ディープリンクとは？Universal Links・App Linksの違いと確認手順

2026年5月28日

著者: 与謝秀作

ディープリンクは、Webやアプリの特定のコンテンツへ直接案内するリンクです。アプリを開く方式にはカスタムURLスキーム、iOSのUniversal Links、AndroidのApp Linksなどがあり、未インストール時やログイン前の動作も設計が必要です。この記事では方式の違いと、実機で確認する手順を整理します。

ディープリンクの意味：特定のコンテンツへ直接案内する

例えば、Webサイトのトップページではなく商品ページへ進むリンクも、広い意味でディープリンクです。モバイルアプリでは、ホーム画面を経由せず商品・予約・コンテンツなどの画面へ進む用途を指します。ハイパーリンクと排他的な分類ではなく、特定の行き先を指定するという性質に注目した言葉です。

リンクを押す操作と、目的の画面に到着することは別の段階です。アプリの有無、ブラウザ、OS、ユーザーの選択、ログイン状態で開き方が変わります。導入しただけで購入や登録が増えると約束せず、利用者が目的を完了できるかを確認します。

カスタムURLスキーム・Universal Links・App Links

代表的な方式を比べると、URLの形だけでなく、Webサイトとアプリの関係をどう確認するかが異なります。以下のパスはすべて説明用です。

方式	URLの形・例	関連付け	未導入時・追加要件
カスタムURLスキーム	exampleappという独自スキームと /items/42 のような行き先	アプリ側でスキームを扱う	同じWeb URLへ自動的に戻れるとは限らず、代替導線が必要
Universal Links	HTTPS URLと /items/42 のようなパス	iOSのAssociated DomainsとAASA	Web側の内容も使えるようにし、呼び出し条件を試す
Android App Links	HTTPS URLと /items/42 のようなパス	Digital Asset Linksなどでドメインとの関係を検証	端末の検証状態や設定を確認する
Deferred deep linking	選んだリンクの文脈を導入後へ引き継ぐ設計	採用する方式ごとに別途設計	インストール誘導と文脈復元を別々に実装・検証する

OS別の基礎は、AppleのUniversal Links資料とAndroid App Links資料で確認できます。独自スキームはHTTPSのドメイン所有権を使う関連付けと同じ仕組みではありません。

Webとアプリの関連付けとフォールバック

iOSでは、アプリ側のAssociated Domainsの設定と、Web側のapple-app-site-association（AASA）による対応関係を整えます。Androidでは、アプリ側の対応する設定と、Web側のDigital Asset Linksの情報を照合します。Androidの署名証明書のfingerprintと、Web通信のためのTLS証明書を同じものとして説明しないようにしてください。

関連付けが正しくても、どの操作から開いたかなどで結果は変わります。Appleは、Safariで同じドメイン内のリンクをたどる場合にSafariで開く動作も説明しています。必ずアプリへ移動するものではありません。調査ではUniversal Linksのデバッグ資料を使い、ドメイン、対象パス、アプリ設定、呼び出し元を切り分けます。

アプリがない人にも、商品情報や必要な手続きへ進めるWeb代替を用意します。単にストアへ送り込むだけでなく、インストールしない選択でも目的を達成できるかを考えてください。

インストール後のリンク復元は別の仕組み

未インストールの人をアプリストアへ案内した後、最初に選んだ商品などを復元する仕組みは、deferred deep linkingとして別に設計します。通常のUniversal LinksやApp Linksを設定しただけで、インストール後の文脈が必ず引き継がれるわけではありません。

必要な文脈、保存する期間、復元できない場合の案内を決め、インストール誘導と初回起動後の復元を別の段階で検証します。アプリストアやOSの条件、採用するサービスの対応範囲も確認してください。なお、Firebase Dynamic Linksは公式FAQで2025年8月25日の終了が案内されており、新規導入候補として扱いません。

OS・ブラウザ・ログイン状態別にテストする

下表は8つの基本テスト条件です。期待する動作は自社の設計に合わせて記入し、実際に開いた場所、認証後の戻り先、Web代替、問題を記録します。特定の条件なら必ずこの結果になるという保証表ではありません。

OS	アプリ	ログイン	点検の焦点
iOS	導入済み	済み	指定した画面と対象IDへ進むか
iOS	導入済み	未	認証後に意図した行き先へ戻れるか
iOS	未導入	済み	利用可能なWeb代替と導入案内
iOS	未導入	未	Webの認証と代替、導入後の復元を分けて試す
Android	導入済み	済み	検証状態と指定した画面
Android	導入済み	未	認証後の行き先と権限確認
Android	未導入	済み	Web代替から目的を完了できるか
Android	未導入	未	代替・認証・導入後の復元を個別に確認

Webとアプリのログイン状態は独立している場合があります。試験ではどちらの状態かも記録します。さらに、Safari内の同一ドメインリンク、メール、他アプリ内ブラウザなどの呼び出し元、OS版、アプリ版を追加条件にしてください。存在しないID、権限のないID、削除済みコンテンツでも安全に案内できるかを確認します。