AIに社内のデータを使わせようとすると、多くの現場が同じところで止まるようです。答えは返ってくるのにそれが正しいかどうかを確かめる手立てがない、という状態です。原因はモデルにデータを渡す層にあります。

このAI Gatewayシリーズでは、LLM Gatewayのモデルルーティングとコスト管理、そしてそれがModel Context Protocol（MCP）Gatewayのデータソース統制とどう噛み合うかを見てきました。

ただ、精度をいちばん左右するのはその下の層です。正しい答えを出すために必要な最新化され権限に沿って絞り込まれた情報を、AIはどこから手に入れるのでしょうか。この問いに答えるのがコンテキストレイヤーです。ゲートウェイを置いただけでは足りない理由は、企業でAIを使うならMCPゲートウェイだけでは不十分でも整理しています。

VentureBeatの報道によれば、RAGだけに頼る方式の限界に多くの企業がぶつかり、コンテキストとハイブリッド検索の基盤に対する購買意欲は2026年第1四半期に3倍になったといいます。この記事では、ベンダー製・オープンソース・内製のどれであっても使える評価の枠組みを、接続範囲・スキーマ理解・権限適用・測定可能な精度という4つの基準で示します。

対象はCRM、ERP、人事システム（HRIS）、データウェアハウス、チケット管理といった、業務が実際に依存している運用データです。非構造化文書の検索は別の問題として後段で触れます。シリーズ全体はこちらにまとめています。

この記事の要点

定義：AI向けのコンテキストレイヤーとは、業務システムにある正確で最新の情報を権限で絞り込んでAIアプリケーションに供給する層です。AIが何にアクセスできるか、そのデータが何を意味するか、システムをまたいだレコードがどう関係するかまでを解決します。

必要になる場面：文書の束ではなく、CRM・ERP・人事システム・データウェアハウスといった運用データからAIが答えを出す場面すべてです。非構造化コンテンツはRAG（検索拡張生成）が、運用レコードはコンテキストレイヤーが担当します。

4つの評価基準：接続範囲、スキーマ理解と意味の解決、データ層での権限適用、測定可能な精度の4つです。

コンテキストレイヤーは何をする層？

コンテキストレイヤーは、業務システムから正確で最新の情報を権限に沿って取り出し、AIアプリケーションに渡す基盤層です。どのシステムに触れてよいか、そのデータが何を意味するか、システムをまたいだレコードがどう関係するか、そしてAIが接続先とどう対話できるかまでを引き受けます。

位置としては、AIアプリケーションとその上のルーティングゲートウェイ、そして下にある業務データソースの間に入ります。そしてモデルが動く前に、そのリクエストに必要なデータだけを添えます。

先に、隣接する言葉との線引きをしておきます。RAGとの違いは次のセクションで詳しく扱うので、ここでは仕組みが別物だとだけ触れておきます。BI（ビジネスインテリジェンス）でいうセマンティックレイヤーはレポート向けにデータを説明しますが、クエリの瞬間にモデルへ供給はしません。

データカタログは資産を棚卸しするだけで、AIのために問い合わせはしません。データウェアハウスは分析用に履歴を集めますが、システムへの書き込みは担いません。

それに比べると、コンテキストレイヤーの役割はずっと限定的です。正しいリアルタイムのシステムに、正しく解釈し、正しくスコープを絞ったうえでアクセスさせます。担当するのはそこだけです。

この層が独立した基盤として立ち上がってきたのは、AIにやらせる処理が変わったからです。単純なチャットボットなら学習データと文書インデックスで足ります。

一方、動いているシステムに対して操作を行うエージェントはそうはいきません。それらのシステムを正確に問い合わせ、権限の範囲から出ず、出力が信頼できるだけの意味的な裏づけを持ち歩く必要があります。この要件の広がりが、実装の細部でしかなかったコンテキストレイヤーを、単体で評価するに値するカテゴリに変えました。

RAGとコンテキストレイヤーはどう使い分ける？

境界線を分けるのは守備範囲です。非構造化でコンテンツ中心の仕事——ナレッジベースへの問い合わせ、社内ドキュメントの検索、長文の要約——では、RAGが確立された正解であり続けます。定期インデックスと意味検索の組み合わせで十分に機能しますし、そこにコンテキストレイヤーは要りません。

では、RAGが限界に当たるのはどこなのでしょうか。運用データを相手にしたときです。理由は3つあります。

1. インデックスの遅れ：RAGのインデックスは、数時間から数日前のスナップショットにすぎません。今の案件状況や当日の在庫を聞けば、自信たっぷりの誤答が返ってくるでしょう。

2. 権限が見えない：検索が並べるのは類似度の順位だけで、認可の判定は入っていません。質問した本人がそのレコードを見てよいかどうかは、インデックス側では分からないままです。

3. 構造が合わない：RAGは文書のための仕組みで、リレーショナルなレコード向けには作られていません。SalesforceのアカウントとNetSuiteの請求書を突き合わせるのに要るのは、類似度検索ではなくクエリのロジックです。

