AIエージェント向けサーバーサイドコード実行ツールの比較

顧客がアップロードしたCSVについて質問に答えるエージェントを作っているとしましょう。モデルは答えを得るためにPythonを実行する必要があります。そのコードはどこで実行されるべきでしょうか？

選択肢のひとつは、自分で実行することです。それは E2B や Modalのようなサンドボックスプラットフォーム、あるいはDocker上の自前のコンテナを用意することを意味し、さらにデータベースやインターネットから隔離し続ける作業、実行時間の上限設定、イメージのパッチ適用といった作業も伴います。

もうひとつの選択肢がサーバーサイドコード実行ツールです。APIリクエストにツールを追加すると、モデルは何かを実行する必要があるときにそれを判断し、プロバイダーが自社のサンドボックス内でコマンドを実行し、同じリクエスト内で出力をモデルに返します。ここでいうサンドボックスとは、独自のファイルシステム、時間制限を備え、デフォルトではネットワークアクセスを持たない分離されたLinuxコンテナのことです。

本記事では、現在サーバーサイドコード実行を提供している4つのプロバイダー、各サンドボックスにできることとできないこと、レイテンシとコストの面での料金、そして依然として自分で運用するサンドボックスを必要とするユースケースについて取り上げます。

要約

• サーバーサイドコード実行ツールは、APIリクエスト中にモデルのコマンドをプロバイダーのサンドボックス内で実行します。コンテナのプロビジョニング、パッチ適用、セキュリティ確保は不要です。
• OpenAI、Anthropic、Googleはそれぞれ自社のモデル向けにコードを実行します。当社の openrouter:shell ツールはResponses APIとMessages API上の任意のモデル向けにコマンドを実行し、 openrouter:bash ツールはMessages APIのみで同じことを行います。どちらのツールもベータ版です。
• 当社のサンドボックスは、アカウントとワークスペースにスコープされた分離されたコンテナで、アウトバウンドネットワークアクセスはデフォルトでオフになっており、コマンドごとに実行時間と出力サイズの上限が設けられています。サンドボックス時間は1秒あたり$0.0001で課金され、新規またはスリープ中のコンテナには30秒の最低料金がかかります。
• カスタムベースイメージ、GPUワーク、数時間に及ぶセッションには、自分で運用するサンドボックスプラットフォームが依然として正しい選択です。

サーバーサイドコード実行とは

モデル自身は何も実行しません。ツールを呼び出すとき、モデルはツール名と引数を指定したリクエストを発行し、それを実際に実行する何かが必要になります。クライアントサイドツールの場合、その「何か」とはあなたのアプリケーションコード、あるいは構築しているエージェントフレームワークです。アプリケーションが呼び出しを受け取り、実行し、後続のリクエストで結果を送り返します。サーバーサイドツールの場合、プロバイダーが自社のインフラ上で呼び出しを実行し、同じリクエスト内でモデルに結果を返すため、アプリケーションにはそれ用のハンドラが不要です。サーバーサイドコード実行は後者の種類にあたります。

このように動作するツールをすでに使っているかもしれません。 Web検索 はモデルがライブウェブ上で調べものをできるようにし、 web fetch はURLの内容を読めるようにします。どちらの場合も、リクエストにエントリをひとつ追加すれば、残りはプロバイダーが処理します。コード実行は、コマンドの実行に同じパターンを適用したものです。

ツール呼び出しが実行されるコマンドになる仕組み

以下の手順は、あらゆるサーバーサイドコード実行ツールに共通します。フィールド名が登場する箇所では、当社のシェルツールが使用する名前を示しています。

1. リクエストの tools 配列にツールを含めます。
2. モデルが何かを実行する必要があると判断し、1つ以上のシェルコマンドを伴う呼び出しを発行します。
3. プロバイダーはそれらのコマンドを、サンドボックス化されたコンテナ内で順番に実行します。
4. 各コマンドの標準出力、標準エラー、および結果がモデルに返されます。結果は終了コードまたはタイムアウトのいずれかです。
5. モデルは結果を読み、あなたに回答するか、同じリクエスト内でさらにコマンドを実行します。

ステップ2から5は、モデルが回答するまで繰り返されます。モデルは何かを実行し、出力を読み、別のコマンドが必要かどうかを判断し、再度実行します。このループこそがコード実行ツールがその価値を発揮する場です。なぜなら、モデルは推測する代わりに実際の出力と照らし合わせて自分の作業を確認できるからです。

