📌

Claude Code × 8サブエージェントで作る脅威インテリジェンス自動パイプライン

maikushimomi

2026/02/07に公開

 はじめに
 この記事について本記事では、8つの専門AIエージェントがJSON形式のデータを受け渡しながら連携し、脅威情報の収集・検証・分析・レポート生成・PowerPoint資料作成までを自動実行するパイプラインの設計と実装を解説します。
!時間がない人は、最終的にどんなレポート(ppt)ができたのかだけでも見てください。7.アウトプット：Markdownレポート＋PowerPoint

 対象読者Claude Codeを使ったことがあり、サブエージェントに興味がある方
脅威インテリジェンス業務の自動化を検討しているセキュリティエンジニア
マルチエージェントシステムの実践的な設計パターンを学びたい方

 ゴールClaude Codeのサブエージェント（.claude/agents/*.md）の設計・定義方法
複数エージェントの依存関係を考慮した並列・逐次パイプラインの構築

JSONによるエージェント間データ受け渡しの設計パターン
脅威インテリジェンスの収集からMarkdown＋PowerPoint出力までの一気通貫自動化

 1. 全体アーキテクチャ：8エージェントが連携するパイプライン
 1.1 なぜマルチエージェントなのか？脅威インテリジェンスの処理は、1つの巨大プロンプトで完結するには複雑すぎます。


単一エージェントの課題
マルチエージェントの解決策


コンテキストウィンドウの枯渇
各エージェントが専門領域のみ担当

全工程が逐次実行
独立フェーズを並列実行で高速化

エラーで全体が停止
フェーズ単位の部分失敗許容


プロンプトが肥大化
各エージェントのMD定義が単一責任



 1.2 パイプライン全体図Phase 1: 収集（並列実行）
  ├── [tier1-collector] ──→ data/tier1/*.json    (確定情報: Confidence 90-100%)
  └── [tier2-collector] ──→ data/tier2/*.json    (推定情報: Confidence 50-89%)

Phase 2: 検証
  └── [validator] ─────────→ data/validated/*.json (クロスバリデーション)

Phase 3: エンリッチメント
  └── [enricher] ──────────→ data/enriched/*.json  (コンテキスト付与)

Phase 4: 分析（並列実行）
  ├── [correlation-analyzer] → data/correlated/*.json (相関分析)
  └── [relevance-assessor] ─→ data/assessed/*.json   (組織別優先度)

Phase 5: レポート生成
  └── [report-generator] ──→ outputs/reports/*.md     (Markdownレポート)

Phase 6: プレゼン生成
  └── [pptx-generator] ────→ outputs/presentations/*.pptx (PowerPoint)
ポイントはPhase 1とPhase 4で並列実行している点です。独立したタスクを同時に走らせることで、処理時間を大幅に短縮しています。

 1.3 ディレクトリ構成threat-intel-pipeline/
├── CLAUDE.md                    # オーケストレーション定義
├── .claude/
│   └── agents/                  # 8つのサブエージェント定義
│       ├── orchestrator.md      # 統括エージェント
│       ├── tier1-collector.md   # Tier1: 確定情報収集
│       ├── tier2-collector.md   # Tier2: 推定情報収集
│       ├── validator.md         # 検証・クロスバリデーション
│       ├── enricher.md          # エンリッチメント
│       ├── correlation-analyzer.md # 相関分析
│       ├── relevance-assessor.md   # 組織別関連性評価
│       ├── report-generator.md  # Markdownレポート生成
│       └── pptx-generator.md    # PowerPoint生成
├── config/
│   └── organization.yaml        # 組織プロファイル
├── data/                        # エージェント間データ受け渡し
│   ├── tier1/
│   ├── tier2/
│   ├── validated/
│   ├── enriched/
│   ├── correlated/
│   └── assessed/
└── outputs/
    ├── reports/                 # Markdownレポート
    └── presentations/           # PowerPointファイル
data/ ディレクトリがエージェント間のメッセージバスの役割を果たします。各エージェントはJSONファイルを読み書きすることで、疎結合にデータを受け渡します。

 2. サブエージェントの設計パターン
 2.1 Claude Codeのサブエージェント機能とはClaude Code では .claude/agents/ ディレクトリにMarkdownファイルを配置すると、独立したサブエージェントとして呼び出せます。各エージェントには専用のツールセット、モデル、役割を定義できます。
.claude/agents/
├── tier1-collector.md    # sonnetモデル + WebFetch/WebSearch
├── validator.md          # sonnetモデル + WebFetch/WebSearch
├── report-generator.md   # opusモデル + Read/Write
└── pptx-generator.md     # sonnetモデル + Bash (Node.js実行)

 2.2 エージェント定義の構造各サブエージェントはYAMLフロントマター + Markdownボディで定義します。以下は tier1-collector.md の実際の定義です。
---
name: tier1-collector
description: >
  公式・検証済み脅威インテリジェンスソース（Abuse.ch, CISA KEV, NIST NVD,
  Shodan, AlienVault OTX等）からConfidence 90-100%のIOCを収集する。
model: sonnet
tools:
  - Read
  - Write
  - Bash
  - WebFetch
  - WebSearch
---

# Tier 1: 確定情報収集Agent

## Role
公式・検証済み脅威インテリジェンスを収集する専門Agent。
出力するIOCの信頼度は **90-100%のみ**。

## 収集ソース（優先度順）
### Priority 1: マルウェア・C2情報
1. Abuse.ch URLhaus - 新規悪性URL
2. Abuse.ch ThreatFox - IOC
3. Abuse.ch Feodo Tracker - アクティブC2リスト

### Priority 2: 脆弱性情報（悪用確認済み）
1. CISA KEV - 新規追加エントリ
2. NIST NVD - CVSS 9.0以上

## 出力
`data/tier1/tier1_result_{timestamp}.json`
設計のポイントは3つです。

modelの使い分け: 収集・分析系はsonnet（高速・低コスト）、レポート生成はopus（高品質文章）

toolsの最小権限: 各エージェントに必要最小限のツールのみ付与

Markdownボディ: 自然言語で役割・ルール・出力形式を記述

 2.3 8つのエージェントの役割分担

エージェント
モデル
主要ツール
入力
出力


tier1-collector
sonnet
WebFetch, WebSearch
organization.yaml
tier1/*.json

tier2-collector
sonnet
WebFetch, WebSearch
organization.yaml
tier2/*.json

validator
sonnet
WebFetch, WebSearch
tier2/*.json
validated/*.json

enricher
sonnet
WebFetch, WebSearch
tier1/ + validated/
enriched/*.json

correlation-analyzer
sonnet
WebFetch, WebSearch
enriched/*.json
correlated/*.json

relevance-assessor
sonnet
Read, Grep
enriched/*.json + organization.yaml
assessed/*.json

report-generator
opus
Read, Write
全data/
reports/*.md

pptx-generator
sonnet
Bash (Node.js)
reports/*.md
presentations/*.pptx

report-generatorだけopusを使っているのは、エグゼクティブサマリーに高い文章品質が求められるためです。

私はMAXプランなのですべてopusです。

 3. 組織プロファイルの設計：パイプラインの「頭脳」パイプラインの分析精度を決定づけるのが config/organization.yaml です。このファイルがすべてのエージェントの判断基準になります。
# 組織基本情報
organization:
  name: "Sample Corporation"
  industry: "金融"
  region: "JP"
  size: "enterprise"

# 監視対象マルウェアファミリー
targets:
  malware_families:
    - "emotet"
    - "qakbot"
    - "cobalt_strike"
    - "lockbit"
    - "blackcat"

# 技術スタック（脆弱性の影響判定に使用）
technology_stack:
  operating_systems:
    - "Windows 11"
    - "Windows Server 2022"
    - "RHEL 9"
  applications:
    - "Microsoft 365"
    - "Exchange Online"
    - "Salesforce"
  security_tools:
    edr: "CrowdStrike"
    siem: "Splunk"
    firewall: "Palo Alto"

# 脅威優先度（関連性評価エージェントが参照）
threat_priorities:
  actors:
    critical:
      - "APT41"
      - "Lazarus Group"
    high:
      - "APT29"
      - "FIN7"
  ttps:
    critical:
      - "T1566"    # Phishing
      - "T1486"    # Data Encrypted for Impact

# 過去インシデント（パターンマッチングに使用）
historical_incidents:
  - date: "2024-06-15"
    type: "phishing"
    ttp: "T1566.001"
    description: "BEC attack targeting finance team"

 なぜ組織プロファイルが重要か
relevance-assessor が技術スタックと脅威情報を照合し、優先度スコア（最大100点）を算出します

tier1-collector が監視対象マルウェアを重点的に収集します

report-generator が組織固有のリスクに焦点を当てたレポートを生成します
例えば、Microsoft 365を使用している組織に対して「CVE-2026-21509: Microsoft Office ゼロデイ」が検出された場合、技術スタック一致で+40点、過去のフィッシングインシデントとのTTP一致で+20点、合計90点＝CRITICALと自動判定されます。

 4. データ受け渡し設計：JSONスキーマの統一
 4.1 共通メタデータスキーマ全エージェントの出力JSONに共通のメタデータを持たせています。
{
  "metadata": {
    "agent": "tier1-collector",
    "timestamp": "2026-02-07T05:42:07Z",
    "status": "partial_success",
    "collection_period": {
      "start": "2026-02-06T00:00:00Z",
      "end": "2026-02-07T05:42:07Z"
    }
  },
  "summary": {
    "total_iocs": 12,
    "by_type": { "ip": 0, "domain": 2, "url": 0, "hash": 0 },
    "by_source": { "cisa_kev": 4, "lockbit_intelligence": 4 }
  },
  "iocs": [ ... ],
  "errors": []
}
status は3値（success / partial_success / failed）で表現します。partial_success は「一部のAPIが失敗したが、他のソースから結果を取得できた」状態です。後続のエージェントはこのステータスを見て、部分データでの処理を判断します。

 4.2 信頼度（Confidence）の流れデータが各エージェントを通過するたびに、信頼度スコアが更新されます。
Tier2収集 (confidence: 65)
    ↓ Validator: VirusTotal検出 +25, MalwareBazaar確認 +30
    ↓
Validated (confidence: 95 → "promoted_to_confirmed")
    ↓ Enricher: リスクインジケーター付与
    ↓
Enriched (risk_score: 85, risk_level: "CRITICAL")
    ↓ Relevance Assessor: 組織コンテキスト照合
    ↓
Assessed (relevance_score: 90, priority: "CRITICAL")
この設計により、Tier2（未検証情報）がTier1レベルに昇格する過程が透明に追跡できます。

 4.3 Validator（検証エージェント）の判定ロジックValidatorは以下のルールで昇格・棄却を判定します。
final_confidence >= 90 → promoted_to_confirmed (Tier1昇格)
final_confidence >= 70 → high_confidence_probable
final_confidence >= 50 → moderate_confidence
final_confidence <  50 → low_confidence (監視のみ)
greynoise == "benign"  → rejected_benign (棄却)
Quality Gate: 昇格判定には最低2つの独立ソースでの確認が必須です。これにより、単一ソースの誤検知がそのまま通過することを防ぎます。

 5. オーケストレーター：パイプライン統括エージェント
 5.1 オーケストレーターの定義.claude/agents/orchestrator.md がパイプライン全体を統括します。
---
name: orchestrator
description: >
  脅威インテリジェンスパイプライン全体を統括する。
  8つのサブエージェントの実行順序・並列化・データ受け渡し・
  エラーハンドリングを管理し、MD+PPTXの最終成果物を出力する。
model: opus
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
  - Task    # ← サブエージェント呼び出し用
---
重要なのは Task ツールの存在です。これにより、オーケストレーターが他のサブエージェントを子プロセスとして起動できます。

 5.2 並列実行の仕組みClaude Codeの Task ツールは、1つのメッセージ内で複数呼び出すことで並列実行されます。
# Phase 1（並列）: 1つのメッセージで2つのTaskを同時呼び出し
Task(subagent="tier1-collector", prompt="Tier1収集を実行...")
Task(subagent="tier2-collector", prompt="Tier2収集を実行...")
→ 両方の完了を待機

# Phase 2（逐次）: Phase 1の結果に依存
Task(subagent="validator", prompt="data/tier2/の検証を実行...")

# Phase 3（逐次）
Task(subagent="enricher", prompt="data/tier1/とdata/validated/のエンリッチ...")

# Phase 4（並列）: 1つのメッセージで2つのTaskを同時呼び出し
Task(subagent="correlation-analyzer", prompt="相関分析を実行...")
Task(subagent="relevance-assessor", prompt="関連性評価を実行...")
→ 両方の完了を待機

 5.3 エラーハンドリング方針各フェーズでの失敗に対する方針をオーケストレーターに定義しています。


フェーズ
エラー時の対応


Phase 1（収集）
片方のみ成功でも続行。両方失敗なら停止

Phase 2（検証）
スキップ可。Tier1のみでPhase 3へ

Phase 3（エンリッチ）
部分エンリッチで続行

Phase 4（分析）
片方のみ成功でも続行

Phase 5（レポート）
必須。失敗時はエラーレポートを生成

Phase 6（PPTX）
オプション。失敗してもMDレポートは配信

「完璧でなくても動く」設計が重要です。外部APIが一部ダウンしていても、取得できた情報だけでレポートを生成します。

 6. 各フェーズの実装詳細
 6.1 Phase 1: 情報収集（Tier1 + Tier2 並列）Tier1 Collectorは信頼度90%以上の確定情報のみを収集します（Abuse.ch, CISA KEV, NIST NVD, Shodan, AlienVault OTX等）。Tier2 Collectorは信頼度50-89%の未検証情報を速報性重視でSNS・研究者ブログ・GitHub等から取得します。
Tier2にはFUD検出ロジックも組み込んでおり、技術的詳細のない「重大脆弱性」主張は信頼度を20点減算します。

 6.2 Phase 2: クロスバリデーションValidatorエージェントは、Tier2の未検証情報をTier1レベルのソースでクロスチェックします。
検証マトリクス:
┌──────────────┬──────────────────┬────────────────┐
│ IOCタイプ     │ 検証ソース        │ 判定基準        │
├──────────────┼──────────────────┼────────────────┤
│ Hash         │ VirusTotal       │ 検出率≥5/70→+25 │
│              │ MalwareBazaar    │ 存在確認→+30    │
├──────────────┼──────────────────┼────────────────┤
│ Domain/URL   │ URLScan.io       │ 悪性判定→+25    │
│              │ URLhaus          │ 存在確認→+30    │
├──────────────┼──────────────────┼────────────────┤
│ IP           │ GreyNoise        │ malicious→+20   │
│              │                  │ benign→即棄却    │
│              │ AbuseIPDB        │ スコア≥50→+15   │
└──────────────┴──────────────────┴────────────────┘
実際の実行結果では、14件を処理して8件がTier1に昇格、1件が棄却されました。

 6.3 Phase 3: エンリッチメント検証済みIOCにコンテキスト情報（脆弱性詳細、影響製品、パッチ状況）を付与し、リスクインジケーター（新規登録ドメイン +20、悪性ASN +25、Bulletproof Hosting +30、DGA疑い +15、複数マルウェア関連 +25）を加算してリスクスコアを算出します。

 6.4 Phase 4: 分析（相関 + 関連性評価の並列実行）Correlation AnalyzerはIOC間の相関を分析し、攻撃キャンペーンをクラスタリングします（例: 「Ransomware Ecosystem」「State-Sponsored APT Operations」等）。
Relevance Assessorは organization.yaml と照合し、最大100点のスコアリングを行います。


カテゴリ
最大スコア
例（CVE-2026-21509）


技術スタック一致
40
Microsoft 365使用中 → 40

脅威アクター一致
30
APT28 = MEDIUM → 20

攻撃手法一致
20
過去BECとTTP一致 → 20

時間的緊急性
10
アクティブ悪用 → 10

合計
100
90 → CRITICAL


 7.アウトプット：Markdownレポート＋PowerPoint
 7.1 Markdownレポート（report-generator）report-generatorはopusモデルを使用し、全フェーズの結果を統合した862行のMarkdownレポートを生成します。
レポートの構造は以下のとおりです。
---
title: 脅威インテリジェンスレポート
date: 2026-02-07
classification: TLP:AMBER
organization: Sample Corporation
slide_count_hint: 13
---

## Part 1: エグゼクティブサマリー（経営層向け）
### 1.1 この期間で何が起きたか？
### 1.2 最重要脅威トップ3
### 1.3 推奨アクション一覧

## Part 2: 技術詳細レポート（SOC向け）
### 2.1 収集統計
### 2.2 新規確認済み脅威
### 2.3 アクティブキャンペーン分析
### 2.4 IOC詳細（コピー可能形式）
### 2.5 検知ルール推奨（Sigma/Snort/YARA）
### 2.6 MITRE ATT&CKマッピング

## Part 3: アクション可能なアウトプット
### 3.1 即座にブロックすべきIOC
### 3.2 ブロックリストエクスポート

## Part 4: 付録
全主張にEvidence引用ブロックが付いている点が特徴です。
> **Evidence**:
> - Source: CISA KEV Catalog, NVD, Microsoft MSRC
> - Date: 2026-01-26（KEV登録）
> - Confidence: 95%
> - Validation: CISA KEV登録 + NVD確認 + Microsoft緊急パッチ発行

 7.2 PowerPoint生成（pptx-generator）pptx-generatorは、Markdownレポートを解析し、**PptxGenJS（Node.js）**を使って10枚のスライドを自動生成します。

 生成されるスライド構成

#
スライド
内容


1
タイトル
TLP分類、作成日、対象読者

2
脅威概要
3カラムカードで主要脅威を可視化

3
脅威アクタープロファイル
2カラム比較レイアウト

4
攻撃キルチェーン分析
シェブロン矢印フロー図

5
技術的詳細
コードブロック＋攻撃フロー図

6
IOC一覧
値を部分マスキングしたIOCテーブル

7
検知・ハンティング手法
Sigma YAML全文＋ハンティングクエリ

8
MITRE ATT&CK マッピング
ヒートマップグリッド

9
推奨対応アクション
3フェーズ（24H/1Week/1Month）フロー

10
参考情報
ソース・CVE一覧


 実際に生成されたスライド（全10枚）以下が、パイプラインが自動生成した実際のPowerPointスライドです。
Slide 1: タイトル — 左端の紫縦バー、TLP:AMBER分類、対象読者を明示しています。
Slide 2: 脅威概要（Threat Overview） — 3カラムカードで主要脅威を一覧化。各カードにCVE番号、影響範囲、影響資産を記載しています。右上に「緊急度: Critical」バッジが表示されます。
Slide 3: 脅威アクタープロファイル — APT28（Russia）とAPT31（China）を2カラム比較。別名、帰属信頼度、標的地域、標的業種、活動規模、特徴的手法を網羅しています。
Slide 4: 攻撃キルチェーン分析 — 紫シェブロンで6段階のキルチェーンを可視化。各段階にMITRE ATT&CK TTPコードと具体的な手法を記載しています。
Slide 5: 技術的詳細 — ダーク背景のコードブロックにマルウェアのPowerShellコードサンプルを表示。下部に攻撃フロー図（4ステップ）を配置しています。
Slide 6: IOC一覧 — IP、Domain、Hash、Fileの全IOCをテーブル形式で表示。安全性のためValue列は部分マスキング（IP下位オクテット、ドメイン中間、ハッシュ中間を伏字）しています。
Slide 7: 検知・ハンティング手法 — Sigma YAML全文と、Proxy Logs/EDR向けのハンティングクエリを記載しています。
Slide 8: MITRE ATT&CK マッピング — 6戦術のヒートマップグリッド。紫が観測済み、グレーが関連技法です。
Slide 9: 推奨対応アクション — 3フェーズ（Immediate/24H、Short Term/1 Week、Mid Term/1 Month）の具体的なアクションアイテムを時間軸で整理しています。
Slide 10: 参考情報・リファレンス — Tier1ソースの出典とCritical CVEの一覧です。
PptxGenJSで各スライドの座標・色・フォントを定義し、最終的に370KBのPPTXファイル（10スライド）が生成されます。生成コード全体はgenerate_pptx.js（約900行）です。

 8. パイプラインの実行方法
 8.1 フルパイプライン実行claude "フルパイプラインを実行して。config/organization.yamlの設定で過去24時間を対象に"
この一行で、8つのエージェントが順次・並列に起動し、最終的にMarkdownレポートとPowerPointが出力されます。

 8.2 部分実行# 収集と検証のみ
claude "Phase 1-2（収集と検証）のみ実行して"

# 既存レポートからPPTXだけ再生成
claude "outputs/reports/最新のMDレポートをPPTX資料に変換して"

 8.3 実行結果サマリー実際のパイプライン実行結果は以下のとおりです。
Phase 1 (収集):
  ├── tier1-collector: 12 IOCs + 4 vulnerabilities (partial_success)
  └── tier2-collector: 14 early warning items (success)

Phase 2 (検証):
  └── validator: 8 promoted, 1 rejected (success)

Phase 3 (エンリッチメント):
  └── enricher: 20 items enriched (8 CRITICAL, 8 HIGH) (success)

Phase 4 (分析):
  ├── correlation-analyzer: 4 clusters, 5 campaigns (success)
  └── relevance-assessor: 1 CRITICAL, 3 MEDIUM (success)

Phase 5 (レポート):
  └── report-generator: 862行 / 39KB Markdown (success)

Phase 6 (プレゼン):
  └── pptx-generator: 10スライド / 370KB PPTX (success)

 9. 課題と改善点：スライド生成の限界
 9.1 PptxGenJSによるスライド生成の現実ここまでパイプラインの強みを紹介してきましたが、正直に課題も共有します。最大のボトルネックはPowerPoint生成フェーズです。
実際にスライドを生成してみると、以下の問題に直面しました。


課題
具体例


レイアウト調整が困難
テキスト量に応じた自動レイアウトができず、文字がはみ出す・余白が偏る

反復的な試行錯誤
座標(x, y, w, h)をピクセル単位で調整→生成→確認→修正の繰り返し

デザインの質
プロのデザイナーが作る資料と比べると明らかに見劣りする

フォント問題
環境によってMeiryo UIが使えず、フォールバック時にレイアウトが崩壊する

コード量の肥大化
10枚のスライドで908行のJavaScriptコードが必要になった

特に、Slide 4（キルチェーン）のシェブロンの右端が見切れたり、Slide 9（推奨アクション）のテキストが密集しすぎたりと、「見た目の微調整」にかかるコストが非常に高いのが実感です。

 9.2 NotebookLMとの比較：スライド生成はNotebookLMに軍配スライド生成に限って言えば、GoogleのNotebookLMの方が圧倒的に使いやすいというのが率直な結論です。


観点
Claude Code + PptxGenJS
NotebookLM


スライド生成の手軽さ
JSコード908行を生成・実行
ソースをアップロードするだけ

レイアウトの品質
座標指定で手動調整が必要
AIが自動でレイアウト最適化

デザインの一貫性
テンプレート準拠に膨大な定義が必要
Googleスライド標準テンプレートで統一

反復改善のしやすさ
コード修正→node実行→PPTX確認のループ
会話で「この部分をもっと詳しく」と指示

図表の自動生成
全て座標指定で手動構築
データから適切なチャート・図を自動選択

日本語対応
フォント指定が必要
自然に日本語対応

NotebookLMの場合、生成されたMarkdownレポートをソースとしてアップロードし、「このレポートからブリーフィング用スライドを作成して」と依頼するだけで、整ったスライドが得られます。

 9.3 ベストプラクティス：パイプラインとスライド生成の分離この経験から導き出したベストプラクティスは、パイプラインの最終出力を「Markdownレポート」までとし、スライド生成は別ツールに委ねるという考え方です。
推奨アプローチ:

Claude Code パイプライン (Phase 1-5)
  → 収集 → 検証 → エンリッチ → 分析 → Markdownレポート
     │
     ├── そのまま技術者に配布（Markdown / PDF）
     │
     └── NotebookLM や Google Slides に投入
         → 経営層向けスライドを対話的に生成
Claude Codeの強みは、8つのエージェントによる情報収集・分析・構造化にあります。一方、最終的な「見た目の資料づくり」は、GUIベースのツールやNotebookLMのようなドキュメント理解に特化したAIの方が得意です。
適材適所で使い分けることで、パイプライン全体の品質と効率が最大化されます。

 9.4 その他の改善点スライド生成以外にも、今後改善したい点があります。

API認証の統合管理: 現在は環境変数で個別管理しているAPIキーを、AWS Secrets ManagerやVaultで一元管理したい

差分レポート: 前回実行との差分を自動検出し、「新規」「変化あり」「消失」を明示したい

STIXフォーマット対応: 現在はJSON独自スキーマだが、STIX 2.1準拠にすることで他ツールとの相互運用性を高めたい

スケジュール実行: cronやGitHub Actionsでの定期実行による完全自動化

フィードバックループ: 過去のレポートの精度を追跡し、エージェントの信頼度計算を自動チューニングしたい

 まとめ本記事では、Claude Codeの8つのサブエージェントを連携させた脅威インテリジェンスパイプラインの設計と実装を解説しました。

 要点の振り返り
サブエージェント定義: .claude/agents/*.md にYAMLフロントマター + Markdownで役割・ツール・出力形式を定義

並列実行: 依存関係のないフェーズは Task ツールの同時呼び出しで並列化

JSONによる疎結合: 各エージェントはファイル経由でのみデータを受け渡し、個別テスト・リプレイを可能に

信頼度の段階的向上: Tier2（50-89%） → Validator → Tier1（90-100%）の昇格プロセス

組織プロファイル連動: organization.yaml で定義した技術スタック・脅威優先度と自動照合

2形式のアウトプット: 技術者向けMarkdown（862行）+ 経営層向けPowerPoint（10スライド）

 一発のコマンドで得られるものclaude "フルパイプラインを実行して。config/organization.yamlの設定で過去24時間を対象に"
このコマンド一発で、8つのAIエージェントが連携し、OSINT情報の収集からクロスバリデーション、コンテキスト付与、自組織への影響分析、そして最終レポート＋プレゼン資料の生成までが完全に自動化されます。
マルチエージェントの設計パターンは、脅威インテリジェンスに限らず、「収集 → 検証 → 分析 → 出力」のワークフローを持つあらゆる業務に適用できます。ぜひ自組織のユースケースに合わせてカスタマイズしてみてください。

 参考リンクClaude Code 公式ドキュメント
MITRE ATT&CK Framework
CISA Known Exploited Vulnerabilities Catalog
Abuse.ch Threat Intelligence
PptxGenJS - JavaScript PowerPoint Library
STIX/TAXII - 脅威情報共有規格

単一エージェントの課題	マルチエージェントの解決策
コンテキストウィンドウの枯渇	各エージェントが専門領域のみ担当
全工程が逐次実行	独立フェーズを並列実行で高速化
エラーで全体が停止	フェーズ単位の部分失敗許容
プロンプトが肥大化	各エージェントのMD定義が単一責任

エージェント	モデル	主要ツール	入力	出力
tier1-collector	sonnet	WebFetch, WebSearch	organization.yaml	tier1/*.json
tier2-collector	sonnet	WebFetch, WebSearch	organization.yaml	tier2/*.json
validator	sonnet	WebFetch, WebSearch	tier2/*.json	validated/*.json
enricher	sonnet	WebFetch, WebSearch	tier1/ + validated/	enriched/*.json
correlation-analyzer	sonnet	WebFetch, WebSearch	enriched/*.json	correlated/*.json
relevance-assessor	sonnet	Read, Grep	enriched/*.json + organization.yaml	assessed/*.json
report-generator	opus	Read, Write	全data/	reports/*.md
pptx-generator	sonnet	Bash (Node.js)	reports/*.md	presentations/*.pptx

フェーズ	エラー時の対応
Phase 1（収集）	片方のみ成功でも続行。両方失敗なら停止
Phase 2（検証）	スキップ可。Tier1のみでPhase 3へ
Phase 3（エンリッチ）	部分エンリッチで続行
Phase 4（分析）	片方のみ成功でも続行
Phase 5（レポート）	必須。失敗時はエラーレポートを生成
Phase 6（PPTX）	オプション。失敗してもMDレポートは配信

カテゴリ	最大スコア	例（CVE-2026-21509）
技術スタック一致	40	Microsoft 365使用中 → 40
脅威アクター一致	30	APT28 = MEDIUM → 20
攻撃手法一致	20	過去BECとTTP一致 → 20
時間的緊急性	10	アクティブ悪用 → 10
合計	100	90 → CRITICAL

#	スライド	内容
1	タイトル	TLP分類、作成日、対象読者
2	脅威概要	3カラムカードで主要脅威を可視化
3	脅威アクタープロファイル	2カラム比較レイアウト
4	攻撃キルチェーン分析	シェブロン矢印フロー図
5	技術的詳細	コードブロック＋攻撃フロー図
6	IOC一覧	値を部分マスキングしたIOCテーブル
7	検知・ハンティング手法	Sigma YAML全文＋ハンティングクエリ
8	MITRE ATT&CK マッピング	ヒートマップグリッド
9	推奨対応アクション	3フェーズ（24H/1Week/1Month）フロー
10	参考情報	ソース・CVE一覧

課題	具体例
レイアウト調整が困難	テキスト量に応じた自動レイアウトができず、文字がはみ出す・余白が偏る
反復的な試行錯誤	座標(x, y, w, h)をピクセル単位で調整→生成→確認→修正の繰り返し
デザインの質	プロのデザイナーが作る資料と比べると明らかに見劣りする
フォント問題	環境によってMeiryo UIが使えず、フォールバック時にレイアウトが崩壊する
コード量の肥大化	10枚のスライドで908行のJavaScriptコードが必要になった

観点	Claude Code + PptxGenJS	NotebookLM
スライド生成の手軽さ	JSコード908行を生成・実行	ソースをアップロードするだけ
レイアウトの品質	座標指定で手動調整が必要	AIが自動でレイアウト最適化
デザインの一貫性	テンプレート準拠に膨大な定義が必要	Googleスライド標準テンプレートで統一
反復改善のしやすさ	コード修正→node実行→PPTX確認のループ	会話で「この部分をもっと詳しく」と指示
図表の自動生成	全て座標指定で手動構築	データから適切なチャート・図を自動選択
日本語対応	フォント指定が必要	自然に日本語対応

Accenture Japan (有志)

アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。

はじめに

この記事について

対象読者

ゴール

1. 全体アーキテクチャ：8エージェントが連携するパイプライン

1.1 なぜマルチエージェントなのか？

1.2 パイプライン全体図

1.3 ディレクトリ構成

2. サブエージェントの設計パターン

2.1 Claude Codeのサブエージェント機能とは

2.2 エージェント定義の構造

2.3 8つのエージェントの役割分担

3. 組織プロファイルの設計：パイプラインの「頭脳」

なぜ組織プロファイルが重要か

4. データ受け渡し設計：JSONスキーマの統一

4.1 共通メタデータスキーマ

4.2 信頼度（Confidence）の流れ

4.3 Validator（検証エージェント）の判定ロジック

5. オーケストレーター：パイプライン統括エージェント

5.1 オーケストレーターの定義

5.2 並列実行の仕組み

5.3 エラーハンドリング方針

6. 各フェーズの実装詳細

6.1 Phase 1: 情報収集（Tier1 + Tier2 並列）

6.2 Phase 2: クロスバリデーション

6.3 Phase 3: エンリッチメント

6.4 Phase 4: 分析（相関 + 関連性評価の並列実行）

7.アウトプット：Markdownレポート＋PowerPoint

7.1 Markdownレポート（report-generator）

7.2 PowerPoint生成（pptx-generator）

生成されるスライド構成

実際に生成されたスライド（全10枚）

8. パイプラインの実行方法

8.1 フルパイプライン実行

8.2 部分実行

8.3 実行結果サマリー

9. 課題と改善点：スライド生成の限界

9.1 PptxGenJSによるスライド生成の現実

9.2 NotebookLMとの比較：スライド生成はNotebookLMに軍配

9.3 ベストプラクティス：パイプラインとスライド生成の分離

9.4 その他の改善点

まとめ

要点の振り返り

一発のコマンドで得られるもの

参考リンク

Discussion