--- title: "BuildKitとは｜Dockerの新ビルドバックエンドの仕組み・キャッシュ/secret/マルチアーキと採用判断を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15701/" published: 2026-07-26 updated: 2026-09-27 categories: ["Kubernetes・コンテナ"] publisher: "株式会社一創" --- # BuildKitとは｜Dockerの新ビルドバックエンドの仕組み・キャッシュ/secret/マルチアーキと採用判断を実装者目線で解説 BuildKit（ビルドキット／moby/buildkit）は、Dockerがコンテナイメージを組み立てるときに裏で動く「ビルドバックエンド」です。Dockerfileの命令を上から順に流す従来のビルダーと違い、BuildKitはビルド手順をLLBという中間形式に変換し、DAG（有向非巡回グラフ）として依存関係を解いてから、互いに影響しないステップを並列で実行します。この記事で扱うのは、LLBとフロントエンドという中核の仕組み、変更のない層を作り直さない差分キャッシュ、イメージに認証情報を残さず渡すビルドシークレット、1コマンドで複数アーキテクチャ向けを作るマルチプラットフォームビルド、そして`docker build`やBuildxとの関係とEngine 23.0以降のデフォルト化です。すでに手元のDockerで既定として動いているものを、仕組みから理解して使いこなし、単体運用まで判断できる状態を目指します。バージョンは0.31系（2026年7月時点）を基準にします。 ## まとめ：BuildKitは並列DAGでイメージを速く安全に作る現代のビルドバックエンド 先に結論を示します。BuildKitは、Dockerfileを逐次実行するのをやめ、ビルド全体を依存グラフ（DAG）として解いてから独立した処理を並列に走らせる、Docker公式のビルドエンジンです。中核はLLBという中間表現と、ビルドグラフのチェックサムを直接見る精密なキャッシュにあります。これにより、変更していない層は作り直さず、変わったファイルだけを転送し、複数のビルドステージを同時に進める設計です。結果として、大きなイメージほどビルド時間が縮みます。 もう1つの核心が安全性です。`RUN --mount=type=secret`で渡した認証トークンはイメージの層に焼き付かず、SSH鍵もフォワードだけで完結します。そして`docker build`はDocker Engine 23.0以降、Buildx経由でBuildKitを既定ビルダーとして使っています。つまり多くの現場で論点は「BuildKitを入れるか」ではなく「既定で動いているBuildKitをどう使いこなし、CIやKubernetesで単体運用まで踏み込むか」です。単純な小さいイメージでは効果が薄く、キャッシュ・シークレット・マルチアーキの要件が出て初めて真価が出ます。 ## BuildKitの基本｜LLBとフロントエンドで成り立つビルドエンジン BuildKitを理解する近道は、「Dockerfileはそのまま実行されず、いったんLLBという設計図に翻訳されてから解かれる」という一点をつかむことです。なお、Dockerfileそのものを書かずにソースコードから直接イメージを組む選択肢もあり、仕組みは[Cloud Native Buildpacksとは？Dockerfile不要のイメージ生成とリベース運用](https://www.issoh.co.jp/tech/details/16909/)で扱っています。ここでは全体像から入ります。 ### BuildKitとは何か｜Dockerfileを並列に解いて実行するバックエンド BuildKitは、コンテナイメージのビルドを担当するツールキットで、Moby（Dockerのオープンソース中核）プロジェクトの一部として開発されています。従来のビルダーがDockerfileの命令を1行ずつ順番に実行していたのに対し、BuildKitはまずビルド全体を依存グラフに落とし込む点が出発点です。あるステージが別のステージの成果物を待つ必要があるか、逆に無関係で先に走らせられるかを解析し、独立した処理は同時に実行します。最終イメージに影響しない命令はグラフから取り除かれ、無駄な処理が走りません。BuildKitはコンテナ技術の一部品であり、そもそもコンテナとは何かという前提から企業の導入判断までは[コンテナとは何かと導入判断の解説](https://www.issoh.co.jp/column/details/13000/)で整理しています。 ### LLBとフロントエンド｜Dockerfileを中間形式に変換する二層構造 BuildKitの拡張性を支えるのが、LLB（Low-Level Build）とフロントエンドの二層構造です。LLBは、内容アドレス方式（content-addressable）の依存グラフを表す中間バイナリ形式で、ビルド手順の「設計図」にあたります。この設計図を人間が直接書くわけではありません。Dockerfileのような人間可読な形式をLLBへ変換する部品が、フロントエンドです。フロントエンドはイメージとして配布でき、Dockerfileの先頭に「# syntax=docker/dockerfile:1」と書けば、Dockerfileを解釈するフロントエンドのバージョン系列を固定できます。この一行があれば、Docker本体を更新しなくても新しいDockerfile構文を先取りできる仕組みです。LLBを直接生成する独自フロントエンドを作れば、Dockerfile以外の定義からもイメージを組み立てられます。 ### 従来ビルダーとの違い｜逐次実行から並列DAGと精密キャッシュへ 旧来の（レガシー）ビルダーとBuildKitの違いは、実行モデルとキャッシュの精度に表れます。レガシービルダーは命令を逐次実行し、キャッシュはヒューリスティック（経験則）でヒットを判定していました。対してBuildKitは依存グラフを並列に解き、キャッシュはビルドグラフのチェックサムを直接追跡する方式です。ビルドコンテキスト（送り込むファイル群）についても、前回からの差分だけを転送し、使われないファイルは転送自体をスキップします。大量のファイルを含むプロジェクトでは、この差分転送だけでビルド開始までの待ち時間が縮む形です。挙動の差が最も出るのはマルチステージビルドで、依存のない各ステージが同時に進むため、ステージ数が多いほど短縮幅が広がります。 ## BuildKitで速く安全になる仕組み｜キャッシュ・secret・マルチアーキ BuildKitの効きどころは、並列化だけではありません。ビルド時間を縮める仕掛けと、認証情報を守る仕掛けが揃っています。実務で押さえるべき3つを順に見ます。 ### ステージ並列とキャッシュマウント｜変更のない層を作り直さない ビルド高速化の主役は、精密なキャッシュとキャッシュマウントです。BuildKitは各ステップのチェックサムを追跡するため、入力が変わっていない層はそのまま再利用します。加えて`RUN --mount=type=cache`を使うと、パッケージマネージャのダウンロードキャッシュ（npmやpip、aptなどのローカルキャッシュ）を層に焼き込まずにビルド間で持ち回せる点が効きます。依存関係のダウンロードを毎回やり直さずに済むため、依存の多いアプリケーションほど短縮効果が読める仕組みです。CIでは`--cache-to`／`--cache-from`でキャッシュをレジストリへ書き出し・読み込みでき、実行環境が毎回まっさらなCIランナーでもキャッシュを共有できます。CIでのビルド短縮をパイプライン全体の設計に落とす観点は[CI/CDの仕組みと導入判断の解説](https://www.issoh.co.jp/column/details/13002/)で扱っています。 ### ビルドシークレットとSSHフォワード｜認証情報をイメージに残さない BuildKitが安全面で評価されるのは、機密情報の扱いです。プライベートリポジトリの取得やライセンス認証で必要なトークンを、`RUN --mount=type=secret`で渡すと、その値はビルド中のその`RUN`だけで見え、完成イメージの層には残りません。従来`ARG`や`ENV`で渡したトークンがイメージ履歴に焼き付いて漏れる、という事故を避けられます。SSH鍵も`--mount=type=ssh`でエージェントをフォワードすれば、鍵ファイルをイメージに含めずプライベート依存を取得できる仕組みです。認証情報をビルド成果物に残さない設計は、そのイメージを社内外のレジストリへ配布する前提では前提条件になります。ビルドしたイメージの置き場と配布の判断は[コンテナレジストリの種類と導入判断の解説](https://www.issoh.co.jp/tech/details/13259/)にまとめています。 ### マルチプラットフォームビルド｜1コマンドで複数アーキ向けを生成 BuildKitは、1回のビルドで複数のCPUアーキテクチャ向けイメージを作れます。`--platform`にlinux/amd64とlinux/arm64を並べて指定すると、両アーキテクチャ向けのイメージと、それらを束ねるマニフェストリストが一度に生成される流れです。Apple Silicon（arm64）のローカルとx86\_64（amd64）の本番サーバー、あるいはAWS GravitonのようなArmインスタンスへ同じイメージを配りたい場合に、CI側でエミュレーションやクロスビルドを組み合わせて対応できます。従来はアーキテクチャごとに別々にビルドしてマニフェストを手で束ねる手間がありましたが、BuildKitではその工程が1コマンドに収まります。 この仕組みをGitHub Actions上で動かす手順は、[GitHub ActionsでDockerイメージをビルドする｜push先とキャッシュ・マルチアーキの設計](https://www.issoh.co.jp/tech/details/16943/)にまとめました。 ## BuildKitの使い方｜docker build・Buildx・buildkitd運用 BuildKitは、普段の`docker build`の裏側としても、独立したデーモンとしても動きます。どの入り口から使うかで運用が変わります。 ### docker buildとBuildx｜Engine 23.0以降はデフォルトで有効 いちばん身近な入り口が`docker build`です。Docker Engine 23.0（2023年2月）以降、`docker build`はBuildxプラグイン経由でBuildKitを既定ビルダーとして使います。つまり最近のDocker Desktopや Docker Engineを使っていれば、特別な設定なしにBuildKitのビルドが走っています。それ以前のバージョンでは、環境変数`DOCKER_BUILDKIT=1`を付けて明示的に有効化する必要がありました。`docker buildx`はBuildKitを操作するCLIプラグインで、複数のビルダーインスタンスの管理やマルチプラットフォームビルド、キャッシュの書き出しといった拡張機能の入り口になります。「BuildKitを使う」とは、多くの場合この`docker build`／`docker buildx`を使うことと同じです。Buildxの実行環境をどこに置くかは、後述の単体運用の判断につながります。 ### syntaxディレクティブ｜フロントエンドのバージョンを固定する Dockerfileの1行目に「# syntax=docker/dockerfile:1」と書くと、そのDockerfileを解釈するフロントエンド（dockerfileフロントエンド）のバージョン系列を固定できます。末尾を「1」とすれば1系の最新を自動で取り込み、Docker本体を更新しなくても新しいRUNマウント構文やヒアドキュメント記法を使える状態になります。逆に「docker/dockerfile:1.7」のようにマイナー系まで指定すれば、フロントエンドの挙動を固定してビルドの再現性を保てる形です。チームでビルド結果を揃えたい場合は、この1行を明示しておくと、環境ごとのDockerバージョン差に振り回されにくくなります。 ### buildkitd単体運用｜Dockerデーモンを置かないビルド環境 BuildKitは、Dockerとは切り離して単体でも動きます。`buildkitd`というデーモンと、それを叩く`buildctl`クライアントの組み合わせで、Dockerデーモンなしにイメージをビルドできる構成です。この形はrootless（root権限なし）でも動かせるため、権限を絞ったCIランナーやKubernetes上でのイメージビルドに向きます。Kubernetesクラスタ内でイメージを作りたいが特権コンテナは避けたい、というセキュリティ要件のあるCI/CDで採られる構成です。Dockerソケットをマウントする方式を避けられるため、ビルド専用のPodとして分離しやすくなります。ただし単体運用は設定と保守の手間が増えるので、必要性は後述の判断章で見極める流れです。コンテナを実際に動かすランタイム側との役割分担は[containerdとDocker・runc/CRIの関係の解説](https://www.issoh.co.jp/tech/details/15681/)で整理しています。 ## 他のイメージビルドツールとの違い｜Buildah・Kaniko・レガシービルダー コンテナイメージを作るツールはBuildKitだけではありません。似た役割のツールと並べると、選定の軸が見えます。 ### Buildah・Kanikoとの比較｜デーモンとイン クラスタビルドの違い 主要なイメージビルドツールを、動作モデルと立ち位置で並べます。BuildKitはDocker公式のビルドバックエンドで、デーモン（buildkitd）を持ちますがrootless運用もできます。BuildahはRed Hat系のツールで、デーモンを持たずコマンド単位でOCIイメージを組み立てる設計です。Kanikoはクラスタ内（Kubernetesのビルド用Pod）でDockerデーモンなしにビルドすることに特化しています。どれもDockerデーモンへの依存を避けられますが、キャッシュの精密さやマルチプラットフォーム対応の作り込みではBuildKitが厚い一方、Podman中心の環境ではBuildahが素直に収まります。 | ツール | 提供元・位置づけ | デーモン | 得意な場面 | | -------- | ----------------------- | -------------------- | ---------------------- | | BuildKit | Docker/Moby公式のビルドバックエンド | buildkitd（rootless可） | 並列DAG・精密キャッシュ・マルチアーキ | | レガシービルダー | 旧Dockerの内蔵ビルダー | Dockerデーモン | 単純イメージの逐次ビルド（現在は非推奨） | | Buildah | Red Hat系・Podmanと同系統 | デーモンレス | Podman環境・OCIイメージを細かく生成 | | Kaniko | Google発・クラスタ内ビルド特化 | デーモンレス | K8s上でソケットを使わないビルド | 実務では、まずレガシービルダーは非推奨のため候補から外します。Docker中心ならBuildKit（＝`docker build`の既定）で足り、Podman中心ならBuildahが自然です。デーモンレスなイメージビルダーどうしの比較は[Buildahのデーモンレス・rootlessな仕組みと導入判断の解説](https://www.issoh.co.jp/tech/details/15687/)で掘り下げています。 ## BuildKitを使いこなす場面と単体運用を見送る場面（採用判断） ここは独自の観点で判断を言い切ります。BuildKitは既定で動いているため、判断の主眼は「拡張機能をどこまで使うか」と「単体運用に踏み込むか」です。 ### 使いこなすべき場面｜キャッシュ・secret・マルチアーキが要るとき BuildKitの拡張機能を積極的に使うべきなのは、次の条件が出たときです。CIでビルドが遅く、依存ダウンロードを毎回やり直しているなら、`--mount=type=cache`とレジストリキャッシュ（`--cache-to`／`--cache-from`）で待ち時間を削れます。プライベートリポジトリのトークンやライセンス鍵をビルド時に使うなら、`--mount=type=secret`で認証情報をイメージに残さない構成にすべきです。Apple Siliconとx86サーバー、あるいはArm系インスタンスへ同じイメージを配るなら、`--platform`のマルチアーキビルドが手間を1コマンドに畳みます。これらは要件が明確なので、該当するなら迷わず使いこなす側に倒します。 ### 単体運用を見送る場面｜既定で足りるとき・イメージが単純なとき 逆に、`buildkitd`単体運用まで踏み込むのを見送るべき場面もあります。Docker Engine 23.0以降を使い、`docker build`の既定BuildKitで足りているなら、あえて`buildkitd`＋`buildctl`を別立てする必要はありません。単体運用は設定と保守の手間が増え、小規模チームには過剰投資になりがちです。ビルド対象が数命令の単純なイメージで、依存も浅く、マルチアーキやシークレットの要件がないなら、並列化やキャッシュの恩恵は小さく、既定のまま何も足さない判断が正解です。単体運用を検討する価値があるのは、Kubernetes上で特権を避けてビルドしたい、Dockerソケットを露出させたくない、というセキュリティ要件がはっきりある場合に絞られます。自社のコンテナビルド基盤やCIパイプラインをクラウド上でどう設計・実装するかで迷う段階なら、AWSやGoogle Cloud上の基盤構築を含めて[クラウドインフラ構築の受託](https://www.issoh.co.jp/service/system/aws/)で相談を受け付けています。 ## BuildKitの有効化・Buildx・Buildahに関するよくある質問 BuildKitの有効化やBuildx・Buildahとの違いなど、実務でよく挙がる疑問に答えます。 ### BuildKitはどうやって有効にしますか？ Docker Engine 23.0（2023年2月）以降を使っていれば、`docker build`はBuildxプラグイン経由でBuildKitを既定ビルダーとして使うため、特別な設定は不要です。それ以前のバージョンでは、環境変数`DOCKER_BUILDKIT=1`を付けてビルドを実行するか、Dockerデーモンの設定ファイルでBuildKitを有効化します。まず`docker version`や`docker buildx version`で使用中のバージョンを確認し、23.0以降ならそのままBuildKitのビルドが走っていると考えて差し支えありません。 ### BuildKitとBuildxの違いは何ですか？ BuildKitはビルドを実行するバックエンド（エンジン）そのもので、Buildxはそれを操作するCLIプラグインです。役割が層で分かれており、Buildx（`docker buildx`）がユーザーからの指示を受け取り、裏でBuildKitがビルドを実行します。マルチプラットフォームビルドや複数ビルダーの管理、レジストリへのキャッシュ書き出しといった拡張機能は、Buildxの入り口から使います。両者はセットで動くもので、対立する選択肢ではありません。 ### BuildKitとBuildahはどう違いますか？ BuildKitはDocker/Moby公式のビルドバックエンドで、`docker build`の裏側として既定で動きます。BuildahはRed Hat系のツールで、デーモンを持たずコマンド単位でOCIイメージを組み立てる設計です。Docker中心の環境ならBuildKit、Podman中心の環境ならBuildahが素直に収まります。両者ともDockerデーモンへの依存を避けられますが、精密キャッシュやマルチアーキ対応の作り込みではBuildKitが厚く、スクリプトで細かくイメージを構築する自由度ではBuildahに分があります。 ### BuildKitでビルドが速くなるのはなぜですか？ 大きく3つの仕掛けが効きます。1つ目は並列化で、ビルドを依存グラフ（DAG）として解き、互いに依存しないステージを同時に実行します。2つ目は精密なキャッシュで、ビルドグラフのチェックサムを直接追跡し、変わっていない層を作り直しません。3つ目は差分転送で、ビルドコンテキストのうち前回から変わったファイルだけを送り、未使用ファイルは転送自体をスキップします。マルチステージで依存の浅いビルドほど、これらの効果が読めます。 ### BuildKitはKubernetes上で使えますか？ 使えます。`buildkitd`デーモンをKubernetes上のPodとして動かし、rootlessで特権コンテナを避けたビルドを組めます。Dockerソケットをマウントする方式を避けたいCI/CD環境で採られる構成です。ただし設定と運用の手間が増えるため、既定の`docker build`で足りる規模ではなく、クラスタ内ビルドのセキュリティ要件がはっきりある場合に絞って検討するのが現実的です。 ## 関連記事 - [コンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説](https://www.issoh.co.jp/column/details/13000/)：BuildKitが作る「コンテナイメージ」の前提となる、コンテナそのものの概念と導入判断をまとめた判断ハブ記事です。 - [Buildahとは？デーモンレス・rootlessでOCIイメージを作る仕組みと導入判断を解説](https://www.issoh.co.jp/tech/details/15687/)：BuildKitと並ぶイメージビルドツールで、Podman環境での選択肢として比較の軸になります。 - [containerdとは？Dockerとの関係・runc/CRIの仕組みとKubernetesでの役割を解説](https://www.issoh.co.jp/tech/details/15681/)：ビルドしたイメージを実際に動かすランタイム側で、ビルドと実行の役割分担を理解できます。 - [コンテナレジストリとは？種類・選び方から企業の導入判断まで解説](https://www.issoh.co.jp/tech/details/13259/)：BuildKitで作ったイメージの配布先で、キャッシュの書き出し先としても関わります。 - [CI/CDとは？仕組み・パイプライン・導入すべき企業の判断基準を解説](https://www.issoh.co.jp/column/details/13002/)：BuildKitのキャッシュ機能が最も効く、CIパイプラインでのビルド高速化の文脈です。 --- 出典: [BuildKitとは｜Dockerの新ビルドバックエンドの仕組み・キャッシュ/secret/マルチアーキと採用判断を実装者目線で解説]()（株式会社一創）