☕

VS Code の Java プロジェクトを Gemini CLI に対応させよう

2025/09/13に公開

 はじめにこの記事は「VS Code と Docker で始める！シンプルな Java 開発入門」の続きです。前回用意したプロジェクトを Gemini CLI に対応させる手順を説明します。
Gemini CLI を開発コンテナ内で実行する方法は、入門者にとってはハードルが高いため、この記事では扱いません。これは、AI ツールの安定稼働には、時として高いハードウェア性能が要求され、環境構築の難易度が上がる可能性があるからです。
!Gemini CLI を開発コンテナ内で実行する方法については、次の記事で説明しています。よろしかったら、ご覧ください。
代わりに、この記事ではローカルマシンに直接 JDK をインストールした環境で Gemini CLI を使い、動作確認を行いました。生成 AI を活用した開発は、今後の主流になるでしょう。この記事を通して、その開発スタイルの一端を感じていただければ幸いです。
!2025-09-21 タイトルをより適したものへ変更しました。

 サンプルコードGitHub にサンプルコードを用意したので、先に紹介しておきます。
前回のものも含めて、各ステップごとにタグをつけてあります。（2025-09-26 に java-app001-05、2025-09-26 版のパーマネントリンクを更新しました）


タグ
説明


java-app001-00
開発コンテナと初期の Java プロジェクト

java-app001-01
メッセージを変更したもの

java-app001-02
テストの追加

java-app001-03
テストが成功するもの

java-app001-04
ログ出力対応

java-app001-05
本記事で解説するもの

2025-09-26 時点の dvc-java ブランチ
2025-09-26 版


 Gemini CLI を使った開発まず、java-app001 プロジェクトの情報を基に、GEMINI.md の雛形を作成することから始めます。使用したプロンプトは次のとおりです。
このプロジェクトの GEMINI.md の雛形を作成すること
最初に生成された GEMINI.md は次のとおりです。日本語での生成も可能ですが、今回はシンプルな英語で出力されたものをそのまま利用します。
# GEMINI.md

This file provides instructions for Gemini on how to interact with this Java project.

## Project Overview

This is a simple Java application that prints a basic "Hello, World!" to the console. This project also includes logging functionality with SLF4J and Logback.

## Build

To build the project, run the following script. This script downloads dependencies, runs the Checkstyle linter, and compiles the source code.

```sh
./script/build.sh
```

## Run

To run the application, use the following script:

```sh
./script/run.sh
```

## Test

To run the project's tests, use the following script. This script first runs the main build script and then executes the JUnit tests.

```sh
./script/test.sh
```

## Project Structure

```text
java-app001/
├── bin/          # Compiled class files
├── lib/          # Dependency libraries (JARs)
├── logs/         # Log files
├── script/       # Shell scripts for build, run, and test
│   ├── build.sh
│   ├── run.sh
│   └── test.sh
├── src/          # Java source code
│   ├── App.java
│   ├── AppTest.java
│   └── logback.xml
├── .gitignore
├── google_checks.xml
├── java-app001.code-workspace
└── README.md
```
このファイルには、Gemini CLI がプロジェクトを理解し、開発を支援するために必要な情報が記載されています。この内容は、AI だけでなく人間が参照するドキュメントとしても役立ちます。
Gemini CLI は起動時に GEMINI.md を読み込んでコンテキストに追加します。そのため、ファイルを生成・更新した後は gemini コマンドの再起動が必要です。
このファイルに規約を追加していくことで、Gemini はそれを拠り所としてコードを生成します。これは、新しい開発者にプロジェクトのルールを伝えるプロセスと似ています。
今回は、次の項目について規約を追加するよう、Gemini に順番に指示を出しました。
コードスタイルの方針を作成して GEMINI.md へ反映すること
ロギングの方針を作成して GEMINI.md へ反映すること
テストの方針を作成して GEMINI.md へ反映すること
開発で使うソフトウェアのバージョンについて GEMINI.md へ反映すること

