LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Android ViewとJetpack Composeの違い — XMLレイアウト命令型UIと宣言型UIが分ける開発パラダイム

Android ViewからJetpack Composeへの移行外注とは、既存のAndroidアプリをView系（XMLレイアウト＋View/ViewGroup・命令的UI）で構築された状態から、Jetpack Compose（Kotlinによる宣言的UIフレームワーク）へ段階的または全面的に書き換える開発作業を、外部の開発パートナーに委託する取り組みを指します。

Android Viewは、XMLファイルでレイアウトを定義し、JavaまたはKotlinコードで`findViewById`（またはViewBinding）を使って各Viewを取得・操作する命令的UIの仕組みです。「ボタンをタップしたらこのTextViewのテキストを書き換える」というように、画面状態の変更手順をコードで逐一記述します。

Jetpack Composeは、Googleが2021年8月に正式安定版（1.0）をリリースした宣言的UIフレームワークです。KotlinのComposable関数（`@Composable`アノテーションを付けた関数）でUIを構築し、「データがこの状態のとき、画面はこう表示される」という対応関係を宣言するだけでUIを定義できます。状態が変わると、Compose ランタイムが差分を検知して必要な箇所だけ再コンポーズ（再描画）します。

命令的と宣言的の違いは、開発者の思考方法そのものを変えます。View系ではActivity/FragmentがUIの状態管理・ライフサイクル管理・レイアウト操作をすべて担います。Jetpack Composeでは状態（`State`/`StateFlow`/`ViewModel`）とUIを分離し、状態が変わればComposable関数が自動的に再コンポーズされます。

移行を判断する3つの理由：保守性・開発速度・Googleの推奨方向

View系で動いているAndroidアプリをJetpack Composeへ移行するかどうかは、3つの観点から判断できます。

1つ目は保守性の向上です。View系の画面はActivity/Fragmentにレイアウト操作・ビジネスロジック・状態管理が混在しがちで、コードが肥大化するにつれて読解・改修コストが上がります。Jetpack Composeへ移行すると、状態とUIが分離されたシンプルなComposable関数の集合になり、機能追加や不具合修正の工数を抑えやすくなります。

2つ目は開発速度の改善です。Jetpack ComposeはAndroid Studioのプレビュー機能（`@Preview`アノテーションによるキャンバスでのリアルタイム確認）を標準で備えており、レイアウト調整のサイクルが短縮されます。またCompose MultiplatformによるAndroid以外のプラットフォーム対応も視野に入れやすくなります。

3つ目はGoogleの技術方向性です。GoogleはAndroid Developers公式ドキュメントおよびAndroid Summitにおいて、新規開発にはJetpack Composeを推奨すると明示しています。新しいJetpackライブラリのAPIはCompose向けに先行提供される傾向が続いており、長期的な機能追加・メンテナンスを見越すと、早期に移行の計画を立てることが将来の技術的負債を抑えることにつながります。

一方、移行すべきでない状況もあります。minSdk 20以下のサポートが必要な場合（JetpackComposeはminSdk 21以上が必須）、または既存のView系実装が安定しており追加開発の予定がない場合は、コストに見合わないこともあります。移行を判断する前に、アプリの将来ロードマップと対象Androidバージョン分布を明確にすることが重要です。

段階移行が現実解：ComposeView/AndroidViewによる相互運用

既存のAndroidアプリをView系から一気にJetpack Composeへ全面書き換えることは、リリース停止リスクと開発工数の観点から現実的ではないケースがほとんどです。Googleはこの課題を想定しており、View系とJetpack Composeを共存させるための相互運用APIを公式に提供しています。

ComposeView — 既存ViewレイアウトにComposableを埋め込む

`ComposeView`は、既存のViewレイアウト（XMLまたはコード）の中にJetpack ComposeのComposable関数を埋め込むためのViewサブクラスです。XMLレイアウトの任意の場所に``要素を追加し、`setContent { }`内でComposable関数を呼び出すだけで利用できます。

