実務で使えるPower Query小技・テクニック | /* */ コメントを使う

M言語でのコメントの基本を整理する

Power Query（M言語）で「/* … */ コメントを使いたい」と思う方は多いですが、結論から言うと M言語には C言語や JavaScript のような /* ... */ 形式のブロックコメント構文は存在しません。 Mで使えるコメントは // の行コメントだけです。

ただし、「複数行まとめて説明したい」「一時的にコードを無効化したい」といったニーズは当然ありますので、ここではそれを 安全に・実務的に実現するための考え方とテクニックをステップバイステップで解説していきます。

M言語では /* */ コメントは使えない

なぜ /* */ が使えないのか

M言語の構文仕様では、コメントは次の1種類だけです。

// ここから行末までがコメント

// ここから行末までがコメント

/* ... */ のようなブロックコメントはサポートされていません。 そのため、Mコードの中にそのまま /* ... */ を書くと 構文エラーになり、クエリが実行できなくなります。

例：これはエラーになります。

let
    Source = Excel.CurrentWorkbook(){[Name="売上"]}[Content],

    /* 金額が1000より大きい行だけ残したい */
    Filtered =
        Table.SelectRows(Source, each [金額] > 1000)
in
    Filtered

let
    Source = Excel.CurrentWorkbook(){[Name="売上"]}[Content],

    /* 金額が1000より大きい行だけ残したい */
    Filtered =
        Table.SelectRows(Source, each [金額] > 1000)
in
    Filtered

M言語のパーサは /* を「演算子や記号」としても認識できないため、 「意味不明なトークン」としてエラーになります。

「ブロックコメントしたい」ときの安全な代替手段

複数行コメントは // を並べて書く

M言語で「ブロックコメントっぽいこと」をしたい場合は、行頭に // を並べるのが基本です。

// このステップでは顧客コードの表記ゆれを修正します
// ・前後の空白を削除
// ・全角→半角に統一
// ・NULLは空文字に変換
CleanedCustomerCode =
    Table.TransformColumns(
        Source,
        {{"顧客コード", Text.Trim, type text}}
    )

// このステップでは顧客コードの表記ゆれを修正します
// ・前後の空白を削除
// ・全角→半角に統一
// ・NULLは空文字に変換
CleanedCustomerCode =
    Table.TransformColumns(
        Source,
        {{"顧客コード", Text.Trim, type text}}
    )

見た目はブロックコメントに近く、M言語としても完全に正しい構文です。 「複数行まとめて説明したい」「処理の意図を詳しく書きたい」ときは、このスタイルを使うのが安全です。

コードを“まとめて無効化”したいときの考え方

「この処理ブロックを一時的に無効化したいから、全部コメントアウトしたい」という場面もあります。 C言語なら /* ... */ で囲めば一発ですが、M言語ではそれができません。

代わりに、次のような方法を使います。

方法1：行ごとに // を付ける

// Filtered =
//     Table.SelectRows(Source, each [金額] > 1000),
//
// AddedTaxColumn =
//     Table.AddColumn(Filtered, "税込金額", each [金額] * 1.1),

// Filtered =
//     Table.SelectRows(Source, each [金額] > 1000),
//
// AddedTaxColumn =
//     Table.AddColumn(Filtered, "税込金額", each [金額] * 1.1),

手間はかかりますが、最も安全で確実な方法です。 特に実務では「誤って本番クエリを壊さないこと」が最優先なので、 多少面倒でもこの方法を選ぶ価値があります。

方法2：一時的に別ステップに切り出して in を差し替える

let
    Source = Excel.CurrentWorkbook(){[Name="売上"]}[Content],

    Filtered =
        Table.SelectRows(Source, each [金額] > 1000),

    AddedTaxColumn =
        Table.AddColumn(Filtered, "税込金額", each [金額] * 1.1)
in
    Source   // ← 一時的に元データだけ返す

let
    Source = Excel.CurrentWorkbook(){[Name="売上"]}[Content],

    Filtered =
        Table.SelectRows(Source, each [金額] > 1000),

    AddedTaxColumn =
        Table.AddColumn(Filtered, "税込金額", each [金額] * 1.1)
in
    Source   // ← 一時的に元データだけ返す

