いま、現場で何が起きているか
2026年6月、AIエージェント界隈の語り口が一晩で変わった。
きっかけは、OpenClaw開発者 Peter Steinberger のXポストだ。
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
（もうコーディングエージェントにプロンプトを打つな。エージェントにプロンプトを打つ"ループ"を設計しろ）
この投稿は約650万viewに達した。翌日にはGoogleの Addy Osmani が "Loop Engineering" と題したエッセイを公開し、この実践に名前と"解剖図"を与える。極めつけは、Claude Code を率いる Anthropic の Boris Cherny の一言だった。
"I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."
（もうClaudeにプロンプトは書かない。Claudeにプロンプトを打つループを走らせている。私の仕事はループを書くことだ）
ここで多くのエンジニアが「じゃあ自分も自律ループを組むツールを導入しよう」と考える。それが最初の、そして最大の間違いだ。 ループエンジニアリングの本質はツールではない。自分の業務を Input → 作業(skill) → Output という関数に分解し、それを回し続ける設計思想である。順番を間違えると、何も回らない。
トレンドの正体 ―「外側へ」進む4つの層
ここ数年のAI活用は、関心の対象が一貫して外側へ移動してきた。
- プロンプトエンジニアリング（2022–2024）：モデルに渡す「言葉」の最適化
- コンテキストエンジニアリング（2025）：モデルが見る「情報全体」の設計
- ハーネスエンジニアリング（2026）：エージェントを取り巻く「環境・足場」の構築
- ループエンジニアリング（2026）：それらを駆動する「反復サイクル」そのものの設計
重要なのは、各層が前の層を置き換えるのではなく内包する点だ。Anthropic は実際、自社にマージされるコードの8割超を Claude が書いていると明かしている（2026年5月時点）。これは個々のプロンプトが上手いからではなく、検証付きのループが回っているからだ。Anthropic 自身が "Building effective agents" でこう定義している ―「エージェントとは本質的に、環境からのフィードバックに基づきツールをループで使うLLMにすぎない」。
ここで一つ、定義を立てておく。ループとは単なる繰り返しではない。Output を評価し、その結果が次の Input と作業(skill)を改善する"循環"のことだ。 この「循環」を主役に据えられるかどうかが、流行に乗れる人と乗り遅れる人を分ける。
本題 ― まず「自分の業務」を3つの箱に入れろ
Osmani はループエンジニアリングをこう言い切る。
"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
（ループエンジニアリングとは、プロンプトを打つ"あなた自身"を置き換えることだ。代わりにそれをやる仕組みを設計する）
「あなた自身を置き換える」と言われても、自分が普段何をやっているか言語化できなければ置き換えようがない。だから出発点は、ツールの導入ではなく業務の言語化だ。あらゆるタスクを、次の3つの箱に強制的に放り込む。
- Input：何を受け取って始まるのか（メール、議事録、ログ、チケット…）
- 作業(skill)：そのInputに対して、どんな判断・変換を施すのか
- Output：最終的に何を出すのか（誰が、何を見て、OKと言えるのか）
Karpathy の言う Software 3.0 ―「プログラミングとはプロンプティングである」― が刺さるのはここだ。業務を3つの箱に分解した瞬間、それは"自然言語で書かれた関数"になる。関数になれば、再利用でき、自動化でき、そして評価ループに乗せられる。
山場 ― 架空の業務を実際に分解する
具体例で見よう。「会議の議事録から課題を抽出し、担当者に割り振る」という、どの職場にもある業務を分解する。
- Input：議事録テキスト（フォーマットは不定）＋ メンバー一覧と担当領域
-
作業(skill)：
- 発言から「未解決の課題」だけを抽出する
- 各課題を担当領域にマッチングする
- 期限の手がかりがあれば付与する
- Output：「課題・担当者・期限」の表。抜け漏れがなく、担当が妥当であればOK
これを最小のループとして書くと、骨格はこうなる。
state = init(議事録, メンバー一覧)
loop:
課題 = reason(state) # 抽出・割り当てを推論
結果 = act(課題) # 表として出力
judge = verify(結果) # 抜け漏れ・誤割り当てを検査
if judge == OK: break # ← exit条件
if loop数 > N: escalate(人間) # ← 暴走の安全弁
state = update(state, judge) # フィードバックを次周へ
「日報作成」でも構造は同じだ。Input＝その日のコミット・チャットログ、作業＝要約と整形、Output＝定型フォーマットの日報。箱の中身が変わるだけで、ループの骨格は使い回せる。 これが「あらゆるタスクに適用できる抽象化」の正体である。
ループの肝は exit条件 ―「業務マニュアル化」との決定的な差
ここまでなら「ただの業務フロー整理では？」と思うかもしれない。違う。決定的な差は、上の擬似コードの verify と break ―プログラム的な検証（exit条件）があることだ。
exit条件のないループがどうなるか。実際に語られた失敗例がある ― ある開発者が、Claude にタスクを実装させ、毎回「過剰実装だ」と人手でフィードバックし、それを13時間・87回繰り返したという話だ。これは自動化ではない。検証を人間が握り続けた結果、ループが回り続けただけだ。
業務マニュアルは「手順書」にすぎない。ループエンジニアリングが手順書と違うのは、「何をもって完了とするか」をコードで定義し、それを満たすまで自走させる点にある。Cherny の "My job is to write loops" は、まさにこの exit条件の設計を指している。
見極め ― 何でもループにすればいいわけではない
断言する。ループ化に向く業務と、向かない業務がある。 これを見誤ると労力の無駄だ。
向いている業務
- 反復頻度が高い（週に何度もやる）
- Input・Output が定型に寄せられる
- 「完了」の基準を言語化・検証できる
向いていない業務
- 一回性で、二度と来ない
- 判断が属人的で、正解を言葉にしにくい
- 失敗コストが高く、人間の承認を外せない
向かない業務に無理やりループを組むより、向く業務を1つ見つけて確実に回すほうが、費用対効果は桁違いに高い。
まとめ ― ツールは後でいい
ループエンジニアリングのバズに乗りたいなら、新しいエージェントツールをインストールする前に、紙とペンでいい、自分の業務を一つ取り出してInput / 作業(skill) / Output の3つの箱に入れてみてほしい。 箱に綺麗に収まり、Output の合否を言葉で書けたなら、それは今日からループにできる業務だ。収まらないなら、まだ言語化が足りない。
「プロンプトを書くのをやめろ」の本当の意味は、手を動かすのをやめて、自分の仕事の構造を書けということだ。流行はツールの顔をしてやってくるが、勝負はいつも、その手前の業務分析で決まっている。
参考
- Peter Steinberger / Addy Osmani — Loop Engineering（addyosmani.com）
- Anthropic — Building effective agents
- Anthropic — Effective context engineering for AI agents
- Andrej Karpathy — Software 3.0（YC/Sequoia 講演, 2025）
- Boris Cherny の発言・80%の出典まとめ — Loop engineering 解説記事（tosea.ai / explainx.ai）