AIプロジェクトの最前線において、共通して直面する課題があります。それは、「レガシーコードをAIに触らせることへの懸念」です。
「AIに社内のソースコードを学習されたくない」
「AIが生成したコードに脆弱性が含まれていないか」
「古いコードに埋め込まれた情報が流出するのではないか」
テックリードやVPoE、セキュリティ責任者であれば、このような懸念を持つことは当然です。AIは強力なツールですが、適切なガバナンスが不可欠です。
しかし、リスクを恐れてAIの導入を避けることは、ビジネス上の大きな機会損失につながります。特に、技術的負債が蓄積したレガシーシステムの刷新において、GitHub Copilot ChatのようなAIアシスタントは、モダナイゼーションを加速させる重要なツールとなりつつあります。
本記事では、AIリファクタリングにおけるセキュリティリスクを分析し、組織的に制御するための「ガードレール（防護柵）」の設計方法を解説します。GitHub Enterpriseの設定項目、開発者が使うべきプロンプトのテンプレート、DevSecOpsに組み込むべき検証フローなど、経営と現場の両視点から実務に即した内容をお届けします。
リスクを適切に管理し、AI駆動開発を安全かつスピーディーに進めるための実践的なノウハウを共有しましょう。
なぜ「レガシーコード×AI」がセキュリティの課題となるのか
AIによるコーディング支援にはリスクが存在しますが、対象が「レガシーコード」である場合、そのリスクはさらに高まります。レガシーコード自体が潜在的なセキュリティ課題を抱えていることが多く、AIがその問題を意図せず顕在化させる可能性があるからです。
ここでは、AIリファクタリング特有のリスク構造を整理し、実践的な対策を検討します。
ブラックボックス化したコードをAIに読ませるリスク
長年運用されてきたレガシーコードには、過去の慣習や応急処置が残っていることがあります。特に危険なのが、ハードコードされた機密情報です。
AWSのアクセスキー、データベースの接続パスワード、社内APIのトークンなどが、ソースコードの中に直接記述されているケースが見られます。人間であれば見過ごすか、問題として認識できる情報でも、AIモデルに読み込ませた場合、予期せぬリスクが生じる可能性があります。
Copilot Chatは、開いているファイルや関連ファイルをコンテキストとして読み込み、回答を生成します。もし、ハードコードされた認証情報を含むファイルをコンテキストとして送信した場合、そのデータは外部サーバーで処理される可能性があります。エンタープライズ版では学習データとして利用されない設定が可能ですが、リスクを根本から絶つためには、「そもそも送らない」仕組みを作ることが重要です。
また、複雑なロジックをAIに解説させようとした際、AIがそのロジックの「脆弱性」までをも忠実に再現したコードを提案する可能性もあります。AIは「動くコード」を素早く作ることは得意ですが、「安全なコード」を作る倫理観をデフォルトで持っているわけではありません。
AIが提案する「もっともらしいが脆弱なコード」のリスク
AIハルシネーション（幻覚）という現象が知られていますが、コーディングにおいて真に問題となるのは、「一見正しく動作し、構文エラーもないが、セキュリティホールが空いているコード」が生成されることです。
例えば、レガシーなSQLクエリをリファクタリングするよう依頼した際、AIが最新のORM（Object-Relational Mapping）を使わず、文字列連結によるSQLインジェクション脆弱性を含んだコードを生成することがあります。元のレガシーコードがそのような書き方をしている場合、AIは脆弱なパターンを踏襲してしまうことがあるのです。
さらに、存在しないライブラリや、タイプスクワッティング（正規のライブラリ名に似せた悪意あるパッケージ）をimportするコードを提案するリスクも指摘されています。開発者がコードレビューを疎かにすると、これらの脆弱性がプロダクション環境に移行する危険性があります。
企業が懸念するリスク：学習データとバックドア
企業がAI導入を躊躇する理由として、以下のような点が挙げられます。
- 自社の知的財産（IP）の流出: 自社のアルゴリズムやビジネスロジックが、AIモデルの再学習に使われ、競合他社がCopilotを使った際に類似のコードが出力されるのではないかという懸念。
- サプライチェーン攻撃的なバックドア混入: AIが生成したコードに、攻撃者が意図的に仕込んだ脆弱性パターンが含まれており、システム全体が危険に晒されるリスク。
これらは、単なる技術的な問題にとどまらず、企業の存続に関わる重大な経営リスクです。したがって、現場のエンジニアの注意力に依存するのではなく、組織としてのガバナンス、つまり「仕組みによる防御」を構築することが不可欠です。
第1の防壁：データプライバシー設定と環境隔離
具体的な防御策として、まずはプラットフォーム側の設定を強固に固めます。GitHub Copilotには、企業利用を前提とした堅牢な管理機能が備わっています。これらを正しく設定することは、レガシーコード刷新プロジェクトにおける「安全地帯」を確保するための第一歩です。
GitHub Enterpriseにおける「学習データ利用」の完全オプトアウト設定
企業導入において最も重要なのは、GitHub Copilot Business または Copilot Enterprise プランを利用することです。
個人向けの「Copilot Free」や「Copilot Individual」プランでは、ユーザーの利用データやコードスニペットがAIの学習に活用される可能性がありますが、ビジネスプランではこれがデフォルトで無効化されています。組織の資産であるソースコードを守るため、企業契約のアカウントを使用することは絶対条件と言えます。
念のため、以下の設定が正しく構成されているか確認してください。
- 設定箇所: GitHub Organization Settings > Copilot > Policies
- 確認項目:
User data usage（ユーザーデータの利用）またはそれに準ずる項目
ここで、「Allow GitHub to use my code snippets for product improvements」（製品改善のためにコードスニペットの使用を許可する）という項目が Disabled（無効） になっていることを確認します。これにより、チームが書いたコードや、Copilot Chatに入力したプロンプトが、AIモデルの再学習に使われることを技術的に防ぎます。
ポリシー管理機能（Policy Management）による制御
次に、Copilotの挙動を組織のコンプライアンス基準に合わせて制御します。特に注意すべきは、Public Code Suggestions（パブリックコードの一致提案） の扱いです。
Copilotは、GitHub上の公開コードと一致するコードを提案する能力を持っています。しかし、これはオープンソースライセンス（GPLなど）のリスクを組織内に持ち込む可能性があります。
- 推奨設定:
Suggestions matching public codeを Block（ブロック） に設定する。
これをブロックに設定すると、Copilotは公開コードと約150文字以上一致する提案を行わなくなります。レガシーシステムのモダナイズでは、既存の社内ロジックをベースに改修することが主目的であり、外部コードをそのまま流用する必要性は低いため、法的リスクを排除する設定を推奨します。
また、Content Exclusion（コンテンツ除外） 機能の設定は、最新のCopilot機能を使う上で極めて重要です。@workspace コマンドやAgent Mode（エージェントモード）といった機能は、リポジトリ全体や複数のファイルを自律的に参照して回答を生成します。これらは非常に強力ですが、同時に機密情報へのアクセスリスクも高まります。
機密性の高い設定ファイル（.envなど）や、古いハードコードされた認証情報を含むディレクトリを「除外対象」として明示的に指定することで、Copilotがそれらをコンテキストとして読み込むことを技術的に遮断できます。
さらに、Copilot Enterpriseでは、マルチモデル対応（Claudeの最新モデルやGeminiの最新版などへの切り替え）が進んでいますが、GitHub経由で利用する限り、これらのモデルを選択しても企業のプライバシーポリシー（学習利用の禁止）が適用される点は安心材料と言えるでしょう。
IP許可リストとSAML SSOによるアクセス境界の強化
Copilot ChatはVS CodeなどのIDEから利用しますが、そのIDEが接続しているネットワーク環境や認証状態もセキュリティの一部です。
GitHub Enterpriseの機能である IP Allow List（IP許可リスト） を活用し、社内のVPNや特定のオフィスIPアドレスからのみGitHubへのアクセス（およびCopilotの利用）を許可することで、物理的なアクセス境界を設定できます。
さらに、SAML SSO（シングルサインオン） を強制することは不可欠です。これにより、退職した社員のアカウントを即座に無効化し、Copilotへのアクセス権を確実に剥奪できます。AIツールへのアクセス権は、ソースコードのリポジトリ権限と同等、あるいはそれ以上に厳格に管理されるべきです。
特に最近では、MCP（Model Context Protocol） を通じて外部ツール（GitHub IssuesやFigmaなど）と連携するケースも増えていますが、SAML SSOによる認証基盤があれば、これらの拡張機能利用時のガバナンスも効かせやすくなります。「誰が、どのネットワークから、どのAIモデルを使えるか」をIDプロバイダーレベルで制御することこそが、強固なガードレールの基盤となります。
第2の防壁：プロンプトエンジニアリングにおける「サニタイズ」
プラットフォームの設定で「学習されない」環境を構築しても、入力するデータ（プロンプト）自体に機密情報が含まれている場合、通信ログやクライアントサイドの履歴に残るリスクがあります。開発者自身がAIと対話する際のリテラシーと、それを支援する仕組みが必要です。
Webアプリケーション開発において、ユーザー入力をそのままデータベースに入れない「サニタイズ」が常識であるように、AIへのプロンプト入力もサニタイズが必要です。特に、最新のGitHub Copilotは@workspaceコマンドやMCP（Model Context Protocol）を通じてリポジトリ全体や外部ツールをコンテキストとして読み込むため、意図しない機密情報の流出を防ぐガードレールが不可欠です。
機密情報をAIに渡さないための「コンテキストフィルタリング」
Copilot Chatは、現在開いているファイルや@workspaceで指定された範囲、さらにはMCP経由で接続された外部リソースをコンテキストとして解析します。ここで重要なのが、GitHubの「Content Exclusion（コンテンツの除外）」機能の活用です。
GitHub EnterpriseやOrganizationの管理者設定で、特定のパスやファイル（例：secret/、.env、顧客データを含むdata/など）をあらかじめ除外設定（Content Exclusion）に追加してください。これにより、開発者が誤ってこれらのファイルを開いた状態でCopilotに質問しても、AIはその内容を読み取ることができなくなります。
また、開発者個人の環境（VS Code等）でも、Copilotの読み取り範囲を制御することが可能です。
設定例（VS Code settings.json）:
"github.copilot.enable": {
"*": true,
"plaintext": false,
"markdown": true,
"scminput": false
}
さらに、.gitignoreに記載されたファイルは通常Copilotのコンテキストからも除外されますが、明示的な除外設定を行うことで、セキュリティの網をより強固にできます。チーム全体で「機密情報を含むファイルは、システム的にAIの目から隠す」という運用を徹底してください。
機密データ（APIキー、パスワード）の自動検出と置換フロー
レガシーコードのリファクタリングでは、ハードコードされたパスワードやAPIキーが含まれるファイルを扱うケースが多々あります。ここで絶対にやってはいけないのが、「コードをコピーしてチャット欄に貼り付け、修正を依頼すること」です。
最新のGitHub Copilotでは、チャットへのコピペではなく、Copilot Edits（インライン編集）やAgent Mode（エージェント機能）を活用するのがベストプラクティスです。特にAgent Modeは自律的にファイルを編集するため、事前の安全対策が重要です。
以下のフローを標準として定義します。
- 事前サニタイズ（プレースホルダー置換）:
AIにコードを読み込ませる前に、機密情報をダミー文字列に置換します。"password": "SuperSecret123!"→"password": "<PASSWORD_PLACEHOLDER>"
- エージェント機能での指示:
Copilot EditsやAgent Modeを使用し、コンテキストを明確にして指示を出します。
プロンプト例: 「@workspaceこの接続ロジックをリファクタリングし、ハードコードされた値を環境変数から読み込むように修正してください」 - 環境変数化:
AIが生成したコードは、プレースホルダーやハードコードではなく、環境変数（process.env.DB_PASSWORDなど）やシークレット管理ツール（AWS Secrets Manager, HashiCorp Vaultなど）を参照する形になっているはずです。
このプロセスを経ることで、生の機密情報がAIモデルへのリクエストに含まれることを物理的に防ぎます。
Copilot Chatに与えるべき「セキュリティ制約プロンプト」のテンプレート
AIに対して漠然と「リファクタリングして」と依頼すると、AIは機能性のみを追求し、セキュリティを軽視する可能性があります。特に@workspaceコマンドやMCPを使用して広範囲のコンテキストを渡す際は、明示的な「セキュリティ制約（Security Constraints）」を含めることが重要です。
以下は、最新のCopilot Chatの機能を活用した、リファクタリング用のプロンプトテンプレートです。
@workspace /fix 以下のレガシーコードのセキュリティと保守性を向上させてください。
【制約事項】
1. セキュリティ: OWASP Top 10の脆弱性を回避すること。特にSQLインジェクションとXSS対策を実装してください。
2. 機密情報管理: コード内のハードコードされた値はすべて排除し、環境変数または設定ファイルからの読み込みに変更すること。
3. エラー処理: 汎用的な例外キャッチではなく、具体的な例外クラスを使用し、スタックトレースの外部流出を防ぐこと。
4. 最新のベストプラクティス: 非推奨（Deprecated）なメソッドは避け、現在推奨されているライブラリや構文を使用すること。
5. 既存動作の維持: 入出力インターフェース（APIシグネチャ）は変更しないこと。
【対象範囲】
現在選択している関数、および関連するデータモデル
このように、役割（Role）と制約（Constraints）を明確に定義し、@workspaceコマンドで必要なコンテキストを正確に渡すことで、AIは「ただ動くコード」ではなく「本番環境に耐えうる安全なコード」を出力します。これをチームの「プロンプト・ライブラリ」として共有し、品質の標準化を図ってください。
第3の防壁：AI生成コードの検証とDevSecOps統合
最後の防壁は、AIが出力した後工程、すなわち検証とデプロイのフェーズです。特に、GitHub CopilotのAgent ModeやCopilot Editsといった機能により、AIが複数ファイルにまたがる自律的なコード修正を行うようになった現在、「AIが書いたコードは、人間が書いたコード以上に多層的に検証する」という原則が不可欠です。
AIリファクタリング専用のコードレビュー・チェックリスト
AI生成コードのレビューは、人間が書いたコードのレビューとは視点を変える必要があります。特に、@workspace コマンドでリポジトリ全体を参照させた場合でも、AI特有の「もっともらしい誤り」が紛れ込む可能性があります。以下の観点でチェックリストを再構築することをお勧めします。
- シークレット管理とハードコードの排除: AIは学習データに含まれるパターンから、APIキーやパスワードをコード内に直接記述（ハードコード）してしまうリスクがあります。認証情報が環境変数（
process.env.DB_PASSWORDなど）や、AWS Secrets Manager、HashiCorp Vaultといった適切なシークレット管理ツールから参照されているかを厳格に確認してください。 - 依存関係とハルシネーションの確認: importされているライブラリは実在するか？ 特にマイナーなライブラリや、存在しないバージョンを指定していないか？
- 広範囲な影響（Agent Mode特有）: 複数ファイルが同時に修正された際、インターフェースの整合性は保たれているか？ 意図しないファイルへの変更が含まれていないか？
- コンテキストとビジネスロジック: 変数名や関数名がプロジェクトのドメイン知識と合致しているか？ エッジケース（境界値）の処理がAIによって簡略化されていないか？
AIは「正常系」のコード生成には長けていますが、「異常系」や「例外処理」を省略する傾向があります。「もしデータベース接続がタイムアウトしたら？」「不正なフォーマットのデータが注入されたら？」という、防御的な視点でのレビューを徹底することが重要です。
SAST（静的解析）ツールによる自動脆弱性スキャンとの連携
人間の目視レビューには限界があります。そこで、機械的なチェックはツールに任せ、自動化されたガードレールを構築します。GitHub Advanced Security (GHAS) の中核である CodeQL は、AI生成コードの検証において強力な武器となります。
CodeQLはコードをデータとして扱い、クエリを投げることで脆弱性を発見するエンジンです。GitHub Copilotの Coding Agent がIssueから自動的にPull Requestを作成するようなワークフローであっても、CI/CDパイプライン上でCodeQLを強制的に実行することで、SQLインジェクションやXSSなどの脆弱性をマージ前に阻止できます。
- 推奨フロー: Coding AgentでPR作成 → GitHub ActionsでCodeQLおよび依存関係スキャンを実行 → 脆弱性検知時はマージブロック → Copilot Autofix 等で修正提案
- インフラコード（IaC）の検証: アプリケーションコードだけでなく、TerraformやCloudFormationなどのIaCコードもAI生成の対象となります。これらに対しても、AWS Configなどのコンプライアンスルールやセキュリティポリシーに違反していないか、自動スキャンを実施する体制が望まれます。
人間が見るべきポイントとツールに任せるべきポイントの分離
すべてを自動化ツールに任せることも危険です。一方で、人間が全ての行を見るのも非効率です。ここで重要なのが、マルチモデル対応が進んだCopilot Chatを「第2のレビュアー」として活用する視点です。
- ツール（SAST/DAST/Lint）: 既知の脆弱性パターン、コーディング規約違反、ライブラリの安全性チェック。
- AI（Copilot Chat - セカンドオピニオン）: 複雑なロジックの解説依頼、エッジケースの指摘依頼。論理的推論に強いモデル（OpenAIの推論モデルやClaudeの最新モデルなど）を明示的に選択し、「このコードのセキュリティ上の懸念点を挙げて」と壁打ちを行う。
- 人間（最終意思決定者）: アルゴリズムの妥当性、アーキテクチャへの適合性、ビジネスルールとの整合性、倫理的判断。
このように役割を分担することで、レビューの質と速度を両立させます。「AIが書いたから時短になる」のではなく、「AIとツールが下回りを支える分、人間はより高次な設計とセキュリティの判断に集中できる」という体制こそが、真のDevSecOps統合と言えるでしょう。
組織導入のための「AIリファクタリング・セキュリティガイドライン」策定
技術的な対策だけでなく、運用するための「ルール作り」も重要です。どれだけ優れたツールがあっても、使う人間がルールを守らなければ意味がありません。特に、Agent ModeやCopilot Editsによる自律的なコード修正に加え、MCP（Model Context Protocol） を通じて外部ツール（Issue管理やデザインツール等）と連携が可能になった現在、セキュリティの境界線はコードエディタの外側にも広がっています。
組織導入の決裁を取るため、そして現場が迷わずスピーディーに使えるようにするために、以下のようなガイドラインを策定することが推奨されます。
開発チームに配布すべき利用規約テンプレート
社内WikiやNotionに掲載するガイドラインの骨子案です。最新のマルチモデル対応やMCPによる外部連携機能を考慮しています。
【AIコーディングアシスタント利用ガイドライン（案）】
1. 利用目的
当社は開発効率向上とコード品質改善のためにGitHub Copilot（Chat, Edits, Agent Mode含む）の利用を推奨します。ただし、利用にあたっては本ガイドラインを遵守してください。2. 禁止事項
- 機密情報の入力: 顧客の個人情報、本番環境の認証情報（パスワード、APIキー）、未発表の極秘プロジェクトの核心部分をプロンプトに入力することを禁止します。
- Agent Modeの放置: エージェント機能による自律的なコード修正を、監視なしで長時間実行させ続けることを禁止します。
- MCP連携時の権限過多: MCPを使用して外部ツール（データベースやチケット管理システム等）と連携する場合、原則として必要最小限の権限（読み取り専用等）で使用し、意図しないデータの書き換えを防いでください。
- 生成コードの盲目的な利用: AIが生成・修正したコードを、内容を理解せずそのままコミットすることを禁止します。特に複数ファイルにまたがる変更は、必ず依存関係への影響を確認してください。
3. 推奨アクション
- 適切なコンテキスト参照:
@workspaceコマンドを活用し、リポジトリ全体の文脈をAIに理解させた上で提案を受けてください。外部仕様を参照する場合は、MCP経由で該当するIssueやドキュメントを明示的に指定（例:@copilot #issue 123）してください。- モデルの使い分け: 複雑なリファクタリングにはClaudeの最新モデルやGeminiの最新版など、推論能力の高いモデルを選択することを推奨します（組織ポリシーで許可されている場合）。
- セキュリティスキャン: Pull Request時は必ず所定のCIパイプラインを通し、セキュリティチェックをパスさせてください。
4. 責任の所在
AIが生成したコードに起因するバグや脆弱性の責任は、AIではなく、それをコミットした開発者（およびレビュアー）に帰属します。
インシデント発生時の責任分界点
特に重要なのが「責任の所在」です。AIは法的な責任能力を持ちません。「Copilotが書いたコードが原因で情報漏洩しました」という言い訳は通用しません。
特に最近のアップデートで、AIは単なる「補完」から「自律的な編集（Agent）」へと進化し、さらにMCPによって外部コンテキストも扱えるようになりました。しかし、「最終的なコードのオーナーシップは人間にある」という原則は変わりません。むしろ、AIができることが増えた分だけ、人間による検証（Verification）の重要性は高まっています。
これは開発者にプレッシャーを与えるためではなく、プロフェッショナルとしての自覚を促すためです。同時に、組織としては「AIのミスを見逃さないためのチェック体制（CI/CD、自動テスト、人間によるコードレビュー）」を提供する責任があります。
定期的な監査と利用ログのモニタリング運用
GitHub Enterpriseには Audit Log（監査ログ） 機能があります。これを使って、定期的に以下の点をモニタリングします。
- Copilotの利用状況: アクティブユーザー数や、どのモデル（ChatGPT、Claude、Gemini等）が頻繁に使用されているかの傾向把握。
- ポリシー設定の変更履歴: 「Public Code（公開コード）と一致する提案をブロックする」設定などが意図せず変更されていないか。
- 外部連携（MCP）の利用状況: 許可されていない外部ツールへの接続や、トークンの不適切な利用がないか（※ログ機能の対応状況による）。
- 不審なアクティビティ: 通常の業務時間外や、許可されていないIPアドレスからの大量アクセス。
また、GitHub Advanced Securityの Security Overview ダッシュボードを活用し、AI導入前後でコードベースの脆弱性が増えていないか、あるいは修正率が向上しているかを計測します。Coding Agent等が自動生成したPRに対しても、脆弱性スキャンが確実に実行されているかを確認してください。もし脆弱性が増えているなら、ガイドラインの再教育やツールの設定見直しが必要です。
このPDCAサイクルを回すこと自体が、組織のセキュリティ能力を高めること（DevSecOpsの成熟）に繋がります。
まとめ：ガードレールがあれば、AIは強力なツールになる
レガシーコードのリファクタリングにおけるAI活用は、セキュリティという観点からはリスクがあります。しかし、「プラットフォーム設定」「入力サニタイズ」「検証プロセス」を適切に構築すれば、リスクを管理できます。
人間が手作業で行うリファクタリングのミスや見落としを、AIと自動テストが補完してくれると考えれば、安全性は向上します。特に@workspaceによる全体把握や、Agent Modeによる広範囲な修正支援は、人間の認知負荷を下げ、より本質的な設計判断に集中させてくれます。
最も危険なのは「なんとなく不安だから使わない」と決定を先延ばしにし、現場が個人アカウントの無料AIツールや、許可されていないWebベースのチャットAIを使い始めてしまうことです。これこそが、管理の及ばないセキュリティホール（シャドーAI）です。
まずは、管理された安全な環境（GitHub Enterpriseなど）を用意し、PoC（概念実証）を行うことを推奨します。実際にCopilot Chatがレガシーコードをモダン化し、同時にCodeQLがその安全性を保証する様子を確認することで、その価値を評価できるはずです。まずは動くものを作り、検証を重ねていきましょう。
コメント