AIコーディングエージェント前提でのスマホアプリ開発：ネイティブ vs クロスプラットフォーム

はじめに

AIコーディングエージェントが開発の主力になりつつある今、スマホアプリのフレームワーク選定にも新たな評価軸が必要です。本記事では、ネイティブ（Swift/Kotlin）・Flutter・React Nativeの3択を「AIエージェントがどれだけ正確に、自律的にコードを書けるか」という観点で比較します。特に、クロスプラットフォームとネイティブの境界にあるハイブリッド実装が、AIにどのような影響を与えるかを掘り下げます。

2026年3月時点の情報をもとに構成しています。引用元はインライン注記として記載しています。

1. 前提

本記事では、Claude Code・GitHub Copilot・Cursor・Windsurf などのAIコーディングエージェントを開発の主力として使うことを前提にします。単なるコード補完ではなく、要件を伝えると自律的にファイルの作成・編集・テスト実行まで回す、エージェント的な利用を想定しています。

この前提では、「AIエージェントがそのコードをどれだけ正確に、自律的に書けるか」が重要な評価軸になります。そして現実のアプリ開発では、クロスプラットフォームのコードだけでは完結せず、ネイティブ実装との組み合わせが必要になる場面が多くあります。このハイブリッド構成がAIエージェントにどう影響するかが、今回の核心です。

2. 2026年、何が変わったか

React Native：New Architectureへの一本化

React Native v0.76（2024年10月）でNew Architecture（JSI/Fabric/TurboModules）がデフォルトになり、v0.82（2025年10月）では旧アーキテクチャへのopt-outが無効化されました。さらにv0.84（2026年2月）ではHermes V1がデフォルトJSエンジンとなり、iOSでは旧アーキテクチャのコードがビルドからデフォルトで除外される段階まで進みました。

「Starting from React Native 0.76, the New Architecture is enabled by default in your projects.」
— React Native公式ブログ — React Native 0.76（2024年10月）

「we're confident in making it the only architecture for this and future versions of React Native」
— React Native公式ブログ — React Native 0.82: A New Era（2025年10月）

Flutter：Dart公式MCPサーバーの登場

Dart SDK 3.9（2025年8月、参考：Announcing Dart 3.9）以降で、Dart公式Model Context Protocol（MCP）サーバーが安定チャネルに追加されました。Claude Code・Cursor・GitHub Copilot・Gemini CLIなどと直接統合できるようになり、AIエージェントがウィジェットツリーの解析、アナライザー実行、テスト、pub.dev検索、依存管理を自律的に扱える点は、2026年時点のFlutterの強みです。ただし、公式ドキュメントでは「experimental and likely to evolve quickly」と明記されているため、運用ではAPIや挙動の変化を見込んでおく必要があります。

Claude Codeとの連携は以下のコマンド1行で設定できます。

claude mcp add --transport stdio dart -- dart mcp-server

参考：Dart and Flutter MCP server — Flutter公式ドキュメント（2026年3月25日更新）

React Native：Expo UIとエージェントスキルの台頭

React Native側でも2つの重要な動きがあります。ひとつはExpo UI（Expo SDK 55、2026年2月）です。SwiftUIとJetpack ComposeのネイティブコンポーネントをReact Nativeから利用できる方向が見えてきており、「クロスプラットフォーム vs ネイティブ」の境界が従来より曖昧になりつつあります。

ただし、Expo UIはまだ発展途上です。Expoの説明でもJetpack Compose側とSwiftUI側の成熟度には差があり、採用時は安定性とAPI変更リスクを個別に確認した方が安全です。現時点では「すでに枯れた解決策」というより、「ネイティブUIの再利用を前進させる有望な仕組み」と捉えるのが妥当です。

もうひとつはCallstackのagent-skills（2026年1月）です。React Native最適化のベストプラクティスをClaude Code・Cursor・Codex等のAIエージェントが直接参照できるスキルセットとして公開しました。MCPサーバーほどの深い統合ではありませんが、パフォーマンス最適化、リスト実装、バンドルサイズ削減などの知見をエージェントが参照しやすくする仕組みです。

参考：Expo SDK 55 Changelog（2026年2月）
参考：Callstack — Announcing React Native Best Practices for AI Agents（2026年1月）

デザインシステムの転換：Material 3 Expressiveの衝撃

2025年5月のGoogle I/Oで発表されたMaterial 3 Expressive（M3E、参考：Google Blog — Material 3 Expressive）は、スプリングベースのモーション、新しいシェイプライブラリ、強調タイポグラフィなど、Android UIの大幅な刷新です。Android 16 QPR1（2025年9月）でPixelデバイスに展開され、Googleの主要アプリも順次M3Eに対応しました。

重要なのは、フレームワーク間で対応状況に大きな差があることです。

