導入後に何も起きない状態
稼働してから半年、誰からも苦情が来ていない。それは順調に動いている証拠にも、誰も見ていない証拠にもなります。この2つを区別する方法を扱います。
この型の特徴は、問題が発生しないことです。障害が起きるわけではなく、精度が急に落ちるわけでもありません。徐々に効果が薄れ、いつの間にか使われなくなる。そして誰も気づかないまま維持費だけが発生します。
だから対処も、問題への対応ではなく気づける仕組みを置くことになります。
型1 ― 精度モニタリングをしないまま放置する
表の網羅版 第13章「AIシステムのアーキテクチャ設計」・網羅版 第14章「テスト・品質保証」で扱ったとおり、AIを含む仕組みではコードを変えていないのに品質が変わることがあります。変化の原因は、モデルの更新、参照データの変化、入力データの傾向の変化、プロンプトの調整、設定値の変更。
これらのいずれが起きても、稼働状況の監視では検知できません。検知できるのは検証セットの定期実行だけです。
放置される理由
実装は大きなものではありません。検証セットとスクリプト1本で成立します。それにもかかわらず行われない理由を挙げます。
| 理由 | 対処 |
|---|---|
| 検証セットがない | 実データ50件から作り始める。数日で足りる |
| 納品物に含まれていない | 受け入れ条件に含める(第14章)。既存の案件では作り直す |
| 必要性が伝わっていない | 「動いているのに何を確認するのか」への説明を用意する |
| 担当者が決まっていない | 運用の役割を4役割の1つとして明示する(表の網羅版 第8章「組織・人材・チェンジマネジメント」) |
| 結果を見る場がない | 月次の確認項目に加える |
4番目が根本的です。稼働後の運用が誰の仕事でもない状態では、どの仕組みも置かれません。導入の担当者が次の案件に移り、運用の担当が決まっていない状態は頻繁に起こります。
型2 ― フィードバックループを作らない
利用者の反応を改善に結びつける仕組みがない状態です。表の第24章で示したとおり、最も価値が高いのは人が修正した内容です。これはそのまま検証セットに追加できる材料になります。
この仕組みがない場合、次のことが起きます。
- 誤りの実例が蓄積されない(検証セットの品質が上がらない)
- 改善の候補が挙がらない
- 利用者が「言っても変わらない」と判断し、要望が上がらなくなる
- 利用率の低下が「慣れの問題」として処理される(第15章)
要望が上がらなくなる構造
この点は第8章でも扱いました。要望への結果を報告者に返さないと、要望が上がらなくなります。報告しても何も起きないという経験が、報告を止めます。
対処は表の第24章に示した5段階です。
- 要望を記録する場所を作る
- 対応・保留・不可に分類し、理由を1行書く
- 対応するものは変更の対象を特定する(プロンプト・参照データ・確認工程・モデル・業務手順のどれか)
- 変更後に検証セットを流す
- 結果を要望の記録に戻す
5番目が省かれやすく、しかも省くと1番目から4番目が機能しなくなります。
型3 ― 利用状況の可視化を怠る
使われているかどうかが把握されない状態です。とくに利用者1人あたりの月額で課金される形式では、利用の有無に関わらず費用が発生します(表の網羅版 第3章「主要AIサービス・モデルの比較」)。
全社導入したものの利用率が1割という状態は、費用面で最も不利な形になります。それにもかかわらず把握されない理由は、測る仕組みが導入時に決められていないことです。
確認すべき数字は表の第24章の5項目です。
- 対象範囲の割合(自動処理できた件数の割合)
- 確認を含む所要時間
- 1件あたりの費用
- 例外の発生率
- 人による修正の割合(品質の実測値)
加えて四半期または半年に1回、直せる人の数を確認します。事業継続の指標です(第10章)。
稼働から6か月以上経過している仕組みについて、次の3点が答えられない場合、その仕組みは実質的に放置されています。(1) 現在の利用率。(2) 人による修正の割合。(3) 直せる人の数。この3点は測定の仕組みがあれば即答でき、なければ調査が必要になります。調査が必要な状態であること自体が、モニタリングの不在を示します。
型4 ― モデル更新への追随を行わない
提供元によるモデルの更新は、障害より高い頻度で発生します。この変化への対応が決まっていない状態です。
表の第24章に手順があります。省かれやすい点を挙げます。
- 更新情報を受け取る担当が決まっていない ― 個人のメールに届いて終わる。
- 影響範囲が把握されていない ― どの処理がどのモデルを使っているかの一覧がない。
- 検証の手順が決まっていない ― 更新のたびに手順を考えることになる。
- プロンプトの調整を試さない ― モデルによって効く指示が違うため、悪化の原因がプロンプトの不適合である場合が少なくありません。
4番目は表の第24章で強調されている点です。新しいモデルで性能が出ないとき、原因がモデルの性能ではなくプロンプトの不適合であることがあります。調整を試さずに「新モデルは使えない」と判断すると、選択肢を狭めます。
型5 ― やめる判断をしない
使われなくなった仕組みが、止められないまま維持される状態です。表の第24章で述べたとおり、改善のサイクルには止める選択肢が含まれている必要があります。
止めることを検討する条件を、あらかじめ決めておきます。
- 利用率が一定水準を下回り、回復しない
- 確認を含む所要時間が、導入前を上回っている
- 1件あたりの費用が、業務価値を上回っている
- 直せる人が社内にいなくなった
- 業務そのものが変わり、対象が消えた
これらに該当した場合、止めるか設計を見直します。使われていない仕組みを維持し続けることは、管理対象を増やすだけです。加えて、止めた記録を残せば次の判断の材料になります(第8章)。
止められない理由が組織的なものである場合(導入を推進した担当者の立場、経営層への報告済みの成果)、その構造自体が第9章・第15章で扱った問題です。着手前に中止条件を決めておくことが、この状況を避ける唯一の方法です。
朝凪精機の営業部と購買課は、二年前から翻訳サービスを40人分契約していました。人数分の契約なので費用は一定で、障害の記録も苦情もありません。二年目の二月、AI推進室が月次報告に「利用の状況」の層を足すために契約の一覧を洗うと、直近3か月で月に一度でも使った人は7人でした。契約数の2割に届きません。使わない理由を聞くと、ほとんどが「使う場面がなくなった」でした。常務の大槻に「問題が起きていないものまで数えるのか」と聞かれ、室長代理の瀬尾は、問題が起きていないから数えないと分からないのだと答えています。次の更新で契約数を実利用に合わせて見直すことにし、年間の費用は大きく下がる見込みです。この2年間、問題は一度も発生していませんでした。
この場面は網羅物語之巻 第11章「テストは本番で」に出てきます。
放置を防ぐ最小構成
本章の型は、次の4つで防げます。表の第24章の内容と同じです。
- 検証セット(実データと期待出力の組)
- 定期実行と結果の記録(週1回または月1回)
- 人による修正の記録(品質の実測値)
- 運用の担当者(4役割の1つとして明示)
4番目がなければ、他の3つは置かれても維持されません。稼働後の運用を誰の仕事にするかを決めることが、この章の対処の起点です。