【保存版】ループエンジニアリング特集｜全体像の地図、コピペで使える実装69パターン

3行でわかるポイント

1. 地図——ループエンジニアリングは「AIに毎回指示する役」から自分を外し、「AIが働き続ける段取り」を設計すること。3部作で全体像がつかめる。
2. 実装——「で、何を回せばいいの？」の答えが、コピペで使える検証済み69パターン（Loop Library）。
3. 味見——道具が増えても肝は「ノーと言える検査役」と最後の味見。惣菜屋の仕込みと同じ、段取りの話。

ループの選択と、ループの実行は、別のプロセスである。

① 使いたいループを選ぶ
下の「全69パターン解説」か、公式カタログから、自分の仕事に近いものを1つ選ぶ。

② プロンプト（指示文）をコピー
このあと各ループに「📋 コピペ用」の日本語プロンプトを載せてあります。そこをまるごとコピー。

③ 自分のAIに貼り付ける
Claude Code / Codex / Cursor はもちろん、ふだん使っているChatGPTやClaudeに貼るだけでもOK。

④「（カッコ）」を自分の状況に書き換える
プロンプト内の（URL）（プロジェクト名）（回数）などを、自分の数字・対象に置き換えて実行。慣れたら「検証方法」と「止める条件」も自分用に微調整。

🎬 たとえば「ドキュメント整備ループ」を使うと——

下にある黒い「📋 コピペ用プロンプト」をコピーして、ふだんのClaudeやChatGPTに貼るだけ。するとAIがあなたのコード（や資料）全体を読み込んで、実態とズレている古い説明を見つけ、最新に直し、「ここを直しました」と確認できる形でまとめて返してくれます。
Before：説明書がバラバラで放置されて、新しい人が混乱 → After：最新に揃って、サッと確認できる形で上がってくる。これが「ループを1本回す」ということ。慣れたら、これを毎晩自動で回すこともできます。

① 検索にもAIにも「見つけてもらう」ループ

こんな時に：自分の発信が検索やChatGPTの回答にちゃんと拾われてるか不安なとき。

あなたの仕事だと：「うちのサービス、AIに聞いても出てこない」をAIが毎週点検して、抜けている言葉や情報を直す。

何が起きる：放っておくと埋もれる発信が、見つけてもらえる状態にキープされる。

② 同じ失敗を二度とさせないループ

こんな時に：一度やらかしたミスを、二度と繰り返したくないとき。

あなたの仕事だと：請求書の宛名ミスが起きたら「宛名チェック」を1個追加→次から自動で引っかける。

何が起きる：ミスのたびに仕組みが1つ賢くなる（私のAI秘書が同じミス2回で止まるのと同じ）。

③ 身内のイエスマンにしないループ

こんな時に：自分の案に自信はあるけど、見落としが怖いとき。

あなたの仕事だと：新しいキャンペーン案を、わざと別のAIに「これ失敗するとしたら？」と攻撃させる。

何が起きる：「いいですね！」ばかりの心地よさで突き進んで事故る、を未然に防げる。

④ 1個のAIを盲信しないループ

こんな時に：大事な文章や判断を、AI1個だけに任せるのが不安なとき。

あなたの仕事だと：重要メールやLPの文言を、2つのAIにチェックさせ、両方OKで初めて出す。

何が起きる：1個のAIの思い込みミスを、もう1個がすり抜けさせない。

⑤ その日の出来事を発信ネタに変えるループ

こんな時に：「今週なにやったっけ」が思い出せない、発信ネタが切れがちなとき。

あなたの仕事だと：1日の作業・更新を夜にAIがまとめ→翌朝のSNSや週報の素になる。

何が起きる：記録ゼロ手間で、発信のネタ切れと「やった感の消失」がなくなる。

⑥ お金の取りこぼしを拾うループ

こんな時に：請求したのに入金されてない、をうっかり忘れがちなとき。

あなたの仕事だと：売掛・未入金・返金をAIが毎週チェックして「これ未入金だよ」と教えてくれる。

何が起きる：人間が忘れがちなお金の抜けを、仕組みが代わりに見張ってくれる。

ドキュメント整備ループ The docs sweep

コードの実態に合わせてドキュメントを最新に保ち、レビューできる形（プルリクエスト）で提出するループです。ドキュメント点検が必要になるたびにコード全体を見直し、すべての説明が今の実装どおりかを確認します。古くなった記述を直し、変更を検証してから、プルリクエストを開きます。

▶ こんな時に：サービスの説明書やマニュアルが実態とズレてきた時に、まとめて今の状態に直したい時に効きます。

✅ やるとこうなる：説明書とソフトの中身がズレて誰も信じなくなった状態 → 最新の中身どおりに全部書き直され、確認済みの説明書がレビュー待ちのPRとして1本上がってる状態になる。

アーキテクチャ納得ループ The architecture satisfaction loop

システムの構造（設計）を、小さくテスト済みで個別にレビューできる区切りごとに作り直していくループです。納得いく構造になるまで作り直しを続け、大きな一歩ごとに実際に動作テストし、自動レビューを回し、その都度保存（コミット）します。

✅ やるとこうなる：いじるのが怖い絡まった配線のような土台 → 小さく直して毎回テスト＆コミットを重ね、納得いく骨組みに整い、進捗メモに足跡が全部残った状態になる。

50ミリ秒未満ページ表示ループ The sub-50 ms page-load loop

すべてのページが安定して50ミリ秒未満で表示されるまで、表示速度を最適化し続けるループです。速度のための改善を続け、大きな変更ごとに、同じ繰り返し可能なテスト条件で全ページの表示速度を測ります。

▶ こんな時に：サイトやサービスの表示が遅くて困っている時に、全ページを速く軽くしたい時に効きます。

✅ やるとこうなる：開くたびモタつくページ → 同じ条件で測り直しながら速くし続け、全ページが毎回0.05秒以内で開く状態になる。

本番エラー一掃ループ The production error sweep

本番環境で実際に対処すべきエラーを見つけて直し、検証するループです。本番のログをエラー観点で点検し、対処すべき問題が見つかれば根本原因まで追って修正し、直ったことを検証してプルリクエストを開きます。対処すべきエラーがなければ、何も変更せずに止まります。

▶ こんな時に：稼働中のサービスでエラーが出ていないか定期点検し、出ていたら直したい時に効きます。

✅ やるとこうなる：本番ログに埋もれて放置されたエラー → 直すべきものだけ根っこまで追って直し検証し、修正PRが上がる（直すものが無ければ何も触らず終わる）状態になる。

SEO/GEO見つけられやすさ改善ループ The SEO/GEO visibility loop

