iOSとAndroidのディープリンク：実践ガイド

ディープリンクとは、Webページではなく、インストール済みのアプリ内の特定の画面を開くURLのことです。考え方としてはそれだけですが、この15年で3通りの実装がなされ、それぞれに固有の壊れ方があります。マーケティングチームがこの件のバグ報告を出し続けるのは、3つが今も同時に存在していて、同じURLでも、メッセージでタップされたのか、ブラウザーなのか、メールクライアントなのか、SNSアプリに埋め込まれたウェブビューなのかによって、挙動が変わり得るからです。

このガイドでは、それぞれの仕組みを、できないことも含めて正直に説明します。1つだけ持ち帰るとすれば、これにしてください。クリックを正しいアプリ画面へ振り分けることは、すでに解決済みのインフラです。しかし、ユーザーがアプリをインストールした後に正しい画面へ送り届けることは、少なくともリンクプラットフォーム単体では、解決されていません。

アプリを開くリンクの3つの世代

カスタムURLスキーム

最初の仕組みです。アプリがmyappのようなスキームを登録すると、myapp://product/42のようなURLがそのアプリにリクエストを渡します。スキームは実装がごく簡単で、アプリ内部の振り分け形式としては今も有用ですが、構造的な問題を2つ抱えています。

1つは所有権の検証がないことです。どのアプリでも任意のスキームを登録でき、2つのアプリが同じものを主張した場合、iOSでは解決結果が未定義、Androidでは選択ダイアログになります。もう1つはフォールバックがないことです。アプリが入っていない端末では、スキームのURLはエラーページを出すか、何も起きません。そのためスキームのリンクには必ず、失敗を検知してユーザーを有用な場所へ送るラッパーが必要になります。そのラッパーこそ、ブラウザーが遷移用タイマーの扱いを厳しくしていくなかで壊れた、まさに脆い部分でした。

iOSのUniversal Links

Appleによる置き換えは、通常のHTTPS URLを使います。アプリ側はapplinks:yourbrand.comという形式の関連ドメインのエンタイトルメントを宣言し、ドメイン側は/.well-known/apple-app-site-associationにJSONファイルを公開して、どのパスがそのアプリに属するのかを記述します。

{
  "applinks": {
    "details": [
      {
        "appIDs": ["ABCDE12345.com.yourbrand.app"],
        "components": [{ "/": "/p/*", "comment": "Product pages" }]
      }
    ]
  }
}

このファイルは、リダイレクトなしのHTTPSで、JSONとして、そのパスちょうどに配信されなければなりません。iOSがこれを取得するのはインストール時と更新時のあたりで、多くはAppleのCDN経由です。つまり、変更は即座には反映されません。利点は、同じURLがどこでも機能することです。アプリが入っていてパスが一致すればアプリが開き、そうでなければSafariがWebページを読み込みます。エラー状態は存在しません。

AndroidのApp Links

Android側の対応物は、/.well-known/assetlinks.jsonに置くDigital Asset Linksのファイルで、アプリのパッケージ名と、署名証明書のSHA-256フィンガープリントを記載します。

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "com.yourbrand.app",
      "sha256_cert_fingerprints": ["A1:B2:C3:D4:E5:F6:..."]
    }
  }
]

アプリ側は、そのドメインに対するインテントフィルターを、自動検証を有効にして宣言します。検証に成功すれば、リンクは選択ダイアログなしでアプリを開きます。失敗すれば、リンクはブラウザーを開きます。そして原因として圧倒的に多いのがフィンガープリントの不一致です。手元のリリース鍵のフィンガープリントを公開してしまう一方で、Play App Signingが別の鍵でアプリを再署名しているのです。ファイルに載せるべきフィンガープリントは、配布される成果物についてストアが表示しているほうです。

短縮リンクはどうやってリンク先を選ぶのか

短縮リンクは、固定されたポインターではなく判断の分岐点です。だからこそアプリ施策で役に立ちます。印刷したコード1つで、iPhoneユーザー、Androidユーザー、デスクトップの訪問者にそれぞれ違う応答ができますし、その判断はコードを印刷した後でも変えられます。

リダイレクトエンジンから見えるのは、リクエストのユーザーエージェント、そこに載っているクライアントヒント、そして国のようなネットワークから導かれるシグナルです。アプリのトラフィック向けに設定したリンクは、たいてい3つのリンク先を持ちます。iOS用のURL、Android用のURL、そしてそれ以外のすべてに使うWeb用のURLです。その上に重なるターゲティングルールは、国、デバイス、OS、言語で振り分けられるので、リンクを別々に作ることなく、カナダのAndroidトラフィックだけを1つのリンク先へ、それ以外の全員を別のリンク先へ送れます。

実装上の細かな点を2つ知っておく価値があります。紛らわしい挙動のほとんどは、この2つで説明がつくからです。

