第29章 AI機能を設計し、評価する

AI を呼び出して結果を表示できても、業務で使えるとは限りません。AI 機能の設計では、平均的に賢く見えることより、対象業務で許容できる失敗、費用、待ち時間の範囲に収まり、問題時に人が止められることが重要です。

本章の「評価」は、AI が作った文章を確認する付録 E とは異なります。付録 E は調査や提案で AI 出力を利用する人の確認、本章は顧客へ提供する AI 機能そのものの品質判定を扱います。

29.1 最初に AI を使わない案と比べる

AI を使うことが依頼に含まれていても、解決策まで AI に固定しません。次を比較します。

AI を使う理由を、「流行しているから」ではなく、対象業務の入力の揺れ、判断の複雑さ、期待する改善で説明します。固定ルールで同じ価値を安く安全に出せるなら、AI は不要です。

29.2 AI機能の型を見分ける

型によって評価方法と危険が変わります。

• 生成: 文章、画像、コードを作る。事実性、禁止表現、修正量を見る。
• 分類: 問い合わせなどを決めた区分へ分ける。見逃しと誤検知を分けて測る。
• 抽出: 文書から氏名、金額、項目などを取り出す。欠落、取り違え、形式崩れを見る。
• 検索拡張生成（RAG、ラグ）: 検索した社内文書などを根拠に回答を生成する。検索できたかと、根拠どおり答えたかを分けて測る。
• 推薦: 利用者に候補を並べる。選択率だけでなく、偏り、多様性、不適切な推薦を見る。
• エージェント: AI が手順を選び、API（システム同士が情報や処理をやり取りする接続口）や画面を操作する。権限、確認、重複実行、取消しを重く見る。

一つの機能に複数の型が含まれる場合は、工程に分けます。社内文書への質問応答なら、検索、回答生成、根拠表示を別々に評価してから全体を試します。

29.3 業務、入力、出力、人の関与を一枚にする

モデルやプロンプトを選ぶ前に、次を書きます。

利用者と利用場面:
現在の作業と困りごと:
AIへ渡す入力:
AIが返す出力:
出力後に人がすること:
AIがしてはいけないこと:
正しい、役立つと判断する条件:
失敗した場合の影響:
人へ戻す条件:
記録するログ:

「人が確認する」と書くだけでは不十分です。誰が、いつ、何を見て、どの基準で承認し、確認できないときにどうするかを決めます。大量処理で全件確認できないなら、標本確認、危険な事例の自動振分け、利用範囲の縮小を設計します。

29.4 失敗を先に分類する

平均点だけでは重大な事故を隠します。対象業務に合わせ、少なくとも次を検討します。

• 根拠にない内容を事実のように作る
• 必要な情報を落とす、別人・別案件を混ぜる
• 禁止された個人情報や機密情報を出す
• 差別的、有害、法令・契約に反する表現を出す
• 指示文を文書中に埋めて AI の動作を変える攻撃を受ける
• 権限のないデータを検索・表示する
• 同じ処理を重複実行する、取消不能な操作を行う
• 自信のない出力を断定する
• 出力形式が壊れ、後続システムを停止させる
• 利用量増加で費用や待ち時間が上限を超える

影響の大きさと発生しやすさから重大度を決めます。平均品質が高くても、重大事故が一件あれば公開しない設計もあります。

29.5 固定した評価データを作る

評価データは、AI 機能へ入力し、期待する結果や採点基準と照合するための問題集です。開発中に都合のよい例だけ試すと、改善したか比較できません。

評価データには次を含めます。

• 日常的で件数の多い代表例
• 境界や例外に当たる難しい例
• 空欄、誤字、長文、複数言語など入力品質が悪い例
• 個人情報、機密、攻撃的指示を含む安全確認例
• 答えるべきでない、または人へ戻すべき例
• 事業上の損失が大きい重要例

実データを使う場合は、利用目的、権限、匿名化、保存期間を確認します。実データが使えない初期段階では、現場の専門家と架空例を作り、本番後に許可された実例へ更新します。

開発中に見る調整用データと、最後の判定にだけ使う確認用データを分けます。同じ問題を見ながらプロンプトを直し続けると、その問題だけに合う状態になるためです。

29.6 品質、費用、速度、安全性を同時に測る

指標は機能の型に合わせます。

