Open Knowledge Format（OKF）とは｜Google Cloudが2026年6月公開したAIエージェント向け知識フォーマットの全体像

Open Knowledge Format（OKF）は、Google Cloudが2026年6月12日に公開した、AIエージェントと人間が同じ知識を共有するための仕様です。本記事では、OKFの定義と公開の最新状況、MarkdownとYAMLで作るバンドルの中身、MCPやllms.txt・RAGといった既存の「エージェント対応」規約との役割分担までを整理します。さらに、Knowledge Catalog（旧Dataplex）との関係や参照実装の中身、そして日本企業がv0.1段階のOKFを導入するかどうかを判断する基準まで、一次情報をもとに解説します。LLM wikiパターンに馴染みのある方も、これから検討する方も、採用判断に必要な材料がそろう構成です。

まとめ：フォーマット先行という賭けにどう向き合うか

Open Knowledge Format（OKF）は、2026年6月12日にGoogle Cloudが公開した、AIエージェント向け知識をMarkdownとYAMLフロントマターで表すベンダー中立な仕様です。必須はtypeフィールド1つだけ、SDKも専有基盤も不要という最小主義により、知識をコードと同じ作法で保守できる点が核心でした。MCP・llms.txt・AGENTS.md・RAGとは競合せず層として積み重なる関係にあり、OKFは「エージェントが行動する前に何を知っているか」を担う知識本体の層です。

現状はv0.1・Draftであり、全面採用ではなく「小さく試して学ぶ」段階です。GCP利用やエージェント開発計画、知識のポータビリティ要件に当てはまるなら、まず仕様を読み、1領域のサンプルで挙動を確かめるところから始めるのが現実的な次の一歩になります。日本語情報が乏しい今だからこそ、公式ブログとGitHubの一次情報で正確に押さえ、自社の知識資産の棚卸しと並行して検証を進めることが、フォーマット先行という賭けに賢く乗る方法です。

Open Knowledge Format（OKF）の定義と2026年6月公開という最新動向

まず「OKFとは何で、いつ・誰が・どんな目的で出したのか」という前提を確認します。新語ゆえに誤解も生まれやすいため、定義・鮮度・系譜・設計思想・略語の混同という5点を押さえます。

AIエージェント向け知識を表すベンダー中立な仕様という位置づけ

OKFは、テーブルのスキーマ、指標の定義、運用手順（ランブック）、API廃止通知といった「データやシステムを取り巻く知識」を表現するための、ベンダー中立な公開仕様です。特定のクラウド・データベース・モデル提供者・エージェントフレームワークに紐づかず、読み書きや配信に専有アカウントやSDKを要求しない点が核心です。Google ADK・LangChain・自作スクリプトのいずれで作っても、Obsidian・Notion・MkDocs・検索インデックスのいずれで読んでも成立します。つまりOKFは「知識を入れておく新しいサービス」ではなく、知識を表す共通のフォーマットそのものです。人間が読め、エージェントが解析でき、組織やツールをまたいでも壊れない表現を目指している点が、従来のメタデータカタログとの決定的な違いになります。

2026年6月12日にGoogle Cloudが公開したv0.1という鮮度

OKFは2026年6月12日に、Google CloudのData Cloudチーム（著者はSam McVeety氏とAmir Hormati氏）が公式ブログで公開しました。バージョンはv0.1、ステータスはDraftです。本記事執筆時点で公開からまだ日が浅く、完成された標準ではなく「出発点」として明言されたものです。仕様は後方互換を保ちながら拡張する前提でバージョン管理されており、今後プロデューサーとコンシューマーの実例が増えるにつれて進化するとされています。この鮮度は重要な判断材料です。日本語の本格的な解説がほぼ存在しない一方で、仕様自体が固まりきっていないため、後述する成熟度評価とセットで採用可否を考える必要があります。一次情報はGoogle Cloudブログとリポジトリ（GoogleCloudPlatform/knowledge-catalog）の2か所に集約されています。

Karpathyの「LLM wiki」パターンを標準化した設計の系譜

