AIエージェントサンドボックスは、生成されたコードをホストシステムから分離します。しかし、その詳細 — 分離の仕組み、エージェントが持つネットワークアクセス、ファイルの保存場所、シークレットの処理方法 — は実装によって大きく異なります。このFAQは、最も一般的な質問を1つのリファレンスにまとめ、各分野の詳細記事へのポインタを提供します。
サンドボックス分離モデル
AIエージェントサンドボックスにおける「分離」とはどういう意味ですか？
分離とは、エージェントのコード、ファイル、プロセス、ネットワークアクセスが、ホストシステムや他のテナントに影響を与えることができない境界のある環境に閉じ込められていることを意味します。実際には、分離はスペクトラムです。プロセスレベルの分離はOSプリミティブ（名前空間、cgroup、seccomp）を使用してシステムコールとリソースアクセスを制限します。コンテナ分離はファイルシステムとネットワーク名前空間の境界を追加します。マイクロVM分離は、ワークロードを独自のゲストカーネルを持つ軽量仮想マシンでラップします。スタックを上がるごとに境界の強度は増しますが、起動オーバーヘッドと運用の複雑さが多少増加します。詳細な評価フレームワークについては、Firecracker for AI Agent Sandboxes を参照してください。
Dockerはエージェント生成コードの実行に十分ですか？
コンテナは再現可能なイメージと優れたリソース制御を提供しますが、同じホスト上のすべてのコンテナはホストカーネルを共有します。カーネルの脆弱性や、seccompフィルタをすり抜けるシステムコールは、他のワークロードに影響を与える可能性があります。リスクが低く、信頼されたコードまたはそれに近いコードを実行する短命なタスクの場合、適切に強化されていれば（特権モードなし、最小限のケイパビリティ、Dockerソケットのマウントなし、可能な限り読み取り専用のルートファイルシステム）、コンテナで十分なことがよくあります。パッケージをインストールしたり、サブプロセスを生成したり、任意のシェルコマンドを呼び出したりする可能性のある、信頼できないAI生成コードの場合は、より強力な境界を評価する価値があります。答えは実際の脅威モデルに依存します。各分離レベルの検証チェックリストについては、AI-Generated Code Sandbox: Requirements for Production Apps を参照してください。
コンテナ分離とマイクロVM分離の違いは何ですか？
主な違いはカーネル境界です。コンテナはホストカーネルを共有します。マイクロVMはそれぞれ、ハードウェア仮想化（KVM）を利用した軽量仮想マシン内でゲストカーネルを実行します。Firecrackerのような技術を使用したマイクロVMベースのサンドボックスは、従来のVMの完全なオーバーヘッドなしにVMスタイルの境界を提供します。起動レイテンシは高速になるように設計されており、デバイスモデルは攻撃対象領域を減らすために最小限に抑えられ、ゲストは設計上ホストカーネルから分離されています。実用的な意味合いとしては、ゲスト内のカーネルエクスプロイトはホストや他のゲストに自動的に影響を与えませんが、共有カーネルのコンテナモデルでは影響を与える可能性があります。マイクロVM境界が役立つ場合と、問題全体を解決しない場合については、Firecracker for AI Agent Sandboxes を参照してください。
サンドボックスはエージェントごと、ユーザーごと、タスクごとに存在しますか？
それはプラットフォームとアプリケーションの設計方法に依存します。マルチテナントアプリケーションにおける最も安全なパターンは、エージェントの実行ごと、またはタスクごとに1つの分離されたサンドボックス環境を持つことです。つまり、各ユーザーのセッションは、独自のプロセスツリー、ファイルシステム、ネットワーク名前空間、および認証情報スコープを持ちます。ユーザー間や無関係なタスク間でサンドボックスを共有することは、プロダクションエージェントアプリケーションにおける状態漏洩の最も一般的な原因です。プラットフォームを評価する際は、同時セッションがAPIルーティングレベルだけでなく、ファイルシステム、プロセス、ネットワークレベルで分離されていることを確認してください。セッションごとの分離チェックリストについては、AI-Generated Code Sandbox: Requirements for Production Apps を参照してください。
サンドボックスEgressとネットワークポリシー
AIエージェントはサンドボックスからアウトバウンドネットワーク呼び出しを行えますか？
サンドボックスのEgressポリシーに依存します。デフォルトでは、多くのサンドボックスがアウトバウンド接続を許可しており、これはWeb調査、API呼び出し、パッケージインストールに便利です。信頼できないコードを実行するプロダクションワークロードでは、デフォルトでオープンなEgressはリスクです。侵害された、または誤動作しているエージェントは、データを外部に持ち出したり、内部メタデータサービスにアクセスしたり、任意のURLから予期しないコードをプルしたりする可能性があります。より強力なプロダクションポスチャは、許可された送信先の明示的な許可リストを持つ、デフォルト拒否のEgressです。どのポリシーを選択するにしても、それは明示的でログに記録されるべきです。ネットワーク制御の評価方法については、Firecracker for AI Agent Sandboxes を参照してください。
サンドボックス内でDNSはどのように制御されますか？
DNSはEgressポリシーにおける一般的なギャップです。HTTP送信先の許可リストは、DNS解決を自動的に制限しません。任意のドメイン名を解決できるエージェントは、HTTPがブロックされている場合でも、ネットワークトポロジを推測したり、内部名をプローブしたり、DNSをサイドチャネルとして使用したりする可能性があります。一貫性のあるEgressポリシーのためには、DNS解決も一貫して処理されるべきです。許可リストを尊重する内部リゾルバを指すか、承認されたドメインへの解決を制限します。サンドボックスプロバイダーに、DNSがより広範なEgressポリシーとどのように関連してスコープされているかを確認してください。
ネットワーク制限付きセッション中、パッケージフェッチはどのように制御されますか？
パッケージインストールはネットワーク操作です。Egressが許可リストに制限されている場合、許可リストにはエージェントが正当に必要とするパッケージレジストリを含めるか、サンドボックスが信頼できるネットワーク内にプルスルーキャッシュを提供する必要があります。プルスルーキャッシュには、どのパッケージがフェッチされたかを確認し、予期しない依存関係をキャッチし、冗長なEgressを減らすことができるという検査ポイントとしての利点があります。再現性が柔軟性よりも重要なワークロードでは、事前に作成されたサンドボックステンプレートを使用するチームもあり、実行時のパッケージフェッチを完全に排除します。ランタイムインストールの管理については、Package Installs セクションを参照してください。
ファイルアクセスとホストファイルシステム
サンドボックス化されたエージェントはどのようなファイルアクセス権を持っていますか？
サンドボックス化されたエージェントは、そのワークスペースに明示的にマウントされたファイルにのみアクセスできる必要があります。コーディングエージェントの場合、それはチェックアウトされたリポジトリと生成されたアーティファクト用の作業ディレクトリかもしれません。データ分析エージェントの場合、アップロードされたCSVファイルと出力フォルダかもしれません。エージェントは、ホストファイルシステム、他のテナントのワークスペース、アプリケーションサーバーのシークレット、またはマウントされたパス外のシステムディレクトリに到達できないようにする必要があります。優れたプラクティスは、ソースマテリアルを読み取り専用でマウントし、生成されたアーティファクト用に別の読み取り/書き込み出力ディレクトリを提供することです。ツールごとのファイルシステムマウントのスコープ設定方法については、MCP Server Sandbox: Isolated MCP Servers with Filesystem, Secrets, and Network Controls を参照してください。
ホストファイルシステムはサンドボックス内部からアクセス可能ですか？
アクセス可能であるべきではありません。正しく設定されたサンドボックス（コンテナまたはマイクロVM）は、エージェントのビューを自身のゲストファイルシステムに制限します。サンドボックス内部からホストファイルシステムにアクセスすることは、設定の失敗であり、期待される動作ではありません。この境界を破る一般的な間違いには、広範なディレクトリ（開発者のホームディレクトリや / など）のマウント、コンテナでの特権モードの使用、またはDockerソケットのサンドボックスへのマウントが含まれます。プラットフォームを評価するか、独自に構築する際は、何がマウントされているか、ルートファイルシステムの権限は何か、シンボリックリンクエスケープやアーカイブ抽出トリックが意図されたワークスペース外のパスに到達できるかを確認してください。
セッション終了後、ファイルはどうなりますか？
エフェメラルセッションの場合、セッションが終了すると作業ディレクトリと生成されたすべてのファイルは破棄されます。これはコード補完、評価実行、および再現性が継続性よりも重要なタスクに適したデフォルトです。永続的ワークスペース（長期実行コーディングエージェント、反復的な開発セッション）の場合、ファイルはセッション内の実行呼び出しをまたいで存続し、プラットフォームがワークスペースの永続化やスナップショットをサポートしている場合はセッション終了後も保持される可能性があります。回答すべき重要な質問は、保持されたワークスペースを誰が所有するか、いつクリーンアップされるか、あるユーザーのワークスペースが別のユーザーに漏洩する可能性があるかです。永続化モデルのチェックリストについては、AI-Generated Code Sandbox: Requirements for Production Apps を参照してください。
セッション状態と永続化
サンドボックスセッションはステートフルですか、それともエフェメラルですか？
両方のパターンが存在し、異なるワークロードに役立ちます。エフェメラルセッションは、すべてのタスクに対してクリーンなベースラインから開始します — 蓄積されたパッケージ、ファイル、履歴はありません。これらは理解しやすく、評価実行やワンショットコード実行に最適です。ステートフルセッションは、複数の実行呼び出しをまたいでファイル、インストール済みパッケージ、シェル履歴、環境状態を保存するため、マルチステップのコーディングエージェント、インタラクティブなデータ分析、長期実行ワークフローに必要です。ほとんどのプロダクションプラットフォームは両方をサポートしています。トレードオフは、ステートフルセッションには明示的なクリーンアップポリシーとより慎重なテナント分離が必要なことです。
管理されたサンドボックスでは、状態はどのくらい持続しますか？
セッション期間はプラットフォームとプランによって異なります。一部のプロバイダーはデフォルトのセッションタイムアウト（通常60分〜24時間）を設定しており、その後セッションは終了し、スナップショットまたは外部ストレージに永続化されない限り状態は失われます。長時間実行されるエージェントワークフロー（LLM呼び出しの間、数分から数時間一時停止する可能性があるセッション）では、アイドル時間の課金を回避しながら状態を保持するために、セッションの一時停止と再開、または自動一時停止をサポートするプラットフォームが必要です。最大セッション長と、タイムアウトが発生した場合の進行中の状態を確認してください。Novita Agent Sandboxは最大24時間のセッションをサポートし、アイドル時間管理のための一時停止/自動再開機能を文書化しています。機能比較については、Novita Sandbox: A Cost-Effective Alternative to E2B Pro with Seamless Compatibility を参照してください。
セッションを一時停止および再開できますか？
一部のプラットフォームは一時停止と再開をサポートしており、セッションがディスクに一時保存され、後で同じ状態から再開できます。これは、ステップ間でLLM応答を待つエージェント、高コストなワークロードのレート制限、および時間をかけて複数のユーザーインタラクションに及ぶセッションに役立ちます。確認すべき重要な点は、一時停止されたセッションをどの程度の期間中断したままにできるか、一時停止中に保持されていたネットワーク接続はどうなるか、セッション開始時に注入された認証情報が再開後も有効か、更新が必要かです。
サンドボックス状態をスナップショットして再利用できますか？
テンプレートとスナップショットは関連していますが、異なります。テンプレートは、新しいセッションが開始する事前構築されたベースライン環境（ランタイム、ツール、承認済みパッケージ）です。スナップショットは、実行中のセッションの現在の状態をキャプチャし、将来のセッションの開始点として使用します。テンプレートはセッションごとの起動オーバーヘッドを削減し、すべてのエージェントが一貫した管理されたベースラインから開始することを保証します。スナップショットは、部分的な作業を保存したり、反復的なジョブをウォームスタートしたりするのに役立ちます。どちらにもガバナンスが必要です。誰が作成できるか、誰が読み取れるか、どのテナントに属するか、どのようにバージョン管理されるかです。
パッケージインストールとランタイム依存関係
エージェントは実行時にパッケージをインストールできますか？
ほとんどのサンドボックス環境は、デフォルトでランタイムパッケージインストール（pip install、npm install、apt-get など）を許可しています。これは多くのエージェントワークロードで必要とされるためです。問題はインストールが許可されているかどうかではなく、各インストールが管理されているかどうかです。管理されていないパッケージインストールは、サンドボックスにおける最もリスクの高い操作の1つです。実行時に外部コードを実行環境にプルし、任意のコマンドを実行する可能性のあるインストール後スクリプトを含むことができ、サプライチェーンリスクをもたらす可能性があります。
ランタイムパッケージインストールを管理するポリシーは何ですか？
プロダクションパッケージポリシーには通常、レジストリ許可リスト（承認されたパッケージレジストリまたはミラーからのみフェッチ）、プルスルーキャッシュ（実行前に入力内容を検査）、インストールログ（すべてのインストールについてパッケージ名、バージョン、ソース、結果を記録）、およびオプションのオフラインモード（依存関係をテンプレートに事前に組み込み、再現性が重要な評価パイプラインではランタイムインストールを禁止）の組み合わせが含まれます。適切なポリシーはワークロードに依存します。コードのデバッグを支援するコーディングエージェントは柔軟なパッケージアクセスを必要とするかもしれませんが、自動評価パイプラインはおそらく凍結された環境から実行する必要があります。実装例については、Build an AI Data Analyst with Sandboxed Python and Controlled Package Access を参照してください。
シークレットと認証情報の処理
サンドボックス内でシークレットと認証情報はどのように処理されますか？
シークレットは狭く注入されるべきです — 特定のタスクに必要な認証情報のみ、そのセッションの期間だけです。一般的なアンチパターンは、すべてのAPIキーを含む広範な環境ファイルをすべてのセッションにマウントすることです。これにより、侵害された場合、すべてのセッションがそのファイル内のすべての認証情報にアクセスできるようになります。タスクにスコープされた短期間のトークンを優先し、ハードコーディングよりも注入メカニズム（環境変数またはマウントされたファイル）を優先してください。最も機密性の高い認証情報については、明示的に承認されたプロセスのみに値を提供するランタイムシークレットAPIが、すべてのプロセスが利用できるフラットな環境変数よりも強力な分離を提供します。
モデルはサンドボックスに注入された環境変数を参照できますか？
はい、環境変数がモデルのコードが実行されるプロセスに注入されている場合、参照できます。環境変数は、デフォルトで同じセッション内のすべてのプロセスから参照可能です。モデルはコンテキストウィンドウから直接読み取ることはできませんが、サンドボックス内で実行される生成コードは、os.environ、process.env、または同等の方法で読み取ることができます。これが狭いスコープが重要である理由です。タスクに必要な認証情報のみを注入し、漏洩した認証情報の有用な期間を制限するために短期間のトークンを優先してください。編集（Redaction）はアプリケーションの責任です。シークレットがエラーメッセージやprint文に表示される可能性がある場合は、デフォルトで完全なstdoutをログに記録しないでください。
セッション終了時、シークレットはどうなりますか？
環境変数とマウントされたシークレットファイルは、セッションのティアダウンの一部としてクリーンアップされる必要があります。プラットフォームがセッション間で状態を保持する場合（スナップショット、永続ボリューム）、ファイルシステムに書き込まれた認証情報や認証情報プロバイダーによってキャッシュされた認証情報もクリーンアップまたはローテーションされることを確認してください。再開可能なスナップショット内の古い認証情報はリスクです。セッションティアダウン後、スナップショットには元のセッション期間中のみ有効だったトークンが保持されるべきではありません。
監査ログと観測可能性
サンドボックスではどのようなイベントがログに記録されますか？
有用なサンドボックス監査記録には、セッションの作成とティアダウン（セッションID、テナント、テンプレートバージョン、リソース割り当て、期間）、実行イベント（実行されたコードまたはコマンドカテゴリ、開始/終了時間、終了ステータス）、パッケージインストール（名前、バージョン、ソース、結果）、アウトバウンドネットワークコンタクト（ドメイン、IP、ポート）、特定のパスからの読み取りまたは書き込みが行われたファイル、およびクリーンアップ結果が含まれます。目標は、監査ログを第二のシークレットストアにすることなく、エージェントの動作を事後的に再構築可能にすることです。生の顧客ファイル、完全なコマンド出力、完全なプロンプトは、特にそのデータ向けに設計された保持およびアクセス制御がない限り、一般に監査ログに含めるべきではありません。
誰が監査ログにアクセスできますか？
監査ログへのアクセス制御は、オペレーター、および関連する場合はテナントにスコープされるべきです。マルチテナントプラットフォームでは、あるテナントの監査記録が他のテナントから見えてはいけません。コンプライアンス重視のデプロイメントでは、監査証跡は改ざん防止可能であり、必要な期間保持され、承認されたレビューア（セキュリティチーム、コンプライアンスオフィサー）がオンデマンドでアクセスできる必要があります。サンドボックスプロバイダーに、デフォルトで提供されるログ保持期間、ログを独自のSIEMやストレージにエクスポートできるかどうか、ログデータを保護するアクセス制御について確認してください。
コンプライアンスとセキュリティレビュー
サンドボックスを本番環境で使用する前に、どのようなコンプライアンスレビューが必要ですか？
具体的な要件は業界や法域によって異なりますが、本番エージェントシステムに関する標準的な質問には次のものが含まれます。どのようなデータがサンドボックスに入るか（そしてそのデータはGDPR、HIPAA、SOC 2、またはその他のフレームワークの対象となるか）、サンドボックスはどこでホストされ、データ主権要件を満たしているか、分離モデルは何か、監査人に文書化できるか、認証情報はどのように管理およびローテーションされるか、監査証跡はどのようなものか。ほとんどのセキュリティレビューでは、生成されたコードが本番データベース、内部管理画面、または意図された範囲外の顧客データに到達できるかどうかも質問されます。これらは、単なるベンダー認証ではなく、アーキテクチャ上の制御です。
セキュリティチームはAIエージェントサンドボックスを評価する際にどのような質問をすべきですか？
セキュリティレビューのための実用的な評価チェックリスト：
- 分離: 境界は何か — プロセス、コンテナ、マイクロVM？各エージェントセッションはファイルシステム、プロセス、ネットワークレベルで分離されているか？
- Egress: デフォルトのEgressポリシーは何か？送信先を許可リストに登録できるか？DNSはどのように制御されているか？
- シークレット: 認証情報はどのように注入されるか？タスクにスコープされているか？セッションティアダウン時にクリーンアップされるか？
- 監査: どのイベントがログに記録されるか？誰がログにアクセスできるか？保持期間は？
- データ主権: サンドボックスはどこでホストされているか？デプロイメントを特定のクラウドリージョンまたはアカウントにスコープできるか？
- コンプライアンス体制: プロバイダーは関連する認証（SOC 2、ISO 27001）を保持しているか？共同責任モデルは何か？
- ネットワーク到達性: サンドボックスは内部メタデータサービス、プライベートAPI、または他のテナントのリソースに到達できるか？ラテラルムーブメントはどのように防止されるか？
これらは、単一のベンダーが自動的に満たす要件ではなく、評価するための質問として捉えてください。ベンダー文書内のセキュリティおよびコンプライアンスに関する主張は、現在の製品文書に対して検証する必要があり、額面通りに受け取るべきではありません。規制上または契約上の要件があるチームは、本番展開の後ではなく、前にセキュリティチームにレビューを完了させてください。
BYOC（Bring Your Own Cloud）またはVPCデプロイメントが適切なのはどのような場合ですか？
データ主権要件、ネットワークセキュリティポリシー、または特定のクラウドアカウントからのデータ流出を禁止する規制上の制約が、チームが共有管理サービスよりもBYOCまたはVPCデプロイメントを選択する主な理由です。独自のAWSまたはGCP VPC内でサンドボックスを実行することは、実行環境がネットワーク境界内にあり、クラウドアカウントのアクセス制御が適用され、サンドボックスからのEgressを既存のネットワークポリシーで管理できることを意味します。トレードオフは運用責任です。インフラストラクチャ管理、パッチ適用、スケーリングを自分で担当します。Novita Agent Sandboxは、これらの要件を持つチーム向けの機能として、AWSまたはGCPアカウントへのBYOCデプロイメントを文書化しています。現在の可用性と設定オプションについては、Novita Agent Sandbox documentation で確認してください。
サンドボックス価格とコスト要因
サンドボックスのコストを左右するものは何ですか？
サンドボックスコストは通常、コンピュート時間（vCPUとメモリ、秒または分ごとに請求）、セッションオーバーヘッド（一部のプラットフォームではセッションごとの起動料金）、含まれる無料ティアを超える永続ストレージ、およびアウトバウンドデータ転送（Egress）の組み合わせです。それぞれの相対的な重みはワークロードに依存します。短いセッションのコードインタプリタは主にコンピュート、大きなファイルをダウンロードするブラウザ自動化エージェントは多量のEgressを生成する可能性があり、永続的なコーディングワークスペースはストレージを蓄積します。アイドル時間の処理は主要な差別化要因です。自動一時停止機能を備えたプラットフォームは、サンドボックスがLLM応答を待っている間の課金を停止するため、インタラクティブなワークフローのコストを大幅に削減できます。各価格軸の詳細な内訳については、AI Agent Sandbox Pricing Models: Per-Session, Compute, Storage, and Egress を参照してください。
セッション時間、コンピュート、Egressはコストにどのように相互作用しますか？
ほとんどのワークロードでは、コンピュート時間が支配的です。1 vCPUでの10分間のコーディングセッションは、標準的なレートでの1 GBのEgressよりもコストがかかります。しかし、特定のワークロードでは相互作用が重要です。大規模なトレーニングデータセットをダウンロードするデータエージェントは、コンピュートコストをはるかに上回るEgress料金を発生させます。LLMターン間でセッションを開いたままにするブラウザエージェントは、自動一時停止が有効になっていない場合、アイドルコンピュートを蓄積します。実用的なアプローチは、プラットフォームにコミットする前に、実際のワークロードプロファイルに対して各次元を見積もることです。Novita Agent Sandboxは、実際のvCPUとメモリ使用量に基づいて秒単位で課金し、セッションごとの起動料金はありません。2026年半ば現在、1 vCPUは $0.0000098/s で価格設定されています。（出典: Novita AI pricing page、公開文書で検証済み。予算計画の前に必ず最新レートを確認してください。）
セルフホスティング vs 管理型AIエージェントサンドボックス
チームは管理型サンドボックスではなく、いつセルフホスティングすべきですか？
セルフホスティング（多くの場合Firecrackerまたは同等のマイクロVMレイヤー上で独自のサンドボックスインフラストラクチャを実行すること）は、以下の場合に適しています。データ主権やネットワークポリシーの要件によりサードパーティの管理サービスの使用が禁止されている場合、ワークロード量が多く管理サービスコストが独自インフラの運用コストを超える場合、またはチームに既存のプラットフォームエンジニアリング能力があり、分離モデル、イメージガバナンス、ネットワークポリシーを完全に制御したい場合。セルフホスティングは見た目よりも困難です。カーネル、ルートファイルシステム、イメージ、スナップショット、レートリミッター、メトリクス、クリーンアップ、マルチテナント分離の管理は、実際の作業です。運用範囲の詳細については、Firecracker for AI Agent Sandboxes を参照してください。
管理型サンドボックスがより適しているのはどのような場合ですか？
コーディングエージェント、データ分析ツール、ブラウザ自動化ワークフロー、評価パイプラインを構築しているほとんどのチームにとって、管理型サンドボックスは本番環境へのより迅速な道です。プラットフォームがインフラストラクチャのプロビジョニング、セキュリティ強化、イメージ更新、スケーリング、ライフサイクル管理を処理します。チームはサンドボックス内部ではなく、エージェントアーキテクチャに集中できます。コスト比較は単なるクラウドコンピュートレートだけではありません。分離レイヤーの構築と維持にかかるエンジニアリング時間、それを文書化するためのコンプライアンス作業、そして予期しないことが発生した場合のインシデント対応を考慮に入れてください。専任のプラットフォームエンジニアリング能力のないチームにとって、管理サービスは通常、より迅速に本番環境に到達し、より低い総所有コストを維持します。管理型とセルフホスティングの総コストを比較するためのフレームワークについては、AI Agent Sandbox Pricing Models を参照してください。
チームは管理型サンドボックスプロバイダーを評価する際にどのような質問をすべきですか？
表面的な価格設定を超えた実用的な評価質問：
- セッションごとの分離モデルは何か（マイクロVM、コンテナ、プロセス）？
- デフォルトおよび設定可能なEgressポリシーは何か？
- どのようなパッケージインストールガバナンスオプションがあるか？
- シークレットはどのように注入およびクリーンアップされるか？
- どの監査ログデータが利用可能で、どのようにアクセスするか？
- 必要なティアでのセッション長と同時実行制限は？
- プロバイダーはBYOCまたはVPCデプロイメントをサポートしているか？
- 一時停止/再開動作はどうなっており、課金にどのように影響するか？
- 起動レイテンシはスケール時にどのように動作するか（ウォームプール、スナップショット、コールドブート）？
