Qiita 初投稿です。
1. なんでこんなことを試したのか
たまーーーに Twitter X を見ると、タイムラインに AI 系のツイートが流れてきて、この先自分の仕事がどうなっていくのか不安になったので、これからの生き方を考えるうえで、AI の現在地がどんなものかを知るために、とりあえずアプリを作ってみた。
2. そもそも Claude とは
特に説明する必要もないですが、生成AIです。
ChatGPT のローカルファイルをいじれる版です。
Claude には、 Chat / Cowork / Code の 3 タイプがあります。
使うのは Code です。

ちなみに、 Claude のアプリは使わず、VSコードで使います。
これは、VSコードから使った方が圧倒的に性能が良かったからです。
ただ、これは今思うと、Claude.md の設定が洗練されてきた頃に乗り換えただけな気もします。(あと Claude の性能が下がってたってニュースもあったような・・・?)
プランは Max(x5) です。
これで足りないくらいのトークンを使おうとすると、生成量が膨大になってレビューが疎かになります・・・ ました・・・
3. DocDD (ドキュメント駆動開発) とは
「画面の要件・データ構造・APIの仕様などを先にドキュメントにまとめ、それらをもとに AI に実装させよう」 という開発スタイルです。

AIはプロンプトの質で生成結果が大きく変わってしまうので、その揺らぎを極力抑える仕組みとして、ドキュメント(仕様書や設計書)をベースとした生成をやっていくことになるだろうなと思ってます。
4. で、何を作ったの
「さあやってみよう」って時に困るのが、特に作りたいものなどないということ。
とりあえず、情報処理安全確保支援士の勉強をしてたので、午後の筆記対策で使えそうなアプリを作りました。機能は以下。
5. インフラ
- ホスティング: CloudFlare
- バックエンド: Supabase (Edge Functions)
- DB (Postgres): Supabase (DataBase)
- アカウント管理: Supabase (Authentication)
- クレカ決済: PayJP
裏側は Supabase で統一。
無料なら何でもよかったのですが、せっかくなら使ったことないやつを使おうということで、 Supabase を採用。
6. DocDDやってみた (本題)
結論、趣味でやる分には十分すぎる物ができた。
日数
- Claude.md (Claude の挙動のルール) の醸成 : 1か月
- このアプリ作り: 全部で3日くらい
開発の流れ
基本的に、Claude と話しながら、先に仕様を詰めていきます。
画面はモックを作りながら調整していきます。
ドキュメントが定まってきたら実装に入りますが、仕様決め漏れなどがあれば、仕様決めに戻ってから実装します。
この辺のルールは、 Claude.md に設定しておけば、 Claude がガイドしてくれます。
リポジトリ構成
Qiita とかで見た構成を真似つつ、多少アレンジ。
長くなるの一部割愛しますが、docs は全部で15フォルダくらいある。
リポジトリルート
├ Claude.md
├ docs
│ ├ mapping.md // マッピング表
│ ├ mocks // モック
│ ├ screen // 画面要件
│ ├ backend // バックエンドAPI仕様
│ ├ tests // テスト仕様書
│ ├ ...
│ └ bug_histories // バグの履歴
├ src // フロント
├ back // バックエンド
└ ...
Claude.md
Claude の挙動のルールを決めるファイルです。
ここに、「必ず 「ドキュメントの作成/修正」 → 「実装」 の順で作業する」的なことを記載します。
あとは、ドキュメントの書き方や実装時の制約などを書きます。
あんまり大量に書かない方がいいです。普通に無視してきます。
とはいえ、250行を超えてしまった。ここは、要改善かなと思う。
内容を載せようと思ったのですが、長いので割愛します。
というか、他の人がもっと良いやつ公開してると思う。
品質
複雑なアプリではないこともあり、アカウント認証やクレカのテスト決済も特に問題なく動作しており、割と満足のいく出来だった。
品質が問題になったという記事を先に読んでいたので、テストも想定したドキュメントにしていたからかもしれない。
あんまり趣味レベルでやる人は居ないと思うけど、ZAP で DAST も試してみた。
Security by Design に則って、最初からセキュリティを意識していたから、ヘッダーの問題はいくつかあったものの、特に大きな問題はなさそうだった。
まあアプリの規模にもよるんだろうけど。

とはいえ、業務であれば、この辺は絶対専門家にやってもらうべき。
なので趣味。
7. 失敗とか反省
AIも人間と同じ
AIもサボるし、忘れる。
例えば、Claude が必ず読むファイルの Claude.md を細かく書きすぎると、普通に読み飛ばす。
仕様書を全ファイル全行毎回読めと命令すると、先に読んだことを忘れる。(特に Cowork で「会話の圧縮」が発生すると、以前の情報が一部欠落する)
この辺はかなり迷走した。
対策としては、工程ごとにファイルを分けてClaude.md では参照だけにするとか、参照先を指定できるようにID振りするとかして、関係する部分のみを読めるようにする。
トークン浪費問題
↑の問題に関連して発生した。
AI が忘れるから、忘れても良いように毎度仕様書を読み込ませていたら、トークン消費が爆速になった。しかも読ませすぎて忘れる。
対策は↑と同じ。
貧乏性問題
トークンのリセットタイミングが近づいてくると、マルチエージェントを使って生成速度を上げたりして、トークンを使い切ろうとする貧乏性が発生した。
結果、レビューが疎かになって仕様もコードも破綻させてしまった。
仕様と設計が問題なければ、コードも問題ないことが多いので、少なくとも上流のドキュメントはちゃんとレビューしないとなと思った。
根本的な対策は、、、お金を稼ごう。。。
まとめ
今回は個人での開発ですが、仕様の提案も AI がガンガンしてきて、自分は本当に判断するだけになっていた。
今後どんどん AI を使った開発が増えてくると予想される中、どうすればこの先生き残れるのか・・・
悩みの解消のためにやったのに、より悩みが深まりましたとさ。 めでたしめでたし。




