Spring Boot×DockerのエラーをAIで即修復する方法

はじめに｜Spring Boot×Docker開発、なぜAIが必要なのか？

Spring Boot と Docker を組み合わせた開発は、マイクロサービス化や環境統一の文脈で非常に一般的になりました。しかし、以下のような「地味にハマるエラー」に多くの開発者が苦しんでいます：

application.yml の設定ミスによる 502 / 500 エラー
select2 is not a function のようなフロントエンド由来の謎エラー
依存関係のバージョン不一致による起動失敗

しかも、これらのエラーは修正してもDocker再ビルドのたびに時間がかかり、心理的にも体力的にも辛いループに陥りがちです。

本記事では、こうしたつまずきを AI（Repeton 的な自動パッチ生成）と Copilot/Cody などの補完ツールを併用することで、一気に効率化する手法を紹介します。

Spring Boot + Docker + AIツール：環境構築のベストプラクティス

このセクションでは、AIによる自動修復を活かすための最低限の環境構築方法を説明します。

前提環境

Java 17
Spring Boot 3.x
Docker & Docker Compose
GitHub Copilot / Cody（どちらでも可）
Node.js（JSエラーの再現用）

Dockerfile のサンプル（Spring Boot）

FROM eclipse-temurin:17-jdk
WORKDIR /app
COPY build/libs/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

docker-compose.yml（データベース付き）

version: '3'
services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db
  db:
    image: postgres:14
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass

ポイント：この構成で「コード変更→AIパッチ→再ビルド→確認」の流れをスムーズに回せるようになります。

Repeton風：AIデバッグ＆自動修復の基本フローを理解する

「Repeton」とは、LLM（大規模言語モデル）を用いて以下のような自動修復ループを回すアプローチです：

バグの症状を収集（ログ／テストエラー）
AIがパッチ案を提示
テスト or 起動で再確認
結果をフィードバックして再提案

この流れを手動で行うことで、どんなAIツールを使っても「自己修復型開発環境」が構築できます。

エラーログ → Copilotに貼る → パッチ案を得る → テスト → 再度貼る → 改善案が進化

JavaScript エラー編：select2 is not a function をAIで解決する

このセクションで解決できること

フロントエンドでの select2 系エラーの再現
AI による修復提案 → 実装 → テストまでの一連フロー

× エラー再現コード

<!-- jQuery がロードされていない状態 -->
<script src="select2.min.js"></script>
<script>
  $('#select').select2();
</script>

Copilot / Cody に貼るプロンプト例：

Uncaught TypeError: $(...).select2 is not a function
上記のエラーを修正するには、どの順序でライブラリを読み込めばよいか？

✔︎ AI のパッチ提案（正しい順序）

<script src="jquery.min.js"></script>
<script src="select2.min.js"></script>
<script>
  $(document).ready(function() {
    $('#select').select2();
  });
</script>

✔︎ 確認：Docker環境でも正しく表示されるか検証しよう

Spring Boot 502/500 エラーをAIで修復する実践例

🎯 このセクションで解決できること

Spring Boot アプリが Docker 上で 502 / 500 を返す原因を特定
application.yml の設定ミスを AI で修復

× ダメな application.yml

server:
  port: "eighty"

上記は ポート番号を文字列で記述しているため、起動時にエラーが発生します。

✔︎ AI 修正案（Copilot 提案）

server:
  port: 8080

さらに、depends_on に DB を指定したのに JDBC 設定が不完全というケースも頻出です。

✔︎ 不足していた JDBC 設定を補完

spring:
  datasource:
    url: jdbc:postgresql://db:5432/mydb
    username: user
    password: pass

ポイント：AI は文法・設定の「形式的正しさ」まで補完してくれるので、誤設定の早期発見に役立ちます。

AI 補完ツールとの協調：Copilot / Cody でレビューする

Copilot や Cody を「ただの補完ツール」で終わらせるのはもったいない。
Repeton的な修復サイクルの中で、「差分のレビュー担当」として活用すると強力です。

活用例：

Uncaught TypeError を貼って、修正案を提示
提案されたコードを 別タブでレビュー要求（「この修正で正しいか？」と聞く）
修正理由と文脈を教えてもらい、最終判断を人間が下す

CI/CDへの応用：GitHub Actionsで自動パッチ検証を仕込む

本番運用を見据え、Repeton的なパッチ検証を CI/CD に組み込む方法を紹介します。

.github/workflows/test.yml

name: Patch Test
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build Docker
        run: docker-compose up -d --build
      - name: Run Tests
        run: docker exec app ./gradlew test

ポイント：パッチ提案を PR に乗せたら、自動でビルド＆テストし、問題なければマージ判定できる。