BLOG

ブログ

SpeckitとPlaywright MCPで体感する、AIエージェント時代の「仕様駆動開発」

  • 書いた人： Ashish Shrestha
  • 最終更新日：
  • 投稿日：

1. はじめに

現在、プロダクト開発を取り巻く環境は大きな変化を遂げています。ClaudeやChatGPTをはじめ、高度なコード生成や自律的なタスク遂行が可能なAIエージェントが次々と登場し、開発の現場へ急速に溶け込みつつあります。単に「人間が指示したコードをAIが補完する」というフェーズを超え、今やAIが自ら考えてコンポーネントを組み立て、プロダクトを形作っていく時代です。

こうしたAIを活用したプロダクト開発の進化をさらに促進するツールとして、約1年前にGitHubからオープンソースとして公開され、今改めて注目を集めているのが「Speckit」です。

Speckitは、「仕様駆動開発（Spec-Driven Development: SDD）」を実践するためのツールキットです。その最大の目的は、人間とAIエージェントがスムーズに連携し、自然言語で書かれた「仕様書」から具体的な実装までを体系的に生成・管理することにあります。

今回は、このSpeckitがもたらす開発手法の変革とメリットについて触れたあと、実際に簡単なアプリケーション開発を行うフロー、そしてPlaywright MCPを用いた画面テストの自動化まで、開発体験をレポートします。

2. 仕様駆動開発（SDD）とSpeckit導入のメリット

Speckitの根底にあるのは、「仕様駆動開発（Spec-Driven Development: SDD）」という思想です。これは、「仕様書（Spec）」を軸に開発を回していく手法です。

AIエージェントに開発を任せる時代において、このアプローチには大きく3つのメリットがあります。

メリット1：仕様書と実装の乖離を防ぐ

従来の開発では、仕様書は「最初に作られて終わり」になりがちで、ソースコードが修正されるたびにドキュメントの更新が置き去りになることが多々ありました。 Speckitを用いたSDDでは、仕様書自体がAIエージェントのインプット（設計図）になります。コードを変更・追加する際はまず仕様書を更新し、それをベースにAIが実装を出力するため、ドキュメントとコードが常に1対1で同期された綺麗な状態を保ち続けることができます。

メリット2：AIエージェントの「迷い」と「ハルシネーション」を減らす

AIエージェントに「いい感じにTodoアプリを作って」と大雑把な指示を出すと、エージェントは細かな仕様の決定に迷い、最悪の場合は予期しない実装（ハルシネーション）を生み出してしまいます。 マークダウンなどで構造化された明確な「Spec」が存在することで、AIは「何を、どんな挙動で、どこまで作ればいいのか」を正確に把握でき、自律的に迷わずタスクを完遂できるようになります。

メリット3：人間は「レビューと方針決定」という本質に集中できる

ルーティン的な定型コードの記述や、複雑なAPIの繋ぎ込みの大部分は、仕様書を理解したAIエージェントが肩代わりしてくれます。 これにより、人間のエンジニアは「この仕様で本当にユーザーの課題を解決できるか？」「アーキテクチャの方針は正しいか？」といった、より上流の設計、レビュー、そして意思決定という本質的なクリエイティブタスクにリソースを集中できるようになります。

3. 【実践】Speckitを使った簡単な開発フロー

ここからは、実際にSpeckitを導入し、シンプルなアプリケーションを開発する際の具体的な環境構築と、一連の開発フローを詳しく解説します。

開発環境の準備

Mac環境であれば、Homebrewを使って非常にシンプルにインストールすることができます。

brew install specify

※詳細な環境構築や設定手順については、他のQiitaやZennの記事でも豊富に解説されているため、ぜひそちらを参考にしてみてください。

Speckitを支える主なコマンド

Speckitでは、開発のフェーズ（憲章作成から仕様策定、実装、Issue管理まで）に合わせて、役割の異なるエージェント（プロンプト）を呼び出すコマンドが用意されています。

コマンドエージェント（プロンプト）の役割
/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：仕様の定義

まずは人間の役割です。specs/ ディレクトリなどを作成し、その中にマークダウン形式で実装したい機能の仕様書を作成します。

# 仕様：Todo管理コンポーネント

## 概要
ユーザーがタスクを追加、完了、削除できるシンプルなTodoリスト。

## 機能要件
- タスクの追加入力フィールドと追加ボタンがあること。
- タスク一覧が表示され、各タスクに「完了」チェックボックスと「削除」ボタンがあること。
- 完了したタスクには打ち消し線が表示されること。

ステップ2：エージェントによるコード生成

