クリスマスだからSpec Kitで仕様駆動ローストチキンを作ってみた

この記事はHTアドベントカレンダー23日目の記事です🔔
12/23ということは…あれよあれよという間に、明日はもうクリスマスイブですね！🎄
そろそろローストチキンでも食べたくなってきませんか？ 食べたいですよね。食べましょう。

---

・・・と、ある日の晩、無性にローストチキンが食べたくなった私。

しかし、普段料理をしない私は料理本など持っているはずもなく、ローストチキンと聞いても「なんか適当に鶏肉を焼いたやつ」ぐらいの知識しかありません。 困りました。手元にあるのは Codex CLIがインストールされたMacBook だけ…。

こうなると仕方ありません。2025年は12月24日、25日が平日ですし、仕事終わりのわずかな時間でローストチキンを作るべく、何を血迷ったか、私は急遽AIコーディングの力を借りて、大急ぎでローストチキンを作ってみることにしたのです。しかも、Vibe Codingより一歩先、最近話題の 「Spec-Driven Development（仕様駆動開発）」 に従って得られた作り方を頼りに──

はじめに

仕様駆動開発(SDD)

仕様駆動開発 (Spec-Driven Development,"SDD") とは、その名が示す通り「仕様（Spec）を開発プロセスの中心（Source of Truth）に据える」というアプローチです。
2025年7月、AWSが公開した統合開発環境"Kiro"が、その機能として「仕様を固めないと実装に進ませない」というSpec Modeを導入していたことから注目されるようになった考え方です。

従来のVibe Codingにおいては、チャットで「こういうアプリ作って」と依頼し、AIが即座にコードを生成していましたが、これには方法の性質上、「文脈の限界」 という構造的な弱点がありました。具体的には、対話が進むにつれてコンテキストウィンドウが埋まり、最初の意図が忘れ去られたり、AIが勝手に要件を補完（推測）して「それっぽいけど違うもの」 が出来上がってしまうという事態です。¹こうした問題に対して、Kiro はすべての要件や制約を明示化し、それをコンテキストとして利用して、少ない反復回数で高精度にタスクを完了するという手法で開発プロセスの変革を進めようとしており、Vibe Codingに疲れが出始めていた開発者の支持を次第に得るようになりました。

この手法の最大のメリットは、仕様書が 「AIエージェントがコードを生成・テスト・検証するための契約書」 として機能する点です。チャットの履歴という「流れていく情報」ではなく、ファイルとして保存された「固定された情報」を正とするため、AIは常に正確なコンテキストを参照することができます。また、仕様段階で曖昧さを排除することで、コードを書いてから「なんか違う」と直すコストに比べ、仕様の段階で「ここはどうなってる？」と詰めるコストの方が圧倒的に低くなり、結果として実装後の手戻りを防ぐことにつながるのも大きな利点です。

すなわち、「How（どう作るか）」の前に「What（何を作るか）」を徹底的にAIと認識合わせをするというのが、SDDの肝となるマインドであると言えます。

Spec Kit

先ほど紹介したKiroは、統合開発環境としてSDDを強く推進する立場となりましたが、この思想を汲み、よりAIコーディングの補助ツールとしての性質を持ったものが、GitHubが2025年9月に公開した Spec Kit です。

Spec Kitは、「Spec-Driven Development」を実践するためのCLIツールキットです。あくまでCLIツールキットなので、これ自体がコードを書くわけではなく、AIコーディングツールの補助的な位置付けに相当します。

このSpec Kitの真骨頂は、単に作るだけでなく、「仕様そのものを検証する」 というプロセスにあります。GitHub CopilotやOpenAI Codex、Claude CodeといったAIエージェントと連携し、仕様策定から実装までのフェーズを管理・ガイドする役割を担います。

「とりあえずコード書こうぜ（Vibe）」ではなく、「まず仕様（Spec）を固めようぜ」 という、ある意味で原点回帰でありながら、AIの力を最大限に活かすためのモダンなアプローチです。

Spec KitにおけるSDDのアプローチ

