Node.js vs Bun：Web／サーバーアプリでのランタイム選び方

この比較が扱うこと

JavaScriptランタイムとは、ブラウザ外でJavaScriptコードを実行するプログラムです。エンジンによりコードを実行するだけでなく、アプリが必要とする“配管”――ファイルの読み書き、ネットワークリクエストの処理、データベースとのやり取り、プロセス管理など――を提供します。

このガイドはNode.jsとBunを実務的な観点で比較します：おもな目的は、トイベンチマークではなく、本番プロジェクトで信頼できるランタイムを選ぶ手助けをすることです。Node.jsはサーバーサイドJavaScriptの長年のデフォルトです。Bunは比較的新しく、より速く、統合されたツール群（ランタイム＋パッケージマネージャ＋ツール）を目指しています。

評価する内容

本稿は本番で出てくることの多いサーバーアプリケーションとウェブアプリケーションに焦点を当てます。具体的には：

• WebサーバーやREST/GraphQL API
• バックグラウンドジョブやワーカー（キュー、スケジューラ、バッチ処理）
• SSRアプリ（サーバーサイドレンダリング）やHTMLとAPIの両方を提供する“ハイブリッド”アプリ

これは「永遠の勝者」を決める比較ではありません。Node.jsの性能やBunの高速性は、アプリの実際の負荷（小さなHTTPリクエストが大量か、CPU負荷が高いか、コールドスタート対長時間動作、依存関係の多さ、OSやコンテナ設定、ハードウェア差）によって大きく変わります。

範囲外（現時点）

ブラウザ内のJavaScriptやフロントエンドフレームワーク単体、実運用に結びつかないマイクロベンチマークには時間を割きません。代わりに、チームがランタイムを選ぶときに重視する点――npmパッケージ互換性、TypeScriptワークフロー、運用挙動、デプロイ考慮、日常的な開発者体験――に重点を置きます。

Node.jsとBunで悩んでいるなら：これを意思決定のフレームワークとして使ってください。自分のワークロードで重要な要素を特定し、小さなプロトタイプと測定可能な目標で検証することが肝心です。

Node.jsとBun：簡単な概要

Node.jsとBunはどちらもサーバーでJavaScriptを動かしますが、誕生した時代が異なり、その差が開発体験に影響します。

簡単な歴史：成熟度と勢い

Node.jsは2009年から存在し、多くの本番アプリケーションを支えています。長年で安定したAPI、豊富なコミュニティ知見、膨大なエコシステム（チュートリアル、ライブラリ、運用実践）を蓄積しました。

Bunはずっと新しく、初期からモダンな開発体験と速度に重点を置いて設計されています。トレードオフとして、エッジケースの互換性や長期的な本番実績でまだ追いついていない部分があります。

JavaScriptの実行方法（概要）

Node.jsはGoogleのV8エンジン（Chromeと同系）上で動作し、イベント駆動のノンブロッキングI/Oモデルを採用、fsやhttp、crypto、ストリームなどのNode固有APIを長年にわたり提供しています。

BunはJavaScriptCore（WebKit/Safari由来）を使用し、パフォーマンスと統合ツールに注力して作られています。多くの既存のNode.jsスタイルのアプリを動かすことを目指しつつ、独自の最適化プリミティブも提供します。

標準で付いてくるツールの違い

Node.jsはランタイム単体で、パッケージ管理（npm/pnpm/yarn）、テストランナー（Jest/Vitest/node:test）、バンドラ（esbuild、Vite、webpack等）を別に組み合わせるのが一般的です。

Bunは初めからいくつかの機能を内包しています：パッケージマネージャ（bun install）、テストランナー（bun test）、バンドリング／トランスパイル機能など。典型的なプロジェクト構成で動く部品が少なく済むよう意図されています。

日常の開発での意味

Node.jsは最良のツールを選ぶ自由を与え、互換性が予測しやすい一方で、Bunは依存を減らしスクリプトが簡潔になり得ます。ただし互換性の穴や特定のスタックでの挙動を自分で検証する必要があります（特にNode APIやnpmパッケージ周り）。

パフォーマンス：何を測るべきか、なぜか

Node.jsとBunの性能比較は、正しい目標から始めないと意味が薄いです。「速い」は多義的で、間違った指標を最適化すると時間を無駄にしたり信頼性を下げたりします。

具体的な目標から始める