例えば「設定画面の一部WidgetだけをCompose製の新UIに刷新したい」という要件なら、その部分だけXMLにComposeViewを配置してComposableを呼び出すだけで対応できます。他のViewには一切手を加えないため、既存機能のリグレッション（意図しない動作変化）リスクを局所化できます。

AndroidView — Composable内でAndroid Viewコンポーネントを使う

逆方向の相互運用も可能です。`AndroidView`はJetpack Composeのコンポーザブルの中に既存のAndroid View（`View`のサブクラス）を組み込むためのComposable関数です。複雑なカスタムView・MapView・WebView・AdMobのAdViewなど、Composeに未対応または移植コストが高いViewコンポーネントを、そのままComposableツリーの中から呼び出せます。

全てを書き換えるのではなく、Compose側のコードベースを拡大しながら必要に応じてView系資産を再利用するアプローチです。Fragmentを単位として移行する場合は`AbstractComposeView`を継承したカスタムViewを作成する方法も選択肢になります。

段階移行の進め方

実務上は「画面（Activity/Fragment）ごとのCompose化」または「コンポーネント（Widget）ごとのCompose化」を単位として移行を進めます。変更頻度が高い画面・新機能追加が多い画面・デザイン刷新対象の画面から着手し、ComposeViewで差し替えながら順次移行するのが現実的です。

ただし段階移行を選んだ場合でも、最終的なアーキテクチャの方向性（状態管理の方針・ナビゲーション設計）を最初に決めておくことが重要です。場当たり的に画面だけ差し替えると、View系側とCompose側で状態管理の方式が乱立し、後から統合コストが膨らむ原因になります。

移行で詰まる6つのポイント：minSdk・状態管理・LazyColumn・Navigation・テーマ・テスト

Jetpack Compose移行を外注で進める際、技術的に詰まりやすいポイントが6つあります。これらは事前に外注先と方針を合意しておかないと、途中でスコープ拡大や手戻りが発生しやすくなります。

最低APIレベル（minSdk）の制約

Jetpack ComposeはminSdk 21（Android 5.0）以上で動作します。ただし、Material Design 3（Material You）のダイナミックカラー機能はAndroid 12（API 31）以降でのみ有効になるなど、活用できる機能がAPIレベルによって異なります。移行前にユーザーのAndroidバージョン分布（Google PlayコンソールのAPIレベル分布）を確認し、minSdkをどこに設定するかを確定することが移行設計の出発点になります。

状態管理の刷新：State/ViewModel/StateFlow

View系ではLiveData・Observable・Delegateなどで状態変化を伝達するコードが多く含まれています。Jetpack Composeでは`mutableStateOf`（Compose State）・`ViewModel`・`StateFlow`を組み合わせた状態管理が基本です。`collectAsState`でStateFlowをCompose Stateに変換する設計が一般的になっています。

既存のView系コードにLiveDataが多用されている場合、LiveData→StateFlowへの移行が工数の大きな部分を占めます。また`remember`・`rememberSaveable`・`derivedStateOf`などのCompose固有のState APIを正しく使い分けないと、意図しない再コンポーズやパフォーマンス低下が発生します。外注先がこれらの仕様を熟知しているかは事前の技術確認で見極める必要があります。

RecyclerView→LazyColumnへの移行

Android開発でリスト表示に広く使われてきたRecyclerViewは、Jetpack ComposeではLazyColumn（縦スクロールリスト）・LazyRow（横スクロールリスト）・LazyVerticalGrid（グリッド）に対応します。RecyclerView.AdapterやDiffUtilを使った既存実装は、PagingLibrary（Compose対応版）やシンプルなitemsブロックに書き換える必要があります。

スクロールパフォーマンス・アイテムアニメーション・スクロール状態の復元（rememberLazyListState）の設計は、View系のRecyclerViewとは考え方が異なります。複雑なリスト画面を多く持つアプリでは、この移行が工数の大きなボトルネックになります。

Navigation ComponentからNavigation Composeへの移行