• Jetpack Compose：M3Eコンポーネントがandroidx.compose.material3ライブラリで提供されています。LoadingIndicator・SplitButton・ButtonGroup・FloatingToolbarなどの新コンポーネントや、MotionSchemeなどのExpressive固有APIを利用できます。
• React Native（Expo UI）：Expo UI経由でJetpack Composeコンポーネントを利用できるため、M3Eへの追従余地があります。ただし、Expo UI自体がまだ安定化の途上にあるため、「React NativeでM3Eがすでに盤石」とまでは言えません。
• Flutter：M3 Expressiveは2026年3月時点で未サポートです。Flutterチームは「Currently, we are not actively developing Material 3 Expressive」と明言し、コントリビューションも受け付けていません。背景には、Material/Cupertinoライブラリをコアフレームワークから分離（デカップリング）する構造改革があります。Flutter 3.41（2026年2月）でこの分離が開始されており、M3Eは分離後のスタンドアロンパッケージとして提供される見込みですが、時期は未定です。

参考：Flutter GitHub Issue #168813 — Bring Material 3 Expressive to Flutter
参考：Android Developers — Material Design 3 in Compose

3. AIエージェントとの相性を決める要因

AIコーディングエージェントがコードを正確に生成できるかどうかは、主に以下の3点に依存します。

1. 学習データの量：React NativeはJS/TSの膨大なコーパスが強みです。Flutterは公式ドキュメントの充実とMCPで文脈理解を補完しています。
2. コンテキスト消費効率：クロスプラットフォームは1コードベースで完結するため、ネイティブ（2コードベース）に対してエージェントの把握コストが低くなります。
3. ツールチェーン連携：FlutterのDart公式MCPサーバーは、アナライザー→修正→テストのループを自律化できる点で現状もっとも体系的です。React Native側もCallstackがagent-skillsとしてClaude Code・Cursor等向けのスキルセットを公開しており、差は縮まりつつあります。

「AI code suggestion quality is roughly equivalent for both frameworks」
— Flutter vs React Native 7 Tests（tech-insider.org, 2026年3月）

ただし、ここでの比較は主に補助的な参考情報です。tech-insider.org や vibrant-info.com のような第三者記事は読み物としては参考になりますが、本記事の結論は公式ドキュメント、ベンダー自身の技術情報、公開された実装方針を主な根拠にしています。

補足資料として、スタートアップ視点の比較記事 React Native vs Flutter: Which Wins for Startups in 2026?（vibrant-info.com） や、React Nativeエコシステム全体の2025年の動向をまとめた React Native Wrapped 2025（Callstack） も参照できます。

4. ネイティブ vs クロスプラットフォームの比較

AIエージェント相性の比較

UI実装の特性比較

5. ハイブリッド実装の現実とAIエージェントへの影響

クロスプラットフォームを選んだとしても、実際のプロダクト開発ではネイティブ実装との境界が生まれます。カメラ・Bluetooth・生体認証・プッシュ通知・AR・HealthKitなど、OSのAPIを直接叩く必要がある機能は、プラグインやPlatform Channel / TurboModules経由でネイティブコードを呼び出さなければなりません。

この「境界線」が、AIエージェントにとってもっとも難しいポイントです。Dart/TSの世界とSwift/Kotlinの世界をまたぐ実装では、コンテキストが複数言語・複数ファイルに分散し、エージェントの生成精度が低下しやすくなります。

Flutterのハイブリッド実装：Platform Channel と FFI

Flutterでネイティブコードを呼び出す方法は主に2つあります。

• Platform Channel：DartとSwift/Kotlinの間でメッセージをやり取りする仕組みです。構造は明確ですが、Dart側・iOS側・Android側の3ファイルを整合させる必要があり、AIが片方を書いても他方と型定義がずれるミスが起きやすくなります。
• Dart FFI：C/C++ライブラリを直接呼び出す仕組みです。OSレベルの高性能APIに近づけますが、ポインタや型マッピングの知識が必要で、AIの生成精度はさらに下がります。

参考：Flutter公式ドキュメント — Developing packages & plugins（2026年1月28日更新）

React Nativeのハイブリッド実装：TurboModules + Codegen

React Native v0.76以降では、ネイティブモジュールの実装にTurboModulesを使います。TypeScriptのSpec定義ファイルからCodegenがiOS（Swift/Obj-C）とAndroid（Kotlin）のボイラープレートを自動生成するため、「TypeScriptのSpec」が単一の情報源（Single Source of Truth）になりやすいのが大きな強みです。

// NativeMyModule.ts — Specファイルの例
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceName(): string;
  requestCameraPermission(): Promise<boolean>;
}

export default TurboModuleRegistry.getEnforcing<Spec>('MyModule');

CodegenはこのSpecからiOS・Android両方のボイラープレートを自動生成します。AIエージェントはTS層に集中しやすく、ネイティブ実装の定型コードは自動生成に任せられます。