チームがランタイム切替を検討する一般的な理由：

• レイテンシ低下：ユーザー向けエンドポイントの応答を速くしたい（平均よりp95/p99が重要）
• スループット向上：同じハードでより多くのリクエストを捌きたい（API負荷が高い場合）
• 起動の高速化：サーバーレス、オートスケール、CLIツール、短命ジョブでのコールドスタート短縮

主要な目的（と副次的な目的）をまず決めてからベンチマークを見ましょう。

パフォーマンスが重要な時とそうでない時

パフォーマンスは、アプリが既にリソースの限界に近いときに最も重要です：高トラフィックAPI、リアルタイム機能、多数の同時接続、厳しいSLOなど。また、効率化が実際のコンピュートコストの削減に繋がる場合も重要です。

一方で、ボトルネックがランタイムでない場合（遅いDBクエリ、外部サービス、非効率なキャッシュやシリアライズ）には、ランタイム変更でほとんど効果が出ないことが多いです。

ベンチマークの誤読に注意

公開ベンチマークは多くがマイクロテスト（JSONパース、単純ルーター、素のHTTP）で、本番挙動を反映しません。TLS、ログ、圧縮、ボディサイズ、DBドライバ、ロードテストツールの差で結果が大きく変わります。

ベンチ結果は結論ではなく仮説として扱い、次に何をテストすべきかを示すものと考えてください。

自分のエンドポイントとデータで測る

公平に比較するには、実際のアプリの仕事を代表する部分をベンチマークします：

• 重要なエンドポイント（読み取り重視、書き込み重視）
• 現実的なペイロードサイズとリクエスト混合
• 実際に使う依存関係（ORM、バリデーション、認証、ロギング）
• 本番に近い環境設定（TLSオン/オフ、同じCPU制限）

追跡するメトリクスは最小限に：p95/p99レイテンシ、スループット、CPU、メモリ、起動時間。複数回試行しウォームアップ期間を設け、他は同じにしておくこと。目的は、Bunの有利な点が実際に運用に活かせるかを検証することです。

npmパッケージとNode APIとの互換性

今日の多くのWeb/サーバーアプリは「npmが動く」ことを前提にしており、ランタイムがNodeっぽく振る舞うことを期待します。これは純粋なJS/TSだけを使い、標準的なHTTPクライアントや一般的なモジュールパターン（ESM/CJS）を守る場合は安全ですが、Node固有の内部やネイティブコードに依存する場合は予測が難しくなります。

そのまま動きやすいパッケージ

次のようなパッケージは多くの場合そのまま動きます：

• フレームワークレベルのツール（React周りのツール、多くのサーバーフレームワーク）
• ユーティリティ系（日時ライブラリ、バリデーション、ルーティング、設定）
• 高レベルのネットワーク系（fetchベースのクライアント、OpenAPI SDK）

内部で深くNode固有の機能を使わなければおおむね問題ありません。

よくある互換性リスクとエッジケース

npmエコシステムの“ロングテール”が最大の驚きの源です：

• ネイティブアドオン（node-gyp、.nodeバイナリ）：NodeのABI向けにビルドされていることが多い
• postinstallスクリプト：プラットフォーム用バイナリをダウンロードしたりパッチするもの
• 特定のNode挙動を前提にしたパッケージ：ストリーム、バッファ、タイマー、子プロセス、TLSの扱いに差が出ることがある
• Node APIにフックするテスト／ビルドツール：カスタムローダー、実験的フラグ、インスペクタ統合等

Node APIとBunのサポート差分

Node.jsはNode APIのリファレンス実装なので、組み込みモジュールは概ね完全に期待通り動きます。

Bunは多くのNode APIをサポートしており拡張を続けていますが、“大部分互換”でも重要な関数が欠けていたり微妙な挙動差がある可能性があります。特にファイルシステムのウォッチ、子プロセス、Worker、暗号、ストリーミングのエッジケースは注意が必要です。

切り替え前に依存関係を監査する方法

1. 直接依存と推移的依存のインベントリを作り、インストールスクリプトやネイティブモジュール、バイナリを持つものを洗い出す
2. コードベースでNode組み込みを検索する：fs、net、tls、child_process、worker_threads、async_hooksなど
3. Bun上でテストスイートを早期に実行する：統合テスト（DB、キュー、ファイルI/O、TLS）を含める
4. ビルド、マイグレーション、バックグラウンドジョブなどCI/CDで実行するワークフローを検証する

