Googleが公開したAIエージェント向け知識共有フォーマット『OKF』を触ってみた

こんにちは、せーのです。

社内ドキュメントを AI エージェントに渡したい、という相談をよく受けます。Wiki もある、Notion もある、共有ドライブもある、という状態で「どう構造化すればいいの？」と悩んでいる方、多いと思います。

2026年6月12日、Google Cloud が Open Knowledge Format（OKF） v0.1 を GitHub で公開しました。AI エージェント向けの「知識共有フォーマット」です。

私は普段、Obsidian Vault にメモを書き、CLAUDE.md や AGENTS.md を置いて、コーディングエージェントにコンテキストを渡しています。ディレクトリ構造と Markdown リンクでナレッジを繋ぐ、いわゆる「LLM-wiki パターン」です。OKF を読んでみたところ、まさにこのやり方を形式化しようとしている、という印象を受けました。

今日は OKF とは何かを整理しつつ、手元で最小バンドルを書いてビジュアライザーで見てみた結果を共有します。

OKF（Open Knowledge Format）とは(おさらい)

OKF は、組織のナレッジを YAML フロントマター付きの Markdown ファイルのディレクトリ で表現する、ベンダー中立なオープン仕様です。

• 発表: 2026年6月12日（Google Cloud Blog）
• リポジトリ: GoogleCloudPlatform/knowledge-catalog/okf
• 仕様書: SPEC.md（約450行・1ページ程度）

設計思想は大きく3つです。

1. 最小限の意見性 — 必須フィールドは type だけ。それ以外はプロデューサー（書く側）に委ねる。
2. プロデューサー／コンシューマー独立性 — 人間が手書きしても、DB エクスポートで生成しても、静的ファイルサーバでも LLM でも、誰でも読める。
3. フォーマットでありプラットフォームではない — 特定クラウド・SDK・ランタイム不要。ただのファイルと Markdown だけで成立する。

つまり、各社がバラバラにやっていた CLAUDE.md / AGENTS.md / index.md だらけのリポジトリを、共通フォーマットとして整理しよう、という動きです。

なぜ今これが出たのか

AI エージェントが組織の業務に答えるには、散在するコンテキストをかき集める必要があります。現状、知識は次のような場所にバラバラに存在します。

• メタデータカタログ（各社独自 API）
• Wiki・サードパーティシステム・共有ドライブ
• コードコメント・docstring・ノートブック
• シニアエンジニアの頭の中（暗黙知）

ベンダーごとに独自のカタログ・SDK・スキーマがあり、エージェント構築者が毎回「同じコンテキスト組み立て問題」をゼロから解いている、というのが課題です。OKF は 翻訳レイヤー不要で、書く側と読む側を分離できる共通フォーマット として、この断片化を解こうとしています。

フォーマット仕様をざっくり読む

SPEC v0.1 を読んだ要点だけまとめます。

バンドルの基本構造

OKF バンドル = コンセプト（概念）を表す Markdown ファイルのツリー。1 コンセプト = 1 ファイル。ファイルパスがそのコンセプトの ID になります。

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

ディレクトリ構造はドメイン非依存で、組織のしかたはプロデューサーが決めます。

YAML フロントマター

---
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
---

type の値は中央レジストリに登録しません。プロデューサーが自明な値を選び、コンシューマーは未知の type も適切に扱う、という設計です。

Markdown 本文とグラフ構造

本文は自由です。スキーマ表やジョイン条件を書き、普通の Markdown リンクでコンセプト同士を相互参照します。これにより、ディレクトリの親子関係より豊かなリレーショングラフになります。

# 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`.

予約ファイル名

それ以外の .md はすべてコンセプトドキュメントとして扱います。

準拠基準

OKF v0.1 適合の条件はシンプルです。

1. すべての非予約 .md が、解析可能な YAML フロントマターを持つ
2. すべてのフロントマターが空でない type を持つ
3. 予約ファイル（index.md / log.md）が規定の構造に従う

コンシューマー側は寛容であるべき、と SPEC には書かれています（欠けたオプションフィールド、未知の type 値、壊れたリンクを許容する）。

OKF vs MCP vs llms.txt vs AGENTS.md（おさらい）

OKF は既存の仕組みと「競合」ではなく「積み重なる（stack）」関係です。

違いを整理すると、OKF は「何を知っているか」をファイルで渡す、MCP は「今何ができるか」を API で呼ぶ、llms.txt は「どこを読めばいいか」を案内する、AGENTS.md はリポジトリ固有の運用ルールを置く、というイメージです。

