ループエンジニアリングとは？仕組み・作り方・コストとデータ基盤への応用まで解説

【PR】本記事はプロモーションを含みます。

「プロンプトを書くのはもう古いの？」

「ハーネスやコンテキストエンジニアリングと何が違うの？」

「監視ループを回すとコストや暴走が心配だけど、どう始めればいいの？」

こうした疑問への答えを一言でまとめると、ループエンジニアリングとは、エージェントにプロンプトする人である自分を、自動でプロンプトし自己評価する仕組みに置き換える設計実践です。

この記事では、定義と提唱経緯、4層比較、2タイプとAnthropicの4分類、コピーで試せる最小ループ、6要素とloop contract、検証と停止の設計、コスト管理、データ基盤への応用案、向くタスクと段階導入まで整理します。数値・仕様は2026年9月22日時点の一次情報に基づきます。変動する箇所には確認日を付けています。YAML例は執筆時点の例示であり要動作確認、データ基盤の適用例は本記事の提案として明示します。

要点（この記事の結論）

• ループエンジニアリングは「人を置き換える仕組みを設計する」実践です。単発の指示作りではなく、反復の制御構造を設計します
• 位置づけはハーネスの1つ上の階層です。下層のプロンプト・コンテキスト・ハーネスの積み上げが前提です
• 回り方は継続監視型とゴール収束型の2つに整理できます。Anthropicの4分類とは別枠組みとして使い分けます
• 始め方は報告のみの最小ループからです。いきなり自動修復させません
• 生成と検証は分けます。書いたモデル自身の自己採点に頼りません
• 停止条件と上限を先に決めます。コストは頻度×ステップ×単価の式で見積もります
• データ品質監視やETL失敗対応への応用は本記事の提案です。一次事例があるかのような書き方はせず、権限と証拠ゲートを付けて試します

ループエンジニアリングとは？一言定義と提唱経緯

まず結論です。ループエンジニアリング（Loop engineering）とは、エージェントにその都度プロンプトする人である自分を、自動でプロンプトし自己評価する仕組みに置き換える設計実践です。

提唱者はAddy Osmani氏です。原典記事の公開日は2026年6月7日です。O’Reilly Radarへの転載版は2026年6月22日公開、著者の許諾を得た転載である旨が明記され、読了目安14分とされています。いずれも2026年9月22日確認です。

原典の一文定義は次のとおりです。

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

日本語にすると「エージェントにプロンプトする人を自分から仕組みに置き換える。代わりにその仕組みを設計する」となります。

ループ自体の定義も原典にあります。「a recursive goal where you define a purpose and the AI iterates until complete」、つまり目的を定義しAIが完了まで反復する再帰的ゴールです。

Anthropicの定義も併せて押さえます。「loops as agents repeating cycles of work until a stop condition is met」、停止条件を満たすまで作業サイクルを繰り返すエージェントです。公開日は2026年6月30日、著者はDelba de Oliveira氏とMichael Segner氏です。IBMの定義は「designing agentic workflows (loops) that iteratively guide AI agents toward user-defined goals with minimal human intervention」、最小限の人間介入でユーザー定義ゴールへ反復誘導する自律ワークフローの設計です。公開日は2026年7月17日、著者はIvan Belcic氏とCole Stryker氏です。

原典では関係者の発言も紹介されています。Steinberger氏の「You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.」や、Claude Code責任者として紹介されるBoris Cherny氏の「I don’t prompt Claude anymore. I have loops running that prompt Claude…」です。いずれもX投稿へのリンク付きで紹介されていますが、X投稿の原文自体は未確認です。そのため本記事では、原典内の引用としての紹介に留めます。

Osmani氏はトークンコストへの注意も明言しています。「you absolutely have to be careful about token costs」（トークンコストには十分注意が必要）としたうえで、まだ初期段階であることや懐疑的な見方があることも併記しています。警告の存在自体が事実であり、具体的な倍率や金額の根拠には使えません。

同名企業との切り分け