アプリがネイティブアドオンやNode専用運用ツールに依存している場合は追加の時間を見積もるか、その部分だけNodeに留めてBunを評価する方が現実的です。

ツールとワークフロー：パッケージ管理、テスト、バンドリング

ツール面ではNode.jsとBunの差が日常的にもっとも大きく感じられます。Node.jsは「ランタイムのみ」で好きなツールを組み合わせる選択肢を与えますが、Bunは多くをデフォルトで提供します。

依存関係のインストール、ロックファイル、スクリプト

Node.jsでは多くのチームがnpm installとpackage-lock.json（またはpnpm-lock.yaml/yarn.lock）を使います。Bunはbun installとbun.lockb（バイナリロックファイル）を生成します。両者ともpackage.jsonのスクリプトをサポートしますが、Bunはスクリプト実行も高速に処理できる（bun run <script>）ため体感速度は変わります。

実務的な違い：チームが既に特定のロックファイル形式とCIキャッシュ戦略に依存している場合、Bunへの切替は慣例、ドキュメント、キャッシュキーの更新を伴います。

テストランナーとバンドリング：標準で得られるもの

Bunは組み込みのテストランナー（bun test）を提供し、Jestに似たAPIを持つため小さなプロジェクトでは依存が減ります。

またbun buildで多くの一般的なビルド作業を扱えます。Node.jsプロジェクトではViteやesbuildのようなツールでバンドリングを行うのが多く、選択肢は増えますが設定コストもあります。

CIパイプラインとローカル開発への影響

CIでの可搬性という点では、動く部品が少ない方がバージョン不整合が減ります。Bunの「ワンバイナリ」アプローチはパイプラインを簡素化できる一方で、Bun本体の挙動やリリースサイクルに依存するリスクも伴います。

Node.jsは長年確立されたワークフローと多くのプラットフォームが最適化したロックファイル形式により予測可能性が高いです。

ツール選択をシンプルに保つためのヒント

• リポジトリごとにパッケージマネージャを統一し、ドキュメントとCIで強制する
• package.jsonのスクリプトを信頼できる実行パターンの単一ソースにする
• チームが合意するまではランタイム特有の省略を避ける（リンタやフォーマッタは標準化する等）
• Bunを採用するなら、まずパッケージ管理やスクリプト実行で試し、bun test/bun buildは別途評価する

TypeScript、ビルド、デバッグ

TypeScriptの扱いがランタイムの日常的な摩擦を決めることが多いです。重要なのは単にTSが動くかどうかではなく、ローカル、CI、本番でビルドとデバッグがどれだけ予測可能かです。

実務で「動く」とされるTypeScriptサポート

Node.jsはデフォルトでTypeScriptを実行しないため、一般的に次のセットアップを使います：

• tsc（またはバンドラ）でトランスパイルして生成したJSをNodeで実行
• 開発時はts-nodeやtsxのようなランタイムで素早い反復を行い、本番はコンパイル済みJSをデプロイ

BunはTypeScriptファイルをそのまま実行できます。小さなサービスでは設定が減り始めが速いですが、大規模アプリでは多くのチームが依然として本番向けにコンパイルを選び、挙動を明示的にします。

ビルド手順：トランスパイルするか「直接実行」か

トランスパイルはビルドアーティファクトを作るため、本番での挙動が明確になります。直接TSを実行する（Bun向けのワークフロー）はローカルでの高速な開発を助けますが、ランタイム依存が増え、将来別のランタイムに移すときに再現性の問題が出る可能性があります。

ソースマップ、デバッグ、エディタ体験

Node.jsのTypeScriptデバッグは成熟しており、ソースマップの扱いも広くサポートされています。コンパイル済みコードを“TypeScriptとして”デバッグするワークフローが確立されています。

BunはTypeScriptファーストの流れで直接的な体験を提供しますが、ステップスルーや本番トレースの細かい振る舞いは設定次第で変わるため、実際のサービスで早めに検証してください。

TypeScript標準化のための推奨

本番ではJSにコンパイルしてデプロイすることを標準にすると驚きが少なくなります。直接TS実行は開発の便宜として扱い、本番での再現性とデバッグ容易性を優先してください。

Webフレームワークのサポートとアプリパターン

