接続切断 — よくある原因と解決方法

モバイルアプリにおける“接続切断”の意味

接続切断 — アプリがサーバーとの接続を失い、操作に応答しなくなったり、エラーで終了したりする状況を表すユーザー用語です。技術的には、ネットワークエラー（タイムアウト、DNS障害）、ANR（UIスレッドのフリーズ）、クラッシュ（未処理の例外）、またはレースコンディションが考えられます。

ユーザーの視点からは、これらのシナリオはすべて同じに見えます：アプリが動作を停止します。開発者にとっての違いは、診断と修正のアプローチにあります。ネットワークエラーはリトライメカニズムで解決され、ANRはUIスレッドから操作を移すことで、クラッシュは例外処理で対処します。

Crittercism（現Apteligent）によると、モバイルアプリはクラッシュのたびに平均1〜2%のユーザーを失います。100万ユーザーのアプリの場合、1つのバグあたり1万〜2万のインストール損失になります。これは特に金融および医療セクターのアプリにとって重要です。

接続喪失の主な原因

不安定なネットワーク — モバイルデバイスは常にWi-Fiとモバイルネットワークを切り替え、圏外エリア（地下鉄、エレベーター、地下室）に入ります。切り替えのたびに一時的な接続喪失が発生し、アプリは適切に処理する必要があります。

タイムアウト — サーバーが設定されたタイムアウト（通常10〜30秒）内に応答しない場合、クライアントはSocketTimeoutExceptionをスローします。フィードバックのない長時間のタイムアウトは、ユーザーにはフリーズとして認識されます。タイムアウトは15秒以内に設定することをお勧めします。

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

レースコンディション — 複数のスレッドが同期なしに同じデータを同時に読み書きするときに発生します。例えば、UIスレッドでキャッシュからデータを読み込みながらネットワークからキャッシュを更新すると、古いデータや不正確なデータが表示される可能性があります。

• 未処理の例外がコールバックやコルーチン内で発生するとアプリがクラッシュする
• メモリプレッシャー — フォアグラウンドアプリに十分なメモリがない場合、システムがアプリを強制終了する
• ライフサイクルレース — Activity/Fragmentが破棄された後に非同期操作が完了する
• UIブロッキング — メインスレッドでネットワークやデータベース操作を行うと5秒後にANRが発生する

耐障害性アプリケーションのためのアーキテクチャ

Offline-first — ローカルストレージ（Room、CoreData）を唯一の信頼できる情報源とするアーキテクチャパターンです。ネットワークはバックグラウンドでのデータ同期に使用されます。ユーザーはネットワーク接続がなくても、ローカルキャッシュから常に最新のデータを表示できます。

Repositoryパターン — ネットワークからデータを取得するかキャッシュから取得するかを決定する、データの単一エントリポイントです。リポジトリはViewModelやUIからデータソースを抽象化します。ネットワークエラー時には、リポジトリは自動的にローカルソースに切り替わります。

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // return cache on network error
            } else {
                Result.failure(e)
            }
        }
    }
}

サーキットブレーカー — サーバーが利用不可のときにリクエストの殺到から保護するパターンです。N回連続でエラーが発生するとサーキットブレーカーが開き、すべてのリクエストは接続を試みずに即座にエラーを返します。指定されたタイムアウト後、サーキットブレーカーはテストリクエストのために半開き状態に移行します。

ネットワークエラーの対処方法

指数バックオフ — 標準的なリトライメカニズムです。最初の失敗後は1秒待ち、2回目は2秒、その後4、8、16秒と待ちます。サーバーとバッテリーに過負荷をかけないよう、最大リトライ回数（通常3〜5回）を制限してください。

ユーザーフィードバック — ネットワークエラー時には、明確なメッセージを表示します：“接続がありません”、“サーバーが一時的に利用できません”、“インターネット接続を確認してください”。SnackbarやInline State Viewを使用します。絶対に技術的なエラー（HTTP 500、SocketException）をユーザーに表示しないでください。

ConnectivityManager — ネットワーク監視のためのAndroid APIです。アプリが変更に反応できるようにします：接続喪失時にプレースホルダーを表示し、復旧時に自動的にデータを更新します。iOSではNetworkフレームワークのNWPathMonitorを使用します。

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

監視とロギングのツール

Crashlytics（Firebase）— モバイルアプリ向けの標準的なクラッシュレポートツールです。すべての未処理例外のスタックトレース、OSバージョン、デバイスモデル、クラッシュ時刻を収集します。エラーをグループ化し、修正責任者を割り当てることができます。

Sentry — パフォーマンス監視をサポートするCrashlyticsの代替ツールです。特定のトランザクション（例：“ユーザー認証”）をトレースし、どのステップでエラーが発生したかを確認できます。パフォーマンストレーシングは、ネットワークタイムアウトとアプリロジックのバグを区別するのに役立ちます。

Timber — クラスごとに自動的にタグを追加するAndroid用ロギングライブラリです。デバッグビルドではすべてのネットワークリクエストとレスポンスをログに記録します。リリースビルドでは、Crashlytics.setCustomLogを介してエラーと警告のみをログに記録します。

Firebase Summit 2023によると、Crashlytics + Performance Monitoringを実装したアプリは、重大なバグの検出と修正にかかる平均時間を3日から4時間に短縮しました。アクティブユーザーの0.1%を超える頻度のクラッシュごとにアラートを設定することをお勧めします。