Claudeでビジネスメールのフィッシングを見抜く方法

要点： Claudeは訓練を受けたアナリストと同じ視点で不審メールを読めます。認証結果、送信者との取引履歴、文面そのもの、そしてリンクが実際にどこへ解決されるか——それらを数秒で構造化された判定と根拠にまとめます。置き場所として最適なのは、社員が報告した不審メールをトリアージする「報告用メールボックス」です。これはメールセキュリティゲートウェイの補完であって代替ではありません。サンドボックスも隔離も、配信後の削除機能もありません。

中堅・中小企業のフィッシング対策は、実際にはほぼ一本しかありません。Microsoft 365やGoogle Workspaceが標準で弾いてくれる分と、たまたまその文面を読んだ人の判断力です。この組み合わせは大量配信のスパムや既知の悪性ドメインには効きます。しかし本当に損失を生むタイプのメール——添付も悪性リンクもない、短くて筋の通った、受信者が知っている相手からの、火曜日の日常業務にしか見えない依頼——には明確に弱い。本稿は、Claude APIを使って半日で組める狭くて実用的な仕組みと、それが「できないこと」のはるかに長いリストについての話です。

標準的なスパムフィルターを実際にすり抜けるもの

ビジネスメール詐欺（BEC）には検知対象が存在しません。 添付なし、悪性リンクなし、不正なヘッダーもなし。あるのは文章だけです。「いま席にいますか。締切前に取引先への支払いを一件お願いしたいのですが」。マルウェアを探すよう調整されたフィルターは何も見つけません。意図以外に何もないからです。

表示名のなりすましは認証を通過します。 SPF、DKIM、DMARCが検証するのは送信ドメインであって、メールクライアントに表示される人名ではありません。攻撃者が自分で正当に保有するドメインから送れば、三つの検査をすべて通したうえで、差出人欄に貴社の財務責任者の氏名を置けます。スマートフォンではドメインが表示されないことも多いのです。

侵害された正規アカウントはすべての検査を通ります。 取引先の本物のメールボックスが乗っ取られた場合、メールは本物のドメインから認証済みで届き、しばしば実在するスレッドの中に現れます。レピュテーション型のフィルタリングは構造上これを見抜けません。そのレピュテーションは本物だからです。

類似ドメインは新規取得され一度だけ使われます。 48時間前に取得されたドメインにはまだ悪評がありません。そもそも評判自体が存在しないからです。ブロックリストに載る頃には、そのキャンペーンは終わっています。

スレッドハイジャックは自社の文脈を借用します。 攻撃者は実在の会話を複製した中に返信し、過去の本物のやり取りを引用します。受信者を安心させるはずの要素——件名、下に続く履歴、見慣れた名前——のすべてが、攻撃側から供給されているわけです。

この五つに共通するのは、手がかりが技術的ではなく文脈的だという点です。言語モデルは「より優れたスパムフィルター」ではありませんが、この五つが必要とする種類の判断は確かに得意です。

AIによるフィッシング判定は実際どう動くのか

モデルに何を渡すか——ヘッダー、送信者履歴、本文、リンクの到達先

判定の質は、API呼び出し前にどんな証拠を組み立てたかでほぼ決まります。しかもその証拠の多くは、モデルに評価させるのではなく、決定的な処理として自前で収集すべきものです。Authentication-Resultsヘッダーは自分で解析し、SPF・DKIM・DMARCの結果を事実として渡します。本当のFromドメインを取り出し、ディレクトリと過去のやり取り履歴とコードで突き合わせます。「この表示名は社内役員と一致するが、このドメインから受信した履歴は一度もない」——この一文の事実は、どれだけ長い文体分析よりも価値があります。

リンクはすべて解決してください。アンカーテキストではなくhrefを取り、何も実行せずにリダイレクトを追い、最終到達先と登録可能ドメイン、可能なら取得からの経過日数まで渡します。プレーンテキスト本文、件名、受信者の職務、そしてそのメールがメールボックス内に実在するスレッドへの返信かどうかも渡します。そのうえで構造化出力を求めます。リスク評価、見つかった具体的な指標、確認したが存在しなかった指標、そして技術者でない同僚が読める説明文を含むJSONです。判断できないものは推測せず不明と記すよう明示してください。自信のある誤判定は、正直な空欄よりはるかに有害です。

二つの実装形態——報告用メールボックスのトリアージ型か、インライン型ゲートウェイか

形は二つありますが、自作に向いているのは一方だけです。インライン型はメールフローの中に入り、配信前にすべてを検査して遮断や隔離を行います。これを自作するとは、全社のメール配信を自分で背負うということです。タイムアウト、レート制限、モデル障害、誤検知のすべてが、失われた、あるいは遅延した業務メールになります。さらにスプール、フェイルオーバー、深夜二時に隔離メールを解放する手段まで必要になる。それは製品であってスクリプトではありませんし、成熟した製品はすでに存在します。