Node.jsとBunの選択は単に速度だけの話ではありません。使っているウェブフレームワークやアプリ構造が、移行を簡単にするか大がかりなリファクタにするかを左右します。

Express、Fastify、Hono、Nestスタイルのアプリ（期待できること）

多くの主流フレームワークはNodeのプリミティブ（HTTPサーバー、ストリーム、ミドルウェア）上に成り立っています。

• Express系ミドルウェア：ランタイムがNode HTTPの表面をサポートしていれば概ね動く
• Fastify系プラグイン：プラグインやログ、スキーマ検証でNodeの慣習に深く依存することがあり、互換性は概ね良好だがエッジが出やすい
• Hono系パターン：Web標準（Request/Response、fetch）に寄せる設計はランタイム依存を減らし移植性が高まる
• Nest系アーキテクチャ：フレームワーク自体は動いても依存グラフが大きいため、どこかが互換性問題を起こすリスクがある

“ドロップイン置換”が意味すること（実務）

ドロップイン置換とは通常「同じアプリコードが修正なしで起動し基本的なスモークテストを通過する」ことを指しますが、それはすべての依存挙動が同一である保証ではありません。特にNode固有の内部を使う箇所は注意が必要です。

実際に変更が必要になりやすい箇所

• ネイティブモジュール（Node-APIアドオン、node-gyp、プラットフォーム依存バイナリ）
• Node固有APIへの依存（一部のストリーム振る舞いやプロセスシグナル、ワーカー／スレッドの詳細）
• テストツールやモックがNodeのモジュール解決やグローバルを前提にしている場合
• フレームワークアダプタ（リクエスト/レスポンスのラッパー、multipartアップロード、WebSocketなど）

ランタイムロックインを減らす方法

• 可能な限り標準Web API（fetchスタイルのハンドラー、Request/Response）を使う
• エッジ（HTTPサーバ設定、ログ、メトリクス）のみ薄いランタイム層でまとめ、ビジネスロジックを分離する
• ある1つのランタイム内部実装（プライベートなNode内部や実験的フラグ）に深く依存しない

サーバーエントリポイントを差し替えるだけでコアアプリに触らずに済めば、Node.jsとBunの評価は大幅に低リスクになります。

サーバー運用：起動、メモリ、同時実行

運用面では、インスタンスの起動速度、メモリの占有、負荷増時のスケーリング戦略にランタイムの差が現れます。

起動時間と定常時性能

サーバーレス関数や頻繁にインスタンスを再起動する環境、デプロイ時のロールアウト速度が重要なら起動時間は重要です。Bunは起動が速いことが多く、コールドスタートやロールアウト速度の短縮に寄与します。

長時間稼働するAPIでは、定常時の予測可能性が優先されることが多く、Node.jsは長年の運用知見（プロセスクラスタ、ワーカースレッド、モニタリング）によって安定した挙動が得やすいです。

メモリ使用量と監視の必要性

メモリはコストであり信頼性リスクでもあります。Nodeのメモリプロファイルはよく理解されており、ヒープサイズ調整、GC挙動、メモリリーク診断の手法が豊富にあります。Bunは効率的なことが多いですが、過去の運用データや定石が少なく、プレイブックが整うまで時間がかかる可能性があります。

ランタイムに関わらず監視すべき点：

• RSSやヒープ使用量のトレンド（単一時点の測定だけで判断しない）
• GCの一時停止やイベントループの遅延（“遅いが停止しない”事象を検出するため）

バックグラウンドジョブ、キュー、スケジュールタスク

キューやcron的タスクではランタイムは一要素に過ぎません。信頼性はキューシステムそのもの（リトライロジック、永続化等）に依存します。Nodeは多くのジョブライブラリと成熟したワーカーパターンのサポートがあります。Bunを使う場合は、利用するキュークライアントが負荷下で正しく振る舞い、再接続やTLS、タイムアウトを適切に扱うかを検証してください。

複数プロセスと水平スケーリング

両ランタイムとも一般的には複数OSプロセス（一コアあたり1プロセス）でスケールし、ロードバランサーの背後に配置するのが良いです。実務上の注意点：

• プロセスマネージャやオーケストレータでワーカーの健全性を保つ
• 各プロセスを破棄可能（disposable）として扱い、セッションは外部に置く（Redis/DB）、アップロードはオブジェクトストレージへ

このパターンにすると、特定のランタイム差がボトルネックになるリスクを小さくできます。

