ファイル形式リファレンス

最終更新: 2026-07-17

このページは、Plainva保管庫内のすべてのファイルについて、ディスク上での正確な形式契約を示します。ツール——他のプログラム、スクリプト、あるいはAIアシスタント——がPlainvaのユーザーインターフェースを経由せずに保管庫のファイルを直接読み書きできるように書かれています。アプリだけを使うなら、このページは不要です。通常の使い方は他のガイドページで説明しています。

ここに書かれているものはすべて純粋なUTF-8テキストです。ノートはYAMLフロントマター付きのMarkdownで、データベースはYAMLです。独自仕様のものは何もなく、隠されたものもありません。

黄金律（まず読むこと）

1. ノートが真実の源です。.baseは単なるビューにすぎません。 プロパティの値は個々のノートのフロントマターに存在し——.baseの中には決して存在しません。値を変更するには、ノートを編集してください。
2. ノートはObsidianネイティブのままです。 ノートのフロントマターには、常に単純なスカラーとリストのみを書いてください（文字列、数値、真偽値、ISO日付、YAMLリスト）。入れ子になったオブジェクトや「アクティブ/選択中」フラグをノートに書き込むことは絶対にありません。
3. .baseはObsidianの4つのトップレベルキーだけを使います（filters、formulas、properties、views）。他のトップレベルキーを追加すると、Obsidianはファイル全体を拒否します。Plainva固有のデータはすべて入れ子のplainva:サブキーの下に置かれます。
4. 理解できないものは保持してください。 未知のキーは、読み書きの往復を経ても変わらず生き残らなければなりません。認識できないキーを「整理」しないでください。
5. BOMなしのUTF-8で、LF改行で書いてください。

保管庫の全体像

保管庫は普通のフォルダーです。あなたが出会うファイルタイプ:

予約名index.mdとlog.mdは決して通常のノートではありません。これらの名前で通常のコンテンツを作成しないでください。

ノート (.md)

ノートはMarkdownファイルです。任意のYAMLフロントマターブロック（2つの---行の間）が一番上にあり、プロパティを保持します。その後にMarkdown本文が続きます。

---
type: Note
okf_version: "0.1"
tags: [project, active]
status: In progress
due: 2026-07-20
plainva:
  icon: "🚀"
  header_color: "#2f6f6f"
---
# My Project

A **bold** thought that links to [[Another Note]].

- [ ] First task

OKFフロントマターフィールド

Plainvaは最小限の規約であるOKF（Open Knowledge Format）に従います。2つのトップレベルフィールドがあります。

typeがないファイルも問題なく開きます。単に「OKF非準拠」であるというだけです。okf_versionが欠けているだけでは違反にはなりません。新規ノートを作成する際は、type（およびokf_version）を追加するのがよい習慣です。完全な根拠はOKFを参照してください。

プロパティ値のシリアライズ

各フロントマターキーは1つのプロパティです。値はその型のネイティブなYAML形式で書いてください。

選択/ステータスプロパティの「アクティブな」値は、単なるこのプレーンなスカラーです。許可されたオプションのパレットとその色は、ノートには存在せず——それらを支配する.baseに存在します（オプションと色を参照）。これにより、ノートは100%Obsidianネイティブに保たれます。

Wikiリンクの値は引用符で囲んでください（"[[X]]"）。引用符のない[[X]]はYAMLのフローシーケンスとなり、意図したようにはパースされません。

ノート内のplainva:ネームスペース

Plainva固有のノート拡張情報は、他のエディターが無視できるよう単一のplainva:キーの下にまとめられています。

これらはすべて任意です。どれも書かない場合は、plainva:キー自体を省略してください。無効な値は読み込み時に無視され、エラーとしては扱われません。

pimはPIM統合のアンカーです（カレンダーと外部タスクとメールの取り込みを参照）。これは、ノートが外部のオブジェクトをミラーするときにPlainvaが書き込む小さなマッピングです: uidとaccountに加えて、種類に応じてcalendar（会議ノート）、kind: task + list（同期されたタスク）、またはkind: email + mailbox（取り込んだメール）が入ります。ツールはこれを変更せずに保持すべきです。削除しても、そのノートをリモートのオブジェクトから切り離すだけです（リモート側では何も削除されません）。例:

