見出し画像

AIシステムは、公開してから何を評価すべきか？品質・費用・事故・変更を管理する継続運用の11要素

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中

AIシステムを公開する前に、さまざまなテストを行った。

正常な入力では期待どおりに動く。危険な操作は止まる。出力形式も正しい。人間承認のフローも確認した。

これなら本番でも使える。そう判断して運用を始めます。

ところが、しばらくすると、公開前には以下のような見えなかった問題が出てきます。

  • 想定していなかった問い合わせが届く

  • 人間による修正が増える

  • 古いナレッジを参照する

  • 特定の例外だけ処理できない

  • 利用件数の増加に伴って費用が膨らむ

  • モデルやToolを更新した後、以前は正しかったケースで失敗する

公開前のテストに合格したことと、本番で継続的に信頼できることは同じではありません。

本番環境では、入力、利用者、業務ルール、データ、外部サービス、モデル、費用が変化します。

必要なのは、一度の合否判定ではありません。

実際の利用結果と失敗を継続的に観測し、原因を切り分け、止め、直し、再評価し、必要なら縮小・廃止できる運用機能です。

フェーズ10では、AIシステムをTest、Trace、停止、再開、Rollbackできる実行基盤へ落としました。

フェーズ11では、その基盤を使い、品質、安全性、速度、費用、変更、事故、責任を継続的に管理します。

今回は、AI活用成熟度12フェーズのフェーズ11「評価・運用・ガバナンス」として、AIシステムを本番で運用するための11の設計要素を整理します。

AI活用成熟度12フェーズの記事一覧


フェーズ10で「測れる・追える・止められる」基盤を作った次は、継続運用へ進む

フェーズ10では、AIモデルを単独で動かすのではなく、周囲に実行制御を設計しました。

例えば次です。

  • Goalと完了条件

  • Context

  • Tool

  • State

  • 権限

  • Human-in-the-loop

  • Guardrail

  • Test

  • Trace

  • Retry

  • Fallback

  • Rollback

これにより、AIシステムが何を行い、何を変更し、どこで失敗したかを確認できるようになります。

しかし、観測できる基盤があるだけでは、何を見て、どの状態を問題と判断するかまでは決まりません。

次を決める必要があります。

  • どの品質を合格とするか

  • どの失敗を重大とするか

  • どのケースを毎回テストするか

  • 何を本番監視するか

  • 費用や人間負担をどこまで許容するか

  • 変更後に何を再確認するか

  • 誰が停止できるか

  • 誰が再開を承認するか

  • いつ改善を諦め、廃止するか

フェーズ10が「測れる・追える・止められる基盤を作る段階」なら、フェーズ11は「その基盤を使い、品質・リスク・成果を継続的に統制する段階」です。

一方、AIの利用結果をもとに事業戦略、組織構造、人材、投資配分まで組み直すのは、次のフェーズ12です。

評価は「良い回答か」を点数化することではない

AI評価と聞くと、回答へ点数を付けたり、正答率を測ったりする作業を想像しやすいでしょう。

もちろん、それも評価の一部です。

ただし、業務で使うAIシステムでは、文章が自然で正しそうに見えるだけでは足りません。

例えば、回答文自体は適切でも、次のような失敗があり得ます。

  • 誤ったToolを選択した

  • 顧客を取り違えた

  • 承認前に送信した

  • 高リスク案件を通常ルートへ流した

  • 同じデータを二重登録した

  • 処理費用が業務価値を上回った

  • 人間確認の負担が以前より増えた

したがって、評価は文章だけでなく、実行と業務結果を含めて設計します。

業務目的を満たしたかを評価する

最初に確認するのは、モデルの一般的な賢さではありません。

そのAIシステムが、対象業務で何を達成すべきかです。

例えば問い合わせ回答AIなら、目的は単に「自然な文章を生成する」ことではありません。

  • 顧客の問題を正しく把握する

  • 適切なナレッジを参照する

  • 不明なことを推測しない

  • 高リスク案件を専門担当者へ渡す

  • 誤解のない回答案を作る

  • 必要な承認を経て送信する

  • 顧客が再度問い合わせなくても解決できる

この目的を満たしたかを評価します。

OpenAIも、まず何をもって優れているとするかを定義し、実環境に即して測定し、エラーから改善する流れを示しています。

正答率だけでは見えない失敗がある

分類業務なら正答率を計算できます。

しかし、正答率95％でも、残り5％がすべて高リスク案件なら運用できません。

