生成AIのツールを導入し、全社員にアカウントを配布し、社内向けの勉強会も開催した。それでも「思ったほど使われていない」「一部の人しか活用できていない」「研修後しばらくは使っていたが、いつの間にか元に戻っている」という状況に悩む生成AI推進担当者は少なくありません。
こうした状況を受けて取られる次の一手は、往々にして「研修をもっと増やす」「プロンプトの使い方を集めたマニュアルを作る」「活用事例を集めた社内ポータルを立ち上げる」「コンテストを開催する」「全社員向けにスキルを作成して配布する」といった施策です。どれも間違いではありません。ただし、こうした施策を打ち続けているにもかかわらず利用率が改善しない場合、原因は施策の数や規模の問題ではなく、「なぜ使われないのか」という問いに対する答えが曖昧なまま施策から入ってしまっていることにあるかもしれません。
生成AI活用が現場に定着しない原因は、ツールが使いにくいことだけでも、知識が足りないことだけでもありません。現象の背後にある原因を見立てずに施策を重ねることが、根本的な問題を長引かせている場合があります。
本記事では、生成AI推進担当者・社内AI活用の促進を担う方々に向けて、次の2点を整理します。
1つ目は、「生成AIが使われない」理由を正しく分解するための考え方です。2つ目は、その見立てと施策検証に生成AIそのものをどう活用できるかです。
生成AI活用を現場に定着させるための基本的な考え方については、以下の記事も参考になります。
企業における生成AI活用の取り組みは、大きく「導入フェーズ」と「定着フェーズ」に分けることができます。この2つを混同することが、利用率が伸び悩む原因の一つになることがあります。
導入とは、ツールを選定し、アカウントを配布し、利用に関するポリシーや規則を整備することです。これは比較的短期間で完了し、「完了した」という実感を得やすいフェーズです。一方、定着とは、現場の日常業務の中で継続的に使われ続ける状態を作ることです。これは導入の完了を告げても、自然には実現しません。

定着が難しい根本的な理由は、現場の実態にあります。生成AI活用に関するヒアリングや現場観察でよく聞かれる声として、次のようなものがあります。
「何に使えばいいのか具体的に分からない」
「間違った内容を出力したときの責任が取れない」
「使い方を調べる時間があれば自分でやった方が早い」
「社外の情報や顧客情報を入力してよいのか判断できない」
「日常業務が忙しくて、新しいツールを試す余裕がない」
これらの声は、ツールの性能や研修内容とは直接関係のない部分に根ざしています。有用性の実感不足、失敗への不安、業務フローとの接続の欠如、利用ルールの不透明さ、時間的な余裕の欠如。こうした要因が重なると、「導入はされたが日常的には使われない」という状態が続くことになります。
Gallupが2026年1月に公開した2025年第4四半期の米国就業者調査によれば、米国の就業者のうち、仕事でAIを毎日使うと回答した割合は約12%にとどまり、週に数回以上使う人は全体の約4分の1、少なくとも年に数回以上使う人は約半数と報じられています(Frequent Use of AI in the Workplace Continued to Rise in Q4、AP News)。また、Gallupが2025年6月に公開した別の調査記事では、管理職・リーダー層は一般の従業員と比較してAIをより頻繁に利用する傾向があるとも報告されており、明確なAI活用方針が示されていると感じている従業員は準備感や安心感が高い傾向もみられると報じられています(AI Use at Work Has Nearly Doubled in Two Years、Business Insider)。
これらは米国の就業者を対象にした調査ですが、日本企業においても「経営層や推進担当者は盛り上がっているが現場はまだ」という構造は珍しくありません。問題の本質は「AIを知らないこと」だけでなく、明確な活用方針の不在、業務との接続不足、安心感や成功体験の欠如にあります。
「生成AIが使われていない」という現象は、一見同じように見えても、その原因は部署・業務・個人によって大きく異なります。原因を特定しないまま施策を打つと、「当たったかもしれないし、外れたかもしれない」という曖昧な結果しか得られません。
以下の表は、現場でよく観察される現象と、その背後にある主な原因、対応する施策の方向性(仮)を整理したものです。
| 見えている現象 | あり得る原因 | 施策の方向性(仮) |
|---|---|---|
| そもそも使わない | 何に使えるか具体的なイメージがない | ユースケース発見の場の設定、業務別活用事例の共有 |
| 触ったが続かない | 成果を実感できない、効果が見えない | 小さな成功体験の設計、業務テンプレートの整備 |
| 一部の人しか使わない | 関心の高い人や得意な人に偏っている | チーム単位の活用設計、横展開の仕組みづくり |
| 使っているが成果が出ない | 使い方が浅い、型化されていない | 活用レビューの場、型化・スキル化のサポート |
| 勝手に外部サービスを使う | 公式環境が使いにくい、または知られていない | ガイドラインの整備、承認済み環境の周知 |
| 怖くて使えない | 情報漏えいへの不安、評価への影響を恐れている | 安全な利用ルールの明文化、心理的安全性の醸成 |
| 管理職・推進側だけ盛り上がる | 現場の業務課題と施策が接続していない | 業務課題から逆算したユースケース発見 |
この表が示す通り、「使われない」の原因は複数のパターンに分類でき、それぞれに対応する施策が異なります。「怖くて使えない」という原因に対しては研修よりも利用ルールの明確化が有効ですし、「成果が実感できない」という原因には事例集よりも業務テンプレートの提供が適しています。同じ「利用率が低い」という現象でも、原因が違えば有効な施策も変わります。