MCP 疲れ、という話題も耳にしますが、OKF は MCP の代替ではありません。静的ナレッジのフォーマットとして、MCP と並べて使う、と考えると整理しやすいです。

やってみた: 最小 OKF バンドルを手で書く

リファレンス実装の enrichment_agent は BigQuery + Gemini が必要なため、AWS 中心の読者にはハードルが高いです。そこで 手書きで最小バンドルを作る → ビジュアライザーで見る を主軸に進めました。誰でも再現できます。

Step 0. リポジトリを clone する

git clone https://github.com/GoogleCloudPlatform/knowledge-catalog.git
cd knowledge-catalog/okf
# SPEC.md を読む / bundles/ のサンプルを見る

リポジトリ構成のメモです。

knowledge-catalog/
├── agents/      # OKF 以外のエージェントサンプル
├── okf/         # OKF 本体（SPEC.md + enrichment_agent + bundles）
│   ├── SPEC.md
│   ├── bundles/ # サンプルバンドル3種
│   │   ├── ga4/
│   │   ├── stackoverflow/
│   │   └── crypto_bitcoin/
│   └── src/     # enrichment_agent パッケージ
└── toolbox/

Step 1. 最小バンドルを手で書く

mybundle/ を作り、1 コンセプト = 1 ファイルで Markdown を書きました。

mybundle/
├── index.md              # 予約ファイル（frontmatter なし）
├── tables/
│   ├── index.md
│   ├── orders.md         # type: Table
│   └── customers.md      # type: Table
└── metrics/
    ├── index.md
    └── weekly_active_users.md  # type: Metric

tables/orders.md の例です。

---
type: Table
title: Orders
description: 1注文1行。確定済み注文のみ。
tags: [sales, revenue]
timestamp: 2026-06-15T09:00:00Z
---

# Schema
| Column | Type | Description |
|--------|------|-------------|
| `order_id` | STRING | 注文ID（グローバル一意） |
| `customer_id` | STRING | [customers](./customers.md) へのFK |

# Joins
`customer_id` で [customers](./customers.md) と結合。

※ リンクは後述の理由で、最初は SPEC 推奨の絶対パス（/tables/customers.md）で書いていました。

簡易チェックの結果、Concept 3 件すべてが OKF v0.1 準拠でした。

Concept総数: 3
✅ 準拠: 3/3

やってみた: ビジュアライザーでグラフ表示

同梱の enrichment_agent には、OKF バンドルを単一 HTML に変換するビジュアライザーがあります。バックエンド不要・インストール不要・データはページ外に出ない、という設計です。

環境セットアップ

cd knowledge-catalog/okf
python3.13 -m venv .venv
.venv/bin/pip install --index-url https://pypi.org/simple/ -e .[dev]

README は Python 3.13 を前提に書かれていますが、pyproject.toml の制約次第では 3.12 でも動く可能性があります（要確認）。

visualize コマンド

まず公式サンプル（GA4）で動作確認しました。

.venv/bin/python -m enrichment_agent visualize \
    --bundle ./bundles/ga4 \
    --out /tmp/okf_ga4.html \
    --name "GA4 OKF Bundle"

Wrote 11 concept(s), 9 edge(s), 50536 bytes → /tmp/okf_ga4.html

続いて手書きバンドルを可視化しました。

.venv/bin/python -m enrichment_agent visualize \
    --bundle ./mybundle \
    --out /tmp/okf_mybundle.html \
    --name "My First OKF Bundle"

落とし穴: SPEC 推奨の絶対パスリンクが visualizer で無視される

ここが今回のハンズオンで一番「えっ」と思ったところです。

初回の結果はこうでした。

Wrote 3 concept(s), 0 edge(s), 17005 bytes → /tmp/okf_mybundle.html

Concept は 3 つあるのに edge が 0。グラフとしてはノードだけ並んでいる状態です。

SPEC §5.1 では / 始まりの絶対パス（例: /tables/customers.md）を推奨しています。ファイル移動に強い、という理由です。私も SPEC に従って絶対パスで書いていたので、エッジが出る、はずでした。

色々調べたところ、リファレンス実装の viewer/generator.py では次のように 絶対パスを明示的にスキップ していました。

# src/enrichment_agent/viewer/generator.py
if "://" in target or target.startswith("/"):
    continue