このように、in で返すステップを変えることで、 処理ブロックを「実質的に無効化」することもできます。

セキュリティや品質の観点では、 「コード自体は残しておき、どのステップを最終結果にするかを切り替える」方が安全な場合も多いです。

セキュリティ・品質の観点から見たコメントの注意点

コメントに機密情報を書かない

コメントは「コードの一部」であり、 Power Query エディタを開ける人なら誰でも読めます。

そのため、次のような情報をコメントに書くのは避けるべきです。

• パスワード
• 接続文字列の認証情報
• 個人情報の具体的な値
• セキュリティ上の脆弱性に関する詳細な説明

例：これは絶対に避けるべきです。

// 社内DBの管理者パスワードは P@ssw0rd! です

// 社内DBの管理者パスワードは P@ssw0rd! です

コメントは「処理の意図」「業務ルールの概要」までにとどめるのが安全です。

コメントと実際の処理がズレないようにする

実務でよくある事故が「コメントとコードの内容がズレている」ケースです。

// 金額が1000より大きい行だけ残す
Filtered =
    Table.SelectRows(Source, each [金額] >= 1000)  // 実際は >= になっている

// 金額が1000より大きい行だけ残す
Filtered =
    Table.SelectRows(Source, each [金額] >= 1000)  // 実際は >= になっている

このようなズレは、仕様の誤解・バグ・監査上の問題につながります。

そのため、次のような習慣が重要です。

• ロジックを変更したら、コメントも必ず見直す
• コメントには「具体的な条件」を書きすぎない（例：> 1000 など）
• 「高額行だけ残す」「不正データを除外する」など、少し抽象度を上げて書く

コメントは「仕様書」ではなく「意図のメモ」です。 コードと矛盾しない範囲で、抽象度を調整することが品質面で重要です。

実務で使えるコメントテンプレート

処理ブロックの説明テンプレート

// このステップでは売上データのクレンジングを行います
// ・顧客コードの表記ゆれを修正（トリム＋全角→半角）
// ・金額が0以下の行を除外
// ・必須項目が未入力の行をエラーとして分離
CleanedSales =
    ...

// このステップでは売上データのクレンジングを行います
// ・顧客コードの表記ゆれを修正（トリム＋全角→半角）
// ・金額が0以下の行を除外
// ・必須項目が未入力の行をエラーとして分離
CleanedSales =
    ...

セキュリティ・品質を意識したコメントテンプレート

// 外部システムから取得したデータのうち、業務上利用可能な行のみを残す
// （不正値・欠損値・マスタ未存在コードを除外）
FilteredBusinessValidRows =
    ...

// 外部システムから取得したデータのうち、業務上利用可能な行のみを残す
// （不正値・欠損値・マスタ未存在コードを除外）
FilteredBusinessValidRows =
    ...

// この結合は売上明細と顧客マスタの整合性チェックを目的としたもの
// 本番集計にはマスタ未存在行を含めない前提
MergedCustomerMaster =
    ...

// この結合は売上明細と顧客マスタの整合性チェックを目的としたもの
// 本番集計にはマスタ未存在行を含めない前提
MergedCustomerMaster =
    ...

コメントに「目的」「前提条件」「利用範囲」を書いておくことで、 セキュリティ・品質の観点からも安心して運用できるクエリになります。

まとめ：M言語では /* */ は使えない。だからこそ // を“意図的に”使う

ここまでのポイントを整理すると、次の通りです。

• M言語には /* ... */ ブロックコメント構文は存在しない
• コメントは // の行コメントのみ
• 複数行コメントは // を並べて書く
• コードを一時的に無効化したいときは、行ごとに // を付けるか、in を切り替える
• コメントには「処理の意図」「目的」「前提」を書く
• 機密情報や具体的なパスワードなどはコメントに書かない

「/* / が使えない」という制約はありますが、 // コメントを意図的に使いこなせば、読みやすくて安全な M コード*を書けます。

次に学ぶと良い関連テーマ

• // コメントを書く基本と実務での使い方
• ステップ名の付け方（変数としての意味を意識する）
• let … in の構造と中間結果の確認テクニック
• クレンジング処理にコメントを組み込んだテンプレート設計

こうしたテーマと組み合わせることで、 「読める・守れる・安心して運用できる Power Query」を設計できるようになります。