「とりあえず動かす」の先にある、もう一段の工夫
以前のAgenticBlue紹介記事では、当社が開発したAgentic SOC基盤「AgenticBlue」の設計思想をご紹介しました。AIエージェントにSOCの組織知を注入し、統制と品質保証のもとで一次分析を自動化する仕組みです。この基盤のおかげで、AIによるSOC分析は「とりあえず動かす」ところまでは来ました。
ただ、「とりあえず動かす」と「本番で安定して回る」の間には、もう一段の工夫が必要です。本番環境で運用を始めると「さらに速く、さらに安定させるには」という問いが自然と出てきます。基盤が整っているからこそ、チューニングに集中できます。導入者として取り組みがいのある領域です。
AIに手順や判断基準を教え込み、SIEMなどの外部システムと接続してSOCのオペレーションを回す取り組みは、業界でも見られるようになってきました。ただ、扱うログやデバイスが限られ、手順もシンプルな環境であれば、簡単な実装でもある程度の精度は保てます。話が変わるのは、多種のデバイスから日々大量のログを相関分析する規模になったときです。コンテキストはあっという間に膨らみ、放っておけば精度も速度も落ちていきます。当社SOCはまさにこの規模で運用しているため、AIに「何を渡し、どう動かすか」を徹底的に設計する必要がありました。
本稿で扱うのは、2つのエンジニアリング領域です。AIに渡す情報を最適化する「コンテキストエンジニアリング」と、AIの動き方を統制する「ハーネスエンジニアリング」。骨格を一言で言えば、知能はSkillに厚く、制御は薄いハーネスに（Thin Harness, Fat Skills）。この分離が本稿のテーマです。
SOCに限らず、AIエージェントを業務に組み込もうとしている方にとって、「動いたあと、どこを詰めるか」の参考になれば幸いです。
コンテキストエンジニアリング：AIに何を見せ、何を見せないかを設計する
AIの「作業机」は有限である
LLM（大規模言語モデル）にはコンテキストウィンドウという、一度に扱える情報量の上限があります。人間の作業机の広さに似ています。コンテキストエンジニアリングは、この有限な机に必要な情報を、必要なタイミングで、過不足なく与える技術です。本稿では、とくに効果の出やすい「載せすぎを絞る」側に焦点を当てます。
机が一杯になると、AIは過去のやりとりを圧縮してスペースを空けます。この処理がコンパクション（Compaction）です。まず古いツール出力（SIEM検索結果など）がクリアされ、それでも足りなければ会話全体が1つの要約に畳まれます。この過程で「なぜそう判断したのか」という細部が失われやすく、分析の質と速度の両方に影響します。
速度と精度の糸口：コンテキストを節約する
コンパクションが起きないに越したことはありませんが、実はそれ以前から劣化は始まっています。コンテキストが埋まるほど推論性能が落ちる現象（Context Rot）や、長いコンテキストの中間に置かれた情報が見落とされやすい現象（Lost in the Middle）が研究で確認されています1, 2。必要な情報だけを絞って渡すことが、精度にも速度にも効くわけです。
AgenticBlue導入後、次節で紹介する3つの「絞る」設計を組み合わせた結果、代表的なアラート種別で処理時間が30%以上短縮され（対策適用前後で同一アラート種別の処理時間を比較した社内計測値）、分析精度のばらつきも小さくなりました。コンパクションが起きなければ同じアラートに毎回安定した判断が返るため、再現性も上がります。
私たちの環境でコンパクションが頻発していた原因を調べると、情報の取捨選択ができていないことが判明しました。
- 当該アラートに直接関係のない手順や情報まで読み込まれていた
- そのフェーズでは使わない情報も保持し続けていた
- SIEMの検索結果が膨大なまま渡されていた
要するに「とりあえず入れておこう」の積み重ねです。
人間の感覚では、判断材料は多いほうがいい結論を出せそうに思えます。しかしLLMでは逆です。「念のため入れておく」が重なると、重要な情報がノイズに埋もれ、推論の質も速度もコストも悪化します。
対策：3つの「絞る」設計
Skillの段階的開示：「読んだものを捨てられない」世界で
従来のソフトウェアでも、必要な時に必要なデータだけを読む設計は普通です。ただし従来のプログラムには「読んだデータから必要な値だけ抽出して、残りは捨てる」という選択肢があります。読み込んだ量が、他の処理の正確さに干渉することもありません。
LLMではこの前提が崩れます。一度コンテキストに載せた情報は、選択的に忘れさせることができません。無関係な情報が混ざっているだけで推論の質が落ちます。使わなかった情報も存在するだけで邪魔になるというのが、従来のプログラムにはないLLM固有の厄介さです。
AgenticBlueでは、顧客プロファイル・調査手順・判定基準といった組織知をSkillとして体系化しています。起動時に全Skillを載せるのではなく、必要になった時点で必要な分だけ読み込ませる、Progressive Disclosure（段階的開示）の原則を採っています。
たとえば顧客固有の特殊手順（「調査前に緊急遮断する」「特定条件で即クローズ」など）は、該当しないアラートのほうが圧倒的に多いです。従来の設計では「念のため全手順を事前に読み込む」になりがちですが、私たちの環境ではこれを反転させています。
まず「該当する特殊手順があるか」だけを軽量にチェックし、なければその先のSkill内容は一切載せない。該当した場合だけ、必要なSkillを読み込んで分岐します。
早期クローズが可能と判断された場合は、詳細分析フェーズや重要度判定フェーズを丸ごとスキップします。通らない分岐のためのコンテキストが不要になり、その分だけ速く軽くなります。
「通らない道の地図は持たない」——これがコンテキストエンジニアリングの起点です。
構造化された出力フォーマット：型で出力に天井を設ける
AIに「自由に分析結果を書いて」と指示すると、出力量はアラートの複雑さ次第で際限なく膨らみます。制約がなければ補足や推論の試行錯誤を重ね、念のための追記も加えて、書けるだけ書こうとします。しかもAIの出力は次のフェーズの入力としてコンテキストに積み上がるため、出力が冗長なほど後続のフェーズを圧迫します。
そこで、各フェーズの出力を決まった型に収めています。たとえば分析フェーズの成果物は「事実→評価→判断根拠→代替仮説→結論」の5段階構造です。型があることで、出力量に天井ができます。フェーズが進んでもコンテキストが際限なく膨張しません。型に沿って書くことで、人間のレビュアーが読みやすくなるという副次効果もあります。
検索結果のフィルタリング：MCPで取得し、ローカルのスクリプトで絞り込む
SIEMへの問い合わせはMCP（Model Context Protocol：AIと外部システムを結ぶ共通プロトコル）を通じて行い、1回の検索で必要な範囲をまとめて取得します。取得した結果はそのまま全部をAIに渡すのではなく、いったんローカルに退避したうえで、調査目的ごとに用意した解析スクリプトで集計・絞り込みをかけ、必要な事実だけを取り出します。
SIEMを何度も叩くのではなく、1回広めに取ってローカルで捌く。この分担が、検索回数の削減にもコンテキストの節約にもつながっています。
「通信先の分布を把握したい」場合と「トリガーイベントの詳細を確認したい」場合では、必要なフィールドも件数もまったく違います。フィールド選択・集計・絞り込みをオプションとして備えた汎用スクリプトをあらかじめ用意し、AIが目的に応じたオプションを指定して呼び出す仕組みです。人間のアナリストも、ログ検索で全フィールドを眺めたりはしません。熟練者が経験的に身につけた「この調査ならこのフィールドだけ見ればいい」という判断を、スクリプトとして形式化しています。
カバーできない未知のパターンが来たときは、AIが通常どおりクエリを組み立てます。そこで得られた知見は、新たなスクリプトパターンとして追加しています。運用を重ねるほどカバー範囲が広がる設計です。
何を見せないか、どう効率よく取得するか。あらかじめ設計しておくのがコンテキストエンジニアリングの勘所です。
1 M. Levy, A. Jacoby, and Y. Goldberg "Same Task, More Tokens: the Impact of Input Length on the Reasoning Performance of Large Language Models", ACL, 2024.
2 N.F. Liu et al. "Lost in the Middle: How Language Models Use Long Contexts", Transactions of the Association for Computational Linguistics, Vol.12, pp.157-173, 2024.
ハーネスエンジニアリング：AIの動き方を統制する
確率的な推論と決定論的な実行を切り分ける
ハーネスエンジニアリングという用語の定義は論者によって幅がありますが、本稿ではこう定義します。AIエージェントの「動き方」——どこをAIの柔軟な推論に委ね、どこを決定論的な仕組みで固め、何を実行させず、結果をどう記録するか——を設計すること。
すべてを機械的に縛るのでも、すべてをAIに委ねるのでもありません。確率的な推論と決定論的な実行を、意図的に切り分けるのが芯です。馬具（ハーネス）が馬の力を変えずに方向と速度を制御するように、AIを賢くするのではなく、AIが力を発揮する枠組みを設計します。
AIエージェントは柔軟に推論できます。ただし「柔軟」は「毎回違う動きをしうる」ということでもあります。本番SOCでは、柔軟さと安定性を両立させなければなりません。ハーネスはそのバランスを取る仕組みです。
AIの動き方を統制するには、決定論的なアプローチ（仕組みで必ず・確定的に効かせる）と、非決定論的なアプローチ（LLMの判断で品質を評価する）の両方が要ります。本稿では、このうち決定論的なアプローチを中心に詳しく説明します。非決定論的な仕組み（後述の独立した評価エージェント）も併用していますが、本稿の焦点は「仕組みで確定的に統制する」側に置きます。
決定論的な統制：フックによる実行制御
フック（Hook）は、ツールの実行前後に任意の処理を差し込める汎用的な仕組みです。入力の検証、引数の書き換え、レート制限、承認フローの割り込みなど、用途は幅広く存在しますが、ここでは代表的な活用例を2つ取り上げます。
PreToolUseフックの活用例：危険な操作を事前に止める
AIエージェントが柔軟に動ける以上、意図しない操作を実行するリスクは常にあります。「危険な操作はするな」とプロンプトで指示しても、AIが従うかどうかは確率の問題です。だからこそ、セキュリティの境界はAIの判断に委ねず、必ず止まる決定論的な仕組みに落とし込みます。
たとえば、ファイルやプロセスを破壊しかねないコマンド、許可していない外部ホストへの通信、想定外の書き込み操作。こうした操作を、実行に移る前の段階で確定的にブロックします。これはSecure by Designの考え方です。危険を「起きてから直す」のではなく、構造的に起こり得ないようにします。
SOCの文脈でとくに重要なのが、テナント分離ガードです。SOCは複数の顧客のログを扱います。ある顧客の調査中に、別の顧客のデータへ誤ってアクセスすることは、絶対に避けなければなりません。AIがSIEMへ問い合わせる直前に、その接続先が「いま担当している顧客のものか」を機械的に照合し、一致しなければ実行を止める仕組みを「PreToolUseフック」として組み込んでいます。プロンプトで「他の顧客のデータを見ないように」とお願いするのではなく、構造的にアクセスできないようにする。ここが決定論的な統制の要点です。
PostToolUseフックの活用例：実行内容を記録し、説明可能性を確保する
AIが出した結論の根拠を、後から追跡・検証できること。顧客に説明責任を果たすSOCにとって、これは譲れない要件です。
何が実行され、何が返り、AIがそれをどう解釈したか。すべてを構造化して確定的に記録します。「なぜこの判定に至ったのか」が後から追えなければ、AIの判断に責任を持てません。
非決定論的な補完：独立した評価エージェント
決定論的に固められる部分は仕組みで固めます。一方で、「判断の質」のように決定論では測りにくい部分もあります。ここは、独立した評価エージェント（Reviewer）がLLMの判断で工程の要所ごとにチェックするかたちで補っています。生成役と評価役を分けることで、自己肯定バイアスを避ける設計です。
2つのエンジニアリングが交差するところ
コンテキストエンジニアリングとハーネスエンジニアリングは、実際には強く連動します。見方によっては、コンテキスト設計はハーネスの一部であり、ハーネスが担う入力設計とも言えます。
- コンテキストを適切に絞ると、AIの判断精度が上がり、ハーネスが効きやすくなる
- ハーネスで実行を決定論的にすると、AIが保持すべき文脈量が減り、コンテキストに余裕が生まれる
Skillの段階的開示（Progressive Disclosure）は、この交差点にある仕組みです。コンテキスト設計の道具であり、同時にハーネスが提供する入力制御でもあります。
モデル選定、エラーハンドリング、人間のレビューフローなど、本番運用を支える要素は他にも多くあります。ただ、この2領域は見落とされがちな割に効果が大きいので、優先して取り組む価値があります。
導入者として伝えたいこと
AgenticBlueという統制された基盤があるからこそ、その上のチューニングに集中できます。AIエージェントを本番業務で運用するとき、「プロンプトを工夫する」だけでは足りない場面が出てきます。AIが動く環境そのものを設計する——システムエンジニアリングの領域に踏み込む必要がありました。
知能はSkillに厚く、制御は薄いハーネスに。この分離が、Agentic SOCを実用に耐える品質で回し続けるための要だと考えています。
コンテキストとハーネスのさらに上には、スケジュール起動や複数エージェントの分業、検証ゲートによる完了判定までを設計する「ループエンジニアリング」という層があります。しっかりしたコンテキスト設計とハーネスがあって初めて、その上に安定したループが載ります。AgenticBlueではこの領域にも取り組んでいますが、それは別の機会にご紹介します。
自社のSOC運用で、AIの導入や高度化に課題を感じておられるなら、NRIセキュアにご相談ください。長年のSOC運用で培った組織知と、統制基盤AgenticBlueを土台に、お客様の現状に合わせたかたちでお応えします。
