AI News HubLIVE
站内改写6 分で読了

エージェントループ:最高のAIコーディングワークフローはプロンプトではなくループである理由

この記事は、AIコーディングにおけるエージェントループ(Agentic Loops)の重要性を解説し、従来のワンショットプロンプトに代わる「行動→チェック→反復」の小さなステップによる反復パターンが、コード品質、安全性、監査性を向上させることを示しています。8つの実戦済みループパターンとその設計原則を詳述しています。

ソースHacker News AI著者: dev_chad

ほとんどの人は、AIを使ってコードを書く際、非常に高速で記憶のないインターンを使うように、プロンプトを書き、コードブロックを受け取り、ざっと見て、貼り付け、期待する、という方法を未だに使っています。この方法は、変更がコンテキストウィンドウに収まらなくなる、リスクが大きすぎて1つの差分に収まらない、またはもっともらしく間違っている可能性が高い、といった限界に達するまでは機能します。

実際にエージェントで仕事を納めているチームは、静かに別の形態に移行しています。プロンプトではなく、ループです。

エージェントループは、定義は単純ですが、正しく実装するのは難しいです:

行動 → 厳格なゲートに対してチェック → 繰り返す、収束シグナルが停止を指示するまで。

エージェントは1つの小さな変更を行い、自動化されたゲートがそれを有効と判断するかどうかを決定し、ループが続きます——成功を蓄積し、失敗をロールバックし、やる価値がなくなったら自動停止します。興味深い部分はエージェント自体ではなく、その周りに構築されたハーネスであり、何千もの小さな自律的なステップを安全にします。

私たちはちょうど、エージェント用の8つの実戦済みループパターンを含む「Agentic Loops」スキルパックをリリースしました。この投稿はその背後にある理由を説明します。

ワンショットプロンプトの限界

エージェントに「失敗しているテストをすべて修正」または「このコードベースを新しいAPIに移行」をワンショットで依頼すると、毎回同じ壁にぶつかります:

  • コンテキストオーバーフロー: 200ファイルのリファクタリングはコンテキストに収まらず、エージェントは見えない部分を推測します。
  • レビュー不可能: 1つのプロンプトから生成された600行の差分は、人間が真剣に読むものではなく、ざっと見て信頼してマージします。
  • もっともらしいが間違いを助長: ゲートがないと、エージェントの自信が受け入れ基準になります。自信は正確性ではありません。
  • 停止スイッチがない: 「バグを見つける」は一度実行して停止し、すべてを見つけたかどうかは関係ありません。

ループはこれら4つすべてを修正します——エージェントを賢くするのではなく、作業単位を「1回の大きな飛躍」から「多くの小さなチェック済みステップ」に変えることによって。

3つの中核的不変原則

すべての良いエージェントループは、タスクに関係なく、同じ3つのルールを強制します。どれか1つをスキップすると、ループは高価な忙しい作業に退化するか、さらに悪いことに自信満々の損害を引き起こします。

1. 毎回の反復における厳格な自動ゲート

ゲートは全体の心臓部です。エージェントが弁論で通り抜けられない決定論的チェックです:テストスイートの終了コード、tsc --noEmitがゼロを返すこと、評価スコアが後退しないこと、バッチごとの行数照合など。

ルール:ゲートを通過しない変更はなかったものとみなす。マージではなくロールバック。ゲートがあるからこそ、10のエージェントが40のファイルを並行して編集しても安全です——緑の変更だけがコミットされるからです。

2. 毎回の反復における単一帰属変更

「これら4つを修正」を1ステップにまとめると、2つが合格し2つが後退した場合、どの編集が何を引き起こしたかわかりません。エージェントは数値を動かすために散弾編集を始め、筋道を見失います。

1変更、1ゲート実行、1判定。1ステップあたりは遅くなりますが、全体としてははるかに速くなります。すべてのステップが独立してレビュー可能かつロールバック可能だからです。何かが壊れたとき、半完成品をデバッグする代わりに、git bisectで正確な行を特定できます。

3. 誠実な収束シグナル

停止条件のないループは永遠に実行されるか、恣意的に停止します。解決策は進捗を計測し、それに基づいて停止することです:スキップ率が50%を超える、失敗テスト数がゼロになる、バグファインダーがK回連続で静かになる、評価スコアが頭打ちになる。

ここでの規律は誠実なスキップです。ページがすでに磨き上げられている場合、正しい出力は「何も変更しなかった、理由はこれ」であり——忙しく見せるための強制的でわずかな調整ではありません。完了したことを知っているループは、10の無理やり続けるループに勝ります。

ループが捉えるがプロンプトが決して捉えないもの

具体的な例。私たちは自己改善ループを本番管理パネルに向けました——すべてのページをスクリーンショットし、見て、1つの小さな改善を行い、tsc + eslintを実行し、繰り返す。数ラウンドで約85の改善を生み出し、毎回クリーンなゲート通過。

しかし、最も素晴らしい瞬間は磨き上げではありませんでした。あるラウンドで、スクリーンショットハーネス——未キャッチのページエラーもリッスンしている——が、設定タブでフレームワークの全画面クラッシュ画面がレンダリングされているのを検出しました。APIのみのヘルスチェックは常に緑でした。なぜならクラッシュはクライアント側だったからです。人間がサムネイルをざっと見ていたら見逃していたでしょう。ループが自動的に捉え、実際のエラー(Cannot read properties of undefined (reading 'memes'))を取得し、状態マージのバグを追跡し、根本的に修正しました——そして今、ハーネスはそのクラスのバグを永久にフラグ付けします。

