モバイルアプリとディープリンク

短縮リンクからアプリを開き、アプリがなければストアへ送り、関連付けファイルを自分のドメインで配信し、インストール後にクリックの情報を読み取ります。

2026年8月14日更新

モバイルアプリへ導く短縮リンクは、同時に3種類の相手を抱えています。すでにアプリを持っている人、持っていない人、そしてブラウザーが別のアプリの中にある人です。このページでは、その3つすべてに加えて、違いを生む2つの設定——ドメイン上の関連付けファイルと、アプリが初回起動時に読み取れる、後から届くクリックの情報——を扱います。

モバイルのセクションでできること

リンクを開き、モバイルタブでモバイル向けのリンク先を有効にします。プラットフォームごとに、3つのアドレスを設定できます。

アプリのリンク — アプリ内のアドレスです。独自のスキームとパス（myapp://product/42）、Androidのintent、あるいはユニバーサルなhttpsリンクを指定します。
ストアのアドレス — App StoreまたはGoogle Playのページで、アプリが開かなかったときに使われます。
Webの代替リンク先 — そもそもストアへ送りたくない訪問者のためのページです。

どれも必須ではありません。ストアのアドレスだけを設定したリンクは、単なるストアへのリダイレクトです。アプリのリンクとストアのアドレスの両方を設定すると、本来の動きになります。ページはまずアプリを試し、何も起きなければストアへ進みます。

残る2つの設定は、通常のスマートフォンのブラウザー以外で開かれたときの動きを決めます。

タブレット — スマートフォンとして扱う（既定）か、デスクトップとして扱うかを選びます。
アプリ内ブラウザー — Instagram、TikTok、Facebookなどのアプリの中でリンクが開かれたときの動きです。

デスクトップの訪問者は、デスクトップのリンク先を設定していればそこへ、していなければリンクのメインのリンク先へ進みます。モバイルのセクションは、あなたが望まない限り、デスクトップの訪問者に見えるものを何ひとつ変えません。

アプリ内ブラウザーに専用の設定が要る理由

SNSのフィード上でのリンクのクリックは、その多くがSafariやChromeに届きません。アプリ自身の中のWebビューで開かれ、そうしたWebビューのいくつかは、あらゆる遷移を自分の中に抱え込みます。ユニバーサルリンクはWebビューに留まり、独自スキームは黙って何もしません。これはリンク側から直せる不具合ではありません。そのWebビューを持つアプリが下した決定です。

そこでこの設定は、正直な選択肢を3つ用意しています。

| 選択肢 | 訪問者に起きること | | --- | --- | | アプリを開こうとする | 中間ページがアプリのリンクを試します。そのWebビューが妨げると分かっている場合は、待ち時間を省いて、スマートフォンのブラウザーでリンクを開き直す方法を案内します。 | | そのままストアへ進む | アプリを試みることはいっさいありません。ストアのページが目的であるインストール施策に向いています。 | | Webの代替リンク先へ進む | 訪問者はWebに留まります。コンテンツへのリンクでは、これが最善であることが少なくありません。 |

関連付けファイル——リンクが黙ってアプリを開くための設定

リンクがブラウザーを経由せずにアプリを開くには、あなたのドメインとアプリが同じ持ち主のものであることを、OSが知っている必要があります。どちらのプラットフォームも、それをドメイン自身から配信されるファイルで確認します。

https://go.brand.com/.well-known/apple-app-site-association
https://go.brand.com/.well-known/assetlinks.json

これらのファイルをご自分で書く必要はありません。ドメインでそのドメインを開き、モバイルアプリの下にアプリを追加してください。

iOSの場合：TEAMID.com.company.appという形式のアプリIDと、アプリが処理すべきパス（*ですべての短縮リンクが対象になります）。
Androidの場合：パッケージ名と、Play Consoleで確認できるSHA-256の署名フィンガープリント。

プラットフォームは両方のファイルを組み立て、あなたのドメインから、両OSが求めるとおりの応答で配信します。ステータス200、リダイレクトなし、application/json、転送時の圧縮なしです。最後の1つは、聞こえる以上に重要です。転送の途中でファイルをgzip圧縮するプロキシは、アプリのリンクが黙って動かなくなる原因として最もよくあるものの1つです。

設定を確認する

ファイルを確認ボタンは、稼働中のドメインから両方のファイルを取得し、プラットフォームから見える状態を報告します。検出内容は、それぞれ具体的な対処に対応しています。

