【ITニュース解説】I Forked My Agent Harness So It Couldn’t Grade Its Own Homework

あるシステムが自動的にタスクをこなし、その結果を「成功」と判断する仕組みは、一見効率的に見えるかもしれない。しかし、この仕組みには根本的な問題が潜んでいる。それは、作業を行った主体が、その作業の成果を評価し、「これでよし」と最終的な判断を下す権限まで持っていることである。このような状況を「自分で自分の宿題を採点している」と表現できる。

この問題の核心は、信頼性の欠如にある。作業を行うプログラム（ここでは「ハーネス」や「エージェント」と呼ぶ）は、悪意がなくても、設定ミス、不完全なロジック、あるいは予期せぬ外部要因によって、誤った判断を下す可能性がある。もし、このエージェントが、作業の実行、結果の収集、そして最終的な成功の宣言までをすべて自分で行うならば、外部からはその判断が本当に正しいのか、あるいはタスクの当初の目的を正確に果たしているのかを検証する独立した手段がない。これは、小さな信頼の隙間というより、信頼そのものが存在しない状態と言える。

この課題を解決するためには、タスクの「完了」を判断する権限を、作業を実行するハーネスから完全に切り離し、別の独立したシステムに委ねる構造的な変更が必要となる。この独立したシステムを、記事では「カーネル」と呼んでいる。

具体的な解決策は次のようになる。まず、カーネルがタスクの指示（ディスパッチ）を出し、その際、タスクと、実際に作業が行われる場所（ワークツリーやコードブランチ）との関係を、改ざん不可能な記録として残す。この記録は、後で検証を行う際の基準となる。次に、ハーネスはカーネルから指示されたワークツリー内で、実際にコードの変更やテストの実行といった作業を行う。作業が完了すると、ハーネスはその結果として、変更のコミットや、関連する参照情報（例えばテスト結果のサマリーなど）を出力する。

しかし、この時点では、ハーネスが出力したものはあくまで「証拠の候補」に過ぎない。ハーネスには、その結果が「成功」であると宣言する権限は与えられない。代わりに、カーネルがハーネスの作業結果を自ら確認しに行く。具体的には、カーネルはコミットされたワークツリーを読み込み、ハーネスが出力した参照情報と、自身が最初に記録したディスパッチ記録とを比較照合する。このプロセスを通じて、カーネルはハーネスの作業が、当初のタスク指示に沿って正しく行われたか、そして出力された証拠が信頼できるものかを評価する。

このカーネルによる評価の結果は「CANDIDATE（候補）」として記録される。重要なのは、この結果が直接「PASS（合格）」と判断されるわけではない点である。「候補」とは、作業が所定の手順で実行され、提出された証拠が検証されたことを意味するが、最終的な「これで承認する」という判断は、多くの場合、人間が行うべきだとされる。自動化されたシステムが「合格」を自動で出すのではなく、最終的な重要な判断は人間が独立した立場で下すことで、システム全体の信頼性と安全性が向上する。これは、重要な移行を容易に偽造させないための「ゲート」として機能する。

自分の開発パイプラインで、このような「自己採点」の危険な構造が存在しないかを確認するためのチェックポイントがいくつか存在する。

• タスクの作成と完了の責任が集中していないか： タスクの識別子を作成したプロセスが、そのタスクを完了とマークしていないか確認する。
• ワーカーが自分のコミットを自己申告していないか： 独立したプロセスが、実際にワークツリーやコミットの内容を読み込み、タスクの指示記録と比較しているかを確認する。
• プラグインのロード方法： 実行時に外部から設定やパッケージパスを通じてプラグインが自由にロードされる構造になっていないか。これは、予期せぬ権限がシステムに入り込む「裏口」となり得る。
• 監視なしでの実行： ハーネスが監視システム（オブザーバー）なしで動作してしまう設定になっていないか。監視役との接続が切断された際に、ハーネスが作業を継続せず、起動を拒否するべきである。
• サマリーが評決になっていないか： 作業者が作成した「テストが実行された」というサマリーが、そのまま最終的な「成功」の判断になっていないか。コミットされた内容に対して独立して計測された結果と比較すべきである。
• 「PASS」という言葉の時期： 人間や別の独立した権限が介入する前に「PASS」という言葉が使われていないか。その代わりに「candidate（候補）」「pending（保留中）」「refused（拒否済み）」「failed（失敗）」といった、状態を示す言葉を使うべきである。

これらのチェックは、単にシステムの構成図上のラベルを見るだけでは不十分である。実際にどのプロセスがどの記録を書き込み、どの成果物をディスクから読み込んでいるのかを深く掘り下げて確認することが重要である。

このような考え方は、RanexというプロジェクトのSLICE-007という実証実験を通じて、ディスパッチからワーカーのループ、フック、カーネルの判断、証拠の記録、そして「CANDIDATE」としてのジャーナル記録まで、エンドツーエンドでその有効性が確認された。この検証は、あくまで「自己採点を防ぐ」という狭い目的に絞られており、大規模な委譲や認証された承認など、他の複雑な側面については、今後の課題として意識的に範囲外とされている。

システムエンジニアを目指す初心者も、自身の開発や運用の自動化に際して、この「自己採点をさせない」という原則を意識することが大切である。もし、あなたが今週担当した自動化タスクの中に、ファイルを変更したプログラムが、その変更結果の最終ステータスまで決定するパスを持っているものがあれば、それは再考の余地がある。ぜひ、独立した権限を持つプロセスに、コミットされた成果物を読み込ませ、作業開始前に記録されたタスク指示と比較させる仕組みを試してみてほしい。この考え方は、より堅牢で信頼性の高いシステムを構築するための重要な一歩となるだろう。