スタッフがAI機能を頼る前に、どうテストすればよい？

試作品は、いくつかの質問にうまく答えます。次はスタッフに使ってもらいたいという話が出ています。了承する前に、スタッフが実際に任せる仕事をどう処理するのか、答えられない質問も含めて、提供元に見せてもらいましょう。

話し合いは具体的に進められます。仕事を一つ選び、使える結果とは何かを決め、その仕事を知る人と一緒に現実的な例への回答を確認します。そうすれば、リリースを判断する根拠ができます。

まず一つの仕事と、その限界を決める

承認された社内ガイドをもとに回答案を作り、スタッフが使う前に読む機能を想像してください。これは仮の例ですが、何を基準に受け入れるか考えやすくなります。

機能が使ってよい情報、対象者、出力するものを書き出します。この例では、その人が閲覧を許可されたガイドから回答案を作ります。回答の送信や記録の変更は、別の機能としてテストする必要があります。

次に、何を使える結果とするか決めます。回答案は質問に答え、承認済みの資料に沿い、答えを左右する条件を残し、根拠となる資料を示す必要があります。資料で答えられない場合は、そのことを伝えます。情報が足りないと明確に認めることも、成功といえます。

ルールを作り出す、答えを変える条件を落とす、誤ったガイドをもとに自信たっぷりに答える。どれも使えない回答です。結果を見る前に、こうした違いを決めておきましょう。そうしないと、流暢な答えに思わず納得してしまいます。

スタッフが実際に尋ねる質問を試す

回答案を作る例では、少なくとも次の状況を含めます。

• 一般的な質問。 ガイドに明確な答えがあります。回答案は正確に答え、適切な資料を示していますか？
• 曖昧な質問。 二つの手順が当てはまる可能性があります。機能は勝手に一方を選ばず、選択に必要な情報を尋ねますか？
• 資料がない場合。 承認済みのガイドに依頼内容が載っていません。機能は不足を伝え、人が判断できるようにしますか？

これらは出発点です。よくある依頼、情報不足、解釈の難しい表現、間違えたときの影響が大きいケースなど、実際の仕事の幅に合わせてテストを作ります。利用が認められた代表的なデータか、安全に用意した例を使い、未承認のサービスに機密記録を入力しないでください。

Microsoftの評価ガイドは、代表的なやり取りや難しいケースを使うことを勧めています。管理者にとって大切なのは、スタッフが助けを必要とする状況を例がカバーしているかです。一般的なモデルのベンチマークでは、自社のアプリについてその判断はできません。

業務を知る人に結果を見てもらう

その仕事に詳しい人に、決めた基準に沿って回答を確認してもらいます。なぜ使えるのか、間違いなのか、判断できないのかを説明できる人が必要です。判断が分かれる場合や、間違いの影響が大きい場合は、別の人にも確認してもらいましょう。

任意で使うNIST AIリスク管理フレームワークは、テストの記録、導入時に近い条件、関連する専門家の関与を支持しています。何を試し、誰が確認したかを尋ねる手がかりになりますが、この機能に共通の合格点を定めているわけではありません。

評価用の例の一部は、機能の改善に使う例と分けておきましょう。提供元がすべてのテスト質問に合わせて調整し続けると、慣れた質問にどれだけ答えられるかしか分かりません。別の例を使えば、調整に使っていない仕事への対応をより確かめられます。

自動採点は結果の整理に役立ちますが、その判断も確認が必要です。人が間違いを見落とすこともあれば、別のAIが採点を誤ることもあります。実際の回答と採点の理由を見せてもらいましょう。

平均点の裏にある失敗を見る

全体の点数は、バージョン同士の比較に役立ちます。それに加えて、重要な状況や間違いの種類ごとに結果を確認してください。一般的な質問にはうまく答えても、根拠資料がない質問では繰り返し回答を作り出すかもしれません。平均点だけでは、その用途について決めるべきことが見えなくなります。

どんな失敗が起きたか、影響はどれほどか、何がまだ不明かを記録します。予定している用途を妨げる失敗を決めましょう。許容できる誤りは仕事の内容と、間違いの後に何が起きるかによって変わります。どの企業にも当てはまる割合はありません。

機能が操作も行うなら、接続先のシステムで実際に何が起きたか確認します。たとえば記録を更新したと表示されたら、正しい記録が意図した値になっているか調べます。Anthropicが2026年1月に公開したAIエージェントの評価に関する説明は、ソフトウェアが操作を行うときに最終結果が重要な理由を述べています。「完了しました」という表示だけでは、成功した証拠になりません。

出力の品質は、受け入れ確認の一部です。セキュリティ、権限、プライバシー、その他の業務フローには、それぞれ適切な確認が必要です。回答の点数が高くても、それらが機能する証明にはなりません。

具体的なリリース判断をする

提供元に、仕事と機能の限界、テストケースと期待する結果、確認した人、重要な失敗、残る不確実性、テストしたバージョンを簡潔に記録してもらいます。モデル、指示文、参照資料、接続ソフトが結果に影響するなら、それらも記録します。どれかを変更したとき、どの確認をやり直すか決めておきましょう。

その証拠をもとに、次の三つから判断します。

• 限定利用を承認する。 決められた範囲の仕事なら、結果が利用を支えています。スタッフは、確認する時、使用を止める時、既存の手順に戻る時を把握しています。
• 修正して再テストする。 具体的な失敗を直す必要があります。再実行するケースと、修正の効果を確かめる別の例を決めます。
• リリースを保留する。 重要な失敗が解決していないか、予定する用途を支える証拠が足りません。

範囲を限った試験運用では、実際の仕事から証拠を増やせます。利用者、仕事、権限、確認方法、従来の手順への戻し方を事前に決め、問題を見守って必要なら停止する担当者を置きましょう。小規模な試験運用で良い結果が出ても、その範囲での利用を支えるだけで、全般的な信頼性を証明するものではありません。

受け入れの話し合いを終えるときには、スタッフが何を頼れるのか、どこで人の判断が必要か、何が再テストのきっかけになるかが分かっているはずです。業務向けのカスタムアプリケーションにAI機能を計画しているなら、実現したい仕事と、受け入れ前に必要な証拠についてご相談ください。