アラート疲労と断片化した運用を組み直すSOC統合基盤「LanG」の設計思想

SOCの課題をまとめて扱う研究

今回取り上げる「LanG」は、大量の通知への対応に追われるアラート疲労と、ツールの断片化、AIガバナンス不在という、現代のSOCが抱える3つの課題をまとめて扱おうとする研究です。

2026年4月7日に公開された論文「LanG -- A Governance-Aware Agentic AI Platform for Unified Security Operations」では、ばらばらに届くアラートやログを1つの事件として整理し、検知ルールを作り、集まったイベントから攻撃の流れを組み立てる仕組みをAIエージェントの実行基盤の上で1つにまとめています。その上に、MCP、役割ごとの権限制御、ガードレール、監査の仕組みも重ねています。個別機能の評価結果も示されていますが、本稿では細かな性能比較より、LanGがどのような構造でSOCを組み直そうとしているのかに注目します。

論文の問題設定は明快です。現代のSOCでは、SIEM、EDR、XDRといった各種セキュリティ監視ツールやネットワーク監視、パケット解析など複数の仕組みをまたいでアラートを追う必要があり、担当者は大量の通知をふるいにかけながら、別々の画面で関係を確認しています。論文は、こうした状態をアラート疲労とツールの断片化として整理しています。そこへLLMを持ち込むと、プロンプトインジェクション、権限の逸脱、誤った出力の実行といった問題も生じるため、AIの利用そのものに統制が必要だと述べています。

LanGは何を1つにまとめているのか

LanGの特徴は、単一のAIモデルを作ったことではなく、SOCで使う複数の機能を1つの構造にまとめた点にあります。論文では、全体をセキュリティ機能の層、AIエージェントの層、MCPで機能を公開する層、その利用を制御する統制の層に分けて整理しています。具体的には、検知やログ解析などの実務機能、AIが処理を進める基盤、外部ツールやデータにアクセスするための窓口、その行動を制御する仕組みを、最初から分けて設計しています。

この分け方は実務的です。SOCで問題になるのは、AIが何を推論したかだけではありません。どのデータに触れられるか、どのツールを使えるか、どこで人が介入するか、どの操作を記録するかも同じくらい重要です。LanGは分析機能と統制機能を同じ場所に押し込むのではなく、層として分離しています。そのため、この論文の読みどころは、モデル性能よりも、各層をどう接続しているかにあります。

ばらばらの通知を1つの事件として扱う

LanGの土台にあるのが「Unified Incident Context Record」です。これは複数のアラート、ログ、侵害の痕跡を示す情報をばらばらのまま扱わず、1つの事件の文脈としてまとめるためのデータ構造です。論文では、この共通レコードの上で似たイベントをまとめ、攻撃の段階を当てはめ、時間の流れを追い、侵害の痕跡を補い、全体を俯瞰できるようにしています。個別通知を都度読むのではなく、ひとつながりの流れとして扱う前提です。

ここがLanGの第1のポイントです。SOCの業務は、単発アラートの確認だけでは終わりません。同じ攻撃の一部なのか、別件なのか、どの端末と通信先がつながっているのかを見極める必要があります。論文は、その判断を人の頭の中だけに置かず、最初からコンテキストデータとして持つ構造にしています。アラート疲労やツール断片化に対処するには、この共通コンテキストが欠かせません。

AIエージェントは自動実行だけを目指していない

LanGの第2のポイントは、AIエージェントの実行基盤です。論文ではLangGraph上で複数の処理をつないだワークフローを組み、検知、ログ分析、ルール生成、攻撃の流れの組み立てなどを段階的に進めています。重要なのは、その途中に人が確認するための停止点を置いている点です。つまり、AIが全工程を自動で進めるのではなく、人が確認してから先へ進める箇所を最初から設けています。

この設計はSOC向けのAIとして自然です。ログの要約や初動調査の整理はAIに任せやすい一方で、ルール配布や外部システムへの書き込みは誤りの影響が大きくなります。そこでLanGは、その差を無視していません。AIがすべての判断を一気に実行するのではなく、ワークフローの途中に停止点を置く構成にしています。ここが、単なるチャットボット連携や要約補助と異なる点です。

