GraphRAG

「現在の90%のAI Agentの記憶は偽物だ」——AI研究者 @AYi_AInotes がXでこう発言し、大きな反響を呼んでいる。 多くの開発者が同じ罠にはまっている。「会話履歴や決定ログをMarkdownファイルに溜め込めば長期記憶になる」という誤解だ。 この記事では、なぜMarkdownダンプが「記憶」ではないのか、4つの根本的欠陥と2026年時点で実用可能なグラフ×埋め込みベースの代替設計を解説する。 Markdownファイルへの履歴ダンプが崩壊するまで @AYi_AInotes 自身の失敗談がわかりやすい。失敗は次の順序で進んだ。 全ての会話履歴・決定ログをMarkdownファイルに蓄積 「これで長期記憶が実現できた」と信じる 2週間で崩壊 崩壊の具体的な症状： 同一事実に3つの矛盾バージョンが存在する — 上書きも検証もなく書き足し続けた結果 先月の好みと昨日の重みが同等に扱われる — 時系列の概念がない 毎回全コンテキストを詰め込む — 遅延増大、コンテキスト汚染（クロストーク）が頻発 Markdownベース記憶の4つの根本的欠陥 1. 重複排除がない（No Deduplication） 同じ情報が何度も書き込まれ、どれが最新・正確かわからなくなる。矛盾する記述が増え続け、Agentが混乱する。 2. セマンティック検索ができない（No Semantic Retrieval） キーワードマッチしか使えず、関連情報を文脈で引き出せない。「先月の判断」と「今月の判断」の関係性が見えない。 3. 時系列優先度がない（No Temporal Weighting） 古い情報と新しい情報が同等に扱われる。ユーザーの好みが変化しても、Agentは古い情報に引きずられる。 4. エンティティ間の関係を持てない（No Relationship Modeling） 「AとBは関係がある」「Cの前提はDである」という構造を表現できない。フラットなテキストでは知識の構造化が不可能。 PromptをRAMとして使うことの問題 Markdownダンプを人間の記憶に例えると： 脳に情報を定着させるのではなく、ノートに書いて毎回全文を読み返すようなもの ノートが増えるほど読み返す時間が増え、矛盾も増える これは記憶ではなく、外部ストレージへの都度参照だ 本物の記憶は： 関連情報を索引化して素早く引き出せる 同じ情報を重複して持たない（圧縮・統合） 時間の経過とともに重要度が変化する 事実間の関係性を持つ Markdownダンプはこれを一切満たさない。PromptをRAMとして使っているだけだ。 本物の記憶 = グラフ + ベクトル埋め込み + トラバーサル 本物の記憶の設計原則は3つのコンポーネントで構成される： グラフ（Graph） 知識をノードとエッジで構造化する。エンティティ（人、概念、出来事）をノードとして、その関係をエッジとして保存する。「AはBを好む」「CはDに依存する」という関係が明示的に管理できる。 埋め込み（Embeddings） 各ノードをベクトルに変換することで、意味的に近い情報を検索できる。「先週の決定」と「今週の状況」の意味的類似性を計算し、関連する記憶だけを取り出せる。 トラバーサル（Traversal） グラフを辿ることで、直接リンクされていない関連情報も発見できる。「ユーザーの好みA → 関連する行動B → 影響を受けた決定C」という連鎖をたどれる。 ...

Claude CodeやCodexのようなAgent Harnessは、RAG（Retrieval-Augmented Generation）をほとんど使わないにもかかわらず、高精度なコード生成や理解を実現している。一方、RAGに依存しすぎたAgentはハルシネーションを起こしやすいという逆説がある。なぜこのような違いが生まれるのか？Software Engineer兼Database ResearcherのTaro L. Saito（@taroleo）氏のポストが、その本質を簡潔に説明している。 コンテキストウィンドウの拡大がRAGの必要性を変えた 現行のAIモデルのコンテキストサイズは20k〜1Mトークンに達している。これは、目安としておよそ100ファイル以下のコードベースであれば、RAGを介さずそのままコンテキストに収めて処理できることを意味する。 モデル コンテキストサイズ GPT-4o 128k tokens Claude Sonnet 4.x 200k tokens Gemini 1.5 Pro 1M tokens Claude CodeやCodexなどのAgent Harnessは、この大きなコンテキストウィンドウを活かして、必要なファイルを直接読み込みながらタスクを実行する。ベクトル検索による「関連しそうな断片」の取得ではなく、「実際に必要なコード全体」を参照できる。 RAGの弱点：断片的な情報がハルシネーションを生む RAGは「大量の文書から関連部分を検索して取得する」ことで、LLMに外部知識を与える仕組みだ。ドキュメント検索や広範な知識ベースへのアクセスには有効だが、コードベースのような相互依存が強い構造的情報に対しては課題がある。 RAG特有の問題点： 断片的なコンテキスト: ベクトル類似度で取得したチャンクは、実際の依存関係を無視している場合がある 欠落した情報: 関連するが類似度スコアが低いコードが検索から漏れる 矛盾した断片: 異なるバージョンや関連する別モジュールの断片が混在する こうした不完全な情報でコードを生成させると、存在しない関数を呼び出したり、実際のインターフェースと合わない実装を生成したりするハルシネーションが発生しやすい。 Agent Harnessが「100ファイル以下」で高精度な理由 Claude CodeのようなAgent Harnessが高精度に動く理由は、コンテキストウィンドウの有効活用にある。 プロジェクト構造の把握（ls、find など） 関連ファイルの直接読み込み（cat、read） 完全なコンテキストを持った上でコード生成・編集 RAGのように「類似チャンク」を取得するのではなく、ツールを使って必要なファイルを選択的に読み込むというアプローチだ。ファイル数が100程度であれば、現行のコンテキストサイズに収まるため、コードベース全体を「見た上で」タスクを実行できる。 これにより： 実際に存在する関数・型・インターフェースのみを参照する インポート関係や依存構造を正確に把握する プロジェクト固有の命名規則や設計パターンに従う ベクトル検索が有効なケースと直接読み込みが有効なケース NTT DATAのエンジニアリングブログ「ベクトル検索は不要なのか？」では、生成AI時代にRAGやベクトル検索をどう捉えるべきかを整理している。Taro氏のポストはこの記事を引用しており、「100ファイル以下という目安」はコンテキストサイズとトークン換算から導き出せる経験則だ。 ベクトル検索が有効なケース： 100ファイルを超える大規模コードベース（モノレポ、大企業の内部リポジトリ） 広範なドキュメント検索（社内ナレッジベース、技術文書） リアルタイム情報の取得（外部ドキュメント、最新の仕様） コンテキストに収まる場合に直接読み込みが有効なケース： 中小規模のプロジェクト（スタートアップのコードベース、個人プロジェクト） 特定モジュールへの集中作業 正確な依存関係の把握が必要な場合 RAG自体を強化する方向: GraphRAG という選択肢 「RAGを捨てて直接読み込み」ではなく、「RAGの断片性を補う」方向の研究もある。代表的なのがMicrosoft Researchが2024年に発表した GraphRAG だ。 GraphRAGの基本アイデアは次の通り： ...