【Fabric / KQL】extend と project の違い・使い分けを整理する

Microsoft Fabric や Azure Data Explorer（KQL）を使い始めると、
extend と project の違いがあいまいなままクエリを書いてしまうことがよくあります。
今回この2つを整理します。

結論：extend と project の違い

演算子	何をするか	列の扱い
extend	計算列を追加する	既存の列はすべて残る
project	列を選択する	指定していない列はすべて消える

一言で言うと、

• extend は「列を増やす」
• project は「列を減らす（SELECT のイメージ）」

extend の例：列を追加するだけ

Sales
| extend Date = format_datetime(SaleDate, 'yyyy-MM-dd')

このクエリでは、以下の状態になります。

• SaleAmount、SaleDate、PaymentMode などの元の列はすべて残る
• Date という新しい列が追加される

extend は、後続の処理で使う可能性のある「中間計算用の列」を作るための演算子です。

project の例：列を選択して絞り込む

Sales
| project SaleAmount, PaymentMode

この場合、

• 指定した列だけが残る
• 指定していない列（SaleDate など）は完全に消える

project は、最終的な出力を整えるために使います。
SQL の SELECT とほぼ同じ役割です。

extend と project の使い分け

中間計算に使う列を作りたい場合は extend

Sales
| extend Date = format_datetime(SaleDate, 'yyyy-MM-dd')
| summarize sum(SaleAmount) by Date

SaleDate を元に Date を作り、その後で集計しています。
元の列を残しておく必要があるため、extend が正解です。

最終的に必要な列だけにしたい場合は project

Sales
| project CustomerName, Date, SaleAmount

出力に必要な列だけを残したい場合は project を使います。

基本形は「extend → project」

最もよく出てくる形は次の流れです。

1. extend で計算列を作る
2. project で不要な列を削る

Sales
| extend Date = format_datetime(SaleDate, 'yyyy-MM-dd')
| join Customers on CustomerID
| project CustomerName, Date, SaleAmount, PaymentMode
| summarize sum(SaleAmount) by CustomerName, Date

extend は前処理、project は仕上げと考えると分かりやすいです。

やってはいけないパターン

project は「指定していない列をすべて削除する」演算子です。
そのため、配置を間違えるとクエリが簡単に壊れます。

よくある失敗例

• summarize の前に必要な列が消えている
• format_datetime が参照する元列が存在しない
• join のキー列が削除されている

project は「この列はもう絶対に使わない」と判断できる場所に置く必要があります。

まとめ

• extend

  • 列を追加する
  • 既存の列は消えない
  • 中間計算や補助列向け

• project

  • 列を選択する
  • 指定していない列は消える
  • 最終出力の整形向け

迷ったときは次の問いを基準にすると判断しやすくなります。

「この列は、後続の処理で使う可能性があるか？」

• あるなら extend
• ないなら project

この2つを正しく使い分けられるようになりましょう。