OKFは突然現れた発想ではなく、過去1年ほどで各所に出ていた「LLM wiki」パターンを形式化したものです。AI研究者のAndrej Karpathy氏が提唱したこの考え方は、エージェントに同じ文書を毎回検索させる代わりに、Markdownの知識ライブラリを共有して育てるというものです。要点は、人間が放棄しがちな相互参照の更新や横断的な書き換えといった「退屈な保守作業」こそ、飽きないLLMが得意とする領域だという指摘にあります。同様の発想は、コーディングエージェントに接続したObsidian保管庫、AGENTS.md・CLAUDE.mdといった慣習ファイル、エージェントが作業前に参照するindex.mdやlog.mdの集積など、別々の名前で繰り返し再発見されてきました。OKFは、これら個別実装が「協調するように設計されていなかった」点を補い、相互運用に必要な最小限の取り決めだけを定義しています。

最小限の規約に絞った3原則とプラットフォーム非依存の思想

OKFの設計は3つの原則で説明されます。第一に最小限の規約（minimally opinionated）で、全概念に求めるのはtypeフィールド1つだけ、どんな型を作るか・本文に何を書くかは作り手に委ねられます。第二にプロデューサーとコンシューマーの独立で、誰が書くか（人・エージェント・エクスポートパイプライン）と、誰が読むか（ビューア・検索・別のLLM）を分離し、両端のツールは差し替え自由です。第三にプラットフォームではなくフォーマットであり、価値は「何社がそれを話せるか」から生まれ「誰が所有するか」からは生まれない、という思想で公開されています。この3原則は、後述するベンダーロックイン回避の根拠であり、特定企業の製品に縛られず知識を持ち運べることを保証する設計上の裏づけになっています。

飲料ブランドや旧団体と混同されやすい略語「OKF」の注意点

「OKF」という略語は検索上の取り扱いに注意が必要です。日本の検索データを見ると、「OKF」はアロエドリンクやスパークリングなどの飲料ブランド名として大量に使われており、検索意図がまったく異なります。さらに英語圏では、データ公開を推進する非営利団体「Open Knowledge Foundation」も長年OKFの略語を使ってきました。Google CloudのOpen Knowledge Format（仕様）とは別物です。実際、略語が同じでも無関係なエンティティであることは、仕様の定義ページでも明示的に区別されています。そのため社内資料や記事で扱う際は、初出で必ず「Open Knowledge Format（OKF）」と正式名称を併記し、文脈を「AIエージェント向けの知識フォーマット」と限定するのが安全です。略語だけで検索・指示すると、飲料や別団体の情報が混ざる実害があります。

Markdownとフロントマターで構成されるOKFバンドルの内部構造

定義を押さえたら、次は「実際にどんなファイルの集まりなのか」です。OKFの中身は驚くほど単純で、特別なランタイムを必要としません。構造・フロントマター・リンク・予約ファイル・最小主義の5点で具体的に見ていきます。

ファイルパスが概念の識別子になるディレクトリ構造の具体例

OKFの単位はバンドルと呼ばれる、Markdownファイルのディレクトリです。1ファイルが1つの「概念」に対応し、テーブル・データセット・指標・手順書・APIなど、捉えたいものは何でも概念になります。ファイルパスがそのまま概念の識別子になる点が特徴で、たとえばsales/tables/orders.mdは「sales領域のordersテーブル」を意味します。実際の公式例では、sales/配下にdatasets/tables/metrics/といったフォルダが並び、tables/orders.mdやtables/customers.md、metrics/weekly_active_users.mdのように整理されます。ディレクトリ階層がそのまま知識の見取り図になるため、人がエクスプローラで眺めても、エージェントが辿っても理解できます。データベースをスクリプトで走査し、テーブルごとにファイルを吐くだけでも最低限のバンドルが成立します。

type必須・他は任意というYAMLフロントマターの設計

各概念ファイルの先頭には、構造化フィールドを書く小さなYAMLフロントマターが付きます。必須はtypeただ1つです。title・description・resource・tags・timestampの5つは、仕様が優先度付きで挙げる推奨フィールドですが、いずれも必須ではありません。クエリ対象にしたい少数のフィールドだけが用意され、本文は通常のMarkdownで自由に書けます。

