LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

ディープリンクとは — 種類・できることの整理

ディープリンク（Deep Link）とは、Webページや通知・QRコードなどのリンクをタップしたとき、アプリのホーム画面ではなく特定の画面（商品詳細・会員ページ・キャンペーンページ等）へ直接遷移させる仕組みを指します。「Web→アプリの特定画面」というナビゲーションを1タップで完結できるため、マーケティングキャンペーンやプッシュ通知との組み合わせでコンバージョン改善に使われます。

ディープリンクには実装方式が3種類あります。それぞれの特徴を整理すると次のとおりです。

新規実装では、フォールバックの堅牢性と標準性からUniversal Links（iOS）またはApp Links（Android）を選ぶことが推奨されています。カスタムURLスキームは別のアプリが同じスキームを登録できるため、意図しないアプリが起動するリスクがあります。

Universal Links（iOS）とApp Links（Android）の仕組み

Universal LinksとApp Linksは、どちらもHTTPS URLを使ってWebサーバとアプリの所有関係を証明する仕組みです。検証が成功すると、ブラウザの「このリンクをアプリで開きますか？」という選択ダイアログが表示されることなく、対象アプリが直接起動します。

Universal Links（iOS）：apple-app-site-associationによるドメイン検証

Appleの公式仕様では、Universal Linksを有効にするにはWebサーバとアプリの両側で設定が必要です^*1。

Webサーバ側では、apple-app-site-association（AASA）ファイルをHTTPSで配信できる場所に配置します。具体的には https://example.com/.well-known/apple-app-site-association というURLで、Content-Type: application/jsonのJSONファイルを置きます。このファイルにはアプリのTeam IDとBundle Identifier、ディープリンクとして有効にするURLパスのパターンを記述します。

アプリ側では、Xcodeの「Signing & Capabilities」でAssociated Domainsエンタイトルメントを追加し、対象ドメインを applinks:example.com の形式で登録します。アプリインストール時にAppleのサーバがAASAファイルを取得し、内容を検証して紐付けを確立します。検証済みであれば、該当URLをタップした際に選択ダイアログなしでアプリが直接開きます。

App Links（Android）：assetlinks.jsonによるSHA-256署名検証

Androidの公式仕様では、App LinksはDigital Asset Linksの仕組みを使ってドメインとアプリの関連を検証します^*2。

Webサーバ側では、assetlinks.jsonファイルを https://example.com/.well-known/assetlinks.json に配置します。このファイルにはアプリのパッケージ名と、アプリに署名したキーストアのSHA-256フィンガープリントを記述します。フィンガープリントによる暗号的な検証がApple方式との大きな違いです。

アプリ側ではAndroidManifest.xmlの対象Activity内に android:autoVerify="true" を追加し、インテントフィルタにHTTPSのURLパターンを設定します。アプリインストール時にAndroid OSがassetlinks.jsonを確認し、フィンガープリントが一致すれば自動的に検証済み状態になります。

iOS/Android共通のフォールバック設計

アプリが未インストールの場合、Universal Links/App LinksのHTTPS URLはWebページとして開きます。このフォールバックページでApp StoreやGoogle Playへ誘導するリダイレクトを設置することで、未インストールユーザーのインストール導線も確保できます。フォールバックの設計を要件定義段階で決めておかないと、未インストールユーザーがエラーページに到達するという問題が生じます。

外注で進める実装フロー — 要件定義からサーバ設定・検証・計測連携まで

ディープリンクの外注実装は、サーバ側の設定・アプリ側の設定・フォールバック設計・計測連携の4領域にまたがります。全体を把握した開発会社に一括で依頼することで、設定ファイルの不整合や動作確認の漏れを防げます。

フェーズ1：要件定義 — 対象プラットフォーム・対象URLパスの特定

まず「iOSのみか・Androidのみか・両対応か」と「どのURLパスをアプリ遷移の対象にするか」を確定します。たとえばECアプリであれば商品詳細ページ（/products/:id）やカート（/cart）、会員マイページ（/mypage）などが対象候補になります。

加えて、アプリ未インストール時のフォールバック先（App Store / Google Play / 既存Webページ）と、クリック計測に使うパラメータの設計もこの段階で決めます。計測パラメータを後付けすると既存のURLパターンが変わり、再設定が必要になるためです。

フェーズ2：サーバ側設定ファイルの作成・配置

