pillar · MCP

MCP完全ガイド|AIと外部ツールをつなぐ仕組み

MCPのHost・Client・Server、Tools・Resources・Prompts、ツール発見、OAuth、Local/Remoteの違いをOGINAUの実装経験も交えて解説。

公開: 2026年10月10日 · OGINAU Editorial

MCP(Model Context Protocol)は、AIアプリケーションが外部のツールやデータを共通の方法で利用するためのオープンなプロトコルです。

まず結論

MCP(Model Context Protocol)は、ChatGPTなどのAIアプリケーションが、外部のツールやデータを共通の方法で利用するためのオープンなプロトコルです。

AIは文章を理解し、必要な作業を判断できます。しかし、外部のファイルや業務システムへアクセスするには、それらと接続する仕組みが必要です。MCPはこの接続方法を標準化します。

たとえば、AIが外部サービスに保存された情報を検索する、許可されたファイルを読み取る、データベースから必要な情報を取得する、用意されたツールを呼び出すといった処理に利用できます。

AIが何をするか判断し、接続先のツールが許可された処理を実行する。MCPは、その間のやり取りを共通化する技術です。

基本的な定義は「MCPとは?」で解説しています。本記事では構成要素、処理の流れ、認証、実装時の注意点まで掘り下げます。

全体像

MCPの基本構成には、Host・Client・Serverという3つの役割があります。

構成要素役割
Host利用者が操作するAIアプリケーション
ClientHostとMCP Serverの通信を担当する
ServerAIに利用可能な機能や情報を提供する

利用者が「保存されている資料を検索して」と依頼すると、AIアプリケーションは必要なツールを選び、Client経由でServerへ検索を要求できます。結果はAIへ返され、回答に利用されます。

MCP ServerはAIモデルを動かすサーバーという意味ではありません。 外部の機能や情報を提供する役割を指します。

主要トピック

1. Tools・Resources・Promptsの違い

種類主な役割使用例
Tools処理を実行するファイル検索、データ取得、更新処理
Resources情報を提供する文書、設定情報、参照データ
Prompts定型的な指示を提供する分析テンプレート、作業手順

Tools はMCPの代表的な機能です。たとえば架空の search_documents というToolなら、「指定した検索語に一致する文書を探す」と説明し、入力に検索キーワード、出力に検索結果を定義します。AIは利用者の依頼に応じてToolを呼び出せますが、権限不足や検索結果なしの場合には適切な応答が必要です。

Resources は文書やデータなど参照用の情報を提供します。Toolsが処理の実行に重点を置くのに対し、Resourcesは情報の参照に重点があります。

Prompts は、あらかじめ用意された指示や定型的な作業のひな型を提供します。利用できる機能はHostとServerの対応状況によって異なります。

2. AIは外部ツールをどのように発見する?

MCPには、接続先が提供するツールの情報を取得する仕組みがあります。代表的な操作は tools/list で、Toolの名前、説明、入力形式などを取得します。

たとえば文書検索Toolの名前が search_documents、入力が検索キーワード、結果が文書一覧として定義されていれば、AIはそれを参考に呼び出す機能を選べます。実行には tools/call などを利用します。

2026年7月版で変わった点

MCPの2026年7月28日版では、セッションへの依存を減らした接続方式や、機能発見の方法などが更新されました。

  • 従来の初期化ハンドシェイクとプロトコルレベルのセッションを廃止

  • 必要に応じて接続先の機能を確認できる server/discover を導入

  • tools/list などの一覧結果にキャッシュ用情報を追加

  • HTTPヘッダーによるメソッド・ツール情報の伝達を規定

  • 認可に関する安全性を強化

これは tools/list がなくなったという意味ではありません。接続開始時の前提や機能発見の方法が変化しているため、実装では対応仕様版の確認が重要です。新しい仕様が公開されても、すべてのHostやServer、SDKが同時に対応するとは限りません。

3. Local MCPとRemote MCPの違い