View系アプリで使われているNavigation Component（`NavController`・`NavGraph`・XML定義のナビゲーショングラフ）は、Jetpack Composeの`NavHost`・`composable`ルートによるNavigation Composeに置き換えることになります。ディープリンク・バックスタックの制御・引数の受け渡しの設計が変わるため、複雑なページ遷移を持つアプリでは再設計の工数が大きくなります。

Material Design 3テーマの適用

Jetpack Composeで推奨されるデザインシステムはMaterial Design 3（Material You）です。View系で使っていたMaterial Design 2のColorTheme・TextAppearanceとは体系が異なり、`MaterialTheme`の`colorScheme`・`typography`・`shapes`を再定義する必要があります。既存アプリのデザインを維持しながら移行する場合は、テーマ変換の設計を移行初期に行っておくことが重要です。

UIテスト（Espresso→Compose Testing）の整備

View系アプリに既存のEspressoテストが存在する場合、Jetpack Compose化に伴いUI要素の識別方法が変わります。Compose TestingではCompose Semantics（`contentDescription`・`testTag`）を使ったUI要素の検索が基本です。移行と並行してテストを整備するか、移行後に再設計するかを外注先と合意しておく必要があります。

内製でJetpack Compose移行を担うには、Kotlin・Jetpack Composeの深い実装経験・Googleの最新APIへの継続的なキャッチアップ・Android Studioによる検証環境の整備が必要です。これらのスキルセットを持つエンジニアを確保・維持するコストと外注費用を比較したうえで意思決定することをおすすめします。

外注費用の相場：移行範囲と既存コード品質が費用を決める

Android View→Jetpack Compose移行の外注費用は、移行画面数・既存コードの品質・状態管理の刷新有無・テスト整備範囲によって大きく変動します。以下に示す費用レンジはあくまで市場参考値であり一次資料ではありません。実際の費用は複数の外注先へ個別見積もりを依頼して確認してください。

費用を大きく変動させる主な要因を以下に整理します。

• 既存コードの品質：View系のコードがMVVM・Clean Architectureなどで整理されているか、Activity/Fragmentにロジックが集中しているかで調査・設計工数が変わります
• 状態管理の刷新範囲：LiveData→StateFlowへの移行・ViewModelの再設計が必要かどうかで工数が変わります
• RecyclerView画面の数と複雑度：カスタムアダプター・DiffUtil・Pagingを使ったリスト画面の数が多いほど移行工数が増加します
• Navigation Composeへの移行範囲：既存のNavigation Componentのグラフが複雑なほど、再設計の工数が増えます
• minSdkの引き上げ有無：対応Androidバージョンの変更が伴う場合は、APKのビルド設定・Play Consoleの対象設定変更も必要です
• テスト整備の範囲：EspressoテストのCompose Testing対応・ユニットテストの追加が含まれるかどうかが費用に影響します

「現状調査フェーズだけ先に外注する」という方法も有効です。移行費用を正確に見積もるには既存コードの詳細調査が必要なため、調査フェーズ（技術的負債の棚卸しと移行設計）を数十万円で先行委託し、その結果をもとに本移行の費用を判断する進め方がリスクを抑えます。

外注の進め方：現状調査→移行方針→段階移行→検証の4ステップ

Android View→Jetpack Compose移行を外注で進める場合、以下の4ステップを基本フローとして押さえることで、スコープ拡大や手戻りを防げます。

ステップ1：現状調査 — コードベースと画面の棚卸し

最初のステップは既存のView系コードを外注先が調査するフェーズです。調査項目は①全画面数と各画面の複雑度、②カスタムViewコンポーネントの数と再利用範囲、③Activity/FragmentへのロジックとUI操作の集中度、④既存テスト（Espresso・JUnit）の有無と品質、⑤現在のminSdkとターゲットAPIレベル、⑥Navigation Componentの使用状況、の6点が中心になります。

この調査結果が移行費用見積もりの根拠となります。コードレビューへのアクセス権限（GitHubなどのリポジトリ閲覧権限）を外注先に提供する必要があるため、NDA（秘密保持契約）の締結を先に行います。

ステップ2：移行方針の決定 — 全面移行か段階移行か、minSdkの確定

