1. はじめに

1-1. 今回やってみたこと

今回、次のプロジェクトに向けて、少しブランクのあるJava / Spring Bootを基本的なところから復習することになりました。

せっかく復習するのであれば、実際に手を動かしながら簡単なアプリケーションを作ってみたい。さらに、ちょうど新しいPCを使い始めたタイミングでもあったため、「それなら開発環境の構築からやってみよう」と考えました。

そこでふと思ったのが、

「最近なら、AIエージェントに開発環境の構築もお願いできるのでは？」

ということでした。

Codexについては、リリースされたことや、コーディングだけでなくPC上でさまざまな作業ができることはなんとなく知っていました。
ただ、実際に自分のPCで本格的に使ったことはなく、「結局どこまでできるんだろう？」という興味がありました。

一方で、AIエージェントに自分のPC上でコマンドを実行したり、ファイルを操作したりしてもらうことには、少し不安もありました。

そこで今回は、普段使っているWindows環境とは分けるため、ちょうど入っていたVirtualBox上にUbuntuの仮想マシンを用意し、その中でCodex CLIを動かすことにしました。

最終的にはChatGPTにも相談しながら、

VirtualBox / Ubuntuの準備 → Codex CLIの導入 → Java / Maven / Spring Toolsの準備 → Spring Bootプロジェクトの作成 → Hello Worldの動作確認

までを行っています。

今回の記事では単なる環境構築手順ではなく、

「AIエージェント初心者のエンジニアが、安全性を考えながらCodex CLIを使ってみたら、実際にどこまでできたのか」

という体験を中心に紹介していきます。

1-2. こんな人に読んでほしい

この記事は、特に次のような方に読んでもらえたらと思っています。

Codex CLIに興味はあるが、まだ本格的に使ったことがない
AIエージェントが実際にどこまで作業できるのか知りたい
AIエージェントにPCを操作させることに少し不安がある
開発言語の学習・復習のために、さくっと開発環境を作りたい
これからプログラミングを学習したい

特に今回の取り組みは、「AIに全部やってもらいたい」というより、「AIを活用しながら自分でも理解して学習したい」という方には参考になる部分があるのではないかと思います。

1-3. やってみた感想を先に

実際に一通りやってみて最初に感じたのは、

「思っていたより、ずっと手軽だった」

ということでした。

以前、自分でJavaの開発環境を一から構築したときには、必要なツールを調べ、インストール方法を確認し、エラーが出れば原因を検索し……と、一つひとつ自分で進める必要がありました。

今回は、分からないことや進め方をChatGPTに相談し、実際の環境調査やコマンド実行、ファイル作成、動作確認などをCodexにお願いすることで、驚くほどスムーズに環境を作ることができました。

特に印象に残ったのは、

ChatGPTに相談して進め方を考え、Codexに実際の作業をしてもらい、最後は自分で確認・判断する

という役割分担です。

感覚としては、「ChatGPTという先生に相談しながら、Codexという優秀な作業者と一緒に作業を進めていく」ようなもので、個人的にはこの進め方自体もかなり楽しめました。

もちろん、AIに任せれば何も理解しなくてよいわけではありませんし、実際に使ってみて感じた注意点もありました。

そのあたりも含めて、今回どのような環境を用意し、どんなルールでCodexに作業してもらい、最終的にどこまで任せることができたのかを順番に振り返っていきます。

2. Codex / Codex CLIについて

2-1. Codex / Codex CLIとは？

まず、今回の主役であるCodexついて簡単に紹介します。

Codex CLIは、OpenAIが2025年4月に公開した、ターミナル上で動作するオープンソースのコーディングエージェントです。

その翌月の2025年5月には、OpenAIからクラウド上でタスクを実行できるCodexも発表されました。

現在のCodexはCLIだけでなく、IDE、Web、デスクトップアプリなどからも利用できるようになっています。

今回使用したCodex CLIをかなり簡単に表現すると、

ターミナルから指示を出すことで、AIが自分の開発環境を調査したり、ファイルを編集したり、コマンドを実行したりしてくれるツール

というイメージです。

例えば今回の取り組みでは、

現在のJava環境を調べる
必要な開発ツールを調査する
コマンドを実行する
Spring Bootプロジェクトを作成する
Javaのソースコードを書く
テストやビルドを実行する
Spring Bootを起動してHTTPレスポンスを確認する

といったところまでCodex CLIにお願いしました。

「AIにコードを書いてもらう」というよりも、開発環境の中で実際に作業してもらうという感覚に近かったです。

参考：

Introducing Codex（OpenAI）
OpenAI Codex CLI（GitHub）

