1月、2月、3月のように期間が列へ並ぶ横持ち表は、人が読むには便利でも、ピボットテーブルやデータモデルでは扱いにくい形です。Power Queryのアンピボットを使えば、月の列を「月」と「金額」の2列へ変換し、列が増えても更新で取り込める明細表を作れます。この記事では、教材の横持ちデータを想定し、変換方法、列追加に強い選択、検算、よくある失敗まで順番に解説します。
- 月別・商品別の横持ち表を分析しやすい縦持ち表へ変換できる
- 『列のピボット解除』と『その他の列のピボット解除』を使い分けられる
- 変換後の行数・合計値・データ型を検算し、更新に強いクエリを作れる
先に結論：分析用データは1列1項目の縦持ちにする
横持ち表では、2026年1月、2月、3月が別々の列になり、値は交差するセルへ入ります。この形は月別実績を眺める帳票には向きますが、月をフィルターしたり、新しい月を同じ軸で集計したりする処理には向きません。
縦持ち表では、商品、月、売上金額をそれぞれ独立した列にします。月が増えると列ではなく行が増えるため、ピボットテーブル、DAX、グラフは同じ列を参照し続けられます。
まず、変換前後で『月』がどこにあるかを見比べてください。
このように、アンピボットは表を細長くするだけの操作ではありません。見出しに埋め込まれた分析軸を列の値へ戻し、同じルールで追加データを処理できる形へ整える操作です。
固定項目は商品番号や商品名として残し、変動する月見出しを『月』列、そのセル値を『売上金額』列へ移します。
横持ちと縦持ちの違いを実務で理解する
横持ち表が作られる理由
予算入力表や部門別報告書では、行に商品や科目、列に月を配置した方が入力と確認をしやすくなります。横持ち表そのものが間違いなのではなく、入力・閲覧用の帳票と、集計・分析用の明細では適した形が違います。
入力担当者に縦持ち入力を強制すると、現場の使いやすさを損なうことがあります。そこで、入力形式は横持ちのまま維持し、Power Queryで分析用の縦持ちデータを別に作る設計が現実的です。
縦持ちにするとできること
- 月をスライサーやフィルターで選択できる
- 月別推移を1つの値列からグラフ化できる
- 商品、部門、月の組み合わせで集計できる
- 新しい月が追加されてもレポートの参照列を変えずに済む
- 日付テーブルと関連付けて前年比や累計を計算できる
縦持ち表では同じ商品名が複数行に繰り返されますが、これは重複データではありません。商品と月の組み合わせが行の粒度になっているため、各行は別の観測値です。
| 用途 | 横持ちが向く | 縦持ちが向く |
|---|---|---|
| 入力 | 月別予算の入力、一覧確認 | 明細登録、システム連携 |
| 集計 | 単純な行合計 | 月・商品・部門の自由な集計 |
| 更新 | 月追加で列が増える | 月追加で行が増える |
| 分析 | 期間比較の式が増えやすい | ピボット・DAXと連携しやすい |
月列を追加したとき、値がどこへ移るかを追います。
4月は新しい列のまま残らず、月列の値として既存の売上金額列へ流れます。そのため、グラフやDAXの参照列を増やす必要がありません。
Power Queryでアンピボットする6ステップ
操作全体は、固定列を決めてから月列を解除し、属性と値を整える6段階です。
重要なのは3番目の選択です。毎月増える列を直接選ぶより、増えない固定列を選び、その他の列を解除する方が保守しやすくなります。
手順1：元表をExcelテーブルとして読み込む
横持ち表の範囲内を選び、Ctrl + TでExcelテーブルにした後、データ、テーブルまたは範囲からを選びます。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
テーブル化すると行数の増加を取り込みやすくなり、Power Queryから列名を安定して参照できます。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
ナビゲーターまたはプレビューで、商品番号、商品名、1月以降の月列が欠けずに表示されているか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順2：固定して残す列を選ぶ
商品番号、商品名、部門など、月が増えても列として残したい項目を選択します。複数列はCtrlキーを押しながら選べます。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
ここで選ぶ列は識別子です。列見出しに月や年度が入る列は値へ変換する対象なので、固定列には含めません。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
選択した列だけで1行の対象を識別できるか、商品番号などのキーが欠けていないか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順3：その他の列のピボット解除を実行する
固定列を選択した状態で、変換タブの列のピボット解除からその他の列のピボット解除を選びます。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
月列を直接指定する方法では、翌月に新しい列が増えた際、その列が処理対象へ入らないことがあります。固定列以外を対象にすれば列追加へ追随しやすくなります。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
変換後に属性と値の2列が増え、商品ごとに月数分の行が作られたか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順4：列名とデータ型を整える
属性を月、値を売上金額へ変更します。月は日付型または年月を表すテキスト、金額は整数または小数へ設定します。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
属性や値という既定名のままでは、後から見た人が列の意味を判断できません。列名と型はデータモデルとの契約になるため、用途が分かる名前にします。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
型変換エラーを抽出し、見出し文字や合計列が月データとして混ざっていないか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
手順5：nullと不要な見出しを処理する
売上金額がnullの行を残すか除外するかを業務ルールで決めます。未入力と売上ゼロを区別する必要がある場合、nullを安易に0へ置換しません。 ここで大切なのは、画面上で一度だけ正しい結果を作ることではなく、翌月の更新でも同じ条件が再現されるように、操作を適用したステップとして残すことです。
nullは『記録なし』、0は『記録した結果がゼロ』を表すことがあります。意味を統一せず置換すると、平均や件数の解釈が変わります。 Power Queryは上から順に処理を実行するため、列名やデータ型を整える位置が後続処理の安定性を左右します。目的が分かるステップ名へ変更しておくと、引き継ぎ時にも判断しやすくなります。
月列に合計、備考などが入っていないか、売上金額のnull件数が想定と一致するか確認します。 更新後はプレビューの数行だけで判断せず、行数、null件数、合計値など、変換前に決めた基準と照合してください。
アンピボット後の行数と合計値を検算する
期待行数を先に計算する
商品が24件、月列が12列で、すべての組み合わせに値があるなら、アンピボット後の期待行数は24 × 12 = 288行です。固定列に重複がある場合や、null行を除外する場合は、その条件を加味します。
行数が期待より少ない場合は、月列の一部を固定列として残していないか、nullを除外していないか確認します。多い場合は、商品以外の行見出しや合計列まで解除していないかを調べます。
変換前後の金額合計を合わせる
アンピボットは値の配置を変える処理であり、売上金額そのものを変更しません。したがって、変換前の月列合計と、変換後の売上金額列の合計は一致する必要があります。
更新の成否は、見た目ではなく次の3点で判断します。
この6項目を更新チェックとして残せば、新しい月列や商品が追加されたときも、レポートへ反映する前に異常を見つけられます。
月列以外の『年間合計』までピボット解除すると、月別金額に年間合計が加算されます。合計列は事前に削除するか、解除後の月列から除外してください。
空欄とゼロは集計時の意味が異なります。
空欄を0に変える操作は見た目の修正ではなく、集計対象を変える判断です。業務上の意味を決めてから分岐させます。
アンピボットでよくある失敗と直し方
新しい月列が縦持ちへ入らない
翌月の列を追加して更新しても、その月の行が出力されないことがあります。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。
変換時に1月から12月の列を直接選び、列のピボット解除を実行した可能性があります。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。
商品番号などの固定列を選択し、その他の列のピボット解除へ変更します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。
テスト用に翌年1月列を追加し、その月が属性列へ現れることを確かめます。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。
月列が日付型にならない
属性列に2026年1月、1月実績などの文字列が入り、日付型への変換でエラーになります。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。
列見出しに年月以外の文字や全角記号が含まれていることが原因です。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。
不要文字を置換し、年と月を分割して月初日を作るか、命名規則を2026-01-01のように統一します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。
最小日、最大日、月の種類数を確認し、連続する期間になっているか調べます。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。
商品名が重複して見える
縦持ち化した後、同じ商品名が12行並ぶため、重複を削除したくなることがあります。 この状態で更新を続けると、見た目は完成していても集計軸が分裂したり、明細が欠落したりするため、結果だけを手直ししてはいけません。
商品名だけを見れば重複ですが、行の粒度は商品と月の組み合わせです。 原因を特定するときは、エラーが見えた最終ステップから戻るのではなく、値が初めて想定外になったステップを探します。
重複削除を行わず、商品番号と月を組み合わせたキーで一意性を確認します。 修正ルールは元データを直接書き換えるのではなく、クエリの変換または管理可能なマスター表として残します。
商品番号×月の件数が1件で、金額合計が維持されていることを確かめます。 修正後は正常行だけでなく、例外行が0件になったか、または意図した監査表へ分離されたかまで確認します。
ピボット解除の3種類を使い分ける
| 操作 | 選択する列 | 向く場面 | 列追加への強さ |
|---|---|---|---|
| 列のピボット解除 | 解除したい月列 | 対象列が固定 | 新しい月列は自動対象にならない |
| その他の列のピボット解除 | 残したい固定列 | 月列が増える定型帳票 | 新しい非固定列も対象になりやすい |
| 選択した列のみをピボット解除 | 明示した対象列 | 意図しない列を厳密に除外 | 列構成変更時に見直しが必要 |
月次・年度更新で見出しが増える帳票では、その他の列のピボット解除が基本です。ただし、固定列以外に備考や合計などの非対象列が追加される可能性がある場合は、その列を先に削除するか、対象列を名前規則で絞る設計が必要です。
『更新に強い』とは、どんな変更にも自動対応することではありません。想定する変更を月列の追加に限定し、想定外の列が来たらエラーまたは監査で気付けるようにする方が安全です。
Mコードで処理内容を確認する
let
ソース = Excel.CurrentWorkbook(){[Name="予算表"]}[Content],
型変換 = Table.TransformColumnTypes(ソース, {{"商品番号", type text}}),
ピボット解除 = Table.UnpivotOtherColumns(
型変換,
{"商品番号", "商品名"},
"月",
"売上金額"
)
in
ピボット解除Table.UnpivotOtherColumnsの第2引数に、固定して残す列が並びます。画面操作で作成した後、この部分を確認すると、どの列が保護され、どの列が値へ変換されるかを読み取れます。
入力帳票から公開レポートまでの責任範囲を分けます。
入力表と分析表を分けると、現場の操作性を保ちながら、下流のレポートを安定した縦持ちデータで動かせます。
アンピボットを毎月運用するための設計
入力帳票と分析データの責任範囲を分ける
横持ち帳票は入力担当者が管理し、縦持ちデータはPower Queryが生成する出力として管理します。出力表へ値を直接追記しても次回更新で上書きされるため、訂正が必要な場合は元帳票または管理された訂正表へ戻します。
入力帳票の列名、商品番号、月見出しの規則を簡潔に決めます。月列の追加は許可し、固定列の削除や改名は事前連絡が必要など、クエリが想定する変更範囲を共有します。
列追加テストを更新前に行う
本番月を追加する前に、テスト用の翌月列と数件の値をコピーへ追加します。更新後に新しい月が月列へ現れ、既存月の行数・金額が変わらないことを確認します。
『その他の列のピボット解除』は新しい非固定列も対象にするため、備考列や年間合計が追加された場合のテストも必要です。想定外の見出しは日付型変換でエラーにし、気付かず金額へ含めない設計にします。
変換仕様と検算値を残す
固定列、解除対象、月の形式、nullの扱い、期待行数の式をクエリ仕様として残します。担当者は操作画面を覚えるより、どの条件なら正しい出力になるかを理解できます。
更新履歴には、対象期間、入力行数、月列数、出力行数、金額合計、型エラーを記録します。前回値との比較があれば、列の追加漏れや合計列の混入を早く発見できます。
よくある質問
アンピボットとピボットテーブルは同じですか？
役割が異なります。アンピボットは列見出しを行の値へ戻すデータ整形です。ピボットテーブルは、整形済みデータを指定した行・列・値で集計して表示します。実務では、Power Queryでアンピボットした後、ピボットテーブルで再集計する流れがよく使われます。
横持ち表を元の見た目へ戻せますか？
Power Queryの『列のピボット』で月を列へ戻すことはできます。ただし、同じ商品・月に複数行がある場合は集計方法を指定する必要があります。出力帳票だけを横持ちにしたい場合は、縦持ちの明細を保ち、ピボットテーブルで表示する方が柔軟です。
空欄は0に置き換えるべきですか？
業務上の意味で判断します。未入力、対象外、実績ゼロが区別されるならnullを残し、表示側で扱います。すべての空欄が確実に実績ゼロを意味する場合だけ、0への置換ルールを明示して適用します。
まとめ：横持ち帳票と縦持ち分析データを分けよう
Power Queryのアンピボットを使うと、月が列に並ぶ横持ち表を、商品、月、売上金額の縦持ち表へ変換できます。列として増える月を値へ移すことで、ピボットテーブルやDAXが同じ列を参照し続けられます。
毎月列が増える帳票では、固定列を選んで『その他の列のピボット解除』を使うのが基本です。変換後は、期待行数、金額合計、月の種類数、データ型、null件数を検算します。
入力・閲覧しやすい横持ち帳票を否定する必要はありません。横持ちを現場の入力形式として残し、Power Queryで縦持ちの分析データを作ることで、使いやすさと更新性を両立できます。
運用開始後は、新しい月列だけでなく、固定列の改名や備考列の追加も変更として監視します。更新前後の列名一覧と検算値を残しておけば、アンピボットの対象が意図せず変わった場合にも、公開レポートへ反映する前に発見できます。
コメント