PJR-E8TT 初期リリースの差別化軸を定める

1. 背景

Gas Town / Gas City の調査を踏まえ、初期リリースで前面に出すものを決める。exec 層は実行基盤として規模で先行されているため機能比較に持ち込まない。register は task tracker ではなく、判断・観測・保留を含めて記録する場である点を差別化として扱う。orchestrator の規律、成果物 kata の網羅範囲と合わせて位置づけを定める。devcontainer と tmux の扱いも併せて決める。

2. 検討した選択肢

prj-0001:pjr-36qg-competitive-landscape-and-release の Gas Town / Gas City（2026-09-24 追加）で、実行基盤の競合を見落としていたことが分かった。差別化の候補を評価し直す。

候補	評価	根拠
成果物 kata の網羅範囲	強い	競合は機能単位の 3〜4 文書。SpecDojo は C4 各層、データモデル 5 種、テスト 4 層、トレーサビリティを含む 106 種
register の記録範囲	強い	後述
対話型 orchestrator	強い	後述
品質の継続評価（grade）	中	長期運用の文書体系に効くが、効果が見えるまで時間がかかる
実行の記帳（exec 層）	弱い	Gas City が同じ問題を解き、規模で先行。tmux は既定 runtime provider
devcontainer	中	価値はあるが配布形態とサポート範囲の設計が要る
tmux	採らない	Gas City の既定 runtime provider であり、後発の追随になる

2.1. register の記録範囲

beads と Gas Town は work の外部化に特化する。beads の目的は「50 First Dates」、すなわち agent がセッションをまたいで作業を覚えていない問題を、課題グラフで埋めることである。扱うのはこれからやることである。

register は work に限らない。7 つの type のうち decision / question / note / risk / change-request は作業ではなく、判断・保留・観測・リスク・変更要求である。気づいた時点でその場に記録でき、後から辿れる。

prj-0001 の実測（2026-09-24、388 項目）は次のとおりである。

type	件数
todo	341
issue	22
decision	16
note	5
question	2
change-request	1

作業でない項目が 46 件（約 12%）ある。task tracker にはこれらの置き場が無く、記録されないか、散逸した Markdown へ書かれて失われる。

さらに register からは PM の統制文書が生成される。

controls/generated/pm-decision-log.md
controls/generated/pm-issue-log.md
controls/generated/pm-risk-register.md
controls/generated/pm-change-request-log.md

同じ記録が、実行の入口であると同時に統制文書にもなる。decision は選択肢の比較・採択理由・承認を持ち、ADR に相当する。

本セッション（2026-09-23〜24）の実例では、npm の staged publishing へ戻すかの保留（question）、CLI 入口の短縮方法の保留（question）、競合状況の観測（note）を起票した。いずれも作業ではなく、task tracker では行き場がない。

2.1.1. type が本文構造を与える

register add --type <type> で個票を作ると、type 固有の章構成が生成される。

type	章構成
todo	概要 / 完了条件 / 作業内容 / 対応結果 / 関連ドキュメント
decision	背景 / 検討した選択肢 / 決定内容 / 採択理由 / 承認 / 影響範囲とフォローアップ / 関連ドキュメント
question	確認事項 / 背景 / 回答候補 / 回答・結論 / 承認 / 関連ドキュメント
risk	リスク内容 / 影響評価 / 対応方針 / モニタリング / 関連ドキュメント
issue	課題内容 / 影響範囲 / 対応方針 / 対応結果 / 関連ドキュメント
change-request	変更要求 / 影響評価 / 審査・決定 / 実施追跡 / 関連ドキュメント
note	メモ / 背景・文脈 / フォローアップ / 関連ドキュメント

beads の課題は title・description・依存関係・状態を持つレコードである。「選択肢を比較し、理由を書き、承認者を記録する」という構造をフィールドとして持たない。description への自由記述になり、次に同じことをする人が同じ構造で書く保証がない。

register では decision を選んだ時点で ADR の骨格が与えられる。型が思考の抜け漏れを防ぎ、採択理由 が空欄で残っていれば理由を書いていないことが一目で分かる。

2.1.2. Markdown が正本であることの帰結

抽象的な可読性ではなく、実際に効く場面で比較する。

場面	register	beads
変更履歴を読む	git log -p で本文の差分がそのまま読める	正本は Dolt。git にあるのは export
3 年後に読む	ファイルを開けば読める。SpecDojo が無くてもよい	bd show かデータベースが要る
検索	grep / rg がそのまま効く	bd のクエリか SQL
閲覧	GitHub でも VitePress でも描画される	専用ビューア
agent が読む	ファイルを読むだけ。アダプタ不要	CLI か MCP 経由
長文の記録	表・コードブロック・mermaid をそのまま書ける	description への自由記述
成果物との接続	[[doc-id]] で成果物・rulebook・他項目へ張れる	課題間の依存のみ

最後の行が要点である。個票から成果物へ直接リンクできるため、「この判断がどの設計書に効いたか」を追える。課題追跡ツールは課題同士の依存しか持たないため、成果物へ接続できない。

2.1.3. orchestrator による起票

