ローンチ前に AI アシスタントをテストする方法：自社のケースからテストセットを作り、合格ラインを定め、誰が承認するかを決める

AI アシスタントは、自社の文書をもとに質問に答えたり、顧客への返信の下書きを作ったり、書類からデータを取り出したりできる。デモはそれができることを示すが、自社のケースをどれくらいの頻度で、どのように間違えるのかは示さない。それを知るには、過去の実際のケースから作ったテストが必要だ。ケースごとに自社の人が正しい答えを書き、誤りの種類ごとにいくつまで許容するかを事前に取り決める。そのうえで、自社の側の指名された担当者が結果を承認する。

よくできた AI のデモは、なぜテストにならないのか

デモが見せるのは、売り手が選んだ質問と、それぞれ一度きりの答えだ。顧客や社員は、それとは別の質問を自分の言葉で尋ねるし、同じ質問でも、二度目には違う答えが返ってくることがある。

評価のベストプラクティスに関する OpenAI のガイドは、まさにこの点から始まる：「生成 AI にはばらつきがある。モデルは同じ入力から異なる出力を生み出すことがあり、そのため、従来のソフトウェアテストの手法は AI のアーキテクチャには不十分なものになる。」この記事の出典はすべて2026年11月4日に閲覧した。

このガイドは、モデルの答えのテストを、evaluations（評価）の略で evals と呼んでいる。ガイドが挙げる間違いの一つは、雰囲気にもとづく評価（vibe-based eval）だ：「『うまく動いているようだ』を評価の戦略にすること、あるいは出荷するまで evals をまったく実装せずに待つこと。」

米国国立標準技術研究所（NIST）は、2024年7月に、任意のガイダンスとして Generative AI Profile（生成 AI プロファイル）を公表した。このプロファイルは、生成 AI（generative AI）を GAI と略している。そこで提案されているアクションの一つには、こうある：「範囲が狭く、体系的でない、逸話的な評価から、GAI システムの性能や能力を推し量ることを避ける。」

テストセットは、デモにはできない仕事をする：実際のケースを並べ、ケースごとに期待する答えを付けた一覧で、変更のたびに同じ方法で採点される。

テストケースは、どこから集めるべきか

自社の業務から、アシスタントが実際に受けることになるのとおおよそ同じ割合で集める。Claude モデル向けに成功基準を定義し、評価を構築するための Anthropic のガイドには、こうある：「現実のタスクの分布を映す evals を設計する。」

OpenAI のガイドは、こう付け加えている：「テストデータに、典型的なケース、エッジケース、敵対的なケースが含まれるようにする。」エッジケースとは、まれな入力や扱いにくい入力のことだ。敵対的なケースは、アシスタントにおかしなふるまいをさせようとする。ケースは次のところから集める：

• 季節ものも入るように、まる1年分の、すべてのカテゴリーにわたる過去の質問とチケット
• スキャンした書類や変わったレイアウトのものも含め、アシスタントが読むことになるあらゆる種類の文書
• 二つの話題が混ざった質問や、記入漏れのある書類など、扱いにくいケース
• 自社の文書に答えがなく、そう伝えて人に引き継ぐのが正しい対応となる質問
• ほかの顧客のデータを求める依頼や、自社の規程が禁じている返金など、決して誤ってはならないケース
• チケットやアップロードされたファイルに隠された指示など、アシスタントをだまそうとする試み

テストセットに標準のサイズはない。ケースが10件しかなければ、一つの不合格でその種類のスコアが10パーセントポイント動いてしまうので、現実的な出発点は質問の種類ごとに数十件である。モデルは、ある言い回しを拒否しても別の言い回しは受け入れてしまうことがあるので、決して誤ってはならないケースは、一つひとつを複数の言い回しで書く。

セットには実際の顧客データが含まれるので、そのもとになったチケットや文書と同じアクセスルールを適用する。

期待する答えは誰が書き、そこには何を含めるのか

期待する答えを書くのは、アシスタントを作っている会社ではなく、自社の専門家である。期待する答え（エンジニアはこれをグラウンドトゥルースと呼ぶ）とは、注意深い社員なら受け入れる答えのことだ。その形は仕事によって変わる：

