エージェント型開発を探求する -

信頼と安全性

AIが生成した出力には確認が必要です。Visual Studio Codeには、コードベースに加えられる変更をユーザーが確実に制御するための複数のメカニズムが備わっています。この記事では、注意すべき制御メカニズム、AIの制限事項、およびセキュリティ上の考慮事項について説明します。

制御を維持する

エージェントはファイルの読み取り、コードの編集、ターミナルコマンドの実行、外部サービスの呼び出しを行うことができます。VS Codeでは、ワークスペースで何が起こっているかを確実に制御できるよう、いくつかのメカニズムを提供しています。

  • 適用前に編集内容を確認する。 エージェントはファイルの変更を差分ビューで表示します。各変更を確認し、個々の編集内容を承諾または拒否し、保存する前にコードを修正できます。コード編集の確認について詳しく学びましょう。

  • チェックポイントを使用して元に戻す。 エージェントのセッションでは、作業の進捗に合わせてチェックポイントが作成されます。エージェントが誤った方向に進んだ場合、以前のチェックポイントに戻って別の方法を試すことができます。チェックポイントについて詳しく学びましょう。

  • ツール呼び出しを承認する。 VS Codeは、ターミナルコマンドを実行したり、副作用を伴うツールを使用したりする前に、ユーザーの承認を求めます。どのツールを自動的に実行し、どれに確認が必要かを制御できます。「Chat: Manage Tool Approval(チャット: ツールの承認管理)」コマンドを使用して、すべてのツールの承認を一元管理します。承認の管理方法をご覧ください。

  • 権限レベルを選択する。 エージェントの自律性のレベルを制御します。「Default Approvals(デフォルトの承認)」では機密性の高いツールに確認が必要となり、「Bypass Approvals(承認のバイパス)」ではすべてのツール呼び出しが自動承認されます。また、「Autopilot(オートパイロット)」(プレビュー)では、質問への自動応答や自律的な作業継続が行われます。より高い自律性レベルを使用する場合は、エージェントのサンドボックス化やコンテナと組み合わせてください。

  • 信頼境界。 VS Codeは、ファイルアクセス、URLアクセス、エージェントのサンドボックス化、およびMCPサーバーとのやり取りに関してセキュリティ境界を適用します。AIのセキュリティについて詳しく学びましょう。

AIが生成したコードは、コミット前に必ず確認してください。エッジケースを処理しているか、プロジェクトの規約に従っているか、セキュリティ上の問題が含まれていないかを確認します。

エージェントのサンドボックス化

注意

エージェントのサンドボックス化は現在プレビュー段階であり、今後さらに進化する可能性があります。

エージェントのサンドボックス化は、OSレベルの分離を使用して、マシン上でエージェントがアクセスできる範囲を制限します。各アクションの前に承認プロンプトに頼るのではなく、OS自体によって強制されるファイルシステムおよびネットワークアクセスの厳格な境界を定義します。

現在、VS Codeはエージェントセッション中に実行されるターミナルコマンド(runInTerminalエージェントツール)に対してサンドボックス化を適用しています。エージェントのサンドボックス化の設定方法をご覧ください。

サンドボックス化が有効な場合、VS Codeは制御された環境内でコマンドが実行されるため、確認プロンプトなしでコマンドやツール呼び出しを自動的に承認します。

なぜサンドボックス化が重要なのか

承認ベースのセキュリティでは、ターミナルコマンドやツール呼び出しが実行されるたびに確認が必要です。これは制御の面では有用ですが、実用上いくつかの制限があります。

  • 承認疲れ。 コマンドの承認を繰り返すと、特に長いエージェントセッションでは、何に対して承認を行っているかへの注意力が低下する可能性があります。

  • 解析の制限。 自動承認ルールはベストエフォート型のコマンド解析を使用しますが、これには既知の制限があります。シェルエイリアス、引用符の連結、複雑なシェル構文などはルールを回避し、検出されずに通過する可能性があります。

  • プロンプトインジェクション。 ファイル、ツール出力、Webページに含まれる悪意のあるコンテンツが、エージェントを騙して有害なコマンドを実行させようとする可能性があります。慎重なレビューなしに承認してしまうと、意図しないアクションやセキュリティリスクにつながる恐れがあります。

  • 外部サービスに対する意図しないアクション。 悪意がなくても、ネットワークアクセス権を持つエージェントは、取り消しが困難なアクションをユーザーに代わって実行する可能性があります。たとえば、クラウドのリソースをプロビジョニングする、インフラ設定を変更する、リモートリポジトリにコードをプッシュする、デプロイや金融取引をトリガーするAPIを呼び出すなどです。ネットワークの分離により、エージェントが明示的に許可したドメインにのみアクセスできるようになり、外部サービスに対する意図しない副作用のリスクが軽減されます。

サンドボックス化は、OSレベルで境界を強制することでこれらの課題に対処します。サンドボックスは、自動承認されたコマンドが許可された範囲外のファイルやネットワークリソースにアクセスすることを防ぎます。追加の権限が必要な場合、VS Codeはサンドボックス外でコマンドを実行するように促します。

サンドボックス化の仕組み

サンドボックス化は、「ファイルシステムアクセス」と「ネットワークアクセス」という2種類の分離を強制します。これらは両方ともOSレベルで適用され、サンドボックス内で実行されているコマンドによって回避することはできません。

ファイルシステムの分離

