自律的なコーディングは、より優れたプロンプト作成から、より優れた制御システムへと移行しつつあります。重要な変化は、エンジニアがエージェントを目標、評価器、ループ、成果物で包み込み、人間が入力を止めた後もエージェントが動作し続けられるようにする方法を学んでいることです。
これは、ほとんどの本格的なエンジニアリング作業が長い時間軸で行われるからです。つまり、曖昧な要件、隠れた制約、部分的な失敗、変化するコンテキスト、繰り返しの検証が伴います。新しいフロンティアは、エージェントを中心にシステムを設計し、エージェントが計画し、実行し、自身の作業を確認し、ミスから復旧し、人間による絶え間ない操作なしに進捗を続けられるようにすることです。
この記事は、[DAIR.AI Academy の自律的な長時間実行コーディングエージェントに関するセッション](https://academy.dair.ai/events/cmplo7v3b000e04l1pxprat4d)に基づいており、Claude Code の [/goal](https://code.claude.com/docs/en/goal) モード、新しい [/loop](https://docs.anthropic.com/en/release-notes/claude-code) コマンド、検証器、成果物、および実際のオーケストレーションパターンについて説明しました。Codex および Claude Code との協力により作成されました。*
プロンプトから目標設計へ
Claude Code の /goal のような機能の背後にある核となる考え方はシンプルです。コーディングエージェントは依然として実行者ですが、人間はもはやターンごとにエージェントと対話しません。代わりに、人間は望ましい最終状態、成功を証明するために必要な証拠、違反してはならない制約、可能であればターン数と予算を指定します。
その目標は、長いプロンプトというよりも、むしろ契約のように機能します。弱い目標では、モデルが早期に停止したり、近道を取ったり、トランスクリプト上ではもっともらしく見えても実際のシステムでは失敗する方法で成功を再定義したりする余地が生まれます。強い目標は、エージェントが繰り返し自身を測定できるターゲットを提供します。
ここでもエンジニアリング的判断が重要です。最良の目標は、モデルが推測するであろうドメイン知識をエンコードします。研究実験の場合、それはターゲットとなるベンチマークスコア、保持された評価、必要な損失曲線、および結果が初期ベースラインを上回らなければならないというルールを意味するかもしれません。UI タスクの場合、スクリーンショットの参照、具体的なレイアウト制約、ブラウザでの検証ステップを意味するかもしれません。モデルは実行できますが、「完了」の実際の意味を定義するのは人間です。
評価器が第一級のコンポーネントに
長時間実行エージェントには、目標に加えて第 2 の役割が必要です。その評価器は、別のコーディングエージェント、LLM-as-judge、スクリプト、テストスイート、ベンチマークハーネス、またはそれらの組み合わせのいずれかになります。重要な設計上の選択は、評価器をタスクに合わせることです。成功が明確に定義されている場合、決定論的なチェックの方が適しています。型チェック、単体テスト、リンタールール、統合テスト、ベンチマークスクリプトは、条件を明確に表現できる場合は常に使用する必要があります。
成功が曖昧な場合、エージェント評価器が有用になります。スクリプトはテストが合格したかどうかを教えてくれますが、生成された研究レポートが一貫しているかどうか、実装が論文に忠実に従っているかどうか、UI が設計意図に一致しているかどうかを簡単に判断することはできません。ここで、評価器は言語、判断、場合によっては視覚の恩恵を受けます。
実際的なパターンは、決定論的なチェックをベースラインとし、エージェント評価をより高レベルのレビューとして使用します。この組み合わせにより、幻影的な成功を減らしながら、テストアサーションにきれいに適合しないタスクでも自律性を可能にします。
検証器が信頼の境界を定義する
より深いポイントは、システムが信頼できる検証器を持っている場合にのみ自律性が機能するということです。コーディングエージェントは計画を生成し、機能を実装し、なぜ作業が完了したと信じるかを説明できますが、その説明を証拠として扱うべきではありません。証拠は、エージェントが容易に回避できない外部チェックから得られます。
コードの場合、検証器はテストスイート、型チェッカー、ベンチマーク、ブラウザ実行、スクリーンショット比較、再現可能なスクリプトなどです。研究作業の場合、保持された評価、再現されたテーブル、損失曲線、ベースラインを改善するベンチマークスコアなどです。デザイン作業の場合、参照スクリーンショットと視覚的なレビューステップかもしれません。検証器は、自信過剰なテキスト生成器を、より多くの時間を任せられるシステムに変えるものです。
ほとんどの近道はこの境界で発生します。検証器が曖昧だと、モデルはタスクの最も簡単な解釈を満たそうとすることがよくあります。検証器が狭すぎると、モデルはそれに過適合し、より広い意図を見逃す可能性があります。したがって、優れた自律ワークフローには、安価な決定論的チェックが基本的な失敗をキャッチし、高レベルのレビューが判断に依存する重大な失敗をキャッチする、階層的な検証が必要です。最先端のモデルの中には、ある程度の検証を達成できるものもありますが、私の調査によると、エージェントに割り当てる検証タスクが学習分布の外にある場合、モデルが著しく苦戦するという明らかな OOD 問題がまだ存在します。
検証器はまだ研究が進んでいる分野ですが、多くの企業がこの分野に巨額の投資を始めるだろうと予想しています。ファインチューニングされた検証器の概念は、エンタープライズでも高い需要があります。
ループが自律性を持続可能にする
目標はエージェントに方向性を与えますが、ループは作業を存続させます。この区別は重要です。なぜなら、モデルは実際のタスクが完了する前に停止することが多いからです。ターン制限に達したり、自信を失ったり、コンテキストを使い果たしたり、部分的な解決策で十分だと判断したりする可能性があります。
ループは外部の制御システムです。起動し、進捗を検査し、チェックを実行し、結果を目標と比較し、目標が達成されていない場合には次の指示とともにエージェントを送り返します。最も単純な形式では、これはコーディングエージェントと決定論的条件を用いた Ralph ループパターンです。より柔軟な形式では、進捗について推論し、次に何が起こるべきかを決定できる評価エージェントをループに含めます。
長時間実行の自律性は、制御層による監督下での反復的な努力として機能し、1 回の継続的な知能の行為ではありません。エージェントは依然として失敗する可能性がありますが、ループはシステムに失敗を認識させ、静かに勝利を宣言する代わりに継続する方法を提供します。
計画は専門知識が入る場所
セッションで最も強く示されたテーマの 1 つは、計画が依然として重要であることです。最先端のモデルに計画を生成させることはできますが、自律ループにタスクを渡す前に、それを検査し、前提に挑戦し、成功基準をより明確にする必要があります。
これにより、有用な役割分担が生まれます。より強力な計画モデルは、目標の定義、欠落した制約の特定、評価の構造化に役立ちます。計画が明確になったら、異なる実行モデルが実装を実行できます。実際には、エンジニアは「モデル」を単一の選択肢として考えるのをやめるべきです。モデルの選択はアーキテクチャ上の決定になります。
計画が得意なモデルもあれば、実行が得意なモデルもあります。安価な評価器として適したモデルもあれば、視覚ベースのレビューが得意なモデルもあります。優れたオーケストレーターを使用すると、1 つのベンダーが完璧なコーディングエージェントインターフェースを提供するのを待つのではなく、これらの役割を交換できます。
視覚的な成果物が制御面になる
多くのエージェントが実行されている場合、ターミナルトランスクリプトはスケールしません。複数のセッションが並行して動作するようになると、生のテキストは進捗を理解するための貧弱なインターフェースになります。
ライブの成果物が重要です。損失曲線、ベンチマークスコア、タスク状態、スクリーンショット、コスト見積もり、最近の決定を示すダッシュボードがあれば、人間は自律性を監督するためのはるかに優れた方法を得られます。成果物は、事後的に生成されるレポートではなく、介入すべきかどうかを決定するための制御面になります。
最も有用なパターンは、ストレージとプレゼンテーションを分離することです。Markdown またはボールトは、永続的な証拠、ログ、メモ、計画、結果を保存できます。HTML 成果物は、その状態を視覚的でインタラクティブなものにレンダリングできます。エージェントは Markdown を検索し、人間は成果物を監視できます。
UI やプロダクトの作業では、視覚的な手がかりが特に強力です。スクリーンショットの参照は、散文よりも正確に設計意図を伝えることができ、視覚認識機能を持つ評価器は、実装をその参照と比較できます。これにより、エージェントが要求されたコンポーネントを技術的に実装しても、スペース、階層、配置、プロダクトの感覚を逃すという一般的な失敗モードが減少します。
セッションマイニングで使用状況を記憶に変える
もう 1 つの重要な洞察は、過去のエージェントセッションがワークフローデータの豊富な情報源であることです。エージェントが同じ方法で繰り返し失敗したり、同じチェックを実行し忘れたり、間違ったパスを使用したり、同じ壊れたコマンドを再試行したりする場合、そのパターンをログに埋もれさせてはいけません。
セッションマイニングは、それらのトランスクリプトを運用ルールに変換します。エージェントは過去 30 日間の作業をスキャンし、繰り返される失敗モードを見つけ、プロジェクト指示、ボールトの学習内容、またはエージェントルールの更新を提案できます。これにより、チームはすべてのミスを手動で記憶することなく、徐々にハーネスを改善できます。
目標は、モデルをゼロからトレーニングすることなく、ローカル環境をよりスマートにすることです。エージェント指示ファイルの小さなルールで、将来のセッション全体にわたって繰り返される失敗を防ぐことができます。特に、そのルールがプロジェクトに固有のものである場合に効果的です。
実用的な運用モデル
AI エンジニアにとって、新たなワークフローは次のようになります。
- 完全な自律実行を開始する前に、小さくて安価なサブセットから始める。
- 測定可能な成功基準、明示的な制約、可能な場合はターン数または時間予算を設定した目標を作成する。
- 実行器と評価器を分離し、実装と判断が 1 つの役割に統合されないようにする。
- 長時間実行ループを開始する前に、外部の検証器を定義する。
- 可能な限り決定論的チェックを使用し、その後、曖昧な基準に対してエージェントレビューを追加する。
- ログ、スクリーンショット、ベンチマーク曲線、変更されたファイルなどの証拠成果物を要求する。
- 過去のセッションをマイニングし、繰り返される教訓をプロジェクト指示に昇格させる。
これが、コーディングエージェントを使用することと、自律的なコーディングシステムをエンジニアリングすることの違いです。前者は会話を提供します。後者はハーネスを提供します。
それでもうまくいかないこと
これらはいずれも難しい問題を解決しません。エージェントは依然として近道を取ります。早期に停止します。完了度を過大評価します。特に、最近の論文、なじみのないベンチマーク、学習分布外のシステムでは、自信過剰だが脆弱な計画を生成します。
エージェントをより信頼してもこれは解決しません。より優れた制御システムが解決します。目標、ループ、評価器、決定論的チェック、視覚的な成果物、セッション記憶はすべて、自律性を観察可能で修正可能にする方法です。
方向性は明確です。コーディングエージェントの未来は、より高性能なモデルを中心としたより優れたオーケストレーションに依存しています。エンジニアは、エージェントが数時間または数日にわたって安全に実行でき、検証可能な成果物を生み出せる条件を設計します。
