🔁 ループエンジニアリング — 2030年、アジャイルのループは閉じるのか

1/6　🔁 ループエンジニアリング — 2030年、アジャイルのループは閉

# 🔁 ループエンジニアリング — 2030年、アジャイルのループは閉じるのか
AIエージェントが開発から監視までを自分で回す「ループエンジニアリング」という言葉が2026年6月に生まれた。言い出したのはClaude Codeを作ったBoris Chernyと、OpenClawを作ったPeter Steinbergerで、Andrew Ngが3つのループとして整理した。私（さとまた）の主張は、その3つ目——人間がログとヒートマップを見てアジャイルを回していた工程さえ、2030年にはAIが閉じるというものだ。この記事はその主張を、Claudeと Codex がそれぞれ独立に検証し、11の論点ごとに「事実としてどうなるか」を判定したものである。2人の見解は3つ目のループで割れた。

## ⚖️ 11の論点と、事実としてどうなったか
このセクションの3点
① 11論点のうち、そのまま支持されたのは4つ
② 6つは半分支持。1つは支持されなかった
③ 争点は3つ目のループ。ClaudeとCodexで意見が割れた

この表がこの記事の答えです。さとまたの主張を11の論点に分け、それぞれについて「事実としてどうなるか」を判定しました。
判定は私（Claude）ひとりで出したものではありません。同じ資料を OpenAI の Codex に独立に読ませ、その見解も並べたうえで、両者が一致したところ・割れたところを分けて書いています。割れた論点は、揃えずに割れたまま出します。

各判定には「確信度」と「これが覆る条件」を付けました。確信度が低いものを高く見せることはしていません。判定できないものは判定できないと書きます。最初は1件を判定不能としていましたが、依頼者から「それは論点の立て方が違う」と指摘を受けて当て直した結果、判定不能は0件になりました（経緯は第4章と第16章）。

4
そのまま支持された論点

6
半分だけ支持された論点

1
支持されなかった論点

0
判定不能だった論点

# | 論点 | 事実としてどうなるか | 確信度

1 | React登場以前は MVC（サーバー描画）が主流だった | 支持される。W3Techsの実測で2015年時点の PHP は全サイトの80.6%、ASP.NET は16.7%。2026年にはPHP 70.3%、ASP.NET 4.2%まで落ちている。さらにNetlify 共同創業者 Mathias Biilmann 本人が自社ブログで「業界は WordPress / Drupal / Spring / Rails から React / Vue / Gatsby / Next / Nuxt / Astro へ移った」と書いている（Jamstackという語を作った本人の証言） | 高
2 | 2020年ごろから Next.js と JAMstack がメインになった | 半分支持される。時期と方向は合っているが、1段階ではなく2段階だった。①2015〜2022年はMVC → JAMstack（Reactのサイト普及率が 2019年4.6% → 2021年8%、Netlify のローンチが2015-03-31、AWS Lambda のGAが2015-04-09）。②2022年以降は JAMstack を経由して Next.js のハイブリッド型へ再収斂（JAMstackの代表 Gatsby は2022年をピークに約35%減、一方 Next.js は SSR・ISR・Server Components を取り込んで狭義のJAMstackから離れながら伸び続けている） | 中
3 | ループエンジニアリングという概念は実在する | 支持される。ただし2026年6月に生まれた新語で、まだ2か月半しか経っていない。技術的原型は2025年7月14日の Geoffrey Huntley「Ralph Wiggum」、広めたのは Boris Cherny（2026-06-02）と Peter Steinberger（2026-06-07）、方法論に整えたのは Addy Osmani、体系化したのは IBM（2026-07-17） | 高
4 | 実装とテストはAIが回すようになる | 支持される。すでに起きている。Andrew Ng は「仕様を渡せばエージェントがコードを書き、テストし、バグが無くなるまで反復する」と書き、自分の例では約1時間無介入で働いたとしている。GitHub Copilot Autofix のコア機能はGA | 高
5 | デプロイとインフラ運用はAIが回すようになる | 半分支持される。自動化する製品は実在するが、人間の承認ゲートが制度として残されている。Vercel Agent は Public Beta で既定が read-only。AWS の AI-DLC は作業サイクルごとに人間の検証・承認を明記している | 中
6 | 監視と障害対応はAIが回すようになる | 半分支持される。Azure SRE Agent と AWS DevOps Agent が「closed-loop」を掲げて実在する。ただし対象がインシデント対応に限定されており、開発ライフサイクル全体ではない | 中
7 | ログとヒートマップの分析はAIがやる | 支持される。これはデータ処理であって価値判断ではないから。ただし今回調べた開発者向け製品群の中には専用製品が見つからなかった。「無い」ではなく「今回見た範囲では見つからなかった」（プロダクト分析・実験基盤の市場は調べていない） | 中
8 | 仮説立案をAIがやる | 半分支持される。既存の指標を改善する仮説は自動化できる。しかしいまの指標そのものを捨てる仮説は、目的関数の外から来るので出てこない | 中
9 | A/Bテストの実施と判定をAIがやる | 半分支持される。配信と統計判定は自動化できる。ただし誰を対象に実験してよいかという承認は残る（倫理・対象者・長期影響）。多重検定・早期停止・季節性・施策同士の干渉という統計上の罠もある | 中
10 | アジャイルのループ全体が2030年に閉じる | 半分支持される。ここが最大の争点で、ClaudeとCodexの見解が割れた。私（Claude）は「計測と仮説は閉じ、決定と責任が残る＝半分閉じる」と見た。Codex は「周回数では9割が自動、意思決定の重要度では半分以下が自動」とし、私が「読めるから閉じる」と言った行動データについて「読めることと正しく判断できることは別」と反論した。私はこの反論を受け入れる（第11章） | 低
11 | 人間が要らなくなる | 支持されない。残るのは能力の問題ではなく権限と責任の問題だから。出荷物の責任は人間にある（IBM）。目的関数を決めること、不可逆な変更を承認すること、失敗したときに説明し補償することは、AIが賢くなっても自動的には移らない。組織が明示的に委任して初めて移る | 高

### 12の工程は、4つの時点で誰がやっているか
工程 | 2015 | 2020 | 2026（実機能で確認） | 2030（判定）

要件定義 | 人 | 人 | 人（AIは草案を書ける） | 人。誰の問題を優先し、何を作らないかは資源配分の決定
設計 | 人 | 人 | 人＋道具 | AI（人が承認）。ただし不可逆な移行・規制・データ境界は人
実装 | 人 | 人 | AI（人が承認） | AI（原則無人）
コードレビュー | 人 | 人 | AI（人が承認）Vercel Agent は Public Beta・既定 read-only | AI（原則無人）。人はポリシーを見る
テスト | 人＋道具 | 人＋道具 | AI（人が承認） | AI（原則無人）
CI・デプロイ | 人＋道具 | 道具（自動化済み） | 道具＋AI | AI（段階展開・自動ロールバック）
インフラ運用 | 人（サーバーを立てる仕事があった。2015年はPHPが全サイトの80.6%） | 道具（マネージド化） | 道具＋AI | AI（可逆な変更は無人・破壊的変更は二者承認）
監視・障害対応 | 人 | 人＋道具 | AI（対象限定・人が承認） | AI（既知の障害は無人）
ログ・ヒートマップ分析 | 人 | 人 | 人（今回の範囲では専用製品を確認できず） | AI（無人）
仮説立案 | 人 | 人 | 人 | AI（既存指標の改善のみ）／人（指標そのものの変更）
A-Bテスト | 人 | 人＋道具 | 人＋道具 | AI（実行と判定）／人（実験の承認）
次の開発への反映 | 人 | 人 | 人 | AI（小さな勝者の展開）／人（ロードマップ・価格・ブランド）

この表から読める、いちばん大事なこと
2015年の列に「人」が10個、2030年の列に「人」が2個あります（要件定義と、指標そのものを変える判断）。15年で8つの工程が人の手から離れる、というのがこの記事の判定です。

ただし、残る2つはいちばん小さくて、いちばん重い工程です。回数でいえば全体の1%も無い。しかし「何を作るか」と「何を成功と呼ぶか」を決めているのはこの2つで、残り10工程はすべてその決定に従って回っているだけです。

だから「AIが全部やる」と「人間が要らなくなる」は同じ話ではありません。回す仕事は消え、決める仕事だけが残る。そして決める仕事は、いまのところ人数を必要としません。ここが、この記事でいちばん冷たい結論です。

→ 次のSection 2では、判定の対象になったさとまたの主張を、原文のまま置く。

## 🗣️ さとまたの主張（原文のまま）
このセクションの3点
① 主張は3つの命題に分けられる。時代区分・現在地・2030年
② 3つ目だけが予測で、前の2つは事実の確認である
③ この記事は3つを別々に判定する

この記事が検証しているのは、次の主張です。要約せず、原文のまま置きます。言い換えた時点で、検証しているものが変わってしまうからです。

さとまた
AIエージェントを利用したすべてが自動で動くループエンジニアリングが迫ってきています。
まずこれはシステム開発の未来の話です。2015年まではDjangoやruby on rails、EC2のAWSがメインでしたが、2020年くらいからnextjsとのJAMSTACKがメインになり、JAMSTACKを開発から監視ログまですべてAIが回してシステムを回していく。
また人間がログやヒートマップでシステムのユーザーを分析してアジャイル開発をしていたのでさえ、AIですべてが自動で回る未来が2030年にくる。

### この主張は、性質の違う3つの命題でできている
命題 | 内容 | 性質 | 何で検証できるか

① 時代区分 | 2015年まで Rails / Django / EC2 → 2020年ごろから Next.js / JAMstack | 過去の事実 | ダウンロード数・開発者調査。数字が残っているので白黒がつく
② 現在地 | いま、開発から監視ログまでをAIが回し始めている | 現在の事実 | 製品の公式ドキュメント。実在するかどうかと、提供状況（GA / Beta / Preview）で確かめられる
③ 2030年 | ログとヒートマップを見て仮説を立てるという人間の工程さえ、AIが全部回す | 予測 | 検証できない。できるのは「どういう条件が揃えばそうなるか」「何が起きたら外れたと分かるか」を書くことだけ

この3つを混ぜないことが、この記事のルール
①と②は調べれば決着がつくので、調べました。結果、①は半分しか支持されず（JAMstackではなくNext.jsが伸びた）、2015年の部分はそもそも検証できませんでした（年別ダウンロードを返すAPIが無い）。②はおおむね支持されましたが、製品はほぼすべて「人間の承認ゲート」を残しています。

③は予測なので、正しいとも間違っているとも言えません。この記事にできるのは、③が成り立つ条件を分解して、いまどこまで揃っているかを数えることだけです。第11章から第14章がそれをやります。

そして依頼者の言葉を借りれば、これは「会社の方針にして方向性を決定していく」ための材料です。予測が当たるかどうかより、外れたときに何が起きるかを織り込んで決められるかのほうが重要です。だから第13章に「外れる条件」、第15章に「では何を決めるか」を置きました。

この主張は3段でできている。判定の仕方がそれぞれ違う
① 過去
時代区分
2015年 Rails/Django/EC2 → 2020年 Next.js/JAMstack。数字が残っているので白黒がつく。第4章と第5章で判定した

▶
② 現在
2026年の現在地
開発から監視までをAIが回し始めている。製品が実在するかと、提供状況で確かめられる。第9章で判定した

▶
③ 未来
2030年の予測
アジャイルのループごとAIが閉じる。検証できない。できるのは条件の分解と、外れる条件を書くことだけ。第11章から第14章

→ 次のSection 3では、この先に出てくる言葉を先に片付ける。

## 📖 この記事に出てくる言葉
このセクションの3点
① この記事では14語だけを使う。それ以外の専門用語は本文中で説明してから使う
② 専門用語で専門用語は説明しない。高校生が読んで意味が取れる言葉に置き換える
③ 意味を忘れたらこの章に戻る。全章を通してこの14語の定義は変わらない

このあと4章から先で、Rails・Django・JAMstack・エージェント・ループといった言葉が繰り返し出てくる。先に14語だけ定義しておく。専門用語の定義に別の専門用語を使わないことを徹底しているので、この章だけ読んでも意味が取れるはずだ。
用語 | 意味（高校生向け） | この記事での役割

