🔖 キーワード索引

別名・略称：（なし）

Power Query は Excel/Power BI の ETL (Extract/Transform/Load) エンジンで、 M 言語で記述された変換ステップが UI 操作と双方向にリンクする。 SSDSE-B-2026.csv をクエリ取り込み、 都道府県列の正規化・年度列のピボット解除・型変換の 3 ステップを M コードで確認する。

これらのキーワードは「power query の理解 → 適用 → 検証」のプロセスを構成する。 各章で詳しく解説する。

🎨 直感で掴む

1
2
3
4
5
6
7

let
    Source = Csv.Document(File.Contents("data.csv"), [Encoding=65001]),
    Header = Table.PromoteHeaders(Source),
    TypeChange = Table.TransformColumnTypes(Header, {{"消費支出", Int64.Type}}),
    Filtered = Table.SelectRows(TypeChange, each [年] >= 2020)
in
    Filtered

📐 定義 / 数式

Power Query は数式というより手順記述。 M言語の文法に従ったクエリが let ... in ... で書かれます。

let
  step1 = ソース取得,
  step2 = step1 を変換,
  step3 = step2 をフィルタ
in
  step3  // 最終結果

📐 M 言語 — Power Query の内部スクリプト

Power Query の「ステップ」は内部的に M 言語 (Power Query Formula Language) というスクリプトに変換される。 GUI 操作だけで使えるが、 高度な処理には M 言語を直接編集することがある。 「let ... in ...」構文と関数型プログラミングの考え方で書かれる。

数式を言葉で読み解く

M 言語の基本構文：

• Source = Csv.Document(File.Contents("...."), ...) — CSV ファイルを読み込む
• Promoted = Table.PromoteHeaders(Source) — 1 行目をヘッダーに昇格
• TypedTable = Table.TransformColumnTypes(Promoted, ...) — 型変換
• Filtered = Table.SelectRows(TypedTable, each [Year] = 2023) — 行フィルター
• Sorted = Table.Sort(Filtered, {{"Pop", Order.Descending}}) — 並べ替え

「各ステップが前のステップ名を入力にする」連鎖構造で、 これは関数型プログラミングの典型。 Python の pandas で書くと「メソッドチェーン」（df.pipe(promote_headers).astype({...}).query(...)）と同じ思想。

📐 M 言語の典型コードスニペット集

1. CSV 読込 + ヘッダー昇格 + 型変換

2. フィルター + 列選択

3. グループ化と集計

4. クエリのマージ（外部結合）

これらは Power Query エディタの GUI 操作で自動生成される M 言語コード。 数行単位で何が起きているかを読めるようになると、 トラブルシューティングや高度なカスタム関数の作成が可能になる。

📐 主要 M 関数リファレンス

Power Query は「カテゴリ.関数」のドット表記。 関数名は英語で覚えると Microsoft Docs を検索しやすい。 pandas と機能対応を意識すると、 両者の使い分けが体系化できる。

🔬 記号・式を言葉で読み解く

クエリ

Power Query が実行する一連の変換ステップの集合。 GUI で記述可能。

ステップ

1 つ 1 つの変換操作。 「列の削除」「型の変更」など。 後から編集可能。

M 言語

Power Query の内部言語。 GUI 操作が自動で M に変換。

データモデル

クエリで読み込んだテーブル群と関係性。 Power BI / Excel データモデルへ。

リフレッシュ

クエリを再実行してデータを最新化する操作。

🔬 パラメータクエリと動的データ取得

Power Query の強力機能の 1 つが「パラメータクエリ」。 ファイルパスや SQL クエリの一部を「パラメータ」として外部化し、 1 箇所変更すれば全体が連動する。

• filepath パラメータ：CSV ファイルのパスを変数化、 毎月のファイル名変更に対応
• year パラメータ：分析対象年を切替（2023 → 2024 へ簡単に変更）
• region パラメータ：分析対象地方を切替（関東 / 関西で別シート出力）

これは Python の関数引数と同じ役割。 「定型処理を 1 度書けば、 パラメータ変更で繰り返し実行できる」「Excel ファイル名や Web URL を動的に切替できる」ため、 月次レポートの自動化に最適。

🔬 カスタム関数で M 言語を本格活用する

M 言語では関数を「クエリの形」で定義し、 他のクエリから呼び出せる。 共通処理（地方分類・年度補正・通貨変換など）を関数化することで、 コードの重複を削減できる。

これにより「Prefecture 列に地方ブロックを付与する処理」を 1 行で書ける。 Python の def による関数定義と同じ思想で、 関数型プログラミングの恩恵を受けられる。

🔬 データ品質の検証 — Power Query のデータプロファイル機能

Power Query には「列の品質」「列の分布」「列のプロファイル」という 3 つのデータ品質可視化機能がある。 これを有効にすると、 各列について以下が即座に分かる：

• 列の品質：有効値 / エラー / 空白 の割合（緑・赤・グレーのバー）
• 列の分布：ユニーク値の数、 各値の出現頻度（小さな棒グラフ）
• 列のプロファイル：min/max/平均/標準偏差/Q1/Q3 などの統計量

これにより、 「人口列に文字列が混入していないか」「出生率に異常値（0 や 100）が無いか」を一目で確認できる。 SSDSE-B-2026 のような信頼性の高い公的データでも、 初回読込時に必ずこのチェックを行うのが鉄則。

pandas でも同等のチェックが可能：df.info()（型確認）、 df.describe()（統計量）、 df.isnull().sum()（欠損集計）、 df.duplicated().sum()（重複検出）。 これらは「データ分析の前に必ず実行する 4 つのコマンド」と覚える。

🔬 高度な変換 — マトリックスの転置・行と列の入替

Power Query には「行と列の入れ替え」（Transpose）機能がある。 これは行列の転置と同じで、 「縦方向の項目」を「横方向の列」に変換する。 SSDSE-B-2026 の特殊な配置（年度が行）を扱うときに便利。

注意：Transpose の前にヘッダーを「最初の行に降格」する必要があるケースが多い。 ヘッダー行も含めて転置されるため、 順序を正しく管理する必要がある。

どちらの形式が便利かは目的次第。 機械学習・可視化には「縦長」、 報告書・ピボットには「横長」。 Power Query と pandas は両方向の変換を 1 ステップで提供する。

🔬 深掘りウォークスルー — SSDSE-B-2026 を Power Query で 5 つの観点から分析する

本ページの締めくくりとして、 SSDSE-B-2026 を題材に Power Query で 5 つの分析観点を順に組み立てる。 「読み込み → 整形 → 集計 → 図 → 解釈」の流れが、 1 ファイル内で完結する様子を体感してほしい。 ここで紹介するすべての処理は、 GUI で 30 分以内に組める分量。

観点1: 人口規模別の一般診療所数 (1 人当たり)

「人口が多い県ほど一般診療所数 (I5102) も多い」は当然 (総人口との相関は r=0.97) だが、 人口 10 万人当たりで見ると順位は入れ替わる。 Power Query で「一般診療所数 / 総人口」の列を追加して並べ替えると、 実数では上位の東京・大阪・神奈川に代わり、 和歌山・島根・長崎など人口規模の小さい県が 1 人当たりでは上位に並ぶことが分かる (2023 年データで確認)。

観点2: 高齢化率と一般診療所数の関係

高齢化率 (65 歳以上人口比) を Power Query で別途集計し、 一般診療所数と結合する。 散布図にすると右下がりの傾向 (高齢化が進む県ほど診療所の実数は少ない、 r=-0.67) が見えるが、 これは高齢化の進む県が人口の少ない地方部に多いためである。 高齢化率が全国最低水準の沖縄県は 1 人当たり診療所数も下位という例外的な位置にあり、 グループ別に層別すると本質が見えてくる。

観点3: 出生率と婚姻率の関係

SSDSE-B-2026 には出生率・婚姻率・離婚率が同居している。 Power Query で 3 つを結合し、 県別の相関行列を作る。 「婚姻率が高い県ほど出生率も高い」の関係は明瞭で、 沖縄県が両方で全国 1 位。 政策議論で「婚姻促進が少子化対策の最上流」と言われる根拠が、 この 1 つの表から見える。

観点4: 大学進学率と所得水準

大学進学率と 1 人当たり所得を結合すると、 強い正の相関が見える。 ただし、 これは「大学に行ったから稼げる」ではなく、 「稼げる地域に大学が集中する」という逆因果の可能性もある。 Power Query で因果まで判定はできないが、 仮説の精緻化には十分役立つ。

観点5: 産業構造別の県分類

第 1 次・第 2 次・第 3 次産業の構成比を Power Query で 3 列追加し、 「最大構成比の産業」をカスタム列で判定する。 結果として「47 都道府県中、 第 3 次産業が最大比率なのは 46 県、 第 2 次産業最大は愛知県のみ」という構造が浮かび上がる。 これは経済構造を 1 つの数字で要約する初手として有用。

5 つの観点を 1 つのワークブックで完結させると、 SSDSE-B-2026 が「都道府県のマクロ像を多角的に語れるデータセット」であることが体感できる。 これは Power Query なしでもできるが、 Power Query を使うと 来年データが更新されても同じ分析が 1 クリックで再現できる 点が決定的に違う。

これら 5 つの観点を Power Query で実装することは、 統計・データ解析コンペで「分析テーマを発掘する」訓練そのもの。 自分なりの 6 つ目・7 つ目の観点を追加していけば、 提出論文の素材は無尽蔵に湧いてくる。 Power Query は分析のプラットフォーム であり、 同時に 分析のリテラシーを身につける道場 でもある。

🧮 実データで計算してみる

🧮 確認クイズ — Power Query の理解度

1. Q1. Power Query で「行のフィルター」をすると、 元データは変わるか？
   解答：変わらない。 Power Query は元データを読み込んで「ステップ」を順に適用するだけ。 元 CSV/DB は影響を受けない。
2. Q2. M 言語の each [Year] = 2023 は何を意味する？
   解答：「各行に対して、 Year 列の値が 2023 と等しいかを判定する」匿名関数。 each x は (_) => x の短縮形。
3. Q3. 「列の追加」と「カスタム列」の違いは？
   解答：「列の追加」は標準集計（合計・平均など）、 「カスタム列」は M 式で任意の計算を定義できる。 後者の方が柔軟。
4. Q4. Power Query の処理結果は通常どこに保存される？
   解答：Excel テーブル / Power BI モデル / Excel データモデル (Power Pivot)。 ファイルを開くたびに「更新」しないと最新化されない。
5. Q5. Query Folding が効かないと何が起きる？
   解答：「全データを Power Query 側にダウンロードしてから処理」するため、 大量データで極端に遅くなる。 SQL 側で処理を委譲する設計が必須。

🧮 ケーススタディ：SSDSE-B-2026 を Power Query で 6 ステップ分析する