MCPで機能を公開し、その利用を制御する

LanGの第3のポイントは、外部連携の標準的な仕組みであるMCPを前提にしていることです。MCPは、AIが外部のツールやデータを決まった形式で呼び出すための接続方式です。論文では、検知、ログ分析、脅威インテリジェンス、ルール生成、AIエージェント処理といった機能をMCP経由で公開し、AIはその範囲でのみツールを利用します。AIに直接すべてを触らせるのではなく、使ってよい機能を窓口経由で明示しているわけです。

この設計が重要なのは、AIガバナンス不在という課題に直結するからです。AIをSOCに組み込むと、問題はすぐに「何ができるか」から「どこまで許可するか」へ移ります。LanGでは、MCPで機能を公開する層と、その利用を制御する層を分けたうえで、AI Governance Policy Engineがツール利用を制御します。AIが使える機能を限定し、その呼び出しを統制対象にする構成です。AIの能力を広げるより先に、AIの行動範囲を定義しています。

権限管理と監査を後付けにしていない

論文では、「MSSP」と呼ばれる複数顧客の環境を監視・運用する事業者での利用も想定しています。そのため、顧客ごとのデータ分離と、役割ごとに利用できる機能を分けるアクセス制御をシステム設計に組み込んでいます。論文の冒頭でも、顧客ごとの分離と役割ごとのアクセス制御は、この基盤の特徴として挙げられています。LanGではAdmin、Operator、Viewerという役割を設け、閲覧だけでよい利用者と、操作可能な利用者を分けています。

ここは論文の中でも実務寄りの部分です。SOCでAIを使う場合、分析精度より前に、誰がどの顧客の情報に触れられるかが問題になります。単一組織向けの実験では見えにくい論点ですが、MSSPやMDRの現場では避けて通れません。そのため、LanGはマルチテナント構成と権限制御を後から付け足した要件ではなく、アーキテクチャの一部として置いています。

危険な指示や出力を途中で止める

LanGの第4のポイントは、ガードレールの置き方です。論文では2層構成を採っています。第1層は正規表現ベースで、危険なコマンドや認証情報、持ち出しにつながる文字列などを機械的に検査します。

第2層は「Llama Prompt Guard 2」という分類器で、プロンプトインジェクションや遠回しな危険指示のように単純な文字列一致では拾いにくい内容を見ます。研究チームによれば、この2層構成によって高い精度を確保できたとしています。

この部分も、数字そのものより構成のほうが重要です。AIエージェントを安全に運用するなら、入ってくる指示と出ていく結果の両方を検査しなければなりません。LanGはガードレールを補助機能として足したのではなく、ワークフローの途中に差し込んでいます。AIがうまく答えることより、危険な動きを途中で止めることを優先した設計です。SOC用途では、この考え方のほうが自然です。

ルール生成と攻撃の流れの組み立てでLLMをどう使っているか

論文では、LLMは主に2つの役割で使われています。1つは、Snort、Suricata、YARA向けの検知ルールを作る役割です。SnortとSuricataは主にネットワーク通信の検知に使われ、YARAはファイルやマルウェアの特徴を記述して検出するときによく使われます。

もう1つは、集まったイベントをもとに、攻撃者がどの順番で何をしたのかという流れを仮説として組み立てる役割です。論文冒頭でも、ルール生成器とLLM駆動の仮説生成を含む仕組みはLanGの主要構成要素として示されています。

ルール生成の部分では、CodeLlama-7B、Mistral-7B、Qwen3-1.7-baseなど、文章やコードを生成できるオープンな大規模言語モデルを比較しています。モデル名の末尾にある「7B」や「1.7」は、モデル規模の目安です。重要なのはLanGが1つのモデルに依存せず、SOCで使う検知ルールの生成に向く複数のLLMを比べたうえで、基盤の一部として組み込もうとしていることです。実際には、4つのベースモデルを微調整してルール生成器を構成しています。

