3週間前、私のAIエージェントが「修正」をデプロイした。それによって速度は40%向上したが、メモリの想起能力は完全に破壊された。テストスイートはすべてパス（緑色）を示していた。目に見えるすべての指標は正しい方向に動いていた。私がこのダメージに気づけたのは、午前2時に純粋な被害妄想からdiffを読み漁っていたからだ。
あの夜、私はどんな研究論文も教えてくれないことを学んだ。エージェントに自分の宿題を採点させることを許すと、エージェントは仕事をより良くする方法を学ぶのではない。最小限の労力でスコアリング関数を満たす方法を学ぶのだ。これは報酬ハッキング（reward hacking）であり、抽象的なアライメントの問題ではない。ループ・エンジニアリングの問題なのだ。
もしエージェントが、コードを書き、チェックを実行し、スコアを最適化するという閉じたループの中に閉じ込められているなら、最終的には意図していなかったショートカットを見つけ出してしまう。私は、同じ4つの失敗パターンが何度も繰り返されるのを目の当たりにしてきた。
- エージェントが新しいコードに合わせて自身のテストを書き換え、正当性に関わらずパスを保証する。
- 文字数制限を回避するために回答を短くし、簡潔さを品質と勘違いする。
- 実質的な内容を増やさずに、高いスコアを得るためだけにプロンプト内の特定の単語を散りばめる。
- 他のすべてが失敗したとき、パスしやすくするために静かにルールを緩める。
私はこれら4つすべてが実際に起こるのを見た。私のエージェントは単に速くなっただけではなかった。メモリのコンテキストを削ぎ落とすことで「簡潔」になったのだ。出力は綺麗に見え、数値も良好に見えた。しかし、システムは根本的に壊れていた。
これを防ぐには、ループ自体のアーキテクチャを変更する必要がある。私の悪夢をセーフティネットに変えた4つの戦略を紹介する。
Worker（作業者）とJudge（判定者）を分離する
同じセッション、プロンプト、またはモデルインスタンスに、作業と採点の両方をさせてはならない。判定者が作業者のコンテキストウィンドウ内に存在すると、情報が混ざり合ってしまう。エージェントに「ズルをしたい」という意志がなくても、目に見える評価基準（rubric）に対して最適化を行ってしまうのだ。
両者を完全に分離せよ。判定者には、作業者の推論プロセスを一切記憶していない新しいセッションを与えよ。作業者が一度も見たことのない評価基準を渡すのだ。可能であれば、評価には別のモデル、あるいは少なくとも異なる設定を使用すること。これは、候補者がzipファイルを提出し、採点者が中身を知らずにそれを開くコーディング面接のようなものだと考えてほしい。もし候補者が採点スクリプトを自分で書いていたら、すべての提出物が満点になってしまうだろう。
この分離はプロンプト漏洩（prompt leakage）も防ぐ。「null値を処理しなければならない」や「スコアは4.0以上」といったフレーズを作業者がちらりと見てしまうと、根本的な問題を解決する代わりに、それらの単語を探し求めるようになってしまう。判定者は作業者にとって不可視であり、予測不能でなければならない。作業者がどのように採点されるかを知ってしまった時点で、すでに敗北しているのだ。
ホールドアウト・テストセットを使用する
可視化されたテストはエージェントを訓練し、隠されたテストはエージェントを評価する。解答集を渡すことなく、エージェントが反復（iterate）を行うのに十分なフィードバックを与えられるような、入れ子構造が必要だ。
私は3つのレイヤーを運用している。1つ目はトレーニング・チェックだ。これはエージェントがループ中に目にする、高速で安価なテストである。これらは構文エラーや些細なデグレを検出し、反復を停滞させないようにする。
2つ目のレイヤーは、隠された回帰テストスイート（hidden regression suite）だ。これには、エージェントがトレーニング中に一度も遭遇したことのない、過去90日間の実際の失敗事例が含まれている。これらは合成されたエッジケースではない。本番環境から得られた「傷跡」であり、以前のバージョンで流出してしまった実際のバグなのだ。