スパゲッティコードの次は「カッペリーニコード」？ AI時代に問われる設計責任【JJUG CCC 2026 Spring】

AI時代に問われる設計責任

私は普段、GMOペイメントゲートウェイ株式会社（以下、GMO-PG）で、AIエージェントを使った開発プロセスの効率化や、設計、アーキテクチャ、性能、セキュリティなど、プロダクト全般に関わっています。

開発では、Claude CodeやGitHub Copilotなども活用しています。そうした実務での経験を通じて、AI時代の開発には新しい設計上の課題があると感じるようになりました。

スパゲッティコードという言葉は、多くのエンジニアにとってなじみがあると思います。
ただ、AI時代に発生する問題は、従来のスパゲッティコードとは少し違います。
一つひとつのコードは小さく、整っていて、テストも通る。けれども、システム全体で見ると、設計意図や責務の境界が見えにくくなっている。

私はこの状態を、従来のスパゲッティコードに対して「カッペリーニコード」と定義しました。

結論から言うと、AIの生成力を活かしながら設計を守るには、設計ガードレールを仕組みにすることが大事だと考えています。
コードを書く速度が上がるほど、設計を人間の記憶や暗黙知だけに頼るのは難しくなります。だからこそ、構造を先に決め、制約をAIが読める形で書き、CIで自動検知する仕組みが必要になります。

開発の主語が変わった

この1〜2年で、開発の主語が変わったと感じています。

これまでは、GitHub Copilotなどの補完ツールを使いながらも、基本的には人間がコードを書く状況でした。

しかし現在は、Claude CodeなどのAIエージェントが現場に入り、AIが実装するのが当たり前になりつつあります。人間は、コードを一行ずつ書く側から、設計や意図を伝える側へと重心が変わってきました。

もちろん、この変化自体はとても良いものです。私自身も、AIエージェントによる開発の効率化に大きな恩恵を受けています。
ただし、問題もあります。
ソースコードの開発速度が10倍、20倍になっている一方で、設計のプロセスがそれに追いついていないことです。特に、設計プロセスをAIに伝える仕組み化が追いついていない点が、大きな課題だと感じています。

少しJavaの話にも触れます。
Java 17以降、recordやVirtual Threadをはじめとする言語機能の進化により、Javaの実装は大幅にシンプルになりました。
Java 25でもその流れは続いており、AIはこれらの機能を活用しながら、以前より少ないコードで機能を実現できます。
つまり、実装は簡略化していきます。

ただ、減ったのは実装の複雑さであって、設計の複雑さ自体は減っていません。
AIがコードを書くことで、その複雑さはソースコードの見た目から、設計意図や構造の管理へ移動している。私はそう考えています。

AIが出すコードは、局所的には非常に整っています。
レビューをしていると、一つひとつのクラスは小さくまとまっていて、命名もきれいで、冗長感も少なく、テストも通るコードが出てきます。ヘルパークラスやマッパークラスなども、Javaに則った形で自然に作られます。
しかし、小さなクラスが大量に量産される一方で、全体としての設計思想や設計の意図を誰が管理するのか。ここが大きな問題になります。

「カッペリーニコード」とは何か

この状態を、私は「カッペリーニコード」と定義しました。

カッペリーニは、パスタの中でも一番細いパスタです。冷製パスタなどに使われる、スパゲッティよりも細い麺です。
従来のスパゲッティコードよりも細く、小さく、見た目には整っている。しかし、それらが大量に絡み合うことで、全体構造が分かりにくくなる。
そのイメージから、「カッペリーニコード」と呼んでいます。

スパゲッティコードと比較すると、その違いが分かりやすくなります。

スパゲッティコードは巨大です。レガシーな技術を使っていて、とても冗長です。ただ一点、良いところがあります。新卒のエンジニアでも「これは明らかにおかしい」と気づけることです。
一方、カッペリーニコードは、一つひとつが小さく、モダンな技術も使っていて、整っています。
そのため、新卒エンジニアだけでなく、ベテランエンジニアでもなかなか問題に気づきにくい。本当に設計の意図と合っているのかが分かりにくいのです。

まとめると、スパゲッティコードは設計の崩壊です。一方、カッペリーニコードは設計の不在です。

しかも、カッペリーニコードはきれいなので、現場に危機感が生まれません。そこが問題です。

Spring Bootで起きる3つの問題

Spring Bootでカッペリーニコードが表面化する例として、「DTOの無秩序な増殖」「ドメインロジックの責務分散」「構造の不可視化」の3つを紹介します。

1つ目：DTOの無秩序な増殖

1つ目は、DTOの無秩序な増殖です。
設計をAIにまったく伝えずに作らせると、リクエスト用、レスポンス用、Create用、Update用など、設計の意図に関係なくDTOが増えていきます。
一つひとつのDTOは小さく、単体では問題がないように見えます。しかし、全体で見ると、なぜそのDTOが必要なのか、どこまでが責務なのかが分かりにくくなります。

2つ目：ドメインロジックの責務分散

