MCP最大の改訂は「認可」だった——社内SaaSをすべてRAGに入れてはいけない理由

MCPの認可強化が示す、AIエージェント時代のデータアクセス設計と統制

2026年7月28日、AIエージェントと外部システムをつなぐオープン標準MCP（Model Context Protocol）の新仕様「2026-07-28」が正式リリースされました。MCPのリードメンテナ自身が「プロトコル発足以来、最大の改訂」と位置づけたバージョンです（2026年5月21日のリリース候補公開時の表現）。

仕様上のハイライトは、プロトコルコアのステートレス化です。初期化ハンドシェイクとプロトコルレベルのセッションが廃止され、MCPサーバーを一般的なHTTP基盤上で水平スケールさせやすくなりました。重要な構造変更です。

それでも本稿は、今回の最大の改訂を「認可」だと捉えます。ここでいう「最大」とは、変更項目の数や破壊的変更の大きさではなく、企業がAIエージェントを実運用するうえでの重要性を指しています。根拠は、リリースノートのこの一文です。

Original

“authorization is where implementers spend most of their integration time”

日本語訳

「認可こそ、実装者が統合作業で最も時間を費やしている領域である」

※文意と読みやすさを優先した独自訳です。逐語訳ではありません。

出典 Model Context Protocol Blog, “The 2026-07-28 Specification,” July 28, 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/

実際、6月に安定版となったEnterprise-Managed Authorization（EMA）拡張と合わせて見ると、企業から見えるMCPの認可は、この改訂の前後で次のように変わりました。なおEMAはコア仕様に含まれる自動適用の機能ではなく、明示的に対応するオプトインの拡張です。

一言でまとめれば、EMAを採用する企業では、MCPサーバーへの接続認可が「利用者ごとの個別作業」から「組織が所有する統治対象」へ移る、ということです。

もう一つ、企業の統制基盤にとって重要なのが、Mcp-MethodとMcp-Nameヘッダーの必須化です。従来、「どのメソッドの、どのツールが呼ばれようとしているか」はJSON-RPCの本文の中にあり、ゲートウェイやWAFは本文を解析しなければ判断できませんでした。新仕様では、この2つがHTTPヘッダーとして必ず外側に出ます。さらに、ヘッダーと本文の内容が食い違うリクエストはサーバー側で拒否されるため、ヘッダーだけを見て通した後に本文で別の操作が実行される、という経路のすり替えも塞がれています。結果として、ツール単位の許可・拒否、利用量の計測、監査ログの記録、追加承認への振り分けといった統制を、MCPサーバーの手前で実装しやすくなりました。認可の強化が「誰が接続してよいか」の話だとすれば、こちらは「その接続で何をしようとしているか」を、統制側が低コストで把握できるようにする変更です。

MCPは2024年11月の登場から、OpenAI、Google、Microsoftを含む主要各社に採用され、2025年12月にはLinux Foundation傘下へ寄贈されてベンダー中立の標準になりました。Tier 1 SDKの月間ダウンロードは、合計で5億件近くに達しています（2026年7月28日時点、MCP公式ブログ）。MCPが標準化するのは接続方式と相互運用性であり、データモデルや業務上の意味、監査までを解決するものではありませんが、「AIと社内システムをどう接続するか」という技術的な摩擦は、確実に下がりつつあります。

接続コストが下がった結果、企業AIの論点は明確に次へ移りました。

つないだAIエージェントに、誰の権限で、どのデータを、どこまで参照・実行させるのか。

ところが、社内のAI導入の現場では、この論点の移動に追いついていない設計がまだ多く残っています。その代表が、「社内のデータをかき集めてベクトル化し、RAGで検索できるようにすれば、AI-readyなデータ基盤が完成する」という考え方です。あらかじめ断っておくと、問題はRAGという技術そのものではありません。現在状態の確認、横断的な分析、文書の意味検索は、それぞれ異なる鮮度・権限・監査・失敗時の制御を必要とします。それらを、権限やデータの性質を区別しない一つの検索空間へ押し込む設計に問題があるのです。

本記事では、情報システム部門の視点から、AIエージェントと社内データの接続をどう設計すべきかを整理します。

