PR
私が使っているPCガジェット類
作業環境で実際に使っている・気になっている周辺機器などをまとめました
※ 一部のリンクは広告(アフィリエイト)を含みます
作業環境で実際に使っている・気になっている周辺機器などをまとめました
※ 一部のリンクは広告(アフィリエイト)を含みます
ループエンジニアリングを調べ終えたばかりなのに、もう次の言葉が出てきた
そんな順番でこのページにたどり着いた方も多いと思います
今回のテーマはグラフエンジニアリングです
グラフエンジニアリングとは何か、ひとことで答えるならAIの仕事をノードとエッジに切り分けて、つなぎ方まで決めておく設計の考え方です
1体のAIをどう回すかではなく、複数の担当と受け渡しをどう組むかを扱います
この記事は「AIの◯◯エンジニアリング」連載の5本目です
前回のエージェントループが「時間軸でどう回すか」だったのに対して、今回は構造軸でどう組むかの話になります
この言葉が一気に広まったきっかけは、実は冗談の投稿でした
ただ、中身まで冗談ではありません
ジャベ雄聞き慣れない言葉ばかりですが、やっていることは仕事の分担と同じです
結論から言うと、AIの仕事を点と線のつながりとして書き出しておく営みです
点がノード、線がエッジ、そのあいだを流れる情報が状態です
グラフエンジニアリングとは、AIエージェント・ツール・人の承認をノード(点)として置き、つながりをエッジ(線)で結ぶ枠組みです
実行の順序・条件分岐・並列処理・失敗したときの戻り先を、1枚の図にまとめます
よく出てくる「有向グラフ」は、点と線を向き付きでつないだ図のことです
棒グラフや折れ線グラフとは別物です
では、なぜ書き出すのか?
1つの流れに判断も情報も外への操作も詰め込むと、途中で止まったときどこから再開すればいいのかが分からなくなります
切り分けておけば、止まった点だけをやり直せます



この3語、仕事の役割分担をそのまま言い換えただけなんです
ループエンジニアリングが設計するのは時間軸です
1体のAIをどう回し続けるかを扱います
グラフエンジニアリングが設計するのは構造軸のほう、複数の担当をどう並べてつなぐかです


