ディープリンク（Universal Links／App Links）

URLでアプリの特定画面を開くという課題

ディープリンクとは、Webページの1URLが特定のコンテンツを指すのと同じように、1本のURLをアプリ内の特定の画面・状態へ直接対応づける仕組みです。メールのボタン、SNSの共有リンク、他アプリからの遷移がホーム画面ではなく目的の商品ページや会話画面をそのまま開くために不可欠です。実現方式は大きく2系統あり、両者の本質的な違いは「そのリンクを本当に自分のアプリが受け取ってよいと、誰がどう保証するか」に集約されます。

横にスクロール

カスタムスキームとその弱点

古くからある方式がmyapp://product/42のようなカスタムURLスキームです。アプリはインストール時にOSへmyappというスキームを登録し、OSはそのスキームのURLが開かれたときに登録アプリを起動します。仕組みは単純ですが、致命的な弱点があります。スキーム名はグローバルに一意ではなく、複数のアプリが同じ名前を登録できてしまうのです。

iOSではどのアプリが起動するかが不定になり、Androidでは選択ダイアログ（ディスアンビゲーション）が出るか、後から入れた悪意あるアプリが同名スキームを奪って正規アプリになりすませます。決済トークンや認証コードをこのURLに載せると、横取りアプリに漏洩する経路が生まれます。加えて、対象アプリが未インストールならスキームURLは何も解決できず、ブラウザ側ではエラーになるだけでフォールバック先も自前で用意する必要があります。

Universal Links／App Links：HTTPSと所有権証明

この問題を解決するのがiOSのUniversal LinksとAndroidのApp Linksです。両者はhttps://example.com/product/42という通常のHTTPS URLをそのままディープリンクとして使います。ポイントは、そのドメインを本当に所有する開発者だけがリンクを受け取れるよう、OSがドメイン側に置かれた検証ファイルを取得して所有権を確認する点です。カスタムスキームがアプリ側の一方的な宣言だったのに対し、こちらはドメイン（サーバー）側の署名済み宣言とアプリ側の宣言を突き合わせる双方向の検証になっています。

副次的だが重要な利点として、未インストール時に同一URLがそのままWebページとして開くことが挙げられます。1本のHTTPS URLがアプリでもWebでも意味を持つため、リンク切れが起きず、Web側にフォールバックUIやインストール誘導を自然に置けます。

検証ファイルの実体

所有権証明の核心が、ドメインの決まったパスに配置する検証ファイルです。OSはアプリのインストール時（およびアプリ更新時）にこれを取得し、内容をアプリの識別子と照合します。

iOSはhttps://example.com/.well-known/apple-app-site-association（AASA、拡張子なし・Content-Type: application/json・リダイレクト不可）を取得します。中身は対象のApp IDと、そのアプリが扱うパスのパターンを列挙したJSONです。

{
  "applinks": {
    "details": [
      {
        "appIDs": ["TEAMID.com.example.app"],
        "components": [
          { "/": "/product/*", "comment": "商品ページ" },
          { "/": "/account/*", "exclude": true }
        ]
      }
    ]
  }
}

Androidはhttps://example.com/.well-known/assetlinks.jsonを取得します。こちらはパッケージ名に加えて、アプリ署名証明書のSHA-256フィンガープリントを含める点が決定的で、署名鍵まで一致しないと検証が通りません。

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.app",
    "sha256_cert_fingerprints": ["AB:CD:EF:..."]
  }
}]

アプリ側も対応する宣言が必要です。iOSはentitlementsのAssociated Domainsにapplinks:example.comを登録し、Androidはマニフェストのintent-filterにandroid:autoVerify="true"を付けます。サーバー側ファイルとアプリ側宣言の両方が揃って初めて検証が成立し、片方でも欠ければリンクはブラウザで開くだけになります。署名フィンガープリントの照合が絡むため、この仕組みは /mobile-development/mobile-app-signing-provisioning/ のコード署名基盤と地続きです。同じドメイン検証はApp ClipやInstant Appの起動経路でも使われ、/mobile-development/mobile-app-clip-instant-apps/ と共通の土台になっています。

遅延ディープリンク（Deferred Deep Linking）

ここで難問になるのが、アプリが未インストールの状態でリンクが押された場合です。理想は、ストアからインストールを完了して初回起動したときに、本来開くはずだった/product/42へ直接遷移させることです。これを遅延ディープリンクと呼びます。

問題は、ストアのインストールという行程がリンク情報を運ばないことです。ユーザーがWebでリンクを踏み、ストアへ飛び、アプリを入れて起動する間に、「どの画面を開きたかったか」という文脈はOSの標準機能では引き継がれません。そのため各種手法で橋渡しします。

• クリップボード方式: Web側で遷移先情報を一時的にクリップボードへ書き、初回起動時にアプリが読み取る。確実だが、OSがクリップボードアクセス時に通知を出すためプライバシー面の配慮が要る。
• 確率的マッチング（フィンガープリント）: IPアドレス・端末機種・OSバージョン・画面サイズなどの組み合わせでクリック時と起動時を確率的に突き合わせる。identifierを使わないが精度が完全ではなく、誤マッチの可能性が残る。
• 決定的マッチング: iOSのApp Clipや一部のAPIのように、OS・ストアが公式に文脈を受け渡せる限定的な経路を使う。精度は高いが適用範囲が狭い。

アプリ内ルーティングへの受け渡し

検証を通ってリンクがアプリに届いた後は、URLを解析してアプリ内の画面遷移へ変換します。届き方はプラットフォームで異なります。iOSはインストール済みならNSUserActivity（continueUserActivity）としてUniversal Linksを受け取り、AndroidはUri付きのIntentとしてActivityに配送されます。届く経路はアプリの状態（起動中か、起動時か）で変わるため、両OSのライフサイクルコールバックを踏まえた設計が要ります（/mobile-development/ios-app-lifecycle-states/、/mobile-development/android-activity-lifecycle/）。

実装上の要点は、URLからルーティング先を決めるロジックを起動経路から独立させることです。「コールドスタートで届いたURL」「起動中に届いたURL」「アプリ内で生成した遷移」がすべて同じルーターを通る構造にすると、経路ごとの分岐が消えて堅牢になります。擬似コードで示すと次のようになります。

route(url):
  path, params = parse(url)        # /product/42 → ("product", {id:42})
  if not authorized(path):         # 認証が要る画面なら
     save_pending(url)             #   URLを退避してログイン画面へ
     go(login); return
  screen = map(path)               # パスを画面へ対応づけ
  navigate(screen, params)         # ナビゲーションスタックへ積む

まとめ

ディープリンクの設計は、リンクを「誰が受け取ってよいか」をどう保証するかという一点に貫かれています。カスタムスキームはアプリの一方的宣言に依存するため横取りに弱く、Universal Links／App LinksはHTTPS URLとドメイン上の検証ファイル（apple-app-site-association／assetlinks.json）による双方向の所有権証明でなりすましを原理的に排除します。未インストール時の文脈を運ぶ遅延ディープリンクはサンドボックス境界ゆえに本質的に難しく、精度と正確性のトレードオフを設計で引き受けます。そして検証を通った後は、外部入力であるURLを必ず検証してから、起動経路に依存しない単一のルーターでアプリ内遷移へ変換することが、堅牢な実装の要になります。