Open Knowledge Format（OKF）とは？Googleのv0.2仕様とRAGとの違い

Open Knowledge Format（OKF）は、AIエージェントと人間が同じ知識を読むための、Google Cloud発のベンダー中立な仕様です。中身はMarkdownファイルとYAMLフロントマターだけで、SDKもスキーマレジストリも要りません。2026年6月のv0.1公開から2か月で仕様はv0.2へ上がり、正準リポジトリも移りました。この記事では2026年9月5日時点の仕様原文と公式リポジトリの実ファイルをもとに、v0.2で何が変わったか、バンドルをどう書くか、RAGやMCPとどう違うのかを整理します。

まとめ：OKF v0.2で先に押さえる4点

現行仕様はv0.2です。v0.1からの破壊的変更は2つだけで、フロントマターのtimestampがgenerated.atに、本文の# Citations見出しがsourcesフロントマターに置き換わりました。それ以外の追加はすべて任意キーなので、v0.1で書いたバンドルはv0.2の読み手からそのまま読めます。

必須キーは今もtypeひとつだけです。適合条件は「予約ファイル以外のすべての.mdがパース可能なYAMLフロントマターを持つ」「そのフロントマターが空でないtypeを持つ」「index.mdとlog.mdが規定の形式に従う」の3点で、任意フィールドが無いことを理由に読み手が文書を拒否することは仕様で禁じられています。

v0.2の中心は信頼です。出所（sources）、誰が書き誰が確認したか（generated・verified）、まだ有効か（status・stale_after）がフロントマターの一級市民になり、さらにtype: Attested Computationという新しい概念型が、エージェントが出した数字を「決められた計算をそのまま走らせたのか」まで機械的に検証できるようにしました。

そして運用上いちばん引っかかるのが場所です。仕様は2026年8月21日にGoogleCloudPlatform/open-knowledge-formatという専用リポジトリへ移り、以前のknowledge-catalogリポジトリ配下のコピーは「凍結されたスナップショット、もはやメンテナンスされない」と明記されました。v0.2の公式ブログのリンク先は移管前のパスのままなので、ブログから辿ると古い側に着地します。

v0.1からv0.2への3か月と、仕様リポジトリの移管

OKFは公開から動きの速い仕様です。日付を押さえておくと、ネット上の解説記事がどの版を前提に書かれているか判別できます。

公開から移管までの実際の日付（コミットとブログで確認）

「2026年6月公開」という表現をよく見かけますが、リポジトリへの初回コミットが6月12日、公式ブログが6月13日です。そして6月公開時点の仕様はもう現行ではありません。移管先の専用リポジトリは2026年8月11日に作られ、ライセンスはApache-2.0です。移管後のSPEC.mdと、凍結された旧コピーのSPEC.mdをdiffすると差分は0行で、内容は同一のv0.2でした。違うのは「どちらが今後更新されるか」だけです。

破壊的変更2点と、読み手側に用意されたフォールバック

仕様§13.1が挙げる破壊的変更は次の2点です。どちらも「v0.1のフィールドを改名または廃止した」という理由でそう分類されています。

# v0.1 の書き方
---
type: Metric
title: Income statement (fiscal year)
timestamp: '2026-05-28T22:53:05+00:00'
---

# Definition
...

# Citations
- https://wiki.acme/finance/fpa-handbook

# v0.2 の書き方
---
type: Metric
title: Income statement (fiscal year)
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }
sources:
  - id: fpa-handbook
    resource: https://wiki.acme/finance/fpa-handbook
    title: FP&A reporting handbook
---

# Definition
...per the FP&A reporting handbook.[^fpa-handbook]

[^fpa-handbook]: FP&A reporting handbook

出所が本文の箇条書きからフロントマターへ移ったことで、個々の主張への帰属はMarkdownの脚注ラベルで書きます。ラベルはsources[].idと一致させる決まりで、読み手は脚注の文面ではなくidの一致で解決します。仕様はその理由まで書いていて、エージェントが文書を書き換え続ける前提だとsources[0]のような位置指定は並び替えた瞬間に黙って誤帰属になるため、安定したidを鍵にしています。

移行が要るかというと、多くの場合は要りません。§13.1は、generatedが無ければ読み手が旧timestampにフォールバックしてよい、旧# Citationsの箇条書きをv0.1文書として解析してもよい、と明記しています。

追加キーが全て任意である理由と、v0.1相当として扱われる条件

