「MCPはAPIではない」――Dockerが解説するAIエージェント開発のベストプラクティスとは：よくある3つの誤解を解説

Dockerは、MCPについて開発者が誤解しがちな3つのポイントを解説するブログエントリを公開した。MCPの正しい実装パターンとアンチパターンも解説している。

[＠IT]

　Dockerは2025年9月3日（米国時間）に公式ブログで、MCP（Model Context Protocol）に関して開発者が陥りやすい3つの誤解を取り上げた。MCPを使う上で押さえておくべき効果的なデザインパターンや避けるべきアンチパターン、簡易的なチェックリストなども紹介している。

Docker公式ブログ

MCPによくある3つの誤解

　Dockerは「開発者はMCPを『APIの延長線上にあるもの』と捉えてしまう点に問題がある」と指摘している。MCPに関する一般的な誤解として、Dockerが指摘するのは以下の3つだ。

• MCPはAPIの一種である
• MCPツールはAI（人工知能）エージェントである
• MCPは単なるツールである

誤解1：MCPはAPIの一種である

　「MCPの呼び出しは、APIの呼び出しのように扱える」という誤解がある。しかしMCPは、大規模言語モデル（LLM）が外部ツールやデータソースと安全に連携するための通信プロトコルだ。「REST」「gPRC」といったAPIを実装するためのフレームワークではなく、RPC（Remote Procedure Call）に取って代わるものでもない。MCPの内部でAPIやRPCを使うことはあるが、その目的は「AIエージェントがAPIやRPCを安全かつ効果的に使用できるようにすること」にある。

効果的なデザインパターン

・APIはそのままにする

　ビジネスロジックの中核になるAPI（ビジネスAPI）には変更を加えない。その代わり、そのAPIをAIエージェントが使いやすい形にラップする。具体的には、APIをMCPツールとして機能させるための事前条件や成功条件などを定義ファイルにまとめ、それをAIエージェントに与える。

・処理の最終段階を安全に設計する

　AIエージェントが使うMCPツールの動作は、可能な限り決定論的（同じ入力に対して同じ結果を返す）で、かつ再試行できるものにする。同時に、AIモデルの出力結果は必ず検証し、異常時は安全に停止（フェイルクローズ）させる。

避けるべきアンチパターン

• MCPツールを、「複雑な状態変更が考慮されていない、安全策のないビジネスAPI」として扱う
• AIモデルの出力が常に正しいデータ形式であることを期待し、検証や再試行をしない

チェックリスト

• MCPツールの前提条件と事後条件を定義する
• MCPツールが返す結果は、AIエージェントが自動で評価可能な形式にする
• AIエージェントが立てた計画、使用したMCPツール、実行結果をログに記録し、後から再現と監査ができるようにする

誤解2：MCPツールはAIエージェントである

　「MCPツールは、それ自体が自律的に思考、行動するAIエージェントである」という誤解がある。だが、AIエージェントは「アクションの計画、再計画、評価を担う」ことが役割であり、MCPツールには「AIエージェントから指示されたアクションを実行する」という別の役割がある。

効果的なデザインパターン

・MCPツールの制御を外部に委ねる

　次に実行すべきMCPツールとその理由の決定はAIエージェントに任せるようにする。

・AIエージェントが客観的に評価できる成功指標を用意する

　AIエージェントがMCPツールの実行結果を評価できるように、プログラムで測定可能な指標をMCPツールから返すようにする。その結果に基づいて、AIエージェントは「処理を停止すべきか」「再試行すべきか」「人間判断を仰ぐべきか」を自律的に判断する。

・MCPを介してAIエージェントから人間に助けを求められるようにする

　AIエージェントの判断の信頼度が低い場合や、ユーザーの指示があいまいな場合は、AIエージェントに自己判断で処理を進めさせないことが重要だ。その代わりに、AIエージェントがMCPを使って人間に質問を投げ掛け、あいまいさを解消できるようにする。

避けるべきアンチパターン

• 単一のMCPツールに対する1回の呼び出しに、AIエージェントの全ての行動や計画を含める
• AIエージェントのパフォーマンスを、MCPツールの応答速度のみで測定する

チェックリスト

