AWS ToolSimulator：ライブAPIコールなしでAIエージェントをテストするLLM駆動フレームワーク——複数ターンの会話を通じた共有状態の維持

AWSは何を発表しましたか？

AWSは2026年4月20日にToolSimulatorを発表しました——Strands Evalsプラットフォーム内の新しいフレームワークで、ライブAPIコールを実行せずにAIエージェントを安全かつスケーラブルにテストするために設計されています。目的は、本番エージェント構築における最も痛点の1つを解決することです：メール送信、データベース変更、フライト予約を行うエージェントを、実際の結果なしにどうテストするか。

従来のモックが不十分な理由

開発者は数十年来モック——事前に定義された応答を返す外部システムの偽バージョン——を使用してきました。エージェントの問題は、それらが動的な複数ターンの会話を行い、その中でシステム状態が進化することです。従来のモックは静的です：毎回同じ応答を返します。「ステップ1でこのユーザーを作成したから、ステップ5で更新できる」とは言えません。

結果：モックは薄すぎる（現実味がない）か、維持コストが高すぎる（各テストシナリオに手動でステートマシンのコーディングが必要）かのどちらかです。

ToolSimulatorはどう問題を解決しますか？

ToolSimulatorは内部でLLMを使用してその場でツール応答を生成します。核心となる革新は共有状態です——シミュレーターは会話で起きたすべてを記憶し、将来の応答が履歴と一貫していることを保証します。

例：エージェントがステップ2で create_user(name="Ana") を呼び出します。ステップ7で list_users() を呼び出すと——ToolSimulatorはAnaが以前に作成されたためリストに含まれていなければならないことを知っています。LLMなしでは開発者がその状態を手動でコーディングする必要がありましたが、LLMがあればシミュレーターが自動で処理します。

統合はどのようなものですか？

技術的な統合は宣言的でシンプルです：

• @simulator.tool() デコレーター — 開発者がPython関数をエージェントが利用できるツールとしてマークします。シミュレーターがシグネチャとdocstringを自動的に取得します。
• Pydanticモデル — スキーマ強制実行に使用されます。Pydanticは引数と戻り値が正しい型を持つことを検証します——エージェントが数値の代わりに文字列を送ると、LLMが応答を生成する前にそのレベルでテストが失敗します。

開発者はしたがってツールの説明を書くだけで、実装は不要です——ToolSimulatorが残りを処理します。

PIIの保護がなぜ重要ですか？

定義：PII（Personally Identifiable Information）は個人を特定できる情報——名前、マイナンバー、住所、電話番号、メールアドレスです。

ライブAPIでエージェントをテストすることはPIIがログ、ステージングデータベース、分析に漏れることを意味します。これは規制上の問題（EUのGDPR、米国のHIPAA）であり、実際的な問題（ステージング環境から公開環境への漏洩）でもあります。

ToolSimulatorは実際のAPIを一切呼び出さないため、PIIの漏洩源がありません——シミュレーションはリアルに見えるが実際の人物に紐づかない合成データを生成します。

誰に役立ちますか？

ツール使用でエージェントを構築するすべてのチーム。MVPエージェントをテストするスタートアップから本番デプロイを検証する大企業まで。特に以下に役立ちます：

• ユニットテスト — エージェントと1つのツールの1回のやり取りを分離
• エンドツーエンドテスト — 複数のツールとステップを持つ完全なワークフロー
• リグレッションテスト — 新しいモデルが古いモデルと同じ動作をするか確認

結論

ToolSimulatorは実際の問題に対する具体的な回答です：本番エージェントにはテストが必要ですが、ライブシステムでのテストはコストが高く、遅く、リスクがあります。このAWSの動きは、エージェントのオブザーバビリティとテスタビリティがクラウドインフラのファーストクラス市民になっていることを示しています。Strands Evalsとの統合により、プラットフォームに完全なスタック——開発からシミュレーション、評価まで——が揃いました。