New string functions and operators in Fabric Data Warehouseの変更点と確認ポイント

Microsoft Fabric Data Warehouseで文字列処理を多用している場合、2026年6月19日に確認された「New string functions and operators in Fabric Data Warehouse」は見逃せない更新です。結論から言うと、既存処理をすぐ変更しなければならない強制的な移行ではなく、表記ゆれ検出・あいまい検索・Unicode文字列・SQLの可読性改善に使える新しいT-SQL機能がプレビューとして追加されたという内容です。

特に確認すべきなのは、EDIT_DISTANCEやJARO_WINKLER_SIMILARITYなどの近似文字列マッチング関数をデータ品質改善に使えるか、||や||=を既存の+連結と混在させても意図したNULL処理になるか、UNISTRを国際化対応や特殊文字の扱いに使う場合に照合順序や文字コードの制約に引っかからないか、という3点です。Microsoft Fabric Blogでは、この更新はFabric Data Warehouse向けのプレビュー機能として紹介されています。([Microsoft Fabric Community][1])

New string functions and operators in Fabric Data Warehouse は何が変わった？

今回の変更は、Fabric Data Warehouseで利用できる文字列処理機能の拡張です。大きく分けると、次の2系統があります。

追加された機能	目的	使いどころ
EDIT_DISTANCE	2つの文字列の差分の大きさを数値化	誤字、表記ゆれ、近い文字列の検出
EDIT_DISTANCE_SIMILARITY	文字列の類似度を0〜100で評価	類似度のしきい値で候補を絞る
JARO_WINKLER_DISTANCE	文字列の距離を評価。先頭が一致する文字列を重視	氏名、地名、短いラベルの照合
JARO_WINKLER_SIMILARITY	Jaro-Winkler方式の類似度を0〜100で評価	顧客名、店舗名、都市名などの名寄せ
| |	ANSI SQLスタイルの文字列連結	SQLの可読性向上、他DBとの互換性改善
| | =	変数への文字列追加を簡潔に記述	動的SQLやメッセージ文字列の組み立て
UNISTR	Unicodeエスケープを使った文字列リテラルの扱い	絵文字、記号、多言語文字、特殊文字の表現

Microsoftの説明では、これらは「実データで起こる表記ゆれ」への対応をSQL内で行いやすくするものです。例として、Hong Kong、Hongkong、Hong-Kongのような地名の揺れや、名前・場所の入力差異を検出する用途が挙げられています。([Microsoft Fabric Community][1])

今回の分類はNoticeです。そのため、期限付きの廃止対応や設定変更を急ぐタイプの告知ではなく、Fabric Data WarehouseのSQL開発者・データエンジニアが新機能として検証すべき更新と捉えるのが現実的です。

影響を受けるMicrosoft Fabric利用者

今回の影響を受けやすいのは、Fabric Data Warehouseを単なる保存先ではなく、SQLでデータ整形・照合・分析前処理を行っているチームです。

影響が大きいケース

次のような運用をしている場合は、早めに検証する価値があります。

利用シーン	確認すべき理由
顧客名・会社名・店舗名の名寄せ	完全一致では拾えない表記ゆれをSQLで検出できる可能性がある
住所・都市名・国名の標準化	手入力データや外部連携データの揺れを抽出しやすい
Power BI用の集計前処理	レポート側ではなくWarehouse側で揺れを整理できる
Data FactoryやNotebookで文字列クレンジングしている	一部処理をT-SQLに寄せられる可能性がある
複数DB製品からFabricへSQLを移行している	| |によりANSI SQL寄りの文字列連結が書きやすくなる
多言語データや記号を扱う	UNISTRでUnicode表現を扱いやすくなる

一方で、既存のSQLが自動的に書き換わるわけではありません。既存処理への直接的な破壊的変更というより、今後のクエリ設計やデータ品質改善の選択肢が増えたという影響です。

近似文字列マッチングで何ができるようになるか

今回の目玉は、EDIT_DISTANCE、EDIT_DISTANCE_SIMILARITY、JARO_WINKLER_DISTANCE、JARO_WINKLER_SIMILARITYです。

