Open Knowledge Format（OKF）とは？Googleのv0.2仕様とRAGとの違い【2026年10月】

Open Knowledge Format（OKF）は、AIエージェントと人間が同じ知識を読むための、Google Cloud発のベンダー中立な仕様です。中身はMarkdownファイルとYAMLフロントマターだけで、SDKもスキーマレジストリも要りません。現行版はv0.2で、2026年10月26日時点でv0.3や2.0は出ていません。この記事では仕様原文、公式ブログ3本、参照実装を実際に動かした結果をもとに、v0.2の書き方、8月に入った日付形式の改訂、Knowledge Catalogへの公開手順、RAGやMCPとの違いを整理します。

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

現行仕様はv0.2です。v0.1からの破壊的変更は2つだけで、フロントマターのtimestampがgenerated.atに、本文の# Citations見出しがsourcesフロントマターに置き換わりました。必須キーは今もtypeひとつで、任意フィールドが無いことを理由に読み手が文書を拒否することは仕様で禁じられています。

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

いちばん踏みやすい落とし穴は日付です。2026年8月21日の改訂で、stale_afterなどの値はオフセット付きの日時でなければ不適合になりました。版番号は0.2のままです。v0.2の公式ブログはstale_after: 2026-12-31と日付だけで例示しているため、写すと参照実装はその概念を永久に陳腐化しないものとして扱います。

場所と配布先も変わりました。正準リポジトリはGoogleCloudPlatform/open-knowledge-formatで、旧knowledge-catalog配下のコピーは凍結済みです。Knowledge Catalogへの公開は、2026年8月26日（日本時間27日）の公式ブログでは、v0.2の信頼シグナルを13フィールドのAspectで損失なく運ぶ方式が紹介されています。仕様リポジトリ側に残る連携ガイドの「7キーしか運ばれない」は古い記述です。

v0.1からv0.2、Knowledge Catalog連携までの経緯と現行版

OKFは公開から4か月で版も置き場所も変わりました。日付を押さえておくと、ネット上の解説がどの版を前提に書かれているか判別できます。

公開から2026年10月までの日付（コミットとブログで確認）

2026年6月に公開されたv0.1を前提とする解説と、現行のv0.2を扱う解説は区別して読む必要があります。専用リポジトリGoogleCloudPlatform/open-knowledge-formatは2026年8月11日に作られ、ライセンスはApache-2.0です。SPEC.mdの最終変更は8月21日のPR #6で、その後10月26日までの2か月、仕様本文は動いていません。v0.3のタグもブランチもありません。

次の版の材料はIssueに積まれています。型付きの関係（#16）、否認を記録するrefuted（#13）、出典のハッシュを持たせるdigest（#45）とrevision（#46）、フロントマターのJSON Schema（#8）などで、いずれも未採用の提案です。「v0.3の新機能」をうたう解説を見かけたら、提案と仕様を取り違えていないか確認してください。

破壊的変更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と一致させます。エージェントが文書を書き換え続ける前提だと、sources[0]のような位置指定は並び替えた瞬間に黙って誤帰属になるため、安定したidを鍵にしています。

移行作業は多くの場合要りません。§13.1は、generatedが無ければ旧timestampにフォールバックしてよい、旧# Citationsの箇条書きをv0.1文書として解析してよい、と明記しています。§13.2の追加分はすべて任意キーで、書かなければ素のv0.1概念として扱われます。

2026年8月21日の日時形式改訂と版番号0.2の据え置き

PR #6は「OKFの日時を表すキーはすべて、明示的なUTCオフセット付きのISO 8601日時」という一文を足し、それまでYYYY-MM-DDと定めていたstale_after・sources[].last_modified・usage_windowの3つを日時に書き換えました。仕様§12は破壊的変更をメジャー更新に限ると定めていますが、SPEC.mdの版表記は改訂前後とも0.2です。この食い違いはIssue #24が「okf_version: "0.2"が2つの文書を指している」と指摘していて、10月26日時点で未解決です。

実害を確かめるため、8月21日時点の参照実装（コミットad30107）のdocument.pyをPython 3.13で読み込み、is_stale()に2026年10月26日を現在時刻として渡しました。

stale_after: 2025-01-01                 -> is_stale = False
stale_after: 2025-01-01T00:00:00Z       -> is_stale = True
stale_after: 2025-01-01T00:00:00        -> is_stale = False
stale_after: 2027-01-01T00:00:00+09:00  -> is_stale = False

