レッスン3：ツール使用と Function Calling——外部世界との接続

このレッスンで学ぶこと

• Function Calling と Tool Use の仕組みを理解する
• JSON Schema でツールのインターフェースを定義する発想を持つ
• Model Context Protocol（MCP）の役割と意義を押さえる
• ツール選定と数の管理を「設計判断」として扱う
• 権限とサンドボックスでリスクを抑える基本を理解する
• 出力検証とリトライの設計を組み立てる

---

前のレッスンでは、エージェントの 5 要素（観察・思考・行動・記憶・道具）を整理しました。本レッスンでは、エージェントが外部世界と接続する中核機能——「道具」と「行動」の境界——を深掘りします。Function Calling、JSON Schema、MCP という 3 つの仕組みは、2026 年時点で AI エージェントを業務に組み込む際の標準的な道具立てです。

Function Calling と Tool Use の基本

Function Calling（または Tool Use）は、LLM が「テキストを返す代わりに、定義された関数を呼び出してくれ」という意思表示を構造化された形式で出力する仕組みです。OpenAI が 2023 年に「Function Calling」として導入し、Anthropic は「Tool Use」と呼んでいます。意味するところは同じです。

基本のフロー

flowchart LR
  U[ユーザー入力] --> L[LLM<br/>思考]
  L --> D{ツール<br/>呼び出し?}
  D -->|Yes| T[ツール実行]
  T --> R[実行結果]
  R --> L
  D -->|No| O[最終出力]

1. ユーザーが「○○について調べて」と入力
2. LLM が「Web 検索ツールを呼びたい」と判断、ツール名と引数を JSON で出力
3. アプリ側がツールを実行
4. 実行結果を LLM に返す
5. LLM が結果を解釈して、次の行動または最終出力を決める

Function Calling と「テキスト出力＋パース」の違い

LLM 黎明期は、ツール使用を「LLM がコマンドをテキストで出力 → アプリ側で正規表現でパース → 実行」のように実装することがありました。Function Calling は、これを構造化して標準化したものです。

• テキスト＋パース：LLM の出力フォーマットが揺れると失敗する。フォーマット指定にプロンプトの大部分を割く必要がある
• Function Calling：モデル側がツール定義を理解した上で構造化された JSON を返す。失敗率が下がり、保守が楽

💡 ポイント Function Calling は「設計の標準化」であり、まったく新しい機能ではありません。本質は「LLM とアプリの間で、ツール呼び出しのインターフェースを構造化された形式で共有する」ことです。本コースでは API の細かい仕様には立ち入らず、設計の考え方を中心に進めます。

JSON Schema でツールを定義する

Function Calling では、ツールを JSON Schema 形式で定義するのが標準です。JSON Schema は、JSON データの構造を記述するための標準仕様で、Function Calling 以前から Web API の世界で広く使われていました。

JSON Schema の例（概念）

{
  "name": "search_documents",
  "description": "社内文書を検索する。クエリに対する関連度上位 5 件を返す",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {"type": "string", "description": "検索クエリ"},
      "category": {"type": "string", "enum": ["人事", "営業", "技術"], "description": "検索対象カテゴリ"}
    },
    "required": ["query"]
  }
}

LLM はこの定義を読み取り、「search_documents ツールに query と category を渡せばよい」と理解した上で、ユーザー要求に応じて適切な引数を生成します。

「description」が決定的に重要

JSON Schema の中で、特に効くのは description フィールドです。LLM はここを読み取って「このツールはいつ使うか」を判断します。

• 悪い例："description": "検索する"
• 良い例："description": "社内文書を検索する。クエリに対する関連度上位 5 件を返す。Web 検索とは異なり、社外には公開されない内部情報を対象とする"

description は技術的なメモではなく、「LLM にいつこのツールを使うべきかを伝える教材」だと捉えるのが現実的です。

📝 補足 JSON Schema 自体は 2009 年頃から OSS コミュニティで策定が進み、現在は IETF の draft 仕様として標準化されています。Function Calling はそれを LLM の世界に持ち込んだ形になります。

Model Context Protocol（MCP）

Function Calling の弱点は、「ツール定義がベンダー固有の形式に依存する」ことでした。OpenAI と Anthropic で書式が微妙に違い、Gemini とも違うため、複数モデルに対応するアプリは同じツールを 3 種類書く必要がありました。

