グラフエンジニアリングとは ノードとエッジで組む設計

ループエンジニアリングを調べ終えたばかりなのに、もう次の言葉が出てきた
そんな順番でこのページにたどり着いた方も多いと思います
今回のテーマはグラフエンジニアリングです

グラフエンジニアリングとは何か、ひとことで答えるならAIの仕事をノードとエッジに切り分けて、つなぎ方まで決めておく設計の考え方です
1体のAIをどう回すかではなく、複数の担当と受け渡しをどう組むかを扱います

この記事は「AIの◯◯エンジニアリング」連載の5本目です
前回のエージェントループが「時間軸でどう回すか」だったのに対して、今回は構造軸でどう組むかの話になります

この言葉が一気に広まったきっかけは、実は冗談の投稿でした
ただ、中身まで冗談ではありません

グラフエンジニアリングとは？まず結論から

結論から言うと、AIの仕事を点と線のつながりとして書き出しておく営みです
点がノード、線がエッジ、そのあいだを流れる情報が状態です

よく出てくる「有向グラフ」は、点と線を向き付きでつないだ図のことです
棒グラフや折れ線グラフとは別物です

では、なぜ書き出すのか？
1つの流れに判断も情報も外への操作も詰め込むと、途中で止まったときどこから再開すればいいのかが分からなくなります
切り分けておけば、止まった点だけをやり直せます

ループエンジニアリングとの違い 時間軸と構造軸

ループエンジニアリングが設計するのは時間軸です
1体のAIをどう回し続けるかを扱います
グラフエンジニアリングが設計するのは構造軸のほう、複数の担当をどう並べてつなぐかです

