AIエージェントの安全対策入門｜サンドボックス・承認・権限設計の基本

AIエージェントにファイル編集やコマンド実行を任せる場面が増えると、「どこまで自動で許可してよいのか」「何かあったときに被害をどこまで抑えられるのか」が運用上の課題になります。

承認ダイアログで1回ずつ確認する運用は安全に見えますが、長時間のセッションでは確認に慣れてしまい、見落としが起きやすくなります。一方で、すべてを自動承認にすると、意図しないコマンドの影響が大きくなります。

この記事では、AIエージェントの安全対策を「承認」「サンドボックス」「信頼境界」「レビュー」の4つの層に整理し、実務で使える最小権限の設計チェックリストを紹介します。根拠は、GitHub Copilot と VS Code の公式ドキュメント（2026年10月12日時点）です。

この記事で行うこと
前提条件・対象読者
安全対策の4つの層
承認だけに頼ると何が困るのか
最小権限で設計する4つの観点
アンチパターンと推奨設定の対比
サンドボックスでは防げないもの
隔離の強さを使い分ける
導入チェックリスト
よくある質問
まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

エージェントの安全対策を4つの層に分けて理解する
承認だけに頼る運用の限界を整理する
ファイル・ネットワーク・認証情報・外部ツールの権限を、最小限に設計する
避けたい設定（アンチパターン）と、推奨する設定を対比で確認する
導入時のチェックリストを手元に持つ

前提条件・対象読者

項目	内容
情報の確認日	2026年10月12日
主な対象	ターミナルコマンドやファイル編集を実行する、コーディングエージェント（Copilot CLI、VS Code のエージェントなど）
想定読者	エージェントに作業を任せ始めた個人開発者、チームの運用ルールを作る方
根拠にした一次情報	GitHub Docs（クラウドとローカルのサンドボックス、ローカルサンドボックス、クラウドサンドボックスの課金）、VS Code Docs（Trust and safety、Manage approvals and permissions、Sandbox Agent Host sessions）

> 補足：この記事は、ツール固有の細かい設定手順ではなく、考え方の整理が中心です。GitHub Copilot のサンドボックスの具体的な設定手順は、別記事「GitHub Copilotローカルサンドボックスの設定方法｜CLI・VS Code」で解説しています。

安全対策の4つの層

VS Code の公式ドキュメントでは、エージェントを制御する仕組みを複数の層に重ねる「信頼モデル」として説明しています。実務で使いやすいように、次の4層で整理します。

層	何を制御するか	具体例
承認（Approvals）	操作を自動で実行するか、人が確認するか	権限レベル、ツール承認、ターミナルコマンドの自動承認
サンドボックス	承認後のコマンドがアクセスできるファイルとネットワークの範囲	OSレベルの隔離で読み書きできるパスと通信先を制限
信頼境界	何を信頼して動かすか	ワークスペース、拡張機能の発行元、MCPサーバー、通信先ドメイン
レビュー	変更をコードベースへ取り込む前の人間による確認	差分の確認、チェックポイントでの復元、コミット前のレビュー

ポイントは、承認とサンドボックスが別の防御層だということです。VS Code の公式ドキュメントでも、Allow all や Autopilot で承認プロンプトを省略しても、有効なサンドボックスは引き続き端末のファイルとネットワークのアクセスを制限すると説明されています。

承認だけに頼ると何が困るのか

VS Code の公式ドキュメントは、承認ベースのセキュリティの限界を次の4点として挙げています。

課題	内容
承認疲れ	何度も承認を繰り返すうちに、内容への注意が下がる。特に長いセッションで起きやすい
解析の限界	自動承認ルールは、ベストエフォートのコマンド解析に基づく。シェルのエイリアス、引用符の連結、複雑なシェル構文は、ルールをすり抜ける可能性がある
プロンプトインジェクション	ファイル、ツールの出力、Webページに悪意ある指示が含まれ、エージェントを誘導しようとする場合がある
外部サービスへの意図しない操作	ネットワークにアクセスできるエージェントは、クラウドリソースの作成、インフラ設定の変更、リモートへのpush、デプロイや課金を伴うAPI呼び出しなど、元に戻しにくい操作を実行しうる

