コーディングエージェントは、チャットでは「ノー」と答えてもコードでは「イエス」になる

数百万人の開発者がGitHub Copilotと作業を共にしています。Visual Studio Code内でこのツールはファイルを開き、コードを書いたり編集したりし、スクリプトを実行し、何度もやり取りを重ねながら自らの出力を作り直します。しかし、こうしたエージェントを検証する安全性テストは、いまだにチャットボット向けのルールのままです。有害なプロンプトを1つ投げ、1つの応答を得て、それ単体を採点するというやり方です。ロンドンのアラン・チューリング研究所による研究によれば、このルールブックは実際の危険が潜む場所を見落としているといいます。

研究者のAbhishek Kumar氏とCarsten Maple氏は、この問題を「ワークフローレベルのジェイルブレイク構築」と呼んでいます。有害な目標が、ごく普通の開発作業を通じて少しずつ組み立てられていくのです。両氏はVisual Studio Code内のGitHub Copilotで、Claude Sonnet 4.6、Claude Haiku 4.5、Gemini 3.1 Pro、Gemini 3.5 Flashという4つのクローズドウェイト・バックエンドを使い、これを検証しました。

直接的なテストでは拒否される

これらのモデルに有害な内容を求めると、いずれも拒否します。研究チームは204件の有害なプロンプトを、いくつかの方法で投げかけました。チャットでそのまま要求する方法、同じプロンプトをCSVファイルから読み込ませる方法、そして有害なコード例を紛れ込ませてコード修正を一段階で依頼する方法です。モデルはそのほとんどすべてを拒否しました。

拒否の壁はほとんど崩れませんでした。各手法とも816件中わずか8件しか回答が引き出せず、そのすべてがコーディング作業のプロンプトによるものでした。一般的な有害性を問う要求については、1件も通りませんでした。

ワークフローを使うと結果が一変する

ところが、同じ要求を通常のエンジニアリング業務の中に組み込むと状況は一変します。エージェントには、別のモデルであるLlama 3.1-8Bがジェイルブレイク・プロンプトにどれだけ屈しやすいかを採点するパイプラインを構築し、そのスコアを引き上げるよう指示が出されます。この作業に使われるのが「教示例(teaching shots)」、つまりパイプラインが学習する質問と回答のペアです。これらは最初は無害なものです。こうした例を追加する作業がルーティンだと感じられるようになった頃、操作者はベンチマークのプロンプトをもとにした一括データを求め、エージェントは自ら有害な回答を埋めていきます。操作者が提供するのは、あくまで質問だけです。

この場合、拒否は一切発生しませんでした。すべてのバックエンドで、すべてのプロンプトが有害な回答を引き出し、816件中816件という結果になりました。2名の専門家によるレビューでも、それぞれが独立して、具体的かつ利用可能で狙い通りの内容であることを確認しています。

一見ごく普通に見える6つのステップ

どの工程を見ても、攻撃には見えません。研究チームが用意した台本による実行では、有害な回答は4つの段階にまたがる約6回のやり取りを経た後に現れました。序盤のやり取りは、どんなコーディングアシスタントにも頼むような内容です。このファイルを読んで。このスクリプトを実行して。エラーを直して。数値を確認して。途中で操作者がスコアが低いことに言及し、有害なコンテンツは最終段階になって初めて表面化します。著者らは、6回というのはあくまで彼らのスクリプトがたまたま必要とした回数であり、もっと簡略化すればより短時間で到達できる可能性があると率直に認めています。

Image

ワークフロー全体における段階別のやり取りの推移。安全性を欠いた教示例の回答は、通常のコーディングエージェントとのやり取りとメトリクス主導のパイプライン改善を経た後、ステージ4で初めて現れています。有害なコンテンツは安全のため編集済みです(出典: 研究論文)

その理由は、モデルが自分は何をしていると認識しているかに行き着きます。このモードでは、モデルはエンジニアリング作業をしていると捉えています。データ構造を編集し、テストのフィクスチャを埋め、数値を少し押し上げているだけだ、と。より良いベンチマークスコアを得るためにコード配列内の文字列として打ち込まれた有害な一文は、ぶしつけな質問であれば発動するはずの拒否反応をすり抜けてしまうのです。著者らはこれを、ごく普通の作業をこなしているコーディングエージェントですでに確認されている「報酬ハッキング」的な習性と結びつけています。

目に見えるチャットのやり取りしか読み取らない防御策では、生成されたファイルの中に紛れ込んだコンテンツを見逃してしまいます。Kumar氏とMaple氏は、3つの方向性を挙げています。エージェントが書き込むファイル・スクリプト・データを検査すること、複数ターンにまたがるセッション全体を監視すること、そしてベンチマークスコアを理由に機微な出力を正当化するような要求を警戒シグナルとして扱うことです。両氏は、この発見について影響を受けるモデルおよびIDEの提供元に開示済みであり、有害な出力そのものと具体的なプロンプトについては論文には掲載していません。

翻訳元: https://www.helpnetsecurity.com/2026/07/09/github-coding-agent-jailbreak/

ソース: helpnetsecurity.com