Astro チームが 2026 年 4 月 30 日に 「Astro 6.2」 をリリースしました。Content Collections の改善、Image Service の最適化、View Transitions まわりの安定化など、ユーザー体験に直結する変更が複数入っています。同日には 「What’s new in Astro - April 2026」 も公開されており、エコシステム側の動きも活発です。
弊社のコーポレートサイト（gleamhub.net）も Astro で構築されており、加えて受託で構築した複数のクライアントサイトも Astro で動いています。「リリースが出るたびに機械的に上げる」運用は事故の元で、受託保守ではアップグレードの 「いつ」「どう」「いくらで」 を契約に織り込んでおくべき話題です。本記事では、Astro 6.2 を受託保守の文脈で安全にアップグレードする手順を整理します。
Astro 6.2 の主要変更（受託で気にすべき範囲）
公式リリースノートから、受託で実装に影響しそうな変更を抜粋して整理します。
| 変更領域 | 内容 | 受託サイトへの影響 |
|---|---|---|
| Content Collections | glob ローダーのパフォーマンス改善 | 大量記事サイトのビルド時間短縮 |
| Image Service | sharp ベースの最適化が高速化 | OG 画像生成・featuredImage の処理が速くなる |
| View Transitions | クロスブラウザ挙動の安定化 | 遷移アニメーションを使うサイトの不具合修正 |
| Type Generation | astro sync の型生成が厳格化 | 既存コードの型エラー顕在化の可能性 |
| Build Format | trailingSlash 設定との相互作用調整 | サイトマップ・リダイレクトに影響 |
特に Type Generation の厳格化は、受託で // @ts-ignore を残しているプロジェクトでビルド失敗を誘発しがちです。アップグレード前に必ず astro check を CI に通しておく必要があります。
Astro × microCMS で構築するメディアサイト や Next.js vs Astro 2026 で扱ったとおり、Astro は 小〜中規模のコーポレート / メディアサイトでデファクトになりつつあり、保守側も追従コストを真剣に見積もる段階に来ています。
受託サイトの安全アップグレード手順
弊社の受託保守で実施している、Astro マイナーアップデートの標準手順です。
[Step 1] アップグレード対象ブランチを切る
└ git checkout -b chore/astro-6.2-upgrade
[Step 2] 依存をバンプ
└ npx @astrojs/upgrade
└ Integration の互換性も同時にチェック（@astrojs/sitemap, @astrojs/mdx 等）
[Step 3] ローカルで型チェック・ビルド
└ npm run build # astro check → astro build → pagefind
└ 失敗したら即修正、コミット
[Step 4] プレビュー環境で目視確認
└ Cloud Build / Cloudflare Pages のプレビューを使う
└ 主要 5 ページ × デバイス 3 種で目視
[Step 5] Lighthouse / Pagefind / OG 画像の差分チェック
└ 性能・検索・SNSプレビューが壊れていないか
[Step 6] 段階リリース
└ ステージング 24h → 本番デプロイ「Step 5 の差分チェック」を抜くと、Pagefind の検索インデックスが壊れた状態で本番リリースされる事故が起きやすいので、保守の手順書に必ず入れます。
よくあるハマりどころと対策
Astro マイナーアップデートで頻発する不具合と対策です。
| ハマりどころ | 症状 | 対策 |
|---|---|---|
| Content Collections のスキーマ変更 | astro:content の型エラー | content.config.ts を最新スキーマに更新 |
| Integration バージョン不整合 | ビルドが通っても本番でエラー | Astro 本体と同じメジャーで揃える |
trailingSlash の挙動変化 | サイトマップの URL が変わる | astro.config.mjs で明示設定 |
| Image Service の出力フォーマット変更 | OG 画像が壊れる | experimental.responsiveImages の設定を確認 |
| Pagefind との相互作用 | dist/pagefind 配下のキャッシュ不整合 | npm run build 前に dist を削除 |
特に trailingSlash は、本サイトでも 'always' で運用しており、ここの挙動が変わると大量のリダイレクト設定が必要になるため、リリースノートで必ず確認すべき項目です。
CI / CD への織り込み — Cloud Build パターン
受託サイトの多くは Cloud Build / Cloudflare Pages / Vercel で CI/CD を組んでいます。Cloud Build を例にしたアップグレード対応設定です。
# cloudbuild.yaml の抜粋
steps:
- name: 'node:22'
entrypoint: 'npm'
args: ['ci']
- name: 'node:22'
entrypoint: 'npx'
args: ['astro', 'sync']
- name: 'node:22'
entrypoint: 'npm'
args: ['run', 'build']
env:
- 'NODE_ENV=production'
- name: 'gcr.io/cloud-builders/gsutil'
args: ['-m', 'rsync', '-d', '-r', './dist', 'gs://${_BUCKET}']ポイントは astro sync を必ず build の前に挟むこと。型生成だけが先に走ることで、Content Collections のスキーマ変化を検知しやすくなります。Astro 6.2 では astro sync の出力が変わっているため、CI のキャッシュキーを更新するのを忘れないようにします。
受託保守の月額にアップグレードを組み込むパッケージ
Astro マイナー / メジャーアップデートを保守月額に明示的に含める価格設計です。
| パッケージ | 月額 | アップグレード対応 |
|---|---|---|
| ライト保守 | 5〜15 万円/月 | パッチアップデートのみ（マイナーは別途見積） |
| スタンダード保守 | 20〜50 万円/月 | パッチ + マイナー対応（Astro 6.x → 6.2 のような） |
| プレミアム保守 | 60〜150 万円/月 | メジャーアップデートも含む（Astro 5 → 6 など） |
スタンダード保守を中心に提案するのが現場感としてフィットしやすく、メジャーアップデートはタイミングを見て個別見積で受けるのが事故が少ないモデルです。これは オウンドメディア構築のコスト感 と組み合わせて、「メディアの記事公開ワークフロー込み」+「Astro 保守込み」でパッケージ化すると顧客にとっても判断しやすくなります。
アップグレードを「半年に 1 回」運用化する
頻度設計の目安です。
| 頻度 | 対象 | 工数目安 |
|---|---|---|
| 月次 | パッチアップデート（6.2.1 → 6.2.2 など） | 0.5〜1 人日 |
| 四半期 | マイナーアップデート（6.1 → 6.2 など） | 2〜4 人日 |
| 半期〜年次 | メジャーアップデート（5 → 6 など） | 5〜15 人日 |
「四半期ごとにマイナーを取り込む」のが、放置しすぎず慌てすぎずのちょうど良いリズムです。これを保守契約に明示しておくと、顧客側も「いつ上げるか」を予算化できるため合意形成が楽になります。
まとめ ─ アップグレードを保守の “計画項目” に
Astro のリリースサイクルは早く、放置すると 1 年後にメジャーが 2 つ進むという状況になりかねません。受託で長期的に Web サイトを運用するなら、アップグレードを「事故対応」ではなく「計画項目」に格上げするのが、サイトの寿命と運用コストを左右します。
弊社では、Astro / Next.js / Nuxt で構築した受託サイトの保守を、月額にアップグレード対応を含めた形で提供しています。「サイトを Astro で作ったが、バージョンアップに追従できていない」「保守費の中身を整理して、計画的に上げていきたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
