AIエージェントのツール連携は、AIが検索、データ取得、登録などの外部機能を使って作業を進める仕組みです。検索者が知りたいのは「ツールを呼べるか」だけでなく、どこで実行を許可し、誤操作を止めるかでしょう。ここでは問い合わせ対応を例に、読み取りから書き込みへ進む設計順を示します。
01ツール呼び出しの基本的な流れ
モデルは利用できるツールの説明と入力形式を見て、呼び出しを提案します。アプリケーション側が引数と利用者の権限を検証し、実際のAPI処理を行い、結果をモデルに返します。モデルが作った引数をそのまま本番APIへ渡す構成にはしません。
たとえば配送状況を調べるなら「注文番号を受け取る → 利用者がその注文を見てよいか確認する → 配送APIを読む → 回答案を作る」と分けます。注文番号が実在していても、質問者に権限がなければ結果を返してはいけません。
02最初は読み取り専用にする
初回は社内資料の検索や、権限を確認したうえでの状態照会から始めます。メール送信、顧客データの変更、支払いなどの書き込み操作は、送信先・変更前後の値・実行者を画面に示し、人が承認した後に実行します。
削除のように戻しにくい操作は別の権限や承認段階を設けます。便利だからといって一つのツールに「検索・更新・削除」をまとめると、必要以上の権限を与えやすくなります。
03引数と結果をどう検証するか
ツールごとに必須項目、型、値の範囲、対象ID、利用者の権限をサーバー側で確認します。外部システムから返ってきた文章は、回答の材料として扱い、新しい実行指示にはしません。APIキーや秘密情報はモデルの会話やログへ含めず、サーバー側で管理します。
ツールが失敗したときは、再試行の上限を決めます。成功したか分からないまま書き込み処理を繰り返すと、重複送信や重複登録につながります。失敗理由を記録し、人へ引き継ぐ分岐を用意します。
04試験で用意するケース
- 正しい依頼で、必要な一件だけを取得できる
- 他人のIDや権限外の対象を指定すると拒否される
- 入力が曖昧なら実行せず追加確認を求める
- ツールが遅延・失敗しても無限に再試行しない
- 外部文書に不審な命令があっても送信先を変えない
「実行しなかったこと」も成功条件に含めてください。処理時間だけでなく、誤実行の有無、承認に要する時間、失敗からの復旧を測れば、導入できる範囲を判断できます。
05具体例：注文照会ツールの入出力を決める
「注文123の配送状況を教えて」という入力を受けたとき、モデルには注文番号を引数として提案させても、実際の照会はアプリケーション側で行います。引数が空、長すぎる、許可されない形式なら呼び出さず、利用者と注文123の関係を確認します。本人の注文なら配送APIを読み、結果が「発送済み・確認時刻あり」ならその時刻とともに回答案へ反映します。他人の注文ならAPI照会も回答も拒否します。これはツールの説明文だけでなく、実行側の条件にする必要があります。
次に「配送先を変更して」と頼まれたら、読み取りツールとは別の変更処理として扱います。変更前後の住所、注文番号、承認者を画面へ示し、人が確認した後に初めて実行します。通信が途切れて結果不明なら、同じ変更をすぐ再送せず、対象システムの現在値を確認します。呼び出しごとに対象ID・実行者・結果を記録すれば、失敗の調査と二重処理の防止に役立ちます。
試験ケースは「本人の正しい注文」「他人の注文」「存在しない注文」「APIの認証エラー」「変更後に応答だけ失われた場合」です。全件で実際に実行されたAPIと引数を見て、許可外の読み取り・書き込みがゼロであることを合格条件にしてください。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。