ビルドは通り、バイナリのアップロードも終わったのに、App Store Connect の「このバージョンの新機能」欄だけが真っ白なまま、手が止まってしまう夜があります。個人でアプリを出していると、リリースのたびにあの数分間がやってきます。
私は壁紙アプリのストア文を日本語と英語で書いてきましたが、最初のうちは日本語を書き終えた時点で力尽き、英語は機械翻訳をほぼそのまま貼っておりました。結果は芳しくありませんでした。英語の説明が硬く、日本語のやわらかさがそっくり抜け落ちていたのです。
最初にお伝えしたいのは、Antigravity に「リリース文を書いて」と丸投げしても、読まれる文章にはならないということです。効いたのは、材料の質を整える側と、制約を明示する側の両方を、人が握っておくことでした。以下、私が実際に回している手順を書き残します。
材料を整える: コミットメッセージとタグ
リリースノートの出来は、ほとんどコミットメッセージで決まります。生成結果が安定しないとき、原因は指示文より、素材のコミット履歴にあることが多いと感じています。
最低限、次の 3 点を揃えておくと、後の工程がぐっと楽になります。
- コミットメッセージを Conventional Commits 形式（
feat:fix:perf:refactor:など）にそろえます - ユーザーに見える変更だけを
feat:かfix:に寄せ、内部の整理はrefactor:かchore:に分けます - リリースのたびに Git タグを打ちます
タグがあれば、前回リリースから今までの差分だけを切り出せます。
# 直近のタグから HEAD までのコミットメッセージをファイルに書き出す
git log v1.4.0..HEAD --pretty=format:"- %s%n%b" --no-merges > /tmp/release-commits.txt
# 出力イメージ（例）
# - feat: ホーム画面に最近開いた壁紙の履歴を追加
# - fix: iPad Pro でツールバーの位置がずれる不具合を修正
# - perf: 画像のプリフェッチを改善
# - refactor: 設定画面のデータ層を整理ここまで整えば、あとは「ユーザーに見える変更だけを、ユーザーの言葉で」という一点に集中できます。
日英を 1 つのプロンプトで下書きする
私は Antigravity の入力欄に、毎回ほぼ同じひな型を貼っています。コミット一覧は @file で読み込ませています。貼り付けでも動きますが、長くなると直しにくいからです。以下のアプリ名と説明は、例として置いた架空のものです。
@/tmp/release-commits.txt
このアプリは「壁紙ノート」という、写真から着想を残すための
iPhone / Android 両対応のメモアプリです（例）。
読者は技術者ではなく、写真とアートが好きな一般のユーザーです。
上のコミット履歴から、App Store と Google Play 用のリリースノートを
次のルールで下書きしてください。
1. 日本語版（200 文字以内、句点で終わる文章）
2. 英語版（English, under 500 characters, friendly tone）
3. 内部の整理（refactor:）はユーザーに見えないので除外
4. API・リポジトリなどの専門用語は使わず、できる動作で書く
5. 箇条書きではなく、3〜4 文の自然な文章
6. 最後に「これでユーザーの使い心地がどう変わるか」を 1 文だけ入れる
出力形式:
【JA】
（本文）
【EN】
（English text）効いているのは、文字数・専門用語の禁止・「機能ではなく体験で語る」という 3 つの制約を、最初から明示している点です。制約が増えるほど、出力に手触りが残ります。
英語版の長さを最初から指定するのにも理由があります。英語は日本語より文字数が膨らみやすく、指定しないと Google Play の「新機能」欄の上限（500 文字）を、うっかり越えてしまうのです。
ストアごとの文字数に合わせて削る
下書きは、たいてい長すぎます。確認しておきたい上限は次のとおりです。数値は私が手元で確認した時点のものですので、リリース前に各ストアの最新の案内もご覧ください。
- App Store の「新機能」: 最大 4,000 文字。ただし長文は折りたたまれて表示されることが多いので、冒頭の 1〜2 文に要点を置くのが安全です
- Google Play の「新機能」: 500 文字以内
- アプリ内のお知らせダイアログ: 数字の決まりはありません。私は 3 行とボタン 1 つに収まる量を目安にしています
そこで、2 回目のプロンプトで削り直します。
今の日本語版を、最初の 80 文字で要点が伝わるように書き直してください。
冒頭の 1 文だけで「このアップデートで何が嬉しいか」が分かる構成にします。
削った内容は、その後ろに短く補足する程度で構いません。
英語版も、最初の 100 文字で要点が伝わるように書き直してください。「冒頭で要点」は、リリースノートに限らず、アプリ内のお知らせやブログの導入にも使える型です。同じ指示を 3 回続けて打つようになったら、保存しておく合図だと考えています。
同じ素材から SNS 文とバナー文へ広げる
リリース文が固まったら、文脈が残っているうちに、周辺の文章も同じ会話で作ってしまいます。
今作った日英のリリースノートをもとに、次の 3 つを作ってください。
1. X 用の日本語投稿（140 文字以内、絵文字は 1 個まで、ハッシュタグ 2 個）
2. X 用の英語投稿（English, under 280 characters, max 1 emoji, 2 hashtags）
3. アプリ内バナー文（タイトル 20 文字・本文 60 文字、日英それぞれ）
X の投稿では、「使ってみたくなる点」を 1 つだけ強調してください。
全部の機能を詰め込まず、いちばん見せたい 1 件に絞ります。私は「生成 → 削り直し → 派生」の 3 本を、同じ会話の中で続けて流しています。アプリの説明をやり直さずに済み、日英と各媒体の調子も揃います。
1 件に絞らせるのは、任せると全部を平等に扱って、印象が薄くなりがちだからです。これは私自身が何度か試して感じたことで、一般則として言い切れるものではありません。
保存して使い回す
毎回同じ文面を貼る作業は、3 回目あたりで億劫になります。ここは正直に書いておきますが、Antigravity でプロンプトを保存して呼び出す仕組みは、お使いの版や画面によって名前も置き場所も異なります。以前の私は置き場所を決め打ちで書いてしまい、その通りに動かない方がいらっしゃる可能性がありました。
そこで、いまは次のように切り分けています。
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
リポジトリ内の Markdown にひな型を置き、毎回 @file で読ませる | どの版でも確実に使いたいとき | 貼る手間は 1 行に減ります |
| Antigravity のスラッシュコマンドやスキルに登録する | 毎リリース同じ流れで回すとき | 置き場所と書式は、お使いの版の公式ドキュメントで確認してください |
指示をどこに置くかの考え方は、Rules と Skills のどちらに書くか迷ったときにまとめました。リリース文のひな型は、毎ターン載せる Rules よりも、必要なときだけ呼ぶ側に置くほうが私には合っていました。
次のリリースで試す小さな一歩
全部を最初から整える必要はありません。次のリリース直前に、git log の出力を 1 回だけ Antigravity に渡し、日英の下書きを出してみてください。
出力はそのまま使わず、1〜2 か所を自分の言葉に直します。AI の文章を丸ごと採用すると、どうしてもテンプレ感が残るからです。ここまで来て、ようやく私は、下書きは AI が、最後の 1 行は自分が。 という線引きに落ち着きました。
リリース文に取られる時間が減れば、次に何を作るかを考える時間が増えます。個人開発でいちばん貴重なのは、コードを打つ時間よりも、その時間なのだと、いまも感じています。