検索エンジンとAIの回答での「見つけられやすさ」について、最も効果の大きい弱点から直していくループです。クロールのされやすさ・インデックス・ページの意図・タイトル・内部リンク・構造化データ・出典の引用・答えを先に出す内容といった観点で監査し、効果の見込み順に弱点を並べ、最も効くものから直して、同じクロールと狙ったクエリのベンチマークを検索エンジンとAI回答エンジンで再実行します。

▶ こんな時に：検索やChatGPTなどのAIから自社サイトが見つけられず集客に困っている時に、強く効きます。

✅ やるとこうなる：検索にもAIの回答にも出てこないサイト → 影響の大きい穴から順に塞ぎ直しを繰り返し、重大な技術問題ゼロ・狙った検索語が答えられるページに全部つながった状態になる。

ログ網羅ループ The logging coverage loop

システムの重要な処理経路すべてに、役立つ・テスト済みのログ（動作記録）を足していくループです。ログ出力を点検し、抜けている部分を、すべての重要な経路が役立つテスト済みのログを出すようになるまで補います。

✅ やるとこうなる：どこで何が起きたか追えない無言のシステム → 大事な経路すべてに使える・テスト済みのログが付き、トラブル時に足取りを追える状態になる。

製品まるごと評価ループ The full product evaluation loop

本番をローカルで再現し、製品のあらゆる画面・機能をテストして、確認できたバグを全体的に直すループです。機能・権限・画面遷移・ボタン・入力欄・状態・作業フローをすべて洗い出して合格基準を定め、実際のユーザーとしてテストし、再現できる証拠とともに全バグを記録。共通原因を見て一貫した修正と再発防止テストを入れ、きれいに通るまで繰り返します。

▶ こんな時に：リリース前やリニューアル前に、サービス全体を一通り触ってバグを潰しきりたい時に効きます。

✅ やるとこうなる：どこが壊れてるか誰も把握してない製品 → 本番そっくりの環境で全画面・全ボタンを実ユーザー目線で総点検し、共通原因ごとに直してテストを足し、不具合ゼロで通るまで仕上がった状態になる。

テスト高速化ループ The test-suite speed loop

テストの網羅性・チェック内容・独立性を弱めずに、テスト一式の実行を速くするループです。網羅性を減らしたり挙動を変えたりせずに、テスト一式をできるだけ速く走るよう最適化します。

✅ やるとこうなる：待たされる長いテスト → チェックの幅も厳しさも落とさないまま、できる限り速く終わるテストになる。

リリース後ベースライン記録ループ The post-release baseline loop

完了したリリースごとに性能を計測し、再現できる基準値（ベースライン）として記録するループです。現在のリリースが終わったあと標準のベンチマークを実行し、その結果を新しい基準値として記録します。

✅ やるとこうなる：前と比べて速くなったか遅くなったか分からないリリース → 標準ベンチで測り、次回の比較に使える再現可能な基準値が記録された状態になる。

製品アップデート・ポッドキャスト化ループ The product update podcast loop

意味のある製品アップデートを、出典に基づく短いポッドキャスト1本に変えるループです。毎晩、一般公開された変更を確認し、ユーザーが知るべきものだけを選んで検証し、「何が変わったか・なぜ重要か・どう試すか」を説明する3〜5分の音声にします。意味ある変更が何も出ていなければ作りません。

▶ こんな時に：製品やサービスの更新内容を、お客さん向けに短い音声番組として手軽に発信したい時に効きます。

✅ やるとこうなる：更新があっても誰も気づかない製品 → 毎晩ユーザーに必要な変更だけ選んで裏取りし、何が変わり・なぜ大事で・どう試すかを語る3〜5分のポッドキャストが、出典付き・公開前確認待ちで用意される状態になる。

Clodex 相互レビュー（クロデックス）ループ The Clodex adversarial-review loop

Codex（別のAI）にClaudeのプルリクエストをレビューさせ、問題が解消するまで回すループです。Claudeがタスクを計画・実装してプルリクエストを開き、Codexに厳しめのレビューを依頼し、許容した深刻度を超える指摘を直して最大5回まで繰り返します。エラーで終わった実行を「承認済み」と偽って報告することは決してしません。

✅ やるとこうなる：自分だけのレビューで通したPR → 別AI（Codex）に厳しくダメ出しさせ受け入れ基準以上の指摘を直すのを繰り返し、Codexが承認するまで磨かれたPRと判定・残課題が揃った状態になる。

悪魔の代弁者（あえて反対する）ループ The devil’s-advocate loop

設計を、影響の大きい反論がすべて解消されるか明確に受け入れられるまで徹底的に問い直すループです。踏み切る前に批判役に「これは間違っている」と主張させ、各反論と対応状況を記録し、作る側は弱点を修正・検証するか、受け入れる理由を文書化します。影響の大きい反論が残らなくなったら止まります。

▶ こんな時に：新しい事業方針や大きな決断の前に、あえて弱点を徹底的にツッコませて穴をなくしたい時に効きます。

✅ やるとこうなる：勢いで決めかけた設計 → 反対役にわざと『これは間違ってる』と突かせ、重大な弱点を全部直すか『承知の上』と理由を残し、その記録が残った状態になる。

サムネイル無限改善ループ The Infinite Clickbait thumbnail loop

サムネイル案を、視聴者を誤解させずに品質基準を超える1つができるまで磨き続けるループです。承認済み素材から10案を作り、実際のYouTube表示サイズで分かりやすさ・好奇心・感情を動かす力・正確さを採点。上位3案を改善して再採点し、最も強い案を磨きます。動画が中身で応えられない誇張は却下します。

▶ こんな時に：YouTubeなどのサムネイルを、釣りすぎず中身に合った形で何案も試して一番良いものを選びたい時に効きます。

✅ やるとこうなる：なんとなく作った1枚のサムネ → 10案をYouTube実寸で採点し上位3案の弱点を磨いて再採点、基準を超える勝者1枚と次点2枚（中身で裏切らないもの限定）が根拠付きで選ばれた状態になる。

作る人・チェックする人 自律ループ The autonomy-loop builder-reviewer loop

コードを「作る側」と「レビューする側」の間で渡し合い、受け入れた修正それぞれをテストで証明するまで回すループです。作る側は限定した1変更と「修正前は失敗・修正後は成功」のテストを足し、レビューする側はその修正を一度戻して本当にテストが効くか証明します。両方通った時だけ受け入れます。

✅ やるとこうなる：直したつもりで実は直ってないコード → 作る役と確かめる役が別作業場で渡し合い、修正前は赤・修正後は緑になるテストで証明できたものだけ採用され、証拠付きで残った状態になる。

