AIの精度が落ちる原因と気づく仕組み｜静かな劣化に備える

「半年前に入れたときは、ちゃんと振り分けられていたんです」「エラーは1件も出ていないのに、営業から最近おかしいと言われました」——AIを業務に組み込んだ部署から、しばらく経ってから出てくる声です。これは故障ではありません。総務省と経済産業省が2026年3月31日に公表したAI事業者ガイドライン第1.2版は、予測性能と出力の品質が、活用開始後に大きく変動する可能性を明記したうえで、事後検証のための作業記録を保存しながら品質を維持・向上することを求めています。品質が動くことは想定外の事故ではなく、公的な指針が前提として書いている性質だということです。この記事では、稼働後に静かに落ちていく精度について、落ちる原因を4つに分け、落ちたことに気づくための仕組み、気づいた後の切り分けと戻し方まで整理します。

場面：半年後に「最近、振り分けがおかしい」と言われた

具体的な場面を1つ置いて、最後まで同じ題材で追います。産業機器を扱うメーカーのマーケ部門で、資料請求とウェビナー申込のフォームに届いた内容をAIに読ませ、どの製品分野の話か、検討がどの段階か、どの部署が受けるか、の3つを付けて営業へ渡す仕組みを入れました。月におよそ600件。導入した月は人が全件を目視し、付け直しが必要だったのは1割ほどでした。

半年後、営業から声が上がります。「最近、うちに来ないはずの案件が回ってくる」。マーケ側が管理画面を開いても、処理件数は月600件前後で変わらず、失敗した件数はゼロ、応答時間も導入時と同じでした。止まってもいないし、警告も出ていない。数字の上ではどこも壊れていません。

実際に起きていたのは、付け直しの割合が1割から3割に増えていたことでした。ところが、その割合はどこにも記録されていませんでした。営業が黙って直していたからです。気づくのが半年遅れた原因はAIの側ではなく、直したという事実を誰も数えていなかったことにあります。劣化そのものより、劣化が見えない構造のほうが問題だったわけです。

この記事では、この仕組みが半年で何をされたのかを原因の側から4つに分けて追い、そのうえで気づく仕組みを組み立てます。なお、本番に出してよいかを決めるまでの評価の作り方は、ここでは扱いません。出す前に決めた物差しを、出した後も同じ手順で当て続ける運用の話に絞ります。

静かな劣化は、止まる故障とは別物

落ちる、という言葉には2種類あります。1つは止まる故障で、接続が切れる、上限に当たる、処理が失敗して例外が返る。これは監視の仕組みが拾いやすく、たいてい当日中に気づきます。もう1つが、返ってきているのに中身が合っていない状態です。こちらは何も鳴りません。

静かな劣化がやっかいなのは、成功として記録されるからです。分類の仕組みなら、どの案件にも必ず何かの分野が付きます。付いた以上、処理は成功です。空欄が返ってくるほうが、実はまだ親切で、間違った値が自信ありげに埋まっているほうを、後工程は疑いません。ガイドライン第1.2版が安全性の項で「様々な状況下でパフォーマンスレベルを維持し、無関係な事象に対して著しく誤った判断を発生させないようにする」と書いているのは、この種の誤りを想定した言い回しです。

しかも劣化は段差ではなく傾斜で来ます。ある日を境に半分になるのではなく、1か月で数ポイントずつずれていきます。現場は毎日少しずつ直すので、直していること自体が日常の作業に溶けます。誰も異常だと思わないまま、1割が半年で3割になるのはこの経路です。

ですから、止まる故障を見る監視と、中身が合っているかを見る仕組みは、別に用意する必要があります。前者はシステム側が持ち、後者は業務側が持つのが現実的です。次の3つがそろっている状態は、劣化を外から知らされる状態だと考えてください。

• エラー率と応答時間だけを見て、正常だと報告している
• 現場が黙って直しているので、直した回数がどこにも残らない
• 気づくきっかけが、営業からの苦情や取引先からの指摘になっている

ガイドライン第1.2版が利用者側の事項として「AIシステム・サービスが想定された仕様に基づき適切に動作しているかを確認する」と明記しているのは、この確認を提供元任せにできないからです。提供元が知っているのは仕組みが動いたかどうかで、業務に合っているかどうかは使う側しか判定できません。

