サインイン

空のサンドボックスは開発者の体験を損なう

投稿日 8月 3日, 2026年
オレグ・シェラジェフ
オレグ・セラエフ

私はDockerサンドボックスの開発に携わっているので、分離性、マイクロVM、使い捨てファイルシステム、ブラスト半径など、優れたインフラストラクチャに関するあらゆることについてよく話します。

しかし、私が日常的に使用する際に最もよく使うDocker Sandboxesの機能はキットです。

キットというのは、実際の作業でサンドボックスを使ってみるまでは、単なるパッケージングの細部のように聞こえるかもしれません。何もない砂場は、良い境界線となる。また、それは（最終的には）一時的で空虚なものとなり、その組み合わせは、煩わしさと繰り返しの設定作業を意味する。

エージェントは、クリーンなファイルシステム、ベースラインとなる制限付きネットワーク、およびクリーンな認証情報環境を受け取ります。そうなると、 gcloud 、Java、Maven、内部CLI、パッケージレジストリの認証情報、そしてチームが長年蓄積してきた暗黙知を凝縮した特別なスキルがすぐに必要になります。

キットは、その儀式から逃れるための脱出口なのだ。キットを使用すると、サンドボックスが必要とするもの、それらをどのように入手するか、どこまでアクセスできるか、使用できる認証情報などを記述し、サンドボックスの起動時にその記述を適用できます。

空ということは、セットアップ作業を意味します。

サンドボックスの一般的な考え方は、セキュリティの観点からのものだ。つまり、危険なものを境界の内側に配置し、影響範囲を制限するというものだ。

開発者がツールを使い続けるのは、アーキテクチャ図に明確な境界線があるからという理由だけではない。彼らは、代替手段よりもワークフローが煩わしくない場合に限り、ツールを使い続ける。

まっさらなサンドボックスは、開発者が実際に始める場所とは全く異なる場所から始まります。実際の開発者のマシンには、SDK、パッケージマネージャー、クラウドCLI、シェル設定、ローカル認証情報、プロジェクトドキュメント、キャッシュされたツール、そして誰も記憶から再構築したくない設定ファイルなどが含まれています。その一部は優れた技術によるものだ。その一部は考古学的なものだ。どちらも、エージェントがタスクを完了できるかどうかに影響します。

失敗はめったに劇的なものではない。エージェントはパッケージのインストールに数分を費やし、ブロックされたレジストリにアクセスし、決してアクセスすべきではないAPIキーを要求する。すると、サンドボックスがあなたと作業の間にある障害物のように感じられるようになる。

その時点で、開発者は選択を迫られる。隔離された環境を準備するために10分を費やすか、ホスト上でエージェントを実行して作業を続けるかだ。

どちらが勝つかは、誰もが分かっている。

SBXキットとは何ですか？

キットのドキュメントでは、キットはspec.yamlファイルとオプションファイルで構成されると説明されています。より分かりやすい考え方はこうだ。キットとは、サンドボックスと、その中で利用したいツールとの間の契約のことである。

キットには以下のツールをインストールできます。

schemaVersion: "1"
kind: mixin
name: jq

commands:
  install:
    - command: "apt-get update && apt-get install -y jq"

これは最小バージョンです。便利なキットはたいてい、より多くのことができる。エージェントは/home/agent/またはワークスペースにファイルをドロップしたり、非機密の環境変数を設定したり、起動コマンドを実行したり、バックグラウンドサービスを開始したり、 CLAUDE.mdやAGENTS.mdなどのファイルにエージェントのコンテキストを追加したりできます。

また、サンドボックスが接触できる外部世界についても説明できます。

network:
  allowedDomains:
    - api.example.com
    - "*.cdn.example.com"
  deniedDomains:
    - telemetry.example.com

そして、実際の機密情報をマイクロVMにコピーすることなく、認証情報を接続できます。標準的なパターンでは、認証情報はホスト上に保持され、エージェントには番兵値が割り当てられ、サンドボックスプロキシはリクエストが承認されたサービスに送信される場合にのみ実際のヘッダーを挿入します。

network:
  allowedDomains:
    - api.example.com
  serviceDomains:
    api.example.com: my-service
  serviceAuth:
    my-service:
      headerName: Authorization
      valueFormat: "Bearer %s"

credentials:
  sources:
    my-service:
      env:
        - MY_SERVICE_API_KEY

environment:
  proxyManaged:
    # Agent sees "proxy-managed"; the host proxy injects the real token.
    - MY_SERVICE_API_KEY

サンドボックス内では、エージェントはMY_SERVICE_API_KEY=proxy-managed認識します。本当の秘密はホストにのみ明かされる。プロキシは送信時にヘッダーを置き換えます。

その違いこそが、認証情報サポートがキット契約に含まれるべき理由です。サンドボックスはエージェントをホストの機密情報から遠ざけるために存在するのだとしたら、それらの機密情報をマイクロVMにコピーするのは、奇妙な祝い方だろう。