「ループエンジニアリング」で検索すると、株式会社ループエンジニアリングが見つかります。同社は横浜市金沢区の電気設備会社で、省エネ・電気設備の点検などを手がけています。本記事のAI概念とは無関係です。以降の「ループ」はすべてAIエージェントの反復制御を指します。

4層比較で位置づけるとどう違う？積み上げの順番論

ループの立ち位置は、プロンプト／コンテキスト／ハーネス／ループの4層で整理すると分かりやすいです。原典の明言は「Loop engineering sits one floor above the harness」、ループはハーネスの1つ上の階層です。

ハーネスエンジニアリング（単一実行環境の整備）について詳しく知りたい方は、ハーネスエンジニアリングの解説もご覧ください。コンテキストの整え方はMCPの解説が参考になります。

層	設計対象	一言イメージ	成果物の例
プロンプトエンジニアリング	単一の最適な指示	その都度の良い指示を作る	単発プロンプト、チェックリスト
コンテキストエンジニアリング	渡す文脈	毎回忘れるモデルに必要十分な材料を渡す	AGENTS.md、SKILL.md、要約済み状態
ハーネスエンジニアリング	単一エージェントが動作する環境	作業場を整える	実行環境、ツール接続、権限、レビュー導線
ループエンジニアリング	反復の制御構造	作業場の上で回し方・止め方を設計する	トリガー、停止条件、上限、検証ゲート、報告

IBMは「Loop engineering versus prompt engineering」節で、プロンプトエンジニアリングは単一の最適な指示を作る実践、ループエンジニアリングは自らプロンプトし自己評価する自動システムを設計する実践と対比しています。固定的なプロンプトチェーンに対し、ループは動的で柔軟とされます。

注意点として、上表の行項目の細部は各サイトが共通して紹介している二次情報の整理です。一次情報の公式表ではありません。「よく使われる整理枠組み」として扱ってください。

積み重ねの注意は単純です。下層が弱いままループだけ回しても品質は上がりません。指示が曖昧、文脈が不足、作業場が散らかった状態で自動反復すると、ズレた成果物が量産されます。まず人間が単発で回してみて詰まりを見つけ、次にハーネスを整え、最後にループ化する順番が安全です。

ループの回り方は？2タイプとAnthropicの4分類の使い分け

回り方は大きく2タイプに整理できます。一方でAnthropic公式の4分類は別物です。混同しないよう区別します。

継続監視型とゴール収束型の2タイプ

本記事で使う2タイプは、二次情報の整理です。Anthropic公式の4分類とは別枠組みとして明示します。

• 継続監視型：定期的またはイベント起点で起動し、終わりなく見回ります。データ品質監視やCI失敗の見回りが該当します
• ゴール収束型：ゴールを宣言し、達成または上限到達で終わります。テスト全通やスコア到達まで直す作業が該当します

cronとの違いは、時刻で起動するかどうかではなく、終了を自分で判断するかどうかです。cronは定刻起動が中心で、終わりの判断は持ちません。ループは停止条件と検証ゲートを持ち、達成・失敗・継続を振り分けます。リレーとの違いは、固定順序で引き継ぐだけか、結果を見て反復分岐するかです。

ループの原形として知られるRalph（ラルフ）は、Bashの無限ループで書かれた実装パターンです。原形は while :; do cat PROMPT.md | claude-code ; done です。公開日は2025年7月14日、著者はGeoffrey Huntley氏です。原則は単一リポジトリ・単一プロセスで1ループ1タスク、ツール非依存とされます。Ralph自体はループエンジニアリングの同義語ではなく、一つの実装パターンとして扱います。

Anthropicの4分類

Anthropic公式の4分類は次のとおりです。本文でトリガー・停止基準・用途・利用管理が定義されています。

