ツール呼び出しでは、AIは道具を自分で動かさない：往復するのは「呼びたい」という依頼と結果だけ、と公式資料で確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたものです。数字は2026年10月8日に確認しました。変わることがあります。

先に結論

• 「AIが道具を使う」は、正確には「AIが、どの道具をどんな引数で使いたいかを書いて返し、アプリがそれを実行して、結果をAIに返す」という往復です。公式文書の言い方では、モデルは関数を自分では実行しません（Googleの文書）。
• 往復の最小単位は2回のAPI呼び出しです。1回目で「呼びたい」が返り、2回目で結果を渡して最終の答えをもらいます。道具が続けて必要なら、これが繰り返されます。
• つまずきやすいのは、呼び出しと結果を結びつけるID、結果を入れる位置とルール、エラーの返し方です。

前提：何の話か

APIは、アプリの中からAIを呼び出す開発者向けの窓口です。ツール呼び出し（function calling、関数呼び出し）は、AIが外の機能（天気の取得、データベースの検索、ファイル操作など）を使えるようにする仕組みです。

AI自身は、文章を生成するだけで、インターネットに出たり、データベースに触ったりはできません。そこで、「こういう道具があります」という説明書を事前に渡し、必要だとAIが判断したら、その道具の呼び出し方を文章（実際には構造化されたデータ）で返してもらいます。実際に動かすのは、アプリ側です。

用語を整理します。

• 道具の定義：名前、説明、引数の形（JSONスキーマ。データの形を書く書式）をまとめたもの。
• 引数：道具に渡す値。たとえば天気の道具なら「場所」。
• 呼び出しのID：どの依頼に対する結果かを結びつける目印。

往復の手順

3社の文書に共通する流れを、順番に書きます。

1. 道具の定義を付けて送る。ユーザーの質問と一緒に、使える道具の一覧を渡します。
2. AIが、道具を呼びたいと返す。通常の文章の代わりに（または文章と一緒に）、道具の名前と引数、呼び出しのIDが返ります。
3. アプリが道具を実行する。AIは何も実行していません。アプリが引数を取り出して、自分の関数を動かします。
4. 結果を、IDつきで返す。2回目のリクエストに、元の会話と、道具の結果を加えて送ります。
5. 最終の答えが返る。AIが結果を使って答えます。まだ道具が必要なら、2に戻ります。

見立てです。この流れから分かるのは、AIは道具の結果を「次の入力」として読むだけだ、という点です。道具の結果に何が入っても、それは次のリクエストの入力トークンとして数えられ、AIに読まれます。道具が外から取ってくる文章に、AIへの指示のような文が混ざっていた場合の扱いは、読んだ文書には書かれていません。結果を渡す前に、アプリ側で検査する設計が無難だと思います。

各社の形

各社の中身

Anthropic

公式のツール使用の文書によると、次の通りです。

• 実行する場所：ユーザー定義の道具や、Anthropicが形を決めたbash、text_editorなどはクライアントの道具で、自分のアプリで実行します。web_search、web_fetch、code_executionなどはサーバーの道具で、Anthropicの側で動き、結果が直接返ります。
• 呼び出し：tool_choiceがauto（既定）のとき、Claudeはターンごとに、道具を呼ぶか直接答えるかを決めます。

公式文書の呼び出しの例です（この記事では実行していません）。

{
  "type": "tool_use",
  "id": "toolu_01A09q90qw90lq917835lq9",
  "name": "get_weather",
  "input": { "location": "New York, NY", "unit": "fahrenheit" }
}

• 結果の返し方（文書の例）：{"role": "user", "content": [{"type": "tool_result", "tool_use_id": ..., "content": ...}]}。その前に、直前のアシスタントの応答（tool_useを含む）を会話に足します。
• 置き方の決まり：tool_resultは、対応するtool_useの直後のメッセージに置きます。間に別のメッセージを入れられません。また、ユーザーのメッセージの中では、tool_resultのブロックを先に置き、テキストはその後に置きます。逆にすると400エラーです。
• エラー：道具の実行が失敗したときは、tool_resultにis_error: trueを付けます。文書は、「failed」のような一言ではなく、何が起きたか、次に何を試すべきかを書くように勧めています（例：「Rate limit exceeded. Retry after 60 seconds.」）。
• 引数が不正のとき：リクエストが不正または引数が足りないと、Claudeは2〜3回、直して再試行してから、ユーザーに謝る、と書かれています。引数を必ずスキーマに合わせたいときは、strict: trueを使います。
• 選択（tool_choice）：auto（呼ぶかどうかを任せる）、any（どれか1つは必ず使う）、tool（特定の1つを必ず使う）、none（使わせない）の4つ。anyとtoolは、API側が助手のメッセージの出だしを先に埋めて強制する、と書かれています。Opus 5.5、Sonnet 5.5、Fable 5.1、Mythos 5.1では、anyとtoolは400エラーになり、autoと厳密な道具の使用を勧める、とあります。
• 並列：1回の応答に、複数のtool_useが入ることがあります。disable_parallel_tool_use: Trueで、1ターン最大1つの呼び出しに抑える例が文書にあります。複数の結果は、1つのユーザーメッセージの中にtool_resultを並べて返します。
• サーバーの道具と混在：1つの応答に、クライアントのtool_useと、結果のまだないサーバー側の呼び出しが入ることがあります。その場合は、クライアントの道具のtool_resultだけを入れたユーザーメッセージで答え、tools配列は同じものを使います。

OpenAI

公式の関数呼び出しの文書によると、次の通りです。