スクリーンショットは23で2026 07 31。05。29

ミックスインキットが一般的です

仕様書には2種類のキット形状が記載されている。kind: sandboxキットは、イメージ、エントリポイント、ポリシーなど、エージェントのランタイム全体を定義します。エージェントを構築する際には、それを使用してください。

ほとんどの統合はミックスインで行うべきです。

ミックスインキットは、既存のサンドボックスに1つの機能を追加するものです。それはツールをインストールし、狭いネットワークパスを開き、認証情報を接続し、エージェントがその機器を使用するために必要な十分な指示を与えます。ランタイムはエージェントキットに付属しています。

それは私が自分のキットのほとんどで使用している形状です。例えば、私が毎日使い続けているキットは、 agy 、 yt-transcript 、 tesslです。

YouTubeキットはまさにあなたが想像する通りのものです。サンドボックスに文字起こしやメディアのメタデータを取得するためのツールを提供しつつ、新しいサンドボックスを小さな依存関係の考古学プロジェクトに変えることなく、それらを可能にします。Tesslのキットはさらに直接的です。これにより、サンドボックス内で実行されるエージェントにスキルが組み込まれるため、中世の農民のように手動でスキルを注入する必要がなくなります。

ミックスインの良いところは、重ねて使えることだ。

巨大な「オレグのノートパソコン一式をマイクロVMに詰め込んだ」キットは、最初は面白いかもしれないが、その後はメンテナンス上の問題になるだろう。明確な作業内容の小さなキットが欲しいのですね。

  • JDK、Maven、SDKMAN!、チームMaven設定をインストールし、Springドキュメントへのリンクを提供するJavaキット。
  • CLIをインストールし、適切なGoogle APIドメインを許可し、プロキシ経由で認証情報を送信するgcloudキット。
  • エージェントがあなたのメールとGoogleドキュメントにアクセスできるようにするGoogle Workspaceキット。
  • Tesslのキットを使えば、スキルをサンドボックスに取り入れることができます。
  • yt-dlp 、 ffmpeg 、およびそれらに必要なネットワークアクセスを追加するYouTube文字起こしキット。

次に、そのタスクのためのサンドボックスを構築します。

sbx run claude . \
  --kit docker.io/acme/sbx-java-kit:1.0 \
  --kit docker.io/acme/sbx-gcloud-kit:1.0 \
  --kit docker.io/acme/sbx-tessl-kit:1.0

同じエージェントが、今度は別の契約内容で業務を開始する。

その時点で、キットは単なる包装手段ではなく、生産性向上に役立つ機能へと変化する。サンドボックス自体は使い捨てのままだが、その設定は再現可能になる。開発者は、環境を破棄しても、それを再構築する方法に関する知識を破棄する必要はない。

分かち合うことは思いやりです

ローカル設定スクリプトは、2人目のユーザーが必要とするまでは問題ありません。その時点でそれらは文書となり、文書は極めて迅速に古びていく。そして、正常な処理経路が欠落していたため、誰かが設定ファイルにトークンを貼り付けた。

キットがあれば、そのセットアップを設置する場所が確保できる。

ベンダーは、自社のCLIまたはAPI用のキットを公開できます。企業内部では、パッケージレジストリ、クラウドアカウント、企業プロキシ証明書、優先言語ツールチェーンなどにも同様のパターンが適用されます。ユーザーは、Wikiページの代わりに--kitフラグを1つ受け取り、軽い不安感を覚える。

ここでは流通が重要だ。キットは、ローカルディレクトリ、Git URL、およびOCIアーティファクトをサポートしています。共有キットの場合、OCI配布はユーザーがバージョン管理された成果物を直接参照できるため、最も適切な方法です。

sbx run claude --kit docker.io/acme/sbx-my-product-kit:1.0

ソースコードはGitHubなど、チームが共同作業を行う場所に保存してください。成果物をDocker Hubまたは他のOCIレジストリに公開します。ソースリポジトリは、人々がレビューを行い、パッチを適用し、丁寧に苦情を申し立てる場所です。登録システムがあるからこそ、このキットは使いやすくなっているのです。

全体として

セキュリティは、キットに気を配るべき十分な理由です。ネットワークと認証情報の契約が明確化されることは、それ自体が有益である。日常的な使用における理由はもっとありふれたものだ。キットを使うことで、サンドボックスを開発ツールとして維持しやすくなる。

空の砂場は境界線である。設定済みのサンドボックスとは、エージェントが実際に動作できる場所のことです。キットとは、その構成を再現可能、検証可能、共有可能にするための手段である。

キットのドキュメントとサンプルがあれば、形状を一から考案することなく、最初のミックスインキットを構築できます。

開発者との接触を避けることが少なくとも同じくらい便利な場合にのみ、孤立状態は存続する。

製品

関連記事