平均値とは別に、次を確認します。

  • 重大エラー

  • 高リスク案件の見逃し

  • 権限超過

  • 誤送信

  • 個人情報・機密情報の漏えい

  • 人間承認の回避

  • 復旧不能な処理

重大な少数ケースを平均スコアへ埋め込まないことが重要です。

評価できない業務は、自動化範囲を広げない

良い結果の条件も、重大な失敗も定義できない場合、AIへ任せる範囲を拡大すべきではありません。

評価できないということは、運用後に品質が悪化しても気づけないということです。

この場合は、AIの役割を次へ限定します。

  • 情報整理

  • 候補作成

  • 論点抽出

  • 下書き

  • 人間判断の補助

最終判断や外部実行へ進めません。

評価対象を4つの層へ分ける

AIシステムの評価対象は、次の4層に分けます。

  1. Output

  2. Action・Tool

  3. Workflow

  4. Business Outcome

Google ADKも、応答品質に加えてTool callの経路、Tool利用品質、安全性、複数ターンのタスク達成度等を評価対象として提供しています。

1. Output｜出力そのものを評価する

最終回答、分類結果、要約、構造化データなどを評価します。

主な観点は次です。

  • 正確性

  • 完全性

  • 関連性

  • 一貫性

  • 根拠

  • 形式

  • 禁止事項

  • 不確実性の表示

例えば問い合わせ回答なら、次を確認します。

  • 顧客の質問に答えているか

  • 必要事項が抜けていないか

  • 社内ナレッジと一致しているか

  • 不明な料金や条件を推測していないか

  • 顧客へ誤解を与える断定がないか

2. Action・Tool｜どの行動を選んだかを評価する

エージェント型のシステムでは、最終出力が正しくても、その過程が危険な場合があります。

確認するのは次です。

  • 適切なToolを選んだか

  • Toolを呼ぶ必要があったか

  • 引数が正しかったか

  • 権限範囲を守ったか

  • 副作用を理解していたか

  • 二重処理を防いだか

  • 不要なToolを呼んでいないか

3. Workflow｜停止・承認・例外・再開を評価する

個々の出力とToolが正しくても、全体の流れが誤っている場合があります。

確認するのは次です。

  • 必要な承認を待ったか

  • 情報不足で停止したか

  • 高リスク条件を例外ルートへ送ったか

  • 差し戻し後に正しい地点から再開したか

  • Retry上限を守ったか

  • 中止後に外部操作を続けていないか

  • 承認済み工程を重複実行していないか

4. Business Outcome｜業務成果を評価する

AIシステムが技術的に正しく動いても、業務が改善していなければ導入成功とはいえません。

確認するのは次です。

  • 総リードタイム

  • 人間作業時間

  • 待ち時間

  • 人間修正率

  • 一件当たり費用

  • 顧客の再問い合わせ

  • 顧客満足

  • 現場負担

  • エスカレーション率

  • 事故・訂正件数

良い文章を出していても、誤ったToolを実行し、現場負担や顧客問題を増やしていれば、そのシステムは失敗です。

ゴールデンデータセットは、成功例より「失敗境界」を集める

回帰評価を行うには、繰り返し使えるテストケースが必要です。

これを、この記事ではゴールデンデータセットと呼びます。

ただし、模範的な入力と正解だけを集めるのでは不十分です。

正常ケースだけでは足りない

正常な入力だけで評価すれば、高いスコアが出やすくなります。

本番では次のケースが届きます。

  • 情報不足

  • 曖昧な質問

  • 複数の意図

  • 資料間の矛盾

  • 古い情報

  • 対象外

  • 高リスク

  • 攻撃的な入力

  • 判断基準の境界

  • 人間へ移管すべき案件

これらを含めます。

過去の失敗を回帰テストへ戻す

本番で発生した失敗は、その場で修正して終えてはいけません。

例えば、古い料金表を参照して誤回答したなら、次をテストケースへ追加します。

  • 古い料金表と新しい料金表が同時に存在する

  • 基準日が指定されている

  • 最新版が見つからない

  • 過去契約には旧料金が適用される

  • 顧客条件によって料金が異なる

同じ種類の失敗が再発しないかを確認します。

模擬ケースと実データを分ける

評価ケースには、次の二種類があります。

  • 人工的に作った模擬ケース

  • 実際の利用から得たケース

模擬ケースは、まだ起きていない危険や境界条件を試すのに向いています。

