2026 DeepSeek Harness 用 E2Bサンドボックスか永続環境か？

この判断に迷っている個人開発者、アプリ開発チーム、プラットフォーム責任者向けです。
特に、短時間のAI Agent実行と、何日も保持したい開発ワークスペースを同じ場所へ置こうとしている場合に役立ちます。

まず、今週は次の作業から始めます。

• [ ] タスクごとに「終了後に消えてよいもの」を洗い出す
• [ ] Xcode、iOS署名、Safari、Keychainの利用有無を記録する
• [ ] セッション、依存パッケージ、データベース、生成物の保存先を分ける
• [ ] 本番資格情報を実行環境へ自動投入しない
• [ ] 代表タスクを3種類に分け、E2B、永続環境、二軌道で最小検証する

ここで重要なのは、サンドボックスの寿命とHarnessの会話履歴の寿命は別管理になることです。E2Bの実行環境が終了しても、Harness側で保存したセッションやログまで自動的に同じ状態で復元できるとは限りません。

E2Bは、コード実行やデータ処理を隔離するための実行基盤です。公式資料には、サンドボックスの作成、接続、一覧、停止、ログ確認、メトリクス確認といった操作が記載されています。サンドボックス操作の公式リファレンス

一方、永続実行環境は、プロジェクトの依存関係、ローカル設定、デバッグ途中のファイル、長時間動くプロセスを残すための場所です。両者は「安全な場所」と「便利な場所」という単純な対立ではありません。保存、権限、失敗時の引き継ぎを誰が担当するかが違います。

E2Bはクラウド上のMacではありません。E2Bの公式説明が示すのは隔離Linux VMであり、macOSの実行面やApple固有の認証資産を提供するものではありません。E2Bの環境定義

注意: 隔離されているからといって、プロンプトインジェクションやデータ流出が自動的に防止されるわけではありません。外部APIへの書き込み、環境変数の公開、成果物の回収経路には別の権限制御が必要です。

個人の試験タスク

個人で試す場合は、次の条件を満たす仕事からE2Bへ移します。

• 公開リポジトリから依存関係を復元できる
• 実行後に環境内のファイルが残らなくても困らない
• 外部サービスへの書き込みが不要
• 失敗してもログ、パッチ、テスト結果があれば再開できる
• APIキーを限定スコープで発行できる

短いスクリプト、未知のパッケージの動作確認、入力データの形式検証はE2B向きです。反対に、同じセッションで何度も人が指示を追加する作業は、永続実行環境のほうが再接続しやすく、調査の手戻りも少なくなります。

DeepSeek HarnessのE2Bサンドボックスは長期タスクに使えるか。
技術的に長く動かせるかだけで決めてはいけません。セッション履歴、作業ファイル、キャッシュ、子プロセスを再現できる保存設計がないなら、長期タスクの主環境には不向きです。長期処理を試す場合も、まずは途中状態を外部ストレージへ回収し、再作成テストを行います。

アプリ開発チーム

アプリ開発では、次の「再構築できるもの」と「再構築しにくいもの」を分けます。

再構築しやすいもの

• lockファイルから取得できる依存パッケージ
• リポジトリ内の設定ファイル
• 自動生成できるテストデータ
• CIで再作成できるビルド成果物
• 実行ログ、差分、テストレポート

再構築しにくいもの

• ローカルデータベースの途中状態
• 手動で変更した環境変数
• 認証済みCLIのホームディレクトリ
• セッション固有の一時ファイル
• 長時間動く開発サーバー
• 人が途中で加えた未記録の修正

前者だけで完結するなら、E2Bにタスクを投入し、タスクID、コミットID、依存関係のハッシュ、成果物の保存先を記録します。後者が含まれるなら、永続環境を標準にし、E2Bでは不可信入力の前処理や静的検査だけを担当させます。

E2Bの有効期限後もDeepSeek Harnessのセッションは残るか。
残る可能性があるのは、Harness側がセッションを外部に保存している場合だけです。E2B内のホームディレクトリやSQLite、作業ファイルにだけ履歴を置いていた場合、サンドボックス終了後の復旧を保証できません。セッションIDと実行環境IDを別々に記録し、終了前に会話ログ、差分、標準出力、生成物を回収します。

Xcode、iOS署名、Safari自動化、Keychain、macOS専用GUIを使うタスクは、一般的なLinuxサンドボックスへ移せません。E2Bを使う場合は、コードレビュー、依存関係の検査、未信頼データの前処理までに限定し、検査を通過した処理を受け入れ済みのMacへ渡します。

Appleの資料では、Xcodeの署名資産や証明書の秘密鍵はMacのKeychainに保存されると説明されています。Xcodeの署名ワークフロー また、コード署名には証明書だけでなく秘密鍵を含む署名アイデンティティが必要です。コード署名証明書の公式技術資料

このため、E2BへAppleの秘密鍵をコピーして解決する設計は避けます。署名は受け入れ済みのMac上で、対象リポジトリ、ブランチ、ビルド番号、承認記録を確認してから実行します。

Xcodeが必要なAI AgentタスクをE2Bへ置けるか。
Xcodeそのもの、iOSシミュレーター、署名、Keychainアクセスが必要なら置けません。置けるのは、Xcodeを呼び出さないコード解析、テストケース生成、依存関係の確認、差分レビューです。最終ビルドと署名は実機に近いMac環境で確認します。

