Microsoft 365 Copilotが使えない・期待した回答を返さない原因と対処｜切り分けフローチャートARTICLE

※ Microsoft 365 Copilot は、2026年8月から「Microsoft Copilot」に名称が変わりました（Copilot Chat は「Microsoft Copilot Chat」）。移行期間中は旧名称も併用されているため、本記事では広く使われている「Microsoft 365 Copilot」の表記で統一しています（出典：Microsoft Learn「Microsoft Copilot のデータ、プライバシー、セキュリティ」）。

「Copilot に聞いても、社内の資料を見つけてくれない」「前任者が作った手順書があるはずなのに、ないと言われる」「そもそも Word に Copilot のボタンが出てこない」——Microsoft 365 Copilot を使い始めた部門から、最初の数週間に必ず寄せられる問い合わせです。

パイロット中にこうした声が続くと、「Copilot は使えない」という評価が一気に広がります。しかし支援の現場で原因をたどると、AIの性能そのものが原因であることは多くありません。ライセンスの割り当て、使っている Copilot の種類、データの置き場所、権限、検索の設定、そして聞き方——原因のほとんどは、確認すれば切り分けられる場所にあります。

本記事は Copilot 導入ロードマップシリーズの番外編として、「期待した回答を返さない」ときの原因を7つに切り分けるフローチャートと、それぞれの確認方法・対処を、Microsoft の公式ドキュメントをもとに整理します。

この記事の要点

• 「Copilot が期待した回答を返さない」原因は、ライセンス・Copilot の種類・データの置き場所・権限・インデックスと検索設定・Web 検索の設定・プロンプトの7つにほぼ切り分けられます
• 7つを確認しても長い資料で答えがおかしい場合は、AIが一度に読める量（コンテキスト）の限界を疑います。分けて渡しても足りない業務には、その業務専用の RAG（検索拡張生成） を作る選択肢があります
• 確認は上から順番に行います。ボタンが出ない、社内データを探さない版を使っている、データが Microsoft 365 の外にある、といった前提の問題を先に潰します
• 利用者が自分で確認できる項目と、管理者が確認する項目を分けておくと、問い合わせ対応が速くなります
• K.S.Rogers の支援の現場では、要約させると要件を取りこぼす、同じものが別の名前で書かれている、といったつまずきを、原文のまま渡す・確認の一覧に回すなど渡し方と工程で解いてきました。AI に任せきれない部分は、人の確認や手順を決めた処理に分けます

Microsoft 365 Copilot が期待した回答を返さない ― まず症状を分ける

問い合わせの内容は、次の3つの症状に分けられます。

症状が分かったら、次のフローチャートで原因を絞り込みます。

原因の切り分けフローチャート

上から順番に確認するのがポイントです。たとえば、ライセンスのない Copilot Chat を使っている人にプロンプトの書き方を教えても、社内データを横断して探すことはできません。前提の問題から先に確認します。

以下、原因ごとに確認方法と対処をまとめます。

原因1：ライセンスとアプリの前提

症状：Word・Excel・PowerPoint・Outlook に Copilot のボタンが出ない、Teams の会議後に要約できない。

Microsoft の要件では、デバイスベースのライセンスでは Copilot を使えないこと、Web 版アプリではサードパーティ Cookie が必要なこと、会議終了後に Teams の Copilot が会議の内容を参照するには文字起こしまたは録画が必要なことが示されています（出典：Microsoft Copilot 管理者のアプリとネットワークの要件｜Microsoft Learn）。また、コンテンツを分析する接続エクスペリエンスをオフにすると、Word・Excel・PowerPoint・Outlook・OneNote で Copilot の機能が使えなくなります（出典：Microsoft Copilot のデータ、プライバシー、セキュリティ｜Microsoft Learn）。デスクトップアプリの更新チャネルについては、Copilot ダッシュボードの推奨事項で、最新チャネルまたは月次エンタープライズ チャネルへの参加が必要と案内されています（出典：Microsoft Copilot ダッシュボードに接続する｜Microsoft Learn）。

情報漏えい対策としてプライバシー設定や Cookie を厳しくしている会社ほど、このつまずきが起きやすい点に注意してください。

原因2：使っている Copilot の種類が違う