最後に、 SSDSE-B-2026 の典型的な分析シナリオを Power Query で実装した例を示す。 「47 都道府県の人口・出生数・出生率から地方別の少子化指標を作成する」という、 政策ダッシュボードでよくある要求。

結果として「最も出生率が低いのは関東（東京 0.99 が影響）」「最も高いのは沖縄県を含む九州沖縄ブロック」といった政策含意のある分析が、 GUI 操作で 10 分以内に実行できる。 毎年データが更新されたら、 ファイルを差し替えるだけで自動再計算。

この「再現可能・自動化された分析」は、 一過性の Excel コピペでは絶対に実現できない価値。 Power Query を学ぶ最大の理由がここにある。

🧮 数式に値を入れて手で計算する: ETL 変換後の件数

合成データで Power Query 5 工程後の行数を計算する。

Step 1: 工程

Step 2: 検算

🐍 Python で再現

1
2
3
4
5

rows = 10000
ops = [-500, -200, 1000, -3300]
for d in ops:
    rows += d
print(f"最終: {rows}")

📤 実行結果

💬 手計算 (Step 2) 7,000 と Python 出力が完全一致。

🎮 触って学ぶ — 変換ステップを積み上げるパイプライン

下は教材用に用意した「汚い小テーブル」（前後空白・カンマ付き数値・欠損・重複を意図的に含む合成データ）。 各ボタンを押すと変換が 1 ステップずつ適用され、テーブルが段階的に整形されると同時に、右側に「適用したステップ」が記録される。 Power Query の中核である「手順を記録して再現・自動化する」感覚を体感できる。

💡 試してみよう: ①「重複削除」を「トリム」より先に置くと、空白違いの重複が消えず結果が変わる（＝手順は順序に依存）。 ②「列分割」を 2 回押すと 2 回目はエラー（＝列名が変わると後続ステップが壊れる）。 ③「🔄 別データで再実行」で、同じ手順が新しいデータにもそのまま効く（＝自動化の価値）。

🎨 直感 — 「手順そのもの」を保存する

Excel で手作業すると、整形の「結果」は残るが「やり方」は消える。 Power Query は逆で、クリック操作を 1 つずつ「適用したステップ」として記録する。 残るのは整形後の表ではなく整形の手順書（レシピ）。 だから来月の新しいデータにも、レシピを再生するだけで同じ整形が一瞬で終わる。 これが上のウィジェットで体感した「ステップの積み重ね＝再現可能なパイプライン」の核心だ。

⚠️ 落とし穴 — 順序依存・列名依存・性能

• ステップの順序が結果を変える: 「重複削除→トリム」と「トリム→重複削除」は別物。 空白や表記ゆれの正規化は必ず先に。 上のウィジェットで行数が変わるのを確認できる。
• 列名の変更で後続が壊れる: 「列分割」で元の列名が消えると、その列を参照する後続ステップがエラーになる（M 言語がステップを列名で参照するため）。 列名変更・削除は破壊的操作。
• 巨大データでの性能: フィルタや列削除はできるだけ早いステップに。 後段に置くと、無駄な行・列を全ステップで運ぶことになり遅くなる（ETL ツール一般の鉄則）。

🚀 発展 — ETL / ELT・パイプライン・冪等性

この「変換ステップの記録」は、より大きな文脈では ETL（Extract-Transform-Load）や ELT と呼ばれるデータ処理の一形態。 手順をコード化して版管理し、複数テーブルの依存関係を DAG で管理する専用ツール（dbt など）へ発展する。 データエンジニアリングでは、同じ入力に何度パイプラインを流しても結果が変わらない冪等性 (idempotency) が重視される。 Power Query の「毎回ステップを頭から再計算する」設計は、まさにこの冪等な考え方の入口であり、Power BI や データクレンジングの自動化基盤になる。

🐍 Python 実装

SSDSE-B-2026（47 都道府県・2023 年データ）を題材にした最小コード：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Power Query 自体は Excel/Power BI の機能ですが、 同じことを pandas で書くと：
import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932', skiprows=[1])

# 型変換 + フィルタ
df['L3221'] = df['L3221'].astype(int)  # L3221 = 消費支出
df = df[df['SSDSE-B-2026'] == 2023]  # 先頭列 = 年度

# 別データと結合
ref = pd.read_csv('data/raw/prefecture_codes.csv')
df = df.merge(ref, on='Prefecture', how='left')

🐍 Python pandas で Power Query 相当を実装する

🎯 このコードでやること：SSDSE-B-2026 に対して Power Query の典型的なステップ（読込 → 型変換 → フィルター → 集計 → 並べ替え）を pandas で同等実装する。 Power Query の「メソッドチェーン」と pandas の「dot-chain」が直接対応することを示す。

📥 入力データ：SSDSE-B-2026.csv (565 行 × 112 列、 cp932 エンコード)。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import pandas as pd

# Step 1: ソース読込 (Power Query: Csv.Document)
raw = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')

# Step 2: 1 行目を見出し化 (Power Query: PromoteHeaders)
# SSDSE では 0 行目が日本語ラベル → 列名は英コード, ラベル行は破棄
df = raw.iloc[1:].copy()

# Step 3: 型変換 (Power Query: TransformColumnTypes)
df['Year']     = df['SSDSE-B-2026'].astype(int)
df['Pop']      = pd.to_numeric(df['A1101'])
df['TFR']      = pd.to_numeric(df['A4103'])

# Step 4: フィルター (Power Query: SelectRows)
d2023 = df[df['Year'] == 2023]

# Step 5: 列選択 (Power Query: SelectColumns)
d2023 = d2023[['Prefecture', 'Pop', 'TFR']]

# Step 6: 並べ替え (Power Query: Sort)
d2023 = d2023.sort_values('Pop', ascending=False)

print(d2023.head(5))
print(f"\n最終データ: {len(d2023)} 県")

📤 実行結果：

💬 結果の読み方：Power Query の各ステップが、 pandas のメソッド呼び出しと完全対応する。 結果は 2023 年の 47 都道府県を人口降順で並べた表。 「東京 1,408 万 → 神奈川 922 万 → 大阪 876 万」と上位 3 県で全国の 30% 強を占める。 これがクロスプラットフォーム ETL の本質：「同じデータ整形ロジックを GUI でも CLI でも実装できる」。

🐍 ピボット・アンピボット (列⇄行変換)

🎯 このコードでやること：Power Query の「列のピボット」「列のピボット解除（unpivot）」を pandas で実装。 SSDSE-B-2026 の 5 都道府県 × 3 年データを「年が列」⇄「年が行」の形に変換する。

📥 入力データ：北海道・東京都・大阪府・広島県・沖縄県の 2021〜2023 年人口。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
df = df.iloc[1:]
df['Year'] = df['SSDSE-B-2026'].astype(int)
df['Pop'] = pd.to_numeric(df['A1101'])
prefs = ['北海道', '東京都', '大阪府', '広島県', '沖縄県']
sub = df[(df['Prefecture'].isin(prefs)) &
         (df['Year'].between(2021, 2023))][['Prefecture','Year','Pop']]

# Power Query: ピボット — 年を列に展開
pivot = sub.pivot(index='Prefecture', columns='Year', values='Pop')
print("[ピボット後]")
print(pivot)

# Power Query: アンピボット (UnpivotColumns) — 元に戻す
unpivot = pivot.reset_index().melt(id_vars='Prefecture',
                                       var_name='Year', value_name='Pop')
print("\n[アンピボット後]")
print(unpivot.head(8))

📤 実行結果：

💬 結果の読み方：ピボットは「縦長 → 横長」、 アンピボットは「横長 → 縦長」の変換。 Power Query では GUI で「列のピボット」「列のピボット解除」を選ぶだけ。 pandas では pivot() と melt() の対応関係。 「縦長 (long format)」の方が機械学習・可視化に適しており、 大量の年次データを保存・処理する場合の標準形式。

🐍 マージ（クエリの結合） — Power Query の Merge と pandas の merge

🎯 このコードでやること：SSDSE-B-2026 の人口データに、 別ファイル（地方コード対応表）を「Prefecture」キーで結合する。 Power Query では「クエリのマージ」、 pandas では merge() を使う。

📥 入力データ：SSDSE-B-2026 と、 別途用意した地方分類マスタ（コード内で定義）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
df = df.iloc[1:]
df['Year'] = df['SSDSE-B-2026'].astype(int)
df['Pop'] = pd.to_numeric(df['A1101'])
d23 = df[df['Year'] == 2023][['Prefecture', 'Pop']]

# 地方分類マスタ (Power Query では別クエリとして読み込む)
region_map = pd.DataFrame({
    'Prefecture': ['北海道', '東京都', '大阪府',
                   '広島県', '沖縄県', '愛知県'],
    'Region': ['北海道', '関東', '近畿',
               '中国', '九州沖縄', '中部'],
})

# Power Query: Merge Queries (LEFT OUTER)
merged = d23.merge(region_map, on='Prefecture', how='left')
print("マージ結果 (Region 欠損は他県の地方コードが必要):")
print(merged[merged['Prefecture'].isin(region_map['Prefecture'])])

📤 実行結果：

💬 結果の読み方：マスタの 6 県だけが Region に値を持つ（他 41 県は NaN）。 「LEFT OUTER JOIN」なので左側（人口）の全行が保持される。 Power Query の Merge ダイアログでは「内部 / 左外部 / 右外部 / 完全外部」を視覚的に選択できる。 pandas の how パラメータと完全対応。

🐍 グループ化と集計 — GroupBy

🎯 このコードでやること：SSDSE-B-2026 の 47 都道府県を地方ブロックでグループ化し、 人口・出生数・出生率・大学数を集計する。 Power Query の「グループ化」と pandas の groupby().agg() が同じ。

📥 入力データ：2023 年 47 都道府県の人口・出生数等。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
df = df.iloc[1:]
df['Year']     = df['SSDSE-B-2026'].astype(int)
df['Pop']      = pd.to_numeric(df['A1101'])
df['Births']   = pd.to_numeric(df['A4101'])
df['TFR']      = pd.to_numeric(df['A4103'])

# 地方ブロック対応 (47 県の完全マッピング)
# 「47 県の完全マッピング」と書きながら中部以降が省略されていた。
# .fillna('その他') があるので落ちないが、30 県が「その他」に集計される。
# 地域コードから 47 県ぶんを割り当てる。
def _region(code):
    n = int(str(code).lstrip('R')) // 1000
    if n == 1: return '北海道'
    if n <= 7: return '東北'
    if n <= 14: return '関東'
    if n <= 23: return '中部'
    if n <= 30: return '近畿'
    if n <= 35: return '中国'
    if n <= 39: return '四国'
    return '九州沖縄'

df['Region'] = df['Code'].apply(_region)

d23 = df[df['Year'] == 2023]
agg = d23.groupby('Region').agg(
    Pop_total=('Pop', 'sum'),
    Births_total=('Births', 'sum'),
    TFR_mean=('TFR', 'mean'),
    N_pref=('Prefecture', 'count')
)
print(agg.round(2))

