詳細エディターとは何か
Power Queryの「詳細エディター」は、クエリ全体のMコードをテキストとして直接編集できる専用画面です。 通常はリボンや右クリックメニューから操作してステップが自動生成されますが、詳細エディターを使うと、
- ステップの追加・削除・並び替え
- 関数化・再利用・テンプレート化
- 細かなロジックやセキュリティチェックの埋め込み などを、コードレベルでコントロールできるようになります。
実務で本気でPower Queryを使いこなすなら、詳細エディターは「避けて通れないステージ」です。 ここから、初心者向けにステップバイステップで、詳細エディターの意味と使い方を噛み砕いて説明していきます。
詳細エディターで見えるもの：クエリの“素顔”
let ～ in 構造とステップ一覧
詳細エディターを開くと、だいたい次のようなコードが見えるはずです。
let
ソース = Excel.CurrentWorkbook(){[Name="売上"]}[Content],
変更された型 = Table.TransformColumnTypes(ソース, {{"金額", type number}}),
フィルター行 = Table.SelectRows(変更された型, each [金額] > 1000),
並べ替え済みの行 = Table.Sort(フィルター行, {{"金額", Order.Descending}})
in
並べ替え済みの行
ここで重要なのは、
letの中に「ステップ名 = 処理」が並んでいるinの後ろに「最終的に返すステップ名」が書かれている- 画面左のステップ一覧と、このコードが1対1で対応している
という構造です。
詳細エディターは、「ステップ一覧の裏側で動いているMコードをそのまま見せてくれる場所」だと理解していただくとよいです。
ステップ名と処理内容を“文字で”把握できる
通常の画面では、ステップ名と簡単な説明しか見えませんが、 詳細エディターでは、
- どのステップがどの関数を使っているか
- どの列にどんな型を設定しているか
- どの条件でフィルタしているか
がすべてコードとして見えます。
これは、
「クエリの意図を、言葉ではなくコードとして正確に把握できる」
という意味で、品質・セキュリティ・保守性の観点から非常に大きな価値があります。
ステップバイステップで詳細エディターを使いこなす
ステップ1：まずは“読む”ことに慣れる
最初から全部書き換えようとせず、 「今あるクエリのコードを読む」ことから始めるのがおすすめです。
見るポイントは次の3つです。
- ステップ名
- 何をしているステップか、名前から推測する
- 関数名
Table.TransformColumnTypes,Table.SelectRows,Table.AddColumnなど- どの関数がどのステップで使われているかを把握する
- 引数（パラメータ）
- どの列にどんな型を設定しているか
- どんな条件でフィルタしているか
例：型変換ステップを読む
変更された型 =
Table.TransformColumnTypes(
ソース,
{
{"顧客コード", type text},
{"顧客名", type text},
{"金額", type number},
{"売上日", type date}
}
),
ここから、
- 「顧客コード・顧客名は文字列」
- 「金額は数値」
- 「売上日は日付」
という前提が、このステップで作られていることが分かります。
詳細エディターは、クエリの“仕様書”でもあるので、まずは読む力を育てることが大事です。
ステップ2：小さな修正から始める
次に、詳細エディター上で「小さな修正」をしてみます。
例：フィルタ条件を少し変える
元のコード：
フィルター行 =
Table.SelectRows(
変更された型,
each [金額] > 1000
),
これを、「1000以上」に変えたいとします。
修正後：
フィルター行 =
Table.SelectRows(
変更された型,
each [金額] >= 1000
),
このように、
- ステップ名はそのまま
- 関数名もそのまま
- 条件式だけを変更
という小さな修正から始めると、 詳細エディターでコードをいじることへの心理的ハードルが下がります。
「画面のボタンでできることを、コードでやってみる」という感覚で練習していくとよいです。
ステップ3：ステップの追加・削除をコードで行う
慣れてきたら、ステップの追加・削除も詳細エディターで行ってみます。
例：消費税額列を追加するステップを挿入
let
ソース = Excel.CurrentWorkbook(){[Name="売上"]}[Content],
変更された型 = Table.TransformColumnTypes(ソース, {{"金額", type number}}),
// ここで新しいステップを追加
消費税額追加 =
Table.AddColumn(
変更された型,
"消費税額",
each [金額] * 0.1,
type number
),
フィルター行 =
Table.SelectRows(
消費税額追加,
each [金額] > 1000
),
並べ替え済みの行 =
Table.Sort(
フィルター行,
{{"金額", Order.Descending}}
)
in
並べ替え済みの行
ここでのポイントは、
- 新しいステップ名：
消費税額追加 - 参照元：
変更された型 - 後続ステップの参照先：
変更された型→消費税額追加に変更
という「依存関係の鎖」を意識して書き換えていることです。
詳細エディターでは、ステップ間の依存関係をコードとして明示的に扱うことになるので、 前のステップ名を変えたら、後続ステップの参照も必ず確認する癖をつけると安全です。
詳細エディターを使うメリット
1. 自動生成コードの“ノイズ”を整理できる
GUI操作でクエリを作ると、
- 不要なステップ
- 意味の重複したステップ
- 名前が分かりづらいステップ
がどうしても混ざります。
詳細エディターを使うと、
- 似た処理を1つのステップにまとめる
- 不要なステップを削除する
- ステップ名を意味のある名前に変える
といった「コードの整理」ができます。
これは、
「クエリを“動けばいいもの”から“読める・守れるもの”に育てる」
ために、実務では非常に重要です。
2. テンプレート化・再利用がしやすくなる
詳細エディターでMコードを扱えるようになると、
- よく使う処理パターンをテンプレートとして保存する
- 別のクエリにコピペして再利用する
- 一部だけ書き換えて別案件に流用する
といったことが簡単になります。
例：売上クエリの基本テンプレート
let
Source = Excel.CurrentWorkbook(){[Name="売上"]}[Content],
Typed =
Table.TransformColumnTypes(
Source,
{
{"顧客コード", type text},
{"顧客名", type text},
{"金額", type number},
{"売上日", type date}
}
),
FilteredPositiveSales =
Table.SelectRows(
Typed,
each [金額] > 0
)
in
FilteredPositiveSales
このようなテンプレートを詳細エディターから貼り付けて、 列名や条件だけ変える、といった使い方ができるようになります。
3. セキュリティ・品質のロジックを明示的に管理できる
詳細エディターでは、
- どのステップで権限チェックをしているか
- どのステップで有効行のフィルタをしているか
- どのステップで型変換をしているか
がコードとして明示されます。
これは、
- セキュリティレビュー
- 品質チェック
- 障害調査
の場面で非常に役立ちます。
「どこで何をしているか」がコードで追える状態にしておくことは、実務の安全性を高めるうえで欠かせません。
詳細エディターを使うときの重要な注意点
1. 依存関係を壊さない
前のステップ名を変えたり削除したりすると、 後続ステップが参照している名前が無効になり、エラーや静かなバグが発生します。
- ステップ名を変更するときは、後続ステップの参照も必ず確認する
- ステップを削除するときは、そのステップがどこから参照されているかを確認する
という「依存関係の意識」が、詳細エディターでは特に重要です。
2. 型とnullを意識する
詳細エディターで直接コードを書くときほど、
- 列の型（number / text / date / logical）
- null の扱い
を意識する必要があります。
例：型変換を削除した結果、フィルタ条件が文字列比較になってしまう 例：nullチェックを忘れて計算でエラーになる
こうした問題は、GUIだけを見ていると気づきにくいですが、 詳細エディターでコードを読むと「前提」が見えるようになります。
「このステップはどの型を前提にしているか」「nullが来たらどうなるか」をコードから読み取る癖をつけると、安全性が一気に上がります。
3. 大きな変更は段階的に行う
詳細エディターで一気に大きな変更をすると、 どこで壊れたか分からなくなりがちです。
- まず小さな変更をして動作確認
- 次にもう一段階変更して確認
- 変更のたびにプレビューを見て結果を確認
という「段階的な変更」を心がけると、 トラブルが起きても原因を特定しやすくなります。
まとめ：詳細エディターは“クエリを設計するための作業机”
「詳細エディターを使う」というのは、 単にコードをいじるというより、
「クエリ全体の構造・依存関係・前提条件を、Mコードとして設計・管理する」
という行為に近いです。
それによって、
- 自動生成されたクエリを整理して読みやすくできる
- テンプレート化・再利用がしやすくなる
- セキュリティや品質のロジックを明示的に管理できる
- 障害時に「どこで何が起きているか」をコードから追える
という大きなメリットが得られます。
ぜひ、
- まずは「読む」ことから始める
- 小さな修正で慣れる
- ステップの追加・削除をコードで試してみる
- 依存関係・型・null・セキュリティ前提を意識して設計する
という流れで、詳細エディターを「怖い画面」から「頼れる作業机」に変えていっていただきたいです。