GoogleのオープンナレッジフォーマットOKF vs. RAG：これはAIメモリの未来なのか？

要約： Google Cloudは2026年6月、オープンナレッジフォーマット（OKF）を発表した——AIエージェントが知識を取得・利用する方法に挑むベンダー中立のMarkdown仕様だ。RAGとの比較と、なぜこれが重要なのかを解説する。

---

はじめに

過去数年間、検索拡張生成（RAG）は、AIシステムに外部知識へのアクセスを与えるための定番のソリューションだった。しかし2026年6月、Google Cloudはひっそりと、パラダイム全体を再構築しかねないものを投入した：**オープンナレッジフォーマット（OKF）**だ。データベースではない。新しいAIモデルでもない。フォーマットだ——そしてまさにそれが、これほど強力な理由だ。

---

RAGとは何か、そしてなぜ私たちはそれを愛していたのか

RAG（検索拡張生成）は、大規模言語モデル（LLM）を外部の知識ベースに接続することで機能する。ユーザーが質問すると、検索器（retriever）が知識ベースから関連するテキストの断片を検索し、モデルのコンテキストウィンドウに注入し、LLMはその取得内容に基づいて回答を生成する。

RAGの強み

• はい — 再訓練なしでLLMを最新の状態に保てる
• はい — 実在する文書に回答を根拠づけることで幻覚を減らす
• はい — 大規模で非構造化の文書コーパスに適している
• はい — 広く採用されており、成熟したツールがある（LangChain、LlamaIndexなど）
• はい — 柔軟——ほぼどんなベクトルデータベースにも接続できる

RAGの弱み

• いいえ — 同じ事実に対して同じ文書を繰り返し取得する——無駄が多く遅い
• いいえ — 知識が互換性のないサイロ（Wiki、カタログ、コードコメント、人の頭の中）に分断されている
• いいえ — すべてのエージェント開発者が同じコンテキスト構築問題をゼロから解いている
• いいえ — 取得された断片には構造がない——モデルはメタデータや関係性のない生のテキストしか得られないことが多い
• いいえ — 標準化されたフォーマットがないため、ベンダーロックインとゼロの可搬性を招く
• いいえ — 大規模になるとベクトル検索のオーバーヘッドにより高レイテンシになる

---

GoogleのオープンナレッジフォーマットOKFとは何か

2026年6月12日にGoogle Cloudが発表したOKFは、組織の知識をYAMLフロントマター付きのMarkdownファイルのディレクトリとして保存するための、オープンでベンダー中立な仕様だ。AI知識のUSB-Cケーブルのようなものだと考えてほしい——独自のSDK、API、ロックインなしで、誰もが生成できて誰もが消費できる汎用コネクタだ。

この核となる発想は、AI研究者Andrej Karpathyからインスピレーションを受けている。彼は「LLM Wiki」パターンを明確に述べた：AIを使って生の文書を何度も検索する（RAG）のではなく、AIに永続的で生きたWikiを段階的に構築・維持させる、という考え方だ。Karpathyはこう述べている：

「LLMは飽きることがなく、相互参照の更新を忘れることもなく、一度に15個のファイルに触れることができる。」

---

OKFの仕組み

OKFバンドルは単純にMarkdownファイルのディレクトリだ。各ファイルは1つの「コンセプト」——テーブルのスキーマ、指標の定義、運用手順書（ランブック）、APIエンドポイント、チームが記録する必要のあるものは何でも——を表す。

図：OKFバンドルはコンセプトファイルのディレクトリであり——それぞれYAMLフロントマターとMarkdown本文を持つ——リンクによって走査可能な知識グラフを形成する。

各ファイルは2つの部分から構成される：

YAMLフロントマター — 構造化された、クエリ可能なメタデータ：

---
type: BigQuery Table
title: Customer Orders
description: One row per completed order
resource: https://console.cloud.google.com/bigquery?...
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---

Markdown本文 — 自由形式の文章、スキーマ、例、結合パス、その他何でも。

ファイルは通常のMarkdownリンクを使って相互にリンクし、人間とAIエージェントの両方が走査できる知識グラフを形成する。必須のフィールドは1つだけ：type。その他はすべて任意だ。

