環境構築にAIなんか使うな

Last updated at 2026-09-05Posted at 2026-09-05

公式ドキュメントを読み違えてAIに泣きついたらDocker環境構築に30倍時間がかかった話

仕事で環境構築のタスクをもらいました。

ただし、最初に1つ重要な条件がありました。

「Docker Desktopは入れないでください」

そこでDocker公式ドキュメントを見に行ったところ、こんなことが書いてありました。

Docker Desktop WSL 2 を有効にする
Windows 版 Docker Desktop をインストールしてください。
（以下略）

……Docker Desktop入れちゃダメなんですけど。

ここで本来やるべきだったことは単純です。

「Docker Desktopのドキュメントではなく、Docker EngineをUbuntuへインストールする公式ドキュメントを読む」

しかし、Dockerをちゃんと触るのもほぼ初めてだった私は、ここでAIに泣きつきました。

結果、公式ドキュメントをちゃんと読んでコピペすれば終わる作業に、体感30倍くらいの時間を溶かしました。

今回はそんなカスの話です。

そもそもDocker DesktopとDocker Engineは別物

最初にここを理解していませんでした。

Windows + WSL2でDockerを使う方法として、大きく分けると次の2パターンがあります。

Windows側にDocker Desktopを入れ、WSL Integrationを利用する
WSL上のUbuntuにDocker Engineを直接インストールする

普段個人開発でDockerを使うならDocker Desktopはかなり便利です。

しかし今回は、

Docker Desktop禁止

という条件があります。

つまり必要なのは2番目です。

WSL2上のUbuntuを普通のLinux環境として扱い、その中にDocker Engineをインストールします。

私はDocker Desktopについて説明しているページを見ながら、

「Docker Desktopなしでこれをやるにはどうすればいいんだ……？」

となっていました。

そもそも読んでいるドキュメントが違います。

最初の罠：`sudo snap install docker`

まずWSLのUbuntuで、

docker -v

を実行しました。

当然Dockerは入っていないので、Ubuntu側からインストール候補が表示されます。

その中にあったのが、

sudo snap install docker

です。

「お、これ実行すればいいんだな」

と思って実行しました。

これが最初の罠でした。

Snap版Dockerでハマる

Snap版Dockerそのものが常にダメという話ではありません。

ただ、今回の

WSL2
VS Code
Dev Containers
Docker Desktopなし

という構成では、余計な差分を増やす原因になりました。

VS CodeのDev Containersでエラーが発生し、Docker周辺の挙動を調べる必要が出てきました。

そして、

docker ps

すら期待通り動かない。

Dockerの勉強をしに来たはずなのに、

「俺は今Dockerを勉強しているのか、Snapをデバッグしているのか？」

という状態になりました。

Docker公式もUbuntu向けDocker Engineのインストール手順では、競合する可能性があるパッケージを削除してから公式aptリポジトリを利用する方法を案内しています。

というわけで、いったん余計なものを消して公式手順に戻ることにしました。

一生curlで止まるAI

Docker Desktopを使わず、Docker公式のaptリポジトリからDocker Engineをインストールする場合、Docker公式リポジトリをaptから安全に利用するための公開鍵を登録します。

公式ドキュメントでは、現在このようなコマンドが案内されています。

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

ところが、AIとのやり取りの中でこんなコマンドが出てきました。

sudo curl -fsSL https://docker.com \
  -o /etc/apt/keyrings/docker.asc

当時の私はGPG鍵周りをよく理解していなかったので、

「originに公開鍵が入っているのかな？」

くらいに考えていました。

もちろん違います。

https://docker.com はDockerのWebサイトです。

公開鍵として取得したいデータは、

https://download.docker.com/linux/ubuntu/gpg

にあります。

さらに私は、

-o /etc/apt/keyrings/docker.asc

の意味も勘違いしていました。

curl の -o は、

「公開鍵を取得するオプション」ではありません。

単に、

「取得したレスポンスを指定したファイル名で保存する」

というオプションです。

つまり、

curl URL -o FILE

は大雑把に言えば、

URLからデータを取得
↓
FILEに保存

しているだけです。

公開鍵なのはURLの先にあるデータであって、-o が何かを公開鍵に変換しているわけではありません。

今見ると当たり前なのですが、GPGもaptリポジトリもよく分かっていない状態だと、この1行の中で何が起きているのかすら分かりませんでした。

結局、公式ドキュメント通りにやればよかった

最終的にやったことは、Docker公式のUbuntu向けDocker Engineインストール手順です。

まず競合する可能性があるパッケージを削除します。

sudo apt remove $(dpkg --get-selections \
  docker.io docker-compose docker-compose-v2 docker-doc \
  docker-buildx podman-docker containerd runc | cut -f1)

続いて、Docker公式リポジトリを利用する準備をします。

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

そしてaptにDocker公式リポジトリを追加します。

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update

最後にDocker Engine関連パッケージをインストールします。

sudo apt install docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

以上。

散々AIと格闘したあとに見ると、

「最初からこれ読めば終わってたじゃん」

となりました。

公式ドキュメント：

そもそもGPG鍵って何をしているの？

今回一番分からなかったのがここでした。

雑に言えば、aptはDocker公式リポジトリからパッケージを取得するとき、

「このパッケージ情報、本当にDocker側が署名したものなの？」

を検証する必要があります。

そこで利用されるのが公開鍵です。

今回の、

