Claude CodeでFlutterアプリ開発、実際どうなの?
室谷今回はFlutter開発者の方に特に刺さる話をしようと思って。Claude CodeとFlutterの組み合わせ、MYUUUでもいくつかプロジェクトで試してみたんですよね。
テキトー教師ですよね。.AI(ドットエーアイ)コミュニティのメンバーさんからも「Flutter開発にClaude Code使ってみたいんだけど、実際どれくらい使えるの?」って声が最近すごく増えてます。
室谷結論から言うと、かなり使えます。ただ「何でもやってくれる」というよりは、「正しく使えば7〜8割の作業が自動化される」感覚です。
残りの2〜3割は人間が判断しながら動かす必要がある。
残りの2〜3割は人間が判断しながら動かす必要がある。
テキトー教師その「正しい使い方」がポイントですよね。何も考えずにClaude Codeに任せると、かえって手戻りが増えることもあるんですよ。
コミュニティのメンバーさんがよくハマるのがそこで、「Claude Codeに投げたら全然違うコードが出てきた」みたいな話をよく聞きます。
コミュニティのメンバーさんがよくハマるのがそこで、「Claude Codeに投げたら全然違うコードが出てきた」みたいな話をよく聞きます。
室谷CLAUDE.mdを最初に丁寧に書くかどうかで、結果が全然変わるんですよね。FlutterプロジェクトのCLAUDE.mdに何を書くかが、このガイドのメインテーマになります。
テキトー教師あとはDart特有の構文とか、Flutterのウィジェットツリーの複雑さとか、状態管理ライブラリの選択肢の多さとか、Flutterには「AIに任せると迷子になりやすいポイント」がいくつかあるんですよ。そのあたりも整理していきましょう。
室谷この記事では、プロジェクト設定から始まって、Riverpodを使った状態管理の自動生成、UIコンポーネント、テスト、App Storeの申請メタデータまで、一気通貫でカバーします。
FlutterとClaude Codeの相性

