Tool UseとFunction Callingの違いは何ですか？同じ概念ですか？
この2つの用語は業界では時々混用されますが、厳密には微妙な違いがあります：
Function CallingはOpenAIが2023年6月に導入した特定のAPI機能で、GPTモデルが開発者定義の関数を呼び出すための特定のフォーマットを定義します（ツールを定義するJSON Schema；モデルはJSONフォーマットの関数呼び出しリクエストを出力）。Function CallingはこのOpenAI APIメカニズムを特定します——ベンダー固有の実装です。
Tool Useは、AIモデルが外部ツール/サービスを呼び出す一般的な能力を説明するより広義の概念で、特定のベンダーやAPIフォーマットに縛られていません。AnthropicはそれをTool Use、GoogleはFunction Callingと呼びますが、技術的にはほぼ同じことをします。
MCP（Model Context Protocol）はTool Useの上にある標準化層で、AIとツール間の統一された通信フォーマットを定義し、同じツールを異なるAIモデルで各モデルに個別に対応することなく使用できるようにします。
良いツールSchemaをどのように設計しますか？ツール記述の品質はAgentの意思決定品質にどれだけ影響しますか？
ツールのSchema設計は、LLMがツールを正しく選択して呼び出せるかを直接決定します。よく書かれたツール記述は、LLMが追加の説明なしに「いつこのツールを呼び出し、どのパラメータを渡すか」を正確に知ることができます。
良いツールSchemaの5つの要素：
ツール名（name）：明確で動詞始まり、ツールが何をするかを説明します。良い例：get_aave_usdc_apy・withdraw_from_morpho。悪い例：tool_1・execute（曖昧すぎる）。
ツール記述（description）：ツールの目的・使用するタイミング・使用すべきでないタイミングを説明します（ネガティブな説明も同様に重要）。
パラメータ定義（parameters）：各パラメータに明確な型・説明・列挙値があります。examplesフィールドを追加して、LLMが期待されるパラメータフォーマットを知れるようにします。
返却値の説明：ツールが返すフォーマットを記述で説明し、LLMが返却値を解析する方法を知れるようにします。
ツールの境界説明：「このツールができることとできないこと」を明確に述べ、LLMがツールの実際の能力を超えた仮定をするのを防ぎます。
ツール呼び出しが失敗した場合、Agentのエラー処理ロジックはどのように設計すべきですか？
ツール呼び出しの失敗はオンチェーンAgentの日常業務で最も一般的な中断イベントです；堅牢なエラー処理ロジックを設計することは本番環境デプロイの必要条件です。
一般的なツール呼び出し失敗のタイプと対応する処理戦略：
ネットワークタイムアウト（HTTPタイムアウト / RPC接続失敗）：最も一般的な一時的な失敗。処理戦略：指数バックオフリトライ（最初1秒待ち、2番目2秒、3番目4秒）、最大3回リトライ。3回リトライしても失敗する場合は、エラーログを記録してOrchestratorに「サブタスク失敗、次のステップを決定してください」と通知します。
APIエラー返却（4xx / 5xx）：エラータイプを区別します。4xx（クライアントエラー）は通常パラメータの問題で、リトライしても解決しません。5xx（サーバーエラー）は一時的なサーバーの問題で、リトライが適切です。
オンチェーンリバート（トランザクションリバート）：トランザクションはブロードキャストされたがオンチェーン実行時にリバート。一般的な原因：スリッページ超過・Gas不足・承認期限切れ。単純にリトライできません——LLMがリバート原因を分析して調整パラメータでリトライするか操作を断念するかを決定する必要があります。
バックエンド検証遮断（BLOCKED）：これは通常「エラー」ではなく「正しいセキュリティ遮断」です。LLMがこの遮断を回避しようとすべきではなく、アラートを記録して人間のレビューに通知します。
オンチェーンAgentでは、読み取りツールと書き込みツールの隔離をどのように設計すべきですか？
読み取りツール（Read Tools）と書き込みツール（Write Tools）の隔離は、オンチェーンAgentのセキュリティ設計の核心原則の一つです：
読み取りツールの特性と設計：外部状態を変更しない；呼び出し失敗は何回でもリトライ可能；追加確認なしにいつでも呼び出せる。設計原則：関数名はget_・query_・fetch_で始まる；純粋なデータオブジェクトを返す；トランザクションのブロードキャストをトリガーしてはならない。
書き込みツールの特性と設計：オンチェーン状態を変更し・Gasを消費し・操作は不可逆です。設計原則：関数名はexecute_・send_・deposit_・withdraw_で始まる；関数内部でパラメータの二次検証（金額上限・アドレスホワイトリスト・操作タイプ許可）を行う；高額操作には人間確認のinterruptポイントを追加する。
隔離の実装：サブAgentの設計レベルで、読み取りサブAgentには読み取りツールのみを与え、書き込みサブAgentには書き込みツールのみを与え、2つのサブAgent間は直接通信できません（Orchestrator経由のみ）。
実際の例：DeFi利回り最適化Agentのツール設計
$50,000 USDCを管理するDeFi利回り最適化Agentの完全なツールセット：
読み取りツール（3つ）：
get_protocol_apy(protocol: str, token: str) -> {apy: float, tvl: float, updated_at: timestamp} ——指定プロトコルとトークンの現在APYとTVLを照会。意思決定に必要な最小フィールドのみ返すget_gas_price() -> {base_fee_gwei: float, priority_fee_gwei: float, estimated_usd: float} ——現在のGas費用を照会get_wallet_balance(address: str) -> {usdc: float, eth: float} ——操作ウォレットの残高を照会書き込みツール（2つ、Orchestratorの承認後のみ呼び出し可能）：
withdraw_from_protocol(protocol, amount_usdc, approval_token) ——プロトコルからUSDCを引き出し。バックエンド検証：amount_usdc ≤ 10,000；プロトコルがホワイトリストに；approval_tokenが有効deposit_to_protocol(protocol, amount_usdc, approval_token) ——プロトコルにUSDCを入金。同じバックエンド検証このツール設計のセキュリティ：LLMがPrompt Injectionに侵害されても、有効なapproval_tokenなしに書き込みツールを呼び出すことはできません。
ツール数が多い → Agentはできることがより多く柔軟ですが、推論ごとのContextコストが高くなり（ツール記述がより多くのトークンを占有）、LLMがツールを選択する際の「選択困難」問題がより深刻になります。ツール数が少ない → Contextコストが低くツール選択が明確ですが、Agentの能力が制限され複雑なタスクはより多くのシーケンシャルなツール呼び出しが必要です。ベストプラクティス：単一Agentのツールセットを5〜15個に保ち；より多くのツールが必要な場合はサブAgentでグループ化します。