ループエンジニアリングとは｜AIを回し続ける仕組みの作り方と止め方

結論​（即答）​: ループエンジニアリングとは

ループエンジニアリングとは、​AIに​指示を​出す役を​人から​仕組みに​移す設計です。

AIが​仕事を​始め、​結果を​検証し、​足りなければ​直してもう​一周します。​人は​その輪の​外から​監督し、​例外と​最終判断だけを​引き受けます。

設計の​中身は​大きく​3つです。

• 何を​きっかけに、​何を​指示するか
• 結果を​誰が、​何を​基準に​合否判定するか
• どこで​止めるか

当社では、​3つ目の​止め方を​先に​決めています。​止め方の​ないループは、​ミスと​API利用料を​人の​見ていないところで​積み上げます。

誰が​言い出したか​（由来）

言い出したのは、​AIで​コードを​書く​現場の​3人です。​2026年6月上旬に​相次いで​発信しました。

Cherny の​発言は、​主催した​ WorkOS が​2026年6月2日付の​公式ブログで​要点を​公開しています。​Steinberger の​投稿は​6月7日​（米国時間）です。​Osmani の​ブログ記事は​同じ​6月7日付で、​2人の​発言を​引用しています。

Osmani は​次の​2文で​定義しています。​「ループエンジニアリングとは、​エージェントに​指示を​出す人と​しての​自分を​置き換える​ことだ。​代わりに、​その​指示出しを​担う​システムを​設計する」。

ralph loop との​関係

名前が​付く​前から、​素朴なループは​使われていました。

代表例が​ Geoffrey Huntley の​「ralph」です。​2025年7月14日の​ブログ記事で、​同じ​指示書を​ Claude Code に​渡し続ける​手法と​して​紹介されました。​中身は​シェルの​1行です。

while :; do cat PROMPT.md | claude-code ; done

ralph は​「止めない」ことを​前提に、​状態を​ファイルと​gitに​残して​回します。​ループエンジニアリングは、​そこに​検証役と​停止条件を​足して、​設計の​対象に​したものです。​当社の​ codex_loop も、​この​系統に​停止装置を​付けた形です。

普通の​自動化​（Cron）と​何が​違うか

違いは​前の​結果を​見て​次の​手を​変えるか​どうかです。

Cronは​決まった​時刻に​同じ​処理を​実行します。​前回​うまく​いったか​どうかで​中身は​変わりません。​ループは​結果を​検証し、​不合格なら​原因を​踏まえて​次の​指示を​組み立て​直します。

当社の​社内ルールには​「Cronで​足りるものを​ループに​しない」と​書いています。​仕事の​種類ごとの​型は​次のとおりです。

毎朝の​ニュース収集を​ループに​しても、​得るものは​ほとんど​ありません。​止まらない​仕組みが​1つ増えるだけです。​ループに​向くのは、​前の​周の​結果が​次の​周の​中身を​決める​仕事です。

4段階の​進化​（プロンプト→コンテキスト→ハーネス→ループ）

ループは、​これまでの​3つの​工夫を​土台に​した​4段目です。

@IT や​ Findy Team+ などの​解説記事は、​おおむね次の​4段階で​説明しています。

1. プロンプトエンジニアリング: 1回の​頼み方を​工夫する
2. コンテキストエンジニアリング: 仕様や​履歴など、​判断材料の​全体を​整える
3. ハーネスエンジニアリング: テスト・権限・承認の​関門など、​安全な​作業場を​作る
4. ループエンジニアリング: 指示を​出して​動か​し始める​部分まで​仕組みに​する

前の​段階を​捨てるわけでは​ありません。​ループの​中には、​良い​プロンプトも、​整った​判断材料も、​安全な​作業場も​入っています。​4段目だけを​作っても、​下の​3段が​弱ければ​同じ​失敗を​速く​繰り返すだけです。

それぞれの​言葉が​生まれた​時期は​近接しています。

コンテキストエンジニアリングは​2025年6月、​Shopify の​CEOが​Xで​提案して​広まったとされます。​ハーネスエンジニアリングは、​HashiCorp の​共同創業者が​2026年2月の​ブログで​名付けたとされます。

ループエンジニアリングは​2026年6月です。​約1年で​4段目まで​進みました。

