Bedrock PTC実装3方式

PTCとは何か

Programmatic Tool Calling（PTC）は、モデルが生成したコードから複数のツールを呼び、絞り込み・計算・集約までsandbox内で進めてから必要な結果だけをモデルへ戻す設計です。通常のtool useのように、ツールを1回呼ぶたびモデルへ戻る往復を減らせます。

重要なのは、この記事で扱うAmazon Bedrock上のPTCがネイティブ機能ではなく実装パターンだという点です。Anthropic公式資料では、allowed_callersを使うネイティブなProgrammatic Tool Callingは現在Amazon Bedrockで利用できないと案内されています。AWS公式ブログは、Bedrockのモデル推論にsandbox、orchestrator、ツール実行基盤を組み合わせて同じ考え方を実装する3方式を紹介しています。

通常のtool useとの違い

比較軸	通常のtool use	Programmatic Tool Calling
制御の主体	モデルとアプリが1呼び出しずつ交互に制御	モデルが生成したコードが複数ツールを制御
モデル推論	ツール結果ごとに再開しやすい	コード生成と最終解釈を中心に往復を削減
中間データ	各ツール結果がcontextへ入りやすい	sandbox内で処理し、必要な結果だけを返せる
分岐・反復	モデルのターンとして進行	条件分岐、loop、並列化をコードで表現
遅延・token	呼び出し数に応じて増えやすい	多数の読み取り・集約で削減余地がある
実行環境	アプリ側のtool handler	分離したcode sandboxとorchestratorが必要
向く処理	少数ツール、各段階の判断・承認	大量取得、計算、filter、集約、multi-step処理
安全設計	各tool callを都度検証	生成コードと複数tool callをまとめて制御

Amazon Bedrockの標準的なツール利用は、対応モデルへ一貫したmessages形式を提供するConverse APIのtoolConfigで実装できます。少数の呼び出しならこの方式が単純です。PTCはConverseの別名ではなく、多数のツール結果をモデルcontextへ逐次投入せず処理したい場合に追加する実行レイヤーです。

処理が進む5段階

1. コード生成：モデルが利用可能なツール定義を基に、目的を達成するPythonなどのコードを生成する
2. sandbox実行：隔離環境でコードを開始し、必要なツール呼び出しをorchestratorへ要求する
3. 検証・実行：orchestratorがallowlist、schema、権限、上限、side effectを検証して業務ツールを実行する
4. 中間処理：sandbox内でloop、並列取得、filter、計算、集約を行い、返す情報を最小化する
5. 最終解釈：整理済みの結果だけをモデルへ戻し、ユーザー向けの回答を生成する

sandboxは任意コードを隔離する場所で、業務データへの認可を決める場所ではありません。実ツールへのアクセスはorchestratorを経由させ、生成コードへ長期credentialを渡さない設計にします。

どちらを選ぶか

• PTCが向く：多数の独立した読み取り、表データの集計、数値計算、大きなtool resultから必要部分だけを抽出する処理
• 通常のtool useが向く：1〜数回の呼び出し、各段階でモデル判断や人の承認が必要な処理
• 慎重に扱う：送信・削除・課金など非idempotentな更新、順序依存の処理、外部状態を変えるツール
• 併用する：最初に処理を分類し、読み取りと集約だけPTCへ、重要な更新は通常のtool loopと承認へ分ける

3つの実装方式

方式	運用負荷	制御・データ境界	向くケース
ECS上の自前sandbox	高い。image、隔離、IPC、監視を自社運用	実装を細かく制御し、AWS account内へ閉じやすい	独自runtimeや厳密なnetwork要件がある
AgentCore Code Interpreter	低め。managedな隔離実行環境を利用	custom resourceでexecution roleとnetwork modeを指定	sandbox運用を減らして早く検証したい
Anthropic SDK互換proxy	中程度。proxyとsandboxを運用	Anthropic SDK形式をBedrockのInvokeModelへ変換	既存SDKの実装資産を活かしたい

AgentCore Code Interpreterは隔離されたcontainerでPython、JavaScript、TypeScriptなどを実行でき、CloudTrailによる操作記録やsession管理を備えます。system resourceは制限的な既定値で始められますが、VPC接続や独自execution roleが必要ならcustom resourceを作成します。private resourceを扱う本番用途ではVPC network modeを第一候補にします。