2-2. ChatGPTとは何が違う？

私自身、今回Codex CLIを使い始める前に少し分かりにくかったのが、

「普段使っているChatGPTと、Codexはどう使い分ければいいのだろう？」

という点でした。

両者の機能を単純に線引きできるものではありませんが、今回の取り組みでは次のように使い分けました。

今回の作業	ChatGPT	Codex
作業の進め方を相談する	◎	○
Codexへの指示内容を考える	◎	×
Ubuntu内の環境を直接調査する	×	◎
コマンドを実行する	×	◎
ファイル・ソースコードを作成する	×	◎
テスト・ビルドを実行する	×	◎
実行結果を報告する	×	◎

※この表は一般的な機能比較ではなく、今回筆者がどのように使い分けたかを示したものです。

私の場合は、

ChatGPTには「どう進めるか」を相談し、Codexには「実際に作業してもらう」

という役割分担にしました。

例えばJavaを導入するときも、いきなりCodexへ「Javaをインストールして」とお願いしたわけではありません。

まずChatGPTと「どのように調査・導入していくか」を相談し、Codexには現在のUbuntu環境や導入候補を調査してもらいます。
その結果をもとに再びChatGPTと相談し、方針を決めてからCodexに実作業をお願いする、という流れです。

ChatGPTに相談 → Codexが調査 → 方針を判断 → Codexが作業・検証

この流れは、今回の環境構築を通して何度も利用しました。

2-3. Codexを使うにはいくらかかる？

今回、私はChatGPT PlusプランでCodexを利用しました。

2026年8月現在、CodexはFreeやGoを含むChatGPTの各プランから利用でき、利用上限はプランによって異なります。

Codexは登場後も利用条件や料金体系が変化しているため、本記事では具体的な利用上限や料金については詳しく触れません。

これから利用する場合は、最新の公式情報を確認することをおすすめします。

参考：

ChatGPTプランでCodexを使う（OpenAI Help Center）

少なくとも今回の私の場合は、普段利用していたChatGPT PlusからそのままCodex CLIを試すことができたため、思っていたよりも利用開始のハードルは低く感じました。

2-4. 他にはどんなAIエージェントがある？

もちろん、AIを利用して開発作業を支援してくれるツールはCodexだけではありません。

代表的なものには、Claude CodeやGitHub Copilotなどがあります。

今回は製品同士の比較が目的ではないため、詳しい説明は割愛します。

私の場合は、もともと普段からChatGPTを利用しており、

「ChatGPTに相談しながら、Codexを使って開発環境を作ってみたい」

という興味があったことからCodex CLIを選びました。

では、実際にCodex CLIを動かすとして、どこで動かすのか？

今回私は、いきなり普段使っているWindows上で動かすのではなく、VirtualBox + Ubuntuという仮想環境を用意することにしました。

次の章では、なぜこの構成にしたのかと、AIエージェントを使ううえで意識したことを紹介します。

3. なぜVirtualBox + Ubuntuにしたのか

3-1. AIエージェントにPCを操作してもらうことへの不安

Codex CLIを使ってみたいと思った一方で、最初に少し気になったのが、

「AIエージェントに、自分のPC上でコマンドを実行してもらって大丈夫なのだろうか？」

ということでした。

Codex CLIでは、コードを生成してもらうだけでなく、ファイルの読み書きやコマンドの実行など、実際の開発環境に対する操作をお願いできます。

しかし、私自身がCodex CLIを本格的に利用するのは今回が初めてです。

どのようなコマンドが実行されるのか、誤った指示を出したらどうなるのか、どの程度まで自動で作業が進むのかも、まだ十分に把握できていませんでした。

そこで、

「最初から普段使っているWindows上で自由に試すのではなく、影響範囲を分けた環境で試してみよう」

と考えました。

3-2. 「分ける」「戻せる」環境を作る

今回選んだ構成は、次のようなものです。

Windows（普段使っているPC）
  └─ VirtualBox
       └─ Ubuntu
            └─ Codex CLI

VirtualBox上にUbuntuの仮想マシンを用意し、Codex CLIには基本的にそのUbuntuの中で作業してもらいます。

こうすることで、普段使用しているWindows環境と、Codexに作業してもらう環境を分けました。

さらに、VirtualBoxには仮想マシンの状態を保存できるスナップショットがあります。

今回は環境構築の途中でスナップショットを作成し、

「何か問題が起きても、正常だった時点まで戻せる」

状態にしてから作業を進めました。

この「普段の環境と分ける」「問題があれば戻せる」という2点が、今回VirtualBoxを利用した大きな理由です。

