ループエンジニアリングとは

このレッスンで分かること

• ループエンジニアリングが何を設計する考え方か
• 1回の指示で十分な仕事と、ループが必要な仕事の違い
• AIの反復を「作業中」ではなく「成果」で管理する方法
• 利用者が最後に終える操作から完了を決め、AIへの改善依頼を6欄の1枚にまとめる方法

ループエンジニアリングの基本

基本の流れは次の4段階です。

1. 何ができたら完了かを決める
2. 必要な行動を1つ実行する
3. AIの報告ではなく、成果物や実行結果を確認する
4. 完了・継続・人間への相談のどれかを選ぶ

1回の回答を良くするのがプロンプト設計なら、何度も続く仕事を安定して完了させる流れを作るのがループエンジニアリングです。

たとえば営業リスト作成なら、「100社調べて」と一度頼むだけでは、重複や対象外企業が混じるかもしれません。ループにすると、10社ずつ調査し、条件に合うか確認し、外れ方を次の10社の探し方へ反映できます。開発ではテスト結果、教材作成では読み手の理解度、問い合わせ対応では未解決件数が、次の行動を決める観測になります。

実際の運用では、1回の作業より長い単位もループにできます。

本講座が参考にする実運用のSprint Loopでは、利用者価値のある候補を順番に取り出し、実装し、検証し、本番へ届け、結果を測って次の改善へつなげます。AIに作業を繰り返させるだけでなく、価値の低い改善へ逃げない仕組み、人間の承認が必要な境界、同じ失敗を繰り返さない停止条件まで含めて設計しています。

このレッスンでは全体像だけをつかみます。続くレッスンで、この運用を支える設計図と検証・停止ルールを順に分解します。

ループを回す機能が、AI Agentに組み込まれた

2026年9月までに、CodexとClaude Codeに「ゴールを渡すと、達成するまで自分で作業を続ける」機能が組み込まれました。

• Codex の /goal 機能：長く続く仕事に、同じスレッドの中で保たれる目標を与えます（別のスレッドには引き継がれません）。OpenAIは、人が入力しなくても何時間も作業を続けられると説明しています
• Claude Code の /goal 機能：作業を終えようとするたびに条件を満たしたかを確かめ、満たしていなければ続けさせます（その会話の間だけ有効）
• Claude Code の /loop 機能：同じ指示を、指定した間隔で繰り返します（間隔を指定しなければClaudeが選びます）

ループを回す仕組みは、自分で作らなくても手に入るようになりました。それでも、この講座で学ぶ設計は要らなくなりません。ツールが回してくれるのは「繰り返し」だけで、何を完了とし、何を証拠にし、いつ止めるかは人が決めて渡すからです。/goal に渡す数行の質が、ループ全体の質を決めます。

うまく設計しないと何が起きるか

金曜の夕方、AI Agent のログには「タスクを投げた」「状態を確認した」「再開した」という報告が200行並んでいました。エラーはありません。

ところが月曜に成果物を数えると、完了した項目はゼロでした。止まっていないため、誰も異常に気づかなかったのです。

ループで危ないのは、止まることよりも、進んでいないのに進んでいるように見えることです。

この失敗を防ぐには、AIへの指示だけでなく、「何を見て前進と判断するか」まで設計する必要があります。

その仕事は、本当に回すべきか

最初の判断は「どう回すか」ではなく、回す必要があるかです。

手順と回数が最初から決まっている仕事は、固定した手順や1回の指示のほうが速く、安く、確認もしやすくなります。ループが向くのは、結果を見ないと次の行動を決められない仕事です。

観点	1回の指示・固定手順	ループ
次の行動	開始時点で決められる	実行結果を見ないと決められない
完了までの手数	先に数えられる	開始時点では読み切れない
確認の置き方	最後にまとめて確認する	1周ごとに結果を確認する

左列で足りるなら、まず単純な手順を使います。右列に当てはまる仕事だけをループにしてください。Anthropicも、単純な方法から始め、必要なときだけエージェント構成を複雑にするよう勧めています。

ループを支える3つの型

代表的な考え方は次の3つです。名前よりも、どの失敗を防ぐかで覚えましょう。

型	何をするか	防ぐ失敗
ReAct	考えることと行動を交互にし、外部の情報や実行結果を取り込む	思い込みだけで最後まで進む
Reflexion	失敗の理由を言葉で残し、次の試行へ渡す	同じ失敗を繰り返す
evaluator-optimizer	作る役と評価する役を分け、基準に照らしてやり直す	自分の成果物へ甘い判定を出す

どの型にも共通するのは、AI自身の説明だけで完了を決めず、外から確認できる結果を使うことです。

3つの型でも残る失敗

型をそろえても、「本当に進んだか」の判定が曖昧なら、冒頭の失敗は残ります。

この講座では、1周ごとに次のどれかが増えたときだけ前進と数えます。

• 完了した成果物
• 確定した事実
• 解消した不明点

「依頼を投げた」「状態を見た」は行動の記録であって、単独では前進ではありません。合計がゼロなら、同じループを続けず、タスクの切り方や完了条件を見直します。

完成例：動く画面ではなく、申込みまで終えられる導線を作る

機能があっても、使う人が目的を達成できるとは限りません。実際の講座では相談する仕組みが存在していたのに、読者がそこへ進むリンクがありませんでした。どこから来た人が何を終えたいのかを先に決めると、作るべき変更を小さくできます。

図の内容を文章でも示します。読者が目的を終えるまでの流れは、次の5段階です。完了を判定する単位は「画面が動いた」ではなく、「読者が⑤の受付まで終えられた」です。

