MCPとは？Model Context ProtocolはAI Agent、Tools、API、JSON Schemaをどのように接続するのか？

MCP Model Context Protocolを導入するなら、MCP Serverをモデルへ直接つなぐのではなく、Host・Client・Serverの責任を分けて実装してください。モデルがToolを選び、ClientまたはHostが呼び出しを管理し、ServerがAPIを検証・実行して構造化された結果を返す構成が基本です。MCPはAI AgentとTools、Resources、Promptsを接続するオープンなプロトコルであり、モデルでもFunction Callingの代替でもありません。

このページは、MCP Serverを開発して社内APIや業務ツールを公開したい開発者、複数のAI AgentやClientを接続したいプラットフォーム担当者、認証・監査・権限を設計する運用とセキュリティ担当者向けです。単にサンプルを動かすのではなく、接続から停止までを運用可能な単位で確認したい場合に適しています。

MCPの責任分担

MCPの最初の誤解は、「大規模言語モデルがServerへ直接接続してAPIを実行する」という考え方です。実際にはHostがAIアプリケーション全体のコンテナとして動作し、複数のClientを生成・管理します。各Clientは原則として特定のServerとの接続を担当し、Server同士を勝手に横断しません。

• Host：モデルとの会話、ユーザー確認、Clientのライフサイクル、接続ポリシーを管理します。
• MCP Client：特定のMCP Serverとセッションを確立し、能力交渉、メッセージ転送、通知処理を担当します。
• MCP Server：Tools、Resources、Promptsを公開し、必要に応じて社内API、データベース、ファイル、開発環境へ接続します。
• 実際のAPI：MCPそのものではなく、Serverが内部から呼び出す業務システムです。

この分離を省くと、少なくとも3つの問題が起きます。第一に、モデルへ過剰な認証情報を渡しやすくなります。第二に、どのユーザーがどの操作を許可したかを追跡しにくくなります。第三に、ClientごとのMCP対応範囲の違いを吸収できず、あるAIアプリで動いた構成が別のClientでは動かない可能性があります。

注意
MCP Serverは、必ずしもMacへ配置する必要はありません。データベース連携や一般的な業務APIであれば、既存のLinux系サーバーやコンテナ環境のほうが管理しやすい場合があります。macOS固有の自動化、Xcode、署名環境が必要なときだけ、Mac常駐を候補にしてください。

接続方式の選択

接続ライフサイクルは、次の順番で進みます。

Host
  ↓ Clientを生成
MCP Client
  ↓ initialize / 能力交渉
MCP Server
  ↓ tools/list
Tool定義・JSON Schema
  ↓ モデルがツールと引数を選択
MCP Client → tools/call → MCP Server
                                  ↓
                         社内API・DB・開発環境
                                  ↓
MCP Client ← Tool Result ← MCP Server
  ↓
Hostが結果をモデルへ渡し、必要なら次の処理へ進む

初回接続ではClientがinitializeを送り、対応するプロトコルバージョン、Client側の能力、実装情報を提示します。Serverは利用するバージョン、Server側の能力、実装情報を返し、Clientは初期化完了通知を送って通常処理へ移行します。ここで能力が一致しない機能を、Clientが対応していると仮定してはいけません。

stdioではClientがMCP Serverをサブプロセスとして起動し、標準入力と標準出力でJSON-RPCメッセージを交換します。一方、Streamable HTTPではServerが独立したプロセスとして動き、HTTPの単一エンドポイントでPOSTとGETを扱います。HTTP化すると共有しやすくなりますが、認証、TLS、Origin、監視を追加しなければなりません。

ツール発見とJSON Schema

接続が終わると、Clientはtools/listで利用可能なTool定義を読み取ります。Toolには、機械的な識別子であるname、人間とモデル向けのdescription、入力を定義するinputSchema、必要に応じて出力を定義するoutputSchemaがあります。MCPがJSON Schemaを使う理由は、自由文だけでは曖昧な引数を型と必須項目として検証できるからです。

