CopilotはExcel内部で動作するように作られており、
PDFからデータを抽出するためのものではありません
Microsoftの公式ガイドによると、Copilot in ExcelはPDFを編集可能なスプレッドシートに変換できるとされています(Microsoft)。しかしr/excelのスレッドでは異なる意見が見られます。あるユーザーはCopilotが「PDFをExcelに変換するという簡単なリクエストを処理できなかった」と書き、ChatGPTは「完璧な出力で数秒で完了した」と報告しています(r/excel)。この差は、単なる機能の不具合ではなく、より具体的な原因に由来します。それは、会話型アシスタントが、そもそも想定されていない作業を依頼されているということです。

重要なポイント
- おそらくプロンプトの問題ではありません。Copilot in Excelはワークブックを編集するために作られており、PDFのフォルダをテーブルに変換する作業は、Copilotの役割が始まる前の段階だからです。
- 個々のフィールドで86%のスコアを出すツールでも、行全体が完全に正しい割合は半分未満です。
- より良いプロンプトを探すのはやめましょう。解決策は、列名を一度設定し、フォルダ全体を単一のバッチで処理することです。
Copilot in ExcelとPDFからテーブルへの変換ツールは、異なる2つの問題を解決している

Copilotは、ワークブック内にすでにあるデータに対して推論します。PDFのフォルダをそのデータに変換する作業は、Copilotの作業が始まる前に行われる仕事です。
Copilot in Excelの公式な役割はワークブックです。 Microsoftはこれを「ワークブックの作成と編集」を支援する機能と説明しています。数式の生成と説明、チャートやピボットテーブルとしてのインサイトの返却、テキスト列のハイライト、並べ替え、フィルタリング、要約などです。これらのタスクはすべて、シート上にすでに存在するテーブルから始まります。
PDFからテーブルへの変換は取り込みの作業です。データはワークブックの外にあり、文字がページ上のどこに配置されているかを保存するファイル形式で存在します。どの列に属するかは保存されません。すべてのファイルから、必要な列を持つテーブルにデータを取り込むことは、分析が始まる前に行われる独立したステップです。
Microsoftは取り込み用の別パイプラインを長年にわたって提供してきました。古いデータ → データの取得 → ファイルから → PDFからインポーターは、PDFに含まれるテキストレイヤーのみを読み取るため、スキャンされた文書では何も返しません。そのパスとCopilotのパスは同じコードではなく、どちらも50種類の異なる形式のファイルから同じ列セットを生成するようには作られていません。PDFから構造化データへの変換ガイドでは、各変換方法がどのファイルタイプでなぜ失敗するかを詳しく説明しています。
2つの作業を分けて考えることで、そのスレッドでの不満がブランド論争にならずに説明できます。Copilotは分析に失敗しているのではありません。取り込みタスクを渡されており、取り込みはCopilotが最も活用できる情報が少ない領域なのです。
Copilot in Excelが本当に得意なこと
Copilotは、設計された用途の仕事には優れています。同じ懐疑的なスレッドもそれを認めています。
使い続けたユーザーは、Copilotを「数式の生成に優れている」と評し、会議の議事録、文書の要約、技術トピックの分析構築に役立つと述べています。ある返信は、実際の価値を率直に語っています。「本当に役立ったと感じたのは、VBAを書くことだけだ」。データがすでにシート上にある場合、Copilotに数式の説明を求めたり、外れ値を指摘してもらうのは、AIアシスタントとして合理的な使い方です。
正直な分かれ目は、データがまだワークブックに存在するかどうかです。
| 行っている作業 | Copilot in Excel | バッチ抽出ツール |
|---|---|---|
| データがすでにシートにある | 最適:数式、インサイト、ピボット、要約 | 目的外。データはすでに構造化されている |
| 一度だけ必要なクリーンなPDFが1つ | 手動での貼り付けとクリーンアップ後、通常は機能する | 機能するが、一度きりのケースにパイプラインは不要 |
| 同じフィールドを持つPDFのフォルダ | 不安定:一度に1ファイル、実行ごとにヘッダーがずれる | 設計されたケース:すべてのファイルから同じ列を抽出 |
| 毎月繰り返す実行 | 不適切:再プロンプトでずれが再発する | 同じ列セットを再利用してバッチを再実行 |
ソースデータがテーブルになれば、Copilotが引き継いで有用な作業を行えます。問題は、その瞬間までに発生するすべてのことです。
会話型アシスタントが反復抽出で失敗する理由
チャットアシスタントの4つの構造的特性が反復抽出の妨げになっており、どれもプロンプトを改善しても解決しません。
出力形式が保証されていません。 Microsoft自身のFAQによると、Copilotは「間違いを犯したり、情報を誤解したり、不正確な結果を生み出すことがある」ため、「財務、法律、医療などのデリケートな分野での判断」には使用しないよう推奨しています(Microsoftサポート)。廃止されたCopilotワークシート関数も同様の警告をより明確な形で示していました。結果は「同じ引数でも時間の経過とともに変化する可能性があり」、「正確性や再現性」が必要な場合は、Microsoftはユーザーにネイティブの数式を利用するよう案内していました(COPILOT関数)。メーカー自身が財務判断での信頼を避けるよう言うツールは、優れた思考パートナーにはなっても、信頼できる記録システムにはなり得ません。
列の契約がありません。 テーブルを依頼すればテーブルは返ってきますが、毎回同じテーブルが返るとは限りません。次の実行では「Invoice Date」が「Date」に変更されたり、列が移動したり、2つのフィールドが1つに統合されたりする可能性があります。r/excelスレッドのユーザーはこの影響を正確に表現しています。「まったく同じデータと指示でも、結果が大幅に異なる」。40のファイルが40の微妙に異なるテーブルを生成する場合、マージと名前変更の作業は、時間を節約しようとしていた人に跳ね返ってきます。
一度に1つのファイルを処理するように設計されています。 OpenAIのファイルアップロードドキュメントでは、ドキュメントファイルは各2百万トークン、画像は20MBに制限されており、これらの制限はフォルダではなく単一の会話に適用されます(OpenAI)。3つのテーブルがある12ページの銀行明細書は、まさにこれらの上限に達する形状であり、失敗は静かに起こります。回答がドキュメントより短くなって返ってくるのです。スキャンされたファイルはさらに悪化させます。ツールがページを画像として扱わない限り、読み取るテキストレイヤーがないためです。これについてはAIがPDFからデータを抽出できるかで説明しています。
レコードレベルの精度は、フィールドレベルの精度よりもはるかに低いです。 これはほとんどの人が目にしない数字です。Cleanlabの構造化出力ベンチマークは、Field Accuracy(正しい個々のフィールドの割合)とOutput Accuracy(すべてのフィールドが正しいレコードの割合)を区別しています。Data Table Analysisセットでは、gpt-4.1-miniはフィールドレベルで86.3%、レコードレベルで45%を記録しました。保険金請求の抽出では、レコード精度はフロンティアモデル全体で30%から40%の間でした。PII抽出では26%から46%に低下しました(Cleanlab)。
90%のようなフィールド数値は、行全体が必要になるまでは安心に聞こえます。 各95%の10フィールドでは、任意の行が完全にクリーンである確率は約60%しか残らず、バッチが大きくなるにつれてエラーが積み重なります。請求書のフォルダの場合、重要なのは何行が正しいかという数字だけです。
Excelの外でも同じパターンが見られます。r/ChatGPTのスレッドで、PDFから請負業者リストを解析する話題がありました。投稿者は1つのドキュメントでは問題なく動作したのに、3つのファイルを結合すると出力が崩れたと報告しています。「100件以上あるはずのスプレッドシートで、4件以上の結果を出力できなかった」と。コメンターはその経験をこう要約しました。「PDF解析は本当に運任せ…ページが欠ける、行が欠ける、値が欠ける」(r/ChatGPT)。より大きなモデルでも、これらの4つの特性は変わりません。だからこそ、バッチ文書処理に特化したツールは、より強力なチャットボットではなく、別のカテゴリの製品なのです。
20分でできるテスト
Excel Copilotが動作しないという検索のほとんどは、結局「これは自分のプロンプトの問題か、それともツールの問題か」という問いに帰着します。何かを切り替える前に、自分のファイルでそれを確認できます。CopilotのPDFからExcelへの変換とChatGPTの両方で、同じチェックを実行することをお勧めします。そのうちの4つが、一度感動したデモと、毎月のプロセスを構築できるツールを区別します。