2つ目は、ドメインロジックの責務分散です。
いわゆるサービスクラスが空っぽになるような状態です。サービスクラスから、ヘルパークラス、マッパークラス、ドメインクラス、ユーティリティクラスなどに処理が移譲され、ロジックが複数の補助クラスに散らばっていきます。
最終的に、ドメインモデルが不在になるという問題です。
これも、一つひとつのクラスだけを見ると整っているように見えます。ただ、どこに本来の業務ルールがあるのか、どこを変更すればよいのかが分かりにくくなります。

3つ目：構造の不可視化

3つ目は、構造の不可視化です。
クラスがたくさんできます。そのため、レビュアーは10個、20個のクラスを横断しながら、それが設計と合っているのか、要件定義と合っているのかを見なければいけません。
しかし、全体像がなかなか脳内に収まらず、「なんとなく良いかな」という感じになってしまう。そこが問題です。
AIは、局所最適の積み重ねに非常に強いです。ただ、全体構造を維持する主体ではありません。やはり全体構造は、人間が主体でなければいけない点は変わっていません。
なぜ、こうしたカッペリーニコードが発生するのでしょうか。
AIは、長期的な全体整合性までは維持しません。
小さなプロダクトや小規模な開発では、AIを使うと「全然完璧じゃん」「設計までそこまでやらなくても大丈夫じゃん」と感じることがあります。
しかし、中長期的な案件では、途中でお客様の要件が変わったり、追加要件が出たり、法律改正に対応したりする必要があります。そういった対応は、AIに丸投げするだけではなかなかできません。
AIに作らせると、きれいなコードはレビューを通過してしまいます。その結果、カッペリーニコードができてしまう。
レビュアーも、スパゲッティコードならすぐに気づけます。しかしカッペリーニコードの場合は、「設計と合っていそうだし、テストも通っているし、大丈夫かな」となりがちです。悪い理由を言語化できず、そのまま承認されてしまいます。
最終的に、カッペリーニコードが量産され、全体を見ている設計責任者がいなくなる。そうした状況が起こり得るのです。

設計ガードレールで構造を守る

では、カッペリーニコードをどう防いでいくのか。
私は、設計を守るために「設計ガードレール」を仕組みにする必要があると考えています。

設計ガードレールには、3つの柱があります。

1つ目：構造を先に固定する

1つ目は、構造を先に固定することです。
AIにコードを書かせる前に、まず人間が決めるべきなのは構造です。
例えば、

• どのパッケージに何を配置するのか
• Controller、Service、Repositoryの責務をどう分けるのか
• ドメインモデルをどこに置くのか
• テストコードをどのように配置するのか

といったルールを先に定義します。

最近では、AI向けの設計書やルールファイルをリポジトリ内で管理することも珍しくありません。
AIは与えられた構造やルールに従って実装することは得意です。しかし、システム全体をどのような構造で組み立てるべきかという設計責任までは、AIに丸投げできません。
だからこそ、パッケージ構造やレイヤーの責務、設計ルールを先に明文化しておくことが重要なのです。

2つ目：制約をファイルに書く

2つ目は、今すぐできる重要なポイントです。制約をファイルに書くことです。
Claude Codeであれば、CLAUDE.mdやルールファイルにあたるものです。
このファイルに、プロダクトやプロジェクトで絶対に守らなければいけないルールを書きます。
Spring Bootであれば、「Controllerから必ずServiceを呼び、そこからDomain、もしくはRepositoryを呼ぶ」といったプロジェクトのルールを、制約として書きます。
口頭で共有されているだけのルールでは、AIは参照できません。AIが読み取れる場所に、設計上の制約を明文化しておく必要があります。

3つ目：CIで自動検知する

3つ目は、CIで自動検知することです。
人間のレビューだけでは、設計ルール違反を防ぎきれません。そのため、CIによる自動検証が欠かせません。
例えばArchUnitを使えば、「ControllerからRepositoryを直接呼び出してはならない」といった設計ルールをテストとして定義できます。さらにGitHub Actionsなどに組み込むことで、AIが生成したコードも含めて継続的に検証できます。
まとめると、制約を設計するのは人間、制約の中で実装するのはAI、そして制約を検証するのは仕組みです。

この3つの柱を持って、AIにカッペリーニコードを作らせない環境を作ることが、今後の課題になります。

AIに任せること、人間が担うこと

改めて、AIに任せることと、人間が担うことを整理します。

AIには「どう書くか」を任せます。
CRUDの実装、DTOの作成、テストコードの生成、典型的なリファクタリングなどは、人間よりも早く、一定品質で実装できるようになりました。
しかし、人間が担うべき役割までなくなったわけではありません。人間が決めるべきなのは、「なぜそのような構造にするのか」です。
例えば、

• パッケージ構成
• レイヤーの責務
• ドメインの境界
• トランザクションの境界
• 非同期化の方針
• 外部システムとの接続ルール

といったアーキテクチャや設計上の判断です。
AIは与えられたルールの中で実装することは得意ですが、そのルール自体を決めることはできません。
エンジニアの価値は、「コードを書くこと」から「構造を設計すること」へと重心が移りつつあります。
AIが「どう書くか」を担えるようになるほど、人間には「なぜその構造にするのか」を定義する力が求められるのです。

