変更履歴

リリースノートを通常のコンテンツファイルとして書くか、GitHub Releases から取得すると、Blume がタイムラインページと RSS フィードを自動的に構築します。

Blume には変更履歴が標準で用意されています。各リリースを通常のコンテンツファイルとして書き、type: changelog を指定するだけで、Blume がすべてのエントリを収集して生成されたインデックスページと RSS フィードにまとめます — レイアウトを構築する必要も、リストを管理する必要もありません。あるいはファイルを一切用意せず、GitHub Releases から変更履歴を取得することもできます。

エントリを書く

変更履歴のエントリは、フロントマターに type: changelog を持つ通常の .md または .mdx ページです。慣例として changelog/ 配下に配置しますが、重要なのはフォルダではなく型です:

---
title: v1.2.0
type: changelog
date: 2026-06-20
changelog:
  version: 1.2.0
  category: Features
---

A big batch of components landed this release — columns, frames, trees, and tooltips, plus code groups that render as proper language tabs.

- New `Accordion`, `Expandable`, and `Tooltip` components
- `CodeGroup` tabs with flush code blocks

インデックスとフィードが新しい順に並ぶよう、すべてのエントリに date を指定してください。クォートなしの YAML 日付でも問題ありません — Blume が正規化します。

changelog オブジェクト

任意の changelog オブジェクトは、インデックスとフィードにより豊富なメタデータを追加します:

インデックスページ

type: changelog のエントリが 1 つでもあれば、Blume は /changelog ページを自動的に生成します。サイドバーや目次のない、集中しやすい全幅のインデックスで、すべてのリリースを 1 行ずつ、新しい順かつ年ごとにグループ化して一覧表示します。そのため長い履歴も短いページに収まります（エージェントが 1 つのコンテキストウィンドウで読み取れるサイズを大きく下回ります）:

• エントリのタイトルが行のラベルになります — タイトルがない場合は v{version} です。そのエントリ自身のページへリンクしており、リリースノートはそこで全文がレンダリングされます。
• category はタイトルの隣にタグとしてレンダリングされるため、読者はリリースとプレリリース、あるいは機能追加と修正を一目で区別できます。
• 日付は設定された dateFormat に従いますが、行のグループですでに表示されている年は省略されます。
• 下書きと sidebar.hidden のエントリはスキップされます。

このページの見出しは Changelog（英語）で、その下に 1 行の説明が表示されます。設定ファイルの changelog で独自のものを指定できます。これらはページの <title>、メタディスクリプション、OG カード、そして /changelog.md にある Markdown ミラーの冒頭にも使われます:

changelog: {
  title: "Release notes",
  description: "Every Acme SDK release, newest first.",
},

どちらも、ヘッダータブのラベルと同様に、ロケールコードからテキストへのマップも受け付けます。インデックスはデフォルトのロケールでレンダリングされるため、そのロケールのエントリが表示されます。どちらかを未設定のままにすると組み込みのテキストが維持され、それは UI 文字列のオーバーライド（i18n.ui 配下の changelog.title と changelog.description）で置き換えられます。

このページは /changelog ルートが他に占有されていない場合にのみ表示されます。

独自のインデックスを書く

一覧の上に何か — 導入文、フィードへのリンク、リリースサイクルについての注記など — を置きたい場合は、ページを自分で書き、一覧を表示したい位置に <Changelog /> を配置してください。一覧は引き続き Blume が受け持つため、自分で書くのは一覧の枠に収まらない部分だけです:

---
title: Changelog
description: Every Acme SDK release, newest first.
mode: center
---

Every release, newest first. Subscribe to the [RSS feed](/changelog/rss.xml) to follow along.

<Changelog />

/changelog にあるコンテンツページがルートを引き継ぐため、生成されたページは表示されなくなり、代わりにあなたのページがレンダリングされます。サイドバーの Changelog グループがこのページにリンクするよう、エントリと同じフォルダ内の changelog/index.mdx に配置してください — フォルダの隣に changelog.mdx を置くと、サイドバーに 2 つ目の Changelog 項目が追加されてしまいます。mode: center を指定すると、生成されたページと同じレイアウト（サイドバーも目次もない、より幅の広い中央寄せのカラム）になります。また、生成されたページも同じコンポーネントをレンダリングしているため、両者の内容がずれることはありません。一覧はエージェント向けの出力（/changelog.md、llms-full.txt、MCP の get_page、検索）では、生成されたページとまったく同じように Markdown に変換されます。