iOS向けにはapple-app-site-associationファイルを、Android向けにはassetlinks.jsonをWebサーバの所定の場所に配置します。どちらもHTTPSで疎通できることが条件で、CDNのキャッシュ設定やアクセス制限が原因で取得失敗するケースが多いため、配置後の疎通確認は必須です。

iOS向けはAppleが提供するApp Search API Validationツールで、Android向けはAndroid DeveloperサイトのStatement List Generatorやadb shellコマンドで検証できます。開発会社への発注時に「設定ファイルの配置と疎通確認まで含めるか」をスコープに明記することが大切です。

フェーズ3：アプリ側の設定

iOSではXcodeでAssociated Domainsエンタイトルメントを追加します。Androidでは対象ActivityのインテントフィルタにHTTPS URLパターンと android:autoVerify="true" を追加します。どちらも設定値を誤るとインストール時の自動検証が失敗し、ディープリンクが動作しません。

既存アプリに追加実装する場合は、変更箇所の影響範囲の確認と、既存のカスタムURLスキームとの並行稼働設計が必要です。既存URLスキームを即時廃止すると、古いディープリンクを掲載しているメール・SNS・パートナーサイトの全てを更新しない限りリンク切れが発生します。

フェーズ4：動作検証 — iOS/Androidの実機テスト

ディープリンクの動作確認はシミュレーターでは再現できない挙動があるため、実機テストが必須です。iOS・Androidそれぞれでアプリインストール済み・未インストール・アプリがバックグラウンド起動中の3パターンを確認します。

特にiOSはAASAファイルの取得タイミングがアプリインストール時であるため、設定ファイルを変更した後は再インストールしてテストする必要があります。

フェーズ5：計測連携 — Adjust/Firebase/Branch等との設定

ディープリンク経由のコンバージョンを計測するには、MMP（モバイル計測プラットフォーム）やAnalyticsツールとの連携設定が必要です。AdjustやBranchなどのサードパーティツールを使う場合は、ディープリンクの実装と計測パラメータの設計を同時に進めることで重複作業を防げます。Firebase Dynamic Linksからの移行案件では、既存の計測設定を維持しながら新しい実装に切り替える移行計画が重要です。

つまずきやすい3つの落とし穴 — ドメイン検証・Dynamic Links廃止・フォールバック

ディープリンクの実装は設定ファイル1つの不備でも動作しないため、外注時にも開発会社の技術力を確認する必要があります。特に頻出する問題を3点整理します。

落とし穴1：サーバ設定ファイルの配信ミスによるドメイン検証失敗

Universal LinksではAASAファイルがHTTPSで正しく配信されていないと、アプリインストール時の検証が失敗してディープリンクが一切動作しなくなります。よくある原因はCDNによるキャッシュの遅延、Webサーバの設定ミスによる404エラー、リダイレクトの介在（AASAはリダイレクトなしで直接アクセスできることが条件^*1）などです。

App Linksではassetlinks.jsonのSHA-256フィンガープリントが本番ビルドの署名と一致していないと検証に失敗します。開発用・本番用それぞれのキーストアに対応したフィンガープリントを記載し忘れるミスが多いため、リリースビルドに切り替えた後の再確認が必要です。

落とし穴2：Firebase Dynamic Links廃止（2025年8月）への対応

Googleは2025年8月にFirebase Dynamic Linksのサービスを提供終了すると告知しています^*3。新規リンクの作成が停止されるだけでなく、既存のDynamic Linksも機能しなくなります。メール・SNS・アプリ内通知・外部パートナーサイトにDynamic LinksのURLを使っている場合、そのURLが全てリンク切れになります。

代替手段はUniversal Links/App Linksの自前実装か、Adjust・Branchといったサードパーティのディープリンク・計測プラットフォームへの移行です。移行には要件定義・サーバ設定・アプリ修正・計測連携の全工程をやり直す必要があるため、早めに移行計画を立てることが重要です。既存のDynamic LinksのURLをどのドメインに切り替えるかの設計も、この機会に整理することをお勧めします。

落とし穴3：フォールバック設計の漏れ

アプリが未インストールの場合の遷移先を設計しないと、URLをタップしたユーザーが何も起きない画面やエラーページに到達します。Universal Links/App LinksのHTTPS URLはアプリ未インストール時にWebページとして開くため、フォールバック先のWebページでApp Store/Google Playへの誘導を設置することが必要です。

