AIエージェントに渡す文脈を、誰でも読めるMarkdownにまとめる共通ルールが出ました。

Google Cloudは2026年6月12日、Open Knowledge Format（OKF） v0.1を公開しました。Karpathy氏が提唱したLLM wikiの考え方を、ベンダー非依存のオープン仕様として形にしたものです。本記事では、OKFが解く課題と、バンドルの構造・導入のイメージを整理します。

この記事でわかること

  • OKFが標準化するのは「知識の置き方」であり、新しいクラウドサービスではない点
  • 必須フィールドはtypeだけで、MarkdownとYAML frontmatterで構成される点
  • 参照実装として公開されたBigQueryエンリッチメントエージェントとサンプルバンドル

https://github.com/GoogleCloudPlatform/knowledge-catalog

OKFが解く課題

大規模言語モデル（LLM）の性能は上がり続けていますが、エージェントが実務で使えるかは「正しい文脈があるか」で決まります。テーブルのスキーマ、指標の定義、インシデント対応手順、APIの非推奨情報など、組織内の知識はメタデータカタログ、社内Wiki、コードコメント、属人メモに散らばっています。

各ベンダーは独自のカタログAPIやSDKを持ち、知識は作った場所から持ち出しにくい状態です。エージェントを組むたびに、同じ「文脈の取り込み」をゼロから実装する負担が重なります。

開発現場では別の流れも広がっています。ObsidianのVaultをコーディングエージェントに接続したり、AGENTS.mdやCLAUDE.mdで運用ルールを書いたり、エージェントが参照するindex.mdやlog.mdをリポジトリに置く運用です。Andrej Karpathy氏のLLM wikiは、この「エージェントが読み書きするMarkdownライブラリ」という発想を端的に示しています。

ただし各チームのwikiは見た目は似ていても、必須フィールドやファイル名の意味がバラバラです。人間向けメモはそのままでは、別ツールのエージェントが解釈できません。OKFはここに、最小限の共通約束を足す仕様です。

OKF v0.1の中身

OKFはフォーマットであり、プラットフォームではありません。公式ブログの説明どおり、圧縮方式や専用ランタイム、必須SDKはありません。知識は「Markdownファイルのディレクトリ＋YAML frontmatter」として表現します。

1つの概念（テーブル、指標、Runbook、APIなど）は1ファイルです。パスが概念のIDになります。ファイル間は通常のMarkdownリンクでつなぎ、ディレクトリ階層だけでは表せない関係をグラフとして表現します。任意でindex.md（目次）とlog.md（更新履歴）を置けます。

frontmatterで必須なのはtypeだけです。例としてBigQuery TableやMetric、Playbookが挙げられますが、中央の型レジストリはなく、未知のtypeは汎用概念として扱う設計です。任意フィールドはtitle、description、resource、tags、timestampです。本文は見出し・リスト・表・コードブロックなど構造化されたMarkdownが推奨されます。

仕様書（okf/SPEC.md）は、次の3原則を掲げています。

  • 最小限の規約：相互運用に必要な表面だけを決め、中身の書き方はプロデューサーに委ねる
  • 作成者と利用者の分離：人が手書きしたバンドルも、パイプラインが吐いたバンドルも、別のエージェントがそのまま読める
  • フォーマットでありプラットフォームではない：特定クラウド、DB、モデル提供者、エージェントフレームワークに縛られない

RAG（検索拡張生成）が生ドキュメントから都度検索するのに対し、OKFはキュレーション済みの概念をバージョン管理し、エージェントが直接読み書きする前提です。用途が近いが、設計の焦点が異なります。

Googleが同時に公開した参照実装

仕様だけでは試しにくいため、GoogleはGoogleCloudPlatform/knowledge-catalogに実装例を置いています。

エンリッチメントエージェントはBigQueryデータセットを走査し、各テーブル・ビュー用のOKFドキュメントを下書きします。続くLLMパスで公式ドキュメントをクロールし、スキーマや結合パス、引用を追記します。静的HTMLビジュアライザは、OKFバンドルを単一のHTMLファイルに変換し、ブラウザ上でグラフ表示します。バックエンドは不要です。

サンプルバンドルはGA4 eコマース、Stack Overflow、Bitcoinの公開データセットの3種類です。いずれも参照エージェントが生成した準拠例としてリポジトリに含まれます。Google CloudのKnowledge CatalogもOKFの取り込みに対応し、エージェントへ配信できるよう更新されています。

実務で使うときの進め方

導入の第一歩は、既存の社内ナレッジを「1概念1ファイル」に分けることです。スキーマ説明、指標定義、障害対応手順など、エージェントに毎回説明している内容から始めると効果が見えやすいです。

各ファイルのfrontmatterにtypeを付け、関連概念へMarkdownリンクを張ります。Gitリポジトリで管理すれば、差分レビューやロールバックもコードと同じ手順で行えます。MCPのread_fileやLangGraphのファイルローダーなど、ファイルを読めるエージェントなら追加SDKなしでバンドルをtraverseできます。

BigQueryを使っている場合は、リポジトリのエンリッチメントエージェントで下書きを生成し、人間が内容を直すハイブリッド運用が現実的です。v0.1は出発点であり、仕様は後方互換を意識して拡張される想定です。IssueやPRでのフィードバックが公式に歓迎されています。

エージェント運用への意味

OKFは「もう一つのナレッジサービス」ではなく、エージェント時代の文脈交換フォーマットです。MarkdownとYAMLという既存技術だけで、人間の編集とエージェントの読み取りを同じファイルで両立します。Karpathy氏のLLM wikiが示した実践を、チームやツールをまたいで再利用できる形にした点が、今回の発表の核心です。自社の散在するメタデータから小さなバンドルを1つ作り、エージェントに読ませてみるのが、仕様の価値を測る最短ルートになります。