Sign in to your Google Cloud account. If you're new to
Google Cloud,
create an account to evaluate how our products perform in
real-world scenarios. New customers also get $300 in free credits to
run, test, and deploy workloads.
Google Cloud CLI をインストールします。
インストール後、次のコマンドを実行して Google Cloud CLI を初期化します。
Web Risk には、統合先にできる 2 つの API が用意されています（Lookup API と Update API）。どちらの API も、同じ情報（URL が悪意があると判断されたかどうか）を提供します。使用するのが簡単な方は Lookup API です。Lookup API を使用すると、チェック対象の URL ごとに Web Risk をクエリすることになります。
Update API はより複雑ですが、望ましいプロパティがあります。Update API を使用して、ローカル データベースが維持します。このデータベースでは、URL が悪意のあるものかどうかを確認できます。このデータベースは Bloom フィルタとして機能します。つまり、偽陽性（URL は悪意があると判定されたが、実際には悪意がない）の可能性はあるものの、偽陰性（URL は悪意がないと判定されたが、実際には悪意がある）の可能性はありません。そのため、Web Risk サーバーへの問い合わせはまれで、一致を確認し、偽陽性の曖昧さを解消するためにのみ問い合わせが行われます。ほとんどの場合、Update API を使用して URL をチェックする際に、Web Risk サーバーに問い合わせる必要はありません。ローカル データベースを更新する場合や、URL が有害なかどうかを確認する場合にのみ、Web Risk サーバーに問い合わせる必要があります。
まとめると、すばやく簡単に設定を済ませたいユーザーには Lookup API が向いています。低レイテンシの URL チェックが必要なユーザーには Update API が向いています。
適切なクライアント機能を選択する
Update API を使用する場合は、仕様全体を実装する必要がない可能性があります。広く分散しているクライアント向けに設計された一部の機能（ウェブブラウザなど）は、多くの企業のケースに合わせて過度に最適化されています。
統合を容易にするために無視できる機能がいくつかあります。
こちらに Web Risk 統合ソリューションを複雑さの順に示します
Lookup API を使用する
基本的な Update API クライアント
差分を使用する Update API クライアント
RICE 圧縮差分を使用する Update API クライアント
Lookup API の使用
Lookup API を使用するのが最も簡単です。不審な URL がある場合は、その URL を指定して Lookup API を呼び出し、判定結果を確認します。URL の正規化とフォーマットは、Web Risk サーバーによって処理されます。このソリューションは、平均レイテンシが要件を超えない限り、ほとんどのクライアントに有効です。
基本的な Update API クライアント
Update API では、クエリの前にローカル データベースと正規化された URL を管理する必要があるため、複雑度が高まります。
Web Risk との一般的なクライアント統合では、クライアントはデータベースの差分を適用して最新の状態を維持します。差分アプリケーション ロジックを正しく実装するには時間がかかることがあります。そのため、最も簡単なケースでは、クライアントは差分を無視し、サイクルごとに Web Risk から完全に新しいデータベースをリクエストすることをおすすめします。このデータベースは、効率的なクエリのために引き続きメモリ内に保存されます。データベースの完全なリセットをリクエストするには、threatLists.computeDiffリクエストのversionTokenフィールドを空のままにします。このソリューションは、帯域幅またはデータベースの同期レイテンシが要件を超えない限り、クライアントに有効です。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-09-04 UTC。"],[],[],null,["# Detect malicious URLs with Web Risk\n===================================\n\nBefore you begin\n----------------\n\n- Create a Google Cloud project. [Learn how to create a Google Cloud project](/resource-manager/docs/creating-managing-projects#creating_a_project).\n\n-\n\n\n [Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n \u003cbr /\u003e\n\nSet up authentication and enable the Web Risk API\n-------------------------------------------------\n\nSign in to your Google Cloud account. If you're new to Google Cloud, [create an account](https://console.cloud.google.com/freetrial) to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.\n\n\n[Install](/sdk/docs/install) the Google Cloud CLI.\n\nAfter installation,\n[initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n```bash\ngcloud init\n```\n\n\nIf you're using an external identity provider (IdP), you must first\n[sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n[Create or select a Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).\n| **Note**: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.\n\n- Create a Google Cloud project:\n\n ```\n gcloud projects create PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with a name for the Google Cloud project you are creating.\n- Select the Google Cloud project that you created:\n\n ```\n gcloud config set project PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud project name.\n\n\n[Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n\nEnable the Web Risk API:\n\n\n```bash\ngcloud services enable webrisk.googleapis.com\n``` \n\n[Install](/sdk/docs/install) the Google Cloud CLI.\n\nAfter installation,\n[initialize](/sdk/docs/initializing) the Google Cloud CLI by running the following command:\n\n```bash\ngcloud init\n```\n\n\nIf you're using an external identity provider (IdP), you must first\n[sign in to the gcloud CLI with your federated identity](/iam/docs/workforce-log-in-gcloud).\n\n[Create or select a Google Cloud project](https://cloud.google.com/resource-manager/docs/creating-managing-projects).\n| **Note**: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.\n\n- Create a Google Cloud project:\n\n ```\n gcloud projects create PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with a name for the Google Cloud project you are creating.\n- Select the Google Cloud project that you created:\n\n ```\n gcloud config set project PROJECT_ID\n ```\n\n Replace \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e with your Google Cloud project name.\n\n\n[Verify that billing is enabled for your Google Cloud project](/billing/docs/how-to/verify-billing-enabled#confirm_billing_is_enabled_on_a_project).\n\n\nEnable the Web Risk API:\n\n\n```bash\ngcloud services enable webrisk.googleapis.com\n```\n\n\u003cbr /\u003e\n\nUsing the APIs\n--------------\n\nWhen you use the Web Risk APIs, make sure you're familiar with Web Risk's [Service Level Agreement](/web-risk/sla) and [usage limits](/web-risk/quotas).\n\nTo start using Web Risk, see these topics:\n\n- [Using the Lookup API](/web-risk/docs/lookup-api)\n- [Using the Update API](/web-risk/docs/update-api)\n\nWhich API is right for me? Lookup or Update?\n--------------------------------------------\n\nWeb Risk provides two different APIs that you may integrate with. These\nAPIs are the [Lookup API](/web-risk/docs/lookup-api) and the [Update API](/web-risk/docs/update-api). Both of\nthese APIs provide the same information. That is, whether a URL has been\nidentified as malicious. The easiest to use is the Lookup API. Using the Lookup\nAPI, you will query Web Risk for every URL you wish to check.\n\nThe Update API is more complex but has some desirable properties. Using the\nUpdate API, you will maintain a local database. This database may be checked\nto see if a URL is malicious. This database acts as a bloom filter. That is,\nthere may be false positives (a URL is identified as malicious but isn't) but\nthere should not be any false negatives (a URL is identified as not malicious,\nbut is). Because of this, the Web Risk servers are rarely contacted, and are\nonly contacted to confirm matches and disambiguate false positives. In most\ncases, when checking a URL using the Update API you won't need to contact the\nWeb Risk servers at all. You are expected to contact Web Risk servers only when\nupdating the local database and when confirming a URL is harmful.\n\nIn summary, use the Lookup API if you want to get set up quickly and easily.\nUse the Update API if you need lower latency URL checking.\n\nChoosing the Right Client Features\n----------------------------------\n\nIf you chose to use the Update API, you may not need to implement the entire\nspecification. There are some features that were designed for widely distributed\nclients (like web browsers) that are over-optimizations in many enterprise\ncases.\n\nThere are some features that may be ignored for easier integration.\n\nHere are the Web Risk integration solutions in order of complexity\n\n1. Use the LookUp API\n2. Basic Update API client\n3. Update API client using diffs\n4. Update API client using RICE compressed diffs\n\n### Using the Lookup API\n\nUsing the Lookup API has the lowest complexity. Whenever there is a potentially\nsuspicious URL, simply call the Lookup API with the URL to see a verdict.\nCanonicalization and formatting the URL is handled by the Web Risk\nserver. This solution should be valid for most clients unless average latency\nexceeds requirements.\n\n### Basic Update API client\n\nThe Update API requires the additional complexity of managing a local database\nand canonicalized URLs before queries.\n\nIn a typical client integration with Web Risk, a client will apply database\ndiffs to remain up-to-date. The diff application logic may take some time to\nimplement correctly, so in the simplest cases we recommend clients ignore diffs\nand request a full new database from Web Risk every cycle. This database will\nstill be stored in memory for efficient querying. Requesting a full database\nreset is done by leaving the `versionToken` field empty in the\n[`threatLists.computeDiff` request](/web-risk/docs/update-api#http_get_request).\nThis solution should be valid for clients unless bandwidth or database\nsynchronization latency exceeds requirements.\n\n### Use the Update API and request diff updates\n\nThis solution has the added complexity of applying the diff logic to the local\ndatabase. For more information, see\n[Database Diffs](/web-risk/docs/local-databases#full-updates). Using diffs will reduce\nbandwidth at the expense of complexity, compared to requesting a new database\neach cycle. A full database update may be on the order of a few megabytes.\nThis solution should be sufficient for most enterprise clients.\n\n### Use the Update API and request RICE encoded diff updates\n\nThis solution is the most efficient client integration possible. RICE encoding\ncompresses DIFF sizes and further reduces update bandwidth. This solution is\nintended to be used by the most bandwidth constrained customers. An example\nwhere this may be relevant is if Web Risk queries are built into a phone App.\nThe users of such an app would surely appreciate a lower bandwidth solution if\nthey needed to update the database over phone data.\nFor more information, see [Compression](/web-risk/docs/compression)."]]
