「私はもうClaudeにプロンプトを打っていない。プロンプトを打って次に何をすべきか考えるループを走らせているだけだ。私の仕事はループを書くことだ」
── Boris Cherny（Anthropic Claude Code 責任者）, 2026年6月
目次
- はじめに ── なぜ今「ループ」なのか
- ループエンジニアリングとは何か
- 設計思想の進化 ── 4つの階段
- エージェントループの土台 ── ReAct と Reflexion
- インナーループ vs アウターループ
- ループを構成する「5+1」の部品
- 代表的なループ実装の比較
- 安全に回すための4つの必須要素
- エンドツーエンドのループ設計例
- リスクと限界 ── ループが解決しないもの
- ベストプラクティスまとめ
- おわりに ── エンジニアの役割はどう変わるか
- 参考文献
1. はじめに ── なぜ今「ループ」なのか
2024年は「良いプロンプトを書く」ことが腕の見せどころでした。2025年は複数のAIエージェントを並列実行する時代。そして2026年6月 ── AIとの付き合い方に、もう一段の進化が起きています。
火付け役は3人の発言でした：
| 人物 | 所属 | 発言の趣旨 |
|---|---|---|
| Peter Steinberger | OpenClaw開発者（元）、OpenAI在籍 | 「もうエージェントにプロンプトを打つな。エージェントにプロンプトを出すループを設計しろ」（X投稿、約763万回表示） |
| Boris Cherny | Anthropic Claude Code 責任者 | 「私の仕事はループを書くこと。IDEは6ヶ月前にアンインストールした」（Acquired Unplugged, 2026年6月2日） |
| Addy Osmani | Google エンジニアリングディレクター | 「Loop Engineering」と名付け、体系的にブログ記事で整理（2026年6月7日、84万回表示） |
要するに 「人間がAIに逐一指示を出す」から「指示を出す仕組みそのものを設計する」 へのパラダイムシフトです。
2. ループエンジニアリングとは何か
定義
Loop Engineering（ループエンジニアリング） とは、AIコーディングエージェントに手でプロンプトを打つのをやめ、「エージェントにプロンプトを出し続けるループ（仕組み）」そのものを設計する考え方。
もう少し噛み砕くと：
- 従来：人間がプロンプトを打つ → AIが応答 → 人間が次の指示を考える → 繰り返し
- ループ：目的を一度定義 → 仕組みが自動でAIに指示を出し、結果を検証し、次のタスクを決定 → ゴールまで自走
cronとの違い
「ループ」と聞くとcronジョブを思い浮かべるかもしれません。実際、Claude Codeの/loopは内部でcronを使っています。しかし決定的な違いがあります：
| 比較項目 | cron | ループエンジニアリングの「ループ」 |
|---|---|---|
| 実行内容 | 毎回同じスクリプト | モデルが状態を判断して次のアクションを決定 |
| 条件分岐 | 人間が書いたif文 | モデル自身が推論 |
| 終了条件 | 固定スケジュール | ゴール達成で自律的に停止 |
| 失敗時 | エラーで停止 or 無視 | 失敗を観察し、修正して再実行 |
cron: 毎5分 → 同じスクリプト実行 → 完了
ループ: 状態を読む → モデルが判断 → 次のアクション実行
↑ ↓
└──── 結果を観察 ← ──── 成功？ 失敗？
（未完了なら戻る）
3. 設計思想の進化 ── 4つの階段
AIとの付き合い方は、2023年から段階的に抽象度が上がってきました。
┌─────────────────────────────────────────────────────┐
│ [4] ループエンジニアリング (2026年6月〜) │
│ 仕組みが自律的にエージェントを動かし続ける │
├─────────────────────────────────────────────────────┤
│ [3] ハーネスエンジニアリング (2026年初頭) │
│ ツール・制約・検証ゲートなどの実行環境を設計 │
├─────────────────────────────────────────────────────┤
│ [2] コンテキストエンジニアリング (2025年) │
│ モデルが見るトークン全体の情報環境を設計 │
├─────────────────────────────────────────────────────┤
│ [1] プロンプトエンジニアリング (〜2024年) │
│ 1回のプロンプトの質を最大化 │
└─────────────────────────────────────────────────────┘
↑ 抽象度が上がる
比較表
| 観点 | プロンプトEng. | コンテキストEng. | ハーネスEng. | ループEng. |
|---|---|---|---|---|
| 最適化の対象 | 1つのプロンプト | モデルが見るトークン全体 | 実行環境（ツール・制約・検証） | 仕組み全体の設計 |
| 人間の役割 | 質問を書く人 | 情報環境を整える人 | 実行環境を構築する人 | 自走する仕組みの設計者 |
| フィードバック | 人間が判断 | 人間が判断 | 部分的に自動化 | ループが自律的に判断 |
| スケール | 1対1の対話 | 1対1の対話 | 1エージェントの高品質化 | 複数エージェントの並列自走 |
| 再現性 | 低い（属人的） | 中程度 | 高い | 非常に高い |
| 代表的な時期 | 〜2024年 | 2025年 | 2026年初頭 | 2026年6月〜 |
重要：これらは対立関係ではなくレイヤーの関係です。良いループは内部に良いプロンプト・コンテキスト・ハーネスを含んでいます。
4. エージェントループの土台 ── ReAct と Reflexion
ループエンジニアリングは空から降ってきた概念ではありません。その土台には、研究から生まれた2つの重要なパターンがあります。
ReAct（Reason + Act）
Princeton大学とGoogleの共同研究から生まれたパターンで、推論と行動を交互に繰り返すアーキテクチャです。
┌──────────────────────────────────────┐
│ ReActパターン │
│ │
│ 思考 (Thought) │
│ ↓ │
│ 行動 (Action) ── ツール呼び出し │
│ ↓ │
│ 観察 (Observation) ── 結果を受領 │
│ ↓ │
│ 思考 (Thought) ← ここに戻る │
│ ... │
│ 最終回答 (Final Answer) │
└──────────────────────────────────────┘
コーディングの文脈では：
- ゴールを理解する
- コードを書く
- コードを実行して出力（またはエラー）を観察する
- 何が間違っていたか推論する
- 修正して再実行する
- テストが通るまで繰り返す
Reflexion
ReActの発展形で、失敗を言語化して次の試行に活かすパターンです。
タスク実行 → 失敗 → 「なぜ失敗したか」を自然言語で振り返り
↓
振り返りをメモリに保存
↓
次の試行で振り返りを参照して改善
ループエンジニアリングでは、この Reflexion の考え方が 外部メモリ（SKILL.md や progress.txt） として実装されています。
5. インナーループ vs アウターループ
ループには 2つの層 があります。この区別を理解することが、ループエンジニアリングの核心です。
インナーループ（単一タスク内の検証ループ）
1つのタスクの中で、エージェントが自分の仕事を検証してから応答するサイクルです。
[ユーザー] 「auth.tsの失敗しているテストを直して」
❌ 弱いエージェント:
ファイルを編集 → 「完了！」
✅ 強いエージェント:
ファイルを編集 → テスト作成 → テスト実行 → 失敗を検知
→ エッジケースを修正 → 再実行 → グリーン確認 → 「完了！」
ポイント：両者ともまったく同じツールループ基盤を使っている。違いはモデルが検証ツールを呼ぶことを「選んだ」かどうか。
アウターループ（セッション横断の学習ループ）
複数のセッションを跨いで、エージェントが過去の経験から学ぶサイクルです。
セッション1: ページネーション処理で失敗
↓
SKILL.md に「ページネーションのベストプラクティス」を記録
↓
セッション2: 同様のタスク → SKILL.md を読んで最初から正しく処理
| 比較項目 | インナーループ | アウターループ |
|---|---|---|
| スコープ | 単一タスク内 | セッション横断 |
| 目的 | タスクの信頼性向上 | 時間経過による改善 |
| 状態の保持 | コンテキストウィンドウ内 | 永続ファイル（AGENTS.md, SKILL.md等） |
| 現在の成熟度 | 多くのエージェントが対応 | まだ発展途上 |
ループエンジニアリングは、この両方を設計の対象に含みます。
6. ループを構成する「5+1」の部品
Addy Osmani氏は、機能するループは 5つの構成要素 + メモリ でできていると整理しました。
全体像
┌───────────────────────────────────────────────────────────────┐
│ ループエンジニアリング │
│ │
│ ① 自動実行 ② ワークツリー ③ スキル │
│ (Automations) (Worktrees) (Skills) │
│ 定期トリガーで 並列エージェントの プロジェクト知識を │
│ タスクを発見・起動 衝突回避 永続化 │
│ │
│ ④ プラグイン/ ⑤ サブエージェント ⑥ メモリ │
│ コネクター (Sub-agents) (Memory) │
│ (Plugins) 作る役と検証役を 会話の外に状態を │
│ 既存ツールとの接続 分離 永続化 │
└───────────────────────────────────────────────────────────────┘
各部品の詳細
① 自動実行（Automations）
ループの心臓部。定期的にタスクを発見し、エージェントを起動する仕組みです。
# 最もシンプルなループ（Ralph loop の原型）
while true; do
claude --print \
--system-prompt "$(cat system_prompt.md)" \
"$(cat task_prompt.md)" \
>> output.log
sleep 300 # 5分ごとに実行
done
② ワークツリー（Worktrees）
複数のエージェントが同じリポジトリで同時に作業するとき、互いのファイル変更が衝突しないよう、独立した作業領域を提供します。
# Gitのworktree機能を使った並列作業
git worktree add ../agent-1-workspace feature/auth-fix
git worktree add ../agent-2-workspace feature/api-refactor
# agent-1 と agent-2 が同時に異なるブランチで作業 → 衝突なし
③ スキル（Skills）
「このプロジェクトではこう書く」というルールや手順書。毎回ゼロから説明し直さなくて済むようにします。
<!-- .claude/skills/testing.md -->
# テストの書き方
- テストフレームワーク: vitest
- ファイル命名: `*.test.ts`
- モックライブラリ: msw
- カバレッジ目標: 80%以上
- 必ずエッジケースのテストを含めること
④ プラグイン / コネクター（Plugins & Connectors）
GitHub、Jira、Slack、データベースなど既存のツールとAIを接続するための仕組みです。
# MCPサーバー設定の例
mcp_servers:
github:
command: "github-mcp-server"
env:
GITHUB_TOKEN: "${GITHUB_TOKEN}"
slack:
command: "slack-mcp-server"
env:
SLACK_BOT_TOKEN: "${SLACK_BOT_TOKEN}"
⑤ サブエージェント（Sub-agents）
「作る役」と「検証する役」を分離するパターンです。GANの発想に着想を得ています。
┌───────────┐ コード生成 ┌───────────┐
│ Generator │ ────────────────→ │ Evaluator │
│ (生成者) │ │ (評価者) │
│ │ ←──────────────── │ │
└───────────┘ フィードバック └───────────┘
↑ │
│ 計画を提供 │
│ ┌───────────┐ │
└─────── │ Planner │ ←─────────┘
│ (計画者) │ 評価結果
└───────────┘
この3エージェント循環はAnthropicが採用しており、単一エージェントでは到達できない品質を実現しています。
⑥ メモリ（Memory）
ループの生命線。会話の外に状態を永続化することで、コンテキストウィンドウの限界を超えます。
<!-- progress.md -->
## 完了タスク
- [x] 認証モジュールのリファクタリング (PR #142)
- [x] APIエンドポイントのテスト追加 (PR #143)
## 進行中
- [ ] データベースマイグレーション
## 学んだこと
- PostgreSQL 16ではJSON pathの構文が変更されている
- テスト環境ではredisのモックが必要
「エージェントは忘れる。リポジトリは忘れない。」（The agent forgets, the repo doesn't.） ── Addy Osmani
7. 代表的なループ実装の比較
主要な実装
| 実装 | 正体 | 特徴 |
|---|---|---|
| Ralph loop | bashのwhile trueで1つのプロンプトを完了まで繰り返す |
1イテレーション=1タスク。毎回フレッシュな文脈。状態はgit/ファイルに永続化 |
Claude Code /loop |
Claude Code内蔵のループ実行機能 | タスクを渡して自走。トークン暴走対策が重要 |
Codex /goal |
OpenAI Codex CLIの組み込みループ | 目標を渡して永続ワークフロー化。TUIで制御 |
| Ralphify等 | Ralph loops標準に沿った専用ランタイム | 毎回フレッシュ文脈・ライブデータでループを回す |
Claude Code vs Codex ── 5+1部品の対応表
| 部品 | Claude Code | Codex |
|---|---|---|
| ① 自動実行 |
/loopコマンド、スケジュールタスク |
Automationsタブ、/goalコマンド |
| ② ワークツリー | git worktreeで自動ブランチ作成 | 各タスクに隔離されたサンドボックス |
| ③ スキル |
CLAUDE.md、.claude/skills/
|
AGENTS.md、カスタムインストラクション |
| ④ プラグイン | MCPサーバー接続 | ツール連携・API接続 |
| ⑤ サブエージェント |
Taskツールでサブエージェント生成 |
オーケストレーター＋ワーカー構成 |
| ⑥ メモリ |
CLAUDE.md、外部ファイル |
セッション間の永続メモリ |
ポイント：どちらの製品も5+1の部品をすべて実装済み。ツールの違いより、ループの設計の巧拙が成果を分けます。
8. 安全に回すための4つの必須要素
ループは「自律したシニアエンジニア」ではありません。ハーネスの中で粘り強く動く"ジュニア" です。放任すると暴走し、コストだけが膨らみます。
┌─────────────────────────────────────────────────┐
│ 安全なループの4要素 │
│ │
│ ┌─────────────┐ ┌──────────────┐ │
│ │ ① 明確な │ │ ② 安全な │ │
│ │ タスク定義 │ │ 作業環境 │ │
│ │ "完了"が │ │ ブランチ/ │ │
│ │ 一文で言える│ │ サンドボックス│ │
│ └─────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ ③ 機械的な │ │ ④ ハード │ │
│ │ 成功テスト │ │ ストップ │ │
│ │ テスト/ビルド│ │ 回数/時間/ │ │
│ │ /lint等 │ │ コスト上限 │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ▸ 4つが揃わないループは暴走リスクあり │
└─────────────────────────────────────────────────┘
各要素の詳細
| # | 要素 | 説明 | 具体例 |
|---|---|---|---|
| ① | 明確なタスク定義 | 何を達成すれば「完了」かが一文で言える | 「auth.tsのテストが全てグリーンになること」 |
| ② | 安全な作業環境 | 失敗してもダメージが閉じる環境 | 専用ブランチ、Dockerサンドボックス |
| ③ | 機械的な成功テスト | 合否を自動判定できる基準 |
npm test、lint、型チェック |
| ④ | ハードストップ | 無限ループ・トークン暴走の防止 | 最大10イテレーション、1時間のタイムアウト、$5のコスト上限 |
この4要素は、そのまま「AIに任せていい仕事の見分け方」でもあります。 成功を機械的に判定できないタスク（経営判断、創作の方向性決定など）は、ループ化に向きません。
9. エンドツーエンドのループ設計例
実践例：毎日のIssueトリアージ＋自動修正ループ
#!/bin/bash
# daily_loop.sh ── 毎朝6時にcronで実行
REPO_DIR="/path/to/project"
PROGRESS_FILE="$REPO_DIR/.loop/progress.md"
MAX_ITERATIONS=5
cd "$REPO_DIR"
for i in $(seq 1 $MAX_ITERATIONS); do
echo "=== イテレーション $i / $MAX_ITERATIONS ==="
# Step 1: 新しいIssueを発見（自動実行）
# Step 2: 独立ブランチで作業（ワークツリー）
# Step 3: スキルファイルを参照して修正
# Step 4: テスト実行（機械的な成功テスト）
# Step 5: 結果を進捗ファイルに記録（メモリ）
claude --print \
--system-prompt "$(cat .claude/loop_system.md)" \
"進捗ファイルを読み、次のIssueに取り組め。
完了したら進捗ファイルを更新せよ。
全Issue完了なら DONE と出力せよ。" \
2>&1 | tee -a .loop/run.log
# ハードストップ：DONEが出たら終了
if grep -q "DONE" .loop/run.log; then
echo "全タスク完了"
break
fi
done
ループのフロー
[cron 毎朝6時] ──→ daily_loop.sh 起動
│
┌─────▼──────┐
│ progress.md│ ← 前回の進捗を読む
│ を読み込み │
└─────┬──────┘
│
┌─────────────▼──────────────┐
│ GitHub Issueを確認 │ ← プラグイン/コネクター
│ 未対応のIssueを取得 │
└─────────────┬──────────────┘
│
┌─────────────▼──────────────┐
│ git worktreeで │ ← ワークツリー
│ 作業ブランチを作成 │
└─────────────┬──────────────┘
│
┌─────────────▼──────────────┐
│ CLAUDE.md / skills/ │ ← スキル
│ を参照してコード修正 │
└─────────────┬──────────────┘
│
┌─────────────▼──────────────┐
│ テスト実行 │ ← 機械的な成功テスト
│ npm test && npm run lint │
└─────────────┬──────────────┘
│
成功？ ─── No ──→ 修正して再試行
│ （サブエージェントが検証）
Yes
│
┌─────────────▼──────────┐
│ PR作成 │
│ progress.md を更新 │ ← メモリ
└─────────────┬──────────┘
│
次のIssueへ or 終了
10. リスクと限界 ── ループが解決しないもの
ループエンジニアリングは万能ではありません。Addy Osmani氏を含む提唱者たち自身が、以下のリスクを警告しています。
10.1 トークンコストの爆発
| 使い方 | トークン消費の目安 |
|---|---|
| 通常のチャット | 1x（基準） |
| エージェント（インナーループ） | 約4x |
| マルチエージェント | 最大15x |
| 長時間ループ（制限なし） | 予測困難 ── 暴走リスクあり |
対策：必ずコスト上限を設定する。
max_tokens、イテレーション回数制限、予算アラートを組み込むこと。
10.2 検証の難しさ
ループが長くなるほど、微妙なズレが積み重なり、最終的に使えないアウトプットになるリスクがあります。
イテレーション1: わずかな設計判断のズレ (許容範囲)
イテレーション2: ズレた前提の上にさらに構築
...
イテレーション10: 元の意図とは全く異なる成果物に
対策：ループ構造の中に人間のレビューポイントを組み込む（例：5イテレーションごとに中間レビュー）。
10.3 その他のリスク
| リスク | 内容 | 対策 |
|---|---|---|
| コンテキストの劣化 | 長時間実行でコンテキストが肥大化し品質低下 | 毎回フレッシュなコンテキストで起動。状態は外部ファイルに |
| 暗黙の権限拡大 | ループが想定外の操作を行う | 最小権限原則。読み取り専用をデフォルトに |
| デバッグの困難さ | 自律的な判断の連鎖を追跡しにくい | 全ステップのログ記録。オブザーバビリティの確保 |
| 品質の均一化 | AIが「動くけど凡庸な」コードを量産 | アーキテクチャ判断は人間が握る |
11. ベストプラクティスまとめ
✅ やるべきこと
- 小さく始める ── まずは1タスク・1ループから。巨大なシステムを一度に作らない
-
状態は外部に持つ ──
progress.md、git履歴、タスクボードなど。会話コンテキストに依存しない - 毎回フレッシュに起動 ── コンテキストの肥大化を防ぎ、外部メモリから状態を復元
- 成功基準を機械化 ── テスト、lint、型チェックなど自動判定できる基準を必ず置く
- ハードストップを設定 ── 回数・時間・コストの上限を必ず設ける
- 作る役と確認する役を分ける ── サブエージェントで生成と検証を分離
- スキルファイルを育てる ── プロジェクト固有の知識を蓄積し続ける
❌ やってはいけないこと
- ループを放置しない ── 完全な自律は幻想。定期的な人間のレビューが必要
- 曖昧なゴールを渡さない ──「いい感じにして」は最悪のループ入力
- コスト上限なしで回さない ── トークン暴走は実害（金銭的損失）に直結
- 機械的に判定できないタスクをループ化しない ── 創作の方向性判断、経営判断などは人間が行う
- ログを取らない ── 何が起きたか追跡できないループは改善できない
12. おわりに ── エンジニアの役割はどう変わるか
ループエンジニアリングの登場は、エンジニアの役割を根本から変えつつあります。
これまで: エンジニア ─→ [コードを書く] ─→ プロダクト
これから: エンジニア ─→ [ループを設計する] ─→ AIが実行 ─→ プロダクト
│
├─ 何をゴールとするか決める
├─ 成功基準を定義する
├─ 安全な作業環境を用意する
├─ 検証の仕組みを組み込む
└─ アーキテクチャ判断を握る
Boris Cherny氏の言葉を借りれば、これはパンチカード → アセンブリ → C言語 → 高水準言語 → ループ という、プログラミングの抽象度が一段上がった瞬間です。
しかし、ここで忘れてはいけないのは：
「味見」だけは手放すな。
ループがどれだけ賢くなっても、最終的なアウトプットの品質を判断し、方向性を決めるのは人間です。ループエンジニアリングとは、任せる範囲と人間が残す範囲の線引きそのものなのです。
13. 参考文献
| # | タイトル | 出典 |
|---|---|---|
| 1 | Loop Engineering | Addy Osmani (Google), 2026年6月7日 |
| 2 | Acquired Unplugged - Boris Cherny Interview | WorkOS / Acquired, 2026年6月2日 |
| 3 | Loop Engineering: The Guide for AI Agents | Lushbinary, 2026年6月9日 |
| 4 | What Is Loop Engineering? The New Meta for AI Coding Agents | MindStudio, 2026年6月9日 |
| 5 | Agents: Inner Loop vs Outer Loop | Philipp Schmid, 2026年2月20日 |
| 6 | Loop Engineeringとは｜"プロンプトの次"のループ設計 | Fyve, 2026年6月10日 |
| 7 | ループエンジニアリングというAIエージェント設計の最前線 | AI-Driven Lab, 2026年6月9日 |
| 8 | cobusgreyling/loop-engineering | GitHub リポジトリ |
| 9 | What Is the AI Agent Loop? | Oracle Developers, 2026年3月16日 |
| 10 | ハーネスエンジニアリング完全ガイド | Qiita, 2026年3月29日 |