Re Reference AI

エージェント

グラフエンジニアリングとは

Graph Engineering

AIエージェントシステムを、ノードとエッジからなる明示的な実行グラフとして設計する実践

自律システムワークフロー

ひとことで言うと

AIエージェントの処理を、作業単位（ノード）とつながり（エッジ）の図として明示的に組み立てる設計のこと。

概要

グラフエンジニアリングとは、AIエージェントシステムをノード（作業単位）とエッジ（遷移）のつながりとして明示的に設計する実践を指す。 ここでのグラフはグラフ理論のグラフであり、棒グラフや折れ線グラフを指さない。ノードにはLLM呼び出しだけでなく、決定的なプログラムコード、評価器、人間の承認ステップも含まれ、エッジが次に実行するノードを決め、状態（state）がステップ間で情報を引き継ぐ。 単一のエージェントループへ判断・状態・副作用が集中すると、途中からの再開や実行経路の監査が難しくなる。グラフエンジニアリングは、LLMへ任せる範囲とコードで確実に制御する範囲を線引きし、依存関係・並列化・責任境界をグラフ構造として外へ出す設計手法にあたる。 プロンプトエンジニアリング（1回の応答の制御）、コンテキストエンジニアリング（モデルへ見せるデータの制御）、ループエンジニアリング（1つのエージェントの動作サイクルの制御）に続く層として整理され、下の層を置き換えるものではない。グラフの各ノードの内側では、従来どおりループ・コンテキスト・プロンプトの設計が必要になる。

背景

初期のエージェント開発では、LLMへツール群を渡して次の行動をすべてLLMに決めさせる構成が主流だった。 この構成を実業務のシステムへ組み込むと、同じ処理を繰り返して停止しない、プロンプトへ書いた業務ルールが守られない、ステップを跨ぐ情報が失われるといった問題が起きやすい。 1つのループを磨くだけでは足りず、LLM・コード・人間という性質の異なる実行主体をどう配置しどうつなぐかという構造自体が設計の論点になったことが、グラフエンジニアリングという呼称の背景にある。

歴史

2026年7月中旬、開発者のPeter Steinbergerが「この分野はすでにループからグラフへ移行したのではないか」という趣旨の短い投稿をした。 これに機械学習エンジニアのHamel Husainが「ループエンジニアリングは終わった」と呼応し、AI開発コミュニティで急速に広まった呼称。 2026年7月4日に公開されたJosh C. Simmonsの論考は、グラフエンジニアリングを「暗黙のループではなく明示的なグラフとしてエージェントシステムを設計すること」と定義し、単一責務のノード、状態を運ぶ型付きエッジ、スキーマを持つチェックポイント可能な状態を主要な要素として挙げている。

アーキテクチャ

構成要素は、作業単位となるノード、次の実行先を決めるエッジ、ステップ間で引き継ぐ型付きの状態の3つ。 実行基盤側では、依存条件を満たしたノードを進めるスケジューラ、再開点を与えるチェックポイント、出力を検査して通過・再実行・エスカレーションを判定する評価器、影響の大きい操作を人間の承認まで止めるゲートが組み合わさる。 グラフの定義自体をバージョン管理された成果物として扱い、実行時の状態と分けて保存する構成が取られる。

ワークフロー

目的を単一責務のノードへ分解 → 依存・分岐・結合・停止条件をエッジとして定義 → 実行前に到達可能性・型整合性・権限・予算を検証してグラフ版を固定 → 実行中はノード遷移ごとに状態をチェックポイントへ保存 → 失敗時は局所再試行・再計画・人間介入へ段階的にエスカレーション。

利点

  • 独立したノードを並列に実行でき、結合点（join）を明示できるため、長いタスクの実行時間を短縮しやすい
  • 実行経路と状態遷移が構造として残るため、どこで何が起きたかを後から追跡・監査しやすい
  • チェックポイントから再開できるため、障害や人間の承認待ちで中断した処理を最初からやり直さずに済む
  • LLMへ任せる判断と、コードで確定させる処理と、人間が承認する操作の責任境界を分けて設計できる

欠点

  • ノード分割・遷移定義・バージョン管理の設計コストが増えるため、1回で完結する単純なタスクには過剰になる
  • グラフ定義を更新したとき、実行途中のランをどう扱うか（移行・ロールバック）の検討が必要になる
  • 計画側がグラフを誤って組んだ場合、個々のノードが正しく動いても全体の結果が破綻する
  • 呼称自体が2026年に広まったばかりで、設計指針やベストプラクティスの蓄積がまだ乏しい

比較

  • ループエンジニアリング — ループエンジニアリングが1つのエージェントの試行・検証・修正サイクルの設計を扱うのに対し、グラフエンジニアリングは複数のノードのつなぎ方という構造の設計を扱う。なお、ループ自体が消えるわけではなく、ノードの内側へ位置づけられる
  • ハーネスエンジニアリング — ハーネスエンジニアリングがエージェントを取り巻く環境全体（コンテキスト・ツール・ガードレール等）の設計を指すのに対し、グラフエンジニアリングは実行主体どうしの依存関係と遷移の構造化に焦点を当てる
  • コンテキストエンジニアリング — コンテキストエンジニアリングがモデルへ見せる情報の構成を扱うのに対し、グラフエンジニアリングはその情報を受け取る実行単位をどう分割しどうつなぐかを扱う
  • ナレッジグラフ — ナレッジグラフはシステムが何を知っているかを構造化した知識のグラフであり、グラフエンジニアリングが設計対象とするのはシステムが何でできているかを表す制御グラフで、両者は同じシステム内で共存する別物
  • GraphRAG — GraphRAGはナレッジグラフを検索・生成へ利用する手法であり、実行順序の制御を目的とするグラフエンジニアリングとは扱う対象が異なる
  • LangGraph — LangGraphはノードとエッジでエージェントのワークフローを定義するフレームワークであり、グラフエンジニアリングという設計思想を実装する代表的な手段のひとつ

関連用語

ループエンジニアリングハーネスエンジニアリングコンテキストエンジニアリングAIエージェントマルチエージェントLangGraphHuman-in-the-Loopワークフロー

よくある質問

ナレッジグラフやGraphRAGとの違いは？

ナレッジグラフはエンティティと関係を表す知識の構造で、GraphRAGはそれを検索・生成へ活用する手法を指す。グラフエンジニアリングが設計するのは制御グラフ、つまりどのノードがあり、誰が何を呼べるかという実行構造であり、設計対象が異なる。

どんな場合にグラフを採用すべきか？

独立して進む分岐と明示的な結合があり、失敗の影響範囲が複数に分かれ、人間の承認ステップを挟み、実行構造そのものを監査したい場合に向く。1回で完結し副作用のないタスクは単一プロンプト、手順が探索中に変わるタスクは単一のエージェントループ、手順と分岐が既知のタスクは決定的なワークフローで足り、複数エージェントが存在することだけをグラフ採用の理由にはしない。

ループエンジニアリングは不要になったのか？

置き換えではなく積み重なる層として整理される。グラフの各ノードの内側では引き続き質の高いループを動かす必要があり、各ループの内側ではコンテキストとプロンプトの設計も欠かせない。

参考文献