AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】

AIエージェントに外部ツールを操作させる接続方式は、MCP（Model Context Protocol）で標準化が進んでいます。この記事は、MCPでエージェントに道具を持たせるまでの実装工程を通しで示す実装者向けガイドです。tool定義（名前・説明文・入力スキーマ）の設計、公式SDKやFastMCPによるサーバー実装、stdioとStreamable HTTPの接続設定、そして本番投入の壁になる権限・認可・監査の統制設計まで、工程順に解説します。あわせて、MCP接続を採用する条件と、function callingの直接実装で足りる場面の線引きも条件付きで言い切ります。

まとめ：MCP接続の実装はtool定義の精度と権限・認可の統制設計で成否が決まる

MCPは2024年11月にAnthropicが公開したオープン規格で、AIアプリケーションと外部ツールの接続をJSON-RPC 2.0の上で標準化します（仕様公開版は2025-11-25リビジョン・2026年7月時点）。実装の工程は4つに分解できます。第一にtool定義で、名前・説明文・入力スキーマの書き方がLLMの呼び出し精度をそのまま決めます。第二にサーバー実装で、公式SDKかFastMCPを使えばツール数本の規模なら小さく書ける範囲です。第三に接続で、ローカル常駐ならstdio、社内共有やリモート提供ならStreamable HTTPを選びます。第四が権限・認可で、OAuth 2.1ベースの認可フロー、破壊的操作の前に人の承認を挟む関門、呼び出し履歴の監査ログを揃えてはじめて本番仕様になります。

採用判断はこう言い切れます。Claude DesktopとIDEと自社アプリのように複数のホストから同じ道具を使い回す、または公開済みの既製MCPサーバー資産を利用するなら、MCP接続を採用します。逆に単一アプリに数本のツールを持たせるだけの要件なら、LLM APIのfunction callingを直接実装するほうが層が薄く軽いため、MCPサーバーの自作は見送りが妥当です。そして読み書きの別を問わず、書き込み系ツールを承認関門と監査ログなしで本番に載せる構成は選びません。本文でこの結論の根拠を工程順に示します。

AIエージェントとMCP接続の全体像──ホスト・クライアント・サーバーの役割分担

手順に入る前に、どこに何を実装するのかという配置を固定します。誤解が最も起きやすいのは「MCPを入れればエージェントになる」という取り違えで、MCPが担うのは接続の層だけです。

MCPがエージェントに道具を渡す仕組み──JSON-RPC 2.0と3層構成の要点

MCPの登場人物は3層です。ホストはClaude DesktopやIDE、自社チャットアプリといったLLMアプリケーション本体で、クライアントはホスト内部でサーバーとの接続を1対1で維持する部品、サーバーはツールやデータを提供する側になります。メッセージはすべてJSON-RPC 2.0で、サーバーが提供できる機能はツール（実行可能な操作）・リソース（読み取れるデータ）・プロンプト（定型指示）の3種類です。エージェント実装で中心になるのはツールで、クライアントがtools/listでツール一覧を取得してLLMに提示し、LLMが選んだ呼び出しをtools/callで実行して結果を返す、という往復が基本動作になります。規格そのものの設計思想やMCPサーバーの役割の詳細はMCPの標準規格としての仕組みの解説に譲り、本記事は実装工程に集中します。

既製MCPサーバー接続と自作の分岐──設定記述で済む範囲と実装が要る範囲

最初の分岐は「作るかどうか」です。GitHub・Slack・Notionなど公開済みのMCPサーバーに接続するだけなら、実装は発生せず、ホストの設定ファイルにサーバーの起動コマンドや接続先URLを記述して終わりです。Claude Desktopならclaude_desktop_config.jsonへの追記がその作業にあたります。自作が必要になるのは、社内の基幹システム・自社データベース・独自APIのように、既製サーバーが存在しない資産をエージェントから触らせたい場合です。このとき書くのはサーバー側だけで、ホストとクライアントは既存のAIアプリケーションをそのまま使えます。接続の取り決めが規格で固定されているため、自作の範囲が「自社資産をツールとして公開する部分」に限定される——ここがMCP接続の工数を読みやすくしている性質です。

