GitHubのSpec-KitとClaude Codeを2ヶ月使ってみて： 有効な点、改善が必要な点

GitHubのspec-kitをSpec-Driven Development（SDD）に使い、Claude Codeを主要エージェントとして2ヶ月間使用した後、r/LocalLLaMAの開発者が何が機能し、何が機能しないかを報告している。このツールキットはgithub.com/github/spec-kitで入手でき、Constitution、Specify、Plan、Tasks、Implementの5フェーズワークフローを強制する。核となる考え方は、プロンプトではなく仕様（spec）が真実の源泉であるということだ。

実際に良い点

• エージェント非依存：同じ仕様がClaude Code、Cursor、Codex、Gemini CLI、Copilotで動作する。著者はClaude Codeでコードを生成し、その仕様をCursorに渡してテストリファクタリングをシームレスに行った。
• フェーズ間のハードチェックポイント：Planフェーズでは、コードが書かれる前の完全な提案アーキテクチャが表示され、悪い判断を5時間ではなく5分の修正コストで発見できる。
• 品質ゲートとしてのConstitutionファイル：テストカバレッジの最低値、依存関係の許可リスト、パフォーマンス予算、型付けの厳格さなど、不可侵のルールを事前に定義できる。エージェントがそれらを破ろうとすると、検証に失敗する。
• 決定性の向上：Implementフェーズを再実行すると、生のプロンプトよりも一貫した出力が得られる。エージェントが30の暗黙の決定を補完する必要がないためだ。

気になる点

• ドリフトは現実的：仕様を更新せずに手動でコードを編集すると、すぐに非同期が発生する。spec-kitにはツールがあるが、まだ初期段階だ。
• 小さな変更にはオーバーヘッド：50行未満のバグ修正や些細な機能には儀式的に感じられる。著者のルール：200行以上に影響する新しいモジュールや機能にのみ完全なSDDを使用する。
• レガシー移行は困難：30k行のコードベースにSDDを後付けするには数ヶ月かかる。
• 品質はエージェントに依存：Claude Code（Sonnet/Opus 4.6+）はうまく処理するが、小さなモデルはコンパイルはできてもアーキテクチャの推論に欠ける計画を生成する。

実用的なセットアップ

• インストール：uv tool install --from git+https://github.com/github/spec-kit.git specify-cli。公式リポジトリのみ安全で、PyPIにはタイポスクワッターが存在する。
• 主要エージェント：Claude Codeを使用し、CursorとGemini CLIで相互検証。
• ローカル永続化：SQLite（仕様化/検証が容易で、クラウド依存がない）。
• 再利用可能なconstitutionテンプレート：厳格な型付け、pytestカバレッジ80%超、明示的な依存関係許可リスト、必須でない限りクラウドサービスなし。

未解決の課題

• ローカルモデル（Qwen、DeepSeek-Coder、GLM、Llama）はPlanとImplementを適切に処理できるか？著者は小規模モデルはフォーマットに従うが、アーキテクチャの推論に失敗することを発見した。
• マルチエージェントSDDは機能するか？あるモデルで仕様、別のモデルで実装、3つ目で監査——理論的には優れているが、実際にはシングルエージェントよりも測定可能な改善はない。