Jetpack Composeとは？宣言的UIの仕組みとBOM運用・採用判断を解説

Jetpack Composeは、Androidの画面をXMLレイアウトではなくKotlinの関数として書く宣言的UIツールキットです。2026年7月末時点の安定版はcompose-bom 2026.06.01で、compose-ui 1.11.4とmaterial3 1.4.0を束ねています。この記事では、Composable関数と再コンポーズが状態を画面に反映する仕組み、BOMでライブラリの版を揃える依存管理、既存のXMLレイアウトと共存させながら移す順序、Kotlin 2.0.20で既定になったstrong skippingを前提にした状態設計、そして受託案件で採用してよい条件と見送るべき場面までを実装者の視点で整理しました。入門記事が扱わない版の運用と採用判断に踏み込みます。

まとめ：Jetpack Compose導入の判断軸とBOM運用で押さえる要点

Jetpack Composeは、Kotlin専用・Android専用のUIツールキットです。判断の順序は3つ。新規のAndroidアプリなら選ばない理由がほとんどありません。既存アプリなら画面単位で切り替えられるため、全面書き直しの計画を立てる必要はありません。逆に、Kotlin 2.0以降へ上げられないプロジェクト、WebViewが画面の大半を占めるアプリ、保守メンバーがKotlinを書けない体制では見送るのが妥当な判断になります。

版の運用はandroidx.compose:compose-bomに集約させてください。個別ライブラリの版を手で並べると、compose-uiとmaterial3の組み合わせがずれて実行時に落ちる事故が起きます。もうひとつの落とし穴がコンパイラです。Compose Compiler Gradleプラグインの版はKotlinの版と一致させる決まりで、Kotlinを上げるたびにプラグインも同じ番号へ揃えます。以降の章では、この2点の具体と、移行・性能設計・見積もりの判断基準を順に扱います。

Jetpack Composeが宣言的UIとして提供する仕組みと担当範囲

Composeを理解する近道は、従来のAndroid Viewと「誰が画面を書き換えるか」を比べることです。担当範囲を先に押さえると、後の移行判断がぶれません。

命令型のView更新と宣言的なComposable関数の記述の違い

従来のAndroid Viewでは、XMLで部品を配置し、Kotlin側からfindViewByIdで参照を取り、テキストや表示状態を1つずつ書き換えていました。画面の状態が5種類あれば、その5種類すべてに対する書き換え手順をコードで維持する必要があります。表示崩れの多くは、この書き換え漏れから生まれます。

Composeでは、状態を受け取って画面の見た目を返す関数を書きます。ボタンの表示・非表示を分岐で書けば、状態が変わったときに枠組み側が関数を呼び直し、差分を画面へ反映します。書き換え手順を書かない分、状態の数が増えてもコードの複雑さが跳ね上がりません。一方で「今どんな状態か」の設計責任は開発者側に寄ります。

@ComposableとRecompositionが担う状態から画面への反映

@Composableを付けた関数がUIの構成単位です。この関数は戻り値でViewを返さず、呼び出された文脈にUIツリーを記述します。状態が変わると、その状態を読んでいた関数だけが呼び直されます。これが再コンポーズ（Recomposition）で、Composeの性能特性を決める中心の仕組みです。

再コンポーズは画面全体では起きません。mutableStateOfで作った状態を読んでいる範囲だけが対象になります。逆に言えば、画面の最上位で状態を読んでしまうと、下位のすべてが呼び直しの対象になります。読む位置を下げるほど描画の負荷が下がる。この関係が、後述する状態設計の出発点です。

KotlinとAndroid Viewの上に載るComposeの実行位置

ComposeはKotlinでしか書けません。公式のプロジェクト作成手順でも言語の選択肢はKotlinのみで、Javaのクラスから@Composable関数を直接呼ぶ手段は用意されていません。Java資産が多いプロジェクトでは、UI層から順にKotlinへ寄せる前提になります。言語側の前提はKotlinとは？Javaとの違いとK2コンパイラ・2.4系の現在地で整理しています。

実行位置も押さえておきます。Composeは既存のAndroid Viewを置き換える描画エンジンではなく、ComposeViewという1つのViewの内側で独自にUIを描く仕組みです。ActivityやFragment、リソース、Navigationといった土台はそのまま残ります。利用できる最小APIレベルは21以上です。だからこそ画面単位の共存が成立します。

