Androidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説

Androidアプリ開発の言語は、実質的にKotlinとJavaの2択から始まります。Googleは2019年5月のGoogle I/OでKotlinを優先する方針（Kotlin-first）を宣言し、公式ドキュメントのサンプルコードもKotlinが標準になりました。一方で、Javaで書かれた既存アプリは今も動き続けており、Javaを選ぶ判断が成立する場面も残っています。この記事では、公式方針の一次情報、null安全やコルーチンといった言語仕様の違い、Android StudioとJetpack Composeという開発環境の前提を整理し、受託開発の現場から見た言語選定の判断基準まで示します。

まとめ：新規はKotlin・既存Java資産の保守はJavaという選定の結論

結論から示します。新規のAndroidアプリ開発でKotlin以外を選ぶ理由は、2026年7月時点ではほぼありません。Googleが公式にKotlinを推奨し、標準UIツールキットのJetpack ComposeはKotlin専用です。null安全による実行時クラッシュの抑制、コルーチンによる非同期処理の簡潔な記述など、保守性に直結する言語仕様の差もKotlin側にあります。

Javaが残る領域は「既存資産の保守・拡張」です。Javaで書かれた稼働中のアプリに小規模な改修を続ける場合や、開発体制がJavaの経験者で構成されている場合は、無理な全面書き換えよりJava維持のほうが費用対効果で上回ります。KotlinとJavaは同一プロジェクト内で混在でき、新規クラスだけKotlinで書く段階移行も選べるため、「いま全部をどちらかに寄せる」必要はありません。この結論に至る根拠を本文で順に説明します。

Android公式言語の現在地—Kotlin優先へ移行した経緯とJavaの位置づけ

最初に「公式が何を推奨しているか」という一次情報を押さえます。言語選定の議論が個人の好みに流れないよう、GoogleとJetBrainsの公表事実を基準にします。

Google I/O 2019のKotlin-first宣言と公式ドキュメントの推奨言語

GoogleがKotlinをAndroidの公式サポート言語に加えたのは2017年5月、さらに2019年5月のGoogle I/Oで「Androidアプリ開発はKotlin-first」と宣言しました。以降、Android公式ドキュメントのコード例はKotlinが第一に掲示され、新規APIやライブラリ（Jetpack）はKotlinでの利用を前提に設計されています。Android公式サイトには、上位1,000本のAndroidアプリのうち95%以上がKotlinコードを含むという記載があり（2026年7月時点）、業界標準の位置はすでに固まっています。

この方針は「Javaの打ち切り」ではありません。Google自身がJavaコードのサポート継続を明言しており、既存JavaアプリがOS更新で動かなくなるという性質の変化ではない点は、選定の前提として区別しておくべき事実です。

Kotlin 2.4系とJava 25 LTS—2026年7月時点の言語バージョン整理

両言語とも開発は活発です。KotlinはJetBrainsが開発し、2024年5月の2.0で新コンパイラ（K2）が既定になって以降も更新が続き、2026年6月に公開された2.4.0では文脈パラメータの安定化やJava 26対応が入りました。2026年7月時点の最新は2.4系です。

Javaは2025年9月公開のJava 25が最新のLTS（長期サポート版）で、その後の通常版としてJava 26が出ています。ただしAndroid開発では、この「Java本体の最新版」がそのまま使えるわけではありません。Androidで利用できるJava言語機能とAPIはビルドツールチェーン経由で提供され、対応範囲はAndroid Gradle Pluginと脱糖（desugaring）の仕組みに依存します。サーバーサイドJavaの感覚で最新構文を前提にすると、Android側で使えないという食い違いが起きます。

JavaコードがAndroidで動き続ける互換性の仕組みと機能制約

KotlinもJavaも、コンパイルされると同じバイトコードになり、Androidの実行環境（ART）上で区別なく動きます。だからこそ両言語は1つのアプリに混在でき、Javaで書かれた資産は今後も動作し続けます。ビルド環境としては、Android Gradle Plugin 8系がJDK 17以上を要求するため、開発マシン側のJDK更新は必要です。