📤 実行結果：

💬 結果の読み方：地方別の集計から「関東 4,350 万人で全国の 35%」が分かる。 Power Query のグループ化ダイアログでは、 列・集計関数（Sum / Average / Count / Min / Max / All Rows）を GUI で選ぶだけ。 pandas の groupby().agg() は同等の操作をコードで表現する。

🐍 Power Query の出力を pandas で再現する（Excel 出力）

🎯 このコードでやること：Power Query の最終ステップが Excel ワークシートへの書き出しなのと同様、 pandas で集計結果を xlsx ファイルに出力する。 複数シート・条件付き書式・ピボットテーブルも対応。

📥 入力データ：上記の地方別集計テーブル。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import pandas as pd
import xlsxwriter   # ExcelWriter の engine 指定に必要（明示すると自動で導入される）

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
df = df.iloc[1:]
df['Year'] = df['SSDSE-B-2026'].astype(int)
df['Pop']  = pd.to_numeric(df['A1101'])
df['TFR']  = pd.to_numeric(df['A4103'])
d23 = df[df['Year'] == 2023][['Prefecture', 'Pop', 'TFR']]

# 複数シートに分けて Excel 出力 (Power Query の各クエリ → 各シート と同じ)
with pd.ExcelWriter('ssdse_report.xlsx', engine='xlsxwriter') as w:
    d23.to_excel(w, sheet_name='Detail', index=False)
    d23.sort_values('Pop', ascending=False).head(10).to_excel(w, sheet_name='Top10', index=False)
    summary = pd.DataFrame({'Metric': ['合計人口', '平均出生率', '県数'],
                            'Value': [d23['Pop'].sum(),
                                      round(d23['TFR'].mean(), 3),
                                      len(d23)]})
    summary.to_excel(w, sheet_name='Summary', index=False)

print("Excel ファイル作成完了")
print(summary)

📤 実行結果：

💬 結果の読み方：全国合計人口 1.24 億人、 47 県の平均出生率 1.21、 県数 47。 1 つの xlsx ファイルに「Detail（全 47 県）」「Top10」「Summary」の 3 シートを格納。 Power Query で同じ出力を作る場合、 各クエリの「読み込み先」を別ワークシートに設定するだけ。 結果のフォーマットは同じ。

🐍 条件列（IF 文）を pandas で再現

🎯 このコードでやること：Power Query の「条件列」（IF 文で値を分岐させる列）を pandas の np.where や pd.cut で再現する。 SSDSE-B-2026 の人口を「大規模（500 万人以上）」「中規模（100〜500 万人）」「小規模（100 万人未満）」に分類する。

📥 入力データ：2023 年 47 都道府県の人口。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
df = df.iloc[1:]
df['Year'] = df['SSDSE-B-2026'].astype(int)
df['Pop']  = pd.to_numeric(df['A1101'])
d23 = df[df['Year'] == 2023][['Prefecture', 'Pop']].copy()

# Power Query の Add Conditional Column 相当
d23['Scale'] = pd.cut(d23['Pop'],
                     bins=[0, 1_000_000, 5_000_000, 100_000_000],
                     labels=['小規模', '中規模', '大規模'])

print(d23.groupby('Scale', observed=True).agg(
    N=('Prefecture', 'count'),
    PopSum=('Pop', 'sum'),
    PopMean=('Pop', 'mean')
))

📤 実行結果：

💬 結果の読み方：「100 万人未満」が 10 県、 「100〜500 万人」が 28 県と最も多く、 「500 万人以上」は 9 県（東京・神奈川・大阪・愛知・埼玉・千葉・兵庫・北海道・福岡）。 合計 1.24 億人のうち 68,708,000 人（55%）がこの大規模 9 県に集中し、 平均人口も小規模県の 10 倍（76 万人 vs 763 万人）。 Power Query で同じ列を作るには「列の追加 → 条件列」で 3 段階の IF を定義する。

🐍 複数ファイルの結合 — フォルダから取得

🎯 このコードでやること：Power Query の「フォルダから取得」機能を pandas で再現。 SSDSE のデータディレクトリには data/2025_U2/SSDSE-B-2026.csv、 data/2025_U3/SSDSE-B-2026.csv、 data/raw/SSDSE-B-2026.csv が存在。 全ファイルを統合する。

📥 入力データ：3 つの SSDSE-B-2026.csv（場所が異なるが同一内容のはず）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

import pandas as pd
import glob

paths = glob.glob('data/**/SSDSE-B-2026.csv', recursive=True)
print("発見ファイル数:", len(paths))
for p in paths:
    print(" -", p)

# 全ファイル読込 + ファイル名列を追加 (Power Query: Combine Files の結果と同じ)
dfs = []
for path in paths:
    d = pd.read_csv(path, encoding='cp932')
    d['_source'] = path
    dfs.append(d)
combined = pd.concat(dfs, ignore_index=True)

print(f"結合後の行数: {len(combined)}")
print("source 別の行数:")
print(combined['_source'].value_counts())

📤 実行結果：

💬 結果の読み方：3 ファイル × 565 行 = 1,695 行が結合された。 「_source」列で出所が分かるので、 重複削除や元ファイル別の集計も容易。 Power Query の「フォルダから取得」は GUI でこの操作を全部実行する：「フォルダ参照 → サンプルファイル選択 → 結合」の 3 ステップ。

🐍 Power Query M 言語と pandas を 1 列で対応させる

🎯 このコードでやること：SSDSE-B-2026 で「2023 年・人口 200 万人以上の県のみ・人口降順 Top 5」を抽出する処理を、 M 言語コードと pandas コードの両方で書き、 結果が一致することを確認する。

📥 入力データ：SSDSE-B-2026.csv 全 565 行。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

import pandas as pd

df = pd.read_csv('data/raw/SSDSE-B-2026.csv', encoding='cp932')
df = df.iloc[1:]
df['Year'] = df['SSDSE-B-2026'].astype(int)
df['Pop'] = pd.to_numeric(df['A1101'])

result = (df
    .query('Year == 2023 and Pop >= 2_000_000')
    .sort_values('Pop', ascending=False)
    .head(5)
    [['Prefecture', 'Pop']]
)
print(result.to_string(index=False))

📤 実行結果：

💬 結果の読み方：M 言語版と pandas 版で同じ結果が得られる。 Top 5 県（東京・神奈川・大阪・愛知・埼玉）が全国総人口の約 37% を占める。 Power Query で習得した「ETL の発想」は pandas にも直接転用でき、 逆も成立する。 これが「データリテラシーの中核を成す」と言われる理由。

⚠️ よくある落とし穴

⚠️ Power Query の落とし穴（深掘り版）

⚠️ よくある間違い — 初心者がハマるポイント

1. 「全列を整数に」と一括変換

列の中に文字列・空白が混入していると、 一括「Int64 型」変換でエラー行が出る。 個別に列を選んで型変換するか、 try ... otherwise null でエラー処理するのが安全。

2. プレビューを見て安心

Power Query のプレビューは「最初の 1000 行」のサンプル。 全件で同じ結果になるとは限らない。 「閉じて読み込む」した後に、 必ず全件で再確認する。

3. ステップ名の自動命名

「Changed Type1, Changed Type2, ...」のままだと、 後で見て何の処理か分からない。 必ず「型変換 (人口列)」のように、 各ステップに意味のある名前を付ける。

4. インデックス列の生成タイミング

「インデックス列の追加」はソート後に行わないと、 番号がランダムに振られる。 「並べ替え → インデックス追加」の順番が重要。

5. パスのハードコード

"C:\Users\shimpei\Documents\data.csv" のように絶対パスを直書きすると、 共有時に動かない。 パラメータクエリ・相対パス・OneDrive 共有が安全。

6. SSDSE データの「年度行 = 0 行目」を見落とす

SSDSE-B-2026 では「英字コード列名（A1101 等）」がヘッダーで、 0 行目に「日本語ラベル（総人口 等）」が入る。 そのまま型変換すると「日本語が整数にならない」エラー。 「最初の N 行を削除」で 1 行スキップしてから型変換するのが正しい順序。

7. ロケール依存の小数点

日本語版 Windows では「1.06」を小数として認識するが、 ヨーロッパ版では「1,06」が小数。 国際チームで共有する場合、 ロケールを明示的に指定（type number with locale "en-US"）するのが安全。

8. リフレッシュタイミングの不一致

Power Query は「ファイルを開いたとき」「更新ボタンを押したとき」にしか実行されない。 自動定期更新には Power BI Service / OneDrive 同期 / Power Automate と組み合わせる必要がある。 「最新データが表示されない」トラブルの多くはここに起因する。

9. メモリリークと残留プロセス

大量データを Power Query で扱った後、 Excel を閉じてもバックグラウンドプロセスが残ることがある。 タスクマネージャで「Microsoft.Mashup.Container.exe」を確認、 必要なら手動終了。 Power BI Desktop の場合は「キャッシュのクリア」コマンドが有効。

🔁 補論: M 言語ステップ ↔ pandas メソッドの完全対応表 (SSDSE-B-2026)

本ページの本文では Power Query の操作感を扱ったが、 ここでは SSDSE-B-2026 (2023 年度に絞ると 47 都道府県 × 112 列) を題材に、 M 言語のステップを pandas に 1:1 で読み替える 実用表を提示する。 「数式を言葉で読み解く」の節で扱った「ステップ列 = 関数合成」の見方を、 そのまま Python ETL に持ち込める。

🎯 対応表: 同じ ETL を Power Query (M) と pandas で書く

🐍 Python 実装: M 言語の主要 5 ステップを pandas でそのまま再現する

このコードでやること: 上表の操作を SSDSE-B-2026 に対して順に適用し、 Power Query の「適用したステップ」と完全に同じ ETL pipeline を pandas で組む。 .pipe() でステップを連結すれば、 M 言語のステップ列と 1:1 対応する。

📥 入力データ: SSDSE-B-2026.csv (564 行 × 112 列、 2012-2023 年度)。 2023 年度に絞ると 47 都道府県。 region は都道府県 → 地方ブロックの対応表 (別途用意):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import pandas as pd

# Step 1: ソース (= Csv.Document)
df = pd.read_csv('data/raw/SSDSE-B-2026.csv',
                 encoding='cp932', skiprows=[1])

# Step 2: フィルタ (= Table.SelectRows): 2023 年度・百万人超
df = df[df['SSDSE-B-2026'] == 2023]
big = df[df['A1101'] > 1_000_000]

# Step 3: 列追加 (= Table.AddColumn): 高齢化率 (%)
big = big.assign(高齢化率=big['A1303'] / big['A1101'] * 100)

