Power Queryのフォルダー結合で「キーが一致しない」と失敗するときの確認

フォルダー結合後の「The key didn't match any rows in the table」は、フォルダー内のすべてのファイルが壊れているという意味ではありません。最初に確認するのは、サンプルファイルで選ばれたシート名・テーブル名などのナビゲーション先が、ほかのファイルにも存在するかです。「Column wasn't found」が出る場合は、サンプル変換後に列名が変わったのに、結合後のクエリが古い列名を参照していないかを分けて調べます。元ファイルを一括編集する前に、どのファイルのどの構造が違うのかを特定しましょう。

まずエラーの種類を分ける

同じ「フォルダー結合の失敗」でも、止まっている場所によって原因は異なります。エラー詳細や適用したステップで、最後に成功している処理と最初に失敗する処理を確認してください。

「The key didn't match any rows in the table」は、クエリが指定したキーに一致する行をナビゲーション対象の表から見つけられないときに起きます。Excelブックを読む流れなら、サンプルファイルで選んだItem（シート名やテーブル名）やKind（対象の種類）が、別ファイルでは違う可能性があります。たとえばサンプルでは「売上」というシートを開いていても、ある月だけ「売上表」になっていれば、そのファイルのナビゲーションで一致する項目が見つかりません。

「Column wasn't found」は、ナビゲーションより後の列変換で止まっている可能性があります。列の削除、ヘッダー昇格、列名変更、型変更などの後続ステップが、現在の表に存在しない列を参照している状態です。エラー文に示される列名を、適用ステップの順に照合します。

まずエラーを表示したステップを記録し、エラー詳細でファイル名や列名が分かる場合は控えます。エラーが出る行で「エラーに移動」などの操作が使える場合は、対象行のSource.Nameを確認します。表示名やエラー操作はExcel、Power BI、Power Query Onlineなどのホストや版によって異なるため、手元の画面で名称が違う場合は、クエリのプレビューと適用ステップから同じ情報を探してください。

先にファイル一覧を絞り込む

Power QueryのFolderコネクタは、指定フォルダー内のファイル情報を一覧にします。サブフォルダー内のファイルも含まれる場合があります。Combineをそのまま選ぶと、意図しない一時ファイル、バックアップ、別形式のファイルまで対象になることがあります。

最初に「Transform data」でファイル一覧を開き、Name、Extension、Folder Path、Attributesなど、表示される列を使って対象を確認します。実際の列名は接続先とホストにより異なります。対象拡張子だけに絞り、Excelの一時ファイル（ファイル名が「~$」で始まるもの）や退避フォルダーが混ざっていないかも確認してください。隠しファイルを含めるかどうかは接続元の表示・設定を見て判断します。

除外するファイルを決めるときは、除外の影響を先に調べます。たとえば月別データのうち特定月だけを外すと、更新は成功しても期間が欠けます。除外理由、ファイル名、対象期間、除外後の件数を記録し、業務上必要なデータではないことを担当者が確認してからフィルターを確定してください。「エラーを無視する」設定だけで処理を通すと、どのファイルが落ちたか気づきにくくなります。

サンプルファイルと変換関数を確認する

「Combine files」は、例として選ばれた一つのファイルに対する変換手順を作り、その手順を関数として各ファイルへ適用する構成を作ります。したがって、サンプルファイルの構造が全体を代表していないと、ほかのファイルで失敗します。

Power Query Editorで、生成されたHelper queriesの「Transform Sample File」または同等のサンプル変換クエリを開きます。名前は製品や版で異なることがあります。ここで、どのバイナリを読み、どのItemとKindを選び、何行スキップし、どの行をヘッダーにし、どの列を残しているかを順番に確認します。サンプル変換の途中でナビゲーションの選択を変更した場合、出力クエリ側に以前の列名を参照するステップが残っていないかも点検します。

差を見つけるため、代表する正常ファイルと失敗ファイルを一つずつ開きます。確認する項目は、ファイル形式・拡張子、シート名、テーブル名、見出し行までの空行や説明行、列名、列順、空白列、データ型、追加・削除された列です。比較は「名前が同じか」だけでは足りません。ナビゲーション先が同じでも、後続の列名やヘッダー行が異なれば別のステップで失敗するからです。

表は横にスクロールできます