java-app001.code-workspace へ反映した方が良いことを提案すること
これらの簡単なプロンプトを元に、Gemini は方針を提案してきます。そこから対話を通じて詳細を詰めていきますが、このプロセスでは開発者の知見が最終的な成果物の質を左右します。
今回は、汎用性が高く実用的な雛形を作成することを目標としました。詳細な調整は開発の進行に合わせて行うものとし、ここでは基本的な方針の決定と、コマンドで動作確認できる状態にすることをゴールとしました。
なお、Gemini が生成した内容はあくまで雛形と捉え、最終的には手動で編集・校正することをおすすめします。実際、今回の作業でも「プロンプト実行 → gemini 終了 → エディタで校正 → gemini 再起動」というサイクルを繰り返しました。
このプロセスを経て、GEMINI.md の Project Overview と Build の間に、次のセクションが追加されました。
## Development Environment

- **JDK Version**: This project requires **Java 21**.
- **Environment**: The use of a **Dev Container** is recommended for a consistent development environment.

## Dependencies

The project dependencies are managed by the `script/build.sh` script and downloaded into the `lib/` directory. Key dependencies include:

- **Checkstyle**: `10.17.0`
- **SLF4J API**: `2.0.17`
- **Logback**: `1.5.6`
- **JUnit**: `4.13.2`
- **Hamcrest Core**: `1.3`

## Coding Style

This project uses the **Google Java Style Guide**. Compliance is enforced by **Checkstyle**.

The style check is automatically run as part of the build script. To run the check, execute:

```sh
bash script/build.sh
```

## Logging Policy

This project uses SLF4J and Logback for logging. The configuration is in `src/logback.xml`, and logs are written to the console and to the `logs/app.log` file.

Log levels are used as follows:

- `ERROR`: For fatal errors that prevent the system from continuing.
- `WARN`: For potential problems.
- `INFO`: For normal operational information (e.g., application start/stop).
- `DEBUG`: For detailed information useful for debugging.
- `TRACE`: For even more fine-grained information than DEBUG.

## Testing Policy

1. **Framework**: Tests are written using **JUnit 4**.
2. **Scope**: The focus is on unit tests. Each new class `Foo.java` should have a corresponding test class `FooTest.java`.
3. **Location**: Test classes are located in the `src/` directory alongside the source code.
4. **Execution**: Run tests using `bash script/test.sh`. This script first builds the entire project and then executes the tests. All tests must pass for a change to be considered complete.

最初に自動で作成された雛形と比較して、このプロジェクトにおける開発では何に対応しないといけないかが明確となったことがわかります。使用する開発用ソフトウェア、ライブラリの情報、レベル分けされたログ出力用コードが必要なこと、テストコードが必要なことについて、説明が追加されています。
この作業の過程で、Gemini からの提案や、こちらからの修正指示に基づき、既存ファイルもいくつか修正しました。それらについて、この後に説明します。

 Checkstyle によるコード品質の維持Gemini からの提案により、このプロジェクトでは、コードの品質と一貫性を保つために Checkstyle を導入することにしました。Checkstyle は、Java のソースコードが特定のコーディング規約に従っているかを検証する「静的解析ツール」です。

 コーディング規約ここで採用している規約は、広く使われている Google Java Style Guide です。これも Gemini から提案されたものを採用しています。ルールセットはプロジェクトルートの google_checks.xml に定義されていて、この用意も Gemini にしてもらいました。これにより、インデントのスタイル、命名規則、Javadoc の書き方といった細かなルールがプロジェクト全体で統一されます。

 実行と連携Checkstyle は、開発プロセスに以下の2つの方法で統合されています。
