RAGはコーディングエージェントの敵だった？DAGで「決定的なコンテキスト解決」を実現するMCPツール「Aegis」の仕組み

Claude Code や Cursor を使っているエンジニアなら一度は経験する「ドキュメント地獄」。最初は AGENTS.md に数行書くだけで済んでいたのが、気づけば docs/architecture.md、docs/specifications/*.md、docs/adr/*.md と増殖し、AIが正しいドキュメントを探すためだけに大量のトークンを消費するようになる。「じゃあRAGで意味検索すれば解決だ！」——その直感は間違っていた、というのがこの記事の核心だ。

RAGが抱える「セマンティック・ギャップ」問題

「ブックマークの並べ替え機能を実装して」とエージェントに頼むと、RAGは「ブックマーク」「並べ替え」というキーワードでベクトル検索をかける。しかし本当に必要なのは 「UseCaseの責務定義」「ドメインモデルの粒度ルール」「プロジェクト固有の例外設計」 といった、実装キーワードとは意味的にかけ離れたアーキテクチャ規約だ。

このギャップをRAGは確率的にしか埋められない。AIの「勘」が冴えた日は適切なドキュメントを引っ張れるが、そうでない日は的外れな情報でトークンを浪費する。品質がAIの気分に左右される開発など、プロダクションには持ち込めない。

Aegis：「検索」ではなく「コンパイル」する

ゆめみ社のエンジニア・fuwasegu氏が開発した Aegis は、RAGを一切使わない。代わりに DAG（有向非巡回グラフ） でドキュメント間の依存関係を定義し、対象ファイルパスから再帰的にコンテキストを収集する「コンパイラ」として動作する。

仕組みはシンプルだ：

• app/UseCases/ を編集しようとする → usecase_guidelines.md が必要
• usecase_guidelines.md を読む → 前提として entity_guidelines.md と exception_guidelines.md も必要
• 依存グラフを辿って全て自動取得

技術的には SQLite + 再帰CTE でグラフを実装。RAGのような確率的ランキングは一切なく、同じファイルパスへの変更には常に同じガイドライン群が返る。この「決定性」こそが最大の強みだ。タイトルの「消費トークン1/12」はこの効率化から来ている。

セルフレビューで知識ベースが育つObservationサイクル

Aegisの面白さは初期設定で終わらない点にある。エージェントがコードを書いた後、セルフレビューでガイドライン不足を発見 → aegis_observe で報告 → 分析パイプラインが改善Proposalを自動生成 → 人間が承認/却下 というフィードバックループが回り続ける。

aegis_observe({
  "event_type": "compile_miss",
  "payload": {
    "target_files": ["src/api/handlers/user.ts"],
    "review_comment": "APIハンドラのバリデーション規約が不足していた"
  }
})

重要なのは Agent Surface（読み取り専用4ツール）とAdmin Surface（管理用16ツール）が完全分離 されている点。エージェントは「不足を報告する」だけで、知識ベースの変更権限は持たない。成長は常に人間がコントロールする設計だ。

セットアップは3ステップ

Cursor・Claude Code・Codex いずれでも npx @fuwasegu/aegis で起動できる。

{
  "mcpServers": {
    "aegis": {
      "command": "npx",
      "args": ["-y", "@fuwasegu/aegis", "--surface", "agent"]
    },
    "aegis-admin": {
      "command": "npx",
      "args": ["-y", "@fuwasegu/aegis", "--surface", "admin"]
    }
  }
}

1. MCP設定に上記2サーバーを追加
2. エージェントに「Aegisを初期化してアダプタールールをデプロイして」と依頼
3. Admin surfaceでアーキテクチャドキュメントをインポートし、ファイルパスとのエッジを設定

所感：「確率的知識検索」から「決定的依存解決」へのパラダイムシフト

AI駆動開発の課題として「コンテキスト管理」は常に語られてきたが、RAGという「もっともらしいアプローチ」に疑問を投げかけたこの設計思想は本質的だと思う。コードのコンパイルが決定的であるように、エージェントへの知識供給も決定的であるべき——その原則は、規模が大きくなるほど効いてくる。

チームで Claude Code や Cursor を本格運用しているなら、ドキュメント管理の仕組みを見直すきっかけとして、Aegisのアーキテクチャは一読の価値がある。