①AI導入したのに現場が使わない理由｜ツール展開だけでは業務は変わらない

なぜAI活用は"検索どまり"で終わるのか

─ プロンプトを教えても、業務は変わらない

はじめに

「うちの会社、生成AI使えるようになったんですよ」

そう話してくれたのは、ある企業の営業部門のマネージャーだった。 Microsoft 365のCopilotを全社導入し、研修も実施済み。 推進部門からすれば、立派な「AI活用推進」の実績だ。

「で、実際どう使ってますか？」と聞くと、少し間があった。

「…調べものとか、メールの文章を整えるときとかですかね」

これが今、多くの企業で起きているAI活用の実態だ。 使ってはいる。でも、何も変わっていない。

これは失敗ではない。 もっとやっかいな状態だ。「止まっている」のだ。

なぜAI活用は"検索どまり"で終わるのか

─ プロンプトを教えても、業務は変わらない

はじめに

「うちの会社、ChatGPT使えるようになったんですよ」

そう話してくれたのは、ある企業の営業部門のマネージャーだった。 Microsoft 365のCopilotを全社導入し、研修も実施済み。 推進部門からすれば、立派な「AI活用推進」の実績だ。

「で、実際どう使ってますか？」と聞くと、少し間があった。

「…調べものとか、メールの文章を整えるときとかですかね」

これが今、多くの企業で起きているAI活用の実態だ。 使ってはいる。でも、何も変わっていない。

これは失敗ではない。 もっとやっかいな状態だ。「止まっている」のだ。

この問題を、私はずっと現場で見てきた。

私について

少し自己紹介をさせてほしい。

私はもともと生命保険会社に長年勤め、主にビジネス部門側でシステムの企画・推進に携わってきた。開発側ではなく、現場と開発をつなぐ立場だ。業務を知っている人間がどう要件をまとめ、どうITに伝えるか、その難しさを身をもって経験してきた。

その後独立し、現在はSalesforceの導入支援やデータ集計業務の支援を行いながら、DX研修の講師としてIT人材への育成やコーチング業務にも携わっている。

この仕事をしていると、似たような光景を繰り返し目にする。

IT部門は一生懸命ツールを導入している。セキュリティルールを整備して、研修を実施して、利用ガイドラインを作って。推進側の努力は本物だ。

でも現場は、使えていない。

「何に使えばいいかわからない」「なんか使いにくい」「結局自分でやった方が早い」──そういう声が現場から上がる一方で、推進側は利用率の数字を追っている。

この乖離は、悪意からではない。 お互いに「相手の言葉がわからない」という構造的な問題だ。

IT部門は業務の実態を深く知らない。現場はAIで何ができるかを知らない。 だから、ツールは届いても、活用は届かない。

このシリーズでは、その乖離の正体と、どう乗り越えるかを、現場で見てきたことをもとに書いていく。

1｜よくあるAI導入の風景

企業がAIツールを導入するとき、だいたい同じプロセスをたどる。

まず経営層や情報システム部門が旗を振る。 「生成AIを活用して業務効率化を推進する」 そういった方針が下りてきて、ツールの契約が決まる。

次に全社へのアナウンスがある。 「○月○日より、ChatGPTの業務利用が可能になります。積極的に活用してください」

研修が行われる。 内容はだいたいこうだ。 ハルシネーションとは何か。社外秘情報を入力してはいけない。個人情報の取り扱いに注意する。上限トークン数はこれくらい。リアルタイム検索はできない。

そして最後にこう締めくくられる。 「あとは皆さん、ぜひ業務の中で活用してみてください」

──ここで、現場に丸投げされる。

KPIは「月間アクティブユーザー数」や「利用率○%達成」。 推進部門は数字を追い、現場は各自で使い方を模索する。

この構造、どこかおかしいと思わないだろうか。

2｜研修は「気をつけろ」を伝えるだけで終わっている

正直に言う。 多くの企業のAI研修は、注意喚起を伝えるだけで終わっている。

ハルシネーションの説明は、「AIは嘘をつくことがある、気をつけろ」という注意喚起で終わっている。 本来ならその特性を踏まえてどう使うかの設計につなげるべきところを、過剰なリスク強調が現場の萎縮を生んでいる。 情報管理の注意喚起は「入れてはいけないものがある」というリスク啓発。 セキュリティ説明はコンプライアンス上の義務を果たすためのもの。

これらは必要だ。やらなければいけない。 でも、これはAIを「安全に使うための研修」であって、「業務で成果を出すための研修」ではない。

決定的に欠けているのは、ユースケースの研修だ。

