PDFインポートでExcelがシートに分割される。
1つのテーブルにまとめる方法

マルチページPDFのインポートで実際に得られるもの

インポート自体がエラーになることはほとんどありません。問題は間違った形で返されることで、その後のすべての症状はその形に起因します。Power Queryがファイルに接続すると、Navigatorウィンドウには2種類のオブジェクトが表示されます。上部には個々のテーブル、下部にはページ全体です。複数にチェックを入れると、Power Queryは項目ごとに個別のクエリを作成します。Loadを選択すると、Excelは各クエリをそれぞれのシートに書き込むため、5ページの明細書が複数のワークシートになり、必要なテーブルがすべてのシートに分散してしまいます。

これが「1つのPDFが複数のシートに分割される」原因です。ファイルが破損しているわけではありません。コネクタがページごとに見つけた内容をそのまま報告しているだけです。その後、行と列が壊れているように見えるのは、各ページのワークシートが個別に読み取られ、それぞれに独自の列名が割り当てられるためです。

マルチページPDFは、破損した1つのテーブルとして読み込まれるわけではありません。結合されなかった複数の小さなテーブルとして読み込まれるため、どんなに再フォーマットしても修正できないのです。

Power Queryがページごとに1つのテーブルと認識する理由

Power QueryがPDFを誤って読み取っているわけではありません。PDF形式には読み取るべきテーブルが存在しないのです。PDFは固定レイアウト形式として規定されており、ISO 32000として標準化されています。各ページは座標に固定されたテキストとグラフィックのキャンバスです。それらの座標がヘッダー行を持つ3列のテーブルを形成するという考えは解釈に過ぎず、ファイルが論理構造を持つタグ付きPDF（ISO 32000 条項14.8）の場合にのみ、その解釈が形式に含まれます。会計システムや銀行システムからエクスポートされるほとんどのPDFはタグ付けされていません。

そのため、Microsoftのコネクタは推測するしかなく、その推測は単一の関数に公開されています。Pdf.Tablesはデータの取得 > PDFからの背後にあるエンジンです。これはName、Kind、Dataの3つの列を持つテーブルを返し、KindはTableまたはPageのいずれかです。そのオプションの1つが推測の積極性を決定します。MultiPageTablesは、MicrosoftのPdf.Tablesリファレンスによると、「連続するページの類似したテーブルが自動的に1つのテーブルに結合されるかどうか」を制御します。デフォルトはtrueです。

このデフォルト動作が分割の挙動を正確に説明しています。連続するページが同じ構造を共有している場合、検出器はそれらを1つのテーブルとして扱い結合します。ページごとにレイアウトが変わる場合（繰り返されるヘッダーバンド、異なる列数、1ページにだけ表示される集計ブロックなど）、検出器は異なるテーブルとみなし、ページごとに1つ報告します。ドキュメントのページごとの構成要素が強固であればあるほど、フラグメントが発生する可能性が高くなります。

これはほとんどのチュートリアルが省略する部分です。彼らは「追加」をクリックして次に進むように指示しますが、ファイル自体に単一のテーブルが存在しなかったため、コネクタが結合するものがなかったことを説明しません。PDFが何を保持でき、何を保持できないかについての全体像を理解することは、エクスポートを非難する前に価値があります。そのストーリーの広範なバージョンについては、PDFが構造化データになる仕組みを参照してください。

2ページ目のヘッダーがデータ行になる理由

列タイトルは最初のフラグメントにのみ存在します。そのページ以降、同じ単語は単なるセル値です。Microsoft Q&Aのユーザーがこの結果として生じる正確な障害を説明しています：3ページにまたがるPDFテーブルは「3つの別々のテーブルとして識別され」、「最初のテーブルだけが元の列タイトルを含み、他の2つのテーブルはColumn1、Column2などを表示します」。列名が一致しなくなったため、編集せずにテーブルを追加することはできません。完全なスレッドはMicrosoft Q&Aの投稿で読むことができます。

