--- title: "Open Knowledge Format（OKF）とは？Googleのv0.2仕様とRAGとの違い【2026年10月】" url: "https://www.issoh.co.jp/tech/details/12530/" published: 2026-06-15 updated: 2026-10-26 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # 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-06-12 | OKF一式の初回コミット（v0.1） | 旧リポジトリ PR #28 | | 2026-06-12 | v0.1の公式ブログ公開 | Google Cloud Blog | | 2026-07-24 | 仕様とツールをv0.2へ移行 | 旧リポジトリ PR #227 | | 2026-07-24 | v0.2の公式ブログ公開 | Google Cloud Blog | | 2026-08-21 | 日時の形式をオフセット付きに統一 | 新リポジトリ PR #6 | | 2026-08-21 | 旧コピーを凍結し専用リポジトリへ誘導 | 旧リポジトリ PR #324 | | 2026-08-26 | Knowledge Catalog連携の公式ブログ公開 | Google Cloud Blog | 2026年6月に公開されたv0.1を前提とする解説と、現行のv0.2を扱う解説は区別して読む必要があります。専用リポジトリ[GoogleCloudPlatform/open-knowledge-format](https://github.com/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](https://github.com/GoogleCloudPlatform/open-knowledge-format/issues/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 # 任意。更新履歴 .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](https://github.com/GoogleCloudPlatform/open-knowledge-format/issues/29)がこの食い違いを指摘しています。どちらに決着しても壊れないのは**`/policies/margin-standard.md`と先頭スラッシュを付ける書き方**です。 ## v0.2の信頼シグナル：sources・generated・verified・status・stale\_after [v0.2の公式ブログ](https://cloud.google.com/blog/products/data-analytics/okf-v0-2-adds-trust-signals)は、エージェントが書いた知識を使う側が答えるべき問いを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種類です。エージェントやツールは`/`、人は`human:`、自動処理は`process:`。読み手はここからトラストティアを導きます。`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 v0.2 | Markdown＋YAML | 知識の本体と信頼シグナル | gitリポジトリ等 | | RAG | 実装方式 | 問い合わせ時の検索と注入 | ベクトルDB等 | | MCP | JSON-RPC | ツールとデータ源への接続 | 実行時のサーバー | | llms.txt | Markdown | 公開サイトの道標 | 公開ドメイン直下 | OKFは検索の仕組みではなく、検索される側の中身の形式です。OKFバンドルをRAGの取り込み元にもできますし、小さければLLMのコンテキストへ丸ごと読み込めます。READMEが挙げる読み手も「静的ファイルサーバー」「Obsidian・Notion・MkDocsのような知識管理UI」「ファイルを読み込むLLM」「検索インデックス」で、特定の検索方式に寄せていません。RAGとMCPの組み合わせ方は[MCPとRAGの違いとは？使い分けの判断とRAG検索をMCPツール化する実装【2026年版】](/tech/details/15347/)で、公開サイト向けの道標であるllms.txtは[llms.txtとは？書き方・設置方法とv2の変更点、Googleが効果なしとする理由【2026年9月】](/column/details/6984/)で扱っています。 ### Karpathy LLM Wiki・AGENTS.md・Agent Skillsとの関係 [v0.1の公式ブログ](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing)は、エージェントに共有のMarkdownライブラリを持たせて育てる発想を、Andrej Karpathyが[LLM Wikiのgist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)で「最も明快に述べている」と名指ししています。同じブログは、同様のパターンとしてObsidianの保管庫、「AGENTS.md / CLAUDE.mdの系統の規約ファイル」、データチームのMetadata as Codeリポジトリを挙げ、「どれも個別仕立てで、連携するよう設計されていない」と続けます。OKFはその共通部分、つまり各文書が持つべきフィールドとファイル名の意味を決めるための仕様です。 違いは読み手と粒度にあります。[AGENTS.md](https://agents.md/)は自身を「エージェントのためのREADME」と説明するファイルで、コーディングエージェント向けの手順や文脈を書き、大きなリポジトリではサブプロジェクトごとに入れ子で置けます。Agent Skillsは`SKILL.md`に作業手順とスクリプトを束ねる形式で、詳細は[Agent Skillsとは？SKILL.md仕様とAAIF寄贈後も移植性を保つ実装手順](/tech/details/17685/)にまとめています。OKFは「何をするか」ではなく「組織が何を知っているか」を、テーブル・指標・方針の概念ごとに1ファイルで書き、出所と確認履歴を付けます。手順はAGENTS.mdやSkillに、定義と根拠はOKFに、と分けるのが素直です。個人のノートをLLMで育てる用途なら、[Personal Knowledge Base（PKB）とは？パーソナルナレッジベースの定義とローカルLLMで組む手順【2026年10月】](/tech/details/15990/)の構成のほうが軽く済みます。 ## 参照実装の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 . \ --web-seed-file \ --out ./bundles/ ``` 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/ ``` バンドル直下に`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年版】](/tech/details/15750/)で解説しています。 ### 公式文書が食い違う「7キー」と「13フィールド」 仕様リポジトリの`connectors/gcp-knowledge-catalog.md`（8月14日以降未更新）には、今も「運ばれるのはフロントマターの7キーと本文だけ」と書かれています。一方、[2026年8月26日の公式ブログ](https://cloud.google.com/blog/products/data-analytics/scale-okf-bundles-across-an-organization-with-knowledge-catalog)と、knowledge-catalogリポジトリの`toolbox/mdcode/demo/okf`（10月24日にも更新）は、独自のAspectType`okf`に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 gcloud config set compute/region 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 ``` `setup.ts`がEntryGroup、EntryType`okf-bundle`、AspectType`okf`を作り、`push.ts`が概念ごとに1エントリを書きます。本文は`overview`Aspect、信頼シグナルは`okf`Aspectへ入り、`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年版】](/tech/details/16132/)、名前空間と権限継承は[Unity Catalogとは？3レベル名前空間と権限継承・移行判断を実装視点で解説【2026年版】](/tech/details/16134/)にまとめています。社内知識をエージェントに読ませる仕組みを、権限設計を含めて組み立てる場合は[AIエージェント開発](/service/ai/agent/)の支援もご相談いただけます。 ## 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年版】](/tech/details/15750/) - [OpenMetadataとは？データカタログOSSの構成・導入手順・2.0移行と採用判断を解説【2026年版】](/tech/details/16132/) - [MCPとRAGの違いとは？使い分けの判断とRAG検索をMCPツール化する実装【2026年版】](/tech/details/15347/) - [MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説](/tech/details/5736/) - [ナレッジベースとRAGの違い｜社内文書をAmazon Bedrockで検索させる設計と権限制御【2026年版】](/tech/details/4317/) --- 出典: [Open Knowledge Format（OKF）とは？Googleのv0.2仕様とRAGとの違い【2026年10月】]()（株式会社一創）