【第4回】アーキテクチャ選定をClaude Codeに相談する｜決め方と整理の仕方

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

前回の記事では、Claude Codeを壁打ち相手にしながら、DB設計を整理する方法を紹介しました。

今回のテーマは、

「アーキテクチャ選定」

です。

アーキテクチャは、開発の土台となる設計方針です。
最初の選択が、その後の開発全体に影響します。

しかし、

選択肢が多くて何を選べばいいかわからない
メリット・デメリットを比較する情報が散らばっている
正解がひとつではないので判断しにくい

という悩みを持つ人は多いと思います。

Claude Codeを使って、アーキテクチャ選定の思考を整理する方法を実例で解説します。

アーキテクチャ選定が難しい理由

アーキテクチャ選定が難しいのは、

「どれが正解か、やってみないとわからない」

という性質があるからです。

プロジェクトの規模・チーム構成・開発期間・将来的な拡張性、これらすべてが選択に影響します。

つまり、

「このプロジェクトにとって何が適切か」

を判断するのは、最終的には自分自身です。

Claude Codeの役割は、その判断を助けることです。

Claude Codeに「決めてもらう」のではない

ここで重要なことを整理しておきます。

アーキテクチャ選定において、Claude Codeは

「選択肢と判断軸を整理してくれる存在」

であって、

「答えを出してくれる存在」

ではありません。

「どれがいいですか？」と聞けば、何かしら回答は返ってきます。
しかしそれは、あなたのプロジェクトの文脈を完全に理解した上での答えとは限りません。

Claude Codeを使って思考を整理し、最終的な判断は自分で行うという姿勢が重要です。

実例：新規アプリのアーキテクチャを選定する

ここでは、個人開発でメモアプリを新規に作る場面を例にします。

開発者のプロフィールはこうです。

- Kotlinの基本は理解している
- Jetpack Composeは使ったことがある
- Clean Architectureは名前を聞いたことがある程度
- 一人で開発する予定
- 将来的にFirebaseと連携したい

ステップ1：前提条件を整理して伝える

まず、自分のプロジェクトの状況をClaude Codeに伝えます。

【質問例】
Androidアプリを個人開発します。
アーキテクチャの選定について相談したいです。

【状況】
- 言語：Kotlin
- UI：Jetpack Compose
- 規模：個人開発・小〜中規模
- スキル：Kotlin基本は理解済み、Clean Architectureは未経験
- 将来：FirebaseのAuthやFirestoreと連携予定

候補として、以下を考えています。
- MVVMのみ（シンプル構成）
- MVVM + Repository
- Clean Architecture（UseCase層あり）

それぞれの特徴と、このプロジェクトへの向き・不向きを教えてください。

候補をあらかじめ提示することで、回答の焦点が絞られます。

ステップ2：選択肢を比較してもらう

Claude Codeが以下のような比較を返してくれます。

【比較例】

■ MVVMのみ（シンプル構成）
特徴：
- ViewとViewModelだけで構成するシンプルな設計
- 学習コストが低い

向いている点：
- 小規模・短期のプロジェクト
- 素早く動くものを作りたい場合

向いていない点：
- 機能が増えるとViewModelの責務が肥大化しやすい
- テストが書きにくくなる場合がある

■ MVVM + Repository
特徴：
- データの取得・保存をRepositoryに分離する構成
- GoogleのAndroid推奨アーキテクチャに沿っている

向いている点：
- FirebaseやAPIとの連携がある場合
- 将来的な機能拡張を見据えている場合

向いていない点：
- MVVMのみと比べると構成が複雑になる

■ Clean Architecture（UseCase層あり）
特徴：
- Presentation・Domain・Dataの3層に明確に分離する構成
- 各層の責務が明確で、テストが書きやすい

向いている点：
- 中〜大規模プロジェクト
- チーム開発・長期メンテナンスが必要な場合

向いていない点：
- 個人開発・小規模では過剰になることがある
- 学習コストが高い

この比較を読みながら、自分のプロジェクトにどれが合うかを考えます。

ステップ3：判断に迷う点を深掘りする

比較を読んで迷う部分が出てきたら、その点をさらに質問します。

【質問例】
MVVM + Repositoryを選んだ場合、
将来的にClean Architectureへ移行することは難しいですか？
段階的に移行する方法があれば教えてください。

【質問例】
個人開発でFirebaseを使う場合、
MVVM + RepositoryとClean Architectureの
どちらを選んでいる開発者が多いですか？
一般的な傾向を教えてください。

「今の判断」だけでなく、「将来の拡張性」も考慮することで、より納得感のある選択ができます。

ステップ4：選んだ理由を言語化する

選択肢が絞れてきたら、選んだ理由をClaude Codeに整理してもらいます。

【質問例】
今回のプロジェクトでは「MVVM + Repository」を選ぶことにしました。
選定理由を以下の観点で整理してください。

- なぜこの構成を選んだのか
- どんなメリットを期待しているか
- 考えられるリスクと対策

Claude Codeが返す整理例です。

【選定理由の整理例】

■ 選定：MVVM + Repository

■ 選んだ理由
- Googleの推奨アーキテクチャに沿っており、公式ドキュメントが充実している
- Firebaseとの連携をRepository層に閉じ込めることができる
- Clean Architectureと比べて学習コストが低く、一人で進めやすい

■ 期待するメリット
- データ取得の処理をViewModelから分離できる
- 将来的にFirestoreからAPIへの切り替えが容易になる
- テストコードが書きやすくなる

■ 考えられるリスクと対策
- ビジネスロジックが複雑になった場合、ViewModelが肥大化するリスクがある
  → 複雑になった時点でUseCase層を追加することを検討する

選定理由を言語化しておくことで、後から「なぜこう設計したのか」を振り返れます。

ステップ5：構成の全体像を整理してもらう

選定が決まったら、具体的なフォルダ構成や各層の責務を整理してもらいます。

【質問例】
MVVM + Repositoryで開発を始めます。
推奨するフォルダ構成と、各層の責務を教えてください。

Claude Codeが返す構成例です。

【フォルダ構成例】

app/
├── ui/
│   ├── screen/        # Composable（画面）
│   └── viewmodel/     # ViewModel
├── repository/        # Repository（インターフェースと実装）
├── data/
│   ├── local/         # Room（ローカルDB）
│   └── remote/        # Firebase・API通信
└── model/             # データクラス

【各層の責務】
- ui/screen：画面の表示・ユーザー操作の受け取り
- ui/viewmodel：UIの状態管理・Repositoryの呼び出し
- repository：データの取得・保存の抽象化
- data/local：Roomを使ったローカルデータの操作
- data/remote：FirebaseやAPIとの通信
- model：アプリ全体で使うデータクラス

この構成をベースに開発を進めることで、「どこに何を書くか」の迷いが減ります。