ハーネスとの​違い

ハーネスは​「AIが​作業する​場の​安全装置」、​ループは​「その​場で​AIを​何度も​動かす運転の​仕組み」です。

ハーネスに​入るのは、​テスト、​lint​（書式の​自動検査）、​権限の​制限、​承認の​関門、​ログなどです。​1回の​作業を​安全に​する​道具立てに​あたります。

ループは​そこに​「いつ​始めるか」​「合否を​誰が​決めるか」​「いつ​止めるか」を​足します。​ハーネスの​ないループは、​誰も​気付かないまま​ミスを​重ねて​周回します。

Human in the Loop から​ Human on the Loop へ

人の​立ち位置は、​工程の​中から​外側へ​移ります。

• Human in the Loop: AIの​各工程に​人が​入り、​指示し、​確認し、​直す
• Human on the Loop: 普段の​処理は​AIが​回し、​人は​外から​監督する。​例外、​方向修正、​最終判断だけを​受け持つ

人を​ゼロに​するわけでは​ありません。​人を​置く​場所と、​見る​頻度を​決め直します。​当社で​人の​承認を​残している​場面は、​後の​「当社の​ルール」の​章で​挙げます。

ループの​6つの​構成要素と​当社での​実物

Osmani は、​ループを​組む部品を​6つに​分けています。​当社の​実物を​並べると​次のとおりです。

ワークツリーは、​同じリポジトリで​複数の​AIを​同時に​書かせるときに​要ります。​当社は​AIに​書かせる​作業を​1本ずつ順に​回しているので、​今は​使っていません。

ループは​周を​またぐと​会話の​中身を​忘れます。​その​ため、​状態を​ファイルに​残す部品が​欠かせません。​前の​周の​「持ち越し」を​ファイルに​書き出す決まりは、​この​忘却への​対策です。

Claude Code で​組む: /goal・/loop・hooks・Routines の​使い分け

Claude Code には、​ループを​組む仕組みが​4つ用意されています。​次の​周を​何が​始めるかで​選びます。

以下は​公式ドキュメントで​確認した​仕様です。

• /goal: 完了条件を​書くと、​毎ターンの​後に​小型モデル​（既定は​ Haiku）が​条件を​満た​したか​判定します。​条件は​4,000字まで​書けます。​回数の​上限を​付けたいときは、​条件に​「20ターンで​止める」のような​一文を​足します​（公式）。
• /loop: 会話を​開いている​間だけ、​同じ​指示を​一定間隔で​繰り返します。​1つの​会話に​置ける​予定は​50件までです。​定期の​タスクは​作ってから​7日で​消えます。​忘れた​ループが​回り続けないための​上限です​（公式）。
• Routines: パソコンを​閉じていても​クラウドで​動きます。​研究プレビュー​（試験提供）の​扱いで、​1日に​始められる​実行回数に​上限が​あります。​Pro、​Max、​Team、​Enterprise の​各プランで​使えます​（公式）。

/goal は​測れる​ゴールまで​粘る​仕組みです。​/loop は​会話中の​見張り役です。​Routines は、​会話と​関係なく​定期で​回します。

当社では​ hooks を​多く​使っています。

• 会話の​終わりに、​引き継ぎノートを​自動で​書き出す
• 会話の​要約​（圧縮）の​前に、​進み具合を​保存する
• 危険な​シェルコマンドを​実行前に​止める
• 3ファイル以上の​変更は、​コミット前に​別モデルの​レビューを​通す

/loop に​当たる​運用は、​会話の​中で​「3周回して」と​頼む型と​して​決めています​（次の​章の​4つの​型）。

/goal に​当たるのは​ codex_loop です。​週次リサーチは、​Routines の​定義が​7月26日に​消える​事故を​受けて、​macOSの​定時実行に​移しました。

当社の​ルール:​ 止め方を​先に​決める​（停止3点セット・検証役は​別モデル・経営判断は​回さない）

当社では​止め方が​決まっていないループを​起動しない​決まりに​しています。

社内ルールでは、​次の​3つを​「停止3点セット」と​呼んでいます。

1. 回数・​時間の​上限: 最大何周、​または​何分で​打ち切るかを​先に​決める
2. 差分ゼロ検出: 前の​周と​出力や​差分が​同じなら​止める。​同じ​エラーが​3回続いた​場合も​止める
3. 費用の​上限: コール数や​金額を​記録し、​超えそうなら​止める

