エージェントのツールは顧客の業務で使う判断と操作に合わせる
既存APIを全部渡す前に、業務に必要な照会・下書き・実行を切り出す。ツール名・入力・結果から、何が確認でき、どこで外部の状態が変わるか分かるようにする。
用語
- ツール契約
- モデルが使う操作の目的・入力・出力・副作用・失敗時の扱いを定めた約束。
- 副作用
- ツールの呼び出しによって外部の状態や相手に生じる変更。
- 処理状態
- 未受付・受付済み・完了・失敗・結果不明など、業務操作がどこまで進んだかを表す情報。
図と例
顧客の1件の業務を追う → 照会・下書き・実行を定義 → 入力と処理状態を検証 → 実例で選択ミスを評価
仮定の例：卸売会社の注文キャンセル支援では、注文状況と適用規程を読む照会、キャンセル案の作成、承認した対象を変更する実行を分ける。照会の結果が「倉庫へ依頼済み」なら「取消完了」と案内せず、確定結果を照会する。モデルに汎用のDB更新ツールを渡して判断させる方式は採らない。
実際のサービス・製品では
Anthropic
Anthropicは既存APIの単純なラップを増やすより、業務に沿ったツールの選定、明確な目的、必要な情報の返却、実タスクでの評価を説明している。受発注の例はこのTipの独自シナリオ。
資料を読む
解説
顧客の実際の業務例で、ツールの選択ミス・引数ミス・不要な呼び出しを観測する。必須項目不足、同名の取引先、出荷後の注文を用意し、説明の改善と実行側の検証を分けて直す。
ツール契約は操作の目的、必要な入力、返す結果、副作用、失敗時の扱いを定めるもの。顧客の受発注システムにある低水準APIをそのまま並べると、注文情報と顧客情報の結合や状態の読み取りを毎回モデルに任せることになる。注文の状況を必要な範囲でまとめて返す照会ツールなど、頻出する業務単位にそろえる。一方で、確認用の照会にキャンセル実行を隠してまとめない。顧客名が曖昧なら候補と安定したIDを返し、候補が複数なら選び直す。結果には処理状態、対象のバージョン、次に使うIDを含め、受付と完了を区別する。テナントと権限はサーバーで確かめ、モデルが入力した顧客IDだけを信用しない。
トレードオフ
- 用途を限定した業務ツールを作る
- 得るもの：必要な判断と返却情報をそろえやすい
- 払うもの：顧客ごとの業務差と契約の保守が必要
- 検証済みの小さなツールを組み合わせる
- 得るもの：複数の業務で再利用しやすい
- 払うもの：呼び出し数と途中状態の解釈を評価する必要がある
さらに学ぶ
チェック
注文状況の照会ツールが「倉庫へ取消依頼を受付済み」と返した。完了の通知はまだない。適切な扱いは？
- 受付済みと伝え、確定結果を照会する
- キャンセル完了と案内する
- 確認できるまで同じ取消操作を無条件に再送する
解答と解説
受付済みと伝え、確定結果を照会する
受付は処理完了を示さない。受付状態を伝え、操作IDなどで確定結果を確認する。無条件の再送は完了確認の代わりにならず、外部操作の重複にもつながり得る。