観点	ループエンジニアリング(連載#4)	グラフエンジニアリング(連載#5)
設計する軸	時間軸:どう回すか	構造軸:どう組むか
対象	1体のエージェントを自走させる	複数のループ・ツール・人をつなぐ
中身のイメージ	実行→検証→改善の繰り返し	開始→並列で作業→集約と検証→出力
もう一方との関係	グラフの1つのノードになる	ループを内側に持つ調整の役

押さえたいのは、2つが置き換えではなく包含の関係だという点です
ループは消えません
1体のAIが回している輪が、そのままグラフの1つの点に収まります

グラフを「多くのループにまたがる調整のレイヤー」と呼ぶ解説もありました

資料づくりで言うと、書いた人が「直して出し直す」を繰り返しているのがループです
その人を含めた全員の担当と受け渡しを決めるのがグラフになります
担当が1人なら、そもそも線を引く必要がありません

ノード・エッジ・状態 3つの部品を噛み砕く

この3語さえ握っておけば、英語の解説を開いても迷子になりません

ノードは「1つのことだけをやる担当」

置かれるのは、だいたい次の粒度になります

• AIに1回考えさせる(下書きを作る・要約する)
• ツールを動かす(検索する・APIを呼ぶ・コードを走らせる)
• 検証役(evaluator)として、前のノードの出来を判定する
• 人の承認(human gate)として、進めていいかを人に聞く

1つのノードにあれもこれも詰め込まないのがコツです
最初にこの言葉を使った記事も、ノードは退屈なくらい単純がいいと書いています
資料づくりでいえば、書く人とチェックする人を兼ねさせないことです

エッジは矢印ではなく「取り決め」

エッジは矢印ではなく、ノードとノードのあいだで交わす取り決めのことです
線1本に、次の4つがぶら下がります

• 渡すもの・受け取るもののかたち(項目や型)
• どういう条件のときに、その線を通るのか
• そのノードが外に対してやっていい操作の範囲
• 失敗したときの扱い(前へ戻すのか・別の線へ逃がすのか)

資料づくりなら「書き終えたら声をかける」だけでは足りません
誤字を直してから渡す・内容が薄ければ書き直しに戻す、そこまで決めるのがエッジです

状態は「途中から再開できるようにする進捗表」

状態は、ノードのあいだで共有される情報です
会話の履歴をそのまま抱える形と、項目を決めた表のように持つ形があります

差が出るのは、状態を会話ログから切り離すかどうかです
切り離してあると、止まっても最後に保存した地点から再開できます
あとから「どの時点で何が入っていたか」もたどれます

共有フォルダの進捗表と同じです
誰でも読める場所に進み具合を書いておけば、担当が抜けても続きから入れます
会話の中だけで進めると、それが残りません

ノード・エッジ・状態という整理は、We Are Entering the Graph Engineering Phase(Josh C. Simmons、2026年7月4日)でも示されています

エッジで表せる4つの形

複雑そうな構成も、たいていこの組み合わせです

形	どういう線か	仕事でいうと
順次実行	A が終わったら B へ進む	下書きができてからチェックに回す
条件分岐	結果によって B か C かを選ぶ	内容が薄ければ差し戻し・問題なければ承認へ
並列分岐と合流	同時に走らせて、最後に集める	章を手分けして書いて、最後に1本にまとめる
ループ回帰	前のノードへ戻す	直しが必要なら書いた人に戻す

4つ目のループ回帰が、さっきの包含の関係です

言葉の出どころ 論考が先で 冗談で火が付いた

この順番を取り違えやすいので、日付で並べます

日付	出来事
2026年6月7日	Addy Osmani 氏の記事で「ループエンジニアリング」という呼び方が広まる
2026年7月4日	Josh C. Simmons 氏が「We Are Entering the Graph Engineering Phase」を公開、用語の最初期の使用として確認できる真面目な論考
2026年7月18日	Peter Steinberger 氏が X に一行だけ投稿、「まだループの話をしてるの？もうグラフに移った？」という皮肉
2026年7月18日(数時間後)	Hamel Husain 氏が「ループエンジニアリングは死んだ、グラフエンジニアリングの時代だ」と投稿、これも冗談
7月18日から数日のうちに	講座・ロードマップ・ツール一覧・解説スレッドが出そろう
7月22日〜8月6日	日本語の解説記事が相次いで公開される

皮肉の的になったのは、業界が数か月ごとに同じ営みを改名し続けることでした
ループエンジニアリングが広まって、まだ6週間ほどのタイミングです
「もう次の名前に移ったの？」という揶揄でした

この2つの投稿は、新しい製品やモデルの発表をきっかけに起きたものではありません

ただ、冗談が出発点だったわけではありません
2週間前の7月4日の論考は「エージェントループが十分に良くなった結果、自分の天井が見えてしまった」と書いています
この限界はモデルの質とは関係ない、次は複数をどうつなぐかだ、という主張です

実装のほうが言葉より2年半早い

フレームワーク	提供元	立ち位置
LangGraph	LangChain	2024年1月に立ち上げ、動的なグラフを組む実装として定番、v1.0 で本番向けに
AutoGen GraphFlow	Microsoft	実験的な機能、DiGraphBuilder で宣言的に組む
Google ADK 2.0	Google	Workflow Runtime でグラフベースに統一、Python版が2026年5月19日・Go版が2026年6月30日にGA
Claude Agent SDK	Anthropic	サブエージェントを中心にした統合ランタイム
Claude Code の動的ワークフロー	Anthropic	agent() と pipeline() を組み合わせてグラフを構成する(JavaScriptで記述)

LangGraph は2024年1月なので、言葉より2年半ほど先に実装があったことになります
新しい言葉が出た=新しい技術が出た、とは限りません

身近なところだと、Claude Code にも複数のエージェントをつなぐ仕組みがあります
公式ドキュメントによると、有料プラン向けで v2.1.154 以降が要ります
Pro は既定でオフなので、/config の Dynamic workflows から入れる形です
私はグラフのフレームワーク自体は触っていないので、名前を挙げるだけにとどめます

冷静な見方 ほとんどのエージェントには要らないという声

Turing Post は、この概念は新しくないとはっきり書いています
ループはすでにグラフの一種ですし、状態機械や DAG(向きがあって一周しない図)は数十年前からあるものです

2年半という数字はAI向けの道具に限った話で、考え方まで遡れば数十年になります

Turing Post には、ほかに次の2点も書かれています

• 「Microsoft と Stanford と Anthropic が同時に発見した」という言われ方には根拠がない
• ほとんどのエージェントに、グラフのフレームワークは要らない

出典はIs Graph Engineering Real?(Turing Post)です
最初期の記事と並べて読むと、温度差がはっきり出ます

もう1つ、日本語の指摘で納得したものです
配線をどれだけ賢くしても、1つ1つのノードの判定が甘ければ、複雑な配線は間違った方向に速く進む装置にしかならない
つなぎ方より、ノードが出す答えの質が先だ、という主張です

これは書き手の意見ですが、私が読んだ範囲では中身が濃かったです
出典はループエンジニアリングの次は本当に「グラフ」なのか考えてみた(Zenn)です

グラフにする / しないの見分け方

線を引くかどうかの判断材料が、解説記事に出ていました

ほかに、独立した枝が複数あるとき・複数の担当が連携するとき・数分を超える待ち時間があるとき・権限の違う操作が混じるときも挙がっていました

3つ目だけ補足します
動的に線を組み替えられる道具もあるので、手順が変わる=グラフにできない、ではありません
ただし組み替えを前提にすると、設計のほうが重くなります

判断の軸は分担する理由があるかどうかに集約されます
元にした記事はグラフエンジニアリングとは？(AI総合研究所、2026年7月28日)で、私が見た限りでは日本語の解説でいちばん詳しかったです

私はまだ線を引くほどの規模ではありません
それでも3語を知っていると、解説を読む速さが変わります

まとめ グラフエンジニアリングの要点と連載ナビ

グラフエンジニアリングとは、AIの仕事をノード・エッジ・状態に分けて、つなぎ方まで決めておく設計の考え方でした

• ノード(担当)・エッジ(取り決め)・状態(共有の進捗表)の3つで組む
• エッジは矢印ではなく、渡すもの・条件・許す操作・失敗時の扱いまで含む取り決め
• ループとは包含の関係、ループはグラフの1つのノードとして収まる
• 広まったきっかけは2026年7月18日の冗談の投稿、ただし論考は7月4日で先
• 実装は言葉より2年半早い(LangGraph は2024年1月)
• ほとんどのエージェントにグラフのフレームワークは要らない、という指摘もある

最後に、いちばん持ち帰ってほしいことです
新しい「◯◯エンジニアリング」が出てきたら、結局、何のノードと何のエッジの話をしているのかに分解して読む
これを覚えておけば、名前が変わっても中身は追えます

この読み方はグラフエンジニアリングを知ろう(Qiita、2026年8月6日)が勧めていたものです

この記事は連載「AIの◯◯エンジニアリング」の1本です
全体を1枚で見たいときはハブからどうぞ

• 連載#1:指示文の書き方を5つのコツで整える
• 連載#2:AIに渡す材料を選び直す
• 連載#3:AIを取り囲む器のほうを整える
• 連載#4:AIが自分で考えて動き続ける輪のしくみ

5本を通して読むと、AIの作り込みが指示文→渡す材料→器→回し方→つなぎ方と外側へ広がってきた流れが見えます