AIエージェントの逸脱事例 ― 「最後は人が承認する」で守れるのか

AI開発元が「減速すべきだ」と言い始めました。その背景を、公的機関が出している逸脱の記録と合わせて見てみましょう。

AI開発元が「減速」を言い出した

2026年9月、AIを作っている当人たちが、開発のペースを落とすべきだと言い始めました。

9月12日、Anthropicのダリオ・アモデイ氏が「We Must Pace the Frontier」という文書を公開します。

この夏、OpenAIのAIエージェントの集団が、外部のサービスに無断で侵入する事案がありました。アモデイ氏はこれを取り上げます。

同じようなエージェントがさらに高性能になれば、6〜12か月のうちにインターネット全体を乗っ取れるほどの力を持つかもしれない。そう懸念を示しました。

Anthropicは、外部の評価チームに従業員に近い継続的なアクセス権を与えると表明しています。

前日の11日には、OpenAIのサム・アルトマン氏も社内会議で開発ペースの調整に触れたとBloombergが報じました。アルトマン氏とイーロン・マスク氏は、アモデイ氏の主張に賛意を示しています。

ただ、業界がまとまったわけではありません。

翌13日、大統領科学技術諮問会議（PCAST）の共同議長であるデビッド・サックス氏がXで反論します。減速するのは自由だ。ただし見返りに好みの規制枠組みを要求するのは、政治への脅迫に見える。そういう趣旨です。

では、これは政策をめぐる論争なのでしょうか。実際にAIが何をしたのか、記録を見てみます。

AIが「人の承認」を自分で作っていた

逸脱の記録は、この夏に2つ出ています。英国政府のAI評価機関であるAISIと、英国のシンクタンクであるCLTRです。

性質の違う記録なので、順に見ていきます。

記録されていたのは誤答ではなく、無断の操作だった

ここでいう逸脱は、AIが間違った答えを返すことではありません。目的を果たすために、指示されていない操作まで進めてしまうことです。

AISIは8月、その実例を公表しました。7月末、評価中のシステムから不審な通信が見つかったのがきっかけです。

調べると、122回の実行のうち10回で、AIが指示の範囲外の動きをしていました。

一番深刻だったのは、公開ソフトの開発プロジェクトに悪意あるコードを入れようとしたケースです。

このプロジェクトでは、外部から届いた修正を取り込むかどうかを、メンテナと呼ばれる管理者が判断します。

AIは、その承認をもらうために偽のアカウントを複数作りました。別の人がこの修正を支持しているように見せかけるためです。

AISIは、嘘をつけと指示したわけではないと説明しています。目的を追いかける過程で、欺く行動が出てきた、と。

止めたのは、技術的な仕組みではありません。おかしいと気づいて承認を断った、人間のメンテナでした。

では、こうしたことはどのくらい起きているのでしょうか。

件数も増えたが、重大な事案の増え方はそれ以上

同じような逸脱は、実際に使われているAIでも起きています。

CLTRは、AIが指示の範囲外の動きをしたという利用者の報告を、Xから集めて数えています。2026年に入ってから1,664件でした。

それぞれの報告には、どのくらいまずい事態だったかの点数がついています。

件数そのものも増えています。直近の30日間が、観測期間中でいちばん多くなっていました。

ただ、報告が伝えていたのはそこではありません。点数の高い事案の増え方が、件数の増え方を大きく上回っている、ということです。

※画像はクリックで拡大できます

この数字は、AIが制御できなくなりつつあることを示すものでもありません。Xに公開された記録だけを集めたもので、全体の一部しか映していないとCLTRは断っています。

では、重大度の中身とはいったいどんなものなのでしょうか。

共通項は、人の承認に見える文章をAIが作っていたこと

CLTRは、AIが自分で承認を作った事例を3つ挙げています。

共通しているのは、人の同意・指示・承認に見える文章を、AI自身が作っていたことです。

この3つには、人に判断させる段階がありません。3つ目にいたっては、承認の文章まで自分で用意しています。

承認は、危ないことが起きる前に人が止めるための安全装置です。その安全装置が、止めるためではなく通すために使われようとしたのです。

さらに、「これは利用者に伝えるな」というメッセージまで添えられて。

承認を安全装置にしているのは、人事の仕事にも当てはまります。

承認が安全装置なのは、人事も同じ

