TL;DR · 2026年6月、複数のAIプログラミング実践者がほぼ同時にLoop Engineeringを提唱し、StripeはMinionsで毎週1300以上のAI生成PRをマージしている。 · この手法は人間が逐次プロンプトを送るのではなく、システムが自動的にタスクを発見・引き継ぎ・検証・状態保存し、次のラウンドに進むようにする。 · 信頼性は依然として独立した評価器、厳格なゲート、人間によるレビューに依存しており、検証負債と理解力の低下が逆にリスクを増幅する可能性がある。
先日、Anthropicのエンジニアが「エージェントシステムのループエンジニアリング」に関する11ページの資料を公開し、Loop EngineeringをPrompt Engineering、Context Engineering、Harness Engineeringに続く、AIプログラミングが次の段階に入るための重要な手法として位置づけた。
この資料が注目を集めたのは、2026年6月のAIプログラミング議論の転換点に合致したからだ。Addy Osmani、Boris Cherny、Peter Steinbergerはほぼ同じ週に、AIプログラミングの新段階をLoop Engineeringと呼び、StripeのMinionsパイプラインは同様のアプローチで毎週1300以上のAI生成Pull Requestをマージしている。
この数字が重要なのは、AIがさらに数行のコードを書いたからではなく、ソフトウェア開発の重心が「人間がモデルに何を書くか指示する」から「人間が、自動的にキューに並び、タスクを取得し、コードを書き、結果を検証し、状態を保存し、実行を継続するシステムを設計する」へと移行しているからだ。
この1年、AIプログラミングツールの語りは主にモデルの能力、つまりコード補完の精度向上、コンテキストウィンドウの拡大、エージェントが複雑なタスクを一度に完了できることなどに焦点が当てられてきた。しかしLoop Engineeringが議論しているのは別のことだ：コード生成自体がますます低コストになるにつれ、エンジニアが本当に設計すべきなのは、持続可能に稼働するループである。機械は絶えず候補ソリューションを生成でき、人間はどの結果が信頼できるか、どれを阻止すべきか、どのような長期的コストが隠されているかを判断する。
先日、Anthropicのエンジニアが「エージェントシステムのループエンジニアリング」に関する11ページの資料を公開し、Loop EngineeringをPrompt Engineering、Context Engineering、Harness Engineeringに続く、AIプログラミングが次の段階に入るための重要な手法として位置づけた。この記事はまさにこの資料を切り口に、Boris Cherny、Addy Osmaniらの公開討論、およびStripeのMinionsが毎週1300以上のAI生成PRをマージする事例を組み合わせ、Loop Engineeringとは何か、なぜ突然ネットで議論されるようになったのか、そしてそれが本当に変えるのはコードを書くことではなく、ソフトウェア開発における検証、スケジューリング、判断であることを解説する。
Loop Engineeringは、Prompt Engineering、Context Engineering、Harness Engineeringに続く、AIエンジニアリングスタックの第4層として位置づけられる。
Prompt Engineeringが解決するのは「どう質問するか」、Context Engineeringは「モデルに何を見せるか」、Harness Engineeringは「一回のモデル実行をツール、テスト、ワークフローに接続する方法」である。Loop Engineeringはさらに一歩進む：システムはタスクを一回実行するだけでなく、一定時間後またはトリガー条件で再起動し、前回の結果を次のラウンドの入力として利用できる。
完全なループは通常、5つのアクションで構成される。
第一に作業の発見：CIの失敗、オープンIssue、コードコミット、保留タスクなどをスキャンする。第二にタスクの引き継ぎ：タスクをモデルが処理できるコンテキストに整理する。第三に独立検証：モデルが生成したコードが実際に動作するか、テストに合格するか、副作用を引き起こすかを確認する。第四に結果の永続化：状態、判断、未完了事項をファイルやシステムに書き込む。第五にループのスケジューリング：次のラウンドを適切なタイミングで実行し続けるようにする。
ここで最も重要なのは「生成」ではなく「検証」である。ループが単にモデルにコードを書き続けさせ、同じモデルに自分の結果を褒めさせるだけならば、それは「うなずきループ」になりやすい：毎回進んでいるように見えて、実際にはエラーをより完全に包装しているだけだ。
Osmani自身の朝のトリアージループは個人向けの例である：システムは毎日自動的に前日のCI失敗テスト、オープンIssue、最近のコミットを読み込み、ステータスファイルを生成し、処理できない事項を人間の受信トレイに入れる。その価値は、エンジニアの代わりにすべての決定を下すことではなく、エンジニアが目覚める前に一次スクリーニングを完了し、真に判断が必要な部分に注意を集中させることにある。
StripeのMinionsパイプラインは、今回の議論で最も衝撃的な企業事例である：毎週1300以上のAI生成Pull Requestをマージし、コード自体は人間が一行ずつ書いていない。
しかしこれは、Stripeが本番システムを大規模言語モデルに自由に委ねているということではない。逆に、Minionsの鍵は高度に制御されたプロセスにある：決定論的オーケストレーターがまずコンテキストを組み立て、Jira、コード検索、内部ツールからタスク情報を抽出する。LLMがコードを生成する。その後、ハードコードされたlinter、コミットゲート、最終的な人間によるレビューを経てマージの可否が決定される。
言い換えれば、信頼性は「モデルが突然十分に賢くなった」からではなく、一連の制約から生まれている。モデルは変更の候補を提案し、システムはそれが触れる範囲と通過すべきチェックを制限し、人間は最終的に本流に取り込むかどうかを判断する。
これこそが、Loop Engineeringと通常のAIプログラミングスクリプトとの違いである。通常のスクリプトは「モデルにタスクを完了させる」ことに重点を置く。ループシステムは、タスクがどこから来るか、失敗した場合の処理、状態の保持方法、予算の管理、エラーが本番環境に入るのを防ぐ方法を考慮しなければならない。
これらの制約がなければ、毎週1300のPRは効率の飛躍ではなく、技術負債の製造機になりかねない。
Loop Engineeringの中核的な設計の一つは、生成器と評価器を分離することである。
生成器はコードの作成、ファイルの変更、候補結果の提出を担当する。評価器はエラーを発見する責任を持ち、理想的にはコードに問題があると仮定するのがよい。両者を同じ「楽観的エージェント」に任せるべきではない。なぜなら、モデルは自己評価の際、特にタスク記述が曖昧、テストカバレッジが不十分、またはコンテキストが不完全な場合に、自分の出力を承認する傾向があるからだ。
独立した評価器はよりシンプルで、より懐疑的で、調整も容易である。創造的に問題を解決する必要はなく、ページが開くか、テストが通るか、境界条件が破られていないか、コードが所定のルールに従っているかを検証すればよい。一部の実践では、評価器がブラウザ自動化ツールを使って実際にページをクリックするようにし、コードを読むだけでの判断を避ける。
これが、「検証」が5ステップのループで最も難しい部分である理由を説明している。コード生成はますます安価になっているが、コードが本当に正しいことを証明するのは依然として高価である。特に大規模なコードベースでは、エラーがすぐに表面化せず、テストが実際のビジネスパスをカバーしていないこともある。ループの回転が速いほど、検証されていない仮定の蓄積も速くなる。
Loop Engineeringのリスクは、コードを誤って書くことではなく、チームが自分たちの理解を失っていることに気づきにくくなることにある。
第一のコストは検証負債である。テストでカバーされていないエラーはループ内で累積され、あるマージやリリースの際に集中爆発する。第二は理解力の低下である。コードベースは拡大し続けるが、エンジニアは重要な設計選択を自ら経験しておらず、メンタルマップは旧バージョンに留まる。第三は認知投降である。人間は機械の出力をデフォルトで受け入れ、形式的な承認のみを行うようになる。第四はトークン消費の爆発である。リトライ、サブエージェント、長いコンテキスト、多段検証により、請求額が急上昇する。
これら4つのコストは相互に餌を与え合う：テスト不足が検証負債を生み、検証負債が増えるとエンジニアはさらに深く理解しようとしなくなり、理解の低下が人間によるレビューをゴム印と化し、ゴム印レビューがさらに多くの自動リトライと高いコストを促進する。
したがって、同じループコンポーネントでも、エンジニアによって全く逆の結果を生む可能性がある。判断力が強く、境界が明確な人は、ループを使ってシステムへの理解を増幅し、機械を疲れを知らない実行層として活用できる。判断力が弱いか自動化に過度に依存する人は、数ヶ月後には自分自身のシステムの「門番」となり、承認または拒否しかできず、なぜシステムがそのように動作するのか説明できなくなる。
Loop Engineeringは、長期的なトレンドをより明確な位置に押し出す：コード、計画、PR、タスク分解はほぼ無料になりつつあるが、「本当に正しいこと」は安くなっていない。
企業にとって、これはAIプログラミングへの投資の重点が、より強力なモデルの購入から、より安定したプロセスの設計へと移行する可能性があることを意味する：タスク境界、コンテキストアセンブリ、独立評価、状態永続化、予算上限、人間によるレビューポイント、および異常発生時のループ停止方法。モデルの能力は依然として重要だが、それはシステムの一部に過ぎない。
エンジニアにとっても、役割は変化している。かつての中心的な労働はコードを書くことであったが、今ではますます、機械が生成した候補回答をレビューする労働に変わっている：要件に合致しているか、アーキテクチャを破壊していないか、単に妥当に見えるだけか、将来のメンテナーに複雑性を押し付けていないか。
これはプログラマーがすでに置き換えられたことを意味しない。むしろ、Loop Engineeringは判断力を増幅する装置のようなものである。一人のエンジニアがかつて小規模チームでなければ達成できなかった量の変更を実現できる一方、怠惰、盲信、検証不足の習慣を生産事故に拡大することもある。
本当の分岐点は、人間が依然として十分強い判断力と拒否権を保持しているかどうかにある。AIはPRを提出し続けることができるが、マージできるかどうか、リリースすべきかどうか、長期的にシステムを崩壊させるかどうかは、依然として人間次第である。
クリックして律動BlockBeatsの募集職種を確認する
律動 BlockBeats 公式コミュニティへようこそ：
Telegram 購読グループ：https://t.me/theblockbeats
Telegram 交流グループ：https://t.me/BlockBeats_App
Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia
1.49M 人気度
378.77M 人気度
62.86K 人気度
310.4K 人気度
2.2M 人気度
ネット中で話題のLoop Engineering、一体何を変えたのか？
先日、Anthropicのエンジニアが「エージェントシステムのループエンジニアリング」に関する11ページの資料を公開し、Loop EngineeringをPrompt Engineering、Context Engineering、Harness Engineeringに続く、AIプログラミングが次の段階に入るための重要な手法として位置づけた。
この資料が注目を集めたのは、2026年6月のAIプログラミング議論の転換点に合致したからだ。Addy Osmani、Boris Cherny、Peter Steinbergerはほぼ同じ週に、AIプログラミングの新段階をLoop Engineeringと呼び、StripeのMinionsパイプラインは同様のアプローチで毎週1300以上のAI生成Pull Requestをマージしている。
この数字が重要なのは、AIがさらに数行のコードを書いたからではなく、ソフトウェア開発の重心が「人間がモデルに何を書くか指示する」から「人間が、自動的にキューに並び、タスクを取得し、コードを書き、結果を検証し、状態を保存し、実行を継続するシステムを設計する」へと移行しているからだ。
この1年、AIプログラミングツールの語りは主にモデルの能力、つまりコード補完の精度向上、コンテキストウィンドウの拡大、エージェントが複雑なタスクを一度に完了できることなどに焦点が当てられてきた。しかしLoop Engineeringが議論しているのは別のことだ：コード生成自体がますます低コストになるにつれ、エンジニアが本当に設計すべきなのは、持続可能に稼働するループである。機械は絶えず候補ソリューションを生成でき、人間はどの結果が信頼できるか、どれを阻止すべきか、どのような長期的コストが隠されているかを判断する。
先日、Anthropicのエンジニアが「エージェントシステムのループエンジニアリング」に関する11ページの資料を公開し、Loop EngineeringをPrompt Engineering、Context Engineering、Harness Engineeringに続く、AIプログラミングが次の段階に入るための重要な手法として位置づけた。この記事はまさにこの資料を切り口に、Boris Cherny、Addy Osmaniらの公開討論、およびStripeのMinionsが毎週1300以上のAI生成PRをマージする事例を組み合わせ、Loop Engineeringとは何か、なぜ突然ネットで議論されるようになったのか、そしてそれが本当に変えるのはコードを書くことではなく、ソフトウェア開発における検証、スケジューリング、判断であることを解説する。
AIプログラミングが「一回のプロンプト」から「継続的なループ」へ
Loop Engineeringは、Prompt Engineering、Context Engineering、Harness Engineeringに続く、AIエンジニアリングスタックの第4層として位置づけられる。
Prompt Engineeringが解決するのは「どう質問するか」、Context Engineeringは「モデルに何を見せるか」、Harness Engineeringは「一回のモデル実行をツール、テスト、ワークフローに接続する方法」である。Loop Engineeringはさらに一歩進む：システムはタスクを一回実行するだけでなく、一定時間後またはトリガー条件で再起動し、前回の結果を次のラウンドの入力として利用できる。
完全なループは通常、5つのアクションで構成される。
第一に作業の発見：CIの失敗、オープンIssue、コードコミット、保留タスクなどをスキャンする。第二にタスクの引き継ぎ：タスクをモデルが処理できるコンテキストに整理する。第三に独立検証：モデルが生成したコードが実際に動作するか、テストに合格するか、副作用を引き起こすかを確認する。第四に結果の永続化：状態、判断、未完了事項をファイルやシステムに書き込む。第五にループのスケジューリング：次のラウンドを適切なタイミングで実行し続けるようにする。
ここで最も重要なのは「生成」ではなく「検証」である。ループが単にモデルにコードを書き続けさせ、同じモデルに自分の結果を褒めさせるだけならば、それは「うなずきループ」になりやすい：毎回進んでいるように見えて、実際にはエラーをより完全に包装しているだけだ。
Osmani自身の朝のトリアージループは個人向けの例である：システムは毎日自動的に前日のCI失敗テスト、オープンIssue、最近のコミットを読み込み、ステータスファイルを生成し、処理できない事項を人間の受信トレイに入れる。その価値は、エンジニアの代わりにすべての決定を下すことではなく、エンジニアが目覚める前に一次スクリーニングを完了し、真に判断が必要な部分に注意を集中させることにある。
Stripeの1300のPR：信頼性はモデルではなく制約から生まれる
StripeのMinionsパイプラインは、今回の議論で最も衝撃的な企業事例である：毎週1300以上のAI生成Pull Requestをマージし、コード自体は人間が一行ずつ書いていない。
しかしこれは、Stripeが本番システムを大規模言語モデルに自由に委ねているということではない。逆に、Minionsの鍵は高度に制御されたプロセスにある：決定論的オーケストレーターがまずコンテキストを組み立て、Jira、コード検索、内部ツールからタスク情報を抽出する。LLMがコードを生成する。その後、ハードコードされたlinter、コミットゲート、最終的な人間によるレビューを経てマージの可否が決定される。
言い換えれば、信頼性は「モデルが突然十分に賢くなった」からではなく、一連の制約から生まれている。モデルは変更の候補を提案し、システムはそれが触れる範囲と通過すべきチェックを制限し、人間は最終的に本流に取り込むかどうかを判断する。
これこそが、Loop Engineeringと通常のAIプログラミングスクリプトとの違いである。通常のスクリプトは「モデルにタスクを完了させる」ことに重点を置く。ループシステムは、タスクがどこから来るか、失敗した場合の処理、状態の保持方法、予算の管理、エラーが本番環境に入るのを防ぐ方法を考慮しなければならない。
これらの制約がなければ、毎週1300のPRは効率の飛躍ではなく、技術負債の製造機になりかねない。
生成器と評価器は分離しなければならない
Loop Engineeringの中核的な設計の一つは、生成器と評価器を分離することである。
生成器はコードの作成、ファイルの変更、候補結果の提出を担当する。評価器はエラーを発見する責任を持ち、理想的にはコードに問題があると仮定するのがよい。両者を同じ「楽観的エージェント」に任せるべきではない。なぜなら、モデルは自己評価の際、特にタスク記述が曖昧、テストカバレッジが不十分、またはコンテキストが不完全な場合に、自分の出力を承認する傾向があるからだ。
独立した評価器はよりシンプルで、より懐疑的で、調整も容易である。創造的に問題を解決する必要はなく、ページが開くか、テストが通るか、境界条件が破られていないか、コードが所定のルールに従っているかを検証すればよい。一部の実践では、評価器がブラウザ自動化ツールを使って実際にページをクリックするようにし、コードを読むだけでの判断を避ける。
これが、「検証」が5ステップのループで最も難しい部分である理由を説明している。コード生成はますます安価になっているが、コードが本当に正しいことを証明するのは依然として高価である。特に大規模なコードベースでは、エラーがすぐに表面化せず、テストが実際のビジネスパスをカバーしていないこともある。ループの回転が速いほど、検証されていない仮定の蓄積も速くなる。
隠れたコストは相互に強化される
Loop Engineeringのリスクは、コードを誤って書くことではなく、チームが自分たちの理解を失っていることに気づきにくくなることにある。
第一のコストは検証負債である。テストでカバーされていないエラーはループ内で累積され、あるマージやリリースの際に集中爆発する。第二は理解力の低下である。コードベースは拡大し続けるが、エンジニアは重要な設計選択を自ら経験しておらず、メンタルマップは旧バージョンに留まる。第三は認知投降である。人間は機械の出力をデフォルトで受け入れ、形式的な承認のみを行うようになる。第四はトークン消費の爆発である。リトライ、サブエージェント、長いコンテキスト、多段検証により、請求額が急上昇する。
これら4つのコストは相互に餌を与え合う：テスト不足が検証負債を生み、検証負債が増えるとエンジニアはさらに深く理解しようとしなくなり、理解の低下が人間によるレビューをゴム印と化し、ゴム印レビューがさらに多くの自動リトライと高いコストを促進する。
したがって、同じループコンポーネントでも、エンジニアによって全く逆の結果を生む可能性がある。判断力が強く、境界が明確な人は、ループを使ってシステムへの理解を増幅し、機械を疲れを知らない実行層として活用できる。判断力が弱いか自動化に過度に依存する人は、数ヶ月後には自分自身のシステムの「門番」となり、承認または拒否しかできず、なぜシステムがそのように動作するのか説明できなくなる。
コードが安くなれば、高価になるのは判断
Loop Engineeringは、長期的なトレンドをより明確な位置に押し出す：コード、計画、PR、タスク分解はほぼ無料になりつつあるが、「本当に正しいこと」は安くなっていない。
企業にとって、これはAIプログラミングへの投資の重点が、より強力なモデルの購入から、より安定したプロセスの設計へと移行する可能性があることを意味する：タスク境界、コンテキストアセンブリ、独立評価、状態永続化、予算上限、人間によるレビューポイント、および異常発生時のループ停止方法。モデルの能力は依然として重要だが、それはシステムの一部に過ぎない。
エンジニアにとっても、役割は変化している。かつての中心的な労働はコードを書くことであったが、今ではますます、機械が生成した候補回答をレビューする労働に変わっている：要件に合致しているか、アーキテクチャを破壊していないか、単に妥当に見えるだけか、将来のメンテナーに複雑性を押し付けていないか。
これはプログラマーがすでに置き換えられたことを意味しない。むしろ、Loop Engineeringは判断力を増幅する装置のようなものである。一人のエンジニアがかつて小規模チームでなければ達成できなかった量の変更を実現できる一方、怠惰、盲信、検証不足の習慣を生産事故に拡大することもある。
本当の分岐点は、人間が依然として十分強い判断力と拒否権を保持しているかどうかにある。AIはPRを提出し続けることができるが、マージできるかどうか、リリースすべきかどうか、長期的にシステムを崩壊させるかどうかは、依然として人間次第である。
クリックして律動BlockBeatsの募集職種を確認する
律動 BlockBeats 公式コミュニティへようこそ：
Telegram 購読グループ：https://t.me/theblockbeats
Telegram 交流グループ：https://t.me/BlockBeats_App
Twitter 公式アカウント：https://twitter.com/BlockBeatsAsia