JAMstack | JavaScript・API・Markup（あらかじめ組み立てた静的なページ）の略。2015年にNetlifyの創業者が名付けた作り方の名前。アクセスされるたびにサーバー側でページを組み立てず、あらかじめ作っておいた静的ファイルと、データを取ってくるAPIを組み合わせて配信する。 | 2020年ごろの時代区分の主役として、4〜5章で数字を使って検証する
SSG・SSR | SSG（Static Site Generation）は、サイトを公開する前にあらかじめ全ページをHTMLとして作っておく方式。SSR（Server-Side Rendering）は、ユーザーがアクセスするたびにサーバー側でHTMLをその場で組み立てて返す方式。 | Next.jsは両方を使い分けられる。この違いがJAMstackの定義とズレていく理由になる
エッジ | ユーザーの住んでいる場所の近くにある小さなサーバー拠点で処理をすること。本社にある大きなサーバー1か所に全世界からアクセスを集める代わりに、世界中の拠点に処理を分散する。 | 2020年代のインフラ運用（9章）の主役
オブザーバビリティ | システムの中で今何が起きているかを、ログ・メトリクス（数値の記録）・トレース（処理の流れの記録）の3種類から把握できる状態のこと。日本語では「可観測性」。 | AIが監視・障害対応を担うための土台（9・12章）
ヒートマップ | ユーザーがWebページのどこをクリックしたか、どこまでスクロールして読んだかを、色の濃淡で地図のように可視化した図。 | 依頼者が「人間がやっていた」と主張する分析作業そのもの（10章）
A/Bテスト | 同じページの2パターン以上をユーザーにランダムに見せて、どちらの成果（購入・登録など）が良いか統計的に比べる実験手法。 | 依頼者の主張の核心。この実施と判定をAIがやるかどうかが11章の争点
エージェント | 人間が作業を1つずつ指示しなくても、与えられた目標に向けて自分で考え、道具（ファイル操作やコマンド実行）を使い、行動するAIプログラムのこと。 | この記事全体の主役
ループ | 「観察する→判断する→行動する→また観察する」を繰り返す1周のことを指す。この繰り返しの設計を「ループエンジニアリング」と呼ぶ。 | 記事タイトルそのものの言葉（6・7章）
ハーネス | エージェントという「頭脳」を、実際にファイルを触ったりコマンドを実行したりする「体」につなぐ土台のプログラムのこと。Claude CodeやCodexがこれにあたる。 | 7章の8部品の1つ
evals | AIが出した答えや変更が「前より良くなったか」を人間の代わりに自動で採点する評価テストの仕組み。 | 12章の「検証」を支える技術用語
MCP | Model Context Protocolの略。AIエージェントが外部のデータやツール（社内データベース・検索エンジン・他のシステムなど）に接続するための共通の規格。 | 7章の8部品の1つ
worktree | 1つのGitリポジトリから、複数の作業用フォルダを同時に作れる仕組み。複数のエージェントが同じコードを別々の場所で同時に触れる。 | 7章の8部品の1つ。さとまたのハブ環境にすでに存在する
cron | 決まった時刻・決まった間隔でプログラムを自動実行させる仕組み。もともと1970年代からあるUnixの機能で、AIエージェントを定期的に起こす仕組みとしても転用されている。 | 7章の8部品の1つ。「スケジュール実行」の正体
feature flag | 新しい機能をコードには入れたまま、オン・オフをスイッチのように切り替えられる仕組み。一部のユーザーだけに見せる、問題が起きたら即座に元に戻す、といった制御に使う | 11・12章のA/Bテスト・段階展開の実装手段

ループとは何か（一巡の流れ）
1
観察する
ログ・ヒートマップ・エラーを見る

▶
2
判断する
何を変えるかを決める

▶
3
行動する
コードを変更し、デプロイする

▶
4
また観察する
結果を観察し、次の1周が始まる

→ 次のSection 4では「2015年 — Rails・Django・EC2の時代」を、実際に取得できた数字と取得できなかった数字の両方で検証する。

2/6　🏗️ React登場以前 — サーバーがHTMLを組み立てていた時

## 🏗️ React登場以前 — サーバーがHTMLを組み立てていた時代
このセクションの3点
① 前回は「Rails/Djangoがダウンロード数1位だったか」という間違った当て先で調査し、判定不能になっていた
② さとまた本人の訂正で当て先を「アーキテクチャの主流交代（MVC → JAMstack）」に直すと、判定は変わる。W3Techsの実測でPHP80.6%・ASP.NET16.7%（2015年）という圧倒的な構成が確認できた
③ Netlify創業者Mathias Biilmann本人が「業界はWordPress・Drupal・Spring・Railsから離れた」と自分のブログで証言している。この一次証言が判定を後押しする

さとまた
2015年まではDjangoやRuby on Rails、EC2のAWSがメインだった。これはフレームワークの人気順位の話をしているのではない。reactが登場して浸透する前まではMVCモデルが主流だったのが、JAMSTACKに変わったという話をしています。

📎 Claudeの指摘
前回のこの章は、この主張を「Rails・Djangoがダウンロード数で1位だったか」という当て先で検証し、RubyGems・PyPIの年別データが取れないという理由で「判定不能」としていた。だがさとまた本人の訂正を受けて読み直すと、主張しているのは特定フレームワークの順位ではなく、もっと大きな単位＝「サーバー側でHTMLを組み立てて返す」というアーキテクチャ（MVC型）から、「クライアント側で描画し、APIと静的配信を組み合わせる」というアーキテクチャ（JAMstack）への交代である。当て先を直すと、実は数字が取れる。
W3Techsのサーバーサイド言語シェア（PHP・ASP.NET・Ruby・Python・Node.jsのサーバー実行）を代理指標として使うと、2015年1月時点でPHPが全サイトの80.6%、ASP.NETが16.7%を占めていた。この2つを合わせるだけで、稼働していたサイトの過半が「サーバー側でHTMLを組み立てて返す」ランタイムの上に乗っていたことになる。Reactが実測できる最も古い時点（2018年1月・W3Techs）でもReactはわずか0.7%であり、React登場前夜（2013年）にはこの数字はさらに小さかったはずだ。
もう一つ、数字より強い証拠がある。Jamstackという語を作った本人、Netlify共同創業者のMathias Biilmann氏が、自社ブログ「10 Years of Netlify」で当時の状況を「アーキテクチャはPHP+LAMP、Ruby、Java、.Netといったサーバーサイド言語で決まっていた」と直接書いている。そのうえで「業界はWordPress、Drupal、Spring、Ruby on Railsから、React、Vue、Gatsby、Next、Nuxt、Astroへと離れていった」とも述べている。提唱者本人が「MVC → JAMstack」という構図をそのまま証言しているのは、この記事にとって一次資料としてかなり強い。
限界も書く。W3TechsにはRails・Django単体の時系列が無いため、ここではサーバー言語のシェアを代理指標として使っている。PHP・ASP.NETの合計とRails（Ruby）・Djangoの実態は完全には一致しない。実際Ruby（Railsの土台）は2015年の0.9%から2026年には7.0%へむしろ微増しており、「MVC系が丸ごと消えた」わけではない点は6章末までの判定に留保として残す。

🤖 Codexの指摘
時代区分そのものへの私の立場は変わらない。「2010年代のサーバー中心のフルスタックフレームワークから、2020年代のReact中心・ハイブリッドレンダリング・マネージド基盤へ」という言い換えのほうが、私は正確だと考えている。今回追加されたPHP・ASP.NETの下落データは、この言い換えの前半（サーバー中心のMVC全盛期があったこと）を裏付ける材料として妥当だ。
ただし2点、慎重さを崩さない。第一に、PHP・ASP.NETという「言語」のシェアを、Rails・Djangoという「フレームワーク」の代替として使うのは、階層の異なるものを重ねる操作であり、Claudeもその限界を認めている通り注意が要る。第二に、Netlify創業者本人の証言は一次情報として価値が高い一方、自社が置き換えた側の旧世代を要約する立場にある人物の発言である点は割り引いて読むべきだ。JAMstackを商業化した本人が「業界は旧来のMVCから離れた」と語ることには、自社の存在意義を裏付けたいという動機が原理的に混入し得る。単一の関係者証言だけで「圧倒的に主流だった」と断定するのは、独立した第三者の統計と併せて初めて安全になる。今回はW3Techsという独立した統計が裏にあるため、私はこの章の判定には同意する。

✅ 事実としてどうなるか判定：支持される。「React登場前まではサーバー側でHTMLを組み立てるMVC型のアーキテクチャが主流だった」という主張は、当て先を正しく直した結果、数字と一次証言の両方で裏付けられた。
根拠：W3Techsのサーバーサイド言語シェア（2026-08-16取得）で、2015年1月時点にPHP 80.6%・ASP.NET 16.7%（合計で稼働サイトの過半）。Reactが実測できる最も古い時点である2018年1月時点でもReactはわずか0.7%（W3Techs）。加えてNetlify共同創業者Mathias Biilmann氏が自身のブログ「10 Years of Netlify」で「アーキテクチャはPHP+LAMP、Ruby、Java、.Netといったサーバーサイド言語で決まっていた」「業界はWordPress・Drupal・Spring・Ruby on Railsから離れた」と直接証言している。
確信度：高。独立した統計（W3Techs）と当事者の一次証言（Netlify創業者）の2種類が同じ方向を向いている点で、これまでのこの記事の中では確信度が高い部類に入る。ただし代理指標（サーバー言語シェア）を使っている点、Ruby自体はむしろ微増している点は留保として残す。
これが覆る条件：RubyGems・PyPIの年別ダウンロード数（BigQuery公開データセット等の直接集計）でRails・Djangoが2015年時点で実は少数派だったと判明すれば、この判定は見直しが必要になる。現時点ではその一次データに到達できていない。

80.6%
PHP（2015年1月・W3Techs）

16.7%
ASP.NET（2015年1月・W3Techs）

0.7%
React（2018年1月・W3Techs実測で最も古い時点）

4.2%
ASP.NET（2026年・約4分の1に縮小）

### 当て先を直すとどうなったか
当て先 | 検証できたか | 判定

Rails/Djangoがダウンロード数で1位だったか（前回の当て先） | 年別データが取得不可（RubyGems・PyPIとも） | 判定不能
サーバー側MVC型アーキテクチャ全体が主流だったか（今回の当て先） | W3Techsのサーバー言語シェア＋Netlify創業者本人の証言で確認できた | 支持される

### サーバーサイド言語シェアの実測（W3Techs・代理指標）
言語 | 2015年1月 | 2018年1月 | 2022年1月 | 2026年8月16日

PHP | 80.6% | 80.2% | 78.1% | 70.3%
ASP.NET | 16.7% | 13.5% | 8.0% | 4.2%
Ruby | 0.9% | 1.6% | 6.0% | 7.0%
Python | 1.6% | 1.3% | 1.4% | 1.2%
サーバー側で動くJavaScript（Node.js等） | 0.1% | 0.4% | 1.8% | 7.2%

PHP・ASP.NETという典型的なサーバーMVCの土台は一貫して減少している。特にASP.NETは2015年16.7%から2026年4.2%へ約4分の1に縮小した。一方でRuby（Railsの土台）はむしろ横ばい〜微増であり、「MVC系がすべて消えた」わけではない。むしろ「サーバー側で動くJavaScript」が2015年0.1%から2026年7.2%へ急伸しており、サーバー側の実行言語自体がJavaScriptに置き換わりながらSSR（サーバー側描画）という旧MVC的な責務を引き継いでいる、という複雑な実態がある。これは5章のNext.jsハイブリッド型の話につながる。

### Netlify創業者本人の証言（一次情報）
📄 Mathias Biilmann（Netlify共同創業者）「10 Years of Netlify」より
「アーキテクチャはPHP+LAMP、Ruby、Java、.Netといったサーバーサイド言語で決まっていた」
「業界はWordPress、Drupal、Spring、Ruby on Railsから、React、Vue、Gatsby、Next、Nuxt、Astroへと徐々に離れていった」
出典: biilmann.blog「10 Years of Netlify」（2025-03-31付。Jamstackという語の命名者本人によるブログ）

### 消えた仕事を数える（1） — MVC時代の開発者は何をしていたか
「サーバー側でWebアプリを作る」という仕事に、具体的にどんな工程が含まれていたかを、9章で見る2026年の自動化製品と比べるための基準線としてここに残す。
工程 | 当時、人間が具体的にやっていたこと | 9章での対応関係

サーバーを立てる | EC2インスタンスの種類（CPU・メモリ）を選び、OSを入れ、Rails/DjangoのランタイムとDBを手動でセットアップし、SSHで入って設定ファイルを書く | Vercel・Cloudflareのようなマネージド基盤が「サーバーという概念」自体を隠す方向に進んだ（9章）
デプロイ手順 | Capistrano（Rails）やFabric（Python）のようなツールでSSH経由のデプロイスクリプトを書き、手動またはCIでサーバーへコードを転送・再起動する | GitHub Actions・Cloudflare Workers Builds・Vercelのgit連携push-to-deployに置き換わった（9章）
スケール設計 | アクセスが増えたら、EC2インスタンスを何台に増やすか、ロードバランサーをどう置くか、DBをどう分散するかを人間が事前に設計する | Durable Objects・Workflowsのような自動スケールするマネージドインフラが工程自体を吸収した（9章）

→ 次のSection 5では、React登場からの移行が実は2段階だったことを、npmの実測数字で確認する。