私たちはこのループに上限を設けています。 max_tool_calls フィールドは、1回のリクエストが取り得るサーバーツールステップの回数を設定します。当社の サーバーツールリファレンス では、デフォルト値も最大値も 30 に設定されています。

ホスト型サンドボックスと自前運用のサンドボックスの違い

自分でサンドボックスを運用するということは、本来プロバイダーが担う部分を自分で担うことを意味します。ベースイメージを選び、コンピュートをプロビジョニングし、実行の開始と出力の読み取りのためのSDKを組み込み、各実行のライフサイクルを管理します。セキュリティ境界も自身で担うことになります。

ホスト型ツールは、その制御をJSON配列の1エントリと引き換えにします。コンテナのサイジング、パッチ適用、運用は不要です。私たちは openrouter:shell を、リクエストあたり数個の短いコマンドで済むケースのために構築しました。

現在ホスト型コード実行を提供しているのはどこか

本記事では、OpenAI、Anthropic、Google、OpenRouterを取り上げます。Agent SDKと専用サンドボックスプラットフォームは別のカテゴリであり、どちらも記事の後半で扱います。この4つのプロバイダーを分けているのは、それぞれどのモデルのためにコードを実行するかという点です。

OpenAIはOpenAIモデル向けにホステッドシェルを提供しています

OpenAIの シェルツール は、Responses API上でOpenAIが管理するコンテナ内でコマンドを実行します。OpenAIは、ホステッドランタイムをDebian 12、デフォルトの作業ディレクトリを /mnt/dataであると文書化しています。コマンドは sudoなしで実行され、対話型のTTYセッションはサポートされていません。ドキュメントに記載されているプリインストール言語には、Python 3.11、Node.js 22.16、Java 17、PHP 8.2、Ruby 3.1、Go 1.23が含まれます。

ホステッドコンテナはデフォルトで外部ネットワークアクセスがありません。有効にするには、組織の管理者がOpenAIダッシュボードで許可リストを設定し、リクエストでコンテナ環境に network_policy を設定します。コンテナは、そのidを container_reference 環境に渡すことでリクエスト間で再利用でき、有効期限はコンテナの作成時に設定されます。OpenAIはPython向けに別の コードインタープリターツール も提供しています。

AnthropicはClaudeモデル向けにPythonとBashを実行しています

Anthropicの コード実行ツール は、Messages API上でAnthropicが管理するサンドボックス内でPythonとBashを実行します。文書化されている環境は、Python 3.11、RAM 5 GiB、ワークスペースストレージ 5 GiB、CPU 1基を備えたLinux x86_64コンテナです。インターネットアクセスは無効化されており外部接続は一切許可されないため、Claudeはプリインストールされたライブラリで動作し、実行中にパッケージをインストールすることはできません。

3つの ツールバージョン が存在し、サポートされているすべてのモデルが3つすべてを受け付けます。 code_execution_20250825 はBashコマンドとファイル操作をサポートします。 code_execution_20260120 はリクエスト間で永続化されるPythonインタープリターの状態を追加します。これはAnthropicのプログラマティックツール呼び出しに依存しており、Claude Haiku 4.5では利用できません。コンテナは作成から30日後に失効します。約5分の非アクティブ状態の後、コンテナはチェックポイント化され、30日以内の期間内であればそのidを含むリクエストで復元できます。

GoogleはGeminiモデル向けにPythonを実行しています

Googleの コード実行ツール は、Googleが管理するサンドボックス内でPythonを実行し、リクエストのtoolsに code_execution エントリを追加することで有効になります。ドキュメントには、モデルはPythonの生成と実行のみが可能であること、コード環境の最大実行時間は30秒であること、独自のライブラリはインストールできないことが記載されています。Googleは環境に含まれるライブラリの一覧を公開しています。

当社はあらゆるモデル向けにホステッドシェルを提供しています

上記の3つのツールはそれぞれ1社のモデルでのみ動作します。当社のツールは、サンドボックスを1つのモデルプロバイダー内部ではなくルーティング層で実行しているため、Responses APIとMessages API上のあらゆるモデルで動作します。

当社は2つのコード実行ツールを提供しています。 openrouter:shell はOpenAIのホステッドシェルツールの形状を踏襲しており、 Responses API および Messages API。 openrouter:bash は Anthropic の bash ツールと同じ形状をしており、Messages API でのみ動作します。

両方のツールはベータ版のため、API は変更される可能性があります。サンドボックス実行はグローバルの openrouter.ai エンドポイントでのみ実行されます。 リージョン内エンドポイント はシェルツールを提供しておらず、Chat Completions は両方のツールを、対応している API を示す 400 で拒否します。

