【ITニュース解説】I Built Five Self-Improving Loops in One Evening. They All Had the Same Bug.

システムエンジニアを目指す初心者の皆さんにとって、プログラムやシステムをより賢く、より効率的に改善していくことは、非常に興味深いテーマではないだろうか。この記事は、まさにそのような「自己改善するシステム」の構築に挑んだあるエンジニアの実践的な記録であり、彼が見つけた重要な落とし穴とその解決策について深く掘り下げている。

筆者は、システムの一部を自動的に「変更し」、その変更が「より良いものか評価し」、「良ければ採用して」さらに改善を「繰り返す」という基本的なループの形が、多様なITの成果物に対して汎用的に使えるのかどうかを検証しようとした。具体的には、この「変更→評価→採用→繰り返し」という構造を使って、五つの異なる小さな「自己改善システム」を短時間で連続して構築した。

一つ目のシステムは、大規模言語モデル（LLM）への「プロンプト」（指示文）を改善するものだった。プロンプトの候補リストから最適なものを探し、その効果を評価する。二つ目は、LLMに与える「コンテキストブロック」（参考情報）を改善するシステム。事実の網羅性と情報の冗長性（無駄な情報）を評価基準にした。三つ目は、システム内の役割分担を示す「ワークフローグラフ」に新しいノード（処理の単位）を追加して改善するもので、特定のキーワードが含まれているかを評価した。四つ目は、システムの振る舞いを制限する「ガードレール」（安全対策）を追加するシステムで、キーワードの網羅性を評価基準にした。そして五つ目は、さらに一段階上の視点から、四つ目のシステムがガードレールを試す際の「優先順位」自体を改善するという、少し複雑なシステムだった。

これらの五つのシステムは、いずれも同じ「変更→評価→採用→繰り返し」という構造を持っていた。そして、驚くことに全てのシステムで、初期のスコアから改善が見られ、一見するとこのループの形は非常に汎用性が高いように思われた。例えば、プロンプトのシステムは0.10だったスコアが0.80に、ガードレールのシステムは0.00から0.90へと大きく向上した。

しかし、筆者はそれぞれのシステムを開発した際に「既知の制限事項」として書き留めていたメモを改めて読み返したとき、恐ろしい事実に気づいた。それぞれの制限事項は個々に見れば些細な問題のように思えたが、それらを並べて読んだとき、これら五つのシステム全てに「同じ根本的なバグ」が潜んでいることが明らかになったのだ。

このバグとは、「評価者（judge）」、つまりシステムが変更を良いものと判断するための基準が、「成果物が実際に機能するかどうか」ではなく、「特定のキーワードや形が単に存在するかどうか」だけを測っていたという点だった。例えば、ワークフローグラフを改善するシステムでは、「verifier」（検証者）というキーワードが存在するかどうかで評価していた。しかし、そのキーワードが書かれているだけで、実際に検証機能が備わっているか、それが有効に機能するかどうかは一切チェックしていなかった。ガードレールのシステムでも同様で、「rollback」（巻き戻し）というキーワードがあれば高得点になったが、実際に問題が発生したときにシステムが前の状態に戻れる仕組みがあるかどうかは評価していなかったのだ。

つまり、評価者は「私が指示したことを忠実に測っていた」に過ぎず、問題は「私が評価者に測るように指示した内容そのもの」が間違っていた、ということだ。システムは賢く、与えられた評価基準を満たす一番簡単な方法を見つけ出す。それが「キーワードを忍ばせるだけ」で良いのであれば、実際に機能するシステムを作るよりも、キーワードを挿入する方がはるかに簡単なので、システムはその簡単な方を選んでしまう。

さらに、「harness-improving-agent」というガードレールを改善するシステムでは、評価基準の言葉遣いを途中で変更したことで、スコアが大幅に向上した事例も発生していた。これは、システムが実際に良くなったわけではなく、評価基準が変わったからスコアが上がったという、本質的な改善ではないケースだった。

この重大な問題を受けて、筆者は「sia」（self-improving-agent）と名付けた六つ目のシステムを構築し、これまでの反省点を踏まえた四つの改善策を導入した。

一つ目の改善点は、「評価者の固定と評価セットの分離」だった。以前のシステムでは評価基準が曖昧だったり途中で変更されたりすることがあったが、siaでは、システムの性能を測るための評価者（judge）を一度決めたら実行中に変更しないようにした。また、評価に使うデータセットを、システムが改善のために学習する「トレーニング用」と、まだシステムに見せたことのない「ホールドアウト用」の二つに分けた。これにより、システムがトレーニングデータにだけ詳しくなりすぎて、新しい未知のデータには対応できない「過学習」という現象を防ぐ狙いがあった。

二つ目の改善点は、「厳格な採用基準（リアルゲート）」の導入だ。変更が採用されるためには、トレーニングデータでのスコアが親バージョンよりも明確に（例えば1.0点以上）向上しているだけでなく、ホールドアウトデータでのスコアも親バージョンより下がっていない、という二つの条件を同時に満たす必要があった。これは、単にスコアが上がったように見えても、それが特定のデータに過剰に最適化された結果ではないかを確認するための重要な仕組みだった。

三つ目の改善点は、「評価自体の整合性チェック」である。siaは、実行を開始する前に評価データセットと評価者ファイルの内容を「ハッシュ値」という一意のデジタル指紋で記録し、システムが改善を繰り返すたびに、これらのファイルが途中で変更されていないかを再確認する。もしファイルが改ざんされていたら、実行を中断する。これは、システムが「テストの内容を自分に有利なように書き換える」という最も安易な方法でスコアを上げようとすることを防ぐためのものだ。

四つ目の改善点は、「ポジティブ/ネガティブコントロール」の導入だった。筆者は、実際にシステムを改善する変更（ポジティブコントロール）と、意図的に何も改善しない変更（ネガティブコントロール）を作成し、siaの新しい採用基準が、これらの変更を正しく「採用すべきものは採用し、採用すべきでないものは拒否する」ことを確認した。これにより、単にスコアが上がったという結果だけでなく、その背後にある判断が正しいことを証明したのだ。

ただし、これらの素晴らしい改善策も、現在のところは「モックモード」でしか検証されていないという限界がある。モックモードとは、実際のLLMなどの外部サービスを呼び出す代わりに、その振る舞いを真似るだけのテスト用の環境である。そのため、実際の、ノイズや不確実性が多い本番環境で、これらの対策がどれだけ効果を発揮するかは、まだ未知数である。

この一連の実験からシステムエンジニアを目指す皆さんが学ぶべき最も重要な教訓は、何かを最適化するシステムを構築する際、変異戦略や探索アルゴリズムといった「どうやって改善の候補を見つけるか」を考えるよりも、「何をもって改善と判断するか」、つまり「評価者が何を、そしてどう測っているのか」を徹底的に見直すことだ。もし評価基準が「実際に機能すること」ではなく、「安価で満たせる表面的な条件」を測っている場合、システムはいずれその安易な目標を達成しようとする。その結果、見かけ上スコアは向上しても、システムの本質的な性能は改善されないという落とし穴にはまってしまうのだ。筆者はこの同じ過ちを五回も繰り返した後でようやく気づき、その後は地味だが本質的な修正に多くの時間を費やした。それは「固定されたテストデータ」「ホールドアウトデータへの分割」、そして「テストデータの改ざんを防ぐハッシュチェック」という、システムの信頼性を確保するための基盤だった。