【通算099｜要求AI 16】Spec Kitに“設計”まで実行——確認しながら完走した

ta_kawano

2026年7月29日 21:10

前回、Spec Kitに、Kiroと同じ経費申請の要求を渡して仕様書（spec.md）を出させた。

今日はその続きだ。同じ仕様から、設計フェーズ（/speckit-plan）を最後まで走らせる。

確認したいのは2点。Kiroで引っかかった「勝手に空白を埋める」と「クレジット不足」——このふたつが、Spec Kitではどうなるか。

技術スタックの確認からスタート

/speckit-plan を実行は技術スタックの確認から始まった。

技術スタックが未定です（コードなし・constitution未記入）。その選択が下流の全成果物を決めるので、assumeせず確認させてほしい。

speckit

そして、言語・DB・証憑の保存方式・認証を、選択肢つきで選択した。

Kiroは、まったく同じ状況で、言語もDBも何ひとつ聞かずに、勝手にTypeScriptと4層アーキテクチャ（DDD）を決めて書き始めた（通算090）。Spec Kitは止まって確認した。

Kiroに合わせてTypeScriptを選んだ。証憑の7年保存は改ざん不可のWORM（S3 Object Lock）、認証はシステム内で完結——どちらも要件（FR-012）や仕様に書かれた前提（Assumptions）を踏まえた選択で、Spec Kitはそれを3つの分岐として明示し、確認させた。

設計は「技術スタック」毎に進む

確認が済むと、Spec Kitは設計成果物を次々に書き出した。承認を求めながら。

research.md（297行／Decision・Rationale・Alternatives の形式で「なぜその設計か」を記録）
data-model.md（8エンティティのER図＋列定義）
contracts/openapi.yaml（747行／OpenAPI 3.1・可読なAPI）＋ README.md（99行）
quickstart.md（検証手順書）

Kiroは、設計を design.md 1枚・433行にまとめた（通算090）。Spec Kitは、複数ファイルで合計千行を超え、APIまで出してきた。量も粒度も違う。

さらに、成果物どうしが要件IDで繋がっている。data-model.md には「金額は整数円 [R-009]」「日時はAsia/Tokyoに変換 [R-010]」と、research.md の番号で紐づいている。openapi.yaml には「監査証跡は追記のみ・更新削除なし [FR-009]」と、要件番号が埋め込まれている。

生成された contracts/openapi.yaml の冒頭。

openapi: 3.1.0
info:
  title: 経費申請・承認ワークフローシステム API
  description: |
    共通の不変条件:
    - 状態を変更する操作は必ず監査証跡(audit_event)に追記される (FR-008)
    - 監査証跡を更新・削除する経路は存在しない (FR-009)
    - 金額は整数円 (JPY)。小数・文字列を受け付けない
    - 日時は RFC 3339 UTC。締め日・営業日の判定はサーバが Asia/Tokyo で行う

data-model.md では、制約条件まで。

| manager_id | uuid   | FK→Employee, NULL可 | 直属上長。NULL は承認ルート未設定(FR-014 で提出拒否) |
| roles      | role[] | NOT NULL            | EMPLOYEE / ACCOUNTING / ADMIN ([R-014])         |

8つのエンティティとリレーション。

erDiagram
    Employee ||--o{ ExpenseRequest : "申請する"
    Employee ||--o{ Employee : "直属上長"
    Employee ||--o{ ApprovalDelegation : "指名・代理を務める"
    ExpenseCategory ||--o{ ExpenseRequest : "費目として選ばれる"
    ExpenseRequest ||--|| Receipt : "証憑を持つ"
    ExpenseRequest ||--o{ AuditEvent : "全操作を記録する"
    ExpenseRequest ||--o{ Notification : "通知の対象になる"
    Employee ||--o{ AuditEvent : "操作者として残る"
    Notification ||--|| NotificationOutbox : "メール送信に載る"

生成された data-model.md のER図（8エンティティ）。
〔和名〕Employee=社員／ExpenseRequest=経費申請／ApprovalDelegation=承認代理指名／ExpenseCategory=費目／Receipt=証憑／AuditEvent=監査証跡／Notification=通知／NotificationOutbox=送信キュー

金額を整数で持つ（浮動小数の誤差を避ける）、時刻はUTCで保存してAsia/Tokyoで判定する、監査証跡は消せない。書き漏らせば静かに消えるはずのこれらが、調査で決められ、番号で追える。

完了報告が表示された

10分あまり走って、設計フェーズが完了した。自分の判断のうち、人間に確認してほしい点を3つ挙げた。

「Constitutionが未設定です」。 原則を書くファイルが空のままだったので、原則チェックを「PASS」ではなく「未設定」として記録し、先に原則を書くよう促してきた。
仕様からの“意図的な逸脱”を1件。 「FR-008は代理指名も承認履歴に含めるよう求めるが、代理指名は特定の申請に紐づかない。だから監査証跡を単一テーブルに集約し、request_idをnullableにした」——そう説明した上で、「認識が異なる場合はご指摘ください」と確認を求めた。
作らなかった状態の理由を説明した。 もし必要なら /speckit-clarify で追記を、と直し方まで示した。

Kiroは、「下書き（DRAFT）」という状態を無言で紛れ込ませ、要件・設計・タスク・実装の全工程を、通過させた（通算095）。

止まらなかった

Kiroの検証を終わらせたのは、クレジットだった（通算095）。
今回の設計生成は、処理だけで10分41秒、4万トークンを費やした。
止まらなかった。

Spec Kitは、手元のAI（Claude Code）の上で動く。AWSを経由した従量クレジットという「壁」が、そもそも存在しない。

正確に書くと、今日、完走したのは「設計フェーズ」。実装（/speckit-implement）はこの次に。少なくとも、「ローカル・定額なら、クレジット量で止まらない」という仮説が、設計フェーズで裏づけられた。

今日のまとめ

Spec Kitは技術スタックを勝手に決めず、確認してから設計した
設計は技術スタック毎（research／data-model／contracts／quickstart）に作成、要件IDで相互参照
完了報告で「判断が必要な点」を3つ自分から挙げた
設計生成は10分超かかっても、クレジットの壁が無いので止まらなかった（定額ローカル）