症状：Copilot は動くが、社内のメールやファイルの内容を踏まえた回答にならない。

「Copilot」という名前のつく機能は複数あり、どれを使っているかで参照できる範囲がまったく違います。

Microsoft Learn では、ライセンスなしの Copilot Chat は主に Web をもとに回答し、Microsoft 365 全体にわたる組織データの横断的な参照は、有償ライセンスの機能として整理されています。また、Word・Excel・PowerPoint・OneNote の画面上に表示されるラベルで種類を見分けられ、「Copilot Chat（基本）」と表示されている場合は、アドオンライセンスがなく、これらのアプリでの Copilot チャットにアクセスできない状態を示します（出典：Microsoft Copilot Chat の概要｜Microsoft Learn）。

利用者に確認してもらうのは次の2点です。

• 職場アカウント（会社のアカウント）でサインインしているか ―― 個人の Microsoft アカウントで個人向けの Copilot を開いていると、社内データは一切参照されません
• 画面に表示される Copilot のラベル ―― 有償ライセンスを割り当てたはずの人が「基本」の表示になっていれば、原因1に戻ってライセンスを確認します

なお、Microsoft 365 Copilot と Copilot Chat は、Microsoft Learn 上でそれぞれ「Microsoft Copilot」「Microsoft Copilot Chat」への名称変更が案内されており、移行期間中は画面や資料によって新旧の名称が混在します。社内の案内資料では、両方の名称を併記しておくと問い合わせが減ります。

原因3：データが Microsoft 365 の外にある

症状：「あるはずの資料」がまったく出てこない。

Copilot が社内データとして参照できるのは、Microsoft 365 の中にあるデータです。Box や Dropbox などの外部ストレージ、社内のファイルサーバー、個人の PC のデスクトップ、LINE WORKS などの外部チャットにある情報は、そのままでは回答の材料になりません。

確認方法は単純で、その資料が SharePoint・OneDrive・Teams・Outlook のどこにあるかを答えられるかです。答えられなければ、Copilot からも見えていません。

対処は2つです。

• Microsoft 365 に移す ―― Copilot に読ませたい資料から優先して SharePoint に移します。全面移行か、読ませたい資料だけを移すかの判断は第2回（前編）：Microsoft 365 Copilotは社内のメールやチャットを「学習」するのかで解説しています
• Copilot コネクタでつなぐ ―― 外部のデータを Microsoft Graph に取り込み、アクセス制御を保ったまま Copilot が参照できるようにする仕組みです。テキストの多いコンテンツで効果を発揮します。利用条件はライセンス要件のページで確認してください（出典：Microsoft Copilot のセマンティック インデックス作成｜Microsoft Learn）

原因4：権限（見えない／見えすぎる）

症状：同僚には出てくる資料が自分には出てこない。あるいは、見えてはいけない資料が出てくる。

Copilot は、質問した本人が少なくとも閲覧権限を持つデータだけを回答に使います（出典：Microsoft Copilot のデータ、プライバシー、セキュリティ｜Microsoft Learn）。確認方法は、そのファイルを本人が SharePoint や OneDrive で直接開けるかです。開けなければ Copilot にも見えません。

権限以外に、ファイルの保護のかけ方でも結果が変わります（出典：Microsoft Purview データセキュリティとコンプライアンス保護｜Microsoft Learn）。

• 暗号化を伴う秘密度ラベル ―― Copilot がデータを返すには、ユーザーに閲覧（VIEW）と抽出（EXTRACT）の使用権限が必要です。閲覧だけ許可されたラベルのファイルは、開けても Copilot の回答には使われません
• S/MIME で保護されたメール ―― Copilot からは返されません
• パスワードで保護されたドキュメント ―― ユーザーが同じアプリで開いている場合を除き、Copilot はアクセスできません

逆に「見えすぎる」場合、つまり本来見るべきでない人事資料や役員会の資料が回答に出てきた場合は、Copilot の不具合ではなく共有設定が緩いまま放置されていることが原因です。これは問い合わせ対応ではなく、情報管理上のインシデントとして扱い、権限の是正を優先してください。

原因5：インデックスと検索の設定

症状：権限もあり、Microsoft 365 の中にもあるのに見つからない。追加したばかりの資料が出てこない。

