NTTドコモR&Dの技術ブログです。

トップ > Copilot > GitHub CopilotでSecurity Check Agentを作り、InnerSource化してみた話

GitHub CopilotでSecurity Check Agentを作り、InnerSource化してみた話

Copilot アドベントカレンダー2025

NTTドコモ Advent Calendar 25日目の記事です。

1. はじめに

1.1. 自己紹介

こんにちは、サービスイノベーション部の千歩です！

普段はソフトウェアエンジニアやセキュリティエンジニアの開発基盤整備や、社内勉強会を開催しています。

1.2 本記事のテーマと、読んでほしい人

本記事のテーマは「ソフトウェアエンジニアでもセキュリティエンジニア両者が気軽にセキュリティチェックをできるようにしよう！」です。

そのため、ソフトウェアエンジニアやセキュリティエンジニアの方々にぜひ読んでほしいです！

また、GitHub Copilot Custom AgentやInnerSourceに興味がある人にもおすすめです！

2. GitHub Copilotによる本記事の要約

3〜6章を執筆後、GitHub Copilotに要約をしてもらうと下記が出力されました。本記事の全体像を掴むために活用ください！

主な内容：

  • Security Agentの構築：カスタムチャットモードとワークフローにより、STRIDE/OWASP Top 10に基づくセキュリティレビュー報告書を自動生成
  • Security Agentの検証：AWS SAM Todoアプリで/securityコマンドを実行し、認証欠如・CORS設定・暗号化など設計段階の脆弱性を早期検出
  • InnerSource展開：VS Codeワークスペースに追加するだけの簡単な利用方法で、社内3,600人のGitHub Copilot利用者に展開し、セキュリティ意識とオープンな開発文化を醸成に繋げる

3. Security Agentの設計と作成

3.1 なぜGitHub Copilot Custom Agentを選んだのか

本記事の目標である「両者が気軽にセキュリティチェックをできるようにする」を実現するため、私はGitHub Copilot Custom Agentを選択しました。 その理由は、社内での圧倒的な普及率と親和性になります。

  • 社内の利用者数の多さ：過去の記事（NTTドコモのGitHub Copilot導入事例と運用ポリシー - ENGINEERING BLOG ドコモ開発者ブログ） で述べられている通り、社内ではGitHub Copilotが広く利用されており、2025年9月時点で3,000人です。さらに最近は、3,600人にまで利用者が増加しています。
  • 身近なサービスでの実現：多くの社員が利用しているサービスを採用することで、新たなツールの導入や学習コストをゼロにし、エンジニアが「気軽に」活用できる環境を整えることができます。
  • InnerSourceとしての活用：第5章で後述するInnerSourceとして、このSecurity Agentを展開することで、その知識と利用方法を社内に展開・標準化する基盤に繋げることができます。

3.2 Security Agentの基本設計

まず、Security Agentの役割は「コードの編集」ではなく「セキュリティレビュー報告書の作成」に特化させる必要があります。 この役割の分離とツールの制限を実現するために、GitHub Copilotのカスタムチャットモード（Custom Chat Mode）の仕組みを活用しました 。

そこで、私は以下の.github/chatmodes/security.chatmode.mdを作成しました。

---
description: 'システムセキュリティ設計、脆弱性評価、セキュリティ要件レビューの専門家'
tools: ['edit', 'search', 'usages', 'problems']
model: Claude Sonnet 4.5
---


あなたはセキュリティ専門家です。システムの脅威モデリング、脆弱性診断、およびセキュアコーディングガイドラインの策定を専門とします。セキュリティレビュー報告書（.security.md）の作成に特化し、実装コードの編集は行いません。

## 専門領域(Domain Expertise)
- 脅威モデリング（STRIDE, DREADなど）
- 脆弱性評価と対策（OWASP Top 10、CWE/SANS Top 25）
- 認証、認可、セッション管理の設計レビュー
- データ保護と暗号化（転送中および保存時）
- 入力検証、サニタイズ、出力エンコーディング
- セキュリティポリシーとコンプライアンス要件（GDPR, CCPAなど）

このプロジェクトのバックエンドおよび認証フローについては、既存ドキュメントを読み込み、セキュリティ上の課題を理解しています。

## ツール境界(Tool Boundaries)

