PowerAppsの命名規則は何から直す? 変数と画面名の決め方

Power Appsのアプリが少し大きくなると、Button1 や Label5 が急に読めなくなりますよね。動いているのに、あとから直すときだけつらい。これ、けっこう多い悩みです。

PowerApps 命名規則は、きれい好きのためのルールではなく、保守しやすさを作るための実務ルールです。まずはPDFの考え方に沿って、変数、コントロール、画面名、コレクションから整えるのが近道ですよ。

PowerApps 命名規則は保守しやすさを作る土台

命名規則は、アプリを作る人だけでなく、あとから直す人のためにも効いてきます。このセクションでは、なぜPowerApps 命名規則が必要なのか、どこから気にすればよいのかを整理します。

名前が読めると数式の意味も読める

Power Appsでは、画面、コントロール、変数、コレクションが数式の中で何度も出てきます。ここが Button1 や TextInput3 のままだと、式そのものは短くても意味が追いにくくなります。

たとえば次の2つは、動きとしては同じような式でも、読みやすさがかなり違います。

SubmitForm(Form1)

SubmitForm(frmExpenseRequest)

後者なら、経費申請フォームを送信しているとすぐわかります。名前は単なるラベルではなく、小さな説明文なんですよ。

PDFと現行ガイドラインで共通する考え方

ユーザー提供PDFの「PowerApps キャンバスアプリの コーディング規約とガイドライン」では、画面、コントロール、データソース、変数、コレクションの命名を扱っています。

大事なのは、細かな接頭語を丸暗記することではなく、共通ルールを作って同じパターンで使うことです。

Microsoft LearnのCode readabilityでも、読みやすいコードは理解、保守、デバッグを助けるという考え方が示されています。PDFと現行ガイドラインの方向性はかなり近いです。

共通のルールを作成し、常にそのパターンに従うこと

PowerApps キャンバスアプリの コーディング規約とガイドライン

すべてを厳密にするより参照される名前を優先する

命名規則を始めると、全コントロールを一気に直したくなります。ただ、現場ではそれをやると時間がかかりすぎることもあります。

最初に直すべきなのは、数式で参照される名前です。ボタンの OnSelect、ギャラリーの Items、フォームの Item、変数、コレクションなどですね。

• 参照されるコントロール
• 複数画面で使う変数
• 何度も更新するコレクション
• 画面遷移で使うスクリーン

見た目だけのラベルを全部直すより、壊しやすい場所から整える方が効果が出ます。完璧を狙うより、まず迷子になりやすい名前を減らすのが現実的です。

PowerApps 命名規則の基本はケースと接頭語

命名規則の入口は、キャメルケース、パスカルケース、接頭語の3つです。ここを押さえると、PDFのルールもMicrosoft Learnの説明もかなり読みやすくなります。

キャメルケースとパスカルケースを使い分ける

PDFでは、コントロールと変数にはキャメルケース、データソースにはパスカルケースを使う考え方が紹介されています。ざっくり言うと、先頭を小文字で始めるか、大文字で始めるかの違いです。

コントロールや変数は、btn、gbl、col のような小文字の接頭語から始めます。データソースは外部の名前に合わせることも多いので、先頭大文字で扱うと区別しやすいです。

接頭語は探しやすさのために付ける

接頭語は、見栄えのためではありません。数式バーで候補を絞ったり、名前を見た瞬間に種類を判断したりするための検索キーです。

gblCurrentUser
locIsSaving
colMenuItems
btnSubmitRequest
galExpenseList

gbl と打てばグローバル変数が並び、col と打てばコレクションが見つかります。アプリが大きくなるほど、この候補検索のありがたさが出てきます。

使わない方がいい名前を先に覚える

命名で悩むときは、良い名前を考える前に避ける名前を決めると楽です。特に次のような名前は、あとから読む人に負担をかけます。

短すぎる名前は入力が楽ですが、あとで読み解く時間が増えます。Power Appsはローコードでも、複数人で触るならコードの読みやすさが成果に直結します。

変数とコレクションはスコープがわかる名前にする

変数とコレクションは、PowerApps 命名規則の中でも特に効果が出やすい場所です。スコープと中身が名前からわかるだけで、画面をまたぐ不具合やデバッグの迷いを減らせます。

グローバル変数はgblで始める

グローバル変数は、アプリ全体から参照できる値です。PDFでは、グローバル変数に gbl 接頭語を付ける考え方が紹介されています。

Set(gblCurrentUser, User());
Set(gblThemeColor, ColorValue("#017376"));
Set(gblIsAdmin, true)

gblCurrentUser なら現在のユーザー、gblIsAdmin なら管理者判定だとすぐわかります。画面をまたいで使う値は、gblで始めるとスコープが伝わります。

ただし、何でもグローバル変数にするのはおすすめしません。どこからでも変えられる値は便利ですが、追跡しにくい値にもなります。