§13.2の追加分は、sourcesとその信用シグナル、generated、verified、status、stale_after、新概念型Attested Computationとその計算系キー、本文の慣用見出し# Computation、そしてアクター表記です。仕様は「これらが無い場合は素のv0.1概念になる」とだけ述べています。バージョン番号の上げ方も定義済みで、マイナー更新は後方互換の追加、メジャー更新で必須フィールドの改名や予約ファイル名の変更が起こりえます。

OKFバンドルの書き方：必須キーはtypeだけという最小仕様

OKFの「バンドル」はMarkdownファイルが入ったディレクトリツリーそのもので、配布形態はgitリポジトリ（推奨）、tarballやzip、あるいは大きなリポジトリ内のサブディレクトリのいずれでも構いません。gitが推奨なのは履歴・帰属・差分が付いてくるからです。

ディレクトリ構造と、2つだけの予約ファイル

path/to/bundle/
  index.md          # 任意。段階的開示のためのディレクトリ目次
  log.md            # 任意。更新履歴
  <concept>.md      # ルート直下の概念
  metrics/
    index.md
    revenue.md

予約ファイル名はindex.mdとlog.mdの2つだけで、これらを概念文書に使ってはいけません。それ以外の.mdはすべて概念文書です。概念のID（Concept ID）はバンドル内のファイルパスから.mdを取り除いた文字列そのもので、別途IDを振る仕組みはありません。

フロントマターで必須なのはtypeだけです。推奨はtitle・description・resource・tagsの4つで、resourceは実体のある資産を指すURIなので、指標や業務プロセスのような抽象的な概念では省きます。typeの値は中央登録されておらず、BigQuery Table・Metric・Playbookのように書き手が自由に決めます。そのぶん読み手側には「知らないtypeを汎用の概念として穏当に扱う」義務が課されています。

---
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.  |
| total_usd  | NUMERIC| Order total in US dollars.         |

本文に必須のセクションはありません。慣用的な意味を持つ見出しが# Schema・# Examples・# Computationの3つあり、該当するときは使うべきとされています。フロントマターに独自キーを足すのも自由で、読み手は未知のキーを保持し、そのせいで文書を拒否してはいけません。

概念間リンクの2形式と、壊れたリンクを異常としない設計

概念どうしは普通のMarkdownリンクで結びます。バンドルルート起点の絶対形（/tables/customers.md）が推奨で、理由はサブディレクトリ内で文書を移動しても壊れないからです。相対形も使えます。

ここに設計思想がよく出ています。リンク先が存在しないリンクは不正ではありません。仕様は「まだ書かれていない知識を表しているだけかもしれない」として、読み手に壊れたリンクの許容を義務づけています。リンクの種類（親子・参照・依存）もリンク自体では表現せず、周囲の文章に委ねます。グラフ表示を作る読み手は、すべてのリンクを型のない有向辺として扱うのが標準的です。

v0.2の信頼シグナル：sources・generated・verified・status・stale_after

v0.2が答えようとしているのは、エージェントが書いた知識コーパスを人が使うときの5つの問いです。これは何から作られたのか、どれくらい信用してよいのか、まだ正しいのか、最新版なのか、そしてその数字は決められたやり方で出されたのか。前の4つが以下の信頼シグナル、最後の1つが次章のAttested Computationに対応します。

verifiedのアクター表記から導出する3段階のトラストティア

generatedは内容を誰がいつ書いたか、verifiedは誰がいつ確認したかを記録します。書いた主体と確認した主体は別でよい、という理由で意図的に分けられています。verifiedは検証イベントのリストで、人の承認と夜間バッチの確認を並べられます。

generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }
verified:
  - { by: human:ahormati, at: 2026-06-25T09:00:00Z }
  - { by: process:finance-nightly, at: 2026-06-26T02:00:00Z }
status: stable
stale_after: 2026-12-31T00:00:00Z

アクターの書き方は3種類に固定されています。エージェントやツールは<producer>/<version>、人はhuman:<id>、自動処理はprocess:<id>です。読み手はここから3段階のトラストティアを導きます。verifiedが無ければ未検証、human:以外のアクターだけなら機械確認済み、human:のアクターが1つでもあれば人によるレビュー済みです。

注意すべきは、ティアそのものはファイルに書かれないという点です。仕様は信用スコアを保存しない方針を明言していて、理由は「スコアは主観的で、読み手ごとに移植できず、陳腐化する」から。同じ理由で出典の信用も数値化せず、材料だけを置きます。実際、公式のGA4サンプルバンドルの概念文書はgenerated.byがreference_agent/gemini-3.5-flashでverifiedを持たないので、規定どおり読めば未検証ティアです。エージェントが生成した状態のまま置かれている、と読み手が判別できます。