テキトー教師まずFlutterとClaude Codeの相性の話をしましょうか。Flutterって、他のフレームワークと比べてClaude Codeとの組み合わせはどうなんでしょう?
室谷相性は正直かなりいいと思います。理由がいくつあって、まずDartのコードはパターンが非常に明確なんですよ。
ウィジェットの構造とか、Riverpodのプロバイダーの書き方とか、「お作法」が固まってるから、Claude Codeが「次に書くべきコード」を予測しやすい。
ウィジェットの構造とか、Riverpodのプロバイダーの書き方とか、「お作法」が固まってるから、Claude Codeが「次に書くべきコード」を予測しやすい。
テキトー教師それは確かにそうですよね。Reactとかだと「どのスタイリングライブラリを使うか」「どの状態管理を使うか」が毎回変わったりしますけど、Flutterは「Riverpod + go_router」みたいに、ある程度デファクトが決まってきてるので、Claude Codeにとって学習コストが低い。
室谷あと海外の事例を見ると、Flutter開発者がClaude CodeでiOSアプリを29時間でリリースしたとか、2日でフルフィーチャーのアプリを作ったとか、そういう事例がかなり出てきてます。実際に試した人の体感として、開発速度が2〜3倍になるというのは誇張じゃないと思います。
テキトー教師ただし前提として、Flutter自体の基礎知識は必要ですよね。Claude Codeが生成したコードをレビューして「これでいいのか」を判断できる最低限の知識がないと、エラーが出たときに対処できない。
室谷そうそう。「Flutter初心者がClaude Codeだけで作れるか?」と言われると、かなり難しいんですよね。
「Flutter中級者がClaude Codeを使って上級者レベルの速度で開発できる」が正確な表現だと思います。
「Flutter中級者がClaude Codeを使って上級者レベルの速度で開発できる」が正確な表現だと思います。
FlutterとClaude Codeの組み合わせで何ができるか
テキトー教師具体的に何が自動化されるかを整理しましょうか。
室谷そうですね。大きく分けると5つのカテゴリになります。
| カテゴリ | Claude Codeに任せやすい内容 | 人間が判断すべき点 |
|---|---|---|
| 状態管理 | Riverpodのプロバイダー・AsyncNotifierのボイラープレート生成 | アーキテクチャの設計判断 |
| UIコンポーネント | ウィジェット実装、レスポンシブ対応 | デザインシステムとの整合性確認 |
| テスト | WidgetTest・ユニットテストの生成 | テスト戦略の優先順位付け |
| 設定ファイル | iOS/Androidのパーミッション設定、ビルドスクリプト | 証明書・署名周りの手動作業 |
| 多言語対応 | ARBファイルの生成・翻訳 | ローカリゼーションのニュアンス確認 |
テキトー教師この表を見ると「設計の判断はやっぱり人間がやる必要がある」というのが分かりますよね。Claude Codeは「実装の実行者」として非常に優秀なんですが、「何を作るべきか」という上位の判断は人間がしっかり持つ必要があります。
室谷ここが本質なんですよね。Claude Codeをうまく使えてる人って、必ず「設計の前提を固めてから実装を任せる」という流れを守ってます。
逆に「とりあえずClaude Codeに投げる」をやると、後で大量の修正が発生する・・・。
逆に「とりあえずClaude Codeに投げる」をやると、後で大量の修正が発生する・・・。
CLAUDE.mdの設計:FlutterプロジェクトのAI辞書を作る
室谷じゃあ実践的な話に入りましょう。最初のステップはCLAUDE.mdの作成です。
テキトー教師CLAUDE.mdは「Claude Codeに渡すプロジェクトのコンテキスト」ですよね。ここを丁寧に書くかどうかで、その後の出力の品質が全然変わります。
室谷Flutterプロジェクトの場合、最低限書くべき内容が4つあります。「技術スタック(使用ライブラリとバージョン)」「ディレクトリ構造」「コーディング規約」「テスト戦略」。
これを書かないで「何か作って」と言うと、Claude Codeが勝手に判断して、自分のプロジェクトとは違うライブラリを選んでくることがあります。
これを書かないで「何か作って」と言うと、Claude Codeが勝手に判断して、自分のプロジェクトとは違うライブラリを選んでくることがあります。
テキトー教師Flutterの場合は特に状態管理ライブラリが多いですよね。RiverpodかBlocかProviderか、プロジェクトによって違うので、そこは明示しないといけない。
室谷実際にMYUUUで使っているCLAUDE.mdをベースにした例を見てみましょう。
Flutterプロジェクト向けCLAUDE.md実例
# MyApp — CLAUDE.md
## 技術スタック
- Flutter 3.41 / Dart 3.11
- 状態管理: Riverpod 2.x(AsyncNotifierProvider パターン)
- ルーティング: go_router 13.x
- ネットワーク: dio + retrofit
- ローカルDB: Hive 4.x
- テスト: flutter_test + mocktail + integration_test
## ディレクトリ構造
lib/
├── features/ # Feature-first アーキテクチャ
│ └── {feature}/
│ ├── data/ # Repository / DataSource
│ ├── domain/ # UseCase / Entity
│ └── presentation/ # Page / ViewModel
├── core/ # 共通ユーティリティ
└── generated/ # Riverpod コード生成出力
## コーディング規約
- すべてのウィジェットは ConsumerWidget を継承
- 非同期処理は AsyncNotifierProvider を使用
- 画面遷移は Navigator.push 禁止 → go_router の context.go / context.push を使用
- 多言語対応: ARBファイルに日本語と英語の両方を必須で追加
## テスト戦略
- ビジネスロジック: ユニットテスト(80%以上のカバレッジ)
- UI: WidgetTest(重要パスのみ)
- E2E: integration_test(主要フロー5件以上)
テキトー教師ここで重要なのが「バージョン番号の明示」ですよね。「Riverpod 2.x」と書くだけで、Claude CodeがRiverpod 2系のAPIを使うようになります。
これを書かないと、古いバージョンのコードが出てくることがあります。
これを書かないと、古いバージョンのコードが出てくることがあります。
室谷あと「ルーティングは Navigator.push 禁止」みたいな制約も書いておくと効果的です。コーディング規約を自然言語で書いておくと、Claude Codeがその制約の中で実装してくれます。
テキトー教師ただ現実には「書いても守ってくれないことがある」というのもあって(笑)。CLAUDE.mdを書いたからといって100%そのとおりにやってくれるわけじゃないですよね。
室谷そうですね。生成されたコードは必ずレビューする習慣を持つ必要がある。
CLAUDE.mdは「方向付け」であって「保証」じゃないんですよね。
CLAUDE.mdは「方向付け」であって「保証」じゃないんですよね。
.claude/settings.jsonのFlutter向け設定
室谷CLAUDE.mdと合わせて、
.claude/settings.jsonの設定も重要です。
テキトー教師FlutterとDartのコマンドをClaude Codeに実行許可しておく設定ですよね。
{
"permissions": {
"allow": [
"Bash(flutter:*)",
"Bash(dart:*)",
"Bash(fvm:*)",
"Write(lib/**)",
"Write(test/**)",
"Write(integration_test/**)"
]
}
}
室谷flutterとdartコマンドを明示的に許可することで、コード生成後にClaude Codeが自動でflutter pub getやdart format、flutter testまで実行してくれるようになります。これが地味に大きくて、「コードを書く→ライブラリを取得する→フォーマットする→テストを走らせる」の一連の流れが全部自動化されます。
テキトー教師fvm:*も入ってるのがポイントですよね。FVM(Flutter Version Manager)を使ってFlutterのバージョン管理をしているプロジェクトなら、これも許可しておかないとバージョン切り替えができない。Riverpodの状態管理コードを自動生成する
室谷Flutterを使っていると、状態管理のボイラープレートコードを書くのが地味に大変なんですよ。Riverpodを使う場合、AsyncNotifierProviderのコードを書くのって、毎回同じパターンなのに結構な量になる。
テキトー教師ここはClaude Codeが本当に強い領域ですよね。「どんな状態管理が必要か」を自然言語で説明すると、プロジェクトの規約に沿ったコードを生成してくれます。
室谷例えばこういうプロンプトを使います。
WallpaperListNotifier を作成してください。
- AsyncNotifierProvider を使用
- WallpaperRepository を DI(依存性注入)で受け取る
- カーソルベースのページネーションに対応
- エラーハンドリング: NetworkException と ServerException を区別する
- お気に入りのトグル操作でオプティミスティックアップデートを実装
- 出力先: lib/features/wallpaper/presentation/wallpaper_list_notifier.dart
テキトー教師「オプティミスティックアップデート」まで含めて指定するのがポイントですよね。Claude Codeはそこまで指示しないと実装してくれないことが多い。
室谷そうなんですよ。「何を作るか」だけじゃなくて「どう動くべきか」まで書かないと、シンプルすぎる実装が出てくることがある。
生成されるコードの例
テキトー教師どんなコードが生成されるか、骨格だけ見てみましょうか。
// lib/features/wallpaper/presentation/wallpaper_list_notifier.dart
import 'package:riverpod_annotation/riverpod_annotation.dart';
import '../data/wallpaper_repository.dart';
import '../domain/wallpaper.dart';
part 'wallpaper_list_notifier.g.dart';
@riverpod
class WallpaperListNotifier extends _$WallpaperListNotifier {
@override
Future<List<Wallpaper>> build() async {
return _fetchPage(null);
}
Future<List<Wallpaper>> _fetchPage(String? cursor) async {
final repo = ref.read(wallpaperRepositoryProvider);
try {
return (await repo.fetchWallpapers(cursor: cursor)).items;
} on NetworkException catch (e) {
throw WallpaperNetworkError(message: e.message);
} on ServerException catch (e) {
throw WallpaperServerError(statusCode: e.statusCode);
}
}
// お気に入りのオプティミスティックアップデート
Future<void> toggleFavorite(String wallpaperId) async {
final previous = state;
state = AsyncData(
state.value!.map((w) =>
w.id == wallpaperId ? w.copyWith(isFavorite: !w.isFavorite) : w
).toList(),
);
try {
await ref.read(wallpaperRepositoryProvider).toggleFavorite(wallpaperId);
} catch (e) {
state = previous; // 失敗時は元に戻す
rethrow;
}
}
}
室谷このコードのポイントは、エラーが起きたらオプティミスティックアップデートを元に戻す処理まで含まれていること。こういうエラー処理の細かい部分って、自分で書くと意外と手間がかかる。
テキトー教師Riverpodを初めて使う人が「ここどう書くんだっけ?」って詰まるポイントを、丁寧にカバーしてくれますよね。受講生さんに「Riverpodの非同期処理の書き方」を教えるとき、このパターンをClaude Codeに生成させて見せるというのも、一つの教え方として面白いと思います。
室谷あとgo_routerの設定も自動生成できます。画面数が多いアプリだと、ルーティングの設定を書くのが地味に大変なので、ここも「画面一覧とそれぞれのパスを渡してgo_routerのルーティング設定を生成して」って指示するだけで、一気に作ってくれます。
UIコンポーネントをデザインシステムに沿って生成する
テキトー教師状態管理の次は、UIコンポーネントの話をしましょうか。Flutter開発でUIを作る部分って、意外と時間がかかりますよね。
室谷そうなんですよ。特にデザインシステムが決まっているプロジェクトだと、「このコンポーネントはこのカラーを使う」「このフォントサイズを使う」みたいなルールを守りながら実装するのが手間だったりする。
テキトー教師ここもCLAUDE.mdに「デザイントークン(カラーパレット・フォントサイズ・スペーシング)」を書いておくと、Claude Codeがそれに沿ったコードを生成してくれるようになりますよね。
室谷実際にやってみると、例えば「商品カードウィジェットを作って」と指示したとき、CLAUDE.mdにデザイントークンが書いてあると、そのトークンを使ったコードが出てきます。書いてない場合は、適当な色が入ってきたりするので、後でクリーンアップが大変になる。
レスポンシブレイアウトの自動実装
テキトー教師レスポンシブ対応はどうですか?Flutterって、タブレット対応とか、デスクトップアプリ対応をする場合、レスポンシブデザインが必要になりますよね。
室谷これが意外とClaude Codeが得意な領域なんですよね。「このウィジェットをモバイル・タブレット・デスクトップの3つのブレークポイントに対応させて」って言うと、
LayoutBuilderやMediaQueryを使った実装を生成してくれます。
テキトー教師ただ、出てきたコードをそのまま使えるかどうかは確認が必要ですよね。特にFlutterのウィジェットツリーは深くなりがちで、レスポンシブ対応を加えるとさらに複雑になるので、可読性が下がることがある。
室谷そこは「ウィジェットを小さく分割して、可読性を上げるようにリファクタしながら実装して」って最初から指示するとよくて。コードの品質まで指定してあげると、それに近い形で出てきます。
テキトー教師あとiOSとAndroidでUIが微妙に異なるところ、例えばナビゲーションバーのデザインとか、アプリバーのスタイルとか、プラットフォーム固有のUIパターンを使い分けるときも、「iOS向けはCupertinoウィジェットを使って、Android向けはMaterialウィジェットを使って」と指示すれば対応してくれますよ。
室谷そうですね。「Material 3のデザインガイドラインに沿った実装にして」って言うと、Flutterの最新のMaterial 3対応コンポーネントを使った実装が出てくる。
デザイン変更が特に強い
テキトー教師個人的に一番インパクトを感じるのが「デザインの雰囲気を変える」という操作ですよね。「もっと温かみのある雰囲気にして」とか「洗練されたダークテーマにして」と言うだけで、カラーパレット全体を変えてくれる。
室谷これは確かに強いですよね。デザイナーがいないプロジェクトで「なんとなくいい感じにしたい」というケースだと、かなり助かる。
ただ「細部までちゃんと指定したい」というケースは、Figmaのデザインファイルを参照させながら指示する方が精度が上がります。
ただ「細部までちゃんと指定したい」というケースは、Figmaのデザインファイルを参照させながら指示する方が精度が上がります。
テキトー教師Claude CodeとFigmaの連携って、最近話題になってますよね。
テストコードの自動生成:WidgetTestからE2Eまで

