Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ウェブサイトの関連付けと動的ルールを構成する

アプリリンクをサポートするには、デジタルアセットリンク JSON ファイルを作成し、ウェブサイトの既知の場所に公開する必要があります。assetlinks.jsonこのファイルは、ドメインのリンクを処理する権限を持つアプリを公開し、Android デバイスはこのファイルをサーバーから取得してディープリンクを検証します。

Android 15 以降の動的アプリリンクの場合、assetlinks.json ファイルは、パス、フラグメント、クエリパラメータのパターンマッチャーなど、動的ルール構成を定義する場所でもあります。Google サービスがインストールされている Android 15（API レベル 35）以降を搭載した Android デバイスは、このファイルを定期的に取得し、動的構成をアプリのマニフェストの静的構成とマージします。

このガイドでは、assetlinks.json ファイルを準備してウェブサイトに公開する方法について説明します。必要に応じて、Google Play のディープリンクツールまたは Android Studio のアプリリンクアシスタントから assetlinks.json ファイルを生成することもできます。詳しくは、アプリリンクデベロッパーツールをご覧ください。

ウェブサイトの関連付けを宣言する

ウェブサイトに関連付けられている Android アプリを示し、アプリの URL インテントを証明するために、デジタルアセットリンク JSON ファイルをウェブサイト上で公開する必要があります。JSON ファイルは、関連付けられたアプリを識別するために次のフィールドと使用します。

package_name：アプリの build.gradle ファイルで宣言されているアプリケーション ID。
sha256_cert_fingerprints: アプリの署名証明書の SHA256 フィンガープリント。このフィンガープリントは、Java Keytool で次のコマンドを使用することで生成できます。

keytool -list -v -keystore my-release-key.keystore

このフィールドは複数のフィンガープリントをサポートしており、デバッグビルドや実稼働ビルドなど、アプリのさまざまなバージョンをサポートすることができます。アプリで Play アプリ署名を使用している場合、ローカルでkeytoolを実行して生成される証明書のフィンガープリントは通常、ユーザーのデバイス上の証明書と一致しません。アプリで Play アプリ署名を使用しているかどうかは、Google Play Console のデベロッパーアカウントの Release > Setup > App signing で確認できます。使用している場合は、同じページにアプリの正しいデジタルアセットリンクの JSON スニペットが表示されます。

次の assetlinks.json ファイルの例では、com.example Android アプリにリンクを開く権限を付与しています。

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example",
    "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"]
  }
}]

1 つのウェブサイトを複数のアプリに関連付ける

1 つの assetlinks.json ファイル内で、1 つのウェブサイトを複数のアプリに関連付けることを宣言できます。次のファイルリストは、2 つのアプリとの関連付けを個別に宣言する、https://www.example.com/.well-known/assetlinks.json にあるステートメントファイルの例です。

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.puppies.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"]
  }
  },
  {
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.monkeys.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"]
  }
}]

1 つのウェブホストにある複数のリソースに対してそれぞれ個別のリンクを用意し、各リンクを別のアプリで処理することができます。たとえば、app1 は https://example.com/articles 用のインテントフィルタを宣言し、app2 は https://example.com/videos 用のインテントフィルタを宣言する、というように指定できます。

複数のウェブサイトを 1 つのアプリに関連付ける

複数のウェブサイトが、それぞれ独自の assetlinks.json ファイルを使用して、同一のアプリに対して関連付けを宣言することができます。次のファイルリストは、example.com と example.net を app1 に関連付ける方法の例を示しています。最初のリストは、example.com と app1 の関連付けを示しています。

https://www.example.com/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "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"]
  }
}]

次のリストアイテムは、example.net と app1 の関連付けを示しています。これらのファイルがホストされている場所のみが異なります（.com と .net）。

https://www.example.net/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "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"]
  }
}]

動的ルールを構成する

Android 15 以降の動的アプリリンクでは、アプリのマニフェストで静的に定義したルールと連携して動作するサーバーサイドのディープリンクマッチングルールを使用できます。assetlinks.json ファイルで動的ルールを定義します。これは省略可能です。

