リリースノートテンプレート

このリリースノートテンプレートは、出荷チームがユーザーに変更内容を伝えるために必要な11のセクションをまとめたものです。サインアップ不要で構成全体をコピーするか、PDFとしてダウンロードできます。

リリースノートテンプレート（そのままコピーして使える）

以下のブロックがテンプレートの全体で、サインアップやメール登録なしにその場でコピーできます。Word、Google Docs、Confluence、Notion、Markdownファイルにそのまま貼り付けても崩れず、印刷したい場合はPDF版にも同じ11セクションが収録されています。角括弧のプロンプトを置き換えたうえで、今回のリリースに関係しないセクションは削除してください。

[製品名] リリースノート
バージョン: [x.y.z]
リリース日: [YYYY-MM-DD]
プラットフォーム / 環境: [web, iOS, Android, API, staging]

変更概要（目的）
[1〜2文: 今回のリリースが対応する内容と、影響を受ける対象]

新機能
- [ユーザーが新たにできるようになったこと。内部の機能名ではなく]

改善・機能強化（パフォーマンスの改善）
- [これまで存在していたもの。ユーザー視点で何が良くなったか]

バグ修正
- 修正: [これまでユーザーが見ていた状態と、今後どうなるか]

破壊的変更と移行手順
- [動作しなくなること]。そのため[何を、いつまでに変更する必要があるか]

既知の問題と回避策（進行中の問題）
- [未解決の問題] ・ [影響を受けるプラットフォーム] ・ [回避策] ・ [修正予定]

アップグレード・インストール手順（アップグレード手順 / インストールに関する注意）
1. [新しいバージョンに移行するためにユーザーが行うべきこと]

非推奨事項
- [機能、連携先、またはAPI]は[日付]に非推奨になります。[移行先]

セキュリティに関する注意事項
- [脆弱性の詳細を説明せず、セキュリティ関連の変更のみを記載]

ヘルプの入手先とフィードバック
- ドキュメント: [リンク] ・ サポート: [メールアドレスまたはチャンネル] ・ フィードバック: [リンク]

リリースノートテンプレートの構成要素

リリースノートテンプレートには11のセクションがあり、それぞれに一つの役割があります。読み手に合わせて書き分けましょう。開発者と顧客では必要とする情報が異なります。

リリースノートテンプレートの使い方

1. テンプレートを、リリース情報がすでにある場所にコピーする。 Jira、Confluence、Notion、GitHub、Azure DevOpsにそのまま貼り付けられるので、ノートが別の場所に散らばらず作業のそばに置かれます。
2. まずヘッダー行を埋める。 製品名、バージョン番号、リリース日、プラットフォームを記入し、ノートを開いた人が本文を読む前にどのビルドの内容かわかるようにします。
3. 出荷ログを集め、ユーザーの目に見えるかどうかで仕分ける。 各変更を新機能、改善、バグ修正、破壊的変更に振り分け、ユーザーから見えない項目は削除します。
4. 各項目は実装内容ではなく、できるようになったこととして書く。 「バッチ処理を実装」ではなく「大量のデータセットをタイムアウトせずにエクスポートできるようになりました」と書けば、このリリースが自分に関係あるかという読み手の疑問に答えられます。
5. UIが変わった箇所にはスクリーンショットや短いGIFを添える。 説明に3段落も必要な項目は、たいてい15秒のGIFで済みます。
6. 今回のリリースに関係しないセクションは削除し、残りは順番どおりに残す。 パッチでは新機能やアップグレード手順のセクションを省きますが、ユーザーがリリースのたびに構成を覚え直す必要がないようにします。
7. ドラフトを担当者一人に引き渡してから公開する。 承認の責任者が一人に定まっていないと、ノートの公開が遅れたり、二重に公開されたりします。

リリースノートテンプレートの記入例

同じテンプレートを、架空の配車・配送プロダクトが機能リリースを出す想定で記入した例です。