Compose本体とMaterial 3をBOMで束ねる依存関係の管理方法

Composeは単一のライブラリではありません。ui・foundation・material3・runtime・animationなどが別々に版を刻むため、依存の書き方を誤ると組み合わせが崩れます。

compose-bomで版を揃える構成と2026年7月末時点の安定版

BOM（Bill of Materials）は、動作確認済みの組み合わせを1つの番号で指定する仕組みです。androidx.compose:compose-bomをプラットフォーム依存として読み込み、個別ライブラリは版を書かずに宣言します。公式のマッピング表から、直近の対応は次の通りです。

material3が1.4.0で据え置かれている点に注意してください。UI側が細かく上がってもデザイン部品側は動かない期間があり、BOMを上げても見た目の挙動は変わらないことがあります。なお、2026-07-29時点でcompose.uiなど中核ライブラリは1.12.0-rc01が公開されており、正式版が出ればBOMの番号も切り替わります。検証環境で先に確かめる価値がある更新です。

Compose Compiler GradleプラグインとKotlin版の対応関係

Kotlin 2.0以降、Composeのコンパイラはコンパイラプラグインとして独立しました。プラグインIDはorg.jetbrains.kotlin.plugin.composeで、版はKotlin本体と同じ番号を指定します。公式手順の記載例はKotlin 2.3.21に対してプラグインも2.3.21です。バージョンカタログを使うならversion.refをKotlinと共有させると、上げ忘れの事故が消えます。

古い設定が残っているプロジェクトではcomposeOptionsブロックのkotlinCompilerExtensionVersionが生きていることがあります。Kotlin 2.0以降ではこの指定が役目を終えているため、プラグイン方式へ書き換えます。移行の副産物として、Kotlinを上げるたびにCompose Compilerの対応表を調べる作業が不要になりました。安定性の設定を外部ファイルへ切り出すstabilityConfigurationFileも同じブロックで指定できます。

既存のXMLレイアウトとComposeを共存させる移行手順と分割の単位

移行の失敗はほぼ例外なく「単位の取り方」で決まります。全画面を一気に書き直す計画は、リリース間隔の長期化とレビュー不能な差分を生みます。

ComposeViewとAndroidViewで画面単位に切り替える移行の順序

両方向の橋渡しが標準で用意されています。XMLの中にComposeを差し込むのがComposeView、Composeの中に既存のカスタムViewや広告Viewを差し込むのがAndroidViewです。実務では次の順序が扱いやすくなります。

1. 新規追加する画面だけをComposeで書き、既存画面には触れない
2. 更新頻度が高く、テストが薄い画面からComposeViewで置き換える
3. リスト画面をRecyclerViewからLazyColumnへ移し、表示崩れの回帰を確認する
4. Compose化できない依存ViewだけをAndroidViewで包んで残す

4番目を許容できるかどうかが分岐点です。地図や動画プレーヤー、決済SDKの画面部品はCompose対応が遅れがちで、包んだまま数年運用する前提を最初から置いておくと計画が破綻しません。

テーマとリソース定義をXML側と二重管理しないための分割基準

共存期間に最も揉めるのが色とタイポグラフィです。XML側のstyles.xmlとCompose側のMaterialThemeに同じ値を書くと、片方だけ直された状態が必ず生まれます。基準は単純で、値の正本を1か所に置くこと。移行期はXML側を正本にし、Composeのテーマはそこから読み替える構成が安全です。

文字列とディメンションの扱いは分けて考えます。文字列リソースはstringResourceで参照でき、翻訳運用をそのまま引き継げるため二重化する理由がありません。一方、間隔や角丸はCompose側でKotlinの定数として持つほうが読みやすくなります。すべてを揃えようとせず、翻訳と色は既存、レイアウト寸法はCompose、と線を引いてください。

再コンポーズの回数を抑える状態設計とstrong skippingの前提

Composeで体感速度が落ちる原因のほとんどは描画エンジンではなく、不要な再コンポーズです。前提となるコンパイラの挙動から押さえます。

Kotlin 2.0.20から既定になったstrong skippingの効き方

strong skippingは、Kotlin 2.0.20で既定有効になったコンパイラの動作です。これが入る前は、引数の型がすべて安定（stable）と判定された関数だけがスキップ対象でした。有効になった後は、再起動可能なComposable関数がすべてスキップ可能になります。不安定な型を引数に取っていても対象です。

