🔍

AIプロダクトの品質保証について〜現場での実例を添えて〜

に公開
AI
QAエンジニア
品質保証
qa4ai
idea

はじめに

Skillnote で QA エンジニアをしている山添です。

今年 4 月から Skillnote では「人材サーチ AI」の提供を開始しました。
（プレスリリース：人材サーチ AI 提供開始）

AI を使ったプロダクトの QA に関わる中で、

  • 「AI の出力って、どこまで保証すればいいの？」
  • 「セキュリティも “ふつうの Web アプリ” と同じでいいの？」

といった悩みが出てきました。

そこで今回は、

  • QA4AI の AI プロダクト品質保証ガイドライン（https://www.qa4ai.jp/）を読んで考えたこと
  • 社内で開発している「人材サーチ AI」で実際にやってみたテスト

この 2 つをベースに、「AI プロダクトの品質保証」をどう考えているかをまとめます。

1. QA4AI から学んだ、「AI の品質保証はなぜ難しいのか」

QA4AI とは？

QA4AI は、「AI プロダクト品質保証ガイドライン」と呼ばれるガイドラインで、
AI プロダクトの品質をどう考え、評価し、保証するかの枠組みをまとめたものです。

社内の読書会で章ごとに読み進めながらディスカッションしたのですが、その中で強く感じたのが、

「AI の品質保証は、そもそも前提が違う」

という点でした。

従来ソフト vs. AI プロダクト：演繹と帰納

QA4AI の中で強調されているポイントの 1 つが、演繹的開発 と 帰納的開発 の違いです。

演繹的開発（これまでの多くのソフトウェア）

  • 定義された仕様に対して、内部設計や実装を明示的に関連付けることができる
  • 「この仕様なら、このテストをすればよい」といった形で整理しやすい

帰納的開発（機械学習・LLM を含む AI プロダクト）

  • 学習データからふるまいを 帰納的 に決める
  • 「なぜこの判断をしたか」を、コードだけ見ても追いづらい
  • その結果として、「テストケースを全部通ったから OK！」という従来のやり方が、そのままは通用しない

このあたりが、AI プロダクトの難しいところだと感じました。

5 つの軸で品質を評価する

QA4AI では、AI プロダクトの品質を次の 5 つの軸で捉えています。

  • Data Integrity

    • 学習データの量は十分か
    • そもそも要件に合ったデータなのか など

  • Model Robustness

    • モデルの精度は十分か
    • モデル更新のたびに、どのように検証しているか など

  • System Quality

    • システムとして提供している価値は適切か
    • 法規制にちゃんと適合しているか など

  • Process Agility

    • 開発の迅速性
    • 自動化は十分にされているか など

  • Customer Expectation（顧客の期待）

    • ステークホルダーの期待度
    • その期待は現実的か、過度に高すぎないか など

個人的に一番興味深いのは、最後の Customer Expectation です。

「顧客の期待値」をコントロールするのも品質保証

QA4AI では、5 つの軸のバランスが悪い状態を、

  • 「データ・モデル・システム・プロセスのどこかが弱い」
  • あるいは「顧客の期待だけが高すぎる」

という形で整理しています。

そのため、品質保証という観点では、

  • 顧客に対して AI の特性（確率的な動作）を理解してもらうこと
  • 顧客の期待値を適切に把握し、その期待を満たすように品質保証を実施すること

が必要になります。

2. AI プロダクト「人材サーチ AI」で実際にやってみたテスト

ここからは、社内で開発している「人材サーチ AI」に対して、実際にどんなテストをしたかを紹介します。

実施したテスト

1. 演繹的にテストできる部分

人材サーチ AI でも、AI 以外の部分は従来の Web アプリと同じようにテストできます。

  • パフォーマンステスト

    • 一定件数以上のデータがあっても、レスポンス時間が許容範囲か

  • 出力された人材情報が「存在するか」のチェック

    • AI が返してきた「メンバー ID」や「力量情報」が、実際にデータとして存在しているか
    • この段階では「その人が本当に適任か」までは見ない

つまり、

「AI が返してきた“キー情報”が、システム内で一貫して扱えているか」

といった 整合性のテスト を中心に行いました。

2. セキュリティテスト

セキュリティに関しては、LLM プロダクトのセキュリティ資料を調べた上で、主に次のような観点でテストしました。

  • プロンプトインジェクション

  • 他テナント情報の漏洩（認可制御の不備）

    • 例：A 社のテナントから、B 社にしか存在しないデータを引き出せないか

LLM のセキュリティに関しては、

  • 「LLM を信用しない」ことを前提に設計する
  • すべてのリソースに対して最小権限を設定する

といった考え方が重要になります。
そこが確実に担保されているかの確認は、開発者・QA エンジニアともに必須だと感じています。

現在のプロダクト開発の進め方

一方で、帰納的な部分（アウトプットの妥当性） については、まだ試行錯誤中です。

  • 「この人材候補は“それっぽい”けど、本当に良いのか？」

といった 中身の良し悪しの評価 には、人間の評価・ドメイン知識がどうしても必要になります。

会社としてはベータ版の段階では、

  • 実際に使ってもらいながらユーザーのフィードバックを集める
  • それをもとにモデルやプロンプト、評価指標をブラッシュアップしていく

というアプローチを取ろうとしています。

ここはまさに、帰納的開発＋探索的テスト の世界だなと感じています。

おわりに

今後、AI プロダクトの品質保証のレベルをより高めるために、実践・意識していきたいことは下記のとおりです。

  • QA4AI のチェックリストなどを実プロジェクトで使用してみること
  • モデルやデータの質にも QA が関心を広げること
  • 「AI を使うとできることが増えた分、セキュリティもより意識する」こと

正直、まだ
「これが正解！」と言えるような形にはほど遠いのですが、

  • いま持っている QA のナレッジをどう転用するか
  • どこから先を “探索的・帰納的” な領域として割り切るか
  • そのうえで、ユーザーや顧客の期待値を理解し、出力結果がその期待値に達しているか

を考え続けることが、AI 時代の品質保証 において大事な点なのかなと感じています。

Discussion