Revolve バージョン管理実験ループ The Revolve versioned-experiment loop

プロンプト・コード・設定を、比較可能で履歴を残す実験で改善していくループです。目標と予算を定め、テストと採点を固定し、今のバージョンを保存して基準値を記録。各回ごとに仮説を1つだけ試し、明らかで後退のない改善だけを残します。

✅ やるとこうなる：勘で書き換えて元に戻せないプロンプトや設定 → テストと採点を固定したうえで1案ずつ実験し、後退なしの勝ちだけ残して、最良版・比較・元に戻す手段がそろった状態になる。

5分ごとリポジトリ世話役ループ The five-minute repository maintainer loop

作業中のAIを邪魔せずに、リポジトリの仕事を前に進め続けるループです。5分ごとに起きて各リポジトリの状況を読み、許可された範囲で最も価値の高い限定タスクを割り当てます。作業を反映する前にテスト・自動レビュー・CIが緑であることを必須とし、取り消せない判断は人間に上げます。

✅ やるとこうなる：放っておくと止まる複数リポジトリ → 5分おきに各リポジトリを見回り、許可範囲で一番価値ある作業を回し、テスト・実証・CI緑を通った変更だけが進み、全部片付くまで自走する状態になる。

約束と実態の照合ループ The promise-to-proof loop

お客さん向けに掲げた主張がすべて本当かを点検し、最もリスクの高いズレから直すループです。マーケティング・資料・デモ・AIの回答で語る約束をすべて列挙し、今の製品の挙動と照らして「証明済み・誤解を招く・裏づけなし」等に分類。最もリスクの高いズレを直すか言い回しを狭めます。

▶ こんな時に：広告やLP・資料で「できます」と言っていることが本当に実態と合っているか棚卸ししたい時に効きます。

✅ やるとこうなる：宣伝と実際の機能がズレた製品 → 全ての顧客向け約束を実挙動と突き合わせて『証明済み/誇大/根拠なし』等にラベル付けし、一番危ない食い違いから直して、危険な未証明の約束ゼロの状態になる。

複数AI合意ループ The multi-LLM convergence loop

2つの別々のAIに同じ成果物をレビューさせ、両方が同じ修正なしの版を承認するまで回すループです。別々の提供元の本当に異なるAIの一方がレビューし、必要な修正だけを当て、直した版をもう一方に渡します。両方が同じ版を承認した時だけ成功とします。

▶ こんな時に：重要な企画書や契約文・コピーを、別々のAIにダブルチェックさせて両方OKになるまで仕上げたい時に効きます。

✅ やるとこうなる：片方のAIだけが見て通した成果物 → 別ベンダーの2つのAIに同じものをレビューさせ、必要な修正だけ入れて、両方が同じ一字一句変えない版を承認するまで詰めた状態になる。

UI/UX 採点ループ The UI/UX Score Loop

実際のユーザー操作を一通りなぞり、各画面を採点し、弱い所を直して再テストするループです。本物のブラウザで毎回まっさらな状態から始め、意味ある画面を撮って1つのチェックリストで採点し、最も弱く安全に直せる箇所を改善。流れ全体を再実行し、後退のない変更だけ残します。

▶ こんな時に：申し込みフォームや登録の流れで離脱が多い時に、画面の使いやすさを採点しながら直したい時に効きます。

✅ やるとこうなる：使いにくいまま放置された申込みなどの画面 → ログインゼロの新規状態から実ブラウザで通しで操作し各画面を採点、一番弱い所を安全に直して再テストを繰り返し、後退なしで改善された状態になる。

アクセシビリティ修復ループ The accessibility repair loop

キーボード操作・スクリーンリーダー・弱視などの利用者にとっての障壁を見つけ、最も害の大きいものから直すループです。アクセシビリティ基準（例：WCAG 2.2 AA）に照らして自動・手動でテストし、害の大きさで順位づけして直し、再点検します。点検を黙らせたり目標を緩めたりは決してしません。

▶ こんな時に：高齢者や障害のある人など、より多くの人が自社サイトを問題なく使えるようにしたい時に効きます。

✅ やるとこうなる：キーボードや読み上げで使えない人を締め出した画面 → 自動・手動チェックで障壁を見つけ被害の大きい順に直し再チェックし、確認できた修正だけ残って通れる状態になる。

AI対戦アリーナ（アクセルロッド）ループ The Axelrod subagent arena loop

AIエージェントが繰り返しの2択ゲームで、協力・報復・許しを学ぶかを検証するループです。2体のAIで決まった形のトーナメントを行い、毎回それぞれが秘密裏に「協力」か「裏切り」を選び、固定の点数を適用。相手の正体と内心は隠したまま、全ての手と合計を検証します。

✅ やるとこうなる：AI同士が協力するか裏切るか分からない状態 → 180ラウンドの固定トーナメントを回し、協力・報復・許しの傾向が得点と安定度のランキングで見える状態になる。

新プロジェクト準備ループ The prepare-a-new-project loop

別々のエンジニアが読んでも実質同じシステムを作れるレベルまで、プロジェクトの資料を強化するループです。要件・設計・合格基準つきタスク・テスト方針がそろっているか確認し、各回ごとに「優秀な2人が別物を作ってしまう原因になる最大の抜け」を1つ直します。

▶ こんな時に：外注先や複数メンバーに開発を任せる前に、誰が読んでも同じものを作れる仕様書に固めたい時に効きます。

✅ やるとこうなる：人によって解釈が割れる曖昧な企画書 → 矛盾や穴を毎回一番大きい所から潰し、独立した2人のエンジニアが見てもほぼ同じシステムを組めるところまで設計書が固まった状態になる。

リビング・ストーリー（生きた記録）ループ The Living Story loop

プロジェクト・優先事項・未解決の課題・最近の成果を、証拠に裏づけられた日々の物語として保ち続けるループです。設定した期間ごとに焦点・期限・未解決の課題・証拠つきの成果を記録し、過去の課題は引き継いで完了を証明するか「古い／要確認」と印をつけ、黙って消すことはしません。

▶ こんな時に：複数の仕事や案件が同時進行している時に、今どこが焦点で何が止まっているかを毎日の記録として把握したい時に効きます。

✅ やるとこうなる：今どのプロジェクトがどうなってるか散らばって見えない状態 → 毎回リポジトリと目標を読み、焦点・締切・未解決・最近の成果を証拠付きで書いた記録が更新され、前回の課題が消えずに引き継がれた状態になる。

リサーチ→成果物ループ The research-to-artifact loop

