BLOG
Loop Engineering — エンジニアの仕事は『ループを書くこと』になった
『My job is to write loops.』プロンプトからループ設計へ。Prompt→Context→Harness→Loop と抽象度が上がる新潮流と、コスト爆発・理解負債という現実的リスクを整理します。
エンジニアの仕事は、いつのまにか「コードを書くこと」から「AIにコードを書かせる仕組みを設計すること」へ移りました。その最新形が Loop Engineering（ループ・エンジニアリング） です。
一回のプロンプトを磨くのではなく、AIエージェントを時間軸で自律的に回し続ける「ループ」そのものを設計する。エンジニアが定義するのは「目的」と「停止条件」だけ。細部の実装や修正は、ループの中でAIが自分でやり切る。この考え方が2026年前半に一気に広がりました。
きっかけは「自分の仕事はループを書くことだ」
火をつけたのは、Anthropic で Claude Code の開発を率いる Boris Cherny 氏の一言です。
My job is to write loops.（自分の仕事はループを書くことだ）
2026年6月のこの発言は、エンジニアの役割が「都度プロンプトを打つ人」から「AIを自律的に動かす仕組みを設計する人」へシフトしていることを、あまりに端的に言い当てていました。だからこそ業界で一気に拡散したのだと思います。
現場感覚としても腑に落ちます。AIに一問一答で指示を出している間、人間はずっと画面に張り付いていなければならない。それは「AIを使っている」ようで、実際には人間がボトルネックになっている状態です。ループを設計できれば、人間は寝ている間もAIに働かせられる。レバレッジの桁が変わります。
Loop Engineering とは何か
AIへの関わり方は、この数年で階段を上るように抽象度を上げてきました。
- Prompt Engineering — 一回の指示文を磨く
- Context Engineering — AIに渡す文脈情報を設計する
- Harness Engineering — エージェントを動かす枠組み（ツール・権限・実行環境）を設計する
- Loop Engineering — その枠組みを時間軸で自律的に回し続ける「ループ」として設計する(いまここ)
一番下の Prompt Engineering は「その場かぎりの職人技」でした。上に行くほど、**一度設計すれば繰り返し効く「資産」**になります。Loop Engineering はその頂点で、人間は具体的な作業手順を書きません。書くのは「何が達成できたら終わりか」という条件だけ。あとはエージェントが試行と修正を繰り返してそこへ到達します。
ループを支える6つの構成要素
自律ループは、ざっくり以下の6つの部品で成り立ちます。ここが Loop Engineering の設計対象です。
- スケジューリング（Trigger） — いつ動き出すか。cron や
/loopのようなコマンドで起動条件を決める - ゴール条件（Goal） — 何が満たされたら止まるか。達成するまでエージェントを回し続ける終了条件
- 隔離ワークスペース（Isolation） — 複数エージェントが同時に動いても衝突しない環境。git worktree などで作業空間を分ける
- 検証者（Verifier） — AI自身が書いたコードを、別ロジック・別モデルで検証する仕組み。「書いた本人に採点させない」のが肝
- 永続メモリ（Memory） — セッションをまたいで学習内容を引き継ぐ。同じ失敗を毎回やり直さないための記憶
- コネクタ（Connector） — GitHub や Slack など外部システムと連携し、実際に行動を起こすための接続口
順番に見ると分かりますが、プロンプトの巧拙はここに一つも入っていません。Loop Engineering で問われるのは、ソフトウェア設計そのもののセンスです。
実践ツールと、すでに始まっている熱狂
この概念は理論だけの話ではありません。オープンソースの cobusgreyling/loop-engineering というCLIツール群が実際にこの考え方を実装しており、公開から短期間で 4,800以上のスター を集めています。上の6要素をコマンドラインから組み立てられるようにしたもので、Loop Engineering が「バズワード」から「触れる道具」へ移りつつあることの証左だと思います。
万能ではない — 3つの現実的リスク
ここまで読むと魔法のように聞こえますが、実際に回してみると明確な代償があります。ここを見ずに導入すると痛い目に遭います。
コストの爆発
ループは「終わるまで回り続ける」のが本質です。裏を返せば、停止条件の設計を誤ると延々とトークンを消費し続ける。一晩放置したら気づかぬうちに数万円が溶けていた、という事故は珍しくありません。ゴール条件と同じくらい「暴走を止めるガードレール（上限トークン・タイムアウト・連続失敗での打ち切り）」の設計が重要です。
検証責任は人間に残る
Verifier を挟んでも、それはあくまで「AIによる一次チェック」です。最終的に本番へ出す判断の責任は、最後まで人間に残ります。ループが「テスト全部グリーン」と報告してきても、そのテスト自体をAIが甘く書いていたら意味がない。自動検証を信用しすぎないことが、逆説的にループを安全に回すコツです。
理解負債の蓄積
これが一番静かで、一番怖いリスクです。AIが生成したコードを人間が読まなくなると、システムの全体像が誰の頭にも残らなくなる。**後から返済できない「理解の喪失」**が溜まっていきます。
技術的負債は書き直せば返せますが、理解負債は「そもそも何をどう直せばいいか分からない」状態です。障害が起きた深夜に、自社のコードなのに誰も中身を説明できない——これはループの生産性で得た時間を、将来まとめて利子付きで奪い返される取引になりかねません。
結論 — ループを設計するのは、まだ人間の仕事
Loop Engineering は「エンジニアを不要にするもの」ではありません。人間のレバレッジのかけ所を、プロンプトから「自律的なシステム（ループ）そのものの設計」へと一段引き上げるものです。
止め方を知らない自動化はただの暴走であり、中身を理解しない生産性はただの負債の前借りです。だからこそ、目的・停止条件・検証・そして「どこまでAIに任せ、どこは人間が読むか」の線引きを設計できる人の価値は、むしろ上がっていく。
株式会社ワイアード&エコでは、Claude Code やエージェントを前提とした開発フローの設計・導入支援を行っています。「AIに書かせているが、レビューと運用が追いつかない」「自律ループを安全に回す仕組みを作りたい」といったご相談を承っています。お気軽にお問い合わせください。