PowerApps Asとは? ThisRecordとの違いと使い方

Power AppsでForAllやFilterを書いていると、「このThisRecordはどの行を指しているの？」と迷うことがありますよね。特に入れ子の式になると、読むだけで少ししんどくなります。

PowerApps Asは、現在のレコードに名前を付ける演算子です。ThisRecordを無理に追いかけるより、TaskやProjectのような名前を付けるだけで、式の意味がかなり見えやすくなります。

PowerApps Asはレコードに名前を付ける演算子

まずはAsの正体をはっきりさせます。ここが曖昧なままだと、ThisRecordとの違いや入れ子で使う理由もぼやけます。

Asは「新しい関数」ではなく、レコードスコープに名前を付けるためのPower Fxの演算子として押さえると理解しやすいです。

Asは現在レコードへ名札を付ける

As はより適切かつ具体的な名前を提供するのに役立ち、ネストされたシナリオでは特に重要です。

Microsoft Learn

Asをひと言でいうと、名札を付ける仕組みです。たとえば、ギャラリーのItemsに次のように書くと、各行のレコードをTaskという名前で扱えます。

Tasks As Task

この場合、ギャラリー内のラベルでは次のように書けます。

Task.Title

ThisItem.Titleでも表示できますが、Task.Titleと書くと「これはタスク1件のTitleなんだな」とすぐに読めます。

式が短いときは差が小さくても、行の中にボタン、アイコン、条件式が増えるほど名前のわかりやすさが効いてきます。

ThisItemとThisRecordとの違い

Power Appsでは、どの場所で式を書くかによって、現在レコードの呼び名が変わります。ざっくり整理すると、次のようになります。

ThisItemやThisRecordは便利ですが、名前が抽象的です。ThisRecord.Titleと書かれていても、タスクなのか、プロジェクトなのか、社員なのかは式の前後を見ないとわかりません。

そこでAsを使ってTask.Title、Project.Name、Employee.Emailのように書くと、どのデータの列かが読みやすくなります。これは、自分のためだけでなく、あとから式を見る同僚にもやさしい書き方です。

Asを使える場所

Asは、ギャラリーのItemsや、レコードスコープを持つ関数で使えます。よく出てくるのは次のような場所です。

• GalleryのItemsで、各行のレコードへ名前を付ける
• ForAllで、処理中の1件へ名前を付ける
• FilterやLookUpで、条件式の中のレコードを明確にする
• With、Sum、Concatなどで、今見ているレコードを読みやすくする

たとえば、Filterで書くなら次のような形です。

Filter(Tasks As Task, Task.Status = "未完了")

Statusだけでも動くことはあります。ただ、列名が増えたり、別のテーブルをLookUpしたりすると、参照先の曖昧さが出やすくなります。最初からTask.Statusと書いておくと、式を読む負担がぐっと下がりますよ。

Asを使う基本パターンを式で押さえる

定義だけでは使いどころが見えにくいので、次はよく使う式で見ていきます。Gallery、Filter、ForAll Patchの3つを押さえると、実務で出会うAsのかなりの部分を読めるようになります。

難しく考えず、テーブル名は複数形、レコード名は単数形と見るのがコツです。

GalleryのItemsで行に名前を付ける

一番シンプルなのは、ギャラリーのItemsでAsを使う形です。SharePointリストやDataverseテーブルのTasksを表示するなら、Itemsにこう書けます。

Tasks As Task

ギャラリー内のタイトルラベルは、次のようになります。

Task.Title

期限を表示するなら、こんな形です。

Text(Task.DueDate, "yyyy/mm/dd")

この書き方の良いところは、ギャラリーの中にいる間ずっとTaskが「今の1行」を表すことです。ThisItemよりもデータの意味が残るので、式が長くなっても読み返しやすいです。

FilterやLookUpで列の出どころを明確にする

FilterでもAsは便利です。たとえば、未完了のタスクだけを表示したい場合は、次のように書けます。

Filter(Tasks As Task, Task.Status = "未完了")

さらに、別のテーブルをLookUpする式が入ると、Asのありがたみが増えます。たとえば、タスクの担当者IDと社員テーブルのIDを照合したい場合は、次のように考えます。

AddColumns(
    Tasks As Task,
    "AssigneeName",
    LookUp(Employees As Employee, Employee.ID = Task.AssigneeId).Name
)

この式では、TaskとEmployeeの2つのレコードが出てきます。Asを使わずにIDやNameだけで書くと、どちらのテーブルの列なのか読み取りにくくなります。

