音声・映像ディープフェイクによる CEO 詐欺への備え：見破る前提を捨て、本人確認と送金フローで止める

Posted at 2026-10-12

役員の声や顔を生成 AI で再現し、送金や情報提供をさせる「なりすまし」は、もはや想定の話ではなく公的機関が注意喚起を出している被害です。この記事では、公開された事例と米国の公的機関の資料から「何が変わったか」を確かめ、偽物を見破ることに頼らず、本人確認の経路と送金の業務フローで止める設計を、Python の小さな判定コードで確かめます。

何が起きているか：公的機関と公開事例から

ビデオ会議に出てきた「財務責任者」と同僚が全員偽物だった事例。 英国の設計・エンジニアリング会社 Arup の香港拠点の財務担当者が、英国本社の財務責任者を名乗るメッセージで内密の取引を依頼され、疑いを持ちながらも、財務責任者や同僚が参加するビデオ会議に出たことで信用し、15 回に分けて約 2 億香港ドルを送金しました。会議の参加者は生成された映像と音声でした。香港警察が 2024 年 2 月に社名を伏せて公表し、同年 5 月に Arup が偽の音声と映像が使われたことを認めています。被害に気づいたのは、担当者が本社に問い合わせた後でした。

この事例で注目すべきは、担当者が最初のメールには疑いを持っていたことです。「念のためビデオ会議で顔を見て確認する」という、多くの組織が正しいと考えてきた確認が、逆に攻撃の決め手になりました。

政府高官の声を使ったメッセージ。 FBI は 2025 年 5 月、同年 4 月から米国の現職・元職の政府高官を名乗るテキストメッセージと AI で生成した音声メッセージが送られており、信頼関係を作ったうえで個人アカウントへのアクセスを狙っていると注意喚起しました。高官を名乗るメッセージを本物だと思い込まないように、としています。

金融機関の本人確認をすり抜ける試み。 米国財務省の FinCEN は 2024 年 11 月 13 日のアラート（FIN-2024-Alert004）で、生成 AI で作った画像・映像を使って口座開設時の本人確認をすり抜けようとする疑わしい取引の届出が、2023 年から 2024 年にかけて増えていると報告しています。

国内でも AI の悪用が上位の脅威に。 IPA の「情報セキュリティ10大脅威 2026」（2026 年 1 月 29 日公開）の組織編では、「AIの利用をめぐるサイバーリスク」が初めて選ばれて 3 位に入り、ビジネスメール詐欺は 10 位でした。

見破ることに頼れない理由

NSA・FBI・CISA は 2023 年 9 月の共同資料「Contextualizing Deepfake Threats to Organizations」で、組織向けの対策として、検知の技術（メタデータや映像・音声の解析）と並べて、リアルタイムの本人確認、重要人物の保護、対応計画と演習、訓練を挙げています。検知はいくつもある対策の 1 つという位置づけです。

業務の設計としては、次の理由から「偽物かどうかを人や検知ツールが見分けられること」を安全の前提にしないほうがよいと考えます。

生成の品質は上がり続けるので、今日見分けられる不自然さが明日も残る保証はない
検知ツールは確率で判定するため、送金のように 1 回の見逃しが大きな損失になる判断の最後の砦には置けない
攻撃者は相手が確認に使う経路そのもの（ビデオ会議、電話、チャット）を用意できる。Arup の事例では、確認のための会議が攻撃者の用意したものだった

そこで、守りの重心を「この顔と声は本物か」から「この依頼は、攻撃者が用意できない経路で確かめられたか」に移します。

確認の経路を分ける：攻撃者が用意できない経路だけを数える

確認の経路は、攻撃者が用意できるかどうかで 2 つに分けられます。

確認の方法	攻撃者が用意できるか	確認として数えるか
依頼のメールに返信する	できる（送信元を偽装・乗っ取りできる）	数えない
依頼の中に書かれた番号に電話する	できる	数えない
依頼者が設定したビデオ会議で顔と声を見る	できる	数えない
社内名簿など、前から登録してある番号に折り返す	難しい	数える
社内の承認ワークフローで、別の人が自分のアカウントで承認する	難しい（アカウントの乗っ取りは別途 MFA で守る）	数える

ポイントは、依頼と同じ経路での確認や、依頼者が示した連絡先での確認を、確認として数えないことです。AHA（米国病院協会）のサイバーセキュリティ担当者も、先の FBI の注意喚起に関連して、メッセージに書かれた連絡先ではなく自分で調べた番号に電話する「アウトオブバンド」の確認を勧めています。

コードで確かめる：顔や声を判定に使わない送金依頼のチェック

送金依頼に対して必要な確認を決め、足りなければ保留にする判定を Python で書きました。顔や声が本物らしいかは一切見ていません。見るのは、依頼の中身（金額、新しい振込先か、内密か）と、誰がどの経路で何を確認したかだけです。

