App Store 審査通過後の30分でやること — 個人開発 iOS アプリのリリース後段取り

AI 主体で執筆

はじめに

朝、メールを開くと App Review からの通知が2通。

"Congratulations! Your submission has been approved for distribution."

数週間〜数ヶ月をかけて作ってきたアプリがついに App Store に並ぶ。嬉しい。でも、よく考えると次に何をすべきか意外と明確ではない。

この記事は、60d Memo v1.0 の審査通過メールを受け取った直後、実際にやった段取りの記録だ。個人開発の iOS アプリで「審査通過がゴールではなく、スタートラインでしかない」ことを踏まえた、リリース直後のチェックリストとして書く。

前提: TestFlight でのベータテストが終わり、App Store への提出で審査通過したタイミングの話。提出前のチェックリストは別物。

結論：やることは大きく5つ

審査通過メールを受け取ったら

  • LP / ウェブサイトに App Store リンクを追加（プレースホルダーを置いていたなら）
  • git リポジトリに v{X.Y} リリースタグを打つ
  • CHANGELOG の [Unreleased] をバージョン確定
  • TODO 管理ファイルのステータスを「リリース済み」に
  • ブログや SNS でリリース告知

それぞれ 5 分〜10 分程度。合計 30 分ほどで完了する。AI コーディングツール（Cursor / Claude Code 等）を使っているなら、これらはほぼ自動化できる。

時系列での作業記録

0 分 — 審査通過メール受信 (0:00)

App Store Connect と App Review から 2 通のメール。配布可能になった旨と、https://apps.apple.com/app/{app-name}/id{id} の URL が記載されている。

LP の App Store リンクを更新 (0:05)

多くの開発者は、公式 LP に「配信開始後にリンクを掲載します」のプレースホルダーを置いているはず。これをすぐ差し替える。放置しがち。

60d Memo の場合、日英両方の LP に:

  1. ヒーローセクションに「App Store で入手」ボタンを追加
  2. 情報セクションのプレースホルダーをリンクに置換

Netlify / Cloudflare Pages 等に置いていれば、main へ push したら数十秒でデプロイされる。

リリースタグを打つ (0:10) 
git tag -a v1.0 -m "v1.0 — First public release

Released: 2026-04-16
App Store: https://apps.apple.com/app/60d-memo/id6759208889"
git push origin v1.0

提出時ではなく、審査通過・配布開始後に打つのがポイント。審査で差し戻された場合にタグを消す手間が発生しないし、実際にユーザーが触るコードが明確に残る。

タグ形式は v{major}.{minor} で十分。ビルド番号（Xcode Cloud が自動管理する）はタグに含めない。

CHANGELOG を確定 (0:15)

CHANGELOG.md の [Unreleased] セクションを、バージョン番号とリリース日にリネームする:

## [1.0] — 2026-04-16
...（Unreleased だった内容）

ここで漏れに気付くことが多い。gh pr list --state merged --search "merged:>2025-12-01" 等で前回リリース以降のマージ済み PR を確認し、記載が足りない項目を補充する。

この作業の痛みを知ると、「PR ごとに [Unreleased] を更新する」運用が身につく（これは別記事で書く）。

TODO 管理・ロードマップの更新 (0:20)

todo.md やプロジェクトのステータスファイルを「リリース済み」に。60d Memo では:

  • 状態を「v1.0 App Store リリース済み」に変更
  • App Store URL を追記
  • リリース後ロードマップ（安定化、UX 改善、機能拡張など）を P0〜P4 で整理
ブログ記事でリリース告知 (0:25)

技術者向けのブログがあるなら、リリース告知記事を書く。以下を盛り込むと価値が出る:

  • どんなアプリか（1 段落）
  • なぜ作ったか（コアコンセプト）
  • 技術スタックと設計判断
  • 開発タイムライン
  • 今後の予定
  • App Store / LP / プライバシーポリシーへのリンク

SNS 投稿用には、同じ内容の短いバージョン（2〜3 文 + リンク）も用意しておくと便利。

完了 (0:30)

ここまでで 30 分。AI エージェントに指示できる部分は並行実行させると、もっと早く終わる。

やらなくていいこと・急がないこと

App Store のリリースノート変更

提出時に書いたリリースノートはそのままで OK。v1.0 の初回リリースなら「初回リリース」で十分だし、後からでも次のバージョンで更新できる。

ASO（App Store 最適化）

キーワード・説明文の最適化は重要だが、リリース直後の 30 分でやることではない。1 週間ほどダウンロード数・検索流入の傾向を見てから判断した方が意味のある改善ができる。

プレスリリース・営業

個人開発のメモアプリでプレスリリースは基本的に不要。代わりに、関連コミュニティ（Reddit, Product Hunt, Zenn, 技術ブログ）への投稿を 1〜2 日のうちに計画する程度で十分。

見落としがちな落とし穴

LP のプレースホルダー

「配信開始後にリンクを掲載します」というテキストが何ヶ月も放置されるのをよく見る。審査通過メールが来た瞬間に差し替えるのが鉄則。

CHANGELOG の陳腐化

リリース時にまとめて書こうとすると必ず漏れる。60d Memo v1.0 の場合、[Unreleased] に 4 項目しかなかったが、実際の機能は 20 以上あった。

対策は「PR ごとに [Unreleased] に追記する」ルール化。これは Cursor Rules / AGENTS.md に書いておくと AI が自動でやってくれる。

関連リポジトリの同期忘れ

アプリ本体のリポジトリ以外に、LP のリポジトリ、ドキュメントサイト、Android/Web 版のリポジトリがあるなら、横断的な変更チェックリストを用意しておく。片方だけ更新して放置すると実装と乖離する。

ルール化のすすめ

2 回目のリリース以降は、これらの手順をプロジェクトのルールに書いておくと AI が自動で実行できる。60d Memo では Cursor Rules の github-workflow.mdc に次のように書いた:

## リリースフロー（App Store 提出〜公開）

### 4. リリース後（AI が実行）
審査通過のメールを受け取ったら、以下を一括実行:
1. リリースタグ: git tag -a v{X.Y} -m "..." && git push origin v{X.Y}
2. CHANGELOG の日付確定: リリース日を記入
3. LP の更新: 60d.dev 側で必要な更新があれば実施
4. todo.md の更新: ステータス反映
5. ブログ記事: 大きなリリースの場合は作成

「審査通った」と伝えるだけで、AI がこのチェックリストに沿って順に実行してくれる。個人開発では「自分がやり忘れない仕組み」の価値は大きい。

まとめ

審査通過メールが来たら、次の 5 点を 30 分以内に終わらせる。

  1. LP の App Store リンクを更新
  2. リリースタグを打つ（v{X.Y}）
  3. CHANGELOG を確定
  4. TODO 管理のステータス更新
  5. ブログ / SNS でリリース告知

これらは重要だが後回しにしがちなタスクだ。直後に片付けておくと、LP と実装の乖離、リリースノートの漏れといった、後から取り返しにくい問題を避けられる。

そして 2 回目以降のリリースでは、これらを AI に任せられるようルールとして書いておく。個人開発における 30 分は貴重なので、自動化できる部分は徹底的に自動化する。

審査通過はゴールではない。次のリリースに向けた、安定化・改善の出発点でしかない。