Dockerイメージビルド時の「failed to read dockerfile: open Dockerfile: no such file or directory」エラーの修正

TL;DR

DockerがDockerfileを見つけられないのは、指定したビルドコンテキストディレクトリに存在しないからです。Dockerfileが置かれているディレクトリでdocker buildを実行するか、-fオプションでファイルを明示的に指定してください：

# オプション1：先にディレクトリへ移動する
cd /path/to/your/project
docker build -t myapp .

# オプション2：現在のディレクトリのまま、ファイルパスを指定する
docker build -f /path/to/your/project/Dockerfile -t myapp .

根本原因

docker buildコマンドは必ずビルドコンテキストを必要とします。これはDockerがデーモンに送信するためにパッケージ化するディレクトリです。デフォルト（.を指定した場合）では現在の作業ディレクトリになり、デーモンはそのディレクトリ内でDockerfileを探します。

エラーメッセージの全文はこのようになります：

failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

このエラーが発生する主な原因は以下の通りです：

間違ったディレクトリでdocker build .を実行した — Dockerfileが別の場所にある。
ファイル名が異なる：dockerfile、Dockerfile.dev、DockerFile — Linuxのファイルシステムは大文字・小文字を区別するため、これらはマッチしない。
誰かが誤ってDockerfileを.dockerignoreに追加した。
指定したビルドコンテキストのパスにDockerfileが存在しない。
CI/CDで、パイプラインの作業ディレクトリが設定ファイルの想定と異なる。

手順ごとの解決方法

ステップ1：Dockerfileの実際の場所を確認する

# Linux — 大文字・小文字を区別した検索
find . -name 'Dockerfile' -type f

# macOS — 大文字・小文字を区別しないファイルシステムだが、念のため確認
find . -iname 'dockerfile' -type f

結果が出ない場合、ファイルがまだ存在しません — 新規作成してください。予期しないパスで見つかった場合は、ファイルを移動するか、-fオプションでDockerに正しい場所を指定してください。

ステップ2：正しいディレクトリでdocker buildを実行する

よくある間違い：親ディレクトリや兄弟ディレクトリでdocker build .を実行してしまうことです。.は「現在のディレクトリをビルドコンテキストとして使用する」という意味で、Dockerはその中にDockerfileがあることを期待します。

# 誤り — /home/user にいるが、Dockerfile は /home/user/myapp にある
docker build -t myapp .

# 正しい — 先に cd してからビルドする
cd myapp
docker build -t myapp .

cd 一回で解決します。

ステップ3：標準外の名前や場所には -f を使う

複数の環境を持つプロジェクトでは、ステージごとに個別のDockerfileを用意することがよくあります。ファイルを移動させるのではなく、パスを明示的に指定しましょう：

# デフォルト以外のファイル名の場合
docker build -f Dockerfile.prod -t myapp .

# サブディレクトリにある場合
docker build -f docker/Dockerfile -t myapp .

# ビルドコンテキスト外にある場合（少ないケースだが有効）
docker build -f ../Dockerfile -t myapp .

重要：-fとビルドコンテキスト（最後の引数）は独立しています。コンテキストはビルド中にデーモンがアクセスできるファイルを制御します。-fフラグはDockerfileとして使用するファイルを指定するだけです。この2つを混同すると混乱の原因になりがちです。

ステップ4：.dockerignoreを確認する

.dockerignoreを開いて、Dockerfileにマッチする行がないか確認します：

cat .dockerignore

Dockerfileが記載されていれば、削除してください。通常DockerはDockerfileを特別扱いしてそのエントリを無視しますが、一部のBuildKit設定ではその慣例に従わないため、まさに今見ているエラーが発生することがあります。

ステップ5：CI/CDの作業ディレクトリを修正する

GitHub Actions、GitLab CI、Jenkinsはそれぞれ作業ディレクトリについて独自の考え方を持っています。思い込みは禁物です — 明示的に指定しましょう：

# GitHub Actions: ステップごとに working-directory を設定する
- name: Build Docker image
  run: docker build -t myapp .
  working-directory: ./myapp

# または曖昧さをなくすために絶対パスを使う
- name: Build Docker image
  run: docker build -f ${{ github.workspace }}/myapp/Dockerfile -t myapp ${{ github.workspace }}/myapp

# GitLab CI: ビルド前に明示的に cd する
build:
  script:
    - cd myapp && docker build -t myapp .

ステップ6：Docker Compose — compose.yaml のビルドコンテキストを確認する

docker compose buildでエラーが発生する場合、コンテキストはシェルの現在のディレクトリではなく、composeファイルから取得されます：

# compose.yaml
services:
  app:
    build:
      context: ./myapp        # このディレクトリに Dockerfile が必要
      dockerfile: Dockerfile  # 省略可能 — デフォルトは 'Dockerfile'

contextが親や兄弟ディレクトリではなく、実際にDockerfileが置かれているディレクトリを指しているか、再度確認してください。

動作確認

ビルドを再実行します。正常に動作するコマンドはすぐにレイヤーの出力をストリームします：

docker build -t myapp .

# 期待される出力 (BuildKit):
[+] Building 3.2s (10/10) FINISHED
 => [internal] load build definition from Dockerfile          0.0s
 => [internal] load .dockerignore                             0.0s
 => [internal] load metadata for docker.io/library/node:20    1.4s
 ...

[internal] load build definition from Dockerfileが表示され、次の行にエラーがなければ成功です — DockerがDockerfileを正常に見つけられました。

クイックリファレンス：よくあるシナリオ

間違ったディレクトリ → Dockerfileが置かれているディレクトリへcdしてからビルドする。
標準外のファイル名 → docker build -f Dockerfile.prod .
モノレポ / ネスト構造 → リポジトリルートからdocker build -f services/api/Dockerfile .を実行するか、cd services/api && docker build .を使う。
CIパイプライン → working-directoryを明示的に設定するか、-fで絶対パスを使う。
Docker Compose → compose.yamlのcontext:パスを確認する。