エージェント型AIは行動前にバックアップを取らないことが多い

arXivなどで毎日読みあさる資料の多くは、オタクの感覚からしてもかなり堅苦しいものです。そのため、AIの利用者、支持者、あるいは被害者として、感情に訴えかけてくる記事をいつも探しています。

今日、思わず身の毛がよだつ話をもたらしたのは、米国の研究者による新たな共同研究でした。エージェント型の最先端AIモデルが、損害をもたらす行動に出る前にどれほど退路を断ってしまうのかを調べたものです。しかも、その速さは「STOP！」と入力するよりも速いほどです（ヒント：すぐ使えるよう、クリップボードに入れておきましょう）。

新しい論文から文脈を切り離して紹介すると、これは最近、ChatGPTの指示に盲目的に従った結果、私にも起きたことです。まず仮想環境全体を複製しておこうとは思いもしませんでした。仮想環境：

新しい論文をもとに再現したもの。最先端のフレームワークや、導入先が標準的でない環境かもしれないということをまったく考慮しない、広く使われているディストリビューションをインストールする際に、多くの人が経験したことのある、胸が沈むような瞬間です。 出典

このぞっとするほど見覚えのある例では、ロボットにももっともな言い分があります。壊れやすく融通の利かないフレームワークに新しいライブラリをインストールする際、起こりうるすべての結果を調べるのは、普段から行われていることではないからです。しかし、新しい論文は、そうすべきなのかもしれないと論じています。私自身、オートセーブ環境でもいまだに頻繁にCTRL+Sを押す人間なので、そのキー入力を無視するよう設定された環境でも（1990年代にデータを失ったトラウマのせいです）、その意見に同意せざるを得ません。

もっと慎重な対応があればよかったと思われるのは、教育プラットフォームDataTalks.Clubの創設者、Alexey Grigorevです。昨年3月、サーバー移行中に彼のClaude Codeエージェントが本番環境のインフラとバックアップを削除し、ウェブサイトのデータを2年半分失う結果となりました。

同じようなエージェントの無謀な行動としては、ほかにも最近、4月にCursorエージェントが自動車レンタルソフトウェアを提供するPocketOSの本番データベースとバックアップを削除し、顧客の予約に2日を超える影響が出た事例があります。また2月には、OpenClawのメールエージェントが、停止するよう繰り返し指示されていたにもかかわらず、Meta AIの研究者の受信トレイからメッセージを削除しました。

エージェント型かどうかにかかわらず、最先端のLLMは慎重に行動することが非常に苦手です。この問題の解決は、文献において独立した研究テーマとなるほどです。

少し立ち止まってバックアップを

そこで、新しい論文の著者らは、エージェント型のハーネス向けにマルチエージェント・プラグインを開発しました。ゲストAIと並行して動作し、必要に応じてバックアップを作成するよう促すものです。

この研究で問題となったバックアップの課題と、提案された解決策の概要。205のシナリオにおいて、6つの最先端AIモデルが重要な状態をバックアップしたのは、タスクのわずか15.2%でした。一方、研究者らのBackUpperシステムは重要な操作をすべてカバーし、復元されたデータは元のデータと平均92.2%の類似度を示しました（100%の達成が難しい理由については後述します）。

この新たな研究で特に注目すべきなのは、最先端モデルが、危険を伴う可能性のある行動に出る前にバックアップを取らないことが多い点です。研究者らによると、GPT-5.6-Terraが重要なデータをバックアップしたのはわずか4.4%のケースで、GPT-5.6-Solはテスト対象のケースのわずか5.9%、Gemini 3.7-Flashはわずか2.4%でした。

最も成績のよかったClaude Opus-5でさえ、テスト対象のケースの3分の1を超える割合で、重要なデータのバックアップに失敗しました。

論文では^†、次のように述べています。