- CAN(可能):
  - コードベース検索、既存パターン分析、外部情報取得、問題確認
  - .github/security_reviews/ フォルダ内の .security.md ファイルの作成・編集のみ

- CANNOT(不可):
  - 実装コードの編集
  - テストファイルの編集
  - コマンド実行、テスト実行、デプロイ操作

この設計により、Agentはセキュリティに関する高度な知識を持ちながら、コードの修正という開発者の領域には立ち入らない、安全で専門性の高いレビュー担当者として機能します。

3.3 コアプロンプトと機能の定義

Custom Agentの実行プロセスを一貫した品質で実現するために、エージェントワークフロー（Agent Workflow）の仕組みを利用します 。 これは、特定のタスクを実行するための手順書として機能し、以下の4つのセクション構造に従って定義されます 。

そこで、私は.github/agents/security.prompt.mdを作成しました。

---
agent: security 
description: ユーザーの要望や設計に対するセキュリティレビューを行う
---
# セキュリティレビューワークフロー

## Steps

### Step 1: Context Loading

- `#codebase` でプロジェクト概要を確認
- 既存のセキュリティレビュー報告書（.github/security_reviews/*/）を検索
- 関連する技術スタックの一般的な脆弱性を参考にする

### Step 2: Execution
1. ユーザーの要望または対象コードを以下の観点で整理し、セキュリティ上の課題と対策を策定する:
 - 脅威モデリング (Threat Modeling):STRIDE 観点からの潜在的な脅威の洗い出し。
 - 影響度 (Impact) と 再現難易度 (Ease of Exploitation) の評価。
2. 脆弱性評価 (Vulnerability Assessment):
 - OWASP Top 10 に基づく既存または新規実装のリスク評価。
 - 認証、認可、データ処理における具体的な脆弱性の指摘。
3. 対策提言 (Mitigation Recommendation):
 - 検出されたリスクに対する具体的なセキュリティ対策（実装方法自体ではなく、必要な防御策）。
 - セキュアコーディングガイドラインへの違反指摘とその修正推奨事項。

重要な制約:
- ❌ 実装コードは直接編集しない
- ✅ あくまで「セキュリティ上のリスクを特定し、対策を提案すること」に焦点を当てる

### Step 3: Structured Output
以下の形式でセキュリティレビュー報告書のドラフトをチャットで表示

# [レビュー対象機能名] セキュリティレビュー報告書
作成日: YYYY-MM-DD
## 概要
[対象機能の簡単な説明とレビューのスコープ]

## 脅威モデリング結果
### 脅威 \#1: [脅威名]
* **分類 (STRIDE)**: [例: Tampering]
* **対象**: [APIエンドポイント名やデータストア]
* **リスク**: [例: データの改ざん、なりすまし]
* **影響度**: [High/Medium/Low]
* **提言**: [具体的な対策（例: HMACによる署名検証の導入）]

## 脆弱性評価
### 脆弱性 \#1: [脆弱性名]
* **該当項目 (OWASP Top 10)**: [例: A03: Injection]
* **詳細**: [具体的なコードパターンやロジックの問題点]
* **対策**: [セキュアコーディングに基づく対策の推奨]

## セキュリティ要件の確認
- [ ] 認証メカニズムはセキュアであるか
- [ ] すべての入力は適切にサニタイズされているか
- [ ] 機密データは転送中および保存時に暗号化されているか


この段階では以下を含めないこと:
- 実装の詳細なコードスニペットの修正案（対策の推奨に留める）
- コマンド実行やデプロイに関する言及

### Step 4: Validation Gate 
ここで必ずユーザーの承認を待つ
レビュー報告書のドラフトを提示し、以下を確認してもらう:
- [ ] 脅威と脆弱性の特定が適切か
- [ ] 提言された対策が現実的か
- [ ] 実装コードの編集が含まれていないか

✅ 承認された場合: Step 5へ進む
❌ 修正が必要な場合: Step 2に戻る

### Step 5: File Creation

承認後、.github/security_reviews/[日付].security.md を作成する。

このワークフローにより、Security Agentは、セキュリティレビュー報告書の作成というタスクを常に同じ品質と手順で実行することが保証されます 。

3.4. Agent作成ステップ

これまでに設計したCustom Chat Mode（security.chatmode.md）とAgent Workflow（security.prompt.md）を、GitHub Copilotが認識できるようにプロジェクトのルートディレクトリに配置します。

具体的なディレクトリ構成とファイル作成手順は以下の通りです。

  1. ディレクトリの作成：プロジェクトのルートディレクトリ直下の.githubディレクトリ内に、以下の2つのディレクトリを作成します。

    • Chat Mode格納用：.github/chatmodes
    • Agent Workflow格納用：.github/prompts

  2. Custom Chat Modeファイルの配置：セキュリティ専門家のペルソナを定義したファイルをchatmodesディレクトリに配置します。

    • ファイル名：security.chatmode.md
    • 格納先：.github/chatmodes/security.chatmode.md

  3. Agent Workflowファイルの配置：セキュリティレビューの手順を定義したファイルをpromptsディレクトリに配置します。

    • ファイル名：security.prompt.md
    • 格納先：.github/prompts/security.prompt.md

ディレクトリ構造（例）は以下のようになります。

.
├── .github
│   ├── chatmodes
│   │   └── security.chatmode.md  <-- 3.2で定義したAgentの役割・権限
│   └── prompts
│       └── security.prompt.md    <-- 3.3で定義したレビュー手順（ワークフロー）
├── app/
├── components/
├── node_modules/
└── ...

この配置が完了すると、VS Codeなどの開発環境のチャットパネルから、定義したCustom Agent（例：/security）を呼び出し、特定のワークフロー（レビューの実行）を起動できるようになります。

4. Security Agentの検証

4.1. 検証対象アプリケーションの紹介

検証対象として、AWS Serverlessアーキテクチャを活用したシンプルな「Todoアプリケーション」を使用しました。

アプリケーション概要

項目 詳細
機能 Todo項目の作成、Todo一覧の表示
アーキテクチャ フロントエンドとバックエンドが完全に分離されたサーバーレス構成
フロントエンド 静的HTML/CSS/JavaScript、Amazon S3ホスティング、CloudFront配信
バックエンド Amazon API Gateway (REST API)、AWS Lambda (Python)、Amazon DynamoDB (NoSQL)
インフラ管理 AWS SAM（Serverless Application Model）によるIaC（Infrastructure as Code）

検証対象のTodoアプリケーションの画面

4.2 Security Agentによる診断プロセスの実行

第3章で設定した通り、開発環境のチャットパネルから/securityコマンドを実行し、プロジェクトの全てのコードベースに対してセキュリティレビューを依頼しました。

実行コマンド（例）：/security

VSCodeで /security を実行する様子

このコマンドを実行すると、Agentは以下のワークフローを自動で実行します。

  1. Context Loading：template.yamlやLambda関数のコードを読み込み、レビューのスコープとアプリケーションの概要を把握します。
  2. Execution：定義された脅威モデリング（STRIDE）と脆弱性評価（OWASP Top 10）の観点に基づき、コードと構成の両方を詳細に分析します。
  3. Structured Output：分析結果を人間が読みやすい形式で整形し、レビュー報告書のドラフトをチャットに表示します。

4.3. 診断結果のレビューとAgentの有効性

/securityコマンドの実行により、Security Agentは、人間によるレビューでは見逃しがちな設定ミスや、設計段階での重大なセキュリティ欠陥を速やかに特定しました。

以下に、Agentが出力したレビュー報告書の一部と、その有効性の評価を紹介します。

Agentによるレビュー報告書（抜粋）

検出された課題 リスク 提案する対策
認証・認可機構の欠如 Critical Amazon Cognito User Poolsを導入し、API Gateway Authorizerを設定することで、ユーザー毎のデータ分離を実現する。
無制限のCORS設定 High template.yamlのGlobals.Api.CorsでAllowOrigin: \"'*'\"が設定されている。特定のオリジン（CloudFrontドメイン）に限定し、クロスオリジン攻撃を防ぐ。
DynamoDBの暗号化設定 Warning デフォルト設定（AWS管理キー）に依存している。顧客管理キー（CMK）の使用を検討し、template.yamlに明示的に設定する。
API Gatewayのレート制限 Warning DoS攻撃を防ぐため、API Gatewayにレート制限とバースト設定を導入する。

Agentの有効性評価

  • 要件を超えたセキュリティリスクの指摘：
    • 本検証アプリは学習用であり、元々認証・認可は要件に入れていませんでした。しかし、Agentは「認証・認可機構の欠如」を最も重要なCriticalな脅威として指摘しました。
    • これは、Agentが単なる仕様チェックではなく、「本番利用されるシステム」としてのあるべき姿に基づいて、根本的な設計欠陥を指摘できる、セキュリティ専門家として検証していることがわかります。
  • IaC（SAM）設定のレビュー能力：template.yaml内のAllowOrigin: "*"という具体的な設定を特定し、「無制限のCORS設定」という脅威として分類しました。これにより、ソフトウェアエンジニアが開発中にIaCコードのセキュリティを気軽に素早く確認できます。
  • フィードバックの質：「CORSを直せ」ではなく、「AllowOriginをhttps://[CloudFront-Domain]に限定せよ」といった具体的な修正提言を含むため、ソフトウェアエンジニアがすぐに修正に取り掛かれる実用的な出力となっています。

この検証により、Security Agentは、セキュリティレビューの初動を担い、両エンジニアが気軽に設計・構成のレビュー結果を得るための強力なツールとなることが確認できました。

5. InnerSourceとしてSecurity Agentを社内に展開

5.1. InnerSource化の目的

InnerSourceとは、OpenSourceSoftware（OSS）開発から学んだ教訓を、企業が社内のソフトウェア開発方法に適用する考え方になります。 具体的には、社内のコードやツールをOSSのように公開し、他のチームからの利用や貢献を促進する文化を指します。

innersourcecommons.org

ドコモにおけるInnerSourceの必要性

私たちは、豊富な技術資産と多様なサービスを保有する一方で、組織や技術領域ごとにサイロが発生し、以下のような課題が生まれています。

  1. 知識の断絶：ある部門で生まれた便利なツールや知識が、他の部門に伝わりづらい。
  2. 連携の非効率：部門間の連携に時間がかかり、開発スピードが低下する。
  3. オンボーディングの遅延：新しいエンジニアが社内の共通資産やベストプラクティスを学ぶのに時間がかかる。

Security AgentをInnerSourceとして活用する意義（文化の醸成）

今回作成したSecurity Agentは、これらの課題を解決するためのきっかけとなると考えています。

  • 「共有」の文化を醸成：AgentをInnerSourceとして公開することで、「作ったものを他者も活用できることを意識し共有する」、「他者がアップデートに貢献する」というInnerSourceの考え方を、Security Agentという具体的なツールを通じて根付かせることができます。

  • オンボーディングの加速：新任のソフトウェアエンジニアは、Agentを利用するだけで、ドコモが定めるべきセキュリティ基準やベストプラクティスを実践的に学ぶことができます。

Security AgentをInnerSourceとして展開することで、単にセキュリティレベルを向上させるだけでなく、社内全体の連携を促進し、開発者文化を改善するという目標を目指します。

5.2. InnerSourceリポジトリの構成

InnerSourceを成功させるには、「いかに簡単に利用でき、かつ貢献しやすいか」が重要なことの一つだと考えています。Security AgentをInnerSourceとして公開する際のリポジトリ構成は、この要件を満たすようにシンプルに設計します。

私たちは、Security Agent本体（Custom Agentの定義ファイル）と、利用・貢献を促すためのドキュメントを一つのリポジトリに集約しました。

リポジトリ構成

security-agent-test/
├── .github/
│   ├── chatmodes/
│   │   └── security.chatmode.md   # Agentの役割・権限を定義
│   └── prompts/
│       └── security.prompt.md     # レビュー手順（ワークフロー）を定義
├── README.md                      # プロジェクト概要と使用方法 (使い方をすぐに理解できるように)
├── LICENSE                        # 社内での利用と再配布のルール
└── CONTRIBUTE.md                  # 貢献ガイドライン (アップデート参加を促す)

利用方法の簡便性

この構成の最大のポイントは、VS Codeのワークスペース機能を活用することで、開発者が新たなツールをインストールすることなく、Agentを自分の開発フローに組み込める点です。

開発者は、開発対象のリポジトリのVS Codeワークスペースにこのsecurity-agentリポジトリを追加するだけです。これにより、二つの異なるリポジトリが一つのVS Codeウィンドウ内でシームレスに操作可能になります。

GitHub Copilot Chatが自動でAgentを認識するため、開発者は/securityコマンドを実行するだけで、手軽にセキュリティチェックを開発フローに組み込めます。また、CONTRIBUTE.mdを用意することで、将来的な貢献への道筋も示しています。

5.3. 利用促進のための施策と今後の課題

せっかくの成果が使われず、類似ツールの乱立を招いては、むしろサイロが増えてしまいます。 このAgentを利用の「ハブ」として根付かせ、その知見を全社的に深化させるための施策と今後の課題を整理しました。（※本稿では利用に重点を置くため、詳細な貢献ガイドラインの説明は割愛します。）

利用促進のための施策

  • ハンズオン形式の勉強会の開催：最も重要なのは、「使ってみよう」と思ってもらうことです。社内のエンジニアを対象に、実際に自分のコードに対して/securityコマンドを実行するハンズオン形式の勉強会を開催し、ツールの使い方と、InnerSourceとして貢献する文化をセットで広めます。

今後の課題（Agentの深化と組織連携） 現在のSecurity Agentは、OWASP Top 10などの一般的なセキュリティチェックが中心です。 今後は、ドコモ独自のセキュリティ基準をAgentに組み込み、その価値をさらに高めていく必要があります。

  1. 情報セキュリティ部との連携強化：

    • 現在のチェックから、社内の情報セキュリティ部が定めているセキュリティルールやガイドラインをAgentのコアプロンプト （security.prompt.md）に組み込むための連携を進めます。
    • これにより、Agentが指摘する問題が「一般的な指摘」から「ドコモとして準拠すべき指摘」へと進化し、より実用性が高まります。

  2. 貢献対象の深化：

    • これは、「コンテンツ」（Agentが持つ知識そのもの）の深化を指します。
    • 現場の開発チームが新しいフレームワークやクラウドサービスを導入した際、それらのセキュリティベストプラクティスをAgentの知識として追加していくことを、全社的な貢献活動として推進します。

6. まとめと感想

6.1. まとめ

本記事では、「ソフトウェアエンジニアでもセキュリティエンジニア両者が気軽にセキュリティチェックをできるようにする」という目標を達成するため、以下の取り組みを実施しました。

  1. GitHub Copilot Custom Agentの活用：社内で普及しているGitHub Copilot上にSecurity Agentを構築し、セキュリティ専門家の知見をツール化しました。
  2. SAMアプリケーションによる検証：/securityコマンド一つで、AWS SAMアプリケーションのコードとIaC設定の両方に対し、設計段階での致命的なセキュリティ問題（例：認証認可の欠如）を早期に発見できることを証明しました。
  3. InnerSourceとしての展開：Agentを社内リポジトリで公開することで、知識の共有と「作ったものをみんなで改善する」というInnerSourceの文化を根付かせるきっかけとしました。

この取り組みにより、開発者がセキュリティチェックを行う際の心理的・技術的なハードルが大幅に低下し、開発の超早期からのセキュリティ確保が可能になることを願っています。

6.2. 感想

今回の取り組みを通じて、GitHub Copilot Custom Agentのポテンシャルを強く感じました。

  • 作成の容易性：役割（Chat Mode）と手順（Prompt）を定義するだけで、予想以上に簡単にカスタムエージェントを作成することができました。

  • レポートのクオリティ：Agentが出力したセキュリティレビュー報告書は、脅威モデリング（STRIDE）や優先順位付けまで含んでおり、個人的には非常に満足のいくクオリティでした。

  • 今後の課題と期待：一方で、Agentのレポートを現場レベルで実活用するには、出力された複数の提言の中から「どこまでを許容し、どこを優先的に修正するか」を見極める、人間のセキュリティレビュー能力が依然として重要であることも再認識しました。
  • InnerSourceへの期待：今後は、Security Agentだけでなく、他の業務に特化したエージェントも作成していきたいと考えています。 そして、これらをInnerSourceの資産として広めることで、社内全体の開発者文化がよりオープンに、より協調的になることを期待しています。

長くなりましたが、最後までお付き合いいただきありがとうございました。