Skip to main content
CoreWeave のサンドボックスは、サーバーレス と CoreWeave Kubernetes Service (CKS) のどちらの配置でも、最大 30 日 (2,592,000 秒) 実行できます。エージェント、開発環境、バッチワークロードが処理を完了するのに十分な時間を確保できるよう、サンドボックスの作成時にライフタイムを設定してください。 このガイドでは、開発者向けに、より長いライフタイムをリクエストする方法を説明します。また、管理者向けに、CKS ランナー上のサンドボックスのデフォルトのライフタイムを設定する方法を説明します。

認証を選択する

以下の例は、セクション内で CKS が指定されていない限り、サーバーレスキャパシティ上で実行されます。サンドボックスを所有するアカウントの認証情報を選択してください。キーまたはトークンの取得方法については、認証情報の選択と取得を参照してください。 使用する言語に応じた設定ファイルを、このページのスクリプトを実行する場所と同じディレクトリに保存してください。Python の例では sandbox_auth.py から AUTH をインポートします。TypeScript の例では sandbox-client.mts から client をインポートします。これらのファイルは認証方式を指定するだけで、認証情報自体は保存しません。Python の場合は、仮想環境を有効化した状態で使用してください。TypeScript の場合は、まず npm install @coreweave/cwsandbox@1.0.0 でクライアントをインストールしてください。
SDK の wandb インテグレーションで Forge APIキーを使用します。[WANDB-API-KEY] をご自身の APIキーに置き換えてください。
sandbox_auth.py
CKS に配置する場合は、CoreWeave トークンを選択し、ランナーを有効化したうえで、サンドボックスの作成時または SandboxDefaults で placement_mode="cks" を設定します。TypeScript で CKS を選択するには、CoreWeave トークンを選択し、空でない runnerIds 配列を設定します。Python で auth=AUTH を指定してセッションを作成すると、そのセッションが所有するサンドボックスも認証されます。サンドボックスへの再接続、一覧表示、クリーンアップの際も、同じ認証情報を使用してください。

有効期間を選択する

有効期間は、サンドボックスを実行できる時間の上限です。有効期間が切れると、作業が進行中であってもプラットフォームはサンドボックスを終了します。ワークロードが完了した場合や、ユーザーがサンドボックスを停止した場合は、それより早く終了することがあります。 明示的に指定した有効期間は、ランナーのポリシーのデフォルトよりも優先されます。有効期間を省略すると、プラットフォームは該当するポリシーのデフォルトを使用します。正の値のデフォルトが設定されていない場合、プラットフォームは 10 分 (600 秒) を使用します。長時間実行する作業では、デフォルトに頼らず有効期間を明示的に設定してください。 30 日を超えるリクエストはプラットフォームによって拒否されます。値 0 は実行時間が無制限であることを意味しません。CKS のポリシーでプラットフォームの最大値を引き上げることはできません。 サンドボックスの開始後に有効期間を延長することはできません。作成時に十分な時間を指定し、期限までに作業を保存できるよう計画してください。

サンドボックス作成時に有効期間を設定する

Python では max_lifetime_seconds を、TypeScript では maxLifetimeSeconds を使用します。以下の例では、上限である 30 日間をリクエストし、後で再接続できるようにサンドボックス ID を出力します。使用する配置モードのタブを選択してください。CKS には CoreWeave の認証情報と設定済みのランナーが必要です。[RUNNER-ID] をそのランナーの ID に置き換えてください。
スクリプトを実行すると、サンドボックス ID が出力されます。これらの例では、sleep infinity でプライマリプロセスを動かし続けるため、スクリプトの終了後もサンドボックスは実行されたままになります。サンドボックスを使い終わったら、停止してください。 有効期間は、他のクライアントインターフェースからも同様に設定できます。 リクエスト形式の詳細については、API リファレンスおよびCompose ファイルからサンドボックスを作成するを参照してください。Python クライアントのデフォルトについては、サンドボックスの設定を参照してください。

CKS ランナーのデフォルトを設定する

ランナーのポリシーのデフォルトは、有効期間を個別にリクエストしない新しいサンドボックスに適用されます。CKS ランナー上のワークロードに通常より長い有効期間を与えたい場合に使用します。ポリシーを編集するには、sandbox_admin アイデンティティとアクセス管理 (IAM) action が必要です。 ポリシーを更新すると、ポリシードキュメント全体が置き換えられます。抜粋を既存のポリシーの代わりに送信しないでください。送信すると、ポリシー内のその他の制約が削除されます。
  1. 対話型ターミナルで、認証済みの CoreWeave Intelligent CLI を使用してランナーの現在のポリシーを開きます。
  2. constraints.lifecycle.default_lifetime_seconds に任意の秒数を設定します。次の YAML は、デフォルトを 30 日に設定する場合の抜粋です。既存のポリシーのその他の部分はそのまま残してください。
    ランナーのポリシーの抜粋
  3. 保存してエディターを閉じ、更新を送信します。ポリシーを取得して値を検証します。
マネージドランナーの REST API を使用してポリシーを更新することもできます。JSON では、フィールド名は policy.constraints.lifecycle.defaultLifetimeSeconds です。読み取り、編集、置き換えまでの完全な手順については、ポリシーを更新するを参照してください。 デフォルトは、更新後に作成されたサンドボックスに適用されます。実行中のサンドボックスの有効期間は延長されません。サンドボックスは、最大 30 日までの範囲で別の有効期間を明示的にリクエストできます。ポリシーに max_lifetime_seconds を追加しないでください。このフィールドは提供終了となっており、CoreWeave Intelligent CLI はこのフィールドが残っているポリシードキュメントを拒否します。ポリシーではデフォルトを指定し、最大値はプラットフォームによって強制されます。

クライアントのセッションをまたいで作業を継続する

サンドボックスを起動した Python スクリプトの終了後もサンドボックスを存続させたい場合は、前述の例のようにスタンドアロンのサンドボックスを作成します。with Sandbox.run(...) コンテキストを使用すると、設定済みの有効期間が 30 日であっても、ブロックを抜けた時点でサンドボックスが停止します。また、Session も自身が所有するサンドボックスのクリーンアップを管理します。詳しくは Cleanup patterns を参照してください。TypeScript では、client.run() はサンドボックスを実行したままにしますが、client.withSandbox() はコールバックの終了時にサンドボックスを停止します。 別のスクリプトから再接続するには、[SANDBOX-ID] を作成時に出力された ID に置き換えます。認証情報には、サンドボックスの作成時と同じものを使用してください。sandbox_auth.py または sandbox-client.mts の設定も、作成時のまま変更しないでください。
このコマンドを実行すると、Connected と出力されます。再接続しても有効期間はリセットされません。作業が終わったら、サンドボックスを明示的に停止してください:

有効期限切れに備える

サンドボックスのライフタイムが切れる前に、結果やチェックポイントをサンドボックスの外部に保存してください。ワークフローに 30 日を超える時間が必要な場合は、代わりのサンドボックスを作成し、保存済みの状態から再開してください。サポートされるストレージとスナップショットのオプションについては、サンドボックスのボリューム および ファイルシステムスナップショット を参照してください。 サンドボックスのライフタイムは、コマンドや API リクエストのタイムアウトとは別物です。timeout_seconds や request_timeout_seconds を増やしても、サンドボックスのライフタイムは延長されません。両者の相違点については、タイムアウト を参照してください。
最終更新日 2026年11月4日