変更履歴ページの作り方：エントリー、タグ、RSS、「新機能」

変更履歴ページは、製品で何が変わったかを、利用者に向けて新しい順に並べた日付付きのリストです。作るには、日付、分かりやすいタイトル、短い説明、そしてタグ（New、Improved、Fixed）を持つエントリー、それらを並べるページ、エントリーごとに独立したURL、そして可能であればRSSフィードと、新しいことを利用者に伝える仕組みが必要です。作り方の中でもとても簡単な部類ですが、主な判断はエントリーをどこに保存するかです。サイトのファイルとして置くか、管理画面付きのデータベースに置くかです。

変更履歴が役立つ理由

変更履歴は、製品が継続的に手を入れられていることを顧客や見込み客に示します。また、「○○はできますか？」と聞かれたときに、サポートや営業が送るリンクにもなります。フィードバックへの対応を締めくくる場所でもあります。要望された機能がリリースされたら、そのことを伝えるのが変更履歴のエントリーです。顧客フィードバックポータルを運営している場合は、リリース済みの要望からそのエントリーへ直接リンクしてください。

変更履歴は社内のコミット履歴ではありません。「請求サービスをリファクタリング」は利用者にとって意味がありません。「請求書に会社の消費税番号が表示されるようになりました」は意味があります。

ページに必要なもの

エントリーごとの内容

ページ

• 変更履歴の一覧: 新しい順で、タグによる絞り込みと、シンプルなページ送りまたは「もっと見る」を備えます。
• エントリーのページ: エントリーごとに1つのURL。リンクや共有ができるようにします。
• RSSまたはAtomフィード: メールを使わずに、人々やツールが更新を追えるようにします。
• 管理画面（データベース版のみ）: 作成、プレビュー、予約、公開を行います。

アプリ内の補助機能

• 「新機能」バッジ: まだ見ていないエントリーがあるとき、メニュー項目に丸い印を付けます。利用者が最後に開いたエントリーの日付を、利用者ごと、またはブラウザ内に保存します。
• メールのダイジェスト: 受け取りに同意した利用者に送る要約です。メール送信プロバイダーが必要です。アプリからメールを送る方法をご覧ください。

最大の判断：ファイルかデータベースか

サイト内のファイルとしてエントリーを保存する

各エントリーはプロジェクト内のMarkdownファイルです。エントリーを公開するには、ファイルを追加して再デプロイします。データベースもなく、管理画面のログインもなく、守るべきものもないため、最もシンプルで堅牢な方法です。ページを事前レンダリングできるので、表示が速く、検索エンジンにも読まれやすくなります。

エントリーを書く人がAIビルダーに頼むか、ファイルを編集することに抵抗がないチームに向いています。

管理画面付きのデータベースにエントリーを保存する

エントリーはテーブルに保存され、非公開の管理画面で、チームの誰もが書き、プレビューし、予約し、公開できます。マーケティングやサポートの担当者が更新を書くチーム、予約公開が必要なチーム、あるいは顧客のセグメントごとにエントリーを分けたい場合（例：エンタープライズの顧客にだけエンタープライズ向け機能を表示）に向いています。

代わりに、作ることと運用することが増えます。管理画面のログイン、画像のアップロード、そして、ブラウザ内でだけエントリーを読み込むページでは検索エンジンに読まれないおそれがあるため、公開ページがサーバー側でレンダリングされるか、事前レンダリングされていることを確認する必要があります。

読まれるエントリーの書き方

• 利点から書き始める。 「新しいエクスポート機能」より「レポートをExcelに書き出せるようになりました」のほうが伝わります。
• 対象者を明記する。 全プラン向け、Pro限定、今週から順次公開、など。
• 見せる。 1枚のスクリーンショットか短い動画で示します。
• 小さな修正はまとめる。 毎週の「修正と改善」エントリーを箇条書きで作ると、ページが小さな変更で埋まりすぎるのを防げます。
• 機能の削除は正直に伝える。 何かを廃止する場合は、いつ、どの代替を使えばよいかを書いてください。

