合計8時間で、Claudeのセッション制限に引っかかり追加クレジットを投入しました。この記録は「体験談」ではなく、同じ場面に立ったとき判断できるための記録です。費用・時間・トレードオフの構造を整理します。
このシリーズの前の記事について
– ローカル開発編 → 実装の設計とAI活用の判断基準
– デプロイ編 → 環境設定と問題切り分けの判断基準
この記録を残す理由
前2記事では「ローカル開発」と「デプロイ失敗」の判断基準を整理しました。
この記事はその締めです。費用・時間コスト・判断の根拠を構造化します。
「AIを使えばアプリが作れる」という情報は増えています。ただ「実際いくらかかるか」「どこで費用をかけるべきか」「完成させることと費用を抑えることのトレードオフをどう判断するか」が書かれた記録は少ないです。ここを整理します。
費用の構造（固定・変動・機会コスト）
費用を「種類」で整理するとこうなります。
固定費（毎月かかる）
- Claude Proプラン：月額固定
変動費（今回だけ発生した）
- 追加クレジット：セッション制限を超えたため投入。数千円程度。「時間をかければゼロだった費用」です。
インフラ費（現時点ゼロ）
- Supabase・Cloudflare Workers：いずれも無料枠内。ユーザーが増えると有料プランへの移行が必要ですが、それは成立してから判断します。
- ドメイン：年間数百円程度（エックスサーバーで取得済み）。
機会コスト（数値化が難しい費用）
- 開発にあてた約8時間
- 家族と過ごす時間（週末を開発に使った）
機会コストを含めると、追加クレジットの費用より大きい可能性があります。ただし機会コストは「どちらの選択をしても発生する」という前提で考える必要があります。
判断基準として残すなら：
費用の種類を先に分類する。変動費（追加クレジット）は「完成を優先するか・時間をかけて抑えるか」で制御できます。固定費とインフラ費は完成の前後で構造が変わります。
時間コストの構造（実装 vs 切り分け）
合計8時間の内訳を構造で整理します。
| フェーズ | 時間 | 内訳 |
|---|---|---|
| ローカル開発 | 約2時間 | 設計・実装・動作確認 |
| デプロイ | 約6時間 | Pages失敗・Workers切り替え・WSL導入・解決 |
| 合計 | 約8時間 |
数値の構造分析として重要なのは「6時間のうち4時間以上が、根本原因を特定するまでの時間だった」という点です。
- 実装時間：約2〜3時間
- 問題切り分け時間：約4〜5時間
原因が分かってからの解決は1〜2時間でした。つまり「ビルド環境の問題」を最初から把握していれば、8時間は3〜4時間以下になっていました。
時間コストの大半は「実装」ではなく「問題の切り分け」に費やされます。 環境設定の判断基準を持っていれば、切り分け時間は大幅に削減できます。この判断基準を知っているだけで、同じ工程が半分以下になります。
判断基準として残すなら：
AIアプリ開発の時間見積もりは「実装時間の2〜3倍」で計算する。特にデプロイ環境（Cloudflare等）の選定を誤ると、そこで大半の時間を失います。
3つのトレードオフと判断基準
今回の開発で直面したトレードオフを構造化します。
トレードオフ①：費用を抑える vs 完成を優先する
「時間をかければ追加クレジットはゼロだった」は正しいです。ただし「時間をかけることで完成しない」リスクもあります。
判断基準：
- 完成することに強い動機があるか → YES なら完成優先（費用を許容）
- 時間をかけても熱が冷めない自信があるか → NO なら完成優先
- 予算に制約があるか → YES なら時間をかけて抑える
トレードオフ②：集中して進める vs 分散して進める
「週末8時間を集中して使う」と「複数週に分けて少しずつ進める」のどちらが良いかは、目的と状況によります。
判断基準：
- 作業の文脈（どこまでやったか）が頭から抜けやすいか → YES なら集中型
- 家族・周囲への影響を一点に集中させる方が合意を得やすいか → YES なら集中型
- 長期間のモチベーション維持に自信があるか → NO なら集中型
今回の私の判断は「集中型」でした。理由は「一度止まると再開のハードルが上がる」「デプロイのような環境依存の作業は文脈が頭から抜けると最初からやり直しに近い」の2点です。
トレードオフ③：完成させる vs 自力で維持できる状態を作る
「完成した」と「自力で維持できる」は別の状態です。今回の私は完成させることを優先しました。
判断基準：
- 「完成してから売る」ことが先か、「維持できる状態にしてから完成させる」ことが先か
- 今回のゴールは前者です。コードを理解することは今回の目的ではありませんでした。
「完成させること」を優先した場合、「自力での修正・改良」は難しい状態になります。エラーが起きたときAIなしでは対応できません。この状態を許容した上で進めるかどうかを先に決めてください。
費用をかけるべきタイミングの判断基準
追加クレジットを投入するタイミングは「今投入しないと完成しない可能性がある」という判断でした。構造として整理すると：
「これを完成させることに強い動機があるか」を確認する。動機が明確なら費用を許容する判断がしやすい。 判断基準：動機が1文で言えるか → 言えない場合は費用より前に目的を整理する
「時間をかければ費用はゼロ」「費用をかければ時間が短縮できる」を数値で比較する。自分の時間単価と追加費用を対比させる。 判断基準：時間単価 × 短縮できる時間 > 追加費用なら費用をかける
「止まった場合に再開できる確率」を正直に評価する。再開の自信がなければ完成を優先して費用を許容する。 判断基準：過去に作業を止めて再開できた経験があるか → NOなら完成優先
「いつまでに終わるか」を具体的に決めて周囲に伝える。期間の終わりが見えない作業は合意を得にくい。 判断基準：終了の見通しを1文で言えるか → 言えない場合は期間を先に決める
セルフチェック
費用の判断
→ 「費用を抑える」か「完成を優先する」か、先に決めているか → NOなら先に決める
時間コストの見積もり
→ デプロイを含む工程を「実装時間の2〜3倍」で見積もっているか → NOなら見積もり直す
切り分け習慣
→ エラー発生時にログを先に確認してから対処しているか → NOなら順序を逆にする
周囲への影響の明示
→ 作業期間と終了の見通しを周囲に伝えているか → NOなら先に伝える
よくある質問
- AIアプリ開発の費用はどのくらいかかりますか？
-
固定費（Claudeプラン）・変動費（追加クレジット）・インフラ費・機会コストで構造が違います。インフラ費は無料枠内で始められます。変動費は「完成を優先するか時間をかけるか」の判断で制御できます。今回の追加クレジットは数千円程度でした。
- 非エンジニアでも自力でエラーに対応できますか？
-
「エラーの意味をAIに聞く」ことはできます。「コードを自力で直す」ことは難しい状態です。この2つは別です。今の私の状態は「AIなしでは修正できない」状態を許容して完成させた、という形です。
- Claudeのセッション制限はどのくらいで引っかかりますか？
-
一つのチャットで長いやり取りを続けると引っかかりやすいです。新しいチャットを都度開く、または作業を複数セッションに分ける方が制限に引っかかりにくいです。今回は同一チャットで続けた結果、制限に達しました。
構造まとめ
今回の3記事シリーズ全体を構造化すると、以下の3点に集約されます。
① AIの使い方そのものを設計しないと、AIを使うほど混乱する
主AIを決め、確認の習慣を設計に組み込む。これだけで大半の実装の失敗は防げます。
② ビルド環境の問題はツールの問題より先に解決する
エラーが出たときはまずログを確認する。ツールを変える前に環境を疑う。この順序だけで、6時間の失敗は2時間以下になります。
③ 費用・時間・完成のトレードオフを先に判断する
「費用を抑えるか」「完成を優先するか」「集中して進めるか」の判断は、作業を始める前に決めておく。決めていないと、どれも中途半端になります。
この3つの判断基準を最初に持っていれば、8時間は3〜4時間以下になっていたと思います。 それがこの3記事を書いた理由です。
まず、あなたが今直面している判断を1つ選んでみてください：
- 費用を抑えることを優先する → 時間をかけてゆっくり進める設計から始めてみると進みやすいです
- 完成を優先する → 期間を決めて周囲に伝えてから集中する設計から始めてみると進みやすいです
どちらを優先するかを先に決めておくことで、作業中の判断ブレが減ります。
関連記事
このシリーズを順番について読む
同じ構成でアプリを作りたい方へ
実際に使用した設計・判断基準・プロンプトをまとめています。
コメント