• AIエージェントの行動方針、制約、停止条件を明確に定義する
• 失敗後すぐに再試行せず、少しずつ間隔を開けながら試行する「バックオフ」の仕組みや、MCPツールごとのエラー処理を実装する
• AIエージェントの思考ループが1周するごとに、AIエージェントが立てた計画や呼び出したツール、得られた結果などの詳細な実行履歴を記録する

誤解3：MCPは単なるツールである

　「MCPは、AIエージェントが使うツールの仕様をJSON形式で定義したものと等しい」という誤解がある。正しくは、MCPはツールに加えて、AIエージェントがコンテキストを理解し、適切に振る舞うため、以下の要素を扱う。

・リソース

　AIエージェントが作業途中の情報を読み取り、書き込み、参照できる、構造化されたデータ。これによってAIエージェントは、複数のステップにまたがる作業を実行できるようになる。

・プロンプト

　AIエージェントに特定のタスクを依頼するための、再利用可能な指示文のセット。バージョン管理を有効にしておくことで、以前の指示に戻したり、指示の違いによる結果を比較したりといった品質管理が容易になる。

・エリシテーション（引き出し）

　AIエージェントが自力で判断できない状態に陥った場合、あいまいさの解決のために人間に助けを求める仕組み。AIエージェントの勝手な判断を防ぐ。

効果的なデザインパターン

・「リソースアダプター」を構築する

　社内のナレッジベースやファイル、チケットを、AIエージェントが読み書きできる「MCPリソース」として扱えるように、データを変換し、データソースとMCPリソースを接続できる仕組み（リソースアダプター）を実装する。この際、MCPリソースのデータへのアクセス権限やデータ保持期間も管理する。

・プロンプトを管理する「プロンプトレジストリ」を構築する

　プロンプトレジストリでプロンプトをコードのように扱い、バージョン管理、テスト、ロールバックを実施する。

・人間の確認を挟む「チェックポイント」を設ける

　AIエージェントの思考ループの中で、人間のユーザーに確認を求めるようにし、ユーザーから回答を得た後にループをどう再開するかを定義しておく。

避けるべきアンチパターン

• AIエージェントを、MCPリソースやプロンプトを使わずに、既存サービスを操作するだけのアシスタントとして使用する
• 長いプロンプトをアプリケーション内にハードコーディングする

チェックリスト

• AIエージェントが読み取れるリソースと書き込み可能なリソースを、少なくとも1つずつMCPリソースとして用意する
• プロンプトに固有のIDを割り振ったり、バージョンを管理したりして、体系的に管理する
• AIエージェントの判断の信頼度が低い場合、ユーザーにどのような質問を投げ掛け、回答を得て処理を続けるかという一連のフローを定義しておく

MCPの役割

　DockerはMCPを、「AIエージェントを信頼できるものにするアーキテクチャ上の接合部」と表現している。具体的には、「非決定論的レイヤー」と「決定論的レイヤー」という異なるレイヤーを接続する役割を果たしている。

非決定論的レイヤー

　AIエージェントによる計画、ツール選択、再計画、評価といった、常に結果が一定ではないレイヤー

決定論的レイヤー

　MCPツールによるタスク実行、AIエージェントの出力結果の検証、べき等性（何度実行しても結果が変わらないこと）の確保、意図しない副作用の制御といった、常に一定の結果が求められるレイヤー

　これらの接合部としてMCPは機能する。「MCPが提供するツール定義、リソース、プロンプト、エリシテーションといった要素や機能が2つのレイヤーをつなぎ、やりとりをログとして記録する」とDockerは説明している。

このニュースのポイント

Q: Dockerが指摘したMCPに関する3つの誤解は何か？

A: 「MCPはAPIの一種」「MCPツールはAIエージェント」「MCPは単なるツール」の3つ。

Q: Dockerが提唱する効果的なデザインパターンの共通点は？

A: 「APIをそのまま活用しつつMCP用にラップする」「AIモデル出力の検証、再試行を徹底する」「プロンプトやリソースを体系的に管理する」「人間のチェックポイントを適切に導入する」など、安全性と再現性を重視している。

Q: MCPが果たす役割は何か？

A: 非決定論的レイヤー（AIエージェントの計画、評価）と決定論的レイヤー（ツール実行や検証）をつなぐ「アーキテクチャ上の接合部」として機能し、ログを通じて信頼性を確保する。