この記事の結論

AI-readyな社内基盤とは、すべてのデータを一か所へ集約することではありません。データの性質に応じて、AIエージェントが正しい参照経路を選択でき、そのすべてに利用者の権限と監査が適用される状態です。

本記事の要点は次の3つです。

• AI-readyな社内基盤とは、全データの集約ではない。データの性質に応じた3つの参照経路——正データ源への直接参照、整備済みの横断データ、意味検索——を設計することである
• 経路の設計だけでは足りない。記憶・権限・実行・監査という4つの統治を、すべての経路に横断的に適用する必要がある
• 2026年、MCPの最大改訂、NISTの検討開始、大型買収が示すように、企業AIの論点は「どうつなぐか」から「誰の権限で、何を、どこまで」へ移った

「AI-ready=全部集約」という誤解

生成AI導入の文脈で「まずデータを整備しよう」「データレイクに集約しよう」という話がよく出ます。方向性としては間違っていませんが、「集約すればAI-readyになる」というのは誤解です。

Gartnerはこの点について明確な整理をしています。AI-readyなデータとは、特定のAIユースケースに対する適合性を、文脈に即して継続的に証明できるデータのことであり、その上でこう断言しています。

Original

“There is no way to make data AI-ready in general or in advance.”

日本語訳

「データを一般的に、あるいは事前にAI-readyにする方法は存在しない」

※文意と読みやすさを優先した独自訳です。逐語訳ではありません。

出典 Gartner, “AI-Ready Data Essentials to Capture AI Value.” https://www.gartner.com/en/articles/ai-ready-data

つまりAI-readinessは「データの状態」ではなく「用途とデータの関係」であり、静的な整備プロジェクトで一度達成して終わるものではないのです。

同時にGartnerは、2026年までに、AI-readyなデータに支えられていないAIプロジェクトの60%が放棄されると予測していました（2025年2月時点の予測）。背景にあるのは同社の調査で、63%の組織が「AIに適したデータ管理実務を持っていない、または持っているか分からない」と回答したという事実です。データ整備が不要という話ではまったくなく、「何のために、どの経路で使うか」を設計しないままの集約は価値につながらない、ということです。

では「用途に応じた正しい経路」とは何か。本題に入る前に、なぜ「すべてRAGへ」が危ないのかを、セキュリティの観点から確認しておきます。

なぜ「すべてRAGへ」が危ないのか

権限の壁抜け：元システムのアクセス制御は自動では引き継がれない

OWASPが公開している「Top 10 for LLM Applications 2025」には、新しいリスクカテゴリとして「Vector and Embedding Weaknesses（ベクトルと埋め込みの脆弱性）」が追加されました。ここで指摘されている問題のひとつが、まさに権限の問題です。

典型的なシナリオはこうです。SharePointやファイルサーバーには、フォルダ単位・ファイル単位で細かなアクセス権限が設定されています。ところが、これらの文書をRAGパイプラインで取り込み、ベクトル化して検索基盤に格納しても、元システムのACLや行・文書単位の権限が自動的に再現されるわけではありません。ベクトルDB側にもメタデータフィルタやテナント分離、ACL同期といった制御は実装できますが、それは「実装すれば」の話です。権限情報をメタデータとして同期し、検索時に利用者の文脈で絞り込む設計がなければ、本来そのファイルを見られないはずのユーザーが、AI経由でその内容を「回答」として受け取ってしまう。当社ではこれを「権限の壁抜け」と呼んでいます。

元システムで何年もかけて設計・運用してきたアクセス制御は、ETLとベクトル化を経ると自動では付いてこない——複製先で再実装し、同期し続ける必要がある。権限の壁抜けとは、元システムのアクセス制御がデータの複製・ベクトル化の過程で複製先に引き継がれず、本来の閲覧範囲を超えて情報がAI経由で参照可能になる状態を指します。これが「とりあえず全部RAGへ」という設計が見落としがちな運用コストの正体です。

オーバーシェアリング増幅：Copilotが可視化した「昔からあった問題」

Microsoft 365 Copilotの企業導入で広く知られるようになったのが、オーバーシェアリング（過剰共有）の問題です。