Copilot は、Microsoft 365 の検索の仕組み（インデックス）を使って社内データを探します。ここでのつまずきは3つあります（出典：Microsoft Copilot のセマンティック インデックス作成｜Microsoft Learn、SharePoint サイトとコンテンツの検出を制限する｜Microsoft Learn）。

特に、Copilot 導入の準備として「機密性の高いサイトをいったん検索対象から外す」対応をした会社では、その後の解除漏れがよく起きます。どのサイトをいつ、なぜ外したかを記録しておきます。

また、セマンティック インデックスが対応するファイルの種類として、Word、PowerPoint、PDF、Web ページ、OneNote などが示されています。一覧にない種類のファイルの中身を探させたいときは、ファイルを直接指定して聞くほうが確実です。

原因6：Web 検索の設定

症状：最新のニュースや法改正、取引先の公開情報について聞くと、古い内容や「分からない」という回答になる。

Copilot は、質問に Web の最新情報が役立つと判断すると、Bing 検索に検索クエリを送って回答に使います。この Web 検索は、管理者が「Copilot での Web 検索を許可」ポリシーで、テナント全体または特定のグループやユーザー単位で制御できます。ポリシーを構成していない場合は既定で使えますが、「Office での追加のオプション接続エクスペリエンスの使用を許可する」を無効にしていると Web 検索も使えなくなります。Web 検索がオフの場合、Copilot は基盤の大規模言語モデルだけで回答を作ります（出典：Microsoft 365 Copilot Chat の管理｜Microsoft Learn）。

情報管理の方針として Web 検索をオフにするのは1つの判断です。その場合は、「最新の外部情報は Copilot では調べられない」ことを利用者に周知しておかないと、「Copilot は古いことしか知らない」という不満につながります。

原因7：プロンプト（聞き方）

症状：回答は返るが、的外れ、一般論ばかり、別の案件の話が混ざる。

ここまでの前提がそろっていれば、残る原因は聞き方です。Microsoft は、プロンプトに次の4つの要素を含めることを勧めています（出典：Copilot チュートリアル：適切なプロンプトの内容｜Microsoft サポート）。

社内データを探させるときに特に効くのがソース（参照先）の指定です。SharePoint のドキュメント ライブラリやフォルダーを添付したり、その URL をプロンプトに含めたりすると、Copilot はその範囲に絞って探し、ライブラリの列の情報も手がかりにします（出典：Microsoft Copilot のセマンティック インデックス作成｜Microsoft Learn）。

3つ目の例のように、古い版のファイルが権限の範囲内に残っていると、Copilot はそれを根拠に答えることがあります。プロンプトの工夫と並行して、旧版をアーカイブに移すなど、置き場所の整理も進めます。

もう1つの原因：一度に読める量には限りがある（コンテキストの上限）

症状：長い資料について聞くと、後半の内容を答えない。途中に書いてあることを「書かれていない」と言う。資料にないことを、もっともらしく答える。

ここまでの7つを確認しても直らない場合に疑うのが、AI が一度に読める量の限界です。フローチャートの7つがすべて「はい」でも起きるため、別に扱います。

AI は「机の上に載った分」しか読めない

Copilot の中で文章を作っている AI（大規模言語モデル）は、質問と一緒に渡された資料を読んで答えます。このとき、一度に読める量には上限があります。この「一度に読める範囲」をコンテキストと呼び、上限のことをコンテキストの上限（コンテキストウィンドウ）と呼びます。

たとえるなら、AI は決まった広さの机で仕事をしています。机に載った資料は読めますが、載りきらない資料は読めません。数百ページのマニュアルや、何年分もの報告書を丸ごと渡しても、机に載らなかった部分は読まれないまま答えが作られます。

Microsoft も、Copilot に長い文書を渡したときについて、次のように説明しています（出典：参照とドキュメントの長さが Copilot の応答に与える影響｜Microsoft サポート）。

• 頼む内容によっては、Copilot が文書の先頭だけに焦点を当てて、それ以降を無視する場合がある
• 大規模言語モデルはファイルの先頭と末尾を優先しやすく、長いファイルでは中間の内容に注意が向きにくい

読めなかった部分を「推測」で埋めると、ハルシネーションになる

