Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

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

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

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

ウェブサイトでデジタルアセットリンクの JSON ファイルを公開して、ウェブサイトに関連付けられている Android アプリを示し、アプリの URL インテントを検証する必要があります。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"]
  }
}]

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

ウェブサイトは、同じ assetlinks.json ファイル内で複数のアプリとの関連付けを宣言できます。次のファイルリストは、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"]
  }
}]

同じウェブホストの下にある異なるリソースのリンクを、異なるアプリが処理する場合があります。たとえば、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 以降の Dynamic App Links では、アプリマニフェストで静的に定義したルールと連携するサーバーサイドのディープリンクマッチングルールを使用できます。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 Links では、dynamic_app_link_components という新しい Digital Asset Links の関係拡張機能が追加されます。ここで動的ルールを構成します。
動的ルールには、パス、フラグメント、クエリパラメータのパターンマッチャーを含めることができます。
また、任意のパターンマッチャーを除外としてマークして、一致する URL がアプリを開かないようにすることもできます。
この例では、パス（"/"）、フラグメント（"#"）、クエリパラメータ（"?"）のマッチャーと、除外されたマッチャー（"exclude"）の例を示しています。
ファイル内のいずれかのフィールドが不正な形式であるか空の場合、Android は動的ルールを破棄し、デバイスはアプリのマニフェストで静的に定義されているルールにフォールバックします。

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

動的ルールを宣言する

Dynamic App Links は、ルールオブジェクトの配列を保持する新しい 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 のアプリが開きます。2 つ目のルール（すべての URL でアプリを開かないようにする）は、2 番目に評価されますが、最初のルールが一致しない場合にのみ評価されます。

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

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

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

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

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

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

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

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 ファイルに動的アプリリンクのサポートを直接追加できます。App Links を検証するための関係フィールドは同じままで、他の変更を加えずに動的ルールの新しい関係拡張フィールドを追加できます。

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

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

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

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

注:

assetlinks.json ファイルはコンテンツタイプ application/json で提供されます。
アプリのインテントフィルタで HTTPS がデータスキームとして宣言されているかどうかに関係なく、assetlinks.json ファイルが HTTPS 接続でアクセス可能である必要があります。
assetlinks.json ファイルは、リダイレクトなし（301 または 302 リダイレクトなし）でアクセス可能である必要があります。
アプリリンクが複数のホストドメインをサポートしている場合は、各ドメインで assetlinks.json ファイルを公開する必要があります。複数のホストのアプリリンクをサポートするをご覧ください。
一般ユーザーがアクセスできない可能性のあるテスト URL（VPN でのみアクセス可能な URL など）をマニフェストファイルに含めてアプリを公開しないでください。このような場合の回避策は、ビルドバリアントを構成して、開発ビルド用に別のマニフェストファイルを生成することです。

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