重要なのは、Copilot自体は権限を破っていないという点です。Microsoftが明言している通り、Copilotはユーザーが既に閲覧権限を持つコンテンツしか参照しません。Microsoft自身が公式に整理しているのは、過剰な権限付与、継承されたアクセス、機密ラベルの未整備といったガバナンスの隙間が、生成AIとエージェントによって増幅されるという構図です。長年放置されてきた過剰共有を、AIが即座に発見・要約可能にしてしまうのです。

全社共有になったまま忘れられていた給与ファイル、リンクを知っていれば誰でも見られる設定のM&A資料——従来は「探さなければ見つからない」ことが事実上の防壁になっていました。AIアシスタントはこの防壁を取り払います。「役員報酬について教えて」と聞くだけで、アクセスできてしまうファイルを横断的に要約してくれるのですから。

Microsoft自身もこれを認識しており、Copilot導入前の権限棚卸し、SharePointの共有設定レビュー、機密ラベルの整備を導入手順として推奨しています。教訓は明快です。AIにデータを読ませる範囲を広げる前に、その範囲の権限が本当に正しいかを確認しなければならない。AIは権限設計の品質を増幅する装置であり、雑な権限は雑なまま高速化されます。

EchoLeak：検索対象の文書が「信頼できない入力」になった日

2025年6月に開示されたEchoLeak（CVE-2025-32711）は、この議論を決定的にしました。研究チームのAim Labsが、実運用中のAIエージェントに対する初のゼロクリック攻撃と位置づけた事例です。

攻撃の仕組みはこうです。攻撃者は、悪意ある指示を巧妙に埋め込んだメールを標的組織の誰かに送ります。受信者がそのメールを操作する必要はありません。後日、受信者がCopilotに何か業務上の質問をしたとき、RAGの検索機構がそのメールを「関連コンテキスト」として拾い上げ、埋め込まれていた指示をCopilotが処理してしまう。研究者らはこれを「LLMスコープ違反」と呼び、特定の条件下で、利用者がアクセス可能な範囲のデータの流出につながる可能性があったと報告しています。CVSSスコアは9.3。Microsoftはサーバー側で修正済みで、既知の悪用は確認されていません。

EchoLeakが示した本質は、Copilot固有の欠陥ではなく、次の一般則です。検索対象に入れた文書は、AIにとっての知識であると同時に、信頼できない入力でもある。外部から届くメールや文書と、社内の機密データを、同じ検索空間・同じコンテキストに同居させる設計は、それ自体が攻撃面になります。「とりあえず全部つないでおけば便利」の代償は、便利さと同じスケールで拡大するのです。

3つのアクセスレイヤー

では、どう設計すべきか。当社が実務で使っている整理が「3つのアクセスレイヤー」です。3つのアクセスレイヤーとは、AIエージェントが社内データを参照する経路を、①正データ源への直接参照（System of Record Access）、②整備済みの横断データ（Agent-ready Data）、③文書の意味検索（Knowledge Retrieval）の3つに分け、質問の性質に応じて使い分ける設計フレームのことです。断っておくと、これは業界標準や特定ベンダーが定義した正式な階層モデルではありません。System of Record、DWH、検索基盤を上から順に通過する物理的な階層構造でもなく、質問の性質に応じてエージェントが参照先を切り替える、並列的な経路として捉えてください。

レイヤー1：System of Record Access——正データ源へ直接つなぐ

「現在の値」が重要な情報のための経路です。

• このアカウントは現在有効か
• この申請は誰の承認待ちか
• このSaaSライセンスは割り当て済みか
• このインシデントは今どのステータスか
• この社員の有給残日数は何日か

これらに共通するのは、答えが一意に定まり、かつ鮮度が命であることです。エージェントは現在値を権威ある情報として記憶・複製せず、質問された時点でID基盤・ITSM・人事システム・SaaS管理台帳といった正データ源（System of Record）へ問い合わせます。

この方式の価値は「最新データが取れる」ことだけではありません。

