通信

アプリの通信の不具合は、開発中の安定した Wi‑Fi ではほとんど再現しません。ところが利用者の多くは移動中に使うので、「固まる」「二重に注文された」といったレビューや問い合わせは、回線が不安定なときの作りの甘さから来ることがよくあります。

ここでは、待つ時間・やり直し方・待っている間の見せ方を、最初に決めておくことを押さえます。

スマホの回線は、電車・地下・エレベーター・Wi-Fi と 4G/5G の切り替わりで、切れたり極端に遅くなったりします。「通信は失敗するもの」として作るのが前提です。

通信を待つ間・失敗したときに画面に何を見せるかは、次の回線が悪くても使える画面にする（キャッシュを先に見せる）で説明します。

（SRE）リトライの設計

（SRE）HTTP/1.1・HTTP/2・HTTP/3 の比較

下の「ブラウザで試す」の図では、電車の中で注文を送り、サーバーは処理したのに返事が途中で消える場面から始まります。アプリは1秒・2秒・4秒と待ち時間を倍にし、ランダムなずれ（ジッター）を足してやり直し（指数バックオフ）、同じ冪等キーで送り直すので、サーバーは注文を作り直さずに前回の結果を返します。上の表の「再試行は安全なものだけ」「待ってから再試行」が、どの手順にあたるかを見てください。

回線が悪いときに「読み込み中」のまま待たせたり、エラーで画面を空にしたりすると、使えないアプリに見えます。前回取ったデータを端末に保存しておき、まずそれを見せて、裏で新しいデータを取り直すのが基本の対策です（Web の stale-while-revalidate と同じ考え方）。

キャッシュを見せてはいけないもの・気をつけること

• ログアウト・アカウントの切り替えのときは、前の人のキャッシュを必ず消す（他人のデータが見える事故）
• 決済・在庫・予約の確定など、古い値で判断すると困る操作は、操作の直前にサーバーで確かめる
• 個人情報を端末に保存するなら、端末の暗号化と保存の期間を決める
• キャッシュの形（スキーマ）は、アプリの版が上がっても読めるようにする（古い版のデータの移行）

まとめると、「通信は失敗するもの」と考えて、タイムアウト・再試行（不安定な回線への対策）＋ キャッシュを先に見せる ＋ 送信待ちのキューを組み合わせます。

再試行の間隔の決め方です。たくさんの端末が同じサーバーを使うアプリでは、再試行のやり方しだいで、障害を長引かせてしまいます。

失敗したらすぐ再試行するのではなく、待つ時間を 1秒・2秒・4秒・8秒…と倍にしていきます（指数バックオフ）。さらに待つ時間をランダムにずらします（ジッター）。ずらさないと、障害から戻った瞬間に何万台もの端末が同じタイミングで一斉に再試行し、サーバーをまた倒してしまいます。

待つ時間 = random(0, min(上限, 基準 × 2^回数))
例：基準 1秒・上限 30秒・最大 5回で諦めて「再試行」ボタンを出す

サーバーが 429 や 503 に Retry-After を付けてきたら、その時間を優先して待ちます。

HTTP/3 は、スマホのように回線が切り替わる環境で特に効く新しい HTTP です。

HTTP/3 は TCP ではなく UDP の上の QUIC で動きます。モバイルで効くのは次の点です。

• 回線が変わってもつながったまま：TCP は IP アドレスが変わると接続が切れますが、QUIC は接続 ID で相手を見分けるので、Wi-Fi から 4G に変わっても続けられます（コネクションマイグレーション）。
• 接続が速い：暗号化の準備（TLS 1.3）と接続を一緒に行うので、往復が少なくて済みます。
• 1つの取りこぼしで全体が止まらない：TCP では1つのパケットの再送待ちで同じ接続の全部が止まりますが、QUIC は流れごとに独立しています。

iOS の URLSession は、サーバーが HTTP/3 に対応していれば自動で使います。Android でよく使う OkHttp は単体では HTTP/3 を使わないので、使うなら Cronet（OkHttp から Cronet を使うための橋渡しのライブラリもある）を選びます。ただし UDP が通らない回線もあるので、HTTP/2 に戻れる前提です。

アプリの通信は、iOS では URLSession、Android では OkHttp（その上に Retrofit や Ktor）を使うのが一般的です。大事なのは、クライアントをアプリで1つにして使い回すことと、共通の処理を1か所に置くことです。

クライアントを API ごとに作ると、接続の使い回し（コネクションプール）が効かず、毎回 TLS の接続からやり直しになって遅くなります。ログを出すときは、トークンや個人情報が残らないよう、リリース版では出さないか、伏せ字にします。

