結論：Claude Codeはモバイルアプリ開発でも、画面コンポーネントの実装・状態管理・API連携・プラットフォーム差異の吸収・テスト生成という一連の工程を加速できます。鍵は「仕様を分解して渡す」「CLAUDE.mdにプロジェクト規約を書く」「生成コードは必ず実機/シミュレータで動作確認して人がレビューする」の3点です。
- 要点1：仕様を画面・状態・通信の単位に分解し、1指示=1責務でClaude Codeに渡すと精度が上がる
- 要点2：CLAUDE.mdに言語・アーキテクチャ・命名規約を書くと、生成コードのブレが減る
- 要点3：iOS/Androidの差異・権限・通知は「どのフレームワークの何バージョンか」を明示して指示する
対象読者：iOS（Swift/SwiftUI）・Android（Kotlin/Jetpack Compose）・Flutter・React Nativeのいずれかでアプリを開発しているエンジニア。
今日できること：自分のプロジェクトのCLAUDE.mdを5分で書き、まず1画面の実装をClaude Codeに任せてみる。
モバイルアプリ開発は、Webと比べて「動作確認の手数」が多いのが正直しんどいところです。シミュレータを起動して、ビルドして、画面遷移を辿って、権限ダイアログを許可して……という往復が積み重なる。だからこそ、画面の雛形やボイラープレートをAIに任せて、自分は設計と確認に集中できると効きます。
この記事では、筆者が実際にClaude Codeをモバイル開発で使ってきたなかで「これは効く」と感じたワークフローを、フレームワーク横断で整理します。2026年6月時点のClaude Codeの挙動・公式ドキュメントを前提にしていますが、各モバイルフレームワーク固有の挙動はバージョンで変わるため、断定せず「自分の環境で確認する」前提で読んでください。
なぜモバイル開発でClaude Codeが効くのか
Claude Codeはターミナルで動くエージェント型のコーディングツールで、リポジトリ全体を読み、ファイルを編集し、ビルドやテストのコマンドを実行できます（公式Overview参照）。モバイルプロジェクトに対しては、次のような場面で手数を減らせます。
- 定型コードの生成：画面コンポーネント、データモデル、API通信レイヤーなど、書けば動くが書くのが面倒な部分
- 横断的な変更：「全画面のローディング表示を共通コンポーネントに差し替える」のような、複数ファイルにまたがる作業
- 既存コードの読解：引き継いだ巨大なViewControllerやWidgetツリーを要約させ、どこをどう触ればいいか当たりをつける
- テストの雛形生成：ロジック部分のユニットテスト、UIテストの骨組み
逆に「実機でのレイアウト崩れ」「特定端末でだけ落ちるクラッシュ」のような、実行しないと分からない問題はAIだけでは閉じません。ここは人間が実機で確認する前提を最初から組み込んでおくのが大事です。
前提：CLAUDE.mdにプロジェクト規約を書く
モバイル開発でClaude Codeの出力品質を一番左右するのが、プロジェクトルートに置くCLAUDE.mdです。これはClaude Codeがセッション開始時に自動で読み込むプロジェクトメモリで、言語・アーキテクチャ・命名規約・禁止事項などを書いておくと、毎回の指示に書かなくても反映されます（Memory公式ドキュメント）。
モバイルプロジェクトのCLAUDE.mdに書いておくと効くのは、次のような項目です。手順は以下の順で埋めていきます。
- 言語とフレームワーク、そのメジャーバージョン（例：Swift 6 / SwiftUI、Kotlin / Jetpack Compose、Flutter 3系、React Native + TypeScript）
- 採用アーキテクチャ（MVVM、Redux系、Clean Architectureなど）とレイヤーの責務
- 状態管理ライブラリと、それを使う際の決まりごと
- 命名規約・ディレクトリ構成・1ファイルの責務範囲
- 動作確認の手順（どのコマンドでビルド・テストするか）と、やってほしくないこと（例：勝手に依存を追加しない）
例として、React Native（TypeScript）プロジェクトのCLAUDE.mdは次のように書けます。
# プロジェクト規約
## 技術スタック
- React Native + TypeScript（strictモード）
- 状態管理: Zustand（Reduxは使わない）
- ナビゲーション: React Navigation v6
- API通信: 既存の src/api/client.ts を必ず経由する
## コーディング規約
- 画面コンポーネントは src/screens/ に1画面1ファイル
- 再利用コンポーネントは src/components/ に置く
- 関数コンポーネント + Hooksのみ。クラスコンポーネント禁止
- 型は any 禁止。不明な場合は unknown + 型ガード
## 動作確認
- 変更後は `npm run typecheck` と `npm test` を実行する
- 依存パッケージの追加は提案だけして、勝手に install しない
「Reduxは使わない」「anyは禁止」のようにやってほしくないことを明示するのがコツです。CLAUDE.mdの設計を深掘りしたい場合はCLAUDE.md設計・運用ガイドにまとめています。
①画面・UIの実装（仕様→画面コンポーネント）
まず効果を実感しやすいのが、画面の実装です。ポイントは「画面を文章で全部説明しようとしない」こと。要素・配置・状態（ローディング/エラー/空）を箇条書きで渡すと、構造が安定します。
SwiftUIで商品一覧画面を実装させる場合の指示例です。
商品一覧画面 ProductListView を SwiftUI で作って。
要件:
- ナビゲーションタイトルは「商品一覧」
- 商品は ProductRow（画像・商品名・価格）の縦リスト
- 状態は loading / loaded([Product]) / empty / error の4つ
- loading 中は ProgressView を中央表示
- empty は「商品がありません」を中央表示
- error は再試行ボタン付きのメッセージ
- ViewModel は @MainActor の ProductListViewModel として分離し、
状態を @Published var state: ViewState で公開する
データ取得処理は仮実装でよい（API連携は後で差し替える）。
このように状態を列挙して渡すと、AIが「正常系しか作らない」事故を防げます。生成されたコードは必ずシミュレータでビルドし、各状態（特にerror・empty）が意図通り表示されるかを目視で確認してください。Claudeが生成したプレビュー用のダミーデータが現実のAPIレスポンスと食い違うことはよくあります。
Webフロントエンドでも同じ考え方が使えます。React/Next.jsでの画面実装の進め方は爆速フロント開発ガイドに詳しく書いています。コンポーネント分割の指示の出し方はモバイルとも共通点が多いので参考になります。
レイアウト調整は「差分」で頼む
レイアウトの微調整は、画面全体を作り直させるより「この部分だけ」と差分で頼むほうが速いです。たとえば「ProductRowの価格を右寄せにして、画像は角丸8ptにして」のように、変更箇所を限定して指示します。Claude Codeはリポジトリ内の既存ファイルを読んで該当箇所だけを編集できるので、無関係な部分を巻き込みにくくなります。
②状態管理・画面遷移（ナビゲーション）
状態管理は、CLAUDE.mdで決めたライブラリに沿わせるのが肝心です。指示の中で「Zustandのストアとして」「Riverpodのproviderとして」と明示しないと、AIが別のパターン（useStateの乱立など）で書いてしまうことがあります。
Flutter（Riverpod）でカート状態を管理させる指示例です。
カート機能の状態管理を Riverpod で実装して。
- CartItem（productId, name, price, quantity）のリストを持つ
- StateNotifierProvider として cartProvider を定義
- 操作: addItem / removeItem / updateQuantity / clear
- 合計金額は派生プロバイダ cartTotalProvider で算出
- 既存の lib/features/cart/ 配下に置く
UI からは ref.watch(cartProvider) で購読する前提で、
今回はロジックとプロバイダ定義だけでよい。
画面遷移は、ナビゲーションの構成を先に伝えるとブレません。「タブが3つ、各タブがスタックを持つ」「カート画面はモーダルで出す」のような構造を渡してから、個別の遷移を依頼します。React Navigationなら型付きのルートパラメータ定義まで一緒に頼むと、後の保守が楽になります。
React Navigation の型定義を整備して。
- RootStackParamList を定義
- 画面: Home / ProductDetail(productId: string) / Cart
- ProductDetail へ遷移するときは productId 必須
- useNavigation / useRoute を型付きで使えるよう
カスタムフック useAppNavigation を作る
遷移まわりは実際にタップして辿らないと分からないバグ（戻る挙動、ディープリンク）が出やすいところです。生成後は必ず実機/シミュレータで一連の動線を手で確認してください。
③API連携・データ永続化（通信・ローカルDB）
API連携は「既存の通信レイヤーを経由させる」のが事故防止の基本です。CLAUDE.mdに「通信は必ずApiClientを経由」と書いておけば、AIが各画面で直接fetchやURLSessionを叩く事態を避けられます。
Kotlin（Retrofit + Coroutines）でAPIサービスとリポジトリを実装させる指示例です。
商品APIの通信レイヤーを実装して。
- Retrofit インターフェース ProductApi に
GET /products と GET /products/{id} を定義
- レスポンスは data class ProductDto（既存の命名規約に合わせる）
- ProductRepository で DTO -> ドメインモデル Product に変換
- 通信は suspend 関数、エラーは Result で返す
- 既存の NetworkModule（Hilt）に ProductApi の provider を追加
APIのベースURLは BuildConfig 経由で、ハードコードしない。
データ永続化（ローカルDB）も、まずスキーマとアクセス方法を文章で固めてから実装を頼みます。SwiftならSwiftData/Core Data、AndroidならRoom、FlutterならdriftやsqfliteなどフレームワークごとにDB層が違うので、「どのライブラリで」を必ず明示してください。バージョン依存で書き方が変わるため、「Room 2.6系で」のようにメジャーバージョンも添えると安全です。
注意点として、AIはマイグレーション（スキーマ変更時の移行処理）を省略しがちです。「スキーマを変えたらマイグレーション方針もコメントで示して」と一言加えておくと、本番でデータが飛ぶ事故を減らせます。生成されたDBコードは、実機で「初回起動・データ追加・再起動後の読み出し」を必ず確認しましょう。
④プラットフォーム差異・権限・通知の対応
iOS/Androidの差異は、AIが最も間違えやすい領域です。理由はシンプルで、フレームワークやOSのバージョンによってAPIや必要な設定が変わるから。ここでは「どのフレームワークの何バージョンで、iOS/Androidそれぞれどうするか」を明示して指示するのが鉄則です。
権限まわりの指示例（React Native）です。
カメラ権限のリクエスト処理を実装して。
- ライブラリは react-native-permissions を使う前提
- iOS: Info.plist の NSCameraUsageDescription の要否をコメントで明示
- Android: AndroidManifest の CAMERA permission と、
実行時権限リクエストの両方を扱う
- 権限が拒否された場合は設定画面へ誘導するダイアログを出す
- 権限状態は granted / denied / blocked で分岐
各プラットフォームの設定ファイルに必要な記述は、
コードではなくコメントで「ここに何を追記するか」を示して。
プッシュ通知やバックグラウンド処理も同様に、プラットフォームごとに設定が分かれます。AIが生成したコードをそのまま信じず、Apple/Googleの公式ドキュメントで必要な設定（証明書、エンタイトルメント、Manifest宣言など）を裏取りしてください。ここはAIの知識が古い・不正確なことが多い前提で扱うのが安全です。
よくある失敗パターン
- ❌ 「カメラ権限を実装して」だけ渡す → ⭕ ライブラリ名・iOS/Android双方の設定・拒否時の挙動まで列挙する
- ❌ 生成された通知コードをレビューなしで本番投入 → ⭕ 証明書・トークン登録まわりは公式ドキュメントで照合する
- ❌ 「最新のやり方で」と曖昧に頼む → ⭕ 「このフレームワークのこのバージョンで」とバージョンを固定する
- ❌ シミュレータだけで確認して終わり → ⭕ 権限・通知・カメラは挙動が異なるため必ず実機で確認する
⑤テスト・既存コードのリファクタ
ロジック部分のユニットテストは、Claude Codeに任せやすい領域です。「このViewModelのテストを書いて」と頼むと、正常系・異常系・境界値をまとめて出してくれます。ただしテストの観点（何を保証したいか）は人間が決めるべきなので、観点を箇条書きで渡すと質が上がります。
CartViewModel のユニットテストを書いて。
検証したい観点:
- 空のカートに addItem すると件数が1になる
- 同じ商品を2回 addItem すると quantity が2になる（重複追加しない）
- removeItem で対象だけ消える
- 合計金額が price × quantity の総和と一致する
- clear で空になる
テストフレームワークは既存のものに合わせて、
モックが必要なら最小限で。
テスト戦略を体系的に組みたい場合はClaude Code実践テクニック完全ガイドでテスト生成・TDDの章を参照してください。学習順がまとまっているので、テスト自動化の前後関係を整理できます。
既存コードのリファクタは、いきなり「全部きれいにして」と頼まないこと。まず読解させ、方針を立ててから、小さく刻んで適用します。
- 対象ファイルを読ませて「現状の責務と問題点を要約して」と頼む
- 「MVVMに分離するなら、どう切るか方針を提案して」と設計だけ先に出させる
- 方針に合意したら「まずViewModelの抽出だけ実施して」と1ステップずつ適用
- 各ステップ後にビルド・テストを通し、差分をレビューしてから次へ進む
大規模な巨大ファイルを一気に書き換えると、レビューしきれず壊れた箇所を見逃します。Plan Modeで方針を確定させてから実装に移ると安全です。
実機確認とレビューは省略しない
ここまで一貫して書いてきた通り、Claude Codeが生成したモバイルアプリのコードは必ず実機/シミュレータで動作確認し、人間がレビューするのが前提です。これはモバイルならではの理由があります。
- レイアウトは画面サイズ・OSバージョンで崩れる。コードを読むだけでは分からない
- 権限・通知・カメラなどは実機でしか正確に再現できない
- フレームワーク/OSのバージョン差異で、AIの知識が古いと動かないコードを出すことがある
- パフォーマンス（スクロールのカクつき、メモリ）は実行して初めて見える
Claude Codeは「実装の手数を減らす」ためのツールであって、「確認を省く」ためのものではありません。むしろ実装が速くなるぶん、確認とレビューに時間を回せるようになる、というのが正しい使い方です。Anthropicのベストプラクティスでも、AIの出力を検証する人間のループを重視しています（Claude Code Best Practices）。
モバイル開発でClaude Codeを使う際のチェックリスト
最後に、今日から使える実践チェックリストです。
- CLAUDE.mdに言語・バージョン・アーキテクチャ・状態管理・禁止事項を書いたか
- 仕様を画面・状態・通信の単位に分解して渡したか
- 状態（loading/empty/error）を列挙して指示したか
- API通信は既存の通信レイヤー経由を指定したか
- 権限・通知は「フレームワーク名＋バージョン＋iOS/Android双方」を明示したか
- リファクタはPlan Modeで方針を固めてから小さく適用したか
- 生成コードを実機/シミュレータで動かし、人がレビューしたか
この7項目を回すだけで、モバイル開発の体感速度はかなり変わります。まずは自分のプロジェクトのCLAUDE.mdを書くところから始めてみてください。
まとめ
Claude Codeはモバイルアプリ開発の各工程──画面実装、状態管理・遷移、API連携・永続化、プラットフォーム差異・権限・通知、テスト・リファクタ──を加速できます。効かせる鍵は「仕様を分解して渡す」「CLAUDE.mdに規約を書く」「実機確認とレビューを省かない」の3点。特にプラットフォーム差異まわりはAIが間違えやすいので、バージョンを固定し、公式ドキュメントで裏取りする習慣をつけてください。2026年6月時点の前提で書いていますが、各フレームワークの挙動はバージョンで変わるため、最終的には自分の環境で確認するのが一番確実です。