これまでFabric Data Warehouseで表記ゆれを探す場合、LIKE、REPLACE、LOWER、TRIM、手作業の正規化テーブルなどを組み合わせる必要がありました。今回の関数を使うと、「完全一致しないが似ている文字列」をSQLで評価しやすくなります。

実務で使いやすい例

たとえば、顧客マスターに次のような会社名が混在しているとします。

入力値	人間が見た判断
山田商事株式会社	正式名
山田商事（株）	同一企業の可能性
ヤマダ商事株式会社	同一企業の可能性
山田商事	同一企業の可能性
山本商事株式会社	別企業の可能性

完全一致だけでは同じ候補として拾えません。しかし、近似文字列マッチングを使うと、類似度の高い候補を抽出し、人間の確認対象としてリスト化できます。

SELECT
    CustomerName,
    EDIT_DISTANCE_SIMILARITY(CustomerName, N'山田商事株式会社') AS Similarity
FROM dbo.CustomerMaster
WHERE EDIT_DISTANCE_SIMILARITY(CustomerName, N'山田商事株式会社') >= 80;

このようなクエリは、最終判断を自動化するというより、確認すべき候補を減らす目的で使うと実務に合います。類似度80以上だから同一と断定するのではなく、「レビュー対象」「候補グループ」「名寄せ候補」として扱うのが安全です。

Microsoft Learnでは、EDIT_DISTANCE_SIMILARITYは0が一致なし、100が完全一致を示す類似度を返すと説明されています。また、EDIT_DISTANCE系の関数はプレビューであり、現時点では転置をサポートしない点も明記されています。(Microsoft Learn)

EDIT_DISTANCE系とJARO_WINKLER系の使い分け

近似文字列マッチングは便利ですが、どの関数を使うかで結果の見え方が変わります。最初は次のように考えると選びやすくなります。

関数	向いている用途	判断のしやすさ
EDIT_DISTANCE	何文字分違うかを見たい場合	距離が小さいほど近い
EDIT_DISTANCE_SIMILARITY	類似度のしきい値で抽出したい場合	0〜100で扱いやすい
JARO_WINKLER_DISTANCE	短い名称や先頭一致を重視したい場合	距離が小さいほど近い
JARO_WINKLER_SIMILARITY	氏名・地名・商品名の候補順位付け	0〜100で扱いやすい

初心者や運用担当者が最初に試すなら、EDIT_DISTANCE_SIMILARITYまたはJARO_WINKLER_SIMILARITYが扱いやすいです。スコアが0〜100で返るため、Power BIや監査用テーブルに出したときも説明しやすいからです。

たとえば、データ品質チェックの運用では次のようにしきい値を分けると判断しやすくなります。

類似度スコアの例	運用上の扱い
95〜100	自動補正候補。ただし初期運用では人の確認を残す
85〜94	同一候補としてレビュー
70〜84	参考候補。誤検出が増えやすい
69以下	原則として別データ扱い

しきい値はデータの種類によって変わります。会社名のように長い文字列では高め、地名や人名のように短い文字列では誤検出が起きやすいため、最初は厳しめに設定するのが無難です。

|| と ||= は便利だがNULL処理に注意

||は、文字列を連結するANSI SQLスタイルの演算子です。従来のT-SQLでは+やCONCAT()を使う場面が多くありましたが、||を使うことで他のSQL製品に近い書き方ができます。Microsoft Learnでも、||はANSI SQL標準に従う文字列連結演算子として説明されています。(Microsoft Learn)

SELECT LastName || ', ' || FirstName AS DisplayName
FROM dbo.Users;

ただし、ここで注意したいのがNULLです。||はSET CONCAT_NULL_YIELDS_NULLの設定に従わず、入力のどれかがNULLなら結果もNULLになります。これは既存の+連結やCONCAT()に慣れているチームでは、見落としやすいポイントです。(Microsoft Learn)

たとえば、MiddleNameがNULLの可能性がある場合は、次のようにCOALESCEを使う方が安全です。

SELECT
    LastName || ' ' || COALESCE(MiddleName || ' ', '') || FirstName AS FullName
FROM dbo.Users;