1つ目はSNSのクローラーです。FacebookやTelegramの取得ボットがプレビューカードを作るためにリンクを要求したとき、正しいリダイレクトエンジンは、そのリクエストをクリックとして数えることも、スマートフォンであるかのように振り分けることもせず、プレビュー用のメタデータで応答します。リンクを投稿した瞬間、まだ誰もタップしていないのにクリック数が跳ね上がるなら、そのエンジンはこれをしていません。

2つ目は関連付けの境界で、これがこの記事で技術的に最も重要な点です。Universal Linksは、ユーザーが実際にタップしたURLのドメインに対して評価されます。誰かがgo.yourbrand.com/p/42をタップし、そのドメインがyourbrand.com/p/42へのリダイレクトで応答した場合、iOSはリダイレクト先を関連付けられたリンクとは扱わないので、アプリは開きません。短縮リンクにネイティブでアプリを開かせるには、関連付けファイルを短縮ドメイン自体で配信する必要があります。それができない場合の実務的なフォールバックは、カスタムスキームか、あるいは直接ストアへの受け渡しであり、ほとんどの短縮サービスのディープリンク機能が実際にやっているのはこちらです。どのベンダーにも、2つのうちどちらを実装しているのかを尋ねてください。宣伝文句はどちらでも同じだからです。

フォールバックの連鎖

機能するアプリ向けリンクは、実のところ小さな判断ツリーであり、それぞれの枝に意図した答えが必要です。

| 状況 | 起きるべきこと | よくある間違い | | --- | --- | --- | | アプリあり、パスが認識される | アプリが目的の画面で開く | リダイレクトの連鎖が関連付けを壊す | | アプリあり、パスが認識されない | Webページが読み込まれ、アプリを案内する | タップのたびに選択ダイアログが出る | | アプリなし、モバイル | 正しいプラットフォームのストアページ | ストアのリンクが片方のプラットフォームに固定されている | | デスクトップ | その画面に相当する完全なWebページ | 汎用のトップページに着地する | | SNSのクローラー | プレビュー用メタデータ、クリックは数えない | プレビュー取得が分析を水増しする |

ストアの枝は、1本のリンクではなく、プラットフォームに応じた掲載ページへ向けてください。そしてWebの枝は、アプリの画面と本当に同等の内容に保ってください。他をどれだけうまく設定しても、アプリ施策のトラフィックのかなりの割合はWebの枝に行き着きます。そこを行き止まりとして扱うことは、出稿費の大半を無駄にすることです。

インストールの境界について、正直に

ベンダーの宣伝と現実が食い違うのがここです。ある新規ユーザーが特定の商品へのリンクをタップし、アプリを持っていないのでストアに着地し、インストールして開いたとします。このときアプリが表示するのは既定のホーム画面です。商品の識別子をインストールの向こう側まで運んだものが、何もないからです。これを機能させることをディファードディープリンク（遅延ディープリンク）と呼びますが、リンクプラットフォームが単体でできることではありません。

必要になるのは、初回起動時に、インストール前にユーザーが何をタップしたのかをサーバーへ問い合わせるアプリ内のSDKです。サーバーは2つのイベントを照合しなければなりませんが、その照合に使えるシグナルは大きく狭まりました。デバイスのフィンガープリンティングは信頼性が低く、プラットフォームの方針による制限も強まっています。広告識別子には同意が必要で、多くのユーザーはそれを拒否します。Appleのアトリビューション基盤が広告主に報告するのはインストール単位の帰属であって、あなたのアプリへパスを渡すものではありません。かつてトークンを運んでいたクリップボードの手法は、今では目に見える貼り付け通知を出します。

残っている手段は機能しますが、それは統合コストの異なる別の製品です。モバイル計測パートナーのSDK、アプリ内での初期化、そして厳密ではなく確率的な照合ウィンドウが伴います。LinkProfitはクリックをデバイスごとに振り分けてストアへ受け渡しますが、インストール後の振り分けができるとは謳っていません。それをきちんとやるということは、あなたのアプリの中にコードを出荷することを意味するからです。ディファードの振り分けが譲れない要件なら、そのSDKはリンクプラットフォームの代わりではなく、その隣に置くものとして計画してください。

ウェブビューと、その他の実務的な落とし穴

アプリ内ブラウザー

SNSアプリの中でタップされたリンクの大半は、システムのブラウザーではなく埋め込みのウェブビューで開きます。そしてウェブビューによるアプリ関連付けの扱いは一貫していません。Universal Linksを無視するものもあれば、カスタムスキームを遮断するものもあり、挙動はアプリのバージョンによっても異なります。テストでは完璧に動いたリンクが本番ではWebサイトを開いてしまう、最も多い理由がこれです。テストはたいてい、正しく振る舞うメッセージアプリでリンクをタップして行われるからです。

