---
title: "ディープリンクとは？ユニバーサルリンク・URLスキーム・App Linksの違いと実装手順"
url: "https://www.issoh.co.jp/column/details/4701/"
published: 2025-01-06
updated: 2026-10-23
categories: ["アプリ"]
publisher: "株式会社一創"
---
# ディープリンクとは？ユニバーサルリンク・URLスキーム・App Linksの違いと実装手順
ディープリンクは、リンクをタップした人をアプリのトップではなく、商品詳細や記事など特定の画面へ直接届ける仕組みです。ユニバーサルリンクとの違いは「目的」と「方式」の関係にあります。ディープリンクが目的の名前で、ユニバーサルリンクはそれをiOSで実現するための、通常の`https://`リンクを使う方式の一つです。
方式はほかに、独自スキーム（`myapp://`）で起動するカスタムURLスキームと、Androidの App Links があります。カスタムURLスキームは「廃止」と言われがちですが、OSから消えたわけではありません。この記事では、方式の違い、URLスキームの現在の扱い、アプリで開かない条件、iOS・Androidの設定と受け取りコードを、Apple・Googleの公式ドキュメントに沿って整理します。
## まとめ
- **ディープリンクとユニバーサルリンクの違い**：ディープリンクは「アプリ内の特定画面を開く」という目的の総称です。ユニバーサルリンクはそれをiOSで実現する方式で、Webと同じ`https`のURLを使い、アプリが無ければそのままWebページが開きます。
- **カスタムURLスキームは廃止されていません**。Appleは「許容される方式」としつつユニバーサルリンクを強く推奨しています。同じスキームを複数のアプリが登録すると、どのアプリが開くかは未定義です。
- **App Links**はAndroid版の同等機能で、`assetlinks.json`で検証されたドメインのリンクだけを選択ダイアログなしでアプリに渡します。Android 12以降は、未検証のWebリンクは既定のブラウザで開きます。
- ユニバーサルリンクは、**Safariで同じドメインのリンクをタップしたとき**や、自分のアプリから自ドメインを開いたときはアプリに切り替わりません。動かないときはまずこの仕様を疑います。
- Firebase Dynamic Links は**2025年8月25日に終了**し、クリックは404を返します。OS標準の方式を基本とし、遅延ディープリンクや計測が必要なら、自前の追加実装と外部サービスの利用を比較します。
## ディープリンクの意味：アプリの特定画面を開くURL
ディープリンクは、利用者をアプリのトップ画面ではなく目的の画面へ直接届けるリンクです。OSがURLを解釈して対応アプリを起動し、アプリはURLのパスやクエリから「どの画面を、どのIDで開くか」を決めます。`https://example.com/product/123`を開けば商品123の詳細が表示される、という動きです。
効くのは、遷移先がはっきり決まっている導線です。メールやSNS、広告から商品詳細へ、プッシュ通知から該当の予約画面へ、といった使い方では、トップから探させる手順がそのまま離脱の原因になります。
### Web文脈の「ディープリンク」との違い
Webの世界では、サイトのトップではなく下層ページへ直接張るリンクもディープリンクと呼びます。こちらはHTMLの普通のリンクで、アプリの起動とは関係がありません。内部リンクの設計という意味での話題は[SEO内部対策の解説](/column/details/12834/)で扱っています。なお、アプリのディープリンクは遷移先を制御する仕組みであり、設定だけでGoogle検索の順位向上を保証するものではありません。検索結果からアプリを開かせる仕組みは[App Indexingの記事](/column/details/7070/)にまとめています。
## ディープリンクとユニバーサルリンク・URLスキーム・App Linksの違い
「ディープリンクとユニバーサルリンクのどちらを使うか」という比較は成り立ちません。選ぶ対象は、ディープリンクを実現する3つの方式（カスタムURLスキーム、ユニバーサルリンク、App Links）で、違いは次の表のとおりです。
| 観点 | カスタムURLスキーム | ユニバーサルリンク | App Links |
| ----------- | --------------------- | --------------------------------- | --------------------------------- |
| 対応OS | iOS・Android | iOS 9以降・macOSなど | Android 6以降（Google サービス搭載端末） |
| URLの形 | `myapp://product/123` | `https://example.com/product/123` | `https://example.com/product/123` |
| アプリ未インストール時 | 何も起きない・エラー | 同じURLのWebページが開く | 同じURLのWebページが開く |
| 所有の証明 | なし（誰でも登録可） | `apple-app-site-association` | `assetlinks.json` |
| 他アプリの横取り | 起こりうる | 起こらない | 起こらない |
決定的な差は「ドメインの所有を証明しているか」です。ユニバーサルリンクとApp Linksは、Webサーバーに置いた設定ファイルとアプリの設定が双方向で一致したときだけ、OSがそのドメインのリンクをアプリへ渡します。カスタムURLスキームにはこの確認がないため、同じ名前を名乗るアプリがあれば誤ったアプリが開きます。
### ユニバーサルリンクとカスタムURLスキームの挙動差
Appleの[ユニバーサルリンクの解説](https://developer.apple.com/documentation/xcode/allowing-apps-and-websites-to-link-to-your-content)によると、ユニバーサルリンクをタップするとブラウザやWebサイトを経由せずにアプリが開き、アプリが入っていなければ既定のブラウザでそのURLが開きます。リンクは1本で、Webとアプリの両方に使えます。カスタムURLスキームは、アプリが無い端末では開く先がありません。メールや広告に貼るリンクとしては、ここが致命的な差になります。
### App Links（Android）とユニバーサルリンクの共通点と相違点
仕組みはほぼ同じで、`https`のURLとWebサーバー上の検証ファイルを使います。相違点は検証の中身です。Androidの`assetlinks.json`にはアプリの署名証明書のSHA-256フィンガープリントを書き、OSはそれがインストールされたアプリの署名と一致するかを確かめます。Androidの[App Linksの解説](https://developer.android.com/training/app-links/about)は対応範囲を「Android 6（API 23）以降、Google サービスを搭載した端末」としており、Google サービスの無い端末では従来どおりのディープリンク扱いになります。
Androidにはもう一つ、検証していない`https`リンク（Web links）があります。Android 12（API 31）以降、アプリがそのドメインで承認されていなければ、Webリンクは既定のブラウザで開きます。intent-filterに`https`を書いただけではアプリは開きません。
## 静的・動的・遅延ディープリンクの使い分け
方式とは別に、リンクの作り方による分類もあります。判断の軸は「アプリが無い人をどう扱うか」と「流入を計測するか」の2つです。
| 種類 | 中身 | 未インストール時 | 向く用途 |
| ---------- | ---------------- | ----------- | ------------ |
| 静的 | URLが固定 | 方式に依存 | 常設の導線・アプリ内共有 |
| 動的 | 生成時にパラメータを付与 | サービスの設定に従う | 広告・キャンペーン |
| 遅延（ディファード） | インストール後に元の遷移先を復元 | ストア経由で目的画面へ | 新規獲得の広告 |
OS標準のユニバーサルリンクとApp Linksは、インストール済みの端末でアプリを開く仕組みです。ストアを経由したあとに元の画面へ運ぶ遅延ディープリンクは含まれません。広告から新規インストール後に特定の商品画面へ誘導するには、遷移先を引き継ぐ追加実装が必要です。外部サービスを利用する方法のほか、AndroidではGoogle Play Install Referrerを使って自前で実装する方法もあります。既存ユーザー向けのメールや通知が中心なら、静的なユニバーサルリンクとApp Linksで足ります。
## カスタムURLスキームは廃止されたのか：Appleの推奨とiOSの制限
廃止はされていません。Appleの[カスタムURLスキームの定義方法](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app)には「While custom URL schemes are an acceptable form of deep linking, universal links are strongly recommended.」とあり、許容される方式だがユニバーサルリンクを強く推奨する、という位置づけです。カスタムURLスキームへの対応、ユニバーサルリンクの推奨、問い合わせAPIの制限・非推奨化は、それぞれ別の話です。
### カスタムURLスキームの弱点：競合・入力検証・Webとの関連付け
- **横取り**：識別子に逆ドメイン形式を使っても、ほかのアプリが同じスキームを登録することは防げません。複数のアプリが同じスキームを登録した場合、どのアプリが開くかは未定義で、変更する手段もありません。
- **攻撃の入口**：「URL schemes offer a potential attack vector into your app」と明記され、すべてのパラメータの検証、不正な形式のURLの破棄、データ削除や機微情報へのアクセスを外部から許さないことが求められています。
- **Webとの一体性がない**：同じドキュメントは、Webサイトと一意に結びついたリンクを定義するならユニバーサルリンクを使うよう案内しています。
### canOpenURLの件数制限とiOS 27での非推奨化
他アプリのスキームを開けるか確かめる`canOpenURL(_:)`は、段階的に締め付けられてきました。Appleの[canOpenURL(\_:)のリファレンス](https://developer.apple.com/documentation/uikit/uiapplication/canopenurl%28%5F:%29)によると、iOS 9.0以降でリンクしたアプリは問い合わせるスキームを`Info.plist`の`LSApplicationQueriesSchemes`に宣言しなければならず、宣言していないスキームには常に`false`が返ります。宣言できる数は、iOS 15以降のSDKでリンクしたアプリで最大50件、iOS 27以降のSDKでリンクしたアプリで最大25件です。さらに、[iOS 27のリリースノート](https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-27-release-notes)で`canOpenURL(_:)`自体が非推奨になりました。Appleは事前確認の代わりにURLを開いて失敗を処理する方法、またはユニバーサルリンクへの移行を案内しています。
### Androidと認可フロー（OAuth）での扱い
Androidでもカスタムスキームは使えますが、公式ドキュメントは、同じスキームを別アプリが登録すると選択ダイアログが出うると説明しています。ログインの戻り先（リダイレクトURI）にカスタムスキームを使う場合は、横取り対策が必須です。ネイティブアプリのOAuthを定めた[RFC 8252](https://www.rfc-editor.org/rfc/rfc8252)は、カスタムスキームでは複数のアプリが同じスキームを登録でき、認可コードがどのアプリに届くか定まらないと指摘し、iOS 9以降ではユニバーサルリンクによる`https`の戻り先を推奨しています。カスタムスキームを使うなら[PKCE](/tech/details/16405/)を必ず組み合わせます。
判断としては、アプリ内の画面遷移や自社アプリ間の連携など、送り手と受け手を自分で管理できる用途ならカスタムURLスキームを残して構いません。メール・広告・SNSなど外へ配るリンクは、ユニバーサルリンクとApp Linksに置き換えます。
## ユニバーサルリンク・App Linksがアプリで開かない8つの条件
設定後もWebが開く原因には、OSやブラウザの仕様によるものと、検証ファイルや署名の設定不備によるものがあります。公式ドキュメントに書かれている条件を先に確認します。
1. **Safariで同じドメインのリンクをタップした**：Appleは、Safariで自サイトを見ている人が同じドメインのユニバーサルリンクをタップした場合はSafariのまま開く、と説明しています。別ドメインのリンクならアプリが開きます。自社サイトのページからアプリへ渡したいリンクは、別のサブドメインに置くと切り替わります。
2. **自分のアプリから自分のドメインを開いた**：アプリ自身が`open(_:options:completionHandler:)`やSwiftUIの`openURL`で自ドメインのユニバーサルリンクを開いても、そのアプリには戻りません。
3. **アドレス欄にURLを直接入力した**：Appleのデバッグ手引き[TN3155](https://developer.apple.com/documentation/technotes/tn3155-debugging-universal-links)は、ブラウザのアドレス欄への直接入力はブラウザ内の移動なので、アプリは決して開かないと説明しています。動作確認はメモアプリに貼ったリンクから行います。
4. **以前に「Safariで開く」を選んだ**：リンクを長押しして表示される選択肢で選んだ動作は、そのドメインのユニバーサルリンクの既定になります。戻すには同じ手順でアプリを選び直します。
5. **設定ファイルがリダイレクトやHTTPで配信されている**：`apple-app-site-association`は拡張子なしで、有効な証明書の`https`からリダイレクトなしで配信する必要があります。`assetlinks.json`も`https`・リダイレクトなし（301・302不可）・`content-type: application/json`が条件です。`www`ありなしの転送ルールに巻き込まれる事故が典型です。
6. **Appleのキャッシュが古い**：iOS 14・macOS 11以降、端末はWebサーバーではなくApple管理のCDNから`apple-app-site-association`を取得します。サーバーを直してもすぐに反映されないことがあります。
7. **Android 11以下で一部のホストだけ検証に失敗した**：Android 11（API 30）以下は、マニフェストに書いた全ホストで`assetlinks.json`が一致したときだけ既定のハンドラーになります。1ホストの失敗で全体が開かなくなります。
8. **Androidの署名フィンガープリントが違う**：Play App Signingを使っていると、手元で`keytool`から出した値は利用者の端末に入るアプリの署名と通常一致しません。Play Consoleの［リリース］→［設定］→［アプリの署名］に正しい値が載っています。
Safari以外のブラウザでユニバーサルリンクを有効にするかは各ブラウザの実装次第で、TN3155もブラウザの提供元に確認するよう案内しています。
## iOSの実装手順：AASAの書き方と受け取りコード
手順は3つです。Webサーバーに`apple-app-site-association`を置く、XcodeでAssociated Domainsを設定する、アプリでURLを受け取る、の順に進めます。
### apple-app-site-associationのcomponents記法
ファイルは`https://<ドメイン>/.well-known/apple-app-site-association`に置きます。現在の書式は`appIDs`と`components`です（古い`appID`・`paths`形式も後方互換で動きます）。サブドメインごとにファイルとentitlementの登録が必要です。
```
{
"applinks": {
"details": [
{
"appIDs": ["ABCDE12345.com.example.app"],
"components": [
{ "/": "/product/*/review", "exclude": true },
{ "/": "/product/*" }
]
}
]
}
}
```
`components`は配列の上から順に照合され、最初に一致した規則が採用されます（Appleの[components のリファレンス](https://developer.apple.com/documentation/bundleresources/applinks/details-swift.dictionary/components-swift.dictionary)の「The first match wins」）。除外したいパスは、それを含む広い規則より前に書きます。上の例で除外を2行目に置くと、レビュー画面のURLも先に`/product/*`に一致してアプリで開きます。
### Associated DomainsとAppleのCDN
Xcodeの［Signing & Capabilities］でAssociated Domainsを追加し、`applinks:example.com`の形でドメインを登録します。パスや末尾のスラッシュは書きません。iOS 14以降、端末はApple管理のCDNからファイルを取得し、CDNに古い版しか無いときやコピーが無いときはCDNがWebサーバーへ最新版を取りに行きます。CDNが持っている内容は次のURLで確認できます。
```
curl -s https://app-site-association.cdn-apple.com/a/v1/example.com
```
開発中の非公開サーバーを使う場合は、entitlementを`applinks:dev.example.com?mode=developer`とします。開発用プロビジョニングプロファイルで署名したアプリに限られ、端末側でも［設定］→［デベロッパ］のAssociated Domains Developmentを有効にすると、CDNを迂回してサーバーへ直接取りに行きます。同じ画面のDiagnosticsにURLを入力すると、インストール済みのアプリで有効なリンクかを判定できます。Macでは`sudo swcutil dl -d example.com`で、AASAを取得できるかを確かめられます。
### アプリでURLを受け取るコード（SwiftUI・UIKit）
SwiftUIのライフサイクルなら、`onOpenURL`でユニバーサルリンクもカスタムURLスキームも受け取れます。
```
@main
struct ShopApp: App {
@State private var path: [Int] = []
var body: some Scene {
WindowGroup {
ContentView(path: $path)
.onOpenURL { url in
// https://example.com/product/123 を想定
guard url.scheme == "https",
url.host == "example.com",
url.pathComponents.count == 3,
url.pathComponents[1] == "product",
let id = Int(url.pathComponents[2]) else { return }
path = [id]
}
}
}
}
```
UIKitのシーンでは、ユニバーサルリンクは`NSUserActivity`として届きます。起動中・バックグラウンドからの復帰では`scene(_:continue:)`、未起動からの起動では`scene(_:willConnectTo:options:)`の`connectionOptions.userActivities`に入るため、両方で同じ処理を呼びます。iOS 27のリリースノートは、最新のSDKでビルドしたアプリはシーンベースのライフサイクルを採用しないと起動しないとしているため、AppDelegateだけで受け取る古い実装は移行が必要です。Appleは[ユニバーサルリンクの受け取り方](https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app)でも、URLスキームと同じくパラメータをすべて検証し、不正な形式のURLは捨てるよう求めています。シーンの仕組みは[UIKitとSwiftUIの比較記事](/column/details/1462/)で扱っています。
```
func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
let url = userActivity.webpageURL,
let components = URLComponents(url: url, resolvingAgainstBaseURL: true) else {
return
}
// components.path と components.queryItems から遷移先を決める
router.open(path: components.path, query: components.queryItems ?? [])
}
```
## Androidの実装手順：intent-filterとassetlinks.json
Androidは、マニフェストで対象のURLを宣言し、Webサーバーで署名を証明する二段構えです。
### intent-filterとassetlinks.jsonの書き方
App Linksにするには`android:autoVerify="true"`を付け、`VIEW`・`DEFAULT`・`BROWSABLE`の3つを揃えます。`DEFAULT`が欠けると、検証が通っても暗黙インテントで起動されません。
```
```
Webサーバーには`https://example.com/.well-known/assetlinks.json`を置きます。`sha256_cert_fingerprints`には複数の値を書けるので、デバッグ用と本番用を並べられます。値の出し方と注意点はAndroidの[assetlinks.jsonの設定ガイド](https://developer.android.com/training/app-links/configure-assetlinks)にあります。
```
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.app",
"sha256_cert_fingerprints": ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
```
アプリ側では、新しいActivityが作られる場合は`onCreate`でURLを読みます。起動モードやIntentのフラグによって既存のActivityが再利用される場合に備え、`onNewIntent`でも同じ処理を呼びます。
```
class ProductActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
handleLink(intent)
}
override fun onNewIntent(intent: Intent) {
super.onNewIntent(intent)
handleLink(intent)
}
private fun handleLink(intent: Intent) {
val uri = intent.data ?: return
// https://example.com/product/123 の形だけを受け付け、IDが数字でなければ捨てる
if (intent.action != Intent.ACTION_VIEW ||
uri.scheme != "https" || uri.host != "example.com") return
val segments = uri.pathSegments
if (segments.size != 2 || segments[0] != "product") return
val id = segments[1].toLongOrNull() ?: return
showProduct(id)
}
}
```
### 検証状態を確かめるadbコマンド
Android 12以降の端末では検証を手動でやり直せます。掲載コマンドはtargetSdkVersionが31以上のアプリを想定しています。31未満では、先に`adb shell am compat enable 175408749 com.example.app`で新しい検証処理を有効にします。手順はAndroidの[App Linksの検証ガイド](https://developer.android.com/training/app-links/verify-android-applinks)のとおりです。
```
# 状態をリセットしてから再検証する
adb shell pm set-app-links --package com.example.app 0 all
adb shell pm verify-app-links --re-verify com.example.app
# 数分待ってから結果を見る
adb shell pm get-app-links com.example.app
```
ドメインの状態が`verified`なら成功です。`legacy_failure`は旧来の検証で拒否されたこと、`none`は検証の記録が無いこと、1024以上の数値は端末側の検証エラーを表します。Android 15（API 35）以降では、`assetlinks.json`側で対象パスを後から変えられるDynamic App Linksも使えますが、Android 14以下では無視されるため、除外の規則は旧OSでは効きません。
## Firebase Dynamic Links終了後の選び方
動的ディープリンクの定番だったFirebase Dynamic Links（FDL）は、[FirebaseのFAQ](https://firebase.google.com/support/dynamic-links-faq)のとおり2025年8月25日に終了しました。独自ドメインと`page.link`のどちらのリンクもクリックするとHTTP 404を返し、新規作成もできません。移行先は2択です。
- **OS標準（ユニバーサルリンク＋App Links）**：リンク機能そのものに利用料はかかりませんが、開発・配信基盤・保守の費用は別途必要です。遅延ディープリンクと流入計測も追加で実装します。既存ユーザー向けの共有・メール・通知が中心ならこれで足ります。
- **外部のディープリンク・計測サービス**：FirebaseのFAQは、FDLと同等の機能が要る場合の移行先としてAdjust、Airbridge、AppsFlyer、Bitly、Branch、Kochava、Singularなどを挙げています（Googleが審査したものではないと注記付き）。対応機能、SDKの組み込み要否、料金はサービスや契約プランによって異なるため、遅延ディープリンクとインストール計測の要件に照らして確認します。
広告経由のインストール計測が要る導線だけを外部サービスに寄せ、残りはOS標準にする組み合わせが費用を抑えやすい構成です。他社のアプリ・WebサイトをまたぐトラッキングやIDFAへのアクセスにはiOSのATT（トラッキング許可）が必要になるため、[広告識別子（IDFA・AAID）](/column/details/5835/)の扱いも同時に設計します。旧短縮リンクの棚卸しなど移行作業の手順は[Firebase Dynamic Linksの終了と移行の記事](/tech/details/17054/)にまとめています。iOS・Android両方のアプリでリンクの受け口を揃える開発は、[一創のスマホアプリ開発](/service/apps/native/)でも設計から対応しています。
## よくある質問
### ディープリンクとは何ですか？
リンクをタップしたときに、アプリのトップではなく商品・記事・予約画面などの特定の画面を直接開く仕組みです。iOSではユニバーサルリンク、AndroidではApp Links、両OS共通ではカスタムURLスキームで実現します。
### ディープリンクとユニバーサルリンクの違いは？
ディープリンクは「アプリ内の特定画面を開く」という目的の総称で、ユニバーサルリンクはそれをiOSで実現する方式の一つです。ユニバーサルリンクは`https`のURLを使い、ドメインの所有を`apple-app-site-association`で証明するため、アプリが無い端末ではWebページが開き、他アプリに横取りされません。
### カスタムURLスキームは廃止されたのですか？
廃止されていません。Appleは許容される方式としたうえでユニバーサルリンクを強く推奨しています。ただし、`canOpenURL(_:)`で問い合わせられるスキームはiOS 15以降のSDKでリンクしたアプリでは最大50件、iOS 27以降のSDKでリンクしたアプリでは最大25件です。これは宣言できるスキーム数の制限であり、URLを開く回数の制限ではありません。また、iOS 27ではこのAPI自体が非推奨です。
### Androidでディープリンクを設定する方法は？
マニフェストのintent-filterに`android:autoVerify="true"`と`VIEW`・`DEFAULT`・`BROWSABLE`、`https`のホストを書き、Webサーバーの`/.well-known/assetlinks.json`に署名のSHA-256フィンガープリントを置きます。検証結果は`adb shell pm get-app-links`で確認できます。
### Firebase Dynamic Linksはまだ使えますか？
使えません。2025年8月25日に終了し、既存のリンクは404を返します。OS標準のユニバーサルリンクとApp Linksへ移し、遅延ディープリンクが要る導線だけ外部サービスか自前の実装で補います。
## 関連記事
- [Firebase Dynamic Linksの終了と移行｜停止後に残る作業とUniversal Links／App Linksへの移行手順【2026年8月時点】](/tech/details/17054/)
- [App Indexingとは？Firebase版が非推奨になった後の仕組みと実装手順【2026年時点】](/column/details/7070/)
- [PKCEとは？認可コード横取り攻撃を防ぐcode\_verifierの実装と検証設計を解説](/tech/details/16405/)
- [UIKitとは？SwiftUIとの違いをコードで比較、iOS 27の変更点と併用の書き方](/column/details/1462/)
- [広告識別子（広告ID）とは？ADID・IDFA・AAIDの違いと確認・リセット・削除](/column/details/5835/)
---
出典: [ディープリンクとは？ユニバーサルリンク・URLスキーム・App Linksの違いと実装手順]()（株式会社一創）