この3つの上に、もう一段わかりにくい問題が乗ります。もっともらしいチャンクが複数出てきても、どれが正典なのかを示すものがありません。結果としてエージェントは、誤った方から推論を組み立ててしまいます。

逆にコンテキストレイヤーが正解になるのは、次の3つの場面です。データがリアルタイムでアクセス制御下にあるとき、問いが複数システムにまたがってレコードの結合が必要なとき、そして答えがトランザクションシステムの現在の状態に左右されるときですね。

ただ、多くの企業では結論はどちらか一方ではなく両方になります。非構造化コンテンツにはRAGを、運用レコードにはコンテキストレイヤーを充てる形です。単一方式の検索がハイブリッドな設計に置き換わりつつある今、問うべきなのはそれぞれの層に何をさせるかです。RAGを含めた選択肢を横に並べて比べたい方は、生成AIで社内データを利用する4つの方法（Fine-tuning・ICL・RAG・MCP）で違いを整理しているので、あわせて読むと判断しやすくなります。

評価基準1：接続できるデータソースはどこまで広い？

接続範囲とは、AIの業務が実際に必要とするシステムにつなげるかどうかです。PoCでたまたま触れた数本のシステムで済む話ではなく、オンプレミスのシステムやレガシーなデータベースを抱えている企業なら、クラウドSaaSだけでも足りません。届かないデータソースからはコンテキストを供給できない以上、これが土台の基準になります。

評価の段階では、深さより広さが効きます。3つのデータソースで動く構成には最初から天井があり、企業の業務はたいてい5〜15のシステムにまたがるからです。データソースが増えても破綻しない構成の考え方は複数データソースをつなぐスケーラブルなAIエージェントの構築ガイドにまとめているとおり、新しいデータソースごとにコネクタを作り込むのではなく、事前構築済みの広い接続性を土台にして、導入規模の拡大にそのまま対応できる形が望ましいところです。

デモと本物を分ける確認は2つあります。順に見ていきましょう。

1つ目はカスタム項目とカスタムオブジェクトです。Workday、NetSuite、SAPといったシステムは、作り込まれているのが前提になっています。標準オブジェクトは読めてもカスタム項目を取りこぼす層は、ツールを設定して使っている企業にとっては不完全です。コネクタがカスタム項目やカスタムオブジェクトまで見せるのか、標準スキーマだけなのかを確認してください。

2つ目はオンプレミスとプライベートクラウドです。ERPや外に出せないデータを抱える企業には、そのシステムをある場所のまま扱える配置モデルが要ります。先にデータを移動させないと使えないクラウド専用のプロキシは、細かい制限ではなく導入そのものを止める要因になります。

評価基準2：スキーマと意味をどこまで理解できる？

コネクタはデータを取得し、コンテキストレイヤーはデータを理解します。単なるコネクタとの差がもっともはっきり出るのがこの基準です。違いは、明示的に設定していないシステムにエージェントが問い合わせた瞬間や、データベースの列名ではなく業務の言葉で質問が飛んできた瞬間に表面化します。

1つ目の要件はスキーマの理解です。それぞれのデータソースのスキーマを、項目名だけでなくデータ型と関連まで把握し、そのクエリに必要なオブジェクトと項目を選べることを指します。これがないと、エージェントは呼び出しのたびにフルスキーマを要求します。

コストははっきり数字に出ます。絞り込みのないクエリは、スキーマを理解した場合と比べて入力トークンを桁違いに消費するからです。ベンダーには、どのテーブルとどの列を含めるかをシステムがどう判断しているのかを聞いてみてください。

2つ目は意味の解決です。「売上」「アクティブ顧客」「有望案件」は、システムごとにも会計期間ごとにも違う意味になります。dbt、LookML、Snowflakeにある既存のセマンティック定義を取り込む方式でも、その層で直接定義する方式でも構いません。何をどこまでモデルに渡すかという設計思想そのものはコンテキストエンジニアリング入門で基礎から解説していますが、大事なのは、この対応づけを持つ層が正しく取得したデータを誤読する事故を防いでくれるという点です。

3つ目はデータソースをまたいだ関連です。業務上の問いはたいてい複数システムに広がります。Salesforceのアカウントとそれに紐づくNetSuiteの請求書、Workdayの人員数とコストセンターの対応づけといった具合ですね。これを解決できる層は、それぞれが単独で答えるコネクタの寄せ集めとは質的に別のものです。

評価基準3：権限はどの層で効かせる？

コンテキストレイヤーが業務システムに投げるクエリは、すべてリクエストしたユーザー本人の認証情報 (クレデンシャル) とアクセス権限で実行されるべきです。昇格された権限を持つ共有サービスアカウントを、誰がトリガーしたかに関係なくすべてのエージェントが継承する形にしてはいけません。

4つの基準のなかで、セキュリティレビューとコンプライアンスにいちばん直接響くのがここです。導入が自社の統制プロセスを通るかどうかも、この基準で決まります。

データ層で効かせるべき理由は、制約がデータソースごとに違うからです。ルーティングゲートウェイやアプリケーション側の制御は、そのユーザーがAIのエンドポイントを呼んでよいかまでは決められます。ただ、認可済みのシステムの中でどのレコードまで見てよいかは決められません。

