グラフエンジニアリングとは？AI処理の分岐・状態・実行経路を設計する

本記事では、AIアプリケーションの実行経路をノード（処理単位）・エッジ（遷移規則）・状態（共有データ）として設計する活動を、グラフエンジニアリングと呼びます。分岐、反復、並列処理、再開の経路を整理するための、実務上の呼び方です。

設計では、固定すべき手順、モデル出力を判断材料に使う箇所、人の承認が必要な操作、失敗時に止める条件を分け、処理の全体像を実装前に検討できるようにすることです。LLMへ渡す情報そのものの選び方は、コンテキストエンジニアリングもあわせて確認してください。

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

チャット型AIは、入力に対して一度回答を返すだけでも成立します。しかし、資料を読み取り、規程を検索し、結果を照合し、不足があれば追加確認を依頼し、最後に人へ渡す、といった業務は一本道では終わりません。

このときグラフは、「データ同士の関係」を描くためだけの図ではなく、アプリケーションがどの順番で何を実行するかを表す設計図になります。たとえばLangGraphは、エージェントのワークフローをグラフとして扱い、状態、ノード、エッジを中核要素として説明しています。ノードは状態を受けて処理や副作用を実行し、更新を返します。エッジは、現在の状態を基に次のノードを決めます。LangGraph Graph API overview

ただし、グラフで可視化したからといって、安全性、回答の正確性、コスト、停止性、障害復旧が自動的に保証されるわけではありません。入力検証、権限、評価、タイムアウト、反復上限、監視は別途設計します。

ノード・エッジ・状態の3要素

以下の表は本記事の設計上の整理です。具体的な実装の説明では、LangGraphの公式ドキュメントを例にします。reducer、スーパーステップ、checkpointer、storeの動作は、LangGraph固有の仕様として扱います。

ノードは「LLMを呼ぶ場所」とは限りません。ファイル形式を検査する、検索APIを呼ぶ、承認待ちにする、データベースを更新する、といった通常のプログラム処理もノードです。ノードを細かくしすぎると状態の受け渡しが複雑になり、粗すぎると失敗箇所や再実行範囲を切り分けにくくなります。まずは失敗時に別の扱いが必要になる単位で分けると判断しやすくなります。

状態は会話履歴だけではありません。処理対象のID、抽出結果、根拠文書、判定理由、試行回数、承認結果、外部操作の冪等キーなどを含めます。LangGraphでは、状態の各キーごとに更新規則（reducer）を持て、指定しないキーは更新値で置換されます。複数の処理が同じキーを更新するなら、キーごとの結合規則を先に決める必要があります。LangGraph Graph API overview

固定経路とモデルに任せる分岐の設計

最初に、分岐を次の3種類へ分けます。

1. 固定分岐：権限、必須項目、金額上限、ファイル形式など、コードや明示ルールで判定できるもの。
2. モデル支援分岐：文書の分類、不足情報の推定、照合候補の選択など、モデルの判断を使うが、候補遷移と出力形式はアプリ側で制限するもの。
3. 人の承認分岐：対象業務の基準に照らし、人の判断を挟むと決めた操作。送信・登録・削除などの外部操作では、影響範囲と取り消しやすさを基に判断します。

モデル支援分岐では、自由文の「次はこれをすべきです」をそのまま実行しません。たとえば判定値を match、needs_review、insufficient のような構造化した選択肢に限定し、各値に対応する遷移先、失敗時の遷移先、最大反復回数を実装側で決めます。

また、同じノードから固定エッジと動的ルーティングを混在させると、意図しない経路まで実行され、挙動を追いにくくなります。LangGraphの公式ドキュメントも、ノードごとに固定遷移か動的ルーティングのいずれかを選ぶよう案内しています。LangGraph Graph API overview

架空の例：文書照合フローをグラフにする

以下は、申請書と社内規程を照合する架空の例です。実際の規程、権限、モデル、入力品質によって設計は変わります。

この例での状態は、request_id、document_version、extracted_fields、evidence、decision、review_result、retry_count、idempotency_key のように分けられます。特に、規程の版IDと根拠箇所を残さなければ、後から「どの情報を基に判定したか」を追いにくくなります。

状態の更新・並列処理・合流で起きる問題

検索、抽出、リスク検査などを並列化すると待ち時間を短縮できる場合があります。一方、複数ノードが同じ状態キーへ同時に書き込むと、どちらの値を残すか、順序で結果が変わらないか、重複が発生しないかを決めなければなりません。LangGraphでは、一つのノードから複数の出力エッジを持たせた場合、宛先ノードは次のスーパーステップで並列実行されます。LangGraph Graph API overview

本記事の提案として、並列合流の前に次の3点を状態キーごとに確認してください。

• 所有者：最終値を確定できるノードは一つか。
• マージ規則：置換、追記、集合化、優先順位付き採用のどれか。
• 順序依存性：実行順が変わっても同じ結果になるか。

たとえば、evidence は根拠一覧として追記し、decision は照合判定ノードだけが確定する、と分離します。複数ノードの出力を単純に一つの result キーへ書き込む設計は、後から競合の原因を特定しにくくなります。

チェックポイントと処理の再開

長時間処理や人の確認を含むフローでは、「どこまで完了したか」を残して再開できるようにします。LangGraphの永続化機能では、checkpointerはスレッド単位のグラフ状態をチェックポイントとして保存し、storeはグラフ状態の外にある、スレッド横断の長期データを保存するものとして区別されています。再開用の状態と、利用者の恒久的な設定・共有知識を同じ場所に混ぜないための参考になります。LangGraph Persistence

再開時の注意は副作用です。LangGraphでは、チェックポイントはノード関数の途中ではなくスーパーステップ境界で保存されます。停止後の再開で該当ノードが先頭から再実行されることがあるため、データベース登録、メール送信、外部API更新を行うノードには、冪等キー、upsert、read-before-writeなどを検討します。LangGraph Graph API overview

GraphRAGとの違い

名称は似ていますが、グラフエンジニアリングで扱うグラフは主に処理の実行経路です。一方、GraphRAGで扱うのは主に知識の関係です。MicrosoftのGraphRAGは、生テキストから知識グラフを抽出し、コミュニティ階層と要約を作成して、検索拡張生成で利用するアプローチです。Microsoft GraphRAG Documentation

両方を組み合わせることは可能です。たとえば、実行経路のグラフ内に「GraphRAGで根拠を検索する」ノードを置けます。ただし、どちらが有効かは、質問の種類、入力文書の構造、知識グラフの品質、評価指標、許容できる遅延とコストで変わります。知識グラフを用いるRAGの設計は、Graph RAGと従来RAGの違いで詳しく解説しています。

ノード設計シートとまとめ

最後に、実装前のレビューで使えるMojiによる提案の設計シートを示します。各ノードについて、空欄を残さずに埋められるか確認してください。

着手時のチェックリストは次のとおりです。

• 固定ルール、人の承認、モデル支援判断を分けたか。
• 状態キーごとに、所有者と更新・結合規則を決めたか。
• 条件付き分岐に、根拠不足・失敗・上限到達の遷移先があるか。
• 外部操作を含むノードの再実行対策を設計したか。
• 処理経路だけでなく、評価指標、権限、タイムアウト、監視を別途定義したか。

グラフエンジニアリングでは、AIが判断する範囲とアプリケーション側で制御する範囲を分け、失敗しても止められ、原因を追え、必要なら途中から安全に再開できる実行経路にすることです。