みなさま、こんにちは。クエルダ開発担当の渡部公也です。
以前から、WindowsとWSLを中心にしていた開発環境を、少しずつUbuntuへ移行したいと考えていました。
せっかくなので、これを機にクエルダではどのように開発を行っているのかを公開するため、テーマ毎にblogの連載を書いて行くことにいたしました。
クエルダも他社の例に漏れずAIを活用して開発を行っていますので、少しでも誰かのお役に立てればうれしいです。
さて、この連載では、クリーンなUbuntuに開発環境を構築していく過程を、ChatGPTとCodexを活用しながら記録していきます。
第1回は、実際にソフトウェアをインストールする前の段階として、Ubuntuへ移行する理由、構築する環境の目的、必要な資材の整理について紹介します。
これまでの開発環境
現在の主な開発環境は、Windows 11、WSL、Visual Studio Codeを組み合わせた構成です。
Windows上で日常業務を行いながら、Linux環境が必要な開発についてはWSLを利用しています。この構成は非常に便利で、WordPressプラグインやPHPシステムの開発でも大きな問題なく利用できています。
一方で、今後はWordPressやPHPだけでなく、次のような開発にも取り組みたいと考えています。
- AWSを利用したネットワークやサーバーの検証
- Dockerやコンテナを利用した開発
- Pythonを利用したAI・自動化ツールの開発
- ローカルLLMやAIエージェントの検証
- Linuxサーバー上で動作するWebシステムの開発
こうした将来の用途を考えると、Linuxを補助的に利用するだけでなく、Ubuntu自体を開発環境として使えるようにしておくことには大きな意味があります。
Ubuntuへ移行する目的
今回の目的は、現在のWindows環境をすぐに廃止することではありません。
WindowsとWSLの環境を維持しながら、Ubuntu側にも独立した開発環境を構築し、実際の業務で利用できる範囲を少しずつ広げていきます。
移行を段階的に行うことで、日常の開発業務を止めずに、新しい環境の操作方法や問題点を確認できます。
クリーンなUbuntuから始める
今回は、以前から利用している環境へ追加設定するのではなく、クリーンな状態のUbuntuから開発環境を構築します。
既存の設定や過去に導入したパッケージの影響を受けにくいため、何をインストールし、どの設定によって動作しているのかを把握しやすくなります。
また、構築手順を最初から記録しておけば、将来パソコンを入れ替える場合や、別のUbuntu環境を作成する場合にも再利用できます。
開発環境は、一度完成すれば終わりというものではありません。OSや各種ツールの更新、新しい開発方式への対応など、継続的な保守が必要です。
そのため今回は、単にソフトウェアをインストールするだけではなく、後から見直せる構成にすることも重視します。
ChatGPTとCodexの役割
この環境構築では、ChatGPTとCodexをそれぞれ異なる役割で利用します。
- ChatGPT
- 環境全体の構成検討、作業順序の整理、コマンドの意味や選択肢の説明、問題発生時の原因整理を担当します。
- Codex
- 実際のプロジェクト内でのコード確認、設定ファイルの編集、差分確認、テスト、Gitを利用した変更管理などを担当します。
- 人間
- 最終的な判断、OSへのログイン、管理者権限が必要な操作、認証情報の入力、ブラウザ上での確認などを担当します。
AIにすべてを任せるのではなく、相談、実行、確認の役割を分けることで、安全性と作業効率の両方を確保します。
最初に構築する環境の範囲
最初の段階では、現在の主業務であるWordPressおよびPHP開発をUbuntuで行えることを目標にします。
今後必要になる可能性があるツールをすべて一度に導入するのではなく、まずは基本的な開発に必要な構成へ限定します。
| 分類 | 資材 | 主な用途 |
|---|---|---|
| バージョン管理 | Git | ソースコードの変更履歴管理 |
| GitHub連携 | GitHub CLI | リポジトリ、Issue、Pull Requestなどの操作 |
| エディター | Visual Studio Code | ソースコードと設定ファイルの編集 |
| AI開発支援 | Codex CLIおよび関連機能 | コード調査、修正、テスト、差分確認 |
| Webサーバー | Apache | ローカルWebサイトの実行 |
| プログラミング言語 | PHP | WordPressおよびPHPシステムの実行 |
| 依存関係管理 | Composer | PHPライブラリや開発ツールの管理 |
| データベース | MariaDBまたはMySQL | WordPressのデータ保存 |
| WordPress操作 | WP-CLI | WordPressのインストールや管理操作 |
| フロントエンド開発 | Node.jsおよびnpm | JavaScript、CSS、ビルドツールの実行 |
Docker、Python、AWS CLI、ローカルLLMなどについては、基本環境が安定してから目的別に追加する予定です。
インストール前に確認すること
ソフトウェアのインストールを始める前に、Ubuntu側の状態と今後の運用方法を確認します。
-
OSが正常に起動すること
ローカルログイン、ネットワーク接続、日本語入力、画面表示など、基本操作に問題がないことを確認します。
-
システム更新を適用できること
Ubuntuのパッケージ情報を更新し、OSの更新処理が正常に完了する状態にします。
-
管理者権限を利用できること
パッケージのインストールや設定変更では管理者権限が必要になるため、sudoを利用できることを確認します。
-
開発データの保存場所を決めること
Gitリポジトリ、Web公開ディレクトリ、検証用サイト、バックアップなどの保存場所を事前に整理します。
-
既存環境から移行する情報を整理すること
Gitのユーザー設定、GitHub認証、Visual Studio Codeの設定、SSH鍵、FTP・SFTP接続情報など、移行が必要な情報を洗い出します。
-
秘密情報をソースコードと分離すること
APIキー、パスワード、OAuthクライアント情報などをGitリポジトリへ誤って保存しない運用をあらかじめ決めておきます。
既存環境をそのまま複製しない
WindowsやWSLで利用している設定を、そのままUbuntuへコピーすれば早く移行できるようにも見えます。
しかし、長期間利用してきた環境には、現在は使われていない設定や、導入理由が分からなくなったツールが含まれている可能性があります。
今回は既存環境を参考にしながらも、各ツールが現在も必要か、より適切な導入方法がないかを確認し、必要なものだけを追加します。
クリーンな環境を作ることは、これまでの開発環境を整理し直す機会でもあります。
作業記録を残す
環境構築中に実行したコマンドや変更した設定は、できる限り記録します。
特に、次の情報は後から確認できるようにします。
- インストールしたツールとバージョン
- インストール方法と選択理由
- 変更した設定ファイル
- 発生したエラーと解決方法
- 動作確認に使用したコマンド
- WindowsやWSLとの違い
正常に完了した手順だけでなく、うまくいかなかった方法も記録します。失敗の記録は、同じ問題を繰り返さないための重要な情報になります。
今回の到達点
今回は、Ubuntuへ移行する目的と方針を整理し、初期段階で必要になる開発資材を洗い出しました。
この時点では、Git、Visual Studio Code、PHP、Apacheなどのインストールはまだ行いません。
まずはUbuntu側の基本状態を確認し、どのような構成を目指すのかを明確にしたうえで、次の作業へ進みます。
次回の予定
次回は、Ubuntuの現在の状態を確認し、Git、GitHub CLI、Visual Studio Code、Codex、PHP、Composer、Apacheなど、基本的な開発資材の導入を開始します。
インストール方法を選ぶ際には、Ubuntuの標準パッケージ、Snap、公式リポジトリなどの違いも確認し、今後の更新や保守を考慮して判断します。