ライフサイクル側は単純です。statusはdraft・stable・deprecatedの3値で、省略時はstableとみなします。stale_afterは相対的なTTLではなく絶対時刻で、現在時刻がその値以上なら陳腐化と判定します。相対値にしなかったのは、判定を「読んだ時刻を持ち出さない単純な比較」にするためです。

出典の信用シグナルauthor・usage_count・last_modifiedの読み方

sourcesの各エントリで必須なのはresourceだけです。resourceには辿れる実体（URL、バンドル相対パス）だけでなく、辿れない範囲記述（たとえば「BigQueryプロジェクトX内の全クエリ」）も書けます。ここに任意で3つの信用シグナルが付きます。

• author：誰が作った出典か。アクター表記に従う権威のシグナル
• usage_count：usage_windowで示す期間内に、その出典が何回参照・実行されたか
• last_modified：出典自体の最終更新。概念を書いた時刻であるgenerated.atとは別物

実務で誤読しやすいのがusage_countです。仕様は粗いシグナルであると明示して、精密なランキングに使わないよう釘を刺しています。生死の判別と桁の比較、そして同じ出典の時系列比較には使えますが、スケジュール実行されたクエリの回数と人が意図して開いたダッシュボードの閲覧数は重みが違うためです。読み手は「生きているか」と「傾向」として読むべきとされています。まずこの1点だけ守れば十分で、他の2つは補助と考えて構いません。

Attested Computation：エージェントが独自SQLで数字を出していないかの機械判定

v0.2で追加されたtype: Attested Computationは、値の意味だけでなく「その値を出すために認められた計算」を持ち歩く概念型です。狙いは、エージェントが金額を報告した瞬間に立ち上がる疑いに答えることです。決められたSQLを走らせたのか、それとも自分でSQLを書いたのか。

runtime・parameters・executor・attesterが結ぶ契約

契約はフロントマターに書きます。この型で必須なのはruntimeで、bigquery・postgres・dbt・python・Lookerなどの値を取り、parametersが何を意味するかを決める役割を負います。同じ「パラメータ」でも、runtimeによってSQLのバインド変数だったりdbtの変数だったりPython引数だったりするからです。

---
type: Attested Computation
title: Revenue for fiscal year
description: Recognized revenue for a fiscal year, per Finance's definition.
status: stable
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: references/skills/run-on-bq.md
  receipt: [job_id, executed_sql, result]
attester:
  resource: references/attesters/revenue.py
generated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-20T22:53:05Z }
verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }
stale_after: 2026-09-23T00:00:00Z
sources:
  - id: rev-policy
    resource: https://wiki.acme/finance/revenue-recognition
    title: Revenue recognition policy
---

# Computation

    SELECT SUM(amount) AS revenue
    FROM finance.recognized_revenue
    WHERE fiscal_year = @year

executorは実行手順やコードの在処と、実行が返すべきレシートの項目を宣言します。上の例ならjob_id・executed_sql・resultです。attesterはそのレシートを検査して合否を返す決定的なコードで、LLMを使わないこと、読み手側で動かすことが仕様に書かれています。

エージェントに許されるのは宣言されたparametersに値を入れることだけで、計算そのものを書いたり編集したりしてはいけません。比較対象が展開・コンパイル後の成果物（executed_sqlやcompiled_sql）なので、クエリを書き換えても、計算ファイルを差し替えても、依存を変えても検査に落ちます。型付きでパラメータだけを開けた面にしたことが、「認められた処理が走ったか」を判断ではなく機械的な突き合わせにしています。

なおverifiedとアテステーションは別物で、両方必要です。verifiedは定義がポリシーに合っているかの文書レベルの確認で、バンドルに保存されます。アテステーションは1回の実行が正しいやり方で値を出したかの実行時の確認で、バンドルには保存されません。定義が古くても実行はきれいに通りますし、定義を確認したばかりでも実行ごとに検査は要ります。

参照実装sql_equality.pyが実際に比較しているもの

公式サンプルバンドルには実際に動くattesterが1本入っています。BigQueryランタイム用のsql_equality.pyで、docstringに「LLMを一切使わない。ネットワークアクセスを一切しない。読み手側で安全に実行できる」と書かれています。中核は正規化処理です。