差は「コマンドが短い」ことではない。本文を書く手間が消えることである。

npx specdojo register add --project prj-0001 --type decision --title "..." --description "..."
bd create "..." -d "..."

コマンド自体は大差ない。差が出るのはこの後で、decision なら選択肢の比較表、採択理由、影響範囲を書く必要がある。これが記録の価値の大半を占め、同時に最も面倒な部分である。

orchestrator を使うと、会話の流れがそのまま本文になる。調査や議論の内容を別途まとめ直す作業が発生しない。agent が課題を作れること自体は beads も bd setup claude で対応しており差にならない。違いは、会話の文脈を構造化された文書へ落とせることである。

加えて orchestrator は type の選択を助ける。利用者が 7 種を覚える必要がなく、「これは todo ではなく question である」と判断して保留の理由まで書ける。

2.1.4. 気軽さの内訳

要素	内容
判断の軽さ	作業でなくても起票してよい。note と question が受け皿になる
記入の軽さ	orchestrator が本文を書き、人は承認する
後始末の軽さ	個票が項目ごとに分かれ ID も乱数のため、並行作業で衝突しない

3 番目は 2026-09-23〜24 の運用で実証された。10 件以上を起票しながら exec が worktree で並行実行していたが、衝突は発生しなかった。

2.1.5. register が劣る点

公開時に都合の良い面だけを述べると、指摘を受けた際に説得力を失う。次は事実として認める。

観点	状況
依存関係	持たない（prj-0001:pjr-srqz-register-dependencies で起票済み）。beads は 4 種の依存グラフを持つ
着手可能判定	持たない。beads は bd ready を持つ
採用実績	実質未公開。beads は 27,391 star
導入	Node と設定が要る。beads はバイナリ 1 つ

依存関係と ready 判定は、SpecDojo では timeline と schedule が担う（3.6.4. beads との比較 を参照）。ただし register だけを使う最小構成ではその層が無いため、欠落として残る。

2.2. 対話型 orchestrator

競合の agent 統合は、slash command やプロンプトを配る形である（Spec Kit は 38 統合）。Kiro は IDE そのもの。Gas City は人と会話する司令塔ではなく、多数の自律 agent を回す SDK である。

SpecDojo の orchestrator が異なるのは、何を勝手にやらせないかが成文化されている点である。

• 提案 → 承認 → 実行の順序
• git push と破壊的操作の禁止
• commit 先を変更の種類で決める 3 層（prj-0001:pjr-ewwx-feature-branch-policy）
• 保護設定による agent の書き込み境界

2026-09-24 時点で config scaffold --provider により 4 provider へ配布できる。

2.3. 常時稼働の実行環境

SpecDojo は routine の cron と 10〜30 分かかる exec run を持つため、常時稼働する実行環境を前提とする。ノート PC を閉じると止まる。

ツール	常時稼働の必要性
Spec Kit / OpenSpec	低い。人が起動したときだけ動く
Kiro	低い。IDE を開いている間
Gas Town / Gas City	高い。cloud / Kubernetes へ向かう
SpecDojo	高い。個人規模で完結させたい

Gas Town / Gas City は cloud で答える。個人が手元の常時稼働マシンで完結させる構成の案内は空白になっている。prj-0001 は Tailscale + SSH + tmux + devcontainer で母艦へ接続しており、運用知見が product 側の文書に 265 行ある。

これは主たる差別化ではなく補強材料として扱う。第三者ツールの組み合わせ方であり SpecDojo の機能ではなく、競合が真似るのも容易で防御力がない。また「簡単に実行できる」と書くと支援範囲が広がり、こちらの責任外で壊れる箇所を抱える。

一方で「自律実行を前提とする」という SpecDojo の性格を具体化し、Spec Kit / OpenSpec との違いを示す材料になる。構成例 として prj-0001:pjr-8myj-remote-host-development-guide で扱う。

なお tmux の用法を区別する。Gas Town / Gas City の節で採らないと判断したのは「agent を tmux で回す」runtime provider としての用法であり、ここで扱うのは「人の作業セッションを切断後も保つ」用法である。両者は競合しない。

3. 決定内容

初期リリースで前面に出すのは register の記録範囲、対話型 orchestrator、成果物 kata の網羅範囲の 3 つとする。

主張	内容
気づいたことを型に沿って残せる	作業も判断も保留も観測も同じ登録簿へ記録する。type ごとに章構成が与えられ、書くべきことが決まる。統制文書が生成される
会話で進められる	orchestrator を配置して話しかければよい。調査や議論がそのまま個票の本文になり、まとめ直す作業が要らない。承認の規律が定義されている
成果物の型が揃っている	必要な成果物だけをカタログで選び、型に沿って作れる

exec 層は機能比較に持ち込まない。「成果物体系を維持するための実行手段」として説明し、Gas City と並べた機能表を作らない。

tmux を agent の runtime provider として採ることはしない。人のセッション永続化としての tmux と devcontainer は、常時稼働環境の構成例として補強材料に位置づけ、構成例 のガイドで扱う。README へ手順を複製せず 1 行リンクに留める。

4. 採択理由

