Open Knowledge Format（OKF）を検証する：GoogleのAIエージェント向け知識フォーマットは何が新しく、どこまで本当か

対象 / ポイント

対象: AIエージェントや社内RAGの基盤を検討するエンジニア、データチーム、AIナレッジ基盤の企画担当者。

ポイント:

• OKFは新しいサービスではなく、AIエージェント向け知識をMarkdownとYAMLで表す交換フォーマットである。
• 新規性は、LLM Wiki的な実践そのものではなく、相互運用に必要な最小面だけを標準化した点にある。
• 「オープン」「ベンダー非依存」「セキュア」は、現時点では実績より設計思想として読むべきだ。

Google Cloudが2026年6月13日に Open Knowledge Format（OKF）を公開した。¹ AIエージェントが社内データを正しく使うため、テーブル定義、メトリクス、Runbookなどの知識を 「1概念 = 1つのMarkdownファイル」として表す提案である。

これは派手な新サービスではない。 むしろ地味なフォーマット案だ。 だが、AIエージェントが実務の文脈を毎回組み立て直している組織にとって、この地味さには意味がある。

この記事の問いは1つだ。 OKFは何を新しくし、Googleの主張のどこまでが2026年6月16日時点で検証できるのか。

OKFは何を解こうとしているのか

モデルが賢くなっても、実務で使えない場面は残る。 たとえば「週次アクティブユーザーはどう算出するのか」とAIエージェントに尋ねたとする。 答えは一箇所にない。

テーブルの意味はメタデータカタログにある。 計算ロジックはWikiにある。 例外処理はコードコメントにあり、最終的な解釈はベテランの頭の中に残っている。

その結果、エージェントは質問を受けるたびに、カタログAPI、Wiki、コード、ベンダー固有スキーマをまたいで文脈を組み立てる。 Google Cloud Blogはこれを context-assembly problem と呼んでいる。¹ 問題の本質は、知識が「特定のツールの中」に閉じ込められていることだ。

OKFはここに共通の入れ物を置く。 カタログ、Wiki、コードコメント、Runbookをすべて同じデータベースへ移すのではない。 AIと人間が読めるMarkdownファイル群として、交換できる形にそろえる。

OKFの正体：1概念 = 1Markdownファイル

OKFのbundleは、概念ごとにMarkdownファイルを並べたディレクトリである。 概念とは、テーブル、データセット、メトリクス、API、Runbookなど「説明したいもの」を指す。 仕様では、ファイルパスから .md を除いたものが概念IDになる。²

sales/
├── index.md
├── datasets/
│   └── orders_db.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly_active_users.md

各ファイルは、構造化フィールドを書くYAML frontmatterと、自由に書けるMarkdown本文に分かれる。 必須フィールドは type だけだ。 title、description、resource、tags、timestamp は推奨フィールドとして扱われる。²

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

## Schema

| Column      | Type   | Description                       |
|-------------|--------|-----------------------------------|
| order_id    | STRING | Globally unique order identifier. |
| customer_id | STRING | FK to [customers](/tables/customers.md). |

## Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

概念同士は通常のMarkdownリンクでつながる。 これにより、ディレクトリ構造は単なる親子関係ではなく、参照、join、依存、関連を含むグラフとして読める。 index.md は段階的に読むための一覧、log.md は更新履歴として予約されている。²

flowchart LR
  subgraph P[Producer]
    P1[人手で執筆]
    P2[カタログから生成]
    P3[LLMが合成]
  end
  B[OKF bundle<br/>Markdown + YAML<br/>Git管理]
  subgraph C[Consumer]
    C1[AIエージェント]
    C2[可視化ツール]
    C3[検索インデックス]
    C4[別のLLM]
  end
  P1 --> B
  P2 --> B
  P3 --> B
  B --> C1
  B --> C2
  B --> C3
  B --> C4

この図の中心は、作る側と読む側をフォーマットだけで疎結合にする点だ。 人が手で書いたbundleをAIが読んでもよい。 BigQueryから生成したbundleを静的ビューアで見てもよい。 形式が契約になり、ツールは後から入れ替えられる。

段階的開示はなぜ効くのか