def _canonicalize(sql: str) -> str:
    """Strip comments, collapse whitespace, uppercase keywords."""
    s = _COMMENT_BLOCK.sub(" ", sql)
    s = _COMMENT_LINE.sub(" ", s)
    s = _WHITESPACE.sub(" ", s).strip()
    # Uppercase only known SQL keywords; leave identifiers alone.
    def _upper_kw(match: re.Match[str]) -> str:
        w = match.group(0)
        return w.upper() if w.upper() in _KEYWORDS else w
    s = re.sub(r"[A-Za-z_][A-Za-z_0-9]*", _upper_kw, s)
    return s

ブロックコメントと行コメントを落とし、連続空白を1個に畳み、あらかじめ列挙した約30語のSQLキーワードだけを大文字化します。識別子には手を触れませんから、テーブル名や列名の綴りが違えば不一致になります。この正規化を通したうえで、実行されたSQLと認められたSQLを比較するのが「出所」の検査、表示した値がレシートの結果の先頭セルと一致するかを見るのが「忠実性」の検査です。名前付きバインド変数は記号として比較され、値の中身までは見ません。バインドはexecutorを信頼する設計だからです。

正規化がこの程度である以上、意味的に同じで字面が違うSQL（結合順の入れ替えなど）は不一致になります。厳しすぎると感じるかもしれませんが、サンプルバンドルacme_retailの粗利計算概念は、むしろそれを利用しています。COGSの4つのLEFT JOINのどれかを落としたSQLは、正規化後の一致に結合グラフが含まれるので検査に落ちる、と本文に明記されています。

RAG・MCP・llms.txt・EntityMapとの関係を、仕様原文で確認した結果

OKFの解説では「MCPと競合しない」「llms.txtの次の層」といった位置づけがよく語られます。実際に確かめました。専用リポジトリの全ファイルをgrepすると、Karpathy、llms.txt、AGENTS.md、EntityMap、MCP（Model Context Protocol）のいずれも出現数は0件です（2026-09-05時点）。OKFの仕様書は他規格との比較を一切していません。ただしKarpathyについては別で、v0.1発表時の公式ブログが「Andrej Karpathyがこの考えをLLM Wikiのgistで最も明快に述べている」と名指しで紹介しています。起源の帰属はブログ側にあり、仕様書側には無い、という配置です。世に出回っている他規格との対比図のほうは、仕様の主張ではなく解説側の整理だと理解しておくのが正確です。

そのうえで、仕様が自分で名乗っている範囲と、各規格が実際に置かれる層を並べると次のようになります。

RAGとの違いはとくに問い合わせの多い論点です。OKFは検索の仕組みではなく、検索される側の中身の形式です。RAGのパイプラインにOKFバンドルを食わせることもできますし、逆に、バンドルが十分小さければLLMのコンテキストへ丸ごと読み込む使い方もできます。仕様が想定する読み手には「静的ファイルサーバー」「Obsidian、Notion、MkDocsのような知識管理UI」「ファイルをコンテキストに読み込むLLM」「検索インデックス」が並んでいて、特定の検索方式に寄せていません。両者は置き換え関係ではありません。

EntityMapは名前と時期が近いため混同されがちですが、別物です。entitymap.orgが公開する仕様v1.0はJSONで、サイトが扱う実体の索引を公開ドメインの決まった場所に置き、AI検索や取得パイプラインに読ませます。2026年7月1日のローンチで、公開Webに向いた層にあります。OKFは社内の知識コーパスに向いた層で、対象読者も配布経路も違います。

参照実装のreference agentとビジュアライザを動かす手順

OKFはフォーマット自体が成果物で、リポジトリに入っているエージェントとビジュアライザは「作る側と読む側を触れるようにするための概念実証」と位置づけられています。この前提を外すと、ツールの完成度で仕様を評価してしまいます。

2パス構成のenrichコマンドとWebクロールの上限

パッケージ名はreference-agentで、requires-pythonは3.11以上、依存にgoogle-adk>=2.0とgoogle-cloud-bigquery>=3.20が入ります。READMEの手順はPython 3.13で仮想環境を作る書き方です。

python3.13 -m venv .venv
.venv/bin/pip install --index-url https://pypi.org/simple/ -e .[dev]

.venv/bin/python -m reference_agent enrich \
    --source bq \
    --dataset <project>.<dataset> \
    --web-seed-file <path/to/seeds.txt> \
    --out ./bundles/<name>