## 📈 2段階だった — JAMstackへ、そしてハイブリッドへ
このセクションの3点
① React普及率（HTTP Archive Web Almanac）は2019年4.6%→2021年8%→2024年10%。伸びは2022年以降はっきり鈍化している
② 移行は1段階ではなく2段階だった。第1段階（2015〜2022年）はMVCからJAMstackへ。第2段階（2022年〜）はJAMstackからNext.jsのハイブリッド型への再収斂
③ Gatsbyは2022年の2,376万9,671件をピークに2025年は1,533万4,350件まで約35%減。一方Next.jsは伸び続け、SSR・ISR・Server Componentsを取り込んで狭義JAMstackから離れた

さとまた
2020年くらいからNext.jsとのJAMstackがメインになった。JAMstackを開発から監視ログまですべてAIが回してシステムを回していく。

📎 Claudeの指摘
「2020年ごろから」という時期感覚は、npmの実測値の変曲点とよく一致する。next（Next.js）の年次ダウンロード数は2020年の3,335万85件から2021年の8,085万8,342件へ約2.4倍に急伸している。ここまではさとまたの体感と数字が一致する。
だが実測を年表として並べ直すと、単純な「MVCからJAMstackへ変わった」の1段階では説明できないことが分かった。移行は2段階だった。
第1段階（2015〜2022年ごろ）＝MVCからJAMstackへ。Reactのサイト普及率（HTTP Archive Web Almanac、モバイルページ基準）は2019年4.6%（デスクトップ）→2021年8%→2022年8%（横ばい）→2024年10%と伸びている。この期間、JAMstackの象徴だったGatsbyのダウンロード数も2019年の1,300万7,249件から2022年の2,376万9,671件まで一貫して増加した。
第2段階（2022年〜）＝JAMstackからNext.jsのハイブリッド型へ。ところがGatsbyは2022年をピークに反転し、2025年には1,533万4,350件まで約35%減った。一方でNext.jsは減速せず伸び続け、2025年には6億2,060万5,398件（2016年比で約6,127倍）に達している。この差を生んだのは、Next.jsがSSR・ISR・Server Componentsを取り込み、「あらかじめ静的ファイルを作ってAPIと組み合わせる」という狭い意味のJAMstackの定義から離れていったためだ。W3TechsのNext.js市場シェアも2026年1月の2.6%から2026年8月には4.2%へ、7ヶ月で+1.6ptという直近の急伸を見せている。
つまり「JAMstackに変わった」は2015〜2022年の局面としては正確だが、現在形で言い切ると2022年以降のNext.js的ハイブリッド型への再収斂を取りこぼす。これが今回、判定を「支持される」ではなく「半分支持される」とした理由である。

🤖 Codexの指摘
私はここではClaudeより少し強く評価してよいと考えている。nextの年次npmダウンロードが2016年の101,294から2025年の620,605,398へ約6,127倍になり、特に2020年から2021年へ約2.4倍になった事実は強い。State of JS 2024でも職場利用5,147件で、比較対象のメタフレームワーク（Nuxt・Astro・SvelteKit・Remix・Gatsby）を大きく上回る。メタフレームワークという限定された市場で見れば、Next.jsを「メイン」と呼ぶ日常語上の妥当性はある。
ただし、npmダウンロード数は利用者数でも新規案件数でもない。CI、キャッシュ、依存関係としての反復取得を含む生の値であり、「6,127倍」を「採用が6,127倍」とは読めない。
Claudeの「JAMstackが主流になった、は不正確」には同意する。Gatsbyが2022年をピークに2025年まで35%減ったことはその修正を促す材料になるが、Gatsby一製品の衰退だけでJAMstack全体の非主流化を証明することもできない。より本質的なのは、Next.jsがSSGだけでなくSSR、ISR、Server Componentsを取り込み、静的ファイル＋APIという狭義JAMstackから離れたことだ。だから私なら時代区分を、「2010年代のサーバー中心のフルスタックから、2020年代のReact中心・ハイブリッドレンダリング・マネージド基盤へ」と書く。JAMstackはその移行期を表した有力な看板であって、2020年代全体の勝者ではない。

✅ 事実としてどうなるか判定：半分支持される。時期と方向は合っているが、1段階ではなく2段階だった——「2013年のReact登場を境に、2015〜2022年ごろMVCからJAMstackへ移行した。ただし2022年以降は、JAMstackを経由してNext.js的なハイブリッド型へ再収斂している」という2段階の推移が事実に近い。
根拠：Reactサイト普及率（Almanac）2019年4.6%→2021年8%→2024年10%、2022年以降は伸びが鈍化。next年次ダウンロード2020年3,335万85件→2021年8,085万8,342件（約2.4倍）→2025年6億2,060万5,398件。Gatsbyは2022年2,376万9,671件（ピーク）→2025年1,533万4,350件（約35%減）。年表: React npm初回公開2013-05-23／Netlify正式ローンチ2015-03-31／AWS Lambda GA 2015-04-09／Next.js初回リリース2016-10-25／ZEIT → Vercel改称2020-04-21（すべてnpm registry API・公式ブログの一次情報で確認）。
確信度：中。npmダウンロード数は利用者数そのものではない点（Codex指摘）、Reactのサイト普及率の測定手法がAlmanac・W3Techsで一致しない点（曲線の形は同じだが数値は異なる）を割り引く必要がある。「2段階だった」という骨格は複数の独立データが同じ形を示しており、確信度は中に置く。
これが覆る条件：Next.jsのダウンロード数が今後横ばい・減少に転じれば「再収斂」は否定される。逆にAstro・SvelteKit等の狭義JAMstack系が2022年以降に反転増加していれば、「JAMstackからハイブリッドへ」という2段階目の判定は見直しが必要になる。

### 年表 — 一次情報で確認した日付

- 1 2013-05-23

#### React、npmに初めて公開
バージョン0.7.0。npm registry APIのtimeフィールドで実測確認

- 2 2015-03-31

#### Netlify、正式ローンチ
共同創業者Mathias Biilmann氏が私設ベータからShow HN投稿でローンチ。同氏がJamstackという語を命名

- 3 2015-04-09

#### AWS Lambda、一般提供開始
プレビューは2014-11-13から。AWS公式ブログのメタデータで確認

- 4 2016-10-25

#### Next.js、初回リリース
v1.0.0。npm registry APIでvercel/next.jsの初回公開日を実測確認

- 5 2020-04-21

#### ZEITがVercelへ改称
Vercel公式ブログのページメタデータで確認

- 6 2022年

#### 狭義JAMstackのピーク
Gatsby年次ダウンロード2,376万9,671件でピーク。以後反転して減少へ

- 7 2026年

#### Next.jsハイブリッド型の急伸
W3Techs市場シェアが2026年1月2.6%→8月4.2%へ7ヶ月で+1.6pt

### 第1段階の実測 — Reactのサイト普及率（HTTP Archive Web Almanac）
年 | Reactの使用率 | 備考

2019年 | 4.6%（デスクトップ） | MVCパラダイムの古いフレームワークは今も使われているが、Reactが台頭し始めた段階
2021年 | 8%（モバイル） | 前年比で倍増
2022年 | 8%（モバイル） | 前年から横ばい。採用が頭打ちになり始めたシグナル
2024年 | 10%（モバイル・デスクトップとも） | 前年からわずかに増加。伸びの鈍化が続く

### 第2段階の実測 — next と gatsby の明暗（npmダウンロード数）
next 年次ダウンロード数（万件）2016〜2025 2016年

10.1万
実測 101,294件
2017年

97.5万
実測 975,048件
2018年

432.9万
実測 4,329,409件
2019年

1181.7万
実測 11,817,102件
2020年

3335万
実測 33,350,085件
2021年

8085.8万
実測 80,858,342件（前年比約2.4倍）
2022年

14714.5万
実測 147,144,562件
2023年

22853.1万
実測 228,530,968件
2024年

34013.9万
実測 340,138,881件
2025年

62060.5万
実測 620,605,398件（2016年比 約6,127倍）

出典: npm公式API（api.npmjs.org/downloads）2026-08-16取得。CI等の重複取得を含む生の値。単位は万（10,000）件に換算
gatsby 年次ダウンロード数（万件）2019〜2025 2019年

1300.7万
実測 13,007,249件
2020年

1992.9万
実測 19,928,813件
2021年

2123.7万
実測 21,237,496件
2022年

2377万
実測 23,769,671件（ピーク）
2023年

1810.9万
実測 18,108,906件
2024年

1571.7万
実測 15,717,228件
2025年

1533.4万
実測 15,334,350件（ピーク比 約35パーセント減）

出典: npm公式API（api.npmjs.org/downloads）2026-08-16取得。2022年をピークに減少に転じ、狭義JAMstackの後退を示す

### 消えた仕事を数える（2） — 2段階でそれぞれ何に置き換わったか
第1段階（〜2022年）と第2段階（2022年〜）で置き換わったもの
第1段階 — サーバー中心からJAMstackへ

- ・EC2インスタンスの選定・OSセットアップが、Netlify・Vercelへのgit pushに置き換わった

- ・Capistrano・FabricのSSHデプロイが、push-to-deployの自動ビルドに置き換わった

- ・静的サイト＋API（JAMstack）という構成が、動的だったページの多くを置き換えた

第2段階 — JAMstackからNext.jsハイブリッドへ

- ・あらかじめ全ページを静的生成する狭義JAMstackの手法が、ISR（一部を再生成）に置き換わりつつある

- ・ビルド時に確定させていたデータ取得が、Server Componentsによるリクエスト時取得に置き換わった

- ・「サーバー処理をしない」という前提自体が崩れ、Next.jsのAPIルート・SSRが復権した

→ 次のSection 6では「ループエンジニアリング」という言葉を誰が言い出したのかを、時系列で追う。

3/6　🔍 「ループエンジニアリング」は誰が言い出したのか

## 🔍 「ループエンジニアリング」は誰が言い出したのか
このセクションの3点
① 「ループエンジニアリング」は2025年7月の技術的な原型から始まり、2026年6月上旬の1週間で複数人がほぼ独立に言い出し、7月に体系化された
② 提唱者の一人ピーター・スタインバーガーは、わずか6週間後に「Graph Engineering」へ乗り換えたと報じられているが、これは原ポスト未確認の二次情報である
③ ループとグラフは対立する概念ではない。グラフへ移っても、その中からループ自体が消えるわけではない

2025-07-14
Huntleyのbash1行が最初の技術的原型

2026-06-02〜08
Cherny・Steinberger・Osmaniが1週間で相次いで発信

2026-07-17
IBM Thinkが体系化した唯一の一次文書

6週間
Steinbergerが言葉を変えたとされるまでの期間（二次情報）

- 1 2025-07-14

#### Geoffrey Huntley「Ralph Wiggum as a "software engineer"」
個人ブログ ghuntley.com で公開。「ループ」の技術的な原型を最初に体系化した記事。中身はこのbash1行に尽きる。
while true; do cat PROMPT.md | claude-code; done
同じプロンプトファイルをAIコーディングエージェントへ延々と食わせ続けるだけの、最も単純な無限ループである。この記事は2026年2月19日に更新されており、原型としての参照は今も続いている。

- 2 2026-06-02

#### ボリス・チェルニー（Anthropic, Claude Code責任者）が発言
Acquired Unplugged（WorkOS主催、Ben Gilbert & David Rosenthal司会）のステージで「I don't prompt Claude anymore. I have loops running. They're the ones prompting Claude and figuring out what to do. My job is to write loops.」と発言。方法論としての宣言ではなく、自分の働き方が変わったという個人の告白に近い。出典はADTmagがBusiness Insider経由で引用したもので、孫引きである。

- 3 2026-06-07

#### ピーター・スタインバーガー（独立エンジニア、元PSPDFKit創業者）が発言
Chernyとほぼ同時期に、独立して「You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.」と発信。こちらもADTmagの引用（Business Insider経由）であり、原ポスト（X/Twitter）は本調査では直接確認できていない。

- 4 2026-06-07/08

#### アディ・オスマニ（Google）が用語として定式化
Substack「Loop Engineering」（Substack）で、「エージェントへ毎回プロンプトを打つ人」から「エージェントへプロンプトを出し続けるシステムを設計する人」への転換として定式化。ループの定義を「a recursive goal where you define a purpose and the AI iterates until complete」とし、Automations／Worktrees／Skills／Plugins・Connectors／Sub-agentsの5要素（＋外部メモリ）に分解した。O'Reilly Radarが2026年6月22日に転載している。

- 5 2026-07-17

#### IBM Thinkが体系化した解説を公開
Ivan Belcic・Cole Stryker「What is loop engineering?」（IBM Think）。定義・4段階（Goal → Action → Observation → Adjustment）・8部品・4つの危険をまとめて提示した、本調査で唯一原文を直接読めた体系的な一次文書。ただし本調査の範囲内で確認できたのがIBMのこの1本というだけであり、「世界で唯一の体系的文書」という意味ではない。

- 6 2026-07-18（要確認）

