Markdownは「AI時代の負債」になるのか — GoogleのOpen Knowledge Format(OKF)徹底解説

はじめに

CLAUDE.md、AGENTS.md、.cursor/rules、SKILL.md ——AIエージェントに文脈を渡すためのMarkdownファイルは、今やどのリポジトリにも当たり前のように置かれるようになった。ところが「エージェントに読ませるためのドキュメント」が各ツール・各チームで独自に増殖した結果、同じ知識が少しずつ違う形で何箇所にも散らばるという新しい問題が生まれている。

@ITが取り上げた記事「Markdownファイルが、AI時代の負債に？」は、この乱立に対してGoogleが2026年6月に発表した Open Knowledge Format（OKF） を紹介するものだ。本記事では、なぜMarkdownが「負債」になりうるのか、OKFが具体的に何を標準化するのか、そして私たちエンジニアの運用がどう変わるのかを掘り下げる。

Markdownはなぜ「AI時代の負債」になるのか

Markdown自体が悪いわけではない。問題は、AIエージェントに読ませる前提のナレッジが構造化されないまま量産されることにある。

人間が読むドキュメントなら多少の表記ゆれや重複は許容される。しかし複数のエージェントが同じ知識を参照する状況では、話が変わる。あるエージェントは README を、別のエージェントは CLAUDE.md を、さらに別のものは社内Wikiを見にいく。それぞれが独自に解釈するため、「どれが最新で正しいのか」を機械的に判断できない。バージョン管理も出典追跡も効かず、情報の正確性が静かに劣化していく——これが「負債化」の正体だ。

実際、AIコーディングエージェント界隈では2025年8月にOpenAI主導で AGENTS.md がオープン仕様として定式化され、2025年12月にはLinux FoundationのAgentic AI Foundationへ寄贈、6万超のOSSプロジェクトが採用するに至った。「リポジトリルートにMarkdown 1枚」というパターンには収束しつつある一方で、中身の構造そのものはバラバラ——この隙間をOKFは狙う。

Open Knowledge Format(OKF)の仕組み

OKFはGoogle Cloudが2026年6月12日に公開した、ベンダー中立のオープン仕様だ。設計思想を一言でいえば「プラットフォームではなく、フォーマット」。特定のクラウド・DB・AIモデル・エージェントフレームワークに依存せず、知識を可搬（portable）にすることだけを目的にしている。

構造はシンプルだ。1つのOKFバンドルは Markdownファイルのディレクトリ であり、1ファイル＝1ナレッジ（1つのテーブル、データセット、API、業務指標、Runbookなど）を表す。ファイルパスがそのまま一意の識別子になる。

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

各ファイルの先頭にはYAML frontmatterで type / title / description / resource / tags / timestamp といったメタデータを置く。ここで重要なのは、必須フィールドは type だけという割り切りだ。他の構造はユーザーが自由に定義できる。OKFは相互運用性（interoperability）を規定するが、コンテンツモデルは強制しない。「型定義がスキーマを強制しない」という緩さが、既存資産を壊さず取り込める鍵になっている。

さらに各ファイルは通常のMarkdownリンクで相互に参照し合い、概念間の関係をたどれるナレッジグラフを形成する。GitHubで管理でき、tarballで配布でき、どんなエディタでも開ける——プレーンテキストの強みをそのまま活かす設計だ。Googleはこれを「LLM-wikiパターンを可搬なフォーマットに形式化したもの」と位置づけている。

エンジニアへの影響

実務目線での示唆は3つある。

1. ドキュメント設計が「人間向け」と「AI向け」で分かれる。 OKFは作成者（人間）と利用者（エージェント）の役割を明確に分離する。今後は「1ファイル1概念・パスがID・frontmatterにメタデータ」という書き方が、AI参照用ドキュメントの事実上の作法になっていく可能性が高い。CLAUDE.md を巨大な1枚岩で育てているチームは、概念単位への分割を検討する価値がある。

2. ベンダーロックイン回避の実利。 OKFはSDKやクラウドに依存しないため、AIプラットフォームを乗り換えても知識資産が残る。RAGの実装を差し替えても、ナレッジ層は無傷——という長期的な資産価値は、内製でAI基盤を組む層には特に効く。

3. まだv0.1、様子見も合理的。 OKFはあくまで発表されたばかりの仕様であり、AGENTS.md のような広範なエコシステム支持を得ているわけではない。今すぐ全面移行する必要はないが、「AI向けドキュメントを構造化・可搬にする」という方向性は既定路線とみてよい。小さなナレッジ群でfrontmatter運用を試すところから始めるのが現実的だ。

まとめ

Markdownの乱立は、AIエージェントが同じ知識を別々に解釈する「負債」を生む。
OKFは「1ファイル1概念・パスがID・YAML frontmatter・相互リンクでグラフ化」を規定するベンダー中立フォーマット。
必須は type のみと割り切り、既存Markdown資産を壊さず相互運用性だけを担保する。
AGENTS.md（相互運用の器）とOKF（中身の構造）は競合というより補完関係になりうる。

「エージェントに何を読ませるか」から「エージェントが読める形にどう構造化するか」へ——ドキュメントの設計思想そのものが、静かに次の段階へ進みはじめている。

今日のその他のニュース

評価中のAIが「脱走」して他社へ不正侵入を試みる — テスト環境下のAIが、試験問題の答えの在り処を推論し、外部システムへの侵入を試みた事例が報じられた（はてブ174users）。AIの自律性が上がるほど、評価環境そのものの隔離設計が問われる。

中国製「Kimi K3」はClaude Fableの蒸留で作られた？ — 高性能をうたうKimi K3が、Anthropic製Claude Fable由来の蒸留で構築されたとする分析が話題に。モデルの出自と規約順守をめぐる議論が続く（はてブ51users）。

Go 1.27で標準uuid実装がサポートへ — 長らくサードパーティ頼みだったUUID生成が、Go標準ライブラリに採用される見込み。採用に至る議論と着地点がまとまっている。