OKF — Open Knowledge Format

最終更新: 2026-09-04

OKF（Open Knowledge Format）は、Markdownの知識コレクションのためのオープンな規約です: 小さく統一されたFrontmatterヘッダーを持つ、純粋なMarkdownファイルです。このページでは、OKFとは何か、Plainvaが自動的に何を行うのか——そして、なぜあなたがそれらを使う必要がないのかを説明します。

OKFとは？

その考え方は: 保管庫内のすべてのドキュメントが、それ自身で何であるかを示すということです。そのためには、Frontmatterの最小限のヘッダーだけで十分です。

---
type: Note
---
# My note

type——このドキュメントがどのような種類か（例: Note、Daily Note、Project）。規約の唯一の必須フィールドです。
okf_version——保管庫がどのバージョンの規約に従っているかを示します。この値は一度だけ、ルートのindex.mdに置かれ（現在は"0.2"）、個々のノートには置かれません。
index.md——各フォルダーは、その目次として1つのindex.mdを持つことができます。index.mdとlog.mdという名前はこのために予約されており、通常のノートには使用すべきではありません。

ツールやスクリプトでファイルを書きますか？正確なフィールド契約——許可される値、各プロパティタイプがどのようにシリアライズされるか、予約名のルール——はファイル形式リファレンスにあります。

OKFの由来: OKFはGoogle Cloudによるオープンな仕様です（GoogleCloudPlatform/knowledge-catalog、Apache-2.0ライセンス）。PlainvaはOKF 0.2（2026年7月25日公開）に従います。0.2で新しく追加されたのは、ノートがどこから来たのか、誰かがレビューしたのか、まだ有効なのかを示す5つの任意フィールドです——generated、verified、sources、stale_after、status。Plainvaがそれらについて何を表示し何を書き込むかは、下の「出所、レビュー、ライフサイクル」で説明します。

なぜPlainvaはOKFを使うのか？

純粋なMarkdownは驚くほどポータブルです——しかしそれだけでは信頼できる構造を持ちません。OKFはそこに必要最小限の構造を加えるだけで、すべては標準的なFrontmatterを持つ、ごく普通のMarkdownのままです:

データベース、フィルター、テンプレートは構造に依拠できます。 すべてのノートがtypeを持つため、普通のファイルに対する.baseビューも堅牢であり続けます。
フォルダーはナビゲート可能なままです。 フォルダーごとのindex.mdという目次は、人にもツールにも役立ちます。
スクリプトやAIアシスタントも保管庫を安全に扱えます——ディスク上の形式が統一され、文書化されているためです。
ロックインなし。 OKFは、ごく普通のMarkdownの上に成り立つオープンな規約です——他のOKFツールも、今日そして10年後もあなたのファイルを理解できます。

Plainvaが自動的に行うこと

新規ファイルにはOKFヘッダーが自動的に付与されます: Plainvaで作成されたすべてのノートは、そのFrontmatterにtypeを受け取ります——OKF 0.2以降、バージョン指標であるokf_versionはルートのindex.mdに一度だけ置かれ、個々のノートにはもう置かれません。値は保管庫ごとに設定できます: 設定 → 保管庫 → コンテンツと構造 → OKF（Open Knowledge Format） → 新規ノートのtype（デフォルトはNote）とデイリーノートのtype（デフォルトはDaily Note）。テンプレートが独自のtypeを持っている場合は、テンプレートが優先されます。

既存のファイルは無断で変更されることはありません。 Plainvaは、新規ファイルを作成する際、またはあなたが明示的に変換を開始した場合にのみ、OKFフィールドを追加します。

保護されたシステムフィールド: プロパティパネルでは、typeと——古いノートにまだ残っている場合は——okf_versionがOKFシステムフィールド（「OKFシステムフィールド——Plainvaによって管理されています」）としてマークされています: typeの値は既知のタイプのドロップダウンから選択でき、okf_versionは表示のみです。規約が誤って壊れないよう、名前変更、タイプの変更、削除はロックされています。

説明モーダル: 設定内の**OKFとは？**が、3つの文での短い要約とこのページへのリンクを示します。もう自動的には開きません。保管庫にOKF形式に適合していないファイルが含まれている場合、Plainvaは一度だけ小さなメッセージでそのことを知らせ、変換へ直接移動できるボタンを表示します。

出所、レビュー、ライフサイクル（OKF 0.2）

