生成AIサービスで品質保証が難しい理由。従来システム開発との比較 |株式会社renue

公開日: 2025/4/25
2023年始ごろより、ChatGPTの登場もあり大きく生成AI、特に自然言語モデルが話題になっているかと思います。多くの企業が「うちではAIを使ったサービスを出す予定です」と広報をしていますが、中にはリリースする前に品質が担保できずに困っている方も多いのではないでしょうか。本稿では、筆者が実際にAI研究・開発および通常の業務システム導入に関わってきた経験を元に、生成AIサービスを実際にリリースする上で課題になる品質担保について解説したいと思います。
システム開発の流れと品質担保
話が少し逸れますが、通常システムの開発ではAIほど混乱はなく、予定通りリリースされる事が多いかと思います。これは長年の経験を世界中で蓄積したプロジェクト管理技術によるモノです。その中でもまずは最も基本的とされる「ウォーターフォール」を前提として品質担保について説明します。

上記の図は「Vモデル」と呼ばれるシステム開発における大きな流れを説明する図です。縦軸がビジネス - 開発のグラデーションで、横軸はプロジェクト進捗の時間軸を表します。まず、プロジェクトで「何を達成するか」をRFP(提案依頼書)などの形で表し、そこから徐々に具体的な設計に移っていく流れです。一番下の「実装」まで到達した後は、テスト工程に移行し、それぞれ高さが一致する層の要件・設計を満たしているかを確認していくことになります。この手法により、厳密にシステム仕様を決めていく事で、手戻りが起こる可能性の低減と想定外の早期検知を可能にしています。

次にこのVモデルを前提とした時に、生成AIを組み込むと一番下に位置している実装・単体テストの領域で問題が起こる事を説明します。基本的に、AIは不確定性を含んだプログラムです。このため、入力と出力が必ずしも一致するわけではありません。このため、従来の単体テストでは
足し算関数に、「1」と「1」を入力したら必ず「2」を返してくる
という挙動を確認するだけで良かったのですが、生成AIでは回答が都度異なってくるため、「必ずこの答えが来る」というテストを行う事ができません。これはVモデルの根幹を揺るがす問題で、ビルの建設において「鉄骨やコンクリートブロックの大きさと形が安定しない」という状態と同じに捉えられます。

このため、従来のシステム開発ではビルの建設に例えると、
土台が設計通りである (単体機能が想定通り)
土台の上に乗せた柱が設計通りである (機能間結合が想定通り)
柱に沿って組み立てた骨子・壁が設計通りである (システム間IFが想定通り)
発注主が想像した通りの間取り、デザインである (ユーザビリティが想定通り)
というような下からの積み上げによる品質担保が可能でした。
しかし、AIにおいては積み上げは難しいです。そのため、いわゆるアジャイル開発※に近い体制で開発している場合が現状は多いです。しかし、従来んアジャイル開発も基本的にはVモデルを基盤とする考え方の派生であるため、AサービスI開発に転用する場合には注意が必要になります。
※ アジャイル開発とは、大型のシステムを作り上げてから一度にリリースするのではなく、一定のサイズの要件を細かくリリースする形式。WEBサービスなど継続的な改善を要する開発環境では好んで使われ、ユーザーの反応を見ながらサービスを改善していく事が可能。
テスト密度とテストケース網羅
次に、「出力が安定しない」という大きな課題とは別に「入力パターンが無限に想定される」というAIの性質からテストの難しさを語っていこうと思います。ここで重要になるのが、テスト密度とテストケースの網羅という概念です。

まずテスト密度とは、「開発規模に応じて適切なテストの数がなされているか」という指標で、単純に機能数やプログラム規模に比例して、より多くのテストをこなすべきと言う考え方に基づいています。類似の指標にバグ密度もありますが、こちらは「人は必ず一定確率でミスをするので規模が大きいほどバグが見つからないとおかしい」という前提の指標になっています。このように、システム開発においては人が間違える事を前提としたチェック体制を敷く事でシステム品質を上げるフレームワークが存在します。

次にテストケースとは、システム動作をテストする際の入力値および外部環境などを少しずつ変えたパターンの総称です。システムを機能単位に分けて考えた時に、各機能が入力を受け付けしうるパターンを網羅していく事で、理論上全てのパターンを出す事ができます。特に、異常検知を行うテストパターンの作成は重要で、数字が入る枠に「?」と「?」をそれぞれ入れてみる、「月初で入力」「平日に入力」「休日に入力」で分けてみる、など細かいパターンまで試す事でバグを見つける事ができるようになります。

