Claudeのcode_execution_20260120は、要求をまたぐREPL状態保持とprogrammatic tool callingを可能にする。分析やAgent処理を効率化できるが、containerを新しい状態ストアとして扱う設計と、失効時に再現できる外部checkpointが必要になる。
何が変わったか
Anthropicの各言語SDKがcode_execution_20260120を扱えるようになった。このtool versionはREPL状態を保持し、programmatic tool callingを使うための最低バージョンである。同じcontainer IDを次の要求へ渡すと、中間変数やworkspace上のファイルを継続利用できる。
code_execution_20260521は同じ実行基盤を使いながら、1 cell 90秒の制限をtool descriptionへ明示し、Claudeが長い処理を分割しやすくする。
変更前後の差
| 項目 | 旧版・単発実行中心 | 20260120以降 |
|---|---|---|
| REPL状態 | 要求間で再構築しやすい | container再利用で保持 |
| tool連携 | modelが個別に呼び出す | codeからprogrammatic calling可能 |
| 長時間処理 | 制限認識が弱い場合 | 20260521で90秒を明示 |
| 再開 | 入力から再計算 | container IDで継続可能 |
| データ条件 | tool利用条件に従う | ZDR対象外は変わらない |
| 対応基盤 | 構成により差 | Bedrock・Google Cloudでは未提供 |
誰に影響するか
複数のCSVを段階処理する分析Agent、Web検索結果をPythonで絞るAgent、外部toolの結果を繰り返し計算するワークフロー、長い処理をpause_turnから継続するシステムに影響する。Amazon BedrockまたはGoogle Cloud経由でClaudeを使うシステムは、このtoolが同じように利用できると仮定してはいけない。
期限
強制移行期限はない。ただしprogrammatic tool callingを導入する場合はcode_execution_20260120以上が前提になる。旧tool versionを使用するコードは、モデル更新時の互換性が保証されないため、機能追加と同時にversionを固定して試験する。
必要な対応
tool typeを明示し、モデルとの互換表と利用基盤を確認する。container IDをユーザーやテナントをまたいで共有しない。containerには個人情報や秘密情報を長期間残さず、保持要件とZDR要件を先に照合する。処理を90秒以内のcellへ分割し、execution_time_exceededやcontainer失効時に入力から再構築できるcheckpointを持つ。
実装・移行手順
- 現行のtool version、モデル、利用基盤を棚卸しする。
- 検証環境で
code_execution_20260120を明示する。 - 同一containerを使う2要求で変数・ファイルが保持されるか確認する。
- container IDをセッションとテナントへ厳密に紐付ける。
- 90秒超過、5GiB超過、失効container、rate limitを試験する。
- 再構築に必要な入力と中間成果物を外部へcheckpointする。
- programmatic tool callingでは呼び出せるtoolを最小化し、引数を監査する。
失敗しやすい点
containerを永続ストレージと考える、30日後も再利用できると仮定する、ZDR契約の処理へ無条件に導入する、BedrockやGoogle Cloudでも同じ機能があると考える、tool versionをモデルに任せる、1 cellへ重い処理を詰め込むことが失敗につながる。
リスク
テナント間の状態混在、container内の機密残存、失効による再開不能、実行時間超過、programmatic tool callingによる意図しない外部操作がある。インターネット接続は無効だが、許可したtool経由で外部へ作用できるため、code sandboxの隔離だけでは権限統制にならない。
評価方法
- 状態保持を利用した再計算削減率
- container失効時の再構築成功率
- 90秒超過件数
- tool callの承認・拒否率
- テナント境界違反件数
- container当たりのディスク・メモリ使用量
- checkpointからの再開時間
- ZDR対象データの誤投入件数
ロールバック
新tool versionをFeature Flagで外し、単発実行または旧版へ戻す。状態を前提にした処理は入力と中間成果物から再計算する。programmatic tool callingを停止し、modelが個別toolを呼ぶ経路または人手承認へ切り替える。container IDは再利用せず、影響調査後に新しいcontainerを作る。
編集部分析
状態保持は処理速度を上げる一方、これまで要求単位だったデータ境界をセッション単位へ広げる。技術的にはcontainer IDを渡すだけでも、運用上は保持期間、テナント、削除、再現性を新たに管理する必要がある。導入判断は性能改善ではなく、状態を持つ実行基盤を受け入れられるかで行うべきだ。
実務チェックリスト
- [ ] tool versionをコードで固定した
- [ ] モデルと提供基盤の対応を確認した
- [ ] container IDをテナント間で共有しない
- [ ] ZDR非対応をデータ管理者が承認した
- [ ] 90秒制限と失効を故障試験した
- [ ] 外部checkpointを用意した
- [ ] programmatic toolの権限を最小化した