Claude Media
code executionとbashツールの混同が起きる実行環境の対処法

code executionとbashツールの混同が起きる実行環境の対処法

code executionとbashツールを併用すると、Claudeは2つの実行環境を1つだと思い込むことがあります。混同が起きる仕組みとシステムプロンプトでの防ぎ方を解説します。

code executionツールとbashツールを同じリクエストに渡すと、片方で作った変数やファイルをもう片方から参照しようとする、あるいはどちらのツールを呼ぶべきか判断を誤る、という挙動が出ることがあります。Anthropicはこの構成を公式docsで「マルチコンピュータ環境」と呼んでいます。Claudeが混同しやすい設計上の理由と、システムプロンプト側での防ぎ方を以下で示します。なお、code executionツール単体の挙動は$OUTPUT_DIRの罠で詳しく扱っています。

code executionとbashツールは別々のコンピューターを指す

code executionツールは、Anthropicが用意したサンドボックスコンテナの中でコマンドを実行します。ネットワークアクセスは完全に遮断され、pandas・matplotlib・numpyなどがプリインストールされた、既定では使い捨ての実行環境です。一方bashツールはクライアントツール、つまりClaude自身は実行しません。Claudeがtool_useブロックでコマンド文字列を返し、それをあなたのアプリケーションが自分のbashセッションで実行して結果を返す、という往復です。

この2つは名前こそ似ていますが、動いている場所がまったく別です。code executionの$OUTPUT_DIRやコンテナ内の/tmpはAnthropicのインフラ上、bashツールの作業ディレクトリはあなたのサーバーやコンテナ上です。ファイルシステムもプロセスもネットワークも共有されていません。Claudeから見ると、どちらも「コマンドを実行できるツール」として並んで見えます。そのため公式docsは、この2つを同時に提供した時点でClaudeは「マルチコンピュータ環境」で動作していると表現しています。

なぜここまで別環境になっているのか — 信頼境界の違い

2つの環境がここまで分離しているのは、実装上の都合ではなく信頼境界の設計が根本的に違うためです。bashツールはクライアントツールなので、コマンドを実際に実行するのはあなたのアプリケーションです。公式docsは「Claudeが要求するコマンドは何であれ実行される前提で動かすこと」を求めています。具体的には、コンテナや仮想マシンのような隔離環境で最小権限のユーザーとして実行し、コマンドの検証・許可リスト・リソース制限・ログ記録を実装側で用意することです。つまりbashツールの安全性は、あなたが作り込むものです。

一方code executionはAnthropicがあらかじめ隔離を作り込んだサンドボックスです。インターネットアクセスは無効、ホストシステムや他のコンテナからは分離され、ファイルアクセスもワークスペースディレクトリ内に限定されています。実装側が何も設定しなくても、この隔離は最初から効いています。

この違いを踏まえると、「なぜ状態が共有されないのか」の答えは単純です。片方はあなたが管理する信頼境界の中、もう片方はAnthropicが管理する信頼境界の中にあります。両者を意図的に混ぜない設計だから、状態も共有されません。混同を防ぐ指示は、単なる利便性の問題ではなく、この境界を越えて情報が漏れないようにする安全設計の一部でもあります。

Claudeが混同する典型パターン

公式docsが明示している混同パターンは、誤ったツールを使う・環境間で状態が共有されていると思い込む、の2つです。実際に起きやすいのは次のようなケースです。

  • code executionのサンドボックスで生成したCSVを、次のステップでbashツールを呼んでcatしようとする(bashツールのセッションにそのファイルは存在しません)
  • ユーザーのローカルファイルを読みたいのに、間違ってcode_executionを呼んでしまう(サンドボックスは外部ネットワークもローカルファイルシステムも遮断されているため、ユーザー環境には到達できません)
  • 「さっきpip installしたライブラリ」をどちらの環境の話として続けているのか、Claude自身が取り違える

いずれも、Claudeが2つのツールを「同じコンピューターの別の入り口」だと誤認していることが根本原因です。ツール定義だけではこの区別が伝わらないため、明示的な指示が必要になります。

システムプロンプトに1文加えて混同を防ぐ

公式docsが示す対処は、システムプロンプトに両者の違いを明記することです。書くべきことは短くまとめられます。

When multiple code execution environments are available, be aware that:
- Variables, files, and state do NOT persist between different execution environments
- Use the code_execution tool for general-purpose computation in Anthropic's sandboxed environment
- Use client-provided execution tools (e.g., bash) when you need access to the user's local system, files, or data
- If you need to pass results between environments, explicitly include outputs in subsequent tool calls rather than assuming shared state

ポイントは4行目です。「状態は共有されない」と伝えるだけでなく、環境をまたいで結果を渡したいなら後続のツール呼び出しに出力を明示的に含めろ、と代替手段まで指示しています。Claudeは「共有されない」を知っただけでは詰まってしまいます。「では次に何をすればよいか」まで書いておくのが実務上のコツです。

