https://www.youtube.com/watch?v=a9eR1xsfvHg

tasksまではGPT-5、コード生成はSonnet4がいい感じ

Figma MCPを使用するとデザインもいい感じにできる？

実際に使用されたプロンプト

constitution.mdを更新

Fill the constitution with the bare minimum requirements for a static web app based on the template.

/specifyでspecを作成

/specify I am building a modern podcast website. I want it to look sleek, something that would stand out. Should have a landing page with one featured episode. There should be an episodes page, an about page, and a FAQ page. Should have 20 episodes, and the data is mocked - you do not need to pull anything from any real feed.

specifyの結果をいい感じに

For things that need clarification, use the best guess you think is reasonable. Update acceptance checklist after.

/planを実行

/plan I am going to use Next.js with static site configuration, no databases - data is embedded in the content for the mock episodes. Site is responsive and ready for mobile.

/tasksを実行

/tasks break this down into tasks

実装を指示

Implement the tasks for this project, and update the task list as you go.

Gemini 2.5 Proによる要約

1. SpecKitの概要と目的

• 仕様駆動開発の簡素化 [00:01:40]
  • SpecKitは、開発者が仕様に基づいてソフトウェアを構築するプロセスを簡素化するために設計されたツールキットです。
• 「Vibe Coding」からの脱却 [00:02:00]
  • 目的：明確な仕様なしに感覚でコーディングを進める「Vibe Coding」にありがちな、実装やデザインの不正確さをなくし、よりスケーラブルなソリューションを目指します。
• オープンソースとCLI [00:02:28]
  • SpecKitはGitHub上でオープンソースとして公開されています。
  • specify CLIというコマンドラインインターフェース（CLI）が付属しており、開発プロセスを自動化し、雛形を作成します。

2. SpecKitのインストールと利用方法

• インストール方法 [00:02:58]
  • uvxコマンド: GitHubリポジトリから直接インストールできます（Pythonパッケージリポジトリへの公開は近日予定）。
  • 手動ダウンロード: リリースページからテンプレートを直接ダウンロードすることも可能です。CopilotやCloud Codeなど、様々なAIエージェントに対応したテンプレートが提供されています。
• プロジェクトの立ち上げ [00:05:02]
  1. uvxコマンドを使い、新しいプロジェクト（動画の例では「pod site」）を立ち上げます。
  2. 使用するAIエージェント（例: Copilot）とスクリプトの種類（例: PowerShell）を選択します。
  3. 選択に基づき、SpecKitが必要なファイルをダウンロードし、プロジェクトの雛形を展開します。

3. 主要なSpecKitコマンドと機能

• Constitutionファイル [00:07:49]
  • プロジェクトにおける譲れない原則（例: 常にテストを含める、Next.jsの特定バージョンを使用する）を定義するファイルです。LLMの支援を受けて簡単に作成・編集できます。
• /specify コマンド [00:15:18]
  • 製品の「何を（what）」と「なぜ（why）」、つまり製品の目的と構築すべき内容を定義します。
  • これにより、技術的な実装から完全に分離された仕様書が作成され、将来の技術スタック変更にも対応しやすくなります。
  • 仕様書にはユーザーシナリオ、テスト、機能要件、レビューのチェックリストなどが含まれます。
• /plan コマンド [00:24:02]
  • 具体的な技術要件（例: Next.jsを使用、静的サイト構成、データベースは不要）を定義します。
  • このコマンドはConstitutionファイルを参照し、プロジェクトの計画と追加メタデータを生成します。
• /tasks コマンド [00:31:06]
  • 作成された計画を、AIエージェントが処理しやすいように管理可能なタスク群に細分化します。
  • テスト駆動開発の場合、テスト作成→データモデル実装といった段階的なタスクが生成されます。

4. 実装と結果の確認

• タスクの実装 [00:34:36]
  • implement the tasks for this projectのようなコマンドで、LLM（動画ではCloud Sonnet 4モデル）にタスクを実装させます。
• サイトの構築と実行 [00:36:43]
  • npm run buildでサイトを構築し、npm run devでローカルサーバー（localhost:3000）を起動して結果を確認します。
