ループエンジニアリング入門 ― AIに「指示する人」をやめて、「指示する仕組み」を作る ―

「もうプロンプトは書かない。AIに指示する“ループ”を動かし続けるだけだ」――AIコーディングの第一線から、そんな声が聞こえてくるようになりました。指示の書き方を工夫する時代から、指示すること自体を仕組みに任せる時代へ。この発想が「ループエンジニアリング」と呼ばれ、大きな注目を集めています。本記事では、それがどんな考え方で、どんな部品からできていて、実際にどう役立つのかを解説します。

ここ数か月、AIコーディングの第一線から、少し前なら考えられなかった発言が相次いでいます。

Here’s your monthly reminder that you shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.

「もうAIエージェントにプロンプトを書くな。AIエージェントに指示する「ループ」を設計しろ。」　― Peter Steinberger（OpenClawの作者）によるXの投稿

I don't prompt Claude anymore I have loops that are running they're the ones that are prompting Claude and kind of figuring out what to do my job is to write loops
「私はもうClaudeにプロンプトを書いていない。Claudeに指示するループを動かし続けている。私の仕事はループを書くことだ。」　― Boris Cherny（Anthropic / Claude Code 責任者）による、イベント「Acquired Unplugged」(WorkOS提供)での発言

かつては「どう指示すればうまく動くか」を磨くことがAI活用の中心でした。それが、「指示すること自体をやめ、指示が自動的に生まれ続ける仕組みを作る」方向へと重心を移し始めている。この発想が「ループエンジニアリング」と呼ばれ、注目されているのです。

ループエンジニアリングは、突然現れた概念ではありません。AI活用における「設計対象」が段階的に広がってきた流れの、いまのところの到達点にあります。

最初に注目されたのはプロンプトエンジニアリングでした。1回の指示文をどう書けばうまく答えてくれるか、という技術です。やがて、1回の指示では足りない場面が増え、AIが推論するときに何を・どの順番で見せるかを設計するコンテキストエンジニアリングが重視されるようになります。さらに、AIが自律的なエージェントとして動く時代になると、その土台を整えるハーネスエンジニアリングが語られるようになりました。

そしてループエンジニアリングは、その先にあります。ハーネスまでは「AIが走れる舞台」を整えるところまででしたが、そこに軌道（いつ・何をきっかけに走り出すか）の自動化まで含めたのがループです。レバレッジポイント ("てこ"の効く場所) が、「指示の書き方」から「指示する仕組み」へと移ってきた、と言い換えてもよいでしょう。

「ハーネスもループも、AIを自動で動かす仕組みでは？」と混同されがちですが、視点が一段違います。

ハーネスエンジニアリングは、1回の作業をAIが完走できる足場を整えることに主眼があります。起動は人間が「これをやって」と走らせ、タスクが終われば止まる。関与のたびに人間がプロンプトを書く前提です。いわば“一回の旅を完走させる装具”です。

これに対してループエンジニアリングは、その軌道自体を自動化します。起動はスケジュールや「メールが届いた」といったイベントをトリガーに自動で始まり、目的を達成するまで何度も繰り返す。人間の判断が要るときだけ人に渡す。人間の役割は、最初に設計したら、あとは監督に回ります。ループは「ハーネスの一階層上」――ハーネスが時計仕掛けのように回り続ける状態を作る、外側の仕組みなのです。

では、ループは具体的にどんな部品でできているのでしょうか。ハーネスと重なる部分もありますが、大きく5つ＋1つに整理できます。

1. 自動化（Automation）
   ループの心臓部で、スケジュールなどでループを起動し、仕事を見つけて持ってくる
   　
2. ワークツリー
   複数のAIが並列で作業してもファイルが衝突しないよう作業空間を分離する仕組み（Gitのバージョン管理の概念に近い）
   　
3. スキル（Skills）
   プロジェクト固有のお作法や定型作業を書き留めておき、毎回説明しなくて済むようにするもの
   　
4. プラグイン / コネクタ
   MCPやAPIを通じてSlackやTeams、Issueトラッカーなど社内の道具に手を伸ばすための接続口
   　
5. サブエージェント
   作る人と検品する人を分ける（Maker / Checker）ための分業の仕組み

＋1 メモリ / 状態
　　全体の背骨部分。進捗や状態を会話の外側――Markdownのチェックリストやチケット管理ツール――に残しておくことで、
　　ループは自分がどこまで進んだかを見失わずに回り続ける

うれしいのは、これらをすべて自前で作る必要はないという点です。最近のClaude Code・Codex・Cursorといったツールには、こうした部品がすでに標準的に揃ってきています。

イメージを掴むために、開発現場での1日のループを例にしてみましょう。人が指示しなくても、朝起きたら仕事が進んでいる――そんな状態です。

毎朝8時、スケジュールがループを自動起動します。ループはCIの失敗や新しいIssue、直近のコミットをスキャンして自分で仕事を見つけ、別のワークツリーでサブエージェントが修正を起案。別のエージェントがテストや規約と照合して検品し、問題なければコネクタが自動でプルリクエスト(PR)を起票し、通知まで行います。人間の役割は、PRのレビューと、ループが「人に渡してきた」案件の判断だけ。実際、Codexの新しいアプリには「スケジュール」機能があり、たとえば「毎週月曜の朝9時に生成AI関連ニュースを調査する」と一度定義すれば、以降は自分でプロンプトを打たなくても毎週まとめが届きます。これもまさにループエンジニアリングの実践例です。

ループは「判断力の増幅器」であり、良くも悪くも、使う人次第という側面があります。導入前に、次の4点は押さえておきたいところです。

第一に、コストが膨らみやすいこと。サブエージェントを多用し長時間動かすと、トークン代がすぐに嵩みます。安いプランで気軽に試すと痛い目を見かねません。

第二に、理解の負債が貯まること。自分が書いていないコードがどんどんマージされ、「中身がわからないコードベース」になる速度も上がります。

第三に、検証は最後まで人間の責任だということ。「自動でやっています」は「正しいと証明済み」を意味しません。無人で動くループは、無人でミスを犯すループでもあります。

第四に、「思考停止」の罠。ループが回ると、つい成果物を鵜呑みにしたくなります。設計力を磨くつもりが、いつのまにか「考えない理由」に変わってしまわないよう注意が必要です。

“Build the loop. But stay the engineer.”（ループを組もう。ただし、エンジニアであり続けよ。）――Addy Osmani のこの言葉が、ループとの向き合い方をよく表しています。

ループエンジニアリングとは、「指示する人」をやめて「指示する仕組み」を設計する技術です。設計対象は、プロンプト→コンテキスト→ハーネス→ループと広がり、ついに「指示そのもの」から「指示者そのもの」へと移りました。しかも、その部品はClaude CodeやCodexなどにすでに揃っており、自前でゼロから作る必要はありません。

ハーネスで「AIが走れる土台」を整え、ループで「その土台を回し続ける外側」を設計する。両者はひと続きの流れです。ただし、コスト・理解の負債・検証責任・思考停止という落とし穴を忘れずに。「ループを組もう。ただし、エンジニアであり続ける覚悟で。」それが、これからのAI活用を左右する分かれ目になります。