AIナレッジ / 理解メモ / 確認日 2026-06-30
OKFはメモの山をAIが使える知識に変えるための考え方
Open Knowledge Formatは、MarkdownにYAMLを付けるだけの話に見える。だが本質は、AIに渡したい知識を、再利用できる単位に切り、ラベルを付け、関係をたどれるようにすることにある。
OKFは、見た目だけだと新しさが分かりにくい
Open Knowledge Format (OKF) を初めて見ると、普通のMarkdownファイルにYAML frontmatterを付けたものに見える。Obsidianでもdocs repoでも似たことはできるので、「それの何が新しいのか」が最初のつまずきになる。
このつまずきは、仕様の細部を読んでもすぐには解けない。先に見るべきなのは、OKFが解こうとしている問題である。つまり、AIに渡したい知識が増えたとき、それをどうやって再利用できる単位として置くか、という問題だ。
問題は、AIに渡したい知識がメモの山になること
人間は、多少散らかったメモからでも必要な文脈を探せる。だがAI agentに知識を渡すときは、どのメモが概念で、どれが判断の根拠で、どれが注意点で、何と何が関係しているのかが曖昧になりやすい。
たとえば社内wiki、データカタログ、runbook、プロジェクトメモ、調査ノートは、それぞれ人間向けには読める。しかしagentに「この背景を踏まえて要約して」「この指標を使って分析方針を考えて」と頼むと、必要な知識の境界がはっきりしない。
OKFは、知識をきれいに保存するための飾りではなく、AIが再利用しにくいメモの山を扱うための考え方として読むと分かりやすい。
OKFが足すのは、知識単位・ラベル・リンク
OKFは新しいデータベースを要求しない。基本はディレクトリに置かれたMarkdownファイル群で、各ファイルの先頭にYAML frontmatterを持つ。仕様上の必須fieldはtypeだけで、title、description、resource、tags、timestampなどは推奨項目として扱われる。
Concept
知識を再利用できる単位に切る。テーブル、指標、業務プロセス、API、playbookなどを1つのconceptとして扱える。
Type
そのconceptが何の種類の知識かを示す。必須fieldがtypeだけなのは、最低限ここを揃えたいからだと理解できる。
Index
index.mdは知識束の入口になる。人間にもagentにも、どこから読めばよいかを示す。
Links
Markdown linkでconcept同士の関係をたどれるようにする。関係の意味は、リンク周辺の文章で説明する。
OKFの前後で変わるのは、知識を渡す前処理である
OKFの前
人間がメモを探し、必要な部分を読み、AIに説明する。知識の粒度や関係は、人間がその場で補う。
OKFの後
最初からAIが参照しやすい単位で知識を置く。agentは入口、種類、関係、注意点をたどりやすくなる。
重要なのは、OKFを置いた瞬間にAIが自動で賢くなるわけではないことだ。変わるのは、AIに渡す知識の前処理が揃うこと。知識を「長い説明文」ではなく「たどれる部品」として準備する発想に変わる。
普通のMarkdown、AGENTS.md、OKFは役割が違う
| 形式 | 主な役割 | OKFとの違い |
|---|---|---|
| 普通のMarkdown | 人間が自由に読む文書。メモ、記事、仕様、議事録などを柔軟に書ける。 | 自由度が高い分、AIがどの単位で再利用すべきかは明示されない。 |
AGENTS.md / CLAUDE.md |
agentに常時読ませる作業指示やリポジトリ規約。 | 作業ルールを渡すのに向く。大量の業務知識や参照知識を全部入れる場所ではない。 |
| OKF | agentが必要に応じて参照できる知識の束。 | 長い指示文ではなく、知識をconceptとして分け、typeやlinkで探索しやすくする。 |
3つの具体例で見る
社内wiki
OKF前は、プロジェクト概要、仕様、意思決定、用語がページごとに散らばる。人間は検索して読めるが、AIに「この施策の背景を踏まえて要約して」と頼むと、どのページのどの部分が背景なのかを人間が補う必要がある。
OKF後は、business_process、decision、termのように知識単位で切り、関係をリンクする。AIに渡すとき、参照すべき単位が明確になる。
データカタログ
OKF前は、テーブル定義や指標定義はあっても、業務上の意味、使ってはいけない条件、結合時の注意点が別文書に散りやすい。schemaだけでは、分析判断に必要な文脈が足りない。
OKF後は、table、metric、join_path、caveatのように、データと業務意味を同じ知識束に置ける。AIに分析相談するとき、単なる列名ではなく、判断文脈ごと渡しやすくなる。
Obsidian-Codex運用
OKF前は、Obsidianのメモ、Codex skills、memory、AGENTS.md、調査ノートがそれぞれ存在する。どれが再利用知識で、どれがその場限りの調査なのかが曖昧になると、agentに読ませる文脈も膨らみやすい。
OKF後の考え方を使うと、すぐに仕様を導入しなくても、「再利用される知識」と「一時的な調査」を分ける視点が得られる。自分のvaultでは、まずこの区別が理解の入口になる。
OKFは整理を自動化しない
OKF v0.1はdraftであり、完成した標準というより、相互運用のための最初の合意面に近い。conformanceも寛容で、unknown type、unknown field、broken link、missing indexはconsumer側が拒否しない前提になっている。
つまり、OKFを使っても、よい粒度、正しい分類、信頼できるsource、更新責任は自動で決まらない。雑に導入すれば、frontmatter付きのメモの山になるだけである。
OKFは知識整理の答えではない。知識を整理するときに、人間とAIが共有できる最低限の形を与えるものだ。
自分の言葉で言い直す
OKFは、AIに渡したい知識がメモの山になって再利用しにくい問題を、知識単位・ラベル・リンクで扱いやすくする考え方。
この一文で説明できれば、OKFを「Markdown + YAMLの細かい仕様」ではなく、「AIに知識を渡すための前処理を揃える概念」として捉えられる。
参考資料
| 資料 | 位置づけ |
|---|---|
| Introducing the Open Knowledge Format | Google Cloud BlogによるOKF v0.1の紹介。2026-06-13公開。 |
| GoogleCloudPlatform/knowledge-catalog | Knowledge Catalogのsamples、tools、OKF関連資料を含むrepository。 |
| Open Knowledge Format (OKF) v0.1 Draft | bundle structure、frontmatter、reserved filename、conformanceを定義する仕様。 |