Apple ContainerのAI Agentサンドボックス手順

Agentが誤ってホームディレクトリを削除したり、SSH鍵を読み取ったりする状態なら、今週は本番投入を止めてください。Apple SiliconとmacOS 26ではApple ContainerでAgentごとの軽量な仮想マシン境界を作れますが、ネットワーク、秘密情報、ファイル書き込み、停止後の破棄まで設計して初めて実用的な隔離になります。

この記事を読むべき方

個人MacでコーディングAgentを試し、誤操作や依存パッケージの危険性を抑えたい開発者向けです。ローカルのAgent環境をリモートMacへ移し、同じイメージと権限で運用したいプラットフォームエンジニアにも適しています。コード実行の基準を作るセキュリティ担当者は、最後の破壊的テストまで確認してください。

最終更新：2026年8月17日。Apple Containerの対応OS、リリース状況、制限事項は公式リポジトリ、公式リリース一覧、技術概要で確認しています。

Apple ContainerのAI Agentサンドボックスが担当する範囲

Apple Containerは、OCI互換イメージをMac上のLinux環境として実行し、各コンテナを軽量な仮想マシンで動かす仕組みです。Appleの公式資料ではApple Siliconが必要で、macOS 26を対応環境としています。2026年8月17日時点の最新リリース表示は1.2.2ですが、プロジェクトは継続開発中であり、リリース間の互換性や挙動を固定的に見積もるべきではありません。対応環境の説明と1.2.2の変更内容を導入前に確認してください。

この境界が守るのは、主にAgentが実行するLinuxプロセスとMacホストの間です。ホストのディレクトリを読み書き可能で渡せば、そのディレクトリ内のデータは保護されません。さらに、ネットワーク出口が無制限なら、漏えいした情報を外部へ送信できます。API鍵を環境変数や共有ファイルへ置けば、Agentのプロセスや依存スクリプトから読み取られる可能性があります。

したがって、隔離の実体は次の4層です。

• 仮想マシン境界：AgentのLinux実行環境をMac本体から分離します。
• ファイル境界：入力、書き込み可能な作業コピー、結果出力先を分けます。
• 通信境界：モデルAPI、パッケージ取得先、コードホスティング先を許可制にします。
• 秘密情報境界：長期鍵を渡さず、タスク単位の短期資格情報にします。

OpenAIも高能力Agent向けの対策として、隔離されたテスト環境、制限されたネットワークとツール、監視、サンドボックス実行を挙げています。Astraは2026年8月17日時点で未公開のモデルであり、ここでは能力や公開日を推測せず、コード実行を隔離する必要性の背景としてのみ扱います。OpenAIの公開説明が示すように、サンドボックス単体ではなく複数の制御を重ねる考え方が必要です。

導入前に確認する3つの失敗条件

1．ホストの対応範囲を先に固定する

最初にApple Silicon、macOS 26、Apple Containerの導入版を記録します。旧版macOSで動作したとしても、公式に同じ対応範囲や同じネットワーク機能が保証されるとは限りません。Appleの技術概要では、macOS 15では複数ネットワークやコンテナ間通信に制限があると説明されています。macOS 15の制限事項を回避策としてではなく、移行判断の材料として使ってください。

2．イメージと作業領域を再現可能にする

Agent用イメージはOCI形式で固定し、タグだけでなくダイジェストも記録します。作業用リポジトリは本番のクローンではなく、削除可能な検証用コピーにします。ホスト側のホームディレクトリ、.ssh、クラウド資格情報の保存場所は、最初の試行ではマウントしません。

3．失敗後に戻せる手順を残す

導入、更新、停止、削除、イメージ整理のコマンドを作業記録に残します。特にバージョン更新では、サービスを停止してから変更する必要があるため、更新前の版、イメージ、設定ファイル、検証結果を保存しておくと復旧判断が早くなります。

第一段階：最小構成で1タスクだけ実行する

まずサービス状態を確認し、必要なら起動します。

container system status
container system start

次に、Agentが必要とするOCIイメージを取得し、検証用ディレクトリだけを作業場所として渡します。実際のオプション名は導入版のヘルプで確認し、古い記事のコマンドをそのまま流用しないでください。

mkdir -p ~/agent-sandbox/input
cp -R ./sample-repository ~/agent-sandbox/input/repository

container run --rm \
  --name agent-one-shot \
  --mount type=bind,source="$HOME/agent-sandbox/input/repository",target=/workspace \
  agent-image:verified \
  ./run-agent.sh

ここで確認するのは、Agentが依存パッケージを導入できるか、テストを実行できるか、変更結果を作業コピーへ出せるかの3点です。成功しても、ホストの個人ファイルへ触れないこと、不要なポートが公開されていないこと、終了後にコンテナが残らないことを確認します。

Apple Containerの現行リリースには読み取り専用パスやマスク対象パスに関する機能追加もありますが、利用できる構文は版によって差があるため、リリースノートの変更点とcontainer run --helpを照合してください。

第二段階：ネットワーク、鍵、書き込み先を加固する

最初の1時間で、次の順番に制御を追加します。

1. モデルAPIの接続先を許可リスト化します。
2. パッケージレジストリを必要なものだけに限定します。
3. コードホスティング先への通信を個別に許可します。
4. API鍵をイメージ、Dockerfile相当の定義、共有ディレクトリへ書き込みません。
5. 入力は読み取り専用、作業コピーは限定的に書き込み可能、結果出力先は別ディレクトリにします。
6. 破壊的なシェル操作、外部公開、権限変更は人手確認または外部ポリシー層を通します。

