はじめよう、Spec道(仕様道)
記して、形にして、
磨き続ける。
SpecDojo は、気づいたことを記帳し、決めたことを要求・要件・仕様へ形にし、後日の変更も同じ台帳に残すための CLI です。いつでも、どこからでも小さく始められ、記録は使うほど育ちます。すべて Markdown なので、Git でそのまま読めます。

こんなことはありませんか
前提が伝わらない
何のために、誰のために作るのかが伝わらないまま頼むと、作り手が人でも AI でも、求めていたものとずれたものができてしまう。
書き残す時間がない
人手が限られていて、仕様や決めたことを文書にする手間がとれない。作りかけのまま止まってしまう。
あの人がいないと進まない
決めたことも、その理由も、一人の頭やチャットの中にある。その人が抜けると、誰も続きを引き継げない。
SpecDojo は、決めたこととその理由を、誰でも読める Markdown の台帳に残します。人と AI が同じ前提を見て進められます。 記録は会話で伝えるだけで記帳でき、本文は AI が書き、人は確かめて承認するだけです。だから誰かが抜けても、続きから引き継げます。
register の考え方
register(登録簿)は、プロジェクトで起きたことを 1 件ずつ起票して記録を集める台帳です。種類は 7 つあります。まずは todo から始め、慣れたら decision と issue を使いましょう。
register の 1 周
記して(P)→ 形にして(D)→ 磨き続ける(C・A)
todo
やること
実施が決まっている作業を、完了条件とやった結果とともに記録します。まずはここから始めます。
decision
選択肢から方針を決める
検討した選択肢、決めたこと、決めた理由と影響を記録します。
issue
解決すべき問題
すでに起きている問題を、解決の内容と確認の結果まで記録します。
question
判断を保留し、後で決める
回答や確認が必要なことを残し、回答が出たら記録します。
risk
将来の不確実性
まだ起きていない懸念を、消えるか対応を終えるまで追います。
change-request
合意済みの範囲の変更要求
成果物・仕様・計画への変更の要望を、反映と確認まで追います。
note
記録として残す
観測や分析を残します。終わらせず、新しい事実を書き足していきます。
- 起票すると、1 件ごとに個票(Markdown)ができます。個票が記録の正本です。
- 一覧は個票から生成されます。一覧を手で直す必要はありません。
- 個票はただの Markdown なので、SpecDojo がなくても読め、Git で履歴を追えます。
何に困ったら、何を使う?
ツールに優劣をつけるのではなく、いま解きたい困りごとから選びます。SpecDojo はほかのツールを置き換えるものではなく、判断と理由を残す役割で組み合わせられます。
- こんなときは
- チームで課題を議論し、通知で共有したい
- 向いているもの
- GitHub Issues
- SpecDojo との関係
- 補完。issue を、agent に渡せる完了条件つきの todo へ落とすところで register を使う
- こんなときは
- 目の前のタスクの段取りを AI と決めたい
- 向いているもの
- agent の plan(Claude Code・Codex の plan mode)
- SpecDojo との関係
- 補完。plan は段取り、register は「何をなぜ決めたか」を長く残す
- こんなときは
- 1 つの機能を仕様から実装まで素早く作りたい
- 向いているもの
- Spec Kit(新規開発)、OpenSpec(既存コードへの変更)、Kiro(IDE の中で承認しながら)
- SpecDojo との関係
- 工程が違う。SpecDojo はその上流で、プロダクトの要求・仕様を決めて保つ
- こんなときは
- 多数の AI agent に作業を配り、並行して大量に回したい
- 向いているもの
- Beads / Gas Town
- SpecDojo との関係
- 規模と依存関係の管理はあちらが強い。register は判断を残す側
- こんなときは
- 迷い・判断・保留・リスクを、理由ごと残してあとでたどりたい
- 向いているもの
- SpecDojo の register
- SpecDojo との関係
- いま使える
- こんなときは
- 決めたことを要求・要件・仕様の文書に反映し、保ち続けたい
- 向いているもの
- SpecDojo(型と品質評価)
- SpecDojo との関係
- 準備中
GitHub Issues と register をつなぐ
GitHub Issues はチームでの議論、通知、開発者以外からの報告に向いています。そこで話した内容を agent が実行できる粒度にするとき、register を使います。
ただし、チームに公開・通知されるため、未整理の迷いや小さな判断は書きにくい面があります。また、完了条件がないため、そのままでは agent への指示になりにくい面もあります。
1. 議論して共有する
GitHub Issues で課題を話し合い、通知を使ってチームに共有します。
2. todo に落とす
issue の URL を個票に書いてつなぎ、背景と完了条件のある具体的な todo にします。
3. agent に渡す
完了条件から exec plan を作り、実行する agent に渡します。決めたことは理由ごと残ります。
GitHub との自動連携ではありません。現時点では、issue の URL を個票に書いてつなぐ形です。
2026 年 10 月時点の各ツールの公開情報による。
5 つの手順で始めて、4 つの手順で回す
導入したら、あとはやりたいことを会話で伝えるだけです。開発中のランディングページ(LP)を例に、加えたいことを起票し、AI に実行させ、確かめて次の改善を記すまでを、上から順に試します。
オーケストレーターは、状態を変える操作を承認を得てから実行し、git push や破壊的な操作は行いません。
始める前に用意するもの
Node.js 22.13 以上
SpecDojo の CLI は npm で導入します。Git も使える状態にしておきます。
Claude Code の導入とログイン
会話で進める場合と、AI に実行させる場合に必要です。npm run orch:opus は specdojo orchestrator launch --provider claude を経由して claude を起動します。ほかの provider を選ぶ場合は、その CLI を用意します。
landing-page-workspace/
├── landing-page/ # 開発中の LP(プロダクト)
├── landing-page-specdojo/ # SpecDojo の記録
└── landing-page-specdojo-worktrees/ # exec の作業領域- register だけなら、まずは
landing-page-specdojo/だけで始められます。 - worktree は、exec でタスクごとの作業を隔離するときに作られます。
- 配置の考え方と詳しい構成はディレクトリレイアウトリファレンスを参照してください。
会話で始める
5 つの手順で始める
- 1
SpecDojo を導入する
ここでは、すでに開発を進めているランディングページ(LP)のリポジトリ landing-page に、SpecDojo を後から加える例で進めます。landing-page は npm で開発していて、npm run dev で表示を確かめ、npm run build でビルドできるものとします。landing-page とは別に、記録を置くプロジェクト用のリポジトリを作り、SpecDojo を開発用の依存として入れます。
mkdir landing-page-workspace mkdir landing-page-workspace/landing-page-specdojo git -C landing-page-workspace/landing-page-specdojo init cd landing-page-workspace/landing-page-specdojo npm init -y npm install --save-dev specdojo - 2
初期設定する
質問に答えると、設定(プロジェクト ID は prj-0001)、登録簿、人と AI の名簿、AI に実行させるための設定、オーケストレーターを起動する npm script がまとめて作られます。使う AI ツール(provider)と、AI に実行させるか(exec)を尋ねられたら、Claude Code の場合は claude と「はい」を選びます。
npx specdojo init - 3
オーケストレーターを起動する
SpecDojo には、会話を CLI の操作に置き換えてくれる対話型オーケストレーターが入っています。初期設定で追加された script で起動します。ほかの provider を選んだ場合は、次の script で起動します。
npm run orch:opusprovider 起動 claude(Claude Code) npm run orch:opus(orch:sonnet も追加されます)opencode npm run orch:opencodecodex npm run orch:codexantigravity npm run orch:agy - 4
LP に加えたいことを起票する(Plan)
やりたいことを、そのまま伝えます。オーケストレーターがコマンドに置き換え、実行する前に内容を見せて確認を求めます。
あなた
問い合わせで同じ質問が続いている。LP によくある質問の節を加えたいので、todo として起票して。
オーケストレーター
次を実行します。よろしいですか。
npx specdojo register add --project prj-0001 --type todo \ --title "LP によくある質問(FAQ)の節を加える"あなた
お願いします。
- 5
気づいたことも記して、一覧を作る
作業だけでなく、気づいた問題(issue)や決めたいこと(decision)も、思いついたときに起票できます。起票した項目は個票(Markdown)として保存され、一覧にまとまります。「今の状況は?」と聞けば、状況の確認もできます。
あなた
そういえば、SNS で共有したときの画像もない。issue として記録して、一覧を作って。
オーケストレーター
次を実行します。よろしいですか。
npx specdojo register add --project prj-0001 --type issue \ --title "SNS で共有したときに表示される画像(OGP)がない" npx specdojo register build --project prj-0001あなた
お願いします。
4 つの手順で回す
- 1
LP のリポジトリをつなぐ
開発中の LP(landing-page)を、設定の repos に宣言します。宣言したリポジトリだけを、AI が読み書きできます。追加したらオーケストレーターを起動し直します。AI の作業は commit 済みの内容から作る作業領域で行うため、ここまでの設定と個票は commit しておきます。
あなた
LP のリポジトリ ../landing-page を、このプロジェクトにつないで。
オーケストレーター
specdojo.config.json の repos に landing-page を追加します。よろしいですか。
あなた
お願いします。
- 2
完了条件を書いて、AI に実行させる(Do)
完了条件が、そのまま AI への指示になります。作業はタスクごとの作業領域(git worktree)で行うので、失敗しても手元の LP は汚れません。実装した AI とは別の AI が検証の結果から報告をまとめます。成功すると、landing-page には FAQ の変更が、プロジェクトのリポジトリには計画・報告・状態の記録が、それぞれ commit されて統合されます。
あなた
FAQ の完了条件は、料金・導入期間・サポートなど問い合わせの多い 5 つの質問に答えていること、ページ上部のメニューから FAQ へ移動できること、npm run build が通ること。書けたら AI に実行させて。
オーケストレーター
個票に完了条件を書き、次を実行します。よろしいですか。
npx specdojo exec run --project prj-0001 --register PJR-XXXX --worktree \ --executor-by claude-executor --reporter-by claude-reporterあなた
お願いします。
オーケストレーター
成功しました。landing-page とプロジェクトのリポジトリの両方に、exec(register PJR-XXXX) の commit が入っています。項目は確認待ち(review)です。
- 3
確かめる(Check)
AI がまとめた報告で完了条件ごとの検証結果を読み、landing-page を手元で動かして FAQ の表示を確かめます。
あなた
報告を見せて。
オーケストレーター
完了条件ごとの結果です。5 つの質問への回答、メニューからの移動、npm run build のいずれも満たしています。表示は npm --prefix ../landing-page run dev で確かめられます。
- 4
完了として残し、次の改善を記す(Action)
確かめて気づいた改善点を次の項目として起票し、FAQ の項目は完了にします。どちらもプロジェクトのリポジトリに commit されます。起票から実行、確認、完了までの経過は、決めた理由と一緒に同じ台帳に残り、次の周回は手順 2 から回せます。始める手順で記録した OGP 画像の issue も、同じ流れで取りかかれます。
あなた
FAQ は条件どおり。ただ、スマートフォンだと回答が長くて読みにくい。改善を todo として起票して、FAQ のほうは完了にして。
オーケストレーター
次を実行します。よろしいですか。
npx specdojo register add --project prj-0001 --type todo \ --title "FAQ の回答をスマートフォンで読みやすくする" --commit npx specdojo register close --project prj-0001 --id PJR-XXXX \ --conclusion "FAQ の節を加え、問い合わせの多い 5 つの質問に答えた" --commitあなた
お願いします。
詳しい進め方はオーケストレーター運用ガイドを参照してください。
コマンドで始める(参考)
5 つの手順で始める
- 1
SpecDojo を導入する
ここでは、すでに開発を進めているランディングページ(LP)のリポジトリ landing-page に、SpecDojo を後から加える例で進めます。landing-page は npm で開発していて、npm run dev で表示を確かめ、npm run build でビルドできるものとします。landing-page とは別に、記録を置くプロジェクト用のリポジトリを作り、SpecDojo を開発用の依存として入れます。
mkdir landing-page-workspace mkdir landing-page-workspace/landing-page-specdojo git -C landing-page-workspace/landing-page-specdojo init cd landing-page-workspace/landing-page-specdojo npm init -y npm install --save-dev specdojo - 2
初期設定する
質問に答えると、設定(プロジェクト ID は prj-0001)、登録簿、人と AI の名簿、AI に実行させるための設定、オーケストレーターを起動する npm script がまとめて作られます。使う AI ツール(provider)と、AI に実行させるか(exec)を尋ねられたら、Claude Code の場合は claude と「はい」を選びます。
npx specdojo init - 3
オーケストレーターを起動する
コマンドで進める場合は不要です(会話で進める場合だけの手順です)。
- 4
LP に加えたいことを起票する(Plan)
FAQ の節を加える作業を todo として起票します。表示された PJR-XXXX の個票(Markdown)を開き、背景を書き足します。
npx specdojo register add --project prj-0001 --type todo \ --title "LP によくある質問(FAQ)の節を加える" - 5
気づいたことも記して、一覧を作る
気づいた問題を issue として起票し、個票から一覧とログを作り直します。controls/project-register/generated/pjr-index.md を開くと、起票した項目が並んでいます。
npx specdojo register add --project prj-0001 --type issue \ --title "SNS で共有したときに表示される画像(OGP)がない" npx specdojo register build --project prj-0001
4 つの手順で回す
- 1
LP のリポジトリをつなぐ
設定の repos に開発中の LP(landing-page)を宣言します。AI の作業は commit 済みの内容から作る作業領域で行うため、ここまでの設定と個票を commit します。
# .specdojo/specdojo.config.json の projects.prj-0001 に追加する "repos": [ { "name": "landing-page", "path": "../landing-page", "integration_branch": "main" } ] git add -A git commit -m "chore: SpecDojo を導入する" - 2
完了条件を書いて、AI に実行させる(Do)
FAQ の todo の個票に、答える質問の数、メニューからの移動、npm run build が通ることを完了条件として書き、commit してから実行します。executor が landing-page で作業し、reporter が報告をまとめ、成功したものだけが統合されます。landing-page とプロジェクトのリポジトリの両方に、exec(register PJR-XXXX) の commit が入ります。
npx specdojo exec run --project prj-0001 --register PJR-XXXX --worktree \ --executor-by claude-executor --reporter-by claude-reporter git -C ../landing-page log --oneline -1 git log --oneline -1 - 3
確かめる(Check)
項目は確認待ち(review)になります。計画と報告は execution/exec/ 配下に残ります。報告で完了条件ごとの結果を読み、landing-page を動かして FAQ を確かめます。
npm --prefix ../landing-page run dev - 4
完了として残し、次の改善を記す(Action)
気づいた改善点を todo として起票し、FAQ の項目は結論を書いて完了にします。--commit を付けると、プロジェクトのリポジトリにそれぞれ commit されます。
npx specdojo register add --project prj-0001 --type todo \ --title "FAQ の回答をスマートフォンで読みやすくする" --commit npx specdojo register close --project prj-0001 --id PJR-XXXX \ --conclusion "FAQ の節を加え、問い合わせの多い 5 つの質問に答えた" --commit
オーケストレーターを使わずに、CLI を直接実行することもできます。各コマンドの詳しいオプションはCLI コマンドリファレンスを参照してください。
次の一歩
起票に慣れたら、decision で決め、仕様書に書き、change-request で直す流れへ進みましょう。詳しくはドキュメントサイトで案内しています。
今できること、その先へ
これから
SpecDojo は、気づきを記すところから始まり、計画や定期的な仕事へ広がっていきます。いま使える register と、準備を進めている機能を、同じ 1 周の流れで示します。
register
いま使える- Plan 記して
- 気づいたことを起票する
- Do 形にして
- AI が実行する
- Check 磨き続ける(評価)
- 人が確かめる
- Action 磨き続ける(確定・改善)
- 完了として残す。必要なら直す
schedule
準備中- Plan 記して
- 作る成果物を計画に並べる
- Do 形にして
- 順に実行する
- Check 磨き続ける(評価)
- 品質を評価し、確かめる
- Action 磨き続ける(確定・改善)
- 確定して次の反復へ
routine + Job
準備中- Plan 記して
- 何を・いつ・誰が確かめるかを決める
- Do 形にして
- 決まった時刻に自動で実行する
- Check 磨き続ける(評価)
- 指名した AI が確かめる
- Action 磨き続ける(確定・改善)
- 合格したものだけ取り込み、続きから再開する