Google サービスがインストールされている Android 15（API レベル 35）以降を搭載した Android デバイスは、このファイルをサーバーから定期的に取得し、動的ルール構成をアプリのマニフェストの静的構成とマージします。動的ルールを含む assetlinks.json ファイルの例を次に示します。

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.example.app",
      "sha256_cert_fingerprints": [...]
    },
    "relation_extensions": {
      "delegate_permission/common.handle_all_urls": {
        "dynamic_app_link_components": [
          {"?": {"dl": "*"}},
          {"#": "app"},
          {"/": "/products/*"},
          {"/": "/shoes", "?": {"in_app": "true"}},
          {"/": "*", "exclude": true}
        ]
      }
    }
  }
]

コードに関する主なポイント

動的アプリリンクでは、dynamic_app_link_components という新しいデジタルアセットリンクの関連拡張機能が追加されます。ここで動的ルールを構成します。
動的ルールには、パス、フラグメント、クエリパラメータのパターンマッチャーを含めることができます。
パターンマッチャーを除外としてマークして、一致する URL でアプリが開かないようにすることもできます。
この例では、パス（"/"）、フラグメント（"#"）、クエリパラメータ（"?"）のマッチャーと、除外されたマッチャー（"exclude"）の例を示します。
ファイル内のいずれかのフィールドが不正な形式であるか空の場合、Android は動的ルールを破棄し、デバイスはアプリのマニフェストで静的に定義されているルールにフォールバックします。

動的ルールでは、アプリのマニフェストファイルで宣言したドメインのスコープ内で適用されるルールのみを指定できます。動的ルールを宣言するをご覧ください。

動的ルールを宣言する

動的アプリリンクは、ルールのオブジェクトの配列を保持する新しい dynamic_app_link_components 関連拡張機能をサポートしています。各ルールは、アプリを開くパス、フラグメント、クエリパラメータのパターンマッチャーを使用して定義されます。マッチャーを個別に除外して、アプリが開かないようにすることもできます。これらはすべて省略可能です。

