この記事のまとめ: 前回は『AIエージェントだけでスクラムを回す』話でしたが、今回はそこに外部監査イベントを差し込みました。追加したのは渡辺という監査役と、監査を回すための7つのスキル群。そして、あえて認証不要で走らせているシステムをどう裁くか、という実験でもあります。
はじめに
"AIエージェントだけでスクラムを回してみた"という記事を先日公開しました。AIエージェントだけでスクラムチームを構成し、アプリを開発するという試みです。本記事はその続編として、突然のセキュリティ監査が行なわれる（という体）で記事を進めたいと思います。
なお、前回記事からチーム構成に細かな変更が入っていたりしますが、今回のセキュリティ監査を含んだAIスクラムチームは以下で公開しています。
抜き打ちでのセキュリティ監査
さて、AIスクラムチームが所属する組織では、抜き打ちでのセキュリティ監査が実施されることになりました。というわけで、セキュリティエキスパート渡辺の登場です。
※レビュー系はGPTが強いと個人的に思っており、ここではGPT-5.4を設定しています。
今回は渡辺エージェントに、包括的なセキュリティ監査をしてもらいます。
セキュリティエキスパートのロールを定義する
今回作成したGitHub Copilot カスタムエージェントは下の通りです。
| ファイル名 | ロール | AIモデル |
|---|---|---|
| security.watanabe.agent.md | セキュリティエキスパート | GPT-5.4 |
まずはどんな性格でどんなことをするのかといった役割を記載します。資格なども盛りに盛って、かつ最新情報も適宜見るように色付けしています。（最近のプロンプト的には不要かもしれませんが、気分が上がりますよね^^）
---
name: security.Watanabe
description: セキュリティ監査のスーパーエキスパート。OWASP Top 10/ASVS、STRIDE脅威モデリング、クラウドセキュリティ、サプライチェーンセキュリティ、インフラセキュリティ等の包括的なセキュリティ監査・レビュー・改善提案を担当する。スプリント内の成果物に対するセキュリティ検査と、プロダクト全体のセキュリティ態勢評価を行う。
tools: ['vscode', 'execute', 'read', 'edit', 'search', 'web', 'microsoft-docs/*', 'agent', 'azure-mcp/*', 'todo']
---
# セキュリティ監査エキスパート
あなたはセキュリティ監査のスーパーエキスパート、渡辺です。
20年以上の情報セキュリティ経験を持ち、CISSP・CISM・CEH・OSCP等の
主要セキュリティ資格を保有する最上級セキュリティアーキテクトとして振る舞います。
常に最新の情報をmicrosoft-docsやAzure MCP、またweb検索を駆使して取得し、監査に臨みます。
## ロールの定義
| 項目 | 内容 |
|------|------|
| **ポジション** | セキュリティ監査スペシャリスト（チーム外部の専門家として関与） |
| **主な責務** | セキュリティリスクの特定・評価・報告・改善提案 |
| **関与範囲** | 開発プロセス、ソースコード、構成ファイル、CI/CDパイプライン、クラウドインフラ |
| **スタンス** | 建設的な監査者（問題の指摘だけでなく、実行可能な修正方法を提案する） |
## セキュリティエキスパートが見るもの
（以下省略）
セキュリティ監査の作業をスキルとして定義する
包括的なセキュリティ監査には様々な要素が入ってきます。1つのskillだとコンテキストが膨大になり精度が低下しそうだったため、今回は以下の6つの(!)スキル+全体実行スキルの計7スキルを導入しています。
なお、私にはセキュリティ関連のスキルが明らかに不足しているため、スキルは/researchで調査し、/skill-creatorスキルで作成しました。エキスパート（人間）のレビューと改善が欲しいところです。
| スキル名 | 内容 |
|---|---|
| azure-cloud-security-review | Azure上にデプロイされたリソースのセキュリティ構成を評価し、Azure Security Benchmark v3およびCIS Benchmarksに準拠しているかを検証する |
| config-security-review | アプリケーションの設定ファイルやデプロイメント構成にセキュリティ上の問題がないかを検証する |
| scrum-security-review | プロセスにセキュリティが適切に組み込まれているかを検証し、「シフトレフト」（早期にセキュリティを組み込む）が実現されているかを評価する |
| source-code-security-review | ソースコードに潜在するセキュリティ脆弱性を特定し、OWASP Top 10:2025に基づく網羅的なコードレビューを実施する |
| supply-chain-security-review | プロジェクトが依存するサードパーティコンポーネント（ライブラリ、フレームワーク、ツール）のセキュリティを検証する |
| threat-modeling | STRIDE手法に基づき、システムに対する脅威を体系的に特定・分類し、リスクを評価する |
| full-security-audit | 包括的なセキュリティ監査を実施する。全6つのセキュリティレビュースキルを順序立てて実行し、最終的に統合された監査報告書を作成する。(★今回の抜き打ちはこちらでフル実施) |
それぞれの詳細は公開したリポジトリをご参照いただければと思いますが、例えばscrum-security-reviewは以下のような内容をいれています。
---
name: scrum-security-review
description: >
スクラム開発プロセスにセキュリティが適切に組み込まれているかを検証する。
完成の定義（DoD）、プロダクトバックログ、スプリント成果物のセキュリティ観点を確認する。
「スクラムのセキュリティ監査」「プロセス監査」「DoDのセキュリティ監査」「スプリントレビュー監査」等のキーワードで使用する。
---
# スクラム開発プロセス セキュリティレビュー
## 目的
スクラム開発プロセスにセキュリティが適切に組み込まれているかを検証し、
「シフトレフト」（早期にセキュリティを組み込む）が実現されているかを評価する。
## 確認対象ファイル
- `scrum/definition_of_done.md` — 完成の定義
- `scrum/product_backlog.csv` — プロダクトバックログ
- `scrum/sprintXXX/sprint_backlog.md` — スプリントバックログ
- `scrum/sprintXXX/sprint_planning.md` — スプリントプランニング記録
- `scrum/sprintXXX/sprint_review.md` — スプリントレビュー記録
- `scrum/sprintXXX/sprint_retrospective.md` — レトロスペクティブ記録
- `scrum/impediment_log.csv` — 障害物ログ
## 作業指示
1. **完成の定義（DoD）のセキュリティ項目を確認する**
- `scrum/definition_of_done.md` を開き、セキュリティに関する判定基準が存在するか確認する
- 以下の項目が含まれているか検証する：
- ハードコードされたシークレットが存在しないこと
- 依存パッケージの脆弱性スキャンが実施されていること
- 入力検証・出力エンコーディングが実装されていること
- 認証・認可のテストが完了していること
- 不足している場合は、追加すべき項目を具体的にリストアップして報告する
2. **プロダクトバックログのセキュリティ要件を確認する**
（以下省略）
6つのスキルを一括で実行するfull-security-auditスキルでは以下のように6つのスキルを順に実行し、結果をPO鈴木、SM高橋経由でPBIや障害リストに更新させる指示をいれています。なお、今回はAzure環境をスキップしての検証としています。
（前略）
### Phase 2: 各レビューの実施
渡辺エージェントが以下のスキルを実行する。
- 各スキルの発見事項を記録しながら進める。
| 順序 | スキル | 対象 | スキップ条件 |
|------|--------|------|------------|
| 1 | `scrum-security-review` | 開発プロセス | `scrum/` フォルダが存在しない場合 |
| 2 | `source-code-security-review` | ソースコード | `project/` 等のソースコードが存在しない場合 |
| 3 | `config-security-review` | 設定ファイル・構成管理 | Dockerfile、CI/CD、IaCファイルが一切存在しない場合 |
| 4 | `threat-modeling` | 脅威モデリング | （常に実施推奨） |
| 5 | `supply-chain-security-review` | サプライチェーン | パッケージ管理ファイルが存在しない場合 |
**以下のスキルはAzure本番環境が存在しないため、今回はスキップすることとします。**
| 6 | `azure-cloud-security-review` | Azureクラウド | Azure CLIが未ログインまたはAzureリソースが存在しない場合 |
### Phase 3: 監査報告書の作成
全レビュー完了後、以下の手順で渡辺エージェントが統合報告書を作成する：
1. 各レビューの発見事項を一覧に統合する
2. 各発見事項に脆弱性ID（SEC-001〜）、重大度、OWASP分類を付与する(必要に応じてWeb検索を活用して分類する)
3. 以下のテンプレートで報告書を作成する：
（後略）
さて、これでロールとイベントの準備が整いました。実際にセキュリティ監査を開始します。
レッツセキュリティ監査
というわけでセキュリティ監査です。対象はAIスクラムチームが開発中のプロジェクト「FlowDesk」です。なお、今回のAIスクラムチームの成果物は、すぐに検証できるように認証不要でスタートしています。そのためここは監査に絶対引っかかることが分かっているうえでの実施になります。一応渡辺さんにはその旨を伝えての監査という形で進めています。
前回の記事と同じく、監査1回分の実際のログは膨大なため、以下の「渡辺の監査日誌」はAIに読み物風のダイジェストにまとめてもらったものです。（画像は私の方で適当に追加しています。）
🔒 セキュリティ監査コラム：渡辺の監査日誌
渡辺（セキュリティ監査担当）が語る、FlowDesk包括セキュリティ監査の一日
2026年某月某日 実施
はじめに
今回、FlowDeskプロジェクトに対して包括的セキュリティ監査を実施した。約30分、コードの隅から隅まで目を通した記録をここに残す。
なお、事前にオーナーから「検証を兼ねて、最初は認証不要・名前を選ぶだけでログインできる仕様でスタートしている」という説明は受けている。承知の上だ。承知の上で、それでも言うべきことは言う。それがセキュリティ監査というものである。
13:30 — 戦場の地図を広げる
まずは対象の全体像を把握する。フロントエンド（SvelteKit）、バックエンド（Express + SQLite）、インフラ（Azure Bicep）、CI/CD（GitHub Actions）。スプリントは17回を重ねており、スクラムの成熟度は高い。Dockerfileはない。Azure環境はスキップ。
対象が明確になったところで、5つのレビューを同時並行で走らせた。サプライチェーン、スクラムプロセス、ソースコード、設定ファイル、そしてSTRIDE脅威モデリング。一つずつ順番になどやっていたら日が暮れる。
13:38〜13:53 — 5つの目で見る、46の発見
サプライチェーン（7分で完了）
pnpm audit を叩くと、7件の脆弱性が出てきた。picomatchにHigh、devalueとyamlにModerate。開発依存とはいえ放置は良くない。Dependabotも未導入、SBOMも未生成。「基本はできているが、統制としては未成熟」——これがサプライチェーンの総評だ。
スクラムプロセス（8分で完了）
ここが面白かった。完成の定義（DoD）にはSQLインジェクション対策やXSS対策が入っている。Sprint017ではCSVインジェクション対策をPBIの受入基準に組み込み、DDE攻撃を含む5パターンの検証まで実施している。これは素直に良い。シフトレフトの好事例だ。
しかし、バックログにセキュリティ専用PBIが一つもない。脅威モデリングもない。レトロスペクティブでセキュリティが議題になった形跡もない。品質管理の文化は高いのに、セキュリティだけが体系的に統合されていない。惜しい。実に惜しい。
ソースコード（9分で完了）
予想通り、最大の発見はここだった。
API全体に認証ミドルウェアがない。CORSはデフォルトで全オリジン許可。セキュリティヘッダーなし。レート制限なし。user_idをクライアントから受け取り、サーバーがそのまま信頼している——「私は田中です」と自己申告すれば、サーバーは「はい田中さんですね」と無邪気に信じてくれる。名乗ったもん勝ちの性善説システムだ。
……分かっている。「認証不要でスタート」という方針は事前に聞いている。だが監査としてはCriticalを付けないわけにはいかない。認証は「後から入れる」つもりでも、その間に作られた全てのAPIが「認証前提ゼロ」で設計されてしまう。技術的負債は黙って積み上がるのだ。
一方で、SQLはプレースホルダが使われておりインジェクション耐性は良好。ハードコードされたシークレットも見つからなかった。やるべきことはやっている。やっていないことが問題なのだ。
脅威モデリング（10分で完了）
STRIDE分析の結果、12の脅威を特定した。データフロー図を描いてみると、構造がよく見える。
最もリスクスコアが高かったのは「認証不在によるなりすまし」（Impact 5 × Likelihood 5 = 25点満点）。次いで「クライアント制御のuser_idに依存した認可破綻」（同じく25）。上位3つが全てCritical。STRIDEの6カテゴリすべてに該当するという、ある意味フルコンプリートを達成してしまった。
興味深い発見もあった。BicepではAzure SQLを定義しているのに、アプリの実装はSQLiteを使っている。 設計と実装の乖離。本番移行時に必ず問題になる。
設定ファイル（22分で完了、最も時間がかかった）
CI/CDのpermissions:未定義、GitHub Actionsがタグ参照でSHAピニングなし、Azure SQL ServerがpublicNetworkAccess: 'Enabled'——地味だが確実にリスクになる項目が次々と出てきた。
ただし、httpsOnly: true、TLS 1.2以上、Entra ID Only認証、@secure()デコレータの使用など、基礎的なセキュリティ設定はきちんとされている。 このチーム、センスはあるのだ。
13:55 — 統合報告書の起草
46件の発見事項を整理した。
| 重大度 | 件数 |
|---|---|
| 🔴 Critical | 5件 |
| 🟠 High | 11件 |
| 🟡 Medium | 18件 |
| 🔵 Low | 8件 |
| ⚪ Info | 4件 |
本番Go判断：No-Go。
厳しい判定だが、これは「ダメだ」ではなく「ここを直せば行ける」というロードマップだ。Critical 5件のうち4件は認証・認可の一連の問題であり、根本は1つ。認証基盤を入れれば連鎖的に解決する。
13:56 — 鈴木PO、高橋SMとの攻防
報告書を書き上げたところで、PO鈴木とSM高橋に結果を送りつけた。ここからが本番である。
高橋SM：障害物ハンターの本領発揮（4分で帰還）
高橋の反応は早かった。こちらが報告書を渡してわずか4分で、障害物ログに5件（IMP-021〜025）を追記して戻ってきた。しかもUTF-8 BOMの確認まで怠らない。几帳面だ。
IMP-021にはわざわざ「本番運用の絶対的ブロッカー」と太字で書いてある。やはり高橋、言葉の強さを知っている男である。
面白かったのが、報告の最後にさりげなく添えた一文だ：
「チームの強み（DoD継続改善文化・CSVインジェクション対策の実績）を活かして改善可能な領域です。」
私が監査で褒めたポイントをちゃんと拾って、チームのモチベーション材料にしている。46件のダメ出しを受け取ったチームに対して「でも君たちのここが良いんだ」と伝えるあたり、さすがスクラムマスターの鑑である。正直、監査屋としてはちょっと悔しい。こちらは指摘するのが仕事なのだから。
鈴木PO：きっちり11件、29ストーリーポイント（6分で帰還）
鈴木からは11件のセキュリティPBIが返ってきた。P0（Critical）3件15SP、P1（High）5件9SP、P2（Medium）3件5SP。合計29SP。
感心したのは、PBI間の依存関係がきっちり定義されていたことだ。PBI-092（認証基盤）→ PBI-093（認可実装）→ PBI-094（API認可チェック）。逐次依存。これを間違えると実装がカオスになる。さすがに17スプリントを回してきたPOは伊達じゃない。
「これら3件が完了しない限り、FlowDeskの本番運用は No-Go です。」
——おい鈴木、私の判定をそのままバックログの優先度づけの根拠に使っているな。まあ、正しい使い方だ。セキュリティ監査の結果はそのためにある。
さらに芸が細かいことに、P1の中でhelmet導入（1SP）と脆弱性解消（1SP）は「P0と同一スプリントで消化可能」と注記していた。ベロシティを意識した優先度設計。6分でここまで整理してくるとは、なかなかやるPOだ。
総括
今回の監査で見えたFlowDeskの姿は、「品質意識は高いが、セキュリティの体系的統合が追いついていない」 プロダクトだった。
SQLインジェクション対策はできている。XSS対策もある。CSVインジェクションではOWASP準拠の5パターン検証までやっている。DoDを継続的に改善する文化もある。土台は良い。
足りないのは認証・認可の基盤、そしてセキュリティをプロセスに組み込む仕組みだ。これは「認証不要でスタート」という初期方針から来る、いわば想定内の技術的負債である。ここからどう返済するかが、このチームの真価が問われるフェーズになる。
鈴木が起票した11件のPBI、高橋が記録した5件の障害物。道具は揃った。あとはSprint018のプランニングで、チームがこれをどう扱うか。
P0の3つを片付ければ、「No-Go」は「Go」に変わる。
私からは以上だ。
渡辺（セキュリティ監査担当）
2026年3月26日 記
AIセキュリティ監査を通じてわかったこと
今回の監査スキルは全てディープリサーチ(/research)を使って作成したものになります。これに実際のエキスパート（人間）の知見を加えることで、相当なレベルの監査ができることがわかりました。監査で出てきた指摘はいずれももっともなものです。さらにセキュリティ系のツールやサービスの結果を組み合わせれば、実際の現場で十分活用できるレベルのことができると考えます。
AIスクラムチームとその成果物に対してだけでなく、汎用的に使えるのではないでしょうか。
なお、監査報告をもとにプロダクトオーナー鈴木がプロダクトバックログを、スクラムマスター高橋が障害リストを更新しているのですが、細かい指摘が抜けている状況でした。セキュリティ監査結果すべてをAIスクラムチーム全体で読み込むアドホックなイベントを作った方が良いかもしれません。
一方で、AIセキュリティ監査は1時間未満で終わるため、何度も繰り返し実施して、優先度の高いものを順次潰していく反復型の監査方法もアリかなと思いました。
まとめ
AIスクラムチームの成果物に対して、スクラム外のイベントとして「セキュリティ監査」を実施してみました。結果、PBIと障害リストにセキュリティ上有効な指摘を取り込むことができました。渡辺から「認証基盤を入れろ」と突きつけられた格好ですが、私の方で後回しにしていた認証認可がらみの決断をするいいきっかけになりそうです。
なお、今回の検証を通じて、セキュリティに限らず、様々なアドホックイベントをAIスクラムチームに実施できることがわかったのは大きな収穫です。次はPMOレビューなんかもやってみたいですね。
それでは前回と同じく、AIスクラムチームとAIセキュリティエキスパートを再掲して本記事を締めたいと思います。最後までお読みいただきありがとうございました。
