Docker未経験から始めたCLI構築記録｜Codex-5.3と作るWordPress環境の全ログ

空のディレクトリから、いきなりCLIのcodexで環境構築を始めてみました。

ところで私は本来VM派でして笑 正直なところDocker を触ったことがありませんでした。

そんな人ですからGUIで構築する選択肢もありましたが、今回はあえてターミナルのみで進めることにしました。理由は単純です。AIと対話しながら、構造そのものを理解したかったからです。

本記事は、空ディレクトリからLAMP構成を立ち上げ、その後にWordPress へ移行し、orphanコンテナ問題を解消し、volumeの永続化を理解し、php.iniを変更して200MBアップロードを通すまでの実ログを基に構成しています。

さらに重要なのは、CLI上で動作したのが Codex-5.3 だったという点です。単にファイルを生成するだけではなく、エラーの診断、設定の分解、再現手順の提示まで一貫して支援する。その挙動を実体験として検証しました。

ただの成功談ではありません。

エラーに詰まり、用語に戸惑い、「これは何をしているのか」と分解し続けた過程そのものが主題です。AIに丸投げするのではなく、AIと協働しながら構造を理解していく。その過程で何が見えたのかを、順を追って整理していきます。

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

ドコモ home 5G「キャッシュバック15,000円」を進呈中！

Docker未経験の自分がいきなりCLIに突っ込んだ理由

いきなりCLIに突っ込むのは無謀です。

普通ならGUIやテンプレート環境から入るでしょう。しかし今回は、空のディレクトリに mkdir lamp だけを打ち込んだ状態から始めました。そこにDockerでLAMP環境を作る、と宣言する。いま振り返ると、かなり強引なスタートです。

なぜそんなことをしたのか。

理由はひとつです。ブラックボックスのまま使いたくなかったからです。CLIであれば、生成されるファイルも、実行されるコマンドも、出力されるログもすべて可視化されます。操作の履歴がそのまま教材になる。

なぜGUIではなくCodex-5.3 CLIだったのか

GUIの方が楽です。

ボタンを押せば進みますし、内部構造を意識せずに構築できます。しかし今回はそれを避けました。CLIであれば、何が生成され、何が実行され、どの設定が適用されたのかがすべてテキストで残る。

さらに、対話の履歴も残ります。

「これは何をしている？」
「そのコマンドの意味は？」

この分解ができることが重要でした。Codex-5.3は単にコードを出すだけではなく、構造を説明する。だからこそCLIを選びました。

楽さではなく、理解を優先した選択です。

「dockerでLAMP環境作りたい」から始まった

実際の始まりは、非常に雑でした。

「dockerでLAMP環境作りたいの　手伝ってくれる？」

それだけです。

すると docker-compose.yml と Dockerfile が生成されました。さらに index.php まで用意され、docker compose config による構文確認まで提示される。

ここで重要なのは生成速度ではありません。

生成物がYAMLとして可視化されていることです。

services、environment、volume。すべてが宣言として書かれている。だから追える。だから読める。

この時点で、「任せる」のではなく「一緒に設計している」感覚が生まれました。

LAMP構築ログから見るCodex-5.3の実力

ここからが実体験の核心です。

生成された構成を実行し、LAMP環境を立ち上げました。docker compose up -d –build を実行すると、レイヤー展開、拡張モジュールのインストール、コンテナ起動が順に表示されます。

ログがすべて可視化される。

これが大きい。

docker-composeとDockerfile自動生成

最初に生成されたのは、docker-compose.yml と Dockerfile でした。

services に web と db が定義され、web は php:8.2-apache、db は mysql:8.0。さらに db_data volume が宣言されている。

Dockerfileでは、FROM php:8.2-apache、docker-php-ext-install pdo pdo_mysql mysqli、a2enmod rewrite といった最低限の構成が追加されていました。

短い。

しかし意味は明確です。

WordPressを見据えた拡張有効化まで含まれている。この時点で、単なるサンプルではなく実用前提の設計になっていると理解しました。

PHP拡張有効化と接続確認までの流れ

起動直後に表示されたのは、PDO MySQL connection: OK、MySQLi connection: OK でした。

ここで終わらせてもよかった。しかし私は止まりました。