「絶対に問題が起きない環境を作る」というより、初めて使うツールだからこそ、失敗しても試しやすい環境を作っておくという考え方でした。

3-3. AGENTS.mdで「どう作業してほしいか」を決める

仮想環境を用意したら、次に考えたのが、

「Codexに、どういうルールで作業してもらうか」

でした。

ここも自分一人で決めるのではなく、ChatGPTに今回の目的や環境を伝え、どのようなルールにするとよいか相談しました。

そして、相談した内容をもとにAGENTS.mdを用意しました。

AGENTS.mdは、Codexに作業するときの指示やルールを伝えるために利用できるファイルです。

今回作成したAGENTS.mdには、例えば次のようなルールを記載しました。

原則として/home/ubuntuを作業領域とする
ホストのWindows環境やVirtualBoxの設定は変更しない
依頼された作業に必要な範囲だけ変更する
大きな影響を与える可能性がある変更は、実行前に確認する
sudoは必要な場合に限って使用する
既存環境を壊す可能性がある場合は、独断で進めない

つまり、

「どういうルールで作業してほしいか」をChatGPTと一緒に考え、そのルールに従ってCodexに実際の作業をしてもらう

という形にしました。

AIエージェントにすべてを自由に任せるのではなく、先に人間側で作業の枠を決めておくイメージです。

3-4. Codexが何をしたのか、あとから確認できるようにする

もう一つ意識したのが、作業内容を記録することです。

今回は、

Codexに渡したプロンプト
Codexが実行したコマンド

をログとして残すことにしました。

保存先は次のように分けています。

/home/ubuntu/codex-logs/
├── prompts/
└── commands/

そして面白かったのが、ログを保存するためのディレクトリ作成や、ログの記録自体もCodexにお願いできたことです。

AIに作業してもらいつつ、

「何をお願いして、実際に何をしたのか」を後から振り返れる状態にする

というのが今回の狙いでした。

実際、このログは今回の記事を書く際にも非常に役立ちました。

「確かこんなことをしたはず」という記憶だけではなく、どんなプロンプトを渡し、どのようなコマンドが実行されたのかを後から確認できたためです。

3-5. いきなり作業させず、「まず調査だけ」をお願いする

実際にCodexを使うときにも、もう一つ意識したことがあります。

それが、

いきなり環境を変更させず、まず「調査だけ」をお願いする

ことです。

例えばJavaの環境を作るときも、最初から「Javaをインストールしてください」とお願いしたわけではありません。

まず現在のUbuntu環境やJava/JDKの導入状況、利用できる候補などをCodexに調査してもらいました。

その際には、

今回は調査・提案のみとし、インストール、パッケージ更新、設定変更は行わないこと。

というように、変更を行わないことも明示しました。

その後は、

Codexが調査
↓
調査結果を確認してChatGPTと相談
↓
筆者が方針を判断
↓
Codexに実際の作業を依頼

という流れで進めました。

この「まず調査だけ」という方法は、JavaだけでなくMavenやSpring Bootの準備でも利用しています。

個人的には、初めてAIエージェントに環境を操作してもらううえで、「いきなり任せる」のではなく、「まず見てもらう」という進め方は安心感がありました。

3-6. VirtualBox + Ubuntuが唯一の正解ではない

ここまでVirtualBox + Ubuntuを選んだ理由を紹介しましたが、もちろん、

AIエージェントを利用するなら、必ずVirtualBoxを使うべき

というわけではありません。

今回この構成にしたのは、

「AIエージェントを初めて本格的に触るので、普段使いのWindowsとは分けて、失敗しても戻しやすい環境で自由に試したい」

という私自身の目的があったからです。

今回、安全面や作業の進め方として意識したことをまとめると、次の5つになります。

意識したこと	今回の方法
分ける	VirtualBox + Ubuntu
戻せるようにする	VirtualBoxのスナップショット
ルールを決める	AGENTS.md
記録する	プロンプト・コマンドログ
いきなり変更しない	まず調査だけお願いする

この環境とルールを準備したうえで、いよいよCodex CLIを使った実際の環境構築へ進んでいきます。

4. Codexが作業できる環境を準備する

4-1. VirtualBox + Ubuntuを準備する

まずは、Codex CLIを動かすためのUbuntu環境を用意しました。

今回の構成は、前章で紹介した通り、

Windows
  └─ VirtualBox
       └─ Ubuntu
            └─ Codex CLI

です。

VirtualBoxのインストールやUbuntu仮想マシンの作成方法については、すでに多くの記事や公式ドキュメントがあるため、本記事では詳しい手順は割愛します。

