AI活用ナビゲーターの ワケハト です。Graphは、AIをたくさん並べるための組織図ではありません。仕事の分岐、並列、合流、差し戻し、人間承認を、実行できる道として描くための構造です。
前回は、1体のエージェントが失敗テストを直すLoopを見ました。今回は、調査・執筆・根拠確認・承認を分けたい観光FAQを使い、Graphが必要になる境界を理解します。
3層の地図ではどこにいるか
| 層 | この回で使うもの |
|---|---|
| 判断品質 | 公式情報、営業時間、家族条件をContextにする |
| 実行構造 | Research → Merge → Draft → FactCheck → Human Gate |
| 運用品質 | 根拠ID、経路ログ、差し戻し、公開前承認 |
Graphも実行構造だけでは成立しません。ノードへ渡す情報と、各ノードを通過させる合格条件を3層から組み合わせます。
Graphをひとことで言うと
Graph Engineeringは、複数の工程と、そのあいだの経路を実行前に地図として設計することです。ここでは製品名ではなく、実行構造を説明するための言葉として使います。
Anthropic の区分では、あらかじめ決めた経路で LLM とツールを動かすものを workflow、LLM が途中ルートを動的に決めるものを agent と呼びます。この回の Graph は、workflow(事前に描いた経路)に近く、各ノードの内側に小さな agent/loop が残る、という読み方が正確です。Loop を消すのではなく、複数のループを配線する上位レイヤです。
| 部品 | 意味 |
|---|---|
| ノード | 専門作業、またはコード/人間/別グラフ |
| エッジ | 次へ進む条件(成功・失敗・差し戻し・承認) |
| 状態(state) | ノード間で渡す共有メモ(会話履歴の外) |
経路の決定権(Anthropic の workflow / agent 区分に寄せた言い方):
- Loop(agent 寄り): 人が Goal/Verify、モデルが途中ルートを探索
- Graph(workflow 寄り): 人が通ってよい道を先に描き、モデルの自由はノード内に閉じる
似た言葉を分ける
| 用語 | 何か | この回 |
|---|---|---|
| Graph(実行) | 誰が次に動くかの配線 | 本丸 |
| GraphRAG/知識グラフ | データの関係を辿る検索 | 別問題 |
| 役割やスキルを並べる | 作業の候補一覧 | ノード候補にすぎない(配線が本体) |
紙に書く最小セット(実装フレームワークより先):
- 目的(終了状態)
- ノード
- エッジ
- 状態
- 評価と終了
- Human Gate
- 記録と復旧
具体例:観光FAQを公開承認まで通す
概念を、次の仕事に落とします。
雨の日・小学生連れ向けの屋内スポットを、根拠つきで3つ答える
AIを動かす前に決めるカード
| 項目 | 設定 |
|---|---|
| 完了条件 | 人間承認済みの回答文 + 根拠リスト |
| 失敗時 | 根拠不足 → Research へ。表現だけ → Draft へ |
| 禁止 | 根拠なき断定、営業時間の憶測 |
| アンカー | 公式URL原文、人の approve、当日日付(rewrite 不能) |
1体の長い会話に全部をまとめると、根拠の不足が調査・統合・執筆のどこで入ったのかを追いにくくなります。そこで、この例では経路を先に分けます。
工程を実行経路にする
| ノード | 役割 | ノード内 Loop の Verify |
|---|---|---|
| Intake | 質問正規化 | 必須スロット |
| Research A/B/C | 公式/営業時間/家族制約(並列) | 根拠カード |
| Merge | 矛盾の明示 | conflicts または要確認 |
| Draft | 回答文 | 3件構成 |
| FactCheck | 主張↔根拠 | evidence_id |
| Human Gate | 公開前承認 | 人の approve / revise |
ノードは LLM だけではありません。スロット検査や evidence チェックはコード、決裁は人間、が経路設計です。
設計7項目をこの FAQ に埋める
| # | 項目 | この FAQ |
|---|---|---|
| 1 | 目的 | 承認済み回答+根拠リスト |
| 2 | ノード | 上表 |
| 3 | エッジ | 調査は並列。FactCheck NG は Draft か Research へ |
| 4 | 状態 | slots / notes / claims / path(会話の外) |
| 5 | 終了 | 全主張に evidence_id。自己申告の完成は不可 |
| 6 | Human Gate | 公開相当の直前 |
| 7 | 記録と復旧 | path とノード別 NG。失敗ノードから再開 |
1本の実行を追ってみる
| 順 | ノード | 結果 | 次 |
|---|---|---|---|
| 1 | Intake | 制約スロット埋まる | fan-out |
| 2 | Research×3 | 根拠取得 | Merge |
| 3 | Merge | 休館と曜日が衝突 | Draft(要確認) |
| 4–5 | Draft→FactCheck | evidence 欠落 | 差し戻し Draft |
| 4’–6 | 再Draft→FactCheck→Gate | approve | Done |
失敗が どのノードの責任か が path で分かるのが、1体ループに対する実務価値です。
なぜ1体のLoopだけでは足りないのか
| 合図 | この FAQ |
|---|---|
| 専門が分かれる | 調査/執筆/突合/承認 |
| 並列が要る | 公式・時間・家族制約を同時に |
| 検証者が別 | FactCheck/Human |
| 差し戻し先が分かれる | Draft だけ戻す vs Research まで戻す |
前回のテスト修正はループ向きでした。同じ「エージェント」でも、仕事の形でレイヤが変わります。
独立して進められる調査まで一直線(A→B→C→…)に並べると、待ち時間が積み上がりやすくなります。また、途中状態と再開点を保存しない設計では、失敗時に前工程までやり直しやすくなります。真の依存だけ直列にし、独立した調査だけを並列候補にします。
役割一覧だけではGraphにならない
役割ごとに手順を分ける発想は、ノード分割の入口になります。ただし、役割名を並べただけでは実行できません。次へ進む条件、共有state、人間承認がなければ、作業一覧で止まります。
| 役割一覧にあるもの | 実行経路で追加するもの |
|---|---|
| 部門 | ノード名 + Verify |
| 増員 | エッジ(並列/差し戻し) |
| 引き継ぎ | 会話外の state |
| 決裁 | Human Gate |
| 監査 | path と再開点 |
実行経路を記録し、改善につなげる
- 作業グラフ: いまの Research→Gate(この回の本丸)
- 改善: 差し戻し率や根拠なし件数を見て手順を見直す
アンカー(公式原文・人の判断・日付)が無いと、内部整合だけのきれいなエコーになります。
設計レビューで確認すること
レビューや導入判断の場で、口頭で答えられるかを見るリストです。
- [ ] 実行グラフと GraphRAG を混ぜていないか
- [ ] 7項目が埋まっているか
- [ ] ループに畳んでも失うものがあるか
- [ ] 真の依存だけ直列か
- [ ] 差し戻し先を紙で描けるか
- [ ] state が会話履歴だけに閉じていないか
- [ ] コード検査・人間ノードを混ぜているか
- [ ] アンカーが rewrite 不能か
- [ ] 失敗ノードから再開できるか
つまずいたこと
ノードを増やしすぎて Merge が渋滞したことがあります。また「グラフにしたから検索は不要」と誤解し、根拠URLを消したこともあります。Verify のない分割と、アンカーなしの自己整合が本質でした。
この回の要点
- Graph = 実行経路の地図。各ノード内は Loop
- 概念は図1・図2、具体例は観光FAQ(図3)
- 役割一覧はノード候補。配線・state・Gateが本体
- 真の依存だけ直列、他は並列
全体像、Loop、Graphの3回で、構造を複雑にする境界を見てきました。次に自分の業務を描くときは、まず一問一答か固定Workflowで足りないかを確認し、必要な理由があるときだけLoop、Graphへ進めます。
よくある質問
Graphにすると必ずMulti-Agentになりますか?
いいえ。ノードはAIだけでなく、通常のコード、Tool、人間の承認にもできます。1体のAgentを複数工程で使うGraphもあります。
Graph Engineering とは何ですか?
専門工程と、分岐・並列・差し戻し・人間承認などの経路を先に描くことです。各ノード内には小さなLoopが残ります。
GraphRAG と同じですか?
いいえ。GraphRAG は知識をグラフとして検索する話。Graph Engineering はエージェントの実行経路の話です。
役割を並べればGraphですか?
いいえ。次へ進む条件、共有する状態、各工程の合格条件、差し戻し先が必要です。