絞り込んだ調査を、実際の意思決定を支えられる出典つきの成果物に変えるループです。支えるべき決定・合格基準・調査予算を定め（指定がなければ優れた出典10件以内か90分以内を上限）、可能なら最新の一次情報を優先。各調査のあと成果物を更新し、証拠の抜けを埋めます。証拠の捏造はしません。

▶ こんな時に：新規事業や設備投資など重要な判断のために、出典つきの調査メモやレポートを作りたい時に効きます。

✅ やるとこうなる：判断材料が足りない調べ物 → 出典10本以内など予算内で一番効く不確実性を埋めながら詰め、受け入れ基準を満たし主要な主張が出典に紐づく『決められる資料』が、確信度と次の一手付きで仕上がった状態になる。

エラーメッセージ書き直しループ The error-message rewrite loop

ユーザーに見えるエラー文をすべて見つけ、分かりにくい文言を書き直し、たどり着ける状態を検証するループです。場所・きっかけ・現在の文言・リスク・置き換え案を記録し、害の大きい順に平易な言葉で書き直します。提供元名や内部の識別子は出さず、変更ごとに該当状態を再現して検証します。

▶ こんな時に：サービス利用中にお客さんが見る「エラー表示」を、分かりやすく親切な文言に直したい時に効きます。

✅ やるとこうなる：意味不明で不親切なエラー文だらけの製品 → 全エラーを棚卸しして害の大きい順に、平易な言葉と次の一手付きに書き直し、内部情報を漏らさず実ブラウザで確認済みの状態になる。

横断検証プレイブックループ The cross-run playbook loop

学び（教訓）を、複数の独立した実行で効くと確かめられて初めて、恒久的な手引きに昇格させるループです。記録した教訓はどれも「未検証の助言」として扱い、規定回数（既定は3回）の独立した実行で成功して初めて昇格。1回の成功だけで昇格させることは決してしません。

✅ やるとこうなる：一回うまくいっただけの自己流ノウハウ → 毎回1つだけ試して成果を記録し、独立した3回など複数回で効いたものだけを正式な手引きに昇格させ、効かなくなったら外す状態になる。

認識の最前線ループ The epistemic frontier loop

難しい意思決定を、競合する仮説を最も価値の高い証拠でぶつけ合わせて前に進めるループです。本当に異なる仮説を最低3つ立て、結論を覆しうる最小で安全なテストを行い、敵対的な批判役に最有力仮説を攻撃させながら、新しい証拠で決定が変わりうる間、最大5回繰り返します。

▶ こんな時に：答えのはっきりしない難しい経営判断を、思い込みでなく根拠を比べながら詰めていきたい時に効きます。

✅ やるとこうなる：答えが出ない難しい決断 → 事実・仮説・未知を切り分け3つ以上の対抗仮説を立て、一番効く検証を最小コストで回しては反論役にぶつけ、どの説が一番説明できるか確信度付きで見える状態になる。

依存パッケージ仕分けループ The dependency triage loop

依存更新の自動提案（Dependabot）を、隔離環境でテストし、証拠に基づいてリスク評価し、1件ずつ順番にマージするループです。差分・リリースノート・脆弱性情報を読み、隔離環境でテストして分類。マージは1件ずつ直列で行い、重大・破壊的・セキュリティは承認を求めます。

✅ やるとこうなる：溜まったライブラリ更新のPRの山 → スナップショットで対象を固定し1件ずつ隔離環境でテストしてリスク判定、許可済みの安全な小更新だけを順番にマージし、要承認分は止めて証拠付きで仕分けた状態になる。

再開できる引き継ぎループ The restartable handoff loop

次の人やAIが推測せず安全に作業を再開できるだけの、検証済みの引き継ぎを残す「作業終了時の手順」です。現在の目標・変更点・検証の証拠・未着手の範囲・触ってはいけない領域・最後の判断を記録し、安全な次の一手をちょうど1つだけ示します。その次の一手には自分では着手しません。

▶ こんな時に：作業を別の人に引き継ぐ時に、相手が迷わず再開できるよう状況をきちんと残したい時に効きます。

✅ やるとこうなる：作業を中断したら次の人が手探りになる状態 → 目標・変更・検証証拠・触ってない範囲・危険箇所・最後の決定を記録し、新しい人やAIが推測ゼロで安全に再開でき、次の一手1つだけ示された引き継ぎが残った状態になる。

React Doctor 100点満点ループ The React Doctor 100/100 loop

本番のReactアプリ（Webアプリを作る仕組み）すべてが、専用点検ツールで100点満点を取るまで根本原因を直し続ける徹底点検ループです。基準値を記録し、根本原因を1つずつ直して関連チェックを再実行。除外や抑制で問題を隠すことは決してしません。

✅ やるとこうなる：健康診断で問題ありのReactアプリ → 除外やルール緩めでごまかさず根っこから1つずつ直して再スキャンを繰り返し、全アプリが100点満点を取り直した状態になる。

証拠優先・機能追加ループ The evidence-first feature loop

実装の前に今のリポジトリの実態を調べてから、安全な1機能分だけを作って検証する、範囲を限定したループです。現在の実装・関連サービス・テストを編集前に読み、証拠・リスク・影響を報告。最小の変更を行い、ユーザーに見える状態を手で確認します。この1機能分が終わったら止まります。

✅ やるとこうなる：中身を確かめずいきなり手を付けて壊す開発 → 既存コードやテストを読んで証拠・リスクを報告してから最小の変更で機能を1区切り足し、画面まで手で確認し、次に作るべき区切りまで示された状態になる。

毎晩の変更履歴ループ The nightly changelog loop

変更履歴（更新内容のメモ）を、前日の意味ある変更で常に最新に保つループです。毎晩、前日の変更を見直し、ユーザーが知っておくべき内容を変更履歴に書き足す、というのを繰り返します。

▶ こんな時に：サービスやツールを日々更新している人が、お知らせ・更新情報をこまめに記録しておきたい時に効きます。

✅ やるとこうなる：放っといたら何を直したか誰も覚えてない状態 → 毎晩前日の変更を見直して、利用者が知るべき変化がそのまま変更履歴に載り続ける状態になる。

品質連続合格ループ The quality streak loop

現実に近いテストが決めた回数だけ連続で通るまで、製品の不具合を直し続けるループです。現実的な場面をテストし、失敗が出たらそれを記録して再発防止テストを追加し、修正して連続記録を最初からやり直します。連続で決めた回数成功したら止まります。

▶ こんな時に：品質を一定ラインまで安定させてから世に出したい時、「たまたま動いた」を防ぎたい時に効きます。