特にSharePointやDataverseでは、Title、ID、Nameのような列名が複数のテーブルでかぶりがちです。列の持ち主をはっきりさせるだけで、読み間違いをかなり減らせます。

ForAllとPatchでは更新対象をはっきりさせる

ForAllとPatchを組み合わせるときも、Asを使うと安全に読みやすくなります。選択済みタスクのコレクションcolSelectedTasksを順番に処理して、データソースTasksを更新する例です。

ForAll(
    colSelectedTasks As Task,
    Patch(
        Tasks,
        LookUp(Tasks, ID = Task.ID),
        { Status: "完了" }
    )
)

ここで大事なのは、Task.IDがコレクション側の1件を指している点です。ThisRecord.IDでも短い式なら読めますが、Patch、LookUp、Filterが重なると、どの行かがあやしくなります。

実務では、まずAsで処理中のレコードに名前を付けます。そのうえで、LookUpで更新対象を探し、Patchで変更内容を書きます。この順番にすると、あとから見ても「何を探して、何を更新しているか」が追いやすいですよ。

入れ子の式ではAsが外側のレコードを守ってくれる

Asが一番効くのは、ForAllやGalleryが入れ子になった場面です。内側と外側のレコードを同時に使う式では、ThisRecordだけだと読み手が迷いやすくなります。

外側と内側に別々の名前を付けると、参照先を式の中で明確にできます。

ThisRecordだけだと内側に寄りやすい

ThisItem and ThisRecord are great, but they only make the innermost record available.

Microsoft Power Platform Blog

入れ子の式でつまずく理由は、ThisRecordが「今いる内側のスコープ」を指しやすいからです。

外側のForAllでプロジェクトを見ていて、内側のFilterでタスクを見ているとき、ThisRecordだけではどちらを指すのか追いにくくなります。

Power Appsの式は、短いときはExcelっぽく読めます。でも、入れ子が2段、3段になると、境界を意識しないと急に読みにくくなります。

入れ子のForAllでは外側と内側に別名を付ける

入れ子のForAllでは、外側と内側にそれぞれ名前を付けます。たとえば、3行3列の九九っぽいデータを作るなら、次のように書けます。

Clear(colCells);
ForAll(
    Sequence(3) As Row,
    ForAll(
        Sequence(3) As Col,
        Collect(
            colCells,
            {
                X: Row.Value,
                Y: Col.Value,
                Result: Row.Value * Col.Value
            }
        )
    )
)

この式では、外側がRow、内側がColです。ResultではRow.ValueとCol.Valueの両方を使っています。Asがあるから、外側の値と内側の値を同じ式の中で安全に読めます。

もし全部をThisRecordで書こうとすると、内側のThisRecordに飲まれて、外側の値をどう読むかで悩みやすくなります。外側と内側に名前を付けるのが、入れ子式を読みやすくする近道です。

親子ギャラリーでは親レコードをそのまま読める

親子ギャラリーでもAsは役立ちます。たとえば、外側のギャラリーでプロジェクトを並べ、内側のギャラリーでそのプロジェクトに紐づくタスクを表示するケースです。

外側ギャラリーのItemsは、次のようにします。

Projects As Project

内側ギャラリーのItemsでは、外側のProject.IDを使ってタスクを絞ります。

Filter(Tasks As Task, Task.ProjectId = Project.ID)

内側ギャラリーのラベルでは、子レコードのタイトルと親レコード名を一緒に表示できます。

Project.Name & " / " & Task.Title

このように、親をProject、子をTaskと名付けると、構造がそのまま式に出ます。入れ子ギャラリーでParent.ThisItemのような書き方に迷う前に、Asで親子それぞれに名前を付けるとスッキリします。

Asで読みやすい式にするコツ

Asは便利ですが、名前を雑に付けると逆に読みにくくなります。aやxのような短すぎる名前を増やすと、ThisRecordと同じくらい意味が見えません。ここでは、実務であとから直しやすい式にするための名前付けと使い分けを整理します。

名前はデータの単数形にする

Asで付ける名前は、データソース名の単数形にすると読みやすいです。たとえば、次のような対応です。

Tasks As Taskと書くと、複数件のTasksから1件ずつTaskとして扱っていることが自然に伝わります。日本語名のデータソースなら、申請一覧 As 申請のように書くこともできます。

ただし、チーム運用なら英語名に寄せたほうが、Power Fxの関数や列名と混ざっても読みやすい場合があります。大事なのは、1件のレコードだとわかる名前にすることです。

Withや変数とは役割が違う

