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 の主要変更（受託で気にすべき範囲）
公式ブログから、受託で実装に影響しそうな変更を抜粋します。
| プロダクト | 変更領域 | 受託サイトへの影響 |
|---|---|---|
| Astro 6.3 | Content Collections の loader API 拡張 | 大量記事サイトのカスタムローダー再設計の余地 |
| Astro 6.3 | Image Service の AVIF / WebP 既定切替 | OG 画像と featuredImage の出力フォーマットが変わる可能性 |
| Astro 6.3 | View Transitions のセッション制御 | SPA 風遷移を入れたサイトの挙動変化 |
| Astro 6.3 | Type Generation の厳格化継続 | astro check で新規警告が出る |
| Starlight 0.39 | サイドバー自動生成のロジック変更 | 既存ドキュメントの並び替えが発生 |
| Starlight 0.39 | i18n まわりのデフォルト変更 | 多言語ドキュメントの URL に影響 |
| Starlight 0.39 | テーマ拡張 API のシグネチャ変更 | カスタムコンポーネント側の修正必要 |
特に 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 メジャー追従を保守月額に明示的に含める価格設計です。
| パッケージ | 月額 | アップグレード対応 |
|---|---|---|
| ライト保守 | 5〜15 万円/月 | パッチアップデートのみ |
| スタンダード保守 | 25〜55 万円/月 | パッチ + マイナー（Astro 6.x → 6.3、Starlight 0.x → 0.39 含む） |
| プレミアム保守 | 70〜160 万円/月 | メジャーアップデート + 並行サイトの調整含む |
スタンダード保守にすでに 「Starlight の追従」を明示している契約は、今回の同時リリースで 「契約範囲内なので追加見積なしで対応します」と即答でき、信頼を積みやすい構図になります。
これは オウンドメディア構築のコスト感 で扱った「運用込みの月額」と同じ思想で、「アップグレードは事故対応ではなく定例タスク」として価格に内包しておくのが事故が少ないモデルです。
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 / Starlight / Next.js / Nuxt で構築した受託サイトの保守を、月額に並行アップグレード対応を含めた形で提供しています。「コーポレートサイトとドキュメントサイトを Astro 系で運用しているが、追従計画が立てられていない」「保守費の中身を整理したい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
