合成データ とは:匿名性を主張せずテスト例を作る
合成データ とは、表している事象の実際の観測結果として収集されたものではなく、例を表すために作成されたデータです。手作業、ルールによる生成、モデルによる生成で作れます。テストでの価値は、明示した事例の網羅範囲と既知の期待結果にあります。合成されたものだからといって、匿名性や統計的な現実性が保証されるわけではありません。
完全に架空のテストデータなら、個人のレコードをコピーせずに、フィールドの欠落や値の矛盾を試せます。実際のレコードに基づいて生成したデータセットでは、作成時にどの情報を使ったかという別の問題が生じます。生成した行をすべて同じように扱わず、由来と想定用途を明示してください。
合成データの作り方
調べる必要のある動作から始め、それを明らかにする値を作ります。正常な例では想定経路を、空の値や型が誤った値では拒否を試せます。各行には、存在する理由と、テスト独自の取り決めに基づく期待する処理結果が必要です。
ルールで生成するデータでは、フィールドを体系的に変化させられます。モデルで生成するデータでは、多様な表現を提案できますが、そのラベルと前提は依然として確認が必要です。どちらの方法も、信頼できる正解データを自動的に提供するわけではありません。生成器が、テスト対象システムと同じ誤解を再現することもあります。
このページでは、目的が現実的な母集団の再現ではなく、境界条件の確認であるため、手作業の小さなテストデータを使います。値は意図的に単純で解釈しやすくしています。追加の動作や既存ルール間の意味のある相互作用を明らかにしない限り、行を増やしてもほとんど価値は増えません。
完全に架空の問い合わせ6行のテストデータ
以下のフィールドと値はすべて合成されたものです。個人のレコード、連絡先、実際の問い合わせは使っていません。この架空のテストデータの取り決めでは、空でない文字列のenquiry_ref、空でない文字列のmessage、informationまたはchangeから選ぶrequested_routeが必要です。メッセージの前後の空白は、空の判定のときだけ除去します。
取り決めは、任意のdeclared_routeも受け付けます。指定されている場合、許可されたルートであり、requested_routeと一致する必要があります。不一致なら確認が必要です。必須フィールドや型の不備は、ルートの競合より優先します。これらは執筆者が作成したテストルールであり、AI Flowiのエンドポイントの説明ではありません。
{
"fixture_id": "enquiry-boundaries-v1",
"origin": "wholly invented",
"all_values_synthetic": true,
"personal_records_used": false,
"purpose": "input-boundary checks",
"population_claim": "none",
"observed_run": false
}
[
{"enquiry_ref":"E01","message":"Which collection days are available?","requested_route":"information","declared_route":"information"},
{"enquiry_ref":"E02","message":"Move collection to Thursday.","requested_route":"change","declared_route":"change"},
{"enquiry_ref":"E03","message":" ","requested_route":"information"},
{"enquiry_ref":"E04","message":"Explain the collection window.","requested_route":"information","declared_route":"change"},
{"enquiry_ref":"E05","message":17,"requested_route":"information"},
{"enquiry_ref":"E06","requested_route":"change"}
]
| 事例 | 確認する目的 | 期待する処理結果 | ルールの根拠 |
|---|---|---|---|
| E01 | 通常の情報問い合わせ。 | 受け入れ | 空でないテキスト。許可されたルートが一致しています。 |
| E02 | 通常の詳細変更の問い合わせ。 | 受け入れ | 空でないテキスト。変更ルートが一致しています。 |
| E03 | 定義した空白検査の後に空となる値。 | 空の値として拒否 | メッセージには空白しかありません。 |
| E04 | 構造化されたルートの競合。 | 競合を確認 | informationとchangeが一致しません。 |
| E05 | JSON自体は有効ですが、フィールドの型が不正です。 | 型の不備として拒否 | メッセージは文字列ではなく数値です。 |
| E06 | 必須フィールドの欠落。 | 欠落として拒否 | messageメンバーがありません。 |
E05は有効なJSONですが、アプリケーションの取り決めに違反するフィールドがあります。JSONの構文エラーの事例ではありません。E06はE03と異なります。メンバーの省略と、明示的に渡した空の値は、異なる検査を試します。その区別を保持すると、どの境界で失敗したかを特定しやすくなります。
このテストデータは、意図的にこれらの6例だけを対象とします。未対応のルート、空の参照、繰り返す送信、失敗のあらゆる組み合わせをテストするものではありません。実際の取り決めに別の関連ルールが加わったら、事例を追加してください。短い一覧から、網羅的であると主張してはいけません。
合成データで網羅範囲と代表性はどう違いますか?
事例の網羅範囲では、テストデータが特定の条件を試すかを問います。代表性では、指定の推論に十分なほど、データが対象の母集団やプロセスを表すかを問います。不正な行を意図的に複数含めることは境界テストに役立ちますが、本番環境で不正な問い合わせが起こる頻度は分かりません。
執筆者が作成した全事例に合格しても、それらの例での動作を示すだけです。モデル全般の品質、実際の顧客満足度、並行するトラフィック下の性能を確定するものではありません。エンドポイントの観測と副作用の確認は、APIテストガイドで扱います。このテストデータは、サービスを実行する前の候補入力を提供します。
執筆者が設定した期待結果と、観測した結果を分けて保持してください。後の試行でE04が受け入れられた場合は、成功したように見せるため期待結果を書き換えるのではなく、当初の期待との不一致を記録します。業務ルールを変更する場合は、新しい取り決めとテストデータのリビジョンが必要です。
合成は匿名化を意味しない
匿名化では、該当する状況で情報を個人に結びつけられるかを扱います。合成データの作成では、データをどう作ったかを扱います。実例を使う生成器は特徴的な詳細を保持することがあり、コピーしたレコードの名前を置き換えても、完全に架空のものにはなりません。
このテストデータの由来について述べる範囲は限定的です。値の作成に、個人に関する入力元のレコードは使っていません。この記述が、合成と呼ばれる他のすべてのデータセットを認証するわけではありません。どの主張が妥当かを判断する前に、入力資料、生成方法、公開目的を確認してください。
モデルによる生成を導入する場合は、生成テキストに意図しないコピーや個人を特定する詳細がないか確認し、入力元の利用許可を記録しておきます。その確認をプライバシーの保証と呼ばないでください。テストに役立つデータセットでも、広範な公開や母集団の分析には適さない場合があります。
AI Flowi Workflowのデータインターフェース
データ構築の取り決めと静的エクスポートの制限は、Create Dataリファレンスで扱います。状態は、カタログに記載されていますが、Ai Flowiによる本番テストは行われていません。
この6行のテストデータは、取り込み可能なコンポーネント設定ではなく、解説用データです。拡張するには、まず未確認のルールを明示します。問い合わせ参照の空欄は、E03とは異なる空フィールドの境界を試します。未対応の要求ルートは許可値への所属を検査し、未対応の申告ルートは、ルートを比較する前に任意フィールドの有効性を検査します。普通の問い合わせを大量に生成して境界を未確認のままにしないよう、追加する各行の目的を明示してください。
不正な値も意図的に保持します。E05の数値メッセージをテキストに書き換えると型の不備の事例が失われ、E06の欠落したメッセージを埋めると省略の事例が消えます。そのため、すべての行をもっともらしくするよう指示した生成器は、テストデータの有用性を下げることがあります。カタログが扱うのはインターフェースであり、テストデータの網羅範囲ではありません。手作業での作成にモデルのアカウントは不要です。任意でプロバイダーによる生成を使う場合は、利用権限のあるご自身の認証情報と、プロバイダーへの別途支払いが必要です。
よくある誤りと関連用語
架空と表示したテストデータに機密性のある入力行をコピーする、通常の入力だけをテストする、生成されたラベルを検証済みの結果として扱う、といったことは避けてください。値または受け入れルールが変わったらテストデータをバージョン管理し、比較のために以前の期待する処理結果を保持します。
データクレンジングは、渡されたレコードの不備を扱います。ETLテストは変換とデータの来歴を検査し、アノテーションは正解ラベルの確認を説明します。架空のテスト例は、実際の結果を証明することなく、これらの確認を支援します。
執筆:Ai Flowi · 公開日