私自身も、VirtualBoxやUbuntuの設定で分からないところは、その都度ChatGPTに画面や状況を見せながら相談して進めました。

設定項目の意味や、どの設定を選べばよいのか分からない場面でも確認しながら進められたため、仮想環境の構築自体は比較的スムーズに完了しました。

Ubuntuの準備ができたところでVirtualBoxのスナップショットも作成し、何か問題があった場合に戻せる状態にしてから次へ進みます。

4-2. Codex CLIを導入する

Ubuntuの準備ができたら、次はCodex CLIを導入します。

Codex CLIのインストールや認証についても、公式の手順を確認しながら進めました。

導入後、Ubuntuのターミナルから、

codex

を実行すると、Codex CLIを起動できます。

最初に起動したときは、

「本当にここから指示するだけで、Ubuntuの中を調べたり、コマンドを実行したりしてくれるのだろうか？」

という感覚でした。

普段ChatGPTへ質問するときと同じように自然言語で指示できますが、その先で実際にターミナルのコマンドやファイル操作まで行われるという点は、やはり新鮮でした。

なお、Codex CLIのインストール方法や認証方法は今後変更される可能性もあるため、本記事では詳しい手順は扱いません。

最新の導入方法については、公式ドキュメントを参照してください。

4-3. 最初は簡単な作業から試してみる

Codex CLIを起動できたからといって、すぐにJavaの開発環境を作り始めたわけではありません。

まずは、

「CodexがUbuntuの中で、実際にどのように作業するのかを見てみよう」

と考え、失敗しても影響の少ない簡単な操作から試しました。

例えば、

指定したディレクトリを作成する
簡単なファイルを作成する
Ubuntuの環境を確認する
実行した内容を報告してもらう

といった作業です。

実際に試してみると、

指示を出す
↓
Codexが必要な操作を考える
↓
コマンドを実行する
↓
結果を確認する
↓
実施内容を報告する

という一連の動きを確認できました。

この段階で、

「思っていたより普通に会話しながら作業をお願いできそう」

という感覚がつかめてきました。

4-4. 本格的な作業に入る前の準備

簡単な動作確認ができたところで、本格的な環境構築へ進む前に、前章で紹介したAGENTS.mdとログ保存の仕組みを用意しました。

AGENTS.mdでは、

作業する範囲
変更時のルール
sudoの扱い
作業前後の確認
ログの保存
作業完了時の報告

などについてルールを設定しています。

また、Codexへのプロンプトと実行したコマンドを後から確認できるよう、

/home/ubuntu/codex-logs/
├── prompts/
└── commands/

というログ保存先も準備しました。

4-5. これでCodexに作業してもらう準備が整った

ここまでで、

VirtualBox + Ubuntu
VirtualBoxのスナップショット
Codex CLI
AGENTS.md
プロンプトログ
コマンドログ

が揃いました。

今回用意した環境をまとめると、次のようになります。

Windows
  │
  └─ VirtualBox
       │
       └─ Ubuntu
            │
            ├─ Codex CLI
            │
            ├─ AGENTS.md
            │    └─ 作業範囲・安全性・ログなどのルール
            │
            ├─ codex-logs/
            │    ├─ prompts/
            │    └─ commands/
            │
            └─ Java / Spring Boot環境
                 ↑
                 ここからCodexと構築

これで、ようやく本題であるJava / Spring Bootの開発環境構築へ進む準備が整いました。

次の章では、実際にCodexへ環境を調査してもらいながら、

Java → Maven → Spring Tools → Spring Bootプロジェクト作成 → Hello World → HTTP 200確認

まで進めた流れを振り返ります。

5. CodexとJava / Spring Boot開発環境を作る

5-1. まずはCodexに現在の環境を調べてもらう

準備が整ったので、いよいよJava / Spring Bootの開発環境を作っていきます。

今回、最初からCodexに、

「JavaとSpring Bootの開発環境を全部作ってください」

とお願いしたわけではありません。

前章までで紹介した方針に沿って、基本的には次の流れで進めました。

① Codexに調査してもらう
↓
② 調査結果を確認し、ChatGPTと相談する
↓
③ 筆者が採用する方法を判断する
↓
④ Codexに実際の作業をお願いする
↓
⑤ Codexに結果を検証してもらう

最初のJava / JDK調査でも、Codexへの指示には、

今回は調査・提案のみとし、インストール、パッケージ更新、設定変更は行わないこと。

と明示しました。

まずCodexに現在の環境や導入候補を調べてもらい、その結果をChatGPTにも相談して、次に何をするかを自分で決める。

