第5章 評価と運用

学習目標

• 測定可能な成功基準を定め、実際の分布と境界事例を含む評価セットを作る。
• 基準ごとに適切な採点方法を選び、LLM採点器を人手による採点と照合して補正する。
• モデルのバージョンを固定し、変更前の回帰評価と段階的な移行手順を設計する。
• 障害調査に必要なログとトレース情報を残しつつ、個人情報を最小限にする。
• 運用上の問いから、指標、平常範囲、アラート、担当者の対応を定義する。

はじめに

ベンダーが、より速く安い新モデルを発表した日、ある会社の経営陣は翌週の移行を指示しました。開発チームは代表的な質問10件を試し、答えは「同じくらいよい」と判断しました。移行2週間後、サポート窓口に苦情が集中しました。まれな複合的問い合わせで、新モデルが重要な条件を1つ落とすことが多く、旧モデル向けに設定したパラメータも、新モデルでは警告なしで無視されていました。10件の質問では見えない問題でした。

LLMの機能は、本番に入っても変わり続けます。モデルは確率的に動き、ベンダーは新モデルを出して旧モデルを廃止し、ユーザーの入力も時とともに変わります。本章は「うまく動いていそう」という感覚ではなく、数値で判断する方法を扱います。成功基準と評価セット、採点方法と採点器の補正、結果の解釈、バージョン固定と変更手順、ログとトレース、個人情報、運用指標、機能別のコスト管理の順で進めます。

重要な概念

運用は計器飛行です

雲の中を飛ぶ操縦士は、窓の外ではなく計器盤を見ます。感覚は惑わされやすく、計器は決まったものを正直に示すからです。LLMの機能も同様です。数件の答えを読んで下す判断は選択バイアスに左右され、まれな失敗を見逃します。運用の計器盤は2種類あります。変更前に実行するオフライン評価と、運用中に見続ける指標です。両者は、同じ成功基準から出発して初めて比較できます。

成功基準から決めます

Anthropicは、よい成功基準の条件として、具体的、測定可能、達成可能、目的に関連していることを挙げます。「性能がよい」ではなく「問い合わせ分類の正解率」のように対象を絞り、定量指標や明確な尺度で測ります。多くの機能では、複数の側面を同時に見る必要があります。

基準ごとに合格ラインを事前に書きます。結果を見た後で決めると、望む結論に数値を合わせてしまいます。

評価セットを作ります

評価セットは、本番機能の回帰テストです。固定した入力、期待結果（または採点基準）、採点方法の組です。

1. 実際の分布を反映する。 運用ログから標本を抽出し、業務の種類、長さ、言語の比率を合わせます。個人情報は後述の方法で事前に処理します。
2. 境界事例を含める。 Anthropicは、無関係または存在しない入力、長すぎる入力、有害な入力、曖昧な入力を例示しています。さらに、自分たちの業務の高リスク区分（高額案件、危機の兆候がある相談）を加えます。
3. 失敗のコストで重み付けする。 まれでも被害が大きい区分は標本を増やし、別集計します。
4. 開発用と検証用を分ける。 プロンプト修正時に繰り返し見る入力と、最終判断にだけ使う入力を分け、評価セットへの過適合を防ぎます。
5. バージョンを管理する。 入力、期待結果、採点コードをリポジトリにまとめて置き、変更のたびに記録します。

Anthropicは、人が念入りに採点した少数の問題より、自動採点できる多数の問題を勧めています。規模があってこそ、小さな回帰も見えます。

採点方法を選びます

採点は、速く、信頼でき、規模を拡大できる方法から選びます。Anthropicは次のように整理しています。

同じドキュメントは、基準ごとの指標も例示しています。正解との完全一致（分類）、文の埋め込み類似度（類似質問への回答の一貫性）、ROUGE-L（模範要約のあるセットで重要情報を捉えたか）、LLMの1～5点尺度（口調）、LLMの二値判定（個人情報の有無）です。基準1つに方法1つを対応させると、どの側面が悪化したかすぐにわかります。