OKF 0.2以降、ノートは自分がどこから来たのか、誰がレビューしたのか、まだ有効なのかを示せます。Plainvaはこれを3つのことに変えます:

Plainvaが表示すること。

status: draftまたはstatus: deprecatedを持つノートは、ドキュメントヘッダーに下書きまたは廃止の帯表示を持ちます。stableは表示されません。他の値を持つ独自のstatus列（例えばタスクデータベースのOpen）はライフサイクルの状態ではなく、帯表示は付きません。
stale_afterを過ぎると、ノートの上に**失効としてマークされています（… 以降）**という通知が、プロパティへのジャンプ（プロパティを開く）とともに表示されます。この通知は表示のみです——Plainvaはノートの内容を何も変更しません。
プロパティパネルの信頼性と出所セクション（スマートフォンでは、ノートのコンテキストシートの中）は、各フィールドをまとめ、それらから信頼度を導き出します: 未検証、機械により確認済み、人によるレビュー済み——加えて生成（生成）、検証（検証）のリスト、クリックできるリンクとしての出典（出典）、ステータス（ステータス）、失効日（失効日）。 ステータス、失効日、OKFバージョン の各行は翻訳されたラベルで表示されます。ファイルに書かれるキー（status、stale_after、okf_version）は鍵アイコンのヒントに表示され、変わることはありません。

Plainvaが書き込むこと。

generated（そして出典が分かる場合はsources）は、正確に3つの機械による書き込み経路によって設定されます: インポーター（plainva-import/<version>、実行ごとに1つの時刻——インポートレポートにも記録されます）、メール取り込み（plainva-mail-capture/<version>、メッセージのMessage-IDを出典として）、タスク同期（plainva-task-sync/<version>、ノートを新規作成するときのみ）。
verifiedは信頼性と出所セクションの確認済みにするによってのみ書き込まれます: Plainvaは現在の時刻とともにhuman:<あなたの名前>をリストに追加します——2回目のレビューが1回目を上書きすることはありません。名前は保管庫ごとに一度尋ねられ、この端末に保存されます。設定 → 保管庫 → コンテンツと構造 → 確認者名で変更できます。
エディターはこれらのフィールドを自ら触れることはなく、既存のノートが後から書き換えられることもありません。statusとstale_afterはプロパティとして、またはフロントマターで自分で設定するものです。

バンドルのバージョンを更新する。 規約のバージョンはルートのindex.mdに一度だけ置かれます。まだ"0.1"を宣言している保管庫はそのまま変わらず動作します——設定 → 保管庫 → コンテンツと構造 → バンドルのバージョン（スマートフォンでは: 設定 → Vault → メンテナンス → バンドルのバージョン）で、**更新…**を使って0.2に引き上げます。ダイアログは事前に何が変わるかを示します: ルートのindex.md内の行、そしてチェックボックス（デフォルトでオン）として、まだ残っている旧okf_versionフィールドをノートから削除すること。すべてのファイルは変更前にバックアップされます。**クリーンアップ…**は2つ目の部分だけを行います。フィールド表と書き込みルールの詳細はファイル形式リファレンスにあります。

index.md: フォルダーごとの目次

index.mdはフォルダーの目次です: そのフォルダーに含まれるノートとサブフォルダーの一覧で、説明と相対リンクが付いています。

