1. はじめに
最近、プロダクト開発の環境って本当にものすごい勢いで変わっていますよね。ClaudeやChatGPTをはじめ、高度なコード生成や自律的にタスクをこなしてくれる「AIエージェント」が次々と登場し、日々の開発に当たり前のように溶け込んできています。ただ人間が指示したコードをAIが補完するだけのフェーズはもう過去のもの。今や、AI自身が考えてコンポーネントを組み立て、プロダクトを形作っていく時代に入っています。
そんな「AIエージェント時代のプロダクト開発」をさらに加速させるツールとして、2025年9月にGitHubからオープンソースで公開され、今注目を集めているのが「Speckit」です。
Speckitは、「仕様駆動開発（Spec-Driven Development: SDD）」を実践するためのツールキット。人間とAIエージェントがスムーズにコラボして、自然言語で書かれた「仕様書」からコードの実装までをきれいに管理・生成することを目的としています。
今回は、このSpeckitがもたらす開発体験の面白さやメリットを紹介しつつ、実際にシンプルなTodoアプリを開発するフロー、さらにはPlaywright MCPを組み合わせたブラウザテストの自動化まで、実際に触ってみた体験をレポートします。
2. 仕様駆動開発（SDD）とSpeckitを使うメリット
Speckitの基本思想になっているのは「仕様駆動開発（SDD: Spec-Driven Development）」です。一言でいうと、「仕様書（Spec）」を中心に据えて開発を進めていくスタイルです。
AIエージェントにコーディングを任せるこれからの時代において、このアプローチにはメリットが3つあります。
メリット1：仕様書とコードの「ズレ」が起きにくい
これまでの開発だと、仕様書は「最初に書いて終わり」になりがちでした。コードを書き換えるたびにドキュメントを更新する余裕がなくて、気づけば仕様書とコードが別物になっている……というのはよくある話かと思います。
Speckitを使った開発では、仕様書そのものがAIエージェントへのインプット（設計図）になります。コードを直すときはまず仕様書を更新し、それをベースにAIが実装を行うので、ドキュメントとコードが常に1対1で同期されたきれいな状態をキープできます。
メリット2：AIの「迷い」や「ハルシネーション」を防ぐ
AIエージェントに「いい感じのTodoアプリ作って」とざっくり指示すると、AIは細かい仕様をどうすべきか迷ったり、勝手に妙な機能を作ってしまったり（ハルシネーション）します。
Markdownなどで構造化された明確な「Spec（仕様書）」を渡してあげることで、AIは「何を作って、どう動かして、どこで完了とするか」を正確に理解でき、迷うことなくタスクを完遂してくれるようになります。
メリット3：人間は「設計・レビュー・方針決定」に集中できる
定型的なコードの作成やAPIの連携といった作業の大部分は、仕様書を読み解いたAIが代行してくれます。
そのおかげで、人間のエンジニアは「そもそもこの仕様でユーザーの課題は解決できるか？」「アーキテクチャの設計方針はこれでいいか？」といった、上流の設計やレビュー、意思決定などのクリエイティブな仕事に時間を使えるようになります。
3. 【実践】Speckitを使った開発の流れ
ここからは、実際にSpeckitを導入して簡単なアプリを開発する流れを紹介します。
開発環境の準備
Pythonのパッケージマネージャー uv が入っていれば、以下のコマンド一発でインストールできます。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
※詳しいセットアップは様々な記事でもいろいろ解説されているので、ぜひ調べてみてください！
Speckitを支えるコマンドたち
Speckitには、プロジェクトのルール決め（憲章作り）から、仕様の書き出し、実装計画、さらにはGitHub Issuesへの変換まで、各フェーズに合わせた便利なスラッシュコマンドが用意されています。
| コマンド | エージェント（プロンプト）の役割 |
|---|---|
/speckit.constitution |
プロジェクトのルール（憲章）を決める |
/speckit.specify |
自然言語のアイデアから仕様書を作って整える |
/speckit.analyze |
仕様に矛盾やツッコミどころがないか分析する |
/speckit.clarify |
仕様のあいまいな部分をQ&A形式でクリアにする |
/speckit.plan |
実装に向けた全体の実装計画を組み立てる |
/speckit.tasks |
計画を細かいタスクに分解する |
/speckit.checklist |
実装漏れを防ぐためのチェックリストを用意する |
/speckit.implement |
コードの自動生成など、実際の開発（実装）を進める |
/speckit.taskstoissues |
作ったタスクを GitHub Issues にドカンと一括変換する |
「こんなにたくさんコマンドがあると、次に何をすればいいか迷いそう……」と感じるかもしれませんが、その心配はいりません。
Speckitと連携しているコーディングエージェント（Claude Codeなど）が、今のフェーズに合わせて「次はこれをやりましょう！」とチャット上でナビゲーションしてくれます。人間はその案内に従って、提案されたコマンドを動かしたり、成果物をレビューしたりするだけで開発を進められます。
具体的な開発サイクル
開発は基本的に、次の3ステップをぐるぐる回していく感じになります。
ステップ1：まずは人間が仕様書（Spec）を書く
最初の主役は人間です。 specs/ フォルダを作って、その中にMarkdown形式で「どんな機能を作りたいか」の仕様書をサクッと書き出します。
# 仕様：Todo管理コンポーネント
## 概要
ユーザーがタスクを追加、完了、削除できるシンプルなTodoリスト。
## 機能要件
- タスクの追加入力フィールドと追加ボタンがあること。
- タスク一覧が表示され、各タスクに「完了」チェックボックスと「削除」ボタンがあること。
- 完了したタスクには打ち消し線が表示されること。
ステップ2：AIエージェントに丸投げして自動実装
仕様書が準備できたら、あとはAIエージェントに任せて /speckit.implement コマンドを実行するだけです。SpeckitがMarkdown仕様書を読み込んで、「この仕様を満たすにはどう実装したらいいのか」を自分で解析してくれます。
AIはいちいち「次どうします？」と聞いてくることなく、ゴールに向かって自律的にファイルを作ったり書き換えたりして一気に進めてくれます。
ステップ3：人間が仕上がりをレビューする
AIの作業が終わったら、人間の出番です。出来上がったコードを見て、ルール通りになっているか、思った通りに動くかをチェックします。
もし「やっぱりこの機能も追加したいな」と思ったり、修正したいところが見つかったりしても、ソースコードを直接いじるのではなく ステップ1に戻って「仕様書（Spec）」の方を書き直します。そしてもう一度AIに実行させます。こうすることで、常にドキュメントが最新の正解であり続ける綺麗な開発サイクルが回るようになります。
4. Playwright MCPでブラウザテストも自動化してみる
AIエージェントにコードの大部分を書いてもらうとなると、「これ、本当に仕様通り動いているのか？」という部分が一番心配になります。そこで活躍するのが自動テストです。
今回は、先ほど作ったアプリに対して、Claude DesktopとPlaywright MCPを連携させて、ブラウザテストをAIに丸投げしてみました。
1. Claude DesktopとMCPを設定する
まずは準備として、Claude Desktopがローカルのファイルをいじったり、Playwrightでブラウザを動かしたりできるように設定します。
設定ファイルの claude_desktop_config.json（「開発者」➔「構成を編集」で開けます）に、こんな感じの記述を追加してあげればOKです。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
]
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"root path of working directory"
]
}
}
}
(※ filesystem のパスには、Claudeに操作を許可する作業ディレクトリのパスを入れてください)
2. AIに「テストケース作っておいて」とお願いする
環境が整ったら、Claudeのチャットを開いて、先ほど作ったTodoアプリのテストケースを作るように指示を出します。今回はこんなプロンプトを投げてみました。
コンポーネントに対するテストケースを作成してください。
テストケースごとにmarkdownファイルを作成してください。
ファイル名は、「{nnn}_どういったテストをするか.md」というふうに作成してください。
nnn：001～999の連番です。
作成したmarkdownファイルは"root path of working directory"（Claudeにアクセスを許可した作業ディレクトリのルートパス）に「テストケース」というフォルダを作成し、配置してください。
各markdownファイルの中身の要件を以下に記載します。
最初にどのようなテストケースについて書くのか見出しを記載します。
以降、各テストケースについてブラウザでどのような操作をするかを記載します。
最初の2ステップは以下のテストケースで共通にしてください。
1.ブラウザを起動し、http://localhost:3000にアクセス
2.画面にフォームが表示されるまで待機
以降は各ケースごとに異なる
プロンプトを送信すると、合計17個のテストケース作ってくれました。
3. ブラウザを自動で動かしてテストを実行・記録してもらう
ローカルサーバー（http://localhost:3000）を立ち上げた状態で、さらにClaudeへ「今作ったテストケースを順番に動かして、結果をまとめて！」と頼みます。
"root path of working directory"（Claudeにアクセスを許可した作業ディレクトリのルートパス）にあるmarkdownについて、テストをしていきます。
また同じ階層に「実施結果.md」というファイルを作成して、ケース実施完了後に、ケース番号 | OK/NG | NGの理由をテーブル形式で記載してください。
すると、ClaudeがPlaywright MCPを叩いて、実際にブラウザ（Chromium）を自律操作しながら画面が仕様通りに動くかをテストし始めました。
（※こちらの動画は5倍速です）
4. バグもしっかり見つけてくれた
試しにわざと「削除ボタンが押せない」状態にして実行させてみたところ、バグを特定し、出力結果の「実施結果.md」でエラーをピンポイントで報告してくれました。
AIが書いたコードを、AI自身がテストしてバグを教えてくれる。このサイクルが回るのには、かなり感動しました。
5. 実際に使って見えてきた課題と解決のヒント
今回、Speckitによる仕様駆動開発と、Claude + Playwright MCPでのテスト自動化を体験してみて、大きな可能性を感じた一方で、実際にチーム開発に導入していくためのリアルな課題も見えてきました。
1. プロジェクトが大きくなったときの仕様書管理
規模が大きくなるとMarkdownファイルが大量になり、人間が全体像を把握しづらくなる懸念があります。
2. テキストだらけによる認知負荷
仕様書が文字だけだと、画面遷移や状態の変化がイメージしにくい部分があります。これについては、仕様書内に Mermaid を埋め込んでフロー図をビジュアル化すると、人間にとってもAIにとっても圧倒的に理解しやすくなりそうです。
3. 「テストのテスト」をどうするか？
AIが仕様を元にテストを作り、AIがそれを実行するため、そもそも「テストケース自体が合っているか」を誰が保証するのかという問題があります。ここは人間がチェックする工程を挟むのが無難そうです。
4. テストの実行速度
ブラウザを目で追う形になるため実行スピードが遅い点が課題でした。
ただ、これに関してはブラウザを画面に表示させずにバックグラウンドで動かす「ヘッドレスモード（仮想ブラウザ）」を使うことで解決できました。さらに、antigravity cli を使い、Claudeが作ったテストケースをベースにしてヘッドレスモードで実行させたところ、驚くほど一瞬でテストが完了するようになりました。実行速度の遅さは、ヘッドレスモードやツールの連携次第でしっかりカバーできそうです！