エージェントループにおけるツール呼び出し──行動フェーズをMCPが担う構図

エージェントは観測・推論・行動のサイクルを回して目標に近づきます。MCPが受け持つのはこのうち行動フェーズで、LLMが「次はこのツールをこの引数で呼ぶ」と推論した内容を、実際の外部システムへ届ける配線がMCP接続です。実行結果はそのまま次の観測としてループに戻り、LLMは結果を読んで続行か終了かを判断します。つまりツールを増やすことはエージェントの行動の選択肢を増やすことと同義で、逆にループの制御——いつ呼ぶか、何回まで許すか、どこで止めるか——はMCPの外側、ホスト側の実装課題です。この制御設計はエージェントループの制御設計の解説で扱っているため、本記事は「ループに道具を供給する側」の工程に絞ります。

MCPツール定義とサーバー実装の手順──スキーマ設計から接続確認までの5工程

ここから実装の本体です。工程は、ツール一覧の洗い出し、tool定義、サーバー実装、transport選択と接続設定、動作検証の5つで、順に進めれば手戻りが出にくい並びになっています。

tool定義の設計──名前・説明文・入力スキーマがLLMの呼び出し精度を決める

tool定義は「LLMに読ませる仕様書」です。1つのツールは名前・説明文・入力スキーマ（JSON Schema）の3点で構成され、LLMはこれだけを根拠に呼び出しの要否と引数を決めます。名前はget_invoice_statusのように動詞＋対象の形で用途が一意に読める語を選び、1ツール1責務に絞るのが原則です。説明文には「何をするか」だけでなく「いつ使うべきか・何を返すか・使うべきでない場面」まで書くと、類似ツールとの取り違えが減ります。入力スキーマは引数ごとに型・必須有無・制約を宣言し、説明の曖昧な自由文字列引数を残さないことが第一です。呼び出しの失敗要因の大半は、コードの不具合ではなく説明文とスキーマの曖昧さに集中します。逆に言えば、この3点の作文が本工程で最も費用対効果の高い作業です。なお、大量文書から関連箇所を探して読ませたい要件はツールではなく検索の問題で、その境界は後述の採用判断で扱います。

公式SDKとFastMCPによるサーバー実装──ツール数本なら小さく書ける規模感

サーバー実装にはPythonとTypeScriptの公式SDK（TypeScript版は@modelcontextprotocol/sdk）があり、Pythonではその上に被せるフレームワークとしてFastMCP（2.x系・2026年7月時点）が使われています。FastMCPでは通常のPython関数に@mcp.toolデコレータを付けるだけでツールとして公開され、型ヒントとdocstringがそのまま入力スキーマと説明文に変換される仕組みです。前工程で作文した定義を関数シグネチャに落とすだけなので、ツール数本のサーバーなら数十行の規模に収まります。実装の詳細な書き方と起動方法はFastMCPによるMCPサーバー構築の解説で手を動かせる粒度で扱っています。実装時の設計指針は1つで、ツール関数の中に業務ロジックを書き込まず、既存のAPIやサービス層を呼ぶ薄い皮に留めることです。こうしておくとツールの単体テストが既存資産のテストと分離でき、後述の権限制御も既存の認可層に寄せられます。

transport選択──stdioとStreamable HTTPの使い分け基準

サーバーとクライアントをつなぐ通信路（transport）は2択です。判断軸は「サーバーをどこで動かし、誰と共有するか」に尽きます。