• 利用者のIdentity Contextを伝播できれば、元システムの権限モデルを利用しやすい（逆に言えば、強力なサービスアカウント経由の直接接続では質問者本人の権限は反映されない——直接接続そのものではなく、正しい委任認可との組み合わせが安全性を作る）
• 回答の根拠を「どのシステムのどのレコードか」まで追跡できる
• データ複製に起因する陳腐化や、正データ源の分裂を抑えられる（キャッシュやSaaS内部の結果整合性による一時的な差異は残るが、恒常的な複製基盤に起因する同期・権限管理の負荷を抑えられる）

ただし、この経路にも実務上の限界があります。エージェントが1つの回答のために複数のツールを自律的に呼び出すと、都度アクセスの積み重ねで回答まで数秒〜数十秒の遅延が生じたり、SaaS側のAPIレート制限に達したりします。ここで短期キャッシュを挟むなら、キャッシュの保持期間（TTL）を延ばすほど応答は速くなる一方で、「その間に権限や値が変わっていたら」というリスクを飲むことになる——鮮度・権限再検証とパフォーマンスのトレードオフをどこで切るかが、レイヤー1の設計の実務的な急所です。

冒頭で触れたMCPは、3つのアクセス経路すべての接続に利用できる汎用の規格ですが、正データ源へのツール/API参照はその代表的な用途です。「エージェントが必要なとき、認可された範囲で外部システムへ取りに行く」という設計の技術的な摩擦を、MCPは大きく下げました。2026-07-28仕様の認可強化は、この経路を企業で運用するための基盤整備にほかなりません。

小さな実例をひとつ。仕組みを確認するため、最初は人事領域の架空データでデモを行いました。人事担当者の設定を与えたAIバディ「RiN」に「森田さんの有給残日数は？」と尋ねると、「18.6日」という答えとともに、繰越・付与・消化の内訳と参照元（どのテーブルのどの行か）が返ってきます。この回答は、一般に「文書RAG」としてイメージされる埋め込み・ベクトル検索ではありません。社員IDをキーに、構造化データベースから該当行を確定的に取得するAPI参照です。「意味的に近い文書」を探すのではなく、「正しい1行」を取りに行く。同じ設計は、SaaSライセンスの割当状況、アカウントの有効状態、申請ステータスなど、情報システム部門が扱う現在値にもそのまま適用できます。

レイヤー2：Agent-ready Data——横断利用のために整備されたデータ

一方、正データ源への都度アクセスだけでは成立しない領域があります。複数システム・複数拠点をまたぐ集計や分析です。

• 退職予定者に残っているアカウントを全SaaS横断で一覧化する
• 未利用ライセンスと契約費用を照合する
• 部門別のITコストを集計する
• 端末・アカウント・権限・所属情報の不整合を検出する

この種の問いに都度、各SaaSのAPIを何十回も叩くのは、レイテンシ・レート制限・コストのすべてで非効率です。ETLやCDC（変更データキャプチャ）でデータを統合し、エージェントが参照しやすい形に整えるのが適切です。

ただし、ここで強調したいのは、データウェアハウスに集めただけでは「Agent-ready」とは呼べないということです。人間のアナリストがBIツールで見るデータと、エージェントが自律的に参照して回答根拠にするデータでは、要求水準が違います。最低限、次のメタデータと統制が揃って初めてAgent-readyです。

• 出所と最終同期時刻：「この数字はいつ時点のスナップショットか」をエージェントが回答に明示できること
• 権限の再実装：元システムのアクセス制御を、集約後のデータにも忠実に反映すること（前述の壁抜け対策）
• 組織・法人・地域の境界：データレジデンシー要件を含め、誰のデータをどこに置き、誰が越境参照できるかの定義
• マスキング状態：個人情報がどの粒度で匿名化・仮名化されているか
• 元データへのドリルバック経路：集計値から個票へ遡る必要が出たとき、正データ源側の権限で確認できる道筋

Gartnerが「AI-readinessは静的でなく、メタデータによって継続的に証明されるもの」と整理しているのは、まさにこの層の話です。

レイヤー3：Knowledge Retrieval——文書と過去事例を意味で探す

そしてRAGが本来の力を発揮するのが、この第3の経路です。

• 社内ITポリシー、セキュリティ規程
• SaaSの利用手順書、運用マニュアル
• 過去の問い合わせ、障害報告書、インシデント対応記録
• システム設計書、ベンダー契約条件