平均値だけでなく、顧客区分、文書種類、入力長、言語など重要な区分ごとに見ます。全体では合格でも、特定顧客だけ著しく悪いことがあります。

品質向上のためモデルを大きくすると、費用や待ち時間が悪化します。単一の点数で隠さず、公開に必要な下限と上限をそれぞれ決めます。

29.7 人による評価を再現可能にする

生成文の良し悪しは、正解が一つでないため人が採点する場合があります。評価者ごとに感覚が変わらないよう、評価基準と具体例を作ります。

正確さ 0: 根拠と矛盾、1: 重要な不足、2: 軽微な不足、3: 根拠どおり
完全さ 0: 目的を満たさない、1: 主要項目欠落、2: 一部欠落、3: 必要項目を満たす
実用性 0: 使用不可、1: 大幅修正、2: 軽微修正、3: そのまま使用可能
安全性 合格・不合格: 禁止情報、危険な助言、権限違反がない

最初の一部は複数人で採点し、食い違う理由を話して基準を直します。別の AI に採点させる方法は、大量の一次評価を補助できますが、その採点 AI にも偏りや見落としがあります。人が採点した例との一致を確認し、重大な公開判断を AI の採点だけに任せません。

29.8 検索拡張生成では検索と回答を分けて調べる

検索拡張生成では、回答が悪い原因が、資料を見つけられなかったのか、見つけた資料を誤読したのかで対策が違います。

確認する項目は次のとおりです。

• 正しい資料が検索候補へ入ったか
• 文書を分ける単位が細かすぎたり大きすぎたりしないか
• 更新済み資料が検索対象になり、古い資料が除かれるか
• 利用者の権限を越えた資料が検索されないか
• 回答の各主張が表示された根拠に支えられているか
• 根拠がないときに「分からない」と返せるか

引用を表示するだけでは安全になりません。引用先が主張を本当に支えているかを評価します。

29.9 エージェントには最小権限と確認点を置く

外部システムを操作する AI には、会話だけする AI より厳しい制御が必要です。

• 読取り、下書き、実行の権限を分ける
• 削除、送信、購入、公開など戻しにくい操作の前に人へ確認する
• 同じ依頼が再送されても重複処理しない仕組みを持つ
• 操作対象、引数、実行者、時刻、結果を監査ログに残す
• 回数、金額、対象範囲、実行時間に上限を置く
• 失敗時に途中状態を確認し、取消しまたは補償処理を行えるようにする
• 外部文書中の命令を、正規の指示として実行しない

本番環境の広い権限を最初から渡さず、読取り専用、テスト環境、限定顧客、少額操作の順に広げます。

29.10 変更のたびに同じ評価を行う

AI 機能は、コードを変えなくても、モデル提供者の更新、検索文書の追加、プロンプト変更で品質が変わります。次を版として記録します。

• モデルと提供者
• システム指示とプロンプト
• 検索設定と参照資料の版
• 前処理・後処理コード
• 安全設定
• 評価データと採点基準

変更前後で固定評価を実行し、良くなった例と悪くなった例を確認します。品質、費用、速度、安全性のいずれかが公開条件を外れたら、以前の版へ戻すか、対象範囲を狭めます。

29.11 公開判定と公開後の監視をつなぐ

公開会議では、次を一枚にします。

対象利用者と提供範囲:
評価データと結果:
合格基準を満たした項目:
例外承認した項目と責任者:
既知の限界と利用者への説明:
人へ戻す条件:
監視する指標と警報値:
停止権限者と連絡先:
以前の版へ戻す手順:
次回評価日:

公開後は、利用率だけでなく、修正、棄却、苦情、重大な誤り、費用、待ち時間、人への切替を見ます。失敗例を評価データへ追加します。ただし、利用者の入力を無断で学習・評価へ転用しません。

考えてみる問い

検討中の AI 機能について、固定ルールや手作業より AI が適する理由を書いてください。次に、絶対に許容できない失敗を三つ、公開前に測る指標を四つ、公開を止める条件を一つ決めてください。

AI 機能の品質は、モデル名だけでは決まりません。対象業務、入力データ、検索、指示、人の確認、権限、運用を含む仕組み全体を、同じ条件で繰り返し測って初めて判断できます。実務では付録 I と付録 J を使います。