コンテキスト変数はlocで始める

コンテキスト変数は、基本的に画面内で使う値です。PDFでは、コンテキスト変数とグローバル変数に同じ名前を使えることが混乱の原因になると説明されています。

だからこそ、コンテキスト変数にはlocを付けます。

UpdateContext({
    locIsSaving: true,
    locSuccessMessage: "保存しました"
})

locIsSaving なら、その画面の保存中フラグだとわかります。同じ IsSaving でも、gblIsSaving と locIsSaving では意味が違いますよね。

コレクションはcolで中身を表す

コレクションは、テーブルのように複数レコードを持つ一時データです。PDFでは、コレクション名に col 接頭語を付け、後ろに内容や用途がわかる名前を付ける考え方が示されています。

ClearCollect(
    colApprovalSteps,
    Filter(ApprovalSteps, RequestId = gblCurrentRequest.ID)
)

colApprovalSteps なら、承認ステップの一覧だと読めます。colData よりも、何の一覧かが具体的です。

コレクションは増えやすいので、最初から中身の名前を入れておくと後が楽です。画面名や機能名を入れるかどうかは、チームの規模に合わせて決めればOKです。

画面とコントロールは役割がわかる名前にする

画面とコントロールは、ツリービューでも数式でも何度も目に入ります。ここでは、PDFで重視されている画面名とコントロール名の考え方を、実務で使いやすい形に整理します。

画面名は読み上げも意識して平易にする

PDFでは、画面名は目的がわかる名前にし、スクリーンリーダーで読み上げられる点も意識するよう説明されています。省略しすぎた名前より、平易な名前の方が安全です。

良い例は、次のような名前です。

Home Screen
Request Detail Screen
Approval List Screen

日本語環境でチームが日本語を主に使うなら、画面名を日本語にする運用もありです。ただし、英語名と日本語名が混ざると統一感がなくなるので、どちらかに寄せるのがおすすめです。

コントロール名は3文字接頭語と目的を組み合わせる

PDFでは、コントロール名に3文字の型記述子を付け、その後に目的を加える考え方が紹介されています。たとえば、ボタンなら btn、ギャラリーなら gal、ラベルなら lbl です。

btnSaveRequest
galExpenseList
lblUserName
txtSearchKeyword
frmExpenseRequest

ポイントは、コントロールの種類だけで終わらせないことです。btnSave より btnSaveRequest の方が、何を保存するのかがわかります。

よく使う接頭語の早見表

すべてを覚える必要はありません。まずはよく使う接頭語だけ、チームで表にしておけば十分です。

この表をチームの標準にしておけば、レビューで「この名前は何？」と聞く回数が減ります。命名規則は暗記ではなく、参照できる表にして使うのがコツです。

既存アプリは命名ルール表を作って少しずつ直す

新規アプリなら最初からルールを入れられますが、困るのは既存アプリです。ここでは、壊さずに少しずつ直す順番と、チームで続けるための運用を整理します。

まず参照されるコントロールから直す

既存アプリを直すときは、全部を一気に変えない方がいいです。優先順位は、数式から参照される名前です。

1. OnSelect や Items で参照されるコントロールを探す
2. 名前の意味が薄いものをリスト化する
3. btn、gal、frm などの接頭語を付ける
4. 変更後に関連する数式を確認する
5. プレビューモードで主要操作を試す

Power Apps Studioは名前変更に追随してくれる場面もありますが、確認なしで進めるのは危険です。検索と動作確認をセットにすると安心ですよ。

チームでは命名表を1枚にまとめる

チーム開発では、細かい説明よりも1枚の表が効きます。NotionでもExcelでもいいので、次のような表を作っておくと運用しやすいです。

ルールを増やしすぎると、今度は守れません。最初は10個以内の接頭語に絞るくらいで十分です。

リネーム前に検索と動作確認を入れる

命名規則の導入で一番避けたいのは、名前を直してアプリを壊すことです。だからリネームは、必ず小さく進めます。

リネーム作業は、次の順番にすると安全です。

Before: Button1.OnSelect = SubmitForm(Form1)

After:
btnSubmitRequest.OnSelect = SubmitForm(frmExpenseRequest)

見た目は同じでも、後者はかなり読みやすいですよね。命名規則は一度で完成させるものではなく、触るたびに少しずつ改善するものです。

PowerApps 命名規則に関するよくある質問

まとめ

PowerApps 命名規則は、アプリをきれいに見せるためではなく、保守性と可読性を上げるための土台です。まずは gbl、loc、col、btn、gal など、数式でよく参照する名前から整えてみてください。

既存アプリでも、1日で全部直す必要はありません。次に触る画面で Button1 を1つだけ意味のある名前に変えるところから始めると、チームの開発体験が少しずつ良くなります。