FetchSandbox

サンドボックスは呼び出し間で状態を保つので、作成した顧客は課金するときにも残っており、Webhookも実サービスのように発火する。ここが重要だ。連携のバグの多くは連続した流れに潜み、単一のリクエストにはない。本番に触れずに本番APIと同じように振る舞う。開発中に本物のキーも本物の課金もない。

FetchSandboxは単なるAPIテストツールではなく検証エンジンとして自らを位置づける。エージェントが何かを直したと主張したとき、ツールは同じシナリオを古いコードと新しいコードに対して実行する。修正は実行前に失敗し実行後に通ったときだけ意味を持ち、曖昧な「良さそう」を終了コードに変える。会社が掲げる目標は自動化できる判定であり、同僚の意見ではない。

MCPサーバーはサンドボックスを主要なAIコーディングアシスタントに接続し、CLIはターミナル駆動のワークフローを担う。どちらもMITライセンスのオープンソースだ。ホスト型エンジン、サンドボックス、Webhookシミュレーションが有料部分となる。リポジトリを預ける前に連携コードを読みたいなら、この切り分けは役に立つ。

Webhookは多くのテスト構成が飛ばす部分であり、FetchSandboxが力を注ぐところでもある。Webhookを複製し、イベントを順不同で配信し、古いイベントを発火して、ハンドラーがどう反応するか見られる。各ワークフローは必須のWebhookイベントと不変条件を仕様の一部として列挙する。「本当に動いたのか」にようやく答えが出る。

実行するたびにレシートURLが生成され、誰でも開いて再生できる。これが信頼の部分だ。プルリクエストやSlackスレッドに貼れば、レビュアーはスクリーンショットを鵜呑みにせず何が起きたか監査できる。各ステップはメソッド、パス、レスポンスコード、所要時間を持ち、各Webhookは署名検証の結果を持つ。もう推測はいらない。

カタログにはStripe、Twilio、Resend、Clerk、Privy、AgentMail、Surge、Kulipa、WorkOSといったプロバイダーの既成サポートが入っている。一つ選べば、空白のモックサーバーではなく数分で動くサンドボックスが手に入る。上位プランでは仕様から自分のAPIを最大五つ追加でき、社内サービスを持つチームはここに行き着く。

すでに一つ連携があるリポジトリに二つ目を足すと、ツールは両方を読んでつなぎ、三つ目を足せば三つとも読む。記録された一例では、Clerkが設定したユーザーIDがStripeの決済メタデータに流れ、次にResendの参照へ流れる。孤立したモックサーバーにはできない。実際のコードベースの配線に、この製品が最も近づくところだ。

要求されたシナリオが成立しないとき、ツールは偽の通過を報告せず、その旨と理由を伝える。公開されたStripeセッションでは、拒否された支払いのシナリオが実行されなかったと指摘した。厳選ワークフローのハッピーパス用テストカードがそれを上書きしたためで、その後その分岐を試すための正確なコマンドを列挙した。ツールの限界を知ることは、信頼できない緑のチェックマークより役に立つ。