SharePointに最新版があるのに、なぜMicrosoft 365 Copilotは古い数字を返すのか
・ 読了 約12分

多くの企業ではM365を導入してファイル共有にはSharePointを使用してるかと思います。Copilotが使用しているモデルの進化もあり、ファイルの探索、文章の要約やデータの提示などがかなり有効になってきたと感じています。
しかし、そういった中でもAIが普及する以前の感覚でファイルを扱っていると思わぬ結果が返ってきてしまう可能性があります。
例えば、SharePoint内で受注のレポートなどを管理していたとします。そうして、Copilotに「先月の受注実績を教えて」と聞いたら、古い数字が返ってきた。もしくは、それらしいデータが返ってきたけれど自分の記録と合わない数字が返ってきた。
こうしたとき、自分が入力したプロンプトやCopilotの精度に問題があると判断するのは早いかもしれません。間違っているのは数字の読み取りではなく、どの情報を根拠にしているかである可能性があるからです。
30秒でできる切り分け
同じ質問を、二通りで聞き比べてみます。
- そのまま聞く(「先月の受注実績は?」)
- 正しいファイルやフォルダを明示して聞く(「このファイルをもとに、先月の受注実績を教えて」)
2番目のようにファイルやフォルダを提示した聞き方で正しく答えるなら、少なくとも問題の中心ではプロンプトやモデルの能力ではなく、情報の探索範囲が原因にあります。

