企業AIの活用には、データの「コンテキスト」が不可欠です。RAGとContext Engineの関係を解説し、AIの理解を深める方法を探ります。
前回のVol.01では、企業がAIを実務で活用するためには、単にAIツールを導入するだけではなく、企業固有のデータや知識をAIが理解・活用できる「AI Ready」な状態をつくることが重要だと説明しました。
そのなかで、最後に提示したのが一つの問いです。
「社内データをAIに使わせるのであれば、RAGで十分なのではないか？」
企業における生成AI活用を考えるうえで、RAGは非常に重要な技術です。
RAGとは、Retrieval-Augmented Generation（検索拡張生成）の略称で、生成AIが回答をつくる際に、外部のデータベースや文書などから必要な情報を検索し、その情報を参照しながら回答を生成する仕組みです。
一般的なLLMは、あらかじめ学習した情報をもとに回答します。しかし当然ながら、企業内部の規程やマニュアル、商品情報、過去の資料といった企業固有の情報まで、すべてを事前に学習しているわけではありません。
そこでRAGでは、ユーザーから質問を受けると、まずその質問に関連する情報を社内文書やデータベースなどから検索します。そして、検索によって取得した情報を質問とともにLLMへ渡し、その内容を踏まえて回答を生成します。
基本的な流れは、
「質問 → 検索 → 関連情報の取得 → LLMへの提供 → 回答生成」
と整理できます。
例えば社員がAIに「海外出張時の宿泊費の上限を教えて」と質問したとします。
LLMそのものは、その企業独自の出張規程を知りません。しかしRAGによって社内規程を検索し、該当するページや記述を取得できれば、その情報をもとに企業固有のルールに沿った回答を生成することができます。
また、RAGにはモデルそのものを再学習しなくても、新しい情報をAIに利用させられるというメリットがあります。
商品情報や社内制度、マニュアルなどが更新された場合でも、検索対象となるデータを更新することで、新しい情報を回答へ反映できます。
つまりRAGは、LLMが持つ一般的な知識と、企業が持つ固有の情報をつなぐ重要な仕組みだと言えます。
企業が保有する膨大な文書やナレッジのなかから必要な情報を見つけ出し、その内容を生成AIの回答に活用する。
この「情報を検索し、AIへ届ける」という役割において、RAGは企業AIに欠かせない技術の一つです。
しかし、企業でAIに求められる役割が、単なる「社内情報へのQ&A」から、状況を踏まえた提案や判断へと広がっていくと、新たな問題が見えてきます。
必要な情報を検索できれば、AIは本当に企業を理解できるのでしょうか。
ここからは、RAGが得意とする「検索」と、企業AIに求められる「理解」の違いを考えていきます。
RAGによって、生成AIは企業内部に存在する文書やナレッジを検索し、その内容を回答へ活用できるようになります。
これは企業における生成AI活用を大きく前進させる技術です。
一方で、RAGを導入すれば、AIが企業のあらゆる情報を理解できるようになるわけではありません。
ここで重要なのは、RAGが基本的に得意としているのは、質問に関連する情報を**「見つけること」**だという点です。
例えば、「A社との過去の商談について教えて」と質問した場合、RAGを使ってA社に関連する議事録や提案資料を検索し、その内容をもとに回答することができます。
しかし、企業の実務で求められる問いは、それだけではありません。
「A社の現在の担当者は誰か」
「過去にどの商品を提案し、なぜ失注したのか」
「その後、担当者や組織はどう変わったのか」
「現在の契約状況を踏まえると、次に何を提案すべきなのか」
こうした問いに答えるためには、単に関連する文書を見つけるだけでなく、複数の情報がどのような関係にあるのかを理解する必要があります。
企業データには、特有の複雑さがあります。
例えば、同じ「A社」という企業でも、CRM、ERP、契約管理システム、営業資料など、それぞれのシステムで異なる名称やIDによって管理されていることがあります。
人物についても同様です。同じ社員や顧客担当者に関する情報が、名刺管理、CRM、メール、会議記録などに分散して存在します。
AIがこれらを別々の情報として認識してしまえば、企業全体の状況を正しく捉えることはできません。
さらに、企業には**「時間」**という重要な要素があります。
現在の担当者と過去の担当者、現在の契約と過去の商談、現在の組織と過去の組織では、それぞれ意味が異なります。情報が正しくても、「いつの情報なのか」を理解できなければ、AIは誤った判断をする可能性があります。
加えて、企業では権限や承認フロー、業務ルールも重要です。
誰がどの情報を閲覧できるのか。誰の承認が必要なのか。どの条件で次のアクションを実行してよいのか。
AIが企業の実務に深く関わるほど、こうした情報そのものの外側にある条件まで理解する必要があります。
つまり、RAGによって**「必要な情報を検索できる状態」をつくることと、AIが「企業の状況を理解できる状態」**をつくることには、まだ距離があります。
その違いを生むものこそ、企業データが持つ意味・関係性・履歴・状態・ルール、すなわちContextなのです。
ここまで見てきたように、RAGは企業の中に存在する情報を検索し、生成AIへ届けるうえで非常に有効な技術です。
一方で、AIが企業の実務に深く入り込むためには、もう一段階重要なことがあります。
それが、「Search」と「Understand」の違いです。
Searchとは、質問に関連する情報を見つけることです。
例えば、「A社との過去の商談資料を探して」と指示された場合、A社というキーワードや質問との意味的な類似性をもとに、関連する議事録や提案書、メールなどを取得します。
これはRAGが得意とする領域です。
一方、Understandとは、単に情報を見つけることではありません。
その情報が**「何についての情報なのか」「何と何が関係しているのか」「これまで何が起きたのか」「現在どのような状態なのか」「どのようなルールのもとで扱われるのか」**まで把握することです。
例えば、AIに「今、A社に提案すべき商品は何か」と質問したとします。
この問いに答えるためには、A社に関連する資料を検索するだけでは十分ではありません。
まず、「A社」がどの企業を指しているのかを正しく特定する必要があります。
次に、A社と自社の間にどのような取引関係があり、誰が担当し、過去にどのような提案を行い、何を購入し、現在どのような契約状態にあるのかを理解する必要があります。
さらに、「以前は商品Xを提案したが予算の問題で失注した」「その後A社では新しい事業責任者が就任した」「直近では新規事業への投資を発表している」といった時間的な変化まで組み合わせることで、初めて現在の状況に即した提案が可能になります。
つまり、企業AIが「理解する」ためには、少なくとも5つのContextが重要になります。
一つ目が、Entityです。
人物、企業、商品、案件、組織など、その情報が「何についてのものなのか」を特定します。同じ企業が複数のシステムで異なる名称やIDを持っていても、同一の対象として認識できることが重要です。
二つ目が、Relationshipです。
「田中さんはA社の担当者である」「A社は商品Xを契約している」といった、人物・企業・商品・案件などのつながりです。
三つ目が、Historyです。
過去の商談、契約、異動、問い合わせ、意思決定など、「これまで何が起きてきたのか」という履歴です。
四つ目が、Stateです。
現在の担当者、現在の契約状況、案件の進捗、組織構造など、「今どうなっているのか」を表します。
そして五つ目が、Ruleです。
閲覧権限、承認フロー、価格設定、契約条件、社内ルールなど、「どのような条件で判断し、行動してよいのか」という企業固有のルールです。
これらが組み合わさることで、個々のデータは単なる情報ではなく、AIが企業の状況を理解するためのContextになります。
Searchが「必要な情報を取り出すこと」だとすれば、Understandは「その情報が企業の中で何を意味するのかを捉えること」です。
そして、AIに求められる役割がQ&Aから提案、判断、実行へと広がるほど、この違いは大きくなります。
企業AIに必要なのは、検索をなくすことではありません。
RAGによる優れたSearchに加えて、その検索結果を企業固有のEntity、Relationship、History、State、Ruleの中で位置付けられる状態をつくることです。
では、このContextを企業データから継続的に形成し、RAGを含むAIから利用できる状態にするには、どのような仕組みが必要なのでしょうか。
そこで重要になるのが、Context Engineです。
ここまで、「検索できること」と「理解できること」の違いについて説明してきました。
では、RAGとContext Engineは、どのような関係にあるのでしょうか。
まず明確にしておきたいのは、Context EngineはRAGを置き換えるものではないということです。
RAGは、ユーザーからの質問に対して関連する情報を検索・取得し、その情報をLLMへ届ける重要な仕組みです。一方、Context Engineが担うのは、その検索対象となる企業データを、AIが意味や関係性まで理解しやすい状態へ継続的に整えていくことです。
つまり、両者は異なる役割を持っています。
RAGの中心的な役割が、**「必要な情報を見つけること」だとすれば、Context Engineの役割は、「その情報が企業の中で何を意味するのかを分かる状態にすること」**だと整理できます。
例えば、AIに「A社への次の提案を考えて」と質問したとします。
RAGによって、A社に関連する過去の提案書、商談議事録、契約書などを検索し、LLMへ渡すことはできます。
しかし、それぞれの文書を単独の情報として取得するだけでは、「どの商談が現在の契約につながったのか」「現在の担当者は誰なのか」「過去の失注理由は何だったのか」「直近でA社にどのような変化が起きているのか」といった全体像を把握することは容易ではありません。
そこでContext Engineでは、まず企業データの中に存在する「A社」というEntityを特定します。
そのうえで、A社と担当者、商談、商品、契約などのRelationshipを整理し、過去に何が起きたのかというHistory、現在どのような状況なのかというState、さらに価格条件や承認フローといったRuleまで関連付けていきます。
こうして形成されたContextをRAGと組み合わせることで、AIへ渡される情報の意味が変わります。
単に「A社という言葉が含まれている文書」を検索するだけではなく、**「現在のA社について判断するために、どの情報が重要なのか」**というContextを踏まえて情報を利用できるようになります。
例えば、過去5年間の議事録が大量に存在していたとしても、現在の担当者との直近3か月のやり取りと、3年前に異なる担当者と行った商談では、今の提案を考えるうえでの重要度は異なるはずです。
情報そのものが正しいかどうかだけでなく、誰に関する情報なのか、いつの情報なのか、現在の状態とどうつながっているのかまで理解することで、検索結果をより適切なContextの中に位置付けることができます。
さらに、企業の判断に必要な情報は社内だけに存在するとは限りません。
CRMに保存された商談情報や契約情報といったClosed Dataに加えて、「A社が新規事業を発表した」「経営体制が変わった」「新しい拠点を開設した」といったOpen Dataを組み合わせることで、AIが捉えられる状況はさらに広がります。
Vol.01でも触れたように、Closed Dataだけでは企業の「内側」しか分からず、Open Dataだけではその企業固有の事情までは分かりません。両者をつなぎ、その関係性を継続的に更新することで、AIは企業やその周囲で起きていることをより立体的に理解できるようになります。
Context Engineの役割は、このような企業固有のContextを継続的に形成し、RAGを含むさまざまなAIから利用できる状態にすることです。
そのため、関係は次のように整理できます。
RAG：必要な情報を検索し、AIへ届ける。
Context Engine：企業データの意味・関係性・背景を構造化し、AIが理解するためのContextをつくる。
この二つを組み合わせることで、企業AIの役割は、単純な情報検索やQ&Aからさらに広がっていきます。
例えば、「A社との過去の商談を教えて」という問いに答えるだけでなく、「現在のA社の状況を踏まえると、次に何を提案すべきか」という問いに対して、社内外の情報とその関係性を踏まえた提案を行う。
あるいは人事であれば、「この社員の評価を教えて」だけではなく、過去の経験、スキル、異動履歴、現在の組織状況などを踏まえて、「次にどのような役割で活躍できる可能性があるか」を考える。
つまり、RAG × Context Engineによって目指すのは、情報を回答するAIから、企業の状況を踏まえて考えるAIへの進化です。
AIが企業固有のContextを利用できるようになれば、その活用範囲はQ&Aにとどまりません。状況を理解し、選択肢を提示し、より企業固有の意思決定を支援する存在へと広がっていきます。
そして、その先にあるのが、AI自身が状況を判断し、必要な情報やツールを選び、業務を実行していくAI Agentです。
AIが「回答する」だけではなく「判断し、実行する」ようになったとき、企業データに求められるContextはさらに重要になります。
ここまで、RAGとContext Engineの関係について見てきました。
RAGによって必要な情報を検索し、Context Engineによってその情報の意味・関係性・履歴・状態・ルールを理解できる状態をつくる。
この組み合わせによって、企業におけるAIの役割は大きく変わっていきます。
これまでの生成AI活用では、「この規程について教えて」「過去の商談を要約して」「この資料をまとめて」といった、人間から与えられた問いに回答することが中心でした。
しかし、企業がAIに期待する役割は、そこからさらに広がり始めています。
例えば営業であれば、「A社との過去の商談を教えて」と回答するだけでなく、過去の商談履歴、現在の契約状況、担当者との関係、直近の企業ニュースなどを踏まえて、**「今、A社には何を提案すべきか」**を考える。
人事であれば、「この社員の経歴を教えて」と情報を提示するだけでなく、これまでの経験やスキル、評価、異動履歴、組織の状況などを踏まえて、**「次にどの役割を任せるべきか」**を提案する。
このように、AIの役割が「回答」から「判断」へ広がるほど、重要になるのがContextです。
判断とは、単に多くの情報を持っていることではありません。
**「誰について判断するのか」「これまで何が起きたのか」「今どのような状態なのか」「何を目的としているのか」「どのようなルールや制約があるのか」**を理解したうえで、複数の選択肢から適切なアクションを導き出すことです。
つまり、企業AIの進化は、
情報を検索するAI → 情報を理解するAI → 状況を判断するAI
へと進んでいくと考えることができます。
そして、この先にあるのがAI Agentです。
AI Agentは、人間から一つひとつ指示されるだけではなく、目的に応じて必要な情報を集め、状況を判断し、利用すべきツールや次のアクションを選択し、業務を実行していくことが期待されています。
しかし、AIが自ら判断し、実行する範囲が広がるほど、誤ったContextをもとに行動した場合の影響も大きくなります。
だからこそ、AI Agent時代には、単に高性能なAIモデルを導入するだけではなく、企業固有のContextを正しく、継続的にAIへ提供できる基盤が必要になります。
AIが企業を理解できなければ、企業のために正しく行動することはできない。
では、AIが自ら判断し、実行する「AI Agent」の時代に、企業データにはどのような条件が求められるのでしょうか。
次回のVol.03では、**「AI Agentは、なぜContextなしでは動けないのか？」**という問いから、AI Agent時代に必要となる企業データのあり方をさらに掘り下げていきます。