これを解消する標準として、Anthropic が 2024 年 11 月に公開したのが Model Context Protocol（MCP）です。

MCP の役割

• ツール（Function）、リソース（読み取り可能なデータ）、プロンプトを、ベンダー非依存の標準形式で記述
• MCP サーバーを 1 つ作れば、Claude・GPT・Gemini など複数モデルから同じツールを呼び出せる
• OSS として公開され、業界全体が採用方向に向かう

2026 年 6 月時点の MCP

公開から 1 年半が経過した 2026 年 6 月時点で、MCP は事実上の標準として定着しました。

• 主要 LLM ベンダー（Anthropic、OpenAI、Google、Microsoft など）が公式対応
• 公開済みの MCP サーバーは、Slack、Notion、GitHub、PostgreSQL、Google Drive、社内 SaaS など多数
• 企業内では「社内専用 MCP サーバー」を立てて、エージェントから安全に社内システムを操作するパターンが普及

MCP の意義——「ツールエコシステム」の誕生

MCP の本質的な意義は、「ツールエコシステム」の標準化にあります。これまでは、ツールが LLM ベンダーごとに作り直されていましたが、MCP 以降は「ツールを 1 回作れば、すべての LLM から使える」状態が広がりました。Web 開発の歴史で「HTTP/REST」が果たした役割と、構造的に似ています。

⚠️ 注意 MCP は標準として急速に普及しましたが、すべてのユースケースで MCP を使うべきとは限りません。1 つの LLM だけを使う社内ツールであれば、ベンダー固有の Function Calling で十分という判断もあります。「将来複数モデルに対応する可能性があるか」「外部の MCP サーバーを活用したいか」が判断軸です。

ツール選定と数の管理

エージェントを設計するとき、「どんなツールを持たせるか」「いくつ持たせるか」は最重要の意思決定の 1 つです。

数の問題

• LLM はツール定義を全部コンテキストに読み込む（または事前に把握している）必要がある
• ツールが多すぎると、LLM が「どれを使うべきか」の判断を間違える
• 経験則として、1 つのエージェントが扱うツールは 10〜20 個程度に抑えるのが現実的

数を抑える設計テクニック

テクニック	内容
統合	似た機能を 1 つのツールにまとめ、引数で切り替える
階層化	「カテゴリ選択 → そのカテゴリの具体ツール」の 2 段階にする
エージェント分割	ツールが 30 個を超えるなら、サブエージェントに分けて連携する（レッスン 6）

「便利だから」の罠

「便利だから追加しよう」と道具を増やすと、エージェント全体の判断品質が落ちます。1 つ追加するときは「LLM がこのツールを正しいタイミングで選ぶ判断品質に耐えられるか」を確認する習慣を持ちます。

💡 ポイント ツールの追加・削除・統合は、エージェント運用の中で繰り返し行う作業です。「1 度作って固定」ではなく、「使いながらリファクタリングする」のが現実的な運用です。後のレッスン 7 の評価とデバッグで、再度この話に戻ります。

権限とサンドボックス

エージェントに道具を渡すと、その道具が外部世界に作用します。権限管理を雑にすると、思わぬ事故が起きます。

権限最小化の原則

• 各ツールには、エージェントが業務を達成するために必要な最低限の権限のみ与える
• 「読み取り専用」で済むツールには書き込み権限を与えない
• 「特定の DB のみ」アクセスできるよう、接続情報を絞る
• API キーやトークンには、必要最小限のスコープを設定する

サンドボックス

コード実行をエージェントに任せる場合、サンドボックス環境（隔離された実行環境）で実行するのが基本です。

• Docker コンテナ、E2B、Modal などの隔離環境
• ローカルファイルシステムや本番 DB に直接接続させない
• ネットワークアクセスを最小限に絞る

Human-in-the-Loop の挟み込み

取り消せない行動（メール送信、決済、本番データ更新など）には、人間の承認を挟む設計が安全です。

• エージェントが行動を提案 → 人間が UI で確認 → 承認後に実行
• 承認の UI と、エージェントの行動ログが連携している
• 緊急時にエージェントを完全に止める「Kill Switch」を用意

レッスン 8 で詳しく扱います。