それが報酬です:ループは単に作業をするだけでなく、回帰が戻ってくるのを防ぐラチェットを構築します。

8つのジョブのための8つのループ

パターンは普遍的であり、ゲートと収束シグナルはタスクに応じて変わります。パックは以下をカバーします:

  • セルフ改善:スクリーンショット→1つ改善→テスト;ゲート:tsc 0 / eslint 0;停止:スキップ率 > 50%
  • テストアンドフィックス:テスト実行→最初の失敗を修正→すべて再実行;ゲート:テスト終了コード;停止:失敗数0
  • バグハント:多様なファインダー→懐疑論者による検証→修正;ゲート:敵対的レビュー + 再現性を通過;停止:Kラウンド新発見なし
  • 移行:サイト偵察→各変換→検証;ゲート:ファイルごとの型チェック + ランタイム;停止:未移行残差0
  • 評価駆動:1変更提案→評価再実行→良ければ保持;ゲート:スコア後退なし;停止:開発スコア頭打ち
  • 研究統合:収集→ギャップ批判→埋める;ゲート:各主張が出典を読んでいることを引用;停止:批評家がギャップなし
  • テスト下でのリファクタリング:小さな構造変更→完全スイート;ゲート:スイートが毎ステップ後緑;停止:目標構造に到達
  • データバックフィル:バッチ→チェックポイント→検証→再開;ゲート:バッチごとの不変条件 + 照合;停止:カーソル完了 + ソース==デスティネーション

誤解されやすいパターンをいくつか:

バグハントは2つの詳細に依存します。ファインダーは視点が多様でなければなりません——各ファインダーに異なるレンズ(正確性、セキュリティ、並行性、リーク)を与えないと、5つの同一ファインダーは同じ明白なnull参照で合意します。検証は敵対的でなければなりません——「このバグを確認せよ」と依頼された検証者はもっともらしいナンセンスを承認印を押しますが、「これを反駁せよ、デフォルトで反駁、具体的な再現がある場合のみ確認せよ」と言われた検証者は信頼できる結果をもたらします。微妙な殺し屋:確認したものだけでなく、見たすべてに対して重複排除すること——さもなければ、拒否された発見は永遠に再発見され、ループは枯渇しません。

テストアンドフィックスは意図的に偏執的です。エージェントはアサーションを削除してテストを通そうとします。そのため、ループは毎回テストファイルを差分し、テストを縮小または弱体化させる変更を拒否します。一度に1つの失敗を修正し、スイート全体を再実行し(失敗1の修正がしばしば失敗5を壊す)、「スタック」を検出します——同じ失敗シグネチャが2回現れたら、永遠にループせずにエスカレーションします。

テスト下でのリファクタリングには1つの不変条件があります:すべてのステップで動作が同一であること。スイートが薄い場合、エージェントは構造に触れる前に現在の動作(バグも含む)を固定する特性テストを書きます。そして、各ステップが独立して緑でロールバック可能なほど小さなステップを踏みます。テストを編集して通す必要が生じた時点で停止します:それはリファクタリングの服装をした動作変更です。

データバックフィルは冪等性に基づいています。1000万行にわたる6時間のジョブは中断される可能性があるため、各バッチは安全に再実行可能でなければならず(キーによるupsert、ブラインド挿入は不可)、カーソルは各バッチ後にチェックポイントを設定する必要があります——一過性のブリップでゼロから再開すると、ジョブは決して完了しません。実行中に検証し、最後にソースとデスティネーションを照合します。「ループがエラーを止めた」は「すべてのデータが正しい」と同じではないからです。

独自ループの構築方法

フレームワークは必要ありません。必要なのは3つのものと、それらを正直に配線する規律です:

  1. 議論できないゲートを選ぶ:終了コード、型チェック、評価スコア、行数。ゲートの名前を言えなければ、ループはありません——雰囲気だけです。
  2. 可能な限り小さな作業単位を作る:1つの失敗、1つのページ、1つの呼び出しサイト、1つのバッチ。帰属可能でロールバック可能。
  3. 収束を計測し尊重する:ゼロに向かう何かを数える。ループに完了を伝えさせ、それを信じる。

そして、作業が大きい場合は、ファンアウトします:複数のエージェント、それぞれが異なるスライス(異なるファイル、異なるページ)を所有し、各々がコミット前に同じゲートを通過します。並行自律性が安全なのはゲートのおかげです。それがすべてのトリックです。

結論

過去1年間のエージェント生産性の飛躍は、よりスマートなモデルがより良いワンショット回答を書いたことではなく、十分に良いエージェントに千の小さなチェック済みステップを取らせる方が、偉大なエージェントに1つの完璧な飛躍を求めるよりも遠くに行けるという認識でした。

プロンプトは成果物を生み出します。ループはプロセスを生み出します——あなたが寝ている間も働き続け、通過しないものを出荷することを拒否し、完了したときに正直に伝えるプロセスです。

上記の8つのパターンは今SkillDBにあり、それぞれ哲学、ループ図、実行可能ドライバー、苦労して得た落とし穴、そしてそれを安全にする正確なゲートが含まれています。エージェントをAgentic Loopsパックに向け、実行するループを与えてください。