4つ目と​して、​人の​承認も​停止条件に​数えています。​外部への​送信、​公開、​課金の​変更の​前では、​いったん止まって​人に​確認する​決まりです。​2つの​審査モデルの​判定が​割れたときも、​事業の​顔に​なる​制作物なら​両方の​意見を​人に​見せる​運用に​しました。

回数・​時間の​上限、​差分ゼロ検出、​費用の​上限の​うち1つでも​欠けたものは、​ループとは​呼ばない​扱いに​しています。​欠けたまま回すと、​ミスも​費用も​上限なく​増えるからです。

3点セットの​ほかに、​次の​決まりが​あります。

• 完了条件は​1文で​機械的に​判定できる​形に​する。​ ​「いい​感じに」は​完了条件に​なりません。
• 検証役は​実行役と​別の​モデルに​する。​ 同じ​モデルが​兼ねると、​見逃しの​癖まで​同じに​なるからです。
• 「できました」と​いう​自己申告を​信じない。​ 実際の​ファイル、​URL、​テスト結果で​確かめます。
• 監視の​ない​自動化を​作らない。​ 失敗したら​通知を​出し、​週1回の​点検で​動いているかを​見ます。
• AIに​ログを​丸ごと​渡さない。​ エラー、​終了コード、​差分だけを​抜き出して​渡します。

経営判断、​戦略、​要件定義は​ループにしません。​回り​始めると、​出てきた​答えを​そのまま​受け入れたくなるからです。

判断を​仕組みに​預けると、​自分の​意見を​持たなくなる​危険が​あります。​判断は​人が​AIと​話しながら​行います。

社内で​AIに​「3周回して」と​頼むときの​型も​決めています。

• 正解の​ない​制作物を​磨く​: 競作改善型。​最大10周
• 調査や​原因究明を​深める​: 深掘り反復型。​2周続けて​新しい​発見が​なければ​終わり
• テストやビルドのように​合否が​ある​: 修理検証型。​修正3回で​止めて​報告
• 前の​周から​持ち越すものが​ない​: ループに​せず、​並列で​回す

計画を​立てるのは​1周目だけです。​2周目以降の​中身は、​前の​周で​書き出した​「持ち越し」が​決めます。​5周分の​TODOを​先に​作って​順に​消すやり方は、​分割した​並列作業と​変わりません。

業界で​言われる​課題と​当社の​対策

Osmani は、​ループの​課題を​6つ挙げています。​そのうち、​当社の​対策に​対応づけられる​4つを​並べました。

残る​2つは、​複数の​AIを​束ねる​手間​（オーケストレーションの​手間）と、​意図の​負債です。​意図の​負債は、​何を​狙った​仕組みかが​記録されず​後から​分から​なくなる​状態を​指します。​当社では、​この​2つに​専用の​対策は​まだ​ありません。

実際に​回している​ループ3つ​（moa-loop / codex_loop / 週次リサーチ）の​数字

3つとも、​上限と​停止条件を​起動前に​固定しています。

moa-loop は​正解の​ない​制作物を​磨く​ループです。​3つの​モデル​（Opus 5.5、​Grok 4.6、​DeepSeek）に​同じ​依頼を​並行で​出します。

できた案を​匿名で​相互に​批評させ、​2つの​モデル​（Fable 5.1 と​ GPT-5.6）が​審査して​改善を​指示します。​この​2つは​生成には​加わりません。​自分の​案を​自分で​採点させないためです。

codex_loop は​実装して​テストを​通すまでの​ループです。​検証コマンドを​指定しないと​起動しません。

周ごとに​作業フォルダの​状態を​記録し、​前の​周と​同じなら​止めます。​オプションで、​実装とは​別の​モデル​（DeepSeek）に​差分を​判定させる​こともできます。

週次リサーチ は​毎週日曜17時台に​動く​レポートの​自動作成です。​これは​厳密には​ループでは​ありません。​毎週同じ形の​成果物を​出す仕事なので、​Cron＋品質チェックの​型を​選びました。

