OKF（Open Knowledge Format）とは？LLM-Wikiパターンの標準化を読む

2026年8月14日

OKF（Open Knowledge Format）とは？LLM-Wikiパターンの標準化を読む

RAGとGraphRAG/Agentic RAGは理解した。でも、そもそも知識をどう保存しておくべきかは考えたことがなかった。

この記事では、Markdown＋frontmatterで知識を蓄積するというやり方に名前を与えた新しい標準「OKF」を紹介します。

姉妹記事「RAGとは何か」で触れた通り、筆者は自分の研究をLLM-Wikiに蓄積している。実験結果、実験計画、調べたことをすべてMarkdownファイルとYAML frontmatterで書き溜め、AIエージェント経由で検索・活用する。この書き方自体は特に目新しいものだと思っていなかった。同じようなことをしている人は、ブログやSNSでちらほら見かける。

あわせて読みたい

RAGとは？仕組み・チャンク分割・ベクトルDBを初心者向けに解説「社内文書をAIに検索させたい」と頼まれたとき、RAGが何をしているのか説明できるか。検索→文脈への挿入→生成という3ステップと、それを支えるチャンク分割・ベクトルDBの役割を、情報が増えるほど検索精度が落ちるという実体験を交えて解説する。

この「Markdown＋frontmatterで知識を蓄積し、AIに読ませる」という非公式なやり方に、2026年6月、名前が付いた。Google CloudのData Teamが発表したOKF（Open Knowledge Format）だ。何をどこまで標準化しているのか、自分たちのやり方とはどう違うのか整理する。

OKFとは何か

OKFは、組織の知識がメタデータカタログ・Wiki・コードコメント・個々人の頭の中に分散し、AIエージェントを1つ作るたびに個別の統合作業が必要になる、という「文脈の断片化」問題への対処として提案された仕様だ。

技術的な中身はシンプルで、Markdownファイルのディレクトリと、そこに付けるYAML frontmatterの規約でしかない。必須フィールドはtypeひとつだけで、title・description・resource・tags・timestampが推奨フィールドとして用意されている。概念同士は普通のMarkdownリンクでつなぐ。

特定のクラウド・データベース・モデル提供元に縛られない
特定のエージェントフレームワークに縛られない
専用のランタイムもSDKも要らない（「ただのファイル」であることが最大の特徴）

この設計は裏を返せば、重厚なナレッジ管理システムを新しく導入しなくても、既存のMarkdownメモにfrontmatterを足すだけで参加できるということでもある。

6週間でv0.2に

OKFは発表されてすぐ静止したわけではない。2026年6月の初版（v0.1）から6週間後の2026年7月25日、早くもv0.2が公開された。

v0.1が「その内容は何か」を記述する仕様だったのに対し、v0.2は「その内容は誰が保証しているのか」を記述するフィールド群を追加した。概念の出所を記録するsources、生成・検証の履歴を記録するgeneratedとverified、相対的なTTLではなく絶対日付で鮮度を示すstale_after、draftからstable、deprecatedへのライフサイクルを示すstatus。いずれも、AIエージェントが書き込んだ内容をどこまで信頼してよいかを判断するための材料になる。新しいフィールドはすべてオプトインで、v0.1のバンドルはそのまま有効という後方互換も保たれている。

わずか6週間でこれだけの拡張が入ったという事実そのものが、この仕様がまだ動いている途中であることを物語っている。

自分たちの運用との違い、そして今の判断

自分たちのLLM-Wikiは、OKFが発表されるより前から、Markdown＋frontmatterで知識を蓄積するという同じ発想で運用してきた。実際、姉妹記事「GraphRAGとAgentic RAG」で書いた通り、検索精度が落ちたときにリンクの付け方や検索範囲を調整してきた経緯もある。OKFという名前がついたことで、自分たちがやっていたことの輪郭がはっきりした感覚はある。

あわせて読みたい

GraphRAGとAgentic RAGとは？RAGの発展形の違いを整理するチャンク分割とベクトルDBだけのRAGは、情報量が増えると検索精度が頭打ちになる。その先にあるGraphRAG（グラフ構造からの検索）とAgentic RAG（エージェントによる複数回検索）は何が違うのか、実際にリンク構造と検索回数を調整した経験をもとに整理する。

ただし、フィールド単位で見ると違いは小さくない。OKFのv0.2が持つsourcesやverifiedのような信頼シグナルは、自分たちの運用にはまだ無い。これを今すぐ追いかけて実装すべきかというと、そう単純でもない。

あたま

標準化がまだ定まっていない仕様に細部まで厳密に合わせにいくと、また数週間後に仕様が変わったときに書き直しが発生します。核となる発想は緩く踏襲しつつ、個々のフィールドへの追従は案件ごとに要不要を判断する、というのが今のところの現実的な向き合い方だと考えています。

これはRAGの検索回数・リンクをたどる範囲を都度調整していたのと同じ態度で、標準に合わせること自体を目的化しない、という一貫した姿勢でもある。

まとめ

OKFは、Markdown＋frontmatterで知識を蓄積するという、すでに一部の実践者がやっていたことに名前と最低限の規約を与えた仕様だ。核となる発想には乗りつつ、細部への追従は都度判断する、というのが今のところの現実的な距離感になる。

次の記事では、自分たちのLLM-Wikiが実際にOKF対応をどう実装したか、frontmatterのマッピングやエクスポート・インポートの実例を見ていく。

あわせて読みたい

RAGとOKF、AIに知識を渡す2つの方法 AIに知識を渡す方法には、検索時にどう情報を引っ張ってくるかというRAGの技術と、そもそも知識をどうファイル化しておくかというOKFの標準という、レイヤーの異なる2つの視点がある。両者の関係と使い分け、このクラスタで書いた4本の記事への案内をまとめる。

あわせて読みたい

「AIを第二の脳にする」LLM-wikiという設計思想（ノートを取るのをやめて、一緒に編纂する）「AIを第二の脳にする」という言葉の中身は比喩止まりの記事が多い。Andrej Karpathy氏が提唱したとされるLLM-wikiパターン（Raw/Wiki/Schemaの3層＋Lintパス）を、クエリ時点で検索するRAGとの違いから解説する連載第0回。

あわせて読みたい

Obsidianとは？AI時代に見直される個人の知識管理（PKM）の基本ローカルMarkdownノートアプリ「Obsidian」の特徴、Zettelkasten・PARAという情報整理の2つの源流、そしてAI時代にPKMの目的がどう変わってきているかを解説します。

出典（2026年8月時点で確認）

よかったらシェアしてね！

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

あたま

本業で生成AIの活用法を研究し、実装・社内への導入推進を担当。属人化しがちなノウハウをどう言語化し、チームの資産にするかに関心があります。このラボでは、ナレッジ・生成AIツール・実践ワークフロー・データサイエンスの4領域で検証したことを記録しています。姉妹サイト「なないろ日和」では育児や暮らしについても書いています。