ループエンジニアリング - エージェントをプロンプトするシステムを設計する

 (addyo.substack.com)
12 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • コーディングエージェントに毎ターン直接プロンプトするやり方を終わらせ、エージェントの代わりにプロンプトするシステムを設計する働き方への転換
  • ループは目的を定義するとAIが完了するまで反復する再帰的目標であり、およそ5つの構成要素から成る
  • 5つの要素はAutomations, Worktrees, Skills, Plugins・connectors, Sub-agentsで、Claude CodeとCodexの両方が現在この5つをすべて備えている
  • 6つ目の要素であるメモリは、単一の会話の外に状態を保存するMarkdownファイルやLinearボードのことで、実行のたびに忘れるモデルを補う
  • まだ初期段階であり、トークンコストへの注意が必須。検証と理解は依然として人間の役割である（build the loop, stay the engineer）

ループエンジニアリングの定義と登場背景

  • ループエンジニアリングとは、エージェントにプロンプトする人の役割を自分からシステムへ置き換えること、その仕事を代行するシステムを自ら設計すること
    • ループは目的を定義するとAIが完了するまで反復する再帰的目標（recursive goal）
    • コーディングエージェントと働く未来のやり方になり得るが、まだ初期段階であり、トークンコストへの注意が必須（token rich/poorかどうかで利用パターンが大きく変わる）
  • 引用
    • Peter Steinberger「もうコーディングエージェントにプロンプトするのではなく、エージェントにプロンプトするループを設計せよ」
    • Boris Cherny（AnthropicのClaude Code責任者）「もうClaudeにプロンプトしているのではなく、Claudeにプロンプトして何をするかを決めるループを回している。私の仕事はループを書くことだ」
  • この約2年間は、よいプロンプトと十分なコンテキストを与え、1ターンずつやり取りしながらエージェントを道具として直接握っているやり方だったが、そのやり方は終わりに向かっている
  • これからは、作業を見つけて振り分け、検証し、完了したことを記録し、次の作業を決める小さなシステムを作り、そのシステムにエージェントを突かせる
    • 以前の記事でいうagent harness engineering（1つのエージェントが動く環境）やfactory model（ソフトウェアを作るシステム）の上位に位置する
    • タイマーで動作し、小さなヘルパーを生成し、自分自身に餌を与えるハーネス
  • もはやツールの問題ではない — 1年前ならループが欲しければbashのダミーを自分で書いて保守する必要があったが、いまでは構成要素が製品の中にそのまま搭載されている
    • Steinbergerの一覧はCodexアプリとほぼ正確に一致し、Claude Codeともほぼ同じなので、どのツールかを争うのではなく、どちらでも動くループを設計する

ループの5つの構成要素とメモリ

  • ループには5つが必要で、そこに状態を記憶する場所が1つ加わる
    • Automations — スケジュールに従って起動し、自ら発見と分類（triage）を行う
    • Worktrees — 並行して働く2つのエージェントが互いに衝突しないようにする
    • Skills — エージェントが推測で埋めてしまうプロジェクト知識を記録しておく
    • Plugins・connectors — すでに使っているツールにエージェントを接続する
    • Sub-agents — 一方がアイデアを出し、もう一方が検証する
  • 6つ目はメモリで、MarkdownファイルやLinearボードなど単一会話の外に存在し、完了したことと次にやることを保持する
    • 単純すぎるように見えるが、長時間動くエージェントがどれも依存している同じトリックである（以前の記事 long-running agents）
    • モデルは実行の合間にすべてを忘れるので、メモリはコンテキストではなくディスク上になければならない — エージェントは忘れてもrepoは忘れない
  • 両製品とも現在この5つをすべて備えており、名前が少し違うだけで能力は同じ

