先月、本業Webエンジニアの自分が、コードを全部Claude Codeに任せて初めてのiOSアプリ「あと何回」を公開した話を書きました。
その1本目の公開から10日後、2本目のiOSアプリ「いただき帳」がApp Storeで公開されました。
企画からリリースまで約3週間だった1本目に対して、今回は企画確定からリリースまで19日。
特に終盤の「実機での受け入れ確認から審査提出まで」は、1本目で約5日かかった工程が約12時間、実質1日で終わっています。
コードを全部Claude Codeに任せるスタイルは前回と同じ。
変わったのは、1本目の開発を「記録」として残してあったことだけです。
「2本目なんだから、慣れて速くなっただけでは？」と思うかもしれません。
正直、半分はそのとおりです。
ただ、振り返ってみると速さの中身は”慣れ”のような曖昧なものではなく、もっと具体的な仕組みでした。そして速くなった一方で、今回は審査で2回の却下も食らっています。
1本目は一発承認だったのに、です｡°(°´ω`°)°｡
この記事では「なぜ速くなったのか」と「何が通用しなかったのか」を、前回と同じくつまずきも含めてそのまま書き残していきます。
記事の目次
「いただき帳」ってどんなアプリ？｜ご祝儀・香典・お返しを”人別に”引ける台帳
結婚式のご祝儀、お葬式の香典、お中元にお歳暮。
こういう「人とのお金・品物のやり取り」を人別に記録しておいて、次の機会に「この人と前はどうやり取りしたっけ？」を一瞬で引けるようにするアプリです。
昔から家庭にある紙の「おつきあいノート」のデジタル版、と言うのが一番伝わると思います。
- 記録するのは「誰と・いつ・何を・いくら」。もらった側もあげた側も両方残せます
- 人名で検索すると、その人との過去のやり取りが時系列で出てきます。「同じ相手からいただいた額と同じくらいを包む」という慣習に直球で応えるための機能です
- お返し（内祝い）には「する予定」「済み」を付けられて、お返し予定だけの一覧でまとめて確認できます
無料で10人まで登録できて（記録の件数は無制限）、11人目からは買い切り¥300、広告なし・サブスクなしです。
実はこの課金の構成が1本目とほぼ同じで、これが後半に出てくる「速さ」の伏線になります。
App Store: いただき帳 – ご祝儀・香典・お返しの記録
作った理由はシンプルです。競合調査で、既存アプリの最大の機能ギャップが「お返し（内祝い）の管理」だと分かったから。
加えて、このジャンルの既存アプリには「データが消えた」という★1レビューが目立ちます。
「消えない保証（エクスポート/バックアップ）×お返し管理×買い切り」なら参入する余地がある、という読みでした。
企画の深掘りにも書きたいことは色々あるのですが、今回の主役は「作る速さ」の方なので、先へ進みます。
数字で見る2本目の速さ｜受け入れ確認から審査提出まで12時間
まず、審査提出の日（7月18日）が実際どう進んだかを並べます。
| 時間帯 | やったこと |
| 午後 | 実機（iPhone 15）で受け入れ確認。テスト済みの14フローを手動でなぞって全合格 |
| 夕方 | アプリ内課金（RevenueCat）の本実装。自動テスト158件が全部緑になるまで |
| 夜 | RevenueCatとApp Store Connectの設定、課金のsandboxテスト8手順を全合格 |
| 深夜 | アプリの公式サイト公開 → 提出用ビルド作成 → 日付が変わって0:16に審査提出 |
実機での受け入れ確認を始めてから審査提出まで、約12時間。1本目の「あと何回」では、同じ工程（課金の仕上げから審査提出まで）に約5日かかっていました。
ざっくり5分の1です。
「その12時間、相当バタバタだったのでは？」と思うかもしれませんが、体感はむしろ逆でした。
理由ははっきりしていて、手戻りがほぼゼロだったからです。象徴的な数字を2つ挙げます。
- 実機で初めて見つかるバグ: 0件。1本目では「数値キーボードを開くと保存ボタンが隠れて詰む」のような実機でしか出ないバグに悩まされましたが、今回は受け入れ確認14フローが一発全合格でした
- 提出時のエラー: 1件だけ。1本目ではiPadスクリーンショットの要求で弾かれて再ビルドしたり、「メタデータが不足しています」の正体探しをしたりと、提出ボタンの前で何度も足止めされました。今回引っかかったのは初見の設定項目（コンテンツ配信権の未申告）の1件だけ。1本目の教訓を先回りで適用した項目は、すべてノーエラーで通過しています
ただ、実機確認のスムーズさについては「2本目だから」ではなく、1本目から続けている進め方の寄与が大きいです。
自分は先にNext.jsでWeb版を作り、バリデーションやUI・UXまわりの仕様をブラウザ上でほぼ詰めきってからFlutterに移植しています（この進め方は 前回の記事 に書きました）。
今回はさらに一歩進めて、受け入れ確認に使った14フローはWeb版のE2Eテストをそのまま実機の受け入れ基準に流用したものです。
実機に載せる時点で「仕様は詰め終わっていて、検証手順まで揃っている」状態になっているので、実機での確認は答え合わせだけで済みます。
念のため書いておくと、開発期間の全体も短くはなっています（企画確定から審査提出まで13日）。
ただ、企画や仕様決めの期間は「決めることの多さ」で決まるので、2本目でも劇的には縮みません。
縮んだのは圧倒的に終盤、つまり1本目と同じことをやる工程です。
で、なぜそこが5分の1になったのか。
次が本題です。
速さの正体｜1本目で残した「型」が3つあった
12時間の内訳を見返すと、時間を食いそうな要素は明らかに課金まわりです。
アプリ内課金は、コードの実装・RevenueCatのダッシュボード・App Store Connect（以下ASC）のIAP登録という3つの世界をまたぐ作業で、初見だと確実に迷子になる場所です。
それが今回スルッと終わったのは、1本目で残した「型」が3つあったからでした。
型その1｜差し替えられるコード
1本目の課金実装は、「購入済みかどうかを答える係」を1つのインターフェースに切り出して、開発中はフェイク実装・本番はRevenueCat実装、と差し替えられる設計にしてありました。
APIキーの置き場所も「実キーはgitに入れない・コミットするのは雛形ファイル・キー未設定ならフェイク実装で起動して止めない」という形で型になっています。
おかげで今回の課金実装は、極端に言えば「RevenueCat用のファイルを1個持ってきて、つなぎ目を書き換える」だけ。
着手前にClaude Codeのサブエージェント2体へ「流用元（あと何回）の実装マップ」と「差し替え先（いただき帳）の現状マップ」の調査を並行で投げたところ、「差し替えが必要な箇所は実質2点」というレポートが返ってきて、実装は自動テスト158件が全部緑になるまで一気に終わりました。
型その2｜コードの外の手順書
課金のコードよりも記録が効いたのが、コードの外の作業です。
RevenueCatのプロジェクト設定、ASCのアプリ登録・IAP登録・審査情報の入力。この手のダッシュボード操作は1本目で散々迷子になった場所ですが、その全手順がCLAUDE.md（Claude Codeがセッションをまたいで参照するプロジェクトメモ）に記録してありました。
今回はClaude Codeがその手順書を読みながら「次はこの画面でこれを設定してください」とナビゲートしてくる状態になります。
こちらがスクリーンショットを見せると現在地を認識して、次の操作を指示してくる。
ダッシュボードのハンドルを握っているのは自分ですが、地図とナビは向こうが持っている、という分担です。
型その3｜ハマりの先回り適用
1本目のハマりは「次はこうする」の形で記録してあったので、今回は提出前にまとめて予防適用しました。
代表は3つです。
- iPhone専用アプリとして設定（1本目はFlutterのデフォルトのままiPad対応扱いになり、iPadスクリーンショットを要求されて再ビルドになった）
- 暗号化に関する申告フラグをビルドに埋め込み（提出時の輸出コンプライアンス質問をスキップできる）
- IAPを審査提出物に同梱する手順の事前確認（審査員が課金を見つけられないと差し戻される）
結果は前のセクションに書いたとおりで、先回りした項目はすべてノーエラー通過。
1本目で起きた「提出ボタンで弾かれて再ビルド」は今回ゼロでした。
その記録、誰が書いたのか？
ここまで読んで「その記録を書き残すのが一番大変なのでは？」と思った方へ。
実はこの記録、大半はClaude Codeが自分で書いています。
作業が一段落するたびに「何をやったか・何にハマったか・次はどうするか」をCLAUDE.mdに書き足していくのを定常運転にしていて、人間の自分がやったのは「記録を残す運用にする」と決めたことくらいです。
1本目の丁寧な記録が、2本目の速度になる。
そしてその記録は、AIに書かせられる。
今回の一番の学びはこれでした。
それでも記録どおりには行かない｜6日でASCの提出UIが変わっていた
と、ここまで型と記録を礼賛してきたので、通用しなかった話もフェアに書いておきます。
1本目の審査提出は7月13日、2本目は7月19日。
このたった6日の間に、ASCでIAPを審査に同梱する手順のUIが変わっていました。
手順書には「バージョンページの欄でIAPを選択する」とあるのに、今回はその欄自体がない。
画面を見回すと、IAPページ側に「審査用に追加」という新しい導線が生えていて、そこから既存の提出物の下書きに追加する方式に変わっていました。
結局、手順書が通用しない部分は、その場の画面のバナー文言から読み解いて軌道修正です。
記録は正確でも、世界の方が変わる。この経験から、手順書は「そのままなぞるもの」ではなく「差分に気づくための基準線」と捉えるようになりました。
基準線があれば「手順書と画面が違う」こと自体に即気づけるので、迷子になる時間は初見よりずっと短くて済みます。
似た話をもう2つ、解決済みの小話として置いておきます。
その1、提出直前の見落とし発見。
提出用のビルド設定を整えていたとき、Claude Codeがホーム画面に表示されるアプリ名が `Itadakicho` とローマ字のままなのを見つけました。
ストア関連の決定事項は STORE.md という1ファイルに集約してあり、そこの「ホーム画面の表示名=いただき帳」という決定と実際の設定ファイルを照合して食い違いを検出した、という流れです。
ドキュメントを「単一の真実」にしておくと、人間が見落とした差分を機械が拾ってくれる。
地味ですが、これはドキュメント運用の実利だと思います。
その2、AIが自分のバグに自分で気づいた瞬間。
課金実装中、APIキーが雛形のままかどうかを判定するコードに、Claude Codeがゆるい部分一致の判定を書きました。
その直後、「実際のキーに偶然この文字が含まれていると、本物のキーをフェイク扱いしてしまう」と自分で気づいて、完全一致の判定に書き直したんです。
実は1本目のアプリの実キーがまさにその「偶然含まれる」ケースで、素通りしていたら本番で課金が動かないバグでした。
AIは間違えるけれど、自分で気づきもする。
ただし毎回気づくとは限らないので、人間のレビューを外していい理由にはならない——という距離感が今のところの結論です。
今回は一発承認ならず｜却下2回で知ったIAP審査の罠
提出から2日後に届いたのは、承認ではなく却下の通知でした。
1本目が一発承認だったので、正直「審査対策も型のうち」と思いかけていたところにこれです。
結局、承認までに却下を2回はさんで約5日。
ここが今回一番の学びどころだったので、少し丁寧に書きます。
却下①｜審査員がアプリ内課金を見つけられない
1通目は「Information Needed（情報が必要）」。
¥300の買い切り課金を審査員が見つけられない、という内容です。
理由は構造的でした。
このアプリのペイウォール（購入画面）は「11人目の相手を追加しようとしたとき」にしか出ません。
審査員が短時間の操作で相手を10人も登録するはずがなく、自然には遭遇できないんです。
しかも実は、審査メモには「10人登録して11人目を追加するとペイウォールが出ます」と提出時から書いてありました。
書いてあっても、見つけてもらえないときは見つけてもらえない。
「1本目はなぜ通ったの？」と思いますよね。
あちらは無料上限が2件で、審査員の操作でも自然に3件目に到達していただけ。
数字の差であって、構造の差ではなかったわけです。
対応としては、連続入力モードで10人登録する具体的な操作手順（相手の名前は重複不可なので毎回変える、まで含めて）を英語で返信して完了。
コードの変更は不要でした。
却下②｜こちらは直していないのに「購入がエラーになる」
返信の翌日、2通目の却下が届きます。
今度は「App Completeness」——審査員が購入を試したらエラーになった、と。
いやいや、sandbox（Appleの課金テスト環境）の購入テストは8手順全部合格させてから提出しています。
「動いていたはずなんだけど？」となりますよね。
ところが実機で確かめると、たしかに購入シートが出ない。
調べて分かった真因はこうでした。
却下①の時点で、提出物に同梱されていたIAPも巻き添えで「却下済み」ステータスに落ちていて、その状態のIAPはsandboxで商品情報を取得できなくなる（RevenueCatの公式ドキュメントにも、購入が動かない典型原因として明記されていました）。
却下に返信して審査を続けてもらう場合でも、IAPのステータスは自動では復旧しない——これが罠です。
つまり却下①をもらった瞬間から、こちらは何も変えていないのに、審査員側では課金が壊れて見える状態になっていました。
対処は3手です。
①IAPページからステータスを「審査準備完了」に復帰させる ②実機＋新規のsandboxアカウントで「購入シート表示→購入→機能解放」までをフル録画する ③原因説明の英文と動画を添えて、同じビルドのまま再提出する。
これで翌日、承認が出ました。
ちなみにASCのメッセージ返信欄が「処理中」のまま送信できなくなる障害まで踏んだので、説明と動画はApp Review情報のメモ欄＋添付欄という代替経路で届けています（添付は1ファイルだけ・動画も可）。
教訓を1行にまとめます。
提出物が却下されたら、アプリ側に原因がなくても、同梱IAPのステータスが巻き添えで落ちていないかを必ず確認する。
知っていれば5分の確認、知らないと却下1往復ぶんの2日です。
公開後の儀式｜自腹¥300の実課金テスト
今回もリリースは自動公開ではなく手動にしました。
理由は1本目と同じで、本番環境のアプリ内課金は公開後にしか確認できないからです。
承認の通知を確認してから公開ボタンを押し、実機から開発用ビルドを消して、テスト用アカウントからサインアウトして、App Storeから自分のアプリをダウンロードし直す。
そして自腹で¥300を払い、購入→機能解放→復元までを確認して完走です。
2本目にして、これはもう公開後の「儀式」だなと思い始めています。
ちなみにこの¥300も、手数料を引いた手取りは¥210。
1本目のぶんと合わせて、記念すべき初着金を静かに待っています。
まとめ｜2本目のアプリ開発で分かったこと3つ
2本目のiOSアプリ開発で腹落ちしたのは、この3つです。
- 1本目の丁寧な記録が、2本目の速度になる。 差し替えられるコード・コード外の手順書・ハマりの教訓。この3つの型が揃っていると、「前と同じことをやる工程」は5分の1になります。そしてその記録は、AIに書かせられます
- 記録が正確でも、世界の方が変わる。 ASCのUIは6日で変わり、審査は同じ作りなのに一発では通りませんでした。手順書は「なぞるもの」ではなく「差分に気づくための基準線」。そう捉えれば、変わった部分にも最短で気づけます
- 人間とAIの分担は、2本目でも変わらない。 AIが手順書とナビを持ち、人間がハンドルを握る。ダッシュボード操作・実機テスト・公開の判断は、今回もすべて人間側の仕事のままでした
1本目の記事の締めに、Webエンジニアにとっての参入障壁は「何を作るか決めること」と「ストア公開の事務手続き」だと書きました。
2本目を終えた今の実感を足すなら、その事務手続きも、記録さえ残せば型になる。
そうなると本当に残る障壁は「何を作るか」だけです。というわけで、3本目の企画はもう動き始めています。
この記事が、同じように「1本目は出せた。さて2本目はどうしようかな」と考えている方の参考になれば嬉しいです。
「いただき帳」はApp Storeで公開中です。ご祝儀や香典のやり取りを、紙のノートや記憶に頼って管理している方は、ぜひ触ってみてください。
App Store: いただき帳 – ご祝儀・香典・お返しの記録
