はじめに

「ループ・エンジニアリング」と聞くと、難しそうに身構えるかもしれません。

でも中身は、「やってみる → 確かめる → 直す」を自動で繰り返すだけです。

AIエージェントを使っていると最近よく見かけるこの言葉を、初心者の方向けにゼロから整理するのが本記事です。

専門用語は本文の中と末尾の用語集で説明しますので、前提知識は不要です。

読むと得られるものは、次の3つを想定しています。

「ループ」と「1回ずつのプロンプト」の違いが分かる
ループを作る5つの要素と、その役割が分かる
自分の手元で小さく始めるための流れと、つまずきポイントが分かる

対象読者は、Claude Code や Cursor などのAIエージェントを触り始めた方、もしくは「ループという言葉は聞くが中身が曖昧」という方です。

本記事は、ループ・エンジニアリングを論じた複数の記事（末尾の参考文献）を出発点に、筆者が初心者向けに噛み砕いて再構成したものです。
用語の説明や図は、筆者の理解に基づく解釈です。
構成・文章の整理と図の作成には生成AI（Claude）を併用し、内容は筆者が確認しました。

先に結論（この記事の要点）

ループとは「プロンプトを与える→出力を見る→完了か判定する→未完なら投げ直す」を自動で繰り返す小さな仕組みです。
1回ずつ手でプロンプトを書く代わりに、その「繰り返し」自体を設計するのがループ・エンジニアリングです。
ループは5つの要素（トリガー / アクション / 証明 / メモリ / 停止条件）でできています。
いちばん大事で、いちばん抜けやすいのが「証明（どうなったら成功か）」と「停止条件（いつ止めるか）」です。
最初は、繰り返しが多くて成功判定がしやすい作業から、小さく始めるのがおすすめです。

一言でいうと

ループ・エンジニアリングを一言でいうと、「AIに仕事を任せて、合格するか行き詰まるまで自動で回す」ことです。

毎回プロンプトを手で打つのをやめて、その繰り返しを仕組みに任せる、という発想です。

この1行さえ持ち帰れば、あとの説明はすべてその肉付けだと考えてください。

ループとは何か

まず、いちばん大事な区別から始めます。

ふだん私たちは、AIエージェントに「これをやって」と1回ずつ頼みます。

これが「1回ずつのプロンプト（one-shot）」です。

一方の「ループ」は、その頼みごとを自動で繰り返す小さな仕組みです。

具体的には、次の4つを自動で回します。

あなたの代わりに、エージェントへプロンプトを与える
エージェントが出した結果を読む
完了したかどうかを判定する
まだなら、エラーや次の指示を添えて、もう一度プロンプトを与える

身近な例で言い換えます。

一発勝負の指示はこうです。

このページを速くして。

ループにすると、こうなります。

いちばん遅いページを見つけて、1か所だけ改善し、もう一度計測する。速くなったときだけ残す。全ページが目標を満たすか、これ以上よくならなくなるまで繰り返す。

違いは「フィードバックが組み込まれているか」です。

ループは「やってみる→確かめる→直す」を、人間が横に座らなくても回せる形にしたものです。

プロンプトの次に来るもの

ループは、いきなり現れた別物ではありません。

ふだんのプロンプトに、少しずつ部品を足していった先にあります。

①だけが「いつものプロンプト」です。

②で前提を渡し、③で成功の判定を足し、④でそれを繰り返しにすると「ループ」になります。

つまりループは、まったくの新概念ではなく、プロンプトの延長線上にある「次の一歩」です。

なぜループが必要なのか

「毎回手で指示すればいいのでは？」と思うかもしれません。

ループが効くのは、次のような場面です。

1回で終わらず、何度かやり直す前提の作業（バグ修正、テスト追加、ドキュメント更新など）
定期的に繰り返す作業（毎週のレポート、毎晩のログ点検など）
人が見ていない間も進めたい作業

もう1つ、見落としやすい理由があります。

エージェントに渡す指示や設定ファイルは、使っているうちに少しずつ崩れていきます。