日付だけの値と、オフセットの無い日時はエラーにならず、黙って「陳腐化していない」と判定されます。関数のdocstringは「日付だけの値はタイムゾーンごとに別の瞬間を指すので、推測せず無視する」と理由を書いています。ビジュアライザも同じ関数を使っていて、2つの概念を並べて読み込むと日付だけの側はstale=Falseになり、viz.htmlの「stale」バッジが付かない扱いでした。

対策は1つです。日時を表すキーは2026-12-31T00:00:00+09:00のようにオフセットまで書く。v0.2の公式ブログのtables/orders.mdの例はstale_after: 2026-12-31のままなので、ブログから書き方を写したバンドルは一度見直してください。リポジトリのサンプルバンドルacme_retailは同じPRで日時形式に直っています。

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はバンドル内のファイルパスから.mdを取り除いた文字列そのもので、別にIDを振る仕組みはありません。ルートのindex.mdには、対象の版を宣言するokf_versionキーを任意で置けます。

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

推奨キーはtitle・description・resource・tagsの4つで、resourceは実体のある資産を指すURIなので、指標や業務手順のような抽象的な概念では省きます。typeの値は中央登録されておらず、BigQuery Table・Metric・Playbookのように書き手が決めます。参照実装のvalidate()もtypeの欠落だけを例外にし、titleの無い文書は通りました。v0.1時点の解説に「参照実装は実質4フィールドを要求する」とあるのは、v0.2の実装には当てはまりません。

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

概念間リンクとパス型フィールドの先頭スラッシュ表記

概念どうしは普通のMarkdownリンクで結びます。バンドルルート起点の/tables/customers.mdが推奨で、相対形も使えます。リンク先が無いリンクは不正ではなく、仕様は「まだ書かれていない知識を表しているだけかもしれない」として、読み手に壊れたリンクの許容を義務づけています。リンクの種類（親子・参照・依存）はリンク自体では表さず、周囲の文章に委ねます。

フロントマターで場所を指すキー（resource・sources[].resource・computation・executor.resource・attester.resource）は、§6.2で「絶対URL」「/で始まるバンドル相対パス」「相対パス」の3形式を受け付けます。ところがサンプルのacme_retailは、metrics/gross-margin.mdの中でpolicies/margin-standard.mdと先頭スラッシュなしで書いています。§6.2どおりファイル起点で解決するとmetrics/policies/を指してしまう書き方で、Issue #29がこの食い違いを指摘しています。どちらに決着しても壊れないのは/policies/margin-standard.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>。読み手はここからトラストティアを導きます。verifiedが無ければ未検証、human:以外のアクターだけなら機械確認済み、human:が1つでもあれば人によるレビュー済みです。参照実装のtrust_tier()にprocess:だけの例を渡すと、machine-confirmedが返りました。

ティアそのものはファイルに書きません。仕様は信用スコアを保存しない方針を明言していて、理由は「スコアは主観的で、読み手ごとに移植できず、陳腐化する」から。公式の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だけで、辿れる実体（URL、バンドル相対パス）のほか「BigQueryプロジェクトX内の全クエリ」のような範囲記述も書けます。任意の信用シグナルは3つです。

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

誤読しやすいのがusage_countです。仕様は粗いシグナルだと明示し、精密なランキングに使わないよう求めています。スケジュール実行されたクエリの回数と、人が開いたダッシュボードの閲覧数では重みが違うためです。使えるのは生死の判別、桁の比較、同じ出典の時系列比較までです。

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

type: Attested Computationは、値の意味に加えて「その値を出すために認められた計算」を持ち歩く概念型です。エージェントが金額を報告したとき、決められたSQLを走らせたのか、自分でSQLを書いたのかを機械的に判定するために追加されました。

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

この型で必須なのはruntimeで、bigquery・postgres・dbt・pythonなどの値を取り、parametersが何を意味するかを決めます。同じパラメータでも、runtimeによってSQLのバインド変数だったりdbtの変数だったりPython引数だったりするからです。下の例のパスは、前章の理由で先頭スラッシュ付きに直してあります。

---
type: Attested Computation
title: Revenue for fiscal year
status: stable
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: /skills/run-on-bq.md
  receipt: [job_id, executed_sql, result]
attester:
  resource: /attesters/sql_equality.py
verified: { by: human:ahormati, at: 2026-06-25T09:00:00Z }
stale_after: 2026-12-31T00:00:00+09:00
---