LLM採点器を補正します

LLM採点器は便利ですが、それ自体がモデルなので、誤りとバイアスがあります。使用前に補正します。

1. 採点基準表（ルーブリック）を具体的に書きます。「最初の文に対応予定がなければ不合格」など、判定条件を記します。
2. 出力を絞ります。「合格／不合格」や1～5点など、決まった値だけを出すようにします。記述式の評価は大量比較しにくいためです。
3. 得点を出す前に推論させます。Anthropicは、思考機能を有効にした採点モデルを使うと、複雑な判断で採点性能が向上すると説明しています。
4. 生成モデルとは別のモデルで採点します。Anthropicのサンプルコードでも、これを推奨事項として挙げています。
5. 人手による採点標本と照合します。50～100件を人が採点し、一致率を測ります。合格・不合格が偏るセットなら、偶然の一致を補正する指標（例：コーエンのカッパ）やクラス別の適合率・再現率も見ます。基準未達ならルーブリックを修正します。
6. 既知のバイアスを点検します。長い答えを高く評価したり、2つを比較すると先の答えを好んだりする傾向がないか、順序を替えて確かめます。
7. 採点モデルとルーブリックのバージョンを固定します。採点器が変われば、得点の意味も変わります。

結果の解釈：変動と区分

評価結果を読む際、次の3点を見落としがちです。

• 変動。 同じ入力でも実行ごとに結果が異なり得ます（第1章）。100件の入力では1件が1パーセントポイントです。1～2ポイントの差は偶然かもしれないので、同じセットを複数回実行し、まず変動幅を測ります。
• 対応のある比較。 2設定の平均を別々に比べるより、同じ入力の結果を照合し、新設定が勝った・負けた事例を数えます。負けた事例を読むと原因が見えます。
• 区分。 平均が上がっても重要な区分が悪化することがあります。業務の種類、長さ、高リスクかどうかで別集計し、高リスク区分には別の合格ラインを設けます。

モデルのバージョンを固定します

本番アプリは特定のモデルバージョンに固定します。OpenAIは、動作の一貫性を保つため、特定のモデルスナップショットへの固定を勧めています。Anthropicのモデル一覧によると、4.6世代以降は日付のないIDも含め、すべてのClaudeモデルIDが固定スナップショットです。それ以前のモデルの別名は、日付付きIDを指す便宜的な名前です。モデルごとに廃止時期（「この日より前には廃止しない」）が公表されるため、固定は永遠の保証ではなく、変更を計画する時間を確保する仕組みです。

モデルIDだけを固定しても、結果の変化は説明できません。再現できる設定の組として管理します。

モデル変更前の回帰評価

変更は「よく見える」ではなく、事前に決めた基準を超えるかで判断します。

1. 基準を先に書く。 全体と高リスク区分の合格ライン、レイテンシ・コストの上限、中止条件と責任者を定める。
2. 同じ評価セットで現設定と候補を比較する。 検証用セットを使い、対応のある比較で負けた事例を読む。
3. パラメータを再調整する。 以前の設定をそのまま移さない。推論の強度を評価セットで測り直し、新モデルが拒否・無視する設定（サンプリングパラメータ、プリフィル、ツール選択の強制）を探して削除する。トークン数も新モデルで数え直す。
4. シャドー実行する。 本番トラフィックの一部を候補にも送るが、結果はユーザーに見せず比較だけに使う。変更操作を行うツールは実行しない。
5. 段階的に移行する。 一部のトラフィックから移し、指標を監視する。中止条件に達したら即座に戻す。
6. 記録を残す。 比較結果、決定、設定の組を保存し、次回の基準にする。評価をデプロイパイプラインに組み込み、合格基準に達しなければデプロイを阻止する品質ゲートとして使えば、プロンプト修正時も同じ手順を守れる。

ログとトレース

障害調査では、特定のリクエストを再び見つけられる必要があります。Claude APIは、すべての応答に一意のrequest-idヘッダーを付け、エラー本文にもrequest_idを含めます。PythonとTypeScriptのSDKでは応答オブジェクトの_request_idから読めます。ベンダーへの問い合わせ時に、このIDが必要です。