SDDの方法論は、仕様 → 計画 → タスク化のワークフローを自動化する3つの強力なコマンドによって大幅に強化されます。Spec Kitにおいても、いきなりコードを書くのではなく、以下のプロセスを経ることで 「意図（Intent）」と「実装（Implementation）」のギャップを埋めようとしています。

/speckit.constitution : 憲法の策定

• プロジェクトの憲法となる管理原則や開発ガイドラインを作成したり、更新したりします。

/speckit.specify : 仕様の策定

• このコマンドは、単純な機能の説明（ユーザープロンプト）を、リポジトリ管理が自動化された完全で構造化された仕様に変換します。

  1. 機能番号の自動採番: 既存のスペックをスキャンして、次の機能番号（例: 001, 002, 003）を決定します。
  2. ブランチ作成: 説明から意味のあるブランチ名を生成し、自動的に作成します。
  3. テンプレートベースの生成: 機能仕様テンプレートをコピーし、要件に合わせてカスタマイズします。
  4. ディレクトリ構造: 関連するすべてのドキュメントのために適切な specs/[branch-name]/ 構造を作成します。

/speckit.plan : 計画の作成

• 機能仕様が存在する状態でこのコマンドを実行すると、包括的な実装計画が作成されます。

  1. 仕様分析: 機能要件、ユーザーストーリー、受け入れ基準を読み取り、理解します。
  2. 憲法への準拠: プロジェクト憲法およびアーキテクチャ原則との整合性を確保します。
  3. 技術的翻訳: ビジネス要件を技術アーキテクチャと実装の詳細に変換します。
  4. 詳細なドキュメント化: データモデル、API契約（コントラクト）、テストシナリオのためのサポートドキュメントを生成します。
  5. クイックスタート検証: 主要な検証シナリオを捉えたクイックスタートガイドを作成します。

/speckit.tasks : 実装

• 計画が作成された後、このコマンドは計画と関連する設計ドキュメントを分析し、実行可能なタスクリストを生成します。

  1. 入力: ここまでの作業で作成したPlan(計画)や、関連するドキュメントを読み取ります。
  2. タスク導出: 契約、エンティティ、シナリオを具体的なタスクに変換します。
  3. 並列化: 独立したタスクに マークを付け、安全な並列グループを作成します。
  4. 出力: 機能ディレクトリに、実装作業を進めるリストであるtasks.md を書き込みます。こうすることで、Taskエージェントによって実行される準備が整います。

プロセスを厳格化して運用したいような実際の開発現場や、より失敗が許されないシチュエーション下では、以下のコマンドを使って品質ゲート（Quality Gate）　を設置することが推奨されています。これらを活用することで、仕様の抜け漏れや矛盾を実装前に検知することが可能であるという考え方です。