「活用開始後に品質は変動する」は公的な指針にも書かれている

品質が動くことを、日本の公的な指針は前提として書いています。AI事業者ガイドライン第1.2版は、AI開発者に対する事項として、予測性能と出力の品質が活用開始後に大きく変動する可能性、想定する精度に達しないこともある特性を挙げ、事後検証のための作業記録を保存しつつ品質の維持・向上を行うことを求めています。落ちないようにしろ、ではなく、落ちうる前提で記録を残せ、という書き方です。

同じ指針は、開発者が提供者へ伝えるべき情報として「AIの更新を行った場合の内容及びその理由の情報」を挙げ、提供者側の事項としては入出力と判断根拠を定期的に評価してモニタリングすることを挙げています。つまり更新は起きる前提で、起きたことを伝える経路と、受けて確かめる経路の両方を用意しろという組み立てになっています。片方だけでは機能しません。

別添の実践例には、より生々しい記述があります。顧客に出力のモニタリングを依頼するだけでは機能せず、メンテナンスが必要な理由とその原因、たとえば学習データと運用時の入力データの分布が変化することを、時間をかけて説明して納得してもらう必要がある、と書かれています。依頼で終わらせず、なぜ必要かを共有しないと運用は続かない、という現場の知見です。

ここから読み取れる実務の順番は明快です。仕組みを入れるときに、劣化するという前提を関係者で共有し、記録を残す設計を先に入れ、確かめる担当を決める。入れてから考えると、記録が無いので原因を特定できません。半年後に「いつから落ちたのか」に答えられるかどうかは、稼働の初日の設計で決まっています。

原因1：扱う中身が変わる

1つ目は、AIに入ってくる中身そのものが変わる場合です。冒頭の例では、半年のあいだに製品分野が1つ増え、展示会の出展テーマも入れ替わりました。フォームの自由記述に出てくる言葉が変わったのに、AIに与えた分野の一覧は導入時のままでした。新しい分野の問い合わせは、いちばん近い旧分野に吸い寄せられます。

この動きは、間違いというより仕様どおりの振る舞いです。選択肢に無いものは選べないので、残った選択肢の中から最も近いものが返ります。選択肢に無いことを「無い」と言わせる設計になっていないと、劣化は分類の偏りとして表に出ます。冒頭の例でも、新分野に隣接する旧分野の件数だけが半年で目立って伸びていて、これが最初の手掛かりになりました。

中身の変化には、季節や商談期による揺れも混じります。年度末に問い合わせが増える、キャンペーン期間だけ短い文章が増える。揺れと劣化を区別できないと、対処が空振りします。区別の目安は戻るかどうかで、揺れは翌月に戻り、劣化は戻りません。判断のために、前年の同じ月を並べて置くと迷いが減ります。

対処は、分野の一覧を見直す担当を決めることに尽きます。製品が増えた、展示会のテーマが変わった、料金の体系が変わった。事業側の変更をAIの設定へ反映する経路を、あらかじめ作っておく。これは技術の話ではなく、変更を知っている人と設定を触る人がつながっているかどうかの話です。つながっていない組織では、この原因が繰り返し起きます。

原因2：モデルが黙って更新される

2つ目は、AI自身が入れ替わる場合です。同じ名前のサービスを使い続けていても、中身の版は変わります。2023年3月版と6月版の同一サービスを比べた研究では、上位モデルで素数か合成数かを判定させる正答率が84%から51.1%へ下がり、そのまま実行できるコードの割合は52%から10%へ、意見調査への回答率は97.6%から22.1%へ落ちました。応答の長さも638.3文字から3.9文字へ短くなっています。

ただし読み方には注意が必要です。同じ研究で、下位モデルの素数判定は49.6%から76.2%へ上がっています。更新は一律の悪化ではなく、用途ごとに上下するというのが正確な理解です。著者らは、同じ名前のサービスの振る舞いが比較的短い期間で大きく変わりうるため、継続的な監視が要ると結論づけています。自社の用途でどちらに動いたかは、自社で測るしかありません。