「勝手に外部サービスを使う」という現象への対応として、業務データの扱いやセキュリティ上の判断基準を整えることは重要な前提になります。この点については以下の記事で詳しく整理しています。
なお、この表の「施策の方向性(仮)」はあくまで仮説であり、原因の確認なしにそのまま当てにいくことには、次節で述べるような問題があります。
生成AI推進でよく見られるパターンは、「利用率が低い→勉強会を開く」「使い方が分からない→プロンプト集を作る」「盛り上がりがない→コンテストを開催する」という形で、現象に対して反射的に施策を当てる進め方です。これらの施策が不適切なわけではありません。しかし、次の問いに答えられないまま進めてしまうと、学習の機会が失われます。
その施策を実施したことで、本当に利用率は改善したのか。
仮に改善したとして、それはその施策のおかげなのか。
施策を実施しなければ、利用率はどうなっていたか。
「勉強会を開催した翌月に利用率が上がった」という結果だけを見ると、勉強会が効果的だったと結論づけたくなります。しかし実際には、同時期に経営層からの活用推進指示が発信されていたかもしれません。繁忙期が終わってメンバーに余裕が生まれた時期と重なっていたかもしれません。もともとAIへの関心が高い部署を対象にしていただけかもしれません。こうした「別の要因(交絡)」が利用率を押し上げた可能性は、前後比較だけでは排除できません。
原因と結果を丁寧に結びつけなければ、「何が効いたのか」を学べません。結果として、効果の定かでない施策を繰り返すことになり、推進活動の精度も次第に下がっていきます。
施策を打つこと自体は必要です。ただし、その前に「何が変われば利用率が上がるはずか」という因果の仮説を置く習慣を持つことで、施策の精度と実施後の学習効率が大きく変わります。