• 定義：typeは常にfunction。name、description、parameters、strict（厳密モードにするか）を持ちます。
• 依頼：応答のoutput配列に、typeがfunction_callの項目が入ります。call_id、name、argumentsを持ち、argumentsはJSON文字列なので、コード側で解析する必要があります。
• 結果：入力に、type: "function_call_output"、call_id、outputを持つ項目を足して、もう一度送ります。
• 推論モデルの注意：推論モデルでは、道具の呼び出しと一緒に返ってきた推論の項目（reasoning items）を、道具の結果と一緒に返す必要がある、と書かれています。
• 並列：応答に道具の呼び出しが0個、1個、複数のどれも入りうるので、複数ある前提で書くのがよい、と書かれています。
• 数：厳密な上限は書かれていません。「ターンの開始時に20個未満が目安」というゆるい提案があり、多い場合は「tool search」を勧めています。
• 選択の指定（tool_choice）、並列の無効化、strictでないときの不正な引数の扱いは、僕らが読んだ範囲には書かれていませんでした。

Google（Gemini）

公式の関数呼び出しの文書によると、次の通りです。

• 流れ：宣言を渡す、モデルが呼び出しを返す、アプリが実行する、結果を返す。文書は「モデルは関数を自分では実行しない」とはっきり書いています。「このプロセスは複数ターンで繰り返せる」ともあります。
• ID：generateContentでは、結果を返すときに、モデルが返したidをそのままfunctionResponseに入れる、とあります。並列の呼び出しでは、結果を元の呼び出しの順序で返す必要はなく、idで対応づけられます。
• モード：generateContentではAUTO（既定）、ANY（必ず関数を呼ぶ）、NONE（呼ばない）、VALIDATED（関数の呼び出しか自然な文章のどちらかで、スキーマに合うように制約。内蔵の道具や構造化出力と併用するときの既定）。allowed_function_namesを渡すと、選べる関数をその一覧に絞れます。
• 並列と連鎖：独立した呼び出しは同時に出せます。ある結果を次の呼び出しに使う連鎖（先に場所を取り、その場所の天気を取る）もできます。
• 思考の署名（thought signature）：Gemini 3系では、関数呼び出しのときに、思考の署名を返すことが必須と書かれています。履歴を自分で組み立てるときは、署名を元の部分に付けたまま返します。公式のSDKは自動で扱います。省いたときに何が起きるかは、文書には書かれていませんでした。
• 数：関数の宣言の最大数は、読んだ範囲に書かれていません。

選び方・判断の基準

見立てです。ここまで読んだ範囲で、設計の基準は次の通りです。

• 道具の説明を丁寧に書く：Anthropicの文書は「最も重要な要素」と明記しています。いつ使うか、何を返すか、引数が何を意味するかを書きます。
• 関連する操作は1つにまとめる：Anthropicの文書は、create_pr、review_pr、merge_prを、action引数つきの1つの道具にまとめる例を挙げています。道具の数が減り、迷いが減ります。
• 名前に接頭辞を付ける：github_list_prs、slack_send_messageのように（Anthropicの文書の例）。
• 結果は、必要な情報だけを返す：内部の見えにくいIDより、スラッグやUUIDのような安定した識別子を返す、と書かれています。
• 引数の形を確実にしたいなら、strict（厳密モード）を使います。詳しくは別記事「構造化出力」で扱います。
• 道具の数が多いとき：OpenAIは20個未満を目安にし、多ければ道具検索を勧めています。

よくある失敗・つまずき

• 結果の置き場所を間違える：Anthropicでは、tool_resultをtool_useの直後に置かないと「tool_use ids were found without tool_result blocks immediately after」というエラーになります。テキストをtool_resultより前に置くのも400エラーです。
• IDを結びつけ忘れる：3社とも、結果は呼び出しのID（tool_use_id、call_id、id）で対応づけます。並列の呼び出しでは、特に重要です。
• OpenAIの引数を、解析せずに使う：argumentsはJSON文字列です。
• 推論モデルで、推論の項目を返し忘れる（OpenAI）。
• エラーを一言で返す：Anthropicは、何が起きたか、次に何を試すかを書くよう勧めています。
• 思考の署名を落とす（Gemini 3系）：履歴を自分で組むときは、署名を元の部分に付けたまま返します。
• 強制の指定が通らない：Anthropicでは、一部のモデルでanyとtoolが400エラーになります。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。形やフィールド名は、公式文書の記載です。
• 3社は、API自体（Responses API、Interactions API、generateContentなど）が複数あり、フィールド名が違います。この記事の表は、読んだ文書の書き方に合わせています。自分の使う窓口の最新の文書を見てください。
• OpenAIのtool_choice、並列呼び出しの設定、strictでないときの不正な引数の扱いは、読んだ範囲では確認できていません。
• Anthropicのpause_turnやmax_tokensのときの扱いは、ツール呼び出しの文書では扱われておらず（別の文書への案内のみ）、読んでいません。
• Geminiは、関数の数の上限、思考の署名を省いたときの挙動が、読んだ範囲に書かれていません。
• 道具の結果に含まれる文章の安全性（外から取った文に、指示のような文が混ざる問題）は、この記事では一次資料を読んでおらず、一般論の見立てだけです。
• トークン数、対応モデル、400エラーになる条件は、変わることがあります。

出典

• Tool use with Claude（Claude Platform Docs、Anthropic、2026年10月8日確認）
• How to implement tool use（Claude Platform Docs、Anthropic、2026年10月8日確認）
• Handle tool calls（Claude Platform Docs、Anthropic、2026年10月8日確認）
• Prompt caching（Claude Platform Docs、Anthropic、2026年10月8日確認）
• Function calling（OpenAI API、OpenAI、2026年10月8日確認）
• Function calling（Gemini API、Google AI for Developers、Google、2026年10月8日確認）
• Function calling（generateContent、Google AI for Developers、Google、2026年10月8日確認）

更新履歴

• 2026年10月25日 書き方を直しました。
  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した