Automations — ループの心拍

  • Automationsは、ループを単発の実行ではなく本当のループにする要素
    • CodexアプリではAutomationsタブで作成し、プロジェクト・実行するプロンプト・周期・ローカルチェックアウトかバックグラウンドworktreeかを選ぶ
    • 何かを見つけた実行はTriageインボックスへ行き、何も見つけられなかった実行は自動的にアーカイブされる
    • OpenAIは日次のissue triage、CI失敗の要約、コミットブリーフィングの作成、先週追加されたバグの探索のような退屈な仕事に社内で使っている
    • 自動化はskillを呼び出せるため、巨大な指示文の壁を貼り付ける代わりに$skill-nameを起動し、反復作業を保守しやすくできる
  • Claude Codeはスケジューリングとhooksで同じ地点に到達する
    • /loopで一定間隔ごとにプロンプトやコマンドを実行し、cronジョブをスケジュールし、エージェントのライフサイクルの特定時点でhooksとしてシェルコマンドを発火できる
    • ノートPCを閉じたあとも動かし続けたいなら、全体をGitHub Actionsに渡せる
  • セッション内の2つ目のプリミティブとして、この文章の核心にかなり近い機能がある
    • /loopは決めた周期ごとに再実行する
    • /goalは、書いた条件が実際に真になるまで継続し、各ターン後に別の小さなモデルが完了可否を検査することで、コードを書いたエージェント自身が採点者にならないようにする
      • 例: 「test/authのすべてのテストに合格し、lint clean」といった条件を与えて席を離れる
    • Codexも同様に/goalを提供し、検証可能な停止条件が成立するまでターンを進めながら動作し、pause・resume・clearをサポートする

Worktrees — 並列を混乱にしないために

  • エージェントを2つ以上走らせた瞬間からファイル衝突が起き始め、ここが失敗ポイントになる
    • 2つのエージェントが同じファイルを書くのは、2人のエンジニアが互いに何も言わず同じ行をコミットするような頭痛の種
    • git worktreeがこれを解決する — 同じrepo履歴を共有しつつ、それぞれのブランチ上にある別個の作業ディレクトリなので、片方のエージェントの編集がもう一方のチェックアウトに触れることはない
  • Codexはworktreeサポートを内蔵しており、複数スレッドが1つのrepoを同時に触っても衝突しない
  • Claude Codeはgit worktree、セッションを独自チェックアウトで開く--worktreeフラグ、subagentに付けるisolation: worktree設定で同じ隔離を提供する（各ヘルパーは終了時に自分で片付く新しいチェックアウトを受け取る）
  • worktreeは機械的な衝突をなくしてくれるが、あなた自身が依然として上限 — 実際に回せる数はツールではなく、自分のレビュー帯域幅で決まる（以前の記事 the orchestration tax）

Skills — 毎回プロジェクトを説明し直さないために

  • skillは、毎セッション金魚のように同じプロジェクトコンテキストを説明し直すのをやめる方法
    • 両ツールとも同じフォーマットを使う — 指示文とメタデータを含むSKILL.mdが入ったフォルダと、任意のスクリプト・参照・アセット
    • Codexでは$または/skillsで呼び出せるほか、作業がskillの説明と一致すれば自動実行もされるため、巧妙な説明よりも簡潔で退屈な説明のほうがよい
    • Claude Codeも同じ方式である（以前の記事 agent skills）
  • skillは意図（intent）が反復コストにならないようにする場所
    • エージェントは毎セッションを冷えた状態で始め、意図の空白を自信満々の推測で埋める（以前の記事 the intent debt）
    • skillはその意図を外部に書き出したもの — 規約、ビルド手順、「あの事件があったのでこうはしない」といったことを一度書いておけば、エージェントが毎回読む
    • skillがなければループは各サイクルごとにプロジェクト全体をゼロから再導出するが、あれば蓄積されて複利のように効く
  • skillは著述フォーマットであり、pluginは配布方法 — 複数repoで共有したりまとめたりするならpluginとしてパッケージ化する（Codex・Claude Codeとも同じ）

Plugins・connectors — ループを実際のツールに届かせる

  • ファイルシステムしか見えないループは小さなループでしかない
    • MCPベースのconnectorにより、エージェントはissue trackerの読み取り、DBへのクエリ、staging APIの呼び出し、Slackメッセージの送信が可能になる
    • CodexとClaude CodeはどちらもMCPを採用しているため、片方用のconnectorがたいていもう片方でもそのまま動く
    • pluginはconnectorとskillを束ね、同僚が記憶だけで全体を再構築することなく一度でインストールできるようにする
  • これが「ここに修正案がある」と言うだけのエージェントと、PRを開き、Linearチケットを関連付け、CIがgreenになったらチャンネルに通知を送るループとの違い
    • connectorがあるからこそ、ループは単に可能性を語るのではなく、実際の環境の中で行動できる

