App Store と Google Play の「新機能 / What's New」欄は、地味で誰も褒めてくれないのに、確実にユーザーの読了率が高い場所です。アーティスト・クリエイターの廣川政樹です。
2014年から個人でアプリを作り続けてきて、最近ようやく自分の中で固まりつつあるのが「リリースノートはアプリ機能の一部として扱う」という考え方です。Rork で並行運用している壁紙アプリ6本について、3週間にわたって「同じ週に同じ温度でリリースノートを揃える」という運用を続けてみました。その所感をまとめます。
なぜわざわざ同期するのか
そもそも、なぜ6本のアプリで What's New を「同期」させる必要があるのか、と疑問に思う方もいるかもしれません。私自身、最初の数年は各アプリそれぞれに思いついたタイミングで書いていました。
ただ、累計5,000万ダウンロードを超えたあたりから、自分のアプリのレビュー欄をまとめて見直す機会が増えました。そこで気づいたのは、同じ作者のアプリでも、リリースノートの「人格」がバラバラだとユーザーが混乱するということです。あるアプリは絵文字だらけで賑やか、別のアプリは事務的に「Bug fixes.」だけ。同じ私が書いたとは思えない温度差でした。
両家の祖父がともに宮大工で、「同じ工房から出るものは、見えない場所まで揃っている」という感覚を子どもの頃から見てきました。リリースノートも同じだと感じます。見えない場所こそ、揃えておく価値があると考えるようになりました。
3週間の運用ルール
具体的なルールはシンプルで、以下の3つだけです。
- 同じ週にビルド可能な改修だけリリースに含める — 1本だけ突出した内容にしない
- What's New の構造を6本で揃える — 「目玉1行」「改善2〜3行」「裏方の改善1行」の3段構成
- 言語は日英を最低限揃え、ローカライズは Rork のテンプレートから機械的に展開する
3週間で、合計18本（6アプリ × 3回）のリリースノートを書いたことになります。最初の週はテンプレートを決めるのに半日かかりましたが、3週目には30分で18本書けるようになりました。
Rork のリポジトリ側で揃えたこと
Rork でアプリを管理しているので、リリースノートも GitHub 上に置いて Pull Request で履歴を残す形にしました。具体的には、各アプリのリポジトリに release-notes/ ディレクトリを切り、以下のような構造で配置しました。
release-notes/
├── 2026-05-08/
│ ├── ja.txt # App Store Japan / Google Play ja-JP
│ ├── en.txt # App Store US / Google Play en-US
│ └── meta.json # ビルド番号・対象アプリ
├── 2026-05-15/
│ └── ...
└── README.md # テンプレートと書き方のルール
meta.json には対象アプリ識別子・バージョン番号・想定リリース日を入れておきます。App Store Connect API を JWT で叩いて What's New を自動投入する仕組みは別途用意していますが、まずは「テキストとして6本揃える」ところまでが今回の運用範囲です。
つまずいた3つの落とし穴
3週間の運用で、想定していなかった落とし穴が3つありました。これは公式ドキュメントには書かれていない実運用での発見です。
1. アプリ固有の機能名が翻訳できない
「お気に入りロック」「シャッフル再生」「壁紙の自動切替」など、6本それぞれに固有の機能名があります。これを英訳するときに、各アプリで揺れが起きました。最初に「機能名辞書」を1つ作り、6本の翻訳がここを参照する形に変えました。これだけで18本のレビュー時間が3割減りました。
2. ビルド番号と What's New のズレ
App Store Connect 側で What's New を保存したあと、ビルドを差し替えると古い What's New が新しいビルドに紐付いてしまうケースがありました。Rork で吐き出したコードをそのまま EAS Build に流すと、ビルド番号は自動採番されますが、What's New は手で同期する必要があります。「What's New を書く → ビルドを送る」という順序を絶対に逆にしないルールを作りました。
3. 同じ温度で書くと作業感が出る
3週目に入ると、テンプレートに慣れすぎて、すべてのリリースノートが事務的になり始めました。これは想定外でした。リリースのたびに、1本だけ「今回特に伝えたい1文」を入れる枠を意図的に作るようにしました。たとえば「春の花の壁紙を50枚追加しました」のように、機械的な改善ログでは出てこない一言を必ず入れます。
数値で見えたこと
3週間運用してみて、目に見えやすい数値変化はまだ大きくはありません。ただ、レビュー1件あたりの平均文字数が、6本平均で 38 → 51 文字に伸びていることに気づきました。
「今回のアップデートで〇〇が改善された」という言及がレビューに増えており、What's New を読んでくれているユーザーが一定数いる、という気配が掴めました。AdMob の eCPM や DAU には3週間では影響は見えませんが、「ユーザーがアプリを開いたまま、What's New を読む時間が増えている」という運用感は確かにあります。
1日4本ペースに耐える設計
私は4つの技術ブログを並行運用しており、Lab 系の記事制作も含めると、毎日複数の「短いテキスト」を出力する生活です。リリースノートはその中でも最も短く、最も読まれる文章です。短いからこそ、書くたびに迷うと運用が崩れます。
3週間試して感じたのは、運用が続くテンプレートには「機械的な部分」と「人間が必ず手で書く1行」が両方必要だということです。全自動化すると人格が消え、全手動だと続きません。リリースノートに限らず、個人開発で6本以上のアプリを並行運用するときに使える原則だと思っています。
これから取り組むこと
次の段階として、以下の3つを試そうとしています。
- App Store Connect API 経由で、Rork リポジトリの
release-notes/から What's New を自動投入する CI ジョブ - 多言語の自動展開（現状は日英のみ、次は中・韓・西・仏の4言語）
- レビュー本文に登場した「機能名」を週次で集計して、次回 What's New に優先反映する仕組み
12年やってきた個人アプリ開発で、自分でも見落としていた地味な領域でした。同じように複数本のアプリを並行運用している方には、まず「What's New を1週間揃える」という小さな実験から試してみることをお勧めします。
お読みいただきありがとうございました。