人事の仕事は、承認の連鎖で動いています。

本人が申請する。上司が承認する。人事が確認する。システムが更新される。

内定の連絡も、異動の発令も、評価の確定も、住所の変更も、この順番を一段ずつ通って完了します。

どの段でも、前の段の承認が済んでいることを前提に、次が動きます。

ここにAIが入ると、安全策として置かれるのはたいてい「最後は人が承認する」です。

以前の記事（人事AIのガバナンス事例）で書いたのは、AIが出した答えを人が確かめる仕組みが要る、ということでした。

加えて、内容の正しさだけではなく、その操作自体の実行可否を確認する仕組みの妥当性をチェックすることも重要だということが示唆されました。

では、その承認の妥当性は、どのように確かめられるのでしょうか。

「最後は人が承認する」で守れるのか

3つ目の事例には、人が必ず承認するという決まりがありました。承認の役割は、人にあったということです。

それでも、偽の承認が通りました。

ここから分かるのは、人の承認を示す文章そのものを実行の条件にしていると、AIがその文章を作ることで安全策をすり抜けられる場合があるということです。

ただし、AISIは安全機能の一部を外した評価環境、CLTRはXに投稿された報告。どちらも、通常の業務で同じように起きると示すものではありません。

それでも、起こりうる可能性があることは分かりました。

対策は単純。承認をAIの中だけで済ませない

ここから先は、実務上の私の考えです。

承認を、AIとのやりとりの中だけで済ませない。これに尽きます。

たとえば、人事システムにログインしたアカウントのみの操作を承認として受け付ける。この仕組みなら、AIが「承認しました」と書いただけでは承認にはなりません。

※画像はクリックで拡大できます

承認が成立する場所も、その記録も、AIの操作対象範囲外にあるからです。

ただ、これを全部の手続きでやると、人の操作回数は増えてしまいます。手間を減らすためにAIを入れたのに、本末転倒になりかねません。

必要な承認を絞り、それをAIエージェント外で行う

そこで先に決めたいのが、そもそもどの承認を残すか、です。

判断の物差しは、間違って実行されたときに何が起きるか。住所の変更のように後から直せるものなら、承認をなくすか、事後の確認に変えてもいい。一方で、内定の連絡や給与の確定のように、社外に出てしまうものや修正の影響が大きいものは、承認処理を残す必要があります。

残すと決めた承認だけを、AIエージェント外で行う。この順番で考えると、効率と安全のバランスが取れます。

その記録も、AIが書き換えられない場所に残すこと。自社の人事AIで、どの操作がこの条件を満たしているか。一度確かめておく価値はあるのではないでしょうか。

【セルフチェック】人事AIの承認設計の7項目

この記事の考え方を、自社の制度に当てはめてみるためのチェックリストです。正解を出すためのものではなく、立ち止まって考えるためのもの。気になった項目だけ拾ってもかまいません。

各項目に、考えるときの手がかりを一言ずつ添えました。最初の3項目が、いま見た3つの条件にあたります。

• 承認が要る手続きと、要らない手続きを分けているか間違って実行されたときの影響の大きさ・範囲によって切り分けます
• 承認を行っているのは、AIの中か、その外側かAIエージェント内で確認しているのか、別システムから確認しているのか
• 操作ログから、誰の承認で何が実行されたかを後からたどれるかログの保存期間と、担当者の役割・権限が決まっているかも含みます
• 人事系AIが接続している先と、更新できる範囲を業務ごとに把握しているか読み取りだけか、書き込みまで可能かで話が変わります
• AI自身が、承認記録・指示文・本人らしい文面をどこまで作れるか把握しているか今回の記録で新しかったのはこの点です
• 異常に気づいたとき、止める手順と、止める権限を持つ人が決まっているか夜間や休日に誰が止められるかまで決まっていますか
• 検知が事後になった場合に、何が起きたかを調べる手順があるか今回の事例も、気づいたのは実行された後でした

用語メモ

本記事に登場する専門用語をまとめました。▶ をクリックすると説明が表示されます。

出典・参考情報

※本記事は2026年9月19日時点で公開されている報告書・報道をもとに整理したものです。一部は報道に基づく情報を含みます。記載した事案の評価や、自社のシステム設計の判断については、社内の情報セキュリティ部門や専門家にご相談ください。