Sub-agents — 作る側と検査する側を分ける

  • ループで最も有用な構造は、やはりコードを書く側と検査する側の分離
    • コードを書いたモデルは、自分の宿題を採点するとき甘すぎる
    • 別の指示文を持ち、ときには別モデルでもある第2のエージェントが、最初のエージェントが自分で納得してしまったものを見つけ出す
  • Codexは必要なときだけsubagentを生成し、同時に実行したうえで結果を1つの回答に統合する
    • .codex/agents/にTOMLファイルとして独自エージェントを定義する（name・description・instructions、任意でmodel・reasoning effort）
    • 例: セキュリティレビューアはhigh effortの強いモデル、explorerは高速なread-onlyモデル
  • Claude Codeは.claude/agents/のsubagentsと、タスクを受け渡すagent teamsで同様に処理する
    • 両ツールで一般的な分担は、1つのエージェントが探索、1つが実装、1つが仕様との差分を検証する形（以前の記事 the code agent orchestra, adversarial code review）
  • ループは見ていない間に回るので、席を離れるには**信頼できる検証者（verifier）**が必要
    • subagentはそれぞれモデルとツール作業を行うためトークン消費が増える。2つ目の意見に価値がある場面で使うべき
    • Claude Codeの/goalが内部でやっているのもこれ — 新しいモデルが作業した側の代わりに完了可否を判断し、停止条件そのものにmaker・checkerの分離を適用している

1つのループはどのような形か

  • まとめると、単一スレッドが小さな制御盤へと変わり、繰り返し使う1つの典型形はこうなる
    • automationが毎朝repo上で実行され、そのプロンプトがtriage skillを呼び出して、昨日のCI失敗・未解決issue・最近のコミットを読み、結果をMarkdownファイルやLinearボードに記録する
    • 価値のある各項目ごとに、スレッドは隔離されたworktreeを開き、sub-agentに修正案のドラフトを任せ、第2のsub-agentがそのドラフトをプロジェクトskillと既存テストに照らしてレビューする
    • connectorがループにPRの作成とチケット更新を行わせ、ループで処理できなかったものはtriageインボックスへ入る
    • **状態ファイル（state file）**が全体の背骨であり、何を試し、何が通り、何がまだ開いているかを記憶して、翌朝の実行が今日止まった地点から続けられるようにする
  • 要点は、そのどの段階も毎回プロンプトしているのではなく、一度設計したということ — CodexでもClaude Codeでも構成要素は同じなので、同じループになる

ループがなお代替してくれないもの

  • ループは仕事の形を変えるだけで、人間を消すわけではない。むしろループがよくなるほど鋭くなる問題が3つある
  • 検証は依然として自分の仕事
    • 無人で回るループは、無人でミスをするループでもある
    • verifier sub-agentをmakerから分けるのは、ループの「終わった」に意味を持たせるためだが、それでも「done」は証明ではなく主張でしかない（以前の記事 code review in the age of AI — 仕事とは、動作確認したコードを出荷すること）
  • 理解は放置すると腐る
    • ループが自分で書いていないコードを速く出荷するほど、存在しているものと実際に理解しているものの間のギャップは広がる
    • これがcomprehension debtであり、滑らかなループほど、ループが作ったものを読まなければそのギャップをさらに速く広げる
  • 楽な姿勢は危険な姿勢
    • ループが自律的に回ると、自分の意見を持つのをやめて、返ってきたものをそのまま受け入れやすくなる（cognitive surrender）
    • ループ設計は、判断を持って行えば治療薬だが、考えることを避けるために行えば加速剤になる — 同じ行動でも結果は正反対

ループを作れ、しかしエンジニアであり続けよ

  • これは仕事の進化の予告編のようにも見えるが、コードを自分でレビューしなかったり、自動ループだけに依存したりすると、製品品質が落ち、ますます深い穴にはまっていく下降スパイラルに閉じ込められかねない
  • ループを設定しつつ、エージェントに直接プロンプトすることも依然として有効であり、要点は適切なバランスを見つけること
  • ループは人によって正反対の結果をもたらす — 同じループを作った2人のうち、1人は深く理解した仕事をより速く進め、もう1人は仕事を理解しないために使う
    • ループ自体にはその違いは分からないが、あなたには分かる
  • これが、ループ設計がプロンプトエンジニアリングより簡単ではなく、むしろ難しい理由 — Chernyの要点は仕事が簡単になったことではなく、レバレッジの位置が移ったということ
  • 結論: ループを作るにしても、ただスタートボタンを押す人ではなく、エンジニアとしてあり続ける人のように作ること

関連記事

1件のコメント

 
shakespeares 3 시간 전

検証は依然として自分の役目

理解は放置すると鈍る

楽な姿勢は危険な姿勢

=> 結局、直接確認し、反復作業を最小化するためのプロンプティングが必要だ。