生成——常にあなたの操作に応じて、何もないところから自動的に生成されることはありません: フォルダーを右クリック → 概要を作成 / 概要を更新、またはまとめてindex.md管理（設定 → 保管庫 → コンテンツと構造）から行います。
生成の代わりに採用する——既に概要ノート（MOC、概要、フォルダーノート、READMEなど）がある場合、管理画面がそれらを候補として提案します。採用は、そのファイルをindex.mdに名前変更し（リンクは保管庫全体で更新されます）、任意でOKF向けに整えることもできます。
自動的な保守——Plainvaによって生成された一覧には、ファイルの末尾に不可視のマーカー（HTMLコメント）が付きます。このようにマークされたファイルのみ、フォルダーが変更されるたびに自動的に最新の状態に保たれます——そしてそれはOKF保管庫でのみです（ルートのindex.mdにokf_versionがあることで識別されます）。
読み取り専用と抜け道——管理されているindex.mdファイルは、「このindex.mdはPlainvaによって管理され、自動的に更新されます」というバナー付きの閲覧モードで開きます。そこでは更新を行うか——それでも編集するを選択できます: これによりマーカーが削除され、そのファイルは再び完全にあなたのものになります（自動更新はされなくなります）。
一括処理——すべてのindex.mdを更新は、保管庫のルートのコンテキストメニューと設定にあります。マーカーのないファイルはスキップされます。
抜けを埋める——index.md管理の中で、index.mdがないすべてのフォルダーに作成を使うと、まだindex.mdがないフォルダーがすべてあらかじめ選択されるので、一度の操作でまとめて作成できます。
スマートフォンでは — 同じことを二つの入口から。フォルダーを長押しすると、そのフォルダーに必要なほうに応じて概要を作成または概要を更新が示されます。保管庫全体をまとめて整えるときは 設定 → 保管庫 → メンテナンス → 概要 へ。概要のないフォルダーが先頭に並び、index.md がない N 個すべてのフォルダーに作成が一度に作ります。index.md を自分で書いたフォルダーは一覧に出ますが手は付けられません——引き継ぎはその一覧における名前の付いた判断であり、タップの副作用ではありません。自動更新もスマートフォンで動くようになりました。そこで編集した保管庫が、デスクトップで開くまで古いままということはもうありません。
閲覧モードでは、管理されている一覧はファイル/フォルダーアイコン付きのカードとしてレンダリングされます。リンクはPlainva内で直接開きます。

既存の保管庫を変換する（オプトイン）

保管庫内のファイルがOKF形式に適合していない場合（typeフィールドの欠落、または予約名が通常のノートとして使われている場合）、Plainvaは変換を提案します——保管庫を開いたときに一度、そして設定 → 保管庫 → コンテンツと構造で恒久的に（この項目は、何かすべきことがある間のみ表示されます）。

OKF形式に変換ウィザードは、明確なステップで動作します。

スキャン——影響を受けるファイル数を表示します（テンプレートフォルダーとシステムフォルダーは除外されます。Frontmatterが読み取れないファイルはスキップされ、決して「修復」されません）。
決定——typeがないファイルのデフォルトtype。既存のtypeの値はそのまま使用（推奨——既に有効なOKFタイプです）するか、別のフィールドに名前変更できます。
プレビュー（変更なし）——ドライランで、何が変更されるかを事前に確認できます。
変換——各ファイルは変更前に.plainva/backups/にバックアップされます。レポートには、何が変更され、何がスキップされたか、そしてバックアップフォルダーが要約されます。その後、任意でindex.md管理へ進むことができます。

ウィザードからのヒント: 変更は通常通り同期されます——Git保管庫の場合は事前にコミットしてください。

スマートフォンで

同じ経路はモバイルにもあります。設定 → Vault → メンテナンス → OKF形式に変換。手順は同じです——スキャン、選択、プレビュー、変換——そして何かが書き込まれる前に、プレビューが対象のノートを名前で示します。

スマートフォンはいつでもアプリをメモリから外せるため、二つの仕組みが加わります。

一時停止と続行。 一時停止をタップするか、アプリがバックグラウンドに回ると、処理は次のファイルで止まります。続行しても書き込み先は同じバックアップフォルダーです——二つ目はできません。
起動時に尋ねる。 処理が未完了のままなら、次にVaultを開いたときにPlainvaがそのことを伝え、続行または元に戻すを提示します。あとでも正当な答えです。中断された処理が残すのは、途中まで変換されたVaultであって、壊れたVaultではありません。追加されるのはfrontmatterのフィールドだけで、どのノートも有効なMarkdownのままです。

元に戻すはバックアップフォルダーからファイルを復元します——デスクトップでも同様に、処理後のレポートから行えます。バックアップフォルダーはその後も残ります。変換前の状態の唯一のコピーだからです。

OKFを使う必要があるか？

いいえ。OKFは緩やかな標準です。

新規ファイルには自動的にヘッダーが付与されます——これが邪魔になることはなく、コストもかかりません。
既存の保管庫（例えばObsidianからのもの）は変更なく引き続き機能します。変換は厳密にオプトインです。
okf_versionが欠落している——あるいは古いノートにまだ残っている——だけでは違反とは見なされません。PlainvaとObsidianを永続的に並行して使用でき、繰り返し通知されることもありません。
Obsidianや他のあらゆるエディターは、引き続きすべてのファイルを開くことができます: それは今も昔もごく普通のMarkdownです。