moa-loopの​1周は、​生成3、​相互批評3、​審査2の​最大8コールです。​総コールの​上限は​60で、​周回の​上限は​10周です。​10周の​前でも、​60コールに​達した​時点で​止まります。

当社の​運用​（2026年7〜9月）では、​多くの​依頼が​2〜3周で​収束しました。

従量課金の​ Grok と​ DeepSeek は​1コール1円未満です。​この​2つの​分は​1周あたり数円です。​Opus は​定額の​サブスクリプションの​範囲内で​動かしています。

週次リサーチには​「失敗を​知らせずに​終わらない」​決まりが​あります。​収集ゼロ、​生成失敗、​ビルド失敗、​公開失敗の​どれでも、​その​時点で​失敗を​通知します。​この​決まりは、​取り込み処理が​7日間止まっていた​事故から​生まれました。

一般的な​分類との​対応

解説記事で​使われる​分類に、​当社の​ループを​当てはめました。

• 4分類​（Turn / Goal / Time / Proactive）は、​起動と​停止を​誰が​担うかで​分けます。​Turn は​人の​指示で​動き、​人の​確認で​止まる型です。​Goal は、​測れる​ゴールに​届くまで​回ります。​Time は​時刻で​起動し、​Proactive は​イベントを​受けて​AIが​自分で​完了を​判断する​型です。​Zenn の​解説記事​（2026年7月19日）は、​これを​ Anthropic の​分類と​して​紹介しています。
• 2分類​（定周期モニタリング型 / ゴール収束型）は、​Findy Team+ の​解説記事の​分け方です。​前者は​一定間隔で​状態を​見に​行き、​後者は​完了条件を​満たしたら​止まります。

当社は​ Proactive を​使っていません。​AI自身が​完了を​決める​型は、​止め方が​甘くなりやすいからです。​イベントで​起動する​場合も、​完了の​判断は​人か別の​検証役に​残しています。

失敗から​学んだ​こと​（事故4件と​対策）

当社の​ルールの​多くは、​実際の​事故の​後で​書き足したものです。

1. 並列実行と​自動再起動が​重なり、​Macが​落ちた​（2026年4月）​ 音声の​文字起こしを​GPUで​4本並列に​しました。​さらに、​止まったら​5分ごとに​再起動する​見張り役を​付けていました。​処理が​重なって​メモリを​使い​切り、​Mac本体が​クラッシュしました。

いまは​GPUを​使う​処理を​1本ずつ動かすのが​既定です。​見張り役の​間隔は​15分以上にしました。​前の​ジョブが​生きていたら​新しく​起動しない​確認も​入れています。

2. 完了を​待つ処理が​終わらなくなった​（2026年5月）​ デプロイの​完了を​裏で定期確認する​処理が、​条件を​満た​せず​回り続けました。​4回タイムアウトしてから​気付きました。

いまは​確認方法を​単純な​HTTP取得と​文字列検索に​変えました。​裏で​起動した​直後に、​1回出力を​確かめる​手順も​足しました。

3. 取り込み処理が​7日間、​誰にも​気付かれず止まっていた​（2026年6〜7月）​ 実行環境の​Python を​切り替えた​影響で、​メモの​取り込みが​毎回失敗していました。​失敗を​誰にも​知らせない​作りだった​ため、​気付くまで​7日かかりました。​この​件以降、​自動化には​失敗時の​通知と、​週1回の​点検を​付ける​決まりに​しました。

4. ブラウザを​8本並列に​して、​操作不能に​なった​（2026年9月）​ 画面確認用の​ブラウザを​8本同時に​動かしたところ、​ロードアベレージ​（1分平均）が​67まで​上がりました。​メモリ不足を​補う​スワップ領域も、​ほぼ満杯に​なりました。​ブラウザを​使う​検証も、​いまは​1本ずつ順番に​回しています。

社外では​PR​（コード変更の​提案）を​自動修正する​ループの​例が​報告されています。​報道では、​修正の​範囲が​際限なく​広がり、​ほとんどの​PRが​却下されたとされています。

原因は​「いい​感じに​直して」と​いう​曖昧な​指示でした。​当社の​「完了条件は​1文で​機械的に​判定できる​形に​する」は、​この​例を​参考に​しています。

うまく​いった​公開事例も​あります。​2026年8月25日の​ ZOZO の​技術ブログ記事です。