ビルド時の自動チェック
VS Code とのリアルタイム連携
script/build.sh を実行すると、ソースコードのコンパイル前に Checkstyle が自動で実行されます。規約違反が一つでも見つかるとビルドは失敗するため、規約に準拠しないコードがリポジトリにマージされるのを防げます。
VS Code 利用時は、java-app001.code-workspace で推奨されている Checkstyle for Java 拡張機能により、コードを記述している最中からリアルタイムで規約違反を検知できます。問題のある箇所はエディタ上に直接ハイライト表示されるため、開発者はすぐに修正できます。
このように、コマンドラインと IDE の両方で同じルールセットを共有することで、開発者と AI が生成するコードの双方に、一貫した品質基準を効率的に適用できます。

 java-app001.code-workspacejava-app001.code-workspace で推奨されている Checkstyle for Java 拡張機能については、Gemini に提案してもらったものです。これを採用した理由と、どのように指定しているかについて説明します。
Gemini CLI は CUI ツールですが、開発者は通常、VS Code のような GUI 環境でコードの確認や編集を行います。このプロジェクトでは VS Code と Dev Containers (Docker) の利用を想定しています。
そのため、コマンドラインでの対応と足並みを揃え、VS Code 上でも同等の開発体験が得られるように設定を整えることが望ましいです。GEMINI.md で Checkstyle の利用を定義したため、VS Code 側にも設定を反映させる必要があります。
そこで Gemini に確認したところ、Checkstyle 拡張機能 (shengchen.vscode-checkstyle) の利用が提案されました。その提案に従い、java-app001.code-workspace に設定を追加しています。ビルドスクリプトとバージョンを統一するため、Checkstyle のバージョンは 10.17.0 を指定しました。
ファイル全体を記載すると長くなるため、ここでは変更箇所のみを差分形式で示します。
***************
*** 28,33 ****
--- 28,41 ----
        // 参照ライブラリのパスを指定 (globパターンが使えます)
        "lib/**/*.jar"
      ],
+     // Checkstyleの設定
+     "java.checkstyle.configuration": "${workspaceFolder}/google_checks.xml",
+     "java.checkstyle.version": "10.17.0", // Checkstyleのバージョンを指定
+     // null 解析のモード
+     // - automatic:   自動で有効化 
+     // - disabled:    無効化 
+     // - interactive: 対話的に確認
+     "java.compile.nullAnalysis.mode": "automatic",
      // Lombok などの Java エージェントを使う場合の設定例（必要ならコメント解除）
      // "java.jdt.ls.vmargs": "-noverify -Xmx1G -jar /path/to/lombok.jar -Djava.awt.headless=true",
      // エクスプローラーから直接操作することのないファイル/フォルダを非表示
