7月30日、MarkTechPostが「Prompt Engineering vs Loop Engineering vs Graph Engineering: What Changes at Each Layer」と題した記事を公開した。「プロンプトエンジニアリング」「ループエンジニアリング」「グラフエンジニアリング」という3つの用語は求人票で同じ行に並ぶようになったが、これらは互いに競合する技術ではなく、積み重なった3層の制御単位だ。どの層を選ぶべきか、その判断基準まで含めて整理されている。
3つの用語は競合していない——「制御の単位」が違う
- プロンプト：1つのモデル応答を制御する
- ループ：1つのエージェントの動作サイクルを制御する
- グラフ：複数エージェントの組織を制御する
下の層はなくならない。ループを構築してもプロンプトは消えず、「手で入力するもの」ではなくなるだけだ。
Layer 1: プロンプトエンジニアリング——「人間が毎回いる」前提
プロンプトエンジニアリングの本質的な前提は、すべてのイテレーションに人間が立ち会っていることだ。プロンプトを書き、モデルが応答し、人間が判断して次を書く。
この前提が崩れる条件は4つある：
- 高ボリュームのタスク
- 複数ステップのタスク
- 出力を採点する人間がいない状況
- 次のステップへ自動的に結果が渡される場合
Anthropicのマルチエージェント研究によると、初期版では単純なクエリに50のサブエージェントを生成していたが、その修正はトポロジーではなくプロンプトの改善で対処できたという。プロンプトエンジニアリングは上位層でも引き続き有効な手段であり続ける。
Layer 2: ループエンジニアリング——「止まる条件」が設計の核心
この概念は2025年9月に命名され、2026年6月ごろには開発者コミュニティで広く共有されるようになったとされる。「エージェントにプロンプトを書くのをやめ、プロンプトするループを設計せよ」という主張が広まり、AnthropicのClaude Codeチームも同週に同じシフトを語った。
公開されている最も詳細な解説（Addy Osmaniの記事）では、ループを構成する5つのプリミティブ＋1つの記憶が定義されている：
- Automations：スケジュールやイベントで自動的に発見・トリアージ
- Worktrees：並列エージェントが同じファイルを編集しないための分離
- Skills：プロジェクト固有の知識を
SKILL.mdに一度だけ書き、毎回再説明しない - Plugins and connectors：MCPベースでイシュートラッカーやDBにアクセス
- Sub-agents：コードを書いたモデルが採点も行うと甘くなるため、maker/checker分離
- State：会話外のmarkdownファイルやボードで状態を保持（モデルはセッション間で忘れる）
Claude Codeには/loop（定期実行）と/goal（条件が真になるまで実行）が実装されており、採点は別の小モデルが担う。
ループの難所はサイクルではなく止まる条件だ。 「完了」と「詰まっている」を機械的に判別できないループは、派手に失敗せず静かにトークンを消費し続ける。
Layer 3: グラフエンジニアリング——2つのグラフが同時に走る
2026年7月に議論はループからグラフへ移った。最もよく見落とされる構造的な点は、本番環境では2つのグラフが同時に稼働していることだ。
- org graph（組織グラフ）：安定している。長期稼働エージェントが役割を持ち、担当ゾーンを所有し、コンテキストを蓄積する。変更はデプロイ時。
- work graph（作業グラフ）：一時的。タスクノードは作業中のみ存在し、並列パスで分岐し、証拠が揃えば不要なブランチは消える。
org graphが「誰が担当か」に答え、work graphが「今、何をするか」に答える。
実装の具体例としてLangGraphが挙げられている。StateGraphをスキーマ上で宣言し、add_nodeでノードを登録、add_edgeとadd_conditional_edgesでエッジを配線し、STARTとENDを定義してコンパイルする。ノードは状態を受け取り部分的な更新を返す関数だ。コンテキストはエッジが運ばない限りノード境界を越えない——これが典型的な障害モードの全てを説明している。
グラフ設計における主な判断ポイントは3点ある。①ノードの粒度：細かすぎるとエッジ管理が爆発し、粗すぎるとループとの差別化がなくなる。②状態スキーマの設計：ノード間で何を共有し何を隔離するかを明示的に決める必要があり、暗黙の依存を持ち込むと条件分岐が追跡不能になる。③条件エッジの書き方：add_conditional_edgesに渡すルーター関数がグラフの「知性」に相当し、ここが複雑化する場合は上位のオーケストレーター層の検討が必要になる。
「グラフエンジニアリング」という名称への懐疑は妥当でもある。Anthropicが2024年12月に公開した5つのワークフローパターン（プロンプトチェーン、ルーティング、並列化、オーケストレーター-ワーカー、評価-最適化）はすでにグラフトポロジーを散文で記述したものだ。「グラフエンジニアリング」は新しい実践ではなく、それらの決定事項——ノードは何か、エッジは何か、状態は何か——に共通の名前をつけたものだ。
どの層を選ぶか——4つの判断基準
記事では順番に問いを立てることを推奨している：
- すべての出力を人間が読んでから次のアクションが起きるか？ → Yesならプロンプト層で十分
- 「完了」を人間以外がチェックできるか？（テスト、スキーマ、別モデルなど） → Noなら止まる条件がなく、あるのはバジェットだけ
- タスクは1エージェントのコンテキストと1ドメインに収まるか？ → Yesならループを構築する
- 独立したブランチを並列で走らせる必要があるか？ → Yesならグラフ問題。Noならエージェントを増やす前にループのツールを拡張する
元記事では「ループはプロンプトにスキャフォールディングを巻いたもの」という定義が紹介されており、ループエンジニアリングはプロンプトエンジニアリングの代替ではなく補完だと述べられている。なお、元記事ではこの定義の出典としてarXiv論文が言及されているが、論文タイトル・著者・URLの記載はなく、独立した検証は現時点では難しい。
また、記事は最後にアーキテクチャより「人間」の問題を指摘している。同一のループを構築した2人のエンジニアが正反対の結果を得ることがある——一方は深く理解した業務で速く動き、もう一方は業務への理解を避けるためにループを使う。システムは両者を区別できない。それが上位層の設計をプロンプトより難しくしている。
詳細はPrompt Engineering vs Loop Engineering vs Graph Engineering: What Changes at Each Layerを参照していただきたい。