これを一括で直せる設定はありません。効くのは、Webのリンク先を良いものにし、そこに目に見える「アプリで開く」操作を追加し、どのチャネルも同じように振る舞うと想定せず、公開先ごとに個別にテストすることです。

関連付けファイルでよくある失敗

繰り返し起きるものが4つあります。1つ目は、関連付けファイルをリダイレクト経由で配信してしまうこと。apexからwwwへの自動リダイレクトも含まれ、それだけでファイルは無効になります。2つ目は、誤ったコンテンツタイプで配信するか、フレームワークが書き換えるパスから配信すること。3つ目は、上で述べたAndroidの署名フィンガープリントを間違えて公開すること。4つ目は、iOSがこのファイルをキャッシュすることを忘れることです。すでにアプリが入っている端末に修正が届くまでには、1日以上かかることがあります。

アプリの枝における分析

クリックがいったんアプリに入ると、あなたのWebアクセス解析からは見えなくなります。レポーティングが静かに崩れるのはここです。キャンペーンパラメータはリンクに載せたままにしてリダイレクトエンジンに記録させ、アプリ側のリンク先へは識別子を引き渡して、アプリ内のセッションをそのクリックと結び付けられるようにしてください。リンクのクリックの計測についてのガイドでは、1つのクリックイベントから分かることと分からないことを扱っていますが、ボットとユニークビジターに関する同じ但し書きは、ここでも当てはまります。

公開前のテスト

curl -sSI https://yourbrand.com/.well-known/apple-app-site-association
curl -sS https://yourbrand.com/.well-known/assetlinks.json

# Android: open a URL as if it were tapped, then inspect verification state
adb shell am start -a android.intent.action.VIEW -d "https://yourbrand.com/p/42"
adb shell pm get-app-links com.yourbrand.app

# iOS simulator
xcrun simctl openurl booted "https://yourbrand.com/p/42"

最初の2つのコマンドは、リダイレクトなしで200を返すはずです。なお、SafariのアドレスバーにUniversal Linkを打ち込んでもアプリが開かないのは、意図的な仕様です。代わりにメモやメッセージ、あるいはシミュレーター用のコマンドからテストしてください。そうしないと、存在しないバグを追いかけることになります。

リンクプラットフォームが実際に含めているもの

ディープリンクへの対応は、この分野の中でも売り方が大きく異なります。そして違いは、機能そのものよりも、どのプランを買わなければならないかにあります。

| ベンダー | ディープリンクの提供状況（2026年8月時点） | | --- | --- | | BL.INK | 全プラン。エントリー階層はユーザー1人・ドメイン1つで月48ドル | | Short.io | 月48ドルのTeamプランから | | Rebrandly | 月99〜119ドルのGrowthプランから | | Switchy | 130を超えるアプリへの対応を表示 | | LinkProfit | デバイスごとのリンク先を全プランで提供 |

ここで正直な基準になるのはBL.INKです。ドメイン1つにしてはエントリー価格が高いとはいえ、ディープリンクをすべての階層に含めるのは珍しいことです。RebrandlyがGrowthに置いていることは、一般に注意しておくべきパターンです。1つの機能のために必要になる階層が、結局は請求額全体を決めてしまいがちだからです。

うまくいく導入の手順

1. リンクを張りたいアプリ画面ごとに、正規のWeb URLを決めます。Webページはフォールバックであり、真実の基準でもあります。
2. 実際にリンクに現れるドメインに、両方の関連付けファイルを公開し、リダイレクトなしのHTTPSで確認します。
3. iOSには関連ドメインのエンタイトルメントを、Androidには検証済みのインテントフィルターを追加します。フィンガープリントは配布されるビルドのものを使います。
4. 短縮リンクが実際にタップされるドメインがどれかを確認し、関連付けがそこにあるのか、それともプラットフォームがスキームやストアへ受け渡すのかをはっきりさせます。
5. 各リンクに、デバイスごとのリンク先とWebのフォールバックを設定し、ストアの掲載ページはプラットフォームごとに正しいものを指定します。
6. 両方のプラットフォームで、メッセージアプリから、システムのブラウザーから、そして実際に公開するすべてのSNSアプリからテストします。
7. キャンペーンパラメータがリダイレクトを生き延び、分析に記録されることを確認します。
8. キャンペーンごと、受信者ごと、商品ごとにリンクを生成するなら、APIで作成を自動化します。

どれも単体では難しくありません。難しいのは、部品が3か所——アプリのプロジェクト、DNSゾーン、リンクプラットフォーム——に分かれて存在し、たいていそれぞれ別の担当者が持っていることです。関連付けファイルを誰が持つのかを書き留めておくことは、この記事にある個々の設定のコツのどれよりも価値があります。