8月11日の15時50分、「利益計算機」というiOSアプリの開発環境をセットアップするコミットを打ちました。その日の21時40分に実装が終わり、翌日の昼にApp Store申請素材一式を作って提出。そのまま審査を通過し、いまApp Storeに並んでいます。

規模感で言うと、Dart約3,300行・25ファイル・テスト31件・計37コミット。実装に使ったのは実働約6時間です。

自慢をしたいわけではありません。git logに全過程が残っていたので振り返ってみたら、速さの理由がコードを書く速さとはほとんど関係なかったのが面白かったのです。この記事では、タイムラインの全公開と、6時間で終わった本当の理由を書きます。

この記事で分かること

  • 環境構築からApp Store申請までの実際のタイムライン（git logの時刻つき）
  • 開始27分で全画面がそろった理由 — 事前に決めた「作らないものリスト」
  • AIが書いたもっともらしく間違った計算式の話（正直パート）
  • 1日の途中で課金モデルを捨てた判断
  • 1日アプリに向く題材・向かない題材

結論: 速さの正体はコード生成ではなく「決める速さ」

先に結論です。Claude Codeのコード生成が速いのは事実ですが、それは前提にすぎません。実際に効いたのは次の3つでした。

  1. 最初に「作らないものリスト」を決めた — iOSのみ・iPhone専用・日本語のみ・サーバーなし・アカウント登録なし。仕様書のWon'tリストに明記してから書き始めた
  2. 開発プロセスを事前にテンプレート化してあった — 要件定義 → 仕様書 → 雛形生成 → 実装 → 申請素材、の流れと成果物の形式を過去のアプリで確立済みだった
  3. 迷ったら削った — 作った機能をその日のうちにrevertし、設計したフリーミアム課金もその日のうちに捨てた

逆に言うと、この3つがないままClaude Codeに「アプリ作って」と頼んでも、たぶん1日では終わりません。順に見ていきます。

何を作ったか: 自分が欲しかった利益計算機

作ったのは、副業・スモールビジネス向けの利益シミュレーターです。販売価格・原価・手数料・広告費・固定費を入れると「最終的にいくら残るか」がリアルタイムに出ます。利益計算・目標利益の逆算・損益分岐点・価格比較・広告シミュレーションの5機能で、データはすべて端末内。登録不要・完全無料・広告なしです。

なぜこれを作ったかというと、自分が一番欲しかったからです。私はAI画像生成アプリを2本運営していて、「月額いくらで何人に使われたら、API原価を引いていくら残るのか」を何度もスプレッドシートで計算してきました。だからこのアプリには、こういうテンプレートが入っています。

AIサービスの変動原価 = 1回あたりAPI原価 × 平均利用回数 × 利用者数

サブスク型・都度課金型・サブスク＋都度のハイブリッド型まで切り替えられます。個人開発でAIアプリを作っている人なら、この計算を欲しがる理由が分かってもらえるはずです。

タイムライン全公開

git logの時刻をそのまま載せます。

時刻 やったこと
15:50 開発環境セットアップ（要件定義・MVP仕様書・CLAUDE.md・ファクトファイル・hooks・CI雛形）
15:55〜15:57 決めごとを連続コミット（課金の境界・初回リリースはiOSのみ・履歴上限100件）
16:03 Flutterプロジェクト初期化＋MVP雛形生成
16:09 計算エンジン実装＋受入テスト12件
16:13 データ層実装（モデルのJSON化・Hiveリポジトリ・テンプレート定義・Riverpod）
16:17 全画面のUI実装（ホーム・計算4画面・プロジェクト・履歴・設定）
16:37〜19:39 機能追加と磨き込み（広告シミュレーション・課金方式バリアント・iOS風デザイン刷新・アプリアイコン）
19:30 スライダー微調整機能をrevert
20:43 フリーミアム廃止 → 完全無料化＋クロスプロモ導線
21:40 プライバシーポリシー・利用規約リンク（実装はここまで）
翌12日 昼 App Store申請素材一式（タイトル・キーワード・説明文・スクショ構成）を作成して提出

環境構築の開始が15:50、全画面がそろったのが16:17。27分です。ここだけ見ると魔法のようですが、種があります。

速さの正体①: コードより先に「仕様書」があった

15:50の環境構築コミットに入っていたのは、コードではなく文書です。要件定義書、MVP仕様書、ファクトファイル（アプリ名・機能数・URLなど実数の単一ソース）、そしてClaude Codeへの指示書であるCLAUDE.md。

特に効いたのが、仕様書のMust/Should/Won'tの区別です。Won'tにはこう書いてあります。

会計帳簿・確定申告・税金計算・請求書発行・銀行口座連携・在庫管理・AI経営診断・チーム共有・クラウド同期・アカウント登録は今回作らない

利益計算アプリを作ろうとすると、会計アプリの方向に膨らむ誘惑が無限にあります。それを書き始める前に全部断ったわけです。さらにプラットフォームもiOSのみ・iPhone専用・日本語のみに絞りました。サーバーも認証もないので、Swiftネイティブの記事で書いた「借りるものが減ると速い」と同じ構図が、Flutterでも起きています（Flutterにしたのは、Android版を後から出す予定があるためです）。

