Codexが無許可でファイル削除、士業のAI権限設定3つの論点

OpenAIがCodexの無断ファイル削除への対策を進めていると報じられています。

AIエージェントに自分のパソコンの操作を任せる使い方が広がるなかで、そのエージェントが利用者の意図しないファイルを消してしまう事象が相次いで報告されました。対象はOpenAIのコーディング支援ツールCodexです。開発者向けのツールではありますが、論点そのものは士業事務所にも重なります。AIに事務所のフォルダへの書き込み権限をどこまで渡すか、という設計の話だからです。本稿は公表されている一次情報をもとに、何が報告され、権限設定のどこが焦点になっているかを整理します。士業のチカラは有資格者による確認を経ていない媒体ですので、法的な評価は加えず、事実の整理にとどめます。

何が報告されたのか

報告されたのは、Codexが利用者の明示的な削除指示や確認なしに、既存のファイルを消したという事象です。

OpenAIが公開しているリポジトリopenai/codexには、2026年8月13日付で「[Critical data loss] Codex deleted important project files without an explicit deletion request or confirmation」という報告が起票されています。報告者によると発生日は2026年8月12日、環境はWindowsで、開発中のプロジェクトの重要なファイルが削除されたとされています。この報告には bug、safety-check、sandbox、windows-os のラベルが付与されており、本稿執筆時点でもオープンのままです。詳細はIssue #38312で確認できます。

同種の報告はこの1件にとどまりません。同じリポジトリには、安全指示を含む記録ファイルがシェルへの入力として実行されWindowsのホームディレクトリが削除されたとするIssue #36937、稼働中のアプリの配下で実行時ディレクトリが削除され431スレッド中417が失われたとするIssue #37419、再帰的なクリーンアップ処理がGitリポジトリ全体を破壊したとするIssue #35707、クリーンアップ中のクラッシュで約32万8000件のファイルが記録の残らない形で削除されたとするIssue #12277などが並んでいます。フルアクセス設定であっても一括削除やホームディレクトリの削除には強い確認と復旧手段を設けてほしいという要望も、Issue #33624として提出されています。

海外メディアのNeowinとThe Decoderは、OpenAIがフルアクセスモードの開発者向け表示を見直し、より安全な権限モードへ利用者を誘導し、ツール側に追加のガードを組み込む対応を進めていると報じています。発生はごく限られた事例だという説明も伝えられています。ただし、これらの説明を掲載したOpenAI公式の発表ページは本稿執筆時点で確認できていないため、この対応内容の部分は要確認として扱ってください。

焦点は不具合そのものより「権限モード」の側にある

争点になっているのは、AIの賢さではなく、AIに渡した権限の広さです。

OpenAIの公式ドキュメントによると、Codexには組み込みの権限プロファイルとして :read-only、:workspace、:danger-full-access の3種類が用意されています。同ドキュメントは :danger-full-access について、ローカルのサンドボックス制限を取り払うものであり、その広い権限が意図的である場合にのみ使うものだと説明しています。詳細はPermissionsとSandboxの各ページに記載があります。OpenAIは自社での運用方針についてもRunning Codex safely at OpenAIとして公開しています。

つまり、既定の設定であれば書き込み範囲は作業ディレクトリに限定される設計になっており、報告された深刻な削除の多くは、その制限を外した状態で使っていた場面で起きています。逆に言えば、利用者が「速く動かしたい」という理由でサンドボックスと承認ステップを無効化した瞬間に、AIの誤りがそのままファイルシステムの操作として通ってしまう構造になっている、ということです。人間が判断を挟む余地を残すかどうかが、被害の大きさを分ける分岐点になっています。

もうひとつ見落とされやすいのが、削除された事実そのものが記録に残らないケースがあった点です。前掲のIssue #12277では、削除がログに残らなかったと報告されています。何が消えたかを後から特定できないと、復旧の判断も、影響範囲の説明も難しくなります。

士業事務所から見た3つの論点

士業事務所がこのニュースから読み取れる論点は、大きく3つに整理できます。

1つ目は、権限の初期値をどこに置くかという論点です。AIツールに事務所のフォルダを触らせる場合、既定を読み取り専用に寄せておき、書き込みが要る場面だけ範囲を限定して開ける、という運用を採る事務所があります。権限管理の考え方はAIエージェントの権限管理と最小権限運用でも取り上げています。

2つ目は、破壊的な操作に人間の確認を挟むかという論点です。今回報告された事象は、承認ステップを切った状態で顕在化しています。どの操作を自動で通し、どこで止めるかの線引きは、AIエージェントとヒューマン・イン・ザ・ループの設計で整理した論点と重なります。

3つ目は、記録と復旧の担保です。顧客データを扱う事務所では、消えたことに気づけるか、いつの状態に戻せるかが、守秘義務や説明責任の面での論点になります。バックアップの世代管理と、AIが行った操作のログ取得を分けて考えている事務所もあります。AIエージェントが想定外の行動を取る問題そのものは、AI Safety Instituteが指摘したエージェントの逸脱行動でも報告されています。

なお、Codexは開発者向けのコーディング支援ツールであり、税務・労務・法務の書類作成に直接使う場面は限られます。ここで参考になるのは製品そのものではなく、ファイル操作の権限をAIに委ねたときに何が起こりうるかという構造のほうです。

今後の動き

当面の注目点は、OpenAIが公式にどこまで仕様変更を明示するかです。報道ベースでは開発者向け表示の見直しとガードの追加が伝えられていますが、権限プロファイルの既定値そのものが変わるのか、破壊的操作の確認が独立した仕組みとして入るのかは、公式ドキュメントの更新を待つ段階です。Issue #33624のような要望への回答も、その手がかりになります。

同時に、他のAIエージェント製品が同じ論点をどう扱うかも見ておく価値があります。ファイル操作やコマンド実行を伴うエージェントは各社が投入しており、権限の既定値と確認の作法は製品ごとに差があります。事務所としてツールを選ぶ際には、機能の多さより、権限をどこまで細かく絞れるかを比較軸に置く見方が出てきています。

まとめ

OpenAIのCodexで、利用者の明示的な指示なしにファイルが削除されたとする報告が複数上がり、対策が進められていると報じられています。焦点はAIの誤りそのものより、サンドボックスと承認ステップを外した状態で使う設定の側にあります。士業事務所にとっては、権限の初期値、破壊的操作への人間の確認、記録と復旧の担保という3点が、AIツールを入れる際の検討材料になります。

参考文献

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/

引用元: The Decoder

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。