ZOZOのSOC（セキュリティ運用）チームが、大量に押し寄せるアラートの初動対応をClaude Codeに任せた実例を読み解く。核心は「賢いエージェントを1体作る」ことではなく、判断させないエージェントを並列で走らせるという、直感に反する設計判断にあった。
Splunk MCP・OpenCTI MCPという2つの外部ツールを「調べるだけの専門役」に分けて呼び出す構成と、危険な操作を仕組みで塞ぐ安全策、そして自分の調べ物・監視系タスクに応用するための3つのチェックポイント。
ZOZOのSOC（セキュリティ・オペレーション・センター）は3人体制で、日々発生する大量のセキュリティアラートに対応していた。1件ずつログを見て、脅威情報と照らし合わせ、優先度を判断する——この初動対応そのものが負荷の高い作業になっていた。
ZOZO TECH BLOG「Claude CodeがSOC業務を全自動でやってくれるってさ」が扱うのは、この初動対応（Tier1相当の切り分け）をClaude Codeに任せた実例だ。SOCアナリストの指示、あるいはSlackへのアラート通知をきっかけにClaude Codeが動き出し、優先度評価と対応案の検討までをこなす。
この構成が面白いのは、司令塔となるメインエージェントが自分で全部を調べに行くのではなく、調査専門の"手足"を並列で呼び出す点にある。
Splunk公式のMCP Serverからアラートデータと詳細ログを取得し、Filigran社のOpenCTI MCPから脅威インテリジェンスを取得する。前者はsearch・get_metadata・indexes_list_all・mcp_tool_executeという4つのRoleがあれば足り、後者は「Access knowledge」というRead権限のみのロールで動く。どちらも権限を絞った状態で接続されている。
opencti-agent・log-search-agent——"分析しない"サブエージェント脅威インテリジェンス取得専用のopencti-agentと、ログ取得専用のlog-search-agent。どちらもsonnetモデルで動き、記事いわく「分析機能なく、ひたすらクエリを投げる設計」。判断はここでは一切行わない。調べたいIOCの種類やログの種類に応じて、呼び出すサブエージェントを使い分ける。
この2種類のサブエージェントは、状況に応じて数十体単位で並列に呼び出される。1体が1つの問い合わせを担当する設計にすることで、「広く浅く同時に調べる」ことを実現している。
ここが核心。サブエージェントに「判断」を持たせなかったこと自体が設計判断だ。分析は司令塔（メインエージェント）に集約し、サブエージェント側は問い合わせに徹する——役割を割り切るほど、並列化しやすくなる。
過去の調査履歴もmemoryとして活用される。「このインシデントは過去に過検知フィードバックがあったものだ」「引き続きこのアクターが関与している可能性が高い」——といった過去の判断が参照され、調査の効率化と精度向上に使われている。
一件ずつ独立して調べ直すのではなく、過去に人間が下した判断を蓄積して次の調査に効かせる。この設計はセキュリティ領域に限らず、同じような問い合わせが繰り返し来る業務全般に応用が効く発想だ。
自動化の範囲が広がるほど、安全策の設計も具体的になっている。Tokenの管理には1Password CLIを使い、記事は「与えるTokenの権限を絞ることをまずお勧めします」と明記する。さらにHooksを使って、GraphQL・SPLクエリのcreate・delete系操作を明示的に禁止している。判断ミスが起きても、破壊的な操作自体が実行できない構えにしてある。
運用面では、Splunk SOAR側でNotableのReference IDをSlackアラートに含める設定により、エージェントが自動でトリガーを検知できるようにしている。人間が毎回起点を用意しなくても、既存の通知の中に検知の手がかりを仕込んでおく形だ。
セキュリティ領域そのものより、この構成パターンは「複数の外部ツールを横断して調べ物をする」タスク全般に一般化できる。ドメイン特化PRレビューの作り方で紹介した「暗黙知をガイドライン化してAIに渡す」発想の、調査業務版と言える。