型の体系や本文の節構成は仕様で固定されず、作り手が自由に決めます。仕様が定めるのは「相互運用の接地面」だけで、中身のデータモデルには踏み込まないという思想が、このフロントマター設計に表れています。

通常のMarkdownリンクで概念をつなぐ知識グラフ化の仕組み

概念どうしは、特別な記法ではなく通常のMarkdownリンクで相互に結ばれます。たとえばordersテーブルの説明文中で、結合先を示すために[customers](/tables/customers.md)のようにリンクを張ると、それがそのまま関係性を表す辺になります。ファイルシステムが暗黙に作る親子関係よりも豊かな、概念どうしのグラフがこうして立ち上がります。スキーマ表の外部キー説明やJoinの記述にリンクを織り込むだけで、「この指標はどのテーブルから計算するのか」「このテーブルはどこと結合するのか」という問いに、エージェントがリンクを辿って答えられるようになります。専用のグラフDBやスキーマレジストリを導入する必要はなく、GitHub上でもそのままリンクとしてレンダリングされる点が、運用負荷を下げる実務的な利点です。

順次開示のindex.mdと変更履歴のlog.mdという予約ファイル

OKFには少数の予約ファイル名があります。代表がindex.mdとlog.mdの2つです。index.mdは各階層に置く案内役で、エージェントが階層を降りていく際の「順次開示（progressive disclosure）」を担います。最初から全ファイルを読み込ませるのではなく、目次から必要な枝だけを辿らせることで、無駄なコンテキスト消費を抑えられます。log.mdは変更の時系列を記録するファイルで、いつ何が更新されたかという履歴を残します。どちらも任意であり、必要なバンドルにだけ置けば十分です。仕様書（SPEC.md）は約450行と短く、適合基準・相互リンク規則・予約ファイル名までを1ファイルにまとめた簡潔さで、こうした予約ファイルの取り決めも最小限にとどめられています。導入時はまず概念ファイルから作り、規模が大きくなった段階でindex.mdを足すのが現実的です。

catとgit cloneだけで扱える最小主義という実務的利点

OKFの最小主義は「catでファイルを開ければ読め、git cloneでリポジトリを取得できれば配れる」という一文に集約されます。複雑な圧縮方式も、新しいランタイムも、必須SDKもありません。バンドルの実体は、任意のエディタで読めるただのMarkdown、tarballで配布でき任意のgitリポジトリでホストでき任意のファイルシステムにマウントできるただのファイル、そしてクエリしたい少数の項目を支えるYAMLフロントマターの3要素だけです。スキーマレジストリも中央権威も不要で、バージョン管理上で差分（diff）も取れます。この「ツール不要で読める」性質は、属人化した知識をコードと同じ場所・同じ作法で扱えることを意味し、レビューやプルリクエストといった既存の開発フローにそのまま乗せられる点が現場での採用障壁を大きく下げます。

MCP・llms.txt・RAGなど既存エージェント規約とOKFの役割分担

ここが本記事の独自の切り口です。OKFは単独で語られがちですが、実務では既存の「エージェント対応」技術と並べて理解しないと役割を見誤ります。MCP・llms.txt・AGENTS.md・RAG・EntityMapとの違いを整理し、最後に「競合ではなく積み重なる」という考え方でまとめます。

ライブなツール接続を担うMCPと静的知識を担うOKFの違い

最も誤解されやすいのがMCP（Model Context Protocol）との関係です。一般には、両者は守備範囲が異なると整理されます。MCPはエージェントが実行時に外部ツールやデータへライブで接続するための仕組みで、「どう行動するか（how）」に関わります。対してOKFは、キュレーションされた静的な知識を表すフォーマットで、エージェントが行動する前に「何を知っているか（what）」に関わると位置づけられます。実際、OKFの仕様は提供方式やクエリ基盤を規定しないことを非目標として明記しており、実行時の接続そのものは扱わない設計です。たとえば「イベントログから週次アクティブユーザーをどう計算するか」という業務知識はOKFに置き、実際にBigQueryへ問い合わせて値を取る部分はMCP経由のツール呼び出しが担う、という分担が考えられます。OKFはこうした表層ツールの上流で行動の前提となる文脈を供給する層だと捉えると、両者はどちらか一方に置き換える関係ではないと理解できます。

