AIチャットボットを公開する前に何を試すか — 小さな会社の“テスト質問表”

「AIチャットボット、試しに聞いたら普通に答えた」——公開前の確認がそこで止まることがあります。

でも本当に困るのは、料金、個人情報、クレーム、古い資料のような少し面倒な質問に出会った時です。

では、小さな会社は公開前に、どんな質問を投げておけば安心しやすいのでしょうか。

「ちゃんと答えるか」だけを見ていませんか？

Anthropicの評価ドキュメントでは、LLMアプリの成功基準を先に決め、実際のタスクやエッジケースを含めて評価する考え方が示されています。OpenAIのevalsも、出力が指定した内容やスタイルを満たすかを見る仕組みです。

小さな会社に置き換えるなら、これは難しい採点システムの話ではありません。公開前に「何を正解とするか」を決め、わざと困る質問も混ぜて聞くという話です。

現場では、担当者が知っている質問だけを試すと、思ったより早く見落としが出ます。

テスト質問は、どの5つの箱に分ける？

Google Cloudの生成AI評価では、テスト駆動の評価やルーブリックの考え方が扱われています。小さな会社なら、採点表を5つの箱に分けるだけでも十分実務に近づきます。

30問ぴったりである必要はありません。最初は各箱に5〜6問ずつ入れます。合計25〜30問あれば、普通の質問だけで公開するより見落としに気づきやすくなります。

社内資料を読ませるなら「探せるか」も試していますか？

Amazon BedrockのKnowledge Basesでは、問い合わせ時に取得する結果数やメタデータフィルタを調整できます。これはBedrock固有の仕様ですが、社内資料を使うAIでは「答えの材料を探せているか」が重要だとわかります。

PromnyAIの仕様として検索件数を断定する必要はありません。見るべきは、質問に対してどの資料を参照してほしいか、古い資料を拾っていないか、根拠を出せるかです。

わざと困る質問を混ぜていますか？

NIST AI Risk Management Frameworkは、AIの設計、開発、利用、評価に信頼性の考慮を組み込むための枠組みです。OWASPのLLM Top 10も、生成AIアプリのリスクと緩和策を整理しています。

小さな会社の公開前チェックでは、難しい用語より「その場で答えない質問」を用意する方が役に立ちます。

採点は100点満点でなくてよい

公開前テストは、点数を細かく付けることが目的ではありません。公開してよいか、直すか、人に戻すかを分けられれば十分です。

たとえば30問のうち、料金の質問で2問ずれる。クレームで1問きつい言い方になる。その時点で、公開前に直す場所が見えます。

まとめ：公開前のテスト質問表で見ること

• check_circle「普通に答えるか」だけではなく、困る質問も混ぜます。
• check_circleよくある質問、答えない質問、人に渡す質問を分けます。
• check_circle社内資料を読ませる場合は、どの資料を探したかも見ます。
• check_circle採点はOK、要修正、人に戻すの3段階で始めます。
• check_circle公開後ではなく、公開前に質問表を作ると見落としに気づきやすくなります。

AIチャットボットの公開前に見るべきものは、AIの賢さだけではありません。会社として「ここまでは答える」「ここからは人が見る」を言葉にすることです。