たとえば社内のデプロイAPIを公開する場合、次のように役割を分けます。

• deploy_preview：プレビュー環境だけへ反映する読み取り寄りの操作
• deploy_production：本番反映を行うため、明示的な確認が必要な操作
• get_deploy_status：デプロイ状況を取得する操作
• cancel_deploy：実行中の処理を停止する操作

Schemaには環境名、対象ブランチ、変更理由などを定義します。しかしSchemaだけで安全になるわけではありません。deploy_productionのような名前、具体的なdescription、破壊的操作であることを示す注釈、Host側の確認画面が揃って初めて、モデルの選択と人間の承認を分けて管理できます。

MCPのTool定義では、入力だけでなく任意の出力Schemaも利用できます。出力をstructuredContentとして返す設計にすると、ClientやHostが結果を再解釈しやすくなります。ただし、対応するSchema機能や注釈はClientごとに差があるため、必ず対象Clientで実際の発見結果と表示を確認してください。

呼び出しと結果処理

モデルが「本番デプロイを実行する」と判断しても、モデル自身がAPIリクエストを送るわけではありません。典型的な流れは、モデルがTool名と引数を提案し、HostまたはClientがユーザー確認と権限判定を行い、MCP Serverが入力検証後に実際のAPIを呼び出す形です。

実装時は、次の5段階で処理してください。

1. Tool選択を受け取る：ClientがモデルからTool名と引数を取得します。
2. Schema検証を行う：必須項目、型、列挙値、文字列長、対象範囲を確認します。
3. 権限と確認を判定する：読み取り、変更、破壊的操作で承認条件を分けます。
4. 下流APIを実行する：タイムアウト、リトライ、レート制限、監査IDを付けて呼び出します。
5. 結果を分類して返す：成功、入力エラー、業務エラー、プロトコルエラーを分離します。

MCPでは、リクエスト自体が壊れている場合のプロトコルエラーと、API実行後に発生した入力エラーや業務エラーを区別します。後者はTool ResultにisError: trueを付けて返すことで、モデルが引数を修正して再試行しやすくなります。すべてを同じエラーとして返すと、モデルが修正不能な通信障害に対しても無限に再試行する危険があります。

長時間処理では、通常の同期呼び出しだけに頼らないでください。対応する能力が宣言され、Tool側も許可している場合は、タスクとして受け付けて状態を確認し、完了後に結果を取得する構成を検討できます。ただし、タスク機能はClientとServerの双方が対応している必要があり、対象Clientでの動作確認が不可欠です。

経験則
1回のTool呼び出しに「検索、更新、通知、削除」まで詰め込むと、失敗地点と再実行条件が不明になります。副作用の単位を小さく分け、冪等性のある取得系Toolと、確認が必要な変更系Toolを分離してください。

運用前の分岐条件

次の条件で、最初の配置を決めると判断がぶれません。

• 同一Mac上のファイルや開発ツールだけを操作するなら、stdioを選び、localhost以外へ公開しないでください。
• 複数人が同じ社内APIを利用するなら、Streamable HTTPへ移し、認証、監査ログ、レート制限を用意してください。
• 本番変更や削除を実行するなら、Host側で対象、引数、実行者を表示し、明示確認を必須にしてください。
• APIキーをClientやモデルへ渡したくないなら、資格情報はServerまたは管理された実行環境だけに保存してください。
• 処理が長時間に及ぶなら、タイムアウトとキャンセルを先に設計し、必要な場合だけタスク対応を追加してください。
• Xcode、署名、AppleScriptなどmacOS固有の資源が必要なら、Mac常駐または遠隔Macを評価してください。それ以外は汎用サーバーを優先します。

HTTPベースのMCP Serverでは、認証を後付けにしないことが重要です。保護されたServerをOAuthベースのリソースとして扱い、Clientが認証サーバーを発見できる仕組みを用意します。また、アクセストークンは対象Server向けであることを検証し、下流APIへそのまま転送してはいけません。