これらは悪意のある攻撃だけでなく、悪意のない「意図しない操作」でも起こりうる点が重要です。そのため、承認に加えて「万が一承認してしまっても、被害範囲が限定される」状態を作ることが推奨されます。

最小権限で設計する4つの観点

1. ファイルアクセス

作業に必要なディレクトリだけに書き込みを許可し、ほかは読み取り専用または拒否にします。

GitHub Copilot CLI のローカルサンドボックスは「deny-by-default（許可しない限り拒否）」で、パスには次の3段階の権限があります。

権限	内容
Read/Write	読み取りと変更ができる
Read-Only	読み取りのみ。変更はできない
Denied	読み書きとも不可。より広い親フォルダが許可されていても拒否される

SSH鍵、シェルの設定ファイル、ほかのプロジェクトのフォルダなど、エージェントに触らせたくない場所は、明示的に拒否しておくと安全です。

2. ネットワークアクセス

外部への通信を、必要な宛先だけに絞ります。

VS Code の公式ドキュメントによれば、サンドボックスを有効にしても外向き通信は既定で許可されます（chat.agent.sandbox.network.allowNetwork の既定は true）
通信を絞るには、許可ドメイン（allowedDomains）や拒否ドメイン（deniedDomains）を設定します
許可した通信先でも、データの読み取りだけでなく、操作の実行も可能です。公式ドキュメントでも「許可した宛先では、読み取りだけでなくアクションも実行できる」と注意されています

3. 認証情報

エージェントに実際のトークンを渡さない設計が有効です。

GitHub Copilot CLI のローカルサンドボックスでは、Git と gh の認証は、サンドボックス内にはプレースホルダーを渡し、ローカルプロキシが承認済みのHTTPS宛先にだけ実際の認証情報を差し替えます
APIトークンなどの環境変数も、同様にマスクできます
一方で、ファイル内に書かれた資格情報や、マスク対象外の環境変数は保護されません。.env などのファイルは、拒否パスに指定することが重要です

4. 外部ツール（MCPサーバー、言語サーバー）

ローカルのMCPサーバーや言語サーバーは、サンドボックス内で動かすことができます（GitHub Copilot の既定は有効）
リモートのMCPサーバーは自分のマシンの外で動くため、ファイルシステムのポリシーでは制限できません。接続先の信頼性は、信頼境界として別に判断します
VS Code では、ワークスペース内のMCP設定は Workspace Trust を継承し、それ以外のソースのサーバーは、個別の信頼判断を求められる場合があります

アンチパターンと推奨設定の対比

❌ 承認をすべてスキップして、サンドボックスもなし

権限レベル: Allow all（または Autopilot）
サンドボックス: オフ

この状態では、エージェントが実行するコマンドは、あなたのユーザーアカウントと同じ権限で動きます。GitHub の公式ドキュメントにも、サンドボックスがオフの間は、コマンドは「あなたがアクセスできる場所のどこでも読み書き・削除でき、マシンから到達できるあらゆるネットワークに接続でき、認証情報も制限なく使える」と記載されています。

⭕ 承認の自動化とサンドボックスをセットで使う

権限レベル: プロジェクトで必要な範囲の自動承認
サンドボックス: オン
ファイル: 作業ディレクトリのみ書き込み可、機密パスは Denied
ネットワーク: 必要な宛先のみ許可
認証情報: マスクを利用

VS Code の公式ドキュメントでは、サンドボックス内で実行されるターミナルコマンドは、既定で確認なしに自動承認される動作になっています。これは、すでに制御された環境で動いているためです。承認の手間を減らしつつ、被害範囲を限定する考え方です。

❌ 「ブロックされたから」とすぐサンドボックスを無効にする

コマンドがブロックされたとき、サンドボックスを丸ごと無効にしてしまうと、以降のコマンドも広いアクセスで動くことになります。GitHub の公式ドキュメントでも、セッション全体でサンドボックスを無効にすると、ブロックされたコマンドだけでなく、後続のコマンドにも広いアクセスが与えられると注意されています。

⭕ 必要なアクセスだけを許可する

まず /sandbox policy のような機能で実効ポリシーを確認し、本当に必要なパスやホストだけを許可します。一度限りのバイパスを求められた場合も、広いアクセスを許容できるときだけ承認してください。

