リリースの直前、コードはもう動いているのに、App Store と Google Play の「このバージョンの新機能」欄が真っ白なままで手が止まる—個人でアプリを出していると、毎回ぶつかるあの瞬間です。私自身、リリースのたびに 30 分以上かけて文章をひねり出し、英語版に至っては「とりあえず Google 翻訳でいいか」と妥協してきました。
Antigravity を本格的に使い始めてから、この「最後の数十分」が大きく短くなりました。コミット履歴を渡し、対象読者と文字数制限を伝えるだけで、日本語と英語のリリースノートが同時に出てきます。ここでは個人開発者の現実に即した形で、5 分で日英 2 言語のリリース文を仕上げるための具体的な手順をご紹介します。
コミット履歴を「読まれる文章」に変えるための前提
Antigravity は与えられた素材の質に大きく結果が左右されます。リリースノート生成で結果が安定しないときの原因は、ほぼ毎回コミットメッセージ側にあります。
最低限揃えておきたいのは次の 3 点です。
- コミットメッセージは Conventional Commits 形式（
feat:fix:perf:refactor:等）に揃える - ユーザーに見える変更は
feat:かfix:、内部リファクタリングはrefactor:で明確に分ける - 1 リリースに含まれるコミットの範囲を
git logで取り出せるよう、リリースごとに Git タグを打つ
タグを打っておくと、次のように前回タグから現在までの差分だけを切り出せます。
# 直近のタグから HEAD までのコミットメッセージを取得
git log v1.4.0..HEAD --pretty=format:"- %s%n%b" --no-merges > /tmp/release-commits.txt
# 期待出力（例）
# - feat: ホーム画面に最近開いた壁紙の履歴を追加
# - fix: iPad Pro でツールバーの位置がずれる不具合を修正
# - perf: 画像のプリフェッチを 30% 高速化
# - refactor: 設定画面のデータ層を整理ここまでが整っていれば、後は Antigravity に「ユーザーに見える変更だけ」を残してもらう作業に集中できます。
日英 2 言語を 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 つの制約を明示している点です。Antigravity に限らず AI を使った文章生成全般に言えることですが、制約を増やすほど出力の個性が立ち、テンプレ感のある文章を避けられます。
私が「英語版にしてください」と一言だけ追加するのではなく、最初から「friendly tone」「under 500 characters」と書く理由は、英語版の文章量が日本語の 1.5〜2 倍に膨らみがちだからです。文字数制限を伝えないと、Google Play で許される 500 文字を簡単に超えてしまいます。
App Store / Google Play の文字数制限に合わせて削る
生成された文章は、そのままでは長すぎることが多いです。手元の感覚値ですが、各ストアの「このバージョンの新機能」欄に対する目安は次の通りです。
- App Store の
What's New: 4,000 文字まで入るが、実際は 最初の 100 文字以内に要点を入れる（折りたたみ表示の都合） - Google Play の
What's new: 500 文字以内（ハードリミット） - アプリ内 What's New ダイアログ: 3 行 + 1 ボタン が現実的な上限
このため、Antigravity に削り直しを依頼する 2 段階目のプロンプトが効いてきます。
今の日本語版を、最初の 80 文字で要点が伝わるように書き直してください。
冒頭の 1 文だけで「このアップデートで何が嬉しいか」が分かる構成にしてほしいです。
削った部分は、その後に短く補足する程度で構いません。
英語版も同様に、最初の 100 文字で要点が伝わるよう書き直してください。「冒頭で要点」というルールは、リリースノートに限らずアプリ内のお知らせ・プレスリリース・ブログ全般に応用できます。Antigravity に何度も同じ指示を出すのが面倒になってきたら、後述の Custom Command としてプロジェクト内に保存しておくのがおすすめです。
SNS 投稿とアプリ内バナーへの派生
リリース文ができたら、同じ素材を使って SNS 投稿とアプリ内バナーまで一気に作ってしまうのが時短のコツです。
今書いてもらった日本語と英語のリリースノートをベースに、
以下を派生させてください。
1. X (旧 Twitter) 用の投稿（日本語 140 文字以内・絵文字 1 個まで・ハッシュタグ 2 個）
2. X 用の英語投稿（English, under 280 characters, max 1 emoji, 2 hashtags）
3. アプリ内バナー用の文章（タイトル 20 文字 + 本文 60 文字、日英それぞれ）
X 投稿は「使ってみて気持ちが動くポイント」を 1 つだけ強調してください。
全部の機能を詰め込まず、1 番目立たせたい 1 件に絞ります。私はここまでの 3 つのプロンプト（生成 → 削り直し → 派生）を、Antigravity の同じ会話セッションで連続実行しています。文脈が引き継がれているので、毎回アプリの説明をやり直す必要がありません。
派生のときに「全部の機能を詰め込まず、1 番目立たせたい 1 件に絞る」と明示するのは、AI に任せると平等に扱おうとして印象が薄くなりがちだからです。これは個人の経験で、ストア最適化（ASO）の文脈でもよく言われている原則と一致します。
同じ作業を毎回やらないために — Custom Command 化する
毎リリース同じプロンプトを貼り付けるのは、3 回目くらいで限界が来ます。Antigravity の Custom Commands を使うと、このワークフロー全体を 1 コマンドにまとめられます。
プロジェクト直下に .antigravity/commands/release-notes.md のようなファイルを作り、上記の 3 つのプロンプトを順序付きで記述しておきます。
# /release-notes
直近のリリースタグから現在までの変更を、
日英 2 言語のリリースノートと SNS 投稿に変換するコマンドです。
## Step 1: 素材の準備
```bash
git log $(git describe --tags --abbrev=0)..HEAD --pretty=format:"- %s%n%b" --no-mergesStep 2: リリースノート生成
（上記「日英 2 言語を 1 つのプロンプトで生成する」のテンプレートをそのまま）
Step 3: 文字数最適化
（上記「App Store / Google Play の文字数制限に合わせて削る」のプロンプト）
Step 4: 派生コンテンツ
（上記「SNS 投稿とアプリ内バナーへの派生」のプロンプト）
Custom Commands の詳しい作り方は Antigravity の Custom Command を使いこなすマスターガイド で詳しく解説していますので、まだ使ったことがない方はそちらも併せてご覧ください。
## 今日のリリースから始められる小さな一歩
リリースノートのワークフロー全体を最初から完璧に整える必要はありません。今日のリリースで試すなら、最初のプロンプト（コミット履歴を渡して日英 2 言語を生成する部分）だけで十分に効果を実感できます。
具体的には、次のリリース直前に `git log` を 1 回 Antigravity に流し込んでみてください。出力をそのまま使うのではなく、自分の言葉で 1〜2 か所だけ書き換える、という使い方がおすすめです。AI が出した文章を 100% 採用すると、どうしてもテンプレ感が残ります。最後に「自分の声」を 1 行入れるだけで、ユーザーに届く印象が大きく変わります。
リリース文を書く時間が短くなれば、その分だけ次の機能の設計やユーザーフィードバックの読み込みに時間を回せます。個人開発で一番貴重なのは、コードを書く時間ではなく「次に何を作るか考える時間」だと、私は感じています。
マーケティング章にある「価値の言語化」のフレームワークは、リリース文の冒頭 1 文をどう書くかという問いに直接効きます。