Open Knowledge Format（OKF）と iknow

Open Knowledge Format（OKF）と iknow

出典:

• 公式仕様 OKF SPEC.md（Version 0.2）（GoogleCloudPlatform/knowledge-catalog、Apache-2.0）
• 解説 Introducing the Open Knowledge Format（Google Cloud Blog、2026-06-12）
• v0.2 解説 OKF v0.2 adds trust signals（Google Cloud Blog、2026年7月）

OKF は LLM Wiki パターンを ポータブルで相互運用可能なオープン仕様 として形式化した標準です。最新は v0.2（2026年7月公開）で、v0.1 からは 後方互換 を保ったまま信頼シグナルが追加されました（詳細は「最新状況」節）。

OKF とは

OKF bundle の構造

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

• 1 ファイル = 1 concept（テーブル、メトリクス、手順書など）
• ファイルパスが concept の ID
• concept 同士は Markdown リンク でグラフ化
• 任意で index.md（カタログ）と log.md（変更履歴）を含む

YAML frontmatter（v0.2）

---
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]
generated:
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:kliu@acme
    at: 2026-07-01T16:00:00Z
status: stable
stale_after: 2026-12-31
---

名称変更は timestamp → generated.at と # Citations → sources の 2 つだけ で、consumer はいずれも旧形式をフォールバックとして受理します。v0.1 の bundle は無修正のまま v0.2 consumer に読ませられます。

設計の3原則

1. Minimally opinionated — type 以外はプロデューサーに委ねる
2. Producer/consumer independence — 書く側と読む側が独立して交換可能
3. Format, not platform — 特定クラウド・DB・モデルに非依存

最新状況（2026-09 時点）

信頼シグナル（v0.2 の中心）

OKF は スコアではなくシグナルを記録 し、信頼できるかの判断は consumer 側に委ねます。

verified の有無と実行者から、consumer は 未検証 / 機械確認済み / 人間レビュー済み の 3 階層を導けます（human:<id> が最上位）。アクセス制御ではなく、「幹部向けダッシュボードには人間レビュー済みだけを出す」のような絞り込みに使う助言的なシグナルです。

バージョン宣言とポリシー（SPEC §12）

• bundle は ルートの index.md の frontmatter に okf_version: "0.2" を書いて対象バージョンを宣言できる（index.md に frontmatter を置ける唯一の例外）。
• マイナー更新＝後方互換の追加（任意フィールド・慣用見出しの追加）、メジャー更新＝破壊的変更（必須フィールド名や予約ファイル名の変更）。
• consumer は理解できないバージョンでも 拒否せずベストエフォートで読む。

仕様で確定している要点（現行ナレッジへの補足）

• Concept ID = ファイルパスから .md を除いたもの（例: tables/users.md → tables/users）。
• 予約ファイル名は index.md と log.md のみ。それ以外の .md はすべて concept。
• 本文の 慣用見出し として # Schema / # Examples が定義（必須ではない）。外部出典は v0.2 では frontmatter の sources に書く（v0.1 の末尾 # Citations もフォールバックとして読まれる）。
• リンクは無向の関係を表す有向エッジ。/ 始まりの bundle ルート相対リンクが推奨。consumer は リンク切れを許容 しなければならない。
• 適合条件（§11）はゆるい：各 concept に解析可能な frontmatter があり、空でない type を持てば適合。任意フィールド欠落・未知の type・リンク切れ・index.md 不在では 拒否しない。
• ドメイン固有スキーマ（Avro / Protobuf / OpenAPI 等）は 置き換えず参照する（非ゴール）。

iknow と OKF の位置づけ

iknow は LLM Wiki 思想（No.10.1） を実装したプラットフォームです。OKF はそのパターンを ファイル交換フォーマット として標準化したものと捉えられます。

flowchart LR
  OKF["OKF bundle（ファイル形式）"] <-->|エクスポート/インポート| IK["iknow（プラットフォーム）"]
  LLM[LLM Wiki 思想] --> OKF
  LLM --> IK

iknow の frontmatter 出力

iknow はナレッジを エクスポート するとき、本文の先頭に YAML frontmatter を付与し、インポート時に読み戻します。出力するのは次の 6 項目です。

type は OKF では concept 種別ですが、iknow では本文形式を表し、値は常に markdown です（テーブル型JSON形式は 2026年8月に廃止 → No.1.3）。

OKF の resource（一次資料 URL）と description は出力しません。かつて出力していた service_name / service_key（インポート元）も、外部サービス連携の廃止に伴いなくなりました。

v0.2 との差分：iknow の出力は v0.1 形式の timestamp のままで、v0.2 で追加された信頼シグナル（generated / verified / sources / status / stale_after）は出力しません。v0.2 consumer は timestamp をフォールバック受理するため 読み込み自体は支障なく可能 です。

OKF との対応（準拠・差分）

3表に分かれていた比較を 1 つにまとめます。

iknow から OKF へ近づけるには

Ingest（No.13.1）で外部資料を取り込むとき、OKF 互換を意識するなら:

1. concept 種別をタグで補う — frontmatter の type は本文形式（markdown/json）なので、OKF の concept 種別はタグで表す（例: BigQuery Table）
2. 冒頭に description 相当の 1 行要約 を書く
3. 出典 URL を本文に残す — frontmatter に resource は出力されないため、本文冒頭または末尾の出典節に書く
4. 関連ナレッジと本文リンクを両方張る — OKF consumer も iknow Query も満たす
5. No.0 目次を常に更新 — index.md 維持と同じ運用
6. ZIP エクスポート前に No を振る — related_nos によるリンク復元のため
7. v0.2 の信頼シグナルは本文で代替する — generated / verified / status / stale_after は出力されないため、外部に渡す前提で必要なら、本文冒頭に「最終確認日・確認者・ステータス」を明記しておく

まとめ

iknow でナレッジを育てる運用（Ingest → Query → Lint）は OKF の思想と一致します。将来 OKF へのエクスポート／インポートが強化された場合も、No.0 目次・タグ・関連リンク・1 テーマ 1 ページ の設計を守っておけば移行コストを下げられます。