これらは自然言語で書かれた文書であり、「社員番号」や「ステータス」のような完全一致では探せません。「VPNにつながらない」という問い合わせに対して、表現の異なる過去事例や手順書を探し当てる——ここでは全文検索、ベクトル検索、その両者を組み合わせたハイブリッド検索が有効に機能します。

ただし、この経路にも規律が要ります。検索で取得した情報は「関連しそうな過去の文書」であって、「現在の正しい値」ではありません。したがって、規程の版数と適用期間、廃止・改定の状況、引用箇所と原文へのリンクを回答に付与する設計が必要です。改定前の古い規程を根拠に回答してしまう事故は、検索インデックスの更新運用（TTL、変更検知による再インデクシング）とセットで防ぎます。

3つの経路は1つの質問の中で交差する

この3レイヤーの使い分けは、実際の問い合わせでは1つの質問の中で交差します。

社員から「Salesforceにログインできない」と問い合わせが来たとき、エージェントは何を見るべきでしょうか。

• ID基盤でアカウントが有効か確認する → レイヤー1（直接参照）
• SaaS管理台帳でライセンス割当を確認する → レイヤー1
• Salesforce側の現在の障害ステータスを確認する → レイヤー1
• 同様の障害が全社・全拠点で増加していないか集計する → レイヤー2（整備済み横断データ）
• 手順書や過去チケットから解決策を検索する → レイヤー3（意味検索）
• 権限変更が必要なら、人の承認へ回す → 後述の統治レイヤー

これは、権限や鮮度を区別しない単一のベクトル検索基盤だけでは、安全かつ正確には解けません。「現在この利用者のVPN権限が有効か」と「VPN接続トラブルの過去の解決手順」は、同じVPNの話でも参照すべき経路がまったく違うのです。この区別を設計せずにすべてを1つの検索空間に押し込むことが、精度問題（古い情報・無関係な情報の混入）とセキュリティ問題（権限の壁抜け・攻撃面の拡大）の共通の根本原因になっています。

補足しておくと、あらゆる組織にこの3経路すべてが必要なわけではありません。扱う情報が規程や手順書などの文書に偏っていて、現在値の照会がほとんど発生せず、参照範囲が全社公開の情報に限られるのであれば、文書RAG単体の構成でも合理的です。本記事の整理が効いてくるのは、人事・IT資産・申請ワークフローのように「今この瞬間の値」と「利用者ごとに見える範囲」が業務上の意味を持つデータを、エージェントに扱わせようとしたときです。自社がどちらに当たるかを見極めることが、設計の最初の判断になります。

経路だけでは足りない：4つの統治

3つのアクセスレイヤーは「どこから読むか」の設計です。しかし実運用でAI-readyと呼べる状態には、「読んだ後」「読む前」の統治が4つ必要だと考えています。

統治1：記憶の規律——エージェントに何を覚えさせないか

AIエージェントには「記憶」を持たせられます。ユーザーの好み、業務方針、繰り返し使う手順——これらを覚えることで、エージェントは回を追うごとに使いやすくなります。

しかし、記憶に置いてよい情報と、絶対に置いてはいけない情報があります。

記憶してよいもの：業務方針、回答スタイル、手順、利用者の継続的な嗜好。変化が緩やかで、権限上の問題がないもの。

記憶してはいけないもの：有給残日数、給与額、評価結果、申請ステータス、在庫、契約状態。つまり正データ源に「現在の値」が存在するマスターデータを、権威ある情報として長期記憶に保存してはいけません。パフォーマンスのための短期キャッシュや分析用の複製を否定するものではありませんが、その場合は取得時刻、TTL、用途、正データ源、再確認の条件を持たせ、「これは正の値ではなくコピーである」ことをシステムが自覚している状態にします。

理由は3つあります。第一に鮮度——記憶した瞬間から陳腐化が始まり、古い残日数を根拠に承認するような事故につながります。第二に権限——正データ源のアクセス制御は、エージェントの記憶へコピーしても自動では引き継がれません。記憶側で同等の権限を再実装し、元システムの変更に追従させ続けなければ、元のアクセス境界は失われます。第三にSingle Source of Truth——正しい値の在り処が複数箇所に分散すると、「どれが本当か」という問い自体が成立しなくなります。