記事名は​「ループエンジニアリング​実践：プロンプトチューニングを​Claude Codeに​任せてみた」です。​分析、​計画、​改善、​評価、​振り返りを​別々の​サブエージェントに​分けています。

止める​条件は​「目標の​精度に​届く」​「最大10回」​「3回続けて​改善が​ごく​小さい」の​3つでした。​作業期間は​約3.5週間から​約1週間に​縮んだと​報告しています。

一方で、​試行は​1回きりで​再現性は​未確認だとも​書いています。​プロンプトが​膨らみ続ける​点にも​注意を​促しています。

何から​始めるか​（小さく​1本・型の​選び方）

最初は​完了条件を​1文で​書ける​小さな​仕事を​1本だけ​選びます。

候補を​選ぶときは、​次の​順に​確かめます。

1. 毎回同じ​仕事か​: 同じなら​Cronで​十分です。​ループにしません。
2. 合否を​機械で​判定できるか​: テスト、​ビルド、​文字数などです。​判定できれば​修理検証型から​始めます。
3. 正解の​ない​制作物か​: 別モデルに​審査させる​競作改善型にします。​審査の​基準を​1文で​書いてから​始めます。
4. 判断や​戦略か​: ループにしません。

型が​決まったら、​起動前に​次の​4つを​書き出します。

• 完了条件を​1文で​書く
• 最大の​周回数と​時間を​決める
• 前の​周と​同じ​結果が​出たら​止めると​決める
• 費用の​上限を​コール数か​金額で​決める

ここまで​書ければ、​最初の​ループは​動かせます。​外部への​送信や​公開、​課金の​変更を​含む​場合は、​人の​承認を​挟む関門を​残してください。

1か​月動かしたら、​実行回数、​失敗の​回数、​上限に​達した​回数、​かかった​費用を​見直します。​当社では、​仕組みの​中身を​自分で​説明できるかも​確かめています。​説明できない​仕組みは、​止まったときに​直せないからです。

非エンジニアでも​作れるか

作れます。​当社の​代表は​非エンジニアで、​コードは​読みません。

この​記事で​紹介したルールは、​代表が​自分で​決めて、​Claude Code と​一緒に​文章に​したものです。​停止3点セットも、​事故の​たびに​代表と​AIで​書き足してきました。

コードを​書く​部分は、​AIに​任せられます。​人が​決める​必要が​あるのは、​次の​3つです。

• 何ができたら​完了か
• どこで​止めるか
• どこで​人が​確認するか

この​3つは、​業務を​知っている​人の​ほうが​正確に​決められます。

始めるときは、​次の​3段階で​進めるのが​安全です。

1. 監視: AIは​読むだけ。​数字や​状態を​集めて、​人に​知らせる
2. 半自動: AIが​案を​作り、​人が​承認してから​実行する
3. 自動: 機械で​合否を​判定できる​部分だけ、​人の​承認を​外す

1段目で​1か​月ほど​回し、​誤報や​取り​こぼしの​数を​見てから​次へ​進みます。​当社でも、​外部への​送信と​公開は​今も​2段目にと​どめています。

よく​ある​質問

Q. プロンプトエンジニアリングとの​違いは？​ プロンプトエンジニアリングは、​1回の​頼み方を​工夫する​技術です。​ループエンジニアリングは、​その​頼み事を​「いつ出すか」​「結果を​どう​判定するか」​「いつ​止めるか」まで​仕組みにします。​良い​プロンプトは、​ループの​中で​今も​必要です。

Q. ハーネスエンジニアリングとの​違いは？​ ハーネスは、​AIが​安全に​作業する​ための​場（テスト、​権限、​承認の​関門など）です。​ループは、​その場で​AIを​繰り返し動かす運転の​仕組みです。​ハーネスが​弱いままループを​組むと、​同じ​失敗を​速く​繰り返します。

Q. Cron や​ GitHub Actions との​違いは？​ Cron や​ GitHub Actions は、​決まった​時刻や​イベントで​同じ​処理を​動かします。​ループは​結果を​検証し、​不合格なら次の​手を​変えてもう​一周します。​Cron は​ループの​「起動役」と​して、​ループの​中で​使われる​ことがあります。