を engine に openrouter いずれかのツールに対して設定すると、コマンドは当社のサンドボックスで実行されます。デフォルトの engine は autoです。openrouter:shell の場合、 auto はプロバイダーのネイティブのホスト型シェルが存在すればそれを保持し、存在しない場合は当社のサンドボックスへルーティングします。openrouter:bash の場合、 auto はツールコールをアプリケーションに返してクライアント側で実行させ、当社のサーバーでは何も実行されません。

サンドボックスでコマンドを実行する

2 つのコマンドを実行し、結果を読み戻す完全なリクエストの例です。

import os
import requests

response = requests.post(
    "https://openrouter.ai/api/v1/responses",
    headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
    json={
        "model": "anthropic/claude-sonnet-4.5",
        "input": "Run `cat /etc/os-release` and `python3 --version`, then tell me the OS and Python version in one sentence.",
        "tools": [
            {"type": "openrouter:shell", "parameters": {"engine": "openrouter"}}
        ],
    },
)

for item in response.json()["output"]:
    if item["type"] == "openrouter:shell":
        print(item["container_id"], item["action"]["commands"])
        for result in item["output"]:
            print(result["stdout"], result["outcome"])

このリクエストを 2026 年 9 月 22 日に実行しました。モデルは両方のコマンドを 1 回のシェルコールで送信し、各コマンドはそれぞれの結果とともに返ってきました。完全な os-release 出力は数行に及ぶため、ここでは最初の 2 行に切り詰めています。

{
  "type": "openrouter:shell",
  "container_id": "sess_art10-418b8597e044",
  "action": { "commands": ["cat /etc/os-release", "python3 --version"] },
  "output": [
    {
      "stdout": "PRETTY_NAME=\"Ubuntu 22.04.5 LTS\"\nNAME=\"Ubuntu\"\n",
      "stderr": "",
      "outcome": { "type": "exit", "exit_code": 0 }
    },
    {
      "stdout": "Python 3.11.14",
      "stderr": "",
      "outcome": { "type": "exit", "exit_code": 0 }
    }
  ]
}

その日、サンドボックスは Python 3.11.14 を搭載した Ubuntu 22.04.5 LTS を報告しました。ランタイムイメージは変更される可能性があるため、バージョンをハードコーディングせずにコンテナから読み取ってください。残りのパラメータについては、 サーバーツールリファレンス を参照してください。

サンドボックスをラップしてくれる Agent SDK

API を直接呼び出すのではなくエージェント SDK 上に構築する場合、これらのツールのいずれかをラップする SDK があります。

The OpenAI Agents SDK 船 CodeInterpreterTool、OpenAIのサンドボックス内でコードを実行するものであり、 ShellToolローカルランタイムと OpenAI がホストするコンテナのどちらかで動作し、どちらになるかは環境の設定方法によって決まります。コマンドがリモートで実行されたと想定する前に、どちらのモードを設定したかを確認してください。私たちの側では、openrouter:shell はに含まれるエントリです。 tools 他の配列と同様に扱われるため、それはそのまま OpenRouter Agent SDK のループに入り、生のリクエストと同じように処理されます。

依然として自分自身のサンドボックスが必要なケース

ホスト型ツールは、スクリプトの実行、ファイルの変換、結果の確認など、短く範囲の限られた作業に適しています。特定のベースイメージやGPUを必要とするものは、4つのホスト型ツールのいずれにも該当せず、自分で運用するサンドボックスプラットフォームが必要になります。

比較

ホスト型ツールの各セルは、上記でリンクしたベンダー自身のドキュメントに基づいています。唯一の例外は OpenRouter のランタイムのセルで、これは上記のリクエストを実行した際にサンドボックスが報告した内容です。self-managed(自己管理)の列は、特定のプラットフォームではなく、自分で実行するサンドボックスを表しています。

当社のサンドボックスが強制する内容

サンドボックスの要点は、モデルを信頼する必要がないことです。意図しなかったコマンドがネットワークや他の人のコンテナに到達することはできず、実行時間と出力量のハードリミットで停止します。このセクションで説明する内容はすべて私たちのサンドボックスに関するものです。上の表は、他の3つがどこで異なるかを示しています。

すべてのコマンドに適用される制限