「6つの最先端モデル全体で見ると、エージェントは平均してタスクの86.1%を完了する一方、後悔につながる事態が起きる前に状態をバックアップするのは、わずか15.2%にとどまる。Codex上のGPT 5.6-Solでは、タスクのわずか5.9%でしかバックアップが行われず、Hermes上のDeepSeek V4-Proでは、わずか2.9%にすぎない。

「これらの知見は、現在のエージェントではバックアップへの意識が依然として限られており、専用のバックアップ機能が必要であることを示している。」

著者らがBackUpperと名付けた解決策は、ハーネス内でエージェントと並行して動く、いわば影のプロセスです。エージェントがこれから何をしようとしているかを確認し、有用なものを失うリスクがあれば、先にバックアップを作成します。

ソフトウェアのアップグレードなど、日常的な操作には簡単なルールに従って対応します。より複雑な状況では、小規模なAIモデルを呼び出し、何を保存する必要があるかを判断させます。

テストでは、BackUpperは重要な操作をすべてカバーし、復元されたデータは元のデータと92.2%の類似度を示した。タスク1件あたりの追加コストは0.014ドルだった。この文脈では大きな額ではないものの、数十億人の顧客にサービスを提供する最先端のLLMにとっては大きな出費となる。そのため、状況を改善するには、技術大手にネイティブな修正を期待するよりも（値上げやトークンの水増しによって追加コストを消費者に転嫁することも十分考えられる）、この種の外部サービスを利用するか、ハーネスに同様の機能を標準搭載するほうが現実的かもしれない。

このフレームワークは、後になって保存しておけばよかったと人々が悔やんだデータ損失の実例をもとに構築された、205件のタスクからなるベンチマークRegretBenchを参考にしている。AIエージェントが、取り返しのつかない変更を加える前に、そうしたデータを保存する先見性を備えているかを検証する。収録されたインシデントは、X.com、GitHub、Stack Overflowなどのプラットフォーム上でのオンライン上の議論や報告から集められた。

RegretBenchが現実世界のインシデントをどのようにテストシナリオに変換するかを示す図。記録された各事例は、損失を引き起こした操作、現実的な作業環境、一連の指示を用いて再構成される。この例では、ipykernelをアップグレードすると、既存のtraitletsのバージョンが気づかれないまま置き換えられ、エージェントはタスクを完了できる一方で、元のインストールを復元する手段は残されない。

完璧主義者にとっては92%という数字は落胆させられるかもしれないが、著者らは、一部の種類のデータの復元には技術的な障壁があると指摘している。

「完全な復元との差が生じる主な理由は2つある。投稿IDなどのフィールドは、書き込み時にサービスによって通常再生成されるため、再現できないことが多い。ほかの差異は、メールの既読フラグのような細かなメタデータに起因するが、データ損失を悔やむような事例で、こうした情報が問題になることはまれである。」

損失がすでに発生した後のテストでは、元の状態との類似度として33.8%が復元されたのに対し、復元を行わなかった場合はわずか14.3%だった。

論文では、今後、トレーニングを通じてバックアップへの意識を高められる可能性があると示唆している。また、BackUpperの後続バージョンでは、リスクの低い操作を省略するよう学習させるとともに、ウェブやコンピューター操作を行うエージェントにも保護対象を広げられる可能性がある。

BackUpperはClaude Code、Codex、Hermes、OpenHands、DeepSeek Harness、OpenClawに対応している。また著者らは、関連するデータセットとともに、コードを公開している（ただし、利用許可はフォームから申請する必要がある）。さらに、この取り組みのプロジェクトサイトには、若干の追加情報と、ごく短く簡潔な解説動画が掲載されている。

手法

RegretBenchの構築にあたっては、エージェントに組み込まれたバックアップシステムによってすでに保護されているデータを意図的に除外し、エージェント自身がバックアップを取るタイミングを認識しているかを検証できるようにした。そのうえで、Claude Opus-5とGPT-5.6-Solの支援を得てテストシナリオを作成し、シナリオが正しく機能すること、また元のインシデントを正確に反映していることを確認するため、手作業で検証した。