この方法をJavaだけでなく、MavenやSpring Tools、Spring Bootの準備でも繰り返しました。

AIエージェントに環境構築をお願いするといっても、最初から最後まで一度の指示で丸投げしたわけではないというのが、今回のポイントです。

5-2. Java / Mavenを準備する

調査結果を確認しながら、まずJavaの開発環境を準備しました。

Java / JDKについては候補を調査してもらったうえでOpenJDK 25を採用し、導入後にはCodexにjava、javac、JAVA_HOME、PATHなどを確認してもらいました。

ここで一つ、今回の役割分担が分かりやすく出た場面がありました。

OpenJDKの導入中、Codexがsudoを利用する操作を試みたところ、Ubuntu側で対話式の認証が必要になりました。

このときはCodexが無理に処理を進めるのではなく、

Codexがインストールを試行
↓
sudoの対話認証が必要になる
↓
筆者がUbuntu側で必要な操作を行う
↓
Codexが検証を再開

という流れで進みました。

CodexができるところはCodexに任せ、人間の操作や判断が必要になったら筆者に戻す

という今回の役割分担がよく表れた場面だったと思います。

続いてMavenも、候補や既存環境との互換性などをCodexに調査してもらってから導入しました。

印象的だったのは、インストール後に単に、

mvn --version

を確認して終わりではなかったことです。

Codexは動作確認用の一時的なMavenプロジェクトを作成し、実際にビルド・実行まで行って動作を確認しました。

さらに、確認が終わると自分で作成したテスト用プロジェクトを削除しています。

「インストールされている」だけでなく、「実際に使える」ことまで確認する。

このあたりから、環境構築をCodexにお願いする便利さをかなり感じ始めました。

5-3. Spring ToolsもCodexに準備してもらう

続いて、Java / Spring Bootの開発に使用するSpring Toolsを準備しました。

ここでも、

調査 → 方針を決める → 導入 → 検証

という流れは同じです。

事前調査では、現在のUbuntu環境やJava / Mavenとの組み合わせなどをCodexに確認してもらい、その結果をもとに導入方法を決めました。

この作業中には、Codexが利用しようとしたcurlがUbuntuに入っていないという場面もありました。

しかし、そこで新しくcurlをインストールするのではなく、

curlが利用できない
↓
Codexが既存環境を確認
↓
wgetが利用できることを確認
↓
wgetへ切り替えて作業を続行

という形で対応してくれました。

既存環境を不用意に変更せず、利用できる別の方法を探して作業を続けた点も印象的でした。

このエピソードについては、次の章でも「エラーが出た後の作業」という観点から改めて触れます。

これで、

Java + Maven + Spring Tools

という基本的な開発環境が揃いました。

5-4. Spring Bootプロジェクトをゼロから作ってもらう

ここからが、今回の取り組みで特にやってみたかった部分です。

環境を準備するだけでなく、

「CodexにSpring Bootプロジェクトそのものを作ってもらったら、どこまでやってくれるのか？」

を試してみます。

ここでも、まず現在の環境やSpring Bootの候補などをCodexに調査してもらい、その結果をChatGPTとも相談しました。

そして最終的にCodexへ、次の一連の作業をお願いしました。

Spring Bootプロジェクトを作成する
HelloControllerを作成する
GET /helloを用意する
Hello, Spring Boot!を返す
Mavenテストを実行する
Mavenビルドを実行する
Spring Bootを起動する
/helloへHTTPリクエストを送る
レスポンス本文を確認する
HTTPステータス200を確認する
確認後、Spring Bootを正常終了する

つまり、単に、

「Hello Worldを書いて」

ではなく、

「実際に起動して、HTTP 200が返ってくるところまで確認してください」

というところまでを作業条件にしました。

「どこまで確認できれば環境構築完了とするか」についてもChatGPTと相談し、それをCodexへの具体的な指示に落とし込んでいます。

5-5. 作成 → テスト → ビルド → 起動 → HTTP確認まで

指示を受けたCodexは、Spring Bootプロジェクトを用意し、HelloControllerを作成していきました。

その後、Mavenテストを実行します。

結果は、

Tests run: 1, Failures: 0, Errors: 0
BUILD SUCCESS

となり、テストに成功。

続けてビルドを行い、実行可能なJarの生成まで成功しました。

ここまででも十分便利なのですが、Codexの作業はまだ終わりません。

次に作成したSpring Bootアプリケーションを起動し、localhost:8080/helloへ実際にHTTPリクエストを送ります。

最終的な確認結果は、

Tomcat started on port 8080
Started HelloWorldApplication