実務例：20件の経費をまとめて監査する

20人分の経費明細を取得し、上限超過だけを抽出する処理を考えます。通常のtool useでは取得結果を1件ずつモデルへ戻す構成になりがちです。PTCなら、独立した読み取りをasyncio.gatherなどで並列実行し、sandbox内で上限判定と集計を行い、違反候補と根拠だけをモデルへ返せます。

AWS公式ブログは、この例を含む評価でtoken使用量が87〜92%減ったと報告しています。ただし、これは掲載されたsampleと条件での結果です。ツール数、resultの大きさ、model、sandbox起動、network遅延で変わるため、自社データの比較評価なしに削減率や費用対効果を保証できません。

導入の8ステップ

1. 対象workflowを選ぶ：多数読み取り、集計、計算などPTCで往復を減らせる候補を集める
2. 基準を取る：通常のtool useで正答率、model呼び出し、token、遅延、費用を記録する
3. tool contractを定義する：入力schema、出力、timeout、side effect、idempotency、利用者権限を明記する
4. 実装方式を選ぶ：ECS、AgentCore Code Interpreter、SDK互換proxyをnetwork・運用要件で比較する
5. orchestratorを実装する：allowlist、schema validation、認可、rate limit、budget、retryを一元化する
6. コード契約を与える：利用可能ツール、終了条件、出力上限、禁止操作、例外時の扱いをsystem promptへ含める
7. 評価・攻撃テストする：誤呼び出し、prompt injection、巨大出力、無限loop、部分失敗、重複更新を試す
8. 段階公開する：read-onlyから始め、指標と監査logを見ながら対象workflowを広げる

本番導入前の注意点

• native APIと混同しない：Anthropicのallowed_callersを使うnative PTCは現在Bedrock非対応。AWSブログの方式はsandboxとorchestratorを組む実装パターン
• 生成コードは信用しない：file、process、network、package、実行時間、memory、出力量を制限し、実行ごとに分離する
• 認可を外へ置く：allowed_callersのようなmodel向け設定をsecurity boundaryにせず、orchestratorでtoolと引数を再検証する
• credentialを渡さない：生成コードへ長期access keyを置かず、最小権限のexecution roleと短期的な委任を使う
• networkを閉じる：機密データやprivate resourceを扱うcustom Code InterpreterはVPCを検討する。Security HubのcontrolもPUBLIC／SANDBOXではなくVPCを推奨する
• side effectを分離する：並列化は独立したidempotent readへ限定し、更新は順序、承認、deduplication key、rollbackを設ける
• 出力を最小化する：最終結果だけでなくstdout、stderr、trace、tool logの個人情報・機密情報をredactする
• 上限を決める：tool calls、wall time、token、費用、retry、出力サイズをrequest単位で制限する
• 注入攻撃へ備える：ユーザー入力とtool resultを命令として無条件に扱わず、許可済みの操作へ固定する
• 仕様を再確認する：対応model、Region、quota、料金は変動するため、導入時点の公式情報で確認する

評価と監視で見る指標

観点	確認する指標
品質	task成功率、計算・集約の正確性、根拠の再現性
モデル利用	model呼び出し回数、input／output token、context量
ツール利用	tool call数、並列度、失敗・retry・拒否件数
体験	全体遅延、sandbox起動時間、timeout率
安全性	未許可tool・引数の拒否、network違反、重複side effect
費用	model、sandbox、network、外部APIを合わせたtask単価

通常のtool useをcontrol groupにし、同じ代表taskで品質と総コストを比べます。平均値だけでなくp95遅延、失敗task、拒否された呼び出しも残すと、削減効果の裏で安全性や再現性が下がっていないか判断できます。

関連する記事と支援

Knowledge Base検索を複数段階へ広げる場合はAmazon Bedrock Agentic Retrieval、ツールの順序や利用量を制御する場合はAgentCore Temporal Policiesとレート制限も参考にしてください。自社workflowで通常のtool useと比較し、安全性・費用・運用まで小さく検証する場合は、AI活用・業務効率化支援で要件整理を支援しています。