ルールが増えすぎたり、昔の都合を引きずったりして、いつのまにか質が落ちます。

この「少しずつズレていく現象」は、英語では「ドリフト（drift）」と呼ばれます。

ループは、毎回きちんと成功を確かめる仕組みを持つので、このズレに気づきやすくなります。

ループを分解する ― 5つの要素

ここが本記事の中心です。

「ループ」という言葉を、いちど分解してみましょう。

多くのループは、次の5つの部品でできています。

たとえるなら、新人に仕事を任せる場面に似ています。

いつ頼むか（トリガー）、何を頼むか（アクション）、できたと判断する基準（証明）、やりとりの記録（メモリ）、いつ切り上げるか（停止条件）。

この5つを決めておくと、横についていなくても任せられます。

初心者の方は、まずこの5つの名前と役割を覚えれば十分です。

この図は「証明を満たさないときに停止へ抜ける」流れを示しています。

うまくいかないときに作業へ戻って繰り返す流れは、後の「進め方」の図で説明します。

トリガー（いつ始まるか）

ループが動き出すきっかけです。

「あなたが頼んだとき」「毎週金曜の朝」のような時刻、「PRにラベルが付いたら」のようなイベントが該当します。

始まる条件を決めておかないと、毎回その場の判断で起動することになり、再利用しにくくなります。

アクション（何をするか）

エージェントが実際に行う作業です。

「要約する」「レビューする」「テストを足す」「修正する」などです。

1回のループで1つの作業に絞ると、結果を確かめやすくなります。

証明（どうなったら成功か）

その作業がうまくいったと、どうやって分かるかです。

英語では proof や verify と呼ばれます。

「テストが全部通った」「目標の速度を満たした」のように、機械でも測れる形にするのがコツです。

「なんとなく良くなった」では、ループは止まりどきを判断できません。

メモリ（学びをどこに残すか）

ループが「何を試して、どうだったか」を保存する場所です。

ファイル、ボード、コミット履歴などが該当します。

AIは実行のたびに前回を忘れますが、ファイルは忘れません。

だから、状態は会話の中ではなくディスク（ファイル）に残します。

停止条件（いつ終わるか）

ループを止める条件です。

「成功したら止まる」「これ以上よくならなければ止まる」「3回失敗したら人に知らせる」などです。

これが弱いと、ループは延々と動き続け、時間と費用を無駄にします。

止まれるループは安心して任せられます。

止まれないループは、付きっきりの世話が必要になります。

ループの進め方（1サイクルの流れ）

5つの要素がそろうと、ループは次の流れで1周します。

ポイントは、1周で変える量を小さくすることです。

小さく変えて、そのつど確かめると、どの変更が効いたかが分かります。

うまくいけば残し、ダメなら元に戻します。

この「残すか戻すか」を毎回はっきりさせるのが、ループを信頼できるものにするコツです。

Pythonで動かす最小のループ例

言葉だけでは分かりにくいので、実際に動く小さなコードで5要素を体験します。

ここでは、AIエージェントの代わりに簡単な関数を使い、「ある値を目標（100）に近づける」ループを作ります。

作業役（worker）と検証役（evaluator）を、わざと別の関数に分けているのがポイントです。

動作確認は Python 3.6 以上（標準ライブラリのみ）で行っています。

loop_demo.py

# loop_demo.py — ループの5要素を最小コードで体験する例
# 実際のAIエージェントの代わりに、簡単な関数を「作業役」「検証役」として使います。
import json

TARGET = 100.0        # 目標（検証役が知っている品質基準）
TOLERANCE = 1.0       # この誤差以下なら成功とみなす（証明のしきい値）
MAX_ITERATIONS = 20   # 繰り返しの上限（停止条件のひとつ）


def worker(value, feedback):
    """作業役: フィードバックを受け取り、値を半分だけ目標へ近づける。"""
    return value + 0.5 * feedback


def evaluator(value):
    """検証役: 作業役とは別に、目標との誤差を測る。"""
    return abs(TARGET - value)


