生成AIの業務テストと評価表の作り方｜福島県の中小企業向け

生成AIを業務に取り入れる前に、実際に任せたい作業の入力例と、合格とする条件を用意して試します。通常の依頼だけでなく、情報が足りない依頼や資料が食い違う依頼も含め、人の確認・修正まで終える時間を記録してください。

この記事では、福島県の中小企業でAI導入を担当する経営者、総務担当者、現場責任者に向けて、表計算ソフトで作れる業務テストの評価表を紹介します。対象は文章の整理や下書き作成です。自動送信や基幹システムの更新まで行う仕組みでは、権限や接続先を含む別の検証が必要になります。

生成AIの業務テストは、任せる作業と合格条件から決める

「きれいな文章が出た」だけでは、その作業を業務に組み込めるか判断できません。たとえば依頼メモを一覧にするなら、文章の読みやすさに加え、品目・数量・期限が元のメモと一致しているかを確認します。

Salesforceの公式解説でも、AIエージェントのテストでは期待する情報や動作を評価し、用途に合わせて評価シートと合格基準を準備する考え方が示されています。Salesforce「AIエージェントのテスト観点と評価基準を整理しよう」

ここから紹介する表と例は、その製品の操作手順ではなく、当社が一般的な文章整理業務向けに提案する進め方です。最初に次の四つを決めておきましょう。

決めること	依頼メモを一覧にする場合の例
AIに任せる範囲	メモから品目・数量・希望日・不足情報を取り出す
合格に必要な内容	元の情報を保持し、書かれていない項目を未記載にする
重大な不合格	数量の書き換え、希望日の捏造、別の依頼の混同
人が行う作業	原文との照合、依頼者への確認、手配の承認

対象業務がまだ決まっていない場合は、AI導入支援に相談する前の要件整理シートで、困っている作業と任せる範囲を先に整理してください。

テストケースには通常・不足・矛盾・対象外を入れる

テストケースとは、「この入力に対して、どのように処理してほしいか」を一組にしたものです。担当者が正解を説明できる、短い架空のメモから始めると確認しやすくなります。

以下は練習用の架空例です。実在する依頼や、特定のAIで得られた結果ではありません。

ケース	入力例	期待する扱い
通常	備品Aを2個、希望日は10月8日	品目・数量・希望日をそのまま取り出す
情報不足	備品Aを追加したい	数量と希望日を未記載にする
矛盾	備品Aを2個。追記には3個とあるが、どちらが正しいか不明	2個と3個の両方を残し、確認が必要と示す
対象外	備品Aを使うイベントの企画書を作って	一覧化の対象外と示し、企画書作成へ勝手に進まない
複数の依頼	依頼1は備品Aを2個、依頼2は備品Bを4個	依頼ごとに行を分け、品目と数量を混ぜない

情報不足のケースでは、答えを埋めないことが合格です。すべての欄が埋まっている方を高く評価すると、推測で補った回答を採用してしまいます。

実際の業務では、日付の表記揺れ、否定文、途中の訂正、複数ページの表なども候補になります。福島県内に複数拠点がある会社なら、拠点ごとの依頼を取り違えないかというケースも追加できます。実在の拠点情報を使う必要はなく、架空の名称で構造を再現してください。

評価表には期待する結果と実際の出力を別々に残す

先に人が期待する扱いを書き、その後でAIを実行します。出力を見てから合格条件を作ると、出てきた回答に都合のよい採点になりやすいためです。

評価表の項目は、次を基本にします。

項目	記録する内容
ケースID・区分	T01／情報不足など
入力文・参照資料	使用した全文、資料の版や日付
期待する扱い	必須項目、残す条件、不明とする項目
実行条件	ツール名、表示されるモデル名、実行日、設定、プロンプトの版
実際の出力	修正する前の回答全文、または保存先
人による判定	合格／不合格／判定保留と、その理由
作業時間	入力準備、生成待ち、照合、修正に要した時間
確認者・次の対応	確認した担当者、直す箇所、再テスト日

モデル名が画面に表示されない場合は「表示なし」と記録し、推測で補いません。ファイルの読み込みや検索機能を使うなら、その有無も条件に含めます。同じ指示文でも、参照できる資料が違えば比較条件が変わるためです。

AIに表の作成を手伝わせる場合も、期待する結果と最終判定は担当者が確認します。生成したAI自身の「合格です」という説明だけを評価結果にしないでください。