HTTP/1.1 200

Hello, Spring Boot!

となりました。

さらに、確認後にはSpring Bootを正常終了し、

生成したJarが存在すること
必要なclassファイルが生成されていること
Javaプロセスが残っていないこと
一時ファイルが削除されていること

なども確認していました。

ここは今回、個人的にかなり驚いたところでした。

自分で環境構築していたときであれば、

プロジェクトを作る
↓
コードを書く
↓
テストする
↓
ビルドする
↓
起動する
↓
HTTPリクエストを送る
↓
レスポンスを確認する

と一つずつ進めていた作業です。

それを今回は、確認してほしい条件までプロンプトで伝えておけば、Codexが一連の作業として進めてくれました。

「AIがコードを書いてくれる」ということ自体は知っていましたが、作ったものを実際に起動し、HTTPレスポンスまで確認して、最後に後片付けまでしてくれるという体験は想像以上に便利でした。

5-6. 最後は自分でもSpring Toolsから確認する

Codexによる確認が終わった時点で、

「このSpring Bootプロジェクトは、少なくともコマンドライン上では正常に動作する」

ことが分かっています。

ここからは、私自身がSpring Toolsを操作して確認しました。

Codexが作成したSpring BootプロジェクトをSpring Toolsへインポートします。

HelloController.javaを開くと、Codexが作成した次のコードを確認できます。

@RestController
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello, Spring Boot!";
    }
}

先にCodexがテスト・ビルド・HTTPアクセスまで確認してくれていたため、この時点では、

「プロジェクト自体が動かないかもしれない」

という不安がほとんどありませんでした。

これは手作業で一から環境を作る場合と比べて、かなり安心感がありました。

最後にSpring ToolsからSpring Bootアプリケーションを起動し、ブラウザから、

http://localhost:8080/hello

へアクセスします。

画面には、

Hello, Spring Boot!

と表示されました。

これで、

Codexによる環境構築・プロジェクト作成・動作確認

に加えて、

筆者自身によるIDE・ブラウザからの最終確認

まで完了です。

5-7. 結局、誰が何をやった？

ここまでの作業を振り返ると、「AIに全部やってもらった」という表現は少し違います。

実際には、筆者・ChatGPT・Codexで自然に役割が分かれていました。

今回の役割分担を簡単にまとめると、次のようになります。

◎：主に担当　○：必要に応じて関与　×：基本的に担当しない

作業	筆者	ChatGPT	Codex
やりたいこと・目的を決める	◎	○	×
作業の進め方を考える	◎	◎	×
Codexへの指示を考える	◎	◎	×
現在の環境を調査する	×	×	◎
調査結果から採用する方法を決める	◎	◎	×
コマンド・ファイル操作を実行する	○	×	◎
テスト・ビルド・動作確認を行う	○	×	◎
エラー原因を調査・特定する	○	×	◎
エラーへの対応方法を検討する	○	◎	◎
対応を実施するか・見送るか判断する	◎	◎	×
エラーへの対応を実施する	○	×	◎
最終結果を確認する	◎	○	◎

特に便利だと感じたのは、「調査」と「実作業」と「検証」をCodexにかなり任せられたことです。

一方で、

何を作るのか
どの方法を採用するのか
Codexにどこまで許可するのか
問題が起きたとき、その対応を実施してよいのか

といった部分では、人間側の判断を残しています。

ChatGPTには、その判断をするための相談相手としてかなり助けてもらいました。

この役割分担が、今回の環境構築を想像以上にスムーズに進められた理由の一つだったと思います。

そして実際に使ってみると、環境構築そのもの以上に、

「エラーが出た後の作業がかなり楽になった」

ことも印象に残りました。

次の章では、こうした実際にCodex CLIを使ってみて感じたメリットと、反対に「人間側で理解・判断する必要がある」と感じた点についてまとめます。

6. 実際に使って感じたこと

6-1. 思っていたより、ずっと手軽だった

今回、Codex CLIを使ってJava / Spring Bootの開発環境を一通り構築してみて、最も強く感じたのは、

「思っていたより、ずっと手軽だった」

ということでした。

Codex CLIを使い始める前は、

AIエージェントを使うための設定自体が難しいのでは？
適切なプロンプトを書けないとうまく作業してくれないのでは？
結局、自分で細かくコマンドを指示する必要があるのでは？

というイメージも少し持っていました。

しかし実際には、Codexをどう使えばよいかという部分自体をChatGPTに相談できるため、想像していたほど難しく感じませんでした。

例えば、

「Javaの環境を作りたいけれど、いきなり変更させるのは少し不安」

