記事本文へ移動
チュートリアル 約10分

GitHubのcloneやDocker取得が遅い開発者へ｜npm・pipも快適にする設定術

GitHubのclone、Dockerイメージのpull、npm・pipの依存関係取得など、開発者がつまずきやすい通信をまとめて見直します。ローカルとCIそれぞれの設定の考え方、認証情報やパッケージソースを安全に扱うポイントを確認できます。

GitHubのclone、Dockerイメージのpull、npmやpipの依存関係取得が遅いときは、回線だけでなく、DNS、プロキシの適用範囲、接続方式、レジストリ、キャッシュ、CIランナーの外向き通信を順に確認しましょう。ブラウザーでは問題なく見えても、GitやDockerのデーモン、ビルドプロセスが同じプロキシ設定を使っているとは限りません。まず遅い処理と実行環境を切り分け、変更は一度にひとつに絞ると、原因を特定しやすくなります。

最初に遅い段階を切り分ける

「開発環境の通信が遅い」という症状だけでは、ネットワーク経路の問題か、サービス側の応答か、ローカルのディスクやCPUの処理待ちかを区別できません。たとえばcloneでは、リポジトリへの接続、オブジェクトの転送、展開のどこで時間がかかるかを見ます。Dockerではレジストリへの接続だけでなく、複数レイヤーの取得や展開、ビルド時の処理も別々に確認します。

まず同じ端末・同じネットワークで、問題が発生するコマンド、実行時刻、エラー全文、対象リポジトリやイメージ、プロキシの有無を記録します。通常のWebサイトが開けるか、DNSで対象ホストを解決できるか、ほかの開発ツールでも遅延するかも確認してください。会社や学校のネットワークでは、ファイアウォールや許可リストが原因の可能性があります。組織のルールを回避する設定を試すのではなく、管理者に対象ホストとエラーを伝えましょう。

  • ✅ Git、Docker、npm、pipのうち、遅いコマンドを個別に再実行する
  • ✅ 端末上の処理か、CI上の処理かを区別する
  • ✅ プロキシ設定、DNS、ネットワーク切り替えの有無を記録する
  • ❌ 原因を確認せず、複数のミラーやプロキシを同時に追加しない

VPNやプロキシを使っている場合も、接続中という表示だけではGitなどの通信がその経路を通っていると断定できません。クライアントのルール設定、システムプロキシ、アプリごとのプロキシ設定、Dockerデーモンの設定は別々に働くことがあります。利用中のクライアントの設定と、各ツールが実際に参照している値を照合してください。基本的な導入手順は新手指引ではなく、日本語ページの初期設定ガイドで確認できます。

切り分けの要点：遅いコマンドと通信段階を先に特定し、経路・DNS・取得元・ローカル処理をひとつずつ確認しましょう。

Git cloneは履歴とプロキシ設定を見直す

大きなリポジトリを丸ごと取得する必要がない作業では、取得する履歴やファイルを減らす方法が有効です。最新の作業ツリーが必要で、過去の履歴を使わない場合は浅いcloneを検討できます。blobの遅延取得を使う方法は、作業時に必要なファイルを追加取得するため、初回転送を抑えられる場合があります。一方、全履歴の調査、タグを使ったビルド、オフライン作業などでは不足が生じることがあります。

# 履歴を限定して取得する例
git clone --depth 1 https://github.com/OWNER/REPOSITORY.git

# ファイル内容の取得を必要時まで遅らせる例
git clone --filter=blob:none https://github.com/OWNER/REPOSITORY.git

# Gitが認識している関連設定を確認する
git config --show-origin --get-regexp 'http\..*|url\..*'

OWNER/REPOSITORYは実際の対象に置き換えてください。浅いcloneやフィルター付きcloneは、通信量を抑えるための選択肢であり、すべての開発作業に適するわけではありません。ブランチやタグが必要な手順では、その手順が要求する履歴を確保します。CIで利用する場合も、後続のテストやバージョン計算が履歴を参照していないか確認してから変更しましょう。

Gitのプロキシ設定を確認するときは、設定の保存元も見ます。システム、ユーザー、リポジトリ単位の値や環境変数が異なると、意図しない設定が優先されることがあります。ローカルのHTTPプロキシを利用する例は次のとおりですが、アドレスとポートは使用中のクライアントの案内に合わせてください。

# 例：ローカルのHTTPプロキシをGitに設定する
git config --global http.proxy http://127.0.0.1:7890

# 不要になったユーザー設定を削除する
git config --global --unset http.proxy

プロキシを使う場合は、GitのHTTPS接続に設定が適用されるかを確認します。SSH形式のリモートURLでは、HTTPS用の設定がそのまま適用されるとは限りません。認証情報を含むURLを設定ファイルやシェル履歴に残すのも避けてください。TLS証明書の検証を無効にしたり、出所のわからない証明書を信頼させたりする方法は、通信の安全性を損なうため、速度対策として使ってはいけません。

Dockerはデーモン、レジストリ、キャッシュを分けて考える

docker pullが遅い場合、Docker CLIを起動したシェルのプロキシ環境変数だけを変更しても、Dockerデーモン側の通信経路には反映されないことがあります。Docker Desktopを使う環境ではアプリ側のプロキシ設定を、Linuxのデーモンでは管理者が設定したサービス環境を確認します。設定を変えた後は、デーモンやDocker Desktopの再起動が必要な場合があります。管理された端末では、組織の手順に従ってください。

レジストリミラーを設定する場合は、組織が承認したもの、または運用元と内容を検証できるものに限定します。任意のミラーは、取得物の鮮度、アクセス制御、プライバシー、障害時の挙動に影響します。公開イメージを指定する際も、意図した提供元とタグを確認し、再現性や供給元の検証が重要なビルドでは、チームの方針に沿ってイメージのダイジェストを固定します。