比較項目	サンプルファイル	失敗ファイル	次に見る場所
拡張子・形式	想定形式	同じ形式か	Folder一覧のExtension
シート / テーブル	ナビゲーション対象	同じItem / Kindか	Workbookのナビゲーション
ヘッダー行	何行目を見出しにするか	ずれ・追加説明行はないか	サンプル変換の行スキップ
列名	変換関数が使う列	欠落・表記違い・空白はないか	失敗ステップと列参照
データ範囲	取込対象	空・別表・複数表ではないか	シート / テーブルのプレビュー

失敗ファイルをSource.Nameから特定する

結合後のテーブルにSource.Nameなどのファイル名列が残っていれば、その列でエラー行を絞り込みます。列名が異なる場合は、Folder一覧で元ファイル名を保つ列を確認してください。対象のファイルを絞り込めない段階で、サンプル変換を変更して全件更新するのは避けます。

特定のファイルでだけエラーが再現するなら、そのファイルを複製または別のテストクエリで調べます。元フォルダーのファイルを直接上書きせず、別の検証用フォルダーまたはQueryのフィルターを使い、正常ファイルと失敗ファイルの違いを一つずつ確認してください。Power Queryのプレビューで、ファイル単位の変換結果が表示できるかを確認する方法もあります。画面操作に依存するため、実際のボタン名やメニュー位置は使用中のホストで確認してください。

原因を記録するときは、「G1077のクエリ」「対象フォルダー」「失敗したSource.Name」「失敗ステップ」「エラーに出たキーまたは列名」「正常ファイルとの差」をひとまとまりにします。個人情報や機密値を含むファイル名・行データを、社外共有用の記録へそのままコピーしないでください。

原因ごとに修正方法を選ぶ

サンプルと同じ構造を持つことが前提のフォルダー結合では、ファイル構造の差をどう扱うかが修正の中心です。全ファイルを一つの規則で変換できるなら、サンプル変換を実データの構造に合わせて直します。シート名が異なる理由が月ごとの命名変更などで、内容の意味が同じと確認できた場合は、明示した候補名から選ぶ処理を検討できます。ただし、存在する最初のシートを無条件に選ぶ方式は、説明用シートや過去データを誤読する危険があります。対象の判定条件を明確にしてから作ります。

特定ファイルが本当に取込対象外なら、結合前のファイル一覧で除外します。逆に、列やシート構成が異なるファイルも必要なデータなら、無理に除外せず、構造別にクエリを分けて共通スキーマへ変換してから追加します。どの方法でも、取り込まれないデータの範囲と影響を説明できることが条件です。

表は横にスクロールできます

観察した差	選択肢	実行前に確認すること
Item / Kindだけが異なる	ナビゲーション条件を調整、または対象名を正規化	候補のシート・テーブルが同じ意味のデータか
ヘッダー行がずれる	サンプル変換で不要行を処理、または構造別に分岐	ずれの規則が全ファイルで一貫しているか
列名が改名・欠落	列名を正規化し、欠損列を許容するか分岐	欠損が「空欄」なのか別定義なのか
一時・対象外ファイルが混入	結合前の一覧でフィルター	除外対象・期間・理由が記録されているか
同じファイル形式でも構造が別	queryを分けて共通表へ整形	共通化によって意味や単位が変わらないか
原因やデータの意味が不明	更新を止めてデータ担当者へ確認	更新成功よりデータ完全性を優先できるか

列名変更後に残る「Column wasn't found」

Transform Sample File側で列名を変更したり、最初の行をヘッダーに昇格したりすると、結合後の出力クエリにある後続ステップが古い名前を参照し続ける場合があります。MicrosoftのCSV結合例では、サンプル変換を変更した後、出力クエリの最後のステップが以前のColumn1を参照してエラーになり、その古いステップを削除することで表示が戻る例が示されています。これはすべてのエラーに同じ削除をすべきという意味ではありません。

出力クエリの「Applied steps」を先頭からたどり、エラーが初めて出るステップを特定します。数式バーまたは詳細エディターで、その式が参照している列名と直前ステップの列一覧を照合します。必要な変換なら新しい列名へ更新します。不要になった古いステップなら、削除した場合に失われる型変換・フィルター・計算列がないか確認してから外します。ステップを一つ削除してエラーが消えても、結果の列数、型、値が意図どおりかまで確認して完了です。

