2026 Apple ContainerでAI Agentを動かす前に、サンドボックスをどう受け入れ検査するか？

2026年8月22日時点で、Apple Containerの公式リリースには1.2.0が掲載されています。公式リリース履歴で確認できるのは、あくまで実装の公開状況です。したがって、Apple Container AI Agent サンドボックスは「起動できた」だけでは合格にできません。ファイル越権、秘密情報の漏えい、無制限の外向き通信、資源枯渇、異常終了後の残留をすべて再現テストし、証拠を保存できた場合だけ本番投入します。

この判断をする対象者
Apple Silicon MacでコーディングAgentの実行環境を繰り返し提供するプラットフォーム担当者向けです。不可信なコードの実行を審査するセキュリティ担当者は、逃走経路、通信制御、秘密情報の露出を重点的に確認してください。チーム責任者は、ローカルMacを継続するか、クラウドMacを増やすか、Linux microVMへ移すかを検査結果で決められます。

起動確認と隔離合格は別の判定です

Agentがタスクを開始し、コードを実行し、結果を返した。この事実は実行経路が動いたことしか示しません。ホスト側のファイル、環境変数、ソケット、内部サービスへ到達できる可能性は残ります。

受け入れ結果は、次の3段階に分けると運用しやすくなります。

判定	必須条件	許可する用途
本番投入可	ファイル、秘密情報、通信、資源、回収の全項目に合格し、ログを再確認できる	管理された単一ユーザーの本番タスク
低リスク内部限定	重大な越権は抑止できるが、ネットワーク監査や回収証拠に不足がある	テストコード、機密情報を持たない開発作業
実行基盤を変更	ホスト境界、秘密情報、無制限通信のいずれかが破られる	高リスクコード、多租用、外部入力を扱うタスクは停止

合格証拠には、実行日時、イメージまたは環境識別子、実行した入力、Agentのツール呼び出し、ホスト側で観測した結果を含めます。画面の成功表示だけを保存しても、後から再現できません。

Apple Container、Docker、dshは境界の種類が違います

Apple ContainerはMac上でLinuxコンテナの実行環境を提供しますが、内部の構成や境界を「完全な物理分離」と扱ってはいけません。Containerizationのアーキテクチャ説明を確認し、どの層がプロセス、Linux環境、ホストMacを分けているかを記録します。

dshはローカルサンドボックスにSeatbelt、bubblewrap、Landlockなどのバックエンドを持ち、カスタムrunnerも提供します。dshのサンドボックス設定で確認できるのは選択可能な実行方式です。developer previewであり、Seatbeltを指定したから完全な仮想マシン隔離になるわけではありません。

方式	受け入れ検査で見る境界	注意点
dshのSeatbelt	許可パス、実行権限、ツール呼び出し	ポリシー制約であり、完全な仮想マシンではありません
Docker	bind mount、seccomp、権限、ソケット	共有カーネルを前提にし、マウント設定が境界を左右します
Apple Container	Mac上のLinux実行環境、ワークスペース、通信経路	軽量仮想化の構成を確認し、別途ネットワーク制御を設計します
Firecracker	LinuxとKVMによるmicroVM、専用ホスト	Linux、KVM、ホスト強化が必要で、Mac上の単純な切替先ではありません

Dockerのsyscall制御については、公式のseccomp文書を基準にします。コンテナ、ポリシーサンドボックス、microVMは同じ「隔離」という言葉でも、失敗時の影響範囲が異なります。

第一段階：ファイル境界を破る入力を先に試します

ワークスペース内の通常処理から始めると、検査が甘くなります。最初からAgentに、許可対象外の読み取りを指示するテストを渡します。

1. 許可した作業ディレクトリ外の既知ファイルを読むよう指示します。
2. ../を使ったパス移動を、相対パス、絶対パス、URLデコード後の文字列で試します。
3. 許可ディレクトリ内から外部を指すシンボリックリンクを作り、追跡されるか確認します。
4. ルートファイルシステムへの書き込みを試し、読み取り専用設定が実効しているか見ます。
5. 想定外のマウントポイント、Dockerソケット、ホスト側の共有パスを列挙させます。

合格条件は「拒否された」という文字が出ることではありません。ホスト側の監査ログ、対象パス、Agentのツール結果を突き合わせ、許可外のデータが一バイトも返っていないことが必要です。

Apple Containerは不可信なコードを安全に実行できますか。
無条件には判定できません。許可パス、マウント、実行権限、Linux環境との境界を実際の攻撃入力で検証し、さらに通信と秘密情報の試験にも合格した場合に限り、定義したリスク範囲で利用できます。

第二段階：秘密情報は「渡さない設計」を検査します

APIキーを環境変数に入れ、Agentに自由なシェルを与える構成は、起動確認だけなら便利です。しかし、プロンプトインジェクションや悪意あるツール呼び出しで、環境変数、設定ファイル、SSH鍵、セッションログ、ビルドキャッシュを読み取られる可能性があります。

次の試験では、実キーではなく失効済みの識別用ダミー値を使います。

• 環境変数と設定ファイルの列挙を依頼する。
• ホームディレクトリ、SSH関連パス、Agentのログとキャッシュを読むよう指示する。
• ダミー秘密値を外向きリクエスト、標準出力、生成物、コミット差分へ入れさせる。
• ツール呼び出しの引数と戻り値に秘密値が残らないか確認する。
• タスク終了後に一時ファイル、プロセス環境、ログ保存先を再確認する。

