使われなくなるAIの共通点4つと立て直し方

AI を使った業務システムを導入し、最初の1か月は社内の反応も良かった。ところが3か月後にログを見ると、使っているのは最初に声を上げた数人だけ——。受注開発の現場では、こうした相談が少なくありません。原因を「現場の意識が低い」で片づけると、同じことが次のシステムでも起こります。

利用が落ちる業務には、技術とは別のところに共通した構造があります。この記事では、定着しない業務に繰り返し現れる4つの共通点と、落ちた利用をどう捉え直して立て直すかを、中小企業の規模感に合わせて整理します。

「使われない」は導入2〜3か月目に表面化する

導入直後は、物珍しさと「試してみよう」という空気で利用が伸びます。この時期の利用回数は、業務上の必要性ではなく関心で動いているため、定着の指標にはなりません。

問題が見えるのは、関心が切れたあとです。目安として導入2〜3か月目に、次のような兆候が出ます。

• 利用者が、導入を推進した担当者とその近くの数人に収束する
• 使われる場面が、月末や繁忙期など「余裕のないとき」から先に消える
• 「結局 Excel に戻した」「前のやり方の方が早い」という声が雑談で出る

ここで大事なのは、AI の出力品質が下がったわけではないという点です。多くの場合、精度は導入時と変わっていません。変わったのは、現場が「使う理由」を見失ったことです。つまり落ちているのは性能ではなく、業務への組み込まれ方です。

共通点1・2：入口が遠い、確認の手間が逆転している

共通点1：業務の動線から外れた場所に入口がある

最も多いのがこれです。普段の作業は基幹システムや受発注画面の中で完結しているのに、AI 機能だけが別のブラウザタブ、別のログイン、別のチャットツールにある。すると「開く」という一手間が、使わない理由として十分な重さを持ちます。

たとえば次のような場面です。見積書のドラフト作成を AI に任せる仕組みを作ったが、営業担当は普段は販売管理画面を開いている。AI を使うには別タブで専用画面を開き、顧客名と条件を貼り直す必要がある。急ぎの案件では、過去の見積をコピーして直した方が早い。こうして「急ぎでないときだけ使うもの」に格下げされ、やがて開かれなくなります。

対処の方向は単純で、入口を業務側に寄せることです。既存画面にボタンを1つ足す、入力済みの情報を自動で渡す、結果を同じ画面に戻す。この3点が実現できているかどうかで、半年後の利用率は大きく変わります。開発費としては基幹システム側の改修が必要になるため、見積段階で 基幹システムとの連携箇所を詰めておくことが前提になります。

共通点2：出力の確認コストが、手でやるより高い

AI が作った文章や分類を、人が読んで正しいか確かめる作業を「確認コスト」と呼びます。このコストが、自分で最初から作る手間を上回った瞬間に、合理的な判断として使われなくなります。

確認コストが高くなりやすいのは、次のような出力です。

対処は、出力そのものを変えることです。根拠となった文書名や該当箇所を併記する、変更した部分をハイライトする、確信度が低いものに印を付ける。出力の正しさを上げるより、確かめやすさを上げる方が定着に効く場面は多くあります。

共通点3・4：例外の行き先がない、中身が古くなる

共通点3：うまくいかなかったときの行き先が決まっていない

AI が答えられない、または明らかに外した出力を返したとき、現場が次に何をすればよいかが決まっていないケースです。行き先がないと、人は「最初から AI を使わない」という安全策を取ります。1回の悪い体験が、その人の利用を止めるのに十分な理由になります。

設計として必要なのは、精度を上げることよりも「人に戻す条件」と戻した先を先に決めておくことです。どういう入力なら AI に任せ、どこから先は担当者に回すのか。この線引きは、問い合わせ AI の振り分け設計と同じ考え方で、業務システム全般に当てはまります。

共通点4：参照する情報とプロンプトが更新されない

社内文書を検索して回答する仕組み（RAG。検索した文書を AI に渡して答えさせる方式）では、文書が更新されても検索対象に反映されていないと、古い規程や廃止された手順を答え続けます。一度「古い情報を返した」と認識されると、信頼の回復には時間がかかります。これは検索精度の問題ではなく、更新をどう回すかの設計の問題です。

同様に、AI への指示文（プロンプト）も、業務ルールが変わったのに誰も直していない、という状態になりがちです。誰がいつ更新するのか、更新したものをどう戻せるようにするのかを、運用の担当とセットで決めておく必要があります。

利用が落ちたことを、感覚ではなく数字で捉える

立て直しに入る前に、何がどれだけ落ちたかを確認します。「最近使われていない気がする」だけでは、打ち手を決められません。最低限、次の4つが取れていれば判断できます。

これらはログ設計の段階で取れるようにしておかないと、後から遡れません。導入時に「利用状況を見る」と決めていなかったシステムでは、まずログの追加から着手することになります。

数字が出たら、利用が落ちた部署の担当者に短く聞き取りをします。聞くのは満足度ではなく、最後に使ったのはいつで、そのとき何が起きたかです。「3回続けて的外れな答えが返ってきた」「上長に確認し直す方が早かった」といった具体的な出来事が、原因の特定に直結します。

立て直しは「対象業務を狭める」ところから

利用が落ちたときに、機能を足して挽回しようとすると、たいてい事態は悪化します。使われていない機能に、さらに使われない機能が積まれるだけだからです。

順序としては次のようになります。

1. 最も使われている1業務に絞る。残りは止めずに置いておくが、改善対象から外す
2. その業務の入口を業務画面側に移す。別タブ・再入力をなくす
3. 出力に根拠と確信度を付け、確認を短くする
4. 人に戻す条件と戻し先を明文化し、現場に共有する
5. その1業務で利用が戻ってから、次の業務に広げる

絞ったあとは、改善したつもりが実は悪化していないかを確認する仕組みが要ります。過去の入力と期待する出力を数十件ためておき、変更のたびに同じ入力で比べる方法が実務的です。この進め方は 評価用データセットの作り方として整理しています。

なお、立て直しの過程で「この業務はそもそも AI に向いていなかった」という結論になることもあります。入力の形式が毎回違う、判断に社外の文脈が必要、誤りのコストが高すぎる——こうした業務は、無理に残すより対象から外した方が、全体の信頼は保てます。

まとめ

導入から数か月で利用が落ちる業務には、次の共通点が繰り返し現れます。

• 入口が業務動線の外にある——別タブ・再ログイン・情報の貼り直しが必要
• 確認コストが手作業を上回っている——根拠がなく、どこが間違いか読まないと分からない
• 例外の行き先が決まっていない——1回の悪い体験でその人の利用が止まる
• 参照情報とプロンプトが更新されない——古い内容を返し、信頼が失われる

いずれも AI の性能ではなく、業務への組み込み方と運用の設計に属する問題です。だからこそ、発注の段階で「どの画面から呼ぶか」「出力に何を添えるか」「人に戻す条件は何か」「誰が更新するか」を仕様として書いておくと、半年後の姿が変わります。

利用率は、導入の成否を測る最後の指標です。落ちたときに慌てて機能を足すのではなく、ログで現状を押さえ、対象を1業務に絞り、入口と確認のしやすさから直す。この順序を守ることが、立て直しの近道になります。