• 文書にもとづく答え：答えに含まれていなければならない事実、その事実の出どころである文書と節、そして言ってはならないこと。完成した模範解答は、正しい答えにはさまざまな言い方があるので、それほど役に立たない
• 返信の下書き：事実が正しいこと、規程に従っていること、規程を外れた約束をしていないことといった、短いチェックリスト
• 文書から取り出すデータ：自社のシステムが保存するとおりの形での、各フィールドの正しい値

文書に対する質問についての OpenAI の例は、テストデータの一部を「ドメインの専門家が作成した、質問に対するハードコードされた正解」から作っている。自社でいえば、そうした専門家とは、サポートのリーダーや規程の責任者である。

それぞれの答えは、二人目の専門家が確認する。注意深い二人の意見が分かれるなら、そのケースの背後にある規程がおそらく不明確であり、それを読むアシスタントも苦労する。Anthropic のガイドは、エッジケースの例の中に、そうしたケースを挙げている：「人間でさえ評価について合意に達するのが難しいような、曖昧なテストケース」。規程の責任者が決め、テストケースとあわせて文書も直す。

各ケースには、その質問の種類と、そのケースが拠りどころとする文書のバージョンを記録しておく。規程が変わったときに該当するケースを更新しておかないと、いまでは正しい答えを、セットが不合格にしてしまう。

合格ラインはどう決めるのか

合格ラインとは、ローンチの前に受け入れる最低の結果のことだ。アシスタント全体で一つの合格ラインでは隠れてしまうものが多すぎるので、合格ラインは質問の種類ごと、誤りの種類ごとに設ける。Anthropic のガイドはこう指摘している：「ほとんどのユースケースでは、いくつかの成功基準に沿った多次元的な評価が必要になる。」

不合格になったケースは、それぞれ一つの誤りの種類に振り分ける：

• 誤った事実：答えが誤ったことを述べている。NIST のプロファイルは、これを作話（confabulation）と呼んでいる：「自信ありげに述べられているが、誤っている、または虚偽である内容（俗に『ハルシネーション』や『でっち上げ』と呼ばれる）を生成し、それによってユーザーを誤解させたり欺いたりしうること。」
• 答えの欠落：文書には答えがあったのに、アシスタントがわからないと答えたか、重要な事実を抜かした
• 誤った出典：答えが、その内容を裏付けない文書や、古いバージョンの文書を出典として挙げている
• 安全でない答え：決して誤ってはならないケースで誤った
• 形式と口調：事実は正しいが、返信がそっけなさすぎるか、形式が間違っている

これらの誤りがもたらす損失は同じではない。答えが欠けていても、たいていは人がそのケースを引き取って終わる。誤った事実は正しく見える形で顧客に届き、誰も気づかないかもしれない。そのため、誤った事実には答えの欠落より厳しい合格ラインを設け、口調の合格ラインは最も緩やかにする。

決して誤ってはならないケースは、すべて合格しなければならない。一つでも不合格があれば、原因を直してセット全体が再び合格するまで、ローンチは止まる。

営業時間の間違いは料金の間違いより損失が小さいように、質問の種類によっても損失は違う。各合格ラインは、その誤りが自社にもたらす損失と、いまのチームが同じケースをどれくらいの頻度で間違えているかをもとに決める。合格ラインは最初の実行の前に書き留めておき、誰も結果に合わせて調整できないようにする。

アシスタントの答えは、誰が、あるいは何が採点するのか

文書から取り出したデータは、コードで採点できる：各フィールドは、期待する値と一致するか、しないかのどちらかである。自由記述の答えや下書きには判断が必要で、それを担うのは、人か、チェックリストにもとづいて動く二つ目の言語モデルである。

Anthropic のガイドは、人による採点を「最も柔軟で品質も高いが、遅く、費用がかかる。可能なら避ける。」と評している。モデルによる採点については「速く柔軟で、規模を広げやすく、複雑な判断にも向いている」としたうえで、こう助言している：「まず信頼性を確かめるためにテストし、それから規模を広げる。」

採点役として使うモデルには、知られている癖がある。OpenAI のガイドは、課題として「位置バイアス（回答の順番）、冗長性バイアス（長い回答を好む）」を挙げている。つまり、答えの並び順が判定を左右することがあり、長い答えが長さだけで勝つこともある。ガイドが挙げるヒントには、こうある：「人のフィードバックを使って、自動採点を較正する。」実際には、モデルも採点するサンプルを自社の専門家が採点し、両者の判定が食い違うところでチェックリストを直す。

