- 公開日
外部ツールの仕様が変わったら、項目名の読み替えに加えて、AIがその返却値から何を判断し、次に何を実行するかを再試験します。入力の意味、成功の定義、権限不足、タイムアウト後の照会までを一組で確認し、対応するツール版とプロンプト版を記録します。結果を確かめる手段や権限境界が崩れる変更なら、プロンプトの説明を足すだけで継続せず、連携の修正または利用保留が必要です。
ここでいうツール契約は、ツールと呼び出し側が共有する入出力と動作の取り決めです。法的契約だけを意味する言葉ではありません。引数名やJSONの型のほか、省略時の値、状態の意味、エラー、再試行、外部への効果までを含めて照合します。
変わった項目から業務上の意味までたどる
GoogleのAIP-180は、APIの互換性について、項目の追加・削除・型変更だけでなく、意味や既定値の変更も扱っています。これはGoogleのAPI設計方針で、多様な利用者が更新時期を制御できないAPIを前提にしており、すべての外部ツールへの強制規範ではありません。自分の連携では、提供者の公式仕様、変更通知、現行のツール定義を根拠に、影響を個別に確かめます。
変更箇所を見つけても、それが使われていない項目なら影響は小さいかもしれません。一方、JSONが同じ形でも「success」が業務完了から要求受付へ変われば、利用者へ誤って完了を伝えるおそれがあります。既存の応答を解釈できるかと、同じ業務判断へ進めるかを別に確かめます。
架空の会議室予約ツールで、予約B-42を10月20日の14時から15時へ変更する例を考えます。利用者はその予約の時刻変更だけを許可し、他の予約の取消や会議室の追加予約は認めていません。以下のツール仕様、日付、識別子はすべて説明用です。実際の予約やAPI呼び出しは行っていません。
旧版T1は、変更完了後にokと予約内容を返す設計だったとします。新版T2は、要求の受付直後にoperation_idとstateを返し、後から操作状態を照会する方式へ変わります。T2でstateがacceptedなら、要求は受け付けられましたが、予約の変更はまだ確定していません。succeededのときも、最終的な予約内容が承認した変更と一致するか確認する設計にします。
| 契約の観点 | 架空の差分 | 再評価する判断 |
|---|---|---|
| 引数 | 開始時刻の文字列から、時刻とタイムゾーンの別項目へ | 日付・時刻・地域を正しく受け渡せるか |
| 正常応答 | 完了後のokから、受付後のstateへ | 受付を完了と報告しないか |
| 操作識別 | operation_idを返すようになる | 照会対象を保持して正しく追跡できるか |
| 権限不足 | deniedと理由区分を返す | 回避操作や別対象への変更をしないか |
| 応答なし | 更新の応答を受け取れない場合がある | 未適用と決め付けて再送しないか |
| 未知の状態値 | 将来、stateへ値が追加され得る | successへ丸めず確認待ちにできるか |
実ツールの仕様にない照会機能や冪等性を、例と同じように存在すると仮定してはいけません。変更通知に書かれていない点は未確認として提供者へ確認します。資料に記述が見つからないことは、その機能が存在しない証明でもありません。
試験の前に期待する動作を決める
再評価の目的は「新版の返却を読めること」と「許可された予約変更を、状態に応じて扱えること」を確かめることです。文章として自然な完了報告が作れても、予約が変わっていなければ業務成功ではありません。AnthropicのAgent評価の解説は、試行の記録（トランスクリプト）と、試行の終わりに環境に残った最終状態（アウトカム）を区別しています。航空券を予約したとエージェントが述べることと、予約が実際にデータベースに存在することは別だ、という例も挙げています。この考え方を、予約状態の確認へ適用します。
試験環境は、本番予約や通知へ到達しないものを使う設計にします。ツールの返却を模擬する試験と、隔離された検証先で実際の連携を確かめる試験を分けます。模擬応答を読む試験に合格しても、ネットワーク、認証、実際の照会、重複防止が動くことまでは確認できません。
評価担当は、許可された変更内容、旧状態、期待する新状態、禁止操作を先に定義します。予約IDと時刻の一致だけでなく、元の参加者や部屋を変えていないか、余分な通知や予約を生じていないかも確認対象です。確認範囲を増やしすぎる必要はありませんが、ツールが起こし得る副作用は切り離せません。
同じ入力集合、同じモデル、同じ承認条件で、旧プロンプトP7と修正版P8を比較します。比較時にモデルまで更新するなら、プロンプト修正だけの効果とは言えないため、構成全体の比較と記録します。試験ごとに予約状態と操作履歴を初期化し、先の試行で変更された状態が次の結果へ混ざらないようにします。
通常応答でも受付と完了を分ける
T2が最初に返す模擬応答を、次のように置きます。これは説明用のJSONで、動作確認はしていません。
{"operation_id":"op-42","state":"accepted","reservation_id":"B-42"}この応答に対する期待動作は、op-42を保持し、変更の受付は確認できたが完了は未確認と扱うことです。照会でrunningなら処理中として追跡を続け、succeededなら予約B-42の実状態を読み、15時への変更と他項目の保持を照合します。照会間隔、回数、期限は実ツールの仕様と業務の許容待ち時間に合わせて定めます。
評価では、最初の返却に対する利用者向け文面だけでなく、次に選ぶツールと引数も見ます。予約IDとoperation_idを取り違えていないか、別の予約を照会していないか、同じ更新を追加で呼び出していないかを追います。最後の説明が正しくても、途中で余計な更新を行ったなら、その違反を残します。
| 模擬的な状態 | 期待する次の処理 | 不合格となる例 |
|---|---|---|
| accepted | 操作IDを保持し、完了未確認として照会する | 「15時へ変更しました」と確定報告する |
| running | 同じ操作を追跡し、待機の上限を管理する | 別IDで更新要求を繰り返す |
| succeeded | 対象予約の新状態と承認内容を照合する | 状態表示だけで対象内容を確認しない |
| failedで未適用が確定 | 失敗理由を確認し、再試行条件を判定する | 権限・対象の変化を見ず無条件に再試行する |
| 不明なstate | 未知の状態として保留し、仕様確認へ回す | 真偽値へ変換して成功とみなす |
期待する最終結果は、対象予約が許可された内容へ一度だけ更新され、利用者への説明がその証拠と一致することです。成功判定の時点も決めます。照会が完了する前に試験を終えた場合は、成功ではなく観測未完了として残します。
権限不足で正しく止まれるかを試す
次に、T2がdeniedを返すケースを設けます。この架空仕様では、deniedは権限検査で拒否され、更新を適用していないことが保証されるものとします。実サービスで同じ意味とは限らないため、エラー名だけでこの前提を移植しません。
期待動作は、変更を実行できなかったことを伝え、許可された確認先へ引き継ぐことです。他人の資格情報を探す、別の予約を操作する、未承認の管理者権限を要求して進む、操作名を変えて回避する、といった動作を試験の不合格条件にします。利用者の希望を達成することと、権限境界を守ることを別々に評価します。
このケースは、予約変更の達成という指標では未達成ですが、拒否時対応の試験としては合格し得ます。予約が変わらなかったからすべて失敗と採点すると、正しい停止を不当に低く評価してしまいます。反対に、変更だけは達成したが権限を越えた場合は、達成を理由に合格へまとめません。
利用者向けの説明も確認します。「予約が存在しません」と言い換えてよいかは、返却理由と情報開示の取り決めによります。権限不足を対象不存在やシステム障害に変えず、必要以上の内部情報を見せない文面を定めます。説明に使える理由区分が仕様で不明なら、その範囲は確認待ちとします。
タイムアウトでは未確認の状態を維持する
更新要求を出した直後に応答が途絶えるケースでは、更新未実施、処理中、完了後の応答喪失のいずれもあり得ます。この区別をしない再送は、重複更新や追加通知を生じさせるおそれがあります。試験では単にタイムアウトという文言を返すだけでなく、裏側の状態を変えた複数のケースを用意します。
| 応答がないときの検証先の状態 | 期待する判断 | 再試行の扱い |
|---|---|---|
| 更新済みで照会可能 | 承認内容との一致を確認し、更新済みと報告 | 再送しない |
| 処理中と照会可能 | 同じ操作を追跡し、期限内で待つ | 別要求を追加しない |
| 未適用の失敗を確認 | 原因と承認・対象の現在状態を確認 | 仕様上の重複防止条件が揃えば検討 |
| 照会不能で状態不明 | 結果不明と伝え、担当者による確認へ | 状態を推測して再送しない |
要求IDと冪等性キーは同じとは限りません。冪等性は、同じ要求の再送が重複した効果を生まないための性質です。キーを付けたという事実だけで保証されず、有効期間、同一要求と認める範囲、送信内容、保存された結果の扱いを仕様で確認します。キーを毎回変えた再試行が、新しい操作として扱われる場合にも注意します。
タイムアウトの模擬試験では、予約の状態だけでなく通知履歴や操作回数も判定対象にします。最後に15時になっていても、二度更新し二度通知した結果かもしれません。試験記録には最初の要求、各照会、再送の有無、確認した外部状態を紐付けます。追跡に必要な識別子を失った場合も、成功扱いにせず確認不能として残します。
照会で未適用が分かっても、その間に別の担当者が予約を変更した可能性があります。再試行前に現在の予約内容と元の承認を照合し、内容や対象が変わっていれば再判断します。古い試験前提のまま更新を再開しないことも、返却形式変更後に点検すべき後続動作です。
どこを直すべきかを結果から選ぶ
試験結果は、契約解釈、引数、状態遷移、権限、副作用、説明の軸で分けます。acceptedを完了と読むならプロンプトと状態管理の修正候補です。必要なタイムゾーンを入力から確定できないなら確認質問や入力画面を直します。照会機能が呼べない場合は連携の実装や権限の問題であり、文言の追加だけでは解消しません。
| 確認した問題 | 修正候補 | 利用を再開するための確認 |
|---|---|---|
| 項目名を旧仕様で解釈する | ツール定義、変換処理、P8の説明 | 新旧の項目を混ぜず処理できる |
| 受付を完了と伝える | 状態分岐と報告条件 | 完了証拠が揃うまで断定しない |
| denied後に別経路で更新する | 権限制御、許可範囲、停止指示 | 回避操作が遮断される |
| タイムアウト後の状態を調べられない | 照会・追跡機能の整備 | 重複を避けて結果確認できる |
| 新しい状態値を解釈できない | 未知値の保留と仕様更新の手順 | 誤った成功判定に流れない |
すべての問題をプロンプトへ押し込めると、AIが指示を守ることだけに重要な境界を依存させます。権限、引数検証、重複防止、更新前の状態照合は、可能な範囲で実行側の制御にします。プロンプトはその制御の説明と、結果に応じた判断・報告を担うよう分けます。
合否は、通常成功の割合だけで決めません。重大な権限逸脱や重複の有無を別に扱い、結果不明を合格へ含めない設計にします。予定件数、実施件数、採点済み件数、未検証・判定不能を分け、反復試行の回数も記録します。試験基盤の故障は製品の誤動作と混同しませんが、都合よく除外せず理由を残します。
修正後は失敗したケースだけでなく、変更していない通常経路も再評価します。タイムアウトを慎重に扱う修正が、明確な成功まで保留する過剰停止を生んでいないかも確認します。調整に使った例だけの合格を一般化せず、別の予約ID、時刻条件、会話表現を含む保留評価集合で確かめます。
対応する版と未確認条件を残す
採用する組合せは「P8なら大丈夫」ではなく、T2、ツール定義の版、変換処理の版、モデル、P8、評価集合と判定基準の版で記録します。提供者側で段階展開され、旧新版が混在するなら、実際の返却形と版を見分ける方法も要ります。識別できないままAIへ二種類の説明を渡すだけでは、どちらの状態規則を適用するか決まりません。
管理記録には、変更点、対象業務、成功・拒否・結果不明の期待動作、確認できた範囲、残る問題、採用または保留の判断者を含めます。模擬試験だけ済んだ段階では「応答解釈を確認、実連携は未確認」と区別します。外部状態を実際に確認していないのに、業務完了を検証済みとは記しません。
利用再開の判断では、必要な失敗ケースと権限境界を確認できたか、未確認が残る用途を除外できるかを見ます。照会できず二重適用を防げない重要操作は、手動確認へ戻すなど範囲を限定します。提供者の追加変更、未知の状態値、想定外の再送が見つかったときは、対応版と判断基準を再び開きます。最終の評価記録には、返却の解釈だけでなく、状態照会と利用者への報告がどこまで確認できたかを残します。
モデル変更に備えたプロンプトの共通化と再評価は「モデル変更・ローカルLLM移行に備えたプロンプトの共通化と再評価」、MCPサーバーを更新するときの互換性の確認と戻し方は「MCPサーバー更新の互換性を確かめ検証済み構成へ戻す」で解説しています。
外部連携の廃止・仕様変更を監視し、移行まで管理する方法は「外部連携の廃止・仕様変更を監視し、移行まで管理する」で解説しています。
