App Clip・Instant App（軽量配布）

フルインストールという摩擦をなくす

アプリストアの審査・ダウンロード・インストールという一連の手順は、初回利用までの離脱を生む最大の要因です。App Clip（iOS）とInstant App（Android、Google Playが2023年に新規公開を終了し既存アプリの更新のみサポート）は、この摩擦そのものを取り除く発想で設計されています。本体アプリをまるごと配らず、今この瞬間に必要な機能だけを切り出した軽量バイナリを、QRコードやNFCタップなどの物理的な起点から数秒で起動させる。駐車場の料金支払いやレンタサイクルの解錠のように、「使う場所」と「使う瞬間」が一致するユースケースを想定した配布方式です。

サイズ制限が設計を決める

App Clipは圧縮後10MB、Instant Appは体験単位（Module）ごとに概ね4〜10MB程度という厳格な上限が課されます。この数字は単なる制約ではなく、アーキテクチャの出発点です。数十MBが当たり前の通常アプリと同じ設計では収まらないため、次のような分割が必須になります。

iOS側はApp Clipターゲット専用のコンパイル設定を持ち、本体アプリと共有するコードは共有フレームワークに切り出したうえで、そのフレームワーク自体が10MB以内に収まるよう継続的に計測する運用が要ります。Android側はApp Bundleの機能モジュール（Dynamic Feature Module）のうちdist:instant属性を付けたモジュール群だけがInstant App実行時に読み込まれ、それ以外のモジュールへの依存を静的解析でブロックされます。つまりモジュール境界の設計ミスはビルド時にすぐ露呈します。

QRコード・NFCによる起動導線

軽量バイナリは検索結果やホーム画面からではなく、物理的な接点から呼び出されるのが前提です。

• App Clip Code / QRコード: 専用のApp Clip Codeか汎用QRコードにApp Clip対応URLを埋め込み、カメラアプリが認識すると自動的にApp Clipカードが起動する。
• NFCタップ: NFCタグをタップすると対応するApp ClipのURLがOS側で解決されカードが表示され、App Clip Codeと組み合わせれば視覚的な目印にもなる。
• Instant Appの起動: Android側はDeep Link（App Links）経由が中心で、対応URLをブラウザや検索結果、共有先で開くとInstant Appが直接起動する。

これらはいずれもOS側がURLとバイナリの対応関係を検証してから起動する仕組みで、任意のアプリが横取りしてなりすますことはできません。iOSはApple側のAssociated Domains検証、AndroidはDigital Asset Linksによるドメイン所有権の証明が前提になっており、Web側のドメインと開発者アカウントの紐付けを事前に登録しておく必要があります。

ネイティブアプリへの誘導設計

軽量配布は目的そのものではなく、多くの場合、本体アプリのインストールへつなげる入口です。ここで重要なのは、軽量体験からフルインストールへの遷移でそれまでの操作や入力データが失われないことです。

• 状態の引き継ぎ: App Clipで入力した会員情報や選択したメニューを共有のUserDefaults（App Group）やサーバー側セッションに保存し、本体アプリの初回起動時に同じ状態から再開させる。
• 控えめなインストール誘導: 体験の途中で唐突にストア遷移を挟むと離脱を招くため、目的の操作（支払い完了、解錠成功など）が終わった直後に自然な導線でインストールを促す設計が定石です。
• Instant Appの現状: Instant Appは新規アプリの公開自体が既に終了しているため、既存導入済みアプリの保守を除けば新規設計での採用対象にはならず、代替はDeep Link起動やWeb体験で完結させる設計になります。

まとめ

App ClipとInstant Appは、フルインストールという参入障壁を取り払い、QRコードやNFCといった物理的な接点から数秒で機能の核心だけを体験させる配布方式です。この体験を成立させているのは、10MB前後という厳格なサイズ制限に応じたモジュール分割設計と、ドメイン検証に支えられた起動経路の安全性です。そして軽量体験は終着点ではなく、状態を引き継ぎながら本体アプリへ自然に橋渡しする導線設計とセットで初めて価値を生みます。アプリのライフサイクルやプロセス管理の基礎は /os/ の考え方とも接続しています。