エージェント的ループの設計とは、コーディングエージェントが解決に向けて反復を任される際のゴール、ツールセット、実行条件を意図的に組み立てる実践である。これは、エージェントをゴールを達成するためにループの中でツールを実行するものとして捉えることから導かれる。エージェントがそういうものであるなら、人間が担う部分はループの実行ではなくその設計になる。この用語は Simon Willison が 2025 年 9 月の投稿で提案したもので、明示的に、彼が台頭しつつあると判断したスキルに名前を与える試みとして示された — エージェント的ループの設計 を参照。
用法
この実践は 4 つの部分から成ると説明されている。1 つ目は、問題を明確なゴールと、それに向けて反復できるツールの組へと落とし込むことである。これにより、繰り返し試行できるというエージェントの能力が、あてどないものではなく役に立つものになる。その前提にある捉え方は、コーディングエージェントは総当たりの道具であり、総当たりには押し当てる対象が必要だというものである。2 つ目は、ループをどこまで自由に走らせるかを決めることである。コマンドごとの承認はより安全だが、この種の問題解決における有効性を劇的に下げると論じられており、そのため設計上の問いは、どのような封じ込めがあれば無人での実行を許容できるかになる（YOLO モード と サンドボックス化 を参照）。
3 つ目は、ツールそのものを選ぶことである。ソースは、コーディングエージェントはシェルコマンドの実行が得意だという理由から、Model Context Protocol に頼るよりもシェルコマンドの観点で考えることを勧め、エージェントが必要とするコマンドを AGENTS.md 風のファイルに記録しておくことを勧めている。その際、エージェントが汎化するには通常 1 つの具体例で足り、よく知られたツールは名前を挙げるだけでよいとされる。4 つ目は認証情報である。認証付きのアクセスが避けられない場合の推奨は、被害が封じ込められるテスト環境やステージング環境を優先すること、そしてお金を使いうるものには厳格な予算上限を設けることである。
適用される場面
示されている前提条件は、明確な成功基準 があり、その解決に退屈な試行錯誤が伴いそうな問題であることである。そうした問題を見分けるシグナルとして挙げられているのは、多くのバリエーションを試さなければならないだろうと考えている自分に気づくことである。ソースの例は、失敗しているテストのデバッグ、インデックスを追加・削除しながらの遅いクエリのベンチマーク、依存関係のアップグレードの積み残しの消化、そしてイメージを小さくするための Dockerfile の反復改善である。ソースが挙げる共通要素は自動テストである。きれいに通るテストスイートこそが、エージェントに前進と後退を見分けさせるものであり、ソースはそれがエージェントの価値を大幅に増幅すると考えている。
この実践は、封じ込めについての判断がすでになされていることを前提とする。エージェントが承認待ちで止まらないときにこそ、ループは成果を生むからである。ソースは率直に、よくある解決策はリスクを軽減しないまま引き受けることだと認めており、また自身が好む代替策 — コンテナ、あるいは使い捨てのクラウド環境 — も保証ではなく個人的なリスク判断だとしている。コンテナエスケープは存在すること、そしてエージェントベンダー自身のサンドボックス化が信頼できるほど説得力のある形で文書化されているのを見たことがないことにも触れている。この実践がどれほど確立しているかについて、ソースは明言している。これは非常に新しい領域であり、この用語は定着した用法としてではなく、一人の実践者による議論の出発点として提示されている。
関連用語
YOLO モード、サンドボックス化、AI エージェント、AI コーディングエージェント、AGENTS.md、Agentic Loop Engineering（ALE）
- Agentic Loop Engineering（ALE） — エージェントがタスクをどう実行するかを統制するための、より形式的な別の提案で、実践者ではなく研究の側から導かれたもの
- アウターループ — このループを内側に含む、周囲のサイクル