App Storeリリースノートの例文：何が変わったかをユーザーに伝える「What's New」の書き方（2026年版）

良いApp Storeリリースノートが答えるべき問いはひとつです。アップデートすると自分にとって何が変わるのか？ 以下のApp Storeリリースノートの例文は、すべて同じパターンに沿っています。ユーザーが気づく変更から書き始め、各修正を具体的に挙げ、ユーザーに見えないものは省きます。What's New in This Version欄に関するApple自身のガイダンスも同じことを言っています。新機能、UIの改善、バグ修正を記載するよう求め、ユーザーに「the specifics of the changes, improvements, or fixes in the version（そのバージョンでの変更、改善、修正の具体的な内容）」を伝えることを推奨しています。

App Store ConnectとGoogle Playのリリースノートのルールは？

Appleの「What's New」欄は4,000文字まで入力でき、最初のバージョン以降のすべてのバージョンで必須です。Google Playは言語ごとに500 Unicode文字までで、宣伝的な内容は禁止されています。

2026年10月時点で、Play Consoleヘルプには「Do not use release notes for promotional purposes or to solicit user actions.（リリースノートを宣伝目的やユーザーへの行動の呼びかけに使用しないでください）」と書かれています。Appleでは、マーケティング文言は代わりにPromotional Text（プロモーション用テキスト）に入れましょう。この欄は170文字まで入力でき、説明文の上に表示され、Appleでは新しいバージョンを提出せずに更新できます。

良いApp Storeリリースノートとはどのようなものか？

良いリリースノートは、ユーザーが置かれていた状況と、今後得られる結果を明示します。以下の例は架空の習慣トラッカーアプリのものです。曖昧なバージョンは、提出直前に慌てて書かれがちなノートの典型です。

ある修正が技術的すぎて一文で説明できないなら、ユーザーはおそらく気づかないので、最後の「安定性の向上」という一行にまとめて構いません。ガイドライン2.3.12は軽微な修正についてはこれを認めていますが、実際の機能変更については認めていません。

使い回せるリリースノートのテンプレートはありますか？

あります。再利用できるテンプレートは、見出しに続いて「New（新機能）」「Improved（改善）」「Fixed（修正）」のセクションで構成します。リポジトリの変更履歴（changelog）の隣に置いておき、ビルドのアップロード後ではなく、リリースブランチを切るタイミングで記入しましょう。

[One-line headline: the change most users will notice]

New
- [Feature]: [what you can now do], [where to find it]

Improved
- [Screen or flow]: [what feels different]

Fixed
- [Symptom the user saw] when [situation]

Thanks for the reports. Reply via Settings > Help if anything looks off.

Google Play向けには、同じノートを見出しと上位2〜3個の箇条書きに削り、500文字に収めます。各言語のタグは、たとえば<en-US>と</en-US>のようにそれぞれ独立した行に置きます。締めの一文はユーザーに行動を求める内容なので、Playでは削除してください。

マージ済みのプルリクエストをリリースノートにするには？

マージ済みのプルリクエストをリリースノートにするには、ユーザーに見えない変更を除外し、残った変更を症状または結果として書き直します。リリースのたびに次の手順を踏みましょう。

1. 前回のタグ以降にマージされたプルリクエストのタイトルを書き出し、リファクタリング、依存関係の更新、CIの変更など、ユーザーに見えないものを削除します。
2. 残った項目をそれぞれ症状または結果として書き直します。「Fix nil coordinator」は「Appleでサインインした後に画面が真っ白になる問題を修正しました」になります。
3. 項目は、エンジニアリング作業の量ではなく、影響を受けるユーザーの多さの順に並べます。
4. App Store Connectで新しいバージョンを作成したら、前のバージョンのメタデータが引き継がれるため、新しいノートを貼り付ける前にコピーされた「What's New」のテキストを消去します。
5. サポートしているすべてのローカライズにノートを貼り付け、翻訳するか少なくとも各言語で確認し、他のロケールのユーザーに前回のノートが表示されないようにします。
6. Play向けには、短縮版を言語タグ内に貼り付け、各言語が500文字未満に収まっていることを確認します。
7. ノートを一度声に出して読みます。開発者の説明が必要な文があれば書き直します。

ホットフィックスのリリースノートには何を書くべきか？

ホットフィックスのリリースノートでは、不具合のあったバージョンを明記し、修正された症状を説明し、影響を受けたユーザーがアップデート後にどうなるかを伝えます。AppleではApp Store上で以前のバージョンに戻すことができないため、修正は必ず新しいバージョンとして配信されます。

