今回は、Power AppsでコンボボックスやAddColumnsを使おうとしたら、なぜかエラーが出てしまったり、ThisRecordがまったく使えなかったりする問題に悩んでいる人に向けて、長いやりとりの中で得られた知見をまとめるよ。とくに「クラシック環境」と「評価モード1.0／2.0」に関する話は、公式ドキュメントにも断片的にしか載っていなくて、戸惑いやすいんだ。実際に僕もChatGPTと一緒に試行錯誤しながら、一歩ずつ解決策を探ったからこそ分かったポイントがたくさんあるんだ。ぜひ最後まで読んでね。
今回のやりとりの背景
今回の相談は、あるPower Appsアプリ（キャンバスアプリらしきもの）で、以下のようなコードビューが提示されたことから始まったんだ。SharePointリストのようなデータソースも登場するし、Office365ユーザー コネクタを使ってユーザー検索しようとしているところも特徴的だよ。
Power Appsのコードビュー（一部抜粋）
Screens:
Screen_Main:
Properties:
OnVisible: |-
=UpdateContext({ varX: false });
Set(
varPhase2Link,
"https://apps.powerapps.com/play/e/8e0ae211-cb79-42c6-92ad-asdfgr3/...
);
Children:
- btnSend:
Control: Classic/Button@2.2.0
Properties:
OnSelect: |+
=UpdateContext({
varX: true,
varYYY: CountIf(
galll.AllItems,
IsBlank(CheckA.Selected.Value)
) > 0
});
- galll:
Control: Gallery@2.15.0
...
Children:
- CheckA:
Control: Classic/DropDown@2.3.1
Properties:
Items: =["","OK", "NG"]
Default: =ThisItem.field_3.Value
...
- CheckB: ...
- CheckAMe: ...
- CheckBMe: ...
- Check項目: ...
- 見出し: ...
- Container1:
Control: GroupContainer@1.3.0
...
Children:
- Container2:
Control: GroupContainer@1.3.0
...
Children:
- OK:
Control: Classic/Button@2.2.0
Properties:
OnSelect: |-
=UpdateContext({ varX: false });
Set(tempRecord, LookUp(CheckListCounter, Title="XXXXXX").LastUsedNumber);
Set(
newX,
Patch(
CheckListCounter,
LookUp(CheckListCounter, Title="XXXXXX"),
{ LastUsedNumber: tempRecord + 1 }
).LastUsedNumber
);
ForAll(
galll.AllItems As currentItem,
Patch(
CheckList,
Defaults(CheckList),
{
Title: newX,
field_1: currentItem.見出し,
field_2: currentItem.Check項目,
field_3: { Value: currentItem.CheckA.Selected.Value },
field_4: currentItem.CheckAMe.Text,
field_5: { Value: currentItem.CheckB.Selected.Value },
field_6: currentItem.CheckBMe.Text
}
)
);
...
実際にはさらに長いスクリプトが続いていたけど、ThisItem や ThisRecord といった書き方に注目すると、環境によっては使えたり使えなかったりするんだ。さらに、ユーザーを検索して選択したい場面で、Office365ユーザー.SearchUserV2({searchTerm:…}) を使うときに不安定だったり、AddColumns() 関数がエラーで赤波線になったりという事象が起こっていたわけ。
Office365Usersコネクタやコンボボックス周りで起きたトラブル
検索できる人が限られる問題
まず、Office365Users.SearchUserV2（Office365UsersはOffice 365 Usersの略）を使うときに、英語の名前を最初の2文字だけ入れたらヒットするのに、3文字目を入れたらなぜかヒットしない――という謎の挙動が報告されたんだ。
これは、Microsoft Graph API（Graph APIの略）との連携で、前方一致の仕組みやサーバーのキャッシュ、表示上限などが絡んでいて、どうにも安定しないことがあるといわれているんだ。実際、多くの環境で「2文字まではOKだけど3文字目入れると出ない」といったバグっぽい症状が見られるんだよね。
結局、「前方一致検索」が不安定で、英字と日本語が混ざる場合なんかはとくに苦しい。最も多い対処としては「2文字検索で妥協」とか「SharePointリストにユーザー一覧を用意してFilterする」という回避策が紹介されていたよ。
displayNameを設定したらCityに書き換わる問題
さらに、ComboBoxコントロールのDisplayFields と SearchFields で ["displayName","mail"] と書いても、なぜか画面上では自動的に ["City","mail"] に置き換わってしまう問題があったんだ。
これもPower Appsの“謎バグ”として有名で、displayName を指定すると勝手にCity に書き換えられることがあるんだって。
回避策としては、AddColumns() で別名のフィールドを作るとか、あるいは右側の「詳細設定」タブから ["Mail","DisplayName"] を無理やり入力して確定させる方法があった。実際、「数式バーで入力するとCityに書き換わるけど、詳細設定タブで入力すると確定できる」という話が出ていて、かなりややこしい仕様（またはバグ）なんだ。
AddColumns()を使おうとしたらエラーになる問題
小文字と大文字の混在
Office365Usersから返ってくるフィールドは多くの場合、mail（全部小文字）や displayName（先頭小文字）になってる。でも、コンボボックスのSearchFieldsやDisplayFieldsでは、表示用に ["Mail"] と大文字で書けたりするんだ。
ところが AddColumns() の中で Mail と書くと、実際には存在しないフィールド名として認識されてエラーになる。正解は mail（小文字）なんだけど、人によっては Mail でも動く場面があり、「なぜか動かない」ということが起こりやすい。
とにかく、「コネクタから返る実際のフィールド名は小文字」「DisplayFieldsやSearchFieldsは表示ラベルとしての大文字小文字が混じってるだけ」という違いを知っておかないとエラーの原因になっちゃうんだ。
「ThisRecord」が原因なのかと思いきや……AddColumns自体がエラー？
さらに混乱を深めたのが、ThisRecord を使って AddColumns() で列を追加しようとしても、環境によってはそもそもAddColumns() がエラーになるケースがあったんだ。
通常、AddColumns(データ, "新列", ThisRecord.何か ) のように書くけど、ThisRecord が効かない評価モード1.0の環境だとエラーになるよね。それで「じゃあThisRecordを使わずにやってみよう」としても、なぜかコンボボックスに AddColumns() を直書きするとそれだけでエラーが出る。
ChatGPTによると、「AddColumns自体は通常どの環境でも使えるはず。でも1.0の古い評価モードだと不安定で、特にコンボボックスと外部コネクタを組み合わせるとハマりやすいバグがある」みたいなんだ。
実際、「本当にAddColumnsが全滅する状態」に陥る人もいて、その場合はSet(変数, AddColumns(…)) のように一度変数経由にすると直ることもあれば、まったく直らないこともあるみたい。
クラシック環境・評価モード1.0の闇
設定画面に「今後の機能」や「最近の機能」タブがない
ふつうのキャンバスアプリなら、Power Apps Studioの左メニューに「設定」があって、そこを開くと「今後の機能」や「最近の機能」というタブが見つかったり、「数式バー評価モード（Formula-level error management (FLM)）」を切り替える項目が出てくる。
でも、今回のやりとりでは「そんなタブは一切ない」と言われてしまったんだ。
これは、クラシックデザイナー環境と呼ばれる古い作成体験を使っている場合に起こる現象。あるいは組織の管理ポリシーでモダン機能を無効にしている場合もそう。
なぜ「評価モード」なんて紛らわしい名前なのか
「評価モード1.0」「評価モード2.0」というのは、要するに「数式の解釈エンジンが古いか新しいか」という違いなんだよね。
プログラミング用語として「式を評価する」とか「Evaluation」という言い方をするから、Microsoftは「Formula-level error management」と呼んだみたい。でも現場感覚だと「バージョン1.0と2.0」って言ってくれたほうが分かりやすい。
1.0だと
ThisRecordが使えないAddColumnsが不安定- 「今後の機能」タブも表示されない
などの制限がある。
2.0だと ThisRecordやAs構文が普通に使えるAddColumnsも安定
という違いが大きいんだ。
だけど、古いアプリや環境だと1.0が固定になっていて、設定で変更もできない状況も多々あるんだよ。
「クラシックデザイナー環境」と明示されない理由
これも公式ドキュメントにははっきり書かれていないんだ。
Microsoftが意図的に「クラシックです」「これは古いです」と表示すると、ユーザーに不安を与えかねないから、あくまで「新しい作成体験」「モダンコントロールが使える環境がある」という風に前向きに案内しているだけなんだろうね。
現場では「ThisRecordが使えない」「設定メニューに最近の機能タブがない」などの症状を総合して、「これはクラシック環境だ」と判断している。
ただ、「クラシック」や「モダン」という単語自体は、公式にも「クラシックコントロールとモダンコントロールの比較」みたいな形で出てくるから、そこに関連付けて説明することは可能だよ。
まとめと実践的な回避策
今回のやり取りでは、とにかく「AddColumnsが使えなくてエラーが出る」「ThisRecordが動かない」という問題がメインだったけど、最終的にChatGPTが何度も言っていたアドバイスは次のとおり。
- 「評価モード1.0」ではAddColumnsの動作が不安定なので、基本的に使わないほうがいい。
- コンボボックスに直接AddColumnsを入れると余計に型エラーが起きやすい。
- ユーザー検索なら、できるだけシンプルに
Office365ユーザー.SearchUserV2({searchTerm:…}).valueをItemsに設定して、DisplayFieldsやSearchFieldsも最小限にする。- たとえば、
["mail"]だけを指定すると部分一致で検索できて安定するケースが多い。 displayNameを無理に使おうとするとCityに書き換わるバグに遭遇しがち。
- たとえば、
- どうしても名前や写真URLなどをまとめて表示したいなら、変数にSetしたうえでギャラリーを使って加工表示したほうが安全。
- コンボボックス単体ではやたらとバグりやすい。
- そもそもクラシック環境を脱して、モダンデザイナー（評価モード2.0）で新規アプリを作ったほうがいい。
- 会社全体のPower Platform管理者に相談し、設定を見直すか、新アプリへの移行を検討。
失敗ストーリーを糧にしよう
ここまでいろいろ試したけど、「なんでこんなにエラー連発するの？」って思うほど、Power Appsはバージョンの歴史的な経緯が複雑なんだ。
今回の僕たちのやり取りみたいに、「AddColumnsがエラーを起こすときはクラシック環境や評価モード1.0の可能性が高い」「displayNameがCityに書き換わるバグもある」なんて知識は、公式ドキュメントを漁ってもなかなか載っていない。
だからこそ、実際に失敗した経験やChatGPTとの紆余曲折のQ&Aがとても貴重なんだよ。みんなの参考になればうれしいな。
まとめ
- クラシック環境（評価モード1.0）では、
AddColumnsやThisRecordを使おうとして大変な目に遭いやすい。 - コンボボックスの
DisplayFieldsやSearchFieldsをいじるとき、displayNameを指定するとCityに書き換わる謎挙動が起こりうる。 Office365Usersで前方一致が部分一致っぽくなったり、2文字でヒットするのに3文字目で消えるなどのAPI仕様が安定しない問題もある。- どうしても安定させたいときは「メールアドレス（mail）だけを検索・表示する」「ユーザー情報リストを自前で用意する」などの回避が使われる。
- 最終的には、モダンデザイナー（評価モード2.0）のアプリを新規に作り直したり、評価モードの切り替えができる環境を用意すると、格段に楽になるはず。
コメント