はじめに
2026年6月、Google が Open Knowledge Format（以下、OKF）を発表しました。
一言でいえば、AI と人間の両方が読める Wiki の書き方を決めたオープン仕様です。中身は Markdown ファイルのディレクトリと YAML のメタデータだけで、特別なツールや環境の準備は要りません。
本記事では OKF の概要と、実際に試してみたい方向けに要点を整理します。
1. OKF とは
一言で
一言でいえば ナレッジを Markdown でまとめるときのルール です。
OKF はサービスや製品ではなく、ナレッジを Markdown でまとめるときの共通ルールです。Google はこれを「Format, not Platform」（フォーマットであってプラットフォームではない、つまり仕様だけを提供して、製品やサービスは付かない）と呼んでいます。
ルールの中身はシンプルです。
- 1 トピック（concept、概念）= 1 つの Markdown ファイルにする
- ファイル先頭に YAML で
type（種別） を書く - ファイル同士は通常の Markdown リンクでつなぐ
- 目次（
index.md）と更新履歴（log.md）は任意
何が必須で何が任意か、という細かい話は次の節の最後で回収します。まずは「どんな見た目になるか」を見てみましょう。
OKF の何が良いのか
AIエージェントに渡すべき知識の多くは、社内の内部知識です。テーブル定義、指標の計算方法、運用手順、API の仕様などです。しかしこれらは Wiki・カタログ・コード・人の頭に散らばっています。
その結果、エージェントを作るたびに必要なコンテキストをゼロから組み立て直すことになります。Google Cloud Blog ではこれを context-assembly problem（コンテキストの組み立て直し問題）と呼んでいます。詳しくは後半の「ポイント」で補足します。
OKF を使うことで、AIを使いながら必要なコンテキストを蓄積し、そしてそのまま活用することができるようになります。
OKFは 散在した知識を git で管理できる Markdown ファイルに一度まとめ直して（コンパイルして）維持するように設計しています。RAG のように質問のたびに探し直すのではなく、Agentや人がソースを読んで OKF bundle に翻訳しておき、あとは index.md から辿るだけで済むようになるのが良い点です。
具体的にどんなものか
OKF に沿ったファイル群のことを bundle（バンドル） と呼びます。例として、BigQuery にある売上関連のテーブル群をナレッジとしてまとめる場合は、こうなります（公式ブログのサンプルを基にしています）。
sales/
├── index.md # 目次
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md # 注文テーブル
│ └── customers.md # 顧客テーブル
└── metrics/
├── index.md
└── weekly_active_users.md # 指標の定義
ディレクトリ階層がそのままナレッジの見取り図になります。
ファイルの中身は メタデータ（YAML） と 本文（Markdown） の2部構成です。orders.md を開くとこんな感じです。
---
type: BigQuery Table
title: Orders
description: 完了注文1件につき1行
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 | 注文を一意に識別する ID |
| customer_id | STRING | FK → [customers](/tables/customers.md) |
# Joins
`customer_id` で [customers](/tables/customers.md) と結合します。
メタデータでは検索・絞り込みに使う少数の項目だけを構造化し、それ以外（スキーマ表・Join 関係・サンプル等）は本文の Markdown で自由に書きます。
ここで最初の「ルール」を回収します。メタデータのうち必須は type の1行だけで、それ以外（title, description, resource, tags, timestamp 等）は推奨または任意です。type の値も自由に決められます（BigQuery Table, Playbook, Metric など）。チーム内で揃えれば十分です。
つまり、普段から「Markdown + フォルダ構成 + リンク」でナレッジを残している人なら、ファイル先頭に type を足すだけで OKF に準拠できます。
源流 — Karpathy の LLM-Wiki と Google の関係
OKF の思想的な源流は、OpenAI の創業メンバーであり、Tesla の AI ディレクターも務めた著名な AI 研究者・教育者 Andrej Karpathy（アンドレイ・カーパシー）が 2026年4月に公開した LLM-Wiki です。
典型的な RAG（質問のたびに大量のドキュメントから関連断片を検索する仕組み）では、ドキュメントを追加・更新しない限り情報が蓄積されていきません。LLM-Wiki は逆に、LLM が Markdown の wiki を継続的にメンテナンスしていく 仕組みです。Karpathy 自身の言葉を借りれば「LLM は飽きないし、相互参照の更新を忘れないし、1回で15ファイル触ることもできる」。
退屈な保守作業こそ LLM 向きだ、という発想です。（ここ重要！）
具体的には、Agentに依頼してソースを読ませ、要約を書かせ、関連ページを更新してもらいます。散らばった情報を wiki にコンパイルして蓄積する、というのが LLM-Wiki の核心です。Obsidian、AGENTS.md、index.md / log.md の蓄積など、似た発想のパターンは各所で再発見されてきましたが、それぞれが独自仕様でした。
なぜ Google が OKF を発表したのか？
Karpathy 個人のプロジェクトを Google が引き継いだわけではありません。Google Cloud Blog でも「Karpathy の wiki とあなたのチームの wiki とベンダーのカタログ出力は似ているが、意図的に協調するよう設計されていなかった」と書かれています。
つまり Google は、各所に広がっていた LLM-Wiki 型の慣習をベンダー中立なオープン仕様として固定した、という位置づけです。
Karpathy は思想的な源流であり、OKF v0.1 の仕様策定・公開は Google Cloud Data Analytics チームが担っています。
- 2026年4月 — Karpathy「LLM-Wiki」公開。同型パターンが各所に広がる
- 2026年6月12日 — Google Cloud が OKF v0.1 を公開。広がっていた慣習を相互運用可能な仕様に固定
仕様・参考実装は Apache 2.0 で knowledge-catalog リポジトリ に公開されています。
設計3原則
OKF の中身がここまでシンプルなのには理由があります。仕様に書かれている3つの設計原則を見ると、その意図が分かります。
-
Minimally opinionated（最小限の規約） — 必須は
typeフィールド1つだけ。どんな型を作るか、本文に何を書くかは作り手に委ねられている - Producer/consumer independence（生産者と消費者の独立） — 人が手で書いた bundle を Agentが読んでもよいし、パイプラインが自動生成した bundle を人が閲覧してもよい。両端のツールは差し替え自由
- Format, not platform（プラットフォームではなくフォーマット） — 特定のクラウド・DB・モデル・エージェントフレームワークに依存しない。価値は「何社がそれを話せるか」から生まれる
要するに「相互運用のための最小限の取り決め」だけが仕様であり、それ以外は意図的に決めていません。
類似する概念との違い
AI エージェントの周辺には、OKF と似た目的を持つ規約や技術がいくつかあります。「MCP や RAG とどう違うの？」と混同しやすいので、役割を表で整理します。
| 規約 | 役割 | OKF との関係 |
|---|---|---|
| llms.txt | サイトの道標（何がどこにあるか） | 入口を示す／中身は OKF |
| AGENTS.md | エージェントへの運用ルール | 「この OKF を読め」と指示する |
| OKF | キュレーションした知識の本体 | 図書館そのもの |
| MCP | ツール・DB へのライブ接続 | 行動時の接続（how）／OKF は事前知識（what） |
| RAG | 都度検索で断片を取得 | OKF への到達手段にもなれる／排他ではない |
つまり、OKF は「事前に書いておく知識」を担い、MCP や RAG は「その場で取得・接続する仕組み」を担う、という棲み分けです。例えば「週次アクティブユーザーの定義」は OKF に書いておき、実際に BigQuery へ問い合わせるのは MCP 経由、という使い分けになります。RAG とも排他ではなく、OKF の bundle を RAG の検索対象にする併用もできます。
どれか一つを選ぶ話ではなく、自分たちがどの層を持っていて、どこが欠けているかを点検するのが実務的です。
2. 仕様の要点
詳細は okf/SPEC.md（約450行）です。ここでは活用にあたって知っておけば困らない要点に絞って解説します。
Bundle
OKF では、関連する Markdown ファイルをまとめたディレクトリのことを bundle と呼びます。1 ファイル = 1 concept、ファイルパスがそのまま concept の識別子になります。
配布は git リポジトリ（推奨）、tarball、zip など自由です。
リンク
concept 同士は通常の Markdown リンクでつなぎます。書き方は2通りあります。
[customers](/tables/customers.md)— bundle ルート相対（推奨）[neighbor](./other.md)— 相対パスも可
ナレッジを書き留めるツールとして広く使われている Obsidian には [[wikilink]] という独自のリンク記法がありますが、これは OKF の仕様外です。Obsidian を使っているユーザーの移行体験記では、この点が最大のトレードオフとして挙げられています。
index.md と log.md
- index.md — ディレクトリの目次。エージェントが全ファイルを一度に読まず、必要な枝だけ辿れるようにする役割
-
log.md —
## YYYY-MM-DDの見出しで更新履歴を記録（新しい順）
どちらも任意です。
準拠（Conformance）
bundle が OKF v0.1 に準拠する条件はこれだけです。
- 予約名（
index.md/log.md）以外の全.mdに YAML frontmatter がある - 全 frontmatter に空でない
typeがある -
index.md/log.mdがあれば所定の構造に従う
ここでいう消費側（consumer）とは、bundle を読む側のことです。人間がエディタで開く、AI エージェントが index.md から辿る、ビジュアライザがグラフ表示する、といったツールやプロセスを指します。
消費側は寛容に設計されており、壊れたリンクや未知の type があっても bundle を拒否しません。Agentが育て途中の wiki でも使えるようにするためです。
3. 使い方
公式の実装例 — BigQuery のテーブル定義を自動で OKF 化する
Google は参考実装として Enrichment Agent を公開しています。これは OKF の仕様に沿って BigQuery のデータセットを走査し、テーブルごとに Markdown ファイルを自動生成する Agent です。
Google Agent Development Kit（ADK）と Gemini で構築されており、2 段階の処理（1: BigQuery メタデータから草案を書く / 2: 公開ドキュメントから引用・Join 関係などを補強する）で bundle を作ります。
公式リポジトリ（knowledge-catalog/okf）の README に沿うと、セットアップから実行までは次の流れです。
# 1. リポジトリを取得
git clone https://github.com/GoogleCloudPlatform/knowledge-catalog.git
cd knowledge-catalog/okf
# 2. 仮想環境を作って Enrichment Agent をインストール
python3.13 -m venv .venv
.venv/bin/pip install --index-url https://pypi.org/simple/ -e .[dev]
# 3. 認証
# BigQuery: gcloud auth application-default login
# Gemini : GEMINI_API_KEY を設定（または Vertex AI を利用）
# 4. bundle を生成
.venv/bin/python -m enrichment_agent enrich \
--source bq \
--dataset <project>.<dataset> \
--out ./bundles/<name>
# 5. グラフ表示（単一 HTML を生成）
.venv/bin/python -m enrichment_agent visualize --bundle ./bundles/<name>
サンプル bundle（GA4 / Stack Overflow / Bitcoin）がリポジトリに同梱されているので、GCP 環境がなくても bundle の構造とビジュアライザを確認できます。
BigQuery 以外のデータソースにも使えるか
この Enrichment Agent は BigQuery 向け producer（生産側）の一例 です。公式では、DB を走査するスクリプトや既存カタログ（Unity Catalog 等）からの export など、producer を自分で書ける前提になっています。OKF が決めるのは出力の形（Markdown + frontmatter）だけで、入力元は実装次第です。
Snowflake 等の他 DWH も、メタデータを読むスクリプトを書けば同型にできます。Slack の会話ログやチャット履歴などは公式の参照実装はありませんが、export したファイルを置いて Agentに OKF 形式で整理させる、といった軽い運用も可能です（次の節）。
個人利用する最小構成案（私なりの案）
ここからは公式の例ではなく、個人で OKF をとりあえず試してみたい場合に、私なりに組んでみた最小構成です。前の節の Enrichment Agent が BigQuery 向けの重い producer なら、こちらは手元のメモや export ファイルをコンパイルする軽い producer として使えます。
公式の Enrichment Agent は BigQuery × チーム展開を前提とした実装で、初見だとセットアップだけでハードルがあります。
一方、OKF の仕様自体はとてもシンプルなので、もっと軽く始めることもできます。手元の AI ツール（ChatGPT、Claude、Cursor 等）と GitHub だけで動かす形です。
ディレクトリ
my-knowledge/
├── AGENTS.md # AI への運用ルール
├── raw/ # 元ネタ（記事・メモ・議事録）
└── knowledge/ # OKF bundle（ここが本体）
├── index.md
├── log.md
└── concepts/
始め方（3ステップ）
-
メモを置く — 読んだ記事・調べたこと・議事録を
raw/に Markdown でそのまま放り込む -
AI に整理を頼む — 「
raw/の新しいファイルを読んで、knowledge/配下に OKF 形式（type必須）の concept を作って」と依頼。AI がファイルを生成・更新 -
レビューして commit —
git diffで AI が書いた内容を確認 → 問題なければ commit
さらに、チームで GitHub リポジトリを共有すれば、同じ bundle を全員で育てられます。PR でレビューしながらナレッジを蓄積する形でもよいですね。
それ以降は、消費側として作業中に「knowledge/ から○○の定義を探して教えて」と聞けば、AI が index.md から辿って答えてくれます。
AGENTS.md に書くこと
以下の内容を最小限として書いておけば、Agentが bundle を読み込んで使える想定です。
# このリポジトリの使い方
- OKF bundle は `knowledge/` 配下
- 作業前に `knowledge/index.md` を必ず読む
- ナレッジの取り込みを依頼されたら: `raw/` を読み、concept を更新し、`log.md` に追記
公式の参照実装との違い
| 観点 | 公式 Enrichment Agent | この最小構成 |
|---|---|---|
| 想定 | チーム・データ基盤向け | 個人がメモから始める |
| 入力 | BigQuery のメタデータ | 手元の記事・メモ |
| 必要環境 | Python + ADK + Gemini + GCP 認証 | 手元の AI ツールと GitHub |
| 自動化 | 2 段階 LLM パイプライン | チャットで都度依頼 |
OKF は仕様が自由なので、こうした規模の小さい運用にも素直に乗ります。
4. Knowledge Catalog（旧 Dataplex）との関係
Google Cloud には Knowledge Catalog（以下、KC。旧 Dataplex）というマネージドサービスがあります。OKF の公式リポジトリ名も knowledge-catalog で、名前が似ていて混同しやすいので、関係を整理します。
種類が違う
| Knowledge Catalog | OKF | |
|---|---|---|
| 正体 | 製品（マネージドサービス） | オープン仕様 |
| 費用 | 有料 | 無料 |
| ベンダー | GCP 必須 | 中立 |
リポジトリ名が knowledge-catalog なので「OKF = KC の一部？」と思いやすいのですが、OKF はリポジトリの中の独立した仕様（okf/ 配下） で、GCP を使わなくても単体で利用できます。
KC で OKF が使えるようになった
両者の接点はここです。Google Cloud Blog によれば、KC が OKF bundle を読み込めるようになり、社内のエージェントに配信できるようになりました。
[OKF bundle] ──読み込み──▶ [Knowledge Catalog] ──配信──▶ [AI Agent]
KC は元々「組織内のデータを横断的にカタログ化し、AI エージェントにセマンティクスや業務文脈を提供する」プラットフォームです。今回の対応で、手書きしたり Enrichment Agent で生成した OKF bundle を、そのまま KC 経由でエージェントに渡せるようになりました。
GCP 上でエージェントを運用しているチームにとっては、自社のカタログと OKF を直接つなげる経路ができたことになります。
たとえるなら、OKF は PDF や HTML のような規格、KC は Acrobat やブラウザのような規格を扱う製品です。OKF を学んでおくと「KC に入れる知識の形」が先に分かるので、KC 本体の理解もスムーズになります。
5. まとめ
OKF とは何か
AI と人間の両方が読める Wiki の書き方を決めたオープン仕様。必須は type フィールドだけで、特別なツールは不要です。
何を解こうとしているか
社内に散らばった知識を、エージェントに毎回組み立て直させる状態（context-assembly problem）の解消。散在した情報を OKF bundle にコンパイルして維持し、git で管理できる Markdown にまとめます。
どう使うか
公式の Enrichment Agent で BigQuery から自動生成するか、個人なら手元の AI ツール + GitHub で始められます。
現状の位置づけ
v0.1 Draft 段階です。全面移行ではなく、1 領域の pilot（10 concept 未満）から始めるのが現実的です。
6. ポイント
気になった点を整理します。
GCP の利用は必要か
不要です。OKF はオープン仕様なので、どの環境でも単独で使えます。
RAG との使い分け
併用できます。RAG は都度検索、OKF はコンパイルして維持する、という棲み分けです。OKF bundle を RAG の検索対象にすることも可能です。
コンテキストの組み立て直し問題（context-assembly problem）とは
「なぜ OKF が必要か」で触れた問題の補足です。エージェントに質問するたびに、テーブル定義・業務ルール・過去の議事録などの前提知識をその場で寄せ集めないと答えられない状態を、公式では context-assembly problem と呼びます。Wiki・カタログ・コード・人の頭に知識が散らばっていると、エージェントを作るたびに同じ作業を一からやり直すことになります。
「コンパイル」とは
先の節でも使った比喩で、プログラムのコンパイルとは別物です。散らばった生の情報を、Agentや人が読みやすい OKF bundle に一度まとめ直し、継続的に更新していくことを指します。一度 bundle にまとめておけば、次の質問では index.md から辿るだけで済みます。
7. 感想
OKF を色々調べてみて、まず良いと感じたのは「Markdown とフォルダ構成だけで成立する」点でした。特別なツールの準備が要らないので、思いついたその日に試せます。新しいフォーマットというより、すでに自分が書いている Markdown に type を1行足すだけ、というハードルの低さが何より魅力的です。
実は普段から、トピックごとに README を置いて関連 Markdown へリンクで降りていく書き方をしていたので、OKF を見たときは「同じ方向のことを考えている人たちがいるんだ」と少し嬉しくなりました。共通ルールが整うと、ナレッジが個人や1チームを超えて運用できるようになる点が、特にこれからの価値だと思っています。