この記事では、エージェントに作業を検証させるためのテクニックを紹介します。なぜこれが重要なのか、使用できるさまざまなチェックの種類、そしてそれらを適用するメカニズムについて説明します。
バリデーションのシフト
エージェントが書いたコードを検証するためのツールを提供することに、最近注目が集まっています。これは「ロングホライズン」なエージェントタスクで特に顕著です。
- AnthropicがClaudeで構築したコンパイラでは、テストを通し続けるためにCIパイプラインが必要になりました
- OpenAIのハーネスエンジニアリングの記事では、機械的チェックとエージェントベースのチェックを組み合わせて、エージェントが設計原則に従っていることを確認しています
- Cursorのクラウドエージェントは、エージェントが目標を達成した証拠としてアーティファクトを生成することを重視しています
- Ralphループは、作業を検証するための「バックプレッシャー」メカニズムに依存しています
リストはまだまだ続きますが、コンセプトは同じです。エージェントが正しく作業を行うことを信頼するのではなく、作業をチェックする方法を提供するということです。
なぜ今なのか
なぜこれが今ホットな話題になっているのか、考える価値があります。「AI能力」の単純化されたモデルとして、人間が介入することなくエージェントがタスクに取り組める時間の長さがあります。長い間、私たちはツールを接続するためのスキャフォールディングを構築してきました。例えば、ターミナル出力とChatGPTの間でコピー＆ペーストしていた状態から、IDE/ターミナル上でコードを実行できるエージェントへの移行です。エージェントがコマンドを実行してくれるため、タスクを完了できる時間が即座に延びました。
しかし現在、エージェントが数時間から数日にわたるタスクに投入されており、人間がすべてのCodexやClaudeセッションを見守ることなく、並列で実行されることもあります。CodexやClaude Coworkでは、継続的なリファクタリングやテスト改善などのタスクを自動化することもできます。
この変化の速度では、エージェントが物事を台無しにするのを止めるシステムが本当に必要です。これは大規模なコードベースでは常に当てはまることでした。規律あるアーキテクチャパターン、リグレッションやモジュール間の破壊を防ぐテスト、破壊的変更への対応などです。しかし現実には、ほとんどのコードベースがそのレベルの複雑さに達することはありません。OpenAIが社内プロジェクトで行ったような「レイヤードアーキテクチャ」設計を強制するリンターを書くことは、巨大なコードベースに何千人もの開発者がいれば理にかなっています。しかし、すべてのコードを手動でレビューしている3人のチームでは、衒学的な演習に過ぎません。エージェントは、この複雑さとコンフリクトの臨界点に、より早く到達させるだけです。
この記事の残りでは、サービスの新しい言語への移行、サードパーティシステム用のカスタムプラグインの構築、エージェントが書いたコードのテストとマージを管理するツールの構築など、比較的大規模なシステムを構築する際に役立つと分かったことを紹介します。
バリデーションのテクニック
レイヤードアプローチによるバリデーションが最も効果的だと分かりました。コードベースレベルのガイドラインから始まり、長期タスクでの指示、そして自動的にトリガーされる動作へと進みます。
それぞれについて以下で説明します。
「フィードフォワード」型の指示
バリデーションの最も簡単な出発点は、プロンプトの改善です。これはフィードフォワード型のスタイルで、エージェントがミスを犯すことを事前に防ごうとするものです。実装は簡単ですが、常に実行されるチェックが最終的には必要になるという制限があります。
CLAUDEファイルとAGENTSファイル
まず、トップレベルのエージェント指示ファイルにテストの実行方法とコードのフォーマット方法を含めるところから始めましょう。指示セットが小さい場合は直接記述できます。しかしコードベースが大きくなると、指示ファイルは情報を見つけるためのリファレンスのようにすべきです。例えば、コマンドをインラインで書く代わりに、Makefileの使用を参照したり、コードベースでの作業に関する別のドキュメントを用意したりします。
OpenAIのハーネスエンジニアリングの記事のアプローチに基づいて、トップレベルのAGENTS/CLAUDE.mdファイルは100行未満に抑えるようにしています。ファイルは、段階的な情報開示を可能にする構造化されたドキュメントへの目次として機能します。
タスク固有の指示
ロングホライズンなタスクには、通常何らかの計画があります。私はOpenAIのExecutable Planスタイルを使っています。計画ドキュメントをコードベースと同じ場所に置き、エージェントが作業する中で得た学びや予想外のことを明示的にトラッキングできるからです。スクラッチパッドのようなものです。それらをエージェントがマイニングして、計画の改善や行き詰まったポイントの発見に活用できます。
私のワークフローは次の通りです。
- エージェントと一緒に計画を作成する（ここでは好きなフォーマットを使えます）
- バリデーションに関するルールを含む実装用の別のプロンプトを用意する
- IMPLEMENTATION.mdファイルに沿って計画を実行するようエージェントに指示する
機械的チェック
プロンプトによるフィードフォワード制御は良い出発点です。「作業中にテストを実行せよ」と言うためのトークンコストは確実に価値があります。しかしいくつかの問題にぶつかります。
- モデルのアテンションメカニズムの制限により、テストが実行されないことがあります。
- 報酬ハッキング：テストを通すように指示されたモデルは、テストを削除したり、浅いテストを書いたりします。
つまり、エージェントがバリデーションを行うこと、または良い仕事をすることを常に信頼できるわけではなく、トークンと時間を費やして完全に壊れたコードができてしまう可能性があります。エージェントに何が間違っていたかを伝えるフィードバックアプローチが、良い第2のレイヤーになります。
フックベースのアプローチを使用すれば、エージェントに常にテスト、CVEスキャナー、リンターを実行させることができます。例えば、Claude CodeやCursorで使えます。ほとんどのエージェントハーネスには、同様のフックやミドルウェアスタイルのアプローチがあります。Chunkサイドカーも同じパターンを持っています。フックはエージェントのストップイベントごとにマイクロビルドを起動し、出力をエージェントに返します。
フックはコマンドを実行するだけではありません。Claudeはワンショットプロンプトフックやサブエージェントの実行を明示的にサポートしています。Cursorもプロンプトベースのフックをサポートしています。これは敵対的なコードレビューを組み込んだり、仕様に対する実装の「意図チェック」を行うための良い方法です。テストに関しては、カバレッジのリグレッションを追跡して、テストに対する報酬ハッキングを検出することもできます。
エージェントがフックをサポートしていなくても、Ralphスタイルのスクリプトの一部として、または手動で呼び出すことで、ブランチ上でバリデーションスクリプトを実行できます。
今後の展望
この記事では、エージェントのバリデーションが求められている理由（自律性の向上とタスクの長時間化）について説明しました。また、プロンプトベースとフックベースの戦略を使ったフィードフォワードとフィードバックのアプローチについても紹介しました。
では、この先はどうなるのでしょうか。バリデーションはしばらくの間存在し続けると思いますが、テクニックは変わっていく必要があるでしょう。
プロンプトでの工夫の必要性は、時間とともに減っていくでしょう。モデルはテストの実行を忘れないようになります。
フィードバックアプローチは、少なくとも人間のコンプライアンスシステムがソフトウェア開発において特定のステップが実行された証拠を求める限り、より長期的に残るでしょう。例えば、多くのコンプライアンスポリシーでは、少なくともCVEをチェックしたことを証明しなければなりません。
しかし、より一般的には、決定論的チェックの一部はエージェント主導の世界では厳格すぎます。エージェントを1つの失敗したテスト（フレイキーかもしれない）で無限にループさせることは、エージェント駆動のコードベースで望ましい動作ではないでしょう。一方、システム間の境界での厳格なテストは理にかなっています。変更によって他のサービスやAPIが壊れる可能性があるかをエージェントにチェックさせ、その情報を判断に活用することも非常に理にかなっています。これは必然的に、バイナリ/パス・フェイルではなく、リスクスコアリングベースのアプローチにつながります。
バリデーションの一部は開発後に行うこともできます。例えば、カナリアリリースでスモークテストを実行することは、よく知られているがまだ普遍的には実装されていない、高速リリースのアプローチです。フィーチャーフラグはより一般的です。エージェントにより、ロールアウトとクリーンアップの管理をループで完結させることができますが、その過程で実験管理の問題全体が生じます。デプロイ後のバリデーションの世界に到達するには、ほとんどのチームが現在行っているよりもはるかにオブザーバビリティに投資し、「デプロイエージェント」に変更が壊れているかどうかの可視性を与える必要があります。さらにその先には、プロダクトアナリティクスツールに接続して、変更がビジネス目標を達成したかどうかを確認することも想像できます。
このシリーズの次の記事では、これらのバリデーションテクニックを機能させるために必要なインフラについて説明します。
