AIエージェントの最も核心的な能力は「思考」ではなく「行動」です。思考はLLMのテキスト予測に過ぎませんが、行動こそがエージェントと現実世界を結びつけるメカニズムです。Tool Use（ツール呼び出し）はこのメカニズムの実装方法です——エージェントが「何かをしたい」というリクエストをどのように発するか、外部システムがどのように実行するか、そして結果がエージェントの次の推論ステップにどのように影響するかを定義します。
Tool Useの動作原理を理解することは、単なる技術的な問題ではありません。クリプトシナリオでは、Tool Useの設計が「エージェントがあなたの知らないうちに資産を動かせるかどうか」を直接決定します。
Tool Useのコンセプトは直感的です：LLMに「ツールリスト」を与え「これらのツールを呼び出せる」と伝えます。ツールは何でも構いません——ETHの現在価格を照会するAPI、Aaveの預金利率を読み取る関数、トランザクションに署名するインターフェース、さらにはメールを送信する能力。実装は4つのステップで展開されます：第一、System PromptまたはAPIパラメータで、LLMにどのツールが存在するか、名前、機能の説明、パラメータ形式を伝えます。第二、LLMが推論中に「今ツールを呼び出す必要がある」と判断すると、ツールを直接実行せず、「ツール呼び出しリクエスト」という構造化された出力を生成します——通常はJSON形式で、どのツールを呼び出すかとパラメータを指定します。第三、あなたのアプリケーションコード（LLMではない）がこのリクエストを読み取り、実際にツールを実行します。第四、ツールの返り値をLLMのコンテキストに戻し、続きの推論を行います。
重要なポイント：LLM自体はツールを実行しません。「何をしたいか」を言うだけで、実際の実行はバックエンドコードです。この設計は遠回りに見えますが、セキュリティの基盤です——実行層があなたのコントロール下にあり、セキュリティ検証ロジックを自由に追加できます。
「Function Calling」（OpenAIの用語）と「Tool Use」（Anthropic Claudeの用語）を同時に見かけて混乱するかもしれません。本質的には、どちらも同じ問題を解決しており、メカニズムはほぼ同じです。違いは主にAPI設計とフォーマットの詳細にあります。MCP（Model Context Protocol）はその上にさらに標準化の層を追加します——Function CallingやTool Useを置き換えるのではなく、ツールの定義と配布を標準化し、同じツールが異なるLLMやエージェントフレームワークから呼び出せるようにします。ユーザー視点で最も重要なのは：どのモデルが使われていても、現代のAIエージェントはほぼすべて類似のメカニズムを通じてLLMにツール呼び出しを可能にしているということです。
Tool Useで最も重要なセキュリティの問題は「ツールを呼び出せるか」ではなく「ツール呼び出しの結果が検証されているか」です。いくつかの重要なセキュリティ設計の次元があります。
ツールの分類管理：ツールを「読み取り専用ツール」（価格照会、オンチェーン状態、データ検索）と「書き込みツール」（トランザクション署名、資金移動、設定変更）に分けます。読み取り専用ツールのエラーの結果は誤情報のみ；書き込みツールのエラーの結果は資産損失の可能性があります。この2つのカテゴリには異なる認可と検証メカニズムが必要です。
パラメータ検証：LLMが生成したツール呼び出しリクエストは実行前にパラメータの妥当性を検証する必要があります。エージェントが「送金」ツールを呼び出そうとするが、パラメータの受取アドレスがホワイトリストにない、または金額が設定上限を超えている場合——このリクエストは実行されるのではなくブロックされる必要があります。
ツール呼び出しのログ記録：すべてのツール呼び出し（リクエストパラメータと返り値を含む）が完全に記録される必要があります。これは事後監査の基盤であり——エージェントが予期しない操作をした場合、ログによって正確にどのツールが呼び出され、どのパラメータで、何が返されたかを追跡できます。
返り値の信頼性検証：ツールの返り値を無条件に受け入れるべきではありません。価格照会ツールが突然「ETH = $0.01」を返した場合、この結果はエージェントが次の決定を誤ったデータに基づいて行うのではなく、異常処理をトリガーする必要があります。プロンプトインジェクション攻撃の核心メカニズムはまさにツールの返り値を汚染することです。
実際のクリプトエージェントのデプロイでは、ツール設計はいくつかの共通パターンに従います。
第一、階層的な認可：照会ツール（DEX価格、オンチェーン状態、ガス代見積もり）は追加承認不要でエージェントが自由に呼び出せます；計算ツール（戦略評価、リスク計算）も同様に自由；実行ツール（トランザクション署名、資金移動）は追加の承認ゲートを通過する必要があります——金額閾値（$100超は確認が必要）、タイムロック（業務時間外の大規模操作の遅延確認）、または承認されたコントラクトのホワイトリスト。
第二、ツールサンドボックス：隔離されたテスト環境でツール呼び出しを「ドライラン」します——オンチェーンにブロードキャストせずに取引実行をシミュレートし、エージェントが期待される結果を確認してから実際に実行します。これにより、本番環境に移行する前にツールの動作を確認できます。
第三、手数料上限チェック：ガス代を含むオンチェーンツールを実行する前に、まずガス見積もりツールでコストを計算し、プリセットの「最大許容ガス代」と比較します。手数料が期待を超える場合は実行を拒否し、ガス代スパイク時の予期しないコスト超過を防ぎます。
AIエージェントサービスを使用または評価する場合、Tool Useの設計品質がセキュリティに直接影響します。エージェントシステムのツール設計を評価する際、以下の質問をしてください：このエージェントのツールリストは「読み取り専用」と「書き込み」ツールを明確に区別していますか？書き込みツール（特にオンチェーン署名）に独立した承認検証がありますか？ツール呼び出しが完全にログ記録され監査可能ですか？ツールの返り値は異常な結果が直接採用されないよう妥当性検証されていますか？これらすべてに明確な答えがあれば、そのシステムのツール設計は信頼に値します。