トリアージ型はメールフローの脇に立ちます。社員が不審メールを転送または報告し、ボットが分析して答える。何も遮断せず、何も遅延させず、最悪の失敗は返答が遅いことだけです。しかも対象は他のあらゆる防御をすり抜けてきたメールそのもの——残存リスクが実際に存在する場所です。ここから始め、明確な理由がない限りここに留まってください。

実践的な構成——「不審メール報告」ボックスのトリアージ運用

社員に取るべき行動をひとつだけ与える。 phishing@yourcompany.comのような共有メールボックス、必要ならOutlookやGmailの標準報告ボタン、そして一言の指示です。おかしいと思ったら報告してください、必ず回答します、と。報告することが、自分で判断することより簡単でなければ機能しません。

転送ではなく原本を取得する。 通常の転送は必要なヘッダーを壊します。添付形式での報告を依頼するか、プラットフォーム標準の報告機能を使うか、Microsoft GraphやGmail APIでメッセージIDから取得し、生のソースを保った状態で扱ってください。

質問する前に情報を付加する。 決定的な検査——認証結果、送信履歴に照らした初回接触判定、リンク解決、ドメイン取得からの日数、表示名がディレクトリの誰かと衝突していないか——を先に走らせ、Claudeには文章の塊ではなく構造化された証拠一式を渡します。

報告者には数分以内に、平易な言葉で返す。 「これは支払先変更を狙った詐欺の可能性が非常に高いメールです。表示名は貴部門の財務責任者と一致しますが、ドメインyourc0mpany-finance.comは9日前に取得されたもので、当社との受信履歴はありません。返信しないでください。IT部門に通知済みです」。この返信こそが、次の一通も報告してもらえる理由になります。

深刻度で振り分け、高リスク側には人を置く。 低リスクの判定は説明付きで自動的に完結して構いません。高リスクと評価されたものはITを呼び出すべきで、そこでのモデルの役割はトリアージと証拠収集であって、意思決定ではありません。

すべて記録し、週次で採点する。 証拠一式、判定、そして後から判明した事実を保存します。週二十分、判定と現実がずれた事例を見直すだけで、事前設計をいくら重ねるよりも早くプロンプトは良くなりますし、感覚ではなく実数としての誤検知率・見逃し率が手に入ります。

確認された攻撃を自社の統制に還流させる。 悪性と確定したドメインはテナントのブロックリストに入れ、他にも標的がいたならメールボックス横断の検索を走らせるべきです。分析の価値は、その結果で何をしたかで決まります。

AIトリアージ vs 管理型メールセキュリティゲートウェイ

• BECやソーシャルエンジニアリング文面の検出 — AIトリアージは実際に強く、ここは歴史的にゲートウェイが最も弱かった領域です。ただし最近のゲートウェイは独自のAIなりすまし検知を備えており、この優位は縮んでいく類のものです。
• 配信前の遮断 — ゲートウェイにしかできません。トリアージ型が答えるのはメールがすでに受信箱にある後で、リスク窓は社員が報告を決意するまでの時間そのものです。
• 添付ファイルと悪性リンク — ゲートウェイの完勝です。サンドボックスでファイルを起爆する、クリック時に再検査されるようURLを書き換える——これらは推論能力ではなく工学的な機能です。モデルはファイル名を読んでも、そのファイルが何をするかは分かりません。
• 配信後の削除 — 全メールボックスに手を伸ばし、後から悪性と判明したメールを引き上げられるのは、ゲートウェイかメール基盤だけです。APIで組んだ仕組みにはできません。
• 判定を非技術者に説明する — AIトリアージが明確に勝ります。ゲートウェイが出すのは隔離通知ですが、モデルが出すのは受信者が本当に理解できる一段落の説明で、社員の意識向上という点では多くの研修教材より価値があります。
• コストと手間 — トリアージボットは数日の統合作業と、一件あたり数円のAPI費用です。管理型ゲートウェイは継続的なサブスクリプションとベンダーとの関係です。価格構造が違うのは、そもそも同じ統制ではないからです。
• 壊れたときに何が起きるか — トリアージボットが壊れても、静かで不便なだけです。自作のインラインフィルターが壊れると、全社のメールが止まります。この非対称性こそが、トリアージ型を選ぶ理由のすべてです。

なぜこれは代替ではなく補完なのか

サンドボックスがありません。 モデルは隔離環境で添付を開き、その挙動を観察することができません。起爆しなければ得られない答えは、そもそも手に入らないということです。

配信後の回収ができません。 配信から一時間後に悪性と確定したメールを四十個のメールボックスから削除するのは、プラットフォームの機能です。ボットは推奨できますが、実行はできません。

キューがありません。 統合が止まっているあいだ、保護もなければメールの退避もありません。ゲートウェイはメールを保持するために作られていますが、スクリプトはそうではありません。

モデル自身もソーシャルエンジニアリングを受けます。 メール本文に仕込まれたプロンプトインジェクション——人間ではなく分析システムに宛てた指示——は、この設計に対する現実的かつ明白な攻撃です。メール本文は信頼できない入力として扱い、自分の指示と明確に区切り、モデルの出力だけで動作が発火しないようにし、いずれ誰かが試すと想定してください。

