エージェントの合格規則が間違っていたら

Google の2026年10月28日付 Agents CLI ガイドは、評価の入力と期待結果を別々に版管理することを勧めている。この提言は Google によるもので、本稿の独創ではない。原文

私たちの問いは、さらに厄介な発見の後から始まる。合格の規則自体が間違っていたら、どうするのか。業務上は許してはならない操作を、エージェントが実行すると高く評価していた可能性がある。規則を直せば、昨日の行動を変えずに昨日の点数が下がり得る。新しい点数だけでは解決できない後始末が見つかる場合もある。

Open Market Notes は、架空の設備保守フローを使ってこの問題を考える。以下は独自の運用提案であり、測定済みの実験でも、Google の稼働中システムに関する記述でもない。

一つの訂正を必要とする二種類の読者

設備の保守作業票を準備するアシスタントを考えよう。最初の評価では、作業票が完成していれば成功とする。その後、特定の制限区域での作業には事前承認が必要だと業務側が認識した。この種の作業票をすばやく完成させるエージェントは、旧テストに合格しながら、本来維持すべき操作の境界を越えていたかもしれない。

一方の読者は次の版を選ぶ技術チームであり、もう一方は処理済みの仕事に責任を持つ業務責任者である。前者には将来の合格規則が必要で、後者には過去の出力が境界を越えたかどうかの確認が必要だ。両方をプロンプト調整の課題として扱うと、後者が未回答のままになりかねない。

この発見だけで実際の事故が起きたとは言えない。作成した作業票は未送信かもしれず、人が却下したかもしれない。外部への影響がない模擬テストだった可能性もある。最初にすべきは、証拠がどの状態を支持するかを確かめることだ。評価の失敗を、そのまま業務上の損害が生じたという断定に変えてはならない。

過去の結果を残し、新しい判断を付け加える

CLI の文書では、エージェントを再実行せずに保存済み軌跡を再採点できる。評価文書

私たちが提案する訂正記録は、元の結果を当時の意味とともに保存し、改訂後の判断と変更理由を追加する。正しい規則が最初から存在したように過去を上書きしない。古い「合格」は旧テストの報告として正確でも、業務上適切な行動の証明には不十分だった、と読者が理解できる必要がある。

この区別は責任にも関わる。開発者が明文化された要件を無視したとは限らない。要件が存在しなかったか、曖昧だった可能性がある。逆に、テスト項目の欠落は、既知の業務制限を無視する許可にはならない。製品が求めたこと、テストが実際に確認したこと、運用者が行ったことを分けて残す。ラベルの変化だけから誰の責任かを推定することはできない。

記録が答えられる反実仮想を問う

有用な橋渡しには二つの部分がある。保存されたやり取りの再評価は、新規則がこの観測済みの行動を許すかを問う。修正したエージェントでケースを再実行する場合は別の問いになる。再構成した条件の下で、提案する修正が適切な次の行動を生むか、という問いだ。

両者は置き換えられない。新版が承認を求めても、旧版が当時そうしたことは証明できない。承認が実際に得られたはずだとも言えない。過去の軌跡に最終作業票の要約しか残っていなければ、権限記録の欠落は未確認を意味するかもしれず、単なる記録漏れかもしれない。利用権限のある別の記録で解決するまでは、その違いを未確定として残す。

したがって、この例の修正目標は限定すべきだ。承認の境界で停止し、足りない許可を示すことである。想像上の承認結果を採点してはならない。後続の業務判断を作り上げなくても、システムが制御できる次の一手を確認することはできる。

再構成の境界も明示する必要がある。現在の設備記録には、元の依頼より後の変更が含まれているかもしれない。それで再実行することは今日のフローの確認には役立つが、旧エージェントが当時知っていた情報を再現しない。過去の入力を得られないなら、そう明記し、もっともらしい物語で空白を埋めるのではなく、遡及的な結論を狭く保つべきだ。

技術的な修正と業務上の終結は違う

改善したプロンプトは将来の行動を変えられる。しかし、送信済みの作業票を撤回したり、関係する監督者に知らせたり、作業が始まったかを確定したりはできない。それらは権限を伴う業務処理の仕事であり、評価スクリプトが独自に決めてよいことではない。

架空の保守チームでは、訂正記録を別の処理状況に結び付ける。外部操作は発生しなかった、権限を持つ担当者が作業票の妥当性を確認した、作業票を撤回した、または未解決、という分類が考えられる。これは提案する分類であって、観測された出来事ではない。「次の版で修正済み」を「過去の影響も解決済み」と取り違えないことが目的だ。

反対のリスクもある。遡及調査を広げすぎると、緊急の修正に必要な資源を消費する。釣り合いの取れた対応は、新たに特定した制限、関係する期間、観測可能な外部操作に重点を置くことだ。過去のすべての失敗に同じ調査が必要だと決め付けない。明確な責任者が範囲の妥当性と残る不確実性を説明する必要がある。

高い点数を追う前に完了を定義する

提案する手続きでは、改訂テストへの合格だけで訂正は完了しない。業務責任者が正しい規則を認め、技術側が許された次の行動を示し、権限のある担当者が過去の案件を解決するか、未処理分の責任を明示的に引き受ける。それぞれの確認が別の問いに答える。

この設計にも限界はある。業務記録へのアクセス制御、妥当な保存方針、曖昧な証拠を確認する時間が必要だ。ツールやモデルが変われば、厳密な再実行は不可能かもしれない。それは結論を限定する理由であり、近似的な再構成を確実な事実として示す理由にはならない。

実務上の利点は、システムの改善と、過去にシステムについて下した判断の訂正を明確に分けられることにある。採点規則はすぐ直せる。しかし信頼を回復するには、訂正によって何が確かになり、何が分からず、残る仕事を誰が引き受けるのかまで説明する必要がある。