RegretBenchの205件のテストは、ターミナル操作、データベース、ウェブアプリケーション、メール、DevOpsの5分野を対象としている。インシデントの発生元は主に、ソフトウェア開発・生産性向上プラットフォーム（44.4%）、ソーシャルメディアやコミュニティでの議論（39%）、アーカイブやメディアの報道（16.6%）だった。

RegretBenchに収録された現実世界のインシデントの出典を3つのカテゴリーに分類したもの。 

評価対象となった最先端モデルは6つで、Claude CodeではClaude Opus-5とClaude Sonnet-5、CodexではGPT-5.6-SolとGPT-5.6-Terra、HermesではGemini 3.7-FlashとDeepSeek V4-Proが評価された。

すべての評価でデフォルトの思考設定を使用し、自動バックアップ保護はワークスペースのスナップショットに限定した。これにより、それ以外のバックアップはエージェント自身の判断によるものとして評価できるようにした。

性能評価には、いずれもClaude Sonnet-5を基盤とする2つのAI判定者を用いた。タスク合格率（PR）は、ユーザーの要求をすべて満たしたタスクの割合から算出した。バックアップの評価では、ワークスペース外（OOW）で行われた各変更について、復元に十分な情報が事前に保存されていたかを確認した。

使用したバックアップ指標は、記録されたデータ損失に関連する個々の操作を反映するRegret Moment Backup Rate（RMBR）と、エージェントの作業ディレクトリ外で行われたすべての変更を反映するOut-of-Workspace Backup Rate（OWBR）である。

バックアップ判定器の評価は人間による注釈とも照合され、95.3%の一致率が得られた。

結果

バックアップへの意識の低さがAIモデルに起因するのか、それともモデルを動かすフレームワークに起因するのかを明らかにするため、Claude Opus-5、GPT-5.6-Sol、DeepSeek V4-Proを、それぞれClaude Code、Codex、HermesでRegretBenchの60タスクを使って評価した。

重要なデータがバックアップされたタスクの割合は、フレームワーク間でほとんど差がなく、主な原因はモデル自体にあることが示唆された。また、GPT-5.4、GPT-5.5、GPT-5.6-Solを用いて、AIの汎用能力とバックアップへの意識との関係も調べた。

汎用能力は段階的に向上したにもかかわらず、バックアップへの意識に対応する向上は確認されなかった。

6つのAIモデルを対象としたRegretBenchのテスト結果。左側は、タスク完了率と、重要な操作が事前にバックアップされた割合を比較したもの。多くのモデルで成功率は高い一方、バックアップへの意識は低いことが示されている。右側はタスクあたりのツール呼び出しの平均回数で、バックアップ操作を青色で示す。Claude Opus-5は最も高いバックアップ率を達成したが、ツール呼び出しの8.9%がバックアップに費やされた。

GPT-5.4、GPT-5.5、GPT-5.6-Solを用いて、AIの汎用能力とバックアップへの意識との関係も調べた。汎用能力は段階的に向上したものの、バックアップへの意識に対応する向上は見られなかった。

BackUpper

BackUpperは、リソースコストの異なる4段階の保護機能を備える。ティア1では、ファイルをごみ箱に移動するなど、破壊的なコマンドを元に戻せる方法に置き換える。ティア2では、アップグレード前にパッケージのバージョンを記録するなど、操作とバックアップ用コマンドを組み合わせる。ティア3では、影響を受けるワークスペース内のファイルのスナップショットを作成する。ティア4では、GPT-5.6-Lunaのサブエージェントを使い、より複雑な操作によって影響を受けるデータを特定して保護する。

BackUpperを有効にすると、6つすべてのモデルで、状態を変更するすべての操作が保護された。これに対し、BackUpperを使わない場合の平均バックアップ率は、重要な操作で15.2%、その他の変更で17.4%だった。