✅ やるとこうなる：テストがたまにコケる不安な状態 → 失敗を記録して回帰テストごと直し、現実シナリオが連続でぶっ通しで通る『連勝記録』が積み上がる状態になる。

画面再現ループ（War Loops） War Loops: frontend reconstruction

実在する画面を再現し、見た目や動きのズレのうち一番弱い部分だけを直していくループです。本物のブラウザで取り込んでレイアウト・スタイル・動きを記録し、静止版と動く版を作り、PC・タブレット・スマホの各サイズで元と比べて、一番再現度の低い部分だけを直します。

▶ こんな時に：既存サイトのデザインをそっくり作り直したい時に効きます（基本は制作向け）。

✅ やるとこうなる：お手本サイトと似て非なる微妙にズレた画面 → PC・タブレット・スマホ全サイズで見比べて一番ズレてる所だけ直し、ビルド・仕様書・スコア・残り課題まで揃った再現版が手に入る状態になる。

チャンピオン勝ち抜きループ The self-improving champion loop

プロンプトや方針の変更を、初見の検証用ケースで勝った時だけ採用するループです。今の最良版（チャンピオン）を保存し、毎回記録された失敗をもとに一カ所だけ変え、新案が検証ケースで決めた差以上に勝った時だけ採用、そうでなければ今の版を維持します。

▶ こんな時に：AIへの指示文（プロンプト）を改良したい時、思いつきで変えて逆に悪化するのを防ぎたい時に効きます。

✅ やるとこうなる：新案を雰囲気で採用して後で劣化する状態 → 手つかずの検証データで現王者に勝った時だけ昇格させるので、本当に強くなった改善版だけが残る状態になる。

完了の約束ループ（Codex） The Codex completion-contract loop

「完了とは何か」を先に定義し、報告する結果すべてに証拠を求めるループです。動き出す前に必要な成果とその証拠を全部定義し、各要件を「証明済み・弱い・不足・矛盾」のどれかに印を付け、全部が証明済みになった時だけ完了とします。

▶ こんな時に：AIに長い作業を任せて「やったつもり」報告を防ぎ、証拠で完了を確かめたい時に効きます。

✅ やるとこうなる：『たぶん終わった』で未完了が混じる状態 → 完了の定義と証拠を先に決めて全部の根拠が揃うまで完了扱いせず、要件と証拠の対応表付きで本当に終わったか一目で分かる状態になる。

最近のダメ出し総ざらいループ The recent-feedback sweep

最近のユーザーの指摘を、プロジェクト全体の点検と検証済み修正につなげるループです。指定期間の「ここがおかしい、直して」を全部見直して重複を除いた課題リストを作り、各パターンについてプロジェクト全体を点検し、確認できた箇所を直して再発防止チェックを足します。

▶ こんな時に：「前にも同じこと言ったよね」を減らしたい時、過去の指摘を一カ所だけでなく全体に反映させたい時に効きます。

✅ やるとこうなる：指摘した不具合がそこだけ直って他に同じ問題が残る状態 → 最近の指摘を失敗パターンにまとめてプロジェクト全体を横断点検し、同じ穴を全部塞いだ上で再発防止テストまで入る状態になる。

値の伝播チェックループ The propagation compliance loop

ある値を変えたあと、古い値のまま残っている他の場所を全部見つけるループです。バージョン・件数・名前などを変えたら、プロジェクト内を古い値で検索し一致箇所を一つずつ確認。本当に古いものは直し、意図的な履歴や例は残します。古い値がゼロになるまで繰り返します。

▶ こんな時に：価格・人数・社名などを変えたあと、サイトや資料の各所に残る古い数字を取りこぼさず直したい時に効きます。

✅ やるとこうなる：数字や名前を1か所変えたら別の場所に古い値が残る状態 → プロジェクト全体を検索して残った古い値がゼロになるまで直し、意図的な履歴や例は守ったまま整う状態になる。

見た目そのままCSS削減ループ The pixel-safe CSS trim loop

テスト対象の画面を見た目そっくりに保ったまま、ユーザーに送るスタイル用コード（CSS）を減らすループです。スタイルの記述を一つ消して作り直し、スクリーンショットを比べ、全スクショが1ピクセルも変わらずサイズが小さくなった時だけ残し、ダメなら元に戻します。

✅ やるとこうなる：利用者に重いCSSをそのまま送ってる状態 → 1行ずつ削ってスクショがピクセル単位で完全一致する時だけ残すので、見た目を一切変えずに配信コードだけ軽くなる状態になる。

お片付けループ The housekeeper loop

コードのプロジェクトを、確実で低リスクな変更を一つずつ重ねて整理するループです。使われていないコード・古いファイル・重複・リンク切れ・名前のバラつきを見直し、安全な掃除を一つ証明して最小限の変更を加え、ビルド・テスト・確認をやり直します。

✅ やるとこうなる：使われない死んだコードや壊れたリンクが散らかった状態 → 安全と確認できた小さな掃除を1件ずつビルド・テスト通しで証明しながら進め、検証済みの片付けだけが反映された綺麗なコードになる。

不安定テスト安定化ループ The test stabilizer loop

結果が安定しない「気まぐれな」テストを見つけ、根本原因を直し、全体テストを繰り返し通して安定を証明するループです。同じ条件で何度も動かして結果が毎回変わるテストを洗い出し、共有状態・タイミング・順序などの根本から直します（ただ待たせたり再試行でごまかさない）。

✅ やるとこうなる：たまに落ちる気まぐれテストに振り回される状態 → 根本原因（共有状態・タイミング・順序・外部依存）を突き止めて直し、全テストが連続で通る安定状態を実証して終わる。

成果物→手順化ループ The artifact-to-skill loop

うまくいった成果物の裏にあるやり方を抜き出し、別の新しいケースで通用するか確かめるループです。成功の判定基準を記録し、判断・順番・コツを抜き出し（その場限りの事情は除く）、別の人が新しい本物のケースに当てて試します。元の成果物なしで品質基準を満たせたら止まります。

▶ こんな時に：一度うまくいったやり方を、再現できる「型」として残し、他の場面でも使えるようにしたい時に効きます。

✅ やるとこうなる：上手くいった成果物が一回限りの当たりで終わる状態 → そのやり方の判断・手順・チェックを抽出して別の新しい案件で第三者が再現できるか実証し、再利用できる手順書として一般化される状態になる。

返金フォローアップループ The refund follow-up loop

返金が手元に届くか、本当に本人の助けが必要になるまで追いかけ続けるループです。会社名と請求情報を渡すと、認められた問い合わせ窓口から請求を始め、返信・約束・期限を追って返金が届くまでフォローを続けます。一回ごとのフォローに文脈が引き継がれるよう短いメモを残します。

