[Android] XML と JSON、どちらを選ぶべきか？Android 開発における使い分けガイド

Android 開発で「このデータ、XML にすべきか JSON にすべきか？」と迷う場面は意外と多いものです。レイアウトやリソースは XML、API 通信は JSON、という大まかな棲み分けはあるものの、設定ファイルや中間データの保存など、どちらでも実装できるケースでは選択に悩むことがあります。

この記事では、Android 開発における XML と JSON の使い分けを、実際のユースケース別に具体的なコードとともに整理します。結論を先に言うと、Android プラットフォームが要求する場所は XML、それ以外は原則 JSONというのが 2026 年時点での実用的な指針です。

両者の特徴を 1 分で整理
1. XML の特徴
2. JSON の特徴
ユースケース別の使い分け
パフォーマンスの観点
1. パースの速さ
2. データサイズ
シリアライズライブラリの選び方
デバッグでの使い分け
迷ったときの判断フロー
まとめ

両者の特徴を 1 分で整理

まずは簡潔に両者の違いを押さえておきます。

XML の特徴

タグベースで階層構造を表現。属性とテキストノードを併用できる
スキーマ（XSD）やバリデーションの仕組みが豊富
コメントやネームスペースなど、メタ情報を持たせやすい
Android プラットフォーム（レイアウト、Manifest、リソース）で標準採用
記述量が多くなりがち

JSON の特徴

キー・値のシンプルな構造。配列とオブジェクトで十分な表現力
JavaScript・REST API のデファクトスタンダード
記述量が少なく、パースが速い
コメントや属性の概念がない
Kotlin/Android でのライブラリ（kotlinx.serialization、Moshi、Gson）が充実

ユースケース別の使い分け

1. UI レイアウト → XML 一択

View システムの Android では、レイアウト定義は XML 以外の選択肢が実質ありません。res/layout/ 配下に XML を配置する前提でツール群（Layout Editor、Lint、リソース ID の自動生成）が組まれているため、ここを外れるメリットはほぼゼロです。

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:orientation="vertical">
 
    <TextView
        android:id="@+id/title"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="@string/app_name" />
</LinearLayout>

逆に言うと、「UI を JSON で書きたい」という発想は Android では基本不要です。動的に UI を構築する特殊なユースケース（サーバー駆動 UI など）を除き、XML のまま扱うのがエコシステムに沿った形です。

2. Manifest・リソース・設定（preferences.xml など） → XML

これも Android プラットフォームが XML を要求するので選択の余地はありません。AndroidManifest.xml、strings.xml、colors.xml、network_security_config.xml、backup_rules.xml、PreferenceScreen の XML など、すべて XML です。

XML の属性順序が変わっただけで「差分が出たように見える」ことがあります。これはコードレビューでノイズになりがちなので、XML フォーマッター・差分比較ツール の「属性をソートして比較」オプションが役立ちます。意味的な差分だけを抽出できるので、マージ衝突の解消やレビュー時の確認が楽になります。

3. API 通信（ネットワーク層） → JSON 一択

REST API との通信は JSON が事実上の標準です。Retrofit + kotlinx.serialization（または Moshi）の組み合わせが 2026 年時点の標準的な構成です。

import kotlinx.serialization.Serializable
 
@Serializable
data class User(
    val id: Long,
    val name: String,
    val email: String
)

import retrofit2.Retrofit
import retrofit2.converter.kotlinx.serialization.asConverterFactory
import kotlinx.serialization.json.Json
import okhttp3.MediaType.Companion.toMediaType
 
private val json = Json { ignoreUnknownKeys = true }
 
val retrofit = Retrofit.Builder()
    .baseUrl("https://api.example.com/")
    .addConverterFactory(json.asConverterFactory("application/json".toMediaType()))
    .build()
 
interface ApiService {
    @GET("users/{id}")
    suspend fun getUser(@Path("id") id: Long): User
}

XML ベースの API（SOAP や一部のレガシーサービス）にどうしても接続する必要がある場合は Simple XML や Jackson XML で対応できますが、新規プロジェクトで能動的に XML API を選ぶ理由はほぼないと考えてよいでしょう。

4. ローカルデータの保存 → ほぼ JSON

アプリ内で「ちょっとしたデータ」を永続化するケース（キャッシュ、ユーザー設定、下書きなど）では JSON が有利です。理由は主に 3 つです。

サイズが小さい（特にモバイルでは地味に重要）
API レスポンスをそのままキャッシュできる（シリアライザを 1 種類で済ませられる）
DataStore（Preferences DataStore / Proto DataStore）と親和性がある

