はじめに：AIはセキュリティの「魔法の杖」ではない
近年、企業のセキュリティインシデント対応の現場では、攻撃側の進化スピードが加速しています。特に、生成AIの悪用によってフィッシングサイトの巧妙さは劇的に向上しました。以前のような「怪しい日本語」や「粗雑なデザイン」のフィッシングサイトは減少し、正規サイトと見分けがつかない、あるいは正規サイトの認証プロセスそのものを中継するAiTM（Adversary-in-the-Middle）攻撃が増加しています。
こうした脅威に対抗するため、多くの企業が「AIによる検知」に期待しています。しかし、ITコンサルタントとしてシステム基盤構築やセキュリティ対策の実務に携わる立場から見ると、考慮すべき現実があります。
セキュリティにおけるAIは、導入するだけで全てを解決するものではありません。
特にブラウザセキュリティの領域において、AI導入は「誤検知（False Positive）」のリスクを伴います。正規の業務システムをAIが「危険」と判断し、アクセスを遮断してしまえば、業務に支障をきたす可能性があります。
本稿で取り上げるのは、大規模な組織におけるAIフィッシング検知ツールの導入プロセスです。現場が直面しやすい「誤検知」の課題と、そこからどのようにして実用的な運用体制を構築し、最終的にインシデント対応工数を削減していくのか。その論理的かつ具体的なプロセスを解説します。
これからAIセキュリティの導入を検討されているCISOや運用責任者の方々にとって、実務に即した現実的な対策を講じるための参考情報となれば幸いです。
1. プロジェクト背景：いたちごっこからの脱却
従業員数が多い組織のWebアクセス保護
従業員数が多く、顧客情報の保護を最優先事項とする組織では、多額のセキュリティ投資が行われています。しかし近年、従来の「URLフィルタリング（ブラックリスト方式）」の限界が共通の課題となっています。
一般的なSOC（Security Operation Center）の運用では、脅威インテリジェンスフィードから提供される悪性URLリストをファイアウォールやプロキシに適用し、アクセスをブロックする手法がとられます。しかし、攻撃者は「使い捨てのフィッシングサイト」を大量生成するようになりました。
生成AIを使えば、本物そっくりのログイン画面を持つフィッシングサイトを短時間で作成できます。そして、それらは短時間で閉鎖され、新しいURLで立ち上がります。ブラックリストに登録された頃には、そのサイトは存在せず、別の新しいサイトが従業員を狙っているという状況が常態化しています。
ブラックリスト方式の限界と生成AIフィッシングの脅威
「検知した時には、もう手遅れ」という状況が発生しやすくなっています。実際の運用現場では、月に数件程度、従業員がフィッシングサイトにアクセスし、ID・パスワードを入力してしまうインシデントが発生するケースが散見されます。多要素認証（MFA）を突破するAiTM攻撃の予兆も観測されており、ID侵害による不正送金や情報漏洩のリスクが高まっています。
「既知の脅威」を防ぐだけでは不十分であり、「未知のサイト」にユーザーがアクセスしたその瞬間に、サイトの中身を解析して危険性を判断する仕組みが必要であるという論理的な帰結から、AI活用への移行が進んでいます。
2. 比較検討：なぜ「ブラウザ内AI検知」だったのか
プロキシ型(SWG) vs ブラウザ拡張型 vs ブラウザ分離
未知の脅威をリアルタイムで検知するために、セキュリティ対策の現場では主に3つの技術アプローチが比較検討の対象となります。それぞれの技術的な特徴と、導入時に考慮すべき課題は以下の通りです。
SWG（Secure Web Gateway）による通信解析
- 概要: プロキシサーバー上で通信内容を検査する手法です。
- 課題: 全てのHTTPS通信を復号（SSLデクリプション）する必要があり、アプライアンスへの負荷が非常に大きくなります。また、プライバシー保護の観点から、個人が利用する金融機関や医療機関のサイトへのアクセスまで復号することへの懸念が残ります。
RBI（Remote Browser Isolation：ブラウザ分離）
- 概要: 画面転送技術を使い、Webコンテンツをサーバー側で実行し、端末側には無害な画像データのみを送る手法です。
- 課題: 安全性は極めて高いものの、導入コストが高額になりがちです。また、ネットワーク環境によっては操作の遅延（レイテンシ）が発生しやすく、業務効率を低下させるリスクがあります。
ブラウザ拡張機能によるAI検知
- 概要: Chrome等のブラウザ上で動作する拡張機能が、表示内容を直接解析する手法です。
- 評価: エンドポイント（PC）のリソースを利用するため、サーバー負荷を気にせず全通信を検査可能です。ユーザー体験への影響も最小限に抑えられます。
決定打となる「DOM構造解析」の能力
ブラウザ拡張機能によるアプローチが、現代のフィッシング対策において特に有効とされる技術的根拠は、DOM（Document Object Model）構造への直接的なアクセス能力にあります。
高度化するフィッシングサイトを見抜くには、URLの文字列解析だけでは不十分です。「画面に何が表示され、ユーザーにどのようなアクションを求めているか」というコンテキストの把握が不可欠だからです。例えば、URLは正規のものとは異なるドメインであるにもかかわらず、画面にはMicrosoft 365のロゴが表示され、緊急性を煽る文言と共にパスワード入力フォームが存在する場合、それは極めて疑わしい状態と言えます。
ブラウザ拡張機能であれば、レンダリング後のDOMツリーを直接参照可能です。ここに最新の画像認識技術と、文脈理解に優れた自然言語処理（NLP）を組み合わせることで、攻撃者の意図をより高精度に検知できます。
特に近年のNLP技術の進化により、単なるキーワードマッチングだけでなく、文脈や感情、曖昧な表現の解釈能力が飛躍的に向上しています。これにより、「アカウントがロックされました」といった脅迫的な文言や、不自然な日本語表現、さらにはサイト全体の構成から「ユーザーに認証情報を入力させようとしている」という攻撃意図（インテント）を解析することが可能になります。
「通信の経路を見るのではなく、ユーザーが見ている画面そのものをAIの目で解析する」というアプローチは、生成AIによって巧妙化するフィッシング攻撃への対抗策として、極めて合理的であると評価できます。
3. PoCの壁：AIの「過剰防衛」と業務への影響
導入初週に発生した社内ツールへの誤検知
PoC（概念実証）の開始後、多くのプロジェクトは特有の課題に直面します。対象を特定の部門に限定してスタートした場合でも、開始早々に、社内で利用しているSaaS型の勤怠管理システムなどがブロックされる問題が頻発します。このシステムのログイン画面がシンプルで、背景が白く、入力フォームが中央にあるだけの構成であった場合、AIモデルが学習していた「典型的なフィッシングサイトの特徴」と合致してしまうためです。
「業務が止まる」という声
さらに、各部門が業務で利用している海外製のクラウドツールなどがブロックされる事態も想定されます。AIは、そのサイトのドメイン評価がまだ定まっていないことと、ログインを促す文言のパターンから「危険」と判定することがあります。
AIの検知ロジックは「黒か白か」ではなく、スコア（確率）で判断します。安全側に倒せば倒すほど、誤検知（False Positive）は増えます。しかし、検知基準を緩めれば、本物のフィッシングサイトを見逃す（False Negative）リスクが高まります。
このトレードオフをどう調整し、問題の根本原因を特定して最適な解決策を導き出すかが、プロジェクトの重要なポイントとなります。
4. 実装とチューニング：精度向上のための取り組み
ホワイトリスト運用とAI学習のハイブリッド体制
AIの判断を絶対視するのではなく、人間による運用で補完する体制を構築することが不可欠です。
まず、「組織内ホワイトリスト」の整備を進めます。社内で利用が許可されているSaaS、取引先のポータルサイト、グループ会社のドメインなどを洗い出し、これらについてはAIの判定に関わらずアクセスを許可する設定を投入します。
しかし、インターネット上の全ての安全なサイトをリスト化することは不可能です。そこで重要になるのが、AIモデル自体のチューニングです。
システム基盤の運用負荷を考慮し、ベンダーと連携して誤検知したサイトのDOM情報を分析することが推奨されます。その結果、特定のJavaScriptフレームワークを使用しているサイトを誤ってフィッシングと判定する傾向があることなどが判明します。この特徴量を「安全」寄りのパラメータとしてAIモデルに再学習させることで、同様の構造を持つサイトへの誤検知率は低下します。
ユーザーフィードバック機能の活用
さらに効果的なのが、エンドユーザーを防御プロセスに巻き込むことです。
ブロック画面のデザインを変更し、「これは業務に必要な安全なサイトです」という報告ボタンを目立つ位置に配置します。ユーザーがこのボタンを押すと、サイトは一時的に閲覧可能になり、同時にSOCへ通知が飛びます。
SOCのアナリストは、ユーザーから報告があったサイトを優先的に調査するフローを構築します。本当に安全であればホワイトリストに追加し、危険であれば再度ブロックを適用します。このサイクルを回すことで、以下の効果が得られます。
- 業務阻害の最小化: ユーザーは自己判断でアクセスを継続できるため、業務が停止しない。
- 運用負荷の分散: SOCは「報告があったサイト」だけを確認すればよくなり、全アラートを確認する必要がなくなる。
- 精度の向上: ユーザーからの報告データが、AIにとって良質な「教師データ」となる。
この「人間とAIの協調ループ」が回り始めることで、導入から一定期間後には、誤検知率は着実に低下していきます。
5. 導入後の成果：インシデント対応工数の削減
不審URL調査の自動化
一定期間のチューニングを経て全社展開を完了した組織では、その成果が数字として明確に表れる傾向にあります。
最もインパクトが大きいのは、SOCチームの工数削減です。導入前の環境では、ユーザーから寄せられる問い合わせや、プロキシログから抽出した不審な通信の調査に多くの時間が費やされがちです。
導入後は、ブラウザ上のAIが一次フィルターとして機能するため、明らかなフィッシングサイトへのアクセスは自動的に遮断されます。SOCが調査するのは、AIが「グレー」と判定したケースや、ユーザーからの誤検知報告のみに絞られます。
結果として、調査工数は大幅に減少します。空いた時間は、より高度な脅威ハンティングや、脆弱性診断といったプロアクティブなセキュリティ業務に充てることが可能になります。
未知のフィッシングサイト検知事例
質的な面でも成果が期待できます。実務の現場では、従業員に対して取引先になりすました標的型攻撃メールが届くケースが後を絶ちません。リンク先のURLは、正規のドメインと一文字違いのタイポスクワッティングドメインなどが用いられます。
従来のブラックリストには当然載っていません。しかし、このような未知の脅威に対しても、従業員がリンクをクリックした瞬間にブラウザ拡張機能が警告画面を表示し、被害を未然に防ぐことが可能です。
AIは以下の要素を複合的に検知します。
- サイト内のロゴ画像が、正規の取引先のものと酷似している。
- ページ内に「請求書」「ダウンロード」といった、フィッシングによくあるキーワードが含まれている。
- ドメインの登録日が短い。
これらを総合的に判断し、「なりすましの疑い高」としてブロックします。もし適切な検知の仕組みがなければ、従業員はIDとパスワードを入力し、ランサムウェアの侵入を許してしまう可能性があります。こうした防御の実績は、経営層に対してセキュリティ投資の対効果を証明する強力な根拠となります。
6. CISOへの提言：AIセキュリティ導入のチェックリスト
製品選定で見るべき「誤検知許容度」
これまでの分析から得られる教訓として、これからAIセキュリティ製品を選定する際に考慮すべき重要なポイントがあります。
カタログスペックの「検知率」という数字だけでなく、「誤検知をいかに許容し、コントロールできる設計になっているか」が重要です。
以下の点をチェックリストとして活用してください。
- ユーザーによるオーバーライド（一時許可）機能はあるか？
- 業務を止めないための機能として必要です。
- ホワイトリストの反映はリアルタイムか？
- 設定変更に時間がかかるようでは、現場の不満が生じる可能性があります。
- 検知理由（Why）が可視化されるか？
- 「なぜ止まったか」が論理的に分からなければ、対策やチューニングが困難になります。
- ブラウザのパフォーマンスへの影響は測定されているか？
- セキュリティのためにPCの動作が重くなっては本末転倒です。
スモールスタートの重要性と拡大計画
そして、「いきなり全社展開しない」ことが重要です。現状のシステム環境を詳細に把握した上で、まずはITリテラシーの高い部門や、誤検知の影響が比較的少ない部門でパイロット運用を行い、AIに自社の業務特性や利用ツールを学習させることが推奨されます。
「AIを育てる」という感覚を持つことが、持続可能なセキュリティ体制の構築に繋がります。最初は調整が必要かもしれませんが、適切に教育（チューニング）すれば、頼もしい存在へと成長します。
まとめ：次世代の防御体制構築に向けて
フィッシング攻撃は、もはや人間が目で見て判断できるレベルを超えています。AIによる自動検知は、企業セキュリティにおいて重要な要素となるでしょう。
しかし、そこには「誤検知」という課題が存在します。その課題を乗り越えるには、ツールの性能だけでなく、運用設計と組織の協力が重要です。
本稿では、実務に即した現実的な対策のプロセスを通じて、その一端を解説しました。多角的な視点からリスクを評価し、最適な解決策を導き出すための参考としていただければ幸いです。
コメント