プロンプト・ループ・グラフ工学:各レイヤーの変化とは
AI エンジニアリングの領域で、単一のプロンプト制御からループによるエージェント行動制御、そしてグラフによる複数エージェント組織化へと層が積み重なる構造が明確に定義され、各レイヤーの設計要件と限界が示された。
AI深層分析を開く2026年7月30日 15:16
AI深層分析
キーポイント
3 つのエンジニアリング概念の階層的関係
プロンプト、ループ、グラフは競合する技術ではなく、それぞれ単一のモデル応答、エージェントの行動サイクル、複数エージェントの組織化を制御する異なる制御単位としてスタック構造で存在する。
各レイヤーの設計対象と進化
プロンプトは単一呼び出しの指示設計から、コンテキストエンジニアリングによるトークン構成の最適化、ハルネスエンジニアリングによる環境構築へと発展し、最後にループで反復的な観測・行動・検証を定義する。
プロンプトエンジニアリングの限界と転換点
人間が各反復に参加することを前提とする従来のアプローチは、高ボリューム処理や自動フィードバックが必要なケースで破綻し、上位レイヤーへの移行が必要となる。
グラフエンジニアリングの現状と課題
最新かつ未確定な概念であるグラフエンジニアリングは用語の由来が曖昧で既存の知識グラフ用語と競合するが、マルチエージェントシステムの研究におけるオーケストレーションの実践として確立されつつある。
ループ設計の重要性と5つのプリミティブ
コーディングエージェントはゴール、ツール、そしてループを設計する工芸であり、プロンプト工程に依存しない。自動化、ワークツリー、スキル、プラグイン、サブエージェンツ、ステートの6要素がループの基盤となる。
重要な引用
They are three different units of control, stacked.
A prompt controls one model response. A loop controls one agent's behavior cycle. A graph controls the organization of many agents.
The term reached mainstream developer discussion in June 2026, after a widely shared post argued that engineers should stop prompting coding agents and start designing the loops that prompt them.
Loops made agent behavior programmable. Graphs make agent organizations programmable.
編集コメントを表示
編集コメント
AI エンジニアリングの概念が単なるツールの進化から、システム全体の制御構造へとパラダイムシフトしていることを示す重要な分析である。開発者は各レイヤーの境界と責任範囲を明確に理解し、複雑化するタスクに対して適切な設計アプローチを選択する必要がある。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
AI 工学の求人票で、現在 3 つの用語が同じ行を争っています。確立されたのが「プロンプトエンジニアリング」です。「ループエンジニアリング」は 2025 年後半に AI の用語として登場し、2026 年 6 月まで開発者の議論を支配しました。そして約 6 週間後、「グラフエンジニアリング」が続きました。
これらは互換的に使われていますが、そうすべきなのでしょうか?
これら 3 つは競合する技術ではありません。それぞれが異なる制御単位であり、積み重なっています。プロンプトは 1 回のモデル応答を制御し、ループは 1 つのエージェントの行動サイクルを制御します。グラフは多数のエージェントの組織構造を制御します。各層は下位の層を維持したままです。ループが構築されてもプロンプトが消えるわけではありません。単に手入力されるものではなくなるだけです。
この記事では、これら 3 つを区別して解説します。各層で何設計的な作業が行われるのか、上位層が自らのコストを回収するタイミングに関する公表された主張、そしてどこに懐疑的な視点が必要なのかについてです。
スタックの順序
各段階は、ベンダーのドキュメントに記載される前に、現場の実践の中で名付けられました。
プロンプトエンジニアリングは、1 回の呼び出しに対する指示の作成と構造化を扱います。Anthropic のガイダンスでは、システムプロンプトをラベル付きセクションに分割することを推奨しています。具体的には、背景情報、指示、ツールガイド、出力説明などです。これらは XML タグや Markdown ヘッダーで区切ります。推奨されるのは、期待される動作を完全に指定する最小限の情報セットを提供することです。ここでいう「最小限」は、「短い」という意味ではありません。
次に登場したのが「コンテキストエンジニアリング」です。Anthropic はこれをプロンプトエンジニアリングの自然な発展と位置付けています。問われるのは適切な言葉を見つけることではなく、どのトークンの構成をウィンドウに含めるべきかを決断することへと移ります。コンテキストは有限のリソースであり、エンジニアリングの課題とは、モデルの制約の中でこれらのトークンの有用性を最適化することです。
ハーネスエンジニアリングは、単一のエージェントが動作する環境——ファイル、ツール、メモリ、フィードバック——をカバーします。
ループエンジニアリングは、その一つ上の階層に位置します。建築分野におけるアジェンティック AI に関する 2026 年 6 月の arXiv 論文「Buildrix」では、この 4 つの段階が明確に示されています——プロンプト、次にコンテキスト、そしてハーネス、最後にループです。最終層は、システムがいかにして繰り返し観察し、行動し、検証し、回復するかを定義するものです。
グラフエンジニアリングは最も新しい呼称であり、まだ定まっていません。ある企業の解説では、この用語の由来が未解決であること、そして同じ言葉を使った古くからの知識グラフの用法と衝突していることが指摘されています。しかし、その根底にある実践——グラフベースのオーケストレーション——には、マルチエージェントシステム研究における明確な系譜があります。
第 1 レイヤー:プロンプトエンジニアリング
ここでの決定的な前提は、「人間が各反復段階に常に存在する」という点です。プロンプトが記述され、モデルが応答し、出力が評価され、プロンプトが修正される——このサイクルを想定しています。
しかし、その前提は崩れ始めます。高ボリュームな処理や多段階のタスク、出力の評価を行う人間が存在しない状況、あるいは結果が自動的に次のステップにフィードバックされるケースなどです。これらいずれかの条件でも、プロンプトだけではもはや不十分となります。
プロンプト自体が悪化したわけではありません。周囲の環境が変わっただけです。
高層部においても、プロンプトエンジニアリングが不要になるわけではありません。Anthropic のマルチエージェント研究レポートでは、プロンプトエンジニアリングが調整失敗を修正するための主要な手段であったと報告されています。初期バージョンでは単純なクエリに対して 50 個のサブエージェントが生成されていましたが、その解決策はトポロジーの変更ではなく、プロンプトの改善でした。
レイヤー 2:ループエンジニアリング
コーディングエージェントを解法を見つけるための力任せのツールと捉えるなら、真の技術はプロンプトだけでなく、目標・ツール・そしてループをどう設計するかにかかっています。
この「ループエンジニアリング」という用語が主要な開発者コミュニティで広まったのは 2026 年 6 月です。当時、エンジニアはコーディングエージェントへのプロンプト作成をやめ、それらを動かすループの設計に注力すべきだと主張する投稿が広く共有されました。その週、Anthropic の Claude Code チームもステージ上で同様の転換点を説明しています。
最も詳細な公開解説では、5 つの基本要素と、これらをつなぎ合わせる 6 つ目の要素が挙げられています:
- 自動化(Automations):監督なしで発見と優先順位付けを行うスケジュールまたはイベント
- ワークツリー(Worktrees):並行して動作するエージェントが同じファイルを編集できないようにするための隔離環境
- スキル(Skills):各セッションごとに説明し直すのではなく、SKILL.md に一度だけプロジェクトの知識を記述しておくこと
- プラグインとコネクタ:MCP ベースで、課題管理システムやデータベース、ステージング API へのアクセスを実現する機能
- サブエージェント:コード作成者とチェック役を分ける仕組み。モデル自身が書いたコードを評価すると甘くなりすぎるためです
- 状態(State):会話外に Markdown ファイルやボードを用意し、実行のたびに忘却しないようにすること
セッション中に重要な機能は2つあります。1 つ目は「/loop」コマンドで、一定間隔で再実行を行うものです。2 つ目は「/goal」コマンドで、記述された条件が実際に満たされるまで継続し、各ターンごとに別の小型モデルが検証を行います。これにより、コードを書いたエージェントと評価するエージェントを分離できます。Claude Code と Codex アプリの両方にも同様の機能が実装されています。
ループ自体は難しい部分ではありません。重要なのは停止条件です。完了状態と停滞状態を機械的に区別できないループは、大きなエラーとして失敗しません。ただひたすらトークンを消費し続けるだけです。
レイヤー3:グラフエンジニアリング
2026 年 7 月、議論の焦点はループからグラフへと移りました。ループによってエージェントの動作をプログラム可能にしましたが、グラフでは組織自体をプログラム可能にします。
よく見落とされる構造的なポイントは、本番環境でのマルチエージェントシステムが同時に 2 つのグラフを実行しているという事実です。
1 つ目は「組織グラフ」で、これは安定しています。長期稼働するエージェントが名前付きの役割を持ち、特定の領域を管理し、時間とともに文脈を蓄積します。このグラフは再デプロイされた際にのみ変更されます。
2 つ目は「作業グラフ」で、こちらは一時的なものです。タスクノードは作業中だけ存在し、並列パスでは分岐し、収束点で合流し、証拠によって不要になった枝は消去されます。
組織グラフが「誰がやるか」を答え、作業グラフが「今何をやるか」を答えます。
このラベルに対する懐疑論はもっともだ。すでに目的が定義されたサブエージェントはグラフを形成しており、その技術自体は用語が存在する前からあった。LangGraph は「グラフ」という言葉が定着する以前からグラフ API を提供していた。Anthropic が 2024 年 12 月に発表した 5 つのワークフローパターン(プロンプトチェーン、ルーティング、並列化、オーケストレーターとワーカー、評価者と最適化者)も、要約すれば文章で記述されたグラフ位相に過ぎない。新しいのは、これらのフレームワークが常に迫っていた判断事項——ノードとは何か、エッジとは何か、状態には何が含まれるのか——に対する共通の名称が生まれた点だ。
具体的な実装形式を知る価値はある。LangGraph では StateGraph を状態スキーマに対して宣言する。add_node でノードを登録し、add_edge や add_conditional_edges でエッジをつなぐ。START と END をマークした上でグラフをコンパイルする。ノードは単なる関数で、状態を受け取って部分的な更新を返す。文脈がノードの境界を越えるのは、エッジを通じてのみだ。この最後の点が、まさに失敗の典型的な原因となっている。
どのレイヤーを選ぶか
質問に順を追って答えよう。「いいえ」が最初に出れば、それが答えであることが多い。
人の手がすべての出力を確認してから何かが実行されるべきか?もしそうなら、プロンプトレイヤーで十分だ。ループは自律性ではなく、監視なしの実行をもたらすだけだ。
「完了」を人間以外の誰か(テスト、スキーマ、評価基準、あるいは別のモデル)が判定できるか?できない場合、停止条件はない。予算の範囲内で回し続けるしかない。
タスクが単一のエージェントのコンテキストとドメインに収まるか?そうであれば、ループを構築してください。仮定の一貫性を保つための最も安価な方法は、単一の推論トレースを使用することです。
独立したブランチを並列実行する必要があるでしょうか?その場合はグラフ問題となります。ノード、エッジ、共有状態、そして障害時の経路を宣言してください。もし並列実行が必要ないのであれば、エージェントを追加する前にループのツールを拡張しましょう。
2026 年 7 月に arXiv に掲載されたコーディングエージェントのループに関する論文は、この関係を正しく説明しています。ループとは、その周囲に足場(スキャフォールディング)を設けたプロンプトの繰り返しであり、ループエンジニアリングはプロンプトエンジニアリングの代替ではなく、それを補完するものです。これは一つ上の階層でも同様です。グラフはループから構築され、ループはプロンプトから構築されます。
最後に注意すべきはアーキテクチャそのものよりも、オペレーター(運用者)の問題です。同じループを構築しても、二人のエンジニアが全く異なる結果を出すことがあります。一方は理解している作業に対して素早く動き、他方は作業内容を理解しようとさえしません。システムはその違いを見分けることができません。これが、プロンプトよりも上位層の設計が難しくなる理由です。
要点
競合する 3 つの方法ではなく、制御のための 3 つの単位があります:プロンプトは 1 回の応答を制御し、ループは 1 つのエージェントのサイクルを制御し、グラフは多数のエージェントの組織化を制御します。
ループの良し悪しは停止条件にかかっています。「完了」を検証する機械的なチェックがなければ、無人で実行されたループは正しさではなくトークン予算の限界で終了してしまいます。
本番環境では、2 つのグラフが同時に稼働しています。1 つは「誰が何を持っているか」を回答する安定した組織用グラフ(org graph)で、もう 1 つはタスクごとの作業用グラフです。後者は証拠が届くたびに分割・統合・キャンセルを行います。
公開された数値からコスト構造が見えてきます。内部の研究評価では +90.2% の向上を記録しましたが、トークン使用量はチャットと比較して約 15 倍に達します。このうち、トークン消費が全体のばらつきの 80% を説明しています。
ほとんどのタスクはスタックの最上位には到達しません。むしろ、記述作業が中心となるケースの方が一般的です。分散した意思決定によって、矛盾する前提条件が生じやすいためです。
参考資料:
- anthropic.com/engineering — AI エージェントのための効果的なコンテキストエンジニアリング
- anthropic.com/engineering — 効果的なエージェントの構築(2024 年 12 月)
- anthropic.com/engineering — マルチエージェント研究システムの構築方法(2025 年 6 月 13 日)
- simonwillison.net — エージェント型ループの設計(2025 年 9 月 30 日)
- addyosmani.com — ループエンジニアリング(2026 年 6 月 7 日)
- firecrawl.dev — ループエンジニアリング
- explainx.ai — グラフエンジニアリング(2026 年 7 月 18 日)
- truefoundry.com — マルチエージェントシステム向けのグラフエンジニアリング
- aibuilderclub.com — グラフエンジニアリングガイド 2026
- cognition.com — マルチエージェントを構築するな(2025 年 6 月)
- langchain.com — マルチエージェントシステムの構築方法とタイミング
- docs.langchain.com — LangGraph Graph API
- arXiv — Buildrix · コーディングエージェントに過度な手助けは不要
本記事「プロンプトエンジニアリング vs ループエンジニアリング vs グラフエンジニアリング:各レイヤーで何が変わるのか」は、MarkTechPost に掲載されました。
原文を表示
Three terms now compete for the same line in AI engineering job descriptions. Prompt engineering is the established one. Loop engineering entered the AI vocabulary in late 2025 and dominated developer discussion through June 2026. Graph engineering followed roughly six weeks later.
They get used interchangeably. Should they be?
The three are not competing techniques. They are three different units of control, stacked. A prompt controls one model response. A loop controls one agent’s behavior cycle. A graph controls the organization of many agents. Each layer preserves the layer beneath it. A prompt does not disappear once a loop is built around it. it stops being the thing typed by hand.
This article separates the three: what gets designed at each layer, what the published claim says about when the higher layers pay for themselves, and where the skepticism is warranted.
The stack, in order
Each step in the progression was named in practice before it appeared in vendor documentation.
Prompt engineering covers writing and structuring the instruction for a single call. Anthropic’s guidance is to separate a system prompt into labeled sections — background information, instructions, tool guidance, output description — delineated with XML tags or Markdown headers. The recommendation is to supply the minimal set of information that fully specifies the expected behavior. Minimal does not mean short.
Context engineering came next. Anthropic describes it as the natural progression of prompt engineering. The question moves from finding the right words to deciding what configuration of tokens belongs in the window at all. Context is a finite resource, and the engineering problem is optimizing the utility of those tokens against model constraints.
Harness engineering covers the environment a single agent runs inside: files, tools, memory, feedback.
Loop engineering sits one floor above the harness. A June 2026 arXiv paper on agentic AI in building engineering, Buildrix, sets out the same four-step progression explicitly — prompt, then context, then harness, then loop — with the final layer defining how a system repeatedly observes, acts, verifies and recovers.
Graph engineering is the newest label and the least settled. One enterprise writeup notes that the term’s provenance is unresolved and that it collides with an older knowledge-graph usage of the same word. The underlying practice, graph-based orchestration, has a documented lineage in multi-agent systems research.
Layer 1: Prompt Engineering
The defining assumption is that a human is present at every iteration. A prompt is written, the model responds, the output is judged, the prompt is revised.
That assumption is what breaks. High volume. Multi-step tasks. No human available to grade the output. Results that feed the next step automatically. Any one of these, and the prompt alone stops being sufficient.
Nothing about the prompt got worse. The surrounding conditions changed.
Prompt engineering also does not vanish inside the higher layers. Anthropic’s multi-agent research writeup reports that prompt engineering was the primary lever for fixing coordination failures. Early versions spawned 50 subagents for simple queries, and the fix was prompting rather than topology.
Layer 2: loop engineering
The framing is that a coding agent is a brute-force tool for finding solutions. The craft is designing the goal, the tools and the loop and not only the prompt.
The term reached mainstream developer discussion in June 2026, after a widely shared post argued that engineers should stop prompting coding agents and start designing the loops that prompt them. The Claude Code team at Anthropic described the same shift on stage that week.
The most detailed public breakdown identifies five primitives, plus a sixth element that holds them together:
Automations: a schedule or event that performs discovery and triage without supervision
Worktrees: isolation so parallel agents cannot edit the same files
Skills: project knowledge written down once in a SKILL.md, rather than re-explained every session
Plugins and connectors: MCP-based access to the issue tracker, database or staging API
Sub-agents: a maker/checker split, since the model that wrote the code grades it too generously
State: a markdown file or board outside the conversation, because the model forgets between runs
Two in-session features are very important. /loop re-runs on a cadence. /goal runs until a written condition is actually true, with a separate small model checking after each turn — so the agent that wrote the code is not the agent grading it. Both Claude Code and the Codex app ship equivalents.
The cycle is not the hard part. The stop condition is. A loop that cannot mechanically distinguish done from stuck does not fail loudly. It keeps spending tokens.
Layer 3: graph engineering
In July 2026 the discussion moved from loops to graphs. Loops made agent behavior programmable. Graphs make agent organizations programmable.
The structural point most often missed is that production multi-agent systems run two graphs at once.
The org graph is stable. Long-lived agents hold named roles, own a zone, and accumulate context over time. It changes on redeploy.
The work graph is ephemeral. Task nodes exist only while the work does. Edges split for parallel paths, merge on convergence, and disappear when evidence makes a branch unnecessary.
The org graph answers who. The work graph answers what, right now.
The skepticism around the label is fair. Sub-agents with a defined purpose already form a graph, and the technology preceded the vocabulary. LangGraph shipped its graph API long before the term existed. Anthropic’s five workflow patterns from December 2024 — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — are graph topologies described in prose. What is new is a shared name for decisions those frameworks always forced: what are the nodes, what are the edges, what is in the state.
The concrete artifact is worth knowing. In LangGraph a StateGraph is declared over a state schema. Nodes register with add_node. Edges wire up with add_edge and add_conditional_edges. START and END are marked, then the graph compiles. Nodes are plain functions that receive state and return partial updates. Context does not cross a node boundary unless an edge carries it. That last part describes the entire failure mode.
How to choose the layer
Work through the questions in order. The first “no” is usually the answer.
Does a person read every output before anything acts on it? If yes, the prompt layer is sufficient. A loop buys unsupervised execution, not autonomy.
Can “done” be checked by something other than a human? Tests, a schema, a rubric, a second model. If not, there is no stop condition — only a budget.
Does the task fit inside one agent’s context and one domain? If yes, build the loop. A single reasoning trace is the cheapest way to keep assumptions consistent.
Do independent branches need to run at the same time? If yes, this is a graph problem: declare the nodes, the edges, the shared state and the failure routes. If no, extend the loop’s tools before adding agents.
A July 2026 arXiv paper on coding-agent loops states the relationship correctly. A loop is a prompt repeated with scaffolding around it, and loop engineering is complementary to prompt engineering rather than its replacement. The same holds one floor up. Graphs are built from loops, and loops are built from prompts.
The final caution is about the operator rather than the architecture. Two engineers can build an identical loop and get opposite outcomes. One moves faster on work they understand deeply. The other avoids understanding the work at all. The system cannot tell the difference. That is what makes the higher layers harder to design than prompts, not easier.
Key Takeaways
Three units of control, not three competing methods: a prompt controls one response, a loop controls one agent’s cycle, a graph controls the organization of many agents.
A loop is only as good as its stop condition — without a mechanical check for “done,” an unattended run terminates on token budget rather than correctness.
Two graphs run simultaneously in production: a stable org graph answering who owns what, and a per-task work graph that splits, merges and cancels as evidence arrives.
Published numbers set the price: +90.2% on an internal research eval, but roughly 15× the tokens of a chat, with token spend alone explaining 80% of the variance.
Most tasks never reach the top of the stack: the counter-case stands for writing-heavy work, where dispersed decisions produce conflicting assumptions.
Sources
anthropic.com/engineering — Effective context engineering for AI agents
anthropic.com/engineering — Building effective agents (Dec 2024)
anthropic.com/engineering — How we built our multi-agent research system (13 Jun 2025)
simonwillison.net — Designing agentic loops (30 Sep 2025)
addyosmani.com — Loop Engineering (7 Jun 2026)
firecrawl.dev — Loop Engineering
explainx.ai — Graph Engineering (18 Jul 2026)
truefoundry.com — Graph Engineering for Multi-Agent Systems
aibuilderclub.com — Graph Engineering Guide 2026
cognition.com — Don’t Build Multi-Agents (Jun 2025)
langchain.com — How and when to build multi-agent systems
docs.langchain.com — LangGraph Graph API
arXiv — Buildrix · Stop Hand-Holding Your Coding Agent
The post Prompt Engineering vs Loop Engineering vs Graph Engineering: What Changes at Each Layer appeared first on MarkTechPost.
AI算出
技術分析ainew評価限定的
記事は AI エージェント運用における概念整理に焦点を当てており、具体的な新製品発表や独自データに基づく市場分析ではないため novelty は低めだが、実装の文脈で有用な技術的枠組みを提供している。検索機会も業界カテゴリ語レベルであり、日本固有の情報もない。
6つの評価軸を見る
- AI関連度
- 75
- 情報源の信頼性
- 25
- 新規性
- 25
- 調べる価値
- 25
- 重複の少なさ
- 40
- 日本での有用性
- 25
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み