同じPDFを同じプロンプトで2回実行する
列見出しの行をセル単位で比較します。1つのファイルで2回の実行間で列名やその順序が異なる場合、列の契約は成立しておらず、後続の数式はどれも成立しません。
10ファイルを実行して行数を数える
63件の取引がある明細書は、63行を生成するはずです。各ファイルについて、期待される数値を実際の数値の横に書き込みます。40行しか返さないファイルが、決して自らは知らせない失敗モードです。
異なるレイアウトの11番目のファイルを追加する
別の銀行の明細書や、別のベンダーの請求書を使用します。同一レイアウトでのみ機能するツールは、デモであってパイプラインではありません。実際のドキュメントセットは決して均一ではないからです。
1つの数値を元のページまで追跡する
抽出された単一の値を選び、ソース内のどこから来たのかを特定します。検証のためにすべてのPDFを手動で開き直す必要がある場合、抽出によって節約された時間よりも、信頼にかかるコストの方が大きくなります。
これらのチェックのいずれかが失敗した場合、そのツールは一度きりの使用には適していても、反復可能な作業には不適切です。このテストの目的は、ブランドの評価ではなく、この区別をすることです。
バッチ規模で安定するツールに必要なもの

これらのチェックを通過するツールは、ドキュメントではなく、まず出力契約を中心に設計されています。この単一の設計上の選択が、他のほとんどの特性を生み出します。
最初の要件は、出力する列名を指定し、その名前が結果の正確なヘッダーになることです。これがカスタム列抽出です。モデルに何を返すかを任せるのではなく、「Invoice Number」「Statement Date」「Balance」などのフィールドを入力すると、AIが値の位置ではなく意味に基づいて各値を特定します。列セットはユーザーが決めるため、ファイルが変わっても同じ列構成が維持されます。
2番目の要件は、ツールがファイルではなくフォルダを処理することです。バッチファースト処理とは、50件のドキュメントを投入して1つのテーブルを出力する方式であり、後で手動で貼り合わせる50回の個別処理とは異なります。これは、同じ質問を50回するのと、1つのジョブを1回実行するのとの違いであり、汎用アシスタントが構造的に最も弱いポイントです。
さらに2つの小さな要件があります。同じ列セットを実行するたびにヘッダー行が同一であること、そして抽出された任意のセルを指すと、その値が由来するソースの領域を確認できることです。検証できない値は、手作業で再確認する必要があるからです。このいずれかが欠けているツールは、レビュー工程を省いているのではなく、移しているにすぎません。
ImageToTable.aiは、カスタム列抽出とバッチ処理という2つの主要な要素に基づいて構築されています。ドキュメントをアップロードし、必要な列名を入力すると、その名前がヘッダーとなった1つのスプレッドシートが得られます。この製品は、印刷されたテーブルデータに対して最大99%の精度を謳っており、1ページの処理時間は5〜10秒です。一方、同じページを手作業で入力する場合、約3分かかります。同じアプローチは、データ抽出ソフトウェアの比較でも広く取り上げられており、カテゴリ間ではなくベンダー間での選定を行う場合は、そちらを参照してください。
ファイルは安全に処理され、保存されることはありません。
文書を説明することと、文書から固定のフィールド群を抽出することの違いは、単なる製品機能ではありません。その違いが、出力結果の上に何を構築できるかを左右します。これこそが、汎用アシスタントがスクリーンショット上の同じタスクでは不十分な理由の根拠です。
Copilot、ChatGPT、Claudeが適切な判断となる場合
Copilotは、すでにワークブック内にあるデータに対する単発の作業には適したツールですが、列を一致させる必要がある定期的なバッチ処理には不向きなツールです。
ソースが単一のクリーンなファイルである場合、すでに持っているデータセットを調査する場合、または数式の説明やテキスト列の要約が必要な場合に使用してください。ChatGPTも同じ状況で合理的な選択肢であり、整ったPDFを1つ、最初の試行で正しく変換できるかもしれません。1回の成功は1つのファイルに関するデータポイントであり、フォルダ全体の保証ではありません。
実行が繰り返される場合、ファイルが複数のソースから届く場合、出力がレポートや支払いを支える場合、そして誤ったセルにコストがかかる場合は、専用の抽出ツールに作業を任せてください。文字起こしと抽出の境界線が2つのカテゴリを分けるものであり、手書き文書の抽出について詳しく読む価値があります。そこでは、同じ区別が、数値をまったく信頼できるかどうかを決定します。これらはどれも、汎用アシスタントが悪い製品であることを意味しません。繰り返しと一貫性によって定義される仕事に対して、間違った製品であることを意味するだけです。
Excel CopilotとPDFからExcelへ:よくある質問
Copilot in ExcelがPDFを読み取れないと言うのはなぜですか?
Copilot in Excelは、ワークブック内のデータに対して機能します。フォルダ内にあるPDFは、サポートされている画面で添付しない限り、そのコンテキストの一部ではありません。また、添付した場合でも、テーブルとして読み込まれるのではなく、文書として処理されます。PDFがテキストレイヤーのないスキャンである場合、テキストベースのステップが読み取るものはまったくありません。
ChatGPTはCopilotよりPDFからExcelへの変換に優れていますか?
単一のクリーンなファイルを一度だけChatGPTでPDFからExcelに変換する場合、そう言えることもあります。r/excelのスレッドにはまさにその経験をした人がいます。どちらも汎用アシスタントであり、次回の実行で同じ列名が返ってくる保証はありません。どちらかが一度成功したかではなく、必要なワークフローに基づいて選んでください。
Copilot in ExcelはPDFをテーブルに変換できますか?
Microsoftの公式ガイドでは可能とされており、整ったファイル1つに関しては妥当な説明です。制限は規模と複雑な入力で顕在化します。複数ファイルの一括処理、一貫性のないレイアウト、スキャンされたページなどです。デモで機能する変換と、来月も再実行できるプロセスは別物です。
実行のたびに列見出しが変わるのはなぜですか?
会話型モデルは固定スキーマを埋めるのではなく、毎回回答を生成するからです。出力の形はモデルが決定する一部であり、ファイルや言い回し、あるいは特に理由もなく変わり得ます。定義された列セットだけが列名を固定できます。
PDFからExcelへの変換ツールで何を確認すべきですか?
5つのポイントがあります。出力列を自分で定義できること、1回の実行で複数ファイルを処理できること、実行間で列名が同一であること、抽出値が元のページに追跡できること、テキストレイヤーのあるファイルだけでなくスキャン文書も処理できることです。
これはプロンプトの問題ですか?
ほとんど違います。より良いプロンプトで単一の結果は改善でき、試す価値はあります。しかし、50ファイルにわたって固定の列契約を作るわけでもなく、ファイルサイズや1回の処理ファイル数の上限を引き上げるわけでもありません。これらは構造上の制限であり、言い回しの問題ではありません。
有益な視点の転換は、「どのAIが賢いか」ではなく「このタスクの形は何か」と問うことです。Copilot、ChatGPT、Claudeは、すでに持っているデータを推論するように作られています。PDFのフォルダはまだ手元にないデータであり、それをテーブルにする作業は、賢さではなく反復、固定列、検証によって定義されます。まず自分がどちらの作業をしているのかを決めれば、ツール選びは意見の問題ではなくなります。