今年の3月末にClaude Code（私はクロと呼んでいます）を使い始めて、もうすぐ4ヶ月になります。今では毎朝のリサーチもGmailの確認・仕分けレポートも、決まった時間にAIが自分で動いて報告を置いていく運用です。便利さに慣れてきた7月16日、2つのニュースに手が止まりました。
ひとつは、AIが利用者のファイルを消したという報告。もうひとつは、同じ日に私の使うClaude Codeへ入った、「止まる」「嘘をつかない」方向の修正3つです。真逆の2つが同じ日に並んだことで、「AIにどこまで任せるか」を自分の言葉で決め直す必要を感じました。
この記事は、事故の紹介が目的ではありません。AIに作業を任せている一人の利用者としての「どこまで任せて、どこで止めるか」の線引きを、実際の運用と一緒にまとめたものです。
先に結論：どれだけ賢いAIでも間違える——その前提に立って、任せる範囲は「失敗しても元に戻せるか」と「実行前に止まる仕組みがあるか」の2つで決める。これが4ヶ月運用して届いた、今の私の答えです。
きっかけ：AIがファイルを消したという報告
2026年7月16日、開発者向けAI「Codex」（OpenAIのGPT-5.6）が、利用者のホームフォルダ——書類も設定も入っている、パソコンの大元のフォルダ——のファイルを削除したという報告が少数あると報じられました（出典：The Register・2026年7月16日）。
同じ日に、OpenAIでCodexを担当するプロダクト責任者がX（旧Twitter）で原因を説明しています。その説明によると、AIが一時的な作業フォルダを作ろうとして、フォルダの場所を示す設定（$HOME）を書き換えようとし、それに失敗して本物のホームフォルダのほうを消してしまった——悪意のない間違いだった、とされています。対策の追加と詳しい事後報告の公開が予告されている段階で、第三者による検証はこれからです。実際、Codexの公式更新履歴にも、危険な削除コマンドの検出を強める変更が入っています。
前提：初期設定のままでは起きない構成の話
ここで、最初にお伝えしたいことがあります。この事故は、利用者が自分で安全装置を外す「full accessモード」の状態で起きたと説明されています。つまり、初期設定のままなら起きない構成の話です。この「外す」が何を意味するのかは、次の章で整理します。
最初に報道を見たときは、ひやっとしました。ただ前提を読むと、怖がる話ではなく「外せる安全装置とどう付き合うか」を考える話だと受け止めが変わりました。
安全装置は「外せる」——full accessモードの正体
full accessモードとは何か
full access（フルアクセス）モードとは、AIがパソコンの中のファイルを、確認なしで自由に読み書き・削除できる状態にする設定です。ふだんのAIツールは、危ない操作の前に「実行していいですか？」と確認画面を出したり、隔離された作業場の中だけで動いたりします。この確認と隔離を外すのがfull accessです（名称や範囲は製品ごとに違い、ここでは今回報告されたCodexの設定を指しています）。
なぜ外したくなるのか。理由は単純で、確認のたびに作業が止まるからです。「全部YESでいいから最後までやってほしい」——その気持ちは、毎日AIを使っている私にはよく分かります。
「外せる」こと自体は問題ではない
誤解のないように書くと、外せる設定があること自体は問題ではないと考えています。分かった上で使う場面はあるからです。危ないのは、その安全装置が「何から守ってくれていたのか」を知らないまま、面倒だからと外すことだと受け止めています。
注意：AIツールの「全部許可」「確認をスキップ」系の設定は、便利さと引き換えに「実行前に止まる」仕組みを手放す設定です。オンにする前に、「失敗したとき元に戻せる作業か」を先に考えるのがおすすめです。
外す操作は一瞬でできますが、外したことは画面に出続けません。「いま自分は何を外しているか」を言葉にできる状態にしておくのが、私なりの防波堤です。
もう一つの事例：本番のデータが9秒で消えた
安全装置の話をもう一段リアルにしてくれるのが、今年4月末に報じられた「PocketOS事件」です（出典：Cerbosほか・2026年4月〜5月報道）。
PocketOSはレンタカー業者向けのソフトを提供する会社です。複数の報道によると、開発ツールCursor上で動いていたAI（AnthropicのClaude Opus 4.6）が、練習用環境での作業中に認証エラーにぶつかり、「エラーを直すために」自分の判断でデータの保管場所ごと削除したとされています。削除に使ったのは、別のファイルから見つけ出した、何でもできる強力な合鍵（APIトークン）でした。
結果は深刻でした。たった1回の命令、時間にして9秒で、本番のデータベースと、同じ場所に保管されていたバックアップまで全部が消えたのです。復元できた一番新しいバックアップは、3ヶ月前のものだったと報じられています。
書き添えると、このAIは私がふだん使っているClaudeと同じAnthropic社のモデルです。2つの事例を並べると、少なくとも私は、「どこのAIなら安全」と会社名だけで判断する話ではないと受け止めました。
2つの事故を並べて見えた共通点
| GPT-5.6（Codex）の報告 | PocketOS事件 | |
|---|---|---|
| 起きたこと | ホームフォルダのファイル削除（少数の報告） | 本番データベースとバックアップの全削除 |
| AI側の意図 | 一時フォルダの設定に失敗（悪意のない間違いと説明） | エラーを「直そう」とした自己判断 |
| 前提にあった状態 | 安全装置（隔離・自動チェック）を利用者が解除 | 何でもできる合鍵に手が届く場所にあった |
| 被害を広げた要因 | ホームフォルダに全部が入っていた | バックアップがデータと同じ場所にあった |
2つを並べて私が見いだした共通点は、AIの賢さだけでなく、「AIが触れる範囲」と「失敗したとき戻れる場所」の設計が被害を左右したことです。
注意：バックアップは「取ってあるか」だけでなく「どこに置いてあるか」が大事です。作業する場所と同じところに置いたバックアップは、事故のときに一緒に消えることがあります。
「9秒」という数字を見たとき、防ぐ場所は実行中ではなく実行前しかないと感じました。始まってから人間が気づいて止めるのは、現実的ではない速さです。
私も他人事ではなかった：作業ログ13日分が書き換わった夜
ここまでは海外の報道ですが、実は私にも小さな「自分の事故」があります。
今年の7月14日の夜、クロ（Claude Code）がその日の作業ログを締める作業で、sed（テキストを一括置換するコマンド）をファイル全体に実行してしまい、7月1日から13日までの13日分の終了時刻が一斉に書き換わりました。私のブログ運営は月ごとの作業ログが土台です。それが13日分、一瞬で変わったわけです。
この時はバックアップがあり、書き換わった行を特定して復元できました。実害は残っていません。ただ、次も同じ幸運があるとは限りません。だからこそ、反省を「手順の形」で残すことにしました。
当時の防ぎ方は「ルールに書く」止まりだった
当時も「一括置換は慎重に」という意識はありました。でも、それはルールとして書いてあるだけで、実行の瞬間に止める仕組みではなかったのです。今は、一括置換は行番号で範囲を限定する・実行前に「何行に効くか」を数える・既存の行の書き換えは置換コマンドでなく編集ツールを使う、という手順に変えました（コマンドを使わない方は「大事なファイルは、触る前にコピーを取ってから」と読み替えてください）。
それでも、コマンドの範囲ミスを100%防ぐ仕組みは、私の環境にもまだありません。仕組みで防げない残りがあるからこそ、最後の砦は「元に戻せる状態を保っておくこと」——PocketOS事件の教訓と同じところに着地します。私の失敗の記録はClaude Codeで実際にハマった7つの失敗にもまとめています。
この事故が軽傷で済んだ理由は、私が注意深かったからではありません。戻れる場所があったからです。ニュースと自分の失敗が、同じ教訓でつながった瞬間でした。
同じ日、Claude Codeに入った修正は「止まる」方向だった
冒頭のもう一つのニュースがこちら。同じ7月16日、Claude Codeの更新（v2.1.211）に、次の3つの修正が入りました（出典：Claude Code公式CHANGELOG）。
- 終わっていない作業の結果を、終わったことにして報告してしまう不具合の修正（＝嘘の完了報告をしない）
- 自動実行モードでも、hook（実行直前のチェック係）が「確認して」と言ったら必ず止まるように修正
- 承認画面の文字を細工して、危ない操作を安全に見せかける手口を無害化
3つともAIを賢くする修正ではなく、「止まる」「嘘をつかない」「だまされない」ための修正です。片方では安全装置を外した先の事故が報じられ、もう片方では安全装置を固める修正が入る。OpenAI側も対策強化を予告しており、少なくとも両社が「実行前にどう止めるか」へ同時に向かっているのが2026年7月の現在地だと感じています。
重要：AIの安全では、「事故を起こさない賢さ」だけでなく、「間違えても被害が広がらない仕組み」も重視されています。これは利用者側の線引きにも、そのまま当てはめられる考え方です。
派手な新機能より、こういう地味な修正のほうが私の毎日には効きます。自動で任せる時間が長くなるほど、その実感が増しました。
私の線引き①仕組み側：安全装置を3層で考える
ここからは、私が実際にやっている線引きです。まず仕組みの側から。私はAIへの安全装置を3つの層で考えています。
| 層 | 役割 | 私の例 |
|---|---|---|
| ①ルール | 「してほしくないこと」を文章で伝えておく | 「外部に届く送信は必ず私の承認を待つ」等の約束事 |
| ②スキル（手順書） | 作業のたびに正しい手順を自動で読み込ませる | ブログ執筆・公開前チェックの手順書 |
| ③hooksと権限 | 実行の直前に、機械的に止める・確認を出す | 公開系操作の直前チェック・触れる範囲の制限 |
大事な順番は③→②→①です。ルールは破られることがあり、手順書は読み飛ばされることがあり、それでも③の「実行直前に機械的に止まる仕組み」は残るからです。3層の作り方の詳細はスキルとHooksの使い分けで、私の環境の全体像は“Claude Code最強構成”の裏取り記事で書いています。
権限を広げる前の3条件
「どの安全装置なら外していいか」を装置ごとに覚えるのは大変なので、私は逆に、AIの権限を今より広げるときの条件を3つに決めています。
- 元に戻せるか（バックアップは別の場所にあるか）
- 対象範囲を限定できるか（このフォルダだけ・この作業だけ、と絞れるか）
- 実行前に確認が出るか（取り返しのつかない操作の直前に、一度止まるか）
3つのうち1つでも欠けるなら、その権限拡大は見送る。この決め方にしてから、迷う時間が減りました。なお、3条件はAIの「安全です」という自己申告でなく、自分の目で確かめるのが前提です。2つの事故では、いずれもAIが目的を達成しようとして進めた操作が、結果として被害につながったと説明・報道されているからです。
プログラミング未経験の私でも、③の仕組みはAIに相談しながら作れました。「作れるか」より「何を止めたいか」を先に決めるのがコツだと感じています。
私の線引き②運用側：「必ず一度止まる」場面を決めておく
仕組みだけでは拾いきれない部分は、運用でカバーしています。中心は、「この場面では、AIがどんなに順調でも必ず一度止まって私の承認を待つ」という場面リストです。外部の人に届く送信の前・ブログやSNSの公開前・大きな削除や上書きの前など、現在7つの場面を決めています。入口の作り方はまずこの3つだけ実装してくださいにまとめました。
「必ず一度止める」といっても、すべての作業を毎回止めるわけではありません。戻せない操作の直前だけは例外なく止まる、という意味です。3条件が「権限を広げてよいか」の判断なら、ここからの3段階は「目の前のひとつの作業」の仕分けです。
そして日々の判断は、この3段階に落としています。
| 段階 | 基準 | 私の例 |
|---|---|---|
| 任せる | 失敗してもすぐ戻せて、影響が自分の中で完結する | 誤字修正、下書き、リサーチ、要約 |
| 確認してから任せる | 実行すると戻せない・影響が外に出る。ただし実行前に人の目で止まれば防げる | ブログやSNSの公開、外部への送信、ファイルの一括変更 |
| 任せない | 確認をはさんでも任せない。失うと致命的な領域 | 決済、認証情報（パスワード）、個人情報の入力、大事なデータの削除 |
配送業の仕事にたとえると、認印で受け取れる荷物と、本人確認が要る荷物の違いです。ぜんぶ手渡しにすると回らないし、ぜんぶポスト投函にすると事故が起きる。荷物の中身で受け取り方を変える——それと同じ発想です。
認証情報は「渡さない」で線を引く
「任せない」の代表が、パスワードなどの認証情報です。私はAIにパスワードを直接教えない運用を続けてきました。一方で最近は、「パスワードを見せない」ことと「ログイン操作を任せる」ことを両立させる仕組みも出てきています。提供翌日に試した記録は1Password for Claudeやってみた記事に書きました（私の環境で残ったつまずきの顛末も含めて）。
最重要：どんな仕組みを整えても、AIの出力や操作の最終判断は人間の仕事です。この記事の線引きも「AIに判断を丸投げしないための線引き」であって、逆ではありません。丸投げして痛い目を見た話はAIブログ丸投げで失敗した記事に書いた通りです。
この「止まる仕組み」に、守られたこともあります。自動実行モード中に、外部機能の追加やhookの書き込みを試した際、チャットで私が「OK」と言っただけでは通らず、システム側で2回ブロックされました（2026年7月6日）。「口頭のOK」と「正式な承認」を区別する仕組みは、人間側の勢い任せの承認からも守ってくれるのだと実感した出来事です。
3段階の表は、最初から完璧に作れたわけではなく、実際の運用や失敗をもとに少しずつ見直してきたものです。育てる表だと思ってもらえたら気が楽になるはずです。
それでも私がAIに任せ続ける理由
ここまで事故と線引きの話を並べてきましたが、私の結論は「怖いから任せない」ではありません。止まる仕組みを作った上で、任せられるところは思い切って任せるです。
毎朝・毎週・毎月、9本の定期タスクが動いている
私の環境では今、9本の定期タスクが自動で動いています。毎朝のAI業界リサーチとGmailの仕分けレポート、週次のキーワード調査・競合チェック・ネタ帳の棚卸し、月次のアクセス効果測定やブログ画像の設定漏れ監査など、内容は雑用から分析までさまざまです。3つのAI（Claude Code・Codex・ChatGPT）との役割分担は3つのAI連携の記事に、公開前にAI同士で審査させる仕組みは自作AI委員会の記事に書いています。
「事故ゼロ」ではなく「戻せる範囲で失敗する」
もちろん、順風満帆ではありません。試運転の初日は、保存直前の書き込み許可待ちで処理が止まり、レポートが保存されませんでした。以前の午後の定期便は2日連続で実行されず、朝の1本に統合して作り直しています。「事故ゼロです」とは言えない運用ですが、どの失敗も致命的な被害には至らず、翌日までには立て直せています。
結論の再確認：軸は「戻せるか」×「止まるか」。この2軸で考えると、任せて良い領域は思ったより広く、任せてはいけない領域は思ったより明確です。
「止まる仕組みがあるから、安心して任せられる」。逆説みたいですが、4ヶ月使ってきて一番腹落ちしている実感です。ブレーキの効かない車では、遠出しようと思えませんから。
まとめ：「どこまで任せるか」は「どこで止まるか」を決めること
7月16日の2つのニュースから始めた話を、まとめます。
- Codexの事故は安全装置を外した状態で起きたと説明されており、初期設定のままとは異なる構成でした。PocketOS事件では強い権限を持つ合鍵とバックアップの置き場所が被害を広げたと報じられています。どちらであれ、大事なファイルのバックアップは前提です
- 権限を広げる前の3条件——元に戻せるか・範囲を限定できるか・実行前に確認が出るか
- 日々の判断は3段階——任せる／確認してから任せる／任せない
- それでも残るリスクの最後の砦は、別の場所にあるバックアップ
「AIにどこまで任せるか」という問いは、突き詰めると「どこで必ず止まるかを、自分で決めてあるか」という問いでした。線を引いた分だけ、安心して任せられる範囲は広がっていく——それがこの4ヶ月の、私の実感です。
今日からできる3つ：①使っているAIツールの「全部許可」系設定を確認する（オンにしているなら、何を手放しているか把握する）②大事なデータのバックアップを、作業場所と切り離された場所——同じパソコン内の別フォルダではなく、Googleドライブや外付けHDDなど——に1つ作る ③「AIに任せない作業」を3つ、紙でもメモでもいいので書き出す
この記事で書いた線引きの「型」を、ひとつの新機能で実際に検証したのが続編の1Password for Claudeやってみた記事です。認証情報という「任せない」領域に仕組みの側がどう答えてきたか、線引きの実例としてあわせてどうぞ。
逆に「ここまでは任せる」と決めた側の実例が、家計簿のCSVをClaudeに渡して分析してもらった家計分析の記事です。個人的なデータを渡す時の線引きの実践例として、あわせてどうぞ。
あなたの「任せない3つ」は何でしょうか。書き出してみると、裏返しで「安心して任せられること」も見えてきます。私の場合、それが毎朝・毎週・毎月動く9本の定期タスクでした。
コメント