仕様書が準備できたら、エージェントのナビゲーションに従って /speckit.implement などのコマンドを実行します。 Speckitは、先ほど作成したマークダウンファイルをインプットとして読み込み、その「仕様」を満たすために必要なソースコードを解析します。

AIエージェントは人間の指示を細かく待つことなく、仕様書に書かれたゴールに向かって自律的にファイルを作成・書き換え、必要な成果物を生成します。

ステップ3：人間によるフィードバック

コードの生成が完了したら、再び人間の出番です。 生成されたコードがプロジェクトのコーディング規約に沿っているか、意図通りの挙動になっているかをレビューします。

もし「やっぱりこういう挙動も追加したい」という差分や修正したい点が発生した場合は、ソースコードを直接いじるのではなく、ステップ1に戻って「仕様書（Spec）」を更新します。 そして再度Speckitを走らせることで、常に仕様書がマスターデータとなる綺麗な開発サイクルが実現します。

4. Playwright MCPを活用したブラウザテストの自動化

AIエージェントにコードを生成・修正してもらう世界線において、最も重要になるのが「本当に仕様通りに動いているか？」を検証する自動テストです 。

今回は、SDDで実装したアプリケーションに対して、Claude DesktopとPlaywright MCPを組み合わせ、自律的に画面テストを行ってもらいます。

1. Claude DesktopとMCPの設定

まず、Claude Desktopからローカルのファイルを操作し、かつPlaywright経由でブラウザを制御できるようにするために、設定ファイル（claude_desktop_config.json）の「開発者」メニューから「構成を編集」をクリックし、以下の設定を記述・追加します 。

{
  "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:8501にアクセス
2.画面にフォームが表示されるまで待機
以降は各ケースごとに異なる

3. 生成された全17個のテストケース

この指示により、AIはアプリケーションの仕様を汲み取り、正常系からかなりエッジなケースまでを含んだ全17個のテストケース（Markdownファイル）を瞬時に自律生成してくれました ！

生成されたテストケースのリストは以下の通りです 。

4. ブラウザを自動操作させてテストを実行・記録する

続いて、ローカルサーバー（http://localhost:3000）を起動した状態で、Claudeに「生成したテストケースを順番に実行し、その結果を記録して」と頼みます。

"root path of working directory"（Claudeにアクセスを許可した作業ディレクトリのルートパス）にあるmarkdownについて、
テストをしていきます。

また同じ階層に「実施結果.md」というファイルを作成して、ケース実施完了後に、ケース番号 | OK/NG | NGの理由をテーブル形式で記載しておいてほしいです。

指示を出すと、ClaudeはPlaywright MCPのブラウザ操作ツールをバックグラウンドで叩き、実際にChromiumブラウザを自律的に操作しながら、画面が仕様通りに動くかを一つずつ検証し始めます。

（５倍速です）

5. バグの検出

わざと削除ボタンを押せなくし、出力された「実施結果.md」を確認したところ、ほとんどのケースが OKで通過する中、バグを完璧にピンポイントで検出してくれました。

AIが実装したものを、AIが自動でブラウザテストにかけ、不具合をレポートしてくれる。この一連のサイクルをある程度高い精度で回ることが実証できました。

5.まとめと今後の課題

今回、Speckitによる「仕様駆動開発」と、Claude Code + Playwright MCPによる「画面テスト自動化」を実際に組み合わせて開発を行ってみて、大きな可能性を実感すると同時に、今後の運用に向けたリアルな課題や懸念点も見えてきました 。

1. プロジェクトが大きくなった時のドキュメント管理

プロジェクトが大規模になるにつれて、仕様を記述するMarkdownファイルの数が膨大になり、人間が全体像を管理・把握しにくくなる懸念があります。

2. 文章の羅列による認知負荷

Markdownは人間が読める形式ではあるものの、すべてが文字の羅列であるため、複雑なステート遷移や画面遷移が直感的に理解しづらい側面があります 。これに関しては、仕様書内に Mermaidを埋め込んでフロー図などをビジュアライズできるようにすると、人間にとってもさらに分かりやすくなり、なお良くなると感じました 。

3. テスト自体の妥当性確認の難しさ

AIがテストケースを作成し、AIがテストを実行するため、そもそも「そのテストケース自体が100%正しいのか」を人間がどこかで担保・検証する仕組みが必要になります。

4. 人間の常駐と実行速度

画面テスト実行中、たまに「Yes」の承認を押さなければ進まない場面があり、現状では人間が画面の前に常駐して見守る必要がある点や、ブラウザの自律操作によるテスト実行のスピード遅さは、今後の設定やツールの成熟によって改善していきたいポイントだと感じました。




➜
前の記事へ
記事一覧へ
➜