実データは、利用者の予想外の表現や運用上の問題を反映します。

両方を組み合わせます。

ケースに版・出典・期待結果を持たせる

各ケースには次を記録します。

  • Case ID

  • 入力

  • 出典

  • 作成日

  • 適用業務

  • リスク区分

  • 期待する出力

  • 期待するTool

  • 期待するWorkflow状態

  • 禁止結果

  • Rubric

  • 対応する過去インシデント

  • ケースの版

  • 更新責任者

ゴールデンデータセットは、単なるテスト用ファイルではありません。

業務における「良い結果」と「許容できない失敗」を記録した組織資産です。

古くなったケースを更新・廃止する

業務ルールや商品仕様が変われば、過去の正解が現在の正解ではなくなります。

ゴールデンデータセットを固定的な正解集として扱わず、次を定期確認します。

  • 現在の業務に合うか

  • 最新資料を参照しているか

  • 廃止されたToolを前提にしていないか

  • 現在の権限・承認ルールと合うか

  • 重複ケースがないか

  • 新しい失敗を含んでいるか

  • 個人情報や機密情報を保持し続ける必要があるか

MetricsとRubricを使い分ける

すべてを同じ方法で評価する必要はありません。

正誤を機械的に判定できるものと、人間的な判断が必要なものを分けます。

完全一致やルールで測れるもの

例えば次です。

  • JSON Schema

  • 必須項目

  • 数値

  • 日付

  • Tool名

  • 引数

  • 状態遷移

  • 承認有無

  • 処理時間

  • Token数

  • 費用

  • 禁止語

  • Reference ID

これらは自動検査しやすい領域です。

Rubricで評価するもの

唯一の正解文章がない場合は、評価基準を定義します。

例えば顧客回答なら次です。

  • 質問へ直接答えている

  • 根拠を示している

  • 不明な点を推測していない

  • 顧客へ必要な次の行動が分かる

  • 不必要に長くない

  • 責任範囲を超えて断定していない

  • 高リスク条件を認識している

項目ごとに合格・不合格、または段階評価を行います。

LLM-as-a-judgeを単独の最終判定にしない

LLMを評価者として使うと、大量の出力を比較できます。

ただし、評価モデルも判断を誤り、評価指示、提示順、文章量、表現形式等の影響を受ける可能性があります。

そのため、次と組み合わせます。

  • 機械的検査

  • 人間評価

  • Tool実行結果

  • 業務成果

  • 高リスクケースの全件確認

  • 複数評価方法の一致

OpenAIも、LLM graderを利用する場合に、ドメイン専門家が精度を継続監査し、実行ログを直接確認する必要があると説明しています。

人間評価と自動評価を組み合わせる

自動評価は、大量ケースを一定条件で繰り返すことに向いています。

人間評価は、価値判断、顧客適合、重大な例外、説明責任に向いています。

どちらか一方へ統一するのではなく、評価対象によって分けます。

オフライン評価では、変更前後を比較する

オフライン評価は、本番へ変更を反映する前に行います。

固定したケースと基準を使い、現行版と変更版を比較します。

OpenAIの現行Evals APIでは、タスクを定義し、テスト入力で評価を実行し、結果を分析して改善する流れが案内されています。一方、旧Evalsプラットフォームは2026年中に終了予定であり、新規構築では現行のDatasetsや評価機能を確認する必要があります。

モデル変更

モデルを変更すると、次が変わる可能性があります。

  • 出力内容

  • Tool選択

  • 構造化出力

  • 長文Contextの扱い

  • 停止判断

  • 速度

  • 費用

変更対象の工程だけでなく、前後Workflowも回帰確認します。

Prompt・Rule・Skill変更

「表現を少し直しただけ」の変更でも、重要な制約が弱まる場合があります。

次を確認します。

  • 正常ケース

  • 例外ケース

  • 禁止操作

  • 出力形式

  • Tool利用

  • 人間移管

  • 過去インシデント

Tool・API変更

Toolの説明やSchema、外部APIの仕様が変わると、エージェントの選択や結果が変わります。

  • Tool名

  • 引数

  • Error

  • 副作用

  • Rate limit

  • 権限

  • 応答形式

を再確認します。

Knowledge・RAG変更

参照文書を追加・削除・更新すると、検索結果や回答が変わります。

確認するのは次です。

  • 最新版を優先できるか

  • 旧版を誤参照しないか

  • 必要文書を取得できるか

  • 関係のない文書を取得しないか

  • 根拠を追跡できるか