更新は自動で降ってくることがあります。マイクロソフトのクラウド上で生成AIを使う基盤の公式文書（2026年7月24日更新）では、一般提供の版は公開時点で18か月後の提供終了日が設定され、公開から12か月で新規の利用者には開かれなくなり、提供終了の少なくとも60日前に通知が届く、と説明されています。試験提供の版は少なくとも30日前です。

押さえるべきは、標準的な配置では期限が来ると自動で後継の版へ上げ替えられる点です。同じ文書は上げ替えの動きを3つから選べるとしていて、新しい既定版が出たら上げる、期限が来たら上げる、自動では上げない、のいずれかを指定します。既定のまま使っていると、通知を受け取る人がいない限り、ある日から別の版で動きます。確保済みの容量で動かしている場合は自動では上がらず、手で移す必要があるとも書かれています。

だから運用側で決めることは2つに絞れます。版を固定するかどうか、そして通知の宛先を誰にするか。通知は契約の管理者に届くので、実際に品質を見ている担当まで転送される経路を作っておかないと、60日の猶予が誰にも使われないまま過ぎます。冒頭の例でも、通知は情報システム部門の共有メールに届いていて、マーケ部門は見ていませんでした。

原因3：参照している資料が古びる

3つ目は、AIが答えを作るときに参照している社内資料が古くなる場合です。冒頭の例では、分野を判定するために製品一覧の資料を参照させていました。半年のあいだに廃番が2つ出て、新製品が1つ増えたのに、参照先の資料は差し替えられていませんでした。判定に使われていたのは、半年前の製品構成です。

このときAIの側は正しく動いています。古い資料を正確に読んで、古い答えを返しているだけです。AI事業者ガイドライン第1.2版は、AIモデルを構成する技術要素として、学習データや利用者が入力する内容と並べて「AIモデルの推論時に参照する情報、連携する外部サービス等」を挙げています。参照先は仕組みの一部であって、外に置いてある資料置き場ではない、という位置づけです。

古びは3つの形で起きます。中身が更新されないまま残る、更新はされたのに古い版も同じ場所に残っている、そして参照先そのものが移動して読めなくなる。2つ目がいちばん厄介で、新旧が同居していると、AIは両方を読んで混ぜた答えを返します。読めなくなった場合はすぐ気づけますが、混ざった場合は静かに間違い続けます。

対処は、資料の側に日付を持たせることです。参照させる資料の冒頭に、いつ時点の情報かを機械が読める形で入れ、一定の期間を過ぎた資料は参照先から外す運用にします。そのうえで、答えに使った資料の名前と日付を出力に添えさせます。ガイドラインが利用者に求めている「最新性が担保されたデータの入力」は、入口だけでなく参照先にも当てはまると考えてください。

なお、AI自身が学習した知識に切れ目があることと、参照させている資料が古びることは、別の問題です。前者は使っているサービス側の性質で、後者は自社の手で直せる範囲にあります。同じ「古い答えが返る」でも、打てる手がまったく違うので、混ぜずに切り分けてください。ここで扱っているのは後者です。

原因4：使う人が増えて、聞き方が変わる

4つ目は、AIではなく人の側が変わる場合です。冒頭の例では、途中でフォームの項目を1つ減らし、自由記述を必須から任意へ変えました。入力の途中離脱を減らすための改善でしたが、結果としてAIに渡る文章の量が半分近くまで減りました。判定の材料が減れば、判定は粗くなります。

社内で使う道具でも同じことが起きます。最初は詳しい担当者が数人で使い、丁寧な指示を書いていた。半年後には部署全体が使い、短い指示が増えた。AI事業者ガイドライン第1.2版の別添には、この現象が実践例として載っていて、開発時に想定した利用者像と実際の利用者像に違いが生じてきた場合には、精度と公平性の確保のためにメンテナンスが必要だと開発担当者から言われた、という企業の証言が引かれています。

この原因が見落とされやすいのは、変えた側に悪気がないどころか、事業としては正しい改善である場合が多いからです。フォームを短くするのも、使える人を増やすのも、施策としては前進です。正しい変更が、離れた場所の品質を下げる。だから変更した人は、自分が原因だとは考えません。

