Gemini CLI と Neo4j で作る知識グラフ RAG 型 AI エージェント開発入門 - なぜ今、グラフなのか？
今回から数ヶ月にわたり、以下の技術を活用した「知識グラフ RAG (Graph RAG) 型の AI エージェント」の構築について解説する連載を始めます。
- Google が提供する LLM である Gemini 3 https://blog.google/products/gemini/gemini-3/
- 同じく Google が提供する CLI 型のAIエージェントである Gemini CLI https://geminicli.com
- そしてグラフデータベースシェア No.1 であるNeo4j https://neo4j.com
記念すべき第 1 回となる今回は、これらの技術の基本概念を整理した後、「なぜ今、グラフ RAG なのか？」「なぜ Gemini CLI を使うのか？」 という背景と動機についてお話しします。
本連載は、グラフデータベースや AI エージェントの開発経験がない方でも、手を動かしながら少しずつ理解を深められる構成にしていますので、ご安心ください。
1. 基本概念の整理
まず、本連載で目指すゴールと、それを実現するための主要な用語について整理します。
知識グラフ RAG 型 AI エージェントの目的
本連載で目指すのは、「 特定分野の知識をグラフ構造で表現し、AI エージェントがユーザーの質問に応じてそのグラフを探索する 」システムの構築です。
エージェントは、ユーザーの曖昧な指示から意図を汲み取り、知識グラフという「地図」を頼りに関連情報を自律的に収集します。そして、集めたリッチなコンテキストを LLM に渡すことで、文脈に応じた、かつ事実に基づいた正確な応答や、複雑な推論を要するタスクの実行が可能になります。
例えば、「部品 A の納入遅延が、どの製品の生産計画に影響するか？」といった質問に対し、エージェントが部品→製品→顧客というつながりを辿って影響範囲を特定し、回答するようなイメージです。
用語の定義
このシステムを実現するために、以下の技術・概念を使用します。
知識グラフ (Knowledge Graph)
現実世界の事象（エンティティ）と、それらの関係性（リレーションシップ）をグラフ構造（ノードとエッジ）で表現したデータベースです。「A 社は B 製品を開発した」「B 製品は C 部品を使っている」といった事実を、つながりとして蓄積します。
事例 1：セマンティック Web (The Semantic Web)
近年の知識グラフの概念の源流は、Web の発明者であるティム・バーナーズ＝リーが提唱した「セマンティック Web」にあります。これは、Web ページ上の情報に「意味（メタデータ）」を付与し、コンピュータが自律的に処理できるようにしようという壮大な構想でした。
RDF (Resource Description Framework) や オントロジー (Ontology) といった技術標準が策定され、これらは現在でも Palantir などのデータ分析基盤で活用されています。
しかし、セマンティック Web は肝心な「厳密にオントロジーを定義し、タグ付けする」ことを人間が行うことの膨大な労力を解決する手段を提示しないことから、タグ付けをどうやるのか答えが見えないまま、Web 全体への普及には至りませんでした。
個人的な話になりますが、筆者が大学生の頃にちょうど流行しており、技術調査やプロトタイプ作成でお小遣い稼ぎをした懐かしい思い出があります。シニアエンジニアになった今、再び同じ用語や概念をベースにした技術に取り組むことに、深い感慨を覚えます。
事例 2：Google ナレッジグラフ
その壁を打ち破ったのが、2012 年に Google が導入した「ナレッジグラフ」です。
Google は、人間による手動定義（セマンティック Web 的なアプローチ）を諦め、Web 上の膨大なテキストから機械的に知識を抽出してグラフを構築する方法を考案しました。
それ以前の検索は単なるキーワードマッチングでしたが、導入後は例えば「Gemini」と検索すると、単なる星座のページだけでなく、「Google が開発した AI モデル」であること、その強みや競合といった文脈を理解した情報が構造化されて表示されるようになりました。これが「知識グラフ」の力です。
RAG (Retrieval-Augmented Generation)
（筆者の理解が正しければ）Meta AI が 2020 年に発表した、LLM の「内部知識（学習したこと）」と「外部知識（検索で見つけたこと）」を組み合わせる仕組みです。LLM は「学習データに含まれない最新情報」や「社内の非公開情報」を知りません。また、知らないことをもっともらしく嘘をつく（ハルシネーション）癖があります。そのため、知識を更新するたびに巨大な AI を再学習させるのは、コストも時間もかかりすぎます。「それなら、必要な情報だけその都度検索して、AI に読ませればいいじゃないか」という発想から生まれました。
**「LLM にカンニングペーパーを渡して、正確に答えさせる技術」**とイメージしてください。
グラフ RAG (Graph RAG)
（筆者の理解が正しければ）Microsoft Research が最初に提唱した、LLM による検索拡張の高度な手法です。
従来の RAG (Baseline RAG) が苦手とする 「点と点をつなぐ (Connecting the dots)」 推論や、データセット全体の 「全体像を把握する (Holistic understanding)」 要約タスクにおいて、劇的な性能向上を実現します。
具体的には、LLM 自身を用いてデータから知識グラフを構築し、それを辿ることで、断片的な情報の背後にある複雑な関係性や文脈を理解可能にします。
AI エージェント
LLM の強力な推論能力を活かし、「入力 → 推論 → タスク実行」というループを自律的に回すシステムです。単にテキストを生成するだけでなく、必要に応じて外部ツール（検索、計算、API 実行など）を呼び出し、その結果を元にさらに推論を進めることができます。
また、開発者の皆さんにとって最も身近な AI エージェントといえば、IDE に統合されたコーディング支援ツールかもしれません。しかし現在、エージェントの提供形態は多様化しており、中でもベンダー各社が提供する CLI (Command Line Interface) 型のエージェントが注目を集めています。既存の開発ワークフローとの親和性が高く、連携が容易だからです。本連載で活用する Gemini CLI も、まさにこのトレンドに位置するツールの一つです。
MCP (Model Context Protocol)
Anthropic 社が提案した、AI モデルと外部システム（データベースやツール）を接続するためのオープンな標準プロトコルです。
これを利用すると、システム連携のための複雑なコードを個別に書くことなく、統一された手順で Neo4j などの外部データベースを LLM に接続し、検索や更新を行わせることが可能になります。Gemini CLI もこのプロトコルを採用しています。
2. 本連載の題材とデモシステムの構成
本連載では、以下の技術スタックと題材を用いて「知識グラフ RAG 型 AI エージェント」を構築・解説していきます。
扱う題材：製造業のグラフ活用
技術的な検証を行うための題材として、筆者が所属する製造業のドメインを扱います。
具体的には、グラフデータベースの活用事例として頻出する以下のようなテーマを想定しています。
- サプライチェーン最適化
- BOM (部品表) 分析
- 品質・コストの原因分析
なぜこれらの題材が知識グラフやエージェントと相性が良いのか、その詳細な理由は後述します。
具体的にどれにするかはサンプルデータがあって、参考になるオントロジやスキーマがあるものにします。
技術スタック
- 知識グラフ RAG の格納先としてグラフデータベース市場でのシェア No.1 である Neo4j を使用します。
- AI エージェント のランタイムとして、Google が提供する Gemini CLI を使用します。
- エージェントの頭脳となる LLM には、最新の Gemini 3 を採用します。
- LLM (Gemini 3) と知識グラフ (Neo4j) を接続するためのプロトコルとして、MCP (Model Context Protocol) を使用します。MCP サーバとして Neo4j が OSS として提供されている
mcp-neo4j-cypherを使用します。
アーキテクチャの全体像を示す構成図は、次回以降の記事で詳細に解説します。現時点では「こういう道具を使うんだな」程度の理解で構いません。
3. 背景：なぜ今、知識グラフ × AI エージェントなのか？
では、なぜ今このアプローチが必要とされているのでしょうか。
リレーショナル DB / ベクター DB の限界
現在、RAG といえばリレーショナルデータベース (RDB) やベクターデータベースを用いた手法が一般的です。しかし、これらには「データのつながり」を扱う上で、「表現」 と 「検索」 の 2 つの側面で限界があります。
1. 「つながり」を表現する難しさ
RDB はデータを「表」に正規化して管理するため、データ同士の関係性は「外部キー」という形で間接的にしか表現できません。
一方、グラフデータベースは 「関係性（リレーションシップ）」をデータそのものとして保存 します。「A は B に依存する」という事実をそのままの形で直感的にモデル化できるため、サプライチェーンや組織図のような複雑なネットワーク構造を扱うのに適しています。
2. 「つながり」を検索する難しさ
つながりを表現できたとしても、それを辿って検索するのはさらに困難です。
- ベクター検索の弱点: 「意味が似ている」ドキュメントを探すのは得意ですが、「A 社の元社員が設立した B 社の競合製品」のような、複雑な関係性を辿る推論は苦手です。
- RDB の弱点: 決まったテーブル同士の単純な結合 (JOIN) は得意ですが、A→B→C...と連鎖していくネットワーク構造において、何段階ものつながりを辿る「マルチホップ」な探索は、計算量が指数関数的に増えるため、極めて不得意です。
対して、グラフデータベース (Graph DB) は、この「つながりを辿る (Traverse)」処理に特化して設計されており、どれだけ階層が深くても高速に探索できます。
Vector RAG エージェント vs Graph RAG エージェント
AI エージェントの「脳」として比較すると、その差は歴然です。
- Vector RAG エージェント: ドキュメントの断片（チャンク）を検索して渡すため、文脈が分断されがちです。LLM は断片をつなぎ合わせて無理やり推論する必要があり、「隠れた関係性」を読み解くのは困難です。
- Graph RAG エージェント: 知識グラフ上のつながりを辿って関連情報を収集します。「A は B に影響を与え、B は C の構成要素である」といった 構造化された文脈（サブグラフ） をそのまま LLM に渡せるため、LLM は持ち前の推論能力をフルに発揮できます。
製造業におけるユースケースと自動化のインパクト
この特性は、筆者が在籍する製造業において特に強力な武器になります。
- サプライチェーン最適化: 部品供給の遅れがどの製品・顧客に波及するかを瞬時に特定する。
- BOM (部品表) 分析: 数万点の部品からなる複雑なツリー構造を探索し、設計変更の影響を分析する。
- 品質・コストの原因分析: 不具合発生時に、共通する設備・材料・作業者を横断的に探索して根本原因を突き止める。
これらのデータを知識グラフ化し、AI エージェントと組み合わせれば、 「この部品の不具合による影響範囲をリストアップして」 と指示するだけで、エージェントがグラフネットワークを自律的に探索し、回答してくれます。人間が時間をかけて行っていた分析作業を自動化することで、生産性の向上は計り知れません。
4. 先行事例：フィンテックスタートアップ Klarna における AI アシスタントの構築
このアプローチの有効性を示す、近年のエポックメイキングな事例として、（製造業ではなく金融業界ではありますが）フィンテック企業の Klarna を紹介します。
Klarna の事業と課題
Klarna はスウェーデン発の「Buy Now, Pay Later（後払い決済）」サービスを提供するフィンテック企業です。オンラインショッピングにおいて、消費者が商品を即座に受け取り、後日分割払いできる仕組みを提供しています。
急成長を遂げた Klarna は、Jira、Salesforce、Workday をはじめとする 1,200 以上の SaaS アプリケーションを社内で利用していました。しかし、これらのシステムが分散・断片化していたため、「チーム構成を理解する」「プロセスドキュメントを探す」といった横断的な質問に答えるには、複数のシステムにアクセスする必要がありました。
CEO の Sebastian Siemiatkowski 氏は、「断片化され、分散した企業データを LLM に与えると、非常に混乱した LLM になる」と指摘しています。
知識グラフによる解決
Klarna は、社内のあらゆる SaaS データを Neo4j の知識グラフに統合し、それを RAG の基盤として AI エージェント「Kiki」を構築しました。知識グラフを構築することで、データの統合・標準化を実現し、サイロを解消しました。
その上で、OpenAI の LLM と統合することで、従業員が Slack や社内ナレッジプラットフォームから自然言語で知識グラフにクエリできるチャットボットインターフェースを提供しました。
業務効果
Kiki は 2023 年 6 月のローンチ以降、1 日あたり 2,000 件、累計 25 万件以上の質問に回答しています。具体的な業務効果は以下の通りです：
- 高い採用率: 全従業員の 85% が Kiki を積極的に利用。非技術部門でも、コミュニケーション部門 93%、マーケティング 88%、法務 86% という高い採用率を記録。
- 即座の回答: 従業員の質問に 1〜5 秒で回答し、コラボレーションを劇的に改善。
- SaaS の大幅削減: Salesforce や Workday を含む SaaS システムを廃止。ライセンス費用の削減だけでなく、知識の統一と標準化を実現。
- 生産性向上: セルフサービス文化を醸成し、従業員が独立して答えを見つけられるようになり、管理業務に費やす時間を削減。戦略的・創造的なタスクに集中できるようになった。
5. 開発ツール：なぜ Gemini CLI なのか？
知識グラフRAG型のAIエージェントシステムを構築・検証するために、本連載では Gemini CLI を使用します。
AI エージェント開発というと、複雑な Python コードを書くイメージがあるかもしれません。しかし、Gemini CLI は MCP (Model Context Protocol) を介して外部システム（今回は Neo4j）と接続することで、驚くほどシンプルにエージェントを構築できます。
- 試行錯誤の高速化: 開発者が新しいアイデアを試す際、コードを書き換えてビルドして...という手順は手間です。CLI ベースなら、プロンプトを変えてすぐに実行、結果を見て修正、というサイクルを高速に回せます。
- 推論に集中: 複雑なグルーコードを書かずとも、ツール定義さえすれば、あとは LLM の推論能力に任せてタスクを自動化できます。
まずは CLI でエージェントの挙動や推論ロジックを素早く検証し、実用性が確認できてから Web アプリケーション等に組み込む、というフローが効率的です。
6. 今後の連載予定
この連載では、座学よりも「まず動かす」ことを重視し、以下のステップで進めていきます。
-
ハンズオン編：デモシステムの構築と体験
具体的な製造業の題材とグラフスキーマを紹介し、コンテナでデモ環境を立ち上げます。データは自動ロードされる仕組みにするため、面倒な準備は不要です。まずは実際にエージェントを動かし、知識グラフ RAG の挙動を体感していただきます。 -
解説編：サブシステムの動作原理と技術要素
デモシステムが裏側でどう動いているのか、各サブシステム（Neo4j, Gemini CLI, MCP）の技術的な仕組みや連携フローを詳細に解説します。 -
設計編：本番運用に向けたアーキテクチャと最適化
実運用に耐えうるシステムを構築するための設計案や、コスト・パフォーマンスを最適化するための基礎概念について議論します。
次回は、さっそくデモ環境を構築し、AI エージェントとの対話を実践してみましょう。お楽しみに！
Discussion