# 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なので、クエリを書き換えれば検査に落ちます。

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キーワードだけを大文字化します。識別子には手を触れないので、Ordersとordersのようにテーブル名の綴りが違えば不一致です。逆に、正規表現は文字列リテラルを区別しないため、SELECT 'a  b'とSELECT 'a b'、'select'と'SELECT'は同じ正規形になりました（掲載関数を実行して確認）。SQLの意味の違いをすべて検出できるわけではありません。この正規化のうえで実行SQLと認められたSQLを比べるのが「出所」の検査、表示した値がレシートの結果の先頭セルと一致するかを見るのが「忠実性」の検査です。docstringのとおりバインド変数の値は検査せず、ネットワークにも出ないので、job_idから実際のジョブを引き直すこともしません。検査できるのは渡されたレシートの中身の整合までで、レシート自体を信頼できる経路で受け取る設計は利用側の仕事です。結合順を入れ替えただけの同じ意味のSQLも不一致になり、acme_retailの粗利計算は、COGSの4つのLEFT JOINのどれかを落としたSQLが検査に落ちることをこの性質で担保しています。

OKFとRAG・MCP・LLM Wiki・AGENTS.mdの違い

先に確認した事実を置きます。仕様リポジトリの全ファイルをgit grepすると、Karpathy・llms.txt・AGENTS.md・CLAUDE.md・EntityMap・MCPはいずれも0件、単語としてのRAGも0件です（2026-10-26）。SPEC.mdは他規格との比較をしていません。他規格の名前が出てくるのは公式ブログの側です。

OKF・RAG・MCPの役割と処理層の違い

OKFは検索の仕組みではなく、検索される側の中身の形式です。OKFバンドルをRAGの取り込み元にもできますし、小さければLLMのコンテキストへ丸ごと読み込めます。READMEが挙げる読み手も「静的ファイルサーバー」「Obsidian・Notion・MkDocsのような知識管理UI」「ファイルを読み込むLLM」「検索インデックス」で、特定の検索方式に寄せていません。RAGとMCPの組み合わせ方はMCPとRAGの違いとは？使い分けの判断とRAG検索をMCPツール化する実装【2026年版】で、公開サイト向けの道標であるllms.txtはllms.txtとは？書き方・設置方法とv2の変更点、Googleが効果なしとする理由【2026年9月】で扱っています。

Karpathy LLM Wiki・AGENTS.md・Agent Skillsとの関係

v0.1の公式ブログは、エージェントに共有のMarkdownライブラリを持たせて育てる発想を、Andrej KarpathyがLLM Wikiのgistで「最も明快に述べている」と名指ししています。同じブログは、同様のパターンとしてObsidianの保管庫、「AGENTS.md / CLAUDE.mdの系統の規約ファイル」、データチームのMetadata as Codeリポジトリを挙げ、「どれも個別仕立てで、連携するよう設計されていない」と続けます。OKFはその共通部分、つまり各文書が持つべきフィールドとファイル名の意味を決めるための仕様です。

違いは読み手と粒度にあります。AGENTS.mdは自身を「エージェントのためのREADME」と説明するファイルで、コーディングエージェント向けの手順や文脈を書き、大きなリポジトリではサブプロジェクトごとに入れ子で置けます。Agent SkillsはSKILL.mdに作業手順とスクリプトを束ねる形式で、詳細はAgent Skillsとは？SKILL.md仕様とAAIF寄贈後も移植性を保つ実装手順にまとめています。OKFは「何をするか」ではなく「組織が何を知っているか」を、テーブル・指標・方針の概念ごとに1ファイルで書き、出所と確認履歴を付けます。手順はAGENTS.mdやSkillに、定義と根拠はOKFに、と分けるのが素直です。個人のノートをLLMで育てる用途なら、Personal Knowledge Base（PKB）とは？パーソナルナレッジベースの定義とローカルLLMで組む手順【2026年10月】の構成のほうが軽く済みます。

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

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

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

パッケージ名はreference-agent（0.1.0）で、requires-pythonは3.11以上、依存はgoogle-adk>=2.0・google-cloud-bigquery>=3.20などです。

git clone https://github.com/GoogleCloudPlatform/open-knowledge-format
cd open-knowledge-format
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>

