playbook

June 5, 2026 · View on GitHub

位置づけ: 存在証明フォーマット spec の各フィールドに対応する how-to（doctrine §7 T3 — T1 従属）。 原料はすべて既存の公開手順・実体験であり、新規の発明はない。tool 名は example であって要件ではない（tool-agnostic）。 これは「こうすればあなたも成功する」という約束ではない。「実際に使われた経路はこうだった」という記録である。

§1. 「書き手の位置」の書き方

  • 成果物領域に相対的に書く。全人生の credential を列挙する必要はない — 作ったものの産出をゲートしてきた種類の credential（学位・所属・職業訓練）の不在だけが対象
  • 他領域の職業・経験は肯定形で書いてよい（「事務員である」「農家である」）。書かなくてもよい
  • 何も名乗らなくてよい。この欄は事実の記述であってラベルではない（spec §3）。「私は〜型の人間だ」という自己分類は要求されない

§2. アンカーの取り方 (a) — DOI（研究・著作の場合）

学位・所属なしで DOI を取得する実際の経路（instance #0 と habitat 事例が使用したもの）:

  1. Zenodo（zenodo.org — CERN 運営の研究 repository）にアカウントを作る。所属の入力は要求されない
  2. 成果物（PDF / repository）を deposit する。メタデータ（タイトル・著者名・abstract・license）を記入する
  3. publish すると DOI が自動採番される。費用は無料。機関の許可はどの段階にも介在しない
  4. 以後この DOI が「番号をたどれば実物に行き着く」恒久アンカーになる。バージョン更新しても concept DOI（常に最新版に解決する番号）は不変
  • 補助 tool の例: GitHub repository と Zenodo を連携させると、release tag を打つだけで自動 deposit される（instance #0 の運用）。必須ではない
  • 著者表記に所属がない場合、Zenodo の著者欄はそのまま空でよい。「Independent Researcher」と書いた実例もある（DOI: 10.5281/zenodo.18691357）

§3. アンカーの取り方 (b) — live deploy（ソフトウェアの場合）

「動いている URL」を成果物のアンカーにする:

  1. AI コーディングエージェントと作ったアプリケーションを、無料枠のあるホスティング（example: Vercel / Cloudflare Pages / GitHub Pages — いずれも個人で契約でき、審査・所属確認はない）に deploy する
  2. 公開 URL が第三者検証可能なアンカーになる。あわせて repository を公開すれば二重のアンカーになる
  3. アンカーは生かし続ける義務を伴う: サービスを畳んだら、その主張は失効する（spec §4）。失効した行は削除するか、公開 repository 等の別アンカーに差し替える

§4. アンカーの取り方 (c) — 納品・採用の痕跡

実ユーザーへの納品を主張にする場合、アンカーは納品先の側に立てる必要がある（自分のスクリーンショットはアンカーにならない — 第三者が書き手の協力なしに検証できないため）:

  • 納品先の公開ページに成果物が載っている / 納品先・利用者が公開の場で言及している — これらはアンカーになる
  • それが得られない場合、その主張は書かない（アンカーのない主張は format に含めない）。納品の事実が消えるわけではない — 検証可能な記録にならないだけである

§5. 「経路の記録」の書き方 — 帰属の整理

AI は経路であって作者ではない、という書き分け（FAQ Q3 / doctrine §2 条件 3）:

  • AI から出てこなかったものを一行書く: 何を作るかの像、なぜ作るかの動機、固有の状況への適合
  • AI が可能にしたものを一行書く: 実装への経路、統合、これまで届かなかった部分
  • 使った tool 名は書いても書かなくてもよい。tool 名は時間とともに古びるが、経路の構造（像は自分・実装が AI）は古びない

§6. 限定文 — なぜ削ってはいけないか

定型 2 文（規模の限定・収益の境界線）は飾りではない:

  • 規模の限定がないと、n=1 の記録が「みんなできる」という一般化に読まれ、記録の信頼性そのものが下がる。正直な限定は記録を弱くするのではなく、検証可能な部分を際立たせる
  • 境界線がないと、「AI で稼ぐ」系の語りと同じ棚に置かれる。語りの中心が制作物か金銭か、は読者が最初に見分ける軸である（habitat-map §5 — 実在の事例群は語彙レベルで income 語りと分離していた）

§7. 機械可読 fragment の作り方

spec §6 の JSON-LD をコピーして値を埋める。注意点は一つだけ — affiliation フィールドを足さないこと。「無所属」と書くのではなく、フィールド自体を置かない（proof-structure §2）。

検証: 埋めた JSON が valid か（オンラインの JSON-LD playground 等に貼れば確認できる）、identifier の URL が実際に解決するか、の 2 点。

付録 — instance #0 という実走例

本 playbook の全節は instance #0 で実走されている: §1 = 学位・所属・職歴なしの相対的記述 / §2 = Contemplative Agent の Zenodo DOI / §3 = pdf2anki の公開 repo / §5 = 「像は以前からあった、届かなかったのは実装」/ §6 = 定型 2 文 / §7 = affiliation 不在の fragment。