エアークローゼット — Agentic Graph RAG と社内MCP基盤（17サーバー・5層セキュリティ）¶
作成日: 2026-07-07 出典 / きっかけ: 辻亮佑（エアークローゼットCTO）Zenn より2本 - 「Agentic Graph RAG MCPのススメ ── Graph RAGは『単発』ではなく『対話』になった」（2026-05-07 / 更新 2026-06-01） - 「社内業務をAIに開放 ── 自社MCPサーバー群一挙公開！」（2026-04-08 / 更新 2026-05-18） 関連: エアークローゼット_cortex_aiハーネス6部作_整理 / エアークローゼット_46リポジトリ知識グラフとllm_observability_整理 / エアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理 / 社内mcp共通基盤_認証認可ログ_整理 / オントロジーと知識グラフ_金融業界の実践例_整理
0. 要点（3行）¶
- Agentic Graph RAG ＝「検索の各ステップは決定的、オーケストレーションだけがAI」。入口だけベクトル類似度（揺らぎ許容）で当たりを付け、以降は ID 指定と graph traversal で確定値を辿る。ハルシネーションは消えず「入口選択」と「ストップ判定」に局所化される。
- 鍵は Runbook パターン＝ツールの返却値に「次に呼ぶべきツール引数・関連ID・enum定義」を埋め込み、AIが多段のツール呼び出しを自力で組み立てられるようにする設計。ツールの description は機能説明でなく AI向けの実行手順書。
- 土台は 3ヶ月で作った17個のMCPサーバー群。全サーバーが TypeScript + Pulumi + Google OAuth の統一構成で、5層セキュリティと「退職＝Workspace無効化で全MCP自動失効」を実現。知識をAIがアクセスできる形で外部化するのが本質的役割。
1. Agentic Graph RAG — RAGは時代ごとに最適解が変わる¶
筆者の主張は「RAG は時代ごとに最適解が異なる」。3世代の進化として描かれる。
1-1. 第1世代：ベクトルRAG（草創期／単発検索の最適解）¶
- 背景：コンテキスト窓が狭い（GPT-3.5 は 4K トークン）、モデル知識が古い、ハルシネーションが課題。
- 手法：ドキュメントを チャンク分割 → Embedding → ベクトルDB格納 → cosine類似度で検索。「1回の retrieval で答えに必要な情報を全部取ってくる」前提。
- 限界：関係性を辿れない。テキスト類似度では複数ホップの質問（「SNS広告キャンペーンが新規会員数にどう影響したか」）に答えられない。
1-2. 第2世代：古典的 Graph RAG（Function Calling期）¶
- Microsoft GraphRAG（2024年登場）。エンティティ抽出 → コミュニティ検出（Leiden法） → 階層的要約という重い前処理。クエリ時は1〜2回の検索で完結させる設計。
- 限界：構築コストが高い、スキーマが LLM 任せ、更新が重い、要約で具体情報が落ちる。
1-3. 第3世代：Agentic Graph RAG（エージェント期）¶
- 前提が変わった：Claude Code / OpenAI Codex など実用エージェントの登場、MCP によるツール記述の標準化、長コンテキスト＋プロンプトキャッシュで multi-hop tool use が現実的に。「1セッションで5〜10回のツール呼び出し」が当たり前になった。
- 核心：「検索の各ステップは決定的、オーケストレーションだけがAI」。
1-4. 実装パターン（4段）¶
- 入口検索：ベクトル類似度（揺らぎ許容）で「だいたいこの辺」を見つける
- 詳細取得：ID を指定すれば確定値を返す（決定的）
- 関係走査：エッジを辿る（決定的）
- 返却値に runbook を埋め込む：関連ID・enum定義・注釈で「次の手」を示唆
1-5. 時代別RAG比較表¶
| 時代 | 代表 | 検索 | オーケストレーション |
|---|---|---|---|
| 草創期 | ベクトルRAG | 確率的（cosine類似度） | なし（単発） |
| Function Calling期 | 古典的 Graph RAG | 事前要約済み | 軽量・ほぼ単発 |
| エージェント期 | Agentic Graph RAG | 決定的（graph traversal） | AIが多段組立 |
2. Runbook パターン — ツール返却値が次の手を教える¶
Agentic Graph RAG の実装上の肝。ツールの返却値に「次に何をすべきか」を同梱する。
DB Graph での返却値の例：
warehouse.荷受記録テーブル (postgresql)
→ status カラムの enum 定義（COMPLETE = 荷受済み）
→ 参照先: warehouse.出荷オーダーテーブル.id
→ 次に呼ぶべきツール引数が既に含まれている
AI は「関連ID・enum・注釈」というコピペ可能な候補を次々に得て、迷わず多段で辿れる。ツールの description も単なる機能説明でなく「次の手が書き込まれた実行手順書（runbook）」として書く。この思想は cortex の cpg（エアークローゼット_cortex_aiハーネス6部作_整理 Part 2）でも usecase パラメータとして実装されている。
2-1. DB Graph MCP の実演（本番調査が4ステップで完結）¶
対象：991テーブル × 15スキーマ（ORM 解析からスキーマグラフ生成）。CSの問い合わせ「この会員さん、アプリでは返却済みだが倉庫側で確認できてるか？」を例に：
- テーブル探索（入口・ベクトル検索）
- 詳細確認（ID指定・決定的）
- スキーマ間の結合経路探索（graph traversal）
- 実データ確認
以前は CTO にしか辿れなかった横断調査を、非エンジニア（PMO・CS）が自然言語で実行できるようになった。
2-2. 同じパターンを社内のあちこちに¶
- DB Graph（991テーブル × 15スキーマ）
- Biz Graph（5,000+施策 × 4,000+KPI。会議スライドから抽出、Week ノード設計）
- Code Graph（静的解析ベース。→ エアークローゼット_46リポジトリ知識グラフとllm_observability_整理）
- Service / Cortex Product Graph（API → DB 依存関係。→ エアークローゼット_cortex_aiハーネス6部作_整理）
3. 設計チェックリスト（6項目）¶
Agentic Graph RAG を組むときの指針として筆者が挙げる6点。
- ドメイン性質でグラフ構築方法を選ぶ：社内暗黙知が強いなら「人間が設計」。LLM 抽出に任せない。
- retrieval を決定的化する：入口のみベクトル、以降は graph traversal で確定値。
- ツール粒度を分解する：
search_*（入口）→get_*_detail（深掘り）→trace_*/query_*（走査）。 - ツール description ＝ AI向け runbook：次の手が書き込まれた手順書にする。
- 返却値に「次の手の候補」を埋め込む：関連ID・enum・注釈・PII対応。
- 集計・要約は AI に委ねる：サーバ側で前処理しすぎない。
3-1. 限界と注意点¶
- グラフ設計の品質がすべてを決める。暗黙知ドメインでは人間による設計が必須。
- エージェントが入口で迷うと深い穴に落ちる。
- コストは「ツール呼び出し回数 × コンテキスト長」に依存。
- ハルシネーションは消えるのではなく「入口選択」「ストップ判定」に局所化される。
- 筆者の結論：「優れたAIシステムは、ドメインを最も深く理解している人間が作る」。AI時代だからこそドメイン知識の価値が上がる。
4. 社内MCP基盤 — 3ヶ月で17サーバー、全部同じ構成¶
Agentic Graph RAG を支える土台。2026年1月から約3ヶ月で17個のMCPサーバーを構築・運用（DB・インフラ・ドキュメント・プロジェクト管理・オブザーバビリティ・CI/CD・コード編集・デプロイまで）。
4-1. 統一構成と認証基盤¶
- 全サーバーが「TypeScript 実装 + Pulumi で GCP デプロイ + Google OAuth 認証」の統一構成。
- 認証：RFC 8414 の自動検出に対応した Google OAuth 2.0 + PKCE。Upstash Redis を全サーバー共通のセッションストア（7日TTL）に。
.mcp.jsonに URL を書くだけで Claude Code が認証フローを自動開始。
4-2. 主要サーバー群¶
| サーバー | 役割・特徴 |
|---|---|
| DB Graph | 全社 17DB・994テーブルの横断検索・クエリ実行 |
| GCloud / AWS | リードオンリー参照のみ。OAuth スコープで書き込みを原理的に不可能に。GCP Audit Log / CloudTrail に個人メール記録 |
| GWS | Google Workspace 全サービス操作 |
| Git Server | ローカル git コマンド実行でレートリミット回避 |
| Grafana MCP | オブザーバビリティ参照 |
| CircleCI MCP | CI/CD |
| Workspace MCP | GitHubアカウント不要のコード編集・デプロイ。Firestore でファイルごとの ACL 管理 |
| Sandbox MCP | 非エンジニアが自分のアプリを社内公開（→ エアークローゼット_非エンジニア内製化_sandbox_mcpと議事録rag_整理）。Cloud Run へ自動デプロイ |
4-3. 5層セキュリティモデル¶
| 層 | 内容 |
|---|---|
| Layer 1 | Google Workspace OAuth + ドメイン制限 |
| Layer 2 | SSO + セッション管理 |
| Layer 3 | サーバーごとのスコープ制限 |
| Layer 4 | PII 自動匿名化（40+ カラムパターン） |
| Layer 5 | BigQuery への全ツール呼び出しログ記録 |
- 退職時は Google Workspace アカウントを無効化するだけで全MCPへのアクセスが自動失効。個別トークン管理が不要。
- 認証・認可・ログの共通基盤という発想は 社内mcp共通基盤_認証認可ログ_整理 と同型。
4-4. 設計哲学¶
- 「知識をAIがアクセスできる形で外部化する」ことが MCP の本質的役割。
- 実装は「既存 CLI / MCP を OAuth プロキシでラップする」アプローチ。
- Workspace / Sandbox MCP により非エンジニアが GitHub アカウント不要でコード修正・デプロイでき、実際に非エンジニアが KPI ダッシュボード改善を実施した。
5. まとめ — いつ効くか（早見表）¶
| 状況 | 打ち手 |
|---|---|
| ベクトルRAGが「関係を辿る質問」に弱い | Agentic Graph RAG：入口だけベクトル、以降は graph traversal で決定的に |
| 古典 Graph RAG の要約で具体情報が落ちる | 事前要約に頼らず、エージェントが多段で生データを辿る |
| AIが多段ツール呼び出しで迷う | Runbook パターン：返却値に次のツール引数・enum・関連IDを同梱 |
| ツールの使われ方が安定しない | description を機能説明でなく AI向け手順書として書く |
| 暗黙知の強いドメインをグラフ化したい | 人間が設計する（LLM 抽出に任せない） |
| 社内システムをAIに安全に開きたい | 統一構成のMCP群 + 5層セキュリティ、read-only は OAuth スコープで物理担保 |
| 退職者のアクセス失効を確実にしたい | Workspace OAuth 一本化（無効化で全MCP自動失効・個別トークン不要） |
一言でいえば 「AIに賢く推論させる」のではなく「決定的な検索部品を並べ、その並べ方（オーケストレーション）だけAIに任せる」。そのための部品置き場が統一構成のMCP群で、部品同士を繋ぐ地図がグラフ、という構造。
参考リンク¶
- Agentic Graph RAG MCPのススメ: https://zenn.dev/aircloset/articles/341dffee42f454
- 社内MCPサーバー群一挙公開: https://zenn.dev/aircloset/articles/d9fc317c1336c2
- Microsoft GraphRAG（公式）
- Model Context Protocol（Anthropic 公式）
- RFC 8414 — OAuth 2.0 Authorization Server Metadata
作成: 2026-07-07 ／ 最終更新: 2026-07-07