「ループエンジニアリング」という言葉が急に増えました。Addy Osmani 氏が2026年6月に名前を付け、Claude Code 公式も「Getting started with loops」を出しています。
要するに、人間が毎回プロンプトを打つ役を、仕組みそのものに置き換えるという話です。プロンプトエンジニアリング → コンテキストエンジニアリング → ハーネスエンジニアリング と来て、その次に来たのがループ、という整理をされています。
で、この記事は解説記事ではありません。個人（1人）でAIエージェント基盤を数ヶ月運用している人間が、実際にループを入れてみて何が動いて何が事故ったかの記録です。結論を先に書きます。
生成をループにしてはいけない。検証をループにしろ。
理由を書いていきます。
前提：何を運用しているか
Obsidian の Vault（実体はただのフォルダ）を Claude Code で開き、CLAUDE.md を「憲法」として置いています。CEO 役の Claude が窓口になり、機械的な量産や実装は安いモデルのサブエージェント（AI社員）に振る、という構成です。SNS運用・電子書籍・動画・アプリなど複数のプロジェクトを、この1つの Vault から回しています。
つまり、ループを入れる土台（永続的な state と役割分担）は既にあった状態です。この記事はその上に「ループ」を1枚足した話になります。
ループの4タイプ（公式の整理）
まず言葉を揃えます。Claude Code 公式はループを4つに分けています。
| タイプ | 中身 | 向いている仕事 |
|---|---|---|
| ターン型 | 普段の対話。人が毎回確認する | 短い修正・探索 |
| ゴール型 | 成功条件を決めて、達成するまで反復させる | 「テストが全部通る」等 |
| 時間型 | 決まった間隔で自動起動する | 外部の変化を見に行く作業 |
| 自律型 | 検知→修正→レビューまで自走 | 定型化された継続業務 |
ポイントは、どのタイプにも必ず「停止条件」が要るということです。ここが今回いちばんの学びでした。
失敗した話：生成をループにした
先に失敗から書きます。
コンテンツ生成（記事や投稿文の下書き）を定期実行に載せた時期がありました。毎日決まった時刻に走らせて、成果物が溜まっていく——理屈の上では最高です。
実際には、品質が落ちて、費用が読めなくなりました。
原因は今なら明確に言えます。生成物の良し悪しは、機械が判定できないからです。
ループの停止条件は「AIの主観を挟まずに判定できる」必要があります。ところが「良い記事ができた」には、コマンドで真偽を返せる線がどこにもありません。判定できない以上、ループは
- 「できました」と自己申告して早々に止まる（＝質が低いまま完成扱い）
- あるいは延々と作り直してトークンを溶かす
のどちらかにしかなりません。前者が起きました。人間の目を通さない生成物は、平均に向かって滑り落ちていきます。
なので今は、創るところはセッション（人間が同席する対話）に戻しました。ループには載せません。
成功した話：検証をループにした
では何をループにすべきか。正解が1つに決まり、コマンドで判定でき、しかも人間が飽きて必ず見落とす作業です。
きっかけは、しょうもない事故でした。
電子書籍の販売リンクを複数の導線（SNS・記事の末尾・別記事）に貼っていたのですが、商品IDを1文字取り違えたまま、全部に展開してしまったのです。しかも数日気づきませんでした。人間も、AIも、目視レビューでは見落とします。文字列としては「それっぽく」見えるからです。
これ、「登録した全リンクが200を返す」という1行のコマンドがあれば、翌朝には見つかっていた種類のミスです。
賢さの問題ではなく、執念の問題でした。そして執念は、人間がいちばん苦手で、機械がいちばん得意な領域です。
最小構成
大掛かりなものは要りませんでした。3点だけです。
1. goals/*.md（守りたい状態を1つ1ファイル）
# 全KDPリンクが生きている
predicate: bash scripts/check-links.sh
status: satisfied
last-pass: 2026-07-13
on-violation: 該当リンクを一覧で報告（自動修正はしない）
必須項目は predicate だけです。終了コード0なら達成、それ以外なら違反。ルールは1つ、bashで判定できないものは目標にしない。
「品質を保つ」は目標になりません。「リンクが全部200」「テストが全部通る」「予約投稿の件数が7件ある」はなります。
2. verify.sh（全部の predicate を回す）
goals/*.md を順に読み、predicate を実行し、落ちたものを VIOLATED に書き換えて、1件でもあれば終了コード1で終わる。それだけです。
3. 時間型ループで毎日起動する
Claude Code のスケジュール実行に登録して、毎朝回します。見つけたら報告するだけ。修理はさせません。 直すのは人間か、通常の作業セッションの仕事です。検知と修理を同じループに入れると、壊れたものを壊れたまま「直した」と報告してくる事故が起きます。
これを入れてから、「静かに壊れていたことに数日後に気づく」がゼロになりました。ループの価値は、賢さではなく、毎朝必ず確認することを絶対に忘れないという一点にあります。
権限は「気分」ではなく「回数」で渡す
もう1つ効いたのが、信頼を数字で管理するという考え方です。
「慣れてきたら自動化しよう」は、精神論のままだと永遠に来ません。作業の種類ごとに実行回数と成功回数を記録して、しきい値で機械的に権限を上げます。
- 見習い（watch）：下書きまで。必ず人が見る
- 確認待ち（queue）：やってよいが、出す前に承認
- 一人前（auto）：無人で実行してよい
昇格の基準は先に数字で決めておきます（例：20回以上実行して成功率95%以上なら auto）。そして失敗したら自動で降格。台帳はただのTSVで十分です。
これがあるだけで、「どこまで手を離していいか」という判断を毎回しなくて済みます。悩みが「感覚」から「テーブルを見るだけ」に変わります。
財布とブレーキは先に付ける
ループは黙って回り続けます。だから、コストの上限は後から気づくものではなく、先に決めて自動で止まる仕組みにしてください。
- 予算ガード：1日の上限を決め、超えたらループごと止める
- 賢いモデルは「指揮官」だけに使う：何をやるか決める部分だけ高いモデルに任せ、実作業は安いモデルへ。これだけで費用は桁で変わります
-
触らせない領域を先に宣言する：認証・決済・本番設定は無人で触らせない。これは
CLAUDE.md側に「絶対ルール」として書いておきます
あと地味に大事なのが、拒否応答の扱いです。安全性の分類器に引っかかった応答は、HTTP としては成功（200）で返ってきます。終了コードだけを見ているスクリプトは「成功した」と誤認します。stop_reason を必ず見てください。静かに握りつぶされる失敗がいちばん怖いです。
まとめ
- 生成はループに載せない。 停止条件が書けないから。創るところは人間が同席するセッションに残す
- 検証をループに載せる。 正解が1つに決まり、コマンドで判定でき、人間が必ず見落とす作業こそ自動化の価値がある
- 停止条件は形容詞ではなく1行のコマンドで書く。 書けないなら、それはまだループにしてはいけない仕事
- 権限は回数と成功率で機械的に渡す。 気分で渡さない
- 予算と「触らせない領域」は着手前に決める
そして最後に、いちばん大事なことを。
検証の責任は、最後まであなたに残ります。 ループは「考えなくてよくなる装置」ではなく、「見落とさなくなる装置」です。回し始めたあとも自分が仕組みの主でいるつもりで設計しないと、静かに壊れたものを、自信満々に報告してくるAIが出来上がります。
なお、この記事で触れた「CEO＋AI社員」構成の CLAUDE.md や社員定義ファイル、context.md 方式まで含めた実際に動いている構成一式は、note にまとめてあります（有料）。この記事の内容だけでも十分に始められる書き方にしているので、丸ごと移植したい方だけどうぞ。