制約は「新しいJava APIをどこまで使えるか」に現れます。java.timeなど比較的新しいAPIを古いAndroid端末で使うには脱糖の設定が必要で、対応範囲は公式ドキュメントの一覧での確認が前提です。Java側の言語進化を追う開発をAndroidで続けるのは制約が多く、この点も新規開発でKotlinへ寄せる実務上の理由になっています。

KotlinとJavaの言語仕様比較—null安全・コルーチン・記述量の差

次に、選定の実質的な根拠になる言語仕様の差を見ます。観点は網羅ではなく、Androidアプリの品質と保守コストに直接効く3点に絞ります。

null安全とデータクラスがクラッシュ率と記述量に効く仕組み

Androidアプリのクラッシュ原因として古くから代表的なのがNullPointerException（NPE）です。Kotlinは型システムでnullを許容する型（String?）と許容しない型（String）を区別し、null検査を通らないコードはコンパイル時に弾かれます。Javaでは実行して初めて分かる不具合の一部が、Kotlinでは実行前に検出される構造です。Android公式の事例では、Google HomeアプリがKotlin導入後にNPE起因のクラッシュを33%削減したと報告されています。

記述量の差も具体的です。値を保持するだけのクラスをJavaで書くとコンストラクタ・getter・equals・hashCodeで数十行になりますが、Kotlinのdata classなら1行で済みます。Duolingoの公式事例では、Kotlin移行で行数が平均30%減ったと公表されており、コードが短いことはレビュー・保守の工数減として効いてきます。

コルーチンによる非同期処理とJavaのスレッド実装との書き方の違い

Androidアプリは通信やDB読み書きをUIスレッドの外で実行する構造が必須で、非同期処理の書きやすさが開発効率を左右します。Javaではスレッドやコールバックを組み合わせる書き方が基本になり、処理の流れが入れ子のコールバックに分断されがちです。Kotlinのコルーチンは、非同期処理を同期処理と同じ見た目の逐次コードで書ける仕組みで、Jetpackの主要ライブラリ（Room・ViewModel等）もコルーチン前提のAPIを提供しています。

Java側にもJava 21以降の仮想スレッドという進展はありますが、前述の通りAndroidのツールチェーンでは最新Java機能をそのまま前提にできません。Android上の非同期処理に関しては、公式ライブラリ群との噛み合わせを含めてKotlinコルーチンが実質標準です。

相互運用100%の実際—KotlinとJava混在プロジェクトの運び方

KotlinはJavaとの100%相互運用を設計目標にしており、KotlinクラスからJavaクラスを呼ぶことも、その逆も追加の仕掛けなしにできます。既存ライブラリもJava製のものがそのまま使える設計です。この性質があるため、Javaで書かれた既存アプリのKotlin化は「全面書き換え」ではなく、次の段階移行が現実的な進め方になります。

1. 新規に追加するクラス・画面をKotlinで書く
2. 改修頻度の高いクラスから順にKotlinへ変換する（Android Studioに変換機能あり）
3. 変更が入らない安定部分はJavaのまま残す

変換機能の出力は動くコードにはなるものの、null許容の扱いなどKotlinらしい書き直しは人手で仕上げる必要があります。移行対象を「これから触るコード」に限定し、触らないコードを変換しないことが、移行コストを膨らませない線引きです。

開発環境と周辺技術の前提—Android StudioとJetpack Compose

言語の議論は開発環境とセットで決まります。どちらの言語を選んでも使う道具は共通で、その道具側がKotlinへ寄っている状況を確認します。

Android Studio 2026.1系で揃える開発環境の標準構成

Androidアプリ開発の公式IDEはAndroid Studioで、KotlinでもJavaでも開発環境はこれ一択です。JetBrainsのIntelliJ IDEAを基盤とし、エミュレータ・デバッガ・プロファイラ・ビルド（Gradle）までを1つに束ねています。リリースは動物名のコードネームで継続しており、2026年7月時点の最新安定版は2026.1系です。Kotlinプラグインは同梱のため、言語側の追加セットアップは不要です。インストール手順や各機能の使い方はAndroid Studioのできること・使い方・インストール手順の解説で別途整理しています。

