kickflowのAI申請前レビュー機能の品質評価プロセス

AI申請前レビュー機能の品質評価プロセス

こんにちは！QAチームのmakiです。

kickflowでは、先月AI申請前レビュー機能をリリースしました。

AI機能のQAは、従来のソフトウェアテストとは異なるアプローチが求められます。 AIは同じ入力に対して常に同じ結果が返るとは限りません。 また、「どこまでの精度を許容するか」という基準を事前に決めておく必要があります。

この記事では、AI申請前レビュー機能のQAをどのように実施し、何を評価したかをまとめます。 AI機能のQAに取り組む方の参考になれば幸いです。

AI申請前レビュー機能とは

この機能は、ワークフローの申請内容をAIが事前にチェックし、入力ミスや不備を指摘してくれるものです。

kickflow.com

入力ミスや不備があった場合、指摘のある入力欄の下部と、画面下部のAI申請前レビューエリアにAIによる指摘が表示されます。

• 指摘は2種類
  • AIが修正を強く推奨している（Error）
  • AIが修正を推奨している（Warning）

AI申請前レビューのUI

AIによるレビューの対象範囲

AI申請前レビューは、申請者が入力可能な以下のフィールドが対象です。

• タイトル
• 汎用セクションと明細セクションの以下のフィールド型
  • テキスト（短文）
  • テキスト（長文）
  • 整数
  • 数値
  • 日付
  • プルダウン
  • チェックボックス

混同行列（AI評価の4分類）の定義

分類	略称	期待する判定	AI判定結果	意味合い
真陽性	TP (True Positive)	指摘あり（Error/Warning）	指摘あり（Error/Warning）	AIが正しく見つけた
偽陽性	FP (False Positive)	指摘なし	指摘あり（Error/Warning）	過剰な指摘
偽陰性	FN (False Negative)	指摘あり（Error/Warning）	指摘なし	見逃し
真陰性	TN (True Negative)	指摘なし	指摘なし	AIが正しくスルー

今回は以下の2つの指標を使って評価しました。

• 再現率（Recall）: 「見逃し」の少なさ
  • AIが、本来指摘すべきミスをどれだけ拾えたか。「ザル検査」になっていないかを確認する指標です。
  • 計算式：TP / (TP + FN)
• 適合率（Precision）: 「指摘」の正確さ
  • AIが出した指摘が、本当に正しいものだったか。「オオカミ少年（嘘の警告ばかり出す）」になっていないかを確認する指標です。
  • 計算式： TP / (TP + FP)

1. 準備フェーズ：評価基準と前提条件の設定

QAを始める前に、「どのくらいの精度ならOKとするか」を決めることが大切です。

1.1. 合格ラインを決める

アクション	やること
① 目標の合意	「90%以上の精度を目指す」など、関係者と目標値を握る
② 正解の定義	「何をもって正解とするか」を決める。例えば、「AIが何かしらの警告を出せばOK」とするのか、「警告の内容まで合っていないとダメ」とするのか
③ 時間の制限	ユーザーを待たせないため、「60秒以内に結果を返す」といったパフォーマンスの基準も決める

1.2. 評価フローの定義とデータ設計

アクション	目的と留意点
① フィールド別分析の計画	AIの得意/苦手を特定するため、フィールド型ごと（数値、日付など）に精度を算出し、評価する計画を立てる
② 複数回の試行	AIの出力は確率的なため、同一入力データで複数回（例：100回）試行する
③ 前提条件の文書化	AIが参照する「説明文」などのワークフロー設定をすべて文書化し、テストデータとセットで管理する

2. 実行フェーズ：評価と分析フロー

精度と不安定性の両面から結果を評価します。

ステップ	実施内容	評価のポイント
① データ収集と記録	各フィールド型ごとに複数回試行を実施し、AI判定結果と実行時間を記録する	記録がTP/FP/FNの件数算出に直結するよう、正確に入力する
② 精度評価の計算	再現率（見逃しの少なさ）と適合率（指摘の正確さ）を計算し、許容ラインと比較する	フィールド別と全体の両方で数値を算出する
③ 不安定性の深掘り	FN（見逃し）や結果がブレたケースを抽出し、その原因（AIロジック、設定ミスなど）を開発者と協力して特定する	原因の特定により、改善の方向性を明確にする
④ パフォーマンスの検証	実行時間データから、最大実行時間が許容ライン（例: 60秒未満）を超えていないかを確認する	基準を超過した回数や条件を分析する

フィールドタイプ別の指摘基準（一例）