分類	トリガー	停止条件	向く用途	コマンド例
turn-based	ユーザープロンプト	Claudeが完了判断または追加文脈要求	短い単発タスク	通常の対話
goal-based（/goal）	手動プロンプト	ゴール達成または最大ターン数	検証可能な終了条件を持つタスク	/goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.
time-based（/loop・/schedule）	指定間隔	ユーザーがキャンセルするか作業完了	定期作業・外部システム連携	/loop 5m check my PR, address review comments, and fix failing CI
proactive	イベント／スケジュールで人間不在起動	各タスクはゴール達成で終了、ルーチン自体は停止するまで継続	バグ報告・issue triage・移行・依存更新など明確な反復作業	動的ワークフローと併用

出典：Anthropic Getting started with loops（2026-06-30公開、2026-09-22最終確認）。コマンド例2件はいずれも同記事からの引用です。

補足の仕様は一部未確認です。/goalの評価者モデルの既定や分岐仕様、/loopのセッション範囲と3つの動作、Claude Code用語集の定義などは、Web検索の抜粋でのみ確認しています。docs本文の直接確認はできていません。本記事では、コマンド例など一次ブログで確認できた範囲を引用し、詳細仕様は未確認として扱います。導入前に公式ドキュメントで再確認してください。

定期実行の関連機能としてRoutines（Cloud Routines）があります。2026年4月14日発表、research previewです。プロンプト・リポジトリ・コネクタを設定し、スケジュールやAPI、GitHubなどのイベントで実行します。ラップトップ不要のクラウド実行です。利用条件はPro・Max・Team・Enterpriseに加え、Claude Code on the webの有効化です。CLIからは/scheduleで作成します。実行はサブスク利用枠を消費し、日次上限があります。2026年9月22日時点の公式発表値はPro 5回／日、Max 15回／日、Team・Enterprise 25回／日で、超過分は追加利用枠です。変動しうるため時点付きで扱ってください。

最小ループをどう組む？GitHub Actions＋STATE.md＋停止条件3行

最小構成は3点です。GitHub Actionsなどの起動手段、STATE.mdなどの永続状態、停止条件3行です。いきなり自動修復させず、報告のみから始めます。

IBMは起動手段について「developers often use GitHub Actions to schedule or trigger agent loops」と明記しています。具体的なYAMLはIBM記事になく、下例は本記事の執筆例です。要動作確認として扱ってください。コピーして動かす前に、リポジトリ名や権限、実行内容を自分の環境に合わせて書き換えてください。

# 例示用・要動作確認：毎朝の見回りを報告のみで起動する例
name: morning-triage-loop
on:
  schedule:
    - cron: "0 22 * * *"  # UTC 22時は日本時間翌7時（JST=UTC+9）。自分の定期実行時刻に合わせて書き換えてください
  workflow_dispatch:
permissions:
  contents: read
  issues: read
jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4  # バージョンは執筆時点の例示です
      - name: read spine
        run: cat STATE.md
      - name: agent triage (report only)
        run: echo "ここで見回りエージェントを起動し、結果をSTATE.mdに追記します"

# STATE.md の例
## 済
- 2026-09-22 CI失敗2件を確認、詳細はログリンク参照
## 次
- 失敗テストの再実行結果を確認する
## 停止中
- なし

停止条件3行の例です。

- 最大3周で止める。3周しても直らなければ人間に引き継ぐ
- 人的レビューなしに本番へ反映しない
- 証拠（ログ・差分・テスト結果）がなければ完了にしない

永続状態はSpine（背骨）と呼ばれます。MarkdownファイルやLinearボードなど、単一会話の外に「済・次」を保持するものです。根拠は原典の「The agent forgets; the repo doesn’t.」、モデルは実行と実行の間では忘れてしまうため記憶はディスク上に置くという原則です。IBMのSpine節も同趣旨です。

停止条件の書き方はAnthropic公式の指針があります。「The more quantitative the checks are, the easier it is for Claude to self-verify」、定量的チェックを含めるほど自己検証しやすいとされます。公式のSKILL.md例は、開発サーバー起動から操作、スクリーンショット、コンソールのエラーなし、Core Web Vitals監査まで進め、失敗時は最初の手順から再実行する形です。

