メインコンテンツへスキップ
見出し画像

【通算098|要求AI 15】GitHubのSpec Kitに同じ要求を渡したら、まったく違う仕様書が出てきた(Spec Kit導入編)

    ta_kawano

    ここからは、GitHubの Spec Kit を、Kiroと同じ土俵で走らせていく。

    Spec Kit の紹介記事。

    まずは導入と、要求仕様の生成までだ。条件はKiroのときと完全に揃えた——同じ経費申請の承認、同じ4つの視点の要求、同じ評価のものさし。違いが出れば、それはツールの違いだ。

    導入は、コマンド1行

    インストールは uvx というPythonのツール経由でコマンド1行。数分で終わる。

    そして開けてみて驚いた。Spec Kitの実体は、スキル(AIへの指示書のMarkdown)10本と、文書テンプレート5本と、PowerShellスクリプト5本。それだけだった。

    画像
    左が中身の全て。専用アプリもクラウドサービスもない

    Kiroが729MBのIDEとクラウドの実行エンジンだったのに対し、こちらはテンプレート集である。前回「SDDの実体は手順と文書ではないか」と書いたが、フォルダを開いた瞬間にそれが証明された格好だ。実行するのは手元のAI(今回はClaude Code)——つまり費用はAIの定額契約に含まれ、ツール独自のクレジットは存在しない。

    用意されているコマンドは、constitution(原則)→ specify(仕様)→ plan(設計)→ tasks(タスク)→ implement(実装)。加えてオプションで clarify(曖昧な箇所を質問する専用工程)、analyze(文書間の整合検査)、checklist(品質チェックリスト)がある。

    同じ要求を渡す

    Kiroに投げたのとまったく同じ、4つの視点の指示文を貼り付ける。

    画像
    【目標】【人間】【システム】【データ】——Kiroの検証で使った指示と一字一句同じ

    Kiroは「新機能かバグ修正か」「何から始めるか」と2つのプロセス質問を挟んだ。Spec Kitは何も聞かずに仕様書を書き始めた。

    画像
    specs/001-expense-approval-workflow/spec.md を作成中

    約8分で154行の仕様書が完成した。

    画像
    spec.md 154行に加えて、品質チェックリストまで自動生成された

    出てきた仕様書が、別物だった

    同じ要求から出てきたのに、Kiroの要件定義書とは別物だった。

    1. EARSではなく、Given/When/Then。 受入基準は「Given 申請者がログインしている状態で、When 5万円未満の申請を提出すると、Then 上長承認待ちとなる」という書き方。曖昧さと戦う流儀が、そもそも違う。

    2. 目標が、測れる数字になった。 Success Criteria という必須セクションがあり、私の「滞留を減らす」という一言から測定可能な指標を自分で導き出していた——締め日時点で当月分100%処理(運用3か月以内)、平均3営業日以内、監査照会1分以内、滞留ゼロ。Kiroでは「目標の視点」が最後まで弱かったが、こちらはテンプレートが目標を書かせる構造になっている。

    3. エッジケースを、聞かずに7つ挙げた。 その筆頭がこれだ。

    申請者に直属上長が登録されていない場合(役員・組織変更直後など)、申請の宛先をどう解決するか

    Kiroが最後まで放置した「組織の穴」を、Spec Kitは自分で拾った。ほかにも、承認待ち中に上長が変わったら/代理人が申請者本人だったら/差し戻したまま締め日を越えたら——実務で最初に詰まる場所が並んでいる。

    4. そして、空白を「仮定」として宣言した。

    ここが最大の違いだと思う。仕様書の末尾に Assumptions(仮定)という欄があり、9項目が並んでいた。5万円ちょうどは2段階と解釈する。25日当日は翌月扱いと解釈する。そして——

    承認完了後の支払・振込処理、および会計システムへの仕訳連携はスコープ外

    Kiroが最後まで無言でスコープ外にした後工程を、Spec Kitは書いて宣言した。

    黙って埋めるか、宣言して埋めるか

    自動生成された品質チェックリストの注記に、この道具の思想が凝縮されていた。

    曖昧だった点(5万円ちょうどの扱い、25日当日の帰属など)は [NEEDS CLARIFICATION] とせず、Assumptions に解釈を明記して解決した。解釈が実運用と異なる場合は /speckit-clarify で修正すること

    両者の違いはここに尽きる。Kiroは空白を、黙って「世間の常識」で埋めた。(頼んでいない「下書き」が紛れ込んだのがその象徴だ。)Spec Kitは空白を「こう解釈した」と宣言して埋め、直す入口まで示した。

    どちらも人間に業務を質問しない点は同じだ。だが、後から気づけるかどうかがまるで違う。宣言された仮定は読めば分かる。黙って埋められた常識は、誰も気づかないまま実装まで通り抜ける——私たちが検証で見たとおりに。

    4つの視点で採点すれば、目標◎(KPI化)・人間◎(組織の穴を拾った)・システム◎(機能要件15本)・データ○(主要エンティティ6つ、ただしER図はまだ)。同じ要求、同じ題材、違う道具。それだけで、これだけ変わる。

    今日のまとめ

    • Spec Kitの実体はスキル10本とテンプレート5本。専用アプリもクラウドもなく、実行は手元のAI=ツール独自のクレジットは無い

    • 同じ4視点の要求から、Kiroとは別物の仕様書が出た。EARSではなくGiven/When/Then、目標は測定可能なKPIに、エッジケースは7つ自力で列挙

    • 最大の違いは空白の扱い。Kiroは黙って常識で埋め、Spec Kitは「こう解釈した」と宣言して直す入口を示す

    • だが、仕様書が出て終わりではない。次回、この仕様から設計書を生成し、実際の構築まで——Kiroと同じ工程を、今度はローカルで走らせて確かめる

    タグ

    #AIエージェント #SpecKit #GitHub #ClaudeCode #スペック駆動開発 #要件定義 #要求定義 #システム開発 #SE #生成AI #50代

     
     
     
    SE30年。50代で退職、介護を終えて再起動。 いま検証しているのは Spec-Driven Development(SDD)。 1990年前後に同じ発想の CASE / RAD を現場で使い、失敗まで見ています。 3回目が本物かどうかを、freeeさん の人事給与で実測中。

    あなたへのおすすめ