権限・承認ルール変更

低リスク案件の承認を減らした場合、処理時間は短くなるかもしれません。

一方で、誤送信リスクが増える可能性があります。

速度だけでなく安全性を回帰確認します。

オフライン評価と本番実験は役割が違う

固定ケースの評価に合格しても、実際の利用者が同じように使うとは限りません。

本番反映では、リスクに応じて次を使い分けます。

Shadow運用

現行システムの結果を正式採用しつつ、新システムも裏側で実行して比較します。

外部影響を出さずに実データ上の挙動を確認できます。

Canaryリリース

一部の利用者、案件、部門だけに変更を適用します。

問題があれば影響範囲を限定できます。

A/Bテスト

複数案を実利用条件で比較します。

ただし、高リスク業務では無作為な実験が適切でない場合があります。

段階的展開

Read-only、Draft、承認付き実行のように、権限と対象範囲を段階的に広げます。

EvalsはA/Bテストや従来のプロダクト実験の代替ではなく、変更の実環境への影響を確認する手段と組み合わせて使う必要があります。

本番監視では、品質・安全・速度・費用を見る

公開前評価だけでは、本番固有の入力分布、利用目的、外部障害、担当者行動までは把握できません。

本番で観測する指標を決めます。

フェーズ11で扱う11要素は、次の3層に整理できます。

評価設計

  1. Purpose・Success Criteria

  2. Golden Dataset・Test Cases

  3. Metrics・Rubrics

  4. Offline Evals

本番運用

  1. Online Monitoring

  2. Human Evaluation

  3. Error Taxonomy・Drift

  4. SLO・Cost・Capacity

  5. Incident Response

組織統制・改善

  1. Change・Vendor・Access Management

  2. Governance・Review・Retirement

これらは1から11へ進む成熟段階ではなく、循環する運用要素です。

NIST AI RMFも、Govern、Map、Measure、Manageを順番に一度だけ行うチェックリストではなく、AIライフサイクルを通じて継続的に行う機能として整理しています。現行のAI RMF 1.0は改訂中であり、Playbookも改訂後に更新予定です。

採用率・修正率を見る

AIの回答案が、どれくらいそのまま採用されたかを確認します。

  • そのまま採用

  • 軽微修正

  • 大幅修正

  • 全面作り直し

  • 却下

  • 専門担当者へ移管

単なる採用率だけでなく、修正理由も分類します。

エラーと例外を見る

確認するのは次です。

  • Tool Error

  • Timeout

  • Schema Error

  • 権限不足

  • 情報不足

  • 判断不能

  • 高リスク移管

  • 二重処理

  • 承認期限超過

  • 手動復帰

正常案件だけでなく、例外処理が機能しているかを見ます。

人間確認時間を見る

AI処理が速くても、人間確認時間が増えていれば全体として改善していません。

  • 一件当たり確認時間

  • 確認待ち時間

  • 差し戻し回数

  • 評価者間の往復

  • 高リスク案件の集中

を確認します。

処理時間と滞留を見る

総リードタイムを次へ分解します。

  • AI処理

  • Tool待ち

  • 情報待ち

  • 承認待ち

  • Retry

  • 手動対応

  • 外部システム待ち

平均だけでなく、長時間滞留する案件も確認します。

費用を見る

費用にはモデル料金だけでなく、次を含めます。

  • Tool・API料金

  • 検索・ストレージ

  • 人間確認

  • 失敗修正

  • インシデント対応

  • 評価・監査

  • 保守

一件当たり価値と比較します。

安全インシデントを見る

重大な安全指標は、通常の品質スコアと分けます。

  • 個人情報

  • 機密情報

  • 誤送信

  • 誤登録

  • 権限超過

  • 未承認実行

  • 不公平な処理

  • 説明不能な判断

重大インシデントは件数が少なくても優先対応します。

利用目的の逸脱を見る

当初は文章作成支援として導入したAIが、いつの間にか最終判断へ使われることがあります。

確認するのは次です。

  • 対象外部門での利用

  • 未承認用途

  • 高リスク判断への転用

  • 私的データの投入

  • 人間確認の省略

  • 手順外のTool利用

指標ごとにOwnerと対応行動を決める

指標を集めるだけでは運用になりません。

各指標について、次を決めます。

  • 誰が見るか

  • どの頻度で見るか

  • どの値で注意するか

  • どの値で調査を開始するか

  • どの値で停止するか

  • 誰へエスカレーションするか