そのルールはSalesforceの共有ルール、SAPの権限オブジェクト、データベースの行レベルセキュリティの側にあります。アプリケーション層での適用はデータを取得したあとに動くので、そもそも成立しません。

ここで権限が効いていないと、導入は2方向のどちらかで失敗します。1つは過剰なスコープです。本来見せてはいけないレコードが表に出てしまい、情報漏えいのリスクになります。

もう1つは締めすぎです。現場がやりすぎた反動でアクセスを絞り込み、AIが実務的な問いに答えられず、実際の操作もできなくなります。Protegrityが委託したEMAの調査では、この「導入したが使えない」状態を81.6%の企業が報告しています。

両方に共通する原因は1つです。権限の判断を間違った場所でしていることに尽きます。

監査ログも権限適用とセットで考えてください。ユーザーIDに紐づいたクエリ単位のログ——何を問い合わせ、誰の資格で実行し、何が返ったか——は、規制業種では必須です。

そして、多くの企業がまさにここを持っていません。Deloitteの2026 State of AI in the Enterpriseでは、AIエージェントの統制モデルが成熟していると答えた企業は21%にとどまりました。

ベンダー製でも内製でも、コンテキストレイヤーに投げる質問は同じです。どのユーザーがどのレコードを問い合わせたかを示す、クエリ単位の監査証跡を出せますか。医療、金融、公共の分野で答えがノーなら、そこで導入は止まります。既存システム側の権限をそのままAIに引き継ぐ実装の考え方は、既存の権限を維持してAIへ業務データを公開する方法で具体的に解説しています。

評価基準4：精度とトークン効率を数値で出せる？

最後の基準は測定です。コンテキストレイヤーの品質はモデルの品質より見えにくく、その失敗はモデルの失敗と同じ顔をしています。古い、欠けている、あるいは誤解されたデータが原因の誤答は、モデル自体が原因の誤答と区別がつきません。データアクセス層に可観測性がなければ、切り分けようがないわけです。

だからこそ、こだわる価値のある指標が3つあります。

• グラウンデッド精度率：AIの回答のうち、特定の正しく取得されたレコードまで追跡できるものの割合です。

• トークン効率：フルスキーマにアクセスする場合と比べて、スキーマを理解し権限で絞り込んだ取得が入力トークンをどれだけ減らすかを示します。

• クエリレイテンシ：現実的な負荷のもとで、データ要求からコンテキスト供給までにかかる時間です。

数字があると、測定されたコンテキストレイヤーの姿がはっきりします。CDataの自社検証では、スキーマを理解した取得によって、Salesforce・Snowflake・ServiceNowにまたがる統制下のマルチソースクエリでトークン使用量が97.6%減りました。

別途実施したMCPの精度ベンチマークでは、実運用に近い378件のプロンプトに対してグラウンデッド精度98.5%を記録しています。他のプロバイダーは65〜75%でした。これは、何を要求すべきかを示す一例です。

評価の締めくくりでは、同じ証拠を出してもらってください。自社に近い業務でのグラウンデッド精度のベンチマーク、絞り込みなしのアクセスと比べたトークン効率、そして現実的な負荷でのレイテンシの推移です。この3つを出せないチームは、肝心なところを測っていません。その不在自体が1つのシグナルになります。

CData Connect AIはこの4基準をどう満たす？

CDataでは、ここまでの4基準を前提にConnect AIのコンテキストレイヤーを設計しています。柱にしているのは次の4点です。

• 数百の業務システムをカバーする接続範囲

• スキーマを理解した取得

• データソースをまたいだ意味の解決

• データがモデルに届く前に適用されるユーザー単位の権限

狙っているのは、このカテゴリが本来求めるものをひととおり満たすことです。データソースのコンテキスト、データソース横断の関連、明文化されていない社内の前提、そして必要な分だけを取りに行くコンテキスト取得——ここまで含めて1つの層で扱えるようにしています。実際に、ヘルスケア分野の専門商社の導入事例では、MCP ServerによるSQL抽象化でハルシネーションリスクを抑えながら、追加のチューニングや開発なしにLLMでの自動カテゴライズを実現しています。

次回は評価基準から離れて、Salesforce、SAP、NetSuite、Snowflakeなどでのユースケースを見ていきます。先に踏み込みたい方は、AIエージェントに必要な7つのデータ要件もあわせてご覧ください。

よくある質問

コンテキストレイヤーを自社の環境で試す

4つの評価基準は、資料を読み比べるより、自社のデータソースを実際につないでみるほうが早く確かめられます。CData Connect AIなら、数百の業務システムに対してユーザー単位の権限を効かせたまま、スキーマを理解した取得をAIから呼び出せます。カスタム項目やオンプレミスのシステムも含めて、手元の構成で試せる形になっています。

まずはConnect AIの無料トライアルから、身近な1つのデータソースをつないで、クエリ単位の監査ログとトークン消費量を確認してみてください。数字が手元にあれば、情報システム部門やセキュリティ担当も交えて、部門横断で導入可否を判断できます。