Google Cloudはこのほど、AIエージェント向けのオープンな知識共有フォーマット「Open Knowledge Format（OKF）」を発表し、OKF v0.1をリリースした。この仕様はGitHub上でApache 2.0ライセンスの下に公開されており、仕様書の全文、リファレンス実装、サンプルデータセットが含まれている。一般的な「新モデル発表、計算能力や推論最適化の強調」とは異なり、OKFはモデルアーキテクチャやGPU性能の飛躍には直接関与しない。しかし、AIエージェントの実用化において繰り返し多大なコストが発生してきた課題、すなわち「AIに正しいコンテキストを取得させる」ための知識整理とエンジニアリングの再利用問題に照準を合わせている。
OKFは、チームやツールを超えて移行可能な「知識フォーマット」によって、こうしたサイロ化を打破しようとする試みだ。その中核はMarkdownファイルによるディレクトリ構造である。各ファイルは一つの「概念（concept）」に対応し、ファイルの先頭にはYAML frontmatterで最小限のメタデータを記述する。仕様上、必須フィールドはtypeのみに限定されており、title、description、resource、tags、timestampなどはすべて推奨項目となっている。Google CloudのData Cloudチーム技術責任者であるSam McVeety氏と、BigQuery技術責任者のAmir Hormati氏は連名のブログ記事で、OKFの本質を「Markdownであること」「ファイルであること」「YAML frontmatterは少数のクエリ可能な構造化フィールドのためだけに存在すること」の3点に集約している。
OKFの「最小限」の設計思想は、一見すると「物足りない」印象すら与えるが、まさにこの抑制こそが導入障壁を下げている。OKFは新たな知識整理法を発明したわけではない。開発者コミュニティがすでに実践で検証してきたパターンを、相互運用可能な標準として形式化したものだ。ObsidianやNotionを使用した経験があるチーム、あるいはリポジトリ内でAGENTS.mdやCLAUDE.mdといった規約ファイルを目にしたことがあるチームにとって、OKFの形式は一目で理解できる。それは、人間が編集可能で、GitHubがレンダリングし、検索ツールがインデックス可能なMarkdownウィキであり、概念同士は通常のMarkdownリンクで相互に参照し合うことで、ナビゲート可能なナレッジグラフを形成する。
業界の議論の観点から見ると、OKFが目指すのは「より賢いモデル」ではなく、エージェントシステムにおいて最も高コストな部分を前倒しし、標準化することにある。Andreij Karpathy氏が提唱した「LLM Wiki」の構想に沿って、議論はしばしば、LLMが機械的なメンテナンス作業（相互参照の更新、インデックスの一貫性維持、単一タスクでの複数ファイルへのアクセスなど）を得意とする点に集中してきた。問題は、この1年で「Markdown＋規約ファイル」路線の亜種が乱立したことだ。あるものはAGENTS.mdやCLAUDE.mdと命名され、またあるものはチーム内部で異なる構文を用いて「metadata as code」を整理していた。異なるチームが同じか類似した形式を用いながらも、クエリ可能なフィールドや相互運用のセマンティクスが各々の体系に依存していたため、組織を超えた再利用が困難になり、車輪の再発明が繰り返されてきた。
OKFは、この「標準化された文法書」の欠落を補おうとするものだ。Google Cloudは発表の中で、OKFと既存のエージェント／データアーキテクチャ関連メカニズムとの関係性を強調している。OKFは代替品ではなく、補完物である。MCP（モデルコンテキストプロトコル）が動的なツール呼び出しの「ソケット」に近いのに対し、OKFはそのソケットから「流れ出る」知識コンテンツの器を提供する。RAG（検索拡張生成）が大規模な動的ドキュメントの意味検索を解決するのに対し、OKFは安定的でキュレーション可能な構造化知識を対象とする。AGENTS.mdやClaude.mdが特定のリポジトリ内の自己記述的な規約であるのに対し、OKFはその規約を組織横断的な標準バージョンへと引き上げる。
外部にその実装方法を理解してもらうため、Google CloudはOKFの「生成」から「提示」までの完全なリンクを示す3つのリファレンス実装を同時に公開した。1つ目は「知識強化エージェント（enrichment agent）」である。これはBigQueryデータセットを走査し、各テーブルとビューに対してOKF概念ドキュメントの初稿を生成する。その後、2回目のLLM処理を起動し、信頼できるドキュメントページを自動的にクロールして、各概念ドキュメントに引用元、テーブル構造、テーブル間の関連パスを補完する。2つ目のリファレンス実装は、静的なHTML可視化ツールだ。任意のOKF知識パック（bundle）をインタラクティブなナレッジグラフとしてレンダリングし、独立したHTMLファイルのみで動作するため、バックエンドもインストールも不要で、ユーザーが閲覧するデータがページ環境から外部に流出することもない。3つ目は、直接閲覧可能な3つのサンプル知識パックで、Google Analytics 4のEコマースデータ、Stack Overflowの公開データセット、ビットコインの公開データセットをカバーしており、いずれもリファレンスエージェントによって自動生成され、GitHubリポジトリに提出されたものである。
仕様の例では、OKF知識パックはディレクトリ構造で整理され、MarkdownファイルとYAMLメタ情報を通じて概念を記述する。例えばサンプルでは、sales/ディレクトリの下にindex.md、datasets/orders_db.md、tables/orders.md、tables/customers.md、metrics/weekly_active_users.mdなどのファイルが含まれる。個々の概念ファイルのYAML部分では、typeのみが必須項目であり、その他のフィールドは例示として与えられる。「Orders」概念を例にとると、YAMLメタ情報にはtype（例：「BigQuery Table」）、title（Orders）、description、BigQueryコンソールのページリンクを指すresource、tags、timestampなどが含まれる。その後のMarkdown本文では、フィールドの説明とテーブル間の関連付けが記述され、例えばorder_idやcustomer_idのフィールドタイプと意味を説明し、「[customers]とcustomer_idで結合」といった形で結合関係が明示される。
Google CloudがOKFの設計に対して掲げた3つの原則もまた、「相互運用可能」という目標を貫いている。第1に「最小限の意見（minimally opinionated）」であること。type以外のフィールドや本文の構成方法などを強制せず、相互運用の表面（interoperability surface）のみを定義することで、フォーマットが特定のコンテンツモデルにさらに束縛されるのを避ける。第2に「生産者と消費者の独立性（producer/consumer independence）」である。人間が手書きした知識パックはAIエージェントが消費でき、機械が生成したメタデータのエクスポートも人間がテキストエディタで閲覧できる。異なるLLMや異なるエージェントフレームワークも、同一の契約に基づいてクエリと合成を実行できる。第3に「プラットフォームではなくフォーマット（format, not platform）」であること。OKFは特定のクラウドサービス、データベース、モデルプロバイダー、エージェントフレームワークに依存せず、仕様自体も専用アカウントやSDKを要求しない。
注目すべきは、Google CloudがOKFの発表と同時に、自社のKnowledge Catalog（知識カタログ）製品を更新し、OKF知識パックをネイティブに取り込めるようにした点だ。業界ではこれを、典型的な「まずオープン標準を確立し、次に自社製品を最初の互換製品にする」というパスと見ている。しかし、「最初はオープン、後から囲い込み」という一部のオープン戦略とは異なり、OKFはMarkdownファイルとYAML frontmatterのみで構成されており、障壁が低く、移行も容易である。言い換えれば、仮に将来メンテナンスのペースが変わったとしても、知識パックのテキスト構造は依然として可読、利用可能、かつ移行可能な状態を保つ。
より深い業界トレンドから見ると、OKFはAIエージェントのボトルネックが「モデルが十分に賢いかどうか」から「モデルが正しい情報を取得できたかどうか」へと移行しつつあることを反映している。基盤モデルの能力が向上し続ける中で、エージェントシステムが実践で直面する最大の障害は、往々にして推論能力の不足ではない。タスクが実行段階に移り、「イベントストリームから週間アクティブユーザーをどう計算するか」といった問いに答えなければならないとき、その答えは複数のデータカタログ、断片的な共有ドキュメント、そして少数のベテランエンジニアの頭の中に分散している。OKFが提供するのは、単一ポイントの技術力向上ではなく、知識を構造化可能、移行可能、かつ任意のエージェントが消費可能にするインフラストラクチャである。
市場および産業レベルでは、OKFは3つの領域に影響を与える可能性がある。第一に、企業内部のAI実装チームにとって、知識整理が「プロジェクトごとのカスタマイズ」から「再利用可能な相互運用フォーマット」へと移行することで、チーム間の移行コストと繰り返しの整理に費やす時間の削減が期待される。第二に、外部のサプライヤーやプラットフォームにとって、オープンフォーマットは「特定のフレームワークへのロックイン」という摩擦コストを低減し、エコシステムの協業を加速させる可能性がある。第三に、データと分析のチームにとって、OKFは「メタデータと参照パス」を検索・ナビゲート可能なナレッジグラフに組み込むことで、ガバナンスとコラボレーションにおいてより一貫性のある共通認識の形成を支援する。
同時に、多方面からは、標準の実際の採用ペースを注視する必要があるとの見方も出ている。OKFが「typeのみ必須、その他のフィールドは推奨」という特性を持つがゆえに、短期的には異なるチーム間でクエリ可能なフィールドの表現に差異が残り、システム間の自動化の程度に影響を与える可能性がある。しかし長期的に見れば、この抑制こそが、標準がより広範なツールチェーンに吸収されやすくする可能性もある。いずれにせよ、OKFはオープンな仕様とリファレンス実装に加えて、知識強化、可視化レンダリング、サンプル知識パックを一式で提供しており、単なる「言語レベル」の提案に留まらず、実行可能なエンジニアリングの道筋も示している。
総合的に見て、OKFは「Markdown＋YAML frontmatter＋ディレクトリ化バンドル」というオープンな構造によって、AIエージェントの知識管理に潜在的な汎用基盤を構築するものである。そのハイライトは、特定のモデル能力を置き換えることではなく、コンテキストと知識の整理を、一回限りのエンジニアリング作業から、相互運用可能なインフラストラクチャへと昇華させる点にある。投資家や産業ウォッチャーにとって、この種の標準の意義は往々にして時間軸で発揮される。より多くのシステムが同じ言語で知識を記述し始めたとき、エージェント間のデータとコンテキストの流動効率が初めて、徐々に規模の効果を生み出す可能性があるのだ。