As、With、変数はどれも式を読みやすくできますが、役割は違います。混ぜると迷いやすいので、次のように分けると整理しやすいです。

Asは、レコードを保持するためのものではありません。今その関数やギャラリーが見ている1件に、わかりやすい名前を付けるだけです。

一方で、画面をまたいで選択行を使いたいなら、Set(varTask, ThisItem)のように変数へ保存します。同じ「名前を付ける」でも、スコープと値の保持は別物なんですよ。

委任や性能が改善するわけではない

Asを使うと式が読みやすくなります。ただし、Asを入れたからといって、委任警告や性能問題が自動で解消するわけではありません。

委任は、使っている関数や演算子、データソースがその処理に対応しているかで決まります。たとえば、Filterの条件に非委任の関数を使っているなら、Asで名前を付けても警告は残ります。

Asを使う目的は、まず式を正しく読みやすくすることです。そのうえで、大量データを扱う場合は、FilterやLookUpの委任可否、SharePointやDataverseの列型、データ件数を別で確認しましょう。

実務では、次の順番で見ると切り分けやすいです。

1. Asでレコードの参照先が明確かを見る
2. FilterやLookUpの条件が正しいかを見る
3. 委任警告が出ていないかを見る
4. データソース側の列型やインデックスを確認する

Asは最初の読みやすさに効きます。委任や速度は、別の観点としてチェックするのが安全です。

よくあるエラーは参照先の曖昧さから見る

最後に、Asまわりでよくあるつまずきを確認します。エラー文だけを見ると遠回りしがちですが、まず「どのレコードの列か」が曖昧になっていないかを見るのが近道です。Asを入れると、参照先の整理がしやすくなります。

同じ列名がある式ではAsで列の持ち主を示す

SharePointやDataverseでは、複数のテーブルにID、Title、Nameのような列があることが多いです。こういう式で列名だけを書くと、Power Apps側も人間側も迷いやすくなります。

たとえば、タスクとプロジェクトのTitleを比較する式なら、Asで持ち主を示します。

Filter(
    Tasks As Task,
    Task.ProjectTitle = LookUp(Projects As Project, Project.ID = Task.ProjectId).Title
)

この例では、Task.ProjectIdはタスク側、Project.IDはプロジェクト側です。同じIDという列名が出ても、どちらのテーブルの列かが見えます。

日本語ブログでも、同名列がある入れ子式でAsを使うと、取得エラーを避けやすい例が紹介されています。エラー文だけで悩むより、まず列の持ち主を明示するほうが早い場面があります。

名前が見つからないときはスコープを確認する

Asで付けた名前は、どこからでも使えるわけではありません。そのGalleryや関数のスコープ内だけで使えます。

たとえば、内側ギャラリーでProject.Nameを使えるのは、外側ギャラリーのItemsでProjects As Projectと名前を付けていて、内側ギャラリーがその中に置かれているからです。

まったく別の画面や別のギャラリーでは、Projectという名前は存在しません。

スコープ外で同じレコードを使いたいなら、Asではなく変数に保存します。たとえば、ギャラリー内のボタンで次のように書きます。

Set(varProject, Project);
Navigate(scrProjectDetail)

詳細画面ではvarProjectを使います。Asはスコープ内、変数は画面またぎの用途、と分けると迷いにくいです。

ThisRecordとAsを混ぜすぎない

単純な式ならThisRecordで十分です。たとえば、短いFilterなら次のように書いても意味は伝わります。

Filter(Tasks, ThisRecord.Status = "未完了")

ただ、同じ式の中でThisRecord、Task、Projectが混ざると、かえって読みにくくなります。入れ子や同名列がある式では、Asに寄せると読みやすいです。

チェックするときは、次の順番で見ると整理できます。

• ThisRecordが複数の意味で読めないか
• 外側レコードと内側レコードの両方を使っていないか
• 同じ列名を持つテーブルを比較していないか
• Asで付けた名前がスコープ外で使われていないか

式が長くなってきたら、ThisRecordを増やすより、レコード名を付けましょう。それだけで、後日の自分がかなり助かります。

PowerApps Asに関するよくある質問

まとめ

PowerApps Asは、現在レコードへ名前を付けて、ThisItemやThisRecordの曖昧さを減らす演算子です。特に入れ子のForAll、親子ギャラリー、同名列を扱う式では、参照先を明確にする効果が大きいです。

まずは既存アプリのForAllやGallery Itemsを1つ選び、ThisRecordをAsで名前付きにすると読みやすくなるか試してみてください。