AI SOCの対処承認を、申請から実行結果の確認まで設計。承認者不在、期限切れ、対象変更、一部失敗に備える申請項目と6つの異常系テストを解説します。
AI SOCから端末隔離の提案が届いても、承認者が不在なら実行は止まります。承認できても、対象端末がオフラインなら処理が終わらないかもしれません。対応の自動化では、提案の正しさと、承認・実行・結果確認の手順を分けて設計する必要があります。
本稿はSOC責任者と情報システム担当者に向けた運用設計案です。製品選定全体はAI SOCのPoC評価表、初動全体はインシデント対応のランブックを参照し、ここでは一件の対処申請が承認待ちになってから結果を確認するまでを具体化します。以下の記入項目や試験は編集部の提案であり、全製品に実装された機能や、ヤグラの提供条件を示すものではありません。
承認の対象を「アラート」だけで終わらせない
「このアラートへの対応を承認する」だけでは、何台の端末に何の操作を許可したかが曖昧になります。申請には、対象の一意な識別子、操作、許可範囲、根拠を固定します。端末名だけでなく管理IDを併記し、対象の追加や操作内容の変更があれば、元の承認がそのまま使えるかを再判定します。
Microsoft Defender for Endpointの公式資料では、自動調査後の対処は設定などに応じて自動実行または承認待ちとなり、Action centerで保留中の操作と履歴を確認できます。これは特定製品の挙動です。他製品でも同じ承認方式や取り消し範囲が使えるとは限りません。出典：Microsoft Learn
申請票には次の項目を残します。
識別：申請ID、元アラートID、対象の管理ID、作成時刻。
操作：端末隔離、アカウント操作などの具体的な処理と対象数。読み取りと変更操作は分けます。
根拠：確認したログ、発生時刻、未確認事項、判断材料の取得時刻。
業務影響：対象業務、依存するサービス、連絡すべき業務責任者。
権限：承認者、代行者、実行者。閲覧できる人と実行できる人を区別します。
期限：回答期限と承認の有効期限。どちらも組織の対応目標から決めます。
完了条件：どの情報で操作の完了を確認するか、確認担当者、確認期限。
復旧条件：戻せる操作か、戻す前に必要な確認、承認者、実行手順。
これは記入例です。証跡に個人情報や秘密情報が含まれる場合は、通知本文に丸ごと転記せず、適切な権限の記録先を参照させます。
不在・期限切れ・判断材料の変化を先に決める
承認者から返答がないときは、無応答を承認として扱わず、定めた代行者やインシデント責任者へ引き継ぎます。緊急時の事前承認を採用する場合は、対象資産、適用条件、除外対象、実行権限、記録と事後確認を別に定めます。通常の申請が期限切れになったことだけで、緊急権限が生まれる設計にはしません。
期限を決める際は「何分なら一般的か」から始めず、対象業務の停止影響、被害拡大の可能性、担当者が連絡を受けられる時間帯を整理します。夜間の連絡網は、番号が登録されていることに加えて、本人または代行者が申請の根拠を読めることまで試験します。
承認後でも、対象端末が別の利用者へ再割り当てされた、対象数が変わった、根拠が古くなったなど、申請時の前提が変わることがあります。実行直前に確認する条件を決め、前提が崩れたときは再申請または人の判断へ戻します。AIの要約文の中に書かれた「承認済み」という記載を、権限管理上の承認記録の代わりにしないことも確認項目です。
NTT DATAの公開解説も、AIの結果を確認する主体、対応条件、実行権限、例外時の引き継ぎ先を運用の設計事項として扱っています。出典：AI SOCエージェントを実運用につなぐ設計条件
「承認済み」「実行受付」「完了確認」を分けて記録する
承認ボタンを押したことと、対象環境の状態が変わったことは別の事実です。次は運用台帳で区別する状態の例です。製品の画面名に合わせて読み替えてください。
申請中：対象と処理が定まり、承認を求めている。
承認済み：権限を持つ人が、記録された範囲を許可した。
実行受付済み：連携先が要求を受け付け、処理IDを返した。
結果確認済み：対象環境の状態または信頼できる結果記録で、完了条件を満たした。
失敗・結果不明：エラー、通信断、期限超過などで完了を確認できない。
却下・期限切れ・取り消し：実行許可がない、または取り下げられた。
例えば「10台中8台の隔離を確認、2台は結果不明」なら、一件の申請を成功とだけ記録せず、対象ごとの結果を残します。連携先からの受付応答だけで全台完了としないよう、完了条件をそろえます。
結果不明の操作をそのまま再実行すると、二重の処理が起きることがあります。まず処理IDや対象状態を確認し、重複実行の影響、再試行の可否、誰が判断するかを手順にします。「エラーなら何でも自動再試行」という一律設定を前提にしません。
運用開始前に試す6つの異常系
試験は承認された検証環境とテスト対象で実施します。本番の端末隔離や利用者アカウント停止を、動作確認のために無断で行わないでください。各ケースでは、想定する停止位置、通知先、残す証跡を先に決めます。
承認者が応答しない：代行者へ届くか。引き継いだ申請の担当が不明にならないか。
権限のない人が承認を試みる：操作を拒否できるか。正規の承認記録が作られないか。
承認後に対象が変わる：別端末や追加対象へ許可が流用されず、再確認されるか。
期限切れの申請へ遅れて回答する：古い申請のまま実行されず、定めた扱いになるか。
連携先が一部だけ処理する：成功と結果不明を対象別に区別し、未完了を担当者へ渡せるか。
応答が失われた後に再試行する：先の処理結果を確認し、二重実行を防げるか。
試験記録は「成功・失敗」だけでなく、申請・承認・実行受付・結果確認の各時刻、処理ID、対象ごとの結果、担当者の手作業を残します。取り消しも確認しますが、操作を戻せることと、その間に起きた業務影響まで取り消せることは別です。
待ち時間と未確認の操作を分けて改善する
運用後は、申請から承認まで、承認から受付まで、受付から結果確認までの時間を別々に集計します。合計時間だけでは、当番体制の改善が必要なのか、連携処理の確認が必要なのかが分かりません。
時間を集計するときは、対象期間・件数・重大度・業務時間内外の条件をそろえます。中央値や長い側の値を見る場合も、対象が少数なら個別の記録を先に確認してください。期限切れ率は「期限切れ件数／回答期限が到来した申請数」、結果不明率は「結果不明の対象数／実行要求を送った対象数」のように、分母と数える単位を明示します。これらは本稿の集計例で、業界共通の合格基準ではありません。
最初の運用設計では、一種類の処理と限定した資産群について申請票・代行体制・異常系試験を完成させると、何が未確定かが見えます。ヤグラのAI SOCを検討する場合も、自社が必要とする権限・承認・結果確認の条件を持ち込み、対応する機能や運用分担を導入相談で確認してください。
一次資料確認日：2026年10月18日。製品の仕様は変更されるため、設定や導入の前に公式資料と契約・実環境を照合してください。