記憶はデータベースの代替ではない。 この一線を設計と実装のレベルで守れているかが、エージェント基盤の成熟度を測るひとつの試金石だと考えています。

統治2：Identity Context——「誰が聞いているか」の伝播

エージェントが何を見られるかは、「エージェントというシステムの権限」だけで決まってはいけません。決めるべきは「誰が、どの立場で聞いているか」です。

• 質問者は誰か（本人のデータか、他人のデータか）
• どの部署・法人・地域に所属しているか
• 管理者権限か、一般利用者か
• 一時的な特権（昇格）を持っているか

この文脈を、エージェントが行うすべてのツール呼び出し・クエリに伝播させる必要があります。エージェントに強力なサービスアカウントを1つ与えて全社データを読ませる設計は、構築は簡単ですが、全利用者の質問が最強権限で実行されることを意味します。エージェント時代のアクセス制御は「ログイン時に一度確認して終わり」ではなく、ツール呼び出しのたびに、その呼び出しの文脈で検証されるものへと変わっていきます。ゼロトラストの原則が、人間のアクセスからエージェントの動作単位へと粒度を細かくして適用されていく、と言い換えてもよいでしょう。

この「権限の伝播」のうち、企業のIdPからMCPサーバーへ至る「入口」の部分を標準化しているのが、冒頭の表で触れたEMAです。EMAはコア仕様の一部ではなく、2026年6月18日に安定版となった独立したオプトイン拡張であり、2026-07-28仕様では、MCP AppsやTasksと並ぶ正式な拡張フレームワーク上に位置づけられました。EMAは、組織のIDプロバイダー（IdP）をMCPサーバーアクセスの権威ある決定者にする設計で、その思想は公式の一句に集約されています。

Original

“Authorize once, inherit everywhere”

日本語訳

「一度認可すれば、あらゆる場所へ継承される」

※文意と読みやすさを優先した独自訳です。逐語訳ではありません。

出典 Paul Carleton (Core Maintainer), Model Context Protocol Blog, “Enterprise-Managed Authorization: Zero-touch OAuth for MCP,” June 18, 2026. https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/

管理者がポリシーを一度定義すれば、利用者は既存の企業IDでログインするだけで、グループ・ロール・条件付きアクセスに応じた範囲のサーバーへ接続され、アクセス決定と監査証跡はIdPの管理コンソールに一元化されます。IdP側はOktaが最初に対応し、クライアントではAnthropic（Claude）やVisual Studio Code、サーバー側ではAsana、Figma、Linearをはじめ複数の主要SaaSが採用を表明済みです。「誰が、どの所属・ロールで使っているか」をエージェントの接続に反映させる仕組みが、特定ベンダーの独自機能ではなく業界標準の拡張として整備された——これは本稿で言うIdentity Contextの土台がプロトコルレベルで揃い始めたことを意味します。

ただし、EMAが解決するのは「IdPからMCPサーバーへの接続と、その入口の認可」までです。その先にはラストワンマイルが残ります。IdP側で認証とポリシーを一元化できても、接続先の個別SaaSや内製システムが、そのIDに紐づく細かな権限——レコード単位・フィールド単位のACL——をAPI経由で正確に認識し、強制できるかは別問題です。ここは各システムのAPIの成熟度に依存し、実際には「入口の認可は標準化されたが、奥の権限はシステムごとにばらばら」という状態がしばらく続きます。Identity Contextの設計とは、この入口から奥までの権限の連鎖を、システムごとに点検する仕事でもあります。

この問題はMCP固有のものでもありません。米国NISTのNational Cybersecurity Center of Excellence（NCCoE）は2026年2月、「ソフトウェアおよびAIエージェントのIDと認可」に関するコンセプトペーパーを初期公開ドラフトとして公開し、意見募集を行いました。AIエージェントに多様なデータ・ツール・アプリケーションへのアクセスを与えることのリスクを正面から扱い、エージェントの識別、認可、監査、行為の否認防止、そしてプロンプトインジェクション対策までを検討対象としています。標準が成立したわけではまだありませんが、エージェントのIDと権限の設計が、公的な標準適用・実証の検討テーマとして独立に立ち上がったということです。