とChatGPTに相談すれば、「では、まず現在の環境と導入候補だけを調査してもらおう」という進め方を一緒に考えられます。

さらに、その方針をCodexへどう伝えるかというプロンプトについてもChatGPTに相談できます。

そして実際の環境では、Codexが、

調査 → コマンド実行 → ファイル作成 → テスト → 動作確認

まで進めてくれます。

つまり、

「AIエージェントを使うために必要な知識も、AIに相談しながら補える」

というのが、実際に使ってみて感じた大きなポイントでした。

以前、自分でJavaの開発環境を構築したときには、必要なツールやインストール方法を調べ、エラーが出れば原因を検索し、一つひとつ自分で進めていました。

もちろん、こうした作業そのものが勉強になる面もあります。

一方、今回の目的は環境構築そのものではなく、Java / Spring Bootを使って実際にアプリケーションを作りながら復習することでもありました。

その意味では、環境構築にかかる手間を減らし、早い段階で本来やりたかった学習へ進めるのは大きなメリットだと感じました。

そして、もう一つ印象的だったのが作業の役割分担です。

今回の感覚をかなり簡単に表すと、

ChatGPTという先生に相談しながら、Codexという優秀な作業者と一緒に作業を進める

というものでした。

分からないことや進め方はChatGPTに相談する。

実際のUbuntu環境を調べたり、コマンドを実行したりする作業はCodexにお願いする。

そして、出てきた結果を見ながら、最終的にどうするかは自分で判断する。

このやり取り自体が新鮮で、個人的にはかなり楽しみながら環境構築を進めることができました。

6-2. 特に楽だったのは「エラーが出た後」

もう一つ強く感じたのが、

「エラーが出た後の作業がかなり楽になった」

ということです。

もちろん、Codexを使えばエラーが一切発生しなくなるわけではありません。

今回も、

必要なコマンドがインストールされていない
sudoによる認証が必要になる
ネットワークや実行環境の制限でコマンドが失敗する
権限制限によって取得できない情報がある

といった場面はいくつかありました。

ただ、以前自分で環境構築していたときとの大きな違いは、エラーが発生したところで自分の作業が止まりにくいことでした。

例えば、第5章で紹介したcurlが利用できなかった場面です。

curlが利用できない
        ↓
Codexが既存環境を確認
        ↓
wgetが利用できることを確認
        ↓
wgetへ切り替えて作業を続行

このときCodexは、

「curlがないなら、とりあえずインストールしよう」

と既存環境を変更するのではなく、すでに利用できるものを探して対応しました。

一方、OpenJDKの導入でsudoによる対話式認証が必要になったときには、

Codexがインストールを試行
        ↓
sudoの対話認証が必要
        ↓
筆者がUbuntu側で操作
        ↓
完了後、Codexが検証を再開

という流れになりました。

つまり、

自分で対応できるものは対応し、人間の操作や判断が必要ならそこで戻してくれる

という動きです。

振り返ってみると、

「エラーが起きなかった」というより、「エラー対応をしている感覚がかなり減った」

という表現が一番近いと思います。

エラーが発生しても、Codexがその出力を読み、原因を調べ、次の方法を検討してくれる。

必要になればChatGPTにも相談できる。

そのため、以前であれば検索エンジンを開いてエラーメッセージを調べていたような場面でも、作業を止めずに進めやすくなりました。

特に開発環境の構築では、「本当にやりたいことへ到達するまでのエラー対応」に時間を取られることもあるので、これはかなり大きな変化だと感じました。

6-3. とはいえ、人間が理解しなくてよいわけではない

ここまで便利だった点を中心に紹介してきましたが、

「それなら全部Codexに任せてしまえばいいのでは？」

というと、実際に使ってみた感覚としては、そうではありませんでした。

むしろCodexが多くの作業をしてくれるからこそ、人間側が何をしているのか把握することは大切だと感じました。

例えば、次のようなケースが考えられます。

意図しない変更が行われても気づけない

Codexに大きな権限を与え、実行内容も確認せずに作業を任せていた場合、必要のないパッケージの導入や、意図していない設定変更などが行われても、自分がその意味を理解していなければ気づけない可能性があります。

今回、

VirtualBox上に環境を分ける
スナップショットを作成する
AGENTS.mdで作業範囲を決める
まず「調査だけ」をお願いする
プロンプト・コマンドログを残す
重要な変更は自分でも確認する

といった工夫をしたのも、この点を意識したためです。

「動いたけれど、なぜ動くのか分からない」状態になる

今回のように学習目的で利用する場合には、こちらも注意したいところです。