def run_loop(start):
    """トリガー: この関数を呼ぶとループが始まる。"""
    value = start
    error = evaluator(value)
    history = [{"iteration": 0, "value": value, "error": error}]

    for i in range(1, MAX_ITERATIONS + 1):
        feedback = TARGET - value               # 実行結果として返るフィードバック
        candidate = worker(value, feedback)     # アクション: 1回だけ変える
        candidate_error = evaluator(candidate)  # 証明: 良くなったか測る

        if candidate_error < error:             # 良くなったときだけ残す
            value, error = candidate, candidate_error
            kept = True
        else:                                   # 悪化したら戻す
            kept = False

        history.append({"iteration": i, "value": round(value, 4),
                        "error": round(error, 4), "kept": kept})

        if error <= TOLERANCE:                  # 停止条件1: 成功
            print(f"成功: {i}回で誤差 {error:.4f} に到達しました")
            break
    else:
        print(f"停止: 上限 {MAX_ITERATIONS} 回に到達しました（誤差 {error:.4f}）")  # 停止条件2: 上限

    with open("loop_history.json", "w", encoding="utf-8") as f:  # メモリ: 学びをファイルに残す
        json.dump(history, f, ensure_ascii=False, indent=2)
    return value, error


if __name__ == "__main__":
    final_value, final_error = run_loop(start=0.0)
    print(f"最終値: {final_value:.4f} / 誤差: {final_error:.4f}")

実行すると、次のように出力されます。

成功: 7回で誤差 0.7812 に到達しました
最終値: 99.2188 / 誤差: 0.7812

値は 0 → 50 → 75 → 87.5 → … と、毎回半分ずつ目標に近づきます。

そして誤差が 1.0 以下になった7回目で、ループは自分で止まります。

なお、同名の loop_history.json があると上書きされるので、試すときは上書きされても困らない場所で動かしてください。

このコードを5つの要素に対応づけると、次のようになります。

要素	コード上の場所
トリガー	`run_loop()` を呼ぶ
アクション	`worker()` で値を1回だけ変える
証明	`evaluator()` で誤差を測る（作業役と分けた検証役）
メモリ	`history` を `loop_history.json` に保存
停止条件	誤差が `TOLERANCE` 以下（成功）、または `MAX_ITERATIONS` 回（上限）

「良くなったときだけ残す（kept = True）／悪化したら戻す」という判定も入っています。

ここがループの心臓部です。

実際のAIエージェントでは、worker() はLLMやツールの呼び出しに、evaluator() はテスト・評価スクリプト・別エージェント・人のレビューなどに置き換わります。

骨格（実行→検証→残すか戻すか→停止）は、コードでもエージェントでも変わりません。

最小の始め方

最初から完璧なループを目指す必要はありません。

次の手順で、小さく始めるのがおすすめです。

繰り返す作業を1つ選ぶ: 定期レポート、テスト修正、ドキュメント更新など、何度も発生する作業にします。
範囲をきつく絞る: 「触るのはこのファイルだけ」のように、対象を限定します。
成功の証明を決める: 「テストが通る」など、機械でも測れる条件にします。
停止条件と上限を付ける: 「3回失敗したら人に通知」「20回で止める」など、暴走を止める線を引きます。
検証役を分ける: 作業した本人とは別の視点で採点させると、見落としが減ります。
状態をファイルに残す: 進捗や学びを、会話ではなくファイルに書きます。

特に「3. 証明」と「4. 停止条件」を先に決めておくと、暴走と費用の膨張を同時に防げます。

ループにすべきでないとき・つまずきポイント

ループは万能ではありません。

次の場合は、無理にループにしなくて構いません。

1回で終わる作業: やり直しが要らないなら、ループはむだな手間です。
ゴールが決まっていない探索: 「何かいい感じにして」は成功条件が無く、止まれません。
成功を自動で確かめにくい作業: 確認が「自分の目だけ」なら完全な自動化には早く、まずは人間のレビューを品質ゲートに組み込むのが安全です。

そしてつまずきは、たいてい単純な原因で起きます。

特に次の3つは、最初にやりがちな失敗です。