なぜ接続できたのか。

PDOとMySQLiはどこで有効化されたのか。Dockerfileでの docker-php-ext-install がその答えでした。

そしてもう一つ。

Composeが自動生成するネットワークです。services名が内部DNSとして使われる。つまり db という名前でMySQLへ接続できる。

構造がつながった瞬間でした。

WordPress構成への自然な切替

LAMPが動いた直後、私は言いました。

「ワードプレスを動かしたいんだよ」

構成は即座に書き換えられました。

webサービスは wordpress イメージへ変更され、environmentに接続情報が追加され、volumeも wp_data へ変更される。

しかしここで事件が起きます。

Bind for 0.0.0.0:8080 failed: port is already allocated

最初は意味がわかりませんでした。

そして私は聞きます。

「一回環境全部削除した方がいい？」

しかし原因は単純でした。旧LAMP構成のコンテナが8080ポートを掴んだまま残っていたのです。Composeは削除されていないサービスを自動では消しません。結果、orphan container が発生していました。

ここで理解しました。

ポートはコンテナのものではない。

ホストの共有資源です。

–remove-orphans の意味が、この瞬間に腹落ちしました。

エラー処理で見えたAIの診断能力

ここからが一番面白いところです。

構築そのものよりも、エラーに対する挙動のほうが記憶に残っています。なぜなら、そこに「診断能力」が見えたからです。

環境を切り替え、ポート衝突を解消し、ようやくWordPressが立ち上がった。そのあとも小さなエラーや違和感が続きました。permission、volumeの扱い、再作成時の挙動。

毎回私はこう聞いています。

これは何が起きている？

すると返ってくるのは、単なる対処コマンドではありませんでした。

原因の分解。
影響範囲の説明。
再発防止の提示。

つまり、修理ではなく診断です。

orphan container問題と8080ポート衝突

すでに触れた通り、8080ポートが掴まれたままになっていました。

ここで重要だったのは、なぜ掴まれているかの説明です。Composeは定義から消えたサービスを自動では削除しない。その結果、旧コンテナが孤立した状態で残る。

orphan container。

名前だけ聞くと抽象的ですが、実体は「定義外の残存コンテナ」です。

AIは単に docker compose down を提示するのではなく、「–remove-orphans を付ける理由」まで説明した。これが大きい。

対処ではなく構造理解。

この違いは大きいです。

volumeの削除と永続化の理解

次に混乱したのは、volumeの扱いでした。

コンテナを削除したらデータも消えるのか。

直感的には「消えそう」に感じます。しかし実際は違う。コンテナとvolumeは別物です。コンテナは書き換え層を持つ一時的存在ですが、volumeはホスト側に保持される永続領域です。

ここで腑に落ちたのは次の整理でした。

コンテナは使い捨て。
volumeは保存領域。

この分離が理解できると、再作成に対する恐怖が減ります。

再作成＝書き換え層消失の概念整理

さらに核心に近い質問を投げています。

再作成って、物理的に削除してimageから作り直すってことだよな？

かなり本質に近い問いです。

返ってきた説明はこうでした。

消えるのはコンテナの書き換え層。
消えないのはvolume。
imageはテンプレート。

この三層構造が整理された瞬間、Dockerの動きが立体化しました。

怖かったのは「何が消えるのかわからない」ことだった。

それが、層として説明される。

診断とは、現象を分解し、構造に還元すること。

ここで私は、単なる補助ツールではないと感じました。対話を通して概念が整理されていく。この体験が、今回の構築の中で最も印象に残っています。

php.ini変更と200MBアップロード設定

ここからは、実務的な話です。

WordPressが動いたあと、最初にやるのはSWELLテーマを入れるためにアップロード容量の拡張でした。初期状態ではアップロード上限が小さく、大きめのテーマやメディアを扱うには不足します。

200MBに上げたい。

単純な要求です。しかしここでも、構造を理解しながら進めることになります。

コンテナ内編集とホストマウントの違い

最初に浮かんだのは、コンテナの中で直接編集すればいいのでは、という発想でした。

しかしそれは一時的な変更です。

コンテナは再作成されると書き換え層が消えます。つまり、コンテナ内で直接 php.ini を編集しても、再作成すれば元に戻る可能性がある。