コマンド	説明
/speckit.clarify	不確定要素に対して詳細を指示することで、明確化を行います。 ( /speckit.planの前段階での実行が推奨）
/speckit.analyze	アーティファクト間の整合性やカバレッジを分析します（/speckit.tasks の後、/speckit.implement の前に実行）。仕様と実装計画に矛盾がないかチェックします。
/speckit.checklist	要件の完全性や明確さを検証するためのカスタムチェックリストを生成します。「英語のユニットテスト」のような感覚で、仕様そのものの品質をテストできます。

全体像

上記のアプローチを「実際に使うと何が起きるか」を俯瞰したフローチャートは、このように描くことができます。個々の行程は、これまで人が時間をかけて実施していた部分もありますが、AIに作業を前面的に委ねることにより、結果として短時間で、しかし堅実な開発サイクルを回すことが念頭に置かれて設計されています。

導入手順

Spec KitはPython製のツールで、uv を使ったインストールが推奨されています。

# Spec Kitのインストール
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

# プロジェクトの初期化
# --here: カレントディレクトリで開始
# --ai codex: 使用するAIエージェントを指定（今回はCodex）
specify init --here --ai codex

--ai オプションでは、Codexの他にも claude (Claude Code), copilot (GitHub Copilot CLI), gemini (Gemini CLI) など、様々なAIエージェントを指定可能です。
手持ちのAIツールに合わせて選べるのがSpec Kitの魅力の一つです。

実際にレシピを作ってみよう

さて、ここからが本題。
今回はこのSpec Kitでプロセスを管理し、実働部隊のAI AgentとしてOpenAIの Codex CLI を使い、ローストチキンのレシピを生成します。

Spec Kitの設定が正しく済んでいれば、Codex CLIを起動するとすでにSpec KitのCLIコマンドが呼び出せるようになっているはずです。これを活用して各フェーズを管理しながら、AIエージェント（今回はCodex）に対話的に指示を出してレシピの実装を進めていきます。

具体的には以下のようなフローで進みます。

1. プロジェクトの憲法となるルールの制定 (/speckit.constitution)

まず、プロジェクトの憲法を定めます。
憲法ですから、ここで生成したものは以後の実装において、すべての意思決定において参照される重要な指針となります。
今回はあえて細かいルールは設けず、「日本語でのドキュメント化」 だけを強制しました。

/speckit.constitution 出力構成・開発規則などはお任せしますが、ドキュメント類は日本語で残してください。

これによって、AIはデフォルトのベストプラクティスに従いつつ、レシピの読者となる日本人の私が読みやすい形式で出力してくれるようになります。

2. 仕様の策定 (/speckit.specify)

次に、何を作るかという「要件」を定義します。このコマンドのなかの記述のみによって進めることも可能ですが、今回は requirement.md という外部ファイルに要件をまとめ、それを読み込ませる形を取りました。

/speckit.specify  requirement.md に従って、ローストチキンを作れるようになるガイドを考えてください

requirement.md の中身:

# Overview
- 料理をやったことのない人でも、自宅で簡単に作れるローストチキンの作り方をドキュメントにしてください。
# 詳細
## ユーザー像
- 普段、自分で料理をすることがなく、料理のワードもあんまり肌感覚がつかめていません。
- レシピを読んでも、なかなか行間がわからないので、食材の選び方から懇切丁寧に順序立ってやり方を教えてあげる必要があります。
- ローストチキンが何かもあまりわかっていません。
## 考慮すべき事項
- 日本の一人暮らしや、2,3人家族であることを念頭に、フライパンとオーブンで調理できるものなど、現実的に日本の一般家庭の規模感で実現可能なものとしてください。
- 味付けや分量などについては、それらが適正であるかの吟味も怠らないようにしてください。（味が薄かったり、濃かったり、適正量でないか）
## その他
- アウトプット形式は、単なるメモでも良いですし、ユーザーが成果物を参照しながら調理ができると良いので、適切な方法を選択してください。
- あなたが作成したアウトプットを参照に、ユーザーが実際に検証することも念頭においてください。

ローストチキンが具体的に何かもよくわかっていない激ヤバさターゲットの初心者像をマイルドな表現で要件に反映するため、ここでは「料理をやったことがない」「行間がわからない」というペルソナ設定を明記することが重要になります。これによって、AIに「適当に焼いてください」という指示よりも「何分焼くか、どう確認するか」を意識して記述したほうが、読み手は事故らないと考えるようになります。

3. 仕様の明確化 (/speckit.clarify)

Spec Kitは、一方的な指示で終わらせず、要件において解像度をもう一段階高めたい時に、対話的に仕様を詰められるような工夫がされている点もポイントが高いです。
今回は、specify の後、さらに解像度を上げるために追加指示を出しました。

/speckit.clarify 必須ではないが、美味しくなるポイント・味付けのオプションも盛り込んでください
/speckit.clarify ユーザーの解像度をもう少し高めたいです

これにより、以下のような詳細な仕様書（spec.md）が生成されました。
「ローストチキンを焼くだけで80分〜100分かかるのはどうなの」 というツッコミはさておき、特に「ユーザーストーリー」として、初心者の心理的ハードル（5分で把握したい、温度計がない不安など）が定義されていることがわかります。

# 機能仕様: ローストチキンレシピの作成 (抜粋)

## ユーザーストーリー1 - 短時間で段取りを掴む (優先度: P1)
料理初心者として、ローストチキンを作る前に短時間（目安5分、多少超過も可）で全体の流れと必要な道具・食材を把握したい。そうすれば、買い物や下準備を迷わず開始できる。

**受け入れシナリオ**:
1. **前提** 読者が初見でドキュメントを開いた、**もし** 冒頭の概要と買い物リストを読む、**ならば** 7分以内に道具・分量・工程の全体像を口頭で説明できる。

## ユーザーストーリー2 - 手順通りに安全に焼き上げる (優先度: P1)
家庭のキッチンで、手順と時間の目安に従ってチキンを安全に焼き上げたい。そうすれば、中まで火が通り、食中毒の不安なく提供できる。

**独立テスト**: ドキュメント通りに調理し、中心まで加熱されたチキンを80〜100分内で提供できれば合格。

4. レシピ作りの計画 (/speckit.plan)

仕様が固まったら、どう実現するかを計画するステップに移ります。

/speckit.plan

AIは requirement.md にもあった「日本の一般家庭」「フライパンとオーブン」という制約に基づき、以下のような実装計画（plan.md）を立案しました。

# 実装計画: ローストチキンレシピの作成 (抜粋)

## 概要
- ローストチキンの作り方を、約5分を目安に全体像を掴めてそのまま調理に使えるレシピ形式へ拡充する。
- 成功指標は「読了目安5分（最大7分で理解）」「80〜100分内で安全に提供」「換算後も味の再調整不要」「リカバリーで廃棄抑制」。

## 技術コンテキスト
- **ターゲット環境**: 静的閲覧（GitHub/ローカルエディタ）
- **性能目標**: 読了目安5分（最大7分以内）で概要把握でき、80〜100分の調理タイムラインを提示
- **制約**: オーブン非必須（フライパン・トースター前提）、安全確認を温度計なしでも実施可能にする

5. タスク分解 (/speckit.tasks)

次に、計画を具体的なタスクに落とし込みます。
ここで面白いのは、タスクが「フェーズ」に分かれ、それぞれに「ゴール」と「テスト」が設定されていることです。（ややこしいですが、料理の手順そのものではなく、「レシピを作るためのタスク」です）

# タスク: ローストチキンレシピの作成 (抜粋)

## フェーズ3: ユーザーストーリー1 - 5分で段取りを掴む (優先度: P1) 🎯 MVP
**ゴール**: 初見で工程・道具・分量の全体像を把握しやすいレイアウトと用語解説を提供する。

- [ ] T004 [US1] 概要文を記述し、「読了5分は推奨（必須でない）」と明記して理解ハードルを下げる
- [ ] T005 [P] [US1] 用語解説ブロックを追加し、「皮目=皮が付いた面」「身側=皮がない面」「押し返し=指で押したときの弾力」など初心者が迷う語を定義
- [ ] T006 [P] [US1] 買い物リスト表を見やすく配置し、1人前/2人前列の横に「代替食材（骨付き/むね）補足」を脚注か備考に記載

## フェーズ4: ユーザーストーリー2 - 手順通りに安全に焼き上げる (優先度: P1)
**ゴール**: 下準備〜火入れ〜安全確認の手順を細かい操作（拭き取り方・馴染ませ方・調味料投入順）まで網羅し、温度計なしでも安全に仕上げられる。

- [ ] T008 [US2] 水分の拭き取り方法を詳細化（キッチンペーパーで皮目/身側を押さえる手順、叩きすぎない注意）を準備節に追加
- [ ] T010 [P] [US2] 調理タイムラインを工程別に細分化し、火加減・返すタイミング・皮目/身側の扱い、温度計なしのチェックポイントを各工程行内に記載
- [ ] T011 [US2] 安全チェック節を拡充し、押し返し/肉汁/断面の判定基準と未達時の追加加熱手順をステップ別に箇条書き

6. 実装 (/speckit.implement)

いよいよ実装です！

/speckit.implement

生成されたレシピ（Artifact）

上記のコマンドを実行すると、最終的なレシピがquickstart.md として、markdown形式で出力されました。

# Quickstart: ローストチキンをすぐ作る

目標: 約5分（最大7分）で段取りを掴み、80〜100分で安全に提供する。道具はフライパンとトースターを想定（オーブン不要）。温度計が無くても押し返し/肉汁/断面で判断できるようにする。

## 1. このガイドの使い方（読了目安5〜7分）
- 上から順に読みながら買い物→下準備→焼き→安全チェック→提供まで進める（5分読了は目安、多少超えてもOK）。
- 1人前/2人前の分量・時間を表内で確認し、道具や食材を持っていない場合は代替手順を参照。
- 用語が不安な場合は次の「用語ミニガイド」を先に読んでおく。

## 1.1 用語ミニガイド（初心者向け）
- 皮目: 皮が付いた面。焼き色はここから付ける。
- 身側: 皮が無い面。
- 押し返し: 指で軽く押したときの弾力。沈み込まず戻れば火が通りやすいサイン。
- 肉汁: カットや押したときに出る液体。透明なら火が通り、赤みがあれば追加加熱。

## 2. 買い物リスト（1人前 / 2人前）
| 材料/道具 | 1人前 | 2人前 | 備考 |
|-----------|-------|-------|------|
| 鶏もも肉（骨なし皮付き） | 250〜300g | 500〜600g | 骨付き: +5〜8分/枚・裏返し1回追加。むね: 油+小さじ1、火入れ2〜3分短縮。2枚同時は重ならないよう配置 |
| 塩・黒胡椒 | 塩2.0〜2.5g | 塩4.0〜5.0g | 仕上げにひとつまみ追加可（表面にまんべんなく） |
| にんにく | 1かけ | 2かけ | すりおろし/みじん切りどちらでも可 |
| レモン | 1/4個 | 1/2個 | 仕上げと味調整用 |
| オリーブ油 | 小さじ2 | 小さじ4 | むね肉は+小さじ1 |
| オプション: 醤油・バター | 醤油小さじ1 / バター10g | 醤油小さじ2 / バター20g | 焼き上がり直後に絡める |
| オプション: パプリカP | 小さじ1/2 | 小さじ1 | 焼き色後に振る |
| オプション: ハーブ（ローズマリー） | 生1枝 or 乾燥小さじ1/2 | 生2枝 or 乾燥小さじ1 | ちぎって下味に混ぜ、仕上げに軽く追い香り。ハーブ無しでも可。 |
| 道具 | フライパン（フタ推奨）、トング、包丁、まな板、キッチンペーパー | 代替: フライパンのみ運用（フタ必須）。耐熱皿/クッキングシート/アルミホイルを補助に使用 |

## 3. 事前準備（~30分）
1. 水分を拭き取る: キッチンペーパーで皮目→身側の順に軽く押さえ、ドリップを吸わせる。叩かず押し当てる。
2. 味をなじませる: 塩→胡椒→にんにく→（使うならローズマリーをちぎって薄く散らす）→オリーブ油の順で表裏に擦り込む。乾燥ローズマリーなら全体に薄く振り、室温戻し10〜15分。
3. トースターを使う場合は耐熱皿やクッキングシートを準備。フライパンのみの場合はフタを用意。

## 4. 調理タイムライン（合計目安80〜100分）
1. **焼き色付け（フライパン 中火 5〜7分）**  
   - 皮目を下に置き、動かさず焼く。脂が出てきつね色になればOK。焦げそうなら火を弱め、余分な脂はキッチンペーパーで軽く吸う。
   - フライパンのみ運用の場合はここでフタを温めておく。
2. **火入れ（トースター 中〜弱 10〜15分）**  
   - 途中で裏返し1回。骨付きは+3〜5分、むね肉は-2〜3分。  
   - フライパンのみ: 弱火+フタで7〜10分、途中返し1回。皮目を上にして蒸し焼きにし、最後に皮目を下に30秒〜1分当ててパリッとさせてもよい。
3. **休ませ（10分）**  
   - アルミホイルをゆるくかぶせ、肉汁を落ち着かせる。皮目が蒸れすぎないよう軽く空間を作る。
4. **盛り付け（5分）**  
   - 繊維に直角にカットし断面を確認。仕上げ調味（レモン/醤油バター/パプリカ）を加える。ローズマリーを使う場合は弱火または余熱で数秒当てて香りを立たせ、焦げそうならすぐ外す。

### チェックポイント（各工程）
- 焼き色: 皮が均一にきつね色。黒くなり始めたら火を下げる。油が跳ねる場合は火を弱める。
- 押し返し: 指で押して弾力があり、沈み込みすぎない。
- 肉汁: 透明で赤みがない。赤い場合は追加火入れ。
- 断面: ピンクが残らない。温度計があれば中心75℃目標。

## 5. 安全チェックとリカバリー
- **生焼け疑い**: トースター弱火5分追加（骨付きなら+3分）、またはフライパン弱火+フタ5分。再度肉汁/押し返し/断面を確認し、透明かつ弾力が出るまで繰り返す。
- **焦げ**: 焼き色面を上にしてアルミホイルをかぶせ、トースター弱火5分。黒色や強い苦味は薄く削り、それでも苦ければ廃棄。
- **味が薄い/濃い**: 休ませ後に塩ひとつまみ or レモン追加。濃い場合はレモンとバター少量で調整し、表面を拭って味をリセットする。

## 6. 保存と再加熱
- 保存: 粗熱後に密閉容器で冷蔵、24時間以内を目安。**異臭・変色・時間超過は廃棄**。
- 再加熱: トースター中火5〜7分、またはフライパン弱火+フタで温め直し。再度肉汁/押し返しを確認し、ピンクや赤みが残れば追加加熱。

## 7. セルフチェック（完了の証跡）
- [ ] 短時間（目安5〜7分）で読了し、必要な道具・分量・所要時間を列挙できる。
- [ ] タイムラインに沿って80〜100分内で提供できた。
- [ ] 押し返し/肉汁/断面の3点で火通りを確認した。
- [ ] 焦げ・生焼け・味の再調整手順を実施/理解した。
- [ ] 保存と再加熱の条件を守る計画を立てた。

・・・なんだかそれっぽい。 買い物リストや作り方はもちろん、読み手のレベルを考慮して、用語解説や調理時のセルフチェック項目まで書いてあります。これは期待できそう！

実際に調理した

忘れかけていましたが、この記事の最終目標はローストチキンを食べることです。

レシピを作って終わりではないので、quickstart.mdの内容に基づいて、実際に私がキッチンで調理を行いました。

トースターで火入れする時の初期配置は皮目・身側どっちかわからなかったり、タイムラインの目安時間80~100分の内訳になってないと気付いたり、改めてレシピを細かくみると気になるところはありましたが、概ねレシピ通りに進みます。少しトースターの焼きが足りないかなとも思ったので、これは5.の安全チェックに従い、焼き時間を5分追加しました。

完成！

ついでに買ってきた野菜を足してみました。焼き色もいい感じ。それっぽいのでは…？

実食

皮はパリパリ、中はジューシー。普通に食えるレベルです。
いい感じのSDDローストチキンができました。

フィードバックから見えたSDDの要注意ポイント

今回、万が一衛生的にまずい場合は最悪止めに入ってもらう前提で、料理経験豊富な家族に、一連の調理工程を横で見守っててもらいました。完成を見届けた後でフィードバックをもらったのですが、ここから得られるSDD活用の要注意ポイントもいくつかありました。

👩💬 筋を取る工程が入ってなかったね…

仕様書（Spec）には「食べやすいこと」という非機能要件が含まれていましたが、実装の手順におけるPlan,Tasksの各工程においては、「筋切り」が具体的に定義されていませんでした。

👩💬 表裏をひっくり返すタイミングとか書いてなかったね…

確かに、レシピには「途中で裏返し1回」とありましたが、一方でそのタイミングに関する情報が記載されていませんでした。今回は15分の焼き時間の半分で裏返しましたが、皮側ばかりを焼くだけでは身にしっかりと火が通らないので、この辺りの情報は結構重要になってきます。

👩💬 塩はもうちょっとあっても良いかもね…

元々のspecを決めるにあたって、調味料周りは適量である前提で、測定可能な指標での指示は特にしていませんでした。どのくらいの塩分だと良いのか、全体の量の何%が適量だとかといった、厳密な型定義（分量指定）が必要だったかもしれません。

このフィードバック(ユーザー受入テスト?)を半ば強引にSDDの教訓、注意点として振り返るならば、下記のように書けるかもしれません。

フェーズ	料理での出来事	SDDの教訓
要件定義	「食べやすく」と書いた	抽象的なUX目標だけでは実装できない
設計・実装	「筋切り」を書き漏らした	ドメイン知識がないと仕様の穴に気づけない
環境構築	オーブンの癖を無視した	本番環境の制約をコードに反映すべき
テスト	「適量」でパスさせた	定量的評価基準がないと品質保証ができない

Spec Kit をはじめとするSDDを使う最大のメリットは、「実装（調理）に入る前に、仕様という文書上でシミュレーションができること」 です。しかし、この考え方を推進する前提として、「何を書くか（What）」 の解像度が低いと、出力されるコード（レシピ）も荒くなるというところは、特性として認識すべきことだと考えます。今回の場合、実際の環境（調理場）で起こり得ることを想定した上で、「制約条件（Constraints）」と「定量目標（Metrics）」 を詳細にレビューできていたら、今以上により良いレシピが作れるかもしれません。

（とはいえ、妻と今回作った料理を試食して「美味しい」「良いじゃん」という会話ができたので、少しホッとしました）

おわりに

多少の仕様の甘さが露呈した事実はあれど、「普段料理をしない私が、平日の夜に、大きな失敗もなく美味しいローストチキンを食卓にデプロイできた」のは、とても良い経験になりました。

もしこれが、Vibe Codingのように順序立てずにAIへ適当なレシピを作らせるアプローチであれば、「適量って何？」「焼き加減がわからん」と途中でパニックになり、黒焦げのチキンか、あるいは生焼けの何かを生み出していたかもしれません。 Spec Kitが強制する 「まず計画（Plan）し、タスク（Tasks）に分解し、一つずつ実行（Implement）する」 というプロセスが、未知の領域に対する心理的ハードルを下げ、着実なゴールへと導いてくれました。これは、AIが単にコードを書くだけでなく、「遂行プロセスそのものをサポートしてくれた」 良い例と言えます。

昨今、Qiitaをはじめとする技術コミュニティでは、今回のSpec Kitのような公式ツールだけでなく、cc-sdd のような国産のSDD支援ツールも登場し、議論が活発化しています。これらが示唆しているのは、AIコーディングのトレンドが「魔法のように作ってもらう」フェーズから、「エンジニアが仕様（意図）を精密に設計し、AIを確実な戦力としてコントロールする」 フェーズへと成熟しつつあるということです。

「仕様を書く」というと堅苦しく感じるかもしれませんが、今回のローストチキンのように、「自分のやりたいこと（What）」 を言語化さえすれば、「どうやるか（How）」 はAIが強力にサポートしてくれる時代が来ています。 その意味で、SDDは開発の面倒を増やすものではなく、私たちエンジニアがより高度な「作りたいもの」に挑戦するための翼 になってくれるはずです。

ということで、皆さんも来年のクリスマス、機会あればSpecでチキンを焼いてみてはいかがでしょうか。Happy Holidays & Happy Coding! 🍗💻

【免責事項】

• 本記事に掲載しているレシピは、生成AIを使用して作成したものです。
  • レシピを使用して実際に調理・実食をされる場合、品質・味や再現性についての保証は一切いたしかねます。 加熱時間のコントロールをはじめとする食品衛生管理、アレルギー等に十分ご注意いただきつつ、自己責任 でお楽しみください。
  • 一般的な解釈として、料理レシピそのものに著作権は存在しないと考えられていますが、生成物の精度向上を目的としてレシピサイトやレシピ本の内容を学習させる行為は、（イラスト・画像も含めた）サイトや本のコンテンツを盗用しているものとして、規約等により禁止されている場合があります。
• Qiitaは料理サイトではありません。
  • 本記事は、身近な題材を通じて仕様駆動開発への理解を深めてもらうことを主たる目的としています。

1. 例えば、Vibe Codingでよくあるフラストレーションとして、0から1の開発においてなんとなく与件に応じた感じは出してくれるが、いざ詳細の手直しを始めていくと動いていたものが動かなくなったり、「あれ、さっき言った条件どこいった？」といった経験は筆者も少なからずあります。 ↩