Docker Hubにイメージをプッシュする方法｜ログイン・タグ付け・pushの手順とdeniedエラーの直し方

Docker Hubにイメージを公開するには、アクセストークンで docker login し、イメージに ユーザー名/リポジトリ名:タグ という名前を付けて docker push します。手順は3つだけですが、名前の付け方を間違えると「denied: requested access to the resource is denied」で止まります。この記事では、事前の準備からタグの付け方、複数CPUアーキテクチャ向けのプッシュ、CIでのログイン、よくあるエラーの原因と確認方法、公開前に見ておきたい秘密情報の点検までを説明します。

Docker Hubの画面の項目名、無料プランでできること、取得回数の制限などは変更されることがあります（2026年10月現在）。数値や表記は、作業時にDocker Hubの公式ドキュメントで確認してください。

事前に用意するもの

• Docker Hubのアカウント（Docker ID）：イメージ名の先頭に付く「名前空間」になります。組織（Organization）のリポジトリに置く場合は組織名が名前空間です。
• リポジトリ：Docker Hubの画面で先に作っておくと、公開（Public）か非公開（Private）かを自分で選べます。存在しないリポジトリ名にプッシュすると自動で作られる場合もありますが、そのときの公開範囲はアカウントの既定の設定に従うため、意図せず公開になるのを避けたいなら先に作っておきます。
• アクセストークン：Docker Hubのアカウント設定で個人用のアクセストークン（Personal Access Token）を作ります。作成時に権限の範囲を選べるので、プッシュに使うなら書き込みを含む権限にします。トークンは作成時にしか表示されないので、パスワード管理ツールなどに保管してください。

パスワードの代わりにトークンを使うのは、漏れたときにトークンだけを無効にできるからです。二要素認証を有効にしたアカウントでは、CLIのログインにトークンが要ります。

手順1：docker loginでログインする

docker login -u your-docker-id

パスワードを聞かれたら、アカウントのパスワードではなくアクセストークンを貼り付けます。Login Succeeded と出れば完了です。最近のDocker CLIでは、ブラウザで確認コードを入力してログインする方式を案内されることもあります。

ログイン情報は、資格情報ヘルパー（OSのキーチェーンなど）が設定されていなければ ~/.docker/config.json に保存されます。このファイルにはトークンが復元可能な形で入るため、共有サーバーではファイルの権限に注意し、作業後に docker logout しておくと安全です。Docker Desktopでは、OSの資格情報ストアが使われるのが一般的です。

手順2：イメージにタグを付ける

Docker Hubにプッシュするイメージの名前は 名前空間/リポジトリ名:タグ の形式でなければなりません。手元で myapp:1.0.0 という名前でビルドしたイメージは、そのままではプッシュ先が分かりません。docker tag で別名を付けます。

docker build -t myapp:1.0.0 .
docker tag myapp:1.0.0 your-docker-id/myapp:1.0.0
docker tag myapp:1.0.0 your-docker-id/myapp:latest

docker images your-docker-id/myapp

docker tag はコピーではなく同じイメージに名前を追加するだけなので、容量は増えません。最初からプッシュ先の名前でビルドする（docker build -t your-docker-id/myapp:1.0.0 .）こともできます。

タグはバージョンが分かる値にします。latest は「最後にこの名前でプッシュしたもの」を指す普通のタグにすぎず、自動で最新版を指す仕組みではありません。本番環境では 1.0.0 や Gitのコミットハッシュのような、後から中身が変わらないタグを指定して取得するほうが、いつ何がデプロイされたかを追えます。

手順3：docker pushで送る

docker push your-docker-id/myapp:1.0.0
docker push your-docker-id/myapp:latest

レイヤーごとに送信状況が表示され、最後に digest: sha256:... が出れば成功です。同じレイヤーが既にDocker Hubにあれば Layer already exists と表示されて送信が省略されるため、2回目以降は差分だけが送られます。

すべてのタグをまとめて送るには docker push --all-tags your-docker-id/myapp が使えます。

確認は、Docker Hubのリポジトリ画面でタグが表示されるかを見るほか、別のマシン（またはローカルのイメージを消した状態）で docker pull your-docker-id/myapp:1.0.0 して起動できるかで行います。

複数のCPUアーキテクチャ向けにプッシュする