下書きには、ブラインドテストが役に立つ。同じチケットに対するアシスタントの下書きと社員の返信を混ぜ、どちらがどちらかを知らせずに、レビュー担当者に採点してもらう。OpenAI のガイドは、人による採点の一例として「無作為化したブラインドテスト」を挙げている。

期待する答えにはそれぞれ出典が記されているので、検索（retrieval）、つまりモデルが読む断片を見つけ出す段階も確認できる。検索が正しい断片をそもそも見つけていなかったのなら、直すべきはモデルではなく検索だ。NIST のプロファイルは、これに関連する確認を提案している：「導入前のリスク測定と継続的な監視の活動において、GAI システムの出力に含まれる出典と引用を確認し、検証する。」

各ケースは何度か実行し、重要な質問は複数の言い回しで尋ねる。Anthropic のガイドは、一貫性を独立した基準として扱っている：「ユーザーが同じ質問を2回したとき、意味的に似た答えが返ってくることはどれほど重要か。」意味的に似ているとは、言葉は違っても、答えが同じことを言っているということだ。

テストセットは、いつもう一度実行するのか

変更のたびに、その変更が顧客に届く前に実行する。変更とは、新しいモデルのバージョン、編集した文書、新しい検索の設定、あるいは新しいプロンプト（モデルが従う書面の指示）のことだ。OpenAI のガイドは、これを独立したステップにしている：「変更のたびに evals を実行するよう、継続的評価（CE）を設定する」。

実行のたびに、リグレッション、つまり変更の前には合格していたのに変更の後で不合格になるケースを探す。平均が上がっていても、ある種類の質問では結果が崩れていることがあるので、種類ごとに見る。変更を本番に出すのは、次の場合に限る：

• 決して誤ってはならないケースが、一つも不合格にならない
• どの種類の質問も、その合格ラインを下回らない
• 新たに不合格になったケースをすべて人が読み、その原因を把握している

すべての実行の結果を、テストしたモデル、プロンプト、文書のバージョンとともに保存しておく。

プロバイダーもまた、自らのスケジュールでモデルの提供を終える。OpenAI の廃止（deprecations）のページは、一般提供されているモデルについて、安全性やコンプライアンス上の懸念からより早いスケジュールが必要な場合を除き、少なくとも6か月前に通知するとしている。プレビュー版のモデルは、はるかに短い予告で提供が終わることがある。Anthropic のページは、一般公開されたモデルについては少なくとも60日前に通知するとしたうえで、こう警告している：「提供終了日を過ぎたモデルへのリクエストは失敗する。」

その予告期間が、後継のモデルでセットを実行し、不合格になったところを直し、改めて承認するための猶予になる。最初からそのための計画を立て、予算を組んでおく。

ローンチの後は何を確認するのか

本番のトラフィックには誰も考えつかなかったケースが含まれるので、毎週、専門家が、実際の答えと下書きから無作為に選んだサンプルを、同じチェックリストで採点する。これは、すべての答えではなく、サンプルに対する人のレビューである。

2023年1月に出た任意のガイダンスである NIST の AI Risk Management Framework（AI リスクマネジメントフレームワーク）には、こうある：「AI システムは、導入の前にテストされ、運用中も定期的にテストされるべきである。」NIST によれば、改訂版の作成が進んでいる。

社員と顧客が良くない答えを簡単に報告できるようにし、誤りだと確認された答えは、一つずつ新しいテストケースにする。OpenAI のヒントの一つには、こうある：「開発しながらログを取り、そのログから良い評価ケースを掘り起こせるようにする。」

ローンチを承認するのは誰で、何を根拠にするのか

承認するのは、その業務の責任者である：たとえばサポート用のアシスタントなら、サポート部門の責任者だ。決して誤ってはならないケースについては、コンプライアンス部門か法務部門が承認する。開発会社は結果を提示するが、自らの仕事を承認することはない。

NIST のフレームワークは、評価について同様の役割の分離を示している：「そのシステムの第一線の開発者を務めなかった社内の専門家、および／または独立した評価者が、定期的な評価と更新に関与する。」続いて、フレームワークのうち Manage（管理）と呼ばれる部分は、AI システムについての判断、つまり「その開発または導入を進めるべきかどうか」の判断から始まる。