ローカルのファイル操作や個人の開発補助ならstdioで足り、設定も起動コマンドを書くだけです。社内の複数メンバーや複数アプリから同じサーバーを呼ぶ段階になったら、Streamable HTTP（2025-03-26リビジョンで従来のHTTP+SSE方式に代わって導入・2026年7月時点）へ移します。この移行はtransport層の差し替えで済み、tool定義とツール関数は書き直しになりません。最初はstdioで作り、共有段階でHTTPへ昇格させる二段構えが実務の定石です。

ホスト接続と動作検証の手順──ツール一覧の取得から呼び出しテストまで

サーバーができたら、ホストにつないで動作を確かめます。検証は次の順で進めると原因の切り分けがしやすい構成です。

1. ホストの設定ファイルにサーバーを登録し、ホストを再起動して接続を確立する
2. ホスト側のツール一覧表示で、定義した全ツールが見えることを確かめる
3. ツールごとに正常系の呼び出しを依頼し、引数と戻り値が意図通りかを見る
4. わざと曖昧な依頼を投げ、LLMが正しいツールと引数を選べるかを確かめる
5. 接続先システム停止などの異常系で、エラーがLLMに読める形で返るかを見る

特に4は tool定義の品質検査そのものです。ここで取り違えが起きるなら、直すべきはプロンプトではなく説明文とスキーマになります。5も省略しがちですが、エラーが人間向けのスタックトレースのまま返ると、LLMは失敗理由を解釈できず同じ呼び出しを繰り返しがちです。「何が起きて、次に何をすべきか」をエラー文言に含めるところまでが実装の範囲だと考えておくと、ループ全体の挙動が安定します。

権限・認可・安全性の設計──書き込みツールを本番に載せるための統制要件

動くところまでは前章で到達できます。本番投入の壁はここからで、エージェントが外部システムを操作する以上、誰の権限で・どこまで・どんな記録を残して動くのかを設計しないと運用に載せられません。

OAuth 2.1ベースの認可フロー──リモート接続で誰の権限で呼ぶかを固定する

Streamable HTTPで公開するサーバーには、MCP仕様がOAuth 2.1をベースにした認可の枠組みを定めています（2025年以降の仕様改定で整備・2026年7月時点）。MCPサーバーをOAuthのリソースサーバーとして扱い、クライアントはアクセストークンを添えて呼び出す構図で、「エージェントが動いている＝誰かの権限を借りている」状態を明示的に管理できます。設計で決めるべきは2点です。第一にトークンの主体をエンドユーザー本人にするかサービス専用アカウントにするかで、操作の責任追跡が要る業務系は本人トークンに寄せます。第二にスコープの粒度で、読み取り系と書き込み系を同一スコープに混ぜないことが後の統制を単純にします。stdioで動かすローカル用途ならこの層は不要ですが、その場合もサーバーのプロセスがOS上で持つ権限がそのままツールの権限になるため、実行ユーザーの絞り込みは同じ発想で必要です。

最小権限と承認ゲートの設計──読み取り専用から始め破壊的操作に関門を置く

権限設計の実務は「最初から全部渡さない」に尽きます。導入初期は参照系ツールだけを公開し、更新・削除・送信のような破壊的操作は、動作実績と監査の仕組みが揃ってから段階的に追加します。追加後も、破壊的操作の実行前には人の承認を挟む関門を置くのが原則です。MCP仕様自体が、ツール呼び出し前のユーザー同意を実装者の必須要件として明記しており、ホスト側の承認UIに任せるか、サーバー側で承認待ちステータスを設けるかは要件次第ですが、「LLMの判断だけで不可逆な操作が完結する経路を作らない」ことが共通の底線になります。あわせてツール側にも防波堤を入れておく設計です。たとえば削除ツールに件数上限や対象範囲の制約をスキーマで宣言しておけば、引数の取り違えが起きても被害の上限を実装側で固定できます。

プロンプトインジェクション対策と監査ログ──ツール記述を信用しない前提の防御

