本記事は、2026/5/30開催の「JJUG CCC 2026 Spring」の登壇内容に関連した技術記事シリーズです。
AIエージェント（Copilot / Claude Code / Cursor）の普及により、Java開発の前提は大きく変わりました。
本シリーズでは「AI時代における設計の変化」をテーマに、実務視点で整理していきます。
【シリーズ一覧】
- AI時代にJava設計はどう変わったのか（本記事）
- カッペリーニコードとは何か
- Java17/21は設計をどう変えたか
- AIは設計できるのか
- AI時代の設計ガードレール
この記事で得られること
- AI（Copilot / Claude Code / Cursor Agent）前提での開発スタイルの変化が整理できる
- Java17 / 21の進化が「設計」にどう影響したか理解できる
- なぜ「コードはきれいなのにシステムは複雑になるのか」が腹落ちする
- AI時代において人間が設計すべき領域が明確になる
結論
AIによってコードは簡単に書けるようになった。
Javaによってコードはさらにシンプルになった。
しかし、
設計の難易度はむしろ上がっている。
なぜ今この話をするのか
ここ1〜2年で開発の前提が明確に変わりました。
- Copilotによるコード補完
- Claude Code / Cursor Agentによる複数ファイル変更
- AIによるテスト生成・リファクタリング・PR作成
もはやAIは「便利な補助ツール」ではなく、
開発を実行する主体の一部
になっています。
この変化を前提にしない設計は、確実に破綻します。
1. AIエージェントによって「開発の主語」が変わった
現在のAIは大きく3つに分類できます。
| 分類 | 代表例 | 役割 |
|---|---|---|
| 補完型 | Copilot | コード補完 |
| エージェント型 | Claude Code / Cursor Agent | 実装・修正・リファクタリング |
| IDE統合型 | Cursor / Windsurf | プロジェクト理解 |
特に重要なのはエージェント型です。
従来：
人間が設計し、人間がコードを書く
現在：
人間が意図を伝え、AIが実装する
さらにAIは複数ファイル変更、リファクタリング、テスト生成、PR作成まで実行します。
つまり、
「コードを書く」という行為はほぼ自動化された
と言えます。
2. 開発は「ツール」ではなく「プロセス」から変わっている
現在議論されている代表的な概念は以下です。
| 概念 | 概要 |
|---|---|
| CC-SDD | コード中心で設計・開発を進める思想 |
| AI-DLC | AIを組み込んだ開発プロセス全体 |
| OpenSpec | 仕様を中心にAIと連携する手法 |
| Spec-Driven Development | 仕様から実装・テストを生成するアプローチ |
| PromptOps | プロンプト設計・管理・運用の体系化 |
| Agentic Development | AIが自律的に開発を進めるモデル |
これらに共通しているのはシンプルです。
コードを書く主体が人間からAIへ移行している
では人間は何をするのか？
構造・意図・制約を設計する
これが役割になります。
3. Java17 / 21は「コードを正しく書きやすくした」
JavaもAI時代と相性の良い方向に進化しています。
| 機能 | 効果 |
|---|---|
| Record | DTOを簡潔に表現 |
| Sealed Classes | 型の制約を明確化 |
| Pattern Matching | 分岐をシンプル化 |
| Virtual Thread | 並列処理を扱いやすく |
これらの進化によって、
短く・明確なコードを書くことが容易になった
のは間違いありません。
ただし重要なのは、
これらは設計を保証する機能ではない
という点です。
4. 「きれいなコード」は簡単に作れるようになった
現在は以下のようなコードは簡単に生成できます。
- Controller
- Service
- Repository
- DTO
- Testコード
しかも命名は自然、レイヤー構造は整理されている、可読性も高い。
つまり、
局所的には非常にきれいなコードが量産される
状態になっています。
5. それでも複雑性が消えない理由
ここが本質です。
AI時代に増えている問題は次のようなものです。
- クラスが増えすぎる
- 小さな責務が分散する
- 依存関係が増える
- 全体像が見えなくなる
例えばよくある構成です。
UserController
UserService
UserUseCase
UserFacade
UserMapper
UserDTO
UserResponse
UserRequest
一つ一つは正しく、きれいです。
しかし、
全体として何をしているのかが見えにくい
なぜこうなるのか
理由は明確です。
AIは局所最適を積み重ねることに非常に強い一方で、全体構造を維持する主体ではありません。
さらに人間側も、コードを書かなくなり、構造に触れる機会が減るという変化が起きます。
その結果、
コードはきれい
しかし設計は見えなくなる
という状態になります。
さらに重要な問題
設計の責任がどこにも存在しなくなる
- AIは設計を生成するだけ
- 人間は構造を深く触らない
この状態が最も危険です。
6. AI時代に人間が設計すべき領域
ここは明確に分ける必要があります。
✅ AIに任せてよいもの
- CRUD実装
- DTO生成
- テストコード
- 単純なリファクタリング
🔴 人間がやるべきもの
- パッケージ構造
- レイヤー設計
- 責務分割
- トランザクション境界
- 依存関係の制御
設計判断のチェックポイント
実務で使える観点として、最低限ここを見ます。
- そのクラスは存在理由を説明できるか
- 依存関係は一方向か
- 変更時の影響範囲が読めるか
- 同じ責務が分散していないか
まとめ
- AIによってコード生成はほぼ自動化された
- Javaの進化によってコードはさらにシンプルになった
- しかし設計は自動化されていない
そして最も重要なのはこれです。
AI時代では「コードを書く力」より「構造を設計する力」が価値になる
次回予告
従来、設計が崩れたコードは「スパゲッティコード」と呼ばれてきました。
しかしAI時代の問題は異なります。
- 細かいクラスが大量に存在する
- 一つ一つはきれい
- しかし構造は絡み合っている
私はこれを 「カッペリーニコード」 と呼んでいます。
次回はこの問題を深掘りします。
シリーズ一覧
- AI時代にJava設計はどう変わったのか（本記事）
- カッペリーニコードとは何か
- Java17/21は設計をどう変えたか
- AIは設計できるのか
- AI時代の設計ガードレール