安定性とセキュリティの考慮

ランタイム選択は速度だけの問題ではなく、本番での予測可能な挙動、アップグレードパス、脆弱性対応の速さも重要です。

本番で期待される安定性

Node.jsは長い実績と保守的なリリース慣行があり、レガシーなネットワーキングや珍しいストリーム挙動などエッジケースでの安定性が期待できます。

Bunは急速に進化しており新しいプロジェクトには魅力的ですが、サーバーランタイムとしてはまだ新しさが残り、互換性の問題や破壊的変更が発生する可能性がNodeより高いです。稼働率を最優先するチームはこの差を重視するべきです。

セキュリティ修正の適用頻度とアップグレード

実用的な問題として「どれだけ速く脆弱性修正を取り込めるか」があります。Node.jsはLTSなどよく知られたリリースラインがあり、アップグレード計画が立てやすいです。

Bunは修正が速く届くこともありますが、頻繁なアップデートに備える必要があります。ランタイムのアップグレードは依存関係のアップグレードと同様に、テスト済みでロールバック可能なプロセスとして扱いましょう。

サプライチェーンの基本：ロックファイルと監査

ランタイムに関わらずリスクの多くは依存関係から来ます。ロックファイルを一貫して使い（コミットする）、重要サービスはバージョン固定、重大な更新はレビュー、CIでの監査（npm audit等）を実行し、自動依存更新PRには承認ルールを設定するなど保護を行ってください。

リスクを減らすガードレール

• ユニット＋統合テストを自動化し、ランタイムや依存更新時に全スイートを走らせる
• ステージング環境を本番に近づける（トラフィック形状、シークレット、可観測性）
• ロールバック手順を用意する：イミュータブルなビルド、バージョン管理されたデプロイ、ワンコマンドでのリバート

デプロイと可観測性のチェックリスト

ローカルのベンチから実際の本番ロールアウトまで、ランタイムの差はコンテナ、サーバーレスの制約、TLS終端、本当のトラフィックを加えると出てきます。Node.jsもBunもどちらもウェブ／サーバーアプリを動かせますが、挙動が異なる点を詳しく検証する必要があります。

ローカル開発と本番の整合性

「自分の環境で動く」がデプロイのギャップを覆い隠さないように：

• バージョンを固定する：リポジトリとCIでNodeまたはBunのバージョンをピン留め
• 環境変数とシークレットの取り扱いを整合させる
• 依存のビルド方法を揃える：ネイティブモジュールやロックファイル、インストールフラグの違いで振る舞いが変わる
• ファイルシステム前提を検証：書き込み権限、テンポラリディレクトリ、作業ディレクトリがコンテナで違うことがある

コンテナとサーバーレスの高レベル考慮

コンテナではベースイメージがランタイムやネイティブ依存をサポートするか確認してください。Node.jsのイメージやドキュメントは豊富ですが、Bunのサポートも向上しています。libc互換性やビルド手順を明示的にテストしましょう。

サーバーレスではコールドスタート、バンドルサイズ、プラットフォームサポートに注意。多くのプラットフォームはNode.jsを前提としているため、Bunはカスタムレイヤーやコンテナ展開が必要になる場合があります。エッジランタイムを使うなら、そのプロバイダがどのランタイムをサポートしているかを確認してください。

ロギング、メトリクス、トレーシング

可観測性はランタイムよりもエコシステム互換性が重要です：

• ロギング：構造化ログ（JSON）、ログレベル、相関IDが一貫しているか
• メトリクス：利用するエクスポーター／エージェントがランタイムをサポートしているか（OpenTelemetry SDKs、Prometheusクライアント等）
• トレーシング：非同期境界とHTTPクライアント／サーバー間でのコンテキスト伝搬が機能するか
• エラー報告：本番ビルドでのソースマップとスタックトレースの検証（特にTypeScript）

ロールアウト前チェックリスト

本番トラフィックを流す前に確認する項目：

• npm + Node API利用：依存するパッケージとNode APIが同等に動作するか
• ビルド出力：TypeScriptのトランスパイル、バンドリング、ソースマップがデバッグ時と一致するか
• ヘルスチェック：readiness/liveness、タイムアウト、グレースフルシャットダウンが機能するか
• 負荷下の性能：レイテンシ、メモリ成長、同時実行制限を実トラフィックで確認
• セキュリティ基礎：依存スキャン、ランタイムアップデート、最小権限コンテナ設定
• ロールアウト計画：カナリーデプロイ、迅速なロールバック、成功指標の定義