同じ API を何度も呼ぶアプリでは、HTTP のキャッシュの仕組みを使うと通信量と待ち時間を減らせます。サーバーが返すヘッダーで、取っておいてよいか、どれだけ使ってよいかが決まります。

iOS の URLSession は URLCache、Android の OkHttp は Cache を設定すると、これらのヘッダーに従って自動でキャッシュします。ただし、ログイン中の人ごとに違う結果を共有のキャッシュに入れないよう、サーバー側の設定（private など）も一緒に確かめます。オフラインで見せたいデータは、HTTP のキャッシュではなく DB に保存します。

一覧を少しずつ取るページ送りには、オフセット方式とカーソル方式があります。フィードやチャットのように新しい項目が次々増える一覧では、カーソル方式を選びます。

アプリ側では、スクロールの終わりが近づいたら（残り数件で）次を取りにいき、同じカーソルで二重に取りにいかないよう、取得中は次の要求を止めます。新しい項目は「上に引っ張って更新」で先頭側を取り、受け取った項目は ID で重複を消してから一覧に入れます。Android なら Paging ライブラリが、この流れと DB との組み合わせ（RemoteMediator）を用意しています。

アプリは更新されない古い版が何年も残るので、API は「今の版」だけでなく「過去に出したすべての版」から呼ばれます。サーバーの変更で古いアプリが落ちないようにするのが、アプリと API の付き合い方の基本です。

バージョンごとの挙動

• 足すのはよい、消す・変えるはだめ：項目を増やすのは安全ですが、名前や型を変える、必須の項目を消すと古い版が壊れます。どうしても変えるなら新しい項目を足し、古い項目は使われなくなるまで残します。
• アプリ側は知らない項目を無視する：Kotlin の kotlinx.serialization は ignoreUnknownKeys = true にしておきます。Swift の Codable は知らない項目は無視しますが、知らない enum の値が来ると解析ごと失敗するので、「不明」の値を用意して受け止めます。
• アプリの版を送る：ヘッダー（User-Agent や X-App-Version など）でアプリの版と OS を送ると、サーバーは版ごとに返す内容を変えられ、どの版がまだ使われているかも分かります。

それでも古い版を動かせないときは、強制アップデートで更新してもらいます（次の章で説明）。

Feature Flag と強制アップデート

アプリから呼ぶ API の形にもいくつかの選び方があります。アプリならではの視点は、通信の往復の回数と量、そして古い版が残っても変えやすいかです。

どの形でも、アプリ側ではAPI のモデルと画面のモデルを分けて変換します。API の形が変わっても、変換の部分を直すだけで画面のコードは変わりません。

チャットやライブの配信のように、サーバーからすぐ知らせたいときの方式です。アプリでは、開いている間と裏に回っている間で使える方式が違うのがポイントです。

アプリが裏に回ると接続は OS に切られるので、戻ってきたら再接続し、切れていた間の差分を取り直す作りにします。再接続は指数バックオフで間をあけ、受け取ったメッセージは ID で重複を消します。WebSocket で受け取ったものだけを頼りにせず、DB と差分の同期を正にするのが安全です。

アプリから直接 Redis につなぐことはありませんが、API サーバーの裏側でよく使われています。概要を知っておくと、サーバー側のエンジニアとの会話や、不具合の切り分けが速くなります。

アプリ側では、古いデータが返ることがある前提で表示を作り（引っ張って更新・最終更新時刻）、429 や 503 には待ってから再試行（指数バックオフ）で応えます。

アプリの通信は、OS の設定で「暗号化されていない通信を禁止する」のが基本です。iOS と Android でそれぞれ仕組みがあります。

開発中にプロキシで通信を見たいときは、Android ならデバッグ版だけで利用者の証明書を信頼する設定（debug-overrides）を使い、リリース版に例外を残さないようにします。

（SRE）暗号と証明書

OS の標準の検証より一段強い守りが、証明書のピン留めです。強い反面、運用を誤るとアプリが一切通信できなくなるので、入れるかどうかを慎重に決めます。

ピン留めは、「この公開鍵を持つ証明書の相手とだけ話す」とアプリに決めておく方法です。不正な証明書を使った盗聴（中間者攻撃）への守りが強くなります。iOS は Info.plist の NSPinnedDomains、Android は Network Security Config の <pin-set> で書けます。

ただし、サーバーの証明書を変えたときにピンが合わないと、古い版のアプリが一切通信できなくなる危険があります。入れるなら、証明書そのものではなく公開鍵を留め、予備の鍵を必ず一緒に入れ、Android では期限（expiration）を付けます。銀行など特に守りたいアプリ以外では、OS の標準の検証だけで十分なことも多いです。