合格率と重大な誤りを分けて、採用可否を判断する

仮に10ケース中9ケースで必要項目が合っていても、残りの1ケースで数量を勝手に変更したなら、平均点だけでは採用を決められません。次のように、影響の大きさを分けて記録する方法を勧めます。

• 重大な誤り：数字や条件の変更、依頼の混同、資料にない約束の追加。原因と対策を確認するまで、その用途への採用を保留する。
• 修正できる不備：表の列順、見出しの表記、長すぎる説明。修正時間を含めて使う価値があるか判断する。
• 適切な保留：情報不足や矛盾を示し、人に確認を求めた。入力条件に合っていれば合格として扱う。

「合格率」は、何を分母にした数値なのかも明記しましょう。合格8件、不合格1件、判定保留1件なら、保留を除いて割合をよく見せず、まず件数をそのまま報告します。

少数の架空例で全件合格しても、実務全体の正確さを保証するものではありません。試していない文書形式や例外は未検証として残し、利用範囲を広げる前にケースを追加します。

同じ条件で複数回試し、確認・修正までの時間を測る

初回の点検では、一つのケースを新しい会話で3回試すなど、同じ条件で繰り返す方法があります。この回数は始め方の一例であり、信頼性を保証する基準ではありません。失敗した出力も残し、うまくいった回だけを採用結果として扱わないようにします。

比較対象として、人が同種の作業を行う場合の所要時間も記録してください。AIを使う側では、入力用の整形や出力後の照合が増えることがあるため、生成時間だけを比べても業務への影響は分かりません。

比較する作業	計測の始点と終点
人が行う場合	元のメモを受け取り、確認済みの一覧を完成させるまで
AIを使う場合	元のメモの入力準備から、生成・照合・修正を終えるまで

同じ題材を繰り返すと、内容を覚えたことで作業時間が短くなる場合もあります。計測順や担当者を記録し、条件の違う数値をそのまま比較しないようにしましょう。

事前に担当者と責任者で、許容できる修正の種類と時間を決めます。確認負担が増えるなら、指示文を直すだけでなく、AIに任せる項目を減らす選択肢も検討してください。

改善用の入力と最終確認用の入力を分ける

同じ例だけで指示文を直し続けると、その例に合わせた改善か、ほかの入力にも役立つ改善かを区別できません。指示文の調整に使わない例を残しておき、最後に試します。

たとえば、数量不足の例で改善した後は、希望日が不足した別の例でも、不足を指摘できるかを確認します。改善後には、問題が出たケースだけでなく、以前合格したケースも再実行してください。指示を追加した影響で、元はできていた処理を崩していないかを見るためです。

社内へ配る指示文には、版、確認した業務、テスト日を添えます。保管と更新の方法は、社内プロンプト集の作り方で整理しています。

生成AIの業務テストでよくある質問

何件テストすれば業務に使えますか？

一律の件数では決められません。通常・不足・矛盾・対象外の入力を用意し、担当者が把握している例外が含まれるかを確認します。少数で始める場合は、試した範囲に用途を絞り、人の照合を残してください。

テストに実際の顧客データは必要ですか？

初回は、公開情報や架空のサンプルで進められます。実データが必要になったら、会社が入力を認めた情報と環境を確認します。氏名だけを消しても、非公開の取引条件や技術情報まで入力可能になるわけではありません。

ツールやプロンプトを変えたら、やり直しますか？

変更前後を比較できるよう、保存したケースで再テストします。ツールの更新、設定変更、参照資料の差し替え、出力の変化を再確認のきっかけとして決めておくと、担当者が迷わず対応できます。再現できない実行条件があれば、それも記録に残してください。

まず一つの業務で、合格条件を共有する

生成AIの業務テストは、入力例、期待する扱い、実際の出力を対応させ、人が採用可否を判断するために行います。重大な誤り、適切な保留、確認・修正時間を分けて見ると、どの条件まで任せるかを具体的に決められます。

まずは担当者が正解を確認できる文章整理を一つ選び、通常・不足・矛盾・対象外の例を作ってみてください。運用開始後の利用状況は、生成AI研修の効果測定シートで継続して振り返れます。

福島県で生成AI研修やAI導入支援を検討している方は、コミットメントのAI活用支援をご覧ください。任せたい作業と、間違えると困る条件を整理しておくと、相談時に検証する範囲を決めやすくなります。