〜 Handy Dev Tools はこうして生まれました 〜
はじめに
最近は「AIでコードを書く」こと自体は珍しくなくなりました。
しかし、以下全てを人がほぼ設計せず、AI主導で進める 事例は、まだ多くありません。
- 要件定義
- 仕様設計
- ディレクトリ構成
- 実装
- デプロイ設定
この記事では、SpecKit + Cursor を使い、コードを完全にAIのみで生成して作成したWebサービス「Handy Dev Tools」 の開発体験を紹介します。

今回作成したサービス概要
- サイト名:Handy Dev Tools
- 内容:開発者向けの小さな便利ツール集
- フロントエンド:React + Material UI
- インフラ(手動構築):
- CloudFront + S3
- ドメイン取得
- Route53設定
- コード作成:
- Cursor + SpecKit
- 実装コードはほぼ全てAIで生成
- ローカル環境:
- Dockerのみ使用
- ローカルに npm / php はインストールしない
なぜ SpecKit を使ったのか?
理由は仕様駆動開発(SDD)を知って、使ってみたくなったから。
また、普段の業務でも活用できるかの調査も兼ねています。
SpecKitは、以下を明確に分けることで、仕様駆動開発(SDD)をAI時代向けに最適化したツールです。
- 憲法(Constitution)
- 仕様(Specification)
- 実装(Implement)
Step1:最初のプロンプト(プロジェクト初期化)
まずは、プロジェクトの作成です。
最初にGitHubでリポジトリを作成して、git init、README.mdをコミット&プッシュしただけの空の状態から初めました。
この状態で、以下のプロンプトを発行します。
最新の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で構築します
ここからSpecKitで作成しても良かったのですが、SpecKitの利用はまだ初回という事もあり、アプリケーション自体の製造に使うのみの留める事としました。
数回エラーを直してもらって動くようにしました。
ここまでおよそ10分程度です。
ポイント
- ディレクトリ構成まで最初に固定
- ルートディレクトリで
docker compose up -dで起動させたかったのでディレクトリを指定 - それ以外に作成されそうなアプリケーションとは関係ないもののディレクトリを指定
- ルートディレクトリで
- 後からディレクトリ構成などをいじるとカオスになるので、先にイメージしてAIが迷わない設計を先に与えます
Step2:CloudFront + S3 デプロイ設定
フロントエンドの構成ができた後、デプロイ設定を追加で依頼しました。
以下の情報でCloudFront + S3へのデプロイ設定をお願いします
CloudFrontのディストリビューションIDは`********`
S3のバケット名は`********`
注)SpecKitを早く使いたかったことや、インフラ側はSpecKitの対象外としていたので AWSリソース・ドメイン取得などは、あらかじめ手動作成 しています。
これでnpm run deployを実行すると、本番に反映されるようになりました。
Step3:SpecKit 憲法(Constitution)の作成
ここから SpecKit の出番です。SpecKitのインストールは既に済ませてあります。手順はSpecKitで始める仕様駆動開発(SDD)入門を参照してみてください。
今後仕様を何度も作成することになると思いますが、それらに共通する事をここに記載します。
/speckit.constitution
日本語でお願いします。今後作成する仕様なども全て日本語でお願いします。
作成するサイトは多言語化対応を必須とします。言語は日本語と英語です。
ここで決めたこと
- 仕様・設計は すべて日本語(英語を読むのは時間がかかり、細かいニュアンスもわからないので)
- 多言語対応は 必須要件
- 後続の仕様は、この憲法に従う
上記以外にもあると思いますが、この時点では思いつかなかったので、思いついた時点で追加していきます。
Step4:TOPページの仕様作成(Specification)
前準備は済みましたので、いよいよSpecKitの本当の出番です。
まずはTOPページと大まかなレイアウトを作成してもらうようにします。
テーマの選択や最初に公開するツールも含めるなど色々盛り込んでも良いのですが、出来上がった仕様や設計などを確認もしなければならないことを考えると、適度なボリュームで分割するのが良いと思います。
以下のプロンプトを発行しました。
/speckit.specify
TOPページを作成したいです
サイト名はHandy Dev Tools
サイト名は.envに記載したい(開発環境と本番環境で名称を変更したい)
ページの基本構成は2ペイン
左側にメニューを表示し、ツール一覧を表示
右側にツール一覧をカード形式で表示
右側の一番上には検索欄があり、ツールを検索可能(具体的な実装は後ほどするため、検索欄のみ配置で良い)
検索欄の右側に言語選択をできるようにしたい(日本語+英語。デフォルトは日本語)
ツールはこの後に作成するため、リストは空でよい
なるべく箇条書きのように短文で、やりたいことを羅列してあげるだけで良いです。
ここでは 実装方法は一切指定していません。
- どう書くか → AIに任せる
- 何を満たすか → 人が決める
仕様が曖昧で実装できなさそうな所は、選択肢で聞いてきてくれます。
ですが、なるべくそうならなく、AIが勘違いしないように記述していきます。
上記の後、spec.mdが作成されるので、以下を主に確認しました。
- 勘違いしていないか
- 機能が不足していないか
- 難しく考えておかしな機能を作っていないか
- 伝え忘れていることがないか
Step5:実装とエラー修正は「対話」で
次にplan -> tasks と実行し、各種ドキュメントの確認もします。
そして、最後にimplement を実行してもらいます。
ここでコーディングはAIに任せるので、ほぼ見ません。
作成後、以下のような色々なエラーが 普通に出ます。これはずっと変わりませんでした。
- ビルドエラー
- ESLintエラー
- 型エラー
AIもバグを出すんだから、人間のコーディングなんてもっとバグが出るものです。
このエラーの修正はシンプルに、以下のプロンプトを使いエラーをコピペして直してもらいました。
エラーが出たので修正してください
ESLintに従って修正してください
結果として、最終的にエラーゼロの状態までAIのみで到達しました。
実際にやってみて感じたメリット
1. 仕様がブレない
- 仕様を先に作成するので、出来上がってからコレじゃないがほとんどない
- SpecKitの憲法をしっかりしておくと、specifyで与える仕様が少なくてもしっかり作ってくれる
2. 実装スピードが異常に速い
- TOPページの骨組みは数分
- UIのたたきはほぼ一発
- 1ヶ月で50個のツールを作成できた
3. 文言もある程度考えてくれる
- 面倒な機能の説明なども書いてくれる
- 多言語化が楽
4. 「人は判断、AIは作業」に集中できる
人間は「何を作るか」を考えればよく、AIはそれを「どう作るか」を担当するので、作りたいものに集中できる
正直に感じたデメリット
- 「言語化能力」が必要
- 小さな違和感や、勘違い実装があったりする
- デザインの指示が難しい
- 共通の設定や変数の規則があまりない
- 多言語化のキー名が重複したりしていた
- キーは異なるが、訳が同一のものが生成される(’戻る’ => ‘戻る’, ‘Back’ => ‘戻る’ など)
まとめ:AI時代の開発スタイルが見えてきた
今回の Handy Dev Tools 開発を通して、
- コードを書く量は激減
- 設計の重要性は爆増
しました。
SpecKit × Cursor は、
- 個人開発
- プロトタイプ
- 小〜中規模ツール
に 非常に相性が良い と感じています。
「次はどんな仕様を書くか」
ここに集中できるのが、この開発スタイル最大の価値だと思います。