室谷テストの話も外せないですよね。Flutterのテスト、書くのは大事だと分かってるんですけど、プロジェクトが忙しくなると後回しになりがちで・・・。
テキトー教師あるあるですよね(笑)。講座でも「テスト書いてますか?」って聞くと、「書こうとは思ってるんですが...」って答える受講生さんが多くて。
室谷Claude Codeを使うと、実装コードと同時にテストも生成させることができるんですよ。「実装しながらWidgetTestも一緒に書いて」って指示するだけで、テストも一緒に出てきます。
テキトー教師ただ、正直に言うと「Claude Codeが生成するテストがそのまま動く」とは限らないですよね。テストコードって、実装の詳細に依存する部分が多いので、ちょっとしたズレでエラーになることが多い。
室谷そこは「flutter testを実行して、エラーがあれば修正して」っていうループをClaude Codeに回させるのが正解ですね。settings.jsonで
flutter testを許可しておけば、自分でテストを実行して修正まで自律的にやってくれます。WidgetTestの書き方をClaude Codeに任せる
テキトー教師WidgetTestの具体的な書き方、少し見てみましょうか。
室谷こういうプロンプトが効果的です。
LoginFormウィジェットのWidgetTestを書いてください。
テストケース:
- メールアドレスが空のままSubmitを押したとき、バリデーションエラーが表示される
- 正しいメールアドレスとパスワードを入力したとき、onLoginCallbackが呼ばれる
- ローディング中はSubmitボタンが非活性になる
モックには mocktail を使用。
テキトー教師テストケースを箇条書きで渡すのがいいですよね。「テスト書いて」だけだと、表面的なテストしか書いてくれないことがある。
室谷実際に生成されるコードはこんな感じです。
void main() {
group('LoginForm', () {
testWidgets('空のメールアドレスでSubmitを押すとバリデーションエラーが出る', (tester) async {
await tester.pumpWidget(
const MaterialApp(
home: Scaffold(body: LoginForm()),
),
);
await tester.tap(find.byType(ElevatedButton));
await tester.pump();
expect(find.text('メールアドレスを入力してください'), findsOneWidget);
});
testWidgets('正しい入力でonLoginCallbackが呼ばれる', (tester) async {
var callbackCalled = false;
await tester.pumpWidget(
MaterialApp(
home: Scaffold(
body: LoginForm(
onLogin: (email, password) {
callbackCalled = true;
},
),
),
),
);
await tester.enterText(
find.byKey(const Key('emailField')),
'test@example.com',
);
await tester.enterText(
find.byKey(const Key('passwordField')),
'password123',
);
await tester.tap(find.byType(ElevatedButton));
await tester.pump();
expect(callbackCalled, isTrue);
});
});
}
テキトー教師これ、ウィジェットのキー(
Key('emailField'))を使ってテストしてますね。逆に言うと、実装側にもキーを設定しておく必要があるので、「テストしやすい実装」を意識したウィジェット設計が大事になってきますよね。
室谷まさにそうで、「テスタブルなコードを書く」という意識を持ってCLAUDE.mdに書いておくと、最初からテストしやすい実装が出てきます。後からテストを追加しようとすると、ウィジェット側の修正が必要になることが多い。
iOS/Androidのプラットフォーム設定を自動化する
テキトー教師Flutterで地味に大変なのが、プラットフォーム固有の設定ファイルいじりですよね。iOSのInfo.plistとか、AndroidのAndroidManifest.xmlとか。
室谷ここも、Claude Codeに任せると楽になります。例えば「カメラ・マイク・位置情報のパーミッションを追加して」と言うだけで、iOSとAndroid両方の設定ファイルを修正してくれます。
テキトー教師ただ、Info.plistのパーミッション説明文(ユーザーに表示される「このアプリはカメラを使用します」のようなテキスト)は、App Storeの審査で引っかかりやすいところなので、生成された文章をそのまま使わずに日本語として自然かどうか確認した方がいいですよね。
室谷そうですね。英語のテンプレートをそのまま使うと、日本語アプリなのに英語の説明文が表示されることがあるので・・・。
「日本語ユーザー向けのアプリです。パーミッション説明文も日本語で書いて」と指定すると解決できます。
「日本語ユーザー向けのアプリです。パーミッション説明文も日本語で書いて」と指定すると解決できます。
ビルドスクリプトの自動生成
テキトー教師CI/CDの設定も、Claude Codeに頼む機会が増えてますよね。GitHub ActionsのFlutter向けワークフローとか。
室谷flutter build ios --releaseやflutter build apk --releaseを実行して、ビルド成果物をアップロードするGitHub Actionsのyamlファイルを「作って」と言うと、ちゃんとしたものが出てきます。
テキトー教師証明書周りは?iOSのビルドって、証明書の管理が一番めんどくさいじゃないですか。
室谷証明書とプロビジョニングプロファイルは、さすがにClaude Codeには限界があります。「fastlaneを使って証明書管理するスクリプトを作って」とか、「matchを使ったコード署名の設定を書いて」くらいはできますが、実際の証明書ファイルを扱う部分は手動でやる必要があります。
テキトー教師まあそこは自動化しない方が安全という考え方もありますよね。証明書の管理は一度間違えると、アプリが配信できなくなるリスクがあるので。
Flutterの多言語対応(ARBファイル)を自動生成する
室谷多言語対応の話もしておきましょう。日本のアプリでも英語対応が必要なケースって結構ありますよね。
テキトー教師そうですね。特にApp StoreやGoogle Playで海外展開を考えるなら、英語のストアページと英語のアプリUIは必須ですよね。
室谷FlutterのARB(Application Resource Bundle)ファイルを使った多言語対応、手でやると地味に大変なんですけど、Claude Codeに「日本語のARBファイルを見て、英語版を生成して」と言うと、一気に翻訳してくれます。
テキトー教師ただ、翻訳の品質は要確認ですよね。特に自社プロダクト固有の用語とか、アプリの文脈に合った表現かどうかは、ネイティブチェックが必要になることがある。
室谷そうですね。技術的な作業(ARBファイルの構造を作る、キーを生成する、機械的に翻訳する)はClaude Codeに任せて、ニュアンスのチェックだけ人間がやるという分業が現実的です。
テキトー教師あとRiverpodと多言語対応を組み合わせるとき、ロケールの変更をプロバイダーで管理する実装もClaude Codeに生成してもらえますよね。「ロケール設定をRiverpodのStateProviderで管理して、アプリ全体に反映させる実装を書いて」と言うと、対応したコードが出てきます。
Flutter開発の進め方:探索・計画・実装の3ステップ

