Graph Engineering 2026年8月12日
ワークフローグラフ設計:ノード・エッジ・状態をどう分けるか
AIワークフローを保守可能なグラフにするためのノード分割、状態スキーマ、条件分岐、チェックポイント、経路テストの設計方法を解説します。
難易度開発の実務経験がある方向けです種別リファレンス
先に業務フローを書く
フレームワークのAPIから設計を始めると、ノードが技術都合で分割されます。まず「誰が、何を確認し、何を次へ渡すか」を書き出します。
依頼受付
↓
要件確認 ─ 不足 → 人間へ質問
↓ 十分
調査 → 執筆 → 事実確認
├ 合格 → 公開承認
└ 不合格 → 執筆へ戻す
ここから、責務、状態、遷移条件を抽出します。
ノードの分割基準
次のいずれかが変わる場所でノードを分けます。
- 実行主体が変わる
- 必要な権限が変わる
- 入出力形式が変わる
- 成否判定が変わる
- 再試行単位が変わる
- 人間承認が必要になる
「1プロンプトで全部やる」は、途中検証と部分再実行ができないため、長い業務フローには向きません。
ノード契約
各ノードは、入力、出力、副作用、エラーを定義します。
type ResearchInput = {
question: string;
allowedDomains: readonly string[];
};
type ResearchOutput = {
findings: readonly {
claim: string;
sourceUrl: string;
}[];
};
モデルの自由文をそのまま次ノードへ渡すより、境界で検証した構造化データを渡す方が、分岐と再実行を安定させます。
状態は最小限にする
グラフ状態へ全ログを詰め込まず、制御に必要な情報と成果物への参照を保持します。
type WorkflowState = {
runId: string;
inputVersion: string;
currentPhase: string;
artifactRefs: readonly string[];
decisions: readonly {
node: string;
outcome: string;
}[];
};
大きな調査結果やバイナリは外部ストレージへ置き、状態には参照を保存します。
エッジを3種類に分ける
固定エッジ
常に次の工程へ進みます。
normalize → validate
条件エッジ
構造化された判定値で経路を選びます。
validate --passed--> publish_review
--failed--> revise
動的エッジ
実行時に必要なサブタスクや並列数が変わります。入力から安全な実行計画を生成し、許可されたノードだけでグラフを展開します。
決定論的ルーターを優先する
type ReviewResult = {
status: "passed" | "needs_revision" | "needs_human";
};
const selectNextNode = (result: ReviewResult): string => {
const routes: Record<ReviewResult["status"], string> = {
passed: "publish_review",
needs_revision: "revise",
needs_human: "human_review",
};
return routes[result.status];
};
モデルに任せるのはstatusの分類までとし、実行可能な次ノードはコードで制限します。
チェックポイントを置く場所
- 長時間ノードの完了後
- 外部副作用の直前と直後
- 並列処理の合流点
- 人間承認の直前
- 再試行ループへ入る前
チェックポイントには、状態だけでなく入力版と実行済み副作用も記録します。
経路をテストする
ノードの単体テストに加え、グラフの経路をテストします。
- 正常系が終了ノードへ到達する
- 検証失敗が修正ノードへ戻る
- 高リスク入力が承認ノードを迂回しない
- 最大再試行後に停止する
- 並列枝の一部失敗で正しい復旧経路へ進む
- 再開時に完了済み副作用を重複実行しない
複雑化のサイン
次の状態になったらグラフを分割します。
- 1ノードが複数の業務責務を持つ
- 共有状態の多くを全ノードが読み書きする
- どの経路が実行されたか説明できない
- 1つの変更で多数の経路テストが壊れる
- サブグラフとして再利用できるまとまりがある