2026/9/17更新: 2026/9/28約11分で読めます

「MCP対応なら安全」ではない。MCP・API・RAG・AIエージェントの関係

「出張の宿泊費の上限は？」と調べる同じ場面を、直接APIとMCPの図で比べます。資料を探す役割、手順を選ぶ役割、道具につなぐ役割が分かり、MCPが必要な条件と接続後の権限確認を考えられます。

影山湧亮 / NeoLogic株式会社代表取締役。元警視庁。現場業務の整理と生成AI活用・Webシステム開発を一貫して担当。

MCPは、AIアプリと外部の情報・機能の接続方法をそろえる規格です。必要な機能、利用者の閲覧権限、資料の更新、実行結果の確認は、使う製品で対応できるかを確かめ、不足する部分を設定・開発します。

「社内の規程検索をAIにつなぎたい。MCP対応の製品なら、そのまま安全に使えるのだろうか」。導入を検討するときは、MCPという表示だけでなく、どのアプリが、誰の権限で、何を呼び出すのかを見る必要があります。公式仕様にも安全上の原則がありますが、その徹底には実装側の対応が必要です（出典：MCP仕様「Overview / Security and Trust & Safety」）。

同じ社内資料検索を「直接APIでつなぐ場合」と「MCP経由でつなぐ場合」で比べ、接続を共通化する価値が自社の用途にあるかを考えます。

「宿泊費の上限は？」を、二つの経路で調べる

APIは、ソフトウェアから機能やデータを利用するための窓口という広い概念です。既存の検索APIをAIアプリのコードから直接呼ぶ方法と、その手前にMCPサーバーを置く方法を比較します。MCPサーバーは既存APIを内部で呼べますし、データベースやファイルを直接扱う実装も可能です。MCPを採用しても、既存APIを引き続き利用できます。MCP仕様「Tools」

同じ社内資料検索を、二つの接続方法で見る

「サンプル社」で、従業員が「出張の宿泊費の上限は？」と尋ねる場面です（想定例）。閲覧できる規程を検索し、根拠付きで回答する構成を考えます。両案で資料、検索API、利用者権限、モデルと生成条件をそろえ、接続経路の違いに注目します。性能・費用・製品間の互換性は未測定です。

直接API案とMCP案で同じ社内検索APIを利用。MCP案はホスト内のクライアントからサーバーの検索Toolを呼び、結果をAIアプリへ返す。両案でRAGが可能。追加検索は任意、業務更新は対象外の拡張例。

図1　同じ社内資料検索を、直接API接続とMCP経由で比較する説明例。実線は要求、破線は返却を示します。業務更新APIへの分岐は拡張例で、今回の検索には使いません。MCP参照仕様：2026-07-28／確認日：2026-09-15。

直接API案では、アプリ側の個別連携コードが検索条件と返り値を扱います。MCP案では、ホスト内のクライアントが検索Toolを呼び、サーバー側が既存APIとの対応付けを担います。どちらも、アプリやサーバーのコードが権限と入力を確認してから実行する設計にします。

図に出てくるホスト・クライアント・サーバー

MCPはModel Context Protocolの略です。モデルを利用するアプリと、外部のデータや機能をやり取りするための約束を定めます。接続の説明では、次の三つを分けると、開発範囲が見えてきます。

ホストは、チャット画面などを持つAIアプリです。モデルとの連携、利用者の同意、外部に渡す情報の管理を担います。クライアントはホストの中の接続部で、各クライアントが一つのMCPサーバーと通信します。サーバーは、使える情報や機能をMCPで公開する側です。ホストは接続部を含むアプリ全体を指します。サーバーはローカルでもクラウドでも実行できます（出典：MCP仕様「Architecture」）。

サーバーが公開する代表的なものには、検索や業務操作などのTools、ファイル等の情報を渡すResources、定型の指示を提供するPromptsがあります。例えば「規程を検索する機能」と「参照する規程本文」は役割が異なります。どの機能を提供・利用できるかは製品ごとに確認します（出典：MCP仕様「Overview / Security and Trust & Safety」、MCP仕様「Tools」、MCP仕様「Resources」）。

