セキュリティチームへのLLM導入が加速しています。ログ要約やインシデント対応メモの自動化が進む一方、「AIに鍵を渡す」リスクを軽視したまま進めると深刻な事故につながります。

この記事では、フラクショナルCTOのHeather Wilde Renzeが提唱する実践的な安全導入の考え方をもとに、SecOps現場でLLMを正しく使うための判断基準を整理します。

この記事でわかること

  • LLMがSecOpsで本当に役立つ業務と、任せてはいけない判断の境界線
  • データ境界を最初に整えるべき理由
  • プロンプトインジェクションがエージェント化でどう変わるか
  • 組織の「レビューループ」に必要な要素

https://redmondmag.com/articles/2026/05/04/using–llms-in-secops-without-handing-ai-the-keys.aspx

LLMが今すぐ使える業務

セキュリティチームにLLMを投入するなら、まず高負荷かつ判断を伴わない業務から始めるべきです。

ログ要約はその典型です。40万行のログを午前2時に人間が読む必要はありません。それは機械の仕事です。インシデント対応の初期コミュニケーション文書の草稿作成も効果的で、「現時点でわかっていること」をすばやくまとめるだけでウォールームの混乱を大幅に軽減できます。コンプライアンスレポートの整備、ポリシードキュメントの更新、Microsoft Defenderアラートのティア1向け要約も実現性が高い用途です。

一方、速さと判断力を混同してはいけません。LLMは組織固有の「正常」を知りません。毎週火曜日の午後3時に発生する認証エラーのスパイクが2019年から動くバッチジョブによるものだと知っているのは、熟練アナリストだけです。LLMは毎回フラグを立て、やがてチームは見るのをやめます。「AIが間違えること」よりも「チームが注意を払わなくなること」が本当のリスクです。

エージェント化するとこの問題は指数関数的に拡大します。ログ要約の誤りは1時間のロスで済みますが、ツールアクセス権を持つエージェントの誤判断は環境全体のコストになりえます。

データ境界を最初に整える

「ユースケースから定義したい」という気持ちはわかります。しかし実際に重要なのは、何よりも先にデータ境界を整えることです。

多くの組織は、自分たちがどんなデータを持ちどこに存在するかを十分に把握していません。これはAI登場以前からの問題ですが、LLMに内部システムを接続した途端、そのギャップが一気に表面化します。

データの所在・アクセス権・分類が明確になれば、ユースケースやガードレール、承認プロセスの設計は後から比較的短時間で固まります。エージェントになればデータを読むだけでなく実際に行動します。データ境界を先に決めていなければ、障害が起きて初めてその問題と向き合うことになります。

LLMの立ち位置：「ジュニアエンジニア相当」

脅威トリアージにおけるLLMの役割は、すべての情報を読んで整理するが本当の意味での判断はできない「ジュニアエンジニア」です。

懐疑心はシミュレートできません。ルールに書かれていない理由でアラートを怪しいと気づく能力は、長年の経験に裏付けられた組織固有のパターン認識です。LLMが持つのはインターネット上の知識であり、あなたの組織のことは知りません。

不可逆なアクションには必ず人間を介在させます。エージェントがチェーンを形成している場合でも、重要な引き渡しポイントには人間のレビューを置きます。「AIが見たこと」を伝えてよいが、「AIが何をするか」を決めさせてはいけません。

プロンプトインジェクション：エージェント時代の新しい脅威

プロンプトインジェクションは、ソーシャルエンジニアリングと本質的に同じ仕組みです。人ではなくモデルを騙します。

ドキュメント、メール、サポートチケットなどLLMが処理するコンテンツに悪意ある指示を埋め込むと、モデルはシステムプロンプトと区別できずにそれに従います。OWASPのLLMアプリケーション向けTop 10でもプロンプトインジェクションは1位に位置しています（参考）。OWASPは2026年版のエージェントアプリケーション向けTop 10も公開しており、エージェント特有のリスク分類が整理されています（参考）。

エージェント化すると問題の次元が変わります。情報の誤出力だけでなく、ファイルの削除・データの外部転送・横断的な移動といった実害が発生します。メールやファイルアップロードを扱うLLMには、この攻撃面があると前提で設計します。対策は「入力をすべて信頼しない」「タスクに不要なアクセス権限を与えない」という最小権限の原則の徹底です。

健全なレビューループの設計

多くの組織のレビュープロセスは「誰かがチェックすることになっている」という認識に留まっています。

実際に機能するレビューループの核心は、役割を「チーム」ではなく特定の一人の名前に紐づけることです。AIが草稿し、名前のある人がレビューし、別の名前のある人が承認する。名前が紐づくことで読む慎重さが変わります。

高リスクな判断には独立したレビューを設けます。AIの推奨を見た人と見ていない人の両方でレビューします。同じ出力を読んで同意しただけでは、本当のセカンドオピニオンにはなりません。

もう一つ初日から始めるべきなのが、AI推奨事項のログです。提案が何件あり、何件が却下されたか。このログから、モデルがどこで失敗しているかが最も明確にわかります。エージェントパイプラインでも同様で、透明な監査ログがあれば失敗した地点を特定して再実行できます。

Microsoft環境での現実的なスタート地点

Microsoft 365環境を持つ組織なら、Copilot for Securityをサンドボックスとして活用する方法が現実的です。このツールはユーザーの既存権限の範囲内で動作するため、アーキテクチャレベルのガードレールがすでに組み込まれています。

スタート地点は「端」から、つまり影響範囲が限定的な業務です。コンプライアンスレポートの整備、Defenderアラートのティア1向けサマリー、ポリシードキュメントの更新から入ることで、レビューの習慣を先に形成できます。

Active DirectoryやIdentity管理・メールセキュリティルールへの適用は最後です。失敗したときのブラストラジウスが大きすぎます。Power Automate/AI BuilderスタックのCopilotエージェントもすでに多くの組織で動いており、これらにもエージェントリスクが存在することを把握しておくことが重要です。

Gartnerは2026年までに企業向けアプリケーションの40%にAIエージェントが組み込まれると予測しています（参考）。調査ではAIエージェントの監査証跡を持たない組織が33%に上るという報告もあります。LLMをSecOpsに導入するうえで、データ境界の整備・最小権限の構成・名前ベースのレビューループ・ログの記録という4つの準備を実行速度よりも先に済ませることが、安全な運用の前提条件です。