PR
私が使っているPCガジェット類
作業環境で実際に使っている・気になっている周辺機器などをまとめました
※ 一部のリンクは広告(アフィリエイト)を含みます
グラフエンジニアリングとは ノードとエッジで組む設計
ループエンジニアリングを調べ終えたばかりなのに、もう次の言葉が出てきた
そんな順番でこのページにたどり着いた方も多いと思います
今回のテーマはグラフエンジニアリングです
グラフエンジニアリングとは何か、ひとことで答えるならAIの仕事をノードとエッジに切り分けて、つなぎ方まで決めておく設計の考え方です
1体のAIをどう回すかではなく、複数の担当と受け渡しをどう組むかを扱います
この記事は「AIの◯◯エンジニアリング」連載の5本目です
前回のエージェントループが「時間軸でどう回すか」だったのに対して、今回は構造軸でどう組むかの話になります
この言葉が一気に広まったきっかけは、実は冗談の投稿でした
ただ、中身まで冗談ではありません
ジャベ雄聞き慣れない言葉ばかりですが、やっていることは仕事の分担と同じです
目次
グラフエンジニアリングとは？まず結論から
結論から言うと、AIの仕事を点と線のつながりとして書き出しておく営みです
点がノード、線がエッジ、そのあいだを流れる情報が状態です
グラフエンジニアリングとは、AIエージェント・ツール・人の承認をノード(点)として置き、つながりをエッジ(線)で結ぶ枠組みです
実行の順序・条件分岐・並列処理・失敗したときの戻り先を、1枚の図にまとめます
よく出てくる「有向グラフ」は、点と線を向き付きでつないだ図のことです
棒グラフや折れ線グラフとは別物です
では、なぜ書き出すのか？
1つの流れに判断も情報も外への操作も詰め込むと、途中で止まったときどこから再開すればいいのかが分からなくなります
切り分けておけば、止まった点だけをやり直せます
ジャベ雄この3語、仕事の役割分担をそのまま言い換えただけなんです
ループエンジニアリングとの違い 時間軸と構造軸
ループエンジニアリングが設計するのは時間軸です
1体のAIをどう回し続けるかを扱います
グラフエンジニアリングが設計するのは構造軸のほう、複数の担当をどう並べてつなぐかです
スクロールできます
| 観点 | ループエンジニアリング(連載#4) | グラフエンジニアリング(連載#5) |
|---|---|---|
| 設計する軸 | 時間軸:どう回すか | 構造軸:どう組むか |
| 対象 | 1体のエージェントを自走させる | 複数のループ・ツール・人をつなぐ |
| 中身のイメージ | 実行→検証→改善の繰り返し | 開始→並列で作業→集約と検証→出力 |
| もう一方との関係 | グラフの1つのノードになる | ループを内側に持つ調整の役 |
押さえたいのは、2つが置き換えではなく包含の関係だという点です
ループは消えません
1体のAIが回している輪が、そのままグラフの1つの点に収まります
グラフを「多くのループにまたがる調整のレイヤー」と呼ぶ解説もありました
資料づくりで言うと、書いた人が「直して出し直す」を繰り返しているのがループです
その人を含めた全員の担当と受け渡しを決めるのがグラフになります
担当が1人なら、そもそも線を引く必要がありません
あわせて読みたい
エージェントループとは 推論と行動を繰り返す仕組み
AIエージェントが自分で考えて動き続ける正体がエージェントループです この記事では推論 行動 観測を停止条件まで繰り返す基本のしくみを ReActの由来やClaude Codeの実例とあわせて解説し 後半では2026年に登場したループエンジニアリングという新しい考え方も等身大で紹介します
連載#4でも書いたとおり、この界隈の言葉はまだ線引きが固まっていません
2026年8月の時点で、ループエンジニアリングでも2か月・グラフはまだ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つ目のループ回帰が、さっきの包含の関係です
ジャベ雄エッジを「矢印」でなく「取り決め」と読み替えるのが、いちばんの山です
AIで仕事を減らしたい方へPR
AI鬼管理｜Claude Code活用の業務自動化トレーニング
Claude Code を業務の自動化に使うためのトレーニングです
いきなり申し込む形ではなく、まずは無料の業務効率化診断(オンライン面談)から始められます
言葉の出どころ 論考が先で 冗談で火が付いた
この順番を取り違えやすいので、日付で並べます
スクロールできます
| 日付 | 出来事 |
|---|---|
| 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日の論考は「エージェントループが十分に良くなった結果、自分の天井が見えてしまった」と書いています
この限界はモデルの質とは関係ない、次は複数をどうつなぐかだ、という主張です
「冗談から生まれた言葉」の部分だけを切り取ると、話が逆さまになります
論考が先・冗談があと・指している中身はもっと前からある
この3段で覚えておくと間違えません
実装のほうが言葉より2年半早い
スクロールできます
| フレームワーク | 提供元 | 立ち位置 |
|---|---|---|
| LangGraph | LangChain | 2024年1月に立ち上げ、動的なグラフを組む実装として定番、v1.0 で本番向けに |
| AutoGen GraphFlow | Microsoft | 実験的な機能、DiGraphBuilder で宣言的に組む |
| Google ADK 2.0 | 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 から入れる形です
私はグラフのフレームワーク自体は触っていないので、名前を挙げるだけにとどめます
ジャベ雄2026年8月の時点で、言葉はひと月・実装は2年半です
この差を知っておくと落ち着いて読めます
冷静な見方 ほとんどのエージェントには要らないという声
Turing Post は、この概念は新しくないとはっきり書いています
ループはすでにグラフの一種ですし、状態機械や DAG(向きがあって一周しない図)は数十年前からあるものです
2年半という数字はAI向けの道具に限った話で、考え方まで遡れば数十年になります
Turing Post には、ほかに次の2点も書かれています
- 「Microsoft と Stanford と Anthropic が同時に発見した」という言われ方には根拠がない
- ほとんどのエージェントに、グラフのフレームワークは要らない
出典はIs Graph Engineering Real?(Turing Post)です
最初期の記事と並べて読むと、温度差がはっきり出ます
もう1つ、日本語の指摘で納得したものです
配線をどれだけ賢くしても、1つ1つのノードの判定が甘ければ、複雑な配線は間違った方向に速く進む装置にしかならない
つなぎ方より、ノードが出す答えの質が先だ、という主張です
これは書き手の意見ですが、私が読んだ範囲では中身が濃かったです
出典はループエンジニアリングの次は本当に「グラフ」なのか考えてみた(Zenn)です
グラフにする / しないの見分け方
線を引くかどうかの判断材料が、解説記事に出ていました
グラフにしたほうがいい(4つのうち2つ以上あてはまるなら検討)
- 専門性の分割:役割の違う担当に分けたい
- 並列処理:同時に走らせたい作業がある
- 監査ルーティング:あとから経路をたどりたい
- 成功基準の変化:途中で合否の基準が変わる
ほかに、独立した枝が複数あるとき・複数の担当が連携するとき・数分を超える待ち時間があるとき・権限の違う操作が混じるときも挙がっていました
単純なままのほうがいい
- 1〜3ステップで終わる短い作業
- 完全に決まりきった手順(そもそもAIでなくても済む)
- 進めながら手順が変わる(先に固定の線を引けない)
- 担当を分けると、同じ大きな文脈を全員に配り直す手間のほうが上回る
3つ目だけ補足します
動的に線を組み替えられる道具もあるので、手順が変わる=グラフにできない、ではありません
ただし組み替えを前提にすると、設計のほうが重くなります
判断の軸は分担する理由があるかどうかに集約されます
元にした記事はグラフエンジニアリングとは？(AI総合研究所、2026年7月28日)で、私が見た限りでは日本語の解説でいちばん詳しかったです
私はまだ線を引くほどの規模ではありません
それでも3語を知っていると、解説を読む速さが変わります
ジャベ雄迷ったら、まず線を引かずに1本の流れで書いてみるのがおすすめです
まとめ グラフエンジニアリングの要点と連載ナビ
グラフエンジニアリングとは、AIの仕事をノード・エッジ・状態に分けて、つなぎ方まで決めておく設計の考え方でした
- ノード(担当)・エッジ(取り決め)・状態(共有の進捗表)の3つで組む
- エッジは矢印ではなく、渡すもの・条件・許す操作・失敗時の扱いまで含む取り決め
- ループとは包含の関係、ループはグラフの1つのノードとして収まる
- 広まったきっかけは2026年7月18日の冗談の投稿、ただし論考は7月4日で先
- 実装は言葉より2年半早い(LangGraph は2024年1月)
- ほとんどのエージェントにグラフのフレームワークは要らない、という指摘もある
最後に、いちばん持ち帰ってほしいことです
新しい「◯◯エンジニアリング」が出てきたら、結局、何のノードと何のエッジの話をしているのかに分解して読む
これを覚えておけば、名前が変わっても中身は追えます
この読み方はグラフエンジニアリングを知ろう(Qiita、2026年8月6日)が勧めていたものです
グラフエンジニアリングは、ループエンジニアリングに取って代わるもの？
置き換えではなく包含の関係です
ループは無くならず、グラフの中の1つのノードとして収まります
ループを先に押さえてからで間に合います
実装しない立場でも、覚えておいたほうがいい？
ノード・エッジ・状態の3語だけ押さえておけば、解説を読むぶんには足ります
ただ広まってからひと月ほどの呼び方なので、定義が変わる前提で見ておくのがおすすめです
この記事は連載「AIの◯◯エンジニアリング」の1本です
全体を1枚で見たいときはハブからどうぞ
あわせて読みたい
AIエンジニアリング5種の違い コンテキストからグラフまで
AIの使いこなしは プロンプト コンテキスト ハーネス ループ グラフ の5段階で進化してきました それぞれ何を設計する技術なのか どう違うのかを1枚の地図で俯瞰し 単発チャットから複数エージェントの編成までの流れをつかめるようにまとめた総論です
5本を通して読むと、AIの作り込みが指示文→渡す材料→器→回し方→つなぎ方と外側へ広がってきた流れが見えます
最後に・・・
PythonとExcelを中心に仕事に役立つ業務ツールや自動化、スクレイピングツールの作成を受注していて、クラウドワークスでは気が付けば100件以上のお仕事を受注してきました！
会社員をやりながらの副業なので時間の捻出は相応ですが、クライアントの方々と近い立場でこちらからも提案しながら活動していますのでお悩みあれば是非ご相談ください
コメント