「AIを入れたのに、いまひとつ」——その正体
期待してAIを導入した。けれど、現場でほとんど使われていない。効果も、はっきりとは見えてこない。
あるいは、こんな経験はないでしょうか。ChatGPTのようなツールに質問しても、返ってくるのは一般論ばかり。自社の事情を踏まえた、本当に欲しい答えにはならない。
実は、これは珍しいことではありません。MIT（マサチューセッツ工科大学）が2025年に公表した調査では、企業のAI導入のうち、損益（会社の利益）に測れる成果を出せたのは、わずか約5%でした。残りの95%は、目に見える効果に届いていません。
では、その差はどこから来るのか。MITが挙げた主な原因は、AIの「頭の良さ」ではありませんでした。原因は、AIが自社の状況に合わせて学べていないことでした。MITはこれを「学習ギャップ」と呼んでいます。
言い換えれば、AIに「自社のこと」が渡っていないのです。ここに、いま注目を集めている考え方があります。それが「コンテキストエンジニアリング」です。
図1：MITの調査では、AI導入で損益に効いたのは約5%。差を分けたのは、AIの賢さではなく「自社の文脈」が渡っているかどうかだった。
コンテキストエンジニアリングとは何か
コンテキストエンジニアリングとは、AIに渡す「文脈（コンテキスト）」全体を設計することです。ここで言う文脈とは、AIに前提として知らせておく情報のことです。
よく似た言葉に「プロンプトエンジニアリング」があります。プロンプトとは、AIへの指示文や聞き方のこと。その工夫は「何を、どう頼むか」に焦点があります。
これに対してコンテキストエンジニアリングは、「AIに、あらかじめ何を知らせておくか」を設計します。聞き方の工夫の、一段上にある考え方です。
この言葉は、2025年にAI研究者のアンドレイ・カーパシー氏や、ShopifyのCEOらが提唱し、広まりました。カーパシー氏はこれを「次の一手に必要な情報を、ちょうどよく渡す技術」と表現しています。
イメージしやすいのは、新人スタッフに仕事を頼む場面です。どれだけ優秀な人でも、自社の事情（顧客の癖、これまでの経緯、社内のルール）を知らなければ、的外れな仕事になります。引き継ぎ資料を渡して、はじめて戦力になる。AIも、これと同じです。
RAGとの違いも、ここで整理
AIの話でよく出てくる「RAG」（検索拡張生成）。これは、自社の資料を検索してAIに渡す仕組みのことです。RAGは、コンテキストエンジニアリングの手段の一つにあたります。文脈を渡す方法のひとつがRAG、という関係で捉えると、混乱しません。
3つの言葉の関係を、一覧で整理します。
| 用語 | ひとことで言うと | 焦点 |
|---|---|---|
| プロンプトエンジニアリング | AIへの「聞き方・頼み方」の工夫 | 何を・どう頼むか |
| コンテキストエンジニアリング | AIに「あらかじめ何を知らせるか」の設計 | 渡す情報の全体 |
| RAG | 自社の資料を検索してAIに渡す仕組み | 文脈を渡す手段の一つ |
図2：コンテキストエンジニアリングは「AIに渡す情報全体」を設計すること。プロンプトの工夫やRAGは、その中の手段にあたる。
中小企業は「自社の文脈」をどう渡すか
では、渡すべき「自社の文脈」とは、具体的に何でしょうか。
ベンチャーネットは、その正体を「経験情報」と呼んでいます。自社にしかない情報のことです。たとえば、次のようなものです。
- 商談メモや、顧客ごとの細かな事情
- 原価の勘所、値決めの判断
- ベテランが積み上げてきた暗黙の判断基準
- 過去の失敗とそこから得た学び
これらの多くは、人の頭の中や、バラバラの場所に眠っています。つまり、AIに渡せる形にはなっていません。
だからこそ、順序が大切です。
- 見える化：散らばった情報を集め、記録する
- 言語化：暗黙のうちにある判断を、言葉やルールにする
- AIに渡す：その文脈を前提として、AIに仕事をさせる
図3：自社の文脈を渡す道のりは「見える化 → 言語化 → AIに渡す」の順。まずは貯める入口から、必要な分をちょうどよく。
この順序は、先ほどのMITの調査とも重なります。成果を出した企業に共通していたのは、汎用ツールをそのまま使うのではなく、フィードバックから学び、文脈を保持する仕組みを持っていたことでした。
実際の入口は、まず「貯める」ところからです。商談メモや議事録を一か所に集約する。そこからRAGの仕組みで、「自社の資料に基づいて答えるAI」へと育てていきます。
ひとつ注意があります。情報は、全部放り込めばいいわけではありません。多すぎると、AIはかえって重要な点を見失います。必要なものを選んで、ちょうどよく渡す。その設計こそが肝心です。
なぜ「自社の文脈」が効くのか
ここまで読んで、こう感じた方もいるかもしれません。なぜ、そこまでして自社の文脈にこだわるのか、と。
理由は、シンプルです。自社の文脈は、他社には真似できないからです。
同じAIを誰もが使える時代に、差がつくのは「AIに何を渡せるか」です。AI時代の競争優位は、いちばん賢いAIを選ぶことではありません。自社の知識を、使うほど賢くなる仕組みに変えること。そうして、自社の経験が、自社だけの資産になっていきます。
このことは、いま起きている「つまずき」の裏返しでもあります。調査会社のGartnerは2025年、自律的に動くAI（エージェンティックAI）のプロジェクトの4割超が、2027年末までに中止されると予測しました。理由として挙げられたのは、コストの増大、価値の不明確さ、リスク管理の不足、そして話題先行のお試し（PoC＝試験導入）で終わってしまうことです。
つまり、AIを「入れること」そのものが目的になると、止まります。渡した文脈を、自社の成果につなげる。その設計があるかどうかが、分かれ目です。
よくある誤解
Q. もっと高性能なAIに変えれば、解決しますか？
モデルの性能差よりも、自社の文脈が渡っているかどうかの差のほうが大きい、というのがMITの指摘です。まず渡す設計を見直すほうが、近道になることが多いものです。
Q. 情報は、全部入れるほど賢くなりますか？
むしろ逆です。多すぎると精度が落ちます。必要な情報を選んで渡す設計が大切です。
Q. RAGを入れれば、コンテキストエンジニアリングは完了ですか？
RAGは手段の一つです。何を・いつ・どう渡すか、その全体の設計が本体になります。
Q. うちは小さいから、関係ない話では？
そんなことはありません。規模が小さいほど、現場の経験情報が一人ひとりに濃く眠っています。渡せる文脈の宝庫だと言えます。
まとめ：渡す設計は、人の仕事
コンテキストエンジニアリングとは、AIに自社の文脈を渡す設計のことでした。成果の分かれ目は、AIの賢さよりも、自社の経験情報をどう渡すかにあります。
そして、ここが大切な点です。何を渡し、何を渡さないか。AIの答えを、どこまで採用するか。それを決めるのは、人です。
便利なAIほど、その判断をつい無批判に受け入れてしまいます。だからこそ、最後の判断と責任は、人が持つ。AIに自社の文脈を渡せば渡すほど、人の経験と判断の価値は、むしろ上がっていきます。
とはいえ、見える化・言語化・渡す設計を、自社だけで進めるのは簡単ではありません。とくに「何を渡すべきか」は、社内にいる人ほど”当たり前”として見過ごしやすいものです。日々の判断に溶け込んだ勘どころは、外からの視点が入って、はじめて言葉になります。
何から手をつけ、どこまでをAIに任せ、どこからを人が握るのか。その設計と実装に、ベンチャーネットは伴走します。
まずは、自社の経験情報を「貯める」ところから。あるいは、AI導入がPoCで止まらない進め方から。次の一歩を、一緒に考えていきましょう。