起動点の方針も公式が示しています。「Not all tasks require complex loops; start with the simplest solution」、複雑なループが要らない作業もあり、最も単純な解法から始めます。これが報告のみ開始の根拠です。

L1からL3への段階ティアは、Zennなど二次情報の整理であり一次情報の用語ではありません。本記事では後述の「どんなタスクに向く？」の節で二次情報として明示し、L1相当の報告のみ開始から説明します。

ループの中身は何でできている？6要素とloop contract 7要素

loop contractの7要素（二次情報の提案枠組み。自分の現場の言葉に置き換えて使う）

骨格はOsmani氏の5要素＋記憶です。IBMの8要素との差分も押さえます。

Osmaniの5要素＋記憶

1. Automations：起動の仕組みです。定時実行やイベント実行、/loopや/goal、フック、GitHub Actionsなどが該当します
2. Worktrees：隔離された作業場です。git worktreeなどで並行作業を分離します
3. Skills：反復作業向けのタスク固有知識です。SKILL.md形式で渡します
4. Plugins and connectors：配布と接続の仕組みです。Skillは作成のための形式、pluginは配布のための形式とされています
5. Subagents：分業する下請けエージェントです。生成と検証の分離などに使います
6. Memory（State）：永続状態です。前章のSTATE.mdが該当します

Osmani氏の対応表では、Claude Code側はscheduled tasksやcron、/loopや/goal、hooks、GitHub Actions、git worktreeや分離設定、SKILL.md、MCPサーバとplugins、Taskサブエージェント、MarkdownやLinear経由の状態管理が挙げられています。Codex側（Codexの解説も参照）はAutomationsタブ、スレッドごとのworktree、Agent Skills、MCP由来のConnectorsとplugins、設定ファイルで定義するSubagentsが挙げられています。Codex公式ドキュメントの詳細仕様は未確認のため、本記事ではOsmani氏対応表の紹介に留めます。

IBMの8要素との差分

IBMの8構成要素は、Automations or scheduling、Hooks、Context engineering、Tool access、Worktrees、Skills、Subagents、Spineです。Osmani氏の5＋1にHooks、Context engineering、Tool accessを加えた形です。

Hooksの定義は、コード生成・ファイル編集・ツール呼出・タスク完了などのイベントで発火する命令です。前後どちらにも付けられ、ガバナンスや品質検査用にエージェント本体から外すことでトークンや計算資源を削減します。

Skillの定義は、単一の反復ワークフロー向けタスク固有知識です。skill.md形式とAGENTS.mdのリポジトリ横断知識は分けて扱います。両一次情報で一致しています。

Tool accessはMCPサーバやAPI、統合による自律行動です。IBMは、なしでは外部に作用できず「やるはずだったことの説明」に留まるとします。

loop contractの7要素

loop contractの7要素（Trigger、Scope、Permission、Verification gate、Budget、Stop-Escalation、Reporting）は、AIDDなどによる二次情報の整理です。一次情報に該当用語はありません。原典本文の未確認部分でもあるため、本記事では「二次情報の提案枠組み」として明示します。使う場合はチェックリストとして扱い、自分の現場の言葉に置き換えてください。

要素	書くこと	例
Trigger	何がきっかけで回るか	定時、issue作成、CI失敗
Scope	対象範囲	対象リポジトリ、対象テーブルのみ
Permission	してよいこと・悪いこと	読み取りのみ、削除禁止
Verification gate	完了と認める証拠	テスト全通、差分の提示
Budget	上限	周回数、実行時間
Stop-Escalation	止めて誰に渡すか	3周で停止し担当者へ通知
Reporting	何を残すか	STATE.mdへの追記

第三者の裏付けとして、AWS公式のEvaluator-Reflect-Refineパターンがあります。generatorが生成し、evaluatorがルーブリックで評価し、optimizerが修正する流れを、基準充足・承認・リトライ上限まで反復します。Maker-Checkerの考え方の裏付けに使えます。

検証と停止をどう設計する？テンプレとMaker-Checker分離

検証と停止は先に設計します。後付けにすると、終わらないループや見かけ上の完了が残ります。

