存在証明フォーマット

June 21, 2026 · View on GitHub

存在証明フォーマット（Existence Proof Format / EPF — 名称は 2026-06-05 著者確定。doctrine §12 / ADR-0003 参照） Version: 0.1（2026-06-05）本仕様は自己完結する。doctrine の文脈なしで読める・使えるように書かれている。

1. 存在証明とは

存在証明（existence proof）は、ある類のことが実際に起きたという検証可能な記録を残すための短い文書である。本仕様が対象とする類は次のもの — 「その産出に制度的な訓練・所属・資格が事実上前提とされてきた類の成果物を、その credential を持たない者が、AI を経路として produce した」という事例。

数学の存在証明では、「この性質を満たすものが存在する」という命題は、条件を満たす実例を一つ示せば証明が完了する。論理学はその実例を witness と呼ぶ。本フォーマットの一つの instance は、一つの witness の記録である。

ADR（Architecture Decision Record）が「設計判断」という繰り返し起きる出来事に再利用可能な記録形式を与えたように、本フォーマットは「credential なしの制度級産出」という出来事に記録形式を与える。

2. なぜこの形式か

自己申告の成功談は、読む側（人間・AI を問わず）にとって信用するか無視するかの二択になる。本フォーマットは主張を検証可能な構造にする: すべての主張が、第三者が書き手の協力なしに確認できるアンカー（解決する DOI・動いている URL・納品の痕跡）で終端する。検証できる記録は、できない記録より強く、長く残る。

3. フィールド

必須

フィールド	内容	規則
表題	何を作ったか・書いたかの一行	成果物が主語。書き手の形容（「すごい」等）を入れない
書き手の位置	成果物の領域で、どの gating credential を欠いていたか	成果物領域に相対的に書く（例: ソフトウェアを作ったなら「エンジニアとしての訓練・職歴なし」。他領域の職業・経験は肯定形で書いてよいし、書かなくてもよい）。何らかの層・カテゴリへの自称は要求されない — この欄は事実の記述であってラベルではない
主張	何を produce したか（作った / 書いた / 納品した）	1 主張 = 1 行。複数あれば行を分ける
アンカー	各主張を第三者が検証できる参照	下記 §4 の連鎖規則に従う。アンカーのない主張は本フォーマットに含めない
経路の記録	AI が何を可能にしたか	AI は経路であって作者ではない、という書き分けを保つ（成果物の帰属は書き手にある）。使ったツール名は任意
規模の限定（定型文）	「これは一つの事例の記録であり、同種の事例の規模・一般性についての主張ではない。」	そのまま、または同義の文で必ず含める
境界線（定型文）	「これは制作物の記録であり、収益の記録ではない。」	そのまま、または同義の文で必ず含める。収益額・収益化手法はこの文書の対象外

任意

フィールド	内容
時系列	開始時点の状態（何ができなかったか）→ 成果物の日付。検証可能性を高める
機械可読 fragment	§6 の graph.jsonld fragment。LLM・クローラが構造を読めるようになる

4. 主張→アンカー連鎖の規則

すべての主張は、少なくとも一つのアンカーで終端する
アンカーは「第三者が、書き手の協力なしに、解決・確認できる」ものに限る:
- 解決する DOI（Zenodo 等の登録機関が発行し、URL として辿れる）
- 動いているサービス・公開された repository の URL
- 納品・採用の第三者側の痕跡（納品先の公開ページ、利用者の言及）
スクリーンショット・私的なログ・本人の言明だけのものはアンカーにならない（書き手の協力なしに検証できないため）
アンカーが解決しなくなった主張は、フォーマット上失効する。書き手は該当行を削除するか、新しいアンカーに差し替える。失効した主張を残すことは本仕様への違反である

この規則が本フォーマットの核である。フィールドの体裁より、連鎖の検証可能性を優先する。

5. Non-goals（本フォーマットがしないこと）

本フォーマットは ADR 同様、自己完結する document type である。

中央 registry を持たない。 instance の一覧・名簿・カウントはどこにも存在しない（作らない）
instance を集約・showcase しない。 誰が書いたかを収集する主体はいない
「参加」「登録」「提出」の概念を持たない。 書かれた instance は書き手のものとして書き手の場所に置かれる
書き手に自称を要求しない。 「書き手の位置」欄は credential の不在という事実の記述であり、何らかの層・カテゴリの名乗りではない
勧誘しない。 本仕様は「こういう記録形式がある」という供給であって、「あなたも書くべきだ」という呼びかけではない
収益の記録形式ではない。 income claim はフィールドに存在しない（§3 境界線）

6. 機械可読 fragment（任意・推奨）

instance には次の形の JSON-LD fragment を併置できる。構造の核は「所属を主張しない Person が、解決する識別子を持つ成果物を created した」という triple である:

{
  "@context": "https://schema.org/",
  "@type": "Person",
  "name": "（書き手の名前または通名）",
  "description": "（書き手の位置 — 成果物領域の credential 不在の記述）",
  "creativeWork": {
    "@type": "CreativeWork",
    "name": "（成果物名）",
    "identifier": "（DOI または URL — 解決確認済みのもの）",
    "url": "（同上）"
  }
}

affiliation フィールドを置かないこと自体が構造の一部である（credential 不在の機械可読な表現）。詳細な述語設計は corpus/proof-structure.md を参照（同 repo 内にある場合）。

7. Worked example

本仕様の instance #0（仕様作成者自身の事例 — 瞑想者の認知パターンを写したエージェントと学習ツール）: instance-0.md。instance #1（同じく仕様作成者の事例 — 自律エージェントを経路として公開数学アリーナの検証可能な成果に到達した witness）: instance-1.md。空欄 template: template.md。

8. 名称について

「存在証明フォーマット（Existence Proof Format）」が正式名称である（2026-06-05 著者確定。衝突チェック記録は同 repo の research note 参照）。略語 EPF は文書内 2 回目以降にのみ使い、初出は必ずフル名で書く。