対応行動につながらない指標は、取得する意味が弱くなります。

人間評価もCalibrationする

AIの評価に人間を入れれば、自動的に正しくなるわけではありません。

評価者によって判断が異なる場合があります。

Rubricを共有する

「分かりやすい」「適切」といった抽象語だけでは、評価が揺れます。

何を見るかを具体化します。

良い例・悪い例・境界例を用意する

Rubricだけでなく、具体例を共有します。

特に重要なのは、意見が分かれやすい境界例です。

評価者間の判断を比較する

同じサンプルを複数人が評価し、差が大きい項目を確認します。

差がある場合、AIの問題ではなく、業務基準が曖昧な可能性があります。

判断責任者を決める

評価者間で合意できない場合、最終的に誰が業務基準を決めるかを明確にします。

多数決だけでは適切でない高リスク領域もあります。

評価者疲労を監視する

大量の出力を連続評価すると、判断が雑になる可能性があります。

  • サンプル数

  • 評価時間

  • 休憩

  • 高リスクケースの分離

  • 二重確認の対象

を設計します。

エラー分類とドリフトで原因を切り分ける

本番で品質が悪化したとき、「AIが間違えた」とまとめると改善できません。

原因を分類します。

入力問題

  • 情報不足

  • 曖昧

  • 形式違反

  • ノイズ

  • 対象外

Context・Knowledge問題

  • 必要文書を取得できない

  • 旧版参照

  • 検索順位

  • 文書欠落

  • 権限不足

モデル問題

  • 推論

  • 指示追従

  • 構造化出力

  • Tool選択

  • 長文処理

Tool問題

  • API障害

  • Schema変更

  • Timeout

  • 誤った結果

  • 副作用

Workflow問題

  • 承認漏れ

  • 例外分岐

  • State消失

  • Retry

  • 二重処理

権限・承認問題

  • 権限過多

  • 権限不足

  • 承認者不在

  • 形式承認

  • 期限超過

人間運用問題

  • 手順逸脱

  • Rubric不統一

  • 誤承認

  • 入力ミス

  • フィードバック未記録

業務変更

  • 商品変更

  • 料金変更

  • 契約変更

  • 組織変更

  • 判断基準変更

ドリフトをモデルだけの問題にしない

変化は複数層に起こります。

  • 入力ドリフト

  • Knowledgeドリフト

  • Toolドリフト

  • 業務ドリフト

  • 利用ドリフト

  • 組織ドリフト

  • モデル変更

どの層が変化したかを確認します。

SLOとガードレールを先に決める

本番監視の数値を見ても、正常か異常かの基準がなければ判断できません。

そこで、サービス目標と停止条件を決めます。

品質目標

例：

  • 必須項目欠落率1％未満

  • 正常案件の大幅修正率10％未満

  • 根拠取得率98％以上

数値は業務ごとに定めます。

速度目標

例：

  • 95％の案件を10分以内に処理

  • 承認待ち24時間超を5％未満

費用上限

例：

  • 一件当たり総費用500円以下

  • 月間予算超過時に新規処理を制限

人間負担上限

例：

  • 一件当たり確認時間5分以内

  • 特定担当者への集中率を一定以下にする

安全下限

例：

  • 高リスク案件の無承認送信0件

  • 個人情報漏えい0件

  • 二重請求0件

停止条件

例：

  • 重大インシデント発生

  • 高リスク見逃し

  • 誤送信が一定件数を超える

  • 費用が上限を大幅超過

  • 例外滞留が増加

  • 人間確認が機能していない

KPIが改善しても、ガードレールが悪化した場合は停止します。

インシデント対応を通常運用へ組み込む

インシデント対応は、問題が起きてから考えるものではありません。

事前に流れを決めます。

検知
→ 影響範囲の特定
→ 停止・隔離
→ 手動運用への復帰
→ 関係者への連絡
→ 原因分析
→ 修正
→ 再評価
→ 再開判断
→ 再発防止

検知

誰が、どの指標・報告から異常を認識するかを決めます。

影響範囲の特定

  • 対象顧客

  • 対象期間

  • 使用モデル

  • Prompt版

  • Tool版

  • 処理ID

  • 出力

  • 外部操作

を追跡します。

停止・隔離

  • 自動送信停止

  • Write権限停止

  • 対象Knowledge隔離

  • 特定モデル停止

  • 対象Workflow停止

