コードではなく、企画のファイルが正。ただし霧走町の第一章は、逆向きに作った
The plan files, not the code, are the source of truth — except chapter one of Kiribashiri, built the other way round
D30-3-T59-spec-driven-development・技術・日本語入力でプレイする仕組み
作品を作る前に、企画のファイルを機械で検査します。
真相が明かされない、たどり着けない手がある、疑いが崩せない。そういう欠陥は、台本を書いてからでは高くつくからです。
ただ、霧走町の第一章だけは、先にゲームができていて、企画はあとからゲームのデータから起こしました。
この回の位置と、前後の回#
区切り: T58〜T64 作り方と周辺（7 回のうち 2 回目）
先に読むとよい回: T58（通った台詞だけを採る）
次に読む回: T60（骨を先に機械で起こす）
名前 — spec-driven development#
- 正式名
- spec-driven development（略 SDD。仕様駆動開発）
- 初出
- 学術の初出はありません。2025 年に、生成 AI のコーディングの道具の側から広まった名前です
- 代表例
- GitHub Spec Kit（2025 年 9 月初めに公開。Specify・Plan・Tasks・Implement の段）、AWS Kiro（2025 年 7 月中旬に公開プレビュー。コードの前に要求・設計・作業の一覧を作る）
- 段の分け方
- Birgitta Böckeler, "Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl"（martinfowler.com、2025 年 10 月）の spec-first・spec-anchored・spec-as-source
spec-driven development とは#
spec-driven development（略 SDD。仕様駆動開発）とは、コードを書く前に仕様を書いて版管理し、生成 AI のエージェントにはその仕様から実装させる開発の進め方です。
コードを書く前に、仕様を書く。
その仕様を版管理し、生成 AI のエージェントには仕様から実装させる。
解説記事の言い方では「実行できて、版管理された仕様が単一の正であり、コードではない」。
これが 2025 年に前へ出た理由は、よくこう説明されます。
エージェントはコードを書くのは得意だが、何を意図したかを当てるのは苦手。
だから意図を先に、機械が読める形で書いておく。
Spec Kit は、仕様・技術の計画・小さな作業の 3 つに分け、段ごとに確認の関門を置きます。
Kiro は、短い指示からユーザーストーリーを作り、受け入れ基準を EARS という記法で書きます。
Böckeler は、SDD を 3 段に分けました。
- spec-first: 仕様を先に書いて作業を進める。仕様は機能ができたら捨ててもよい
- spec-anchored: 作業が終わっても仕様を残し、機能を変えるときは仕様から変える
- spec-as-source: 人は仕様だけを編集し、コードは仕様から生成する
そして「見つけた SDD はどれも spec-first だが、全部が spec-anchored や spec-as-source を目指してはいない」と書いています。
時間が経ったあとの仕様の保守は、曖昧なまま残されがちだ、とも。
よく知られた弱点は 2 つです。
仕様とコードがずれていく（仕様のドリフト）。
そして、仕様を書く手間が前に寄るので、小さな変更には重い。
Böckeler は、上の 2 段はモデル駆動開発の弱点（硬さ）と LLM の弱点（非決定）の両方を抱えうる、とも書いています。
うちの企画のファイル#
推理アドベンチャーでは、コードにあたるのは作品データ（Game/adv-<work>/ の JSON。意図・台本・フラグ・場所）です。
仕様にあたるのが、企画のフォルダ Plots/<work>/ です。
霧走町の企画は 4 つのファイルを道具が読みます。
- s_01_overview.md: 冒頭の front matter に、ジャンル・時代・調子・章の数・形式・主人公・入力の案内（genre・era・tone・chapters・episodes_per_chapter・interactive・format・protagonist・inputHint）
- s_02_characters.md: 人物。見出しを「## 表示名（id）— 場所」の形にしたときだけ、道具が id を拾えます
- s_03_plot.md: 章ごとの筋。何をすると何が開き、どこで詰まり、どう救うか
- s_09_beats.json: 手のグラフ（adv-beats/1）
中心は s_09 です。欄はこうなっています（数は 2026-10-29 に数えた）。
origin 作品の設計値（主型・動機・反転位置・targetBeats 70・places "10-12"）
clearFacts クリアの条件になる事実（1）
facts 事実の一覧（81） { id, text, from }
places 場所（10） { id, name, gives, opensAfter, events, props }
people 人物（8） { id, name, at, appearsAfter, knows, hides }
misleads 誤導（9） { suspect, raisedBy, brokenBy, note }
beats 手（137） { id, verb, target, at, who, gives, needs, until, repeats }
第一章の手を 2 本だけ写します。
{"id": "saeki.alibi_night", "verb": "saeki", "target": "事件の夜の居場所", "at": "port", "who": "saeki",
"gives": ["f_saeki_alibi_10pm", "f_saeki_admits_8pm"], "repeats": 2}
{"id": "saeki.confront_alibi", "verb": "saeki", "target": "番屋を出た時刻の食い違い", "at": "port", "who": "saeki",
"gives": ["f_saeki_alibi_broken"]}
港で佐伯に事件の夜の居場所を聞くと「10時まで番屋」が手に入り、食い違いをぶつけると崩れる。
gives が「その手で分かる事実」、needs が「その手を打てる前提」です。
事実の側は、たとえば宿に入るだけで分かる事件の概要。
{"id": "f_case_briefed", "text": "事件の概要（被害者・現場・署の見立て）を把握した", "from": "章1"}
設計値は入力側のファイルに書きます。
目標の手数は、2026-08-17 まで企画の検査の引数の既定値 70 にしかありませんでした。
「この作品は何手を狙ったのか」をあとから読み出せないので、origin.targetBeats へ移しました。
検査の注記は「作品の設計値なのに呼び出し方でしか決まらず」と書いています。
企画を、作る前に検査する#
Scripts/adv-plot-check.mjs が企画を検査します。規則はこうです。
P0 参照の実在（at／needs／gives／opensAfter が実在の id か）
P1 真相の要素が、どれかの手で明かされるか
P2 needs に循環が無く、全ての手に到達できるか（clearpath の企画版）
P3 疑いが崩せるか（brokenBy が raisedBy より後に到達する）
P4 場所を開く手が、その場所の外にあるか（自己矛盾）
P5 隠している人物に、それを崩す手があるか
P6 手数・場所数が目標の範囲か
P7 手の相手が、人物設定に実在するか
P9 作品データに落ちない指定（事実を立てない手を前提にしている／段が事実より多い）
P10〜P13 は新しい形式（adv-beats/2）の企画だけ（画面の文・手帳のヒント・相談役と章・公式見解）
error は終了コード 1、warn は 0。
目標値（P6）は作品ごとに違うので warn に留めています。
人物が企画に無いときは、P5・P7 を黙って通さず SKIP と出します。
今日の霧走町の企画の結果です。
PLOTCHECK facts=81 places=10 beats=137 moves=154 clear=62 misleads=9 reachable=137/137 errors=0 warnings=2 skipped=0
clear=62 が、企画のグラフから逆算した「クリアに要る手」です。
同じ日に作品データの側を逆算すると（CLI の clearpath）、steps=60 でした。
企画の s_01 は、この差を「分かっている歪み」の表で説明しています。段の数え方が企画と実データで違うためで、作品側の欠陥ではない、と。
数の正は道具の出力で、企画には「手で数えた値をここに置かない」と書いてあります。
新しい作品では、企画が通ったあとに、作品データの骨を機械で起こします（T60）。
企画の検査が error を出したら、骨は起こしません。
名前どおりでない所（1）第一章は逆向きに作った#
霧走町の第一章は、企画より先にゲームがありました。
2026-09-09 に企画を書いたとき、第一章の手は作品データから機械で起こしています（Scripts/adv-beats-from-work.mjs）。
道具の注記は「逆向きの生成。本来は企画 → 作品だが……そこから企画ファイルを起こして、形式が実データに耐えるかを確かめる」。
意図は手に、フラグは事実に、場所の開く条件は opensAfter に写します。
誰が何を隠しているか（hides）は作品データに書いていないので、空のまま人が書きます。
「機械に決められないものは出さない」。
だから企画の s_01 は、章によって出どころが違うと書いています。
第一章は「実装済みなので企画がデータに合わせる」。前提はフラグの id で書かれています。
第二章・第三章は人が書いた企画で、前提は手の id で書きます。
第一章に限っては、正はコードの側です。
SDD の定義どおりなのは、第二章・第三章だけです。
名前どおりでない所（2）「単一の正」が 3 つに分かれている#
企画のファイルが正、と言い切れない所がもう一つあります。
事実（真相・人物が何を知っているか・時系列）の正は、企画ではなく世界設定の文書です。
s_01 は「この企画ファイルは真相を定義しない。食い違ったら世界設定の正本が勝つ」と書いています。
そして 2026-09-23 に、制作の手順そのものを「プレイヤーが体験する物語を最上流に置く」形に改めました。
量産の手順書（Codex が書いた）の層の表は、こうです。
- 体験の原典: 章ごとのプロット（何を見て、疑い、知り、結末へ至るか）
- 事件・世界の設定: 因果の整合を支える。原典の開示順を飛び越えない
- 実装用企画: s_01・s_02・s_09。原典を場所・人物・手・前提へ翻訳する
- 採用済み本文・条件: 作品データ。AI の出力も採用後は固定の入力として扱う
- 派生物と検証の証拠
s_09 は「翻訳」の位置に下がりました。
手順書は「構造検査だけで物語の忠実さを判断しない」とも書いています。
P0〜P13 が見るのは、たどり着けるか・崩せるか・数が合うかで、筋が原典どおりかではありません。
Böckeler の分け方で言えば、うちは spec-as-source ではありません。
台本と言い換えは作品データの側で書き、企画から生成しません。
企画を残して育てる spec-anchored に近く、それも章によって向きが違います。
弱点と、採らなかった案 — spec-driven development#
弱点の一つ目は、仕様のドリフトです。
企画を変えたあと、作品データへ反映する道具は 2 つあります。
adv-new-work の --merge は、id で突き合わせて無いものだけ足します。企画側の変更と削除は同期しません。
三者比較の adv-update-work は、変更も反映できますが、比べる元（骨を起こした直後の写し baseline/）が要ります。
霧走町は骨を機械で起こしていないので baseline/ が無く、--merge しか使えません。
第二章・第三章もこれで足しました。
企画を直したら、作品データの側は人が直すしかありません。
二つ目は、規約との食い違いです。
霧走町の体験の原典は、手順書と s_03 の冒頭で、日付つきの記録（Docs/Reports/2026/09/21/02 の §2）に置かれています。
作品のデータ Game/adv/story.json の source の欄も、同じ記録を指しています。
一方、規約（CLAUDE.md の原則 6）は「日付つきレポートは記録であって現況ではない」と書いています。
原典を記録の置き場に置いたまま、正として参照している状態です。
三つ目は、検査が企画の「形」しか見ないことです。
企画の検査を全部通っても、筋が面白いか、原典の開示順どおりかは分かりません。
採らなかった案。
- 第一章も企画から作り直す。遊べる版が既にあり、作り直すと 2 つの版の差を全部確かめ直すことになります。手順の設計（2026-09-09）は「章1を書き換えない」と決めています。
- 仕様を Markdown の文章だけで書く。読めますが、P0〜P9 のような到達性の検査ができません。手のグラフは JSON にしました。
- 台本まで企画から生成する（spec-as-source）。文章は作品データの側で書き、検査を通ったものだけを採る形にしています（T58）。
検索語#
spec-driven development
GitHub Spec Kit
Kiro spec-driven
spec-anchored spec-as-source Böckeler
佐伯の「10時まで番屋」は、企画の手のグラフでは 1 本の矢印です。ゲームの中では、どう崩れるか。『霧走町 流氷に眠る』の第一章をブラウザで確かめられます。プロフィールのリンクから。