エージェントが自分で改善するとき、それを信じてよいか判定する層がない

どんな問題か

エージェントが自らプロンプトを書き直し、新しいツールを足し、成功した軌跡をメモリに入れて次の判断へ反映する。ここまではもう現実だ。問題はその先にある。その「改善」が本当に改善なのか、誰が判定するのか。新版が請求問い合わせの精度を上げたとしても、その代償に返金の例外処理を静かに壊したかもしれない。もっと厄介なのはエージェントが自分自身を採点するときだ。自分に「合格」を出すが、それが能力の向上なのか採点基準を覚えただけの報酬ハッキングなのか、区別がつかない。いまチームが使っているのは事後のログを見せるオブザーバビリティ・ツールだけだ。何かが壊れたあとにダッシュボードで気づく。デプロイの前に「この自己改善を本番へ出してよいか」を自動で止める関門がない。

なぜ今か

自己改善そのものが急に当たり前になった。本番トレースから失敗事例を抜き出してプロンプトを自動更新するパイプライン、成功軌跡をメモリに蓄えるエージェント・フレームワーク、強化学習でツール使用を磨くループが、オープンソースで次々に出てくる。作る側は爆発したのに、制御する側は動いていない。DevOpsではカナリアデプロイと自動ロールバックが標準になったが、エージェントには対応物がない。コードのリグレッションはテストで捕まえられるが、「口調が微妙に攻撃的になった」「特定の顧客層でだけ判断が悪化した」といった能力のリグレッションはユニットテストをすり抜ける。さらにEU AI Actのように高リスクシステムへログ・人間の監督・変更履歴を求める規制が発効し、エージェントが自ら変わるたびに「何がなぜ変わり、どう検証したか」を証明する圧力が高まる。作りやすさの速度と検証の速度の差、その隙間こそ市場だ。

どう作るか

核心は自己改善をコードのデプロイのように扱うことだ。エージェントが新版を提案したら、そのまま本番へ出さず、三つの関門を通す。第一に、held-outゲーティング。エージェントが学習にも自己評価にも絶対に使えない評価セットを隔離しておく。採点基準を見せないことで報酬ハッキングを弾く。第二に、リグレッション検知。新版を旧版と並べて走らせ(shadowまたはA/B)、タスク種別ごとにスコアの変化を統計的有意性まで見る。全体平均が上がっても特定の区間が落ちていれば捕まえる。第三に、eval-as-CI。この評価を開発者のパイプラインへゲートとして埋め込み、通らなかった自己改善は本番昇格を自動で止め、直前の版へロールバックする。LangfuseやArizeのようなオブザーバビリティ・ツールの上に載る「判定・昇格・ロールバック」層として位置づければ、すでにトレースを溜めているチームへ自然に入り込める。

flowchart LR
  A[Deployed Agent] --> B[Proposes Self-Improvement]
  B --> C{Held-out Eval Gate}
  C -->|Pass| D{Regression Check}
  C -->|Fail| E[Auto Rollback]
  D -->|Clean| F[Promote to Prod]
  D -->|Regression| E

成功の条件

これは「また一つの評価ツール」になったら死ぬ。オフライン・ベンチマークを回す会社はすでに多い。生き残るには「本番で自ら変わるエージェント」という狭く熱い問題ひとつに絞ることだ。差別化は事前ゲーティングと自動ロールバックにある、事後のダッシュボードではなく、デプロイを止める関門だ。信頼の核はheld-outセットの無傷さなので、評価セットがエージェントへ漏れていないと証明する仕組みが製品の心臓になる。リスクも明白だ。LangChainやLangfuseのようなオブザーバビリティ基盤がこの機能を吸収すれば市場は狭まる。だから特定フレームワークに縛られない横断標準と、規制対応の証拠(何がなぜ変わり、どう検証したか)を自動で残すコンプライアンスの角度で防衛線を先に張る。誤検知が多くて健全な改善まで止めれば、チームはゲートを切ってしまう。統計的な厳密さと低い誤検知率が生存線だ。