1件のユーザー要求が複数のモデル呼び出しやツール実行につながる場合、呼び出し別のログだけでは流れが見えません。業務1件にトレースID（trace ID）を付け、モデル呼び出しとツール実行をそれぞれ子スパン（span）として記録します。OpenTelemetryなどの分散トレーシング標準と生成AI向け規約を使うと、ツール間で形式を合わせやすくなります。

プロンプトと応答の原文は、既定では残しません。必要な場合は、短い保存期間、アクセス制御、マスキングもあわせて決めます。

個人情報を扱います

個人情報はユーザー入力から始まり、ベンダーへの送信、ログ、評価セット、バッチファイル、キャッシュへと複製されます。名前1つを隠すだけでは不十分で、流れ全体を管理する必要があります。

法律の原則。 韓国の「個人情報保護法」（2026年9月11日施行）第3条は、処理目的に必要な範囲で最小限の個人情報だけを収集し、プライバシー侵害を最小化し、匿名化で目的を達成できれば匿名で、それができなければ仮名で処理するよう定めています。第2条は仮名処理を、個人情報の一部を削除・置換し、追加情報なしでは特定の個人を識別できなくする処理と定義します。健康情報などの機微情報は、第23条により、別途の同意など例外に該当する場合だけ処理できます。第26条は個人情報の処理委託を文書で行い、委託業務と受託者を公開するよう定め、第28条の8は国外への提供・処理委託・保存には法定要件のいずれかを満たすよう定めます。別途の同意が代表例であり、契約履行に必要な処理委託・保存は、移転事項をプライバシーポリシーで公開するか通知する方法もあります（第1項第3号）。第29条は内部管理計画やアクセス記録の保存など、安全措置を求めます。実際の適用は個人情報担当者・法務と確認します。

ベンダー側の保存。 方針はベンダーと契約ごとに異なるため、文書で確認します。

ユーザー識別子。 不正利用の検知のためにユーザー識別子を送る場合は、名前などを直接表さない識別値（不透明な値）を使います。Anthropicはmetadata.user_idに名前、メールアドレス、電話番号を入れずUUIDかハッシュを、OpenAIはユーザー名やメールアドレスをハッシュ化したsafety_identifierを勧めています。ポリシー違反時に、組織全体でなく該当ユーザーを追跡できるようにします。

運用指標を定義します

指標は、集めるだけでは障害後に開く記録帳になります。運用上の問いから、指標、平常範囲、アラート、担当者の対応を1行にまとめます。

技術指標（エラー率、レイテンシ）と業務指標（自動処理率、人の修正率）を併用します。応答がすべて200で速くても、人が毎回書き直すなら機能は失敗です。

機能別にコストと上限を分けます

複数の機能が1アカウントを共有すると、1機能の暴走がほかを止め、請求書だけでは原因がわかりません。ベンダーの分離単位を使います。Anthropicはワークスペースごとに支出上限とレート制限を、組織の上限より低く設定できます（既定のワークスペースには設定できず、組織の上限は常に適用されます）。応答のanthropic-workspace-idヘッダーで、どのワークスペースに計上されたか確認できます。OpenAIは組織とプロジェクト単位でレート制限を設けます。ログの機能・顧客タグも加えると、機能別、顧客企業別の原価を計算できます。

さらに深く

評価ツールに縛られない方法

評価データと採点基準は会社の資産ですが、特定のプラットフォーム内だけに置くと、その寿命に縛られます。実例があります。OpenAIによると、OpenAI Evalsプラットフォームは2026年10月31日から既存ユーザー向けに読み取り専用となり、11月30日に終了予定です。また、ダッシュボードの再利用可能なプロンプトオブジェクトもサポートを終了し、本番のプロンプトはアプリケーションコードに保存するよう勧めています。