特に自動生成された「変更された型」ステップを見直します。サンプル変換で列名が変わった後に、古い列名を含む型変更ステップが残ると、更新時だけ失敗することがあります。型変更を外すだけで終わらせず、必要な列へ正しい型を設定し直します。日付が文字列に戻っていないか、数値の小数点や通貨がロケールの影響を受けていないか、NULLや空文字がエラーへ変わっていないかを代表値で確認してください。

更新後の検証表

プレビューの一部だけでなく、最終的な更新結果をファイル単位と集計単位の両方で確認します。更新前に対象ファイル一覧と期待行数を記録していると、欠落や重複を見つけやすくなります。

表は横にスクロールできます

検証	記録する値	合格の見方
対象ファイル	ファイル名と対象件数	予定外の一時ファイルや対象月がない
取り込まれたファイル	Source.Name等の一覧	対象一覧と一致し、除外も理由付き
ファイル別行数	元の行数、取込行数	ヘッダー・空行を除く規則が説明できる
合計行数	期待値と更新後	差分があればファイル単位で追える
代表レコード	複数ファイルから同一キー等	重複・列ずれ・文字切れがない
型と欠損	列型、NULL、エラー行	型が意図どおりで、例外に説明がある

元ファイルの総行数とPower Queryの行数が一致しないこと自体は、直ちに失敗とは限りません。見出し行、空行、除外条件、重複排除など、どの規則で差が生じるかをファイル別に説明できる必要があります。期待値が分からない場合は「更新成功」とせず、データ所有者に照合用の件数や代表キーを確認します。

作業を止める条件と次の一手

修正方針は、データの意味が分かるかで選びます。シート名の違いが単なる表記揺れだと資料から確認でき、各ファイルの列構造も一致するなら、変換クエリ側で正規化してから全ファイルを再評価できます。特定ファイルが対象外と確認できるなら、結合前に除外し、対象件数と除外理由を記録します。一方で、別シートが別の業務データなのか、列名変更が意味変更なのか分からない場合は、成功する式を先に作るのではなく更新を止めます。

更新後に「エラーなし」だけを合格条件にしないでください。結合前の対象ファイル数、更新後に残ったSource.Nameの種類、ファイルごとの行数、合計行数、代表レコード、列型を確認します。失敗を隠す目的でエラー行を除外した場合は、除外ファイルと行数を別に記録し、欠損データが許容されることを業務側で判断します。

すぐに着手するなら、次の順番でメモを作ります。

1. エラー全文、失敗ステップ、エラーに表示されるキー・列名を保存する。

2. Folder一覧をTransform dataで開き、対象ファイル名・拡張子・Folder Pathを確認する。

3. 正常なサンプルと失敗ファイルを一つずつ選び、シート/テーブル名、ヘッダー位置、列名、列数を比較する。

4. Transform Sample Fileと出力クエリのApplied stepsを照合し、最初に失敗するステップを特定する。

5. 修正、フィルター、構造別queryのどれを選ぶか、欠落・重複リスクとともに決める。

6. 検証用コピーまたは限定フィルターで更新し、全ファイル名と件数を照合する。

7. 結果と除外を記録してから、本番の更新へ反映する。

UIの名称・配置はExcel、Power BI Desktop、Power Query Onlineなどで異なる可能性があります。またコネクタの能力もホストごとの提供状況に左右されます。この記事は特定版の画面を実測した操作レポートではなく、Microsoftの現行資料に基づく切り分け方です。読者は、所属組織の更新権限、機密データの取り扱い、検証用コピーの作成可否を確認してから作業してください。

まとめ：どのファイルか分かるまで一括修正しない

「キーが一致しない」なら、まずナビゲーション対象のシート・テーブルとKindを正常ファイル／失敗ファイルで比較します。「列が見つからない」なら、サンプル変換で変更した列名と出力クエリの後続ステップを照合します。失敗元をSource.Nameで特定できない、またはシートや列の意味が分からないときは、更新を止めて確認するのが安全です。

原因が単なる構造差なら、サンプル変換の調整、対象ファイルの明示的フィルター、構造別クエリのいずれかを選びます。最後に、対象ファイル一覧、ファイル別・合計行数、代表レコード、列型まで照合できれば、エラーを隠さず結合の完全性を確認できます。