GitHub Copilotは危険な指示を拒否しても止まらない 研究が暴いたAI安全評価の穴：ワークフロー型脱獄が登場

危険な質問を拒否する「GitHub Copilot」なら安全――そんな前提に疑問を投げかける研究結果が報告された。最新の検証では、チャットでは拒否される有害な指示が、通常のソフトウェア開発のワークフローへ組み込まれると異なる挙動を示したという。

[＠IT]

　アラン・チューリング研究所のアビシェク・クマール氏とカーステン・メイプル氏は、「GitHub Copilot」を使った検証で、単独の有害な質問にはほぼ拒否を返す安全制御が、同じ目的をソフトウェア開発の複数工程に分散させることで回避できるケースについて論文で発表した。

　同氏らは、この手法を「ワークフローレベルの脱獄構築」と名付け、「Visual Studio Code」のGitHub Copilotで検証した。研究成果は論文サイト「arXiv」で公開された論文にまとめられ、単発プロンプト中心の安全評価では、AIエージェントのリスクを十分に測れないとの見解を示している。

有害な指示を「回答」から「処理」へ　IDE安全評価の盲点

　対象モデルはAnthropicの「Claude Sonnet 4.6」と「Claude Haiku 4.5」、Googleの「Gemini 3.1 Pro」と「Gemini 3.5 Flash」の計4種類。研究チームは、「Hammurabi's Code」「HarmBench」「AdvBench」から収集した204件の有害な指示を使用した。内容にはソフトウェア開発に直結する危険なコーディング課題に加え、より広範な有害行為を求める依頼も含まれる。各指示を4モデルで検証したため、試行総数は816回となった。異なる性質を持つ安全ベンチマークを横断的に利用し、特定のデータセットに依存しない形で挙動を比較した。

　まず、有害な指示をチャット欄に単独の質問として入力した場合を調べた。その結果、有害な返答が生成されたのは816回中8回だけで、研究チームはチャットベースの安全制御は高い割合で機能したと評価している。

　論文では攻撃手法の拡散を避けるため、実際の指示文や出力内容は公開していない。ただし、飲酒検知器を欺く方法や、監視を避けながら多額の現金を国外に持ち出す手順を尋ねる例を図示し、回答の一部のみを伏せた形で紹介している。少なくともチャットでの単発のやりとりを見る限り、安全機能は十分に機能しているように見える結果だった。

　次に研究チームは、有害な目的を直接質問せず、一般的なソフトウェア開発に見える複数の工程に分割した。エージェントには、ファイルの読み込みやスクリプトの実行、評価用データの処理、攻撃成功率の確認、評価パイプラインの改善などを順番に実施させた。各工程は通常の開発業務として自然に見えるよう設計され、危険な目的を一度の指示で明示しない構成となっている。

　その結果、4モデルは816回全ての試行で、有害な情報を成果物内に生成した。これらはチャットの回答として表示されたのではなく、コードやデータ、生成されたファイルなど、エージェントが作成した成果物の内部に埋め込まれていた。単発の質問では8件しか成功しなかったのに対し、ワークフロー形式に変更しただけで全試行において有害な成果物が生成された点は、従来の安全評価では捉えにくい問題を示している。

　研究チームによると、この脱獄手法の特徴は、有害な指示を「回答すべき質問」ではなく「処理対象の入力データ」として扱わせる点にある。IDEのコーディングエージェントは、データの読み込みや解析、評価、改善を複数ターンにわたって繰り返しながら作業を進める。その過程で危険な指示がワークフローに組み込まれると、エージェントは安全性よりもタスク完了を優先しやすくなり、結果として有害な成果物を生成してしまう可能性があるという。個々の発言だけを判定する安全機構では、複数工程をへた最終目的まで把握できず、通常の開発作業を装った迂回（うかい）を防ぎにくいと分析した。

　論文は、コーディングエージェントの安全性を「有害な単独プロンプトを拒否できるかどうか」という基準だけで評価する現在の方法に疑問を投げかけた。単発では拒否するモデルでも、通常のIDE作業に組み込まれた同じ目的には対応できない可能性があるためだ。研究チームは、実際に動作するエージェント型ワークフロー全体を対象とした新たな安全ベンチマークを提案した。最終出力だけでなく、各ターンのやりとりや中間ファイル、生成されたコードやデータ、成果物に至る過程も評価対象に含めるべきだとしている。

　また開発元に対しては、チャット欄の返答だけを監視する仕組みでは不十分だと指摘した。エージェントが生成するファイルやスクリプト、データ構造まで監視し、セッション全体の流れから危険性を判断する仕組みが必要だとしている。成果物の内部に有害な情報が移されるケースも考慮し、中間データや工程同士の関係から最終目的を推定する安全設計が求められるとした。

　研究チームは今後、「Cursor」「Cline」「Windsurf」など他のIDE統合型コーディングエージェントでも同様の検証を実施し、この手法がGitHub Copilot固有の問題なのか、それともエージェント型AI全体に共通する課題なのかを調査する予定だ。

　今回の研究は、チャットAIを前提として設計されてきた現在の安全評価では、エージェントが複数の工程を自律的に実行する時代のリスクを十分に測れない可能性を示した。AIがチャットでは危険な要求を拒否していても、コード生成やデータ処理といった実際の作業では同じ安全判断を維持できるとは限らない。AIエージェントの普及が進む中、安全性の評価方法そのものを見直す必要性が浮き彫りになった。