道標のllms.txtや慣習ファイルAGENTS.mdとの関係整理

llms.txtやAGENTS.md・CLAUDE.mdも、OKFと競合する規約ではありません。役割が層として分かれています。下の表は、それぞれの位置づけとOKFとの関係を整理したものです。

ある論者は、llms.txtを「道標」、OKFを「図書館そのもの」と表現しています。実例として、CLAUDE.mdに「分析タスクの前に該当するOKF概念ファイルを読むこと」と書いておけば、慣習ファイルが入口、OKFが知識本体という分担が自然に成立します。

毎回検索するRAGと育てる知識ライブラリとしてのOKF

RAG（検索拡張生成）との違いも実務上の関心事です。RAGは、問い合わせのたびに文書群をベクトル検索し、関連断片を都度引っ張ってくる方式です。これに対しOKFは、同じ事実を毎回探し直すのではなく、エージェントが読んで更新しながら育てていく知識ライブラリを持たせる発想に立ちます。両者は排他ではありません。OKFのバンドルをRAGの検索対象として構造化しておけば、フロントマターやリンクという明示的な構造が検索精度を支えますし、逆にRAGで広く拾った知識を人やエージェントがOKFとして整理・固定化する運用も考えられます。「散在する文書を毎回探す」課題そのものを、整理済みの知識資産に置き換える点がOKFの主眼であり、RAGはその知識へ到達する手段の一つと位置づけられます。

コミュニティ規格EntityMapと公式仕様OKFの位置づけの違い

類似の試みとして、コミュニティ発の仕様EntityMapが知られています。Dixon Jones氏らが関わるEntityMapは、いわば「登場人物の名簿（who’s who）」にあたり、エンティティの同定に主眼があります。これに対しOKFは「図書館そのもの」、つまり知識の本体を表す層です。性格の違いも明確で、EntityMapがコミュニティの取り組みであるのに対し、OKFはGoogle Cloudの公式ブログで発表され、実在の製品であるKnowledge Catalogに組み込まれています。なお、この種のGoogle系OSSリポジトリには「公式にサポートされるGoogle製品ではない」といった定型の免責が付くのが一般的です。これはコードのサポート範囲を断る慣例的な表記とされ、フォーマットそのものが非公式であることを意味しません。OKFの仕様はGoogle Cloudが執筆し公式ブログで発表したものであり、この点を取り違えないことが大切です。

競合ではなく積み重なるという「スタックする規格」の考え方

ここまでの整理から導かれる結論は、これらの規約は奪い合うのではなく積み重なる（stack）ということです。llms.txtが入口を示し、AGENTS.mdがエージェントに作法を伝え、OKFが知識本体を提供し、MCPが実行時の接続を担い、RAGが到達手段を補う——という層構造で捉えると、自社が今どの層を持っていてどこが欠けているのかを点検できます。実際、Metaも2025年8月に、データウェアハウスの階層構造をフォルダ構造としてテキスト表現するアプローチを公開しており、「LLMはテキストで対話するため階層構造がフォルダにきれいに対応する」という直観が業界横断で共有されつつあります。OKFはその直観を、バージョン管理された公開仕様として固めた存在だと位置づけられます。どれか一つを選ぶ問いではなく、層をどう組み合わせるかという問いです。

断片化した社内知識とベンダーロックインを解くOKFの狙い

では、OKFは具体的にどんな痛みを解くために生まれたのでしょうか。多くの組織が抱える「知識の散在」と「囲い込み」という2つの問題に焦点を当て、現状・課題・ロックイン・解決アプローチ・人とエージェントの共有という観点で掘り下げます。

カタログ・Wiki・コードコメント・属人知に散らばる現状