• 生成されたサイト [00:37:31]
  • 動画では、ランディングページ、エピソードページ、アバウトページ、FAQページなどを備えた、モダンで洗練されたポッドキャストウェブサイトが生成されました。
• カスタマイズと再構築 [00:38:35]
  • 生成された仕様書と成果物があるため、色の変更や機能追加といったカスタマイズが容易です。
  • また、異なるLLMモデルを使ってソースコードを再生成することも可能です。

5. まとめ [00:39:27]

SpecKitは、仕様駆動開発という構造化されたアプローチを通じて、一貫性と品質の高いソフトウェアを効率的に構築するための強力なツールです。開発者はこれを用いることで、プロジェクトの仕様定義からAIエージェントによる実装までをスムーズに進めることができます。動画では、ぜひSpecKitを試してフィードバックを送ってほしいと締めくくられています。

GPT-5による要約

以下は、該当動画「The ONLY guide you’ll need for GitHub Spec Kit」の**内容要約（日本語／できるだけ詳細に構造化）**です。
※動画ページ自体のテキスト取得が難しいため、動画中で解説されている要点は公式ドキュメント／GitHub Blogの一次情報と照合して整理しています（補完した部分はその旨を示します）。(GitHub)

1. 概要（何の動画か）

• テーマ: GitHubの実験的OSS「Spec Kit」を使ったSpec-Driven Development（仕様駆動開発）の実践ガイド。
  目的はAIコーディング（Copilot / Claude Code / Gemini CLI / Cursor 等）で起こりがちな“vibe coding（場当たり的プロンプト）”をやめ、仕様→計画→タスク→実装の流れをAIに踏ませて、再現性と品質を上げること。(The GitHub Blog)
• 発信者: Den Delimarsky（GitHub PM、Spec Kitメンテナ）。(GitHub)

2. なぜSpec-Driven Developmentか（背景と問題意識）

• 従来の「雑に要件を投げて大きなコード塊を返してもらう」やり方は、動かない／意図とズレる／スタックが勝手に変わるなどの不確実性が高い。
• **AIは“読心術”ではなく“厳密なペアプロ”**として扱うべきで、曖昧さを仕様で先に潰すと精度が上がる——という立場。(The GitHub Blog)

3. ワークフローの全体像（4フェーズ）

**動画の中心はこの4段階の反復。**各フェーズごとに“人間がチェックしてから次へ”を強調。(The GitHub Blog)

1. Specify（仕様化）

   • 何を・誰のために・どうなれば成功か（What/Why/Outcomes）を高密度に記述。
   • スタックや設計の話はまだしない。生きた仕様として後で更新していく。(The GitHub Blog)

2. Plan（技術計画）

   • スタック／アーキテクチャ／非機能要件／社内標準・制約（セキュリティ、デザインシステム等）を明示。
   • 複数案の比較も可能。(The GitHub Blog)

3. Tasks（タスク分解）

   • 仕様＋計画を小さく検証可能なタスクへブレークダウン。
   • 「認証を作る」ではなく「メール形式を検証する登録エンドポイントを作る」のように単機能・検証容易に。(The GitHub Blog)

4. Implement（実装）

   • AIがタスク単位で実装。人間は差分レビューで意図と整合を確認し、必要なら仕様・計画・タスクへ差し戻し。(The GitHub Blog)

公式リポジトリにも同趣旨の「開発フェーズ」整理があり、動画と整合します。(GitHub)

4. セットアップと基本コマンド（動画内デモの要点）

**CLI（Specify）**を使ってプロジェクトを初期化し、エージェントに専用スラッシュコマンドを使わせる流れ。(GitHub)

• インストール／初期化

  uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME>
  

  • --ai で claude | gemini | copilot | cursor を指定可
  • --script で sh または ps（Windows等）を選択
  • --here でカレントに展開、--no-git でGit初期化スキップ、specify checkで要件確認 など。(GitHub)

• エージェント側の操作（IDE/CLI内）

  • /specify … 高レベル要求→詳細仕様を生成（ここでは技術選定をしない）
  • /plan … 技術計画（スタック、アーキ、制約、非機能）を生成
  • /tasks … 実装タスクの一覧と順序を生成（小さく検証可能に）
    （コマンドの役割は公式Blog/READMEと一致）(The GitHub Blog)

