ある開発チームはUnityを利用したアプリケーションのバックエンドをAWS上で構築しています。ソースコードは外部のGitリポジトリ（GitHub）で管理されており、AWS CodePipelineを利用してCI/CDパイプラインを構築しています。ビルドステージではAWS CodeBuildを使用し、テストとアーティファクトの生成を行っていますが、最近npmパッケージやDockerイメージなどの外部依存関係のダウンロードに時間がかかり、ビルド時間が長くなっています。ビルド時間を短縮するための最も効果的なアプローチはどれですか。
AWS CodeBuildでは、ビルドプロセス間で再利用可能なファイル（依存関係、コンパイル済みバイナリ、Dockerレイヤーなど）をキャッシュすることで、ビルド時間を大幅に短縮できます。CodeBuildは、Amazon S3キャッシュとローカルキャッシュの2種類をサポートしています。S3キャッシュはビルドアーティファクトをS3バケットに保存し、複数のビルド環境で共有するのに適しています。ローカルキャッシュはCodeBuildのビルドホスト上に直接保存され、Dockerレイヤーキャッシュやカスタムディレクトリ（node_modulesなど）のキャッシュに利用でき、S3へのネットワーク転送が発生しないため非常に高速です。buildspec.ymlのcacheセクションでディレクトリを指定することで毎回のダウンロードを回避し、CI/CDパイプラインのフィードバックループを最適化できます。 選択肢Bのコンピューティングタイプのスケールアップは、CPU・メモリを増強してビルド処理自体を高速化しますが、外部依存関係のダウンロード時間はネットワーク待ち時間に依存するため根本解決にならず、継続的なコスト増も招きます。 選択肢CのGitHub WebhooksによるCodeBuild直接トリガーはパイプライン起動方式の変更であり、依存関係のダウンロード時間そのものを短縮しません。CodePipelineのアーティファクト保存バイパスもビルド時間増加の原因とは無関係です。 選択肢DのCodeBuild開始前に`sleep 30`を追加することはビルド時間を不必要に30秒延長させるだけで、依存関係のダウンロード遅延を解消する根拠がなく逆効果です。