Devinのサンドボックス環境とシークレット管理を設定し、安全な自動ビルドと統合テストを実行する実践ガイド

エンジニアリングチームがDevinを活用して自動ビルドや統合テストを安全に実行するには、宣言的ブループリント（Blueprints） による再現可能なスナップショット分離環境、実行時にのみ環境変数として安全に注入される 階層型シークレット管理（Secret Management）、そしてDevin Cloudの一時仮想環境やCLIの bubblewrap によるOSレベル隔離、オンプレミス・プライベートVPC向けの Devin Outposts という3つの防御層を適切に構成することが不可欠です。

一般的なコード補完ツールとは異なり、Devinは自律的なAIソフトウェアエンジニアとして機能します。自らリポジトリをクローンし、OSパッケージをインストールし、バックエンドサービスを起動してテストを実行し、内蔵ブラウザでエンドツーエンドの動作確認を行います。自律型エージェントにシェル実行権限やネットワークアクセスを許可する場合、堅牢なサンドボックスと最小権限の認証情報管理がなければ、テスト用認証情報の漏洩や内部ネットワークへの意図しないアクセス、ホスト環境の汚染といった深刻なセキュリティリスクを招きます。

1. Devinの環境アーキテクチャ：サンドボックスと計算リソースの分離

Devinは、組織のセキュリティポリシー、ネットワーク構成、コンプライアンス要件に応じて3つの実行環境モードを提供しています。

Devin Cloud サンドボックス

デフォルトのクラウドモードでは、Devinの各セッションは独立した一時的（エフェメラル）な仮想環境内で動作します。

• スナップショット分離と宣言的設定： 環境構成は宣言的Blueprintによって定義されます。ブループリントのビルド時に暗号化されたマシンスナップショットが作成され、以降のセッションや差分ビルドはこのクリーンなベースラインから起動します。
• エフェメラルな状態管理： 自動テスト実行中に作成されたファイルや一時データベースの変更は、そのセッションのコンテナ内にのみ留まります。セッション終了時に破棄されるため、後続の実行にテストの残骸が影響を与えることはありません。

Devin CLI によるOSレベルサンドボックス

ローカル環境や自社CIランナーでDevin CLIを実行する場合、--sandbox フラグを付与することでOSレベルの強制隔離を有効化できます。

• ファイルシステムの書き込み制限： 書き込み権限は、アクティブなワークスペースディレクトリおよび明示的に許可された Write(...) スコープのみに制限されます。システムライブラリやユーザー設定、ホームディレクトリの重要ファイルは読み取り専用に保護されます。
• 明示的拒否ルール（Deny Rules）： Read(...) の拒否リストに指定されたパスは、サンドボックス内のプロセスから完全に不可視化されます。ビルドスクリプトやエージェントが ~/.ssh や ~/.aws などの秘密情報を探索することはできません。
• フェイルクローズ（Fail-Closed）保証： Linux環境で bubblewrap（bwrap）や socat などの必須依存ツールが不足している場合、Devinは未保護の状態で起動することを拒否し、直ちにハードエラーで停止します。Windows環境で --sandbox を指定した場合も同様に実行が停止され、セキュリティ要件が静かに無視されるのを防ぎます。
• ネットワークフィルタリング： ユーザー設定でドメイン許可リスト（allowed_domains）や拒否リスト（denied_domains）を定義し、サンドボックスからの外部通信を信頼できるモックサーバーや内部パッケージレジストリのみに制限できます。

Devin Outposts（自社管理インフラでの実行）

自社VPC内のデータベースやプライベートなマイクロサービスに対する統合テストが必要な企業向けに、Devin Outpostsはコントロールプレーンとデータプレーンを分離する仕組みを提供します。

• 仕組み： エージェントの思考・推論ループはCognitionのクラウドで実行されますが、シェルコマンドの実行、ファイルの編集、コードの取得、テストの実行はすべて自社のインフラ（VM、コンテナ、Kubernetesクラスタ）上で稼働するワーカーによって行われます。
• アウトバウンド専用接続： ワーカーマシンで devin worker start --outpost=<outpost_name> を実行すると、Devin Cloudに対して外向き（アウトバウンド）のHTTPS接続を確立します。インバウンドポートの開放、パブリックIPの割り当て、VPNトンネルの構築は一切不要です。
• 厳格なデータ境界： ソースコード、テスト用DBの接続情報、テストログが外部に漏れ出すことなく、社内ネットワーク境界内に完結します。

2. 階層型シークレット管理と安全な注入メカニズム

CI/CDにおける重大な脆弱性の1つは、認証情報がソースコードにコミットされたり、保存されるマシンイメージやログにベイク（焼き付け）されたりすることです。Devinは暗号化された階層管理により、これを防止します。

シークレットのスコープ分離