• テンプレートの更新状況（信頼性）

  • 直近では v0.0.30（2025-09-13） で Copilot/Claude/Gemini/Cursor 向けテンプレートと sh/ps 版が整備。頻繁に改善されている。(GitHub)

5. どんなユースケースに強いか

• ゼロ→イチ（Greenfield）: 仕様重視で“汎用サンプル”に流れない。
• 既存機能追加（N→N+1）: 既存制約を計画に織り込み“馴染むコード”に。
• レガシー刷新: 失われた意図を現代の仕様に再定義し、計画→再実装へ。(The GitHub Blog)

6. 良い“仕様／計画／タスク”の書き方（動画内TIPS＋公式の要点）

• 仕様（/specify）: ペルソナ／ユーザージャーニー／成功基準／制約（例: 「アルバムは入れ子不可」）など挙動に集中（技術の話はしない）。(GitHub)
• 計画（/plan）: 採用技術、設計原則、統合ポイント、社内標準・コンプラ、SLO/性能目標など実装ガードレールを列挙。(The GitHub Blog)
• タスク（/tasks）: 独立にテスト可能・レビュー容易・粒度小・明確な完了条件。大課題は分割する。(The GitHub Blog)

7. よくある失敗と回避（動画の注意喚起と一致するポイント）

• 仕様で“技術の話”を始めてしまう → 計画でやる。仕様は目的と挙動に専念。(The GitHub Blog)
• 巨大PRを一発生成 → タスク分解し小さく検証。(The GitHub Blog)
• “暗黙の社内ルール”をAIに共有しない → 計画へ明文化してから実装させる。(The GitHub Blog)

8. エコシステム連携（補足）

• 対応エージェント: GitHub Copilot、Claude Code、Gemini CLI、Cursor などに公式テンプレートあり。(GitHub)
• 環境前提: Python 3.11+、uv、Git、Linux/macOS（WindowsはWSL2またはPowerShell）。(GitHub)

9. まとめ（要点）

• 言語化された“意図”＝仕様を源泉に置き、AIには仕様→計画→タスクの明確な足場を与える。
• エージェントは**大仕事（生成）を、開発者は判断（検証・差し戻し）**を担う。
• テンプレートとCLIが揃っており、少ないコマンドで導入できる。(GitHub)

参考URL（一次情報）

• 動画: The ONLY guide you’ll need for GitHub Spec Kit（Den Delimarsky）
  https://www.youtube.com/watch?v=a9eR1xsfvHg
• 公式リポジトリ（README／CLIリファレンス／テンプレート）
  https://github.com/github/spec-kit (GitHub)
• GitHub Blog（公式解説）
  https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/ (The GitHub Blog)
• リリース（最新テンプレート v0.0.30 など）
  https://github.com/github/spec-kit/releases/tag/v0.0.30 (GitHub)

補足（推測の明示）: 上記の「デモの進行順」や「動画内の言い回し」は、公式ドキュメントに完全一致するため高確度ですが、動画を逐語で起こしたものではありません。より厳密な逐語要約が必要なら、該当回の字幕テキストが公開され次第、そこからも再構成できます。

• 仕様書や計画、タスクがMarkdownで残る。
  • チームでの共有・レビューがしやすい。
  • 後から新メンバーが参加しても背景を理解しやすい。
  • 再現性がある。GPT-5で実行してイマイチだったらSonnet 4で動かしてみる、といったことも簡単にできる
• 小さいタスクに分割できる。
• LLMが生成した仕様や計画を必ず人間がレビュー・修正する必要がある。
• チームで運用するなら、ある程度の教育やルール化が必要。

大規模開発やチーム開発では、仕様の明確化・一貫性・再現性が大きな価値を持つ。
小規模プロトタイプや個人開発では、オーバーヘッドが大きい。

結論

• 個人の小規模な開発 → 単純なvibe coding で十分。
• チーム開発・長期運用プロジェクト → Spec Kitが輝く（はず）。