Apple Silicon（arm64）のMacでビルドしたイメージを、一般的なamd64のサーバーで動かすと exec format error で起動しないことがあります。両方で動かしたい場合は、buildxでマルチプラットフォームのイメージを作り、そのままプッシュします。

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t your-docker-id/myapp:1.0.0 \
  --push .

docker buildx imagetools inspect your-docker-id/myapp:1.0.0

imagetools inspect で、1つのタグに複数のプラットフォームが含まれていることを確かめられます。環境によっては、マルチプラットフォームのビルドに専用のビルダー（docker buildx create --use）やエミュレーションの準備が必要です。

CIからプッシュする場合

GitHub ActionsなどのCIでは、トークンをCIのシークレット機能に登録し、標準入力で渡します。コマンドの引数にトークンを書くと、シェルの履歴やログに残るおそれがあるためです。

echo "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USERNAME" --password-stdin

CI用には個人のトークンとは別に、権限を絞ったトークンを用意しておくと、漏れたときの影響を小さくできます。組織で運用する場合は、組織用のアクセストークンなどの仕組みが用意されているかもDocker Hubのドキュメントで確認してください。

よくあるエラーと確認方法

denied: requested access to the resource is denied

最も多いエラーです。原因として多い順に確かめます。

1. イメージ名に名前空間が付いていない：docker push myapp:1.0.0 は、Docker Hubの公式イメージの場所（library/myapp）に送ろうとして拒否されます。docker images で your-docker-id/myapp という名前になっているかを見ます。
2. 名前空間の綴りが違う：Docker IDと1文字でも違えば、他人の名前空間への送信として拒否されます。Docker IDは小文字で指定します。
3. ログインしていない、または別のアカウントでログインしている：docker login をやり直します。複数のアカウントを使い分けている場合は特に注意します。
4. トークンに書き込み権限がない：読み取り専用で作ったトークンではプッシュできません。権限を含めたトークンを作り直します。
5. 組織のリポジトリで自分に書き込み権限がない：組織の管理者にチームの権限を確認してもらいます。

An image does not exist locally with the tag

指定した名前とタグのイメージが手元にありません。docker images で正確な名前とタグを確かめ、docker tag を付け直します。タグを省略すると latest を探すため、1.0.0 しか付けていないイメージは docker push your-docker-id/myapp では見つかりません。

途中で止まる・タイムアウトする

大きなレイヤーの送信中にネットワークが切れると失敗します。もう一度 docker push すれば、送信済みのレイヤーは省略されて続きから進みます。毎回止まるようなら、イメージ自体を小さくすること（マルチステージビルドや不要ファイルの除外）を検討します。

公開前に秘密情報が入っていないか点検する

公開リポジトリのイメージは誰でも取得でき、中のファイルや各レイヤーを調べられます。後から削除しても、その間に取得された分は取り戻せません。プッシュする前に次を確認します。

• .env、秘密鍵、wp-config.php の本番の認証情報などがイメージに入っていないか。.dockerignore で除外し、docker run --rm -it イメージ sh で中を見て確かめます。
• docker history --no-trunc イメージ で、ARG や ENV にトークンやパスワードを渡した跡が残っていないか。
• 既知の脆弱性を含むパッケージがないか。Docker Scoutや、Trivyなどのスキャナーで調べられます。検出できるのは既知のものだけなので、ベースイメージの定期的な更新と組み合わせます。

もし秘密情報を含むイメージをプッシュしてしまったら、イメージの削除より先に、その秘密情報（パスワードやAPIキー）を無効にして新しいものに切り替えてください。

まとめ

• 準備はDocker ID、リポジトリ（公開範囲を先に決める）、書き込み権限付きのアクセストークンです。
• docker login にはパスワードではなくトークンを使い、CIでは --password-stdin で渡します。
• イメージ名は 名前空間/リポジトリ名:タグ。docker tag で名前を付けてから docker push します。本番では中身が変わらないタグを使います。
• deniedエラーは、名前空間の付け忘れ・綴り違い・ログイン状態・トークンの権限の順に確かめます。
• 公開前に秘密情報と既知の脆弱性を点検し、漏れた場合は秘密情報の無効化を最優先にします。

• GitHub ActionsでDockerイメージをビルドする方法
• TrivyやSnykでDockerイメージの脆弱性をスキャンする方法