やってはいけない3つ（と、その防ぎ方）

成功条件を決めずに回す → 「テストが通る」など、機械で測れる条件を先に決める。
停止条件を付けずに回す → 「○回失敗したら人へ」など、止めどきを必ず付ける。
学びをファイルに残さない → 進捗や結果をファイルに書き、次回そこから始める。

裏を返すと、この3つを避けるだけで、ループはぐっと安定します。

用語集（よく出る言葉の説明）

本文に出てきた言葉を、まとめて説明します。

用語	読み・英語	意味
プロンプト	prompt	AIへの指示文。「これをやって」と伝える文章です。
AIエージェント	agent	指示を受けて、調べる・書く・実行するなどを自分で進めるAIです。
ループ	loop	「実行→確認→やり直し」を自動で繰り返す小さな仕組みです。
one-shot	ワンショット	1回きりの指示。繰り返しや学習が無い使い方です。
トリガー	trigger	ループが始まるきっかけ（時刻・イベントなど）です。
証明	proof / verify	作業が成功したと判定する根拠・検査のことです。
停止条件	stop condition	ループを止める条件。成功・行き詰まり・上限超過などです。
メモリ	memory	学びや進捗を残す場所。多くはファイルに書きます。
アーティファクト	artifact	作業を形づくる再利用可能な部品。指示書・チェックリスト・採点基準などです。
ルーブリック	rubric	採点基準表。「何が良くて何がダメか」を定義したものです。
検証役	evaluator	成果物を採点する役割。特に重要な成果物では、作業した本人と分けるのが安全です。
eval	評価	アーティファクトやループの良し悪しを、例を使って測ることです。
ドリフト	drift	指示や設定が、使ううちに少しずつズレて質が落ちる現象です。
誤green	―	テストが緑（合格）でも、実際は壊れている状態を見逃すことです。
オーケストレーション	orchestration	1人が多数のエージェントに仕事を割り振り、束ねることです。

次の一歩

基礎がつかめたら、次の順で進むと迷いません。

まず1つ動かす: 本記事のPythonコード例を、手元で実行してみます。
実例を使う: 公開ループ集「Loop Library」から近いループを探し、コピーして使います。
自分の業務へ: いつもの繰り返し作業を1つ選び、5要素に当てはめて小さくループ化します。

エンジニア向け（コードを書くシステムを設計する話）や、プロダクトマネージャー向け（プロダクト判断を反復させる話）の記事は、末尾の参考文献に挙げています。

どの記事も、本記事の5要素（トリガー / アクション / 証明 / メモリ / 停止条件）がそのまま土台になります。

まとめ

ループ・エンジニアリングは、「1回ずつプロンプトを書く」から「自動で回る仕組みを設計する」への切り替えです。

ループは5つの要素（トリガー / アクション / 証明 / メモリ / 停止条件）でできており、特に「証明（成功の判定）」と「停止条件（止めどき）」が要になります。

ここで大事なのは、AIに丸ごと任せる人で終わらず、「任せ方を設計する人」になることです。

ボタンを押す側ではなく、止めどきと合格基準を決める側に回る、という意識の変化が中心にあります。

なお、本記事のPythonコード例も、実際に動かして出力を確認しています。

難しく考えず、まずは身近な繰り返し作業を1つ選び、成功の条件と止めどきを決めるところから始めてみてください。

参考文献

elvis (@omarsar0), "From Prompting Agents to Loop Engineering"（ループの考え方の出発点）
Shubham Saboo (@Saboo_Shubham_), "Loop Engineering for Product Managers"（PM視点のループ論）
Matthew Berman の Loop Library（実例のループ集）: https://signals.forwardfuture.ai/loop-library/
関連記事「ループエンジニアリング入門（エンジニア向け）」: https://qiita.com/nogataka/items/60c1a9ba6b2cdebacc1f

本記事の構成・文章の整理と図の作成には生成AI（Claude）を併用しました。用語の説明・初心者向けの噛み砕きは筆者の解釈で、内容は筆者が確認しています。