macOS側では、少なくとも次を分けます。

• レビュー用の読み取り専用ワークスペース
• ビルド用ワークスペース
• 署名可能なリリース用ワークスペース
• 開発者が接続するデバッグ用セッション

同じMacを使う場合でも、権限、環境変数、成果物保存先を分離します。MESHLAUNCHのMac環境の利用相談を使う場合も、必要なmacOS専用ツールと接続方式を先に定義してから構成を決めます。

プラットフォームチームには、二軌道構成を勧めます。永続環境はHarness設定、タスク台帳、監査ログ、承認、再実行指示を保持します。E2Bは、入力の検査、コード実行、テスト、変換など、失敗しても破棄できる処理を受け持ちます。

ただし、二軌道にしただけで安全になるわけではありません。最低限、次の4つをインターフェースとして固定します。

1. タスク識別子
   HarnessのセッションID、E2BのサンドボックスID、GitのコミットIDを一つの実行記録へ結びます。

2. ファイル同期
   入力ファイルのハッシュ、転送方向、サイズ制限、除外パスを定義します。同期を無制限にすると、秘密情報や不要な個人データまで実行面へ流れます。

3. 成果物回収
   パッチ、ログ、テスト結果、生成ファイルを個別に回収します。「環境が残っているから後で見ればよい」という運用は、サンドボックス終了時に破綻します。

4. 失敗時の接管
   E2Bが終了した場合に、誰が再実行し、誰が永続Macへ切り替え、誰が外部書き込みを承認するかを決めます。

MESHLAUNCHのMac mini M4利用案内を確認する場合も、単にCPUやメモリを見るのではなく、Harnessのセッション保持、SSH接続、ログ回収、Mac専用処理の受け渡しを確認項目にします。

運用メモ: E2BからMacへ渡すのは、原則として「検査済みの入力、コミットID、実行指示、必要な成果物」に限定します。実行面から制御面へ戻すデータも、同じタスクIDで監査できる状態にします。

安全管理を担当するチームは、環境の種類より先に資格情報の種類を分けます。

• 読み取り専用の公開API
• 開発用の限定API
• ステージング書き込み権限
• 本番書き込み権限
• コード署名用の秘密鍵
• 顧客データへアクセスする資格情報

不可信コードをE2Bで実行する場合、本番資格情報や外部書き込み権限を自動投入しません。必要な場合は、短時間、対象リソース限定、承認済みタスク限定にします。環境変数へまとめて渡すだけでは、ログ出力や子プロセス経由の漏えいを防げません。

Harness側のツールガードがあっても、許可されたツールが過剰な権限を持っていれば危険です。削除、公開、送信、署名、デプロイは別の承認段階に置き、サンドボックスの隔離とは別に制御します。

本番導入前は、次の順で検証します。

1. タスク分類
   一度きりの検証、状態依存の開発、macOS専用処理の3種類に分けます。

2. 再構築テスト
   リポジトリ、lockファイル、設定、入力データだけで同じ処理を再現できるか確認します。

3. 状態保存テスト
   E2B終了後に、Harnessの会話ログ、差分、テスト結果、成果物を復元できるか確認します。

4. 権限テスト
   読み取り、外部送信、削除、署名を別々に試します。想定外のAPI呼び出しやパスアクセスがないか監査します。

5. 引き継ぎテスト
   E2Bで検査したタスクをMacへ渡し、同じタスクIDでビルド、署名、成果物回収まで追跡します。

個人試験なら、まず公開コードの単体テストと静的解析だけをE2Bへ置きます。アプリ開発チームなら、依存関係とデータベースを別々に検証します。プラットフォームチームなら、E2Bの終了、通信失敗、成果物欠落を意図的に発生させ、再実行責任が曖昧にならないことを確認します。

短期で破棄でき、リポジトリから再構築でき、macOS専用機能を使わない処理はE2Bサンドボックスが適しています。固定ワークスペース、長期セッション、継続プロセス、Xcode、Safari、Keychainが関わるなら、受け入れ済みの永続Mac環境を選びます。

両方が必要なチームは、すべてをE2Bへ移すのではなく、制御面と状態を永続環境に残し、危険な入力や使い捨て処理だけをE2Bへ送ります。単一環境に集約すると、短期タスクの隔離不足、長期タスクの状態消失、資格情報の過剰共有という3つの問題が同時に起きやすくなります。

現在の構成が共有Macや一般的なLinuxサーバーだけの場合、未信頼コードと開発者の長期セッションが同居しやすく、権限境界も曖昧になります。さらに、XcodeやKeychainを使う処理では実行面が不足し、失敗時に同じ状態へ戻れないことがあります。こうした仕事を残すなら、短期サンドボックスだけへ統一するより、MESHLAUNCHの永続Mac環境を使ったDeepSeek Harness運用を候補に含めるほうが、状態とmacOSツールチェーンの責任を明確にできます。

まずは代表タスクを1本ずつ選び、E2Bで破棄できるか、永続Macで再接続できるか、二軌道で成果物を回収できるかを確認します。短期の検証環境が必要な場合はE2B、継続的な開発環境が必要な場合は永続Macという境界を、タスク台帳と権限設定へ反映してください。