その判断の根拠となる資料一式には、次のことが示されているべきだ：

• セットをどう作ったのか、質問の種類ごとの件数、答えを書いたのは誰か
• テストしたバージョン：モデル、プロンプト、文書、検索の設定
• 事前に合意した合格ラインに照らした、質問の種類ごと、誤りの種類ごとの結果
• 決して誤ってはならないケースのすべてと、その結果
• 不合格になったケースの一つひとつと、人が目を通したうえでの説明
• 同じケースでの、自社のチームの結果
• アシスタントが扱わないもの、そしてローンチ後に毎週のサンプルを誰がレビューするのか

承認は部分的でもよい。合格した種類の質問についてはアシスタントを本番に出し、残りは、それらも合格するまで人に回す。

テストセットは誰のものか

ケース、期待する答え、チェックリスト、スクリプト、結果の履歴は、自社が所有すべきだ。これらを合わせたものが、良い答えとは何かを自社が書面で定義したものになる。それがあれば、あとで使うどのモデルやベンダーにも、同じ基準を課すことができる。

ベンダーのツールも提供を終えることがあるので、それらは自社が管理するストレージに保管する。OpenAI の廃止（deprecations）のページによれば、OpenAI は2026年6月3日に、Evals プラットフォームを使う開発者に、この製品を廃止する予定であることを通知した。同じページは、既存の evals が読み取り専用になる日を2026年10月31日、ダッシュボードと API の停止予定日を2026年11月30日としている。

自社の側でセットの責任者を決め、ケースを追加したり、規程が変わったときに答えを更新したりする時間を確保しておく。

ベンダーや、アシスタントの構築を任せる会社に何を聞くべきか

ベンダーが精度の数字を示したら、何で測ったのかを尋ねる。NIST のプロファイルは、こう提案している：「モデルの能力についての主張は、実証的に検証された方法で評価する。」そのうえで、候補に挙がっているすべてのベンダーと会社に、次の質問をする：

• 自社のケースと、自社の人が書いた期待する答えでテストするのか
• テストセットのうち、どの部分を、最終の実行まで見ないでおくのか
• 質問の種類ごと、誤りの種類ごとに、どんな合格ラインを提案するのか。それはなぜか
• 自由記述をどう採点するのか。採点に使うモデルが人の採点と合っているかを、どう確かめたのか
• 変更のたびに、そちらの手を借りずに、自社だけでセット全体を再実行できるのか
• モデルの提供元がそのモデルの提供を終えたとき、再テストの費用は誰が払うのか
• 最後に、ケース、チェックリスト、スクリプト、結果の履歴を受け取れるのか

amBrain はどこに位置づけられるか

このブログを発行しているのは amBrain である。自社のプロダクトについて、amBrain はこう述べている：「自社プロダクトのshyash.aiは、会社の事実を集めた一つの共有メモリをもとに、調査、執筆、確認、計測を行うAIエージェントで動きます。配信されるものはすべて担当者が承認します。」

言語モデルを使った顧客の仕事について、amBrain はこう述べている：「私たちは、顧客の FinTech 環境の境界内で LLM の統合を本番稼働させた:ブローカーや取引施設から届く非構造化の通知 ― コーポレートアクション、銘柄や証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化された記録にするものだ。」

この記事は事例紹介ではなく、その一文を超えて顧客のための仕事について述べてはいないし、その一文も、プロジェクトがどうテストされたかについては何も述べていない。この記事は、上で説明したテストセット、合格ライン、承認の手順を amBrain が作ったとは主張しておらず、shyash.ai がどうテストされているかも述べていない。例は一般的なものであり、amBrain の仕事から取ったものではない。

ここで名前を挙げた組織は、それぞれが公開しているページから引用したものである。この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張せず、amBrain の価格や期間も示さない。

amBrain は2019年からソフトウェアを作っている。顧客との仕事の進め方については、こう述べている:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」署名の前に、そのコンポーネントを名前で列挙した一覧を求めること。

この記事は法的助言でもない。顧客のデータから作ったテストセットにプライバシー法がどう適用されるかは、弁護士に尋ねる。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をすること。