生成AIが使われない理由を考える上で、技術受容に関する研究の枠組みが参考になります。
TAM(Technology Acceptance Model)は、フレッド・デイビスが1989年に発表した技術受容のモデルです。技術が受け入れられるかどうかに影響する主な要素として、「有用性の知覚(その技術を使えば業務成果が向上すると感じられるか)」と「易用性の知覚(その技術の利用が困難でないと感じられるか)」の2点を挙げています(出典:Davis, 1989, "Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology")。
これを発展させたUTAUT(Unified Theory of Acceptance and Use of Technology)は、Venkateshらが2003年に提唱したモデルで、技術の利用意図と利用行動に影響する要因として次の4点を整理しています(出典:Venkatesh et al., 2003, "User Acceptance of Information Technology: Toward a Unified View")。
1点目は「パフォーマンス期待度」:システムを使うことで業務成果が向上するという期待。2点目は「努力期待度」:システムを利用する際の難易度や労力に関する認識。3点目は「社会的影響」:周囲の人々や組織からの影響が利用意図に与える効果。4点目は「促進条件」:システム利用を支援するインフラやサポート体制といった環境要因です。
UTAUTの縦断研究では、利用意図の分散の70%、実際の利用行動の約50%をこれらの要因で説明できたとされています。
専門的なモデルを現場の言葉に翻訳すると、次の表のようになります。
| 観点 | 現場で確認すべき問い |
|---|---|
| 有用性 | 自分の業務が本当に楽になると実感できているか |
| 容易性 | 最初の一歩が重すぎないか、試すことへの心理的・手順的な障壁はないか |
| 安心感 | 使って問題にならない、失敗しても大丈夫だと感じられているか |
| 業務適合 | 日々の業務フローに自然に組み込めているか |
| 周囲の影響 | チームや部署内で使うことが普通になっているか |
| 支援環境 | 相談できる場所、利用ルール、テンプレートや事例が整っているか |
この6つの観点は、現場ヒアリングやアンケート設計を行う際の軸として有用です。「利用率が低い」という現象の背後に、どの観点が不足しているのかを見立てることが、施策選択の出発点になります。
たとえば、「有用性が実感できていない」という原因であれば、業務別の活用事例や小さな成功体験の提供が有効です。「安心感が欠けている」という原因であれば、利用ルールの明文化や問い合わせ窓口の設置が先決になります。「周囲の影響」が弱いという原因には、管理職やチームリーダーが率先して活用する場を設けることが効果的です。
生成AIの出力精度に対する期待値の置き方については、以下の記事が参考になります。
また、AI・機械学習・生成AIといった用語の意味や期待値について、社内で共通認識を作ることも、有用性の観点では重要な前提になります。
施策を評価する場面で最もよく使われるアプローチが、「施策の前後で利用率を比較する」という方法です。直感的に分かりやすく、実施しやすい評価手段です。しかし、前後比較にはある限界があります。
「施策後に利用率が上がった」という事実は、その施策が利用率を上げた「原因」であることを証明しません。施策と同時期に別の要因が変化していた場合(これを交絡と呼びます)、その影響を前後比較だけでは取り除けないからです。
因果推論の分野では、ある介入(施策)の効果を測るためには、「施策を実施した場合」と「実施しなかった場合」の結果を比較することが必要だと考えます。これを平均処置効果(Average Treatment Effect)と呼び、「施策を受けたグループ」と「受けなかったグループ」の平均的な差として定義されます(出典:Naimi and Whitcomb, 2023, "Defining and Identifying Average Treatment Effects")。
しかし実際には、まったく同じ条件のグループに「施策あり」と「施策なし」の両方を経験させることはできません。そのため、できるだけ条件の似た比較対象を設けるか、施策の展開範囲を段階的に広げながら比較するといった工夫が必要になります。

