AI連携テストのデータ準備｜実データを持ち込まず境界を試す

AI連携のテストデータには、欠損・表記ゆれ・重複と権限を意図的に組み合わせた合成データを使い、業務データの持ち込みを避けます。実行可否は、各組み合わせの期待結果、権限制御、確認ログ、合否条件まで判断表に記録できたかで決めます。

ただし、条件を一つずつ試すだけでは境界を十分に切り分けられません。欠損したレコードが重複し、さらに読取専用の利用者が処理したとき、AIの出力と業務システムの更新をどこまで許すのか。自社でテストを始める前に、この複合条件への答えを固定しておく必要があります。

AI連携のテストデータで確かめる境界

AI単体の応答確認と、業務システムをつないだ結合テストは分けて考えます。ここで対象にするのは後者です。入力の取得、AIへの受け渡し、結果の返却、権限に応じた表示や更新、ログの記録までを一連の処理として確認します。研修で操作を覚えるための演習データとは、目的も合否条件も異なるため、台帳と保管場所を分けます。

2026年9月21日時点で、NIST AI RMF PlaybookのMEASURE 2.1は、テストセット、指標、テスト・評価・妥当性確認・検証に使うツールの詳細を文書化することを掲げています。測定方法とプロセスの文書化は、反復可能性と一貫性の基礎になるという整理です。つまり、入力データだけを保存してもテスト設計は再現できません。どの条件で何を観察し、何をもって合格とするかを同じ成果物に残す必要があります。

同じく2026年9月21日時点のMEASURE 2.3は、導入環境に類似した条件で測定結果を文書化し、非最適条件で定期的にテストすること、測定環境と導入環境の差異を記録することを提案しています。合成データに置き換えることは、実運用との差を無視する理由にはなりません。接続先、権限の判定点、更新の可否など、想定導入環境との違いをテスト結果と一緒に残します。

欠損・表記ゆれ・重複と権限を交差させる判断表

以下は、出典の一般原則を基にした実務上の提案であり、原典所定の分類や義務ではありません。行にデータ状態、列に権限状態を置き、各セルを独立したテストケースとして扱います。

表を埋める目的は、すべてのセルでAIを動かすことではありません。「拒否なら入力取得前に終了」「必要項目が欠けていればAIへ渡さず保留」のように、処理しないことが期待結果になるセルもあります。権限をAIの出力表示だけの問題にせず、入力取得、前処理、AI処理、業務更新のどこで止めるかまで定めるのが要点です。

各セルには、入力、期待される処理結果、期待される権限制御、確認するログ、合否条件を記録します。たとえば「欠損＋重複／読取専用」なら、欠損箇所と重複キーを入力欄に示し、処理結果欄には保留か候補提示かを記します。権限制御欄では更新されないこと、ログ欄では停止または判定の記録箇所、合否欄では確認者が迷わない観察可能な状態を定めます。

実データを複製しない合成台帳

合成データだからといって、無秩序な架空データでよいわけではありません。2026年9月21日時点で、NIST SP 800-188の表3は、テストデータを元データの構造や値域に似せつつ、元データにはない極端値をソフトウェア試験用に含め得るデータと説明しています。同資料の4.4.2は、構文上は有効でも分析上正確な情報を伝えないデータをソフトウェア開発に利用でき、機密データとの取り違えを避けるため、氏名や住所などを明白に不自然な形にすることが有用だとしています。同資料の発行日は2023年9月14日です。

この原則を基に、結合テスト用台帳はケース条件から合成し、架空だと明白な識別子、氏名、組織名で作ります。これは、出典の一般原則をテスト設計へ適用した実務上の提案です。各ケースには次の項目を持たせます。

• ケース識別子：研修用や実データと取り違えない名称
• 入力条件：正常、欠損箇所、表記ゆれの種類、重複キー
• 権限条件：許可、読取専用、拒否のいずれか
• 期待結果：処理、保留、拒否など、業務側が受け取る状態
• 確認点：権限制御、更新の有無、確認対象のログ
• 環境差分：想定導入環境と異なる接続先や設定

これらがそろえば、失敗時に「AIの判定」「データの前処理」「権限による停止」「業務システムへの反映」を切り分け、再確認すべき境界を判断できます。氏名だけを架空にして元の識別子や自由記述を残す作り方は、この台帳の方針には合いません。作成元はケース条件とし、実データの識別子や自由記述を台帳の材料から外します。

2026年9月21日時点で、Google CloudのAI/MLセキュリティ指針は、業務目的に厳密に必要でないデータを収集・保持・使用しないデータ最小化を勧め、可能なら合成データまたは完全に匿名化したデータを使うとしています。同指針は、役割ベースのアクセス制御と最小権限を実装し、職務に必要な最小限の権限だけを付与することも勧めています。ページの更新日は2025年11月26日です。この二つの推奨を踏まえると、合成台帳のデータ状態と権限列は一つのケースとして交差させる必要があります。

自社で実行するための開始判定

次の開始条件も、出典の一般原則を基に記事が提案する実務上の方法であり、原典所定の分類や義務ではありません。すべてを満たした場合に、業務システムの結合テストへ進みます。

• 対象を業務システムの結合テストに限定し、研修演習と区別している
• ケース条件から作り、由来を再確認できる合成台帳がある
• 欠損・表記ゆれ・重複の単独条件と複合条件が判断表にある
• 許可・読取専用・拒否ごとの期待結果と、止める処理段階が定義されている
• 各セルに確認ログと合否条件があり、同じ条件で再実行できる
• 測定環境と想定導入環境の差異を記録できる

一つでも未確定なら、テスト件数を増やす前に判断表へ戻ります。特に「読取専用だから安全」「合成データだから権限確認は不要」とは置かず、入力の取得から業務更新までの各境界に期待結果を割り当てます。

実装範囲そのものが固まっていない場合は、AI導入の進め方を課題定義から整理するガイドで対象業務と判断主体を先に合わせます。検証後に本番接続へ進む条件は、AIのPoCから本番運用へ移行するための整理と併せると、環境差分を残す意味が明確になります。

境界を説明できる状態で始める

自社でAI連携テストを実行する開始点は、合成データの完成より後にあります。欠損・表記ゆれ・重複を組み合わせた各行と、許可・読取専用・拒否の各列について、処理する理由と処理しない理由を説明でき、期待結果、権限制御、ログ、合否条件を再確認できる段階です。

最も厳しい「欠損＋表記ゆれ＋重複／拒否」のセルから、入力取得前に止めるのか、前処理後に結果を開示せず止めるのかを決めてください。その決定を他のセルへ展開すれば、実データを持ち込まずに、業務システムとの境界を具体的に試せます。判断表や環境差分を自社だけで確定しにくい場合は、公開LPの無料相談やAI活用診断で、課題定義・実装・定着のどこに未決定があるかを整理できます。

FDE・AI実装ガイドへ戻る