「あなたの業務のこの場面で、こう使うと、こういう成果が出る」

この具体性が、ほぼどこにもない。

営業担当者が提案資料を作るとき、どのステップでAIを使うのか。 カスタマーサポートの担当者が問い合わせ対応をするとき、どこにAIを差し込むのか。 経営企画がレポートを作るとき、AIをどう組み合わせるのか。

こういった問いに答える研修を、私はほとんど見たことがない。

結果として何が起きるか。 AI好きな一部のメンバーだけが自力で使いこなし、組織の大多数は「なんとなく使ってみたけど、よくわからなかった」で止まる。 利用率のグラフだけが推進部門の会議資料に載り、業務は何も変わらない。

3｜制約の壁が、離脱を加速させる

さらに問題を複雑にするのが、ツールの制約だ。

企業が契約するAIツールには、さまざまな制限がある。 入力できる情報の種類に制約がある。 一度に処理できるトークン数に上限がある。 インターネットのリアルタイム検索ができない。 社内システムとの連携が取れない。

これ自体は仕方がない。セキュリティや契約上の理由があることがほとんどだ。

問題は、この制約が現場にきちんと伝わっていないこと、そして制約を踏まえた使い方を誰も教えていないことだ。

「じゃあ使ってみよう」と思った現場の担当者は、まず壁にぶつかる。

「あれ、これ入力しちゃいけないんだっけ」 「なんか古い情報しか出てこない」 「思ったより精度が低いな」 「これ、自分でやったほうが早くない？」

一度「使えない」と感じた人間は、戻ってこない。 利用率のグラフは下がり、推進部門は次の施策を考え始める。 でも根本は何も変わっていない。

さらに根深いのが、「設計次第で変えられる制約」が変えられないものとして扱われているケースだ。

典型例が「機密情報・社内情報の入力禁止」だ。 セキュリティ上の懸念から一律禁止にしている企業は多い。 でも、これは設定や構成の工夫次第で解決できる問題であることがほとんどだ。 プライベートな環境でAPIを利用する、社内データを安全に参照できるRAGの仕組みを構築するなど、手段はある。

問題はIT部門がそこまで詳しくないことだ。 AIのリスクは把握している。でもAIの活用設計はわからない。 だから「禁止」という最も安全な方向に倒す。 現場はその制約の中で使うしかなく、用途は最初から狭く固定される。

「変えられない制約」と「設計で変えられる制約」を区別できているIT部門が、今の企業にどれだけあるか。 この問いに自信を持って答えられる企業は、まだ少ない。

4｜精度を追い求めて、沼にはまったプロジェクト

ここで、私が実際に見た事例を話しておきたい。

「自動回答AIを作る」——そう意気込んでプロジェクトがスタートした企業がある。 問い合わせ対応の自動化が目標だ。方向性は間違っていない。

しかしプロジェクトは終わらなかった。正確には、完成しなかった。

精度が95%まで来た。でも残りの5%が気になる。 データを追加する。チューニングを繰り返す。97%になった。 今度は別の問い合わせパターンで精度が落ちた。また修正する——。

「リリースできるのはいつですか」という問いに、誰も答えられなくなった。

結果、着地したのは「単なるbot」だった。 選択肢を選ばせるシナリオ分岐型の、最初から作れたものだ。 投資した金額は、回収されなかった。

これは特殊な失敗例ではない。 「AIで100%の精度を目指して、完成しないまま終わる」というパターンは、あちこちで繰り返されている。

この事例に、前の章で述べた「制約の壁」問題と同じ根っこが見える。 AIに対して誤った期待値を設定することで、判断が狂う。 「100%でないと使えない」という前提が、プロジェクトを沼に引き込んだのだ。

5｜「プロンプトを教えること」だけでは不十分だ

この状況への処方箋として、よく出てくるのが「プロンプト研修」だ。

「ChatGPTをうまく使うには、プロンプトが重要です」 「役割を与えて、条件を明示して、出力形式を指定すると精度が上がります」

間違いではない。プロンプトの質がアウトプットに影響することは確かだし、プロンプトを学ぶこと自体に意味はある。

ただ、ユースケース設計とセットでなければ、プロンプト研修は効果をなさない。

包丁の使い方を教えても、何を作るかが決まっていなければ料理はできない。 道具の扱い方より先に、何のために使うかを決める必要がある。 それと同じことが、企業のAI活用で起きている。

プロンプトの問題ではなく、ユースケースが設計されていないことが問題だ。

どの業務の、どのプロセスに、どう組み込むのか。 その設計がないまま「あとは使ってください」では、現場が自力で答えを見つけるしかない。 これが「検索どまり」の正体だ。