タグをどこに置いても、一覧には常にデフォルトロケールのエントリが表示されます — これは一覧を公開するすべての出力がすでに従っているルールであり、翻訳されたページでも、どのリリースが存在するかについて食い違うことなく同じリリースが一覧表示されます。日付はそのページ自身の言語で表示されます。

ページを完全に置き換える

コンポーネントでは表現できないデザインにしたい場合は、pages/changelog.astro にカスタムページを追加してください — それが優先され、Blume はデフォルトのインデックスの生成を停止します。以前のタイムラインの構築に使われていた <Update> コンポーネントは、リリースノートをインラインで表示したいカスタムページ向けに引き続き提供されています。これは MDX コンポーネントには含まれていないため、.astro ページ自体でインポートしてください: import Update from "blume/components/content/Update.astro";。

一覧を自分で構築するということは、<Changelog /> が行っている処理を再現することを意味し、その中には気づかないうちに失敗するものが 1 つ含まれます: ファイルシステム以外のソース（GitHub Releases など）からのエントリは並行する staged コレクションを通じてレンダリングされるため、getCollection("docs") だけを読み込むページにはそれらが 1 つも表示されず、警告も出ません。本当に異なるマークアップが必要な場合を除き、コンテンツページで <Changelog /> を使うことをおすすめします。

GitHub Releases から

エントリを手作業で書く代わりに、組み込みの githubReleases() ソースをリポジトリに向ければ、すべてのリリースが type: changelog エントリになります — 同じタイムラインとフィードが、すでに公開しているリリースから直接供給されます。Blume 自身の変更履歴もこの方法で構築されています:

import { filesystem, githubReleases } from "blume/sources";

content: {
  sources: [
    filesystem({ root: "content" }),
    githubReleases({
      prefix: "changelog",
      owner: "acme",
      repo: "sdk",
    }),
  ],
}

リリース名がタイトルになり、そのタグが changelog.version になり、公開日でタイムラインがソートされます。各リリースページには、そのノートから要約された固有のメタディスクリプションも付与されます — マークダウンを除去し、セクション見出しと changeset のコミットハッシュ接頭辞を削除し、blume audit がチェックする検索スニペットの長さに切り詰めたもので、サイトの説明にフォールバックすることはありません。プライベートリポジトリは GITHUB_TOKEN 環境変数で認証します。すべてのオプションについてはGitHub Releasesを参照してください。

エントリをサイドバーから除外する

変更履歴のエントリは通常のページなので、生成されたサイドバーには他のページと同様に一覧表示されます。changelog/ フォルダ、または prefix: "changelog" を指定した githubReleases() ソースは Changelog グループになり、最新のエントリが先頭に並び、リリースのたびに増えていきます。前へ/次へのリンクもこのグループを通るため、ドキュメントの最後のページから最新のリリースへと続くことがあります。

エントリをドキュメントのサイドバーから除外するには、ヘッダーアクションではなくヘッダーのタブで変更履歴にリンクしてください:

navigation: {
  tabs: [
    { label: "Docs", path: "/" },
    { label: "Changelog", path: "/changelog" },
  ],
}

/changelog タブはインデックスを開き（href は不要です）、changelog/ セクションを受け持ちます。このセクション外のページにはリリースが一覧表示されなくなり、それらのページの前へ/次へのリンクはドキュメント内にとどまります。エントリ自身のページでは、リリースの一覧がサイドバーとして表示されます。インデックス、RSS フィード、llms.txt、サイトマップ、検索には引き続きすべてのエントリが掲載されます。タブの path は、エントリが配置されているフォルダまたは prefix と一致している必要があります。/ の Docs タブは任意で、読者が戻るためのタブになります。

エントリに sidebar.hidden を設定しても同じ効果は得られません。インデックスやフィードを含むすべての場所でエントリが非表示になってしまいます。

RSS フィード

Blume は /changelog/rss.xml に変更履歴フィードも構築し、date の新しい順にソートします。フィードには絶対的なサイト URL が必要なので、deployment.site を設定してください。その後 Blume がすべてのページに <link rel="alternate"> タグを挿入し、読者が自動的に見つけられるようにします。

フィードはデフォルトで有効です。seo.rss で調整できます:

seo: {
  rss: {
    enabled: true,
    types: ["blog", "changelog"],
    limit: 50,
  },
}

タイムラインを維持したままフィードだけをスキップするには、rss.types から "changelog" を削除してください。

構造化データ

構造化データが有効な場合、各変更履歴エントリは説明と公開日を伴う schema.org の TechArticle として出力されるため、検索エンジンがリリースを日付付きの記事としてインデックスできます。