例えば今回、CodexはHelloControllerを作成し、テスト・ビルド・起動・HTTP 200の確認まで実行してくれました。

非常に便利ですが、

「HTTP 200が返ってきたから成功！」

だけで終わってしまえば、

@RestControllerは何をしているのか
@GetMapping("/hello")は何を意味するのか
Mavenは何をしているのか
Spring Bootはどのように起動しているのか

といった部分を、自分では理解しないまま進むこともできます。

これでは、環境は完成しても「Java / Spring Bootを復習する」という本来の目的から外れてしまいます。

そのため今回は、Codexが作成したプロジェクトを最後にSpring Toolsへインポートし、ソースコードを自分でも確認し、ブラウザから実際にアクセスするところまで行いました。

今後も、

Codexが何を変更したのか確認し、分からない部分はChatGPTにも聞きながら、自分でも理解する

という使い方を意識したいと思います。

6-4. AIに任せることと、自分で学ぶことは両立できる

今回の取り組みを通して感じたのは、

AIに作業してもらうことと、自分が理解することは両立できる。

ということでした。

すべてを自分の手で入力することだけが学習ではありません。

一方で、AIが出した結果を何も確認せず受け入れるだけでも、十分な学習にはならないと思います。

調査や定型的な作業はAIに助けてもらい、その結果を確認しながら、本当に理解したいところへ自分の時間を使う。

今回のような学習目的の環境構築では、この使い方が自分にはかなり合っていると感じました。

次の章では、今回の取り組み全体を振り返りながら、Codex CLIを実際に使って分かったことをまとめます。

7. まとめ

今回は、

「AIエージェントに開発環境の構築をお願いしたら、実際にどこまでできるのか？」

という興味から、VirtualBox上にUbuntu環境を用意し、ChatGPTと相談しながらCodex CLIを使ってJava / Spring Bootの開発環境を構築してみました。

始める前は、AIエージェントにPCを操作してもらうことへの不安も少しありました。

そこで今回は、

VirtualBox + Ubuntuで普段の環境と分ける
スナップショットで戻せるようにする
AGENTS.mdで作業ルールを決める
プロンプト・コマンドログを残す
いきなり変更せず、まず調査してもらう

といった工夫をしながら進めました。

実際に使ってみると、Codexができることは想像していた以上に幅広いものでした。

単にコードを生成するだけでなく、

環境を調査する
↓
必要なコマンドを実行する
↓
開発ツールを準備する
↓
Spring Bootプロジェクトを作成する
↓
ソースコードを書く
↓
テスト・ビルドする
↓
アプリケーションを起動する
↓
HTTP 200とレスポンスまで確認する

というところまで、一連の作業としてお願いすることができました。

特に、作成したSpring Bootアプリケーションを実際に起動し、HTTP 200とHello, Spring Boot!のレスポンスまで確認してくれたことは、今回特に印象に残った部分です。

ChatGPT・Codex・筆者の三者で進める

今回の取り組み全体を振り返ってみると、私にとっては、

「ChatGPTという先生に相談しながら、Codexという優秀な作業者と一緒に開発環境を作っていく」

ような感覚でした。

役割を改めて整理すると、

💬 ChatGPT：先生・相談役
進め方を一緒に考えたり、Codexへの指示や問題への対応方法を相談したりする

🤖 Codex：作業者
実際の環境を調査し、コマンドを実行し、ファイルを作成し、結果まで検証する

👤 筆者：学習者・判断する人
何をしたいのかを決め、提案や実行結果を確認し、最終的な判断をする

最初は「Codexがどこまでできるのか試してみよう」という気持ちで始めましたが、実際に使ってみると、Codexだけに任せるというより、ChatGPT・Codex・自分で役割を分担する使い方が自分にはとても合っていました。

一方で、便利だからといって、すべてをAIに任せればよいわけではありません。

何を変更しようとしているのか、実行結果は妥当なのか、問題が起きたときにその対応を実施してよいのか。

そうした部分を理解し、最終的に判断する役割は人間側に残ります。

今回の取り組みを通して感じた、

AIに作業してもらうことと、自分が理解することは両立できる。

という点は、これからAIエージェントを使っていくうえでも大切にしたいと思っています。

環境構築や調査、定型的な作業をAIに助けてもらうことで、自分は「本当に学びたいこと」「考える必要があること」に、より多くの時間を使えるようになる。

AIエージェントは単に「自分の代わりにコードを書いてくれるもの」ではなく、自分の学習や開発を一緒に進めてくれる存在としても活用できそうだと、今回実際に使ってみて感じました。

ここまで読んでいただき、ありがとうございました。