停止テンプレート

そのまま書き換えて使える形です。

- 成功条件：〇〇テストが全通したら成功とする
- 失敗条件：〇回繰り返して未達なら失敗として止める
- 禁止事項：人的レビューなしの本番反映をしない
- 証拠：ログ・差分・テスト結果のいずれか必須とする
- 引継ぎ：停止時はSTATE.mdに「済・次・証拠」を残し担当者へ通知する

決定論的基準が有効と公式は明言します。通過したテスト数やスコア閾値など、数えられる基準にします。

Maker-Checker分離

原則は単純です。書いたモデルは自分の採点に甘いため、別指示・別モデルの検証者が必要です。/goalの停止判定自体がこの分離の適用例です。IBMもmaker／checker構造を推奨し、別検証サブエージェントは自己検査より品質保証が高いとします。タスク進捗監視や終了条件判定用の別サブエージェントを使う方式もあります。

Anthropicの品質維持の指針は4つです。コードベース自体を清潔にすること、検証手段を与えること、ドキュメント到達性を保つこと、新鮮な文脈の別エージェントでレビューすることです。組み込みのレビュー機能やコードレビュー用スキル、GitHub用レビューを使います。公式の説明では、新鮮な文脈のレビュワは偏りが小さく、主エージェントの推論に影響されないとされます。

ただしSubagentsはトークンを余計に消費するため、セカンドオピニオンが対価に見合う場面で使うことが原典の注意です。数値の定量化はなく、使いどころの判断が必要です。

機械判定と不正対策

人が毎回読む前に、機械で落とせるものは落とします。Ralphではbackpressureという考え方で、テスト・ビルド・型・静的解析・セキュリティスキャナなどを「車輪を速く回す」ために配線します。動的型言語では型チェッカや静的解析の配線が必須級とされます。

不正対策も必要です。Ralphはプレースホルダや最小実装への偏向をプロンプトで禁止します。「DO NOT IMPLEMENT PLACEHOLDER OR SIMPLE IMPLEMENTATIONS」（プレースホルダや安易な実装をするな）とプロンプトで禁じ、TODO残しや最小実装、placeholderの有無の確認を計画ループに組み込みます。ゴールハック検出のチェックリスト例を示します。

• テストを書き換えて通していないか
• skipや除外で見かけ上通していないか
• TODO残しのまま完了にしていないか
• 差分と報告の内容が一致しているか
• 証拠リンクが有効か

テスト書き換えやskipの具体的検出数値、ツール別失敗率は一次情報になく未確認です。断定的数値は書きません。

プロンプトインジェクションへの注意も要ります。外部のissue文やログをそのまま指示として取り込むと、意図しない操作につながります。外部入力は引用として扱い、許可された操作だけに絞ります。

コスト膨張をどう防ぐ？試算式とコンテキスト対策

ループは回すほどトークンを消費します。Osmani氏も警告し、Anthropicも管理指針を示しています。ここでは式と考え方だけ固めます。具体的な倍率や金額は一次裏取りがなく未確認のため書きません。

ループ税の考え方と試算表

試算は「頻度×ステップ×単価」の式で考えます。数値は前提と時点付きでのみ扱います。下表の例は執筆例であり料金・倍率の確定値ではありません。頻度×ステップ×単価の式のみが一次情報の裏付け範囲です。

項目	決めること	例の置き方
頻度	いつ・どれだけ回すか	1日1回、CI失敗時のみ
ステップ	1周あたりの作業量	下調べ＋修正案＋検証の3段階
単価	使うモデルと枠組み	小型高速モデルで下調べ、大型は検証のみ
上限	打ち切り条件	3周まで、実行時間30分まで
観測	使いすぎの検知	利用枠の定期確認

競合記事にある具体的倍率や金額事例は、一次情報の裏取りがなく未確認です。本記事では式のみ提示します。

上限・頻度・モデル使い分け