加えて、アプリがインストール済みでも対象のOSバージョンがUniversal Links/App Linksをサポートしていない古い端末では動作しない場合があります。サポート対象のOSバージョンを要件定義で明確にし、古い端末向けの代替フローも設計しておくことが大切です。

外注の使いどころ — 実装・移行・計測連携の委託判断軸

ディープリンクの実装を外注する判断は、内製エンジニアの工数と技術的な経験値によって変わります。以下の3つの観点から委託の必要性を判断することをお勧めします。

判断軸1：実装の専門性 — サーバ設定・ネイティブ開発両方の知識が必要

Universal Links/App Linksの実装には、Webサーバの設定（HTTPSヘッダー・CDN設定）とiOS/Androidのネイティブ開発の両方の知識が必要です。フロントエンドエンジニアのみ・iOSエンジニアのみなど、片側の専門家しかいない体制では設定ファイルとアプリの連携部分で詰まるリスクがあります。

内製エンジニアがUniversal Links/App Linksの実装経験を持っていない場合、設定ミスによる動作不全の調査に想定外の工数がかかることがあります。外注先に実績を確認し、「設定ファイル配置→疎通確認→実機テスト」を一貫して対応できる会社を選ぶことで、そのリスクを軽減できます。

判断軸2：Firebase Dynamic Links移行の工数

既存のDynamic Linksを使っているアプリで2025年8月の廃止前に移行を完了させるには、移行の設計・実装・テストを数ヶ月以内にこなす必要があります。内製エンジニアが他の開発と並行して対応できない場合は、移行のみを単独プロジェクトとして外注する選択肢が現実的です。

移行先をAdjust・Branchなどのサードパーティツールにする場合でも、SDK組み込みとアプリ側の設定変更に開発工数がかかります。移行先ツールの選定・ライセンス費用の試算・実装のスコープ定義を外注前に整理しておくと、見積もりの精度が上がります。

判断軸3：計測連携の継続的なメンテナンス

ディープリンクは一度実装すれば終わりではなく、OSのメジャーバージョンアップやAASAファイル・assetlinks.jsonの更新、計測ツールのSDKアップデートに伴うメンテナンスが継続的に発生します。

開発フェーズを外注する場合、リリース後の継続保守（OSアップデート対応・設定ファイル更新・動作確認）まで対応できる体制を持っているかを契約段階で確認することが大切です。保守フェーズを別途内製で対応する計画であれば、引き継ぎ時のドキュメントの品質を発注要件に含めることをお勧めします。

まとめ：ディープリンク外注で押さえる3つの判断軸

本稿では、ディープリンク（Universal Links/App Links）の仕組み・外注での実装フロー・つまずきやすい落とし穴・委託判断軸を整理しました。要点を3点に集約します。

第一に、Universal Links（iOS）はAppleのAASAファイル検証、App Links（Android）はSHA-256フィンガープリントによる暗号的検証を使います。どちらもサーバ側の設定ファイルとアプリ側の設定を整合させる必要があり、片方の設定ミスだけでも動作しません。

第二に、Firebase Dynamic Linksは2025年8月に提供終了します。既存のDynamic LinksのURLを使っている場合は、Universal Links/App Linksの自前実装またはサードパーティへの移行を早急に計画する必要があります。移行は要件定義から計測連携の再設定まで複数工程にわたるため、外注での対応が現実的な場合もあります。

第三に、外注先を選ぶ際はWebサーバ設定・iOS/Androidネイティブ開発・計測ツール連携の3領域を一貫して対応できる会社を選ぶことが手戻り防止につながります。設定ファイルの疎通確認・実機テスト・フォールバック設計が発注スコープに明示されているかを確認してください。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Apple「Supporting associated domains | Apple Developer Documentation」（https://developer.apple.com/documentation/xcode/supporting-associated-domains）— Universal Links・apple-app-site-associationファイルの配置要件・検証方法に関する公式仕様
2. *2　出典：Google「Android App Links | Android Developers」（https://developer.android.com/training/app-links）— App Links（Digital Asset Links）のassetlinks.json配置要件・SHA-256検証に関する公式仕様
3. *3　出典：Google「Firebase Dynamic Links deprecation | Firebase」（https://firebase.google.com/support/dynamic-links-faq）— Firebase Dynamic Links 2025年8月提供終了の告知と代替手段の案内

Tweet