最初に効くプロンプトの例

サイトの/changelogに、公開の変更履歴を追加してください。各エントリーは、タイトル、日付、タグ（New、Improved、Fixed）、任意のカバー画像、本文を持つMarkdownファイルにします。一覧ページでは、エントリーを新しい順に並べ、日付、タグ、最初の段落を表示します。タグによる絞り込みボタンを付け、1ページに10件表示してください。各エントリーには/changelog/<slug>という独自のページを用意し、検索エンジン向けに適切なページタイトルと説明文を付けてください。/changelog/rss.xmlにRSSフィードを追加してください。サンプルエントリーを3件作ってください。既存のサイトのデザインに合わせ、スマートフォンでも読みやすくし、ページは事前レンダリングして表示を速くしてください。

データベース版の場合は、最初の文を「下書き・公開のステータスと予約公開日を持つエントリーをデータベースに保存し、エントリーを書く、プレビューする、公開するためのパスワード保護された管理画面を追加してください。」に置き換えてください。

構築の手順

1. ファイルかデータベースかを決める。 上の表を参考にします。
2. 一覧ページとエントリーのページを作り、 サンプルエントリーを数件入れます。
3. タグとフィルターを追加する。
4. RSSフィードを追加し、 ページからリンクします。
5. 各エントリーにページタイトル、説明文、サイトマップのエントリーを追加する。 AIで作ったウェブサイトのSEOで基本を確認できます。
6. データベース版を選んだ場合は、管理画面とログインを作る。
7. アプリ内に「新機能」バッジを追加する。
8. 直近数か月分の実際のエントリーを書く。 空っぽの状態で公開しないようにします。

よくある間違い

• コミットメッセージをそのままコピーする。 利用者向けに書いてください。開発者向けではありません。
• エントリーごとのURLがない1枚の巨大なページ。 特定の変更にリンクできず、検索エンジンにもページが1つにしか見えません。
• 1か月で更新が止まる。 1年前に最後に更新された変更履歴は、製品が放置されていると思わせます。続けられるリズムを決めてください。
• ブラウザ内でだけエントリーを読み込む。 検索エンジンやリンクのプレビューには空のページに見えることがあります。事前レンダリングするか、サーバーでレンダリングしてください。
• 障害情報を混ぜる。 障害は、変更履歴ではなくステータスページに掲載してください。

ホスト型の変更履歴ツールのほうが適している場合

ホスト型の変更履歴・製品アップデートツールも存在します。フィードバックボードやアプリ内ウィジェットがセットになっているものもあります。アプリ内のポップアップ、対象者の絞り込み、分析機能を自作せずに使いたい場合や、チームがすでに料金を払っているツールに含まれている場合は、価値があります。ブログやヘルプセンターのソフトウェアにも、適した形式が既にあるかもしれません。

変更履歴を自分のドメインで、自分のデザインで、そして完全に検索可能な形で置きたい場合は、自作が向いています。日付付きの投稿のシンプルな一覧であれば、作る手間はそれほど大きくありません。

Mythexでの構築

Mythexでは、既存のプロジェクトに変更履歴を追加するようエージェントに頼むことも、独立した小さなサイトとして作ることもできます。作られていく過程はライブプレビューで確認できます。ファイル版ならデータベースは不要です。管理画面付きの版を選ぶと、エントリーを保存する必要が出た時点でエージェントが専用のPostgresデータベースを追加します（/databaseと入力することもできます）。スクリーンショットはプロジェクトのファイルストレージに保存されます。管理画面のログインは、自分の認証方式で追加します（ログインを追加するレシピ）。

Mythexで新規に作られるアプリは、クライアント側でレンダリングされるSPAであることが多く、SEOのレシピでは検索に弱いと説明されています。エントリーを検索で見つけてもらいたい場合は、変更履歴のページを静的または事前レンダリングされた形にするよう依頼してください。同じレシピで、タイトル、説明文、サイトマップも扱っています。変更履歴が組み込まれた出発点としては、プロダクトナレッジハブのテンプレートが参考になります。

よくある質問