プロンプトエンジニアリング・Loop エンジニアリング・Graph エンジニアリングとは何か
目次
プロンプトエンジニアリング、Loop エンジニアリング、Graph エンジニアリング。この三つは最近いつも同じ比較表に並べられ、三択を迫られているように見えます。しかし三者はそもそも同じ階層にいません。それを整理することは、どれか一つを習得するより価値があります。この記事では特定のツールの話はせず、各層が何を管理し、どこに限界があるのかを整理します。最後に、目の前の課題がどの層に属するかを判断するための三つの問いを示します。
三つの言葉、それぞれ別の出自
まずこの三つがどこから出てきたのかを見ておきます。来歴がまったく違うからです。
プロンプトエンジニアリングは、この二年で一度名前を変えています。初期の議論は「一文をどう書くか」でした。どんなペルソナを与えるか、どんな言い回しを使うか。その後、成果を決めているのは言い回しではなく「今回モデルに何を見せたか」だと分かってきました。そこで登場したのが Context Engineering という、より正確な呼び方です。
Loop エンジニアリングは、Ralph のようなやり方がコミュニティで広まる中で形になりました。仕組みは拍子抜けするほど単純です。一行の while ループで同じ指示を繰り返しモデルに渡し、正誤の判定はテストに任せる。十分な回数を回せば、受け入れ基準を通るバージョンが自然に浮かび上がってきます。
Graph エンジニアリングは、LangGraph のようなオーケストレーションフレームワークとともに視野に入ってきました。エージェントの実行経路を明示的に図として描く——誰が誰に渡すのか、差し戻せるのか、どこで必ず止まるのか、という主張です。
三つの流れはそれぞれ別に育ち、最後に同じ表へ並べられました。問題はまさにこの表にあります。三者はそもそも同じ種類のものではありません。
🧱 三者は同じ階層にいない
正しい関係は横並びではなく、積み重ねです。
| 階層 | 何を管理するか | 制御の粒度 |
|---|---|---|
| Graph エンジニアリング | 経路をどう組み立てるか | ステージ単位 |
| Loop エンジニアリング | 反復をどう収束させるか | ラウンド単位 |
| プロンプトエンジニアリング | 一回のやり取りをどう行うか | Token 単位 |
ここで一つ補足しておかないと、別の落とし穴にはまります。階層関係が成り立つことと、すべての層が必要であることは別です。
「標準の三層アーキテクチャ」が頭に入ってしまうと、どんなタスクにも三層を被せたくなります。実際にはうまく回っているシステムの多くは一層か二層しかありません。
| 形態 | どういう場合か |
|---|---|
| プロンプトのみ | 単発の分類・抽出・書き換え。オーケストレーションを足すのは純粋なマイナス |
| プロンプト + Loop | テストを支えに反復する。経路は最初から描いていない |
| プロンプト + Graph | 経路を全列挙できる。自律的な反復は不要 |
| 三層すべて | 本番運用の開発ワークフロー |
Anthropic が『Building effective agents』で示している原則は実践的です。最も単純な方法から始め、効果がはっきり改善するときだけ複雑さを足す。
つまり正しいメンタルモデルは「三層アーキテクチャ」ではなく、三つの選択可能な入れ子の層。既定では最下層から始め、上に足すには代償が伴うということです。
🔍 各層は結局何を管理しているのか
以下、各層について四点を扱います。何であるか、どうやるか、誤解しやすい要点、そして限界です。
プロンプトエンジニアリング：今回モデルに何を見せるかを決める
すでに「言い回しを整える」段階ではありません。本当に管理すべきなのは、今回モデルに何を見せ、何を見せないか、です。
そう変わった理由は単純で、タスクが複数ラウンドの推論をまたぐようになると一文の言い回しでは足りなくなり、焦点がコンテキスト全体の管理——システム指示、ツール定義、外部データ、履歴メッセージ——へ移るからです。
具体的な手立てはそう多くありません。システムプロンプトは適切な高さで書く必要があります。行動を導けるだけ具体的で、かつあらゆる状況を書き切ってしまわない程度に。細かすぎる規則は想定外の場面に出会うと互いに矛盾し始め、曖昧すぎる規則は何も言っていないのと同じです。ツールの説明はそれぞれの担当をはっきり書く。機能が重なるツールが多いほど、モデルは選び間違えます。出力フォーマットは先に決めておけば、後から正規表現で拾う手間が消えます。例示は多様なものを一組、境界ケースを積み上げるより有効です。
誤解しやすい要点：コンテキストは長ければ良いというものではありません。詰め込むほど中間部分は薄まっていきます。これは実際に起きる劣化であって、「モデルが賢くない」からではありません。注意力には予算があり、どこに使うかはトレードオフです。「多く渡すほど安全」ではありません。今回そもそも見せる必要のないものを見極めるほうが、何を書くかを考えるより早いことがよくあります。
限界：これはソフトな制約です。モデルは必ずしも指示どおりに動くとは限らず、しかもその場では気づけないことがあります。
この層の最大の長所と最大の問題は同じ事実です。一文直せばすぐ効く。だからこそ、モデルが従う気になるかどうかに委ねるしかありません。
Loop エンジニアリング：一つのタスクに、一つの検証を足す
この層には公理として使える一文があります。
A loop is a task with a check. A task without a check is just hope. ループとは、タスクに一つの検証を足したもの。検証のないタスクは、ただの願望である。
Ralph の形は先に触れたとおり、あの一行の while です。しかし本当の設計はループの中にはなく、周辺のファイルにあります。全部で三つ、それぞれ役割が違います。一つは仕様書で、このプロジェクトを何に仕上げるか、何をしてはいけないかを書く。一つは進捗リストで、何が終わり次に何をやるかを記録する。もう一つは毎回そのまま投入される指示で、「先に前の二つを読め、それから一件選んで手をつけろ」とモデルに伝える。ループ自体に技術的な難しさはありません。難しいのはこの三つを正しく書くことです。
誤解しやすい要点：毎ラウンド、コンテキストは完全に洗い流されます。モデルは前のラウンドで何をしたか覚えていません。欠陥のように聞こえますが、これは仕様です。記憶がないおかげで毎回きれいな状態から始まり、前のラウンドの誤った理解を後まで引きずりません。代償として、ラウンドをまたいで残すべきものはすべてディスクに落とす必要があります。それがあの進捗リストです。人間向けのメモではなく、次のラウンドのモデルにとって唯一の記憶です。
停止の信号はどこから来るか：ループは何をもって止まると判断するのか。機械が自動で判定できる信号が要ります。テストの終了コード、コンパイル結果、型チェック。「見た感じ良さそう」では条件判断に書けないので、成立しません。
典型的な失敗は二通りあります。一つは空回りです。モデルは毎ラウンド何かをやった気になっているのに実際には何も進まず、Token だけが燃えていく。もう一つは重複作業です。前のラウンドで完成しているものを見つけられず、まだ無いと判断してもう一度作ってしまう。昨日敷いた配管に気づかず、床を剥がしてもう一度敷き直す職人と同じです。
限界：検証信号のないループは、ゴミを量産しているだけです。しかもその失敗は最も見つけにくい。動き続けているのに、向きが間違っているからです。
Graph エンジニアリング：同じ名前の別物を先に切り分ける
この層はまず用語の曖昧さを解消する必要があります。同じ「グラフ」でも、まったく別の二つを指しています。
- オーケストレーショングラフ：LangGraph の類。フローがどの経路を通るかを描く
- ナレッジグラフ：GraphRAG やコード関係グラフの類。実体どうしの関係を描く
同名別物です。この記事で扱うのは前者、オーケストレーショングラフのほうです。後者はこのシリーズの第 7 回で単独に扱います。
オーケストレーショングラフがやっているのは、「この仕事をどの順で進めるか」を頭の中から紙の上へ移すことです。誰が誰の仕事を受け取るか、どの工程なら差し戻せるか、どこで必ず止まって人の承認を待つか。
よく使われる形は五つで、それぞれ向く仕事が違います。
- 直列：一歩終えたら次へ。コードを書くのがまさにこれで、設計 → テスト → 実装の順に進みます。
- ルーティング：まず種類を判定し、それから担当を決める。問い合わせが来たら分類し、返金は返金フロー、障害は障害フローへ。
- 並列：互いに独立した作業を同時に走らせ、最後に統合する。同じ差分をセキュリティ・性能・可読性で別々に見て、指摘をまとめる。
- オーケストレーターとワーカー：一人が分解して割り振り、複数が黙々と実行する。
- 評価と改善：出来上がったものを一度レビューに通し、基準に満たなければ差し戻す。
実際のシステムはたいていこの五つの組み合わせです。新しい形を発明する必要はありません。
図を描くことには、見落とされがちな利点が二つあります。一つは復旧できること。各ノードでチェックポイントを取れるので、落ちても最後の地点から再開でき、最初からやり直さずに済みます。もう一つは監査できること。後から「なぜその経路を通ったのか」を説明できます。説明を求められる場面では効いてきます。
誤解しやすい要点：グラフが定めるのは「どの経路を通ってはいけないか」であって、「どうやるか」ではありません。これは重要なので後で単独に扱います。
限界：事前に想定できたことしか表現できません。その場で判断が要るもの、見たことのない状況には、図は何の役にも立ちません。さらに隠れたコストがあります。一度描いた図はそのまま負債になり、現実が変われば描き直しになる。図の描き直しは一文の書き換えよりずっと高くつくので、着手前によく設計しておく必要があります。
🏠 リフォームに置き換えてみる
三層を一つの喩えで通しておきます。
| 概念 | リフォームでの対応 |
|---|---|
| プロンプトエンジニアリング | 職人にどう作業を伝えるか |
| Loop エンジニアリング | 施工 → 検査 → 不合格 → やり直し → 再検査 |
| 検証信号 | 監理者の直定規、水平器、防水試験 |
| Graph エンジニアリング | 施工順序の規定（配管 → 防水 → 防水試験 → タイル → 木工 → 塗装） |
| 人手の介在点 | 要所で施主が立ち会って承認する |
| 毎ラウンドのコンテキスト刷新 | 毎朝、別の職人が入ってくる |
三者の性格を三文で。
プロンプトは指示出しです。 「主寝室の北向きの壁、オフホワイト、二度塗り、際はマスキング」。コストはゼロ、即座に効きます。ただし職人が「これで十分だろう」と判断する余地があり、その場では気づけません。
Loop はやり直しの仕組みです。 指示だけでは足りず、検査が要ります。ここで効いているのは「やり直し」ではなく直定規のほうです。定規のないやり直しは、ただの二度手間です。
Graph は施工順序です。 壁を何色に塗るかは決めません。「防水をやらずにタイルを貼る」を、工程として不可能にするだけです。
三者の分担を一文で言うと、順序が「やってはいけないこと」を封じ、やり直しが基準まで押し上げ、指示が具体的なやり方を決める、ということです。
⚖️ 三つの性格、三通りの壊れ方
| プロンプト | Loop | Graph | |
|---|---|---|---|
| 制御権は誰に | モデル | モデル（人は停止条件だけ決める） | 人（人が経路を描き、モデルが埋める） |
| 決定性 | 低い | 最も低い | 高い |
| 初期投資 | ごく小さい | 小さい。ただし検証体制が先に要る | 大きい |
| 単位コスト | 1x | 4x、マルチエージェントで 15x | 2–3x、ただし回り道は減る |
| デバッグしやすさ | 良い | 最も悪い | 最も良い |
| 典型的な失敗 | モデルが従わない | 逸れているのに誰も気づかない | 図が間違っている、または硬直している |
コストの行について：エージェントで約 4x、マルチエージェントで約 15x は Anthropic の公開情報によるもの、Graph の 2–3x は公開資料で流通している概算です。いずれも桁感の参考であり、実測値ではありません。
この表で最も考える価値があるのは最後の行です。三つの壊れ方はまったく違います。プロンプトの失敗は見える——従わなかった結果がそこにあります。Loop の失敗は見えない——動き続けていて、向きだけが違う。Graph の失敗は直せない——図が固まっていて、現実のほうが動いた。
後ろの二つは最初の一つよりずっと厄介で、しかもそれは層を足したからこそ現れた新しい問題です。「上に足すには代償が伴う」というのは、具体的にはこういう意味です。
🚧 誤解しやすい二つのこと
Graph は計画しない。負の制約をかけている
三層を「Graph が計画し、Loop が実行し、Prompt が実装する」という指揮系統として読みたくなります。しかし図はどうやるかについて一言も言っていません。宣言しているのは「テストを飛ばして実装に入ってはいけない」だけです。この設計をどのモジュールに分けるか、実装をどのファイルから書くか——そちらが本当の計画で、それは下の二層で起きています。
別の言い方をすると、こうなります。
線路が決めるのはどこへ行けるか、どこで必ず止まるかであって、その外出の目的には関与しません。 エンジンはただ前へ押し出すだけです。終点まで、あるいは停止信号にぶつかるまで。 ハンドルは線路が許す範囲の中で、具体的な進み方を決めます。
線路が旅程を計画してくれることはありません。「横へ逸れる」を成立させなくしているだけです。
階層が上がるほど、能力は弱くなる
「上位層・下位層」という言い方に引きずられると、上のほうが重要に思えます。実際は逆で、制御力が強いほど表現力は弱くなります。Graph は事前に想定できたことしか表現できず、現実が図の想像を超えた瞬間、何の助けにもなりません。
もう一段踏み込むと、この三層はどれ一つとして何かを「実装して」いません。実際に作業しているのは常にモデル自身で、三層はその振る舞いを形づくる三つの手段にすぎません。Graph は構造で、Loop は反復と検証で、プロンプトは言語で。
つまり、モデルが強くなるほど上の二層の必要性は縮んでいきます。この仕組み一式の価値は、ある意味でモデルの現時点の弱点を補うところにあります。
✅ 選定のための三つの問い
この記事から一つだけ持ち帰るとしたら、次の三つの問いにしてください。
第一問：間違ったとき、機械が自動で気づけるか。
気づける → Loop を使う。テスト、コンパイラ、型システムが直定規になります。 気づけない → どんなに魅力的に見えても使わない。検証信号のないループはゴミの量産です。
判断基準は素朴です。「正しくできた」を、終了コードを返すコマンドとして書けるか。書けるなら回せます。書けないなら回さないことです。
第二問：今この場でフローチャートを描けるか。
描けて、しかもこのフローを繰り返し使う・監査する・人の承認点を残す必要がある → Graph を使う。 描けない → 無理に描かない。
ここでいう「描けない」とは、そもそも何ステップで終わるか言えない種類の仕事です。三歩で終わるかもしれないし、二十回行き来するかもしれない。途中で何に出会うか次第です。この種の仕事は本来モデル自身に進みながら判断させるべきで、無理に図を被せると縛るだけになります。Anthropic の推奨も同じ趣旨です。ステップ数が読めないオープンな問題はエージェントに任せ、固定フローを当てはめない。
もう一点。問うているのは「今描けるか」であって「いずれ描けるか」ではありません。先に考え抜いてから描いた図だけが制約として機能します。走りながら継ぎ足した図は、混乱を別の形式で記録し直しただけです。
第三問：上の二つはどちらも要らないか。
ならプロンプトエンジニアリングで十分です。これは妥協ではなく、正解です。 単発の分類タスクにループとオーケストレーションを被せても、遅く、高く、デバッグしにくくなるだけです。
次回：三層が同時に育った実物はあるのか
概念の話はここまでです。最後に一文だけ残しておきます。この文はシリーズ全体を貫きます。
プロンプトの層ができるのは「要求」までで、「保証」は与えられません。「Token を節約しろ」と書けばモデルはたいてい従いますが、本当に超過したとき止める手立てはありません。その一文には強制力がないからです。
保証が欲しいなら、層を変えた手段が要ります。たとえば「この一回で一定額を超えたら自動停止」というハードなラインを引く。この線はモデルと交渉せず、モデルの意思も問いません。
つまり、欲しいものが「保証」なら、プロンプトの層はそれを与えられない。一つ上に移す必要がある。
次回は具体的なものを扱います。私が作っている pdlc-skills が、なぜこの三層に自然に収まっているのか、という話です。
試してみる：
curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
| bash -s -- --global
プロジェクトページ：kanfu-panda.github.io/pdlc ／ ソース：github.com/kanfu-panda/pdlc-skills
役に立ったら star をいただけると励みになります ⭐
三つの言葉の違いが整理できたなら、いいねやフォローをいただけると嬉しいです。周りに同じところで混乱している方がいれば、共有していただけると助かります。
コメント