***************
*** 48,53 ****
--- 56,62 ----
    "extensions": {
      "recommendations": [
        "vscjava.vscode-java-pack",
+       "shengchen.vscode-checkstyle", // Checkstyle拡張機能
        "ms-azuretools.vscode-containers",
        "docker.docker",
        "eamodio.gitlens",
Checkstyle の設定以外に、"java.compile.nullAnalysis.mode": "automatic" の指定も追加してあります。これを指定しないと、VS Code でこのワークスペースを開いて Java プロジェクトを認識させたときに、Null annotation types have been detected in the project. Do you wish to enable null analysis for this project? といった通知が表示されます。それを抑制するためのものです。
これは VS Code にインストールされている Java 拡張機能が、プロジェクト内のコードやライブラリに @NonNull や @Nullable といった「null 関連のアノテーション」を検出したときに表示されるメッセージです。
null 解析を有効にする（Enable）と、NullPointerException を引き起こす可能性のあるコード（例：null かもしれない変数をチェックせずに使っている箇所）を VS Code が自動的に検知し、警告を表示してくれるようになります。これにより、コードの品質と安定性を高めることができるため、ここでは自動で有効化としています。。

 ロギング実装を Logback へ変更ロギング方針を決めるにあたって、「コンソールとファイルへのログ出力」という要件をいれところ、Gemini は SLF4J と Logback を使うことを提案されました。
slf4j-simple は、設定なしでコンソールにログを出力できる手軽な実装です。学習用には適していますが、今後の本格的なプログラミングで利用することを考慮すると、より高度な機能に対応しているものへ変更しておきたいところです。
一方、Logback は商用環境でも採用されることが多く、slf4j-simple より柔軟で高機能なロギングが可能です。また、slf4j-simple と同様に SLF4J と組み合わせて使えます。設定ファイル (logback.xml) を用いることで、ログの出力先（コンソール、ファイル）、フォーマット、レベルごとのフィルタリングなどを細かく制御できます。
以上のことから、筆者は「この提案は良い」と判断して、GEMINI.md のロギング方針に SLF4J と Logback を使用するという定義を記載することにしました。
これに伴い、Gemini へ既存コードの修正を依頼し、前回の記事で導入した slf4j-simple から Logback へ実装の切り替えについて対応しました。コード変更を Gemini が要件に応じて提案し、筆者がレビューと最終コードの作成をするという作業になりました。
最終的に、このプロジェクトでは、src/logback.xml を用意し、コンソールと logs/app.log の両方にログが出力されるように設定しました。この変更は script/build.sh にも反映されており、slf4j-simple の代わりに logback-core と logback-classic の JAR ファイルをダウンロードし、logback.xml をビルド時にクラスパスへコピーするようになっています。

 script/build.sh と script/test.shロギング実装の変更をしている最中に、Gemini から「ライブラリのバージョン管理を容易にするため、テスト実行時に script/build.sh を呼び出す方式」を提案されました。ここでは、この提案を受け入れ、両スクリプトを修正しました。
script/build.sh は次のようになります。
#!/bin/bash
SCRIPT_DIRNAME=$(dirname "$0")
PROJECT_DIR=$(cd "${SCRIPT_DIRNAME}/.." || exit 1;pwd)

# --- Create directories ---
echo "Creating directories..."
if [ ! -e "${PROJECT_DIR}/bin" ]; then mkdir -p "${PROJECT_DIR}/bin"; fi
if [ ! -e "${PROJECT_DIR}/lib" ]; then mkdir -p "${PROJECT_DIR}/lib"; fi
if [ ! -e "${PROJECT_DIR}/logs" ]; then mkdir -p "${PROJECT_DIR}/logs"; fi

# --- Download dependencies ---
echo "Checking dependencies..."
# SLF4J API (Interface)
if [ ! -e "${PROJECT_DIR}/lib/slf4j-api-2.0.17.jar" ]; then
  echo "Downloading slf4j-api..."
  curl -L -o "${PROJECT_DIR}/lib/slf4j-api-2.0.17.jar" https://repo1.maven.org/maven2/org/slf4j/slf4j-api/2.0.17/slf4j-api-2.0.17.jar
fi

# Logback (Implementation)
LOGBACK_VERSION="1.5.6"
if [ ! -e "${PROJECT_DIR}/lib/logback-core-${LOGBACK_VERSION}.jar" ]; then
  echo "Downloading logback-core..."
  curl -L -o "${PROJECT_DIR}/lib/logback-core-${LOGBACK_VERSION}.jar" "https://repo1.maven.org/maven2/ch/qos/logback/logback-core/${LOGBACK_VERSION}/logback-core-${LOGBACK_VERSION}.jar"
fi
if [ ! -e "${PROJECT_DIR}/lib/logback-classic-${LOGBACK_VERSION}.jar" ]; then
  echo "Downloading logback-classic..."
  curl -L -o "${PROJECT_DIR}/lib/logback-classic-${LOGBACK_VERSION}.jar" "https://repo1.maven.org/maven2/ch/qos/logback/logback-classic/${LOGBACK_VERSION}/logback-classic-${LOGBACK_VERSION}.jar"
fi

# JUnit (for testing)
if [ ! -e "${PROJECT_DIR}/lib/junit-4.13.2.jar" ]; then
  echo "Downloading junit..."
  curl -L -o "${PROJECT_DIR}/lib/junit-4.13.2.jar" "https://repo1.maven.org/maven2/junit/junit/4.13.2/junit-4.13.2.jar"
fi
if [ ! -e "${PROJECT_DIR}/lib/hamcrest-core-1.3.jar" ]; then
  echo "Downloading hamcrest-core..."
  curl -L -o "${PROJECT_DIR}/lib/hamcrest-core-1.3.jar" "https://repo1.maven.org/maven2/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar"
fi

# Checkstyle
CHECKSTYLE_VERSION="10.17.0"
CHECKSTYLE_JAR="checkstyle-${CHECKSTYLE_VERSION}-all.jar"
if [ ! -e "${PROJECT_DIR}/lib/${CHECKSTYLE_JAR}" ]; then
  echo "Downloading Checkstyle..."
  curl -L -o "${PROJECT_DIR}/lib/${CHECKSTYLE_JAR}" "https://github.com/checkstyle/checkstyle/releases/download/checkstyle-${CHECKSTYLE_VERSION}/${CHECKSTYLE_JAR}"
fi

# --- Run Checkstyle ---
echo "Running Checkstyle..."
if ! java -jar "${PROJECT_DIR}/lib/${CHECKSTYLE_JAR}" -c "${PROJECT_DIR}/google_checks.xml" "src/"; then
  echo "Checkstyle found violations. Build failed."
  exit 1
fi
echo "Checkstyle passed."

# --- Compile & Copy Resources ---
echo "Compiling source code..."
CP="${PROJECT_DIR}/src"
for f in "${PROJECT_DIR}/lib"/*; do
  CP="$f:${CP}"
done
javac -d "${PROJECT_DIR}/bin" -cp "${CP}" "${PROJECT_DIR}/src/App.java" "${PROJECT_DIR}/src/AppTest.java"

echo "Copying resources..."
cp "${PROJECT_DIR}/src/logback.xml" "${PROJECT_DIR}/bin/"

echo "Build successful!"
script/test.sh は次のようになります。
#!/bin/bash
SCRIPT_DIRNAME=$(dirname "$0")
PROJECT_DIR=$(cd "${SCRIPT_DIRNAME}/.." || exit 1;pwd)

# Run the build script first to ensure everything is compiled and up-to-date
echo "Running build script..."
if ! bash "${SCRIPT_DIRNAME}/build.sh"; then
    echo "Build failed. Aborting tests."
    exit 1
fi

# Run the tests
echo "
Running tests..."
CP="${PROJECT_DIR}/bin"
for f in "${PROJECT_DIR}/lib"/*; do
  CP="$f:${CP}"
done
java -cp "${CP}" org.junit.runner.JUnitCore AppTest
この構成は、ライブラリのバージョン管理のメンテナンス性を向上させる一方で、実行時ライブラリとテスト用ライブラリの区別が曖昧になるという欠点があります。
この問題に対応するには、開発用と実行用のビルドを分離するなどの方法が考えられます。しかし、そこまで複雑化するのであれば、Apache Maven や Gradle といった本格的なビルドツールを導入する方が合理的です。そのため、今回は対応を見送りました。
このプロジェクトは、あくまで学習や小規模なライブラリ試用を想定しており、複雑な依存関係管理よりも、全体像の把握しやすさを優先しています。
こういった判断は、Gemini へ指示を出している開発者が下すものになります。実際のところ、最初の指示のときに Gemini へ「学習や小規模なライブラリ試用のためのプロジェクトを想定」とはしていなかったので、これに適していない提案もいくつかあり、却下しています。Gemini へ同じ指示をしても、開発者によって最終的な成果物がちがってくるのは、こういった暗黙の要求が対話時に明確となるからです。

 開発者向けの README.md
GEMINI.md には Gemini 向けに、このプロジェクトの開発方法について説明がありますが、英語で記述しています。これは、Gemini が解析する際に、英語の方が内容を正確に把握できると期待されるためです。
ここでは、日本人の開発者が参照しやすいように、日本語の README.md も別途用意しました。こちらも Gemini を使って生成したものです。こちらは開発者向けのため、VS Code の使い方も含めて説明しています。Gemini は基本的に GUI 操作を必要としないため、そういった説明は GEMINI.md には記載しません。
また、リスト形式よりも表形式の方が見やすい項目は、表を用いて表現しています。
作成した README.md は次のようになります。
# java-app001

これは、基本的な "Hello, World!" をコンソールに出力するシンプルな Java アプリケーションです。このプロジェクトは、SLF4J と Logback によるロギング機能も含んでいます。

## 必要なもの (Prerequisites)

- Java Development Kit (JDK) 21

## 主な依存ライブラリ (Dependencies)

依存ライブラリは `script/build.sh` によって `lib/` フォルダにダウンロードされます。

| ライブラリ    | バージョン | 説明                                                                                                       |
| ------------- | ---------- | ---------------------------------------------------------------------------------------------------------- |
| Checkstyle    | `10.17.0`  | Java ソースコードがコーディング規約に準拠しているかをチェックするための静的解析ツール。                    |
| SLF4J API     | `2.0.17`   | 各種ロギングフレームワーク（Logback など）のシンプルなファサード。                                         |
| Logback       | `1.5.6`    | SLF4J のネイティブ実装であり、Log4j の後継として広く使われている高パフォーマンスなロギングフレームワーク。 |
| JUnit         | `4.13.2`   | Java アプリケーションのユニットテストを記述・実行するためのフレームワーク。                                |
| Hamcrest Core | `1.3`      | `assertThat`構文を使い、より宣言的で可読性の高いアサーション（テストの検証文）を記述するためのライブラリ。 |

## 開発環境 (Development Environment)

開発環境の差異をなくすため、VS Code の **Dev Container** を使用することを推奨します。

### VS Code 拡張機能

このプロジェクトを VS Code で開くと、`java-app001.code-workspace`ファイルに基づき、以下の拡張機能のインストールが推奨されます。

- [Extension Pack for Java](https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack)
- [Checkstyle for Java](https://marketplace.visualstudio.com/items?itemName=shengchen.vscode-checkstyle)
- [Dev Containers](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-containers)
- その他、Git 関連の便利な拡張機能

## 使い方

### ビルド

プロジェクトをビルドするには、以下のスクリプトを実行します。
このスクリプトは、依存関係をダウンロードし、Checkstyle でコードスタイルをチェックし、ソースコードをコンパイルします。

```bash
./script/build.sh
```

### 実行

アプリケーションを実行するには、以下のスクリプトを使用します。

```bash
./script/run.sh
```

実行すると、コンソールに "Hello, World from VS Code!" と表示されます。

### テスト

プロジェクトのテストを実行するには、以下のスクリプトを使用します。このスクリプトは、まずプロジェクト全体のビルド（依存関係の解決、スタイルチェック、コンパイル）を実行し、その後 JUnit テストを実行します。

```bash
./script/test.sh
```

## テスト方針 (Testing Policy)

1. フレームワーク: テストは **JUnit 4** を使用して記述します。
2. テストの粒度: 主に単体テスト（ユニットテスト）に焦点を当てます。クラスの public なメソッドの動作を個別に検証します。
3. テストの場所: テストクラス（`...Test.java`）は、テスト対象のクラスと同じ `src` フォルダに配置します。これは、プロジェクトの構成をシンプルに保つための意図的な選択です。
4. テストの実行: テストは `bash script/test.sh` を実行して行います。すべてのテストが成功することをもって、変更の完了とします。
5. アサーション: `org.junit.Assert` が提供するメソッド（`assertEquals`, `assertTrue` など）を使用して結果を検証します。

## コーディングスタイル (Coding Style)

このプロジェクトでは、**Google Java Style Guide** をコーディング規約として採用しています。

規約への準拠は [Checkstyle](https://checkstyle.org/) によって自動的にチェックされます。チェックはビルドスクリプトに組み込まれており、`./script/build.sh` を実行するたびに実行されます。

設定ファイル: `google_checks.xml`

## ロギング方針 (Logging Policy)

このプロジェクトでは、ロギングに SLF4J と Logback を使用します。設定は `src/logback.xml` にあり、ログはコンソールと `logs/app.log` ファイルに出力されます。

### ログレベル

以下の基準でログレベルを使い分けます。

| レベル  | 説明                                                                       |
| ------- | -------------------------------------------------------------------------- |
| `ERROR` | システムの続行を妨げる致命的なエラー。                                     |
| `WARN`  | 潜在的な問題や、現在はエラーではないが将来的に問題になる可能性のある状況。 |
| `INFO`  | システムの正常な動作を示す情報。アプリケーションの起動・終了など。         |
| `DEBUG` | 開発者がデバッグ時にのみ必要とする詳細情報。                               |
| `TRACE` | `DEBUG` よりもさらに詳細な情報。                                           |

## プロジェクト構造

```text
java-app001/
├── bin/          # コンパイルされたクラスファイル
├── lib/          # 依存ライブラリ (JARs)
├── logs/         # ログファイル
├── script/       # ビルド、実行、テスト用のシェルスクリプト
│   ├── build.sh
│   ├── run.sh
│   └── test.sh
├── src/          # Javaソースコード
│   ├── App.java
│   ├── AppTest.java
│   └── logback.xml
├── .gitignore
├── google_checks.xml
├── java-app001.code-workspace
└── README.md
```
いまのところ、GEMINI.md と README.md と比較すると、重複している部分が多くあります。今後、内容を充実させていく過程では、差分が大きくなっていくことでしょう。重複する部分のメンテナンスが大変になってきたら「GEMINI.md を参照するように README.md を変更し、GEMINI.md の内容を日本語とする」といった対応も考えられます。
いずれにせよ、AI 向けと開発者向けのドキュメントは目的が違うものなので、別々に用意しておいた方がメンテナンスしやすいはずです。

 まとめこの記事では、Gemini CLI を活用して、既存の Java プロジェクトに開発規約を整備していくプロセスを紹介しました。中心的な作業は GEMINI.md の作成であり、ここに開発環境、依存関係、コーディングスタイル、ロギング、テストの方針を定義しました。
このプロセスに連動し、ビルドスクリプト (build.sh, test.sh) の改善や、VS Code のワークスペース設定 (java-app001.code-workspace) の更新も行いました。
ビルドツールを使わないシンプルな構成を通して、AI をプロジェクト開発に参加させるための準備をどのように進めるか、具体的なイメージを掴んでいただけたのではないでしょうか。このような環境を整えることが、AI との協調による開発を円滑に進める第一歩となります。

 次の記事

VS Code の Java プロジェクトを Gemini CLI に対応させよう

はじめに

サンプルコード

Gemini CLI を使った開発

Checkstyle によるコード品質の維持

コーディング規約

実行と連携

java-app001.code-workspace

ロギング実装を Logback へ変更

script/build.sh と script/test.sh

開発者向けの `README.md`

まとめ

次の記事

Discussion

タグ	説明
java-app001-00	開発コンテナと初期の Java プロジェクト
java-app001-01	メッセージを変更したもの
java-app001-02	テストの追加
java-app001-03	テストが成功するもの
java-app001-04	ログ出力対応
java-app001-05	本記事で解説するもの
2025-09-26 時点の dvc-java ブランチ	2025-09-26 版