各コマンドは、リクエストを処理するインフラストラクチャやお使いのマシンとは切り離された隔離コンテナ内で実行され、お客様のアカウントとワークスペースの範囲に限定されます。上限は でご自身で設定できます。 timeout_ms コマンドが実行できる時間の長さおよび max_output_length 「印刷できる額について。」 timeout_ms デフォルトは120,000 msで、300,000 msを超えることはできません。 max_output_length ストリームごとに16,384文字がデフォルトで、65,536を超えることはできません。100を超えるコマンドを含むシェル呼び出しは拒否されます。

アウトバウンドのネットワークアクセスは、有効にしない限りオフになっています。2026年9月22日に、何も含まないリクエストを送信してこれを確認しました。 network_policy モデルに取得を依頼し https://example.com with curl、HTTPステータスコードのみを出力し、5秒後に諦めるというものでした。このコマンドが出力したのは 000、これこそが curl 応答がない場合に出力され、終了コード 28 で終了しました。これは curl タイムアウト。

{ "stdout": "000", "stderr": "curl: (28) Failed to connect to example.com port 443 after 5206 ms: Connection timed out", "outcome": { "type": "exit", "exit_code": 28 } }

ネットワークを開くには、 network_policy 最大50個のホスト名またはglobパターンのallowlist。アクセスできるのはポート80と443のみで、ポリシーはコンテナの起動時に固定されます。 pip install 両方必要です pypi.org および files.pythonhosted.org 許可リスト内。

プロンプトインジェクションとサンドボックスが制限するもの

モデルにシェルを与えることは、あなたを以下のリスクにさらします プロンプトインジェクションエージェントがウェブページ、サポートチケット、または誰かがアップロードしたファイルを読み込むと、攻撃者がそのテキストの中に命令を隠し、モデルにあなたのプロンプトを無視して別のものを実行させることがあります。

上記の制限は、モデルがあなたのプロンプトに従っている場合でも、攻撃者の指示に従っている場合でも適用されます。インジェクションされた指示のもとで実行されるコマンドは、外のホストには到達できません。 network_policy 設定した範囲に限定され、ポリシーをオフにした場合は一切のネットワークアクセスが不可能になります。別のテナントのコンテナには到達できず、同じタイムアウトで停止します。許可リストは、注入されたコマンドが到達できる範囲を広げます。 allowed_domains: ["*"] 無制限の外部への通信（egress）が許可されるため、許可リストはジョブに必要なホストのみに限定してください。

リクエスト自体に到達した試行も検出できます。 プロンプトインジェクション検出 中で ワークスペースガードレール 各リクエストをモデルへ転送する前に、受信リクエストごとのユーザー提供のメッセージ内容を、一般的なインジェクション手法に対応する正規表現パターンと照合してチェックします。それ以降にサーバーツールが取得した内容までは検査しないため、モデルがツール経由で読み取るページ、ファイル、コマンド出力については、アプリケーションが受け取るサンドボックス出力をレビューするなど、独自の管理策が必要です。マッチした場合の動作は、設定したアクションに応じて3つのうちのいずれかになります。

• フラグは検出を記録し、リクエストを変更せずに転送します。
• Redactは一致したスパンを以下で置き換えます [PROMPT_INJECTION] サニタイズされたリクエストを転送します。
• リクエストがモデルに到達する前に、Blockが403で拒否します。

複数のガードレールが適用される場合、最も厳しいアクションが block、redact、flag の順で優先されます。検出は網羅的ではなく、偽陽性が発生する可能性があるため、redact または block を強制する前に、flag モードで自身のトラフィックに対するマッチ率を測定してください。Logs ページから偽陽性を報告できます。

ホスト型サンドボックスがあなたの時間とコストに与える影響は、秒とドルでこんなに大きい

ホスト型サンドボックスはリクエストに数秒を追加し、実行すべきインフラを残しません。また、後から戻ってこられるコンテナを提供してくれます。

ファイルはリクエスト間で保存されます

以下で実行されたコマンド: /workspace/homeそのディレクトリの下に変更されたファイルをすべてのコマンド実行後に保存します。安定した session_id、またはツールの 環境 設定により、そのIDを持つすべてのリクエストは同じコンテナと同じファイルに到達します。A session_id は、英字、数字、 _、および -のみを使用する必要があります。他の文字を含む id は無視され、 session_idを送らなかった場合と同様にコンテナが選択されます。つまり、リプレイされた会話内に最近の container_id があればそれが使われ、なければそのリクエスト用の新しいコンテナが作成されます。 session_id が20文字を超える場合、末尾の20文字のみが使用されるため、同じ末尾を持つ2つの長い id は同じコンテナを共有します。 container_reference の id は同じ文字セットから1文字から40文字まで使用でき、切り詰められないため、id を正確にする必要がある場合にはこちらを使用してください。2026年9月22日、あるリクエストでファイルを書き込み、同じ session_id.

