OKFは知識をconcept fileとして切り出すための考え方

普通のメモは、人間が読むには十分に見える

たとえば、monthly_active_usersという指標をagentに説明したいとする。普通のMarkdownメモなら、次のように書ける。

# monthly_active_users

月次アクティブユーザー数。月内に1回以上ログインしたユーザーを数える。
無料トライアル中のユーザーは含めない。
退会済みユーザーは退会日以降の月から除外する。
分析では users と login_events を user_id で結合する。

人間が読むなら、これでも意味は分かる。しかしagentに渡す知識として見ると、いくつかの判断を人間が毎回補っている。

• これは指標なのか、テーブルなのか、業務ルールなのか。
• どのテーブルやイベントと関係するのか。
• どの注意点を分析時に必ず参照すべきなのか。
• 他のagentやtoolへ渡すとき、どこを入口にすればよいのか。

OKFでは、それを1つのconcept fileとして置く

OKFの中心発想は、文書を長くすることではない。再利用したい知識をconceptとして切り出し、最低限のラベルと関係を付けることだ。

---
type: metric
title: Monthly Active Users
description: 月内に1回以上ログインした有料ユーザー数
tags: [growth, product_analytics]
---

# Monthly Active Users

月内に1回以上ログインしたユーザーを数える。
無料トライアル中のユーザーは含めない。
退会済みユーザーは退会日以降の月から除外する。

## Related concepts

- [[tables/users]]
- [[tables/login_events]]
- [[caveats/trial-users-excluded]]

ここで重要なのは、MarkdownにYAMLを付けたこと自体ではない。monthly_active_usersを「agentに再利用させたい知識の1単位」として扱ったことが変化である。

「AIが使える」とは、毎回人間が説明しなくてよいという意味

ここでいう「AIが使える」は、魔法のようにAIが賢くなるという意味ではない。agentが入口を見つけ、種類を判断し、関連する知識をたどり、人間が毎回説明しなくても文脈を復元できる、という意味である。

OKFが足すものは、記法ではなく契約である

普通のMarkdownにもfrontmatterは付けられる。違いは、OKFが「知識をconceptとして切る」「最低限typeを持つ」「束として入口や関係を持てる」という契約を置くことにある。

OKFの前後で変わるのは、人間が補っていた文脈の置き場所

変化は「AIが自動で正解を出す」ことではない。人間が頭の中で補っていた文脈を、ファイル構造とリンクに逃がすことだ。

Markdown、frontmatter、AGENTS.mdとは役割が違う

OKFは、よい分類や正しさを自動では決めない

OKF v0.1はdraftであり、完成した標準というより、相互運用のための最初の合意面に近い。conformanceも寛容で、unknown type、unknown field、broken link、missing indexはconsumer側が拒否しない前提になっている。

つまり、OKFを使っても、どの粒度でconceptを切るか、typeをどう設計するか、sourceをどこまで信頼するか、誰が更新責任を持つかは自動で決まらない。雑に使えば、frontmatter付きのメモの山になるだけである。

OKFは知識整理の答えではない。知識をagentに渡すとき、人間とAIが共有できる最低限の形を与えるものだ。

自分の言葉で言い直す

OKFは、AIに渡したい知識がメモの山になって再利用しにくい問題を、conceptという知識単位、typeというラベル、Markdown linkという関係で扱いやすくする考え方。

この理解なら、OKFを「Markdown + YAMLの仕様」ではなく、「人間が毎回補っていた文脈を、agentがたどれるファイル構造へ逃がすための形式」として説明できる。

参考資料