クラウド実行環境

Dockerとは|命令を2行入れ替えただけで、1回の組み立てが122.6秒から44.4秒になった

Dockerの層とは何か命令の並べ方で何が変わるのか作り直しはどこまで波及するのか

変更200回のうち165回はソースだけの変更でした。依存は変わっていません。

それでも依存の導入が毎回走ると、1回あたり122.6秒です。並べ替えると44.4秒になりました。

この記事の要点

  • ソースを先に置くと122.6秒
  • 依存定義を先に置くと44.4秒
  • 再利用できた層は186層と516層
  • 変更の82.5%はソースのみ

命令を2行入れ替えただけで、1回の組み立てが122.6秒から44.4秒になった

変更の大半はソースだけです。依存の導入をその前に置けるかどうかで、時間が決まります。

Dockerの組み立て時間は、命令の並べ方で大きく変わります。実際に計算して差を出しました。

変更を200回分用意しました。内訳はソースのみ165回・依存の更新21回・土台の更新14回です。

層ごとの時間も置きました。依存の導入が95秒、組み立てが25秒、土台の取得が8秒、取り込みが数秒です。

並べ方を変える

text
変更 200回。内訳はソースのみ 165回・依存の更新 21回・土台の更新 14回
層は上から順に作られ、1つ作り直すとそれより下も全部作り直しになる

並べ方                  1回あたり  合計      作り直した層  再利用できた層
ソースを先に置く                   122.6秒    24512秒          614層            186層
依存定義だけ先に置く                  44.4秒     8872秒          484層            516層

ソースを先に取り込むと、1回あたり122.6秒です。ソースが1文字変わるたびに依存の導入が走ります。

依存定義だけ先に取り込む形にすると44.4秒になりました。2.8倍の差です。

再利用できた層で見る

右端の列が効き方を表しています。再利用できた層は186層と516層で、2.8倍です。

並べ替えでやっていることは1つだけです。変わりにくいものを先に、変わりやすいものを後に置きます。

出典もこの波及をある層が変われば、それより後ろにあるほかの層もすべて影響を受けると説明しています。

並べ替えると、再利用できる層が2.8倍になる。

ソースを先に置く再利用できた186作り直した614800層依存定義だけ先に置く5164841000層+25%(200層)変更200回での計算。層の数が違うのは、並べ方で命令の数が1つ増えるため。
図1 ── 並べ方ごとの層の内訳
出典Docker Docs「Docker build cache」2026-08-18 確認
If a layer changes, all other layers that come after it are also affected.
原文Docker Docs「Docker build cache」 この内容の有効期限2027-02-18

Dockerの層とは何か

命令1つが層1つになります。層は上から積まれ、下の層は上の層の上に成り立ちます。

Dockerでは、手順書に書いた命令1つが層1つになります。出典もこの対応を明記しています。

その言い方はこの手順書の各命令が、最終的なイメージの1つの層に対応するというものです。

積み方の順番

変わりにくいものを上に、変わりやすいものを下に置く。

全 5 段8秒土台の取得変わりにくい1秒依存定義の取り込みたまに変わる95秒依存の導入ここが重い2秒ソースの取り込み毎回変わる25秒組み立て毎回走る依存の導入が95秒。これを作り直すかどうかで、1回あたりの時間がほぼ決まる。
図2 ── 層の並びと、それぞれにかかる時間

この並びなら、ソースが変わっても依存の導入までは再利用できます。走るのは下2つの27秒だけです。

何が層を無効にするか

  1. 命令そのものの変更。書き換えれば作り直しになる
  2. 取り込むファイルの変更。中身が変われば作り直し
  3. 土台の更新。上流が変わると全部作り直し
  4. 順番の入れ替え。並びが変われば以降が作り直し

2番目が要注意です。取り込む対象を広くすると、関係ないファイルの変更でも作り直しになります

手順書の隣に除外の設定を置き、取り込む対象を絞ります。ログや作業用の一時ファイルを含めないだけで効きます。

出典Docker Docs「Docker build cache」2026-08-18 確認
Each instruction in this Dockerfile translates to a layer in your final image.
原文Docker Docs「Docker build cache」 この内容の有効期限2027-02-18

手元では効いても、自動実行では効かないことがある

再利用は、前回の層が残っている場所でしか働きません。毎回まっさらな環境では効きません。

Dockerの再利用は、前回作った層が手元にあることが前提です。出典も条件を述べています。

その言い方は層が変わるたびに、その層は作り直しが必要になるというものです。裏を返せば、変わらなければ作り直しません。

まっさらな環境で消える

自動実行の環境は、多くの場合毎回まっさらから始まります。前回の層が残っていません。

この状態では、並べ方を工夫しても毎回すべての層を作り直します。手元では44.4秒でも、自動実行では130秒かかります。

  1. 層を保存所に押す。前回の層を取り寄せて使う
  2. 作業機を使い回す。まっさらにしない
  3. 専用の保管場所を使う。層だけを別に持つ
  4. 土台を自前で作る。依存まで含めた土台を用意する

4番目は、依存が安定している場合に効きます。依存の導入そのものを、日々の組み立てから外せます

効いているか確かめる

組み立ての記録を見れば、どの層が再利用されたか分かります。毎回すべて作り直しているなら、並べ方の工夫は届いていません

層の保存量そのものはコンテナレジストリの記事で扱っています。共有できる範囲で大きく変わります。

前回の層が残っていなければ、並べ方の工夫は効かない。

充足 2 / 4変わりにくいものを先に置いている並べ替えるだけで1回あたりが122.6秒から44.4秒になる前回の層を取り寄せているまっさらな環境では、並べ方を工夫しても毎回すべて作り直しになる取り込む対象を絞っていない関係ないファイルの変更でも、その層から後ろが作り直しになる手元の速さだけを見ている手元で44.4秒でも、自動実行では130秒かかることがある変更200回での計算にもとづく。層ごとの時間は置いた値。
図3 ── 組み立てを速くする前の点検項目
余談 この計測での注意

層ごとの時間は置いた値です。依存の導入95秒という比重が、この差の大きさを決めています。依存が軽い場合は差も小さくなります。変更の内訳も、ソースのみが8割強という前提です。ここで見せているのは、変更の頻度が高いものを後ろに置くほど再利用が増えるという関係です。

出典Docker Docs「Docker build cache」2026-08-18 確認
Whenever a layer changes, that layer will need to be re-built.
原文Docker Docs「Docker build cache」 この内容の有効期限2027-02-18

よくある質問

Dockerの層とは何ですか
命令1つが1つの層になります。ある層が変わると、それより後の層はすべて作り直しになります。
命令の並べ方で本当に差が出ますか
出ます。この計測では同じ変更200回に対し、1回あたりが122.6秒と44.4秒に分かれました。
なぜ差が出るのですか
変更の大半がソースだけだからです。依存の導入をソースの取り込みより前に置けば、その層は再利用できます。
どこに置けばよいですか
変わりにくいものを先に、変わりやすいものを後に置きます。この計測では依存定義だけ先に取り込みました。

まとめ

  • 命令1つが1つの層になる
  • 1つ変わると後ろが全部作り直し
  • 変わりにくいものを先に置く
  • 差は1回あたり2.8倍

今日から始められること

  1. 直近50回の変更で、何が変わったかを数える
  2. そのうちソースだけの変更が何%かを出す
  3. 依存の導入がその都度走っていないか確かめる
  4. 依存定義だけ先に取り込む形へ並べ替える

実務で組んだDockerのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る