# Step 4: 地方ラベル結合 (= Table.NestedJoin)。 region は対応表
# region は SSDSE に無いので、地域コードの上 2 桁から作る
import numpy as np
_no = df['Code'].str[1:3].astype(int)
region = pd.DataFrame({'Prefecture': df['Prefecture'], '地方': np.select(
    [_no <= 7, _no <= 14, _no <= 23, _no <= 30, _no <= 35, _no <= 39],
    ['北海道東北', '関東', '中部', '近畿', '中国', '四国'], default='九州沖縄')})
big = big.merge(region, on='Prefecture', how='left')

# Step 5: グループ集計 (= Table.Group)
summary = big.groupby('地方').agg(
    合計人口=('A1101', 'sum'),
    県数=('Prefecture', 'count'),
    平均高齢化率=('高齢化率', 'mean'),
).sort_values('合計人口', ascending=False)
print(summary.head())

📤 実行例 (2023 年度、 実測値。 高齢化率は %):

💬 関東が 7 県で 4353 万人と圧倒的に多く、 平均高齢化率 28.0% は全地方で最も低い (百万人未満の 10 県は Step 2 のフィルタで除外されている点に注意)。 同じ集計を Power Query で書くと 5 ステップ (ソース→フィルタ→追加列→結合→グループ化) になり、 上の pandas コードと完全に対応する。 つまり M 言語の習熟は pandas の理解を 80% カバーし、 逆もまた然り。

⚠️ 補論の落とし穴 (pandas 移植時)

• SettingWithCopyWarning: big = df[df['総人口'] > 1e6] の後に big['新列'] = ... と書くと警告が出る。 .copy() または .assign() を使うこと。 M 言語にはこの落とし穴がない。
• 結合の重複爆発: M の NestedJoin は明示的に展開するまでネストされた状態を保つが、 pandas の merge は即座にデカルト積になる。 結合キーの一意性 (df.duplicated('都道府県').sum() == 0) を事前に検証する習慣を。
• 型の自動推論差: Power Query は日本語ロケールで「5,224,614」を整数として推論するが、 pd.read_csv は文字列扱いになる。 thousands=',' 引数を渡すか、 事前に str.replace(',', '').astype(int) で前処理する。

📊 Power Query で整形したデータを「実図」で確認する

Power Query の真価は、 整形した結果が「分析できる形」になっていることを 図で確認できる こと。 SSDSE-B-2026 を Power Query (または等価な pandas) で整形した後、 散布図・ヒストグラム・箱ひげ図でドリフトや外れ値を素早く確認するワークフローを示す。 グラフはすべて SSDSE-B-2026 (2023 年度の 47 都道府県 × 112 列) から生成された実データの図である。

図1: 散布図 — 整形後の総人口 × 一般診療所数 (47 都道府県)

この散布図は Power Query の出力テーブル (型変換済) を Excel の「挿入 → 散布図」で 2 クリック生成、 あるいは pandas で df.plot.scatter('A1101','I5102') と書けば同じ結果になる。 整形が崩れていると、 文字列が混入して空白プロットが出るので、 ETL の品質確認に図は欠かせない。

図2: ヒストグラム — 整形後の人口分布の歪み

ヒストグラムを Power Query の出力テーブルから直接生成することで、 「平均と中央値どちらで集計するか」「ロバスト統計に切り替えるか」が判断できる。 「整形 → 図 → 設計見直し」というループは、 Power Query の 適用したステップが可変・追加可能 という特性によって低コストになる。 ETL を SQL でハードコードすると、 こうした「図を見てから戻る」が難しい。

図3: 箱ひげ図 — 整形後の地方ブロック別人口

箱ひげ図で「中央値・四分位範囲・外れ値」を地方ごとに比較すると、 Power Query で作った地方コード対応表が妥当か (例: 関東に新潟が誤って分類されていないか) を直感的に検証できる。 これは「テスト駆動 ETL」の入り口で、 RFC 2119 でいう SHOULD レベルの実務的習慣。

🧭 Power Query の 8 ステップを「実務基準」で深掘りする

本ページの前半では Power Query の概要を説明したが、 実務で詰まるポイントは「どのステップでどう判断するか」。 ここでは標準的な 8 ステップを、 SSDSE-B-2026 を題材に 判断基準・出力検証・コスト見積 の 3 軸で示す。 これは「ETL の意思決定マトリクス」と呼ばれる実務知識を表に落としたもの。

合計 2 分強で SSDSE-B-2026 の典型的な前処理が一通り完了する。 これを毎月手動でやると 5-10 分かかるところを、 Power Query は クリック 1 つでリフレッシュ できる。 年 12 回の作業を自動化すると、 年間 1-2 時間の工数削減になる。

🌐 関連手法・この用語を使う論文

🌐 Power Query vs pandas — 使い分けガイド

基本ルール：「現場ユーザー（非エンジニア）が操作する」「Excel に結果を貼る」「データ量が中規模」なら Power Query。 「大規模データ」「機械学習を含む」「Git で管理する」なら pandas。 両方使えると無敵。

🌐 実務での Power Query 活用シナリオ

シナリオ 1: 月次売上レポート

毎月初に、 前月分の売上 CSV を「フォルダから取得」で一括読込。 顧客マスタ・商品マスタとマージし、 部門別・地域別の集計表を Excel で出力。 ステップは初月に定義すれば、 翌月以降はリフレッシュボタン 1 つで更新完了。

シナリオ 2: Web スクレイピング

Power Query は「Web から取得」機能で、 HTML テーブルを直接読み込める。 例：気象庁の月別気温データページから、 全国の気温推移を毎月自動更新。 SSDSE-B-2026 の B4101（年平均気温）と組み合わせれば、 「人口と気温の関係」のダッシュボードが作れる。

シナリオ 3: 複数 Excel ファイル統合

「営業所ごとの月次報告書」を 47 ファイル（フォーマット同一）受け取った場合、 Power Query の「フォルダから取得」で全ファイルを 1 つのテーブルに結合できる。 数十時間の手動コピペ作業が数分で終わる。

シナリオ 4: データクレンジング

不揃いなフォーマットのデータ（全角半角混在、 空白の有無、 表記ゆれ）を、 Power Query の「値の置換」「文字列のトリム」「大文字小文字変換」で標準化。 SSDSE-B-2026 のような公的データでも、 古いデータには表記揺れがあることがある。

🌐 セキュリティとプライバシー

Power Query は複数のデータソースを混合できるため、 セキュリティが重要になる：

• Privacy Levels：Public / Organizational / Private の 3 段階。 「個人情報を Web に漏らさない」ためのガード
• 認証情報の管理：データソース毎に Windows 認証 / 基本認証 / API キー / OAuth を選択
• 機密データの匿名化：「列のハッシュ化」「マスキング」を変換ステップで実装
• 監査ログ：Power BI サービスでクエリの実行履歴を記録

SSDSE-B-2026 は公開データだが、 これに「自社の売上データ」を結合する場合、 Privacy Levels を適切に設定しないと「警告ダイアログ」「リフレッシュ失敗」が起きる。 「データソースの設定」から事前に Privacy Level を「Organizational」に統一しておくのが実務的。

🌐 データフロー Gen2 と Microsoft Fabric — クラウド時代の Power Query

2023 年に発表された Microsoft Fabric は、 Power Query をクラウドベースの ETL 基盤として再構築した。 「データフロー Gen2」と呼ばれ、 ローカル PC ではなくクラウド上で実行される。

主な特徴

• スケーラビリティ：数億行のデータも数分で処理
• OneLake 統合：1 つの統合ストレージにすべてのデータが集約
• Spark エンジン：分散処理で高速化
• CI/CD 対応：Git 連携でバージョン管理可能
• Notebook 統合：Python / R で複雑なロジックを補完

SSDSE-B-2026 のような小規模データは Excel 版 Power Query で十分だが、 企業の「数百万件の顧客データ × 数十年の取引履歴」を扱う場合、 Fabric / データフロー Gen2 が必須。 「ローカル Power Query で開発 → Fabric にデプロイ」のワークフローが標準化しつつある。

🌐 組織への導入 — Power Query を「全社共通言語」にする

Power Query は「Excel を使う人全員」が習得できるツール。 営業・経理・人事といった非エンジニア部門にも展開できるのが強み。 組織導入のステップ：

1. パイロット選定：データ量の多い 1 部門で先行導入（例：営業の月次レポート作業）
2. トレーニング：4 時間のハンズオン研修で基本操作を習得
3. テンプレート整備：「売上集計テンプレート」「在庫レポートテンプレート」を共有
4. サポート体制：データガバナンス部門が M 言語の高度部分をサポート
5. Power BI 展開：Excel から Power BI へ段階的に移行
6. クラウド統合：Microsoft Fabric / OneLake にデータ集約

「データを民主化する」とよく言われるが、 Power Query はその具体的な実装手段。 SSDSE-B-2026 のような公開データで研修すると、 政治的・組織的問題なしで全社的なスキル底上げができる。

🌐 AI との統合 — Copilot in Power Query

2024 年から Microsoft Copilot が Power Query にも統合され始めた。 「自然言語でステップを記述」すると、 M 言語コードが自動生成される機能。

これにより「M 言語を完全に理解していなくても、 高度な処理ができる」時代に。 ただし「Copilot 生成コードのレビュー」は依然として人間の責任。 ロジックエラー・型ミス・性能問題は AI が見落とすことがある。

Python の世界でも GitHub Copilot や ChatGPT が同様の役割を果たす。 「コードを書く労力」は減るが、 「何を作りたいか」「結果が正しいか」を判断する力はますます重要になる。 SSDSE-B-2026 のような既知のデータで結果検証する習慣を持つと、 AI 生成コードの信頼性を高められる。

🌐 エコシステム — Power Query が組み込まれている製品群

Power Query は単なる「Excel のアドイン」ではなく、 Microsoft データプラットフォームの ETL レイヤーとして広く組み込まれている。 SSDSE-B-2026 を 1 つの ETL で整形した後、 そのクエリをほぼそのまま他製品へ移植できるのが大きな魅力。

この「同じ M 言語クエリが複数製品で動く」性質によって、 個人作業から組織展開、 さらにクラウドスケールへとシームレスに拡張できる。 Excel で 1 人が書いたクエリが、 翌月には部門の Power BI ダッシュボードに、 半年後には全社の Fabric Lakehouse に流れる、 という導入パスが標準化されている。

この特徴は他の ETL ツール (Talend, Informatica, Apache NiFi など) には少ない強みで、 「個人 → 部門 → 組織 → クラウド」の階段を 1 つのスキルで登れる。 SSDSE-B-2026 のような統計データで Power Query を学ぶことは、 結果としてキャリアの広がりも生む投資になる。

⚖️ 他ツールとの比較 — Power Query をどう位置付けるか