エージェント特有のリスクは、ツールが返した文書やWebページの中に「この指示に従え」という文字列が仕込まれ、LLMが本来の指示より優先してしまうプロンプトインジェクションです。ツールが増えるほど外部由来テキストの流入口が増えるため、MCP接続はこのリスクと常にセットで考えます。対策の軸は3つです。第一に、外部由来の内容はデータであって指示ではないという役割分離をシステムプロンプトで固定し、重要操作は前述の承認関門で人が止められるようにします。第二に、接続するMCPサーバー自体を選別します。仕様も、ツールの説明文やアノテーションは信頼できるサーバー由来のものを除き未検証として扱うべきだと明記しており、出所不明の公開サーバーを安易に足さないことが第一の防御です。第三に監査ログで、どのツールを・誰の権限で・どんな引数で呼び、何が返ったかを全件記録します。事故対応だけでなく、呼び出しの失敗率や取り違えの傾向からtool定義を改善する材料としても、このログが唯一の観測点になります。

MCP接続の採用判断──標準化が効く条件と自前実装で足りる場面の線引き

最後に、そもそもMCPを採るべきかを条件で切ります。接続の標準化は便利さの話ではなく投資判断の話で、効く条件と効かない条件がはっきり分かれています。

MCP接続を採用する条件──複数ホストでの道具共有と既製サーバー資産の利用

採用の決め手は2つです。第一に、同じ道具を複数のAIアプリケーションから使い回す計画がある場合で、ここがプロトコルの本領になります。接続をアプリごとに個別実装すると実装量はアプリ数×ツール数で増えますが、MCPサーバーとして一度立てれば対応ホストすべてから同じサーバーを呼べるため、導入面が増えるほど共通化が効く構図です。第二に、使いたい道具が既製MCPサーバーとして既に公開されている場合で、このときは自作ゼロ・設定記述だけで行動できるエージェントが手に入ります。なお「社内文書を読ませて答えさせたい」だけの要件は、ツール接続ではなく検索——RAG——の領分です。どちらの層の問題かの切り分けはMCPとRAGの違いと使い分けの解説で整理しているため、要件に読ませる系が混ざっている場合は先にそちらで層を確定させると設計が迷いません。

見送る場面と失敗パターン──単一アプリ・少数ツールなら直接実装が軽い

逆に、自社アプリ1つに社内API数本をつなぐだけの要件なら、MCPサーバーの自作は見送ります。各LLM APIが備えるfunction calling（ツール呼び出し）機能に定義を直接渡すほうが、間に挟む層が1つ減り、実装も運用監視も軽いためです。標準化は道具や利用面が増えるときに回収できる投資であり、増える見込みがない構成では認可・監査を含む統制コストだけが先行します。失敗パターンも型が決まっています。1つ目は、出所を確認していない公開MCPサーバーを試しにつないだまま本番相当のデータに触らせる構成で、前章のインジェクション経路を自ら増やす行為です。2つ目は、書き込みツールを承認関門なしで解放し、LLMの引数取り違え1回が不可逆な操作になる構成です。3つ目は、ツールを一度に大量公開して呼び出し精度を落とすパターンで、ツール数は要件を満たす最小から始め、監査ログの傾向を見て増やすのが安全側の運びになります。

受託開発でエージェント接続を進める手順──要件の仕分けから統制設計まで

実案件での進め方は次の順です。最初にエージェントにさせたいことを「読む」「操作する」「両方」に仕分け、操作系の対象システムごとに既製サーバーの有無を確認します。次に、自作が要る対象について本記事の5工程でツールを設計し、読み取り専用の範囲で動作実績を作ります。最後に認可・承認関門・監査ログの統制を固めてから書き込み系を解放する、という段取りです。この進め方を自社だけで組み立てにくい場合——たとえば基幹システムをエージェントから安全に操作させたい、どこまでを任せてよいか統制の線が引けないといった案件は、AIエージェント開発の支援で要件の仕分けからtool定義・統制設計・実装までを通しで進められます。ツール接続だけを切り出して依頼するより、承認関門をどこに置くかという業務設計ごと相談するほうが、本番投入までの手戻りが小さくなります。

