Markdownファイルが、AI時代の負債に? Googleが提案する「ナレッジ標準化」の一手:「Open Knowledge Format」公開
Google Cloudは、AIエージェントが利用するナレッジをMarkdownで標準化するオープンフォーマット「Open Knowledge Format」を公開した。ベンダー非依存で、異なるエージェント間でもナレッジをそのまま共有できる。
Google Cloudは2026年6月12日(米国時間)、大規模言語モデル(LLM)を活用するAIエージェントが必要とするナレッジを表現するためのオープンフォーマット「Open Knowledge Format」(OKF)のバージョン0.1を公開した。
OKFは、YAMLフロントマター(YAML形式のメタデータ)を持つMarkdownファイルのディレクトリとしてナレッジを表現するフォーマットだ。ベンダーに依存しない、エージェントと人間にとって使いやすい標準規格として設計されている。
OKFの仕組み
開発チームは、AIエージェントの構築方法を変えつつある。同じドキュメントから同じ事実を何度も検索するモデルを使う代わりに、エージェントに共有のMarkdownライブラリを提供し、そのMarkdownライブラリを時間とともに洗練させ、有用性を高めていく手法だ。エージェントがファイルの読み込みや更新を担い、開発チームはコンテンツをキュレーションしてコードのように管理できる。
AI研究者のアンドレイ・カルパシー氏は「LLM Wiki」に関する記事の中で、「LLMは相互参照の更新など煩雑な管理作業を正確にこなす能力に長けており、一度に15個のファイルを処理できる」と指摘している。
同様のパターンは、ナレッジ管理アプリ「Obsidian」の保管庫、「AGENTS.md」「CLAUDE.md」といったエージェント向け規約ファイル、データチームの「Metadata as Code」リポジトリなど、さまざまな名称で繰り返し現れている。だが、それぞれの事例は個別にカスタマイズされており、システム間で意図的に連携するよう設計されているわけではない。
OKFはこの問題をサービスではなくフォーマットで解消しようとする取り組みだ。
SDK(ソフトウェア開発キット)や事前統合なしで誰でも作成・利用でき、システムや組織、ツール間をまたいで機能し、記述対象のコードとともにバージョン管理できる形式を目指している。人間が読みやすく、エージェントが解析可能な設計であるため、翻訳レイヤーも必要としない。
OKFバンドル
OKFバンドルは、コンセプトを表すMarkdownファイルのディレクトリだ。テーブル、データセット、メトリクス、プレイブック、ランブック、APIなど、記述したいあらゆるものを表現できる。
OKFバンドルには以下の特性がある。
- 単なるMarkdownファイルであり、どのエディタでも読みやすく、GitHubで管理でき、どの検索ツールでもインデックス可能だ
- 単なるファイルであるため、tarballとして配布でき、どのgitリポジトリでもホストでき、どのファイルシステムでもマウントできる
- YAMLフロントマターで記述するのは、クエリ(検索)可能にする必要がある「type」「title」「description」「resource」「tags」「timestamp」といった最小限の構造化フィールドのみでシンプルだ
OKFでは「1つのファイル=1つのナレッジ」として扱い、フォルダ階層を含むファイルパスそのものを識別子として活用する。具体的なディレクトリ構成のイメージは以下の通りだ。
sales/
├── index.md
├── datasets/
│ ├── index.md
│ └── orders_db.md
├── tables/
│ ├── index.md
│ ├── orders.md
│ └── customers.md
└── metrics/
├── index.md
└── weekly_active_users.md
各Markdownファイルには、構造化フィールド用のYAMLフロントマターと、Markdown形式の本文が含まれる。
OKF設計の3原則
1.最小限の制約
OKFが全てのドキュメントに対して要求するのは、type(型)フィールドという一つの要素のみだ。どのような型が存在するか、他にどのようなフィールドを含めるか、本文にどのようなセクションがあるかといった事項は制作者に委ねられる。このフォーマットは中身の細かいスキーマまで指定するものではなく、相互運用性の標準を定義するものだ。
2.作成者と使用者の独立性
OKFは、ナレッジを作成する人と利用する人を明確に分離する。人間が手書きで作成したバンドルをAIエージェントが利用でき、メタデータエクスポートパイプラインが生成したバンドルをビジュアライザーで閲覧でき、あるLLMが合成したバンドルを別のLLMが照会できる。
3.プラットフォームではなくフォーマット
OKFは特定のクラウド、データベース、モデルプロバイダー、エージェントフレームワークに依存しない。読み取り、書き込み、提供にプロプライエタリな(ベンダー独自の)アカウントやSDKは一切必要ない。「ナレッジフォーマットの価値は誰が所有するかどうかではなく、どれだけの人が利用できるかで決まる」として、オープン標準として公開したという。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
AIコーディングはなぜ後から苦しくなるのか? 技術負債に続く「理解負債」「認知負債」という新たな落とし穴
AIコーディングが普及する中で注目され始めた「理解負債」と「認知負債」。従来の技術負債と合わせた「AIコーディング時代の三大負債」を整理し、なぜ開発が後から苦しくなるのかを分かりやすく解説する。
国土交通省が「MCPサーバ」公開 APIの知識不要、対話形式でのデータ取得が可能に
国土交通省は、APIの知識不要で、自然言語による対話形式で「国土交通データプラットフォーム」からデータ検索が可能なMCPサーバを公開した。
ホントに役立つスキルを作るには? AnthropicがAIエージェントで使うスキルの構築ガイドを公開
何らかのワークフローや定型処理の手順、それに必要な情報をAIエージェントに持たせる「スキル」の構築方法について、Anthropicが公式ガイドを公開した。実際に役に立つスキルを作りたいのなら、このガイドがその第一歩になるかもしれませんよ。
Cursor開発チームが明かす、コーディングエージェントの7つのベストプラクティス
Cursor開発チームは、同社のCursor IDEを活用する上で、コーディングエージェントの性能を最大限に引き出すためのベストプラクティスを公開した。単なるコード生成にとどまらず、大規模なリファクタリングやテスト駆動開発の自動化が可能になる一方、その制御にはコツが必要だと指摘している。