1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Power Apps / Power AutomateにおけるUnicode検索の不一致 ― SharePointの丸数字①〜㊿で検証

1
Last updated at Posted at 2026-10-15

概要と結論

SharePointの1行テキスト列に保存した BOX①〜BOX㊿ を、Power AppsとPower Automateで検索した。

㉑〜㊿では異なる丸数字まで一致し、Power AppsのLookUpは別の行を返した。一方、取得後のローカル比較では全50種類を区別できた。

今回の回避策は、候補を漏れなく取得してから再比較すること。内部原因は未確定であり、特定の照合順序の不具合とは断定していない。

現象説明

2026年10月16日、SharePoint Onlineの検証専用リストに、Title列(1行テキスト)として BOX①〜BOX㊿ の50行を保存した。保存後も50種類の値が保たれていることを確認し、各文字列で検索した。

Power Automateでは、Get itemsのFilter Queryに次を指定した。

Title eq 'BOX㉛'

Power Appsでは、検索値を varProbe に入れて次を実行した。

Filter(UnicodeComparisonLab20261016, タイトル = varProbe)
LookUp(UnicodeComparisonLab20261016, タイトル = varProbe)
検索値 AutomateのFilter Query/Appsの直接Filter Appsの直接LookUp
BOX①〜BOX⑳ 対象の1行だけ 対象の行
BOX㉑〜BOX㊿ どの値でも㉑〜㊿の30行 すべてBOX㉑(ID21)

Power Appsの全50件では、Filterの不一致が30件、LookUpの不一致が29件だった。LookUpでは㉑の検索だけが返却値と一致するため、誤りが29件になる。常にID21が返るという順序保証を示す結果ではない。

同じ50行に対するPower AppsのローカルFilter/LookUpと、Power AutomateのFilter arrayによるequals比較は、すべて正しい1行に一致した。

原因と対策

原因:比較を行う経路によって結果が異なる

保存値は壊れておらず、取得後には区別できた。確認できたのは、SharePoint接続への検索とローカル比較で、一致判定が異なるという点である。

原因候補として、検索経路の照合処理で一部の文字の違いが評価されていない可能性がある。Microsoftも、一般的な文字列比較では方式により一致判定が変わり、未定義文字を無視する関数があると説明している。ただし、これは今回のSharePoint内部実装を裏付ける資料ではない。Microsoft:比較関数の注意事項

NFKC正規化だけでも説明できない。㉛と㉜は正規化後も31と32で異なる。内部原因の確定には、Monitorや直接RESTとの比較、Microsoftへの確認が残る。Unicode正規化の仕様

対策:取得後に再比較する

Power Appsでは、今回の50行をコレクションへ取得した後、次の比較で正しい行を取得できた。

ClearCollect(colSaved, UnicodeComparisonLab20261016);
LookUp(colSaved, タイトル = varProbe)

Power Automateでは、取得した value をFilter arrayへ渡し、検索値を入れた変数と比較する。

@equals(item()?['Title'], variables('TargetTitle'))

前提は、必要な候補をすべて取得できていること。 Power AppsのClearCollectは委任できず、非委任の取得上限は通常500行、最大2,000行。大きなリストへの単純な全件取得は避ける。Power Automateも取得件数・ページングを確認し、再比較後の出力を使う。Power Appsの取得上限、Get itemsの取得数・ページング

今回の再比較は、無条件取得した50行で検証した。Filter Queryで候補を絞ってから再比較する構成は、対象行が候補から欠落しないことを別途検証する必要がある。Top Countを1にしたり、過剰一致した結果の先頭行だけを使ったりしても解決しない。

長期的には、表示名と検索キーを分け、既知の項目IDなどで対象を特定する設計が考えられる。これは本検証では未実装の対策案である。

結言

今回の条件では、①〜⑳と㉑〜㊿で検索結果が分かれた。「eqや=で比較した」「1件だけ返った」だけでは、意図した行を取得できたとは限らない。件数に加え、返却IDと実際の値を確認することが重要である。

本結果はSharePointの1行テキスト列と今回の式で確認したもの。他の列型・データソースや、Unicode全般の比較へは一般化しない。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?