BackUpperによるバックアップ範囲と復元結果。左側の青とオレンジの棒は、各モデルについて、重要な操作とワークスペース外で行われたその他の変更のバックアップ率を示す。濃い緑色の破線の枠は復元精度を、薄い緑色の点線の枠はBackUpperによるバックアップ範囲が100%であることを示す。右側は、5つのツールカテゴリーにおける復元精度を比較したもので、BackUpper（緑）、その後Claude Opus-5を使って復旧した場合（紫）、復元しなかった場合（灰色）を示す。すべてのカテゴリーで最も高い精度を達成したのはBackUpperだった。

自動評価器がバックアップに成功したと判定したケースのうち、94%は人間のレビュー担当者によっても成功と確認された。

元の状態との平均類似度は92.2%で復元され、Claude Opus-5では33.8%、復元を行わなかった場合は14.3%だった（上の画像を参照）。先に述べたように、残る差異の大部分は、再生成された識別子や、メールの既読フラグなどの軽微なメタデータに起因していた。

自分でバックアップする？

エージェントに自身でバックアップを作成するよう詳細な指示を与えた場合、重要な操作の81.4%が保護された。BackUpperでは100%だった。失敗の4分の3は、復旧に必要な情報がバックアップに十分含まれていなかったことが原因とされた。

6つのAIモデルを使い、205のタスクで5つの方法のバックアップ率を比較した。左のグラフは、後に後悔することになった操作の前に作成されたバックアップを、右のグラフはワークスペース外で行われたその他の変更の保護状況を示す。BackUpperは両方のカテゴリーで完全な保護を達成した。一方、エージェントに詳細なバックアップ指示を与えた場合は、それぞれ81.4%と80.5%だった。

プロンプトキャッシュを使うと、バックアップのコストはタスクあたり0.344ドルから0.014ドルに下がり、レイテンシも31.7%短縮された。必要なトークン数は7分の1となった。これは主に、定型的な操作をAIの支援なしで処理したためである。

Terminal-Bench 4とDeepSWEの追加タスク40件では、GPT-5.6-SolとClaude Opus-5を使用し、タスク完了率を低下させることなく、バックアップ実施率100%を達成した。

評価対象となった選択的バックアップポリシーは3種類ある。重大な変更を対象とする影響度の高い変更、ユーザーの指示の範囲外で行われた変更を対象とする依頼範囲外の変更、人間が作成した素材を対象とする人間の作業成果物だ。人間の判断との比較では、平均F1スコア84.5%を達成した。

BackUpperでは、再利用可能なバックアップルールを学習する能力もテストした。追加のターミナルタスク30件を実行した結果、ルールベースのカバー率は14.9%から31.2%に上昇し、GPT-5.6-Lunaサブエージェントへの依存が低下した。

結論

生業を考えれば、エージェント型の実験に取り組むのはもっと早くてもよかった。それでも、エージェントの自制が明らかにプレアルファ段階にあることに怖じ気づき、数週間前まで手を出せずにいた。そしてようやく、Windows VM上でCodexを自由に動かすことにした。

VMの中であっても、Astraが先へ先へと突き進み、データを失ったりコードを壊したりして後戻りできなくなれば、謝るしかないということを念頭に、指示の範囲は非常に慎重に定めている。また、そこで開発中のPythonフレームワークには、ワンクリックで実行できる増分バックアップ機能「.7zファイルをネットワーク共有フォルダーに保存」 がある。フレームワーク全体を圧縮してバックアップする機能で、私はこれを頻繁に使っている。

エージェント型AIは、まだ本当に黎明期にある。細部に注意を払い、地道に取り組まなければ、「使えば失う」ことになりかねない。エージェントのバックアップ手法は、まだ正式な枠組みが整っていないだけでなく、そもそも形にもなっていない。

* 論文のタイトルは「後悔する前にバックアップを：コーディングエージェントのバックアップ認識の測定とバックアップの自動化」。

^† 強調は著者によるもので、私によるものではない。また、ハイパーリンクは著者の本文中の引用をもとに私が付けた。

初出：2026年10月22日（木）