Local MCP は、同じPCなどローカル環境で動作するMCP Serverとの接続です。開発補助やローカルツールを使う用途などがあります。

Remote MCP は、ネットワーク経由でMCP Serverへ接続します。クラウド上のAIアプリケーションから外部サービスを使う用途などがあり、認証や通信の保護が重要です。

比較項目Local MCPRemote MCP
接続先ローカル環境ネットワーク上のサービス
利用例開発支援、ローカルツールクラウドサービス連携
主な確認事項ローカル権限、プロセス管理認証、通信保護、アクセス制御

どちらが優れているかではなく、AIをどこで使い、どの環境のデータを利用したいかで選択します。

4. MCPとOAuthはどう関係する?

Remote MCPでは認証と認可が重要です。接続先は、誰がアクセスしようとしているのか、その人にどの操作が許可されているのかを判断しなければなりません。

OAuthは、外部サービスとの認可を扱う標準的な技術です。確認すべき代表的な要素には、発行元(issuer)、対象サービス(audience/resource)、有効期限(expiration)、許可範囲(scope)があります。

ログイン成功と、すべてのToolへの操作許可は別です。 認可されていないデータや操作を、AIの判断だけで実行できるようにしてはいけません。

2026年7月28日版のMCPでは、認可関連の安全性強化が進み、Dynamic Client Registration(DCR)は非推奨となり、Client ID Metadata Documents(CIMD)への移行方針が示されました。既存システムがただちに利用できなくなるという意味ではありません。新規実装や更新では公式仕様と接続先の対応状況を確認します。

5. MCPの実装で確認すべきこと

  • Toolの入力と結果を明確にする。 何を実行するか、どのようなパラメータを受け取るかを定義します。

  • 必要な操作だけを公開する。 検索だけの用途に書き込みや削除を追加しません。

  • 失敗条件を想定する。 権限不足、通信エラー、対象データなしなどを適切に扱います。

  • AIの判断だけに安全性を依存させない。 実行側でも権限を確認します。

MCPは接続方法を標準化しますが、業務上のアクセス制御まで自動的に完成させるわけではありません。

実装・検証から分かったこと

OGINAUでは、OGINAU Remote と OGINAU Browser の開発で、AIと外部環境をつなぐ技術としてMCPを利用しています。

Toolの定義と、実際の処理完了は違う

OGINAU Remoteの初期開発では、AIからの操作要求をWindows PCへ届け、ファイル操作の結果を返す実機接続を検証しました。初期E2E試験では5項目がPASSしています。

これはToolの定義ができたことだけではなく、外部環境との接続から処理結果の取得までを確かめた記録です。

正常に動くことだけでは安全性を判断できない

実装検証では、ファイル操作の成功だけでなく、許可された範囲が守られることや、不適切な更新を拒否できることも重要な確認項目になりました。

また、接続が成立していても、環境や接続先の状態によって処理が完了しないことがあります。正常時だけでなく失敗時も含めた検証が必要です。

ここで紹介するのは実装・検証で得られた知見です。個別の内部構成やアクセス制御ロジックは公開していません。

根拠・一次情報

公開されている一次情報

OGINAUの一次情報

OGINAU Remoteの実機接続試験と関連する開発・検証記録を基に、外部Tool接続に関する知見を整理しています。個別の認証情報や内部構成は公開していません。

技術仕様・実装記録の確認基準日:2026年10月10日。

次に読む記事

まとめ

MCPはAIアプリケーションと外部のツール・データをつなぐための共通プロトコルです。 Host・Client・Server、Tools・Resources・Prompts、ツールの発見と呼び出し、認証・認可を理解することで、AIが外部環境を利用する仕組みが見えてきます。

実際のサービスでは、適切な権限管理、失敗時の処理、接続先の管理が必要です。MCPは共通基盤であり、その上で何を安全に実現するかが各サービスの品質を分けます。

OGINAUでは、MCPを利用した実際の開発・検証を通じ、接続技術の実用化に取り組んでいます。