ビルドのたびにベースイメージや依存関係をすべて取り直しているなら、ビルドキャッシュが維持されているか確認します。Dockerfileの命令順やコピー対象が変わると、キャッシュが無効になる場合があります。依存関係の定義を先にコピーしてインストールし、その後に頻繁に変わるソースコードをコピーする構成は、依存関係の層を再利用しやすくする一例です。ただし、キャッシュには古い成果物が残る可能性もあるため、更新やセキュリティ確認を妨げない運用にします。

レイヤー取得が止まるのか、取得後の展開が遅いのかも分けて観察してください。ディスク容量不足、ディスクI/O、CPU負荷が原因なら、ネットワーク経路を変えても改善しません。チームの利用規約やセキュリティ要件に沿って、レジストリの状態とローカルのリソースを確認しましょう。

Dockerの要点：CLIとデーモンの設定を混同せず、信頼できるレジストリと再利用可能なキャッシュを別々に点検します。

npm・pipは取得元とロック情報を守る

パッケージマネージャーでは、取得先の変更がすべてのプロジェクトに及ぶことがあります。まず現在の設定と、プロジェクト内の設定ファイルを確認しましょう。npmではレジストリ設定、プロジェクトの設定ファイル、ロックファイルを確認できます。pipでは設定ファイルや環境変数に指定されたインデックスを確認します。想定していないホストへ接続している場合は、プロキシの有無と設定の適用範囲を調べてください。

# npmの取得先を確認する
npm config get registry

# pipの有効な設定を確認する
python -m pip config list

# pipで利用する取得先の例
python -m pip install --index-url https://pypi.org/simple PACKAGE

取得先を変更する必要がある場合は、パッケージの正規提供元または組織が管理する信頼できるレジストリを使い、プロジェクトとチームの設定をそろえます。第三者のミラーを使うなら、運用主体、更新方針、認証方法、障害時の扱いを確認してください。パッケージ名の取り違えや、同名パッケージを使った攻撃を防ぐため、取得元を安易に切り替えないことも重要です。

チームやCIでは、依存関係のロックファイルをバージョン管理し、npmなら用途に応じてnpm ciを利用します。これにより、ロックファイルに基づくインストールを行いやすくなりますが、通信が必ず速くなるわけではありません。pipでも依存バージョンやハッシュの固定を含め、再現性と更新手順をプロジェクトの方針に合わせます。キャッシュを使う場合も、キャッシュが破損したときに更新できる手順を用意しましょう。

認証トークンやユーザー名・パスワードをコマンドライン、公開ログ、共有設定ファイルに書き込まないでください。CIでは秘密情報の保管機能を使い、ログ上で値がマスクされることを確認します。TLS検証を無効にして速度や接続性を改善しようとするのも避けましょう。

ローカルとCIで一項目ずつ検証する

ここでは、設定を増やしすぎずに原因を見つける手順を紹介します。ローカルとCIでは実行環境やネットワーク制限が異なるため、同じ設定をコピーして終わりにせず、それぞれで確認します。テスト中に変えるのは一度にひとつの項目です。変更前の値と、成功・失敗したコマンドを記録しておけば、元に戻す判断もしやすくなります。

  1. 元の状態を記録する。遅いコマンド、エラー全文、使用OS、ネットワーク、プロキシの有無、GitやDockerなどのバージョンを控えます。認証情報やトークンは記録に含めません。
  2. ネットワーク経路を確認する。対象ホストの名前解決、通常のHTTPS接続、クライアントのルール設定、ツール別のプロキシ設定を確認します。一般的なWeb通信が成功しても、レジストリやGitの通信が許可されているとは限りません。
  3. 取得する内容を減らせるか調べる。Gitの履歴制限、Dockerのビルドキャッシュ、不要な依存関係の削減などを、プロジェクトの要件を損なわない範囲で試します。処理の再現に必要なデータまで省かないようにしてください。
  4. 信頼できる取得元を確認する。Gitの接続方式、Dockerのレジストリ、npmやpipのインデックスを確認し、意図しない上書きや不明なミラーがないか調べます。
  5. CIで独立して検証する。ランナーから対象サービスへの外向き通信、秘密情報の設定、キャッシュの保存と復元、ログへの認証情報の露出を確認します。CIサービスや組織のネットワーク制約がある場合は、管理者の承認を得てください。
  6. 変更後に再現性を確かめる。同じコマンドを再実行し、取得内容やテスト結果が変わっていないことを確認します。改善しなければ、変更を戻して次の原因候補へ進みます。

VPNやプロキシは、経路の混雑やネットワーク方針が原因のときに選択肢となりますが、すべてのサービスや環境で速度を改善する保証はありません。開発ツールだけを経由させる必要がある場合は、クライアントのルール分岐がGit、レジストリ、認証先の通信にどう適用されるか確認します。CIでは、使用するランナーがその接続方式を許可しているか、資格情報の取り扱いが規定に合っているかを先に確認してください。

ネットワーク側の問題が疑われる場合は、ネットワーク診断で接続状況を確認し、クライアントやOSごとの設定を調べます。インストール方法を確認する場合は初期設定ガイドも参照できます。設定を変更しても改善しないときは、DNS、TLS証明書、ファイアウォール、組織の許可ポリシー、サービス側の障害を分けて確認し、必要に応じて管理者や対象サービスのサポートに相談しましょう。

安全な改善の結論：取得元の信頼性、認証情報、TLS検証を保ったまま、ローカルとCIを別々に測定し、再現できる変更だけを採用します。
無料で始める