結果を明示的に橋渡しする実装パターン

システムプロンプトの4行目が指示する「結果を後続のツール呼び出しに明示的に含める」とは、具体的には次のような流れです。社内DBから顧客データを取得しつつ、その集計をcode executionのpandasで行いたいケースを考えます。

  1. Claudeがbashツールでpsql等を呼び、社内DBから必要な行だけをCSV形式で抽出する
  2. アプリケーションがそのtool_resultのテキストをそのままClaudeに返す(bashツールのセッション内のファイルパスではなく、出力内容そのものを返すのがポイント)
  3. Claudeが次のターンでcode executionを呼び出し、直前のtool_resultに含まれていたCSVの中身を"""..."""のような形でPythonコードに埋め込んで、サンドボックス内に新しいファイルとして書き出してから集計する

この3ステップの要は2番目です。「bashセッションの/tmp/data.csvをcode executionから読んで」という指示は、環境が別である以上機能しません。ファイルパスではなくデータの中身そのものをtool_resultとして往復させることで、初めて2つの環境をまたいだ処理が成立します。中間データが大きい場合は、Files APIにアップロードしてからcontainer_uploadでcode execution側に渡す方法もあります。ただしbashツールとFiles APIの間には直接の橋渡し機能がありません。橋渡しはいずれもアプリケーション側の実装が担います。

web_search/web_fetchが環境をもう1つ増やす

見落とされがちなのが、web_search_20260209以降・web_fetch_20260209以降のツールを渡すと、code executionが自動的に有効化される点です。すでにクライアント側のbashツールを提供しているアプリケーションでこれらのツールを追加すると、意図せず2つ目の実行環境(code execution)が増設され、bashツールと合わせて3つの環境が並ぶ構成になります。この組み合わせを使うときほど、上記のシステムプロンプト指示の重要度が上がります。

同時に呼んだときの結果が届く順番

Claudeがクライアントツール(bashツール等)とcode executionを同じターンで呼んだ場合、code executionの呼び出し自体はレスポンスに含まれますが、実行結果はまだ返ってきません。結果が届くのは、あなたがクライアントツールのtool_resultを送り返した後の、次のレスポンスです。この非対称な返り方を知らずに実装すると、「code executionを呼んだのに結果が無い」というバグに見えることがあります。処理の実体は完了しているので、次のラウンドトリップを待てばbash_code_execution_tool_resultが届きます。エラー発生時の切り分けはエラーコード一覧にまとめています。

使い分け早見表

用途bashツール(クライアント側)code executionツール(Anthropicサンドボックス)
ユーザーのローカルファイル・DB・社内APIへのアクセスbashツール(クライアント側)◎ 自分のマシン・ネットワークで実行するので到達できるcode executionツール(Anthropicサンドボックス)✕ 完全にネットワーク遮断で外部に出られない
pandas・matplotlib等でのデータ集計・可視化bashツール(クライアント側)△ 環境構築とライブラリ管理は自前code executionツール(Anthropicサンドボックス)◎ 主要ライブラリがプリインストール済み
追加パッケージのインストールbashツール(クライアント側)◎ 自分の環境でpip install可能code executionツール(Anthropicサンドボックス)✕ ネットワーク遮断のためランタイムでの追加導入は不可
複数リクエストをまたいだ状態保持bashツール(クライアント側)◎ 同一bashプロセスを維持すれば継続code executionツール(Anthropicサンドボックス)container.idを明示的に渡して再利用すれば可能(自動では持続しない)
リソース上限bashツール(クライアント側)アプリ側の設計次第code executionツール(Anthropicサンドボックス)メモリ5GiB・CPU1・ディスク5GiBに固定

bashツールは「あなたの環境に手を伸ばす」ためのツール、code executionは「Anthropicの隔離環境で計算する」ためのツールと役割が逆です。両方を渡す構成自体は正当です。Claudeにその境界線を教えるのはあなたの責任という点が、この組み合わせ特有の注意点です。判断に迷ったときは、表の1行目(アクセス先)だけを見れば十分です。ユーザー側のリソースに触るならbashツール、Anthropic側の使い捨て環境で完結する計算ならcode execution、という基準は迷ったときの最短ルートになります。

まとめ

code executionとbashツールを同時に使う構成では、Claudeは2つの別々のコンピューター上で動いていることを前提に、システムプロンプトで明示的にその違いを教える必要があります。ここまでの要点は4つです。状態は環境間で共有されないこと、環境をまたぐ結果は次のツール呼び出しに明示的に含めること、web_search/web_fetchが意図せずcode executionを増設しうること、code executionの結果はクライアントツールのtool_resultを返した後に届くこと。この4点を押さえておけば、混同によるバグの大半は防げます。ツールの数自体を減らしたい場合はAdvanced Tool UseのTool Search Toolも選択肢になります。

この記事を共有:XはてブLinkedIn