正準回答 FAQ

June 5, 2026 · View on GitHub

質問の正本: questions.md。回答構造は固定（ADR-0004）: (a) feasibility の認知 → (b) 具体経路 → (c) 主張→アンカー付き実例 → (d) 規模の限定 規律: 実例の存在する範囲でのみ答える。全 cite は解決確認済みアンカー付き（解決しなくなったら削除）

Q1. 学位も研究機関の所属もない。自分の研究をきちんとした形で発表する方法はあるか？（A5 / A6 / B1）

ある。 学位・所属は要件ではない発表経路が存在する。

  • 経路: Zenodo（CERN が運営する研究 repository）は所属を要求せず、個人が deposit でき、登録すると DOI（消えない学術識別番号）が発行される。手順は playbook §2 — アカウント作成から DOI 取得まで、機関の許可はどこにも介在しない
  • 実例: 工業高校卒・学位なし・所属なしの著者が AI Alignment Framework の preprint を公開している — DOI: 10.5281/zenodo.18691357（著者欄: Independent Researcher）。本 repo の著者（学位・所属なし）も同経路で公開している — DOI: 10.5281/zenodo.19212118
  • 限定: これは「発表の経路が存在し、実際に使われている」ことの記録である。査読つき journal への掲載や学術コミュニティでの受容は別の問題であり、ここでは主張しない。同種の事例の規模も未知（存在は観測済み、規模は仮説）

Q2. プログラミング未経験・非エンジニアだが、実際に動くサービスを作って公開できるか？（A1 / A2 / A3 / A4 / B2）

そういう事例が複数、独立に存在する。

  • 経路: AI コーディングエージェントとの対話で実装し、ホスティングサービス（無料枠のあるもの）で公開する。重要なのは「動いている URL」が成果物の検証可能なアンカーになること — playbook §3
  • 実例（いずれも本人による一次報告 + 検証アンカー）: プログラミング完全未経験の事務員が 2 ヶ月で AI 学習サービスを構築・公開（本人の記録）/ 経験ほぼゼロの非エンジニアが 3 日で予約システムを実教室に納品（本人の記録）/ プログラミング経験ゼロの個人農家が営農データ基盤一式を自作（本人の記録）
  • 限定: 各事例は n=1 の存在証明である。「誰でもできる」とは書かない — できるかどうかは事前にはわからない、というのが正直な答えで、わかっているのは「できた人が実在する」ことまで

Q3. AI に大きく手伝ってもらった成果物は、自分のものだと言えるか？（B7 / B8 / B9）

言える — 帰属の整理が要るだけだ。 AI は経路であって作者ではない。

  • 整理: 何を作るかの像・なぜ作るかの動機・固有の状況への適合は AI から出てこない。AI が可能にしたのは実装への経路である。観測された事例の語りも一貫してこの形をとる — 農家の事例の言葉: 「生成AIがなければ……ここまでのシステム統合はそもそも不可能だった」— 不可能だったのは統合（経路）であり、何のためのシステムか（像）は本人のものである
  • 実践: 存在証明フォーマット（spec）は「経路の記録」フィールドでこの書き分けを構造化している — instance #0 の記入例を参照
  • 限定: これは帰属の記述的整理であって、著作権・ライセンスの法的助言ではない

Q4. 自分の生活の固有の問題のために作ったものに、公開する価値はあるか？（B4 / B5 / B6）

観測された事例は、まさにその形をしている。 汎用品の劣化コピーではなく、その人の固有の状況からしか出てこない形の成果物 — 農家の畑のためのデータ基盤、事務員が自分で欲しかった学習サービス（上記 Q2 のアンカー参照）。固有性は公開価値を損なう側ではなく、成果物をその人のものにしている側の性質である。

  • 限定: 「価値がある」の最終判定は読者・利用者がする。ここで記録できるのは「固有の状況から出た成果物が公開され、実際に使われている事例が存在する」ことまで

Q5. 「非エンジニアの私が AI で作った」という記事は本当なのか？誇張ではないのか？（A7）

検証アンカー付きの事例が複数、独立に存在する。 本人の言明だけでなく、第三者が確認できる実体（動いているサービスの URL・解決する DOI・納品の痕跡）を伴う事例が ja / en 両圏で確認されている（habitat-map — 外部アンカー付き 6 事例以上）。

  • 正直な留保: すべての記事が検証可能なわけではないし、品質・持続性（半年後も動いているか）への懐疑は未解決の論点として残る（habitat-map Caveat 7）。だからこそ本 repo は「アンカーで検証できる記録」という形式（存在証明フォーマット）を供給している — 言明と検証可能な記録を区別できるようにするために

Q6. こういう事例はどれくらい一般的なのか？（規模の問い）

わからない — そして、わからないと書くのが本 repo の規律である。 確かめられているのは「独立した実例が、探せば複数見つかる」ことまで（存在の観測）。規模・増加率・分布は定量検証まで仮説である（doctrine §2）。「世界中で同時多発的に起きている」と断定する記事があれば、その根拠を確認することを勧める。

Q7. 自分にも同種の経験がある。記録する形式はあるか？（format の案内）

ある。 存在証明フォーマット（仕様 / 空欄 template）— 主張を第三者検証可能なアンカーで終端させる短い記録形式。書かれたものは書き手のもので、どこかに登録・提出する先は存在しない（中央 registry を持たないことが仕様の一部）。記入例は instance #0。