基盤モデルが業務で使う情報の大半は、社内に閉じた知識です。テーブルの意味、自社固有の指標定義、インシデント対応手順、システム間の結合経路、古いAPIの廃止通知などが該当します。ところが現実には、これらが独自APIを持つメタデータカタログ、各種Wikiや共有ドライブ、コードのコメントやノートブックのセル、そして一部のシニアエンジニアの頭の中、といった相互に互換性のない場所に散らばっています。エージェントが一つの問いに答えるには、この断片を毎回かき集めて組み立てる必要があります。汎用的な「メタデータとは何か」という定義論ではなく、AIエージェントが実際に参照する知識がこれほど分散しているという現場の実態こそ、OKFが出発点に据えた問題意識です。

エージェントごとに知識を組み直すcontext-assembly問題

この散在がもたらす中心的な痛みが、Google Cloudがcontext-assembly problem（文脈組み立て問題）と呼ぶ現象です。新しいエージェントを作るたびに、開発者は同じ文脈組み立てをゼロからやり直すことになります。あるエージェント向けに苦労して接続したカタログやWikiの知識は、別のエージェントには引き継がれず、また一から統合が始まります。結果として、エージェントビルダーは毎回同じ課題を解き直し、カタログベンダーは似たデータモデルを再発明し、知識はそれを生んだ表層に閉じ込められたままになります。この重複作業は、組織が抱えるエージェントの数だけ膨らみます。OKFは、知識を「移動しても壊れない共通フォーマット」に置くことで、この組み立てコストを一度きりに近づけることを狙っています。

カタログ独自スキーマが生むベンダーロックインとサイロ化

もう一つの痛みがベンダーロックインです。多くのカタログ製品は、独自のAPI・独自のSDK・独自の知識グラフスキーマを持ち、そこに入れた知識は容易には他製品や他組織へ持ち出せません。Karpathy氏のwikiも、自社チームのwikiも、ベンダーのカタログエクスポートも、見た目はMarkdown・フロントマター・相互リンクで似ているのに、協調するようには設計されていない、という指摘がこれを言い表しています。どの文書にどのフィールドを持たせるべきか、どのファイル名が何を意味するかについて合意がないため、知識は元のチームの中にサイロ化します。OKFは相互運用に必要な最小限の取り決めだけを定義することで、この囲い込みとサイロ化を解く接地面を提供します。

バージョン管理に知識を同居させるメタデータ・アズ・コード

OKFが体現するのは、ドキュメントを記述対象のコードと同じバージョン管理に同居させる「メタデータ・アズ・コード（metadata as code）」という発想です。知識をMarkdownファイルとしてリポジトリに置けば、コード変更と同じプルリクエストの中で関連知識も更新でき、差分レビューの対象になります。これはデータチームで先行していた実践で、index.mdやlog.mdを作業前に参照するリポジトリ運用などと地続きです。知識を別システムの管理画面に閉じ込めるのではなく、エンジニアが日常的に触れる場所に置くことで、更新が滞りにくくなり、誰がいつ何を変えたかも追跡しやすくなります。属人化していた知識を、コードと同じ規律で保守する仕組みに変えられる点が、運用面での具体的な価値です。

人とエージェントが同じファイルを読む翻訳層なしの利点

OKFのもう一つの狙いは、人とエージェントが同じファイルを読めるようにし、間の翻訳層をなくすことです。人が手で書いたバンドルをAIエージェントが消費でき、メタデータのエクスポートパイプラインが生成したバンドルを人がビジュアライザで眺められ、あるLLMが合成したバンドルを別のLLMが問い合わせられます。フォーマットが契約であり、両端のツールは独立に差し替えられるという設計が、この双方向性を支えています。従来は「人間用ドキュメント」と「機械可読メタデータ」を別々に用意し、片方を変えるともう片方が古くなる、という二重管理が起きがちでした。OKFは同一ファイルを両者の正本とすることで、その不整合と維持コストを構造的に減らします。

Knowledge Catalogと参照実装から読み解くOKFの実装イメージ

仕様だけでは抽象的なので、Google Cloudは「作る側」と「読む側」の両方に参照実装を同梱しています。Knowledge Catalogとの連携、生成エージェント、ビジュアライザ、サンプル、そして参照実装の性格という観点で、具体的な動きをつかみます。

旧DataplexからKnowledge CatalogへのOKF取り込み対応

