AIツールを使えば、エンジニアでなくてもWebアプリを実装できました。ただし、ローカルで動くまでの2時間と、本番公開までの6時間では、全く別の問題が起きました。この失敗の多くは、技術の難しさではなく設計の順序ミスとして整理できます。この記録では、何をどの順番でやったか、どこで判断を誤ったかを整理しています。
この記録を残す理由
ローカルで動くことと、本番で動くことは別の問題です。この前提を最初に持っているかどうかで、詰まる場所と時間が大きく変わります。
AIを使えばアプリが作れる、という話はよく聞くようになりました。ただ、実際に「非エンジニアが」「どのくらいの時間で」「どんな判断ミスをしたか」を正直に書いた記録はあまり見かけません。
私は理学療法士として病院に勤務しながら、副業としてフレイル予防メディア「jogtime.jp」を運営しています。コードを書いた経験はほぼゼロです。
そんな私が、Claude（Anthropic）とChatGPTを使いながら、30日フレイル予防アプリ「Rehapro」を実装しました。この記事は、その実践の記録ではなく、同じ状況に置かれた人が同じ判断ができるようにするための記録です。
作ったもの：30日フレイル予防アプリ「Rehapro」
12問の質問に答えると、AIがユーザータイプを判定して30日間の行動プランを生成するWebアプリです。毎日の外出・歩行・会話をタップで記録し、スコアで見える化します。
使った技術スタックはこうです。
- フロントエンド：Next.js 16（TypeScript + Tailwind CSS）
- データベース：Supabase（PostgreSQL）
- AI処理：Dify API（ワークフローを3本組んだ）
- デプロイ：Cloudflare Workers
これらを選んだのはClaudeが提案したからです。私には選択基準がなかったので、「非エンジニアでも扱いやすいか」という観点でClaudeに絞ってもらいました。
実際の数値（ローカル完成まで）
ローカル環境でアプリが動くまでの時間：約2時間
この2時間でできたこと：
- Supabaseのテーブル設計（4テーブル）
- 12問の質問画面
- Difyフロー①（初回登録：ユーザータイプ判定＋Week1プラン生成）の設計と接続
- ダッシュボード画面（今日の記録・スコア・状態表示）
- 日次記録画面（外出・歩行時間・会話をタップで記録）
数値の構造分析として書いておくと、2時間で完成した理由は「Claudeがファイルを直接読み書きできる」という点にあります。処理の流れが「指示→ファイル生成→確認」という単純な構造だったため、私が判断を介入する場面が少なく済みました。
「2時間で完成した」のは処理構造が単純だったためです。 外部APIとの連携が複数になると設計の複雑度が上がり、時間は比例して増えます。「AIがあれば何でも速い」という解釈は危険です。
判断基準として残しておくなら、こうなります。
依存関係（API・DB・認証）が閉じた状態で動いているなら次に進めます。外部への接続が未確認のまま次のステップに進むと、問題の切り分けが難しくなります。
失敗の構造（何がずれていたか）
今回の失敗を「現象」ではなく「構造」で整理すると、3つに分類できます。
構造ミス①：AI選択の設計がなかった
複数のAI（ClaudeとChatGPT）を並行して使っていたにもかかわらず、「どちらを主軸にするか」を最初に決めていませんでした。情報の受け取り方に設計がなかったため、矛盾する情報を同時に受け取ることになりました。
構造として言うと「判断の一元化ができていなかった」です。
構造ミス②：確認の順序が逆だった
AIから提案を受けるたびに、確認なく実行していた時期がありました。「表示がおかしい」と感じてから確認を取るのではなく、実行前に確認を挟むという習慣がなかったことが複数の修正コストを生みました。
構造として言うと「実行前の検証ステップが設計されていなかった」です。
構造ミス③：ローカルとデプロイの問題を同一視していた
「ローカルで動いているのにデプロイで動かない」という状況を、「何かが壊れた」と解釈していました。実際には、ローカルとデプロイ環境の違いを最初から想定した設計が必要でした。
構造として言うと「環境差異の認識が設計に組み込まれていなかった」です。
判断の分岐点（どこで誤り、正しい判断は何か）
分岐点①：どのAIを主軸にするか
誤った判断：両方から情報を受け取り、合わせながら進める
正しい判断：主AIを1つ決め、他方は「第三者確認」に限定する
なぜ誤ったか：ClaudeにはセッションのクレジットLimit（週間制限）があったため、「節約のためにChatGPTも使おう」という判断をしました。コスト最適化の意図が、情報の一貫性を壊す結果になりました。
分岐点②：提案をそのまま実行するか、確認を挟むか
誤った判断：AIの提案をそのまま実行する
正しい判断：表示や動作に違和感があれば、実行前に確認を取る
なぜ誤ったか：「AIが言うなら正しいはず」という前提で動いていました。実際には、私の指示の曖昧さが原因でAIが誤った提案をすることがあります。
AIへの指示が曖昧なほど、提案の精度は下がります。「表示が違う」「動きがおかしい」と感じた場合、原因はAIではなく指示の粒度にあることが多いです。
再現条件（この方法が機能する条件）
「非エンジニアでもアプリが作れた」という事実は、以下の条件が揃っていたから成立しました。
条件①：処理の流れが単純であること
今回のアプリは「入力→判定→表示」という単純な流れでした。条件分岐が複雑になると、AIが生成するコードの整合性確認が難しくなります。
条件②：主AIにファイル操作権限があること
Claudeがファイルシステムに直接アクセスできる環境（MCPを使用）だったため、私はコードのコピペ作業をほぼしなくて済みました。ファイルを手動で更新する環境では、時間が大幅に増えます。
条件③：主AIを1つに固定していること
複数のAIから情報を受け取る場合、「どちらを採用するか」の判断が毎回必要になります。この判断コストは想定以上に大きいです。
条件④：ローカルで完全に動作確認してからデプロイすること
ローカルで未解決の問題がある状態でデプロイに進むと、問題の切り分けが困難になります。
最初に「どのAIを主軸にするか」を決める。私の場合はClaudeを主軸とし、ChatGPTは別の視点が必要なときだけ使う形にした。 判断基準：主AIが決まっているか → 決まっていない場合は先に決める
外部API（Supabase・Dify）との接続も含めてローカルで動作確認する。「画面が表示される」だけでなく「データが保存される」まで確認する。 判断基準：依存関係が全て閉じた状態で動いているか → NOなら次に進まない
AIの提案をそのまま実行する前に、「何のためにこの操作をするか」を確認する習慣を作る。 判断基準：提案の意図が理解できているか → NOなら実行前に確認を取る
セルフチェック
AI活用の設計
□ 主AIを1つ決めているか → NOなら先に決める
□ サブAIの提案を主AIに確認してから動いているか → NOなら確認ステップを挟む
□ AIの提案に違和感があるとき、実行前に確認しているか → NOなら習慣として定着させる
開発の順序
□ ローカルで依存関係が全て閉じた状態で動いているか → NOなら次に進まない
□ 「ローカルで動く問題」と「デプロイ環境の問題」を分けて考えているか → NOなら環境差異を先に把握する
この後どうなったか（デプロイ編へ続く）
ローカルで動くアプリが完成した後、本番公開（Cloudflareへのデプロイ）に挑みました。
ここから約6時間の試行錯誤が始まります。Pages、Workers、opennextjs、WSLと複数の方法を行き来して、最終的にWSLからCLIでビルド＆デプロイする方法にたどり着きました。
デプロイ失敗の記録と判断の分岐点については、次の記事に整理しています。
よくある質問
- コードの知識がなくても本当にアプリは作れますか？
-
ローカルで動かすだけなら、コードの知識はほぼ不要でした。ただし「動かない」「表示がおかしい」という場面で、エラーの意味を把握しながら進む必要があります。「コードを書く力」ではなく「エラーを読む力」が必要です。
- ClaudeとChatGPTはどちらが優れていますか？
-
「どちらが優れているか」より「何に使うか」で選ぶ方が機能します。主AIを決め、もう一方は「別の視点の確認」に使う設計が、情報の混乱を防ぎます。
- アプリ開発にかかった費用は？
-
Claudeのプロプランを使いましたが、長いやり取りでセッション制限に引っかかり、追加クレジットを投入しました。「時間をかければプロプランだけで済んだかもしれない」ですが、作業の勢いを維持するために一気に進める判断をしました。インフラ費用（Supabase・Cloudflare）は現時点では無料枠内に収まっています。
構造まとめ
今回の失敗を構造化すると、以下の3点に集約されます。
① AI選択の設計がなかった
複数のAIを使うなら、主AIを先に決める必要があります。情報の一元化ができていないと、矛盾する提案を受け取ることになります。
② 確認の順序が設計されていなかった
「実行前に確認を挟む」ステップを最初から設計に組み込むことで、修正コストを大幅に減らせます。AIを使う場合でも、確認の習慣は人間側の設計です。
③ ローカルとデプロイの問題を同一視していた
ローカルでの動作確認とデプロイ後の動作は、解決すべき問題の構造が異なります。この2つを分けて認識することが、問題の切り分けを速くします。
この3つの構造ミスを避けるだけで、同じ工程の時間は大幅に短縮できます。 技術力の問題ではなく、設計の順序の問題です。AIを活用するなら、AIの使い方そのものを先に設計する必要があります。
関連記事
このシリーズを順番について読む
同じ構成でアプリを作りたい方へ
実際に使用した設計・判断基準・プロンプトをまとめています。
この記録を読んで「自分が今どの段階にいるか」を確認してみてください。
- ローカル開発がまだ → この記事のSTEP1〜3のチェックリストから始めてみると進みやすいです
- デプロイで詰まっている → 次の記事（デプロイ編）の判断の分岐点から確認してみてください
Jogtimeは、設計によって変わりました。
では、あなたは今どの段階でしょうか？
- まず全体像を整理したい
- 構造を整えて伸ばしたい
- 設計から見直したい
今の状態に合わせて、次の一手を選んでください
コメント