BQパスがBigQueryのメタデータから概念ごとに1文書を書き、続くWebパスではLLMがシードURLを取得して、既存の概念を補強するか、参照文書を作るか、無視するかを選びます。暴走対策の--web-max-pages上限と同一ドメイン許可リストはツールの内側で強制され、Webパスを外す--no-webもあります。BigQueryは公開データセットでもクエリのバイト課金が呼び出し側のプロジェクトに来ます。Gemini側はAI StudioのGEMINI_API_KEYかVertex AIの環境変数で認証します。

単一HTMLのビジュアライザと、サンプルバンドル4本

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

バンドル直下にviz.htmlが1ファイル出ます。概念グラフ、フロントマターと本文、被リンク一覧、検索と型フィルタが入り、トラストティアと陳腐化の判定も表示されます。サンプルはGA4のeコマース、Stack Overflow公開データセット、Bitcoin、acme_retailの4本で、v0.2の書き方を通しで見せるのはacme_retailだけです。metrics/・computations/・policies/・skills/・attesters/に分かれています。

Google外の実装も出ています。PyPIにはCLIとLLM取り込みを持つokflib（0.5.0）や、生成前の原稿から隠しテキストやプロンプトインジェクションを検出するokf-guard（0.1.0）があります。どちらも仕様の適合を保証するものではないので、採用前に対応している版と日時形式の扱いを確認してください。

Knowledge CatalogにOKFバンドルを公開する手順と権限設計

gitに置くだけでは、バンドルをBigQueryなどの技術メタデータと同じカタログで横断検索し、そのカタログのIAMでアクセスを管理する仕組みまでは備わりません。そこを埋めるのが、Google Cloudのメタデータ基盤Knowledge Catalog（旧Dataplex）への公開です。製品そのものはKnowledge Catalog（旧Dataplex）とは：機能・料金・自己学習型コンテキスト強化とgcloud手順を実装目線で解説【2026年版】で解説しています。

公式文書が食い違う「7キー」と「13フィールド」

仕様リポジトリのconnectors/gcp-knowledge-catalog.md（8月14日以降未更新）には、今も「運ばれるのはフロントマターの7キーと本文だけ」と書かれています。一方、2026年8月26日の公式ブログと、knowledge-catalogリポジトリのtoolbox/mdcode/demo/okf（10月24日にも更新）は、独自のAspectTypeokfに13フィールドを定義しています。okf_type・generated・sources・verified・status・stale_after・usage_window、Attested Computationのruntime〜attesterの5つ、そして型に無いキーを[path, value]の組で退避するextraです。demoのREADMEはこれで「適合するバンドルなら損失なく往復できる」としています。従うべきは新しいほうで、7キーの記述は連携の初期版のものです。

kcmd pushによるEntryGroupへのバンドル公開

git clone https://github.com/GoogleCloudPlatform/knowledge-catalog
cd knowledge-catalog/toolbox/mdcode && npm install && npm run build

gcloud config set project <your-project>
gcloud config set compute/region <your-location>
gcloud services enable dataplex.googleapis.com
gcloud auth application-default login

cd demo/okf
bun run setup.ts --entry-group acme-bundle   # EntryGroup・okf-bundle・okf を作成
bun run push.ts --bundle <path/to/bundle>

setup.tsがEntryGroup、EntryTypeokf-bundle、AspectTypeokfを作り、push.tsが概念ごとに1エントリを書きます。本文はoverviewAspect、信頼シグナルはokfAspectへ入り、index.mdとlog.mdもエントリになります。acme_retailは9概念で17エントリでした。注意点は2つあります。--bundleを省くと、凍結された旧コピー側のokf/bundles/acme_retailが押されます。またpushは冪等な上書きで毎回全エントリを書き、概念を消すにはkcmd deleteかcleanup.tsが要ります。本番ではバンドルのリポジトリへのコミットごとにCIからpushする運用がブログの推奨です。

EntryGroup単位の権限管理とLookupContextのカスタムAspect非対応

読む側はroles/dataplex.catalogViewer、pushする側はroles/dataplex.catalogEditorを使い、EntryGroupのIAMがその中のエントリへ継承されます。ブログが勧めるのは「バンドルを持つチームごとに1つのEntryGroup」で、概念ごとに見せる相手を変える仕組みはありません。仕様リポジトリ側のガイドは、プロジェクトのroles/viewerがcatalogViewerの上位集合でEntryGroupの一括エクスポート権限まで含むと注意しています。機微な定義を含むバンドルは別のEntryGroupに分け、基本ロールを広く配っているプロジェクトには置かないでください。

