Microsoft Copilotが定着しない原因と対策｜利用率を上げる定着支援の設計

なぜMicrosoft Copilotは定着しないのか？

原因は個人のスキル不足ではなく、プロンプトの型・体感効果・推進体制・測定という4つの仕組みの欠落に構造化できる。

導入直後の数週間はよく使われる。デモを見た直後は誰もが試すからです。ところが1〜2か月経つと、Copilotを開く人が目に見えて減り、「うちの社員はAIに向いていないのでは」という話になる。多くの企業で同じ経過をたどりますが、止まる理由は人ではなく仕組みの側にあります。定着を阻む原因は、次の4つに整理できます。

1. プロンプトが分からない。「何を頼めるのか」「どう指示すればよいのか」の型が手元にない。全社共通の一般的な研修だけでは、自分の業務にどう当てはまるかまで翻訳されず、開いても打つ言葉が浮かばないまま閉じてしまう。
2. 「手作業の方が速い」という体感。使い始めの数回は、指示の書き方を試行錯誤する分だけ手作業より時間がかかる。比較対象が「何年も磨いてきた熟練の手作業」なので、最初の谷で「自分でやった方が速い」と結論づけて離脱する。
3. 推進体制の不在。IT部門がライセンスを配って導入は完了、という体制のまま業務部門に相談相手がいない。つまずいた人が質問する先も、うまい使い方が横に広がる経路もない。
4. 測定していない。利用率を誰も見ていないので、離脱が起きても気づかない。気づかないので打ち手も打てず、更新のタイミングで「使われていないのでは」という稟議の壁だけが残る。

定着しない原因には、それぞれ何を打てばよいのか？

4つの原因に、部門別プロンプト集・体感の設計・チャンピオン制度・利用率KPIを一対一で対応させると打ち手が決まる。

原因が4つに分かれるなら、対策も4つ用意します。下のマトリクスは、原因ごとに「現場で起きていること」と「制度としての打ち手」「主な担い手」を対応させたものです。ポイントは、どれか1つを選ぶのではなく4点セットで回すこと。1つでも欠けると、残りの3つで持ち上げた利用率が数か月で元に戻ります。

この4点を自社だけで整えるか、外部の定着支援サービスと組んで整えるかは、社内の推進リソース次第です。外部に任せる場合の選び方はCopilot定着支援サービスの比較で整理しています。以下では、自社で設計する場合の中核となる「チャンピオン制度」「部門別プロンプト集」「利用率KPI」の3つを順に見ていきます。

チャンピオン制度と部門別プロンプト集はどう設計するか？

部門ごとに業務が分かる推進者を置き、その部門の頻出業務に絞ったプロンプト集を整備する。全社一律の配布では動かない。

チャンピオン制度は、部門ごとに推進者（チャンピオン）を公式に任命する仕組みです。設計の要点は3つあります。第一に選び方。ITスキルの高さではなく、その部門の業務を理解していて、同僚から相談されやすい人を選びます。Copilotの操作は覚えられますが、業務の翻訳力と社内の信頼は後から付けられません。第二に役割の明文化。週次でうまい使い方を部門内に共有する、プロンプト集を更新する、つまずきを吸い上げて事務局に渡す——この3つを役割として書き出します。第三に公式化。兼務前提になるため、推進活動に使う時間を業務時間として認め、評価にも反映させます。「善意のボランティア」に頼った推進は、その人の異動と同時に止まります。

これはTechWorker独自の発明ではなく、Microsoft自身が実践している型です。Microsoftは社内推進コミュニティ「Copilot Champs Community」を運営し、同僚同士で学び合う仕組みを全社展開の柱に据えていることを公式ブログ（Microsoft Inside Track）で公開しています。またMicrosoft Learnの公式トレーニング（MS-4007）でも、ユーザーエネーブルメントの枠組みに沿って導入計画を作る方法が提供されています。推進者を置いて横に広げるやり方は、提供元自身が採用している標準的な進め方です。

部門別プロンプト集は、チャンピオンが機能するための道具です。全社共通のプロンプト集が使われないのは、書かれている例が自分の業務の言葉になっていないから。営業には営業の、経理には経理の頻出業務があり、プロンプト集はその単位で作ります。設計はシンプルで、部門の頻出業務トップ5に絞り、「用途・そのまま使える指示文・差し替え箇所」をセットにして配るだけです。

図：部門別プロンプト集の1項目のイメージ。「用途・そのまま使える指示文・差し替え箇所」をセットで配布し、出力は必ず人が確認して仕上げます。

なお、研修そのものの設計と費用感はCopilot研修の費用相場で扱っています。定着した先に業務プロセス自体を組み替えるフェーズが来ますが、その論点はCopilotを起点にしたBPRを参照してください。

Copilotの利用率はどう測ればよいのか？

Microsoft 365管理センターの利用レポートとCopilot Dashboardで、アクティブ利用率を28日単位で定点観測する。

測定に追加開発は不要です。Microsoftが標準で提供する2つの機能——Microsoft 365管理センターの「Microsoft 365 Copilot利用レポート」と、Viva Insightsの「Microsoft Copilot Dashboard」——で、定着支援に必要な指標はそろいます。本稿の機能記述は、2026年7月時点のMicrosoft Learn公開ドキュメントに基づきます。

指標の定義はMicrosoft Learnのドキュメントで確認できます。利用レポートの「アクティブユーザー」は、選択した期間内にMicrosoft 365のいずれかのアプリで、ユーザー起点のCopilot機能を1回以上使った有効ユーザーを指します。注意したいのは判定の基準で、Copilotのチャットペインを開いただけではカウントされず、プロンプトを送信するなどの意図的な操作だけが対象です。つまりこの数字は「画面を見た人」ではなく「実際に仕事で使った人」を数えており、定着のKPIとしてそのまま使えます。Copilot Dashboard側も同様に、直近28日間に1回以上のCopilotアクティビティを行ったユーザーを「Active Copilot users」として集計します。

そのうえで、何をどの頻度で見るか。定着支援の実務でのKPI設計の要点を1枚にまとめました。

経営への報告では、Copilot Dashboardの「Copilot assisted hours」（Copilotが支援した推定時間）が説得材料になります。ただしこの値はMicrosoftの調査に基づく係数を使った推計であり、Microsoft Learn自身が「精密な計算ではなく概算」と明記しています。社内資料では必ず「推計値」と添えて使ってください。また「うちの利用率は高いのか低いのか」という問いには、Copilot Dashboardの内部ベンチマーク（社内の類似グループとの比較）と外部ベンチマーク（類似企業との比較）機能で答えられます。外部の記事にある断片的な数値を合格ラインにするより、自社データの傾向と公式ベンチマークで判断する方が確かです。

定着支援は何から始めて、90日で何をやるか？

最初の30日で測定と体制、次の30日で部門展開、最後の30日で定着判定。90日で改善ループを一巡させる。

4つの対策を一度に全社へ広げようとすると、どれも中途半端に終わります。実務では90日を3つの区切りに分け、「測る→広げる→判定して改める」の順で一巡させるのが着実です。

最初の30日で必ず「ベースライン」を取っておくこと。改善の主張は、開始時点の数字がなければ成立しません。逆にベースラインさえあれば、90日後の報告は「やった研修の一覧」ではなく「利用率がどう動いたか」で語れます。ここまでの設計を自社で担うのが難しい場合、研修と定着支援をどう外部に切り出すかはCopilot定着支援サービスの比較とCopilot研修の費用相場が参考になります。

よくある質問