実務において完全な実験環境を整えることは難しいですが、以下のような工夫によって学習の精度を高めることができます。
施策を全社に一斉に展開するのではなく、特定の部署やチームに先行して実施し、その結果を他のチームと比較する方法があります。完全な対照実験ではなくても、「この部署では施策を実施し、別の部署では実施しなかった」という比較を意識することで、施策の効果をある程度評価できます。「まずここで試して、結果を見てから展開を広げる」という順序立てが、学習の機会を生み出します。
施策の対象を選ぶ際に、もともとAIへの関心が高い部署や個人だけを選ぶと、施策の効果を過大評価してしまいます。「関心の高い人が多い部署で施策が成功した」という結果は、施策の効果ではなく、対象の偏りによるものかもしれません。比較対象を設けるときも、条件が大きく異なるグループを比べることには注意が必要です。
「施策前後の比較」に加えて、「同時期に何が変わったか」を記録しておく習慣が役立ちます。全社的なAI活用推進の通達、業務の繁閑のサイクル、組織変更、外部環境の変化など、施策以外の変化を把握しておくことで、利用率の変動の解釈精度が高まります。
施策を実施する前に、「この施策は、どのような経路で利用率を高めるはずか」という仮説を言語化しておくことが重要です。たとえば「業務テンプレートを配布することで容易性への障壁が下がり、試す頻度が増え、成功体験が生まれ、継続利用につながる」という形で仮説の経路を描いておくと、後から「どの部分が機能したか、しなかったか」を検証しやすくなります。
完全な因果の特定を目指す必要はありません。大切なのは、「この結果は施策のおかげか、それとも別の要因か」という問いを常に持ちながら施策を評価する習慣です。この習慣が、推進担当者としての判断精度を積み上げていきます。
小さく試して比較するアプローチの実践については、以下の記事も参照してください。
ここまで、利用率向上には「なぜ使われないのかの仮説を持つこと」「施策の前に因果の仮説を立てること」が重要だと整理してきました。しかし、こうした分析・設計を推進担当者が単独でゼロから行うことは、特に少人数チームでは負担が大きくなります。
ここで活用できるのが、生成AI自体です。「生成AIの社内浸透を進めるための施策を、生成AIと一緒に設計する」というアプローチは一見メタな構造ですが、実務として有用性の高い使い方です。
以下の表は、推進担当者が取り組む各フェーズと、生成AIが担える支援内容を整理したものです。
| フェーズ | 生成AIに担わせられること |
|---|---|
| 課題の分解 | 利用しない理由の仮説の列挙(現象 → 原因 → 検証方法の形式で) |
| ヒアリング設計 | 現場担当者へのインタビュー項目の作成・整理 |
| アンケート設計 | 利用頻度・有用性・不安・業務適合を測定する設問の起案 |
| 施策設計 | 部署別・職種別の施策案の比較、優先順位の整理 |
| 因果仮説の整理 | 「何が何に影響するのか」の仮説の言語化と構造化 |
| 分析の補助 | 前後比較の注意点・交絡要因の洗い出し |
| 振り返り | 結果から次の施策候補の抽出 |
生成AIは、人間が思いつきにくい仮説の組み合わせや観点の漏れを補う役割として機能します。人間側の判断・現場ヒアリング・意思決定と組み合わせることで、分析と施策設計のサイクルを早めることができます。