などを行います。

手動復帰

業務を継続する必要がある場合、手動運用へ戻します。

報告

社内外への報告要否を判断します。

原因分析

「モデルの誤り」で終えず、入力、Knowledge、Tool、Workflow、承認、人間運用を確認します。

再評価・再開

修正後に回帰評価を行い、再開権限者が判断します。

変更・ベンダー・アクセスを管理する

AIシステムの挙動は、モデル以外の変更でも変わります。

すべての変更を管理対象にします。

変更記録

  • 変更内容

  • 変更理由

  • Owner

  • 影響範囲

  • 回帰評価

  • 承認者

  • 反映日時

  • 監視期間

  • Rollback先

Model provider・モデル変更

提供条件、データ利用条件、価格、廃止予定、性能差を確認します。

API・Tool変更

Schema、権限、Error、Rate limit、副作用を確認します。

データ・Knowledge変更

最新版、保存期間、利用権限、削除、旧版管理を確認します。

Access管理

利用者、管理者、評価者、承認者の権限を定期確認します。

評価データの管理

評価用の本番入力、出力、人間修正、インシデント記録には、個人情報や機密情報が含まれる可能性があります。

次を決めます。

  • 収集対象

  • 匿名化・仮名化

  • 閲覧権限

  • 学習利用の可否

  • 外部評価サービスへの送信可否

  • 保存期間

  • 削除手順

  • 監査記録

「評価のため」という理由で、本番データを無制限に保存しません。

ベンダー管理

ベンダーのマーケティング説明だけを判断根拠にしません。

  • 契約

  • セキュリティ

  • データ処理

  • 可用性

  • 価格

  • サポート

  • モデル・APIの廃止予定

  • 終了時のデータ移行

  • 代替手段

を確認します。

ガバナンスは、判断権限と改善責任を決める

ガバナンスは、禁止事項を並べた文書ではありません。

誰が判断し、誰が止め、誰が直し、誰が再開・廃止を決めるかを明確にする仕組みです。

ISO/IEC 42001:2023は、組織がAIマネジメントシステムを確立、実施、維持し、継続的に改善するための要求事項と指針を扱います。個別モデルの精度を保証する規格ではなく、方針、役割、運用、パフォーマンス評価、継続改善を組織的に管理する枠組みです。

System Owner

システム全体の継続・変更・廃止へ責任を持ちます。

Business Owner

業務目的、品質基準、顧客・現場への成果へ責任を持ちます。

Technical Owner

モデル、Tool、データ、実行基盤、障害対応へ責任を持ちます。

Risk・Security・Legal

高リスク利用、セキュリティ、プライバシー、規制・契約上の確認を行います。

Human Reviewer

個別出力の採否・例外を判断します。

Incident Commander

重大事故時の停止、影響確認、対応を統括します。

Stop authority

誰が即時停止できるかを決めます。

Restart authority

修正・再評価後、誰が再開を承認するかを決めます。

Retirement authority

誰が縮小・廃止を決定するかを決めます。

ケース：問い合わせ回答AIを継続運用する

具体例として、顧客問い合わせへ回答案を作成するAIを考えます。

システムの基本フロー

問い合わせ受信
→ 分類
→ 社内Knowledge検索
→ 回答案作成
→ 人間承認
→ 送信

公開前評価

ゴールデンデータセットへ次を含めます。

  • 正常な質問

  • 情報不足

  • 契約条件

  • 返金

  • 個人情報

  • 感情的な苦情

  • 対象外

  • 古いFAQ

  • 高リスク

  • 専門担当者へ渡す案件

出力評価

  • 質問へ回答している

  • 正しいFAQを参照している

  • 推測していない

  • 必要な留保がある

  • 次の行動が分かる

Tool・Workflow評価

  • 正しい顧客を参照

  • 最新FAQを検索

  • 高リスク案件で停止

  • 人間承認前に送信しない

  • 同じ問い合わせへ二重送信しない

本番監視

  • 回答案採用率

  • 軽微修正率

  • 大幅修正率

  • 専門担当者への移管率

  • 返信時間

  • 承認待ち時間

  • 再問い合わせ率

  • 一件当たり費用

  • 誤回答

  • 苦情

  • 誤送信

インシデント例

ナレッジ検索が古いFAQを優先し、現在とは異なる料金を複数顧客へ案内したとします。

初動

  • 自動送信を停止

  • 影響顧客を特定

  • 対象期間を確認

  • 誤案内を訂正

  • 旧FAQを隔離

  • 手動回答へ戻す