ここで重要になるのが「マウント」という概念です。

ホスト側に custom.ini を置き、それをコンテナへマウントする。すると設定はホスト側に存在し続ける。コンテナを再作成しても消えない。

一時変更か、永続変更か。

この違いを理解できたのは大きかった。

設定反映と値確認の手順

custom.ini に以下を記述しました。

upload_max_filesize = 200M
post_max_size = 200M
memory_limit = 256M

そして compose を再起動します。

ここで終わらせない。

本当に反映されたかを確認する必要があります。

php -i で値を確認する。あるいは WordPress のシステム情報画面を見る。設定が200MBになっていることを確認する。

設定 → 再起動 → 確認。

この流れが自然に提示されることが重要でした。

なんとなく変更するのではなく、検証まで含める。

php.iniの変更は小さな作業です。しかしここでも、コンテナとホストの関係、再作成時の挙動、マウントの意味が整理されました。

環境構築は単なる手順ではない。

構造理解の積み重ねでした。

今回の体験が示すAI協働時代の学習速度

ここまで来て、ようやく本題に触れられます。

今回の体験は「Dockerが動いた」という話ではありません。AIと対話しながら環境を構築したとき、学習速度がどう変わるのか。その検証です。

正直に言えば、最初は不安でした。

本当に理解できるのか。
丸投げにならないか。

しかし実際に起きたことは逆でした。

理解しながら進められる。

対話ログそのものが学習教材になる

CLIで進めた最大の利点は、ログがすべて残ることでした。

生成されたYAML。
実行したコマンド。
出力されたエラー。
そして、それに対する説明。

すべてが時系列で保存されています。

これが強い。

後から読み返せば、どこで何を理解したのかが追える。単なる結果ではなく、思考の流れまで含めて再現できる。

対話そのものが教材になる。

これは従来の検索型学習とは明らかに違います。

「理解しながら構築できる」体験価値

通常の環境構築は、手順をなぞる作業になりがちです。

コマンドをコピーし、実行し、動けば終わり。

しかし今回は違いました。

エラーが出るたびに止まり、「なぜ？」を挟む。その問いに対して、構造として説明が返る。現象が概念に変換される。

理解がその場で進む。

作業と学習が分離しない。

この体験は大きい。

環境構築が“作業”から“理解プロセス”へ変わった瞬間でした。

Codex-5.3は実務エンジニアレベルか

率直に言います。

少なくとも「初期診断」「構成提案」「原因分解」のレベルでは、実務補助として十分に機能します。

もちろん最終判断は人間が行う必要があります。しかし、ログの分解力と説明の一貫性は高い。

重要なのはここです。

答えを出すことよりも、理由を説明できること。

今回の構築で印象に残ったのは、常に「なぜそうなるか」が言語化されたことでした。だからこそ、ブラックボックスにはならなかった。

AIが作業を奪うのではない。

理解を加速させる。

それが今回の実感です。

まとめ：Docker構築体験は時代の変化ログである

今回の構築は、単なる環境セットアップではありませんでした。

空のディレクトリから始まり、LAMP構成を立ち上げ、WordPressへ切り替え、ポート衝突を解消し、volumeの概念を理解し、php.iniをマウントで制御する。

ひとつずつ整理すれば、特別なことはしていません。

しかし進み方が違いました。

検索して断片的に調べるのではなく、対話しながら構造を分解していく。エラーが出れば止まり、なぜを挟む。概念が曖昧なら言語化させる。

その結果、作業と理解が同時に進みました。

これは学習体験として大きい。

Docker未経験でも、構造を理解しながら構築できる。AIに丸投げするのではなく、AIを思考補助として使う。そのスタイルが成立することを、今回のログは示しています。

重要なのはツールの優劣ではありません。

理解可能な状態で進められるかどうかです。

CLIでの対話は、ブラックボックスを減らす。ログが残る。検証が挟まる。だから再現できる。

環境構築は一度きりの作業ではない。

記録された学習ログです。

そして今回の体験は、そのログ自体が「時代の変化」を物語っていました。

AIが作業を奪う時代ではない。

AIと構造を分解しながら進む時代です。素晴らしい！

よくある質問