AIエージェントへのMCPツール接続の実装で実務によく挙がる質問

MCP接続の実装を検討する開発者・技術選定者から、実務でよく挙がる質問に答えます。

MCPを使わなくてもAIエージェントは外部ツールを操作できますか？

できます。各LLM APIのfunction calling機能にツール定義を直接渡せば、MCPなしでも外部操作は実装可能です。違いは共有性で、直接実装はそのアプリ専用になるのに対し、MCPサーバー化すればClaude DesktopやIDEなど複数のホストから同じ道具を呼べます。単一アプリ×少数ツールなら直接実装、道具の使い回しや既製サーバー利用が視野にあるならMCPという線引きです。

MCPサーバーの自作にはどの言語とSDKを選べばよいですか？

公式SDKはPythonとTypeScriptを軸に複数言語で提供されており、迷ったら社内の既存資産と同じ言語を選びます。ツールの中身は既存APIを呼ぶ薄い皮にするのが定石のため、呼び出し先と同じ言語のほうが認証情報や型定義を使い回せて実装が短くなります。Pythonなら@mcp.toolデコレータで関数をそのまま公開できるFastMCP（2.x系・2026年7月時点）が立ち上がりの速い選択です。

stdioとStreamable HTTPはどちらで接続すべきですか？

個人のローカル利用や開発中はstdio、複数ユーザー・複数アプリで共有する段階からStreamable HTTPが基準です。stdioはホストがサーバーを子プロセスとして起動する方式で設定が最少、HTTPは常駐サービスとして立てる代わりにOAuth 2.1ベースの認可で利用者を管理できます。tool定義は両者で共通のため、stdioで作って共有段階でHTTPへ移す進め方で作り直しは発生しません。

ツールの呼び出し精度が低いときはどこを見直すべきですか？

最初に見るのはプロンプトではなくtool定義です。説明文に「いつ使うべきか・何を返すか・使うべきでない場面」が書かれているか、引数スキーマに型と制約が宣言されているか、似た責務のツールが並存していないかを順に点検します。改善後は、曖昧な依頼を投げて正しいツールが選ばれるかのテストで効果を確かめます。ツール数が多すぎる場合は、使用頻度の低いものを外すだけで選択精度が戻ることも多いです。

書き込み系のツールを本番で安全に運用する条件は何ですか？

3点セットが条件です。第一に権限の絞り込みで、認可スコープを読み取り系と分離し、ツール自体にも件数上限や対象範囲の制約を宣言します。第二に承認関門で、更新・削除・送信のような不可逆操作はLLMの判断だけで完結させず、実行前に人の承認を挟む構えです。第三に監査ログで、呼び出しの主体・引数・結果を全件記録します。この3点が揃うまでは参照系のみで運用し、書き込みは解放しない判断が安全側です。

関連記事

• MCPとは？AIと外部ツールをつなぐ標準規格の仕組み・MCPサーバーの役割を解説：本記事で省いた規格そのものの設計思想と3層構成を、概念側から押さえられます。
• エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計：MCPが道具を供給する先の、ループ制御と終了条件の設計を確認できます。
• MCPとRAGの違いとは？役割の違いと使い分け・併用アーキテクチャを実装者向けに解説：読ませたい要件と操作させたい要件の層の切り分けを深掘りできます。
• AIエージェントとは？生成AIとの違い・仕組みと業務に組み込む判断基準を解説：エージェントそのものの仕組みと導入判断を、技術選定の前段として整理できます。
• マルチエージェントオーケストレーションとは？仕組み・主要パターン・フレームワーク選定：単体エージェントの先にある、複数エージェント構成の設計判断を扱っています。