SpecKit × CursorでWebサービスをAIだけで作ってみた実体験

AI AI
AI

〜 Handy Dev Tools はこうして生まれました 〜

はじめに

最近は「AIでコードを書く」こと自体は珍しくなくなりました。

しかし、

  • 要件定義
  • 仕様設計
  • ディレクトリ構成
  • 実装
  • デプロイ設定

までを 人がほぼ設計せず、AI主導で進める 事例は、まだ多くありません。

この記事では、SpecKit + Cursor を使い、コードを完全にAIのみで生成して作成したWebサービス「Handy Dev Tools」 の開発体験を紹介します。

Handy Dev Tools - ブラウザ完結のエンジニア向けツール集
ブラウザ完結のエンジニア向けツール集。アカウント登録不要、全て無料、100%ブラウザで処理。現役エンジニアが実際に必要と感じた機能を厳選して実装しています。
handy-dev.tools

今回作成したサービス概要

  • サイト名：Handy Dev Tools
  • 内容：開発者向けの小さな便利ツール集
  • フロントエンド：React + Material UI
  • インフラ：
    • CloudFront + S3（手動構築）
  • コード作成：
    • Cursor + SpecKit
    • 実装コードはほぼ全てAIで生成
  • ローカル環境：
    • Dockerのみ使用
    • ローカルに npm / php はインストールしない

なぜ SpecKit を使ったのか？

理由は仕様駆動開発（SDD）を知って、使ってみたくなったから。

また、普段の業務でも活用できるかの調査も兼ねています。

SpecKitは、

  • 憲法（Constitution）
  • 仕様（Specification）
  • 実装（Implement）

を明確に分けることで、

仕様駆動開発（SDD）をAI時代向けに最適化したツールです。

Step1：最初のプロンプト（プロジェクト初期化）

まずは、プロジェクトの作成です。

git initをしただけの空の状態から初めて、以下のプロンプトを記載しました。

最新のReactにてプロジェクトを作成したいです。
ブラウザに表示できるところまで初期セットアップをお願いします。
詳細は以下の通り。

# 環境構築条件
- Dockerを利用して環境を構築
- ローカル側にはphpやnpmなどは入れません
  - 実行時はコンテナ内に入ってから実行します
- AWS_ACCESS_KEY_IDなどの環境変数は.env系に入れて欲しいです。

# 主なディレクトリ構成
- /: docker-compose.ymlを配置
- /docker: Dockerfileやiniファイル系などDocker環境構築に必要なファイルを配置
- /.cursor/rules: cursorのmdcファイルを配置
- /.specify: Speckitのものを配置

# 作成するもの
React + MaterialUIにてサイトを作成します
本番環境はCloudFront + S3で構築します

作成してもらいましたが、さすがに一発で起動はできませんでした。

ですが、数回エラーを渡して直してもらったら動くようになりました。

ポイント

  • ディレクトリ構成まで最初に固定
    • ルートディレクトリでdocker compose up -dで起動させたかったので指定
    • それ以外に作成されそうなアプリとは関係ないものの場所を指定
  • 後から「ここに置いてほしい」は言わない
  • AIが迷わない設計を先に与える

Step2：CloudFront + S3 デプロイ設定

フロントエンドの構成ができた後、デプロイ設定のみを追加で依頼しました。

以下の情報でCloudFront + S3へのデプロイ設定をお願いします
CloudFrontのディストリビューションIDは`********`
S3のバケット名は`********`

SpecKitを早く使いたかったので AWSリソース自体は手動作成 しています。

Step3：SpecKit 憲法（Constitution）の作成

ここから SpecKit の出番です。SpecKitのインストールは既に済ませてあります。

/speckit.constitution 
日本語でお願いします。今後作成する仕様なども全て日本語でお願いします。
作成するサイトは多言語化対応を必須とします。言語は日本語と英語です。

ここで決めたこと

  • 仕様・設計は すべて日本語（英語を読むのは時間がかかり、細かいニュアンスもわからないので）
  • 多言語対応は 必須要件
  • 後続の仕様は、この憲法に従う

Step4：TOPページの仕様作成（Specification）

次に、コードを書かせる前に仕様を書くのがSpecKit流です。

/speckit.specify 
TOPページを作成したいです
サイト名はHandy Dev Tools
サイト名は.envに記載したい（開発環境と本番環境で名称を変更したい）
ページの基本構成は2ペイン
左側にメニューを表示し、ツール一覧を表示
右側にツール一覧をカードで表示
右側の一番上には検索欄があり、ツールを検索可能（具体的な実装は後ほどするため、検索欄のみ配置で良い）
検索欄の右側に言語選択をできるようにしたい（日本語+英語。デフォルトは日本語）
ツールはこの後に作成するため、リストは空でよい

ここでは 実装方法は一切指定していません。

  • どう書くか → AIに任せる
  • 何を満たすか → 人が決める

仕様が曖昧で実装できなさそうな所は、選択肢で聞いてきてくれます。

Step5：実装とエラー修正は「対話」で

上記の後、plan -> tasks と実行し、各種ドキュメントの確認もします。

そして、最後のimplement 実行後は、

  • ビルドエラー
  • ESLintエラー
  • 型エラー

が 普通に出ます。これはずっと変わりませんでした。

ここでやったことはシンプルで、以下のプロンプトを使いました。

エラーが出たので修正してください

ESLintに従って修正してください

人がやったこと

  • エラー内容を読む
  • それを そのままコピペでAIに渡す

人がやらなかったこと

  • 自分でコードを書く
  • ロジックを考える

結果として、最終的にエラーゼロの状態までAIのみで到達しました。

実際にやってみて感じたメリット

1. 仕様がブレない

  • 仕様を先に作成するので、出来上がってからコレじゃないがほとんどない
  • SpecKitの憲法が効いている

2. 実装スピードが異常に速い

  • TOPページの骨組みは数分
  • UIのたたきはほぼ一発
  • 1ヶ月で50個のツールを作成できた

3. 文言もある程度考えてくれる

  • 面倒な機能の説明なども書いてくれる
  • 多言語化が楽

3. 「人は判断、AIは作業」に集中できる

  • 人：何を作るか
  • AI：どう作るか

正直に感じたデメリット

  • 「言語化能力」が必要
    • 小さな違和感や、勘違い実装があったりする
  • デザインの指示が難しい
  • 共通の設定や変数の規則があまりない
    • 多言語化のキー名が重複したりしていた
    • キーは異なるが、訳が同一のものが生成される（’戻る’ => ‘戻る’, ‘Back’ => ‘戻る’ など）

まとめ：AI時代の開発スタイルが見えてきた

今回の Handy Dev Tools 開発を通して、

  • コードを書く量は激減
  • 設計の重要性は爆増

しました。

SpecKit × Cursor は、

  • 個人開発
  • プロトタイプ
  • 小〜中規模ツール

に 非常に相性が良い と感じています。

「次はどんな仕様を書くか」

ここに集中できるのが、この開発スタイル最大の価値だと思います。

スポンサーリンク
タイトルとURLをコピーしました