【Claude Code 失敗談 #9】Claude Codeに設計を丸投げしたらアーキテクチャがグチャグチャになった話

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

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

#9：Claude Codeに設計を丸投げしたらアーキテクチャがグチャグチャになった話 ← 今回

はじめに

「設計はClaude Codeがやってくれるから考えなくていい」と思っていた時期がありました。
その結果、半年後にコードを見返すと誰も触れないスパゲッティになっていました。

やらかしたこと

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

数ヶ月後、新しい機能を追加しようとClaude Codeに見せると：

このコードは複数の責務が混在しており、修正が困難な状態になっています。
リファクタリングをお勧めします。

という返答。Claude Code自身に「このコードは複雑すぎる」と言われました。

何が起きていたか

指示に設計方針を含めなかったため：

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

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

設計は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は常にこの方針に沿ったコードを生成してくれます。