OKFが狙う読み方は、bundle全体を丸ごとLLMへ投げ込むことではない。 まず index.md で概念の一覧と短い説明を見る。 次に description や type で当たりをつけ、必要な概念ファイルだけを開く。 本文内のリンクをたどれば、ordersからcustomersのように関連概念へ移れる。

この挙動を仕様は progressive disclosure と呼ぶ。²description は検索スニペットや一覧表示に効く。 type と tags は、本文を読ませる前に「Metricだけ」「Runbookだけ」と絞る鍵になる。

ここで重要なのは、OKFがランタイムを規定しない点だ。 仕様のゴールは、消費エージェントがどう読むべきかを示すところまでである。 保存基盤、検索基盤、権限管理、クエリAPIは対象外に置かれている。²

つまりOKFは「読みやすい知識ファイルの形」を出す。 それを本当に段階的に読むエージェントや検索基盤は、利用者側が用意する。 この線引きが、OKFの強みと弱みの両方を作っている。

なぜ「また新しいフォーマット」でも筋がよいのか

OKFの診断はかなり正しい。 相互運用のボトルネックは、エージェントや検索ツールの不足ではなく、知識の表現形式がそろっていないことにある。 OKFはそこへ、Markdownと type だけの低い入口を置く。

この軽さは重要だ。 厳密なメタデータ標準は、語彙体系、ガバナンス、データリネージ、品質契約まで抱え込みやすい。 正しく作れば強いが、導入の摩擦も大きくなる。

OKFは反対側に振っている。 標準化するのは、知識を交換するための最小面だけだ。 中身の分類体系や本文構造は、producerに任せる。

もう1つの追い風は、既存の実践に乗っていることだ。 Andrej KarpathyのLLM Wiki gistは、LLMがMarkdown wikiを保守し、raw sourceから知識を継続的に統合するパターンを示した。³ AGENTS.md、CLAUDE.md、Obsidian vault、llms.txt的な発想も同じ潮流にある。

OKFの新規性は、知識をMarkdown化するアイデアそのものではない。 すでに広がっている実践を、交換できる形に寄せようとした点にある。

どこまで「本当」か

2026年6月16日時点で確認できる事実は、かなり限定的だ。 OKF v0.1は公開から数日しか経っていない。 公式ブログで示されている実装は3つだ。 BigQuery datasetを走査してOKF concept documentを作るenrichment agent、静的HTML visualizer、 GA4、Stack Overflow、Bitcoinのサンプルbundleである。¹

「ベンダー非依存」は設計思想であって、まだ市場実績ではない。 仕様は特定クラウド、DB、モデル、agent frameworkに縛られないと説明している。¹ また、OKFのGitHub repoはApache 2.0で公開されている。⁴

ただし、フォーマットの中立性は複数のproducerとconsumerが現れて初めて実証される。 現時点で言えるのは「ベンダー非依存に設計されている」までだ。 Google外の継続的な採用が見えるかどうかは、これからの観察対象である。

「最小限の規約」は諸刃の剣である。 必須が type だけなら、BigQuery Table、table、dataset_table はすべて適合しうる。 仕様も、type値は中央登録されず、consumerは未知のtypeを許容すべきだとしている。²

これは採用コストを下げる。 一方で、読む側はproducerごとの差異を吸収する処理を書き続けることになる。 OKFが減らそうとしたcontext assemblyが、今度はtype正規化や語彙調整として残る可能性がある。

「セキュア」はフォーマット単体の性質ではない。 OKF仕様は、storage、serving、query infrastructureをnon-goalに置いている。² 権限管理、機密情報のマスキング、承認フロー、鮮度管理、データ品質は、OKFの外側で設計する必要がある。

Googleのvisualizerは、自己完結HTMLとしてbundleを表示するproof of conceptだ。 その実装上の扱いやすさと、組織全体のセキュリティモデルは別問題である。 OKFを導入しても、誰がどのbundleを作り、誰がレビューし、どこまでAIに読ませるかは残る。

自動生成された知識の品質も別問題である。 KarpathyのLLM Wikiは、LLMが人間の苦手な相互参照更新や整理作業を肩代わりできる点を示した。³ しかし、LLMは存在しないjoin経路を自然な文章で書くこともある。

