設定 約10分

開発者向けGitHub・Docker・npmが遅いときの高速化設定ガイド

コード取得、コンテナイメージのpull、npmパッケージ導入で発生する遅延を、プロキシ・レジストリ・DNSの観点から整理。開発PCとCIの設定例や速度確認の手順を紹介し、認証情報を守りながら作業を効率化する方法を解説します。

GitHubからのcloneやfetch、Dockerイメージのpull、npmパッケージのインストールが遅いときは、回線だけでなく、通信経路、DNS、プロキシの適用範囲、接続先レジストリを分けて確認することが大切です。VPNやプロキシを有効にすれば必ず速くなるわけではありません。遠回りになる場合や、認証・証明書の問題で接続が失敗する場合もあります。まず遅い処理を特定し、設定を一つずつ変えて比較すれば、開発PCとCIの両方で原因を絞り込みやすくなります。

最初に確認する：遅い処理と通信経路を分ける

「開発環境全体が遅い」とまとめず、Gitのリポジトリ取得、Dockerイメージの取得、npmの依存関係取得を別々に試してください。GitHubのページ表示は速いのにcloneだけ遅いなら、Gitが使うHTTPSまたはSSHの経路、リポジトリのサイズ、認証方式が関係している可能性があります。Dockerでは、イメージを取得する段階と、取得したイメージ内でパッケージをダウンロードする段階は別の通信です。npmも、レジストリへの接続と、依存パッケージの展開・スクリプト実行を区別して考えましょう。

再現条件を記録すると比較が簡単になります。実行したコマンド、失敗または停止した段階、利用中のネットワーク、VPN・プロキシの有無、表示されたエラーをメモしてください。同じ処理を同じ作業ディレクトリで繰り返し、変更する条件は一度に一つにします。別のネットワークで改善した場合も、それだけでDNSが原因とは限りません。経路の混雑、通信制限、接続先側の状態など、複数の要因が考えられます。

  • ✅ Git、Docker pull、npm installを個別に実行して、遅い工程を特定する
  • ✅ VPNやプロキシのオン・オフを比べるときは、ほかの条件をそろえる
  • ✅ エラー全文と、処理が止まった段階を記録する
  • ❌ 原因を確認せずに、複数のプロキシやDNS設定を同時に変更しない

会社や学校のネットワークを利用している場合は、管理者が指定するプロキシや証明書の要件を優先してください。ネットワーク制限を回避する目的で不明な中継先を設定すると、ソースコードや認証情報が第三者に見られるリスクがあります。利用が許可された経路かどうかを確認してから設定を進めましょう。

プロキシ設定の範囲：Git、Docker、npmは別々に考える

プロキシ設定で見落としやすいのは、設定が適用されるプログラムの範囲です。ブラウザーにプロキシを設定しても、GitやDocker、npmが同じ設定を使うとは限りません。VPNクライアントのシステムプロキシモードも、アプリの通信方式やOSの設定によっては、すべてのコマンドライン通信に適用されないことがあります。クライアントに接続済みと表示されているかだけでなく、対象コマンドが実際にその経路を使っているかを確認してください。

Gitでの一時設定と永続設定

GitのHTTPS通信にローカルプロキシを使う場合は、プロキシのアドレスとポートを、利用中のクライアントやネットワークの案内に合わせて設定します。以下は書式の例です。値をそのまま使うのではなく、利用環境で指定された値に置き換えてください。

git config --global http.proxy http://127.0.0.1:PORT
git config --global https.proxy http://127.0.0.1:PORT

特定のリポジトリだけで試したい場合は、作業ディレクトリ内で --local を指定します。接続が改善しない、または別のネットワークへ移動して不要になった場合は、設定を確認して削除してください。グローバル設定は他のリポジトリにも影響します。

git config --global --get http.proxy
git config --global --unset http.proxy
git config --global --unset https.proxy

SSH形式のリモートURLを使っている場合、HTTPS用のGitプロキシ設定だけではSSH通信に適用されません。リモートURLは git remote -v で確認できます。SSH接続を使う必要があるときは、組織が認めた接続方法やネットワーク設定を確認してください。認証トークンをプロキシURLやコマンド履歴に直接書き込むのは避けましょう。

Dockerはイメージ取得とビルド内通信を区別

docker pullの通信を扱うのは、Docker CLIではなくDockerデーモンです。CLI側に設定を書いただけでは、デーモンがイメージレジストリへ接続するときの経路が変わらないことがあります。一方、Docker CLI設定のプロキシ項目は、主にビルド時にコンテナへ渡すプロキシ情報に関係します。どの処理を速くしたいのかに応じて、デーモン、ビルド環境、コンテナ内の設定を分けて確認しましょう。

Dockerデーモンにプロキシを設定する場合は、利用しているOSとDockerの導入方法に合った公式手順を確認してください。設定ファイルを編集する前に既存の内容をバックアップし、他の設定を消さないようにします。変更を反映するにはデーモンの再起動が必要な場合があり、稼働中のコンテナにも影響することがあります。Docker Desktopでは、Linuxサーバー向けの手順をそのまま適用せず、アプリの設定画面や管理者の案内を確認してください。

動作確認の手順：設定を一つずつ切り替える