エージェントから読むときの制約もあります。LookupContextは1回に最大10件、単一ロケーション内のエントリを解決し、本文中のリンクは辿りません。そしてカスタムAspectを描画しないため、verifiedやstale_afterはentries.get（view=ALL）で別に取る必要があります。LookupContextだけで実装すると、信頼シグナルを持たない本文だけがエージェントに渡ります。stale_afterなどの日時フィールドを検索条件に使うときは、完全な日時ではなくstale_after>2026-01-01のように日付か範囲で書く、とブログは注記しています。

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

フォーマットを採る判断と、Attested Computationに依存した仕組みを組む判断は分けてください。前者はMarkdownとYAMLのディレクトリでしかなく、専有APIもSDKも介在しません。OKFが普及しなくても、手元にはgitで差分の見える文書群が残ります。後者は仕様§12が、実行時プロトコル（レシートと判定結果のワイヤフォーマット）、attesterのABIとサンドボックス化、結果のキャッシュ、セマンティックレイヤー向けのテンプレートを「今後の版へ持ち越す」と列挙しています。契約の書き方は決まったが、走らせる側の相互運用はまだ決まっていないので、これを前提にした本番基盤は時期尚早です。

着手するならこの順です。SPEC.mdを読み、acme_retailでv0.2の書き方を確認し、既存のConfluenceや社内Wikiから1ディレクトリ分だけ文書を移してtypeとdescriptionを付ける。日時はオフセット付きで書き、パスは先頭スラッシュで書く。ここまでは無料でGCPの契約も要りません。費用が出るのは、reference agentでBigQueryを走査してクエリ課金とGeminiの利用が発生する段階と、Knowledge Catalogへ公開してGoogle Cloudのプロジェクトを使う段階からです。

見送るべき条件もはっきりしています。データカタログ製品を運用中で、権限管理と系譜がそこで完結しているなら、OKFを二重の正本にしないでください。公式READMEもDataplex・Unity Catalog・CollibraをOKFの生産者の例として挙げていて、置き換えとは言っていません。OSSカタログの構成はOpenMetadataとは？データカタログOSSの構成・導入手順・2.0移行と採用判断を解説【2026年版】、名前空間と権限継承はUnity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】にまとめています。社内知識をエージェントに読ませる仕組みを、権限設計を含めて組み立てる場合はAIエージェント開発の支援もご相談いただけます。

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

OKF v0.3やOKF 2.0はもう出ていますか？

出ていません。2026年10月26日時点の現行版はv0.2です。「OKF 2.0」「version 2」という表記を見た場合は、参照している仕様の版を確認してください。SPEC.mdの最終変更は8月21日で、v0.3のタグやブランチはありません。型付きの関係やrefuted、出典のdigestなどはIssueでの提案段階です。

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

別物です。Open Knowledge Format（OKF）はGoogle Cloudが2026年6月に公開した、AIエージェント向けの知識表現の仕様です。Open Knowledge Foundation（OKFN）はオープンデータを推進する非営利団体で、設立も目的も異なります。社内資料では「Open Knowledge Format」と省略せずに書くと混同を避けられます。

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

読めます。§13は、v0.1バンドルがv0.2の読み手から消費可能だと明記しています。timestampと# Citationsにはフォールバックがあり、追加機能はすべて任意キーです。ただし8月21日以前のv0.2の書き方でstale_afterを日付だけで書いた文書は、参照実装では陳腐化の判定から外れるので、オフセット付きの日時へ直してください。

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

正準はGoogleCloudPlatform/open-knowledge-formatです。knowledge-catalogリポジトリのokf/配下は2026年8月21日に「凍結されたスナップショット、もはやメンテナンスされない」と明記されました。v0.2発表時の公式ブログのリンク先は旧パスのままです。Knowledge Catalogへの公開手順だけは、knowledge-catalog側のtoolbox/mdcode/demo/okfが最新です。

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

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

関連記事

• Knowledge Catalog（旧Dataplex）とは：機能・料金・自己学習型コンテキスト強化とgcloud手順を実装目線で解説【2026年版】
• OpenMetadataとは？データカタログOSSの構成・導入手順・2.0移行と採用判断を解説【2026年版】
• MCPとRAGの違いとは？使い分けの判断とRAG検索をMCPツール化する実装【2026年版】
• MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説
• ナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年版】