OpenRouter、任意のAIモデルでコマンド実行が可能な「Shell」ツールと「Files API」をベータ公開

要点

• OpenRouterは、ホスト型Linuxコンテナ上でコマンドを実行できるサーバーツール「openrouter:shell」と、データ入出力を担う「Files API」のベータ版を提供開始した。
• ツール呼び出しに対応するOpenRouter上のすべてのAIモデルで利用可能で、モデルが必要に応じて自律的にターミナルを呼び出して処理を行う。
• OpenAI仕様互換の「openrouter:shell」とAnthropic仕様互換の「openrouter:bash」の双方が用意され、サーバーサイドのサンドボックス上で実行できる。
• コンテナ環境は外部通信の許可リスト制御やセッション間の状態保持に対応し、アイドル状態が5分続くと自動停止する仕様となっている。
• サンドボックスの利用料金は1秒あたり0.0001ドルで、実行ログ画面ではモデルの推論ターンとコマンド実行のコストや所要時間が個別管理される。

リード文

AIモデルの統合APIプラットフォームを手がける米OpenRouterは2026年9月8日、サーバー上でホストされたLinuxコンテナ内でコマンドを実行できる新機能「openrouter:shell」および「Files API」のベータ提供を開始した。これにより、同プラットフォームが提供する任意のAIモデルに対して、サーバーサイドで動作するターミナル環境とファイルストレージ機能を提供できるようになったという。開発者はモデルを切り替えながら、データの取得からスクリプト生成、コードの実行までを一気通貫で処理させるエージェント動作を構築可能になるとしている。

モデルが自律的にコマンドを実行・修正する仕組み

「openrouter:shell」は、OpenRouterが拡充を進めるサーバーツール群の一つとして位置づけられている。ツール呼び出し（Tool Calling：AIモデルが外部機能の利用を自ら判断して呼び出す仕組み）をサポートしているモデルであれば、APIリクエストのツール一覧に指定するだけで利用できる。

モデルがこのツールを呼び出すと、複数行のコマンドが一括で発行され、OpenRouter上のコンテナ内で順次実行される。実行後、標準出力（stdout）、標準エラー出力（stderr）、および終了コード（exit code）がモデル側へフィードバックされる仕組みだ。これにより、例えばCSVファイルのパース用スクリプトを実行してエラーが発生した場合でも、モデルがエラー内容を自ら確認し、コードを修正した上で再実行してから最終的な回答を導き出すといった柔軟な処理が可能になると説明している。

OpenAIとAnthropicの仕様に対応した2種類のツール

OpenRouterでは、既存の開発環境やプロトコルとの親和性を保つため、異なるAPI仕様に対応した2つの実行ツールを提供している。

一つはOpenAIの仕様に準拠した「openrouter:shell」で、Responses APIおよびAnthropic Messages APIの両方から呼び出すことができる。もう一つはAnthropicの仕様に準拠した「openrouter:bash」で、こちらはMessages APIに対応している。

通常、Anthropic互換のbashツールはクライアント側のローカル環境でコマンドを実行することを前提とした仕様になっているが、OpenRouterではエンジン設定に「openrouter」を指定することで、どちらのツールであってもOpenRouter側の安全なサンドボックス（外部に影響を与えない隔離環境）上で実行可能になるという。

隔離環境「Containers」のネットワーク・ファイル・生存期間

コマンドが実際に実行される場となる「Containers」は、ワークスペースごとに隔離されたLinux環境として動作する。開発者の用途に応じていくつかの設定や制約が設けられている。

外部ネットワークへのアクセスは安全のため初期状態で遮断されている。ライブラリのインストールなどで外部接続が必要な場合は、許可ドメインを配列で指定する許可リスト形式（allowlist）でポリシーを設定する必要がある。すべてのドメインへの接続を許可する設定も可能だが、利用可能なポートは80番および443番に限定されており、許可されていないドメインへのアクセスは接続エラーではなくHTTP 520エラーとして失敗する仕様だ。なお、このネットワークポリシーはコンテナ起動後に変更することはできない。

コンテナ内のファイルについては、ホームディレクトリ（/workspace/home）配下に置かれたファイルのみが保持対象となる。コマンド実行によって作成または更新されたファイルには「cfile_」で始まる識別用IDが付与され、コンテナ用のAPIエンドポイントを通じてファイル一覧の確認やダウンロードが行える。

コンテナの再利用性に関しては、通常は会話ごとに新しいコンテナが生成されるが、リクエストにセッションIDを含めるか、設定でコンテナIDを明示的に指定することで、以前の状態を保持したまま再利用できる。一方、コンテナの生存期間については、無通信のアイドル状態が5分間続くと自動的にスリープ状態へ移行し、このアイドル時間の変更はできないとしている。

データ連携を支える「Files API」

コンテナ環境と外部とのファイル受け渡しを担うのが「Files API」である。これはワークスペース単位で利用できるストレージ機能であり、モデルに処理させたい入力データの事前配置や、コマンド実行によって生成された出力成果物の回収に使用される。

開発者は専用のエンドポイント（/api/v1/files）に対してファイルをアップロードすることで、「or_file_」から始まる一意のファイルIDを取得できる。このIDをツールの実行パラメータで指定すると、コンテナ内のホームディレクトリに書き込み可能な複製ファイルとして配置される。1つのコンテナに同時にアタッチできるファイル数は最大20個までに制限されているという。

料金体系とタイムラインによるログ表示

利用料金については、サンドボックスの稼働時間に応じて1秒あたり0.0001ドルが課金される。この費用はAPIリクエスト全体の利用料金に合算されて請求され、Files APIのストレージ利用分もこの料金に含まれるとしている。

また、プラットフォーム上のログ管理画面では、リクエストの処理経過がタイムライン形式で可視化される。モデルによる推論ターンとサンドボックス内でのコマンド実行がそれぞれ独立した行として表示され、各ステップごとの所要時間および発生したコストを個別に確認できる設計となっている。

なお、今回発表された機能はWeb上のチャットルーム機能でも有効化して即座に試すことができるほか、APIリファレンスや各種ドキュメントもあわせて公開されている。