例：「3.4.0で一部のユーザーのリマインダーが通知されなくなっていた問題を修正しました。アップデート前に設定したリマインダーは自動的に再開されます。」影響を受けたユーザーはアップデートすべきだとわかり、影響を受けていないユーザーは自分には関係ない修正だと判断できます。OSのせいにしたり、今後の修正の日程を約束したりしないでください。段階的リリースでアップデートを配信している場合、修正版の審査中にロールアウトを一時停止すれば、不具合のあるビルドを受け取るユーザーの数を抑えられます。ホットフィックスで機能の挙動が変わる場合は、App Store提出チェックリストをもう一度確認し、ノート、スクリーンショット、審査メモの内容を一致させましょう。

リリースノートが原因でApp Reviewにアップデートをリジェクトされることはあるか？

あります。リリースノートはメタデータであり、App Reviewガイドラインで直接扱われています。ガイドライン2.3.12には「Apps must clearly describe new features and product changes in their "What's New" text.（アプリは「What's New」のテキストで新機能と製品の変更を明確に説明しなければならない）」と書かれています。

汎用的な表現は「simple bug fixes, security updates, and performance improvements（単純なバグ修正、セキュリティアップデート、パフォーマンスの改善）」には認められていますが、「more significant changes must be listed in the notes（より重要な変更はノートに記載しなければならない）」とされています。ガイドライン2.3.10は、「What's New」を含むメタデータ内で他のモバイルプラットフォームの名称や画像を使うことを禁じています。フラグで隠された機能や、提出したビルドに含まれていないものは説明しないでください。さらにガイドライン2.3.1(a)では、新機能を「described with specificity in the Notes for Review section（審査メモ欄で具体的に説明する）」ことが別途求められているため、審査担当者向けの手順やデモアカウントは公開ノートではなくそちらに記載しましょう。メタデータについて問い合わせを受けた場合は、App Storeリジェクトへの対処法のガイドで返信の仕方を解説しています。

他の開発者はリリースノートでどんな問題に遭遇したか？

公開されている事例からは、2種類の失敗が見えてきます。ストアの文字数制限を超えたためにアップロードが拒否されるケースと、修正指示の対象に「What's New」のテキストが含まれる審査リジェクトです。

• CIでのPlayの文字数制限。 FlutterデプロイテンプレートのGitHub issueでは、AIが生成した変更履歴によって、fastlane経由のGoogle Play内部テストへのアップロードが「The release created has notes in language ko-KR with length 612, which is too long (max: 500).」というエラーで失敗したと報告されています。メンテナーは、アップロード前にノートを切り詰めるスクリプトを追加しました。Playは480文字、TestFlightは上限をバイト単位で計るため3,800バイトです。
• 「What's New」を含む2.3.10の修正指示。 ある開発者がApple Developer Forumsに、スクリーンショット内のiOS以外のステータスバーが原因となったガイドライン2.3.10のリジェクトを投稿しました。Appleが示した次のステップには「remove all instances of this information from your app and its metadata, including the app description, promotional text, What's New info, previews, and screenshots（アプリの説明、プロモーション用テキスト、What's Newの情報、プレビュー、スクリーンショットを含め、アプリとそのメタデータからこの情報をすべて削除すること）」と書かれていました。返信では、スクリーンショットを撮り直し、リリースノートを含むすべてのメタデータ欄を確認するよう助言されています。

教訓：文字数制限は機械的なもので、アップロード時にはっきりエラーになります。一方、審査ルールは内容に関するもので、すべてのメタデータ欄に適用されます。文字数チェックは自動化し、「What's New」はスクリーンショットと同じくらい丁寧に読み返しましょう。

リリースノートを提出する前に何を確認すべきか？

提出前に、ノートがビルドに含まれる内容だけを説明していること、各ストアの制限に収まっていること、すべての言語で前回のテキストが置き換えられていることを確認しましょう。

• 見出しで、最も多くのユーザーが気づく変更を伝えている。
• ガイドライン2.3.12の要求どおり、重要な機能や製品の変更がすべて記載されている。
• 各修正が、内部コードではなくユーザーが遭遇した症状を説明している。
• フラグで隠された機能、将来の約束、社内のチケット番号、他プラットフォームの名称が含まれていない。
• すべてのローカライズで前のバージョンの「What's New」のテキストが消去され、置き換えられている。
• Playのノートが言語ごとに500文字未満で、正しい言語タグで囲まれ、宣伝や行動の呼びかけが含まれていない。
• Appleでは、マーケティングメッセージをプロモーション用テキストに移している。
• Androidのテスターも運用している場合、同じノートをクローズドテストの計画と照らし合わせて確認している。

提出前にアップデートのメタデータを第三者の目で確認してほしい場合は、ノートの下書きとビルドに含まれる変更の一覧を添えてyagyeshsrbobde@gmail.comまでメールするか、サービスをご覧ください。