AIを使った攻撃の話では、未知の脆弱性や高度な自動化が注目されがちです。しかし、現場で最初に起きることは、必ずしも高度な技術とは限りません。ログインを促す連絡、支払い先の変更依頼、共有ファイルへの招待、取引先を装った確認など、人が判断する入口が先に狙われます。
AIによって文章、翻訳、画像、音声の作成コストが下がると、もっともらしい依頼を大量に用意しやすくなります。だから防御の出発点は「攻撃を全部止める」ではなく、重要な操作へ到達するまでの入口を分け、確認と権限を狭くすることです。
AI時代に変わったのは「攻撃」より「説得」
メッセージの誤字や不自然な日本語を見分ければよい、という対策は弱くなっています。内容が自然でも、依頼元が本物とは限らないからです。AIが書いたかどうかを当てるより、依頼が正しい経路を通っているかを確認する方が、業務ルールに落とし込みやすくなります。
例えば、急な振込先変更、管理者権限の追加、顧客データの共有、外部ツールへの接続は、通常の連絡と同じ扱いにしません。依頼の種類に応じて、別経路での確認、二人目の承認、一定時間の保留、記録の保存を組み合わせます。
入口を4つに分けて見る
最初から全システムを精査する必要はありません。次の4つを業務単位で棚卸しします。
- ログイン: メール、管理画面、クラウド、遠隔接続。誰が使い、どの操作まで許すかを確認する。
- 支払い・設定変更: 振込先、請求先、管理者追加、公開設定。通常業務より強い確認を置く。
- 共有ファイル・フォーム: 顧客情報、契約書、社内資料、アップロード欄。公開範囲と持ち出しを確認する。
- 外部連携: APIキー、Webhook、委託先、アプリ連携。接続先、期限、停止方法を記録する。
各入口について、担当者、認証方法、許可される操作、独立確認の方法、ログの保存先、異常時の停止担当を一枚にまとめます。防御製品の一覧より先に、操作の流れを可視化するのがポイントです。
認証は「設定済み」ではなく「耐性」で評価する
IPAの「情報セキュリティ10大脅威 2026」では、組織向けの脅威としてAIの利用をめぐるサイバーリスクが取り上げられています。AIを使うかどうかだけでなく、AIを含む業務の入口をどう守るかが、管理対象になっています。
多要素認証は重要ですが、方式によってフィッシングへの耐性は異なります。NISTのデジタル・アイデンティティ指針では、認証プロトコル自体が偽サイトへの認証情報の開示を防ぐ「フィッシング耐性」が説明されています。手入力のワンタイムコードだけでは、この条件を満たさない場合があります。CISAも、利用可能な範囲でフィッシング耐性のある認証を優先する考え方を示しています。
実務では、すべてを一度に変更するより、管理者アカウント、メール、金融関連、遠隔接続の順に優先します。導入可否は利用中のサービス、端末、復旧手段、社内規程で変わるため、設定後は必ず予備の復旧経路とログイン不能時の対応を確認します。
参考: IPA 情報セキュリティ10大脅威 2026、NIST SP 800-63B、CISA More than a Password
高リスク依頼に独立確認を組み込む
攻撃者が作った文章を見破ることを、担当者の注意力だけに任せると運用が不安定になります。確認方法を業務規則にします。
- 依頼を受けた人は、元のメールやチャットの返信ボタンを使わず、社内台帳にある電話番号や別の公式チャネルで確認する。
- 振込先、権限、公開範囲、顧客データが変わる場合は、一人で完了させず、別担当が依頼内容と変更先を確認する。
- 確認できない場合は、処理を保留にし、期限、依頼者、確認結果を記録する。
- 緊急性を理由に確認を省略する場合は、誰が例外を承認したかを残す。
これは人を疑う仕組みではありません。判断を個人の記憶から、確認できる経路と記録へ移すための仕組みです。
公開範囲と権限を仕事単位で狭くする
AIエージェントや自動化ツールを導入する際、便利だからと一つのアカウントに広い権限を与えると、誤操作の影響も広がります。人、サービス、AIエージェントを分け、次の順に権限を決めます。
- 何を読む必要があるか
- 何を書き換える必要があるか
- 公開や削除まで許す必要があるか
- 権限はいつ失効させるか
- 操作ログを誰が確認するか
「全部見られるが、通常は使わない」という権限は、必要な権限ではありません。読み取り専用、対象フォルダ限定、期限付きトークン、承認後だけ書き込み可能、といった小さな境界から始めます。認証情報をプロンプトや共有メモに貼らないことも、最初に決めるルールです。
AIに守らせる範囲と、触らせない範囲
AIはログの要約、問い合わせの分類、手順書の下書き、設定差分の説明には使えます。一方で、制限なく外部を探索し、本番設定を変更し、顧客データを外へ送る役割まで与えると、便利さと同時に境界の曖昧さが増します。
AIへ渡す前に、データの種類、利用目的、保存先、削除期限を決めます。実行が必要な操作は、提案と実行を分け、承認者と停止条件を置きます。AIの出力を採用するかどうかは、人が説明できる証跡を残せるかで判断します。
事故発生後の最初の30分を決める
事故時に「まず原因を調べる」と始めると、被害の拡大やログの消失につながることがあります。最初の30分は、原因究明よりも被害範囲の限定を優先します。
- 連絡窓口を一つに集め、事実と推測を分けて記録する。
- 疑わしいアカウント、トークン、外部連携を一時停止または無効化する。
- ログ、依頼文、変更前後の設定を保存する。削除や上書きを急がない。
- 既知の正常な状態へ戻せるか確認し、復旧後の再開条件を決める。
- 顧客、委託先、関係機関への連絡要否を、契約と社内規程に沿って判断する。
この手順は、専門家の調査や法的判断の代わりではありません。緊急時に誰も動けない状態を避けるための初動の骨格です。
14日で始める小さな実装
大がかりなセキュリティ計画を作る前に、重要な入口を一つ選びます。例えば管理者ログイン、振込先変更、顧客ファイル共有のいずれかです。
- 1〜2日目: 入口、担当者、認証、許可操作、停止担当を棚卸しする。
- 3〜4日目: 影響が大きい操作をP0、確認を加えれば改善できる操作をP1、後回しにできる操作をP2に分ける。
- 5〜7日目: 独立確認、二人目の承認、保留時間、例外記録を決める。
- 8〜10日目: 認証方式と権限を見直し、テスト用の操作で復旧経路を確認する。
- 11〜14日目: 実際の依頼を一件だけ通し、迷った箇所と不要な手順を修正する。
重要なのは、14日で安全を保証することではありません。どの入口が未確認で、誰が次に判断するのかを明らかにすることです。
AI時代のセキュリティは、攻撃者の技術を追いかけ続けるだけでは運用になりません。人が判断する入口、認証、権限、証跡、復旧を分け、失敗しても戻れる流れを先に作る。小さな事業者ほど、この順番が継続できる防御になります。