パスマッチング
- キー: "/"
- 値: 単一の文字列、URL パスのマッチング式
フラグメントマッチング
- キー: "#"
- 値: 単一の文字列、URL フラグメントのマッチング式
クエリパラメータマッチング
- キー: "?"
- 値: URL クエリパラメータの Key-Value ペアを照合するディクショナリ。
- たとえば、ディクショナリ "?", {"dl": "*", "in_app":"true" はクエリ文字列 "?in_app=true&dl=abc" と一致します。
- ディクショナリ内の Key-Value ペアの順序は、クエリ文字列内のペアの順序と一致する必要はありません。また、ディクショナリはクエリ文字列内のすべての Key-Value ペアと一致する必要はありませんが、ディクショナリエントリごとに一致するものが見つかる必要があります。
- たとえば、このディクショナリはクエリ文字列 "?lang=en&in_app=true&tz=pst&dl=abc"とも一致しますが、クエリ文字列 "?lang=en&tz=pst&dl=abc"とは一致しません。
除外
- キー: "exclude"
- 値: dynamic_app_link_components で定義された各ルールの省略可能な true/false 値（例を参照）。

パターンマッチャーでは、次の特殊文字を使用できます。

「*」は、パターン内のワイルドカードの後の文字が一致する文字列で見つかるまで、0 個以上の文字と一致します。
「?」は任意の 1 文字と一致します。
「?*」は 1 文字以上の文字と一致します。

値には、その他の文字制限はありません。

動的ルールを並べ替える

ルールが宣言される順序が重要です。Android は、一致するものが見つかるまで各ルールを順番に評価します。

次の例は、順序が処理にどのように影響するかを示しています。最初のルールはすべてのパス（「*」）と一致しますが、一致を除外します（exclude: true）。つまり、すべての URL でアプリが開かないようにします。この場合、「/path1」を許可する 2 番目のルールは評価されません。

dynamic_app_link_components: [
  {"/": "*", "exclude": true},
  {"/": "/path1"}
]

ただし、次の例では、「/path1」ルールが最初に宣言されるため、最初に評価され、「/path1」と一致する URL でアプリが開きます。すべての URL でアプリが開かないようにする 2 番目のルールは、最初のルールが一致しない場合にのみ評価されます。

dynamic_app_link_components: [
  {"/": "/path1"},
  {"/": "*", "exclude": true}
]

宣言されたコンポーネントのリストに一致するものがない場合、URL でアプリは開きません。次の例では、どのパスも「/path3」と一致しないため、デバイスはこのパスを除外として扱います。

dynamic_app_link_components: [
  {"/": "/path1"},
  {"/": "/path2"}
]

この動作は、dynamic_app_link_components で特定の URL 部分のみを除外し、他のすべての部分を許可する場合に重要です。次の例では、残りのすべてのパスを許可する最後のルールを省略すると、すべての URL がアプリから除外されます。

dynamic_app_link_components: [
  {"/": "/path1", "exclude": true},
  {"/": "*"}
]

動的ルールのスコープを適切に設定する

Android 15 以降で動的アプリリンクで使用するサーバーサイドルールを定義する場合は、アプリマニフェストで宣言された静的インテントフィルタと連携して動作し、補完するように、適切にスコープを設定することが重要です。

assetlinks.json ファイルで宣言された動的ルールでは、アプリの AndroidManifest.xml ファイルで宣言したホストのルールのみを指定できます。動的ルールでは、アプリマニフェストで静的に宣言した URL ルールのスコープを拡大することはできません。

このため、動的ルールと静的ルールで次のアプローチを使用することをおすすめします。

アプリマニフェストで、スキームとドメインのみを宣言するなど、可能な限り広いスコープでルールを設定します。
パスレベルのルーティングなど、サーバーサイドの動的ルールを使用してさらに絞り込みます。

この理想的な構成では、アプリマニフェストで設定した広いスコープ内に収まるように、必要に応じて assetlinks.json ファイルに新しいアプリリンクパスを動的に追加できます。

dynamic_app_link_components を 1 回だけ宣言する

ルールを適切に処理するには、特定のサイト、関連付け、アプリのステートメント全体で dynamic_app_link_components オブジェクトを 1 つだけ宣言します。

同じサイト、関連付け、アプリに対して、dynamic_app_link_components オブジェクトを宣言する複数のステートメントを探します。
1 つのステートメントで宣言されている複数の dynamic_app_link_components オブジェクトを探します。

このような場合、Android ではどの動的ルール構成が使用されるかは保証されません。

以前のアプリリンク構成との動的ルールの互換性

すでにアプリリンクをサポートしている場合は、既存の assetlinks.json ファイルに動的アプリリンクのサポートを直接追加できます。アプリリンクを検証するための関連フィールドは変更されず、他の変更を加えることなく、動的ルールの新しい関連拡張フィールドを追加できます。

Android 14（API レベル 34 以前）を搭載した Android デバイスは、動的ルールの新しい関連拡張フィールドを無視しますが、Android 15 以降を搭載したデバイスは、これらのルールをマニフェストで定義されたルールとマージします。

JSON 検証ファイルを公開する

次の場所で JSON 検証ファイルを公開する必要があります。

https://domain.name/.well-known/assetlinks.json

注:

assetlinks.json ファイルは、content-type application/json で配信されます。
アプリのインテントフィルタが HTTPS をデータスキームとして宣言しているかどうかにかかわらず、assetlinks.json ファイルは HTTPS 接続でアクセスできる必要があります。
assetlinks.json ファイルは、リダイレクトなしでアクセスできる必要があります（301 リダイレクトや 302 リダイレクトなし）。
アプリリンクが複数のホストドメインをサポートしている場合、各ドメインで assetlinks.json ファイルを公開する必要があります。複数のホスト用のアプリリンク機能をサポートするをご覧ください。
誰もがアクセスできるわけでないテスト URL をマニフェストファイル内で使用してアプリを公開しないでください（VPN 内に限りアクセス可能なテスト URL など）。このような場合の回避策は、ビルドバリアントを構成して、開発ビルド用に別のマニフェストファイルを生成することです。

次の関連ガイドをご覧ください。