OKF対応を実装してみた｜knowledge-wikiでのエクスポート/インポートの中身

2026年8月14日

OKF対応を実装してみた｜knowledge-wikiでのエクスポート/インポートの中身

OKFという標準の概念は理解した。でも実際に自分たちのナレッジベースに組み込むと、どんな作業になるのだろう。

この記事では、実際にOKFバンドルのエクスポート/インポート機能を実装してみた過程を、まだ実運用に至っていない現在地も含めて正直に紹介します。

あわせて読みたい

OKF（Open Knowledge Format）とは？LLM-Wikiパターンの標準化を読む MarkdownとYAML frontmatterで知識を蓄積し、AIに参照させる。この非公式な実践に、2026年6月Google Cloudが「OKF」という名前を付けた。発表からわずか6週間でv0.2に更新された経緯と、自分たちのLLM-Wiki運用との違い・向き合い方を整理する。

姉妹記事「OKFとは何か」で、核となる発想には乗りつつ、細部への追従は都度判断する、という距離感を書いた。では実際に「乗る」とはどういう作業なのか。LLM-Wikiとして運用している自分たちのObsidian Vaultに、OKFバンドルのエクスポート/インポート機能を実装してみた。

まだ実運用は始めていない。異なるVault同士で実際にデータを交換した経験はなく、あくまで仕組みとして用意した段階だ。その前提で、実装してみてわかったことを書く。

なぜOKF対応を実装したか

きっかけは、Vault間で知識を持ち運びたいという場面があったことだ。自分の研究ノートを別のプロジェクト用Vaultに移したいときや、他の人のVaultから知識を取り込みたいとき、独自のフォーマットのままではその都度変換の手間が発生する。

OKFはMarkdown＋frontmatterというシンプルな形式で、かつランタイムやSDKを必要としない。この形式に合わせてエクスポート・インポートの機能を用意しておけば、フォーマット変換の手間なくVault間の知識移転ができる、という見立てだった。

frontmatterのマッピング

自分たちのVaultは、ページごとにlayer（Knowledge/Thinking/Writing/Journalのどの階層か）、summary（要約）、domain、raw_sourcesのような独自のfrontmatterキーを使っている。これをOKFの語彙に変換する対応表を作った。

layerはOKFのtype（大文字始まりに変換、knowledge→Knowledge）に、summaryはOKFのdescriptionに、tagsとdate_updatedはそのままOKFのtags・timestampにマッピングする。OKFはfrontmatterに自由なキーの追加を許しているため、独自のlayerやraw_sourcesはそのまま拡張キーとして残す設計にした。これにより、OKFバンドルとして書き出しても、自分たちのVaultに戻すときに情報が失われない。

作業してみて意外だったのは、対応表自体はほとんど機械的な一対一変換で済んだことだ。自分たちのfrontmatter設計が、最初からOKFの必須フィールドtype＋推奨フィールドという最小限の構成と方向性が近かったからだろう。もし独自のキー体系がもっと入り組んでいたら、この対応表はもっと悩ましいものになっていたはずだ。

progressive disclosureという考え方の実装

OKFの仕様には、いきなり全ページを読ませるのではなく、階層ごとのindex.mdを経由して段階的に情報を開示するという考え方がある。この考え方に合わせて、バンドルのルートに全体の一覧を示すindex.mdを、階層・ドメインごとのフォルダにもそれぞれのindex.mdを生成するようにした。

エージェントが最初に読むのはルートのindex.mdだけで、必要な階層に絞ってから詳細ページへ進める。全ページをまとめて渡すより、読み込む情報の量を絞り込める設計だ。

まだ試せていないこと

ここまでは「作った」話であって、「使った」話ではない。実際に別のVaultへエクスポートしたバンドルを渡し、向こうでインポートしてもらう、というやり取りはまだ行っていない。フォーマット変換自体は動くことを確認したが、本当の価値は異なる作り手同士のVaultをつなげたときに出るはずで、そこはこれからの検証になる。

OKFのバージョンについても正直に書いておく。今実装しているのはtype・title・description・tags・timestampというv0.1のフィールドのみで、2026年7月に追加されたsources・generated・verifiedのようなv0.2の信頼シグナル群には対応していない。姉妹記事「OKFとは何か」で書いた通り、標準がまだ動いている以上、今すぐこれを追いかける必要はないと考えている。

あたま

正直なところ、v0.1のマッピングをようやく組み終えたと思ったタイミングで、その6週間後にはもうv0.2が出ていたと知りました。標準に追従するというのは、追いついた瞬間にまた少し先を行かれる、という感覚と付き合い続けることなのかもしれません。だからこそ、細部を毎回追いかけるより、核となる発想だけ緩く踏襲するという距離の取り方のほうが、今の自分たちには合っています。

まとめ

OKF対応の実装自体は、既存のfrontmatterをマッピングし、progressive disclosure用のindex.mdを生成する仕組みを足すだけで、思ったより小さな作業で済んだ。ただし、これはまだ仕組みを用意しただけの段階であり、実際に異なるVault間でのやり取りを試すのはこれからだ。

RAG（検索の技術）とOKF（知識の保存形式）という2つの視点を見てきたところで、次の記事ではこの2つをあらためて並べ、AIに知識を渡すときにどちらをどう検討すればいいか整理する。

あわせて読みたい

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

あわせて読みたい

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

あわせて読みたい

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

あわせて読みたい

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

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

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

URLをコピーしました！

URLをコピーしました！

この記事を書いた人

あたま

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