Anthropicのトークン管理指針は6項目です。適材適所の実行手段（primitive）とモデル、明確な成功・停止条件、大規模化前のパイロット、決定論的作業のスクリプト化、必要以上の頻度で回さないこと、利用レビューです。指針の中で「Your model and effort level choices are among the biggest levers」、モデルと労力の選択がコスト最大のレバーとされます。

IBMも再帰ゴールを毎反復評価し、不要反復防止とトークンコスト制御に使うとします。曖昧な例「Make my website load faster」に対し、測定可能例「stop iterating when your code passes all unit tests…」を挙げています。

対策比較の骨格は次のとおりです。

対策	内容	根拠
小さく始める	単純な解法と報告のみから始める	Anthropic公式の助言
頻度を絞る	必要以上の頻度で回さない	Anthropic 6指針
決定論化する	機械でできる作業はスクリプト化する	Anthropic 6指針
定量化する	測定可能な停止条件にする	IBMのGoal節
観測する	利用枠を定期確認する	Anthropicの利用レビュー

Auto modeはツール呼出ごとにわずかなトークン・コスト・遅延増の可能性があるとされます。「may have a small impact」と定性的な表現であり、定量化はありません。Routinesは対話セッションと同様にサブスク利用枠を消費します。具体料金額は記事になく未確認です。

観測手段は公式にあります。/usageでスキル・サブエージェント・MCP別内訳、無引数の/goalでターン数とトークン使用量、/workflowsでエージェント別トークン使用量を確認できます。

コンテキスト膨張対策

Context engineeringの注意として、各サイクルの生成物が次サイクルの文脈に積み上がります。過剰な文脈は関連性低下・コスト増・重要情報の埋没を招きます。対策は要約圧縮とMarkdown構造化です。STATE.mdに「済・次・証拠」だけ残し、生ログはリンク参照に留めるのが目安です。

データ基盤に応用できる？品質監視・ETL失敗対応の提案

本章は本記事の提案です。データ基盤固有の一次適用事例は確認できず、競合分析でも空白とされています。一次事例があるかのような書き方はせず、実践枠組みの応用として明示します。

発想の土台はOsmani氏のループ例です。毎朝automationが起動し、triage用のskillで昨日のCI失敗やopen issue、直近コミットを読み解き、MarkdownやLinearに記録し、worktree分離で修正案を作り、別のsubagentがレビューし、connectorでPRやチケットを更新し、さばききれないものはtriage inboxへ送ります。これをデータ基盤に翻案します。

接続の裏付けはあります。ConnectorsのMCP基盤（MCPの解説）でissue tracker読取・DB照会・staging API・Slack通知が可能です。MCPベースのconnectorはCodexとClaude Code間で概ね互換とされます。IBMのTool accessも、MCPサーバやAPI、統合で自律行動するとします。

応用案を3つ示します。いずれも報告のみ開始が前提です。

応用案	起動	検証ゲートの例	報告
データ品質監視	定時	検査クエリ結果と件数の提示	STATE.mdに結果と証拠リンクを追記
ETL失敗対応	失敗イベント	ログ抜粋と再実行可否の提示	担当者へ通知、自動再実行はしない
スキーマ変更検出	定時または変更イベント	変更前後の差分提示	下流影響の確認依頼を起票

権限denylistのYAML実例や証拠必須ゲートの一次仕様は未確認です。以下の例は執筆者作成物として扱ってください。要動作確認です。

# 例示用・要動作確認：権限の考え方の例
permission:
  allow:
    - read_only_query
    - notify_slack
  deny:
    - production_write
    - secret_access
    - bulk_delete
verification_gate:
  required_evidence:
    - query_result
    - log_link

Auto modeのclassifierによる事前検査については一次情報で確認できます。大量削除・機密持出し・悪性実行を検査し、安全は自動通過、危険は阻止して別手段へ誘導し、繰り返し阻止は人間プロンプトへつなぎます。ただしリスク完全除去ではないと明記されています。権限設計の裏付けに使えますが、万全とは書けません。

どんなタスクに向く？向かない仕事と段階導入の目安