動きは2パスです。BQパスがBigQueryのメタデータだけで概念ごとに1文書を書き、続くWebパスではLLM自身がクローラーとして動きます。与えられたシードURLを取得し、既存の概念にとって権威ある文書に見えるかで辿る先を判断し、ページごとに既存文書を補強するか、独立した参照文書を作るか、無視するかを選びます。暴走対策はエージェントの判断任せではなく、--web-max-pagesの上限と同一ドメイン許可リストがツールの内側で強制されます。Webパスを丸ごと外す--no-webもあります。

資格情報は2種類要ります。BigQueryはgcloud auth application-default loginと課金先プロジェクトの設定で、公開データセットでもクエリのバイト課金は呼び出し側のプロジェクトに来ます。Gemini側はAI StudioのGEMINI_API_KEYか、Vertex AIを使う環境変数の組み合わせです。

単一HTMLのビジュアライザと、公開されているサンプルバンドル4本

.venv/bin/python -m reference_agent visualize --bundle ./bundles/<name>

これでバンドル直下にviz.htmlが1ファイル出ます。バックエンド不要、閲覧側のインストールも不要で、力学モデルによる概念グラフ、選択した概念のフロントマターと本文、被リンク一覧、検索と型フィルタが入っています。グラフはCytoscape.js、Markdown描画はmarkedをCDNから読む構成で、バンドルは生成時に一度パースされてJSONとしてファイルに埋め込まれます。ページからデータは出ません。

リポジトリに入っているサンプルバンドルは4本です。GA4のeコマース、Stack Overflow公開データセット、Bitcoinのブロックとトランザクション、そしてacme_retail。前の3本はエージェントが生成したもので、acme_retailだけがv0.2の新機能を通しで見せるための構成になっており、metrics/・computations/・policies/・skills/・attesters/にディレクトリが分かれています。v0.2の書き方を掴むならここを読むのが最短です。

Knowledge Catalogへ公開する前に知るべき、7キーしか運ばれない制限

Google Cloudは自社のKnowledge Catalog（旧Dataplex系のカタログ）にOKFを取り込めるようにしたと発表しています。ただし専用リポジトリのconnectors/gcp-knowledge-catalog.mdには、読者に「まずLimitationsを読め」と書かれた実装ガイドが置かれていて、そこがいちばん実務に効きます。取り込みはkcmdというCLIで、実行にはBunと、gcloud configでのプロジェクトとロケーションの設定が要ります。フラグも環境変数もありません。

運ばれるのはフロントマターの7キーとMarkdown本文だけです。title・description・tagsはネイティブのエントリ項目になり、resourceはエントリのリソース名に、type・generated・sourcesはokfアスペクトに載ります。それ以外のキーは翻訳されません。さらに以下が明記されています。

• .md以外は双方向で無視される（画像・HTML・CSVは押しも引きもされない）
• 概念間の相対リンクは文字列のまま保存され、カタログ側では何も解決しない
• tagsは値が"true"のラベルになり、読み戻せるのはその値のラベルだけ。Dataplexはラベルキーを128文字までに制限する
• リネームはカタログ側の状態を孤児にし、削除はエントリを残す。マージの筋道は用意されていない
• エントリ単位のアクセス制御が無い。プロジェクトの基本ロールがあれば誰でも読めて一括エクスポートできる
• 規模は14ファイルのデモを超えて検証されていない

この一覧を踏まえると、判断は明快です。機微な内容を含むバンドルをKnowledge Catalogへ押し込むのは、現時点では避けるべきです。roles/viewerはroles/dataplex.catalogViewerの厳密な上位集合でエントリグループのエクスポート権限まで含むため、閲覧者を広く配っているプロジェクトでは、押した瞬間に全文が持ち出せる状態になります。ガイド自身が「gitを正本として扱い、マージ時にpush、追跡中のバンドルにpullしない」と運用を限定しているのも同じ理由です。カタログ連携は配布のための一方向の投影であって、同期ではありません。

日本企業がOKF v0.2に着手するかの判断基準

まず成熟度の見方から。v0.2はまだ0系で、仕様§12は「今後の版に持ち越す」項目を自分で列挙しています。実行時プロトコル（レシートと判定結果のワイヤフォーマット、実行まわりのアテステーション・ライフサイクル）、attesterのABIと可搬性・サンドボックス化、アテステーション結果のキャッシュ、そしてセマンティックレイヤー向けのテンプレートです。つまりAttested Computationは、契約の書き方は決まったが、走らせる側の相互運用はまだ決まっていません。ここに依存した基盤を今組むのは早すぎます。