原因分析

確認するのは次です。

  • 最新FAQのMetadata

  • 検索順位

  • 基準日の扱い

  • 旧版の権限

  • 回答案の根拠表示

  • 人間承認時の確認項目

  • 評価ケースの不足

改善

  • 旧版を通常検索対象から除外

  • 基準日を必須入力にする

  • 根拠FAQと更新日を表示

  • 過去インシデントをゴールデンケースへ追加

  • 回帰評価を実施

  • Shadow運用で新しい構成を比較

  • 限定範囲で再開

  • 監視期間後に通常運用へ戻す

本番の失敗を、次の評価ケースと仕組みの改善へ戻すことが重要です。

実務テンプレート：AI評価・運用キャンバス

対象AIシステム：

1. Purpose・Success Criteria
業務目的：
対象利用者：
成功状態：
対象範囲：
許容しない結果：
一時停止条件：
廃止条件：

2. Evaluation Scope
Output：
Action・Tool：
Workflow：
Business Outcome：

3. Golden Dataset
正常ケース：
情報不足：
矛盾：
高リスク：
対象外：
過去失敗：
期待結果：
禁止結果：
Case版：
更新責任者：
データ保存期限：

4. Metrics
品質：
安全性：
速度：
費用：
人間負担：
顧客価値：
指標Owner：
対応行動：

5. Rubric
評価項目：
合格条件：
不合格条件：
境界例：
重大エラー：
評価方法：

6. Offline Evals
モデル変更：
Prompt変更：
Skill・Rule変更：
Tool・API変更：
Knowledge変更：
権限・承認変更：
回帰合格条件：

7. Production Experiment
Shadow：
Canary：
A／B：
対象範囲：
監視期間：
展開条件：
Rollback条件：

8. Online Monitoring
採用率：
軽微修正率：
大幅修正率：
差し戻し率：
例外率：
処理時間：
承認待ち：
人間確認時間：
費用：
事故：
利用目的逸脱：

9. Human Evaluation
評価者：
サンプル率：
Rubric：
Calibration：
境界例：
不一致時の判断者：
評価者負担：

10. Error Taxonomy・Drift
入力：
Context・Knowledge：
Model：
Tool：
Workflow：
権限・承認：
人間運用：
業務変更：
利用目的変更：

11. SLO・Guardrails
品質下限：
速度目標：
費用上限：
人間負担上限：
安全下限：
滞留上限：
一時停止条件：

12. Incident Response
検知方法：
初動責任者：
停止権限：
影響範囲確認：
隔離：
手動復帰：
社内報告：
利用者連絡：
原因分析：
再評価：
再開承認：

13. Change Management
変更対象：
変更理由：
影響範囲：
Test：
承認者：
反映日：
監視期間：
Rollback：

14. Vendor・Data・Access
ベンダー：
契約：
データ利用：
評価データ：
匿名化：
保存期間：
利用者権限：
管理者権限：
外部評価サービス：
サービス終了時の移行：

15. Governance
System Owner：
Business Owner：
Technical Owner：
Risk・Security・Legal：
Human Reviewer：
Incident Commander：
Stop authority：
Restart authority：
Retirement authority：

16. Review・Retirement
定期レビュー日：
継続条件：
修正条件：
縮小条件：
一時停止条件：
廃止条件：
終了後のデータ処理：

最初からすべての指標を集める必要はありません。

運用上の判断に使うものから始めます。

すべてを評価しようとしない

評価項目を増やすほど成熟しているわけではありません。

測定・保存・レビューにはコストがかかります。

測定コストが便益を上回る

低頻度・低リスクで、手動確認が容易な業務では、大規模な評価基盤は不要かもしれません。

正常処理が単純

Schema検証と既存の業務確認だけで十分な場合があります。

データが不足している

少数データから細かな指標を出しても、安定した判断には使えません。

評価結果を使う責任者がいない

指標を集めても、変更・停止を判断する人がいなければ改善につながりません。

意思決定に使わない指標は集めない

各指標について確認します。

  • 誰が見るか

  • 何の判断に使うか

  • どの値で行動が変わるか

  • 取得コストに見合うか

  • 保存するリスクはないか

フェーズ11の到達条件