対処は、AIに入る手前の変更を「変更」として扱うことです。フォームの項目、入力欄の必須の有無、利用できる部署の範囲。これらを変えるときに、AIの担当へ一言通す決まりを置きます。止める決まりではなく、知らせる決まりで十分です。あわせて、次の3つを改善の効果測定に混ぜておくと、後から突き合わせられます。

• 変更の前後で、入力の平均文字数と空欄率を比べておく
• 利用部署を広げるときは、広げた週の付け直し率を別に数えておく
• 改善の効果を測る指標に、AI側の指標を必ず1つ混ぜておく

4つの原因と、表に出る症状を1枚で見る

ここまでの4つを並べます。見てほしいのは、症状の列と確かめ方の列です。原因が違えば、症状の出る場所も、確かめる手順も違います。「精度が落ちた」という1つの言葉でまとめて調べようとすると、どこから手を付けるかが決まらないまま時間だけが過ぎます。

原因	起きていること	表に出る症状	確かめ方
扱う中身が変わる	新しい種類が増えたのに、選択肢が導入時のまま	特定の分類だけ件数が伸び続ける	分類ごとの件数を月ごとに並べる
モデルが更新される	版が入れ替わり、振る舞いが変わる	ある週を境に出力の傾向が変わる	版の変更日と、付け直し率の立ち上がりを突き合わせる
参照資料が古びる	廃番や旧版を正確に読んで答えている	存在しない選択肢や古い名称が混じる	答えに添えさせた資料名と日付を見る
使い方が変わる	入力が短くなる、書き手の層が広がる	判断できないと返す割合や中間の判定が増える	入力の平均文字数と空欄率を並べる

表を見ると、症状の列がどれも正常系の数字には出ないことが分かります。件数、成功率、応答時間はどれも変わりません。見る場所を変えないかぎり、静かな劣化は見えないままです。逆に言えば、この4行を月に1度ずつ見るだけで、原因の当たりはかなり絞れます。

もう1つ、表に入れなかった原因にも触れておきます。AIが出した結果を、そのまま次の学習の材料に戻している場合です。ガイドライン第1.2版の別添は、これを自分自身の誤りを繰り返し学習して誤りが蓄積し、性能が徐々に劣化していく現象として説明しています。生成した文章を確認せずに社内の資料へ戻している運用は、これに近い形になります。

気づく仕組み1：人が直した割合を数える

気づく仕組みは、増やす前に1つに絞ります。最初に置くのは人が直した割合です。AIが付けた値を、後工程の人が変更した件数で割ります。冒頭の例なら、営業が担当部署や分野を付け替えた回数を、その月の全件で割った数字です。

この指標が強い理由は3つあります。品質の定義を新しく作らなくてよいこと、現場がすでに行っている動作をそのまま数えられること、そして集計より先に人の手が動くことです。人は違和感を持った瞬間に直すので、どの指標よりも早く反応します。冒頭の例でも、営業は3か月目にはすでに直していました。

実装で必要なのは、直した事実を残すことだけです。上書きする前の値、上書きした後の値、直した人、直した日時。この4つがあれば十分です。直された記録が残らない仕組みは、劣化を測れない仕組みでもあります。逆に、この4つさえ残っていれば、後から遡って立ち上がりの週を特定できます。

数え方は単純でよく、週ごとの割合を並べます。絶対値ではなく、前の週からの動きを見ます。1割が高いか低いかは業務によって違うので、他社の水準と比べても意味がありません。導入直後に下がり、しばらく横ばいで、そこから静かに上がる。上がり始めた週が、原因を探しに行く起点です。

注意点も1つあります。直した割合は、直す人が変わっても動きます。担当が代わって基準が厳しくなっただけで上がることがあるので、上がったら人の側の変化も候補に入れて確かめます。誰が直したかを残しておく理由の半分は、これを切り分けるためです。

気づく仕組み2：出力そのものの形を見る

2つ目は、出力の中身を読まずに、形だけを見る方法です。分類の仕組みなら、分類ごとの件数の割合。文章を作る仕組みなら、文字数の分布。正解を用意しなくても取れる指標なので、運用の負担がほとんど増えません。