⚠️ 注意 「うちのエージェントは社内で使うだけだから、権限管理は雑でいい」と考えるのは危険です。社内エージェントでも、プロンプトインジェクションで指示を乗っ取られる事例が報告されています（レッスン 8）。最初から権限最小化を前提に組むのが、後から穴を塞ぐより圧倒的に楽です。

出力検証とリトライの設計

ツール呼び出しが失敗したり、結果が想定外だったりすることは、本番環境では日常茶飯事です。設計時にリカバリーを組み込みます。

検証の典型例

• API レスポンスが期待する JSON Schema に合致するか
• ツール呼び出しが成功したか（HTTP ステータス）
• 結果の中身が業務的に妥当か（例：金額がマイナスでない、日付が未来でない）

リトライの設計

• 一時的な失敗（タイムアウト、レートリミット）は自動リトライ
• 永続的な失敗（パラメータが間違っている）は LLM に戻して再判断
• リトライ上限を設定し、無限ループを防ぐ
• 一定回数失敗したら、人間にエスカレーション

フォールバック

• メインツールが使えないとき、別ツールに切り替える（例：Web 検索 API がダウンなら、別の検索 API に切替）
• フォールバック設定は「便利機能」ではなく、「本番運用の前提条件」と捉える

💡 ポイント エージェントを 1 週間運用すると、想定していなかった失敗パターンが必ず出てきます。設計時に「すべての失敗を予測する」のは不可能なので、「失敗を観察してリトライ・フォールバックを継続的に追加する」運用設計を前提に置きます。

講師の現場メモ：「ツールを 30 個から 12 個に減らしたら精度が倍になった」

私（高梨）が AI スタートアップで CTO だった頃、社内向け業務エージェントを作っていました。1 年ほど運用したあと、ある時点でエージェントの精度が頭打ちになりました。

タスク成功率（Task Success Rate）が 60% で止まり、何をしても上がらない。プロンプトを工夫しても、reasoning モデルに切り替えても、改善は数 % だけ。チームで原因分析を始めました。

トレースを 100 件ほど集めて見比べると、失敗パターンの大半が「ツール選択ミス」だったのです。具体的には、

• 「Slack 通知」と「メール通知」と「Microsoft Teams 通知」が別ツールとして並んでおり、LLM が状況に応じてどれを選ぶべきか迷っていた
• 「データベース検索」が「顧客 DB」「商品 DB」「在庫 DB」「履歴 DB」に分割されており、複合的なクエリで混乱していた
• 「ファイル読み込み」「ファイル書き込み」「ファイル移動」「ファイル削除」が独立しており、意図と違うツールを呼ぶことがあった

私たちはツール群を全面的に再設計しました。

• 通知系：3 ツールを 1 つの send_notification(channel, message) に統合（引数 channel で Slack／メール／Teams を切り替え）
• DB 系：4 ツールを 1 つの query_database(target, query) に統合
• ファイル系：4 ツールを 1 つの file_operation(action, path, ...) に統合

合計のツール数は 30 個から 12 個に減りました。

再評価を実施すると、タスク成功率が 60% → 85% に跳ね上がったのです。エージェントの「迷い」が減り、ツール選択が正確になりました。LLM の判断負荷が下がった結果でした。

このときに学んだのが、「ツールは多ければ多いほど良い」のではなく、「LLM の判断負荷を最小化する」設計が、最終的な精度を決めるということです。本コースで「ツールは 10〜20 個程度に抑える」と繰り返すのは、この実感が背景にあります。

まとめ

このレッスンでは、以下のことを学びました。

• Function Calling／Tool Use は、LLM とアプリの間でツール呼び出しを構造化して共有する仕組み
• ツールは JSON Schema で定義し、description フィールドが LLM の判断を大きく左右する
• Model Context Protocol（MCP、Anthropic 2024 年 11 月公開）は、ベンダー非依存のツール標準として 2026 年 6 月時点で事実上の標準
• ツールは 10〜20 個程度に抑え、統合・階層化・エージェント分割で数を管理する
• 権限最小化・サンドボックス・Human-in-the-Loop の挟み込みで、リスクを抑える
• 出力検証・リトライ・フォールバックは、本番運用の前提条件として設計する

次のレッスンでは、エージェントが計画を立て試行錯誤するパターン——ReAct・Plan-and-Execute・Reflection——を扱います。

---

確認クイズ

このレッスンの理解度をチェックしましょう。

回答する もう一度挑戦