不正防止Google 広告の IP 除外の上限：500 件の制限、CIDR、そして除外できないもの
Google 広告の IP 除外の上限は、キャンペーンごとに 500 件、アカウントごとに 500 件です。CIDR で 1 枠をどう広げるか、どの IP に枠を割くべきかを、実際に行った 6 件のルックアップから解説します。
手元にはクリックログがあります。何度も現れるアドレスがいくつかあり、除外欄には 500 件しか入らず、埋まったらどうなるのかと考えている。上限について検索すると、答えてくれるページのほとんどはクリック詐欺対策ベンダーのもので、その答えのほとんどは同じ結論で終わります。「当社のツールがリストを自動でローテーションします」。
私たちは、それは問いの立て方が間違っていると考えています。Google 自身の API ドキュメントは上限を「IP ブロック」の数で数えているので、1 件で範囲全体をカバーでき、本当に有用な問いは「どの範囲に枠を割く価値があるか」になります。私たちの立場はシンプルです。除外リストは、自社のオフィスや繰り返し現れるホスティングのブロックのような、安定した迷惑元のためのものであり、不正対策のためのものではありません。Google は自社側ですでに無効なクリックをフィルタリングしていると述べており、そのページは本記事の終盤で引用します。
以下では、2 つの上限を Google 自身の言葉で示し、範囲を管理画面で入力する方法と API で CIDR として入力する方法を紹介し、実在する 6 つのアドレスを当社の API に通してどれに枠を割く価値があるかを判断し、どんな除外でも防げないものを列挙します。クリックを禁止するのではなくスコアリングするべき理由について、より広い議論は当社のクリック詐欺ガイドから読み始めてください。
Google 広告の IP 除外の上限：いくつのアドレスを除外できるか
除外できる IP エントリーは、キャンペーンごとに 500 件、アカウントごとに 500 件です。2 つの数字は Google の別々のページに書かれており、そのせいで多くの解説記事が 2 つ目の数字を間違えています。
本記事で引用している Google のページは、すべて 2026 年 10 月 14 日 06:12 UTC に開きました。キャンペーンの上限は Google のヘルプページ IP アドレスを除外する に書かれています。
「You can exclude up to 500 IP addresses per campaign.」（キャンペーンごとに最大 500 件の IP アドレスを除外できます。）
ヘルプページにはアカウント単位の数字は書かれていません。アカウントの上限は、アカウント単位の除外を保持するリソースである CustomerNegativeCriterion の Google Ads API リファレンスにあります。その ip_block フィールドには「Immutable. IpBlock. You can exclude up to 500 IP addresses per account.」（変更不可。IpBlock。アカウントごとに最大 500 件の IP アドレスを除外できます。）と書かれています。上位に表示されるページの中には、これを見落としているものがあります。同じ時刻に開いた Lunio の 500 件の上限に関する記事 は、「The 500 IP exclusion limit applies per campaign, not per account.」（500 件の IP 除外の上限はキャンペーンごとに適用され、アカウントごとではありません。）と述べています。Google のリファレンスは、アカウントのリストにも独自の 500 件の上限があるとしています。
数字よりも単位のほうが重要です。Google の API システム上限 の表では、この行は「Excluded IP blocks per campaign」（キャンペーンごとの除外 IP ブロック数）、値は「500」、エラーは ResourceCountLimitExceededError.CAMPAIGN_LIMIT と記載されています。条件はアドレスごと、または CIDR ブロックごとに 1 つ作成されるので、Google の API ドキュメント上は、一度入力した /24 は 1 件です。これは実際のアカウントではテストしていません。私たちが「500 アドレス」ではなく「500 枠」と呼ぶのはこのためです。
両方の単位にエントリーがある場合、リストは統合されると Google のヘルプページは述べています。
「If you have IP exclusions set up at both the account level and the campaign level under the same CID: Google Ads will merge the exclusion lists. This means all the IP addresses excluded at either level will be blocked from viewing your ads for that campaign.」（同じ CID でアカウント単位とキャンペーン単位の両方に IP 除外を設定している場合、Google 広告は除外リストを統合します。つまり、どちらかの単位で除外したすべての IP アドレスに対して、そのキャンペーンの広告が表示されなくなります。）
Google 自身の例はこうです。「キャンペーン単位（キャンペーン A）で IP アドレス 1、2、3 を除外し、アカウント単位で IP アドレス 4、5 を除外したとします。設定したキャンペーン（キャンペーン A）では、Google 広告は実質的に IP アドレス 1、2、3、4、5 をブロックします。」2 つの上限がどう相互作用するかについて Google はそれ以上何も述べていないので、私たちも述べません。
| 単位 | 上限 | Google の記載箇所 | 適用範囲 |
|---|---|---|---|
| キャンペーン | 500 | ヘルプページ 2456098、API CampaignCriterion.ip_block | 1 つのキャンペーン。すべてのキャンペーン タイプではない |
| アカウント | 500 | API CustomerNegativeCriterion.ip_block のみ | P-MAX を含むアカウント内の全キャンペーン |
| 両方を設定 | キャンペーンごとにリストを統合 | ヘルプページ 2456098 | 各キャンペーンは自身のエントリーとアカウントのエントリーをブロック |
アカウント単位かキャンペーン単位か：IP 除外をどこに追加するか
すべてに適用したい除外はアカウント単位に、1 つのキャンペーンだけに固有の問題がある場合にのみキャンペーン単位に追加します。Google 自身が挙げる良い除外の例は自社のスタッフです。「自社のネットワークの IP アドレスを除外することにしました」。このアドレスはアカウント単位に置くべきものです。
アカウント単位の手順は、同じヘルプページによると次のとおりです。
- Google 広告アカウントで、管理者 アイコンをクリックします。
- アカウント設定 をクリックします。
- 「IP 除外」セクションに移動します。
- 広告を表示させたくない IP アドレスを入力します。
- 保存 をクリックします。
1 つのキャンペーンの場合は次のとおりです。
- Google 広告アカウントで、キャンペーン アイコンをクリックします。
- セクション メニューの キャンペーン プルダウンをクリックします。
- キャンペーン、設定 の順にクリックします。
- IP アドレスを除外するキャンペーンを選択します。
- 「設定」ページで その他の設定 をクリックします。
- 「IP 除外」セクションを展開し、アドレスを入力して 保存 をクリックします。
エントリーの削除は、どちらの単位でも同じ手順です。Google の説明では、上記の手順に従って「適用したくない IP アドレスの除外を削除し」、保存 をクリックします。落とし穴が 1 つあります。「アカウント単位の除外は、個々のキャンペーン内から編集または削除することはできません。」キャンペーン内でエントリーが消せないように見える場合は、アカウント設定を確認してください。
アカウント単位に適したエントリーは、自社のオフィス、代理店のオフィス、そして繰り返しクリックしてくることが確認されたホスティングのブロックです。競合他社のオフィスの固定範囲も、キャンペーン単位の枠として妥当です。本当の目的が地域であれば、Google は別の方法を案内しています。「特定の地域で広告が表示されないようにしたい場合は、IP アドレスを除外するのではなく、地域を除外してみてください。」
キャンペーン単位の IP 除外を使えないキャンペーン タイプは
動画、ホテル、アプリ、P-MAX、スマート ディスプレイの各キャンペーンでは、キャンペーン単位の IP 除外を設定できません。Google のヘルプページは、これを 1 つの注記にまとめています。
「Note: IP exclusions aren't available for video campaigns, hotel campaigns, App campaigns, Performance Max campaigns, and Smart Display campaigns.」（注：IP 除外は、動画キャンペーン、ホテル キャンペーン、アプリ キャンペーン、P-MAX キャンペーン、スマート ディスプレイ キャンペーンではご利用いただけません。）
アカウント単位はより広く適用されます。Google によると、アカウント単位の除外を使えば「P-MAX、デマンド ジェネレーション、検索、ショッピング、ディスプレイ、Discover、YouTube を含む、アカウント内のすべてのキャンペーンで特定の IP アドレスに広告が表示されないように」できます。つまり P-MAX で IP 除外を使えるのはアカウント単位だけで、そのリストは他のすべてのキャンペーンと共有する同じ 500 件です。
| キャンペーン タイプ | キャンペーン単位の除外 | アカウント単位の除外 |
|---|---|---|
| 検索、ショッピング、ディスプレイ | 利用可能 | Google が明記 |
| P-MAX | 利用不可 | Google が明記 |
| 動画 | 利用不可 | Google は YouTube を明記 |
| ホテル、アプリ、スマート ディスプレイ | 利用不可 | ページに記載なし |
| デマンド ジェネレーション | Google の非対応リストに含まれない | Google が明記 |
このリストについてはベンダーのページによって記述が異なります。Google 自身のページでも食い違いがあることが一因です。以前の 検索広告 360 のヘルプページ は、動画、アプリ、スマート ディスプレイ、ファインド キャンペーンを挙げています。私たちは現行の Google 広告のページにある 5 つだけを採用しています。
IP 範囲を除外する方法：アスタリスク、CIDR、IPv6
管理画面で文書化されている範囲の形式は、最後のオクテットのアスタリスクです。API 経由なら、任意の IPv4 または IPv6 の CIDR ブロックが 1 件になります。
Google のヘルプページには「特定の IP アドレスを入力するか、アドレスのブロックを除外したい場合はアスタリスク（*）で最後の 3 桁を置き換えることができます」とあります。最後の 3 桁とは最後のオクテットのことで、198.51.100.* は /24 と同じ 256 個のアドレスをカバーします。Google が文書化しているのはこの位置のアスタリスク 1 つだけです。アスタリスクを 2 つ使う形式や先頭にアスタリスクを置く形式を載せている上位ページもありますが、Google はそのような構文を文書化していないので、頼らないでください。
API はより柔軟です。Google の IpBlockInfo リファレンス には「We support excluding individual IP addresses or CIDR blocks. Create one IpBlockInfo criterion for each individual IP address or CIDR block you want to exclude.」（個々の IP アドレスまたは CIDR ブロックの除外に対応しています。除外したい個々の IP アドレスまたは CIDR ブロックごとに IpBlockInfo 条件を 1 つ作成してください。）とあります。例として、IPv4 では 192.168.0.0/24 と、単一アドレスを表す 192.168.0.1/32、IPv6 では 2001:db8::/48 と 2001:db8:a0b:12f0::1/128 が挙げられています。
管理画面で文書化されているのは単一のアドレスとアスタリスクです。CIDR と IPv6 のブロックは API 向けに文書化されています。管理画面に CIDR や IPv6 のエントリーを入れたときの挙動はテストしていないので、使えるとは言いません。
CIDR が威力を発揮するのは枠の計算です。英国の代理店が WebSuccess Insights で例として使っている、194.83.41.0 から 194.83.47.255 までの範囲を考えます。これを Python の ipaddress.summarize_address_range に通しました。
| 入力内容 | 場所 | カバーするアドレス数 | 使用するエントリー数 |
|---|---|---|---|
194.83.41.* から 194.83.47.* まで、/24 ごとに 1 行 | 管理画面 | 1,792 | 7 |
194.83.41.0/24、194.83.42.0/23、194.83.44.0/22 | API | 1,792 | 3 |
2001:db8::/48 | API | 65,536 個の /64 サブネット | 1 |
Google の IPv6 の例は /48 で、65,536 個の /64 サブネットを含みます。1 台のデバイスのネットワークは通常 1 つの /64 ですが、ISP は家庭に /56 や /48 を割り当てることが多いので、/48 のエントリー 1 件で顧客の拠点全体をカバーできることがあります。/48 と /64 がそれぞれ何をカバーするか は、IPv6 の記事で解説しています。
Google はさらに 1 行付け加えています。「IP アドレスには異なるバージョンがあるため、除外したい IP アドレスのすべてのバージョンを使用してください。」つまり、IPv4 と IPv6 の両方のアドレスを持つオフィスやサーバーには、両方のエントリーが必要だということです。
Google Ads API で IP 除外を一括追加する
API では、キャンペーンの除外は ip_block を持つ除外の CampaignCriterion で、アカウントの除外は ip_block を持つ CustomerNegativeCriterion です。Google の 条件の表 では、IP ブロックはキャンペーン単位と顧客単位で除外専用として記載されています。
何かを送信する前に、リストを圧縮しましょう。次のスクリプトは、候補のアドレスとブロックを、それらすべてをカバーする最少の CIDR エントリーに変換し、クリック数の多い順に並べ、500 件で打ち切ります。10 月 14 日に Python 3.9.6 で、標準ライブラリだけを使って実際に実行したコードそのものです。
"""Turn candidate IPs and CIDR blocks into a Google Ads exclusion list of at most 500 entries.
Input: one entry per line, an IPv4/IPv6 address or a CIDR block (for example the
registered block you looked up in RDAP), optionally followed by a click count.
Output: the fewest CIDR entries that cover every input, busiest first, capped at 500.
"""
import ipaddress
import sys
GOOGLE_ADS_LIMIT = 500 # per campaign, and per account, in Google's API reference
def build_exclusions(lines, limit=GOOGLE_ADS_LIMIT):
clicks = {}
for line in lines:
line = line.split("#", 1)[0].strip()
if not line:
continue
parts = line.split()
net = ipaddress.ip_network(parts[0], strict=False) # 1.2.3.4 -> 1.2.3.4/32
clicks[net] = clicks.get(net, 0) + (int(parts[1]) if len(parts) > 1 else 1)
merged = []
for version in (4, 6): # collapse_addresses refuses to mix IPv4 and IPv6
nets = [n for n in clicks if n.version == version]
merged += ipaddress.collapse_addresses(nets)
# Credit each merged entry with the clicks of everything it now covers.
totals = {m: sum(c for n, c in clicks.items() if n.version == m.version and n.subnet_of(m))
for m in merged}
ranked = sorted(merged, key=lambda m: totals[m], reverse=True)
return ranked[:limit], ranked[limit:], totals
if __name__ == "__main__":
keep, dropped, totals = build_exclusions(sys.stdin)
for net in keep:
print(f"{net}\tclicks={totals[net]}")
print(f"# {len(keep)} entries kept, {len(dropped)} over the limit", file=sys.stderr)
公開できる実際のクリックログはないので、ドキュメント用のアドレス範囲だけで作った合成サンプルを入力しました。これらは実際のクリックではなく、ルックアップも一度もしていません。
# SYNTHETIC sample: documentation ranges (RFC 5737, RFC 3849), not real clicks
198.51.100.7 3
198.51.100.0/25 12 # a registered block you looked up
198.51.100.128/25 9 # its neighbour: merges with the line above into one /24
203.0.113.10 2
203.0.113.11 2 # adjacent to .10: the two merge into one /31
192.0.2.200 1
2001:db8::42 4
2001:db8::/48 6 # covers the address above
python3 -I build_exclusions.py < synthetic_clicks.txt を実行すると、次の出力が得られました。
198.51.100.0/24 clicks=24
2001:db8::/48 clicks=10
203.0.113.10/31 clicks=4
192.0.2.200/32 clicks=1
# 4 entries kept, 0 over the limit
8 行が 4 件のエントリーになりました。198.18.0.0/15 から隣接しない合成の /32 を 600 個入力したところ、クリック数の多い 500 件を残し、100 件が上限超過と報告されました。
このスクリプトが意図的に行わないことが 3 つあります。
- アドレスを広げることは決してしません。
collapse_addressesが統合するのは、接しているか重なっているブロックだけです。1 つのアドレスをその /24 に広げるのは RDAP でルックアップした後に人が下す判断であり、コードが推測すべきことではありません。 - 管理画面の構文は考慮しません。 /31 や /48 は API では問題ありません。管理画面では /31 を 2 つのアドレスとして入力することになり、IPv6 の範囲形式は管理画面では文書化されていません。
- 共有アドレスを除外しません。 次のセクション以降で説明するルールでリレーやキャリア NAT のアドレスを取り除いてから実行してください。
また、このスクリプトは当社の API を一切呼び出しません。ルックアップのステップを加える場合は、API リファレンス にあるとおり、アドレスごとに 1 回、パスに IP を入れ、x-api-key ヘッダーにキーを入れた GET を送ります。一括呼び出しはありません。Python の urllib から呼ぶ場合は、User-Agent を明示的に設定してください。当社の API は現在、urllib のデフォルトの User-Agent に 403 を返します。
エントリーの送信は次のようになります。10 月 14 日時点で v25 と表示されていた Google の IpBlockInfo と CampaignCriterion のリファレンスをもとに、Python クライアント ライブラリの命名に従って書いたものです。実際のアカウントに対しては実行していません。
# Written from Google's IpBlockInfo and CampaignCriterion reference (v25); not run against a live account.
operation = client.get_type("CampaignCriterionOperation")
criterion = operation.create
criterion.campaign = client.get_service("CampaignService").campaign_path(customer_id, campaign_id)
criterion.negative = True # IP blocks can only be excluded
criterion.ip_block.ip_address = "198.51.100.0/24" # one CIDR block = one criterion
client.get_service("CampaignCriterionService").mutate_campaign_criteria(
customer_id=customer_id, operations=[operation]
)
# Account level: CustomerNegativeCriterionOperation, criterion.ip_block.ip_address,
# CustomerNegativeCriterionService.mutate_customer_negative_criteria.
# At 501 campaign entries the API returns ResourceCountLimitExceededError.CAMPAIGN_LIMIT.
Google がエラーを文書化しているのはキャンペーンの上限についてだけです。アカウントの上限については文書化されたエラーコードが見つからなかったので、名前は挙げません。Google 広告エディタの バージョン 2.11 のリリースノート には「Account-level placement and IP exclusions」（アカウント単位のプレースメントと IP 除外）という見出しがありますが、エディタはテストしていないので、エディタの手順は示しません。
500 件ではホスティング ネットワークを収められない理由
Google は ASN でネットワークを除外する方法を文書化しておらず、大手プロバイダーは数千のプレフィックスをアナウンスしているので、500 件では大手クラウド プロバイダーを収められません。10 月 14 日 06:14 UTC に数えた結果は次のとおりです。
| ネットワーク | 必要なエントリー数 | 出典 |
|---|---|---|
| AS16509（Amazon） | アナウンスされているプレフィックス 27,319 個（IPv4 21,267、IPv6 6,052） | RIPEstat announced-prefixes、期間 2026-09-30 から 2026-10-14 |
| AWS の公開範囲 | 一意のプレフィックス 11,336 個（IPv4 7,863、IPv6 3,473） | ip-ranges.amazonaws.com、createDate 2026-10-14-03-37-06 |
| AS63949（Akamai Connected Cloud、旧 Linode） | 452（IPv4 354、IPv6 98） | RIPEstat、同期間 |
| AS39351（31173 Services、Mullvad のネットワーク） | 74（IPv4 53、IPv6 21） | RIPEstat、同期間 |
| AS60729（TORSERVERS-NET） | 6（IPv4 3、IPv6 3） | RIPEstat、同期間 |
RIPEstat の数には、重複するより細かいプレフィックスや、2 週間の期間中に観測されたものすべてが含まれるので、一意のアドレス空間ではなく、エントリー数の上限値として扱ってください。数は日々変動します。それでも、Amazon だけで、2 つのリストを合わせた容量の何倍ものエントリーが必要です。
つまりホスティングについての問いは「クラウドを除外できるか」ではありません。それはできません。問うべきは「自社のログにどのホスティングのブロックが繰り返し現れるか」です。アドレスがデータセンター IP とされる条件 は別の記事で解説しています。当社の API は、厳選した 853 のホスティング ASN と 10 社のクラウド プロバイダーの公式範囲からホスティングを判定しており、無料の データセンター IP チェック で 1 つのアドレスを試せます。
このフラグに基づいてルールを書く前に、注意点が 1 つあります。ホスティングのトラフィックは MRC 基準における一般無効トラフィック（GIVT）の最初のカテゴリーですが、同じ基準は正当な VPN ルーティングや仮想マシンでのブラウジングをそこから除外しています。これについては GIVT と SIVT：Google の無効なトラフィックのカテゴリー で詳しく説明しています。ホスティングだけでは意図的に低いスコアになります。後述の 45.33.32.156 は detection.is_hosting: true を返し、スコアは 10、allow です。有料クリックについて、ホスティングのトラフィックに広告を表示すべきかどうかは、スコアではなくあなたが書くルールで決めることです。
500 枠のうちの 1 つに値するアドレスは
枠を割くべきなのは、誰とも共有されておらず、自社のクリックログで実際に見かけた、安定した範囲です。それがどのようなものかを示すため、10 月 14 日 06:12 UTC に、匿名の GET https://api.geoiphub.com/v1/lookup/{ip} で 6 つの公開アドレスをルックアップしました。6 つすべてが HTTP 200 を返しました。どれも誰かの広告をクリックしたわけではありません。クリックログに含まれる種類のアドレスの代表として使っています。
当社のレスポンスにはプレフィックスのフィールドがないため、登録ブロックはそれぞれ 06:14 UTC に rdap.org 経由の RDAP で取得しました。rdap.org は ARIN と RIPE にリダイレクトしました。
| IP とその正体 | asn / org | user_type | is_hosting | is_vpn | is_relay | is_cgnat | スコア、アクション | detection_methods | RDAP ブロック | 枠を割くか |
|---|---|---|---|---|---|---|---|---|---|---|
| 45.33.32.156、scanme.nmap.org | 63949 AKAMAI-LINODE-AP | hosting | true | false | false | false | 10、allow | datacenter_ip | 45.33.0.0/17（LINODE） | このブロックが自社のクリックログに繰り返し現れる場合のみ、自社の広告トラフィック ルールとして |
| 185.220.101.1、Tor 出口ノード、ハンブルク | 60729 TORSERVERS-NET | hosting | true | false | false | false | 100、block | tor_exit, datacenter_blocklisted, rdns_tor, known_spammer | 185.220.101.0/27（ARTIKEL10） | はい：独立した 4 つの理由を持つ、安定した運営者のブロック |
| 45.83.220.7、Mullvad のネットワーク、マルメ | 39351 31173 Services AB | hosting | true | true、"Mullvad (31173 Services)"、85 | false | false | 46、review | known_vpn_server, datacenter_ip | 45.83.220.0/24 | デフォルトではいいえ：クリック時にスコアリングする |
| 185.213.155.73、Mullvad de-fra-wg-001 | 39351 31173 Services AB | hosting | true | true、"Mullvad"、95 | false | false | 100、block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | 185.213.155.0/24 | 可能。ただし同じ運営者が上の行では 46 だった |
| 104.28.46.99、iCloud Private Relay | 13335 Cloudflare | consumer_privacy_network | false | false | true | false | 9、allow | relay_ip | 104.16.0.0/12（CLOUDFLARENET） | 絶対に割かない |
| 172.224.226.1、iCloud Private Relay | 36183 AKAMAI-AS | consumer_privacy_network | true | false | true | false | 24、allow | datacenter_ip, no_ptr_datacenter, relay_ip | 172.224.0.0/12（AKAMAI） | 絶対に割かない。is_hosting: true のリレー |
2 つの行には補足が必要です。45.83.220.7 の VPN 名は、Mullvad 自身のサーバー一覧ではなく、当社の VPN ホスティング ネットワークの表から信頼度 85 で得たものです。10 月 13 日に確認したとき、Mullvad の一覧にはこのアドレスは含まれていませんでした。また 104.28.46.99 は Cloudflare の登録済み /12 の中にありますが、Cloudflare が 自社ネットワーク用に公開している 範囲の外にあります。したがって「Cloudflare のブロックを除外する」と、Cloudflare のサーバーではなく Apple のリレーのユーザーを締め出すことになります。
1 つのアドレスを最初から最後まで
185.220.101.1 を、クリックからエントリーになるまで追ってみましょう。自動タグ設定が有効な場合、Google はランディング URL に GCLID を追加します。Google の例では「www.example.com/?gclid=123xyz」です。ランディング ページで、その gclid と並べてクライアント IP をログに記録してください。この組み合わせこそが、アドレスと有料クリックを結び付けます。
次に、そのアドレスをルックアップします。以下は 06:12 UTC のレスポンスを抜粋したもので、入れ子構造はそのまま、値は編集していません。
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"user_type": "hosting"
},
"whois": {
"netname": "ARTIKEL10",
"status": "ASSIGNED PA"
},
"detection": {
"is_vpn": false,
"is_tor": true,
"is_hosting": true,
"is_relay": false,
"is_anonymous": true
},
"threat": {
"is_spammer": true,
"is_cgnat": false
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"]
}
}
detection.is_tor は true、スコアは 100 で、独立した 4 つの手法が反応しています。レスポンスは登録ネットワークの名前は示しますが、その大きさは示さないので、RDAP に問い合わせました。結果は 185.220.101.0 から 185.220.101.31、つまり /27 です。このブロックは API 経由で 185.220.101.0/27 という 1 件のエントリーになります。500 枠のうち 1 枠を使い、1 つの Tor 運営者が運用する 32 個のアドレスをカバーします。これは良い取引です。
私たちが従うルール
- 枠は、自社のクリックログで見かけた、安定していて共有されていない範囲にだけ使います。
is_relay: falseのホスティング ブロックと、Tor 運営者のブロックです。 detection.is_relayまたはthreat.is_cgnatが true のアドレスには、スコアにかかわらず決して枠を使いません。- それ以外はすべて、VPN も含めてランディング時にクリックごとにスコアリングします。1 つの VPN 運営者の 2 つのアドレスが 46 と 100 になったからです。
- ブロックは当社のレスポンスからではなく、RDAP かプロバイダー自身の範囲ファイルから取得します。
これらのアクションの背後にあるスコア帯は、allow が 25 まで、review が 50 まで、step_up が 75 まで、block が 75 超です。不正スコアの帯域の仕組み は別の記事で解説しています。枠を使う前に、無料の IP 不正スコア チェッカーでアドレスを確認する こともできます。
共有アドレスには決して枠を使わない：キャリア NAT と Private Relay
キャリア NAT と iCloud Private Relay のアドレスは、同時に多数の実在の人のトラフィックを運ぶので、1 つ除外するとその全員から広告が見えなくなります。スコアやクリック数が何であっても、それは変わりません。
まず Private Relay から。各出口アドレスを多数の Apple ユーザーが共有しており、当社のスコアリングはリレーの上限を 60 としているので、Private Relay の IP が block に達することはありません。落とし穴は上の表にあります。172.224.226.1 は Apple のリレー一覧に載っていながら、Akamai のデータセンターで稼働しているため detection.is_hosting: true を返します。「ホスティングのブロックはすべて除外する」というルールは Apple ユーザーを除外してしまいます。リレーや VPN のユーザーを通す方法 で説明しているとおり、何よりも先に is_relay を確認してください。
キャリア NAT は、同じ問題のモバイル版です。当社は一般消費者のアドレスをルックアップすることも公開することも決してしないため、安全に示せるキャリアのアドレスがなく、この部分は文章のみです。threat.is_cgnat は多数のキャリア契約者が共有するアドレスを示し、当社のスコアリングにはキャリア NAT の上限 50 があるので、ほかに不利な材料がない共有キャリア アドレスは step_up を下回ったままです。RFC 6598 の範囲 100.64.0.0/10 はキャリアの内部側であり、クリック IP として現れることはありません。代わりにキャリアの公開アドレスが見えます。
これを誤ったときのコストは、何年も前に書き記されています。RFC 6269 は、共有アドレスでは「ログインに何度も失敗した 1 人のユーザーが、それまで一度も試行していない他のユーザーを締め出し、そのユーザーは最初の試行で失敗することになる」と警告しています。ログイン試行を広告クリックに置き換えれば、それが除外の問題です。共有アドレスを禁止すると実在の顧客に影響が出る理由 は、ハブ記事でさらに詳しく扱っています。
IP 除外でブロックできないもの
IP 除外は、あるアドレスからのすべてのクリックを止めることはできず、ネットワークを名前で指定することもできず、すでに支払ったクリックには影響しません。最初の点は Google 自身が 除外した IP アドレスからクリックが発生するのはなぜですか？ で述べています。
「When you use the Internet Protocol (IP) exclusion tool, clicks from excluded IP addresses may still appear in your web logs.」（インターネット プロトコル（IP）除外ツールを使用しても、除外した IP アドレスからのクリックがウェブログに表示されることがあります。）
Google は 3 つの理由を挙げています。
- ローテーション。 「一部のインターネット サービス プロバイダは、ユーザーの IP アドレスを継続的にローテーションしています。」広告はあるアドレスに表示され、クリックは別のアドレスから届きます。
- データの欠落。 「一部の Google ネットワーク サイトは IP 情報を提供していないため、除外した IP アドレスのユーザーにもこれらのサイトで広告が表示されることがあります。特定の IP アドレスからのクリックが一切ないことは保証できません。」
- 自然検索のクリック。 「Google の自然検索結果のクリックと広告のクリックでは、参照元 URL が同じになります。IP 除外は広告にのみ適用されるため、表示されているクリックが実際には検索結果からのものである可能性があります。」
そして、私たちの立場全体を形作る一文があります。
「Google automatically and proactively filters invalid clicks from your account. You don't have to do anything in order to receive this protection. However, you can use the IP address exclusion tool to gain additional control over the placement of your ads.」（Google は、無効なクリックをアカウントから自動的かつ予防的にフィルタリングしています。この保護を受けるために何かをする必要はありません。ただし、IP アドレス除外ツールを使えば、広告の掲載先をさらに細かく管理できます。）
Google の言葉では、これは掲載先の管理であって、不正対策ではありません。Google は除外について ASN、ISP、VPN、プロキシ、データセンターの設定を一切文書化しておらず、除外しても、すでに課金されたクリックの代金は戻りません。
当社の側にも限界があります。当社の API は渡された IP を分類します。Google 広告のクリックや GCLID は見えず、それらは自社のランディング ページのログからしか得られません。プレフィックスを返さないので、ブロックは常に RDAP から取得します。そしてルックアップ結果は変化します。10 月 13 日まで、当社のクリック詐欺ガイドは 45.83.220.7 を単純なホスティングの例として使っていましたが、現在の API はこれを Mullvad のネットワークとして識別しています。対応の根拠にする結果には、すべて日付を記録してください。
アドレスの種類ごとの対処法は次のとおりです。
| アドレスの種類 | 対処法 | 理由 |
|---|---|---|
| 自社のオフィス、競合他社のオフィスの固定範囲、ログに繰り返し現れる安定したホスティングまたは Tor のブロック | アカウント単位で、ブロックごとに CIDR エントリー 1 件として除外する | 安定していて共有されておらず、エントリー数が少ない |
キャリア NAT（threat.is_cgnat: true）、iCloud Private Relay（is_relay: true） | 決して除外しない | 1 つのアドレスに多数の実在ユーザーがいる |
| VPN の出口、一度きりのホスティング アドレス、ローテーションするもの全般 | ランディング時に scoring.recommended_action でスコアリングする | 同じ運営者が 46 と 100 になった |
今週、自社の除外リストについて確認すべきことが 2 つあります。
- 圧縮する。 現在のエントリーをエクスポートし、上のスクリプトに通します。統合されたエントリーの分だけ枠が空くので、新しいものを追加する前に残りの数を数えてください。
- 共有アドレスを削除する。 各エントリーから 1 つのアドレスを 不正スコア チェッカー でルックアップします。
is_relayまたはis_cgnatが true と返ってきたエントリーは削除してください。
よくある質問
Google 広告では IP アドレスをいくつまで除外できますか？
キャンペーンごとに最大 500 件です。Google の API リファレンスでは、アカウント単位の除外にも同じ 500 件の上限が定められています。アカウントのリストが別枠の大きなプールになるわけではありません。
Google 広告の IP 除外で CIDR や IPv6 は使えますか？
Google Ads API 経由であれば使えます。IPv4 または IPv6 の CIDR ブロックはそれぞれ 1 件として数えられます。管理画面について Google のヘルプページが説明しているのは、単一のアドレスと、最後のオクテットを置き換えるアスタリスクだけです。
P-MAX（Performance Max）から IP アドレスを除外できますか？
アカウント単位でのみ可能です。キャンペーン単位の IP 除外は、動画、ホテル、アプリ、P-MAX、スマート ディスプレイの各キャンペーンでは使えません。
除外した IP アドレスからクリックが届き続けるのはなぜですか？
Google は 3 つの理由を挙げています。ユーザーの IP アドレスをローテーションする ISP があること、IP 情報を提供しない Google ネットワークのサイトがあること、そして自然検索のクリックと広告のクリックで参照元が同じになることです。
IP アドレスを除外すると、すでに支払ったクリック分は返金されますか？
いいえ。除外は、それ以降そのアドレスに広告を表示しなくするだけです。無効なクリックに対するクレジットは別の手続きです。
携帯キャリアや iCloud Private Relay の IP は除外すべきですか？
いいえ。そうしたアドレスはそれぞれ多数の実在の人が共有しているため、枠を使うのではなくクリックをスコアリングしてください。
GeoIPHub API を支えるチーム
GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。