/etc/apt/keyrings/docker.asc

がそのために利用されます。

そして、

Signed-By: /etc/apt/keyrings/docker.asc

によって、

「このリポジトリの署名検証にはこの鍵を使ってください」

とapt側に指定しています。

つまり、

Docker公式の公開鍵を取得
        ↓
/etc/apt/keyrings/docker.asc に保存
        ↓
Docker公式aptリポジトリを登録
        ↓
Signed-Byで利用する鍵を指定
        ↓
aptがリポジトリの署名を検証

という流れです。

ここまで理解していれば、

curl https://docker.com -o /etc/apt/keyrings/docker.asc

を見た瞬間に、

「いや、それDockerのWebページ保存してるだけでは？」

と気付けます。

コマンドを理解せずコピペしていると、AIが間違えたときに自分で止められません。

AIが便利だからこそ「コマンドの意味」を知らないと危険

今回の失敗で一番感じたのは、

AIが使えないというより、自分にAIの回答を検証する知識がない分野ほど事故りやすい

ということです。

Dockerについて十分な知識がある人なら、

sudo curl -fsSL https://docker.com \
  -o /etc/apt/keyrings/docker.asc

なんて出された時点で違和感を持てます。

しかし、

GPG鍵とは何か分からない
aptリポジトリとは何か分からない
curl -o の意味も曖昧
Docker DesktopとDocker Engineの違いも曖昧
WSL2上でDockerがどう動くのかも曖昧

という状態だと、AIが出したコマンドが正しいのか判断できません。

そしてエラーが発生すると、そのエラーをAIに貼ります。

AIが次のコマンドを出します。

実行します。

別のエラーが出ます。

また貼ります。

こうして、

エラー → AI → コマンド → エラー → AI → コマンド

という無限ループが完成します。

「環境構築」は特にAIの回答を鵜呑みにしづらい

環境構築はAIと相性が悪くなりやすい分野だと思いました。

理由は、環境依存の条件が多すぎるからです。

例えば今回だけでも、

Windowsのバージョン
WSLのバージョン
WSL1 / WSL2
Ubuntuのバージョン
Docker Desktopを使うか
Docker Engineを直接入れるか
Dockerをaptで入れたか
Snapで入れたか
systemdが有効か
VS Code Dev Containersを使うか
既存のcontainerdやruncが存在するか

などの条件があります。

AIは、こちらが伝えていない環境情報まで自動的に把握してくれるわけではありません。

条件が1つ抜けただけでも、一般論としては正しいが自分の環境では間違っているコマンドが返ってくる可能性があります。

なのでタイトルのように「AIは嘘しか言わない」は言い過ぎですが、

環境構築でAIを一次情報として扱うのは危険

というのが今回の結論です。

じゃあAIをどう使えばよかったのか

今回なら、最初にDocker公式ドキュメントを一次情報として固定して、

「この公式手順の各コマンドが何をしているのか説明して」

とAIに聞くべきでした。

例えば、

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
  -o /etc/apt/keyrings/docker.asc

を貼って、

sudo はなぜ必要？
curl は何をしている？
-f -s -S -L はそれぞれ何？
-o は何？
なぜ /etc/apt/keyrings/ に保存する？
docker.asc の中身は何？
この鍵は後でどこから参照される？

と聞けばよかったわけです。

AIに「正しいコマンドを生成させる」のではなく、

公式ドキュメントにある正しいコマンドをAIに解説させる。

この使い方なら、かなり有用です。

さらにAIが変な説明をしても、少なくとも実際に実行するコマンド自体は公式ドキュメントから取っているので、事故る可能性を減らせます。

今回学んだこと

今回の環境構築で得た教訓はこのあたりです。

まず自分が何をインストールしようとしているのか確認する
- Docker DesktopなのかDocker Engineなのかで、読むドキュメントから違う。
環境構築では公式ドキュメントを一次情報にする
- 特にリポジトリ追加、GPG鍵、権限、パッケージ管理周辺はコピペ元を確認する。
OSが提案してきたインストール方法を即実行しない
- apt、snap、公式リポジトリなど、同じソフトでも導入経路が複数ある。
AIにコマンドを作らせるより、公式コマンドを説明させる
- 「これどういう意味？」という使い方はかなり強い。
知らないコマンドをsudoで実行する前に意味を確認する
- 特にcurl | sh系、パッケージ削除、リポジトリ変更、権限変更は要注意。
エラーが出たら闇雲に次のコマンドを実行しない
- 「何を期待して」「実際には何が起きて」「どこで失敗したのか」を確認する。

おわり

Dockerを勉強するつもりで始めた環境構築でしたが、結果的にはDockerそのものより、

WSL2
apt
Snap
GPG
Linuxのパッケージ管理
リポジトリ
公開鍵
curl

あたりの勉強になりました。

そして何より、

公式ドキュメントをちゃんと読むのが一番速いことがある

という、あまりにも当たり前なことを学びました。

AIは分からないことを噛み砕いてもらうには非常に便利です。

ただし、自分が全く知らない分野でAIに環境構築を丸投げすると、間違ったコマンドを間違っていると判断できません。

なので今後は、

公式ドキュメント → 分からない部分をAIに聞く → 公式ドキュメントと照合 → 実行

くらいの順番で使っていこうと思います。

公式ドキュメントを読み違えた結果、公式ドキュメントを読むことの重要性を学ぶ。

非常に効率の悪いDocker入門でした。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up