仕様は設計書ではありません
仕様が答えるのは「何が正しいか」です。「どう作るか」ではありません。
作り方まで書き込むと、作る側の選択肢が理由もなく狭まります。しかも、作り方は変わるので、仕様の寿命もそのぶん短くなります。作り方は、仕様とは別の「計画」に書きます。
仕様に何を書き、何を書かないか
レベル 1・実践「何が正しいか」を先に決める約90分
先に読む回：ふわっとした依頼を、判定できる依頼にする
この回でできるようになること
- 具体的な例と「壊れてはいけない条件」から、合否を判定できる基準を書ける
- どの要求をどのテストで確かめたかを、1枚の表で示せる
おさえておくこと
仕様に書く3つのこと
- 例
- 「この状況でこう操作すると、こうなる」を、具体的な値で書きます。
- 壊れてはいけない条件
- どの例でも必ず成り立っていてほしい条件です。たとえば「残高はマイナスにならない」。
- 速度や安全性などの条件
- 満たされていないと、機能として成り立たない条件です。
3つとも、合否を判定できる書き方にすることが大切です。
「どのテストで確かめたか」は、あとからは作れません
要求・テスト・結果・確認方法の対応は、作り終わってから思い出して書こうとすると、必ず抜けます。
要求を書いた時点で番号を振り、その番号をテストにも残してください。この一手間で、変更したときに何が壊れるおそれがあるかを、あとから追えるようになります。
ここまでで分からないところがあれば、この回の本文だけを使って答えてもらえます（任意・自分のAPIキーが必要です）。
この回では扱わないこと
- 数学的に厳密な仕様記述
- 特定のテンプレートの書式を覚えること
やってみる
どちらでも約75分
機能1つ分の仕様を書いて、対応表を作る
これから作る機能、または最近作った機能を1つ選びます。具体的な例・壊れてはいけない条件・合否の判定基準を書き、要求からテストまでの対応表を作ります。
やること
- 機能を1つ選び、要求に番号を振ります（R-1、R-2 …）。
- それぞれの要求について、具体的な値を使った例を1つ以上書きます。
- どの例でも必ず成り立っていてほしい条件を書きます。
- 合否を判定できる形で、完成の基準を書きます。
- 要求・判定基準・テスト・確認結果の4列の表を作ります。
- テストがまだない行に印を付けて、埋めるか、埋めない理由を書きます。
できあがるもの：仕様を書いたファイルと、要求→テスト→結果→確認方法の対応表
できたかどうかの確かめ方
観点の表で採点する自分で採点する
その基準で、合否を判定できるか
書いた仕様の判定基準を、「中身を知らない人でも合否を判断できるか」という観点で採点してください。
例が具体的か
- まだ
- 状況がぼんやりしていて、何を入れたら何が返るのかが分からない。
- できた
- どの例にも、具体的な入力と期待する結果が書かれている。
- よくできた
- 境目の値や、失敗したときにどうなるかも書かれている。
壊れてはいけない条件
- まだ
- 書かれていない。
- できた
- どの例でも成り立っていてほしい条件が、1つ以上書かれている。
- よくできた
- その条件が、作り方に左右されない形で書かれている。
対応表をたどる自分で採点する
要求からテストまで辿れるか
作った対応表について、要求から対応するテストへ、テストから実行結果へ辿れることを確かめてください。辿れない行があれば、その理由を書きます。
pnpm test
番号がつながっているか
- まだ
- 要求に番号がない、またはテスト側に残っていない。
- できた
- 要求の番号がテストから分かり、どちらの向きにも辿れる。
- よくできた
- テストのない要求がはっきり示されていて、いま埋めない理由も書かれている。
この回の情報の出どころ
- 公式の説明GitHubSpec Kit ドキュメント
2026-09-14 に確認／2026-12-14 までにもう一度確認
- 公式のリポジトリGitHubgithub/spec-kit
2026-09-14 に確認／2026-12-14 までにもう一度確認
この回で触れている外部の情報は、いちばん古いもので 2026-09-14 に確かめたものです。 この日付は ADR-0019 の一次情報一覧から引き継いでいます。
この回の記録
書いた内容はこのブラウザの中だけに残ります。送信はしません。 成果物そのものではなく、どこにあるか（ファイルの場所、ブランチ名など）を書いてください。 鍵やパスワードは書かないでください。
確かめた結果
その基準で、合否を判定できるか
要求からテストまで辿れるか
置き場所を書き、すべての確認を「できた」以上にすると、記録つきの完了になります。
AIに見てもらう（任意）
使わなくても、すべての回は完了できます作ったものを、この回の観点表に照らして見てもらえます。返ってくるのは助言であって、 合否ではありません。完了にするかどうかを決めるのは、いつでもあなたです。 自分のAPIキーを使うため、料金はご自身のアカウントに請求されます。
先に、上の「この回の記録」ですべての確認に自分で評価を付けてください。 モデルの評価を先に見ると、自分の判断がそれに引きずられます。
キーはこの実行にのみ使われ、保存もログ出力もしません。ブラウザにも残らないため、ページを離れると再入力が必要です。
APIキーを発行する