AIコーディングエージェントはコードを壊すのか？Claude Code、Codex、Copilot、Gemini CLIの安全リスクはどれほど大きい？

今週の判断：まず変更範囲と実行権限を絞る

Anthropicは、Claude Codeのサンドボックス利用により、社内利用で許可確認のプロンプトが84%減ったと報告しています。ただし、これは同社内の利用結果であり、コードの安全性を保証する数値ではありません。AIコーディングエージェントはコードを壊すことがあり、権限があれば危険なコマンドも実行できます。今週は、ツール名で安全性を決めず、作業範囲を限定し、差分を確認してから反映してください。(Anthropicのサンドボックス説明)

Claude Code、Codex、Copilot、Gemini CLIでコードを変更しており、どこを人が確認すべきか知りたい開発者向けです。
エージェントにファイルやターミナルへのアクセスを許可するか検討中のチーム責任者にも役立ちます。
隔離した開発環境や自動化の導入を考えているエンジニア、運用担当者も対象です。

失敗の種類を分けて考える

「コードが壊れる」には、性質の異なる問題が含まれます。修正内容が要件とずれる、対象外のファイルまで変更する、依存関係やテストの前提を見落とす、といった誤変更は、差分確認とバージョン管理があれば戻せる場合があります。

一方、ターミナル操作でデータを削除したり、秘密情報を外部へ送ったりした場合は、コードの巻き戻しだけでは解決しません。実行コマンド、アクセス可能なファイル、外部通信、認証情報を別々に制御してください。OpenAIのエージェント実行環境に関するセキュリティ資料も、環境の分離や権限の制限を安全設計の要素として説明しています。

たとえば「ログ出力を直す」という依頼が、エージェントの判断で設定ファイルの変更に広がり、さらにテスト用コマンドの実行へ進むことがあります。最初の依頼が小さくても、変更範囲と実行可能な操作を確認しないまま進めると、影響が連鎖します。

4ツールの権限境界を比べる

下表は公式資料で確認できる仕組みの比較です。製品の版、起動方法、設定、組織ポリシーで挙動は変わります。特定の作業を同じ環境で比較した根拠がないため、安全性の順位ではありません。

ツール	ファイル・コマンドの扱い	運用で見る点
Claude Code	権限設定に加え、サンドボックスでファイルやネットワークへのアクセスを制御できます。	CLIの権限関連資料を参照し、許可範囲を実際の設定で確認します。
Codex	実行環境の設定により、ファイル操作やネットワーク利用などの境界を定めます。	環境のセキュリティ資料と、利用する画面・実行方式の設定を照合します。
Copilot	エージェントモードでは、コード編集に加えてターミナルコマンドを扱う場合があります。	エージェントモードの説明と、リスク軽減策を確認します。
Gemini CLI	CLIからツールを実行でき、サンドボックスは実行環境や設定に応じて利用します。	サンドボックスの公式説明を読み、起動時に有効かを確認します。

確認操作の目安を、製品の優劣ではなく運用上の注意として整理すると次の通りです。

操作	注意の目安	理由
作業ツリー内の小さなコード編集	差分を見て判断	変更範囲を限定しやすく、版管理から復元できる場合があります。
依存関係の更新や広範囲の書き換え	追加レビューが必要	既存の互換性やプロジェクト固有の制約に影響します。
削除、外部送信、認証情報を扱うコマンド	実行前の明示確認が必要	取り消しが難しく、漏えいやデータ損失につながる可能性があります。

リスクが上がる条件を見極める

危険度は名称ではなく、タスクの影響範囲、リポジトリの機密性、コマンド権限、外部ネットワークへの接続、人によるレビューの強さで変わります。公開サンプルの小さな修正を、書き込み範囲を限定した環境で行う場合は比較的制御しやすい一方、秘密情報を含むリポジトリで広い権限を与え、実行結果を確認せずに反映する運用は避けるべきです。

Claude Code、Codex、Copilot、Gemini CLIの各設定で「確認が表示されるか」だけを見てはいけません。許可済みの操作が何か、作業ディレクトリ外へアクセスできるか、ネットワークを使えるかを確認します。Codexの実行環境に関する案内も、実行方法や設定に応じた境界の確認に使えます。

今週試すリスク低減の手順

作業前に状態を保存します。 バージョン管理に未保存の変更がないか確認し、必要なら専用ブランチを作ります。
依頼を狭く書きます。 変更対象、変更してはいけない箇所、実行してよいテストを明記します。
必要最小限のアクセスだけ許可します。 作業対象外のファイル、機密情報、外部通信へのアクセスが不要なら無効にします。
高影響のコマンドを止めます。 削除、依存関係の大規模更新、外部送信、秘密情報の処理は、実行前に内容と対象を人が確認します。
差分とテスト結果を別々に確認します。 テストが通っても、意図しない変更や秘密情報の混入がないとは限りません。
レビュー後に統合します。 変更の理由と影響範囲を確認し、問題があればブランチ単位で戻します。

この手順はどのツールにも適用できる基本策です。サンドボックスや承認設定などの機能は製品ごとに異なります。公式資料を確認し、実際の設定でファイル範囲とコマンドの確認方法を試してください。

誤操作を隔離し、回復できる範囲を決める

独立した作業ブランチや使い捨ての開発環境は、誤ったコード変更を本番の作業ツリーへ持ち込まないために役立ちます。ただし、環境を分けただけでは、渡した認証情報の保護や外部通信の制限、最終差分の確認は代替できません。隔離は被害範囲を狭める策であり、権限管理の代わりではありません。

導入前には次の条件で判断してください。

変更対象を限定でき、すぐに差分を戻せるなら、既存の開発環境で小さく試します。
機密情報や共有リソースに触れるなら、アクセス権を分離し、外部通信と認証情報の扱いを先に定めます。
削除や外部送信を含む操作を自動化するなら、実行前の人による確認を必須にし、制限できない場合は自動実行を避けます。
失敗時に作業環境ごと廃棄して再作成したいなら、隔離環境を候補にします。ただし、提供条件や実際の分離方式を事前に確認してください。VPSSparkのサービス概要も確認し、実際に利用できる環境や提供条件を問い合わせてから判断してください。

今のローカル環境は導入が手軽ですが、個人の作業領域や認証情報とエージェントの実行範囲が重なることがあります。Mac環境を短期で借りて検証する方法も選択肢ですが、環境を分けるだけでリスクが消えるわけではありません。作業を戻せるか、権限を絞れるか、秘密情報を分離できるかを先に比べてください。VPSSparkの環境について確認したい場合は、問い合わせ窓口で提供条件を確認し、仕様が目的に合う場合に限って試すのが適切です。