攻撃の流れを組み立てる機能でも、LLMは単独で結論を出す役割ではありません。論文では、イベントのまとまりを見つける処理、LLMによる仮説生成、別の手法による妥当性確認を組み合わせる三段構成だと説明しています。つまり、まず機械的に関連するイベント群を見つけ、そのあとで「これはどういう攻撃の流れか」をLLMに補わせ、最後に別の仕組みで確からしさを見ています。この使い方からも、LanGの主眼が「AIを好きに動かす」ことではなく、「既存の分析処理にLLMをどこまで組み込むか」にあることが分かります。

なぜクラウドではなくローカルLLMなのか

LanGがクラウド型のLLMではなく、ローカルLLMを前提にしている点も重要です。論文の議論では、LanGはGPT-5、Claude、Geminiのような外部APIではなく、微調整したローカルモデルやOllama経由のローカル推論を採用すると述べています。論文の冒頭でも、完全にローカルで動かせる構成は特徴の1つとして挙げられています。

理由は明快です。SOCが扱うのは、ログ、アラート、攻撃痕跡、調査結果、検知ルール案といった機密性の高いデータです。これらを外部クラウドへ送らずに処理したいという要求は自然です。論文では、ローカルLLMを選ぶ理由として、機密データを組織外へ出さないこと、トークン課金を避けてコストを読みやすくすること、外部APIへの往復をなくして遅延を抑えることを挙げています。MSSPのように複数顧客のデータを扱う環境では、性能だけでなく、どこで処理し、どこまでデータを外へ出すかが設計の中心になります。LanGがローカルLLMを選んでいるのは、その点を優先したからです。

もちろん、論文はその代償も書いています。1.7Bから8B規模のローカルモデルは、より大きな先端モデルより複雑な推論で不利だと認めています。それでもLanGは能力の上限より機密性、予測しやすいコスト、低遅延、統制しやすさを取っています。ここにも、この論文の姿勢が出ています。AIをできるだけ強くすることより、SOCの運用要件に収めることを優先しているわけです。

数値より、部品同士のつながりが参考になる

論文では、個別機能ごとに評価結果が示されています。論文冒頭の整理でも、ばらばらのイベントを1つの事件としてまとめる機能、検知ルール生成、攻撃の流れを組み立てる機能、ガードレールそれぞれに一定の結果が出たと報告しています。異常検知と脅威分類のモデルについても、件数の多い分類項目に重みを付けた指標で評価が示されています。

ただ、本稿で強調したいのは細かな比較ではありません。従来のSOCではルールを書く画面、ログを見る画面、ケースを管理する画面が分かれていることが珍しくありません。LanGは、その分断を前提にせず、共通コンテキスト、AI実行基盤、ツール公開、統制を一本のアーキテクチャでつないでいます。個別機能の精度向上より部品同士の接続方法に価値があります。アラート疲労とツール断片化に向き合うという題に照らすと、こちらのほうが本質です。

完成品というより設計指針として読むべき

もちろん、論文はそのまま完成品の説明ではありません。制約の節では、保存層にSQLiteを使っていること、認証基盤が簡易実装であり、本番利用にはOAuth2、SAML、LDAPとの統合が必要だと述べています。つまり、LanGはすぐに全面導入する製品というより、SOC向けAI基盤を設計するときに何を揃えるべきかを示した研究として読むのが適切です。

この読み方をすると、この論文の位置づけははっきりします。LanGはAIをSOCへ入れるとき、ログ整理やルール生成だけでは足りず、MCP、権限制御、監査、ガードレール、人手確認まで同じ図の中に入れる必要があることを示しています。アーキテクチャの価値は、AIを強くしたことではなく、AIを運用に乗せるための枠組みを整理したことにあります。

まとめ

LanGは、アラート疲労、ツール断片化、AIガバナンス不在という3つの課題に対して、SOCの機能を1つの基盤として組み直そうとした研究です。中心にあるのは、ばらばらの通知を1つの事件として扱う共通コンテキスト、AIエージェントの実行基盤、MCPによるツール公開、役割ごとの権限制御、2層ガードレール、そしてローカルLLMを前提にした設計です。

論文で押さえるべきなのは、AIの性能の高さそのものより「AIを含むSOCの構造をどう設計したか」という点です。AIをSOCへ入れるなら、先に必要なのは高機能な代理人ではなく、境界と停止点が明確な基盤です。LanGはその役割で構成されているのです。