一方で、フォーマットそのものを採る判断は別です。バンドルはMarkdownとYAMLのディレクトリでしかなく、専有APIもSDKも介在しません。仮にOKFが普及しなくても、手元に残るのはgitで差分の見える文書群です。捨て値が小さい、というのが導入判断の実質です。

着手するなら順序があります。仕様のSPEC.mdを読み、acme_retailバンドルでv0.2の書き方を確認し、既存のConfluenceや社内Wikiから移す文書を1ディレクトリ分だけ選んでtypeとdescriptionを付ける。ここまでは無料でGCPの契約も要りません。BigQueryを実際に走査してバンドルを自動生成するreference agentの段階で初めて、クエリのバイト課金とGeminiの利用が発生します。

逆に、採用を見送るべき条件も具体的に挙げられます。既存のデータカタログ製品を入れていて権限管理と系譜がそこで完結しているなら、OKFを二重の正本にしないでください。データカタログOSSの構成と採用判断はOpenMetadataとは？データカタログOSSの構成・実装手順と採用判断を解説【2026年版】に、名前空間と権限継承の設計はUnity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】にまとめています。こうした製品を運用中の組織では、OKFは「外へ出す形式」として後段に置くのが素直です。実際、公式のREADMEもDataplex・Unity Catalog・Collibraからのエクスポート経路をOKFの生産者の一例として挙げていて、置き換えとは言っていません。

日本語の一次解説がまだ少ないため、判断材料は英語のSPEC.mdとリポジトリの実ファイルに取りに行くことになります。移管の件のように、公式ブログのリンクが古いままという状況も起きています。仕様の版とリポジトリのパスは、参照するたびに確認してください。

Open Knowledge Format（OKF）に関するよくある質問

OKFとOpen Knowledge Foundationは同じものですか？

別物です。Open Knowledge Format（OKF）はGoogle Cloudが2026年6月に公開した、AIエージェント向けの知識表現フォーマットの仕様です。Open Knowledge Foundation（OKFN）はオープンデータを推進する非営利団体で、設立も目的も異なります。頭字語の「OKF」は飲料ブランドなど他分野でも使われているため、検索や社内資料では「Open Knowledge Format」と省略せずに書くか、Google Cloudの名前を添えると混同を避けられます。

OKF v0.1で書いたバンドルはv0.2でそのまま読めますか？

読めます。v0.2の仕様§13は、v0.1バンドルがv0.2の読み手から消費可能であると明記しています。破壊的変更はtimestampと本文の# Citationsの2点ですが、どちらにもフォールバックが用意されていて、generatedが無ければ旧timestampを読んでよく、旧形式の引用リストを解析してもよいとされています。追加された機能はすべて任意キーなので、書き足さなければv0.1相当の概念として扱われます。

OKFの仕様はどのリポジトリを見ればよいですか？

2026年9月時点の正準はGoogleCloudPlatform/open-knowledge-formatです。以前はknowledge-catalogリポジトリのokf/配下にありましたが、2026年8月21日に専用リポジトリへ移り、旧コピーには「凍結されたスナップショット、もはやメンテナンスされない」という警告が付きました。両者のSPEC.mdは現時点で内容が同一ですが、今後更新されるのは新しい側だけです。v0.2発表時の公式ブログのリンク先は旧パスのままなので注意してください。

OKFとRAGはどちらを採用すべきですか？

比較の軸が違うので、どちらかを選ぶ関係ではありません。RAGは問い合わせのたびに検索して文脈を注入する実装方式で、OKFは検索される側の知識をどう書き表すかというフォーマットです。OKFバンドルをRAGの取り込み元にすることもできますし、バンドルが小さければLLMのコンテキストへ直接読み込む使い方もできます。社内知識が複数の場所に散っていて表現形式が揃っていないなら、OKFで形を揃えることが先に効きます。

OKF v0.2は本番環境に導入してよい成熟度ですか？

フォーマットとしての採用と、Attested Computationに依存した仕組みの構築は分けて考えてください。前者はMarkdownとYAMLのファイル群でしかなく、規格が普及しなくても資産が残るため、限定した範囲から始める価値があります。後者は仕様§12が実行時プロトコル、attesterのABIとサンドボックス化、結果のキャッシュを今後の版へ持ち越すと明記しているため、相互運用を前提にした本番実装は時期尚早です。

関連記事

• Dataplexとは？機能・料金・Knowledge Catalog改称を実装目線で解説【2026年版】
• OpenMetadataとは？データカタログOSSの構成・実装手順と採用判断を解説【2026年版】
• Unity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】
• MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説
• ナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年版】