資格情報をSchema、プロンプト、公開設定ファイルへ書かないでください。特に、MCP Serverが受け取ったトークンを別のAPIへ透過転送する設計は、権限の取り違えや「混乱した代理人」問題につながります。Serverが下流APIを呼ぶ場合は、そのAPI専用の資格情報をServer側で取得し、用途ごとにスコープを制限してください。

FAQ：接続前に確認すること

MCPとAI Agentの関係

MCPはAI Agentそのものではありません。Agentが複数のToolを選び、結果を受けて次の処理を考えるための接続面を標準化します。実際の推論、ループ制御、ユーザー確認、権限判断はHostやClientの実装に残ります。

APIをMCP Serverへ変換する方法

既存APIの各操作を、入力Schemaを持つToolとして薄く包むのが基本です。Serverはモデル向けの説明、引数検証、API認証、エラー分類を担当します。API仕様をそのまま公開するのではなく、危険な操作を分割し、Agentが誤って実行しても影響を限定できる単位にしてください。

JSON Schemaが必要な理由

JSON Schemaは、モデルへ形式を教えるだけでなく、ClientとServerの境界で入力を検証する契約になります。必須項目、型、列挙値を明示すれば、誤った引数を下流APIへ送る前に止められます。一方、業務上の制約はSchemaだけで表現しきれないため、Server側の認可と検証を省略してはいけません。

誰がToolを実行するのか

モデルはToolの候補と引数を選びますが、実際の実行は通常、Hostが管理するClient経由でMCP Serverへ渡されます。ServerがAPI、データベース、ファイル、開発環境を操作し、結果をClientへ返します。したがって、実行ログと資格情報の管理場所はモデルではなくHostとServerを中心に設計します。

ローカルServerを遠隔化する際の変更点

stdioの子プロセスを、HTTPで待ち受ける独立サービスへ分離します。次に、TLS、認証、Origin検証、監視、タイムアウト、デプロイ手順を追加し、Clientの接続先を変更します。ローカルのファイルパスや環境変数をそのまま移すと、権限漏れやデータ消失が起きるため、秘密情報と永続データを先に棚卸ししてください。

常駐環境の選び方

個人開発では、ローカルMCP Serverの起動が最も簡単です。チーム共有では、遠隔Serverに移すことでClientの追加や更新を一元化できますが、認証障害、ネットワーク遅延、ログ保管、バージョン互換性を運用対象に含める必要があります。

混合構成では、社内APIやデータベース連携を共有Serverへ置き、ローカルファイルやXcode操作だけをMac上のstdio Serverへ残す方法が現実的です。これなら、機密データを不用意に外部へ出さず、macOS固有の処理だけを必要な端末またはMac環境へ限定できます。

MCP接続を本番運用へ進める前に、公式仕様の対象バージョンと利用Clientのバージョンを記録し、initialize、tools/list、tools/call、入力エラー、タイムアウト、切断後の再接続を確認してください。新しい仕様や伝送方式が公開された際は、同じ検証項目を再実行する運用にすると、特定Clientの独自実装をMCPの標準機能と誤認しにくくなります。

仕様の確認には、MCPのアーキテクチャ定義、ライフサイクル仕様、伝送方式の仕様、Tool定義とエラー処理、認証仕様を参照してください。

現在のローカル構成は、端末が停止するとToolも止まり、利用者ごとに環境変数や依存関係がずれ、Xcodeや署名処理ではMacの電源状態とログイン状態にも左右されます。汎用APIだけなら専用サーバーのほうが適しますが、Apple自動化や署名環境を継続的に使うチームでは、Macを常駐実行環境として分離したほうが、端末依存、手動起動、権限のばらつきを抑えやすくなります。

必要な場合は、まずKvmjetのインフラ構成で運用条件を確認し、要件が固まらない段階ではサポート窓口からMac常駐環境の適合性を相談してください。