きっかけ

本番環境がHerokuのプロジェクトを担当しているが、使うのはこれが初めてだった。

デプロイが近づいてきたので手順を確認しようと、次の内容でClaudeに質問した。なお、この時点でログ取得のために heroku git:remote -a <アプリ名> はすでに実行済みだった。

herokuへのデプロイを行うのに、次のコマンドで問題ない？
heroku git:remote -a <アプリ名>  # 初回のみ
git push heroku master
heroku run rails db:migrate      # 必要な場合のみ

すると、こんな感じの回答が返ってきた。

問題ありません、次のコマンドを実行しますか？

git push heroku master

これは単に手順を確認したかっただけで、実行してほしいわけではなかった。幸い返ってきた内容にちゃんと目を通したので事なきを得たが、もしそのままEnterを押していたら、意図しない本番反映が走っていた。

質問したつもりが、いつのまにか実行確認のフローに乗っていて、普段のやり取りと同じ感覚でつい反射的にEnterを押しそうになった。今回はリスクを回避できたが、一歩間違えれば本番環境に影響が出るところだった。

「AI」と「本番環境にコマンドを送れる環境」の組み合わせは危険

実害はなかったが、ゾッとした。危険だと感じたポイントは以下の通り。

• 質問しただけのつもりが、AI側は「コマンドを実行してよいか」の確認モードに入っていた
• 手元のシェルはすでに本番Herokuアプリのgit remoteが登録済みで、git push heroku master が通る状態だった
• 「確認しますか？」に対するEnterは、日常的に大量の低リスクな確認(ファイル読み取りなど)に対して無意識に押していることが多く、同じ調子でEnterしていたら内容の重大性でブレーキがかからなかった可能性が高い

要するに、AIが提案してくる確認プロンプトへの反応は、放っておくとリスクの大小によらず均質になりがちなのが危険の本質だと思う。今回はたまたま踏みとどまれただけで、次も同じように気づける保証はない。人間側の注意力だけに頼るのは無理があるので、環境を分離することにした。

対策: WSL2のディストリビューションを分離する

現在はWSL2を使っているので、まずはディストリビューションを開発用とデプロイ用の2つに分けることにした。

• 開発用: Claude Codeなどのエージェントを常用する。Herokuの本番アプリへのgit remoteやcredentialは置かない。誤って heroku git:remote してしまってもpushが通らないよう、そもそも認証情報を入れない
• デプロイ用: Heroku CLIとログイン情報だけを置く。AIエージェントはインストールしない。ここでコマンドを打つときは「今から本番を触る」という意識に自然に切り替わる

実装としては wsl --export / wsl --import で今の開発環境ディストリビューションを複製し、デプロイ用の方からは以下を徹底する。

# デプロイ用ディストリビューション側
# - AIエージェント関連のパッケージ/CLIは一切入れない
# - .netrc や heroku credential 以外の秘匿情報は持ち込まない

コード変更自体は開発用ディストリビューションで行い、デプロイのタイミングだけデプロイ用ディストリビューションに切り替えてpushする、という運用にする。

課題

結局デプロイ用ディストリビューションでも人間はコマンドを打つ

AIを排除しただけで、デプロイ用ディストリビューションでのコマンド実行自体は人間が担当する。「本番を触っている」という意識づけにはなるが、ヒューマンエラー自体をゼロにする対策ではない。

コードの受け渡しが増える

開発用で作った変更をデプロイ用に持っていく手順(git pushやリモート経由の取得など)が一手間増える。ここが面倒になって結局同じディストリビューションで済ませたくなる誘惑と戦う必要がありそう。

サプライチェーン攻撃には無力

デプロイ用ディストリビューションであっても、そこで実行するコード自体(依存パッケージのpostinstallなど)が悪意を持っていれば意味がない。あくまで「AIの提案を無自覚に実行してしまう」経路を塞ぐための対策であって、それ以外の脅威はカバーしていない。

同じように「本番環境にコマンドを送れる環境」でAIエージェントを使っている人は、一度自分の運用を見直してみることをおすすめしたい。