たとえば、自社の状況を整理した上で次のようなプロンプトから始めることができます。
あなたは組織における生成AI活用の専門家です。
以下の状況を前提に、社内で生成AIが使われていない理由の仮説を
「見えている現象 → 考えられる原因 → 検証方法(ヒアリング or アンケート)」
の形式で10個挙げてください。
【状況】
- 業種・組織規模: (例:製造業、従業員約2,000人)
- 導入済みツール: (例:Microsoft Copilot for Microsoft 365)
- 現状の利用状況: (例:月1回以上使う人が全体の約15%程度)
- 現場から聞こえている声: (例:「何に使えばいいか分からない」「忙しくて試す余裕がない」)
- 実施済みの施策: (例:全社向け説明会を1回、部門長向け勉強会を2回実施済み)
このプロンプトに自社の情報を当てはめることで、推進担当者では見落としがちな仮説の候補が複数得られます。得られた仮説はそのまま施策に転換するのではなく、現場ヒアリングやアンケートで検証する材料として扱うことが重要です。
課題仮説が出そろったら、現場に確認するためのヒアリング項目を設計します。
以下の仮説リストを前提に、現場の担当者へのインタビューで使える
質問項目を10問作成してください。
各質問は、仮説が正しいかどうかを確認できる内容にしてください。
誘導にならないよう、オープンな質問形式を基本にしてください。
【確認したい主な仮説】
- 生成AIを使うことで自分の業務が楽になるという実感が得られていない
- 失敗した場合の評価への影響を恐れて試すことを避けている
- 日常業務のフローの中で、いつ・どこで使えばいいかが明確でない
このように生成AIを設計の補助として使うことで、ヒアリングの抜け漏れを減らしながら、短時間で構造化された調査設計を行うことができます。
生成AIを活用した効果的なプロンプトの作り方については、以下の記事も参考になります。
生成AIが出力する仮説や施策案は、論理的な推論の結果です。自社の業種・文化・組織の特性・業務の独自性は、プロンプトに明示しない限り考慮されません。「生成AIがこう言ったから正しい」ではなく、「仮説として有力そうなものを現場ヒアリングで確認する材料」として扱うことで、実務に活かすことができます。
生成AIとの協働は、推進担当者の思考を代替するものではなく、思考の速度と網羅性を高めるものとして位置づけるのが適切です。
生成AI活用の促進施策として「カスタムスキルを作る」「プロンプトテンプレートを整備して配布する」というアプローチは、実際に効果的な場合があります。ただし、これらが機能するのは「どの業務課題に対して」「誰が」「どんな場面で使う」という前提が明確になった後のことです。
課題仮説を持たずにスキルやテンプレートを先行して作ることの問題は、「誰のどの業務課題に応えるものか」が不明確なまま開発が進んでしまうことです。誰もダウンロードしないスキル、配布したがほとんど使われないプロンプト集が増えていくのは、この順序の逆転が一因となっています。
スキルやテンプレートが定着しやすい業務には、次のような特徴があります。
逆に、毎回内容が大きく変わる業務、高度な文脈判断が求められる業務、アウトプットの判断基準が曖昧な業務は、スキル化よりも都度の対話型利用の方が向いていることが多いです。
全社向けの汎用スキルを先に作って配布するよりも、「特定のチームの特定の業務で使いどころを見つけ、その業務に合わせた形でテンプレートやスキルを作る」という順序の方が、利用に結びつきやすいです。課題仮説と現場ヒアリングを通じて「ここだ」という業務が特定されてから、スキルやテンプレートの整備に移ることが、効果的な定着への近道です。
ChatGPTにおけるSkillsの基本的な仕組みや考え方については、以下の記事で解説しています。
Skillsを実際に作成する手順については、以下も参考になります。
本記事では、生成AIの社内利用率を上げたい推進担当者に向けて、次の点を整理しました。
生成AI活用における「定着」の難しさは、ツールの整備だけでは解決しない問題です。現場では「有用性の実感不足」「操作への不安や障壁」「安心感の欠如」「業務フローとの不適合」「周囲の影響力の弱さ」「支援環境の不整備」という複数の要因が絡んでおり、「使われない」の原因は一つではありません。
よくある失敗は、この原因を丁寧に分解する前にいきなり施策から入ることです。施策の前後で利用率を比較するだけでは「その施策が本当に効いたのか」を判断できず、学習の機会が失われます。施策の効果を正確に把握するためには、比較対象の設定や交絡要因の記録といった、因果の仮説に基づいた観察の習慣が必要です。
こうした分析や設計を人間だけで行う必要はありません。生成AI自体を使って、課題仮説の洗い出し、ヒアリング・アンケートの設計、施策案の比較、振り返りを行うことで、推進活動のサイクルを回す速度と精度を高めることができます。スキルやテンプレートは、課題仮説が明確になった後に、特定の業務へ向けて整備することで、はじめて利用に結びつきます。
生成AIの社内浸透は、ツール導入の問題ではなく、行動変容と業務設計の問題です。利用率を上げるために必要なのは施策の量を増やすことではなく、「なぜ使われないのか」という問いを丁寧に扱う思考の習慣と、それを生成AIと協働しながら実践する継続的な取り組みです。
「研修が効果を持つ条件と持たない条件の違い」「プロンプト集が使われなくなる理由と活性化のアプローチ」「推進担当者が設定すべきKPIの考え方」など、本記事で取り上げきれなかった個別テーマについては、引き続き整理・発信していく予定です。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた支援を3つのパックでご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。