きれいなコードは、良い設計とは限らない

この記事で伝えたいことはシンプルです。
きれいなコードは、良い設計を保証しません。
AIはコード生成や設計書作成を支援できます。しかし、設計意図を維持しながらシステムを成長させる責任まで担ってくれるわけではありません。
だからこそAI時代には、AIが実装しやすい構造とルールを人間が設計することが重要になります。
大切なのは次の3つです。

• 構造を設計する
• ルールを明文化する
• CIで継続的に検証する

この3つの仕組みがあれば、AIを活用しながら設計を守り続けることができます。まずは月曜の朝、AI設定ファイルに設計ルールを3行書くところから始めてみてください。

質疑応答

JJUG CCC 2026 Springの登壇後には、依存関係チェックの仕組みや、CIで検出しきれないルールの扱い、AI向けドキュメントの設定方法について質問をいただきました。ここでは、その内容を一部紹介します。

Q. 依存関係をチェックする仕組みは導入していますか？

質問者：先ほど、ガードレールの仕組み化というところで、AIの設定ファイルを設けるという話がありました。例えば、JDependのような依存関係を調べるライブラリをCIに組み込むようなことはやっていますでしょうか。
レイヤードアーキテクチャでは、Controller、Serviceというふうに必ず流れが決まっていて、ViewからServiceへ直接行ってはいけない、といったルールがあります。そのようなパッケージ間の依存関係をチェックする仕組みの導入事例があれば教えてください。

森本：近い取り組みは行っています。
ArchUnitによるアーキテクチャテストに加え、GitHub Actionsのワークフローでもさまざまなチェックを実施しています。
私たちのプロジェクトでは、画面側・クライアント側・サーバー側のコードが同一リポジトリ内に存在するため、それぞれの責務や依存関係が崩れないようにCIで検証しています。
また、プルリクエストのマージ前に必ずチェックを実行し、ルール違反がある場合はレビュー工程に進めない仕組みにしています。
設計ルールをドキュメントだけで管理するのではなく、CIで継続的に検証することが重要だと考えています。

Q. CIでチェックしきれないルールはどう扱いますか？

質問者：ルールや設計のポイントをファイルに書いているとお聞きしました。実際の運用ではCIでルール違反を検出する形になると思いますが、CIだけでは完璧にチェックしきれないルールもあるのではないかと思っています。
その場合、守ってほしいルールをファイルに書いていても、AIが守ってこないケースはありますか。
小さな修正であれば、書いてあるルールをほぼ守れていてレビューが不要なレベルなのか。それとも、やはりCIだけでは難しい部分があるのか。そのあたりの所感を教えてください。

森本：小さな修正に関しては、ほぼ100%に近い精度でルールを守ってくれます。
ただ、画面側の修正、APIの変更、業務ロジックの変更など、複数の要件が絡むものを一度に任せると、まだうまくいかないケースがあります。
やはり現時点では、人間のフォローは必要です。
AI駆動のフレームワークも登場していますが、AIに丸投げするのではなく、対話しながら進めることが重要だと考えています。AIとのキャッチボールを通じて認識のずれを減らし、少しずつ品質を高めていく。そうしたプロセスはまだ必要だと思っています。

質問者：つまり、ガイドに書くのも重要だけれど、設計者側がそのルールを理解した上でレビューするところが、今後かなりポイントになるということですね。

森本：そうですね。
AIは「こう理解しました」という形で結果を出してきます。それに対して、人間が「それで合っている」「そこは違う」とフィードバックしながら進めていくことが大切だと思います。

Q. AI向けドキュメントの設定方法にコツはありますか？

質問者：AIに指示を出す事前のところで、エージェント向けのドキュメントなど、いろいろなドキュメントが階層型になって、ボリュームが大きくなると、AIが混乱するのではないかと思います。
このあたりで、ベストな設定の仕方はありますか。

森本：私はClaude CodeとGitHub Copilotを併用していますが、AI向けのルールが重複しないように気を付けています。
例えば、.claude/CLAUDE.mdには比較的大きな方針やルールを書き、細かい内容は別ファイルに切り出して参照させています。
Copilot側も同様で、カスタムインストラクションには詳細なルールを直接書かず、共通のルールファイルを参照する形にしています。
そうすることで、複数のAIを利用していてもルールの管理を一元化できます。
また、AIだけでなく人間が見ても理解しやすい構造にすることを意識しています。できるだけシンプルな構成にして、「どこを見れば何が分かるのか」がすぐに分かる状態を目指しています。

FAQ

GMO-PGのエンジニアリングに関心のある方へ。
GMO-PGでは、決済・金融領域のシステムを支える開発に取り組んでいます。継続的な変更に耐えられる設計や、安定して運用できる構造は、そうした開発においても重要なテーマです。

関連する技術発信やイベントレポートも、あわせてご覧ください。

▶ 関連採用情報：エンジニア・デザイナーの求人一覧を見る

エンジニアイベント書き起こし記事一覧はこちら

採用情報はこちら

パートナーインタビュー記事一覧はこちら