この教訓は、ベンダーを問いません。評価入力、期待結果、採点コードとルーブリック、プロンプト、設定の組をリポジトリでバージョン管理し、評価ランナーはベンダーのアダプターだけ替えれば動くようにします。マネージド評価ツールは実行と可視化に使い、原本はリポジトリに置きます。そうすれば、モデル変更の日にも、前後を同じ基準で比較した記録を途切れず残せます。

フィードバックを評価セットに戻す循環

運用で見つかった失敗を次の評価セットの問題にして初めて、同じ失敗の繰り返しを防げます。

1. 信号を集める。 明示的なフィードバック（高評価・低評価、報告）と、暗黙の信号（回答の再生成、担当者が案の大半を修正、すぐ画面を閉じる）を記録する。
2. 分類する。 失敗事例を原因別（事実誤認、形式、口調、ツールの誤用）に分ける。
3. 評価用のテストケースを作成する。 個人情報を処理し、期待結果を付けて評価セットに加え、バージョンを上げる。
4. 定期的に実行する。 設定を変えなくても定期評価すれば、入力分布の変化や予想外の動作変化を早く検知できる。

実務の場面

海の恵み福祉財団：平均は上がったのに見落としが増えました

社会福祉法人「海の恵み福祉財団」は、相談員が書く相談記録を要約し、危機の兆候（自傷への言及、虐待の疑い、差し迫った生活困窮）を表示する機能を運用します。コスト削減のため安いモデルへの変更を検討し、情報システム担当のヨムさんが回帰評価を担当しました。

評価セットは、過去半年の記録から抽出した320件でした。仮名処理を施し、危機の兆候がある70件を意図的に多く含めました。要約の品質はLLM採点器が1～5点で採点し、危機の兆候は社会福祉士が付けた正解とコードで比較しました。採点器には候補と別のモデルを使い、社会福祉士2名が採点した60件と照合し、一致率0.86を確認してから使いました。

結果は分かれました。要約の平均は4.1から4.3点に上がりましたが、危機の兆候の再現率は96%から88%へ下がりました。対応のある比較で見落とした事例を読むと、新モデルは婉曲な表現（「最近はすべてを投げ出したい」）をよく見逃していました。事前に決めた高リスク区分の合格ラインは95%でした。

ヨムさんは全面変更を保留し、2経路を提案しました。危機の兆候の判定は旧モデルに残し、要約生成だけ新モデルへ移します。さらに、見落とした表現の種類を評価セットに加え、次の候補評価に使います。平均だけで変更する意見も、採点器の得点だけで判断する意見も却下されました。部分移行でコストは35%減り、危機の兆候の再現率は維持できました。

きれい洗濯：集荷メモに書かれた玄関の暗証番号

洗濯物集荷アプリ「きれい洗濯」は、顧客の集荷メモを要約して配達員に渡し、依頼の種類を分類します。セキュリティ点検で問題が発覚しました。顧客が玄関の暗証番号や連絡先をメモに書き、その原文がアプリケーションログに90日、評価セットのCSVに無期限で残っていました。評価セットは外部の品質確認業者とも共有されていました。

個人情報担当のハさんと開発リードのキさんは、まずデータフロー図を描きました。メモはアプリ→注文DB→モデルAPI→ログ・評価セット・週次バッチファイルと複製されていました。対応は次のとおりです。

1. 入力段階でマスキングします。モデルに送る前に電話番号や暗証番号らしい数字列をプレースホルダーに置き換え、要約にもそのまま残っているか検査します。配達員アプリでは、権限のある配達員にだけ注文DBの原文を見せます。
2. ログは原文でなくメタデータだけにします。トレースID、ベンダーのリクエストID、モデルID、トークン数、分類結果、検証結果を残します。
3. 評価セットを仮名処理した標本で作り直し、保存期限を決めます。既存CSVと共有コピーを回収・削除し、個人情報のパターンが評価セットにあれば失敗する検査をCIに加えます。
4. ベンダー側の設定と契約を確認します。会話状態の保存を無効にし、プライバシーポリシーの委託事項を更新し、国外移転に当たるか法務と検討します。