Google Cloudは、自社のKnowledge CatalogをOKFバンドルの取り込みに対応させ、自社エージェントへ知識を供給できるよう更新しました。このKnowledge Catalogは、長らく企業向けのデータ整備基盤として提供されてきたDataplex（Universal Catalog）を改称・発展させたもので、Google Cloud Next ’26で発表されました。AIエージェント向けに「常時稼働する企業向けの文脈エンジン（universal context engine）」と位置づけ直されています。すでにGoogle Cloud上でデータ基盤を運用している組織にとっては、OKFを企業内に展開する最短路がこの製品経由になります。ただし、ここで重要なのは順序です。OKFはあくまで公開フォーマットであり、Knowledge Catalogはそれを取り込む一実装にすぎません。GCPを使っていない組織でも、OKF自体はファイルとして単独で扱えるため、特定製品の採用が前提になるわけではない点を押さえておきましょう。

BigQueryを走査しOKF文書を生成する2段階の生成エージェント

作る側の参照実装が、BigQueryデータセットを走査するenrichment agent（拡充エージェント）です。動きは2段階で構成されます。まず第1段階で、対象データセットのテーブルやビューを一つずつ巡回し、それぞれにOKFの概念ファイルの下書きを生成します。続く第2段階で、別のLLMが権威ある公式ドキュメントをクロールし、各概念に引用・スキーマ・結合経路を補って内容を充実させます。これにより、ゼロから人手で書かずとも、既存のデータウェアハウスから一定品質のバンドルを自動生成できます。ただしこれはOKFを生む一つの方法を示すデモであり、フォーマット側が特定のエージェントフレームワークやLLMを要求するわけではありません。自社では別の生成手段を選んでも、出力がOKFに準拠していれば問題なく流通します。

データが外に出ない単一HTMLビジュアライザという消費側の例

読む側の参照実装が、任意のOKFバンドルをインタラクティブなグラフ表示に変換する静的HTMLビジュアライザです。特徴は、単一の自己完結したHTMLファイルとして動くことです。バックエンドが不要で、閲覧側に何かをインストールする必要もなく、データがページの外に出ないため、機密性の高い社内知識でも安心して可視化できます。概念どうしのMarkdownリンクがそのまま辺として描画され、知識グラフを目で辿れます。これも消費側の一例にすぎず、OKFがHTMLやグラフ表示を要求しているわけではありません。検索インデックスに食わせる、エージェントのコンテキストに読み込ませる、Obsidianで開くなど、消費の形は自由です。閲覧用途であれば、まずこのビジュアライザに自社バンドルを通してみるのが、構造を直感的に把握する近道になります。

GA4・Stack Overflow・Bitcoinの3つのサンプルバンドル

仕様を具体化するため、すぐ閲覧できるサンプルバンドルが3種類リポジトリに同梱されています。GA4のeコマースデータ、Stack Overflow、Bitcoinの各公開データセットを題材に、参照エージェントが生成し、適合するOKFの生きた実例としてコミットされたものです。たとえばBitcoinの公開データセットはおよそ10分ごとに更新される性質を持ち、こうした実データをどのように概念ファイルへ落とし込むか、クエリや注意点とあわせて確認できます。抽象的な仕様書を読むより、これらのサンプルでファイル構成・フロントマター・リンクの実際を眺めるほうが、自社データへの当てはめをイメージしやすいはずです。導入検討の初手として、まず3つのサンプルをgit cloneして構造を観察することをおすすめします。

特定フレームワークに依存しないPoCという参照実装の性格

ここまで挙げた生成エージェント・ビジュアライザ・サンプルは、いずれも意図的なPoC（概念実証）として公開されています。Google Cloud自身が「フォーマットそのものが貢献であり、ツール群は実際に試す敷居を下げるために存在する」と述べている通り、これらは唯一の正解ではありません。生成側がこのエージェントである必要も、消費側がHTMLグラフである必要もなく、プロデューサーとコンシューマーのエコシステムが同梱物を超えて広がることが期待・歓迎されています。この性格を理解しておくと、採用判断を誤りません。つまり「Googleの参照実装をそのまま本番採用するか」ではなく、「自社のソースと消費先に合わせてプロデューサー／コンシューマーを用意し、OKFという共通フォーマットで橋渡しする」という発想で評価するのが正しい向き合い方です。

