Astroで作ったサイトの依存関係を入れ直してビルドすると、手元では通るのにCIだけが止まる。原因はコードではなく、CIで動いているNode.jsの版。2026年10月15日に公開されたAstro 7.4.0では、この形の失敗が起こりえます。
7.4.0は「マイナー版」なので、package.json で "astro": "^7.2.2" のように ^ を付けて指定しているサイトでは、ロックファイルを作り直したときに自動で入ります。本記事では、変更履歴（CHANGELOG）と公式ドキュメントの記述を、編集部の検証環境で実際に動かした結果と合わせて、上げる前に確かめる点と、新しく使えるようになった2つの機能を整理します。
必要なNode.jsが22.22.0以上に
Astroの変更履歴の7.4.0には、次の1行があります。
Increases the minimum Node.js version to 22.22.0
npmに公開されたパッケージの engines も、7.3.8の node: ">=22.12.0" から、7.4.0では node: ">=22.22.0" に変わっていました。
インストールは通り、ビルドで止まる
編集部の検証環境で、Node.js 22.21.1（公式の配布物）を使って astro@7.4.0 を入れ、ビルドしました。
npm installはEBADENGINE（対応していないNode.jsの版）の警告を出しますが、終了コードは0で、インストールは成功しますastro buildを実行すると、次のメッセージで止まります
Node.js v22.21.1 is not supported by Astro!
Please upgrade Node.js to a supported version: ">=22.22.0"npmは既定では engines の不一致を警告にとどめるため、インストールの段階では気づきにくい構成です。CIのログで警告を読み飛ばしていると、ビルドの失敗で初めて気づくことになります。同じ環境で Node.js 22.22.0 に替えると、ビルドは通りました。
確かめる場所
ビルドを動かしている場所ごとに、Node.jsの版を確認します。
- CI：GitHub Actions なら
actions/setup-nodeのnode-version、ほかのCIなら実行イメージの版 - ホスティングのビルド：Cloudflare・Netlify・Vercel などのビルド設定。プロジェクトに
.nvmrcや.node-versionを置いて指定しているか - 開発者の端末：チームで版を揃えているか
22 のように大まかに指定している場合、実際に入る版はサービスの既定やキャッシュで変わります。22.22.0 以上を明示するか、24系に上げるかを決めておきます。
なお、Node.jsの公式ブログは、2026年10月21日ごろに26.x・24.x・22.xのセキュリティ修正版を出すと予告しています（最も高い深刻度は「HIGH」）。Astroのためだけでなく、どの系列でもこの修正版まで上げることになるため、版の固定方法をここで見直しておくと手戻りが減ります。Node.jsの系列ごとのサポート期間はNode.js 24の保守期入りと26のLTS化で整理しています。
--timings：ビルドの遅い処理を一覧にする
記事やページが増えると、ビルドの時間がじわじわ延びます。ところが、遅いのが画像の変換なのか、Markdownのプラグインなのか、コードのハイライトなのかは、通常のログからは分かりません。7.4.0で追加された --timings は、ビルドの最後に内訳を表示します。
npx astro build --timings検証用に、Markdownの記事3本（コードブロック入り）、画像1枚、リダイレクト2件を持つ小さなサイトを作って実行しました。表示された項目は次のとおりです。
- Build phases：設定の読み込み、バンドル、ページの生成などの段階ごとの時間と割合
- Vite plugins：プラグインごとの時間と呼び出し回数
- Markdown plugins / Syntax highlighting：Markdownの処理とコードのハイライトの時間（言語別）
- Slowest files to bundle / Slowest pages：時間のかかったファイルとページ
- Images：画像の変換ごとの時間
この小さなサイトでも、ページの生成（58ミリ秒）より、事前描画用のバンドル（748ミリ秒）が大半を占めていました。Markdownの3ファイルはそれぞれ約190ミリ秒で、内訳の「Syntax highlighting」には3つのコードブロックで計112ミリ秒と出ました。数値はこの検証環境での1回の結果で、サイトの規模や構成で大きく変わります。
使いどころは、最適化の前後で同じコマンドを実行して比べることです。例えば、ハイライトの言語を絞る、画像を事前に縮小しておく、といった変更が実際に効いたかを確認できます。記事数が多いメディアのビルドを速くする考え方は、Astro 7.2の増分ビルドやMarkdownの処理系を替える記事でも扱っています。
静的サイトのリダイレクトページを自作する（実験機能）
静的サイトには、HTTPの Location ヘッダーでリダイレクトを返すサーバーがありません。そのためAstroは、redirects の設定ごとに、<meta http-equiv="refresh"> を入れた小さなHTMLを生成します。これまでは、このページの文言や見た目を変えられませんでした。
7.4.0では、experimental.redirectPage を有効にすると、src/pages/3xx.astro を置いてこのページを自作できます。
// astro.config.mjs
export default defineConfig({
experimental: { redirectPage: true },
});ページには、移動元（from）、移動先（to）、ステータス（status）、待ち時間（delay）が渡されます。ドキュメントによると、delay は302のときに2秒、それ以外は0秒です。検証でも、301の設定は content="0;url=..."、302の設定は content="2;url=..." になりました。
気をつける点が3つ
検証で見えた、移行時に気をつける点です。
1. meta refresh を消すと、リダイレクトしなくなる。 試しに 3xx.astro から <meta http-equiv="refresh"> を外すと、ビルドは成功したまま、[WARN] [redirects] ... visitors will not be redirected. という警告が出ました。止まらないので、警告を見落とすと、移動しないページが公開されます。
2. /3xx.html というページも公開される。 ドキュメントにも「Astro also builds 3xx.astro as the ordinary /3xx route, written to 3xx.html.」とあり、このときはリダイレクトの情報が渡されません。ドキュメントの例をそのまま使うと、3xx.html は content="undefined;url=undefined" という壊れた転送先を持つページになりました。to が無いときは meta refresh を出さないよう、次のように条件を付けると避けられます。
---
import type { RedirectPageProps as Props } from 'astro';
const { to, delay } = Astro.props;
const canonical = to ? new URL(to, Astro.site).href : undefined;
---
<html lang="ja">
<head>
{to && <meta http-equiv="refresh" content={`${delay};url=${to}`} />}
<meta name="robots" content="noindex" />
{canonical && <link rel="canonical" href={canonical} />}
<title>ページを移動しました</title>
</head>
<body>
{to ? <p>このページは移動しました。<a href={to}>移動先へ進む</a></p>
: <p>ページが見つかりません。</p>}
</body>
</html>3. 既定のページにあった canonical が消える。 7.4.0の既定のリダイレクトページには、移動先を指す <link rel="canonical"> と noindex が入っていました。自作のページでは、自分で書かない限り入りません。上の例のように、site の設定から絶対URLを組み立てて入れておきます。
実験機能のため、今後の版で仕様が変わる可能性があります。サイトのリニューアルでURLを大きく変える場合は、静的なリダイレクトページに頼るより、ホスティング側（Cloudflareの _redirects、Netlifyの設定など）でHTTPのリダイレクトを返せないかを先に検討するのが安全です。この判断は、検索エンジンへの影響も含めて移行の計画の段階で決めておきます。
上げる前の確認リスト
編集部の整理として、Astro 7.4へ上げる前に確かめる点をまとめます。
- ビルドを動かすすべての場所で、Node.jsが22.22.0以上か（10月21日予定の修正版を含めて上げる計画を立てる）
package.jsonの範囲指定で、意図せず7.4.0が入らないか。入れるならロックファイルの更新とビルドの確認をセットにする- ビルドが遅い場合は、上げる前と後で
--timingsを取り、内訳を比べる experimental.redirectPageを使うなら、/3xx.htmlの中身、meta refresh、canonicalをビルド結果で確認する
Astro 7系の全体像はAstro 7でコーポレートサイトを作る土台で紹介しています。
確認した範囲
2026年10月16日に、Astroの変更履歴（
packages/astro/CHANGELOG.mdの7.4.0）、公式ドキュメントの「Experimental static redirect page」（withastro/docs リポジトリの原稿）、npmに公開されたastro7.3.8・7.4.0のengines、Node.js公式ブログのセキュリティリリースの予告を直接取得して確認しました（資料調査）。あわせて、編集部の検証環境（Linux、Node.js v22.22.0 と v22.21.1、astro7.4.0）で、検証用の小さな静的サイトを作り、インストール・ビルド・--timings・experimental.redirectPageを試しました（実機検証）。数値はこの環境での1回の結果です。SSR（オンデマンド描画）のサイト、各ホスティングサービスのビルド環境、7.4.0のそのほかの変更（画像サービスの分離、フォントの設定など）は確認していません。
Astroで作ったサイトの版上げ、ビルド環境の見直し、リニューアル時のURL移行の設計は、HP制作・リニューアルのご相談からお問い合わせください。