現在のMicrosoft 365 Copilotでは、個別のファイルだけでなく、フォルダ全体を情報源として指定できます。SharePointサイトを選び、その中の情報に質問の範囲を絞ることも可能です。さらに、SharePointのドキュメントライブラリやフォルダを添付するかURLを指定すると、Copilotはその範囲にあるファイルと、ライブラリに設定された列を手掛かりに、回答に使う情報を絞り込むこともできます。
したがって、2番はCopilotに備わっている参照範囲を指定して、「この範囲の情報に限定してとして答えてほしい」と明示する切り分けです。
Copilotは「最新版」というファイルを探しているわけではない
昔からの慣習で、「2026_受注一覧_最新版.xlsx」などファイルの拡張子の前にバージョン識別子のようなものをつけて管理することは少なくないかと思います。しかしCopilotが、ファイル名に含まれる「最新版」という文字を、正本を判断する決定的な基準として扱うとは限りません。Microsoft 365 Copilotは、質問を受けると、Microsoft Graphやセマンティックインデックスなどの仕組みを使って、ユーザーがアクセスできる情報の中から関連する内容を取り出し、それらを材料にして回答を作ります。
Microsoftの公式の説明でも、検索結果は単純なファイル名の一致だけでなく、内容の近さ、利用者と情報との関係、アクセス権などをもとに順位付けされると記載されています。つまりCopilotは、社内にあるすべての資料を読み比べて「これが正式な最新版だ」と確定してから答えているわけではないのです。
「受注実績」に関係する資料が他にも複数あれば、そのどれもが回答の候補になりえます。Copilotから見れば、内容がよく似た二つの資料のうち、どちらが正しいかを判断する材料がない可能性が生じてしまうのです。
参考:Semantic indexing for Microsoft 365 Copilot(Microsoft Learn)
そもそも、別ファイルにバージョン名を付けて管理するのではなく、SharePoint上の同じファイルを共同編集すべきなのは言うまでもありません。過去の状態は、バージョン履歴から確認・復元できます。
しかし、実態としては社外とのメール添付やローカル作業が残る現場ではこういったことが起こる可能性はまだまだあると感じています。そのため、まずは運用を社内全体で確立することが重要だと考えています。SharePoint上で共同編集が定着した組織では、問題の中心が「同じファイルの版」から、別々の目的で作られた複数のファイルや保存場所へ移っています。
参考:Document collaboration and co-authoring(Microsoft Support)、Version history overview(Microsoft Learn)
バージョン履歴では解決しない「別のファイル」
次に起こりうる問題です。たとえば、営業部のSharePointに正式な 受注実績.xlsx があるとします。それでも、業務の中では次のような資料が生まれます。
- 営業部 SharePoint / 受注実績.xlsx
- 役員会 SharePoint / 月次報告_7月.xlsx
- Aさんの OneDrive / Microsoft Teams Chat Files / 受注実績_会議用.xlsx
- 基幹システムから出力した 受注明細_20260731.csv
これらは、同じファイルの過去バージョンではないものです。それぞれ目的の違う別のファイルとして扱われており、個別に現在の版とバージョン履歴を持ちます。
特にTeamsでは、チャネルにアップロードしたファイルはチームのSharePointに保存されますが、1対1やグループチャットに新たにアップロードしたファイルは、送信者のOneDrive for Businessに保存されます。そのため、ファイルを都度アップロードして共有していると、業務資料が組織の共同領域とユーザーごとの領域に分散することがあります。しかし、SharePoint上の既存ファイルをリンクで共有しただけであれば、別のファイルは作られません。
参考:File storage in Microsoft Teams(Microsoft Support)
ここで必要なのは、単なる更新日時ではありません。
- どの場所が正式な保存先なのか
- 元データと会議用資料のどちらを実績値の根拠にするのか
- 月末時点の確定値と、現在まで更新された値のどちらを指すのか
- 誰が数字の責任者なのか
- いつからいつまでを「先月」と定義するのか
人間は業務の経緯や個々人のナレッジから判断できますが、その判断基準がファイルや保存場所に表現されていなければ、Copilotには区別できません。
ファイルを見つけても、表として正しく読めないことがある
もう一つの問題は、Excelの中身です。
人が見て理解しやすい帳票と、集計しやすい表は同じではありません。
- セルが結合されている
- 見出しが2行以上にまたがっている
- 1つのシートに複数の表が並んでいる
- 印刷用の空行・空列が挟まっている
- 同じ列に日付、文字列、数値が混在している
このような表では、「どこからどこまでが一つのデータか」「どの見出しがどの値に対応するか」が曖昧になります。
そのため、見出しを1行にそろえ、結合セルや空行・空列をなくしたうえで、対象範囲をExcelの「テーブル」として設定することが望まれます。テーブル化すると、データの範囲と列見出しが明確になり、CopilotやExcelの分析機能がデータを解釈しやすくなります。1行を1件のデータ、1列を1項目とする構造化された表です。
また、少し余談ではありますが、Excelのテーブル化は、Copilotが内容を理解しやすくするためだけのものではありません。Copilot StudioやPower AutomateからExcel Onlineコネクタを使い、データを行単位で操作する場合は、対象範囲がExcelテーブルとして定義されていることが前提になります。Excelを単なる文書として読ませるのではなく、後から自動化やシステム連携にも使うなら、テーブル化しておくことをおすすめします。
MicrosoftもAnalyze Dataについて、1行の重複しない見出しを付け、結合セルを避けることに加えて、データをExcelテーブルとして書式設定することを推奨しています。
参考:Analyze Data in Excel(Microsoft Support)
「読めるファイル」から「集計できるデータ」へ
Excel内のデータを表形式に整え、対象範囲をExcelのテーブルとして定義することは重要です。しかし、さらに一歩進めるなら、個々のPDFやExcelに散らばっている情報を、共通の項目を持つ構造化データとして蓄積する必要があります。
たとえば注文書のPDFには、注文番号、取引先、注文日、商品、数量、金額などが記載されています。人が見れば注文書だと分かりますが、PDFはレイアウトを保ったまま表示・共有することに適した形式です。当然ながら、取引先ごとにPDFの項目名や配置、レイアウトが異なることも多く、そのままでは複数の注文書を横断して集計できる共通のデータ構造になっていません。
CopilotやOCRを使えば、PDFから必要な項目を読み取ることはできます。しかし、回答のたびに複数のPDFから値を抽出し、「先月分だけを選んで金額を合計する」方法では、帳票ごとのレイアウト差や読み取り誤りの影響を受けます。どの条件で抽出・集計したのかも残りにくいため、同じ処理を再現・検証することが難しくなります。
そこで、PDFを原本として残しながら、必要な項目を共通の表へ取り出します。
注文番号 | 取引先 | 注文日 | 商品コード | 数量 | 金額 | 元ファイル |
|---|---|---|---|---|---|---|
A-1024 | 株式会社A | 2026-07-15 | P-001 | 10 | 120,000 | order_A-1024.pdf |
一つの注文明細を1行、同じ意味の項目を同じ列にそろえ、読み取り結果を確認してからデータとして貯めていきます。これにより、「2026年7月の金額を合計する」という処理は、回答のたびに文書を解釈する作業ではなく、条件を明示して繰り返し実行できるデータの処理に変わります。
重要なのは、PDFを捨てることではありません。
- PDFや受領時のExcelは、原本や証跡として残す
- 必要な項目を、一定の列を持つ表へ変換する
- 表の各行から、元ファイルをたどれるようにする
- 読み取り結果を確認・修正した履歴も残す
この仕組みがあれば、数字を確認する必要が生じたときに、表の各行から元の注文書までさかのぼれます。データの集計自体は、ExcelやBIなどで定めた条件に従って再現可能な形で行い、Copilotは構造化されたデータや集計結果を根拠として、検索や説明を支援します。もちろんCopilotを通してそういった表示をさせることも可能です。
つまり、ファイルは根拠として残し、構造化データを集計と判断に使うという役割分担です。
構造化する利点は、Copilotの回答の精度や検証のしやすさだけではありません。同じデータを集計、検索、BI、他システムとの連携にも利用できます。将来、部門や全社のデータ基盤へ移す必要が生じた場合にも、共通の項目を持つデータとして整っていれば移行しやすくなります。
これはAIのためだけの前処理ではありません。ファイルの中に閉じ込められていた情報を、繰り返し利用できる会社の資産へ変える工程です。
これは管理が悪いから起きているのか
必ずしもそうではありません。むしろ、かなり構造的に起きます。
正式な受注実績と、役員会で説明するための資料は用途が違います。取引先から届く注文書、拠点から集めたExcel、基幹システムから出力したCSVも、元から同じ形ではありません。誰かがコピーし、列を足し、並べ替え、会議に合わせた形へ加工することで業務が回っています。
SharePointのバージョン履歴は、一つのファイルの変更履歴を管理する仕組みです。どのファイルを正本とするか、複数の資料の数字が矛盾したときにどちらを採用するかまでは決めてくれません。
Microsoft自身も、Copilot導入に向けたSharePoint管理の課題として「content sprawl」を挙げています。不要または管理されていないSharePoint/OneDrive上の情報を減らすことが、Copilotの回答の関連性向上につながると説明しています。つまり、Microsoft 365を導入すれば情報の散在が自動的になくなるわけではありません。
参考:SharePoint Advanced Management overview(Microsoft Learn)
それでも毎月、ファイルは増える
仮にここまで整えたとしても、取引先などからPDFやExcelが届いたり、社内のシステムからCSVを出力したり、集計・転記する業務は残るはずです。
問題はファイルが存在すること自体ではありません。ファイルからファイルへ人が加工する過程で、元データ、処理手順、確定した結果の関係が残らないことです。残るのが加工後のファイルだけなら、翌月にはまた別のファイルが生まれます。
この部分は命名規則やバージョン履歴だけでは解決できません。毎月繰り返す取得・読み取り・整形・照合・集計を、再実行できる処理として残し、結果を同じ構造の表へ蓄積する必要があります。
流れとしては、次のようになります。
PDF・Excel・CSVを受領
↓
必要な項目を抽出し、人が確認
↓
共通の列を持つ表へ蓄積
↓
Copilot・集計・BIから利用この形なら、翌月に新しいPDFが増えても、回答対象となる表の構造は変わりません。Copilotに毎回異なる様式を解釈させるのではなく、AIは読み取りや確認を助け、その後の集計は再現可能なデータ処理として行えます。
結論
Microsoft 365 Copilotが正確に答えないとき、モデルだけを疑うのは十分ではありません。
SharePoint上の同一ファイルを共同編集していれば、昔ながらの _最新版 問題はかなり減らせます。しかし、Teamsチャットの添付、個人のOneDrive、会議用の加工版、月次の出力ファイルまで含めると、Microsoft 365の中にも複数の情報源が生まれます。バージョン履歴は、それらを一つの正本にまとめてはくれません。
AIに社内データを読ませる前に必要なのは、すべてのファイルをなくすことではありません。PDFやExcelを原本として残しつつ、そこから必要な項目を構造化された表へ変換し、何を正しい情報源とし、どの処理を経て数字が作られたかを残すことです。
Copilotの精度は、モデルの性能だけで決まりません。こちら側の情報に、正しさを判断できる構造があるかどうかでも決まります。

Resonal編集部
Google Cloudや生成AIの導入、プロダクト開発における役立つコンテンツをお届けします。