冒頭の例では、3つの分野のうち1つの割合が半年かけて伸び続けていました。この伸びに事業としての説明が付くかどうかは、マーケ側が答えられます。展示会でその分野を押した、広告を寄せた、といった心当たりが無ければ、選択肢の不足か参照資料の古びを疑う合図です。分布の変化は、原因の当たりを付ける最初の手掛かりになります。

もう1つ有効なのが、判断できないと返した割合です。AIに対して、材料が足りないときは判断できないと返してよいと明示していれば、この割合は入力の質を映します。入力が短くなれば上がり、選択肢が足りなければ下がります。上下どちらに動いても、動いたこと自体が信号になります。

出力の形を見るときの落とし穴は、平均だけを見ることです。平均文字数が同じでも、極端に短い出力と極端に長い出力が同じだけ増えていれば、中身は確実に変わっています。平均ではなく分布の端を見ます。上位1割と下位1割がどう動いたかを並べるだけで、平均では消えていた変化が見えます。

この指標は取り方を固定することが重要です。集計の期間、対象の絞り方、除外する条件を毎回変えると、変化なのか集計の違いなのかが判別できなくなります。取り方を書いた1枚を残し、担当が代わってもそのまま使えるようにしておきます。

気づく仕組み3：入口の変化と、外から来る変更の通知

3つ目は、AIに入る手前と、AIの外側で起きた変更をつかむ仕組みです。入口については、入力の平均文字数、空欄の割合、1件あたりの入力項目数を月ごとに並べます。入口が動いた月と、直した割合が上がった月が重なれば、原因は入口側と考えてほぼ外れません。

外側の変更は、通知を受け取る仕組みで拾います。契約している生成AIの版の変更、参照している社内資料の改訂、連携先の仕様変更。前述のとおり提供終了の通知は少なくとも60日前に届きますが、宛先は契約の管理者であって、品質を見ている担当ではありません。ここが切れていると、通知は届いているのに誰も動きません。

実務では、変更の記録を1つの台帳にまとめます。日付、変わったもの、変えた人、影響しそうな範囲の4列で足ります。AI事業者ガイドライン第1.2版の別添は、記録を検討するときの観点として、記録の目的、記録の精度、取得の頻度、時刻と保存期間と保存方法、記録の保護、開示する範囲を挙げています。記録は取ることが目的ではなく、後から突き合わせられる形にしておくことが目的です。

台帳が効くのは、劣化に気づいた後です。付け直し率が上がった週を見つけたら、その前後2週間の台帳を開く。変更が1件も無ければ、原因は緩やかな中身の変化に絞られます。逆に版の更新や資料の差し替えが記録されていれば、そこから順に確かめます。台帳の有無で、切り分けにかかる時間が桁で変わります。

別添の実践例には、コードを読める人が社内にいない企業が、開発者に依頼して入出力のログを自動で取れるようにしてもらい、モニタリングの仕方も教わって、チェックリストで管理している例が載っています。自社で読めないなら、読める形にしてもらう交渉を契約の段階でするという順番です。

誰が、いつ、何を見るか

指標を決めても、見る人と見る日が決まっていなければ運用になりません。冒頭の例で半年気づかなかったのは、指標が無かったからというより、見る日が無かったからです。手順として置くと、次の形に落ちます。

この手順の要点は、週の作業を1つに絞ったことです。週に5つ見る決まりは、経験上3週間で形骸化します。続く仕組みの密度は、週に1つ、月に3つ、四半期に1つくらいが上限だと考えてください。

見る人は、システムの担当ではなく業務側に置きます。付け直し率が上がったときに「これは業務として説明が付く伸びか」を判断できるのは、事業の事情を知っている人だけだからです。数字を取る役と、意味を判定する役を分けて、後者を業務側に置くのが安定します。

AIに判断させない範囲を、先に決める

劣化に備えるうえで、いちばん効くのは指標ではありません。AIに判断させない範囲を、稼働の前に決めておくことです。範囲が決まっていれば、劣化が起きても被害の大きさは範囲の内側に収まります。決まっていなければ、劣化の影響は際限なく広がります。