サンドボックスでは防げないもの

サンドボックスは強力ですが、万能ではありません。公式ドキュメントに記載されている限界は次のとおりです。

仮想マシンやユーザーアカウントの境界ではなく、単独のセキュリティ境界でもありません。エンドポイントセキュリティの代わりにもなりません
ネットワーク許可、追加パス、開発ツールの設定やキャッシュへのアクセス、サンドボックス外での実行を許可する設定は、隔離を弱めます
明示的に注入した認証情報は保護されません
プロセスを起動しない組み込みツール（ファイルの読み取り・編集など）は、サンドボックスの対象外で、各ツール独自の権限チェックで制御されます
完了済みのターミナルコマンド、ネットワークリクエスト、デプロイ、外部サービスへの変更は、リクエストを止めたり、ワークスペースのファイルを復元したりしても元に戻りません

そのため、サンドボックスに加えて、コミット前の差分レビュー、不要な権限を持たせない認証情報の発行、重要な環境（本番など）へ直接アクセスさせない運用が必要になります。

隔離の強さを使い分ける

公式ドキュメントでは、隔離の方法が複数あることを説明しています。

方式	特徴	注意点
ローカルサンドボックス	OSレベルでプロセスのファイルとネットワークを制限する軽量な隔離	仮想マシンではない。設定によって弱まる
Dev Container	プロジェクトのコンテナ内でエージェントとツールを動かす	ホストへのアクセスやネットワークを自動では遮断しない。マウントや権限の設定次第
クラウドサンドボックス	GitHub がホストする隔離されたLinux環境で実行し、停止後に状態を再開できる場合がある	パブリックプレビュー中で仕様変更の可能性あり。クラウドサンドボックスのみ使用量課金

たとえば、普段の開発では軽量なローカルサンドボックスを使い、リスクの高い作業（信頼できないリポジトリの調査など）は、よりしっかり隔離された環境を選ぶ、といった使い分けが考えられます。

導入チェックリスト

エージェントを使い始める前に、次の項目を確認してください。

[ ] サンドボックスは有効か（既定でオフのツールが多いため、実効ポリシーを確認する）
[ ] 書き込みを許可するパスは、作業ディレクトリに限定されているか
[ ] SSH鍵、.env、ほかのプロジェクトなどの機密パスを拒否しているか
[ ] 外向き通信を、必要な宛先に絞れているか
[ ] Git や API の認証情報は、マスクされているか。トークンに必要以上の権限を与えていないか
[ ] MCPサーバーの接続先と提供元を確認したか
[ ] Allow all や全体の自動承認を、必要以上に有効にしていないか
[ ] コミットやマージの前に、人間が差分をレビューする運用になっているか
[ ] 会社で利用する場合、管理者設定（必須のサンドボックスなど）との整合を確認したか

よくある質問

サンドボックスを有効にすれば、承認は不要ですか？

いいえ。承認とサンドボックスは別の防御層です。サンドボックスはコマンドが触れる範囲を制限しますが、組み込みツールや外部サービスへの操作などは別途の権限チェックや承認が必要です。両方を組み合わせることが推奨されています。

プロンプトインジェクションは、サンドボックスで防げますか？

防げるのは、インジェクションされた指示で実行されたコマンドの「被害範囲」を制限することです。指示に従わせること自体を防ぐわけではありません。VS Code の公式ドキュメントでも、ツール承認とトラストバウンダリが、この対策として挙げられています。

個人利用でも、ここまで設定する必要がありますか？

作業内容によります。たとえば、信頼できる自分のリポジトリだけで作業するのか、外部のコードやWebページを読み込むのかで、リスクは変わります。まず、サンドボックスを有効にして実効ポリシーを確認するところから始め、必要に応じて絞り込むのがおすすめです。

他社のAIエージェント（Codex、Claude Code など）でも同じ考え方は使えますか？

「最小権限」「承認とサンドボックスの併用」「信頼境界」という考え方は、ツールが違っても共通して活用できます。ただし、具体的な機能名や既定値はツールごとに異なります。この記事では GitHub Copilot と VS Code の公式ドキュメントのみを根拠にしているため、ほかのツールを使う場合は、それぞれの公式ドキュメントを確認してください。