困るのは、読めなかったときに AI が「読めませんでした」と言うとは限らないことです。読めた範囲の情報から、もっともらしい答えを組み立ててしまうことがあります。資料に書かれていないことや、事実と違うことを、それらしく答えてしまう現象をハルシネーション（幻覚）と呼びます。

「規程の第12条について聞いたら、存在しない条文を答えた」「300ページの仕様書の後半にある数値を聞いたら、前半の別の数値を答えた」といったケースは、プロンプトの問題ではなく、読める量の問題であることがあります。

まずは利用者側でできる対処

• 資料を分けて渡す ―― 長い文書は章ごとなど小さく分けて、1つずつ Copilot に渡します。Microsoft も、長い文書は分割し、まとまりごとに要約する方法を勧めています（出典：同上）
• 聞く範囲を指定する ―― 「第3章について」「2026年度版の規程の第12条について」のように、見てほしい範囲をプロンプトではっきり伝えます。参照先のファイルを指定する方法は、原因7の「ソース」と同じです
• 全体の要約と、細部の質問を分ける ―― 全体の要約は章ごとに作ってからまとめさせ、細かい数値や条文は、該当する部分を指定して聞きます
• 回答の根拠を確かめる ―― 数値・固有名詞・条文は、回答に示された引用元の該当箇所を開いて確かめます

要約は便利ですが、細部を落とすことがあります。細部が大事な業務では、要約に頼らない渡し方も考えます。

K.S.Rogers の現場から

医療分野の会社様で、資料を AI で作る仕組みを検証したときは、改定項目を AI に要約させると、資料に必要な要件を取りこぼすことが分かりました。そこで、改定項目は要約させず、原文の「具体的な内容」をそのまま載せる処理に変えました。要約が向くのは全体をつかむときで、条件や数値を漏らせない部分は、原文のまま渡す・載せるほうが確実です。

それでも足りない業務には「RAG」を作る

実は、Microsoft 365 Copilot が社内の資料を探して答えるときも、資料を丸ごと AI に渡しているわけではありません。質問に関係しそうな部分を検索で探し、その部分を AI に渡して答えさせています。このように、検索で必要な部分だけを取り出してから AI に答えさせる仕組みを、RAG（Retrieval-Augmented Generation、検索拡張生成）と呼びます。Microsoft は、RAG は企業のデータを検索する仕組みと、取り出した情報をもとに文章を作る仕組みを組み合わせ、誤った情報を減らし、実際の組織の資料に根ざした回答を作るものだと説明しています（出典：検索拡張生成で AI 応答を強化する｜Microsoft Learn）。

多くの業務は、Copilot の標準の機能と、上の工夫で足ります。ただ、次のような業務では、その業務専用の RAG を作ることを検討します。

一方で、Microsoft は、RAG が向いているのは事実を確かめる質問への回答や、方針・手順の要約であり、文書全体を比べたり、長い文書を通して複雑に推論したりする用途には向かないとも説明しています（出典：同上）。「何でも答える社内AI」を作るのではなく、答えさせたい業務と、根拠にする資料を絞って作るのが、RAG を役立てるコツです。

資料の形に合わせた工夫は、実際に作ってみて初めて必要だと分かることが少なくありません。

K.S.Rogers の現場から

先ほどの医療分野の会社様の検証では、縦書きの告示が、そのままでは検索に当たりませんでした。読み取り方を変えて、検索に当たるようにしています。また、同じものが資料によって別の名前で書かれていたため、用語の対応表を作って表記をそろえました。ただし、文脈によって意味が変わる語は自動では置き換えず、担当の方が確かめる一覧に出す形にしています。置き換えを間違えると、もっともらしい誤りがそのまま残るためです。

それでも解決しないとき

7つの原因を確認しても期待どおりにならない場合は、次を確認します。