| 観点 | ループエンジニアリング(連載#4) | グラフエンジニアリング(連載#5) |
|---|---|---|
| 設計する軸 | 時間軸:どう回すか | 構造軸:どう組むか |
| 対象 | 1体のエージェントを自走させる | 複数のループ・ツール・人をつなぐ |
| 中身のイメージ | 実行→検証→改善の繰り返し | 開始→並列で作業→集約と検証→出力 |
| もう一方との関係 | グラフの1つのノードになる | ループを内側に持つ調整の役 |
押さえたいのは、2つが置き換えではなく包含の関係だという点です
ループは消えません
1体のAIが回している輪が、そのままグラフの1つの点に収まります
グラフを「多くのループにまたがる調整のレイヤー」と呼ぶ解説もありました
資料づくりで言うと、書いた人が「直して出し直す」を繰り返しているのがループです
その人を含めた全員の担当と受け渡しを決めるのがグラフになります
担当が1人なら、そもそも線を引く必要がありません


連載#4でも書いたとおり、この界隈の言葉はまだ線引きが固まっていません
2026年8月の時点で、ループエンジニアリングでも2か月・グラフはまだ1か月ほどの呼び方です
来年には別の言い方に吸収されているかもしれません
この3語さえ握っておけば、英語の解説を開いても迷子になりません


置かれるのは、だいたい次の粒度になります
1つのノードにあれもこれも詰め込まないのがコツです
最初にこの言葉を使った記事も、ノードは退屈なくらい単純がいいと書いています
資料づくりでいえば、書く人とチェックする人を兼ねさせないことです
エッジは矢印ではなく、ノードとノードのあいだで交わす取り決めのことです
線1本に、次の4つがぶら下がります
資料づくりなら「書き終えたら声をかける」だけでは足りません
誤字を直してから渡す・内容が薄ければ書き直しに戻す、そこまで決めるのがエッジです
状態は、ノードのあいだで共有される情報です
会話の履歴をそのまま抱える形と、項目を決めた表のように持つ形があります
差が出るのは、状態を会話ログから切り離すかどうかです
切り離してあると、止まっても最後に保存した地点から再開できます
あとから「どの時点で何が入っていたか」もたどれます
共有フォルダの進捗表と同じです
誰でも読める場所に進み具合を書いておけば、担当が抜けても続きから入れます
会話の中だけで進めると、それが残りません
ノード・エッジ・状態という整理は、We Are Entering the Graph Engineering Phase(Josh C. Simmons、2026年7月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日の論考は「エージェントループが十分に良くなった結果、自分の天井が見えてしまった」と書いています
この限界はモデルの質とは関係ない、次は複数をどうつなぐかだ、という主張です
「冗談から生まれた言葉」の部分だけを切り取ると、話が逆さまになります
論考が先・冗談があと・指している中身はもっと前からある
この3段で覚えておくと間違えません
| フレームワーク | 提供元 | 立ち位置 |
|---|---|---|
| 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点も書かれています
出典はIs Graph Engineering Real?(Turing Post)です
最初期の記事と並べて読むと、温度差がはっきり出ます
もう1つ、日本語の指摘で納得したものです
配線をどれだけ賢くしても、1つ1つのノードの判定が甘ければ、複雑な配線は間違った方向に速く進む装置にしかならない
つなぎ方より、ノードが出す答えの質が先だ、という主張です
これは書き手の意見ですが、私が読んだ範囲では中身が濃かったです
出典はループエンジニアリングの次は本当に「グラフ」なのか考えてみた(Zenn)です
線を引くかどうかの判断材料が、解説記事に出ていました
グラフにしたほうがいい(4つのうち2つ以上あてはまるなら検討)
ほかに、独立した枝が複数あるとき・複数の担当が連携するとき・数分を超える待ち時間があるとき・権限の違う操作が混じるときも挙がっていました
単純なままのほうがいい
3つ目だけ補足します
動的に線を組み替えられる道具もあるので、手順が変わる=グラフにできない、ではありません
ただし組み替えを前提にすると、設計のほうが重くなります
判断の軸は分担する理由があるかどうかに集約されます
元にした記事はグラフエンジニアリングとは?(AI総合研究所、2026年7月28日)で、私が見た限りでは日本語の解説でいちばん詳しかったです
私はまだ線を引くほどの規模ではありません
それでも3語を知っていると、解説を読む速さが変わります



迷ったら、まず線を引かずに1本の流れで書いてみるのがおすすめです
グラフエンジニアリングとは、AIの仕事をノード・エッジ・状態に分けて、つなぎ方まで決めておく設計の考え方でした
最後に、いちばん持ち帰ってほしいことです
新しい「◯◯エンジニアリング」が出てきたら、結局、何のノードと何のエッジの話をしているのかに分解して読む
これを覚えておけば、名前が変わっても中身は追えます
この読み方はグラフエンジニアリングを知ろう(Qiita、2026年8月6日)が勧めていたものです
置き換えではなく包含の関係です
ループは無くならず、グラフの中の1つのノードとして収まります
ループを先に押さえてからで間に合います
ノード・エッジ・状態の3語だけ押さえておけば、解説を読むぶんには足ります
ただ広まってからひと月ほどの呼び方なので、定義が変わる前提で見ておくのがおすすめです
この記事は連載「AIの◯◯エンジニアリング」の1本です
全体を1枚で見たいときはハブからどうぞ


5本を通して読むと、AIの作り込みが指示文→渡す材料→器→回し方→つなぎ方と外側へ広がってきた流れが見えます
PythonとExcelを中心に仕事に役立つ業務ツールや自動化、スクレイピングツールの作成を受注していて、クラウドワークスでは気が付けば100件以上のお仕事を受注してきました!
会社員をやりながらの副業なので時間の捻出は相応ですが、クライアントの方々と近い立場でこちらからも提案しながら活動していますのでお悩みあれば是非ご相談ください
VBAとPythonを中心にユーザー側でできるITを自己学習しているので備忘録半分、学習履歴を残して同じ道を辿る人の参考になればとブログを始めました
副業でスクレイピングツール作成を中心にできることを色々やっていますのでご相談いただけるとありがたいです!
クラウドワークスのページへ
ココナラのページへ
コメント