この記事で分かること：
- 「Copilotを入れたが誰も使っていない」相談で共通していた4つのパターン
- 使われ始めたチームと止まったままのチームで違った「最初の1手」
- 今すぐ試せる「業務を1つに絞る」アプローチの具体的な手順
会議の議事録をCopilotに作らせてみたが、要点が抜けていて使い物にならなかった。そういう経験が最初の1回になってしまうと、その後に使われなくなるパターンがある。
Microsoft 365 Copilotの企業導入について、相談を複数件受けてきた。共通して出てくる困りごとがあり、また「使われ始めた」チームに見られた行動にも共通点があった。Copilotの社内展開を担当しているエンジニアや情シスの方に向けて、その整理を書く。
Copilotが使われない4つのパターン
相談の中で繰り返し出てきた状況を整理すると、次の4つのパターンに分類できる。
1. 最初の1回で「使えない」と判断してしまう
Copilotを試してみた業務が、たまたまCopilotの苦手な作業だった。議事録の作成でいえば、会議の文字起こしがない状態では、要点を正しく取り出すのは難しい。しかし「議事録を作ってみたら要点が抜けていた」→「使えない」という判断が最初の体験になると、その後で使い道を探す気力がなくなる。
最初にどの業務で試したかは、その後の使われ方に影響しやすい。
2. 何に使えばいいかが分からないまま放置されている
ライセンスが配布された。でも「具体的に何に使えばいいか」の説明がない、または説明を受けたが「あとは自分で試してみて」で終わった。相談の中で繰り返し出てきた状況だ。
Copilotは「汎用性が高い」ツールとして紹介されることが多いが、それが「何でもできそうだが何に使えばいいか分からない」という感覚につながっていた。
3. プロンプトの書き方が分からない
「Copilotに聞いてみたが的外れな回答が返ってきた」という状況は、多くの場合プロンプトが漠然としすぎていることが原因だ。「会議のサマリーを作って」よりも「以下のテキストから、決定事項と担当者と期日を箇条書きで抽出して」の方が精度が上がる。
この「型」を持っていないまま試すと、失敗体験が積み重なる。
4. チームへの展開方法が分からない
担当者自身はCopilotをある程度使えているが、チームへの展開で詰まっているケースがある。「自分で試した使い方を説明しようとしたが、うまく言語化できない」「研修をどう設計すればいいか分からない」という状況だ。
使われ始めたチームがやっていた「業務を1つに絞る」
相談を受けた中で、「使われ始めた」という結果になったケースに共通していたのは、最初に試す業務を1つに絞っていたことだ。
「何でも使える」という前提を一度捨て、「今週はこれだけに使う」と決める。
最初の1つの候補になる業務の例：
- メール返信の下書き：「この内容への返信案を3つ作って」という形で使う。送るかどうかは人間が判断する。前後で1通あたりの時間を測っておくと、効果を確かめられる
- 報告書の骨格作り：「この資料の要点を3点で箇条書きにして、報告書の構成案を出して」という使い方。ゼロから書く代わりに、案を直す形にする
- 複数メールの横断検索：「先月の〇〇に関するメールを要約して」という使い方。Outlookと連携して大量のメールから必要な情報を探す
この3つに共通しているのは、「Copilotが出したものを、人間が最終確認して使う」という構造だ。全自動ではなく、時間を短縮するためのツールとして使う。
Copilotが精度を出しにくい作業もある。社内固有の情報（社内システムのデータ、過去のプロジェクトの詳細など）は学習していないため、そこを聞くと幻覚が起きやすい。最終的な意思決定を要するアウトプットに使う場合は、必ず人間がチェックする前提で設計する。
プロンプトの型を先に作ると展開が速い
社内展開で詰まっているケースに共通していたのは、「プロンプトをどう書けばいいかを人それぞれに探索させている」という状況だ。
担当者が先に「型」を作り、それをチームに配布する方法を勧める。
型の作り方：
- よく使う業務を1つ選ぶ（例：会議後のサマリー作成）
- その業務でCopilotに渡す情報の形を決める（入力フォーマット）
- 期待するアウトプットの形を書く（出力フォーマット）
- この「型」を
PROMPT: ○○業務テンプレートという名前で保管する
たとえばサマリー作成の型：
以下の会議メモから、次の形式でサマリーを作成してください。
【形式】
- 決定事項（箇条書き・3〜5件）
- 担当者と期日のペア（表形式）
- 次回議題の候補（1〜3件）
【会議メモ】
（ここに会議のテキストを貼り付ける）
型が決まっていれば、チームへの展開も「このテンプレートをコピーして使ってください」で済む。個人が試行錯誤する時間を減らせる。
社内展開で詰まりやすいポイント：「効果の説明ができない」
担当者が上司や経営層に「Copilotを使い続ける理由」を説明しなければならない場面がある。そこで詰まることがある。
「便利になった気がする」では説明として弱い。
効果を示すために測っておくといい指標：
- 業務ごとの作業時間（Copilot使用前後）：メール返信1通の所要時間、報告書作成の所要時間など
- 利用率（週あたりの利用回数）：チームの何割が週1回以上使っているか
- 誤送信・修正件数の変化：ドラフトが増えたことで見直しの機会が増えたかどうか
これらを最初から記録していれば、3か月後に「効果が出たか」を数字で語れる。最初に「何を測るか」を決めておくことが、展開の次のステップに繋がる。
Copilotの利用率をKPIにすることに対して「形式的な利用が増えるだけ」という批判もある（公式の見解ではなく、筆者の考え）。「使った回数」より「使って時間が短くなった業務の数」を指標にする方が実態に近い。
個人情報・機密情報の入力リスクは先に整理する
相談の中で「Copilotに何を入れていいか分からない」という声もあった。これは使い方の問題というより、情報セキュリティのポリシーの問題だ。
Microsoft 365 Copilotのプロンプトや応答は、基盤モデルの学習には使われないという公式の説明がある。一方で、Web検索を使う場合は検索語がBingの検索サービスに送られる。社内のポリシーで「外部サービスへの情報入力の範囲」が定まっていない場合、担当者が判断しにくい。
先に情報システム部門や法務と確認しておく事項：
- 個人情報（顧客の氏名・連絡先など）の入力可否
- 機密扱いの社内文書の入力可否
- 外部委託契約の内容をCopilotに読み込ませる可否
これが曖昧なまま展開すると、「問題が起きたときに誰が責任を取るか分からない」という状況になる。展開の前に整理しておくことを勧める。
今回まだ整理できていないこと
- Copilot Studio（社内カスタムエージェント）を組み合わせた場合のチーム展開のパターン（別途まとめる）
- 利用が定着したチームがその後どんな使い方を広げたか
- 部門ごと（総務・営業・エンジニアチーム）の展開で変わる部分（今回は一般的なパターンに留めた）
大企業でAIエージェントの本番稼働を増やしていくときに感じていることを、別の記事にまとめた。
https://note.com/light_tern636/n/n5d27b048b357