生成AIの出力を確認するとき、「なんとなく良さそう」で通す場面が増える。 文章が自然で、画面もそれらしく見えるからだ。 しかし、自然な文章と、目的に合う出力は同じではない。
従来のプログラムなら、決まった入力に決まった結果を期待できる。 生成AIでは、同じ依頼でも表現や順序が揺れる。 だから評価では、唯一の正解を探すより先に、何を満たせば使えるのかを決める必要がある。
利用者が次に何をできればよいかを決める#
評価の起点は、モデルが正しい文章を出すことではない。 利用者が、出力を受けてどんな判断や操作をできればよいかである。
問い合わせの要約なら、担当者が原文を読み直さなくても優先順位を決められること。 記事の下書きなら、著者が事実確認と表現の修正に集中できること。 このように利用後の仕事を言葉にすると、見るべき項目が定まる。
評価基準は、最初から多くしない。 たとえば要約なら、重要な事実を落とさない、推測を事実のように書かない、次の担当者が行動を決められる、の三つでも始められる。
許容できない失敗を、先に書き出す#
出力の揺れはすべて欠陥ではない。 言い回しや段落の順番が変わっても、目的を果たせるなら問題にならないことが多い。
逆に、少数でも見過ごせない失敗がある。
- 存在しない事実、出典、約束を作る
- 個人情報や権限外の情報を出す
- 高い確信で不確かな判断を勧める
- 後続の処理が読めない形式で値を返す
これらを先に定義すると、レビュー担当者は文章の好みではなく、リスクの有無に集中できる。 レビュー力とは、出力を細かく直す能力だけではない。 止めるべき出力を、目的と責任から見分ける能力でもある。
代表的な入力を、変更に耐える資産にする#
テスト用の入力は、理想的な依頼だけで作らない。 短すぎる依頼、前提が矛盾する依頼、情報が古い依頼、複数の意味に読める依頼を混ぜる。 実運用で困るのは、きれいに整った入力より、こうした端のケースだからだ。
各ケースには、期待する文面を一字一句で固定する代わりに、満たすべき条件を書いておく。 「不足情報を質問する」「資料にない数字を断定しない」「分類値は定義済みの候補だけを返す」といった条件なら、モデルやプロンプトを変えた後も比較できる。
自動評価と人のレビューを分ける#
形式、必須項目、禁止語、参照できるデータの範囲は、自動で検査しやすい。 一方で、文脈に沿った優先順位、利用者が誤解しそうな表現、業務上の妥当性は、人のレビューが残る。
AIに評価を補助させることもできる。 ただし、その判定を唯一の合否にしない。 評価用のモデルも誤るため、判定理由と対象の出力を並べ、人が確認できる形にする。
評価は、出力を直すためではなく判断を残すためにある#
生成AIの機能は、モデル、プロンプト、参照データ、画面の導線が少しずつ変わる。 そのたびに「前より悪くなった気がする」と話し始めると、修正の方向が定まらない。
どのケースで、どの基準を満たさなかったのかを残せば、変更の影響を追える。 レビューは最後の防波堤ではなく、機能の責任範囲を育てる記録になる。 揺れる出力を扱うからこそ、評価の基準は人の頭の中ではなく、チームで見返せる場所に置きたい。