システムプロンプトに「個人情報を出力しない」と加える案は、入力がログや評価セットに複製される問題を解決しないため却下しました。ログをすべて無効にする案は、障害調査が不可能になるため不採用にしました。1か月後の再点検で、個人情報の原文が残るコピーは運用DBだけになっていました。

間違えやすいポイント

• 最新モデルを指す別名なら自動で改善します。 未検証で動作が変わり得ます。本番は固定バージョンで運用し、変更は評価で判断します。
• バージョンを固定すれば永久に同じモデルを使えます。 廃止予定があります。固定は変更計画のための時間を確保する仕組みです。
• 代表的な質問数件で十分です。 まれな高リスク事例や境界事例の回帰を見逃します。分布を反映した固定セットが必要です。
• 平均が上がれば変更できます。 重要な区分が悪化することがあります。区分ごとに別の合格ラインを設けます。
• LLM採点器はそのまま信頼できます。 人手による採点標本と照合して補正し、バイアスとバージョンを管理します。
• デバッグのため原文をすべて長期保存します。 個人情報のリスクが増します。メタデータを中心に残し、原文は必要な範囲・期間だけ保存します。
• ベンダーが学習に使わないので個人情報の問題はありません。 保存、不正利用監視、委託、国外移転、自分たちのログや評価セットは別の問題です。

ひと目でわかるまとめ

• 成功基準：具体的・測定可能・達成可能・関連性。合格ラインは結果を見る前に定める。
• 評価セット：実際の分布＋境界事例＋高リスク区分の重み付け、開発用・検証用の分離、リポジトリでバージョン管理。
• 採点：コード→LLM→人の順で選び、LLM採点器は人の標本と照合して補正する。
• 解釈：変動幅の測定、対応のある比較、区分ごとの集計。
• バージョン：スナップショット固定＋設定の組。Anthropicは4.6世代以降、全IDが固定スナップショット。
• 変更：基準を先に→同じセットで比較→パラメータ再調整→シャドー実行→段階的移行→記録。
• ログ：トレースID、ベンダーのリクエストID、設定バージョン、使用量、停止理由。原文は既定で残さない。
• 個人情報：最小収集と仮名処理、ベンダーの保存方針確認、委託・国外移転の検討、不透明なユーザー識別子。
• 指標：問い→指標（分母）→平常範囲→アラート→担当者の対応。業務指標もあわせて使う。

公式ドキュメントで確認する

• Anthropic — Define success criteria and build evaluations：成功基準、評価設計の原則、採点方法、LLM採点の要点を読む。
• Anthropic — Models overview：モデルIDとスナップショット、廃止時期、Models APIを確認する。
• Anthropic — API and data retention：ZDRの範囲と機能ごとの適用を確認する。
• OpenAI — Data controls in the OpenAI platform：学習利用、保存期間、ZDR、データ保存地域を読む。
• 韓国国家法令情報センター — 個人情報保護法：第2条、第3条、第23条、第26条、第28条の8、第29条を読む。

セルフチェック

5-1. よい成功基準の4条件を挙げ、「回答の品質がよいこと」という基準を、条件に合う2つ以上の測定可能な基準に書き直してください。

5-2. LLM採点器を運用評価に使う前に行う補正手順を、順に書いてください。

5-3. Anthropicのドキュメントで、4.6世代以降のモデルIDとそれ以前の別名がそれぞれ何を指すかを書き、固定しても変更計画が必要な理由を説明してください。

5-4. 韓国の「個人情報保護法」における仮名処理の定義を書き、LLM機能の評価セット作成にどう適用できるかを説明してください。

5-5. 変更候補のモデルは評価セットの平均を上げましたが、高リスク区分の得点を下げました。どの手順で判断し、どの選択肢があるかを書いてください。

5-6. 運用中のLLM機能を1つ選び、運用上の問いを5つ定め、各問いの指標（分母を含む）、平常範囲、アラート条件、担当者と最初の対応を表にしてください。

実習課題