「GUI で書ける」「Office に標準搭載」「学習コスト低」の 3 点で、 Power Query は 個人〜中小組織 の ETL 用途で他の追随を許さない優位性がある。 数億行スケールの ETL や、 Git ベースの開発フローを徹底したい場合は dbt や Airflow に軸足を移すのが妥当。 大切なのは「目的に応じてツールを使い分ける」発想で、 Power Query を学ぶことはその第一歩。

🚀 次の一歩 — 本ページを読み終えたら何をするか

1. 今すぐ Excel を開く: 「データ → データの取得 → ファイル → CSV」で SSDSE-B-2026.csv を読み込んでみる。 ここで詰まれば、 まず CSV のエンコーディング (cp932 か utf-8 か) を疑う。
2. 3 ステップだけ書く: ヘッダ昇格 → 不要行削除 → 型変換、 の 3 つだけで「適用したステップ」に何が記録されるかを観察する。 数式バーの M 言語コードを必ず見る。
3. 1 つの列を追加: 「列の追加 → カスタム列」で高齢化率 (65 歳以上人口 A1303 ÷ 総人口 A1101) を計算してみる。 GUI で書いた式がそのまま M 言語に変換される様子を観察する。
4. 同じことを pandas で書く: pd.read_csv → df.iloc[1:] → df.astype → df.assign の順で書くと、 Power Query と完全に対応する。 ステップ単位での思考が pandas でも崩れないことを確認する。
5. 翌月のデータで再実行: SSDSE-B-2027 が出たら、 ファイル名を差し替えて「すべて更新」する。 1 クリックで再計算される様子を体験すると、 Power Query が「コードではなく作業」を自動化していることが腑に落ちる。
6. Power BI Desktop を試す: Excel に出した表を Power BI に貼り付けると、 同じクエリが Power BI でも動く。 そのままドラッグ&ドロップでダッシュボード化できる。
7. 関連ページを巡る: Power BI、 ETL ツール、 pandas、 データクレンジング を読み、 ETL の生態系全体を俯瞰する。

この 7 ステップを 1 週間で完走すれば、 Power Query を「業務で使える」レベルに到達できる。 SSDSE-B-2026 のような公開データで練習することの利点は、 失敗しても誰にも迷惑がかからない こと。 業務データでいきなり始めると、 ミスが本物の損害につながる可能性があるが、 公開データなら何度でもやり直せる。 この「安全な道場」を活用しない手はない。

Power Query は学べば学ぶほど、 「データを再現可能・自動化された形で扱う」という発想が身につく。 これは Power Query 固有のスキルではなく、 SQL でも pandas でも、 さらに dbt や Airflow のような上位ツールでも変わらない普遍的な発想。 つまり Power Query を 1 つ学ぶことは、 データエンジニアリング全体への扉を開くことに等しい。 SSDSE-B-2026 を継続的に触ることで、 47 都道府県データに対する直感も同時に育つので、 統計データ解析コンペの素地にもなる一石二鳥の学習方法と言える。

最後に、 Power Query の価値は「更新できる前処理」を残せる点にある。 手作業の修正を一度で終わらせず、 次回も同じ手順で再実行できる形にすることが、 分析品質を支える。

🌐 Power Query 実務適用パターン集 — 14 のレシピで現場に対応する

SSDSE-B-2026 は (2023 年度に絞ると) 47 都道府県 × 112 列という、 業務でよく遭遇する「中規模・多列」のデータ構造を持っている。 ここでは Power Query で頻出する 14 種類の整形パターンを、 SSDSE を題材にしながらレシピ形式で示す。 各レシピはコピーして自分のデータに置き換えれば、 即座に動くように作ってある。

レシピ1: 列名の一括変更

SSDSE のカラム名は SSDSE-2026 / 都道府県 / 総人口 ... のような形式だが、 業務用には英語名にしたい場合がある。 Power Query の Table.RenameColumns で一括変更できる。

pandas なら df.rename(columns={'総人口': 'population_total', ...}) に相当。 業務システム連携で英語列名が必要な場面で頻出。

レシピ2: 文字列クレンジング (空白除去・全角半角統一)

手入力データには「東京都」「東京都 」「東京都(都内)」などの揺れがある。 Power Query で正規化するには Text.Trim + Text.Clean + 置換を組み合わせる。

Text.Trim は前後の空白を除去、 Text.Clean は印字不可能な制御文字を除去。 公的データでも稀に混入することがあるので、 重要な前処理。

レシピ3: 複数列の一括型変換

SSDSE は 112 列のうち数値列が 100 以上ある。 1 列ずつ型変換するのは面倒なので、 リスト操作で一括変換する。

100 列に対して 1 行で型変換が完了する。 pandas の df.iloc[:, 2:] = df.iloc[:, 2:].astype(int) に相当する高度な書き方。

レシピ4: ピボット (縦持ち → 横持ち)

「都道府県 × 年度 × 指標値」の長表を「都道府県 × 年度1, 年度2, ...」の横表に変換する。 Excel ピボットの自動化版。

レシピ5: アンピボット (横持ち → 縦持ち)

SSDSE のように 112 列ある横持ちデータを、 BI ツールで扱いやすい縦持ち (Long Format) に変換する。 Table.Unpivot はその逆操作。

これで 2023 年度の 47 行 × 112 列が、 47 × 110 = 5,170 行 × 4 列の縦持ちテーブルに変換される。 タブロー/ Power BI / matplotlib いずれのツールでも、 縦持ち形式の方が扱いやすい。

レシピ6: 重複の検出と削除

複数 CSV を結合した後、 同じ都道府県の行が重複していないかチェックする。 Table.Distinct で重複を削除、 重複行だけを抽出するには Table.RowCount との差分を取る。

レシピ7: 欠損値の検出と補完

SSDSE は基本的に欠損なしだが、 業務データには欠損が多い。 Table.ReplaceValue で null を 0 や平均値に置換する。

レシピ8: 累積計算 (Running Total)

「人口の少ない県から順に累積していき、 全国人口の 50% に達する県を特定する」といった分析。 Power Query には直接の累積関数がないので、 インデックス列を追加して再帰的に計算する。

pandas なら df.sort_values('総人口').assign(累積人口=lambda x: x['総人口'].cumsum()) で 1 行。 M 言語の弱点が出る場面でもあるが、 工夫すれば対応可能。

レシピ9: 上位 N 件抽出 (per group)

地方ごとに「人口上位 3 県」を抽出する。 SQL でいう ROW_NUMBER() OVER (PARTITION BY ...) に相当する処理。

レシピ10: 日付列の生成と分解

月次データを年度・四半期・月などに分解する。 Power Query の Date.* 関数群を使う。

レシピ11: 範囲 JOIN (BETWEEN)

「年齢が階級表の各範囲に該当する人をマッチング」のような範囲 JOIN。 Power Query には直接の機能がないので、 デカルト積を取ってからフィルタする。

レシピ12: テキスト分割 (1 列を複数列に)

「03-1234-5678」のような電話番号を市外局番・市内局番・加入者番号に分割する。 Table.SplitColumn + Splitter 関数を使う。

レシピ13: 正規表現での抽出 (M には標準で正規表現がない)

M 言語には正規表現が標準で備わっていない (これは大きな欠点)。 代わりに Text.Select で文字種類による抽出を行う。

本格的な正規表現が必要なら、 Power Query から pandas にエクスポートして処理するか、 R や Python の MyExtension を呼び出す。

レシピ14: パラメータ化された動的クエリ

「年度」「地方」をパラメータ化して、 ユーザーがドロップダウンで選択できるクエリを作る。 これが Power BI のスライサーと連動する仕組み。

このクエリは「対象年度」「対象地方」を変更するだけで、 異なるサブセットを返すようになる。 これにより、 同じクエリロジックを複数の用途に再利用できる。

📊 14 レシピの使用頻度マトリクス

この 14 レシピを使いこなせれば、 SSDSE-B-2026 のような実データに対する整形作業の 95% は対応できる。 残りの 5% は type any での動的処理や、 R/Python 連携での高度な処理になるが、 これらは登場頻度が低いため、 必要になった時点で個別に学べばよい。 まずはレシピ 1-7 を完全に手に馴染ませることから始めると、 Power Query の習熟が一気に進む。

🛡 Power Query エラー対処辞典 — 頻出 10 エラーの解決策

Power Query を使い始めると、 Microsoft 独特のエラーメッセージに遭遇する。 メッセージが分かりにくいことが多く、 ネット検索しても日本語情報が少ないケースが多い。 ここでは現場で頻出する 10 種類のエラーと、 その解決策をまとめた。 SSDSE-B-2026 のような公的データを扱う場面でも、 これらのエラーは普通に出てくる。

エラー1: Expression.Error: ... 列が見つかりません

原因: 前段のステップで列名を変更したのに、 後段のステップが古い列名を参照している。 「列名変更」ステップを挿入すると、 後続の参照を自動更新してくれるが、 ステップを並び替えると参照ズレが起きる。 解決: エラーが出ているステップの数式バーで、 列名を正しい現在名に書き直す。

エラー2: DataFormat.Error: 値を Number 型に変換できません

原因: 型変換ステップで「総人口」を Int64 に変換しようとしたが、 一部の行に「-」「不明」などの非数値が混在している。 SSDSE は基本的にクリーンだが、 業務データではよくある。 解決: 型変換の前に Table.ReplaceValue で非数値を null に置換するか、 Table.SelectRows で除外してから変換する。

エラー3: Formula.Firewall: ... プライバシーレベルが互換性がありません

原因: Power Query は異なるデータソース (例: SQL DB + Web API) を結合する際、 「プライバシーレベル」が一致しないと混合できない。 セキュリティ機能の一つ。 解決: 「ファイル → オプション → 現在のファイル → プライバシー」で「常に組織のプライバシーレベル設定を無視する」を選択。 ただしセキュリティリスクを理解した上で実施する。

エラー4: Token Comma expected

原因: M スクリプトの構文エラー。 ステップ間のカンマ忘れか、 括弧の閉じ忘れが大半。 解決: 詳細エディタで、 各ステップが , で区切られているか確認。 最後のステップだけはカンマ不要 (in の前)。

エラー5: Expression.SyntaxError: トークン Literal が予期されました

原因: 文字列リテラルの引用符忘れ。 例えば each [都道府県] = 東京都 と書くと、 「東京都」が変数として扱われエラーになる。 解決: 文字列は必ず "東京都" のようにダブルクォートで囲む。

エラー6: Expression.Error: キー X は要素を一意に識別しません

原因: Table.NestedJoin の右側テーブルで結合キーが重複している。 SSDSE で「都道府県」をキーにする場合、 47 行が一意なので問題ないが、 市町村データを結合する際に「同名の市町村」 (例: 府中市が東京と広島にある) が一意性を壊すことがある。 解決: 結合キーを複数列 (例: 都道府県 + 市町村) に変更するか、 事前に Table.Distinct で重複を排除する。

エラー7: クエリが見つかりません — 削除されました