27分で全画面が出たのは、Claude Codeが速かったからではなく、27分ぶんの作業しか残らないように事前に削ってあったからです。

速さの正体②: 仕様書の受入条件がそのままテストになった

もうひとつ、初日の16:09に受入テストが12件入っているのがポイントです。仕様書に「予算30,000円・CPA1,000円なら30件獲得で黒字」のような受入条件を書いてあったので、それをそのままテストコードに落としています。

test('月額型: 使われるほどAPI原価が増える（売上は固定）', () {
  // 月額1,000円×100人、API原価5円×平均20回 → API原価10,000円
  final input = buildInput({
    TemplateField.price: 1000,
    TemplateField.quantity: 100,
    TemplateField.apiUnitCost: 5,
    TemplateField.avgUsageCount: 20,
    TemplateField.fee: 10,
    TemplateField.fixedCost: 20000,
  }, feeIsRate: true);
  final result = calculator.calculate(input);
  expect(result.revenue, 100000);
  expect(result.costOfGoods, 10000);
});

計算アプリは入出力が明確なので、この進め方と相性が抜群です。計算エンジンをUIから切り離した純Dartにして、テストで固めてから画面を作る。最終的にテストは31件になりました。AIに書かせるからこそ、正解を機械で判定できる形にしておくのが効きます。

正直パート: AIはもっともらしく間違った計算式を書く

順調に見えますが、17:49にこんなfixコミットがあります。

fix: ハイブリッド型をサブスク＋都度モデルに修正（売上はチケット購入分のみ、API原価は総利用回数に連動）

サブスク＋都度課金のハイブリッド型で、最初にAIが書いた計算式は売上と原価の連動のさせ方が間違っていました。コードとしては綺麗に動くし、テストも「その間違った理解のまま」書けば通ってしまいます。これはコードのバグではなく、ビジネスモデルの理解のバグです。

自分が実際にサブスク＋チケット制のアプリを運営しているから「売上はチケット購入分だけ、API原価は消費された総利用回数に連動するはず」と気づけました。AIと開発する時代でも、ドメイン知識のレビューは人間の仕事として残ります。むしろそこだけが仕事になるとも言えます。

もうひとつ、19:03に追加したスライダー微調整機能を19:30にrevertしています。触ってみたら、リアルタイム再計算だけで十分で、スライダーはただ画面を複雑にしていました。30分で作った機能を迷わず捨てられるのは、作るコストが下がったことの隠れた恩恵です。作る速さは、捨てる速さでもあります。

1日の中で課金モデルを捨てた話

タイムラインで一番大きな方針転換は20:43です。開始10分後の15:55には「保存3件まで無料・Pro買い切り」というフリーミアム課金を設計してコミットしていたのに、20:43にフリーミアムを廃止して完全無料にしました。

理由はシンプルで、出来上がったアプリを触ってみて「計算機に課金は成立しにくい」と判断したからです。代わりに設定画面へ「開発者の他のアプリ」導線を置き、自分のアプリ群へ送客する名刺として配ることにしました。IAPを外せば実装も申請もシンプルになるという副次効果もあります。

収益ゼロのアプリを作る意味があるのか、と思うかもしれません。でも個人開発を続けていると、ストアに並ぶ無料アプリ1本はデベロッパーページへの入口になります。課金で数百円を狙うより、そちらの価値を取りました。この判断も、朝の設計に固執していたらできなかったことです。

1日アプリに向く題材・向かない題材

今回の経験から、線引きをまとめます。

向く 向かない
データ 端末内で完結 サーバーの台帳が必要
機能 入出力が明確（計算・変換・記録） 外部APIを呼ぶ（キー保護が必要）
認証 不要 ログインが前提
課金 なし・買い切り サブスク（サーバー検証が要る）
正解 テストで機械判定できる 見た目・体験の良し悪しが本体

私のAI画像生成アプリのように、APIキーを守るバックエンド・不正対策・課金基盤が要るアプリは、どうやっても1日では終わりません。逆に言えば、初めて個人開発でリリースまでやり切る題材としては、今回のようなローカル完結の計算・記録系が最適です。

そして繰り返しになりますが、「1日」はゼロからの1日ではありません。要件定義から申請素材までのプロセスを過去のアプリで確立し、テンプレート化してあったから再現できた1日です。速くしたいなら、コード生成より先に自分の開発プロセスを文書化するのをおすすめします。

まとめ

  • 実働約6時間・37コミットで、利益計算機アプリを実装からApp Store申請まで完了した
  • 速さの正体は、事前に決めた「作らないものリスト」と、テンプレート化済みの開発プロセス
  • 受入条件をテストに直結させると、AI開発でも品質を機械で担保できる
  • ただしAIは、もっともらしく間違った計算式を書く。ドメイン知識のレビューは人間の仕事
  • 出来上がったアプリは完全無料。App Storeの「利益計算機」で試せます。副業やアプリの収益設計に使ってみてください