グラフエンジニアリングとは
最終更新: 2026年8月11日
複数のエージェント・ツール・人の承認をノードとして置き、 その間をエッジでつないで、実行の順番・条件分岐・並行処理・失敗したときの戻り先を ひとつの図として設計する考え方です。
よくループエンジニアリングと並べて語られます。 この記事では2つの違いと、どこで乗り換えるべきかを整理します。
ループとグラフは、見ている単位が違う
| ループエンジニアリング | グラフエンジニアリング | |
|---|---|---|
| 見ている単位 | 1体のエージェント | 処理全体のつながり |
| 扱うこと | 1体のエージェントが回すサイクル | 複数のノードのつなぎ方 |
| 問い | いつ道具を使い、いつ止めるか | どういう順で流し、どこで分岐し、失敗したらどこへ戻るか |
| 主な設計項目 | 終了条件、試行回数の上限、道具の選び方、失敗時のやり直し | ノードの分け方、分岐の条件、並行、状態の持ち方、戻り先 |
| うまくいかないときの症状 | 同じ失敗を延々と繰り返す。終わらない。無駄に何十回も道具を叩く | 処理が複雑になり、どこで失敗したかわからない。途中から再開できない |
たとえるなら、ループは1つの部屋の中で人がどう動くか、 グラフは部屋をどう並べて、どの順に通すかです。 そしてグラフの各ノードの中では、いまもループが動いています。 図をきれいに描いても、ノードの中で止まらなければ全体は止まりません。
ループ設計で決めること
グラフの話に進む前に、ループ側で決めておくべきことを挙げます。 ここが空白のまま外側を作ると、必ず後で戻ってくることになります。
- 終了条件 — 何をもって「終わった」とするか。 これを決めていないと、それらしい作業を延々と続けます。
- 試行回数の上限 — 何回まで試すか。 同じ失敗を繰り返すとき、止めるのは人ではなく仕組みの役割です。
- 失敗したときの動き — やり直すのか、別の手を試すのか、諦めて報告するのか。
- 1周あたりの費用 — 1回まわすといくらか。 これがわからないと、上限を決める根拠がありません。
とくに費用は見落とされがちです。1周あたりのトークン量は トークン数の計算で見当をつけられます。 会話が伸びるほど1周の費用も増える仕組みは コンテキストエンジニアリングで計算しています。
グラフへ移る判断の目安
「複雑になってきたから」では判断できません。次のどれかに当てはまったら検討する時期です。
| こうなったら | なぜグラフなのか |
|---|---|
| 条件分岐が3つ以上ある | 「もし〜なら」を指示文の中に書き並べると、どれが効いているのか追えなくなります。分岐は図にしたほうが早く読めます。 |
| 途中に人の承認を挟みたい | 送信・支払い・公開といった取り返しのつかない操作の前で止めたい。ループの中に「止まって待つ」を入れるのは無理があります。 |
| 並行してやりたい処理がある | 3つの資料をそれぞれ要約する、といった作業を順番にやると3倍の時間がかかります。分けて同時に流せるのはグラフの利点です。 |
| 失敗したところから再開したい | 10分かかる処理の9分目で落ちたとき、最初からやり直すのは現実的ではありません。どこまで進んだかを持つ設計が要ります。 |
| どこで失敗したのか説明できない | 「なんかうまくいかない」の原因がわからない状態は、処理の形が見えていないということです。図にすると、見る場所が決まります。 |
| 役割の違う処理が混ざっている | 調べる・書く・確認する。全部を1体にやらせると指示が肥大化します。分けたほうが、それぞれの指示は短く済みます。 |
逆に、移らなくていい場合。 処理が一直線に進む、分岐がひとつもない、途中で止める必要もない。 こういう場合に無理やり図へ落とすと、管理する対象が増えるだけで何も良くなりません。 グラフは複雑さを消す道具ではなく、複雑さを見えるようにする道具です。
グラフにすると何が手に入るか
- どこで失敗したかがわかる。 「なんかうまくいかない」が「3番目のノードで落ちている」に変わります。 これだけで直す速さが変わります。
- 途中から再開できる。 どこまで進んだかを持っているので、落ちた場所からやり直せます。 長い処理では、これが実用上いちばん効きます。
- 人が入る場所を決められる。 「送信の前で必ず止まって確認を求める」を、図の上で保証できます。 指示文で「必ず確認してから送って」とお願いするのとは、確実さが違います。
- 一部だけ差し替えられる。 あるノードだけモデルを変える、あるノードだけ手作業に戻す、といった調整ができます。
- 指示文が短くなる。 1体に全部やらせると指示が肥大化しますが、役割ごとに分ければそれぞれは短く済みます。
設計するときに詰まりやすいところ
ノードを細かく割りすぎる
最初から10個も20個もノードを作ると、つなぎの管理だけで手一杯になります。 まず3〜5個で始めて、必要になったら割るくらいがちょうどよいです。
状態をどこに持つか決めていない
ノード間で受け渡す情報が増えると、「これはどこで作られた値か」がわからなくなります。 何を持ち回すかを先に決めるのが、あとで効きます。 全部を持ち回すと、コンテキストが膨らんで費用にも跳ね返ります。
失敗の戻り先を決めていない
正常に進む線だけ引いて満足してしまい、落ちたときの矢印がない。 これはよくあります。失敗の線こそ先に引くほうが、結果的に早く動くようになります。
層として見ると、位置づけがはっきりする
ループとグラフは、AIエージェントの設計を語る5つの層のうち3番目と4番目にあたります。 内側から順に、プロンプト → コンテキスト → ループ → グラフ → ハーネス。 どれも上が下の代わりにはなりません。
- AIエージェント設計の5階層マップ — 全体像と、症状からの切り分け
- コンテキストエンジニアリング — ノード間で何を渡すかにも直結します
- ハーネスエンジニアリング — 図の外側、任せられる状態にする話
本記事は2026年8月時点で見られる用語の使われ方を整理したものです。これらの言葉は新しく、定義や範囲は書き手によって異なります。特定のフレームワークやサービスを推奨するものではありません。