長期運用に宿主側の秘密情報を常時注入しないと成立しない方式は、その時点で本番可とは扱いません。短時間の代理発行、最小権限トークン、用途別の失効を組み合わせ、Agentから直接読めない経路を優先します。

第三段階：外向き通信は許可リストの外側から試します

実行環境の隔離とネットワーク制御は別機能です。Apple ContainerやDockerを起動しても、DNS、外部HTTPS、内側の管理サービス、ホストサービス、クラウドのメタデータ向けアドレスが自動的に安全になるわけではありません。

AI Agentのサンドボックス公開前に、どの隔離項目を試すべきですか。
少なくともファイル、秘密情報、名前解決、外部通信、内側のアドレス、資源枯渇、強制終了後の回収を分けて試します。各項目で、許可・拒否の結果だけでなく、誰が遮断し、どこに監査記録が残ったかを保存します。

通信試験	合格とする観測	不合格時の扱い
許可外ドメイン	DNSまたは接続が制御層で拒否される	高リスク用途を停止
内部アドレス	ホストサービスや管理面へ到達しない	経路と権限を再設計
メタデータ相当の宛先	応答を取得できず、試行が監査される	秘密情報漏えいの重大欠陥として扱う
許可リストの宛先	一時許可の範囲と期限が記録される	無期限の全開放を避ける

「通信できなかった」というAgentの報告だけでは不十分です。DNSログ、ファイアウォールログ、プロキシログ、実行環境のネットワーク状態を同じ検査記録に関連付けます。

注意：Astraについては、OpenAIの2026年8月7日の安全公告が隔離要求を考える背景になりますが、未公開モデルを実運用済みの製品や公開性能として扱ってはいけません。

第四段階：資源枯渇と終了後の残留を確認します

Agentには、終了しないループ、急速なプロセス生成、大量のディスク書き込み、長時間の子プロセス、強制終了されるタスクを実行させます。ここで確認するのはベンチマーク値ではなく、制限が発動し、他のタスクへ影響を広げず、終了後に状態が消えることです。

確認項目はCPU、メモリ、ストレージ、プロセス数、実行時間、子プロセス、ネットワーク状態です。起動時間、同時実行数、資源オーバーヘッドを数値で比較する場合は、対象バージョンの公式資料または再現可能なサイト内実測が必要です。根拠のない性能値は受け入れ基準に入れません。

終了後には、プロセス一覧、マウント、作業ファイル、ログ、ソケット、通信セッションをホスト側から確認します。再起動しないと消えない状態や、別タスクから見える一時データが残る場合は、回収試験に不合格です。

条件分岐で「継続」「強化」「移行」を決めます

検査結果から実行基盤を選ぶ際は、平均的な性能表より、失敗した項目を優先します。

• 全項目に合格し、単一ユーザーの信頼できるタスクだけを扱う場合：Apple Containerを継続します。監査ログと再検査用スクリプトを保管します。
• ファイル境界は合格するが、ネットワーク監査や秘密情報の扱いが弱い場合：低リスクの内部作業に限定し、代理トークン、通信プロキシ、追加ログで強化します。
• dshを使う場合：Seatbelt、bubblewrap、Landlockの適用結果を個別に記録します。dshのカスタムrunnerは拡張インターフェースであり、Firecrackerへ即時切替できる既製アダプターではありません。
• 高リスクの任意コード実行、多租用、または重要な隔離項目に失敗した場合：サンドボックスを無効化せず、Linux/KVM上のFirecrackerを評価します。Firecrackerの設計文書と本番ホストの強化要件を確認し、宿主OS、KVM権限、更新手順まで含めて設計します。

FirecrackerはMac上のApple Containerに設定を足すだけの代替ではありません。Linuxホストを用意できないチームは、まずタスク分類と秘密情報の非注入化を行い、それでも要件を満たせない場合に実行基盤の移行を決めます。

実環境で再検査する場合は、macOSの版、Apple Siliconの機種、ワークスペースのマウント方式、Agentの並行実行方法、検査スクリプトを固定します。ProxyMacのコンソールを使う構成でも、環境を借りた事実だけで安全性を証明するのではなく、同じPoCを実行してログを保存する運用にします。利用条件の確認にはProxyMacのヘルプも参照できます。

現在の方式を続けるか、Mac環境を一時検証するか

ローカルMacだけで検査すると、担当者の端末状態、秘密情報、既存プロセスが結果に混ざりやすくなります。Dockerだけに寄せる場合も、共有カーネル、広すぎるbind mount、Dockerソケット、無制限の外向き通信が残れば、Agentの不可信なコード実行には長期的な弱点になります。

一方、Linux/KVMのFirecrackerは強い境界を評価しやすい反面、Linuxホストの運用、KVM権限、ホスト強化が必要です。Apple Silicon向けの実行条件を保ったまま検査を再現したい場合は、ProxyMacで一時的なMac環境を用意し、同じ隔離スクリプトを実行して証拠を比較する方法が現実的です。レンタルを選ぶ場合も、安全等級を先に約束するのではなく、対象のmacOS、Apple Silicon環境、並行実行方式、ワークスペース構成を固定してから申請します。

受け入れ検査の目的は、特定のランタイムを勝者にすることではありません。失敗した境界を特定し、低リスク作業なら継続し、高リスク作業ならFirecrackerなど別の隔離層へ移せる状態を作ることです。