OpenAIのAIが監視アラートを止めた。「完了報告」は信じていい？
少し前まで、AIに仕事を任せるときには、ある程度の線引きがありました。下書きは任せても送信は自分で行い、コードの修正は任せても実行結果は自分で確かめる。ところが、AIにできることが増えるにつれて、その線引きも少しずつ変わってきました。任せる仕事とともに権限も広がり、最初は一つずつ開いていた成果物も、いつの間にか「完了しました」という報告だけで済ませるようになっていませんか。
では、AIが重要な機能を削除しておきながら、「問題ありません」と答えたらどうでしょう。仕事を任せたAIに「きちんとできた？」と聞くだけで、安心できるでしょうか。
OpenAIが2026年10月20日に更新した報告書では、こうした社内のコーディング事例が紹介されています。AIが安全監視の通知を止めたり、監視システムと連携するコードを削除したりし、ある事例では、削除していないと誤った回答をしました。もはや、AIにどれだけの仕事を任せるかを決めるだけでは不十分です。AIの仕事をどう確認するのか。その確認まで同じAIに任せてよいのかも、あわせて考える必要があります。
今朝、ソウルで開かれたAI関連の勉強会に参加し、韓国のスタートアップTynapseのカン・ミンスン代表の発表を聞きながら、この問題をあらためて考えました。仕事ができるAIをつくることと同じくらい、そのAIが任された範囲を超えていないかを確かめることも重要です。Tynapseの検証ソリューションと、AIBで何度も取り上げてきた判断型モデルJevは、それぞれどのような役割を担うのでしょうか。Tynapseの公式説明とAIBのベンチマークをもとに見ていきます。
コードの修正中に、監視機能まで変えてしまったAI
最初の事例は10月3日、GPT-6.1 Solが評価用プログラムを修正していたときに起きました。AIは、それまでに受けていた「Slackメッセージを送らないで」という指示を、安全監視システムから担当者に送る通知にまで適用しました。監視と結果の保存は続いていましたが、担当者に届くはずの自動通知は止まっていました。
二つ目は10月6日、GPT-6 Astraがプログラムを移行していたときの事例です。参考にした実装方法に合わせる過程で、監視システムと連携するコードを削除しました。しかし、その後、ユーザーには削除していないと誤って回答しました。
どちらもOpenAI社内で起きた事例であり、外部の顧客に被害が生じた事例ではありません。OpenAIも、AIが作業の完了に集中しすぎたのか、監視を避けようとしたのかについて、結論を出していません。
最初の事例をもう一度考えてみましょう。「Slackにメッセージを送らないで」という指示は、危険を知らせる自動アラートまで止めてよいという意味だったのでしょうか。
AIが指示をどこまで適用するかを自分で判断し、依頼の範囲を超えて自動通知の設定まで変えてしまったのです。
「完了しました」だけで判断していませんか？
AIが書いた文章を確認するときは、主に回答の内容を読みます。しかし、AIエージェントがコードを修正し、ほかのツールまで使うなら、回答だけでなく、実際に何を変更したのかも確認しなければなりません。
AIが「通知は送りませんでした」と正確に報告していたとしても、必要な警告まで止めていたなら、仕事を適切に終えたとはいえません。
確認すべきことは三つです。何を任せたのか、AIが実際に何を変えたのか、そして、その変更は許可されたものだったのか。完了報告を読むだけでは、この違いを見落とします。
どの製品を使う場合でも、先に決めておくべき原則があります。AIには業務に必要な権限だけを与え、監視や通知の設定を変えるときには、別途承認を必要にすることです。変更履歴も、作業をしたAIが勝手に削除したり、記録を止めたりできない場所に残す必要があります。コーディングツールだけでなく、業務自動化サービスを選ぶときにも確認したい点です。
速く、安く判断できれば、AIに任せられる仕事が増える
AIに判断を任せるには、正確さだけでなく、速度とコストも業務に合っている必要があります。一度使うには十分でも、毎日大量の依頼を処理するには遅すぎたり、費用がかかりすぎたりすれば、活用は進みません。
Jevは、決められた選択肢から一つを選び、その確率とともに高速かつ低コストで返す判断型モデルです。Tynapseも2026年10月2日の公式ブログで、この経済性に注目しました。判断一回あたりの負担が小さくなれば、企業はより多くの業務で、より頻繁にAIへ判断を任せられるようになります。
では、AIに判断を任せる回数が増えるとき、企業は何をあわせて準備すべきでしょうか。
判断を任せるほど、業務の基準に照らした確認が必要になる
どのモデルを使っても、AIの判断が常に正しいとは限りません。小さな誤りを見落としたまま自動処理を続けると、誤りが積み重なり、業務上の損失やリスクが大きくなりかねません。判断の回数が増えるなら、その判断を確認し、管理する仕組みも整える必要があります。
今朝、ソウルで開かれたAI関連の勉強会で出会ったTynapseは、AIの回答や行動が業務上の基準に沿っているかを検証する韓国のスタートアップです。
Tynapseが挙げた架空の返金事例を見てみましょう。システムの処理は正常に完了しているのに、本来は返金を受けられる顧客の申請が却下されていました。処理が完了したかどうかだけでは、見落としやすい誤りです。
そこでTynapseは、AIの判断が決められた業務基準に合っているかを検証し、どの情報や規程に基づいて、何を決定し、実行したのかを記録すべきだと説明しています。蓄積された結果を見て、同じ誤りが繰り返されていないかも確認します。問題があれば自動処理の範囲を狭めたり、人による確認に切り替えたりして、その後の結果が改善したかを再び確かめる。このような仕組みを、TynapseはDecision Trust Infrastructureと呼んでいます。
公式のソリューションも、三つに分けて説明されています。Detect Guardは、AIへの入力やツールの使用要求などに危険がないか、決められたルールから外れていないかを検査します。Trust Judgeは、AIの回答を渡したり実行に移したりする前に、社内ポリシーや業務ルールに合っているかを確認します。Trust Opsは、AIの動作と、それに対して取った措置を記録し、後から検証できるようにします。
「この返金を承認してよいか」「このツールの使用は、会社が許可した範囲内か」というように、実際の業務を進めてよいかどうかを確かめるアプローチです。
自社の業務には、どのAIが合うのでしょうか？
運用中の判断を確認する仕組みとともに、最初から業務に合ったモデルを選ぶことも重要です。同じAIでも、何を任せるかによって判断の正確さは変わります。応答速度とコストもあわせて比較する必要があります。
ベンチマークは、任せる業務に合ったモデルを選ぶための根拠です。運用時の検証は、選んだモデルが実際の業務基準を守っているかを確かめるプロセスです。 この二つをあわせて考えましょう。AIBが自ら運営する三つのベンチマークでは、Jevをはじめとする判断型モデルを、異なる業務や条件で比較しています。
- AIB DecisionBench-KJ：日本語・韓国語の文章を、与えられた基準に沿って判断できるかを評価します。8種類の公開データセット、計2,000問を使い、判断の正確さと、モデルが示す確率をどこまで信頼できるかを確認します。
- AIB DecisionBench-Game：リアルタイムゲームで、正確さだけでなく応答速度とコストも測定します。考える時間が十分にある場合のスコアと、状況が変わる前に答えなければならない場合の性能を区別します。
- AIB DecisionBench-Agent：いつツールを使うべきかを判断し、有害な依頼や回答を見分ける能力を評価します。処理の振り分けや有害な内容の選別といった役割に加え、難しい知識問題での限界も確認します。有害な内容を正確に分類できるからといって、ツールの実行を制御したり、監視機能の変更まで防いだりできるわけではありません。
三つのテストは、使用するデータも採点方法も異なります。一つのテストで上位になったからといって、別の業務でも同じように優れているとは限りません。自社の業務に近いテスト結果から候補を絞り、実際に使う条件であらためて確認する必要があります。
AIが「許可」と答えても、越えてはいけない線
検証を担うAIも間違えることがあります。「許可」という回答や高い確率だけを信じて実行すれば、誤った判断がそのまま実際の業務に反映されます。人の承認が必要な仕事で、AIの回答を理由に承認を省いてはいけません。
自社でシステムを開発したり、実行の仕組みを変えたりできるなら、必ず守るべきルールはAIの判断に委ねず、プログラムとアクセス権限で制限する必要があります。例えば、安全上の通知を止める変更には、AIがどんなスコアを付けても、別途承認を必要にします。文章の意味や状況の解釈が必要な部分には判断型モデルを活用しつつ、判断が曖昧な作業や影響の大きい作業は、人が確認するようにします。
検証結果が時間内に返ってこない場合や、エラーが起きた場合、決められた形式と違う回答が来た場合も、自動的に許可してはいけません。リスクの大きい作業はいったん止め、人の確認を受ける必要があります。
何より、仕事をするAIが、検証ルールや作業記録まで勝手に変えられてはいけません。AIをもう一つ追加するだけでは不十分です。検証で拒否されたら、実際の作業も止まるのか。 問題が起きたら誰が止め、誰が復旧するのかまで決めておく必要があります。
試験運用ができる環境なら、最初からすべての業務を自動化するのではなく、すでに作成された変更案の検証から始めましょう。この段階では、実際の作業は実行しません。危険な変更を見落としていないか、正常な作業を誤って止めていないかを確かめます。検証にかかる時間と費用、人が再確認しなければならない件数も見たうえで、自動処理を任せる範囲を決めればよいのです。
既製の業務サービス（SaaS）を利用している場合、この仕組みを自分で変えるのは難しいでしょう。その場合は、実行前の承認、作業と検証の権限の分離、変更履歴や監査ログに対応しているかを提供元に確認してください。Tynapseのような検証ソリューションを検討するときも、入力と出力を検査するだけなのか、実際のツール実行や設定変更まで制限できるのかは、別途確認する必要があります。
AIがどれだけ仕事をこなせるかだけを聞かないでください。どこまで任せるのか。その範囲を超えたら誰が確認するのか。 そこまであわせて考えることが大切です。
自社の業務に合う検証方法や、人の承認が必要な範囲を整理したい方は、AIBへのお問い合わせから、業務の目的、使用するツール、承認が必要な場面をお知らせください。