Open Knowledge Format（OKF）は本当に必要か？CLAUDE.mdとの違いから考える

コードを読まないAIエンジニア

2026/06/19

こんにちは。もるふぉです。

2026年6月12日、Google CloudがOpen Knowledge Format（OKF）v0.1を公開しました。

「またひとつAIエージェント向けの仕様が増えたか」というのが正直な第一印象でした。

MCPがあり、llms.txtがあり、AGENTS.mdやCLAUDE.mdまである中で、これ以上何を統一したいのか。

SPEC.mdを読み、最小バンドルを手で書いて検証してみたところ、OKFの立ち位置はかなり明確でした。

同時に、v0.1の段階で本番投入するのは早すぎるという結論にも至っています。

この記事では、OKFの正体・既存仕様との役割分担・採用判断の基準を、賛美抜きで整理します。

Open Knowledge Format（OKF）とは何か、一言で言うと

OKFは「YAMLフロントマター付きMarkdownファイルを置いたディレクトリ」を、AIエージェント向け知識バンドルの最小フォーマットとして標準化する仕様です。

それ以上でも以下でもありません。

公開元はGoogle Cloud、リポジトリはGoogleCloudPlatform/knowledge-catalogのokf/配下にSPEC.mdが約450行で置かれています。

v0.1はドラフト扱いで、現時点では「これから議論する叩き台」というステータスです。

YAMLフロントマター付きMarkdownの「ディレクトリ」が全て

OKFバンドルの実体は、ただのGitリポジトリかディレクトリです。

各.mdファイルが1つのコンセプトを表し、ファイルパス自体が識別子になります。

/tables/customers.mdならパスがそのままIDです。

コンセプト同士はMarkdownのリンク記法で相互参照します。

特別なランタイムもサーバーも要りません。

git cloneして、好きなツールで読めばそれで終わりです。

スキーマレジストリも中央機関も置かない設計で、llms.txt以来の「軽さ重視」の流れを汲んでいます。

必須フィールドは`type`のみ──この一点から設計思想が読める

フロントマターで必須なのはtypeだけです。

title・description・resource・tags・timestampは推奨ですが、義務ではありません。

typeの値さえ自由に決められます。

BigQuery TableでもAPI EndpointでもPlaybookでも好きにつけてよく、消費者側（エージェント）は知らないtypeが来ても落ちずに処理する責務を負います。

この「必須はtypeだけ」という設計が腹落ちすると、既存Markdownにフィールドを1個足すだけで動き出せる、という現実が見えてきます。

ここに「プロデューサーとコンシューマーを独立させる」「フォーマットであってプラットフォームではない」というv0.1の思想がそのまま出ています。

標準化を最小に抑え、運用の自由度を最大化する選択です。

この最小仕様が、既存フォーマットとどこで役割が分かれるのかを次に整理します。

OKF・CLAUDE.md・MCP・llms.txtの役割分担を整理する

「OKFはMCPと何が違うのか」「llms.txtで十分では？」という疑問は当然出ます。

競合ではなく、それぞれが担う層が違います。

各フォーマットが担う「層」の違い

整理するとこうなります。

フォーマット

担う層

形式

MCP

エージェントが外部ツール・データを動的に呼ぶ実行層

プロトコル（JSON-RPC）

llms.txt

サイト全体の知識リソースへのポインタ案内層

1枚のテキストファイル

AGENTS.md / CLAUDE.md

リポジトリ固有のエージェント行動規範層

1枚のMarkdown

OKF

「知識そのもの」を持ち運び可能な形で記述する層

YAML付きMarkdownのディレクトリ

この表を見ると、4つがそれぞれ食い合わずに棲み分けているのがわかります。

MCPは「動詞」の標準化、OKFは「名詞」の標準化、と言うとイメージしやすいかもしれません。

MCPがツール呼び出しの仕様であるのに対し、OKFはツールを呼んだ先にある「テーブル定義」「APIの意味」「業務ルール」自体をどう書くかの仕様です。

CLAUDE.mdやAGENTS.mdとの具体的な差分

Claude Codeを日常的に使っている方には、ここが一番気になる論点だと思います。

CLAUDE.mdは「このリポジトリでClaude Codeにどう振る舞ってほしいか」を書く慣習ファイルで、行動規範や開発ガイドラインを1ファイルにまとめるスタイルです。

対してOKFは、知識を複数ファイルに分解し、type付きで構造化します。

CLAUDE.mdが「うちのチームの暗黙知をAI向けに明文化したもの」なら、OKFは「その知識を他チーム・他エージェントに渡せる形に正規化したもの」と捉えると差が見えます。

両者は共存できます。

リポジトリ内の運用ガイドはCLAUDE.mdに残し、外に出していい知識資産だけをOKFバンドルに切り出す、という分け方が現実的です。

ただし「切り出す価値があるか」の判断は、次のセクションが評価の分かれ目です。

「Markdownでいいのでは？」という疑問に正直に答える

ここがOKF評価で一番ごまかしてはいけない論点です。

「type付けるだけなら自分で運用ルール決めれば済む話では？」という疑問には、私も否定しきれない部分があります。

単独チームならYesかもしれない

自社内で1チームが運用するだけなら、命名規則を決めたMarkdownリポジトリで十分動きます。

私が関わっている案件の多くは、CLAUDE.mdとMarkdownメモの組み合わせで現状回っています。

typeをフロントマターに足したところで、ツール側が読んでくれなければ何も変わりません。

OKFが効くのは「自分たちが作った知識を、自分たちが書いていないエージェントが読む」局面です。

知識を「他エージェントに渡す」時に差が出る理由

OKFの本質的な価値は、消費者側（エージェント側）に「未知のtypeも処理する」という規約を課している点にあります。

プロデューサーがtype: Playbookと書けば、その意味を知らないエージェントも汎用コンセプトとして扱える。

ここに、独自Markdownでは出せない移植性があります。

別の言い方をすると、OKFは「ナレッジのCSVみたいなもの」です。

CSVの中身が何を意味するかはアプリ次第ですが、カンマ区切りで読める保証だけは共有されている。

OKFも同じ立て付けで、最小規約だけを共有し、中身の意味づけは各プレイヤーに委ねています。

社内ナレッジを将来別のエージェントやベンダーに渡す可能性があるなら、最初からOKF準拠で書く価値はあります。

その予定がないなら、Markdownのままで十分です。

OKF v0.1バンドルの最小構成を手で書いてみた

文章だけだと掴みにくいので、最小バンドルを手で書いてみました。

SPEC.mdに従えば、これだけで「OKF準拠バンドル」を名乗れます。

ディレクトリ構造と最小ファイル例

my-knowledge/
├── index.md
├── log.md
└── tables/
    └── customers.md

コンセプトファイルtables/customers.mdはこんな形です。

---
type: BigQuery Table
title: Customers
description: 全チャネルの顧客マスタ。1行=1顧客
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=customers
tags: [sales, customers]
timestamp: 2026-06-12T09:00:00Z
---

# Customers

顧客マスタテーブル。注文情報は [orders](./orders.md) を参照。

フロントマターはtypeだけ書けば仕様としては合格です。

title以降はあくまで推奨で、運用上の親切さの問題です。

既存のMarkdownメモがあるなら、フロントマターを1行足すだけで今日から試せます。