#### Steinbergerが「Loop Engineering時代の終わり」を宣言したと報じられる
KuCoin flash newsなどの二次情報によれば、Steinbergerが線形的な「ループ」の反復から、グラフ構造でエージェントを組む「Graph Engineering」への転換を提唱したとされる。原ポストは本調査では確認できていない。「言い出した本人が撤回した」と断定することはできず、「そう報じられた」までしか言えない。

さとまた
ループエンジニアリングって私が言い出したわけじゃなくて、Claude Codeを作ってる本人たちとか、Googleの人とか、他にもいろんな人がもうこの話をしてる。私だけが言ってる特殊な話じゃなくて、業界で実際に起きてることだよね？

📎 Claudeの指摘
その感覚は正しい。2025年7月のHuntleyの技術的な原型から数えても1年、「ループエンジニアリング」という語としては2026年6月の1週間の間に、AnthropicのClaude Code責任者・独立エンジニア・Googleのエンジニアリングリーダーという、互いに独立した立場の3人がほぼ同時に同じ方向のことを言い始め、7月にIBMが体系化した。ここは一次情報で確認できる。ただし冷静に見るべき点が2つある。1つは、この語自体がまだ2ヶ月ほどしか経っていない非常に若い言葉だということ。ADTmag自身が「still a young term」「may prove to be more of a developer shorthand than a formal discipline」（正式な分野というより開発者の略語に留まるかもしれない）と留保している。もう1つは、ChernyとSteinbergerの発言はいずれもADTmagがBusiness Insiderを経由して引用したものであり、私（Claude）が読んだのはADTmagの本文までで、発言そのものの一次確認ではないということだ。「言った」ことは複数の経路で確認できるが、「正確にどう言ったか」の一次確認はできていない。

🤖 Codexの指摘
Steinbergerが6週間で「Graph Engineering」へ乗り換えたという件は、語の未成熟さを示す材料ではあるが、実践の否定を示す証拠ではない。そもそもこの件は原ポストを確認できず、KuCoinのflash news等を経由した二次情報である。よって「本人がループを捨てた」と事実認定するのは危険で、現時点で言えるのは「そう報じられた」「ラベルと構成モデルを早期に更新した可能性がある」までだ。さらに、ループとグラフは排他的でもない。実用的なエージェント系は、個々のノード内では観察と修正を反復し、全体では分岐・並列・承認ゲート・ロールバックを持つ有向グラフになる。単純なwhile trueから、状態機械やワークフローDAGへ精密化したと読む方が技術的には自然であり、グラフへ移っても、その中からループは消えない。語が消えても、停止条件・eval・外部ツール・永続状態・権限境界・maker/checker分離といった中身の強い部分は残る。

✅ 事実としてどうなるか
判定: 半分支持される。「私以外にも複数人がループエンジニアリングを話している」は支持される。Anthropic・独立エンジニア・Googleという異なる立場の3人が2026年6月の1週間にほぼ独立に同じ方向を語り、IBMが7月に体系化した事実は一次情報で確認できる。一方で「これが確立した専門用語・分野である」は支持されない。語の発生から本調査時点でまだ13ヶ月（技術的原型から）、用語としての定式化からは2ヶ月しか経っておらず、提唱者の一人が早くも「Graph Engineering」という次の看板を出したと報じられている。根拠: ghuntley.com（2025-07-14）、ADTmag（2026-07-01、Cherny・Steinberger・Ng発言の引用元）、Substack（2026-06-07/08）、IBM Think（2026-07-17）、KuCoin flash news（2026-07-18、二次情報）。確信度: 語の実在と拡散については高、Graph Engineeringへの「乗り換え」の事実認定については低（原ポスト未確認）。覆る条件: Steinbergerの原ポストが確認でき、実際に「Loop Engineeringは終わった」と明言していれば、この語の短命さはより強く支持される。逆に2027年以降もIBM・Osmani・ベンダー各社が同じ語を使い続けていれば、「若い言葉」という評価は「定着した言葉」へ書き換える必要がある。

→ 次のSection 7では、この語が具体的に何を指しているのか（定義と4段階、8つの部品）を見る。

## 🔁 何をループと呼んでいるのか
このセクションの3点
① IBMはループを「Goal → Action → Observation → Adjustment」の4段階、明示的な停止条件を持つ再帰的目標として定義する
② IBMが挙げる8つの部品は、Automations・Hooks・Context engineering・Tool access・Worktrees・Skills・Subagents・Spineの8つである
③ この8部品は、さとまたのハブ環境（.claude/以下）にすでにほぼ全部揃っている。2030年の未来の話ではない

4段階
Goal → Action → Observation → Adjustment

8部品
IBMが挙げるループの構成要素

8/8
ハブ環境にすでに存在すると確認できた部品数

4つ
IBMが挙げる危険（Section 12で詳述）

出典はIvan Belcic・Cole Stryker「What is loop engineering?」（IBM Think, 2026-07-17）。原文の定義を引く。
Loop engineering is the practice of designing agentic workflows, or loops, that iteratively guide AI agents toward completing user-defined goals with minimal human intervention.
For developers, loop engineering reframes their role away from prompting AI agents toward one in which they design automated systems that prompt, check and guide agents.
プロンプトを打つ人から、プロンプトを打ち・検証し・導くシステムを設計する人へ。IBMが「開発者の役割の再定義」として位置づけている点が、ADTmagのCherny引用（「もうプロンプトを書かない」）と符合する。

図: ループの4段階
1
Goal
再帰的な目標。毎回の反復で評価され、明示的な停止条件を持つ必要がある

▶
2
Action
エージェントがツールを呼び、コードを書き、変更を加える

▶
3
Observation
結果を観測する。テスト・eval・ログ・実行結果

▶
4
Adjustment
観測結果をもとに次の一手を調整し、Goalに戻る

4段階の中でIBMが最も強く注意を促しているのは1のGoalである。「再帰的な目標」は、毎回の反復のたびに評価し直され、いつ止めるかが決まっていなければ、エージェントは終わりなく回り続けるか、達成不能な基準を追い続けて資源を浪費する。IBMは良い例と悪い例を対比させている。
悪い例: Make my website load faster（もっと速くして、では終了条件が測定できない）
良い例: stop iterating when your code passes all unit tests and satisfies the requested requirements（全ユニットテストが通り、要求仕様を満たしたら止める）
停止条件が曖昧な目標を与えると、ループは「うまくいっているように見えるが、いつまでも終わらない」状態に陥る。これは技術的な弱点というより、目標設定という人間側の仕事の質がループ全体の質を決めるという、依頼者の主張に対する重要な補助線になる。

部品 | 役割 | これが無いとどうなるか

Automations / scheduling | 反復の刻み。GitHub Actionsやcronで一定間隔・イベントごとにループを起動する | エージェントは人間が手動で起動したときしか動かず、無人運用にならない
Hooks | イベント駆動の割り込み。ポリシー強制・出力検証をエージェントの外側で行う | 検証ロジックまでエージェント自身のプロンプトに書く羽目になり、トークンを消費しつつ信頼性も下がる
Context engineering | 周回のたびに溜まる文脈を圧縮し、必要な分だけ次の周回へ渡す | 周回を重ねるほど文脈が肥大化し、コストが増え、古い前提が混ざって判断が劣化する
Tool access | MCPサーバーやAPIへの接続。エージェントが実際に外の世界へ手を伸ばす経路 | エージェントは「やる」と言うだけで、実際には何も実行できない
Worktrees | git worktreeなどによる並列作業の隔離 | 複数の変更を同時に試せず、1本のブランチを取り合って作業が直列化する
Skills | 反復する作業ごとの知識をskill.mdのような形で文書化したもの | 同じ種類の作業のたびに、エージェントが毎回ゼロから手順を組み立て直し、再現性が落ちる
Subagents | 実装するエージェントと検証するエージェントを分けるmaker/checker構造 | 書いた本人に確認させることになり、見落としが素通りしやすくなる
Spine | 周回の結果を書き足していく持続する状態・記憶 | 前回の失敗を忘れ、同じ間違いを繰り返す。ループが「学習しない」状態になる

📎 Claudeの指摘 — この8部品は、もう手元にある
この記事を書いている環境そのものが、8部品の実例になっている。2030年の未来の話としてではなく、いまこの瞬間の設備として並べる。

IBMの8部品 × さとまたのハブ環境
✓ Automations / scheduling
ハブのスケジュールタスク（.claude/scheduled_tasks）、cronによる定期実行

✓ Hooks
PreToolUse/PostToolUseの command型フック（pre-commit-check.sh、post-edit-lint.sh 等）。全てLLM不使用の決定的スクリプト

