システム基盤構築やセキュリティ対策の現場では、「あの時、たった一行のコードチェックがあれば」と悔やまれるインシデントが後を絶ちません。
開発スピードが求められる現代において、すべてのコードをセキュリティ専門家がレビューするのは現実的ではありません。しかし、脆弱（ぜいじゃく）性は待ってくれません。そこで今、強力な味方となるのがGitHub Copilot ChatのようなAIコーディング支援ツールです。
多くの開発者はCopilotを「コードを書くスピードを上げるツール」として使っていますが、実は「専属のセキュリティアドバイザー」としても極めて優秀であることをご存じでしょうか。
この記事では、セキュリティの専門家ではないアプリケーション開発者の皆さんが、AIと対話しながらコードの安全性を高めるための具体的な手法を紹介します。単にツールに任せるのではなく、AIを「ペアプログラマー」として扱い、共に脆弱性を探し、修正し、学ぶための実践的なプロンプト（指示出し）の技術です。
今日から使える具体的なテンプレートを用意しました。さあ、あなたのIDE（統合開発環境）に、頼れるセキュリティ担当を呼び出してみましょう。
なぜAIとの対話がセキュリティ学習に最適なのか
従来のセキュリティ対策といえば、静的解析ツール（SAST）を導入し、大量のアラートに対処するのが一般的でした。しかし、これには大きな課題があります。ツールは「ここがダメ」とは指摘してくれますが、「なぜダメなのか」「どう直せば文脈に沿った修正になるのか」までは、文脈を汲み取って教えてくれるわけではありません。
ここで、GitHub Copilot Chatのような対話型AIの真価が発揮されます。特に最新の機能セットは、単なるコード補完を超え、セキュリティのパートナーとしての役割を強めています。
静的解析ツール(SAST)とAIチャットの違い
静的解析ツールは、事前に定義されたルールに基づいてコードを機械的にスキャンします。これは網羅的なチェックには向いていますが、誤検知（False Positive）も多く、開発者のモチベーションを下げてしまうことが珍しくありません。
一方、Copilot Chatはコードの文脈（コンテキスト）を理解します。特に@workspaceコマンドを使用することで、現在開いているファイルだけでなく、リポジトリ全体をスキャン対象とし、変数の命名意図や、その関数がシステム全体でどのような役割を果たしているかを踏まえた上でリスクを指摘できます。
たとえば、「この入力値検証は、プロジェクト内のutils/validator.tsで定義された共通ルールに準拠していますか？」といった、プロジェクト固有の文脈に依存する判断を対話の中でクリアにしていける点は、AIならではの強みです。
「修正」だけでなく「理由」を学ぶ教育的価値
インシデント対応の事後分析において専門家が重視するのは、「誰が書いたか」ではなく「なぜその脆弱性が混入したか」という根本原因です。知識不足が原因であれば、それを埋める必要があります。
AIに修正を依頼する際、「なぜこの修正が必要なのか解説して」と付け加えるだけで、Copilotは優れたセキュリティ講師に早変わりします。SQLインジェクションのリスクや、クロスサイトスクリプティング（XSS）の仕組みを、あなたの書いたコードを教材にして説明してくれるのです。これは、一般的な技術書を読むよりもはるかに高い学習効果をもたらします。
開発フローに組み込む「ひとりセキュリティ診断」のメリット
セキュリティ対策を開発プロセスの後半で行うと、手戻りのコストが膨大になります。これがいわゆる「シフトレフト（工程の前倒し）」が必要とされる理由です。
Copilot Chatや、最新の「Copilot Edits（編集機能）」を使えば、コードを書いたその瞬間に「ひとりセキュリティ診断」が可能になります。エディタ内でAgent Modeのような自律的な修正支援を活用し、プルリクエスト（PR）を出す前に自分自身でAIと壁打ちを行って基本的な脆弱性を潰しておく。これにより、テックリードやセキュリティチームによるレビューの負担を減らし、より本質的な設計レビューに時間を割けるようになります。
準備編：診断精度を高めるコンテキスト設定
AIは優秀ですが、エスパーではありません。何も情報を与えずに「このコードは安全？」と聞いても、一般的な回答しか返ってきません。精度の高い診断を引き出すには、適切なコンテキスト（前提知識）を与えることが不可欠です。
ワークスペースと開いているファイルの関係
GitHub Copilot Chatには、現在開いているファイルやプロジェクト全体を認識させるためのコマンドがあります。特に重要なのが @workspace です。
単一のファイルだけでなく、プロジェクト全体の構造や依存関係を踏まえて診断してほしい場合は、必ずこのコマンドを使いましょう。たとえば、認証ロジックが別のファイルに定義されている場合、それを含めて判断させる必要があります。
カスタム指示によるコンテキストの永続化（推奨）
最新のGitHub Copilotでは、毎回プロンプトを入力する手間を省き、プロジェクト全体で統一された振る舞いを定義する機能が強化されています。特に有効なのが、リポジトリ内に .github/copilot-instructions.md ファイルを配置する方法です。
プロジェクトのルートディレクトリにこのファイルを作成し、セキュリティ要件や役割定義を記述しておくと、Copilotは自動的にその内容をコンテキストとして読み込みます。これにより、チーム全体でセキュリティ基準を統一し、診断の質を底上げすることが可能です。
【copilot-instructions.md の記述例】
# Security Guidelines
あなたは経験豊富なシニア・セキュリティエンジニアとして振る舞ってください。
コードを提案または診断する際は、常にOWASP Top 10を考慮し、セキュアな実装を優先してください。
# Tech Stack
- Language: TypeScript (Latest)
- Framework: Next.js (App Router)
- DB: PostgreSQL
- ORM: Prisma
役割の付与（Role Prompting）と技術スタックの明示
カスタム指示ファイルを使用しない場合や、特定のセッションで一時的に役割を強調したい場合は、会話の冒頭で明確な指示を与えます。
プロンプトエンジニアリングの基本ですが、AIに「誰として振る舞ってほしいか」を明確に指示することで、回答の質が向上します。セキュリティ診断の場合は、以下のようなプロンプトが有効です。
【基本設定プロンプト例】
あなたは経験豊富なシニア・セキュリティエンジニアであり、OWASP Top 10などの国際的なセキュリティ基準に精通しています。
@workspace 私のコードに対して、攻撃者の視点から厳しく脆弱性を診断し、安全な実装方法を指導してください。
回答は具体的で、かつ開発者が理解しやすいように根拠を示して説明してください。
また、言語やフレームワークのバージョンによって、推奨されるセキュリティ対策は異なります。例えば、Reactのレガシーバージョンと最新モデルでは、XSS対策の仕組みが違うことがあります。
そのため、環境情報を明示的に伝えておくことが重要です。
現在、以下の環境で開発しています。
- 言語: TypeScript
- フレームワーク: Next.js (App Router使用)
- DB: PostgreSQL
- ORM: Prisma
この環境特有のセキュリティベストプラクティスに基づいてアドバイスしてください。
これで準備は整いました。次からはいよいよ、実践的な診断ステップに入ります。
Step 1：潜在的な脆弱性をあぶり出す「診断プロンプト」
まず行うべきは、現状のコードに潜むリスクの可視化です。ここでは、AIに対して「攻撃者の視点」を持たせることで、見落としがちな穴を見つけ出します。
OWASP Top 10を基準にした網羅的チェック
漠然と「バグはない？」と聞くのではなく、具体的な基準を示してチェックを依頼します。以下のプロンプトは、Webアプリケーション開発で最も汎用性が高いものです。
【診断プロンプト A：全体スキャン】
@workspace /explain
現在選択しているコードブロックについて、OWASP Top 10の観点からセキュリティ上の脆弱性がないか診断してください。
特に以下の点に注目してください：
1. インジェクション攻撃（SQL, OSコマンド等）のリスク
2. 認証・認可の不備
3. 機密情報のハードコーディング
4. エラーハンドリングによる情報漏洩
脆弱性が見つかった場合は、その危険度（高・中・低）と、悪用された場合の具体的な被害シナリオを提示してください。
このプロンプトのポイントは、「悪用された場合のシナリオ」を求めている点です。単に「脆弱性があります」と言われるより、「このままだとデータベースの中身がすべて盗まれる可能性があります」と言われた方が、修正の優先度が明確になります。
特定の攻撃シナリオ（SQLi, XSS）を想定した質問法
特定の機能（例えば検索フォームやログイン画面）を実装している場合は、より具体的な攻撃手法を指定して診断させます。
【診断プロンプト B：入力処理重点】
この関数はユーザーからの入力を受け取ってデータベースクエリを実行しています。
SQLインジェクションの脆弱性はありますか？
入力値に `' OR '1'='1` のような悪意ある文字列が含まれた場合、このコードはどう動作しますか？
シミュレーション結果を教えてください。
このように具体的な攻撃コード（ペイロード）を例示して質問することで、AIはより正確にコードの挙動をトレースしてくれます。
ビジネスロジックの抜け穴を探す対話術
技術的なバグだけでなく、仕様上の欠陥（ビジネスロジックの脆弱性）も重大なリスクです。たとえば、「他人の注文履歴が見えてしまう」「在庫がマイナスになっても購入できる」といった問題です。
【診断プロンプト C：ロジック診断】
このコードの認可ロジックを見てください。
正規のユーザーであっても、URLのパラメータ（IDなど）を改ざんすることで、本来アクセス権限のないデータ（他人のデータなど）を閲覧・操作できてしまう可能性はありますか？
IDOR（安全でない直接オブジェクト参照）の観点でチェックしてください。
これらのプロンプトを使い分けることで、表面的な構文エラーだけでなく、設計レベルの脆弱性まであぶり出すことができます。
Step 2：堅牢なコードへ書き換える「修正・生成プロンプト」
脆弱性が見つかったら、次は修正です。しかし、AIに「直して」とだけ言うのは危険です。元のロジックを壊したり、別のバグを埋め込んだりする可能性があるからです。
修正案と解説をセットで出力させる
修正コードを受け入れる前に、その修正が「なぜ安全なのか」を理解する必要があります。
【修正プロンプト A：解説付き修正】
先ほど指摘されたSQLインジェクションの脆弱性を修正するコードを提示してください。
要件:
1. プリペアドステートメント（またはパラメータ化クエリ）を使用すること。
2. 修正前と修正後のコードを比較し、なぜ修正後のコードが安全なのかを技術的に解説すること。
3. コードの可読性を維持し、既存の命名規則に従うこと。
このプロンプトを使えば、単なるコピペではなく、技術的な裏付けを得た上でコードを適用できます。
既存のコーディング規約に準拠させる指示
チーム開発では、セキュリティと同じくらい「コードの統一感」も大切です。AIが生成するコードが独特な書き方だと、後のメンテナンスが大変になります。
【修正プロンプト B：スタイル維持】
@workspace
プロジェクト内の他のファイル（例: `utils/db.ts`）の実装パターンを参考にして、この脆弱性を修正してください。
独自のエラー処理は追加せず、プロジェクト標準の `AppError` クラスを使用してください。
@workspace を活用して既存コードを読み込ませることで、まるでチームメンバーが書いたかのような自然な修正コードが得られます。
エッジケース（境界値）の処理を追加する
セキュリティホールは、想定外の入力（空文字、極端に長い文字列、特殊文字など）で発生しがちです。サニタイズ処理の実装を依頼する際は、こうしたエッジケースへの対応も明示します。
【修正プロンプト C：堅牢化】
入力値の検証（バリデーション）ロジックを追加してください。
以下のケースを考慮すること：
- 入力が空、またはnullの場合
- 入力が想定以上の長さの場合（バッファオーバーフロー対策）
- 絵文字や制御文字が含まれる場合
検証ライブラリとして `Zod` を使用して実装してください。
Step 3：修正後の安全性を確認する「検証プロンプト」
コードを修正して終わりではありません。「本当にこれで直ったのか？」を確認するまでが、実務に即したセキュリティ対策の基本です。ここでもAIの力を借ります。
修正コードに対する再診断の実施
AIが生成した修正案を、あえてAI自身に再度診断させます。これを「再帰的チェック」と呼びます。
【検証プロンプト A：ダブルチェック】
提示された修正コードを適用しました。
この新しいコードに対して、もう一度攻撃者の視点で脆弱性診断を行ってください。
まだ見落としているリスクや、この修正によって新たに生まれた副作用はありますか？
AIは確率的に回答を生成するため、一度目で完璧な回答が出るとは限りません。視点を変えて再質問することで、精度を高めることができます。
単体テストコードの生成と実行
セキュリティ対策が正しく機能しているかを永続的に保証するために、テストコードを作成します。
【検証プロンプト B：テスト生成】
このセキュリティ修正が正しく機能していることを確認するための単体テストコード（Jest）を作成してください。
正常系のテストだけでなく、以下の異常系テストケースを必ず含めてください：
1. SQLインジェクション攻撃文字列を入力した場合
2. 許容範囲外の巨大なデータを入力した場合
3. 不正な形式のデータを入力した場合
期待される動作は「適切にエラーがハンドリングされ、システムがクラッシュしないこと」です。
こうして生成されたテストコードをCI/CDパイプラインに組み込めば、将来的なリグレッション（改修による先祖返り）も防ぐことができます。
攻撃シナリオを用いた仮想的なペネトレーションテスト
最後に、思考実験としてAIに「侵入テスト」を行わせます。
【検証プロンプト C：仮想攻撃】
あなたは優秀なホワイトハッカーです。
修正後のこのコードを突破して、不正アクセスを試みてください。
どのような手法であれば突破できる可能性がありますか？
もし「突破不可能」であれば、その理由を論理的に説明してください。
AIに「突破できない理由」を語らせることで、実装に対する自信と根拠を持つことができます。
注意点：AIの限界と人間の責任
ここまでAI活用のメリットをお伝えしてきましたが、セキュリティや基盤構築の専門的観点から、最後に重要な点を強調しておきます。AIはあくまで強力な「支援ツール」であり、最終的なセキュリティ担保の責任は人間にあります。
ハルシネーション（もっともらしい嘘）のリスク
GitHub Copilot Chatを含む生成AIは非常に流暢に回答を生成しますが、実在しないライブラリや関数を提案したり、一見正しく見えてもセキュリティ的に脆弱なコードを自信満々に提示したりすることがあります（ハルシネーション）。
対策:
提示されたコードや解説は、必ず公式ドキュメントや信頼できるソースで裏付けを取る習慣をつけてください。また、AIモデルは頻繁に更新されます。利用可能なモデルやその挙動は変更される可能性があるため、常に最新の公式ドキュメントを参照することが重要です。「AIが安全と言ったから」という理由は、インシデント発生時の説明として通用しません。
機密情報の取り扱いとフィルタリング設定
プロンプトの中に、本番環境のAPIキー、パスワード、顧客のPII（個人識別情報）などの機密データを直接貼り付けることは避けるべきです。GitHub Copilot BusinessやEnterpriseプランでは、入力データが学習に利用されない設定が可能ですが、セキュリティの基本原則として「チャット欄に機密情報を入力しない」というルールを徹底することを推奨します。
最終的なコードレビューの重要性
AIによる簡易診断は、専門的なセキュリティ監査や人間の専門家によるレビューを完全に代替するものではありません。
特に推奨されるのは、GitHub Advanced Security (GHAS) などの専用セキュリティツールとの併用です。CodeQLのようなSAST（静的アプリケーションセキュリティテスト）ツールで網羅的に脆弱性をスキャンし、検出されたアラートの解釈や修正案の作成にCopilot Chatを活用する。この「専用ツールの網羅性」と「AIの解説力」を組み合わせたハイブリッドなアプローチこそが、現代の開発現場における堅牢な防御策となります。
セキュリティ対策は、もはや一部の専門家だけのものではありません。GitHub Copilot Chatという強力なパートナーを得た今、すべての開発者が「セキュアなコード」を書くための強力な武器を手にしています。
まずは手元のコードブロックを一つ選び、今回紹介したプロンプトを試してみてください。AIとの対話を通じて、コードに潜むリスクを可視化し、より強固な実装へと昇華させるプロセスを体験できるはずです。
さらに高度なセキュリティ機能や、組織全体でのガバナンス強化が必要な場合は、GitHub Advanced Securityなどの導入も検討に値します。安全な開発ライフサイクルを、確かな知識とツールで築き上げていきましょう。
コメント