自信に満ちた見逃しは、ツールがないより悪い。 社員が「ボットが大丈夫と言った」と学習すれば、注意深く読むのをやめます。不確実性は返信の中で見えるようにし、低リスク判定が保証書のように読めることは絶対に避けてください。

正しく運用するために——メールデータのガバナンス、APIキー、ITに任せる範囲

報告されたメールは社内で最も機微なデータの一つです。フィッシング報告には本物の請求書、本物の契約書、本物の会話が付いてくることが珍しくなく、それを第三者APIに転送する判断には契約上・規制上の重みがあります。人とデータの所在によって、香港のPDPO、シンガポールのPDPA、中国の個人情報保護法のいずれかが関わります。何がテナントの外に出るのか、ゼロ保持のAPI条件を使うのかを意識的に決め、顧客のセキュリティ質問票に聞かれる前に答えを文書化しておいてください。

認証情報の範囲は適切に絞ります。メールボックス連携に必要なのは共有メールボックス一つへの読み取り権限であって、組織全体のメール読み取り権限ではありません。Microsoft Graphのアプリケーション権限は既定で広いため、アプリケーションアクセスポリシーでそのメールボックスだけに限定してください。Anthropic APIキーは自動化の設定ファイルではなくシークレット管理に置き、定期的に更新し、費用の異常にアラートを設定します。想定外の請求は、どこかがループしているか悪用されている最初の可視サインであることが多いのです。

ここが管理型パートナーの価値が出る地点です。Brocentの管理型メールセキュリティは、この運用が隣接するゲートウェイ層——AI支援のなりすまし・BEC検知、添付のサンドボックス、そして自社スクリプトには不可能な配信後対応——を担います。AI+サポートはトリアージ連携そのものの構築とチューニングを行い、管理型ITサポートが稼働後の認証情報管理、監視、インシデント対応を引き受けます。課題がツールではなく社員の行動側にあるなら、アジアにおけるフィッシング訓練プログラムの記事が同じ問題の教育側を扱っています。Brocentは2007年の北京での創業以来アジアで管理型ITとセキュリティを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

AIはメールセキュリティゲートウェイの代わりになりますか？

なりません。理由をはっきり書く価値があります。ゲートウェイは配信前に遮断し、添付をサンドボックスで起爆し、クリック時に再検査されるようURLを書き換え、事後に全メールボックスからメールを削除できます。API型の分析器はそのどれもできません。既存のスタックの上に文脈判断を足すものであって、スタックそのものになるわけではないのです。

不審メールをAIに転送すること自体にリスクはありませんか？

意識的に答えるべきデータ処理上の論点が生まれます。内容は機微であることが多く、しかもテナントの外に出ていきます。提供元のデータ保持・学習利用の条件を確認し、判断を記録に残してください。PDPO、PDPA、個人情報保護法の適用下にあるなら、他のクラウド処理で依拠している根拠にこの移転が含まれることを確認してください。

見逃しへの対処はどうしますか？

必ず起きる前提で、低リスク判定が保証に読めないよう返信文を設計します。すべての分析を結果とともに記録し、週次で食い違いを見直し、見逃し率を実数として追跡してください。社員が「問題なさそう」をクリック許可と受け取るなら、そのツールは状況を改善せず悪化させています。

添付ファイルや悪性リンクはどうなりますか？

ここが最も明確な限界です。モデルが読めるのはファイル名とリンクの可視テキストで、それはほとんど何も語りません。リンクの到達先は分析前にコードで解決し、添付の検査は本物のサンドボックスを持つゲートウェイに任せてください。モデルの評価を実際のスキャンの代用にしてはいけません。

メールが、それを読んでいるAIを攻撃できますか？

できます。プロンプトインジェクションがこの設計に対する明白な攻撃です。攻撃者は本文に、あなたの分析器宛ての指示を書き込めます。信頼できない内容は明確に区切り、人間か決定的なルールを挟まずにモデル出力で動作を発火させず、信頼する前に自分のプロンプトを注入攻撃で試してください。

どのメールボックスを監視すべきですか？

共有の報告用メールボックス一つ、それだけです。権限範囲もデータの足跡も小さく保て、しかも他のすべての統制をすでに通過してきたメールを狙えます。追加の判断力に費用をかける価値が最も高い母集団がそこです。

まずどこから

最初は読み取り専用版を作ってください。報告されたメールを取得し、決定的な情報付加を行い、判定を得て、チーム外の誰にも見えないIT専用チャンネルに投稿する。それを実際の報告に対して二週間走らせ、一件ずつ採点します。その二週間で得られる自社のフィッシング曝露の理解は、どのベンダーレポートより深く、しかも返信を社員に出せる品質かどうかも分かります。自動返信を有効にするのはその後です。ゲートウェイ、トリアージ層、インシデントプロセスを一つのものとして構築したい場合は、お問い合わせください。