コンテナはアイドル状態が5分続くとスリープし、アイドル時間は設定できません。スリープしてもファイルは削除されません。その後、同じidを持つリクエストが到着すると、新しいサンドボックスが起動し、保存されたファイルを最初に読み込みます。実行中のプロセス、環境変数、インストール済みのシステム状態は復元されないため、スリープから復帰したコンテナは、自分のファイルが入った新品のマシンとして扱ってください。保存されたファイルは、コンテナが最後に使用されてから30日間保持されます。アーティファクトを取り出すには、 GET /api/v1/containers/{container_id}/files コンテナが生成した内容を一覧表示し、 エンドポイントを昇格する workspaceのdocumentsにファイルをコピーします。そこでは期限切れになりません。

後から確認できる内容

応答内の各シェルツールの結果には、モデルが実行したコマンドと各コマンドの stdout、stderr、および結果が含まれるため、アプリケーションは応答の他の部分と同じ方法でそれらをログに記録できます。 入出力ロギング OpenRouterはプロンプトと完了結果をLogsページに保存して確認できるようにし、ガードレールの検出結果もそこに表示されます。本番環境の監視には、 放送 リクエストの完了時にトレースを外部のオブザーバビリティプラットフォームへストリーミングします。

ルーティングする場合 地域内「シェルツールは利用できず、Input & Output Loggingが有効になっている場合でもスキップされます。Broadcastはリージョン内ルーティングをサポートしており、各宛先には受け取るトレース元のデータリージョンが設定されます。」

この往復でかかるコスト

サンドボックス化されたコマンドを実行するリクエストは、そうでない同じリクエストよりも時間がかかります。2026年9月22日に送信した一連の単一リクエストでは、シェルツールを使用しないリクエストは約2秒で返り、シェルを1回呼び出したリクエストはモデルに応じて8秒から21秒で返りました。これらは1つのセッションからの単一サンプルであり、ベンチマークではありません。シェル呼び出しごとに数秒のオーバーヘッドを見込んでおいてください。

サンドボックスの利用時間は1秒あたり$0.0001で課金されます。計時は、リクエストが最初にサンドボックスコマンドを実行したときに開始され、レスポンスが完了したときに停止します。新しいコンテナまたはスリープ状態のコンテナを起動したリクエストは最低30秒分が課金され、後から同じウォーム状態のコンテナを再利用するリクエストは、実際に計測された時間のみを支払います。上記のリクエストは新しいコンテナを起動したものであり、そのusageオブジェクトには server_tool_cost 0.003の30秒最低料金です。リクエスト間でアイドル状態のコンテナには課金されません。

ツールコードに触れずにモデルを変更する

モデルを交換しても、ツール定義は同じままです。

2026年9月22日、リクエストボディを1つ送り、6回にわたって変更したのは model 分野であり、各モデルに実行するよう求めた python3 -c "print(sum(range(1, 101)))" サンドボックス内で。各モデルは1回のシェル呼び出しを行い、5050を返しました。

すべての6モデルを、同じサンドボックスで同じツール定義のもとで実行しました。それぞれのプロバイダーがネイティブに提供するものではなく、サンドボックスはモデルのプロバイダーではなく私たちのものだからです。その上で構築する前に、使用する予定のモデルをテストしてください。ツール呼び出しの信頼性はモデルによって異なるからです。当社の ツール呼び出しガイド サーバーツールと独自の関数ツールが単一の tools 配列を共有する仕組みを解説します。

独自のサンドボックスプラットフォームが必要なとき

ホスト型ツールでは得られないものが必要な場合は、専用のサンドボックスプラットフォームを選びましょう。 Modal は、最長24時間の設定可能な存続期間とGPUリソースを備えた、カスタムイメージから構築されるサンドボックスについて文書化しています。 Daytona は、GPUサンドボックスを含む、公開コンテナイメージから作成されるサンドボックスについて文書化しています。 E2B は、Proプランでは最長24時間、基本プランでは1時間実行できるサンドボックスについて文書化しており、より長いワークロード向けに一時停止と再開機能を提供しています。

結論

