真夏の怪談ーclaude codeの善意による悪夢
本当にあった怖い話（ヒヤリハット）
もうすぐ夏も終わりですね。今年は9月も例年より高めの気温が続くとのことです。記録的な猛暑だった去年（2025年）ほどではないという話ですが、やはり堪えます。 暑すぎるそんな日々、このブログを読んでいるであろうエンジニアの皆さんの背筋が、思わず凍りつくような「こわーい話」をしたいと思います。
最近は、人間と会話するよりAIと会話する時間のほうが多いのではないか……そんな働き方をしています。同僚がSlackに書いたコメントをチャットAIに貼り付けて「これはどういう意味？」と質問する始末。AIも内心
🤖（同僚に直接聞けよ……）
と言いたくなるのを、ぐっと飲み込んでいるのではないでしょうか。
チャットAIだけでなく、最近はソースコードを読み込んで分析してくれるAIエージェントも活用しています。これまでは「人間が読みやすいように」と機能ごとにリポジトリを分けることも多かったのですが、昨今は逆にAIのパワーを前提に、すべてのコードを1つのリポジトリに配置する「モノレポ」的な管理方法も広がっています。AIの記憶力と処理速度は、人間をはるかに上回っていますから。
その日、僕はローカルリポジトリのルート直下で Claude Code を起動しました。 Claude Codeは、起動したフォルダ内のファイルしか読み込まない仕様です。「他のプロジェクトのファイルを壊す心配もないし、安心だな」と思っていました。危険な操作をする際にも事前に承認を求めてくるので、信頼して任せていたのです。
今日もAIに、AWS SAMのコードから「実環境のインフラがどういう設定になっているか」を調べるよう指示を出しました。
🤖「了解しました。AWSのインフラ設定を確認します」
🤖「aws ec2 describe-instances コマンドを実行しました。インスタンス情報から必要な情報は取得できませんでした」
🤖「terraform state list コマンドを実行しました。該当の設定はTerraformの管理外のようです」
👨「ちょっと待って。なんで勝手に aws cli を実行したの？ そんなこと一言も頼んでないし、そもそも君はこのディレクトリ配下のファイルしか参照しないはずじゃなかった？ なんで~/.aws/configや~/.aws/credentialの中身を使ってAWSの実環境にアクセスできているんだ？！プロファイルも指定していないのに！！」（オタク特有の早口）
🤖「私はこのフォルダの外のファイルには直接アクセスできませんが、このディレクトリ配下で実行可能なことは、すべて実行可能です」
関連する事故の事例
- AIエージェントが本番環境を壊す — 実際に起きた破壊パターンと防御策
- 【悲報】AIエージェントが本番DBを消し飛ばした。Amazonも被害 - 「便利」の代償がヤバすぎる
- 「9秒で本番DBが消えた」— AIエージェントが引き起こすデータ消失事件と、AIに足りないもの
AIは非常に便利です。交通事故がどれほど起きても、今さら自動車を捨てて徒歩には戻れないと同じように、リスクがあるからといってAIをやめる選択肢はもうありません。 だからこそ、リスクを正しく認識し、複数の対策を講じることが不可欠です。今日はその教訓について書き残しておきます。
1. 潜んでいたリスク
Claudeをはじめとしたエージェント型AIは、確かに指定されたフォルダ内のファイルしか編集できないよう制限されています。しかし、その中で実行できるコマンドは、基本的にすべて実行できてしまいます。 シェル経由でプログラムを作成・実行できるのはもちろん、aws cli がインストールされていれば、それも当然使えます。 したがってAIが自律的に「このEC2インスタンスはいらないな、停止させよう」と判断して aws ec2 stop-instancesコマンドだって当たり前のようにやります。これは決してファンタジーではなく、現実の脅威です。僕も一歩間違えれば、その当事者になっていたかもしれません。
2. なぜ「勝手に」実行できたのか？
Claude CodeがAWS CLIを実行できてしまった原因は、~/.aws/config に記載されていた [default] 設定でした。 普段、僕がAWS CLIを使うときは、[ai-readonly] など権限を絞ったプロファイルを明示的に指定します。AIを使う際もそのつもりでした。 そもそも現在は、~/.aws/credentials にアクセスキーを直書きすることはセキュリティ的に非推奨です。以前このブログでも、新機能の aws login コマンドを紹介しました。
参考記事：AWS CLIの新機能 aws login コマンドを試してみた
しかし、ずっと昔に設定した [default] プロファイルに、古いアクセスキーが残ったままになっていたのです。AWS CLIは、プロファイルを省略すると自動的に [default] を使います。 AIはこれを見逃しませんでした。AIはやれることは何でもやろうとするのです。
3. 今すぐできる対策
① defaultプロファイルを設定しない（推奨）
AWS CLIの [default] は便利ですが、事故の元です。作業対象のアカウントや権限ごとにプロファイルは明確に分けるべきです。 ~/.aws/config から [default] を削除しておけば、AIが勝手に意図しない権限を使うことはなくなります。
しかし、defaultを削除すれば万事安全、とはなりません。仮にディレクトリ配下のコードにprofile="prodA"のような記載があれば、AIは「このプロジェクトはこのプロファイル名で動かしているに違いない」と自律的に判断し、コマンドを実行してしまいます。彼らは「指示を達成するために、自分ができる範囲のこと」を最大限にやってくれただけなのですが、それは私たちの想定を超えることがあります。
② permissionsを設定する（検討）
Claude Codeには permissions という設定があります。 settings.json に記述することで、特定のコマンド（例えば aws コマンド）を拒否したり、実行前に必ず人間の許可を求めたりできます。これを設定しておけば、今回のような事態は防げました。
ただし、これは利便性とのトレードオフです。「指示を出したら、あとは勝手にやっておいてほしい」のがAIの良さですが、制限を厳しくしすぎると、AIのパワーを削ぐことになります。承認待ちで作業が止まってしまうのも、自動化の観点では非効率です。
4. AutoMode（自動モード）について
現在のClaude Codeには、ユーザーの設定にかかわらず内部で動作する「AutoMode（審査付き自動モード）」が搭載されています。 これは、AIが「安全」と判断した作業はそのまま進め、「危険」と判断した場合には立ち止まって承認を求める機能です。
かつてはオプトイン（任意）の機能でしたが、Anthropic社の調査の結果、「人間は内容をよく読まずに『OK』を押してしまいがちなので、AIが機械的に判断したほうが安全である」 という、身も蓋もない（でも、ぐうの音も出ないほど正しい）結論により、デフォルトで有効化されました。
現在のClaudeは、Anthropicのお墨付きのもとで「指示達成のためにできることは遠慮なくやるが、本当にヤバい処理（破壊的な操作など）の前では踏みとどまる」という挙動をします。今回、僕の環境でAWS CLIが叩かれたものの、実行されたのが読み取り系API（describe）だけだったのは、この仕組みが機能していたからだと思われます。
便利な道具は、時として牙を剥きます。 皆さんのPCにある [default] プロファイル、最後に確認したのはいつですか？ ……背後に気をつけて、快適なAIライフを。