導入は起点であって終点ではない
AIを組み込んだ仕組みは、稼働した時点が完成ではありません。第13章で述べたとおり、コードを変えていないのに品質が変わるという性質があるためです。
本章では、稼働後に何を測り、どう改善のサイクルを回すかを扱います。第14章(テスト・品質保証)で作った仕組みを、運用に乗せる章です。
必要なものは多くありません。検証セット、ログ、月次で見る数字、そして見直しの担当。この4つで成立します。
定期的な精度モニタリング
何を測るか
測る対象は、性質の違う3種類に分かれます。混ぜると原因の切り分けができません。
1層目はモデルやプロンプトの変化を検知します。2層目は実際のデータの傾向の変化を検知します。基準に対する精度が変わっていないのに実運用の修正率が上がった場合、入力データの性質が変わっている可能性があります。
実務的な運用
- 検証セットの定期実行を自動化する ― スクリプト1本と実行の仕組みで足ります。
- 結果を時系列で残す ― 単発の数値ではなく推移を見ます。
- 閾値を決めて通知する ― 正解率が一定以上下がったら通知します。
- 修正率も同じ表に並べる ― 2つの層の関係が見えます。
- 費用も同時に記録する ― 1件あたりの費用の変化に気づけます。
劣化に気づけない構造を避ける
モニタリングがない場合、品質の低下に気づく経路は「利用者からの申告」だけになります。この経路には2つの問題があります。
- 遅い ― 利用者が違和感を持ち、それを報告するまでに時間がかかります。
- 届かない ― 報告が「AIとはそういうもの」で処理されると、記録にも残りません(第15章)。
したがって、数値による検知の仕組みは、報告経路の代替ではなく前提です。
モデル・サービスのアップデートへの追随
提供側の変化に対応する運用です。第10章でリスクとして扱った内容を、実務手順として整理します。
変化を知る経路を作る
- 提供元の更新情報を受け取る担当を決める ― 通知の受信先を個人のメールにしない。
- 更新の予定を記録する ― モデルの廃止予定、仕様変更の予定。
- 影響範囲を把握しておく ― どの処理がどのモデルを使っているか(第13章の抽象化の層があれば一覧化できます)。
更新時の手順
あらかじめ手順を決めておくと、更新の通知が来たときの判断が速くなります。
- 検証セットで新しいモデル・バージョンを評価する
- 結果を現行と比較する(改善・悪化の両方を確認)
- 悪化がある場合、プロンプトの調整を試す
- 費用と応答時間を再計算する
- 一定期間の並行運用または段階的な切り替えを行う
- 切り替え後、修正率の推移を注視する
3番目が重要です。モデルによって効く指示が違うため、同じプロンプトのままでは性能が出ないことがあります。悪化の原因がモデルの性能ではなくプロンプトの不適合である場合が少なくありません。
フィードバックループの構築
利用者の反応を改善に結びつける仕組みです。作らないと、改善の材料が集まりません。
集める仕組み
| 方法 | 集まるもの | 使い道 |
|---|---|---|
| 修正の記録 | 実際に何が誤っていたか | 検証セットへの追加。最も価値が高い |
| 出力への評価(役立った/役立たない) | 利用者の主観的な満足度 | 傾向の把握。理由は分からない |
| 自由記述の意見 | 具体的な不一致の内容 | 設計の見直し(第15章) |
| 利用率の推移 | 使われているかどうか | 低下は設計の不一致を示す |
| 問い合わせ・要望 | 期待と実態のずれ | 対応・保留・不可の分類と理由 |
1番目が最も価値があります。人が修正した内容は、そのまま検証セットに追加できる材料です。誤りの実例が蓄積されるほど、検証セットの品質が上がります。
改善に変換する
集めた材料を処理する経路を決めます。第15章で扱った「要望が『そういうもの』で終わる」型を避けるためです。
- 要望を記録する場所を作る ― 口頭で消えないようにします。
- 対応・保留・不可に分類し、理由を1行書く ― 「不可」の理由が書けないものは、まだ検討されていません。
- 対応するものは、変更の対象を特定する ― プロンプト、参照データ、確認工程、モデル、業務手順のどれか。
- 変更後に検証セットを流す ― 他の項目を悪化させていないかを確認します(第14章)。
- 結果を要望の記録に戻す ― 報告した人に結果が返る経路を作ります。
5番目を省略すると、要望が上がらなくなります。報告しても何も起きないという経験が、報告を止めます。
自動的な学習への反映は慎重に
利用者の評価を自動的に学習に反映する設計は、注意が必要です。意図的に誤った評価を与える操作が成立し得るためです(第21章のデータポイズニング)。人の確認を挟む設計が安全です。
利用状況の可視化とレポーティング
数字を見る仕組みと、それを共有する形です。
月次で見る項目
多くすると見られなくなります。5項目に絞ります(第15章の共通の評価軸と同じものです)。
- 対象範囲の割合 ― 自動処理できた件数の割合
- 確認を含む所要時間 ― 実際の削減効果
- 1件あたりの費用 ― 件数増加時の見通し
- 例外の発生率 ― 運用の安定度
- 人による修正の割合 ― 品質の実測値
これに加えて、四半期または半年に1回、直せる人の数を確認します。事業継続の指標です(第10章)。
レポートの作り方
- 推移で示す ― 単月の数値ではなく、時系列で並べます。
- 成果と条件を同じ行に置く ― 「処理時間40%短縮(対象:全体の3割)」(第15章)。
- 変更の履歴を併記する ― モデル更新、プロンプト変更、参照データの更新をタイムラインに載せます。数値の変化と対応付けられます。
- 1ページに収める ― 詳細は付録に置きます。
3番目が実務では効きます。数値の変化と変更の履歴が同じ図の上にあると、原因の推定が容易になります。
改善サイクルの回し方
本章の内容を、1つのサイクルとして整理します。頻度は月1回で十分です。
- 測る ― 検証セットの結果、修正率、利用率、費用(自動取得)
- 見る ― 月次で5項目を推移として確認する
- 拾う ― 要望と修正の内容から、改善の候補を挙げる
- 変える ― 一度に1つだけ変更する(第14章)
- 確かめる ― 検証セットを流し、他の項目への影響を見る
- 戻す ― 結果を要望の記録と報告に反映する
4番目の「一度に1つだけ」が守られないと、どの変更が効いたか分からなくなります。改善が偶然に依存するようになります。
朝凪精機のカスタマーサポート課は、二年目の四月から汀システムの回答案づくりを使い、回答案を「AI案」と「担当者確認」の2列で記録していましたが、担当者が手を入れた割合を月ごとに集計する人はいませんでした。一月二十八日、課長の村瀬から「回答案の口調が変わった」と連絡が入ります。指示文も手順書も変えていません。情報システム課の森が2列を突き合わせると、修正率は十月から一月前半まで22〜25%、一月後半に41%で、汀システムの上流のモデルが更新された一月中旬と重なりました。人による修正の割合を月次で見ていれば、課長に言われる前に気づけたはずの変化でした。二月分から、修正率をAI推進室の月次報告に入れ、モデル更新の履歴を同じ図に載せる運用に変えました。
この場面は網羅物語之巻 第11章「テストは本番で」に出てきます。
やめる判断も改善の一部
最後に、続けないという判断について触れます。改善のサイクルには、止める選択肢が含まれている必要があります。
止めることを検討する条件を、あらかじめ決めておきます。
- 利用率が一定水準を下回り、回復しない
- 確認を含む所要時間が、導入前を上回っている
- 1件あたりの費用が、業務価値を上回っている
- 直せる人が社内にいなくなった
- 業務そのものが変わり、対象が消えた
これらに該当した場合、止める、または設計を見直します。使われていない仕組みを維持し続けることは、管理対象を増やすだけです。止めた記録を残せば、次の判断の材料になります(第15章)。