ChatGPT Enterprise を全社導入した。Copilot も入れた。研修も3回やった。それでも Slack に「AIに聞いた」の痕跡は残らず、経営会議で「うちのAI活用ってどうなってるの」と問われて答えに窮する。DX 推進を任されたあなたは、次に何を打つべきか決めきれずに立ち止まっていないでしょうか。
「使われない」の裏には、技術ではなく権限設計・業務プロセス・KPI 設計・組織体制の噛み合わせで起きる、5つの構造的な原因があります。原因の見立て、浸透の設計、KPI 設計、半年ロードマップまでを、実装の勘所と一緒に整理します。
浸透しない5つの構造的原因
私たちが相談を受けてきた事例の中で見える失敗パターンは、次の5つに整理できます。多くの企業は複数のパターンを同時に抱えていて、切り分けが難しいのが実態です。
| 原因 | 症状 | 根本の噛み合わせ |
|---|---|---|
| 権限設計の不整合 | AIから業務データが見えない | 情シスの権限設計 × 業務側の必要データ |
| 業務プロセスへの非適合 | 使うタイミングが業務フローに埋め込まれない | 業務プロセス × AI適用場面 |
| プロンプト習熟度の不足 | 3回試して離脱、以後使わない | 教育設計 × 現場のプロンプト経験値 |
| 失敗体験の固定化 | 1度の誤答で「AIは使えない」の印象が定着 | データ品質 × 再挑戦を促す設計 |
| 推進体制の空転 | 推進担当が疲弊、相談が滞留 | 推進体制 × 相談経路の設計 |
原因1: 権限設計の不整合
Copilot Chat から Dynamics 365 や Salesforce の商談データを読ませたい、というのは営業部門で最頻の要望です。多くの企業で、営業ロールに Graph API 経由の読み取り権限が付与されておらず、Copilot は「議事録要約マシン」に留まります。情シスは全社セキュリティを守る立場、業務側は使いたい立場。この間の合意形成に半年かかることもあります。
原因2: 業務プロセスへの非適合
「AIを使ってください」の研修だけでは、業務のどの瞬間に AI を呼ぶかは決まりません。月次締めなら仕訳判断のタイミング、営業なら商談前の会社調査、といった具体的な「AIを呼ぶトリガー」を業務プロセスに埋め込む必要があります。ここが空欄のままだと、AIツールは業務フローの外に浮いた存在になります。
原因3: プロンプト習熟度の不足
生成AIの回答品質は、プロンプトの書き方で桁が変わります。3回試して「思ったより使えないな」と離脱した担当者は、その後60日間再挑戦しないケースが多く見られます。研修で網羅的に教えるより、業務別に「これを使ってください」というプロンプト集を配布する方が、離脱率が下がります。
原因4: 失敗体験の固定化
1度でも誤答を経験すると、「AIは信頼できない」の印象が担当者の中に固定化します。特に経理や法務のように「正確さが命」の業務では、誤答の再現性が低くても離脱の引き金になります。誤答の原因（多くはデータ側の問題）を切り分けて、再挑戦を促す設計が必要です。
原因5: 推進体制の空転
情シスの兼任1名が推進担当、というケースが多く見られます。相談が集中して返信に5営業日、返信待ちで問い合わせを取り下げる利用者が7割、という状態は珍しくありません。相談経路を階層化し、部門ごとに社内推進役を立てる構造への切り替えが必要です。
浸透設計の4つのレバー
原因の見立てが済んだら、次は打ち手の設計です。効くレバーは大きく4つに整理できます。
| レバー | 目的 | 典型的な打ち手 |
|---|---|---|
| 権限・データ整備 | AIが業務データを見られる状態を作る | 情シスとの合意形成、権限設計変更、マスタデータ整備 |
| 業務プロセス埋め込み | AIを呼ぶトリガーを業務フローに配置する | SOP改定、業務別プロンプト集、ワークフロー変更 |
| 推進体制の階層化 | 推進担当の疲弊を防ぐ | 部門ごとの社内推進役制、相談経路の3層化、週次同期会 |
| KPI と可視化 | 浸透状況を数字で追える状態を作る | 利用ログの可視化、月次浸透率レポート、経営層への同期 |
4つを同時にすべて動かす必要はありません。診断で「あなたの会社で最大のボトルネックはどれか」を切り分け、優先順位をつけて1つずつ潰していくのが定石です。
現場定着KPIの3層モデル
浸透状況を経営層に説明できる形にするには、3層のKPIを持ちます。層をまたぐと数字の意味が変わるため、混同しないのがコツです。
| 層 | 指標例 | 見る目的 |
|---|---|---|
| アクティビティ層 | 週次アクティブ率、月次アクティブ率、部門別利用率 | そもそも使われているか |
| 用途分布層 | 議事録要約 / 提案書ドラフト / データ調査 / コード作成 の内訳 | 本来狙った用途に使われているか |
| 成果層 | 業務時間削減、成果物品質、顧客満足度への影響 | 業務価値に転換されているか |
よくある失敗は、アクティビティ層だけを見て「30%使われているから成功」と判断することです。用途分布を見ると、9割が議事録要約で本来の狙いだった提案書ドラフトはゼロ、というケースは頻繁にあります。3層を並べて初めて「浸透」の実態が見えます。
半年間の浸透プロジェクト標準ロードマップ
原因を潰して浸透状態を作るには、半年を1つの区切りで見ます。急ぎすぎるとPlaybookが薄くなり、遅すぎると経営層の期待とズレます。標準的な進め方は次の通りです。
| 月 | 重点 | ゴール |
|---|---|---|
| Month 1 | 診断と初動設計 | 5つの原因のうち貴社の主要2〜3を特定、KPIダッシュボードの土台 |
| Month 2 | 権限・データ側の解消 | 業務データがAIから見える状態、マスタ整備の完了 |
| Month 3 | 業務プロセス埋め込み | 部門別プロンプト集の初版、業務SOPへのトリガー追加 |
| Month 4 | 推進体制の階層化 | 部門ごとの社内推進役立ち上げ、週次同期会の運用開始 |
| Month 5 | 浸透KPIの安定運用 | 3層KPIの月次レポート化、経営層への同期 |
| Month 6 | 自走体制への引き継ぎ | 社内推進役へのPlaybook継承、外部支援の離任 |
6ヶ月ですべての業務ドメインを覆うわけではありません。診断で選んだ1〜3部門で「使われる状態」を作り、その勢いで他部門に広げていく設計です。全部門を同時に狙うと、どこも中途半端になります。
導入後にまず打つべき3つの初動アクション
この記事を読み終えて「次に何をするか」を1つ決めるとしたら、次の3つのどれかから始めます。
| 初動 | 内容 | 所要 |
|---|---|---|
| 利用ログの棚卸し | 過去60〜90日のAI利用ログをコンソールから取り出し、部門別・用途別に集計 | 1〜2週間 |
| 現場ヒアリング | 対象部門の担当者5〜10名に30分ずつ、実際の使い方と諦めた理由を聞く | 1〜2週間 |
| 業務プロセス棚卸し | AIを埋め込みたい業務プロセスを1つ選び、SOPに沿って手順を書き出す | 1週間 |
いずれも社内リソースで着手できる作業です。3つを終えるだけで、「うちの浸透ボトルネックはどこか」の見立てが手に入ります。ここまで済んでから、外部支援を検討するかどうかを判断するのが健全な順序です。
まとめ
生成AIが導入後に使われないのは、技術ではなく権限設計・業務プロセス・KPI 設計・推進体制の噛み合わせの問題です。5つの構造的原因を切り分け、4つのレバーで打ち手を組み立て、3層のKPIで浸透状況を追い、半年で自走体制に引き継ぐ。この設計を持って動けば、導入したAIを業務価値に転換できます。
原因の切り分けと打ち手の優先順位づけには、外部の目が入る方が精度が上がることが多いです。
「うちの場合はどこから手をつけるべきか」の見立てを掴みたい場合は、AI浸透支援 by DE-STKのAI浸透スコア診断（2週間・25万円）が入口として使えます。現状の利用実態、構造的な原因、次に打つべき手の候補まで、社内の投資判断に耐える粒度でお出しします。
あわせて読みたい
- Forward-Deployed Engineer（FDE）が去った後、AIプロジェクトを引き取る組織設計
- 生成AI浸透KPIの設計：アクティブ率・用途分布・成果指標の3層モデル
- AI浸透スコア診断に含めるべき10項目：入る前に確認する優先順位
- Microsoft Copilotが営業部門で使われない典型3パターンと構造的原因
よくある質問
Q. 5つの原因のうち、うちの会社はどれが該当するかどう見立てますか？
A. 60〜90日のAI利用ログと、担当者5〜10名へのヒアリング、業務プロセス1〜2件の棚卸しの3点セットで、8割は切り分けられます。ログだけでは足りず、ヒアリングだけでも足りず、両方見ることで構造が浮かびます。診断としてこの3点を体系化したのが、AI浸透スコア診断（2週間・25万円）です。
Q. 半年ロードマップの中で、どの月を厚くすべきですか？
A. Month 1〜2 に力をかけると、その後が楽になります。診断と権限・データ整備は「土台」で、ここが甘いと後の月がすべて滑ります。逆に Month 4以降は、社内推進役が育っていれば外部支援を薄く引くことができます。
Q. 全社導入は済んでいますが、まだ手をつけていない部門があります。どこから始めるべきですか？
A. すでに導入が済んでいる部門の中で、「使いたい意欲があるが構造で止まっている」部門を1つ選ぶのがおすすめです。意欲のない部門から始めても、浸透の起点になりません。営業部門でCopilot利用が中途半端、経理部門でChatGPT試行が止まっている、といったケースが典型的な起点になります。