AIアプリでは何をテストしますか？
期待どおり動くことに加え、誤入力、権限のない利用、通信エラー、AIの誤った出力を確認します。人が用意したサンプルデータと判断基準で、結果を記録します。
一回うまくいった。それだけでは分からないこと
会議メモを入れたら、担当者と期限の一覧が出てきた。思わず「できた」と言いたくなります。しかし、そのメモにはたまたま必要な情報が全部そろっていたのかもしれません。別のメモでも同じように使えるか、知らない人が情報を見られないかは、まだ分かりません。
テストは、AIや開発者を疑うためではなく、使ってよい条件を知るための仕事です。JIKABI AIでは、画面が動いたことと、会社で使うための確認が終わったことを分けて考えます。
作る前に、期待する結果を言葉にする
ここでは、会議メモからタスク一覧を作る架空のアプリを題材にします。「田中さんが金曜日までに資料を確認」と書かれたメモなら、担当・作業・期限が分かれて出る。「誰か確認して」だけなら、担当者を推測せず未定として出る。このように、入力と期待する結果を対にします。
AIにサンプルを作らせることはできますが、正解まで無条件に任せません。業務を知る人が、サンプルが現実的か、期待値が会社のルールと合うかを確認します。生成した入力と生成した正解が、同じ思い込みでそろってしまう場合があるからです。
正常・異常・権限を分けて確かめる
以下は検証用の例で、すべてのアプリに共通の合格条件ではありません。実際の利用条件に合わせて、期待する動作を先に決めます。
- 正常：担当と期限が明記されたメモを渡す。元の記述と一致するタスクが出るか。
- 情報不足：期限が書かれていないメモを渡す。勝手な日付ではなく、未定と返すか。
- 入力不備：空欄や上限を超える入力を渡す。分かる案内が出て、不要な処理を続けないか。
- 権限：権限のないテストユーザーから別の担当者のデータへアクセスする。取得も変更も拒否されるか。
- 障害：検証環境でAI接続の失敗を再現する。失敗を知らせ、再試行で重複登録しないか。
ボタンが見えないことと、アクセスできないことは違う
管理者ボタンを隠しても、データへの直接のアクセスまで防げているとは限りません。OWASPも、アクセスのたびに適切な権限を確認することを勧めています。画面の見え方と、サーバー側で許可・拒否する仕組みを分けて確認します。
こうしたテストは、自社が管理し、実施を許可した検証環境とテスト用アカウントで行います。他社サービスや第三者のアカウントへ勝手に試すものではありません。自分たちで確認できない範囲は、実装担当や専門家へ依頼します。
AIの精度は、一つの正解率にまとめすぎない
タスクが一件漏れることと、存在しない約束を作ることは、仕事への影響が違います。担当者の一致、期限の一致、タスクの漏れ、書かれていない情報の追加を分けて記録します。数値を出す場合も、何件のどんなデータで測ったかを添えます。
人が修正した時間も確認します。文章が自然でも、確認に長くかかれば実務での負担は残ります。同じ入力でも回答が変わることがあるので、重要な条件は繰り返して確かめます。正しく答えるだけでなく、分からないときに確認へ回せることも評価します。
直した後に、同じテストへ戻れるようにする
記録には、入力、期待値、実際の結果、判定、確認者、アプリや指示文の版を残します。不具合を見つけて直したら、その一件だけでなく、以前うまく動いていた代表的な入力も再確認します。変更で別の箇所を壊していないかを見るためです。
調整に使ったサンプルだけで評価すると、その例にだけ合うことがあります。別に残した確認用のサンプルでも試し、都合のよいデータだけを選ばないようにします。本番データを使う必要がある場合は、利用許可と情報の扱いを先に確認します。
合格は、業務の責任者と決める
すべてのテストが通っても、安全性や正確性が永遠に保証されるわけではありません。公開範囲、扱う情報、誤りの影響を見て、残る課題を受け入れられるかを人が判断します。高い機密性や外販の要件がある場合は、別の専門的な確認が必要です。
まずは正常、情報不足、権限違反の三種類について、入力と期待値を書いてみてください。アプリを作る前に書ければ、AIへの開発依頼そのものも具体的になります。
出典・参考情報
情報は最終更新時点の内容です。サービスの仕様・料金・利用条件は公式情報をご確認ください。