3行サマリ

• AWS Amplify Gen2 のビルド環境をカスタム Docker イメージに切り替え、自社アプリのビルド時間を中央値で約 10%（1 ビルドあたり約 1 分）短縮しました。

• 同時に、外部ダウンロード起因のビルド失敗を構造的にゼロにし、深夜・休日にリリースが止まる事故を撲滅しました。

• 今回作った Docker イメージは次に立ち上げる Next.js プロジェクトでも使い回せ、そこでは 50〜70% の短縮が射程に入ります。一度の投資で複数プロジェクトに効く施策です。

背景：ビルドの遅さと、それ以上に厄介だった不安定さ

自社アプリは AWS Amplify Gen2 上で運用しており、ソースコードを main や staging ブランチに push するたびにビルドとデプロイが走ります。このビルドは 1 回あたり 9〜10 分程度かかり、エンジニアは「push してから動作確認できるまでの待ち時間」としてこれを何度も払っていました。

しかし本当に課題だったのは、単に遅いことよりも不安定さでした。Amplify のビルド過程で外部のファイル（Chromium という、LLM 機能で使うブラウザ部品）を毎回インターネットからダウンロードする仕組みになっており、ネットワークの一時的な不調で月に数回ビルドが赤く染まります。深夜にリリースが止まり、朝の会議前に復旧させる、ということが実際に起きていました。

取り組み：ビルド環境を専用イメージに固定する

打ち手は「ビルドに必要なツールと外部ファイルを、あらかじめすべて焼き込んだ専用の Docker イメージを作り、Amplify にそのイメージを使わせる」というものです。従来は毎ビルドごとに Node.js をインストールし、パッケージマネージャをセットアップし、外部ファイルをダウンロードしていたのを、すべて事前に終わった状態から開始できるようにしました。

技術的な選択のポイントは 3 つです。第 1 に、Amplify の標準環境と同じ OS（Amazon Linux 2023）をベースに選ぶことで、互換性リスクを最小化しました。第 2 に、依存パッケージのキャッシュ保存場所を全環境で統一し、2 回目以降のビルドで再ダウンロードをスキップできるようにしました。第 3 に、カスタムイメージを使わない環境でも従来どおり動くようフォールバック処理を残し、段階的な導入と不測のロールバックを安全にしました。

成果：定量と定性の両面で効いた

定量面：中央値で約 10% 短縮

適用前の 38 ジョブと適用後の 57 ジョブを AWS の実データから集計したところ、ビルド時間の中央値は 9 分 43 秒から 8 分 45 秒へと、約 58 秒（10.0%）短縮しました。1 週間あたり 50 本のビルドが回る現在の開発ペースでは、週 50 分の累積リードタイム短縮に相当します。

なお、この短縮率はフレームワーク特性で上限が決まります。自社アプリで採用している Vite という構成は構造上 10〜15% が上限で、実測はその中央に着地しました。一方、React Router v7 / Remix なら 10〜20%、Next.js なら 50〜70% が射程に入ります。つまり「どの技術スタックを採用したかで、この施策の費用対効果は最初から決まっている」という構造です。

定性面：ビルド失敗ゼロと環境統一

時間短縮以上に大きかったのは、副次効果として得られた 3 つのリターンです。

• 外部ダウンロード起因のビルド失敗がゼロになりました。必要なファイルはすべてイメージに焼き込まれており、イメージ作成時にファイルサイズの検証も済ませているため、本番ビルドが走る時点で「ファイルが存在することが保証された状態」です。深夜にリリースが止まるリスクが構造的に消えました。

• 全環境のランタイムバージョンが一元化されました。エンジニアのローカル環境、CI（GitHub Actions）、4 つの Amplify 環境すべてが同一の Dockerfile から派生した同じランタイムで動きます。「ローカルでは通るのに本番で落ちる」類の再現性のない不具合が減ります。

• 次のプロジェクトへの横展開コストがほぼゼロです。同じイメージを次に立ち上げる Next.js プロジェクトでそのまま使えば、そちらでは 50〜70% の短縮が期待できます。加えて今回の仕組みは Amplify だけでなく GitHub Actions の CI 環境にも同じイメージを使えるので、開発現場全体でランタイムが揃います。

学び：ビルド改善は「速さ」よりも「失敗しないこと」が本丸

ビルド時間の短縮は見た目の数字で語られがちですが、実際の開発現場では「失敗しないこと」のインパクトの方がはるかに大きい、というのが今回の一番の学びです。1 ビルド 1 分の短縮が月 50 分の時間節約になるのはもちろん価値がありますが、それ以上に「深夜・休日にリリース事故で叩き起こされない」という安心感は、数字には表れないかたちで開発チームの生産性を支えます。

また、技術施策のリターンは採用している技術スタックによって上限が決まる、という構造も改めて意識する必要があります。今回の施策は Vite 構成の自社アプリでは 10% 止まりでしたが、同じ施策を Next.js プロジェクトに適用すれば 5〜7 倍の効果が出ます。個別施策の「上限値」を先に見積もってから投資判断をする、という視点は他の技術改善にも応用できそうです。

AWS Amplify でモノレポを運用している開発チームにとって、カスタム Docker イメージの導入はコストに対してリターンが読みやすく、かつ副次効果が大きい投資先だと感じています。同じ課題感のあるチームの参考になれば幸いです。

技術詳細（Zenn）

Dockerfile や amplify.yml の具体的なコード例、ハマりどころの技術詳細、そして読者がそのまま試せる ECR Public 上のお試しイメージの紹介を、Zenn の技術記事で公開しています。エンジニア向けにより踏み込んだ内容にしているので、手元で同じ仕組みを導入したい方は合わせてご覧ください。

Zenn：Amplify Gen2 のビルドをカスタム Docker イメージで 10〜20% 高速化する