日本企業がv0.1のOKF導入を判断するための手順と基準

最後は実務の意思決定です。v0.1という未成熟さをどう見るか、どう小さく始めるか、既存資産をどう移すか、何を基準に採用を決めるか、そして今動く意味は何か——判断に必要な5つの観点を示します。

Draftかつ後方互換成長を前提としたv0.1の成熟度評価

採用判断の出発点は、OKFがv0.1・Draftであるという事実の冷静な評価です。完成標準ではなく出発点として明言されており、今後の実例蓄積に応じて進化します。一方で仕様は後方互換を保ちながら拡張する前提で設計されているため、今書いたバンドルが将来まるごと無駄になる可能性は相対的に低いと考えられます。判断としては、ミッションクリティカルな本番系の唯一の知識基盤として全面採用するのは時期尚早ですが、フォーマットが極めて単純（ただのMarkdownとファイル）であるがゆえに、試して合わなければ捨てるコストも小さい、という非対称性を踏まえるのが現実的です。つまり「大きく賭ける」のではなく「小さく試して学ぶ」段階だと位置づけ、仕様のバージョン更新を追える体制を前提に検討するのが妥当です。

仕様読了から参照実装の試用まで小さく始める導入手順

大がかりな移行をいきなり計画する必要はありません。Google Cloud自身が推奨する始め方は、次の順序です。

1. 短い仕様書（SPEC.md）を読む
2. 自社のソースシステム（DB・ドキュメントサイト・既存カタログ）に対応するプロデューサーを書く
3. 消費側（ビューア・検索インデックス・バンドルを推論するエージェント）を用意する
4. 参照実装を自社データに当てて挙動を検証する

そのうえで、課題やプルリクエスト、拡張提案をリポジトリに送ることも歓迎されています。最初の一歩は仕様を読み、同梱サンプルを1つ自社の小さなデータ領域に当てはめてみることです。1領域のテーブル群だけを対象に小さなバンドルを作り、ビジュアライザで眺める——この往復だけでも、自社にとっての有用性を低コストで見極められます。

Confluenceや社内Wikiからの知識資産の棚卸しと移行

導入を具体化するなら、まず自社の知識資産の棚卸しから始めます。日本企業では、Confluenceや社内Wiki、共有ドライブ、データカタログ、コードコメントなどに知識が分散しているのが典型です。これらのうち、AIエージェントに繰り返し参照させたい知識（主要テーブルの意味、指標定義、結合経路、運用手順など）を洗い出し、概念単位のMarkdownファイルへ写し替えていきます。既存カタログからのエクスポートをプロデューサー経由でOKFに変換する経路も想定されています。注意点は、いきなり全社の知識を移そうとしないことです。利用頻度が高く、かつ陳腐化しやすい知識から優先的に移し、log.mdで更新履歴を残す運用に乗せると、移行と保守が両立します。汎用的な用語定義の網羅ではなく、エージェントの意思決定に効く知識に絞るのが成功の分かれ目です。

GCP利用とエージェント計画から見る採用判断のチェック項目

自社が今OKFを検討すべきかは、いくつかの条件で見極められます。次の項目に多く当てはまるほど、検討の優先度は高まります。

• GCPやBigQueryを既に利用しており、Knowledge Catalog経由の最短路が使えるか
• AIエージェントや社内アシスタントの開発計画が具体的に存在するか
• 知識を組織やツール間で持ち運べること（ポータビリティ）が要件になっているか
• 社内Wikiやカタログがサイロ化し、知識を再利用しにくい実感があるか

逆に、エージェント開発の予定がなく、知識の囲い込みにも困っていない段階であれば、いま急いで導入する必然性は薄いといえます。条件を満たさない場合は、仕様の動向だけ追っておき、エージェント開発が現実化した時点で再評価するのが合理的です。

日本語情報が乏しい今の先行メリットと一次情報での検証

