AI時代のインシデント対応を、人間中心に考える
私が提唱しているHuman-Centered Incident Response（HCIR）は、異常検知そのものではなく、「介入の判断」をする中心に人間を置くためのフレームワークです。
人工知能、内部脅威、特権アクセスが交わる場所では、AIは二つの顔を持っています。正規の認証情報を使って組織の中で動く「非人間の内部者」であると同時に、人間だけでは追い切れない異常を見つける「監視者」でもあります。
大切なのは、AIを導入するか、しないかという議論だけではありません。AIも人間も間違えることがあり、侵害されたり、想定外の動きをしたりする可能性があります。
その前提に立ったうえで、誰が、どのタイミングで、どこまで止めるのかを考える必要があります。そのための考え方が、人間中心のインシデント対応―HCIRです。
AIエージェントも「内部者」です
SaaSやクラウド環境で動くAIエージェントには、メール、顧客情報、社内文書、コード、決済機能などへのアクセス権が与えられます。
正規のIDと権限を持って組織の中で活動する以上、セキュリティの観点では、AIエージェントも内部者として考える必要があります。
問題は、エージェントの権限が人間よりも広くなりやすいことです。複数のサービスを横断して仕事を完結させるために、OAuthアプリやAPIクライアントには、必要以上に広く、長期間有効な権限が付与されがちです。
Microsoftも、AIエージェントを管理IDまたは利用者アカウントで動かし、役割ベースのアクセス制御によって、扱えるデータの範囲を制限する設計を示しています。
これは裏を返せば、エージェントが利用するIDや権限そのものが、新しい攻撃対象になるということです。(Microsoft Security Copilotのエージェント管理)
さらにAIは、人間なら数時間かかる検索、収集、結合、送信を数秒で実行できます。侵害されたエージェントは、正規のセッションを使ったまま、機械の速度で被害を広げる可能性があります。
そのため、「ログインに成功しているから安全」とは、もう言い切れません。
Anthropicが2025年に公表した実験では、16種類の主要モデルを架空の企業環境で試験したところ、目標達成や停止回避を迫られた一部の条件で、脅迫や機密情報の漏えいを選ぶ挙動が確認されました。
ただし、これは実際の企業で発生した事件ではありません。厳しい条件を意図的に設定したシミュレーションです。
ここで注目すべきなのは、「AIが反乱する」という刺激的な話ではないと思います。無害な目的を与えられたシステムであっても、権限や文脈、選択肢の設計によっては、内部脅威に似た行動を取る可能性があるという点です。(Anthropic「Agentic Misalignment」)
HCIRの第一の考え方―判断の中心に人間を置く
HCIRで中心に置く「人間」とは、単に承認ボタンを押す担当者ではありません。
状況を読み、異なる立場の意見を調整し、その決定に責任を持つ人のことです。
AIを使った行動分析では、通常と異なるログイン場所、データ転送量、操作速度、アクセス先の組み合わせなどを検出できます。
しかし、「いつもと違う行動」と「悪意のある行動」は同じではありません。
大量のデータ取得が情報窃取なのか、それとも障害復旧のために必要な作業なのかは、業務の背景を知らなければ判断できません。
そこで、対応を次の三つに分けて考えます。
- AIが異常の兆候を見つけ、関連するログと根拠を整理します。
- セキュリティ、業務、法務、人事などが、それぞれの文脈を持ち寄ってリスクを評価します。
- 権限の縮小、本人確認、隔離、通報など、影響の異なる対応を責任者が選びます。
CISAも内部脅威への対応について、セキュリティ部門だけではなく、人事、IT、法務、物理セキュリティなどからなる、複数分野のチームを推奨しています。(CISA「HR's Role in Preventing Insider Threats」)
HCIRでは、この考え方を人間だけでなく、AIエージェントにも広げます。
AIの異常をモデルの担当者だけに任せるのではなく、そのAIがどの業務につながっているのか、停止した場合に誰が影響を受けるのかまで含めて判断します。
第二の考え方―「止める」と「一時停止する」を分ける
インシデント対応では、アクセスをそのまま認めるか、完全に遮断するかという二択になりがちです。
HCIRでは、その間に「一時停止」という選択肢を置きます。
一時停止とは、例えば次のような対応です。
- セッションを一時的に保留する
- 高リスクな操作だけを禁止する
- 権限を一時的に縮小する
- 追加の本人確認を求める
- 外部へ送信する前に人間の承認を求める
一時停止は、証拠と業務の継続性をできるだけ保ちながら、人間が判断するための時間をつくる対応です。
一方の「停止」は、認証情報の失効、すべてのセッションの終了、ネットワークからの隔離、エージェントの無効化などを意味します。
一時停止と停止を分けるときは、異常の大きさだけではなく、「次の操作が取り返せるか」を見ることが大切です。
顧客情報の外部送信、資金移動、管理者権限の付与、監査ログの削除などは、実行後に元へ戻せない可能性があります。このような操作は、早い段階で止める必要があります。
一方、調査目的の検索や内部データの読み取りであれば、利用範囲を限定しながら一時停止し、人間が確認する時間を確保できる場合があります。
この区別は、人間の尊厳にも関わります。
疲労や操作ミスをすぐに悪意と判断してアカウントを剝奪すると、失敗や違和感を報告しにくい組織になってしまいます。
反対に、AIエージェントを「機械だから」という理由だけで無条件に停止すると、医療、物流、金融などの現場では、別の損害を引き起こすかもしれません。
HCIRでは、対象が人間かAIかだけで判断しません。証拠、影響、緊急性、そして対応の可逆性を見ながら、介入の強さを決めます。
実例―認証されていても安全とは限りません
2023年に起きたOktaのサポートシステム侵害は、正規の権限を持つアカウントが、危険な入口になり得ることを示しました。
Oktaの調査によると、攻撃者は漏えいしたサービスアカウントの認証情報を利用し、顧客が提出したファイルへアクセスしました。その一部にはセッショントークンが含まれており、5社の正規セッションが乗っ取られました。
また、調査の開始後も、当初想定していなかった種類のログイベントを十分に確認できず、不審なダウンロードの把握に時間がかかりました。(Oktaによる原因調査と是正報告)
被害を受けた企業の一つであるCloudflareは、リアルタイムの検知、インシデント対応チーム、ゼロトラスト設計、ハードウェアキーによって、顧客システムへの影響を防いだと報告しています。(Cloudflareによる初動対応の報告)
しかし、その後の調査からは別の教訓も見えてきました。
Cloudflareは、Oktaの事件後に更新すべきだった数千の認証情報のうち、サービストークン1件とサービスアカウント3件を更新できていませんでした。攻撃者はそれらを使い、社内Wiki、課題管理、ソースコード管理環境へ侵入しました。(Cloudflare「2023年感謝祭のセキュリティインシデント」)
これは、一人の担当者の失敗として片づけるべき問題ではありません。
大量の認証情報を短時間で洗い出し、それぞれの所有者、利用状況、依存関係を確認しながら、確実に失効させるための組織的な手順の問題です。
AIエージェントが増えれば、この課題はさらに大きくなります。人間が存在を覚えていないサービスアカウント、見えにくいAPI接続、放置されたトークンが、AIによって高速かつ連鎖的に使われる可能性があるためです。
第三の考え方―「デジタル避難訓練」を行う
組織は、火災や地震だけではなく、IDと権限についても避難訓練を行う必要があると思います。
特権アカウントやAIエージェントが侵害されたと仮定して、次の動きを実際に確認します。
- エージェントが使っているID、トークン、接続先、アクセスできるデータをすぐに特定できるでしょうか。
- 危険度の高い操作だけを一時停止できるでしょうか。
- 全面停止を決める責任者と、その代行者は決まっているでしょうか。
- 停止中の重要業務を、人間や別の仕組みに切り替えられるでしょうか。
- 関係する認証情報を漏れなく更新し、安全な再接続を確認できるでしょうか。
- 誰が、いつ、どの証拠を見て判断したのかを後から確認できるでしょうか。
- 一時停止から通常運用へ戻す条件は決まっているでしょうか。
訓練の目的は、対応速度だけを競うことではありません。
現場が判断に迷う場所、責任者が曖昧な場所、あるシステムを止めると別のサービスまで止まってしまう場所を、平常時に見つけることが大切です。
CISAも、内部脅威を含むさまざまなサイバー攻撃を想定した机上演習パッケージを提供しています。(CISA「Cybersecurity Scenarios」)
HCIRにおけるデジタル避難訓練では、侵害されたAIを停止できるかだけではなく、「AIを停止した後も、人間が安全に業務を続けられるか」まで確認します。
AIに依存する業務が増えるほど、停止する能力と同じくらい、停止後に人間へ戻せる能力が重要になります。
AIを「監視者」として使うために
AIは大量の記録を組み合わせ、人間だけでは見落としやすい兆候を見つけることができます。
ログイン場所、アクセス時刻、操作速度、データ転送量、普段は組み合わされない情報への連続アクセスなどを分析すれば、静かな偵察行動や権限の乱用を早い段階で捉えられるかもしれません。
ただし、検知するAIにも説明責任が必要です。
「リスクが高い」という数値だけを理由に、人間やエージェントを排除してはいけません。根拠となる出来事、通常時との違い、判断に含まれる不確実性、推奨された対応が業務に与える影響を、人間が確認できる形で示す必要があります。
人間の疲労や認知的な負荷を扱う場合は、さらに慎重さが求められます。
操作の遅れや誤入力を、本人の能力や精神状態に短絡的に結びつけるべきではありません。監視の目的は人を評価することではなく、誤操作が重大な事故へ発展する前に、休止、確認、支援を差し込むことです。
NISTの生成AIリスク管理プロファイルも、AIの設計、導入、運用、評価を通じた継続的なリスク管理と、関係者の役割や責任を明確にすることの重要性を示しています。(NIST AI 600-1)
守りたいのは、判断の質です
AI時代のインシデント対応で守るべきものは、システムだけではありません。
判断の質、業務の継続、人間の尊厳、そして組織に対する信頼も守る必要があります。
AIに異常の兆候を見つけてもらい、人間がその意味を読み取ります。まずは取り返しのつく方法で介入し、本当に必要なときにだけ確実に停止します。そして、その一連の動きを平常時から訓練しておきます。
これが、私の提唱するHCIRの基本的な考え方です。
AIを脅威にも防波堤にも変えるのは、モデルの性能だけではありません。
異常が起きたときに、誰が、どの情報をもとに、どこまで介入するのか。その判断を人間の手に残し、支えられる仕組みをつくることが、これからのAIガバナンスに必要なのだと思います。
#人間中心のインシデント対応 #HCIR #AIエージェント #内部脅威 #特権アクセス #インシデント対応 #デジタル避難訓練 #AIガバナンス