---

OKFの強み

• はい — ベンダー中立——SDK、APIキー、独自のランタイムは不要
• はい — 人間とAIの両方が読める——同じファイルが両方に機能し、変換層は不要
• はい — バージョン管理——コードと一緒にGitに保存される
• はい — 永続的かつ蓄積的——知識は毎回再取得されるのではなく、時間をかけて成長する
• はい — 相互運用可能——あるチームが書いたWikiを、変換なしで別のエージェントが消費できる
• はい — 設計上最小限——必須フィールドは1つ（type）だけで、他はすべて柔軟
• はい — コンテキストの断片化を解決——1つの標準フォーマットが分散したカタログ、Wiki、共有ドライブを置き換える
• はい — 生産者/消費者の独立性——誰が知識を書き、誰がそれを読むかが完全に分離されている

OKFの弱み

• いいえ — 非常に新しい（v0.1）——2026年6月に発表され、エコシステムとツールはまだ発展途上
• いいえ — 事前のキュレーションが必要——誰か（人間かAI）がWikiを構築・維持しなければならず、生の文書から自動生成されるわけではない
• いいえ — 非構造化・大規模コーパスには最適ではない——事前構造のない何百万もの生文書がある場合、RAGはまだ優位に立つ
• いいえ — 組み込みの検索・取得メカニズムがない——OKFはフォーマットであり、プラットフォームではない；提供層は自分で構築または統合する必要がある
• いいえ — 採用リスク——新しいオープン標準として、真に相互運用可能になるにはコミュニティとベンダーの採用に依存する
• いいえ — 保守の負担——AIが助けてくれても、生きたWikiを正確かつ最新に保つには継続的な努力が必要

---

OKF vs. RAG：正面比較

---

OKFはRAGを置き換えるのか

完全にはそうではない——それが誠実な答えだ。OKFとRAGは異なる層で異なる問題を解決する。RAGは、膨大で非構造化の文書ライブラリがあり、それらを動的に検索する必要がある場合に優れている。OKFは、テーブルスキーマ、指標の定義、運用手順書、結合パスなど、エージェントが繰り返し確実に必要とする、精選され構造化された組織の知識がある場合に優れている。

より正確な捉え方はこうだ：OKFは、多くの一般的な企業向けAIエージェントのシナリオにおいてRAGの必要性を置き換える。 エージェントがクエリを実行するたびにデータスキーマについての同じ事実を再取得するのではなく、エージェントが読み、更新し、走査できるOKF Wikiを与える。知識は常にそこにあり、常に構造化されており、常に最新だ。

図書館（RAG）と、よく整備されたチームのハンドブック（OKF）の違いだと考えてほしい。両方とも有用だ。しかし日々の業務には、ハンドブックが必要だ。

---

これがAIの未来にとって重要な理由

断片化されたコンテキストの問題は、今日の企業AIにおける最大の静かなボトルネックの一つだ。知識は互換性のないサイロに存在している——独自のAPIを持つメタデータカタログ、ログインの壁の裏にあるWiki、リポジトリに埋もれたコードコメント、そして明日退職するかもしれないシニアエンジニアの頭の中だ。すべてのAIエージェント開発者が、同じコンテキスト構築問題をゼロから解いている。

OKFは、解決策がフォーマットであり、別のサービスではないというGoogleの賭けだ。知識をデフォルトで可搬的、バージョン管理可能、そしてエージェントが読めるようにすることで、OKFはAIエージェントが組織を理解するための基盤層になる可能性がある——HTTPがWebの動作の基盤になったのと同じように。

---

結論

RAGは実在する問題への見事な解決策であり、消えることはない。しかしOKFは、AIエージェントが組織の知識とどのように関わるべきかについての根本的な再考を示している——検索問題としてではなく、生きたドキュメンテーションの問題として。エコシステムがこれを採用すれば、OKFはAIエージェントを企業環境において劇的に信頼性が高く、可搬的で、有用なものにできる可能性がある。フォーマットはシンプルだ。しかし、その影響はシンプルではない。