← 一覧へ戻る

AI / ナレッジフォーマット

Open Knowledge Formatとは何か

作成日: 2026年6月15日

要点

  • Open Knowledge Format（OKF）は、Google Cloud が2026年6月12日に公開したオープン仕様（現行 Version 0.1 Draft）です。
  • AI エージェントが読み書きする「ナレッジ」を、人間にもエージェントにも扱いやすい形で表現することを目的とします。
  • 実体は「YAML frontmatter 付き Markdown ファイルのディレクトリ」だけで、スキーマレジストリも中央管理機関も必須のSDKもありません。cat で読めて、git clone で配れます。
  • Andrej Karpathy が提唱した「LLM-wiki」パターンを、ベンダーニュートラルでポータブルな標準へ形式化したものです。

何を解決するフォーマットか

AI エージェント向けのナレッジ表現は急速に進化しており、互換性のない慣習が多数生まれています。OKF は、ナレッジを「よく使われる既存の形式」で表現するのが最適だという立場をとります。人間がツールなしで読め、エージェントが専用SDKなしで解析できることを前提にしています。

背景にあるのは、Andrej Karpathy が提唱した LLM-wiki パターン、つまり Markdown と frontmatter を使ってエージェントが読めるナレッジベースを作る手法です。この手法は広く使われ始めているものの、各現場で独自ルールが乱立しがちでした。OKF は小さなルールの集合だけを固定し、ツールを強要せずに相互運用性を確保することを目指しています。

位置づけは「仕様化された（specified）フォーマット」です。Obsidian や Notion のような個人ナレッジツールも同じ Markdown + frontmatter の系譜ですが、OKF は相互運用に必要な最小限の規則を明文化した点が異なります。

Authoring 人間が書く エージェントが生成 Exchange OKF bundle 組織をまたぐ受け渡し Consumption エージェントが読む 人間も読む Markdown + YAML frontmatter で一貫
ナレッジは人間かエージェントが書き、bundle として交換され、人間とエージェントの両方が読みます。形式が共通なので、どの経路でも同じ文件がそのまま通ります。

フォーマットの実体

OKF は意図的に最小です。対象は「YAML frontmatter 付き Markdown ファイルのディレクトリ」のみです。スキーマレジストリ、中央管理機関、必須ツールは一切ありません。

仕様書は、この簡潔さを次のように表現しています。

If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it.
（cat で読めて、git clone で配れる）

つまり、特別なランタイムやパーサーを用意しなくても、標準的なファイル操作と Markdown の知識だけで作成・配布・閲覧が完結します。これが「ベンダーニュートラル」を実現する根幹です。

読める

人間がエディタや cat でそのまま読めます。専用アプリが不要です。

解析できる

エージェントが専用 SDK なしで frontmatter を解析し、走査できます。

配れる

ディレクトリごと git clone すれば、そのまま受け渡せます。

概念（concept）の構造

OKF では、1つの Markdown ファイルが1つの概念（concept）を表します。概念は、テーブルや API のような実体のある資産を記述することもあれば、メトリクスや業務プロセス、プレイブックのような抽象的な事柄を記述することもあります。ファイルは UTF-8 の Markdown で、次の2つの部分から成ります。

  • Frontmatter: ファイル先頭の --- で区切られた YAML メタデータブロック。
  • Body: frontmatter 以降の、自由形式の Markdown 本文。

frontmatter の必須フィールドは type のみです。推奨フィールドと、拡張（追加キーは自由、消費側は未知のキーを寛容に扱う）の規則は以下の通りです。 

---
type: <Type name>                  # 必須
title: <Optional display name>
description: <Optional one-line summary>
resource: <Optional canonical URI for the underlying asset>
tags: [<tag>, <tag>, …]            # 任意
timestamp: <ISO 8601 datetime>     # 任意の最終更新時刻
# … 生産者が自由に定義したキー/値
---
必須は type のみ。type 値は中央登録されず、消費側は未知の type を寛容に扱います（例: BigQuery Table, API Endpoint, Metric, Playbook）。

本文は標準的な Markdown です。見出し・リスト・表・コードブロックのような「構造的な Markdown」が推奨されます。構造がある方が、人間の阅读にもエージェントの検索にも都合が良いためです。# Schema、# Examples、# Citations などの見出しには慣習的な意味が与えられています。 

