【第2回】基本ツールを導入してLAMP環境の土台を作る

最初にUbuntuの状態を確認する

開発ツールのインストールを始める前に、現在のUbuntuがどのような状態なのかを確認しました。

今回利用するOSはUbuntu 26.04 LTSです。インストール直後に近いクリーンな状態で、Web開発に必要なソフトウェアはほとんど導入されていません。

まずは、今後利用する予定のコマンドがすでに存在しているかをまとめて確認しました。

git --version
gh --version
code --version
codex --version
php --version
composer --version
apache2 -v

確認した時点では、Git、GitHub CLI、Visual Studio Code、Codex CLI、PHP、Composer、Apacheのいずれも利用できない状態でした。

コマンドが見つからない場合、Ubuntuはインストール候補を表示してくれることがあります。しかし、表示された候補をそのまま選ぶのではなく、どの提供元から導入するのが適切かを確認してから進めました。

ChatGPTと一つずつ確認しながら進める

今回の環境構築では、複数のソフトウェアをまとめてインストールするのではなく、一つの作業を実行するたびに結果を確認する方法を採用しました。

1. ChatGPTが確認コマンドを提示する

   実行する場所、必要な権限、コマンドの目的、影響範囲を確認します。

2. 人間がUbuntuでコマンドを実行する

   管理者権限や認証が必要な操作は、内容を確認したうえで実行します。

3. 実行結果をChatGPTへ共有する

   表示されたバージョン、エラー、警告、サービスの状態などを確認してもらいます。

4. 問題がなければ次へ進む

   想定と異なる結果が出た場合は、その原因を整理してから次の作業を決めます。

少し時間はかかりますが、この方法であれば、どの操作によって環境が変化したのかを把握しやすくなります。

複数の問題が同時に発生することも避けられるため、Linuxに慣れていない段階では特に有効だと感じました。

システムを最新の状態にする

最初に、Ubuntuが管理しているパッケージ情報を更新しました。

sudo apt update

apt updateは、インストール済みソフトウェアそのものを更新するコマンドではありません。Ubuntuが参照しているリポジトリから、利用可能なパッケージの最新情報を取得します。

続いて、更新可能なパッケージを確認し、必要なシステム更新を適用しました。

クリーンインストール直後であっても、Ubuntuのインストールメディアが作成された後に公開された更新が存在する可能性があります。

古いパッケージが残った状態で開発ツールを追加すると、依存関係やバージョンの問題が発生することがあるため、最初にOS側を整えておくことが重要です。

開発データを保存する場所を決める

このUbuntuには、OSが入っているディスクとは別に、大容量のデータ保存用ディスクも接続されています。

当初は、容量の大きい別ディスクへ開発環境全体を置くことも検討しました。

しかし、確認したところ、このディスクはWindowsとのデータ共有に向いたファイルシステムでフォーマットされていました。

WordPressやGitの開発環境では、Linuxのファイル権限、所有者、シンボリックリンクなどが利用されます。これらを安定して扱うには、Linux向けのファイルシステムを利用する方が適しています。

そのため、ソースコードやWebサーバーのファイルはUbuntuのシステムディスク側へ置き、大容量ディスクは必要に応じてバックアップや共有データの保存に利用する方針としました。

空き容量だけで保存場所を決めるのではなく、ファイルシステムの特性も確認する必要があることが分かりました。

GitとGitHub CLIを導入する

最初に導入した開発ツールはGitです。

Gitは、ソースコードの変更履歴を記録するためのバージョン管理システムです。WordPressプラグインやテーマの開発でも、変更前の状態へ戻したり、複数の修正内容を比較したりするために欠かせません。

導入後に、次のコマンドで正常に利用できることを確認しました。

git --version

今回導入されたGitのバージョンは2.53.0でした。

続いて、GitHubをコマンドラインから操作するためのGitHub CLIも導入しました。

GitHub CLIを利用すると、ブラウザを開かなくても、リポジトリの確認、認証、IssueやPull Requestの操作などを行えます。

gh --version
gh auth status

GitHubの認証では、パスワードを設定ファイルへ直接保存するのではなく、GitHubが提供する認証手順を利用します。

導入後は、Gitのコマンドが実行できることだけでなく、GitHubアカウントへ正しく接続できていることも確認しました。

Visual Studio Codeを導入する

ソースコードを編集するエディターには、これまでWindowsとWSLでも利用してきたVisual Studio Codeを採用しました。

Ubuntuには複数の方法でVisual Studio Codeを導入できますが、今後の更新や拡張機能との互換性を考慮し、継続して更新を受け取れる方法を選択しました。

導入後は、アプリケーション一覧から起動できることと、ターミナルから次のコマンドを実行できることを確認しました。

code --version

今回導入されたVisual Studio Codeのバージョンは1.129.0でした。

ターミナルからcodeコマンドを利用できると、現在のディレクトリをVisual Studio Codeで開くことができます。

code .

WindowsとWSLで利用していた設定については、すべてをそのまま複製するのではなく、Ubuntuでも必要なものを確認しながら移行する方針としました。