もう1つの効果がラムダの記憶です。不安定な値をキャプチャしたラムダを、コンパイラがキャプチャ値をキーにしたrememberで自動的に包みます。手書きでrememberを並べていた定型作業がかなり減りました。ただし、これは「安定性を気にしなくてよい」という意味ではありません。データクラスの中身が変わり続ければ、スキップ判定は当然外れます。

状態のホイスティングと不変データで再描画の範囲を絞る設計手順

設計の勘所は2つに絞れます。第一に、状態は使う関数の近くに置き、上位へ無闇に持ち上げないこと。画面全体のViewModelに1つの巨大なデータクラスを持たせると、どこか1フィールドの変化で画面全体が再コンポーズの候補になります。第二に、リストはListではなくImmutableListなど不変であることが型から分かる形で渡すこと。

効果の確認は感覚ではなく計測で行ってください。Compose Compilerのレポート出力をreportsDestinationで有効にすると、どの関数がスキップ可能かがビルド時に一覧で出ます。加えて、2025年8月のBOMで入った1.9系ではリスト描画の性能改善と2Dスクロール向けAPIが入っており、古いBOMのまま性能を評価しても現行の挙動とはずれます。まずBOMを上げ、それから計測する順序が正解です。

新規案件でComposeを採用してよい条件と見送るべき場面の線引き

ここは条件付きで言い切ります。玉虫色の結論は、見積もりでも技術選定でも役に立ちません。

新規Androidアプリで迷わずComposeを選んでよい条件

新規のAndroidアプリで、Kotlin 2.0以降を使え、対象OSがAPI 21以上で、開発メンバーがKotlinを日常的に書いているなら、Composeを選んでください。XMLレイアウトを新規に起こす理由は、この条件下ではほぼ残りません。プレビュー機能によるUIの確認速度と、状態から画面を導く記述の見通しが、学習コストを数週間で回収します。

将来iOSへ展開する可能性がある場合も、Composeで書いた記述はJetBrainsのCompose Multiplatformへ持ち込む余地が残ります。ただしJetpack Compose自体はAndroid専用で、そのままiOSで動くわけではありません。共有の土台となる仕組みはKotlin Multiplatformとは？その利点と特徴を先に確認しておくと、判断の順序を誤らずに済みます。

Composeを見送るべき案件の条件と失敗しやすい移行の進め方

次の条件に当てはまるなら見送りが妥当です。判断を先送りにしないでください。

• Kotlin 2.0以降へ上げられない事情がある（依存ライブラリの非対応、検証工数の未確保）
• 画面の大半がWebViewで、ネイティブUIの記述量がそもそも少ない
• 保守を引き継ぐ体制がJavaのみで、Kotlinの読み書きを教育する計画がない
• 残存期間が1年程度と決まっている旧アプリで、改修が障害対応に限られる

失敗しやすい型も挙げておきます。最悪なのは「全画面を一括で書き直す」計画です。数か月リリースが止まり、その間の障害対応が旧コードと新コードへ二重に発生します。次に多いのが、既存のUIテストを捨ててから移行を始めるやり方。回帰の検出手段を失うため、表示崩れが本番で見つかります。なお、既存のReact Nativeアプリを抱えている場合はCompose移行よりExpo UI（@expo/ui）でネイティブUIを描く構成のほうが投資対効果は高く、無理にネイティブへ寄せる必要はありません。

受託開発でCompose案件の見積もりと保守体制を組む判断基準

技術判断と同じくらい、体制の判断が案件の成否を決めます。工数のずれが出る箇所は事前にほぼ特定できます。

Compose案件の見積もりで工数が膨らむ箇所と過小評価の要因

膨らむのは画面の実装そのものではありません。第一にデザインシステムの整備で、色・タイポグラフィ・間隔をMaterial 3の枠組みへ落とし込む初期作業に、画面数と無関係の固定工数が乗ります。第二にAndroid View資産の橋渡しで、地図やカメラ、決済SDKをAndroidViewで包む部分は個別調査が要ります。第三がアニメーションとジェスチャで、XML時代の実装をそのまま移せません。

