Open Knowledge Format (OKF) 入門

2026年7月31日

🐧 要するにどういう話か

LLMに知識を扱わせるとき、RAGだと効率が悪いので、wikiを回したほうが実用的だろうとKarpathy氏が「LLM Wiki」として提案したが、そのアイデアが公式化されたものがOKFである。OKFでは、index.mdでディレクトリや文書のリストを用意しつつ、コンテンツ自体はMarkdownにメタデータとしてYAMLフロントマターを付与したものを考えることで、LLMが極力コンテンツを読み込まないで済む段階的開示の方式が取られている。知識マネジメント全体としては、OKFにもとづいた文書の他に、もとになる資料、それをもとにした文書の生産者（人、AIエージェント、ツール）、それを利用する消費者（人、AIエージェント、ツール）から構成される。

はじめに

AIエージェントが組織の知識を活用する際、最大の障壁は「知識がどこにあるか分からない」ことです。テーブルのスキーマ、指標の定義、インシデントの対応手順、APIの仕様——これらの知識要素は、メタデータカタログ、wiki、共有ドライブ、コードコメント、さらにはシニアエンジニアの頭の中に散在しています。

本記事では、この断片化された知識統合の問題を解決するひとつの手段として、Andrej Karpathy氏によるLLM Wikiパターン、およびそれを公式化したオープン仕様 Open Knowledge Format (OKF) について紹介します。

第1章: LLM Wikiパターンの登場

LLM Wikiパターン

AI研究者のAndrej Karpathy氏が提唱した LLM Wikiパターン（日本語訳） は、個人知識ベースの構築方法に新たなパラダイムを示しました。

従来のRAG（Retrieval-Augmented Generation）アプローチでは、ファイルをアップロードするとLLMが関連するチャンクを検索して回答を生成しますが、これは「毎回知識をゼロから再発見」する方式です。質問のたびに文書を探し、断片を組み立てる——何も積み上がっていきません。

LLM Wikiパターンの核心は、LLMに永続的なwikiの維持を任せ、人間はキュレーションと問いかけに集中するという発想です。

人間がwikiを直接書くのではなく、LLMが読み、要約し、クロス参照を更新し、矛盾のフラグを立て——知識は複利的（compounding）に積み上がっていきます。新しいソースを追加するたびに、wikiはより有用になり、クロス参照はすでに存在し、矛盾はすでに検出され、合成はすでにすべての情報を反映しています。

このパターンは以下の3層アーキテクチャで構成されます：

1. Raw Sources（生データ） 不変の一次情報。記事、論文、画像、データファイル。LLMはこれを読み、決して変更しません。

2. Wiki LLMが生成・維持するマークダウンファイルのディレクトリ。要約、エンティティページ、概念ページ、比較、統合——LLMがこの層を完全に所有し、新しいソースが届くたびにページを作成し、更新し、クロス参照を維持します。

3. Schema（設計図） wikiがどのように構造化されるか、どのような規約に従うか、ソース取り込み時にどのようなワークフローを踏むかをLLMに指示する設定ファイル（例: CLAUDE.md、AGENTS.md）。

この3層において、人間が担当するのは「ソースのキュレーション」「探索の方向性」「適切な問いかけ」です。LLMが担当するのは「要約」「クロス参照の更新」「ファイルの整理」「保守作業（bookkeeping）」——つまりwikiを有用なものにするための退屈な作業のすべてです。

LLM Wikiパターンには3つの操作があります：

• Ingest（取り込み） 新しいソースを投入し、LLMが読み、要約ページを作成し、インデックスを更新し、関連エンティティページを更新し、ログにエントリを追加
• Query（照会） wikiに対して質問し、LLMが関連ページを検索し、読み、引用付きで回答を合成。良い回答はwikiにファイルとして蓄積される
• Lint（健康診断） 定期的にLLMにwikiの健康診断を依頼。矛盾の検出、古くなった主張の特定、孤立したページ、不足するクロス参照の発見

また、wikiのナビゲーションには2つの特殊ファイルが活用されます：