市場も同じ方向に動いています。MCP新仕様と同じ2026年7月28日、データセキュリティ企業Cyeraが、AIエージェントなどの非人間ID（Non-Human Identity）管理を手がけるOasis Securityの買収で基本合意したと発表されました。買収額は約10億ドルと報じられていますが、公式には取引条件は開示されておらず、取引もまだ完了していません。CyeraはFortune 500企業内の非人間IDが直近6か月で約5倍に増えたと説明していますが、これは同社の自社集計で、公開された調査方法はない点には留意が必要です。それでも、「どのデータが機密か」を管理するデータセキュリティと「誰が（何が）アクセスしているか」を管理するID統治を統合しようとする大型取引は、エージェントのアクセス統治が独立した市場課題になったことを示す一例と言えます。

プロトコル標準（MCP/EMA）、公的な標準適用・実証の検討（NIST）、市場の投資（Cyera/Oasis）——三つの方向から同じ結論が指し示されています。データの管理とIDの管理は、エージェント時代には切り離せない。

統治3：Action Control——参照と実行の分離

データを読めることと、変更できることは、明確に分離すべきです。さらに「変更」の中にも段階があります。

• アカウント状態の確認：自動でよい
• パスワードリセット：本人確認を条件に自動
• 管理者権限の付与：人の承認を必須に
• 契約解約・データ削除：人が実行し、エージェントは準備までに留める

そして忘れてはならないのが、参照権限があっても回答すべきでない領域の存在です。給与、評価、社会保険、懲戒、人事異動——これらはデータとして取得可能でも、エージェントがそのまま回答・実行してよいとは限りません。質問を分類し、センシティブ領域と判定したら停止し、適切な承認者へルーティングし、その判断過程を記録する。どの領域を停止対象にするかは、すべての企業に共通の一般法則があるわけではなく、各組織のリスク分類で決めるポリシー設計の問題です。当社のデモでは、誤回答や権限逸脱の影響が大きい給与関連の問い合わせを、承認待ち停止の対象にしています。「止まれること」は機能制限ではなく、企業でAIを任せられる範囲を広げるための前提条件です。

統治4：Auditability——「なぜその回答をしたか」を再構成できること

最後が監査可能性です。エージェントの回答が誤っていたとき、あるいは情報漏洩が疑われたとき、次を再構成できなければなりません。

• どのシステムを、どの権限で参照したか
• どの条件で検索し、何がヒットしたか
• 取得したデータはいつ時点のものか
• なぜ自動実行し、あるいはなぜ停止したか

これは3つのレイヤーすべてに横串で必要です。直接参照ならクエリログ、整備済みデータなら同期時刻とリネージ、意味検索なら検索クエリとヒット文書の記録。EchoLeakのような攻撃が「通常のCopilot利用の裏で気づかれずに進行する」性質を持っていたことを思い出してください。エージェントの動作が観測できない基盤は、便利になるほど危険になります。

なお、この観測可能性についても、仕様側の整備が進んでいます。2026-07-28仕様では、W3C Trace Contextが固定のキー名で伝播されるようになり、クライアント、ゲートウェイ、MCPサーバーをまたいだ分散トレースをOpenTelemetry互換の形で取得しやすくなりました。「どのエージェントの、どの一連の処理の中で、この呼び出しが起きたのか」を、実装ごとの独自仕様ではなく標準的な形で追跡できるということです。監査可能性は、後から足す機能ではなく、経路の設計と同時に決まるものになりつつあります。

日本企業の文脈で

日本でも制度面の整備は進んでいます。総務省・経済産業省の「AI事業者ガイドライン」は2024年4月の初版以降も更新が続けられており、AIの安全性・プライバシー保護・セキュリティ確保・透明性・アカウンタビリティを、開発者・提供者・利用者それぞれの立場で求めています。また、IPAセキュリティセンターは2026年4月から、AIシステムのインシデントや対策動向を扱う「AIセキュリティ短信」を公式に公開しています。2026年6月号では、AIエージェントによるスプレッドシートからのデータ流出の脆弱性など、AIエージェントを取り巻く国内外のセキュリティ事例が具体的に取り上げられました（短信は外部公開情報の収集・要約であり、個々の事例の正確性をIPAが保証するものではありません）。本稿で扱ってきた「エージェントが外部データを読み、社内データへアクセスし、操作を行う」構造のリスクを、国内の公的機関も具体的なセキュリティ事例として収集・紹介し始めているということです。