6｜「業務に組み込む思想」がなければ、何も変わらない

ここまで読んで、こう思った人もいるかもしれない。

「でも、まず使い始めることが大事なんじゃないの？」

その通りだ。使い始めることは正しい第一歩だ。 検索ベースで使うことが浸透してきているのは、確かに前進している。

ただ、第一歩は第一歩でしかない。

AIを「便利な検索ツール」として使うことと、「業務の構造に組み込む」ことは、まったく別の話だ。

前者は個人の生産性をわずかに上げるかもしれない。 後者は組織の業務そのものを変える可能性がある。

その差を生むのは、ツールでも、プロンプトでも、研修の回数でもない。 「この業務に、AIをどう組み込むか」を設計する思想と、それを推進する仕組みがあるかどうかだ。

では、どうすればいいのか。

ユースケース研修を整備する、というのもひとつの答えだ。 でも、それより先にやるべきことがある。業務に入り込むことだ。

全社に展開する前に、まず特定の業務・特定のチームに深く入る。 その業務をAIでどこまで変えられるか、小さく試す。

順序はこうだ。

① この業務、理想的にはどこまで自動化・効率化できるか？（制約なし） 　　　↓ ② その理想に対して、今のツールでどこまで近づけるか？ 　　　↓ ③ 足りない部分は人が補う設計にする

理想から逆算するから、「では今何ができるか」が見えてくる。 小さく始めて、成果を出す。 その成果が、横展開の根拠になる。

全社展開より先に、一つの業務を深く変えることを優先する。 この順序が逆になっている企業が、あまりにも多い。

そしてもう一つ、業務に入り込むことで見えてくるものがある。制約の再設計だ。

業務によって、守るべき情報の種類も、許容できるリスクの水準も違う。 一律の制約は、リスクの低い業務まで同じ縛りをかけてしまう。

業務に入り込んで初めてわかることがある。 「この業務では、実はここまでの情報は使っていい」 「この用途なら、この設計で安全に社内データを参照できる」

一律で制約を決めるのではなく、業務起点で制約を設計する。 守るべきものを守りながら、用途を広げる。

ただ、これを社内だけでやり切るのは難しい。理由は構造的なものだ。

業務側の人間は、自分たちが何に困っているかはわかっている。 でも、それをITに伝える言葉を持っていない。 IT側の人間は、技術はわかっている。 でも業務の実態が見えていないから、「何を作れば現場が助かるか」に答えられない。

この構造的なギャップを埋めるのが、翻訳者の役割だ。 業務の課題をITの言葉に変換し、AIで何ができるかを業務の言葉で説明する。 その翻訳ができる人間が間に入って初めて、業務起点のAI活用が動き出す。

社内にその役割を担える人材がいないなら、外部の力を借りることも選択肢に入れるべきだ。 翻訳者の不在が、AI活用を「検索どまり」で止めているもうひとつの理由だ。

おわりに──次回予告

「業務に組み込む」という話をするとき、避けて通れない問いがある。

「でも、AIってどこまで信頼できるの？」

これは正直な疑問だ。 そしてこの問いへの答えが、AI活用の設計を根本から変える。

冒頭で紹介した「自動回答AIが単なるbotに着地した」事例も、この問いへの答えを持たないまま設計を始めたことが原因の一つだ。 「AIは100%正確でなければならない」という誤解が、プロジェクトを沼に引き込んだ。

多くの企業が、AIを「従来のシステムの延長」として捉えている。 ルールを入れれば正確に動く。一度設定すれば再現性がある。そういう前提で使おうとしている。

でも、AIは根本的に異なる性質を持つ。 この誤解が、現場での期待外れと「やっぱり使えない」を生む。

次回は、「AIは従来のシステムとは何が違うのか」を掘り下げる。 業務に組み込む前に、AIという道具の本質を正しく理解しておこう。

このシリーズは全５回です。
① AI導入したのに現場が使わない理由｜ツール展開だけでは業務は変わらない（本ページ）
② AIが「たまに間違える」のは欠陥じゃない｜現場担当者が知っておくべきAIの本質
③ AIに丸投げしても、人がやり直すだけ｜成果を出す企業が実践する役割分担の設計
④ 社内データをAIに入れるだけでは危ない｜メンテナンス設計なきAI活用が招く静かな失敗
⑤ 今日から使えるAI活用11選｜現場支援で見えた、業務を変えるユースケース実例

#創作大賞2026 #ビジネス部門

#創作大賞2026 #ビジネス部門