以前の環境で使っていた拡張機能や設定の中には、WindowsやWSLでのみ必要なものもあるためです。

Codexを利用できるようにする

Visual Studio Codeの導入後、AIによる開発支援を行うためにCodexの環境を整えました。

今回は、Visual Studio Code上で利用するCodex拡張機能と、ターミナルから利用するCodex CLIの両方を導入しています。

Codex拡張機能

Visual Studio Code上で、開いているプロジェクトやファイルを確認しながらCodexへ作業を依頼するために利用します。

Codex CLI

ターミナル上でプロジェクトを調査し、ファイルの変更、差分確認、テストなどを行うために利用します。

導入後は、Visual Studio Code上にCodexの画面が表示されることと、ターミナルから次のコマンドを実行できることを確認しました。

codex --version

確認時点のCodex CLIは0.144.4、Visual Studio CodeのCodex拡張機能はopenai.chatgpt@26.707.71524でした。

Codexが利用できるようになっても、環境構築に関するすべての操作を自動で任せるわけではありません。

管理者権限を伴う操作や、OS全体へ影響する変更は、人間が内容を確認して実行します。Codexには、主にプロジェクト内の調査、コード変更、差分確認、テストなどを担当してもらいます。

PHPと必要な拡張機能を導入する

WordPressを動作させるためにはPHPが必要です。

PHP本体だけでなく、WordPressや一般的なWebシステムで利用される拡張機能もあわせて導入しました。

• データベースへ接続するための機能
• 文字コードを扱うための機能
• XMLを扱うための機能
• 画像を処理するための機能
• ZIPファイルを扱うための機能
• 外部のWebサービスと通信するための機能

導入後は、PHPのバージョン、実行ファイルの場所、有効になっている拡張機能を確認しました。

php --version
command -v php
php -m

今回導入されたPHPは8.5.4で、実行ファイルは/usr/bin/phpに配置されていました。

curl、gd、intl、mbstring、mysqli、pdo_mysql、xml、zipなど、予定していた拡張機能も有効になっていることを確認しました。

PHPのバージョンだけを確認するのではなく、必要な拡張機能が読み込まれていることまで確認するのが重要です。

Composerを導入する

PHPの導入後、PHP用の依存関係管理ツールであるComposerを追加しました。

Composerは、PHPライブラリ、コード品質検査ツール、テストツールなどをプロジェクト単位で管理するために利用します。

WordPress本体を動かすために必須というわけではありませんが、WordPressプラグインやPHPシステムを継続して開発するためには重要なツールです。

今回はUbuntuのパッケージ管理を利用して導入し、次のコマンドで確認しました。

composer --version
command -v composer

導入されたComposerは2.9.5で、実行ファイルは/usr/bin/composerに配置されていました。

ComposerがPHP 8.5.4を利用して正常に起動することも確認しました。

ApacheとPHP-FPMを導入する

続いて、WebサーバーとしてApacheを導入しました。

Apacheは、ブラウザからWordPressやPHPシステムへアクセスできるようにするためのソフトウェアです。

PHPの実行には、ApacheへPHPを直接組み込む方法ではなく、PHP-FPMと連携する構成を採用しました。

Apache

ブラウザからのアクセスを受け付け、HTML、画像、CSS、JavaScriptなどを返します。

PHP-FPM

Apacheから渡されたPHPファイルを実行し、処理結果を返します。

役割を分けることで、WebサーバーとPHPの設定を整理しやすくなり、将来PHPのバージョンを切り替える場合にも対応しやすくなります。

導入後は、Apacheのバージョンとサービスの状態を確認しました。

apache2 -v
systemctl status apache2
systemctl status php8.5-fpm

今回導入されたApacheは2.4.66です。

ApacheとPHP 8.5のPHP-FPMが起動し、OS上で正常にサービスとして動作していることを確認しました。

この段階では、まだWordPress専用のURLやデータベースは設定していません。まずはWebサーバーとPHPを組み合わせて利用できる土台を整えることを優先しました。

導入後の構成を確認する

今回の作業で導入し、動作を確認した主な資材は次のとおりです。

ソフトウェアをインストールしただけでは、開発環境が完成したとはいえません。

それぞれのコマンドが実行できること、必要なサービスが起動していること、予定した拡張機能が有効になっていることまで確認して、初めて次の段階へ進めます。

今回の到達点

今回は、クリーンなUbuntuの状態を確認し、開発に必要な基本ツールを導入しました。

GitとGitHub CLIによるバージョン管理、Visual Studio CodeとCodexによる開発支援、PHPとComposerによるPHP開発、ApacheとPHP-FPMによるWeb実行環境の土台が整いました。

まだデータベースやWordPressは含まれていませんが、ここまでで一般的なPHPファイルを作成し、Apacheを通してブラウザから実行するための基本構成が用意できました。

また、ChatGPTへ実行結果を共有しながら一つずつ進めることで、環境の状態を確認しながら安全に構築できることも分かりました。