MCPで共通化されるのは、利用できる機能の伝え方や呼び出し、結果の返し方などです。「出張申請をどう承認するか」といった業務の意味や、誰に閲覧・更新を許すかは、利用するシステム側で決めます。

RAGは「根拠を使った生成」、エージェントは「進め方の選択」

RAG（検索拡張生成）は、検索で得た情報を回答生成に利用する考え方です。図のどちらでも、戻った規程本文をモデルへの文脈に含めれば、この構成を取れます。MCPは情報取得のための接続手段になり得ます。検索品質の改善や取得情報の回答への組込みは、検索機能とAIアプリが担います（出典：Lewisほか「Retrieval-Augmented Generation」）。

一方、Anthropicの整理を参考に、AIエージェントを、状況に応じてモデルが次の処理やツール利用を選ぶ仕組みとして扱います。検索後に回答する固定手順と、足りない情報を見て追加検索を選ぶ方式は区別します。RAGはエージェントの一部にもなれます。固定手順で十分な用途もあり、エージェントの接続手段として直接APIを選ぶこともできます（出典：Anthropic「Building effective agents」）。

別のエージェントへ仕事を渡す場合のA2A

A2A（Agent2Agent）は、独立したエージェント同士の連携を扱います。外部ツールへの接続を扱うMCPとは主眼が違い、併用できます。社内規程を一つのアプリで検索する用途なら、別エージェントへの委任を加える必要性から判断します。規格・モデル・検索方式を一列の候補として順位付けしません（出典：A2A公式「A2A and MCP」）。

接続できても、規程の正しさと権限は確かめる

業務機能と資料を、使える状態にする

サンプル社の検索Toolには、質問から作った検索語を受け取り、本文抜粋・文書ID・改訂日・参照リンクを返す役割を持たせます。MCPサーバーを用意しても、検索先に必要な資料がなければ答えは得られません。最新版を見分ける項目、更新の反映、対象外資料の除外を整備します。これらは説明例の設計条件です。

また、既存システムに必要なAPIも、許可された実行手段もなければ、MCP対応だけでその業務操作はできません。APIや検索機能を追加する、承認された別の接続方法を用意する、今回は接続しない、といった判断が先になります。

接続の認可と、業務上の権限を分ける

さらに、MCPサーバーへの接続を許可した後も、利用者が閲覧できる規程の範囲を確認します。検索結果をモデルへ渡す前に、サーバー側で文書単位の権限を適用する設計が必要です。モデルが出した利用者IDだけを信用したり、全資料を読める共通アカウントで本人の権限確認を省いたりしないようにします。

検索結果と引用リンクの両方で、社員本人の閲覧範囲を保てるかを試します（出典：MCP仕様「Tools」、MCP仕様「Authorization Security Considerations」）。

実装時に確認する接続方式と認可

下流APIにも認可が必要な構成では、MCP区間と下流API区間を分けて確認します。公式の認可セキュリティ文書は、MCPクライアントから受け取ったトークンを下流APIにそのまま流すことを禁止し、下流側の認可サーバーが発行した別のトークンを使う構成を示しています。

MCPにはHTTP接続向けの認可仕様があります。ローカルのstdio接続では、環境から認証情報を取得する方法などを用います。接続方式に応じた認可方法と実装を確認します（出典：MCP仕様「Authorization」、MCP仕様「Transports」）。

失敗と実行結果を確かめる

検索では、資料がない場合、権限が足りない場合、APIが落ちている場合を区別します。根拠を取れないのに、取得できたかのように回答させない設計にします。MCPにはエラーを返す仕組みがありますが、業務として何を成功とするかは別に決めます。

申請更新などへ広げる場合は、通信が途切れた後の再実行で二重登録しないことや、実際の登録結果の確認も必要です。MCPの要求番号を付けることだけで、業務上の二重実行防止を済ませたことにはしません（出典：MCP仕様「Tools」、MCP仕様「Key Changes」）。

検索語と本文が、どこへ渡るか