enrichment agentが引用付きで概念を補強するとしても、その出力を誰が承認し、いつ古くなったと判断するのかは別レイヤーだ。 自信のある誤りがMarkdownとしてGitに残るなら、それは人間にもAIにも再利用される。 ここが実務上の一番危ない点である。

既存標準とは競合より補完に近い

OKFは、Avro、Protobuf、OpenAPIのような厳密なスキーマ標準を置き換えない。 仕様自身も、こうしたdomain-specific schemaは参照する対象であり、OKFが包含するものではないと明記している。²

近い領域の仕様や慣習と比べると、OKFの位置づけははっきりする。

仕様・パターン	標準化する対象	制約の強さ	OKFとの関係
OKF	知識の入れ物、ファイル構造、最小メタデータ	弱い。type のみ必須	本記事の対象
llms.txt	サイトのLLM向け案内	弱い	粒度が粗く、用途が異なる
AGENTS.md / CLAUDE.md	リポジトリ内のエージェント指示	弱い	ローカル運用向けで、交換規格ではない
OpenLineage / OpenMetadata	系譜、カタログ、メタデータモデル	強い	厳密だが、人が直接読む形とは限らない
データコントラクト	品質、契約、SLA	中から強	品質保証寄りで、OKFとは目的が違う

表が示すのは、OKFが軽さと厳密さのトレードオフで軽い側にいることだ。 カタログやデータコントラクトを捨てる話ではない。 むしろ、それらからAIが読める知識bundleを吐き出す補助フォーマットとして考えるほうが自然である。

実務では小さく試す

OKFを入れればAIナレッジ基盤が完成すると理解するのは危険だ。 妥当なのは、低コストの交換フォーマットとして小さく試すことだ。

向いている用途は明確である。

• メタデータ、メトリクス定義、RunbookをAIが読める形でGit管理する。
• RAGやエージェントの入力知識を、特定ベンダーに閉じないファイル群として持つ。
• 「このテーブルは何とjoinできるか」「このAPIは非推奨か」をリンクでたどれるようにする。

期待してはいけない用途も明確である。

• 権限管理、機密マスキング、承認、鮮度管理、データ品質をOKF単体で解く。
• 全社カタログをv0.1前提で一気に置き換える。
• LLM生成のdescriptionやjoin説明を、人間レビューなしで信頼する。

最小の入口は、既存のMarkdown資産を作り替えないことだ。 本文と構造はそのままに、frontmatterへ type、description、可能なら tags を足す。 これだけでも、AIはどの文書に何が書かれているかを探しやすくなる。

ただし、timestamp をAIに推測させてはいけない。 最終更新日はGit履歴やファイル更新時刻のような事実から取る。 推測した日付は、メタデータに自信のある誤りを刻む。

まとめ

OKFの貢献は、知識をMarkdown化するアイデアそのものではない。 貢献は、AIエージェントが読む知識の交換面を標準化しようとしたことにある。

これは筋のよい低コストな賭けだ。 ただし、「オープン」「非依存」「セキュア」は、2026年6月16日時点では実績より設計思想に近い。 導入判断を急ぐより、まず小さなbundleを作り、エージェントの回答精度と保守コストが本当に改善するかを見る。

半年から1年後に見るべき指標は、Google以外のproducerとconsumerが増えているかだ。 そこに広がりが出れば、OKFは標準になりうる。 出なければ、Google Cloud周辺で便利なMarkdown規約にとどまる。

関連記事

• 図で読むKarpathyのLLM Wiki：RAGを知識コンパイルへ変える発想と課題
• RAG三類型入門：検索・生成・エージェントの違いを整理する
• コンテキストエンジニアリング全体像

---

1. Introducing the Open Knowledge Format, Google Cloud Blog, 2026-06-13. ↩↩↩↩

2. Open Knowledge Format v0.1 SPEC.md, GoogleCloudPlatform/knowledge-catalog. ↩↩↩↩↩↩↩↩

3. LLM Wiki, Andrej Karpathy, GitHub Gist. ↩↩

4. GoogleCloudPlatform/knowledge-catalog, GitHub repository, Apache-2.0. ↩