• index.md — コンテンツ指向のカタログ。各ページのリンク、要約、メタデータをカテゴリ別に整理。LLMは取り込みのたびに更新する。
• log.md — 時系列指向の変更履歴。YYYY-MM-DD形式のヘッダーで、取り込み、照会、健康診断の実行記録を時系列的に追跡。

wikiはgitリポジトリであり、バージョン管理、分岐、コラボレーションが無料で利用できます。

組織における知識の断片化問題

個人レベルでのLLM Wikiパターンの魅力は、組織における知識の断片化という深刻な問題と対比するとより明確になります。

ほとんどの組織において、基盤モデルが使用する情報は圧倒的に内部知識です：

• テーブルのスキーマ
• ビジネスにおける指標の定義
• インシデント対応手順書
• システム間の結合パス
• 古いAPIの非推奨通知

しかし、これらの知識は今日、断片化された様々なシステムに散在しています：

AIエージェントが「イベントストリームから週次アクティブユーザーをどのように計算するか？」という問いに答える際、これらの散在した互換性のないインターフェイスから答えを組み合わせなければなりません。あらゆるベンダーが独自のカタログ、SDK、知識グラフスキーマを提供していますが、いずれの知識も製品や組織間で容易に持ち運べるものではありません。

結果として：

• すべてのエージェントビルダーが同じ文脈統合問題をゼロから解決
• すべてのカタログベンダーが同じデータモデルを再生産
• 知識自体がそれが作成されたインターフェイスにロックされている

各ドキュメントが持つべきフィールドは何なのか、ファイル名が何を意味するのか——合意された答えはありません。その結果、wikiにエンコードされた知識は元のチーム内に閉じ込められ、新しいエージェントが構築されるたびに同じような努力が生じます。

第2章: OKFの登場

OKFとは何か

この問題に対する答えは、新たな知識サービスではありません。必要なのはフォーマットです。

Open Knowledge Format (OKF) は、LLM Wikiパターンをポータブルで相互運用可能な形式に公式化したオープン仕様です。現代のAIシステムが必要とするメタデータ、文脈、キュレーションされた知識を表現するための、ベンダーに依存しないエージェント・人間双方に優しい標準規格です。

2026年6月、Google CloudはOKF v0.1を発表しました。その後、OKF v0.2で仕様が強化され、信頼性・起源・ライフサイクルを第一級の概念として取り込みました。

OKFは、YAMLフロントマター付きのマークダウンファイルのディレクトリとして知識を表現します。重要な点は、OKFが「サービス」ではなく「フォーマット」であることです：

• ただのマークダウン 任意のエディタで読み取り可能、GitHubでレンダリング可能、任意の検索ツールでインデックス可能
• ただのファイル tarballとして配布可能、任意のgitリポジトリでホスト可能、任意のファイルシステムにマウント可能
• ただのYAMLフロントマター クエリ可能な構造化フィールド: type, title, description, resource, tags, timestamp

Obsidian、Notion、あるいは過去1年間で登場した任意のLLM Wikiパターンを使用したことがあるなら、OKFの形状は馴染み深く感じられるでしょう。OKFは、これらのパターンを相互運用可能にするために必要な小さな規約のセットを公式化したものです。

OKFバンドルの構造

OKFバンドルは、概念を表すマークダウンファイルのディレクトリです。概念とは、キャプチャしたいあらゆるもの：テーブル、データセット、指標、プレイブック、APIなどです。各概念は1つのファイルです。ファイルパスが概念のアイデンティティです。

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

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

概念は通常のマークダウンリンクで互いにリンクし、ディレクトリをファイルシステムが示す親/子リンクよりも豊かな関係のグラフに変えます。

また、各ディレクトリには index.md を配置して、そのディレクトリ内のファイル一覧をカテゴリ別にカタログ化します：

# Datasets

* [orders_db](datasets/orders_db.md) - Main sales orders database

# Tables

* [orders](tables/orders.md) - One row per completed customer order
* [customers](tables/customers.md) - Customer reference data

# Metrics

* [weekly_active_users](metrics/weekly_active_users.md) - Weekly active user count

