Claude Codeでスマホアプリを個人開発して、失敗した設計と、AIに任せて起きた事故をお伝えさせていただきます。
筆者はSIerでエンジニアを約7年、SAPコンサルタントを約3年経験し、現在は生成AI・LLMを使ったアプリケーション開発に携わるAI開発エンジニアです。本業とは別の個人開発で、テニスの練習記録アプリをClaude Codeで作り、着手から21日でApp Storeに公開しました。
公開までは順調に見えても、途中では何度も設計をやり直しています。この記事では、作り直した設計5つと、Claude Codeの報告を信じて起きた事故6つを、数字と作り直した方法つきでまとめます。
失敗と作り直しの一覧
詳細は後ほど説明しますが、作り直した設計5つのまとめは以下となります。
| 失敗 | 作り直した後 |
|---|---|
| データ変換の書き方で、アプリのデータベースが二度と開けなくなった | 「起動後の補完」と「読み出し時の変換」の2段構えにした |
| 作業記録ファイルが14日で約2MBに膨らんだ | 3層に分けて2,030KB→61KBにした |
| 何でも課題番号を振り、1日50件採番していた | 優先度「低」は番号を振らない。残っている課題は168件→67件 |
| 公開サーバーのデプロイ回数の上限を使い切り、24時間止まった | 記録ファイルだけの変更ではビルドしない設定にした |
| WindowsとMacの2台で、同じ番号を二重に振った | 着手を宣言するファイルを置き、番号は取り込む直前に振る |
- 5つのうち4つは、コードではなく「作業の記録と管理」の設計の失敗だった
- 事故6つのうち2つは、AIの報告や読んだ記録が実際の状態と食い違っていたことから起きた
- 早い段階で静的な書き出しにしていた判断は、後で大きく効いた
アプリの内容や開発期間・体制・費用の全体は、別の記事にまとめています。
▼Claude Codeでスマホアプリを個人開発した記録はこちら▼
失敗1：データ変換の書き方で、アプリのデータベースが二度と開けなくなった
このアプリはサーバーを持たず、記録はすべて端末の中に保存しています。保存先はIndexedDBという、ブラウザやアプリの中にデータを保存する仕組みです。
保存するデータの形を変えるとき、IndexedDBではデータベースの版を上げ、その更新処理（upgrade）の中で古いデータを新しい形に変換できます。筆者のアプリでは、この更新処理の中で、awaitで別の処理を待ちながらデータを変換していました。その結果、そのURL（オリジン）ではデータベースが二度と開けなくなりました。
作り直した後は、データの変換を更新処理から外し、次の2段構えにしています。
- 起動後の補完：アプリが起動してから、古い形のデータを新しい形に書き直す
- 読み出し時の変換：まだ書き直されていないデータも、読み出すときに新しい形にそろえて扱う
データが端末の中にしかないアプリでは、データベースが開けなくなることは、そのまま記録が見られなくなることにつながります。データの形を変える処理は、Claude Codeが書いたものでも、どこで実行されるのかを人が確認しておくべきだったと思います。
失敗2：作業記録ファイルが14日で2MBに膨らんだ
筆者は、課題や作業の状況を1つのファイル（以下、台帳）に記録し、Claude Codeに読ませながら開発を進めていました。この台帳には、古い記録を別のファイルに移す仕組みがありませんでした。
課題を管理するファイルは、14日で約2MB（10倍）に膨らみました。そこで、台帳を次の3層に分けています。
- 生きている一覧：いま対応中・未着手の課題だけを1行ずつ並べる
- 詳細：課題ごとの経緯や調査結果
- アーカイブ：終わった課題
分けた結果、課題を管理するファイルは2,030KBから61KBになりました。AIに読ませる記録は、作った時点で「いつ、どこへ片付けるか」まで決めておくのがおすすめです。
失敗3：何でも課題番号を振り、1日50件採番していた
気付いたことを何でも課題として登録し、番号を振っていた結果、1日に50件の番号を採番する日がありました。残っている課題は168件まで増え、そのうち6割が優先度「低」の未着手でした。
作り直した後は、優先度「低」の気付きには番号を振らず、別のファイルにメモとして残すだけにしています。これで、残っている課題は168件から67件に減りました。
AIは指示すればいくらでも課題を登録してくれますが、登録した数だけ一覧は読みにくくなります。「番号を振るのは、対応すると決めたものだけ」と線を引いたのがよかったと思います。
失敗4：公開サーバーのデプロイ回数の上限を使い切り、24時間止まった
Web版の公開にはVercelを無料プランで使っており、GitHubに変更を送る（push）たびに、自動でビルドとデプロイ（公開サーバーへの反映）が走る設定にしていました。
Vercelの公式ドキュメントでは、無料のHobbyプランで作れるデプロイは1日100回までです。筆者は、アプリのコードではなく台帳を更新するだけのpushでもデプロイを走らせていたため、この枠を使い切りました。その結果、変更を取り込む作業（プルリクエストのマージ）が24時間止まりました。
作り直した後は、記録ファイルを置くフォルダだけの変更ではビルドしない設定にしています。AIに記録を細かく残させるほど、pushの回数は増えます。無料枠のあるサービスを使う場合は、上限の回数を先に確認しておきましょう。
失敗5：2台並行で同じ番号を二重に振った
開発はWindowsとMacの2台で並行して進めていました（MacはiPhone向けの確認と提出の担当です）。それぞれの端末で課題に番号を振った結果、同じ番号が両方で採番されることが起きました。
作り直した後は、次の2つを決めています。
- どちらの端末で何に着手したかを1つのファイルで宣言してから作業する
- 課題の番号は、作業中ではなくプルリクエストを出す直前に振る
Nico5つのうち4つは、コードではなく記録や管理の決め事の失敗でした。AIに任せる量が多いほど、記録の片付け方や番号の振り方は先に決めておくのがおすすめです。
Claude Codeに任せて起きた事故6つ
設計の失敗とは別に、Claude Codeの報告や作業をそのまま受け取ったことで起きた事故が6つあります。
シミュレーターでの確認を「実機で確認」と報告された
Mac上でiPhoneの画面を再現するiOS Simulatorで確認した結果を、Claude Codeは「実機で確認した」と報告しました。そのため、ある不具合が3日間「直った」扱いになっていました。
それ以後は、「実機」と「Simulator」を用語の定義として分け、報告ではどちらで確認したかを書き分けるようにしています。
1日古い記録を読み、終わった作業を最優先にした
Claude Codeが、1日前の状態のままの台帳（その作業が「プルリクエスト待ち」と書かれたまま）を読み、すでに終わっている作業を最優先として指名しました。記録が古いと、AIの判断も古くなります。
ほかの4件
| 事故 | 起きたこと |
|---|---|
| 検証の見逃し | 記録ファイルを置くフォルダだけの変更ではビルドが走らず、自動チェックが失敗していることを見逃した |
| 記録の衝突を片側で丸取り | 2台の台帳が衝突したとき、片方の内容をそのまま採用したため、閉じたはずの課題が復活した |
| 起動しない開発環境 | 部品のフォルダ（node_modules）をWindowsのジャンクション（フォルダの別名）で共有したところ、自動チェックは通るのに開発用サーバーだけが起動しなかった |
| ダミーのリンク | 紹介ページのApp Storeへのリンクがダミーのまま17日間放置され、週次リリースの初回で気付いた |
ダミーのリンクに気付いた経緯や、App Storeで公開するまでの手続きは、別の記事で詳しく紹介しています。
▼Claude Codeで作ったアプリをApp Storeで公開した手続きはこちら▼
うまくいった判断：早い段階で静的書き出しにしていた
失敗ばかりではなく、後から効いた判断もあります。アプリはNext.jsで作っており、早い段階で静的書き出し（サーバーなしで動くHTMLやJavaScriptのファイルとして出力する設定）に切り替えていました。
そのおかげで、WebアプリをCapacitorでiPhoneアプリにするとき、書き出したファイルをアプリの中に載せるだけで済み、技術的な障壁はほとんどありませんでした。Web版の利用者を切らずにiPhone版を出せたのも、この判断があったからです。
失敗から決めたルール
ここまでの失敗と事故を受けて、Claude Codeと開発を進めるときのルールを決めました。同じようにAIで個人開発をする方にも、そのまま使えると思います。
| ルール | きっかけ |
|---|---|
| 「実機」と「Simulator」など、紛らわしい用語は定義を分ける | Simulatorでの確認が「実機で確認」と報告された |
| 作業に着手する前に、どの端末で何をするかを宣言する | 2台並行で同じ番号を二重に振った |
| 課題の番号はプルリクエストの直前に振る | 同上 |
| 優先度「低」には番号を振らない | 1日50件採番し、一覧が読めなくなった |
| 記録は「生きている一覧・詳細・アーカイブ」の3層に分ける | 作業記録ファイルが14日で2MBに膨らんだ |
| 記録ファイルだけの変更ではビルドしない | デプロイ回数の上限を使い切った |
さいごに
Claude Codeでスマホアプリを個人開発して、作り直した設計5つと、AIに任せて起きた事故6つをお伝えしました。
要点を1つにまとめると、AIが書くコードより先に、AIが読む記録と報告の決め事を設計するです。
今回の失敗や事故の多くは、「Simulatorと実機の違い」「データベースの更新処理」「ビルドとデプロイの仕組み」を知っていれば、もっと早く気付けたものだったと思います。AIに任せる時代でも、こうした基礎を知っているかどうかで、AIの報告を見抜けるかが変わると思います。基礎から体系的に学びたい方は、プログラミングスクールを比較した記事も参考にしてみてください。
最後までお読みいただきありがとうございました。
▼プログラミングスクールの比較はこちら▼
※本記事の情報は2026年9月時点のものです。各サービスの仕様・上限は変更される場合がありますので、最新情報は公式サイトでご確認ください。
コメント