2024年後半、Appleは珍しいことをした。キーノートなし、プレスリリースなし、Apple のプラットフォーム機能に通常伴う華やかさなし。macOSにネイティブLinuxコンテナサポートを搭載したのだ。プロジェクトは「container」という名前でGitHubにオープンソース化された——小文字、ブランディングなし、マーケティングなし。Apple Silicon上でOCI互換のLinuxコンテナをネイティブに近いパフォーマンスで実行するSwiftバイナリだ。
ほとんどの開発者は気づかなかった。Docker DesktopがmacOSのコンテナ事情を依然として支配しており、気づいた少数の人々も、外部に漏れた内部ツールだろうと思った。しかし、macOS上で軽量かつ安全な隔離を必要とするソフトウェアを構築する人にとって、Apple Containerは静かに革命的だった——そしてNanoClawはこれを基盤に構築した最初のプロジェクトの一つだった。
なぜDockerでは不十分だったのか
Apple ContainerがAIエージェントにとってなぜ重要かを理解するには、DockerがmacOS上で実際に何をしているかを理解する必要がある。Docker Desktopはコンテナをネイティブに実行しない——Linux仮想マシンを実行し、そのVM内でコンテナを実行する。Mac上のすべてのDockerコンテナは、実際にはDocker Desktopが管理する隠れたLinux VM内で実行されている。これは動作するが、オーバーヘッドを伴う：VMにはRAMが必要で（デフォルトで通常2〜4GB）、すべてのコンテナ操作にレイテンシが追加され、NanoClawが起動する前にDocker Desktopがバックグラウンドサービスとして実行されている必要がある。
たまにPostgresコンテナを起動するWeb開発者にとって、このオーバーヘッドは見えない。しかし、会話ターンごとに新しいコンテナを起動し、レスポンス完了時に破棄するNanoClawにとって、このオーバーヘッドがボトルネックになる。VMオーバーヘッドのせいで起動に2秒かかるコンテナは、キビキビしたAIアシスタントをもっさりしたものに変える。WhatsAppメッセージが本来より3秒余計にかかると、ユーザーは気づく。
Apple ContainerはVM層を完全に排除する。Appleの Virtualization.frameworkを使って軽量なLinuxカーネルをハードウェア上で直接実行し、コンテナはそれぞれ独自のVMを実行するのではなくそのカーネルを共有する。結果として、コンテナ起動時間は秒単位ではなくミリ秒単位、メモリオーバーヘッドはギガバイト単位ではなくメガバイト単位、I/Oパフォーマンスはネイティブに近い。
NanoClawでの使い方
NanoClawのコンテナモデルはシンプルだが意図的だ。WhatsAppでメッセージが届くと、NanoClawは特定のマウントセットを持つコンテナを起動する：プロジェクトソースコード（読み取り専用）、グループのCLAUDE.mdメモリファイル（読み書き可能）、そのグループにスコープされた書き込み可能なワークスペース。APIキーはJSONペイロードとしてstdin経由で渡される——コンテナ内のファイルシステムや環境変数に触れることはない。
macOSでは、NanoClawはApple Containerを検出してデフォルトで使用する。Linuxでは、Dockerにフォールバックする。コンテナ内のエージェントコードはどちらでも同一だ——ホストOSに関係なく、Linux環境で実行されるAgent SDK付きのClaude Codeセッションだ。コンテナイメージにはChromiumとagent-browserが含まれており、ホスト上でブラウザを実行することなくエージェントにWeb検索とページ閲覧の能力を与える。
macOSでの実用的な違いは速度だ。Apple Containerでのコンテナ起動時間は約200〜400ms——通常のAIレスポンス時間を超える遅延をユーザーが感じないほど高速だ。Docker Desktopでは同じ操作に1.5〜3秒かかり、これは体感できる。1日に数十のメッセージを処理すると、その差は明らかに異なるユーザー体験に積み重なる。
セキュリティモデル
Apple ContainerはDocker Desktopにはできない方法でmacOSのセキュリティプリミティブを継承する。コンテナはAppleのサンドボックスフレームワーク下で実行され、他のサンドボックス化されたmacOSアプリケーションと同じセキュリティポリシーの対象となる。明示的にマウントされたパス外へのファイルアクセスは、コンテナランタイムによって拒否されるだけでなく、オペレーティングシステム自体によって拒否される。
これはプロンプトインジェクションのため、AIエージェントにとって特に重要だ。悪意のあるプロンプトがエージェントを騙して~/.ssh/id_rsaや~/Documents/tax-returns.pdfを読み取ろうとしても、その試みはアプリケーションレベルではなくOSレベルで失敗する。NanoClawのマウント検証コードのバグを悪用して制限を回避することはできない。制限はNanoClawではなくmacOSのカーネルによって強制されるからだ。
ネットワーク隔離も同様に重要だ。各コンテナは独自のネットワーク名前空間を持ち、エージェントはローカルネットワークをスキャンできず、localhost上で実行されている他のサービスにアクセスできず、他のエージェントコンテナと通信できない。唯一のネットワークアクセスは、AIプロバイダーとエージェントが閲覧するウェブサイトへのアウトバウンドHTTPSだ。これは、侵害されたエージェントが同じマシン上の他のサービスにピボットしようとする攻撃クラスに対する意味のある防御だ。
Macユーザーにとっての意味
NanoClawをMacで実行している場合——個人利用で最も一般的なデプロイメントだ——Apple ContainerはDocker Desktop不要でDockerグレードの隔離を提供する。2〜4GBのRAMを食うバックグラウンドVMなし。管理すべきDocker Desktopライセンスなし。NanoClawが起動する前に実行されている必要のあるDockerデーモンなし。
セットアップは最小限だ。NanoClawのブートストラップスクリプトがmacOSを検出し、Apple Containerを確認し、自動的に設定する。Apple Containerがインストールされていなければ、Dockerにフォールバックする。どちらも利用できなければ、コンテナ隔離なしで実行する（警告付き）。目標は、コンテナ隔離が追加セットアップを必要とするオプトイン機能ではなく、デフォルトであることだ。
macOSとLinuxマシンが混在する環境へのデプロイメントでNanoClawを評価するチームにとって、コンテナ抽象化は同じ設定がどこでも動くことを意味する。Apple ContainerとDockerのどちらが隔離を提供しているかに関係なく、エージェントの動作は同一だ。唯一の違いはパフォーマンスだ——そしてその指標では、Apple Silicon上のApple Containerに勝つのは難しい。
AppleはAIエージェントのためにContainerを作ったわけではない。自社の内部ツールと、macOS上で軽量なLinux環境を必要とする開発者のために作った。しかし、それらのユースケースに適した特性——高速起動、低オーバーヘッド、強力な隔離、ネイティブパフォーマンス——は、まさにAIエージェントのサンドボックスに必要な特性だ。時に、ある仕事に最適なツールは、まったく別の仕事のために作られたものだったりする。