各項目には概念の description から取った短い説明文が付き、人間やエージェントがディレクトリの内容を把握してから個別のドキュメントを開く段階的開示（progressive disclosure）をサポートします。

フロントマターフィールド一覧

OKFの概念ドキュメントは、YAMLフロントマターによって構造化されたメタデータを持ちます。フィールドは必須と推奨に分類されます。

必須フィールド

typeは唯一の必須フィールドで、typeさえ持てばOKFに完全に準拠したことになります。例として BigQuery Table, Metric, Playbook, API Endpoint など。

推奨フィールド

その他のフィールド（OKF v0.2で追加）

OKF v0.2では、信頼性・起源・ライフサイクルを第一級の概念として取り込みました。これらはすべてオプションです：

詳細なフィールドやアクター形式、信頼ティアについては仕様書（SPEC.md）を参照してください。

第3章: OKFの設計思想

OKFの3つの設計原則

OKFは、以下の3つの設計原則に基づいて構築されています。

1. Minimally opinionated（最小限の意見）

OKFは概念に対してちょうど1つのこと、すなわち typeフィールドのみを要求します。それ以外——どのような型が存在するか、他のどのフィールドを含めるか、本体にどのセクションがあるか——は生産者に委ねられます。

仕様は相互運用性を示すインターフェースを定義するのであり、コンテンツモデルを定義しません。

2. Producer/consumer independence（生産者/消費者の独立性）

OKFは知識を書く人とそれを消費する人を明確に分離します：

フォーマットが共通のインターフェースとして機能するため、生産側と消費側のツールはそれぞれ独立して開発・交換できます。

3. Format, not platform（フォーマットであり、プラットフォームではない）

OKFは特定のクラウド、データベース、モデルプロバイダー、またはエージェントフレームワークに紐付いていません。プロプライエタリなアカウントやSDKを、読み書きや配信のために決して要求しません。

知識フォーマットの価値はそれを所有する者ではなく、それを話す当事者の数から来るため、OKFはオープン標準として公開されています。

クロスリンクとパス

OKF概念は標準Markdownリンクで互いにリンクします：

references/ 規約：外部資料・実行コードをバンドル内で第一級の概念として配置する命名規約です（必須ではありません）。

index.md / log.mdの役割

log.md は以下のような内容になります。

# Directory Update Log

## 2026-05-22
* **Update**: Added a BigQuery table reference for [Customer Metrics](/tables/customer-metrics.md).
* **Creation**: Established the [Dataplex Playbook](/playbooks/dataplex.md).

## 2026-05-15
* **Initialization**: Created foundational directory structure.

YYYY-MM-DD 形式のヘッダーで日付ごとにグループ化し、新しいエントリを上に配置します。

第4章: OKFの具体例

具体例1: BigQueryテーブルの概念ドキュメント

リソースにバインドされた概念の例です：

---
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]
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-05-28T14:30:00Z }
---

# Schema

| Column        | Type      | Description                              |
|---------------|-----------|------------------------------------------|
| `order_id`    | STRING    | Globally unique order identifier.        |
| `customer_id` | STRING    | Foreign key into [customers](/tables/customers.md). |
| `total_usd`   | NUMERIC   | Order total in US dollars.               |
| `placed_at`   | TIMESTAMP | When the customer submitted the order.   |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

具体例2: インシデント対応プレイブック

リソースにバインドされない概念の例です：

---
type: Playbook
title: "Incident response: data freshness alert"
description: Steps to triage a freshness alert on the orders pipeline.
tags: [oncall, incident]
generated: { by: human:ahormati, at: 2026-04-12T09:00:00Z }
verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }
---

# Trigger

A freshness alert fires when `orders` lags more than 30 minutes behind its
expected SLA. See the [orders table](/tables/orders.md).

# Steps

1. Check the [ingestion job dashboard](https://example.com/dash).
2. ...

📚 参照資料

• OKFアナウンス記事 Google Cloudチームによる公式アナウンス
• GitHubリポジトリ OKFの仕様、リファレンス実装、サンプルバンドル
• OKF仕様書 OKFの完全な仕様書
• LLM Wikiパターン Karpathy氏によるLLM Wikiパターンの概要