前章では、頭脳（LLM）にツールをつないで自分でループを回す最小のエージェントを動かしました。その手応えでわかったはずです ― エージェントの実力は「どんな道具につながっているか」でほぼ決まると。この章では、その道具を毎回自作する消耗から抜け出し、MCP（Model Context Protocol）という共通規格で外部ツールやデータへ標準的につなぐ方法を学びます。MCPはClaudeで生まれ、いまや業界全体に広がる接続の標準になりつつあります。
ゴールは「道具を自作せず、標準規格で安全につなぐ」
なぜツール接続がエージェントの肝なのか
LLMそのものは、どれだけ賢くても「言葉を生み出す」ことしかできません。最新の在庫数を知ることも、ファイルに1行書き込むことも、外の世界に触れる手段がなければ不可能です。エージェントが「調べて・実行して・確認する」ループを回せるのは、外部に働きかけるツール（道具）を持っているからにほかなりません。
つまり、エージェントの能力の上限は、つながっている道具の質と数で決まります。同じLLMでも、電卓しか持たないエージェントと、データベース・検索・ファイル・社内APIにつながったエージェントとでは、できることがまるで違います。頭脳を上等なものに替えるより、良い道具を的確につなぐほうが、体感の能力は大きく伸びることも珍しくありません。
💡 「頭がいい」より「道具が揃っている」。 優秀な人でも、道具箱が空では何もできません。エージェント開発の多くの時間は、実は「どの道具を、どう安全に渡すか」の設計に費やされます。この章はその中核です。
素のツール定義の限界
前章では、ツールを自分の手で定義しました。関数を書き、名前・引数・説明文をLLMに渡し、呼び出しが来たら実行して結果を返す ― この流れ自体は正しく、いまも基本です。問題は、これを毎回・道具ごとに・プロジェクトごとに作り直すことにあります。
たとえば「データベースを検索するツール」を考えてみましょう。接続処理を書き、クエリを組み立て、結果を整形し、エラーを処理し、認証情報を安全に扱う…。この一式を、あなたのプロジェクトでも、隣のチームでも、別の言語でも、それぞれが独自に実装しています。同じ道具を、世界中の開発者が何度も車輪の再発明で作っているのが素のツール定義の現実です。
あるプロジェクト用に書いたツールは、そのフレームワーク・その言語に縛られ、他へ持ち出しにくい。
M種類のツールをNつのエージェント基盤につなぐと、理屈上N×M通りの接続コードが要る。
接続先の仕様が変わるたび、あちこちに散らばった自作ツールを個別に直して回ることになる。
これは、周辺機器ごとに専用ケーブルが必要だった時代とよく似ています。プリンタにはプリンタ専用、マウスにはマウス専用の差込口 ― 機器が増えるほど、つなぎ方の種類が爆発します。「共通の差込口」があれば、この面倒はまとめて消える。そこで登場するのがMCPです。
MCPとは ― ツール接続の共通規格
MCP（Model Context Protocol）は、AIと外部のツール・データを標準的な方法でつなぐためのオープンな規格です。Anthropicが2024年末にClaude向けに公開し、その後さまざまなAIツールやサービスが対応。2026年現在はベンダーを越えて広く採用され、中立的な運営体制のもとで育つ業界標準へと成長しています。特定の1社の製品ではなく、誰もが実装できる共通仕様である点が重要です。
MCPの発想を一言で言えば、「AIツール接続版のUSB」です。USBが登場して、どのメーカーの周辺機器も同じ差込口で使えるようになったように、MCPに対応した道具はMCPに対応したエージェントなら、どれでも「差せば使える」。作る側と使う側が同じ約束事に従うことで、N×Mの組み合わせ地獄が「N＋M」に畳まれます。
あなたが作るエージェントや、Claudeなどのアプリがこちら。「今つながっている道具は何？」とサーバーに問い合わせ、必要なツールを呼び出す側。
ファイル操作・DB検索・SaaS連携などの機能を「ツール」としてまとめて公開する側。1つのサーバーが複数のツールを持てる。
両者は決まった手順で会話します。クライアントが接続すると、まず「使えるツールの一覧」と「それぞれの説明・引数」をサーバーから受け取ります。LLMはその一覧を見て、目的に合うツールを選んで呼び出し、サーバーが実行して結果を返す ― この往復が、道具ごとの個別実装なしに成立するのがMCPの肝です。
クライアント → サーバー :「使えるツールを教えて」 サーバー → クライアント:「search_docs / read_file / query_db の3つ、説明はこう」 LLMが判断 :「query_db を、引数 {sql:"..."} で呼ぼう」 クライアント → サーバー :「query_db を実行して」 サーバー → クライアント:「結果はこの行データ」
公開のしかたは主に2通り。手元のマシンでプロセスとして動かすローカル型と、ネットワーク越しに接続するリモート型です。ローカルは自分のファイルや開発DBに、リモートはチームで共有するSaaS連携などに向きます。どちらも「ツール一覧をもらって呼ぶ」という約束事は同じで、クライアント側の扱い方はほとんど変わりません。
📖 まず全体像から。 MCPの成り立ち・用語・対応状況をやさしく整理した「MCPとは」解説記事を先に読むと、この章の話がすっと入ります。仕様の細部やバージョンは進化が速いので、実装前には必ず公式ドキュメントで最新を確認しましょう。
MCPサーバーを使う・作る
MCPの一番おいしいところは、すでに世の中に公開されているサーバーをそのまま使える点です。よく使う道具は、たいてい誰かがMCPサーバーとして用意しています。自作エージェントに接続すれば、車輪の再発明なしに能力が一気に増えます。
指定フォルダの読み書き。ドキュメントを読ませたり、成果物を書き出させたりの土台に。
SQLの実行やスキーマ参照。「集計して」に対し、実データへ問い合わせて答えられる。
Web検索や社内ナレッジ検索。最新情報や根拠を引いてくる「調べる手」になる。
課題管理・チャット・ストレージなど。既存の業務ツールをエージェントの手足にできる。
接続の手順自体はシンプルです。使いたいサーバーを起動（またはURLを指定）し、クライアント側の設定にサーバーの場所と認証情報を登録するだけ。あとはエージェントが接続時にツール一覧を受け取り、必要に応じて呼び出します。あなたが「DB検索ツールの中身」を書く必要はありません。提供されたツールを、目的に合わせて組み合わせるのが仕事になります。
⚠️ 「便利だから全部つなぐ」は禁物。 サーバーを1つ足すたび、ツールの数だけLLMに渡す説明が増え、判断が散り、誤操作の余地も広がります。そのエージェントの目的に本当に要る道具だけを選んでつなぐのが基本です。多すぎる道具はむしろ精度を下げます。
自作サーバーも作れる
既製サーバーがない道具 ― 社内の独自API、特殊な業務ロジックなど ― は、自分でMCPサーバーを書けばいいだけです。ここがMCPの美点で、一度サーバーとして公開すれば、対応するどのエージェントからでも同じように使えます。あるプロジェクト用に作った道具が、次のプロジェクトでも、チームの別のエージェントでも、書き直しなしで再利用できるわけです。
サーバー作りの中身は「提供したい機能をツールとして定義し、名前・引数・説明を宣言し、呼ばれたら処理を実行して結果を返す」というもの。前章で書いた素のツール定義と発想は同じですが、出力先が「特定のエージェント」ではなく「MCPという共通の差込口」になる点が決定的に違います。作る労力は一度きり、使い回しは何度でも、です。
🛠 実装に踏み込むなら。 Claudeでエージェントやツール接続を組む具体的なコードは、Claude Agent SDK 入門が実践的です。SDKにはMCPサーバーを扱う仕組みが備わっており、既製サーバーの接続も自作も、公式ドキュメントの手順に沿って進められます。
どんなツールを、どう与えるか
道具を「つなげる」ようになると、次の問いは「何を、どう与えるか」です。ここはエージェントの品質と安全性を左右する設計の勘所で、次章以降の土台にもなります。3つの原則を押さえましょう。
そのタスクに必要な道具・範囲だけを渡す。「読むだけで済むなら書き込み権限は渡さない」。DBなら参照用の限定アカウント、ファイルなら対象フォルダのみ、が基本。
LLMはツールの説明文だけを頼りに使うか否かを判断する。「何をする道具か・いつ使うか・引数の意味・使ってはいけない場面」を具体的に書く。曖昧な説明は誤用を生む。
書き込み・削除・課金・コマンド実行など取り返しのつかない操作は、読み取り系と同列に置かない。実行前の確認、対象の制限、記録を必ず添える。
とくに③は重要です。「調べる」道具（検索・参照・読み取り）は、間違って呼ばれても大きな害になりにくい。一方「変える」道具（書き込み・削除・送信・実行）は、一度の誤操作が取り返しのつかない結果を生みます。読み取り系と書き込み系を意識して分け、後者にはガードを重ねるのが鉄則です。
| タイプ | 例 | リスク | 与え方の目安 |
|---|---|---|---|
| 読み取り系 | 検索・参照・ファイル読み込み | 低め（情報の取り扱いに注意） | 比較的自由に。範囲は絞る |
| 書き込み系 | ファイル更新・DB書き込み・送信 | 高い（取り消しにくい） | 確認・制限・記録を必須に |
| 実行系 | コマンド実行・外部呼び出し・課金 | 最大（暴走・悪用の入口） | 原則ガード＋人の承認を挟む |
🔒 ここは第6章で徹底的にやります。 危険なツールの制御、プロンプトインジェクション対策、承認フローの設計は、エージェントを本番へ出すうえで避けて通れないテーマ。第6章「ガードレールと安全」でまとめて扱うので、この章では「道具には危険度の差がある」という感覚だけ持ち帰ってください。信頼できないMCPサーバーを安易につながない、というのも大切な習慣です。
ブラウザ操作など高度なツール
道具の中でも、近年とくに注目されるのがブラウザ操作です。画面を見て、リンクをたどり、フォームに入力し、ボタンを押す ― 人間がブラウザでする操作をエージェントに任せられれば、専用APIのない多くのWebサービスも「手足」に変わります。MCPサーバーとしてブラウザ操作を提供する実装も登場し、接続のハードルは下がってきました。
ただし、これは最も強力で、最もリスクの高い道具のひとつでもあります。画面上の指示をそのまま受け取ってしまう危うさ（誘導・偽情報）、意図しないクリックや送信、認証情報の露出 ― 前節の「実行系」の注意がそっくり当てはまります。まずは閲覧・情報取得といった読み取り寄りの用途から始め、書き込みを伴う操作は慎重にガードを設けるのが賢明です。
🌐 どこまで任せられる？ ブラウザ操作エージェントの現実的な実力と限界は、AIはブラウザ操作をどこまで自動化できるかで具体的に検証しています。「万能ではないが、用途を絞れば実用」という距離感をつかんでおくと、道具選びの判断がぶれません。
ブラウザに限らず、高度な道具ほど「できること」と「起こりうること」が比例して大きくなります。強い道具を渡すときほど、権限・説明・ガードの3原則を丁寧に ― これが、この章を通して繰り返してきたメッセージです。
- エージェントの能力はつながっている道具の質と数で決まる。頭脳より道具の設計が効くことも多い。
- 素のツール自作は再利用しにくく、N×Mの組み合わせ地獄になる。共通の差込口が欲しくなる。
- MCPはAIと外部ツールを標準的につなぐオープン規格。クライアント（使う側）とサーバー（提供する側）が同じ約束事で会話する「AI版USB」。
- 既製のMCPサーバー（ファイル/DB/検索/SaaS）を差して使え、独自の道具は自作サーバーにして再利用できる。
- 与え方の原則は①権限最小化 ②説明文の質 ③危険な道具は別扱い。ブラウザ操作など強い道具ほど慎重に。
道具の揃え方がわかったら、次は「エージェントを増やす」段階です。1体で抱えきれない仕事を、複数のエージェントで分担・連携させる設計へ進みます。次の第4章「マルチエージェント設計」で、役割分担とエージェント同士の協調（A2A）を学びましょう。