次を満たせれば、フェーズ11の実践が進んでいると判断できます。

  • AIシステムの業務目的が明確

  • 重大な失敗を定義している

  • 評価対象をOutput・Action・Workflow・Business Outcomeへ分けている

  • ゴールデンデータセットがある

  • 正常例だけでなく例外・高リスク・過去失敗を含む

  • ケースの版と更新責任者が明確

  • MetricsとRubricを使い分けている

  • オフライン評価とオンライン監視がある

  • Shadow・Canary等の段階的展開を選択できる

  • 人間評価をCalibrationしている

  • エラー分類がある

  • ドリフトを複数層に切り分けられる

  • 品質・速度・費用・人間負担のSLOがある

  • 重大な安全指標を平均品質と分けている

  • 指標ごとのOwnerと対応行動がある

  • インシデント対応がある

  • 手動復帰できる

  • 変更管理がある

  • モデル以外の変更も回帰対象にしている

  • ベンダー・データ・アクセスを管理している

  • 評価データの権限・保存期間が明確

  • System OwnerとBusiness Ownerが明確

  • 停止・再開・廃止権限が明確

  • 定期レビューがある

  • 継続・修正・縮小・停止・廃止を判断できる

  • 本番の失敗が次の評価ケースへ戻る

最も重要なのは、評価スコアを高く保つことではありません。

問題を早く検知し、影響を限定し、原因を特定し、正しく止め、直し、再開または廃止できることです。

次フェーズでは、評価可能なAIを経営と組織変革へ接続する

フェーズ11では、AIシステムの品質、費用、リスク、利用結果を継続的に把握できるようになります。

そのデータがそろうと、経営は次を判断できます。

  • どのAI投資を拡大するか

  • どのシステムを縮小・廃止するか

  • 内製・購入・提携をどう分けるか

  • 人間が担う役割をどう変えるか

  • どの能力を育成するか

  • 意思決定権をどう再配置するか

  • どの事業モデルを変えるか

  • どの競争優位を自社へ蓄積するか

これがフェーズ12「AIネイティブな経営・組織変革」です。

フェーズ11の評価データがなければ、経営判断はAI利用件数や印象論へ戻ってしまいます。

品質、費用、顧客価値、現場負担、事故を把握できて初めて、AIを経営資源として比較・配分できます。

まとめ：AIの信頼性は、止めて直せる運用能力で決まる

AIシステムは、公開前にTestへ合格したから完成するわけではありません。

本番では、入力、利用者、業務、Knowledge、Tool、モデル、費用が変化します。

フェーズ11で確認するのは次です。

  • 何を成功とするか

  • 何を重大な失敗とするか

  • どのケースを繰り返し評価するか

  • OutputだけでなくAction・Workflow・業務成果を評価しているか

  • どの本番指標を監視するか

  • 人間評価の基準はそろっているか

  • 原因を分類できるか

  • 品質・速度・費用・人間負担の限界はどこか

  • インシデント時に誰が止めるか

  • 誰が再開を承認するか

  • 変更後に何を再評価するか

  • 評価データを安全に管理しているか

  • いつ縮小・廃止するか

AIシステムの信頼性は、問題が一度も起きないことではありません。

本番の失敗と変化を検知し、影響を限定し、原因を追跡し、止め、直し、学びへ変えられることです。

評価は公開前の関門ではありません。

運用を継続するか、変更するか、停止するかを判断するための機能です。

本番から得た失敗をゴールデンデータセットへ戻す。変更後に回帰評価する。重大な問題では停止する。効果が見合わなければ縮小・廃止する。

この循環があって初めて、AIシステムは「動く仕組み」から「責任を持って運用できる仕組み」へ変わります。

関連記事

AIへ任せる範囲と、人間が保持すべき採否、停止、回復、説明責任の境界はこちらで考察しています。

特定モデルへ依存せず、評価基準、業務データ、判断履歴を企業の資産として持つ考え方はこちらで整理しています。

個別のAI導入を、業務、権限、評価、組織を含む経営変革へ接続する論点はこちらで解説しています。

企業で実行する場合

この記事で扱ったEvals、本番監視、変更管理、インシデント対応、AIガバナンスを、自社のAIシステムや業務運用へ落とし込みたい場合は、支援内容を以下の記事にまとめています。

生成AIを導入した。でも、業務は変わらなかった。そんな企業へ研修から業務設計・開発・改善運用まで支援します

AI活用成熟度12フェーズの記事一覧

出典・参考資料

いいなと思ったら応援しよう！

南翔伍 / AIコンパニオンとSNSの間くらいの「Jams」開発中 社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。