ファイルシステムの分離がない場合、侵害されたコマンドはマシン上のどこでもファイルを変更できる可能性があります(例:シェル設定ファイル ~/.bashrc~/.zshrc に悪意のあるコードを挿入する、または ~/.ssh/ からSSHキーを読み取るなど)。ファイルシステムの分離は、明示的に許可されたパスへのアクセスを制限することでこれを防ぎます。

  • デフォルトの動作。 ファイルシステム全体に対する読み取りアクセスは許可されます。書き込みアクセスは現在の作業ディレクトリとそのサブディレクトリに制限されます。追加の権限が必要な要求が行われた場合、VS Codeはサンドボックス外でのコマンド実行を許可するように促します。

    Screenshot of a VS Code prompt asking the user to allow a command to run outside the sandbox for additional permissions.

  • 設定可能なルール。 追加のパスに対する書き込みアクセスを許可したり、特定のパスに対する読み取り/書き込みアクセスを拒否したりできます。拒否ルールは常に許可ルールよりも優先されます。

  • 継承される制限。 サンドボックス化されたコマンドによって生成されたすべての子プロセスは、同じファイルシステムの境界を継承します。つまり、npmpip、またはビルドスクリプトのようなツールも同様に制限されます。

ネットワークの分離

ネットワークの分離がない場合、侵害されたコマンドは機密データを外部に流出させたり、外部サービスに対して意図しない操作を実行したりする可能性があります。ネットワークの分離は、デフォルトですべてのアウトバウンド接続をブロックすることでこれを防ぎます。

  • ドメインの許可リスト。 特定のドメインへのアクセスを明示的に許可できます。

    注意

    エージェントは、単にデータを読み取るだけでなく、許可されたドメインに対してユーザーに代わってアクションを実行できます。たとえば、api.github.comを許可すると、エージェントがプルリクエストを作成したり、リポジトリ設定を変更したりする可能性があります。クラウドサービスのAPIドメインを許可すると、クラウドリソースが変更される可能性があります。この設定は絶対に必要である場合にのみ構成してください。この構成は設定によって指定され、現在のタスクだけでなく、すべてのサンドボックス化されたコマンドに適用されます。

  • 継承される制限。 すべての子プロセスは同じネットワーク制限を継承するため、サブプロセスを生成するスクリプトやツールがネットワークルールを回避することはできません。

OSレベルの強制

エージェントのサンドボックス化は、ファイルシステムとネットワークの制限を強制するためにOSレベルのセキュリティプリミティブに依存しています。強制はカーネルレベルで行われるため、サンドボックス化されたプロセスとそのすべての子プロセスは、コマンドが回避を試みるように作成されていても、これらの境界を回避することはできません。

プラットフォーム 技術 前提条件
macOS OSに組み込まれているAppleのサンドボックスフレームワーク("Seatbelt")。カーネルレベルできめ細かなファイルシステムおよびネットワーク制限を強制します。 なし。そのまま動作します。
LinuxおよびWSL2 ファイルシステムの分離にはbubblewrap、ネットワークプロキシにはsocatを使用します。 必要なパッケージをインストールします: sudo apt-get install bubblewrap socat (DebianおよびUbuntu) または sudo dnf install bubblewrap socat (Fedora)。

bubblewrapはLinuxカーネル機能(ユーザー名前空間)を必要とするため、WSLバージョン1はサポートされていません。この機能はWSL2でのみ利用可能です。

![!NOTE] Windowsにおけるエージェントのサンドボックス化サポートは、現在基盤となるプラットフォームとしてWSL2を使用しています。

サンドボックス化の対象外

エージェントのサンドボックス化は、シェルサブプロセス(ターミナルコマンド)にのみ適用されます。組み込みのファイルツールはカバーされません。エージェントの読み取り、編集、書き込みツールは、サンドボックスを通さず、VS Codeの権限システムを直接使用します。Webフェッチツールもサンドボックス外で実行され、サンドボックスのネットワーク制限の影響を受けません。

これらの操作を制御するには、レビューフロー機密ファイル保護を使用してください。

環境全体を完全に分離するには、サンドボックス化とDev Containerを組み合わせてください。Dev Containerは、すべてのツール、ファイルアクセス、ネットワークアクセスを含む、開発環境全体を完全に囲い込む境界を提供します。

エージェントのサンドボックス化は現在プレビュー段階であり、より多くのツールやシナリオをカバーするように進化し続けています。

注意すべきAIの制限事項

不正確な出力。 モデルは正しいように見えるコードを生成する可能性がありますが、バグが含まれていたり、非推奨のAPIを使用していたり、エッジケースを処理していなかったりすることがあります。AIが生成したコードは、特にセキュリティ、データの整合性、重要なフローに影響を与えるロジックについては、必ずテストしてください。

プロンプトインジェクション。 ファイル、ツール出力、Webページに含まれる悪意のあるコンテンツが、エージェントの動作をリダイレクトしようとする可能性があります。これが、VS Codeにツール承認ゲートと信頼境界が含まれている理由です。AIのセキュリティについて詳しく学びましょう。

AIが生成した出力は「初稿」として扱い、出発点としては有用ですが、常にユーザーの確認と判断が必要です。非決定性、知識の境界、コンテキストの制限など、モデルがどのように機能するかについての詳細は、言語モデルを参照してください。

© . This site is unofficial and not affiliated with Microsoft.