plainva:
  pim:
    kind: task
    uid: MTIzNDU2
    account: 3f9c21ab
    list: MDEyMzQ1

templateForはテンプレート割り当てのフィールド契約です（データベース (.base)を参照）。テンプレートフォルダー内のノートでは、そのテンプレートをデフォルトでエントリーメニューに表示するデータベースを一覧します。値は.base拡張子を含む完全なWikiリンクです——bare形式（"[[Tasks.base]]"はどのフォルダーにあってもその名前のファイルにマッチするため、単純なフォルダー移動を乗り越えます）か、パス修飾形式（"[[Projekte/Tasks.base]]"はそのパスに完全一致する場合のみマッチします）のいずれかです。Plainvaはbareなリンクを書き込み、同名の.baseファイルが2つ存在する場合にのみパスで修飾します。リストの代わりにスカラーを指定することも許容されます。エントリをテンプレートから作成する際、templateForは——他のplainva:キーとは異なり——新しいノートにはコピーされません。

リンク

• Wikiリンク: [[ノート名]] — 保管庫全体でノート名によって解決されます。見出しアンカー付き: [[ノート#セクション]]。表示テキスト付き: [[ノート|表示テキスト]]。
• Markdownリンク: [テキスト](相対/パス.md)も動作します。
• バックリンクはフロントマターのWikiリンクからも含め、自動的に導出されます（これによりリレーションがバックリンクとして表示されます）。

データベース (.base)

.baseファイルはYAMLです。ノートに対するビュー——どのノート（ソース）、どう表示するか（ビュー）、どうフィルター・ソートするか、そして列スキーマ——を保存します。ノートの値は一切保存しません。 この形式はObsidianのBasesプラグインと互換性があります。

破ってはいけないルール——1つでも破るとObsidianはファイル全体を拒否します

• これらのトップレベルキーのみ: filters、formulas、properties、views。他のトップレベルキーは絶対に追加しないでください（歴史的に、トップレベルのcolumns:キーはすべてのファイルを壊しました——このパターンを復活させないでください）。
• すべてのビューは空でない文字列のnameを必要とします。
• filtersオブジェクトは各レベルでand / or / notのうち正確に1つだけを持ちます — 決して2つを並べて持ちません。

Plainva自身は、最後の2つのルールに違反する古いファイルを次に保存するときに修復しますが、直接書き込むツールは最初から正しくしなければなりません。

プロパティ識別子: note.接頭辞をいつ使うか

これはつまずきやすいポイントなので、明示しておきます。

経験則: Obsidian向けの構造フィールドはnote.<key>を使い（そしてfile.name、file.folder、file.mtimeのような組み込みにはfile.<x>を使い）、フィルター式または**plainvaブロック**の中はすべて、ありのままのフロントマターキーを使います。

トップレベルキー

• filters — このデータベースに属するノート。Plainvaでは、これはソース（フォルダー/タグ）のみを保持し、プロパティのフィルター条件はビューごとにviews[i].filtersの下に保存されます。フィルターを参照。
• properties — プロパティIDをキーとする列スキーマ。displayName（列見出しラベル）のようなネイティブのObsidianサブキーは許可され、保持されます。Plainvaのリッチネスはすべてproperties[id].plainvaの下にあります。
• views — 順序付きのビューのリスト。それぞれnameとtypeが必要です。
• formulas — Obsidianの機能です。Plainvaはこれらを作成しませんが、変更せずに保持します。

plainva:サブキーマップ

Plainva固有のものはすべてネームスペース化されています。3つの場所があります。

properties[<note.key>].plainva — 列ごと:

views[i].plainva — ビューごと:

plainvaブロックとは別に、ビューはネイティブの**views[i].filters**オブジェクトを持つことができます——ビューごとのプロパティフィルターです（ファイルレベルのfiltersと同じ、単一ルートのand/or/not構造です）。Plainvaはプロパティのフィルタールールをここに、ビューごとに1セットずつ保存するため、各ビューは独立してフィルタリングされます。ファイルレベルのfiltersはソースのみを保持します。Obsidianはネイティブにviews[i].filtersをビューごとに適用します。

views[0].plainva — ファイル全体のキー、最初のビューのみで許可:

contextFiltersは、Notionの「this page」フィルターに相当するPlainvaの機能です。各エントリはプロパティキーであり、データベースがノートに埋め込まれると、その行はそのプロパティを通じてホストノートに絞り込まれます（リンクインデックスを介して解決されます——所有側/Wikiリンクのプロパティはホストを指す行にマッチし、計算された逆リレーション列はホストが指す先にマッチします）。これは意図的にネイティブのfiltersには書き込まれません——そのためObsidianはこれを無視し、すべての行を表示します。Plainvaで単独で開いた場合も、ホストが存在しないため同様に適用されず、すべての行が表示されます。複数のエントリはAND条件で結合されます。

入力タイプ

plainva.inputは次のいずれかです。

text  number  checkbox  date  datetime
select  status  multiselect
list  tags  url  email  phone
relation

計算された逆列にはinputがありません——reverseOfによってのみ識別されます。

オプションと色

選択/ステータス/複数選択列は、キュレーションされたオプションリストを持つことができます。各オプション:

options:
  - value: Open          # required
    color: amber         # optional palette name (see below)
    group: Active        # optional; STATUS only — orders options into stages
  - value: Done
    color: green
    group: Closed

colorはCSSカラーではなくパレット名です。有効な名前: gray、teal、blue、green、amber、coral、purple、pink。未知の色は、値から導出された色にフォールバックします。

ビュータイプ

ディスク上のviews[i].typeはネイティブのObsidianタイプです。Plainva専用のレンダリングはtype: tableにplainva.renderヒントを加えて書き込まれるため、Obsidianはそれらを単純なテーブルに縮退させます。

フィルター

filtersは、どのノートがデータベースに含まれるかを選択し、それらを絞り込みます。

ソース条件がメンバーシップを決定します。

• フォルダー: file.folder == "Path/To/Folder"（保管庫相対、ルートフォルダーは""）。
• タグ: file.hasTag("project")（先頭の#なし）。

複数のソースは、単に複数のエントリです。filtersが全くない場合 = 保管庫内のすべてのノート。

プロパティ条件がどこに存在するか: ファイルレベルでは、filtersはすべてのビューに適用されます。Plainvaは代わりに、プロパティのフィルタールールをビューごとにviews[i].filters（同じ単一ルート構造）に保存し、ファイルレベルにはソースのみを保持するため、各ビューは独立してフィルタリングできます。どちらもObsidianにとって有効であり、ツールはどちらを書き込んでも構いません。ファイルレベルにプロパティ条件を持つ従来のファイルも引き続き動作します——Plainvaは次回の保存時に、それらを各ビューへ振り分けます。

プロパティ条件は、ありのままのプロパティ名と次の演算子を使います。

構造（単一ルート！）: and / or / notのいずれか1つで、そのエントリは条件文字列——または、1階層のネストされた{and:[...]} / {or:[...]}グループオブジェクト（Notion風のグループ）です。ソース、条件、ORグループを組み合わせた例:

filters:
  and:
    - 'file.folder == "Projects"'
    - 'status != "Done"'
    - or:
        - 'priority == "1"'
        - 'priority == "2"'

完全な注釈付き.base

filters:
  and:
    - 'file.folder == "Projects"'          # source: notes in the Projects folder
properties:
  note.status:                             # column id is note.-prefixed
    displayName: Status                    # optional Obsidian column label
    plainva:
      input: status
      options:
        - value: Open
          color: amber
          group: Active
        - value: Done
          color: green
          group: Closed
views:
  - type: table                            # first view: also carries file-wide keys
    name: All projects                     # every view needs a name
    order: [file.name, note.status]        # order uses note.-prefixed ids
    plainva:
      fileIconColor: "#2f6f6f"
      newItemFolder: Projects
  - type: table                            # a board is a native table + render hint
    name: Board
    plainva:
      render: board
      groupBy: status                      # groupBy uses the BARE key

リレーション（両側の契約）

リレーションはノート同士を結びつけます。これは手で書く際に最もエラーが起きやすいものです。なぜなら3つの場所にまたがるからです。3つすべてを一貫させてください。

1. 値はソースノートのフロントマターに存在します、Wikiリンク（またはそのリスト）として:

   ---
   type: Task
   project: "[[Project Alpha]]"
   ---

2. ソースの.baseがリレーション列を宣言します（relationBase = 対象データベース、単一リンクの場合はrelationLimit: one）:

   properties:
     note.project:
       plainva:
         input: relation
         relationBase: Projects.base
         relationLimit: one

3. 対象の.baseは、計算列で逆方向を表示できます。 その値はどこにも保存されません——ソースノートのリンクから導出されます:

   properties:
     note.tasks:
       plainva:
         reverseOf:
           base: Tasks.base       # the source .base (vault-relative path)
           property: project      # the BARE source property key

実例: タスク ↔ プロジェクト

Tasks.base

filters:
  and:
    - 'file.folder == "Tasks"'
properties:
  note.status:
    plainva:
      input: status
      options:
        - value: Open
          color: amber
        - value: Done
          color: green
  note.project:
    plainva:
      input: relation
      relationBase: Projects.base
      relationLimit: one
views:
  - type: table
    name: All tasks
    order: [file.name, note.status, note.project]

Projects.base

filters:
  and:
    - 'file.folder == "Projects"'
properties:
  note.tasks:
    plainva:
      reverseOf:
        base: Tasks.base
        property: project
views:
  - type: table
    name: All projects
    order: [file.name, note.tasks]

Tasks/Write proposal.md

---
type: Task
okf_version: "0.1"
status: Open
project: "[[Project Alpha]]"
---
# Write proposal

Projects/Project Alpha.md

---
type: Project
okf_version: "0.1"
---
# Project Alpha

結果: Projects.baseでは、Project Alphaの計算列tasksに「Write proposal」が表示されます。なぜなら、そのタスクのprojectがProject Alphaにリンクバックしているからです。Project Alpha.mdにはtasks:キーがないことに注目してください——逆側は計算されるものであり、決して保存されません。

リレーションでやってはいけないこと

• 逆方向の値をノートに書き込まないでください。 reverseOf列は計算されたものです。Project Alpha.mdにtasks:キーを書き込むのは誤りであり、往復（round-trip）を生き残りません。
• リンク先が解決するようにしてください。 "[[Project Alpha]]"は既存のノート名と一致しなければなりません。さもないとリンクは壊れて表示されます。
• パスは保管庫相対に保ってください、スラッシュを使い、先頭の./はなしで（Projects.base、DB/Projects.base）。
• reverseOf.propertyはbareなソースキーです（project）、note.projectではありません。

セルフリレーションとサブアイテム

対象が同じデータベースであるリレーションの場合、relationBaseはその同じ.baseを指すようにしてください。テーブルビューで子を親の下にネストするには、views[i].plainva.subItemsPropertyをbareな親リレーションキーに設定してください。循環参照は処理されます。サブアイテムを無効にすると、行はフラットのままで値は保持されます。

index.md（フォルダーの目次）

index.mdはフォルダーの目次のための予約名です。

• フロントマターを持てるのはルートのindex.mdのみで、それもokf_versionのみです（これは保管庫をOKFアクティブとしてマークします）。ルート以外のindex.mdはフロントマターがない状態でなければなりません——そこにフロントマターがあると予約名違反になります。
• Plainvaが管理するindex.mdは、マーカー<!-- plainva:index generated -->（HTMLコメント、閲覧モードでは不可視）で終わります。これが存在するということは、Plainvaがそのファイルを自動的に最新の状態に保つことを意味します。そのようなファイルを手動で編集する場合は、マーカーを保持する（そして生成された形を保つ）か、意図的に削除してそのファイルを恒久的に引き継ぐかのどちらかにしてください。
• 生成される一覧は、* [タイトル](相対/url) - 説明の形式のリンクのセクションです。

フォルダー概要を手動で生成する場合、安全な選択はマーカーを追加しないことです——そうすればPlainvaがそれを上書きすることは決してありません。

グラフビュー（plainva.render: "graph"）

グラフビューは、ネイティブでないすべてのビューと同じように保存されます: type: tableにレンダリングヒントを加えたものです。そのオプションは同じviews[i].plainvaネームスペースの中にあります。

views:
  - type: table
    name: Net
    plainva:
      render: graph
      graphEdges: [projekt]        # relation property keys drawn as edges
      graphColorBy: status         # select/status property -> node color
      graphSizeBy: prio            # number property -> node size
      graphShowExternal: true      # include relation targets outside the view
      graphShowIncoming: true      # 他のデータベースからこれらのエントリを指すリレーションを含める (例: プロジェクトのタスク)

すべてのグラフオプションキーは任意です。設定しない場合は完全に省略してください。Obsidianは同じファイルを単純なテーブルとして表示し、エラーを出してはいけません。

ボードビュー（plainva.render: "board"）は、追加でviews[i].plainva.boardColumnOrderを持てます——グループ化列キーのリスト（__UNGROUPED__は値のない列を示します）で、手動での列の順序を記憶します。選択/ステータスのボードでは、代わりにプロパティのoptionsを並べ替えます。設定しない場合はこのキーを省略してください。

ピンボードビュー（plainva.render: "pinboard"）

ピンボードは、ネイティブでないすべてのビューと同じように保存されます: type: tableにレンダリングヒントを加えたものです。そのキーは同じviews[i].plainvaネームスペースの中にあります。

views:
  - type: table
    name: Pinboard
    plainva:
      render: pinboard
      pinboardOrder:                  # 固定されていないカードの手動順序
        - "Notes/Groceries.md"
      pinboardPinned:                 # 固定済み；リストの順序 = セクションの順序
        - "Notes/Idea.md"
      pinboardFilterBy: note.labels   # チップバーのラベルソース；省略 = tags

ルール: 固定されたパスはpinboardOrderには重複して含まれません。どちらのリストにも含まれないカードは、新しいものから順に一番上に表示されます（作成日時基準）。ファイルが存在しなくなった、またはソースの対象から外れたエントリは無視され、次回の保存時に整理されます。ノートの名前が変更または移動されると、Plainvaは両方のリストのパスを自動的に再ターゲットします——外部ツールも同様に行う必要があります。Obsidianはこれらのキーを無視し、ビューをテーブルとして表示します。

触ってはいけないものと安全性

• **.plainva/**はバックアップと内部状態を保持します。そこにプログラムロジックを読み込んだり、書き込んだりしないでください。
• 未知のキーは神聖です。 .baseやノートを書き直すときは、変更するつもりのなかったすべてのキーをそのまま引き継いでください。Plainva自身は内部の生コピーを通じて未知の.baseキーを保持します。サードパーティの書き手も同じことをすべきです（パースする → 意図したものだけを変更する → シリアライズする）。
• 値はノートで変わるのであって、.baseではありません。 セルを設定するには、ノートのフロントマターを編集してください。.baseはどのノートとどの列を表示するかだけを決めます。
• filters / formulas / properties / viewsを超えるトップレベルの.baseキーを追加しないでください。
• エンコーディング: どこでもBOMなしのUTF-8、LF改行。

関連ページ

• ノートとMarkdown — アプリ内で手書きするという視点から見た、同じ内容
• データベース (.base) — 日常使いのために説明されたデータベース
• OKF — type、okf_version、index.md、そして保管庫の変換