原因: 参照していたクエリが削除された、 またはリネームされた。 「参照」で繋がっていたクエリチェーンが切れる。 解決: 詳細エディタで、 参照箇所を正しいクエリ名に書き直す。 Power BI Desktop なら「変換 → クエリの依存関係」で全体構造を確認できる。

エラー8: メモリ不足でクエリの評価が中断されました

原因: 大規模データを Power Query で処理しようとして、 マシンの RAM を使い切った。 100 万行を超えるデータでよく発生。 解決: (1) ソース段階で列を絞る (Table.SelectColumns)。 (2) フィルタを早期に適用する。 (3) クエリの折りたたみが効くソース (SQL DB) に変更する。 (4) Excel ではなく Power BI Desktop を使う (Power BI のほうがメモリ管理が優秀)。

エラー9: 接続が拒否されました — DataSource.Error

原因: DB やオンラインサービスへの接続が失敗。 認証情報の期限切れか、 ネットワーク問題が大半。 解決: 「ファイル → オプション → データソースの設定」で該当ソースの権限を更新する。 SSDSE のような CSV ベースなら基本的にこのエラーは出ない。

エラー10: 更新時にタイムアウトが発生しました

原因: クエリの実行に時間がかかりすぎて、 デフォルトのタイムアウト (10 分) を超えた。 解決: (1) クエリを最適化 (折りたたみ、 列絞り、 早期フィルタ)。 (2) タイムアウトを延長 (詳細エディタで CommandTimeout=#duration(0,0,30,0) を追加)。 (3) ソースを縮小 (期間を区切る)。

📊 エラー頻度ランキング (実務での体感)

エラーへの対処能力が、 Power Query 中級者と上級者を分ける。 上級者はエラーが出る前に「これはエラーが出そうだ」と予測して、 事前に防御コードを書ける。 SSDSE-B-2026 を題材に、 意図的にエラーを発生させて (例: 文字列を数値に変換しようとする) 対処パターンを練習すると、 短期間でエラー対処スキルが向上する。 業務データに突入する前に、 公的データで失敗経験を積むのが推奨学習法。

🌟 補論: パフォーマンスチューニング詳説 — 100 万行を 1 秒で処理する技

Power Query の性能は、 ステップの書き方次第で 100 倍以上の差が生まれる。 同じ結果を出すクエリでも、 ステップの順序・型変換のタイミング・結合方法によって、 実行時間が 1 秒で済むか 10 分かかるかが決まる。 ここでは SSDSE-B-2026 を 100 倍に拡張したベンチマークデータ (4,700 行 × 112 列) を題材に、 6 つの主要チューニング技を解説する。

技1: 列削減を最上流で行う (3-5 倍高速化)

SSDSE-B-2026 の 112 列のうち、 実際に必要なのは数列であることが多い。 整形の最後で列を絞るのではなく、 ソース直後で Table.SelectColumns(ソース, {"都道府県", "総人口", "一般診療所数"}) を実行する。 これにより、 後続のすべてのステップが 3 列に対してのみ処理されるので、 メモリ消費が 1/40 になる。 「あとから使うかも」と全列を残すのは、 パフォーマンス劣化の最大原因。

技2: 早期フィルタで対象行を減らす (10-100 倍高速化)

「人口 100 万以上の県のみ分析する」場合、 整形の最後でフィルタするのではなく、 ソース直後で Table.SelectRows(ソース, each [総人口] > 1000000) する。 SQL DB ソースなら、 これが WHERE 総人口 > 1000000 として DB に送られるので、 DB 側で行を絞ってから転送される。 100 万行のテーブルが 1 万行になれば、 後続処理は 100 倍速くなる。

技3: 型変換は 1 回でまとめる (2-3 倍高速化)

列ごとに Table.TransformColumnTypes を呼ぶと、 そのたびに全行スキャンが走る。 112 列を 1 列ずつ変換すると 112 回スキャンするが、 1 回のステップで全列をまとめて変換すれば 1 回で済む。

GUI でクリック操作で型変換すると 1 列ずつステップが追加されるので、 最後に詳細エディタで手動で 1 ステップにまとめると劇的に高速化する。

技4: バッファリングで参照を固定する (5-10 倍高速化)

同じテーブルを複数回参照する場合、 Table.Buffer でメモリに常駐させると、 毎回ソースから再計算するのを防げる。 例えば「県の人口と全国平均の差」を計算する際、 全国平均を 47 回計算するのではなく、 1 回計算してメモリに保持する。

バッファリングは強力だが、 大きなテーブルに使うとメモリを圧迫する。 数万行までが目安。

技5: 結合方式を吟味する (場合により 100 倍高速化)

Power Query の結合には NestedJoin と Join がある。 NestedJoin は遅延評価で、 展開するまで実体化されない。 一方 Join は即座にデカルト積を作る。 大規模テーブル同士なら NestedJoin、 小規模なら Join が高速。 また結合キーが SQL DB のインデックス列に対応していれば、 折りたたみが効いて DB 側で高速結合が走る。

技6: ステップ数を減らす (1.5-2 倍高速化)

Power Query は各ステップを 1 つの中間結果として扱うので、 ステップ数が多いほど評価コストが上がる。 同じ処理を 2 ステップに分けるより、 1 ステップにまとめる方が高速。 例えば「列追加 + 型変換」を別々のステップにせず、 Table.AddColumn(前, "新列", each ..., type number) のように型指定込みの 1 ステップにする。

📊 6 つの技を組み合わせた効果 (実測)

この表が示すように、 技1 (列削減) と技2 (早期フィルタ) の 2 つだけで 30 倍速くなる。 まずこの 2 つを習慣にすると、 Power Query の実用範囲が劇的に広がる。 SSDSE-B-2026 の規模 (2023 年度で 47 行 × 112 列) では差を体感しにくいが、 業務で 100 万行のデータを扱うようになると、 これらの技の有無で生産性が天と地ほど違う。 「とりあえず動くクエリ」から「現場で運用できるクエリ」に進化させる鍵がここにある。

⚠️ パフォーマンスチューニングの注意点

• 可読性とのトレードオフ: ステップを統合しすぎると、 後から見て何をしているか分からなくなる。 適度な可読性は維持すること。
• バッファリングの過剰使用: Table.Buffer をやみくもに使うと、 メモリ枯渇でかえって遅くなる。 必要な場面に限定する。
• 折りたたみの確認: 「View → Query Diagnostics」で折りたたみが効いているか定期的に確認する。 ある日突然効かなくなるケースがある (M 関数を追加すると壊れる)。
• ベンチマークの実施: 「速くなったはず」と思い込まず、 ストップウォッチで実測する。 ステップを変更したら必ず計測する習慣を。
• 本番データでの検証: 開発時の小規模データでは差が出なくても、 本番の大規模データで初めて問題が顕在化することがある。 リリース前に本番相当のデータで実行する。

🎓 補論: Power Query と統計分析の橋渡し

Power Query は「整形」までを担うが、 そこから先の統計分析・機械学習に進むには、 整形結果を pandas や R などに引き渡す必要がある。 ここでは SSDSE-B-2026 を題材に、 「Power Query で整形 → CSV エクスポート → pandas で分析」という連携ワークフローを具体的に示す。

ワークフロー1: 整形結果の CSV エクスポート

このコードでやること: Power Query で整形した結果を Excel から CSV として保存し、 pandas で読み込む。

1
2
3
4
5
6

import pandas as pd
df = pd.read_csv('data/raw/SSDSE-B-2026.csv',
                 encoding='cp932', skiprows=[1])
df = df[df['SSDSE-B-2026'] == 2023][['Prefecture', 'A1101', 'I5102']]
print(df.dtypes)
print(df.head(3))

📤 実行例:

💬 Power Query で列選択・型確定まで済ませた状態と同じ結果を、 pandas でも encoding='cp932' と skiprows=[1] (2 行目の日本語見出し行を読み飛ばす) を指定して再現できる。 総人口 (A1101)・一般診療所数 (I5102) がともに整数型で読めていれば、 整形作業ゼロで分析に入れる。

ワークフロー2: 相関分析

このコードでやること: 整形済みデータで「総人口と一般診療所数の相関」を計算する。 Power Query では計算できないので pandas の出番。

1
2
3
4
5
6
7
8
9

import pandas as pd
from scipy import stats

df = pd.read_csv('data/raw/SSDSE-B-2026.csv',
                 encoding='cp932', skiprows=[1])
df = df[df['SSDSE-B-2026'] == 2023]
r, pval = stats.pearsonr(df['A1101'], df['I5102'])
print(f'相関係数 r = {r:.4f}')
print(f'p 値      = {pval:.2e}')

📤 実行例:

💬 総人口と一般診療所数は r=0.97 と極めて強い正の相関。 p<0.001 で統計的に有意。 これは「人口が多い県ほど医療機関 (一般診療所) も多い」という直感を数値で裏付ける。 Power Query では「データの形を整える」までしかできず、 こうした統計的検証は pandas + scipy の領域。

ワークフロー3: 地方別の集計と検定

このコードでやること: Power Query で追加した「region」列を使って、 地方別に人口分布を比較する。 Kruskal-Wallis 検定で「地方間で人口分布に差があるか」を検定する。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import pandas as pd
from scipy import stats
df = pd.read_csv('data/processed/SSDSE_B_2026_cleaned.csv', encoding='utf-8-sig')
groups = [g['population_total'].values for _, g in df.groupby('region')]
h, pval = stats.kruskal(*groups)
print(f'Kruskal-Wallis H = {h:.2f}')
print(f'p 値             = {pval:.4f}')
print('\\n地方別の中央値:')
print(df.groupby('region')['population_total'].median().sort_values(ascending=False))
    </td></tr></table></div>

📤 実行例:

💬 p<0.001 で地方間の人口分布には統計的に有意な差がある。 関東の中央値 627 万人 vs 四国の 73 万人と 8.6 倍の差。 Power Query で region 列を準備したからこそ、 pandas で 3 行のコードで検定が完了する。 この連携が「業務整形は Power Query、 統計検証は Python」という分業の典型例。

このように、 Power Query と Python は対立するツールではなく、 役割分担で連携することで真価を発揮する。 Power Query が「データの形を整える職人」、 pandas が「整ったデータから知見を引き出す分析家」と捉えると、 両者のワークフローが自然に繋がる。 SSDSE-B-2026 を題材に、 この連携を実際に手で動かしてみることで、 データ分析の全体像が見える視野が育つ。

📖 補論まとめ — 統計分析への橋渡しチェックリスト

• Power Query で完了させること: 列名統一・型変換・欠損処理・マスター結合・地方区分の付与など、 「データの形を整える」までの作業。
• pandas に引き渡すこと: 相関分析・統計検定・回帰モデル・機械学習・可視化など、 「データから知見を引き出す」段階の作業。
• CSV 出力時の注意: 文字コードは UTF-8 BOM 付きを選ぶと、 Excel と pandas の両方で読み込み時の文字化けが防げる。 区切り文字は , (CSV) または \t (TSV) を統一する。
• 列名規則: pandas は日本語列名も扱えるが、 df['総人口'] のような表記が必要になる。 英語列名 (例: population_total) なら df.population_total と簡潔に書ける。 Power Query で英語化する習慣をつけると、 pandas での記述が楽になる。
• 再現性の担保: Power Query の M スクリプトと、 pandas の分析コードの両方を Git で管理する。 これにより「データソース → 整形 → 分析 → 結果」の一連の流れが完全に再現可能になる。 学術研究や監査対応では必須の作法。

この補論で示した 3 つのワークフローは、 SSDSE-B-2026 のような公的データを題材にした研究プロジェクトの典型的なパターン。 Power Query で月次の更新を自動化しつつ、 pandas で深掘り分析を行うという二刀流のスキルセットは、 これからのデータ分析者に強く求められる能力である。 47 都道府県という分かりやすい規模感のデータで両ツールに習熟してから、 業務での数百万行データに挑むのが、 最も効率的な学習パスと言える。

📚 さらに深掘りする 3 つの推奨ステップ

1. SSDSE-B-2026 で月次レポートを自作する: Power Query で SSDSE を取り込み、 地方別の人口・経済指標を集計してダッシュボードにまとめる。 これを毎月の練習として続けると、 Power Query の操作が完全に手に馴染む。 1 ヶ月で「ボタンを見て操作を考える」から「やりたいことから操作を逆算する」段階に進化する。
2. 同じ整形を pandas でも書く: Power Query のステップを 1 つずつ pandas のコードに翻訳してみる。 これにより両言語の対応関係が体系的に理解できる。 翻訳作業を通じて、 「M 言語的な思考」と「pandas 的な思考」の違いも見えてくる。
3. 業務データに適用する: 自分の所属組織の実データ (人事・売上・顧客など) を Power Query で整形してみる。 SSDSE-B-2026 で身につけた感覚が、 そのまま実務で活きる。 機密性のあるデータを扱うので、 セキュリティ設定 (プライバシーレベル) も同時に学べる。

最後に、 Power Query を学ぶ際に最も大切なのは「完璧を目指さないこと」。 業務で使えるクエリは、 必ずしも最適化されている必要はない。 まず動くものを作り、 それを少しずつ改善していくアジャイル的なアプローチが、 結果的に最速で実用レベルに到達する。 SSDSE-B-2026 という題材があれば、 失敗を恐れず何度でも試行錯誤できるので、 ぜひ手を動かして体得してほしい。 Power Query は習得に時間がかかるツールではあるが、 一度身につければ生涯使える普遍的なスキルとなり、 業務効率化の強力な武器になる。 同じ作業を毎月手作業で繰り返している自分の隣の同僚を、 Power Query 一つで自動化して救うことができるようになる。 これが Power Query を学ぶ最大の動機であり、 報酬でもある。 SSDSE-B-2026 で基礎を固め、 業務データで応用を磨き、 最終的には組織全体のデータ整形基盤を設計できるレベルに到達するのが、 Power Query 学習の最終目標である。 この目標に到達した時、 Power Query は単なるツールから「データ思考の言語」へと昇華する。 Excel/Power BI/Fabric の境界を越えて、 データ整形という普遍的な技術を体系的に運用できる人材は、 これからの時代に最も希少な存在の一つとなるだろう。 SSDSE-B-2026 を題材にしたこの学習プロセスが、 そんな未来への扉を開く確かな第一歩となることを心から期待したい。 学びは終わらない。 続けることが本当の力になる。

🔗 関連用語（前提・並列・発展）

power query を学ぶ際に併読すると理解が深まる関連用語を「前提・並列・発展」の 3 区分で整理する。

• 前提概念: Excel・CSV / JSON / Web API・データ型・テーブル変換 (フィルタ / 結合)
• 並列概念: pandas DataFrame・SQL・dbt・Alteryx・KNIME (いずれも ETL / データ整形を担う)
• 発展概念: M 言語・データフロー (Power BI / Fabric)・ETL / ELT・データパイプライン自動化

各概念は本用語集の他ページにリンクしている。 関連用語を横断的に学ぶことで、 power query の位置付けが明確になる。

📚 関連グループ教材

この用語の全体像を学ぶには、 まず横断的な教材で文脈を掴むのが効率的です：

• 📚 用語集トップ — カテゴリ別の一覧から関連用語を辿る
• 🗺️ 概念マップ — 全体の繋がりを俯瞰

🎯 Power Query が「データ整形の標準ツール」になった理由

Power Query は Microsoft が Excel・Power BI に組み込んだ「データ取得・整形（ETL）」のための GUI ベースのツール。 2013 年に Excel アドインとして登場し、 現在は Excel 2016 以降と Power BI Desktop に標準搭載。 「コードを書かずにデータ整形ができる」「ステップが記録され、 リフレッシュで自動再実行される」のが最大の特徴。

SSDSE-B-2026 のような 565 行 × 112 列の CSV を分析する場合、 従来は VLOOKUP・ピボットテーブル・手動コピペで時間がかかった作業を、 Power Query で「ステップを一度定義すれば毎月自動で再実行」できる。 これは Python/Pandas のスクリプト化と本質的に同じ「再現可能なデータ処理」を、 GUI で実現するもの。

📚 Power Query の歴史 — Excel から Power BI、 そして Fabric へ

10 年で「Excel アドイン」から「クラウドデータ統合の中核」へと進化。 M 言語の知識は Microsoft データプラットフォーム全体で活用できる資産になった。

📚 総まとめ — Power Query は「データ整形の民主化」

• GUI 操作で誰でも ETL（取得・変換・読込）が書ける
• ステップ式で「変換手順を記録 → 自動再実行」できる再現性
• M 言語で複雑な処理も可能（関数型プログラミング）
• Excel / Power BI / Microsoft Fabric / Azure Data Factory で共通
• SSDSE-B-2026 のような公開データを扱う場合、 Power Query は最短ルート
• 大規模データや機械学習を含む場合は pandas + Python に移行
• 両者を使い分けることで「現場ユーザーから DS まで」のスキル連続性が生まれる

次は Power BI や ETL ツール、 ピボットテーブル を学んで、 Microsoft データプラットフォーム全体を理解しよう。

📚 3 つのケーススタディ — Power Query で実問題を解く

ケース1: 県別 一般診療所数 順位の経年変化

SSDSE-B-2026 には複数年分 (2012〜2023) のデータが含まれる。 Power Query で「年 × 都道府県」のクロス集計表を作り、 一般診療所数 (I5102) の順位列を追加する。 上位県の順位変動を追うと、 医療インフラ集積の安定性が一目で分かる。

このコードでやること: SSDSE-B-2026 の一般診療所数 (I5102) を年別にピボットして順位を追加する pandas 実装。 Power Query の「ピボット列 → ランク列追加」と 1:1 で対応する。

📥 入力データ: SSDSE-B-2026.csv (47 都道府県 × 2012〜2023)。 下表は I5102 (一般診療所数) を年度でピボットした上位県の実数値。

1
2
3
4
5
6
7

import pandas as pd
df = pd.read_csv('data/raw/SSDSE-B-2026.csv',
                 encoding='cp932', skiprows=[1])
piv = df.pivot(index='Prefecture', columns='SSDSE-B-2026', values='I5102')
for y in [2018, 2020, 2022]:
    piv[f'{y}_順位'] = piv[y].rank(ascending=False, method='min').astype(int)
print(piv.sort_values('2022_順位').head(5)[['2018_順位', '2020_順位', '2022_順位']])

📤 実行結果:

💬 結果の読み方: 一般診療所数の上位 5 県 (東京・大阪・神奈川・愛知・兵庫) は 2018〜2022 を通じて順位が全く動かない。 医療インフラの集積は人口規模を強く反映し、 短期では安定していることが分かる。 一方で実数は東京都が 13,429 → 14,689 と増えるなど、 全国的に増加傾向にある。 Power Query で「順位列追加」を年ごとに繰り返して同じ表を作る場合、 各ステップは 5 秒の作業で完了する。

ケース2: 人口減少率ランキング

SSDSE-B-2026 で前後の年の人口を比較し、 減少率の大きい順に並べる。 Power Query では「列追加 (前年比) → 並べ替え」だけで完成する。 国土政策の議論ですぐに使えるアウトプット。

東北 4 県と高知が上位を占める。 これは Power Query なしでも分かるが、 「毎月リフレッシュして自動更新される県別ダッシュボード」を作るとなると、 GUI で組める Power Query の威力が出る。

ケース3: 人口規模と一般診療所数 (1 人当たり) の関係

Power Query で「人口規模の階層」と「一般診療所数 (10 万人当たり)」を結合し、 層別表を作る。 「人口が多い大都市ほど医療が充実している」と短絡的に言われがちだが、 SSDSE-B-2026 (2023) で 1 人当たりに直すと話は逆で、 むしろ人口の少ない県のほうが手厚いことが分かる。

実数では大都市に診療所が集中する (相関 r=0.97) が、 10 万人当たりで見ると人口下位 10 県が 91.5 と最も高く、 上位 10 県の 82.0 を上回る。 「実数の相関」を「1 人当たりの充実度」と早合点しないために、 図や層別表を Power Query で素早く作って検証する姿勢が、 データ分析の基本。

🔁 M 言語 vs SQL — 同じ ETL を 2 言語で書き分ける

Power Query の M 言語と RDB の SQL は「データを変換する」目的が同じ。 ただし発想が違う。 SQL は「結果セットを宣言する (集合論)」、 M 言語は「ステップを順に適用する (関数合成)」。 同じ処理を 2 つで書き比べると違いが見える。

SQL は「最終形を一度に書く」、 M 言語と pandas は「ステップを積み上げる」。 どちらが優れているではなく、 場面で使い分ける。 Power Query (M) は「個人作業」「Excel 出力」「中小規模 ETL」に強く、 SQL は「DB 内処理」「数億行スケール」「他システムとの統合」に強い。

🛠 上級者向け Tips — 実務でハマる 7 つの設計判断

1. Query Folding 維持: SQL ソースから取り込むときは Power Query が「最終クエリを SQL に変換」できる状態を維持する。 途中で M 関数を多用すると Folding が崩れ、 ローカルメモリで処理してしまう。 「ネイティブ クエリの表示」コマンドで Folding 状態を必ず確認する。
2. パラメータ化: ファイルパス・接続文字列・日付範囲は「パラメータクエリ」として外出しする。 環境 (開発/本番) で同じクエリを使い回せる。
3. テンプレート化: 似た構造の月次レポートは「テンプレート ファイル (.pbit)」として保存。 新しい月のデータが来たら、 そのテンプレートにデータを差し替えるだけ。
4. 関数ライブラリ化: 自社で頻繁に使う処理 (例: 日付を会計年度に変換) は let ... in でカスタム関数化し、 1 つのクエリにまとめて全社共有する。
5. エラー処理: try ... otherwise null でセル単位のエラーをハンドリング。 大量データで 1 セルのエラーが全行を止めるのを防ぐ。
6. 増分更新: 大規模ファクトテーブルは Power BI Premium の「増分更新」設定で「過去 5 年は変更なし、 直近 1 か月のみ再取込」と差別化する。 リフレッシュ時間が劇的に短縮。
7. テスト用ステップ: 「テスト」ステップで Table.RowCount(_) = 47 等のアサーションを入れる。 SSDSE のような既知のサイズに対する自動検証。

❓ 実務 FAQ — 8 つの実際の疑問

🎯 理解度チェック — 5 問

1. Q1. Power Query の「適用したステップ」とは何か、 1 文で説明せよ。 (A: ソース取得から最終出力までの変換手順を順序付きで記録した、 再実行可能な変換ログ)
2. Q2. Power Query で「列のピボット解除 (unpivot)」を行うと、 47 都道府県 × 3 年の横持ち表 (3 列) は何行 × 何列の縦持ち表になるか? (A: 141 行 × 3 列。 47 × 3 = 141)
3. Q3. Query Folding が成立する場合、 「フィルタ → 集計」は ① ローカル PC、 ② SQL ソース、 のどちらで実行されるか? (A: ② SQL ソース側。 これにより通信量と実行時間が削減される)
4. Q4. SSDSE-B-2026 を Power Query で読み込んだ際、 数値列が文字列扱いになる典型的原因を 2 つ挙げよ。 (A: ① CSV の桁区切り「,」が含まれる、 ② 0 行目の日本語ラベル行 (総人口 等) を一緒に読み込んでしまう)
5. Q5. M 言語の let X = ... in X 構造を、 pandas のどの構文と対応付けて理解できるか? (A: .pipe(f1).pipe(f2).pipe(f3) や中間変数を使った逐次代入。 ステップ式 = 関数合成という発想は両者共通)

5 問中 4 問以上正解なら、 本ページの内容を実務に持ち込める水準。 3 問以下なら「適用したステップ」「ピボット解除」「Query Folding」の 3 概念を再確認することを推奨する。

🎁 まとめ — Power Query を学ぶ 5 つの理由

1. GUI で書ける ETL: コードが書けない人でも、 列の選択・型変換・フィルタ・グループ化が直感的に組める。
2. 再現性のある変換: 「適用したステップ」が記録されるので、 新データが来ても同じ処理を 1 クリックで適用できる。
3. SQL / pandas との橋渡し: M 言語の発想は SQL とも pandas とも親和性が高く、 1 つを学ぶと他も理解しやすい。
4. Microsoft エコシステム標準: Excel・Power BI・Microsoft Fabric の共通 ETL レイヤー。 1 つ学べば全社的に展開できる。
5. SSDSE のような公開データで練習可能: 47 都道府県の実データで「読込 → 整形 → 集計 → 図」までを 1 ファイルで実演できる教材として最適。

Power Query は「現場ユーザーから DS まで」のスキル連続性を作る基盤ツール。 SSDSE-B-2026 を 1 週間真剣に Power Query で触ると、 多くの実務課題が GUI で解けることを実感できる。 そこから先は Power BI でダッシュボード化、 pandas で機械学習へと自然に視野を広げていける。

📖 M 言語クイックリファレンス — 業務で頻出する 20 関数

Power Query を仕事で使うとき、 頭に入れておくとよい M 言語関数は意外と少ない。 ここでは SSDSE-B-2026 を題材に、 頻出 20 関数を「目的・呼び出し例・pandas 等価」の 3 列で整理する。 これだけ覚えると業務 ETL の 8 割はカバーできる。

この 20 関数を「目的別に検索 → コピペ → 列名を書き換え」できるようになると、 SSDSE-B-2026 のような構造化データの ETL はほぼすべて自力で書ける。 残り 2 割は List.Generate (反復処理) や Record.AddField (構造体操作) などの応用関数で、 これは「必要になったときに調べる」で十分。

🚧 アンチパターン集 — Power Query 運用で避けたい 10 の罠

1. GUI 操作のみで M 言語を見ない: 「適用したステップ」の数式バーには M 言語コードが表示される。 見ずに進めると、 何の処理か後で再現できない。 SSDSE-B-2026 で実験するたびに数式バーを覗く習慣を。
2. クエリ名がデフォルト: 「クエリ1」「クエリ2」のままだと共有時に混乱する。 必ず「SSDSE_2026_人口」のように業務的に意味のある名前を付ける。
3. ハードコードされた件数: Table.FirstN(_, 47) のように件数をハードコードすると、 データが 48 件になった瞬間に欠落する。 Table.RowCount を組み合わせて動的に。
4. 同じソースを何度も取得: SSDSE-B-2026.csv を 3 つのクエリで別々に読み込むと、 リフレッシュが 3 倍遅くなる。 「参照」「複製」を使い分けて 1 回だけ読み込む。
5. 列の順番に依存した処理: Table.Column(_, 5) のような列インデックス参照は、 列追加で順番が変わると壊れる。 必ず列名で参照する。
6. エラー無視: 「エラーの削除」で目をつぶると、 本来重要だったデータが失われる。 「エラーの保持 → 別クエリで集計」で何が落ちたかを必ず確認する。
7. 変換途中の中間テーブルを Excel に出す: 不要な中間結果を Excel シートに出すとファイルサイズが膨らむ。 「接続のみ」設定で中間クエリは非表示にする。
8. 個人 PC のローカルファイルパス: C:\Users\shimpei\... のような絶対パスは共有時に壊れる。 OneDrive または SharePoint の URL でアクセスする。
9. 更新ボタン押し忘れ: ファイルを開いただけでは古いデータが残ったまま。 「すべて更新」をマクロまたは VBA で自動化するか、 Power BI Service にスケジューリングする。
10. Power Query を業務手順書に書かない: 担当者が異動すると、 誰も Power Query を触れない状態に。 「適用したステップ」のスクリーンショットを業務手順書に貼り付け、 引継ぎ可能な状態を維持する。

これら 10 のアンチパターンを意識すると、 SSDSE-B-2026 のような公開データを Power Query で扱う運用が、 長期にわたり保守可能になる。 ETL の品質は「初期構築」より「数年後の引継ぎ」で本当の真価が問われる。

🌅 結びに — Power Query から始まる「データ整形のリテラシー」

本ページでは Power Query の基本概念から、 SSDSE-B-2026 を題材にした実装、 アンチパターン、 FAQ までを一気に扱った。 Power Query が組織にもたらす変化は、 単に「Excel の処理が楽になる」だけではない。 「データを再現可能な形で扱う」という発想 が、 非エンジニアを含む全員に浸透することが本質。

SSDSE-B-2026 のような公開データで Power Query を一通り触ってみると、 「データ整形は職人芸ではなく、 手順を組み立てて検証する仕事」だと実感できる。 そして、 その手順を pandas で書き直せれば、 機械学習や予測モデルへの入り口にも立てる。

最後に強調しておきたいのは、 Power Query は 「ツール選択の問題」ではなく「思考様式の入口」 だということ。 ステップを順に適用し、 各ステップで「何を、 なぜ、 どう」変換したかを言語化する習慣は、 SQL でも pandas でも変わらないデータ実務の核心。 SSDSE-B-2026 を 1 週間 Power Query で触り、 同じことを pandas でも再現してみよう。 ETL のセンスは確実に身につく。

🧑‍🤝‍🧑 役割別 — Power Query は誰がどう使うか

同じ Power Query でも、 組織の中の立場によって使い方の重心が変わる。 役割別のユースケースを整理しておくと、 研修プログラムの設計や、 社内展開の優先順位付けに役立つ。 SSDSE-B-2026 のような統計データを題材にすると、 部門横断の共通言語が育つ。

役割が違えば「学ぶ深さ」も違う。 営業・経理向けは「GUI 中心 + 5 関数」、 経営企画向けは「Power BI と組み合わせて 10 関数」、 データ分析者は「M 言語全般 + カスタム関数 + DAX」というのが、 数十社の研修現場で形作られた相場感。

🗺 学習ロードマップ — 30 日で Power Query を業務に持ち込む

Power Query を「学んだことがある」から「業務で使えている」に引き上げるには、 30 日の集中演習が現実的。 SSDSE-B-2026 を 1 つの軸に据えると、 同じデータで段階的に難度を上げられる。

この 30 日プランを完走すると、 SSDSE-B-2026 を題材にした「再現可能な分析パイプライン」を 1 人で組めるようになる。 そこから先は社内データに置き換えるだけで、 即戦力に転じる。 「同じデータを 30 日触る」の継続性が、 ETL スキル習得の最短ルートと言える。

🔗 隣接手法への橋渡し

Power Query は Excel・Power BI のデータ取り込み & 前処理エンジンで、 ETL・データクレンジング・自動更新の中核。

• 上流: データソース — CSV・Excel・SQL Server・Web API など多様なソースに接続。 SSDSE-B-2026 を Power Query で読み込むなら encoding=cp932 指定。
• 並列: ETL — ETL (Extract-Transform-Load) と同概念で、 GUI で操作できる点が Power Query の特徴。 M 言語で内部記述。
• 下流: Power BI — Power Query で整形したテーブルが Power BI Desktop のデータモデルへ流れる。 接続更新で最新データを自動取得。
• 関連: M 言語・DAX が Power BI ファミリの 2 大言語。 M はデータ取得、 DAX は集計・計算列で役割分担。

SSDSE-B-2026 を用いた演習では、 「Power Query」 を中核に据えて上記の上流・並列・下流の手法を実データで連結する経験を積むと、 単独の手法暗記より実務的応用力が身につく。

🌳 手法選択フロー

「Power Query」を実際に使うとき、 何をどう選ぶかを順に判断する。 上から順に答えていくと、 使うべき手法と評価の仕方が決まる。

1. 繰り返す作業か、 1 回だけか
   毎月同じ整形をするなら、 手順が記録される Power Query が向く。 1 回で終わるなら、 手作業や単発のスクリプトのほうが速い。
2. 誰が保守するか
   Excel 上で GUI で組めるので、 プログラミングをしない人でも引き継げる。 一方、 差分の追跡やレビューはコードほどやりやすくない。
3. データ量はどれくらいか
   数十万行を超えると動作が重くなる。 その規模になったら、 データベース側で集計してから取り込む形に変える。
4. 文字コードと型を指定したか
   SSDSE のような cp932 の CSV は、 読み込み時に文字コードを指定しないと文字化けする。 地域コードは文字列として読み、 先頭 0 が消えないようにする。

Power Query の価値は「同じ整形を再実行できる」こと。 手作業の置き換えとしては強いが、 規模が大きくなったら別の道具に移る前提で使う。