import kotlinx.serialization.encodeToString
import kotlinx.serialization.json.Json
 
private val json = Json { prettyPrint = false }
 
// 書き込み
fun saveUser(user: User, file: File) {
    file.writeText(json.encodeToString(user))
}
 
// 読み込み
fun loadUser(file: File): User {
    return json.decodeFromString(file.readText())
}

ただし SharedPreferences / PreferenceScreen 経由の設定 は XML に落ちるので、「ユーザー設定画面の項目定義」部分だけは XML になります。

5. Gradle 設定 → Kotlin DSL（どちらでもない）

ついでに触れておくと、ビルド設定は現在 Kotlin DSL（build.gradle.kts）が推奨されています。かつての Groovy DSL（build.gradle）から移行が進んでおり、型安全性とコード補完の恩恵を受けられます。XML でも JSON でもないので注意してください。

パフォーマンスの観点

細かい話ですが、実務で差が出るポイントです。

パースの速さ

一般に JSON の方が XML より高速にパースできます。タグの開始・終了の対応関係を追う必要がないぶん、ステートマシンがシンプルだからです。ただしモバイルアプリで扱う数 KB〜数百 KB のデータ程度であれば、体感差はほぼゼロです。マイクロ最適化より可読性・保守性を優先すべきレベルの差です。

データサイズ

同じ内容を表現する場合、JSON の方が一般的に 20〜40% 小さくなります。属性と閉じタグがない分、冗長性が減るためです。

<!-- XML（約140バイト） -->
<user id="1">
    <name>Alice</name>
    <email>alice@example.com</email>
    <role>admin</role>
</user>

// JSON（約90バイト）
{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin"
}

API レスポンスで大量のリストを返す場合、この差は通信量に直接効いてきます。ユーザーのデータ通信量に配慮するなら、やはり JSON を選ぶのが妥当です。

シリアライズライブラリの選び方

Kotlin/Android で JSON を扱う場合、主な選択肢は以下の 3 つです。

kotlinx.serialization：Kotlin 公式。Kotlin の言語機能（data class、null 安全、デフォルト値）と統合されていて、新規プロジェクトの第一候補。
Moshi：Square 製。Kotlin サポートあり、Retrofit との相性が良好。
Gson：Google 製。枯れている。ただし新規プロジェクトで積極的に選ぶ理由は薄くなってきている。

新規で Android/Kotlin プロジェクトを始めるなら、kotlinx.serialization が 2026 年時点では第一候補です。既存プロジェクトで Gson を使っている場合、動いているなら無理に移行する必要はありません。

XML のシリアライズは Retrofit + Jackson XML、または Simple XML を使う程度ですが、新規で XML API を扱うケース自体が少ないため、選定で悩むことは稀です。

デバッグでの使い分け

開発中、Logcat や設定ファイルで生の XML / JSON を目視で確認する場面は頻出します。どちらの形式でも、「整形して差分比較する」ワークフローを普段の開発に組み込んでおくとデバッグ時間が短縮できます。

API レスポンスの差分確認 → JSON フォーマッター・差分比較ツール
AndroidManifest.xml やレイアウト XML の差分確認 → XML フォーマッター・差分比較ツール

どちらもブラウザ内で処理が完結するため、API キーやユーザー情報を含むデータを外部サーバーに送信せずに済みます。Logcat の JSON 整形については [Android] Logcat に出る長大な JSON を読みやすくする 3 つの方法でも詳しく紹介しています。

迷ったときの判断フロー

最後に、実務で迷ったときに使えるシンプルなフローチャートを示します。

Android プラットフォームが XML を要求する？（レイアウト、Manifest、resources） → YES なら XML 一択。
外部 API との通信？ → JSON（相手が XML API なら仕方なく XML）。
ローカル保存？ → JSON（DataStore と組み合わせるのが一般的）。
人間が手で編集する可能性がある？ → コメントが必要なら XML、シンプルさ優先なら JSON。
上記以外 → JSON を選んでおけばだいたい正解。

まとめ

Android 開発における XML と JSON の使い分けを整理しました。

UI レイアウト・Manifest・リソースは XML（Android プラットフォームの要求）
API 通信・ローカル保存は JSON（サイズ・速度・エコシステム）
新規プロジェクトのシリアライザは kotlinx.serialization が第一候補
デバッグ時は整形・差分比較ツールを日常的に使うと効率が上がる

どちらか一方を極端に避けるのではなく、「プラットフォームと周辺ツールが要求する場所では XML、それ以外は JSON」と切り分けると、選択で悩む時間が減ります。両方の形式を扱えるツールを手元に揃えておくと、どちらが来ても焦らず対応できます。