参考：React Native公式ドキュメント — Native Modules: Introduction
参考：Callstack — Announcing React Native Best Practices for AI Agents（2026年1月）

機能別：ハイブリッド実装の難易度とAI対応状況

ハイブリッド実装でAIエージェントを使う際の原則

「Native plugins and heavy custom logic still need human oversight.」
— Stitch + Antigravity + Flutter（dev.to, 2026年3月）

6. 何を選ぶべきか

ハイブリッド実装の現実を踏まえたうえで、シナリオごとの推奨をまとめます。

Flutter推奨：成熟プラグインで賄えるネイティブ機能のみの場合

カメラ・通知・認証など、定番プラグインがそろう機能なら、Dart + MCPサーバーによるエージェント統合は非常に効率的です。ただし、Android側でMaterial 3 Expressive準拠が必要な場合は、Flutterでは未対応のため注意が必要です。

React Native推奨：独自ネイティブモジュールの実装、またはM3E準拠が必要な場合

TurboModules + CodegenによるTypeScript Spec起点の設計は、AIエージェントの作業範囲を明確化しやすく、ハイブリッド実装で優位が出やすいです。Expo UIを通じてJetpack ComposeのM3Eコンポーネントへ追従できる可能性もありますが、採用時はExpo UIの成熟度を見極める必要があります。

ネイティブ推奨：ネイティブ実装が機能の大半を占める場合

ARKit・CoreML・カスタムBLE制御など、ネイティブ実装の比率が高いほどクロスプラットフォームの共通層のメリットは薄れます。最初からネイティブで書いた方が、AIのコンテキストを一言語に集中できます。

ハイブリッド戦略：UI層はFlutter、重いネイティブ処理はモジュール分離

アプリの大部分はFlutterで構築しつつ、ネイティブ処理が必要な箇所だけを明確に切り出してモジュール化する戦略もあります。AIエージェントには「Flutter層だけ」を担当させることで、精度を保ちやすくなります。

7. 結論

「どのフレームワークを選ぶか」より「ネイティブ実装の比率と種類が何か」で最適解は変わります

成熟プラグインで賄える範囲のネイティブ機能だけなら、FlutterはMCPサーバー連携も含めて非常に効率的です。独自ネイティブモジュールが必要なら、React NativeのTypeScript Spec起点の構造はAIにとって扱いやすいです。ネイティブ実装の比率が高くなるほどクロスプラットフォームの恩恵は薄れ、ネイティブ一択に近づきます。

いずれの場合も、ネイティブとクロスプラットフォームの境界を事前に設計してからエージェントに渡すことが、精度を左右します。

なお、Android向けにMaterial 3 Expressive準拠のUIが求められる場合は、Flutter（2026年3月時点で未サポート）より、React Native + Expo UI（Jetpack Compose経由）またはネイティブの方が現実的な選択肢です。ただし、React Native側でもExpo UIの成熟度は継続確認が必要です。Flutterチームはデザインライブラリのデカップリングを進めており、完了後にM3Eがスタンドアロンパッケージとして提供される見込みですが、タイムラインは不確定です。

参考文献

• React Native 0.76 リリースブログ — New Architecture デフォルト化
• React Native 0.82 リリースブログ — 旧アーキテクチャopt-out無効化
• React Native 0.83 リリースブログ — ゼロ破壊的変更、Legacy Architecture除外フラグ導入
• React Native 0.84 リリースブログ — Hermes V1デフォルト化、Legacy Architectureコード除外のデフォルト化
• Dart and Flutter MCP server — Flutter公式ドキュメント（2026年3月25日更新）
• Announcing Dart 3.9 — Dart公式MCPサーバーのstableチャネル追加
• Flutter — Developing packages & plugins — Platform Channel・FFI公式解説（2026年1月28日更新）
• React Native — Native Modules: Introduction — TurboModules公式ドキュメント
• Callstack — React Native Best Practices for AI Agents（2026年1月）
• Flutter vs React Native 7 Tests, 1 Clear Winner（tech-insider.org, 2026年3月）
• React Native vs Flutter: Which Wins for Startups in 2026?（vibrant-info.com, 2026年3月）
• Expo SDK 55 Changelog — Expo UIの概要とSDK 55の変更点
• Expo Blog — Expo UI in SDK 55 — Expo UIの位置づけと制約
• React Native Wrapped 2025（Callstack, 2026年2月）— React Nativeエコシステムの年間まとめ
• Google Blog — Material 3 Expressive（2025年5月）— M3E発表
• Flutter GitHub Issue #168813 — Bring Material 3 Expressive to Flutter — FlutterのM3E対応方針
• Android Developers — Material Design 3 in Compose — Jetpack ComposeでのM3E実装