束ねて見ると「言語＝Kotlin/Java、IDE＝Android Studio、ビルド＝Gradle」が標準構成で、ここに選択の分岐はほぼありません。選定の論点は言語とUIツールキットに集約されます。

Jetpack ComposeがKotlin専用である事実が選定に与える影響

UIの作り方は現在2系統あります。XMLレイアウトによる従来方式（View）と、Kotlinコードで宣言的にUIを書くJetpack Composeです。GoogleはComposeを新規開発の推奨としており、そしてComposeはKotlinのコンパイラプラグインとして実装されているため、Javaでは書けません。

これが言語選定に与える影響は決定的です。Javaを選ぶことは、UIを従来のXML方式に固定することと同義になります。XML方式が直ちに廃止されるわけではないものの、新しいUI部品・公式サンプル・周辺ライブラリの供給はCompose側へ移っており、Javaを選ぶ場合は「今後のUI技術の主流から外れた構成を保守し続ける」前提を織り込む必要があります。

Kotlin MultiplatformとFlutter—複数OS要件がある場合の分岐

iOSも同時に必要な案件では、Androidネイティブ（Kotlin）単独ではなく、クロスプラットフォーム技術との比較になります。候補は大きく、Kotlinのコードを複数OSで共有するKotlin Multiplatform、Dart言語のFlutter、JavaScriptのReact Nativeです。Kotlin Multiplatformはビジネスロジックを共有しつつUIは各OSネイティブで作る構成を取れるのが特徴で、仕組みと導入判断はKotlin Multiplatformの利点と特徴の解説で詳しく扱っています。

分岐の目安は要件の重心です。Android単独、または端末機能・性能要件が強いならKotlinネイティブ、両OSへ同一UIを速く出すことが優先ならFlutter等のクロスプラットフォーム、Androidを軸にしつつロジックだけiOSと共有したいならKotlin Multiplatformが検討線に乗ります。ここでもKotlinを選んでおけば、後からMultiplatformへ広げる選択肢が残ります。

受託開発の現場基準で決める言語選定—Kotlinを選ばない場面の明示

ここまでの事実を、実際の案件でどう判断に落とすかを示します。当社が受託開発で使っている線引きをそのまま書きます。

新規開発でKotlinを既定にする採用条件と保守性・採用面の効果

新規案件では、発注側から特段の指定がない限りKotlin＋Jetpack Composeを既定にします。理由は3つです。公式推奨と一致するため将来のOS・ライブラリ更新への追従コストが読めること、null安全と簡潔な記述が長期保守のバグ・レビュー工数を下げること、そして開発者の採用市場でもAndroid経験者の主流がKotlinへ移っており、体制を組みやすいことです。

逆に「Kotlinにしない条件」を挙げるほうが早く、それは次項のJava資産条件に該当する場合だけです。新規でJavaを指定する積極的な理由は、2026年7月時点では見当たりません。

あえてJavaを維持する判断が成立する既存資産と開発体制の条件

Java維持が合理的なのは、条件が揃った場合に限られます。具体的には、稼働中のJava製アプリへの改修が小規模・低頻度で今後の機能拡張予定が薄い場合、保守要員がJava経験者で固定されておりKotlin習得の時間を取れない場合、あるいは社内の他システムとコード規約・レビュー体制をJavaで共通化している場合です。このどれかに該当するなら、動いている資産を書き換えるリスクとコストのほうが高くつきます。

注意すべき失敗パターンは「新機能開発が続くアプリをJavaのまま引っ張る」ことです。改修が続くコードは触る頻度が高い分、null安全や記述量の差が毎回の工数に累積します。機能追加のロードマップがあるなら、前述の段階移行で新規部分からKotlin化を始めるのが妥当で、全面移行かJava凍結かの二択で考えないことが判断の要点です。