室谷ちょっと俯瞰した話をしましょうか。Claude Codeのドキュメントにも書いてある「探索→計画→実装」のフロー、Flutterでも基本的な考え方はそのまま当てはまります。
テキトー教師「とりあえずコードを書いて」ではなくて、まず「探索」から始めるんですよね。
室谷そうです。具体的には、Claude CodeのPlan Modeで「このプロジェクトの現在の状態を理解して。
状態管理はどうなってる?ルーティングは?」みたいな質問をして、まずClaude Codeにコードベースを理解させる。
状態管理はどうなってる?ルーティングは?」みたいな質問をして、まずClaude Codeにコードベースを理解させる。
テキトー教師既存のプロジェクトに機能を追加するときは、特にこのステップが大事ですよね。いきなり「この機能を追加して」と言うと、既存のアーキテクチャと噛み合わないコードが出てくることがある。
室谷次に「計画」です。「こういう機能を追加したい。
どのファイルを変更する必要がある?実装プランを立てて」と聞くと、Claude Codeが修正が必要なファイルと変更内容を整理してくれます。
どのファイルを変更する必要がある?実装プランを立てて」と聞くと、Claude Codeが修正が必要なファイルと変更内容を整理してくれます。
テキトー教師この段階で「この計画でいいか?」を確認できるのが大きいですよね。コードを書き始めてから「方向性が違った」となると、巻き戻すのが大変なので。
室谷計画を確認したら、最後に「実装」。「さっきの計画通りに実装して。
変更のたびにflutter testを実行して、テストが全部通ることを確認しながら進めて」という指示を出すと、テストを回しながら自律的に実装してくれます。
変更のたびにflutter testを実行して、テストが全部通ることを確認しながら進めて」という指示を出すと、テストを回しながら自律的に実装してくれます。
コンテキストウィンドウの管理
テキトー教師長い開発セッションでのコンテキスト管理も大事ですよね。Claude Codeのドキュメントでも「コンテキストウィンドウが埋まるにつれてパフォーマンスが落ちる」と書かれてますよね。
室谷Flutterプロジェクトって、ファイル数が多くなりがちなんですよ。特にfeature-firstアーキテクチャを採用すると、小さなファイルが大量にできるので、Claude Codeが全部読み込むとコンテキストがすぐ埋まる・・・。
テキトー教師対策としては、一度に大きなタスクをやらせるんじゃなくて、タスクを小さく分割して「1つのfeatureを実装する」という単位で新しい会話を始めるのが良いですよね。
室谷そうですね。「この会話でやること」を最初に明確にしておいて、スコープを絞ることが大事です。
あとは
あとは
/compactコマンドで会話を要約してコンテキストを節約するという手もありますよ。App Store申請の準備もClaude Codeで
テキトー教師ここは個人的にあまり知られていないと思うんですけど、App Storeの申請メタデータ(アプリ説明文・キーワード・スクリーンショットのキャプションなど)もClaude Codeに生成してもらえますよね。
室谷ASO(App Store Optimization)向けのメタデータ生成ですね。「このアプリのコードベースを読み込んで、App Store掲載用の日本語・英語の説明文とキーワードを生成して」と言うと、コードを理解した上で説明文を書いてくれます。
テキトー教師これ、かなり便利ですよね。アプリの全機能を把握した上でキャッチコピーを書いてくれるので、自分でゼロから書くより精度が高い場合がある。
室谷ただ、最終的なASOのキーワード選定は、実際の検索ボリュームデータを使って判断する必要があります。Claude Codeはキーワードの候補を出してくれますが、そのキーワードが実際に検索されているかどうかは別途確認が必要です。
テキトー教師なるほど。「アイデアを出してもらう」という使い方は正しいけど、最終判断は人間がするということですね。
室谷あとPlayStore(Google Play)とApp Storeでは最適なメタデータが微妙に違うので、「App Store向け」「Google Play向け」と指定して別々に生成してもらうのがおすすめです。
よくある質問
テキトー教師ここまでかなり実践的な内容をカバーしてきましたが、よくある質問を整理しましょうか。.AIのメンバーからよく聞かれる疑問があって。
室谷いいですね。どんな質問が多いですか?
テキトー教師まず「Claude Codeはどのプランで使えばFlutter開発に十分ですか?」というのがよく来ます。
室谷Proプランから十分使えますが、Flutter開発のような大きなプロジェクトで本気でやるなら、Max 5xが現実的ですね。Flutterって1つの機能を実装するだけで、複数のファイルを読んで複数のファイルを書くので、トークンの消費量が多めです。
テキトー教師「生成されたコードの品質はどれくらいですか?」という質問も多いです。
室谷「そのまま本番に使えるか?」というと、90%の確率でレビューが必要です。パターンに沿ったコードは非常に高品質ですが、プロジェクト固有のビジネスロジックが絡んでくると、意図を正確に反映しているかの確認が必要になります。
テキトー教師「FlutterのCodexとの比較は?」という質問もよく来ますね。
室谷Codexも試しましたが、2026年時点でFlutterのエコシステムへの理解という意味では、Claude Codeの方が精度が高い印象です。Dartの独特な構文やFlutter特有のパターンへの理解度が違う感じがします。
まとめ
室谷じゃあまとめましょうか。Claude CodeとFlutterの組み合わせ、かなり実用的です。
テキトー教師整理すると、こういう使い方が特に効果的でしたね。
- CLAUDE.mdに技術スタック・ディレクトリ構造・コーディング規約・テスト戦略を書く
- settings.jsonで
flutter:*とdart:*コマンドを許可する - 状態管理のボイラープレート(Riverpod AsyncNotifierProvider)は丸ごと任せる
- UIコンポーネントはデザイントークンをCLAUDE.mdに書いてから生成させる
- テストは「実装と同時に書かせる」のが最も効率的
- 探索→計画→実装の順で進める
室谷何より「設計の判断は自分がする」という意識を持って、Claude Codeを「実装の実行者」として使うのが正解だと思います。設計まで任せようとすると、後でアーキテクチャの修正が大変になる。
テキトー教師Flutter自体の学習も大事で、「Claude Codeが生成したコードを理解できる力」がないと、エラーが出たときに対処できません。Claude Codeはあくまでも「Flutter開発を加速するツール」であって、「Flutterの知識を代替するもの」ではないですよね。
室谷そこが一番大事なポイントかもしれないですね。Claude Codeで開発速度は確実に上がりますが、Flutterエンジニアとしての力は引き続き磨いていく必要がある。
MYUUUでもそこのバランスは意識してます。
MYUUUでもそこのバランスは意識してます。
テキトー教師.AIのコミュニティでも「Claude Codeを使いながらFlutterを学ぶ」という使い方をしているメンバーさんが増えてきていて、学習ツールとしても面白い使い方だと思います。Claude Codeが生成したコードを「なぜこう書いてるんだろう?」と読み解くことで、Dartのパターンをよく理解できるという声もありますよ。
室谷それは確かにいい使い方ですね。ということで、今回はClaude CodeとFlutterの組み合わせを詳しく見てきました。
実際に手を動かして試してみると、ここで話した以上の発見があると思います。
実際に手を動かして試してみると、ここで話した以上の発見があると思います。