||=は、変数に文字列を追加して代入するための演算子です。短い動的SQLやログメッセージの組み立てでは便利ですが、変数の宣言長を超えると切り捨てが起きる可能性があります。Microsoft Learnでは、変数がLOB型でない場合、結果は宣言された型の最大長に切り詰められると説明されています。(Microsoft Learn)

DECLARE @message nvarchar(100) = N'処理開始: ';
SET @message ||= N'顧客マスター検証';
SELECT @message;

運用で使う場合は、nvarchar(100)のような短い変数に安易に連結し続けないことが重要です。長くなる可能性がある文字列は、最初からnvarchar(max)などを検討してください。

UNISTR はUnicode対応に便利だが照合順序を確認する

UNISTRは、Unicodeエスケープを使って文字列を表現するための関数です。多言語データ、記号、絵文字、特殊文字をSQLで扱う場面で役立ちます。Microsoft Learnでは、\xxxxまたは\+xxxxxx形式でUnicode値を指定でき、NCHARより複数のUnicode値やエスケープシーケンスを扱いやすいと説明されています。(Microsoft Learn)

SELECT UNISTR(N'\306F\3044') AS JapaneseText;

上記のように、Unicode値を使って文字を表せるため、SQLスクリプト内で特殊文字を明示的に扱いたい場合に便利です。

ただし、charやvarcharで使う場合は照合順序に注意が必要です。Microsoft Learnでは、charやvarcharの入力では有効なUTF-8照合順序が必要で、レガシーコードページの照合順序とは互換性がないと説明されています。(Microsoft Learn)

日本語データを扱う現場では、nvarcharを使っているか、既存テーブルの照合順序がどうなっているかを確認してから検証するのが安全です。特に、外部システムから取り込んだ古い文字コード由来のデータが混在している場合、想定通りに表示・比較できるかをサンプルデータで確認してください。

すぐ確認したい設定・SQL・運用ポイント

今回のNoticeを受けて、管理者やデータエンジニアがすぐに確認すべきポイントを整理します。

確認項目	確認する理由	推奨アクション
対象ワークロード	Fabric Data Warehouseで文字列処理をしているか	Warehouse、SQL analytics endpoint、関連SQLを洗い出す
既存の名寄せ処理	NotebookやPipelineで重い前処理をしていないか	SQL関数で置き換えられる候補を探す
NULL連結の扱い	| |利用時に結果がNULLになる可能性がある	COALESCEやCONCAT()との使い分けを決める
文字列長	連結結果が切り捨てられる可能性がある	varchar(max)、nvarchar(max)の要否を確認
照合順序	UNISTRや多言語文字の扱いに影響する	UTF-8照合順序やnvarchar利用を確認
プレビュー利用方針	本番利用の判断が必要	重要処理では検証環境から始める
性能	近似マッチングは比較対象が多いと重くなりやすい	対象列、件数、しきい値、前処理を絞る

特に重要なのは性能です。近似文字列マッチングは便利ですが、全行対全行の比較に使うと処理量が急増します。たとえば10万件の顧客名を総当たりで比較すると、単純計算で膨大な比較が発生します。

実務では、次のように段階的に絞り込むのが現実的です。

SELECT
    c.CustomerId,
    c.CustomerName,
    r.ReferenceName,
    EDIT_DISTANCE_SIMILARITY(c.CustomerName, r.ReferenceName) AS Similarity
FROM dbo.CustomerMaster AS c
JOIN dbo.ReferenceCustomer AS r
    ON LEFT(c.CustomerName, 1) = LEFT(r.ReferenceName, 1)
WHERE EDIT_DISTANCE_SIMILARITY(c.CustomerName, r.ReferenceName) >= 85;

この例では、最初の1文字が一致するものに絞ってから類似度を計算しています。実際には、都道府県、国コード、法人種別、メールドメイン、電話番号の一部など、業務データに合った前処理条件を加えると、誤検出と処理負荷を減らしやすくなります。

既存環境で急いで変更すべきか

今回の更新だけを理由に、既存SQLを急いで全面的に書き換える必要はありません。むしろ、既存の安定した処理を変更する場合は、差分検証を行うべきです。

