Playwright×ZAP×AIエージェントで作るCIセキュリティ検証パイプライン

今週の国内コミュニティでは、Playwright・OWASP ZAP・AIエージェントを組み合わせるCI実践が注目されました。価値は明確です。E2Eで再現できるユーザーフローをそのままセキュリティ検査へ接続できれば、再現コストと手戻りを大きく下げられます。

ただし設計を誤ると、検知ノイズで開発が停止し、最終的にパイプラインが無効化されます。鍵は段階設計とトリアージ規律です。

推奨アーキテクチャ

Stage A：決定的E2Eフロー取得

• Seed済み環境でPlaywrightを実行
• 認証状態を安全に引き継げる形で保存
• 経路カバレッジと重要導線タグを出力

Stage B：誘導付きセキュリティ探索

• PlaywrightトレースからZAPへ探索対象を供給
• 変更対象サービス中心にアクティブスキャンを限定
• パイプライン階層ごとに実行時間予算を設定

Stage C：AI支援トリアージ

• 悪用可能性を含む要約生成
• サービスオーナーへの自動ルーティング
• 修正案・回帰テスト案をPRコメント下書きとして提示

AIは理解速度を上げるために使い、承認を飛ばすためには使わない、が原則です。

パイプライン階層

• PR層（高速）：受動検査＋限定探索、10分以内
• Nightly層（深掘り）：広範囲アクティブ検査
• Release層（厳格）：重大未解決でゲート停止

全コミットで重検査を回さないことが、現場定着の前提です。

必須データ契約

• 検知スキーマ（経路・認証状態・証跡）
• 所有者マップ（service→team）
• 抑制スキーマ（理由＋失効日）
• 状態遷移（new/validated/fixed/verified）

スキーマが曖昧だと、AI出力は追跡不能なチャットログになります。

AIエージェントの適正タスク

• 類似検知のクラスタリング
• 最小再現手順の草案
• 修正候補（入力検証、認可チェック、レート制御）
• Playwright連動の回帰テスト雛形生成

不適切なのは、セキュリティ承認の省略です。

導入ステップ

1. 高価値ユーザージャーニー1本から開始
2. 2週間は誤検知率を計測
3. AIトリアージは閲覧専用で導入
4. オーナー自動振り分けを追加
5. 信号品質が安定後にブロッキングを有効化

KPI

• actionable検知率
• 検知から初回トリアージまでの時間
• 修正完了までの中央値
• セキュリティ検証のflaky率
• リリース前に捕捉した重大件数

まとめ

Playwright×ZAP×AIは、ツール寄せ集めではなくデリバリーシステムの再設計です。検知に「文脈・責任者・修正導線」を同時に付与できれば、セキュリティはボトルネックではなく開発速度の安定化要素になります。