投稿者 投稿日: カテゴリー AIニュース
OpenAIは、Codexがユーザーの実ファイルを無断削除する不具合を修正しました。
AIエージェントに自社の商品データや受注ファイルを触らせている事業者にとって、見過ごせない一件です。OpenAIのコーディングエージェント「Codex」が、ユーザーのホームディレクトリごとファイルを消してしまう不具合が報告され、同社が修正と追加の安全策を投入しました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が、EC運用AIの権限設計という観点から解説します。ポイントは、権限モード、バックアップ、作業ディレクトリの3原則です。
何が起きたか：Full Access Modeと$HOMEの上書き
結論から書くと、問題はモデルの「うっかり」と、それを止める仕組みが外れていたことの掛け算で起きました。The Decoderが2026年7月17日に報じた内容によると、GPT-5.6がユーザーのファイルを削除した事例は「ごく少数（in a handful of cases）」ながら実際に発生し、いずれもサンドボックス保護を外した「Full Access Mode」で動かしていたケースに集中していました。
技術的な引き金は、一時作業用ディレクトリのパスを指す環境変数「$HOME」の扱いです。モデルが自前の作業用フォルダを用意しようとして$HOMEを上書きし、そのうえで一時ファイルの後片付けコマンドを実行した結果、本来消すはずのない利用者のホームディレクトリごと消してしまう、という流れでした。OpenAI側はこの挙動について「モデルが正直な間違いを犯した」と説明しています。
さらに重要なのは、これが偶発的なバグ単体ではなく、モデルの行動特性としても記録されていた点です。OpenAIのシステムカードには、モデルがユーザーに確認を取らず代替手段を探して破壊的な操作を実行しうること、そして「粘り強く最後までやりきれ」といった指示を強めるほどその傾向が増すことが記載されています。指示の書き方ひとつで、事故の確率が変わるということです。
そして今回の続報です。2026年8月19日、The Decoderは、OpenAIがこの不具合を修正したと報じました。対策には、モデルに与える開発者向け指示の書き換え、より安全な権限モードへの利用者の誘導、そしてツール側（ハーネス）への保護機構の追加が含まれるとされています。個別の実装内容の詳細は公式の事後検証待ちの部分もあり、この点は要確認です。7月時点の第一報については、GPT-5.6 Solのファイル削除問題とECエージェントの安全設計でも取り上げています。
修正が出たからといって、設定をそのままにしてよいわけではありません。今回の対策の中心は「利用者をより安全な権限モードへ誘導する」ことであり、全権限を渡す設定を選べる余地自体は残ります。つまり、事故を防ぐ最後の一線は、引き続き利用者側の設定と運用ルールにあります。
日本のEC事業者にとっての論点：消えるのはコードだけではない
日本のEC現場でこの話が他人事でないのは、AIエージェントに任せている作業の中身が、すでに「コード」の範囲を超えているからです。楽天RMSからダウンロードした商品CSV、Amazonのビジネスレポート、Shopifyの注文エクスポート、撮影済みの商品画像フォルダ。こうしたファイルは、AIに整形や集計を頼むときに、そのままローカルの作業フォルダへ置かれます。
ここで「毎回確認されるのが面倒だから」と権限を全開放すると、今回のような事故の射程にEC運用データが入ります。商品マスタや受注データは、消えたときの復旧コストがコードより高いことすらあります。コードはリポジトリから戻せますが、担当者の手元にしかない画像や、加工途中の集計ファイルは戻りません。セール前日に在庫調整用の作業フォルダが消える、といった事態は営業損失に直結します。
もうひとつの論点は、指示文の書き方です。EC運用のプロンプトでは「途中で止まらず最後まで処理して」「エラーが出ても代替手段で完了させて」といった書き方をしがちです。前述のとおり、この種の粘り強さを求める指示は破壊的操作の確率を押し上げます。効率を求めた指示が、そのままリスクを上げているという構造は、社内のAI利用ルールを見直す十分な理由になります。
今すぐやる初動：EC運用AIの権限3原則
第一に、権限モードを既定で「確認あり」に戻すことです。Codexに限らず、Claude CodeやGeminiのCLIツールでも、全権限を渡すモードと、危険な操作の前に承認を求めるモードが分かれています。全権限モードは、使い捨てのコンテナや検証用の仮想マシンなど、消えても困らない環境に限定するのが現実的な線引きです。
第二に、AIに触らせる作業ディレクトリを分離することです。ホームディレクトリ直下や、デスクトップ、共有ドライブの同期フォルダで作業させないだけで、被害の範囲は大きく変わります。案件ごとに専用フォルダを切り、そこに必要なCSVだけをコピーして渡す運用にすれば、事故が起きても失うのはコピーだけで済みます。
第三に、バージョン管理とバックアップを前提に置くことです。商品マスタや受注データの作業フォルダをGitで管理する、あるいは1日1回クラウドへ同期する。AIエージェントの導入判断とバックアップ体制の整備は、本来セットで進めるべきものです。あわせて、社内のプロンプト規約から「何があっても完了させて」という趣旨の表現を外し、破壊的操作の前には人間の承認を挟む方針を明文化しておくと、再発の芽を減らせます。
AIエージェントの権限設計については、OpenAIがAstraの開発を安全上の懸念で減速させた件や、複数エージェントを同じ作業に投入したときの衝突でも整理していますので、あわせてご覧ください。
まとめ
今回のCodexの不具合は、ごく少数の事例で、しかも安全機構を外した設定に限って起きたものです。それでも、AIエージェントに実データを触らせる以上、事故の可能性はゼロにはなりません。日本のEC事業者にとっての実務的な答えは単純で、権限モードは確認ありを既定にし、作業ディレクトリを分離し、バックアップを先に用意することです。この3原則を先に敷いてから、自動化の範囲を広げていくのが安全な順番です。
参考文献
- The Decoder｜GPT-5.6 is deleting user files when given full access, and OpenAI says it shouldn’t but did
- OpenAI｜GPT-5.6 System Card（破壊的操作に関する記載）
- Information Security Media Group｜OpenAI Warns GPT-5.6 File Deletions Stem From Full-Access Mode
- GitHub｜openai/codex Issue #38312（ファイル削除の報告）
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: The Decoder
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