• Fieldpost 4.2.0 ・ リリース日: 2026年3月12日 ・ プラットフォーム: WebおよびiOS
• 変更概要: 大規模アカウントでもエクスポートが完了するようになり、カナダの価格表示が正しくなり、セルフホスト管理者には1つの移行手順があります。
• 新機能
• スケジュールエクスポート。 レポートを毎週月曜日に自動実行し、受信箱に届くよう設定できるようになりました。
• 一括ステータス更新。 最大500件のジョブを選択し、一度の操作でステータスを変更できます。
• 改善・機能強化
• ディスパッチボードの高速化。 未処理ジョブ10,000件のアカウントでも、ボードの読み込みが従来の9秒から約2秒に短縮されました。
• バグ修正
• 修正: 50,000行を超えるエクスポートがタイムアウトし、空のファイルが返される問題。
• 修正: カナダのアカウントで価格がUSD表示になっていた問題。
• 破壊的変更と移行手順
• バージョン4.2.0ではv1の/exportsエンドポイントが削除されます。連携先は/v2/exportsに向けてください。こちらはジョブIDを返します。セルフホスト環境では、4.2.0を起動する前にfieldpost migrate --v2-exportsを実行してください。
• 既知の問題と回避策
• iOSでは、日曜日に予定したエクスポートが月曜日に実行されてしまいます。3月26日リリース予定の4.2.1が出るまでは、Webアプリをご利用ください。
• アップグレード・インストール手順
• クラウドアカウントはすでに4.2.0になっています。iOSユーザーは3月31日までにApp Storeからアップデートしてください。
• 非推奨事項
• Fieldpostは2026年9月1日にCSV専用のレポート形式を非推奨とします。保存済みレポートはXLSXに切り替えてください。
• セキュリティに関する注意事項
• セッショントークンは12時間で失効するようになり、管理者は他のユーザーのセッションを終了できるようになりました。
• ヘルプの入手先とフィードバック
• ドキュメント: docs.fieldpost.example ・ サポート: support@fieldpost.example ・ フィードバック: アプリ内のフィードバックタブ

リリースノートテンプレートのバリエーション

以下の5つのバリエーションは、誰が読むかとどんな種類のリリースを扱うかという2つの軸で分かれています。いずれもヘッダー行と変更概要は残したまま、残り9つのセクションを追加・削除・書き換えます。有用なのはこの差分の部分です。小規模なリリースで何を削るかの判断こそ、多くのチームが間違えるポイントだからです。

メジャーリリース向けテンプレート

このバリエーションでは11セクションすべてを使います。新機能ごとに段落とスクリーンショットまたはGIFを添え、移行手順はリンクで済ませず具体的に書き出し、変更概要はそれ単体で成立するように書きます。チームメンバーがSlackに貼り付けて引用する行になるからです。

• 維持: 11セクションすべて。
• 拡張: 新機能、破壊的変更と移行手順、アップグレード手順。
• 注意点: 変更概要は他のセクションを見なくても意味が通る必要があります。

パッチ・ホットフィックス向けテンプレート

主に4つのセクションで成り立ちます: ヘッダー行、変更概要、バグ修正、そして残っていれば既知の問題です。まず修正内容を、次に影響を受ける対象を、最後に読み手が何か対応する必要があるかを書きます。バージョン番号から書き始めて修正内容が3段落目に埋もれているホットフィックスノートは、素早く出す意味を失っています。

• 省略: 新機能、改善、非推奨事項、アップグレード手順。
• 維持: ヘッダー行、変更概要、バグ修正、既知の問題。
• 注意点: 対応が不要な場合はその旨を明記します。

社内・技術者向けテンプレート

このバリエーションはシステムを運用するチーム向けに書くもので、メリットを伝える表現ではなく仕組みそのものを記載します。影響を受けるサービス名、変更した設定内容、そして深夜2時にチームメンバーが遭遇しうる事象を明記します。

• 追加: コード変更、APIおよびデータベースの変更、環境・設定に関する注記。
• 省略: ユーザー向けのメリット訴求表現。
• 維持: 破壊的変更、既知の問題、アップグレード手順。このバリエーションでは他より重みを持ちます。

モバイルアプリストア向けテンプレート

ストア掲載情報には文字数制限があるため、ノート全体をバージョン行と短い「新着情報」リストに圧縮します。3〜5個の箇条書きで、それぞれユーザーが新たにできることを1つずつ挙げ、関心が高い順に並べます。

• 維持: ヘッダー行、圧縮した新機能リスト、注目すべき修正1行。
• 省略: 既知の問題、非推奨事項、セキュリティに関する注意事項、移行手順。
• 注意点: ストア掲載から削った内容も、自社でホストするフルバージョンのノートには残しておきます。

API向けテンプレート

このバリエーションはエンドユーザーではなく、連携を実装する開発者向けに書きます。各項目は関係するエンドポイントやパラメータを明記し、非推奨事項にはカレンダーに登録できる廃止日を添えます。