過小評価の典型は「XMLの行数から換算する」やり方です。Composeは記述量が減る一方、状態設計の検討時間が増えます。行数ベースの換算は初回案件ではほぼ外れるものです。発注側と工程の全体像を揃えるならAndroidアプリ開発とは？できること・開発の流れ・iOSとの違いと外注の進め方を共通の下敷きにすると、見積もりの前提説明が短く済みます。

Compose移行を内製と外注で分ける保守範囲と体制の決め方

分担の基準は「更新頻度」で引いてください。デザインシステムと共通コンポーネント群は、一度作ると変更が少なく、品質が全画面へ波及します。ここは外部の実装者が集中して作り切るほうが速い領域です。逆に、業務ロジックに密着した個別画面は仕様変更が続くため、内製側が持ったほうが伝達のロスが減ります。

BOMとKotlinの更新は、担当を明文化しないと誰も触らなくなります。四半期に一度BOMを上げて回帰を確認する担当を、契約の保守範囲に明記してください。新規のCompose実装、あるいはXML資産を抱えたアプリの移行計画づくりからの相談はAndroidアプリ開発で受けています。既存コードの規模と対象OS、Kotlinの版が分かれば、移行の単位と概算の工程まで一度に示せます。

よくある質問

Jetpack Composeの検討時に実務でよく挙がる質問を5つ整理しました。

Jetpack ComposeはJavaでも書けますか？

書けません。@Composable関数はKotlinのコンパイラプラグインが処理する仕組みで、Javaから直接呼ぶ手段は提供されていません。公式のプロジェクト作成手順でも、Composeを選ぶと言語の選択肢はKotlinのみになります。Java中心のプロジェクトで導入するなら、UI層から順にKotlinへ移す計画が前提です。Kotlin側からJavaのクラスは従来どおり呼べるため、業務ロジックを一括で書き直す必要はありません。

XMLのレイアウトは全部書き直す必要がありますか？

ありません。ComposeViewを使えばXMLの一部にComposeを差し込めますし、AndroidViewで既存のカスタムViewをCompose側から呼び出せます。実務では、新規画面と更新頻度の高い画面から順に切り替え、地図や決済SDKなどCompose対応が遅れている部品は包んだまま残す形が現実的です。全面書き直しはリリースが長期間止まるため、避けてください。

Compose MultiplatformとJetpack Composeは同じものですか？

別物です。Jetpack ComposeはGoogleが提供するAndroid専用のUIツールキットで、Compose MultiplatformはJetBrainsが同じ記述モデルをiOS・デスクトップ・Webへ広げた枠組みです。記述の作法は共通しているため学習は引き継げますが、Androidだけを対象にしているうちはJetpack Composeで完結します。共通化の土台にはKotlin Multiplatformの理解が前提になります。

Composeに移行するとアプリの起動やスクロールは遅くなりますか？

設計次第です。速度低下の原因はほぼ不要な再コンポーズで、状態を上位に集めすぎている構成が典型となります。Kotlin 2.0.20から既定になったstrong skippingで、不安定な引数を持つ関数もスキップ対象になり、素朴な実装での取りこぼしは減りました。加えて2025年8月のBOMで入った1.9系はリスト描画の性能が改善しています。評価するなら、BOMを現行へ上げてから計測してください。

Composeが使えるAndroidのバージョンはどこからですか？

APIレベル21以上です。公式のプロジェクト作成手順でも、Composeを使う場合はAPI 21以上を選ぶ案内になっています。実務上は対象OSの下限がこれを下回ることはほとんどなく、制約になる場面は限られます。むしろ確認すべきはKotlinの版で、Compose Compilerがプラグイン方式になったKotlin 2.0以降へ上げられるかどうかが、導入可否の実質的な条件です。

関連記事

• Androidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説：Composeの前提となる言語選定を判断できます。
• Android Studioとは？できること・使い方・インストール手順と最新版の概要をわかりやすく解説：プレビューやビルド環境の準備手順が分かります。
• Capacitorとは？Ionic製ネイティブランタイムの仕組みと8系要件・採用判断を解説：Web技術でアプリを作る対極の選択肢です。
• Ionicとは？UIツールキットの構造と8系の要件・採用判断を解説：UI部品群の考え方をCompose以外と比べられます。
• Realm（モバイルDB）とは？SQLiteとの違いとDevice Sync終了後の採用判断を解説：Composeへ渡す状態の供給元を選ぶ参考になります。