先日、海外の掲示板Redditで面白い議論を見かけました。
AIアシスタントのコミュニティでの投稿です。
テーマは、Googleが新しく公開した「Open Knowledge Format（OKF）」という仕様について。
Open Knowledge Formatとは何か
まず、投稿で語られていたOKFの中身を整理しましょう。
GoogleがOKFのv0.1を公開しました。
仕様としては驚くほど素朴です。
組織の知識を、マークダウンファイルが並んだ一つのフォルダとして扱う。
それだけ。
各ファイルの先頭には、小さなYAMLのメタ情報ブロックを置きます。
そして、ファイル同士をつなぐのは特別な記法ではありません。
ごく普通のマークダウンのリンクです。
必須の項目は、たった一つtypeだけ。
ナビゲーション用のindex.mdと、変更履歴を残すlog.mdは任意。
仕様の説明は、もうこれで終わりです。
投稿者は、自分のAIアシスタントの記憶を何ヶ月も前からこの形で運用していたそうです。
そのうえで、いくつか実践的な指摘をしていました。
一つは、必須項目をtype一つに絞ったのは妥当だ、という点。
バラバラのメモを後から検索できる状態にするには、最低限この区分さえあればいい。
タグや日付や説明文は、あれば便利です。
ただ、それは状況次第、というわけです。
リンクの書き方についても触れていました。
一部のメモアプリで使われる[[二重角かっこ]]より、普通のマークダウンリンクのほうが移植性が高い。
GitHub上でもそのまま表示されます。
専用の変換ツールも要りません。
だからもし今[[ ]]を使っているなら、移行を検討する価値があるところだ、と。
そして、この仕様はあえて「最小限の主張」にとどめている、という点も指摘されていました。
標準化したのは、ツール同士が読み合える接続面だけ。
では、それぞれのメモを役立たせる工夫はどうか。
「どこから来た情報か」「なぜ重要か」「もう古くなっていないか」。
こうした部分は、依然として自分で足す必要があります。
そしてGoogleは、そうした拡張をむしろ歓迎しているそうです。
「当たり前。でも、いいね」という空気
さて、ここからが本題です。
コメント欄の反応が、なかなか味わい深いものでした。
全体の空気を一言でまとめるなら、「そんなの当たり前。
でも、まあ、いいね」。
驚くほど多くの人が、まったく同じ「マークダウンファイルを並べたフォルダ」をすでに何年も運用していました。
多くはObsidianというメモアプリを使って。
だからこそ、巨大なIT企業がそれを正式な仕様として公開した。
その事実に、ある種の安心感を覚えたようです。
コミュニティが手探りでたどり着いた答えを、後から会社が追認してくれた格好ですから。
冷めたコメントもありました。
「数ヶ月前に自分で似たものを組んだ。良い土台だけど、まだ表面をなぞっただけ」。
皮肉る人もいます。
「ドキュメントにtypeが付きました、すごいでしょう、なんて史上もっとも目新しくない発明だ」。
AIの記憶システムを作り始めて最初の二週間で、誰もが思いつく分類だ、というわけです。
一方で、本質を突いた声もありました。
「大事なのはフォーマットじゃなくて相互運用性だ」という指摘です。
みんなが独立に「マークダウン＋メタ情報」という形に行き着きました。
これは、その形が正しい証拠でしょう。
ところが、各自のタグやリンクの付け方はバラバラです。
だから、誰かのメモを別の誰かのツールが読めない。
共通の仕様があって初めて、別のツールがあなたの知識を専用パーサー無しで歩ける。
そういう論旨でした。
本当に難しいのは、フォーマットじゃない
コメント欄でもっとも繰り返されたテーマがあります。
それは「フォーマットは簡単な部分にすぎない」ということ。
ある人はこう言っていました。
フォーマットは一度も苦労したことがない。
難しいのは検索のほうだ、と。
200個のメモのうち、今この瞬間の作業に関係するのはどれなのか。
typeがあれば絞り込みはできます。
でも、「今この瞬間に何が重要か」までは教えてくれません。
そしてこう締めくくっていました。
自分のメモフォルダがうまく回っている理由は、メタ情報が立派だからではない。
コードのように容赦なく剪定しているからだ、と。
別の人は、もっと踏み込んだ言い方をしていました。
仕様が決められるのは、フォルダの形やファイルの書き方、エージェントが中身を見つける手順まで。
では、決められないものは何か。
記憶が積み重なって価値を生むかどうかを左右する部分、つまり「編集の方針」です。
走り書きのログから、どれを正式なメモへ昇格させるのか。
何を捨てるのか。
どの情報が、どの情報を上書きしてよいのか。
ファイルを、それが追いかけている現実に対して正直に保つには、どうするか。
同じOKFの構成をなぞっても、片方は使える資料庫になり、もう片方は沼になる。
差を分けるのは、ひとえに手入れの規律だけ。
「フォーマットは簡単な80パーセント。昇格の判断こそが、生きるか腐るかの分かれ目」。
この表現は、言い得て妙だと思いました。
そして、多くの人が口をそろえたテーマがあります。
「ドキュメントの陳腐化」という古典的な問題です。
情報を放っておくと、古くなり、膨らみ、やがてAIを誤った方向へ導く。
簡単な仕様はありがたい。
でも、本当に厄介なのはその後の維持なんですよね。
投稿者自身も「メモ帳で開けるテキストの集まり、というのが最先端の到達点だ」と書いていました。
すると複数の人が、こう返します。
「開けることより、開いた中身が腐らないようにするほうが、ずっと大変だ」。
なぜ「シンプルでいい」が刺さるのか
ここまで読んで、拍子抜けした方もいるかもしれません。
要するに、ただのテキストファイルのフォルダなのですから。
でも、その「拍子抜け」こそが、この話の肝だと思います。
投稿者の最後の一文が印象的でした。
エージェントに記憶を持たせる最先端のやり方が、メモ帳で開けるテキストの集まりだった。
もしあなたが「シンプルなままでいい」という許可を待っていたなら。
巨大なプラットフォーム企業が、その結論をオープンな仕様として出荷してくれた。
投稿者はそう書いていました。
複雑なシステムを組まなくていい。
サブスク課金の知識ベース製品も要らない。
あるコメントには、こうありました。
「世に出回る知識ベース製品の半分は、これに月額料金と重いWeb UIを乗せただけだ」。
フォルダにマークダウンを置いて、grepで一瞬で全文検索する。
どこにでも同期できて、仕組みは透明。
これで足りる場面は、思っているより多いのです。
もちろん、シンプルさは万能ではありません。
コメントの随所で語られていたとおりです。
検索精度も、情報の鮮度管理も、編集の規律も、結局は自分の手で育てるしかない。
仕様が肩代わりしてくれるのは、いちばん簡単な土台の部分だけです。
それでも、複雑さに逃げ込まずに済む。
その安心感には価値があります。
道具を立派にすることと、知識を役立てることは、別の話なのですから。
まとめ
GoogleのOpen Knowledge Formatは、技術的に目新しいものではありません。
多くの人が独立に到達していた「マークダウンのフォルダ」を、共通仕様として言語化しただけ、とも言えます。
けれど、Reddit上の議論を読んで、別の景色が見えてきました。
コミュニティが手探りで見つけた素朴な答えを、巨大企業が追認した。
シンプルでいい、という結論に正式なお墨付きが出た。
そして同時に、もう一つの共通認識も浮かび上がってきました。
本当の難所はフォーマットの外側にある、と。
つまり、検索と維持と編集の規律です。
もしあなたが今、複雑な知識管理システムを組もうか迷っているなら、いったん立ち止まってみてください。
本当に必要なのは、メモ帳で開けるテキストの集まりと、それを腐らせない地道な手入れだけ。
案外、そんなところなのかもしれません。
