Open Knowledge Formatをエージェント用ナレッジ形式として読む

形式をそろえるための仕様

Open Knowledge Format (OKF) は、AIエージェントに渡す業務知識やデータ文脈を、Markdownファイル群とYAML frontmatterで表現するための最小仕様。Google Cloudは2026-06-13にOKF v0.1を紹介し、断片化した社内知識、データカタログ、wiki、runbookを、特定ベンダーやSDKに閉じない形式で交換できるようにする狙いを説明している。

実務で見るべき点は「新しいナレッジDB」ではなく「エージェントが読めるリポジトリ規約」に近いこと。Obsidian vault、AGENTS.md、CLAUDE.md、data catalog export、runbook repoのような既存のMarkdown運用に、相互運用のための薄い共通ルールを足す発想として読むと使いやすい。

bundle、concept、frontmatter

OKFのbundleはディレクトリツリーで、各conceptは1つのMarkdownファイルとして置かれる。conceptはテーブル、API、metric、playbook、business processなど、知識として扱いたい単位でよい。

読める、diffできる、移せる

OKFの強みは、エージェント用のcontextを「読める、diffできる、移せる」単位に落とすことにある。社内の重要知識は、データカタログ、wiki、shared drive、コードコメント、個人の頭の中に分散しやすい。OKFはそこに新しい専用サービスを足すのではなく、Markdown、YAML、gitという既存の運用単位へ寄せる。

1. BigQuery tableやdatasetに、schemaだけでなくbusiness meaning、join path、注意点を添える。
2. metric、API、runbook、incident playbookを、エージェントが探索できる単位に分ける。
3. 人がreviewできる形で、LLMやmetadata pipelineに知識ファイルを生成・更新させる。
4. vendor-specificなcatalogやwikiから、別のagent/toolへ渡す中間形式にする。

v0.1 draftとして扱う

OKF v0.1はdraftであり、完成した標準というより、相互運用のための最初の合意面と見るのがよい。conformanceもかなり寛容で、非予約Markdown fileにparse可能なfrontmatterと非空のtypeがあること、予約fileが仕様の構造に沿うことが中心。

unknown type、unknown field、broken link、missing indexはconsumer側が拒否しない前提になっている。これは導入しやすい一方で、よい分類、よい粒度、正しいcitation、更新責任までは自動で解決しない。

採用時に決めるべきことは、concept type、review責任、citationとして許すsource、生成agentの出力を止めるgate。

このvaultでは小さく試す

Obsidian vaultやCodex向けskill memoryの運用に近い領域では、OKFはすぐ全面導入するより、次のような小さな規約として試すのがよい。

1. agentが繰り返し参照する知識だけ、type、title、description、tagsを揃える。
2. index.md相当の目次を、深いfolderではなく浅いtopicごとに置く。
3. 重要な主張にはSourcesやCitationsを残し、agentが根拠へ戻れるようにする。
4. 生成物はgit diffでreviewできるMarkdownに寄せる。

OKFは、知識管理をきれいに作り直す口実ではなく、agentが迷わず読める最低限の契約を置くための仕様として扱うのが現実的。

参考資料