▶ こんな時に：サービスの返金交渉を粘り強く続けてほしい時、やり取りの追いかけを任せたい時に効きます。

✅ やるとこうなる：返金申請して放置され有耶無耶になる状態 → 承認済み窓口から申請して返事・約束・期限を追い続け、お金が実際に振り込まれるまで（か本当に行き詰まるまで）粘り続ける状態になる。

フレームレート安定化ループ The stable-frame-rate loop

ゲームなどの動作のカクつきを、測定で見つけた一番大きい原因から一つずつ直し、なめらかさが安定するまで続けるループです。繰り返せる計測条件を決めてフレーム時間やFPSを記録し、一番大きいボトルネックに一つだけ手を入れ、同条件で測り直して悪化させずに改善した時だけ残します。

✅ やるとこうなる：ゲームがカクついて原因も分からない状態 → 同条件のベンチで一番効くボトルネックを1つずつ潰し、目標FPSが一定時間ガタ落ちなしで保たれるまで改善して、前後比較データ付きで滑らかになる状態になる。

ループ採用担当ループ The Loop Hiring Manager

繰り返しの仕事の中で「ループにする価値があるもの」を見つけ、価値を証明できない自動化は却下するループです。定例の雑務や繰り返す失敗を見直し、既存ループの流用を優先、合わなければ最小調整、それも無理な時だけ新規設計。証拠付きの候補を最大三つに絞り、承認なしには何も導入しません。

▶ こんな時に：繰り返しの作業の中から「自動化する価値が本当にあるもの」だけを見極めたい時に効きます。

✅ やるとこうなる：自動化すべき繰り返し作業を見落としてる状態 → 公開ループ集と照らして仕組み化すべき仕事を見つけ出し、根拠付きで最大3案・お試し1案に絞った採用候補リストが手に入る状態になる。

公開前ファクトチェックループ The pre-publish source-check loop

公開前に、検証できる主張すべてを最新の一次情報と突き合わせ、一番危ない根拠の穴から直すループです。事実・統計・引用を全部洗い出し「裏付けあり・古い・誤った帰属・根拠なし」と分類して、最も危ない食い違いを直します。出典のでっち上げや引用文の改変は絶対にしません。

▶ こんな時に：記事や資料を出す前に、数字や引用の根拠を確かめて、間違った情報の公開を防ぎたい時に効きます。

✅ やるとこうなる：裏取りせず公開して古い数字や誤引用が混じる状態 → 公開前に検証できる主張を全部洗い出して一次情報と照合し、危ない箇所から直して、主張と出典の対応表付きで安心して出せる状態になる。

リポジトリ整理ループ The repository cleanup loop

ソースコードの保管庫（リポジトリ）に散らかった作業を整理し、不要になった古い状態を安全に片づけるループです。枝（ブランチ）・レビュー依頼・変更履歴・作業用フォルダを点検し、価値ある作業は救い出し、確実に不要と分かったものだけを掃除します。

✅ やるとこうなる：散らかったブランチやPRを放っておくと迷子の作業が埋もれる → 回すと拾うべき仕事は救出され、不要なゴミは安全に消えて、リポジトリが最新で整理された状態になる。

まとめてリリースループ The stale-safe batch release loop

有効な変更だけをまとめて、完成品として一括で世に出す（リリースする）ループです。保留中の変更を見直し、古いものや未完成のものを除外し、有効な変更だけを最新の本流に統合してから一緒に出します。古い・中途半端なものを混ぜません。

✅ やるとこうなる：古い・未完成の変更が混ざったまま出すとリリースが崩れる → 回すとそれらを除外して有効な変更だけまとめ、最新の本流から完成品だけが揃ってリリースされる状態になる。

本番データ清掃ループ The production data cleanup loop

本番環境の中で、ルールに合わない（許可されていない）データを取り除き、同じ仕分けミスが二度と起きないようにするループです。本番の記録を見直して定義に合わないものを削除し、仕分けの仕組み（分類ロジック）自体を改善するので、同じ間違いが戻ってきません。

▶ こんな時に：顧客リストや会員データに「区分が間違ったまま混ざった行」がたまっている時、それを消すだけでなく仕分けの基準ごと直したい時に効きます。

✅ やるとこうなる：本番データに混ざったルール違反の行を放置すると分類ミスが繰り返される → 回すと違反データが消え、分類の仕組みも直って、残ったデータが検証済みのきれいな状態になる。

問い合わせ→修正準備完了ループ The ticket-to-PR-ready loop

問い合わせ票やお客さんからのクレームを、レビューにかけられる状態まで仕上げたプログラム修正に変えるループです。不具合をいちばん小さな環境で再現し、本当の原因を突き止め、いちばん小さく確実な修正を当てて再現手順とテストを通します。本気で2回試しても再現できなければ「できなかった」と正直に言います。

▶ こんな時に：お客さんからの「ここが動かない」というクレームを、丸投げではなく原因と証拠つきで開発担当に渡したい時に効きます。

✅ やるとこうなる：クレームやバグ報告を受けたら、回すと最小の環境で再現され原因が証明され、最小限の修正と前後比較の証拠つきで、担当者がそのまま見られる修正案になって返ってくる（2回試して再現できなければ正直にそう報告される）。

成功パターン採掘ループ The Strip Miner loop

許可されたAIの作業履歴の中から、何度も成功していて、まっさらな状態でやり直しても通用する手順を掘り出すループです。独立して3回以上はっきり成功したものを探し、記録は鵜呑みにせず、失敗や隠れた立て直しが混じる候補は除外。元の記録を見ずにやり直して再現できるか確かめます。

✅ やるとこうなる：過去のAI作業履歴を放置すると埋もれたまま → 回すと3回以上独立して成功し再実行でも通る手順だけが、追跡可能なステップと止める条件つきで抽出され、再生したループ・却下分・障害がレポートされる状態になる。

実証監査ループ The Groundtruth loop

プロジェクトを思い込みではなく実物の証拠から監査し、すべての領域を「証明済み・弱い・未検証」のどれかで報告するループです。設計・互換性・セキュリティ・権限・性能などを実際のコードと設定から直接の証拠つきで記録し、最後に専門用語なしの概要と「領域と証拠の対応表」を出します。

▶ こんな時に：外注や他人が作ったシステムを引き継ぐ時、「どこが本当に大丈夫でどこが怪しいか」を証拠つきで棚卸ししたい時に効きます。

