OKF：Google発エージェント向けMarkdown仕様

2026年6月12日、Google CloudはAIエージェントがキュレーションされた知識をどう読み書きし、交換すべきかについての仕様を公開しました。グラフデータベース、スキーマレジストリ、SDK、それを動かすサービス——そんなものを想像するかもしれません。

実際のOpen Knowledge Formatはこうです。YAMLフロントマター付きのMarkdownファイルが並んだディレクトリ。

それがフォーマットのすべてです。そしてこの抑制こそが面白いところです。

仕様は見た目より小さい

OKFについて書かれた文章の多くは、発表内容をなぞっただけです。仕様そのものを読む価値があります。カバーする範囲が驚くほど小さいからです。

OKF v0.1がすべてのコンセプト文書に要求するのはたった1つのフィールドです。

---
type: BigQuery Table
---

これだけです。typeはその文書がどんな種類のコンセプトを説明しているかを示す短い文字列で、ルーティングとフィルタリングに使われます。値は中央で登録されているわけではありません——有効な型のリストを承認する委員会は存在しません。生成する側が自明な名称を選んで先に進むだけです。

さらに5つのフィールドが推奨されていますが、必須ではありません。

フィールド	用途
title	表示名。無ければ消費側がファイル名から導出してもよい。
description	一文の要約。
resource	元となるアセットを一意に識別するURI。
tags	横断的な分類のためのYAMLリスト。
timestamp	最終更新のISO 8601形式の日時。

生成する側は好きなカスタムキーを追加してよく、消費する側は未知のフィールドを拒否せず保持しなければなりません。

完全で準拠したコンセプト文書は次のようになります。

---
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, orders]
timestamp: 2026-05-28T00:00:00Z
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| order_id | STRING | Unique identifier |

Obsidianでフロントマター付きのノートを書いたことがあるなら、すでに有効なOKFコンセプトにかなり近いものを書いたことになります。

グラフデータベースなしのナレッジグラフ

OKFを採用するかどうかに関わらず、盗む価値のある設計判断がここにあります。

コンセプト同士の関係は標準のMarkdownリンクとして表現されます。データベースのエッジではありません。フロントマターのrelationships:ブロックでもありません。ただのリンクです。

Each order references a [customer](/tables/customers.md).

安定性のためバンドル相対の絶対パス（/始まり）が推奨されますが、./other.mdのような通常の相対パスも機能します。

そして、これを機能させているのが肝心な部分です。関係の種類はリンクそのものではなく、周囲の文章が運んでいます。「Each order references a customer」というプローズ自体がエッジのラベルなのです。維持すべきオントロジーも、合意すべき述語の語彙もありません。なぜなら自然言語がすでにそれを持っていて、消費する側は言語モデルだからです。

10年にわたるナレッジグラフのツール開発は、機械が解釈できるよう関係の種類を形式化することに費やされてきました。OKFの賭けは、それがもう必要ないということです——機械はもう英語を読めるのですから。

予約された2つのファイル名

バンドル内で特別な意味を持つファイル名は2つだけです。

• index.md — 段階的開示を可能にするディレクトリ一覧。フロントマターは持ちません。エージェントはまずindexを読み、必要なリンクだけをたどります。すべてのコンセプトをコンテキストに読み込むのではなく。
• log.md — ISO 8601形式の日付見出しを使った、新しい順の更新履歴。

それ以外のすべての.mdファイルはコンセプト文書です。バンドルは結局のところ、ごく普通の閲覧可能なフォルダのように見えます。

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

index.mdは静かに重要な存在です。よく書かれたCLAUDE.mdの背後にあるのと同じ発想です。ライブラリ丸ごとをコンテキストウィンドウに投げ込むのではなく、目次を渡してエージェントに取りに行かせる。

OKFではないもの

RAGではありません。 RAGはクエリのたびに生のチャンクを検索し、関連するものが浮かび上がることを期待して知識を再導出します。OKFバンドルはキュレーションされ、相互リンクされたコンセプトを保存し、エージェントはそれを直接読み書きします。キュレーションはクエリのたびに近似されるのではなく、一度だけ意図的に行われます。

