ケイパビリティ
モバイルアプリケーションは、チームが任意のタイミングで再デプロイできない、長寿命のクライアントです。断続的なネットワーク上で動作し、OSによって予告なく終了させられ、古いバージョンのまま何か月もインストールされ続けます。私たちはこうした事実を前提に、アプリケーション、API、リリースパイプラインを設計します。
モバイルエンジニアリングは、構造的に3つの点でWebエンジニアリングと異なります。ネットワークは断続的であるため、アプリケーションは通信がなくても役に立ち、回復したときに整合を取らなければなりません。プロセスのライフサイクルはOSが制御し、メモリとバッテリーを守るためにアプリケーションをサスペンドまたは終了させます。リリースはストア審査を経たうえでユーザーによるアップデートに依存するため、常に複数のバージョンが使われており、不具合を再デプロイで取り下げることはできません。
こうした制約は、クライアントだけでなくシステム全体の形を決めます。APIは何か月も前に出荷されたバージョンとの互換性を保ち、ペイロードは従量制の回線に適したものでなければならず、認証はアプリケーションがバックグラウンドにある間にトークンが失効しても破綻しないようにする必要があります。端末上では、認証情報はハードウェアに裏付けられたストレージに保管し、ローカルデータにはあらゆるデータベースと同様にスキーマとマイグレーションが必要で、起動時間、フレームレート、メモリ、消費電力は計測すべき特性です。
私たちは、iOSではSwiftとSwiftUI、AndroidではKotlinとJetpack Composeで開発し、コードベースの共有が有利なトレードオフとなる場合はFlutterまたはReact Nativeを用います。どれを選ぶかはプロダクトの要件とチーム構成に基づいて判断し、バックエンドとのコントラクト、オフラインモデル、リリースプロセスは最初の画面と並行して設計します。
エンジニアリング領域
ネイティブ開発では、すべてのプラットフォームAPIをすぐに利用でき、起動とレンダリングの特性が最も優れ、プラットフォーム標準の挙動が得られますが、コードベースが2つになります。Flutterは独自のエンジンで独自のウィジェットを描画し、プラットフォーム間で高い視覚的一貫性を実現します。React NativeはJavaScriptまたはTypeScriptからネイティブビューを駆動し、Webチームとスキルを共有できます。いずれも、一部の連携にはネイティブコードが必要です。
オフラインファーストの設計では、UIはローカルデータベースに対して読み書きを行い、同期エンジンがバックグラウンドでサーバーとの整合を取ります。ローカルでの書き込みは冪等性キー付きのミューテーションとしてキューに積み、接続が回復したときに順番にリプレイします。コンフリクトの扱いはエンティティごとに定義します。メモに適したルールが、決済に適したルールであるとは限らないためです。
シークレットはiOSのKeychainとAndroidのKeystoreに保管し、端末が対応している場合は、鍵をSecure EnclaveまたはStrongBoxに裏付けられたセキュアエレメント内で生成します。生体認証は、ハードウェアが保持する鍵の使用を制御します。つまり、照合の成功は、改ざんされたアプリケーションが回避できてしまう真偽値を返すのではなく、暗号処理の実行を許可します。サインインには、システムブラウザを介したPKCE付きのOAuth 2.0認可コードフローを用います。
BFF（Backend for Frontend）はレスポンスを画面に合わせて整形し、高レイテンシなネットワークでの往復回数を減らします。APNsとFCMによるプッシュ通知はベストエフォートであるため、状態を取得するきっかけとして扱い、状態そのものを運ぶ手段としては決して扱いません。Universal LinksとAndroid App Linksは、検証済みドメインでホストするファイルを通じてURLをアプリケーションに紐づけるため、別のアプリケーションがそのURLを横取りすることを防げます。
パフォーマンス改善の対象は、コールドスタート、フレームペーシング、メモリ、消費電力です。1フレームは60 Hzで約16.7ミリ秒、120 Hzで約8.3ミリ秒以内に生成する必要があるため、処理はメインスレッドの外で行い、リストは仮想化します。クラッシュとハングのレポートは、アップロードしたdSYMとR8のマッピングファイルでシンボリケートし、リリースごとのクラッシュフリーセッション率として追跡します。
モバイルのパイプラインは、クリーンなマシンから再現可能な形でビルド、署名、テスト、配布を行い、署名用のIDはシークレットストアで保持し、個人のノートPCには決して置きません。ビルドは、内部テスト、TestFlight、Playのテストトラックを経て、App Storeの段階的リリースまたはGoogle Playの段階的公開へ進みます。クラッシュ率やANR率が悪化した場合は、自動または手動でロールアウトを停止します。
モバイルクライアントは、エッジ層を通じてバックエンドに到達します。まずCDNとWebアプリケーションファイアウォール、次にAPIゲートウェイがあり、ゲートウェイはTLSを終端し、トークンを検証し、端末単位・ユーザー単位のレート制限を適用し、リクエストをルーティングします。ゲートウェイの背後では、BFFがKubernetesまたはサーバーレス基盤上で動くドメインサービスへの呼び出しを集約し、画面に合わせて整形した1つのレスポンスを返します。これにより、呼び出し回数の多いオーケストレーションは、1回の呼び出しが1ミリ秒で済むデータセンター内にとどまり、数百ミリ秒かかるモバイルネットワーク上には出てきません。
アイデンティティはOpenID Connectを通じて流れます。アプリケーションはシステムブラウザを開き、PKCE付きの認可コードフローを完了して、有効期間の短いアクセストークンとローテーションされるリフレッシュトークンを受け取り、KeychainまたはKeystoreに保管します。ゲートウェイはトークンの署名を検証し、検証済みのクレームを下流に渡します。各サービスは、そのクレームに照らしてリクエストごとに認可を行います。App AttestやPlay Integrityによるアテステーションは、呼び出し元が改変されていない正規のビルドであることを示すシグナルとして追加できます。高リスクの操作には有用ですが、サーバー側の認可の代わりには決してなりません。
サーバー側で発生した状態変化は、3つの経路で端末に届きます。APNsとFCMによるプッシュ通知は、アプリケーションを起こすかユーザーに知らせ、データの取得を促します。WebSocketまたはServer-Sent Eventsの接続は、アプリケーションがフォアグラウンドにある間にライブ更新を運び、OSの制限に従ってバックグラウンドでは切断します。起動時と復帰時の差分同期がすべての欠落を埋めるため、プッシュ通知が届くかどうかに正しさが依存することはありません。サーバー側では、これらは他のコンシューマーを駆動するのと同じイベントストリームから供給され、通知サービスがイベントをデバイストークンへファンアウトします。
アーキテクチャ
モバイルアプリ
エッジ
BFF / モバイルAPI
可能な限り1画面を1往復で取得
サービス
データ・通知
オブザーバビリティ
オフライン対応には段階があります。読み取りキャッシュは、接続がなくても最後に取得したデータを表示するもので、低コストです。書き込みのキューイングは、ユーザーがオフラインでも操作できるようにするもので、順序付きのアウトボックス、冪等なサーバーエンドポイント、目に見える保留状態が必要です。ローカルデータベースをUIにとっての信頼できる情報源とし、双方向に同期する完全なオフラインファーストは、最も高機能であると同時に最も複雑です。フィールドサービス、物流、点検のように、ユーザーが長時間にわたり圏外で作業する場合に選ぶべきものです。
コンフリクトは、同期と同期の間に、同じレコードが2台の端末で、あるいは端末とサーバーの双方で変更されたときに発生します。サーバーのタイムスタンプによるLast-Write-Winsはシンプルですが、一方の編集を黙って破棄します。これは設定値には許容できますが、共有ドキュメントには許容できません。フィールド単位のマージは、重ならない編集を保持します。CRDTは、共同編集のテキストやリストを自動的に収束させますが、メタデータの増加とデータモデルの難しさという代償を伴います。残高、在庫、予約については、キューに積まれた各操作をサーバーが現在の状態に照らして検証し、拒否することがあるため、アプリケーションはその拒否を分かりやすく提示しなければなりません。
同期ではさらに、トゥームストーンによる削除の扱い、まだアップロードされていないデータに対するスキーママイグレーション、バッチの途中で起きる部分的な失敗にも対処する必要があります。端末の時計は信頼できないため、順序付けにはサーバーが割り当てるバージョンまたは論理クロックを用い、端末のローカル時刻は決して使いません。
判断の決め手は、プロダクトのうちどれだけがプラットフォーム固有であるかです。フォーム、リスト、API駆動のコンテンツが中心のアプリケーションは共有に向いており、FlutterまたはReact Nativeの単一コードベースにより、機能開発の重複の大半がなくなり、2つのプラットフォームの足並みも揃います。一方、カメラのパイプライン、Bluetooth周辺機器、バックグラウンドでの位置情報、オンデバイス機械学習、ウィジェット、ウォッチ向けコンパニオン、最新のOS機能を中心に構築するアプリケーションは、労力の多くをネイティブとの境界に費やすことになり、クロスプラットフォームの層は作業を減らさないまま間接層を増やすだけになります。
チーム構成は技術と同じくらい重要です。TypeScriptとReactに習熟したWebチームはReact Nativeですぐに生産性を発揮できます。FlutterはDartの習得が必要になる代わりに、レンダリングをより厳密に制御できます。ネイティブチームはツールチェーン全体を自ら掌握しており、新しいOSバージョンが出荷されたときにフレームワークのリリーススケジュールに左右されません。Kotlin Multiplatformはその中間の道で、ネットワーク、永続化、ドメインロジックを共有しつつ、UIは完全にネイティブで構築します。
どれを選ぶにせよ、ある程度のネイティブの専門知識は必要です。署名、プッシュ通知の設定、ストアへの申請、ディープリンクの関連付け、パフォーマンスプロファイリング、そして多くのサードパーティSDKはプラットフォーム固有であり、その知識を持たないクロスプラットフォームのチームは、まさにそうした箇所で行き詰まります。
エンジニアリングの進め方
私たちは、クライアント、API、リリースプロセスを一体として設計します。古いバージョンがインストールされているかぎり、1つの判断が他の2つを制約し続けるためです。
対象とするOSバージョン、端末クラス、オフライン要件、規制およびストアポリシー上の制約、そしてプロダクトが依存する端末機能を確定します。これらが、ネイティブかクロスプラットフォームかの判断を決めます。
エンドポイント、ページネーション、エラーのセマンティクス、冪等性、旧バージョンに対する互換性ポリシーを、バックエンドチームとともに仕様化します。オフラインでの書き込みが必要な場合は、ストレージのコードを書く前に、エンティティごとのコンフリクトルールを決定します。
MVVMやMVIといった単方向データフロー、依存性注入、モジュール化したプロジェクト構成、ローカルの永続化層を整えると同時に、開発の最初の週からテスターに届く署名済みのCIビルドを用意します。
認証フロー、セキュアストレージ、生体認証による保護、通信路のセキュリティ、アテステーションを共通基盤として実装し、機能開発がそれらに依存する前にOWASP MASVSに照らしてレビューします。
ユニットテストとスナップショットテストはコミットごとに実行し、UIテストは古いハードウェアやOSバージョンを含むデバイスマトリクス上で実行します。ネットワークコンディショニングでパケットロス、遅延、リクエスト途中の切断を再現し、プロセス終了のテストで状態の復元を検証します。
ビルドは内部トラックとベータトラックを経て、本番環境への段階的なロールアウトへ進みます。公開範囲を広げる前に、クラッシュフリー率、ANR率、起動時間、主要なファネルイベントを前バージョンと比較します。
トレードオフ
アーキテクチャを確定する前に、お客様のチームとともに検討する問いです。
本番対応
トークンと鍵は、ハードウェアによる保護と、生体認証または端末の認証情報によるアクセス制御のもとでKeychainとKeystoreに保持し、機密情報はログ、平文の設定ストア、バックアップ、タスクスイッチャーのスクリーンショットのいずれにも書き込みません。通信にはTLSを用い、脅威モデルが求める場合はピンニングを加えます。リリースビルドは難読化し、デバッグフラグが残っていないことを確認します。クライアントは信頼できないものとして扱い、重要なルールはすべてサーバー側で改めて強制します。
モバイルにおけるスケールとは、多数のバージョンにまたがって増え続ける端末群を意味します。そのため、CDN、ゲートウェイでの端末単位のレート制限、ページネーションされキャッシュ可能なレスポンスによって、バックエンド側で負荷を受け止めます。プッシュ通知のファンアウトは、送信をバッチ化し無効なトークンを除去する、キューを背後に持つ通知サービスが担います。コードベースは、明示的なインターフェースを持つ機能モジュールによってスケールさせ、チームが拡大してもビルド時間とマージコンフリクトを抑えます。
クラッシュ、ハング、ANRのレポートはシンボリケートしてリリースごとにグループ化し、ブレッドクラム（直前の操作履歴）と端末のコンテキストを付与します。パフォーマンスモニタリングでは、コールドスタート、遅延フレームとフリーズフレーム、ネットワークリクエストのレイテンシを実機から記録し、トレースIDによってクライアントのリクエストをバックエンドのスパンに関連付けます。アナリティクスイベントはバージョン管理されたスキーマに従い、同意とプラットフォームのトラッキング規則を尊重します。
パイプラインは、タグ付けされたコミットから署名済みでバージョン管理されたビルドを生成し、シンボルをアップロードし、TestFlightとPlayのテストトラックへ自動で提出します。本番環境では、App Storeの段階的リリースとGoogle Playの段階的公開を利用し、どちらも一時停止が可能です。審査にかかる時間は保証されないため、リリース計画にはその余裕を織り込み、緊急時の緩和策はリモートフラグに頼ります。
アプリケーションはOpenID Connectを通じてIDプロバイダーと連携し、決済、地図、メッセージング、アナリティクスのSDKは内部インターフェースの背後に置いて、それぞれを置き換えたりテストでスタブ化したりできるようにします。サードパーティSDKは1つずつ、サイズ、起動コスト、権限、データ収集の観点で評価します。その挙動を、App Storeのプライバシーラベルと、Playのデータセーフティフォームで申告しなければならないためです。
ワークロードとお客様の既存環境に合わせて選定します。
ゼロから本番へ
アイデア
ディスカバリー
システムアーキテクチャ
UX・プロダクトデザイン
アプリケーション開発
AI・データレイヤー
クラウドインフラ
セキュリティ
QA・パフォーマンス
デプロイ
オブザーバビリティ
継続的な進化
FAQ
プロダクトのうちどれだけがプラットフォーム固有であるか、そしてどのようなチームがあるかによって決まります。コンテンツやワークフローが中心のアプリケーションはFlutterやReact Nativeで共有しやすく、カメラ、Bluetooth、バックグラウンド処理、新しいOS機能を土台とするプロダクトは、通常SwiftとKotlinのほうが適しています。最もリスクの高い端末連携について短期間の技術検証（スパイク）を行うほうが、比較表よりも確実に答えが出ます。
アプリケーションはiOSではAPNs、AndroidではFCMに登録してデバイストークンを受け取り、それをバックエンドに送信します。バックエンドはプラットフォームのサービスに対し、そのトークン宛てのメッセージ配信を依頼し、プラットフォームは端末に到達可能になった時点で配信します。配信はベストエフォートで、遅延したり、まとめられたり、破棄されたりすることがあり、トークンも変わります。そのため、バックエンドは無効なトークンに対処し、アプリケーションは正となる状態をAPIから取得する必要があります。
審査時間は一定ではなく、どちらのストアも保証していないため、所要時間が固定であるという前提でリリースを計画すべきではありません。リジェクトのよくある原因には、プライバシー申告の不備、アカウント削除機能の欠如、目的が明確でない権限リクエスト、審査担当者がサインインできないこと、アプリ内課金のルールに抵触する決済フローなどがあります。申請のたびにテスト用の認証情報と審査用メモを添えることで、その多くを回避できます。
認証情報と鍵は、ハードウェアに裏付けられた保護のもとでKeychainまたはKeystoreに保管し、より大きな機密データセットはそこに保持した鍵で暗号化します。生体認証のチェックは暗号鍵に紐づけるため、条件分岐にパッチを当てて回避することはできません。機密性の高い画面はスクリーンショットとバックアップの対象から除外し、サーバーは、クライアントがルールを強制済みであることを決して前提にしません。
はい、可能です。ドメインサービスとデータは共有し、クライアント種別ごとの薄いBFFがそれらを適合させます。モバイル向けのBFFは、回数が少なく、小さく、バージョン差に寛容なレスポンスを重視し、Web向けのBFFはWebのデプロイに合わせて変更できます。これにより、ビジネスルールを1か所に保ちつつ、各クライアントがそれぞれのリリースサイクルで進化できます。