この時、AIが大きな問題を起こすのが「入力パターンが無限に存在するのでテストケースを網羅できない」という特性です。上記の図でも3つの無限性を示唆しています。
用途: ユーザーがAIに求める機能が無限パターン存在する
表現: 同じ要望であっても、入力される文字・画像は無限パターン存在する
文脈: 全く同じ入力であっても、それまでの文脈は無限パターン存在する
これらのテストケースを全て網羅する事は不可能です。このため、仮にAI開発責任者が社長から「このAIが差別的な発言や嘘を言う可能性をゼロにしろ」と指示されても絶対にこれを保証する事ができません。勿論、様々な回避方法はあるのですが、従来のテスト手法では全てのパターンは潰せないというのが実情です。
AIによるAIのテスト:GAN(敵対的生成ネットワーク)
ここで有効と言われているのがAIによってAIの品質をテストする手法です。特にGANと呼ばれる手法は、近年急速に広まっており、この登場によってStable Diffusion(画像生成)やChatGPT(自然言語処理)などのAIモデル・サービスが実用化に至ったと言われているほどです。本来GANは、モデルを作る場合や追加学習を行う場合によく使われていますが、実務におけるサービス品質検証にも同じ考え方を使う事ができます。

サービス開発では厳密には異なりますが、GANにおいてはGenerator(贋作者)とDiscriminator(鑑定士)を対決させ続け、GeneratorがDiscriminatorを騙せるほど高度な偽物を作れるまで対決を繰り返す事で精度を上げる手法です。初めは単なるノイズの様な画像しか出せなかったGeneratorも、この手法でDiscriminatorに敗北し続けた事で加速度的に綺麗な画像を生成できる様になりました。
実務においてモデル開発ではなく、既存モデルを追加学習やエンベッディング、プロンプト制御によって利用する事が多いと思います。しかし、同じ考え方でのサービス開発を行い、出力結果をAIによって「高品質である」など評価をさせる事で、テストケース網羅の難しさと言う課題に立ち向かっている事例は増えています。
(こちらが良記事のため英語に抵抗のない方はご拝読をおすすめします。https://towardsdatascience.com/testing-large-language-models-like-we-test-software-92745d28a359?gi=4132bc5df8d6)
また、品質が高いかをテストするのには向きませんが、プロンプトインジェクション攻撃やAIの致命的なミス(不適切な発言など)を防ぐための最低保証的な手法もいくつか存在しています。
ホワイトリスト: 入力・出力しても良い単語を登録する
ブラックリスト: 入力・出力してはいけない単語を登録する
プロンプト制御: 攻撃被害や差別発言などを避ける様念押しする
agent層の実装: 生成と入力・出力の判別機を分けて設置する
ただし、これら手法を用いても「Open AIなどモデルを提供している団体が仕様をアップデートする」という外部要因による出力のブレはカバーできません。例えば、GPTモデルを使うのであれば、Open AIによるアップデートがあれば、全てのテストケースをやり直さないと出力の変化を誰も予測できません。
実務でのAIサービスの品質保証
まずは本稿で記述した生成AIを用いたサービスを作る上での品質保証の観点での難しさを改めてまとめてみましょう。
# | 原因となる課題 | 発生する課題 |
---|---|---|
1 | 出力結果が安定しない | 先に具体的に設計してから開発する従来手法が使いづらい |
2 | 入力パターンが無限に存在する | テストケースを十分に用意できず、品質を保証できない |
3 | 外部環境の変化に機能が依存する | 外部サービスの更新によって品質検査をやり直す必要が生じる |
これらの問題は、AIがいまの形である以上は基本的に解決されないと筆者個人は考えています。そのため、これらの不確定性をいち早く取り込んだIT組織を作る事こそが、これからの時代に求められるとも考えています。

宣伝になりますが、弊社ではこれらのリスク・品質保証の課題を解決する「AI品質保証の代行サービス」を立ち上げています。内製化の意図がある場合、全てを任せたい場合など様々なケースがあるかと思いますが、まずはお気軽にご相談ください。
https://renue.co.jp/business/06
このサービスでは、GANのようなテストを擬似的に生み出すため、評価AIとテストケース生成AIを合わせて整備します。このために、まず通常のIT開発同様にテストケースを業務要件に照らして網羅的に作る必要があり、人とAIの共同作業を行なっています。このテスト環境は一度作れば継続して使えるため、外部環境の変化にも強いです。お困りの際にはぜひご相談ください。
# | 原因となる課題 | 弊社解決手段 |
---|---|---|
1 | 出力結果が安定しない | 業務・開発部隊と連動して、出力のブレを織り込んで開発できるプロジェクト管理環境を提供 |
2 | 入力パターンが無限に存在する | テストケース生成AIと評価AIによって人力では不可能な量のテストを実施 |
3 | 外部環境の変化に機能が依存する | テストケース生成AIと評価AIを定期的に動かす事で品質保証を継続し、AIの信頼性を向上 |