出力の形状を見れば、そのメカニズムは単純明快です。各ページのテーブルは独立して検出されるため、それぞれが独自のヘッダー昇格ステップを取得します。1ページ目では、「先頭行をヘッダーとして使用」が日付、説明、金額を正しく列名に変換します。2ページ目には昇格させるヘッダー行がありません。繰り返されるタイトルは単にデータの最初の行だからです。Power QueryはColumn1、Column2、Column3にフォールバックします。列名の一致によってテーブルを積み重ねるAppend Queriesは、それらを整列させることを拒否します。

ページ区切りで行が半分に分割される場所

ページ区切りは用紙の終端に合わせて配置されるため、折り返された説明文や複数行のセルが2つの行に分かれてしまうことがあります。Microsoft自身のPDFコネクタのドキュメントでは、この問題は「複数行の行の処理」として既知の制限事項に挙げられており、ずれた値を上の行にコピーするTable.FillDownや、隣接する行を結合するTable.Groupを指摘しています。どちらも自動では実行されません。同じページには、EnforceBorderLinesが「枠線が常にセル境界として適用されるかどうか」を制御し、既定ではfalseであるため、完全な罫線なしで描かれた表は誤ったセル境界で解析される可能性があると記載されています。

ここで2つの障害モードが重なります。ページ区切りをまたいで分割されたレコードは2つの行になり、前のセクションのヘッダー問題により、2行目はそれを識別するラベルを失うことが多いため、気づかないかもしれません。結合されたセルや緩いセル境界は列マッピングを悪化させ、これは結合セルが表抽出を壊す理由で説明されている別の抽出問題です。

Excelでの修正：クエリの追加とヘッダーの操作

修復はExcel内で行われ、レイアウトが異なるファイルごとに繰り返す4つの手順です。機能しますが、手動です。コツは、すべてのフラグメントを積み重ねる前に同じように見せかけ、最後に実際のヘッダーを一度だけ復元することです。

2つの注意点があります。手順はクエリに保存されるため、同じファイルの更新は簡単ですが、レイアウトが来月変更されるステートメントは検出を再び壊し、ヘッダーの昇格をやり直す必要があるかもしれません。また、PDFがテキストレイヤーのないスキャンである場合、コネクタはOCRを実行しないため、構造化するものは何もありません。その場合は、スキャンしたPDFをExcelにOCR変換するに該当します。

PDFをページとしてモデル化しない方法

シートごとに1ページという結果は、ページ単位の読み取りの症状です。そのため、代替策はページ単位で読むのをやめることです。目標がページのコピーではなくテーブルである場合、出力を先に定義し、ドキュメントを作業単位にすることができます。これはページレベルの読み取りとドキュメントレベルの理解の違いであり、抽出ツールがページインポーターから分岐し始めるポイントです。

カスタム列抽出では、Invoice Number、Statement Date、Amountなどの列名を入力すると、それらの名前が完成したテーブルのヘッダーになります。ツールは固定位置を読むのではなく、ドキュメントを読んで各値を見つけるため、各ページの上部で繰り返されるヘッダーバンドは、データ行ではなくページの装飾として扱われます。出力は、ページごとに1つのワークシートではなく、レコードごとに1行です。単位がドキュメントであるため、列名が最初のページとずれる可能性のある2ページ目は存在しません。

単一ファイルではなくフォルダの場合も、同じ設計がバッチで適用されます。バッチファースト処理とは、多数のPDFを一度にドロップすると、同じヘッダーを持つ単一のスプレッドシートにマージされることを意味します。つまり、40件の月次明細書が、手作業で組み立てる40枚のシートではなく、1つのテーブルの40行になります。クエリエディタなしでそれを行う方法は、コードなしでのドキュメントのバッチ処理で説明されています。コミットする前に自分のファイルで出力形状を確認したい場合は、以下の埋め込みデモがサンプルで実行されます。

各ページが独立したドキュメントである場合

1つの連続したテーブルが正しい答えとなるのは、各ページが同じレコードに属している場合だけです。そうでない場合もあります。PDFが無関係な1ページのドキュメントの連続である場合、ページごとに異なる顧客の明細書である場合、数十枚の別々の請求書のスキャンである場合、それらを1つの包括的なテーブルにまとめると、分けておくべきレコードが結合されてしまいます。適切な対応は、より良いインポートではなく、グループ化のルールです。

