このページの内容
緑色のテスト結果が、欠けたルールを隠すことがあります。例として、エージェントに店舗とメール配信サービスの接続を依頼します。テスト用サーバーは連絡先の更新を受け入れ、整った 200 を返します。エージェントは仕事を終え、テストは通ります。
しかし実際の送信先には追加のルールがあります。連絡先の更新でカスタム属性を設定する前に、その属性を宣言しなければなりません。テスト用サーバーはそのルールを再現していません。緑色の結果は、テストの世界でのエージェントについて何かを証明しますが、本番の世界にある欠けたルールについては何も証明しません。
これがシミュレーションの基本的な交換条件です。危険または高価な行動を繰り返し試せますが、元のシステムとずれる可能性のある第二のシステムを作ります。
代役があれば行動を試せる
行動するエージェントを試すには、目的、環境、観測できる最終状態を与えます。エージェントの模擬環境に関する資料は、ブラウザー作業や知識作業を例にこの構造を説明します。環境があるからこそ、検証器はエージェントが残した状態を既知の正しい結果と比較できます。
連携の代役には、送信先の少数の操作を公開できます。フィールドの列挙、連絡先の作成と更新、読み戻しです。宣言済みの FNAME と、存在しない CUSTOM_TIER を持つテストデータを用意できます。対応付けを提案させ、定義前に CUSTOM_TIER を使う書き込みを拒否するテストが可能です。
代役の利点は、毎回同じ状態から始められることです。欠けたフィールド、権限拒否、古いスキーマの版、曖昧な識別子など、一度に一条件だけ変えられます。モデルやプロンプトを変えても、呼び出し順と結果の状態を比較できます。
これは、エージェントがどうするつもりかを文章で尋ねるより強い試験です。管理された世界で実際に何を呼び出したかを調べます。
テスト用データには、定型応答だけでなく各呼び出し前後の状態を持たせます。同じ連絡先を二度作成したなら、二度目の呼び出しで試したい重複の振る舞いを示すべきです。書き込み後に読み戻すなら、保存した状態を返すべきです。そうしないと、もっともらしい要求を送るだけで合格し、目的のレコードができたかをテストが発見できません。
忠実度もテストの一部
「提供元にサンドボックスがあるなら、なぜ別のものを作るのか」という反論は妥当です。必要な事例を扱え、データを安全に保てるなら、提供元のサンドボックスを使います。ローカルの代役が価値を持つのは、毎回同じ状態に初期化したい、意図的な障害を起こしたい、サンドボックスでは用意できない呼び出しを試したい場合です。ただし保守費用もあります。再現したルールはどれも間違ったり古くなったりし得ます。
公式のBrevo 連絡先 APIによれば、連絡先の属性はアカウントに存在する必要があり、宣言済みの型と違う値は無視されます。すべての不正値を拒否する代役は、この文書化された事例とは異なります。実際には返らないエラーをエージェントに期待させてしまいます。
代役が再現する提供元の振る舞いを明記します。本物の API または公式のテスト環境に対して、少数の契約確認を続けます。違いを見つけたら代役を更新し、発見につながった事例を追加します。シミュレーションは提供元のモデルであり、提供元の代替ではありません。
時間にも同じ規律が必要です。すべての書き込みを即時に見せる代役では、早すぎる読み取りを見逃します。すべてを遅らせる代役では、提供元にはない失敗を作るかもしれません。試す判断に時間が影響するときだけ再現し、残りは対象外と記します。合格の意味は正確になります。このエージェントは、再現したルールの下で、これらの行動を完了したということです。
Tajo のBrevo コネクターガイドは、店舗側から同じ実務上の問題を説明します。要求が成功してもフィールドが欠けることがあります。HTTP 応答だけでなくフィールドを確認して初めてテストは役立ちます。
模擬的な送信先は再現したルールの下でエージェントを試します。少数の契約確認でそのルールを実際の送信先と比べてから、範囲を限ったプレビューに進みます。
安全な練習から範囲を限った証拠へ
シミュレーションに合格したら、小さな本番プレビューに進みます。期待する送信先の状態が明確なレコードを数件選びます。通常のレコード、任意フィールドがないレコード、同意状態によりマーケティング利用が禁止されるレコードを含めます。送信先に実際に保存されたものを確認し、要求本文だけから結果を推測しません。
合成データでのプレビューと送り先の確認は、別の問いに答えます。Tajoの対応付けプレビューは、送り先に書き込まずに変換を試します。以下の提案図は次の境界を示します。更新が適用されても、送り先の状態を確認する必要があります。保留中と示すことで、練習を証拠と取り違えずに済みます。
書き込みが終わっても証拠は必要です
顧客の同期は完了しましたか？
書き込みを適用しました。検証は保留中です。
送り先の状態はまだ確認していません。
同期アクティビティ
- リクエストを受け付けました
- 更新を適用しました
- 送り先の確認は保留中です
実行例 · 14:32 UTC
分かっていること
- 提供元の応答
- 受け付け済み
- 書き込み結果
- 適用済み
- 送り先からの再読み取り
- 保留中
呼び出しの成功だけでは最終状態を証明できません。
Tajoのアクティビティ履歴を参考にした提案図です。検証状態を加えていますが、送り先からの再読み取りが実装済みという意味ではありません。
プレビューの範囲と停止条件は狭く明確にします。失敗したら広い有効化を止め、フィールド定義、識別子、型、許可、時間のどこに相違があるかを示します。合格しても将来の全レコードが同じとは証明できませんが、選んだ事例について今日その契約が動くことは示せます。
この順序で二つの問いを分けられます。シミュレーションは「世界を管理したとき、エージェントは設計したルールに従うか」を問います。本番プレビューは「設計したルールはこの提供元アカウントに合うか」を問います。どちらももう一方の代わりにはなりません。
リバース ETL のガイドは、最終的な仕事が多くのレコードに繰り返される理由を説明します。その反復により、模擬と現実の契約の小さなずれが大きくなります。
初期化できる世界で練習し、その後で初期化できない世界を調べます。
よくある質問
模擬的な送信先では何をテストできますか？
エージェントが期待する呼び出しを選び、権限を守り、既知のエラーに対処し、模擬環境内に期待する状態を残すかをテストできます。
何を証明できませんか？
提供元の動作を再現したモデルが完全だとは証明できません。文書化されていない振る舞い、処理時間、アカウント固有の設定は模擬環境と違う可能性があります。
模擬環境に合格した後は何をしますか？
実際の送信先に対して範囲を限ったプレビューやカナリアを実行し、広く有効化する前に結果の状態を調べます。