2026年7月、AIプログラミング分野で大きな転換が起こった。Peter SteinbergerがXプラットフォームで、ループエンジニアリング時代の終焉を発表し、業界をグラフエンジニアリングへと導いた。ループエンジニアリングはGeoffrey HuntleyのRalph手法に由来し、AIエージェントが目標達成まで継続して実行されることでコンテキストウィンドウの制限を回避するものだった。2026年4月から5月にかけて、CodexやClaude Codeなどのツールが次々とGoal機能を導入し、ループの製品化を実現した。現在、業界は組織グラフとワークグラフの協調設計を含む、より複雑なグラフエンジニアリングの探求を進めている。記事執筆者、出典：微信公众号InfoQ（ID：infoqchina）
まだ循環について議論しているのか、すでに図に移ったのか？
2026年7月18日、ピーター・スタインバーガーはXプラットフォームでこの一文を投稿し、循環工学時代の終焉を静かに告げた。この投稿は公開後2日間で260万回の閲覧を記録した。
6週前、彼は「エージェントを誘導するためのループ設計」で840万回の閲覧を獲得し、世界中の開発者に、プロンプトエンジニアリングの時代が終わり、ループエンジニアリングが新たな方向であることを気づかせた。
2つの投稿の合計閲覧数は1,100万回を超え、AIプログラミング分野で最も話題になっている議論を次の段階へと導いた。
循環の台頭
過去1か月で、「Loop Engineering（ループエンジニアリング）」はAIプログラミング分野で急激に注目される概念となった。
しかし、その真の起源は1年前にさかのぼる。2025年7月、ソフトウェアエンジニアのGeoffrey Huntleyが、「Ralph」と称する方法を提案した——これは、目標が達成されるまでClaudeに繰り返しタスクを実行させるシンプルなBashループだった：
while :; do cat PROMPT.md | claude-code ; done
ラルフ手法の核心は、コンテキストウィンドウの制限を回避することである。当時は2025年中期で、コンテキストウィンドウの最大値は20万トークンであった。これはより複雑なタスクには十分でなかったため、エージェントの実行をより小さな実行単位に分割し、順次実行する必要があった。
このような背景において、Ralph方法の動作は以下の通りです：
- プロジェクトに目標を設定し、その目標が達成されるまでAgentを継続して実行または再実行してください。
- 完了した作業を、ログや更新された計画などの形式でファイルシステムに圧縮して永続化します。
- 新しいコンテキストを使用してAgentを起動し、コンテキストの劣化を最小限に抑えます。
- 必要に応じて、各エージェントが「全体計画」を追加または変更することを許可します。
ハントリーはこの方法でプログラミング言語をゼロから構築し、可能性を実証したが、より強力なモデルが登場するまで、開発者コミュニティでは広く知られることはなかった。
Loopの爆発的ヒットには、AnthropicやOpenAIの核心的な開発者たちも大きく貢献している。最初はAnthropicの開発者会議で、Claude Codeの開発者であるBoris Chernyが「私はもうClaudeにプロンプトを入力しない。私はループを実行し、それらのループがClaudeにプロンプトを出し、次に何をすべきかを判断している。私の仕事はループを書くことだ」と述べた。
その後、ピーター・シュタインベルガーも投稿し、開発者に対してプログラミングエージェントに直接プロンプトを送るのをやめるよう呼びかけました。「毎月のお知らせ：あなたはもはやプログラミングエージェントに直接プロンプトを送るべきではありません。エージェントにプロンプトを送るサイクルを設計すべきです。」
元GoogleエンジニアのAddy Osmaniは、その後「ループエンジニアリング」と題した記事を執筆し、これを次のように要約した。「ループエンジニアリングとは、自らAgentにプロンプトを送る立場から離れ、代わりにその作業を自動で完了させるシステムを設計することである。」
コンセプトはでき、名前も決まり、インフラも迅速に整備されました。
2026年4月から5月にかけて、Codex、Claude Code、Hermesが次々と/goalコマンドを導入し、手作業で作成されたループを1つのコマンドに統合した。
ラルフが広く導入されてから約6か月後、Codexはgoal機能をリリースしました
Codexドキュメントには、「GoalsはCodex内で永続的な目標であり、対話スレッドが複数のインタラクションにわたり明確な結果へと継続的に進むことを可能にします。GoalはCodexに完了条件を提供します：どの状態が成立すべきか、成功の確認方法、および常に維持されるべき制約です。」
ドキュメントは明確に指摘しています：「通常のプロンプトは『次にこの作業を実行する』ことを示し、Goalは『この結果が達成されるまで作業を継続する』ことを示します。」
通常のリクエストでは、Codexは現在の指示を処理し、結果を報告した後、次のステップを待ちます。Goalを使用する場合、スレッドには永続的な目標が付与されます。1ラウンドの実行が終了した後、Codexは現在の証拠を確認し、目標が達成されたかどうかを判断できます。答えが否定的であり、Goalがまだ有効で予算が残っている場合、Codexは最新の状態から作業を継続できます。
チェックスイートが常に通過するように保ちながら、チェックアウトベンチマークのp95遅延を120ミリ秒以下に削減する。
これは十分明確な「終了基準」であり、直接エージェントに渡すことができます。その後、エージェントは自らタスクを分割し、サブエージェントを作成して、作業が完了するまで継続して実行します。CodexチームはRalphループのアイデアを参考に、複数のエージェントを調整して互いに干渉しないようにし、ステータスを管理し、テストを実行し、エージェントの起動と停止を行うインフラストラクチャを構築しました。その後、予算設定などの機能も追加されました。
目標：機能的アーキテクチャ
開発者はどのようにループを使用するか
では、開発者は実際にループを使って何をしているのでしょうか？コミュニティのフィードバックによると、最も一般的なシナリオは周期的なタスクを処理することです。
しかし、循環の能力はこれ以上に広がります。循環工学の真の価値は、より複雑で継続的な反復を要する長期的なタスクに現れます。
たとえば大規模なコード移行を完了するなど。スタートアップの創業者であるRafel Mendiolaは、ReactアプリをReact Nativeに変換する必要がありました。従来の方法では、巨大なEpicを作成し、そこから50〜100枚のチケットに分割する必要があり、インフラ構築だけで圧倒されてしまいます。
彼の代替案は、エージェントが移行可能なコードブロックを自ら識別し、変換を完了して進捗を追跡するスキルを作成し、それを30分ごとに実行されるCronタスクに組み込むことです。膨大な移行計画を管理するよりも、この方法の方が認知的な負担がはるかに軽いです。
次は：Graph
ピーターのツイートの問題は、実際には一つの進化の道筋を示している。
一年前、プロンプトエンジニアリングは核心的なスキルだった。2025年から2026年初頭には、重心はループの設計に移った。そして現在、ピーターが指し示しているのはさらに先の領域だ：複数のループからなるグラフを設計する——各エージェントが独自のループを実行し、依存関係を通じて互いに接続される。
このツイートのディスカッションスレッドで最も印象的な返信はLuis Catacoraによるものでした：「ループには大きな許容範囲があります。この図は、ワークフローのどの部分がまだ本当にモデル化されていないかをあなたに認めさせます。」
この文は、这两种范式的違いを示しています。ループでは、アーキテクチャ設計を先送りできます：最初にエージェントにすべての作業を任せ、もはや処理できなくなるまで続けます。一方、グラフでは、全体の構造を事前に定義する必要があります—誰が何を担当し、どのタスクがどのタスクに依存し、あるブランチが失敗した場合にどう対応するかを明示します。ループは意思決定の延期であり、グラフは事前の意思決定です。
Googleの上級AI製品マネージャーで、Awesome LLM Appsのコードリポジトリ（GitHub上で12.4万以上のスター）の作者であるShubham Sabooは、別の分解方法を提示し、2つのレベルを区別した。「長期的な組織図は、どの分野を誰が担当するかを定義し、コンテキストを保持する；作業図は、現在何を実行する必要があるかを定義し、証拠に基づいて分割、統合、再配置、または直接消去される可能性がある。」
Graphとは一体何ですか？Loop により、エージェントの行動をプログラミング可能にします。Graph により、エージェントの組織をプログラミング可能にします。さらに一歩進んだのは、動的エージェント組織です。タスク実行中に、Graphは自らの構造を書き換えます。
プレストン・ホルムズ：少なくとも2つのグラフが重要です。1つ目は、あなたの図に示されているように、長期的に存在するエージェントで構成され、それぞれが地域を担当するグラフです。2つ目は、完了すべき作業によって形成されるグラフです。これは動的で、常に変化します。Shubham Saboo：長期的に存在する「組織図」は、各領域の責任者を決定し、コンテキストを維持する役割を担う。「作業図」は、現在完了すべきタスクを決定する。新たな証拠が現れると、それは分割され、統合され、再配置され、または単に消えることもある。これは本番環境用のマルチエージェントシステムの鍵です：実際には、2つの図が同時に動作しています。
組織図（Org Graph）：「誰が何を担当するか」を定義します。これは、各エージェントが固定された分野を担当し、その分野のコンテキスト、専門知識、ツールの権限を保持する長期的なエージェントで構成されています。組織図は比較的安定しており、企業の組織構造に似ています。
ワークグラフ：「今何をすべきか、そしてタスクがどのように移動するか」を定義します。タスクや新しい証拠に応じて変化し、分割、統合、順序の調整、または直接キャンセルが可能です。ワークグラフは、リアルタイムで生成されるプロジェクト計画に似ています。
プレストン・ホルムズは、両方の図が重要であり、異なる時間スケールで動作していると考えています。組織図は事前に設計されデプロイされます。一方、作業図は各タスクに対して動的に生成され、タスク完了後に破棄されます。
循環がエージェントの行動をプログラマブルにするとすれば、グラフはエージェントの組織をプログラマブルにします。さらに一歩進むと、動的エージェント組織—タスク実行中にグラフが自らその構造を書き換えることです。
プロンプトの作成からループの設計、そしてグラフの構築まで、AIプログラミングの重心は継続的に上昇している。開発者は、単一のエージェントとの対話方法に注目するのではなく、エージェント間の協力構造を設計することに集中するようになっている。