---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---
# Schema
| Column        | Type      | Description                         |
|---------------|-----------|-------------------------------------|
| `order_id`    | STRING    | Globally unique order identifier.   |
| `customer_id` | STRING    | FK into [customers](/tables/customers.md). |

# Citations
[1] [BigQuery table schema](https://console.cloud.google.com/...)
実体のある資源（テーブル）を記述する概念の例。resource に正規の URI を持ち、本文でスキーマと引用を構造的に示します。 
---
type: Playbook
title: Incident response — data freshness alert
description: Steps to triage a freshness alert on the orders pipeline.
tags: [oncall, incident]
---
# Trigger
A freshness alert fires when `orders` lags more than 30 minutes.
See the [orders table](/tables/orders.md).

# Steps
1. Check the [ingestion job dashboard](https://example.com/dash).
2. …
実体を持たない抽象概念（プレイブック）の例。resource は省略し、本文で手順を構造的に記述します。

バンドル・index.md・段階的開示

ファイル群のまとまりをバンドル（bundle）と呼びます。バンドルは Markdown ファイルのディレクトリツリーで、ディレクトリ構造はドメインに依存しません。生産側は、対象のナレッジに合うように自由に概念を整理します。

どのディレクトリにも（バンドルのルートを含む）index.md を置けます。これは段階的開示（progressive disclosure）を支える仕組みで、個別の文件を開く前に「そのディレクトリに何があるか」を人間やエージェントに示します。index.md 自体は frontmatter を持たず、本文で概念をグループ化して列挙します。生産側が自動生成してもよいですし、存在しない場合は消費側がその場で合成しても構いません。

bundle/ ├ index.md (root) ├ tables/ │ ├ index.md │ ├ orders.md │ └ customers.md └ playbooks/ └ freshness.md index.md 一覧を提示 何があるか先に見せる （progressive disclosure） frontmatter なし 個別の概念 orders.md customers.md 必要なものだけ開く
index.md がディレクトリの中身を一覧示し、エージェントや人が個別文件を開く前に全体を把握できるようにします。これが段階的開示です。

リンクと相互運用性

概念同士は標準の Markdown リンクで結びます。2つの形式がサポートされており、/ 始まりの絶対（バンドル相対）リンクが推奨です。文件をディレクトリ内で移動してもリンクが壊れにくいためです。通常の相対パスも使えます。

OKF は、既存のナレッジ表現と明確に住み分けています。同じ Markdown + frontmatter の系譜でありながら「仕様化されている」ことが差です。

野良 LLM-wiki

Markdown + frontmatter の慣習は普及中だが、現場ごとに互換性がない。

Obsidian / Notion

階層 Markdown と相互リンクの個人ツールだが、交換向けの固定規則はない。

OKF

同じ系譜でありつつ、相互運用に必要な最小の規則を仕様として明文化。

どういう場面で有効か

  • 組織をまたいでナレッジを交換し、複数の異なるエージェント/プラットフォームで同じナレッジを読ませたいとき。
  • データ資産（テーブル、データセット、API）周辺のメタデータ・文脈・キュレーションされた知見を、人間とエージェントの両方で共有したいとき。
  • エージェントが自ら生成・追記できるナレッジベースを、SDK や専属ツールに縛られず運用したいとき。
  • 引用（Citations）を含め、主張の出どころを辿れる形で知識を蓄積したいとき。

注意点

  • 現行は Version 0.1 Draftであり、仕様は今後変わりうる Draft 段階です。
  • Google Cloud が発表したものの、フォーマット自体はクラウド非依存のベンダーニュートラルな仕様です。発表文脈はデータ共有と BigQuery 周りですが、Google Cloud 固有ではありません。
  • type 値は中央登録されません。生産側は分かりやすい値を選び、消費側は未知の type を一般的な概念として扱います。
  • バンドルは対象とする OKF バージョンを、ルートの index.md の frontmatter に okf_version: "0.1" として宣言できます。未対応のバージョンでも、消費側はベストエフォートで読むことが推奨されます。

まとめ

Open Knowledge Format は、AI エージェント時代のナレッジを「Markdown + YAML frontmatter のディレクトリ」という極めて平易な形で標準化する試みです。cat で読めて git clone で配れる簡潔さと、最小限の規則による相互運用性を両立します。LLM-wiki パターンを仕様化した点が核心で、特定ベンダーやツールに縛られず、人間とエージェントの双方が作り・交換し・読める知識の共通言語となることを目指しています。

参考URL