Google、Open Knowledge Formatを公開 - AIエージェント向け知識共有標準
(cloud.google.com)- 異なる作成者が書いたWikiを翻訳なしで複数のエージェントが利用できるようにするベンダー中立のオープン仕様で、LLM-wikiパターンを移植可能かつ相互運用可能な形式として定式化
- OKF v0.1は知識をYAML frontmatterを含むMarkdownファイルのディレクトリとして表現し、複雑な圧縮方式・新しいランタイム・必須SDKなしで動作
- 組織内の知識がメタデータカタログ、Wiki、コードコメント、一部のシニアエンジニアの頭の中など断片化したシステムに散在しており、エージェントは毎回同じコンテキスト組み立て問題をゼロから解かなければならない
- 新しい知識サービスではなくフォーマットそのものが解決策であり、誰でもSDKなしで生成でき、統合なしで利用でき、バージョン管理でコードと一緒に管理可能
- オープン標準として公開され、作成者・利用者エコシステムの拡大を通じて価値が決まる構造
背景: 断片化したコンテキスト環境
- 基盤モデルが進化しても、関連コンテキストの不足により、特にエージェントシステム構築時には性能が制限される
- コード作成、文書要約、データセット分析は可能でも、正確で実行可能な結果を出すには正しい情報が必要
- 組織でモデルが利用する情報の大半は内部知識であり、テーブルスキーマ、ビジネス指標の意味、インシデント対応ランブック、2つのシステム間の結合経路、旧APIの廃止告知などが該当
- このような知識単位が散在するシステムの例
- 独自APIを持つメタデータカタログ
- Wiki、サードパーティーシステム、共有ドライブ
- コードコメント、docstring、ノートブックのセル
- 一部のシニアエンジニアの頭の中
- 「イベントストリームから週間アクティブユーザー(WAU)をどう計算するか」という質問に答えるには、エージェントが相互互換性のない表面から答えを組み立てる必要がある
- すべてのベンダーが独自カタログ、独自SDK、独自のナレッジグラフスキーマを提供し、知識は製品・組織間で移植されない
- 結果として、すべてのエージェント開発者が同じコンテキスト組み立て問題を繰り返し、カタログベンダーは同じデータモデルを再発明し、知識はそれを生成した表面に閉じ込められる
生きたWikiとしての知識
- 開発チームは、同じ文書で同じ事実を繰り返し検索する代わりに、時間とともに有用性が増す共有Markdownライブラリをエージェントに提供する形へ移行
- エージェントが自分でファイルを読み更新する雑務を担い、チームはコンテンツをキュレーションし、コードのように管理する
- Andrej KarpathyがLLM Wiki gistでこのアイデアを提示
- 「LLMは退屈せず、相互参照の更新を忘れず、一度に15ファイルを扱える」と説明
- 人が個人Wikiを諦めてしまう台帳管理(bookkeeping)作業こそ、LLMが得意な仕事
- 同じ知識Wikiパターンがさまざまな名前で繰り返し登場
- コーディングエージェントと接続されたObsidian vault
- AGENTS.md / CLAUDE.md系の慣習ファイル
- エージェントが作業前に参照するindex.md、log.mdアーティファクト格納庫
- データチーム内部の「metadata as code」リポジトリ
- パターンは強力だが、各事例が**個別最適化された(bespoke)**ものであるという限界がある
- Markdown、frontmatter、相互リンクなど形は似ていても、協調動作するようには設計されていない
- すべての文書が持つべきフィールドやファイル名の意味について合意がなく、知識は元のチーム内にサイロ化され、新しいエージェント構築時に重複作業が発生する
必要なのはサービスではなくフォーマット
- 解決策は別の知識サービスではなく、知識を表現するフォーマットであり、次の要件を満たす必要がある
- 誰でもSDKなしで生成できる
- 誰でも統合なしで利用できる
- システム・組織・ツールをまたいで移動しても保持される
- 説明対象のコードとともにバージョン管理に存在する
- 人が読めてエージェントが解析可能で、翻訳レイヤーなしに同じファイルを利用できる
- OKFは設計上、この要件を満たすフォーマット
OKFの動作方式: 1画面に収まる設計
- OKF**バンドル(bundle)は概念(concept)**を表すMarkdownファイルのディレクトリで、テーブル・データセット・指標・プレイブック・ランブック・APIなど、捉えたいあらゆる対象を含む
- 各概念は1つのファイルであり、ファイルパスが概念の識別子となる
- ディレクトリ構造の例: sales配下にdatasets、tables、metricsフォルダとorders.md、customers.md、weekly_active_users.mdなどを配置
- 各概念文書は、構造化フィールドのためのYAML front matterブロックと、残りを記述するMarkdown本文で構成される
- front matterフィールド例: type(BigQuery Table)、title(Orders)、description、resource(コンソールURL)、tags([sales, revenue])、timestamp(2026-05-28T14:30:00Z)
- 本文にはSchema(order_id、customer_idカラムと型・説明)、Joins(customer_id基準でcustomersを結合)などを含む
- 概念同士は通常のMarkdownリンクで接続され、ディレクトリをファイルシステムの親子関係より豊かなグラフへ変換する
- バンドルには任意でindex.md(エージェント探索時の段階的開示)とlog.md(変更履歴)を含められる
- v0.1の完全仕様は、適合性基準、相互リンク規則、少数の予約ファイル名を含めて1ページに収まる
設計の3つの原則
-
最小限の規定(Minimally opinionated)
- OKFがすべての概念に要求するのは1つだけ、typeフィールド
- どのtypeを定義するか、どのフィールドを追加するか、本文にどんなセクションを置くかは作成者に委ねられる
- 仕様は相互運用の表面を定義するだけで、コンテンツモデルは規定しない
-
作成者/利用者の独立性(Producer/consumer independence)
- 知識を書く主体と利用する主体を明確に分離
- 人が手で書いたバンドルをAIエージェントが利用し、メタデータ出力パイプラインが生成したバンドルをビジュアライザーで探索し、あるLLMが合成したバンドルを別のLLMが問い合わせ可能
- フォーマットが契約であり、両端のツールは独立して置き換えられる
-
プラットフォームではなくフォーマット(Format, not platform)
- 特定のクラウド・データベース・モデルプロバイダー・エージェントフレームワークに依存しない
- 読み取り・書き込み・配信に独占的なアカウントやSDKを要求しない
- 知識フォーマットの価値は所有者ではなく、どれだけ多くの主体がそのフォーマットを使うかによって生まれるため、オープン標準として公開
仕様とともに提供されるもの
- フォーマットを具体化するため、作成者・利用者双方のリファレンス実装を公開
- Enrichment agent: BigQueryデータセットを巡回してすべてのテーブル・ビューに対するOKF概念文書を下書きし、その後の第2段階LLMパスで公式文書をクロールして引用・スキーマ・結合経路で各概念を補強
- 静的HTMLビジュアライザー: 任意のOKFバンドルを自己完結型の単一ファイルによるインタラクティブなグラフビューへ変換し、バックエンド不要・閲覧側のインストール不要・データはページ外に出ない
- すぐに探索できる3種類のサンプルバンドル: GA4 e-commerce、Stack Overflow、Bitcoin公開データセットをリファレンスエージェントが生成し、適切なOKFの生きた例としてリポジトリにコミット
- これらは意図的に**概念実証(proof of concept)**として提供
- エージェントはOKF生成の1つの方法を示すだけで、特定のフレームワークやLLMを要求しない
- ビジュアライザーは利用方法の1例を示すだけで、HTMLやグラフビューを要求しない
- 作成者・利用者エコシステムが提供範囲を大きく超えて成長することを期待
今後の方向性
- OKF v0.1は完成した標準ではなく出発点であり、より多くの作成者・利用者が現れ、エージェントが実際に必要とする知識表現を学びながら進化していく
- 知識カタログ、補強パイプライン、AIエージェント向けWikiなど何を作るにしても、初日からオープンに公開してこそフォーマットとして意味を持つ
- 推奨される行動
- 仕様を読む(短い)
- ソースシステム・データベース・文書サイト向けの**作成者(producer)**を書く
- ビューアー、検索インデックス、バンドル上で推論するエージェントなど**利用者(consumer)**を書く
- 自社データにリファレンス実装を適用する
- Issueの起票、PRの送信、拡張提案を行う(仕様はバージョン管理され、下位互換のある成長を想定して設計されている)
- リポジトリ・仕様・サンプルバンドルはGitHubで公開されており、Google CloudのKnowledge CatalogがOKFを収集してエージェントに配信できるよう更新された
- 提供の中心はフォーマットそのものであり、付属ツールはそれを現実のものにし、試行コストを下げるためのもので、OKFは将来の知識交換における**共通語(lingua franca)**として設計されている
2件のコメント
.claudeと.agentを取り込めなかった者の最善策、といったところかHacker Newsの意見
このOKF仕様のシンプルさは良いが、すべてを「ただのMarkdown」でうまく表現できるかは確信が持てない
最近は、AIが効果的かつトークン効率よく共同で貢献できるように概念を表現する方法に関心があり、たいていは何かを半構造化された逐次テキストとしてうまく表す方法を探すことになる。ただ、その過程で人間が見る知識表現の体験を犠牲にしてはいけない
特に従来は開発者でない役割まで貢献する必要があるなら、「変なテキスト形式 + git」は、今使っている作成・可視化ツールよりずっと悪く感じられる可能性が高い
今後数年で、さまざまな種類の知識を意味的に表現する標準がどう現れてくるのか楽しみだ
参考になる成功例としては、スキーマ/E-R向けのDBML、アーキテクチャ向けのLikeC4、Mermaidのようなdiagram-as-code方式がある。LLMもこうした形式はよく理解するし、短いEBNFプロンプトで教えることもできる。重要なのは、これらにも人間が見やすい可視化形態があり、Markdown内の
code blockとして自然言語のすぐ横に入れられ、LLMが文法の記述も手伝える点ださらに難しいのは、複雑なスプレッドシートやMiroのように、空間配置や色に暗黙の意味があるものだ。まだ良い代替案は見つかっていない
データエンジニアリング領域で実際に試したものとしては、AIと人間が一緒にソース-ターゲットのマッピングや変換を扱うためのhttps://equalexperts.github.io/satsuma-lang/がある。自然言語を許容する簡潔な構造化テキスト表現であり、優れた可視化やLSP/文法ツールも提供するため、エージェントがリネージや完全性、未定義のソースなどを推論するのに、大きな文書をトークン非効率に切り分けて見なくても済むようにしている
Markdown文書は、先頭のYAMLに
typeを追加すればOKF文書になれるMarkdownの散文やMarkdownコードブロックの中でも使え、テキストフィールドがある場所ならどこでも使える知識グラフ言語はどうだろうか
ミニマルな言語https://ddot.itでは、Markdown世界の外にあるファイル、URL、単純なラベルまでつなげられる。OKFのように、それ自体が単一の形式だ
念のため言うと、その短い仕様は私が書いた
何でもうまく表現できるわけではないという点には同意するが、それは本質を外している。Markdownは人間とAIモデルの両方にとって最小公倍数なので、勝っているように見える
10年ごとにRDF/OWLのセマンティックWeb形式を見直すのは楽しい
いつかそのうちのどこかの年が本当の年になるだろう
https://en.wikipedia.org/wiki/Semantic_Web
元記事には壊れたリンクがいくつかあったので、リポジトリを置いておく
https://github.com/GoogleCloudPlatform/knowledge-catalog
仕様: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...
私の理解では、私たちは3次元より先を見ることができないので、これは本質的に人間のための足がかりに近い
こちらがそこそこうまく整理しておけば、エージェントがMarkdownを受け取ってメモリ内にグラフ基盤を作ったり、Neo4jに保存したりできることを期待している
Markdownの方言、たとえばCommonMarkのようなものは指定されているのか？
最初の数ページをざっと見た限りでは関連する記述を見つけられなかったが、仕様ならかなり重要な部分に感じる
Googleが発表したのは、結局YAMLフロントマター付きのMarkdownだ。拍手をどうぞ。これのために15KBの仕様とは
みんなが「しまった、インデントを1つ落とした」みたいなYAMLの使い方をやめられるなら、もう少し皮肉も減るだろう
Markdownに「翻訳」しなければならなかったPDFをたくさん見てきた身としては、奇妙な選択に感じる
AIからアクセスしやすくしたい意図が大きいのは分かるが、どうせモデルを学習させるなら、なぜもっと良い形式で学習させないのか疑問だ
Markdownはかなり制約が多く、たとえばネストしたテーブルのようなものもレンダリングできない。「オープンな知識」の目的がAIなら、人間が実際には読まない形式をわざわざ使う必要があるのかも分からない
このアプローチは気に入った。階層的な知識の整理がとても好きだ
現在のClaudeの知識管理抽象化は、ほぼ全部壊れていると思う。複数のコーダーを同時に回したり、1,000個を超えるスキルを作ったりするとそれが表面化する。例: https://news.ycombinator.com/item?id=48407998
barrasindustries.com/okfind/ を見てみるとよい
OKFバンドルレジストリについてのアイデアだ