Astro 6.3 と Starlight 0.39 同時リリース — 受託サイトの並行アップグレード戦略 2026

Astro チームが 2026 年 5 月 7 日に Astro 6.3 と Starlight 0.39 を同時リリースしました。Astro 本体と、ドキュメントサイト向け公式テーマ Starlight が同じ週にバンプされるのは、受託で 「コーポレートサイトは Astro、ドキュメントサイトは Starlight」と分けて運用している現場にとって、並行アップグレードの設計を迫られるイベントです。

弊社のコーポレートサイト（gleamhub.net）も Astro で構築されており、加えて受託で構築した複数のクライアントサイトが Astro / Starlight で動いています。「本体と Starlight を同じ日に上げる」運用は、片方の問題でもう片方のリリースが止まる構造を生むため、受託保守では避けるのが鉄則です。本記事では、Astro 6.3 と Starlight 0.39 をズラして取り込む手順を整理します。

6.3 と 0.39 の主要変更（受託で気にすべき範囲）

公式ブログから、受託で実装に影響しそうな変更を抜粋します。

特に Image Service の出力フォーマット既定切替と Starlight サイドバー自動生成のロジック変更は、コーポレートサイトとドキュメントサイトの両方で 「目視確認が必須」になる変更です。

Astro 6.2 リリースを受託保守に織り込む で扱った 6.x のリリースサイクルが「事実上の四半期メジャー級」になっていることが、この 6.3 でさらに鮮明になりました。

「同じ週には上げない」並行アップグレード手順

弊社の受託保守で実施している、Astro 本体と Starlight をズラして取り込む手順です。

[Week 1] Astro 6.3 をコーポレート / メディアサイトに取り込む
  └ chore/astro-6.3-upgrade ブランチで検証 → 段階リリース
  └ Starlight サイトはこの週は据え置き

[Week 2] Astro 6.3 を Starlight サイトにも取り込む
  └ Starlight 0.38 は据え置きのまま、本体だけ 6.3 に上げる
  └ Starlight 側に互換性問題が出ないか観測

[Week 3] Starlight 0.39 を取り込む
  └ chore/starlight-0.39-upgrade ブランチで検証
  └ サイドバー自動生成の挙動変化を目視確認

[Week 4] バッファ週(障害対応 / ホットフィックス)
  └ 何も予定を入れず、前週までの不具合に当てる

ポイントは 「Astro 6.3 を全サイトに行き渡らせてから Starlight 0.39 を上げる」順序です。逆順にすると、Starlight 0.39 のテーマ拡張 API 変更で動かなくなった原因が、本体 6.3 由来なのかテーマ由来なのか切り分けに時間がかかります。

保守契約のスコープに「並行アップグレード」を明記する

上のズラし手順を実際に回せるかどうかは、Astro のマイナー / メジャー追従と Starlight のメジャー追従が保守契約のスコープに書かれているか次第です。

範囲の区切りが文面に無いと、6.3 と 0.39 が同じ週に出た瞬間に 「これは契約範囲なのか、追加見積なのか」の交渉が始まり、それが片付くまで検証に着手できません。バッファ週どころか Week 1 が交渉で溶けます。逆にスコープが明記されていれば 「契約範囲内なので今週から着手します」と即答でき、リリース週の段取りをそのまま実行できます。

スコープを書くときに効くのは 「どのバージョン階層まで」と **「どのパッケージまで」の 2 軸です。Starlight は Astro 本体とは別のバージョン体系で動くため、「Astro のマイナーまで」**とだけ書くと Starlight 0.38 → 0.39 が範囲外に落ちます。本記事の並行アップグレードは、この 2 つが両方スコープに入っていて初めて成立します。

オウンドメディアの運用費用そのものの相場観は オウンドメディア構築のコスト感 に整理していますが、金額をどう置くにせよ 「アップグレードは事故対応ではなく定例タスク」として契約に内包しておくほうが、事故は確実に減ります。

CI / CD で「並行サイト」をまとめて壊さない設計

受託で複数の Astro / Starlight サイトを抱えると、「1 つの依存更新で全サイトの CI が落ちる」事態が起きやすくなります。これを避ける CI / CD 設計です。

# 共通ワークフロー（GitHub Actions の例）
on:
  pull_request:
    paths:
      - 'package.json'
      - 'package-lock.json'

jobs:
  build-matrix:
    strategy:
      fail-fast: false  # 1 サイトの失敗で他を止めない
      matrix:
        site: [corporate, media, docs-starlight]
    steps:
      - uses: actions/checkout@v4
      - run: npm ci --prefix sites/${{ matrix.site }}
      - run: npx astro sync --root sites/${{ matrix.site }}
      - run: npm run build --prefix sites/${{ matrix.site }}

**fail-fast: falseの設定が肝で、これを忘れると 「コーポレートサイトのビルド失敗で Starlight サイトの確認まで止まる」**ということが起きます。1 つの依存更新は 1 つの PR で複数サイトを並行検証できるようにマトリクスを組むのが受託の標準です。

ハマりやすい 5 つの落とし穴

最後に、Astro 6.3 と Starlight 0.39 を受託で取り込むときに踏みやすい落とし穴を共有します。

落とし穴 1: 同じ日に両方上げる

PR を 1 本にまとめると 「どちらが原因かわからない」事態になります。最低 1 週間ズラすのが鉄則です。

落とし穴 2: AVIF 既定でホスティング側が落ちる

Cloud Storage や CDN の Content-Type マッピングに AVIF が無いと 「画像が表示されない」ことがあります。ホスティング側の MIME タイプ設定を先に確認します。

落とし穴 3: Starlight サイドバー自動生成の差分を見ない

サイドバー順序が変わると 「ドキュメントの読了率が落ちる」ため、astro:assets 配下のスナップショットテストを必ず通します。

落とし穴 4: i18n のデフォルト URL 変更を放置

Starlight 0.39 は多言語デフォルトロケールの URL ハンドリングが変わっています。/ で出ていたパスが /ja/ に動くケースがあるため、リダイレクト設定を必ず追加します。

落とし穴 5: View Transitions のセッション制御を試さない

Astro 6.3 は View Transitions のセッション制御 API が拡張されています。実装を入れていないつもりで、Layout に残骸が残っているケースがあるため、astro check の警告を必ず潰します。

まとめ — 「同じ週に揃える」をやめる

Astro 6.3 と Starlight 0.39 のような同時リリースは、今後も **「同じ週」にやってきます。「本体とプラグイン / テーマを別の週に上げる」**を運用ルールにしておくだけで、受託保守の事故率は確実に下がります。

弊社のコーポレートサイトも Astro で動いているので、6.3 のような「事実上の四半期メジャー級」が来たときに何を目視し、どこでバッファを取るかは自分たちでも毎回踏んでいます。ただし追従計画の組み方は、Astro 系のサイトが何本あるか、テーマやプラグインをどこまで独自拡張しているか、CI がどこまで自動化されているかで作業量も順序も変わるため、決まった型はありません。「Astro と Starlight の追従順序を含めた計画を一度引きたい」「今の保守契約にどこまで入っているのか整理したい」という段階でしたら、お問い合わせフォーム からご連絡ください。

Sources

• Astro 6.3（Astro Blog）
• Starlight 0.39（Astro Blog）
• Astro 6.2 リリースを受託保守に織り込む（GH Media）
• オウンドメディア構築のコスト感（GH Media）
• Astro × microCMS で構築するメディアサイト（GH Media）