まず、サーバーの提供者・配布元・保守担当を確かめ、必要な権限と情報の行き先を書き出します。検索語がMCPサーバーへ渡る経路だけでなく、取得した本文がモデル提供先へ送られる経路、ログに残る項目、保持条件も確認対象です。「社内にサーバーを置く」ことだけでは、外部送信がないとは判断できません（出典：MCP仕様「Overview / Security and Trust & Safety」、MCP仕様「Authorization Security Considerations」）。

規程本文やツール出力に書かれた文章を、アプリが従うべき命令と混同する危険もあります。OWASPは、外部内容の分離、最小権限、重要操作の人による承認などを挙げています。プロンプトの注意書きだけに頼らず、送信先や操作をコード側で制限します。対策を組み合わせて影響を減らし、接続先や扱う情報に応じて検証します（出典：OWASP「LLM01:2025 Prompt Injection」）。連携先の文章でAIが誤作動するのを防ぐ具体的な対策は、プロンプトインジェクションと連携時の対策で扱っています。

接続前には、次の三群を確かめます。実装担当者が記入する製品版・接続方式・再試行・停止手順などの詳細は、接続前チェック表（Excel）の見本と空欄版を使えます。

表1　サンプル社で接続判断を変える三つの確認

確認すること	この検索例で求める条件	足りない場合の次の一手
既存機能で必要な情報を取れるか	出張規程の検索APIが本文抜粋・文書ID・改訂日・参照リンクを返し、元資料の更新を反映できる	必要なAPIや検索資料を先に整える。更新・送信は今回の検索に加えない
社員本人の閲覧権限を保てるか	接続の認可とは別に、検索結果と引用先の両方で本人の文書権限を適用する	提供元と管理者が権限の適用箇所を確認し、閲覧できる人・できない人で試す
検索語と本文を、許可した先だけへ渡せるか	MCPサーバー、モデル提供先、経由サービス、ログの送信先と保持条件が分かる	データ取扱文書と実環境の設定を確認する。送信先を限定できなければ接続を見送る

製品間の対応版・認可方式、検索と権限の動作、転送・保持条件は、この説明例では未検証です。提供者の仕様書、データ取扱文書、管理者の設定と試験結果をチェック表へ記録してから接続を決めます。

旧仕様から実装を移す場合の確認

2026年9月15日時点の参照版は2026-07-28です。旧版の2025-11-25からは、初期化や接続単位のセッションの扱いが変わっています。古い解説の手順を前提にせず、ホストとサーバーの対応版・機能・接続方式を突き合わせます。規格の公開と、利用する製品の対応完了は別です（出典：MCP仕様「Key Changes」、MCP仕様「Transports」）。

一つのアプリで使うか、複数から再利用するか

次の選択は、説明例の条件から考えた判断例です。サンプル社が「アプリ一つ、検索API一つ、検索後に回答する固定手順」で始めるなら、直接API接続を候補にします。すでに使える連携をMCPに置き換えるためだけに、管理対象を増やす必要はありません。接続方法より前に、既存のAIをそのまま使うか、設定で足りるかを決めたい場合は、既存AIの利用・設定・API開発の違いから読むと判断の順番が分かります。

一方、同じ検索機能を複数の対応AIアプリから使いたい、機能の説明や呼び出し方を共通化したい、という要件があればMCPを候補にします。ただし、再利用先が必要な機能と認可方式に対応し、サーバー側の保守を担えることが条件です。追加される運用と、減らせる個別連携を比較します。

必要なデータを取得できない、本人の権限を保てない、転送先や停止方法が不明、という状態なら、直接APIでもMCPでも本番接続は見送ります。まず「取得する情報」「許可する操作」「失敗したときの戻し方」を決め、そのうえで接続方法と自律性を選びます。接続の共通化による価値と、業務を任せるための確認を合わせて判断します。

まず接続先を一つ選び、取得する情報と許す操作を表1に書き込んでください。更新処理も加える場合は、API連携の待ち時間・再送・二重実行への備えも確認します。

道具につないだ後の手順をAIに選ばせるかは、決まった流れで足りる部分を見つけて判断します（AIエージェント・RPA・自動処理の使い分け）。

社内規程の検索を実際の業務へ取り入れる場合は、社内文書検索の開発・導入相談で、対象資料・閲覧権限・回答の確認方法から相談できます。