[Google Play] リリースノート500文字制限と多言語トリミング戦略

概要

Google Play Console のリリースノート(What’s new)フィールドには、言語ごとに 500文字 の上限があります。英語で変更点を1行ずつ全部書いていくと、この上限を簡単に超えてしまいます。上限を超えたまま fastlane supply などの自動アップロードツールでリリースしようとすると、アップロード自体が失敗するため、ノート作成段階で上限を意識する規律が必要です。

このブログでは、韓国語ノートを512文字から482文字へ、英語ノートを890文字から406文字へ圧縮した実例をもとに、多言語リリースノートを上限内に収めるためのトリミング戦略を整理します。

Google Play のリリースノート500文字制限

Google Play Console の「What’s new in this release」フィールドは、言語ごとに最大500文字(空白・改行を含む)まで許可されます。上限を超えると Console の UI で即座に赤い警告が表示され、fastlane / Play Developer API でアップロードすると次のようなエラーで失敗します。

The release notes for language 'en-US' are too long. Limit is 500 characters.

各言語のノートは 独立して 上限が適用されます。韓国語ノートが上限を満たしていても英語ノートが超えていればリリース自体が拒否されるため、全言語を同時に検証する必要があります。

多言語ノートの文字数の非対称

韓国語と英語を同時に運用していると、同じ意味を表現しても英語の方がはるかに長いという事実によく直面します。次は同じ変更内容を1行で書いた場合の比較です。

# 韓国語(1行)
복습 결과 화면에서 정답 단어의 한자 상세 정보를 바로 확인할 수 있도록 개선했습니다.
# → 約42文字

# 英語(1行)
Improved the review result screen to let you view kanji details of the correct word directly.
# → 約95文字

英語は韓国語のおよそ2〜2.5倍の長さになります。結果として、項目数が増えるほど英語側が先に上限を突破します。実例でも韓国語ノートは12項目で512文字(上限を少し超える)でしたが、英語ノートは同じ12項目で890文字(上限の1.78倍)でした。

この非対称はノート作成パターンにそのまま影響します。

韓国語: 項目を1〜2個削れば上限を満たせる → 「1行 = 1項目」原則を維持
英語: 項目を削るだけでは足りない → 関連項目を まとめてグルーピング する必要がある

文字数のカウント方法

まず、現在のノートが何文字なのかを正確に把握する必要があります。macOS / Linux の wc -m は改行を含む文字数を出力するため、上限検証にそのまま使えます。