1. 来訪 — 講座のページを開く
2. 無料の本文を読む
3. 内容と費用を確認する（改善前は、②からここへ進む案内がなかった）
4. 申し込む — すでにある受付フォームを使う
5. 受付 — 相談を送り終える

確認できたことと、まだ分からないこと

当社（株式会社COMPASS）の公開講座の1つで、2026年9月29日に次のことを確認しました。

• 観測：講座ページ・各レッスン・無料プレビューの計12ページに、相談の受付へ進むリンクが1つもなかった
• 観測：相談の受付フォームと、相談料金を載せた講師のプロフィールはすでに存在していた
• 変更：新しい仕組みは作らず、講座ページ・無料プレビューの末尾・最後の演習の末尾に、既存の受付へつながる「この講座の内容で相談する」カードを表示した
• 未測定：カードを追加したことで相談や売上が増えたかは、まだ測定していない

足りなかったのは仕組みではなく、読者がそこまでたどり着く道でした。前の節の「行動の記録は前進ではない」と同じで、自動テストが通った、画面が表示された、というだけでは、利用者が最後の操作を終えられた証拠になりません。そして効果は、測るまでは「未測定」と書きます。

持ち帰る1枚：6欄の依頼書（記入見本）

AIに改善を頼む前に、次の6欄を埋めます。上の実例で書いた見本です。

• 1. 誰の課題：講座を読み、自社に当てはめたいが1人では判断しきれない読者
• 2. 完成してほしい行動：講座の内容と相談料金を確認し、その講座について相談を1件送る
• 3. 変更する箇所：講座ページ・無料部分の末尾・最後の演習の末尾から、既存の受付へつなぐ
• 4. やらないこと：新しい顧客管理の仕組み、予約システム、一斉配信
• 5. 正常・失敗時の確認：ログインしていない状態で講座から受付まで進めるか。入力を誤ったとき、入力内容を失わずに直せるか
• 6. 追加開発を止める条件：受付まで進めることを確かめたら止める。入口への到達数と受付の実数を見てから、次に直す1箇所を選ぶ

2欄目が、ループでいう「何ができたら完了か」にあたります。6欄目は「いつ止めるか」です。まずは自分の仕事で、1欄目と2欄目だけでも書いてみてください。

1. 誰の課題：
2. 完成してほしい行動：
3. 変更する箇所：
4. やらないこと：
5. 正常・失敗時の確認：
6. 追加開発を止める条件：

まとめ

• ループエンジニアリングは、AIへの指示ではなく、行動・観測・判定の流れ全体を設計する
• 手順を決められる仕事は単純な方法を使い、結果を見て次を変える仕事だけをループにする
• 3つの型を使っても、前進を証明する基準は現場ごとに決める必要がある
• 完了は「機能が動く」ではなく「利用者が目的の操作を終えられる」で判定し、効果は測るまで未測定と書く

この先で、会話を「運用」に変える

ここまでで見たのは、ループの入口です。この先では、実際に運用できる形へ一段ずつ組み立てます。

1. ループの設計図を作る — 目標、入力、使える道具、状態、完了条件を決める
2. 検証と停止のルールを入れる — AIの自己申告ではなく証拠で判定し、暴走や空回りを止める
3. 自分の仕事へ落とし込む — 開発に限らず、結果を見て次を変える仕事を実際のループにする。最初に、上の6欄をAIに作らせて人が確かめる演習、よくある誤答とその直し方、相談ではなく有料講座の購入に置き換えるときの書き換え方を扱う

続きを自分で進める場合、相談は必要ありません。自社の業務への当てはめ方を個別に判断したい場合は、講座ページや無料公開ページに表示される講師カードから、この講座の内容で相談できます。相談料金はカードに表示しています。

次のレッスンでは、実運用のSprint Loopでも使う考え方を、まず1枚の設計図へ落とします。

振り返りとして、次の3点を考えてみてください。

• 自分の仕事で、結果を見ないと次の行動を決められないものは何ですか
• その仕事では、何が増えたら「1周進んだ」と言えますか
• その仕事の利用者が最後に終えるべき操作は何ですか

出典・クレジット

冒頭の事例と、成果物・事実・不明点で前進を数える基準は、株式会社COMPASSが自社プロダクト開発で複数のAI Agentを運用した際の実測にもとづく自社作成の内容です。

相談導線の完成例は、株式会社COMPASSが自社の公開講座で2026年9月29日に確認した記録にもとづく自社作成の内容です。表の「未測定」のとおり、カード追加後の効果はまだ測定していません。

• Anthropic「Building effective agents」 https://www.anthropic.com/engineering/building-effective-agents — 単純な方法から始める判断、環境から得た結果による進捗確認、evaluator-optimizerを参照（2026-08-31確認）
• IBM「What Is Loop Engineering?」 https://www.ibm.com/think/topics/loop-engineering — ループエンジニアリングの定義、Goal・Action・Observation・Adjustmentの循環、プロンプト設計との違いを参照（2026-08-31確認）
• ReAct: Synergizing Reasoning and Acting in Language Models https://arxiv.org/abs/2210.03629 — 推論と行動を交互に行う枠組みを参照（2026-08-31確認）
• Reflexion: Language Agents with Verbal Reinforcement Learning https://arxiv.org/abs/2303.11366 — 言語化したフィードバックを次の試行へ持ち越す枠組みを参照（2026-08-31確認）
• OpenAI「Follow a goal」「Using Goals in Codex」、Anthropic「Claude Code Docs」（/goal・/loop）— Codex と Claude Code に組み込まれたループ機能の仕様を参照（2026-10-01確認）