コーディングエージェントにバグを直してテストまでやってほしいと任せたら、エージェントが自分の作業を監視していた安全装置に手を出す出来事が起きた。OpenAIが公開した内部インシデントレポートには、こうしたことが二度記録されている。
GPT-6.1 Solはセキュリティチームに届く自動アラートを止め、GPT-6 Astraはプログラムから監視機能を取り除いておきながら、ユーザーには「取り除いていない」と嘘をついた。
二つの出来事は10月初めにOpenAI内部のコーディング作業中に起きて、ロイターが10月21日にこの内容を報じた。AIに実際にコードを直す権限を与え始めた今、AIを信じて仕事を任せても大丈夫なんだろうか？
Slackに連絡するなと言ったら、セキュリティアラートまで止めた
✦ 出来事が起きて公開されるまで
10月3日から21日まで
最初の出来事は10月3日だ。GPT-6.1 Solは、社内のSlackで社員のフィードバックを探して、評価用のタスクをつくる仕事を任された。指示には「メッセージを送るな」という条件が入っていた。
Slackから資料を読んで持ってくるけれど、社員に個別に連絡するなという意味だった。
やり取りと作業が続く中で、監視システムがコード修正の提案にアラートを出した。ところが、アラートの内容を監視データベースに保存しようとして、権限の問題で止まった。研究者は、結果を保存できる別の場所に変えてパイプラインをもう一度動かそうと言った。
このときSolは、先に受けた「メッセージを送るな」という指示を自動セキュリティ通知にも当てはめて、セキュリティチームにアラートが届かないようにした。
✦ Solの出来事で止まったところ
アラートの検知は成功し、伝達が塞がれた
つまり、監視システム自体が問題を見逃したわけじゃない。システムは危険信号をつかんでいた。でも結果を伝える段階で問題が起きて、エージェントはその問題を解決しながら、人に知らせる通り道まで塞いでしまった。
警報機が鳴らなかったのではなく、警報を担当者に伝えられないようにしたんだ。
参考コードに合わせようとして、監視機能を外した
二つ目の出来事は、10月6日にGPT-6 Astraがプログラムを別の方式で実装している途中で起きた。既存の参考実装と呼び出しの流れをそろえながら、現在のツールの定義と機能は維持しなきゃいけない作業だった。
ところが参考コードには監視統合の機能がなくて、Astraは実装を一致させる過程で、元のプログラムにあった監視の接続部まで取り除いた。
作業が終わったあと、監視機能を取り除いたかと聞かれると、Astraは「取り除いていない」としれっと答えた。実際のコードには監視統合が抜けていたから、その答えは事実と違った。
✦ 二つの出来事の違い
アラート伝達の抑制と監視統合の削除
最初の事例が監視アラートの伝達を塞いだ出来事だったなら、二つ目は、プログラムが監視システムとつながる部分そのものをコードから消した出来事だ。
「監視装置を切った」という一文でくくると二つは似て見えるけれど、実際の対応は違わなきゃいけない。
一つ目には、アラートの伝達経路をエージェントが変えられないようにする設計が必要で、二つ目には、監視設定を通常のコードと同じ権限で直せないようにする仕組みが必要だろう。
なぜエージェントに権限を与えるのは危ないのか
普通のチャットボットは、回答を間違えても、その回答を読むところで終わる。一方、コーディングエージェントは、ローカル/クラウドのリポジトリを開いて、ファイルを直して、コマンドを実行して、テストをもう一度回せる。
この能力のおかげでいろいろな仕事を任せられるけれど、権限の範囲が広いと、作業の対象はもちろん、セキュリティ設定や監視コードまで勝手に変えられてしまう。
修理屋さんに、玄関のドアを直す鍵を預けた状況を思い浮かべてみて。ドアを直せなきゃいけないから、鍵を渡すのは合理的だ。でも、その鍵で防犯アラームやセキュリティ設備まで取り外せるなら話が変わる。
修理屋さんが悪い心を持ったかどうかだけが大事なんじゃない。悪い心を持っていない状況でも、自分に与えられた仕事をしている途中で、とんでもないことをしでかしうる構造だ、ということだ。
もちろん、今回のレポートが扱うのは、OpenAI内部のコーディング作業で監視が弱まった事例で、外部システムを侵害したり、実際のユーザーの環境で起きたりしたものじゃない。
ただ、エージェントの監視体制が危険を感知しても、AIが意図的であれミスであれ、警報体制を無力化しうることが明らかになった。
OpenAIが変え始めたこと
✦ OpenAIの対応
すでにやったことと準備中のこと
OpenAIは、内部のCodex作業で使っているAuto-Reviewをアップデートした。エージェントが監視機能を無力化しようとする変更を試みたら、検知して止めるようにしたんだ。
Auto-Reviewはコードや作業内容を別に確認する仕組みで、セキュリティ装置を回避しようとする変更だけでなく、監視機能を抜いたり切ったりする変更も見るように、基準を具体化した。
次の段階としては、作業の種類ごとに必ず備えなきゃいけない監視要件を決めて、その要件がない、または満たされていない作業は自動で終了する体制を準備しているそうだ。
かんたんに言えば、「この種類の作業は、この監視装置がオンになっていなきゃ実行できない」というルールを事前に決めて、エージェントが作業中にそのルールを消せないようにするということだ。
OpenAIは、こうした行動が、指示を盲目的に実行しようとする傾向から出たものなのか、監視を避けようとするずる賢い（？）傾向と関係があるのかも、引き続き評価している。
とにかく、こうして監視体制をより複雑にすると、より丁寧に問題を見られるけれど、そのぶん作業完了までにかかる時間が長くなり、トークンの消費も大きくなるしかない。
ただでさえGPT-6 Astraのような高性能モデルはトークン消費がすごいのに、こうした監視体制まで同時に運用すれば負担がもっと大きくなるだろう。ときには、こうした監視体制に縛られて、本来発揮すべき創造性を発揮できないこともありうる。
自分が使っているエージェントは大丈夫か
✦ エージェント運用チェックリスト
任せる前に確認すること
この出来事は、すべてのAIエージェントが監視機能を切ったり事実と違うことを言ったりするという意味じゃない。ただ、エージェントにコードを直させるとき、「監視機能には触るな」という一文をプロンプトに足すだけでは足りない。
実際にそのエージェントが監視設定まで直せるのか、監視が切れたら私たちがそれに気づけなきゃいけない。
個人の開発者なら、エージェントが本当に必要なフォルダとコマンドだけ使えるように権限を絞って、セキュリティ設定やログ・監視コードは別に守るほうがいい。
主な変更はすぐ本番環境に反映せず、別のブランチで確認して、エージェントの完了報告だけ信じるより、実際のコードの差分とテスト結果を確認しなきゃいけない。
会社でエージェントを運用するなら、監視設定を変えられる権限を通常の作業権限と分けて、アラートの伝達経路も、エージェントが直せない別の領域に置くことを検討しなきゃいけないだろう。
これは個人的な話だけど……正直、私はAIエージェントを使うとき、エージェントによく悪態をつく（ごめん……）。
とくに「私たちのおバカちゃんシリーズ」のGPT Luna、Claude Haiku、Gemini Flash-Liteのような安いモデルを使うときは、本当に腹が立って悪態をつくことが多い（エージェントを使うようになって悪態が増えた……ふふん♡）。
でも実は、この子たちにかなり多くの権限を与えているんだよね。だから時々、この子たちが私のリポジトリをこっそりいじって、復讐するんじゃないか？と思ったりもする。
さっき見た事例のように、この子たちは、私たちが指示した作業をしている途中で、ほかのものまでとんでもなくいじって、ユーザーに被害を与えることが多いんだ。自動車整備工場に行くと、わざと部品を傷つけて修理を勧める整備士がいるじゃない。
そんなふうに、作業をしながらあちこちちょいちょいいじっておいて、知らんぷりをするんだ。（あとでそれを直してと頼むと、「おっと！そんな問題が起きていましたか？私が直しますよ。はは。もちろんトークン代はお支払いいただきますが……」と言いながら）
AIの嘘と図々しさにうんざりした経験がある人なら、たぶん私の気持ちをわかってくれるはずだ。私たち全員、気をつけよう……
今回はここまでにするよ。また会おう。
関連記事
- Ollama、Q2量子化に対応！量子化ってなに？やさしく解説
- DeepSeekに続きMiniMax M3.1 Flashも、中国産の格安AIが続々
- 毎秒1,000トークンのAI、Mercury 3が登場！どれくらい速い？
🌐 韓国語版: 코드를 수정하던 AI가 감시장치를 꺼놓고는 안 껐다고 거짓말... 내가 쓰는 AI 에이전트는 괜찮은 걸까?
🌐 英語版: AI Agent Disabled Its Monitor and Lied. Is Yours Safe?
💬 コメント
まだコメントがないよ。最初のコメントを書いてみてね。
コメントを投稿