AIが古い答えを返すとき、直すのはAIではありません──入れたあとに効果を測る話
社内でAIを使えるようにしたが、効果があったのか説明できない。
AIに聞いても、古い情報を答えてくる。
「AIで効率化しました」と報告したが、次に何を聞かれるか怖い。
業務改善の効果測定シリーズ、第3回（最終回）です。
第1回では、測るものには管理項目（目標に対してどうなっているか）と点検項目（自分たちで動かせる原因）の2種類がある、という話を書きました。第2回では、その測り方を扱いました。
今回は、AIを使った改善に同じ考え方を当てます。
先に結論です。AIを入れても、測るものは変わりません。 変わるのは、点検項目の中身だけです。
そして、その点検項目を探すときは、AIそのものより先に、周辺を見た方がいいと思っています。
社内の資料をAIに読ませたら、古い答えが返ってきた
実際にやったことから書きます。
会社の社内資料をAIに読ませて、質問に答えられるようにしました。いわゆるRAGと呼ばれる仕組みです。
簡単に説明します。質問が来たときに、関連する社内文書を検索して取り出し、その中身を根拠にして回答を組み立てる仕組みです。AIが社内資料を丸ごと覚えているわけではありません。質問のたびに探して、読んで、答えていると考えると近いです。
⚠️ 何を参照できるかは、契約しているプラン・接続の設定・管理者の設定・その人のアクセス権限によって変わります。「AIを入れれば社内資料を読んでくれる」という単純な話ではありません。導入前に、この4点は確認してください。
さて、動かしてみると、問題が出ました。
最新の仕様が反映されておらず、古い答えを返していたのです。
このケースでは、AIが勝手なことを言っていたわけではありませんでした。読ませた資料が古かったのです。古い資料を根拠にすれば、古い答えが出ます。当たり前といえば当たり前です。
たとえば、こういうことが起きました
あるサービスで、配送の拠点を複数立ち上げたことがありました。
最初は、東と西のエリアで配送を分ける形で作りました。ところが運用してみると、契約上の配送数に届きません。そこで、エリアではなく、サービスの種類ごとに分けて配送するやり方へ切り替えました。
切り替えそのものは、きちんと実装されました。古いまま残ったのは、資料の方です。
その結果どうなったか。「この人はどこから申し込んだから、いつ届く」という案内が、ずれます。
そしてここが大事なところです。ずれていたのは、AIだけではありませんでした。 同じ資料を見ていたサポートの担当者も、同じように誤認していました。
つまり、AIを入れる前から、間違いは起きていたわけです。AIを入れたことで、それが表に出ました。
直したのは、AIではなく資料でした
ここで手を入れたのは、AIの設定ではありませんでした。
まず、そもそもの資料が最新かどうかを確かめました。ここは、更新日を見るだけでは分かりません。担当者に直接聞いています。
そのうえで、実際に動いているプログラムや、ホームページに載っている情報と照らし合わせて、おかしなところを直していきました。
地味な作業です。ですが、これで回答の精度が上がりました。
第1回の言葉に置き換えると、こうなります。
管理項目（結果として見るもの） … 回答の精度、満足度、利用された回数
点検項目（自分たちで動かせる原因） … 元になる資料が最新か、実物と食い違っていないか
点検項目の側が本体です。 AIの回答は、読ませている資料の状態にかなり左右されます。そして資料は、自分たちで直せます。 第1回で挙げた点検項目の4条件を、きれいに満たします。
ただし、「資料さえ整えれば良くなる」とまでは言えません。検索の精度、権限の設定、文書の分け方、指示の出し方、使っているモデル。関係するものは他にもあります。資料の更新日は「効く点検項目のひとつ」であって、それだけではありません。
指標は、段階的に上げていきました
もうひとつ、やり方の話を書きます。
最初から完成形の目標を置きませんでした。まずトライアルとして動かし、そこで指標を決めました。 そして、その指標に届いたら、次の段階の指標を決める。この繰り返しです。
これは、第1回で引用した規格の考え方と同じでした。
管理水準は……（実施計画の進行に応じて段階的に変わっていかなければならない）．
——JSQC-Std 33-001:2016『方針管理の指針』
線は、一度引いたら終わりではありません。 届いたら引き直す。届かなければ、なぜ届かないかを見る。
AIを入れるときは、これが特に効くと思っています。最初は、どのくらいの精度が出るのか誰にも分かりません。分からないまま高い目標を置くと、達成できずに「失敗した」ことになります。 逆に低すぎると、いつまでも次に進みません。
段階を刻めば、そのどちらも避けられます。
効果は、満足度と利用数で確かめました
効果の確認には、定期的な満足度調査を入れました。そして、実際に使われた回数も見ています。
調査は自由記述です。役に立っているか、満足しているか。それに加えて、改善の要望と、「仕様が違う」という指摘も書けるようにしています。
この最後のひとつが、思わぬ働きをしました。満足度を聞く場所が、資料の誤りを見つける入口にもなっています。
結果として、満足度も利用数も、上向きの傾向を確認できました。
具体的な数値は社外に出せないため、ここでは書きません。数字を出せない以上、成果を大きく見せる書き方もしません。
ただ、この2つを組み合わせたことには意味がありました。
満足度だけでは、使っていない人の声が入りません。 利用数だけでは、役に立ったかどうかが分かりません。片方だけを見ていたら、たぶん判断を誤っていました。
「精度が上がった」を、どう判断したか
数字だけでは分からないので、2つのやり方で確かめました。
ひとつは、満足度調査の自由記述です。「こういうケースで役に立った」「探す手間が減った」といったコメントが出てきました。どんな場面で効いたのかは、点数ではなく言葉の方に出ます。
もうひとつは、同じ質問をもう一度投げてみることです。資料を直したあとに、以前おかしな答えを返した質問をぶつけ直します。
ここで、合格の条件を先に決めておきます。 さきほどの配送の例なら、「切り替えたあとの、拠点ごとの配送の仕様を正しく答えるか」です。古い分け方が出てきたら、まだ直っていません。
そして、誰が確かめるかも決めています。
その仕様を考えた人たちに、テストしてもらっています。 正解を知っているのは、その人たちだからです。私自身は、物流まわりの質問について、答えが合っているかを見ています。
第1回で、基準を決める場にはその業務を実際にやっている人を入れると書きました。AIの答えが合っているかどうかも、同じです。 正解を知らない人が「それっぽいから合格」と判断してしまうと、確かめたことになりません。
そして、いちばん実感があったのはこれです。自分たち自身が、資料を探さなくなりました。
以前は、聞かれるたびに資料を開いて探していました。いまは、その手前で答えが出ます。作った側が使うようになったかどうかは、けっこう正直な指標だと思っています。
まだ残っている課題
正直に書いておくと、解決していないこともあります。
PowerPointやExcelで作った資料です。読み取りにくい理由は、いくつかありました。
図やフローチャートの書き方が統一されていない
同じ資料の中でも粒度が違う（細かい手順と、ざっくりした概要が混ざっている）
画像を貼っている（文字が絵になっていて、そもそも読めない）
最後がいちばん厄介です。人が見れば読めますが、文章としては存在していないからです。
いまは、MarkdownやHTMLの形に変換できないかを模索しています。変換自体をAIにやらせる手も含めて、試している最中です。
ここは、まだ答えが出ていません。
手直しが多かったのは、AIのせいではありませんでした
運用していて、いちばん手直しが必要だったところを書きます。
人が作った資料に埋もれていた、仕様の誤りでした。
AIが変な答えを返す。調べる。元の資料をたどる。すると、そもそも資料に書いてあることが間違っている。しかも、誰も気づかないまま何年も残っている。そういうものが出てきます。
AIを入れたことで見つかった、とも言えます。それまでは、誰もその資料を端から端まで読んでいなかったわけですから。
誤りの見つけ方
2つやっています。
ひとつは、さきほど書いた実物との照合です。動いているプログラムや、公開されている情報と突き合わせる。
もうひとつが、関係者での認識合わせです。
これにはコツがあります。忙しいと、見てもらえません。
「時間があるときに確認しておいてください」で渡した資料は、まず確認されません。悪気があるわけではなく、単に優先度が下がるだけです。
だから、ちゃんと時間を取ったうえで確認してもらいます。 集まる場を作る。その場で見てもらう。
第1回で、基準は決めるより握る方が大変だと書きました。資料の正しさも同じです。「合っていますか」と聞くだけでは、合っているかどうか分かりません。
問い合わせが減ったことを、成果にしてはいけません
ここは、経験というより注意点です。
AIやFAQを入れると、問い合わせの件数が減ることがあります。ですが、件数の減少だけを成果として報告するのは危険です。
考えられる理由が2つあるからです。
解決したから、聞く必要がなくなった（狙いどおり）
聞くのをやめた（悪化）
2番は実際に起こります。的外れな答えが続くと、人は「使えない」と判断して、そもそも使わなくなります。窓口を通さず、隣の人に直接聞くようになるだけです。
このとき、数字はきれいに下がります。そして実態は、何も良くなっていません。
私が満足度と利用数の両方を見ているのは、これが理由です。利用数が増えていれば、少なくとも全体として利用が細っている状態ではないと分かります。
第1回で書いた「件数をゼロにすることを目標にしない」は、まさにこの場面の話です。
よくある失敗
導入前を測っていない → 「速くなった気がする」しか言えません
件数の減少だけを見る → 使うのをやめただけ、を見逃します
誤った回答を測っていない → 速さと引き換えに正確さを失っても気づきません
資料の更新を止める → 数か月後には、古い答えを返す仕組みになります
AIの設定ばかり触る → 読ませている資料の側に原因が見つかることがあります
削減時間の試算を、実測のように出す → 一度ずれると、それ以降の数字が全部疑われます
最後のひとつだけ、補足します。
AI導入の効果として、削減できた時間を積み上げて報告することがあります。「1件5分 × 100件 = 500分」のような形です。提案のときには分かりやすい数字です。
ただ、これは試算です。試算なら「試算」と書く。実測なら、どう測ったかを書く。 分けて出すだけで、報告の信頼度は変わります。
3回のまとめ
この連載で言いたかったことは、結局2つです。
ひとつ。測るものは2種類ある。
目標に対してどうなっているかを見るもの（管理項目）と、自分たちで動かせる原因を見るもの（点検項目）。この2つを分けるだけで、報告の質が変わります。
もうひとつ。改善に手をつける前に、いまの数字を測っておく。
比べる相手がなければ、どんな改善も証明できません。これが、いちばん取り返しのつかない失敗です。
AIを使うかどうかは、実は本質ではありませんでした。
社内資料をAIに読ませても、結局やったことは資料を最新にすることでした。効果を確かめる方法も、満足度と利用数を見るという、昔からあるやり方でした。
手段が変わっても、測り方の考え方は変わらない。 3回書いてみての結論です。
FAQ
Q. AIが間違えるのは、AIの性能のせいではないのですか？
A. その場合もあります。ただ、社内の情報について答えさせるときは、読ませている資料が古い・間違っている可能性を、まず疑う価値があります。
Q. RAGを入れれば、社内の質問には全部答えられますか？
A. いいえ。参照できる範囲は、契約プラン・接続設定・管理者の設定・アクセス権限に左右されます。元の資料が古ければ、古い答えが返ります。
Q. 効果は何で測ればいいですか？
A. 満足度と利用数の両方を見ることをおすすめします。満足度だけでは使っていない人の声が入らず、利用数だけでは役に立ったかが分かりません。
Q. 削減時間を報告に使ってもいいですか？
A. 使えます。ただし「試算」と明記してください。実測値と混ぜないことが条件です。
Q. 最初の目標は、どのくらいに置けばいいですか？
A. 高すぎると達成できず「失敗」になり、低すぎると次に進めません。まずトライアルで動かして、そこから決めるのが現実的です。届いたら、次の段階を決めてください。
おわりに
AIを入れると、効果を大きく見せたくなります。実際、見せられてしまいます。
ですが、盛った数字は一度でも実態とずれると、それ以降の報告が全部疑われます。改善を任された人にとって、これがいちばん高くつきます。
測るものを2つ決めて、始める前の数字を残しておく。地味ですが、これが結局いちばん強いと思っています。
そして、AIが変な答えを返したときは、AIを疑う前に、読ませている資料を見てください。 そこに原因が見つかることがあります。しかもそこは、自分たちで直せます。
3回にわたってお付き合いいただき、ありがとうございました。
最後に、この記事を読んで「うちの場合はどうか」と思われた方へ。
AIを入れる前後で、こういうところからお手伝いできます。
AIに読ませる前の、資料の点検（どれが古いか、実物と食い違っていないか）
管理項目と点検項目の整理（何を結果として見て、何を原因として見張るか）
効果の測り方の設計（満足度・利用数・誤った回答を、どう取るか）
入れる前の業務の棚卸し（そもそもAIに任せる範囲はどこまでか）
いきなり全部でなくて構いません。 1つの業務について、管理項目と点検項目を1行ずつ決めるところからでも進められます。
参考にした資料（無料で読めます）
管理項目・管理水準・点検項目の定義 … 日本品質管理学会『品質管理用語』（JSQC-Std 00-001:2023）
管理水準が段階的に変わること … 同『方針管理の指針』（JSQC-Std 33-001）のサンプル
あわせて読みたい（業務改善・効果測定の記事）
ママゴトラボは、業務の自動化ツールを要件定義から設計してつくる開発ラボです。
属人化した業務の見える化から、自動化ツールの開発・保守まで承っています。
👉 ママゴトラボ｜業務自動化の開発ラボ