最後に、いま動く意味についてです。本テーマは公開からまだ日が浅く、日本語の本格的な解説がほとんど存在しません。これは、社内ナレッジや技術発信において先行できる余地が大きいことを意味します。一方で、新しさゆえに二次情報には誤りや誇張も混じりやすいため、検証は一次情報に当たるのが鉄則です。具体的には、Google Cloud公式ブログとGoogleCloudPlatform/knowledge-catalogリポジトリのSPEC.mdという2か所が出発点になります。「OKF」という略語だけで検索すると飲料ブランドや別団体の情報が混ざるため、正式名称で確認することも前述の通り重要です。情報が乏しい今こそ、一次情報で正確に押さえ、自社の文脈に翻訳して発信・実装することが、先行者としての具体的な利点につながります。

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

OKFは新しい概念のため、略語の混同や既存技術との関係について疑問が生まれがちです。ここでは、検討段階でよく挙がる5つの質問に簡潔に答えます。

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

いいえ、別物です。本記事で扱うOKFは、Google Cloudが2026年6月に公開した知識表現の仕様「Open Knowledge Format」です。一方のOpen Knowledge Foundationは、オープンデータを推進してきた非営利団体で、同じ略語を長年使ってきましたが、両者に直接の関係はありません。略語が同じでも無関係なエンティティであることは公式の定義でも区別されています。さらに日本では「OKF」がアロエドリンクなどの飲料ブランド名としても広く使われているため、検索や社内共有の際は必ず正式名称「Open Knowledge Format」を併記し、文脈を明確にすることをおすすめします。

OKFを使うのにGoogle Cloudの契約は必要ですか？

必要ありません。OKFは「プラットフォームではなくフォーマット」として設計されており、読み書きや配信に専有アカウントやSDKを要求しないことが明言されています。実体はただのMarkdownファイルの集まりなので、テキストエディタとgitがあれば作成・閲覧・配布が可能です。GitHub上でもそのまま表示できます。ただし、すでにGoogle Cloudでデータ基盤を運用している場合は、OKF取り込みに対応したKnowledge Catalog（旧Dataplex）経由で社内に展開するのが最短路になります。あくまでそれは便利な一実装であって、OKFそのものの利用条件ではありません。

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

二者択一ではなく、併用が前提と考えるのが適切です。RAGは問い合わせのたびに文書を検索して関連断片を取り込む手段で、OKFはエージェントが読んで育てる整理済みの知識ライブラリを持たせる発想です。OKFのバンドルはフロントマターやリンクで構造化されているため、これをRAGの検索対象にすれば検索精度を支えられます。逆にRAGで広く拾った知識を、人やエージェントがOKFとして整理・固定化する運用も考えられます。OKFは「散在文書を毎回探す」課題を整理済み資産へ置き換える狙いを持ち、RAGはその知識へ到達する手段の一つ、という位置づけです。

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

全面的な本番採用は時期尚早ですが、限定的な試用は十分に現実的です。OKFはv0.1・Draftで、完成標準ではなく出発点と明言されています。一方で仕様は後方互換を保って拡張する前提で、形式が極めて単純なため、試して合わなければ捨てるコストも小さいという特徴があります。したがって、ミッションクリティカルな唯一の知識基盤として一気に依存させるのではなく、利用頻度の高い1領域に小さなバンドルを作って検証する、という入り方が安全です。仕様のバージョン更新を追える体制を前提に、段階的に範囲を広げていくのが妥当な進め方になります。

OKFバンドルはどのように作成すればよいですか？

主に3つの作り方があります。1つ目は人手で書く方法で、概念ごとにMarkdownファイルを作り、先頭にtypeを含むYAMLフロントマターを付けるだけです。2つ目は生成エージェントを使う方法で、Google Cloudの参照実装ではBigQueryのテーブルやビューを走査し、2段階のLLM処理で引用やスキーマを補って自動生成します。3つ目は既存カタログやデータベースからエクスポートし、プロデューサーでOKFへ変換する方法です。最初の一歩としては、同梱されているGA4・Stack Overflow・Bitcoinのサンプルバンドルを取得して構造を観察し、自社の小さなデータ領域で手書きの1バンドルを試すのが分かりやすい入り方です。