LLM や音声・映像の生成モデルは呼び出していません。依頼と確認の記録は固定値で与えています。実行環境は Python 3.13（標準ライブラリのみ）です。

from dataclasses import dataclass, field
from datetime import datetime, timedelta

# 社内の正規の連絡先（人事システムなどから作る。依頼の中に書かれた番号は使わない）
DIRECTORY = {
    "cfo@example.co.jp": {"name": "財務責任者", "phone": "+81-3-0000-0001"},
    "ceo@example.co.jp": {"name": "社長", "phone": "+81-3-0000-0002"},
}
# 依頼者になりすまされた本人が「経路の外」で確認できる操作だけを数える
TRUSTED_CHECKS = {"callback_directory", "approval_in_workflow"}

@dataclass
class PaymentRequest:
    request_id: str
    claimed_requester: str        # 依頼者だと名乗っている人
    channel: str                  # 依頼が届いた経路: email / video_call / voice / chat
    amount_jpy: int
    payee_is_new: bool            # 初めての振込先・振込先の変更か
    marked_confidential: bool     # 「内密に」「他の人に言わないで」
    received_at: datetime
    evidence: list = field(default_factory=list)   # 行った確認

@dataclass
class Evidence:
    kind: str          # callback_directory / approval_in_workflow / same_channel_reply / video_call_seen
    by: str            # 確認・承認した人
    detail: str = ""

def required_controls(req: PaymentRequest):
    """依頼の内容から、必要な確認を決める。顔や声が本物らしいかは判定に使わない。"""
    need = {"callback_directory"}            # 名乗った本人へ、登録済みの番号で折り返す
    approvers = 1
    hold = timedelta(0)
    if req.amount_jpy >= 1_000_000 or req.payee_is_new:
        approvers = 2                        # 依頼を受けた人以外の承認者を足す
    if req.payee_is_new:
        hold = timedelta(hours=24)           # 新しい振込先は一定時間おく
    if req.marked_confidential:
        approvers = max(approvers, 2)        # 内密の依頼ほど、ほかの人に見せる
    return need, approvers, hold

def decide(req: PaymentRequest, handler: str, now: datetime):
    need, approvers, hold = required_controls(req)
    reasons = []
    trusted = [e for e in req.evidence if e.kind in TRUSTED_CHECKS]
    ignored = [e for e in req.evidence if e.kind not in TRUSTED_CHECKS]
    for e in ignored:
        reasons.append(f"確認に数えない: {e.kind}（依頼と同じ経路・攻撃者が用意できる）")

    done = {e.kind for e in trusted}
    for kind in sorted(need - done):
        phone = DIRECTORY.get(req.claimed_requester, {}).get("phone", "未登録")
        reasons.append(f"未実施: {kind}（{phone} へ折り返す）")

    approved_by = {e.by for e in trusted if e.kind == "approval_in_workflow"}
    approved_by.discard(handler)                 # 処理担当者の自己承認は数えない
    approved_by.discard(req.claimed_requester)   # 依頼者本人の承認も数えない
    if len(approved_by) + 1 < approvers:         # 処理担当者 + 別の承認者
        reasons.append(f"承認者が不足: 別の承認者 {approvers - 1} 名が必要（現在 {len(approved_by)} 名）")

    if now < req.received_at + hold:
        reasons.append(f"保留期間中: {req.received_at + hold:%m-%d %H:%M} まで実行しない")

    blocked = any(r.startswith(("未実施", "承認者", "保留")) for r in reasons)
    return ("保留" if blocked else "実行可"), reasons

if __name__ == "__main__":
    t0 = datetime(2026, 10, 12, 10, 0)
    # 1) メールで依頼 → ビデオ会議で「財務責任者」と同僚が顔を出して念押し、という流れ
    req = PaymentRequest("R-1", "cfo@example.co.jp", "email", 30_000_000,
                         payee_is_new=True, marked_confidential=True, received_at=t0,
                         evidence=[Evidence("video_call_seen", "tanaka", "会議で本人の顔と声を確認"),
                                   Evidence("same_channel_reply", "tanaka", "メールに返信して確認")])
    print("1:", decide(req, "tanaka", t0 + timedelta(hours=1)))

    # 2) 登録番号へ折り返し、別の承認者がワークフローで承認、保留期間も経過
    req.evidence += [Evidence("callback_directory", "tanaka", "+81-3-0000-0001 に折り返し、本人が依頼したと回答"),
                     Evidence("approval_in_workflow", "suzuki")]
    print("2:", decide(req, "tanaka", t0 + timedelta(hours=25)))

    # 3) 承認者が処理担当者本人だけ（自己承認）
    req3 = PaymentRequest("R-3", "ceo@example.co.jp", "voice", 2_000_000,
                          payee_is_new=False, marked_confidential=False, received_at=t0,
                          evidence=[Evidence("callback_directory", "sato"),
                                    Evidence("approval_in_workflow", "sato")])
    print("3:", decide(req3, "sato", t0 + timedelta(minutes=30)))

