Power Apps のフォームで、毎回自分の名前や所属部署を手打ちしていませんか。入力の手間だけでなく、タイポによる誤登録も起きます。User() 関数や Office365Users コネクタを使えば、ログインしているユーザーの情報を自動で取得し、初期値として埋め込めます。手入力させない設計が、最も確実な入力ミス防止です。
手打ちをなくすことが最大の入力ミス対策
バリデーションの多くは入力された値が正しいかをチェックする仕組みです。しかし考えてみると、そもそも入力させなければチェック自体が不要になります。物流系の現場でよく見るのが、申請フォームに毎回自分の名前・メールアドレス・社員番号を手打ちするケースです。20人のスタッフが毎日使うアプリなら、1日に20回は不要な入力が発生していることになります。
さらに問題なのは、タイポが誰にでも起きることです。自分の名前のはずなのに1文字ミスが入り、集計でその行だけ弾かれる。そういうトラブルを何度か経験してから、私はユーザー情報を自動取得する設計を標準にしました。
User() 関数で取得できる情報
Power Apps には標準で User() 関数が用意されています。追加のコネクタなしに使えるため、ライセンスの心配もありません。取得できるプロパティは3つです。
| プロパティ | 取得できる値 | 使用例 |
|---|---|---|
| User().FullName | 表示名（例：守屋 祐輔） | 申請者名フィールドの初期値 |
| User().Email | メールアドレス | 通知先・ログ記録 |
| User().Image | プロフィール画像URL | アバター表示 |
テキスト入力コントロールの Default プロパティに User().FullName を設定するだけで、アプリを開いた瞬間に自分の名前が入力された状態になります。さらに DisplayMode プロパティを Disabled に設定すれば、ユーザーが書き換えることもできなくなります。
// TextInput_Name の Default プロパティ
User().FullName
// TextInput_Name の DisplayMode プロパティ
DisplayMode.Disabled
ただし注意点があります。User() 関数で取得できる名前は、Microsoft 365 のアカウントに登録された表示名です。社内で表示名が統一されていない環境（例：英語名と日本語名が混在している）では、期待した値と異なる場合があります。事前にどのプロパティが現場に合っているか確認しておきましょう。
Office365Users コネクタでより詳細な情報を取得する
User() 関数は手軽ですが、取得できる情報が3つに限られています。部署名・役職・社員番号・上長のメールアドレスなど、より詳細な情報が必要な場合は Office365Users コネクタを使います。ただしこれはプレミアムコネクタではなく標準コネクタなので、Power Apps の標準ライセンスで利用できます。
Office365Users コネクタの主要な関数は MyProfileV2() です。ログインユーザーの Azure AD プロファイルにアクセスし、DisplayName・Mail・Department・JobTitle・Id などを取得できます。
// App.Formulas（名前付き計算式）での定義例
currentUser = Office365Users.MyProfileV2();
// フォームで使う場合
TextInput_Dept.DefaultText = currentUser.Department
TextInput_JobTitle.DefaultText = currentUser.JobTitle毎回 Office365Users.MyProfileV2() を直接プロパティに書くと、コントロールが増えるたびに API 呼び出しが増えてパフォーマンスが低下します。名前付き計算式（App.Formulas）を使って一度だけ取得し、結果を参照する設計が推奨です。アプリ全体で1回だけ API を呼び出し、複数のコントロールがその結果を共有できます。
App.Formulas への定義手順
- Power Apps Studio の左上メニューからアプリの設定を開き、App オブジェクトを選択します
- Formulas プロパティに currentUser = Office365Users.MyProfileV2(); を追加します
- 各テキスト入力の Default プロパティで currentUser.DisplayName や currentUser.Department を参照します
ユーザー情報をフィルターに使う応用設計
ユーザー情報の自動取得は、入力ミス防止だけでなくデータの絞り込みにも活用できます。ログインユーザーが自分に関係するデータだけを見られる設計です。申請フォームなら、自分が提出した申請だけがギャラリーに表示される、といった使い方になります。
ギャラリーの Items プロパティに Filter 関数と User().Email を組み合わせれば実現できます。ユーザー情報を使ったフィルター実装の詳細はそちらの記事で解説していますが、基本構文は次のとおりです。
// ギャラリーの Items プロパティ（自分の申請のみ表示）
Filter(RequestList, Applicant = User().Email)この設計はセキュリティの観点からも有効です。他のユーザーのデータが画面に表示されないため、個人情報や機密データを誤って見せてしまうリスクが減ります。Power Apps のコンテナを使ったレイアウト設計と組み合わせると、ギャラリーとフォームを並べた申請管理アプリのUIをすっきり構成できます。
自己割り当て禁止のバリデーションへの応用
Office365Users.MyProfileV2().id を使うと、より高度なバリデーションが作れます。たとえば、承認者フィールドに申請者自身を選べないようにする制御です。
承認ワークフローを Power Apps で実装するとき、申請者が自分自身を承認者に指定できてしまうと内部統制が崩れます。これを防ぐには、ユーザーピッカーで選択した人物の ID とログインユーザーの ID を比較し、一致していたらエラーにする設計が有効です。
// 承認者選択コントロールの ValidationState（モダンフォーム）
If(
And(varFormSubmitted, PeoplePicker_Approver.Selected.Id = Office365Users.MyProfileV2().id),
"Error",
"None"
)
// ValidationMessage
"申請者自身は承認者に指定できません"この応用パターンは、バリデーションがデータの整合性を守るだけでなく、ビジネスルールを強制する手段になることを示しています。フォームのルールを Power Apps 側に組み込むことで、利用者がルールを覚えていなくても自然に正しい操作へ誘導できます。
まとめ：入力させない設計が、最も強いバリデーション
User() 関数と Office365Users コネクタを使えば、ログインユーザーの名前・メール・部署・役職を自動で取得してフォームに埋め込めます。手打ちをゼロにすることで、タイポも二重確認の手間も発生しなくなります。
フォーム設計の全体像を整理したい場合は、フォームコントロールの基本的な仕組みも合わせて読むと、どの場面でどの実装パターンを選ぶかの判断がしやすくなります。市民開発とは、こうした地道な設計の積み重ねです。
入力エラーに関する一覧はこちらの記事をご覧ください。