ここでは、開発PCで遅い通信を切り分ける流れを示します。プロキシのアドレスは例示用の書式にすぎません。ローカルクライアントが実際に待ち受けている値、または管理者が指定した値を使ってください。認証情報を含む設定を共有端末に残さないことも重要です。

  1. 対象を一つ決めます。まずGitのcloneなど、問題を再現できるコマンドを一つ選びます。Docker pullとnpm installも同時に動かすと、回線の競合やキャッシュの影響を区別しづらくなります。作業前の設定とエラー内容を記録してください。
  2. 現在の設定を確認します。Gitでは git config --show-origin --get-regexp 'http.*proxy' で、設定値だけでなく設定元も確認できます。環境変数の HTTP_PROXY、HTTPS_PROXY、NO_PROXY が設定されている場合は、対象コマンドへの影響も調べましょう。表示結果に認証情報が含まれる場合、ログや画面をそのまま公開しないでください。
  3. 現在の経路で再現を確認します。同じコマンドを実行し、どの段階で待つかを観察します。初回取得とキャッシュがある状態では条件が異なります。比較するときは、キャッシュを削除するか残すかを決めて、毎回同じ条件にそろえましょう。
  4. 許可されたプロキシまたはVPNを試します。設定を一つだけ変更して、同じ処理を再実行します。改善しない場合は設定を戻してから、別の条件を試します。プロキシ経由で証明書エラーが出る場合は、証明書検証を無効にせず、管理者に正しい証明書や設定方法を確認してください。
  5. 処理ごとに確認範囲を広げます。Gitの結果を記録した後、Docker pull、npmの順に同じ考え方で確認します。Dockerではデーモンとビルド内の通信を分け、npmでは現在のレジストリとスコープ別の設定を確認します。改善が再現できた設定だけを残し、不要な一時設定は削除します。

VPN経由でGitHubへのアクセスが改善しても、Dockerイメージの取得やnpmパッケージの取得まで改善するとは限りません。各ツールが異なるプロセスやネットワーク名前空間で動いていることがあるためです。Windows、macOS、Linuxのいずれでも、システム設定、クライアントアプリ、コマンドラインツールの設定が一致しているかを確認してください。VPNクライアントの設定や対応OSを確認する場合は、ダウンロード案内を参照できます。

npmレジストリとDNS：速さだけで接続先を選ばない

npmでは、まず現在のレジストリを確認します。組織のパッケージを利用している場合、スコープごとに別のレジストリが設定されていることもあります。登録先を変更すると、公開パッケージだけでなく社内パッケージの取得先や認証動作にも影響するため、現在値とプロジェクト内の設定を確認してから変更してください。

npm config get registry
npm config get @scope:registry
npm config set registry https://registry.npmjs.org/
npm config delete registry

上の @scope は設定例です。実際のスコープ名に置き換えて確認してください。レジストリを変更した後にエラーが出た場合は、プロジェクトの .npmrc、ユーザー設定、環境変数、認証トークンの設定を順に調べます。トークンをソースコードへ直接書いたり、公開リポジトリへコミットしたりしないでください。社内で指定されたレジストリがある場合は、速度だけを理由に公開レジストリへ切り替えず、運用ルールに従います。

DNSは接続先の名前をIPアドレスに解決する仕組みです。名前解決に時間がかかる場合には改善要因になり得ますが、転送中のデータ量や遠い経路そのものを解消するものではありません。DNSを変更する前に、同じホスト名で繰り返し再現するか、特定ネットワークだけで起きるかを確かめましょう。VPN接続中にOSのDNS設定だけを変えると、VPN側の名前解決や社内ドメインへのアクセスと整合しなくなる場合があります。手当たり次第に公開DNSを指定するのではなく、ネットワーク管理者やVPNクライアントの案内を優先してください。

CIでの設定と認証情報の保護

CIで遅延が起きる場合は、開発PCと同じ設定をそのまま持ち込まず、実行環境がどこにあるか、どのプロセスが外部へ接続するかを確認します。ホスト上のDockerデーモンがイメージを取得する通信と、コンテナ内のビルドコマンドがnpmへ接続する通信は別です。CIサービスのネットワーク設定や管理者が用意したキャッシュ、内部レジストリがある場合は、まずその公式な利用方法を確認してください。

プロキシの認証情報やnpmトークンは、CIのシークレット機能から実行時に渡し、リポジトリやビルドログへ出力しないようにします。設定ファイルを生成する手順では、権限を必要最小限にし、値をコマンドライン引数へ直接書くことでログに残らないかも確認しましょう。ビルド失敗時のログを共有するときは、URL、環境変数、設定ファイルに認証情報が含まれていないか確認してから共有します。

CIのキャッシュは、同じ依存関係を毎回ネットワークから取り直す回数を減らせる場合があります。ただし、キャッシュキーを適切に管理し、ロックファイルや依存関係が変わったときに古い内容を誤って再利用しないようにしてください。Dockerのレイヤーキャッシュも、ビルド手順やコピーするファイルの順序によって再利用のされ方が異なります。キャッシュの導入後は、キャッシュが使われたか、依存関係の更新が反映されたかをログで確かめます。

  • ✅ Git、デーモンのpull、ビルドコンテナ内の通信を別々に計測する
  • ✅ 認証情報はCIのシークレットとして管理し、ログに出力しない
  • ✅ レジストリの変更は社内ルールとパッケージの取得元を確認して行う
  • ❌ TLS証明書の検証を無効にして、接続エラーを隠さない
  • ❌ 開発PCの認証情報やプロキシ設定をCIへそのままコピーしない
結論：Git、Docker、npmで遅い工程を分け、プロキシの適用範囲と取得先を一つずつ確認するのが近道です。速度だけで判断せず、認証情報、証明書、パッケージの取得元を安全に保てる設定を選びましょう。
無料で試す