調査結果をもとに、外注先と以下の方針を合意します。まず「全面書き換えか段階移行か」を決定します。多くの場合は段階移行（ComposeViewを活用した画面・コンポーネント単位の置き換え）が選ばれます。

次に「どの画面から移行するか」の優先順位を決めます。変更頻度が高い画面・新機能追加予定がある画面を優先すると、移行の投資対効果が得られやすくなります。あわせて「minSdkをどこに設定するか」も確定します。minSdk 26（Android 8.0）以上に設定できればMaterial Design 3のカラースキームを幅広く活用でき、コードが簡潔になります。

ステップ3：段階移行の実施 — 画面・コンポーネント単位のCompose化

移行方針に従い、画面またはコンポーネント単位でJetpack Composeへの置き換えを進めます。各画面の移行完了時にはUIテスト・手動テストでリグレッションがないことを確認してからマージします。View系とComposeが混在する期間は、状態管理の一貫性（どちら側で状態を持つか）をアーキテクチャドキュメントで明文化しておくことが重要です。

移行と同時にLiveData→StateFlowへの移行やViewModelの再設計を進める場合は、画面数だけでなく状態管理の書き換え工数も計上される点に注意が必要です。

ステップ4：検証・統合 — UI整合性の確認とテスト整備

全移行対象画面のCompose化が完了したら、アプリ全体のUI整合性（Material Design 3テーマの統一・スペーシング・フォント）を確認します。View系とComposeが混在している段階では、デザインの細部が一致しないケースが発生しやすいため、デザインシステムと照合するレビューを実施します。

最終的にGoogle Playへの審査・リリースまでを外注先が担うかどうかも、契約時に明確にしておく必要があります。Google Play Consoleの操作・AAB（Android App Bundle）のビルド・審査ポリシー対応・ストア掲載情報の更新まで含めて外注できるかどうかは、委託先選定の重要な評価ポイントです。

外注先の選び方：Kotlin/Compose実績・段階移行経験・リリース管理体制で見極める

Android View→Jetpack Compose移行を外注する場合、一般的なAndroidアプリ開発会社ではなく、移行プロジェクトの経験を持つ外注先を選ぶことが重要です。新規開発と移行では求められるスキルセットが異なります。

確認すべき5つのポイント

外注先を選定する際は、以下の5点を確認します。

• Kotlin/Jetpack Compose実績：Jetpack Compose 1.0（2021年）以降を対象とした実案件（可能であればComposeを採用したリリース済みアプリ）を持つかどうか。ポートフォリオまたはGoogle Playで確認できるか確認します
• ComposeView/AndroidViewを使った段階移行の経験：既存View系アプリのリプレイスやCompose化の実績があるかどうか。新規開発のみの会社とは経験が異なります
• 既存コードの調査・読解能力：他社が書いたView系のKotlin/Javaコードを読み解き、移行リスクを評価できるか。提案段階で「現状調査メモ」の提出を求めることで見極められます
• 状態管理の知見：ViewModel・StateFlow・Compose State（`mutableStateOf`・`remember`・`rememberSaveable`）を正確に使い分けられるか。設計提案書にこれらの記述があるか確認します
• Google Playの審査・リリース管理体制：Google Play Consoleの操作・AABビルド・ポリシー対応・ストア掲載情報の管理まで一気通貫で対応できるかどうかです

契約形態の選び方

Android View→Jetpack Compose移行のような改修プロジェクトは、要件定義前にスコープが確定しないことが多く、準委任契約（工数精算型）での契約が適することがあります。一方で現状調査〜移行方針決定フェーズは固定費用の請負契約で切り出し、本移行フェーズを準委任で進めるハイブリッド契約も有効です。

いずれの場合も、進捗報告の頻度・成果物の定義・品質基準（テストカバレッジ・コードレビュー体制）を契約書または別紙の業務仕様書に明記することで、完成物の品質リスクを管理できます。