言語選定の先にある開発費用と外注判断—内製と受託の切り分け基準

言語選定は費用と体制の議論につながります。KotlinとJavaで開発単価に大きな差はなく、費用を左右するのは画面数・API連携・対応OSといった要件側です。相場観はアプリ開発の費用相場の内訳と抑え方の解説に発注者視点でまとめているため、予算化の段階ではそちらが参考になります。

内製か外注かは、Android開発を続ける体制を自社で維持できるかで切り分けます。OSの年次更新・ストア審査・ライブラリ更新への追従は継続的に発生するため、単発の開発だけでなく運用フェーズの体制まで見て判断すべきです。株式会社一創ではAndroidアプリ開発をKotlinとJetpack Composeを軸に受託しており、要件定義からGoogle Play公開・公開後の改善まで一貫して請け負っています。既存JavaアプリのKotlin移行を含む相談にも、この記事の線引きをベースに対応できます。

よくある質問

Androidアプリ開発の言語選定で実務からよく挙がる質問をまとめます。回答は2026年7月時点の情報に基づきます。

AndroidアプリはいまでもJavaだけで開発できますか？

できます。GoogleはJavaコードのサポート継続を明言しており、Javaのみで書かれたアプリのビルド・公開は現在も可能です。ただしJetpack ComposeはKotlin専用のため、UIは従来のXML方式に限定されます。公式ドキュメントやサンプルの多くがKotlin前提になっているため、新規情報の入手コストが年々上がる点は織り込んでおくべきです。

既存のJavaコードをKotlinへ移行する方法はありますか？

Android StudioにJavaファイルをKotlinへ変換する機能が標準搭載されています。変換後のコードはそのまま動作しますが、null許容型の扱いなどはJavaの構造を引きずるため、Kotlinらしい形への手直しは人手による仕上げが前提です。実務では全面変換ではなく、改修頻度の高いクラスや新規クラスから段階的にKotlin化し、安定稼働している部分はJavaのまま残す進め方を推奨します。

Java経験者がKotlinを習得するコストはどの程度ですか？

両言語は文法思想が近く、Java経験者なら基本文法の習得は短期間で済みます。実際の学習の山は言語文法よりも、null安全の設計への馴染み、コルーチンによる非同期設計、Composeの宣言的UIという「書き方の転換」です。既存プロジェクトの改修をKotlinで書くところから始めると、動く実例を参照しながら転換でき、習得が早く進みます。

KotlinはAndroid以外の開発でも使えますか？

使えます。KotlinはJVM上で動く汎用言語で、Spring Framework等によるサーバーサイド開発でも採用例が多い言語です。Kotlin Multiplatformを使えばiOSやデスクトップとビジネスロジックを共有する構成も組めます。Androidのために習得したKotlinがモバイル以外へ広げられる点は、技術投資の回収先が多いという意味で選定の追い風になります。

FlutterやReact NativeではなくKotlinを選ぶ基準はありますか？

Android単独の開発なら、公式推奨と情報量の面でKotlin一択です。iOSも必要な場合は、端末機能・性能・OS標準UIへの密着度が求められる案件はKotlin（＋必要ならKotlin Multiplatform）、両OSへ同一UIを短期間で展開したい案件はFlutter等のクロスプラットフォームが候補になります。判断の軸は「OSごとの作り込みがどれだけ要るか」に置くと整理しやすくなります。

関連記事

• リフレクションとは？実行時にクラス情報を操る仕組みを言語横断で解説：JavaとKotlinに共通する実行時機構を理解する際の前提知識です。
• RevenueCatとは？アプリ内課金・サブスク実装を1SDKで担う仕組みと導入判断【実装者向け】：Androidアプリに課金機能を組み込む段階で検討する周辺技術です。
• LINEミニアプリとは？仕組み・LIFFとの違い・開発費用から導入判断まで解説：ネイティブアプリを作らずに要件を満たす選択肢との比較に使えます。