冒頭の例では、分野と検討段階はAIが付けるが、取引先への連絡はAIの判定だけでは行わないと決めていました。だから半年ずれていても、社内の振り分けが乱れただけで済みました。取り消せない動作、社外に出る動作、金額が動く動作は、劣化の有無にかかわらず人を挟みます。ここは自動化の度合いを上げても最後まで残す線です。

根拠を書かせることも、稼働前に決めます。ただし、ここには誤解が多い。AI事業者ガイドライン第1.2版の別添は、大規模言語モデルについて、結果とその根拠を出力させることはできるが、内部の決定ロジックを説明しているわけではなく、結果と根拠のもっともらしい組み合わせを出しているにすぎないため、従来型のAIの説明可能性とは別に検討すべきだと注意しています。

この注意を運用に落とすと、根拠は「なぜそう判断したかの説明」としてではなく、確かめに行くための手掛かりとして使うことになります。参照した資料の名前と日付、根拠にした文言の抜き出し。人が5秒で裏を取れる形で書かせることが、根拠を出させる目的です。もっともらしい理由文だけを書かせても、劣化の検知には使えません。

人が確認する範囲も、先に狭く決めます。全件を見る決まりは必ず崩れるので、見る件を絞ります。冒頭の例では、判断できないと返した件、金額が一定を超える件、初回取引の件の3つに絞り、月におよそ40件、確認は1時間で終わる形にしました。

• AIの判定だけでは社外に出さない範囲を、稼働前に文書化する
• 根拠は、参照した資料の名前と日付まで書かせる
• 人が見る件を「判断できない」「金額が大きい」「初回」の3つに絞る
• 劣化が見つかったときに、どこまで止めるかと、誰が止めてよいかを先に決めておく

気づいた後の切り分け：原因を1つずつ外す

付け直し率が上がった。ここから先は、原因を当てに行くのではなく安い順に外していくのが速い方法です。4つの原因は確かめる手間が大きく違うので、順番は決まっています。外から来た変更、参照資料、入口、扱う中身、の順です。なお、実行の記録を1行ずつ追う作業はここには含めません。業務側で取れる数字だけで、当たりは付きます。

最初に外から来た変更を見ます。版の更新、連携先の仕様変更、資料の差し替え。台帳に該当する日付があり、付け直し率の立ち上がりと重なれば、そこで止めて構いません。重ならない場合だけ次に進みます。所要は5分です。

次に参照資料です。直近で付け直された件を10件ほど開き、答えに添えられた資料の名前と日付を見ます。古い日付が並んでいれば参照先の問題です。この段階では資料の中身を読む必要はなく、日付を見るだけで判断できます。所要は15分程度に収まります。

3つ目が入口です。入力の平均文字数と空欄率を、立ち上がりの前後で比べます。変わっていれば、フォームの変更か、利用できる範囲の拡大が入っています。ここまでで3つ外れたら、残るのは扱う中身が緩やかに変わった場合で、分類ごとの件数の推移を数か月分並べれば形が見えます。

順番を守る理由は、後ろに行くほど確かめる手間が増えるからです。台帳は5分、資料の日付は15分、入口の数字は30分、中身の推移は半日。安い順に外すと、多くの場合は1時間以内に当たりが付きます。逆から始めると、半日かけて外れたときに気力が尽きます。

なお、原因は1つとは限りません。冒頭の例では、版の更新と分野の増加が2か月ずれて起きていました。1つ見つけても、立ち上がりが2回あるなら2つ探します。週ごとの折れ線を見て、段が何回あるかを先に数えておくと見落としません。

戻し方は3つ：版を固定する、人に戻す、止める

原因が絞れたら、直す前に戻す手を打ちます。直すには時間がかかり、そのあいだも仕組みは動き続けるからです。AI事業者ガイドライン第1.2版の別添は、危害が生じた場合の初動として、元に戻すことや代替の仕組みの利用による復旧、停止、ネットワークからの遮断を挙げています。順に見ていきます。

戻し方	使う場面	決めておくこと
版を固定する	更新の日と劣化の立ち上がりが重なる場合	前の版がいつまで使えるか。自動での上げ替えをどう止めるか
人に戻す	特定の分類や条件だけがずれている場合	どの単位で切り出せるか。戻したときに人が処理できる件数か
止める	社外に出る動作や取り消せない動作に届いている場合	誰が止めてよいか。止めたときの代替の手順は何か