向く作業と向かない作業を分け、報告のみから段階的に進めます。L1からL3のティア自体は一次定義がなく未確認のため、二次情報として明示します。

向くタスク

Anthropic公式のproactive loopの適用先は、bug reports、issue triage、migrations、dependency upgradesなど明確な反復作業です。公式のまとめ表では、探索・判断時は検証スキル付きのturn-based、完了条件が明確な時は/goal、外部・定時は/loopや/schedule、明確な反復作業は動的ワークフローと組み合わせたproactive loopが担うとされます。

データ基盤では、定型の見回りや失敗時の一次切り分けなど、終わりの形が決まる作業が向きます。

向かないタスク

RalphはGreenfield立上げに最適で、既存コードベースでは非推奨とされます。「There’s no way in heck would I use Ralph in an existing code base」という強い表現で既存コードベースでの使用を戒めており、90%到達が期待値ともされています。既存の複雑な基盤にいきなり全面適用しないのが目安です。

Osmani氏の残る3課題も判断材料です。検証は人間の責任、理解の腐食、安楽な姿勢の危険です。結論文は「Build the loop. But build it like someone who intends to stay the engineer」、ループを作れ、ただし技術者であり続けるつもりで作れという趣旨です。IBMの4 pitfallsも同様で、Unverified code、Comprehension debt、Intent debt、Cognitive surrenderの4項目です。

Auto modeの日付と仕様も押さえます。2026年3月24日発表のresearch previewでTeam先行、2026年7月10日に全ユーザーGA追記です。–dangerously-skip-permissionsより安全な長時間実行の代替と位置づけられます。権限の裏付けになりますが、完全除去ではない点に注意します。

段階導入の目安

L1からL3のティアは一次定義がなく、二次情報の整理です。本記事では目安として次の順番を提案します。

• L1相当：報告のみです。読み取りと通知だけ許可し、変更は人が行います
• L2相当：下書きまでです。修正案やクエリ案を作らせ、適用は人が承認します
• L3相当：限定自動化です。対象と上限を絞り、証拠ゲート付きで実行します

Anthropic公式の助言「自分のボトルネック作業を1つ選び、委譲可能部分を問う」が始め方の根拠です。検証・停止条件・トリガーを1作業分だけ書き出します。

よくある質問

Q1. ループエンジニアリングとは何ですか？

A. エージェントに指示を出す役割の自分自身を、自動で指示出しと自己評価を行う仕組みに置き換える設計実践です。原典の一文は「Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.」です。目的を定義しAIが完了まで反復する再帰的ゴールがループです。

Q2. 4層（プロンプト・コンテキスト・ハーネス・ループ）の違いは何ですか？

A. 設計対象が違います。プロンプトは単一指示、コンテキストは渡す文脈、ハーネスは単一エージェントの作業環境、ループは反復の制御構造です。ループはハーネスの1つ上の階層とされます。詳細な比較表自体は各紙の整理であり、公式表ではありません。

Q3. ハーネスエンジニアリングとの違いは何ですか？

A. ハーネスは単一エージェントが動作する環境を作る実践、ループはその上で回し方・止め方を設計する実践です。関連する原典記事へのリンクも原典にあります。作業場の整備が先、反復の設計が後と覚えると分かりやすいです。詳しくはハーネスエンジニアリングの解説をご覧ください。

Q4. cronやスケジュール実行との違いは何ですか？

A. 停止条件と検証ゲートを持つかどうかです。cronは定刻起動が主役で終わりの判断を持ちません。ループは達成・失敗・継続を振り分け、上限到達で人間に引き継ぎます。Routinesのような定期実行は起動手段であり、ループの停止設計と組み合わせて使います。

Q5. 何から始めればいいですか？

A. 自分のボトルネック作業を1つ選び、報告のみの最小ループから始めます。公式助言は「Not all tasks require complex loops; start with the simplest solution」です。GitHub Actionsなどの起動手段、STATE.mdなどの永続状態、停止条件3行をそろえ、読み取りと通知だけ許可します。YAML例は本記事の執筆例であり要動作確認です。