優先度は次のように考えると判断しやすくなります。

優先度	対象	対応方針
高	表記ゆれ・名寄せ・重複検出に課題がある環境	検証用クエリを作り、精度と性能を確認
中	複数DBからFabricへ移行中の環境	| |の採用可否とNULL処理ルールを設計
中	多言語・特殊文字を扱う環境	UNISTRと照合順序を検証
低	単純な集計・数値分析中心の環境	すぐの対応は不要。機能把握に留める

また、Microsoft Learnの各関数ページではプレビュー機能であることが示されています。プレビュー機能は仕様や動作が変わる可能性があるため、基幹処理や監査対象の本番処理に組み込む場合は、リリースノートと公式ドキュメントを確認しながら段階的に導入するのが安全です。(Microsoft Learn)

管理者・開発者向けの実践チェックリスト

Fabric管理者やデータ基盤担当者は、次の順番で確認すると効率的です。

既存処理の棚卸し

まず、Warehouse内で文字列加工をしているSQLを洗い出します。特に、LIKE、REPLACE、TRIM、LOWER、UPPER、CONCAT、+による文字列連結を多用しているクエリは確認対象です。

確認したいのは、「新関数に置き換えるべきか」ではなく、「新関数を使うと保守しやすくなる処理があるか」です。すべてを変更する必要はありません。

サンプルデータで精度を確認する

次に、実データから100〜1,000件程度のサンプルを取り、類似度スコアを出してみます。ここで重要なのは、正解データを人間が確認することです。

「85以上なら同一」と最初から決めるのではなく、業務担当者が見て納得できる境界値を探してください。人名、会社名、住所、商品名では適切なしきい値が変わります。

NULLと文字列長のルールを決める

||を使う場合は、チーム内でNULLの扱いを統一しておくとトラブルを避けられます。

たとえば、次のようなルールを決めておくと安全です。

ルール	例
NULLを空文字として扱いたい場合	COALESCE(ColumnName, '')を使う
NULLを異常値として検出したい場合	あえて| |のNULL伝播を利用する
表示名を作る場合	CONCAT()と| |のどちらを標準にするか決める
長いログ文字列を作る場合	nvarchar(max)を使う

本番投入前に性能を測る

近似マッチング関数は、使い方によっては便利な反面、比較回数が増えやすい処理です。Power BIの更新前処理や定期バッチに組み込む場合は、対象件数を変えて実行時間を測ってください。

特に次のようなクエリは注意が必要です。

-- 注意：件数が多いテーブル同士で総当たりに近い比較をすると重くなりやすい
SELECT *
FROM dbo.CustomerA AS a
JOIN dbo.CustomerB AS b
    ON EDIT_DISTANCE_SIMILARITY(a.Name, b.Name) >= 85;

このような書き方をする前に、国、地域、頭文字、法人番号、メールドメインなどで候補を絞る設計を検討しましょう。

今回の変更をどう活用すべきか

今回の「New string functions and operators in Fabric Data Warehouse」は、Fabric Data Warehouseをより実務的なデータ品質改善の場として使いやすくする更新です。単に文字列関数が増えたというより、これまでSQL外で処理していた名寄せ、表記ゆれ検出、Unicode文字列処理をWarehouse側に寄せられる可能性があります。

ただし、プレビュー機能であること、NULL連結の挙動、文字列長の切り捨て、照合順序、近似マッチングの性能には注意が必要です。特に本番データの自動補正に使う場合は、最初から自動更新するのではなく、候補抽出、業務確認、しきい値調整、段階導入の順に進めるのが安全です。

まずは、Fabric Data Warehouse内で表記ゆれや重複候補の検出に困っているテーブルを1つ選び、EDIT_DISTANCE_SIMILARITYまたはJARO_WINKLER_SIMILARITYで候補リストを作ってみてください。そこで精度と処理時間を確認し、効果が見える処理から運用に組み込むのが、今回の更新を最も実務的に活かす進め方です。
[1]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/New-string-functions-and-operators-in-Fabric-Data-Warehouse/ba-p/5195232 “
New string functions and operators in Fabric Data … – Microsoft Fabric Community
“