ただ、これらのガイドラインが示すのは「何を守るべきか」であり、「どう作るべきか」は各社の設計に委ねられています。本稿の3レイヤー×4統治は、その設計の叩き台として使えるはずです。個人情報保護法第28条に基づく外国にある第三者への提供の規律に加え、各国法・業界規制・顧客契約上のデータレジデンシー要件は、特にレイヤー2（どこにデータを集約するか）とIdentity Context（誰が越境して参照できるか）の設計に直結します。グローバル拠点を持つ企業では、「技術的に集約できるか」より先に「法的・契約的に集約してよいか」を確認する順序になる点も付記しておきます。

まず何から始めるか

概念と設計原則だけで終わらせないために、明日から着手できる最初の一歩を3つ挙げておきます。

• AIに読ませる前に、過剰共有を棚卸しする。 SharePointや共有ドライブで「全社共有のまま忘れられた機密文書」「リンクを知っていれば誰でも見られる設定」を洗い出す。AIは権限設計の品質を増幅する装置なので、増幅される前に直すのが最も安上がりです。
• 主要SaaSのAPI権限仕様を確認する。 利用者の委任アクセスに対応しているか、サービスアカウントしか選べないか、レコード単位・フィールド単位の権限をAPI経由で強制できるか。ラストワンマイルの現状を、システムごとに把握しておく。
• エージェントの記憶ポリシーを明文化する。 何を覚えさせてよく、何を覚えさせないか。マスターデータを権威ある情報として記憶しない、という一線を、導入前に文書で決めておく。

この3つはいずれも、特定のAI製品を導入する前にできる仕事です。そしてどれも、AIがなくてもやる価値のあるデータガバナンスの基本でもあります。

この3つを自社で点検する際の観点は、当社が提供しているAIトークンガバナンス診断の設問構成としても整理しています。現状の把握から着手したい場合は、あわせてご覧ください。

結論：AI-readyな社内基盤とは何か

まとめます。

「社内SaaSをすべてRAGに入れる」アプローチは、構築が分かりやすい反面、権限の壁抜け、オーバーシェアリングの増幅、そしてEchoLeakが示したような新しい攻撃面という、構造的な問題を抱えています。RAGが悪いのではありません。RAGは3つある参照経路のうちの1つ——自然言語で書かれた文書を意味で探す経路——であり、そこに現在値の照会や権限管理まで背負わせることが問題なのです。

情報システム部門が設計すべきは、次の構造です。

• 現在の状態は、正データ源へ直接照会する（レイヤー1）
• 横断的な集計・分析は、メタデータと権限まで整備されたデータ基盤で行う（レイヤー2）
• 文書と過去知識は、検索基盤で意味検索する（レイヤー3）
• そのすべてに、記憶の規律・権限の伝播・実行の段階設計・監査可能性という4つの統治を適用する

そして、これが本稿の結論です。

AI-readyな社内基盤とは何か。データを集めることではなく、参照経路を統治することである。

AIエージェントの導入が進むほど、情報システム部門の役割は「AIにデータを渡すこと」から「AIがどのデータへ、どの権限で、どこまでアクセスできるかを設計すること」へ移っていきます。MCPの最大規模の改訂で、認可が企業運用上の主要論点として大きく強化されたことも、NISTがエージェントのIDと認可を標準適用と実証の検討テーマに据えたことも、データセキュリティとID管理を統合する大型買収が動き出したことも、同じ方向を指しています。プロトコル、標準適用をめぐる議論、市場は整いつつある。残っているのは、各社の設計です。

よくある質問

参照した一次情報

記事情報

関連記事

• 2026.07.31｜解説Kimi K3のようなオープンウェイトモデルと、クローズドモデルは何が違うのか

改訂履歴