3. リリース判定フェーズ：リスクベースの判断

QAが算出した評価結果を基に、PMや開発者への情報共有とリスクの明確化を行います。

判定ステップ	QAの実施内容	目的と判断基準の視点
① 許容ラインとの照合	算出した再現率・適合率が、事前に合意した許容ラインをクリアしているかを判定し、不適合なフィールドをリストアップする	リスクの発生有無を数値で明確化する
② リスク・インパクトの報告	不適合となったフィールドについて、「見逃し率（再現率の低さ）がユーザーの信頼性低下に繋がる」といった業務上のインパクトを添えて報告する	PMが修正要否や機能除外の判断を下すための材料を提供する
③対策の提案	精度が低い機能については、「今回はリリース対象から外す」や「ユーザーへの注意書きを追加する（運用でカバー）」といった現実的な解決策を提案する	PMの判断を支援する具体的な解決策を提示する

4. 実際に起きた修正例

問題点

検証データから算出した結果（再現率と適合率）

QA実施の結果、再現率の許容ラインを下回っているフィールドがありました。

• 選択フィールド: 63.5%
• テキストフィールド: 50.8%

適合率はすべてのフィールド型で99%を超えており優秀でしたが、再現率が低い状況でした。

これは、AIが一度指摘を出せばその指摘はほぼ正確（無駄な指摘がない）である一方で、指摘すべき事項の半分近くを見逃しているという状況です。

上記をPM・開発者へ共有しました。

修正方針

フィールド	採られた修正方針	理由
選択	ワークフローの設定で説明を詳細に記載する	ユーザーがワークフローの設定でAIに明確なルールを与えれば、モデル修正なしで精度向上が期待できると判断
テキスト	プロンプトの追加	ユーザーが説明に「誤字に気を付けて」と入力することは想定外のため、AI側で責任を持つ必要があると判断

再検証の結果

両フィールドとも許容ラインを超え、リリース可能な品質を達成しました。

フィールド	修正前 再現率	実施した修正	修正後 再現率	最終結果
選択	63.5%	運用：説明文を詳細化	96.5%	✅
テキスト	50.8%	開発：プロンプトを追加	77.1%	✅

5. データ収集・集計の効率化

データ作成や処理時間の計測方法には、効率化の余地があります。これらは現在、改善対応中です。

Postmanでのデータ収集

UI操作ではAIレビュー完了に時間がかかってしまうというボトルネックを回避するため、APIを直接操作してデータ作成・収集を効率化しました。

Geminiでのデータ集計

収集した大量のデータは、手動ではなくGeminiで処理しました。

1. 収集したデータをGeminiに投入し、必要なエラー情報を抽出する
2. Geminiから出力されたフィールド別のError/Warningの発生件数を受け取る
3. 出力結果をスプレッドシートに記録する

レビュー実行時間の計測手順

AI申請前レビューはレスポンスに時間がかかるため、結果取得は3秒ごとのポーリングに依存しています。 APIからは正確な実行時間を計測できなかったため、以下の方法でユーザー体験上の実行時間を算出しました。

1. UIでレビュー実行
2. レビュー完了まで待機
3. デベロッパーツールのネットワークタブでポーリング回数を確認
4. ポーリング回数 × 3秒 でレスポンスにかかる時間を算出

今後の取り組みと改善点

• データ準備の自動化

  • テスト開始までの準備時間を短縮し、新しい機能の検証を早く始められるようにする

• 評価プロセスの完全自動化

  • AIレビューの実行から、結果の取得、そして「見逃し」や「過剰指摘」の件数を数えて計算するところまでを、すべて自動で実行できる仕組みを作る

• テスト手法の標準化

  • 今回作成したAI機能のテスト手順や評価基準を、他のAI機能の開発や検証にも使えるように、標準的なルールとしてまとめる
  • チーム全体のAI機能の品質保証レベルを底上げする

おわりに

AI機能のテストは、「バグか仕様か」だけでなく、「この精度でユーザーは満足するか」という視点が求められます。

• 100%を目指さない: AIに完璧を求めず、許容できるラインを握っておく
• 何度も試す: 1回OKでも、次はダメかもしれない。複数回試して傾向を見る
• 数字で会話する: 「なんか精度悪い」ではなく、「再現率が低い」と伝えることで、具体的な対策（プロンプト修正など）につながる

この記事が、これからAI機能のQAに挑む方の参考になれば嬉しいです。

---

kickflowでは一緒に働いてくれる仲間を募集しています。 careers.kickflow.co.jp