それがマルチページマージの目的です。これは、抽出されたどの結果が同じ論理ドキュメントに属するかを決定するテンプレート設定であり、グループ化の方法を設定します:追跡対象の列の値が変わるたびに新しいグループを開始する、バッチ全体で参照番号を共有する行を一致させる、または一定数のアップロードごとにグループ化する。グループの複数のページに同じフィールドが表示される場合、重複の解決方法を選択します。最初の値を保持する、最後の値を保持する、連結する、または別々の行に分割する。重要なのは制御の方向です。ツールはどのページが属しているかを黙って推測するのではなく、ルールを指定すると、そのルールを一貫して適用します。

実際に属しているページの正確性もチェックに値します。それがBbox支援検証機能付きレビューモードが提供するものです。抽出されたセルにカーソルを合わせるかクリックすると、元の画像でその値がどこから来たのかがハイライト表示され、逆も同様です:ドキュメント上の領域をクリックすると、対応するセルにジャンプします。ハイライト表示は、単一ファイルに対してオンデマンドでトリガーすることも、処理後に自動的に実行するように設定することもできます。1桁の読み間違いが重要な明細書では、この視覚的なクロスチェックはページを読み直すよりも高速です。

FAQ

ExcelのPDFからのインポートで、複数ページのテーブルが自動的に1つのシートに配置されることはありますか?

場合によってはあります。連続するページが同じテーブル構造を共有する場合、デフォルトでtrueに設定されているMultiPageTablesオプションにより、それらは1つのテーブルに結合されます。ページごとにレイアウトが異なる場合は、別々のテーブルとして検出され、別々のワークシートに配置されます。任意のページを1つのテーブルに強制する設定はありません。

ページ2と3にヘッダーではなくColumn1とColumn2が表示されるのはなぜですか？

各ページの表は個別に検出されるため、ページ1に適用したヘッダー昇格は引き継がれません。最初のフラグメントだけが実際のヘッダー行を持ち、以降のフラグメントはプレースホルダー名を使用します。そのため、名前が一致するまでAppend Queriesが失敗するのもこのためです。

Google Sheetsで複数ページのPDFを1つの表としてインポートできますか？

Google Sheetsには、Power QueryのようにPDF内の表を検出するネイティブコネクタはありません。一般的な回避策は、PDFを中間形式に変換してからインポートするか、スプレッドシートを直接返す専用の抽出ツールを使用することです。どちらもページごとのシートを避けられますが、クリーンアップを回避できるのは抽出ルートだけです。

PDFがテキストレイヤーのないスキャンの場合はどうすればよいですか？

Power QueryのPDFコネクタはOCRを実行しないため、純粋な画像スキャンには構造化するテキストがありません。最初にOCRステップが必要か、画像を直接読み取るツールが必要です。トレードオフについてはスキャンPDFからExcelへのガイドで説明しています。

シートの分割を止めるワンクリック設定はありますか？

いいえ。この動作はチェックボックスではなく、PDFがコンテンツを保存する方法に起因します。最も近い組み込みのレバーは、構造が一致する場合のMultiPageTablesと、それ以外のすべてに対するAppend Queriesとヘッダーステップです。ファイルが非常に大きい場合、巨大なPDFはページ分割以前に独自の問題を引き起こします。また、Copilotがクリーンアップを吸収してくれると期待していた場合、その期待には独自の理由があり、CopilotがPDFからExcelへの変換で苦戦する理由で説明しています。

インポートする代わりにPDFをExcelに変換するだけではダメですか？

可能です。ドキュメントが単一のクリーンな表で、数値を一度だけ必要な場合は合理的な選択です。入力が異なる形式のドキュメントのフォルダで、出力が一貫した列を維持する必要がある場合、列ベースのPDFからExcelへの変換の方が安定した経路です。ヘッダーがページごとに検出されるのではなく、あなたによって定義されるためです。

分割を損傷ではなくモデリングの選択として見ると、判断は容易になります。ファイルが数個あり、クエリを維持する時間がある場合は、Excelの追加と昇格のシーケンスで十分です。表が目的でページが単なるパッケージである場合は、必要な列に名前を付け、ドキュメントを作業単位にしてください。設定なしで自分のステートメントでテストし、次の複数ページのPDFが1つの表として着地するか、シートの山として着地するかを確認できます。