• 組織・エンタープライズシークレット（Organization Secrets）： 管理コンソールの Settings > Resources > Secrets で一括管理され、保存時に暗号化されます。エンタープライズプランでは Build only（ビルド時のみ）を指定可能で、環境構築スナップショット作成時のみ利用され、リポジトリのクローンやテストセッション開始前に完全に削除されます。
• リポジトリ専用シークレット（Repository Secrets）： 各リポジトリのブループリントエディタ（Settings > Environment > Blueprints > [リポジトリ] > Secrets）で設定します。該当リポジトリのビルドおよびセッションでのみ参照可能であり、権限を持たない一般メンバーにはシークレット名のみが表示され、値は閲覧できません。
• 個人・セッション専用シークレット（Personal & Session Secrets）： 開発者個人が検証用に登録するシークレットや、チャットプロンプトで一時的に渡す単一セッション限定のシークレットです。

ベイクを防ぐ注入原則

• 環境変数としての動的マッピング： UIで登録したシークレットは、コマンド実行時に $TEST_DB_PASSWORD や $STRIPE_TEST_KEY などの環境変数としてプロセスに動的注入されます。Blueprint YAMLやリポジトリ内の .env に平文で記述する必要はありません。
• スナップショットからの自動スクラブ： 環境スナップショットが保存される際、注入されたシークレット情報はメモリやディスクから自動的に除去（スクラブ）されます。生成されたイメージディスクにシークレットが残存することはありません。
• ファイル添付機能の活用： Mavenの settings.xml や npmの .npmrc など設定ファイルが必要な場合、ブループリント経由でファイルを安全にアップロードできます。ファイルは ~/.files/ に配置され、$FILE_SETTINGS_XML などの環境変数が自動生成されるため、リポジトリに認証ファイルを直接コミットするリスクを回避できます。
• サイトCookieとTOTPのサポート： Web統合テスト向けに、base64エンコードされたChromium Cookieや二要素認証（TOTP）シークレットの登録に対応しています。テスト専用アカウントのセッションを直接再現できるため、マスターパスワードを露出させずにステージング環境のE2Eテストを実行できます。

3. 安全なビルドと統合テストのステップ別設定手順

工程チームが安全なテストパイプラインを構築する4つの手順：

ステップ1：宣言的ブループリントの構成

Blueprintエディタで、OSツール導入と依存関係解決、テスト手順を明確に分離して記述します。

# 1. initialize: フルビルド時のみ実行。OSパッケージや言語ランタイムのセットアップ
initialize: |
  curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
  apt-get update && apt-get install -y nodejs postgresql-client

# 2. maintenance: 依存関係のインストール。セッション開始時にエージェントへ提示される
maintenance:
  - name: "Install Project Dependencies"
    run: npm ci

# 3. knowledge: Devin向けのテスト実行ガイダンス（コマンドの実行は行われない）
knowledge: |
  ユニットテスト実行コマンド: npm test
  ローカルDB向け統合テスト実行コマンド: npm run test:e2e

ステップ2：テスト専用シークレットの割り当て

1. Settings > Environment > Blueprints を開き、対象リポジトリを選択します。
2. Secrets タブで Create secret をクリックします。
3. 最小権限に絞ったテスト用認証情報を登録します：
   • E2E_DATABASE_URL：分離されたテスト用DBコンテナまたはステージングRDSの接続文字列。
   • TEST_API_KEY：モックデータ操作のみに権限を絞ったサンドボックスAPIキー。
   • DEVIN_AUTH_COOKIE：Web E2Eテスト用の一時セッションCookie。
4. Note 欄に有効期限や用途（例：「ステージング環境QA専用、月次自動ローテーション」）を明記します。

ステップ3：ネットワークとサンドボックスの境界設定

• クラウド実行時： エンタープライズ設定で、Devinがアクセスできる対象リポジトリおよびブランチを厳密に制限します。
• CLI・ローカルCI実行時： --sandbox を指定し、ドメイン許可リストで未承認の外部エンドポイントへの通信を遮断します。
• Outposts実行時： 専用の隔離サブネット内にWorkerを展開し、本番環境ネットワークへのルーティングをセキュリティグループでブロックします。

ステップ4：統合テストの実行とエビデンス確認

コード修正完了後、Devinにテスト実行を指示します：

「自動ビルドを実行し、npm run test:e2e でログインから購入完了までのシナリオをテストしてください。」

Devinは自動的に Testing Mode に入ります：

1. ブループリント環境を確認し、依存パッケージを整えます。
2. 注入されたテスト用環境変数を自動認識します。
3. ローカルサービスを起動してテストを実行し、Web UI検証が必要な場合は内蔵ブラウザを操作します。
4. 画面操作の録画ビデオを生成し、テスト結果とともにPRに添付します。ログに生のシークレットを出力することなく、動作検証のエビデンスをレビュー担当者に提供できます。

4. セキュリティベストプラクティスと回避すべき落とし穴

参考資料

• Secrets & Site Cookies - Devin Docs
• Devin environment blueprints - Devin Docs
• Blueprint reference - Devin Docs
• Sandbox - Devin Docs
• Devin Outposts: self-hosted infrastructure - Devin Docs
• Testing & Video Recordings - Devin Docs
• Enterprise security - Devin Docs