• 実行基盤で競うと規模と成熟度で勝てない。Gas Town 18,167 star、beads 27,391 star に対し SpecDojo は実質未公開である。同じ土俵へ上がらない判断は、beads に対する register の判定（単独製品として売り込まない）と同じ論理である。
• register の記録範囲は、競合が構造的に持たないものである。beads は「plans/ の食べかけの markdown の山を置き換える」と明示しており、Markdown を正本としない。判断や観測を人が読める形で残す思想とは前提が異なる。
• orchestrator と register は 2026-09-23〜24 の作業で既に成立している。npm 導入から会話による起票・実行まで、空ディレクトリで実測済みである（prj-0001:pjr-49jk-readme-orchestrator-onboarding）。未完成のものを差別化として掲げると、試した利用者の期待を裏切る。
• 成果物 kata の網羅範囲は PJR-36QG が一貫して挙げてきた軸であり、変更する理由がない。ただし品質は要修正 58% であり、網羅範囲と品質は分けて説明する必要がある。
• devcontainer を外すのは、現行の .devcontainer/ が本リポジトリ専用（ollama、agy、claude、codex、6 個のボリューム、cron）で、配布には設計作業を要するためである。価値を否定するものではない。

4.1. 見込みがあると判断する根拠

競合と比べて「見込みがある」と言えるかを整理する。根拠の置き方を誤ると、検証できない主張になる。

リスクの性質は異なる。 Gas Town の未解決点（verification chain が閉じない、most work gets done; some work gets lost）は思想に内在し、throughput 優先という前提を捨てない限り努力では縮まない。SpecDojo の未解決点（カタログを書く負担、106 種からの選定、文書の維持）はコストと習熟の問題で、設計で軽くできる余地がある。この差は事実として認めてよい。

ただし努力の外にある要素が 2 つある。 詳細は prj-0001:pjr-q3w9-gastown-design-philosophy の リスクの性質の違い に記す。

• 技術の軌道への賭け。モデルの能力が上がって粗い指示でも意図を推測できるようになれば、型を用意する価値は下がる。Gas Town は能力向上に、SpecDojo は構造に賭けている。
• 採用は努力の変数ではない。正しいが重い体系が軽い方式に負けた例は多い。

したがって根拠は「努力で到達できるから」に置かない。 検証できないためである。置くのは次である。

段階的に価値が出る構造だから、賭けが外れたときの損失が小さい

register だけなら設定 2 行で使え、catalog も schedule も要らない。orchestrator、kata の参照、catalog / schedule は必要になった時点で足せる。重さが必須ではなく選択になっている。空リポジトリから register まで 4 コマンドで到達することは実測済みである（prj-0001:pjr-09kk-npm-onboarding-path）。

この構造は本決定の前提でもある。初期リリースで register と orchestrator を前面に出すのは、全体を採用しなくても価値が出ることを入口で示すためである。成果物 kata の網羅範囲を先に見せると、重さで脱落する。

5. 承認

項目	内容
決定者	naoji3x
決定日	2026-09-24
承認方式	commit
証跡	register event close（events/pjr-e8tt.yaml）と本個票の遷移 commit

• 承認方式は commit または PR を記載する。PR の場合は証跡に PR URL と merge SHA を本文テキストで記載する。
• 不可逆・高リスク・framework schema 破壊的変更に該当する決定は PR 方式で承認する。

6. 影響範囲とフォローアップ

項目	内容
影響範囲	README、ドキュメントサイトの入口、npm のパッケージ説明、公開時の告知
必要な対応	決定後に README とドキュメントサイトの表現を揃える。devcontainer の配布は別項目
追跡先	本項目および派生する todo

6.1. 見直しの契機

本決定は利用者の反応を観測していない段階で下す。prj-0001:pjr-36qg-competitive-landscape-and-release も「この位置づけが妥当かは実際の利用者の反応を見ないと判断できない」としている。

次のいずれかが観測されたら reopen して見直す。

• 導入した利用者が register ではなく成果物カタログから入ろうとする。入口の想定が誤っていたことを示す。
• orchestrator を使わず CLI を直接叩く利用が大半を占める。会話による操作の価値が想定より低いことを示す。
• 「重い」という評価が、段階的採用を説明した後にも続く。構造による防御が効いていないことを示す。
• モデルの能力向上により、型と完了条件を与えなくても意図どおりの成果物が得られるようになる。prj-0001:pjr-q3w9-gastown-design-philosophy の リスクの性質の違い で挙げた賭けが外れたことを示す。

7. 関連ドキュメント

• prj-0001:pjr-36qg-competitive-landscape-and-release
• prj-0001:pjr-7vkr-npm-release
• prj-0001:pjr-49jk-readme-orchestrator-onboarding
• prj-0001:pjr-2w38-sample-quality-observation

追記 (2026-09-29)

利用者からの提案を受け、specdojo devcontainer scaffold により利用リポジトリ向けの隔離環境を生成する機能を初期リリースに含めることに判断を変更した。配布用に構成を最小限に絞り、利用者が任意の CLI やオプションを指定して生成できるようにしたため、本リポジトリ専用の構成と分離して保守できるようになった（PJR-2H5F）。