ClaudeのTool useを理解する：要求・実行・結果のループを設計する

要求と結果を一対一に対応させる

ツール名、引数、要求IDを受け取り、実行結果を対応する要求へ返します。複数の要求がある場合も、返ってきた順番だけで結び付けないようにします。モデルが最終的な文章を生成するためには、何が起きたかが分かる結果が必要です。

クライアント側で実行するツールと、提供者側で実行される機能では責任範囲が異なります。自分のアプリが実行する操作では、モデルの提案をそのまま関数呼び出しへ流さず、認可や入力検証を挟みます。

失敗を空の成功へ変えない

検索結果が0件、検索サービスが停止、対象を読む権限がない、という状態は違います。すべてを空配列で返すと、モデルは「存在しない」と判断してしまうかもしれません。機密を漏らさない範囲で、扱えるエラー種別と次の動作を定義します。

内部例外の全文を会話へ返す必要はありません。利用可能な情報と再試行の可否を整理し、秘密や内部構成を必要以上に露出しないようにします。

ループの終わりを業務側でも定義する

モデルが操作を要求し続けた場合、いつまでも実行を続ける設計にはしません。最大回数、費用、経過時間、同じ要求の反復を停止条件にします。停止時は実行済みの操作と未完了の作業を区別して報告できるようにします。

複数の要求に隠れた依存を確認する

同時に見える二つのツール要求でも、片方の結果がもう片方の前提になる場合は、そのまま並行実行できません。たとえば対象を検索してから、その対象を更新する処理です。モデルが示した呼び出しの並びだけで安全性を判断せず、ツールの業務契約と引数の関係を確認します。独立した照会と、状態を変える処理を同じ扱いにしないことが重要です。

結果を返す際は、成功した要求だけを都合よく残さず、失敗や未実行も対応付けます。どれが実行されたかが曖昧なまま会話を続けると、モデルが同じ操作を再要求する可能性があります。実行IDをアプリで保持し、結果の確認と最終説明の生成を分けると、途中の障害から再開する範囲を小さくできます。

具体例で考える

架空の在庫照会ツールが、存在する商品に対して権限エラーを返しました。

要求：在庫を照会。
検証：利用者の参照権限を確認。
結果：参照不可として扱う。
最終応答：在庫0と断定せず、確認先を案内。

実行できなかったことは、在庫がない証拠ではありません。ツール結果の意味を正しく定義することで、会話が誤った業務判断へ進むことを防ぎます。

確認課題と合格の目安

一つの照会ツールに正常、0件、権限不足、一時障害の結果を定義してください。

• 要求IDと結果を対応できる。
• 失敗を正常な0件に置き換えない。
• 反復と時間の上限を設けている。