内製チームとの協業形態も検討に値します。自社でプロダクトオーナーがいる場合、外注先にはCompose実装の専門知識を担ってもらい、ビジネスロジックや要件の確認は内製で行うスタイルも有効です。この形でも、外注先が元請（プライムベンダー）として開発全体を統括できるかどうかで、プロジェクト管理コストが大きく変わります。

まとめ：Android View→Jetpack Compose移行外注を成功させる3つの判断軸

本記事では、既存AndroidアプリをView系からJetpack Composeへ移行する外注の進め方・費用・技術的ポイントを整理しました。要点を3つに集約すると次のとおりです。

第一に、段階移行（ComposeView/AndroidView活用）が現実的な選択です。全面書き換えはリリース停止リスクが高く、既存View資産の損失期間が生じます。画面・コンポーネント単位でのCompose化を段階的に進める方法が、リスクを抑えながら移行できる現実解です。

第二に、minSdkの確定と現状調査が費用を左右します。Jetpack ComposeはminSdk 21以上で動作しますが、Material Design 3のダイナミックカラーなど機能の一部はAPIレベルに依存します。移行前にminSdkを確定し、外注先による既存コードの詳細調査を最初のフェーズとして設けることで、見積もり精度と移行品質が上がります。

第三に、外注先の選定はKotlin/Compose実案件の実績と段階移行経験で見極めることが重要です。新規開発実績だけでなく、既存View系コードの移行経験・状態管理（ViewModel/StateFlow）の知見・Google Play審査管理まで一気通貫で対応できるかを確認することが、プロジェクト失敗リスクの低減につながります。

よくある質問

Android View→Jetpack Compose移行の外注費用はどのくらいですか？

移行範囲・画面数・既存コードの品質によって大きく異なります。10〜20画面程度の部分移行であれば150万〜500万円程度が市場参考値の目安ですが、50画面以上の大規模全面移行では1,500万円以上になるケースもあります。これらはあくまで市場参考値であり一次資料ではないため、複数社への個別見積もりで確認してください。

全面書き換えと段階移行のどちらが適していますか？

多くのケースでは段階移行が現実的です。ComposeView（既存ViewレイアウトにComposableを埋め込む）とAndroidView（Composable内でAndroid Viewコンポーネントを使う）を組み合わせることで、既存アプリのリリースを止めずに画面・コンポーネント単位でJetpack Composeへ移行できます。まず既存コードの調査フェーズを先行させ、移行方針を確定してから着手することを推奨します。

Jetpack Compose移行に必要な最低APIレベル（minSdk）はどのくらいですか？

Jetpack ComposeはminSdk 21（Android 5.0 Lollipop）以上で動作します。ただしMaterial Design 3のダイナミックカラー機能はAndroid 12（API 31）以降でのみ有効になるなど、活用できる機能がAPIレベルによって異なります。移行前にユーザーのAndroidバージョン分布を確認し、minSdkをどこに設定するかを外注先と合意することが重要です。

Jetpack Compose移行で特に注意すべき技術的な詰まりポイントはどこですか？

主な詰まりポイントは①minSdk制約と新APIのバージョン分岐、②状態管理（State/ViewModel/StateFlow）の設計見直し、③RecyclerView→LazyColumnへの移行、④Navigation Component→Navigation Composeへの移行、⑤Material Design 3テーマの適用、⑥UIテスト（Espresso→Compose Testing）の再整備、の6点です。これらは事前に外注先と方針を合意しておかないと手戻りが発生しやすくなります。

Jetpack Compose移行の外注先はどのように選べばよいですか？

選定のポイントは①Kotlin/Jetpack Compose実案件の実績、②ComposeView/AndroidViewを使った段階移行の経験、③既存View系コードの読解・調査能力、④状態管理（ViewModel/StateFlow/Compose State）の知見、⑤Google Play審査・リリース管理まで一気通貫で対応できるか、の5点です。開発からテスト・リリース管理まで元請（プライムベンダー）として対応できる外注先に依頼することで、複数ベンダー間の調整コストを抑えられます。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Jetpack Compose — Android Developers」（公式ドキュメント）
2. *2　出典：Google「Compose interoperability APIs — Android Developers」（公式ドキュメント）