AI駆動開発 2026年7月27日

あなたのMarkdownファイルは、すでにAI時代の負債かもしれない——GoogleのOpen Knowledge Formatが問うこと

𝕏 シェアする

あなたのMarkdownファイルは、すでにAI時代の負債かもしれない——GoogleのOpen Knowledge Formatが問うこと

Markdownのカオスに、Googleが「フォーマット」で切り込んだ

Google Cloudが2026年6月12日に公開した「Open Knowledge Format」（OKF）バージョン0.1は、AIエージェントが使うナレッジをMarkdownで標準化しようとするオープンフォーマットだ。

一言でいえば「YAMLフロントマターを持つMarkdownファイルのディレクトリ」として知識を表現し、異なるエージェント間でそのまま共有できる形式を定義したもの。SDKも事前統合も不要で、誰でも作れて使える。これがOKFの骨格だ。

「Markdownで知識を管理する」という発想自体は新しくない。では何がニュースなのかというと、Googleが「フォーマットとして標準化する」という一手を打ったことにある。

何が問題だったのか——「個別最適化」の繰り返し

ここ数年、AIエージェントと組み合わせてナレッジを管理する試みは、さまざまな名称と形で繰り返し登場してきた。

AGENTS.md、CLAUDE.mdといったエージェント向けの規約ファイル。Obsidianの保管庫。データチームの「Metadata as Code」リポジトリ。これらは本質的に同じパターンだ——「人間が読めてAIも読めるMarkdownファイルに知識を置く」という発想。

だが元記事が指摘するように、「それぞれの事例は個別にカスタマイズされており、システム間で意図的に連携するよう設計されているわけではない」。

つまり問題の本質は、こうした知識ファイルが横断的に使えないことにある。あるチームが丁寧に作ったナレッジが、別のエージェントや別のシステムでは読めない。あるいは読めてもスキーマが合わないから使えない。結果として、同じ情報を形を変えて何度も書き直すことになる。これが「AI時代の負債」という表現の実体だ。

OKFはこの問題を「サービスで解消しようとするのではなく、フォーマットで解消しようとする」アプローチだと明記している。この言葉の意味は、後述する。

OKFの中身を整理する

OKFの構造はシンプルだ。

各Markdownファイルには、YAMLフロントマターで最小限の構造化フィールドを記述する。フォーマットが要求するのはtype（型）フィールドただ一つで、title、description、resource、tags、timestampなどはオプション扱いだ。本文はMarkdownで自由に書く。

ディレクトリ構成の例が元記事に示されており、こんな形になる。

sales/
├── index.md
├── datasets/
│   └── orders_db.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly_active_users.md

「1つのファイル＝1つのナレッジ」として扱い、ファイルパスそのものを識別子として活用する設計だ。

設計原則は3つに整理されている。

1. 最小限の制約——細かいスキーマは定めない。typeフィールドだけを要求し、あとは作成者に委ねる。「中身の細かいスキーマまで指定するものではなく、相互運用性の標準を定義するもの」という位置づけだ。

2. 作成者と使用者の独立性——人間が書いたバンドルをAIエージェントが使えて、LLMが合成したバンドルを別のLLMが照会できる。生産者と消費者を分離する設計は、長期的な互換性を意識した判断だ。

3. プラットフォームではなくフォーマット——特定のクラウド、データベース、エージェントフレームワークに依存しない。プロプライエタリなアカウントもSDKも不要。「ナレッジフォーマットの価値は誰が所有するかどうかではなく、どれだけの人が利用できるかで決まる」という思想がここに出ている。

ここからは見方だが——構造として何を意味するのか

AI研究者のアンドレイ・カルパシー氏は「LLM Wiki」に関する記事の中で、「LLMは相互参照の更新など煩雑な管理作業を正確にこなす能力に長けており、一度に15個のファイルを処理できる」と述べている。OKFはこの観察を前提として設計されていると読める——エージェントがファイルの読み書きを担い、開発チームはコンテンツをキュレーションしてコードのように管理する、という役割分担だ。

「サービスではなくフォーマット」という表現は、Google Cloudの戦略的な意図をにじませている。サービスを提供すれば、Googleがナレッジのプラットフォームになれる。だがそれでは普及しない。OKFがHTMLやMarkdownと同じ意味での「インフラ」になるためには、Google以外が自由に使える必要がある。この設計判断はJSON-LDやschema.orgが普及した経緯と重なって見える。

ただし、現実的な目で見れば「まだバージョン0.1」という事実は重い。

typeフィールドひとつを要求するだけというミニマルな設計は、相互運用性を標準化したいという意図と少し矛盾する。何のtypeを定義するかが各実装に委ねられている以上、今のところ「Markdownをどのフォルダに置くか」というレベルの合意にとどまる。本当の相互運用性は、型の定義が業界で収束してはじめて機能する。type: tableと書いたファイルが、別のエージェントでも同じように解釈されるには、その先の標準化が必要だ。

OpenAPI仕様が普及したプロセスを思い出せばわかるが、フォーマットが本当に「インフラ」になるまでには時間とエコシステムの形成が要る。OKFがそこに至れるかどうかは、これから数年の実装事例と採用ツールの広がりにかかっている。

実務的に何を考えるべきか

では今すぐOKFを採用すべきかというと、答えは「まだ急がなくてよいが、背景にある発想は今すぐ取り込む価値がある」だ。

OKFが提示しているのは、フォーマットそのものより先に「知識をコードのように管理する」という考え方だ。エージェントに読ませることを前提に知識を構造化し、バージョン管理し、陳腐化と戦いながら継続的にメンテナンスする——このサイクルを意識しているチームと、していないチームでは、AIエージェントの実用性に差が出てくる。

具体的には、次の問いを自チームに当てはめてみると使いやすい。

今の社内ドキュメントは、AIエージェントがそのまま読んで使えるか。フォーマットがバラバラであれば、どの層で標準化するかを決める価値がある。
エージェントに読ませる知識は「誰が更新するか」が決まっているか。OKFの設計原則が「作成者と使用者の独立性」を掲げているのは、この役割分担があいまいなままにしておくと、知識が陳腐化するからだ。
知識がツール固有のフォーマットに閉じ込められていないか。ChatGPT、Claude、Cursor……AIツールを乗り換えるたびに知識を書き直すコストは、蓄積量が増えるほど大きくなる。MarkdownとGitで外在化しておけば、少なくともポータビリティは確保できる。

「一度に15個のファイルを処理できる」という指摘は、AIエージェントがナレッジのメンテナンス作業そのものを担える可能性を示している。人間がレビューしてコミットする。エージェントが読んで更新案を出す。このサイクルはソフトウェア開発のCI/CDに近い発想で、ナレッジ管理に持ち込める。

次の論点として押さえておきたいのは、「知識のバージョン管理コスト」だ。コードと違い、ナレッジの陳腐化は目に見えにくい。「最新」「現在」という表現が実は1年前のドキュメントを指していても、エラーは出ない。OKFのtimestampフィールドがこの問題にどこまで対応できるか、あるいは別の仕組みが必要になるかは、実装が進む中で明らかになってくるはずだ。