Q6. 停止条件はどう書けばいいですか？

A. 数えられる基準にします。通過したテスト数やスコア閾値など決定論的基準が有効と公式は明言します。成功条件、失敗時の打ち切り回数、人的レビューなしの本番反映禁止、証拠必須、引継ぎ方法を先に書きます。測定可能例として「stop iterating when your code passes all unit tests…」が挙げられています。

Q7. 生成と検証はなぜ分けるのですか？

A. 書いたモデルは自分の採点に甘いためです。別指示・別モデルの検証者が必要で、/goalの停止判定自体が分離の適用例です。新鮮な文脈のレビュワは偏りが小さく、主エージェントの推論に影響されないとされます。ただし検証分離はトークンを余計に消費するため、見合う所に使います。

Q8. コストはどう見積もればいいですか？

A. 頻度×ステップ×単価の式で見積もります。具体的な倍率や金額事例は一次裏取りがなく未確認のため、本記事では数値を断定しません。モデルと労力の選択が最大のレバーとされます。観測は/usageで内訳、無引数の/goalでターン数と使用量、/workflowsでエージェント別使用量を確認します。Routinesの日次上限は2026年9月22日時点でPro 5回／日、Max 15回／日、Team・Enterprise 25回／日とされます。

まとめ

ループエンジニアリングとは、エージェントに指示を出す役割の自分自身を、自動で指示出しと自己評価を行う仕組みに置き換える設計実践です。ハーネスの1つ上の階層で、回し方・止め方・証拠の残し方を設計します。

要点は、報告のみ開始、生成と検証の分離、定量的な停止条件、上限付き試算の4点です。データ基盤への応用は本記事の提案として、読み取りと通知から試します。

次の一手は、ボトルネック作業を1つ選び、STATE.mdと停止条件3行を書くことです。YAML例は要動作確認のため、自分の環境で権限を絞って試してください。作業環境の整え方はハーネスエンジニアリングの解説、接続の考え方はMCPの解説から試してみてください。

関連記事

• ハーネスエンジニアリングとは？仕組み・作り方まで解説 — 単一エージェントの作業環境づくりを知りたい方向け
• MCPとは？仕組み・使い方まで解説 — DB照会や通知の接続方法を知りたい方向け
• OpenCodeとは？仕組み・使い方・料金まで解説 — 単体エージェントの基本を固めたい方向け
• Codexとは？仕組み・使い方・料金まで解説 — 比較対象の作業者を固めたい方向け
• AIオーケストレーションとは

参考文献

• Addy Osmani, Loop Engineering（原典公開日2026-06-07、2026-09-22最終確認）: https://addyosmani.com/blog/loop-engineering/
• O’Reilly Radar, Loop Engineering（転載版公開日2026-06-22、2026-09-22最終確認）: https://www.oreilly.com/radar/loop-engineering
• Anthropic, Getting started with loops（公開日2026-06-30、2026-09-22最終確認）: https://claude.com/blog/getting-started-with-loops
• IBM Think, Loop engineering（公開日2026-07-17、2026-09-22最終確認）: https://www.ibm.com/think/topics/loop-engineering
• Geoffrey Huntley, Ralph（公開日2025-07-14、2026-09-22最終確認）: https://ghuntley.com/ralph/
• Anthropic, Introducing Routines in Claude Code（発表日2026-04-14、2026-09-22最終確認）: https://claude.com/blog/introducing-routines-in-claude-code
• Anthropic, Auto mode（発表日2026-03-24、GA追記2026-07-10、2026-09-22最終確認）: https://claude.com/blog/auto-mode
• AWS, Evaluator-Reflect-Refine loop patterns（2026-09-22最終確認）: https://docs.aws.amazon.com/prescriptive-guidance/latest/agentic-ai-patterns/evaluator-reflect-refine-loop-patterns.html
• 株式会社ループエンジニアリング 公式サイト（同名企業切り分け用、2026-09-22最終確認）: https://loopeng.co.jp/