• サービスの障害や既知の問題 ―― 管理者が Microsoft 365 管理センターのサービス正常性で、Copilot に関する障害や既知の問題が出ていないかを確認します
• 製品の仕様 ―― 機能によっては対応するアプリやファイル形式、処理できる量に制約があります。Microsoft Learn の該当ページで最新の仕様を確認します。処理できる量については、前述の「一度に読める量には限りがある」も確認します
• AI の回答の性質 ―― Microsoft は、生成AIの回答が100%事実であるとは保証されず、他者に送る前に利用者が内容を確認する必要があると説明しています（出典：Microsoft Copilot のデータ、プライバシー、セキュリティ｜Microsoft Learn）。数値や固有名詞、規程の条文などは、回答に示された引用元の資料で確かめる運用にします

AI に任せきれない部分は、人の確認や、手順を決めた処理に分けておくと、使える範囲がはっきりします。

K.S.Rogers の現場から

前述の検証では、名称が変わった項目が「削除＋追加」として出てしまい、AI だけでは正しく扱えませんでした。この部分は担当の方の確認が要ると明示して、工程に組み込んでいます。また、別の支援先では、Copilot に処理を任せたところ精度が足りなかったため、手順として決められる部分は Office Scripts でロジックを組み、確実に処理する形に変えました。AI に頼る部分と頼らない部分を分けるのも、立派な対処のひとつです。

利用者と管理者の確認の分担

問い合わせ対応を速くするには、利用者が自分で確認する項目と、管理者が確認する項目を分けておきます。

利用者側の5項目は、社内の FAQ やポータルに「問い合わせる前に確認すること」として載せておきます。それでも解決しない場合は、次の情報を添えて管理者に問い合わせてもらうと、原因の特定が早くなります。

• 使ったアプリ（Word、Teams、Copilot Chat など）と、画面に表示されていた Copilot のラベル
• 入力したプロンプトの全文
• 期待していた回答と、実際に返ってきた回答
• 探してほしかった資料の保存場所（URL）

問い合わせを原因1〜7に分類して記録しておくと、「権限の問い合わせが多い部門」「プロンプトの問い合わせが多い部門」といった傾向が見え、研修や整備の優先順位を決める材料になります。

パイロット中によくある問い合わせと対処

最後に、パイロットの時期に特に多い問い合わせを、原因と対処の組み合わせで整理します。

K.S.Rogers の支援

K.S.Rogers では、Microsoft 365 Copilot の導入後に「思ったように使えない」という状態を、原因の切り分けから立て直す支援を行っています。

• 問い合わせの原因分類と、利用者向け FAQ・問い合わせ様式の作成
• ライセンス、アプリの更新チャネル、プライバシー設定、Web 検索ポリシーの点検
• SharePoint の権限・検索設定の棚卸しと、データの置き場所の整理
• 部門の業務に合わせたプロンプト研修
• RAG（検索拡張生成）の開発 ―― 標準の Copilot では答えきれない業務向けに、社内のマニュアルや過去資料、Microsoft 365 の外のデータを検索して根拠つきで答える仕組みを、業務と資料を絞って開発します

「長い資料や大量の資料を正確に答えさせたい」「社内のシステムのデータも使って答えさせたい」といったご相談では、Copilot の設定で解決できるか、RAG を作るべきかの見極めから一緒に行います。

M365 の導入・ファイル移行から Power Platform・Copilot の活用までの支援の範囲と進め方は、Microsoft 365 導入・活用支援のページにまとめています。

Copilot 導入の全体像は第1回：非IT企業のMicrosoft 365 Copilot導入ロードマップで解説しています。「導入したが使われていない」「問い合わせに追われている」といった段階からご相談いただけます。お問い合わせからお気軽にご連絡ください。

まとめ

• 「期待した回答を返さない」原因は、ライセンス・Copilot の種類・置き場所・権限・インデックスと検索設定・Web 検索・プロンプトの7つに切り分けられます
• 確認はフローチャートの上から順番に。前提の問題を潰してから、聞き方の改善に進みます
• 7つを確認しても長い資料で答えがおかしい場合は、AI が一度に読める量（コンテキスト）の限界を疑います。読めなかった部分を推測で埋めるとハルシネーションになります。資料を分けて渡し、範囲を指定し、それでも足りない業務には専用の RAG を作ります
• 「見えてはいけない資料が出る」は Copilot の不具合ではなく、共有設定の問題です。インシデントとして権限の是正を優先します
• 利用者と管理者の確認項目を分け、問い合わせを原因ごとに記録すると、研修と整備の優先順位が見えてきます