外部 URL と / 始まりのリンクは edge 生成対象外、という実装です。v0.1 ドラフト段階のギャップだと思いますが、ちょっと気持ち悪いですね。

リンクを相対パス（./customers.md, ../tables/orders.md）に修正したところ、正常にエッジが生成されました。

Wrote 3 concept(s), 5 edge(s), 17615 bytes → /tmp/okf_mybundle.html

グラフの関係は次のとおりです。

• tables/orders ←→ tables/customers（相互リンク）
• metrics/weekly_active_users → tables/orders
• metrics/weekly_active_users → tables/customers

現時点の実務的な注意: ビジュアライザー v0.1 を使うなら、リンクは相対パスで書く。SPEC 推奨の絶対パスは、将来のコンシューマー実装を見据えて書いておき、visualizer 利用時だけ相対パスに寄せる、という割り切りもありそうです。

Obsidian Vault を OKF 準拠チェックしてみた

OKF はデータカタログ向けの例が多いですが、フォーマット自体はベンダー中立です。普段使っている Obsidian Vault が、どれくらい OKF に近いか試してみました。

Vault の 10_DailyNotes/, 20_Projects/, 30_Knowledge/ 配下 812 件の .md を検査しました（OKF v0.1 準拠 = YAML フロントマター + 非空の type フィールド）。

総.mdファイル数: 812
✅ OKF準拠（frontmatter + type あり）: 206件 (25.4%)
⚠️  frontmatterなし: 487件 (60.0%)
⚠️  typeフィールドなし（frontmatterはある）: 119件 (14.7%)
📝 OKF準拠にするには type を追加するだけ: 606件

25.4% は既に OKF v0.1 準拠 でした。意図せず準拠していた、という感じです。

既存の type フィールド値（上位）は次のとおりです。

55件  memo
25件  knowledge
19件  meeting
12件  project
11件  progress
10件  draft
 8件  output
 7件  design / skill
 6件  reference

Obsidian で運用している type 値（memo, knowledge, meeting 等）が、そのまま OKF の type 値として機能します。中央レジストリがない、という SPEC の設計と相性がよいです。

残り 606 件は type を追加するだけで準拠可能です。フロントマターのない 487 件（デイリーノート等）は type: daily-note を足す、というイメージです。大規模 Vault でも、必須は type だけ なので、段階的に寄せていくのは現実的だと感じました。

AWS エンジニア視点での使いどころ

OKF のリファレンス実装は BigQuery + Gemini ですが、フォーマット自体は GCP に依存しません。

AWS 文脈で考えると、例えば次のような接続が想像できます（妄想レベル、要確認）。

• Amazon Bedrock Knowledge Base に載せる前段で、S3 上のドキュメントを OKF バンドルとして整理する
• AWS Glue Data Catalog や Amazon DataZone から OKF 形式にエクスポートするスクリプトを書く
• 既存の AGENTS.md 運用に、OKF バンドルを type 付き Markdown ツリーとして追加する

同梱の enrichment_agent（BigQuery を走査して OKF コンセプトを自動生成する）は GCP アカウントと Gemini API が必要です。AWS 中心の環境では読み飛ばして問題ありません。フォーマットを理解するだけなら、手書きバンドル + ビジュアライザーで十分です。

まとめ

Google OKF v0.1 を触ってみて感じたのは、次の3点です。

1. 必須は type だけ — 既存の Markdown + フロントマター運用に、type を足すだけでかなり近づける
2. MCP とは補完関係 — 静的ナレッジのフォーマットと、動的ツール接続は役割が違う
3. v0.1 はスタート地点 — visualizer と SPEC の絶対パス推奨のズレなど、実装はこれから追いつく余地がある

チームによっては、すでに Obsidian や CLAUDE.md で LLM-wiki パターンを実践しているはずです。OKF はその慣習に名前と最低限のルールを付けた、と捉えると入りやすいです。

v0.1 はドラフトです。仕様へのフィードバックは GitHub リポジトリ経由で歓迎されている、とのことです。もっとスマートな OKF 運用を御存知の方がいれば、ぜひツイッターででも教えて下さい。

参考資料

一次情報

• Google Cloud Blog: How the Open Knowledge Format can improve data sharing
• GitHub: GoogleCloudPlatform/knowledge-catalog/okf
• SPEC.md（OKF v0.1 Draft）

二次情報（解説記事）

• Impress Watch（日本語ニュース）
• Search Engine Journal