1つ目の版の固定は、更新が原因のときの基本手です。前述の公式文書では、上げ替えの動きを3つから選べるので、確かめが終わるまでは自動では上げない設定に寄せるのが素直です。ただし、その版にも提供終了の期限がある点は忘れないでください。固定は時間を買う手であって、放置してよい状態ではありません。

2つ目の人に戻すは、全部を戻す必要がありません。冒頭の例なら、伸びている分野に該当する件だけを人の確認に回し、残りはAIのまま流しました。戻す範囲を分類の単位で切り出せるようにしておくと、全部を止めずに済みます。切り出せる設計にしておくかどうかは、稼働前に決めることです。

3つ目の止めるは、社外に出る動作や取り消せない動作につながっている場合の判断です。止めてよい人を稼働前に決めておくことが要点で、決まっていないと止めるかどうかの会議で半日が過ぎます。止めた後に何で代替するかも、あわせて書いておきます。

戻した後で直します。直したら、戻す前とまったく同じ物差しを、同じ手順で当てて確かめます。ここで新しい指標を作ると、良くなったのか物差しが変わったのかが分からなくなります。別添の実践例でも、出力を記録して品質の劣化を判断し、実際の状況も確認したうえで作り直しの必要性を報告する、という順序が示されています。判断の前に確認が入ることが要点です。

よくある質問

どのくらいの頻度で確かめればよいですか

仕事の重さで決めます。取り消せない動作につながっている仕組みは週に1度、社内の振り分けのように後から直せる仕組みは月に1度が現実的な下限です。ただし頻度より大事なのは、同じ物差しを同じ手順で当てることです。毎回見る場所が変わると、変化なのか見方の違いなのか判別できません。冒頭の例では、週に1つ、月に3つに固定しました。

精度が落ちたら、すぐに作り直したほうがよいですか

作り直す前に、原因を外す順番を通してください。4つの原因のうち3つは、作り直さずに直せます。選択肢を足す、参照資料を差し替える、入口の変更を戻す。作り直しが要るのは、扱う中身そのものが変わった場合に限られます。ガイドライン第1.2版の別添にも、出力から品質の劣化を判断し、実際の状況も確認したうえで作り直しの必要性を報告する、という実践例が載っています。

提供元が更新したかどうかは、利用者側で分かりますか

契約している基盤によります。前述の公式文書のように、版ごとの状態と提供終了の日付を機械が読める形で確認できるものもあれば、明示されないものもあります。分からない場合は自分の側で版の指定を残し、出力の傾向を定点で見るしかありません。ガイドライン第1.2版が、開発者から提供者へ伝える情報として更新の内容と理由を挙げているのは、この分からなさを契約と説明で埋めるためです。

小さく試している段階でも、記録は必要ですか

必要です。むしろ試している段階のほうが安く始められます。残すのは4つで、AIが出した値、人が直した後の値、直した人、直した日時。この4つが無いと、後から「いつから落ちたか」に答えられません。ガイドラインが求める事後検証のための作業記録も、出発点はここです。保存の期間や保護の程度は、扱う情報の性質に応じて後から詰めても間に合います。

まとめ

AIの精度は、壊れて落ちるのではなく、周りが動いて合わなくなります。原因は4つ。扱う中身が変わる、モデルが更新される、参照している資料が古びる、使う人と聞き方が変わる。どれも件数や成功率には出ないので、見る場所を変えないかぎり気づけません。

気づく仕組みは、週に1つから始めます。人が直した割合を数え、上がり始めた週を起点に、外から来た変更、参照資料、入口、中身の順で安い側から外す。戻す手は3つで、版を固定する、人に戻す、止める。直す前にまず戻す、が順番です。

そして、指標より先に決めておくものがあります。AIに判断させない範囲と、人が確認する件の絞り込みです。ここが決まっていれば、劣化しても被害の大きさは決まります。落ちない仕組みを作るのではなく、落ちたときに小さく済む仕組みを作る。稼働後の品質は、そう考えたほうが現実に合います。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。