実行結果です。

1: ('保留', ['確認に数えない: video_call_seen（依頼と同じ経路・攻撃者が用意できる）', '確認に数えない: same_channel_reply（依頼と同じ経路・攻撃者が用意できる）', '未実施: callback_directory（+81-3-0000-0001 へ折り返す）', '承認者が不足: 別の承認者 1 名が必要（現在 0 名）', '保留期間中: 10-13 10:00 まで実行しない'])
2: ('実行可', ['確認に数えない: video_call_seen（依頼と同じ経路・攻撃者が用意できる）', '確認に数えない: same_channel_reply（依頼と同じ経路・攻撃者が用意できる）'])
3: ('保留', ['承認者が不足: 別の承認者 1 名が必要（現在 0 名）'])

1 は Arup の事例と同じ流れです。担当者はビデオ会議で「本人の顔と声を確認した」と記録していますが、それは確認に数えられず、登録番号への折り返し・別の承認者・保留期間の 3 つが足りないため保留になります。2 は、登録番号へ折り返して本人が依頼したと答え、別の人が承認ワークフローで承認し、新しい振込先の保留期間も過ぎたので実行できます。3 は、処理担当者が自分で承認しているので、別の承認者が足りず保留です。

実装上の注意をいくつか挙げます。

連絡先は依頼から取らない。 DIRECTORY は人事システムなどから作り、依頼に書かれた番号や「新しい携帯番号」は使いません。連絡先の変更そのものも、別の経路で確かめる依頼として扱います。
「内密に」は承認者を減らす理由にしない。 内密を強調する依頼ほど、ほかの人に見せる設計にします。攻撃者が相談相手を減らそうとするのは典型的な手口です。
承認は人ではなくアカウントで数える。 会議で「承認します」と言った人を承認者にすると、偽の参加者が承認者になれます。承認は社内システムで、承認者自身のアカウントから行わせます。そのアカウントはフィッシング耐性のある MFA で守ります。

この実装で守れないこと

社内の承認ワークフローや名簿のアカウントが乗っ取られた場合
登録番号そのものが、事前の連絡先変更の詐欺で書き換えられていた場合（名簿の変更履歴を残し、変更直後の番号は信用しない運用が要ります）
送金以外の依頼（認証情報、機密資料、システム権限の付与など）。同じ考え方で、依頼の種類ごとに必要な確認を決めて広げる必要があります

業務フローに組み込むときの決めごと

「どの依頼を止めるか」を先に決める。 振込先の変更、新しい振込先への送金、一定額以上の送金、ギフトカードや暗号資産の購入、認証情報やアクセス権限の提供、機密資料の送付など、なりすましで狙われる依頼の種類を列挙し、それぞれ必要な確認を決めます。役職が上の人からの依頼ほど例外にしない、と明文化しておくことが大切です。

役員自身に「確認されること」を合意してもらう。 担当者が社長に折り返し電話をするのをためらうと、ルールは形だけになります。役員側から「私からの送金依頼は必ず登録番号に折り返して確認してよい。確認しなかったことの方を問題にする」と伝えておきます。

合言葉は補助にとどめる。 家族や少人数のチームで、事前に決めた合言葉や質問を使う方法はよく勧められます。ただし合言葉は漏れたり、本人が覚えていなかったりするので、登録番号への折り返しと承認ワークフローの代わりにはしません。

採用面接やヘルプデスクも対象に含める。 NSA・FBI・CISA の資料は、採用や会議で使われる偽の映像も訓練で扱うべき内容に挙げています。オンライン面接での本人確認や、ヘルプデスクへの「パスワードをリセットしてほしい」という電話も、同じく「攻撃者が用意できない経路で確かめる」対象です。FinCEN のアラートは、ライブでの本人確認中に技術的な不具合を理由に連絡手段を変えようとすることを、疑わしい兆候の 1 つに挙げています。

演習する。 NSA・FBI・CISA の資料は、狙われやすい役員を含めたテーブルトップ演習を勧めています。「ビデオ会議で社長が至急の送金を指示してきた」という想定で、担当者がどこで止まり、誰に相談し、どこへ報告するかを実際にたどってみると、ルールの抜けが見つかります。

役員の公開されている声と映像を把握する。 講演やインタビューの動画は、声や顔の再現の素材になります。公開を止めることは現実的ではないので、「役員は狙われる前提で、確認の経路を守る」という方針と組み合わせます。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up