業務でAIエージェントのアーキテクチャ設計に携わる中で、GraphRAGエージェントを実際に構築してみました。本記事ではその実装と、背景にある概念を整理して紹介します。
対象読者
- AIエージェントの業務設計・アーキテクチャ設計・構築に取り組んでいる方
- エージェント設計においてPalantirモデルやオントロジー的な概念の必要性を感じているが、まだ十分に理解できていない方
- 実際に手を動かして理解を深めたい方
従来のRAGとGraphRAGの違い
従来のRAG（ベクトル検索）
テキストを細かく分割し、意味の近さをベクトル化して検索します。
「単一文書の要約」や「キーワード検索」には強い一方で、「親会社と子会社の関係」や「人脈の繋がり」といった構造的な推論は苦手です。
GraphRAG（グラフ検索）
データ同士の関係性をノードとエッジによるグラフ構造でモデル化します。
文脈や関係性を深く辿れるため、「Aさんと関連が深いプロジェクトは？」「関連部署のルールは？」といった複雑なクエリに対応できます。
前提知識：用語の整理
GraphRAGを理解する上で必要な概念を整理します。
グラフ
ノード（点）とエッジ（線・繋がり）で構成されるデータ構造です。
- 「顧客」と「商品」
- 「社員」と「パソコン」
オントロジー
ノード間の繋がりに意味とルールを付与する概念です。
- 「顧客」は「商品」を 「契約している」
- 「社員」は「パソコン」を 「利用している」
ナレッジグラフ
グラフ構造にオントロジーで意味づけしたものです。
LLMを用いたナレッジグラフでは、自然言語情報から関係性を自動抽出し、ノードやエッジを動的に追加・更新できます。
個人的には「動的に更新されるクラス図」に近いイメージを持ちました。
（以下参考）
必須ではありませんが、データ基盤との接続を考える際に役立ちます。
セマンティックレイヤー
物理データ名とビジネス用語を紐づけるレイヤーです。
-
T_CUSTOMER→ 「顧客」 -
STS = ACTIVE→ 「有効顧客」
データカタログ
データの所在・意味・属性を一元管理し、検索・活用できるようにした仕組みです。
超ざっくりとした説明になりましたが、もう少し深めに理解したい場合は
こちらの記事をおすすめします。
ナレッジグラフ設計
次に実際にナレッジグラフを設計してみました。今回はOAヘルプ業務を想定し
ユーザーの発話テキストを解釈し、適切なオペレーションにルーティングするための
グラフ構造を定義しています。
想定オペレーション
| オペレーション | 概要 |
|---|---|
| パスワードリセット | 本人確認後にPWをリセットする |
| 問い合わせ回答 | ナレッジに基づいてFAQ・手順を回答する |
| 人間引継 | いずれにも該当しない場合に人間オペレーターに引き継ぐ |
オペレーションは拡張可能であることを想定しています。
処理フロー概要
発話テキスト
→ Entity照合（グラフ・ルールベース）
→ 意図解釈LLM（Intent確定）
→ Operation起動
→ Condition評価（ルールベース）
→ Procedure実行 or EscalationReason記録
ノード種別
| ノード | 役割 |
|---|---|
| Entity | 発話概念の正規化レイヤー |
| Intent | ユーザーの意図カテゴリ |
| Operation | 実行単位（拡張ポイント） |
| Condition | 分岐条件の評価器 |
| Procedure | 実際の処理ステップ |
| EscalationReason | 人間引継理由の記録 |
6種のノードは「発話の受け取り → 意図の確定 → 処理の実行 → 結果の記録」という一本の変換パイプラインになっています。
生の発話に含まれる概念をEntityで正規化し、IntentでAIが「何をしたいのか」を抽象化、Operationで「何をするか」を決定、Conditionで「実行できるか」を判定、できればProcedureで処理、できなければEscalationReasonに理由を記録して人間に引き継ぐ。
各ノードが「変換の責務」を一つだけ持つ設計です。
エッジ種別
今回作成したエッジはノードパイプラインの「継ぎ目」を述語で定義し、ほぼ1対1で対応させた単純なものになっています。
| エッジ | 主語 → 目的語 | 意味 |
|---|---|---|
| triggers | Entity → Intent | 発話概念がIntentを候補として活性化する |
| routes_to | Intent → Operation | 確定したIntentがOperationを起動する |
| requires | Operation → Condition | OperationがConditionの評価を要求する |
| proceeds_when | Condition → Procedure | Condition成立時にProcedureに進む |
| escalates_when | Condition → EscalationReason | Condition不成立時に引継理由を記録する |
| follows | Procedure → Procedure | 手順の実行順序を示す |
| answered_by | Intent → Procedure | 問い合わせIntentの回答入口を示す |
ノード・エッジの定義やプロパティの詳細、オントロジー制約については別途GitHubリポジトリにまとめています。実際に構築してみたい方はあわせて参照してください。
構成したナレッジグラフ
実際に構築したナレッジグラフを可視化したものです。HTMLファイルとして公開しているので、詳しく確認したい方はこちらからローカルでダウンロードしてみてください。
アーキテクチャ図
本構成はモック用途を想定し、AWSの標準サービスで完結するようシンプルにまとめています。Claudeに指示して作成していますが、AWSアカウントとFAQデータさえあれば、再現できるはずです。
（構成図を貼り付けてこのとおりに実装して、でもよいかもですｗ）
結果
チャットの簡易インターフェースを用意して実際に動かしてみました。グラフ構造で関係性を持たせた効果が出ているのか、単純なQ&Aにとどまらない、わりと人間らしいやりとりができています。
まとめ
今回のグラフ構成はシンプルなものにとどめています。従来のRAGでもそれなりの精度が出るようになった今、GraphRAGの真価はグラフ設計の深さと評価の体系化にあると感じています。ノードとエッジの設計を磨き、回答品質を測る仕組みを整えることで、はじめて他のエージェントとの差が出てきます。
この記事をきっかけに、グラフエージェントの構築に興味を持つ人が増えたらうれしいです。業務課題でも社会課題でも、問題の構造をグラフで捉えて解くエージェントを一緒に作っていく、そんな輪が広がることを期待しています。