フィッシング検出の「常識」が崩れた
セキュリティ担当者がフィッシングメールを見抜く手がかりとして長年機能してきたのは、「おかしな日本語」「不自然なリンク」「宛名が『お客様』になっている」といった表面的なシグナルだった。それが今、ほぼ使い物にならなくなりつつある。
AWSのブログ記事が描く「Johnの話」は、その変化をよく捉えている。中堅企業のITセキュリティエンジニアである彼は、かつて「タイポを探し、汎用的な挨拶に注意し、送信ドメインの不一致を確認する」というルールで仕事をしていた。そのルールは機能していた。なぜなら、当時の攻撃は「量で勝負する粗製乱造型」だったからだ。何百万通も送って、引っかかる人を探す。精度より数でカバーする戦略だった。
生成AIはそのモデルを壊した。現代のソーシャルエンジニアリングは、OSINT（公開情報インテリジェンス）で企業の組織図、担当者の役職、プロジェクトの文脈を収集し、ターゲットに合わせた「完璧な文章」を大量生成できる。記事の表現を借りれば、「脅威はもはやどう見えるかではなく、何を知っているかで識別される」。
皮肉なことに、今や「完璧にフォーマットされた、プロらしい文章」がフィッシングの指標になる可能性すらある。
Amazon Bedrockが何をやっているのか
Amazon Bedrockは、生成AIアプリケーション構築のためのマネージドサービスで、複数の基盤モデル（Foundation Model）をAPIで統一的に利用できる。今回の記事はその上にメールセキュリティのパイプラインを構築する話だ。
アーキテクチャの骨格はシンプルだ。まず標準的なメール認証（SPF、DKIM、DMARC）でサーバーの正当性を確認する。これは「送信サーバーがそのドメインを代理して送る権限を持っているか」「メッセージが転送中に改ざんされていないか」を確かめる既存プロセスで、新しい話ではない。
問題は、そこを通過したメールだ。Bedrockを使った検出ワークフローは、その先の5ステップ分析を担う。具体的には、語彙の選択、コミュニケーションスタイルの逸脱、リクエストの文脈的妥当性の三軸でメールを評価し、リスクスコアを算出してルーティングを決定する。
重要なのは「送信者ベースライントラッカー」という概念だ。普段その人がどんな書き方をするか、どんな文体で連絡してくるかをプロファイリングし、それとの差分を見る。文法の正しさではなく、「この人らしいか」を問うアプローチだ。
もう一つの要素がAmazon Bedrock Guardrailsだ。これはコンテンツフィルター、禁止トピック、単語フィルター、機密情報フィルターを組み合わせて、モデルの入出力を制御する仕組みだ。たとえば、分析中に発見された個人識別情報（PII）を自動的にマスキングする設定が可能で、セキュリティ分析がかえって情報漏洩の経路にならないよう管理できる。
ただし、記事はここで注意を促している。「ガードレールの設定は慎重な調整が必要」という一節が繰り返し登場する。たとえば、攻撃者がフィルターを回避しようとして意図的に不快な言語をメールに含めた場合、ガードレールが厳しすぎるとそのメール自体を「分析対象から除外」してしまう。保護と分析能力のトレードオフだ。これは抽象的なリスクではなく、実装時に直面する設定問題として明示されている。
ここからは見方だが——構造として何を示しているか
この話を「AWS新機能の紹介」として読むと、実務的な示唆を見落とす。もう少し引いて見ると、これはひとつの重要な構造変化を示している。
攻撃がAI化したなら、防御もAI化する。その「対称性の時代」が来た。
従来のセキュリティ製品は、ルールベースか、過去の攻撃パターンの機械学習ベースだった。つまり「既知の悪いもの」を覚えておいて弾く設計だ。これは生成AIフィッシングには根本的に向かない。なぜなら、生成AIは毎回「ユニークなメッセージ」を作る。記事に書かれているように、攻撃者は「毎回異なる、文法的に正確で、文脈的に正確な、パーソナライズされたメッセージを大量生成」できる。過去の事例から学んでも、そのパターンとは一致しない。
Bedrockのアプローチは、「何が悪いか」ではなく「何がおかしいか」を問う。これはアーキテクチャの発想として大きく違う。文体の逸脱、コミュニケーションパターンの異常、リクエストの文脈的不自然さ——これらは個別の攻撃事例を知らなくても検出できる可能性がある。
ただし、ここで期待値を調整しておきたい。この記事はAWSのブログ、つまりプロダクト紹介の性質を持つ。「誤検知率がX%以下」「検出精度がY%」といった定量的な数字は示されていない。5ステップのパイプライン設計は具体的だが、それが実際の本番環境でどのくらいのコストと精度で動くかは、別途検証が必要だ。「センダーベースライントラッカー」が有効に機能するには、相応量の過去メールデータが必要になるはずで、導入初期の精度については慎重に見ておく必要がある。
実務担当者が考えるべきこと
この記事を読んで「よし、Bedrockを入れよう」と動く前に、考えておくべき順序がある。
まず、自社の既存フィルターへの信頼を一度疑い直すタイミングだ。SPF/DKIM/DMARCの設定は完璧でも、その先の「本当に社員が書いたか」を見る仕組みがない組織は多い。現状把握として、AI生成っぽいメールがどの程度社内に届いているかを確認することから始めると整理しやすい。
次に、ベースライン構築が先という順序問題がある。Bedrockの行動分析が機能するためには「正常な通信パターン」の蓄積が必要だ。これは導入した翌日から使えるものではない。新しいセキュリティ基盤を入れるタイミングの選択と、学習期間中のリスク管理をどうするかをセットで考える必要がある。
さらに、Guardrailsの設定は専門知識が要る。前述のように、セキュリティ文脈のコンテンツフィルターは「有害なコンテンツを分析できないようにする」と本末転倒になる。一般的なコンプライアンス用途のGuardrails設定をそのまま流用すると問題が起きる可能性がある。セキュリティエンジニアとMLエンジニアが協力して設定を詰める工程が必要だ。
次に来る論点
技術的な仕組みより、これから問題になるのは三つの軸だと見ている。
コスト。メール一通ごとに基盤モデルを呼び出す構成は、大量メールを処理する組織ではランニングコストが跳ね上がる可能性がある。スループットとコストのバランス設計は、導入時の重要な検討事項になる。
誤検知と運用負荷。「文体の逸脱」で怪しいと判定される場合、普段と違うトーンで書いた正当なメールも引っかかりかねない。急ぎで書いたメール、外国人同僚からの英文混じりのメール、役員の代わりに秘書が送ったメール……。運用が始まったとき、誤検知対応に追われるチームの負担は現実問題だ。
プライバシーと情報ガバナンス。メール内容を基盤モデルで分析するということは、社内のビジネスコミュニケーションがAWS側の処理基盤を経由するということでもある。Bedrockはデータプライバシーに関する仕様を持っているが、規制業種（金融、医療など）や国をまたぐデータ処理が関わる場合は、法務・コンプライアンスのレビューが不可欠だ。
まとめに代えて
フィッシング検出の話として読んでいたが、実は「ルールベースのセキュリティが機能しなくなる領域でどう設計するか」という、より大きな問いの一例だと思っている。
攻撃が多様化・個別化・高度化するほど、「既知の悪いパターンを覚える」設計の限界が出てくる。そこにAIを使った文脈・行動・異常検知を組み合わせるアプローチは方向性として合理的だ。ただし「AIを使えば解決」ではなく、「どのパイプラインで、どのデータで、どう調整して動かすか」という実装と運用の話に、すぐ落ちてくる。
次に同種のニュースを見るとき、確認すべき点を一つ渡しておく。「どのシグナルを使って判定しているか」だ。文法か、文脈か、ベースラインとの差分か、それとも送信サーバーの情報か。使うシグナルが変われば、攻撃者の回避戦略も変わる。そこを見ると、そのセキュリティ製品の本質的な強みと限界が見えてくる。