• 追加: エンドポイントの変更、パラメータの変更、リクエストとレスポンスを含む移行例。
• 拡張: 廃止日付きの非推奨事項、および破壊的変更。
• 省略: 開発者の読み手には不要なスクリーンショットやGIF。

セキュリティパッチは、リリース内容に合ったバリエーションを使いつつ、ひとつだけルールを追加します。セキュリティに関する注記は事実のみとし、脆弱性そのものについては説明しないことです。

リリースノートテンプレートを使うタイミング

ユーザーの目に触れる、またはユーザーが対応する必要のあるすべてのリリースでこのテンプレートを使いましょう。最も多いきっかけは、機能のローンチ、バグ修正・ホットフィックス、社内ビルドの3つです。セキュリティパッチ、APIリリース、ストア更新も同じ構成を使い、使うセクションが変わるだけです。

リリースノート、チェンジログ、パッチノートは、それぞれ異なる問いに答えるものです。リリースノートはリリースごとに作成する、人が読みやすい文書で、変更の影響を受ける相手に向けて書かれます。チェンジログは時系列ですべてを記録した、開発者向けの恒久的な記録です。パッチノートは、修正のみのリリース向けの短いリリースノートです。チーム外の誰かが対応する必要があるときはリリースノートを公開し、その裏でチェンジログを継続的に記録しておきます。

所有権は引き継ぎのかたちで機能します。エンジニアリングが出荷ログを提供し、PMまたはPMMがそれをユーザー向けの項目に翻訳し、名前の決まった一人が公開前に承認します。

白紙の文書は飛ばして、代わりに録画する

白紙のテンプレートを埋める作業は、多くのチームがリリース後まで先延ばしにしがちなステップです。もう一つのやり方は、どのみち行うはずだった操作説明を録画し、それをそのままノートにすることです。

Hinto AIは、Loom、Zoomの通話、YouTube動画、ローカルのMP4など、どの動画ソースでも取り込め、Webアプリまたはchrome拡張機能から画面を録画できます。AIによるアクション検出がUIの状態変化やボタンクリックを識別し、スクリーンショットと手順のテキストを抽出します。この手順がそのまま新機能・改善・バグ修正の項目になり、GIFエンジンがUIの変わった箇所を補います。Hintoには、製品デモからリリースノートを作るための「What's New」プロジェクトテンプレートが用意されています。

そこから先は一から書くのではなく編集するだけです。セクションを選択してAIに書き直しを依頼し、できあがったものをカスタムドメイン付きの公開URLでホストするか、Notion、Confluence、GitHub、GitLabに同期できます。

リリースノートテンプレートに関するFAQ

リリースノートには何を記載すべきですか?

11のセクションです。ヘッダー行、変更概要、新機能、改善、バグ修正、破壊的変更と移行手順、既知の問題、アップグレード手順、非推奨事項、セキュリティに関する注意事項、そしてヘルプの入手先です。変更概要は、ざっと目を通す人が読み、AIエージェントが引用する行です。

良いリリースノートはどう書けばよいですか?

読み手が今できるようになったことから書き始め、実装の詳細は書きません。「バッチ処理を実装」ではなく「大量のデータセットをタイムアウトせずにエクスポートできるようになりました」と書きます。機能名は太字にし、New、Improved、Fixedのラベルを使い、各項目は2〜3文に収めます。

リリースノートは通常誰が書きますか?

プロダクトマネージャーまたはプロダクトマーケティングマネージャーが、エンジニアリングから引き継いだ情報をもとに書きます。エンジニアリングが出荷ログを提供し、PMまたはPMMがそれをユーザー向けの項目に翻訳し、名前の決まった責任者が公開前に承認します。

パッチノートとリリースノートの違いは何ですか?

パッチノートは、修正のみのリリース向けの短い形式です。新機能、改善、非推奨事項、アップグレード手順を省き、修正内容、影響を受ける対象、読み手が対応すべきかどうかから書き始めます。リリースノートは、機能リリース向けにフルの構成を保ちます。

Jiraにおけるリリースノートとは何ですか?

同じ文書を特定の場所に貼り付けたものです。Jira、Confluence、GitHub、Notion、Azure DevOpsについて検索する人は、リリースノートそのものを求めているので、上記のテンプレートをチームが普段読んでいる場所にそのままコピーしてください。Hintoは、Notion、Confluence、GitHub、GitLabへの公開に対応しています。