3行まとめ
このテーマをもう少し広げて見るなら、Gemini Enterprise Agent Platformの導入判断：Vertex AI移行、Agent Runtime、価格で確認すること と Google×KaggleのAI Agents Intensive Course：6月15日開始、参加前に確認すること も合わせて確認してください。OKFを知識フォーマットとして見る読者が、次にエージェント基盤やVertex AI側の導入条件を確認しやすくなります。
Google Cloud BlogとGitHub上の仕様が確認できるため、噂ではなく公開済みの提案として読む。
MarkdownファイルとYAML frontmatterで、表、指標、API、runbook、業務ルールの周辺知識を持ち運ぶ。
何をOKF化し、誰が作り、どのagentや検索基盤が読み、権限と監査をどう扱うかを先に決める。
OKFはモデルや社内wikiの置き換えではなく、AIエージェントに渡す知識を整える形式として見る。
- Google Cloudは2026年6月13日、AIエージェントや人が読める知識交換フォーマットとしてOpen Knowledge Format、OKF v0.1を公開した。公式発表とGitHub上の仕様が確認できるため、噂ではなく公式発表として扱う。
- OKFはMarkdownファイルとYAML frontmatterで、テーブル、指標、API、runbook、業務ルールの周辺知識をbundleとして持ち運ぶ考え方だ。モデルや社内wikiを置き換える製品ではなく、知識を渡す形式として読むと誤解しにくい。
- 導入判断では、どの知識をOKF化するか、誰が作り、どのagentや検索基盤が読むか、Knowledge Catalogとどう役割分担するかを先に決めたい。特に機密情報、権限、監査ログを決めないままMarkdown化するのは危うい。
OKF v0.1は、AIエージェントに渡す知識をファイルとして整える提案
- 1文脈不足
基盤モデルが高度でも、社内の業務文脈が足りないと実行しやすい回答に届きにくい。
- 2MarkdownとYAML
OKF v0.1は、Markdownファイル群とYAML frontmatterで知識を表すDraft仕様として公開された。
- 3Knowledge Catalog連携
Google Cloudは、Knowledge CatalogがOKFを取り込んでagentへ提供できるよう更新したと説明している。
- 4置き換えではない
新しいSaaS、モデル名、社内wikiの代替ではなく、知識を渡すための中立的な形式として読む。
v0.1は出発点であり、仕様や周辺ツールの更新を追いながら小さく試す段階にある。
Google Cloudが公開したOpen Knowledge Formatは、企業内に散らばるメタデータ、業務文脈、説明、参照先を、AIエージェントや人が読みやすい形で束ねるための提案だ。公式ブログでは、基盤モデルが高度になっても、必要な文脈が足りないと正確で実行しやすい結果を出しにくいという問題意識からOKFが説明されている。
まず切り分けたいのは、OKFが新しいSaaSやモデル名ではないことだ。OKF v0.1は、Markdownファイル群とYAML frontmatterを使う知識bundleの仕様であり、Google Cloudだけに閉じた独自ランタイムではない。Google Cloudの発表では、GitHub上にrepo、仕様、サンプルbundleが公開され、Knowledge CatalogがOKFを取り込んでagentへ提供できるよう更新されたことも説明されている。
公式発表として確認できること
今回確認できる事実は、Google Cloud Blogが2026年6月13日に「Introducing the Open Knowledge Format」を公開したこと、OKF v0.1の仕様がGoogleCloudPlatformのknowledge-catalogリポジトリ内に置かれていること、そしてKnowledge Catalogとの連携が公式ブログで言及されていることだ。
根拠
公式ブログは、OKFを「vendor-neutral」「agent- and human-friendly」な仕様として説明し、OKF v0.1がMarkdownファイルとYAML frontmatterのdirectoryで知識を表すと書いている。GitHubのSPEC.mdでは、Version 0.1のDraftとして、bundle、concept、frontmatter、cross-linking、index.md、log.md、conformanceの考え方が整理されている。
注意点
一方で、OKF v0.1は出発点だ。仕様書にもDraftとあり、公式ブログも今後producerとconsumerが増えながら進化すると説明している。したがって、この記事ではOKFを「完成した業界標準」とは扱わない。いま見るべきなのは、社内のAIエージェントPoCで試せる小さな知識交換フォーマットかどうかだ。
OKFが扱うのは、表、指標、API、runbook、ドキュメントの周辺知識
AIエージェントが社内データを扱うとき、足りないのはデータそのものだけではない。テーブル名の意味、指標の定義、JOIN条件、APIの制約、障害時runbook、古い仕様の廃止予定、担当部署の業務ルールなど、周辺の知識が必要になる。
OKFは、こうした知識を1つの巨大な文書に押し込むのではなく、conceptごとのMarkdownファイルとして分ける。ファイルごとにtype、title、description、resource、tags、timestampなどをYAML frontmatterで持たせ、本文側にはスキーマ、例、注意点、引用元、関連するconceptへのMarkdownリンクを書く。
確認項目
導入前には、まず対象を分けたい。OKF化の候補になるのは、BigQueryのテーブル説明、社内KPI、APIエンドポイント、インシデント対応手順、データ品質ルール、データリネージの補足説明などだ。反対に、認証情報、個人情報、契約上の非公開情報、アクセス制限を越えて読ませてはいけないログは、Markdownにしやすいからといってbundleへ混ぜない。
モデル、エージェント製品、社内wikiの置き換えではない
OKFは、GeminiやVertex AIのモデルそのものではない。agentの実行基盤でもなければ、社内wikiの完全な置き換えでもない。役割を分けるなら、OKFは「知識を持ち運ぶ形式」、producerは「既存カタログや文書からOKFを作る仕組み」、consumerは「OKFを読むagent、検索インデックス、ビューア、Knowledge Catalogなど」だ。
評価基準
導入判断では、「OKFを使うか」だけを見ない。既存のwikiやデータカタログをsource of truthにするのか、OKFを生成物として扱うのか、あるいはOKF自体をレビュー対象の知識リポジトリにするのかを決める必要がある。ここが曖昧だと、AIエージェントのために作った知識が、すぐ二重管理になる。
OKF bundleの基本形を、MarkdownとYAML frontmatterから読む
- 1bundle
Markdownファイルのdirectory treeとして知識をまとめる単位。Gitで差分を見やすく、小さなPoCを始めやすい。
- 2concept
テーブル、メトリクス、API、playbook、referenceなど、bundle内の1つの知識単位。
- 3YAML frontmatter
type、tags、resource、timestampなど、検索やフィルタに使う最小メタデータを置く。
- 4Markdownリンク
知識同士の関係を通常のリンクでつなぎ、人もagentも辿れる構造にする。
機械が読むメタデータと、人が読める本文を分けると、レビューと再利用がしやすくなる。
OKFの扱いやすさは、形式の軽さにある。SPECでは、bundleはMarkdownファイルのdirectory treeであり、conceptはbundle内の1つの知識単位と説明される。concept IDは、bundle内のファイルパスから.mdを除いたものとして扱う。
この作りは、社内の開発者やデータチームにとって見慣れたものに近い。Gitで差分を見られる。Markdownとして読める。frontmatterは検索やフィルタに使える。リンクは通常のMarkdownリンクとして書ける。新しい中央サーバーや専用SDKを前提にしないため、小さなPoCを始めやすい。
conceptごとに1つのMarkdownファイルを置く
OKFでは、テーブル、メトリクス、API、playbook、referenceなどをconceptとして扱える。たとえば、tables/orders.mdは注文テーブルのconcept、metrics/weekly_active_users.mdは週次アクティブユーザー指標のconcept、playbooks/data_freshness_alert.mdはデータ鮮度アラート対応手順のconceptにできる。
根拠
SPECは、conceptを1つのMarkdown文書として表し、物理的な資産でも抽象的な概念でもよいとしている。公式ブログでも、テーブル、データセット、メトリクス、playbook、runbook、APIのような知識をbundle化できる文脈で説明している。
YAML frontmatterは機械が読む最小メタデータ、本文は人が読める説明にする
frontmatterの必須項目はtypeだ。title、description、resource、tags、timestampは推奨項目として扱われる。重要なのは、OKFが最初から重い中央スキーマを押しつけていないことだ。type以外は、producerや組織が必要に応じて決められる。
条件
社内で使うなら、typeの粒度を先に決めたい。BigQuery Table、Metric、API Endpoint、Runbookのように担当者が理解できる値にするか、より細かく業務別に分けるかで、検索と運用のしやすさが変わる。最初からfrontmatterを増やしすぎると、OKFの軽さが消える。PoCでは、type、title、description、resource、tags、timestampの範囲から始めるのが無難だ。
Markdownリンクで知識同士の関係を作る
OKFのconceptは、Markdownリンクで互いに関係を持てる。注文テーブルから顧客テーブルへ、KPI定義から利用するテーブルへ、runbookから監視ダッシュボードや関連手順へ、通常のリンクでつなげる。consumer側は、そのリンクを知識グラフのように扱える。
注意点
リンクが増えるほど、運用上のリスクも増える。古いテーブルへリンクしたままになる、指標定義の改定が一部のconceptにだけ反映される、リンク先が存在しない、権限の違う情報へ誘導してしまう、といった問題が起きる。SPECはconsumerが壊れたリンクを許容すべきだとしているが、社内運用ではリンク切れ検査とレビュー担当を決めておきたい。
社内知識をOKF化する価値は、エージェントの失敗原因から逆算する
active user、revenue、churnなど、期間、除外条件、集計粒度が部署ごとにずれやすい指標。
同名テーブル、古いテーブル、鮮度、join pathなど、SQL生成時に誤解しやすい情報。
実行前の条件、失敗時の扱い、利用制限、参照すべき手順が必要な運用知識。
wikiやREADMEが多い組織ほど、どの文書を正とするかを決めてからbundle化する。
OKF化の対象は、管理しやすい文書ではなく、agentが間違えやすい知識から選ぶ。
OKFを検討するときは、「Markdownで管理できるから便利そう」という入口だけでは弱い。AIエージェントが今どこで失敗しているのかから逆算すると、PoCの価値が見えやすい。
たとえば、売上指標を聞くたびに違うSQLを作る、データ鮮度の確認を忘れる、同名のテーブルを取り違える、障害対応手順の前提条件を飛ばす、APIの利用制限を知らずに実行計画を出す。こうした失敗があるなら、OKFで「agentに読ませるべき知識」を小さく整理する意味がある。
テーブルや指標の意味が曖昧だと、エージェントはもっともらしい回答を作りやすい
データチームで起きやすいのは、指標名は同じでも部署によって定義が違うケースだ。active_user、revenue、churnのような言葉は便利だが、対象期間、除外条件、通貨換算、返品処理、bot除外、集計粒度がずれると別物になる。
評価基準
OKF化する価値が高いのは、定義が口頭や古いwikiに散っている指標だ。agentに「この指標はどのテーブルを使い、どの条件で集計し、どの利用目的では使ってはいけないか」を読ませられるなら、PoCの価値はある。逆に、定義が既に1つの正式カタログで管理され、agentがそこへ安全にアクセスできるなら、OKFを重ねる理由を慎重に見る。
runbookやAPI仕様は、実行前の条件と失敗時の扱いまで書く
AIエージェントに運用手順を任せる場合、手順名だけでは足りない。実行してよい権限、事前確認、停止条件、失敗時の連絡先、ロールバック、監査ログの場所まで必要になる。
確認項目
runbookをOKFにするなら、本文に「前提条件」「実行してよいロール」「確認するログ」「中止条件」「ロールバック」「関連手順」を分けて書く。API仕様なら、エンドポイント、認証方式の参照先、rate limit、利用してよい環境、サンプルリクエスト、破壊的操作の禁止条件を分ける。ここまで書かないと、agentは手順を知っているように見えて、実行判断を誤りやすい。
wikiやREADMEがある組織ほど、OKFのsource of truthを決める
既にNotion、Confluence、Google Docs、GitHub README、Data Catalog、Lookerの説明欄がある組織では、OKFが追加の置き場所になりやすい。便利だからと増やすだけでは、どれが正しいか分からなくなる。
注意点
OKFをsource of truthにするなら、更新責任とレビュー手順を置く。既存wikiをsource of truthにするなら、OKFはエージェント投入用の生成物として扱い、生成元へのリンクを必ず残す。どちらの場合も、古いbundleをagentが読み続けないよう、更新頻度と破棄手順を決める。
Knowledge Catalogとの関係は、置き換えではなく取り込み先と配信先で考える
- 1OKF
Knowledge Catalogへ入れる前後で使える、MarkdownとYAML frontmatterの知識ファイル形式。
- 2Knowledge Catalog
メタデータ、業務文脈、検索、ガバナンス、agent向け配信を束ねるGoogle Cloud側のレイヤー。
- 3取り込み
既存カタログ、SQL、API仕様、runbookからOKFへ変換し、必要に応じてKnowledge Catalogへ渡す。
- 4配信
人、検索、AIエージェント、Knowledge Catalogのどれが読むのかを先に決める。
既存カタログがある組織では、エクスポートとインポートの責任者を分けると運用責任が曖昧になりにくい。
Google Cloud文脈でOKFを読むとき、Knowledge Catalogとの関係を混同しやすい。Knowledge Catalogは、Google Cloudのデータカタログ、メタデータ、文脈、ガバナンス、検索、MCP対応を束ねるサービス側のレイヤーだ。OKFはファイル形式であり、Knowledge Catalogそのものではない。
Google Cloudの公式ドキュメントでは、Knowledge CatalogはGemini-powered data catalogとして説明され、データ資産の技術メタデータ、ビジネス文脈、データ関係をcontext graphとして扱い、AI agentsが信頼できる情報へアクセスできるようにする位置づけだ。2026年4月10日時点でDataplex Universal CatalogはKnowledge Catalogと呼ばれるようになったが、API、client library、CLI、IAM名は変わらないとも説明されている。
Knowledge Catalogは、メタデータ、文脈、検索、ガバナンスを束ねるGoogle Cloud側のレイヤー
Knowledge Catalogのoverviewでは、governance foundation、context curation、context retrievalの3つが柱として説明されている。BigQueryなどのGoogle Cloudサービスからメタデータを集め、Geminiを使ってビジネス意図やデータ関係を補い、semantic searchやMCP toolsを通じてagentやアプリケーションが文脈を取り出せるようにする、という流れだ。
根拠
公式ドキュメントは、Knowledge CatalogがBigQuery、AlloyDB for PostgreSQL、Spanner、Cloud Storage、Vertex AIなどのメタデータを扱うこと、AI agents向けにcontext retrievalを提供することを説明している。OKFの記事では、ここを「Google Cloud側で知識を管理、検索、提供するレイヤー」として読むと分かりやすい。
OKFは、Knowledge Catalogへ入れる前後で使えるファイル形式として読む
公式ブログでは、Google CloudのKnowledge CatalogがOKFをingestし、agentsへserveできるよう更新されたと説明されている。これは、OKFをKnowledge Catalogの代替物として見るより、Knowledge Catalogに取り込める外部知識や生成物の形式として見る方が自然だ。
条件
ただし、現時点で記事にできるのは公式ブログとGitHubで確認できる範囲までだ。料金、SLA、全リージョンの提供条件、企業サポート範囲、既存カタログからの正式移行手順は、この記事では断定しない。導入前には、Google Cloudの管理コンソール、Knowledge Catalogドキュメント、リリースノートで最新の提供条件を確認する必要がある。
既存カタログがある組織は、エクスポートとインポートの責任者を分ける
GitHub READMEでは、OKFを人が手で書くことも、Google ADKやLangChainなどのagent、既存カタログのexport pipeline、スクリプトで作ることも想定している。BigQueryは最初のsource implementationとして説明されているが、OKF自体は特定のデータソースだけに閉じない。
評価基準
既存のデータカタログがある組織では、誰がOKFを作るのかと、誰がOKFを読む環境へ配るのかを分けたい。producerは既存カタログ、SQL、API仕様、runbookからbundleを作る担当。consumerは検索、agent、Knowledge Catalog、ビューアなどでbundleを読む担当だ。この責任分界がないと、OKFの品質問題がagentの回答品質問題として見えてしまう。
導入判断は「今試す」「条件付きで試す」「待つ」に分ける
セキュリティや運用責任が絡むため、単純な勝敗ではなく組織の準備状況で分ける。
OKFは軽量な仕様なので、試すこと自体は難しくない。だが、簡単に試せることと、全社の知識運用へ入れてよいことは別だ。現時点では、「今試す」「条件付きで試す」「待つ」に分けて考えるのが現実的だ。
Google Cloud、Vertex AI、Gemini API周辺の導入判断では、モデルやAPIの性能だけでなく、agentが参照する文脈をどう管理するかが重要になる。モデル側の提供条件を整理するなら、Gemini 3.5 Flashの導入判断も合わせて確認したい。
今試す価値が高いケース
AIエージェントPoCをすでに進めており、社内データやrunbookを読ませる段階に入っている組織は、OKFを小さく試す価値が高い。Gitレビュー、Markdown管理、データカタログ運用に慣れているなら、1つの業務ドメインでbundleを作り、agentの回答根拠が改善するかを見られる。
条件
最初の対象は狭くする。たとえば、1つのBigQuery dataset、3つの重要KPI、1つの障害対応runbookに絞る。すべての社内知識をOKF化しようとすると、仕様検証ではなく整理プロジェクトになる。
条件付きで試すケース
既存のデータカタログやwikiはあるが、更新責任者が曖昧な組織は条件付きだ。OKFにする前に、どの情報が正式で、どの情報が参考なのかを分ける必要がある。ここを飛ばすと、AIエージェントは整理された誤情報を読んでしまう。
注意点
PoCでは、OKFにする前の棚卸しを成果物に含める。正式な表定義、古い説明、担当者メモ、未承認の運用ノウハウを同じbundleに入れない。未承認の文脈は、agentに読ませる前にレビュー対象として分ける。
まだ待つべきケース
機密情報の分類、データアクセス権限、agentの参照ログ、出力ログ、削除手順が整っていない組織は、OKF化より先に統制を整えたい。Markdownで扱える知識は、複製も検索も投入も簡単だからだ。
下振れ
最も避けたい下振れは、便利な知識bundleが社内の権限境界を越えて広がることだ。OKFは暗号化や権限管理の仕組みそのものではない。どこに保存し、誰が読めて、どのagentが参照でき、いつ削除するかは別途設計する。
PoCは1つの業務ドメインから、producerとconsumerを決めて始める
- 1業務ドメインを選ぶ
注文分析、週次レポート、障害対応など、知識の範囲を説明できる単位に絞る。
- 2producerを決める
既存カタログ、SQL、API仕様、runbookからOKFを作る人、スクリプト、agentを決める。
- 3bundleを作る
concept、resource、tags、timestamp、参照元を入れ、レビューできる形で保存する。
- 4consumerを絞る
検索、ビューア、AIエージェント、Knowledge Catalogのどれで読むのかを1つ決める。
- 5成果を見る
回答精度だけでなく、更新コスト、レビューしやすさ、根拠の追いやすさも確認する。
PoCの目的は全社標準を急ぐことではなく、知識を作って読む運用が回るかを確かめることにある。
OKFのPoCは、短くても実用的にできる。いきなり全社標準を作らず、1つの業務ドメインを選ぶ。producerとconsumerを決め、既存情報からOKF bundleを作り、agentや検索で読ませ、更新コストまで見る。
たとえば、ECの注文分析ドメインなら、注文dataset、注文テーブル、顧客テーブル、売上指標、返品処理、週次レポート作成手順をconceptにする。各conceptにresource、tags、timestamp、参照元URLを持たせる。agentには「週次売上の定義と除外条件を説明し、必要なテーブルを挙げる」といったタスクを投げる。
producerは、既存カタログ、SQL、API仕様、runbookからOKFを作る役割
producerは、人でもスクリプトでもagentでもよい。ただし、生成した文書を誰がレビューするかは必ず決める。GitHub READMEのreference agentは、BigQuery datasetを歩いてOKF concept documentを作り、さらにauthoritative documentationを参照してcitation、schema、join pathを補う例として説明されている。
確認項目
PoCでは、手書き、スクリプト生成、カタログexport、agent生成の4つを比べるとよい。手書きは品質が高いが遅い。スクリプト生成は再現性があるが文脈が薄い。カタログexportは既存資産を活かせるが形式変換が必要になる。agent生成は速いが、citationとレビューが不可欠になる。
consumerは、検索、ビューア、AIエージェント、Knowledge Catalogのどれかに絞る
OKFを作っただけでは価値は出ない。誰が読むのかを決める必要がある。人が読むなら、GitHubやMarkdownビューアで十分かもしれない。AIエージェントが読むなら、bundleの探索方法、読み込む範囲、参照ログが必要になる。Google Cloud側で扱うなら、Knowledge Catalogとの取り込み条件を確認する。
評価基準
初回PoCの合格条件は、回答精度だけにしない。人が読んで意味が分かること、agentが必要なconceptへたどれること、根拠となるsourceやcitationを確認できること、更新差分をレビューできること、古いbundleを破棄できること。この5つを見ると、運用に乗るかどうかが分かりやすい。
成果は回答精度だけでなく、更新コストとレビューしやすさで見る
AIエージェントの回答が一時的によくなっても、更新コストが高すぎるなら続かない。逆に、すべてを自動生成してレビューしないなら、誤った知識が整った形式で配布されるだけになる。
上振れと下振れ
上振れは、agentの回答に根拠が出ることだ。どのconceptを読んだか、どのsourceに基づくか、どの指標定義を使ったかが追える。下振れは、frontmatterや独自分類を増やしすぎ、OKFが事実上の独自CMSになることだ。OKFの魅力は軽さなので、最初のPoCでは形式を増やしすぎない。
ガバナンスとセキュリティは、Markdownで扱える手軽さの裏側として書く
セキュリティ、権限、監査は単純な勝敗で比較せず、扱う知識の機密度と組織の運用条件で判断する。
OKFは、MarkdownとYAMLで扱える。これは大きな利点だが、同時にリスクでもある。ファイルとしてコピーでき、検索でき、agentに読ませやすい知識は、社内の権限設計から外れると危険になる。
Google CloudのAI関連サービスを使う場合でも、OKF自体がアクセス制御や監査を自動で解決するわけではない。セキュリティ文脈では、Google AI Threat Defenseの確認点で扱ったように、AIを使う側の権限、ログ、脅威対応を分けて見る姿勢が必要だ。
機密情報や認証情報をbundleに入れないルールを先に決める
Markdownのbundleは、開発者にとって扱いやすい。だからこそ、入れてはいけない情報を先に決める。API key、OAuth client secret、個人情報、顧客別の契約条件、未公開のセキュリティ手順、社外秘の障害詳細などは、OKFに書く前に分類が必要だ。
注意点
「agentに読ませると便利そう」は、公開範囲の理由にならない。OKFのresource欄には、実データや管理画面への直接リンクを置けるが、そのリンク先を読める権限と、OKFファイルを読める権限が一致しているとは限らない。ファイルを見た人がリンク先に行けない、またはリンク先よりもOKF本文の方が機密を含む、という逆転も起きる。
agentに読ませる前に、権限境界と監査ログを決める
AIエージェントにOKFを読ませる場合、agentがどのbundleを読めるか、読んだことをどこへ記録するか、出力にsourceを出すか、誤った回答が出たときにどのconceptを修正するかを決める。
確認項目
チェックリストは単純でよい。OKFの保存場所、閲覧権限、編集権限、reviewer、agentの読み取り権限、参照ログ、出力ログ、削除手順、古いbundleの無効化、誤更新時のrollback。この10項目が答えられない場合、導入対象をさらに小さくする。
更新履歴はlog.mdやGit履歴だけに任せず、業務上の承認も見る
SPECでは、log.mdが更新履歴を記録する任意ファイルとして説明されている。Gitで管理すれば差分も追える。だが、業務上の正しさは、差分があるだけでは保証されない。
評価基準
誰が指標定義を変えられるか。変更がagent回答へ反映されるまでの時間はどれくらいか。変更後、古い回答や古いbundleをどう扱うか。承認前の修正をagentが読まないようにできるか。OKFの運用設計では、ここまで見ておきたい。
OKF v0.1で見るべき仕様ポイントを、実装前チェックリストにする
directory tree、concept document、cross-linkingの基本を押さえる。
parse可能なYAML、空でないtype、必要なmetadataを用意し、独自拡張を増やしすぎない。
agentがbundleの階層をたどる入口として扱い、重要なconceptへ到達しやすくする。
更新説明、運用監査、変更レビューに使えるように記録の粒度を決める。
根拠の参照先と、consumerが最低限読み合える条件を確認する。
OKF v0.1はすべてを同じデータモデルへ押し込む仕様ではなく、producerとconsumerが読み合うための共通構造として使う。
OKF v0.1のSPECでまず見るべき点は多くない。bundle構造、concept document、frontmatter、cross-linking、index.md、log.md、citations、conformance、versioningの順に読むと追いやすい。
社内導入では、仕様を全部使うより、最小構成で動かしてから足す方がよい。OKFが標準化しようとしているのは、知識を完全に同じデータモデルへ押し込むことではなく、異なるproducerとconsumerが最低限読み合える構造だからだ。
最小構成は小さくし、frontmatterの独自拡張を増やしすぎない
conformanceでは、非予約の.mdファイルがparse可能なYAML frontmatterを持ち、frontmatterに空でないtypeがあり、index.mdとlog.mdが定義された構造に従うことが示されている。一方で、consumerは任意項目の欠落や未知のtype、未知のfrontmatter、壊れたリンク、index.mdの欠落を許容すべきだとも書かれている。
条件
この寛容さは、運用側に自由を与える。だが、社内で自由にしすぎると検索やレビューが難しくなる。最初はtypeの候補、titleの書き方、resourceの形式、tagsの命名、timestampの更新条件だけを決め、bodyの見出しは数個の推奨に留めるのが扱いやすい。
index.mdはagentが階層をたどる入口として扱う
index.mdは、directory内の内容を列挙し、humanやagentが一度にすべてを読まなくても階層をたどれるようにするための入口だ。社内の大きなbundleでは、rootのindex.md、datasetごとのindex.md、runbookごとのindex.mdがあると、agentが必要なconceptへ絞り込みやすい。
根拠
SPECは、index.mdをprogressive disclosureのための任意ファイルとして説明している。これはagentに全bundleを渡すのではなく、まずindexを読み、必要なconceptへ移動する設計に向く。
log.mdやGit差分は、運用監査と更新説明に使う
log.mdは、更新履歴を日付順に記録する任意ファイルだ。Git差分と組み合わせれば、いつ、何を、誰が変えたかを追いやすい。ただし、監査に必要な承認フローや責任者までは、log.mdだけでは足りない。
注意点
log.mdには、変更理由、影響範囲、確認したsource、関連するissueや承認リンクを短く残すとよい。agentが古い定義で回答したとき、どの更新で変わったのか追えるようにするためだ。
需要シグナルは強いが、採用実績とは分けて読む
Google Cloud Blog、GitHub README、SPEC、Knowledge Catalog overviewは、仕様や提供条件の根拠に使う。
daily.devなどのピックアップは、関心の高さを示す補助材料として読む。
周辺文脈として扱い、OKFの仕様や採用実績を示す証拠にはしない。
導入企業数、SLA、サポート範囲、正式な移行手順は、一次情報が出るまで断定しない。
話題性は強いが、採用実績や企業向け条件は別の根拠で確認する必要がある。
今回のトピックは、Google Cloud Blogの当日公開、GitHubリポジトリとSPECの公開、外部キュレーションでの当日ピックアップが重なっている。AIエージェントに渡す知識をどう整えるかは、開発者、データチーム、Google Cloud導入企業にとって関心が高い。
ただし、需要シグナルと事実認定は分ける。daily.devなどの外部ピックアップは、読者がこの話題を知りたがっている合図として使える。OKFの仕様、提供条件、Knowledge Catalogとの関係を確認する根拠には、Google Cloud Blog、GitHub README、SPEC、Knowledge Catalog overviewを使う。
公式ブログ、GitHub、SPECは技術的根拠に使う
この記事で断定するのは、一次情報で確認できる範囲だ。OKF v0.1が公開されたこと、MarkdownとYAML frontmatterで知識bundleを表すこと、typeが必須であること、Knowledge CatalogがOKFを取り込めると公式ブログに書かれていること、Knowledge CatalogがAI agents向けのcontext retrievalを説明していること。ここまでは根拠を置ける。
根拠
Google Cloud Blog、GoogleCloudPlatform/knowledge-catalogのREADMEとSPEC、Knowledge Catalog overviewはいずれも公開資料だ。確認日は2026年6月13日JST。Knowledge Catalog overviewはページ上でLast updated 2026-06-11 UTCと表示されていることも確認した。
外部キュレーションは、関心の高さを示す補助材料にする
外部のキュレーションや専門メディアが拾うと、話題としては広がる。しかし、それだけでは企業導入が進んでいる証拠にはならない。OKF v0.1の採用実績、標準化状況、長期サポートは、今後の公式資料とGitHubの更新を見て判断したい。
注意点
「話題になっているから導入すべき」ではない。読者が見るべきなのは、自社のAIエージェントがどの知識で失敗しているか、既存カタログとwikiのどこが散らばっているか、OKF bundleで小さく整理できるかだ。
同日のAI/Agent関連更新は文脈として扱い、OKFの証拠にしない
Google CloudのAI/Agent関連更新は多い。Knowledge Catalog、MCP、agent向けのcontext retrieval、BigQueryやVertex AI周辺の更新は、AIシステムが企業内の信頼できる文脈を必要としている流れを示している。
評価基準
ただし、同じ文脈にあることと、OKFの仕様が確定したことは別だ。OKFの判断では、仕様の安定性、producerとconsumerの成熟度、Knowledge Catalog側の取り込み手順、セキュリティ運用のしやすさを追う。
更新履歴と公開後に見るもの
- 2026年6月13日JST
Google Cloud Blog、OKF README、SPEC、Knowledge Catalog overviewを確認した時点として扱う。
- SPEC更新
OKF SPECのバージョン、conformance条件、frontmatterやbundle構造の変更を見る。
- Knowledge Catalog手順
OKF取り込み手順、対応範囲、管理機能、ドキュメントの追加を確認する。
- サンプルと続報
サンプルbundle、reference agent、Google Cloudリリースノート、公式ブログの続報を追う。
料金、サポート範囲、SLA、対応リージョン、企業向け管理機能は、公式資料に追加された時点で判断を見直す。
この記事は、2026年6月13日JST時点の公開資料をもとにしている。OKF v0.1はDraftであり、GitHub上のSPECやサンプルbundle、Knowledge Catalogのドキュメントは今後変わる可能性がある。
Google Cloud関連の月次追跡は、2026年6月 重要トピックまとめにも集約している。OKFの仕様更新、Knowledge Catalogの手順追加、Google Cloud Blogの続報が出た場合は、月次ページと個別記事の両方で確認したい。
公開時点で入れる確認日
確認日は2026年6月13日JST。確認した主な情報は、Google Cloud BlogのOKF発表、GoogleCloudPlatform/knowledge-catalog内のOKF READMEとSPEC、Google Cloud DocumentationのKnowledge Catalog overviewだ。
確認項目
発表日、OKF v0.1のDraft表記、MarkdownとYAML frontmatterのbundle構造、type必須のconformance、index.mdとlog.mdの扱い、Knowledge CatalogがOKFを取り込むという公式ブログ上の記述、Knowledge Catalog overviewの最終更新日を確認した。
次回更新のトリガー
更新を見るべきトリガーは、OKF SPECのバージョン更新、conformance条件の変更、Knowledge CatalogのOKF取り込み手順の追加、Google Cloudリリースノートでの正式な機能説明、サンプルbundleやreference agentの大きな更新だ。
条件
とくに、料金、サポート範囲、SLA、正式な移行手順、対応リージョン、企業向け管理機能は、今回の一次情報だけでは断定しない。これらが公式ドキュメントに追加されたら、導入判断は変わる。
次に読むなら
参照した主な情報源
- Google Cloud Blog, "Introducing the Open Knowledge Format"（確認日: 2026年6月13日）
https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing
- GoogleCloudPlatform/knowledge-catalog,
okf/README.md（確認日: 2026年6月13日）
https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf
- GoogleCloudPlatform/knowledge-catalog,
okf/SPEC.md（確認日: 2026年6月13日）
https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
- Google Cloud Documentation, "Knowledge Catalog overview"（確認日: 2026年6月13日。ページ表示の最終更新: 2026年6月11日 UTC）
https://docs.cloud.google.com/dataplex/docs/introduction
本記事はAlphabet Inc.、Google、Google Cloudとは非提携の独立した調査記事です。製品名、サービス名、会社名は各社の商標または登録商標です。投資判断や契約判断ではなく、公式情報を読むための確認メモとして利用してください。
Google Cloud、Gemini、Vertex AI、Knowledge Catalog、AIエージェント関連の公式発表を継続して追う場合は、ニュースレターと月次まとめも合わせて確認できます。