# 言語ごとの文字数
for f in release_notes/*.txt; do
  printf "%-25s %4d chars\n" "${f}" "$(wc -m < "${f}")"
done

出力例:

release_notes/en.txt       890 chars
release_notes/ja.txt       431 chars
release_notes/ko.txt       512 chars

wc -c (バイト数) ではなく wc -m (文字数) を使うことで、韓国語・日本語のマルチバイト文字を1文字として数えます。UTF-8 環境ではロケールが英語の場合に wc -m がバイト数を返すことがあるため、LANG=en_US.UTF-8 のような UTF-8 ロケールが設定されているかを確認します。

トリミング戦略

500文字に収める作業は、単に項目を削るのではなく、ユーザー価値をできるだけ維持しながら長さを減らす編集作業です。2つの戦略を組み合わせて使います。

戦略 1. ユーザー体感の低い項目を削る

韓国語のように上限をわずかに超えた場合は、項目を1〜2個削るのが最も簡単な解決策です。どの項目を削るかは次の優先順位で判断します。

他言語のユーザーには影響しない、locale 固有の変更 を最優先に候補に入れる。
ユーザーが直接認識しづらい内部変更(ラベル表記の統一、文言の微調整など)を優先して削る。
バグ修正項目 はできる限り残す。リリースノートは、ユーザーが「今回のバージョンで自分の問題が解決されたか」を確認するチャンネルでもあるためです。

実例でも、韓国語ノートからは 한국어 문제 유형 라벨 표기 형식을 통일했습니다. (「韓国語の問題タイプラベル表記形式を統一」)という項目を削除しました。ko 固有の変更で、かつユーザーがラベル形式の違いを明示的に認識しづらいという2つの条件を満たすためです。

戦略 2. 関連項目をグルーピング

英語のように上限の1.5倍以上を超えた場合は、項目を削るだけでは足りません。意味的に関連する複数項目を1行にまとめて圧縮します。グルーピングの基準は次の通りです。

機能単位でまとめる: 「復習画面に関する新規オプション3つ」 → 1行
プラットフォーム単位でまとめる: 「iOS オーディオ関連の修正3つ」 → 1行
カテゴリ単位でまとめる: 「互換性 / 安定化 / クラッシュ修正」 → 1行

実例で英語ノートは12項目890文字から6項目406文字に圧縮されましたが、変換パターンは次の通りでした。

# Before — 項目ごとに1行
- Added per-quiz-type descriptions and display options to the review screen.
- Improved the review result screen to let you view kanji details of the correct word directly.
- Added an option to hide the pronunciation under the speaker in listening quiz types.

# After — 機能単位でグルーピング
- New review options: per-quiz-type descriptions, kanji details on correct answer,
  listening pronunciation hide.

# Before — iOS オーディオ関連3つを別々に記載
- Improved the voice filter to make more voices available on iOS.
- Fixed an issue on iOS where audio could cut off during auto-repeat playback.
- Fixed an issue where ads containing speech blocked the app's voice.

# After — プラットフォーム単位でグルーピング
- iOS audio: more voices, no auto-repeat cut-off, ad blocking fix.

グルーピングは情報を失わずに長さを半分以下に減らせる強力な手法です。ただし、まとめすぎると1行が抽象的になり、ユーザーが何が変わったか把握しづらくなるため、「1行に3〜4項目」程度を上限にするのが良いです。

CI に文字数検証ゲートを追加

500文字制限を毎回人間がチェックすると漏れが発生します。CI 段階で全言語のリリースノートの長さを自動検証するゲートを追加すれば、リリースワークフローがトリガーされる前に上限超過を検出できます。

#!/usr/bin/env bash
# scripts/verify_release_notes_length.sh

LIMIT=500
FAIL=0

for f in release_notes/*.txt; do
  len=$(wc -m < "${f}")
  if [ "${len}" -gt "${LIMIT}" ]; then
    echo "FAIL: ${f} ${len} chars (> ${LIMIT})"
    FAIL=$((FAIL + 1))
  else
    echo "OK:   ${f} ${len} chars"
  fi
done

if [ "${FAIL}" -eq 0 ]; then
  echo "RESULT: PASS"
  exit 0
else
  echo "RESULT: FAIL (${FAIL} files over limit)"
  exit 1
fi

GitHub Actions ワークフローでは、リリースビルドの直前にこの検証ステップを配置します。

# .github/workflows/release_android.yml
- name: Verify release notes length
  run: bash scripts/verify_release_notes_length.sh

こうしておけば、誰かがノートに新しい項目を追加して上限を超えたままマージしても、リリースが進む前に CI で失敗します。すでにタグを push した後の fastlane 段階で上限超過に気づくよりも、はるかに早くフィードバックを受けられます。

まとめ

Google Play の言語ごと500文字制限は、リリースノートを自動化する過程で頻繁に直面する制約です。本ブログで扱った内容を要約すると次の通りです。

上限は言語ごとに独立して適用されるため、全言語を同時に検証 する必要がある。
英語は韓国語 / 日本語に比べて同じ意味を表現するのに約2倍の長さが必要なため、韓国語が通っても英語が上限を超えるパターン がよくある。
文字数は wc -m で正確に数えられる。UTF-8 ロケールを確認する。
上限を少し超える場合: ユーザー体感の低い項目(locale 固有、内部変更)を優先して削る。
上限の1.5倍以上超える場合: 関連項目を機能 / プラットフォーム / カテゴリ単位でグルーピング する。1行に3〜4項目までが無理のない上限。
毎回手動で数えるのではなく、CI に文字数検証ゲートを追加 してリリースが進む前に上限超過を検出する。

リリースノートは、新しいバージョンで何が変わったかをユーザーに伝える最も直接的なチャンネルです。500文字の中で情報価値を最大化する作業は、単なる長さ削減ではなく、変更内容の優先順位をユーザー視点から再整理する機会 だと考えると良いでしょう。

アプリ広報

今見てるブログを作成たDekuが開発したアプリを使ってみてください。
Dekuが開発したアプリはFlutterで開発されています。

興味がある方はアプリをダウンロードしてアプリを使ってくれると本当に助かります。

[Google Play] リリースノート500文字制限と多言語トリミング戦略

Google Play のリリースノートには言語ごと500文字の制限があります。韓国語・英語のノートが制限を超えた実例をもとに、どの項目を削り、どのようにグルーピングして圧縮したか、実践的なトリミング戦略を整理します。

目次

概要

Google Play のリリースノート500文字制限

多言語ノートの文字数の非対称

文字数のカウント方法

トリミング戦略

戦略 1. ユーザー体感の低い項目を削る

戦略 2. 関連項目をグルーピング

CI に文字数検証ゲートを追加

まとめ

関連資料

アプリ広報