✅ やるとこうなる：プロジェクトを思い込みで語ると危うい → 回すと実際のコードと設定を根拠に各領域が『証明済み／弱い／未検証』で判定され、平易な概要と領域ごとの証拠対応表が手に入る状態になる。

復旧実証ループ The Recovery Proof loop

バックアップが本当に必要な場面で復元できるかを、使い捨ての隔離された清潔な環境の中で証明するループです。本物のバックアップをランダムに選んでゼロから復元し、データの整合性やどこまで戻せるかを確認。本番を上書きしない・復元データを外に出さない、という安全線は絶対に守ります。

▶ こんな時に：「バックアップは取ってあるけど、いざという時に本当に戻せるのか」を試したことがない事業で、その不安を実際に証明しておきたい時に効きます。

✅ やるとこうなる：バックアップが本当に戻せるか分からないまま放置すると有事に詰む → 回すと使い捨ての隔離環境でゼロから復元し、整合性も実際の読み書きもどこまで戻せるかも検証されて、必要な復旧が連続成功で実証される状態になる。

依存ライブラリ脆弱性つぶしループ The dependency-CVE burndown loop

プログラムが利用している外部部品の既知の弱点（CVE＝公開された脆弱性）を、危険な順に直しては再点検するループです。最新の注意喚起情報で弱点を洗い出し、「実際に手が届くか・悪用条件がそろうか」を調べて順位づけし、いちばん危険なものから最小限の変更で直します。

✅ やるとこうなる：依存ライブラリの脆弱性を放置すると穴が残る → 回すと到達可能な重大な脆弱性がリスク順に潰され各修正後に再スキャンされて、悪用可能な脆弱性が消えるか証拠つきリスク判断が残った状態になる。

React Doctor修繕ループ The React Doctor repair loop

React（Webアプリを作る仕組み）専用の点検ツール「React Doctor」を使い、本物の指摘を少しずつ直して、不具合の出戻りがない改善だけを残すループです。現状を記録し、1回につき本物の指摘を最大5件だけ直して関連チェックをやり直し、確認できた改善だけ残します。

✅ やるとこうなる：Reactの不具合を闇雲に直すと壊しがち → 回すと毎回5件までの本物の指摘をエラー優先で直し、スキャンと検証を通った改善だけが残って、最初より前進した状態になる。

テスト100%カバレッジ達成ループ The 100% test coverage loop

コードの全体が確実に動くか確かめる「テスト」を、意味のあるものだけ少しずつ書き足していくループです。テストが全コードをカバーする状態（100%カバレッジ）に達するまで、追加→確認→また追加を繰り返します。

▶ こんな時に：自社サービスやWebツールの中身が「ちゃんと全部動くか不安」なとき、抜け漏れゼロまで品質を固めたい時に効きます。

✅ やるとこうなる：「ここ動作確認してないけど多分大丈夫」のままだったコードに、意味あるテストが端から端まで貼られて、全コードが自動チェックの網にかかった状態になる。

顧客向けAI導入ループ The customer AI deployment loop

お客さんのAI活用の優先テーマを1つ選び、「検証→段階的な本番投入→監視」という順番で前に進めるループです。担当者・入力データ・成功指標・費用対効果の仮説を最初に決め、本物に近いデータでお試しし、確認できた一番小さな問題から直して、承認された段階を踏んでリリース・監視まで回します。

▶ こんな時に：クライアントから「リード情報の補強」「メール下書き」「会議の要約」などAI業務を頼まれたとき、いきなり全社展開せず安全に導入したい時に効きます。

✅ やるとこうなる：顧客の「このAI業務やりたい」という要望が、本物のデータでの試運転→段階リリース→本番監視まで通り、成果・証拠・顧客への報告・学び・次回見直し日までセットで残る状態になる。

次の一手OK確認ループ The next-action confidence check

「そのタスクが本当に終わったか」という証明と、「次の作業に着手していいか」という許可を、わざと別々に判定するループです。直前のタスクをPASS/DELAY/BLOCK、次の行動をGO/HOLD/BLOCKに分けて判定し、GOでも勝手に着手せず必ず一旦止まって指示を待ちます。

▶ こんな時に：1つの施策が終わるたびに次々と手を広げてしまいがちな人が、「本当に終わった？」「次やっていい？」を一度立ち止まって確認したい時に効きます。

✅ やるとこうなる：「終わったから次いくね」と勢いで進んでいたのが、直前の作業が本当に完了したかと次に動いていいかが別々に判定され、GOでも勝手に動かず一旦止まって指示待ちになる状態が手に入る。

ループ棚卸し監査ループ The loop-auditor loop

手持ちのループ（仕組み）を一つひとつ点検し、それぞれに証拠付きで「継続・方向転換・引退・廃止・証拠不足」のどれか1つの判定を付けるループです。目的・成功基準・予算・記録を調べ、測定型は成績を生データから計算し直して直近と過去を比べます。ループ自体は動かさず推奨するだけです。

▶ こんな時に：自動化や仕組みをたくさん作ったものの「どれが本当に効いていてどれが惰性で残っているか」を、証拠ベースで仕分けして整理したい時に効きます。

✅ やるとこうなる：増えていくループが「これ意味あるの？」と曖昧なまま放置されず、一つ残らず継続・方向転換・引退・廃止・証拠不足のどれかに、計算式と根拠つきで判定され、廃止候補まで一覧で出てくる状態になる。

5人の購入者ヒアリングループ The talk-to-five-buyers loop

実際に買ってくれたお客さんへ繰り返しヒアリングし、その「生の言葉」でランディングページや購入ページのコピーを練り直すループです。5人ずつ・最大15人に「買うのを、あと少しで何が止めましたか？」だけを聞いて本人の言葉を記録し、その不安が湧きやすいページ箇所のコピー案を作り、次の5人で不安が消えたか確認します。

▶ こんな時に：商品の購入ページやLPの成約率が伸び悩んでいるとき、お客さんの「買うのをためらった本音」をそのまま反映した刺さるコピーにしたい時に効きます。

✅ やるとこうなる：買った人を5人ずつ最大15人「買う直前、何で止まりかけた？」と聞き、出た不安をその場所のコピーに反映するのを繰り返し、最終的に匿名のお客様の生の声でランディングページの修正案が手に入る状態になる。

週1投稿テストループ The one-post-a-week loop

毎週1つだけ投稿の型を試し、「意味のある反応」で勝てる型が見つかるまで6週間かけて検証するループです。毎週、対象の本当の悩みについて短い投稿を1本書き、中身のある返信・保存・質問を記録（いいねは参考扱い）。前回の一番強い反応をもとに「冒頭・形式・例・呼びかけ」のどれか1要素だけを毎週変えます。