| 検出内容 | 対処 | | --- | --- | | ドメインが応答しませんでした | ドメインがまだトラフィックを配信していないか、DNSの伝播が続いています。 | | ファイルがありません | このドメインにアプリが1つも設定されていないか、リクエストがプラットフォームまで届いていません。 | | ドメインがこのアドレスをリダイレクトしています | ドメインの手前にある何かが/.well-known/を書き換えています。各プラットフォームは、ここでのリダイレクトをたどりません。 | | 種類が正しくありません | 応答がHTMLです。多くは別のサービスが返す404ページです。 | | 応答が圧縮されて届いています | プロキシがファイルを圧縮しています。両OSの検証は、これで失敗することがあります。 | | アプリが宣言されていません | ファイル自体は正しいものの、そのプラットフォーム向けの中身が空です。ダッシュボードでアプリを追加してください。 |

ファイルを配置したあと、両プラットフォームはそれを自前のCDNにキャッシュするため、新しく入れたアプリが変更を拾うまでに時間がかかることがあります。テスト中に読み直しを確実に起こさせる方法は、アプリを入れ直すことです。

インストール後に届くクリックの情報

アプリを持っていない訪問者がリンクをクリックし、ストアに着き、アプリをインストールして開きます。その時点で、アプリはその人がどこから来たのかを何も知りません。ブラウザーのセッションとアプリは、互いに無関係な2つの世界だからです。

インストール後にクリックの情報を引き渡すを有効にすると、プラットフォームは短いデバイスのフィンガープリントを2時間ほど保持します。内容は、プラットフォーム、OSのメジャーバージョン、言語、国、画面サイズ、タイムゾーン、通信事業者です。IPアドレスも、広告識別子も、個人までたどれるものも含まれていません。

初回起動時に、アプリはプラットフォームへ、クリックがあったかどうかを問い合わせます。

curl -X POST https://go.brand.com/__dl/claim \
  -H 'content-type: application/json' \
  -d '{
    "platform": "ios",
    "os_version": "17.4",
    "language": "de",
    "timezone_offset": 120,
    "screen_width": 1170,
    "screen_height": 2532,
    "pixel_ratio": 3
  }'

一致した場合は、元のリンクとそのキャンペーンタグが返ります。

{
  "matched": true,
  "confidence": "high",
  "score": 100,
  "matched_on": ["screen", "timezone_offset", "language", "os_version"],
  "url": "myapp://product/42",
  "domain": "go.brand.com",
  "slug": "promo",
  "link_id": "lnk_...",
  "utm": { "utm_source": "newsletter" },
  "click_id": "...",
  "clicked_at": "2026-08-14T10:00:00.000Z"
}

一致しなかった場合は{"matched": false}が返ります。同じクリックに対する2回目のリクエストでも同じです。記録が引き渡されるのは、ちょうど1回だけだからです。

制約を、率直に

照合は確率的です。 同じ機種、同じネットワーク、同じタイムゾーン、同じ言語の2台の端末は、この方法では見分けが付きません。だからこそ、どの応答にもconfidenceと、判定に使われた属性の一覧が付きます。highは直近のクリックで画面サイズとタイムゾーンがどちらも一致したことを、lowは事実ではなく手掛かりとして扱うべきことを意味します。
有効なのは日単位ではなく、時間単位です。 フィンガープリントはクリックから2時間で失効し、最初の15分を過ぎると確からしさは下がります。
リクエストは初回起動時に1回だけ送ってください。 記録は最初に一致した時点で消費されるため、2回目の呼び出しでは何も返りません。
中間ページを挟まないストアへのリダイレクトでは、集まる情報が少なくなります。 画面サイズとタイムゾーンを知っているのはブラウザーで動くページだけなので、そのままストアへ進むリンクは、言語とOSのバージョンだけで照合します。応答にもそう示され、確からしさは低くなります。

テストのチェックリスト

アプリをインストールしたスマートフォンでリンクを開きます。アプリの中に着くはずです。
アプリを入れていない端末で開きます。ページが一瞬表示され、ストアが開きます。
SNSのフィードから開きます。アプリ内ブラウザーの設定が、期待どおりに働いているか確認します。
デスクトップのブラウザーで開きます。デスクトップのリンク先か、メインのリンク先へ進みます。
そのドメインでファイルを確認を実行し、両方のファイルに問題がないことを確かめます。