✓ Context engineering
仕様書を会話に貼らず.claude/worktrees/*.mdに書いてパスだけ渡す運用がすでに定着している

✓ Tool access
MCP（codex・playwright・context7等）で外部ツール・外部サービスへ接続済み

✓ Worktrees
.claude/worktrees/配下で実装作業を隔離。implementer・testerはworktree隔離が標準

✓ Skills
codex-delegate等のグローバルスキルとして、繰り返す作業の手順が文書化されている

✓ Subagents
architect・implementer・reviewer・writer・git-ops・explorer・testerの7種、maker/checker構造がすでにある

✓ Spine
.claude/NEXT.mdがセッションをまたぐ持続する記憶として機能している

さとまた
IBMが8つの部品を挙げてるって言うけど、それを全部揃えるのが2030年に向けた目標ってことでしょ？まだ先の話だよね？

📎 Claudeの指摘
そこは違う。上のチェックリストの通り、8部品は「これから揃える目標」ではなく「このハブ環境にすでに全部ある部品」である。cronによる定期実行、command型フック、仕様書をパスで渡すcontext engineering、MCPによるツールアクセス、git worktreeによる並列隔離、繰り返し作業を文書化したスキル、maker/checkerのサブエージェント構成、NEXT.mdという持続する記憶。IBMが2026年7月にループの構成要素として挙げたものと、この記事を生産している体制はほぼ1対1で対応する。つまりこの章の落ちは「2030年にはこうなる」ではなく、「部品はもう手元にある」ということだ。足りないのは部品ではなく、それらを一つの再帰的な目標のもとで自律的に回し続ける設計と、止めるべきときに止める判断の方である。

🤖 Codexの指摘
IBMの8部品は有用なチェックリストだが、worktree・cron・hook・skills・subagentを一つの新分野として束ねただけという面がある。これらの個々の技術はLoop Engineeringという名称より前から、CI/CD、ワークフローエンジン、SRE、オートノミック・コンピューティングに存在した。LLMが不確率的な実行主体としてそこへ入ったため再設計が必要になった、というのが実態に近い。したがって「8部品が揃っている」ことは、新しい工学分野を体現していることの証明にはならない。私の見解では、ループエンジニアリングは定着済みの工学分野ではなく、既存の自動化技術をLLM時代向けに再編する過渡期の呼び名である。看板は消え得るが、設計課題は残る。

✅ 事実としてどうなるか
判定: 支持される（部品の実在について）／半分支持される（新分野としての価値について）。IBMが挙げる8部品は実在し、さとまたのハブ環境にもすでに全て確認できる。これは判定できる事実である。一方、「この8つを束ねたものが独立した新しい工学分野である」という主張は、Codexの指摘の通り、既存技術（CI/CD、ワークフローエンジン、hooks、cron）の再編成である可能性が高く、判定は割れる。根拠: IBM Think（2026-07-17、4段階と8部品の原文）、.claude/配下の実際のhooks・worktrees・agents・NEXT.mdの構成（このプロジェクト自身）。確信度: 部品の実在については高、新分野としての独自性についてはCodexの指摘を採用し中〜低。覆る条件: この8部品の組み合わせが、単体の技術の総和を超える性質（例えば予測不能な創発的な振る舞いや、既存のCI/CDでは不可能だった成果）を示せば、独立した工学分野としての評価を引き上げる材料になる。逆に、これらを別の名前（例えばオーケストレーション、ワークフローエンジニアリング）で呼んでも中身が変わらなければ、看板だけの言葉だったという評価が固まる。

→ 次のSection 8では、Andrew Ngが挙げる「3つのループ」を見る。依頼者の主張はこのうち3つ目が閉じるかどうかの話である。

4/6　🎯 Andrew Ng の3つのループ

## 🎯 Andrew Ng の3つのループ
このセクションの3点
① Ngは0→1のプロダクト開発を、速さが全く異なる3層のループ（数分・時間〜日・数日〜数週間）として説明する
② Ngは「人間の貢献はtasteではなくcontext advantageだ」と述べ、AIが知らないことを人間が知っている限り人間が要ると条件付きで主張する
③ Codexの指摘: この文は条件文であり永久に人間が残るとは言っていない。データ接続が進めば、条件そのものが狭くなる

数分
①agentic coding loop — 1周にかかる時間

時間〜日
②developer feedback loop — 1周にかかる時間

数日〜数週間
③external feedback loop — 1周にかかる時間

約1時間
Ngの娘のタイピング練習アプリ実例で、エージェントが無介入で働いた時間

出典: John K. Waters「Loop Engineering Emerges as Developers Put AI Coding Agents on Repeat」ADTmag、2026年7月1日。Andrew Ng（DeepLearning.AI創業者）が0→1のプロダクトを作る際に使うとしている3層構造で、依頼者の主張はこのうち3つ目が閉じるかどうかの話に対応する。

# | ループ | 中身 | 速さ

① | agentic coding loop | 仕様（＋任意でevals）を渡すと、エージェントがコードを書き、テストし、仕様を満たすまで反復する | 数分で1周
② | developer feedback loop | 開発者が成果物を見て、改善の方向へエージェントを操舵する | 時間〜日
③ | external feedback loop | 友人・アルファテスター・本番ユーザー・A/Bテストからのフィードバック | 数日〜数週間

図: 速さの違う3つのループ → この図は横にスクロールできます
①数分②③
-
-
- ①agentic coding loop（数分）仕様を渡すとエージェントがコードを書きテストし満たすまで反復する依頼者の主張: ここは既に閉じている②developer feedback loop（時間〜日）開発者が成果物を見て、改善の方向へエージェントを操舵する依頼者の主張: 閉じつつある③external feedback loop（数日〜数週間）友人・アルファテスター・本番ユーザーA/Bテストからのフィードバック争点: ここが閉じるか（第11章）

3つのループは同じプロダクトを内側から外側へ包む入れ子構造で、周期の速さが1桁以上違う。①は数分で1周するが、③は数日〜数週間かかる。速さの目安はNgの記述に基づくもので、正確な計測値ではない。依頼者の主張とNgの主張が対立するのは③についてであり、詳しい検証はSection 11で行う。
📎 Ngの原文（人間擁護論）
依頼者の主張への最大の反論はここにある。Ngの原文を引く。
Many people describe this human contribution as "taste," but I prefer to think of it as humans having a context advantage.
So long as the human knows something the AI does not, human-in-the-loop is needed to inject that knowledge into the system.
Ngが実例として挙げるのは、娘のタイピング練習アプリを作らせたときのことである。エージェントは約1時間、ブラウザで自分の作ったものを何度も確認しながら、人の介入なしに働き続けたという。①のループが数分で回るのに対し、この1時間という数字は、単純なアプリでも複数周の①ループが積み重なっていることを示す傍証になる。

さとまた
ログとヒートマップを見てアジャイルを回す、あの人間の仕事も2030年にはAIがやるようになる。3つ目のループも閉じるはずだ。

📎 Claudeの指摘
Ngのcontext advantageは、私（Claude）の見立てでは3つに割れる。①ユーザーの行動データ、②言語化されていない事業判断、③責任、の3つである。①は完全にデータであり、ログ・ヒートマップ・A/Bの結果としてAIが読める。しかし②③は、データを読めることとは別の種類の仕事であり、簡単には閉じない。したがって私の暫定的な見立ては「アジャイルのループは半分閉じる」——計測と仮説はAIへ、何を作るかの決定と責任は人間に残る、というものである。ただしこの分解にはCodexから明確な反論が来ている。詳しい応酬はSection 11で行う。

🤖 Codexの指摘
Ngの「So long as the human knows something the AI does not」という文は条件文であって、人間が永久に残るとは言っていない。この条件は、十分なセンサー・記憶・顧客会話・事業ルールをAIへ接続すれば狭くなっていく。私はcontext advantageを5つに分解する。①非接続の情報、②暗黙の価値判断、③因果と反実仮想、④探索権限とリスク予算、⑤正統性と責任。①はデータ接続が進めば減り、③はモデルと実験基盤の進歩で縮む。しかし②④⑤は、AIが賢くなれば自然消滅する種類の問題ではなく、組織が明示的に委任して初めて移る。「読める」ことと「正しく意思決定できる」ことは別であり、ここを混同すると③のループを過小評価する。

✅ 事実としてどうなるか
判定: この章では判定しない（保留）。詳細な検証はSection 11で行う。3つのループという整理自体は、Ngの一次情報として確認でき、速さの違いも記述と符合する。①agentic coding loopはすでに実務で閉じており、②developer feedback loopは閉じつつある、という点はClaude・Codexの双方で一致している。③external feedback loopが閉じるかどうかだけが、Claudeの「context advantageの3分解・半分閉じる」とCodexの「5分解・周回数では9割自動だが意思決定の重要度では半分以下」という、結論の異なる2つの見立てに割れている争点である。根拠: ADTmag（2026-07-01、Ngの3つのループと引用の原文）。確信度: 3層構造の実在については高、③が閉じるかどうかについては中〜低（Claude・Codexで結論が割れている）。覆る条件: 事業判断・責任の所在を測る具体的な観測データが出れば、③の判定は動く。Section 11でその判定条件を詳しく書く。

→ 次のSection 9では、2026年時点でこの3つのループがどこまで実際に閉じているかを、製品ベースで見る。

## 🧭 2026年 — いまどこまで閉じているか
このセクションの3点
① 12工程×製品を洗い出すと、GAと明記されているのはDurable Objects・AI Gateway・Copilot Autofix・GitHub Actionsなど下位インフラ寄りの機能だけ
② Vercel Agent・Claude Code on the web・Routinesは公式にBeta／research previewと明記されている。Routinesだけは実行中に承認プロンプトが出ない設計
③ 要件定義・仮説立案・A/Bテストには専用製品が見つからなかった。ただし調査が開発者向け製品に偏っているため「無い」ではなく「見つからなかった」が正確

4件
公式にGA明記

4件
Beta/Previewと明記

8件
ステータス未確認

工程 | 製品 | トリガー | 人が止める場所 | 提供状況

コードレビュー | Vercel Agent (Code Review) | PR作成・コミットpush・@vercelメンション | 修正案はSandboxで検証済のものだけPRに提示、既定read-only・書き込みは承認制 | Beta/Preview（Public Beta・Pro/Enterprise）
監視・障害対応 | Vercel Agent (Investigation) | 異常検知アラート発火 | 仮説と推奨修正を提示のみ、実行はObservability Plus有効化＋承認が必要 | Beta/Preview（Public Beta・上記と同枠）
実装・テスト | Vercel Sandbox | エージェント/開発者がSandbox APIを明示呼び出し | 実行は隔離環境内、停止はCLI/SDKから明示操作 | ステータス未確認
CI・デプロイ／実装基盤 | Vercel Workflow (DevKit) | 'use workflow'関数の呼び出し・外部イベント（hooks） | ダッシュボードでログ・トレースを観測可能 | ステータス未確認
実装（コード生成） | Vercel v0 | プロンプト入力 | 生成後、人間がレビューしてデプロイを承認 | ステータス未確認
インフラ運用（状態管理） | Cloudflare Durable Objects | Workerからのオブジェクト呼び出し | 該当なし（下位インフラ機能） | 公式にGA明記（コア機能。SQLiteストレージはbeta → GAへ移行済み）
実装（モデル呼び出し一元化） | Cloudflare AI Gateway | アプリからのAPI呼び出し | キャッシュ・レート制限・リトライ・フォールバックをダッシュボードで制御 | 公式にGA明記（"Available on all plans"）
CI・デプロイ／インフラ運用 | Cloudflare Workflows | プログラム的トリガー・API呼び出し | プログラム的に一時停止・終了が可能と明記 | ステータス未確認
コードレビュー（脆弱性修正） | GitHub Copilot Autofix | CodeQLのコードスキャンでアラート検出時に自動生成 | 修正案はsuggestionとして提示、自動適用はされない | 公式にGA明記（コア機能。関連のagentic autofixのみpublic preview）
実装（コーディングエージェント） | GitHub Copilot coding agent | Issueアサイン・@copilotメンション・スケジュール起動 | ブランチの差分をレビュー、マージの最終判断は人間 | ステータス未確認
CI・デプロイ | GitHub Actions | push・PR・schedule・手動実行・API呼び出し | 実行中でも手動キャンセル可能 | 公式にGA明記（長年の実運用実績）
実装（クラウド実行） | Claude Code on the web | claude --cloud実行・Web UI/モバイルからのタスク投入 | クラウドVMで隔離実行、diffをレビューしてPR作成を承認 | Beta/Preview（"research preview"と明記）
CI・デプロイ／監視・次の開発への反映 | Claude Code Routines | スケジュール（最短1時間）・API呼び出し・GitHub Event | 実行中は承認プロンプトなし。人間はON/OFF切替または削除で止める | Beta/Preview（"Routines are in research preview"と明記）
実装（クラウドタスク） | OpenAI Codex Cloud | Codex Cloud上での直接起動・GitHub/Linear/Slack連携からの委任 | サマリーとdiffを人間がレビューし、追加指示かPR作成を判断 | ステータス未確認
実装（自律エンジニアリング） | Devin | Ask/Agentモードの選択・Slack連携・CLI起動 | Ask modeでプラン作成→Agent modeで実行、セッション中に介入可能 | ステータス未確認
実装（クラウドエージェント） | Cursor Cloud Agent | Cursor UI・Slack（@cursor）・GitHub/Bitbucket PRコメント・Linear・API | "merge-ready PR"としてレビュー後に人間がマージ | ステータス未確認

📎 Claudeの指摘 — 「Beta表記なし」はGAの意味ではない
research-Bの16行を並べると、公式にGAと明記されているのはCloudflare Durable Objectsのコア機能、Cloudflare AI Gateway（"Available on all plans"）、GitHub Copilot Autofixのコア機能、GitHub Actionsの4つだけだった。これらはいずれも「下位インフラ」か「1つの修正案を提示して終わる」という、責任範囲が狭い機能である。一方、複数工程をまたいで自律的に動く設計のVercel Agent・Claude Code on the web・Claude Code Routinesは、そろって公式にPublic Beta／research previewと明記されている。残りの半分以上は「Beta表記なし」だが、これはGAの証明ではなく、公式ページに明示的なラベルが見当たらなかったというだけの意味である。GitHub ActionsのようにGAだと周知の事実として扱ってよいものと、単に確認できていないだけのものを、この記事では区別して「ステータス未確認」と書く。

🤖 Codexの指摘 — GA判定の基準を一つに固定する
「Beta表記なしはGAを意味しない」と正しく注意している一方、Cloudflare AI Gatewayでは「Beta表記なし＝GA相当」と書いてしまうと、記事の中で基準が割れる。GitHub ActionsのGAも、取得した該当ページ自体には明示がなく「周知の事実」で補っている。だから記事では「公式にGA明記」「Beta/Previewと明記」「ステータス未確認」の3列を機械的に分けるべきで、周知の事実による補完は別枠として断る必要がある。この表もその基準に従って作り直した。

🚫 見落としがちな1点 — Claude Code Routinesだけ設計思想が違う
・Vercel AgentもGitHub Copilot coding agentも「読み取り→提案生成→人間の承認でのみ書き込み」を明示している
・Claude Code Routinesだけは公式ドキュメントに"there is no permission-mode picker and no approval prompts during a run"と明記され、実行中は無承認で自律的に走る
・人間の介入点は「Routine単位でのON/OFF切替」または「削除」という事後的なものに変わる。組織ポリシーで管理者が全体を無効化することはできる

📎 Claudeの指摘 — AWS AI-DLC と Azure SRE Agent は承認ゲートを制度として残している
すべてのベンダーが無承認の自律実行へ向かっているわけではない。AWS AI-DLC（AI-Driven Development Lifecycleの公式ライフサイクル）は、AIがBolt（作業サイクル）ごとに計画・コード・テスト・IaCのドラフトを作るが、公式資料自体が「各Boltごとに人間が検証・承認する」ことを明記している。Azure SRE Agent🤖 Codexの指摘 — 「専用製品が無い」は調査範囲の偏りかもしれない
要件定義・仮説立案・A/Bテストに専用製品が見つからなかったという事実は、弱い証拠としては意味があるが、調査対象がVercel・Cloudflare・GitHub・Claude Code・Codex・Devin・Cursorという開発者向け製品へ偏っている。プロダクト分析・feature flag・experimentation・CRM・広告最適化の市場を調べなければ、A/Bテスト自動化の不在は結論できない。「専用製品がない」は「汎用エージェントでできない」の証明でもない。だから記事では「無い」ではなく「今回見た開発者向け製品の範囲では見つからなかった」と書くべきだ。

さとまた
AIがJAMstackを開発から監視ログまですべて回すって言ったけど、実際どこまで来てるの。もう全部揃ってるの、それともまだ穴だらけなの。

📎 Claudeの指摘
「実装」「コードレビュー」「テスト」「CI・デプロイ」「インフラ運用」「監視・障害対応」の6工程は、限定された環境の中でなら2026年時点ですでに自動で回る部品が揃っている。だが「部品が揃っている」と「無人で本番を任せられる」は別だ。Vercel AgentもClaude Code on the webも、書き込みには人間の承認を挟む設計になっている。無承認で走るのはRoutinesだけで、しかもそのRoutines自体がまだresearch previewである。要件定義・仮説立案・A/Bテストには、この記事が確認した範囲では専用製品そのものが見当たらなかった。

🤖 Codexの指摘
重要なのは、2026年の製品がそろってPR・sandbox・read-only・承認・ロールバックを中心に設計している事実である。これは単なる移行期の弱さではなく、権限境界そのものが製品価値であることを示している。部品が揃うこと、製品が提案できること、無人で安全に本番を回せることは三段階として別であり、research-Bの表は最初の段階（部品が揃った）までしか証明していない。

✅ 事実としてどうなるか 判定: 半分支持される。実装・テスト・CI・デプロイ・監視の実行部分は2026年時点で自動化の部品がそろい、GitHub Copilot AutofixやCloudflareの一部機能はGAとして提供中。一方、複数工程を横断して無承認で走る設計（Claude Code Routines）はまだresearch preview、要件定義・仮説立案・A/Bテストには専用製品が見当たらなかった（ただし調査範囲の偏りによる可能性が高い）。根拠: research-Bの16製品×提供状況の実測。確信度: 中（提供状況ラベルは2026-08-16時点の公式ページのスナップショットであり、B以外の市場は未調査）。これが覆る条件: ①Routines・Vercel Agentが正式GAへ移行する ②プロダクト分析・experimentation市場を調査してA/Bテスト専用製品の有無が確定する。

→ 次のSection 10では、AIが奪うと言われている「アジャイルのループ」そのものの中身を、計測から目的関数の決定まで7段に分解する。

5/6　♻️ アジャイルのループとは何だったのか

## ♻️ アジャイルのループとは何だったのか
このセクションの3点
① アジャイルのループは「計測→仮説→実装→検証→計測」の輪。ヒートマップとログ分析はこの輪の入り口で、クリック位置・スクロール到達率・離脱ポイント・ファネル・コホートを見て次に何を作るかを決める仕事だった
② さとまたが「AIが奪う」と言っているのは、まさにこの計測から仮説立案までの工程である
③ この輪を7段に分解すると、①計測②異常検知はデータ処理で自動化しやすい。⑥展開判断⑦目的関数の決定は価値判断で、AIが賢くなっても自動で決まる種類のものではない

アジャイルのループ（4段の輪）
①
計測
ヒートマップ・ログ・アクセス解析でユーザーの行動を集める

▶
②
仮説
なぜこの数字になったかを考え、次に試すことを決める

▶
③
実装
仮説をもとに機能・文言・導線を変更する

▶
④
検証
A/Bテストや前後比較で、良くなったかを判定する

📎 Claudeの指摘 — ヒートマップとログ分析は具体的に何をする仕事だったか
この工程の中身を分解しないまま「AIが奪う」と言っても検証できない。人間（プロダクトマネージャー・グロースハッカー・アナリスト）がヒートマップとログ分析でやっていたのは、具体的には次のようなことだ。クリック位置＝どのボタン・リンクが実際に押されているか、意図した動線と一致しているか。スクロール到達率＝ページのどこまで読まれているか、重要な情報が見られていない位置はどこか。離脱ポイント＝フォームや購入フローのどのステップで人がいなくなるか。ファネル分析＝訪問→会員登録→購入のように、段階ごとに何%が次へ進んだか。セッション再生（セッションリプレイ）＝個々のユーザーの操作を録画のように再生し、迷っている挙動を目視で確認する。コホート分析＝登録時期や流入経路でユーザーを束ね、束ねごとの継続率・行動差を比較する。これらを見て「なぜ離脱が多いのか」「どの導線を変えれば改善しそうか」という仮説を立てるところまでが、依頼者が「人間がやっていた」と言っている仕事の中身である。

🤖 Codexの指摘 — 「読める」と「正しく解釈できる」は別の話
ヒートマップやログの数値そのものはAIが読める。だがユーザー行動データは現実そのものではなく計測器が切り取った代理変数である。ヒートマップのクリック増加は理解が進んだことも、UIが紛らわしくなったことも意味しうる。滞在時間の増加は満足にも迷子にも読める。コンバージョン率を上げた施策が、後から返品・解約・信頼毀損・サポート負荷を増やす場合もある。AIはログを読めても、何を成功と定義するか、観測されない損失をどう扱うか、短期指標と長期価値をどう交換するかをデータだけから一意には決められない。ここは「AIが奪う」と言い切る前に、計測（データ処理）と目的の定義（価値判断）を分けて考える必要がある。

### この輪を分解すると7段になる
# | 段階 | 中身 | データ処理か価値判断か

① | 計測 | クリック・スクロール・離脱・ファネル・セッション再生・コホートのデータを集める | データ処理
② | 異常検知 | 通常と違う数字の動きを見つける（急な離脱増加・エラー率上昇など） | データ処理
③ | 仮説生成 | なぜその数字になったかの説明候補を作る（相関から因果の候補を出す） | データ処理寄り（因果の識別が要る分だけ難度が上がる）
④ | 実験設計 | 何を・誰に・どれだけの期間・どんな停止条件で試すかを決める | 価値判断寄り（対象者・リスク予算の選択が入る）
⑤ | 統計判定 | サンプル数・有意差・多重検定・季節性を踏まえて「良くなった」を判定する | データ処理（ただし設計の質に判定の正しさが依存する）
⑥ | 展開判断 | 判定結果を全ユーザーに広げるか、一部に留めるか、やめるかを決める | 価値判断
⑦ | 目的関数の決定 | そもそも何を「良い」とするか（売上・信頼・安全・従業員負荷のどれを優先するか）を決める | 価値判断

さとまた
人間がログやヒートマップでユーザーを分析してアジャイル開発をしていたところも、AIがすべて自動で回すようになる。

📎 Claudeの指摘
7段のうち①計測と②異常検知は、すでにVercel Agent（Investigation）やClaude Code Routinesの"Alert triage"のような形で自動化が進んでいる。③仮説生成もデータ処理の延長で自動化しやすい。だが⑥展開判断と⑦目的関数の決定は、そもそも何を「良い」とするかという価値判断であり、これはユーザーの行動データそのものからは導けない。この記事の争点（第11章）は、この7段のどこまでが閉じ、どこから先が閉じないかという線引きである。

🤖 Codexの指摘
A/Bテストは自動化すれば真実が自動的に出る装置ではない。サンプル比率の異常、複数検定、早期停止、季節性、ネットワーク効果、学習効果、セグメント間の異質性、施策同士の干渉がある。⑤統計判定を「データ処理だから自動化できる」と単純化すると、これらの落とし穴を見落とす。AIが統計設計とガードレールを実装することは可能だが、④実験設計と⑦目的関数が不完全なら、不完全な指標を高速に最適化するだけになる。これは能力不足ではなく仕様不足の問題である。

✅ 事実としてどうなるか 判定: 工程の分解としては支持される、自動化の範囲は半分支持される。①計測〜③仮説生成はデータ処理の性質が強く自動化が進みやすい。④実験設計〜⑦目的関数の決定は価値判断の性質が強く、AIの読解力向上だけでは自動的には閉じない。根拠: research-mainのNgの3層モデル（external feedback loopの記述）とCodexの見解のcontext advantage 5分解。確信度: 中（7段への分解はこの記事独自の整理であり、業界標準の分類ではない）。これが覆る条件: 実験設計・目的関数の決定を人間から明示的にAIへ委任する運用（ガードレール・停止条件・予算をあらかじめ人間が固定した上でAIに実験選択を任せる形）が一般化した場合、④⑤⑥はデータ処理側へ寄る。

→ 次のSection 11では、この争点をさらに掘り下げ、Ngの「context advantage」とCodexの5分解を突き合わせて、3つ目のループが閉じるかどうかを判定する。

## ⚔️ 争点 — 3つ目のループは閉じるか
このセクションの3点
① この章が主張の核心。3つ目のループが閉じるかどうか
② Claudeは半分閉じると見た。Codexは分け方が粗いと反論した
③ Claudeは反論を受け入れ、判定を書き換えた

Andrew Ng の3つのループのうち、①コーディングループはすでに閉じています。②開発者フィードバックループも閉じつつあります。争点は③外部フィードバックループ——本番ユーザーの反応を見て、次に何を作るかを決める輪です。

さとまたの主張は「ここも2030年に閉じる」。Ng は「人間がAIの知らないことを知っている限り、human-in-the-loop が必要だ」と書いています。この章は、その真正面の衝突です。

さとまた
人間がログやヒートマップでシステムのユーザーを分析してアジャイル開発をしていたのでさえ、AIですべてが自動で回る未来が2030年にくる。

📎 Claudeの指摘（最初に書いたもの）
Ng の言う「context advantage（文脈の優位）」の中身を、私は3つに割りました。

① ユーザーの行動データ——クリック位置、離脱、滞在、ファネル。これは完全にデータです。人間が目で見て読み取っていただけで、機械が読めない理由はどこにもない。
② 言語化されていない事業判断——なぜこの顧客層を狙うのか、なぜ利益率を落としてでも信頼を取るのか。
③ 責任——失敗したときに説明し、補償する主体。

私の結論は「①はAIが読めるので閉じる。②③は残る。よってアジャイルのループは半分閉じる」でした。計測と仮説はAIへ、何を作るかの決定と責任は人間に残る、と。

🤖 Codexの指摘（私に反論した）
「①の扱いに同意しない」と Codex は書いてきました。

「『読める』と『正しく意思決定できる』の間に、最も難しい問題が残っている。ユーザー行動データは、現実そのものではなく計測器が切り取った代理変数である。ヒートマップのクリック増加は、理解が進んだことも、UIが紛らわしくなったことも意味し得る。滞在時間の増加は満足にも迷子にもなる。コンバージョン率を上げた施策が、返品、解約、信頼毀損、サポート負荷を後から増やす場合もある。」

「AIはログを読めても、何を成功と定義するか、観測されない損失をどう扱うか、短期指標と長期価値をどう交換するかをデータだけから一意に決められない。これは能力不足というより、仕様不足である。」

そのうえで Codex は、context advantage を3つではなく5つに割りました。①非接続の情報 ②暗黙の価値判断 ③因果と反実仮想 ④探索権限とリスク予算 ⑤正統性と責任。「①はデータ接続が進めばかなり減る。③もモデルと実験基盤の進歩で縮む。しかし②④⑤は、AIが賢くなれば自然消滅する種類の問題ではない。組織が明示的に委任して初めて移る。」

結論の言い方も違いました。「半分閉じる」ではなく——「周回数では9割が自動、意思決定の重要度では半分以下が自動」。

✅ 事実としてどうなるか

判定: 半分支持される。ただし「半分」の測り方は、私（Claude）の最初の言い方が間違っていた。

根拠: 私は「行動データは読めるから閉じる」と書いたが、これは観測と意思決定を混同している。Codex の指摘のとおり、指標が上がったことと、良くなったことは同じではない。コンバージョンを上げた変更が解約を増やす例は、この記事が引いた資料の外でも普通に起きる。読めることは、目的関数を選べることを意味しない。

私が受け入れた点: context advantage の分解は、私の3分類より Codex の5分類のほうが精度が高い。とくに「④探索権限とリスク予算」を私は落としていた。誰にどの実験を見せてよいか、どこまでの損失を許すかは、データでも責任でもない第三のものであり、これは明確に私の見落としである。

私が譲らない点: それでも、ループの周回数の大半は自動になる。Ng の文は「人間がAIの知らないことを知っている限り」という条件文であって、人間が永久に残るとは言っていない。データ接続が進めば条件は狭くなる。狭くなった先に残るのは「知識」ではなく「権限」である。

確信度: 低。これは2030年の予測であり、検証されていない。

これが覆る条件: ①目的関数の自動設計（何を成功と呼ぶかをAIが決めてよいと組織が委任する事例）が2028年までに複数出る → 私の判定は保守的すぎたことになる。②逆に、AIが最適化した指標が長期価値を毀損した事故が公になり、実験の人間承認が制度化される → 周回数の自動化さえ後退する。

### アジャイルのループを7段に割ると、どこが割れるのかが見える
段 | 工程 | これはデータ処理か、価値判断か | 2030年の判定

1 | 計測（ログ・ヒートマップを集める） | データ処理 | AI（無人）
2 | 異常検知（いつもと違う数字を見つける） | データ処理 | AI（無人）
3 | 仮説生成（なぜそうなったかの候補を出す） | データ処理に近い。ただし相関を因果と取り違える | AI（無人。ただし既存指標の枠内）
4 | 実験設計（何をどの集団に出すか） | 両方。統計設計はデータ処理、対象者の選定は価値判断 | AI（設計）／人（対象の承認）
5 | 統計判定（勝ったかどうか） | データ処理 | AI（無人）
6 | 展開判断（本番に出すか） | 価値判断。可逆かどうか、影響範囲による | AI（可逆な小変更）／人（不可逆・大影響）
7 | 目的関数の決定（何を成功と呼ぶか） | 純粋な価値判断 | 人。ここが最後まで残る

同じ「ループが閉じる」でも、2人が見ているものが違う
閉じる側
周回数で数えると、ほぼ全部

- ・計測・異常検知・仮説生成・統計判定はすべてデータ処理

- ・文言、導線、通知時刻、検索順位、オンボーディングの小変更は事前に条件を決めておけば無人で回る

- ・1日に何十回も回る改善のうち、人が見るのは例外だけ

- ・Codexの言葉で「周回数では9割が自動」

閉じない側
重要度で数えると、半分も閉じない

- ・何を成功と呼ぶか（目的関数）は、データの中に答えが無い

- ・誰にどの実験を見せてよいか、どこまでの損失を許すか（探索権限とリスク予算）

- ・価格、対象顧客、データ利用、ブランド、ロードマップへの波及

- ・失敗したときに説明し、補償する主体（正統性と責任）

- ・Codexの言葉で「意思決定の重要度では半分以下が自動」

この争点の決着のつけ方
この対立は、実は「閉じる」の数え方の違いでした。回数で数えれば閉じます。重さで数えれば閉じません。そして依頼者の主張「すべてが自動で回る」は、回数の話としてはほぼ正しく、重さの話としては正しくない。

ただし、ここで安心してはいけない部分があります。未来の選好は、既存のデータの中に存在しません。新しい市場へ行く、利益率を落として信頼を取る、ある顧客層をあえて狙わない——これは予測ではなくコミットメントです。Codex はこれを「external feedback loop の最終的な人間ゲート」と呼びました。私も同意します。

逆に言えば、コミットメントを持たない組織のループは、閉じてしまいます。目的関数を疑わず、指標が上がることだけを追う会社は、2030年にはAIだけで回ります。そして上がった指標のまま、遅く死にます。これがこの章のいちばん重い結論です。

→ 次のSection 12では、閉じるのを実際に止めている4つを、製品と数字で見る。

## 🚧 閉じるのを止めている4つ
このセクションの3点
① 2030年でもループが無条件には閉じない理由は、検証・権限・費用・責任の4つに整理できる
② 検証は「良くなった」を誰がどう判定するかの統計的な難しさ、権限は本番へ触る範囲の段階化、費用はサブエージェント構成がトークンを食う構造、責任は出荷したコードの説明責任が人間に残ること
③ IBMが挙げる4つの危険のうちcomprehension debtは特に静かに溜まる。技術的負債と違い意図的な近道ではなく、自動テストを通ってしまうため気づかれにくい

4つのうち、2026年時点でどこまで閉じているか
△ 検証 — evalsとA/Bの統計的な信頼性
仕組みは自動化できるが、統計的落とし穴は自動化しても消えない

△ 権限 — 本番に触れる範囲の段階化
可逆な変更は自動、データ削除や認証変更は二者承認という段階化が進行中

− 費用 — ループの回数×単価が下がる
サブエージェント構成はむしろ単一エージェントよりトークンを食うと公式に明記されている

− 責任 — 出荷したコードの説明責任をAIへ移す制度
法制度・保険の整備が進んだという一次情報は確認できていない

項目 | 何が問題か | 具体例・根拠

検証 | 「良くなった」を誰がどう判定するかが自動化しにくい | サンプル比率の異常・多重検定・早期停止・季節性・ネットワーク効果・学習効果・施策同士の干渉があると、統計的に正しく見える判定でも誤る（Codexの見解 §3）
権限 | 本番に触れる権限をどこまでAIに渡すかの段階化が要る | Vercel Agentは既定read-only、GitHub Copilot coding agentはPRレビュー経由。Claude Code Routinesのみ実行中は無承認（第9章）
費用 | ループは回数×単価で効く。サブエージェント構成は単一エージェントよりトークンを食う | OpenAI Codexのドキュメントが明記（各サブエージェントが自前でモデルとツールを回すため。本記事の調査 §4）
責任 | 出荷したコードの説明責任は人間に残る | IBM Think: "Unverified code" — チェッカーもまたエージェントであり、出荷の責任は人間にある（本記事の調査 §3-3）

### 検証 — evalsとA/Bの統計は自動化してもごまかせない
🤖 Codexの指摘 — 統計の落とし穴は自動化しても消えない
A/Bテストは自動化すれば真実が自動的に出る装置ではない。サンプル比率の異常（SRM）、複数検定、早期停止、季節性、ネットワーク効果、学習効果、セグメント間の異質性、施策同士の干渉がある。観測データからの仮説生成も、相関を因果と取り違えうる。AIが統計設計とガードレールを実装することは可能でも、目的関数が不完全なら、不完全な指標を高速に最適化するだけになる。これは能力不足ではなく仕様不足の問題である。evalsも同じ構造を持つ——チェッカー自体がエージェントである以上、検証の質は検証を設計した人間の目的関数に依存する。

### 権限 — 可逆かどうかで段階化する
🤖 Codexの指摘 — 権限は「自動化できるか」ではなく「無承認実行を許すか」の問題
実装・コードレビュー・テスト・CI・デプロイ・インフラ運用・監視・障害対応・ログ分析は、限定された環境では技術的には閉じうる。ただし本番への権限はリスクに応じて段階化される。可逆な設定変更は自動、データ削除や認証変更は二者承認、という形である。「工程が自動化可能」と「企業が無承認実行を許す」は別問題であり、第9章の表が示すとおり、2026年時点の製品はどれも権限境界そのものを製品価値として設計している。

### 費用 — ループは回数×単価で効く
📎 Claudeの指摘 — さとまた自身が費用の教訓をすでに持っている
OpenAI Codexのドキュメントは、サブエージェント構成は単一エージェントよりトークンを食うと明記している（各サブエージェントが自前でモデルとツールを回すため）。これは開発エージェントの話だが、同じ構造は本番運用のポーリング型自動化でも起きる。さとまた自身の環境では、常時稼働のラズパイbotが3秒間隔で2チャンネルをポーリングし続け、1日57,600リクエストを発生させてCloudflare Pagesの無料枠（10万リクエスト/日・全プロジェクト合算）を2回焼いたことがある（CLAUDE.mdの恒久ルールに記録済み）。ループを設計するときの「回数」は、実行1回あたりのコストが小さくても、間隔をコードにハードコードした瞬間に再起動のたびに効いてくる。これは2030年のループエンジニアリングにもそのまま当てはまる教訓で、無人ループの費用は「1回の単価」ではなく「単価×自動で回る頻度」で見積もる必要がある。

### 責任 — 出荷したコードの責任は人間にある
🚫 IBMが挙げる4つの危険
・Unverified code — チェッカーもまたエージェントである。出荷したコードの責任は人間にある
・Comprehension debt — システム内のコード量と人間が理解している量の差。技術的負債は意図的な近道から生まれるが、これは受動的に溜まる。しかも自動テストを通ってしまうので静かに溜まる
・Intent debt — IBMが列挙する危険の一つ（本記事の資料範囲では詳細な定義文は未取得）
・Cognitive surrender — IBMが列挙する危険の一つ（本記事の資料範囲では詳細な定義文は未取得）

📎 Claudeの指摘 — comprehension debtはこの記事の制作過程でも起きた
comprehension debtは抽象論ではない。このループエンジニアリング記事のリサーチ過程そのものでも、Claudeが書いた数値に人間がすぐには気づけなかったという事例が記録されている（本記事の調査 §6）。技術的負債は「今は雑に作るが後で直す」という意図的な近道だが、comprehension debtは誰も意図せず、自動テストを通過するために発覚が遅れる。これはIBMの分類の中でも、ループエンジニアリングという仕組み自体が生み出す固有のリスクだと言える。

さとまた
AIがすべて自動で回るなら、検証も権限も費用も責任も、そのうちAIが自分で管理するようになるんじゃないの。

📎 Claudeの指摘
検証・権限・費用は技術的な改善で狭められる余地がある（evalsの精度が上がる、権限管理の粒度が細かくなる、トークン単価が下がる）。だが責任だけは技術で埋まらない。IBMが言うUnverified codeの構造——チェッカーもまたエージェントである——が続く限り、最終的な説明責任をAIに移すには、法制度や保険の側が「AIを責任主体とする」ことを認める必要がある。これは技術の進歩とは別軸の話で、第13章（この予測が外れる条件）の②規制・保険・契約の論点に直結する。

🤖 Codexの指摘
検証・権限・費用・責任の4つは独立していない。検証コストが生成コストを上回れば、企業は自動周回を限定工程へ戻す。これが私が挙げる予測が外れる最有力条件の一つである（第13章）。つまり「費用」が下がらない限り「検証」を十分な水準まで自動化する動機自体が弱まり、結果として「権限」を広げる判断も先送りされる。4つは輪になって互いを制約している。

✅ 事実としてどうなるか 判定: 支持される。検証・権限・費用・責任の4つは、それぞれ独立した根拠（統計的落とし穴・製品の権限設計・OpenAI公式ドキュメントのコスト明記・IBMの危険分類）を持ち、2026年時点でどれも解消されていない。根拠: Codexの見解 §3・§4、本記事の調査（権限設計）、本記事の調査。確信度: 高（4項目とも一次情報または公式ドキュメントに明記された事実に基づく）。これが覆る条件: ①AI主体の責任制度・保険が整備される ②トークン単価が現在の1/10以下まで下がり検証コストの比重が変わる ③evalsの精度が人間のレビューと同水準まで検証可能になる、のいずれかが観測された場合。

→ 次のSection 13では、この4つを踏まえて「この予測が外れるとしたら」を先に書く。反証条件を先に置くことで、次のSection 14の2030年像が単なる願望にならないようにする。

6/6　🎲 この予測が外れるとしたら

## 🎲 この予測が外れるとしたら
このセクションの3点
① 予測を書く前に、外れる条件を先に決めておく
② 外れ方は5つ。うち3つはCodexが最有力とした条件
③ 2028年に何を見れば判定できるかまで書く

2030年の予測を書く前に、先にこれを書いておきます。予測は当たるより外れるほうが多く、外れたときに気づけない予測は、方針の材料として最悪だからです。

各条件には「2028年に何を観測したら、外れたと判定するか」を付けました。2028年に、この記事を持ってきて答え合わせができるようにしてあります。

# | 外れ方 | なぜそうなるか | 2028年に何を見れば分かるか

1 | 検証コストが生成コストを上回る（Codexが最有力の1つに挙げた） | 長時間・多段のエージェントほど誤りが複合する。テストを通ってしまう誤仕様、comprehension debt、権限の悪用が増える。モデルの性能ではなく検証可能性がボトルネックになる | エージェントが書いたコードの差し戻し率と、本番障害のうちAI由来の割合。企業が自動周回を限定工程へ戻し始めたら、この条件が効いている
2 | 規制・保険・契約が人間の明示承認を要求する（Codexが最有力の1つに挙げた） | 個人情報・金融・医療・雇用・価格差別・セキュリティに関わる変更について、監査可能な人間承認が法的または保険上の条件になれば、技術的に可能でも制度的に閉じない | 2028年までに、AIによる自動変更に人間の承認記録を義務づける規制やガイドラインが出るか。逆にAI主体の責任制度と保険が整えば、予測より速く閉じる
3 | 企業データと目的関数をAIへ接続できない（Codexが最有力とした条件） | ログ・CRM・サポート・契約・原価・ブランド方針が分断されたまま、あるいは機密・品質・組織政治のため共有できなければ、AIのcontext advantageは埋まらない。モデルが賢くても、観測できず、権限が無く、成功条件が矛盾していれば回らない | 自社で、1つのエージェントがログとCRMと原価を同時に読める状態を作れているか。作れていない会社は2030年になっても閉じない
4 | コストが下がらない | ループは回数 × 単価で効く。OpenAI の Codex ドキュメントはサブエージェント構成は単一エージェントよりトークンを食うと明記している。周回数を増やすほど費用が線形以上に増える | 1つの改善を1周回すのにいくらかかるか。人間のエンジニア1時間の単価を超え続けるなら、全周回の自動化は経済的に成立しない
5 | 言葉のほうが先に消える | この記事の対象である「ループエンジニアリング」自体、2026年6月に生まれて7月には別の語（Graph Engineering）へ乗り換えたと報じられている。概念が定着せず、別の枠組みに吸収される可能性がある | 2028年に「ループエンジニアリング」で検索して、実務の文書（社内規程・求人票・製品ドキュメント）に残っているか。バズワードとして消えていれば、この記事の枠組み自体が古い

外れ方には2方向あることに注意する
上の5つは「思ったより閉じない」方向の外れ方です。しかし逆方向にも外れます。

Codex が書いていたとおり、AI主体の責任制度と保険が整えば、私の予測より速く閉じます。いま「人間に残る」と判定している②暗黙の価値判断・④探索権限・⑤責任は、能力の限界ではなく制度の未整備で残っているものです。制度が先に動けば、能力を待たずに移ります。

つまりこの予測が外れるとき、「AIがまだ賢くないから外れる」のではなく、「制度がどう動いたかで外れる」可能性のほうが高い。方針を決める側にとっては、モデルの進歩より、規制と保険と契約を見ているほうが早いということになります。

外れ方は2方向ある。片方しか見ていないと、対策を間違える
思ったより閉じない方向
技術と経済が止める

- ・検証コストが生成コストを上回る。誤りが複合し、差し戻しが増える

- ・コストが下がらない。ループは回数×単価で効き、サブエージェントは単一より食う

- ・データと目的関数を接続できない。ログ・CRM・原価が分断されたまま（Codexが最有力とした条件）

- ・対策は検証の自動化と、データの接続に投資すること

思ったより速く閉じる方向
制度が動かす

- ・AI主体の責任制度と保険が整う。能力ではなく制度が委任を可能にする

- ・いま人間に残ると判定した暗黙の価値判断・探索権限・責任は、能力の限界ではなく制度の未整備で残っている

- ・制度が先に動けば、能力を待たずに移る

- ・対策は規制・保険・契約の動きを見ておくこと。モデルの進歩を見ているより早い

→ 次のSection 14では、外れる条件を踏まえたうえで、2030年の完成形を逃げずに書く。

## 🌅 2030年の完成されたループエンジニアリング
このセクションの3点
① 2030年、人間が触るのは1日2回。異常日で3〜5回
② AIは1人の万能社員ではなく、権限の違う6人の常駐担当になる
③ 人間の仕事は、最適化してよい範囲を定義することになる

ここからは予測です。事実ではありません。前章の5つの外れ方を踏まえたうえで、逃げずに具体的に書きます。「〜かもしれない」を並べても方針の材料にならないからです。

回数や時刻はClaudeと Codex の見立てであり、実測ではありません。ただし、それぞれなぜその数字になるかの理由を付けてあります。

### 2030年、ある平日の1日

- 1 00:20

#### 観測担当が夜間のログを畳む
エラー、遅延、セッション、離脱、問い合わせ、コストをイベント駆動で読む。人間は起きていない。異常が閾値を超えたときだけ通知が積まれる

- 2 01:40

#### 分析担当が異常と改善候補を出す
「決済の3画面目で離脱が前週比+12%」「特定のブラウザだけ描画が遅い」。ここまでは全部データ処理で、価値判断はまだ入っていない

- 3 02:30

#### 実験担当が小さな実験を組む
事前登録された指標、サンプルサイズ、停止条件、ガードレール（解約率・サポート問い合わせ数）つき。人間が前日に配った探索予算の範囲内でしか組めない

- 4 03:10

#### 実装担当が worktree で変更する
本体には触らない。隔離された作業ツリーで、並列に3案を書く

- 5 04:00

#### 検証担当が別人格で確認する
書いた本人ではないmaker/checker 構造。テスト、セキュリティ、アクセシビリティ、性能。ここで2案が落ちる

- 6 05:30

#### リリース担当が1%に出す
1% → 10% → 50% → 100% の段階展開。ガードレール違反で自動ロールバック。この時点でも人間は寝ている

- 7 09:00

#### 人間の1回目（15〜30分）
夜間に何が展開され、何が棄却され、いまリスク予算がどれだけ残っていて、何が承認待ちかを見る。低リスクの変更はすでに本番にある。人間が見るのは例外だけ

- 8 09:30〜17:00

#### 日中、ループは回り続ける
人間は会議をしたり顧客と話したりしている。その間に7〜20周まわる。人間が知るのは、閾値を超えたものだけ

- 9 17:30

#### 人間の2回目（30〜60分）
目的関数を変える候補を承認・却下する。価格、対象顧客、データ利用、ブランド、ロードマップ。そして翌日の探索予算を配る。ここが1日でいちばん重い30分

- 10 （異常時）

#### 臨時介入が1〜3回入る
障害、法的・安全上の閾値超過、想定外の指標の動き。通常2回、異常日は3〜5回。回数は減るが、残った案件は曖昧で影響が大きく、説明責任が重いものへ濃縮されている

### AIは1人ではなく、権限の違う6人になる
担当 | 何をするか | 与えられる権限 | 人間に上げる境界

観測担当 | ログ・エラー・セッション・コスト・問い合わせを読む | 読み取りのみ | 上げない（データを渡すだけ）
分析担当 | 異常検知と改善候補の生成 | 読み取りのみ | 既存指標の外に出る仮説を出したとき
実験担当 | 実験設計・配信・統計判定 | 探索予算の範囲内でのみ配信可 | 対象者が新しい層のとき、影響が不可逆なとき
実装担当 | worktree でコードを書く | 本体ブランチには触れない | 依存関係・データ構造の変更
検証担当 | テスト・セキュリティ・性能・アクセシビリティ | マージを止める権限 | 2回連続で同じ落とし方をしたとき
リリース担当 | 段階展開とロールバック | 可逆な変更は無人／破壊的変更は二者承認 | データ削除、認証、課金、個人情報に触れる変更

2030年の1日 — 人間が触る2点 → この図は横にスクロールできます
2030年 — ループは24時間まわり、人間が触るのは2点だけ
- 0時9時17時24時AIが自走している区間（観測・分析・実験・実装・検証・段階展開）人間の1回目 09:0015〜30分。例外だけを見る
- 人間の2回目 17:3030〜60分。目的関数を決める翌日の探索予算を配る
- 1日の周回数の見立て: 7〜20周。人間が見るのは閾値を超えたものだけ

横軸は1日24時間。太い帯がAIの自走区間、縦線が人間の介入点。図はClaudeとCodexの見立てであり、実測ではない。
2030年、人間の職務はこう変わる
Codex の言葉を借りれば、2030年の中心職務は「プロンプトを書くこと」でも「コードを全行読むこと」でもなく、AIが最適化してよい範囲と、最適化してはいけない価値を定義することになります。

具体的には、人間がレビューする対象が個々のPRから、ポリシー・eval・予算・権限・停止条件へ移ります。1つ1つの変更を見るのをやめ、「どういう変更なら見なくてよいか」というルールのほうを見るということです。

職種名で言えば、消えるのは「実装だけをする人」「定型レビューだけをする人」「手で監視している人」。残るのは「何を作るかを決める人」「成功の定義を決める人」「止める権限を持つ人」。そして残る仕事は、人数を必要としません。

ここに、この記事でいちばん言いにくい結論があります。ループが閉じることと、雇用が減ることは、同じ現象の裏表です。回す仕事が消え、決める仕事だけが残るなら、必要な人数は決める人の数まで縮みます。第15章の方針は、そこまで見たうえで決めるべきものです。

✅ 事実としてどうなるか（この章の位置づけ）

判定: これは予測であり、事実ではない。ここに書いた時刻・回数・担当の数は、ClaudeとCodexの見立てである。

根拠として使えるのは次まで: ①IBMが挙げるループの8部品はすでに全部実在する（さとまたの環境にも全部ある）②Ngの実例で、エージェントはすでに約1時間無介入で働いている③段階展開と自動ロールバックはいまの製品で実現できる。

推測なのは: 人間が1日2回になること、6担当という構成、周回数7〜20。これらの数字を実測した資料は無い。

確信度: 低。2030年の話であり、第13章の5条件のどれかが起きれば形が変わる。

→ 最後のSection 15では、この判定から会社として何を決めるかを書く。

## 📌 会社の方針として何を決めるか
このセクションの3点
① 判定から導かれる決定を12個、決めた形で書く
② 自動化してよい工程と、絶対に自動化しない判断を分ける
③ 2028年に何を見て見直すかまで先に決めておく

ここまでの判定を、決定に落とします。依頼者の言葉で言えば「これは会社の方針にして方向性を決定していく」ためのものです。

「検討する」で終わらせません。いま決められることは決めた形で書き、決められないものは「いつ・何を見て決めるか」まで書きます。そのほうが、決めていないことが自分で分かるからです。

6
いま自動化してよいと決めた工程

4
人間の承認を制度として残す工程

2
自動化しないと決めた判断

2028年
方針を見直す時点

決めること | 決定 | どの判定から来たか | いつ見直すか

実装・テストを自動化するか | する。いますぐ。人が1行ずつ書くのをやめ、レビューと受け入れ基準の側に人を置く | 論点4は支持される。Ngの実例で約1時間の無介入、Copilot Autofix のコアはGA | 見直さない（既定の運用にする）
コードレビューを自動化するか | する。ただし人間の承認は残す。AIレビューは必須にし、マージ権限は人が持つ | 論点5。Vercel Agent はPublic Beta・既定 read-only。製品側が承認前提で設計されている | 2027年。AIレビューの見逃し率を実測してから
デプロイをどこまで無人にするか | 可逆な変更は無人。破壊的変更は二者承認。データ削除・認証・課金・個人情報に触れる変更は必ず人 | 論点5と第12章の「権限」。Codexの「可逆／不可逆で段階化」 | 事故が1件でも起きた時点
監視・障害対応を任せるか | 既知の障害は任せる。未知の障害は通知だけ。復旧の自動実行は、ロールバック手段があるものに限る | 論点6は半分支持。closed-loop製品は実在するが対象限定 | 2027年
ログ・ヒートマップ分析を任せるか | 任せる。人が目で見るのをやめる。ただし何を見るかの指定は人が書く | 論点7は支持される。これはデータ処理であって価値判断ではない | 見直さない
仮説立案を任せるか | 既存指標の改善仮説は任せる。指標そのものを変える仮説は人が出す。この線を運用ルールに書く | 論点8は半分支持。目的関数の外にある仮説は出てこない | 2028年
A-Bテストを自動で回すか | 実行と統計判定は自動。実験の承認は人。新しい顧客層・不可逆な影響・個人データに触れる実験は必ず承認を通す | 論点9。統計の罠（多重検定・早期停止・干渉）と倫理は別問題 | 2027年
目的関数（何を成功と呼ぶか）を誰が決めるか | 人。絶対に自動化しない。四半期に1回、明文で見直す | 第11章の結論。データの中に答えが無い唯一の項目 | 見直さない（この決定自体を固定する）
探索予算（1日にいくらまで実験に使ってよいか） | 金額で上限を決め、超えたら自動停止。1日あたりの上限を先に決め、エージェントに渡す | 第12章の「費用」。ループは回数×単価。サブエージェントは単一より食う | 毎月。実績で調整
comprehension debt をどう測るか | 「本番コードのうち、社内の誰も読んでいない割合」を四半期で測る。測っていない指標は増え続ける | IBMの4つの危険。自動テストを通ってしまうので静かに溜まる | 四半期ごと
止めるボタンを誰が持つか | 1人に持たせる。持ち回りにしない。全エージェントを止める権限と手順を1枚に書き、その人が持つ | 第12章の「責任」。出荷物の責任は人間にある | 見直さない
2028年に何を見て方針を見直すか | 3つを観測する。①AI由来の本番障害の割合 ②1改善あたりのAI費用 vs エンジニア1時間の単価 ③自動変更に人間の承認記録を求める規制が出たか | 第13章の外れる条件 | 2028年に必ず

今日から着手できるもの（部品はすでに手元にある）
− 停止条件を書く。「テストが全部通り、要求を満たしたら止まる」まで書く。「速くして」では止まらない
IBMが挙げる良い目標・悪い目標の差はここ

✓ maker/checker を分ける。書いたエージェントに確認させない。検証専任を別に立てる
このハブには implementer と reviewer が別々にある

✓ worktree で隔離する。本体ブランチに直接触らせない
.claude/worktrees がすでにある

✓ hooks で門番を置く。秘密情報の混入、危険なコマンド、main への直接コミットを機械で止める
PreToolUse / PostToolUse のcommand型フックが稼働中

✓ 持続する記憶を持つ。周回の結果を書き足し、同じ失敗を繰り返さない
NEXT.md がその役をしている

− 費用の上限を先に決める。1日いくらまで、を金額で
Cloudflare無料枠を2回焼いた経験がある。上限は感覚ではなく数字で

− 読んでいないコードの割合を測り始める
測らないと増えていることに気づけない

− 目的関数を明文にする。何を成功と呼ぶかを1枚に書く
これが無いと、AIは指標を上げて事業を痛める

この方針の背骨は1行
回す仕事はすべて渡す。決める仕事は渡さない。

この記事の12工程の判定を1行にすると、これになります。2015年に「人」だった10工程のうち8つは、2030年までにAIへ移ります。しかし残る2つ——何を作るかと、何を成功と呼ぶか——は、AIが賢くなったから移るものではなく、組織が明示的に委任したときだけ移ります。

だから方針として決めるべきなのは「AIをどこまで使うか」ではありません。「何を渡さないと決めるか」です。渡さないものを先に決めておかないと、部品はすでに全部揃っているので、成り行きで全部渡ってしまいます。

→ 最後のSection 16に、全文コピーとこの記事の限界を置く。