Q. 向いている​タスク、​向いていない​タスクは？​ 向いているのは、​合否を​機械で​判定できる​仕事​（テストを​通す、​文字数に​収める）です。​別モデルに​審査させられる​制作物も​向いています。​向いていないのは、​経営判断、​戦略、​要件定義のように​正解を​人が​決める​仕事です。​毎回同じ​処理なら、​ループに​せずCronで​足ります。

Q. Claude Code 以外​（Codex など）でもできますか？​ できます。​OpenAI の​ Codex にも、​ゴールまで​作業を​続ける​ /goal が​あります。​当社の​ codex_loop は、​Codex を​外側の​スクリプトから​呼び、​停止装置も​そこに​付けています。​道具よりも、​完了条件と​停止条件の​設計の​ほうが​結果を​左右します。

Q. Claude Code では​何を​準備すれば​よいですか？​ まず、​完了条件を​1文で​書きます。​次に、​検証に​使う​コマンド​（テストなど）を​用意します。​回数の​上限も、​条件の​中に​書き添えて​おきます。

Q. /goal と​ /loop の​違いは？​ /goal は​ゴールを​満たすまで​ターンを​続け、​小型モデルが​達成を​判定します。​/loop は​決めた​間隔で​同じ​指示を​繰り返し、​7日で​自動的に​消えます。​測れる​ゴールが​あるなら​ /goal、​状態を​定期的に​確かめたいなら​ /loop です。

Q. 費用は​どれくらい​増えますか？​ 周を​重ねる​ほど、​前の​周の​文脈が​積み​上がって​入力が​膨らみます。

OptiMax の​AI情報記事​（2026年6月11日）は、​Unblocked 社の​試算を​紹介しています。​単発の​呼び出しと​比べて、​5ステップで​約3.2倍、​200ステップで​100倍超です。​当社の​ moa-loop では、​従量課金の​ Grok と​ DeepSeek の​分は​1周あたり数円です。​上限を​先に​決めれば、​最大の​損失額が​事前に​決まります。

Q. 非エンジニアでも​作れますか？​ 作れます。​当社の​代表は​非エンジニアで、​ルールを​自分で​決め、​AIと​一緒に​文章に​して​運用しています。​人が​決めるのは​「完了条件」​「止める​場所」​「人が​確認する​場所」の​3つです。​コードは​AIに​書かせられます。

Q. 暴走を​防ぐ​停止条件は？​ 当社は、​回数・​時間の​上限、​差分ゼロ検出、​費用の​上限の​3つを​最低条件に​しています。​加えて、​外部への​送信や​公開の​前には​人の​承認を​挟みます。​同じ​エラーが​3回続いたときも​止めます。

Q. Human in the Loop との​違いは？​ Human in the Loop は、​AIの​各工程に​人が​入って​確認する​形です。​ループエンジニアリングが​目指すのは​ Human on the Loop です。​人は​外側から​監督し、​例外と​最終判断を​受け持ちます。​当社では、​仕事ごとに​人を​置く​場所を​選んでいます。

まとめ

ループエンジニアリングは、​AIを​回す仕組みと​止める​仕組みを​一緒に​設計する​仕事です。

• AIへの​指示出しを​仕組みに​移し、​人は​外側で​監督と​判断を​担う
• 毎日同じ​仕事は​Cronで​足りる。​ループは​前の​結果で​次の​手が​変わる​仕事に​使う
• 回数・​時間の​上限、​差分ゼロ検出、​費用の​上限の​3つが​揃​うまで​起動しない
• 検証役は​実行役と​別の​モデルにし、​自己申告を​信じない
• 経営判断は​ループに​しない。​外部送信と​公開の​前は​人が​承認する
• Claude Code では、​ゴールは​ /goal、​見張りは​ /loop、​定期実行は​ Routines で​組む
• 失敗したら​知らせる​仕組みを​最初から​付ける

当社の​事故4件は、​どれも​止まる​条件か​知らせる​仕組みの​欠けから​起きました。​回し方の​工夫より​先に、​止め方を​決める​ことを​おすすめします。

社内で​AIの​自動化を​設計したい、​AI利用の​ルールを​作りたいと​いう​場合は、​当社の​事例をもとに​ご相談に​乗れます。​検討の​段階でもかまいません。​ AIの​自動化設計に​ついて​相談する