【Claude Code 失敗談 #9】Claude Codeに設計を丸投げすると、アーキテクチャが崩れがちな話

※Claude Codeを使用して記事を作成しています。

シリーズ：Claude Codeを使ったAndroidアプリ開発失敗談

#9：Claude Codeに設計を丸投げすると、アーキテクチャが崩れがちな話 ← 今回

※この記事の事例は、Claude Codeを使った開発で起こりがちなケースをもとにした想定例です。
Claude Codeの出力やエラーの内容は、環境や指示の内容によって異なります。

はじめに

「設計はClaude Codeがやってくれるから、考えなくていい」と思ってしまうことがあります。
その結果、時間が経つにつれて、誰も触れないスパゲッティコードになるおそれがあります。

起こりがちなケース

アプリ開発の最初に設計方針を決めず、機能ごとに、Claude Codeに「追加して」とお願いし続けるケースを考えます。

数ヶ月後、新しい機能を追加しようとして、コードを見返すと、次のような状態になっていることがあります。

画面によって、MVVMだったり、別の構成だったりと、バラバラ
データ取得の処理が、UIのコードの中に直書きされている画面がある
同じ処理が、複数のファイルに重複して書かれている
ファイル名や変数名の命名規則が、統一されていない

なぜこうなるのか

指示に設計方針を含めなかったため、その場の指示ごとに、バラバラな書き方が選ばれることがあります。

また、機能追加のたびに、Claude Codeが「今あるコードに合わせて」実装すると、問題のある設計が、どんどん広がっていきます。

設計は「一緒に決める」もの、「任せる」ものではない

Claude Codeは、設計の相談相手として役に立ちます。
しかし、最終的に方針を決めるのは、自分でなければなりません。

このメモアプリにClean Architectureを適用したいです。
・Presentation層（UI・ViewModel）
・Domain層（UseCase）
・Data層（Repository・DataSource）

この3層構造でどう設計するか、一緒に考えてください。
まずはメモのCRUD機能の設計から始めます。

このように、最初に設計を固めてから実装に入ると、Claude Codeは、その設計に沿ったコードを、一貫して書きやすくなります。

CLAUDE.mdに設計方針を書く

#4で紹介したCLAUDE.mdに、設計方針を明記しておくのが効果的です。

## アーキテクチャ方針
Clean Architecture（3層構造）を採用する。

### 層の責務
- Presentation：UIとViewModelのみ。ビジネスロジックを書かない
- Domain：UseCase。Androidのクラスに依存しない
- Data：Repository実装・DataSource。外部との通信はここだけ

### 禁止事項
- ViewModelにFirestoreの直接参照を書かない
- Activityにビジネスロジックを書かない

この記述があると、Claude Codeは、その方針に沿ったコードを生成しやすくなります。