Google Ads で広告を出したら、突然アカウントを止められた。理由は「Malicious software」と「Compromised Site」。ただ、本人は「そんなものはない」と反論し、公開した検証結果を並べて再審査を求めた。この記事は、そのやり取りの経過と、なぜ本人がここまで強く false positive を疑っているのかを記録したものだ。しかも最後には、Hacker News で話題になった結果、アカウントが復活したと追記されている。広告審査のブラックボックスさと、開発者が巻き込まれる理不尽さが、かなり生々しく見える話だった。
記事の主題は、RACE という macOS 向け terminal multiplexer の広告が Google Ads で止められた、という出来事だ。RACE は Rust で書かれたネイティブアプリで、複数の端末を自由な大きさで並べ、開発作業に合わせて配置できる。普通の terminal multiplexer のように、アプリを閉じても shell session を生かしたままにできるのが売りで、作者自身が開発し、日常的に使い、保守もしているという。
作者はこのアプリのサイト race-term.com も自分で作っている。静的サイトで、Bridgetown を使い、JavaScript は DOM を少し動かすだけ。サーバー側の独自アプリはなく、当時の第三者 JavaScript は Cloudflare Analytics だけだった。Google Analytics や広告トラッキングも入れていない。配布ファイルは Cloudflare R2 で置いている。そういう比較的シンプルな構成で初めて Google Ads を試し、500ドルを使ったところでアカウントが「Malicious software」として停止された。
作者はこの判定に納得せず、アプリは署名済みで notarized 済みだし、サイトにも攻撃面は見当たらないと考えた。実際に確認すると、何も出てこなかったので異議申し立てをした。ところが返ってきたのは拒否の連続だった。再提出を求められ、材料がなければアカウント削除を勧められ、EU の救済手続きの案内まで出たが、何が悪いのかは説明されなかった。作者は何度も再審査を求め、追加情報も出したが、拒否され続け、最後には一週間の停止まで食らった。
そこで作者は、考えられる原因を一つずつ潰すために確認作業をまとめている。Google Safe Browsing で race-term.com と downloads.race-term.com を調べると「No unsafe content found」。Google Search Console の Security Issues でも両ドメインに問題なし。配布 DMG も VirusTotal でクリーン。ファイル署名と notarization も有効で、サイトの JavaScript ソースもビルド後バンドルも見直したが、怪しいコードはなかった。Cloudflare のログも見、異なる User Agent での到達性も試したが、どれも問題なしだった。
それでも一点だけ、作者は terminal multiplexer であることが引っかかったのではないかと考える。RACE は裏で shell process を起動し、管理する。これは製品の核心だが、セキュリティ製品のふるまいに似て見える可能性はある。そこで作者は version 1.0.39 を作り、アプリ削除後に後始末をするような回避策まで入れて再申請した。だが結果は芳しくなかったようだ。記事の最後では、ここから先は EU court case しかないかもしれない、と半ば諦めた調子で書かれている。ところが追記として、Hacker News で話題になった“おかげ”か Google Ads アカウントは復活したと明かし、何が停止の引き金だったのかは結局わからないままだと締めている。
この記事で強く印象に残るのは、作者が潔白を証明していることそのものより、何を示しても判断の中身に届いていない点だ。Safe Browsing も Search Console も VirusTotal も、見られるところは全部見ている。それでも広告側の審査は「Malicious software」「Compromised Site」というラベルだけを返す。ここで厄介なのは、開発者にとっては反証ができても、Google 側が何を根拠に止めたのか分からないことだと思う。相手の嫌疑が不明なら、どれだけ検査を積み上げても、的外れかどうかを判断できない。
この手の問題は、セキュリティ審査が「安全かどうか」を見るのではなく、「機械が危険っぽいと感じたかどうか」に寄ると起きやすい。今回なら、terminal multiplexer が裏でプロセスを管理する点が、悪質な常駐ソフトの特徴に見えた可能性はある。だがそれはあくまで推測で、本人もそう書いているにすぎない。重要なのは、正当な用途の振る舞いが、文脈なしでは疑わしく見えることだ。広告審査や自動検出は、その文脈をうまく拾えないことがある。
金額の大きさも地味に重い。作者は 500ドルを使ってから停止を食らっている。広告主の立場で見れば、これは「出稿してみたら宣伝効果がなかった」ではない。出稿行為そのものが後から無効化される感覚に近い。しかも説明がないので、どのクリエイティブが悪かったのか、どのリンクが問題だったのか、あるいはサイト全体なのかも分からない。広告運用の修正ができないまま止まるのは、実務上かなりきつい。
さらに、再審査のたびに「追加情報を出せ」と言われるのに、追加しても何が足りないのか返ってこないのが厳しい。普通の問い合わせなら、返答をもとに修正できる。でもここでは、修正点そのものが非公開に近い。作者がEU の救済手続きに触れているのも、もはやプロダクトの改善では解けない問題だと感じているからだろう。広告審査がプラットフォームの専権に寄りすぎると、利用者は“上訴”しか手段を持てなくなる。
この話を読んで思ったのは、技術的に安全であることと、審査に通ることは別だという現実だ。作者は実際に安全確認をしているし、その姿勢は正しい。ただ、広告や配布の世界では、検査機関が理解できる形で説明できるかどうかも同じくらい重要になる。terminal multiplexer のように、背景でプロセスを持つソフトはなおさらだ。機能として正しくても、見た目が“常駐型”に寄ると、機械判定では不利になりやすい。
一方で、だから利用者側が過剰に譲歩すべきだ、とは思わない。今回の本質は、作者が「何が悪いか」を知る術を持たなかった点にある。もし理由が分かれば、説明文の修正、UI の整理、配布方法の変更など、打てる手はまだある。だがブラックボックスのままだと、開発者は無限に試行錯誤させられる。Hacker News で可視化された途端に復活した、という追記も象徴的だ。中身の修正より、外から見える圧力のほうが効いてしまったわけで、これは個人開発者にかなり不利な構図だと思う。
今回の話は、Google が間違った、で終わらせるには少し重い。むしろ問題は、間違いをどう直すかの導線が弱いことだ。false positive はゼロにできない。そこまでは現実的ではない。でも、誤検知したときに「どのファイル、どの挙動、どのドメインが引っかかったのか」を返せるかで、利用者の体験は大きく変わる。作者がここまで詳しく検証を書けたのも、説明がなかったから自前で調べ尽くした結果に見える。
広告とセキュリティが結びつく領域では、こうした問題は今後も出るはずだ。配布物にコード署名があり、サイトが静的で、外部トラッキングも少ない。そういう「素朴に健全な」構成であっても、振る舞いだけで引っかかることがある。だからこそ、プラットフォーム側には自動判定を出すだけでなく、異議申し立てのための材料を返す責任があると思う。開発者が必要なのは免罪符ではなく、修正できるヒントだ。今回それがなかったから、話はここまでこじれた。