AGENTS.mdやCLAUDE.mdでもありません。 それらは指示ファイルです——リポジトリでエージェントがどう振る舞うべきかを伝えます。OKFが記述するのはその分野の知識です。このテーブルは何を意味するのか、このメトリクスはどう定義されているのか、なぜこのデータセットは3月に欠損があるのか。役割は違いますが補完的です。

MCPでもありません。 MCPはエージェントをライブシステムに接続するためのランタイムプロトコルです。OKFはディスク上に静止しているファイルフォーマットです。両方を使うのは十分にあり得ます。ウェアハウスに到達するのはMCP、中身を説明するのはOKF。

準拠ルールは意図的に寛容

バンドルがOKF v0.1に準拠するのは、予約されていないすべての.mdファイルがパース可能なYAMLフロントマターを持ち、すべてのフロントマターブロックが空でないtypeを持ち、予約ファイルが存在する場合はその構造に従っている場合です。

さらに示唆的なのは、消費する側に禁止されていることです。消費する側は、オプションフィールドの欠落、未知のtype値、未知のキー、壊れた相互リンク、index.mdの欠如を理由にバンドルを拒否してはなりません。

これは、バンドルが半端に完成していて、部分的に機械生成されていて、常に変動していることを前提に設計されたフォーマットです——実際のナレッジベースは実際そういうものです。厳格なフォーマットは自らの厳格さで死にます。これはぐちゃぐちゃなフォルダとの接触を生き延びるように作られています。

Googleはリファレンスツールも同時に公開しました。BigQuery拡充エージェント、静的HTMLビジュアライザー、3つのサンプルバンドルです。

はっきり述べておくべき注意点が一つ。 OKFはv0.1で、明示的にドラフトです。仕様はバージョン管理されていて後方互換の成長を前提に設計されていますが、フィールド名や規約はまだ変わり得ます。今日これを軸にナレッジベースを作り直す必要はありません。ただ、標準がどちらに向かっているかは押さえておいてください。

Google Cloudを超えて重要な理由

BigQueryの例を取り除くと、OKFはもっと射程の広い賭けです。機械可読な知識の恒久的なフォーマットは、自分が所有するフォルダの中の、ただのMarkdownファイルである、という賭けです。

APIつきの独自カタログではありません。読めないベクトルストアの中の埋め込みでもありません。テーブルを崩壊させるエクスポートボタン付きのwikiでもありません。ファイルです。ディスク上の。差分が取れて、grepできて、ベンダー間を移動でき、人間にも市場のあらゆるモデルにも読める。

これはClaude Code、Cursor、Copilot、Windsurfが指示フォーマットとしてMarkdownを選んだときに、それぞれ独立にたどり着いたのと同じ結論です。Google Cloudがそれを仕様として書き下ろしたのは、発明ではなく確認です。

Minibaseの居場所

Minibase Vaultを運用しているなら、すでに構造的にOKFバンドルに近いものを維持しています。フロントマター付きのMarkdownファイルのフォルダが、自分のディスク上にあり、ClaudeやChatGPTに読まれている、というものです。

正式に準拠させるのはちょっとした編集で済みます。フロントマターにtypeを追加し、あとはリンクに任せるだけです。

---
type: Article
title: How the Open Knowledge Format can improve data sharing
resource: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing/
tags: [okf, agents, markdown]
timestamp: 2026-07-19T00:00:00Z
---

これがこの発表の実践的な形です。エージェント向けナレッジベースの難しい部分は、これまでもファイルフォーマットではありませんでした——良い素材をそこに入れることが難しかったのです。仕様はフォルダの形を教えてくれます。中身を埋めてはくれません。

Minibaseは中身を埋める部分です。ドキュメント、GitHubのREADME、仕様書、スレッド、論文——どんなウェブページも、ワンクリックでクリーンなMarkdownに変わり、あなたのフォルダに収まり、次に動かすエージェントを待ちます。

フォーマットはもう標準になりました。そこに何を入れるかは、まだあなたの優位性です。

---

Minibaseはどんなウェブページもエージェントが読めるクリーンなMarkdownに変える——拡張機能をインストールして、あなたのエージェントを賢くするバンドルを作り始めよう。