モデルリクエスト内の短く範囲の限られたコマンドには、ホスト型ツールを使用してください。 tools 配列に1エントリ追加するだけで、アウトバウンドネットワークアクセスがオフにされた分離コンテナを利用でき、推論料金に加えてサンドボックスが実行される秒数分の料金を支払います。シェル呼び出しごとに数秒のオーバーヘッドを見込み、可能な範囲でコンテナを再利用してください。

カスタムベースイメージ、GPU、数時間実行されるセッション、あるいはセキュリティ境界そのものの所有権が必要なジョブの場合は、自分で運用するサンドボックスプラットフォームへ移行してください。いずれの場合も、コミットする前に各プロバイダーの最新のドキュメントを確認してください。私たちの2つのツールはベータ版であり、他の3社のプロバイダーのツールも変化しているからです。

よくある質問

リクエスト中にモデルが直接呼び出せるホスト型のサンドボックス化されたシェルツールはありますか?

はい。私たちのopenrouter:shellサーバーツールは、Responses APIとMessages APIの両方で、リクエスト中に当社のインフラストラクチャ上で実行されるサンドボックス化されたLinuxシェルをモデルに提供します。 engine を openrouter に設定すると、コマンドは分離コンテナ内で実行され、各コマンドのstdout、stderr、および終了またはタイムアウトの結果がモデルに返されます。OpenAI、Anthropic、Googleはそれぞれ自社のモデル向けにホスト型コード実行ツールを提供しています。

モデルにコマンドを実行できるサンドボックス化されたシェルを与えることはできますか?

はい。追加 {"type": "openrouter:shell", "parameters": {"engine": "openrouter"}} 〜への tools Responses API または Messages API リクエストの配列です。モデルはシェルコールを出力でき、隔離されたコンテナ内でコマンドを実行し、各コマンドの出力をモデルに返します。設定しない限り、コンテナにはアウトバウンドのネットワークアクセスはありません。 network_policy 許可リスト(allowlist)。

サーバーサイドのコード実行を標準で提供しているSDKやプラットフォームにはどのようなものがありますか?

当社の openrouter:shell サーバーツールは、Responses API および Messages API 上のあらゆるモデル向けにコマンドを実行し、openrouter:bash サーバーツールは Messages API のみで同じ機能を提供します。OpenAI、Anthropic、Google はそれぞれ、自社モデル向けに Responses API のシェルツール、コード実行ツール、Gemini API のコード実行ツールを通じてコードを実行しています。OpenAI Agents SDK は、OpenAI のホスト型ツールをラップし CodeInterpreterTool および ShellTool. E2B、Modal、Daytonaは、プロバイダーがAPI呼び出しの中で実行するツールではなく、自身で統合して運用するサンドボックスプラットフォームです。

AIエージェントにはどのサンドボックスが最適ですか?

これは、ワークロードがどれくらいの時間実行されるか、そしてランタイムに対してどの程度の制御が必要かによって異なります。リクエスト内での短いコマンドであれば、openrouter:shell のようなホステッドツールを使えばインフラを一切運用する必要がありません。カスタムベースイメージ、GPUアクセス、あるいは数時間にわたって実行されるセッションが必要な場合は、Modal や Daytona のような自分で運用するサンドボックスプラットフォームが、それらの制御を提供してくれます。

AIエージェントをどのようにサンドボックス化しますか?

エージェントのコマンドは、あなた自身のシステムから分離された環境で実行し、その環境がアクセスできる範囲を制限します。ホスト型ツールでは、プロバイダーがこれを行います。OpenRouterでは、コンテナは当社のインフラストラクチャやあなたのマシンから分離され、あなたのアカウントとワークスペースにスコープされ、アウトバウンドのネットワークアクセスはデフォルトで無効になっており、各コマンドは timeout_ms、出力は次の値によって上限が定められます： max_output_length. Workspaceガードレールは、モデルの前面にプロンプトインジェクション検出を追加します。

サンドボックス化されたAIツールとは何ですか?

そのツールは、副作用が本番システムではなく隔離された環境に限定されるものです。コード実行の場合、モデルのコマンドは独自のファイルシステム、制限されたネットワークアクセス、および時間制限を備えたコンテナ内で実行され、モデルに返されるのはコマンドの出力だけです。当社のシェルおよびbashサーバーツールはこのように動作します。

参考文献

• サーバーツールリファレンス
• シェルサーバーツール
• Bashサーバーツール
• コンテナ
• ガードレール および プロンプトインジェクション検出
• 入出力ロギング
• ツール呼び出しガイド
• Responses API のツール呼び出し
• モデルカタログ