認証情報を環境変数で渡す方法は簡単ですが、Agentがenvの内容を読み取ったり、ログへ出力したりできます。より厳しい運用では、ホスト側のプロキシで許可ドメインへだけ資格情報を付与し、仮想マシン内には本物の鍵を置かない方式を検討できます。これはApple Containerそのものの標準機能ではなく、別の制御層として設計してください。

ローカルからリモートMacへ移す時系列

リモート運用では、Macへログインできることだけを確認しても不十分です。次の項目を同じ設定ファイルや生成スクリプトから再現できる状態にします。

• OCIイメージとダイジェスト
• Agentの起動コマンド
• 作業領域のマウント方式
• 許可する通信先
• 秘密情報の注入方法
• タスク終了時の停止、削除、ログ保存
• セッション期限と異常終了時の強制破棄

ローカルMacでは手動操作で済んだcontainer system startや作業ディレクトリの準備も、リモートMacでは自動化し、実行者ごとのアクセス制御を加えます。複数Agentを同時に動かす場合は、作業領域、ログ、ポート、停止処理をタスク単位で分離します。

Macの管理や利用期間を短く検証したい場合は、JexMacのMacレンタル案内で利用形態を確認し、導入後はサポート情報と照合しながら小規模に始めるのが安全です。長期運用へ進む前に、同じイメージで停止、再起動、異常終了から復帰できるかを確認してください。

第一週の受け入れ判定は正常系だけで終えない

Agentがコードを書けたという事実は、サンドボックスが安全だという証明になりません。次の破壊的テストを意図的に実行し、ホスト側の影響とログの追跡可能性を記録します。

• 作業ディレクトリの外へ移動してファイルを書こうとする。
• ホストのSSH関連ファイルや環境変数を読む。
• 許可していない外部ドメインへ接続する。
• 大量のファイル、プロセス、メモリを消費する。
• Agentを途中停止し、再起動後に作業状態を確認する。
• 失敗したタスクのコンテナ、ボリューム、ネットワーク、ログを削除する。
• 結果出力だけを回収し、入力や秘密情報が残っていないか確認する。

評価は「動いたか」ではなく、「越境を検知できたか」「ホストを変更されなかったか」「失敗後に完全破棄できたか」「誰が何を実行したか追跡できるか」で行います。

選択を迷った時の比較表

FirecrackerはLinuxのKVMを使うVMMで、不要なデバイスを減らしたmicroVM、jailer、ネットワークとストレージのレート制限を備えています。公式サイトはユーザー空間コードの起動を最短125ms、microVMの追加メモリを5MiB未満と説明していますが、これはFirecracker側の公開値であり、Apple Containerとの性能比較やMac上での実測値ではありません。Firecracker公式概要を基盤選定の資料として参照してください。

運用開始前のスコアカード

この表で1項目でも未達なら、本番リポジトリや長期有効な資格情報を渡さないでください。特にApple Containerは実行境界を提供しますが、チーム向けのアクセス管理、ジョブ調度、監査、コスト配分を自動的に完成させる製品ではありません。

よくある設計上の疑問

Mac本体のファイルを読ませない設定にする

ホストの便利なディレクトリをまとめてマウントするほど、Agentの作業範囲は広がります。入力用コピー、書き込み用ワークスペース、成果物の回収先を分け、不要になったら作業用ディレクトリごと削除できる構成にします。

macOS 26で一回限りの実行にする

タスクごとに固有の名前と作業ディレクトリを生成し、--rm相当の自動削除を使います。削除機能だけに依存せず、終了後に一覧表示でコンテナ、ボリューム、ネットワークを確認してください。

秘密情報をAgentへ渡す

モデルAPIを使う場合でも、長期鍵を常時公開しない設計にします。許可ドメイン、利用時間、用途を限定し、Agentの標準出力、エラーログ、生成ファイルに鍵が現れていないか検査します。

Firecrackerへ切り替える時期

Linux KVMを使える基盤があり、複数顧客や複数チームのタスクを同一ホストで扱うなら、早い段階でFirecrackerを検討します。Apple ContainerのMac連携を無理に大規模調度へ拡張するより、イメージとタスクAPIを共通化して実行層だけ移す方が保守しやすくなります。

Apple Containerを使う現在の構成は、Macの開発環境と接続しやすい一方、手動の権限設定、Mac単位の運用、外部調度の不足、メモリ回収や互換性確認の負担が残ります。Linux基盤へ移せば密度や多租借には向きますが、Mac固有の開発体験を失い、KVM、監視、調度、更新管理を自分たちで組み立てるコストが増えます。

まずは同じOCIイメージ、同じ権限設定、同じ破壊的テストを、隔離したJexMacのリモートMac環境で小規模に再実行するのが現実的です。長期の高負荷処理や物理インターフェースが必要なら自社保有のMacや専用Linux基盤が適しますが、短期の検証、Agentの移行確認、チーム向けの試験ノードであれば、必要な期間だけMacをレンタルして判断材料を集める方が、先に固定設備を購入するより失敗コストを抑えやすくなります。詳細な利用条件はJexMacの料金案内で確認してください。

よくある質問