更新の制約
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このドキュメントは、Update API(v4)メソッド threatListUpdates.fetch に適用されます。
制約の設定
ローカル データベースを更新する場合(データベースの更新を参照)、クライアントは threatListUpdates.fetch リクエストの maxUpdateEntries
フィールドと maxDatabaseEntries
フィールドを使用してサイズ制約を指定できます。クライアントは、クライアントの RAM、ディスク、帯域幅の予測可能な消費量を維持し、リストの増加を防ぐために制約を設定する必要があります。
- クライアントは、更新レスポンスの最大サイズ(
maxUpdateEntries
)をエントリ数に指定できます(1 エントリ = 1 追加または 1 削除)。
- クライアントは、最大データベース サイズ(
maxDatabaseEntries
)をエントリ数で指定できます(データベース内のエントリの大半は 4 バイトのハッシュ プレフィックスであるため、1 エントリを約 4 バイトと想定して構いません)。
帯域幅とストレージ
クライアントではアップデート レスポンスとデータベースのサイズに任意のサイズを指定できますが、セーフ ブラウジング サーバーが事前生成するアップデート レスポンスとデータベースのサイズには限りがあります。
- クライアントは、帯域幅の使用量を制限するために、更新レスポンスのサイズ(
maxUpdateEntries
)を使用する必要があります。
- クライアントはデータベース サイズ(
maxDatabaseEntries
)を使用して、デバイスで必要な RAM またはディスク ストレージの量を制限する必要があります。
どちらの上限も、更新されるデータベースのサイズに影響するため、ユーザーに提供される保護のレベルにも影響します(つまり、ローカル データベースのサイズが大きいほど保護が向上します)。
制約の設定に関するガイダンス
セーフ ブラウジング リストのサイズは、段階的または突然変わることがあります。クライアントは、リスト更新リクエストに対して maxUpdateEntries
を設定する必要があります。これにより、リスト更新レスポンスの最大サイズが制限され、大規模な更新を処理できない場合の信頼性が向上します。
より厳しい要件やそれほど厳格でない要件がない場合は、maxUpdateEntries=16777216
を使用することをおすすめします。一般的なリストエントリのサイズはハッシュ プレフィックスあたり 4 バイトであるため、リストあたり約 67 メガバイトに相当します。モバイル クライアントの場合は通常、容量が小さいため、上限を maxUpdateEntries=2097152
に設定することをおすすめします。一般的なリストエントリ サイズがハッシュ プレフィックスあたり 4 バイトの場合、リストあたり約 8 MB に相当します。
セーフ ブラウジング リストはサイズと増加率が異なります。ただし、クライアントは各リストで許容されるメモリまたは帯域幅の最大使用量に基づいて、すべてのリストに同じ制約を設定する必要があります。
Google では、信頼性を向上させるために、メモリまたは帯域幅の過剰使用を検出するためのテレメトリーと、クライアントに新しい制約を迅速に提供するメカニズムをクライアントで実装することをおすすめします。
クライアントの状態
セーフ ブラウジング サーバーが、クライアントを古い状態のままにする更新を送信することはありません。更新リクエストが行われるたびに、クライアントは完全に最新の状態になります。たとえば、クライアントに現在 4,096 エントリのデータベースがあり、ダウンロードできる差分が最大 2,048 件のみである場合、クライアントが実際に古くなっている場合、サーバーはクライアントを 2,048 データベースにリセットできます。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-07-25 UTC。
[null,null,["最終更新日 2025-07-25 UTC。"],[[["\u003cp\u003eThe Safe Browsing API allows clients to set constraints on update and database sizes to manage resource usage.\u003c/p\u003e\n"],["\u003cp\u003eClients can limit bandwidth with \u003ccode\u003emaxUpdateEntries\u003c/code\u003e and storage with \u003ccode\u003emaxDatabaseEntries\u003c/code\u003e to optimize performance.\u003c/p\u003e\n"],["\u003cp\u003eGoogle provides recommended constraint values for different client types to balance protection and resource consumption.\u003c/p\u003e\n"],["\u003cp\u003eThe Safe Browsing server ensures clients remain up-to-date even with constrained updates, potentially resetting the database if necessary.\u003c/p\u003e\n"]]],["Clients updating local databases via the `threatListUpdates.fetch` API can set size constraints using `maxUpdateEntries` (for update response size, limiting bandwidth) and `maxDatabaseEntries` (for database size, limiting storage). Google recommends `maxUpdateEntries=16777216` (67MB) for most clients and `2097152` (8MB) for mobile. These constraints should be consistently applied across all lists, with telemetry to detect overusage. The server ensures clients are always fully updated, potentially resetting to smaller databases if necessary.\n"],null,["# Update Constraints\n\nThis document applies to the following method:\n[Update API (v4)](/safe-browsing/v4/update-api):\n[threatListUpdates.fetch](/safe-browsing/v4/update-api#example-threatListUpdatesfetch).\n\nSetting constraints\n-------------------\n\nWhen updating local databases\n(see [Database Updates](/safe-browsing/v4/local-databases#database-updates))\nclients can use the `maxUpdateEntries` and `maxDatabaseEntries` fields in the\n[threatListUpdates.fetch request](/safe-browsing/v4/update-api#http-post-request)\nto specify size constraints. Clients should set constraints to maintain\npredictable consumption of client RAM, disk, and bandwidth, and to safeguard\nagainst list growth.\n\n- Clients can specify a maximum update response size (`maxUpdateEntries`) in number of entries (1 entry = 1 addition or 1 removal).\n- Clients can specify a maximum database size (`maxDatabaseEntries`) in number of entries (the vast majority of entries in the database are 4-byte hash prefixes so it's fair to assume that 1 entry ≈ 4 bytes).\n\nBandwidth vs. storage\n---------------------\n\nWhile clients may specify arbitrary sizes for the update response and database sizes, the Safe\nBrowsing server only pre-generates a finite number of possible update response and database sizes.\n\n- Clients should use the update response size (`maxUpdateEntries`) to limit bandwidth usage.\n- Clients should use the database size (`maxDatabaseEntries`) to limit the amount of RAM or disk storage needed on the device.\n\nBoth of these limits have an effect on the size of the database that is being updated and therefore have an impact on the amount of protection provided to the user (that is, the larger the local database size the better the protection).\n\n\u003cbr /\u003e\n\nGuidance for setting constraints\n--------------------------------\n\nSafe Browsing lists can gradually or suddenly change in size. Clients should\nset the `maxUpdateEntries` for list update requests, which limits the\nmaximum list update response size and improves reliability when large updates\ncannot be processed.\n\nIn the absence of stricter requirements or requirements that are less strict,\nGoogle recommends using `maxUpdateEntries=16777216`. With the typical\nlist entry size of 4 bytes per hash prefix, this equates to approximately 67\nmegabytes per list. Google recommends using the smaller limit\n`maxUpdateEntries=2097152` for mobile clients, because they are\nusually less powerful. At the typical list entry size of 4 bytes per hash\nprefix, this equates to approximately 8 megabytes per list.\n\nSafe Browsing lists differ in size and growth rate. However, clients should\nset the same constraints for all lists, based on the maximum allowed memory or\nbandwidth usage for each list.\n\nTo improve reliability, Google recommends that clients implement telemetry\nfor detecting memory or bandwidth overusage, as well as mechanisms to quickly\ndeliver new constraints to clients.\n\nClient state\n------------\n\nThe Safe Browsing server never sends an update that leaves the client in an outdated state;\nclients will be fully up-to-date after every update request. For example, if a client currently has\na database of 4096 entries but only wants to download at most 2048 deltas, the server may reset the\nclient to a 2048 database if the client is really out-of-date."]]