低リスクに進めたいなら、デプロイ形状（コンテナのエントリポイント、設定）を同じにしてランタイムだけ差し替え、エンドツーエンドで差分を測るのが良いです。

どちらのランタイムを選ぶべきか？

Node.jsとBunの選択は「どちらが優れているか」ではなく、どのリスクを許容できるか、どのエコシステム前提に依存しているか、速度がプロダクトやチームにとってどれだけ重要かに依存します。

ケース1：依存関係が多い既存のNode.jsアプリ

フレームワークプラグイン、ネイティブアドオン、認証SDK、モニタリングエージェントなど多数の依存がある成熟サービスでは、互換性の観点からNode.jsが安全なデフォルトです。

小さなAPI差やNode APIの微妙な違いが数週間のトラブルに発展することがあるため、ベンダーの多くがNodeを明記している点も重要です。

実務的な選択：Node.jsを維持し、Bunは限定的な用途（ローカル開発スクリプト、小さな内部サービス）でパイロットする。

ケース2：速度とシンプルなツールを重視する新規プロジェクト

グリーンフィールドでスタックを管理できるなら、Bunは有力な選択です。インストールの高速さ、起動の速さ、組み込みツールにより日々の摩擦を減らせます。

効果的なのは次の条件が揃う場合：

• 依存は主流でメンテされている
• 書面通りのNode内部に依存していない
• アプリの表面積がシンプル（HTTP API、背景ジョブ、軽量サービス）

実務的な選択：Bunで始めつつ、決定的な互換性障害に備えてCIでNode.jsでも同じアプリを動かせるようにしておく。

ケース3：長期的なサポートと予測可能性を重視するチーム

アップグレードパスの予測可能性、幅広いサードパーティサポート、ホスティングプロバイダ上での安定した運用が最優先なら、Node.jsが保守的で現実的な選択です。

特に規制の厳しい環境、大企業、ランタイムの変更が運用リスクになるプロダクトでは重要です。

実務的な選択：本番標準はNode.jsにして、Bunは開発体験改善や限定的な改善にのみ導入する。

決定マトリクス

不確かな場合は「両方をパイロット」が最良の答えです：小さく測定可能なスライス（1サービス、1エンドポイント群、あるいは1つのビルド/テストワークフロー）を定義して比較してから全体を移行してください。

低リスクで評価・移行する方法

ランタイム切替はリライトではなく実験として扱うと容易です。ゴールは早く学び、影響範囲を限定し、元に戻す道筋を残すことです。

1) 低リスクなパイロットから始める

小さなサービス、バックグラウンドワーカー、あるいは読み取り専用の単一エンドポイント（例：一覧API）を選びます。スコープを狭く保ち、入力と出力、依存関係はできるだけ同じにします。

まずステージング環境でパイロットを回し、自信がついたら本番でカナリア（少量トラフィック）を試してください。

評価を迅速にしたければ、Koder.aiのようなツールで最小API＋バックグラウンドワーカーを生成し、Node.jsとBunで同一ワークロードを走らせて比較するのも一案です。

2) テストと重要指標を測る

既存の自動テストを変更せずそのまま使い、ランタイムに注目した指標を追加します：

• コールドスタートとウォームスタートの時間
• スループットとテールレイテンシ（p95/p99）
• 継続負荷下のメモリ消費
• エラー率とタイムアウト率

既存の可観測性があるなら成功基準を事前に定義します（例：「5xxの増加なしでp95を10%改善」）。

3) 移行の障壁を早期に発見する

驚きの大半はエッジに現れます：

• Node固有APIや微妙な振る舞いの違い（ストリーム、バッファ、タイマー）
• ネイティブアドオン、postinstallスクリプト
• ESM/CJSの解決やバンドリングの前提
• テストランナーやモック、スナップショット挙動の違い

まず依存監査を行い、ランタイムのせいではなく依存ライブラリの前提違いが原因であることを確かめてください。

4) 結果を記録しロールバックルートを残す

何を変えたか（スクリプト、環境変数、CI手順）、改善点と壊れた点をコミットやリンク付きで記録します。両ランタイム分のデプロイアーティファクトを保持し、以前のイメージに戻せる「ワンコマンドのロールバック」を用意しておくこと。