答えは正しい。しかし経路が間違っている。

同じ「420」という数値が、相容れない二つの理由から正しく見えることがあります。例として、二つのエージェントが同じ連絡先の対象集団を返し、いずれも顧客数を420と報告したとします。一方は承認済みの店舗の対象集団を使い、同意を確認しました。もう一方は別のワークスペースにある古いエクスポートをコピーし、偶然同じ件数を得ました。

結果だけを採点すれば、両方が満点です。それは誤った評価です。

エージェント環境の検証に関する議論は、最終出力とそこに至る経路を区別します。表計算の例では、正しい数値は仕事の一部にすぎません。数式、参照元、必要な書式も重要です。連携ではこの区別がさらに切実です。結果の出所によって、そもそも許可された作業かどうかが決まります。

最終値から来歴は証明できない

エージェントが店舗の顧客オブジェクトからマーケティングシステムへのフィールド対応を提案したとします。email をメールに、firstName を名に、同意のフィールドを送信先のマーケティング状態に対応させます。プレビューはもっともらしく見えます。

その判断のために何を読みましたか。現在のスキーマ、古い標本、それとも別アカウントの文書でしょうか。同意フィールドの意味を調べたのでしょうか、それとも名前から推測したのでしょうか。null を「未購読」と解釈したのでしょうか、「不明」としたのでしょうか。

答えが違えば、同じ最終対応付けでも信頼性が変わります。対応表は出力です。証拠の経路こそ、それを使う根拠です。

その経路には、判断時点で参照できた各資料の版を記す必要があります。後から修正したスキーマの画面を示しても、昨日提案した対応付けは説明できません。関係するスキーマや文書の版を判断とともに記録し、その版と承認済みルールの結び付きを残します。目的は、エージェントが見た全ページを保存することではなく、判断を再現できることです。

そのため、ツールの実行記録は自信に満ちた説明より重要になり得ます。実行記録には実際に使った呼び出しと識別子が残ります。文章による要約も役立ちますが、資料を参照した証明にはなりません。連携の証拠は、元のオブジェクト、送信先の契約、データを移す具体的なルールを指すべきです。

業務ツール連携ガイドがフィールドの所有者から始めるのは、両側の名前だけでは権限が決まらないためです。過程の確認では、エージェントが書き込み案を作る前に、その所有者の判断を実際に参照したかを問います。

許された経路を課題に書き込む

よいテストケースには二つの部分があります。まず送信先に何があるべきかを定めます。次に、そこへ至るために許される証拠と行動を定めます。

例の対象集団なら、期待する出力は420件かもしれません。しかし承認された経路には、店舗の範囲に限定した検索、現在の同意の対応付け、除外されたレコードを示すプレビューも必要でしょう。ワークスペースをまたぐ読み取りや、キャンペーンの直接送信は禁止できます。

これなら検証器は具体的に動けます。別のワークスペースの識別子を機械的に拒否できます。有効化前にプレビューが呼ばれたか確認できます。出力に記されたデータ元が実行記録のデータ元と一致するか確かめられます。これらはモデルの意見ではなくルールです。

残る問いには判断が必要かもしれません。選んだ同意フィールドは、このキャンペーンへの許可を本当に意味するでしょうか。そこでは人、または対象を絞った判断モデルが、フィールド定義と用途を調べます。ルールと判断の役割は違います。

その結果、テストは役立つ失敗理由を示せます。「答えが違う」だけではチームは推測するしかありません。「件数は正しいが、対象者を別のワークスペースから読んだ」ならデータ境界の失敗です。「対応付けは正しいが、同意の定義を確認できない」なら証拠の不足です。検証器は失敗した条件と原因となった実行記録を示し、修正が文言ではなく経路を変えられるようにします。

実行記録から何が分かるか？

1. 承認済みの資料と必要な確認

   経路を受け入れる

   結果に課題が要求した証拠があります。

2. 別ワークスペースの資料

   経路を拒否する

   件数が一致しても、その読み取りは許可されません。

3. 必要な証拠がない

   審査まで保留する

   出力だけでは導出過程を証明できません。

実行記録を儀式にしない

「必要な呼び出しを実行しても、その結果を無視できる」という反論は正しいです。呼び出し一覧が証明するのは呼び出しが起きたことだけで、返された証拠が判断に反映されたことではありません。

一つの試験方法は、証拠を変えることです。ほかは似ていて同意状態だけ違う二つのレコードを示します。両方に同じ対応付けと説明を返すなら、参照したふりをしている可能性があります。別の方法は、必須資料を取り除いて停止を要求することです。記憶で空白を埋めるエージェントは、許された経路を守っていません。

その分、テスト用の条件を作る手間は増えます。誰かが許可された資料、区別すべき結果、禁じられた近道を定めなければなりません。「答えがよさそうか」という汎用的な採点のほうが作成は安価ですが、得られる学びは少なくなります。

リバース ETLは対応付けを反復的なデータ移動に変えます。承認後は通常のコードが各行に適用でき、エージェントが毎回証拠を見直す必要はありません。経路の監査はルールを作成または変更する判断時と、契約の変化で再検討が必要になったときに行います。

別のアカウントを経由して得た正解は、惜しい失敗ではありません。別の仕事をしたのです。