▶ こんな時に：SNS発信で「どんな投稿が刺さるか分からない」とき、毎週1要素ずつ変えて反応を測り、自分の再現できる勝ちパターンを見つけたい時に効きます。

✅ やるとこうなる：週1投稿を6週間、毎回1要素だけ変えて返信・保存・質問で計測し、最後に「これは効く」という勝ちパターン（か、勝者なしの結論）と全投稿の実測データが手元に残る状態になる。

LaTeX文書作成ループ The LaTeX document creation loop

指定の出典・前提・データだけを根拠に、出典までたどれるLaTeX形式の文書を作り、決められた構造チェックを全部通るまで組版し直すループです。要約・序論・方法・結果・考察・結論・参考文献の7セクションを入れ、すべての主張を式・引用・データ・前提のどれかに紐づけ、エラーゼロになるまで最大5回直します。

▶ こんな時に：研究レポートや学術風の文書を、出典をきちんとたどれる形で体裁崩れなくきっちり仕上げたい時に効きます（技術寄り）。

✅ やるとこうなる：思いつきの主張が混ざりがちな論文ドラフトが、全主張を数式・引用・データに紐づけ、7セクション揃い・図表は本文で先に参照され・エラーゼロまで仕上がった、出典まで追えるLaTeX文書として手に入る状態になる。

ループハーネス検証ループ The Loop Harness verification loop

スケジュールで自動実行するエージェントの作業を、独立した別チェックに合格してから初めて世に出すループです。1つのAIセッションが修正案や送信メッセージを準備し、もう1つのAIセッションが明確な基準で検証。合格した時だけ送り出し、ダメなら気づいた点を残して上限回数だけ再挑戦します。

▶ こんな時に：CIの仕分けや依存ライブラリの更新、ドキュメントの同期など、定期的に回したい作業を「人のチェックなしで勝手に世に出てしまう」のが怖い時に効きます。

✅ やるとこうなる：夜中に自動で動かしたリポジトリ作業が、別の目で検証OKを取った分だけ静かに届いている——通らなかったものは記録を残して勝手に止まる、当たり外れのない夜が手に入る状態になる。

ボーイング747ベンチマークループ The Boeing 747 benchmark

Three.js（ブラウザで3Dを描く技術）の基本パーツだけで、できる限りリアルなボーイング747を作って磨き続けるループです。お手本画像・採点基準・合格ライン・予算を決め、毎回9つの決まった角度で撮って採点。批評役が一番弱い部分を指摘し、他を悪くしないようそこだけ直します。

✅ やるとこうなる：最初はガタガタだった3Dのジャンボ機が、毎回9アングルで採点しては一番弱い箇所だけ直すのを繰り返して、合格ラインに届いた『一番出来のいい1機』として手元に残る状態になる。

まっさらクローン・導入確認ループ The fresh-clone loop

リポジトリ（ソフト一式）を毎回まっさらな使い捨て環境に持ってきて、READMEの手順だけを頼りに「動く状態」までたどり着けるか試すループです。途中で手順が失敗したり書かれていない前提が必要になったら、その抜けを記録して直し、環境を捨ててまた一からやり直します。

✅ やるとこうなる：READMEだけを頼りに毎回まっさらな環境から立ち上げ直し、最後は一度も詰まらずアプリが起動する状態に到達——『うちのPCだから動いた』隠れ前提が消えた手順書が手に入る状態になる。

ゴール・フォージ（目標設計）ループ The Goal Forge loop

ざっくりした開発アイデアを、AI（Codex）が長時間作業を始める前に「測れる計画書」へ仕上げるループです。質問しながら、何を作り何を作らないか・完了の判定基準をまとめた仕様書と、計画・進捗・承認の境界を書いた目標書の2つを書きます。準備不足なら止まり、承認なしに実装へ進みません。

▶ こんな時に：「やりたいことはあるけど指示が曖昧なままAIに丸投げして暴走されるのが不安」という時に、走り出す前に要件と完了条件を固められます。

✅ やるとこうなる：ふわっとした『こんなの作りたい』が、AIが長時間走り出す前に仕様書と目標書の2枚に固まる——決め事や許可が足りなければ『まだ着手不可』と止まるので、見切り発車での実装が起きない状態になる。

初回読み込み軽量化ループ The cold-load trimmer loop

Webアプリが最初の画面を表示する前にダウンロードするデータ量を、見た目も動きも変えずに減らすループです。テスト合格・画面・実際に転送されたバイト数を記録し、1項目ずつ後回し・圧縮・削除しては作り直し、画面が1ピクセルも変わらずバイト数が減った時だけ採用します。

▶ こんな時に：「サイトやアプリの初回表示が遅い」のを、デザインや機能を一切変えずに速くしたい時に効きます。

✅ やるとこうなる：最初の画面が出るまでに裏で読み込む重いデータが、見た目もテストも一切変えないまま1つずつ削られて——表示は1ピクセルも変わらないのに転送量だけ確実に減った状態が手に入る。

初回ユーザー体験改善ループ The easy onboarding loop

ログイン情報も履歴も残っていないまっさらな状態から「初めて使う人」になりきり、画面に見える案内だけを頼りに登録・利用開始を試すループです。つまずいた点を記録し、一番ひどい障害だけを要件を守ったまま最小の変更で直し、そのたびにセッションを捨てて再挑戦します。

▶ こんな時に：「新規のお客さんが登録や使い始めで離脱していないか」を、自分の慣れを排除して本物の初見目線でチェックしたい時に効きます。

✅ やるとこうなる：毎回ログイン情報ゼロの新規ユーザーになりきって最初の入口から触り直し、一番つまずく箇所を最小修正で潰すのを繰り返して——一度も引っかからず登録を終えられる導線が残る状態になる。

設計を壊さないリファクタリングループ The architecture-preserving code refactor loop

コードを測れる目標へ向けて整理し直す作業を、影響範囲を地図にして公開仕様を守りながら最大5周で進めるループです。今の動きと依存先を記録し、外向きの仕様を変えずに一度に1つだけ手を入れ、同じテスト・型・lintを回して、不具合が出ない改善だけを残します。

✅ やるとこうなる：外向きの仕様は一切変えず、テストとチェックを毎回通る改善だけを最大5巡で積み上げて——元の動きを保ったまま中身が目標値まで整い、何を直し何を諦めたかの記録まで残る状態になる。

うるさい警報は調整すればいい。でも、警報そのものを切った車には、乗りたくない。

ループを作れ。ただし、ボタンを押すだけの人ではなく、エンジニアであり続けるつもりの人として作れ。（Addy Osmani「Loop Engineering」より）