市民開発.com

Power Apps開発の全体マップ。基礎・データ操作・関数・UI設計の完全ガイド

Mon, 16 Mar 2026 15:46:51 GMT

Power Appsでアプリを作れるようになりたいなら、まず開発全体の地図を持つことが最初の一手です。何をどの順番で覚えるかを把握しているかどうかで、上達スピードが大きく変わります。

Power Apps習得の全体マップ

Power Appsでアプリを開発するには、大きく分けて4つの領域があります。

領域	主な内容	優先度
①基礎	データソースへの接続・画面遷移	★★★
②データ操作	読み込み・書き込み・削除（CRUD）	★★★
③関数・ロジック	変数・条件分岐・検索関数	★★☆
④UI設計	ギャラリー・フォーム・見た目	★★☆

この4つを軸に習得を進めるのが、現場で使えるアプリを最短で作るルートです。慣れてきたら⑤パフォーマンス管理と⑥Power Automate連携も加わります。

どこから手をつければいいかわからない方は、アプリ開発の一連の流れで全体像を先に確認しておくといいでしょう。初心者の方はPower Appsとは？完全ガイドもあわせてどうぞ。

①基礎：アプリの骨格を作る

アプリ開発の入口として最初に習得すべきなのは、データソースへの接続と画面遷移の2つです。この2つが分かれば、最低限動くアプリは作れます。

データソースは何を使うか

Power Appsはさまざまなデータソースと繋がれますが、市民開発の入口としてもっともおすすめなのはSharePointリスト（Microsoft Lists）です。Excelをデータソースにしたいと思う方も多いでしょうが、Excelには件数の上限や委任問題があり、業務利用では早々に限界が来ることも少なくありません。

SharePointリストとExcelをどう使い分けるかは、データソースの選び方やSharePointリストとMicrosoft Listsの関係で詳しく解説しています。

画面遷移の設計

複数の画面を持つアプリを作るには、Navigate関数を使います。画面同士の移動を管理することが、マルチスクリーンアプリの基本設計です。Navigate関数の詳しい使い方は別記事で解説しています。

②データ操作：読み書き削除の基本（CRUD）

アプリの核心は、データの読み書き・削除——いわゆるCRUDです。CRUDとはCreate（作成）・Read（読み込み）・Update（更新）・Delete（削除）の頭文字で、ほぼすべての業務アプリがこの4種類の操作を必要とします。

データの読み込みと絞り込み

SharePointリストからデータを読み込むには、ギャラリーコントロールにデータソースを接続します。そこにFilter関数・Search関数・LookUp関数を組み合わせて、必要な行だけを表示します。3つの関数の使い分けはFilter・Search・LookUp関数の使い分けガイドで整理しました。

データの書き込みと削除

データの追加・更新にはPatch関数かフォームコントロールを使います。Patch関数はコードで直接書く方法で自由度が高い反面、書き方を覚える必要があります。フォームコントロールはコードがほぼ不要で手軽に実装できますが、カスタマイズには限界があります。SharePointリストのCRUDをまとめて学びたい方は別記事で詳しく解説する予定です。Patch関数の詳しい使い方はPower AppsのPatch関数の使い方でも解説しています。

③関数・ロジック：数式で動きを作る

Power Appsの数式はExcelに近い感覚で書けます。ただし、Excelとは異なる独自ルールもあり、最初は戸惑うこともあるでしょう。私もその一人でした。ここでは特に重要な3つの領域を紹介します。

変数と初期化処理

Power Appsには変数が2種類あります。グローバル変数（Set関数で設定）とコンテキスト変数（UpdateContext関数で設定）です。どちらをどんな場面で使うかはグローバル変数とコンテキスト変数の使い分けで図解しています。

初期化処理をOnStartに書くか、OnVisibleに書くかも迷いどころのひとつです。OnStartとOnVisibleの使い分けについては別記事で整理する予定です。

条件分岐

条件によって動きを変えたいときはIf関数かSwitch関数を使います。複数の条件を並べるとき、IfよりもSwitchの方がすっきり書ける場面があります。IfとSwitchの使い分けについては別記事で詳しく解説します。

データを絞り込む3つの関数

ギャラリーに表示するデータを絞り込むFilter・Search・LookUpは、Power Appsでもっともよく使う関数です。使い分けがわかるようになると、アプリ開発の幅が一気に広がります。Filter・Search・LookUp関数の使い分けガイドで詳しくまとめています。

④UI設計：使いやすさに投資する

機能が動いても、使いにくければ誰も使わないアプリになります。これは現場でよく起きることです。UI設計の考え方の全体像はPower Appsは見た目と使いやすさにこだわって開発すべしでまとめています。

ギャラリーコントロール

データを一覧表示するためのコントロールです。ギャラリーのSelectedプロパティと画面遷移を組み合わせることで、一覧→詳細表示という基本的な流れが作れます。ギャラリーの基本と検索連携の実装については別記事で解説する予定です。

フォームコントロール

EditForm・NewForm・DisplayFormの3種類があり、データの編集・追加・閲覧に対応しています。フォームコントロールを使えばPatch関数を書かなくてもデータの更新ができます。設定のポイントはフォームコントロールの解説記事で別途まとめる予定です。

小ネタやUI改善のテクニック集としてはPower Appsで使える実用テクニックもおすすめです。

⑤パフォーマンス：重くなる前に知っておくこと

アプリが大きくなってくると、表示が遅くなったり、データが全件取得できなくなる問題が出てきます。特に注意が必要なのが委任（デリゲーション）という概念です。

委任とは、Power Appsがデータ処理をデータソース側に依頼する仕組みのことです。委任できないフィルターを使うと、データが最大2,000件までしか扱えなくなります。たとえば20人が使うアプリで1日20件の登録があれば、5ヶ月で2,000件に達します。設計の早い段階で委任を意識しておきましょう。委任の詳細はPower Appsの委任の警告とは？を参照してください。

パフォーマンス改善の具体策は別記事でまとめる予定です。

⑥Power Automateとつないで自動化する

メール送信・承認フロー・Teams通知など、Power Apps単体では難しい自動化はPower Automateが担います。ボタンを押したときにフローを呼び出し、処理結果をアプリに返す——これがPower Apps×Power Automateの基本パターンです。

連携の実装方法はPower AppsとPower Automateの連携記事で別途解説する予定です。Power Platformで業務改善を進めるイメージ全体はPower Platformで始めるシンプルな業務改善もあわせて読んでみてください。

まとめ

Power Apps開発の全体像を6つの領域で整理しました。

全部を一気に覚えようとする必要はありません。①②で動くアプリを1本作り、③④で磨き込む——この繰り返しがいちばん確実な上達ルートです。この記事を地図として、自分のペースでPower Apps習得を進めていきましょう。

Power Appsでアプリ開発する一連の流れを紹介

Tue, 13 Feb 2024 21:37:10 GMT

Power Appsでのアプリ開発は、流れを把握してから着手すると驚くほどスムーズに進みます。要件定義から本公開・メンテナンスまで、市民開発者の視点で一連のプロセスを整理しました。

一般的なシステム開発経験者の視点では抜け・漏れがあるかもしれませんが、あくまでも市民開発者目線の記事として参考にしてください。

要件定義
環境構築
設計
開発
プロトタイプの公開
本公開
メンテナンス

開発の流れは料理でかんがえるとわかりやすい

難しく考える必要はありません。料理をするときの流れを想像してみましょう。

ご飯を作るときも、何を作るか決めて、材料を揃えて、手順通りに調理する。アプリ開発も、まったく同じ考え方で進めることができます。

開発	詳細	料理
要件定義	なにを作るか？	ご飯何にしよう？
環境構築	ツールを考える	材料や調理器具の準備
設計	仕様や動作	玉ねぎはどう切る？お米は何合？
開発	実際の開発	材料を切る、炒める
プロトタイプの公開	試作品の公開	味見
本公開	完成	完成
メンテナンス	保守・メンテナンス	後片付け

1. 要件定義

要件定義は、アプリ開発でもっとも重要なフェーズです。何を作るか、誰のために作るか、どんな機能が必要かを言語化することで、開発の方向性が定まります。

Power Appsで作るアプリには、大きく2種類あります。依頼を受けて作るアプリと、自発的に作るアプリです。

依頼を受けて作るアプリは、誰かから困っていることを聞いてニーズを把握したうえで作るものです。他人の依頼を形にするわけなので、要件定義が大切というのは理解できるでしょう。

自発的に作るアプリは、自らが業務改善をするために作るアプリです。現場の仕事を理解している分、業務改善・DX化が進みやすいメリットがあります。ただし、ついつい要件定義を省略して好き勝手に作ってしまいがちです。私がそうでした。ちゃんとした運用を考えるのであれば、やはり要件定義は必要です。

自分の思考を見える化することで整理ができますし、他人が見ても共通のゴールと道筋が見えるのが大切なのです。

要件定義の一例

アプリの一例を出して、要件定義を作ってみました。

定義項目	詳細
いま困っていることは何か	テレワークが増え、部内で誰がテレワークなのか出社なのか把握しづらい
アプリでそれをどう解決するのか	ひと目で全員のテレワークと出社を見ることができる
アプリを使うユーザーは誰か	自分の部署と関係部署、合わせて3部署
必須機能は何か	Outlookスケジューラーの予定を抽出する機能。テレワークと出社を判別し、わかりやすく表示する機能。
あったら便利な機能は何か	1週間ほど先まで予定が見える機能。部署ごとにわけて表示する機能。出社人数がわかる棒グラフ機能。

このような感じです。ExcelやSpreadsheetにまとめておき、進捗に合わせて色付けするなどして管理しやすくしておきましょう。

ちなみにこのアプリは、実際に私が作った自発的なアプリの一例です。作った当時は市民開発の初心者だったので、きちんと要件定義も作らずに制作していました。

判断できる力が必要

必須機能として挙げた項目が、本当に実装可能かどうか判断できる力が必要です。Power Appsでできることとできないことを要件定義の段階で明確にする必要があり、市民開発者はその判断を求められます。

実装できないものは3つのレベルにわけて考えると整理しやすいです。

それが実装可能かどうか知らないので実装できない
実装できることは知っているが、経験値が自分にないので実装できない
Power Appsの仕様上、実装できない

初心者の市民開発者は、まず1が該当するでしょう。Power Appsに詳しい人に尋ねたり、ネットや書籍で調べる必要があります。2のケースは、時間をかければ自力で解決できるかもしれません。3の判断がつくのであれば、非常にラクですね。どのレベルに当てはまるかを把握できれば、このアプリはほぼ成功したも同然です。

この業務は何のためにやっているのか、やり方を変えられるか、業務を無くせないか――こういう考え方が重要です。

2. 環境構築

環境構築とは、Power Appsを使うか、Power Platformを組み合わせて使うか、データベースは何にするかを決めることです。

Power Platformには、外部サービス連携のためのコネクタが1,000種類以上用意されています。ただし、企業によっては業務に関係ないSNSや海外サービスのコネクタに使用制限がかかっていることが多いです。自社で使用できるコネクタと制限を把握したうえで、どのツールを使うかを考える必要があります。

Power Appsは万能ツールではないため、機能上限があります。Power Automateも会社のライセンス次第で1日の使用に制限がかけられています。まずは制約をきちんと把握することが大切です。

データベースの種類も考える必要があります。Excelにすると一部機能が制限されることがあります。SharePoint Listsにすると委任問題や5,000件問題があります。Dataverseにするとほぼ万能ですが追加料金がかかります。それぞれの特徴はPower Appsのデータベース選びの記事で詳しく解説していますので、あわせて参考にしてください。

3. 設計

設計では、アプリで扱うテーブルを計画します。エンティティ、属性、リレーションシップなどを定義し、データの整合性とアクセス効率を最適化するためのスキーマを設計します。この設計が、後のアプリのパフォーマンスと拡張性に大きく影響します。

私がまだ市民開発の初心者だったころ、データベースはアプリに1つあれば十分じゃないかと考えていました。アプリから入力して保存する、それをアプリで表示する、アプリ作りなんて楽勝だと思っていました。

でもアプリを使う人が増えたり、凝った内容にしようとすると、これユーザー情報をまとめた一覧表が別で必要じゃないか、とか、選択肢の名称が変更になったら全部の記録を手動で修正するのは現実的に無理じゃないか、と行き詰まることに気づいてきたのです。Dataverseを使ったアプリ作成に乗り出してからは、特にこのデータベース設計が重要な意味を持つことを実感しています。

逆にいえば、ExcelやListsを使ったシンプル構造のアプリは、そこまでデータベース設計にこだわる必要はないかもしれません。ただ考え方のクセはつけておいたほうがいいです。

データベース設計の基本

データベース設計は簡単にいうと、データベースにどんな列を持たせる必要があるかを考え、正規化し、その関係性を明確にすることです。

例えば、社員のデータベースを作るなら、名前・部署・入社年月・出身地などの列を作って管理するでしょう。

そのデータベースで何を管理したいかに合わせて列を設けます。こうして出来上がったものをテーブルと呼びます。

正規化とは、テーブルの余計な列を無くし（冗長性の排除）、データの整合性を保つための最小単位のかたまりにすることです。このような名簿テーブルがあるとします。

一見するとこのままデータベースとして使えそうですが、先々のメンテナンスを考えてみましょう。例えば社内の部署名変更があり、営業部が営業統括部に変更するとします。すると先程の名簿はこのように修正が必要です。

全データを一括で修正するのは手間がかかりますし、修正ミスのリスクも高い。ではこれをどうするべきかというと、部署名に固有IDを持たせて2つのテーブルで管理します。

すると、部署名を変更するときも部署テーブルを1箇所変更するだけで済み、間違うリスクを減らすことができます。

Power Appsのデータソースには、この2つのテーブルを連携します。あとはギャラリーコントロールなどで参照が可能になりますね。このような作業を正規化といいます。

非エンジニアの私は、このデータベース設計のことを知らないままPower Appsに触れていました。ところがアプリを作っていくうち、テーブルをわけて別々にデータを管理しないと、作業が複雑すぎて対応できなくなると気づいたのです。結果的にデータベース設計の大切さを知ることになり、初心者向けデータ設計の書籍を数冊読み込んで勉強しました。

要件定義とデータベース設計は一朝一夕ではならず

要件定義とデータベース設計は、理屈を知ったからといって最初から完璧なものができるわけではありません。アプリを作るうち、やっぱりあの機能があったほうがいいとか後で思いつくことはザラにありますし、必要なデータベースを忘れていて後から追加することもあります。

これらは経験を重ねて慣れていくしかないと思っています。学べば学ぶほど、必要な機能やデータ構成がわかるようになってきます。一朝一夕ではいかないものです。

4. 開発

開発段階では、要件定義で特定した核となる機能に焦点を当て、アプリの基礎を構築します。必須要求を満たし、核となるプロセスが正しく機能することを確認するフェーズです。

先ほどの要件定義の例でいえば、ひと目で全員のテレワーク・出社状況を把握できるギャラリー画面を作ること、個人がステータスを入力する画面を作ること、これが最初の開発目標になります。

定義項目	詳細
いま困っていることは何か	テレワークが増え、部内で誰がテレワークなのか出社なのか把握しづらい
アプリでそれをどう解決するのか	ひと目で全員のテレワークと出社を見ることができる
アプリを使うユーザーは誰か	自分の部署と関係部署、合わせて3部署
必須機能は何か	Outlookスケジューラーの予定を抽出する機能。テレワークと出社を判別し、わかりやすく表示する機能。
あったら便利な機能は何か	1週間ほど先まで予定が見える機能。部署ごとにわけて表示する機能。出社人数がわかる棒グラフ機能。

開発が進むにつれ画面が増えてきます。複数画面のアプリ設計については、Navigate関数を使った画面遷移の記事で詳しく解説していますので、あわせて参考にしてください。

完璧を求めすぎず、まず動くものを作ることが重要です。細かい調整や追加機能は、プロトタイプ公開後のフィードバックをもとに対応していけば十分です。

5. プロトタイプの公開

プロトタイプの公開では、初期バージョンのアプリを限定的なユーザーグループにリリースし、実際の操作を通じたフィードバックを収集します。この段階で得られる意見や提案は、アプリの改善と最終的な品質向上に不可欠です。

最低限のUIを作り、テストユーザーに公開してアプリを使ってもらいましょう。自分一人では見落としていた挙動を指摘してもらったり、使い勝手向上のためのヒアリングを進めます。

Power AppsはURLを通じてアクセスしますので、改修したアプリはすぐに使ってもらうことが可能です。Teamsを使って専用チームを作成し、気づいたことをどんどん投げてもらうといいですね。

6. 本公開

本公開の段階では、アプリを関係者全員にリリースし、実運用を開始します。ここまでくれば一通りの開発フェーズが終了です。場合によっては、付属機能の実装と本公開はオーバーラップしてもいいですね。

7. メンテナンス

メンテナンスフェーズでは、アプリの運用を継続的に監視し、バグ修正やパフォーマンスの最適化を行います。また、ユーザーからのフィードバックに基づいて機能の追加や改善を続けていきます。

アプリは公開して終わりではありません。使われながら育てていくものです。定期的に見直す習慣をつけておきましょう。

まとめ

アプリ開発の一連の流れをまとめます。

要件定義
環境構築
設計
開発
プロトタイプの公開
本公開
メンテナンス

要件定義は、アプリ開発における肝になるフェーズです。開発・プロトタイプの公開は、ひたすら手を動かすフェーズ。本公開・メンテナンスはアフターフォローのフェーズです。

アプリの規模にもよりますが、最も時間がかかるのは手を動かして作るフェーズですね。1つ機能をつけたらできるだけ早くプロトタイプとして公開し、フィードバックを得るといいでしょう。

Power Apps全体の学習ロードマップや各機能の位置づけについては、Power Apps開発の全体マップ記事でまとめて解説しています。あわせて参考にしてください。

今回紹介した流れは、アプリを作れば作るほど自然と身についてきます。楽しみながら手を動かして、1つでも多く経験を積んでいきましょう。

Power Appsを社外の人と外部共有して使う方法

Sat, 10 Aug 2024 13:03:36 GMT

Power Apps で開発したアプリは、社外の人と外部共有し、共同で利用することができます。

ただし、社内利用時と同じような自由度で利用してもらうのはハードルが高く、シンプルな利用に限ります。

外部共有における注意点を押さえておきましょう。

アプリを社外共有するための3つの条件

自社開発アプリを社外の人が使うためには、次の3つの条件すべてをクリアする必要があります。

1. Power Apps を利用できるライセンス契約をしていること

まず、アプリを開発するあなたと、そのアプリを利用したい社外の人お互いが Power Appsを利用できるライセンスを契約している必要があります。

昨今のライセンスを見る限り、Microsoftと契約のある企業であれば基本的に最初から利用可能になっていることがほとんどだと思います。

2024年6月現在、最新のライセンス一覧はこちらです。

Microsoftライセンス一覧より抜粋

相手先企業の人が Power Apps ライセンスを所有しているかどうか、先方のシステム担当者に確認してもらうか、またはPower Appsのサイトにアクセスできるかどうかを確認してもらえばいいですね。

お互いがライセンスを持っていなければいけないということは、不特定多数の人が利用することを想定したアプリ開発は不可能であることを意味します。

具体的には、ECサイトなどで顧客に必要情報を入力してもらうためのアプリとしてPower Appsは不向きということになります。

なぜなら、基本的に Power Appsはビジネス利用が前提となっていて、個人契約の Microsoft 365 Personal や Familyプランは Power Apps のライセンスを含んでいないからです。

それらの人が利用するためには、追加オプションで別途 Power Apps ライセンスを契約する必要があり、よほど興味関心のある人でない限り、個人でこれらを契約する人は少ないと考えられます。

2. 外部共有を設定したSharePointサイトにデータソースを配置すること

SharePointサイトを外部共有可に設定し、そこに外部利用したい人のメールアドレスを設定します。

その上でSharePointリストなどデータソースを配置することで、アプリからの利用が可能になります。

[M365管理センター]-[SharePoint管理センター]-[アクティブなサイト]-[任意のサイト]-[設定]-[ファイルの外部共有]から変更できます。

セキュリティのことを考えると[新規および既存のゲスト]にしておくといいでしょう。

外部ユーザーがアクセスのたびに認証が必要となりますし、ドメインでアクセス制限ができたり、アクセス可能日数を30日〜730日の間で設定することも可能です。

サイトを共有した相手には、サイトリンクを通知するこのようなメールが自動送信される

3. 作ったアプリの共有先に外部ユーザーを追加する

共有したいアプリの共有先に、2で追加した外部ユーザーのメールアドレスを設定します。

2で外部メンバーを追加していないとアプリの共有先候補に一覧が表示されませんので注意しましょう。

あとはアプリのリンクは外部ユーザーに連絡すれば、そのURLからアクセスできるようになります。

Power Apps外部共有のデメリット

苦労して Power Apps の外部利用が可能になっても、デメリットや使い勝手の悪い点があります。

コネクタの利用はかなり制限される

コネクタとは、例えばPower Apps内で使うTeamsコネクタ、Outlookコネクタ、OneDriveコネクタなどのこと。

これらはいわゆる標準コネクタと呼ばれるものですが、コネクタごとに外部共有の設定が必要で、管理が相当煩雑になります。

そのため、外部利用したいアプリはコネクタを使わないシンプルな構造にすることを求められます。

認証が面倒くさい

サイトの外部共有設定で[新規および既存のゲスト]を選択すると、外部ユーザーがアプリにアクセスするたびに認証を求められます。

月1回アクセスする程度ならまだ許容できますが、頻繁にアクセスするとユーザビリティが低下します。

[すべてのユーザ]をアクセス可にすれば認証問題は無くなりますが、セキュリティ性が大幅に低下しますので、推奨されません。

データは誰でも編集可能になってしまう

SharePointサイトにデータソースを保存する以上、サイト内部のすべてのアイテムに対してメンバーは編集権限を持ちます。

ここでの説明の通り、外部ユーザーをサイトに追加した段階でサイトアドレスが通知されますので、データの保存場所は相手に筒抜けです。

そのため、ユーザーによって改変される恐れがあることを許容した上でアプリを設計する必要があるのです。

情報管理レベルに応じて、例えば自社とA社だけが使う外部サイト、自社とB社、C社、D社が使う外部サイトのように分けて管理する必要もありますね。

【情報収集に最適】Forms を活用した外部との連携

凝ったアプリが必要なければ、わざわざPower Appsを使わず、Formsで事足りるかもしれません。

Formsはアンケートをお手軽に作れるツールですが、[すべてのユーザーが回答可能]にすることで、社外から簡単に情報収集が可能です。

Formsの回答をトリガーとしてPower Automateと連携させれば、Dataverseやリストへの格納も可能ですね。

まとめ

Power Appsを社外の人が使うためには、[必要なライセンス]・[サイト（リスト）のアクセス権を付与する]・[アプリを共有する]が必要。
社内で使うような自由さはなく、外部ユーザーが手間に感じる恐れあり
Formsで事足りるならFormsのほうが簡単

Power Appsは基本的に社内ユースが前提のツールですが、上記のことを踏まえれば外部共有が可能になります。

Dataverseのテーブルから30秒でアプリを自動生成する方法

Wed, 25 Mar 2026 17:30:33 GMT

Dataverseのテーブルを作ったら、まず自動生成でアプリを動かしてみましょう。テーブルを選んでボタンを押すだけで、ギャラリー（一覧画面）＋フォーム（入力・編集・詳細表示）がセットになった、実際に動くアプリが30秒〜1分で完成します。

私がDataverseを使い始めたとき、「テーブルを作ったあと何をすればいいか」がしばらくわかりませんでした。自動生成機能を知ってからは、テーブルを作るたびにまず自動生成でアプリを動かして、テーブル設計の確認ツールとして使うようになりました。この段階で設計ミスを発見しておくと、後の修正コストが大幅に下がります。

自動生成アプリの作り方

手順はとてもシンプルです。慣れれば1〜2分で完了します。

make.powerapps.com を開き、左上の「ホーム」をクリックします
画面中央の「データから開始」セクションにある「既存のテーブルから開始」をクリックします
テーブルの一覧が表示されるので、アプリを作りたいテーブルにチェックを入れます
右下の「アプリの作成」ボタンをクリックします
30秒〜1分ほど待つと、Power Appsのエディタが開いてアプリが表示されます

「既存のテーブルから開始」が見つからない場合は、「テーブル」一覧からテーブルを選び、上部メニューの「このデータを使用してアプリを作成する」からも同じ操作ができます。どちらの方法でも同じアプリが生成されます。

生成されるアプリの構成

自動生成されるアプリは、SharePointリストからアプリを作ったときと同じ3画面構成です。

BrowseScreen（一覧画面）：テーブルのレコードをギャラリーで一覧表示します。上部に検索バーと並び替えボタンが自動で設置されており、右上の「＋」ボタンで新規レコードの追加もできます
DetailScreen（詳細画面）：ギャラリーでタップしたレコードの詳細を表示します。DisplayFormを使って全列の値を表示する画面です
EditScreen（編集・新規画面）：レコードの新規追加と編集を行う画面です。EditFormを使って各列の入力フィールドが自動で配置されます

この3画面でCRUD（作成・読み取り・更新・削除）がすべて動作します。ギャラリーからレコードを選んで詳細を見て、編集・削除もできる一通りの機能が最初から揃っています。

ギャラリーの仕組みの詳細はPower Appsのギャラリーコントロールで、フォームの構造についてはPower AppsのEditForm・NewForm・DisplayFormでそれぞれ解説しています。自動生成アプリをカスタマイズするときの参考にしてください。

自動生成アプリの3つの活用シーン

1. そのまま業務アプリとして使う

単純なデータ入力・一覧表示・編集・削除が目的であれば、自動生成のアプリをほぼそのまま使えます。フォームの列の並び順を整えたり、ギャラリーに表示する列を調整したりする程度の修正だけで、実用的なアプリになります。

SharePointリストのデータ管理に使っていたアプリと同じ感覚で使えるため、Dataverse移行後の初期段階でもスムーズに運用できます。リストとの使い勝手の比較についてはSharePointと違うDataverseのテーブル作成フローも参考になります。

2. カスタマイズのベースとして使う

複雑な機能を持つアプリを作る場合でも、まず自動生成で土台を作り、そこにカスタマイズを重ねていく方法が効率的です。ギャラリーとフォームの接続設定がすでに完了した状態から始められるため、ゼロからスクリーンを構築するより大幅に時間を節約できます。

たとえばギャラリーに条件付き書式を追加する、フォームに独自のバリデーションを設定する、承認ボタンを追加するといったカスタマイズも、自動生成の土台があればスムーズに進みます。

3. テーブル設計の確認ツールとして使う

これが私が最もよく使うシーンです。テーブルを作ったあと、自動生成でアプリを動かしてみると設計ミスに気づきやすいです。

確認できる主なポイントは以下の通りです。

ルックアップ列のドロップダウンに意図した値（primary column）が表示されているか
choice列の選択肢が正しい内容で並んでいるか
必須設定にした列が正しく「必須」になっているか
フォームの列の並び順がユーザーにとってわかりやすいか
日付・時刻・数値など各列の入力フィールドが適切なタイプで表示されているか

設計のミスはデータを入れ始める前に発見するほうが、修正コストが圧倒的に低くなります。自動生成アプリは数分あれば動く状態になるため、「テーブルを作ったらまず動かして確認する」という習慣をつけると、後のやり直しを大きく減らせます。

自動生成アプリの注意点と限界

便利な反面、自動生成のままでは対応できない場面もあります。事前に把握しておきましょう。

列の表示順はそのまま反映されます。テーブルで定義している列の順番がそのままフォームに出るため、ユーザーが使いやすい入力順に並び替えるには、Power Appsエディタでフォームの列の順序を手動で変更する必要があります。

ルックアップ列の表示はprimary columnのみです。自動生成のComboBoxは参照先テーブルのprimary columnしか表示できません。「氏名と部署名を組み合わせて表示したい」といった要件がある場合は、ComboBoxのItemsプロパティやDisplayFieldプロパティをカスタマイズする必要があります。ルックアップ列の詳細はDataverseのルックアップ列でテーブルをリレーションさせるをご覧ください。

委任（Delegation）の警告が出ることがあります。テーブルのレコード数が多くなると、自動生成のFilter関数やSearch関数が委任警告を出す場合があります。この場合はクエリの書き方を見直す必要があります。

他ユーザーと共有する場合はライセンスが必要です。自分一人で使うアプリであれば問題ありませんが、他のユーザーと共有して使う場合は、Dataverseを使うアプリにはPower Apps Premiumライセンスが必要になります。SharePointリストを使ったアプリはMicrosoft 365ライセンスで共有できましたが、Dataverseではそれができません。詳細はDataverseはSharePointアプリと違いライセンスが必要で整理しています。

DataverseとSharePointの自動生成アプリの違い

SharePointリストからアプリを自動生成したことがある方なら、操作感はほぼ同じと感じるはずです。ただ、いくつかの点が異なります。

	SharePointリストから生成	Dataverseテーブルから生成
生成の入口	SharePointリスト画面の「Power Appsで編集」	make.powerapps.comのホームから「既存のテーブルから開始」
必要なライセンス（共有時）	Microsoft 365（追加ライセンス不要）	Power Apps Premium（有償）
データ容量	リスト上限2,000アイテム（実用上の目安）	大量データに対応しやすい
リレーション	ルックアップ列で疑似的に実現	テーブル間リレーションとして正式に管理
生成される画面構成	3画面（Browse・Detail・Edit）	同じく3画面

操作感はほぼ同じですが、Dataverseの方がデータ構造の厳密さとスケーラビリティが高い分、設計時に考慮すべき事項も増えます。はじめは自動生成アプリで動作を体感してから、徐々にカスタマイズを加えていくアプローチが取り組みやすいです。

まとめ

Dataverseのテーブルから自動生成するアプリは、30秒〜1分で動く状態になります。そのまま業務アプリとして使う・カスタマイズのベースにする・テーブル設計の確認に使う、いずれの用途でも役に立ちます。

「テーブルを作ったらまず自動生成で動かして確認する」という習慣をつけることで、データを大量に入れてから設計ミスに気づくという状況を防ぎやすくなります。Dataverseを使い始めの段階でこの流れを体に染み込ませておくと、その後の開発がスムーズになります。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。テーブル設計・列型・環境・ライセンスまで、SharePoint経験者の視点で一通り整理しています。

DataverseのAuto-number列はテキスト型。フローで数値比較できない理由と回避策

Wed, 25 Mar 2026 17:30:32 GMT

DataverseのAuto-number列は、数値に見えてテキスト型です。この一点を知っているかどうかで、Power Automateフローを組むときの詰まり方がまったく変わります。

SharePointリストのID列（1, 2, 3と増える連番）を使い慣れていると、Dataverseにも同じような採番列があると期待するのは自然なことです。Auto-number列がまさにそれだと思って使い始め、フローの条件式で比較しようとしたら型エラー、という経験は、SharePointからDataverseに移行する人なら一度はぶつかります。自分もそうでした。

Auto-number列とはどんな機能か

設定できるフォーマット

Auto-number列は、レコードが新規作成されるたびに自動で値が採番される列です。採番のルールをフォーマット文字列で設定できるのが特徴で、以下の3種類の要素を組み合わせられます。

SEQNUM(桁数)：連番。例：{SEQNUM:4} なら 0001, 0002…
DATETIME(フォーマット)：日付。例：{DATETIME:yyyyMMdd} なら 20260322
RANDSTRING(桁数)：ランダム文字列

これらを自由に組み合わせることができます。たとえば REQ-{DATETIME:yyyyMM}-{SEQNUM:4} と設定すれば、REQ-202603-0001 のような番号が自動生成されます。SharePointの連番IDにはできない、業務要件に合わせた採番が可能なのはたしかに便利です。

ただし型はテキスト型。これが全ての起点

便利なフォーマット設定ができる一方、Auto-number列の型はテキスト（文字列）です。見た目が 0001 や 123 であっても、Dataverseの内部では文字列として保存されています。つまり数値計算も大小比較もできません。

なぜテキスト型なのかというと、REQ-202603-0001 のように日付や固定文字列を含めた複合フォーマットを実現するには、型を文字列にするしかないからです。純粋な数値型では、アルファベットや記号を含める採番ルールを表現できません。機能の柔軟性とのトレードオフとして、型はテキストに固定されています。

SharePointのID列との違い

改めて2つを比較してみます。

比較項目	SharePoint ID列	Dataverse Auto-number列
データ型	数値（整数）	テキスト（文字列）
自動採番	1, 2, 3…（固定）	フォーマット自由（REQ-0001 など）
数値比較	できる（gt, lt, eq）	できない（テキスト比較になる）
計算	できる（+1など）	できない
Patchでの書き込み	不可（自動）	不可（自動）
採番リセット	できない	できない（連番は減らせない）

SharePointのIDは純粋な数値型なので、フローの条件式で ID gt 100（100より大きい）のような比較がそのまま動きます。Auto-numberは見た目が同じ数字でも、中身は文字列なのでこれができません。

Power Automateフローで起きるエラーの実例

条件ステップでの型エラー

フローの条件ステップで Auto-number列の値が 100 より大きければ〜という分岐を作ろうとすると、思い通りに動きません。数値の 100 とテキストの 0100 を比較しているため、フローが正しく評価できないのです。エラーにならず無言でfalseを返し続けるケースもあり、原因に気づきにくいことがあります。

個人的に一番やっかいだと感じるのはこのパターンです。エラーメッセージが出ないまま動作がおかしいだけなので、フローのどこに問題があるのか特定しづらいです。

int()で数値に変換してから比較する

純粋な連番形式（0001, 0002…）のAuto-numberであれば、int()関数でテキストを整数に変換してから比較できます。式エディタ（fx）で以下のように書きます。

// Auto-number列の値を整数に変換してから比較する
int(triggerOutputs()?['body/cr52a_managementnumber'])

ただしこれが使えるのは、採番値が純粋な数字のみの場合に限ります。REQ-202603-0001 のようなプレフィックス付きフォーマットでは、数字部分だけを substring() や split() で切り出してからint()変換する必要があります。だんだん複雑になってきますね。

値の型を確認するには Composeアクションが便利です。Composeアクションの使い方の記事でも触れていますが、フローの途中でComposeにAuto-number列の値を渡して実行してみると、どんな形式で保存されているかを目で確認できます。

フィルタークエリでの注意

Dataverseの行を取得するアクションで、フィルター行に Auto-number列を使って絞り込もうとするときも注意が必要です。

// 数値として比較しようとするとうまく動かない
cr52a_managementnumber gt 100

// テキストとして一致比較なら動く
cr52a_managementnumber eq '0100'

大小比較はテキスト型では期待通りに動作しません。一致比較（eq）であればテキストとしての比較になるので動きます。どうしても大小比較が必要な場合は、数値型の別列を用意してそちらで管理するほうが現実的です。

Patch関数でAuto-number列への書き込みはできません

Power AppsのPatch関数でレコードを新規作成するとき、Auto-number列を指定しようとするとエラーになります。Auto-numberは読み取り専用の自動採番列なので、アプリ側から値を指定できない仕様です。

解決策はシンプルで、Patchのレコード定義からAuto-number列を省略するだけです。

// ❌ Auto-number列に値を入れようとするとエラー
Patch(
    案件テーブル,
    Defaults(案件テーブル),
    {
        管理番号: "0001",   // ← これがNGの原因
        件名: TextInput1.Text,
        担当者: Dropdown1.Selected.Value
    }
)

// ✅ 省略するだけでOK。採番はDataverseが自動でやってくれる
Patch(
    案件テーブル,
    Defaults(案件テーブル),
    {
        件名: TextInput1.Text,
        担当者: Dropdown1.Selected.Value
    }
)

Patchの書き方全般についてはPatch関数の使い方の記事をあわせて参照してください。

どうしても数値として使える連番が欲しい場合

SharePointのIDのように数値として扱える連番が業務上どうしても必要な場合、Auto-numberではなく数値型の列を別途用意するのが現実的です。いくつかの設計パターンを紹介します。

パターン1：Power Automateフローで採番する

レコード作成時にPower Automateをトリガーとして起動し、フロー内で現在の最大値を取得して+1した値を数値型列に書き込む方法です。処理の流れとしては次のようになります。

Dataverseの行が作成されたときにフローを起動
テーブル全体の行を取得し、採番列の最大値を取得
最大値+1を計算して、対象レコードの採番列に書き込む

同時に複数のレコードが作成される環境では採番の重複が起きるリスクがあります。同時アクセスが少ない業務アプリであれば現実的に問題になることは少ないですが、設計の前提として把握しておく必要があります。

パターン2：表示用と管理用を分けて持つ

Auto-number列はあくまで表示・印刷用の採番として使い、内部の管理キーはGUIDのままにする設計です。フローの条件分岐や検索キーにはGUIDを使い、Auto-numberは帳票に印刷する申請番号としてだけ機能させます。DataverseはGUIDで完結できる設計なので、この割り切りが一番シンプルです。

Power AppsからPower Automateを連携させる基本的な設計についてはPower AppsとPower Automateの連携記事も参考にしてください。

まとめ

DataverseのAuto-number列は見た目が数字でも型はテキスト（文字列）です
フロー条件での数値比較には使えません。int()変換が必要で、プレフィックス付きフォーマットではさらに複雑になります
Patch関数での書き込みは不要で、省略するのが正解です
数値として使える連番が必要な場合は、数値型の別列を用意してフローで採番するか、GUIDで割り切る設計を選びましょう

仕様を知った上で使うぶんには、表示用の採番列として十分活躍してくれます。SharePointのIDとは別物だと割り切って、Dataverse本来の設計に慣れていきましょう。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

Dataverseの列データ型まとめ｜SharePoint対応表つきで全型を解説

Wed, 25 Mar 2026 17:30:31 GMT

SharePointで使える列の種類をDataverseで探すと、似ているようで微妙に違う。そのギャップを整理したのがこの記事です。

Dataverseには10種類以上の列データ型があります。SharePointの列と対応させながら、それぞれの特徴と注意点を一通り把握しておくと、テーブル設計のときに迷わなくなります。個人的には、最初の1〜2テーブルを作るときにこの一覧をチェックしながら進めると後悔が少ないと思っています。

テキスト型（単一行・複数行）

単一行テキスト：デフォルト100文字に注意

SharePointの単一行テキストはデフォルト255文字ですが、Dataverseは100文字がデフォルトです。変更しなければ100文字を超える入力が切り捨てられます。最大400文字まで拡張できますが、SharePointから移行するつもりで設計するなら255文字に揃えておくのが無難です。変更手順と文字数制限の詳細についてはDataverseのテキスト列文字数設定の記事でまとめています。

また、Email・電話・URLなどのフォーマット指定が用意されていますが、Power Appsのキャンバスアプリでは見た目にほぼ反映されません。モデル駆動型アプリ（Model-driven App）を使う場合は機能しますが、キャンバスアプリ主体であれば気にしなくてよいです。

複数行テキスト：SharePointより大きな上限を持つ

デフォルト1000文字で、最大100万文字まで対応しています。SharePointの複数行テキスト（約65,000文字）より上限が大きいです。議事録や長文メモをDataverseで管理する用途には十分すぎるほどの容量です。

数値型：3種類ありますが普段はdecimalで十分

数値型はWhole number（整数）・Decimal number（小数）・Floating-point number（浮動小数点）の3種類から選べます。

Whole numberは年齢・個数・順位など小数点以下が不要な数値向けです。DecimalとFloatingは小数を扱える点では同じですが、精度が異なります。Decimalは正確な桁数を保持する方式なので、金額・パーセンテージなど精度が必要な場面に向いています。Floatingは科学的計算向けの方式で、誤差が出ることがあります。業務アプリの数値入力欄であれば、DecimalかWhole numberを選んでおけば間違いありません。

日付型：Date and Time と Date Only の2種類

日付型はDate and Time（日付と時刻）とDate Only（日付のみ）の2種類から選べます。一見シンプルですが、落とし穴があります。Date Onlyを選んだとしても、Dataverseの内部では深夜0時を含む日時として保存されます。タイムゾーンの設定を誤ると、見かけ上は同じ日付でも時差の影響で1日ずれて表示される現象が起きます。

この問題を防ぐには、列作成時にadvanced optionsのTime Zone設定でTime Zone Independentを選ぶ必要があります。この設定は作成後に変更できません。詳しい仕組みと対処法はDataverseの日付タイムゾーン設定の記事で解説しています。日付列を作るときは必ずこの記事を確認してから設定するようにしています。

選択肢（Choice）：SharePointの選択肢とほぼ同じですが複数選択は扱いが複雑

SharePointの選択肢列と似た感覚で使えます。選択肢の値・ラベルを設定して、ドロップダウンで選ばせる列です。Dataverseでは色を設定する機能もありますが、キャンバスアプリでは色の情報が反映されません。モデル駆動型アプリのみ色が使われる仕様です。

注意が必要なのは複数選択対応の選択肢（Multi-select Choice）です。SharePointの複数選択と見た目は似ていますが、Dataverse内部ではテーブル構造として保存されるため、Power AutomateやPower Apps数式での取り扱いが複雑になります。単純な一択選択肢で事足りる場合は、Multi-select Choiceを使わないほうが扱いやすいです。

Yes/No：SharePointのBoolean（true/false）とは別物

SharePointのYes/No列はBoolean型（true/false）ですが、DataverseのYes/No列は選択肢型の一種です。Power Appsの数式でif(YesNo列, …)と書いても思い通りに動きません。詳しい扱い方はDataverseのYes/No列の記事でまとめていますので、ぜひ一読してから使ってください。

Auto-number：見た目は数字でも型はテキスト

自動採番の列です。採番ルールをフォーマット文字列で柔軟に設定できます。ただし型はテキスト（文字列）なので、Power Automateのフローで数値比較をしようとするとエラーになります。SharePointのID列（整数型の連番）とは別物です。仕組みと対処法はDataverseのAuto-number列の記事で詳しく説明しています。

通貨（Currency）：追加すると関連列が4本自動生成される

金額を扱う列です。多通貨対応のため、通貨列を1本追加すると関連列が約4本自動生成されます。具体的には、基準通貨での金額・換算レート・使用通貨の種類などが裏側で追加されます。初めて通貨列を作ると突然テーブルに見知らぬ列が増えて驚きます。自分も最初に見たとき何が起きたのかわからず焦りました。業務で多通貨対応が必要な場合以外は、単純な数値型（Decimal number）で代用するほうが混乱を避けられます。

ルックアップ（Lookup）：テーブル同士のリレーションを作る

別のテーブルを参照する列です。SharePointのルックアップ列と概念は似ていますが、Dataverseのルックアップはリレーション（多対一の関係）を自動で生成する本格的なリレーショナル設計です。

ルックアップを設定すると、ドロップダウンに参照先テーブルのプライマリ列（Primary column）の値が表示されます。SharePointは表示列を後から選び直せますが、Dataverseはプライマリ列がそのまま使われます。プライマリ列の設計が後から変更できないため、参照テーブルを作るときに何をプライマリ列にするかを先に考えておく必要があります。ルックアップ列の詳しい使い方は別記事で解説しています。

また、Power Appsの数式でルックアップ値を参照するときとSharePointのルックアップとでは書き方が異なります。Filter・Search・LookUp関数の記事に実例があるので参照してください。

数式（Formula）：Power FXで計算列を作れる

Power FXの数式を使って計算列を作れます。たとえば姓と名を結合してフルネーム列を作ったり、日付の差分を日数で出したりといった用途に使います。Excelの計算列に近い感覚で設定できますが、使える関数の種類がまだ限られていて、今後拡充される予定の機能です。現時点ではシンプルな計算列であれば十分機能します。

SharePoint列との対応表

まとめとして、SharePointとDataverseの列データ型の対応を整理します。

SharePoint列	Dataverse相当	主な注意点
一行テキスト（255文字）	単一行テキスト（100文字）	デフォルト文字数が少ない。255に変更推奨
複数行テキスト	複数行テキスト	上限はDataverseのほうが大きい
数値	整数 / 小数 / 浮動小数点	精度によってDecimalかWhole numberを選ぶ
通貨	通貨（Currency）	関連列が自動追加される。Decimalで代用も可
日付と時刻	Date and Time / Date Only	タイムゾーン設定を必ず確認。後から変更不可
選択肢	Choice	色設定はキャンバスアプリでは使われない
Yes/No（Boolean）	Yes/No（Choice型）	SharePointのBoolean(true/false)と別物
ルックアップ	Lookup	リレーションを自動生成。Primary column設計が鍵
ID（自動採番・整数）	Auto-number（テキスト型）	数値比較できない。GUIDが本来の主キー
計算列	Formula（数式）	Power FXで設定。使える関数は現時点で限定的

SharePointのリストとDataverseを比較したい場合はSharePointリストとMicrosoft Listsの記事も参考にしてください。またExcelをデータソースとして使う場合との違いについてはExcelデータソースの記事と合わせて読むと整理しやすいです。

まとめ

テキスト型はデフォルト100文字なので、SharePoint移行時は255文字への変更を検討しましょう
数値型はDecimal numberかWhole numberを選んでおけば業務アプリでは十分です
日付型はタイムゾーン設定が後から変更できません。作成前に必ず確認してください
Yes/NoとAuto-numberはSharePointとは別物です。それぞれの専用記事で仕組みを把握しておくと詰まらなくなります
ルックアップは参照先テーブルのプライマリ列設計が後から変えられないため、設計段階で何を表示名にするかを決めておきましょう

列の種類を一通り把握できると、テーブル設計の打率が格段に上がります。最初は全部理解しようとせず、まず作るテーブルに使いそうな型だけをおさえて、必要に応じてこの記事に戻ってくる使い方で十分です。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

Dataverseで日付が1日ずれる原因と解決策｜タイムゾーン設定の落とし穴

Wed, 25 Mar 2026 17:30:32 GMT

Dataverseの日付列をDate Only（日付のみ）に設定したのに、Power Appsで表示すると1日前にずれてしまう。このバグっぽい挙動を経験したことがある方は多いと思います。原因はタイムゾーンの設定です。そして厄介なことに、列を作成した後からは変更できません。

この記事では、なぜDate Onlyでもずれるのかの仕組みと、列作成時に必ず設定すべき Time Zone Independent の選び方を解説します。

なぜDate Onlyでも日付がずれるのか

Dataverseの内部保存の仕組み

Dataverseの日付列は、内部では日付と時刻をセットで保存しています。Date Only という表示設定は、あくまでユーザーインターフェース上で時刻部分を隠しているだけです。

たとえば2026年3月22日として入力した値は、内部では 2026-03-22T00:00:00Z（深夜0時のUTC）として保存されています。このときタイムゾーンがどう扱われるかが、ずれの根本原因です。

デフォルト設定 User Local の問題

Dataverseの日付列にはタイムゾーンの動作という設定があり、デフォルトは User Local（ユーザーのローカルタイム）になっています。User Localの動作はこのような流れです。

日本（UTC+9）のユーザーが2026年3月22日を入力する
Dataverseは2026-03-22T00:00:00+09:00として解釈し、UTCに変換して2026-03-21T15:00:00Zで保存する
Power Appsでこの値を表示すると、UTCの値にユーザーのタイムゾーンを適用して2026年3月22日と表示される

日本国内だけで使うなら一見問題ありません。しかし Date Only として扱っているにもかかわらず、タイムゾーン変換が走ることで、ブラウザの設定や環境によって表示がずれることがあります。特に2つの問題が起きやすいです。

Power Automate フローで日付を取り出すと、内部保存のUTC値が返ってくるため日本時間より9時間前になる
異なるタイムゾーンの環境（例：海外に設定されたテナント）で開くと前日の日付として表示される

解決策：列作成時に Time Zone Independent を選ぶ

Time Zone Independentとは

Time Zone Independent（タイムゾーン非依存）を選ぶと、入力した日付をそのままの値でDataverseに保存します。タイムゾーン変換が一切行われないため、2026年3月22日と入力したら2026-03-22としてそのまま保存されます。

日付だけを管理したいユースケース（生年月日・期限日・契約日など）では、Time Zone Independentが正解です。

設定手順

Dataverseでテーブルを開き、日付列を新規作成します
データ型で「日付と時刻（Date and Time）」または「日付のみ（Date Only）」を選びます
詳細オプション（Advanced options）を展開します
タイムゾーンの動作（Time zone adjustment）をTime Zone Independentに変更します
保存してCreate（作成）します

詳細オプションを展開しないとこの設定が表示されないので注意が必要です。デフォルトのUser Local のまま気づかずに列を作ってしまうケースが多いです。

作成後に変更できない、という最大の注意点

このタイムゾーン設定は、列を作成した後に変更できません。User Localで作ってしまったら、既存のデータを別列に移し替えて、元の列を削除し、新しくTime Zone Independentで作り直すしかありません。

Dataverseを初めて触ったとき、この制約を知らずにUser Localで列を大量に作ってしまい、後で全部作り直した経験があります。設計の初期段階でこの選択をしっかりしておくかどうかで、後の手間がかなり変わります。テーブル設計フロー全体については、SharePointと違うDataverseのテーブル作成フローでまとめています。

Power Automateフローでの注意点

Time Zone Independentで列を作成しても、Power Automateフローで日付を扱う際は別の注意が必要です。フローで日付列の値を取得すると 2026-03-22T00:00:00Z のようなUTC形式で返ってくることがあります。この値を条件式や通知メッセージで使う場合、convertTimeZone()や formatDateTime()関数で適切な書式に変換する必要があります。

Dataverseの日付がフローで期待どおりに動かないときは、まず User LocalかTime Zone Independentかを確認し、次にフロー内の変数の型を確認するのが手順です。変数の型の扱い方についてはPower Automateで変数を使いこなす記事が参考になります。

タイムゾーン設定の選び方まとめ

設定	動作	使うべきケース
User Local（デフォルト）	入力時のタイムゾーンを考慮してUTC変換	時刻まで含めて正確に管理したいとき
Time Zone Independent	入力値をそのまま保存、変換なし	日付のみを管理するとき（期限・生年月日など）
UTC	UTC固定で保存	グローバルなシステム連携など特殊なケース

日付のみを管理するなら Time Zone Independent 一択です。これだけ覚えておけばほとんどのケースをカバーできます。

まとめ

DataverseのDate Only列でも、タイムゾーン設定が「User Local」だと日付がずれる可能性があります
日付のみ管理するなら、列作成時に詳細オプション→Time Zone Independent を選びます
この設定は列作成後に変更できないため、テーブル設計の段階で必ず確認してください
Power Automateフローで日付を扱う場合はさらに書式変換が必要になる場合があります

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

Dataverseの環境とは何か。テーブルが見えない原因の8割はここにあります

Wed, 25 Mar 2026 17:30:31 GMT

Dataverseを使い始めた人が最初にぶつかる壁の一つが、環境（Environment）という概念です。作ったはずのテーブルが見えない、アプリが動かない、フローがつながらない。これらのトラブルの多くは、環境を正しく理解できていないことが原因です。

SharePointを使い慣れている方には、環境をSharePointのサイトコレクションと同じ感覚で捉えると理解しやすいです。この記事で環境の仕組みと実際の使い方を整理します。

環境とはデータベースの境界線です

SharePointのサイトコレクションで考える

SharePointには、サイトコレクションという単位があります。サイトコレクションが違えば、そこにあるリストもファイルも別の管理領域にあります。異なるサイトコレクション間でリストを参照するには特別な設定が必要です。

Dataverseの環境はほぼ同じ考え方です。環境が違えば、テーブルも別物です。環境Aで作ったテーブルは、環境Bからは見えません。アプリやフローは作成した環境に紐づいているので、環境を間違えて作ってしまうと、テーブルに接続できなくなります。

概念	SharePoint	Dataverse
データの管理単位	サイトコレクション	環境（Environment）
中にあるもの	リスト・ライブラリ・サイト	テーブル・フロー・アプリ
別の単位との関係	基本的に分離（クロスサイトは特別設定が必要）	完全に分離（環境をまたいだ参照は原則できない）
誰が作れるか	サイトコレクション管理者	管理センターの権限保有者 or 開発者プランユーザー

環境の中に何が入っているか

一つの環境の中には、Dataverseのテーブルだけでなく、その環境に紐づくPower Appsのアプリ、Power Automateのフロー、Power BIのレポートなども含まれます。つまり環境は、Power Platformで作るものすべての入れ物です。

アプリを作るときは必ず特定の環境の中に作ることになります。そのアプリがDataverseのテーブルにアクセスできるのは、同じ環境のテーブルだけです。これを知らずに異なる環境でアプリとテーブルを作ってしまうと、接続できなくて詰まります。自分も最初のころにやらかしました。

環境の種類と使い分け

デフォルト環境は触らないほうが無難です

テナントに最初から存在する共有の環境です。テナント内の全ユーザーが自動的にアクセスできるため、誰でもテーブルやアプリを作れます。

一見便利そうですが、管理の観点からは問題が起きやすいです。誰が作ったかわからないテーブルが増えていき、データの品質もアクセス制御も担保しにくくなります。社内全員が書き込み権限を持つSharePointリストを想像してみてください。整理されずに情報が散乱していく状況に近いです。

本番のアプリやデータは、デフォルト環境ではなく専用の本番環境で管理することをおすすめします。デフォルト環境は学習・実験用と割り切るのが現実的です。

開発者環境は最初はここで始めましょう

Microsoft Power Apps Developer Planに登録すると、自分専用の開発者環境を無料で作れます。この環境は自分しかアクセスできないので、デフォルト環境を汚すことなく自由に実験できます。

Dataverseを初めて触る方は、まず開発者環境を作ってそこで作業することを強くおすすめします。失敗しても自分の環境の中だけで完結しますし、テーブルを壊しても作り直せます。社内のデフォルト環境で練習すると、意図せず他の人に影響が出ることがあります。

開発者環境の作り方

Microsoft Power Apps Developer Planに登録する（公式サイト）
make.powerapps.com を開く
画面右上の環境名をクリックして環境一覧を表示する
一覧の中に（自分の名前）の環境が表示されていれば作成完了

Developer PlanはDataverseも含めて無料で使えますが、本番公開はできません。あくまで学習・検証用です。本番運用に移行するときはPremiumライセンスが必要になります。ライセンス周りの詳細についてはPower Appsのライセンス解説記事を参照してください。

本番環境は管理者が作る正式な器

組織のPower Platform管理者がPower Platform管理センター（admin.powerplatform.microsoft.com）で作成する環境です。アクセス権限・データ保護ポリシー・Dataverseの有効化などを管理者が設定します。

本番環境はユーザーが勝手に作れないよう、管理センターのロールで制御するのが一般的です。開発環境・テスト環境・本番環境の3つを分けて運用するのが理想ですが、小規模な組織では開発者環境と本番環境の2つで運用することも多いです。

テーブルが見えないときの4つの確認ポイント

make.powerapps.com でテーブルを探しても見当たらない。このトラブルは環境が原因のことがほとんどです。以下の順番で確認してみてください。

確認1：今いる環境は正しいか

画面右上に環境名が表示されています。ここが期待している環境名になっているか確認します。違う場合はクリックして正しい環境を選択します。環境の切り替えだけで解決することが一番多いです。

確認2：その環境にDataverseが有効化されているか

環境が存在していても、Dataverseデータベースが有効化されていない環境があります。特にデフォルト環境以外の手動で作った環境では、Dataverseを後から追加する設定が必要なことがあります。Power Platform管理センターで対象の環境を開き、Dataverseの欄が有効になっているか確認します。有効化するには管理者権限が必要です。

確認3：アクセス権限はあるか

本番環境など管理者がアクセス制御を設定している環境では、自分がテーブルにアクセスする権限を持っていないことがあります。環境管理者に確認して、必要なロールを付与してもらいます。

確認4：テーブル自体が存在するか

最後の確認です。そのテーブルを作ったのは本当にこの環境だったでしょうか。別の環境で作成していた場合、この環境にはテーブルがありません。開発者環境と本番環境を混同して作業していたというケースもよくあります。

環境の切り替え方と確認の習慣

make.powerapps.com を開いたとき、自動的にどの環境が選択されるかは前回ログアウトした時点の環境によって変わります。毎回右上の環境名を確認する習慣をつけておくと、環境の混同によるトラブルを防げます。

社内でPower Platformを複数のプロジェクトで使い始めると、環境の数も増えていきます。本番A・本番B・開発用・個人実験用……と増えていくので、環境の命名規則を最初から決めておくのがおすすめです。SharePointのサイト名の命名規則と同じ感覚で決めると整理しやすいです。

まとめ

Dataverseの環境はSharePointのサイトコレクションと同じ概念です。環境が違えば、テーブルもアプリも別の管理領域にあります
テーブルが見えないときは、まず画面右上の環境名を確認します。環境の切り替えで解決することが最多です
Dataverseを初めて使う場合は、Developer Plan（無料）で開発者環境を作ってそこで作業を始めるのが安全です
本番運用には管理者が作成した専用の環境とPremiumライセンスが必要です

環境の概念さえ理解できれば、Dataverse周りのトラブルシューティングがかなり楽になります。SharePointのサイトコレクションと対応させながら、感覚をつかんでいきましょう。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

DataverseのExcelライブ編集機能｜バルク編集とデータ構造確認に使う隠れ技

Wed, 25 Mar 2026 17:30:33 GMT

DataverseのデータはExcelで直接編集できます。エクスポートしてインポートし直す必要はありません。

このExcelライブ編集という機能、知っている人が意外と少いです。Dataverseを使い始めた人に教えると、ほぼ全員が驚きます。単なるデータ編集手段というだけでなく、GUIDの実態や Created by 列の中身など、Dataverseの内部構造を生データで確認できる唯一の手段でもあります。バルク編集とデバッグの両方で使える機能です。

Excelライブ編集とは何か

エクスポートではなく「ライブ接続」

まず最も重要な点を先に言います。ExcelにDataverseのデータが表示されますが、これはスナップショットのコピーではありません。Power Appsアドイン経由でDataverseに直接接続した状態です。

Excelで編集して保存すると、その変更が直接Dataverseに書き戻されます。SharePointでExcelをエクスポートしてデータをコピーし、またインポートする——という手順は不要です。この仕組みを理解していないと、後述するPublishボタンを押し忘れてデータが反映されないという落とし穴にはまります。

Excelをデータソースとしてそのまま使う方法は別の話です。DataverseのExcelライブ編集はDataverseを主として使い、その操作・確認UIとしてExcelを使う位置づけです。Excelをデータソースにする場合との違いはExcelをPower Appsデータソースにする記事に整理しています。

基本的な操作手順

Excelを開くまで

make.powerapps.com を開き、テーブル一覧から対象のテーブルを選択する
画面上部の Edit ボタンをクリックし、メニューから Edit data in Excel を選ぶ
.xlsx ファイルのダウンロードが始まるので開く
Excelが起動したらPower Appsアドイン（画面右側）のサインインを求められる
Microsoft 365アカウントでサインインして接続を確認する

初回はアドインのサインインが必要です。2回目以降は自動で接続されることが多いですが、アカウントが変わった場合はサインインし直しが必要です。

データを編集してPublishする

Excel上でデータを直接編集する（セルをクリックして書き換えるだけ）
新規行の追加も可能（最終行の下に入力する）
編集が終わったら、Excelの右側に表示されているPower Appsアドインパネルで Publish ボタンをクリックする
成功メッセージが表示されたらDataverseに反映完了

Excel側で保存（Ctrl+S）をしても、Dataverseには反映されません。Publishボタンを押して初めて書き戻されます。この違いを最初に教わらなかった人がPublishを知らずに閉じてしまい、入力したデータが消えた——という話はよく聞きます。

活用シーン①：バルク編集（大量データの一括修正）

Power Appsアプリ上でレコードをひとつひとつ編集するのは大量件数だと現実的ではありません。Excelライブ編集を使えばExcelの操作感のままデータを一括修正できます。

たとえばこういった使い方が実用的です。

担当者名が変わったレコードを一括で書き換える（100件でも一操作）
ステータスが特定の値のレコードを一括で更新する
マスターデータの初期投入（手入力よりExcelのほうが速い）
別システムからコピーしたデータを貼り付けて登録する

ただし同時に複数のユーザーが同じテーブルを編集している状況では、Publish時に競合が発生することがあります。業務時間外や利用者が少ない時間帯にまとめて更新するほうが安全です。

活用シーン②：生データを確認する（Dataverse理解の最短ルート）

Excelライブ編集のもう一つの価値が、Dataverseの内部データをそのままの形で見られる点です。Power Appsアプリ上では表示を加工しているため、実際にDataverseに保存されている値と見え方が異なることがあります。生データを確認することでDataverseの仕組みへの理解が格段に速まります。

GUIDの実態が見える

Power Appsアプリ上でレコードを見ても、主キーであるGUIDは通常表示されません。Excelライブ編集を開くと、IDや主キー名の列にGUIDの値（36文字の英数字）が表示されます。DataverseにはSharePointのような連番IDがなく、GUIDが主キーとして機能しているという感覚を、目で見て実感できます。GUIDの詳細についてはDataverseのGUID解説記事を読んでみてください。

Created by がGUIDで表示される

作成者（Created by）列は、アプリ上では名前やアイコンで表示されることが多いですが、Excelライブ編集では内部のGUID値が表示されます。Dataverseではユーザーも別のテーブル（SystemUser）で管理されていて、ルックアップ先のGUIDが保存されているためです。

フローや数式で作成者をフィルター条件にしようとしたとき、なぜ名前ではなくGUIDを使わなければならないのか——その理由がExcelライブ編集を一度見れば腑に落ちます。

列のシステム名（スキーマ名）が見える

Power Appsのテーブル画面では列の表示名（日本語名）が並んでいますが、Excelライブ編集ではヘッダーにシステム名（例：cr52a_tantousha）が表示されることがあります。Power AutomateのDataverse行の取得アクションや、ODataフィルター条件を書くときにシステム名が必要になる場面があるので、ここで確認しておくと便利です。

注意点と使えないケース

Excelライブ編集にはいくつかの制約があります。把握しておくと現場で慌てずに済みます。

制約	内容
書き込み権限が必要	閲覧権限のみのユーザーはPublishできない
同時編集の競合	複数人が同時にPublishすると後勝ちになる（注意が必要）
Auto-number列は編集不可	読み取り専用列はExcel上でも変更できない
大量件数は時間がかかる	数千件を超えるデータのPublishは処理時間がかかる
アドインのサインインが必要	初回・アカウント変更時にPower Appsアドインへのログインが必要

Auto-number列や主キー（GUID）列はExcel上でも編集できません。グレーアウトされているか、変更しようとするとエラーになります。これはDataverseの仕様として想定された動作なので、試みず放置するのが正解です。

まとめ

ExcelライブEditはエクスポートではありません。Power Appsアドイン経由でDataverseに直接接続した状態です
編集後は必ずPublishボタンをクリックしてください。Excel側の保存だけではDataverseに反映されません
バルク編集（大量データの一括修正・初期投入）に最も使いやすい手段です
GUID・Created by・スキーマ名など、Dataverseの内部構造を目で確認できる唯一の手段です。Dataverseを理解する上でも一度は覗いてみる価値があります

まだ触ったことがない方は、テスト用の環境で一度試してみてください。アプリからしかデータを操作できないと思い込んでいたとしたら、この機能を知るだけで作業効率がかなり変わります。

データベースからアプリを作る全体的な流れについてはデータベースからのアプリ作成記事も参考にしてください。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

DataverseにIDがない理由｜GUIDとは何か、SharePointのIDとの違いを解説

Wed, 25 Mar 2026 17:30:32 GMT

SharePointリストのIDに慣れていると、Dataverseのテーブルを初めて開いたとき「あれ、ID列がない？」と戸惑います。でも実際には、IDに相当するものはちゃんとあります。名前が違うだけです。

この記事では、DataverseのGUIDとは何か、SharePointの連番IDとどう違うのか、そしてテーブルと同じ名前の列が2本あるように見える謎を順番に整理します。

SharePointのID列とDataverseのIDの違い

SharePointのID：1から始まる連番

SharePointリストのID列は、レコードを追加するたびに自動で1, 2, 3……と増えていく連番です。視認性が高く、「今何件登録されているか」を直感で把握できます。フローの条件式でも「ID eq 123」のように数値比較できるので、扱いやすいです。

ただしこの連番はSharePoint特有の仕様で、削除したレコードの番号が再利用されることはありません。100番を削除しても、次のレコードは101番になります。

DataverseのID：GUIDという文字列

Dataverseのテーブルには連番IDが存在しません。代わりに、レコードごとに自動で割り振られる「GUID」がIDの役割を担います。

GUIDとは、Globally Unique Identifierの略で、世界中で重複しない一意の識別子を生成する仕組みです。見た目はこんな形になります。

a1b2c3d4-e5f6-7890-abcd-ef1234567890

ハイフンで区切られた32文字の英数字です。ランダムに生成されるため連番にはなりませんし、人間が覚える必要もありません。Power Appsのギャラリーや数式の内部で自動的に参照されるので、開発者がGUID自体を意識する場面はほとんどありません。

とはいえ、「IDが連番でない」という事実はフローや数式の設計に影響することがあります。特にSharePointのID列を前提にした設計（例：Auto-incrementで採番したいなど）を持ち込もうとすると、壁にぶつかります。

「テーブルと同じ名前の列が2本ある」謎を解く

なぜ同名の列が2本に見えるのか

Dataverseのテーブルを列の一覧で見ると、テーブル名と同じ名前の列が2本存在するように見えることがあります。たとえば「案件管理」というテーブルを作ると、「案件管理」という列が2本表示されるようなイメージです。

これは仕様です。2本あるように見える列のうち1本は「プライマリ列（Primary column）」——つまり主キーとは別の「表示名」として機能する列です。SharePointリストの「タイトル（Title）」列に相当します。

もう1本はテーブルの主キーとなるGUIDを格納する列で、テーブル名に「ID」を付けた名前になっています（例：案件管理ID）。この列が実質的なIDの本体です。

プライマリ列とGUID列の違い

列の種類	役割	データ型	ユーザーが入力するか
プライマリ列（テーブル名と同名）	ルックアップ時の表示名	テキスト	する
GUIDを格納する列（テーブル名＋ID）	レコードの一意識別子（主キー）	一意識別子（GUID）	しない（自動生成）

ルックアップ列（他のテーブルを参照する列）を設定すると、参照先のプライマリ列の値がドロップダウンに表示されます。SharePointリストの「タイトル列がルックアップの表示名になる」動作と同じ仕組みです。

テーブルを作ったら最初に「プライマリ列に何を入れるか」を設計しておくと、後のルックアップ設定がスムーズになります。

Excelライブ編集でGUIDを実際に見てみる

GUIDが自動生成されることは説明しましたが、「本当にそんな列があるのか」を目で確認したいなら、Dataverseの「Excelでデータを編集する」機能が手っ取り早いです。

make.powerapps.com でテーブルを開き、上部メニューの「データの編集」→「Excelで編集」を選ぶと、Excelがライブ接続の状態で開きます。そこには画面上には表示されていないGUID列も含め、テーブルの生データが全列分表示されます。

自分が初めてDataverseを使ったとき、このExcel表示を見てようやくGUIDの存在が腑に落ちました。「そうか、ここに書いてあるこれがIDの正体か」という感覚です。概念として理解するより、生データを見るほうが早いことは多いです。

詳しい使い方はDataverseのExcelライブ編集で解説しています。

GUIDは「覚えなくていいが、存在は知っておく」

日常的な開発では、GUIDを直接扱う場面はほとんどありません。Power Appsの数式でレコードを参照するときも、GUIDを意識せず「ThisItem」や「LookUp」で操作できます。

ただし以下のようなケースでは、GUIDの存在を知っていると解決が速くなります。

Power Automateフローで「レコードのID」をどの列から取得するか迷ったとき
別のテーブルからルックアップで参照したレコードを特定したいとき
SharePointのID列を使ったフローをDataverseに移行しようとして詰まったとき

SharePointのIDに慣れていると「DataverseにはなぜわかりやすいIDがないんだ」と感じることもあります。でも、GUIDはグローバルなシステム間連携を想定した仕様です。SharePointは社内の小規模リストを想定した連番、Dataverseはエンタープライズ規模のデータ管理を想定したGUID、という設計思想の違いとして理解しておくと気持ちが楽になります。

DataverseとSharePointリストの構造的な違いについては、SharePointリストとMicrosoft Listsの記事もあわせて参照してください。また、Power AppsでSharePointリストのデータをCRUD操作する具体的な手順はこちらの記事でまとめています。

まとめ

DataverseにはSharePointのような連番IDはなく、代わりにGUID（一意識別子）がレコードを識別します
テーブルと同じ名前の列が2本に見えるのは「プライマリ列（表示名）」と「GUID列（主キー）」が別物だからです
GUIDはExcelライブ編集で生データとして確認できます
日常の開発でGUIDを直接操作する場面は少ないですが、存在と役割を知っておくと詰まったときに早く解決できます

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

DataverseはSharePointアプリと違いライセンスが必要｜E5でも別途必要な理由

Wed, 25 Mar 2026 17:30:31 GMT

DataverseはSharePointリストよりはるかに強力なデータソースですが、利用にはPower Apps Premiumライセンスが必要です。SharePointアプリと同じ感覚で導入しようとすると、ライセンスの壁にぶつかります。

SharePointアプリとDataverseアプリ。ライセンスの根本的な違い

まず前提として、Power Appsのライセンスには大きく2種類あります。Microsoft 365ライセンス（M365やOffice 365のサブスクリプション）に含まれているものと、追加で契約が必要なPower Apps Premiumです。

SharePointリストをデータソースにしたアプリは、Microsoft 365ライセンスの範囲内で動かすことができます。つまり多くの会社では、社員がすでにM365アカウントを持っているなら、追加コストゼロでSharePointアプリを作って使ってもらえます。これがSharePointが市民開発の定番データソースになっている大きな理由のひとつです。

一方、Dataverseをデータソースにしたアプリは話が変わります。アプリをビルド（作成）すること自体はPremiumなしでも可能です。ただし、そのアプリを他のユーザーと共有して実際に使ってもらうためには、利用者全員にPower Apps Premiumライセンスが必要になります。

この仕組みを整理すると次のようになります。

項目	SharePointリストアプリ	Dataverseアプリ
アプリのビルド（作成）	M365ライセンスで可能	M365ライセンスで可能
他ユーザーへの共有・利用	M365ライセンスのみでOK	利用者全員にPower Apps Premiumが必要
E5で利用可能か	可能	不可（追加契約が必要）
追加コストの目安	なし	約20ドル/ユーザー/月（2024年時点）

SharePointリストとDataverseの機能面での違いについてはSharePointリストとMicrosoft Listsの違いでも解説しています。ライセンスだけでなく、機能面での使い分けも参考にしてください。

E5ライセンスでも対象外

よく受ける質問のひとつが、「うちの会社はMicrosoft 365 E5を契約しているからDataverseも使えますよね？」というものです。残念ながら、これは正確ではありません。

E5はMicrosoft 365の最上位プランで、高度なセキュリティ機能や音声通話機能なども含まれる充実したプランです。しかし、Power Apps Premiumは含まれていません。E1でもE3でもE5でも、Power Apps Premiumは別途契約が必要です。

個人的にも社内でこの説明をするたびに驚かれます。高いライセンス料を払っているのにさらに追加が必要なのかと。気持ちはよくわかりますが、これはMicrosoftのライセンス構造上そういうものなので、そういうものだと割り切って考えるしかない部分です。

導入前に試算してみる

Power Apps Premiumは2024年時点で1ユーザーあたり月額約20ドル（日本円で概算3,000円前後）です。

たとえば10人のチームで社内ツールを使う場合、月3万円程度の追加コストが発生します。SharePointアプリなら追加コストゼロだったことを考えると、この差は無視できません。50人が使うアプリになれば月15万円規模になります。

Dataverseを導入する前に、利用者の人数と月額コストをざっと試算してから意思決定することをおすすめします。小規模なチーム内ツールなら費用対効果が見えやすいですが、全社展開を考えているなら、先に情報システム部門や経営層との調整が必要になる場合もあります。

Dataverseだけじゃない、Premiumが必要なデータソース

Premium扱いになるのはDataverseだけではありません。Power Appsで接続できるデータソースの中には、Premiumコネクターに分類されるものが多数あります。代表的なものを挙げると、SQL Server（オンプレミス・Azure SQL）、Salesforce、ServiceNow、Dynamics 365などです。

これらをデータソースにしたアプリも、利用者にPower Apps Premiumが必要です。SharePointやExcel、Teams、OneDriveはStandardコネクターなので追加コストはかかりませんが、ひとつ踏み込んだデータソースを使う場合は必ずライセンスを確認してください。

Power Appsのライセンス全体の仕組みについてはPower Appsのライセンスをわかりやすく解説に詳しくまとめています。無料で使える範囲と有料プランの違いも合わせて確認しておきましょう。

model-driven appsとPower Pagesも同様

Dataverseを前提としたアプリの種類として、model-driven appsというものがあります。Canvas appがUIを自由に設計できるのに対して、model-driven appsはDataverseのテーブル構造に沿って自動的に画面が生成されるタイプのアプリです。Excelのフォームビューのような使い勝手で、設定次第で素早くデータ管理画面を作れます。

model-driven appsはDataverseなしでは動かない仕組みなので、利用者にPower Apps Premiumが必要であることはCanvas appと同様です。

Power Pages（外部向けWebサイトをDataverse連携で作るサービス）についても、ライセンス体系は別途確認が必要です。こちらは用途が社外向けになるため、ライセンス構造がより複雑になります。

それでもDataverseを選ぶ理由

ここまでコストとライセンスの話ばかりしてきましたが、Dataverseにはそのコストに見合うだけの価値があります。

SharePointリストにはないテーブル間のリレーション（ルックアップ列）、タイムゾーン対応の日付管理、GUIDによる堅牢な主キー設計、こうした本格的なデータベース機能を、ノーコードのPower Appsから扱えるのはDataverseだけです。大量のデータや複数テーブルを組み合わせた複雑な業務ロジックが必要なアプリを作るなら、SharePointリストには限界があります。

実際に私が社内でDataverseを使い始めたのは、SharePointリストだけではどうしても実現できない要件が出てきたからです。最初はライセンスコストを聞いて一歩引きましたが、実現できる機能の幅を考えると、必要な投資だと判断しました。

データベースからアプリを作る基本的な流れはPower Appsでデータベースから簡単にアプリを作る手順でも紹介しています。Dataverseを使ったアプリ作成のイメージをつかむ参考にしてください。

まとめ

Dataverseは機能面では文句なしのデータソースですが、利用には追加のライセンスコストがかかります。ポイントを整理しておきます。

Dataverseアプリの利用者全員にPower Apps Premiumが必要
E5を含むM365ライセンスではカバーされない
SQL ServerなどほかのPremiumコネクターも同様
導入前に人数×月額コストを試算する

コストも仕様のひとつとして正確に把握した上で、それでも必要だと判断したら導入する、その順番を踏んで進んでいきましょう。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

Dataverseのルックアップ列でテーブルをリレーションさせる｜作成・primary column設計のポイント

Wed, 25 Mar 2026 17:30:33 GMT

Dataverseのルックアップ列は、SharePointのルックアップ列と似ているようで、設計時に押さえておくべき重要な制約があります。なかでも「primary column（プライマリ列）は後から変更できない」という点を最初に知っておかないと、後で大きな手戻りが発生します。

私自身が最初にDataverseのリレーション設計で失敗したのは、担当者テーブルのprimary columnを確認せずにルックアップ列を作ってしまったときです。ドロップダウンに社員番号が表示されてしまい、後から修正しようとしたところ変更できないとわかり、テーブルごと作り直す羽目になりました。この記事では、同じ失敗をしないためにルックアップ列の設計から作成手順まで順を追って説明します。

choice列とlookup列——まず使い分けを把握する

Dataverseでドロップダウンを実現する方法は主に2つあります。「choice列（選択肢列）」と「lookup列（ルックアップ列）」です。この2つの違いを理解することが、設計の第一歩です。

choice列はシンプルで、列の定義に選択肢リストを直接書き込む仕組みです。「承認済み」「未承認」「却下」のような固定の選択肢であれば、choice列で十分です。Power Appsでの扱いも文字列としてシンプルに扱えるため、初心者にも使いやすい設定です。

一方、lookup列は別テーブルのレコードと紐づける仕組みです。たとえば「担当者」をドロップダウンで選ぶ場合、担当者テーブルのレコードそのものと紐づけることができます。担当者のメールアドレスや部署名なども後から引き出せるのが、choice列との最大の違いです。

	choice列	lookup列
データの実体	列に定義した選択肢リスト	別テーブルのレコード
追加属性の取得	不可	参照先テーブルの列を引き出せる
複数テーブルでの共有	グローバルchoiceなら可	テーブルを共有するため自然に可能
Power Appsでの扱い	文字列としてシンプルに扱える	レコード型として扱う（少し複雑）
複数選択	対応（内部構造が複雑化する）	many-to-many専用テーブルが別途必要

判断の基準はシンプルです。「選択肢の横に追加情報を持たせる必要があるか」で決めれば問題ありません。担当者名だけ表示できれば十分であればchoiceで足ります。担当者のメールアドレスや部署コードも後から使いたい場合は、lookup列を選びましょう。

なお、choice列の複数選択（Multi-Select Choice）については注意が必要です。SharePointの複数選択列と似た感覚で使えそうに見えますが、内部的にはテーブル化された複雑な構造になっており、Power AutomateやAPIでの操作が一段階難しくなります。用途がシンプルな場合は避けることをおすすめします。

primary columnを先に設計する——後から変えられない唯一の制約

ルックアップ列を作成する前に、参照先テーブルの「primary column」を確認・設計することが最も重要なステップです。これがSharePointのルックアップ列と最も大きく異なる点です。

primary columnとは、テーブル作成時に設定する「Name」フィールドにあたる列のことです。Dataverseのルックアップ列は、ドロップダウンに参照先テーブルのprimary columnだけが表示されます。SharePointのルックアップ列では表示する列を後から自由に変更できますが、Dataverseではこの変更ができません。

たとえば、担当者テーブルのprimary columnが「氏名」に設定されていれば、ドロップダウンには氏名が表示されます。しかし「社員番号」に設定されていれば、社員番号しか表示されません。そしてprimary columnは、テーブル作成後に変更することができないという制約があります。

ルックアップ列を設定する前に、参照先テーブルの「ドロップダウンで何が表示されるか」を必ず確認しておきましょう。もし既存のテーブルのprimary columnが意図した列でない場合は、ルックアップ列を作成する前にテーブル構造を見直す必要があります。

primary columnの確認方法は、make.powerapps.comで対象テーブルを開き、「列」タブの一覧で「Primary」アイコンがついている列を確認します。デフォルトでは「Name」という名前のテキスト列がprimary columnになっています。テーブルを作成する段階で、この列名と入力内容を「ドロップダウンに表示したい値」に合わせて設計しておくことが大切です。

ルックアップ列の作成手順

実際にルックアップ列を作成する手順を説明します。慣れれば3〜5分ほどで完了します。

make.powerapps.com を開き、左メニューの「テーブル」から子テーブル（ルックアップ列を追加する側のテーブル）を選択します
「列」タブを開き、「新しい列」をクリックします
「データ型」のドロップダウンから「Lookup（ルックアップ）」を選択します
「Related Table（関連テーブル）」で参照先のテーブルを選択します
列の表示名を入力し、「保存」をクリックして列を作成します

ひとつ注意点があります。「Related Table」の選択肢に「Customer」という項目が表示されます。これはAccountテーブルとContactテーブルを統合した特殊な複合ルックアップ列を作るための設定で、通常のユーザーが使う場面はほとんどありません。一般的なルックアップ列を作る場合は「Customer」を選ばないようにしてください。

自動生成されるリレーションを理解しておく

ルックアップ列を作成すると、Dataverseが裏側でmany-to-one（多対一）のリレーションを自動生成します。「テーブル」→「リレーションシップ」タブを開くと、作成されたリレーションを確認できます。参照先テーブル（親テーブル）側でも、one-to-manyのリレーションとして表示されます。

SharePointにはこのようなリレーションの概念がありませんでしたが、Dataverseではテーブル間のリレーションが明示的に管理されています。これにより、データの整合性を担保するための設定が細かくコントロールできるようになります。

リレーション動作（Relationship behaviors）の設定

リレーションには「動作（behaviors）」という設定があります。基本的にデフォルトのままで問題ありませんが、知っておくと設計時の判断に役立ちます。

設定名	動作の内容
Referential（デフォルト）	親レコードを削除しても子レコードは残る。ルックアップ列の値がnullになる
Referential, restrict delete	子レコードが存在する間は親レコードを削除できない
Parental	親レコードを削除すると子レコードも連動して削除される（カスケード削除）

Referential（デフォルト）は最も安全な設定です。親レコードを削除しても子レコードが残るため、データが意図せず失われるリスクがありません。

「Referential, restrict delete」を選ぶと、子レコードが存在する間は親レコードを削除できなくなります。データの整合性を厳密に保ちたい運用では、この設定が安全です。たとえば「担当者テーブルの担当者を削除したとき、その担当者が紐づいている案件レコードが残ってしまう」という状況を防げます。

「Parental」は親レコードを削除すると子レコードも連動して削除されるカスケード削除です。意図せずデータが大量に消えるリスクもあるため、データ構造を十分に理解した上で使うようにしましょう。初心者のうちはデフォルトの「Referential」から始めることをおすすめします。設定の変更は、リレーションを開いて「General」タブから行えます。

Power AppsとPower Automateでの注意点

ルックアップ列はPower Appsで操作するとき、choice列とは異なる扱いになります。いくつか代表的なパターンを押さえておきましょう。

自動生成アプリを使う場合は、ルックアップ列のComboBoxが自動的に設定されるため、特別な操作は不要です。まずは自動生成でアプリを動かしてみて、動作を確認するのがおすすめです。詳細はDataverseのテーブルから30秒でアプリを自動生成する方法をご覧ください。

Patch関数でルックアップ列に値を書き込む場合は、テキスト文字列ではなくレコード型で渡す必要があります。たとえば次のような書き方になります。

Patch(
  案件テーブル,
  Defaults(案件テーブル),
  {担当者: LookUp(担当者テーブル, ID = ComboBox1.Selected.ID)}
)

Filter関数でルックアップ列を使ってフィルターする場合は、ルックアップ列のフィールドを参照する記述が必要です。たとえば担当者テーブルのIDでフィルターする場合は、Filter(案件テーブル, 担当者.ID = ComboBox1.Selected.ID)のような書き方になります。

Power AutomateでDataverseのルックアップ列をODataフィルターで使う場合は、システム列名に_valueサフィックスを付ける特殊な書き方が必要です。列のシステム名（スキーマ名）はmake.powerapps.comの「列」タブで確認できます。

列型全体の整理はDataverseの列データ型まとめをご覧ください。テーブル作成の流れはSharePointと違うDataverseのテーブル作成フローも合わせて参考にしてください。

まとめ

Dataverseのルックアップ列は、choice列では実現できない「参照先テーブルのデータを丸ごと扱う」リレーション設計を可能にします。設計で最も重要なのは、ルックアップ列を作成する前に参照先テーブルのprimary columnを固めることです。この設定は後から変えられないため、ドロップダウンに何を表示したいかを先に決めてから着手するようにしましょう。

リレーション動作の設定や、Power Appsでのレコード型の扱いなど、SharePointと異なる概念が出てきますが、一つひとつ順番に理解していけば難しくありません。最初は自動生成アプリでルックアップ列の動作を確認しながら、少しずつカスタマイズを重ねていくのがおすすめです。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。環境・テーブル・列型・ルックアップまで、SharePoint経験者の視点で一通り確認できます。

Dataverseの標準テーブルとは｜最初から大量にあるテーブルの正体と触ってはいけないもの

Wed, 25 Mar 2026 17:30:33 GMT

Dataverseを初めて開いたとき、テーブル一覧に見覚えのないテーブルが30〜40個並んでいて戸惑う方は多いと思います。これらは「標準テーブル（Standard Tables）」と呼ばれるシステムテーブルで、Dataverseが最初から用意しているものです。自分で作ったわけでも、誰かが追加したわけでもありません。

私も最初に見たとき、「Account」「Contact」「Activity」といった見慣れない英語のテーブルが大量に並んでいて、何が何だかわかりませんでした。誤って標準テーブルに列を追加しようとしたこともあります。この記事では、標準テーブルとは何か、どれが触っていいもので、どれを避けるべきかを整理します。

標準テーブルとは何か

Dataverseの環境を作成すると、最初から大量のテーブルが存在しています。これが標準テーブルです。SharePointでサイトを作ったとき、「サイトページ」「ドキュメント」「カレンダー」などが最初から存在しているのと似た感覚ですが、Dataverseの場合はその数がはるかに多く、またシステムとしての役割も複雑です。

標準テーブルは主に、Microsoft Dynamics 365やModel-driven appsが使うために用意されています。これらのアプリが顧客情報・連絡先・活動履歴などを管理するためのデータ構造として、あらかじめ定義されているのが標準テーブルです。

代表的な標準テーブルとその用途は以下の通りです。

テーブル名（英語）	表示名	主な用途
Account	取引先企業	顧客・取引先の企業情報を管理するためのテーブル
Contact	取引先担当者	個人の連絡先情報を管理するテーブル
User	ユーザー	Dataverse環境にアクセスするユーザーの情報
Activity	活動	メール・電話・タスクなどの活動履歴の親テーブル
Team	チーム	ユーザーをグループ化して権限管理するテーブル
Business Unit	部署	組織の部門・部署構造を表すテーブル
Role	セキュリティロール	アクセス権限の役割定義テーブル

Canvas appを独自に作るだけが目的であれば、これらの標準テーブルはほとんど使いません。Dynamics 365との連携や、Model-driven appsの構築を前提とした場合に意識する必要が出てきます。

カスタムテーブルとの見分け方

テーブル一覧でカスタムテーブル（自分で作ったテーブル）だけを表示したい場合は、一覧上部のフィルターで「カスタム」を選択すると絞り込めます。普段の作業はこのビューを使えば、標準テーブルに混乱させられることなく作業できます。

フィルターを使わずに見分ける場合は、以下の3点を確認するのが目安になります。

スキーマ名のプレフィックス：カスタムテーブルのスキーマ名には「cr52a_」「abc_」のようなパブリッシャープレフィックスが付きます。標準テーブルにはプレフィックスがなく、「account」「contact」のようにシンプルな名前です
Managed（マネージド）の表示：テーブルの詳細を開いて「Managed solution」と表示されているものは、Microsoftが管理しているシステムテーブルです
テーブルプロパティの制限：標準テーブルの一部は、削除や特定のプロパティ変更が制限されています。カスタムテーブルは自由に変更できます

Dataverseの環境の概念や、環境によって標準テーブルのセットがどう変わるかについては、Dataverseの「環境」とは何かで詳しく解説しています。合わせて確認してみてください。

標準テーブルは触っていいのか

結論からいうと、「基本的には自分でカスタムテーブルを作れば十分」です。ただし「触ってはいけない」という意味ではありません。標準テーブルは用途に応じて3種類に分けて考えると整理しやすいです。

積極的に活用できる標準テーブル

「Account（取引先企業）」と「Contact（取引先担当者）」は、カスタマイズが許可されており、列を追加することもできます。顧客管理や案件管理をDataverseで行う場合は、これらの標準テーブルをベースにカスタマイズするのが推奨アプローチです。

特にDynamics 365との連携を前提にする場合は、AccountやContactに独自列を追加してデータを管理するのが一般的です。一から作ったカスタムテーブルでは連携がうまくいかないケースもあるため、将来的にDynamics 365の導入が視野にある場合は標準テーブルの活用を検討する価値があります。

参照には使えるが変更は慎重に

「User（ユーザー）」「Team（チーム）」「Business Unit（部署）」などは、Power Appsで「ログインユーザーの情報を引き出す」「担当者を選択肢に表示する」といった用途でよく参照します。ただし構造を変更すると、既存のアプリやフロー、セキュリティ設定に影響が出る可能性があるため、列の追加などは慎重に行いましょう。

触らなくていいシステムテーブル

Managedと表示されているテーブルや、名前から明らかにシステム内部で使われているとわかるテーブル（例：「Suggestion」「Audit」「Role」など）は基本的に変更しないほうが安全です。誤って構造を変えると、Dataverse内部の処理やModel-driven appsの動作に影響する可能性があります。

SharePointに例えるなら、サイトページライブラリやワークフロー履歴リストを直接触らないのと同じ感覚です。業務データは自分のカスタムリスト（カスタムテーブル）で管理するのが基本です。

カスタムテーブルを作成したときに知っておくこと

自分でテーブルを作成すると、スキーマ名にパブリッシャープレフィックス（例：cr52a_）が自動的に付きます。これは環境を作成したときに設定されたプレフィックスで、標準テーブルと自分のテーブルを区別するためのものです。

このプレフィックスは、Power AutomateでDataverseのテーブルを操作するときや、APIでアクセスするときに使います。画面上の「表示名（Display Name）」はプレフィックスなしで見られるため、日常の操作では気にする必要はありませんが、数式やフローを書くときに意識しておくと混乱しません。

たとえば「案件テーブル」という表示名のテーブルのスキーマ名が「cr52a_案件テーブル」になっているという具合です。make.powerapps.comのテーブル設定画面でスキーマ名を確認できます。

カスタムテーブルの作成フローについてはSharePointと違うDataverseのテーブル作成フローで詳しく解説しています。SharePointリストとの設計の違いも含めて確認してみてください。また、テーブルを作成した後はすぐに自動生成アプリで動作確認するのがおすすめです。手順はDataverseのテーブルから30秒でアプリを自動生成する方法をご覧ください。

まとめ

Dataverseを開いて大量のテーブルに驚いたとしても、それらのほとんどは標準テーブルであり、Canvas appを作るだけであれば直接関わる必要はありません。テーブル一覧は「カスタム」フィルターで絞り込んで使うのが日常の操作として正解です。

標準テーブルを知っておくことには、将来の設計上の意味があります。「Account」「Contact」は業務要件によっては積極的に活用できます。また、Dynamics 365との連携を前提にするなら、最初から標準テーブルを使う設計が重要になります。

「触ってはいけないテーブル」を見極める目安は、Managedかどうかとパブリッシャープレフィックスの有無を確認するだけで十分です。これを知っておけば、大量のテーブルに惑わされることなく、自分が必要なカスタムテーブルだけに集中して作業を進めることができます。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。環境・テーブル設計・列型まで、SharePoint経験者の視点で整理しています。

SharePointと違うDataverseのテーブル作成フロー。設計してから建てる順番を知っておこう

Wed, 25 Mar 2026 17:30:31 GMT

SharePointリストは作ってから列を追加していく設計ですが、Dataverseのテーブルは先にすべての列を設計してからCreateボタンを押す設計です。この順番の違いを知らないまま触ると、画面の構成からして戸惑います。

2つの設計思想の違い

SharePointリスト：作ってから育てる

SharePointでリストを作るときは、まず空のリストを作ります。最初はタイトル列だけがある状態で保存され、そこから列を一つずつ追加していきます。後から列の種類を変えたり、削除したりするのも比較的自由です。

Excelで新しいシートを作って、後から列ヘッダーを追加していく感覚に近いです。まず器を作って、中身を後から整えていくイメージです。

Dataverseテーブル：設計してから建てる

Dataverseのテーブル作成画面を開くと、列名と型を入力するフォームが並んでいます。ここですべての列を定義してからCreateボタンを押す流れです。Createを押すまでテーブルは存在しません。

料理でいうと、SharePointは冷蔵庫にあるものを見ながら何を作るか決めるスタイル、Dataverseは最初にレシピを完成させてから買い物に行くスタイルです。どちらが良い悪いではなく、設計の文化が根本的に違います。

もちろん、Createした後に列を追加することは可能です。ただし、タイムゾーン設定のように後から変更できない項目がいくつかあります。その代表例が日付列のタイムゾーン設定で、詳しくはDataverseの日付タイムゾーン設定の記事でまとめています。後悔しないように、設計段階で考えきっておくほうが確実です。

テーブル作成時に選べる3つの方法

make.powerapps.com でテーブルの新規作成を選ぶと、作成方法を選択する画面が表示されます。

Add columns and data（手動）

列名・データ型・必須かどうかなどを自分で設定していく方法です。設計の自由度が最も高く、どんなテーブルでも作れます。初めてDataverseを触る方にはこの方法が一番把握しやすいです。列を一行ずつ定義してCreateを押すシンプルな流れです。

Copilotで作成（自然言語）

どんなテーブルが欲しいかを日本語で説明すると、AIが列の候補を提案してくれます。たとえば申請者・申請日・申請内容・承認者・ステータスを管理する申請管理テーブルと入力すると、それらしい構成を自動で提案してくれます。

ゼロから考えるのが面倒なときのたたき台として便利です。ただしそのまま使えることは少なく、不要な列を削除したり、型を修正したりする作業が必ず発生します。提案を参考にしながら手直しする使い方がおすすめです。

高度なプロパティから作成

スキーマ名（システム名）やオーナーシップタイプなどの詳細設定が必要な場合に使います。特別な理由がなければ最初は不要です。

設定を慎重にすべき3つの項目

Primary column（プライマリ列）——後から変更できません

SharePointリストのタイトル列に相当するのがプライマリ列（Primary column）です。ルックアップ列（他のテーブルを参照する列）を設定したとき、ドロップダウンに表示される名前がこのプライマリ列の値になります。

たとえば社員テーブルのプライマリ列が社員IDだと、申請テーブルのルックアップで社員を選ぶドロップダウンに社員IDの数字が並んでしまいます。氏名にしておけば、ドロップダウンに名前が表示されて直感的に使えます。

プライマリ列の設定はテーブル作成後に変更できないため、最初にしっかり決めておく必要があります。そのテーブルを参照するときに何の値を見せたいか。この一点を先に考えておきましょう。また、プライマリ列はテキスト型のみで、数値型や日付型には変更できません。

Plural name（複数形名）——Power Apps上の表示に影響します

テーブル名の複数形を設定する項目です。Power Appsの数式エディタや管理画面のあちこちで、テーブルは複数形の名前で表示されます。

英語のテーブル名であれば自動で適切な複数形が生成されます。しかし日本語のテーブル名（例：申請管理）では、英語変換が変な形になることがあります。作成前に確認して、わかりにくい場合は修正しておきましょう。後から変更することも可能ですが、既にフローやアプリで参照している場合は影響が出ることがあります。

Schema name（スキーマ名）——API接続時に使います

テーブルのシステム内部名称です。作成環境のパブリッシャープレフィックス（例：cr52a_）が自動で付きます。たとえば申請管理テーブルのスキーマ名は cr52a_shinseikanri のようになります。

Power Automateの行の追加アクションやDataverseコネクタを使うとき、このスキーマ名がドロップダウンに表示されます。普段の開発では気にする必要はほぼありませんが、APIで直接Dataverseにアクセスするケースでは意識する場面があります。

列を設計するときに決めておくべきこと

テーブルを作る前に、以下を整理しておくと作業がスムーズになります。

確認項目	検討内容
プライマリ列に何を入れるか	ルックアップで参照されたとき何を表示したいか
日付列のタイムゾーン設定	日付のみ管理する列はTime Zone Independentを選ぶ（後から変更不可）
テキスト列の文字数	デフォルト100文字。SharePointの255文字に合わせるなら変更が必要
選択肢列の選択肢	後から追加は可能だが、削除は使われているとできない
必須項目	Required設定は後から変更できるが、初期設計で決めておくとデータ品質が安定する

SharePointリストは列を後から追加・変更するのが容易で、その感覚のまま来るとDataverseの制約に驚くことがあります。一度テーブルを作り直すのは手間なので、設計に少し時間をかける価値はあります。

SharePointリストとの設計フローの違いまとめ

作業の順番を並べると次のようになります。

手順	SharePointリスト	Dataverseテーブル
①	空のリストを作成・保存	テーブル名・プライマリ列を設定
②	必要な列を一つずつ追加	すべての列（名前・型・設定）を入力
③	保存して即使用可能	Createを押してテーブルが作成される
④	後から列を追加・変更・削除	列の追加は可能。一部の設定は変更不可

実際にSharePointリストのCRUD操作に慣れている方が、Dataverseで同様の操作をする際の違いについてはSharePointリストのデータを読み書きする記事もあわせて参考にしてください。また、テーブルを設計した後のフォームでのデータ入力についてはフォームコントロールの記事で詳しく解説しています。

まとめ

SharePointは作ってから列を追加する設計、Dataverseは先に列を設計してからCreateを押す設計です
プライマリ列はルックアップの表示名になります。作成後に変更できないため、最初に何を入れるか決めておきましょう
日付列のタイムゾーン設定やテキスト列の文字数など、後から変更できない・しにくい設定が複数あります
Copilotの自動生成はたたき台として便利ですが、そのまま使わず必ず手直しをしましょう

最初は設計ファーストという感覚が慣れないかもしれませんが、慣れてしまえばむしろきちんと設計してから作る習慣が身につきます。SharePointリストを作る前にもExcelで列を整理するようになったら、Dataverse的な設計思想が自然に身についてきたサインかもしれません。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

Dataverseのテキスト列はデフォルト100文字｜SharePointに合わせる設定方法

Wed, 25 Mar 2026 17:30:34 GMT

DataverseのテキストはSharePointとデフォルト文字数が違います。知らないままデータを入力し始めると、100文字を超えた分がいつの間にか切れています。

SharePointの一行テキスト列は作った直後からデフォルト255文字で使えます。ところがDataverseの単一行テキストはデフォルト100文字です。移行前の社内システムや既存のSharePointリストにある住所・備考・商品名など、100文字を軽く超えることがある項目をそのままDataverseに持ってくると、静かにデータが欠けます。声を大にして言いたいのはこの一点です。

単一行テキスト：デフォルト100文字、最大400文字

SharePointとの比較

並べて確認するとこうなります。

比較項目	SharePoint 一行テキスト	Dataverse 単一行テキスト
デフォルト文字数	255文字	100文字
変更できる上限	255文字（固定）	400文字まで拡張可
変更タイミング	設定なし（常に255）	列作成前後どちらでも変更可

SharePointは255文字から変えることができない代わりに最初から255文字が保証されていますが、Dataverseは自分で設定する必要があります。自由度が高い分、設定漏れのリスクがあります。

100文字で足りなくなる実例

どんな項目が100文字を超えるか、イメージしにくい方向けに実例を挙げます。

住所（都道府県+市区町村+番地+マンション名で100文字を超えることがある）
備考欄（自由入力なので100文字制限は短い）
商品名・品番（長い正式名称が入る業種では超えることがある）
URL（https://で始まる長いリンクは簡単に超える）

自分が最初にDataverseでテーブルを作ったとき、住所列を100文字のままにして後から入力データが途中で切れているのに気づきました。すでに数十件入力した後で、列の文字数を変更してもデータは自動では修正されないため、ひとつひとつ確認する羽目になりました。テーブル設計の段階で変えておけばよかったと心底思いました。

文字数を変更する手順

列の文字数は作成前でも作成後でも変更できます。手順は以下です。

make.powerapps.com でテーブルを開く
対象の列をクリックして列の編集画面を開く
Advanced optionsを展開する
Maximum character countの値を変更する（例：255や400）
保存する

既存データがある状態で文字数を増やす変更は問題ありません。反対に、文字数を減らす方向の変更は既存データが制限を超えていると保存できないことがあるので注意してください。

複数行テキスト：デフォルト1000文字、最大100万文字

複数行テキストはデフォルト1000文字で、SharePointの複数行テキストの約65,000文字と比べてもデフォルトで十分な容量があります。議事録・自由記述欄・メモ欄など、長文が入る可能性がある列はこちらを選びましょう。

単一行テキストと複数行テキストの使い分けのポイントは、改行を含むかどうかです。住所や短い備考は単一行で十分ですが、議事録や詳細説明のように段落や改行が含まれる可能性がある項目は複数行を選んでおきます。後から単一→複数に変更するとデータの再確認が必要になるので、設計段階で判断しておくほうが楽です。

比較項目	SharePoint 複数行テキスト	Dataverse 複数行テキスト
デフォルト文字数	6列（設定なし）	1000文字
最大文字数	約65,000文字	100万文字
改行の扱い	対応	対応

推奨設定：用途別の文字数選択の目安

テーブルを作るときに列ごとに文字数を考えるのは最初は手間に感じますが、慣れてくると5秒で判断できるようになります。迷ったときはこの表を参考にしてください。

列の用途	推奨設定	理由
氏名・担当者名	100文字（デフォルト）	通常は50文字以内。デフォルトで十分
住所	255文字以上	都道府県+市区町村+番地で100文字を超えることがある
商品名・品番	255文字	長い正式名称が入る可能性を考慮
URL・リンク	400文字（最大）	長いURLは200文字を超えることもある
備考・メモ（短め）	255〜400文字	単一行テキストで対応可能な範囲
議事録・詳細説明	複数行テキスト	改行が含まれる。1000文字デフォルトで十分

住所やURLを扱う列は最初から400文字にしておいても特に問題はありません。上限を大きくすることでストレージが圧迫されるわけではないので、迷ったら大きめにしておくほうが後悔が少ないです。

Power Appsで入力前に文字数チェックする方法

アプリ側でテキスト入力欄に文字数制限のフィードバックを出すには、Len関数を組み合わせます。たとえば入力欄の下にカウンター表示を置いたり、文字数が上限を超えたらSubmitボタンを無効化したりする実装が一般的です。

// 入力残り文字数を表示する数式の例
255 - Len(TextInput1.Text)

// 文字数超過でSubmitボタンを無効化する数式の例
Len(TextInput1.Text) > 255

Len関数の使い方についてはLen関数の記事でくわしく解説しています。またDataverseのテーブル作成フローの記事ではテーブル設計全体の流れをまとめているので、文字数設定もあわせて設計段階で確認してみてください。

SharePointとDataverseの列の違い全体についてはDataverse列データ型まとめの記事に対応表があります。テキスト型以外の型も確認したい場合はそちらをどうぞ。

まとめ

Dataverseの単一行テキストはデフォルト100文字です。SharePointの255文字とは異なります
最大400文字まで拡張できます。列の作成前後どちらでも変更可能です
住所・URL・備考など、100文字を超える可能性がある列は設計段階で文字数を変更しておきましょう
複数行テキストはデフォルト1000文字。議事録や自由記述欄はこちらを選びます

列を一本作るたびに文字数を確認するのは最初は面倒に感じるかもしれませんが、後からデータが欠けていることに気づくほうがはるかに大変です。テーブル設計の習慣として身につけておきましょう。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

DataverseのYes/NoはSharePointのYes/Noと別物｜Boolean判定できない理由

Wed, 25 Mar 2026 17:30:32 GMT

SharePointリストのYes/No列と同じ感覚でDataverseのYes/No列を使おうとすると、Power Appsの数式やPower Automateのフロー条件で動かないケースに当たります。原因は、SharePointのYes/NoはBoolean型（true/false）ですが、DataverseのYes/Noは選択肢型（Choice）だからです。

名前が同じだけに混乱しやすいです。この記事でその違いと正しい扱い方を整理します。

SharePointのYes/No＝Boolean、DataverseのYes/No＝Choice

SharePointのYes/No列

SharePointリストのYes/No列は、内部的にBoolean型（真偽値）で保存されます。値は trueまたはfalseの2択です。

Power Appsから参照するとき、チェックボックスの状態を If(ThisItem.承認済み, “済”, “未”) のように直接Boolean判定できます。Power Automateフローの条件式でも is equal to true という書き方が自然に機能します。

DataverseのYes/No列

一方、DataverseのYes/No列は、内部的にはChoice型（選択肢型）として扱われます。「Yes」と「No」という2つの選択肢が定義された選択肢列です。

そのため If(ThisItem.承認済み, “済”, “未”) という書き方では動きません。選択肢列に対してBoolean判定（true/false直接比較）をしているためです。Power Appsから見ると、この列はBoolean値ではなくOptionSetValueとして認識されます。

実際にこの詰まりポイントに当たって、「なぜSharePointと同じように書いたのに動かないんだ」と30分ほど悩んだことがあります。結論を知ってしまえば単純ですが、知らないと原因にたどり着けません。

Power Appsでの正しい扱い方

選択肢の値を比較する

DataverseのYes/No列を条件分岐に使うには、Boolean直接判定ではなく選択肢の値との比較が必要です。以下のような書き方をします。

// ❌ 動かない（SharePoint式の書き方）
If(ThisItem.承認済み, "済", "未")

// ✅ 動く（Dataverse Yes/No列の正しい書き方）
If(ThisItem.承認済み = 'テーブル名（承認済み）'.Yes, "済", "未")

‘テーブル名（承認済み）’.Yes の部分は、Power Apps上でEnum（列挙型）として扱う記法です。実際には候補が自動補完で表示されますので、入力中に候補から選べば正しく書けます。

Filter関数での使い方

ギャラリーや変数に絞り込んだデータをセットするときも同様です。

// ❌ 動かない
Filter(案件管理, 承認済み = true)

// ✅ 動く
Filter(案件管理, 承認済み = '案件管理（承認済み）'.Yes)

Filter・Search・LookUpの使い分けの記事でも触れていますが、列型によって条件の書き方が変わる点は意識しておきたいです。また、If・Switchの使い分けについてはPower AppsのIfとSwitch記事も参考にしてください。

Power Automateフローでの正しい扱い方

フローの条件式での注意点

Power Automateでも同様に、DataverseのYes/No列はBoolean値ではなく整数値（0または1）として取得されます。

Yes（選択されている）= 1
No（選択されていない）= 0

フローの条件ステップで「is equal to true」と書くと動きません。代わりに「is equal to 1」と書きます。トリガー条件（ODataフィルタークエリ）を使ってYes/Noで絞り込む場合は以下のようになります。

// Dataverse Yes/No列でYesのレコードだけ取得するODataフィルター
承認済み eq true

// または整数で書く場合
承認済み eq 1

ODataフィルタークエリの書き方はDataverseとSharePointで微妙に異なります。Power Automateのトリガー条件の記事もあわせて参考にしてください。

フローでのデバッグ

「条件に合致するはずなのに動かない」場合は、Composeアクションで列の生の値を確認するのが手っ取り早いです。0か1かtrueかfalseか、実際の型を目で確認してから条件式を書くと詰まりにくくなります。

なぜDataverseはBoolean型にしなかったのか

DataverseがYes/No列をChoiceとして実装しているのは、「Yes」と「No」のラベルをカスタマイズできるようにするためです。たとえば「承認済み」と「未承認」、「有効」と「無効」のように表示名を変えられる柔軟性があります。

Dataverseはもともと大規模なビジネスアプリ向けのデータストアとして設計されており、選択肢型での実装のほうがメタデータとして管理しやすいという背景もあります。SharePointの単純なBoolean型より複雑になりますが、その分自由度は高いです。

まとめ

DataverseのYes/No列はSharePointのYes/No列と同名ですが、内部型が異なります（SharePoint＝Boolean、Dataverse＝Choice）
Power Appsでは If(field, …) の直接Boolean判定は動きません。 field = ‘列名の列挙型’.Yes の形式で比較します
Power Automateフローでは整数値（1 = Yes、0 = No）として扱われます
ODataフィルタークエリでは列名 eq true または列名 eq 1 の形式を使います

DataverseとSharePointの違いはこのYes/No列に限らず列型全体で起きます。詳細はDataverseの列データ型まとめで解説しています。

Dataverseの全体像はDataverseをSharePoint経験者向けに完全解説にまとめています。

Power Apps のデータソースでExcelの評価をちょっとだけ見直した件

Sat, 27 Jul 2024 21:02:25 GMT

一昔前まで Power Apps のデータソースに Excel を使うのはタブー視されていましたが、ここ最近になってExcelも場合によってはありと見直すようになりました。

本格的な開発にはやっぱりリスト/Dataverse一択になってしまうのですが、どうして Excel への評価を見直すことになったか紹介します。

Excelの進化

Excel を Power Apps のデータソースとして使うのは絶対に避けなければいけない理由が、過去にはいくつか存在しました。

しかし、2021年4月以降の数回のアップデートにより、Excelは進化を遂げています。

委任が一切できなかった▶一部は委任できるようになっている

Excel をデータソースにすると一切の関数が委任不可でした。

委任できないということは、どんなに頑張っても2,000件までしかデータが扱えなかったということです。

しかし今では一部関数は委任問題をクリアするようになっています。

同時編集できなかった▶同時編集できるようになっている

Excel をデータソースにしたアプリを使う場合、誰かがアプリを開いている時に別の場所で同時にアプリを起動するとエラーが起きていましたが、それが今はクリアになっています。

また、Excelが開きっぱなしだとアプリ側でパッチ処理がエラーになる（Submit Formも同様）事象がありましたが、これも無くなっています。

関数が入っているとエラー▶エラーにならなくなった

セルに関数（＝A1+B1など）が入っているとアプリのエラーを引き起こしていましたが、それも無くなりました。

変更履歴が残らなかった▶Excelに履歴が残るようになった

誰がいつどんな変更を加えたか、アプリから変更を加えたExcelに履歴が残るようになりました。

コツはコネクションを使うこと

ただし、上記のExcel進化を体感するためには、キャンバスアプリからExcel Online（Business）コネクタ、またはOneDrive for Businessコネクタを使ってExcelと連携しなくてはいけません。

データの追加から接続する必要がある

アプリを新規作成する際にデータで開始するから始めてしまうと、内部で古いExcelのコネクションを使ってしまうようで、進化する前のポンコツExcel機能しか利用できません。

外部データを選択、は使わないように。

Excel Online(Business)とOneDrive for Businessの違い

Excel Online（Business）コネクタ
OneDrive for Businessコネクタ

この2つのコネクタのどちらかを利用しなければいけないのはわかったけど、2つの違いが気になると思います。

2024年7月現在、どちらのコネクタを利用するかで、進化版Excelの機能に違いがあることがわかっています。

	Excel Online (Business)	OneDrive for Business	データで開始した場合
Search関数	1列のみ。委任可能。	複数列。委任可能。	1列のみ。委任不可。
同時編集	可能	不可	不可
関数を使ったセル	エラー	表示可能	エラー

Search関数が委任可能な点は見逃せないでしょう。

この点においてはリストよりも優れていますし、Search以外でも、リストでは委任不可でもExcelで委任可能な関数は存在すると思われます。

それでもExcelが主役のデータソースにはならない理由

地味に進化する（そしてそれが公式ドキュメントに載っていないという）Excelですが、それでも私は本番開発においてExcelを使うことはこの先ないでしょう。本番開発においてはSharePoint Listsの活用か、可能であればDataverseを選ぶことをおすすめします。

その理由はこちらです。

ユーザー列が存在しない

Excelにはユーザー列が存在しないため、入力者情報の取り扱いが面倒です。

リストやDataverseは入力した人の氏名・アドレス・所属部署などEntra IDに紐づく情報を抽出できますが、Excelにはそれがありません。

画像の取り扱いが不明

これは私が未検証なのが理由ですが、Excelにおける画像の取り扱いが不明です。

できるのかもしれませんし、できないかもしれません。

Power Automateとの相性が悪い

Power AutomateとExcel Onlineは非常に相性が悪いです。

Power AutomateでExcel Onlineに何らかの変更をかけた場合、Excel内部でその情報が反映されるまでにラグ（遅延）が発生します。

そのため、AutomateのApply to eachアクションで繰り返し同じ処理をExcel Onlineに施す場合、遅延回避の処理を入れておかないと新しいデータが古いデータを上書きしてしまい、正しく処理されない事象が発生してしまうのです。

リストやDataverseであれば、Automateの処理は即座に反映されるため、ラグを心配する必要なく使えます。

参考までに、このラグは1つのデータに対しておよそ40秒〜50秒ほどあります（2024年7月現在）。

例えば、10人分の日報をApply to eachでExcel Onlineに転記し、1つずつPDFに変換しようとする場合、遅延回避のアクションを組み込むと約10分弱かかってしまうというわけです。

Excelのご利用は計画的に

一部のネット情報や動画では、Excelは絶対に使ってはならないデータソースと訴えるものがありますが、それは2021年4月以前のExcelを触った人か、もしくはコネクションの仕様を知らない人でしょう。

Excelはその後も地味に進化を続けていて、全く非推奨とまではいわないレベルになっていると感じます。

ただし最後に述べたように、本番開発において私がExcelデータソースを利用することはありませんし、開発に慣れた人も、今更Excelが進化していると知ったところで、使い勝手のいいリスト／Dataverseから乗り換える理由は見当たらないでしょう。

Excelは個人で使うアプリ、練習用アプリで気軽に使うデータソースとしてとどめ、リストもしくはDataverseに少しでも早く慣れるといいでしょう。

SharePoint ListsをPower Appsのデータソースとして活用する具体的な実装については、Power AppsでSharePointリストのデータを読み書きする記事で詳しく解説しています。あわせて参考にしてください。

どのデータソースを選ぶかは、アプリの規模・ユーザー数・予算によって変わります。Power Apps開発の全体マップ記事では、データソース選びも含めた開発全体のロードマップを解説しています。

Power Apps開発をAIで加速するテクニック

Sat, 12 Oct 2024 10:25:56 GMT

Power Apps開発にAIをうまく活用すれば、調べる時間を大幅に短縮できます。ここでは私が実際に使っているAIへの具体的な質問テクニックを紹介します。

AIへの質問テクニック

有名どころのAIを使えばOK

ChatGPT、Gemini、Copilot、Perplexity、Gensparkなど巷はAIで溢れかえっていますが、耳にしたことがあるAIを使えばいいです。

個人的にはChatGPT有償版をずっと使っています。レスポンス速度や機能面で無料版より使いやすいです。

有償版はちょっと・・・という方はGeminiがいいですね。無料で高性能バージョンのAIが使えます。

ただし、こちらのGeminiではなく、開発版のこちらのGeminiじゃないと高性能AIは使えないので注意しましょう。

具体的な質問＞あいまいな質問

AIには可能な限り具体的な質問を投げます。

✕）Power Appsでボタンを押して確認画面を出すにはどうする？

◯）Power Appsでユーザーが削除ボタンを押下した際、誤操作防止と意思確認のために確認画面をポップアップ表示したい。どう実装する？

あいまいな質問にはあいまいな回答が返ってきますし、具体的な質問には具体的な回答が返ってきます。

ただし、使用するAI性能によってはあいまいな質問でも通ることがあります。

ChatGPT有償版はあいまいな質問でも回答がきた

ChatGPT有償版（4o）は求めていた回答を一発で出しました。さすがです。

一方、無料のCopilotはというと。

Copilotは残念な結果

あいまいな質問には的外れな回答が来ました。

Copilotに具体的な質問をしたらどうなったかというと、

Copilotの限界か？

一応やりたいことは実現できそうな回答ですが、私にとっては90点な内容でした。

いつも私がポップアップ機能を作るとき、Set関数（グローバル変数）ではなくUpdateContext関数（ローカル変数）を使いますが、CopilotはSet関数を提示していますね。

その点ChatGPT有償版は、最初からUpdateContext関数での回答です。さすがです。

やりたいことの流れを説明する

その質問に至るまでの過程を細かくAIに伝えると、こちらの意図を汲み取った回答を返してくれやすくなります。

例：

日報提出アプリを作ろうとしている、GalleryのItemsにリストを設定して一覧表示させた、一覧の項目をクリックしたら画面が切り替わって詳細が表示されるようにしたい。何をどうしたらいいか？

スクリーンショットを使う

エラー発生時、式をコピペしてAIに丸投げして質問するのはよく知られています。

私はエラー箇所をスクリーンショットしてAIに貼り付けてどういうこと？と一言だけ聞きます。

WindowsでChatGPTを使っている場合、Shift+Win+Sで任意の範囲で画面切り取り（スクリーンショット）ができ、画像保存せずそのままChatGPTのチャット欄にCtrl+Vで画像アップロードが可能です。

Power Appsはエラーメッセージの内容はコピーできないため、スクリーンショットが最も効率的かつ入力ミスもないのです。

ただし、これもやはりAIの種類や料金プランによって画像貼り付けができないものがあるので注意しましょう。

無料版で先におすすめしたGeminiは、一度Googleドライブに画像を保存した後Geminiで読み込む手間が発生します。

代案を聞いてみる

AIが出した回答が難しくて理解できないときは、もっと簡単なやり方はある？と聞いてみます。

実はもっとシンプルな道筋が存在することもあり、違う角度から質問してみるといいかもしれません。

YAMLで投げる

エラーが出たら、自分が作ったコントロールをYAMLコピーし、AIに投げて何が違うか聞いてみましょう。

YAMLコピーすると、複雑なプロパティの中身をコードで表示してくれますので、AIが構造を理解できるのです。

AIに解説してもらう

Power Appsで作りたい機能があってネット検索したところ、詳しい手順を紹介した記事があったとします。

ところが内容が難しく、手順通りにやってもうまくいきません。

そんなとき、記事のURLをAIに貼り付けるか、記事をまるまるコピーしてAIに貼り付けて手順をわかりやすく教えてと聞きましょう。

途中でエラーが出たらスクリーンショットして聞けばいいです。

もしくはこの記事とは別のアプローチでやり方ない？と聞くのも良さげです。

存在しない機能や関数に注意

AIは万能ではないため、Power Fxに存在しない関数を平気で答えとして出すことがあります。

Power Appsのエラーで存在しない関数ですのようなエラーが出るのでわかりやすいです。

そんな時は〜という関数はPower Appsでは使えない、ちゃんと回答してとたしなめるといいですね。

複数のAIをつかう

求める答えがChatGPTで出なければGeminiを使いますし、それがだめならPerplexityを使いますし、複数のAIを使いましょう。

繰り返し質問する

求める答えが出ないからといって、一度聞いただけで諦めてはいけません。

切り口を変えて、表現を変えて、繰り返し質問を続けることが大切です。

AIは万能ではありません。使いこなす側の人間の質問力と根性が問われるのです。

AIと組み合わせると特に効果的な場面

個人的にAIが特に役立つと感じているのは、パフォーマンス改善です。アプリが遅い・重いと感じたとき、原因の特定と改善策の提案をAIに聞くとヒントがもらえることが多いです。Power Appsが重い・遅いと感じたときの改善策の記事もあわせて参考にしてください。

Power Apps開発の全体像については、Power Apps開発の全体マップ記事でまとめて解説しています。AIはあくまで補助ツールですが、うまく活用することで学習スピードが大幅に上がります。

あなたのおすすめ、おしえてください

他にもこんなAIテクニックがあるよ、という方はぜひ教えて下さい！

Power Appsの画面遷移とNavigate関数。複数画面アプリの基本設計

Mon, 16 Mar 2026 15:46:50 GMT

Power Appsで複数画面のアプリを作るなら、Navigate関数を理解することが最初の関門です。これを押さえると、ボタンを押して画面を切り替える、一覧から詳細に移動するといった動作が一気に作れるようになります。

複数画面アプリの基本的な考え方

Power Appsでは、1つのアプリの中に複数のスクリーン（画面）を作ることができます。左側のツリービューを見ると、スクリーンが一覧で並んでいる場所があると思います。スクリーンを追加するほど、表現できるアプリの幅が広がります。

ただし、スクリーンは互いに独立しています。つまり、スクリーンAのコントロールにスクリーンBから直接アクセスすることはできません。画面をまたいでデータを使いたいときは、変数という仕組みを使う必要があります。この点は最初に覚えておくと後で混乱しません。

画面遷移を実現する関数が Navigate関数と Back関数です。この2つを使いこなすことで、複数画面アプリの基礎が固まります。

Navigate関数の基本

構文と使い方

Navigate関数の基本的な書き方はシンプルです。

Navigate(遷移先スクリーン, 遷移アニメーション)

例えば、ボタンを押して詳細画面に移動させたいとします。そのボタンのOnSelectプロパティに次のように書きます。

Navigate(詳細画面, ScreenTransition.Cover)

第1引数が移動先のスクリーン名、第2引数が遷移時のアニメーションです。アニメーションは省略も可能ですが、指定しておくと画面の切り替わりが自然に見えます。

遷移アニメーションの選び方

よく使うアニメーションは3種類です。用途ごとに使い分けると、アプリの操作感が良くなります。

アニメーション	動作	おすすめの場面
ScreenTransition.None	アニメーションなし、即切り替え	高速な操作が必要なとき、パフォーマンス重視のとき
ScreenTransition.Fade	フェードイン・アウト	一般的な画面遷移。どこでも使いやすい
ScreenTransition.Cover	右からスライドしてくる	一覧→詳細など、階層が深くなる方向への遷移

個人的には ScreenTransition.None か ScreenTransition.Cover をほぼ使っています。アニメーションが凝りすぎると動作がもたつくことがあるので、シンプルなもので十分です。

Back関数で元の画面に戻る

詳細画面から一覧画面に戻るボタンには Back関数を使います。

Back()

これは直前のスクリーンに戻る関数です。使い方は簡単なのですが、1点だけ注意があります。Back()は画面の履歴を遡るので、複雑な遷移フローだと意図しない画面に戻ることがあります。シンプルなアプリであれば問題ないのですが、慣れてきたら明示的に遷移先を書くほうが安全です。

Navigate(一覧画面, ScreenTransition.None)

こちらのほうが、どの画面に戻るかが一目でわかるのでおすすめです。

コンテキスト変数を使って値を受け渡す

Navigate関数の第3引数

一覧画面でタップした行の情報を、詳細画面でも使いたい——こういう場面はよくあります。そのときに使うのが Navigate関数の第3引数です。

Navigate(詳細画面, ScreenTransition.Cover, {selectedItem: ギャラリー1.Selected})

こう書くと、詳細画面に selectedItem という名前のコンテキスト変数が渡されます。コンテキスト変数とは、そのスクリーン内だけで有効な一時的な変数のことです。料理でいえば、調理台の上にしか置けない食材のようなものです。別のスクリーンに持ち出すことはできません。

詳細画面では、渡されたコンテキスト変数をこのように使います。

selectedItem.タイトル
selectedItem.担当者名
selectedItem.期日

SharePointリストのフィールド名をそのまま書けば、選択した行のデータが表示されます。

グローバル変数との使い分け

コンテキスト変数はそのスクリーン内でしか使えないので、詳細画面から編集画面にさらに移動したい場合は少し工夫が必要です。

よく使う方法は2つあります。1つ目は Navigate関数の第3引数でそのまま次の画面にも渡す方法。2つ目は Set関数を使ってグローバル変数に保存しておく方法です。

// グローバル変数に保存してから遷移する場合
Set(gSelectedItem, ギャラリー1.Selected);
Navigate(詳細画面, ScreenTransition.Cover)

グローバル変数はアプリ全体からアクセスできるので、複数の画面をまたぐデータにはこちらが向いています。グローバル変数とコンテキスト変数の違いや使い分けについては、グローバル変数とコンテキスト変数の解説で詳しく整理しているので参照してみてください。

実際の画面設計——一覧・詳細・編集の3画面構成

業務アプリで最もよく使う画面構成が、一覧→詳細→編集の3画面パターンです。私が物流現場で作った申請管理アプリも、最初はこの構成から始めました。

画面の役割と遷移の流れ

各画面の役割を先に決めておくと、設計がスムーズになります。

一覧画面：ギャラリーでデータをリスト表示する。行をタップすると詳細へ移動
詳細画面：選択したレコードの情報を表示する。編集ボタンで編集画面へ
編集画面：データを入力・変更してPatch関数で保存。完了後は一覧に戻る

一覧画面のギャラリーのOnSelectプロパティはこのようになります。

Navigate(詳細画面, ScreenTransition.Cover, {selectedRecord: ThisItem})

ThisItemはギャラリーが今タップされているレコードを指します。これをコンテキスト変数 selectedRecord として詳細画面に渡します。詳細画面の各テキストラベルには selectedRecord.フィールド名と書けば、選んだレコードの値が表示されます。

変数の設計に少し時間をかけると後が楽になる

画面遷移で詰まるのは、だいたい変数の使い方が曖昧なときです。コンテキスト変数でいくか、グローバル変数でいくかを最初に決めておくと、作りながら迷わずに済みます。

私がよく使うパターンは、詳細画面まではコンテキスト変数でデータを渡して、編集画面に進む段階でグローバル変数に切り替える方法です。詳細画面では読み取りだけなのでコンテキスト変数で十分。編集画面ではフォームとのやり取りもあるので、アプリ全体からアクセスできるグローバル変数のほうが扱いやすいのです。

ギャラリーコントロール自体の使い方（リスト表示の設定、Selected状態の管理、Search関数との組み合わせ）については別記事で解説する予定です。Navigate関数と組み合わせると、より実用的な一覧画面が作れるようになります。

注意点と限界

画面数が増えると管理が大変になる

Power Appsはスクリーン数が増えると、どの変数がどの画面で使われているかを追うのが難しくなります。スクリーンが10枚を超えてくるあたりから、変数名の付け方や画面の命名規則を統一しないと自分でも混乱しやすくなります。

開発者ドキュメントには、スクリーン数やコントロール数が増えるほどパフォーマンスが落ちると書かれています。体感として、スクリーンが20を超えてくると動作がもたつき始めることがあります。複雑になりそうな場合は、画面の分け方自体を見直すか、コンポーネントの活用を検討してみてください。

Back()は使いすぎに注意

Back()自体は便利なのですが、Navigate()で画面を飛ばした経路が複雑だと、Back()で戻る先が想定外になることがあります。ユーザーが予期しない画面に戻った場合、操作に迷わせてしまいます。シンプルな構成なら問題ないので、複雑になってきたら Navigate()で明示的に戻り先を指定するほうが安全です。

アプリ開発の全体像についてはPower Apps開発の全体マップに整理しています。画面設計だけでなく、データソース・関数・フォームなど各トピックへの地図になっているので、何から学べばいいか迷ったときに使ってみてください。また、アプリを作る一連の手順を知りたい方はPower Appsアプリ開発の流れも参考にしてみてください。

まとめ

Navigate関数をマスターすると、複数画面を持つ本格的な業務アプリが作れるようになります。最初はNavigateで飛んで、Back()で戻るだけを覚えれば十分です。慣れてきたら第3引数でコンテキスト変数を渡して、画面間のデータ連携に挑戦してみてください。

一覧→詳細→編集の3画面構成は、業務アプリの定番パターンです。まずはこれを1本作り切ることを目標にしてみましょう。地道に積み上げていけば、使い物になるアプリはちゃんと作れます。

Power Apps, Power Automate, アプリ作成の初心者におすすめの勉強手順

Thu, 01 Feb 2024 21:28:13 GMT

私が実際に実施してきた、Power Apps / Power Automate の初心者向けおすすめ勉強手順を紹介します。

1. まずハンズオン（動画教材）

初心者はハンズオンからスタートしましょう。

ハンズオンとは、オンラインで動画を視聴し、手順通りに実際に手を動かしてアプリを作る流れのことを指します。

代表的なものは “Udemy（ユーデミー）“でしょう。

初心者向けのPower Platform学習コースがたくさんあるので、一通り受講してみることです。

本当に基礎の基礎から丁寧に教えてくれるので、動画の通りに作るだけで流れが理解できました。

勤務開始前の通知アプリや注文系のアプリなど、コースの中でイチからアプリを作るので、達成感も感じられます。

個人的におすすめだったのはこの2つのコース。

『Microsoft Power Apps - 入門講座』

マスカワシゲルさん

『【2023年版】Microsoft Power Apps 基礎マスターコース』

ヒョウノモトハルさん

説明が丁寧でわかりやすく、非エンジニアの私でもすんなり理解できたのが印象的でした。

当時、Power Appsの知識が皆無だった私も、きちんとアプリが出来上がりました。

Udemyで学習を進めるにあたって気をつけるポイントはこちら。

画面構成が異なることがある

Power AppsやPower Automateの設計画面は日々アップデートされるため、動画で紹介している画面構成は古く、最新版と異なることがあります。

それでもどこに何の機能があるか自分で探し出し、自己解決する必要があります。

アレンジするにはさらなる勉強が必要

Udemyで作るアプリが自分の業務に完全にマッチすることはまずなく、多少なりともアレンジを加えたくなります。

その場合、そこまで詳細にコースでは紹介されていないため、別の手段で勉強するしかありません。

2. アプリを作る

動画でアプリ作成の流れを一通り理解したら、さっそく手を動かしてアプリ作成に移りましょう。

ローコードを含め、プログラミングを勉強するときは、実践に勝る学習方法はないと思っています。

✕　知識を身につけてから作る
◯　まず作り、作りながら知識を身につける

この流れが正解です。

アプリの制作手順をノートにまとめるなど、それも不要です。

わからないことがあれば、その場でネット検索すればいいからです。

Power Apps を作るには主に2通りの手順があり、『1. ExcelやSharePointリストからアプリを作る』であれば、本当に数クリックでアプリが自動生成されます。

出来上がるアプリは、3画面構成です。

データの一覧表示画面
詳細画面
新規入力画面

正直このままでは物足りなさがありますので、自分好みにレイアウトや表示内容を変更する必要があるでしょう。

一方、『空のアプリ』は全くの白紙からアプリを作ります。

パーツ配置や構成の自由度が高い反面、初心者にはハードルが高いです。

まずは自動生成のアプリを作り、Power Fx の仕組みや挙動を確認してみるといいですね。

アプリ制作にあたり、個人的に重要だと感じるポイントをまとめます。

日常のちょっとした手間を削減できないか考える

Excelの日報、紙資料の提出、手間のかかる承認作業。

面倒くさく感じているちょっとした作業をアプリのネタにするといいでしょう。

業務に直結するものはいきなり作らなくていい

市民開発と聞くと、誰しも仕事の効率アップとかDXを目的としてしまいがちです。

でも最初は仕事を忘れ、業務改善と無関係のアプリでも良しとしましょう。

なぜなら、自分自身がPower Platformで具体的にどんなツールが作れるかを理解できていないから。

例えば、今日の天気を入力して保存するだけのアプリとか、ボタンを押したら0〜100の数字がランダムに表示されるアプリとか、なんでもいいので形にしてみることです。

その中でPower AppsやPower Automateの機能を習得し、テクニックが身につき、応用を効かせられるようになっていきます。

目標を最初から仕事と結びつけると、度重なるエラーにやられてしまい、途中で挫折します。

そうなる前に、簡単でもいいのでアプリをたくさん作っておくことで、試行錯誤する知識と経験を身につけることができます。

Excelは早々に卒業する

Power AppsのデータベースにExcelを使うのはやめておきましょう。

データが多くなると、アプリ内で限られた数の情報しか閲覧できなくなったり（委任問題）、2人以上が同時にアプリを使うと、片方のデータが正しく保存されない（排他制御）など、データベースとしては使い物にならないのです。

Excelデータベースも多少改善されつつあるようですが、Listsが使えるのにあえてExcelを使う理由は正直見当たりません。

作成の基本はLists、慣れてきたらDataverseも視野に入れるといいですね。

要件定義やデータベース設計も最初は無視

学習の初期では、アプリの要件定義やデータベース設計は無視して構いません。

そんなことより、おもしろそうとか便利そうとか、自分の気持ちに素直になり、下手でもいいのでそれらを形にすることを意識しましょう。

アプリを使う人や関係部署が増えてくると、要件定義・データベース設計は避けては通れないようになりますが、それまでは気にする必要はありません。

そもそも、アプリにどんな機能を持たせるかとか、どんなデータテーブルと列を作るかなんてことは、ある程度アプリを作った経験がないとわかりっこないのです。

アプリを作りながら「あぁ、あの機能もつけたいな」「この列がやっぱり必要で・・・あの列は削除して」という、まさに行ったり来たりを経験する中でしか磨かれないと思います。

たくさんのアプリ開発事例を見る

他の人がどんなアプリを作っているか知ることはとても大切です。

新しい機能を知れたりアイディアにつながったり、自分に無い情報を周りから得ることは重要です。

気軽に相談できる間柄であれば、ソースを開示してくれるかもしれませんね。

人が開発する様子を見て学ぶ

機会があれば他人が開発する様子を見せてもらうといいでしょう。

関数の使い方や書き方を勉強できるだけでなく、どういう順番で開発をすすめるのか、ショートカットキーは何があるのかなど、新しい気付きと発見が必ずあります。

私もある程度開発経験を積みましたが、YouTubeで人が開発している様子を見ると今でも新しい発見がたくさんあります。

2-1. 情報の取り方

自分であらゆる情報を調べて試行錯誤することが開発上達への道です。

どういう情報を取るべきか、紹介します。

ChatGPTに聞く

Power Fxでわからないことがあれば、ChatGPTに質問してみましょう。

有料版がおすすめです

まるで市民開発のプロがつきっきりで面倒を見てくれるかのごとく、あらゆる質問に回答してくれます。

困り事があったら、まずChatGPTを使ってみることをおすすめします。

ただし、ChatGPTは万能ではなく、あたかも正解かのような口ぶりで平気で間違ったことを示してきます。

提示された式をそのまま使っても動かないことはしょっちゅうなので、自力で解析して修正したり、間違っていることをChatGPTに伝えて直してもらう必要があります。

開発において上手にAIに質問するテクニックを紹介していますので、興味があればこちらもどうぞ。

YouTubeを使う

YouTubeにもPower Platformの有益な情報が上がっていますので、積極的に調べてみましょう。

英語で発信されている海外YouTuberの情報は豊富で高レベルなものが多くあります。

英語に抵抗感の無い方はぜひ英語コンテンツの視聴を強くおすすめします。

ネット検索する

ネットの情報も貴重な学習資料です。

エラーをそのまま検索するのは常套手段ですが、作りたい機能や調べたい関数で検索して答えを見つけることも有効です。

動画と違ってコードをコピペできるのがネット検索の利点ですが、データソース名や変数をそのまま貼り付けてもあなたの環境では動きません。

どの箇所をどう修正するべきか見極める最低限の知識が必要です。

公式コミュニティを検索する

Power Apps公式フォーラム、Power Automate公式フォーラムの中身を検索し、欲しい情報を探します。

情報はすべて英語ですが、非常に有益な情報の宝庫です。

日本語フォーラムも存在しますが、情報量が圧倒的に少ないため、英語版がおすすめです。

ChatGPTなどにコピペすれば英語コンテンツも怖くないですね。

3. 人に使ってもらう

アプリは自分一人で使うより、他人に使ってもらったほうが勉強になることが多いです。

自分なりによくできたアプリだと思っていても、他人の目で見たら改善点が見つかることはよくあります。

式が抜けていて挙動がおかしかったり、このボタンはここにあったほうが使いやすいとか、後からどんどん見つかってくることでしょう。

アプリの中にお問い合わせフォームを設けてフィードバックをもらったり、Teamsチャットで気軽に質問を受けられるようにしておくといいですね。

4. 質問できるコミュニティに参加する

市民開発で行き詰まったとき、質問できるコミュニティに参加するといいでしょう。

社内でコミュニティがあるかもしれませんし、無いなら自分で人を集めて作ってしまいましょう。

同じ志を持った人同士の集まりは、いい刺激になるはずです。

わからないことがあれば先人に聞くのはアプリ制作において非常に大切ですが、なんでもかんでも聞いてしまうのはちょっと考えもの。

トライアンドエラーで苦労して自力で解決した経験は、後々に大きな財産になります。

自分で考えるクセも必要ですので、コミュニティに頼りっぱなしというのは避けたいですね。

5. 継続的に学習を続ける

毎日少しでもいいのでアプリ制作を継続しましょう。

時間がたつと、せっかく学習したことが抜けてしまいます。

また、Power Platformは頻繁にアップデートされ、新しい関数や機能が追加されます。

XやYouTubeなどで最新情報を積極的に取りに行くことが大事です。

まとめ

動画で概要をつかむ
さっそくアプリをつくる
人に使ってもらう
コミュニティを探す
学習を続ける

この流れです。

先に知識を蓄えすぎるのは逆効果ですので、わからないなりにも手を動かして作ることをおすすめします。

作っていく中でしかわからないことがたくさんあるのです。

Power AppsでOutlookスケジュールの詳細を表示するギャラリーの作り方

Tue, 15 Apr 2025 13:59:39 GMT

Power Appsのギャラリー機能を使い、各個人のOutlookスケジュールを詳細に表示する方法を紹介します。

Outlookのスケジュールを自動的に取得するためには Power Automate を使います。

例では当日を含めて6日分の予定を30分毎に更新し、特定のSharePoint Listに保存しています。

詳しいやり方は先にこちらをご覧ください。

https://shiminkaihatsu.com/pa_outlookschedule_listcopy/

使用している環境の紹介

この予定表示は、こちらで紹介している「テレワークか出社か表示するアプリ例」で実装している機能です。

このうち、青島さん（仮名）を例にして紹介していきます。

具体的なやり方

予定を保存したSharePoint Listをキャンバスアプリに接続し、コレクションに格納します。

Apps.OnStartでもいいですし、スクリーンのOnVisibleなどを利用するといいでしょう。

ClearCollect(AoshimaCollection, 青島スケジュール)

続いて名前を表示するボタンを作ります。

ボタンのTextは表示させたい人の名前を入力し、OnSelectは次の式を入れます。

Set(OnesSchedule, AoshimaCollection);
Set(OnesName, Self.Text);
Navigate(scrScheduleDetail, ScreenTransition.Fade);

ここではグローバル変数を2つ宣言しています。

OnesSchedule：AoshimaCollectionをOnesScheduleに格納しています。
OnesName：ボタンのTextの値をOnesNameに格納しています。

Selfはそのコントロールが持つプロパティの値を参照することができる、非常に便利な関数ですね。

Navigate関数で別のスクリーンに遷移します。

ここではscrScheduleDetailというスクリーンをあらかじめ作成済みです。

ところが実は、このコードは問題を抱えています。

人が増えても大丈夫なように工夫しておく

※ ここのやり方はちょっと複雑なことを書いていますので、難しい人は飛ばして次の段落へ進んでください ※

私が作成した「テレワークか出社か表示するアプリ例」は、30人を越えるメンバーの予定を表示しています。

ここで問題になるのが、人が増えた時に関数の管理が大変になることです。

もう一度さきほどのコードを見てみます。

Set(OnesSchedule, AoshimaCollection);
Set(OnesName, Self.Text);
Navigate(scrScheduleDetail, ScreenTransition.Fade);

人が増えたときに問題になるのは、1行目の Set(OnesSchedule, AoshimaCollection) の AoshimaCollection の箇所。

ここはいわゆるハードコーディング（直打ち）してしまっているので、いざ修正や変更となるとボタンの数だけ1つ1つ手直ししなくてはいけません。

そこでFormulasを使用します。

Formulasで設定する内容は、常にアプリに反映されます。

Apps.OnStartのように挙動が重たくなることもなく、変数などをこちらで宣言しておくことで開発・メンテナンスがとても簡単になります。

Formulasには次のように入れます。

ScheduleItems=
Table(
    {
        Name: "青島",
        Collection: AoshimaCollection
    }
);

ポイントは、Nameの値をボタンのTextと一致させておくことです。

その上で、ボタンのOnSelectの関数を次のようにします。

Set(OnesSchedule, LookUp(ScheduleItems, Name=Self.Text).Collection);
Set(OnesName, Self.Text);
Navigate(scrScheduleDetail, ScreenTransition.Fade);

1行目の AoshimaCollection が LookUp(ScheduleItems, Name=Self.Text).Collection に変わりました。

Formulasで定義したScheduleItemsのうち、Name項目がボタンのText（Selt.Text=青島）に一致する項目を見つけ、そのCollection項目の中身（AoshimaCollection）をOnesScheduleに格納する、という内容です。

もし人が増えてきたら、Formulasは次のように増やしていきます。

ScheduleItems=
Table(
    {
        Name: "青島",
        Collection: AoshimaCollection
    },
    {
        Name: "伊藤",
        Collection: ItoCollection
    },
    {
        Name: "上田",
        Collection: UedaCollection
    },
    {
        Name: "榎本",
        Collection: EnomotoCollection
    },
    {
        Name: "大塚",
        Collection: OtsukaCollection
    }
);

ここでの注意点は2つあります。

コード末尾は必ず　;　で終えること
〜Collectionは Apps.OnStartで宣言しておかないとFormulasでエラーになる

これを守っておけば大丈夫です。

ギャラリーを入れ子にするのがポイント

続いて scrScheduleDetailという名前で空のスクリーンを追加します。

まず先にツリービューをお見せします。

galDateは日付を表示するためのものです。

入れ子にしたgalScheduleDetailは、その日の予定を表示します。

galDateの中にgalScheduleDetailを入れ子にして使うのがここでのポイントですね。

galDateのItemsには次の式が入ります。

Table(
    {
        ID: 1,
        Date:
            Text(Today(), "m/d") & "(" &
            Switch(
                Weekday(Today()),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            ) & ")",
        LookupDate: Text(Today(), "yyyy/mm/dd"),
        LookupWeekday: 
        Switch(
                Weekday(Today()),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            )
    },
    {
        ID: 2,
        Date:
            Text(Today() + 1, "m/d") & "(" &
            Switch(
                Weekday(Today() + 1),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            ) & ")",
        LookupDate: Text(Today() + 1, "yyyy/mm/dd"),
        LookupWeekday: 
        Switch(
                Weekday(Today() + 1),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            )
    },
    {
        ID: 3,
        Date:
            Text(Today() + 2, "m/d") & "(" &
            Switch(
                Weekday(Today() + 2),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            ) & ")",
        LookupDate: Text(Today() + 2, "yyyy/mm/dd"),
        LookupWeekday: 
        Switch(
                Weekday(Today() + 2),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            )
    },
    {
        ID: 4,
        Date:
            Text(Today() + 3, "m/d") & "(" &
            Switch(
                Weekday(Today() + 3),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            ) & ")",
        LookupDate: Text(Today() + 3, "yyyy/mm/dd"),
        LookupWeekday: 
        Switch(
                Weekday(Today() + 3),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            )
    },
    {
        ID: 5,
        Date:
            Text(Today() + 4, "m/d") & "(" &
            Switch(
                Weekday(Today() + 4),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            ) & ")",
        LookupDate: Text(Today() + 4, "yyyy/mm/dd"),
        LookupWeekday: 
        Switch(
                Weekday(Today() + 4),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            )
    },
    {
        ID: 6,
        Date:
            Text(Today() + 5, "m/d") & "(" &
            Switch(
                Weekday(Today() + 5),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            ) & ")",
        LookupDate: Text(Today() + 5, "yyyy/mm/dd"),
        LookupWeekday: 
        Switch(
                Weekday(Today() + 5),
                1, "日",
                2, "月",
                3, "火",
                4, "水",
                5, "木",
                6, "金",
                7, "土"
            )
    }
)

簡単に解説します。

ID列

私が作った「テレワークか出社か表示するアプリ例」の仕様に合わせて6日分の日付を表示するようにしています。

ID列はあっても無くてもいいのですが、わかりやすくするために入れてます。

Date列

今日や明日などの日付と曜日を　4/14(月)　の形式で表示させます。

Today関数を使うことで、動的に表示を変更しています。

LookupDate列

日付をyyyy/mm/ddで表示させます。

これは入れ子にしたgalScheduleDetailで利用する参照列として機能します。

LookupWeekday列

その日の曜日だけを取り出しています。

これはgalDateの曜日を色付けして表示するために機能します。

次に、各コントロールのプロパティを見ていきます。

lblDate

Text:

ThisItem.Date

Color:

Switch(
    ThisItem.LookupWeekday,
    "日", Color.Red,
    "土", Color.Blue
)

日曜日を赤色、土曜日を青色で表示するようにしています。

祝日には対応していないため、別途祝日Listなどを用意して接続すれば、より見やすい表示になるでしょう。

galScheduleDetail

Items:

Sort(
    Filter(OnesSchedule, Text(DateTime, "yyyy/mm/dd")=ThisItem.LookupDate),
    DateTime,
    SortOrder.Ascending
)

Height:

CountRows(
    Filter(
        OnesSchedule,
        Text(
            DateTime,
            "yyyy/mm/dd"
        ) = ThisItem.LookupDate
    )
) * 140

Height 140 を掛けるようにしています。

ご自身の環境に合わせて数字は変更してください。

lblScheduleTitle

Text:

ThisItem.'Title (Title0)'

lblTitle

Text:

Text(
    ThisItem.DateTime,
    "H時mm分"
)

SharePoint Listの作り方によっては列名が異なる場合があります。

ご自身の環境に合わせた列名に置き換えて使ってください。

応用に向けたアイディア

未実装ですが、アイディアだけは持っています。

開発時間対効果がどこまで期待できるかという問題がありますので、もし時間があるようなら作ってみたいと考えています。

複数人の予定を同時表示する

現状は1人だけの予定詳細しか見れませんが、何人かの予定を同時に表示させると便利になると思います。

バーで予定を表示する

今はテキストだけの表示ですが、こういう画像のように色付きバーで予定が見えるとわかりやすくなると思います。

複数人の予定を同時に表示するなら、横向きのバーがわかりやすいですね。

アプリから予定を変更する

これは機能的に実現可能かわかりませんが、市民開発アプリからOutlookの予定を変更できるようになると、もっと便利になるでしょう。

ギャラリーの入れ子は1階層までしか入らない

ギャラリーの入れ子は便利ですが、1階層までしか入れることができません。

入れ子を多様するとアプリが重たくなる原因にもなりますので、ほどほどに使いましょう。

Power AutomateでOutlookスケジュールをリストにコピーする方法

Tue, 29 Oct 2024 20:39:14 GMT

Outlookの予定を、Power Automateを使って30分間隔で自動的にSharePoint List（リスト）にコピーする方法を紹介します。

全体の概要

1人分のスケジュールをコピーするためには次のものが必要になります。

リスト1つ
Power Automateフロー1つ

もし2人分になれば、リスト2つ、フロー2つ必要です。

自分以外の予定をコピーすることもできますが、その場合はその人のアカウントからPower Automateを設定する必要があります。

Outlookの編集権限を自分に付与してもらう必要はありません。

それとは別に、次のものも必要です。

更新用リスト1つ
更新用 Power Automate フロー1つ

これらは人数が増えても減っても1つずつあれば大丈夫です。

つまり、1人分のOutlookスケジュールをリストにコピーしようとすれば、最低限リスト2つ、フロー2つが必要になります。

なお、SharePoint Listに予定を格納できれば、キャンバスアプリで見やすく表示することもできます。

興味があれば、こちらも御覧ください。

https://shiminkaihatsu.com/outlook-schedulelayout/

リストの準備

リストを2種類準備します。

まず1つ目は次のようにします。

仮にこのリストをスケジュールリストと呼称します。

・Title/1行テキスト（予定の件名を入れる）

・DateTime/日付と時刻（時間を含める、わかりやすい形式）（日時を入れる）

・Name/1行テキスト（誰の予定かわかるようにする）

このリストにはOutlookスケジューラーから抽出した予定が入ります。

1人1リストなので、もし複数人の予定を取り扱いたい場合は人数分のリストを準備します。

そして2つ目のリストはこちらです。

仮にこのリストを更新用リストと呼称します。

列は初期値のタイトルのままでいいです。

それ以外の列は不要です。

このリストに新しい項目が作成されたことをトリガーとし、30分間隔でOutlookの予定を吸い上げる Power Automate が動くようにしていきます。

ここではあえて「スケジュール済みクラウドフロー」は使いません。詳細は後述します。

Power Automate1つ目

Power Automateのフローも2種類用意します。

まず簡単なほうからいくと、全体像はこちらです。

スケジュール済みクラウドフローを使います。

中身は非常にシンプルな内容です。

自動発火は30分ごとです。

次に SharePointリストから複数の項目を取得しますが、先に作成した更新用リストを設定します。

詳細オプションは未入力のままです。

続いて残り2つのアクションがこちら。

更新用リストから取得した複数の項目を、Apply to each で削除します。

そして最後に SharePointリストの項目の作成で更新用リストを設定し、タイトル列に任意の値を入れましょう。

私の場合はわかりやすく「30分」としました。

これで1つ目のフローが完成です。

やっていることは、30分間隔で更新用リストの中身を全消去し、項目を1つ作成するということ。

更新用リストが更新されることで、次に作成するフロー2つ目のトリガーになります。

スケジュール済みクラウドフローを使わない理由

それは、人数が増えたとき、仮に発火の頻度を30分から変更したいときや、一時的にフローをストップするときに役立つためです。

いま紹介しているやり方は、1人につき1つフローを準備しますので、人数が増えるほどフローも増えます。

もしこれらのフローを「スケジュール済みクラウドフロー」のトリガーにしてしまうと、数の分だけ手動で変更しなくてはならず、大変です。

私が実業務で使うときは30人以上の予定を取得していますので、更新用リストを設けることで随分ラクしています。

Power Automate 2つ目

続いて予定を取得するフローの全体図がこちら。

自動化したクラウドフローを使います。

中身を見ていきます。

トリガーは、更新用リストに項目が作成された時にします。

これは1つ目のフローで30分間隔でリストが更新されるように設定済みのものですね。

続いて変数Today に、addHours を使って日本時間の現在時刻を格納します。

addHours(utcNow(),9,'yyyy-MM-dd')

変数Todayは後のアクションで使用します。

続き。

「イベントのカレンダービューの取得（V3）」アクションで、自分のカレンダーを指定し、開始時刻と終了時刻に式を設定します。

開始時刻

addHours(variables('Today'),-9)

終了時刻

addHours(addDays(variables('Today'),6), -9)

6というのは6日分を意味します。

取得したい日数に合わせて数字を変更してください。

カレンダーIDを選択する時、おそらく複数の候補が表示されます。

この場合は「予定表」を選択します。

そして変数 Kaishi を設定しておきます。

次に SharePoint「複数の項目の取得」アクションで、スケジュールリストを設定します。

次は複雑なアクションが続きます。

ここはtry-catchというエラー処理を施したアクションです。

スコープというのは複数のアクションをひとまとめにできる、いわばフォルダみたいな役割をします。

まず「スコープtry」の中身がこちら。

複雑なように見えますが、やっていることをまとめます。

スケジュールリストの中身を Apply to each で全消去。

消去後のスケジュールリストの項目を取得。

本当に全削除できているかを Do until で判断し、まだ削除しきれていなければ再び Apply to each で消去ループをまわす。

全削除できていれば次のアクション（スコープcatch）に進む。

というものです。

Do until の条件式はこちら。

length(outputs('複数の項目の取得_2')?['body/value'])

値の length がゼロ、つまり項目が全削除されたら Do until ループが抜ける仕組みです。

ごくまれに項目の削除アクションで削除しきれない現象があるため、こういう複雑な処理をしています。

次に「スコープcatch」の中身です。

中には通知アクションがあります。

エラー発生時に簡単なメッセージを送ることができるアクションです。

これで「スコープcatch」の中身は終了なのですが、もう1つ設定箇所があります。

「スコープcatch」アクションのメニューから「実行条件の構成」を選択します。

チェックボックスを画像のようにし、完了ボタンを押します。これでOKです。

Power Automateは基本的に1つ前のアクションでエラーが起きると、それ以降のアクション全てが中断されます。

ところが「実行条件の構成」から上記のようにチェックを入れることで、エラーが起こってもその次にくるアクションを実行させることができます。

これを利用し、もし「スコープtry」でエラーが起こった場合、「スコープcatch」でエラー通知を出し、次の「スコープfinally」アクションにつなげることができるのです。

こういうやり方をエラー処理、例外処理といったりします。

実行条件を設定した場合、矢印で示したようにアクション同士を繋ぐ線が点線表示になっていることがわかります。

最後に「スコープfinally」の中身です。

イベントのカレンダービューの取得で取得した予定をスケジュールリストにコピーする作業です。

「項目の作成」のDateTime列の式はこちら。

addHours(variables('Kaishi'), 0, 'yyyy/MM/dd HH:mm:ss')

これでPower Automate2つ目は完成となります。

フローを動かした結果

完成したフローを動かすには、更新用リストに項目を追加します。

1つ目に設定したフローが動くのを待つのもよし、更新用リストに手動でレコードを追加してもよし。

ただしくフローが設定できていれば、スケジュールリストにOutlook予定の件名と日時が並びます。

あとはこのリストを使ってPower Appsで予定を表示させるなど使いましょう。

Power Apps / Power Automate アウトプット完全ガイド｜メール・通知・画像埋め込み・AI添付ルーティングの全パターン

Sun, 05 Apr 2026 10:18:36 GMT

Power Apps / Power Automate から何かを送り出す手段は、メール・プッシュ通知・Teams 通知・ファイル保存など複数あります。それぞれを個別に覚えていくより、全体像を先に把握してから選ぶほうが設計がブレません。この記事では、私が現場で使っているアウトプットのパターンをすべて整理します。

アウトプットの全体像：3つのカテゴリで整理する

Power Apps / Power Automate からのアウトプットは、大きく3つに分けられます。

メール系：Outlook を使ったメール送信。Power Apps 単体でできるものと、Power Automate 経由でないとできないものがある
通知系：プッシュ通知・Teams 通知。即時性が高く、相手にアクションを促したい場面に向く
ファイル系：SharePoint / OneDrive へのファイル保存。メール添付との組み合わせも含む

それぞれの手段を誰に・何を・どれくらいの即時性で届けたいかという軸で使い分けると、設計の判断が明確になります。以下、各パターンを順に解説します。

Power Apps 単体でのメール送信

Power Apps からメールを送るには Power Automate が必要と思っている方も多いですが、Power Apps 単体でも Outlook メールを送ることができます。Office 365 Outlook コネクタを追加するだけで、フローを作らずにメール送信が実装できます。

関数は SendEmailV2 で、ボタンの OnSelect に直接書けます。

Office365Outlook.SendEmailV2(
    "to@company.com",
    "件名テキスト",
    "本文テキスト"
)

宛先をユーザー入力から動的に取得したり、コンボボックスで複数宛先を選択させたり、リッチテキストエディターで HTML メールを作ったりと、Power Automate なしでここまでできるのは設計の自由度が高まります。私の職場では、フォーム送信と同時に確認メールを送る処理を Power Apps 単体で実装しています。フロー設計が不要になるぶん、メンテナンスがシンプルです。

宛先パターン・添付ファイル・HTML 本文・CC/BCC の全実装方法は、Power Apps から Outlook でメールを送信する記事で詳しく解説しています。

Power Automate でのHTMLメール・画像埋め込み

メール本文に画像を埋め込みたい場合は、Power Automate 経由になります。URL リンクではなく Base64 形式で画像データを直接 src 属性に埋め込む方法で、URLが無効になる心配がなく確実に表示できます。

基本的な仕組みは、SharePoint や OneDrive からファイルを取得し、base64() 関数で文字列に変換して、img タグの src に埋め込む3ステップです。

<img src="data:image/jpeg;base64,@{base64(outputs('ファイルコンテンツの取得'))}" width="300">

Office 365 ユーザーのプロフィール写真も同じ方法で埋め込めます。担当者の顔写真つきで社内連絡メールを送るという用途で使っている現場も増えています。注意点として、Base64 に変換した画像が大きすぎると Outlook 側で表示されないことがあるので、まず小さいファイルで動作確認をしてから本番に進んでください。

Base64 変換の詳細手順・Compose（作成）アクションを使ったデバッグ方法は、Power Automate で HTML メールに画像を埋め込む記事にまとめています。

AI を使ったメール添付ファイルの自動振り分け

受信メールの添付ファイルを自動で分類し、SharePoint の適切なフォルダに保存する処理は、Power Automate のRun a prompt（プロンプトの実行）アクションを使って実現できます。

フローの全体設計は、メール受信 → 添付取得（ループ） → AI 分類 → Switch 振り分け → SharePoint 保存 → Teams 通知の5ステージです。AI にプロンプトで PDF を渡すと、resume（履歴書）・contract（契約書）・other に分類しつつ要約も返してきます。プロンプトで JSON 形式の出力を指定するのがポイントで、Switch（条件）アクションで振り分けに使える構造化データとして取り出せます。

現時点で AI が対応できるファイル形式は PDF・JPEG・PNG・GIF（非アニメ）のみで、Word ファイルはそのままでは処理できません。この制約を前提に設計する必要があります。AI Builderのクレジット消費も考慮に入れておきましょう。

5ステージそれぞれの詳細実装は、Power Automate でメール添付ファイルを AI で分類して SharePoint に自動振り分けする記事で解説しています。

プッシュ通知：スマートフォンに直接届ける

メールより即時性が高く、タップするとそのまま Power Apps アプリが起動するのがプッシュ通知の強みです。承認フローで、特定の申請レコードを開いた状態でアプリを起動するDeep Link が実装できると、担当者の操作ステップを大幅に削減できます。

実装には Power Automate のプッシュ通知の送信 V2アクションを使います。Power Apps V2 トリガーにメッセージ・宛先・パラメーターの3つのテキスト入力を設け、Power Apps 側からフローを呼び出す形です。

重要な注意点が2つあります。ひとつは新デザイナーでは既知バグがあるため旧デザイナーで作成すること、もうひとつはDeep Link を使う場合はフォームの Item プロパティを Gallery.Selected ではなく varRecord にしておくことです。Gallery.Selected は画面遷移後にリセットされてしまうため、通知経由でアプリを直接起動した場合に機能しません。

プッシュ通知はスケジュールトリガーからも送れます。毎朝リストをチェックして未提出者だけに通知する、という自動化との相性も抜群です。設定の全手順はPower Apps でプッシュ通知を送る記事にまとめています。

Teams 通知：チームへの一斉周知に最適

個人への直接アクション誘導にはプッシュ通知が向きますが、チーム全体への周知・定期レポート配信は Teams 通知が適しています。Power Automate の、チャットまたはチャネルへの投稿（Post a message in a chat or channel）アクションで、Flow Bot として投稿する方法が最もシンプルです。

HTML モードを使えばハイパーリンクや太字・テーブルをメッセージに含められます。SharePoint に保存したファイルへの直接リンクを埋め込んでここをクリックして確認という導線を作ると、Teams 通知の有用性がさらに高まります。

基本設定から実用シーン7パターンまでは、Power Automate で Teams 自動通知する記事で網羅しています。

どれを使う？アウトプット手段の使い分けガイド

5つのパターンを誰に・どんな内容を・どれくらい急いでという軸で整理すると、次のような判断基準になります。

シーン	推奨手段	理由
承認催促・タスク割り当て（即時アクション誘導）	プッシュ通知	タップで該当レコードを直接開ける
詳細説明・外部関係者への連絡	Outlook メール（Power Apps 単体）	HTML・添付・CC/BCC が揃っている
画像・グラフを含んだ見栄えのいい社内メール	Power Automate メール（Base64 画像埋め込み）	URL 依存なしの確実な表示
受信メールの仕分け・分類	Power Automate ＋ AI 振り分け	手動仕分けをゼロにできる
チーム全体への周知・定期レポート	Teams 通知	チャンネルに流れるため見逃しにくい

とりあえず全部メールにするという設計はシンプルですが、重要な催促が埋もれやすくなります。受け取る側が、このメールは読まなくていいと無意識に判断してしまうと、通知そのものの価値が下がります。プッシュ通知・Teams・メールを使い分けて、各通知の重要度を伝えることが、業務改善の精度を上げるポイントです。

まとめ

Power Apps / Power Automate のアウトプット手段は、メール・通知・ファイル保存を軸に5つのパターンがあります。それぞれに向き不向きがあり、シーンに合わせて選ぶことで通知の効果が変わります。

最初からすべてを実装する必要はありません。まずPower Apps 単体でのメール送信から始めて、届け方を変えたいシーンが出てきたらプッシュ通知や Teams 通知を追加していくのが現実的な進め方です。それぞれの詳細な実装は各記事にまとめているので、必要になったタイミングで参照してください。

Power Apps / Power Automate の連携全般については、Power Apps から Power Automate を呼び出す基礎の記事が入口として最適です。フロー連携の考え方を把握しておくと、今回紹介したどのパターンにも応用できます。

【2026年最新】Power Appsとは？業務効率化を実現するローコード開発ツール完全ガイド

Sat, 26 Apr 2025 11:28:29 GMT

Power Appsはマイクロソフトが提供する簡単アプリ作成ツールで、プログラミングの専門知識がなくても業務アプリケーションを素早く開発できるプラットフォームです。

近年、DX推進や業務効率化を目指す企業から注目を集めています。

この記事では、Power Appsの基本から応用まで徹底解説し、実際の活用法や最新機能についてご紹介します。

Power Appsとは？マイクロソフトが提供する業務アプリ開発プラットフォーム

Power Appsは、マイクロソフトが推しに推している簡単アプリ作成ツールのこと。

従来のアプリ開発では多くの時間とプログラミングの専門知識が必要でしたが、Power Appsなら慣れれば非常に素早くマルチプラットフォームのアプリケーションを開発することができます。

このツールはマイクロソフトの「Power Platform」に含まれる製品の一つで、他にもプロセス自動化を行う「Power Automate」、データのビジュアライズの「Power BI」などと連携して使われます。

これらを総合的に活用することで、包括的な業務システムを構築できるのが特徴です。

Power Appsの最大の魅力は、コードをほとんど書かずにアプリを開発できる「ローコード」の仕組み。

ドラッグ＆ドロップの直感的な操作で画面を設計し、必要に応じて簡単な関数を追加するだけで、実用的なアプリが作れます。

また、Office 365やSharePointなどのマイクロソフト製品との親和性が高く、既存の業務環境とシームレスに連携できる点も大きな利点です。

Power Appsで実現できること

現場の業務報告アプリ（日報、点検記録など）
社内リソース予約システム（会議室、備品管理など）
顧客管理アプリ（簡易CRM）
申請・承認ワークフロー（経費精算、休暇申請など）
検索機能を持つ情報管理システム

Power Appsの2つの開発アプローチと他ツールとの比較

Power Appsには「キャンバスアプリ」と「モデル駆動型アプリ」という2種類の開発方法があります。

キャンバスアプリは白紙のキャンバスに自由にUIをデザインしていくアプローチで、デザインの自由度が高いのが特徴。

一方、モデル駆動型アプリはデータモデルを先に定義し、そこから自動的にアプリの画面が生成される方式で、より少ないコードで開発できます。

他社の類似ツールと比較すると、以下のような特徴があります：

ツール名	開発アプローチ	特徴	適している用途
Power Apps	ローコード（キャンバス/モデル駆動）	Microsoft製品との連携、大規模アプリ対応	業務アプリ内製化、市民開発
kintone	ノーコード「画面からデータ」	日本語サポート、簡単操作	シンプルな業務アプリ、情報共有
AppSheet	ノーコード「データから画面」	Google連携、データ駆動	Googleユーザーの業務効率化

Power Appsの特徴は、比較的大規模なアプリケーションの開発にも対応していることです。

マイクロソフトによれば、Power Appsの導入目的は「現場主導のDX推進」と「アプリの内製化」の2種類あるとされています。

Power Appsのメリット・デメリットを徹底分析

メリット

開発スピードの向上: 従来の開発手法と比べて圧倒的に短期間でアプリを開発できます。数ヶ月かかっていた開発が数週間や数日で完了することも珍しくありません。
コスト削減: 外部委託せずに社内リソースでアプリ開発ができるため、開発コストを大幅に削減できます。
現場主導のDX推進: IT部門だけでなく、実際の業務に詳しい現場の社員がアプリを開発できるため、真に現場のニーズに合ったシステムを構築できます。
マイクロソフト製品との連携: Office 365、SharePoint、Teamsなど既存のマイクロソフト環境と簡単に連携できます。
マルチデバイス対応: 一度開発すれば、Web、iOS、Androidなど様々なプラットフォームで利用できます。

デメリット

複雑な処理の限界: 非常に複雑な処理や大量データの処理には不向きな場合があります。
カスタマイズの制限: 従来の開発に比べると細かなカスタマイズの自由度は制限されます。
ライセンスコスト: 本格的に活用するには有償ライセンスが必要になります。
ガバナンスの課題: アプリが増えていくとメンテナンスや管理が難しくなる場合があります。

Power Appsは特に、頻繁に変更が必要な業務アプリや、比較的シンプルな処理を行うアプリの開発に適しています。

基幹システムや複雑な計算処理を要するアプリケーションには、従来の開発手法を選択した方が良いでしょう。

Power Appsの基本機能と活用方法

Power Appsには様々な機能が搭載されていますが、ここでは基本的な機能の一つである「検索機能」の実装方法を紹介します。

検索機能の実装例

Power Appsでは、Search関数を使って簡単に検索機能を実装できます。

例えば、テキストボックスに入力した値をもとにレコード一覧をフィルタリングする機能は以下のように実装できます：

検索用のテキストボックスを配置（例：SearchTextBox1）
データを表示するギャラリーを配置
ギャラリーのItemsプロパティに以下のような式を設定

Search(データソース, SearchTextBox1.Text, 検索対象の列名)

この実装により、テキストボックスに文字を入力するたびにリアルタイムでフィルタリングされる「インスタント検索」機能が実現できます。

入力の都度Enterキーを押す必要がなく、ユーザー体験が向上します。

このような関数はPower Fxと呼ばれる専用の関数ではあるものの、Excel関数にも似たところが多様にあります。

日頃からExcelを使いこなす方は違和感なく入り込めるでしょう。

Power Appsを始めるための具体的ステップ

Power Appsを始めるには、以下のステップを踏むことをおすすめします：

環境準備: Microsoftアカウントを用意し、Power Appsにログインします。企業で使うMicrosoftのプランであれば、基本的にどれもPower Appsが使えるようになっているはずです。
基本操作の学習: マイクロソフト公式のラーニングパスやYouTube動画を活用して、基本的な操作方法を学びます。
サンプルアプリの作成: シンプルな業務報告アプリなど、小さなアプリから始めてみましょう。例えば以下のようなステップで作成できます：
- Power Apps Studioで新しいキャンバスアプリを作成
- データソース（SharePointリストやExcelなど）を接続
- 画面レイアウトをデザイン
- コントロールに動作を設定
- 保存してテスト実行
- 問題がなければ公開して共有
実務への適用: 小さな成功体験を得たら、実際の業務課題に適用していきます。最初は簡単な業務から始め、徐々に範囲を広げていくのがコツです。

まとめ：Power Appsで実現するDXと業務効率化

Power Appsは、プログラミングの専門知識がなくても業務アプリを開発できる革新的なツールです。

「市民開発者」と呼ばれる現場の社員がアプリを開発できるようになることで、IT部門の負担軽減とDX推進の両立が可能になります。

デジタル化の波が加速する今、Power Appsを活用したローコード開発の取り組みは、企業の競争力強化に直結する重要な戦略となっています。

ぜひ本ブログを参考に、Power Appsの導入と活用を検討してみてください。

Power Appsでカメラコントロールを使って写真撮影・添付ファイルとして保存する方法

Mon, 16 Mar 2026 15:46:52 GMT

Power Appsのカメラコントロールを使えば、スマホやタブレットのカメラで撮影した写真をそのままSharePointに添付ファイルとして保存できます。現場で写真を撮ってすぐ記録に残せるので、点検・巡回・施設管理などのアプリで重宝します。

私が最初に作ったカメラ連携アプリは配送現場の荷物破損記録用でした。スマホで撮ってボタン1つで記録完了、という流れにしたところ「これは便利」と現場から喜ばれました。実装自体はそこまで複雑ではないので、この記事で仕組みをまとめます。

カメラコントロールの基本

カメラコントロールをキャンバスに追加すると、実行時にデバイスのカメラ映像がリアルタイムで表示されます。Photoプロパティに現在のカメラ映像（またはスナップショット）が入るので、これを使って画像を取り扱います。

Streamと静止画の違い

カメラコントロールには2つの重要なプロパティがあります。

プロパティ	内容	用途
Stream	カメラのリアルタイム映像	プレビュー表示
Photo	シャッターを押した瞬間の静止画	保存・送信に使う

StreamはImageコントロールのImageプロパティに入れるとリアルタイムプレビューとして機能します。撮影後の確認画面を作るには、撮影後にCamera1.PhotoをImageコントロールに表示する構成にします。

撮影ボタンとプレビューの実装

シャッターはCamera1のOnSelectプロパティに処理を書くことで実装します。

// 撮影ボタンのOnSelect
Set(varPhoto, Camera1.Photo)

varPhotoに撮影した画像を保存して、ImageコントロールのImageプロパティにvarPhotoをセットすれば、撮影後の確認プレビューが表示されます。

撮影した写真をSharePointに保存する

撮影した写真をSharePointリストの添付ファイルとして保存するには、Power Automateを経由する方法が確実です。Power Apps単体ではSharePointの添付ファイルAPIに直接アクセスするのが難しいためです。

Automateを使う場合の流れ

Power AutomateでPower Appsトリガーのフローを作成
AppsからBase64文字列に変換した画像データをフローに渡す
フロー内でSharePointの「添付ファイルの追加」アクションで保存する

Apps側で画像をBase64に変換する数式はこうなります。

// 保存ボタンのOnSelect
FlowName.Run(
    Text(Today(), "yyyy-mm-dd"),
    Mid(varPhoto, Find(",", varPhoto) + 1)
)

varPhotoはデータURIスキーム（data:image/png;base64,……）の形式になっているので、カンマ以降のBase64部分だけを切り出してフローに渡します。Mid関数とFind関数の組み合わせでこれが実現できます。

ファイル名の設定

SharePointの添付ファイルとして保存するとき、ファイル名はフロー側で設定します。撮影日時をファイル名に含めると後から管理しやすくなります。フロー内で「添付ファイルの追加」アクションに次のように入力します。

ファイル名：@{triggerBody()?[‘text’]}_photo.png
ファイルコンテンツ：base64ToBinary(triggerBody()?[‘base64’])

SharePointのAddAttachmentで直接保存する方法

Automateを使わず、Power AppsのPatch関数とAddAttachment関数を組み合わせてSharePointリストの添付ファイルを直接操作する方法もあります。ただしAddAttachmentはレコードが既に存在していないと動かないため、先にPatchで新規レコードを作成してからAddAttachmentで添付する、という手順になります。

// まずレコードを作成
Patch(記録リスト, Defaults(記録リスト), {タイトル: TextInput1.Text});

// 作成したレコードのIDを取得してから添付
AddAttachment(
    記録リスト,
    Last(Sort(記録リスト, ID, Descending)).ID,
    "photo.png",
    varPhoto
)

このやり方は処理がシンプルですが、最後のレコードIDを取る部分がやや不安定です。Automateを経由するほうが確実なケースが多いので、個人的にはAutomate経由を選びがちです。

実装時の注意点

カメラ権限の確認

スマホやタブレットでカメラを使うには、アプリにカメラへのアクセス権限を付与する必要があります。初回実行時にOSからカメラ使用の許可を求めるダイアログが表示されます。企業のモバイル管理（MDM）環境では事前に権限設定が必要なこともあります。

画像のサイズに注意

スマホのカメラで撮影すると数MBの画像になることがあります。SharePointの添付ファイルの上限は既定で250MBですが、大きすぎるとフローのタイムアウトやAppsの動作遅延の原因になります。カメラコントロールのResolutionプロパティを下げるか、Medium程度に設定しておくと扱いやすくなります。

SharePointへの書き込み全般については、こちらの記事も参考にしてください。

→ Power AppsでSharePointリストのデータを読み書きする——基本のCRUDパターン

まとめ

Power Appsのカメラコントロールは、Camera1.PhotoにBase64の画像データが入ります。SharePointへの保存はAutomate経由が確実で、Base64データをフローに渡してSharePointの「添付ファイルの追加」アクションで保存する流れが定番です。

写真撮影→即記録という流れは、点検や現場業務のアプリに特に効果的です。紙の記録票をなくしてスマホ1台で完結できるようになると、現場からの反響が大きいですよ。ぜひ試してみてください。

Power Appsのコレクション（Collection）活用入門。一時データ操作の基本

Sun, 15 Mar 2026 10:50:00 GMT

Power Appsのコレクションは、アプリの中だけで使える一時的なデータテーブルです。SharePointに都度アクセスしなくてもデータを操作できるので、使い方を知っておくとアプリ設計の幅が大きく広がります。

コレクションとは何か

アプリ内だけの一時テーブル

コレクションとは、Power Appsアプリのメモリ上に存在する一時的なデータテーブルです。SharePointリストやExcelとは異なり、アプリを閉じると消えます。永続的に保存したいデータはSharePointなどのデータソースに書き込む必要があります。

コレクションの使いどころは主に3つです。SharePointへのアクセス回数を減らしてパフォーマンスを上げる、入力途中のデータをアプリ内で一時的に保持する、委任できないFilterやSearchをかけるためのローカルデータを用意する、というものです。

変数との違い

Power Appsの変数（Set / UpdateContext）は単一の値を保存するものです。コレクションは複数の行と列を持つテーブルを保存します。ギャラリーのItemsにコレクションを設定して一覧表示できる点が、変数との最大の違いです。

コレクションの基本操作

ClearCollect：作成・全置き換え

ClearCollect はコレクションを初期化してデータを入れる関数です。既存のコレクションがあれば中身をすべて消してから新しいデータを入れます。

// SharePointリストの内容をコレクションに取り込む
ClearCollect(colShinsei, Filter(申請リスト, 担当者 = User().DisplayName))

画面が開いたタイミング（OnVisible）でこれを実行しておくと、以降は colShinsei というコレクションを使って表示や検索ができます。SharePointへのアクセスは最初の1回だけで済むため、その後の操作がスムーズになります。

Collect：追加

Collect は既存のコレクションに行を追加します。ClearCollect と違ってコレクションを消しません。入力フォームで1件ずつデータを追加していく場面で使います。

// フォームの入力内容をコレクションに追加する
Collect(
    colDraft,
    {
        商品名: テキスト入力_商品名.Text,
        数量: テキスト入力_数量.Text,
        単価: テキスト入力_単価.Text
    }
)

受発注アプリや日報アプリで、複数の明細行を入力してから一括保存するパターンでよく使います。コレクションに貯めてギャラリーで確認させ、最後に確認ボタンでSharePointに一括Patchするというフローです。

Remove・RemoveIf：行の削除

コレクションから特定の行を削除したいときは Remove または RemoveIf を使います。

// ThisItemで指している行を削除（ギャラリー内のボタンから）
Remove(colDraft, ThisItem)

// 条件に一致する行をすべて削除
RemoveIf(colDraft, 数量 = 0)

入力途中の明細リストから1行削除したいとき、ギャラリー内の削除ボタンに Remove(colDraft, ThisItem) を書きます。これだけで該当行がコレクションから消え、ギャラリーの表示もリアルタイムに更新されます。

Patchでコレクションの特定行を更新する

コレクションに対して Patch を使うと、特定の行の値を更新できます。Patch関数はSharePointだけでなく、コレクションにも使えます。

// コレクションの特定行を更新する
Patch(colDraft, ThisItem, {数量: テキスト入力_数量.Text})

ギャラリーで選択した行の数量だけを書き換えるといった使い方ができます。コレクション上で編集してから、最後にまとめてSharePointに保存するというパターンの骨格がこれです。

コレクションの実用パターン

OnVisibleで取り込んでパフォーマンスを上げる

SharePointリストを直接ギャラリーの Items に設定すると、画面を操作するたびにSharePointへの通信が発生します。アイテム数が増えてくると表示が遅くなりがちです。

OnVisibleで一度ClearCollectしてコレクションに落とし、ギャラリーのItemsをコレクションにする設計にすると、初回読み込み以降はSharePointへの通信なしで動作します。検索や絞り込みもコレクション上で行えるので、委任の制約も受けません。

ただし画面を開いたときの初回読み込みに時間がかかるというトレードオフがあります。データ件数が少ない（数百件以内）なら有効な手法ですが、数千件になるとむしろ遅くなるので注意しましょう。

入力データを一時保存してから一括登録する

複数の明細行を入力してから一括で登録したい場合、コレクションを使うと自然な設計ができます。

入力フォームで1行分のデータを入力
追加ボタンでCollectしてコレクションに追加
ギャラリーでコレクションの中身を表示・確認
登録ボタンでForAll + Patchを実行してSharePointに一括保存
ClearCollect（またはClear）でコレクションを空にする

このパターンは受発注の明細入力、日報の複数行入力、棚卸しのスキャン登録など、一度に複数件を登録する業務アプリで繰り返し使っています。

コレクションの中身をデバッグで確認する

コレクションの中身は、Power Appsスタジオの左側メニューにある変数パネルから確認できます。テスト実行中にコレクションに何が入っているかをリアルタイムで見られるので、デバッグに役立ちます。

また、一時的にギャラリーをコレクションにつないで中身を表示させるのもよい方法です。思ったデータが入っているかを視覚的に確認できます。

コレクションを使うときの注意点

アプリを閉じると消える

コレクションはアプリのメモリ上にしか存在しないため、アプリを閉じた瞬間に中身が消えます。入力途中のデータをコレクションに溜めていて、うっかりアプリを閉じるとそのデータは失われます。重要なデータは随時SharePointに保存する設計にするか、ユーザーにこのままアプリを閉じると入力中のデータが消えますと警告を出す設計を入れましょう。

件数の上限を意識する

ClearCollectでSharePointリストから取り込めるデータ件数は、データ行の制限の設定値まで（デフォルト500件、最大2000件）です。委任の警告の記事でも触れましたが、2000件を超えるデータをすべてコレクションに入れることはできません。コレクションに取り込む前にFilter（委任可能な条件）でデータを絞り込んでおくことが重要です。

Filter・Search・LookUpとコレクションの使い分けについてはFilter・Search・LookUp関数の記事も参考にしてみてください。

まとめ

コレクションはPower Appsの中でも特に実務でよく使う機能です。ClearCollectで取り込み・Collectで追加・RemoveIfで削除・Patchで更新という4パターンを押さえておけば、たいていのユースケースはカバーできます。

まずはOnVisibleでSharePointリストをコレクションに取り込んで、ギャラリーにつなぐところから始めてみてください。アプリの操作感が変わるのを実感できると思います。市民開発の積み重ねがここでも活きてきます。

Power Apps 初心者がハマりやすいミス10選｜よくある「なぜ動かない」の答えを全部まとめた

Sat, 18 Apr 2026 08:45:32 GMT

Power Appsを使い始めた頃にハマりやすいミスは、ほぼパターンが決まっています。この記事では、動かない、表示されない、保存されない系のよくある落とし穴を10個まとめました。

この記事はエラー・デバッグクラスターのサテライト記事です。エラーの種類別の調べ方はPower Apps 数式エラー解決の全体マップで整理しています。

ミス①：OnStartに変数を書いたのに起動直後に使えない

OnStartに書いた処理はアプリ起動時に実行されますが、すべてのOnStartが終わってから最初の画面が表示されます。ところが、OnStartの処理の中で非同期的に実行される部分があると、変数の初期化が完了する前に画面が表示されてしまうことがあります。

また、Power Apps Studioでプレビューを実行したとき、アプリの再起動ではなく、戻る/進むでページを移動するとOnStartが再実行されないため、変数が空のまま動作することがあります。これは開発中にしか起きない現象ですが、初心者が混乱しやすいポイントです。

OnStartとOnVisibleの使い分けについてはOnStartとOnVisibleの使い分けの記事を参照してください。初期化処理は原則としてOnVisibleに書くことをおすすめします。

ミス②：Gallery.SelectedをそのままPatchに渡してエラー

ギャラリーで選んだ行のデータをPatchで更新しようとするとき、Gallery1.SelectedをそのままPatchの第2引数に渡すと意図しない動作になることがあります。特に、ギャラリーの選択が解除されたタイミングでPatchが動くと、Selectedが空レコードになってしまいます。

// 危険：Gallery.Selectedをそのまま使う
Patch(SP_Tasks, Gallery1.Selected, {Status: {Value: "完了"}})

// 安全：ギャラリー選択時にvarRecordに格納しておく
// ギャラリーのOnSelect：
Set(varSelectedRecord, ThisItem)

// PatchはvarRecordを使う
Patch(SP_Tasks, varSelectedRecord, {Status: {Value: "完了"}})

ギャラリーで行を選んだ瞬間にOnSelectでvarRecordなどの変数に格納し、以降の処理はその変数を使うのが安全なパターンです。

ミス③：変数を初期化せずに使う

Power Appsの変数は、SetやUpdateContextで代入する前はブランク（空）の状態です。初回起動時に変数を参照する処理が走ると、ブランクが返ってきます。

例えばフラグ管理に使うBoolean型の変数を初期化せずに `If(varIsApproved, …)` と書くと、初回はブランクが返るため `false` として扱われます。意図通りに動いているように見えて、実は初期化されていないだけというケースがあります。

// OnVisibleで変数を初期化する
Set(varIsApproved, false);
Set(varCount, 0);
Set(varMessage, "");

グローバル変数とコンテキスト変数の使い方でも触れていますが、変数は使い始める前に初期値を設定する習慣をつけると、予期しない挙動を防げます。

ミス④：DropdownのItemsに文字列を直接書こうとする

ドロップダウンコントロールのItemsプロパティには、テキストの配列を渡す必要があります。文字列を1つそのまま書いてもエラーになります。

// NG：文字列を1つだけ書く
Dropdown1.Items = "選択肢A"

// OK：配列形式で書く
Dropdown1.Items = ["選択肢A", "選択肢B", "選択肢C"]

// SharePointの選択肢列から動的に取得する場合
Dropdown1.Items = Choices(SP_Tasks.Status)

選択肢の内容をSharePointの選択肢列から引っ張ってくるときはChoices()関数を使います。こうするとSharePoint側で選択肢を追加・変更したとき、アプリ側を修正しなくても自動で反映されます。

ミス⑤：テキスト入力の値を.Textなしで参照する

テキスト入力コントロール（TextInput）の入力値を取得するには、`.Text` プロパティを参照する必要があります。コントロール名だけ書くとコントロールオブジェクト全体を参照することになり、文字列として扱えません。

// NG：コントロール名だけ書く
Label1.Text = TextInput1

// OK：.Textプロパティを参照する
Label1.Text = TextInput1.Text

// Patchに渡すときも同様
Patch(SP_Tasks, Defaults(SP_Tasks), {Title: TextInput_Title.Text})

他にもDropdownの選択値は `.Selected.Value`、Toggleのオン/オフは `.Value`、DatePickerの選択日は `.SelectedDate` と、コントロールの種類によって参照するプロパティが変わります。最初は迷いますが、使っているうちに自然と覚えます。

ミス⑥：SharePointの選択肢列を.Valueなしで参照する

SharePointの選択肢列（Choice型）をラベルに表示したり、文字列として比較したりするとき、列名だけで参照すると `{Value: “選択肢名”}` というレコード形式で返ってきます。これを直接ラベルに渡すと `[object Object]` と表示されます。

// NG：選択肢列を直接ラベルに表示しようとする
Label1.Text = ThisItem.Status
// 結果：[object Object]

// OK：.Valueで文字列部分を取り出す
Label1.Text = ThisItem.Status.Value
// 結果："進行中"

// Filter条件で比較するときも同様
Filter(SP_Tasks, Status.Value = "進行中")

ミス⑦：フォームを開いたら前回の入力が残っている

EditFormを使って新規登録フォームを実装したとき、前に入力した内容が次回も残っていることがあります。これはフォームのDefaultModeプロパティの設定が原因です。

新規入力フォームとして使う場合は、画面のOnVisibleでNewForm()を実行してフォームをリセットするのが確実です。

// 画面のOnVisibleでフォームをリセットする
NewForm(Form1)

// または編集フォームとして特定のレコードを表示する場合
EditForm(Form1);
Form1.Item = varSelectedRecord

ミス⑧：データが500件以上あるのに全件取得できない

Power AppsのFilter・Search・LookUp関数は、データソース側で処理（委任）できない書き方をすると、アプリ側で処理する形になります。このとき取得できるのは最大500件（設定変更で2000件まで）です。データが増えてきた段階で突然、件数が合わないという症状が出ます。

数式バーに黄色の波線（委任警告）が出ている状態はこのリスクがあります。委任の仕組みと対処法は委任の警告とは？意味と対処法で詳しく解説しています。データが少ないうちに対処しておくことをおすすめします。

ミス⑨：OnChangeに書いた処理が初回は動かない

テキスト入力やDropdownのOnChangeプロパティに処理を書いた場合、そのコントロールの値がユーザーの操作によって変更されたときだけ発火します。画面が開いた初回は発火しません。

例えばDropdownの選択値が変わったときに変数を更新する処理をOnChangeに書いても、画面を開いた直後のデフォルト選択の状態では処理が走りません。初回から変数に値を持たせたい場合は、OnVisibleでDropdownのSelectedプロパティを参照して初期化しておく必要があります。

// 画面のOnVisibleで初期値を設定する
Set(varSelectedCategory, Dropdown_Category.Selected.Value)

// Dropdownのコントロール自体のOnChangeで更新する
Set(varSelectedCategory, Self.Selected.Value)

ミス⑩：UpdateContextが別の画面で使えない

UpdateContext()で設定したコンテキスト変数は、設定した画面の中でしか使えません。別の画面に移動すると参照できなくなります。複数の画面をまたいで使いたい変数はSet()（グローバル変数）を使う必要があります。

関数	スコープ	使いどき
Set(変数名, 値)	アプリ全体	画面をまたいで使う変数
UpdateContext({変数名: 値})	その画面のみ	その画面だけで使う一時的な状態管理

UpdateContext()は同じ画面の中で使う分には問題ありません。ダイアログの表示/非表示フラグや、フォームの入力モード切り替えなど、画面ローカルな状態管理に向いています。画面間でデータを受け渡したいときは、Navigate()の第3引数でコンテキストを渡すか、Set()でグローバル変数にする方法を選んでください。

まとめ

10個のミスを振り返ると、共通するテーマが3つあります。変数の型と初期化、コントロールのプロパティ参照の正しい書き方、そしてスコープの理解です。この3つを押さえると、初心者がハマりやすい問題の大半は回避できます。

最初は同じミスを何度か繰り返すのが普通です。でも繰り返すうちに、あ、またこのパターンだと気づける瞬間が必ずきます。市民開発はそういう地道な積み上げで成長するものです。

Power AppsのConcat関数｜コンボボックスの複数選択をメール宛先に変換する方法

Sun, 22 Mar 2026 11:17:43 GMT

コンボボックスで複数選択した値を1本の文字列にまとめたい。Concat関数を使えば、テーブルの内容をカンマ区切りや改行でつなぎ合わせられます。複数選択をメールのTo行に変換する場面でも活躍します。

ConcatとConcatenateの違い

Power Appsには文字列を結合する関数が2つあります。まず違いを整理しておきます。

関数	対象	用途
Concatenate	複数の文字列（固定の値）	“A” & “B” & “C” のような固定値の結合
Concat	テーブルの各行	コレクションやコンボボックスの選択値など、行数が変わるデータの結合

ほとんどの場面でConcatが必要になるのは、データの件数が実行時まで決まらないケースです。固定の2〜3個の文字列をつなぐだけなら、& 演算子で十分です。

Concatの基本構文

Concat関数の引数は3つです。

Concat(テーブル, 数式 [, 区切り文字])

第2引数には、各行に対して評価する数式を書きます。シンプルな例として、リスト内の全フルーツ名をカンマ区切りで結合するには次のように書きます。

Concat(["りんご","みかん","ぶどう"], Value, ", ")
// 結果：りんご, みかん, ぶどう

第3引数の区切り文字はPower Apps 2023年以降のバージョンから追加されたオプションです。古いバージョンでは区切り文字を数式の中に含める必要があります。

// 区切り文字引数がない場合の書き方
Concat(["りんご","みかん","ぶどう"], Value & ", ")
// 末尾に不要なカンマが残るため、後処理が必要

実例3パターン

コンボボックスの複数選択をPower Automateに渡す

コンボボックスで選択された担当者のメールアドレスをカンマ区切りで結合し、Power AutomateのHTTPリクエストや承認フローのTo行として渡す場面です。

Concat(ComboBox_Assignees.SelectedItems, Email, ";")

OutlookやTeamsの複数宛先はセミコロン区切りが一般的です。Power AppsからPower Automateのフローを呼び出す方法についてはこちらの記事で解説しています。Teams通知への活用はPower AutomateのTeams通知記事も参考にしてください。

コンボボックスの選択値でFilterをかける

コンボボックスで複数のカテゴリを選択し、そのいずれかに該当するデータをギャラリーに表示したい場合、ConcatとInを組み合わせます。

Filter(
    商品リスト,
    カテゴリ in ComboBox_Category.SelectedItems.Value
)

このケースではConcatではなくInを使うほうがシンプルですが、選択値を画面上に文字列として表示したいときはConcatが必要になります。ギャラリーの使い方はこちらの記事を参考にしてください。

コレクション内の値を改行でまとめる

承認フローなどで、選択されたアイテムの一覧をメモ欄にまとめて表示したい場面です。Char(10)で改行を挟みながらConcatで結合できます。

Concat(
    colSelectedItems,
    品名 & "：" & 数量 & "個",
    Char(10)
)

このようにして生成した文字列をPatchでSharePointの複数行テキスト列に保存することもできます。

よくある間違い：Concatの結果をテーブルと混同する

Concatはテーブルを受け取り、文字列を返します。Split（文字列をテーブルに変換）とは逆向きの関数です。ConcatとSplitを組み合わせると、テーブルと文字列を相互に変換できます。

// テーブル → 文字列
Concat(colItems, Value, ",")

// 文字列 → テーブル
Split("りんご,みかん,ぶどう", ",")

この2つの関係を覚えておくと、データの受け渡し場面で役立ちます。

まとめ

Concatは「テーブルを文字列に変換する関数」です。コンボボックスの複数選択をメール宛先にする、コレクションの内容をまとめて表示する、といった場面で繰り返し使います。

文字列を組み立てる別のアプローチとして、文字列補間という構文もあります。$“…” を使ったシンプルな書き方についてはこちらの記事をご覧ください。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

少し地味ですが、実務でよく使う関数です。ぜひ手に馴染ませてみてください。

Power Appsは万能ツールじゃない。デメリットあれこれ

Sun, 05 May 2024 18:32:42 GMT

Power Appsは万能なツールではありません。

エンジニアが作成するプログラムと比較すると機能は貧弱でメンテナンス性は悪く、プロから見たらデメリットだらけな環境らしいです。

そこで今回は、現役のPower Platform開発者が実際に感じるデメリットを紹介します。

Power Appsのデメリット

思いつくままに挙げていきます。

大量のデータの取り扱いは難あり

Power Appsでは、標準だと500件まで、上限でも2,000件までのデータしか一度に読み込むことができません。

それ以上のデータを取り扱う場合はあらためて読み込みが必要になりますが、そこに委任の問題も絡んできます。委任問題を回避できない場合は、どんなに頑張っても2,000件以上のデータが取得できません。

2,000件というのはExcelでいうところの2,000行です。

例えば自部署の20人が使用する日報アプリを Power Apps で作ったと仮定し、1日20件データが蓄積され、1ヶ月20日間の計算として月のデータ件数は400件です。

委任できない処理を含んだアプリの場合、わずか5ヶ月（400件×5ヶ月：2,000件）でそのデータソースは上限2,000件を迎えてしまい、新たに別のデータソースと切り替えなければいけません。

仮に委任可能な処理を施していたとしても、SharePoint Listsはデータ量が多くなるとパフォーマンスが低下する性質があるため、上限3,000件〜4,000件に留めることになります。

データベースにDataverseを使えばこれらの問題は解決されますが、有料契約が必要です。

パフォーマンスが悪い

1つのアプリに500を超えるコントロールを配置すると、アプリの挙動が極端に悪くなります。

コントロールというのは、Label1、TextInput1、DropDown1がアプリ内に存在していれば、コントロールは3ということです。

アプリが複雑化するほどコントロールが増大し、Power Apps Studio（アプリを作成する画面）がもっさりしたり、アプリのパフォーマンス低下に繋がります。

他にもデータソースが30を超えたり、スクリーンが20を超えてくると同様にパフォーマンスが低下します。

大量のデータはギャラリー表示するなどして対策が必要になります。

無い機能は使えない

Power Appsに備わっていない機能はどうやっても追加することができません。

一般的なプログラミングであれば、卓越した技術を持った人の個人開発ソースを使うなどして機能の追加が実現できたりするらしいのですが、Power Apps では Microsoft が動いてくれない限り、どうやっても拡張性が限られます。

MS製品に依存してしまう

Power Appsは基本的に外部サービスとの連携がほとんどできないため、どうしてもMicrosoftに依存したツールになります。

ゆえに大規模なアプリは作れない

ここまでに挙げた理由から、Power Apps で大規模なアプリ作成はできません。

プログラミングの専門知識を必要としない Power Apps は、参入障壁が低い代わりに出せるパフォーマンスも限られます。

既存業務のシステムをすべて Power Apps に置き換えていくなんてことは天地がひっくり返っても無理です。

ネット速度に依存してしまう

テザリングで作業をしていると速度が遅くなりますが、そういう時に Power Apps Studio で作業すると、正しく入力したはずの Power Fx が反応しなかったり、保存が途中で止まってしまうことがあります。

開発するにあたってネットの速度は非常に重要だと感じます。

（基本的に）社内でしか使えない

Power Appsは基本的に社内のみでの使用に限られます。

取引先とアプリを共有したければ、次の条件をすべて満たす必要があります。

先方の企業がPower Appsを使えるライセンス契約をしていること
データベースを共有していること
アプリを共有していること

バージョン管理ができない

Power Apps はバージョンを分けて保存することができません。

上書き保存したら過去のデータには戻れないため、特定のタイミングでZipでエクスポートしておくなど事前の準備が必要です。

費用対効果が小さい

苦労して作ったアプリも、実はそれ1つだけでは業務改善に与えるインパクトは非常に小さかったりします。

そもそも Power Apps は市民開発のための手段で、少ない労力でかゆいところに手が届くツールです。

何十時間もかけて作ったアプリのわりには、削減時間がたった数時間しかないなんてこともよくあります。

数をたくさん作らないといけません。

英語ができないと非効率的

開発でわからないことをネット検索するにしても生成系AIを使うにしても、英語ができるのとそうでないのとでは、得られる情報に天地の差があります。

プログラミングは英語を使いますので、ネット上は必然的に英語での情報が多くなります。

Power Apps も同じで、英語に抵抗感がなければ、ぜひ英語のブログ記事や英語のYouTubeを積極的に使うことをおすすめします。

デメリットを理解した上で使うもの

ここで挙げたデメリットを理解した上で Power Apps と付き合っていく必要があります。

できることとできないこと、得意なことと不得意なことを理解し、割り切りが必要です。

どんなに頑張っても Power Apps には限界がありますし、純粋なプログラミングには逆立ちしても機能面で勝つことはできません。

Power Apps（Power Platform）が得意とするのは、エンジニアに高いお金をかけて発注するまでもない、身近な業務改善のためのフィールドです。

日報をまとめるだけのアプリを、うん百万円も払って外注することはありませんし、社内承認が得られるはずがありません。

でも日報のExcel管理が大変だし、集計が手間だし、手間に感じているかもしれません。

それなら自前で好きな仕様で作ってしまおうというのが Power Apps です。

単純なCRUD（登録（Create）、読み込み（Read）、更新（Update）、削除（Delete））のアプリでいいなら、10分で出来上がってしまいます（見た目や使い勝手はともかく）。

市民開発とはこういう地道な事柄の積み重ねだと思っています。

Power Apps コンテナの子要素の配置・整列・重なりを制御する方法

Mon, 06 Apr 2026 22:40:39 GMT

Power Apps のコンテナでレイアウトを組むとき、子要素の整列とサイズ配分を制御するプロパティを理解しているかどうかで、完成度が大きく変わります。この記事ではオートレイアウトで使う主要プロパティを一通り整理します。

整列を制御する2つのプロパティ

LayoutAlignItems：交差軸方向の整列

LayoutAlignItems は、コンテナの主軸（方向）と垂直に交差する軸上での子要素の並び方を制御します。縦方向（Vertical）のコンテナなら左右方向、横方向（Horizontal）のコンテナなら上下方向の整列が対象です。設定できる値は Start・Center・End・Stretch の4択です。

Start にすると子要素がコンテナの左端（縦コンテナの場合）に寄ります。Center にすると中央揃え、End にすると右端寄せになります。Stretch はコンテナの幅いっぱいに子要素を引き伸ばします。個人的に一番使うのは Stretch で、子要素の幅を親コンテナに合わせて自動的に広げてくれるので、画面幅が変わっても崩れにくいレイアウトが作れます。

LayoutJustifyContent：主軸方向の配置

LayoutJustifyContent は、主軸方向（縦コンテナなら上下、横コンテナなら左右）での子要素全体の配置方法を制御します。設定できる値は Start・Center・End・SpaceBetween・SpaceAround の5択です。

SpaceBetween が特に便利で、最初の子要素をコンテナの先頭に、最後の子要素をコンテナの末尾に配置し、残りを等間隔に並べます。たとえばヘッダーバーの左端にタイトル、右端に更新ボタンを置きたいとき、横コンテナに2つの要素を入れて LayoutJustifyContent を SpaceBetween にするだけで実現できます。私のアプリでも cntBI_1stL（KPIカードの上段コンテナ）でこのパターンをよく使っています。Gap で間隔を細かく調整するより、SpaceBetween のほうがスッキリ書けます。

サイズ配分を制御するプロパティ

FillPortions：比率でスペースを分割する

FillPortions は子要素に設定するプロパティで、コンテナ内の余白を比率で分け合う仕組みです。たとえば左カラムに FillPortions: 3、右カラムに FillPortions: 2 と設定すると、利用可能なスペースを3:2で分割します。全体幅が変わっても比率は保たれるので、レスポンシブ対応に非常に便利です。

よくある使い方は「左側にサイドメニュー、右側にメインコンテンツ」の2カラムレイアウトです。サイドメニューに FillPortions: 1、メインコンテンツに FillPortions: 3 と設定すれば、画面幅に関わらず常に1:3の比率が維持されます。Width に直接数値を書くよりはるかに管理が楽で、画面サイズが変わるたびに計算し直す手間がなくなります。

固定サイズとFillPortionsの組み合わせ

FillPortions は固定サイズと組み合わせて使うとさらに強力になります。たとえばヘッダーの高さを Height: 60 で固定し、残りのボディ部分に FillPortions: 1 を設定すると、ヘッダーは常に60pxを確保しつつ、ボディが残りの高さをすべて占有します。画面の高さが変わってもヘッダーは60pxのまま、ボディだけが伸び縮みします。

この組み合わせは、固定ヘッダー＋スクロール可能なボディというよくある画面レイアウトの基本パターンになっています。FlexibleHeight プロパティでも同様のことが実現できますが、FillPortions のほうが直感的に比率をコントロールできるので私はこちらをよく使います。

間隔・余白を制御するプロパティ

GapとPaddingの違いを押さえる

Gap はコンテナ内の子要素同士の間隔をピクセルで指定します。一方 Padding はコンテナ自身の内縁と子要素の間の余白です。Gap は子要素間の隙間、Padding はコンテナの壁と中身の間の余白です。

たとえばカード一覧で各カードの間に16pxの隙間を空けたい場合は Gap: 16 を設定します。一覧全体の外側にも余白が欲しいときは PaddingLeft・PaddingRight などを追加します。Gap だけで全部やろうとすると、最初と最後の要素の外側に余白が出せないので、役割を分けて使うのが正解です。

MinimumWidthとMinimumHeight：崩れを防ぐ最小サイズ

FillPortions や Flexible Width・Height を使うと、画面が極端に小さくなったときにコントロールが潰れて表示が崩れることがあります。これを防ぐのが MinimumWidth と MinimumHeight です。たとえば MinimumWidth: 200 と設定しておくと、どんなに親コンテナが縮んでも子要素の幅は200px未満にはなりません。

ボタンやラベルなど、一定以下のサイズになるとテキストが読めなくなるコントロールには積極的に設定することをおすすめします。設定しておかないと、タブレットや小さいウィンドウで開いたときに想定外の崩れが起きることがあります。体感的に、最小幅80〜120px程度を目安にしていることが多いです。

スクロールと折り返し

Overflow（Scroll）：コンテナをスクロール可能にする

子要素の合計サイズがコンテナの表示領域を超えた場合の挙動を制御するのが Overflow プロパティです。Overflow: Scroll に設定すると、コンテナの範囲を超えた分はスクロールで表示できるようになります。縦方向と横方向でそれぞれ独立して設定できます。

よくある使い方は、画面下部に固定フッターを置きつつ、メインコンテンツ部分だけをスクロールさせたい場合です。ボディ部分のコンテナに Overflow: Scroll を設定し、FillPortions で残りの高さを占有させれば、フッターが画面外に消えることなくボディだけがスクロールする構造が作れます。Power Apps はギャラリーのスクロールが標準ですが、コンテナ単位でスクロールを制御できると設計の幅が大きく広がります。

Wrap：横コンテナでの折り返し

横方向（Horizontal）のオートレイアウトコンテナで Wrap を有効にすると、子要素が横幅に収まらない場合に次の行に折り返します。タイル状のカードレイアウトや、ボタンが増えたときに自動で折り返すツールバーを作るときに便利です。

注意点として、Wrap を使うと子要素の高さが行ごとに変わる場合があります。各行の高さを揃えたい場合は LayoutAlignItems: Stretch と組み合わせて使うと整いやすいです。

重なりを使うテクニック

Manual Layout内でのZ順活用

オートレイアウトは子要素を一列に並べる仕組みなので、コントロールを重ねるデザインには向いていません。重なりが必要な場合は Manual Layout のコンテナを使い、ツリービューでのコントロールの順序（Z順）を利用します。ツリービューで下にあるコントロールほど画面手前に表示されます。

よくある使い方は、画像の上にテキストを重ねるヒーローバナーや、グラフの上にアイコンや数値ラベルを重ねるKPIカードです。Manual Layout コンテナの中で X・Y・Z 順を使い分けると、オートレイアウトだけでは実現できないリッチなデザインが作れます。

コンテナの使い方全般についてはPower Apps コンテナ完全ガイドでまとめて解説しているので、あわせて参照してください。

プロパティの全体像をまとめる

ここまで解説したプロパティを表で整理します。

プロパティ	設定場所	主な使い道
LayoutAlignItems	コンテナ	交差軸方向の整列（Start/Center/End/Stretch）
LayoutJustifyContent	コンテナ	主軸方向の配置（SpaceBetween等）
FillPortions	子要素	余白を比率で分割
Gap	コンテナ	子要素間の間隔（ピクセル）
Padding（各辺）	コンテナ	コンテナ内縁の余白
MinimumWidth/Height	子要素	最小サイズの保証
Overflow	コンテナ	スクロール有無の制御
Wrap	コンテナ	横コンテナでの折り返し

これらのプロパティは単体で使うより、組み合わせて使うことで真価を発揮します。たとえば「LayoutAlignItems: Stretch ＋ FillPortions ＋ MinimumWidth」の組み合わせは、レスポンシブなカラムレイアウトの定番セットです。最初から全部覚えようとせず、まず LayoutAlignItems と Gap だけ試してみて、物足りなくなったら他のプロパティを加えていくと身につきやすいです。

コンテナの基本概念から学びたい場合は座標配置とコンテナの違いを解説した記事が入口になります。また、手動レイアウトとオートレイアウトのどちらを選ぶかの判断基準は手動レイアウトとオートレイアウトの使い分けの記事で詳しく扱っています。

まとめ

整列と配置を制御するプロパティは数が多いように見えますが、役割ごとに整理すると覚えやすくなります。LayoutAlignItems と LayoutJustifyContent が並び方、FillPortions と Gap・Padding が間隔とサイズ、Overflow と Wrap がはみ出し時の挙動です。この分類で頭に入れておくと、実際にレイアウトを組むときにどのプロパティを触ればいいかがすぐ判断できます。市民開発とはこういう地道な知識の積み重ねだと思っています。一つひとつ実際のアプリで試しながら身につけていきましょう。

Power Apps コンテナを使ってすべてのコントロールに角丸（ボーダーラジアス）を適用する方法

Mon, 06 Apr 2026 22:29:03 GMT

Power Apps で角丸デザインを実現したいと思っても、DropdownやDatePickerなど一部のコントロールは BorderRadius プロパティを持っていません。コンテナで包んでしまえばこの問題は解決します。しかも、アプリ全体の角丸を変数1つで一括管理できるようになります。

角丸が設定できないコントロールが存在する

Power Apps のコントロールには、モダンコントロールとクラシックコントロールの2種類があります。モダンコントロールはネイティブに BorderRadius プロパティを持っているので、プロパティパネルから直接角丸の値を指定できます。問題はクラシックコントロールです。Dropdown・DatePicker・ComboBox といったよく使うコントロールの多くがクラシック扱いで、BorderRadius プロパティが存在しません。

モダンコントロールに全面移行すればこの問題は解決しますが、既存アプリをそのまま使い続けている場合や、モダンコントロールではまだサポートされていない機能が必要な場合は、クラシックコントロールを使い続ける必要があります。私のアプリでもDatePickerはクラシックを使い続けており、どうしても角丸が揃わない箇所が出てしまっていました。これを解決したのがコンテナを使ったラップのテクニックです。

コンテナクラスターの全体像はPower Apps コンテナ完全ガイドにまとめています。このテクニックを使いこなすために、コンテナの基本概念を先に押さえておくと理解が深まります。

コンテナで包むと BorderRadius が子要素に伝播する

Power Apps のコンテナには、BorderRadius を設定すると内側の子要素にも角丸が適用される仕組みがあります。つまり、BorderRadius を持たないクラシックコントロールをコンテナに入れて、コンテナ側に BorderRadius を設定すれば、見た目上は角丸になります。

手順はシンプルです。まずコンテナを追加し、角丸を付けたいコントロールをその中に移動します。次にコンテナの BorderRadius プロパティに値を入れます。これだけで、コンテナの形状に沿った角丸がコントロール全体に適用されます。

// コンテナ側の設定例
BorderRadius: 8

注意点が一つあります。コンテナの Width と Height をコントロールと完全に一致させてください。コンテナがコントロールより大きかったり小さかったりすると、角丸の位置がずれて見えます。コントロールを親コンテナ（Auto Layout）内に配置している場合は、Flexible Width / Flexible Height を活用してサイズを自動追従させるのが確実です。

変数でアプリ全体の角丸を一元管理する

コンテナごとに BorderRadius を個別に設定していくと、後から「やっぱり角丸を少し小さくしたい」となったときに全コンテナを修正して回らなければなりません。コントロールが50個あれば50回修正が必要です。これは現実的ではないです。

そこで有効なのが、角丸の値を変数として管理する方法です。App.OnStart または App.Formulas で変数を定義し、全コンテナの BorderRadius をその変数で参照するようにします。

// App.OnStart に定義
Set(varRadiusBI, 8);

各コンテナの BorderRadius プロパティには固定値ではなくこの変数を指定します。

// 各コンテナの BorderRadius
BorderRadius: varRadiusBI

こうしておけば、varRadiusBI の値を変えるだけでアプリ全体の角丸が一括で変わります。デザインの方向性が途中で変わっても、1か所を書き換えるだけで済む。これは実際に開発していてとても助かっています。以前は個別に設定していたのですが、デザインレビューで角丸を変えることになった際に全部修正が必要で、かなり時間を取られました。それ以来、見た目に関わる値はできるだけ変数に逃がすようにしています。

上だけ角丸にするパターン

角丸は4辺すべてに均等に設定するだけではありません。上辺だけ角丸にして下辺はフラットにする、というデザインもよく使います。カードコンポーネントの上部だけ丸くして、下部はボーダーレスにする場合などです。

Power Apps のコンテナには BorderRadius とは別に、RadiusTopLeft・RadiusTopRight・RadiusBottomLeft・RadiusBottomRight という4辺個別のプロパティがあります。これを使えば非対称な角丸が実現できます。

// 上だけ角丸にするパターン
RadiusTopLeft: varRadiusBI
RadiusTopRight: varRadiusBI
RadiusBottomLeft: 0
RadiusBottomRight: 0

私のアプリでは cntCard_3rd1〜3 という3枚のKPIカードでこのパターンを使っています。カードの上部は varRadiusBI で丸く、下部は 0 にしてフラットにすることで、カードを並べたときに視覚的にすっきり見えるようにしています。上下の角丸を変えるだけでカードの印象がかなり変わるので、一度試してみることをおすすめします。

モダンコントロールとの使い分け

ここまで説明してきたコンテナラップのテクニックは、あくまでクラシックコントロールを使い続ける場合の対処法です。モダンコントロールに移行できるなら、コンテナでラップする必要はなく、直接 BorderRadius を設定できます。

ではどちらを選ぶべきか。私の判断基準はシンプルで、新規アプリはモダンコントロールを基本にして、クラシックが必要な箇所だけ使う。既存アプリは全面移行のコストが高いのでクラシックのまま維持して、このコンテナラップで角丸を対応する。これで大半のケースはカバーできています。

半分正解、半分間違いという感じですが、モダン一択にはまだなれない現実があります。ComboBox のカスタム候補表示や DatePicker の細かい制御はクラシックにしかない機能もあるので、過信しすぎは禁物です。コントロールの選択と UI 設計の考え方についてはPower Apps の見た目と使いやすさにこだわった設計の記事で詳しく触れています。

まとめ

クラシックコントロールの角丸問題は、コンテナで包む・変数で一元管理する、この2ステップで解決します。個別に設定して回る時代はもう終わりにしましょう。varRadiusBI を一つ定義しておくだけで、アプリのデザイン変更に柔軟に対応できるようになります。地道なようですが、こういった設計の積み重ねがメンテナンスしやすいアプリにつながっていきます。

Power Apps コンテナで再利用できるカスタムコントロールを作る方法｜カスタムボタン・プログレスバーの実装

Mon, 06 Apr 2026 22:29:03 GMT

Power Apps でボタンやプログレスバーを作るとき、標準コントロールのデザインだと物足りないことがあります。コンテナを使って複数のコントロールをまとめることで、見た目も動作も自分好みのカスタムコントロールを作れます。しかも一度作ればコピペで量産できます。

カスタムコントロールとは何か

Power Apps におけるカスタムコントロールとは、複数のコントロールをコンテナにまとめて一つの部品として扱えるようにしたものです。コンポーネント（Component Library）という仕組みも似たようなことができますが、コンポーネントは複数画面での再利用を前提にしていて、設定が少し複雑です。一方、コンテナを使ったカスタムコントロールは同一画面内での量産・使い回しに向いていて、コピペするだけで増やせるのが強みです。

コンテナを使ったレイアウト設計の全体像はPower Apps コンテナ完全ガイドで解説しています。このページではその応用として、カスタムコントロールの実装パターンを具体的に掘り下げます。

私がよく作るのはカスタムボタンとプログレスバーの2種類です。どちらも標準コントロールだと痒いところに手が届かない場面があり、コンテナで自作することにしました。一度パターンを作ってしまえば、以降は複製して中身を変えるだけなので、2つ目からの作業はとても速くなります。

カスタムボタンの作り方

標準の Button コントロールはシンプルで使いやすいですが、アイコンとテキストを横並びにしたい、テキストの左右にそれぞれ要素を置きたい、といった要件には対応しにくいです。そこでコンテナを使ってボタンを自作します。

構成はシンプルです。Auto Layout の水平コンテナを作り、中にアイコン（または Icon コントロール）とラベルを横並びで入れます。さらに透明な Button コントロールを同じコンテナに重ねてタップ判定を担当させます。

cntCustomBtn（水平 Auto Layout コンテナ）
├─ Icon コントロール（アイコン表示）
├─ Label（テキスト表示）
└─ Classic/Button（Fill: Transparent、タップ判定専用）

Button の Fill を Color.Transparent にしてコンテナ全体を覆うように配置することで、見た目はアイコン＋テキストのカスタムデザインのまま、クリック・タップの判定は Button が受け持つという役割分担ができます。OnSelect の処理は Button コントロールに書きます。

コピペで量産する方法

このカスタムボタンを別の場所に使い回したいときは、コンテナごとコピーします。コンテナをコピーすると中の子要素も全員ついてきます。コピー後に変える箇所は Label の Text プロパティと Button の OnSelect だけです。アイコンの種類を変えたい場合は Icon プロパティも変えますが、それだけで別のボタンとして機能します。

私のアプリでは更新ボタン・フィルタークリアボタン・CSVエクスポートボタンをすべてこのパターンで作っています。最初の1つを作るのに10分かかっても、2つ目以降は3分で完成します。コンポーネントを使うほどではないけれど、同じ画面で何度も使うボタンがあるなら、このコンテナ量産パターンが一番コスパが良いです。

カスタムプログレスバーの作り方

Power Apps には標準のプログレスバーコントロールがありません（モダンコントロールのProgressBar は存在しますが、デザインの自由度が低い）。コンテナと Rectangle を組み合わせると、自由なデザインのプログレスバーが作れます。

構造はこうです。外側コンテナがバー全体の背景（グレーなど）を担当し、内側コンテナが進捗部分（グリーンなど）を担当します。内側コンテナの Width を進捗率に応じた式で動的に変えることで、バーの長さが変化します。

cntBar（外側コンテナ：背景色・角丸設定）
├─ recLeft（Rectangle：進捗部分、Width は動的計算）
└─ recRight（Rectangle：残余部分、Width は残り幅）

進捗部分の Width 式はこう書きます。

// recLeft の Width（進捗部分）
Parent.Width * varSubmittedCount / varTotalCount

Parent.Width はバー全体の幅、varSubmittedCount は完了件数、varTotalCount は総件数です。完了件数が30で総件数が100なら、バーは全体の30%の長さになります。残余部分（recRight）の Width は Parent.Width - recLeft.Width で計算すると、合計が常にバー全体の幅になります。

件数ゼロのときのエラーを防ぐ

varTotalCount がゼロのとき、ゼロ除算エラーになります。データがまだない初日や、フィルターで全件が除外された場合などに起きます。これを防ぐには If 式で分母がゼロの場合を分岐させます。

// ゼロ除算を防ぐ式
If(
    varTotalCount = 0,
    0,
    Parent.Width * varSubmittedCount / varTotalCount
)

私はこのプログレスバーを船舶の作業進捗表示に使っています。varTotalCount が全船舶数、varSubmittedCount が作業提出済み船舶数です。朝一番にアプリを開いたとき、バーがどこまで埋まっているかで今日の進捗が一目でわかります。数字だけ見るより直感的で、チームへの共有にも使いやすいです。

コンポーネントとの違いと使い分け

コンポーネント（Component Library）はプロパティを外部から注入できるため、複数の画面・複数のアプリで同じ部品を共通化したい場合に向いています。一方、コンテナを使ったカスタムコントロールは同一画面内での使い回しに向いています。設定の複雑さとスコープで使い分けるのが現実的です。

まとめると、同一画面で3つ以上同じデザインのボタンやバーを使う場合はコンテナ量産パターン、複数画面や複数アプリに展開したい場合はコンポーネントという判断基準で問題ないです。市民開発の現場では、コンポーネントを設計する時間が取れないことも多いので、まずコンテナで作って後からコンポーネント化するというステップが現実的です。

角丸をコンテナで実現するテクニックはコンテナを使ってすべてのコントロールに角丸を適用する方法で解説しています。カスタムコントロールにも同じ考え方が使えるので、合わせて確認してみてください。

まとめ

コンテナを使ったカスタムコントロールは、作る手間より使い回しのメリットの方がはるかに大きいです。最初の1個を丁寧に作っておけば、あとはコピペと中身の差し替えだけで量産できます。プログレスバーのように標準コントロールにないものも自作できるのがコンテナの強みです。市民開発はこういった小さな工夫の積み重ねで、アプリの品質が上がっていきます。楽しみながら試してみてください。

Power Apps コンテナのドロップシャドウと FillPortions でカードUIに奥行きを出す方法

Mon, 06 Apr 2026 22:29:03 GMT

Power Apps のコンテナには DropShadow プロパティがあります。カードに影をつけることで画面に奥行きが生まれ、どこがタップ可能でどこが背景かが直感的に伝わります。ただし使い方を間違えると影が二重になったり、全体がうるさい印象になったりするので注意が必要です。

DropShadow プロパティの種類と使い分け

Power Apps のコンテナの DropShadow プロパティには5段階の設定があります。

設定値	影の強さ	主な用途
None	なし	レイアウト専用コンテナ（影不要）
Light	弱い	サブカード・補足的な要素
Regular	中程度	標準的なカードUI
Semibold	やや強い	強調したいカード・選択状態
Bold	強い	ポップアップ・モーダル的な要素

私のアプリでは KPIカードに Regular を使っています。Light だと影が弱すぎてカードの存在感が出ず、Semibold 以上だと3枚並べたときにくどくなりました。画面全体のトーンを見ながら Regular か Light を起点に調整するのがおすすめです。

コンテナクラスターにおけるデザイン設計の全体的な考え方はPower Apps コンテナ完全ガイドでまとめているので、DropShadow を活用する前の前提知識として目を通しておくと理解が早まります。

変数でアプリ全体のシャドウを一元管理する

角丸の変数管理と同じ発想で、DropShadow も変数で一元管理できます。App.OnStart に変数を定義し、全カードコンテナの DropShadow をその変数で参照するようにすれば、後から変更するときに1か所だけ書き換えればよくなります。

// App.OnStart に定義
Set(varDropShadowBI, DropShadow.Regular);

// 各カードコンテナの DropShadow プロパティ
DropShadow: varDropShadowBI

DropShadow の値は DropShadow.Regular のように列挙型で指定します。文字列や数値ではないので注意してください。変数に代入するときも DropShadow.Regular をそのまま入れれば動きます。

一元管理しておくと、例えばダークモード対応を検討したときに影の強さを画面全体で一括調整できます。角丸の一元管理についてはコンテナを使った角丸の一元管理でも同じパターンを紹介しています。DropShadow も同じ思想で管理できます。

影を付けるコンテナと付けないコンテナの判断基準

ネストされたコンテナ構造では、どのコンテナに DropShadow を設定するかが重要です。すべてのコンテナに設定してしまうと、親と子の両方に影がついて影が二重に重なって見えます。これは視覚的にうるさく、逆に品質が下がります。

判断基準はシンプルです。カードの外枠コンテナにだけ DropShadow を設定し、カード内部のレイアウト用コンテナはすべて DropShadow.None にします。

// カード外枠コンテナ（影あり）
DropShadow: varDropShadowBI

// カード内部のレイアウト用コンテナ（影なし・必ず None に）
DropShadow: DropShadow.None

これを意識せずに作ると、カードの中に入っているセクションコンテナにまで影がついて、カード内部に謎の陰影が発生します。私も最初にこれをやらかして、なんか変だなと思いながら原因がわからずしばらく悩みました。ネストしているコンテナが多いほどこの問題は起きやすいので、内側のコンテナは明示的に DropShadow.None を書いておく習慣をつけるといいです。

FillPortions でカードを比率で分割する

複数のカードを横並びにするとき、幅を均等に分割したい場面が多いです。ピクセル値で指定すると画面幅が変わったときに崩れるため、FillPortions プロパティを使った比率指定が便利です。

FillPortions は Auto Layout コンテナの子要素に設定するプロパティで、親コンテナの余白をどの割合で占有するかを指定します。3枚のカードを均等に並べるなら、全カードに FillPortions: 1 を設定します。

// 3枚均等配置
cntCard_3rd1: FillPortions = 1
cntCard_3rd2: FillPortions = 1
cntCard_3rd3: FillPortions = 1

2枚を6：4の比率にしたい場合は FillPortions: 3 と FillPortions: 2 を設定します。3と2の比率が6：4と同じになるからです。比率で指定しているので、親コンテナの幅が変わっても自動的に追従します。

// 6:4 の比率で2分割
cntCardA: FillPortions = 3
cntCardB: FillPortions = 2

FillPortions を使う場合、対象のコンテナには Width プロパティに固定値や式を設定しないでください。FillPortions と Width の両方が設定されていると FillPortions が無視されます。Width はブランクのままにしておくのが基本です。

Fill と DropShadow の組み合わせ：透明コンテナの落とし穴

カード内部のレイアウト用コンテナを透明にする場合、Fill を Color.Transparent に設定します。このとき DropShadow.None を設定し忘れると、透明なコンテナにも影がついてしまい、カードの背景に謎の影が重なって見えます。

Fill=Color.Transparent と DropShadow.None はセットで設定するものだと覚えておくと事故が減ります。レイアウト専用のコンテナは見た目に関わるプロパティをすべてオフにする、という原則を持っておくと、後から原因不明の見た目のバグに悩まされにくくなります。

よくある落とし穴：すべてのコンテナに影をつけてしまう

コンテナを新規追加するたびに、デフォルトのまま DropShadow が None 以外になっていることがあります（設定によって異なります）。そのままネストしていくと、知らないうちに全コンテナに影がついて、画面がごちゃごちゃした印象になります。

これを防ぐには、コンテナを追加したら最初に DropShadow を確認する習慣をつけることです。カード外枠だけ影あり、それ以外は None。このルールを最初から徹底しておけば、後から修正して回る手間がなくなります。

DropShadow と FillPortions を組み合わせて KPI ダッシュボードカードを実装する具体例は、コンテナで KPI ダッシュボードカードを作る方法で詳しく解説する予定です。今回の内容を踏まえた上で読むとコードの意味がよりわかりやすくなります。

まとめ

DropShadow はシンプルなプロパティですが、ネスト構造と組み合わせると細かいルールが必要になります。カード外枠だけに影をつける、内側は必ず None にする、透明コンテナには None をセットで設定する。この3つを守るだけで、影が意図通りに機能するようになります。FillPortions との組み合わせで均等分割も簡単にできます。試行錯誤しながら自分のアプリに合ったデザインを見つけていきましょう。

Power Apps ギャラリー内にコンテナを使ったレイアウト設計｜TemplateWidth・カスタムパディングのパターン

Mon, 06 Apr 2026 22:29:04 GMT

Power Apps のギャラリーは、そのままでは細かいレイアウト調整が難しいコントロールです。内側にコンテナを組み合わせることで、余白・整列・パディングを自由にコントロールできるようになります。

なぜギャラリー内にコンテナが必要なのか

ギャラリーコントロールには TemplatePadding というプロパティがあります。これは各行（テンプレート）の外縁に均等に余白を設定するプロパティです。問題は、すべての辺に同じ値が適用されること。上下に10px、左だけ16px、右は0pxといった非対称なパディングは、TemplatePadding だけでは実現できません。

さらに、テンプレート内のコントロールを右寄せにしたい、あるいは特定の要素を下端に揃えたいといったレイアウト要件も、コントロールを直接ギャラリーに置くだけでは対応しにくいです。ギャラリーの基本的な使い方についてはギャラリーコントロールの基本と検索・選択の組み合わせ方で解説していますが、ここではその先の細かいレイアウト調整を掘り下げます。

こうした問題を解決するのが、ギャラリーのテンプレート内にコンテナを設置するアプローチです。TemplatePadding を 0 にしてギャラリー側の余白管理を放棄し、コンテナ側でパディング・整列・サイズをすべて制御します。

ルートコンテナの基本設定

まず、ギャラリーのテンプレート直下に配置するルートコンテナの設定です。このコンテナはテンプレート全体を覆うように配置するため、以下の4つのプロパティをこの値に設定します。

X: 0
Y: 0
Width: Parent.TemplateWidth
Height: Parent.TemplateHeight

Parent.TemplateWidth と Parent.TemplateHeight を参照することで、ギャラリーのテンプレートサイズが変わっても自動的に追従します。絶対値（ピクセル数）で書くと、ギャラリーの幅を後から変更したときにコンテナだけ合わなくなるという事故が起きます。必ず Parent 参照で書きましょう。

TemplatePadding を 0 に設定する

ルートコンテナを配置したら、ギャラリー本体の TemplatePadding プロパティを 0 に設定します。これでギャラリー側の余白管理を完全にオフにします。以降のパディング・整列はすべてコンテナ側で行います。

この設定を忘れると、コンテナに Padding を設定してもギャラリー側の TemplatePadding が加算されてしまい、意図した余白より広くなる、という現象が起きます。余白を設定したのになぜか大きいと感じたときは、まず TemplatePadding を確認してみてください。

カスタムパディングの2つのパターン

パターン①：コンテナのサイズをテンプレートより小さくする

最もシンプルな方法は、コンテナのサイズをテンプレートより少し小さくして、その差分を余白として使うやり方です。例えば幅を TemplateWidth の 90% にして、残りの 10% を左右の余白として活用します。

Width: Parent.TemplateWidth * 0.9
X: Parent.TemplateWidth * 0.05

垂直方向のセンタリングは少し計算が必要です。コンテナの Height を Parent.TemplateHeight より小さくした上で、Y プロパティに次の式を入れます。

Y: (Parent.TemplateHeight - Self.Height) / 2

テンプレートの高さからコンテナの高さを引いた差を2で割ることで、上下均等に余白が入ります。難しく見えますが、余った空間を半分ずつ上下に振り分けるという発想です。

パターン②：外側コンテナ＋内側コンテナの2層構造

より柔軟な方法は、透明な外側コンテナと見た目を担当する内側コンテナの2層構造にすることです。外側コンテナはパディングだけを担当し（PaddingLeft・PaddingRight・PaddingTop・PaddingBottomをそれぞれ独立して設定）、内側コンテナがカードの見た目（背景色・ボーダー・シャドウなど）を担当します。

この方法の利点は、非対称なパディングが自然に書けることです。左だけ16px、上下は8px、右は0pxといった指定も、外側コンテナのPaddingプロパティを4辺個別に設定すれば実現できます。

内側コンテナには Fill でカード背景色を設定し、外側コンテナは Fill=Color.Transparent にします。これで余白と見た目の責任が分離されるため、後からどちらかだけを変更しやすくなります。

実例：TemplateSize 計算式の読み方

実際のアプリで使っている colResentVessel というコレクションのギャラリーで、TemplateSize プロパティにこんな式が入っています。

(Self.Height - Self.TemplatePadding * 10) / 9

一見複雑ですが、読み解くと単純です。このギャラリーは9行表示を想定しています。ギャラリー全体の高さ（Self.Height）から、行間のパディング合計（TemplatePadding × 10）を引いた残りを9等分する、という計算です。TemplatePadding が10倍になっているのは、9行の間に行間が10箇所あるからです（上端・各行間・下端）。

こういった高さから逆算して行数で割るパターンは、ギャラリーをスクロールさせずにぴったり収めたいときによく使います。体感的に、表示件数が固定されている管理リスト系のアプリでは特に重宝します。

セパレーター（区切り線）を追加する

ギャラリー行間に区切り線を入れたい場合、Rectangle（四角形）コントロールをテンプレート内に配置して使います。Height を 1 に設定し、Y を 0（テンプレートの一番上）に置くと、各行の上部に区切り線が入ります。

Height: 1
Y: 0
Width: Parent.TemplateWidth
Fill: RGBA(220, 220, 220, 1)

BorderStyle を Dashed にすると点線のセパレーターになります。デザインによって実線・点線を使い分けてみてください。コンテナのネスト構造と命名規則を整理しながら作業を進めると、ツリービューが複雑になりにくいです。コンテナのネスト構造の考え方についてはコンテナのネスト構造を作る方法の記事を先に読んでおくと理解が深まります。

まとめ

ギャラリー内のレイアウトを細かく制御したいなら、コンテナを使うのが最善の方法です。TemplatePadding を 0 にしてコンテナに管理を移すことで、非対称な余白・整列・複数要素の配置がすべて柔軟に扱えるようになります。

最初の一歩はルートコンテナをテンプレートと同じサイズで配置するだけです。あとはコンテナのパディングやネスト構造で、やりたいレイアウトに近づけていきましょう。市民開発はこうした地道な積み重ねの連続ですが、一度パターンを覚えると次からは迷わなくなります。

コンテナを使ったレイアウト設計全体の体系についてはPower Apps コンテナ完全ガイドにまとめているので、より深く学びたい場合はそちらも参照してください。

Power Apps ギャラリーでレコードのステータスを一覧表示するレイアウト｜ボタンで状態を色分けする実装

Mon, 06 Apr 2026 22:29:04 GMT

Power Apps のギャラリーでレコードのステータスを色分けして一覧表示したい、というニーズは現場でよく出てきます。AddColumns で計算列を追加し、If 式で色を切り替えるパターンを覚えておけば、たいていの一覧表示要件に対応できます。

AddColumns でギャラリーに計算列を追加する

ギャラリーの Items に AddColumns を使うと、データソースを変更せずに表示専用の列を動的に追加できます。例えば最終更新日や件数をギャラリーの各行に持たせたい場合、AddColumns で LookUp や CountRows の計算結果を列として付与します。

// ギャラリーの Items 式
AddColumns(
    colResentVessel,
    "LastSubmittedDate",
    LookUp(colSubmitLog, VesselID = ThisRecord.ID, SubmittedDate),
    "SubmitCount",
    CountRows(Filter(colSubmitLog, VesselID = ThisRecord.ID))
)

colResentVessel が船舶リストのコレクション、colSubmitLog が提出ログのコレクションです。AddColumns の第2引数以降に列名と計算式のペアを並べます。ここでは LastSubmittedDate（最終提出日）と SubmitCount（提出件数）の2列を追加しています。

このパターンの利点はデータソース（SharePointリストなど）を直接変更しないことです。表示のためだけの計算列をデータソースに追加してしまうと、Power Automate や他のアプリとのデータ連携が複雑になります。AddColumns であれば Power Apps のメモリ上だけで計算が完結します。

ギャラリー内のレイアウト設計の基礎はPower Apps コンテナ完全ガイドで触れています。AddColumns と組み合わせてより実践的なギャラリーを構築する方法がこの記事の主題です。

テンプレートサイズの均等計算

ギャラリーの各行（テンプレート）の高さを均等にするには、ギャラリー全体の高さから行間のパディングを引いて行数で割る式を使います。例えば9行表示する場合の式はこうです。

// TemplateSize プロパティ
(Self.Height - Self.TemplatePadding * 10) / 9

TemplatePadding * 10 は上端・各行間・下端のパディングが合計10か所あるためです（9行の間には10か所の境界がある）。この式でギャラリーの高さが変わっても自動的に9行がぴったり収まります。ギャラリーをスクロールさせずに全件表示したい一覧系の画面でよく使うパターンです。

行レイアウトの構成

横並び要素の配置

1行の中に船舶名・最終更新日・件数・ステータスボタンを横並びで表示します。各要素の幅を固定値で決めて、X 座標を前の要素の X + Width で連結していくと位置が確実に決まります。

// 各要素の X 座標と幅
lblVesselName:   X = 0,   Width = 160
lblLastDate:     X = 160, Width = 120
lblSubmitCount:  X = 280, Width = 80
btnStatus:       X = 360, Width = 100

X を前の要素の X+Width で連結することで、1要素の幅を変えても後続のずれが発生しません。コンテナの Auto Layout を使う方法もありますが、ギャラリーテンプレート内では絶対座標で管理した方がシンプルなケースも多いです。テンプレート内コンテナのレイアウト設計についてはギャラリー内にコンテナを使ったレイアウト設計の記事で詳しく解説しています。

条件付きボタンで状態を色分けする

ステータスボタンは件数が0かどうかで Color・Fill・Text を切り替えます。AddColumns で付与した SubmitCount を使います。

// ステータスボタンの Text
If(ThisItem.SubmitCount > 0, "提出済", "未提出")

// ステータスボタンの Fill
If(ThisItem.SubmitCount > 0, RGBA(46,139,87,1), RGBA(210,100,50,1))

提出済みは緑（SeaGreen相当）、未提出はオレンジ（DarkOrange相当）にしています。私のアプリでは1日の船舶作業提出状況をこのギャラリーで管理しています。朝9時の時点でオレンジが多いと現場に声をかけるきっかけになります。色で状態がわかるというのは、文字で読むより判断が速いので現場に好評です。

ColorFade で背景色とテキスト色を自動対応させる

ボタンの背景色と文字色を手動でそれぞれ設定すると、色を変更するたびに2か所修正が必要になります。ColorFade を使うと、背景色から自動で対応する薄い色を生成できます。

// ボタンの文字色（Color）はFillを70%淡くした色
ColorFade(Self.Fill, 0.7)

ColorFade(Self.Fill, 0.7) は Fill の色を70%薄くした色を返します。背景が緑なら文字は薄い緑、背景がオレンジなら文字は薄いオレンジになります。色の組み合わせを考える手間がなくなる上に、どの色でも一貫した見た目になります。これは体感的にかなり便利で、色の組み合わせを試行錯誤していた時間が大幅に減りました。

DisplayMode.View でステータスボタンをクリック不可にする

ステータスボタンは状態を表示するためのものなので、クリックさせる必要はありません。DisplayMode を View に設定するとクリックイベントが発生しなくなります。

// ステータスボタンの DisplayMode
DisplayMode.View

DisplayMode.View にすると見た目はボタンのままでクリックできない状態になります。Edit にするとクリックでき、Disabled にするとグレーアウトします。ステータスの色分けは表示専用なので View が適切です。Navigate や詳細画面への遷移を担うボタンは別に用意して、役割をはっきり分けておくとコードが読みやすくなります。

区切り線を追加する

ギャラリー行間に区切り線を入れるには、Rectangle を Y=0・Height=1 で配置します。

// セパレーター Rectangle の設定
Y: 0
Height: 1
Width: Parent.TemplateWidth
Fill: RGBA(220, 220, 220, 1)
BorderStyle: BorderStyle.Dashed

BorderStyle.Dashed にすると点線になります。実線にしたい場合は BorderStyle.Solid を使います。行数が多いギャラリーでは区切り線があるだけで視認性がかなり上がります。1行ずつの境界がはっきりすることで、横並びのデータを目で追いやすくなります。

まとめ

AddColumns で計算列を追加し、If で色を切り替え、ColorFade で色を自動対応させる。この3つのパターンを組み合わせれば、データソースを変更することなくリッチなステータス一覧が作れます。DisplayMode.View で表示専用ボタンを作る考え方も、アプリ設計をすっきりさせる上で重要です。市民開発はこういった小さな積み重ねで、現場で本当に使われるアプリに育っていきます。

Power Apps コンテナ完全ガイド｜モダンUIを作るための基礎・レイアウト設計・実践テクニック

Mon, 06 Apr 2026 22:58:08 GMT

Power Apps でモダンなUIを作りたいなら、コンテナの設計を避けて通れません。コントロールをばらばらに並べる時代は終わりました。

私が最初にコンテナを触ったときは、正直なところこれ、何が便利なの？と思っていました。座標でコントロールを置いていく旧来のやり方に慣れていたので、コンテナの概念が最初はピンとこなかったのです。ところが使い込むうちに、画面設計の考え方そのものが変わりました。コントロールをどこに置くかではなく、コントロール同士の関係をどう定義するか——この記事では、そういう設計思想の転換点から始めて、レイアウト設計・実践テクニック・実装事例・開発者向けの管理術まで、コンテナに関するすべてをまとめます。

コンテナとは何か——旧来の座標配置との根本的な違い

Power Apps にはコントロールの配置方法が2世代あります。旧来は X・Y 座標を使った絶対配置で、画面の左上を基準にピクセル単位でコントロールを固定していました。地図に緯度と経度でピンを打つイメージです。これはシンプルで直感的ですが、コントロールが増えるほど管理コストが跳ね上がります。デバイスサイズが変わるたびに全コントロールの座標を手動で修正しなければならず、20個・30個と増えていくとにっちもさっちも行かなくなります。

コンテナを使った配置は、親コンテナとの相対関係で位置やサイズを決めます。Width: Parent.Width * 0.6 のように書けば、親の幅が変わっても60%という関係性は保たれます。駅から徒歩3分、という感覚です。駅の場所が動いても、3分という関係は変わらない。この思想の転換が、コンテナ設計の核心です。

絶対座標が悪いわけではありません。小規模・固定サイズのアプリでは絶対座標のほうがシンプルで速いケースもあります。コンテナの真価はコントロール数が増えたとき・複数デバイスへの対応が必要なときに現れます。座標配置とコンテナの違いを詳しく解説した記事も合わせて読むと、この転換がより腹落ちするはずです。

コンテナの2種類——手動とオートレイアウトの使い分け

コンテナには手動レイアウト（Manual Layout）とオートレイアウト（Auto Layout）の2種類があります。この選択が後のレスポンシブ対応に大きく影響します。

手動レイアウトは、子要素を自由に配置できるコンテナです。自由度が高い反面、レスポンシブ対応は自分で書く必要があります。オートレイアウトは子要素を縦（Vertical）または横（Horizontal）の一方向に並べ、サイズ・間隔・整列を自動で管理してくれます。シンプルなカード・リスト型にはオートレイアウト、重なりや自由な配置が必要な場合は手動レイアウトと使い分けるのが基本です。

よくある失敗は、全部手動レイアウトで作り始めてしまい、後からレスポンシブ対応ができなくなるパターンです。私も最初の頃はそれをやりました。最初の設計段階でどちらを使うか判断しておくことが重要です。手動レイアウトとオートレイアウトの詳しい使い分け基準をまとめた記事も参考にしてください。

画面設計の基本。セクション分割とネスト構造

コンテナ設計で最初にやることは、画面をセクションに分割することです。コードより先に、どう分割するかを決めます。私がよくやるのは、仕切り板を1枚入れるとしたらどちらの向きか、という問いを立てることです。縦に入れてもすべてのセクションが片側に収まるなら垂直コンテナ、横に入れてもすべて片側に収まるなら水平コンテナがルートになります。

ヘッダー・フィルター・ギャラリーが縦積みなら垂直コンテナ、サイドメニューとメインコンテンツが横並びなら水平コンテナです。どちらを試してもセクションが分断されてしまう場合は、粒度が粗すぎるサインです。一段階内側の要素に対して同じ問いを繰り返します。セクション分割の設計思想を詳しく説明した記事に、ケース別の判断基準をまとめています。

セクションが決まったら、その中にさらにコンテナを入れていきます。これがネスト構造です。PCのフォルダ構造をイメージすると分かりやすく、ドライブ→フォルダ→サブフォルダ→ファイルが、画面→ルートコンテナ→セクションコンテナ→個別コントロールに対応します。各階層で向きを決めれば、あとは同じ判断の繰り返しです。ネストが深くなりすぎると管理が辛くなるので、3〜4階層を目安にするとよいです。

配置・整列プロパティを使いこなす

オートレイアウトコンテナには、子要素の配置を細かく制御するプロパティが揃っています。主なものをまとめます。

プロパティ	役割	よく使う値
LayoutAlignItems	交差軸方向の整列	Start / Center / End / Stretch
LayoutJustifyContent	主軸方向の配置	SpaceBetween / Center / Start / End
FillPortions	子要素の幅・高さの比率	数値（例：3と2で60:40に分割）
Gap	子要素間の余白	ピクセル数
Wrap	横コンテナでの折り返し	true / false

特によく使うのが LayoutJustifyContent の SpaceBetween です。更新ボタンと最終更新日を両端に置くような配置が、これ1行で実現できます。FillPortions は子要素に FillPortions: 3 と FillPortions: 2 を設定すれば60対40の比率で幅が分かれます。Padding（コンテナ外縁の余白）と Gap（子要素間の余白）の違いも最初は混乱しやすいので覚えておきましょう。配置・整列プロパティの全詳細はこちらの記事に整理しています。

実践テクニック。角丸・カスタムコントロール・ドロップシャドウ

角丸をコンテナで一元管理する

Dropdown や DatePicker など一部のクラシックコントロールは、ネイティブに BorderRadius プロパティを持ちません。コンテナでラップして、コンテナ側に BorderRadius を設定すると子要素に伝播します。さらに、App.OnStart で変数（例：varRadiusBI）を定義しておき、全コンテナで参照する形にすると、1箇所変えるだけでアプリ全体の角丸が変わります。上だけ角丸にするパターンでは RadiusTopLeft / RadiusTopRight のみ設定して下を0にします。カードの上辺だけ丸くするデザインでよく使います。

カスタムコントロールをコンテナで作る

Label と透明なボタン（Fill=Transparent）をオートレイアウト水平コンテナにまとめると、コピペで量産できるカスタムボタンができます。コピー後は Label の Text と Button の OnSelect を変えるだけで別ボタンになります。プログレスバーは外側コンテナ（背景色・角丸）に内側コンテナ（進捗色）を入れ、内側の Width を Parent.Width * varSubmitted / varAll のように動的に設定する構造です。

ドロップシャドウとFillPortionsでカードUIに奥行きを出す

DropShadow プロパティは None / Light / Regular / Semibold / Bold の5段階があります。カード外枠のコンテナにシャドウを設定し、内部のレイアウト用コンテナは必ず DropShadow.None にします。両方に設定すると境界線のように影が二重になって視認性が下がります。これは地味に気づきにくい落とし穴で、私も最初しばらく原因がわからなかったです。

実装事例。KPIカード・SVGグラフ・ステータスギャラリー

コンテナの使い方を理解したら、実際のダッシュボード実装に応用できます。KPIカードは外側コンテナ（DropShadow・BorderRadius）→内側AutoLayout垂直コンテナ（Padding）→Label群という3層構造が基本形です。3枚均等レイアウトなら水平AutoLayoutコンテナの中で各カードに FillPortions: 1 を設定します。

SVGグラフは "data:image/svg+xml," & EncodeUrl("...SVGコード...") のパターンで Image コントロールに表示します。棒グラフなら LookUp でカウントを取得して棒の長さを動的計算し、ドーナツグラフなら stroke-dasharray と stroke-dashoffset で円弧を描きます。コンテナと組み合わせることで、レイアウト内にグラフを美しく収められます。

ギャラリーでステータスを色分けするには、Count > 0 を条件に Color / Fill / Text を切り替える If 式を使います。ColorFade を使えば ColorFade(Self.Color, 70%) でテキスト色と背景色を自動的に対応させられるので、色の一貫性を保ちながらコード量を減らせます。

開発者UX。命名規則とYAML共有

コントロールが200件を超えると、ツリービューの検索だけでは追えなくなります。命名規則を決めておくことが大切です。推奨プレフィックスは cnt（コンテナ）/ lbl（ラベル）/ btn（ボタン）/ col（ギャラリー）/ img（イメージ）/ rec（レクタングル）。さらに cntBI_1stL（BI領域の1行目・左）のように場所と階層番号を含めると、構造が名前から読めるようになります。

Power Apps Studio のコンテナ右クリック → コードのコピーで YAML 形式のコードが取得できます。別画面・別アプリに貼り付けると構造ごと再現されます。旧来のグループでは子コントロールを1つずつ選択して再配置する必要がありましたが、コンテナなら親を1つコピーするだけで子も全員ついてきます。Slack や Notion にYAMLを貼り付けてチームで共有するワークフローを使えば、デザインの属人化も防げます。

このピラー記事で紹介したコンテナ設計の各テーマは、それぞれ詳細な解説記事に分けています。UI/UX設計の全体的な考え方と合わせて読むと、コンテナをどういう文脈で使うべきかの判断がより明確になります。

まとめ

コンテナ設計は、Power Apps 開発のUIクオリティを一段引き上げる技術です。最初は概念の理解に時間がかかりますが、仕切り板1枚の問い・フォルダ構造のアナロジー・プロパティの一元管理という3つの考え方を体得すれば、どんな画面でも同じプロセスで設計できるようになります。

市民開発とはこういう地道な設計の積み重ねだと、私はつくづく感じています。コードの書き方より先に、どう分割してどう関係を定義するかを考える習慣を身につけると、開発スピードも保守性も大きく変わります。

Power Apps コンテナでKPIダッシュボードカードを作る｜今月件数・前月比・直近7日のカード実装

Mon, 06 Apr 2026 22:29:05 GMT

Power Apps でダッシュボードを作るとき、KPIカードは画面の顔になります。今月の件数・前月比・直近7日間の3枚を横並びで並べて、アプリを開いた瞬間に現場の状況が把握できるようにする。コンテナを使えばこのレイアウトを崩れなく、メンテナンスしやすい構造で実装できます。

カード1枚の基本構造

KPIカードは2層のコンテナで作ります。外側コンテナがカードの見た目（DropShadow・BorderRadius・Fill）を担当し、内側コンテナがコンテンツのレイアウト（Padding・整列）を担当します。内側はAuto Layout の垂直コンテナにして、タイトルラベル・数値ラベル・補足ラベルを上から順に積み上げます。

cntCard_3rd1（外側コンテナ：DropShadow・BorderRadius・Fill）
└─ cntCard_3rd1_inner（内側垂直コンテナ：Padding・LayoutAlignItems）
   ├─ lblCard1Title（タイトルラベル）
   ├─ lblCard1Value（数値ラベル：大きいフォント）
   └─ lblCard1Sub（補足ラベル：前月比など）

外側コンテナの Fill には背景色を設定し、内側コンテナは Fill=Color.Transparent にします。DropShadow は外側だけに設定し、内側は必ず DropShadow.None にします。ネストしたコンテナで両方に影をつけると二重影になるので注意してください。

コンテナクラスターの設計思想の全体像はPower Apps コンテナ完全ガイドでまとめています。KPIカードの実装はその集大成の一つです。

3枚均等レイアウトの組み方

3枚のカードを均等に横並びにするには、親の水平AutoLayoutコンテナに3枚のカードを入れて、各カードに FillPortions=1 を設定します。これで親コンテナの幅が変わっても自動的に3等分されます。

ピクセル値で幅を計算する場合は次の式を使います。

// 3枚均等のピクセル計算式（FillPortionsを使わない場合）
(Parent.Width - Parent.LayoutGap * 2) / 3

LayoutGap * 2 は左右のカード間のギャップが2か所あるためです（カード①とカード②の間、カード②とカード③の間）。残った幅を3等分した値が各カードの Width になります。私は基本的に FillPortions を使う派ですが、カードの最小幅を MinimumWidth で保証したい場合はこのピクセル計算式と組み合わせることがあります。

今月件数カードの実装

3層のラベル構成

今月件数カードはタイトルラベル・数値ラベル・前月比ラベルの3層で構成します。数値ラベルは FontSize を大きくして視認性を上げ、タイトルと補足ラベルはそれより小さくして情報の階層を作ります。垂直コンテナに入れているので、LayoutAlignItems を Center にすれば横方向の中央揃えが自動でかかります。

各ラベルの Height は固定値か FillPortions で配分します。タイトルを20%・数値を50%・補足を30%にする場合は FillPortions を 1・2.5・1.5 のような比率で設定します。コンテナの高さが変わっても比率が保たれるので、画面サイズを後から変更する際に修正が楽です。

前月比の表示ロジック

前月比をプラスマイナス付きで表示するには If 式で符号を動的に付与します。varDiff に前月同日比の差分件数が入っている前提で、次のように書きます。

// 前月比ラベルの Text 式
If(varDiff > 0, "+", "") & Text(varDiff, "0") & "件"

varDiff がプラスのときだけ + を付け、マイナスのときは Text 関数が自動でマイナス記号を付けてくれます。ゼロのときは符号なしで 0件と表示されます。変数の基本についてはPower Apps のグローバル変数とコンテキスト変数の記事で詳しく解説しています。

さらに varDiff の正負で文字色を切り替えると視認性が上がります。

// 補足ラベルの Color 式
If(varDiff >= 0, RGBA(46, 139, 87, 1), RGBA(210, 70, 70, 1))

プラスなら緑、マイナスなら赤にすることで、数字を読まなくても瞬時に良し悪しが判断できます。ダッシュボードはこういった情報設計の積み重ねが大切です。シンプルですが、実際の現場で使うと見やすいと好評でした。

未対応件数カードの実装

未対応件数カードは、総件数から完了件数を引いた差分を表示します。数値ラベルの Text 式はシンプルです。

// 未対応件数の計算
Text(varTotalCount - varCompletedCount, "0") & "件"

未対応件数がゼロかどうかで補足テキストを切り替えると、アラートとして機能するカードになります。

// 補足ラベルの Text 式
If(
    varTotalCount - varCompletedCount > 0,
    "要対応あり",
    "すべて完了"
)

要対応ありのときは文字を赤にして、すべて完了のときは緑にする。私のチームでは毎朝の船舶管理確認にこのカードを使っていて、赤が出ている日は即対応を確認するようにしています。朝のミーティングでこのカードを映した瞬間に全員が状況を把握できるので、言葉で説明する手間が省けます。

直近7日カードの実装

直近7日の件数は、Filter で期間を絞ったコレクションの CountRows を表示します。ClearCollect でデータを取得しているコレクションが colData だとすると、次のように書きます。

// 直近7日の件数
Text(
    CountRows(
        Filter(colData, UpdatedDate >= DateAdd(Today(), -7, TimeUnit.Days))
    ),
    "0"
) & "件"

DateAdd(Today(), -7, TimeUnit.Days) で7日前の日付を計算し、それ以降のレコードだけを Filter で絞り込んで CountRows で件数を取得します。コレクションはすでにメモリ上にあるので委任の問題が起きません。データソースに直接 Filter をかけると委任の警告が出ることがありますが、ClearCollect で手元に落としてから Filter すれば全件カウントできます。コレクションの基本と使いどころも合わせて確認しておくと理解が深まります。

データ取得とスピナー制御

KPIカードのデータは画面を開いたときと更新ボタンを押したときに取得します。更新ボタンの OnSelect に ClearCollect を書いて、取得中はスピナーを表示する設計が使いやすいです。

// 更新ボタンの OnSelect
Set(varSpinner, true);
ClearCollect(colData, DataSource);
Set(varSpinner, false);

varSpinner が true のあいだはローディング表示のコンテナを Visible にして、false になったらカードを表示する切り替えです。データ件数が多いと取得に数秒かかることがあるので、スピナーがないとアプリが固まったように見えます。私も最初はスピナーなしで作っていましたが、現場から「ボタンを押しても何も起きない」と言われてから必ず入れるようにしました。

まとめ

KPIカードはコンテナの構造・変数管理・Filter の組み合わせで作ります。カード1枚の構造を覚えてしまえば、3枚目でも5枚目でも同じパターンで作れます。前月比の符号表示や色の切り替えなど、細かい仕掛けを一つ入れるだけで現場での使い勝手がぐっと上がります。ダッシュボードは地道な積み重ねで育てていくものです。

Power Apps 手動レイアウトとオートレイアウトの使い分け｜選ぶ基準と切り替え方

Mon, 06 Apr 2026 22:40:39 GMT

Power Apps のコンテナには手動レイアウトとオートレイアウトの2種類があります。どちらを選ぶかでアプリの設計の自由度と保守のしやすさが大きく変わるので、最初に整理しておくことをおすすめします。

2種類のコンテナの概要

手動レイアウト（Manual Layout）とは

手動レイアウトは、コンテナの中に追加した子コントロールを、引き続き X・Y 座標や Width・Height で自由に配置できる方式です。コンテナという箱を用意しつつも、中の配置は自分でコントロールするため、座標配置に近い感覚で使えます。

イメージとしては区画は決まっているが、家具の置き方は自由な部屋のようなものです。コンテナで画面をいくつかの領域に分割しつつ、各領域の中はドラッグ&ドロップで好きなように配置できます。複雑なレイアウトや、コントロール同士が重なり合うデザインを実現したいときには、手動レイアウトが向いています。

オートレイアウト（Auto Layout）とは

オートレイアウトは、コンテナ内の子要素を縦方向（Vertical）または横方向（Horizontal）の一方向に自動的に並べる方式です。子要素の間隔・整列・折り返しを Wrap・Gap・Align などのプロパティで一元管理できます。子コントロールの X・Y 座標は自分では設定せず、コンテナが自動的に計算して並べます。

等間隔に並べて、要素が増えても自動で詰めてくれる棚のようなイメージです。商品を追加したら棚が自動で整列し直してくれる感覚です。カード型の一覧表示やボタンを横並びにするナビゲーションバーなど、規則的な繰り返しのレイアウトにとても向いています。

どちらを選ぶか：判断基準

2種類の使い分けを表でまとめます。

場面	おすすめ	理由
カード一覧・リスト表示	オートレイアウト（縦）	要素の増減に自動追従する
横並びのボタン・ナビ	オートレイアウト（横）	間隔・整列を自動管理できる
コントロールを重ねるデザイン	手動レイアウト	重なりや自由配置が必要なため
複雑な非構造的デザイン	手動レイアウト	オートレイアウトでは実現しにくいことがある
将来的にレスポンシブ対応したい	オートレイアウト	相対サイズ・自動整列でデバイス対応しやすい

シンプルなカードやフォームのように、縦か横に規則的に並べたい場合はオートレイアウトを選ぶのが基本です。一方、コントロールが複雑に重なり合うダッシュボードや、グラフと数値を重ねて表示するような場面では、手動レイアウトのほうが作りやすいです。

オートレイアウトの主要プロパティ

オートレイアウトを使い始めたときに最初に設定することになるプロパティを整理します。

Direction（方向）：Vertical（縦）か Horizontal（横）か。最初に決める一番重要なプロパティ
Gap（間隔）：子要素同士の間隔をピクセルで指定。0 にすると間隔なしで詰まる
AlignItems（整列）：主軸と交差軸方向の整列を制御。Center・Start・End・Stretch から選ぶ
Wrap（折り返し）：子要素が横幅に収まらない場合、次の行に折り返すかどうかを制御する
Padding（余白）：コンテナの内側の余白。上下左右それぞれ設定できる

コンテナの種類の切り替え方

追加後でも Variant プロパティで変更できる

コンテナを挿入した後でも、Variant（バリアント）プロパティを変更すれば手動レイアウトとオートレイアウトを切り替えられます。値は ManualLayout か VerticalAuto・HorizontalAuto のいずれかです。

最初にどちらで作ったか気にしすぎなくても大丈夫で、設計途中でやっぱりオートレイアウトにしたいと思ったら切り替えればいいだけです。ただし切り替えると既存の子要素の配置が変わることがあるので、子要素の数が多い状態で変更するとレイアウトが崩れる可能性があります。なるべく早い段階で決める方が安全です。

よくある失敗パターン

全部手動で作ってしまいレスポンシブ対応できなくなる

私が社内でアプリのレビューをしていてよく見かけるのが、コンテナを使っているのに全部手動レイアウトにしてしまっているケースです。コンテナで画面を区切りつつ、中はすべて座標配置の感覚で作ってしまうパターンで、これだと座標配置との違いが活かせていません。

後からタブレット対応やスマホ対応の要望が来たとき、全部手動レイアウトで作ってあると修正範囲が広くなってしまいます。最初からオートレイアウトを使っておけば、Gap や AlignItems の調整だけで大部分が自動追従してくれます。設計段階で少し頭を使うだけで、後の工数が大きく変わります。

オートレイアウトに何でも詰め込もうとする

逆に、オートレイアウトを知ってから全部オートレイアウトで作ろうとして、重なりが必要な部分で詰まってしまうことも多いです。オートレイアウトは子要素を一方向に整列する仕組みなので、コントロールを重ねるような設計には向いていません。グラフの上にラベルを重ねたいとか、画像にテキストをかぶせたいといった場面では手動レイアウトが必要です。

2種類の使い分けを覚えたら、このセクションはリスト状に並べたいからオートレイアウト、このセクションは重なりが必要だから手動レイアウトと、コンテナごとに方針を変えていくのが実践的な使い方です。コンテナは何段でもネストできるので、外側のコンテナはオートレイアウト、内側の特定のコンテナだけ手動レイアウトという組み合わせも全く問題ありません。

また、コンテナとドラッグ&ドロップ配置の根本的な違いについてはPower Apps コンテナと旧来の座標配置との違いの記事で解説しています。コンテナを使い始める前に読んでおくと、この記事の内容もスムーズに理解できます。

まとめ

手動レイアウトは自由度が高いぶん、自分で配置を管理する必要があります。オートレイアウトは整列・間隔を自動管理してくれるぶん、重なりや複雑な配置は苦手です。どちらが正解というわけではなく、作りたいレイアウトに合わせて選ぶことが重要です。

最初はオートレイアウトを使ってみることをおすすめします。カード一覧やボタン並びの場面で使ってみると、ああ、これは楽だと実感できると思います。手動レイアウトが必要な場面はそのうち自然とわかってくるので、まずはオートレイアウトを使える場面で積極的に使ってみてください。楽しみながらコンテナを使いこなしていきましょう。

慣れてくると総合的にコンテナの理解が深まってきますので、あらためて全体をまとめて確認してみましょう。

Power Apps コンテナの命名規則とツリービュー整理術｜階層が深くなっても迷わない管理方法

Mon, 06 Apr 2026 22:29:03 GMT

Power Apps でアプリが大きくなってきたとき、ツリービューがカオスになった経験はありませんか。コントロールが増えるにつれて、あのボタンどこだっけ、このラベルは何のためにあるのかという状況が必ず訪れます。命名規則とツリービューの整理術を最初から意識しておくだけで、後からの修正コストが劇的に下がります。

命名規則がなぜ必要なのか

Power Apps Studio のツリービューは、コントロール数が増えると一覧で確認するだけでも時間がかかります。体感ですが、コントロールが200件を超えたあたりから検索だけでは追いきれなくなります。私が最初に作ったアプリはまさにそれで、Button1・Button2・Button3が乱立していて、どのボタンが何をするのか自分でも把握できなくなっていました。

命名規則がない状態でチーム開発をすると、さらに問題が深刻になります。Power Apps はコントロール名がそのまま数式の参照先になるため、名前が不明瞭だと数式を読んでいるときにこれは何を参照しているのかが一瞬でわからなくなります。自分が書いた数式でも、数週間後に見直すと意味がわからなくなるのが正直なところです。

コンテナ構造を使うアプリでは特にこの問題が顕著です。コンテナは階層が深くなりやすいため、ツリービュー上のどのコンテナがどのセクションに対応しているかが、名前だけで判断できる状態にしておくことが重要です。コンテナの設計思想についてはPower Apps コンテナ完全ガイドで全体像を整理しているので、合わせて参照してください。

推奨プレフィックス一覧

コントロールの種類ごとにプレフィックスを決めておくと、名前を見ただけでコントロールの型がわかるようになります。以下が私が実際に使っているプレフィックスです。

プレフィックス	コントロール種別	例
cnt	コンテナ（Container）	cntHeader、cntBIArea
lbl	ラベル（Label）	lblTitle、lblLastUpdate
btn	ボタン（Button）	btnSave、btnRefreshBI
gal / col	ギャラリー（Gallery）	galRecords、colResentVessel
img	イメージ（Image）	imgIcon、imgBarchart
rec	レクタングル（Rectangle）	recSeparator、recLeft
txt	テキスト入力（TextInput）	txtSearch、txtComment
ddl	ドロップダウン（Dropdown）	ddlStatus、ddlDepartment
ico	アイコン（Icon）	icoEdit、icoDelete
frm	フォーム（Form）	frmDetail、frmEdit

最初はプレフィックスを覚えるのが面倒に感じるかもしれません。ですが一度習慣にしてしまえば、逆にプレフィックスなしでは落ち着かなくなります。私も今では命名なしでコントロールを置くことが気持ち悪く感じるくらいです。

階層と場所を名前に含める

プレフィックスだけでは不十分です。コンテナのネスト構造が深くなると、どのコンテナがどの画面のどのエリアに属しているかが名前からわからなくなります。そこで「場所＋階層番号」を名前に含める方法が有効です。

私のアプリ scrHome での実例を紹介します。ホーム画面のBIエリアには次のような命名をしています。

cntAll_Home（ルートコンテナ・ホーム画面全体）
cntRight_Home（右エリア・ホーム画面）
cntBI（BIセクション全体）
cntBI_1stL（BIの1行目・左側）
cntBI_2ndL（BIの2行目・左側）

この命名を見るだけで、ツリービューのどこを開けばよいかが名前から推測できます。1stL・2ndL という連番は1行目・2行目の意味で、L は Left（左）を指しています。コンテナのネスト構造の設計についてはコンテナのネスト構造を作る方法で詳しく解説しているので、階層設計と合わせて読んでもらえると理解が深まります。

役割を名前に含める

コントロールの名前には、そのコントロールが何をするものかという役割も入れるべきです。プレフィックスで型がわかり、本体部分で役割がわかる。この2要素が揃って初めて名前が機能します。

具体的な例を見てみましょう。

btnRefreshBI：BIエリアのデータを更新するボタン
lblLastUpdate：最終更新日時を表示するラベル
txtSearchKeyword：検索キーワードを入力するテキストボックス
galVesselList：船舶一覧を表示するギャラリー
ddlPhaseFilter：フェーズでフィルタリングするドロップダウン

名前が長くなりすぎることを気にする人がいますが、個人的には多少長くても役割がわかる名前のほうが絶対によいと思っています。Power Apps Studio の数式バーにはオートコンプリートがあるので、名前の途中まで入力すれば候補が出ます。長い名前は入力コストにならない。短すぎて意味が取れない名前のほうが、後々のコストが高くつきます。

ツリービューでの並び替えと選択操作

命名規則を整備したら、ツリービュー上の操作もスムーズになります。いくつか知っておくと便利な操作をまとめます。

並び替えの方法

コンテナ内の子要素はツリービュー上でドラッグ＆ドロップで順序を変更できます。ただしドラッグが効かない場合があり、その場合は対象のコントロールを右クリックして表示されるメニューから並び替えを選びます。

注意点として、コンテナをオートレイアウト（Auto Layout）に設定している場合、子要素の並び順がそのまま画面上の表示順になります。ツリービューで上にあるほど画面の上（または左）に表示されます。見た目の調整はプロパティではなくツリービューの順序で制御する、という感覚を覚えておくとよいです。

セクション単位での全選択

コンテナ構造の大きなメリットのひとつが、セクション単位での全選択が容易になることです。旧来の平坦なツリービューでは、ヘッダーエリアのコントロールを全選択しようとすると、Ctrlキーを押しながら1つずつ選ぶしかありませんでした。

コンテナがあれば、cntHeader を1クリックするだけでその中のすべての子コントロールが選択対象になります。移動・複製・削除もコンテナ単位で行えるため、画面レイアウトの大規模な調整がずっと楽になります。ヘッダーをまるごと別の画面に移植したいとき、コンテナごとコピーするだけで子コントロールも全員ついてくる点は特に便利です。この点についてはYAML共有の観点からもコンテナをYAMLコードで共有する方法で詳しく紹介しています。

深くなりすぎたときのリファクタリング基準

命名規則を守っていても、ネストが深くなりすぎるとツリービューが読めなくなってきます。目安として3〜4階層が限界で、それ以上は設計を見直すサインと考えてください。

よくある失敗パターンは、レイアウト調整のためにコンテナを積み重ねていくうちに、気づいたら6〜7階層になっていたというケースです。1コントロールしか持たないコンテナが連続している場合は、そのコンテナが本当に必要かどうかを見直す余地があります。ただし整列・パディング目的で1コントロールのコンテナを使うことは正当な理由になります。判断が難しければ、コンテナを省いたときに見た目が崩れるかどうかを試してみましょう。

深すぎる階層に気づいたら、思い切ってフラット化するリファクタリングを行います。一見面倒に見えますが、命名規則が整っていればcntBI_1stL 配下を全部整理するという作業がコンテナ単位で完結するため、旧来の方法より遥かに作業量が少なくて済みます。

チームで命名ルールを共有する方法

個人開発ならば自分が守れれば十分ですが、チームで Power Apps を開発する場合は命名規則をドキュメント化しておく必要があります。口頭で伝えるだけではすぐに崩れます。

私がチームでの勉強会で使っているのは、プレフィックス一覧をSharePointリストに登録しておき、いつでも参照できる状態にしておく方法です。表をひとつ共有するだけで、新しくメンバーが加わったときも命名の統一が保てます。

命名規則がドキュメント化されていると、コードレビューのときに指摘しやすくなります。感覚的な指摘ではなく、ルールに基づいた指摘ができるため、受け取る側も納得しやすいです。社内での Power Platform 推進を担っている立場としては、こういったルール整備が長期的な品質維持に直結すると感じています。

まとめ

命名規則は地味な作業ですが、その恩恵はアプリが大きくなるほど効いてきます。最初にルールを決めてしまえば、後から名前を付け直す作業がほぼなくなります。プレフィックス・場所・役割の3要素を名前に含めるだけで、ツリービューの可読性は大きく変わります。

市民開発とはこういう地道な事柄の積み重ねだと思っています。命名規則ひとつ整えるだけで、1か月後の自分がずっと楽になる。まずは自分のプロジェクトのプレフィックス表を1枚作るところから始めてみてください。

Power Apps コンテナのネスト構造を作る方法｜フォルダ階層のように考えると整理しやすい

Mon, 06 Apr 2026 22:29:04 GMT

Power Apps でコンテナを使い始めると、すぐに直面するのがネスト（入れ子）構造です。コンテナの中にさらにコンテナを入れる。これが理解できると、画面設計の見通しが一気に良くなります。

ネスト構造とは何か

ネストとは、コンテナの中にさらにコンテナを入れる構造のことです。マトリョーシカ人形を思い浮かべる方もいるかもしれませんが、実際の操作感はPCのフォルダ構造に近いです。ドライブの中にフォルダがあり、その中にサブフォルダがあり、さらにその中にファイルが入っている。Power Apps のコンテナもこれと同じ考え方で設計します。

具体的に対応させると、こうなります。ドライブが画面（Screen）、その直下にルートコンテナ、その中にセクションコンテナ、さらに内側に個別のコントロール（ラベルやボタン）が並ぶイメージです。フォルダ階層を整理するのと同じ感覚で画面を設計できるようになると、コントロール数が増えても迷わなくなります。

実例で追うネスト構造：scrHomeの4階層

実際に私が業務で使っているアプリのホーム画面（scrHome）を例に取ると、ネスト構造は4階層になっています。ざっくりとした骨格はこうです。

cntAll_Home（垂直コンテナ：画面全体）
└─ cntRight_Home（垂直コンテナ：メインコンテンツ領域）
   └─ cntBI（水平コンテナ：KPI表示エリア）
      └─ cntBI_1stL（水平コンテナ：KPI行の左側）
         └─ lblLastUpdate（ラベル：最終更新日）
         └─ btnRefreshBI（ボタン：更新）

このYAMLの階層を追いながらなぜここで入れ子にするのかを考えると、構造の意図が見えてきます。cntAll_Home は画面全体を縦に積み上げる垂直コンテナです。その中の cntRight_Home はメインコンテンツを管理する垂直コンテナで、ここでヘッダーとボディの上下関係を制御しています。さらに内側の cntBI は複数のKPIカードを横並びにする水平コンテナ、cntBI_1stL はその中の1行目の左エリアをさらに水平に分割するコンテナです。

各階層でやることはたった一つ。この親コンテナの子要素を縦に並べるか、横に並べるかを決めるだけです。この問いを内側に向かって繰り返すのが、ネスト設計の本質です。コンテナとセクション設計の考え方については、画面をセクションに分割する設計の考え方の記事でより詳しく解説しています。

階層ごとの判断：仕切り板の向きだけを決める

ネスト設計で迷うポイントは、ほぼ一つに集約されます。このコンテナは縦方向（垂直）か横方向（水平）か、という判断です。コンテナの追加後でも Variant プロパティを変更すればいつでも切り替えられますが、最初から方向を意識しておくと後の修正が少なくなります。

判断の基準としてよく使うのが仕切り板を1枚入れるとしたらという問いです。

縦に仕切り板を入れると左右に分かれる。横に仕切り板を入れると上下に分かれる。分けたい子要素がその片側に全部収まる方向が、そのコンテナに設定すべき方向です。これを最初の階層から繰り返すだけで、どれだけ画面が複雑になっても設計プロセス自体は変わりません。

子コンテナが1コントロールしか持たないケース

ネストを組んでいると、子コンテナの中にコントロールが1つしか入らないケースが出てきます。これは省略できるかどうかを判断するポイントです。整列やパディングの目的でコンテナを使っている場合はそのまま残しましょう。一方、単純に場所を決めるためだけに存在しているコンテナであれば、コントロールを直接親コンテナに入れたほうがシンプルになります。

個人的には、後から子要素が増えそうなら残す、増えない確信があるなら省略する、という判断をしています。コンテナの追加は後からでもできますが、後から省略するのは意外と面倒なので、迷ったら残しておく方が無難です。

よくある失敗：ネストが深くなりすぎる

ネスト構造に慣れてくると、今度は深くなりすぎるという問題が出てきます。5階層、6階層と深くなると、ツリービューを縦にスクロールしても全体像が把握できなくなります。私も最初の頃はこれをやってしまいました。ツリービューを開いた瞬間にどこに何があるかわからないという状態になるのは、深すぎるネストのサインです。

目安として、3〜4階層を超えたら設計を見直すことをおすすめします。階層が深くなる原因のほとんどは、1つのコンテナが担う役割が多すぎることです。このコンテナは何のために存在するかを1文で言えないなら、分割・整理のタイミングです。命名規則と合わせてツリービューを整理する方法は、コンテナの命名規則とツリービュー整理術の記事でまとめています。

同じ問いを内側に向かって繰り返すだけ

ネスト設計の良いところは、覚えることがほとんどないことです。縦か横かを決める。この問いを内側に向かって繰り返す。それだけです。最初の画面で慣れてしまえば、次の画面でも同じプロセスで設計できます。

どこから手を付けていいかわからないという段階から、この画面は垂直コンテナから始めて、内側を水平で分けて…と考えられるようになると、Power Apps の開発がぐっと楽になります。ギャラリーの中でコンテナを活用するレイアウト設計については、ギャラリー内にコンテナを使ったレイアウト設計の記事で続きを解説しています。ぜひ合わせて読んでみてください。

Power Apps 画面をセクションに分割する設計の考え方｜仕切り板1枚で方向を決める

Mon, 06 Apr 2026 22:40:38 GMT

Power Apps でコンテナを使ってレイアウトを組むとき、最初につまずくのがどこからコンテナを入れ始めるかです。この記事では、画面をセクションに分割するときの考え方を一つのシンプルな問いに落とし込んで解説します。

設計はコードより先に始まる

ワイヤーフレームで分割を決めてから手を動かす

コンテナのレイアウト設計で一番やってはいけないのは、Power Apps を開いてからその場でコンテナを置き始めることです。行き当たりばったりで作ると、途中で構造を見直したくなったときに大幅な作り直しが発生します。まず紙でもスライドでもいいので、画面に必要なセクションを書き出してから手を動かすのが正解です。

ワイヤーフレームといっても大げさなものは必要ありません。ヘッダー・フィルターエリア・一覧エリア・フッターのような大まかな区切りを四角形で描くだけで十分です。この時点でどの要素がどのグループに属するかを考えることが、コンテナ設計の核心です。

画面テンプレートを出発点にする

ゼロからコンテナ構造を組むのが難しいと感じる場合は、Power Apps の画面テンプレートを活用するのも一つの手です。新規画面を追加するときに選べる Sidebar・Header and main などのテンプレートは、最初からコンテナが適切に配置された構造になっています。これを土台にして、自分のアプリの要件に合わせてコンテナを追加・削除していく進め方は、特に慣れないうちは効果的です。

テンプレートから学べることも多く、ああ、こういう方向でコンテナを組むのかという感覚が身につきます。私もコンテナを使い始めた最初の頃はテンプレートのコンテナ構造を一段ずつ追いかけて理解しました。

方向を決めるシンプルな問い

コンテナの方向（縦か横か）を決めるときに私がいつも使っている問いが、仕切り板を1枚入れるとしたら、縦と横どちらに入れるかです。仕切り板を入れたとき、すべてのセクションが分断されずそれぞれ片側に収まる方向が、そのコンテナの正しい方向です。

たとえばヘッダー・フィルターエリア・一覧エリアが縦に積み重なっている画面なら、横に仕切り板を入れると各セクションが上下に分かれます。つまりこの画面のルートコンテナは縦方向（Vertical）です。一方、サイドメニューとメインコンテンツが左右に並んでいる画面なら、縦に仕切り板を入れると左右に分かれます。この場合は横方向（Horizontal）のコンテナが正解です。

縦分割が正解のケース

ヘッダー・検索バー・ギャラリー・フッターのように画面の要素が縦に積み重なっている場合は、ルートコンテナを Vertical（縦方向）にします。各セクションを縦に並べるので、子コンテナの追加・削除・順序変更がすべて縦方向に影響します。横方向の変更が他のセクションに波及しません。

社内で使う業務アプリの多くはこのパターンです。一覧を見てフォームに入力して保存する、というシンプルなフローのアプリは大体ヘッダーと本文が縦積みになっています。まずこのパターンから覚えておくと応用が利きます。

横分割が正解のケース

左側にナビゲーションメニュー、右側にメインコンテンツという2カラム構成の場合は、ルートコンテナを Horizontal（横方向）にします。左右のカラムがそれぞれ独立して縦に伸縮できるようになります。

タブレット向けのアプリや、画面幅が広いことを前提にしたダッシュボード系のアプリでよく使うパターンです。ナビゲーションはどの画面でも固定幅にしたい場合は Width を固定値にして、メインコンテンツ側に FillPortions を設定すれば残りの幅を自動で埋めてくれます。整列プロパティの使い方についてはコンテナの配置・整列プロパティの解説記事も参考にしてください。

どちらに仕切っても分断される場合

粒度が粗すぎるサイン

縦に仕切っても横に仕切っても、セクションが分断されてしまう場合があります。これは分割しようとしている単位が大きすぎるサインです。一段階内側の要素に対して同じ問いを繰り返してみてください。

たとえばKPIカードが横に3枚並んでいて、その下に折れ線グラフがある画面を考えます。仕切り板を縦に入れると3枚のKPIカードが分断されます。横に入れると、KPIカード群とグラフが上下に分かれます。この場合、横方向の仕切りが正しい。上段（KPIカード群全体）と下段（グラフ）を縦方向のルートコンテナで並べ、上段コンテナの中で3枚のカードを横方向に並べる、という2段階の設計になります。

共通の親を持てるかという別アプローチ

仕切り板の問いと同じことを別の角度から考える方法もあります。この要素たちは共通の親コンテナを持てるか、という問いです。ヘッダー・本文・フッターは縦に積み重なる兄弟なので、親は縦方向コンテナです。サイドメニューとメインコンテンツは横に並ぶ兄弟なので、親は横方向コンテナです。

どちらのアプローチも本質は同じで、要素の関係性から方向を決めるという考え方です。仕切り板の問いのほうが直感的に判断しやすいと感じる方もいれば、親子関係で整理したほうがしっくりくる方もいます。どちらでも答えは同じになるので、自分が使いやすい方で考えてください。

設計の手順をまとめると

ここまでの考え方を実際の作業手順に落とし込むと、次のようになります。

画面に必要なセクションを紙やスライドに書き出す
一番外側の要素群に対して、仕切り板を1枚入れるとしたら縦か横かを問う
答えが出たらルートコンテナの方向を決める
各セクションに対して同じ問いを繰り返し、内側のコンテナの方向を決める
どちらでも分断される場合は粒度を細かくして問い直す

このプロセスを一回覚えると、どんな画面でも同じ手順で考えられます。コンテナの方向を迷うたびに仕切り板どっち？と自問するだけです。コンテナを使ったレイアウト設計全体の体系についてはPower Apps コンテナ完全ガイドにまとめているので、より深く学びたい場合はそちらも参照してください。

まとめ

コンテナのセクション設計は、どこに置くかではなくどう分類するかの問いです。分類が決まれば方向は自然に決まります。仕切り板の問いはシンプルですが、どんな複雑な画面でも同じ問いを繰り返すだけで方向が出せます。設計の前に一度立ち止まって構造を考える習慣をつけると、後からの修正が格段に減ります。地道な設計の積み重ねが、長く使えるアプリにつながります。

Power Apps コンテナ内にSVGで棒グラフ・ドーナツグラフを作る方法｜コードで動くチャートの実装

Mon, 06 Apr 2026 22:29:04 GMT

Power Apps のネイティブグラフコントロールはデザインのカスタマイズに限界があります。SVGコードを Image コントロールで表示すれば、棒グラフもドーナツグラフも自分で設計できます。コードが動くグラフなので、データが変われば見た目も自動で変わります。

なぜ SVG を使うのか

Power Apps のネイティブグラフコントロール（Chart コントロール）は手軽ですが、色・サイズ・フォント・レイアウトの自由度が低いです。デザインを統一したいダッシュボードで使うと、KPIカードとの見た目の差が出てしまいます。かといって PowerBI を埋め込むのはライセンスの問題があります。

SVG はテキストベースのベクターグラフィック形式です。Power Apps の Image コントロールは SVG コードを直接表示できるので、コード内にコレクションや変数の値を差し込めば動的なグラフになります。ファイルサイズも軽く、拡大しても画質が落ちません。私がダッシュボードにSVGグラフを採用したのは、デザインの自由度とパフォーマンスの両方を満たせるからです。

コンテナ内にSVGグラフを組み込む方法はコンテナクラスターの実装事例の一つです。クラスター全体の設計思想はPower Apps コンテナ完全ガイドでまとめています。

Image コントロールで SVG を表示する基本

Image コントロールの Image プロパティに次のパターンで SVG を渡します。

"data:image/svg+xml," & EncodeUrl("SVGコード")

EncodeUrl で SVG コードを URL エンコードすることで、ブラウザが SVG を画像として認識します。SVGコードの中に Power Apps の式（コレクション参照・変数参照）を文字列として埋め込めるのが重要なポイントです。例えば棒の長さを変数で指定したい場合、SVGコード内の width 属性に & で変数を連結します。

"data:image/svg+xml," & EncodeUrl(
    "" &
    "" &
    ""
)

varBarWidth の値が変わると棒の幅が自動で変わります。この仕組みを理解しておくと、棒グラフもドーナツグラフも同じ発想で作れます。

棒グラフの実装

複数フェーズの件数を棒グラフで表示する場合、コレクション colPhaseCount に Phase（フェーズ名）と Count（件数）の列が入っているとします。各フェーズの棒の長さは最大値に対する相対値で計算します。

// 各フェーズの棒幅の計算式（最大値に対する比率×グラフ最大幅）
LookUp(colPhaseCount, Phase = "荷役中").Count / Max(colPhaseCount, Count) * 160

Max(colPhaseCount, Count) でコレクション内の最大件数を取得し、各フェーズの件数をその最大値で割って比率を出します。160 はグラフの最大幅（ピクセル）です。件数が最も多いフェーズが幅160になり、他のフェーズはその比率に応じた長さになります。

これを各フェーズ分 SVG の rect タグで並べるとグラフになります。フェーズが3つあれば rect を3行書きます。y 座標は各行の高さ×インデックスで計算します。

"data:image/svg+xml," & EncodeUrl(
    "" &
    "" &
    "" &
    "" &
    ""
)

rx=‘4’ は棒の角丸です。コンテナの BorderRadius と統一しておくとデザインに一体感が出ます。

ドーナツグラフの実装

ドーナツグラフはSVGの circle タグと stroke-dasharray・stroke-dashoffset の組み合わせで作ります。少し数学的な話になりますが、仕組みを一度理解すれば応用できます。

半径 38px の円の円周は 2×π×38 ≈ 238.8 です。stroke-dasharray=“238.8” を設定すると、円周全体が1本の線として扱われます。そこに stroke-dashoffset で「この長さだけ線をずらす」と指定することで、円の一部だけを表示できます。

"data:image/svg+xml," & EncodeUrl(
    "" &
    "" &
    "" &
    "" & Text(varCompletedRate * 100, "0") & "%" &
    ""
)

stroke-dashoffset に 238.8×(1-完了率) を設定することで、完了率が100%なら offset=0（全部表示）、0%なら offset=238.8（全部隠れる）となります。transform=‘rotate(-90 50 50)’ で開始位置を12時方向に合わせています。SVGのデフォルトは3時方向から始まるので、-90度回転させています。

varCompletedRate は 0〜1 の小数で持っておくと計算式がシンプルになります。完了件数÷総件数で出します。ゼロ除算の対処は If 式で同様に対応してください。

不可視ラベルで中間値を保持するパターン

SVGのImage式の中に長い計算式を直接書くと、EncodeUrl の中でエラーが出たときにどこが悪いかわかりにくくなります。そこで、中間値をラベルに保持しておいてImage式からそのラベルを参照する方法が有効です。

Visible=false のラベル（例：lblCalcBarWidth）を画面に置いて、Text プロパティに計算式を書きます。

// lblCalcBarWidth の Text プロパティ
Text(LookUp(colPhaseCount, Phase = "荷役中").Count / Max(colPhaseCount, Count) * 160, "0")

Image コントロールの Image 式ではラベルのテキストを参照します。

// Image式内での参照
"width='" & lblCalcBarWidth.Text & "'"

これでImage式がすっきりし、計算結果をラベルで目視確認しながらデバッグできます。私もSVGグラフを初めて作ったとき、EncodeUrl の中でエラーが出て何時間も悩みました。それ以来、複雑な計算はすべて不可視ラベルに出してから Image 式で使うようにしています。

まとめ

SVGグラフは最初のとっつきにくさがありますが、仕組みを理解すれば自由度が高くパフォーマンスも良い選択肢です。棒グラフはデータの最大値に対する比率で棒幅を計算する、ドーナツグラフは stroke-dashoffset で円弧を切り取る。この2パターンを覚えておけば、ダッシュボードのグラフ表現の幅が大きく広がります。デバッグは不可視ラベルを使いながら進めると格段にやりやすくなります。

Power Apps コンテナとは？旧来の座標配置との違いを絶対値 vs 相対値で理解する

Mon, 06 Apr 2026 22:40:39 GMT

Power Apps のコンテナを使うと、アプリのレイアウト管理がまるで別物になります。旧来の座標配置との違いを理解しておくだけで、画面サイズ対応やコントロールの並び替えがぐっと楽になるので、ぜひ最後まで読んでください。

旧来の配置方式とは何か

X・Y座標でコントロールを固定する仕組み

Power Apps の旧来のアプリ（いわゆる1st Generation、または座標配置モード）では、すべてのコントロールを画面の左上を原点として X プロパティと Y プロパティで配置します。たとえばこのボタンは画面の左から 100px、上から 200px の位置に置くという指定方法です。地図にピンを打つとき、緯度と経度を直接指定するイメージに近い感覚です。

この方式はシンプルで直感的です。ドラッグ&ドロップでコントロールを動かすと X・Y の数値が更新され、何も考えなくても配置できます。小規模なアプリや、画面サイズが固定されている PC 専用ツールなら、これで十分なことも多い。私も最初の頃はこの方法でアプリを作っており、特に困ることはありませんでした。

絶対座標の限界が見えてくるとき

問題はアプリが成長したときです。コントロールが 10 個から 50 個、100 個と増えていくにつれ、座標管理のコストが一気に上がります。あるコントロールの幅を変えたら、その右に並んでいる 10 個のコントロールの X 座標をすべて手動でズラさなければならない。テキストラベルの横幅を少し広げるだけで連鎖的に修正が発生する、という経験はないでしょうか。

さらに深刻なのがデバイス対応です。PC で作ったアプリをタブレットやスマホで開くと、コントロールが画面からはみ出したり、間隔がバラバラになったりします。絶対座標は特定の解像度に依存した設計なので、前提が変わるたびに全コントロールの X・Y を見直す必要があります。社内でデバイスの種類が増えるたびに修正を繰り返すのは、正直しんどい作業です。

コンテナが解決すること

配置の基準が親との関係に変わる

コンテナを使うと、子コントロールの位置とサイズを親コンテナとの相対関係で定義できます。たとえば Width: Parent.Width * 0.6 と書けば、親コンテナの幅が変わっても自動的に 60% の幅を保ちます。緯度・経度で固定するのではなく、駅から徒歩 3 分のような相対的な場所の示し方に切り替わるイメージです。基準点（駅）が動いても、3 分という関係性は変わらない。

この仕組みのおかげで、コンテナのサイズや画面の解像度が変わっても、中のコントロールが自動的に追従します。コントロールを 1 個追加したり順序を入れ替えたりしても、その影響は親コンテナの範囲に留まり、画面全体には波及しません。修正の影響範囲を局所化できることが、座標配置との最大の違いです。

コントロール間の関係を設計する考え方

コンテナを使うと、アプリ設計の思考がコントロールをどこに置くかからコントロール同士の関係をどう定義するかへと変わります。これは地味に大きな転換です。場所を指定するのではなく、構造を設計する感覚です。

ツリービューで見ると、コンテナが親になりその中に子コントロールが並ぶ階層構造になります。どのコントロールがどのグループに属しているかが一目瞭然です。座標配置だとすべてのコントロールがフラットに並ぶため、画面に要素が増えるほどツリービューが読みにくくなります。コンテナを使うと、このあたりの管理しやすさが格段に上がります。

一応私は社内でアプリを教える立場なので、この構造的な設計の話はよく研修でも取り上げます。座標配置で作ったアプリを後から引き継いで修正しようとすると、コントロールの意図が読み取れなくて困ることが多い。コンテナで階層化されていると、ツリービューを見るだけでレイアウトの意図が伝わるので、メンテナンス性がまったく違います。

2つの配置方式を比較する

座標配置とコンテナ配置の違いを 4 つの軸で整理すると、それぞれの特性がはっきりします。

比較軸	座標配置（旧来）	コンテナ配置
基準点	画面の左上が固定原点（X=0, Y=0）	親コンテナが基準（Parent.Width など）
変更時の影響	周囲のコントロールに連鎖しやすい	影響がコンテナ内に限定される
画面サイズ対応	自分で数式を組む必要がある	相対指定で自動追従しやすい
コントロール間の関係	フラットで関係性が見えにくい	親子階層で構造が明確

表を見てわかるように、コンテナが圧倒的に有利な場面はコントロールが多いときと複数デバイス対応が必要なときです。逆に言えば、コントロールが少なく固定サイズの PC 専用アプリであれば、座標配置のほうがシンプルで早いこともあります。どちらが正解というわけではなく、アプリの規模と要件に合わせて選ぶものです。

絶対座標が悪いわけではない

ここまでコンテナの良さを話してきましたが、座標配置を全否定するつもりはありません。単機能のアプリや、プロトタイプをとにかく速く作りたいときは座標配置のほうが手早い。Power Apps の学習を始めたばかりのころも、まず座標配置でアプリの動きを覚えてから、コンテナの概念を学ぶほうが順序として入りやすいと思います。

コンテナの真価が発揮されるのは、コントロール数が増えてきたとき、複数人が同じアプリを引き継ぎながら運用するとき、タブレット・PC など複数デバイスで使うことが決まっているとき、の3つのいずれかに当てはまってからです。最初から全部コンテナで作る必要はありませんが、このアプリは将来大きくなりそうだなと感じたら、設計段階からコンテナを使う習慣をつけておくと後で楽になります。

なお、手動レイアウトとオートレイアウトの2種類のコンテナの使い分けについては、手動レイアウトとオートレイアウトの使い分けの記事で詳しく解説しています。どちらを選ぶかで設計の自由度がかなり変わるので、合わせて読んでみてください。

コンテナの使い方を学ぶ前に押さえるべきこと

Power Apps のUI設計全般に通じる考え方

コンテナの話をすると、UI/UX 設計の話題とセットになることが多いです。コンテナは配置の技術的な仕組みですが、その背景には使いやすいアプリをどう設計するかという考え方があります。Power Apps の UI 設計全般についてはPower Apps の UI/UX 設計の考え方の記事が参考になります。コンテナを使いこなす前に、なぜ見た目と構造を整えることが重要なのかを理解しておくと、コンテナの学習がスムーズになります。

また、アプリのパフォーマンスという観点からも、コンテナを使った構造化設計は有効です。コンテナを使って画面上のコントロール数を適切に管理することは、アプリが重い・遅いときの改善方法にも間接的につながってきます。設計の段階から構造を意識することが、後からの改善コストを下げることになります。

まとめ

座標配置はどこに置くかをピンポイントで決める方式で、シンプルさが魅力です。一方コンテナはどう関係するかを定義する方式で、アプリが大きくなるほど管理の楽さが実感できます。どちらが絶対的に正しいということはなく、アプリの規模と将来の拡張を見越して選ぶことが重要です。

コンテナを使い始めると、最初は少し考えることが増えます。でも慣れてくると、コントロールの位置をいちいち手動で調整しなくて済む設計の快適さがわかってきます。市民開発とはこういう地道な設計の積み重ねだと思っています。コンテナをうまく使いこなして、メンテナンスしやすいアプリを作っていきましょう。

慣れてくると総合的にコンテナの理解が深まってきますので、あらためて全体をまとめて確認してみましょう。

Power Apps の YAML コードでコンテナをチームに共有する方法｜コピペで再利用する実践ワークフロー

Mon, 06 Apr 2026 22:29:02 GMT

Power Apps には、コンテナをそのままYAMLコードとして書き出し、別のアプリや画面に貼り付けて再現できる機能があります。デザインの属人化を防ぎ、チームで同じUIコンポーネントを使い回す上で非常に強力な方法です。

YAMLコピー機能とは

Power Apps Studio では、コンテナやコントロールを右クリックしてコードのコピーを選ぶと、そのコントロールの構造がYAML形式のテキストとして取得できます。YAMLはインデントで階層を表現するテキスト形式で、コンテナのネスト構造がそのまま文字列として出力されます。

この機能が強力なのは、親コンテナをコピーすると子コントロールもすべて含まれる点です。旧来のグループ機能を使っていたころは、子コントロールを1つずつ選択して再配置する必要がありました。コンテナであれば、親を1つコピーするだけで子が全員ついてくる。この違いは実際に試してみると感動するレベルです。

コンテナの設計思想と合わせて理解することで、このYAML共有の価値がより明確になります。Power Apps コンテナ完全ガイドでコンテナ全体の概念を整理しているので、YAMLを活用する前に読んでおくと理解が深まります。

コードのコピーと貼り付けの手順

コードをコピーする方法

Power Apps Studio でコピーしたいコンテナをツリービューまたはキャンバス上で選択する
右クリックメニューを開き、コードのコピーを選択する
クリップボードにYAML形式のテキストがコピーされる

コードを貼り付ける方法

貼り付け先の画面またはコンテナをツリービューで選択する（子として挿入したい親コンテナを選ぶ）
右クリックメニューからコードから貼り付けを選択する
コピーしたYAMLが解析され、コンテナ構造ごと再現される

貼り付け後は、コントロール名が重複しないよう自動的に番号が付与されます。数式内でのコントロール名参照はそのまま引き継がれるため、変数名やコレクション名が一致していれば数式がそのまま動作します。

コンテナ単位での再利用の実例

私が実際にYAMLコピーを使った場面を紹介します。物流管理アプリを作っていたとき、ホーム画面のBIカード（KPIを表示するカードエリア）を別の管理画面にも配置したくなりました。旧来のグループ方式ならラベル・ボタン・レクタングルをひとつずつ選んで配置し直す作業になりますが、コンテナのYAMLコピーを使えばcntBIを右クリック1回でコピーして貼り付けるだけです。

貼り付け後にデータソースの参照先（コレクション名や変数名）を書き換えれば、まったく別のデータを表示するカードとして動き出します。見た目のコードをゼロから書き直す必要がありません。体感で作業時間が半分以下になりました。

このような再利用に向いているのは、カスタムボタンやカード型レイアウトなどのUIパターンです。コンテナで再利用できるカスタムコントロールを作る方法で紹介しているカスタムボタン・プログレスバーの実装も、YAMLでコピーして使い回すと効率が上がります。

チームでYAMLを共有するワークフロー

個人での再利用だけでなく、チームでのUI共有にも使えます。具体的なワークフローを紹介します。

共有の手順

共有したいコンテナを「コードのコピー」でYAMLテキストとして取得する
そのテキストをSlackのコードブロック・Notionのコードブロックなどにそのままペーストしてチームメンバーに共有する
受け取り側は、Power Apps Studio を開いて貼り付け先の画面を準備する
コードから貼り付けでYAMLを読み込み、コンテナが再現される
変数名・コレクション名などのアプリ固有の参照先を修正して完成

このワークフローのよい点は、デザインの再現に画像やスクリーンショットが不要なことです。テキスト1つを共有するだけで、レイアウト・サイズ・色・数式まで全部移植されます。Slackのメッセージ1本でUIコンポーネントのやり取りができるのは、慣れると手放せなくなります。

NotionやSharePointでのテンプレート管理

よく使うUIパターンをNotionのデータベースやSharePointリストにYAMLとして保存しておく方法もあります。「ヘッダーコンポーネント」「KPIカード」「検索フォーム」のように用途別にページを作り、YAMLコードを貼り付けておくだけです。

新しいアプリを作り始めるとき、このテンプレート集から必要なコンポーネントをコピーして貼り付ければ、UIのベースが数分で完成します。私はこれをUIライブラリと呼んでいて、社内推進の勉強会でも紹介しています。エンジニアがコンポーネントライブラリを持つように、非エンジニアがYAMLライブラリを持つという発想です。

貼り付け後に確認すべきこと

YAMLの貼り付けはほぼ自動で完了しますが、いくつかのエラーが出やすい箇所があります。

変数・コレクション名の不一致

貼り付け先のアプリに存在しない変数名やコレクション名を参照している数式があると、エラーが発生します。エラーが出た場合は、Power Apps Studio の「数式バーのエラーマーク」か「App Checker」で一覧確認できます。参照先の名前を修正するか、App.OnStart にその変数・コレクションの定義を追加して対応します。

コントロール名の重複

Power Apps はコントロール名が重複すると自動的に番号を付与しますが（例：cntHeader_1）、数式内の参照先は元の名前のままになっています。そのため、貼り付け後にこのコントロール名は何番になったかを確認してから数式を修正する必要があります。

この問題を防ぐには、命名規則を徹底することが有効です。コンテナの命名規則とツリービュー整理術で紹介しているように、プレフィックスと役割を組み合わせた命名をしておくと、貼り付け後の名前重複が起きにくくなります。

テーマカラー・変数の依存

varRadiusBI や varDropShadowBI のように App.OnStart で定義したテーマ変数を参照している場合、貼り付け先のアプリに同じ変数定義がないとエラーになります。貼り付けるコンポーネントが依存している変数のリストを事前にメモしておき、貼り付け先にも同じ定義を追加する手順を踏むとスムーズです。

コンポーネントとの使い分け

Power Apps にはコンポーネントライブラリという仕組みもあります。YAMLコピーとコンポーネントはどちらも再利用を目的としていますが、得意な場面が異なります。

比較項目	YAMLコピー	コンポーネントライブラリ
使い回しの範囲	同一アプリ内・別アプリ（コピペ）	複数アプリ（ライブラリから参照）
変更の反映	コピー後は独立。変更は各コピーに個別適用が必要	ライブラリ更新で全アプリに反映できる
プロパティの外部注入	不可。貼り付け後に直接編集	可能。カスタムプロパティで値を渡せる
習得コスト	低い。右クリック2回で完結	やや高い。コンポーネントの作成・公開手順が必要
向いている場面	同じアプリ内での使い回し・一時的なUI移植	組織全体で統一UIを使い回す・デザインシステム構築

個人開発や小規模なチームであればYAMLコピーで十分です。組織全体でUIを統一したい場合や、変更を一括反映したい場面ではコンポーネントライブラリが向いています。最初はYAMLコピーから始めて、必要になったらコンポーネントに移行するというステップが無理のない進め方だと思っています。

まとめ

YAMLコピーはコンテナ構造を活かした再利用の仕組みです。右クリックで取り出せるYAMLは、テキストとして自由に持ち運べるUIコンポーネントと考えると、使い道がぐっと広がります。

チームで使う場合は、よく使うUIパターンをYAMLライブラリとして蓄積しておく習慣をつけるとよいです。市民開発とはこういう地道な資産の積み上げだと思っています。一度作ったUIをゼロから作り直さなくてすむ仕組みを整えておくと、次のアプリ開発が確実に速くなります。

Power Appsでデータベースから簡単にアプリを作る手順の紹介

Wed, 07 Feb 2024 22:00:04 GMT

Power Appsでアプリを作るには、データベース（DB）との接続が基本になります。DBの種類によって作り方が異なりますので、Excel・SharePoint（Lists）・Dataverseそれぞれの手順を解説します。

なお、すでにPower Appsライセンスが使用可能な環境であることを前提とします。

アプリ作成ができるようになるまでの流れ

Power Appsは基本的にデータベース（DB）と接続し、そのデータをアプリで表示したり、入力データをDBに保存します。

DBとはつまり、データの入れ物と捉えるとわかりやすいです。

市民開発者レベルで使うDBは主に3種類あります。

Excel
SharePoint（Lists）
Dataverse（データバース）

理由は後で紹介しますが、社内で複数人が利用することを考えると、SharePoint（Lists）、またはDataverseがおすすめです。

Dataverseは高機能で優秀なDBな一方、プレミアムプランが必要なこと、使いこなすのに知識が必要なことから、SharePoint（Lists）を使う機会が多いかもしれません。

Excelは、アプリを使うのが自分一人しかいない場合や、データ量が少ないアプリを作る場合をのぞき、基本的には選択肢から外してしまってもいいでしょう。

Excelをデータソースにするかどうか迷っている方は、Power AppsのデータソースでExcelを評価した記事もあわせて参考にしてください。

ここから先は使用するDB別に紹介しますので、必要な項目をクリックして進んでください。

Excelを使う
SharePoint（Lists）を使う
Dataverseを使う

Excelを使う場合

あまり使う機会はないかもしれませんが、Excelからアプリを作るケースの紹介です。

STEP

OneDriveにExcelファイルを作成する

OneDriveにExcelを作成します。タイトルはわかりやすいもので大丈夫です。
STEP

テーブルを作成する

Excelではテーブルを作成する必要があります。

順を追って説明しますね。

まず下のような一覧表を作ります（内容はなんでもいいです）。

次に作成した一覧を選択し、『テーブルとして書式設定』ボタンを押下します。

どんな見た目にするかを聞かれますので、ここでは仮に青色を選択します。

見出しとして使用するにチェックを入れ、OKを押下します。

これでExcelにテーブルが作成されました。

Power AppsとExcelを繋げるためには、必ずテーブルが必要になりますので覚えておきましょう。

テーブルまで作成できたら、Excelは閉じておいてください。開いたままだと、この先アプリを作成した時にエラーが出てしまいます。
STEP

Power Appsにアクセスして作成を進める

Power Appsのページにアクセスし、『＋作成』を押下します。

Excelを押下します。
STEP

OneDrive for Businessに接続する

『＋新しい接続』を押下します。

OneDrive for Businessを見つけ、『作成』ボタンを押下します。

自分のアカウントでログインし、『Allow Access』を押下します。これで接続に OneDrive for Businessが追加されました。
STEP

Excelと接続する

STEP1で作成したExcelが選択できるようになっているので、そのファイルを押下します。

STEP2で作成したテーブルを選択し、『接続』を押下します。
STEP

アプリが完成

しばらくすると、このようにアプリが完成しました。簡単ですね。

Ctrl+S、または画面右上の保存アイコンを押下し、アプリを保存しておきましょう。

アプリを開くと画面が真っ白のままだったり、『要求されたリソースはロックされています』というエラーが出る場合、開いたままになっているExcelを閉じましょう。Excelが開いていると Power Appsは使えません。

SharePoint（Lists）を使う場合

DB（データベース）でSharePointを使用する場合、Lists（リスト）というものを使います。

見た目はExcelのような表計算に見えますが、中身は違います。

ListsはSharePointサイトに紐づいているサービスですので、使い始めるためにはまずSharePointサイトから作る必要があります。SharePoint Listsを使ったデータの読み書き（追加・更新・削除）の詳細は、Power AppsでSharePointリストのデータを読み書きする記事で詳しく解説しています。

STEP

SharePointサイトを作る

まずSharePointサイトを作りましょう。

SharePointサイトの作り方は2通りあります。

会社によっては新規サイトを自由に作れないよう制限している場合があるため、ここで紹介するどちらかのやり方を使ってSharePointサイトを作りましょう。

まず1つ目が、無難に作成ボタンから進める方法です。

Microsoft 365などのページにいくと、画面左上にアイコンメニューがあるので、それを押下します。

その中にSharePointのメニューがあれば、それを押下します。

もしSharePointが見当たらない場合、下部の『全てのアプリを探索する』を押下します。

さらにその先で『すべてのアプリ』を押下し、表示された先でSharePointを探して押下しましょう。

すべてのアプリを押下し、

その中からSharePointを見つけましょう

無事にSharePointページに飛んだら、次は『サイトの作成』を押下します。

チームサイトの作成を押下します。

標準チームを選択します。

サイト名を決めましょう。

ここでは、社内のどの範囲に向けたアプリを作るかによって名付けを考える必要があります。

例えば自分が所属する営業部だけで使うアプリであれば、サイト名はわかりやすく『営業部DX』がいいかもしれません。

会社の全社員を対象にしたアプリを作るなら、『全社向けサイト』かもしれません。

グループメールアドレスとサイトアドレスも自由に決めることができますので、わかりやすいのがいいでしょう。

全て決まったら『次へ』を押下します。

追加するメンバーを聞かれますが、この時点では空欄でも構いません。

すでに決まっているメンバーがいれば、追加してもいいですね。

完了ボタンを押下すると、これでようやくSharePointサイトが出来上がりました。

このやり方でSharePointサイトが作れた人は、STEP2に進んでください。

会社によっては新規サイトの作成が制限されているかもしれません。

その場合、Teamsでチームを作るとSharePointサイトが付随して自動で作成される特性を活かし、次のやり方をおすすめします。

まず、Teamsを立ち上げます。Webでもアプリでもどちらでも構いません。

Teamsが立ち上がったら、左のメニューの中から『チーム』を選択し、右上のプラスボタンを押下します。

表示されるメニュから『チームを作成』を選択します。

どのようにチームを作成するか聞かれますので、『最初から』を押下します。

次にプライバシー（誰がアクセス可能か）を聞かれます。

これもアプリをどの範囲に向けて作るのかによって選択が変わります。

部単位で作るなら『プライベート』ですし、全社員向けなら『パブリック』『組織全体』ですね。

ここでは『プライベート』を選択することにします。

チームの名前を決めます。

『営業部DX』とか『企画部DX』など、わかりやすいものがおすすめです。

説明は空欄でかまいません。

名前が決まったら『作成』を押して次に進みます。

追加するメンバーは空欄で進めます。

この時点でメンバーが決まっていれば、追加しておいていいでしょう。

無事にTeamsのチームに追加されましたね。

こうやって新しいチームを作ると、自動的にSharePointサイトが1つ作成されます。

どこからSharePointサイトが確認できるかというと、まず次の画像のように、今作成したチームの『一般』スレッドを選択します。

三点リーダー（･･･）を押下すると『SharePointで開く』とありますので、それを選択します。

するとどうでしょう、SharePointサイトが開きました。

このサイトはブックマークしておくといいですね。
STEP

SharePointサイトからListsを新規作成する

STEP1で作成したSharePointサイトにアクセスし、新規ボタンを選択します。

『リスト』という項目が出てきますので、それを押下します。

『空白のリスト』を選択します。

作成するリストの名前を聞かれますので、わかりやすい名前にしましょう。

ここでは例として、次のようにしました。

『サイトナビゲーションに表示』のチェックは外しておきましょう。

はい、これで無事Listsが作成できました。

次はこれに列を作成していきます。
STEP

Listsの列を作成する

作成したリストに列を作成します。

まずは『列の追加』を選択します。

ここでは列に入れる値の種類を選択する必要があります。

今回は『テキスト』を選択し、次へを押下します。

なんという列名にするか聞かれますので、ここでは仮に『名前』と入力します。

それ以外の項目は変更しなくて大丈夫です。

保存を押しましょう。

ここではわかりやすく日本語で列を作りましたが、実際には英語で作ることをおすすめします（Nameなど）。日本語で作ると列の内部名が非常に複雑になるため、扱いづらくなってしまいます。

これで『名前』列が新しく作成されました。

今と同じことを3回繰り返します。

列の追加-テキスト-好きな食べ物（名前）
列の追加-テキスト-好きな教科（名前）
列の追加-テキスト-住所（名前）

ここまで入力すると、下の画像のように列が完成したことでしょう。

ここで気になる『タイトル』という列。

実はこれ、Listsを作成すると最初から1つだけ自動作成されている列なのですが、私はいつも使っていません。

なぜかというと、この列の種類はテキストしか選択することができず、汎用性に乏しいからです。

種類というのはこれのことですね。

Listsは列ごとに保存できる値の種類を明確に決めることができます。

選択肢の列、日付・時刻列の列、数値の列、通貨の列など、さまざまです。

タイトルはこの種類がテキストしか選べず、使い勝手が良くないのです。

ですので、使わないタイトル列は非表示にしてしまいましょう。（削除もできないのがタイトル列のやっかいな点です）

タイトルをクリックし、下の画像のように進みます。

タイトルのチェックマークを外し、左上の適用を選択しましょう。

これでタイトル列が非表示になります。
STEP

Listsに値を入力する

列ができましたので、必要な値を入力していきます。

まずは新規ボタンを押下します。

値を入力する画面が立ち上がります。

この時、さきほど非表示にしたはずのタイトル列が表示されますが（仕様です）、ここには入力しないようにしましょう。

名前、好きな食べ物、好きな教科、住所に値を入力して『保存』を選択すると、まるでExcelのような見た目になってきました。

これと同じことを繰り返しましょう。

なお、いちいち入力画面から入力するのが面倒な場合、『グリッドビューの編集』を選択することもできます。

Excelのようにセル1つ1つに直接入力ができるようになりました。

どちらが入力しやすいかは好みです。

ちなみに私はグリッドビュー入力のほうが好きです。

全て入力が終わると、次のようになりました。

これでListsへのデータ入力が完成です。

ちなみに、不要な行が入ってしまい、それを削除したい時があると思います。

そんな時は、列の左側にチェックマークを入れ、三点リーダー（･･･）から削除することができますよ。
STEP

ListsからPower Appsを作成する

Listsが完成しましたので、Listsをベースにしてアプリを作っていきます。

Power Appsのページから『＋作成』ボタンを押下します。

SharePointを選択します。

『＋新しい接続』を選択します。

接続先から『SharePoint』を探して選択します。

直接接続を選択し、作成ボタンを押下します。

『Allow access』を押下して接続が完了です。

（画像左側）接続にSharePointが追加されました。

（画像右側）STEP1で作成したSharePointサイトが掲載されていますので、それを選択します。

一覧の選択では、STEP2で作成したリストが表示されますので、それを選択します。

しばらくすると、アプリが自動生成されました。

これでSharePoint（Lists）からアプリを作る方法は完了です。

Dataverseを使う場合

Dataverse（データバース）は、Listsよりもより高機能で多くのデータを格納することができるDBのこと。

Listsから乗り換える人は、テーブルの作成でつまづくかもしれませんので、紹介していきますね。

STEP

テーブルを作成する

Dataverseではテーブルを作成し、そこにデータを格納していきます。

まずPower Appsの『テーブル』項目を選択します。

『＋新しいテーブル』を選択します。

Dataverseは最初からテーブルが自動で作成されているため、画像右下にテーブルが存在しています。

『列とデータを追加』を選択します。

『高度なプロパティを設定する』から作ることもありますが、ここでは割愛します。

これで新しいテーブルが作成されました。
STEP

テーブル名、列名を入力する

まず、新しいテーブルに名前をつけます。

鉛筆アイコンを押下し、表示名（テーブルの名前）を入力しましょう。

ここでは『市民開発.com』という表示名にしました。（『複数形の名前』は自動で同じ名前が入力されます）

『高度なオプション』を選択します。

スキーマ名とは、わかりやすくテーブルの内部名称とおぼえておきましょう。

テーブル名にあわせたわかりやすいものを設定しておきます。

保存して次に進みます。

テーブル名を英語にすると、入力した英語がそのままスキーマ名に自動入力されます。

続いて『新しい列』クリック▶『列の編集』に進みます。

表示名を『名前』とし、データの種類をテキスト→プレーンテキストにします。

ここではわかりやすく日本語で列を作りましたが、実際には英語で作ることをおすすめします（Nameなど）。

『高度なオプション』を選択し、スキーマ名を入力して更新ボタンを押下します。

これで名前列が完成しました。

今と同じ要領で、

好きな食べ物-テキスト-プレーンテキスト
好きな教科-テキスト-プレーンテキスト
住所-テキスト-プレーンテキスト

で列を作ります。

スキーマ名も忘れず設定しておきましょう。
STEP

テーブルにデータを入力する

完成したテーブルに、データを入れます。

『作成』を押下し、これでテーブルが完成しました。

本来はデータベース設計を考慮した、もう少し複雑なテーブルが必要になりますが、今回は割愛します。
STEP

Dataverseからアプリを作成する

完成したテーブルからアプリを作ります。

『＋作成』を選択します。

Dataverseを選択します。

接続の種類からDataverseを探し、『作成』を押下します。

無事に接続されると、右側に先程作成したテーブルが表示されますので、それを選択します。

キャンバスアプリが立ち上がりました。

これでアプリが出来上がりました。

アプリ設計に合わせたDBを選択しよう

おさらいです。

市民開発者レベルで使うDBは主に3種類あります。

Excel
SharePoint（Lists）
Dataverse（データバース）

今回は、DBをもとに簡単にアプリを作成する方法を解説しました。

アプリ作りは本来、空の状態から自由に作ることで、Power Apps本来の持ち味を発揮します。まずはDBから自動生成したアプリを触りながら、Power Appsのインターフェースに慣れていきましょう。

Power Appsのアプリ開発全体の流れや設計の考え方については、Power Apps開発の全体マップ記事でまとめて解説しています。あわせて参考にしてください。

手を動かすほど、できることが増えていきます。楽しみながら進めましょう。

Power Apps 式が動かないときの調べ方｜ラベルに式を貼って確認するデバッグ入門

Sat, 18 Apr 2026 08:45:33 GMT

Power Appsで式を書いたのに動かない、変数に値が入っているはずなのに画面に出ない。そういうときに使えるデバッグ手法を整理します。難しいツールは必要ありません。ラベルを1つ置くだけで大半の問題は特定できます。

この記事はエラー・デバッグクラスターのサテライト記事です。エラーの種類の全体像と調べ方の地図はPower Apps 数式エラー解決の全体マップで整理しています。

ラベルデバッグとは何か

ラベルデバッグとは、画面に一時的なラベルコントロールを置き、確認したい式をそのままTextプロパティに書いて結果を目で見る方法です。Power AppsにはVisual Studioのようなステップ実行機能がないため、今この瞬間の値が何かを確認するには、画面に表示するか、Monitorツールを使うかのどちらかになります。

私がPower Appsを使い始めた頃、変数に値が入っているかどうかを確認する方法が分からず、とにかく式を書き直しては試すという非効率な作業を繰り返していました。ラベルデバッグを知ってからは、問題の特定にかかる時間が体感で半分以下になりました。

手順はシンプルです。ラベルを追加して式を書き、アプリを実行して値を確認し、確認が終わったらラベルを非表示にする。これだけです。

変数の中身を確認する

グローバル変数を確認する手順

グローバル変数（Set関数で設定した変数）の中身を確認するには、ラベルのTextプロパティに変数名を直接書きます。

画面にラベルコントロールを追加する
Textプロパティに確認したい変数名を書く（例：varUserName）
アプリを実行して、そのラベルに表示される値を確認する
確認後はラベルを選択してVisibleプロパティを false に設定するか、削除する

変数の値がテキスト型以外の場合は、Text()関数でラップして表示します。

// 数値型の変数を表示する
Text(varCount)

// 日付型の変数を表示する
Text(varSelectedDate, "yyyy/mm/dd")

// 論理型（true/false）の変数を表示する
Text(varIsApproved)

グローバル変数とコンテキスト変数の使い方でも触れていますが、変数の型は最初の代入時に決まります。型が分からなくなったときも、このラベルデバッグで実際の値と型を確認できます。

複数変数を一度に確認する

複数の変数を同時に確認したいときは、& 演算子で結合して1つのラベルにまとめると効率的です。

"ID: " & Text(varSelectedId) & " / 名前: " & varUserName & " / フラグ: " & Text(varIsApproved)

これでラベル1つに複数変数の状態がまとめて表示されます。デバッグ専用のラベルとして画面の隅に固定しておくと、複数の操作を試しながら状態を追いやすくなります。

ギャラリーのデータが出ないときの確認

件数ゼロの原因を切り分ける

ギャラリーにデータが表示されないとき、原因は大きく2つです。データソース自体が空か、Filter関数の条件が厳しすぎてヒットしていないかです。この2つを切り分けるためにCountRowsを使います。

ラベルのTextプロパティに `Text(CountRows(データソース名))` を書く
アプリを実行してラベルの数値を確認する
0より大きい数が出ればデータソースにはデータがある。Filter条件が原因
0が出ればデータソースへの接続か権限の問題

次に、ギャラリーに適用しているFilter条件だけを取り出してCountRowsで確認します。

// ギャラリーのItemsに書いているFilter式をそのままCountRowsに入れて件数確認
Text(CountRows(Filter(SP_Tasks, Status = "進行中")))

0が返ってきたら、条件の文字列が列の値と一致していないことが多いです。列の実際の値（英語・全角半角・スペースなど）と比較している値が一致しているかを確認してください。

複雑な式を分解してデバッグする

With関数で中間値を確認する

長い式の途中の値を確認したいときは、With関数を使うと便利です。With関数はローカルな中間変数を定義できる関数で、式の途中の状態を名前付きで取り出せます。

With関数で数式をすっきり書く方法の記事でも解説していますが、デバッグ目的でも非常に有効です。例えば以下のような複雑な式があったとします。

// デバッグしたい元の式
Text(DateDiff(LookUp(SP_Projects, ID = varProjectId).StartDate, Today(), Days))

この式をWith関数で分解して、中間値をラベルに表示します。

// With関数で分解してデバッグ
With(
    {
        targetRecord: LookUp(SP_Projects, ID = varProjectId),
        startDate: LookUp(SP_Projects, ID = varProjectId).StartDate
    },
    "レコード: " & Text(IsBlank(targetRecord)) &
    " / 開始日: " & Text(startDate, "yyyy/mm/dd") &
    " / 経過日数: " & Text(DateDiff(startDate, Today(), Days))
)

これをラベルのTextプロパティに書いてアプリを実行すると、LookUpがレコードを取得できているか、StartDateに値が入っているか、DateDiffが計算できているかを一度に確認できます。

バイナリサーチ的に問題を絞り込む

式が長くてどこでおかしくなっているか分からないときは、式を半分に切って動くかどうかを確認します。動けば後半が問題、動かなければ前半が問題です。これを繰り返すことで原因箇所を素早く特定できます。

ネストが深い式の場合は内側から外側に向かって確認します。まず一番内側の関数だけをラベルに書いて確認し、正しい値が返ってきたら一段外側の関数を加えて確認する、という順番です。

IfError関数で実行時エラーをキャッチする

IfErrorの基本的な使い方

式の書き方に問題はないのに実行したときだけエラーが起きる場合は、IfError関数でエラーの内容をキャッチして画面に表示します。IfError関数は第1引数の式がエラーになったとき、第2引数の値または処理を実行します。

// Patch操作のエラーをキャッチして画面に表示する
IfError(
    Patch(
        SP_Tasks,
        Defaults(SP_Tasks),
        {Title: TextInput_Title.Text, Status: "未着手"}
    ),
    Notify("エラー: " & FirstError.Message, NotificationType.Error)
)

FirstError.Message には発生したエラーの詳細メッセージが入ります。Notify関数と組み合わせると、アプリ上部にバナーとしてエラー内容が表示されます。

エラーメッセージに列名が含まれている場合は、その列の型や値が正しいかを確認します。Patchで列が見つからない系のエラーが出たときは、SharePointの列の内部名（英語名）とPowerAppsで指定している列名が一致しているかを見直してください。

OnStartやOnVisibleの初期化エラーを確認する

OnStartとOnVisibleの使い分けの記事でも触れていますが、OnStartやOnVisibleに書いた処理でエラーが起きると、変数が初期化されないまま画面が表示されます。そのため、変数が空のままという症状として現れることがあります。

OnStartやOnVisibleの処理をIfErrorでラップしておくと、初期化時のエラーをNotifyで表示できます。

// OnVisibleの処理全体をIfErrorでラップする
IfError(
    ClearCollect(colUsers, SP_Users);
    Set(varCurrentUser, LookUp(colUsers, Email = User().Email)),
    Notify("初期化エラー: " & FirstError.Message, NotificationType.Error)
)

デバッグ用ラベルの後片付けルール

デバッグに使ったラベルを放置しておくと、アプリが重くなる原因になります。確認が終わったらすぐに片付ける習慣をつけてください。

削除するのが一番すっきりしますが、後でまた使うかもしれない場合はVisibleプロパティをfalseにして非表示にしておく方法もあります。ただし、非表示のラベルでも数式は評価されるため、パフォーマンスへの影響がゼロではありません。長期間放置するなら削除することをおすすめします。

後片付け方法	メリット	デメリット
削除する	式が評価されなくなる。アプリが軽い	また使いたいときに書き直しが必要
Visible: false	式を残しておける。すぐ確認再開できる	式は評価され続けるため微妙に重くなる
別画面に移動	デバッグ専用画面として集約できる	管理が複雑になる

私は開発中は Visible: false で残しておき、公開前にまとめて削除するやり方をとっています。公開直前に一度ツリービューを上から確認して、デバッグ用のラベルが残っていないかチェックする癖をつけると安心です。

まとめ

ラベルデバッグは地味ですが、Power Appsで最も頼りになる確認手段です。ラベル1つで変数の状態、ギャラリーの件数、式の途中の値をすべて確認できます。

デバッグが速くなると、開発のリズムが変わります。エラーで詰まる時間が減る分、機能を作る時間が増える。市民開発を続けていく上で、デバッグの習慣は早めに身につけておくと後々かなり楽になります。

Power Apps 委任（Delegation）完全ガイド｜仕組み・非委任関数・回避策・データソース比較

Thu, 02 Apr 2026 16:50:25 GMT

委任を知らずにアプリを作ることは、ユーザーに見えないバグを仕込むことと同じです。Power Appsの委任（Delegation）は、すべてのアプリ開発者が最初に理解しておくべき仕組みです。

委任を無視したアプリが危険な理由

委任の警告（黄色い三角マーク・青い下線）はPower Appsの編集画面にしか表示されません。アプリを使うユーザーの画面には何も出ません。検索しても結果が少ない、一覧に出ないデータがある、選択肢に新しいカテゴリが出てこない。こうした症状がユーザー側で静かに起き続けます。

社内の承認フローや日報管理など、意思決定に使われるアプリで委任問題を放置すると、見えていないデータに基づいて判断を下すことになります。作った本人は気づかないまま、ユーザーだけが不完全な情報を見続ける状況は、無責任なアプリと言わざるを得ません。私が社内でアプリ開発を教えるとき、委任の話を最初にする理由はここにあります。

委任とは何か

委任とは、Power Appsがデータの処理をデータソース側に丸投げすることです。丸投げできる＝委任できる、丸投げできない＝委任問題が発生する、というのが基本の構図です。

Filter関数はSharePointに仕事を投げられます。SharePointサーバーが絞り込みを実行して結果を返すので、10万件のリストでも正しく動きます。一方、Search関数はSharePointが処理を断ります。先頭500件だけブラウザに送られ、ブラウザ上のJavaScriptで検索が走ります。残りのデータは最初から存在しない扱いです。

Power Appsが何もしない＝良いこと、というのが委任の核心です。直感に反しますが、この考え方を掴むと設計の判断が大きく変わります。委任の仕組みと、データが消える具体的な症状については委任とデータの欠落を解説した入門記事で詳しく扱っています。

委任問題が引き起こす3つの症状

ギャラリーの件数不足

ギャラリーはデフォルトで先頭100件しか読み込みません。Search関数を使った検索では、先頭500件の中からしか結果を返しません。リストが成長するほど、新しいデータが検索対象から外れます。数年問題なく動いていたアプリが、ある時期から最新の申請を表示しなくなる、というのが最もよくある症状です。

SearchとDistinctの無警告バグ

Search関数は委任警告が表示されますが、Distinctは警告が出ません。Distinct(リスト, 列名) でドロップダウンの選択肢を生成していると、先頭500件にしか存在しない値しかリストアップされません。新しいカテゴリを追加しても選択肢に出てこない、という問題が警告なしで進行します。

Collectionに逃げても解消しない

ClearCollectでSharePointのデータをコレクションに入れれば委任問題が解消する、という誤解が広まっています。ClearCollect自体が委任の対象なので、先頭500件しかコレクションに入りません。委任警告が消えることで解決したと勘違いしやすい、最も危険なパターンです。コレクションの使い方と委任の関係も参照してください。

主な回避策の概観

委任問題への対処は大きく3つです。それぞれの詳細は委任の回避策を深掘りした記事にまとめています。

StartsWithを使う

Search関数の代わりに、Filter内でStartsWith(列名, 検索文字) を使う方法です。SharePointで委任可能な前方一致検索になります。名前の先頭文字で絞り込む要件であれば、これで十分です。

FilterとSearchをネストする

委任できるFilterで先にレコード数を500件以内に絞り込んでから、その結果にSearchをかける方法です。完全な解決策ではありませんが、ドロップダウン選択後にフリーワード検索するような場面では現実的な選択肢です。FilterとSearchの使い分け基礎も参考になります。

データソースを移行する

DataverseやSQL ServerはSearch関数も委任できます。リストが1万件を超える見込みがある、意思決定に使われる重要なアプリ、SearchやDistinctを避けられない要件がある。このいずれかに当てはまるなら、データソースの移行が根本的な解決策になります。委任対策はアプリのパフォーマンス改善とも直結するので、Power Appsのパフォーマンス改善記事も合わせて読むと判断の材料が増えます。

データソース別の委任力マップ

どのデータソースが何を委任できるかを整理します。移行を検討するときの参考にしてください。

機能	SharePoint	Dataverse	SQL
Filter	◎委任可	◎委任可	◎委任可
Search	✗委任不可	◎委任可	◎委任可
Distinct	✗委任不可（無警告）	要確認	要確認
StartsWith	◎委任可	◎委任可	◎委任可

ユーザーフィルターへの橋渡し

委任を正しく理解した上で次に必要になるのが、ログインユーザーのデータだけ表示するフィルターです。自分の申請だけ表示する、自分宛の承認依頼だけ表示するといった要件は、ほぼすべてのビジネスアプリで発生します。

SharePointではCreated By.Emailで組み、DataverseではAzure AD Object IDで合わせるのが基本です。実装の全パターンはユーザーフィルターの実装ガイドにまとめています。

このクラスターの読み方

委任を初めて知る方はまず入門記事から読み始めることをすすめます。症状の確認と仕組みの理解が先にあると、回避策の話が腹落ちしやすくなります。

委任の仕組みとCollectionの罠を知りたい → Power Apps でデータが足りない原因は委任にある
回避策の選び方・データソース移行の判断基準を知りたい → Power Apps 委任完全理解ガイド
ログインユーザーのデータだけ表示したい → Power Apps でユーザーフィルターを実装する
委任警告の表示の意味が分からない → 委任の警告とは？意味と対処法

まとめ

委任はPower Appsにおける設計の根幹です。知っていると知らないとでは、アプリの信頼性に大きな差が出ます。症状を知り、原因を理解し、要件に合わせて回避策を選ぶ。この流れを身につけておくことが、ユーザーに使ってもらえるアプリを作る上で欠かせません。

Power Apps全体の開発フローについてはPower Apps開発の全体マップも参照してください。市民開発とはこういう地道な積み重ねだと、個人的には思っています。

Power Apps 委任完全理解ガイド｜回避策・Distinctの罠・データソース比較・テスト手法

Thu, 02 Apr 2026 16:50:26 GMT

委任問題を知っているだけでは足りません。どの回避策を選ぶか、そしてデータソースをどのタイミングで移行するか、その判断基準を持っているかどうかが、アプリの品質を左右します。

大きなリストはPower Appsで使えないは誤解

10,000件のSharePointリストがあるとき、Power Appsでは使えないと思っている方がいます。これは半分正解、半分間違いです。委任問題は関数の問題であって、リストのサイズの問題ではありません。

Filterのように委任できる関数を使えば、10,000件のリストでも問題なく動きます。ギャラリーをスクロールし続ければ全件にアクセスすることも原理上は可能です。問題が起きるのは、Search関数やDistinctのように委任できない関数を使ったときだけです。大きなリストが悪いのではなく、非委任関数と大きなリストの組み合わせが問題だということを最初に押さえておきましょう。

委任の定義を再確認する

委任とは、Power Appsがデータの絞り込みや処理をデータソース側に任せることです。先頭500件をブラウザに送り、ブラウザ側のJavaScriptで検索処理が行われます。

仕組みの詳細については委任の基礎とCollectionの罠をまとめた記事で解説しています。この記事では症状の説明は最小限にとどめ、どう対処するかに絞って話を進めます。

500件の意味するもの

非委任クエリの上限は500件（デフォルト値）です。ただしこれは、条件に一致する先頭500件という意味ではありません。リスト全体の先頭500レコードのうち、条件に一致するもの、という意味です。この違いは重要です。

SharePointのリストはレコードが追加された順に並んでいます。新しいレコードはIDが大きく、末尾に積み上がっていきます。リストが育つほど、最近登録されたデータは先頭500件から遠ざかります。Search関数で検索しても最新の申請が見つからない、という症状は、この構造から必然的に生まれます。リストを長期運用するほど深刻化する、構造的な問題です。

警告が出ない非委任の罠

Distinctは青線が出ないまま非委任で動く

Power Appsの編集画面では、委任できない関数に青線や黄色い三角マークが付きます。ただし、Distinctはこの警告が出ないまま非委任で動作します。警告がないから大丈夫、と思っていると痛い目を見ます。

Distinctでドロップダウンの選択肢を生成しているとき、実際には先頭500件にしか存在しない種類しかリストアップされません。新しいカテゴリを追加しても選択肢に出てこない、という問題が静かに進行します。CollectionもClearCollect段階で委任を受けるため、同様の問題があります。青線が消えた＝解決した、は間違いです。

回避策① StartsWithを使う

Search関数の代わりに、Filter内でStartsWith関数を使う方法です。StartsWith(列名, “検索文字”) はSharePointで委任可能なため、10,000件のリストでも正しく絞り込めます。

// Search関数（委任不可）
Search(Mega, TextInput1.Text, "AnimalName")

// StartsWithに置き換え（委任可）
Filter(Mega, StartsWith(AnimalName, TextInput1.Text))

StartsWithは前方一致です。入力した文字列で始まるレコードを返します。検索ワードが先頭から一致していればよい要件、たとえば名前の先頭文字で絞り込む場合はこれで十分です。

一方で、文字列の途中に含まれるものも検索したい場合にはStartsWith単体では対応できません。たとえば田中太郎を太郎で検索してヒットさせたいケースは、StartsWithでは拾えません。この場合は回避策②を使います。

回避策② FilterとSearchをネストする

Filter（委任可）で先にレコード数を大幅に絞り込んでから、その結果に対してSearch（委任不可）を重ねる方法です。FilterがSharePointに仕事を投げてレコード数を減らすことで、Searchが処理する対象を500件以内に収めることを狙います。

// FilterとSearchのネスト
Search(
    Filter(Mega, AnimalColor = Dropdown1.Selected.Value),
    TextInput1.Text,
    "AnimalName"
)

たとえばFilterで絞り込んだ後のレコードが400件以内であれば、そこにSearch関数をかけても全件対象にできます。ただしFilter後のレコード数が500件を超える場合は、Search側でまた漏れが出る可能性があります。

この回避策は完全な解決策ではありませんが、Filter単体では物足りない場面、たとえばドロップダウンで絞り込んだ結果をさらにフリーワード検索したい場合に現実的な選択肢になります。Filterネストのより詳細な実装パターンについてはギャラリーの複合フィルター解説記事も参考にしてください。

回避策の使い分け基準

どちらの回避策を使うかは、要件によって決まります。以下の表を判断の基準にしてください。

要件	推奨回避策
名前の先頭文字・コードの前方一致検索	① StartsWith
複数列にまたがるフリーワード検索	② Filter＋Searchネスト
どちらも使えない（部分一致・大量データ）	データソース移行を検討

前方一致で十分な要件であれば①、複数列をまとめて検索したいなら②、というシンプルな判断フローです。②で対応しきれない場合はデータソース自体を変えることを考える必要があります。

データソース移行の判断基準

DataverseやSQL ServerはSearch関数も委任できます。SharePointで委任問題に悩んでいるなら、データソースの移行が根本的な解決策になります。ただしDataverseはライセンスコストが別途かかるため、費用対効果のトレードオフが必要です。

移行を検討するタイミングの目安として、私はいくつかの条件を持っています。リストが継続的に成長して1万件を超える見込みがある。SearchやDistinctを使わざるを得ない要件が複数ある。アプリが意思決定に使われる重要な業務に組み込まれている、このいずれかに当てはまるなら、移行コストを払う価値があります。反対に、使用者が少なく件数も増えない運用なら、SharePointのまま回避策で対応する判断もあります。データソース別の委任対応状況は以下の表にまとめています。

機能	SharePoint	Dataverse	SQL
Filter	◎委任可	◎委任可	◎委任可
Search	✗委任不可	◎委任可	◎委任可
Distinct	✗委任不可	要確認	要確認
StartsWith	◎委任可	◎委任可	◎委任可

Pro Tip｜本番投入前の委任チェックリスト

アプリをリリースする前に、以下の項目を必ず確認するようにしています。委任限界値を1にするテスト手法については委任の基礎記事で紹介しているので、そちらを参照してください。

確認箇所	チェック内容
ギャラリー	Filter条件は委任可能な関数だけで構成されているか
ドロップダウン	選択肢の生成にDistinctを使っていないか（使っている場合は件数が少ないか）
検索ボックス	SearchをStartsWith or Filterネストに置き換えられているか
コレクション	ClearCollectのデータソースが500件を超えないか

委任の警告はメーカー画面にしか出ません。ユーザーは何も知らないまま不完全なデータを見続けます。回避策を選んだ根拠と、その限界をドキュメントに残しておくことが、責任ある開発者の習慣だと思っています。

まとめ

委任の回避策は、要件と現実のデータ量に合わせて選ぶものです。StartsWithで済むなら①、複合条件が必要なら②、それでも足りないならデータソースの移行を検討する、というフローで考えると整理しやすくなります。

委任を正しく理解して設計に反映させることが、長く使えるアプリを作る上で欠かせません。地道な確認の積み重ねが、ユーザーへの信頼につながります。楽しみながら開発を続けていきましょう。

Power Apps でデータが足りない原因は委任にある｜仕組み・非委任関数・Collectionの罠・テスト法

Thu, 02 Apr 2026 16:50:25 GMT

Power Appsのギャラリーに表示されるデータが少ない。その原因の大半は委任（Delegation）の問題です。Search関数で検索しても結果が足りない、Collectionに入れても解決しない、その理由をこの記事で整理します。

ギャラリーに100件しか表示されない謎

デフォルトで先頭100件しか読み込まない

Power Appsのギャラリーは、デフォルトで先頭100件しかデータを読み込みません。10,002件のSharePointリストにギャラリーをつないでも、最初に表示されるのは100件です。これはPower Appsの仕様であり、バグではありません。

実際の件数を確認したいときは、データソース全体のカウントとギャラリーが取得している件数を別々に出してみると差がよくわかります。なぜ100件しかないんだろうと首をかしげる前に、まずこの仕様を把握しておくことが大切です。

スクロールで増えるが全件ではない

ギャラリーを下にスクロールし続けると、次の100件、さらに次の100件と追加で読み込まれます。無限スクロールのような挙動です。ただし、スクロールで全件取得できるかというとそうではありません。ブラウザが保持できるメモリには上限があり、実測で8,000件前後からクラッシュリスクが高まります。スクロールで増える＝全件取得できている、と考えないようにしましょう。

委任クエリとは何か

委任とは、Power Appsがデータの処理をデータソース側（SharePointやDataverseなど）に丸投げすることです。丸投げできる＝委任できる、というのが基本の考え方です。

Filter関数はSharePointに仕事を投げる

たとえば Filter(Mega, AnimalColor = “Red”) という式を書くと、SharePointサーバーが AnimalColor が Red のレコードを絞り込んで、最初の100件をPower Appsに返します。Power Apps側は何も計算していません。この状態が委任できている状態です。

Power Appsが何もしない＝良いこと、というのは直感に反しますが、これが委任の核心です。サーバーが絞り込んでくれるので、10万件のリストでも先頭100件として正しい結果が返ってきます。

非委任クエリの正体

Search関数はSharePointで委任できない

Search関数はSharePointで委任できません。Search関数を使うと、SharePointは先頭500件をまとめてブラウザに送り、ブラウザ上のJavaScriptが検索処理を実行します。残り9,500件はそもそもPower Appsの手元に届いていないので、検索対象にすら含まれません。

10,000件のリストでSearchを使った場合、実態は先頭500件の中から探しているだけです。リストが育つほど、新しいレコード（IDが大きく末尾に並ぶもの）が検索に引っかからなくなります。個人的には、SharePointとSearchの組み合わせは使わない方針で設計するようにしています。

ユーザーには委任警告が一切見えない

Power Appsの編集画面では、委任できていない関数の下に黄色い三角マークや青い下線が表示されます。しかしこの警告はメーカー（アプリを作る側）にしか見えません。アプリを使うユーザーの画面には何も表示されません。

ユーザーからすると、検索しても結果が少ない、一覧に載っていないデータがある、といった状況が起きるだけです。アプリが壊れているのかと思うかもしれませんが、実際には委任問題が静かに動いています。これが委任を無視したアプリが無責任と言われる理由です。委任警告の表示の見方については委任警告の基礎記事も参考にしてみてください。

よくある現場の症状

私が現場でよく見るのは、数年間問題なく運用していたのに、ある時期から最新の申請が一覧に出てこなくなる、というパターンです。レコード数が積み重なって委任の限界を超えたタイミングで、新しいデータが見えなくなります。長く使われているアプリほどこのリスクが高くなります。

委任の上限が500件のうちはリストが育っていなければ表面上は問題ありません。ところがリストが成長した途端に症状が出始めます。アプリ作成時点では気づきにくいので、設計段階から委任を意識しておく必要があります。

Collectionに逃げても解決しない

ClearCollectも委任上限を受ける

ClearCollect(colStuff, Mega) というように、SharePointのデータをコレクションに入れれば委任の問題が解消する、と思っている方が多いです。残念ながらこれは誤りです。ClearCollect自体が委任の対象であり、Megaから先頭500件（または設定した上限件数）しかコレクションに入りません。

コレクションに入れると委任警告が消えることがあります。これはコレクションはローカルデータなので委任の概念がないためであり、問題が解決したわけではありません。警告が消えた＝解決した、という勘違いが最も危険です。コレクションの詳しい使い方についてはコレクション活用の基礎記事を参照してください。

Distinctも委任されない（しかも無警告）

Distinct(Mega, AnimalType) はドロップダウンの選択肢を生成するときによく使います。ところがDistinctはSharePointで委任できません。しかも委任警告が表示されないまま、委任上限内のレコードからしか選択肢を生成しないという問題を抱えています。

具体的に考えてみます。ネコ・サカナ・イヌ・シマウマ・ウシの5種類が入った10,000件のリストがあるとします。先頭500件にネコしか登録されていなかった場合、Distinct(Mega, AnimalType) の結果はネコだけになります。残りの4種類は存在していても選択肢に出てきません。新しいカテゴリを追加しても選択肢に反映されない、という問題が静かに起きているわけです。

Pro Tip｜委任限界値を1にしてテストする

委任問題を手軽に確認する方法があります。Power Appsの設定から、データ行の制限（行数の上限）を500から1に変更するやり方です。この方法はこの記事だけで紹介するProTipとして、ぜひ習慣化してほしいです。

設定 → 一般 → データ行の制限と進み、値を1に変更します。この状態でアプリを実行すると、非委任クエリは必ず1件しか返さなくなります。大量のテストデータがなくても委任問題を可視化できる、確実な手段です。

Power Apps スタジオを開く
設定 → 一般 → データ行の制限を探す
値を500から1に変更する
アプリを実行して、ギャラリーやドロップダウンの件数を確認する
テスト後は元の値（500）に戻す

私はアプリを本番に出す前にこのテストを必ずやるようにしています。開発中は少量のデータしか入れていないことが多く、実運用で件数が増えてから問題が出るケースが後を絶ちません。1にして正しく動くかチェックするだけで、多くの委任バグを事前に潰せます。

次のステップへ

ここまでで委任の仕組みと、よくある落とし穴を整理しました。では実際にどう対策するのか。StartsWithを使った回避策、FilterとSearchをネストするパターン、データソース移行の判断基準については委任完全理解ガイドで解説しています。また、ログインユーザーのデータだけ表示する実践的なフィルター実装はユーザーフィルター実装の記事にまとめています。

まとめ

委任を理解していないアプリは、データが少ない・検索がおかしい・選択肢が出てこない、という症状を静かに起こします。しかもユーザーには何も伝わりません。アプリを作る側が責任を持って委任を把握しておくことが、使えるアプリを作る第一歩です。

委任の問題は奥が深いですが、まず仕組みを理解するところから始めましょう。知っているだけで設計の判断が大きく変わります。市民開発とはこういう地道な積み重ねだと、個人的には思っています。

Power Appsの委任の警告とは？意味と対処法を初心者向けに解説

Wed, 11 Mar 2026 21:36:53 GMT

Power Appsでフィルターを使ったとき、数式バーに黄色い三角のマークが出た経験はありませんか。あれは委任の警告と呼ばれるもので、放置するとデータが正しく表示されない可能性があります。

委任の警告とは何か

黄色い三角マークの正体

委任の警告は、Power Appsが「この処理をサーバー側に任せることができない」と教えてくれるサインです。簡単にいえば、フィルターや検索の処理がアプリ側（クライアント側）で実行されており、データの取得に上限が生じてしまう状態を意味します。

Power Appsは基本的に、フィルターや並び替えの処理をデータソース（SharePointやDataverseなど）のサーバー側に委任して実行します。これが委任という仕組みです。委任できれば、データが何万件あっても条件に合うものだけをきちんと取得できます。ところが、データソースやPower Appsが対応していない処理の組み合わせでは、委任が成立しません。

500件の壁

委任できない処理が発生すると、Power Appsはデータソースから最大500件（設定を変えれば最大2000件）しかデータを取得しません。その限られたデータの中で条件に合うものを絞り込むため、500件以降に存在するデータは見えなくなります。

具体的なイメージをつかんでおきましょう。SharePointリストに1000件の受注データがあるとします。委任できないFilterを使うと、先頭500件の中から条件に合うものだけが画面に表示されます。残り500件は存在しなかったことになる。現場で使うアプリでこれが起きたら、正しい業務判断ができなくなります。

私も最初は知らずにSearchを使っていて、勉強会で参加者から「なんか件数少なくないですか？」と言われて気づいたことがありました。黄色い三角は気になっていたものの、動いているから大丈夫だと思っていたんですよね。あの経験から、委任の警告は必ず潰す習慣がつきました。

どの関数が委任できて、どれが委任できないか

FilterとSearchの委任可否

Filter関数は、条件の書き方によって委任可否が変わります。SharePointリストを使っている場合、等号や比較演算子（=、<、>）、StartsWith などは委任可能です。一方で、Mid、Left、Len、Trim、EndsWith など文字列の中間を操作する関数は委任できません。

Search関数はあいまい検索ができて便利ですが、SharePointに対しては委任できません。Dataverseなら委任対応していますが、SharePointで全文検索したいときは工夫が必要です。データソースとFilterの組み合わせを以下にまとめます。

関数・条件	SharePoint	Dataverse
Filter（=、<、>）	委任可能	委任可能
Filter（StartsWith）	委任可能	委任可能
Filter（in 演算子）	委任不可	委任可能
Filter（Mid、Left など文字列操作）	委任不可	委任不可
Search	委任不可	委任可能
Sort（単一列）	委任可能	委任可能
CountIf	委任不可	委任不可

委任できないのはどんな処理か

委任が成立しない主なパターンは3つです。

データソースが対応していない関数の組み合わせ（例：SharePointでのSearch、CountIf）
列に対して計算や変換を行う式（例：Left(タイトル, 2) = “東京” のような書き方）
コレクションに対するFilter（これはコレクション自体がローカルなので警告は出ますが件数制限の問題は起きません）

2番目のパターンはついやりがちです。たとえば、列の値の先頭2文字を切り取って比較したいとき、Left関数を使うとSharePointへの委任が成立しません。代わりにStartsWithを使えば委任できるので、前方一致の検索ではStartsWithに書き直す習慣をつけましょう。

データソースによって委任の対応範囲が変わる

Dataverse、SharePoint、Excelの違い

委任の対応範囲はデータソースによって大きく異なります。最も対応が広いのはDataverseで、ほぼすべての関数で委任が成立します。大量データを扱う業務アプリならDataverseが第一候補です。ただし、Microsoft 365のライセンスだけでは使えず、Power Apps Premiumの有料ライセンスが必要になります。

SharePointリストは委任の対応範囲がやや限定的ですが、Microsoft 365を持っていれば追加費用なく使えるので、現場では一番よく選ばれています。委任の制約を把握した上で設計すれば、業務改善の用途では十分に実用的です。SharePointリストとMicrosoft Listsの違いについてはこちらの記事でも解説しています。

ExcelをOneDriveやSharePointに置いてデータソースとして使う場合は注意が必要です。ExcelはFilterやSortを含むほとんどの処理で委任が成立しないため、どんな条件を書いても先頭500件（最大2000件）しか取得できません。データ量が少いならいいのですが、増えてくると途端に危うくなります。Excelをデータソースにするときの考え方はこちらの記事も参考にしてみてください。

上限件数を2000件まで拡張する方法

Power Appsの設定から、データ行の制限を最大2000件まで引き上げることができます。Power Appsスタジオのメニューから設定 → 全般を開き、データ行の制限の値を変更します。デフォルトは500件です。

ただし、これは根本的な解決ではありません。2000件を超えるデータを扱う可能性があるなら、設計を見直す必要があります。上限を上げることで問題を先送りにするのではなく、委任できる書き方に変えることを先に検討してください。

委任の警告が出たときの対処法

委任できる書き方に変える

一番基本的な対処は、委任対応の書き方に変えることです。前方一致の検索をしたいなら、SearchではなくStartsWithを使います。

// 委任不可（SharePointの場合）
Filter(受注リスト, Search(受注リスト, テキスト入力1.Text, "件名"))

// 委任可能（前方一致で代替）
Filter(受注リスト, StartsWith(件名, テキスト入力1.Text))

前方一致に限定するだけで委任が成立します。部分一致が必要な要件かどうかを一度立ち止まって確認してみると、実は前方一致で十分というケースも多いです。

ClearCollectでデータを取得してからFilterする

委任できない処理をどうしても使いたい場合、OnVisibleなどのタイミングでClearCollectを使い、データをコレクションに取り込んでから絞り込む方法があります。

// 画面の OnVisible で全件取得（委任可能な条件で絞り込んでおく）
ClearCollect(colJuchu, Filter(受注リスト, 担当者 = User().Email))

// ギャラリーの Items で部分一致検索（コレクションなので委任の問題なし）
Filter(colJuchu, テキスト入力1.Text in 件名)

コレクションはローカルに存在するデータなので、委任の制約を受けません。ただし、ClearCollectに取り込める件数も最大2000件までです。取り込むタイミングでSharePoint側で絞り込み（委任可能な条件で）、件数を絞ってからコレクションに入れるのがポイントです。

データ設計を見直す

根本的には、2000件を超えるような設計をしないことが最善策です。データを年度や部署ごとにリストを分ける、古いデータをアーカイブリストに移す、といった方針をあらかじめ決めておくと安心です。

私が社内で作った日報アプリを例にすると、1日20件の日報が毎営業日蓄積されます。月400件、年間4000〜5000件になるペースです。SharePointリストを使い続けると3年も経たないうちに2000件を超えます。そこで設計段階から、年度ごとにリストを分ける方針にしました。最初に計算しておくだけで後からの手戻りがかなり減ります。

Power Appsの基本的な仕組みや設計の考え方についてはPower Appsとは？完全ガイドやPower Appsで使える実用テクニックも合わせて読んでみてください。

まとめ

委任の警告は、Power Appsが出してくれる親切なサインです。動いているからといって無視して作り続けると、本番稼働後にデータが正しく表示されないという事態になりかねません。

まずは使っているデータソースと、どの関数が委任できるかを確認することから始めましょう。完璧に委任を通すのが難しいケースも正直あります。そういうときはClearCollectで逃げるか、データ設計を見直すか、割り切りが必要です。ただ、知っているのと知らないのでは大違いです。

委任の制約を理解した上で設計を組み立てていく。これがPower Appsを使いこなすうえで避けては通れない第一歩だと思っています。地道な積み重ねですが、それが後から余計な手戻りを防いでくれます。

Power Apps で編集可能グリッドを作る｜コレクション×ギャラリーコントロールの基本設計

Sun, 29 Mar 2026 19:06:15 GMT

Power Apps でExcelのように行を直接編集できるUIを作りたいなら、コレクションとギャラリーを組み合わせた編集グリッドが最適解です。フォームを使わずにデータを画面内で即時編集できる、使い勝手のいいパターンです。

編集グリッドとは何か

編集グリッドとは、ギャラリーの各行にテキスト入力・ドロップダウンなどの入力コントロールを配置して、Excelのような行編集UIを実現したものです。通常のギャラリーは読み取り専用のリスト表示ですが、編集グリッドは行ごとに値を直接変更できます。

簡単にいえば、Excelのシートを Power Apps の画面上で再現するイメージです。業務の現場では、複数件のデータを一覧で確認しながら一括で修正したい場面がよくあります。フォームを1件ずつ開いて保存するよりも、表形式で直接編集できるほうが圧倒的に速いです。

ただし Power Apps の編集グリッドはデータソースを直接編集するのではなく、一時的なコレクションを中間バッファとして使うのが鉄則です。その理由を含めて、設計の考え方から解説していきます。

コレクションをベースにする理由

編集グリッドにコレクションを使う理由は2つあります。パフォーマンスと操作の自由度です。

SharePoint や Dataverse などのデータソースを直接ギャラリーの Items に渡して、各行を編集しようとすると、行を変更するたびにデータソースへのアクセスが発生します。行が多い場合や通信環境が悪い場合、操作のたびに待ち時間が生じます。コレクションを中間に挟むことで、編集中はローカルのメモリ上で操作が完結し、保存ボタンを押したときだけデータソースに書き込む設計になります。

操作の自由度という意味では、コレクションを使うと行の追加・削除・並び替えをメモリ上で自由に行えます。未保存の状態でキャンセルしたいときも、コレクションを元のデータで上書きすれば簡単に戻せます。コレクションの基本的な使い方はPower Apps のコレクション活用入門で解説しているので、あわせて確認しておくと理解が深まります。

ClearCollect でコレクションを初期化する

編集グリッドの起点は ClearCollect です。OnVisible や画面の読み込みタイミングで、データソースのデータをコレクションに読み込みます。

ClearCollect(colTasks, Tasks)

これでデータソース Tasks の内容が colTasks というコレクションに複製されます。ギャラリーの Items には colTasks を設定します。

列の型を定義するコツ

コレクションの列型は最初のレコードで決まります。ところが実データで ClearCollect すると、数値列が文字列になってしまったり、日付型が崩れるケースがあります。これを防ぐため、空のレコードを先に ClearCollect してから本データを Collect する方法があります。

ClearCollect(colTasks,
  {タスク名: "", 担当者: "", 優先度: 0, 完了: false}
);
Clear(colTasks);
Collect(colTasks, Tasks)

空のレコードで列型を定義してから Clear し、実データを Collect することで、型の不整合を防げます。これは地味ですが、後から数式エラーに悩まされないための重要な一手間です。私もこれを知る前に数値列の比較でエラーが出て、原因究明に時間をかけた経験があります。

ギャラリーに入力コントロールを配置する

ギャラリーのテンプレートに TextInput・Dropdown・ラベルを配置して、編集グリッドを構成します。TextInput は編集可能な列、ラベルは読み取り専用で表示したい列に使います。

ギャラリーを追加し、Items に colTasks を設定する
テンプレート内に TextInput を追加する
TextInput の Default プロパティに ThisItem.タスク名を設定する
必要に応じて Dropdown を追加し、Items に選択肢リストを設定する

TextInput の Default 設定

TextInput の Default プロパティには ThisItem.列名を設定します。これでギャラリーが表示されたとき、各行の現在の値がテキスト入力に自動的に入ります。

ThisItem.タスク名

注意点として、Default は初期表示値を設定するだけで、ユーザーが入力した後は Default の値は反映されません。ギャラリーが再描画されたときに Default が適用されるため、コレクションを更新する前に TextInput のリセットが必要な場面があります。この挙動を最初から理解しておくと、保存ロジックの設計で迷いません。

ドロップダウンを使う列では、Items に選択肢のテーブルを渡します。たとえば優先度列に高・中・低の3択を出す場合はこうなります。

["高", "中", "低"]

ドロップダウンの現在の選択値は Dropdown.Selected.Value で取得できます。後でコレクションにPatchするときに使うため、変数や直接の参照で値を渡せるよう設計しておきます。

Dropdown の Default プロパティには ThisItem.優先度を設定して、現在のコレクションの値がドロップダウンに選択済みの状態で表示されるようにします。

DisplayMode で非編集時の見た目を整える

編集グリッドをずっと編集モードにしておくと、誤操作のリスクがあります。たとえば通常は読み取り専用にしておき、編集ボタンを押したときだけ入力を受け付けるという設計がよく使われます。

これを実現するには、TextInput の DisplayMode プロパティで制御します。

If(varEditMode, DisplayMode.Edit, DisplayMode.View)

varEditMode が true のときだけ編集可能にする、という設計です。編集ボタンを押したときに UpdateContext({varEditMode: true}) で切り替えます。

DisplayMode.View と DisplayMode.Disabled の違いも押さえておきましょう。View は読み取り専用でテキストとして表示されます。Disabled はコントロールがグレーアウトされた非活性の見た目になります。UX的には View のほうが自然に見えるので、通常は View を使うことをおすすめします。

DisplayMode	見た目	用途
Edit	入力可能なテキストボックス	編集中
View	テキスト表示（枠なし）	閲覧中（推奨）
Disabled	グレーアウトのテキストボックス	無効状態を明示したいとき

まとめ

編集グリッドの設計は、大きくまとめると次の3ステップです。

ClearCollect でデータをコレクションに読み込む（型定義→Clear→Collect）
ギャラリーの Items にコレクションを設定し、TextInput・Dropdown の Default を ThisItem で設定する
DisplayMode で編集モードと閲覧モードを切り替える

この基盤ができたら、次のステップは行ごとの保存・新規行の追加・削除・全件保存の実装です。データの書き込みと IsNew フラグの使い方については、編集グリッドのデータ保存の記事で詳しく解説します。

Excelライクな編集UIは現場でも要望が多い機能です。設計パターンを覚えると、他のアプリでもすぐ応用できます。地道に一つずつ実装して、業務改善の幅を広げていきましょう。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps 編集グリッドのデータ保存｜Patch・IsNew・削除・一括保存の実装パターン

Sun, 29 Mar 2026 19:06:15 GMT

編集グリッドの見た目を作るだけなら前の記事で完成しますが、実際に使えるアプリにするには保存・削除・一括保存のロジックが必要です。Patch関数とコレクション操作を組み合わせた実装パターンを一通り解説します。

コレクションを中間バッファとして使う設計の基礎は、編集グリッドの基本設計の記事で解説しています。この記事はその続きとして、データの書き込み操作に特化した内容です。

行ごとの保存：フロッピーアイコン＋Patch

編集グリッドでよく使われる行ごとの保存パターンは、ギャラリーテンプレート内にアイコン（フロッピーディスク）を置き、OnSelect に Patch を書くというものです。

Patch(Tasks, ThisItem,
  {
    タスク名: TextInput_タスク名.Text,
    優先度: Dropdown_優先度.Selected.Value,
    担当者: TextInput_担当者.Text
  }
)

Patch の第1引数はデータソース（Tasks）、第2引数は更新対象のレコード（ThisItem）、第3引数は更新するフィールドと値のレコードです。ThisItem を指定することで、クリックした行のデータだけを更新できます。

Patch 関数の使い方の基本はPatch 関数の解説記事で詳しく触れているので、あわせて確認しておくとより理解が深まります。

Value 関数で数値型変換が必要な理由

TextInput から取り出した値は常にテキスト型です。数値列に Patch しようとするとエラーになります。

Patch(Tasks, ThisItem,
  {
    タスク名: TextInput_タスク名.Text,
    工数: Value(TextInput_工数.Text)
  }
)

Value(TextInput_工数.Text) のように Value 関数で数値に変換してから渡します。入力欄が空のとき Value 関数は Blank を返すため、空白のまま保存されます。空白を 0 として扱いたい場合は Coalesce(Value(TextInput_工数.Text), 0) とすると安全です。

IsNew フラグの役割

編集グリッドで行を追加するとき、既存のレコードと新規で追加した行を区別する仕組みが必要です。そのために IsNew フラグをコレクションに持たせます。

新規行を追加するボタンの OnSelect はこのようになります。

Collect(colTasks,
  {タスク名: "", 優先度: "中", 担当者: "", 工数: 0, IsNew: true}
)

IsNew: true を持つ行が新規追加行です。既存データを読み込んだ行には IsNew: false または IsNew フィールド自体がないため、Patch するときに新規か更新かを判断できます。

IsNew フラグを使った保存ロジックはこうなります。

If(ThisItem.IsNew,
  Patch(Tasks, Defaults(Tasks),
    {タスク名: TextInput_タスク名.Text, 優先度: Dropdown_優先度.Selected.Value}
  ),
  Patch(Tasks, ThisItem,
    {タスク名: TextInput_タスク名.Text, 優先度: Dropdown_優先度.Selected.Value}
  )
)

IsNew が true の場合は Defaults(Tasks) を使って新規レコードとして作成し、false の場合は ThisItem を指定して既存レコードを更新します。Defaults(Tasks) はデータソースのデフォルト値を持つ空のレコードを返します。これが新規作成のサインです。

削除ボタンの実装

削除も IsNew フラグで分岐します。新規行（まだデータソースに存在しない行）はコレクションから削除するだけで済みますが、既存行はデータソースからも削除が必要です。

If(ThisItem.IsNew,
  Remove(colTasks, ThisItem),
  RemoveIf(Tasks, ID = ThisItem.ID);
  Remove(colTasks, ThisItem)
)

IsNew が true なら Remove(colTasks, ThisItem) でコレクションから取り除くだけです。既存行は RemoveIf でデータソースから削除した後、コレクションからも Remove します。セミコロンで複数の処理をつなぐことで1つの OnSelect にまとめられます。

削除確認ダイアログを入れる

削除は元に戻せません。誤操作を防ぐために確認ダイアログを挟むのが安全です。コンテナのVisibleを変数で制御する方法が一般的です。

削除ボタンの OnSelect：UpdateContext({varDeleteTarget: ThisItem, varShowDeleteDialog: true})
確認ダイアログコンテナの Visible：varShowDeleteDialog
はいボタンの OnSelect：上記の削除ロジック実行 → UpdateContext({varShowDeleteDialog: false})
いいえボタンの OnSelect：UpdateContext({varShowDeleteDialog: false})

varDeleteTarget には削除対象の行（ThisItem）を入れておき、はいボタンの削除処理で varDeleteTarget.ID を参照して RemoveIf することで、正確な行を削除できます。

全件保存ボタンの実装

行ごとの保存ではなく、まとめて一括保存したい場合は ForAll を使います。コレクション全体をループして、IsNew フラグに応じて新規作成か更新かを切り替えます。

ForAll(
  Filter(colTasks, タスク名 <> ""),
  If(IsNew,
    Patch(Tasks, Defaults(Tasks),
      {タスク名: タスク名, 優先度: 優先度, 担当者: 担当者, 工数: 工数}
    ),
    Patch(Tasks, LookUp(Tasks, ID = ThisRecord.ID),
      {タスク名: タスク名, 優先度: 優先度, 担当者: 担当者, 工数: 工数}
    )
  )
)

ForAll の第1引数には Filter(colTasks, タスク名 <> “”) を使って空白行を除外してから渡します。タスク名が空の行を保存対象から外すことで、新規行ボタンを押しただけでまだ何も入力していない行が誤って保存されるのを防げます。

既存行の更新には LookUp(Tasks, ID = ThisRecord.ID) で正確なレコードを取得してから Patch します。ForAll の内部では ThisItem の代わりに ThisRecord を使う点に注意が必要です。

保存後にコレクションを再取得する

一括保存が完了したら、コレクションをデータソースから再取得してリフレッシュします。

ForAll(Filter(colTasks, タスク名 <> ""), ...);
ClearCollect(colTasks, Tasks)

ForAll の後に ClearCollect でコレクションを上書きすることで、IsNew フラグがリセットされ、保存済みのデータが最新の状態で表示されます。この一行を忘れると、保存後も IsNew: true の行が残ってしまい、再度保存すると重複レコードが作られるという事故につながります。

まとめ：編集グリッドの保存ロジック全体像

操作	実装
行ごと保存	Patch(DataSource, ThisItem, {…}) with Value() for 数値
新規行追加	Collect(colTasks, {IsNew: true, …})
新規行保存	Patch(DataSource, Defaults(DataSource), {…})
削除（新規行）	Remove(colTasks, ThisItem)
削除（既存行）	RemoveIf + Remove(colTasks, ThisItem)
一括保存	ForAll(Filter(…)) + IsNew で分岐
保存後リフレッシュ	ClearCollect(colTasks, DataSource)

編集グリッドは最初の設計さえ固まれば、後は同じパターンを繰り返すだけです。私も最初に実装したときは ForAll の中での ThisRecord の使い方に戸惑いましたが、一度動くものを作ると次からは迷わなくなります。コレクション操作の基礎についてはコレクション活用入門の記事もあわせて確認してみてください。地道に実装して、使いやすいグリッドUIを完成させましょう。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps 数式エラー解決の全体マップ｜式が赤い・動かないを自力で直す

Sat, 18 Apr 2026 08:45:34 GMT

Power Appsで数式が赤くなったとき、何から手をつければいいか分からなくなることがあります。エラーメッセージを読んでも意味がつかめない、直したつもりなのに別のところが壊れる。そういう経験は市民開発者なら誰でも通る道です。

この記事では、数式エラーが起きたときの診断の順番とよくある原因のパターンを整理します。全体の流れを頭に入れておくと、どんなエラーが出てもあわてずに対処できるようになります。

Power Appsのエラーはなぜ読みにくいのか

Power Appsのエラーメッセージは、初見だと意味がつかみにくいものが多いです。英語で表示されることもありますし、日本語でもこの関数は引数を2つ受け取りますのように、具体的に何が問題なのかすぐには分からない言い方をします。

私が最初にPower Appsを触り始めた頃、数式バーが赤くなるたびに検索エンジンを頼っていました。ところが、検索で出てくる解説は前提知識が必要なものが多く、自分の状況と合致しているかどうかも判断しにくい。結果的に、エラーを直すたびに30分以上かかることもありました。

そこで大切なのは、エラーの種類を素早く見分ける力です。Power Appsで起きるエラーは大きく3つに分類できます。構文エラー・型エラー・実行時エラーです。それぞれ原因が違うので、診断の方向性も変わります。

数式エラーの3分類と見分け方

構文エラー：式の書き方が間違っている

もっとも多いのが構文エラーです。括弧の閉じ忘れ、カンマの位置ミス、全角スペースや全角カンマが混入している、などが典型的な原因です。

構文エラーは数式バーが赤くなる段階、つまりアプリを実行する前の時点で検出されます。エラー表示の下に波線が引かれている箇所が原因です。数式バーのカーソルをそこに合わせると、ツールチップでメッセージが表示されます。

確認ポイントは以下の通りです。

括弧の開き・閉じの数が合っているか（Visual Studioなどのエディタと違い、Power Appsは対応する括弧をハイライトしてくれません）
引数の区切りがセミコロン（;）かカンマ（,）か（地域設定によって変わる）
文字列のダブルクォートが正しく閉じているか
コピペしたコードに全角文字が混じっていないか

特に全角文字の混入は見た目で気づきにくく、私も何度か引っかかりました。コピペで式を作ったときに起きやすいので、手で書き直すと解決することがあります。

型エラー：データの種類が合っていない

型エラーは、関数が期待するデータの種類（型）と、実際に渡している値の型が食い違っているときに起きます。例えば、テキスト型の列に数値を直接渡そうとした場合や、日付型の列に文字列を入れようとした場合です。

よくある組み合わせミスを表にまとめます。

やりがちなミス	原因	対処
数値列に & でテキスト結合しようとした	& 演算子はテキスト型同士が必要	Text() 関数で数値をテキストに変換
日付列に DateValue() を使わずに文字列を入れた	文字列と日付型は別物	DateValue(“2024/01/01”) で変換
Patch で選択肢列に文字列を渡した	選択肢列は {Value:“…”} の形式が必要	{Value: “選択肢名”} に直す
Filter の条件式に論理型でない値を書いた	Filter の条件は true/false でなければならない	= や <> で比較式にする

型変換が必要な場面では、Text()・Value()・DateValue()・DateTimeValue() の4つを覚えておけばほとんど対応できます。

実行時エラー：動かしてみて初めて出るエラー

実行時エラーは、数式バーの段階では問題がないのに、アプリを動かしたときに起きるエラーです。データソースが見つからない、権限がない、レコードが存在しないといった、実際の処理を動かさないと分からない問題が原因です。

実行時エラーが出たときは、アプリ上部にエラーバナーが表示されます。バナーをタップするか、モニター（Monitor）ツールを開くと詳細が確認できます。

実行時エラーの主な原因は3つです。

SharePointリストやDataverseへのアクセス権限がない
Patch関数で存在しない列名を指定している
委任警告のある関数がデータ上限（2000件）を超えた部分で動作している

委任の問題は特に見落としやすいです。委任警告が出ていても動作するので直さなくていいと思いがちですが、データが増えた段階で突然おかしな動きをし始めます。委任の警告と対処法については別記事で詳しく解説しています。

エラーを自力で特定する5ステップ

エラーの種類が分かったら、次は原因を特定します。私が実際に使っている診断の手順を順番に紹介します。

ステップ1：エラーが出ているプロパティを確認する

Power Appsでは、コントロールのプロパティごとに数式を書きます。どのプロパティでエラーが出ているかを最初に特定することが大切です。

ツリービューでコントロールを選択し、プロパティドロップダウンを切り替えながら赤くなっているプロパティを探します。エラーアイコンが付いているプロパティが原因です。

ツリービューで問題のコントロールをクリック
画面上部のプロパティドロップダウンを確認
赤いエラーマークが付いているプロパティを選択
数式バーでエラーの内容を確認

ステップ2：式を最小構成まで削る

エラーが出ている数式が複雑な場合は、式を分解して最小構成に削ることが有効です。

例えばFilter関数にネストした条件が複数ある場合、まず条件を1つだけにして動くか確認します。動くなら条件を1つずつ追加していくことで、どの条件が問題かを切り分けられます。

体感的に、複雑な数式のエラーの7割はこの「削る→確認→追加」のサイクルで特定できます。デバッグの基本は動く状態から育てることです。

ステップ3：作成（Compose相当）でデバッグ変数に値を出す

式の途中の値が何になっているか確認したいときは、ラベルコントロールを使ってデバッグ表示する方法が便利です。

画面上の適当な場所にラベルを追加し、Textプロパティに確認したい式を直接書きます。例えば、変数の値が正しいかどうかを確認するには以下のように書きます。

"変数の値: " & Text(varMyValue)

アプリを実行して、このラベルに表示される値を見ることで、数式の途中の状態を確認できます。確認が終わったらラベルを非表示（Visible: false）にするか削除します。

パフォーマンス改善の記事でも触れましたが、デバッグ用のラベルを大量に残したままにするとアプリが重くなります。確認が済んだらすぐに片付けることをおすすめします。

ステップ4：IfError関数でエラーを可視化する

実行時エラーが出るタイミングと場所をもっと詳しく特定したいときは、IfError関数が役に立ちます。IfError関数は、第1引数の式がエラーになったとき、第2引数の代替値（またはアクション）を返す関数です。

IfError(
    Patch(データソース名, Defaults(データソース名), {列名: 値}),
    Notify("エラーが発生しました: " & FirstError.Message, NotificationType.Error)
)

FirstError.Message はエラーの詳細メッセージを取得できるプロパティです。Notify関数と組み合わせることで、画面上にエラーの内容を表示できます。本番アプリでも活用できるパターンです。

ステップ5：Monitorツールで実行ログを確認する

Power Appsにはモニター（Monitor）という公式のデバッグツールがあります。アプリの実行中にどんなAPIリクエストが発生しているか、どのデータソースにアクセスしているか、エラーが何件出ているかをリアルタイムで確認できます。

Power Apps スタジオの上部メニューから詳細設定→モニターを開く
アプリのモニターをクリックしてモニターを起動
別ウィンドウでアプリが開くので、エラーが起きる操作をする
モニター画面にログが積み上がるので、エラー行（赤くなっている）をクリック
右ペインで詳細を確認する

私はSharePointへのPatch操作が失敗するとき、必ずMonitorを確認します。エラーメッセージに列名が書かれていることが多く、この列の型が合っていないという原因が一発で分かります。

よく出るエラーと解決パターン一覧

エラーの種類とよくある原因・解決策をまとめます。同じパターンを何度も調べることになりがちなので、手元に置いておくと役立ちます。

エラーメッセージ（抜粋）	よくある原因	解決策
Expected {Table}	テーブル型が必要な場所にレコードや値を渡している	データソース名を直接渡す。または Table() 関数でラップする
Invalid argument type	引数の型が期待されるものと違う	型変換関数（Text, Value, DateValue）を使う
The function ‘X’ has some invalid arguments	引数の数か型が違う	公式ドキュメントで引数の仕様を確認する
Delegation warning（委任の警告）	Filter・Search・LookUpが委任非対応の書き方になっている	委任対応の書き方に変更するか、Collectionに取り込んでから処理する
Network error	SharePoint・Dataverseへの接続が切れた、または権限不足	ブラウザをリロードしてみる。権限設定を確認する
Record not found	Patch・Remove・LookUpで対象レコードが見つからない	条件式が正しいか確認。レコードが実際に存在するか確認

エラーを減らすための設計習慣

エラーを直す力と同じくらい大切なのが、エラーを出にくくする設計の習慣です。

変数の型をあらかじめ決める

Power Appsの変数は型宣言がなく、Set関数で代入した値の型になります。途中で別の型の値を代入してしまうと、型エラーが起きます。変数を使い始めるときに、テキストなら空文字列（“”）、数値なら 0、テーブルなら ClearCollect で初期化しておく習慣をつけると型エラーが減ります。

// OnStart や OnVisible で変数を初期化する
Set(varSelectedId, 0);   // 数値型として初期化
Set(varMessage, "");      // テキスト型として初期化
ClearCollect(colItems, []); // テーブル型として初期化

数式を短い単位に分割する

1つのプロパティに複雑な式を詰め込むほど、エラーが出たときの特定が難しくなります。With関数を使って式を分割したり、名前付き計算式（App.Formulas）を使ってアプリ全体で使い回せる形にしたりすることで、デバッグのしやすさが大きく変わります。

コンテナで構造を整理する

画面の構造が複雑になるほど、どのコントロールのどのプロパティにエラーがあるかを追うのが大変になります。コンテナを活用してコントロールの階層を整理することで、ツリービューが見やすくなりエラーの発生場所を素早く特定できるようになります。

まとめ

数式エラーの診断は、構文エラー・型エラー・実行時エラーの3種類に分けて考えると整理しやすくなります。エラーの種類が分かれば、確認すべき場所と使うべき道具も自然と決まります。

最初は一つひとつ調べながらで構いません。同じパターンのエラーを何度か直しているうちに、数式バーが赤くなった瞬間にこれは括弧の問題だなと分かるようになってきます。市民開発のデバッグスキルはそうやって地道に積み上げていくものです。

Power Apps でよく出るエラーメッセージ10選｜英語の意味と直し方チェックリスト

Sat, 18 Apr 2026 08:45:34 GMT

Power Appsのエラーメッセージは英語で出ることが多く、初心者には意味がつかみにくいです。でも、よく出るパターンは決まっています。10種類のエラーを、意味 → 原因 → 直し方の3点セットで整理しました。

この記事はエラー・デバッグクラスターのサテライト記事です。エラーの種類の全体像はPower Apps 数式エラー解決の全体マップで整理していますので、あわせて読んでおくと理解が深まります。

なぜ英語のエラーが出るのか

Power Appsの数式エンジンはMicrosoft製ですが、内部的には英語ベースで動いています。日本語の表示に対応しているものもありますが、数式に関するエラーは英語のまま出ることが多いです。

私が最初に見たエラーは `Expected Text value` というものでした。当時はテキスト値が期待されていますという機械翻訳すら思いつかず、ただ途方に暮れていた記憶があります。今はこういったメッセージを見た瞬間に「あ、型変換が必要だな」と判断できるようになりましたが、それはひたすらエラーを直す経験を積んだからです。

エラーメッセージを読む力は、繰り返しで身につきます。まず代表的な10パターンを頭に入れておきましょう。

エラーメッセージ10選

1. Expected Text value

テキスト型の値を要求しているのに、数値や日付などの別の型が渡されているときに出るエラーです。もっとも多く遭遇するエラーのひとつです。

典型的な発生パターンは、ラベルのTextプロパティに数値を直接置こうとしたときです。

// NG：数値をそのまま渡している
Label1.Text = 100

// OK：Text関数でテキスト型に変換する
Label1.Text = Text(100)

文字列連結（& 演算子）でも同じエラーが出ます。数値・日付をテキストと結合したい場合は、Text()で変換してから結合します。

2. Expected Number value

数値型が必要な場所にテキストが渡されているときに出ます。SharePointのテキスト列に数値を入力しているケースで特によく遭遇します。

// NG：テキスト列の値をそのまま計算に使う
TextInput_Amount.Text * 1.1

// OK：Value関数で数値型に変換する
Value(TextInput_Amount.Text) * 1.1

テキスト入力コントロールの値は常にテキスト型です。これを数値として扱いたい場合は必ずValue()を通してください。

3. Incompatible types for comparison

比較演算子（=, <>, <, >）の左右で型が違うときに出るエラーです。例えばテキスト型の変数と数値を = で比較しようとしたときです。

変数の型は Set 関数で最初に代入した値によって決まります。途中で別の型を代入してしまうとこのエラーが起きます。グローバル変数とコンテキスト変数の使い方の記事でも触れていますが、変数を使い始めるときに型を意識して初期値を設定しておくことが大切です。

// NG：テキスト型に初期化した変数を数値と比較
Set(varCount, "");   // テキスト型として初期化
If(varCount = 0, ...)  // 数値と比較 → エラー

// OK：数値型として初期化する
Set(varCount, 0);    // 数値型として初期化
If(varCount = 0, ...)  // 問題なし

4. The formula contains an error（数式にエラーが含まれています）

構文エラーの総称です。括弧の閉じ忘れ・カンマの位置ミス・スペルミスなど、式の書き方そのものが正しくないときに出ます。

このエラーが出たときにまず確認すべき箇所を順番に挙げます。

括弧の開き ( と閉じ ) の数が合っているか
カンマ（,）またはセミコロン（;）の区切りが正しい場所にあるか（地域設定によって違う）
関数名のスペルが正しいか（大文字・小文字は問わないが、全角文字が混入していないか）
文字列のダブルクォート（“）が正しく閉じているか

コピペで式を貼り付けた際に全角スペースが混入することがあります。見た目では分かりにくいので、エラー箇所のテキストを一度消して手打ちし直すと解決することがあります。

5. This formula has external side effects and cannot be used here

Set・Collect・Patch・Navigate・Notify などの副作用のある関数を、使えないプロパティに書いたときに出ます。

ItemsプロパティやVisibleプロパティ、ラベルのTextプロパティなどは値を返す式しか書けません。こういった場所にSetやCollectを書くとこのエラーになります。

// NG：ラベルのTextプロパティにSet関数を書く
Label1.Text = Set(varName, "テスト")

// OK：Set関数はボタンのOnSelectなどのアクションプロパティに書く
Button1.OnSelect = Set(varName, "テスト")

副作用のある関数はボタンのOnSelect・タイマーのOnTimerEnd・ギャラリーのOnSelectなどユーザー操作やイベントに反応するプロパティに書くのが基本です。

6. Name isn’t valid / is not recognized

コントロール名・列名・変数名のスペルが間違っているか、参照先が存在しないときに出るエラーです。

よくある原因はコントロールをコピーして名前が変わっているケースです。例えば `TextInput1` を参照していたのに、コピー後のコントロール名が `TextInput1_1` になっていてエラーが出る、というパターンです。ツリービューでコントロールの名前を確認してから式を書く習慣をつけると防げます。

7. Circular reference（循環参照）

式の中で自分自身を参照しているときに出るエラーです。例えばLabel1のTextプロパティにLabel1.Textを参照するような式を書いてしまった場合です。

意図せず起きるケースとしては、コレクションの初期化でClearCollectとCollectを混在させてしまい、お互いを参照し合う状態になることがあります。発生したらまず参照のチェーンをさかのぼって、どこで自分自身を参照しているかを探します。

8. Cannot connect to the server / データソースへの接続エラー

SharePointリストやDataverseなどのデータソースへの接続が失敗したときに出ます。数式の問題ではなく、ネットワークや権限の問題であることが多いです。

確認すべきポイントは3つです。

ブラウザをリロードして再接続を試みる
そのSharePointサイトやDataverse環境にアクセス権限があるかを確認する
Monitorツールを起動してHTTPステータスコードを確認する（403は権限不足、404は場所が違う）

同僚のアカウントでは動くのに自分のアカウントだと接続エラーになる場合は、権限設定の問題です。SharePoint管理者に確認してください。

9. Delegation warning（委任の警告）

これはエラーではありません。黄色い波線で表示される警告です。Filterなどの関数がデータソース側で処理できず、アプリ側で処理する形になっているときに出ます。

この警告が出ていても動作はします。ただし、データが500件（デフォルト）または2000件（設定変更後の上限）を超えていると、それ以降のデータが無視されます。データが増えてきた段階で突然動作がおかしくなる原因になります。

委任の仕組みと対処法については委任の警告と対処法の記事で詳しく解説しています。件数が少ないうちに対処しておくことをおすすめします。

10. ラベルに [object Object] または [Table] が表示される

これはエラーメッセージではなく、表示の問題です。ラベルのTextプロパティにテーブル型またはレコード型の値をそのまま渡しているときに起きます。

// NG：テーブル型をそのまま表示しようとしている
Label1.Text = Filter(リスト名, 条件)

// OK：件数を表示するならCountRows
Label1.Text = Text(CountRows(Filter(リスト名, 条件)))

// OK：最初の1件の列を表示するならFirst
Label1.Text = First(Filter(リスト名, 条件)).タイトル列

ギャラリーのSelectedプロパティもレコード型を返します。`Gallery1.Selected` をそのままラベルに渡すと同じ現象が起きるので、`.列名` で特定の列を指定してください。

エラーを素早く特定するための3つの習慣

エラーに慣れてきたら、診断の速度を上げるための習慣を身につけていきましょう。

まず型を疑う

私の経験では、Power Appsで出るエラーの半分以上は型に関するものです。Expected Text・Expected Number・Incompatible types のどれかに当てはまります。エラーが出たら最初に型が合っているかを確認する癖をつけると診断が早くなります。

式を短く削ってから確認する

複雑な式でエラーが出たときは、式を最小構成まで削って動かしてみます。動くなら削った部分を少しずつ戻しながら、どこでエラーが起きるかを二分探索する要領で特定します。体感的に、この削る → 確認 → 追加のサイクルが一番確実です。

エラーメッセージをそのまま検索する

`Expected Text value Power Apps` のように、英語のエラーメッセージをそのまま検索エンジンに入れると解決策が見つかりやすいです。日本語に訳してから検索するより、英語のまま検索するほうが情報が多く出てきます。MicrosoftのLearnサイトやコミュニティフォーラムも活用してください。

まとめ

よく出るエラーパターンを覚えておくだけで、エラーを見たときの焦りが大きく減ります。最初は一覧を手元に置いておいて、出るたびに照合してみてください。3ヶ月もすれば見た瞬間に原因が浮かぶようになります。

デバッグのスキルはアプリ開発の土台です。エラーを直す経験の積み重ねが、読める式の幅を広げていきます。トライしてみましょう。

Power Apps でギャラリーの選択データをCSVに出力してメール送信する｜多選択・JSON変換・フロー実装の全手順

Sun, 05 Apr 2026 10:18:36 GMT

Power Apps でギャラリーに並んだデータを選択してCSVに出力するには、Power Apps側とPower Automate側の役割を分けて考えることが出発点です。この分担を理解しているかどうかで、実装のスムーズさが大きく変わります。

2ステージ構成で全体を把握する

この実装は2つのステージに分かれます。Power Apps側がデータを選択・整形してフローを呼び出す段階と、Power Automate側がCSVファイルを生成して出力する段階です。アプリがデータを整形し、フローがファイルを作る。この切り分けが全体設計の核心です。

Power Apps側の処理の流れはこうなります。ギャラリーのチェックボックスで複数レコードを選択し、選択済みレコードをFilter関数で取り出し、JSON関数でJSON文字列に変換してフローに渡します。Power Automate側では、受け取ったJSON文字列をParse JSON（JSONの解析）アクションで解析し、Create CSV table（CSVテーブルの作成）アクションでCSVを生成し、メール添付やSharePoint保存など任意の出力先に渡します。

この記事ではPower Automateのアクション名を日本語と英語の両方で記載します。画面上の表示名で迷ったときの参照にしてください。

ギャラリーにチェックボックスを追加する

ギャラリーに多選択UIを実装するには、テンプレートエリアにチェックボックスを追加するところから始めます。ギャラリー自体の基本操作はギャラリーコントロールの基礎記事を先に確認しておくとスムーズです。

ギャラリーのテンプレートエリアを選択した状態でInsertメニューからCheckboxを追加します。チェックボックスのDefaultプロパティにはvarSelectAllという変数名を設定します。このvarSelectAllは後述する全選択・全解除のトグルと連動するために使います。現時点ではOnStartなどで初期値をfalseに設定しておけば問題ありません。

選択済みレコードを取り出すには、ギャラリーのAllItemsプロパティをFilterで絞り込みます。

// 選択済みレコードを取り出す
Filter(Gallery1.AllItems, Checkbox1.Value)

このFilterの結果が後続のすべての処理の起点になります。この1行で選択されているレコードだけを集めたテーブルが得られるので、合計計算・JSON変換・フロー呼び出しはすべてここから始まります。コレクション操作との組み合わせについてはコレクション操作の基礎記事もあわせて読むと理解が深まります。

全選択・全解除トグルを実装する

全選択ボタンを作るとき、varSelectAllをtrueにセットするだけでは連続して押したときに効かなくなります。一度trueにした後に再び同じボタンを押しても変数の値が変わらないため、コントロールが再レンダリングされないからです。

解決策は、falseとtrueを連続してセットすることです。UpdateContext({varSelectAll: false})を先に実行してからUpdateContext({varSelectAll: true})を実行すると、一瞬falseを経由することでコントロールの再描画が起きて全チェックがかかります。ボタンのTextプロパティにIfを使って現在の選択状態に応じてラベルを切り替えると、ユーザーへの案内としてもわかりやすくなります。

// 全選択ボタンのOnSelectプロパティ
UpdateContext({varSelectAll: false});
UpdateContext({varSelectAll: true})

// ボタンのTextプロパティ
If(IsEmpty(Filter(Gallery1.AllItems, Checkbox1.Value)), "Select All", "Deselect All")

選択数・合計を動的に表示する

選択したレコードの件数や数値列の合計をリアルタイムで表示すると、ユーザーが選択状態を確認しながら操作できます。請求明細や在庫リストなど数値を扱う業務では、出力前に合計金額を確認できる設計が現場から喜ばれます。私が社内で作った棚卸しアプリでも、この表示を入れてから「選んだ数がすぐわかる」という声をもらいました。こういう小さな配慮がUXを変えます。

// 選択件数
CountRows(Filter(Gallery1.AllItems, Checkbox1.Value))

// 選択行の合計（金額列の例）
Sum(Filter(Gallery1.AllItems, Checkbox1.Value), 金額)

ツールバーコンテナやラベルのVisibleプロパティにNot(IsEmpty(Filter(…)))を設定すると、何も選んでいないときはこれらの表示が消えます。選択がない状態では不要な情報を出さない。その配慮が使いやすいアプリと使いにくいアプリの差になります。

JSON関数で選択データを文字列に変換する

基本的な使い方

Power AppsからPower Automateにデータを渡すには、テーブル型のデータをJSON文字列に変換する必要があります。JSON関数とShowColumns関数を組み合わせて、必要な列だけを取り出したJSON配列を生成します。

// 選択データをJSON文字列に変換する
JSON(
    ShowColumns(
        Filter(Gallery1.AllItems, Checkbox1.Value),
        "商品名",
        "数量",
        "金額"
    ),
    JSONFormat.IndentFour
)

JSONFormat.IndentFourは整形出力のオプションです。改行・インデントが入って人が読みやすい形式になります。開発中はこの設定のままにしておくといいです。本番運用に移行するときにJSONFormat.Compressに変えると通信量が減ります。

シリアライズできない列のエラーに注意する

ShowColumnsに指定できる列には制限があります。Checkboxコントロール・Choice列（選択肢列）・ルックアップ列はそのままShowColumnsに入れるとエラーになります。Power Appsが内部的にレコードとして持っているデータをJSON文字列にシリアライズできないためです。

Choice列は表示値をText()で取り出してAddColumnsで新しい列として追加してから、ShowColumnsでその列名を指定します。

// Choice列をText()で取り出してからShowColumnsに渡す
JSON(
    ShowColumns(
        AddColumns(
            Filter(Gallery1.AllItems, Checkbox1.Value),
            "カテゴリ名", Text(カテゴリ.Value)
        ),
        "商品名",
        "カテゴリ名",
        "金額"
    ),
    JSONFormat.IndentFour
)

ルックアップ列（例：Supplier.SupplierName）も同様です。AddColumnsで仕入先名、Supplier.SupplierNameのように取り出してからShowColumnsに渡します。ShowColumns内でネストプロパティを直接参照しようとするとエラーになるので、必ずAddColumnsを経由する手順を守ってください。

Power Automate側の実装

Parse JSONでスキーマを自動生成する

Power Apps側から受け取ったJSON文字列をParse JSON（JSONの解析）アクションに渡します。スキーマを手動で書く必要はありません。Power Appsから実際に出力されたサンプルのJSON文字列をコピーして、Parse JSONのサンプルから生成機能に貼り付けるだけで自動生成されます。

スキーマが正しく生成されると、後続のCreate CSV table（CSVテーブルの作成）やCreate HTML table（HTMLテーブルの作成）で各列のデータ型が正しく認識されます。スキーマなしでJSONを扱おうとすると動的コンテンツの列名が表示されないため、必ずParse JSONを先に入れてください。

Create CSV tableで列名と書式を整える

Create CSV table（CSVテーブルの作成）アクションのColumnsをCustom設定にすると、列名を日本語に変更したり、日付や数値のフォーマットを指定できます。自動設定のままでは列名がシステム名そのままで出力されることが多く、受け取った人が内容を把握しにくいCSVになります。渡す相手が使いやすい形に整えるひと手間が、ツールの完成度を大きく上げます。

// 日付列のフォーマット変換（Create CSV table内のValue設定）
formatDateTime(item()?['申請日'], 'yyyy/MM/dd')

// 数値列の通貨フォーマット
formatNumber(item()?['金額'], 'C', 'ja-JP')

HTMLテーブルをメール本文に埋め込む

Create HTML table（HTMLテーブルの作成）アクションを使うと、同じデータをHTML形式のテーブルとして生成できます。このOutputをSend an email（V2）（メールの送信（V2））のBodyに差し込むだけで、メール本文にデータが表形式で表示されます。CSVファイルを添付しつつメール本文にもプレビューを表示する構成が実用的です。受信者がCSVを開かなくても概要を確認できる設計は、特に承認フローや報告業務で喜ばれます。

出力先は用途に合わせて選ぶ

CSVファイルが生成できたら、出力先は用途に応じて選択できます。メール添付はすぐに担当者に送れて手軽ですが、SharePoint保存にすると他のフローや外部システムからもファイルにアクセスできるようになります。OneDriveに保存して共有リンクをメールで送るパターンも、添付制限に引っかかるような大容量ファイルで有効です。ファイルさえ生成してしまえば、後は配置先を変えるだけでさまざまな用途に転用できます。

SolutionにまとめてチームにExportする

アプリとフローが完成したら、Solutionとしてパッケージしてチームに展開できます。Power Appsの画面でSolutionsを開き、Add existing → App または Cloud flowでアプリ・フローを追加します。Advanced → Add required objectsを選ぶと、参照しているDataverseテーブルや接続情報など依存するコンポーネントも一緒にパッケージされます。このSolutionを他のメンバーの環境にImportすることで、アプリとフローをセットで配布できます。社内でツールを横展開するときや本番環境への移行時に使える実務的なテクニックです。

Patchを使ったデータ保存の設計についてはPatch関数で新規レコードを保存する方法の記事もあわせて読むと、データ操作全体の理解が深まります。生成したCSVをさらにExcelに変換してSharePointリストに取り込む応用的な使い方は、Power Automate × Excel ScriptsでCSVをXLSXに変換する記事で詳しく扱っています。

まとめ

Power Appsでのデータ選択からCSV出力までは、アプリ側の整形とフロー側のファイル生成という2ステージの組み合わせで成り立っています。構造が見えてしまえば、実装は一つひとつの手順の積み重ねです。特にJSON関数のエラーは初見で戸惑いますが、Choice列とルックアップ列の処理パターンを一度理解すれば以降は同じ手順を適用するだけです。私もはじめてこれを組んだときにシリアライズエラーで詰まりましたが、AddColumnsで取り出してからShowColumnsに渡すという手順を身につけてからは、同じ問題で止まることがなくなりました。

市民開発とはこういう地道な積み重ねです。一度動くものを作ってしまえば、それが次の応用の土台になります。楽しみながら進めていきましょう。

Power Apps でユーザーフィルターを実装する｜SharePoint・Dataverse 別全パターン解説

Thu, 02 Apr 2026 16:50:25 GMT

Power Appsのビジネスアプリでは、ほぼ必ずユーザーフィルターが必要になります。自分の申請だけ表示したい、自分宛の承認依頼だけ出したい。こうした要件を実現するための実装パターンを、SharePointとDataverseそれぞれで整理します。

ユーザーフィルターが必要な場面

申請管理アプリを作るとき、一覧画面には全員分のデータが表示されます。ところが実際の運用では、自分が出した申請だけを見たい、自分が承認者になっている案件だけを確認したい、という要件がほぼ必ず出てきます。ロールに応じた表示の切り替えは、ビジネスアプリの基本中の基本です。

実装自体はシンプルです。ただし、データソースによって使えるプロパティが違うため、同じ感覚で書くと動かないことがあります。まずSharePoint、次にDataverseの順で順番に整理します。

フィルター式を書く前に列の型を目で確認する

フィルター式を組み立てるときに最初にやるべきことがあります。左辺、つまりデータがどういう型で保存されているかを先に目で確認することです。これをやらずに式を書き始めると、型のミスマッチで動かないまま時間を使うことになります。

確認手順はシンプルです。ギャラリーのItemsに対象のデータソースをそのまま設定して実行し、ラベルコントロールのTextプロパティに ThisItem.‘Created By’ を入れます。すると画面上に値が表示されます。さらに .Email まで掘ると、メールアドレスの文字列が出てきます。これで左辺がどんな値を持っているかが目視できます。ギャラリーの基本操作が初めての方はそちらを先に確認しておくとスムーズです。

SharePointのユーザーフィルター

Created By のプロパティはどれを使うか

SharePointの Created By 列は、展開するといくつかのプロパティを持っています。Email、Claims、DisplayName、Department などです。どれを使えばいいか悩むところですが、結論から言うとEmailの一択です。

Claimsはi:0#.f|membership|user@domain.comのような形式で値が入っています。組織の設定によって形式が変わることがあり、式の中で扱うのに向いていません。DisplayNameは表示名なので、同姓同名がいる組織では正しくフィルターできません。結果として、SharePointでユーザーフィルターを組むときはEmailに絞って考えるのが現実的です。SharePointのCRUD操作の基礎と合わせて読むと、列の扱いについての理解が深まります。

Filter式の完成形

User()関数は現在ログインしているユーザーの情報を返す関数です。持っているプロパティはEmail、FullName、EntraObjectId、Imageの4つです。SharePointのCreated ByにはEntraObjectIdが存在しないため、EmailとEmailで合わせることになります。

// SharePointのユーザーフィルター
Filter(Employees, 'Created By'.Email = User().Email)

左辺の ‘Created By’.Email が SharePoint 側のメールアドレス、右辺の User().Email がログインユーザーのメールアドレスです。同じ型・同じ形式で比較しているので委任も問題ありません。Filter関数はSharePointに委任できるので、件数が多くても全件から正しく絞り込めます。委任の仕組みについては委任とデータの欠落について解説した記事を参照してください。

Emailを使う場合の弱点

Emailを識別子として使う場合、一点だけ覚えておく必要があります。メールアドレスは変わることがあるということです。結婚による改姓、社名変更、M&Aによるドメイン移行など、組織の都合でアドレスが変わるケースは珍しくありません。

アドレスが変わると、変更前に登録されたレコードの Created By.Email と、変更後のUser().Email が一致しなくなります。過去の申請が一覧から消える、という状況が起きます。利用者が少なく、組織変更もほとんどないチームのアプリなら許容範囲です。ただし長期運用を前提にした重要業務のアプリなら、後述するObject IDを使う設計を最初から採用した方がいいです。

DataverseのユーザーフィルターはObject IDを使う

Created ByはUsersテーブルへのルックアップ

DataverseをデータソースにしたときのCreated Byは、SharePointとは構造が違います。DataverseのCreated Byは、Usersテーブルへのルックアップ列です。アプリにDataverseのテーブルを追加すると、Usersテーブルも自動的に追加されます。初めて見ると驚きますが、正常な動作です。Dataverseがリレーションを自動で解決している結果です。

Azure AD Object IDで合わせる

Created Byを展開すると、Azure AD Object IDというフィールドが出てきます。これはEntra Object IDと同一の値です。Azure Active DirectoryがMicrosoft Entraに名称変更された関係で、古い名称が残っています。右辺にはUser().EntraObjectIdを使います。

// DataverseのユーザーフィルターはObject IDで合わせる
Filter(ChewyDoggyData, 'Created By'.'Azure AD Object ID' = User().EntraObjectId)

GUIDと呼ばれる識別子の形式で値が入っています。GUIDについての詳細はDataverseのGUIDとIDの違いを解説した記事にまとめています。

Object IDが最強な理由

Object IDはメールアドレスとは違い、改名しても、ドメインが変わっても、絶対に変わりません。Microsoft Entraが発行する一意のIDであり、ユーザーが組織に存在し続ける限り固定です。SharePointでEmailを使う場合と比べて、データの一貫性が段違いに高くなります。

個人的にも、Dataverseを使う案件では必ずObject IDでフィルターを組むようにしています。Emailで組んで後から直す手間を考えれば、最初から設計を正しくしておく方が圧倒的に楽です。

自前の列に承認者・担当者を保存するときもObject IDで

Created Byではなく、自前で作った列に担当者や承認者を保存するケースもよくあります。このとき、メールアドレスで保存している設計をよく見かけます。上で説明した通り、メールアドレスは変わる可能性があります。最初からEntra Object IDで保存しておくことをすすめます。

フォーム送信時やPatch実行時に、User().EntraObjectIdを一緒に保存しておく実装です。保存の書き方についてはPatch関数で新規レコードを保存する方法を参考にしてください。

// 申請フォーム送信時にObject IDも一緒に保存する例
Patch(
    申請テーブル,
    Defaults(申請テーブル),
    {
        Title: TextInput_title.Text,
        申請者ID: User().EntraObjectId,
        申請者名: User().FullName
    }
)

こうしておけば、後からフィルターするときに Filter(申請テーブル, 申請者ID = User().EntraObjectId) で正確に絞り込めます。アドレス変更の影響を受けない設計が最初から完成します。

パターンの考え方まとめ

ユーザーフィルターを実装するときは、次の手順で考えると迷いません。まずギャラリーで列の値を目視確認して左辺を確定します。次に User() のどのプロパティと型が合うかを確認して右辺を決めます。あとはFilterで等号でつなぐだけです。

データソース	左辺	右辺	注意点
SharePoint	‘Created By’.Email	User().Email	アドレス変更リスクあり
Dataverse	‘Created By’.‘Azure AD Object ID’	User().EntraObjectId	変更に強く長期運用向き
自前列（任意）	保存した列名	User().EntraObjectId	保存時からObject IDで設計する

ハードコード（特定のメールアドレスを直接式に書く）は絶対に避けましょう。ユーザーが変わるたびにアプリを修正することになります。User()関数を使うことで、誰がログインしても正しく動くアプリになります。

まとめ

SharePointならEmail、DataverseならObject ID、自前列でもObject IDが基本です。データソースによって使えるプロパティが違うので、最初に左辺の型を目視確認する習慣をつけておくことが大切です。

ユーザーフィルターは地味ですが、使い勝手に直結する重要な実装です。設計段階から正しい方法で組んでおくと、後から修正する手間が省けます。楽しみながら、丁寧に作っていきましょう。

Power AppsのFilter・Search・LookUp関数。3つの違いと使い分けガイド

Sat, 14 Mar 2026 11:30:00 GMT

Power AppsのFilter・Search・LookUpは、どれもデータを絞り込む関数です。ただし返り値の型と得意な使い方が違うため、場面によって使い分ける必要があります。

3つの関数の根本的な違い

返り値の型がそれぞれ違う

最も重要な違いは、何を返すかです。Filter と Search はどちらも条件に合う複数のレコードをテーブル（表）として返します。LookUp は条件に一致した最初の1件だけをレコードとして返します。

この差が使い分けの基本になります。ギャラリーの Items に設定するなど複数件を一覧表示したい場合は Filter か Search を使います。1件の特定レコードの特定列の値を取り出したい場合は LookUp を使います。

関数	返り値	件数	主な使い道
Filter	テーブル（Table）	0件以上	ギャラリーの一覧表示・絞り込み
Search	テーブル（Table）	0件以上	テキスト検索ボックスとの連携
LookUp	レコード（Record）	最大1件	特定レコードの値を取得・Patchの対象指定

LookUp の返り値はテーブルではなくレコードなので、LookUp の結果をギャラリーの Items に設定しようとするとエラーになります。これは初心者がよくはまるポイントです。

委任（delegation）の対応状況も違う

データが大量にある場合に気にしなければならない委任の可否も、3つの関数で異なります。委任の詳細は委任の警告についての記事で解説していますが、簡単にいえば委任できないとデータが500件（最大2000件）しか取得できなくなります。

関数・条件	SharePoint	Dataverse
Filter（=、<、>、StartsWith）	委任可能	委任可能
Filter（in、Mid、Left）	委任不可	一部可能
Search	委任不可	委任可能
LookUp（=、<、>）	委任可能	委任可能

SharePointリストを使っているなら、Search は委任できないと覚えておくと安全です。件数が多くなる可能性があるデータソースで Search を使うと、500件以降のデータが検索に引っかからなくなります。

Filter関数の使い方

基本の書き方

Filter はデータソースと条件式を渡すだけです。

// ステータスが「申請中」のレコードだけを返す
Filter(申請リスト, ステータス = "申請中")

// 自分が申請したレコードだけを返す
Filter(申請リスト, 申請者 = User().DisplayName)

// 複数条件（AND）
Filter(申請リスト, ステータス = "申請中" && 申請者 = User().DisplayName)

&&（アンパサンド2つ）で AND 条件、||（パイプ2つ）で OR 条件を書けます。SharePointリストで等号や比較演算子を使う場合は委任が成立するので、データ件数を気にせず使えます。

テキスト入力と組み合わせた絞り込み

ギャラリーに絞り込み検索を実装する場合、Filter と StartsWith の組み合わせが定番です。

// タイトルの前方一致で絞り込む（SharePointで委任可能）
Filter(申請リスト, StartsWith(タイトル, 検索テキスト.Text))

テキスト入力が空のときは全件表示したい場合は、条件を追加します。

Filter(
    申請リスト,
    IsBlank(検索テキスト.Text) || StartsWith(タイトル, 検索テキスト.Text)
)

テキスト入力欄が空のとき（IsBlank）は全件表示し、値が入っているときは前方一致で絞り込むという書き方です。このパターンは実務で非常によく使います。

Search関数の使い方

複数列をまとめて検索できる

Search が Filter と異なる点は、複数の列をまとめてあいまい検索できることです。タイトルと担当者名のどちらに検索ワードが含まれていても一発で拾いたい、という場合に便利です。

// タイトルと担当者名の両方から部分一致で検索
Search(申請リスト, 検索テキスト.Text, "タイトル", "担当者名")

列名を文字列（ダブルクォーテーション）で渡すのが Filter との大きな違いです。複数列を指定するときはカンマで並べます。

SharePointでSearchを使うときの注意

繰り返しになりますが、SharePointリストに対してSearchを使うと委任の警告が出て、500件しかデータを取得できません。データ件数が少ないアプリや、コレクションに取り込んだデータに対してSearchを使うのであれば問題ありません。SharePointリスト直接に対して Search を使う場合は、件数の上限を意識した設計にしましょう。

個人的には、SharePointリストを使うときは原則 Filter + StartsWith で代替できないか先に検討します。部分一致の検索どうしても必要な場合は、OnVisible で ClearCollect してコレクションに落としてから Search するという回避策を使っています。

LookUp関数の使い方

1件のレコードまたは列の値を取得する

LookUp は条件に合う最初の1件を返します。テーブルではなくレコードを返すため、特定の列の値を直接取り出すことができます。

// IDが一致するレコードの「担当者名」列を取得
LookUp(申請リスト, ID = 選択ID, 担当者名)

// 3番目の引数で取り出す列を指定できる
LookUp(マスタリスト, 部署コード = ドロップダウン1.Selected.Value, 部署名)

3番目の引数で「どの列を返すか」を指定できます。省略するとレコード全体を返しますが、値だけが欲しいときは列名を指定したほうがシンプルです。

Patchと組み合わせた更新処理

LookUp の大事な使い道がもう1つあります。Patch 関数で更新対象のレコードを特定するときに使います。

// ギャラリー外から特定レコードを更新する
Patch(
    申請リスト,
    LookUp(申請リスト, ID = gv_SelectedID),
    {ステータス: "承認済み"}
)

グローバル変数 gv_SelectedID に保存している ID と一致するレコードを LookUp で見つけ、そのレコードを Patch で更新するパターンです。Patch関数の使い方と組み合わせると、ギャラリーから選択したレコードを別の画面で編集・更新するという設計が実現できます。

条件に一致するレコードがない場合

LookUp は一致するレコードが存在しない場合、Blank（空値）を返します。その後の処理で LookUp の結果を使うときは、IsBlank で存在チェックを入れるほうが安全です。

If(
    IsBlank(LookUp(申請リスト, ID = gv_SelectedID)),
    Notify("対象のレコードが見つかりませんでした", NotificationType.Warning),
    // 更新処理を実行
    Patch(申請リスト, LookUp(申請リスト, ID = gv_SelectedID), {ステータス: "承認済み"})
)

少し冗長に見えますが、現場アプリでは複数人が同時に操作する可能性があります。誰かが削除した後に別の人が承認ボタンを押すといった事態も起こりえるので、このチェックは入れておいて損はありません。

3つの関数を使い分ける判断フロー

まとめとして、どの関数を選ぶかの判断基準を整理します。

複数件を一覧表示したい → Filter または Search
1件のレコードまたは特定列の値を取得したい → LookUp
条件が等号・比較・StartsWith で済む → Filter（SharePointでも委任可能）
複数列をまとめてあいまい検索したい → Search（ただしSharePointでは件数に注意）
Patchで更新対象を指定したい → LookUp

どれが正解というより、状況によって組み合わせて使うものです。ギャラリーの Items に Filter をかけて表示しつつ、承認ボタンでは LookUp + Patch で更新する、というパターンが実務では一番多いと思います。

まとめ

Filter・Search・LookUp の最大の違いは、返り値がテーブルかレコードかです。複数件の表示には Filter か Search、1件の取得や Patch の対象指定には LookUp。これを基本に使い分けましょう。

SharePointリストを使うなら委任の問題も頭に入れておく必要があります。Search は件数が多いデータソースには向かないので、Filter + StartsWith で代替できないか先に考えるクセをつけるといいです。3つの関数が使いこなせると、Power Appsでのデータ操作がぐっと楽になります。

Power Apps フレキシブル高さギャラリー入門｜行ごとに高さが変わるAutoHeightの仕組み

Sun, 29 Mar 2026 19:06:14 GMT

Power Apps の通常ギャラリーは行の高さが固定ですが、フレキシブル高さギャラリーを使えば内容に応じて各行の高さが自動で変わります。長いテキストが途中で切れてしまう問題をそのまま解決してくれる、地味ながら実用性の高い機能です。

フレキシブル高さギャラリーとは

通常のギャラリーコントロールは、TemplateSize プロパティで全行の高さを一律に固定します。内容が短い行も長い行も、表示領域は同じです。これは一覧表示には都合がいいですが、自由なテキスト（メモ・コメント・説明文など）を表示すると文字が途中で切れてしまいます。

フレキシブル高さギャラリーは行ごとに高さが変わります。テキストが短ければ行は小さく、長ければ行は大きくなります。ニュースフィードやSNSのタイムラインのような、内容量がばらばらなリストに向いています。

ギャラリーの種類	行の高さ	向いている用途
通常ギャラリー（Vertical）	固定	一覧・マスター画面・シンプルなリスト
フレキシブル高さ	内容に応じて自動変化	コメント一覧・ニュースフィード・説明文あり

追加方法

挿入メニューからギャラリーを選ぶとき、通常の Vertical Gallery ではなく Flexible Height を選びます。

Power Apps Studio の画面で Insert をクリックする
Gallery → Flexible Height を選択する
画面に追加されたギャラリーの Items にデータソースを設定する

追加直後は News feed レイアウトが適用されます。このレイアウトにはタイトル・本文・日時などを組み合わせたテンプレートが最初から用意されていて、フレキシブルギャラリーの動きを確認しやすいです。最初は News feed から始めて、不要なコントロールを削除しながら自分のレイアウトに近づけていくのが個人的なやり方です。

AutoHeight プロパティをオンにする

フレキシブルギャラリー内でテキストを折り返して表示させるには、ラベルコントロールの AutoHeight プロパティを On にします。

ギャラリーテンプレート内のラベルを選択する
プロパティ一覧から AutoHeight を探して On に切り替える
あるいは数式バーで AutoHeight プロパティに true を入力する

AutoHeight を On にすると、ラベルに表示するテキストの長さに応じて、ラベルの高さが自動的に広がります。テキストが1行に収まる場合は1行分の高さ、3行必要な場合は3行分の高さになります。

TemplateSize は自動計算される

通常のギャラリーでは TemplateSize に数値を直接入力して行の高さを固定します。フレキシブルギャラリーでは TemplateSize は自動で計算されるため、手動で設定する必要がありません。

ここが最初に戸惑うポイントです。TemplateSize を変更しようとしても数式バーがグレーになっており、入力できません。これは仕様であり、バグではありません。テンプレート内のコントロールの高さの合計を Power Apps が自動計算して TemplateSize に反映する仕組みです。

ですので、フレキシブルギャラリーで行の高さを調整したいときは、TemplateSize を変えようとするのではなく、テンプレート内の各コントロールの高さや余白を調整します。コントロールの Height が増えれば行の高さも増え、減らせば縮みます。

使う際の注意点

フレキシブルギャラリーは便利ですが、いくつか割り切りが必要な点があります。

スクロールのパフォーマンス

通常ギャラリーはスクロールが非常にスムーズです。一方、フレキシブルギャラリーは行ごとに高さを計算するため、データが多いと（体感では 50件超あたりから）スクロールが少しカクつくことがあります。委任で大量データを扱う場合は注意が必要です。委任の考え方については委任の警告と対処法の記事で詳しく解説しています。

行の高さの最小値

テンプレート内のコントロールをすべて削除すると、行の高さが極端に小さくなります。最低限のパディングを持つコンテナや余白ラベルを残しておくと、行間が詰まりすぎるのを防げます。

テンプレートのデザイン調整は手間がかかる

通常ギャラリーと違い、行の高さが動的に変わる分、デザインの見通しが立てにくいです。特に長文と短文が混在するデータで見た目を整えるには、少し試行錯誤が必要です。そういうものだと割り切ってしまうと気が楽になります。

まとめ

フレキシブル高さギャラリーは、内容量がばらばらなテキストデータを表示するときにとても重宝します。AutoHeight を On にしてテンプレート内のラベルを伸縮させる、TemplateSize は自動計算に任せる、この2点を押さえれば基本的な使い方はマスターできます。

フレキシブルギャラリーを発展させると、行ごとに展開・折りたたみができるアコーディオンUIも作れます。その実装パターンについてはギャラリーで展開・折りたたみを実装する記事で解説しています。まずは表示を動かしてみて、感触をつかんでみてください。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーで展開・折りたたみを実装する｜ボタン・ネストギャラリー・コレクションの3パターン

Sun, 29 Mar 2026 19:06:14 GMT

ギャラリーの各行をクリックすると詳細が展開され、もう一度クリックすると折りたたまれるUI、いわゆるアコーディオンを Power Apps で実装する方法は3パターンあります。それぞれの仕組みと使い分けを解説します。

この記事はフレキシブル高さギャラリーの基礎知識を前提にしています。AutoHeight の仕組みや Flexible Height の追加方法が気になる方は、フレキシブル高さギャラリー入門の記事を先に読んでおくとスムーズです。

なぜギャラリー内で変数が使えないのか

ギャラリーで展開・折りたたみを実装しようとすると、最初にぶつかる壁があります。ギャラリーの各行は同じテンプレートを使い回しているため、行固有の状態を変数で持てないという制約です。

たとえば UpdateContext({varExpand: true}) を行ごとに持ちたくても、コンテキスト変数は画面単位の変数なのですべての行に影響します。1行目を展開しようとすると全行が展開されてしまうのです。グローバル変数も同じ理由で行ごとの状態管理には使えません。変数の種類と使い分けについてはグローバル変数とコンテキスト変数の違いの記事でまとめています。

この制約を回避する方法が3つあります。順番に見ていきましょう。

パターン①：HTMLテキストコントロールで折りたたみを表現する

最もシンプルなパターンは、HTMLテキストコントロールと AutoHeight を組み合わせて、クリックで展開・折りたたみを切り替えるものです。ただし行ごとの変数は使えないため、この方法では1行だけ展開してあとは閉じるというトグル管理はできません。

代わりに Toggle コントロールを使います。Toggle の Value は行ごとに独立した状態を持てます（内部的に行のテンプレートとして扱われるため）。ただしこれは Power Apps の仕様上の動きであり、必ずしも全バージョンで安定して動くとは限らない点は割り切りが必要です。

// 詳細エリアの Visible プロパティ
Toggle1.Value

テンプレート内に Toggle を置き、詳細テキストを表示するラベルやコンテナの Visible を Toggle1.Value にします。Toggle がオンになった行だけ詳細エリアが表示され、フレキシブルギャラリーによって行の高さが自動で広がります。

パターン②：ネストギャラリーの高さを動的に計算する

詳細エリアに別のテーブルデータ（たとえばタスクに紐づくコメント一覧）を表示したい場合、ネストギャラリーを使います。

ネストギャラリーは親ギャラリーのテンプレート内に子ギャラリーを配置する構成です。子ギャラリーの高さを行数に応じて動的に計算することで、展開・折りたたみを実現します。

// 子ギャラリーの Height プロパティ
CountRows(GalleryComments.AllItems) * GalleryComments.TemplateHeight

CountRows(GalleryComments.AllItems) は子ギャラリーに表示されているレコード数を返します。TemplateHeight は子ギャラリー1行分の高さです。この積が子ギャラリー全体の高さになります。

折りたたみは子ギャラリーの Visible を Toggle1.Value でオン・オフするだけです。Visible が false のとき親ギャラリーのテンプレートは折りたたまれ、true のとき子ギャラリーの高さ分だけ行が展開されます。

パターン③：コレクションに ShowDetails 列を持たせる

最も柔軟で安定したパターンは、コレクションに ShowDetails（boolean型）列を追加して、Patch で行ごとに切り替える方法です。変数ではなくコレクション自体に状態を持たせることで、行ごとの独立した展開・折りたたみが実現できます。

コレクションの準備

データを読み込む際に ShowDetails 列を追加します。

ClearCollect(colTasks,
  AddColumns(Tasks, "ShowDetails", false)
)

AddColumns 関数でデータソースのテーブルに ShowDetails 列を追加しながらコレクションに格納します。初期値はすべて false（折りたたみ状態）です。

展開・折りたたみの切り替え

ギャラリーの各行にある展開ボタンの OnSelect で、該当行の ShowDetails だけを反転させます。

Patch(colTasks, ThisItem, {ShowDetails: !ThisItem.ShowDetails})

!ThisItem.ShowDetails は現在の値の反転です。true なら false に、false なら true にします。Patch でコレクションのその行だけを更新するため、他の行の ShowDetails には一切影響しません。これが変数との決定的な違いです。

詳細エリアの Visible は ThisItem.ShowDetails にするだけです。

Expand All・Collapse All の実装

全件展開・全件折りたたみのボタンも簡単に作れます。UpdateIf でコレクション全行の ShowDetails を一括更新します。

// 全件展開ボタン
UpdateIf(colTasks, true, {ShowDetails: true})

// 全件折りたたみボタン
UpdateIf(colTasks, true, {ShowDetails: false})

UpdateIf の第2引数に true を渡すことですべての行が条件に一致するため、全件更新になります。コレクション操作なのでデータソースへの書き込みはなく、画面のローカル状態だけが変わります。これが変数ではなくコレクションの Patch を使う理由です。変数をトグルすると全行に影響してしまい、行ごとの独立制御ができません。

3パターンの比較

パターン	仕組み	向いている用途	難易度
① Toggle + Visible	Toggle.Value で詳細エリアを表示切替	シンプルな展開・折りたたみ	低
② ネストギャラリー	子ギャラリーの高さを動的計算	詳細に別テーブルデータを表示	中
③ コレクション Patch	ShowDetails 列をコレクションで管理	行ごとの安定した状態管理・全件操作	中

シンプルに始めたいならパターン①、詳細に別データを表示したいならパターン②、Expand All などの全件操作が必要ならパターン③を選ぶのがおすすめです。コレクション操作の基礎についてはコレクション活用入門の記事で改めて確認しておくと、パターン③の実装がよりスムーズになります。

まとめ

ギャラリー内の変数は全行共通になってしまうという制約さえ理解すれば、対処方法は明快です。Toggle・ネストギャラリー・コレクションの Patch、どれも一度作れば次から迷わず使えます。

アコーディオンUIは使いやすいアプリの定番パターンのひとつです。画面のスペースを有効活用しながら情報を整理できるので、社内アプリでも喜ばれることが多いです。ぜひ試してみてください。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power AppsのEditForm・NewForm・DisplayForm。フォームコントロールの仕組みと設定のポイント

Mon, 16 Mar 2026 15:46:49 GMT

Power Appsでフォームを使うなら、EditForm・NewForm・DisplayFormの3種類を正しく使い分けることが基本です。これを曖昧にしたまま開発を進めると、データの読み書きでつまずくことになります。

フォームコントロールは、SharePointリストやDataverseといったデータソースと連携して、データの表示・新規追加・編集を担うコントロールです。Patch関数を自分で書かなくてもデータを保存できるのが最大の魅力です。ただし、使い方の型を知らないと思ったとおりに動かないことも多いので、この記事で仕組みをまとめておきます。

3種類のフォームモードと使い分け

フォームには3つのモードがあります。EditForm・NewForm・DisplayFormというのは厳密にはコントロール名というより、DefaultModeプロパティで設定するモードのことです。実際には1つのフォームコントロールを用途ごとにモード切替して使うか、画面ごとに別のフォームを置くかを選びます。

モード	用途	SubmitForm後の動作
Edit（編集）	既存レコードの更新	既存レコードを上書き保存
New（新規）	新しいレコードの追加	新規レコードとして追加
View（表示）	読み取り専用で表示	保存操作なし

私がよく使うのは、一覧画面（ギャラリー）+ 編集画面（フォーム）という構成です。一覧で選択したレコードを編集画面に渡してEditモードで開く、という流れが王道です。

Itemプロパティの設定が肝心

EditモードでフォームにレコードをバインドするにはItemプロパティの設定が必要です。ギャラリーで選択したレコードをフォームに渡すには、フォームのItemプロパティに次のように書きます。

Gallery1.Selected

これだけで、ギャラリーで選んだ行の内容がフォームに自動的に流れ込みます。Newモードのときは、Itemプロパティを空白（Blank()）にしておくか、何も設定しなければ空のフォームになります。

SubmitFormとResetFormの基本

フォームでデータを保存するにはSubmitForm関数を使います。Patch関数を自分で書く必要がなく、フォームに紐づいたデータソースに自動で書き込んでくれます。

SubmitForm(Form1)

保存後にフォームをリセットしたい場合はResetFormを使います。これを忘れると、次に新規入力しようとしたときに前回の値が残ってしまいます。

ResetForm(Form1)

よくある実装パターンは、保存ボタンのOnSelectに次のように書くことです。

SubmitForm(Form1);
If(Form1.Error = "",
    Navigate(ListScreen, ScreenTransition.None),
    Notify(Form1.Error, NotificationType.Error)
)

Form1.Errorが空文字なら保存成功なので一覧画面に戻り、エラーがある場合はNotifyで画面上にエラーメッセージを表示する、というパターンです。これだけで最低限のエラーハンドリングになります。

OnSuccessプロパティも活用できる

フォームにはOnSuccessというプロパティもあります。SubmitFormが成功したときだけに実行される処理を書けるので、保存後の画面遷移やResetFormをここに書く方がすっきりする場面もあります。好みと設計方針で使い分けてください。

フォームのカードコントロールを理解する

フォームコントロールを画面に追加すると、データソースの各列が自動的にカードコントロールとして並びます。カードはフォームの子コントロールであり、各フィールドの入力欄をカプセル化したものです。

カードのUpdateプロパティを見ると、その入力値がどうデータソースに送られるかが確認できます。例えばテキストカードならTextInputのTextプロパティがUpdateに入っているはずです。

カードのロック解除に注意

デフォルトでカードはロックされていて、直接プロパティを変更できません。カードを右クリックして「カードのロック解除」を選ぶとカスタマイズできるようになりますが、一度ロックを解除するとデータソースの列変更を自動で追従しなくなります。

個人的には、シンプルな入力フォームであれば標準カードをそのまま使い、どうしてもカスタマイズが必要な列だけロック解除するのをおすすめします。全部ロック解除すると後のメンテナンスが大変になります。

EditFormとPatch関数の使い分け

フォームコントロールを使わず、Patch関数で直接データを書き込む方法もあります。どちらを使うべきか迷うことがあると思いますが、目安は以下のとおりです。

用途	おすすめの方法	理由
標準的な入力フォーム	EditForm	カードが自動生成される。バリデーションも組み込み済み
複数レコードの一括更新	Patch関数	フォームは1レコードずつしか扱えない
ボタン1つで部分更新	Patch関数	フォームを使わずピンポイントで列を更新できる
カスタムUIで入力欄を自作	Patch関数	フォームカードのUIに縛られない

フォームコントロールはUI込みで素早く実装できる反面、細かい制御が必要なときには窮屈に感じることもあります。Patch関数の書き方は別記事で詳しく解説しているので、合わせて読んでみてください。

→ Power Appsで絶対覚えたいPatch関数の使い方

また、フォームと組み合わせることの多いSharePointリストの読み書きについては、こちらも参考になります。

→ Power AppsでSharePointリストのデータを読み書きする——基本のCRUDパターン

まとめ

Power AppsのEditForm・NewForm・DisplayFormは、それぞれ編集・新規・表示という3つのモードを持つフォームコントロールです。ItemプロパティでバインドするレコードをSubmitFormで保存する、という流れさえつかめれば、あとは実際に作りながら覚えていける内容です。

最初はPatch関数と比べてフォームコントロールのほうが難しく感じるかもしれません。でも、一度形を作ってしまえばカード自動生成のおかげでスピードが格段に上がります。ぜひ一度シンプルなフォーム画面を作ってみてください。

Power Apps の長い数式を読みやすく整理する｜With関数・改行・コメントで保守できるコードを書く方法

Sat, 18 Apr 2026 08:45:32 GMT

動いているからといって、読みにくい式のままにしておくと、3ヶ月後に自分でもわからなくなります。Power Appsの数式を保守しやすい形で書く方法を説明します。

動けばいいは危険な発想

Power Appsを使い始めて少し慣れてくると、複雑な条件分岐や計算式を書けるようになります。でもその式が長くなればなるほど、後から読み返したときに、これ何をやっているんだろうと迷子になりがちです。

私自身の経験でいえば、半年前に作ったアプリのIf関数の式を見返して、全く意図が読み取れなかったことがあります。動いているからそのままにしていたのですが、少し機能を変えようとしたとき、どこを直せばいいかを探すだけで1時間以上かかりました。

市民開発のアプリは、最初に作った人が長期間メンテナンスすることも多いです。そうでなければ引き継いだ人が困ります。動けばいいという発想は短期的には正しいですが、中長期的にはアプリの保守コストを上げる原因になります。

読みにくい式になりやすいパターン

If関数の入れ子が3段以上になっている
1つのプロパティに10行以上の式が書かれている
同じ計算を複数のコントロールのプロパティで繰り返している
コメントが一切ない

こういった状態は、作った直後はまあいいかと思えても、時間が経つほど修正コストが増えていきます。

改行・インデントで式を整形する

Power Appsの数式エディタでは、Shift+Enterで改行を入力できます。これだけで式の読みやすさが大きく変わります。

例えば、次のような式があります。

If(varStatus = "承認済み", Navigate(完了画面, ScreenTransition.Fade), If(varStatus = "差し戻し", Navigate(修正画面, ScreenTransition.None), Navigate(確認画面, ScreenTransition.None)))

これをShift+Enterで改行・インデントを入れると、次のようになります。

If(
    varStatus = "承認済み",
    Navigate(完了画面, ScreenTransition.Fade),
    If(
        varStatus = "差し戻し",
        Navigate(修正画面, ScreenTransition.None),
        Navigate(確認画面, ScreenTransition.None)
    )
)

同じ式ですが、構造が一目でわかるようになります。条件が何で、真の場合と偽の場合に何をするかが視覚的に区別できます。

インデントのルール

関数の引数ごとに1段インデントを深くする
入れ子の関数はさらに1段深くする
閉じ括弧は開き括弧と同じ深さに揃える

// コメントで意図を残す

Power Appsの数式エディタでは、// 以降をコメントとして記述できます（その行の末尾まで）。コメントは実行時に無視されるので、動作に影響はありません。

// ステータスに応じて遷移先を分岐する
If(
    varStatus = "承認済み",
    Navigate(完了画面, ScreenTransition.Fade), // 承認後は完了画面へ
    If(
        varStatus = "差し戻し",
        Navigate(修正画面, ScreenTransition.None), // 差し戻しは修正画面へ
        Navigate(確認画面, ScreenTransition.None) // それ以外は確認待ち画面へ
    )
)

コメントに書くべきは、何をしているかではなくなぜそうしているか、です。コードを読めば何をしているかはわかります。でもなぜこの条件なのか、なぜこの順番なのかは、書いた人でないとわかりません。

例えば、差し戻し状態のチェックを承認の前に行うと誤判定が起きるため後から判定するといったコメントは、後から読む人にとって非常に価値があります。

With関数で中間変数を作って式を分解する

長い式を短くする最も効果的な方法が、With関数を使って中間変数を作ることです。With関数の基本的な使い方では構文を解説していますが、ここでは保守性を高める観点での使い方を紹介します。

例えば、次のような式があるとします。

If(
    CountRows(Filter(受注リスト, 担当者 = User().Email And ステータス = "未処理")) > 0,
    Notify("未処理の案件が " & Text(CountRows(Filter(受注リスト, 担当者 = User().Email And ステータス = "未処理"))) & " 件あります", NotificationType.Warning),
    false
)

Filter関数の同じ式が2回登場しています。With関数を使うと次のように書き換えられます。

With(
    {
        // 自分担当の未処理件数を先に計算する
        myPendingCount: CountRows(
            Filter(受注リスト, 担当者 = User().Email And ステータス = "未処理")
        )
    },
    If(
        myPendingCount > 0,
        Notify("未処理の案件が " & Text(myPendingCount) & " 件あります", NotificationType.Warning),
        false
    )
)

変数名 myPendingCount が自分担当の未処理件数であることを明示しています。式が1回しか書かれていないため、条件を変えたいときも1箇所だけ直せばよいです。

With関数で中間変数を定義する手順

複数回使っている式や、複雑すぎて読みにくい部分を特定する
With関数のレコードリテラル（波括弧部分）に変数名と式を記述する
本体の式では変数名を参照する

長いIf関数をSwitch関数に書き換える

同じ変数の値に対して複数の条件分岐をする場合、Ifの入れ子よりSwitchのほうがシンプルに書けます。IfとSwitchの使い分けについては別記事で詳しく説明していますが、保守性の観点からもSwitchに書き換えるメリットは大きいです。

先ほどのIf入れ子の例をSwitchで書き直すと次のようになります。

Switch(
    varStatus,
    "承認済み", Navigate(完了画面, ScreenTransition.Fade),
    "差し戻し", Navigate(修正画面, ScreenTransition.None),
    Navigate(確認画面, ScreenTransition.None) // デフォルト
)

Switch関数は、この変数が○○のときは△△、□□のときは▲▲という構造を表現するのに最適です。条件の種類が増えても、縦に追加するだけで対応できます。

一方、条件が変数の値の一致ではなく、複数の条件を組み合わせた判定（AかつB、またはC）の場合はIfのほうが適しています。どちらを選ぶかは同じ変数の値で分岐するか否かを基準に判断するとよいです。

名前付き計算式（App.Formulas）で繰り返し式を一元管理する

複数のコントロールや画面で同じ計算を繰り返している場合、名前付き計算式（App.Formulas）を使うと式の管理が大幅に楽になります。

名前付き計算式とは、アプリ全体で使える計算式の名前を定義する機能です。App.Formulasプロパティに次のように書きます。

myPendingCount = CountRows(Filter(受注リスト, 担当者 = User().Email And ステータス = "未処理"));

こうすることで、アプリの任意のコントロールから myPendingCount という名前で参照できます。受注リストのフィルター条件を変えたいときも、App.Formulasの1箇所を修正するだけで、全コントロールに反映されます。

With関数が、ある式の中での局所的な中間変数を作るのに対し、名前付き計算式はアプリ全体で使えるグローバルな計算式を定義します。繰り返しの多い計算は名前付き計算式に切り出すことをおすすめします。

名前付き計算式の設定手順

Power Apps StudioのツリービューでAppを選択する
プロパティドロップダウンからFormulasを選択する
計算式を「名前 = 式;」の形式で記述する（複数定義する場合はセミコロンで区切る）

名前付き計算式は変数とは異なり、参照されるたびに再計算されます。セットした値を保持するグローバル変数（Set関数）と使い分けることが大切です。詳しい違いはグローバル変数とコンテキスト変数の解説記事も参考にしてください。

まとめ

Power Appsの数式を保守しやすくするための方法として、改行・インデント・コメント・With関数・Switch関数・名前付き計算式の6つを紹介しました。すべてを一度に取り入れる必要はありません。まずは改行とコメントから始めて、式が複雑になってきたらWith関数を使う、という段階的な取り組みが現実的です。

アプリは作って終わりではなく、使いながら改善していくものです。数式エラー解決の全体マップと合わせて活用することで、問題を素早く見つけて直す力もついていきます。読みやすい式を書く習慣は、じわじわと開発の効率を上げてくれます。楽しみながら続けていきましょう。

Power Appsのギャラリーコントロール。リスト表示の基本と検索・選択との組み合わせ

Mon, 16 Mar 2026 15:46:50 GMT

ギャラリーコントロールはPower Appsで一覧表示を作るときに使う、最も基本的なコントロールです。SharePointリストのデータを並べて見せる、タップした行の詳細を表示するといった操作の起点になります。

ギャラリーの基本設定

Itemsプロパティにデータソースを渡す

ギャラリーコントロールを追加したら、まずItemsプロパティにデータソースを設定します。SharePointリストを直接指定するだけで、リストの全件が一覧表示されます。

Items = タスク管理リスト

ギャラリーの左側にある鉛筆アイコン（テンプレートの編集）をクリックすると、1行分のテンプレートを編集できる状態になります。ここに配置したラベルやアイコンがすべての行に繰り返し表示されます。

ThisItemで各行のデータを表示する

テンプレート内のラベルでSharePointリストの値を表示するにはThisItemを使います。

// タイトルを表示するラベルのTextプロパティ
ThisItem.タイトル

// 担当者を表示するラベルのTextプロパティ
ThisItem.担当者名

// 日付を表示するラベルのTextプロパティ
Text(ThisItem.期日, "yyyy/mm/dd")

ThisItemは「現在この行のデータ」を指すキーワードです。ギャラリーが1行ずつデータをループして表示するとき、その行のレコードがThisItemに入ります。

Selectedで選択状態を扱う

タップした行の情報を取り出す

ギャラリーで行をタップすると、その行がギャラリーのSelectedプロパティに格納されます。タップした行の値を別の場所に表示したいときはこれを使います。

// 選択された行のタイトルを別のラベルに表示
ギャラリー1.Selected.タイトル

さらに一歩進めると、タップしたときに詳細画面に遷移してその行のデータを引き渡すことができます。Navigate関数の第3引数にSelectedを渡す方法です。

// ギャラリーのOnSelectプロパティ
Navigate(詳細画面, ScreenTransition.Cover, {selectedRecord: ThisItem})

画面遷移とデータの受け渡しの詳しい解説はNavigate関数の解説にまとめています。ギャラリーとNavigateはセットで覚えると実用的なアプリが作れます。

選択行のハイライト表示

どの行を選んでいるかを視覚的に示したい場合は、ギャラリーのテンプレート背景色をSelectedの状態で切り替えます。

// テンプレートのFillプロパティ
If(ThisItem.IsSelected, RGBA(0, 120, 212, 0.1), RGBA(0, 0, 0, 0))

IsSelectedはその行が現在選択されているかを示すプロパティです。選択時だけ薄い青背景にするだけで、ユーザーが今どの行を選んでいるか一目でわかります。

検索機能との組み合わせ

Search関数でリアルタイム検索

テキスト入力コントロールを検索ボックスとして使い、ギャラリーのItemsプロパティにSearch関数を組み合わせると、文字を入力するたびに一覧が絞り込まれます。

Items = Search(タスク管理リスト, 検索ボックス.Text, "タイトル", "担当者名")

Search関数の第2引数に検索ボックスの入力値を渡し、第3引数以降に検索対象のフィールド名を指定します。複数のフィールドを指定すると、そのうちいずれかに一致する行を返します。

Filter関数で条件絞り込み

ドロップダウンで選んだステータスに一致する行だけを表示したい場合はFilter関数を使います。Search関数と組み合わせることもできます。

Items = Filter(
    Search(タスク管理リスト, 検索ボックス.Text, "タイトル"),
    ステータス = ステータスドロップダウン.Selected.Value
)

検索と絞り込みを同時に使うときは、Filter関数の第1引数にSearch関数をネストします。Filter・Search・LookUpの使い分けや委任の注意点についてはFilter・Search・LookUp関数の解説を参照してください。

委任の警告に注意する

SharePointリストのレコード数が500件を超えると、Filter関数やSearch関数を使ったときに委任の警告（黄色い三角マーク）が出ることがあります。

委任の警告が出ると、実際には条件に合うデータが500件以上あってもアプリ側で最初の500件しか取得できず、検索結果が不完全になります。リストが大きくなりそうな場合は早めに対策が必要です。委任の警告の意味と対処法は委任の警告の解説で詳しく説明しています。

レイアウトの調整とUI

ギャラリーはテンプレートに自由にコントロールを配置できます。ラベルだけでなくボタン・アイコン・画像なども置けます。ただし詰め込みすぎると視認性が下がります。

私が現場で作ったアプリでは、ギャラリーの1行に表示するのはタイトル・ステータス・担当者の3つだけにしています。詳細はタップしてから詳細画面で見せる設計にすることで、一覧がスッキリしてユーザーが迷いません。Power Appsの見た目と使いやすさについてはUI/UX設計の考え方も参考にしてください。

まとめ

ギャラリーコントロールの要点はItemsプロパティ・ThisItem・Selectedの3つです。これを押さえると、一覧表示から検索・詳細遷移まで一通りのフローが作れます。

最初はシンプルなリスト表示から始めて、慣れてきたら検索ボックスや絞り込みを追加していくのがおすすめです。アプリ開発の全体像はPower Apps開発の全体マップで整理しています。

Power Apps ギャラリー完全ガイド｜表示・フィルター・選択・編集・応用の全パターン

Sun, 29 Mar 2026 19:06:15 GMT

Power Apps のギャラリーコントロールは、データの表示・絞り込み・選択・編集・応用UI まで、アプリ開発のあらゆる場面で登場します。この記事では、ギャラリーを使いこなすために知っておくべき内容を5つのテーマに整理して解説します。各テーマの詳細記事へのリンクも掲載しているので、自分の課題に合った記事を選んで読み進めてください。

ギャラリーコントロールとは

ギャラリーコントロールは、データソースのレコードを一覧表示するためのコントロールです。SharePoint リスト・Dataverse テーブル・コレクションなどを Items プロパティに設定するだけで、データを繰り返し表示できます。

ギャラリーの特徴は、テンプレートと呼ばれる1行分のデザインを1つ作るだけで、全行に同じレイアウトが適用されるという点です。テンプレートを変更すれば全行に反映されるため、デザイン変更が簡単です。ギャラリーコントロールの基本的な使い方はギャラリーコントロールの基礎記事でも確認できます。

この記事ではギャラリーを5つのテーマに分けて解説します。テーマ①表示・レイアウト、テーマ②フィルター・絞り込み、テーマ③選択と変数管理、テーマ④編集グリッド、テーマ⑤応用UIの順に進みます。

テーマ①：表示・レイアウト

ギャラリーの見た目はテンプレート内のコントロールで自由にカスタマイズできます。Power Apps が用意しているデフォルトのレイアウトには Image・Title・Subtitle・Body の4種類があり、どれを選ぶかによって初期配置が変わります。

各フィールドのバインド変更（どのデータソース列を表示するか）はプロパティパネルから直感的に設定できます。ルックアップ列のドット記法や、複数列を連結して表示する方法など、実際の業務でよく使うカスタマイズをギャラリーのレイアウト設定記事でまとめています。

選択された行をハイライト表示する方法も押さえておきたいポイントです。TemplateFill プロパティに条件式を書くことで選択行の背景色を変えられますが、Gallery.Selected を使ったパターンと varRecord を使ったパターンでは挙動が異なります。TemplateFill の基本的な設定方法はギャラリーで選択行をハイライトする記事で解説しています。

テーマ②：フィルター・絞り込み

ギャラリーに表示するデータを絞り込むには Filter 関数を使います。Filter 関数は条件が true になる行だけを返します。ドロップダウンやテキスト入力と連動させることで、ユーザーが操作しながらリアルタイムに絞り込めるUIが作れます。

Filter 関数の基本構文とドロップダウン連動の書き方はFilter 関数入門の記事で詳しく解説しています。

ドロップダウンに全件表示のための選択肢（すべて）を追加したい場合は、IsBlank を使った条件分岐が定番パターンです。Table 関数で手動テーブルを作って Distinct と結合する方法も含めて、全件表示の追加方法の記事でまとめています。

And・Or・範囲指定・StartsWith を組み合わせた複合フィルターの書き方は複合フィルターの記事に詳しいです。委任の制約も記事内で触れています。

Dataverse のルックアップ列をフィルター条件にする場合は、文字列ではなく GUID による一致が必要です。これは SharePoint のルックアップ列とは仕組みが異なります。Dataverse フィルターの書き方の記事でその仕組みを解説しています。

テーマ③：選択と変数管理

ギャラリーで選択したレコードをフォームに渡す方法として、Gallery.Selected を使うのはよくある間違いです。Gallery.Selected は便利に見えますが、新規入力モードとの組み合わせで選択ズレが発生し、保存後にフォームが前のレコードに戻るというバグが起きます。

これを解決するのが varRecord 変数を使ったパターンです。OnSelect で UpdateContext({varRecord: ThisItem}) を実行して選択レコードを変数に格納し、フォームの Item は varRecord を参照させます。詳しい置き換え手順はGallery.Selected を使ってはいけない理由と varRecord への置き換え方の記事で解説しています。

varRecord を導入した後の新規追加・保存後のレコード選択・プレースホルダーUIの実装パターンまでをまとめた記事がギャラリーとフォームを変数でつなぐ記事です。OnSuccess での LastSubmit 活用など、実用的な実装パターンが一通り揃っています。

テーマ④：編集グリッド

Excel のように行を直接編集できるUIが编集グリッドです。ギャラリーテンプレート内に TextInput や Dropdown を配置して、コレクションを中間バッファとして使うのが基本設計です。

ClearCollect でコレクションを初期化する際の列型定義のコツや、DisplayMode プロパティで編集・閲覧モードを切り替える方法は編集グリッドの基本設計の記事でまとめています。

行ごとの保存（Patch）・IsNew フラグを使った新規行と既存行の判別・削除確認ダイアログ・ForAll を使った一括保存の実装パターンは編集グリッドのデータ保存の記事で解説しています。

テーマ⑤：応用UI

ギャラリーの応用パターンとして、フレキシブル高さ・展開折りたたみ・複数選択・タブUIの4つを紹介します。

フレキシブル高さギャラリー

通常ギャラリーは行の高さが固定ですが、フレキシブル高さギャラリーは内容量に応じて行の高さが自動で変わります。コメント一覧や説明文など、テキスト量がばらつくデータに向いています。AutoHeight プロパティや TemplateSize の仕組みはフレキシブル高さギャラリー入門の記事で解説しています。

展開・折りたたみ（アコーディオン）

行をクリックすると詳細が展開されるアコーディオンUIは、Toggle・ネストギャラリー・コレクション Patch の3パターンで実装できます。行ごとに独立した状態を持てる理由と、Expand All / Collapse All の実装方法は展開・折りたたみの実装パターンの記事で詳しく解説しています。

複数選択チェックボックス

ギャラリーの複数行にチェックを入れて一括操作するUIは、Gallery.AllItems プロパティを使って実現します。選択済みアイテムの取得・選択数の表示・Select All / Deselect All の実装は複数選択チェックボックスの実装記事でまとめています。選択中のときだけアクションエリアを表示するコンテナを使ったUIの作り方は複数選択時のアクションエリアの記事で解説しています。

タブUI

モダンコントロールのタブが制限的な場面では、ギャラリーをタブバーとして使うパターンが有効です。コレクションでタブ一覧を管理して varSelectedTab で切り替える設計は、デザインの自由度が高くレスポンシブ対応も容易です。実装の流れ全体はギャラリーをタブUIとして使う記事で解説しています。

📷 画像生成プロンプト：白背景のクリーンな概念図。ギャラリーの5つの応用パターン（フレキシブル高さ・アコーディオン・複数選択・タブUI・編集グリッド）を5つのアイコンと短いキャプションで横並びに示すインフォグラフィック風の図解。各パターンは独立したブロックとして表現し、矢印やつながりは不要。白背景・シンプル・クリーン。

まとめ：ギャラリーの5テーマ早見表

テーマ	内容	主な記事
① 表示・レイアウト	フィールドのバインド・ハイライト	レイアウト設定・TemplateFill
② フィルター	単一・複合・全件表示・Dataverse	Filter基本〜Dataverseフィルター
③ 選択と変数管理	varRecord・フォーム連携	varRecord・ギャラリー×フォーム
④ 編集グリッド	行内編集・保存・削除・一括保存	編集グリッド基本・保存パターン
⑤ 応用UI	フレキシブル・折りたたみ・複数選択・タブ	グループE各記事

ギャラリーコントロールは Power Apps の中でも使う頻度が特に高い部品です。表示から始めて、フィルター・変数管理・編集グリッドと段階的に習得していくと、できることの幅が大きく広がります。一つひとつ手を動かしながら積み重ねていきましょう。

Power Apps ギャラリーの複合フィルター｜And・Or・範囲・StartsWith を組み合わせる

Sun, 29 Mar 2026 19:06:16 GMT

Filter 関数の基本と全件表示対応を覚えたら、次は And・Or・範囲・StartsWith を組み合わせた複合フィルターです。複数の Dropdown を使った絞り込みや、テキスト入力での範囲指定まで実装できるようになります。

And：複数条件がすべて true のときだけ返す

And は複数の条件をすべて満たす行だけを返します。ステータスと担当者の両方で絞り込む場合は次のように書きます。

Filter(Tasks, Status = Dropdown1.Selected.Value And AssignedTo = Dropdown2.Selected.Value)

And を使うと条件が増えるほど絞り込みが厳しくなります。3つ以上の条件を繋ぐことも可能で、同じように And を続けるだけです。

複合条件を書くときは、各条件を単独でテストして動くことを確認してから And で繋ぐのがコツです。最初から全部書こうとするとどこが間違っているか特定しにくくなります。Filter 関数の入門記事で解説したハードコードでの動作確認の手順と同じ考え方です。

Or：どちらかが true なら返す

Or は条件のどちらか一方が true なら行を返します。複数のステータスをまとめて表示したいときに使います。

Filter(Tasks, Status = "未着手" Or Status = "進行中")

Dropdown に全件表示の All を追加するパターンでもすでに Or を使っています。Or と IsBlank を組み合わせた全件表示で詳しく解説しているので、そちらも合わせて確認しておくと Or の使い所が一気に広がります。

括弧による条件のグループ化

And と Or を混在させる場合、括弧を使って評価の優先順位を明確にする必要があります。括弧なしで書くと And の方が Or より優先されるため、意図しない絞り込みになることがあります。

複数の Dropdown にそれぞれ全件表示（All）を持たせる実装例を示します。

Filter(
    Tasks,
    (Dropdown1.Selected.Value = "All" Or Status = Dropdown1.Selected.Value)
    And
    (Dropdown2.Selected.Value = "All" Or AssignedTo = Dropdown2.Selected.Value)
)

各 Dropdown のブロックを括弧でくくり、And で繋いでいます。このパターンを覚えると、Dropdown を何個追加しても同じ構造で対応できます。1ブロックずつ追加・動作確認しながら組み立てていきましょう。

範囲フィルター（数値・日付）

数値や日付の範囲で絞り込むには > と < を組み合わせます。

数値の範囲指定

予算が 10,000 以上 50,000 以下の行を返す例です。

Filter(Tasks, Budget >= 10000 And Budget <= 50000)

上限・下限のどちらかだけを指定したい場合は片方だけ書けばよいです。たとえば Budget >= 10000 だけなら、10,000 以上の行をすべて返します。

TextInput で最小値・最大値を動的指定する

テキスト入力コントロール（TextInput）を使うと、ユーザーが最小値・最大値を入力して動的に絞り込めます。

Filter(
    Tasks,
    Budget >= Value(MinInput.Text) And Budget <= Value(MaxInput.Text)
)

TextInput の Text プロパティはテキスト型のため、数値列との比較には Value 関数で型変換が必要です。

これを忘れると型エラーになります。私はこの変換を忘れて何度かエラーに悩みましたが、数値の入力欄は必ず Value() を使う、と覚えてからはスムーズに書けるようになりました。

なお、TextInput が空のときに Value(MinInput.Text) は 0 または Blank() を返します。空欄のとき全件を返したい場合は IsBlank 判定を追加してください。

日付の範囲指定

日付範囲の絞り込みには DatePicker コントロールを使うのが便利です。

Filter(
    Tasks,
    DueDate >= DatePicker1.SelectedDate And DueDate <= DatePicker2.SelectedDate
)

DatePicker.SelectedDate は Date 型を直接返すため、型変換なしで日付列と比較できます。SharePoint の日付列は DateTime 型であることが多く、時刻の差異で一致しないケースがあります。そのときは DateValue 関数で日付部分だけを取り出して比較します。

StartsWith：前方一致フィルター

StartsWith は列の値が指定した文字列で始まる行を返します。テキスト検索ボックスと組み合わせて使うのが典型的なパターンです。

Filter(Tasks, StartsWith(Title, SearchInput.Text))

タイトルの前方一致で絞り込む例です。SearchInput にテキストを入力するたびに、ギャラリーがリアルタイムで絞り込まれます。

StartsWith か Search か

テキスト検索には StartsWith（前方一致）と Search（部分一致）の2つの選択肢があります。Filter・Search・LookUp の使い分けでも触れていますが、委任の観点では大きな違いがあります。

関数	マッチ方式	委任	向いている用途
StartsWith	前方一致	SharePoint・Dataverse で委任可	コード番号・氏名の頭文字など
Search	部分一致	委任不可	件数が少ないリストのキーワード検索

大量データのテキスト検索には StartsWith を使うか、検索対象を件数の少ないリストに限定するか、どちらかを選択してください。Search を使いたい場合は委任の上限（既定 500〜2,000件）を超えないか事前に確認が必要です。委任の仕組みと対処法については委任の警告と対処法を参考にしてください。

全部組み合わせた実装例

Dropdown 2つ・テキスト検索・日付範囲をまとめて組み合わせた複合フィルターの例を示します。

Filter(
    Tasks,
    (Dropdown1.Selected.Value = "All" Or Status = Dropdown1.Selected.Value)
    And
    (Dropdown2.Selected.Value = "All" Or AssignedTo = Dropdown2.Selected.Value)
    And
    StartsWith(Title, SearchInput.Text)
    And
    DueDate >= DatePicker1.SelectedDate
    And
    DueDate <= DatePicker2.SelectedDate
)

長い数式ですが、各ブロックは独立しているので1つずつ追加・確認しながら組み立てられます。私は常にこの方法で複合フィルターを組み立てます。Dropdown1 の条件だけで動作確認 → Dropdown2 を追加 → テキスト検索を追加 → 日付範囲を追加、という順番で進めると詰まりにくいです。

なおこの数式ではすべての条件が常に評価されます。DatePicker が初期状態のとき、DueDate >= DatePicker1.SelectedDate が予期しない結果を返す場合があります。

DatePicker を空にしたときは全件を返すよう IsBlank 判定を追加するなど、実装後の動作確認も丁寧に行いましょう。

まとめ

And・Or・範囲・StartsWith を組み合わせることで、業務アプリで必要なフィルターのほぼすべてを実装できます。複雑に見えますが、各ブロックはシンプルなルールの積み重ねです。1つずつ追加・確認しながら組み立てるのが、完成への最短ルートです。

フィルターを使いこなせると、アプリの検索・絞り込み体験が大きく向上します。次はギャラリーの選択行ハイライトや、フォームとの変数連動にも挑戦してみましょう。レイアウトの設定と組み合わせることで、見た目も機能も整ったギャラリー画面が完成します。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーに「すべて表示」を追加する｜Or + IsBlankパターン完全解説

Sun, 29 Mar 2026 19:06:16 GMT

Dropdown でデータを絞り込めるようにしたら、次に欲しくなるのが全件表示に戻すオプションです。Or 方式と IsBlank 方式の2パターンを整理しておきます。どちらも覚えておくと実務で必ず役に立ちます。

All を追加したいという典型的なニーズ

Filter 関数と Dropdown を連動させると、常に何かが選択された状態になります。最初は気にならなくても、アプリを使っていると全件を見直したい場面が必ず出てきます。社内アプリを展開したとき、ユーザーから「全部表示に戻すにはどうするの？」という質問が来ることは珍しくありません。

対策は2つあります。Dropdown の選択肢に All を追加して Or 条件で全件を返す方法と、Dropdown の Allow empty selection をOnにして IsBlank で全件表示に切り替える方法です。それぞれ見ていきます。

パターン1：Or 方式（Dropdown に All を追加）

Distinct に All の行を追加する

Dropdown の Items に Distinct 関数を使っている場合、そのままでは All という選択肢が含まれません。Table 関数と Ungroup を組み合わせることで、Distinct の結果に All を先頭に追加できます。

Ungroup(
    Table(
        {Value: "All"},
        {Value: Distinct(Tasks, Status)}
    ),
    "Value"
)

少し複雑に見えますが、やっていることはシンプルです。{Value: “All”} という1行のレコードと、Distinct が返したテーブルを Table 関数でまとめ、Ungroup でフラットなテーブルに展開しているだけです。このテーブルを Dropdown の Items に指定します。

なお Distinct 関数は委任対象外のため、2,000件を超えるデータには注意が必要です。この点については委任警告の解説記事で詳しくまとめています。大量データを扱う場合は選択肢の管理方法も合わせて検討してください。

Or でAll 選択時のロジックを書く

Dropdown.Selected.Value が All のとき、フィルターをスキップして全件返すには Or 条件を使います。ギャラリーの Items を次のように変更します。

Filter(
    Tasks,
    Dropdown1.Selected.Value = "All" Or Status = Dropdown1.Selected.Value
)

Or の最初の条件（Dropdown1.Selected.Value = “All”）が true になると、Power Apps の短絡評価により2つ目の条件は評価されず、行全体が true になります。結果として全件が返ります。All 以外の値が選ばれているときは最初の条件が false になるため、Status の一致で通常の絞り込みが行われます。

Default を設定して初期表示を All にする

アプリ起動時に All が選ばれた状態で全件表示したい場合は、Dropdown の Default プロパティに次を設定します。

{Value: "All"}

これだけで、アプリを開いたときに自動で All が選択された状態になります。

パターン2：IsBlank 方式（Allow empty selection）

Allow empty selection の設定

Dropdown には Allow empty selection（空選択を許可）というプロパティがあります。これをOnにすると、選択肢の最上部に空の選択肢（未選択状態）が表示されます。Dropdown を選択した状態で右ペインのプロパティを開き、Allow empty selection をOnに変更するだけです。

IsBlank で空選択を全件表示に変換する

空選択状態のとき Dropdown1.Selected.Value は空白（Blank）になります。IsBlank と Or を組み合わせることで、未選択時を全件表示に変換できます。

Filter(
    Tasks,
    IsBlank(Dropdown1.Selected.Value) Or Status = Dropdown1.Selected.Value
)

IsBlank(Dropdown1.Selected.Value) が true のとき、つまり何も選ばれていないとき、Or 条件全体が true になり全件が返ります。IsBlank は Power Apps でよく使う判定関数で、Filter・Search・LookUp の使い分け記事でも関連する使い方を紹介しています。

Or 方式 vs Allow empty 方式の比較

比較項目	Or 方式（All 追加）	Allow empty 方式
Dropdown の見た目	All が選択肢に表示される	空欄が表示される
ユーザーへの直感性	All があり分かりやすい	空欄の意味が伝わりにくい
実装の複雑さ	Table＋Ungroup が必要	IsBlank だけで完結
初期全件表示	Default に {Value:“All”} を設定	自然に空選択で全件表示

個人的には Or 方式の方が好きです。ユーザーに All という選択肢が見えるので、操作が直感的に理解できます。Allow empty 方式は実装はシンプルですが、空欄が何を意味するのか説明なしには伝わりにくいケースがあります。社内アプリを展開するとき、説明なしで使ってもらえる設計を優先しています。

一方で Allow empty 方式の方が合うケースもあります。たとえば検索フィルターとして使う場合、未入力＝全件という動作は直感的です。アプリの用途やユーザーの特性に合わせて選んでください。

複数条件のフィルターに拡張する

全件表示を実装したら、次は複数の Dropdown を組み合わせた複合フィルターにも挑戦できます。And を使って複数条件をすべて満たす行を絞り込んだり、日付の範囲指定を組み合わせたりするパターンです。

たとえばステータスと担当者の両方で絞り込む場合は次のように書きます。

Filter(
    Tasks,
    (Dropdown1.Selected.Value = "All" Or Status = Dropdown1.Selected.Value)
    And
    (Dropdown2.Selected.Value = "All" Or AssignedTo = Dropdown2.Selected.Value)
)

条件のブロックを And で繋ぐだけです。各ブロックの中に Or 方式の全件表示ロジックをそのまま使い回せます。複合フィルターを作ると、アプリの検索・絞り込み機能が一気に実用的になります。

まとめ

全件表示への切り替えは、Or 方式と IsBlank 方式の2つで確実に実装できます。ユーザーの使いやすさを優先するなら Or 方式、コードをシンプルに保ちたいなら Allow empty 方式が向いています。

Filter 関数の基礎から全件表示対応まで身に付けると、業務アプリで必要なリスト絞り込みのほとんどを自力で作れるようになります。Filter 関数入門と合わせて読んでおくと、ギャラリーの絞り込み機能を一通り理解できます。楽しみながら開発を進めましょう。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーのFilter関数入門｜単一条件・Dropdown連動の基本パターン

Sun, 29 Mar 2026 19:06:17 GMT

Filter 関数の使い方を覚えると、ギャラリーで表示するデータを自由に絞り込めるようになります。構文はシンプルですが、Dropdown との連動・委任の落とし穴まで理解しておくと、実務で詰まることが大幅に減ります。

Filter 関数の基本構文

Filter 関数は、テーブルと条件式の2つを引数に取ります。

Filter(テーブル名, 条件式)

テーブル名には SharePoint リストや Dataverse テーブルのデータソース名を指定します。条件式には true/false を返す式を書きます。Filter 関数はテーブルの各行に対して条件を評価し、true になった行だけを返します。簡単にいえば、条件を満たすレコードだけを通過させるフィルター、というイメージです。

条件がtrueであれば返す、という考え方

Excel のフィルター機能は手動で操作しますが、Power Apps の Filter 関数は数式として書くため、変数やコントロールの値と連動できます。Dropdown で選んだ値をそのまま条件式に組み込めるのは、このおかげです。

条件式が false になった行は返ってきません。全件表示に戻したい場合は、Dropdown に All を追加して Or 条件と組み合わせる方法が一般的です。全件表示対応のパターンは次の記事で詳しく解説しています。

列は左辺・値は右辺というルール

Filter 関数の条件式は、必ず列名を左辺に、比較する値を右辺に書きます。

Filter(Tasks, Status = "完了")

Tasks テーブルから Status 列が完了に一致する行だけを返す例です。左辺が列・右辺が値、というルールは必ず守ってください。逆に書いても一見動くことがありますが、委任（Delegation）の観点から問題が生じます。委任とは Power Apps がデータソース側にクエリを委譲する仕組みのことで、左辺に列を置くことで委任が正しく機能します。委任についてはPower Apps の委任警告の解説でまとめているので、フィルターを使い始めたタイミングで一読しておくことをおすすめします。

比較演算子は = の他に <>（不一致）・>・<・>=・<= も使えます。テキストの前方一致には StartsWith 関数、部分一致には In 演算子を使います。

まずはハードコードで動作確認する

Filter 関数を初めて使うときは、値をいったんハードコードして動作を確認することをおすすめします。動くことを確認してから Dropdown と連動させると、問題の切り分けがしやすくなります。

Filter(Tasks, AssignedTo = "守屋")

私自身、最初からDropdownと組み合わせようとして、どこで詰まっているのかわからない状態になったことがあります。シンプルな条件で動作を確認してから段階的に複雑にしていくのが、Power Apps 開発の基本的な進め方です。

ギャラリーの Items プロパティに Filter 関数を書く場合は次のようになります。

Filter(TasksList, AssignedTo = "守屋")

TasksList は接続したデータソースの名前です。ギャラリーにデータソースを接続する基本的な手順についてはギャラリーコントロールの基礎記事も参考にしてください。

ハードコードで動作確認できたら、次は Dropdown の選択値と連動させます。ここが Filter 関数の実用的な使い方の核心です。

まずスクリーンに Dropdown コントロールを追加します。Items プロパティに選択肢を設定してください。ひとまず手動でテキストを入力するなら次のように書きます。

["未着手", "進行中", "完了"]

この段階では選択肢がハードコードになっていますが、まず動作の確認を優先します。

Dropdown.Selected.Value を条件に使う

Dropdown を配置したら、ギャラリーの Items を次のように変更します。

Filter(Tasks, Status = Dropdown1.Selected.Value)

Dropdown1.Selected.Value は、Dropdown で現在選ばれている項目の Value プロパティです。ここを条件の右辺に置くだけで Dropdown と連動したフィルターが完成します。Dropdown の選択が変わるたびにギャラリーが自動で再描画されるため、OnSelect やボタンは不要です。Power Apps のリアクティブな動作のおかげで、このシンプルな数式一行だけで連動が実現します。

Distinct でDropdown の選択肢を自動生成する

Dropdown の選択肢を手動で管理するのは手間がかかります。データが増えるたびに選択肢を更新しなければならないからです。Distinct 関数を使えば、データソースの列から重複を除いた一覧を自動で生成できます。

Distinct(Tasks, Status)

このテーブルを Dropdown の Items に指定します。データが追加されると選択肢が自動更新されるので、メンテナンスコストを大幅に下げられます。

ただし Distinct を使う場合、Dropdown の Value プロパティが Result になります。Filter 関数の条件式では Dropdown1.Selected.Value ではなく Dropdown1.Selected.Result を使う必要があります。ここで詰まる方が多いので注意してください。

なお、Filter・Search・LookUp の3つの関数はそれぞれ用途が異なります。絞り込み以外の使い方も含めて理解したい方はFilter・Search・LookUp関数の違いと使い分けを参照してください。

Distinct は委任対象外なので注意

Filter 関数自体は SharePoint や Dataverse に対して委任が効きますが、Distinct 関数は委任対象外です。つまり、2,000件を超えるテーブルに対して Distinct を使っても、先頭 2,000件の中からしか選択肢が生成されません。

たとえば20人が使う日報アプリで1日20件、月400件、5ヶ月で2,000件を超えます。件数が増えてくるタイミングで Distinct が正しく動かなくなるため、初期設計の段階で考慮しておく必要があります。委任の仕組みを理解しておくと、こういったトラブルを未然に防げます。委任の警告と対処法もあわせて確認しておきましょう。

Distinct の委任制限を回避したい場合は、SharePoint の選択肢列や Dataverse の Choices 型で選択肢を管理して、Choices 関数または ColumnValues 関数で取得する方法を検討してください。

まとめ

Filter 関数の基本は、テーブルと条件式の2つを書くだけです。まずハードコードで動作確認し、次に Dropdown と連動させ、さらに Distinct で選択肢を自動生成する、という順番で進めると詰まりにくいです。

絞り込みができるギャラリーが完成すると、アプリの使いやすさが格段に上がります。次のステップとして、絞り込み後に全件表示へ戻す仕組みも作っておきましょう。Or と IsBlank を使った全件表示パターンで詳しく解説しています。フィルターを使いこなせると、業務アプリらしいリスト画面が自力で作れるようになります。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps × DataverseのギャラリーをDropdownで絞り込む｜ルックアップ列フィルターの書き方

Sun, 29 Mar 2026 19:06:13 GMT

Dataverse のルックアップ列を Filter 関数の条件にするとき、SharePoint のルックアップ列と同じ書き方をしても動きません。GUID による一致という仕組みを理解すると、詰まることなく実装できます。

Dataverse のルックアップ列をフィルター条件にするときの特殊性

SharePoint のルックアップ列であれば、Filter 関数の条件式に列名と表示名（文字列）の一致を書けば動きます。ところが Dataverse のルックアップ列（リレーション列）は、文字列ではなくレコード型を返します。表示名での比較を試みても一致しないため、絞り込みが機能しません。

この問題でつまずく方は非常に多いです。私自身、SharePoint で慣れた書き方をそのまま使って動かず、しばらく原因がわからなかったことがあります。Dataverse のフィルターは GUID の一致で行う、と最初に知っておくだけで無駄な時間を省けます。

テーブル名.テーブル名が GUID を返す仕組み

Dataverse のルックアップ列（たとえば担当者列がユーザーテーブルを参照している場合）を参照すると、Power Apps はそのリレーション先のレコードを返します。さらにそのレコードに対してリレーション先のテーブル名をドット記法で続けると、プライマリキー（GUID）が返ってきます。

Tasks テーブルに担当者というルックアップ列があり、それが Users テーブルを参照している場合、次のように書くと担当者の GUID が取得できます。

ThisItem.担当者.Users

末尾の Users はリレーション先のテーブル名で、これが GUID（一意識別子）を返します。Dataverse の GUID についてはDataverseにIDがない理由｜GUIDとは何かで解説しているので、仕組みを先に理解しておくとスムーズです。

Dropdown.Selected.テーブル名との一致でフィルターする

仕組みを理解したら、実際の Filter 関数を書きます。Dropdown のデータソースを Users テーブルに設定している場合、Dropdown で選択されたレコードの GUID は次のように取得できます。

Dropdown1.Selected.Users

これをギャラリーの Items の Filter 関数に組み込みます。

Filter(
    Tasks,
    担当者.Users = Dropdown1.Selected.Users
)

左辺の担当者.Users がレコード側の GUID、右辺の Dropdown1.Selected.Users が Dropdown で選択された行の GUID です。同じ型同士の比較になるため、正しく一致判定が行われます。

Dropdown の Items プロパティには Users テーブルをそのまま指定します。

Users

画面上は名前が表示されていても、内部では GUID で比較しているのがポイントです。Dropdown の DisplayFields プロパティで表示列を氏名列などに設定すると、ユーザーには名前が見えた状態で GUID フィルターを実現できます。

名前一致ではなく GUID 一致を使う理由

名前（文字列）での一致が使えないのには設計上の理由があります。Dataverse のルックアップ列は、表示名ではなくリレーション先レコードの一意識別子（GUID）で関係を管理しているからです。

たとえば同姓同名の担当者が2人いる場合、名前で比較すると両方がヒットしてしまいます。GUID はレコードごとに必ず異なるため、正確な絞り込みができます。Dataverse がリレーションを GUID で管理している設計上、フィルターも GUID で行うのが唯一の正しいアプローチです。

Filter 関数の基本では SharePoint を前提にした条件式を解説しています。Dataverse を使う場合はこの違いを意識しながら書くようにしてください。

IsBlank と Or で全件表示に対応する

Dropdown で何も選ばれていないとき全件表示に戻す実装も追加しておきましょう。Or と IsBlank を使った全件表示パターンと同じ考え方で書けます。

IsBlank 方式（Allow empty selection）

Dropdown の Allow empty selection をOnにしておくと、未選択時に Dropdown1.Selected.Users が Blank になります。

Filter(
    Tasks,
    IsBlank(Dropdown1.Selected.Users) Or 担当者.Users = Dropdown1.Selected.Users
)

IsBlank が true のとき Or 全体が true になり、全件が返ります。Dataverse を使う場合、All の選択肢を別途追加するより IsBlank 方式の方が型変換の問題が起きにくく、個人的にはこちらをよく使います。

SharePoint のルックアップ列との比較

比較項目	SharePoint ルックアップ列	Dataverse ルックアップ列
フィルターの比較対象	表示名（文字列）でも可	GUID（一意識別子）で行う
値の取得方法	ThisItem.列名.Value	ThisItem.列名.テーブル名
Dropdown の Items 設定	Choices 関数・手動リスト	Dataverse テーブルを直接指定
型の扱い	テキスト型として扱える	レコード型・GUID 型

SharePoint に慣れた状態で Dataverse を使い始めると、この違いで必ずつまずきます。反対にいえば、GUID での比較という概念さえ理解すれば、その後は迷わず書けます。Dataverse のテーブル設計全体についてはSharePointと違うDataverseのテーブル作成フローでまとめているので、合わせて読んでおくと理解が深まります。

まとめ

Dataverse のルックアップ列フィルターのポイントは、名前ではなく GUID で比較する、という1点に尽きます。ThisItem.列名.テーブル名と Dropdown1.Selected.テーブル名を一致させる書き方を覚えれば、どのルックアップ列でも同じパターンで対応できます。

SharePoint から Dataverse に移行するとき、最初のハードルのひとつがこのフィルターの書き方です。仕組みを理解した上で実装すれば、詰まることなく完成まで進めます。楽しみながら開発を進めましょう。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーとフォームを変数でつなぐ｜新規・保存・プレースホルダーの完全パターン

Sun, 29 Mar 2026 19:06:14 GMT

ギャラリーで選択したレコードをフォームに渡すとき、変数を使って連携すると新規作成・保存後の挙動が安定します。Gallery.Selected から varRecord に切り替えた前提で、新規ボタン・保存後の選択・プレースホルダーUIの実装パターンを一通り解説します。

Gallery.Selected の問題点と varRecord への基本的な置き換え方は、Gallery.Selected を使ってはいけない理由の記事で解説しています。この記事はその続きとして、フォームとの連携に特化した内容です。

変数でギャラリーとフォームをつなぐ設計の全体像

まず全体の設計を確認しておきます。ギャラリーとフォームを変数でつなぐ構成には、次の4つの状態を制御することが必要です。

選択状態：ギャラリーのどのレコードを見ているか（varRecord）
フォームモード：表示・編集・新規のどの状態か（EditForm の Mode）
フォームの Item：varRecord を参照していること
プレースホルダー：レコード未選択のときにフォームエリアに何を表示するか

この4つをそれぞれ正しく設計するだけで、ユーザーが操作しても迷わないアプリになります。一つずつ実装していきましょう。

新規ボタンの設計

新規ボタンの OnSelect では3つのことをやります。フォームを新規モードにする、varRecord をリセットする、そしてハイライトを消すです。

NewForm(EditForm1);
UpdateContext({varRecord: Blank()})

NewForm(EditForm1) でフォームを新規入力モードに切り替えます。UpdateContext({varRecord: Blank()}) で varRecord を空にすることで、ギャラリーのハイライトがすべて消えます。

フォームの Item は varRecord を参照しているので、varRecord が Blank になるとフォームも空になります。ギャラリーで何かを選択していた状態でも、新規ボタンを押せばきれいにリセットされます。これが Gallery.Selected を使っていたときには実現できなかった動きです。

保存後に新規レコードを選択状態にする

保存ボタンを押してフォームを送信した後、新しく作られたレコードを自動的に選択状態にしたい場面があります。Power Apps の EditForm には OnSuccess プロパティがあり、送信が成功したときに実行する処理を書けます。

UpdateContext({varRecord: EditForm1.LastSubmit});
ViewForm(EditForm1)

EditForm1.LastSubmit は、直前に送信されたレコードそのものを返します。これを varRecord にセットすることで、保存が完了した直後に新しいレコードが varRecord に入り、ギャラリーのハイライトが新規レコードの行に移動します。ViewForm(EditForm1) でフォームを表示モードに戻すことも忘れないようにしましょう。

ここが Gallery.Selected との一番大きな違いです。Gallery.Selected は保存後のギャラリー再取得タイミングによって結果がブレますが、LastSubmit を varRecord にセットする方法は保存成功時に確実に動きます。体感では、この実装に変えてから保存後のフォームズレが完全になくなりました。

フォームの Item と Mode の設定

EditForm の設定を確認しておきます。

プロパティ	設定値	備考
Item	varRecord	選択レコードを参照
DefaultMode	FormMode.View	初期表示は読み取り専用

フォームコントロールの基本的な仕組みや EditForm・NewForm・DisplayForm の違いについては、フォームコントロールの仕組みと設定のポイントの記事も参考にしてください。

Item に varRecord を渡すだけで、ギャラリーの選択に関係なくフォームが安定して動くようになります。DefaultMode を FormMode.View にしておくと、選択したレコードをまず表示モードで見せられるので UX としても自然です。編集する場合は別途 EditForm を呼び出すか、編集ボタンを設置します。

プレースホルダーを表示する

アプリを開いたばかりや、何も選択していないときにフォームエリアが空白だと、ユーザーはそこに何か表示されるのか、故障しているのか判断できません。プレースホルダーUIを用意しておくだけで、操作の手がかりが増えてユーザーの迷いが減ります。

プレースホルダーの表示条件

フォームエリアの上にラベルやコンテナを置き、表示条件を次のように設定します。

IsBlank(varRecord) And EditForm1.Mode <> FormMode.New

varRecord が空（何も選択していない）かつフォームが新規モードでないときだけ表示する、という条件です。新規入力中はプレースホルダーを出さずにフォームを前面に出したいので、FormMode.New を除外しています。

プレースホルダーのテキスト例

プレースホルダーに表示するメッセージは短くシンプルなものが効果的です。

← 左のリストから項目を選択してください
👆 上から確認したいタスクを選んでください
左のギャラリーから選択すると詳細が表示されます

絵文字や矢印アイコンを入れると、どこを操作すればいいか視覚的に伝わりやすくなります。個人的には、プレースホルダーにひと手間かけるだけで社内ユーザーの問い合わせが明らかに減ったので、これは省かずに入れておくことをおすすめします。

OnStart・OnVisible でデフォルトレコードを指定する

アプリを開いたときやスクリーンに遷移したときに、ギャラリーの先頭レコードを自動的に選択状態にするパターンもよく使います。

UpdateContext({varRecord: First(GalleryTasks.AllItems)})

OnVisible にこの式を入れておくと、スクリーンを開くたびにギャラリーの先頭レコードが varRecord にセットされます。ユーザーが何もしなくても先頭のレコードが表示されている状態になるので、空白のフォームエリアを見せずに済みます。

OnStart と OnVisible の使い分けについては、OnStart と OnVisible どちらに書くべきかをあわせて読むと整理しやすいです。

まとめ

ギャラリーとフォームを varRecord でつなぐパターンを整理すると、次のように設計が固まります。

操作	やること
行をタップ	OnSelect で UpdateContext({varRecord: ThisItem})
新規ボタン	NewForm + UpdateContext({varRecord: Blank()})
保存後	OnSuccess で varRecord を LastSubmit に + ViewForm
未選択時	IsBlank(varRecord) のプレースホルダーを表示
初期表示	OnVisible で First() を varRecord にセット

一度このパターンをマスターすると、どのアプリでも迷わず同じ設計で組めるようになります。個人的には、これを習得した後の開発速度が明らかに上がりました。積み重ねの力を実感できる部分ですので、ぜひ一度手を動かして試してみてください。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーで選択行をハイライトする｜TemplateFillの設定方法

Sun, 29 Mar 2026 19:06:17 GMT

ギャラリーの選択行をハイライトするには TemplateFill プロパティを使います。まず IsSelected で動かしてみて、その問題点を理解した上で変数（varRecord）管理に切り替えるのが正しい順番です。

TemplateFill とは何か・どこで設定するか

TemplateFill はギャラリーの各行（テンプレート）の背景色を設定するプロパティです。通常は Transparent（透明）が設定されていて、どの行も同じ背景のフラットな表示になっています。ここに条件付きの色を設定することで、選択行だけを目立たせられます。

テンプレート領域を選択する方法

TemplateFill を設定するには、ギャラリーのテンプレート領域（行の背景部分）を選択する必要があります。ギャラリーをクリックするとギャラリー全体が選択されますが、そこからもう一度クリックするとテンプレート内に入ります。慣れないうちはツリービューからギャラリー配下の Template を直接選ぶのが確実です。

テンプレートを選択できたら、数式バー左側のプロパティドロップダウンから TemplateFill を選んで数式を入力します。右ペインのプロパティタブから探すより、数式バーのドロップダウンを使う方がすぐ見つかります。ギャラリーコントロールの基本的な構造についてはギャラリーコントロールの基礎記事も参考にしてください。

IsSelected を使ったシンプルなハイライト

まずは IsSelected を使った最もシンプルな実装から試しましょう。完成形に向けていきなり変数を使うのではなく、まず動く状態を作って挙動を確認するのが Power Apps 開発の進め方です。

TemplateFill に If 条件を書く

TemplateFill に次の数式を入力します。

If(ThisItem.IsSelected, ColorFade(Color.Blue, 0.7), Transparent)

これだけで、クリックした行が青色でハイライトされます。IsSelected は Power Apps がギャラリーの各行に自動で付与するプロパティで、その行が選択状態のとき true を返します。

ColorFade で色を薄める

ColorFade(Color.Blue, 0.7) は Blue を 70% 薄くした色を返す関数です。第2引数の値は 0〜1 の範囲で指定します。0 に近いほど元の色に近く、1 に近いほど白に近くなります。

完全に元の色を使うと背景が濃すぎて、ギャラリー内のテキストが読みにくくなります。個人的には 0.6〜0.8 で調整することが多く、デザインのテーマカラーに合わせて選ぶときれいにまとまります。Power Apps のUI設計全般については見た目と使いやすさへのこだわりも参照してみてください。

IsSelected の問題点

IsSelected で動くことを確認したら、次にその限界を把握しておきます。フォームと連動させるアプリを作ると、IsSelected では対処できない問題が必ず出てきます。

新規レコード保存後にハイライトがリセットされる

新しいレコードをフォームで追加して保存した後、ギャラリーがデータを再取得するタイミングで IsSelected がリセットされます。具体的には次の流れで問題が起きます。

ギャラリーから既存レコードを選択する
新規追加ボタンでフォームを NewMode にする
フォームを入力・保存する
ギャラリーがデータを再取得する
直前まで選択していたレコードのハイライトが消え、フォームが前の選択を表示したまま残る

IsSelected がギャラリーの表示状態に依存していて、データ再取得のタイミングでリセットされてしまうのが原因です。これはバグではなく Power Apps の仕様ですが、実用上は大きな問題になります。私が最初に作ったアプリでもこの問題にぶつかり、保存のたびにハイライトが飛ぶ挙動をユーザーに不思議がられました。

フォームの Item プロパティとの連動も不安定になる

フォームの Item プロパティに Gallery.Selected を指定している場合、IsSelected がリセットされると同時にフォームの参照先も失われます。保存直後にフォームが空になったり、前に選んでいたレコードを表示し続けたりする現象が起きます。この問題の根本的な解決策が、次の varRecord への切り替えです。

varRecord への切り替え

IsSelected の問題を解消するには、選択レコードを変数（varRecord）に保存して、TemplateFill の判定もその変数を参照するよう変更します。コンテキスト変数の使い方についてはグローバル変数とコンテキスト変数の違いと使い分けを参考にしてください。

OnSelect で varRecord に保存する

ギャラリーの OnSelect プロパティに次の数式を書きます。

UpdateContext({varRecord: ThisItem})

行をクリックするたびに varRecord にそのレコードが保存されます。UpdateContext はコンテキスト変数（画面スコープ）を更新する関数です。varRecord というのは変数名なので、任意の名前に変えて構いません。ただし、プロジェクト内で統一した命名規則を使うとコードの読みやすさが上がります。

TemplateFill を varRecord で判定する

TemplateFill の数式を次のように変更します。

If(ThisItem.ID = varRecord.ID, ColorFade(Color.Blue, 0.7), Transparent)

IsSelected の代わりに、現在の行の ID が varRecord に保存されたレコードの ID と一致するかで判定しています。varRecord の中身は、データが再取得されても変わりません。ゆえに保存後もハイライトが保持されます。SharePoint を使っている場合は ID（数値型）、Dataverse を使っている場合は GUID で比較します。

新規ボタンでハイライトを解除する

新規追加ボタンを押したとき、varRecord を空にしてハイライトをすべて解除するのが自然な挙動です。新規ボタンの OnSelect に次を追加します。

UpdateContext({varRecord: Blank()})

varRecord を Blank() にすると、ThisItem.ID = varRecord.ID がどの行でも false になるため、全行のハイライトが消えます。この制御は IsSelected ではできません。新規モードに入ったことをユーザーが視覚的に理解できる、という点でも重要な実装です。

フォームの Item も varRecord に変更する

フォームの Item プロパティを Gallery.Selected から varRecord に変更するのも忘れずに行います。

varRecord

これでフォームの参照先も varRecord になるため、データ再取得後もフォームが正しいレコードを表示し続けます。ギャラリーとフォームを変数でつなぐ全体設計については、後続の記事で詳しく解説する予定です。

IsSelected vs varRecord の比較

比較項目	IsSelected	varRecord
実装の手軽さ	数式1行のみ	OnSelect の追加が必要
データ再取得後のハイライト	リセットされる	保持される
フォームとの連動	不安定	安定
新規モードの制御	できない	Blank() で解除できる
用途	プロトタイプ・確認用	実用アプリ

現場で作るアプリのほとんどはフォームと連動するため、最初から varRecord を使うのをおすすめします。IsSelected はプロトタイプや動作確認のような限定的な場面だけで使う、と割り切るのがよいです。

まとめ

TemplateFill による行ハイライトは、IsSelected で動作を確認してから varRecord に切り替えることで実用的なアプリになります。変数の管理が一つ増えますが、フォームとの連動が安定するメリットは大きいです。

varRecord の仕組みを理解すると、ハイライト以外にもフォームの制御や新規モードの切り替えなど、さまざまな場面で応用できます。ギャラリー表示の基本についてはギャラリーのレイアウト設定もあわせて参照してみてください。地道に積み重ねていきましょう。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーのレイアウト設定｜Image・Title・Subtitle・Bodyとフィールドのカスタマイズ

Sun, 29 Mar 2026 19:06:16 GMT

ギャラリーのレイアウトは、最初に選んだだけでは使いこなせません。フィールドのバインドを自分でコントロールできるようになると、データソースのどの列でも自由に表示できるようになります。

デフォルトレイアウトの種類と使いどころ

Power Apps のギャラリーには、挿入時にいくつかのレイアウトテンプレートが用意されています。挿入直後のレイアウト選択画面で選ぶパターンが、ギャラリーの基本的な見た目を決める最初のステップです。代表的なのが次の4種類です。

レイアウト	含まれる要素	向いている用途
Image, title, and subtitle	画像・タイトル・サブタイトル	社員名簿・商品カタログなど
Title, subtitle, and body	タイトル・サブタイトル・本文	タスク一覧・お知らせ表示など
Title and subtitle	タイトル・サブタイトル	シンプルなリスト表示
Blank	なし	完全カスタム

実際の業務アプリでは Image を必要としないケースがほとんどです。社員名簿や商品カタログのように画像が必要な場合を除けば、Title, subtitle, and body のパターンで十分です。私がよく使うのもこのパターンで、タスク名・担当者・期限という3つの情報をそれぞれの行に割り当てるだけで、必要な情報がコンパクトにまとまります。

Blank レイアウトは完全カスタムが必要なときに使いますが、一から全部のコントロールを配置するため作業量が増えます。ギャラリーのコントロール配置に慣れていない方は、まず既存テンプレートから始めて後から調整する方が効率的です。ギャラリーコントロール自体の基本から確認したい方は、ギャラリーコントロールの基本と検索・選択との組み合わせも参考にしてください。

フィールドのバインドを変える方法

ギャラリーを挿入すると、Power Apps がデータソースの列を自動でひも付けします。しかしこの自動アサインが意図通りになることは少ないです。よくあるのが、Title1 に ID（数値）が入ってきて、本来表示したかった商品名や氏名が表示されない、というケースです。同じ経験をしたことがある方も多いはずです。

フィールドパネルから変更する

フィールドのバインドを変更する最も簡単な方法は、フィールドパネルを使うことです。

ギャラリーを選択した状態で右ペインのレイアウトタブを開く
Edit fields（フィールドの編集）ボタンをクリックする
各スロット（Title1・Subtitle1・Body1など）のドロップダウンで表示したい列を選ぶ

操作するとギャラリー内のラベルの Text プロパティが自動で書き換わります。たとえば Title1 の Text が ThisItem.ProductName に更新されます。フィールドパネルを使う限り、数式を手書きする必要はありません。慣れないうちはこの方法を使っておくのがよいです。

数式バーで直接変更する場合

フィールドパネル経由ではなく、数式バーに直接 ThisItem.列名を書くこともできます。条件によって表示内容を切り替えたいときや、複数の列を結合して表示したいときは数式バーでの編集が必要になります。基本的な操作に慣れてきたら、数式バーも積極的に使うようにしましょう。

ルックアップ列の表示

SharePoint のルックアップ列や Dataverse のリレーション列を表示するときは注意が必要です。単純に列名を指定しただけでは、テキストではなくオブジェクトそのものが返ってきます。ラベルに何も表示されなかったり、意味のない文字列が並んだりするのはこれが原因です。Power Apps がルックアップ列をレコード型として扱っているため、テキストとして表示するにはひと手間必要になります。

SharePoint のルックアップ列はドット記法で掘り下げる

SharePoint のルックアップ列の場合、次のようにドット記法で値を取り出します。

ThisItem.Department.Value

Department というルックアップ列から Value（表示名）を取り出す書き方です。.Value が表示名、.Id が数値IDに相当します。初めてルックアップ列を触ったとき、なぜラベルが空白になったり意味不明な文字列が出たりするのか理解できず、しばらく悩みました。.Value を付けるだけで解決するとわかってからは、すっきり使えるようになりました。

Dataverse のリレーション列

Dataverse のルックアップ列（リレーション）は SharePoint とは書き方が異なります。リレーション先のテーブル名を記述してから、表示したい列名を指定します。

ThisItem.担当者.氏名

SharePoint と Dataverse でドット記法の書き方が微妙に違うため、両方を扱う場合は混乱しやすいポイントです。Dataverse の列型の全体像を把握しておくと、こういった問題を事前に防げます。

複数フィールドの結合表示

1つのラベルに複数の列データを組み合わせて表示したいケースはよくあります。氏名と部署名を同じ行に並べたい、ステータスと更新日を1行にまとめたいという要望は、業務アプリでは頻繁に出てきます。

アンパサンドで連結する

テキストの連結には & 演算子（アンパサンド）を使います。

ThisItem.Name & " / " & ThisItem.Department.Value

氏名と部署名をスラッシュで区切って表示する例です。間に固定テキストを挟みたいときは、ダブルクォーテーションで囲んで & で繋ぎます。3つ以上の要素を繋ぐ場合も同じように & を続けるだけです。慣れてくると自然に書けるようになります。

改行を入れる

1つのラベル内で改行して2行表示したい場合は、Char(10) を挟みます。

ThisItem.Name & Char(10) & ThisItem.Department.Value

ただし、ラベルの AutoHeight プロパティをOnにしておかないと改行が表示されません。AutoHeight が Off の場合はテキストが1行に切り詰められます。改行を使う場合は AutoHeight の設定もセットで確認してください。また、ギャラリーのテンプレートサイズも適切に調整しないと表示が崩れます。

日付を文字列に変換して連結する

日付型の列をそのまま & で繋ごうとすると型エラーになります。日付は Text 関数で文字列に変換してから結合します。

ThisItem.Name & "（期限：" & Text(ThisItem.DueDate, "yyyy/mm/dd") & "）"

Text 関数の第2引数に書式文字列を指定します。日時のフォーマット指定は次の節で詳しく解説します。

数値・通貨列のText関数フォーマット

数値列や通貨列をそのまま Text プロパティに指定すると、フォーマットのない生の数字が表示されます。金額を扱うアプリなら、カンマ区切りと通貨記号を付けた方が格段に読みやすくなります。

Text(ThisItem.Price, "¥#,##0")

100000 という数値が ¥100,000 という形式で表示されます。社内の業務アプリで見積金額や在庫数を一覧表示するとき、この一手間が実際の使いやすさに大きく貢献します。数字の羅列では読み取りにくい情報が、フォーマット一つで一覧として機能し始めます。

よく使うフォーマット指定をまとめておきます。

用途	書式文字列	表示例
通貨（円）	¥#,##0	¥100,000
カンマ区切り	#,##0	100,000
小数2桁	#,##0.00	1,234.56
日付（スラッシュ）	yyyy/mm/dd	2026/03/25
日付（日本語）	yyyy年mm月dd日	2026年03月25日

Text 関数の書式指定は Excel のセル書式設定と似た記法です。Excel に慣れている方なら直感的に書けるはずです。Power Apps でデータ操作の幅を広げたい方は、Filter・Search・LookUp関数の違いと使い分けも合わせて読んでおくと、ギャラリー表示のバリエーションがさらに増えます。

まとめ

ギャラリーのレイアウト設定の核心は、フィールドのバインドをコントロールすることです。ルックアップ列のドット記法、アンパサンドによる結合、Text 関数のフォーマット指定を押さえておくと、業務アプリらしいギャラリーを自在に作れるようになります。

レイアウトが整ってきたら、次は Filter 関数を使った絞り込み表示にも挑戦してみましょう。Filter 関数の入門記事では、Dropdown との連動まで基礎から解説しています。ギャラリーをひとつひとつ磨いていく地道な作業が、使い勝手のいいアプリに繋がっていきます。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps ギャラリーで複数選択チェックボックスを実装する｜AllItems・CountRows・SelectAll

Sun, 29 Mar 2026 19:06:13 GMT

ギャラリーの複数行にチェックを入れて一括操作するUIは、Power Apps でよく求められる機能のひとつです。Gallery.AllItems プロパティを使えば、選択中のアイテムをまとめて取得できます。チェックボックスの配置から全選択・全解除まで、実装の流れを一通り解説します。

ギャラリー内にチェックボックスを配置する

まずギャラリーテンプレート内に Checkbox コントロールを追加します。配置自体はドラッグ＆ドロップで完了しますが、Default プロパティの設定が重要です。

Checkbox の Default に固定値 false を入れると、ギャラリーが再読み込みされるたびにすべてのチェックがリセットされます。これはフィルターをかけてギャラリーの表示内容が変わったときも同様です。初期状態では全行チェックなし、という挙動でよければ Default は false のままで問題ありません。

ギャラリーを選択してテンプレート編集モードに入る
Insert → Input → Checkbox を追加する
Checkbox の Default プロパティを false に設定する
Checkbox をギャラリーテンプレートの左端に配置する

Gallery.AllItems で選択済みアイテムを取得する

Gallery.AllItems は、ギャラリーに現在表示されているすべてのアイテムをテーブルとして返すプロパティです。このテーブルにはギャラリーテンプレート内の各コントロールの値も含まれます。つまり Checkbox.Value も行ごとに取得できます。

選択済みの行だけを取り出すには Filter を使います。

Filter(GalleryTasks.AllItems, Checkbox1.Value)

Checkbox1.Value が true の行だけが返ってきます。これが選択済みアイテムのテーブルです。この式をボタンの OnSelect やラベルの Text など、好きな場所で使えます。

CountRows で選択数を表示する

何件選択されているかをラベルに表示するには CountRows を組み合わせます。

CountRows(Filter(GalleryTasks.AllItems, Checkbox1.Value)) & " 件選択中"

選択数がリアルタイムで変わるので、ユーザーが今何件選んでいるかをその場で確認できます。0件のときは表示しない、という制御は後述のアクションエリアUI記事で解説します。

選択済みテーブルを別ギャラリーの Items に使う

選択済みアイテムを確認用に別のギャラリーに表示したい場合も、同じ Filter 式をそのまま Items に渡せます。

Filter(GalleryTasks.AllItems, Checkbox1.Value)

選択するたびにリアルタイムで確認ギャラリーが更新されます。承認フローや一括削除の確認画面などで重宝します。

Select All ボタンの実装

全件選択ボタンは変数を使います。Checkbox の Default に変数を設定することで、変数を true にした瞬間すべての行がチェック状態になります。

Select All ボタンの OnSelect：UpdateContext({varSelectAll: true})
Checkbox1 の Default プロパティ：varSelectAll

ただしこのままだと、ユーザーが個別のチェックボックスを操作しても varSelectAll が true のままなので、再クリックしても変化しなくなります。Select All ボタンを押した後は個別のチェック操作も有効にしたいため、Checkbox の OnCheck / OnUncheck で varSelectAll をリセットする処理を入れるか、全選択後は変数でなく Checkbox の自然な状態に委ねる設計にします。

個人的には Select All の後は変数をすぐ false に戻す方法が扱いやすいです。

// Select All ボタンの OnSelect
UpdateContext({varSelectAll: true});
UpdateContext({varSelectAll: false})

true にして即 false に戻すことで、チェックボックスの Default が一瞬 true になり全選択状態になります。その後は各チェックボックスが独立して動くようになります。

Deselect All（全解除）の実装

全チェック解除には Reset 関数を使いたくなりますが、ギャラリー内のチェックボックスに Reset 関数を直接使っても動作しません。これは Power Apps の制約です。

代わりに使うのがリセット用変数のトグルパターンです。

Deselect All ボタンの OnSelect：UpdateContext({varReset: !varReset})
Checkbox1 の Default プロパティ：If(varReset, false, false)

varReset が変化するたびに Checkbox の Default が再評価されます。結果は常に false ですが、式が再評価されることでチェックボックスがリセットされます。一見無意味に見える仕組みですが、これが Power Apps でギャラリー内チェックボックスを一括リセットする定番パターンです。そういうものだと割り切ってしまいましょう。

まとめ

Gallery.AllItems を使った複数選択の基本パターンをまとめます。

やりたいこと	実装
選択済みアイテムを取得	Filter(Gallery.AllItems, Checkbox.Value)
選択件数を表示	CountRows(Filter(…))
全選択	varSelectAll を true→false にトグル
全解除	varReset をトグルして Default を再評価

複数選択が動いたら、次は選択中のときだけアクションエリアを表示するUIを作りましょう。コンテナを使った表示切り替えの実装パターンは複数選択時のアクションエリアをコンテナで作る記事で解説します。地道な積み重ねですが、使い勝手のいいUIができあがっていきます。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps 複数選択時だけ表示されるアクションエリアをコンテナで作る

Sun, 29 Mar 2026 19:06:13 GMT

複数選択チェックボックスを実装したら、次は選択した件数が 0 のときはアクションエリアを隠し、1件以上になったら表示するUIを作りましょう。コンテナを使えば X・Y・Height の手動計算なしにレスポンシブな表示切り替えが実現できます。

Gallery.AllItems を使った複数選択の基本については複数選択チェックボックスの実装記事で解説しています。この記事はその続きとして、選択数に応じたUIの表示切り替えに特化した内容です。

VerticalContainer にギャラリーを収める

まず画面レイアウトの土台として VerticalContainer（縦方向コンテナ）を使います。ギャラリーをコンテナに入れることで、アクションエリアが展開・折りたたまれても、ギャラリーの幅が自動的にコンテナに追従します。昔は X・Y・Width を手動で計算して配置していましたが、コンテナを使えばその手間が完全になくなります。

Insert → Layout → Vertical Container を追加する
VerticalContainer の中にギャラリーを配置する
アクションエリア用の HorizontalContainer をギャラリーの上か下に追加する

VerticalContainer の Fill を設定して背景色を付けておくと、レイアウトの境界が見えて開発中の確認がしやすくなります。

アクションエリアの表示条件を設定する

アクションエリア（HorizontalContainer）の Visible プロパティに次の式を設定します。

Not(IsEmpty(Filter(GalleryTasks.AllItems, Checkbox1.Value)))

Filter(GalleryTasks.AllItems, Checkbox1.Value) でチェックが入った行のテーブルを取り出します。IsEmpty はそのテーブルが空かどうかを判定します。Not でその逆にすることで、1件以上選択されているときだけ true になります。

式を分解して読むと IsEmpty が空なら true を返すので、Not(IsEmpty(…)) は空でないとき（つまり1件以上選択中）に true になる、という意味です。慣れるまで少し読みにくいですが、パターンとして覚えてしまうと応用が利きます。

コンテナの Flexible height でアニメーションなしに消す

Visible を false にすると要素が消えますが、コンテナの場合は Visible が false になってもスペースが残ることがあります。完全に消して下のコンテンツが詰まるようにするには、コンテナの Flexible height 設定を活用します。

アクションエリアコンテナの Height プロパティに次の式を使うと、Visible が false のときに高さが 0 になります。

If(Not(IsEmpty(Filter(GalleryTasks.AllItems, Checkbox1.Value))), 60, 0)

選択中は高さ 60（ボタンが収まるサイズ）、非選択中は高さ 0 にすることで、アクションエリアが完全に消えてギャラリーが上に詰まります。Visible と Height の両方を制御するのが確実です。

アクションエリアの中身を設計する

アクションエリアには選択件数の表示と操作ボタンを配置します。HorizontalContainer を使うと横並びレイアウトが簡単に作れます。

HorizontalContainer 内にラベルを追加して選択件数を表示する
削除ボタン・承認ボタンなど操作ボタンを右側に配置する
コンテナの LayoutJustifyContent を SpaceBetween にしてラベルと右側ボタンを両端に揃える

ラベルの Text プロパティには次の式を使います。

CountRows(Filter(GalleryTasks.AllItems, Checkbox1.Value)) & " 件選択中"

コンテナを使う以前との比較

コンテナが登場する前は、アクションエリアの Y 座標をギャラリーの Y + Height で計算していました。アクションエリアの高さが変わるたびにギャラリーの Y を手動で調整する必要があり、画面のレイアウト変更が非常に大変でした。

方法	Y・高さの管理	レイアウト変更
コンテナなし（旧来）	X・Y・Height を手動計算	変更のたびに全座標を修正
VerticalContainer	コンテナが自動追従	コンテナの順序を変えるだけ

コンテナを使うと、アクションエリアを上に出すか下に出すかも、コンテナ内の順序を入れ替えるだけで変更できます。昔と比べて格段に楽になったと感じます。Power Apps のバージョンが上がるごとにこういう地味ながら実用的な改善が積み重なっているので、最新の使い方を追うのは損ではありません。

まとめ

複数選択UIのアクションエリアは、Not(IsEmpty(Filter(Gallery.AllItems, Checkbox.Value))) を Visible の条件にするだけで動きます。コンテナの Height も 0 に制御することで完全に消えて、ギャラリーが詰まるレイアウトが実現できます。

VerticalContainer と HorizontalContainer を組み合わせたレイアウト設計に慣れると、あらゆる画面デザインがすっきりまとまるようになります。X・Y の手動計算から卒業して、コンテナベースの設計に移行していきましょう。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps でギャラリーをタブUIとして使う｜レスポンシブ対応タブインターフェースの作り方

Sun, 29 Mar 2026 19:06:12 GMT

Power Apps でタブUIを作るとき、モダンコントロールのタブコンポーネントは制約が多く自由なカスタマイズが難しい場面があります。ギャラリーをタブとして使うパターンを覚えると、デザインを自由に制御しながらレスポンシブなタブインターフェースが作れます。

ギャラリーをタブとして使う発想

タブUIに必要な要素は2つです。タブバー（どのタブが選ばれているかを表示する部分）と、タブに対応したコンテンツエリアです。

ギャラリーをタブバーとして使うアイデアはシンプルです。タブの名前一覧をコレクションか Table 関数で用意して、それをギャラリーの Items に設定します。各行がタブの1項目になります。選択されたタブ名を変数に保持して、コンテンツエリアの表示を切り替えるという構成です。

モダンコントロールのタブと比べて、この方法では色・フォント・間隔・選択インジケーターのデザインをプロパティで完全にコントロールできます。社内アプリでブランドカラーに合わせたいときや、アイコン付きのタブを作りたいときに重宝します。

タブデータの準備

タブの一覧はシンプルなテーブルで用意します。アプリが起動したときに OnStart か OnVisible でコレクションを作ります。

ClearCollect(colTabs,
  {TabName: "概要",    TabIcon: "📋", Order: 1},
  {TabName: "詳細",    TabIcon: "📝", Order: 2},
  {TabName: "設定",    TabIcon: "⚙️", Order: 3}
)

TabName がタブのラベル、TabIcon が絵文字アイコン、Order が並び順です。必要に応じて列を追加できます。タブをあとから増やしたいときもコレクションに行を追加するだけで対応できます。

ギャラリーをタブバーとして設定する

水平スクロールなしの Horizontal Gallery を使います。Items に colTabs を設定して、テンプレート内にタブ名のラベルを配置します。

Insert → Gallery → Horizontal を追加する
Items プロパティに colTabs を設定する
テンプレート内のラベルの Text に ThisItem.TabName を設定する
アイコン用のラベルを追加して Text に ThisItem.TabIcon を設定する
ギャラリーの OnSelect で選択タブを変数に保存する

// ギャラリーの OnSelect
UpdateContext({varSelectedTab: ThisItem.TabName})

選択中タブのハイライト

選択されているタブを見た目で示すには TemplateFill を使います。

If(ThisItem.TabName = varSelectedTab,
  ColorFade(Color.Blue, 0.7),
  RGBA(0, 0, 0, 0)
)

varSelectedTab と一致する行だけ背景色を変える方法です。TemplateFill の使い方についてはギャラリーで選択行をハイライトする記事でも詳しく解説しています。

コンテンツエリアをタブに連動させる

タブごとに異なるコンテンツを表示するには、各コンテンツコンテナの Visible を varSelectedTab で切り替えます。

// 概要コンテナの Visible
varSelectedTab = "概要"

// 詳細コンテナの Visible
varSelectedTab = "詳細"

// 設定コンテナの Visible
varSelectedTab = "設定"

各タブのコンテンツを VerticalContainer にまとめて、その Visible を上記の式で制御します。タブが切り替わると varSelectedTab が変わり、対応するコンテナだけが表示されます。

ギャラリーをコンテナに追従させてレスポンシブ化する

タブバーのギャラリーをコンテナに追従させて、画面幅に応じて自動的にサイズが変わるレスポンシブ対応にするには、ギャラリーの Width プロパティをコンテナの幅に連動させます。

// タブバーギャラリーの Width
Parent.Width

Parent.Width は親コンテナの幅を返します。これを設定するとコンテナが広がればギャラリーも広がり、縮めばギャラリーも縮みます。各タブの幅は TemplateWidth で制御します。

// TemplateWidth（タブ1項目の幅）
Parent.Width / CountRows(colTabs)

タブの数でコンテナ幅を割ることで、タブが何項目あっても均等に並びます。タブを1つ追加してもコレクションに行を追加するだけで、幅の計算は自動で更新されます。

初期タブの設定

アプリを開いたとき varSelectedTab が空だと何も表示されないため、OnVisible か OnStart で初期値を設定します。

UpdateContext({varSelectedTab: "概要"})

画面遷移で戻ってきたときも初期タブに戻したい場合は OnVisible に書きます。画面遷移後も前のタブを保持したい場合はグローバル変数に変更します。OnStart と OnVisible の使い分けについてはOnStart と OnVisible の使い分けの記事が参考になります。

まとめ

ギャラリーをタブバーとして使うパターンの全体設計をまとめます。

要素	実装
タブデータ	ClearCollect で colTabs を作成
タブバー	Horizontal Gallery、Items に colTabs
タブ選択	OnSelect で UpdateContext({varSelectedTab: ThisItem.TabName})
ハイライト	TemplateFill で varSelectedTab と一致する行を強調
コンテンツ	各コンテナの Visible を varSelectedTab で切替
レスポンシブ	Width = Parent.Width、TemplateWidth = Parent.Width / CountRows

ギャラリーを使ったタブUIは、モダンコントロールが成熟するまでの代替手段として十分実用的です。デザインの自由度が高く、コレクションでタブを管理するため追加・削除もコードで制御できます。ぜひ自分のアプリで試してみてください。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power Apps でGallery.Selectedを使ってはいけない理由｜varRecordへの置き換え方

Sun, 29 Mar 2026 19:06:14 GMT

Gallery.Selected はギャラリーで選択したアイテムを取得できる便利なプロパティですが、実は使い続けると厄介なバグの温床になります。フォームとの連携に Gallery.Selected を使っている方は、ぜひ最後まで読んでください。

Gallery.Selected の何が問題なのか

Gallery.Selected とは、ギャラリーコントロールで現在選択されている行のレコードを返すプロパティです。フォームの Item プロパティに Gallery.Selected を設定して詳細・編集フォームと連携するのは、Power Apps を始めて間もない頃に誰もが通る道です。

ところがこの書き方には、新規追加の場面で確実にバグが出ます。新規ボタンを押してフォームを NewForm に切り替えたとき、ギャラリーの選択状態はそのまま残ります。つまり Gallery.Selected には前に選択していたレコードが入ったままです。

このとき何が起きるかというと、新しいレコードを保存してギャラリーが更新された後、フォームが新規レコードではなく前のレコードに戻ってしまいます。保存したはずのデータが画面に反映されず、ユーザーが混乱するというバグです。私自身、これに気づかず何度もテスト環境で首をひねりました。フォームとギャラリーが連動しているように見えて、実は Gallery.Selected がズレたまま動いているというのは、原因が見つかりにくいので本当に厄介です。

新規追加後に前のレコードに戻ってしまう現象

もう少し具体的に追ってみます。タスク管理アプリで、ギャラリーにタスク一覧が表示されていて、右側に EditForm を置いているとします。

一覧からタスクAを選択する → フォームにタスクAの内容が表示される
新規ボタンを押す → フォームは NewForm になるが、ギャラリーの選択はタスクAのまま
タスクBを入力して保存する → ギャラリーにタスクBが追加される
フォームは Gallery.Selected を参照しているため、ギャラリーの選択行（タスクA）に戻る
ユーザーには保存したタスクBがどこに消えたのかわからない状態になる

これが Gallery.Selected の根本的な問題です。簡単にいえば、ギャラリーの選択という不安定な状態に依存しているため、操作の順番によって結果が変わってしまうのです。

varRecord 変数への置き換え

この問題を解決するのが、コンテキスト変数 varRecord を使ったパターンです。ギャラリーの各行を選択したとき、Gallery.Selected を参照する代わりに、選択したレコードを変数に格納するという考え方です。変数に格納した瞬間の値は不変なので、後でギャラリーの選択が変わっても影響を受けません。

コンテキスト変数とグローバル変数の違いが気になる方は、Power Apps のグローバル変数とコンテキスト変数の使い分けをあわせて確認しておくとスムーズです。ここでは画面ローカルの状態管理なので UpdateContext を使います。

OnSelect に UpdateContext を追加する

ギャラリーの OnSelect プロパティに次の式を追加します。

UpdateContext({varRecord: ThisItem})

ThisItem は OnSelect のタイミングでクリックした行のレコードです。これで varRecord に選択した行のデータが格納されます。その後のフォームやラベルは Gallery.Selected ではなく varRecord を参照するように変更します。

これだけで土台は完成です。後は参照先を Gallery.Selected から varRecord に差し替えていくだけです。

フォームの Item を varRecord に変更する

EditForm の Item プロパティを Gallery.Selected から varRecord に変更します。

varRecord

これだけで、ギャラリーの選択状態に関係なく、varRecord に格納されたレコードがフォームに表示されるようになります。新規ボタンを押すときは varRecord を Blank() にリセットすれば、フォームが空になって新規入力モードとして機能します。新規ボタンの OnSelect はこのようにします。

NewForm(EditForm1);
UpdateContext({varRecord: Blank()})

Gallery.Selected を使っていたときと比べると、フォームの動作が安定します。新規追加後の保存でフォームが前のレコードに戻るという現象が起きなくなります。

TemplateFill も varRecord 連動に切り替える

選択行のハイライト表示を実装している場合、TemplateFill の式も変更が必要です。TemplateFill の基本的な仕組みについては、Power Apps ギャラリーで選択行をハイライトする記事で詳しく解説しています。

Gallery.Selected が参照されているときは、IsSelected という組み込みプロパティを使ってハイライトを切り替えているケースが多いです。しかし varRecord に切り替えた後は IsSelected への依存をゼロにするのが理想です。代わりに次の式を使います。

If(ThisItem.ID = varRecord.ID, ColorFade(Color.Blue, 0.7), RGBA(0,0,0,0))

ThisItem.ID と varRecord.ID が一致する行だけ色を変える、という考え方です。これでギャラリーの選択状態（IsSelected）ではなく、変数に何が入っているかでハイライトが制御されます。新規ボタンを押して varRecord が Blank になれば、どの行もハイライトされない状態になります。これが意図どおりの挙動です。

FontWeight の参照を Title1 に集約する

ギャラリー内のラベルで FontWeight を IsSelected に連動させていた場合、そこも書き換えが必要です。たとえばタイトルラベルの FontWeight を選択中なら Bold にするという式で組んでいると、IsSelected の参照が残ることになります。

解決策は、FontWeight の判定ロジックを Title1（ギャラリー内の先頭ラベル）に集約して、他のラベルからは Title1.FontWeight を参照させるパターンです。

コントロール	プロパティ	設定値
Title1（先頭ラベル）	FontWeight	If(ThisItem.ID = varRecord.ID, FontWeight.Bold, FontWeight.Normal)
Subtitle1・Body1 など	FontWeight	Title1.FontWeight

このように参照先を一本化しておくと、ロジックを変更するときに Title1 の1箇所だけ直せばよくなります。ギャラリーが10列・20列と増えても修正は1箇所で済む。メンテナンス性が上がるので、複雑になる前に習慣づけておくことをおすすめします。体感では、後から直すよりも最初から設計しておいたほうが圧倒的に楽です。

Gallery 全体で IsSelected の参照をゼロにする

varRecord への切り替えが完了したら、ギャラリー内のすべてのコントロールで IsSelected が参照されていないことを確認します。これが最後の仕上げです。

確認の手順はシンプルです。Power Apps Studio の検索機能（Ctrl + F）で IsSelected と入力して、ヒットする箇所を一つずつ確認します。残っている場合はすべて varRecord.ID との比較式か、Title1 への参照に置き換えます。

IsSelected が残っていると、新規ボタンを押したときに前のレコードのハイライトが残ったり、フォームとギャラリーのハイライトが食い違ったりします。一見小さな問題に見えますが、ユーザーが操作するたびに違和感が積み重なります。アプリの品質に直結するので、リリース前に必ず確認しておきましょう。

varRecord への切り替えが済んだら、次のステップとして新規作成後の保存フロー・プレースホルダーUI・OnSuccess の実装パターンについて、ギャラリーとフォームを変数でつなぐ記事で詳しく解説しています。

まとめ

Gallery.Selected は手軽ですが、新規入力フォームとの組み合わせで必ずズレが発生します。varRecord を使ったパターンに置き換えることで、ギャラリー・フォーム・ハイライトを変数ベースで一貫して制御できるようになります。

最初は手間に感じるかもしれません。でもこのパターンを覚えると、中〜大規模のアプリを作るときに迷わなくなります。Gallery.Selected のズレで何時間も悩むよりも、最初から varRecord で設計するほうが結果的に速いです。地道な一手間ですが、アプリの安定性を大きく高めてくれる変更です。楽しみながら取り組んでみてください。

ギャラリーの使い方を一覧でまとめた記事はこちらからご覧ください。

Power AppsのIfとSwitch。条件分岐の書き方と場面別の使い分け

Mon, 16 Mar 2026 15:46:48 GMT

Power AppsのIfとSwitch、どちらも条件分岐に使いますが、使い分けを理解しておくと数式がずっと読みやすくなります。一言で言えば、条件が1〜2つならIf、同じ値との比較が3つ以上続くならSwitchが向いています。

とはいえ正解は1つではなく、どちらで書いても動くことが多いです。大事なのは後から見て何をしているか理解できる数式になっているかどうかです。この記事では判断基準と書き方を整理します。

If関数の基本と使い所

If関数は、条件がtrueかfalseかで処理を分岐します。構文はシンプルです。

If(条件, trueのとき, falseのとき)

複数の条件を連鎖させることもできます（else ifに相当）。

If(
    点数 >= 90, "優",
    点数 >= 70, "良",
    点数 >= 50, "可",
    "不可"
)

最後の値はデフォルト（どの条件にも当てはまらなかった場合）です。

Ifが向いているケース

Ifは条件の内容が多様なときに使いやすいです。数値の大小比較や、複数のフィールドを組み合わせた複合条件など、値の種類に関係なく柔軟に書けます。

数値の範囲での分岐（以上・以下・範囲内）
複数フィールドの組み合わせ（AかつB、またはC）
2択のシンプルな分岐

特にColorプロパティへの適用は実務でよく使います。ステータスによって文字色を変えたいとき、こんな書き方をします。

If(
    ThisItem.ステータス = "完了", Color.Gray,
    ThisItem.ステータス = "エラー", Color.Red,
    Color.Black
)

Switch関数の基本と使い所

Switch関数は、ある1つの値が複数の候補のどれと一致するかで分岐します。

Switch(
    対象の値,
    候補1, 結果1,
    候補2, 結果2,
    候補3, 結果3,
    デフォルト
)

先ほどのステータスによる文字色変更をSwitchで書き直すとこうなります。

Switch(
    ThisItem.ステータス,
    "完了", Color.Gray,
    "エラー", Color.Red,
    Color.Black
)

比較する対象（ThisItem.ステータス）が1回しか出てこないので、Ifで書くより読みやすくなっています。候補が4つ5つと増えてきたときほどSwitchの恩恵が大きくなります。

Switchが向いているケース

同じ1つの値と複数の候補を比較する
選択肢が3つ以上ある
ドロップダウンやコンボボックスの選択値による分岐

申請フローのステータス（下書き・申請中・承認済み・却下）のような、決まった値の集合に対して処理を振り分けるケースがSwitchの典型的な使い所です。

IfとSwitchの比較まとめ

観点	If	Switch
比較の種類	任意の条件（大小・複合条件など）	1つの値と複数候補の一致確認
読みやすさ	条件が2〜3つまでなら読みやすい	同じ値の比較が3つ以上のとき読みやすい
柔軟性	どんな条件も書ける	完全一致の比較のみ（範囲比較はできない）
デフォルト値	最後の引数	最後の引数

個人的には、2択か簡単な複合条件はIf、同じ列の値で3パターン以上に分岐するときはSwitch、と使い分けています。どちらでも動くので、後から読む人が迷わない書き方を選ぶのがいちばんです。

IfsとSwitchの活用パターン

ネストしたIfは読みにくい

Ifをネストして書く（Ifの中にIfを書く）と途端に読みにくくなります。条件が増えてきたと感じたら、連鎖Ifかswitchへの切り替えを検討しましょう。

例えばこれはわかりにくいです。

If(
    条件A,
    If(条件B, "パターン1", "パターン2"),
    If(条件C, "パターン3", "パターン4")
)

こういう場合はAndやOrで条件を整理するか、変数に一旦結果を入れてロジックを分割するほうが管理しやすくなります。

変数との組み合わせでロジックを整理する

複雑な分岐は変数に結果を入れておくとすっきりします。例えばボタンのOnSelectで条件判断をして変数にセットし、その変数をColorプロパティで参照する、というパターンです。数式の責任範囲が分かれて見通しがよくなります。

変数の使い方についてはこちらも参考にしてください。

→ Power Appsのグローバル変数とコンテキスト変数——違いと使い分けを図解

また、データの絞り込みに条件を使いたい場合はFilter関数との組み合わせも重要です。

→ Power AppsのFilter・Search・LookUp関数——3つの違いと使い分けガイド

まとめ

IfとSwitchはどちらも条件分岐ですが、使い分けのポイントは条件の種類と数です。範囲比較や複合条件はIf、同じ値の完全一致で3つ以上に分岐するときはSwitchを選ぶと数式が読みやすくなります。

どちらの関数も使いこなせるようになると、アプリの色の出し分けや操作可否の制御など、UIの動きをきめ細かくコントロールできるようになります。最初は簡単なColorプロパティの変更から試してみるのがおすすめです。楽しみながら使い分けを覚えていきましょう。

Power AppsのIndex関数｜テーブルのn番目を取り出す方法

Sun, 22 Mar 2026 11:17:40 GMT

FirstやLastでは取り出せない「3番目」「5番目」の要素を取り出したいとき、Index関数を使います。Splitと組み合わせると、区切り文字で分割した文字列の任意の部分を取り出せます。

Index関数の基本

Index関数は、テーブルから指定した行番号のレコードを返します。引数は2つです。

Index(テーブル, 行番号)

行番号は1始まりです。テーブルの1行目を取り出すIndex(テーブル, 1)はFirst(テーブル)と同じ結果になります。

Index(["A","B","C","D"], 3).Value
// 結果：C

Firstは先頭行、Lastは末尾行しか取れませんが、Indexは行番号を指定できるため、中間の任意の要素を取り出せます。

Splitと組み合わせる

Splitで文字列をテーブルに変換してからIndexで要素を取り出すパターンは、区切り文字で区切られたデータを扱うときに特に役立ちます。

// "東京/大阪/名古屋/福岡" の3番目を取り出す
Index(Split("東京/大阪/名古屋/福岡", "/"), 3).Value
// 結果：名古屋

SplitはValueという1列のテーブルを返すため、Indexの後に .Value をつけて文字列として取り出します。Split・First・Lastの使い方についてはこちらの記事をご覧ください。

実例3パターン

コレクションのn番目を取り出す

ボタンを押すたびに次の項目を表示するスライドショー的なUIで、現在のインデックスを変数で持ちながらIndexで表示内容を切り替えます。

// 変数 varIndex を 1 で初期化しておく
// 「次へ」ボタンのOnSelect
Set(varIndex, varIndex + 1);

// ラベルのText
Index(colSlides, varIndex).Title

コレクションの使い方についてはこちらの記事で詳しく解説しています。

SharePointリストの特定行を参照する

SharePointリストの先頭から数えてn行目のデータを取り出したい場面です。GalleryのSelectedを使わずにIndex指定でレコードを取り出せます。

Index(
    SortByColumns(社員リスト, "社員番号", Ascending),
    varTargetRow
)

ただし、SharePointリストにIndexを直接かけると委任の警告が出る場合があります。データ量が多い場合はCollectでコレクションに取り込んでからIndexを使うほうが安全です。委任についてはこちらの記事を参照してください。

ギャラリーで選択せずにn番目の行を操作する

ギャラリーを使わず、プログラムで特定行のデータを取得・編集したいケースです。たとえば「最新の申請を自動で選択状態にする」処理でIndexが活用できます。

// 日付降順でソートした先頭行を変数に格納
Set(
    varLatestRecord,
    First(SortByColumns(申請リスト, "申請日", Descending))
)

このケースではFirstで対応できますが、「最新から2番目」を取りたい場合はIndex(SortByColumns(…), 2)という書き方になります。

IndexとFirst・Lastの使い分け

関数	取り出す位置	行番号の指定
First	先頭行のみ	不要
Last	末尾行のみ	不要
Index	任意のn番目	必要（数値または変数）

単純に先頭・末尾を取るならFirst・Last、動的に位置を変えたい場合はIndexを使います。

まとめ

Index関数は、FirstとLastだけでは対応できない「n番目」を取り出す関数です。Splitと組み合わせてn番目の文字列を取り出す、コレクションをスライドショー的に操作する、といった場面で便利に使えます。

ギャラリーのSelected（選択行）を使う方法と比べて、Indexはプログラム側で行を制御できるのが強みです。ギャラリーの使い方はこちらの記事で解説しています。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

使い始めると、データ操作の幅が一気に広がります。ぜひ活用してみてください。

Power Appsで先頭・末尾から固定文字数を取り出す｜LeftとRightの使い方

Sun, 22 Mar 2026 11:17:32 GMT

請求番号の末尾4桁、郵便番号の前3桁など、文字の位置が固定されているデータを切り出すときはLeftとRightが最もシンプルな選択肢です。引数が少なく、数式を短く書けるのが利点です。

Left：先頭からn文字を取り出す

Left関数は文字列の先頭から指定した文字数を返します。引数は2つです。

Left(テキスト, 文字数)

Left("ABCDE", 3)
// 結果：ABC

たとえばカテゴリコードが先頭2文字で固定されているコードから、カテゴリ部分だけを取り出すときに使います。

Left("TK2024001", 2)
// 結果：TK

Right：末尾からn文字を取り出す

Right関数は文字列の末尾から指定した文字数を返します。構造はLeftと同じです。

Right(テキスト, 文字数)

Right("請求書-2024-0042", 4)
// 結果：0042

請求番号の末尾4桁を取り出して管理番号として使う、といった場面がよくあります。Left・Rightは固定長のデータに強く、ハードコードでも壊れにくいのが特長です。

実例3パターン

カテゴリコードで絞り込む

商品コードの先頭2文字がカテゴリを表す場合、Leftで取り出した値でFilterをかけられます。

Filter(
    商品リスト,
    Left(商品コード, 2) = "TK"
)

FilterやLookUpの詳しい使い方はこちらの記事をご覧ください。

入力値のバリデーションに使う

郵便番号入力フォームで、先頭3文字が数字かどうかを確認するバリデーションです。LenとLeftを組み合わせて桁数チェックも同時に行えます。

If(
    Len(TextInput_PostalCode.Text) >= 3 &&
    IsNumeric(Left(TextInput_PostalCode.Text, 3)),
    "OK",
    "先頭3桁は数字を入力してください"
)

Ifの使い方はPower AppsのIfとSwitchでまとめています。

Patchで保存する前にコードを整形する

入力されたコードの先頭2文字を部署コードとして別の列に保存する場面です。Patchと組み合わせてSharePointリストに書き込めます。

Patch(
    申請リスト,
    Defaults(申請リスト),
    {
        申請番号: TextInput_AppNo.Text,
        部署コード: Left(TextInput_AppNo.Text, 2),
        連番: Right(TextInput_AppNo.Text, 4)
    }
)

Patchの使い方についてはPatch関数の使い方で解説しています。SharePointリストの操作についてはSharePointリストのCRUDパターンもあわせてご覧ください。

MidやFindとの使い分け

Left・Rightは文字の位置が固定されているときに使います。位置が変わりうる場合や、区切り文字を基準に切り出す場合はMidとFindを使います。

関数	向いているケース	位置の指定方法
Left	先頭からn文字が固定されているコード	文字数をハードコード
Right	末尾からn文字が固定されているコード	文字数をハードコード
Mid＋Find	区切り文字の間にある可変長の文字列	Findで位置を動的取得

Mid・Findの組み合わせについてはこちらの記事をごらんください。

まとめ

Left・Rightはシンプルさが最大の強みです。固定長のコードや番号を扱うときは迷わずLeft・Rightを選んでください。数式が短く、読みやすいアプリになります。

文字数が変わる可能性があるデータや、文字列全体の長さに応じて切り出し範囲を変えたい場合は、Len関数と組み合わせることで対応できます。Lenの使い方はこちらの記事をご覧ください。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

地味な関数ですが、データ整形の現場では頻繁に使います。ぜひ手に馴染ませてみてください。

Power AppsのLen関数｜文字数カウントは単独では使わない、数式の部品としての使い方

Sun, 22 Mar 2026 11:17:48 GMT

Len関数は文字数を返すだけのシンプルな関数ですが、単独で使うケースはほとんどありません。IfやMid・Rightと組み合わせて初めて役立つ、数式の部品として使う関数です。

Lenの基本

Len関数は1つの引数を受け取り、その文字列の文字数を数値で返します。

Len("Power Apps")
// 結果：10

Len("")
// 結果：0

スペースも1文字としてカウントされます。全角文字も半角文字も同じく1文字です。

Lenを使う3つのパターン

入力バリデーション：文字数上限チェック

フォームの入力欄に文字数制限を設けて、超過したときにメッセージを出す定番パターンです。

If(
    Len(TextInput_Memo.Text) > 200,
    "200文字以内で入力してください",
    ""
)

ラベルのTextにこの数式を入れておけば、200文字を超えた瞬間に警告を表示できます。送信ボタンの活性制御にも応用できます。

// 送信ボタンのDisplayMode
If(Len(TextInput_Memo.Text) <= 200, DisplayMode.Edit, DisplayMode.Disabled)

Ifの使い方はこちらの記事で詳しく解説しています。

残り文字数を表示する

SNSの入力欄のように「残り○文字」をリアルタイムで表示するUIです。

$"残り {200 - Len(TextInput_Memo.Text)} 文字"

文字列補間と組み合わせるとシンプルに書けます。文字列補間の使い方はこちらの記事を参照してください。

MidやRightと組み合わせて末尾から動的に切り出す

Rightは末尾からn文字を取り出しますが、文字列全体の長さに応じて切り出し範囲を変えたいときはLenと組み合わせます。たとえば最初のスラッシュより後ろをすべて取り出したい場合です。

With(
    { slashPos: Find("/", TextInput_Path.Text) },
    Right(
        TextInput_Path.Text,
        Len(TextInput_Path.Text) - slashPos
    )
)

Len(全体の文字数) から Find(区切り文字の位置) を引くことで、末尾から取り出すべき文字数を動的に算出します。Left・Rightの詳しい使い方はこちらの記事で解説しています。

SharePointの文字数制限との関係

SharePointのテキスト列（1行テキスト）はデフォルトで255文字の上限があります。Power Appsのフォームからそのまま入力すると、255文字を超えた場合にPatchがエラーになることがあります。Lenを使ったバリデーションを入れておくことで、保存前に弾けます。

If(
    Len(TextInput_Title.Text) > 255,
    Notify("タイトルは255文字以内にしてください", NotificationType.Error),
    Patch(申請リスト, Defaults(申請リスト), { タイトル: TextInput_Title.Text })
)

委任の警告やSharePointのデータ制限についてはこちらの記事も合わせてご覧ください。

Lenは単独では使わない

あらためて整理すると、Lenを単体でラベルに表示する用途はほぼありません。常にIf・Mid・Right・Findなどと組み合わせて、文字数を条件や計算の材料として使います。逆に言えば、IfやMidの中に数値が必要な場面で「文字数から計算できないか」と考えたとき、Lenを思い出せばいいのです。

まとめ

Lenの使いどころは3つです。入力バリデーション（文字数制限チェック）、残り文字数の表示、そしてMidやRightと組み合わせた動的な切り出しです。いずれも他の関数と組み合わせて初めて機能します。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

地味ですが確実に使う場面が来る関数です。引き出しのひとつとして覚えておきましょう。

Power Appsのライセンスをわかりやすく解説。無料でどこまで使える？有料プランとの違い

Mon, 16 Mar 2026 15:46:47 GMT

Power Appsのライセンスは正直わかりにくいです。ただ、整理してみると実務上の選択肢は3パターンにまとまります。無料で使えるのかどうか、有料にするとどう変わるのか、この記事でまとめます。

私も最初は社内にPower Appsを広めようとしたとき、ライセンス周りで何度も調べ直しました。上司に聞かれてもうまく説明できなかった経験があるので、できるだけ平易にまとめておきます。

Power Appsには3種類の使い方がある

まず大きく3パターンに分けて理解するとスッキリします。

パターン	ライセンス	使える範囲	費用
①	Microsoft 365 込み	StandardコネクタのみのSharePoint・Teamsアプリ	Microsoft 365に含まれる
②	Power Apps Premium（旧Per App）	Premium含む。ただし1アプリ1ユーザー単位	有料（アプリ×ユーザー数）
③	Power Apps Per User	Premium含む。無制限でアプリ作成・利用可	有料（ユーザー単位）

パターン①は多くの会社で既に持っているMicrosoft 365に含まれているので、追加費用なしで使えます。ただしPremiumコネクタ（Dataverseやサードパーティサービスとの連携）は使えません。

Microsoft 365込みで何ができるか

Microsoft 365（旧Office 365）のE1・E3・E5などには、Power Appsが含まれています。SharePointリストやExcelをデータソースにしたアプリなら、追加ライセンスなしで作れます。

社内申請アプリや日報アプリ、在庫管理など、SharePointリストと組み合わせる用途なら十分なことが多いです。私が社内で最初に作ったアプリはすべてこのライセンス範囲でした。

Premiumコネクタが必要になるのはどんなとき？

Dataverseをデータソースにしたい場合や、SAP・Salesforceといった外部システムと連携したい場合はPremiumコネクタが必要です。このとき、アプリを使うユーザー全員にPremiumライセンスが必要になります。

開発者だけが有料ライセンスを持てばいいわけではありません。アプリを使う社員が20人いれば、20人分のライセンス費用がかかります。これを把握せずにアプリを設計すると、後から予算の問題が発生します。

Developer Planで無料開発・検証できる

個人で学習・開発するだけなら、Power Apps Developer Planが使えます。個人のMicrosoftアカウント（職場または学校アカウント）に無料で追加でき、Dataverseを含む本番同等の機能を試せます。

ただしDeveloper Planで作ったアプリは他のユーザーに共有して使わせることができません。あくまで個人開発・検証用です。私は新しい機能を試すときに自分のDeveloper Plan環境を使って実験してから、社内の本番環境に展開するようにしています。

ライセンス計画でよくある失敗パターン

失敗①：開発者だけ有料ライセンスを持てば使えると思っていた

前述のとおり、Premiumコネクタを使うアプリはユーザー全員にライセンスが必要です。20人が使う申請アプリをDataverseで作ると、20ユーザー分のPer Userライセンスが必要になります。これを計算に入れないと予算オーバーになります。

失敗②：SharePointで代替できることをわかっていなかった

Dataverseを使いたくなる場面でも、SharePointリストで十分なケースは多いです。Dataverseが必要なのは、複数のリレーションを持つ複雑なデータモデルや、大量レコードを扱うケースが主です。SharePointで収まるならMicrosoft 365ライセンスだけで解決するので、まずSharePointで検討することをおすすめします。

失敗③：Per AppとPer Userのどちらが安いか試算していなかった

1人が複数のアプリを使う場合はPer User（ユーザー単位）のほうが割安になります。逆に1つのアプリを少人数だけが使う場合はPer App（アプリ単位）が安いこともあります。ユーザー数とアプリ数で試算してから選びましょう。

2024年以降のライセンス変更点

Microsoftはライセンス体系を定期的に改定します。2024年時点ではPer Appプランが廃止され、Pay-as-you-go（従量課金）やPremiumライセンスへの統合が進んでいます。Microsoft公式のライセンスガイドを必ず確認してから社内提案してください。

ライセンスの最新情報はMicrosoftの公式ドキュメントが一次情報です。ブログ記事の情報は古くなっていることがあるので、金額や条件は必ず公式で確認することをおすすめします。

Power Appsをどんな用途で使うかが固まったら、全体の開発マップを見ながらアプリ設計に進みましょう。

→ Power Apps開発の全体マップ——基礎・データ操作・関数・UI設計の完全ガイド

まとめ

Power Appsのライセンスは、Microsoft 365込み・Per App（Premium）・Per Userの3パターンで整理できます。SharePointリストベースのアプリなら追加費用なしで始められます。Premiumコネクタを使う場合はユーザー全員分のライセンスが必要になるため、アプリ設計前にライセンスコストを試算しておくことが大切です。

ライセンスの話は地味ですが、社内でPower Appsを広げるときに必ず壁になります。最初に把握しておくと、後から慌てずに済みます。

Power Appsで区切り文字を基準に文字列を動的に切り出す｜MidとFindの使い方

Sun, 22 Mar 2026 11:17:34 GMT

「TK-2024-001」というコードから「2024」だけ取り出したい。そんなとき、FindとMidを組み合わせると動的に切り出せます。文字の位置がデータによって変わっても壊れないのが強みです。

Findで文字の位置を調べる

Find関数は、文字列の中から指定した文字列が最初に現れる位置を返します。位置は1始まりです。

Find("-", "TK-2024-001")
// 結果：3（3文字目に最初の"-"がある）

第3引数に開始位置を指定すると、その位置以降で検索できます。

Find("-", "TK-2024-001", 4)
// 結果：8（4文字目以降で検索し、8文字目に2つ目の"-"がある）

Findは文字が見つからない場合にBlankを返します。条件分岐に使う場合はIsBlankで確認しておくと安全です。

Midで指定位置から文字列を切り出す

Mid関数は、文字列の特定の位置から指定した文字数を取り出します。引数は3つです。

Mid(テキスト, 開始位置, 文字数)

たとえば「TK-2024-001」の4文字目から4文字取り出すには次のように書きます。

Mid("TK-2024-001", 4, 4)
// 結果：2024

ただし位置をハードコードすると、コードの形式が変わった瞬間に壊れます。Findと組み合わせることで、データが変わっても動作する数式になります。

FindとMidを組み合わせる

FindとMidを組み合わせると、区切り文字の位置を動的に取得しながら切り出せます。「TK-2024-001」の最初のハイフンと2番目のハイフンの間にある「2024」を取り出す例です。

With(
    {
        pos1: Find("-", "TK-2024-001"),
        pos2: Find("-", "TK-2024-001", Find("-", "TK-2024-001") + 1)
    },
    Mid("TK-2024-001", pos1 + 1, pos2 - pos1 - 1)
)

Withで位置を変数的に持つことで、同じFind計算を何度も書かずに済みます。Withの使い方はこちらの記事で詳しく解説しています。

実例3パターン

管理番号から年度を抽出する

「部署コード-年度-連番」形式の管理番号から年度部分だけ取り出し、ギャラリーのフィルタに使う例です。

Filter(
    申請リスト,
    With(
        { pos1: Find("-", 管理番号) },
        Mid(管理番号, pos1 + 1, 4)
    ) = "2024"
)

FilterやLookUpの使い方はこちらの記事でまとめています。

メールアドレスのドメインを取り出す

メールアドレスから@以降のドメイン部分を取得する場面です。

With(
    { atPos: Find("@", TextInput_Email.Text) },
    Mid(TextInput_Email.Text, atPos + 1, Len(TextInput_Email.Text) - atPos)
)

Len関数を組み合わせることで、文字列の末尾まで取り出せます。

SharePointリストのコードを照合する

SharePointリストに登録されたコードの一部を切り出し、別のリストと照合するパターンです。たとえば品番コードの先頭3文字がカテゴリを表す場合、Midで取り出した値でFilterをかけられます。

Filter(
    カテゴリマスタ,
    カテゴリコード = Left(ThisItem.品番, 3)
)

SharePointのデータ操作についてはSharePointリストのCRUDパターンも参考にしてください。

ReplaceとSubstituteとの使い分け

MidとFindは切り出しに特化した関数です。文字列を別の文字に置き換えたい場合は、ReplaceやSubstituteを使います。Replaceは位置指定での置換、Substituteは文字列を検索して置換です。これらの使い分けについてはこちらの記事をご覧ください。

まとめ

FindとMidは単体でも使えますが、組み合わせることで真価を発揮します。Findで位置を動的に取得してからMidで切り出すという流れを覚えておけば、どんな区切り文字にも対応できます。

Left・Right関数は位置が先頭・末尾に固定されているケース向けの切り出し関数です。固定位置ならLeft・Right、動的な位置ならMid・Findと使い分けてください。Left・Rightの使い方はこちらの記事をご覧ください。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

少し複雑に見えますが、Withと組み合わせれば整理できます。ぜひ実際のデータで試してみてください。

Power Apps 監視（モニター）機能とは？データ取得や接続エラーをリアルタイムで特定する方法

Sat, 18 Apr 2026 08:45:33 GMT

ラベルデバッグで原因が掴めないとき、次に使うのが監視（モニター）機能です。データソースへのリクエストとレスポンスをリアルタイムで確認できるので、接続エラーやPatchの失敗原因を素早く特定できます。

この記事はエラー・デバッグクラスターのサテライト記事です。ラベルを使った基本的なデバッグ手法はPower Apps 式が動かないときの調べ方で解説しています。

監視（モニター）機能とは何か

監視（モニター）はPower Apps Studioに内蔵されたデバッグツールです。アプリが動いている間、データソースへのHTTPリクエストとレスポンスをリアルタイムでログに記録し続けます。どのコントロールがどのデータを取りに行ったか、Patchがどんなデータを送ったか、エラーが返ってきたときのステータスコードとメッセージ、これらすべてを一覧で確認できます。

Webブラウザの開発者ツール（DevTools）のネットワークタブに近いものだと思ってもらうと分かりやすいです。ただし監視（モニター）はPower Apps専用なので、SharePointやDataverseへのリクエストが見やすい形で整理されて表示されます。

私が監視（モニター）を使い始めたきっかけは、Patchが失敗しているのにエラーメッセージが画面に出ないケースでした。ラベルデバッグで変数の値を確認しても問題は見当たらず、でもデータが保存されない。監視（モニター）を開いてPatchのログを見たら、SharePointのある列の型が違うというメッセージがレスポンスに含まれていました。あの瞬間から、デバッグの考え方が変わりました。

監視（モニター）の起動方法

Power Apps Studioから起動する

Power Apps Studioでアプリを開く
上部メニューの詳細設定をクリック
ドロップダウンからモニターを選択
別タブで監視（モニター）画面が開く
監視（モニター）画面でアプリのモニターボタンをクリック
別ウィンドウでアプリのプレビューが起動する

アプリのプレビューウィンドウで操作すると、そのたびに監視（モニター）画面にログが積み上がります。エラーが起きる操作（ボタンを押す、データを保存するなど）を再現すると、その操作に関するログが赤くハイライトされます。

監視（モニター）画面の見方

ログ一覧の列の意味

監視（モニター）画面のログ一覧には複数の列があります。それぞれの意味を把握しておくと、問題のある行を素早く見つけられます。

列名	内容	確認ポイント
時刻	リクエストが発生した時刻	操作のタイミングと照合する
操作	発生したイベントの種類（GetItems、Patch等）	どのデータ操作か確認する
コントロール	操作を発生させたコントロール名	どのコントロールが原因か特定する
プロパティ	該当するプロパティ（Items、OnSelectなど）	どのプロパティに書いた式か確認する
結果	成功 / エラー	赤字の行がエラー
状態コード	HTTPステータスコード（200、403、404等）	エラーの種類を大まかに判断する

エラー行をクリックすると右ペインに詳細が表示されます。リクエストに送ったデータと、サーバーから返ってきたレスポンスの両方が確認できます。

HTTPステータスコードで原因の大枠を掴む

状態コード（HTTPステータスコード）の数字を見るだけで、エラーの種類を大まかに絞り込めます。

ステータスコード	意味	よくある原因
200	成功	エラーではない
400	リクエストが不正	送ったデータの型・形式が間違っている
403	アクセス権限なし	そのSharePointサイト・リストへの権限がない
404	リソースが見つからない	リスト名・サイトURLが間違っている
429	リクエスト過多	短時間に大量のリクエストを送った（スロットリング）
500	サーバーエラー	SharePoint側・Dataverse側の問題

監視（モニター）の使いどころ3パターン

パターン1：ギャラリーにデータが出ないとき

ギャラリーが空表示になっているとき、監視（モニター）を開いてアプリを起動すると、データ取得（GetItems）のログが表示されます。このログの結果列を見ることで、データソースへのアクセス自体が失敗しているのか、データが0件で返ってきているのかを区別できます。

監視（モニター）を起動してアプリのプレビューを開く
ギャラリーが表示されたタイミングでGetItemsのログを確認する
結果がエラー→ステータスコードで原因を特定する
結果が成功でも0件→Filter条件を見直す

結果が成功でも件数が0の場合は、データソース自体は繋がっているのでFilter条件の問題です。数式エラー解決の全体マップのデバッグ手順と組み合わせて、Filter式を段階的に確認していきます。

パターン2：Patchが失敗しているとき

ボタンを押しても保存されない、エラーメッセージも出ない、そういうときは監視（モニター）でPatchのログを確認します。Patchが発生したタイミングのログを開くと、送信したデータの内容とサーバーの応答が両方確認できます。

Patchログの右ペイン要求タブに送ったデータが表示されます。列名・値・型が意図通りになっているかを確認してください。応答タブにはSharePointやDataverseが返したエラーメッセージが含まれており、この列の型が不正です、この列は必須ですといった具体的な情報が得られます。

パターン3：パフォーマンスが遅いとき

アプリの動作が遅いとき、監視（モニター）で各リクエストの所要時間を確認できます。特定のGetItemsに時間がかかっている場合、委任が効いていない（アプリ側で全件取得してから絞り込んでいる）可能性があります。

ログの期間列（ミリ秒）を見て、1秒を超えているリクエストがあれば改善の余地があります。Power Appsが重いときの改善方法の記事と組み合わせて対処してください。

ラベルデバッグと監視（モニター）の使い分け

2つのデバッグ手法をどう使い分けるかは、問題の場所によって決まります。

問題の場所	使うべきツール	理由
変数の中身が正しいか	ラベルデバッグ	データソースに関係ない式の確認はラベルが速い
Filter条件で件数が合っているか	ラベルデバッグ（CountRows）	式の結果をそのまま表示できる
データソースへの接続が成功しているか	監視（モニター）	HTTPレベルの結果が必要
Patchの書き込みが失敗している	監視（モニター）	送信データとサーバー応答の両方が必要
アプリが遅い原因を調べる	監視（モニター）	リクエスト単位の所要時間が分かる

簡単にいうと、式の中の問題はラベル、データソースとの通信の問題は監視（モニター）です。ラベルデバッグで原因が見つからないときにMonitorを開く、という順番が実務的には効率的です。

まとめ

監視（モニター）は最初こそとっつきにくく感じますが、使い方を覚えると、データが来ない、保存されない系の問題が格段に速く解決できます。ステータスコードと右ペインのメッセージを読む習慣をつけるだけで、原因不明のまま延々と試行錯誤する時間がなくなります。

デバッグツールを使いこなすことは、開発の腕前を上げることと同じくらい大切です。ラベルデバッグと監視（モニター）の2つを組み合わせて、問題を素早く特定できるようになりましょう。

Power Apps 名前付き計算式（App.Formulas）とは｜変数との違いと使いどころを解説

Tue, 24 Mar 2026 22:49:25 GMT

OnStartに変数を並べているなら、名前付き計算式の導入で起動時間を短縮できます。変数と異なり、必要な瞬間にだけ計算されるため、アプリの応答性が向上します。

設定場所：アプリレベルでFormulaプロパティを開く

名前付き計算式を定義するには、ツリービューでアプリそのものを選択した状態で、右側のプロパティパネルの Formulas プロパティ（日本語UIでは「計算式」）を開きます。ここにコードを入力することで、アプリ全体で参照できる計算式が誕生するわけです。

変数一覧パネルには表示されないので、名前でしっかり識別することが重要になります。nfプレフィックスを使うと、どの値が名前付き計算式なのか一目瞭然です。

基本の書き方：イコール＆セミコロン

最もシンプルな書き方は次の通りです。

nfUser = User();

イコール記号の右辺に値を返す式を書き、末尾に必ずセミコロンを付けます。これが命名規則です。変数を定義する Set 関数との構文は大きく異なるので注意しましょう。

Set 関数と比べると、Set は「Set(varName, value)」という順序ですが、名前付き計算式は「nfName = value;」という逆の向きになります。初めての人は戸惑いやすいポイントです。

変数との違い①：Immutable（変更不可）

名前付き計算式は、一度定義されたら後から書き換えることはできません。つまり、変更不可能な属性を持つということです。その代わり、コード内でうっかり上書きされるリスクがなくなります。

変数（Set関数で定義）は、何度でも Update Select ボタンのOnSelectなど、イベントハンドラー内で書き換えられます。一方、名前付き計算式はアプリ起動時に一度だけ評価され、その値は保証されます。

ボタンの OnSelect プロパティで nfUser を書き換えようとすると、エラーが返ります。この挙動を理解することが、設計を大きく変える第一歩になります。

変数との違い②：遅延評価

OnStart では、アプリ起動時にすべての処理がブロッキング実行されます。つまり、OnStart 内の処理がすべて終わるまで、ユーザーは待つしかありません。読み込む件数が多ければ多いほど、起動画面は長く表示されたままになります。

一方、名前付き計算式は必要な瞬間に計算されます。例えば、画面Aで nfUser が参照されるタイミングで初めて User() 関数が実行されるということです。すべての計算式を起動時に完了させる必要がないので、アプリ全体の応答性が改善されるわけです。

ただし、計算式の定義自体は起動時に構文チェックされます。構文エラーがあれば、起動時に検出されます。

命名規則：nfプレフィックスで識別性を高める

変数一覧パネルには表示されない名前付き計算式だからこそ、命名規則が重要です。nf（named formula）というプレフィックスを付けることで、コード内でその値が計算式であることを即座に判断できます。

例えば nfUser、nfDepartments、nfThemeColor といった具合です。ほかの開発者がコードを見たときも、プレフィックスを見るだけで「これは名前付き計算式だ」と理解できるため、チームでの開発時にも有効です。

典型的な用途：4つのパターン

名前付き計算式が活躍する場面は、主に4つに絞られます。

まず、ユーザー情報キャッシュです。User() 関数の結果を nfUser として定義しておけば、OnStart でブロッキングされることなく、必要なコントロールで User().FullName などとアクセスするより効率的になります。

次に、テーマカラー定数です。ColorValue(“mediumaquamarine”) といった色指定を一箇所で管理し、アプリ全体で共通の nfPrimaryColor などを参照することで、デザイン変更時の修正箇所が1つで済みます。

3番目は、変わらないリストです。例えば、都道府県リストやステータス選択肢を Table({Value:“北海道”},{Value:“青森県”},…) のように定義しておけば、複数の Combobox コントロールで共有できます。OnStart で ClearCollect を実行するより、起動速度が向上します。

最後に、フィルター済みサブセットです。nfExecutives = Filter(Employees, Department = “Executives”) のように、特定条件でフィルタリングしたテーブルを先に計算しておくことで、ギャラリーやコンテナの Items プロパティを単純に保てます。

OnStartを完全に置き換えるものではない：使い分けの実際

名前付き計算式は便利ですが、すべてのケースで OnStart を置き換えられるわけではありません。2つの例外があります。

まず、深リンク処理です。アプリが特定の引数付きURLで起動された際、その引数を抽出して変数に設定する必要がある場合、OnStart のブロッキング実行が有効になります。遅延評価では、引数の確認が遅れるため、画面遷移ロジックが複雑になりがちです。

次に、確定させる必要がある値です。例えば、現在のユーザーが持つ権限フラグを計算して、その結果に基づいて特定の画面を表示・非表示にする場合、起動時に確定していることが重要になります。遅延評価だと、計算結果が変わるタイミングで画面の表示状態が揺らぐリスクがあります。

つまり、起動速度を優先したい値は名前付き計算式に、初期状態の確定が必要な値は OnStart に、という使い分けが理想的です。

まとめ

名前付き計算式は、immutable かつ遅延評価される計算式です。OnStart に並べた変数をそのまま移行することで、アプリの起動体感を大きく改善できます。ユーザー情報、テーマカラー、選択肢リスト、フィルター結果といった「一度取得したら変わらない値」の管理に最適です。

OnStart をすべて置き換えることはできませんが、小さな改善の積み重ねが起動速度を左右します。次のステップとして、自分のアプリで OnStart に書かれている処理を見直し、どの値が名前付き計算式の候補になるかを検討してみてください。

関連記事：Power Appsパフォーマンス改善まとめ → Power Appsパフォーマンス改善まとめ

関連記事：名前付き計算式の書き方チートシート → 名前付き計算式の書き方チートシート

Power Apps 名前付き計算式の書き方チートシート｜型別・用途別の構文まとめ

Tue, 24 Mar 2026 22:49:26 GMT

Formulasプロパティの書き方を型別にまとめました。基本ルールさえ押さえれば、変数（Set関数）から名前付き計算式への移行は簡単です。

共通ルール：覚えるべき4つのポイント

すべての名前付き計算式に共通するルールは4つです。まず、等号の右辺に値を返す式を書きます。左辺は計算式の名前、右辺はその値です。次に、末尾にセミコロンを必ず付けます。これを忘れるとエラーになります。

3番目として、Set関数や Collect関数、ClearCollect関数は使いません。名前付き計算式内では、読み取り専用の計算をしか実行できないということです。4番目に、変数一覧パネルには表示されません。コード内でしか参照できないため、nfプレフィックスで識別することが重要です。

レコード型：ユーザー情報やAPIレスポンス

User関数の結果は1つのレコードです。そのレコードを名前付き計算式に格納する場合の書き方です。

nfUser = User();

こうすることで、アプリ全体で nfUser.FullName や nfUser.Email といったプロパティにアクセスできます。Set関数を使う場合は、Set(varUser, User()) と書きますが、イコール記号の向きが逆になることに注意してください。

Setの場合は関数名が最初に来ますが、名前付き計算式は変数名が最初に来ます。アプリ開発で一番よく使う書き方なので、早めに慣れることをお勧めします。

テーブル型①：データソースをキャッシュする

SharePointリストやDataverseテーブルを、OnStartのClearCollectではなく名前付き計算式で管理する書き方です。

nfDepartments = Departments;

Departments がデータソース名だとすると、この1行で nfDepartments にそのテーブル全体がキャッシュされます。ギャラリーの Items プロパティに、そのまま nfDepartments を指定できます。OnStartでClearCollectを実行するより、起動速度が向上します。

ただし、データソース自体に対する検索やフィルタリングは、その都度Dataverseに問い合わせされます。データ更新の有無を確認したいなら、Refresh関数を別途呼び出す必要があります。

テーブル型②：手動テーブルを定義する

固定値のテーブルを定義する場合は、Table関数を使います。

nfChoices = Table({Value:"はい"},{Value:"いいえ"},{Value:"どちらでもない"});

Set関数ではなく、Table関数を使うことが重要です。Collect関数や ClearCollect関数は、名前付き計算式の中では使えません。Comboboxやドロップダウンの Items プロパティに nfChoices をそのまま指定すると、選択肢リストが表示されます。

複数の画面で同じ選択肢を使う場合、この手法でテーブルを一元管理することで、メンテナンスが楽になります。選択肢が増えた場合も、1箇所の修正で全画面に反映されます。

色・定数：デザイン要素を統一管理

テーマカラーや数値定数を定義する書き方です。

nfColor = ColorValue("mediumaquamarine");
nfMaxRetries = 3;
nfCheckInterval = 500;

ColorValue関数で色を定義して、複数のコントロールの Fill プロパティに nfColor を指定すれば、デザイン変更時は定義箇所を修正するだけで済みます。数値定数も同様に、計算式内で繰り返し使う値をあらかじめ定義しておくと、コードの可読性が高まります。

この手法は、デザイン・システムの構築に有効です。ブランド色、フォントサイズ、マージン幅といったデザイン値を一箇所に集約することで、アプリ全体のビジュアル統一が実現します。

フィルター結果のテーブル：条件付きデータセット

特定条件でフィルタリングしたテーブルを名前付き計算式で定義する書き方です。

nfExecutives = Filter(Employees, Department = "Executives");

Filter関数を使って、Employees テーブルから Department が「Executives」の行だけを抽出します。結果は nfExecutives に格納され、ギャラリーの Items プロパティに直接指定できます。OnStartで ClearCollect(varExecutives, …) を実行するより、遅延評価のメリットが活きてきます。

複数の条件でフィルタリングしたいなら、Filter関数をネストさせることもできます。例えば、nfExecutives の結果をさらにフィルタリングしたい場合、別の計算式で nfExecutivesByHireDate = Filter(nfExecutives, HireDate > Today()) のように、名前付き計算式を参照する計算式を定義できます。

名前付き計算式の連鎖参照：計算式が計算式を参照する

名前付き計算式は、ほかの計算式を参照できます。Power Appsが依存関係を自動で解決するため、複雑な計算も論理的に整理できます。

nfExecutives = Filter(Employees, Department = "Executives");
nfExecutiveCount = CountRows(nfExecutives);

1番目の計算式 nfExecutives を2番目の計算式で参照しています。Power Appsは自動的に nfExecutives が先に計算されることを認識し、その結果を使って nfExecutiveCount を計算します。ただし、ループ参照（AがBを参照し、BがAを参照する状況）はエラーになります。

計算式を設計する際は、参照の流れを図に書いてみることをお勧めします。複数の計算式が絡む場合、視覚化することで依存関係が明確になり、バグを防ぎやすくなります。

日付・Sequenceを使った計算列

日付範囲や数列を使って、複数行のテーブルを生成する書き方です。

nfNext10Days = AddColumns(Sequence(10), "MyDate", DateAdd(Today(), Value, Days));

Sequence(10) は1から10までの数値テーブルを生成します。AddColumns関数で「MyDate」という列を追加し、Today() に Value（1, 2, 3… 10）日を加えています。結果として、今日から10日間の日付テーブルが作成されます。

このテーブルをギャラリーの Items に指定すると、自動的に10行のギャラリーが表示されます。固定的な日付範囲が必要な場合、この手法は非常に効率的です。動的に日付範囲を計算する場合も、Sequence の引数を変更するだけで対応できます。

トラブルシューティング：エラーが出たときの対処

Formulasプロパティはエラーメッセージが見づらいことが多いです。構文エラーが出た場合、まず画面上のコントロール（例えば、テキスト入力）の OnStart プロパティなどで計算式を試してみることをお勧めします。

コントロール上でエラーメッセージが明確に表示されれば、問題箇所を特定しやすくなります。その後、修正した計算式を Formulas プロパティに貼り付けると、スムーズに進みます。Formulasプロパティへの直接入力は、検証が終わった後が効率的です。

また、Formulasプロパティ内の計算式が相互に参照される場合、定義順序は関係ありません。Power Appsが自動的に依存関係を解決するため、どの順序で書いてもかまいません。

早見表：SetとClearCollectから名前付き計算式への置き換え

よく使う変数定義の置き換え方を表にまとめました。

用途	Set（変数）の書き方	名前付き計算式の書き方	主な違い
ユーザー情報	Set(varUser, User())	nfUser = User();	イコール向きが逆。セミコロン必須
固定選択肢リスト	Set(varStatus, Table({Value:“新規”}…))	nfStatus = Table({Value:“新規”}…);	Collectは使わない。Table直接指定
データソースキャッシュ	ClearCollect(varDepts, Departments)	nfDepartments = Departments;	ClearCollectは使わない。遅延評価
フィルター結果	ClearCollect(varExec, Filter(…))	nfExecutives = Filter(…);	ClearCollectは使わない
テーマカラー	Set(varColor, ColorValue(…))	nfColor = ColorValue(…);	イコール向きが逆
数値定数	Set(varMax, 100)	nfMaxValue = 100;	セミコロン必須

まとめ

名前付き計算式の書き方は、型によって異なりますが、基本ルール（右辺に式、末尾にセミコロン）は共通です。ユーザー情報、テーブル型、色定数、フィルター結果といった「変わらない値」の管理に最適です。

Set や ClearCollect から移行する際は、上の早見表を参考にしてください。計算式を連鎖参照させたり、Sequence を使って動的にテーブルを生成したりと、応用の幅も広がります。

関連記事：名前付き計算式とは → 名前付き計算式（App.Formulas）とは

関連記事：Power Appsパフォーマンス改善まとめ → Power Appsパフォーマンス改善まとめ

Power AppsのOnStartとOnVisible。どちらに書くべき？使い分けの鉄則

Mon, 16 Mar 2026 15:46:48 GMT

OnStartとOnVisibleは何が違うのか

Power AppsのOnStartとOnVisibleは、どちらに初期化処理を書くべきか迷う人が多いプロパティです。結論から言うと、ほとんどのケースでOnVisibleに書くほうが正解です。

OnStartはアプリ起動時に一度だけ実行されます。OnVisibleは画面が表示されるたびに実行されます。この違いを理解していないと、一覧を更新したはずなのに古いデータが表示され続けるという問題が起きます。実際に私も最初のころはOnStartに全部書いてしまい、画面遷移後にデータが更新されないというバグに何度もはまりました。

OnStartの特徴と使い所

OnStartはAppオブジェクトのプロパティで、アプリが起動したとき（または開発中にCtrl+Rでアプリを再実行したとき）に一度だけ実行されます。

OnStartに書くべき処理

OnStartに向いているのは、アプリ全体を通して一度だけ取得すればよい情報の初期化です。

ログインユーザー情報の取得（User()関数など）
アプリ全体で使うグローバル変数の初期値設定
環境によって変わる設定値の読み込み

例えば、ログインユーザーのメールアドレスをグローバル変数に格納しておくなら、OnStartに書くのが自然です。

Set(gblCurrentUser, User())

これをOnVisibleに書くと、画面を遷移するたびに毎回User()を呼び出すことになります。軽い処理なら問題ありませんが、SharePointリストからユーザー情報を引っ張るような処理は毎回実行したくないはずです。

OnStartの注意点：パフォーマンスへの影響

OnStartに重い処理（大量データの取得や複数のコレクション初期化など）を詰め込むと、アプリの起動が遅くなります。体感として、OnStartが3秒以上かかるとユーザーから苦情が来ます。重い処理はOnVisibleで遅延ロードするか、Named Formulasへの移行を検討しましょう。

OnVisibleの特徴と使い所

OnVisibleは各画面（スクリーン）のプロパティです。その画面が表示されるたびに実行されます。Navigate関数で画面遷移してくるたびに動くと考えてください。

OnVisibleに書くべき処理

OnVisibleに向いているのは、画面を開くたびに最新データを取得したい処理です。

ギャラリー用コレクションの更新
画面に表示するデータのフィルタリング
画面ローカルの変数の初期化

例えば、申請一覧画面を開くたびに最新の申請データを取得するなら、こうなります。

ClearCollect(colRequests, Filter(申請リスト, 担当者 = gblCurrentUser.Email))

OnVisibleにこれを書いておけば、他の画面から戻ってきたときも常に最新のデータが表示されます。OnStartに書いてしまうと、アプリ起動後に他の人が申請データを追加しても、自分の画面には反映されません。

コンテキスト変数の初期化はOnVisibleで

その画面だけで使うコンテキスト変数（UpdateContext）の初期化もOnVisibleに書きます。コンテキスト変数はその画面のスコープでしか使えないので、OnStartから操作することはできません。

UpdateContext({locIsLoading: false, locSelectedId: 0})

変数の使い分けについては別記事で詳しく解説しています。

→ Power Appsのグローバル変数とコンテキスト変数——違いと使い分けを図解

判断基準をまとめると

どちらに書くか迷ったときの判断基準はシンプルです。

判断基準	OnStart	OnVisible
実行タイミング	アプリ起動時に1回だけ	画面表示のたびに毎回
スコープ	アプリ全体	その画面
変数種別	グローバル変数（Set）	コンテキスト変数（UpdateContext）・コレクション
データ取得	一度だけ取れば十分なもの	最新データが必要なもの

私がアプリを設計するとき、OnStartはできるだけ軽くしておくのを心がけています。グローバル変数の初期値設定程度にとどめて、データ取得はすべてOnVisibleに回す、という方針にしてからアプリの起動が体感で早くなりました。

Concurrent関数で並列実行する

OnVisibleに複数のコレクション取得処理を書くと、上から順番に実行されるため時間がかかります。関係のない処理を並列で実行したいときはConcurrent関数が使えます。

Concurrent(
    ClearCollect(colRequests, 申請リスト),
    ClearCollect(colMembers, 社員マスタ),
    Set(locTitle, "申請一覧")
)

3つの処理が同時に走るので、順番に書くより速くなります。ただし処理が互いに依存している（AのコレクションをBで使うなど）場合は並列にできないので注意が必要です。

まとめ

OnStartはアプリ起動時に一度だけ、OnVisibleは画面表示のたびに実行されます。ほとんどの初期化処理はOnVisibleで対応できますし、そのほうがデータの鮮度も保てます。OnStartはグローバルな設定値の初期化など、本当に一度だけでいいものに絞るのが正解です。

この使い分けを意識するだけで、データが更新されないバグはかなり減ります。アプリ開発の地道な基礎ですが、ここを押さえておくと後々の開発がずっと楽になります。

Power Apps Patch関数応用ガイド｜複雑な列型・エラー処理・下書き保存の全パターン

Sun, 29 Mar 2026 19:06:12 GMT

Power Apps のPatch関数を使いこなすと、フォームコントロールに頼らない柔軟なデータ操作ができるようになります。新規レコードの作成から複雑な列型の更新、下書き保存のUX設計まで、Patch関数はアプリ開発の核心です。この記事では、Patch関数の応用パターンを体系的に整理し、各テーマの詳細解説へ案内します。

私自身、最初にPatch関数を触ったときは「引数の意味がよくわからない」「列の型によって渡し方が違うのが面倒」と感じました。でも使い込んでいくうちに、Patchさえ覚えれば編集フォームなしであらゆるデータ操作ができることに気づきます。一度コツをつかめば、アプリ設計の選択肢が格段に広がります。

Patch関数の基本をおさらいする

Patch関数の構文はシンプルです。第1引数がデータソース（SharePointリストやDataverseテーブル）、第2引数が対象レコード（新規ならDefaults・更新なら既存レコード）、第3引数が変更したい列と値のセットです。

// 基本構文
Patch(
    データソース,
    対象レコード,
    { 列名: 値, 列名: 値 }
)

この3引数の役割を理解するだけで、新規作成も更新も同じ関数で処理できることが見えてきます。Patch関数の基礎と使い方ではフォームなしでデータを保存する方法を丁寧に解説しています。Patchが初めての方はまずそちらを読んでから戻ってきてください。

新規レコードの作成：Defaults()を使う

第2引数にDefaults(テーブル名)を渡すと、新規レコード作成モードになります。Defaultsは「そのテーブルに新しいレコードを追加するための雛形」を返す関数で、IDや作成日時など自動設定される列の型情報を内包しています。

列型ごとに渡すべき値の形式が決まっている点がPatch初心者の最初の壁です。テキスト列はダブルクォートで囲んだ文字列、数値列はValue()でラップした数値、日付列はDatePickerコントロールのSelectedDateプロパティ、Yes/No列はBoolean値（true/false）を渡します。TextInputの出力は常に文字列型なので、数値列に直接渡すと「Expected Number, found type Text」エラーが出ます。

列型別の値渡しパターンを体系的にまとめたPatch関数で新規レコードを作成する方法では、Defaults関数の仕組みと各列型のサンプルコードを詳しく解説しています。

既存レコードの更新：Gallery.SelectedとvarRecord

既存レコードを更新するには、第2引数をDefaults()から更新対象のレコードに切り替えるだけです。ギャラリーで行を選択している場合は Gallery1.Selectedを渡せばそのレコードが更新対象になります。入力フォームの各コントロールのDefaultプロパティに Gallery1.Selected.列名を設定すると、選択したレコードの現在値が事前に入力欄へ反映されるので、編集フォームらしいUXが作れます。

ただし、Gallery.Selectedには落とし穴があります。新規レコードを追加した直後、ギャラリーはその新しいアイテムをSelectedとして選び直しません。前の選択状態が残ったまま次の操作に進むため、意図しないレコードを上書きするバグが起きます。これを解決するのがvarRecordパターンです。ギャラリーのOnSelectでUpdateContext({varRecord: ThisItem})を実行し、Patchの第2引数をvarRecordに変えることで、ギャラリーの選択状態への依存をゼロにできます。

Gallery.SelectedとvarRecordの使い分け・移行手順はPatch関数で既存レコードを更新する方法で段階的に解説しています。まずGallery.Selectedで動かし、慣れたらvarRecordに移行する順番がおすすめです。

複数画面の下書き保存：status列パターン

入力フォームが複数画面にまたがるアプリでは、「途中で保存できる」仕組みが必要です。承認フローの前段や、現場で入力を途中まで進めて後日続きを入力するケースが典型例です。このパターンの核心は、テーブルにstatus列（draft / open / in progress など）を追加し、Patchで状態を制御することです。

新規ボタンを押した瞬間にstatus=draftのブランクレコードをPatchで作成し、そのレコードをvarRecordに格納します。以降の画面遷移ボタンでは「varRecordをPatch→Navigate」の順で実行するため、どの画面でアプリを閉じてもdraftレコードとして残ります。最終画面の送信ボタンだけstatusをopenに変え、実質的な「提出」を実現します。

50フィールドある入力画面でもDisplayModeの制御を1箇所に集約できるテクニックや、空白ドラフトのクリーンアップ方法など、実装上の細かい工夫はPower Appsで下書き保存を実装する方法にまとめています。

SharePointの複雑な列型をPatchする

テキスト・数値・日付以外のSharePoint列をPatchするとき、渡すべき値の形式がテキストや数値と大きく異なります。最初に覚えるべき大原則は「単一選択はレコード形式、複数選択はテーブル形式」です。この1行を押さえれば、Choice列・Lookup列・Person列のパターンが一気に読みやすくなります。

Choice列（単一）はDropdownのSelectedをそのまま渡せます。Choices(リスト名.列名) をDropdownのItemsに設定しておくと、DropdownのSelectedが自動的に {Value:“Red”} のようなレコード形式になるので、それをPatchに渡すだけです。Person列はComboBoxを使い、Choices関数がClaimsやDisplayNameを含む全フィールドを整形してくれます。ハードコードする場合はClaims列だけ渡せばSharePointが残りを自動補完します。

マネージドメタデータや複数選択Lookup列も含めた全列型の解説はSharePoint複雑な列をPatchする方法で網羅しています。よくあるエラーの逆引き方法も紹介しているので、詰まったときに参照してください。

DataverseをPatchする：SharePointとの違い

Dataverseの列型パターンはSharePointと似ているようで、いくつか重要な違いがあります。まずChoice列の形式です。SharePointのChoice列はレコード形式（{Value:“選択肢”}）で渡しますが、DataverseはEnum形式で列名.オプション名（例：Status.Draft）と書きます。SharePointに慣れた状態でDataverseに移ると、ここで必ずはまります。

もう一つの落とし穴がYes/No列です。SharePointのYes/Noは true/false のBoolean値を直接渡せますが、DataverseのYes/Noは内部的にChoice型として実装されているため、If(Toggle.Value, 列名.Yes, 列名.No)の形式が必要です。Toggleの値をそのまま渡すとエラーになります。SharePoint経験者が最もつまずくポイントです。

Dataverse固有の機能として、ファイル列と画像列を直接Patchできます。SharePointではアプリ内でファイルを直接保存することはできませんが、Dataverseではこの制約がありません。画像列の.valueと.fullの使い分けなど、Dataverse特有のパターンはDataverseをPatchする全列型ガイドにまとめています。

Patch関数と組み合わせる関連パターン

Patch関数は単独で使うことも多いですが、他の機能と組み合わせることで真価を発揮します。よく一緒に登場する3つのパターンを整理しておきます。

1つ目はSharePointのCRUD基本パターンとの組み合わせです。ギャラリーでデータを表示し、フォームなしでPatchで書き込む流れはSharePointリストのCRUD操作でも触れています。PatchはRemove（削除）と並んで、フォームを使わないデータ操作の中心です。

2つ目はエラー処理との組み合わせです。Patchが失敗したときにユーザーへ通知する仕組みや、Errors関数でエラーの詳細を取得する方法はエラー処理クラスターで解説予定です。業務アプリでは「保存に失敗したことを使用者に伝える」ことが必須なので、Patchを本番アプリに使うなら合わせて実装してください。

3つ目はコレクションとの連携です。Patchをコレクションに対して使うと、ローカルで複数行を一時編集してまとめてSharePointへ書き込むパターンが作れます。編集グリッドを実装するときに登場するアプローチです。

まとめ：Patch関数の学習ロードマップ

Patch関数の習得には段階があります。まず基礎記事でDefaults・列型・Format Textを覚える。次に更新パターンでGallery.SelectedとvarRecordの使い分けを身につける。慣れてきたら下書き保存やstatus列パターンでアプリのUXを設計する。複雑な列型（Choice・Person・Lookup）はその後に取り組むと、引数の意味が腹落ちした状態で読めるので理解が早いです。

ステップ	テーマ	キーワード
基礎	Patch関数の使い方	基本構文・3引数
新規作成	新規レコードの作成	Defaults・列型別の値渡し
更新	既存レコードの更新	Gallery.Selected・varRecord
UX設計	下書き保存の実装	status列・条件付きPatch
応用①	SharePoint複雑な列型	Choice・Person・Lookup
応用②	Dataverse列型ガイド	Enum形式・ファイル列

Patch関数は覚えるべきことが多いように見えますが、基本パターンを一度体で覚えれば、列型が変わっても「形式が違うだけ」と冷静に対処できます。社内の業務改善アプリを自分の手で作るという目標に向かって、一歩ずつ積み上げていきましょう。

Power Apps でDataverse列をPatchする｜テキスト・数値・選択肢・ファイル・画像の全列型ガイド

Sun, 29 Mar 2026 19:06:12 GMT

DataverseはSharePointと比べてPatchの書き方が異なる列型がいくつかあります。特にYes/No列と選択肢列はSharePoint経験者が最もつまずくポイントです。本記事では列型別にPatchの書き方を整理します。最後にSharePointとの違いを一覧で比較するので、切り替えの際の参考にしてください。

SharePointと違うDataverseのPatch：先に知っておくべき3点

SharePointからDataverseに切り替えたときに戸惑いやすい点が3つあります。選択肢列がEnum形式（Status.Draft のような書き方）になること、Yes/No列がBoolean（true/false）ではなくEnum扱いになること、そしてファイル・画像列が直接Patchできることです。最初の2点は「SharePointのやり方が通用しない」という意味でエラーが出やすいので、先に覚えておくと後半が読みやすくなります。

テキスト列

テキスト列には文字列をそのまま渡します。SharePointと同じ要領です。1行テキスト・メール・電話番号・URLはいずれも同じ書き方でPatchできます。

TextColumn: "こんにちは"
TextColumn: inpTitle.Text

1行テキストの最大文字数は4,000字です。それを超える場合は複数行テキスト列（プレーンまたはリッチテキスト）に変更してください。どちらも渡し方は同じです。リッチテキスト列にはHTMLタグを含む文字列を渡せます。表示側はHTMLテキストコントロールで受け取ると書式が保持されます。

数値列

数値列にはダブルクォートなしの数値を渡します。これもSharePointと同じです。TextInputから渡す場合は Value() でラップが必要です。

NumberColumn: 28
NumberColumn: Value(inpAge.Text)

Dataverseには整数・小数・浮動小数点・期間・言語コードなど複数の数値型がありますが、Power Apps側からはいずれも数値を渡すだけで変わりません。通貨列も実体は数値です。金額を数値で渡すだけで、通貨記号や換算レートはDataverse側が管理します。

CurrencyColumn: 9.99

日付・時刻列

日付列にはDatePickerの .SelectedDate か Today() / Now() 関数を渡します。SharePointと同じ要領です。

DateColumn: dpHireDate.SelectedDate
DateColumn: Today()

選択肢（Choice）列：DataverseはEnum形式

DataverseのChoice列はSharePointのChoiceとは異なります。SharePointは { Value: “Red” } のようなレコード形式でしたが、DataverseはEnum形式で渡します。

// 列名.オプション名 の形式
StatusColumn: Status.Draft
StatusColumn: Status.Open

Power Apps数式バーで列名を打ってドットを押すと、登録されている選択肢が補完候補に出てきます。そこから選ぶと確実です。コントロールから渡す場合はDropdownのSelectedを使います。

Yes/No列：SharePoint経験者が最もつまずくポイント

DataverseのYes/No列はSharePointと最も動作が違う列です。SharePointのYes/No列はBoolean（true/false）をそのまま渡せますが、DataverseのYes/No列は実態がChoice型です。そのため true/false を直接渡すとエラーになります。

// NG（SharePoint式の書き方。Dataverseでは動かない）
PropertyDamage: tglDamage.Value

// OK（If文でEnum形式に変換して渡す）
PropertyDamage: If(
    tglDamage.Value,
    PropertyDamage.Yes,
    PropertyDamage.No
)

SharePointで動いていたコードをDataverseに移行するとここで必ずつまずきます。Toggleから渡す場合はIf文でYes/Noに変換する必要があることを覚えておいてください。このEnumの列名はDataverseのテーブル設計時に設定した列名です。数式バーで補完が効くので確認しながら入力してください。

ルックアップ列

DataverseのルックアップはSharePointのChoices関数は使いません。DropdownのItemsに参照先テーブルを直接設定してDropdown.Selectedを渡す形が基本です。

// DropdownのItemsプロパティ
Employees

// Patchに渡す
ParentRecord: ddEmployee.Selected

画像列：.valueと.fullの使い分け

DataverseはSharePointと異なり、ファイルや画像をPatch関数で直接書き込めます。SharePointの画像列はPower Appsからの直接Patchができないのとは大きな違いです。

// 画像を保存する（AddPictureコントロール）
ImageColumn: UploadedImage1.image

// ギャラリーで表示する（サムネイル推奨）
Image1.Image = ThisItem.ImageColumn.value

// 詳細画面で高解像度を表示する
Image1.Image = ThisItem.ImageColumn.full

Dataverseの画像列には .value と .full の2つのプロパティがあります。.value はDataverseが自動生成したサムネイル（低解像度・角丸）、.full は元ファイルです。ギャラリーでは .value を使うのがパフォーマンス上おすすめです。リスト表示時に全行分の高解像度画像を読み込まずに済むため表示が速くなります。詳細画面で大きく見せたいときだけ .full を使う設計が定石です。

AutoNumber列はPatch不可

AutoNumber列（自動採番）はPatchできません。Dataverseが自動的に連番を割り当てるため、アプリ側から値をセットしようとするとエラーになります。Patch文に含めなければエラーにはなりません。自動採番列はPatch時には無視してください。

SharePointとDataverseの主な違い

SharePointとDataverseのPatchで押さえるべき違いを整理します。テキスト・数値・日付はどちらも同じ書き方で渡せます。Choice列はSharePointがレコード形式（{ Value: “Red” }）なのに対し、DataverseはEnum形式（Status.Draft）です。Yes/No列はSharePointがBoolean直渡しOKなのに対し、DataverseはIf文でYes/Noに変換が必要です。画像列はSharePointがPower Appsから直接Patch不可なのに対し、DataverseはPatch可能です。SharePointの複雑な列型のPatch解説と合わせて読むと理解が深まります。

まとめ

DataverseやSharePointのPatchパターンを含む応用ガイド全体はPatch関数応用ガイドでまとめています。列型ごとの比較表や学習ロードマップも掲載しています。

Dataverse列のPatchでSharePoint経験者が引っかかりやすいのは、選択肢列のEnum形式とYes/No列のIf変換の2点です。この2点さえ覚えれば、それ以外はSharePointとほぼ同じ感覚で書けます。Patch関数の基本については新規レコード作成編を、既存レコード更新のパターンは既存レコード更新編を参照してください。

Power Appsで絶対覚えたいPatch関数の使い方。フォームなしでデータを保存する方法

Thu, 12 Mar 2026 11:48:00 GMT

Power Appsでデータを保存するには、フォームを使う方法とPatch関数を使う方法の2つがあります。Patch関数を覚えると、フォームに縛られない柔軟なアプリ設計ができるようになります。

Patch関数とは何か

SubmitFormとの違い

Power Apps でデータを保存する方法は大きく2つあります。フォームコントロール（EditForm）を配置して SubmitForm で送信する方法と、Patch関数を直接呼び出す方法です。

SubmitForm はフォームコントロールと画面のレイアウトがセットになっており、標準的な入力画面を素早く作るには便利です。ただし、複数のデータソースに同時に書き込みたいとき、ボタン1つで複数のレコードをまとめて更新したいとき、ポップアップ内や確認ダイアログからのみデータを保存したいとき、といった場面ではフォームコントロールが邪魔になることがあります。そういうときの答えが Patch 関数です。

私が最初に Patch関数の必要性を感じたのは、承認ボタンを押したときにステータスと承認者と承認日時の3列を一気に更新したかったときでした。フォームを使うと余計なフィールドが全部並んでしまう。Patch なら必要な列だけを書き込めるので、UI の自由度が大きく上がります。

それ以降も、基本的にアプリ作成時はSubmitFormよりもPatchを使うことが自然になりました。

Patch関数の基本構文

Patch の基本的な書き方はシンプルです。

Patch(データソース, 対象レコードまたはDefaults(データソース), {列名1: 値1, 列名2: 値2, ...})

引数は3つです。最初がどのデータソース（SharePointリストなど）に書き込むか。次が新規作成か更新かを決めるレコードの指定。最後が実際に書き込む列と値のセットです。

新規レコードを作成する

Defaultsを使った新規作成

新しいレコードを作るときは、2番目の引数に Defaults 関数を使います。Defaults はデータソースの初期状態（空白レコード）を返す関数です。簡単にいえば、新しい行を追加するときのひな型を用意してくれると思えばいいです。

Patch(
    申請リスト,
    Defaults(申請リスト),
    {
        タイトル: テキスト入力_タイトル.Text,
        申請者: User().DisplayName,
        申請日: Today(),
        ステータス: "申請中"
    }
)

このコードをボタンの OnSelect に書くだけで、SharePointリストに新しいレコードが追加されます。フォームコントロールは一切不要です。User() 関数でログインユーザーの名前を自動入力したり、Today() で今日の日付を入れたりと、入力を省力化する書き方も自由に組み合わせられます。

保存後の処理を組み合わせる

Patch の後に続けて処理を書く場合は、セミコロンで区切ります。保存した後でフォームをリセットしたり、別の画面に遷移したりする場合は以下のように書きます。

Patch(
    申請リスト,
    Defaults(申請リスト),
    {
        タイトル: テキスト入力_タイトル.Text,
        申請者: User().DisplayName,
        申請日: Today(),
        ステータス: "申請中"
    }
);
Reset(テキスト入力_タイトル);
Navigate(ホーム画面, ScreenTransition.None)

Patch で保存、Reset でテキスト入力欄を空に戻し、Navigate で画面遷移という3ステップをボタン1つに集約できます。この書き方ができるようになると、アプリ設計の幅がぐっと広がります。

既存レコードを更新する

ThisItemとの組み合わせ

ギャラリーやフォームの中で既存レコードを更新するときは、2番目の引数に ThisItem を使います。ThisItem はギャラリーの現在の行を指します。

// ギャラリー内のボタンの OnSelect に書く例
Patch(
    申請リスト,
    ThisItem,
    {
        ステータス: "承認済み",
        承認者: User().DisplayName,
        承認日: Today()
    }
)

この書き方をすると、ギャラリーで選択している行のステータス・承認者・承認日の3列だけを書き換えます。他の列（タイトルや申請者など）はそのまま維持されます。これが Patch の便利なところで、指定した列だけを選択的に更新できる点が大きな強みです。

LookUpで対象レコードを特定する

ギャラリーの外から特定のレコードを更新したい場合は、LookUp関数で対象を特定します。LookUp は条件に一致する単一のレコードを返す関数です。

Patch(
    申請リスト,
    LookUp(申請リスト, ID = SelectedID),
    {ステータス: "却下"}
)

SelectedID に更新したいレコードの ID が入っている前提です。LookUp が該当レコードを見つけて Patch に渡し、そのレコードのステータスだけを更新します。画面をまたいだ処理や、グローバル変数に保持している選択レコードを後から更新する場面でよく使います。

複数レコードをまとめて更新する

ForAllとPatchの組み合わせ

複数のレコードを一括更新したい場合は、ForAll 関数と組み合わせます。ForAll はテーブルの各行に対して処理を繰り返す関数です。

// コレクション内の全件をSharePointに一括保存
ForAll(
    colDraft,
    Patch(
        申請リスト,
        Defaults(申請リスト),
        {
            タイトル: タイトル,
            申請者: 申請者,
            ステータス: "申請中"
        }
    )
)

colDraft というコレクションに溜めておいたデータを、ボタン1つで一括保存するパターンです。入力画面でどんどんコレクションに追加していき、最後に一括でSharePointに書き込む設計が、スキャン系・日報系アプリではよく使われます。

ただし、ForAll の中で Patch を呼ぶと件数が多いときに時間がかかります。体感でも10件を超えると待ち時間が気になります。大量件数の一括保存が必要な場合は、Power Automate のフローに処理を渡す設計を検討しましょう。

Patch関数を使うときの注意点

列名はSharePointの内部名に注意

SharePointリストを使う場合、Patch に渡す列名は SharePoint の表示名と内部名が一致していることが多いですが、日本語の列名で作ったリストの内部名が英数字になっているケースがあります。特にリスト作成後に列名を変更した場合、内部名は変わらないので注意が必要です。

Power Appsのデータソースペインで列をクリックすると内部名が確認できます。Patch でエラーが出るときは、まず列名のズレを疑ってみてください。

必須列が欠けているとエラーになる

SharePointリストで必須列（Required）の設定がある場合、Patch でそれらの列を省略するとエラーになります。新規作成のときは必須列をすべて含めるよう注意しましょう。Defaults を使っていても必須列の値が入っていなければ保存できません。

エラーが発生したかどうかは Errors 関数で確認できます。

If(
    IsEmpty(Errors(申請リスト)),
    Notify("保存しました", NotificationType.Success),
    Notify("エラーが発生しました: " & First(Errors(申請リスト)).Message, NotificationType.Error)
)

Patch の直後にこの分岐を書いておくと、保存成功と失敗をユーザーに通知できます。現場アプリでは必ず入れておきたい処理です。

SubmitFormを使うべきシーンも残っている

Patch関数を覚えると何でも Patch で書きたくなりますが、標準的な入力フォームを素早く作りたいときは SubmitForm のほうがシンプルに済みます。入力・編集・表示の3モードを自動で切り替えてくれる EditForm コントロールはよくできていて、バリデーション（入力チェック）もある程度自動でやってくれます。

Patch と SubmitForm の使い分けをまとめると以下のようになります。

シーン	おすすめ
標準的な入力フォームを素早く作る	SubmitForm（EditForm）
特定の列だけを更新する	Patch
複数データソースに同時に書き込む	Patch
ボタン1つでまとめて保存する	Patch
コレクション経由で一括登録する	Patch（ForAll と組み合わせ）

Power Appsの変数の使い方についてはグローバル変数とコンテキスト変数の記事も合わせて読んでみてください。Patch で保存する前後の状態管理に変数はよく使います。また、データの取得には Filter や LookUp 関数が必要になるので、Power Appsとは？完全ガイドも参考にどうぞ。

まとめ

Patch関数の基本は「どこに（データソース）」「何を（Defaults か既存レコード）」「どんな値で（列と値のセット）」の3点セットです。これを押さえれば、フォームに縛られない自由な設計ができるようになります。

最初は Defaults との組み合わせで新規作成から始めて、慣れてきたら ThisItem や LookUp を使った更新に挑戦してみてください。Patch が使えるようになると、Power Apps でできることの幅が体感でわかります。楽しみながら試してみましょう。

Power Apps Patch関数で新規レコードを作成する｜Defaults・列型別の値指定パターン完全解説

Sun, 29 Mar 2026 19:06:11 GMT

フォームを使わずにSharePointにデータを保存したいなら、Patch関数が答えです。Patch関数は列の型さえ意識すれば難しくありません。ただ最初のうちは型エラーで詰まる人が多いので、基本の構造から丁寧に解説します。

Patch関数の3つの引数

Patch関数は次の3つの引数で構成されています。

Patch( データソース, 対象レコード, 更新する列と値 )

「どのテーブルに」「新規か更新か」「何を書くか」という3点セットです。この構造さえ頭に入れておけば、あとは列の型に合わせた値を渡すだけです。

第1引数：データソース

保存先のテーブルを指定します。SharePointリストなら接続時の名前（例：Employees）をそのまま書きます。アプリにデータソースを追加してあれば自動補完が効くので、名前を丸暗記する必要はありません。データソースの追加方法がわからない場合は、SharePoint CRUDの基本パターンを先に読んでみてください。

第2引数：対象レコード

新規レコードを作るか、既存レコードを更新するかはここで決まります。新規作成には Defaults(テーブル名) を使います。Defaultsとは「まだ何も書いていない新規レコードの雛形」を意味します。料理にたとえるなら、まだ何も書いていない注文票を1枚取り出す操作です。既存レコードを更新したい場合はGallery.SelectedやvarRecordを使いますが、それは既存レコード更新編で解説します。

第3引数：更新する列と値

{ 列名: 値, 列名: 値 } の形で書きます。波括弧で囲むことを忘れないでください。Power Appsのレコードは常にこの波括弧形式で表現されます。列名は自動補完が効くので、最初の数文字を打てば候補が出てきます。補完候補を活用するとスペルミスも防げて一石二鳥です。

まずハードコードで動かしてみる

Patch関数を初めて使うとき、やるべきことはまずハードコードで動かすことです。入力コントロールを一切使わずに固定値を書いて、それだけで動作するか確かめます。

Patch(
    Employees,
    Defaults(Employees),
    {
        Title: "テスト太郎"
    }
)

ボタンのOnSelectにこれを貼り付け、Altキーを押しながらクリックすると1秒以内にSharePointへレコードが作成されます。うまく動いたら、次の列を1本ずつ追加していくやり方が、エラー発生時に原因を特定しやすくておすすめです。

私が社内で教えるときも、まずこのハードコードバージョンを試してもらいます。最初から入力フォームを組み込もうとして型エラーで詰まる人が多いので、まず動かすことを最優先にする順番が大切です。Power Appsは動いている状態から拡張していくほうが圧倒的に学びやすいです。列を1本追加して動かす、また1本追加して動かすという地道な繰り返しが、結果的に最短ルートになります。

列型別：値の渡し方

Patch関数で詰まる原因のほぼすべては、列の型に合わない値を渡していることです。Power Appsは型に対してとても厳格で、テキストを欲しがっているのに数値を渡すとすぐにエラーになります。「Power Appsはとにかく欲しいものだけを渡せ」という原則を念頭に置いて読み進めてください。

テキスト列

テキスト列には文字列を渡します。ハードコードならダブルクォートで囲み、入力コントロールを使うなら .Text プロパティを指定します。

// ハードコード
Title: "テスト太郎"

// TextInputから渡す場合
FirstName: inpFN.Text

TextInputコントロールのデフォルト出力は常に文字列です。テキスト列に渡すぶんには .Text をつけるだけでOKです。このあたりが数値列との大きな違いになりますので、次を読み進めてください。

数値列

数値列にはダブルクォートを外して数値をそのまま渡します。

Age: 28

TextInputから値を渡したいときは Value() 関数でラップしてください。これが最初の壁になる人がとても多いです。TextInputの .Text はどんな数字を打っても文字列として返します。28 と入力しても Power Apps からみれば「28という文字列」です。数値列は数値が欲しいので Value() で変換する必要があります。

Age: Value(inpAge.Text)

Value() を忘れると「Expected Number, found type Text」というエラーが出ます。次のセクションで詳しく取り上げますが、このエラーを見たらまず Value() が抜けていないか確認してください。

日付列

日付列にはDatePickerコントロールの .SelectedDate プロパティを使うのが定番です。.SelectedDate は日付型を返すので、そのまま渡せます。

// DatePickerから渡す場合
HireDate: dpHire.SelectedDate

// 今日の日付をハードコードする場合
HireDate: Today()

テスト段階では Today() を使ってハードコードしておくと、DatePickerの設定まで手が回らないうちでも動作確認ができて便利です。まずハードコードで動かして、後からコントロールに切り替える流れがおすすめです。

Yes/No列（SharePoint）

Yes/No列（SharePoint）には true または false をそのまま渡します。ダブルクォートは不要なBoolean値です。Toggleコントロールなら .Value プロパティがBoolean型を返すので、そのまま使えます。

// Toggleコントロールから渡す場合
GoodAtJob: tglGood.Value

// ハードコードの場合
GoodAtJob: false

なおDataverseのYes/No列はSharePointとは動作が異なります。DataverseのYes/No列はChoice型と同じ扱いになるため、true/falseをそのまま渡してもエラーになります。DataverseとのPatchについては別記事で解説しています。

よくあるエラーと対処法

Expected Number, found type Text

数値列にテキストを渡しているときに出るエラーです。原因はほぼ例外なく Value() の付け忘れです。数式バーでエラーが出ている箇所をホバーすると「The type of argument does not match the expected type: Number. Found type: Text.」という説明が表示されます。Numberが欲しいのにTextを渡したという意味なので、Value(inpAge.Text) のように Value() でラップして解決します。

体感的にいって、Value()の付け忘れはPatch関数デビュー時の詰まりポイント1位です。エラーメッセージをホバーして読む癖をつけると、原因が一発でわかるようになります。Power Appsが型を丁寧に教えてくれているので、それを読む習慣が身につくと一気に上達します。

TextInput全体を渡したときのエラー

.Text や .Value まで指定せず、コントロール名だけを渡すとエラーになります。Power Appsはコントロールオブジェクト全体を送ろうとするため、SharePointが受け取れないデータになってしまいます。

// NG（.Textが抜けている）
FirstName: inpFN

// OK
FirstName: inpFN.Text

ホバーして「Data type: Control」と表示されたら、プロパティまで掘り下げられていないサインです。ドットを追加して .Text や .SelectedDate などに辿り着くまで確認してください。コントロールのどのプロパティを使えばいいかわからないときも、ドットを打って補完候補を眺めると目的のプロパティが見つかります。

Format Textで整形する習慣

列が増えると、Patch関数を1行に書き連ねてしまいがちです。数式バー右下のFormat Textボタンで整形すると、列ごとに自動で改行されます。

Patch(
    Employees,
    Defaults(Employees),
    {
        Title: "テスト太郎",
        FirstName: inpFN.Text,
        Age: Value(inpAge.Text),
        HireDate: dpHire.SelectedDate,
        GoodAtJob: tglGood.Value
    }
)

列が5本・10本と増えても修正しやすく、どの列に何を渡しているか一目でわかります。Patch関数を書いたら必ずFormat Textをかけることをおすすめします。これは地味な習慣ですが、後から別の人が読むときにも助かりますし、自分が数週間後に見直すときにも理解しやすくなります。

変数と組み合わせた複雑なパターンが増えてきたときは、グローバル変数とコンテキスト変数の使い分けも参考にしてみてください。Patch関数と変数の組み合わせはアプリ設計の基本パターンになります。

まとめ

Patch関数の新規レコード作成は、Defaults・型に合わせた値渡し・Format Textの3点を押さえれば動かせます。Patch関数の基礎記事で全体像を把握した上で、この記事で列型別の渡し方を練習するのが自然な順番です。

次のステップは既存レコードの更新です。Defaultsを選択中のレコードに変えるだけで更新モードに切り替わります。Gallery.SelectedやvarRecordを使った更新パターンは既存レコード更新編で詳しく解説しています。

新規作成をはじめ、更新・下書き保存・複雑な列型など、Patch関数の応用パターンを体系的にまとめたPatch関数応用ガイドも合わせて参照してください。

Patch関数は最初は難しく感じますが、使い込むほど手に馴染みます。市民開発は地道な積み重ねですが、Patchを使いこなせるようになると作れるアプリの幅が一気に広がります。楽しみながら進めていきましょう。

Power Apps でSharePoint複雑な列をPatchする｜選択肢・ユーザー・ルックアップ・マネージドメタデータ完全解説

Sun, 29 Mar 2026 19:06:12 GMT

SharePointのChoice列・Person列・Lookup列・マネージドメタデータ列は、テキストや数値と同じ感覚でPatchしようとすると必ずエラーになります。これらの列には「レコード形式」や「テーブル形式」で値を渡す必要があるからです。本記事では列型ごとにコントロールを使う方法とハードコードする方法の2パターンを整理します。

まず押さえる大原則：単一選択はレコード、複数選択はテーブル

複雑な列型のPatchを理解するうえで最初に覚えるべき原則が1つあります。

単一選択の列にはレコード（波括弧 { } ）を渡します。複数選択の列にはテーブル（Table関数で包んだレコードの集合）を渡します。Choice列・Lookup列・Person列すべてにこの原則が適用されます。これを先に腹落ちさせておくと、後半の各列型の説明が一気に読みやすくなります。

また、コントロールから渡す場合はChoices関数がデータを自動的に正しい形に整えてくれます。一方ハードコードする場合は自分でレコードやテーブルを組む必要があります。コントロール経由のほうが圧倒的に楽なので、まずはコントロールから試して動作確認をしてからハードコードに挑戦する順番がおすすめです。

Choice列（単一選択）

コントロールから渡す

DropdownコントロールのItemsプロパティにChoices関数を設定します。

// DropdownのItemsプロパティ
Choices(ComplexColumns.MyChoiceColumn)

これでSharePointのリストから選択肢（例：Red / Green / Blue）が自動的に取得されます。Patch時はDropdown.Selectedをそのまま渡すだけです。

MyChoiceColumn: ddChoice.Selected

Dropdown.Selectedは { Value: “Red” } のようなレコード形式を返します。SharePointが求めているのもこのレコード形式なので、そのまま渡せばOKです。

最頻出ミス：.Selected.Valueを渡してしまう

選択した値のテキストが欲しくて ddChoice.Selected.Value と書きたくなりますが、これをPatchに渡すとエラーになります。.Selected.Value は文字列 “Red” を返しますが、Choice列はレコードを求めているからです。

// NG（文字列を渡している）
MyChoiceColumn: ddChoice.Selected.Value

// OK（レコードをそのまま渡す）
MyChoiceColumn: ddChoice.Selected

ハードコードする

値がわかっている場合は { Value: “Blue” } の形で直接書けます。SharePointは値が一致すれば受け付けてくれます。

MyChoiceColumn: { Value: "Blue" }

Choice列（複数選択）

複数選択にはComboBoxコントロールを使います。ItemsはDropdownと同じくChoices関数を設定します。Patch時は .Selected ではなく .SelectedItems を使います。

MyMultiChoiceColumn: cbChoices.SelectedItems

.SelectedItemsはテーブル形式を返します。1つだけ選んでいてもテーブル形式で返ってくるのがポイントです。複数選択列はテーブルが必要なので、これはそのまま渡せます。ハードコードする場合はTable関数で複数のValueレコードを包みます。

MyMultiChoiceColumn: Table(
    { Value: "London" },
    { Value: "Paris" }
)

Lookup列

Lookup列もChoice列と同じパターンです。DropdownのItemsにChoices関数を設定し、Dropdown.Selectedをそのまま渡します。Choices関数が { ID: 4, Value: “Chewy” } のようなレコードを自動生成してくれます。IDはルックアップ先リストのIDで、Valueは表示フィールドの値です。

// DropdownのItemsプロパティ
Choices(ComplexColumns.MyLookupColumn)

// Patchに渡す
MyLookupColumn: ddLookup.Selected

ハードコードする場合はIDとValueの両方が必要です。IDはルックアップ先リストをブラウザで開いて確認します。わからない場合はDropdown.Selectedをホバーするとレコードの形が見えるので、そこからIDを読み取るのが確実です。

MyLookupColumn: { ID: 3, Value: "Shane" }

Person列

Person列は必ずComboBoxを使います。DropdownではSharePointのユーザー候補が表示されません。さらにComboBoxのSearchableプロパティをtrueに設定しないと検索入力欄が現れません。これが見落としやすいポイントです。

// 単一ユーザー（SelectMultiple: false）
MyPersonColumn: cbPerson.Selected

// 複数ユーザー（SelectMultiple: true）
MyPersonColumn: cbPerson.SelectedItems

Choices関数がClaims・DisplayName・Email・Departmentなど多数のフィールドを含むレコードを自動で整形してくれます。ハードコードではClaimsフィールド1つだけで済みます。SharePointが残りのフィールドを自動補完してくれるからです。

// 特定ユーザーをハードコード
MyPersonColumn: { Claims: "user@contoso.com" }

// ログイン中のユーザーを動的に指定
MyPersonColumn: { Claims: User().Email }

// 複数ユーザーをTable関数で
MyPersonColumn: Table(
    { Claims: "user1@contoso.com" },
    { Claims: User().Email }
)

エラーから列名を逆引きするテクニック

ハードコードで必要な列名がわからないときは、わざと存在しない列名で書いてエラーを出す方法が使えます。ホバーすると「Missing column: Claims」のように必要な列名を教えてくれます。記憶に頼らず確認できる実用的なテクニックです。

// 意図的に存在しない列名で書く→エラーが必要な列名を教えてくれる
MyPersonColumn: { WrongName: "test" }

マネージドメタデータ列・Yes/No列・ハイパーリンク列・画像列

マネージドメタデータ列もChoices関数が使えます。Dropdown.Selectedをそのまま渡します。ハードコードする場合はLabelとTermGuidの2フィールドが必須です。TermGuidはSharePoint管理センターのタームストアで事前に調べておく必要があります。

Yes/No列（SharePoint）はBoolean（true/false）をそのまま渡せます。Toggleコントロールなら .Value がBoolean型を返すのでそのまま使えます。なおDataverseのYes/No列は動作が異なり、true/falseの直渡しはできません。詳しくはDataverseのPatch完全解説で解説しています。

// Yes/No列（SharePoint）
MyYesNoColumn: tglApproved.Value
MyYesNoColumn: true

ハイパーリンク列はURL文字列をそのまま渡します。列の設定が「画像」になっている場合はPatch自体ができません。代替テキストの設定はPower Appsからは不可です。画像列にはAddPictureコントロールの UploadedImage1.image を渡します。

MyHyperlinkColumn: inpUrl.Text
MyImageColumn: UploadedImage1.image

まとめ

SharePointの列型を含むPatch関数の応用パターン全体はPatch関数応用ガイドで整理しています。Dataverseとの違いや下書き保存パターンも同じページから確認できます。

SharePointの複雑な列型のPatchは「単一選択=レコード、複数選択=テーブル」の原則と、コントロール経由ならChoices関数が形を整えてくれるという2点を押さえれば整理できます。基本的なPatchの書き方は新規レコード作成編を参照してください。

Power Apps Patch関数で既存レコードを更新する｜Gallery.Selected・varRecord・入力欄の初期値設定

Sun, 29 Mar 2026 19:06:11 GMT

Patch関数の第2引数を1か所変えるだけで、新規作成から既存レコードの更新に切り替えられます。この仕組みを理解すると、「編集ボタンを押した行だけ更新する」というパターンが自然に作れるようになります。

Gallery.Selectedで更新モードに切り替える

Patch関数の第2引数をDefaultsからGallery.Selectedに変えるだけで、新規作成から既存レコードの更新に切り替わります。

// 新規作成（Defaults = 空の新規レコードの雛形）
Patch(Employees, Defaults(Employees), { Title: "テスト太郎" })

// 既存レコードの更新（Gallery.Selected = 現在選択中のレコード）
Patch(Employees, Gallery1.Selected, { Title: "テスト太郎" })

Gallery1.Selectedはギャラリーで現在選択されているレコードを指します。第2引数をそこに変えるだけで、「今選んでいる行を上書き更新する」ボタンが完成します。新規レコード作成編でDefaultsを使った保存を試した後に、この変化を見るとPatch関数の構造が一気に腹落ちします。

選択状態を視覚化してデバッグしやすくする

Gallery.Selectedが正しく動いているか確かめるには、ギャラリーのTemplateFillプロパティにIsSelectedを使う方法が便利です。選択中のアイテムを色でハイライトします。

// TemplateFill プロパティ
If(
    ThisItem.IsSelected,
    ColorFade(RGBA(74, 144, 226, 1), 80%),
    Transparent
)

ThisItem.IsSelectedは選択中のアイテムがtrueを返します。見た目が変わるだけで「どの行を選んでいるか」が確認できるので、Patchが意図したレコードに当たっているか把握しやすくなります。ギャラリー系の記事で詳しく紹介していますが、更新系アプリを作るときにも必ず役立つテクニックです。

入力欄に現在値を事前表示する

更新フォームでは「現在の値を入力欄に最初から表示してから編集する」UXが基本です。TextInputのDefaultプロパティにGallery.Selected.列名を設定すると、選択中のレコードの値が入力欄に事前表示されます。

// TextInputのDefaultプロパティ
Gallery1.Selected.Title

これを設定しておくと、ユーザーが「今何が入っているか」を見た上で編集できます。全部消してから打ち直す手間がなく、一部だけ変更したいときに特に便利です。

ギャラリーでアイテムをクリックするたびに入力欄の表示が切り替わるため、「どのレコードを編集しているか」がユーザーにも自然に伝わります。ただし、この方法はGallery.Selectedへの依存が強くなるため、複数画面アプリでは次のvarRecord方式に移行することをおすすめします。

Gallery.Selectedの限界

Gallery.Selectedは手軽ですが、使い続けると限界にぶつかります。最も多いのが「新規作成直後の残存問題」です。

Patchで新規レコードを作成した後、ギャラリーの先頭に新しいレコードが表示されます。しかしGallery.Selectedは自動的に新しいレコードを選択してくれません。前に選んでいたレコードのままになるため、この状態でPatchボタンを押すと意図していない別のレコードが上書きされます。

私が最初にアプリを作ったとき、まさにこれで詰まりました。データを更新したはずなのに別の行が変わっていて、しばらく原因がわからなかったです。複数画面にまたがるアプリでは、ギャラリーから離れた瞬間にSelectedが解除されるケースもあります。Gallery.Selectedへの依存はシンプルなアプリには十分ですが、規模が大きくなると不安定さが増します。

varRecordへの移行

Gallery.Selectedの限界を超えるには、varRecordという変数を使う設計に切り替えます。変数の種類（グローバル変数・コンテキスト変数）については変数の使い分けも参考にしてください。

OnSelectでvarRecordに格納する

ギャラリーのOnSelectプロパティに次の1行を追加します。

UpdateContext({varRecord: ThisItem})

ThisItemはクリックされたアイテムのレコードです。これをコンテキスト変数varRecordに格納することで、「どのレコードを選んだか」を画面内で記憶できます。別の画面に遷移する場合はSetを使いグローバル変数にします。

PatchをvarRecordに切り替える

Patch関数の第2引数をGallery1.SelectedからvarRecordに変更します。

Patch(
    Employees,
    varRecord,
    {
        Title: inpTitle.Text,
        Age: Value(inpAge.Text)
    }
)

これでギャラリーの選択状態に依存しなくなります。別の画面に遷移しても、varRecordが「選んだレコード」を記憶しているので正しいレコードを更新できます。入力欄のDefaultも Gallery1.Selected.Title から varRecord.Title に変えると一貫性が保てます。

段階的な習得ロードマップ

Patch関数の習得は次の3段階で進めるのがおすすめです。

最初はDefaultsで新規作成を動かします。ハードコードで固定値を書いてPatchが動くことを確かめます。次にGallery.Selectedで更新を試します。第2引数を1か所変えるだけで更新ができる体験をすると、Patch関数の構造が一気に腹落ちします。最後にvarRecordに切り替えてギャラリーへの依存をゼロにします。複数画面のアプリや安定した動作が求められる場面で本領を発揮します。

最初からvarRecordを使おうとすると、変数の概念とPatch関数の両方を同時に理解する必要があり混乱しやすいです。Gallery.Selectedを経由して段階を踏むことで、何がどう変わったのかが理解しやすくなります。

まとめ

Patch関数の第2引数を切り替えるだけで新規作成・Gallery.Selectedによる更新・varRecordを使った安定した更新へと段階的に移行できます。新規レコード作成編と合わせて読むと、Patchの全体像が整理できます。

次のステップは複数画面にまたがる下書き保存です。varRecordをベースに、statusで提出状態を管理するパターンが必要になります。詳しくは下書き保存の実装パターンで解説しています。

更新パターンを含むPatch関数の全応用パターン——新規作成・下書き保存・SharePoint/Dataverse対応——はPatch関数応用ガイドに体系化しています。

Patchは使えば使うほど手に馴染む関数です。まずGallery.Selectedで更新を動かして、慣れたらvarRecordへ。焦らず1段階ずつ積み重ねていきましょう。

Power Appsが重い・遅いときの改善方法まとめ｜OnStart最適化・名前付き計算式・委任の3ステップ

Tue, 24 Mar 2026 22:49:25 GMT

Power Appsが重い・起動が遅いと言われたとき、原因はほぼ3つに絞られます。OnStartへの処理詰め込み、変わらないデータの毎回取得、委任の警告放置。この3つを順番に改善するだけで、アプリの起動体感は大きく変わります。

原因1：OnStartへの処理詰め込みすぎ

OnStartプロパティは、アプリが起動する前にすべての処理をブロッキング実行します。つまり、OnStartに100個の処理があれば、ホーム画面が表示されるまでその100個が全部終わるのを待つことになります。ClearCollect や Set で10個、20個の変数を定義していれば、その分だけ起動が遅くなります。

SharePointリストのキャッシュやユーザー情報の取得など、「とりあえずOnStartに書いておこう」という習慣がある方は多いと思います。私もそうでした。ただ、そのアプリが重いと言われたとき、真っ先に疑うべき場所がまさにそのOnStartです。

典型的なNG例

よくあるパターンを一つ挙げます。

ClearCollect(colDepartments, Departments)

こうしてSharePointリストをコレクションにキャッシュしているケースです。部署リストは起動中に変わらないので、OnStartでキャッシュするのは一見合理的に見えます。ところが、このコレクションをホーム画面で使わない場合でも、アプリが起動するたびにこの処理が走ります。ホーム画面に関係ないデータを取りに行くせいで、表示が遅くなっているわけです。

OnStartを残すか、名前付き計算式に移すかの判断基準

名前付き計算式（App.Formulas）は、OnStartの代替として使えるケースがあります。最大の違いは実行タイミングです。OnStartがアプリ起動時に全処理をまとめて実行するのに対して、名前付き計算式はその値が実際に必要になった瞬間に初めて計算されます。

OnStartに残すべきか、名前付き計算式に移すべきかは、次の1つの問いで判断できます。

その値は、アプリが起動した時点で確定している必要があるか？

値の種類	判断	理由
変わらないリストのキャッシュ	名前付き計算式へ移行	起動時に計算する必要がない
ユーザー情報（User関数）	名前付き計算式へ移行	変更不要・必要な画面で計算すればよい
テーマカラーの定数	名前付き計算式へ移行	変更不要・一元管理できる
深リンク処理（URLパラメーターで遷移先を決める）	OnStartのまま	起動時点で確定している必要がある
後から変更する可能性がある変数	OnStartのまま	名前付き計算式は変更不可（immutable）

移行手順：ClearCollect → 名前付き計算式

先ほどのClearCollectの例を名前付き計算式に移す手順を示します。

まずOnStartから次のコードを切り取ります。

ClearCollect(colDepartments, Departments)

次にアプリを選択した状態（App）で、上部メニューからFormulaプロパティ（日本語UIでは「計算式」）を開き、次のように書きます。

nfDepartments = Departments;

末尾のセミコロンが必須なので忘れずに。ClearCollectとは構文が違い、データソース名をそのまま右辺に書きます。あとはアプリ内でcolDepartmentsを使っていた場所をnfDepartmentsに書き換えるだけです。ギャラリーのItemsプロパティに nfDepartments と指定すれば、その画面が表示されたタイミングで初めてデータを取りに行きます。ホーム画面では計算が走らないため、起動が速くなります。

移行後に気をつけること

名前付き計算式はimmutable（変更不可）です。OnStartで Set(varUser, User()) と書いていた場合、後からボタンで Set(varUser, Blank()) と上書きできましたが、名前付き計算式では後から変更できません。書き換えが必要な値には引き続き変数を使います。

また、名前付き計算式はPower Appsの変数一覧パネルに表示されません。変数（Set/ClearCollect）と区別するために、nf というプレフィックスをつける命名ルールを採用することをおすすめします。nfUser、nfDepartments のようにしておくと、数式バーで見たときに名前付き計算式だとすぐわかります。

Concurrent関数との違い

OnStartを速くする方法として、Concurrent関数で複数の処理を並列実行するテクニックがあります。ただし、Concurrent内では処理同士がお互いを参照できないという制限があります。同じConcurrent内でnfExecutivesを先に計算してからnfExecutiveCountを計算するといった依存関係は書けません。

名前付き計算式にはその制限がありません。

nfExecutives = Filter(Employees, Department = "Executives");
nfExecutiveCount = CountRows(nfExecutives);

このようにnfExecutivesを参照するnfExecutiveCountが書けます。Power Appsが依存関係を自動で解決してくれるからです。ただし相互参照（AがBを参照し、BがAを参照する）はループになるため不可です。

名前付き計算式の構文や型別の書き方については名前付き計算式（App.Formulas）とはと名前付き計算式の書き方チートシートで詳しく解説しています。

原因2：変わらないデータを毎回取得している

都道府県リストや業種分類といった、アプリ起動後に変わらないデータを、毎回 Filter や Lookup で取得していないでしょうか。その都度データソースに問い合わせされるため、ネットワーク遅延やサーバー負荷に左右されます。

名前付き計算式でキャッシュする考え方が有効です。

nfDepartments = Departments;
nfStatusChoices = Table({Value:"申請中"},{Value:"承認済み"},{Value:"却下"});

遅延評価のため、参照されない計算式は計算されず、無駄な処理が削減されます。複数の画面で同じリストを使う場合は特に効果的で、1箇所の定義で全画面に反映されます。

原因3：委任の警告を無視している

Power Appsで赤い波線とともに表示される委任の警告を見かけたことがあります。これは、データ件数が上限（通常500件）に達するとフィルタリング結果が不完全になるという警告です。

Filter 関数を Dataverse や SharePoint に委任できる書き方に変更することで、警告を解消できます。例えば、Filter(Employees, Department = “Sales”) と書く場合、Department列がインデックス化されていれば、委任が可能になります。委任可能な関数や演算子は限定されているため、詳細は委任の警告の意味と対処法を参照してください。

まとめ：3ステップで起動を速くする

起動速度の改善は、小さな最適化の積み重ねです。OnStart の処理を名前付き計算式に移す、変わらないデータをキャッシュする、委任の警告に対応する。この順番で見直すと、アプリの応答性は大きく向上します。

まず自分のアプリの OnStart を開き、ClearCollect や Set の数を確認するところから始めてみてください。移行候補が見つかれば、体感速度の改善はすぐそこです。

Power AppsからPower Automateのフローを呼び出す。ボタン実行・値の受け渡しの基本

Mon, 16 Mar 2026 15:46:47 GMT

Power AppsからPower Automateのフローを実行する仕組みは、思っているより単純です。アプリのボタンに1行書けばフローが動き、フローの結果をアプリ側で受け取ることもできます。

最初は「AppsとAutomateを連携させる」という言葉に身構えてしまいがちですが、実際に手を動かしてみると数分で動くものができます。この記事では基本の呼び出し方と、値の受け渡し方法をまとめます。

フローをAppsから呼べる形にする

まずPower Automateで、Power Appsから呼び出せるフローを用意します。トリガーの種類は「Power Appsからのインスタント」を選びます。これを選ぶと、Apps側からフローを起動できるようになります。

トリガー選択のポイント

Power Automateのトリガーには自動型・インスタント型・スケジュール型があります。Appsから手動で呼ぶときは「インスタント」を選び、さらにその中から「Power Apps（V2）」を選択します。V2を選ぶと引数の型を明示的に定義でき、Appsから値を渡すときに扱いやすくなります。

Power Automateのトリガー種類の詳細はこちらも参考になります。

→ Power Automateのトリガーはどれを選ぶ？自動化・インスタント・スケジュールの違いを徹底解説

Power Appsから値を渡す方法

フローにAppsから値（テキストや数値）を渡すには、フローのトリガー設定でインプット引数を定義します。V2では引数の名前と型（テキスト・数値・日付など）を設定でき、Apps側の数式でその引数に値をセットします。

例えばテキスト引数を1つ渡す場合、Appsのボタン数式はこうなります。

FlowName.Run(TextInput1.Text)

引数が複数ある場合はカンマ区切りで渡します。

FlowName.Run(TextInput1.Text, Dropdown1.Selected.Value, Today())

引数の順番はフロー側で定義した順と一致させる必要があります。数式を書いた瞬間にIntelliSenseが引数の型を教えてくれるので、型不一致のエラーはわりとすぐ気づけます。

フローの結果をAppsで受け取る

フローからApps側に値を返したい場合は、フローの最後に「Power Appsに応答する」アクション（Respond to a Power App）を追加します。返す値の名前と中身を定義すると、Apps側でフローの戻り値を取り出せます。

Apps側での受け取り方はこうなります。

Set(gblResult, FlowName.Run(TextInput1.Text).resultvalue)

フロー側で返す値に result という名前をつけた場合、Apps側では .result でアクセスできます。この値を変数に格納しておけば、ラベルの表示やギャラリーの絞り込みに使えます。

非同期実行には注意

フローの実行には時間がかかることがあります。Run()は同期的に動作するため、フローが完了するまでAppsの処理は待ちます。フローが5秒・10秒かかる場合、ボタンを押してから結果が返ってくるまでアプリが止まって見えます。

長時間かかるフローにはNotify関数で「処理中」表示を出すか、アイコンのVisible切り替えでローディング状態を見せると親切です。

どんなケースで使うか

私が実務でApps→Automate連携を使うのは、主に以下のケースです。

ケース	内容
メール・Teams通知	ボタン押下で承認者にメール通知を送る
SharePointへの書き込み	複数リストへ同時に書き込む（Patchが複雑になる場合）
PDFの生成・保存	定型フォームをPDFに変換してSharePointに保存する
外部API連携	Apps単体では直接叩けないAPIをAutomateを経由して呼ぶ

特にメール・Teams通知は定番の使い方です。Appsだけではメール送信ができないので、この組み合わせが必須になります。

フローをAppsに追加する手順

Power Apps Studio（アプリの編集画面）から直接フローを紐づけられます。手順は次のとおりです。

Power Apps Studioで編集中のアプリを開く
左メニューの「Power Automate」アイコンをクリック
「フローを追加」から使いたいフローを選択する
フローが追加されると数式バーで .Run() が使えるようになる

フローが表示されない場合は、フロー側のトリガーが「Power Apps（V2）」になっているか確認してください。他のトリガーのフローはこのリストに出てきません。

Power Automateの全体像は入門記事でまとめています。連携の前に基礎を確認したい方はこちらをどうぞ。

→ Power Automate入門——変数・データ処理・通知・デバッグの全体マップ

まとめ

Power AppsからPower Automateを呼び出すのは、FlowName.Run() の1行で完結します。引数で値を渡し、Respond to a Power Appで結果を受け取る、という流れが基本パターンです。

AppsとAutomateを組み合わせると、アプリ単体では難しいメール通知・PDF生成・外部連携ができるようになります。どちらか一方に閉じて考えずに、得意なことを分担させる設計ができると業務改善の幅がぐっと広がります。

Power Apps でスマートフォン・タブレットにプッシュ通知を送る｜NotificationsV2 + Deep Link 完全解説

Sun, 05 Apr 2026 10:18:35 GMT

Power Apps からスマートフォンにプッシュ通知を送ることができます。メールや Teams とは異なる即時性とアプリへの直接誘導が最大の特徴で、タイムシートの催促・承認依頼など、相手にすぐ行動を促したい場面で力を発揮します。

Power Apps のプッシュ通知でできること

Power Apps のプッシュ通知は、スマートフォン・タブレット・スマートウォッチの OS ネイティブ通知として表示されます。iPhone であれば画面上部にバナーとして出てきて、タップするとそのまま Power Apps アプリが起動する仕組みです。

私が一番重宝しているのがDeep Link（ディープリンク）という機能です。通知にパラメーターを埋め込んでおくことで、特定のレコードを開いた状態でアプリを起動する動作が実現できます。承認フローで申請書番号を通知に乗せれば、受け取った担当者がタップするだけで該当レコードを即確認できる。これだけで業務のスピードがかなり変わります。

メール・Teams 通知との違いをまとめると次の表の通りです。

通知手段	即時性	アプリ起動	リッチな文面	向いているシーン
プッシュ通知	◎	直接起動	△	承認催促・タスク割り当て・緊急連絡
Teams 通知	◯	△	◯	チーム全体への周知・定期レポート
Outlook メール	△	×	◎	詳細説明が必要・外部関係者への連絡

大前提：端末への Power Apps アプリインストール

プッシュ通知を受け取るためには、受信者の端末にPower Apps モバイルアプリがインストールされており、一度でもログインしていることが必要です。アプリを日常的に使っていなくても通知は受け取れますが、インストール自体は省略できません。

社内展開時に地味にはまるのがここです。アプリを使っていない人には届かないのではなく、モバイルアプリが入っていない人には届かないという違いを、展開前に全員に説明しておく必要があります。私の職場でも、プッシュ通知を本番運用する前にモバイルアプリの初期セットアップを全員に案内するステップを踏みました。

フロー作成は旧デザイナーで行う

Power Automate でプッシュ通知の送信 V2（Send push notification V2）アクションを使う際は、必ず旧デザイナーを使って作成してください。新デザイナーでは「object, object」というエラーが発生する既知バグがあり、現時点では正常に動作しません。

旧デザイナーへの切り替えは、フロー編集画面右上の新しいデザイナートグルをオフにするだけです。フロー作成後は新デザイナーで表示できる場合もありますが、最初の作成時は必ず旧デザイナーを使うのが安全です。このあたりの仕様は Microsoft が随時改善中なので、将来的には制約がなくなる可能性もありますが、現時点では旧デザイナー一択です。

フローの基本構成：Power Apps V2 トリガー＋3つの入力

フローのトリガーにPower Apps V2を使い、3つのテキスト入力を追加します。

MyMessage：通知のメッセージ本文
MyNotify：通知を送る相手のメールアドレス
MyParam：Deep Link 用のパラメーター値

名前は任意ですが、用途が伝わるネーミングにしておくと後から見直したときも迷いません。Power Automate の変数・入力値の命名は、チームで運用するならルールを統一しておくと管理が格段に楽になります。

プッシュ通知の送信 V2アクションの設定

フローにプッシュ通知の送信 V2アクションを追加します。最初に Field Service / Power Apps / Sales の3択が表示されますが、Power Appsを選択してください。

設定する主な項目は次の通りです。

Mobile app：対象の Canvas App をドロップダウンから選択
Recipients：["通知先メールアドレス"] の形式で指定。動的コンテンツから MyNotify を選んだ後、角括弧で囲む
Message：動的コンテンツの MyMessage を選択
Open app：Yes（通知タップ時にアプリを起動する）

Recipients の JSON 配列がやや特殊なポイントです。セミコロン区切りではなく、配列の要素として複数のメールアドレスを入れることで一斉送信できます。承認者が3名いる場合は ["aaa@company.com","bbb@company.com","ccc@company.com"] のように書きます。

Deep Link の仕組みと varRecord 必須の前提

Deep Link とは、プッシュ通知にパラメーターを埋め込み、通知タップ時に特定のレコードを開いた状態でアプリを起動する仕組みです。アクションの Parameters フィールドに次の形式で JSON を渡します。

{"cal": "@{triggerBody()?['text_3']}"}

Power Apps 側の App.OnStart でパラメーターを受け取ります。

Set(varParam, Param("cal"))

ここで重要な前提があります。フォームコントロールの Item プロパティを Gallery.Selected ではなく varRecord に設定しておくことが必須です。

理由は Gallery.Selected が画面遷移後にリセットされるからです。通知をタップしてアプリを起動した場合、ギャラリー画面を経由せずに直接フォーム画面が開くため、Gallery.Selected には何も入っていない状態になります。varRecord 変数にレコードを格納しておく設計にすることで、Deep Link 経由でもフォームが正しく機能します。変数を活用したギャラリーとフォームの連携についてはギャラリーと varRecord を組み合わせたフォーム連携の記事も参考にしてください。

Power Apps 側の実装：フロー呼び出しと Publish

Power Apps のボタンから先ほどのフローを呼び出します。ボタンの OnSelect に次のように記述します。

MyNotifyFlow.Run(
    "タイムシートが未提出です。本日中に提出してください。",
    InputEmail.Text,
    Text(ThisItem.ID)
)

3つの引数はそれぞれ MyMessage・MyNotify・MyParam に対応しています。メッセージ本文をハードコードしてもよいですし、TextInput コントロールの入力値を渡すこともできます。

ひとつ見落としやすい注意点があります。フローを呼び出す前にアプリを Publish（公開）しておかないと最新版のフロー連携が動きません。アプリを保存しただけでは不十分で、公開ボタンを押して公開済みバージョンを更新しておく必要があります。変更を加えるたびに公開し直す習慣をつけておくと、なぜか古い動作をするという混乱を防げます。

Power Automate フローを Power Apps から呼び出す基本的な流れは、Power Apps から Power Automate を呼び出す基礎の記事で詳しく解説しています。フロー連携が初めての方は先にこちらを確認しておくとスムーズです。

コネクタ直接通知の現状

Power Apps のデータからPower Apps 通知コネクタを追加することで、フロー不要で直接通知を送る方法もあります。ただし、V2 コネクタの正確な構文は現時点では公式ドキュメントにも正確に記載されておらず、生成 AI に聞いても古い V1 の情報が返ってくることが多い状態です。

V1 は動作しますが非推奨になっています。安定して使えるのはフロー経由の V2だけなので、新規実装は本記事で解説したフロー経由の方法を選んでください。V1 のコネクタは既存フローで動いていても、将来的に廃止される可能性があります。

Power Apps からだけじゃない：スケジュール実行でも使える

プッシュ通知は Power Apps のボタンを押したときだけ送れると思っている方も多いのですが、そんなことはありません。スケジュールトリガーや他の自動フローからでもプッシュ通知の送信 V2アクションは呼び出せます。

毎朝8時に SharePoint リストをチェックして、タイムシートが未提出の担当者にだけ通知を送る、というフローは実用性が高く、私の職場でも実際に動いています。Power Apps を起動していない人に対しても確実に届く通知として重宝しています。5名のチームで運用したところ、タイムシートの回収が大幅に楽になりました。

個人への直接的なアクション誘導にはプッシュ通知、チームへの一斉周知には Teams がそれぞれ向いています。Power Automate での Teams 自動通知の設定方法と合わせて、用途に応じて使い分けてください。

まとめ

Power Apps のプッシュ通知は、設定の手間はやや大きいですが、それだけの価値がある機能です。特に Deep Link と組み合わせることで、通知を受け取ってタップするだけで該当レコードを確認・承認できる体験は、業務効率を確実に変えます。

まずはシンプルなボタンを押したら1人に通知から始めて、動作確認ができたら Deep Link やスケジュール実行に発展させていくのがスムーズな進め方です。モバイルアプリのインストールを社内で先に展開しておくことを忘れずに。

メール・Teams・プッシュ通知それぞれの使い方を組み合わせれば、Power Apps / Power Automate からのアウトプット手段は一通り揃います。Power Apps / Power Automate のアウトプット完全ガイドで全パターンを俯瞰しておくと、次に何を使うかの判断がしやすくなります。

Power AppsのReplaceとSubstituteはどう違う？使い分けを解説

Sun, 22 Mar 2026 11:17:27 GMT

Power Appsには文字列を置換する関数が2つあります。ReplaceとSubstituteです。結論から言うと、ほぼSubstituteを使えば問題ありません。Replaceが必要になるケースは限定的です。この記事ではその違いと使い分けを整理します。

Replaceの仕組みと使いどころ

Replaceは、文字列の特定の位置から指定した文字数を別の文字列に置き換える関数です。引数は4つあります。

Replace(テキスト, 開始位置, 文字数, 置換後の文字列)

たとえば「ABCDE」の2文字目から3文字分を「XYZ」に置き換える場合、次のように書きます。

Replace("ABCDE", 2, 3, "XYZ")
// 結果：AXYZЕ

位置番号で指定するため、対象の文字列が変わると意図しない箇所を置き換えてしまうリスクがあります。データが固定長のコードや番号でなければ、Replaceは扱いにくい関数です。私の現場では、郵便番号のハイフンをなくす処理など、文字の位置が必ず決まっているときにしか使いません。

Substituteの仕組みと使いどころ

Substituteは、文字列の中から特定の文字列を検索して別の文字列に置き換える関数です。位置指定ではなく、文字列を直接指定します。

Substitute(テキスト, 検索する文字列, 置換後の文字列 [, インスタンス番号])

たとえば「Power Apps Tips」の「Tips」を「ガイド」に置き換えるには次のように書きます。

Substitute("Power Apps Tips", "Tips", "ガイド")
// 結果：Power Apps ガイド

対象の文字列が何文字目にあるかを気にしなくていいため、動的なデータへの適用に強いです。SharePointリストのデータでも、テキスト入力の値でも、同じ書き方で対応できます。

ReplaceとSubstituteの比較

	Replace	Substitute
指定方法	開始位置と文字数	置き換えたい文字列
動的データへの対応	弱い（位置が変わると壊れる）	強い（文字列を検索して置換）
複数箇所の置換	1箇所のみ	全箇所またはn番目を指定可能
向いているケース	固定長コード・番号の特定位置	ほぼすべての置換ケース

Substituteの第4引数にインスタンス番号を指定すると、同じ文字列が複数ある場合でもn番目だけを置換できます。たとえば「AAA」の2番目の「A」だけを「B」にするといった使い方です。

Substitute("AAA", "A", "B", 2)
// 結果：ABA

実例3パターン

文字列の単語置換（Substitute）

テキスト入力で入力された文章の中から、特定の単語を別の表現に統一する場面です。たとえば入力フォームに「お客様」と「顧客」が混在している場合、Substituteで一方に統一できます。

Substitute(TextInput1.Text, "顧客", "お客様")

Patchで保存する直前にこの処理を噛ませておくと、SharePointリストのデータを統一した表記で管理できます。Patchの使い方はこちらの記事で解説しています。

位置指定置換の動作確認（Replace）

たとえば社員コードが必ず8文字固定で、3文字目と4文字目が部署コードになっている場合、その部分だけをReplaceで書き換えることができます。

Replace(TextInput_EmpCode.Text, 3, 2, "01")

このようにデータの構造が完全に固定されていない限り、Replaceは使わないほうが安全です。

特殊文字の標準化（Substitute）

SharePointリストの全角スペースと半角スペースが混在しているデータを、半角スペースに統一する処理もSubstituteで対応できます。

Substitute(ThisItem.氏名, "　", " ")

SharePointのデータ操作についてはSharePointリストのCRUDパターンも参考にしてください。

まとめ：迷ったらSubstitute

ReplaceとSubstituteの使い分けは、一言で言えば迷ったらSubstituteです。Replaceが活きるのは、データの文字位置が完全に固定されていると保証できるケースに限ります。それ以外はSubstituteを選んでおくほうが、データが変化しても壊れにくいアプリになります。

スペースの除去にはTrimやTrimEndsが適しています。TrimとSubstituteを組み合わせて使う場面も多いので、あわせて覚えておくと便利です。TrimとTrimEndsの使い方はこちらの記事で紹介しています。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

少し地味な関数ですが、データ整形の場面で頼りになります。積極的に使っていきましょう。

Power Apps で下書き保存を実装する｜複数画面・status列・条件付きPatchの設計パターン

Sun, 29 Mar 2026 19:06:11 GMT

複数画面にまたがる入力フォームで「途中まで入力して後で続ける」を実現したいなら、下書き保存の仕組みが必要です。難しそうに見えますが、status列・varRecord・条件付きPatchの3つを押さえれば実装できます。

下書き保存が必要なシーン

下書き保存が必要になるのは、現場での点検入力で途中に呼び出しが入るケース、複数画面にまたがる申請フォームで一度に全部入力できないケース、承認フローに回す前に内容を確認しながら段階的に埋めたいケースなどです。

いずれも共通しているのは「入力途中の状態を安全に保持したい」という要件です。フォームを閉じてもデータが消えず、次回開いたときに続きから始められることが求められます。アプリの変数だけで管理しようとすると、アプリを閉じた瞬間に状態が消えてしまいます。これを防ぐためにデータソース側にstatus列を持たせます。

status列をテーブルに追加する

下書き保存の核心はstatus列です。SharePointリストやDataverseテーブルに「draft / open / in progress / closed」のような選択肢を持つ列を追加します。アプリのユーザーはこの列を直接触る必要はありません。あくまでアプリ側が制御するための内部管理列です。

なぜこの列が必要かというと、「このレコードがまだ提出されていない」という状態をデータ側で識別するためです。列があることで「draft状態のレコードだけギャラリーに編集アイコンを出す」「draftでないレコードはすべて入力不可にする」といった分岐ができます。

新規ボタンでdraftレコードを即座に作成する

新規ボタンが押されたタイミングで、空のdraftレコードをその場で作成します。そのレコードをvarRecordに格納することが大切です。

Set(
    varRecord,
    Patch(
        IncidentManagement,
        Defaults(IncidentManagement),
        { Status: Status.Draft }
    )
);
Navigate(InfoAndCategoryScreen)

Patch関数は成功すると作成されたレコードを返します。それをSetでvarRecordに格納するのがポイントです。これにより「今どのレコードを編集しているか」が全画面で共有されます。

Navigateはセミコロンで繋いでPatchの後に書きます。先にNavigateを書くとPatchが完了する前に画面が切り替わるため、必ずPatch→Navigateの順番を守ってください。Patch関数の返り値をSetで受け取るパターンは既存レコード更新編のvarRecordとも共通する設計です。

画面遷移ボタンでPatch→Navigateの順に実行する

各画面の「次へ」ボタンにはPatchとNavigateをセットで書きます。statusはまだdraftのままです。変えるのはそのページで入力した列だけです。

Set(
    varRecord,
    Patch(
        IncidentManagement,
        varRecord,
        {
            Title: inpTitle.Text,
            Description: inpDescription.Text,
            Category: ddCategory.Selected.Value
        }
    )
);
Navigate(LocationAndPriorityScreen)

「Patchして変数を更新してからNavigate」という構造が全ページ共通です。PatchはvarRecordを返すので、Setで再びvarRecordに格納することで変数が常に最新状態に保たれます。

戻るボタンも基本的に同じ構造です。ただし「draftのときだけPatchする」という条件分岐を追加する必要があります。これは次のセクションで解説します。

draftのときだけPatchする条件分岐

提出済みのレコードを閲覧モードで開いているとき、「次へ」ボタンを押してもPatchが走ると不要なデータ変更が発生します。これを防ぐには、PatchをIf文で囲んでdraftのときだけ実行します。

If(
    varRecord.Status = Status.Draft,
    Set(
        varRecord,
        Patch(
            IncidentManagement,
            varRecord,
            { Title: inpTitle.Text }
        )
    )
);
Navigate(LocationAndPriorityScreen)

NavigateはIf文の外に置きます。これにより、draft以外のレコードを閲覧しているときもボタンで画面遷移はできます。Patchだけがdraftのときに限定されます。全ての「次へ」ボタンと「戻る」ボタンにこのパターンを適用します。

送信ボタンはstatusをopenに変えるだけ

最終画面の送信ボタンはシンプルです。途中画面でデータは全部保存済みなので、最終画面ではstatusをopenに変更するだけで済みます。

Patch(
    IncidentManagement,
    varRecord,
    { Status: Status.Open }
);
Navigate(WelcomeScreen)

全列を再度Patchする必要はありません。statusを1列だけ更新してホーム画面に戻ります。これでそのレコードはdraftではなくなるので、次回ギャラリーで開いても閲覧モードになります。

ギャラリーでdraftと非draftを見た目で区別する

一覧ギャラリーのアイコンをstatus別に切り替えると、どのレコードが編集可能かが一目でわかります。

// ギャラリー内のIconプロパティ
If(
    ThisItem.Status = Status.Draft,
    Icon.Edit,
    Icon.View
)

draftには鉛筆アイコン、提出済みには目のアイコン。これだけで「編集できるかどうか」が視覚的に伝わります。色分けを加えるとさらに直感的になります。OnSelectは両方とも共通で「varRecordにThisItemを格納してNavigate」でよいです。

表示専用モードを1か所でコントロールする

提出済みのレコードを開いたとき、全フィールドを入力不可（閲覧のみ）にする必要があります。全コントロールのDisplayModeに同じ式を書くのは非効率なので、1つのコントロールだけに式を書いて、他はそれを参照させます。

// inpTitle のDisplayModeプロパティ（ここだけ式を書く）
If(
    varRecord.Status = Status.Draft,
    DisplayMode.Edit,
    DisplayMode.Disabled
)

// 他のすべてのコントロールのDisplayModeプロパティ
inpTitle.DisplayMode

このやり方だと50個のフィールドがある画面でも変更箇所は1か所だけです。status判定ロジックを後から変えたくなったときも修正が1か所で済みます。これは地味ですが保守性を大きく上げるテクニックです。1コントロールにロジックを集約してほかはそれを参照するという考え方は、変数の一元管理と同じ発想です。

応用：空白ドラフトのクリーンアップ

新規ボタンを押してそのまま何も入力せずホームに戻ると、タイトルすら入力されていない空白のdraftレコードがテーブルに残ります。これを放置するとデータが汚れるので対処が必要です。

1つ目はギャラリーのItemsでFilter関数を使い、タイトルが空のdraftを非表示にする方法です。

Filter(
    IncidentManagement,
    Title <> "" || Status <> Status.Draft
)

2つ目はホームへの戻るボタンでRemoveIfを使い、空白draftを物理削除する方法です。確実にデータをきれいに保てますが、誤操作で入力途中のレコードが消えるリスクも考慮が必要です。どちらを選ぶかはアプリの要件次第ですが、まずはFilter方式から試すのが安全です。

まとめ

下書き保存の実装はstatus列・varRecord・条件付きPatchの3点が核心です。複雑に見えますが、「新規作成でdraftレコードを作る→途中画面でdraftのままPatch→送信時にopenに変える」という流れに沿ってコードを書けば整理できます。

下書き保存を含むPatch関数の応用パターン全体はPatch関数応用ガイドでまとめています。各テーマの詳細解説へのリンクもそちらから辿れます。

Patch関数の基本がまだ不安な方は新規レコード作成編や既存レコード更新編を先に読んでおくとスムーズです。下書き保存はPatchと変数の組み合わせの最も実践的な応用例です。一度作れてしまえば、どんな複雑な入力フォームでも同じパターンで対応できます。

Power Apps でスケジュールを色別にわかりやすく表示する

Fri, 01 Nov 2024 21:21:34 GMT

リストにある予定に合わせて Power Apps上で色をつけて視覚的にわかりやすく表示する方法を紹介します。

全体の概要

準備するものはこちら。

Power Appsキャンバスアプリ
祝日を入力したリスト
Outlookの予定を記載したリスト

Power Appsには残念ながら日本の祝日を判断させる機能がありません。

2の祝日リストは、あらかじめ祝日だけをまとめたリストを作成しておきます。

会社指定の休暇日がある場合、まとめて入れておきます。

独自の休暇がある場合も入れておく（2月22日）

3のリストについては、こちらで紹介したOutlookの予定を自動的にリストにコピーするものを使用します。

https://shiminkaihatsu.com/pa_outlookschedule_listcopy/

このアプリの見た目は次のように仕上がります。

名前は仮名

一番左に氏名、予定は本日を含めて6日間分を表示します。

表示する予定の項目は1種類のみです。

色で見た目を区別しますので、視覚的に情報が入りやすくなっています。

ちなみにこのアプリは、会社で出社人数を一目で把握するために私が作成したものの一部です。

アプリの概要はこちらから御覧ください。

https://shiminkaihatsu.com/scheduleapps/

グローバル変数

最初に色や用語を定義しておくため、OnStartプロパティに次の式を入れておきます。

Set(
    globalVars,
    {
        //表示させる名称
        dayoff: "休", //休
        holiday: "祝日", //祝日
        goingToOffice: "出社", //出社
        telework: "TW", //テレワーク
        businesstrip: "出張", //出張

        //表示させる色
        bgcolor_weekends: Color.LightGray, //土日をライトグレー
        bgcolor_dayoff: Color.LightGray, //休暇をライトグレー
        bgcolor_holiday: Color.LightGray, //祝日をライトグレー
        bgcolor_telework: Color.Blue, //テレワークを青
        bgcolor_businesstrip: Color.Green, //出張をライト緑
        bgcolor_others: Color.Red, //それ以外（出社）を赤

        //各種条件
        teleworkList: ["テレ", "TW", "ＴＷ","リモート", "WFH", "ｔｗ", "ﾃﾚ", "tele"],
        vacationList: ["休暇", "有給", "公休", "欠勤", "年休", "代休"],
        holidayList: ["祝日"],
        businessTripList: ["出張"]
    }
);

ClearCollect(colHoliday, '祝日年休リスト');
ClearCollect(colMoriya, '守屋スケジュール'),

Set(StartDate0, Now()); //今日
Set(StartDate1, DateAdd(Now(), 1, TimeUnit.Days)); //明日
Set(StartDate2, DateAdd(Now(), 2, TimeUnit.Days)); //明後日
Set(StartDate3, DateAdd(Now(), 3, TimeUnit.Days)); //明後日+1
Set(StartDate4, DateAdd(Now(), 4, TimeUnit.Days)); //明後日+2
Set(StartDate5, DateAdd(Now(), 5, TimeUnit.Days)); //明後日+3

ここではOnStartを使っていますが、本来はFormulaで定義するほうが動作が軽くなるのでおすすめです。

グローバル変数にオブジェクトを格納することで、こういう書き方ができます。

使い方は、例えばLabelのTextプロパティに globalVars.dayoff といれると「休」と表示されます。

中身を簡単に説明します。

表示させる名称・表示させる色

予定に表示したい名称と色を自由に設定します。

各種条件

配列で条件を設定します。

もし予定件名の中に配列のキーワードを含む場合、条件に合う名称と色を表示する、という流れです。

Label1.Text in globalVars.teleworkList のように in と一緒に使います。

ClearCollect

祝日リストと予定リストをコレクションに格納します。

StartDate

6日分の日付をそれぞれ変数に入れます。

これは後述する条件式の中で使います。

スケジュールのパーツ

予定を表示するパーツは全てLabelを使いますので、1人7つLabelがあります。

それをグループ化してまとめています。

※ Galleryを使うともっと少ないパーツで表現できると思われます。

※ グループよりコンテナのほうが使い勝手が良いです。

名前Labelはベタ打ちで人の名前を入れます。

1つ目の予定LabelのTextプロパティには次の式を入れます。

If(
    // 土曜日または日曜日の条件
    Weekday(StartDate0) = 7 || //土
    Weekday(StartDate0) = 1, //日
    "休",
    
    // 祝日年休リストのDateとの一致条件
    !IsBlank(LookUp(colHoliday,  Text(DateTimeValue(Date), "yyyy/m/d") = Text(StartDate0, "yyyy/m/d"))),
    "休",

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.vacationList, Value in Title))
        )
    ),
    globalVars.dayoff,  // 休暇なら休

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.teleworkList, Value in Title))
        )
    ),
    globalVars.telework,  // テレワークならTW

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.businessTripList, Value in Title))
        )
    ),
    globalVars.businesstrip,  // 出張なら出張
    globalVars.goingToOffice  // 上記のいずれにも該当しない場合は出社
)

Fillプロパティは次の式です。

If(
    // 土曜日または日曜日
    Weekday(StartDate0) = 7 || //土
    Weekday(StartDate0) = 1, //日
    globalVars.bgcolor_weekends,
    
    // 祝日年休リストのDateとの一致条件
    !IsBlank(LookUp(colHoliday, Text(DateTimeValue(Date), "yyyy/m/d") = Text(StartDate0, "yyyy/m/d"))),
    globalVars.bgcolor_holiday,

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.vacationList, Value in Title))
        )
    ),
    globalVars.bgcolor_dayoff,


    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.teleworkList, Value in Title))
        )
    ),
    globalVars.bgcolor_telework,

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.businessTripList, Value in Title))
        )
    ),
    globalVars.bgcolor_businesstrip,
    globalVars.bgcolor_others // 上記の条件に一致しない場合
)

If関数を使って式を上から順に判断し、条件に合致するときにTextとFillをグローバル変数で決めた値に動的に変化させます。

わかりやすくまとめると、次の流れです。

関数の解説

If(
    // 土曜日または日曜日の条件
    Weekday(StartDate0) = 7 || //土
    Weekday(StartDate0) = 1, //日
    "休",

最初の条件は土・日の判断です。

Weekday関数は曜日を取得します。

OnStartでグローバル変数StartDateを次のように設定しました。

Set(StartDate0, Now()); //今日
Set(StartDate1, DateAdd(Now(), 1, TimeUnit.Days)); //明日
Set(StartDate2, DateAdd(Now(), 2, TimeUnit.Days)); //明後日
Set(StartDate3, DateAdd(Now(), 3, TimeUnit.Days)); //明後日+1
Set(StartDate4, DateAdd(Now(), 4, TimeUnit.Days)); //明後日+2
Set(StartDate5, DateAdd(Now(), 5, TimeUnit.Days)); //明後日+3

Weekday(StartDate0)、つまり当日の曜日が7（土曜日）、1（日曜日）なら強制的に休が表示され、If関数はそこで処理を終えます。

    // 祝日年休リストのDateとの一致条件
    !IsBlank(LookUp(colHoliday,  Text(DateTimeValue(Date), "yyyy/m/d") = Text(StartDate0, "yyyy/m/d"))),
    "休",

続いて祝日（社の特別休暇含む）の判断は、祝日年休リスト（colHoliday）を使います。

colHolidayのDate列の日付とStartDate0をText値として比較し、一致するものがある場合、つまり当日が祝日なら休表示になります。

日付をText値で比較するのは、もし片方の日付が時刻を含む型の場合、不一致でエラーが出るのを防止するためです。

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.vacationList, Value in Title))
        )
    ),
    globalVars.dayoff,  // 休暇なら休

次は有給や病欠による休暇を判断します。

&& で繋いでいますので、同時に2つの条件を満たす場合に globalVars.dayoff、つまり休が表示されます。

1つ目の条件は、予定リスト（colMoriya）のDateTime列とStartDate0をText値で比較して一致すること。

2つ目の条件は、予定リスト（colMoriya）のTitleの中に、配列vacationListで定めたキーワードを含むこと。

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.teleworkList, Value in Title))
        )
    ),
    globalVars.telework,  // テレワークならTW

    !IsEmpty(
        Filter(
            colMoriya,
            Text(DateTime, "yyyy/m/d") = Text(StartDate0, "yyyy/m/d") &&
            !IsBlank(LookUp(globalVars.businessTripList, Value in Title))
        )
    ),
    globalVars.businesstrip,  // 出張なら出張
    globalVars.goingToOffice  // 上記のいずれにも該当しない場合は出社
)

TWと出張の表示も、考え方は同じです。そしていずれのケースにも該当しない場合、出社表示が適用されます。

ご自身の環境に合わせて判断の順番や表示値を変更してください。

TextとFillの関数は、基本的構造は同じです。

これで1日目（当日）の予定表示ができるようになったので、2日目以降も同様に設定します。

明日はStartDate1ですので、全てのStartDate0をStartDate1に書き換えます。

明後日も同様にStartDate2に書き換え、これを6日目まで繰り返し、ようやく1人分の予定が完成です。

人数を増やす場合は全体をコピーし、好みの位置に配置します。

増えた分だけスケジュールリストやコレクションを追加することを忘れないようにしましょう。

Power Apps から Outlook でメールを送信する｜SendEmailV2・添付・HTML・宛先複数選択の全パターン

Sun, 05 Apr 2026 10:18:37 GMT

Power Apps から Outlook でメールを送信したいとき、Power Automate のフローは不要です。Office 365 Outlook コネクタをデータソースに追加するだけで、宛先の複数選択・HTML 装飾・添付ファイル付きの本格的なメール送信がアプリ単体で実現します。

Office 365 Outlook コネクタの追加

Power Apps Studio のデータメニューから「コネクタ」→「Office 365 Outlook」を追加します。ここで注意したいのは、個人用の Outlook.com コネクタと間違えないことです。職場・学校アカウントで使える Exchange Online に接続するコネクタを選んでください。追加が完了すれば、フローなしにアプリ内から直接メールを送れるようになります。

このコネクタは Power Apps の Premium コネクタではなく、Microsoft 365 のライセンスがあれば追加費用なしで利用できます。Power Automate を使わなくてよい分、アプリの設計がシンプルになり、送信ロジックをアプリ内に完結させられます。メール送信以外の通知手段についてはPower Automate Teams 通知の設定方法も参考にしてください。

SendEmailV2 関数の基本構文

ボタンの OnSelect プロパティに次のように書きます。

Office365Outlook.SendEmailV2(
    "recipient@example.com",
    "件名テキスト",
    "本文テキスト"
)

必須引数は To・Subject・Body の 3 つだけです。V2 を使う理由は、V1 が廃止予定のためです。数式の候補に V1 と V2 の両方が出てくるため、必ず V2 を選ぶようにしてください。V1 で作ったアプリは将来動かなくなる可能性があります。

To（宛先）の書き方パターン

宛先の指定方法は用途によって使い分けます。主なパターンは次のとおりです。

パターン	記述例	用途
ハードコード	“user@example.com”	固定の宛先（通知先など）
セミコロン区切り	“a@example.com;b@example.com”	複数宛先を固定で指定
ログインユーザー	User().Email	自分自身への送信・確認メール
入力値	TextInput1.Text	画面で宛先を入力させる場合

複数宛先を動的に選択させたい場合はコンボボックスを使います。詳細は後述します。

Body の HTML 対応

HTML タグを Body に直接書く

Body 引数に HTML タグをそのまま書くと、装飾されたメールが届きます。

Office365Outlook.SendEmailV2(
    TextInput_To.Text,
    TextInput_Subject.Text,
    "<h2>申請が届きました</h2><p>申請者：<strong>" & User().FullName & "</strong></p>"
)

<h1>・<strong>・<p>・<ul> など標準的な HTML タグが使えます。テキストと HTML のどちらも渡せるので、シンプルな通知メールにも装飾が必要なレポートメールにも対応できます。

リッチテキストエディタを使う

画面上でユーザーが太字・色付け・見出しを入力できるようにしたい場合は、リッチテキストエディターコントロールを使います。Body に RichTextEditor1.HtmlText を渡すだけで、ユーザーが書式設定した内容をそのまま HTML メールとして送れます。

CC・BCC・重要度などのオプション引数

必須 3 引数の後にコンマを打ち、波括弧 {} でオプションを追加します。

Office365Outlook.SendEmailV2(
    "to@example.com",
    "件名",
    "本文",
    {
        Cc: "cc@example.com",
        Bcc: "bcc@example.com",
        Importance: "High"
    }
)

Importance は “High” / “Normal” / “Low” の文字列で指定します。Sensitivity（秘密度）は GUID が必要で複雑なため、通常は使いません。オプション引数は必要なものだけを波括弧の中に入れる書き方で、不要なものは省略できます。

添付ファイルを送信する

フォームの添付コントロールを流用する

Power Apps の Insert メニューには Attachment コントロール単体が存在しません。フォームコントロールを画面に追加すると内部に Attachment コントロールが含まれており、これを流用するのが最も簡単な方法です。

RenameColumns での列変換が必須

Attachment コントロールのデータは AddMediaButton1.Attachments などで取得できますが、列名が Value になっています。SendEmailV2 の Attachments 引数が期待する列名は ContentBytes です。そのため RenameColumns() で変換する必要があります。

Office365Outlook.SendEmailV2(
    "to@example.com",
    "添付あり",
    "本文",
    {
        Attachments: RenameColumns(
            AttachmentControl1.Attachments,
            "Value", "ContentBytes"
        )
    }
)

この RenameColumns を忘れると、添付ファイルが送信されないか、エラーになります。添付を実装するときに最も見落としやすいポイントです。

From（差出人変更）と ReplyTo の設定

From（差出人変更）を使うには、Exchange 側で対象アカウントへの「代理送信」権限が IT 管理者によって設定されている必要があります。権限がない状態で From を指定してもエラーになります。

ReplyTo はサポートデスクのメーリングリストなど、返信先を別のアドレスにしたい場面で便利です。From 権限は不要なので、一般ユーザーでも気軽に使えます。

コンボボックスで宛先を複数選択する

社内ユーザーを検索して複数の宛先を選べる UI を作るには、Office 365 Users コネクタとコンボボックスを組み合わせます。

データソースに「Office 365 Users」コネクタを追加する
ComboBox の Items に Office365Users.SearchUserV2({searchTerm: Self.SearchText, top: 10}).value を設定する
ComboBox の DisplayFields に ["DisplayName"]、SearchFields に ["DisplayName", "Mail"] を設定する
SendEmailV2 の To に Concat(ComboBox1.SelectedItems, Mail, ";") を渡す

Concat 関数の第3引数にセミコロンを指定することで、複数選択されたメールアドレスをセミコロン区切りの文字列に変換できます。これが SendEmailV2 の複数宛先形式と一致します。

Power Automate を使わない意義

Power Automate 経由でメールを送る方法は多くの記事で紹介されていますが、Office 365 Outlook コネクタを使えばフローが不要です。コネクタ追加だけで「宛先検索・CC/BCC・複数添付・HTML 装飾」のフル機能を実現できます。フローを作らない分、設計がシンプルになり、トラブルシューティングも容易になります。

Power Apps から Power Automate を呼び出す連携パターンについてはPower Apps からフローを呼び出す基礎記事で解説しています。メール送信に限らず、より複雑な処理が必要な場面ではフロー連携を使い分けるとよいでしょう。アウトプット系アクションの全体像についてはPower Apps / Power Automate アウトプット完全ガイドで整理しています。

まとめ

Office 365 Outlook コネクタと SendEmailV2 関数を組み合わせれば、Power Apps 単体で本格的なメール送信が実現します。To・Subject・Body の 3 引数を押さえたら、HTML 装飾・添付ファイル・コンボボックスでの複数宛先選択へと順番に機能を拡張していきましょう。RenameColumns の変換を忘れずに、という点だけ頭に入れておけば、実装で詰まることはほとんどなくなります。

Power AppsでSharePointリストのデータを読み書きする。基本のCRUDパターン

Mon, 16 Mar 2026 15:46:50 GMT

Power AppsでSharePointリストのデータを読み書きするには、Filter関数・Patch関数・Remove関数の3つを使いこなすことが基本です。この記事では、一覧表示・追加・更新・削除という4つの操作（CRUD）を整理します。

CRUDとは

CRUDとは Create（追加）・Read（読み込み）・Update（更新）・Delete（削除）の頭文字です。データを扱うアプリで必ず必要になる4つの操作をまとめた言葉です。Power Appsでは、この4つをほぼすべてギャラリーとPatch関数・Remove関数で実装します。

SharePointリストとPower Appsの組み合わせは相性がいいです。追加や更新の処理がPatch関数1行で書けるため、コードが複雑になりません。Excelをデータソースにするよりも委任の制約が少なく、複数人の同時編集にも対応しています。SharePointリストの基本的な使い方はSharePointリストとMicrosoft Listsの解説で整理しているので参照してください。

Read——データの読み込みと一覧表示

ギャラリーで一覧表示する

SharePointリストのデータを画面に一覧表示するにはギャラリーコントロールを使います。ギャラリーのItemsプロパティにデータソース名を指定するだけで、リストの全件が表示されます。

Items = SharePointリスト名

絞り込みを行いたい場合はFilter関数を使います。例えばステータスが「未完了」のものだけを表示するには次のように書きます。

Filter(タスク管理リスト, ステータス = "未完了")

検索ボックスと組み合わせてキーワード検索にしたい場合はSearch関数が使えます。Filter・Search・LookUpの使い分けはFilter・Search・LookUp関数の解説にまとめています。

Create——データの追加

Patch関数でレコードを新規作成する

新しいレコードをSharePointリストに追加するにはPatch関数を使います。第1引数にデータソース、第2引数にDefaults関数を指定することで新規レコードとして扱われます。

Patch(
    タスク管理リスト,
    Defaults(タスク管理リスト),
    {
        タイトル: タイトル入力.Text,
        担当者: 担当者入力.Text,
        期日: 期日入力.SelectedDate
    }
)

Defaults関数は「このリストの空の新規レコード」を意味します。第2引数にDefaultsを渡すことで、既存レコードの更新ではなく新規追加になります。

Update——データの更新

選択したレコードを上書きする

ギャラリーで選択した行を更新する場合は、Patch関数の第2引数にギャラリーの選択状態（Selected）を渡します。これがCreateとの大きな違いです。

Patch(
    タスク管理リスト,
    ギャラリー1.Selected,
    {
        タイトル: タイトル入力.Text,
        ステータス: ステータスドロップダウン.Selected.Value
    }
)

第2引数に更新したいレコードを指定することで、そのレコードだけが上書きされます。指定しなかったフィールドは元の値が保持されます。Patch関数の詳しい使い方はPatch関数の解説にまとめています。

Delete——データの削除

Remove関数でレコードを削除する

レコードを削除するにはRemove関数を使います。削除ボタンのOnSelectプロパティに次のように書きます。

Remove(タスク管理リスト, ギャラリー1.Selected)

削除は取り消せないので、実際のアプリではConfirm関数と組み合わせて確認ダイアログを出してから実行するのが安全です。

If(
    Confirm("このレコードを削除しますか？"),
    Remove(タスク管理リスト, ギャラリー1.Selected)
)

私が現場で作った申請管理アプリでも削除機能は最初は入れていませんでした。誤操作が怖かったのです。結局、管理者権限を持つ担当者だけが使えるボタンとして後から追加しました。最初からすべての機能を実装しようとせず、必要になってから追加するくらいで十分です。

フォームコントロールを使う方法との違い

Power AppsにはEditFormというフォームコントロールがあり、これを使うとデータの追加・更新をほぼ自動で処理してくれます。Patch関数を自分で書かなくていい分、実装が速いです。ただしフォームのレイアウト自由度が低く、細かいUI設計をしたいときは制約になります。

	Patch関数で書く	フォームコントロール
実装のしやすさ	コードを書く必要がある	設定だけでほぼ完結
レイアウト自由度	高い（完全に自由）	低い（フォームの制約あり）
複雑な条件処理	やりやすい	やりにくい

業務アプリを素早く作りたいときはフォームコントロールを使い、細かいUIや複雑な条件が必要なときはPatch関数で書く——この使い分けが現実的です。フォームコントロールの使い方については別記事で詳しく解説する予定です。

まとめ

SharePointリストのCRUDは、Filter（一覧）・Patch + Defaults（追加）・Patch + Selected（更新）・Remove（削除）の組み合わせで実装できます。最初はこの4つのパターンをそのままコピーして動かしてみてください。

1本のCRUDアプリが完成すると、Power Appsでできることの感覚が一気につかめます。まず動くものを作ることが大切です。Power Apps開発の全体像はPower Apps開発の全体マップで整理しているので合わせて確認してみてください。

Power Appsで姓と名を分けて取り出す｜Split・First・Lastの使い方

Sun, 22 Mar 2026 11:17:37 GMT

SharePointやActive Directoryから取得できる名前のデータは、「田中, 太郎」のようにカンマ区切りで姓と名が逆順に並んでいることがあります。Splitを使えば、この形式をアプリ上で自由に組み替えられます。

Splitの仕組み：文字列をテーブルに変換する

Split関数は、文字列を区切り文字で分割し、テーブルとして返す関数です。引数は2つで、対象の文字列と区切り文字を指定します。

Split("田中, 太郎", ", ")

この結果は1列（Value列）のテーブルになり、最初の行に「田中」、2行目に「太郎」が入ります。文字列を返すわけではないため、Splitの結果を直接ラベルのTextプロパティに渡してもうまく表示されません。ここが最初に戸惑うポイントです。

FirstとLastで要素を取り出す

Splitが返すテーブルから特定の行を取り出すには、FirstやLastを使います。

// 最初の行（姓）を取り出す
First(Split("田中, 太郎", ", ")).Value

// 最後の行（名）を取り出す
Last(Split("田中, 太郎", ", ")).Value

FirstとLastはそれぞれテーブルの先頭行・末尾行をレコードとして返します。その後ろに .Value をつけることで、Value列の値（文字列）として取り出せます。Splitで2つに分割した場合、FirstとLastの組み合わせで十分対応できます。

3つ以上に分割する場合はIndex関数が必要になりますので、詳細はこちらの記事をご覧ください。

実例3パターン

カンマ区切りの姓名を反転する

Active DirectoryからUser().FullNameで取得できる名前が「田中, 太郎」形式の場合、次の数式で「太郎田中」に組み替えられます。

Last(Split(User().FullName, ", ")).Value & " " & First(Split(User().FullName, ", ")).Value

ただし、Split関数を2回書くと数式が長くなります。Withを使うとすっきり書けます。

With(
    { parts: Split(User().FullName, ", ") },
    Last(parts).Value & " " & First(parts).Value
)

Withを使った数式の整理についてはPower AppsのWith関数の記事も参考にしてください。

コレクションに格納して加工する

Splitの結果をコレクションに入れておくと、複数の場所で使い回せます。たとえばボタンのOnSelectでコレクションを作り、ギャラリーに表示する構成です。

ClearCollect(
    colNameParts,
    Split(TextInput_Name.Text, " ")
)

コレクションの使い方についてはPower Appsのコレクション活用入門で詳しく解説しています。

SharePointリストへの整形保存

SharePointリストに氏名を格納する際、姓と名を別の列に分けて保存したいケースがあります。Splitで分割した値をPatchでそれぞれの列に書き込めます。

With(
    { parts: Split(TrimEnds(TextInput_FullName.Text), " ") },
    Patch(
        社員マスタ,
        Defaults(社員マスタ),
        {
            姓: First(parts).Value,
            名: Last(parts).Value
        }
    )
)

SharePointリストの読み書きパターンについてはSharePointリストのCRUDパターンをあわせて参考にしてください。スペース混入が心配な場合は、Splitの前にTrimEndsをかけておくと安心です。TrimとTrimEndsの使い方はこちらの記事をご覧ください。

まとめ

Splitは文字列をテーブルに変換する関数で、そのままでは文字列として扱えません。First・Lastと組み合わせることで目的の要素を取り出せます。Withと組み合わせれば、Split関数を何度も書く必要がなくなり、数式がすっきりします。

3つ以上の区切りがある場合や、n番目の要素を取り出したい場合はIndex関数が役立ちます。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

地道な処理ですが、データ整形ができるようになるとアプリの完成度がぐっと上がります。ぜひ試してみてください。

Power Appsの文字列補間 $"..." とアンパサンド記法の違いを比較

Sun, 22 Mar 2026 11:17:45 GMT

Power Appsには文字列を組み立てる方法が2つあります。従来からある & 演算子と、比較的新しい文字列補間（$“…”）です。どちらを使うかで数式の読みやすさが大きく変わります。

アンパサンド（&）記法の基本

& 演算子は以前から使える文字列連結の方法です。文字列と変数や関数の結果を & でつなぎます。

"こんにちは、" & User().FullName & "さん。今日は " & Text(Today(), "yyyy/mm/dd") & " です。"

シンプルな結合なら問題ありませんが、変数や関数を多く挟むほど & が増えて読みにくくなります。特に条件や変換処理が混ざると、どこが文字列でどこが変数なのか一目で判断しにくくなります。

文字列補間（$“…”）の基本

文字列補間は、文字列の中に波括弧 {} で変数や式を埋め込む書き方です。C#やJavaScriptのテンプレートリテラルに近い構文です。

$"こんにちは、{User().FullName}さん。今日は {Text(Today(), "yyyy/mm/dd")} です。"

先ほどの & 記法と全く同じ結果になりますが、全体が1本の文字列として見え、変数や式の挿入箇所が {} で明確に示されます。私は社内の勉強会でPower Appsを教える立場ですが、文字列補間は初心者にも直感的に伝わりやすいと感じています。

どちらを使うべきか比較

	& 演算子	文字列補間 $“…”
可読性	変数が増えると読みにくい	全体が1文字列として読める
対応バージョン	全バージョン	Power Apps 2022年11月以降
波括弧 {} の扱い	不要	{ } 自体を出力したいときは {{ }} と書く
ネスト	関数が増えると煩雑	{ } の中に関数・条件式を書ける

現在の環境が文字列補間をサポートしている場合は、積極的に使うことをおすすめします。特に動的なメッセージを組み立てる場面では、読みやすさが保守性に直結します。

実例3パターン

通知メッセージの組み立て

ボタンを押したときに承認依頼のメッセージをNotify関数で表示する場面です。

// & 演算子
Notify("申請番号 " & TextInput_AppNo.Text & " を提出しました。担当者: " & varAssigneeName, NotificationType.Success)

// 文字列補間
Notify($"申請番号 {TextInput_AppNo.Text} を提出しました。担当者: {varAssigneeName}", NotificationType.Success)

文字列補間のほうが「どこが変数か」が一目でわかります。IfやSwitchの中で使う場合も同様で、数式全体がすっきりします。Ifの使い方はこちらの記事を参照してください。

With関数と組み合わせて複雑な式を整理する

計算結果を文字列に埋め込む場合、Withで中間値を変数として持つと式が整理されます。

With(
    {
        taxRate: 0.1,
        subtotal: varItemPrice * varQuantity
    },
    $"小計: {subtotal}円、消費税: {subtotal * taxRate}円、合計: {subtotal * (1 + taxRate)}円"
)

Withを使った数式整理についてはこちらの記事で詳しく説明しています。

Named Formulasと組み合わせて再利用する

よく使うメッセージテンプレートをNamed Formulas（名前付き数式）に定義しておくと、アプリ内の複数の画面から同じ文字列補間式を呼び出せます。

// App.Formulasに定義
WelcomeMsg = $"ようこそ、{User().FullName}さん";

名前付き数式についての詳細は別記事で解説予定です。

波括弧そのものを出力したいとき

$“…” の中で { や } という文字そのものを表示したい場合は、{{ または }} と2つ重ねて書きます。

$"JSONの例: {{key: value}}"
// 結果：JSONの例: {key: value}

まとめ

文字列補間は一度使い始めると、& 演算子には戻りにくくなります。数式が短くなるわけではありませんが、読みやすさが上がることで見直しやメンテナンスが楽になります。

テーブルをまとめて1本の文字列にしたい場合はConcat関数が必要です。Concatと文字列補間の使い分けは、個々の変数を埋め込むか、テーブルの行をつなぎ合わせるかで判断してください。Concatの使い方はこちらの記事をご覧ください。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

書き方を変えるだけで数式の見通しがぐっと良くなります。ぜひ取り入れてみてください。

Power Appsテキスト関数完全ガイド｜Split・Mid・Trimなど10関数を解説

Sun, 22 Mar 2026 11:17:22 GMT

Power Appsでデータを整形・加工するために欠かせないテキスト関数を1記事にまとめました。スペース除去・文字列置換・切り出し・変換・結合まで、実務でよく使う10関数を用途別に解説します。

なぜテキスト関数が必要なのか

SharePointリストや入力フォームから取得したデータは、そのまま使えない形式であることが多いです。末尾にスペースが混入している、大文字小文字が統一されていない、コードの一部だけ取り出したい、複数の値を1本の文字列にまとめたい。こうした整形・加工の場面でテキスト関数が必要になります。

社内でPower Appsを教えていると、数式の書き方よりも「どの関数を使えばいいかわからない」という声のほうが多いです。この記事では用途別に整理したので、目的に合った関数を探す際の参考にしてください。

Power Apps開発の全体像についてはこちらの記事もご覧ください。

スペース除去：TrimとTrimEnds

文字列の両端や文字間の余分なスペースを取り除く関数です。入力フォームからデータを受け取るときに最初にかませる習慣をつけると、比較ミスや保存データの不整合を防げます。

Trim：先頭・末尾のスペースを除去し、文字間の連続スペースも1つに圧縮
TrimEnds：先頭と末尾のスペースのみ除去（文字間のスペースはそのまま）

IfやFilterの条件が通らない原因の多くはスペース混入です。詳しい使い方と実例はこちらの記事で解説しています。

文字列置換：ReplaceとSubstitute

文字列の一部を別の文字列に置き換える関数です。

Replace：開始位置と文字数を指定して置換（固定長コード向け）
Substitute：置き換えたい文字列を指定して置換（動的データ向け）

迷ったらSubstituteを選ぶのが基本です。Replaceが必要になるのは、データの文字位置が完全に固定されている場合に限ります。詳しくはこちらの記事をご覧ください。

大文字小文字の変換：Upper・Lower・Proper

Power Appsの文字列比較は大文字小文字を区別します。比較前にLowerで統一しておくと、ケース違いによるミスマッチを防げます。

Upper：すべて大文字に変換
Lower：すべて小文字に変換（比較・検索前の前処理に使う）
Proper：先頭だけ大文字、残りを小文字に変換（人名・地名の表示整形向け）

User().Emailとリストのメールアドレスを比較する場面で特に役立ちます。詳しくはこちらの記事で解説しています。

文字列の切り出し：Left・Right・Mid・Find

文字列の特定の部分を取り出す関数です。

Left：先頭からn文字を取り出す（固定長コードの先頭部分向け）
Right：末尾からn文字を取り出す（請求番号の末尾桁向け）
Mid：指定した位置からn文字を取り出す（区切り文字の間の値向け）
Find：指定した文字列が何文字目にあるかを返す（Midと組み合わせて使う）

文字の位置が固定されているならLeft・Right、位置が変わりうるならMidとFindを組み合わせます。Left・Rightはこちら、MidとFindの組み合わせはこちらの記事で詳しく解説しています。

文字列の分割と要素取り出し：Split・First・Last・Index

カンマやスラッシュで区切られた文字列をテーブルに分割し、特定の要素を取り出す組み合わせです。

Split：区切り文字で文字列を分割し、テーブルとして返す
First：テーブルの先頭行を返す
Last：テーブルの末尾行を返す
Index：テーブルのn番目の行を返す

「田中, 太郎」という形式の氏名を「太郎田中」に組み替える、スラッシュ区切りのパスから任意の要素を取り出す、といった場面で使います。Split・First・Lastの使い方はこちら、Indexの使い方はこちらの記事をご覧ください。

文字列の結合：Concat・文字列補間 $“…”

複数の値をまとめて1本の文字列にする方法です。

Concat：テーブルの各行を結合して1本の文字列にする（コンボボックスの複数選択をメール宛先にするなど）
文字列補間 $“…”：文字列の中に変数や式を直接埋め込む（可読性が高く、動的なメッセージ組み立てに向く）

単純な2〜3個の固定値の連結には & 演算子で十分ですが、テーブルの内容を結合するときはConcat、変数を埋め込む場面では文字列補間が使いやすいです。Concatはこちら、文字列補間はこちらの記事で解説しています。

文字数カウント：Len

文字列の文字数を返す関数です。単独ではほとんど使わず、Ifによるバリデーション・残り文字数の表示・MidやRightの引数計算などと組み合わせて使います。詳しくはこちらの記事をご覧ください。

テキスト関数を組み合わせる実例

実務では複数のテキスト関数を組み合わせて使います。たとえばSharePointリストに保存されたメールアドレスと、フォームで入力されたメールアドレスを比較する場合、次のように処理します。

Filter(
    社員リスト,
    Lower(TrimEnds(メール)) = Lower(TrimEnds(TextInput_Email.Text))
)

TrimEndsでスペースを除去してから、Lowerで大文字小文字を統一して比較します。この2ステップを習慣にするだけで、データ不一致の原因のほとんどは解消できます。

FilterやSearchとの組み合わせについてはこちらの記事、Ifとの組み合わせはこちらの記事を参考にしてください。Withを使った数式の整理についてはこちら、変数への格納についてはこちらもあわせてご覧ください。

まとめ：用途別の関数選択ガイド

やりたいこと	使う関数
スペースを取り除く	TrimEnds（端のみ）/ Trim（全体）
文字列を置き換える	Substitute（通常）/ Replace（固定位置）
大文字小文字を統一する	Lower（比較前）/ Proper（表示整形）
先頭・末尾を切り出す	Left / Right
中間を動的に切り出す	Mid + Find
区切り文字で分割する	Split + First / Last / Index
テーブルを文字列に結合する	Concat
変数を文字列に埋め込む	文字列補間 $“…”
文字数を調べる	Len（Ifや他の関数と組み合わせて）

テキスト関数は地味に見えますが、データ整形の精度がアプリの信頼性に直結します。1つずつ手に馴染ませていきましょう。

Power Appsでスペース混入バグを防ぐ｜TrimとTrimEndsの使い方

Sun, 22 Mar 2026 11:17:25 GMT

数式は正しいのに、Ifが通らない。FilterでSharePointのデータがヒットしない。こういった謎のバグの犯人は、ほとんどの場合スペースです。TrimとTrimEndsを覚えておくだけで、この種のトラブルを大幅に減らせます。

スペース1文字が引き起こすバグの仕組み

Power Appsの文字列比較は、スペース1文字の差でも別の値として扱います。たとえば「田中」と「田中　」（末尾にスペース）は、見た目がほぼ同じでも完全に別の文字列です。IfやSwitchの条件式でFalseが返るとき、数式の書き方ではなくデータ側のスペースを疑ってみてください。

私が最初にこれで詰まったのは、SharePointリストのデータをLookUpで検索していたときのことです。画面上は同じ値なのに一致しない。数式を何度見直しても問題がない。ようやく判明した原因は、SharePointに登録されたデータの末尾に半角スペースが混入していたことでした。入力フォームのテキスト入力コントロールはスペースをそのまま渡すため、入力者が気づかずスペースを含めてしまうことが多いのです。

TrimとTrimEndsの違い

Power Appsにはスペースを除去する関数が2種類あります。まず両者の違いを整理しておきましょう。

関数	除去する対象	主な用途
Trim	先頭・末尾のスペース＋文字間の連続スペースを1つに圧縮	氏名・住所など文字間も整えたいとき
TrimEnds	先頭と末尾のスペースのみ	テキスト入力の値を受け取るとき

Trimは文字列の両端に加えて、文中の連続スペースも1つに詰めます。たとえば「山　　田」（スペース2つ）は「山田」（スペース1つ）に変換されます。一方、TrimEndsは両端だけを除去し、文中のスペースはそのまま保持します。氏名や住所のように文中のスペースに意味がある場合は、TrimEndsのほうが安全です。

実例3パターン

テキスト入力の末尾スペースでIfが通らない

入力フォームで名前を入力し、特定の値と一致したときにメッセージを表示する場面です。テキスト入力コントロールからそのまま値を取得すると、ユーザーが気づかず末尾にスペースを入れた場合にIfが通らなくなります。

If(
    TrimEnds(TextInput1.Text) = "田中太郎",
    "一致しました",
    "一致しません"
)

TextInput1.Textをそのまま比較するのではなく、TrimEndsで両端を整えてから比較します。Ifの使い方についてはPower AppsのIfとSwitchで詳しく解説しています。

SharePointデータとの比較失敗

SharePointリストのデータを検索フィールドの入力値で絞り込む場面です。Filterでヒットしない原因の多くは、片方のデータにスペースが混入しています。

Filter(
    社員リスト,
    TrimEnds(氏名) = TrimEnds(TextInput_Search.Text)
)

検索フィールドの値だけでなく、SharePointリスト側の列にもTrimEndsをかけておくと確実です。特に人の手で登録されたデータはスペース混入が起きやすい傾向があります。FilterやSearchの使い方はPower AppsのFilter・Search・LookUp関数にまとめています。

SharePoint保存時にTrimをかけておく

Patch関数でSharePointリストにデータを書き込む際、入力値をそのまま渡すとスペース混入がリストに蓄積されていきます。Patchの時点でTrimEndsを一枚かませておくと、後工程での問題を防げます。

Patch(
    社員リスト,
    Defaults(社員リスト),
    {
        氏名: TrimEnds(TextInput_Name.Text),
        部署: TrimEnds(TextInput_Dept.Text)
    }
)

SharePointリストへの読み書きの基本はPower AppsでSharePointリストのデータを読み書きするで解説しています。

よくある間違い：Trimしたつもりが変数に入れ忘れ

Trimをかけたのに効いていない、というときに多いのが、Trimした結果をどこにも使えていないパターンです。

// 間違い例：Trimの結果が捨てられている
Trim(TextInput1.Text);
Set(varName, TextInput1.Text);

// 正しい例：Trimした値を変数に入れる
Set(varName, Trim(TextInput1.Text));

Trimは新しいテキスト値を返す関数であり、元のコントロールの値を書き換えるわけではありません。戻り値を変数に格納するか、比較式の中で直接使いましょう。OnButtonPressなど複数の処理をまとめて書くとき、この間違いが発生しやすいので注意が必要です。

まとめ：入力を受け取るときは常にTrimEnds

テキスト入力コントロールからユーザーの入力を受け取るときは、常にTrimEndsを1枚かませる。これを習慣にしておくだけで、スペース起因のバグに悩む機会を大幅に減らせます。

Trimは文字間まで整えたいとき、TrimEndsは末尾スペースだけ取り除きたいときと使い分けてください。ほとんどのケースではTrimEndsで十分対応できます。

大文字小文字の違いも同様に比較結果を狂わせます。その対策については、Upper・Lower・Properの使い方として別記事で解説する予定です。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

地道な一手間ですが、こういった処理を積み重ねることが、信頼できるアプリにつながります。ぜひ習慣にしてみてください。

Power Apps の型変換エラーを解消する｜Text・Value・DateValue・Boolean関数の使い方

Sat, 18 Apr 2026 08:45:34 GMT

Power Appsでは、数値・テキスト・日付・Boolean（true/false）はそれぞれ別の型として厳格に管理されています。型が合わない値を渡すと式がエラーになります。

Power Appsが型に厳しい理由

Power Appsの数式エンジンは、値の種類（型）を常に意識して動いています。Excelなら数値に見えればそのまま計算してくれることが多いですが、Power Appsでは各データの型を厳密に区別します。

テキスト入力コントロールに入力した値は、数字に見えても型はテキスト（Text）です。そのまま計算式に使おうとすると、型の不一致を検知してエラーが出ます。数式バーに赤いアンダーラインが引かれ、マウスを乗せると Expected Number value のようなエラーメッセージが表示されます。

なぜこういう設計になっているかというと、Power Appsはデータベースと接続して動くツールだからです。SharePointの列はそれぞれ一行テキスト・数値・日付と時刻などの型が定義されていますし、その型に合わない値を保存しようとするとPatchが失敗します。型を意識する習慣は、アプリを安定させる上で欠かせません。

型の種類：6種類を把握する

Power Appsで扱う型は主に以下の6種類です。

型	説明	代表的な場所
Text（テキスト）	文字列	テキスト入力・一行テキスト列・ラベル
Number（数値）	整数・小数	数値入力・数値列・計算結果
Date/Time（日付）	日付・時刻	日付入力・日付列・Today()
Boolean（真偽値）	true/false	チェックボックス・はい/いいえ列
Record（レコード）	1行分のデータ	Gallery.Selected・Patch の引数
Table（テーブル）	複数行のデータ	コレクション・Filter の結果

初心者がよくハマるのは、Text・Number・Dateの3種類の間での変換です。特にSharePointのテキスト列に数値っぽい値が入っているケースが多く、私自身も最初の頃は変換が必要だとわかっておらずよく詰まっていました。Record型とTable型は、PatchやFilter関数を使うときに意識することになります。

よくある型ミスマッチのパターン

テキスト列に入った数値を計算したい

SharePointのテキスト列には、設定次第で数字が入ることがあります。それを計算しようとすると型エラーになります。解決策は Value() 関数でテキストを数値に変換することです。

Value(TextInput1.Text) + 100
Value(項目.テキスト列名) * 0.8

Value() はテキストを数値に変換します。変換できない文字列が入っていた場合は実行時エラーになります。不正な入力への対策は IfError(Value(入力値), 0) のように書くと安全です。

数値をラベルやテキストに表示したい

数値をそのままラベルのTextプロパティに渡すと、型の不一致でエラーになります。Text() 関数で文字列に変換します。

Text(100)                    // "100"
Text(SumResult, "0.00")      // 小数点2桁で表示
Text(99.5 / 100, "0%")      // パーセント表示

書式文字列を指定することで、表示形式も同時に制御できます。数値列を合計してラベルに表示する場面では Text(Sum(コレクション, 数値列), “#,##0”) のように書くと、カンマ区切りで表示されます。書式文字列はExcelと同じ形式が使えるので、Excel経験者はスムーズに理解できます。

日付をテキストとして扱いたい

日付型の値をテキスト連結（&）に使おうとするとエラーになります。Text() 関数で書式文字列を指定して変換します。

"申請日：" & Text(Today(), "yyyy/mm/dd")
"〆切：" & Text(DateValue("2026-05-31"), "yyyy年mm月dd日")

逆に、テキスト形式の日付文字列をDate型として扱いたいときは DateValue() を使います。SharePointの日付列はすでにDate型なので変換不要ですが、テキスト入力から日付を受け取るケースでは必要になります。

DateValue(TextInput1.Text)                             // "2026/04/13" → Date型
DateAdd(DateValue(TextInput1.Text), 30, TimeUnit.Days) // 30日後を計算

日付の入力はDatePickerコントロールを使うと最初からDate型で受け取れるため、型変換が不要になります。テキスト入力で日付を受け取るよりも、DatePickerを使う設計のほうが式がシンプルになります。

Boolean型の変換

チェックボックスの値はBoolean（true/false）です。これをテキストとして表示したい場合や、文字列のtrueやfalseをBoolean型に変換したい場面があります。

// Boolean → テキスト（条件分岐で対応）
If(Checkbox1.Value, "対象", "対象外")

// テキスト → Boolean
Boolean("true")      // true
Boolean("false")     // false
Boolean("yes")       // true

SharePointのはい/いいえ列はすでにBoolean型なので、条件式では If(項目.はい列, …) のように直接使えます。変換が必要になるのは、テキスト列に文字列としてtrueが入っているケースや、外部APIから文字列で受け取るケースです。体感的にBoolean変換が必要になる頻度はText・Number・Dateと比べて少ないですが、知っておくと詰まったときに素早く対処できます。

変換関数チートシート

よく使う変換関数をまとめます。この表を手元に置いておくと、エラーが出たときにどの関数を使うか迷わなくなります。

変換したい方向	関数	例
Text → Number	Value()	Value(“42”) → 42
Number → Text	Text()	Text(42) → “42”
Number → Text（書式あり）	Text(値, 書式)	Text(3.14, “0.00”) → “3.14”
Text → Date	DateValue()	DateValue(“2026/04/13”) → Date
Date → Text	Text(日付, “書式”)	Text(Today(), “yyyy/mm/dd”) → “2026/04/13”
Text → Boolean	Boolean()	Boolean(“true”) → true
Boolean → Text	If(値, “はい”, “いいえ”)	—
Number → Text（パーセント）	Text(値, “0%”)	Text(0.8, “0%”) → “80%”

Patch関数で型を意識する場面

型変換の知識が最も役立つのは、Patch関数でSharePointリストにデータを書き込む場面です。列の型と渡す値の型が一致していないと、Patchは実行時エラーになります。

特に注意が必要なのは次の2点です。テキスト入力の値を数値列に書き込む場合は Value(TextInput.Text) で変換してから渡します。日付の場合、DatePickerコントロールならDate型なのでそのまま使えますが、テキスト入力で受け取った場合は DateValue() で変換が必要です。

Patch関数で新規レコードを作成するときの列ごとの書き方では、各列型に合わせた値の指定パターンを整理しています。型変換を組み合わせると式が複雑になりますが、それぞれの関数の役割を理解しておくと対処できます。

型が合わないときの確認手順

型エラーが発生したときは、次の手順で確認します。

エラーメッセージを読む（Expected Text / Expected Number / Incompatible types のいずれか）
エラーが出ている式で使っている値の型を確認する（コントロールの種類・SharePointの列型）
型が合っていない部分に Text / Value / DateValue を挿入して変換する
保存して動作確認する

型エラーのメッセージの意味を知っておくと、エラーが出てもどこを直せばいいかがすぐわかります。Power Appsのエラー解決マップでは、型エラーを含むよくあるエラーパターンの全体像を整理しています。型変換だけでなく、エラー対処の引き出しをまとめて増やしておくと開発が格段にスムーズになります。

まとめ

Power Appsの型変換は、最初は面倒に感じるかもしれません。ですが、Value・Text・DateValueの3つを押さえるだけで、日常的な型エラーの大半はカバーできます。

SharePointリストを使って業務アプリを作ると、テキスト列・数値列・日付列を混在して扱う場面が必ず出てきます。そのたびに型変換を意識する癖をつけておくと、Patchエラーや表示のズレに悩まされることが減ります。地道に積み上げていきましょう。

Power Appsは見た目と使いやすさにこだわって開発すべし

Sun, 20 Oct 2024 15:44:29 GMT

Power Apps でのアプリ作成は見た目と使いやすさが極めて重要です。

その理由

見た目が悪いとユーザーの気分が萎えます。

同じ色、同じレイアウトだと飽きられます。

使い勝手が悪いとアプリは使われなくなります。

つまり、ユーザー目線に立った開発が何よりも大切ということです。

業務用なので機能重視なのでは？

こういう声が聞こえてきそうですが、半分正解、半分間違いです。

例えばVBAマクロやPythonは機能が全てで、意図した操作が正しく完了することを求められます。

一方 Power Apps は、機能面はもちろんですが、ユーザーが実際にアプリに触れて操作・入力することを忘れてはいけません。

ギャラリーコントロールとボタンを並べました、はい皆さん使ってくださいねでは不十分で、ユーザー目線で使いやすさとわかりやすさを考える必要があります。ギャラリーコントロールの使い方もあわせて参考にしてください。

アプリ開発はそれ自体が目的ではなく、ユーザーが触れて使うことを忘れてはいけません。

プロトタイプ（試作品）は機能重視でもいいのですが、本番運用までには見た目と使いやすさにこだわったアプリ、つまりユーザーフレンドリーなアプリに仕上げておくべきです。

Power Appsの見た目にこだわる

見た目にどうこだわるか紹介します。

トンマナを意識する

トーン＆マナー、略してトンマナと呼びます。

デザインやスタイルに一貫性を持たせることをいい、アプリに統一感を生み出します。

トンマナを突き詰めるとフォントやサイズ、表現の内容などどこまでも細かくなりますが、市民開発ではまず色味を意識します。

例えば、コカ・コーラは赤と白、ペプシは赤と青、ポカリスエットは青と白、という具合に、サービスを連想付ける色があり、HPやCMではその色を意識した見せ方をします。

社内アプリですのでブランディングは不要ですが、せめてコンセプトを決め、テーマカラーを決め、それに合った色で統一しましょう。

色を決める時は Color Hunt のような配色サイトがおすすめ。

他にも、あなたの会社のロゴマークの色と揃えるとか、Excelに関するアプリなら緑系統でまとめるとか、テーマに沿って色を決めるといいですね。

テーマで色を変える

開発画面上部にある[テーマ]からアプリ全体の色味を変更できます。

標準では[青]になっているので、お好みの色に変更してみましょう。

左上から時計回りに、青、赤、ローズ、紫

これだけでも随分垢抜けた印象になります。

パーツごとに自由に色変更が可能ですが、その場合はFormulaで色を定義することでメンテナンス性の高い仕様になります。

コントロールを結ぶ線をなるべく減らす

画面内にコントロールを配置する際は端を揃えます。

ボタンやギャラリーの端がきちんと揃って並んでいるか、画像のように線を結んで確認します。

左の例は端がバラバラで、線が11本。

対して右の例は端を揃えて線が6本。

右のほうがレイアウトがすっきりしています。

一応私は社内で教える立場なので人のアプリをよく目にしますが、実際コントロールがガタガタになっている例をよく見ます。

線を減らすことを意識してアプリを見直しましょう。

丸みを取り入れる

挿入したコントロールは基本的にどれもカクカクしています。

これにちょっと丸みを入れるだけで雰囲気が柔らかくなります。

ボタンの形あれこれ

丸みは[境界半径]のプロパティで設定します。

角ごとに細かく設定するなら Radius の項目です。

ここで真円（まんまる）ボタンの作り方を紹介します。

ボタンの幅と高さを同じ数値にし、Radius の4つの値を Self.Width/2（または Self.Height/2）としましょう。

余白をつくる

レイアウトには余白を入れましょう。

ボタンや項目がギチギチに詰まったアプリは見づらいです。

ユーザーの直感的な操作を妨げ、直感的に使いづらさを覚えます。

余白は洗練されたイメージを作り、余裕を与えます。

ゆったりしたスペースを確保しましょう。

無駄を削ぎ落とす

社員番号、管理番号、登録日など、その情報、本当にアプリに表示させる必要はありますか？

特にFormコントロールを多用する人にありがちで、ユーザーに不必要な情報が見えてしまっていることがあります。

ユーザーの判断を迷わせるだけでなく、余白を埋めてしまいかねません。

設計はあくまでユーザー目線であるべきです。

不要な情報は載せるべきではありません。

画像やアイコンを効果的に使う

画像やアイコンを載せるとアプリが華やかになります。

画像の多用はアプリが重たくなるので使いすぎには注意。

SVGは画像が崩れず軽量なので、使える場面は積極的に使いたいですね。

アイコンはすっきりしたレイアウトを作りますが、直感的に意味が伝わるアイコンを使いましょう。

コンテナを使いこなす

コンテナは複数のコントロールを1つにまとめる機能です。

縦並び、横並びをきれいに揃えたり、両端揃えにしたり、割合で大きさを指定します。

すっきり整列できることはもちろん、動的に配置が変わるため、レスポンシブデザインにコンテナは欠かせません。

コンテナはクセがある機能ですが、使えるようになるとグッとデザインが洗練されますので、トライしてみましょう。

Power Appsの使いやすさにこだわる

続いて使いやすさにつながる機能面の紹介です。

デバイスを意識する

パソコン、タブレット、スマホ。

アプリはどのデバイスから使われるか意識し、それに合う設計をしましょう。

パソコン向け・タブレット向けは横画面です。

スマホ向けは縦画面です。

縦アプリをパソコンで使っても、違和感はあるものの使えます。

逆に、横アプリをスマホで見るとスマホ自体を横操作することになり、表示も小さくなるので無理があります。

つまりスマホ向け縦画面で作っておけば最悪事足りるのですが、使用デバイスを考えることは非常に重要です。

使用する場所を意識する

このアプリはどんな場所で使いますか？

事務所、作業現場、イベント会場、倉庫、いろいろシーンがあります。

使用する場所の特徴をよく考慮し、それに合うアプリにしましょう。

事務作業が多い事務所で使うなら、じっくり腰を据えて使うでしょうから入力項目が多くても大丈夫でしょう（少ないに越したことはありませんが）。

作業現場で使うなら、わかりやすくシンプルに、ボタンは大きく、挙動は軽く、を意識するでしょう。

イベント会場なら、人が多くて回線が不安定になりがちなので、画像は使わず挙動の軽さを優先するでしょうか。

倉庫で検品作業に使うなら、画像を大きく見えやすくするかもしれません。

ユーザー属性を意識する

ユーザーの年齢層やデジタル知識のレベル、役割に合わせた設計をしましょう。

高齢者がユーザーなら、はっきりした色使いでフォントは大きく、難しい言葉遣いを避けます。

デジタルに抵抗のない人向けのアプリなら、多少説明を省略したりモダンな設計が好まれるでしょう。

逆にデジタル知識が乏しい人が多ければ、細かな説明を表示し、機能をシンプルにするなど必要です。

ユーザーの役割に合わせ、入力者と管理者の画面をわける必要があるかもしれません。

アクションの前に確認を入れる

Patch, SubmitForm, Remove などのデータ操作の前には、確認画面を入れましょう。

これらの確認画面は、一般的に UpdateContext関数で True/Falseを切り替えて使います。

ボタンの誤操作を防止する役目もありますので、ぜひ導入しましょう。

スピナーを使う

いわゆるNow Loading…やデータ更新中などを入れましょう。

こういうやつです

PatchやSubmitFormを使うと、約1〜2秒かけて更新されます。

デフォルトでは、アプリの画面上部に申し訳程度のローディングのアイコン（これをスピナーといいます）が出ますが、視認性が悪いです。

わかりやすいスピナーがあるといいですね。

メニューを使う

メニューバーがあると、ユーザーは直感的に操作しやすくなります。

スクリーンが複数ある場合、メニューを使うとページ移動しやすくなりますね。複数画面の遷移設計については、Navigate関数を使った画面遷移の記事も参考にしてください。

スマホの場合は画面下に常にメニューを表示したり、メニューボタンを押したら一覧が表示されるなど工夫すると使いやすいです。

できるだけユーザーに入力させない

ユーザーがTextInputやFormに情報入力する時、自分の名前や所属部署、役職など、Office365ユーザーコネクタで取得できる情報はDefaultで表示させましょう。

入力の手間を極力減らし、ユーザーに無駄な操作をさせないよう意識することが大切です。

ヒントテキストはときに不親切

TextInputには[ヒントテキスト]を設定できますが、実はこれが不便に機能するシーンがあります。

ヒントテキストは画像のように、入力欄に何を入力するべきかうっすら表示される説明文のこと。

薄い文字で説明文がある

ここをクリックすると、説明文が消えてユーザーが入力できるようになります。

入力欄をクリックすると説明文が消え、入力可能になる

これ、一見すると親切設計ですが、入力時に説明文が消えるのであれ、ハイフン必要だったっけ？と一瞬迷うことがあるんですね。

ですので私なりの最適解は、下のようにヒントテキストに加えて別に説明文を設ける、です。

ヒントテキストが消えてもわかりやすい

こうしておけば入力に迷うことがありません。

このあたりはアプリのレイアウトによっては野暮ったくなるので、うまく使い分けましょう。

マニュアルを掲載する

使い方を記した資料をアプリ内のどこかに置いておきましょう。

問い合わせを減らすことができます。

Power Pointなどの共有リンクを載せておくといいですね。

お問い合わせ機能をつける

万が一のためにお問い合わせ機能を設置しておきましょう。

わからないことがあれば、ユーザーはここからコンタクトを取ります。

終了ボタンは不要

Exit関数でアプリを終了させる機能は基本的に不要です。

親切心からか、わざわざ画面右上にバツボタンでExit()を設定する人をたまに見かけますが、ユーザーの誤操作に繋がります。

どうしてもExit()を残したいのであれば、せめて終了確認画面を表示させるなどワンクッションはかならず入れましょう。

Power Automateで便利機能をつくる

アプリに連動して Power Automate が動く設計にするとさらに利便性が向上します。

例えば登録確認がメールで届くとか、アプリのデータがCSVになり、PCにダウンロードするかWeb上で開くか選択できるとか、かゆいところに手が届くんですね。

自動化の恩恵を最大限に享受できるようにするといいでしょう。

万人受けするものは存在しない

これまで色々紹介してきましたが、これをやったからといって必ずしも見やすく使いやすいアプリになるわけじゃありません。

そもそも誰が見やすさと使いやすさを判断するのか？

言うまでもなく、それはアプリのユーザーです。

もっといえば、あなたの同僚や社員がそれを判断します。

私の会社では受け入れられる見た目も、業種も職種も異なるあなたの会社で当てはまるかどうかはわかりません。

だからこそ、ユーザー（あなたの同僚や社員）目線に立ってあなたが試行錯誤しなければいけません。

今回のテクニックはきっかけにすぎませんが、共通していえるのはユーザーファーストの設計、これに尽きます。

Power Appsで大文字小文字を統一する｜Upper・Lower・Properの使い方

Sun, 22 Mar 2026 11:17:30 GMT

確かに同じ文字なのにTrueにならない。Power Appsでこうなる場合、大文字小文字の違いが原因であることがよくあります。Upper・Lower・Properを使えば、この問題はすっきり解決できます。

Power Appsの文字列比較は大文字小文字を区別する

Power Appsの文字列比較は、大文字と小文字を別の文字として扱います。たとえば「yamada@example.com」と「Yamada@example.com」は別の文字列です。Ifの条件式が通らない、FilterやLookUpでヒットしない、という症状がある場合は、大文字小文字の違いを疑ってみてください。

特によく起きるのが、User().Emailとリストに登録されたメールアドレスを比較するケースです。Active Directoryから取得されるメールアドレスは環境によって大文字小文字の扱いが異なることがあり、SharePointのリストに手で入力されたデータと一致しないことがあります。私の社内でも、勤務表アプリで自分のデータだけが表示されないという相談が来たとき、この原因が多かったです。

3つの関数の使い分け

Power Appsには大文字小文字を変換する関数が3つあります。

関数	動作	主な用途
Upper	すべて大文字に変換	コード・略称の統一
Lower	すべて小文字に変換	メールアドレスの比較
Proper	先頭だけ大文字、残りを小文字に変換	人名・地名の表示整形

用途が明確に分かれているため、使い分け自体はそれほど難しくありません。比較をするときはLower、表示を整えるときはProperと覚えておけば、ほとんどのケースで対応できます。

実例3パターン

User().Emailとの比較でLowerを使う

ログインユーザーのメールアドレスと、SharePointリストに登録されたメールアドレスを比較してデータを絞り込む場面です。どちらもLowerで小文字に統一してから比較することで、大文字小文字の違いによるミスマッチを防げます。

Filter(
    申請リスト,
    Lower(申請者メール) = Lower(User().Email)
)

FilterやLookUpの詳しい使い方はPower AppsのFilter・Search・LookUp関数でまとめています。

フォーム入力の氏名整形にProperを使う

テキスト入力コントロールでユーザーが入力した名前を、先頭大文字に統一して表示・保存する場面です。たとえば「SUZUKI TARO」や「suzuki taro」といった入力をPatch前にProperで整形すると、リストのデータが統一されます。

Patch(
    社員リスト,
    Defaults(社員リスト),
    {
        氏名_英語: Proper(TextInput_Name.Text)
    }
)

ただし、Properはすべての単語の先頭を大文字にするため、メールアドレスや略称には使えません。「yamada@example.com」にProperをかけると「Yamada@Example.Com」になってしまいます。表示整形に使う場面を人名・地名などに限定してください。

ギャラリーの検索でLowerを組み合わせる

検索ボックスの入力値でギャラリーを絞り込む場面では、入力値とデータ両方をLowerで統一することで、大文字小文字を気にしない検索が実現できます。

Filter(
    商品リスト,
    Lower(商品名) = Lower(TextInput_Search.Text)
)

SearchではなくFilterで完全一致検索をする場合、この前処理が特に効果的です。ギャラリーコントロールの使い方はPower Appsのギャラリーコントロールで解説しています。

よくある間違い：Properをメールアドレスに使う

Properは人名の整形には便利ですが、メールアドレスや複合語には使えません。代表的なNGパターンを挙げておきます。

入力値	Proper適用後	問題
yamada@example.com	Yamada@Example.Com	メールアドレスとして無効になる
power apps	Power Apps	これは正しく変換される
sharepoint-list	Sharepoint-List	ハイフン後も大文字になる

メールアドレスを含むデータには、ProperではなくLowerを使いましょう。

まとめ：比較前はLower、表示整形はProper

使い分けの基準を一言でまとめると、比較前はLower、表示整形はProperです。Upperは英字コードの統一など、特定の用途で使います。

大文字小文字の問題は、スペースの混入と並んでデータ不一致の代表的な原因です。スペース除去にはTrimやTrimEndsが効果的で、こちらも合わせて使うと比較処理がより堅牢になります。TrimとTrimEndsの使い方はこちらの記事をご覧ください。

IfやSwitchと組み合わせた使い方についてはPower AppsのIfとSwitchもあわせて参考にしてください。

Power Appsのその他のテキスト関数についての完全ガイドはこちらの記事をご覧ください。

小さな関数ですが、使いどころを知っておくだけでアプリの信頼性がぐっと上がります。ぜひ取り入れてみてください。

重すぎる画像を弾く！Power Appsで添付ファイルのサイズや枚数を制限する方法

Sat, 11 Apr 2026 11:26:47 GMT

添付ファイルのサイズ制限は、Power Apps側で作るしかない

スマホで撮影した写真を何枚も添付されて、保存時にエラーが出る、Power Appsで添付ファイルを扱うアプリを作ったことがある人なら、一度は経験するトラブルです。SharePointには列ごとのファイルサイズ上限はありますが、Power Appsは標準状態ではその上限を超える添付を止めてくれません。つまり、制限の仕組みはアプリ側で作る必要があります。

この記事では、添付ファイルの枚数制限・拡張子チェック・送信ボタンの制御という3つの観点から、実用的なバリデーション設計を解説します。

なぜ添付ファイルのバリデーションが必要なのか

私が開発した現場報告アプリでも、運用開始直後に同じ問題が起きました。スマホで高解像度の写真を5〜6枚添付した状態で送信ボタンを押すと、SharePointへの保存が途中でタイムアウトし、データが中途半端な状態で残ってしまうのです。しかも、エラーメッセージが分かりにくいため、保存できたと思い込んで離席するユーザーも出てきました。

こうした問題を未然に防ぐには、添付時点でファイルをチェックする仕組みが必要です。添付コントロールには OnAddFile という専用のプロパティがあり、ここにバリデーション処理を書くことでファイル追加のタイミングで制御できます。

枚数制限の実装

CountRowsで添付数をカウントする

添付ファイルコントロールの .Attachments プロパティは、添付されているファイルのテーブル（コレクション）を返します。これを CountRows 関数に渡せば、現在の添付枚数をリアルタイムに取得できます。

枚数制限を実装する基本的な考え方は次の通りです。

添付コントロールの OnAddFile プロパティを開く
CountRows で枚数を確認し、上限を超えていたら Notify でエラーを表示しつつ Reset で追加をキャンセルする
送信ボタンの DisplayMode も添付枚数の条件に連動させる

OnAddFile プロパティに書く数式の例です。

If(
    CountRows(DataCardValue5_1.Attachments) > 3,
    Notify("添付ファイルは3枚までです", NotificationType.Error);
    Reset(DataCardValue5_1)
)

Reset 関数を呼ぶことで、追加しようとしたファイルをその場でキャンセルできます。ユーザーには Notify のポップアップでメッセージが表示されるため、なぜ添付できなかったのかが一目でわかります。

拡張子チェックの実装

OnAddFileにSplit関数で拡張子を取り出す

枚数だけでなくPDFしか添付できないといった拡張子の制限も、同じく OnAddFile プロパティで実装できます。ファイル名から拡張子を取り出すには Split 関数を使います。ファイル名をドット（.）で分割して末尾の要素を取れば、拡張子だけを抽出できます。Split 関数についてはテキスト関数の解説記事でも触れていますが、この使い方は特に実用的です。

拡張子チェックの実装例です。

If(
    CountRows(Filter(DataCardValue5_1.Attachments, Last(Split(Name, ".")).Value <> "pdf")) > 0,
    Notify("PDFファイルのみ添付可能です", NotificationType.Error);
    Reset(DataCardValue5_1),
    Set(varValidationAttachment, true)
)

この数式の動きを分解すると次の通りです。

Filter で拡張子がpdfでないファイルを絞り込む
CountRows で該当ファイルが1件でもあるか判定する
あれば Notify でエラーを出し、Reset でキャンセルする
問題なければ変数 varValidationAttachment を true にする

許可する拡張子は「pdf」の部分を変更するだけです。「xlsx」や「png」など複数許可したい場合は Filter の条件を And や Or で組み合わせます。

送信ボタンの制御

変数と DisplayMode を連動させる

バリデーションが通ったかどうかを変数（varValidationAttachment）で管理することで、送信ボタンの DisplayMode と連動させられます。

// 送信ボタンの DisplayMode
If(varValidationAttachment, DisplayMode.Edit, DisplayMode.Disabled)

ここで注意したいのが、変数の初期化タイミングです。画面の OnVisible プロパティで Set(varValidationAttachment, false) を実行しておくことで、画面を再訪問したときに前回の状態が引き継がれる問題を防げます。変数の設計パターンについては変数の使い分けガイドも参考にしてください。

添付ファイル制限のまとめと応用

3つの制御をセットで実装する

添付ファイルのバリデーションは、次の3つをセットで実装するのがおすすめです。

制御の種類	実装場所	主な関数
枚数制限	添付コントロールのOnAddFile	CountRows / Reset / Notify
拡張子チェック	添付コントロールのOnAddFile	Split / Last / Filter / Reset
ボタン制御	送信ボタンのDisplayMode	変数（varValidationAttachment）

バリデーション設計全体の考え方については、Power Apps入力ミス防止ガイドの記事で4つのアプローチをまとめています。添付ファイル制限はその中のアプローチ③：UI・選択制御の延長線上にある実装です。

また、カメラコントロールを使って写真を撮影してSharePointに保存するパターンとの違いも押さえておくと、設計の幅が広がります。カメラ撮影の実装についてはカメラコントロールと添付ファイル保存の記事を参照してください。

なぜ添付できないのかをユーザーに伝える

エラーメッセージは「エラーが発生しました」だけでは、ユーザーは何をすれば解決するかわかりません。PDFファイルのみ添付可能です・添付ファイルは3枚までですのように、制約と理由が1文でわかるメッセージを設定することが大切です。Notify 関数で表示するメッセージは NotificationType.Error（赤）・NotificationType.Warning（黄）・NotificationType.Information（青）から選べます。

まとめ

添付ファイルのバリデーションは、OnAddFile プロパティを使うことでファイル追加のその場で制御できます。

CountRows による枚数確認、Split と Last による拡張子チェック、変数と DisplayMode による送信ボタン制御。この3つを組み合わせれば、ファイルサイズ起因のエラーや不正形式の添付をアプリ側でほぼ防ぎきれます。

仕組みを作るのは最初の1回だけです。あとは要件が変わったときに数式の一部を修正するだけで対応できます。市民開発とはこういう地道な積み上げだと思っています。

言った・言わないを防ぐ！Power Appsで誰がいつ入力・変更したかログを残す設計

Sat, 11 Apr 2026 11:26:44 GMT

データがおかしくなったとき、誰がいつ変えたのかがわからないと原因調査が止まります。Power Appsにログ保存の仕組みを組み込んでおくだけで、そのストレスがなくなります。

ログを残さないと何が起きるか

現場でよくある話です。SharePointリストを使った申請アプリを運用していたら、ある日突然登録内容がおかしいと報告が来ました。担当者に確認しても自分は入力していない、自分が変えたわけじゃないと言う。SharePoint標準のバージョン履歴を確認すれば変更者はわかりますが、Power Appsから直接Patchした場合、SharePoint側に誰が何の項目を変えたかの詳細は残りません。

私が社内で最初にアプリを作ったときも、ログ機能を後付けしてかなり苦労しました。最初から設計に組み込んでおけばよかったと今でも思っています。特に承認フローや在庫管理のような重要なデータを扱うアプリほど、ログは必須です。

ログがあれば、問題発生時、2月14日 15:23に田中さんが数量を5から12に変更したという事実を即座に確認できます。言った・言わないの水掛け論がなくなり、何より担当者への不当な疑いを防ぐことができます。

ログ用リストの設計

まず、本番データとは別にログ専用のSharePointリストを用意します。本番リストにログ列を追加する方法もありますが、データが混在して見づらくなるため、リストを分けることをおすすめします。

ログリストの列構成

最低限必要な列は以下の5つです。

列名	型	内容
Title	テキスト	操作種別（登録・更新・削除など）
OperationBy	テキスト	操作したユーザーのメールアドレス
OperationAt	日付と時刻	操作日時
TargetID	数値	操作対象レコードのID
Detail	複数行テキスト	変更内容の詳細（任意）

最初はシンプルな5列で十分です。運用しながら必要な情報が見えてきたら列を追加していくのが現実的です。

Power AppsからログをPatchする実装

ログの書き込みはPatch関数1本で完結します。本番データの保存処理と同じタイミングで、ログリストにも書き込むように設定します。

新規登録時のログ保存

申請データを新規作成するボタンのOnSelectに、本番データへのPatchとログへのPatchを並べて書きます。

// 本番データを保存
Patch(
  '申請データ',
  Defaults('申請データ'),
  {
    Title: TextInput_Subject.Text,
    担当者: TextInput_Name.Text,
    金額: Value(TextInput_Amount.Text)
  }
);

// ログを記録
Patch(
  '操作ログ',
  Defaults('操作ログ'),
  {
    Title: "新規登録",
    OperationBy: User().Email,
    OperationAt: Now(),
    TargetID: Last(Sort('申請データ', ID, SortOrder.Descending)).ID,
    Detail: "件名：" & TextInput_Subject.Text & " / 担当者：" & TextInput_Name.Text
  }
)

2つのPatch関数をセミコロンでつなぐだけです。Power Appsのセミコロン区切りは順番に実行されます。本番データを先に保存し、そのIDをログに記録する流れになります。

Patch関数の基本的な書き方についてはPatch関数の使い方の記事で詳しく解説しています。Defaults関数の使い方や列の型ごとの値指定も確認できるので、あわせて参照してください。

更新時のログ保存

既存レコードを更新する場合は、変更前後の値を Detail に記録しておくと後から見やすくなります。変更前の値はギャラリーで選択したレコード（Gallery.Selected）から取得できます。

// 本番データを更新
Patch(
  '申請データ',
  Gallery_Main.Selected,
  {
    金額: Value(TextInput_Amount.Text)
  }
);

// 変更前後をログに記録
Patch(
  '操作ログ',
  Defaults('操作ログ'),
  {
    Title: "更新",
    OperationBy: User().Email,
    OperationAt: Now(),
    TargetID: Gallery_Main.Selected.ID,
    Detail: "金額変更：" & Text(Gallery_Main.Selected.金額) & " → " & TextInput_Amount.Text
  }
)

変更前の値を Gallery_Main.Selected.金額で、変更後の値を TextInput_Amount.Text で取得し、Detailに「変更前 → 変更後」の形で文字列結合しています。この形式にしておくと、ログを見ただけで何がどう変わったか一目でわかります。

レコードの更新パターンについてはPatch関数で既存レコードを更新する方法の記事も参考になります。Gallery.SelectedとvarRecordの使い分けも解説しています。

ログをアプリ内で確認できるようにする

ログリストはSharePointで直接確認することもできますが、アプリ内にログ表示画面を作ると現場での使い勝手が上がります。ギャラリーを使った実装はシンプルです。

対象レコードのログだけ絞り込む

ギャラリーの Items に Filter 関数を使って、選択中のレコードに関するログだけ表示します。

Filter(
  '操作ログ',
  TargetID = Gallery_Main.Selected.ID
)

さらに日時の新しい順に並べるなら Sort を追加します。

SortByColumns(
  Filter('操作ログ', TargetID = Gallery_Main.Selected.ID),
  "OperationAt",
  SortOrder.Descending
)

ギャラリーのテンプレート内に OperationAt（日時）・OperationBy（操作者）・Detail（詳細）のラベルを並べれば、最新の操作履歴が時系列で確認できる画面が完成します。

実装時に気をつけること

ログ実装でよくある失敗が、Patchの順序によるIDの取得ミスです。新規登録の直後に最後に追加されたレコードのIDを取るため、Last(Sort(‘申請データ’, ID, SortOrder.Descending)).ID を使う方法が簡便ですが、複数ユーザーが同時に使うアプリでは別の人が登録したIDを取ってしまうリスクがあります。

より確実な方法は、Patchの戻り値を変数で受け取ることです。Patch関数は保存したレコードを戻り値として返すので、以下のように書けば取得したIDが正確です。

Set(
  varNewRecord,
  Patch(
    '申請データ',
    Defaults('申請データ'),
    {
      Title: TextInput_Subject.Text
    }
  )
);

Patch(
  '操作ログ',
  Defaults('操作ログ'),
  {
    Title: "新規登録",
    OperationBy: User().Email,
    OperationAt: Now(),
    TargetID: varNewRecord.ID
  }
)

Set(varNewRecord, Patch(…)) の形で、Patchの戻り値をそのまま変数に格納します。次の行で varNewRecord.ID を参照すれば、今作ったレコードのIDが確実に取れます。SharePointへのデータ読み書きの基本についてはSharePointリストのCRUDパターンの記事も参考になります。

もうひとつ注意したいのが、ログが膨らみすぎる問題です。アクティブに使われるアプリでは、1日に数百件のログが積み上がることもあります。SharePointリストは委任制限（標準2000件）があるため、古いログを定期的にアーカイブするPower Automateのフローを組み合わせることをおすすめします。

まとめ

ログ機能の実装はPatch関数を1本追加するだけです。難しいことは何もありませんが、後付けになると既存のボタンをすべて修正する手間が発生します。新しいアプリを作るときには最初の設計に組み込む習慣をつけると、後々の運用がぐっと楽になります。

入力ミス防止の全体的な設計についてはPower Apps入力ミス防止ガイドにまとめています。バリデーション・UX改善・ログ保存を組み合わせた設計で、信頼性の高いアプリを現場に届けましょう。積み上げた仕組みが業務を守ってくれる、そんな実感が、市民開発を続ける原動力になっていきます。

自分の名前の手打ちは不要！Power Appsでログインユーザー情報を自動入力させる方法

Sat, 11 Apr 2026 11:26:48 GMT

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 コネクタを使えば、ログインユーザーの名前・メール・部署・役職を自動で取得してフォームに埋め込めます。手打ちをゼロにすることで、タイポも二重確認の手間も発生しなくなります。

フォーム設計の全体像を整理したい場合は、フォームコントロールの基本的な仕組みも合わせて読むと、どの場面でどの実装パターンを選ぶかの判断がしやすくなります。市民開発とは、こうした地道な設計の積み重ねです。

入力エラーに関する一覧はこちらの記事をご覧ください。

13桁の手打ちは地獄！Power Appsのバーコードリーダーで入力ミスをゼロにする方法

Sat, 11 Apr 2026 11:26:46 GMT

13桁のJANコードを手打ちするのは地獄です。1桁でも間違えれば、まったく別の商品として登録されてしまいます。Power Appsにはバーコードリーダー機能が標準搭載されており、スマホのカメラでコードを読み取って自動入力できます。入力ミス防止の設計全体についてはPower Apps入力ミス防止ガイドでまとめているので、手入力をなくす設計の位置づけとして確認してください。

この記事では、バーコードスキャナーコントロールの基本的な使い方から、読み取った値をPatchで即座に登録するフロー設計まで解説します。

手入力をやめるのが最強の入力ミス防止策

バリデーションや視覚フィードバックは、ユーザーが誤った値を入力したあとに気づかせる仕組みです。それに対して、そもそも手入力させない設計はミスが起きる余地を根本から消します。

倉庫での在庫管理、店舗での商品登録、資産管理。バーコードやQRコードが印刷されているものを扱う現場では、スキャン入力を取り入れるだけで入力ミスがほぼゼロになります。私が社内で作った棚卸しアプリでも、バーコード入力に切り替えた後からミスの報告がなくなりました。

バーコードスキャナーコントロールの基本

Power Appsでバーコードを読み取るには、バーコードスキャナーコントロールを使います。挿入メニューから追加でき、スマホのカメラを自動的に起動してコードをスキャンします。

コントロールの追加手順

Power Appsの編集画面で、挿入タブを開く
メディアカテゴリからバーコードスキャナーを選択して追加する
コントロール名を BarcodeScanner1 のように分かりやすい名前に変更する
必要に応じてサイズと配置を調整する

読み取った値はBarcodeScanner1.Valueで参照できます。スキャンが完了した瞬間に値が更新されるので、この値をラベルに表示したり、変数にセットしたりして利用します。

OnScanプロパティで読み取り後の処理を設定する

バーコードスキャナーコントロールには、OnScanというプロパティがあります。コードが読み取られた瞬間に実行されるアクションをここに書きます。

読み取った値を変数にセットする例です。

Set(varScannedCode, BarcodeScanner1.Value)

変数に格納しておくことで、スキャン後に画面の別の場所（テキスト入力のDefaultや、Patch関数の引数）からその値を参照できます。

スキャンしてそのままPatchで登録するフロー

最もシンプルな実装は、スキャンと同時にデータを登録してしまうパターンです。棚卸しや入庫確認のように、コードを読んだらその場で記録したい場面に向いています。

OnScanプロパティに直接Patch関数を書きます。

Patch(
    棚卸リスト,
    Defaults(棚卸リスト),
    {
        バーコード: BarcodeScanner1.Value,
        スキャン日時: Now(),
        スキャン者: User().FullName
    }
);

スキャンした瞬間にSharePointリストへ書き込まれます。スキャン日時にはNow()、スキャン者にはUser().FullNameを自動セットするので、誰がいつ読んだかも記録に残ります。

確認ステップを挟むパターン

スキャンしてすぐに登録するのではなく、一旦内容を確認してから保存したい場合は、OnScanで変数にセットし、別の保存ボタンで登録するフローにします。

// OnScan
Set(varScannedCode, BarcodeScanner1.Value);
Set(varShowConfirm, true)

// 保存ボタンのOnSelect
Patch(
    棚卸リスト,
    Defaults(棚卸リスト),
    {
        バーコード: varScannedCode,
        スキャン日時: Now(),
        スキャン者: User().FullName
    }
);
Set(varShowConfirm, false)

varShowConfirmをtrueにした瞬間に確認用のコンテナ（スキャン値を表示するパネル）が表示され、保存ボタンを押したら登録してパネルを閉じる、というUXになります。誤スキャンのやり直しも、保存前なら変数を書き換えるだけで対応できます。

対応コードの種類と注意点

Power Appsのバーコードスキャナーが対応しているコード形式は複数あります。主なものは次のとおりです。

コード形式	用途の例
QRコード	URLや文字列の埋め込み、社内帳票
コード128	物流・在庫管理の国際標準
JANコード（EAN-13）	小売商品のバーコード
コード39	製造業・医療の部品管理

注意点として、暗い環境や印刷が薄いバーコードはスキャン精度が下がります。現場テストは必ず実機スマホで行い、実際の印刷物でスキャンできるかを確認してください。PCのプレビューではスキャン機能は動作しません。

また、スキャンした値はあくまで文字列として取得されます。数値として扱いたい場合はValue関数で変換が必要です。Patchで既存レコードを更新するパターンも合わせて確認しておくと、スキャンデータを既存マスターに紐付ける実装がスムーズになります。

まとめ

バーコードスキャナーコントロールをOnScanとPatchと組み合わせるだけで、手入力ゼロの登録フローが実現します。コードを読むだけで日時も担当者も自動記録されるので、ユーザーの負担が最小になり、ミスも入り込む余地がなくなります。

入力させないことが最強のバリデーションです。現場にバーコードやQRコードがあるなら、ぜひスキャン入力を取り入れてみてください。

北海道なのに新宿区？Power Appsで存在しない組み合わせを防ぐ連動プルダウンの作り方

Sat, 11 Apr 2026 11:26:47 GMT

都道府県で北海道を選んでいるのに、市区町村で新宿区が選べてしまう、こんな入力ミスがデータに混入すると、集計やレポートの段階で大きな問題になります。Power Apps では連動プルダウン（カスケードドロップダウン）を実装することで、存在しない組み合わせをそもそも選べないようにできます。この記事では、Filter 関数を使った連動プルダウンの作り方を、マスターデータの準備から動作確認まで順を追って解説します。

連動プルダウンが必要な理由

Power Apps でドロップダウンを単体で使う場合、各コントロールは互いに独立しています。都道府県の選択結果に関係なく、市区町村の一覧には全都道府県の市区町村がすべて並んでしまいます。ユーザーは意図せず不正な組み合わせを選べてしまい、後工程でデータを使う人が困ることになります。

物流系の社内アプリでこのパターンを経験しました。配送先の都道府県と市区町村を別々のドロップダウンで選ばせていたのですが、誤った組み合わせのデータが数件混入し、配送先への連絡で問題が発生したのです。連動プルダウンに変えてからは、そういったミスは完全になくなりました。

連動プルダウンは業務アプリでよく登場するパターンです。都道府県と市区町村に限らず、大カテゴリと小カテゴリ、部署と担当者、製品ラインとモデル番号など、親子関係のある選択肢ならどこでも同じ設計が使えます。

マスターデータの準備

連動プルダウンを実装するには、大分類と小分類を紐づけたマスターデータが必要です。SharePoint リストを使うのが最も一般的で、委任にも対応しているため大量データにも対応できます。

SharePoint リストの構成はシンプルです。大分類列（例：Prefecture / 都道府県）と小分類列（例：City / 市区町村）の2列を持つリストを作成します。行ごとに「北海道, 札幌市」「北海道, 函館市」「東京都, 新宿区」のように、大分類と小分類の組み合わせを1行ずつ登録します。

データ件数が100件以下の場合は、SharePoint リストの代わりにコレクションをアプリ起動時に作成する方法もあります。コレクションの基本的な使い方を理解していれば、OnStart でマスターデータを定義するアプローチも取れます。ただし将来的なデータ追加のしやすさを考えると、SharePoint リストで管理するほうが運用しやすいです。

Filter 関数で連動させる実装

マスターデータが用意できたら、子のドロップダウンの Items プロパティに Filter 関数を設定します。親のドロップダウンで選ばれた値を条件として、対応する小分類だけを絞り込むのが基本の考え方です。

設定手順

都道府県を選ぶ親ドロップダウン（dd_Prefecture）をキャンバスに配置し、Items に SharePoint リストや Distinct 関数で重複除去した都道府県一覧を設定します
市区町村を選ぶ子ドロップダウン（dd_City）を配置し、Items プロパティに下記の Filter 式を設定します
アプリをプレビューして、親を選択したときに子の選択肢が絞り込まれることを確認します

// dd_City の Items プロパティ
Filter(MasterList, Prefecture = dd_Prefecture.Selected.Value)

Filter 関数の基本的な書き方はギャラリーの絞り込みでよく使いますが、ドロップダウンの Items プロパティにも同じように使えます。Filter の書き方に慣れていない方はそちらの記事も合わせて読むと理解が深まります。

親を変更したときに子をリセットする

連動プルダウンで見落としがちなのが、親の選択を変えたときの子のリセットです。例えば北海道を選んで札幌市を選択した後、都道府県を東京都に変更しても、子のドロップダウンには札幌市が選択状態のまま残ることがあります。これは実際には東京都に存在しない市区町村が選択された状態なので、データとして不正になります。

対策は親ドロップダウンの OnChange プロパティで子をリセットすることです。

// dd_Prefecture の OnChange プロパティ
Reset(dd_City)

この1行を追加するだけで、親を変更したときに子の選択が自動的にクリアされます。

AllowEmptySelection と IsBlank を組み合わせた必須チェック

通常のドロップダウンは初期状態で必ず何かが選択されています。アプリを起動した瞬間から先頭の選択肢が選ばれた状態になるため、IsBlank でチェックしても必ず false が返ってきます。これでは未選択状態を検出できません。

未選択状態を許可したい場合は、ドロップダウンの AllowEmptySelection プロパティを true に設定します。これにより何も選択されていない状態が作れるようになり、IsBlank(dd_Prefecture.Selected.Value) が正しく true を返すようになります。

// 必須チェックの例（AllowEmptySelection: true の場合）
IsBlank(dd_Prefecture.Selected.Value)

必須入力チェックの全体設計については、エラーメッセージの実装パターンでも詳しく解説しています。送信ボタンの制御や varFormSubmitted パターンと組み合わせることで、連動プルダウンの必須チェックも同じ設計の中に自然に組み込めます。

3階層以上の連動プルダウン

都道府県→市区町村→町名のように3階層になる場合も、同じパターンを繰り返すだけです。第2階層の子ドロップダウンをさらに親として、第3階層の子ドロップダウンの Items に Filter を設定します。

ただし、階層が増えるほどリセット処理も階段状に必要になります。第1階層を変更したときは第2・第3階層をリセット、第2階層を変更したときは第3階層をリセット、という具合です。OnChange の中に Reset を複数書けば対応できます。

// dd_Prefecture の OnChange（3階層の場合）
Reset(dd_City);
Reset(dd_Town)

// dd_City の OnChange
Reset(dd_Town)

階層が深い選択肢を扱う場合、マスターデータの列設計が重要になります。それぞれの階層に対応した列を用意し、Filter の条件が確実に一致するように列名と値の形式を統一しておきましょう。

まとめ：選ばせない設計が、後工程を守る

連動プルダウンの実装は Filter 関数1行で実現できます。難しい処理はありませんが、親変更時のリセット処理や AllowEmptySelection の設定を忘れると、不正なデータが入り込む穴が残ります。設計の細部まで意識することが、現場で使い続けられるアプリを作る基本です。

バリデーション設計の全体像は入力ミス防止ガイドにまとめています。個々のテクニックを組み合わせて、ユーザーが迷わず正確に入力できるフォームを作り上げましょう。市民開発とはこういう地道な設計の積み重ねだと、私は思っています。

入力エラーに関する一覧はこちらの記事をご覧ください。

未来の日付は入力禁止！Power Appsのカレンダーで選択可能日を制限する方法

Sat, 11 Apr 2026 11:26:46 GMT

経費精算で「2年後の日付」が入力されていたことがあります。操作ミスとはわかっていても、システムが弾いてくれれば防げた話です。

Power Appsの日付ピッカー（Date Picker）は、デフォルトでは過去・未来を問わず、あらゆる日付を選択できてしまいます。ちょっとした設定を追加するだけで、選択できる範囲をぐっと絞れます。

なぜ日付の誤入力が起きるのか

経費精算・勤怠申請・予定登録など、日付を扱うフォームはPower Appsの定番用途です。しかし現場では、スマホ操作中にうっかりスクロールしすぎて数ヶ月先を選んでしまったり、前月の申請を見ながら入力してそのまま日付を更新し忘れたりと、ありえない日付が登録されるトラブルが後を絶ちません。

データを集計する側は、Excelで月次集計をかけた際に「なぜか未来の行がある」という状況に直面し、その調査と修正に余計な時間を取られます。問題は入力者のミスだけでなく、そもそも選べてしまう設計にあります。

Power Appsのフォームコントロールの基本を理解していれば、日付ピッカーにも同じ考え方が使えます。コントロールのプロパティで制御するのが基本です。

モダン日付ピッカーのStartDate / EndDateプロパティ

Power Appsの日付ピッカーには2種類あります。クラシックとモダンです。現在新しく追加されるコントロールはモダンが主流であり、この記事ではモダン版を前提にします。

モダン日付ピッカーには、StartDateとEndDateという2つのプロパティがあります。この2つを設定するだけで、カレンダー上で選択できる日付の範囲をコントロールが自動的に制限してくれます。バリデーション式を別途書く必要はありません。

設定方法は非常にシンプルです。

過去90日〜今日だけを選択可能にする設定

経費精算のような過去の日付のみのユースケースに向いた設定です。

画面にモダン日付ピッカーを追加します
コントロールを選択した状態で、右ペインまたは数式バーから StartDate プロパティを選びます
次の式を入力します

DateAdd(Today(), -90)

続いて EndDate プロパティに以下を設定します。

Today()

これだけです。カレンダーを開くと、今日より先の日付はグレーアウトされてタップできない状態になります。90日より前の日付も同様です。バリデーション式を一行も書かずに、コントロール自体が入力範囲を守ってくれます。

未来の予定登録（今日〜1年後）を許可する設定

会議室予約や作業予定登録など、未来の日付を入力させたい場合は逆の設定にします。

StartDate：Today()（今日以前は選択不可）
EndDate：DateAdd(Today(), 365)（1年後以降は選択不可）

こちらも設定値を変えるだけで、同じ考え方が使えます。DateAdd関数の第二引数の数値を変えれば、任意の日数に調整できます。

StartDate / EndDate を設定しない場合の挙動

これらのプロパティを設定しない（またはBlankにした）場合、日付ピッカーは制限なしの状態になります。過去も未来も自由に選べてしまうため、申請系フォームには必ず設定する習慣をつけることをおすすめします。

クラシック版との違い：OnChangeバリデーションパターン

クラシック日付ピッカーにはStartDate/EndDateがありません。そのため、選択後に検知するアプローチが必要になります。

具体的には、コントロールの OnChange プロパティにIf関数を書き、条件を満たさない場合にエラー変数をTrueにします。

If(
    DateValue1.SelectedDate > Today(),
    Set(varDateError, true),
    Set(varDateError, false)
)

そして画面上のラベルコントロールに「未来の日付は選択できません」というメッセージを配置し、その Visible プロパティを varDateError に設定します。このラベルはエラーのある間だけ表示されます。

変数を使ったエラーフラグの管理については、グローバル変数とコンテキスト変数の使い分けガイドを参照してください。

ただし現実的には、クラシックコントロールを今から新規で使う機会は少なくなっています。既存アプリの改修でクラシックが残っている場合はOnChangeパターンで対応し、新規作成ならモダン版のStartDate/EndDateを使うのがよいです。

送信ボタンと連動させる

日付の範囲制限とあわせて、送信ボタンのDisplayModeも制御するとより堅牢になります。

クラシックコントロールを使ってOnChangeパターンで実装した場合、varDateError が true のときはボタンを無効化できます。

If(varDateError, DisplayMode.Disabled, DisplayMode.Edit)

モダン日付ピッカーの場合、StartDate/EndDateの範囲外は物理的に選べないため、原則として送信ボタンの追加制御は不要です。ただし、日付が未選択（Blank）のまま送信されるリスクは残ります。IsBlankでの必須チェックは別途行う必要があります。

必須チェックの組み合わせ方については、必須チェックとエラーメッセージの作り方で詳しく解説しています。

DateAdd関数の基本

この記事で繰り返し登場したDateAdd関数について、簡単に補足しておきます。

DateAdd(基準日, 加算する数値, 単位) という構文で、基準日に対して指定した期間を加減算した日付を返します。単位はデフォルトでは「日（Days）」です。月単位や年単位で制限したい場合は第3引数を指定します。

DateAdd(Today(), -3, TimeUnit.Months)  // 3ヶ月前
DateAdd(Today(), 1, TimeUnit.Years)    // 1年後

月末が存在しない日付（例：2月31日）は自動的に調整されます。経費申請なら「当月1日〜今日」、有給申請なら「今日〜3ヶ月後」のように、業務ルールに合わせて柔軟に設定できます。

入力ミス防止の考え方：「選ばせない」が最強

バリデーションの考え方として、エラーを検知して後から弾くより、そもそも選べない設計にするほうが強いです。モダン日付ピッカーのStartDate/EndDateはまさにその考え方を体現したプロパティです。

Power Apps入力ミス防止ガイドでは、こうした「入力させない」設計の全体像を整理しています。フォーマット制御・選択制御・UX向上・自動化の4アプローチから、現場に合う手段を選んでもらえればと思います。

コントロールのプロパティひとつ変えるだけで、誰も傷つかないフォームが作れます。地味ですが、こういうひと手間が積み重なって使いやすいアプリができていくものです。

そのデータ、もうあります！Power Appsで既存データの重複登録を事前に防ぐ

Sat, 11 Apr 2026 11:26:45 GMT

同じ社員番号が2件登録されていた、そのせいでVLOOKUPが意図しない行を返し、給与計算がおかしくなった。そんなトラブルを経験したことはないでしょうか。Power Appsで重複登録を防ぐには、LookUp関数を使った事前チェックが効果的です。入力ミス防止の設計全体についてはPower Apps入力ミス防止ガイドでまとめているので、あわせて参考にしてください。

この記事では、LookUp関数でデータの重複を判定し、送信ボタンをDisabledにするガードレールの作り方を解説します。さらに応用として、自己割り当て禁止（ログインユーザー自身を担当者に選べないようにする）パターンも紹介します。

重複登録が引き起こす現場の問題

取引先管理アプリに同じ会社名が複数登録されると、担当者ごとに異なるレコードを更新してしまい、情報が分断されます。社員番号の重複なら給与・人事データへの影響は深刻です。発覚するのが後になればなるほど、修正のコストが跳ね上がります。

問題は、Power Appsの標準フォームには重複チェック機能が内蔵されていないことです。SubmitForm関数でSharePointに保存する際、既存データと同じ値であっても構わず書き込んでしまいます。防ぐには自分で判定ロジックを組み込む必要があります。

一応私は社内でPower Platformを教える立場なので、新しくアプリを作る人から、気づいたら同じデータが2件あるという相談をよく受けます。ほぼ毎回、重複チェックが実装されていないことが原因です。

LookUp関数で既存データの存在を確認する

LookUp関数は、データソースから条件に一致する最初のレコードを返す関数です。一致するレコードがなければblankを返すので、IsBlankと組み合わせることで重複の有無を判定できます。LookUp関数の基本的な使い方については別記事で詳しく解説しているので、関数の構文に不安がある方は先に確認しておくと理解が深まります。

基本的な判定式は次のとおりです。

!IsBlank(LookUp(社員マスター, 社員番号 = TextInput_EmpNo.Text))

この式は、社員マスターに同じ社員番号が存在する場合にtrueを返します。falseなら重複なし、trueなら重複ありです。

送信ボタンをDisabledにして登録をブロックする

重複チェックの結果を送信ボタンのDisplayModeプロパティに反映させます。重複が検出された場合は送信できないようにします。

If(
    !IsBlank(LookUp(社員マスター, 社員番号 = TextInput_EmpNo.Text)),
    DisplayMode.Disabled,
    DisplayMode.Edit
)

これで、既存の社員番号が入力されている間はボタンが押せなくなります。ボタンは非表示にするのではなく、Disabledのまま表示し続けることが重要です。消してしまうとユーザーがどこに保存ボタンがあるか分からなくなります。

エラーメッセージで理由を伝える

送信ボタンがグレーアウトするだけでは、なぜ送れないかユーザーが分かりません。入力フィールドの直下にラベルコントロールを配置し、重複検出時のみ表示させます。

ラベルのVisibleプロパティに次の式を設定します。

!IsBlank(LookUp(社員マスター, 社員番号 = TextInput_EmpNo.Text))

ラベルのTextプロパティにはこの社員番号はすでに登録されていますという文言を設定し、Colorプロパティは赤にします。これで、重複があるときだけ入力欄のすぐ下に赤いメッセージが表示されます。

委任の警告に注意する

LookUp関数はSharePointやDataverseに対して委任可能な関数ですが、フィルター条件によっては委任の警告が出ることがあります。特に文字列の完全一致（=）は委任されますが、関数を使った変換（例：Lower関数で大文字小文字を無視する）は委任できないことがあります。

委任については委任の警告と対処法の記事で詳しく解説しています。大量データを扱うアプリでは、委任可能な書き方になっているかを必ず確認してください。500件を超えるデータで先頭500件しか検索されない状態だと、重複チェックとして機能しなくなります。

応用：自己割り当て禁止のバリデーション

重複チェックの発想を応用すると、ログインユーザー自身を担当者に選べないようにするバリデーションも実装できます。例えば、承認フローで申請者と承認者が同じ人にならないようにする制御です。

ドロップダウンで担当者を選ぶ場合、選択したユーザーのIDとログインユーザーのIDを比較します。Office365Usersコネクタを使えばログインユーザーのIDを取得できます。

If(
    Dropdown_Approver.Selected.Id = Office365Users.MyProfileV2().id,
    DisplayMode.Disabled,
    DisplayMode.Edit
)

自分自身のIDが選択されている間は送信ボタンがDisabledになり、承認者に自分を指定した状態での送信を防げます。モダンコントロールのドロップダウンでは、ValidationStateプロパティを使った別の実装方法もあります。

If(
    And(varFormSubmitted, Self.Selected.Id = Office365Users.MyProfileV2().id),
    "Error",
    "None"
)

varFormSubmittedは送信ボタンを押したタイミングでtrueに変える変数です。この方法だとフォームの送信を試みたときにだけエラーが発動するので、最初から赤枠が出てユーザーを混乱させることがありません。

まとめ

重複チェックの実装はシンプルです。LookUpで既存レコードを検索し、IsBlankで存在確認、結果を送信ボタンのDisplayModeとエラーラベルのVisibleに反映させる。この3ステップで、ユーザーが気づかないまま重複データを登録してしまう事故をほぼ防げます。

データが壊れてから直すより、入口で守る方がずっと楽です。フォームを作るたびに重複チェックをセットで入れる習慣にすると、後から泣くことが格段に減ります。

スマホ入力のイライラ解消！Power Appsで数値用キーボードを自動表示させる設定

Sat, 11 Apr 2026 11:26:45 GMT

スマホで数量を入力するたびに、日本語キーボードから数字キーボードに切り替えるのは地味にストレスです。Power Appsのテキスト入力コントロールにはFormatプロパティという設定があり、これを変えるだけでスマホに数値専用キーボードを自動表示させることができます。入力ミス防止の設計全体についてはPower Apps入力ミス防止ガイドでまとめているので、スマホ向けフォーム設計の参考に合わせてどうぞ。

この記事では、Formatプロパティの設定方法と、IsNumeric関数を使って数値以外の入力を弾くバリデーションの組み合わせ方を解説します。

なぜスマホのキーボード設定が重要なのか

現場で使われるPower Appsアプリの多くは、スマートフォンで操作されます。倉庫での在庫数入力、営業の訪問件数記録、工場での作業時間報告。どれもスマホから数字を入力する場面です。

デフォルト設定のままだと、テキスト入力コントロールを選択したときに表示されるキーボードは日本語・テキスト用のものです。数字を入力するには、キーボードを数字モードに切り替えてから入力する手間がかかります。1入力あたり数秒の操作でも、1日100件の入力があれば積み重なります。

加えて、テキスト用キーボードからだと誤って全角数字や漢字を入力してしまうリスクもあります。後から集計するときに数値として扱えないデータが混入する原因になります。

Formatプロパティで数値専用キーボードを表示する

テキスト入力コントロールにはFormatプロパティという設定があります。デフォルトはTextFormat.Textですが、これをTextFormat.Numberに変更するだけで、スマホでそのコントロールをタップしたときに数値専用キーボードが自動表示されます。

Formatプロパティの設定手順

Power Appsの編集画面でテキスト入力コントロールを選択する
右側のプロパティパネル、またはツリービューから数式バーを表示する
プロパティのドロップダウンからFormatを選ぶ
値をTextFormat.Numberに変更する

これだけで、スマホでそのフィールドをタップすると数値専用キーボードが表示されます。0〜9のキーとマイナス符号、小数点が並ぶシンプルなキーボードで、誤入力のリスクが大幅に下がります。

社内でスマホ向けの日報アプリを作ったとき、この設定を入れる前後でユーザーから聞こえる声がまったく変わりました。切り替え操作が不要になっただけで、体感的に入力がずいぶんスムーズになったという感想をもらいました。

IsNumeric関数で数値以外の入力を弾く

Formatプロパティを変えても、PCブラウザからアプリを使う人は通常のキーボードで入力します。また、スマホでも数値専用キーボードからテキストを入力できる環境もあります。フォームに数値しか受け付けたくない場合は、IsNumeric関数を使ったバリデーションを追加するのが確実です。

IsNumeric関数は、渡した文字列が数値として解釈できるかどうかをtrue/falseで返します。テキスト入力コントロールのOnChangeプロパティに条件チェックを入れておくと、数値以外が入力されたときに自動でリセットできます。

OnChangeで入力値をリアルタイム検証する

テキスト入力コントロールのOnChangeプロパティに次の数式を設定します。

If(
    Not(IsNumeric(TextInput1.Text)),
    Reset(TextInput1)
)

数値として解釈できない文字が入力されたとき、Reset関数でコントロールを空に戻します。ユーザーが文字を入力しようとしても、即座に消えるためテキストが登録されません。

Notifyで理由をユーザーに伝える

黙ってリセットするだけでは、なぜ入力が消えたかわからずユーザーが戸惑います。Notify関数でポップアップ通知を出すと、入力ルールが明確になります。

If(
    Not(IsNumeric(TextInput1.Text)),
    Notify("数値を入力してください", NotificationType.Error);
    Reset(TextInput1)
)

Notify関数の第2引数にNotificationType.Errorを渡すと、画面上部に赤いエラーバナーが表示されます。NotificationType.Warningなら黄色、NotificationType.Successなら緑のバナーになります。

数値の範囲チェックも組み合わせる

数値であることを確認するだけでなく、値の範囲チェックも一緒に入れておくと実用的なバリデーションになります。例えば年齢チェック（18歳以上のみ受付）や、個数の上限チェック（999個まで）などは現場でよく必要になります。

Value関数でテキストを数値に変換してから比較します。

If(
    Or(
        Not(IsNumeric(TextInput1.Text)),
        Value(TextInput1.Text) < 1,
        Value(TextInput1.Text) > 999
    ),
    Notify("1〜999の数値を入力してください", NotificationType.Error);
    Reset(TextInput1)
)

Or関数で複数の条件をまとめているので、数値でない場合も範囲外の場合も同じエラーメッセージで対処できます。条件によってメッセージを出し分けたい場合は、If文を入れ子にして対応します。

なお、このようなバリデーション設計全体の考え方については、必須チェックとエラーメッセージの作り方の記事でIsBlankやIsEmpty関数を使った実装パターンと合わせて解説しています。フォームバリデーションの設計に取り組む場合は、あわせて確認しておくと全体像がつかみやすいです。

入力ミス防止の設計は入口で決まる

Power Appsのバリデーション設計は、コンテナガイドで解説しているUI設計の原則と同じで、後から直すより最初に入れておく方がコストが低いです。Formatプロパティの変更とIsNumericによる検証は、どちらも数分でできる実装です。

特にスマホ向けアプリでは、入力しやすさがアプリの使用率に直結します。ユーザーがストレスなく入力できる環境を整えることが、正確なデータ収集への近道です。

まとめ

テキスト入力コントロールのFormatプロパティをTextFormat.Numberにすることで、スマホに数値専用キーボードを自動表示できます。さらにIsNumericとNotify・Resetを組み合わせることで、数値以外の入力を弾く確実なバリデーションになります。

設定そのものはシンプルですが、現場のユーザーに与える影響は小さくありません。使いやすさと正確なデータを両立させるために、ぜひフォーム設計の標準として取り入れてみてください。

全角で打たないで…を防ぐ！Power Appsで全角半角の混在や不要な空白を自動制御する方法

Sat, 11 Apr 2026 11:26:45 GMT

全角で打たないでほしい。現場でそう思ったことはありませんか。Power Appsでフォームを作ったはいいものの、入力されたデータを後でExcelに取り込んだらVLOOKUPがことごとくエラー。原因を調べると、ある人は全角スペース、ある人は全角英数字で名前を入力していた。そんな経験が私にも何度もあります。

この記事では、Power Appsで全角・半角の混在や不要なスペースを自動制御する方法を解説します。IsMatch関数とTrim関数を組み合わせれば、入力ミスを保存前に食い止めることができます。

なぜ全角半角の混在が問題になるのか

Power Appsのフォームから入力されたデータは、SharePointリストやExcelシートに保存されます。このとき、VLOOKUPやCOUNTIFといった集計関数は文字の一致判定が厳密で、全角のAと半角のAは別の文字として扱われます。

例えば、20人の営業担当がそれぞれ日報を入力するアプリを想像してください。担当者名を手入力する欄があれば、ある人は全角で入力し、ある人は半角で入力します。月に400件、半年で2,400件のデータが蓄積されたとき、Excel側でピボットを組もうとして同じ人の集計値がバラバラに出てくる。これは実際によくある話です。

問題はデータが登録された後では修正が大変なことです。入力時点で制御するのが最も効率的です。

IsMatch関数で全角文字をリアルタイム検知する

Power AppsのIsMatch関数は、入力値が指定したパターンに一致するかどうかをtrue/falseで返す関数です。正規表現を渡すことができるので、半角英数字以外の文字が含まれているかどうかを判定できます。

BorderColorを使った視覚フィードバック

最もシンプルな実装は、テキスト入力コントロールのBorderColorプロパティをIsMatchの結果に連動させる方法です。半角英数字以外が入力されたときに枠線を赤くすることで、ユーザーに即座に気づかせることができます。

テキスト入力コントロールのBorderColorプロパティに次の数式を設定します。

If(
    IsMatch(TextInput1.Text, "^[a-zA-Z0-9!-/:-@\[-`{-~\s]*$"),
    RGBA(0, 0, 0, 1),
    RGBA(255, 0, 0, 1)
)

正規表現の意味は、先頭から末尾まで半角英数字・記号・スペースのみで構成されているかどうかを判定するものです。全角文字が1文字でも含まれていれば条件に一致しなくなるため、枠線が赤くなります。

送信ボタンを無効化してデータ汚染を防ぐ

枠線の色を変えるだけでは、ユーザーが気づかないまま送信してしまう可能性があります。確実にデータ汚染を防ぐには、送信ボタンのDisplayModeプロパティをIsMatchの結果で制御するのが有効です。

送信ボタンのDisplayModeプロパティに次のように設定します。

If(
    IsMatch(TextInput1.Text, "^[a-zA-Z0-9!-/:-@\[-`{-~\s]*$"),
    DisplayMode.Edit,
    DisplayMode.Disabled
)

全角文字が入力されている間はボタンがグレーアウトして押せなくなります。ボタンは常に表示したままDisabledにするのがポイントです。非表示にしてしまうと、ユーザーが保存方法を見失ってしまいます。

Trim関数でコピペ由来の不要スペースを除去する

全角半角の問題とは別に、コピペ操作による末尾スペースも集計ミスの原因になります。見た目では気づかないのに、VLOOKUPがエラーになってしまう。その犯人がこの見えない空白です。

Power AppsのTrim関数とTrimEnds関数は、文字列から余分なスペースを取り除きます。TrimとTrimEndsの違いを簡単にまとめると、Trimは文字列の先頭・末尾・単語間の余分なスペースをすべて除去するのに対し、TrimEndsは先頭と末尾のスペースだけを除去します。コピペ時の末尾スペース対策にはTrimEndsで十分なことが多いです。

保存時にTrimEndsで自動クリーニングする

ユーザーに気づかせずに自動でスペースを除去するには、Patchで保存する際にTrimEndsで値を包む方法がシンプルです。

Patch(
    '担当者リスト',
    Defaults('担当者リスト'),
    {
        担当者名: TrimEnds(TextInput1.Text),
        電話番号: TrimEnds(TextInput2.Text)
    }
)

入力フォームに保存ボタンがあり、そのOnSelectプロパティにPatchを書いている場合は、このように各フィールドをTrimEndsで囲むだけです。ユーザーは意識しなくてよく、保存されるデータは常にクリーンな状態になります。

DelayOutputで入力中のストレスを減らす

IsMatchを使ったリアルタイムチェックは便利ですが、1文字入力するたびに枠線が赤くなるとユーザーがイライラすることがあります。例えば電話番号を入力中に最初の1桁を打った瞬間から赤くなれば、入力途中なのにエラー扱いされている気分になります。

この問題を解決するのがDelayOutputプロパティです。テキスト入力コントロールのDelayOutputプロパティをtrueに設定すると、入力が止まってから約1秒後に値の再評価が行われます。タイプ中に即座にエラーが出るのを防ぎ、入力が落ち着いてから判定するUX設計になります。

設定は簡単で、テキスト入力コントロールのDelayOutputプロパティをtrueにするだけです。デフォルトはfalseなので、リアルタイムバリデーションを使う場面では積極的にtrueにすることをおすすめします。

実装パターンの組み合わせ方

ここまでで紹介した方法は、組み合わせて使うのが実践的です。個人的には次の組み合わせをよく使います。

DelayOutputをtrueにして入力中のチラつきを防ぐ
BorderColorをIsMatchで赤/黒に切り替えて視覚フィードバック
送信ボタンのDisplayModeをIsMatchで制御してデータ汚染ブロック
Patchの際にTrimEndsで末尾スペースを自動除去

この4つをセットで設計しておくと、全角入力も末尾スペースも保存されることがありません。フォームを作るたびに同じ設計を踏襲するようにしたところ、社内でデータの集計ミスがほぼなくなりました。

なお、IsMatchの正規表現については、テキスト関数ピラー記事でも関連する文字列操作の関数をまとめているので、合わせて参考にしてください。また、入力フォームのバリデーション設計全体については、必須チェックとエラーメッセージの作り方の記事で詳しく解説しています。バリデーション全体の設計思想については、コンテナ完全ガイドでもUI/UX観点から触れています。

まとめ

Power Appsで全角半角の混在や不要スペースを防ぐには、IsMatch関数とTrim関数の組み合わせが効果的です。IsMatchで全角文字を検知して送信ボタンをDisabledにし、保存時にTrimEndsで末尾スペースを除去する。この設計を入れておくだけで、後から集計がつらくなる状況をかなり防げます。

データの整備を後からやるのは、作り直すのと同じくらい大変です。入力時点で正しいデータを作る設計に、最初から投資するのが結果的には早いです。市民開発とはそういう地道な積み重ねだと思っています。

入力エラーに関する一覧はこちらの記事をご覧ください。

【保存版】Power Apps入力ミス防止ガイド！現場が助かるUI/UX設計の極意

Sat, 11 Apr 2026 11:26:47 GMT

なぜ入力ミスはなくならないのか

Power Appsでアプリを作ってデータを蓄積し始めたはいいものの、全角と半角が混在していてVLOOKUPがエラーになる、ありえない日付が登録されている、メアドが@なしで保存されていた、そんな経験はないでしょうか。

入力ミスは、使う人が悪いのではありません。ミスが起きやすい設計になっているのが原因です。Power Appsには、ミスを事前に防ぐための仕組みが豊富に用意されています。この記事では、入力ミス防止の4つのアプローチを体系的に整理して解説します。

入力ミスが現場に与えるコスト

私が勤める物流会社では、かつてExcelの集計作業を担当する社員が毎月頭を抱えていました。社内システムから出力したデータに株式会社と（株）が混在し、取引先ごとの集計が崩れてしまうのです。VLOOKUPは完全一致で判定するため、表記ゆれが1文字あるだけで別のデータとして扱われます。

こうした問題の根本は入力時に遡ります。入力した人に悪意はなく、ただどう入力すればいいか分からなかっただけです。Power Appsでアプリを設計する立場になった今、入力制御はアプリ品質の根幹だと痛感しています。

入力ミスが引き起こすコストは大きく3つに分類できます。

データクレンジングの工数（月次で何時間も費やす）
ミスに気づくまでのタイムラグ（登録から数週間後に発覚するケースが多い）
信頼性の低下（集計値を疑い始めると、データ活用そのものが止まる）

入力ミス防止の4つのアプローチ

Power Appsで入力ミスを防ぐ手法は、大きく4つのカテゴリに整理できます。それぞれが異なる種類のミスに対処するもので、現場のニーズに合わせて組み合わせて使うのがおすすめです。

アプローチ①：テキスト入力の自動制御（フォーマット・表記ゆれ）

テキスト入力のミスで最も多いのが、全角半角の混在と不要な空白です。手作業による入力では、半角英数字と指定していても全角で打ち込む人が必ず出てきます。コピペ時に末尾に見えない空白（スペース）が紛れ込むことも日常的です。

こうした表記ゆれは、Trim関数やValue関数、IsMatch関数の正規表現を使ってアプリ側で吸収できます。保存ボタンを押した瞬間に自動で正規化する設計にすれば、ユーザーは意識せずに正しいデータを登録できます。文字列置換や大文字小文字統一についてはPower Appsテキスト関数の使い方の記事が参考になります。

アプローチ②：フォーマットチェック（IsMatch関数）

メールアドレスや電話番号のように形式のルールがあるデータには、IsMatch関数によるフォーマット検証が有効です。Power Appsにはメールアドレス形式（Match.Email）や数字のみ（Match.Digit）など、よく使うパターンが組み込まれています。

IsMatch関数は入力中にリアルタイムで評価できるため、入力が正しければ緑のチェックアイコンを表示し、間違っていたら入力欄の枠線を赤くするというUXを作れます。ユーザーが送信ボタンを押す前に気づけるので、後からエラーになるよりずっとストレスが少なくなります。

アプローチ③：UI・選択制御（選ばせ間違いを防ぐ）

自由入力ではなく選択肢から選ばせる設計にすれば、そもそも表記ゆれは発生しません。ドロップダウンやコンボボックスを使って選べる範囲を絞るのが最も根本的な対策です。

さらに踏み込んで実装したいのが、連動プルダウン（カスケード接続）です。都道府県を選んだら市区町村の選択肢が絞られる設計にすれば、北海道なのに新宿区を選ぶという論理的にありえない組み合わせを防げます。Filter関数と子ドロップダウンのItemsプロパティを組み合わせることで実現できます。Filter・Search・LookUp関数の使い分けガイドで基本的な絞り込みの書き方を確認しておくと理解が深まります。

必須項目のチェック（IsBlank関数）や重複登録の防止（LookUp関数で既存データを事前確認）も、このカテゴリに含まれます。必須チェックのエラーメッセージ設計については、サテライト記事で詳しく解説しています。

アプローチ④：日付・数値の範囲制限

日付ピッカーは標準設定だとすべての日付が選べてしまいます。経費精算アプリで来月の日付や10年前の日付を入力できると、後から人の目でチェックするしかなくなります。

モダン日付ピッカーコントロールには StartDate と EndDate のプロパティがあり、ここに Today() を使った数式を設定するだけで選択可能な日付の範囲を制限できます。バリデーション式を書く必要もなく、コントロール自体が制御してくれるのでシンプルです。

数値入力のキーボード制御も地味に重要です。スマホで数量を入力するたびに日本語キーボードから数字に切り替えるのは、現場のユーザーには小さなストレスの積み重ねです。テキスト入力コントロールの Format プロパティを Number に設定するだけで、スマホ操作時に数値専用キーボードが自動的に表示されるようになります。

4つのアプローチの選び方

現場で実際に使うとき、どのアプローチを選べばいいかを整理してみます。

入力の種類	推奨アプローチ	主な関数・設定
会社名・住所など自由テキスト	①テキスト自動制御	Trim / Value / Lower / Upper
メールアドレス・電話番号	②IsMatchフォーマットチェック	IsMatch / Match.Email / Match.Digit
部署・カテゴリ・ステータス	③選択制御	Dropdown / ComboBox / Filter
日付・数量・金額	④範囲制限	StartDate / EndDate / Format=Number
必須項目	共通	IsBlank / DisplayMode.Disabled

重要なのは組み合わせることです。たとえば担当者欄であれば、自由入力をやめてユーザーピッカーコントロールに変えつつ（アプローチ③）、必須チェック（IsBlank）でガードする、という2重の設計にするのがおすすめです。

ボタンのDisabledとエラーメッセージの設計

バリデーション設計で見落としがちなのが、送信ボタンの見た目の扱いです。入力が不完全な状態でボタンを非表示にすると、どこに保存するのかと迷うユーザーが出てきます。一方で DisplayMode.View を使うと見た目は表示されていてもクリックできないため、ユーザーを混乱させます。

正解は常に表示し、DisplayMode.Disabled で押せない状態にすることです。条件が揃ったときだけ DisplayMode.Edit に切り替えます。グローバル変数とコンテキスト変数の使い分けの記事でエラーフラグの管理方法を確認しておくと、実装がスムーズです。

エラーメッセージは、入力欄の直下に赤字のラベルを配置し、Visible プロパティで動的に表示するのが現場で最もわかりやすいパターンです。画面上部に小さく出る標準エラーは、スクロールしていると気づかないことが多い。入力欄のすぐ隣で伝えるのが親切な設計です。

まとめ：設計で防ぐ、仕組みで守る

入力ミスは使う人の問題ではなく設計の問題です。4つのアプローチ（テキスト自動制御・IsMatchフォーマットチェック・選択制御・範囲制限）を組み合わせることで、大半の入力ミスはアプリ側で未然に防げます。

完璧なバリデーションを最初から実装する必要はありません。まずはこのフィールドで一番多いミスは何かを現場に聞いてみてください。そこから1つずつ対策を加えていく、地道な積み重ねがデータ品質を上げていきます。Power Apps開発の全体マップも合わせて参照すれば、バリデーション設計をアプリ開発全体の中に位置づけて考えることができます。

楽しみながら、データを守る設計を作っていきましょう。

Power Appsでメアドや電話番号の形式間違いを防ぐ！IsMatch関数を使ったフォーマットチェック術

Sat, 11 Apr 2026 11:26:46 GMT

「@」マークのないメールアドレスが登録されていたことがあります。入力した本人は正しいつもりでも、システムはそのまま通してしまいます。

IsMatch関数を使えば、メールアドレスや電話番号の形式をリアルタイムでチェックし、間違いがあれば即座にフィードバックできます。正規表現と聞くと難しそうですが、Power Appsには組み込みパターンが用意されているので、意外とシンプルに実装できます。

なぜ形式チェックが必要か

名簿登録・問い合わせフォーム・社内申請など、メールアドレスや電話番号を入力させる場面は多いです。しかし「必須チェック（IsBlank）」だけでは、何かが入力されているかどうかしか確認できません。

問題は「形式が正しいかどうか」です。「test@」や「090-1234」のような不完全な値も、IsBlankの観点では合格してしまいます。後から連絡を取ろうとしたとき、データが使い物にならないと気づいても遅いです。

IsMatch関数はこの問題に対処するための関数です。入力値が指定したパターンに一致するかどうかをtrueかfalseで返します。必須チェックと組み合わせることで、「何か入力されていて、かつ正しい形式である」ことを同時に保証できます。

Power Apps入力ミス防止ガイドでも、フォーマット制御はバリデーションの重要な柱として位置づけています。

IsMatch関数の基本構文

IsMatch関数の基本的な書き方は次のとおりです。

IsMatch(テキスト, パターン)

第一引数に検証したいテキスト、第二引数にパターンを指定します。パターンには、Power Appsが用意している組み込みパターン（Match列挙型）か、正規表現文字列を使います。

戻り値はtrueまたはfalseです。一致すればtrue、一致しなければfalseが返ります。

組み込みパターン一覧

Power Appsには、よく使うパターンがあらかじめ定義されています。

パターン	意味	使いどき
Match.Email	メールアドレス形式	メアド入力欄
Match.Digit	1桁の数字	電話番号・郵便番号（繰り返しと組み合わせ）
Match.Letter	1文字のアルファベット	英字チェック
Match.MultipleLetters	1文字以上のアルファベット	英単語チェック
Match.MultipleDigits	1桁以上の数字列	数値文字列の汎用チェック

メールアドレスのチェックなら、こう書きます。

IsMatch(txtEmail.Text, Match.Email)

実装パターン①：変数＋アイコンでリアルタイムフィードバック

入力中に正誤をリアルタイムで表示するUXは、ユーザーのストレスを大幅に減らします。実装のポイントは3つです。

OnChangeプロパティで変数をセット

テキスト入力コントロールのOnChangeプロパティに、次の式を書きます。

If(
    IsMatch(txtEmail.Text, Match.Email),
    Set(varValidEmail, true),
    Set(varValidEmail, false)
)

入力のたびにIsMatchが評価され、結果が変数に格納されます。

アイコンコントロールで合否を視覚化

チェックアイコンと警告アイコンを組み合わせて表示します。アイコンコントロールの各プロパティを次のように設定します。

Icon：If(varValidEmail, Icon.Check, Icon.Warning)
Color：If(varValidEmail, Color.Green, Color.Red)
Visible：Not(IsBlank(txtEmail.Text))（未入力時は非表示）

これで、入力が始まったらアイコンが現れ、正しい形式ならチェックマーク、間違っていれば警告マークが表示されます。入力前から赤いアイコンが出て「なぜ怒られてるの？」となるのを防ぐ工夫です。

DelayOutputで入力途中の誤検知を防ぐ

テキスト入力コントロールには DelayOutput プロパティがあります。これをtrueにすると、入力が止まってから約1秒後にOnChangeが発火します。デフォルト（false）では1文字打つたびに評価されるため、入力途中でずっとエラー表示になるストレスが生まれます。

実務では DelayOutput を true にするのをおすすめします。設定場所はコントロールのプロパティパネル、または数式バーから直接 DelayOutput: true と書きます。

実装パターン②：背景色で視覚フィードバック

アイコンを使わず、入力欄の背景色を変えてフィードバックするパターンもあります。テキスト入力コントロールの Fill プロパティに次の式を設定します。

If(
    varValidEmail,
    Color.White,
    If(IsBlank(txtEmail.Text), Color.White, Color.LightCoral)
)

ポイントは、空欄のときは白（エラー色にしない）、入力後に不正なら薄赤、正しければ白に戻るという3段階の制御です。未入力なのに赤くなると、フォームを開いた瞬間から全項目が赤くなって見た目が悪くなります。

枠線を赤くするパターンは、未入力項目の枠線を赤く光らせるUX改善の記事で詳しく解説しています。

正規表現を使ったカスタムパターン

組み込みパターンでは対応できない場合、正規表現文字列を直接指定できます。

電話番号（10桁または11桁の数字）のチェック

IsMatch(txtPhone.Text, "d{10,11}")

ハイフンなしの数字のみを想定した場合のパターンです。ハイフンありの形式（例：090-1234-5678）を許容する場合は、パターンを調整する必要があります。

IsMatch(txtPhone.Text, "d{2,4}-d{2,4}-d{4}")

URLの先頭チェック

URLが「https://」から始まっているかどうかだけ確認したい場合は、MatchOptions.BeginsWithを第3引数に指定します。

IsMatch(txtURL.Text, "https://", MatchOptions.BeginsWith)

MatchOptionsを使うことで、文字列全体ではなく「先頭だけ」「末尾だけ」の部分マッチも可能になります。

送信ボタンの制御と組み合わせる

バリデーションを実装しても、ボタンを制御しなければ無効な値のまま送信できてしまいます。送信ボタンのDisplayModeプロパティに次の式を設定します。

If(
    Or(IsBlank(txtEmail.Text), Not(varValidEmail)),
    DisplayMode.Disabled,
    DisplayMode.Edit
)

メールアドレスが空欄か、形式が不正な場合はボタンが押せない状態になります。複数フィールドを同時にチェックする場合はOrでつなげていきます。

変数を使ったエラーフラグの設計については、グローバル変数とコンテキスト変数の使い分けガイドも参考にしてください。

IsMatchを使う上での注意点

IsMatch関数を使い始めると、いくつかの落とし穴に気づきます。

ひとつは、組み込みパターン Match.Email は厳密なRFC準拠ではないという点です。実務上のメールアドレスのほぼすべてはカバーできますが、極めて特殊な形式に対応しきれない場合があります。実用上は問題になりません。

もうひとつは、入力欄が空欄のとき IsMatch は false を返すという点です。IsBlankとIsMatchを組み合わせる場合、「空欄かどうか」と「形式が正しいかどうか」を別々に判定するか、空欄時だけ評価を免除する設計を明示的に書く必要があります。

If(
    IsBlank(txtEmail.Text),
    true,  // 空欄は別途必須チェックに任せる
    IsMatch(txtEmail.Text, Match.Email)
)

このように役割を分けて書くと、それぞれのチェックが独立してわかりやすくなります。

フォームの品質はバリデーションの積み重ねでできている

IsMatch関数は、コントロールのOnChangeに数行書くだけで動作します。正規表現というと身構えてしまいがちですが、Match.Emailなどの組み込みパターンがあれば正規表現を書かずに済むケースが大半です。

アイコンの切り替えやDelayOutputの設定も含めて、実装そのものは30分かからないと思います。それで連絡先データの品質が大きく上がるなら、やっておく価値は十分あります。トライしてみましょう。

送信ボタンの連打によるデータ二重登録を防ぐ！Power Appsのボタン制御テクニック

Sat, 11 Apr 2026 11:26:48 GMT

社内アプリで同じデータが2件・3件と登録されているというトラブルに遭遇したことはありませんか。原因のほとんどは送信ボタンの連打です。処理が重いときやネットワークが遅いときに、ユーザーが押せた？と思って何度もボタンをタップしてしまい、同じデータが複数作られます。この記事では、変数と DisplayMode を組み合わせた連打防止の実装方法を解説します。

なぜ連打問題が起きるのか

Power Apps で SubmitForm や Patch 関数を実行したとき、処理が完了するまでの数秒間、画面には何も変化が起きません。特にモバイル環境や SharePoint リストへの書き込みは、通信状況によって 1〜3 秒かかることもあります。ユーザーはボタンが反応していないと判断して、もう一度タップします。

私が展開した日報アプリで、まさにこの問題が起きました。20人のスタッフが使うアプリで、1日に数件ずつ重複データが登録されていたのです。現場からは、保存を何回か押さないと保存されない気がして…という声がありました。処理中であることをユーザーに伝えないまま放置したのが原因でした。

解決策は2つのアプローチを組み合わせることです。1つ目は処理中のボタンを押せない状態にすること。2つ目はいま処理中ですよとユーザーに伝えることです。

varIsSubmitting 変数でボタンを制御する

基本的な実装パターンを解説します。varIsSubmitting という変数を用意し、送信処理の前後でフラグを切り替えます。処理中は true になるため、ボタンを DisplayMode.Disabled に変えて押せなくします。

変数の基本的な使い方を理解していれば、実装は難しくありません。UpdateContext か Set のどちらを使うかはスコープによって選びます。フォーム送信は通常1画面内の処理なので UpdateContext で十分ですが、複数画面をまたぐ場合は Set を使います。

送信ボタンの OnSelect

// 送信ボタンの OnSelect
UpdateContext({varIsSubmitting: true});
SubmitForm(Form1);
UpdateContext({varIsSubmitting: false})

送信ボタンの DisplayMode プロパティ

// 送信ボタンの DisplayMode プロパティ
If(varIsSubmitting, DisplayMode.Disabled, DisplayMode.Edit)

ただし、SubmitForm はフォームコントロールの非同期処理を内包しているため、OnSelect の3行目（varIsSubmitting を false に戻す処理）が SubmitForm の完了を待たずに実行されることがあります。確実な制御には OnSuccess・OnFailure イベントでフラグをリセットする方法がより堅牢です。

// フォームの OnSuccess プロパティ
UpdateContext({varIsSubmitting: false});
Navigate(Screen_List, ScreenTransition.Fade)

// フォームの OnFailure プロパティ
UpdateContext({varIsSubmitting: false})

Or 条件で複数バリデーションと組み合わせる

実際のフォームでは、送信ボタンの制御条件が連打防止だけでなく、バリデーションの結果とも連動していることがほとんどです。複数の条件を Or でまとめることで、1つでも問題があればボタンが押せない設計にできます。

// 送信ボタンの DisplayMode（バリデーション複合）
If(
  Or(
    varIsSubmitting,
    IsBlank(TextInput_Name.Text),
    IsBlank(TextInput_Email.Text),
    lbl_EmailError.Visible
  ),
  DisplayMode.Disabled,
  DisplayMode.Edit
)

この Or 条件をそのまま書き続けると、フィールドが増えるたびに条件式が長くなり管理が難しくなります。そこで名前付き計算式の書き方を使い、formValid という named formula にまとめるアプローチが有効です。App.Formulas に定義することで、各ボタンの条件式を formValid の1参照だけに簡潔化できます。

タイマーを使った堅牢な送信パターン

モダンフォームを使っている場合は、タイマーコントロールを組み合わせた設計がより確実です。Power Apps の OnSelect は処理を同時評価するため、変数のセット→バリデーション再評価→フォーム送信という順序を素直な記述で保証できません。

タイマーパターンは次のように設計します。送信ボタンを押すとタイマーが起動し、100〜200ミリ秒後に OnTimerEnd が発火します。この時点でバリデーションが再評価されているため、formValid が true の場合のみ SubmitForm を実行します。

// 送信ボタンの OnSelect
Set(varFormSubmitted, true);
UpdateContext({varIsSubmitting: true});
UpdateContext({varStartTimer: false});
UpdateContext({varStartTimer: true})  // タイマー起動

// Timer コントロールの Duration: 150
// Timer コントロールの Start プロパティ: varStartTimer

// Timer コントロールの OnTimerEnd
If(
  formValid,
  SubmitForm(Form1),
  UpdateContext({varIsSubmitting: false})
)

このパターンは少し複雑に見えますが、一度テンプレートとして作ってしまえばどのフォームにも使い回せます。私はこのパターンをスニペットとして保存しており、新しいフォームを作るたびにコピーして使っています。

ローディングスピナーでユーザーに処理中を伝える

連打を防ぐだけでなく、ユーザーにいま処理中ですと伝えることも重要です。ボタンが灰色になるだけでは気づかないユーザーもいます。簡単な方法は varIsSubmitting が true のときにボタン上にラベルを重ねて、保存中…と表示することです。

// ローディングラベルの Visible プロパティ
varIsSubmitting

// ローディングラベルの Text プロパティ
"保存中..."

もう少し手間をかける場合は、GIF アニメーション画像をボタンの上に重ねて表示する方法もあります。ローディングスピナーのGIFをアプリのメディアに追加し、Image コントロールの Visible を varIsSubmitting で制御します。

視覚フィードバックの設計は、バリデーションのエラー表示と同様にユーザーが今何が起きているかわかる状態を作ることが目的です。コンテナを使ったレイアウト設計と組み合わせることで、ローディング表示の重ね配置もすっきり管理できます。

まとめ：処理中を見える化する設計で信頼感を上げる

連打防止の実装は varIsSubmitting 変数と DisplayMode.Disabled の組み合わせで実現できます。さらにローディング表示を加えることで、ユーザーが迷わずアプリを使える状態になります。

重複登録が発生するアプリは、現場への信頼感を大きく損ないます。またデータが重複してたという経験を積み重ねると、アプリへの信頼が失われ、最終的には紙に戻ってしまうことすらあります。連打防止はシンプルな実装ですが、アプリの信頼性を守る重要な設計です。地道なUX改善の積み重ねが、長く使われるアプリを作ります。

入力エラーに関する一覧はこちらの記事をご覧ください。

本当に送信しますか？Power Appsで入力内容のプレビューと確認ダイアログを作る方法

Sat, 11 Apr 2026 11:26:47 GMT

送信ボタンをタップした瞬間、画面が切り替わって「あ、間違えた」——そんな経験はありませんか。Power Appsは一度Patchで保存してしまうと簡単に取り消せません。だからこそ、送信前に確認ダイアログを挟む設計が重要です。

なぜ確認ダイアログが必要なのか

スマートフォンで使うアプリであれば、タッチ操作のミスは日常茶飯事です。フォームに5〜6項目入力して、最後に送信ボタンを押した瞬間に「あ、担当者を間違えた」と気づく。そのまま登録されてしまうと、後から上司に「この件誰が対応してるの？」と聞かれる羽目になります。

私が現場でアプリを使ってもらい始めた頃、一番多かった問い合わせが「間違えて登録してしまった、消してほしい」でした。SharePointリストから手動で削除する作業が積み重なると、それだけで1日数十分が消えていきます。確認ダイアログひとつで、その手間が丸ごとなくなります。

また、申請・承認フローと連動しているアプリなら、誤送信のコストはさらに大きくなります。一度承認フローが走り始めると、承認者に不要な通知が届いてしまいます。送信前に「本当によろしいですか？」と聞く一手間は、関わる全員の時間を守ることにつながります。

確認ダイアログの基本設計

Power Appsには標準の確認ダイアログ機能はありません。ですので、コンテナとラベルを組み合わせて自分で作る必要があります。仕組みはシンプルで、変数を使ってダイアログの表示・非表示を切り替えるだけです。

ダイアログの表示制御（変数の役割）

まず、ダイアログの表示状態を管理するための変数を用意します。名前は varShowConfirmDialog とします。ボタンを押したら変数を true にし、ダイアログ内のキャンセルを押したら false に戻す——これが基本の動きです。

送信ボタンの OnSelect プロパティに以下を設定します。

Set(varShowConfirmDialog, true)

これだけで送信処理は実行せず、まずダイアログを表示する動きになります。

ダイアログ本体の作り方

ダイアログはコンテナで作ります。画面上に半透明の黒いオーバーレイを被せ、その上に白いカードを浮かせるデザインが一般的です。実装手順は以下の通りです。

新しいコンテナを追加し、名前を con_ConfirmDialog とする
Visible プロパティを varShowConfirmDialog に設定（変数が true のときだけ表示）
コンテナの Width と Height を画面いっぱいに広げる（Parent.Width、Parent.Height）
コンテナ内に半透明の背景レイヤー用コンテナ（Fill: RGBA(0,0,0,0.5)）を作る
その上に白いカードコンテナを重ねる（Z-indexは自動で前面になる）

コンテナを使ったUIの基礎については、コンテナのドロップシャドウとカードUIの記事も参考になります。ドロップシャドウを加えると、ダイアログが画面から浮いているような立体感が出てより見やすくなります。

プレビュー表示の実装

確認ダイアログに入力内容をそのまま表示することで、ユーザーは送信前に内容を見直せます。実装は非常にシンプルで、ラベルの Text プロパティにフォームのコントロール参照を書くだけです。

テキスト入力の内容を表示する

例えば、フォームに氏名・件名・メモの3項目があるとします。ダイアログ内に配置したラベルの Text プロパティをそれぞれ以下のように設定します。

"氏名：" & TextInput_Name.Text
"件名：" & TextInput_Subject.Text
"メモ：" & TextInput_Memo.Text

これでダイアログを開いたときに入力内容がそのまま表示されます。ドロップダウンの場合は Dropdown.Selected.Value、日付ピッカーの場合は Text(DatePicker.SelectedDate, "YYYY/MM/DD") のように参照方法が変わるので、コントロールの種類に合わせて調整してください。

必須項目の未入力チェックと組み合わせる

確認ダイアログを出す前に、必須項目の入力チェックを済ませておくのが理想です。未入力のまま確認ダイアログが開いても意味がないので、送信ボタンの OnSelect に条件を追加します。

If(
  IsBlank(TextInput_Name.Text) || IsBlank(TextInput_Subject.Text),
  Notify("必須項目を入力してください", NotificationType.Error),
  Set(varShowConfirmDialog, true)
)

入力チェックの詳しい実装については、必須チェックとエラーメッセージの作り方の記事で解説しています。バリデーションの変数管理との組み合わせ方も参考になるので、あわせて読んでみてください。

確認・キャンセルボタンの動作設定

ダイアログ内には送信確定のボタンとキャンセルボタンの2つを置きます。それぞれの動作は明確に分けます。

確定ボタン（送信実行）

確定ボタンの OnSelect では、実際のデータ保存処理と変数のリセットをまとめて行います。

Patch(
  '申請リスト',
  Defaults('申請リスト'),
  {
    Title: TextInput_Name.Text,
    件名: TextInput_Subject.Text,
    メモ: TextInput_Memo.Text
  }
);
Set(varShowConfirmDialog, false);
Notify("送信が完了しました", NotificationType.Success);
Navigate(Screen_Complete)

保存後にダイアログを閉じて完了通知を出し、完了画面へ遷移する流れです。二重送信を防ぐために、Patch処理が完了するまでボタンを無効化する設計も有効です。その方法については連打防止とボタン制御の記事が参考になります。

キャンセルボタン（ダイアログを閉じる）

キャンセルボタンはシンプルです。変数を false にするだけでダイアログが消えます。

Set(varShowConfirmDialog, false)

大切なのはキャンセルしたらフォームの入力内容はそのまま残すことです。入力をリセットしてしまうと、ユーザーが確認画面を見てから内容を直そうとしたときに入力し直す手間が生じます。確認 → キャンセル → 修正 → 再確認の流れが自然に使えるよう設計しましょう。

応用：入力内容をテーブル形式で表示する

項目数が多い場合は、ラベルを縦に並べるよりもギャラリーでテーブル表示するほうがすっきり見えます。コレクションを使ってプレビュー用データを一時的に組み立てる方法が便利です。

送信ボタンの OnSelect で、確認ダイアログを開く直前にコレクションを作ります。

ClearCollect(
  colPreview,
  {項目: "氏名", 内容: TextInput_Name.Text},
  {項目: "件名", 内容: TextInput_Subject.Text},
  {項目: "メモ", 内容: TextInput_Memo.Text}
);
Set(varShowConfirmDialog, true)

あとはダイアログ内にギャラリーを配置し、Items を colPreview に設定するだけです。テンプレート内に「項目」ラベルと「内容」ラベルを並べると、入力内容が一覧で確認できる表になります。項目が増えても ClearCollect に1行追加するだけで対応できるので、後からのメンテナンスも楽です。

ダイアログ設計で気をつけること

確認ダイアログを実装するときに私がよくやってしまうのが、ダイアログコンテナのZ-order（前後の重なり順）の問題です。コンテナを後から追加したつもりが、ツリービューで見ると他のコントロールの下に入ってしまっていることがあります。ダイアログが他のコントロールに隠れて見えない場合は、ツリービューでダイアログのコンテナを一番下（画面上では最前面）に移動してください。

もうひとつ注意したいのが、ダイアログを閉じた後の変数リセットです。画面の OnVisible プロパティで Set(varShowConfirmDialog, false) を設定しておくと、別の画面から戻ってきたときに意図せずダイアログが開いている状態を防げます。変数の初期化は変数の種類と使い分けの記事で詳しく解説しているので、変数管理を整理したい方はあわせて確認してみてください。

まとめ

確認ダイアログの実装はそれほど複雑ではありません。変数1つ、コンテナ1つあれば基本的な仕組みは作れます。重要なのは設計の考え方で、間違えた後に直す仕組みより間違えないように確認させる仕組みのほうが、結果的に運用コストが下がります。

入力ミス防止の全体像については、Power Apps入力ミス防止ガイドにまとめています。バリデーション・フォーマット制御・UX設計の組み合わせで、ミスが起きにくいアプリを目指しましょう。市民開発はこういう地道な積み上げの繰り返しだと、現場で何度も実感しています。

「未入力です」と優しく伝える！Power Apps必須チェックと分かりやすいエラーメッセージの作り方

Sat, 11 Apr 2026 11:26:49 GMT

Power Apps のフォームで送信ボタンを押したとき、画面上部にちっぽけなエラーが出て終わる。そんな経験はありませんか。ユーザーはそのエラーに気づかず再度ボタンを押し、なんで保存されないの？と混乱します。入力ミスを防ぐには、エラーをユーザーの目線で、わかりやすい場所に、わかりやすい言葉で伝える設計が必要です。

この記事では、Power Apps で必須チェックを実装し、入力項目のすぐ下にエラーメッセージを出す方法を解説します。

標準フォームのエラー表示が弱い理由

Power Apps の標準フォーム（EditForm）には SubmitForm 関数を使った保存機能があり、必須列の未入力も検出してくれます。ところが、そのエラーは画面上部のシステムメッセージとして表示されるだけです。スマホアプリで画面を下にスクロールしていると、上部のエラーは視野の外に出てしまい、ユーザーがエラーに気づかないまま何度もボタンを押すことになります。

私が社内でアプリを展開したとき、現場のスタッフから、保存ボタンを押しても何も起きないという報告が複数きました。原因を調べると、必須項目が空欄のままで上部にエラーが出ていたのに、全員がそれを見ていなかったのです。エラーを出す場所と伝え方を変えるだけで、そういった問い合わせはほぼゼロになりました。

標準フォームの弱点をまとめると、エラー位置が固定（上部のみ）、エラー文言が英語や無機質な自動生成メッセージ、どの項目が問題なのかパッと見てわからない、の3点です。これを解決するのが、本記事で解説するカスタムエラー表示の実装です。

IsBlank と IsEmpty の違いと使い分け

必須チェックを実装する前に、よく混同される IsBlank 関数と IsEmpty 関数の違いを整理しておきます。この2つは名前が似ていますが、チェックする対象が根本的に異なります。

IsBlank はテキスト入力・日付・数値など単一のフィールドや値が空かどうかを判定します。テキスト入力コントロールの空欄チェックにはこちらを使います。一方 IsEmpty はテーブル（コレクションや Recordset）が0件かどうかを判定するものです。テキスト入力に IsEmpty を使うと、空欄でも必ず false を返してしまい、バリデーションが機能しないので注意が必要です。

関数	対象	空のとき	使うケース
IsBlank	値・フィールド	true	テキスト入力・日付・数値の未入力チェック
IsEmpty	テーブル・コレクション	true	ギャラリーの件数ゼロ・コレクション未初期化チェック

必須チェックの基本構文は次のとおりです。IsBlank 関数にテキスト入力コントロールの Text プロパティを渡します。

IsBlank(TextInput_Name.Text)

これが true を返したとき、エラーラベルを表示するという設計になります。

エラーメッセージを入力項目のすぐ下に配置する

実装の考え方はシンプルです。各入力項目の直下にエラー用ラベルコントロールを配置し、Visible プロパティを条件式で制御します。エラーがない状態ではラベルは非表示になっていますが、未入力で送信しようとした瞬間に赤字のメッセージが現れます。

ただし、ここで一点注意があります。画面を開いた直後から入力前にいきなりエラーを出すのは、ユーザーにとってストレスになります。名前欄に何も入れていないのに最初から「未入力です」と赤字が出ていたら、使いにくいですよね。そこで varFormSubmitted という変数を使い、送信ボタンを押した後にだけエラーを表示する設計にします。

varFormSubmitted パターンの実装手順

送信ボタンの OnSelect に Set(varFormSubmitted, true) を追加します
エラーラベルの Visible プロパティに And(varFormSubmitted, IsBlank(TextInput_Name.Text)) を設定します
キャンセルボタンの OnSelect と画面の OnVisible に Set(varFormSubmitted, false) を追加してリセットします

この設計の利点は、ユーザーが送信を試みるまではまったくエラーが見えないため、入力作業中の余計なストレスがゼロになることです。送信ボタンを押した瞬間に問題のある項目だけが赤くなるので、どこが問題かが一目でわかります。

送信ボタンの表示と無効化のルール

エラー表示と合わせて、送信ボタンの状態制御も設計しておく必要があります。ここで陥りやすいミスが2つあります。

1つ目は DisplayMode.View を使うことです。Power Apps の DisplayMode.View は見た目はボタンに見えますが、実際にはタップできません。ユーザーがボタンを押しても反応がなく、故障していると思われます。ボタンのモードは DisplayMode.Edit（通常）か DisplayMode.Disabled（非活性）のみを使うようにしましょう。

2つ目はボタンを Visible:false で隠すことです。入力前から送信ボタンが消えていると、どこで保存するの？とユーザーが迷います。ボタンは常に表示した状態を保ち、条件を満たさないときは DisplayMode.Disabled で押せない状態にするのが正解です。

// 送信ボタンの DisplayMode プロパティ
If(
  Or(IsBlank(TextInput_Name.Text), IsBlank(TextInput_Email.Text)),
  DisplayMode.Disabled,
  DisplayMode.Edit
)

グローバル変数とコンテキスト変数の使い分けを理解していると、varFormSubmitted のようなフラグ変数の管理がスムーズになります。

モダンフォームのバリデーション設計

Power Apps にはクラシックフォームとモダンフォームの2種類があります。モダンフォームの場合は ValidationState プロパティと ValidationMessage プロパティを使うことで、よりシンプルにエラー表示を実装できます。

モダンフォームのテキスト入力では、ValidationState プロパティに Error または None を設定します。Error にすると自動的に赤枠が付き、ValidationMessage に指定した文字列がエラーメッセージとして表示されます。カスタムのラベルコントロールを別途配置しなくても済むのが利点です。

// モダンフォームの ValidationState プロパティ
If(And(varFormSubmitted, IsBlank(Self.Value)), "Error", "None")

// ValidationMessage プロパティ
"名前は必須です"

また、複数フィールドのバリデーション状態を一括管理したい場合は、名前付き計算式（App.Formulas）を使ったアプローチが有効です。たとえば formValid という named formula を App.Formulas に定義しておくと、送信ボタンの DisplayMode や各エラーラベルの Visible を1箇所で管理できます。

// App.Formulas に定義する named formula の例
formValid = Not(Or(lbl_NameError.Visible, lbl_EmailError.Visible));

この formValid を送信ボタンの DisplayMode 判定に使えば、フィールドを追加するたびに各所の条件式を書き直す手間がなくなります。再利用性が高く、メンテナンスしやすい設計です。

タイマーで変数セット→バリデーション→送信の順序を保証する

Power Apps の OnSelect はすべての処理が同時に評価されるため、変数を true にしてからバリデーションを動かし、問題なければ保存、という順番を素直に書いてもうまくいかないことがあります。

Set(varFormSubmitted, true) を書いた直後に SubmitForm を書いても、変数の更新がバリデーションの再評価より先に終わらない場合があるのです。これはモダンフォームで特に顕著です。

解決策はタイマーコントロールを使うことです。送信ボタンの OnSelect でタイマーを起動し、OnTimerEnd の中で formValid が true のときだけ SubmitForm を実行します。Duration を 100〜200 ミリ秒に設定するだけで、評価順序の問題を回避できます。

// 送信ボタンの OnSelect
Set(varFormSubmitted, true);
Set(varStartTimer, false);
Set(varStartTimer, true)  // タイマーを起動

// Timer コントロールの OnTimerEnd
If(formValid, SubmitForm(Form1))

この設計は少し手間に見えますが、一度作ればほぼどんなフォームでも使い回せます。私はこのパターンをテンプレート化して、新しいフォームを作るたびにコピーして使っています。

まとめ：エラーの見せ方が、アプリの信頼感を決める

Power Apps で入力ミスを防ぐには、エラーを出すこと自体よりもどこでどう伝えるかの設計が重要です。入力項目のすぐ下にエラーメッセージを出し、ボタンは常に見えていて条件次第で押せない状態にする、この2点を守るだけで、現場からの問い合わせは大きく減ります。

バリデーション設計はコンテナを使ったレイアウト設計とも組み合わさると威力を発揮します。エラーラベルの配置をコンテナで管理すれば、レイアウト崩れを気にせずフォームを改修できます。地道な設計の積み重ねが、使ってもらえるアプリに近づく一歩です。

入力エラーに関する一覧はこちらの記事をご覧ください。

10項目の入力がパーに…を防ぐ！Power Appsで保存せず戻る時に警告を出す方法

Sat, 11 Apr 2026 11:26:48 GMT

フォームに10項目入力した直後、間違えて戻るボタンを押してしまい、全部消えた。そんな経験がある現場スタッフは少なくありません。Power Apps では、未保存の変更がある状態で画面を離れようとしたとき、確認ダイアログを出して離脱を防ぐ設計が作れます。

この記事で解説する未保存警告は、Power Appsの入力ミス防止設計の全体像の中でもうっかりミスを防ぐフロー制御の一つです。Unsaved プロパティと OnChange フラグを使った警告ダイアログの実装方法を解説します。

入力途中で画面を離れるとデータが消える問題

Power Apps の画面遷移は Navigate 関数で実装します。戻るボタンの OnSelect に Back() や Navigate(Screen_List) を書くだけで、即座に画面が切り替わります。このシンプルさが便利な一方、確認なしに離脱できてしまうという問題も生みます。

私が現場展開したアプリで、最初は何も警告を入れていませんでした。社内の勉強会で実演中にスタッフが入力フォームのテスト中に誤って戻るボタンを押し、全入力が消えるという場面がありました。その場はデモだったので笑い話で済みましたが、実務で起きたらシャレになりません。

スマホ操作では特にこの問題が顕在化します。画面端のスワイプ操作がアプリの戻るボタンと競合したり、誤タップが起きやすかったりします。入力量が多い申請フォームほど、未保存警告の設計は重要です。

Unsaved プロパティを使う方法

EditForm コントロールを使っているなら、Unsaved プロパティが利用できます。フォームに紐づいたいずれかのデータカードで値が変更された場合、Unsaved は自動的に true になります。保存（SubmitForm）か Reset（ResetForm）が実行されると false に戻ります。

この仕組みを戻るボタンの制御に使います。戻るボタンの OnSelect に直接 Back() を書く代わりに、Unsaved の値によって処理を分岐させます。

// 戻るボタンの OnSelect
If(
  Form1.Unsaved,
  Set(varShowUnsavedDialog, true),
  Navigate(Screen_List, ScreenTransition.Fade)
)

Unsaved が true のとき、確認ダイアログを表示する変数を立てます。false なら未変更なのでそのまま画面遷移します。変数の基本的な使い方を理解していれば、このフラグ制御はすぐに実装できます。

確認ダイアログをコンテナで作る

警告ダイアログは、コンテナコントロールを使ったオーバーレイUIで実装します。ダイアログ用のコンテナを画面の最前面に配置し、varShowUnsavedDialog が true のときだけ表示する設計です。

ダイアログの構成

垂直コンテナを1つ作成し、Visible プロパティに varShowUnsavedDialog を設定します
コンテナの背景色を半透明の黒（RGBA(0,0,0,0.5)）にして、画面全体を覆う大きさにします
その中に白背景の内側コンテナを配置し、メッセージとボタン2つ（破棄して戻る・キャンセル）を配置します

破棄して戻るボタンの OnSelect には、ダイアログを閉じてから画面遷移する処理を書きます。キャンセルボタンはダイアログを閉じるだけです。

// 破棄して戻るボタンの OnSelect
Set(varShowUnsavedDialog, false);
ResetForm(Form1);
Navigate(Screen_List, ScreenTransition.Fade)

// キャンセルボタンの OnSelect
Set(varShowUnsavedDialog, false)

コンテナを使ったオーバーレイダイアログの配置については、コンテナを使ったレイアウト設計の全体ガイドが参考になります。Z軸方向の重なり順（コンテナの配置順）を正しく設定しないと、ダイアログが他のコントロールの下に隠れてしまうことがあります。

OnChange フラグを使う方法（EditForm 非使用の場合）

EditForm を使わず、個別のテキスト入力やドロップダウンを直接配置している画面では、Unsaved プロパティが使えません。この場合は各コントロールの OnChange プロパティでフラグを立てる方法を使います。

// 各テキスト入力コントロールの OnChange プロパティ
Set(varHasChanges, true)

// 画面の OnVisible プロパティ（画面を開くたびにリセット）
Set(varHasChanges, false)

戻るボタンの処理は Unsaved パターンと同様です。varHasChanges が true なら確認ダイアログを出し、false ならそのまま遷移します。保存処理（Patch 関数など）が成功したタイミングでも varHasChanges を false に戻すことを忘れないようにしましょう。Patch 関数の使い方と組み合わせると、保存後の状態リセットがスムーズに実装できます。

画面遷移の基本と組み合わせる

Power Apps の画面遷移は Navigate 関数が基本です。Navigate 関数の使い方で解説しているように、画面遷移に引数としてコンテキスト変数を渡すこともできます。未保存警告の実装では、遷移先画面に情報を渡す必要はほとんどありませんが、複雑な遷移フローを組む場合は知っておくと便利な機能です。

注意点：スワイプ操作やハードウェアバックには対応できない

このアプローチには1つ大きな制限があります。Power Apps 内の戻るボタンを制御するのは有効ですが、Android 端末のハードウェアバックボタンやスワイプ操作による戻るアクションには対応できません。Power Apps はこれらのシステム操作を上書きする機能を持っていないためです。

割り切りが必要な部分です。スマホ利用が多い現場では、この制限をユーザーに周知するか、画面の上部に保存状態を常時表示するUI（保存済み / 未保存の表示ラベル）を追加して意識させる設計も有効です。完璧な防止は難しくても、ほとんどのユーザーのうっかりミスを防ぐことに意味があります。

まとめ：入力の労力を守るのも、アプリ設計の仕事

未保存警告は、ユーザーが積み上げた入力作業を守るための設計です。EditForm を使うなら Unsaved プロパティ、個別コントロールなら OnChange フラグと、状況に応じて使い分けられます。確認ダイアログはコンテナで作るのが最もシンプルで、他の画面にも流用しやすいコンポーネントになります。

現場のスタッフが安心してアプリを使い続けられる環境を作ることが、市民開発の本質だと思っています。地道な UX 改善の積み重ねが、長く使われるアプリを作ります。

どこがエラーか一目でわかる！Power Appsで未入力項目の枠線を赤く光らせるUX改善

Sat, 11 Apr 2026 11:26:46 GMT

送信してからエラーに気づく。これがユーザーにとって最もストレスの高いUXのひとつです。どの項目が問題なのかを送信前に一目でわかるように、Power Appsでは枠線の色や背景色を動的に変えることができます。入力ミス防止の設計全体についてはPower Apps入力ミス防止ガイドでまとめているので、UX設計の全体像と合わせて確認してください。

この記事では、BorderColorとFillプロパティをIsBlankやIsMatchと組み合わせて、未入力・不正入力を視覚的にフィードバックする方法を解説します。

視覚フィードバックがUXを変える理由

ユーザーが10項目のフォームを入力し終えて送信ボタンを押したとき、画面上部に小さく未入力の項目があります、と出るだけでは、どこを直せばいいか分かりません。探すのに時間がかかり、ストレスが溜まります。最悪の場合、何度試してもどこが問題か気づけず離脱につながります。

対して、問題のある入力欄そのものの枠線が赤くなっていれば、どこを直せばいいかが一目瞭然です。これがリアルタイムの視覚フィードバックの価値です。社内アプリでも、使われないアプリと使われるアプリの差はこういったUXの細部に出ることが多いと思っています。

BorderColorで枠線を動的に変える

テキスト入力コントロールのBorderColorプロパティは、通常RGBA値や色定数で固定設定されています。これをIf関数で条件付きの式にすることで、入力状態に応じて枠線の色を切り替えられます。

未入力時に赤枠を表示する基本パターン

最もシンプルな実装は、IsBlankで未入力を検知して赤枠にするパターンです。テキスト入力コントロールのBorderColorプロパティに次の式を設定します。

If(
    IsBlank(TextInput_Name.Text),
    Color.Red,
    Color.Black
)

空欄のときは赤、何か入力されていれば黒になります。ただしこのままでは、画面を開いた瞬間からすべての必須フィールドが赤くなっており、ユーザーを萎えさせます。

送信ボタンを押したあとだけエラーを表示する

最初から赤くするのではなく、送信ボタンを押したあとにだけエラーを表示するのが実用的です。varFormSubmittedという変数を用意し、送信ボタンのOnSelectで最初にtrueにします。そのフラグが立っているときだけ、バリデーションが発動する設計です。必須チェックとエラーメッセージの作り方でも同じ変数パターンを解説しているので合わせて確認してください。

If(
    And(varFormSubmitted, IsBlank(TextInput_Name.Text)),
    Color.Red,
    Color.Black
)

送信ボタンのOnSelectプロパティの先頭に UpdateContext({varFormSubmitted: true}) を入れておけば、ボタンを押した瞬間にエラーが可視化されます。フォームが正常に保存されたタイミング（OnSuccess等）でfalseに戻すのを忘れないようにしてください。

Fillプロパティで背景色も変える

枠線だけでなく、入力フィールドの背景色（Fillプロパティ）も変えることで、より目立つエラー表示ができます。ただし、真っ赤な背景にすると視覚的に強烈すぎるので、薄いピンクや薄い赤にするのが現場では使いやすいです。

If(
    And(varFormSubmitted, IsBlank(TextInput_Name.Text)),
    RGBA(255, 220, 220, 1),
    Color.White
)

枠線が赤くなるだけより、背景も薄赤になることでエラー箇所がより直感的に伝わります。特に高齢のユーザーが多い職場や、色覚のバリエーションがある環境では、枠線の色だけに頼らず背景色やアイコンも組み合わせることを意識しています。

IsMatchで形式チェックの枠線制御をする

未入力チェックだけでなく、入力形式（メールアドレス・電話番号・郵便番号など）が正しいかをリアルタイムで枠線に反映させることもできます。

メールアドレスの形式チェックをBorderColorに組み込む例です。

If(
    Or(
        IsBlank(TextInput_Email.Text),
        IsMatch(TextInput_Email.Text, Match.Email)
    ),
    Color.Black,
    Color.Red
)

空欄または正しいメール形式のときは黒枠、何か入力されているのに形式が間違っているときだけ赤枠にしています。空欄を黒枠扱いにするのは、入力前からエラーを出さないためです。

モダンコントロールのValidationStateを使う

モダンコントロールのテキスト入力には、ValidationStateプロパティという専用の設定があります。Errorを設定すると自動的に赤枠が付き、Noneにすると通常の状態に戻ります。

If(
    And(varFormSubmitted, IsBlank(Self.Value)),
    "Error",
    "None"
)

ValidationStateを使うと、エラー時のスタイリングをPower Appsが自動で処理してくれます。カスタムのRGBA値を書かなくて済むため、コードがすっきりします。エラーメッセージのTextプロパティには、Parent.Error（フォームの標準エラー）と組み合わせることで既存のバリデーションと共存できます。

送信ボタンをすべての条件がクリアされるまでDisabledにする

視覚フィードバックと合わせて、すべての必須フィールドが正しく入力されるまで送信ボタンを押せないようにするとより安全です。複数フィールドの条件をOr関数でまとめ、ひとつでも問題があればDisabledにします。

If(
    Or(
        IsBlank(TextInput_Name.Text),
        Not(IsMatch(TextInput_Email.Text, Match.Email)),
        IsBlank(TextInput_Tel.Text)
    ),
    DisplayMode.Disabled,
    DisplayMode.Edit
)

この設計を再利用しやすくするには、App.FormulasにNamed Formulaとして条件をまとめておく方法もあります。コンテナの設計思想と同様、UI設計全体の中で再利用性を意識することが長期的なメンテナンスコストを下げます。

まとめ

BorderColorとFillプロパティをIsBlankやIsMatchの結果と連動させることで、どの項目に問題があるかをユーザーが一目で把握できるフォームになります。送信してから気づくのではなく、入力中に気づける設計が、ユーザーのストレスを下げてデータ品質を上げます。

見た目の工夫に見えますが、実際には入力ミスを防ぐ実用的な仕組みです。市民開発とは、こういった地道な配慮の積み重ねだと思っています。

Power Appsのグローバル変数とコンテキスト変数。違いと使い分けを図解

Tue, 10 Mar 2026 23:13:20 GMT

Power Appsの変数は、グローバル変数とコンテキスト変数の2種類があります。この使い分けさえ最初に理解しておけば、後になって迷子になることがぐっと減ります。

変数とは何か

変数を使うとどう変わるか

変数とは、数値・テキスト・真偽値などの情報を一時的に記憶しておく入れ物です。料理にたとえるなら、調理中に使う小皿のようなものです。作業途中に出た値をそこに置いておき、必要なときに取り出す。Power Appsではこの仕組みを使って、画面間でデータを渡したり、UIの状態を管理したりします。

変数を使わなくてもアプリは作れます。ただ、複数の画面を持つアプリや、条件によって表示内容を切り替えたいアプリでは、変数なしに実現するのはかなり難しくなります。社内で勉強会をやっていると、変数の概念でつまずく方は多いのですが、仕組みを整理すると意外とシンプルです。

Power Appsには変数の種類が2つあります。アプリ全体で使えるグローバル変数と、特定の画面の中だけで使えるコンテキスト変数です。この2つは仕組みが異なるので、それぞれ順番に見ていきます。

グローバル変数とコンテキスト変数の違い

グローバル変数（Set）

グローバル変数は、アプリ全体のどこからでも読み書きできる変数です。Set という関数を使って値を保存します。

Set(gv_UserName, User().Email)

この1行で、ログイン中のユーザーのメールアドレスを gv_UserName という名前で保存できます。一度 Set で保存すると、アプリ内のどの画面からでも gv_UserName と書けば値を呼び出せます。

グローバル変数の名前の先頭に gv_ をつけるのが個人的なルールです。変数の一覧を見返したときに、グローバルかどうかが名前だけで判別できるので、後から見直す際にとても楽です。チームで開発するときは、こういった命名規則をはじめに決めておくことをおすすめします。

コンテキスト変数（UpdateContext）

コンテキスト変数は、その画面（スクリーン）の中だけで有効な変数です。UpdateContext という関数を使います。

UpdateContext({lv_showForm: true})

lv_showForm が true のときにフォームを表示する、といった使い方ができます。UpdateContext はレコード形式（波括弧で囲む）で書くのが特徴で、複数の変数をまとめて更新することも可能です。

UpdateContext({lv_showForm: true, lv_editMode: false})

コンテキスト変数の重要なポイントは、定義した画面の中でしか読み取れないことです。別の画面に移動すると、その変数は参照できません。私は頭に lv_（local variable の略）をつけてグローバル変数と区別しています。

2つの違いを整理する

まとめると次のとおりです。

	グローバル変数	コンテキスト変数
使う関数	Set()	UpdateContext()
有効範囲	アプリ全体	定義した画面のみ
主な使いどころ	画面をまたいで使う値	画面内のUI制御
命名例（慣習）	gv_UserName	lv_ShowForm
初期化タイミング	OnStart が多い	OnVisible が多い

どちらを使うべきか——実務での判断基準

グローバル変数を選ぶとき

画面をまたいで値を渡したいときはグローバル変数一択です。代表的な使いどころは次の3つです。

ログイン情報（User().Email などをアプリ起動時に保存しておく）
選択したアイテムのIDや名称（一覧画面から詳細画面に渡す）
編集モードと参照モードの切り替えフラグ

特に多いのが、ギャラリーで行をタップして詳細画面に遷移するパターンです。タップしたタイミングで選択行の情報をグローバル変数に保存しておけば、詳細画面側でその情報を自由に使えます。

// ギャラリーの OnSelect に書く例
Set(gv_SelectedItem, ThisItem);
Navigate(DetailScreen, ScreenTransition.None)

これで DetailScreen に移動した後も、gv_SelectedItem からタップした行のデータを参照できます。シンプルですが、現場のアプリでは非常によく使うパターンです。

コンテキスト変数を選ぶとき

その画面の中で完結するUI制御にはコンテキスト変数が適しています。代表的なケースは次のとおりです。

フォームの表示・非表示の切り替え（追加ボタンを押したらフォームが開く）
ポップアップや確認ダイアログの開閉
ボタンを押してデータ送信中にローディング表示を出す

これらはアプリ全体に共有する必要がない、画面限定の状態管理です。グローバル変数で代用することもできますが、コンテキスト変数のほうがスコープが狭い分、意図しない値の上書きが起きにくくなります。グローバル変数を必要のない場面で乱用すると、後から見直したときに何のために使っているのかわかりにくくなるので注意が必要です。

初心者がよくやる失敗パターン

コンテキスト変数を別の画面から読もうとする

コンテキスト変数でつまずく原因のほぼすべては、定義した画面の外で参照しようとすることです。画面Aで設定したコンテキスト変数は、画面Bからは見えません。勉強会でも毎回と言っていいほど出てくる質問がこれです。

画面間で値を渡したい場合は、グローバル変数を使うか、Navigate 関数の第3引数を使う方法があります。

// Navigate の第3引数でコンテキストを渡す方法
Navigate(DetailScreen, ScreenTransition.None, {lv_itemId: ThisItem.ID})

Navigate の第3引数にレコードを渡すと、遷移先の画面のコンテキスト変数として値を引き渡せます。ただし私はこの方法よりもグローバル変数で渡す方が直感的でわかりやすいと感じており、通常はグローバル変数を使っています。どちらでも動くので、自分がわかりやすいほうを選べば問題ありません。

変数を初期化しないままアプリを作る

OnStart や OnVisible で変数を初期化しておかないと、アプリの状態によって予期しない値が残ることがあります。特に、編集フォームを開いた状態で別の操作をして戻ってきたときに、前回の値がそのまま残っていてバグになるケースがよくあります。

対策はシンプルで、画面に入るたびに使う変数はOnVisibleでリセットするか、初期値を明示的に設定しておくことです。

// DetailScreen の OnVisible に書く例
UpdateContext({lv_showForm: false, lv_editMode: false})

体感では、この初期化の漏れが初心者のバグの原因としてかなりの割合を占めています。動かないと思って悩んでいたら、変数に古い値が残っていたというケースは珍しくありません。アプリが複雑になってくると特に起きやすいので、早い段階から習慣づけておくことをおすすめします。

コレクションとの違いも知っておこう

変数とは別に、コレクションという仕組みもあります。変数が単一の値（1つの数値や文字列）を保持するのに対して、コレクションは複数行のテーブルデータを保持できます。簡単にいえば、Excelのような表形式のデータを一時的に保存するための入れ物です。

一時的なリストを画面に表示したい場合や、データを加工してから保存したい場合にコレクションを使います。変数とコレクションを両方理解しておくと、Power Appsで作れるアプリの幅が大きく広がります。コレクションについては別の記事で詳しく解説する予定です。

また、変数を使いこなせるようになったら、Power Appsで使える実用テクニックの記事もあわせて読んでみてください。実際の現場で役立つ記法がまとまっています。

まとめ

グローバル変数は Set、コンテキスト変数は UpdateContext——まずこの2つの関数と有効範囲の違いを覚えてしまえば大丈夫です。画面をまたぐならグローバル、その画面の中で完結するならコンテキスト。この判断基準が頭に入れば、変数で迷う場面はかなり減ります。

最初から完璧に使い分けようとしなくても大丈夫です。実際にアプリを作りながら、動かして確認していくうちに自然と身につきます。変数の使い方が手に馴染んでくると、アプリで表現できることが一気に増えます。ぜひ小さなアプリから試してみてください。

Power AppsのWith関数で数式をすっきり書く。ネストを解消するテクニック

Mon, 16 Mar 2026 15:46:47 GMT

Power AppsのWith関数は、複雑な数式を見やすく整理するためのツールです。ネストが深くなった数式や、同じ計算を何度も繰り返している数式があれば、With関数で書き直すと一気にスッキリします。

変数（Set/UpdateContext）と似ていますが、With関数はその数式の中だけで使えるスコープを作ります。副作用がなく、読み込み専用の一時的な値として使えるのが特徴です。

With関数の基本構文

With関数の構文は次のとおりです。

With(
    {
        変数名1: 値1,
        変数名2: 値2
    },
    // 変数名1や変数名2を使った式
)

最初の引数にレコード形式で名前と値のペアを定義し、2番目の引数でそれを使った式を書きます。定義した変数名はその式の中だけで有効です。

シンプルな例：計算の再利用

例えば、税込み価格と割引後の価格を両方表示したいとします。With関数を使わない場合はこうなります。

Text(SliderPrice.Value * 1.1, "#,##0") & "円（割引後：" & Text(SliderPrice.Value * 1.1 * 0.9, "#,##0") & "円）"

SliderPrice.Value * 1.1 が2回出てきて冗長です。With関数を使うとこうなります。

With(
    {taxPrice: SliderPrice.Value * 1.1},
    Text(taxPrice, "#,##0") & "円（割引後：" & Text(taxPrice * 0.9, "#,##0") & "円）"
)

taxPriceという名前をつけることで、意図が明確になり繰り返しも消えます。

ネストを解消する使い方

With関数の真価が発揮されるのは、If関数やSwitch関数とネストした複雑な数式を整理するときです。

ネストが深い数式の問題

例えば、ギャラリーの各アイテムについて「ステータスに応じた色」と「期限切れかどうかの判定」を同時に使う数式はこうなりがちです。

If(
    DateDiff(Today(), DateValue(ThisItem.期限), Days) < 0 && ThisItem.ステータス <> "完了",
    Color.Red,
    If(
        DateDiff(Today(), DateValue(ThisItem.期限), Days) < 3 && ThisItem.ステータス <> "完了",
        Color.Orange,
        Color.Black
    )
)

DateDiff(Today(), DateValue(ThisItem.期限), Days) が2回登場しています。With関数で整理するとこうなります。

With(
    {
        daysLeft: DateDiff(Today(), DateValue(ThisItem.期限), Days),
        isDone: ThisItem.ステータス = "完了"
    },
    If(
        daysLeft < 0 && !isDone, Color.Red,
        daysLeft < 3 && !isDone, Color.Orange,
        Color.Black
    )
)

daysLeftとisDoneという名前がついたことで、「残り日数が0未満かつ未完了なら赤」という意図が一目でわかるようになりました。

WithとSetの使い分け

Withと変数（Set/UpdateContext）は似ていますが、役割が異なります。

比較	With	Set / UpdateContext
スコープ	その数式の中だけ	グローバル / 画面内
副作用	なし（読み取り専用）	あり（値を書き換える）
主な用途	数式の整理・可読性向上	状態管理・画面間の値の受け渡し
パフォーマンス	良い（評価時のみ）	変数更新で再評価が走る

まとめると、計算の途中結果を名前づけして再利用したいだけなら With、別のボタンや別の画面からも参照・変更したいならSet/UpdateContextを使います。

変数の使い方については別記事で詳しく解説しています。

→ Power Appsのグローバル変数とコンテキスト変数——違いと使い分けを図解

Withを使うと良い場面のまとめ

With関数を使うと数式が読みやすくなるのは、次のような場面です。

同じ計算（DateDiff、FilterなどのLookUp）が2回以上出てくる
If/Switchの条件が長くなりすぎて何を判定しているかわかりにくい
ネストが3段以上になっている
数式を後から自分以外が読む可能性がある

With関数自体がパフォーマンスを上げるわけではありませんが、数式が読みやすくなることで後からのメンテナンスが楽になります。私は「3ヶ月後の自分が読んでわかるか」を基準に、Withを入れるかどうか判断しています。

条件分岐の書き方はこちらも参考にしてください。

→ Power AppsのIfとSwitch——条件分岐の書き方と場面別の使い分け

まとめ

With関数は数式の中に一時的な名前つきの値を定義して、その数式内で使い回せるツールです。変数と違って副作用がなく、数式の可読性を上げるためだけに使います。同じ計算が繰り返し出てきたり、ネストが深くなってきたりしたらWith関数への切り替えを検討してみてください。

数式がスッキリすると、バグも減りますし、チームで開発するときも理解しやすくなります。地道ですが、こういう積み重ねが良いアプリ開発につながると思っています。

Power Appsで使える実用テクニック

Mon, 14 Oct 2024 21:01:03 GMT

Power Apps開発を効率的に進めるテクニックを紹介します。

Power Appsショートカット

ショートカットキーを使って効率的に開発しましょう。

ショートカット	内容	備考
Ctrl + S	保存	オートセーブもあり
Ctrl + A	全選択
Ctrl + X	切り取り
Ctrl + C	コピー	他アプリからコントロールをコピーすることも可能
Ctrl + V	貼り付け
Ctrl + Z	取り消し	6−7ステップ戻しが限界？
Ctrl + Y	やり直し
Ctrl + クリック、または Shift + クリック	複数オブジェクトの選択
F2	コントロール名の変更
F5	プレビュー	PC, スマホ両方のデザイン確認が可能
Alt押しながら	動作確認
Ctrl + [ Ctrl + ]	コントロールの背面・全面移動
Shift + Ctrl + L	複数同時編集

一般的なPC操作とほぼ同じショートカットが有効です。

紹介した中からいくつかピックアップします。

Ctrl + C（コピー）

非常によく使うショートカットの1つ。

別のアプリからコントロールをコピーすることも可能です。

例えばアプリ1でLabel1をコピーし、アプリ2で貼り付けすると同じLabel1がアプリ2に複製されます。

これを使えば、1つ1つ手動で追加せずとも複数のアプリで機能の使い回しができます。

Ctrl + Z（取り消し）

うっかりコントロールを消してしまったとき、関数を入力ミスしたときなど、Ctrl + Zを使います。

便利な半面、戻せるステップ数に上限があり、体感的に6−7ステップかと。

これもなぜか日によって（タイミングによって？）変わるので、過信しすぎは禁物です。

F5（プレビュー）

アプリのプレビューボタンを押さずとも、F5を押せば同じ効果があります。

Altを押しながら（動作確認）

「このボタンを押した動きを確認したい」
「ソート機能の動きを確認したい」

こういう時、プレビューボタン（またはF5）を押してから挙動を確認すると思いますが、実はいちいちプレビューにする必要はありません。

Altを押しながらボタンを押したり、並び替えをしてみてください。

簡易的に動きを確認できます。

Mac環境の場合はoptionを押しながら、になります。

Ctrl + [、Ctrl + ]（前面・背面移動）

コントロールの並び順を変える時におすすめのショートカット。かなり使います。

Shift + Ctrl + L（複数同時編集）

Power Fx内で使える便利ショートカット。

例えばこんな式があります。

varDisplayを修正したいが、数が多い・・・

このうち、varDisplayを別の変数に置き換えたいとした時、1つずつ手動で修正するのは手間がかかります。

そんな時、修正したい値を選択した状態（クリックしてカーソルがそこで点滅している状態）で、Shift + Ctrl + L を押します。

式の中のvarDisplayが全選択される

式の中のすべてのvarDisplayが選択状態になりました。

この状態でBackspaceを押したり文字を入力すると、

すべてのvarDisplayを一度に編集することができます。

Ctrl + F からの一括置換もほぼ似たような機能ですが、個人的に Shift + Ctrl + L のほうが使いやすく、リアルタイム同時置換みたいな感じでしょうか。

Macの場合はなぜか Shift + Ctrl + L に相当する機能がなく、代わりに Shift + Ctrl + D を複数回押して代用できます。

オートセーブ機能

Power Appsには2分間隔で自動的に変更内容を保存するオートセーブ機能があります。

デフォルトではONになっています。

ONだと、ネットワークエラーやうっかり画面を閉じてしまった時の救済措置になります。

OFFにすると救済措置が使えなくなる反面、変更内容が勝手に保存されなくなります。

OFFのメリットとしては、複雑なPower Fxを編集していて、原型から大きく変更をかけてしまい、やっぱり初期状態に戻したいときに重宝します。

グループは使わない。コンテナを使う

複数のコントロールをまとめる機能でグループ化機能がありますが、使わないことをおすすめします。

Power Pointなどでもおなじみの機能なので意外に思われる方がいらっしゃることでしょう。

複数の要素を1つにまとめたいなら、代わりにコンテナ機能を使います。

なぜなら、Power Appsのグループ化機能は開発において不便極まりないもので、コンテナ機能が完全な上位互換だからです。

グループ	コンテナ
コントロールを直接追加できない。一旦グループ化を解除しなくてはいけない	コントロールを直接追加できる
再グループ化すると名前がリセットされる	名前はリセットされない
背景色を付けるなら図形（四角形）コントロールが必要	コンテナそのものにFillプロパティがある
中身が絶対座標	中身が相対座標
グループへの処理がすべてのコントロールに影響する	コンテナへの処理はコンテナのみに影響する
グループ in グループは不可	コンテナ in コンテナが可能

コントロールの追加が不便すぎる

例えばこんな状態のグループがあります。

このグループの中に新たにButtonコントロールを追加したい場合、Group1の子要素を選択した状態で[挿入]→[ボタン]と進めると、Group1の外側に追加されてしまいます。

グループ内に直接追加することができない

こうなったら、Group1を一度グループ解除し、Button2を含めたすべてのグループ化したいコントロールを再び全て選択してグループ化しなければなりません。

また、この際にGroup1の名称を仮にgrpMembersのように任意の名称にしていたとすると、再グループ化したらGroup1に戻ってしまうので、それも修正の手間がかかります。

コンテナはこんな手間はいっさい不要です。

背景色は図形が必要

グループ全体に色付けしたい場合、グループ内に図形（基本的に四角形）を追加し、最背面に配置し、図形のFillプロパティで色付けします。

一方のコンテナは、コンテナそのものにFillプロパティがあるため、図形挿入は不要です。

絶対座標と相対座標

グループは絶対座標、コンテナは相対座標です。

図で表すとこんなイメージです。

グループ化した要素は、アプリ画面全体に対する絶対座標を持ちます。

つまり、グループ全体が移動しても、内部の要素のサイズや位置は変わりません。

コンテナ内の要素は相対的な座標位置を持ち、コントロール内に対する位置の指定となります。

これは、画面のサイズ変更や他のコントロールとの関係に基づいて、内部の要素が自動的に位置やサイズを調整するというもので、例えばレスポンシブデザイン（PCレイアウトとスマホレイアウトを自動的に切り替える機能）の実現に欠かせない機能の1つです。

グループ in グループができない

グループの中にグループを作ることはできません。

コンテナ in コンテナは可能です。

複数のコントロールを一括して編集できる

コントロールを Ctrl+クリック、またはShift+クリックで複数選択した状態で、一括してプロパティを編集することができます。

リセットは変数で処理するのがおすすめ

TextInputなどに入力した値を消去するため、ButtonなどのOnSelectにReset関数を使い、 Reset(TextInput1)とすることがあります。

でもコントロールが増えると管理が大変になりますね。

Resetしたいコントロールを全て書くのが大変

そんな時は変数のTrue/Falseを使って簡単にResetすることができます。

まず、TextInputのResetプロパティに変数を設定します。

この時点でエラーが出ても問題ありません

次に、ButtonのOnSelectでこの変数をTrue、Falseと宣言します。

これでボタンを押せば、locResetをResetプロパティに設定したTextInputの値がResetされます。

あとは同様に、ResetしたいコントロールのResetプロパティにlocResetを設定すればOKです。

データ行の制限数は1で開発するとよい

[設定]-[全般]-[データ行の制限]から、委任がサポートされていない場合の取得行数を変更できるのはよく知られたことです。

上限は2,000行

アプリを作る場合、この値を1にして開発することをおすすめします。

実は関数の中には、委任警告は表示されないが実は裏で委任できていない時が存在します。

具体的には、SoryByColumnsで第三引数にテーブルが含まれる場合がそれに該当するのですが、これ以外にも似たケースは存在すると思われます。

これらはMicrosoftの公式ドキュメントにも掲載されていないのでやっかいなのです。

万が一にも委任できない状況を見落とさないためにも、開発中はデータ上限を1にすることで、想定外の委任問題をあなた（開発者）が認知することができます。

もちろん、アプリを公開する際は2,000行に戻しておくのを忘れずに。

随時更新します

他にも便利技があれば更新していきます。

Power Automateのそれぞれに適用（Apply to each）完全攻略

Mon, 16 Mar 2026 11:42:00 GMT

Power Automateで複数件のデータを処理しようとすると、自動的にPower Automateのそれぞれに適用（Apply to each）が挿入されます。便利な反面、フローが遅い・エラーが出る原因の多くがここにあります。

Apply to eachとは何か

繰り返し処理の入れ物

それぞれに適用（Apply to each）は、配列（複数のデータの集まり）の中の要素を1件ずつ取り出して処理を繰り返すアクションです。Excelでいえば、セルの範囲を1行ずつ処理するループ処理と同じ考え方です。

たとえばSharePointリストのアイテムを複数件取得して、それぞれにメールを送りたい場合。リスト取得のアクションはアイテムの配列を返します。その後にメール送信アクションを追加すると、Power Automateが自動でそれぞれに適用（Apply to each）を挿入して、全件分のメール送信をループしてくれます。

なぜ自動で挿入されるのか

Power Automateは、配列型のデータに対してアクションを設定しようとすると、自動的にそれぞれに適用（Apply to each）を挿入します。これは仕様で、意図したかどうかに関係なく起きます。

よくある疑問は、1件しかないはずなのにApply to eachが入ったというものです。これはSharePointやOutlookの取得系アクションが、1件しかなくても配列型でデータを返すためです。1件確実に取れるとわかっていても、取得アクションの返り値が配列型である限り、Power Automateはそれぞれに適用（Apply to each）を提案してきます。

Apply to eachが遅くなる原因

デフォルトは1件ずつ順番に処理する

それぞれに適用（Apply to each）のデフォルト設定は、1件ずつ順番に処理するシリアル実行です。10件のアイテムがあれば、1件目の処理が終わってから2件目、2件目が終わってから3件目、と順番に処理します。1件あたり1秒かかる処理なら10件で10秒、100件なら100秒かかります。

フローが実際に動き出すと想定より遅い、という相談を受けたとき、大半はそれぞれに適用（Apply to each）の中で時間のかかる処理（メール送信、HTTP要求、承認アクションなど）を大量に繰り返しているケースです。

ループ内に余計なアクションが入っている

もう一つの原因は、それぞれに適用（Apply to each）の中に本来ループ外に置けるアクションが含まれているパターンです。毎回同じデータを取得するアクション（変わらないマスタデータの参照など）がループ内にあると、10件処理するなら同じデータを10回取得します。これは無駄な処理です。

それぞれに適用（Apply to each）の中に入れるのは、ループ内の各要素に依存する処理だけにするのが原則です。ループに依存しない処理はそれぞれに適用（Apply to each）の前に出して、結果を変数に保存しておきます。

Apply to eachを速くする方法

同時実行数を設定する

それぞれに適用（Apply to each）の処理を並列で実行する設定があります。それぞれに適用（Apply to each）アクションのメニューから設定を開くと、同時実行の制御というトグルがあります。これをオンにして並列度を設定すると、複数件を同時に処理するようになります。

並列度を1にするとシリアル（順番）実行、2以上にすると指定した数だけ同時に処理します。最大50まで設定できます。ただし、並列実行にすると順番が保証されなくなります。処理の順番が重要な場合（連番の採番など）は並列実行にしないようにしましょう。

実際に使ってみると、メール送信を10件シリアルで処理すると40〜50秒かかっていたものが、並列度5にすると10秒以内に終わることがあります。劇的に速くなるので、順番を問わない処理には積極的に使いましょう。

Apply to eachを使わない書き方に変える

件数が多くて速度が問題になる場合、そもそもそれぞれに適用（Apply to each）を使わない設計を検討します。SharePointのアイテムを更新するだけなら、HTTP要求でSharePointのREST APIをバッチ処理すると複数件を1回のリクエストで更新できます。ただしこれは中〜上級の話なので、最初はApply to each + 並列実行で対応するので十分です。

Apply to eachでエラーが出るときの対処法

1件のエラーで全件が止まる

デフォルトの設定では、それぞれに適用（Apply to each）の中の処理が1件でもエラーになると、そこでフロー全体が失敗します。10件のうち3件目でエラーが出ると、4件目以降は処理されません。

これを防ぐには、それぞれに適用（Apply to each）内のアクションに実行条件の構成でエラー時でも次に進む設定を入れるか、アクションをScope（スコープ）で囲んでエラーハンドリングを追加します。エラーが出た件だけスキップして残りを処理したい場合は、後者のScope + 実行条件の組み合わせが使いやすいです。

ネストしたApply to eachは避ける

それぞれに適用（Apply to each）の中にさらにそれぞれに適用（Apply to each）を入れるネスト構造は、できる限り避けましょう。外側が10件、内側が10件なら、処理の総数は100件になります。さらに内側が増えると指数的に増えて、タイムアウトや想定外の処理件数につながります。

ネストが必要になる設計のときは、外側のループ処理を先に完了させてデータを整形し、内側のループに渡す前にデータ構造をフラットにできないか検討しましょう。選択（Select）やアレイのフィルター処理（Filter Array）といったデータ操作アクションがこの整形に役立ちます。

件数が多すぎるときはデータを絞り込んでから渡す

それぞれに適用（Apply to each）に渡すデータは、できるだけ少なくしておくのが基本です。SharePointリストを取得するときに件数の上限（デフォルト100件、最大5000件）があることも意識しましょう。複数の項目の取得（Get items ）アクションのフィルタークエリで事前に絞り込んでおくと、ループ処理の件数を減らせます。

複数の項目の取得（Get items）の上限を5000件に設定して全件取得してからそれぞれに適用（Apply to each）に渡す方法もありますが、処理時間が長くなります。フィルタークエリを使って必要なアイテムだけを取得してから処理するのが、速度・コストともに優れた設計です。

Apply to eachを正しく使うためのチェックリスト

それぞれに適用（Apply to each）を使うときに確認しておきたいポイントをまとめます。

ループ内に「全件で同じ処理」がないか確認する（ある場合はループの外に出す）
件数が多い場合は同時実行数の設定を検討する
処理の順番が重要かどうかを確認し、問題なければ並列実行にする
ネストしたApply to eachになっていないか確認する
渡すデータをフィルタークエリなどで事前に絞り込んでいるか確認する
エラー時に全件が止まっていいか確認し、必要ならエラーハンドリングを追加する

Power Automateのトリガーの選び方についてはトリガーはどれを選ぶ？の記事も合わせてご覧ください。フロー全体の設計を理解するとApply to eachの使いどころも見えてきます。

まとめ

それぞれに適用（Apply to each）はPower Automateの繰り返し処理の核です。デフォルトのシリアル実行のまま大量データを処理すると遅くなるので、並列実行の設定とループ内のアクションの最小化を意識するだけで体感が大きく変わります。

最初はフローが自動でApply to eachを挿入する仕組みに戸惑うかもしれませんが、慣れてくるとなぜここにApply to eachが入るのかが自然にわかるようになります。地道な積み重ねで、フロー設計の精度は確実に上がっていきます。

承認コネクタの裏側と Dataverse テーブルの仕組み｜プレミアムライセンスでできること

Wed, 08 Apr 2026 19:21:14 GMT

Power Automate の承認フローを使っていると、いつか必ず承認者のコメントを後から取得したい誰がいつ承認したか記録に残したいという要件に直面します。標準の承認アクションだけではここに限界があり、Dataverse の中身を理解する必要が出てきます。

この記事では、承認データが裏側でどのように Dataverse に保存されているかを整理し、コメント取得・履歴追跡・ライセンスの考え方まで解説します。中級〜上級者向けの内容ですが、仕組みを知るだけでフロー設計の選択肢が広がります。

承認データはどこに保存されているのか

Power Automate の承認コネクタを使ってフローを実行すると、承認に関するデータは自動的に Dataverse の標準テーブルに書き込まれます。フローの実行履歴には結果（承認 or 拒否）しか表示されませんが、その裏では承認依頼・承認者の応答・コメントといった情報が構造化されて保存されています。

この仕組みを知らないと、コメントを取得したくても動的コンテンツに出てこない、という壁にぶつかります。私もはじめて承認者のコメントを SharePoint リストに記録しようとしたとき、承認アクションの出力だけでは不十分なことに気づいて Dataverse の構造を調べることになりました。

承認フロー全体の設計についてはPower Automate 承認フロー完全ガイドで解説しています。この記事では Dataverse の裏側に絞って掘り下げます。

4つの主要テーブルと役割

承認コネクタが使う Dataverse テーブルは主に4つあります。それぞれの役割を理解することが、必要なデータを取得するための第一歩です。

テーブル名	論理名	役割
承認	msdyn_approval	承認フロー全体の親レコード。最終結果（承認/拒否）が入る
承認依頼	msdyn_approvalrequest	承認者への通知・依頼情報。誰に依頼したかが記録される
承認応答	msdyn_approvalresponse	各承認者の回答・コメント。ここにコメントが入る
承認ステップ	msdyn_approvalstep	多段承認の各ステップの状態・順序が記録される

承認テーブル（親）

承認フロー全体を管理する親レコードです。フローが完了したとき、最終的な結果（承認されたか拒否されたか）がここに入ります。承認アクションの動的コンテンツで取れる結果はこのテーブルから来ています。ただし承認者のコメントはここには入りません。

承認応答テーブル（コメントの在処）

承認者が承認・拒否をクリックしたときの応答レコードです。ここに各承認者のコメントが保存されます。多段承認の場合、承認者の数だけレコードが作られます。標準の承認アクションの動的コンテンツだけではこのテーブルにアクセスできないため、コメントを取得するには Dataverse コネクタを別途使う必要があります。

コメント取得の落とし穴

承認フローが完了した後、承認者のコメントをフロー内で取得しようとすると、ほとんどの人が一度はつまずきます。承認アクションの出力にコメントが入っていないためです。

標準の動的コンテンツにコメントがない理由

承認アクション（承認の開始と待機）の出力として使える動的コンテンツには、結果・応答概要などは含まれますが、承認者が入力したコメントの本文は含まれていません。コメントは承認応答テーブルに別途保存されるため、そのテーブルを直接クエリしないと取得できない仕組みになっています。

コメントを取得する2つのアプローチ

コメントを取得する方法は2つあります。1つ目は承認アクションの出力にある応答詳細を使う方法、2つ目は Dataverse コネクタで承認応答テーブルを直接クエリする方法です。

1つ目のアプローチでは、承認の開始と待機アクションの出力から応答配列を参照し、それぞれに適用（Apply to each）で回して各承認者のコメントを取り出します。これは標準コネクタのみで完結するため、ライセンス追加が不要です。ただし応答配列の構造を正確に把握する必要があります。

// Apply to each の中で使うコメント取得の式
items('Apply_to_each')?['comments']

2つ目の Dataverse コネクタを使うアプローチでは、承認応答テーブルを承認IDでフィルターしてコメントを取得します。こちらのほうが柔軟性は高いですが、後述するプレミアムライセンスが必要になります。

多段承認の履歴追跡

連続した承認（多段承認）を使っている場合、第1承認者のコメントと第2承認者のコメントを分けて記録したいケースがあります。承認ステップテーブルと承認応答テーブルを組み合わせることで実現できますが、設計がやや複雑になります。

ステップ番号でコメントを仕分ける

承認ステップテーブルにはステップ番号（順序）が記録されています。承認応答テーブルと承認ステップテーブルをリレーションでつなぐことで、第1ステップの承認者コメント・第2ステップの承認者コメントを区別して取得できます。

ただし、この操作は Dataverse コネクタのリレーションクエリを使うため、プレミアムライセンスが必要です。標準ライセンスのみの環境では、Apply to each でステップインデックスを自分で管理する方法で代替するのが現実的です。

ライセンスの考え方

Dataverse コネクタ（行を一覧表示する・行を取得するなど）はプレミアムコネクタに分類されます。つまり、承認応答テーブルや承認ステップテーブルを Dataverse コネクタで直接操作するには、フローを実行するユーザーに Power Automate Premium（または Power Apps Premium）ライセンスが必要です。

操作	必要なライセンス
承認コネクタで承認フローを動かす	Microsoft 365 標準ライセンス
承認アクションの出力でコメントを取得する	Microsoft 365 標準ライセンス
Dataverse コネクタで承認応答テーブルを直接クエリする	Power Automate Premium
Dataverse コネクタでリレーションクエリを使う	Power Automate Premium

社内でプレミアムライセンスが使えない場合は、標準の動的コンテンツの範囲でコメントを取得する設計に留めるのが現実解です。コメントの記録先として SharePoint リストを使う場合は、SharePoint リストのデータ読み書きの基本も参考にしてください。

Dataverse テーブルを確認する方法

実際にどんなデータが入っているかを確認したい場合は、Power Apps のメーカーポータル（make.powerapps.com）からテーブルを直接参照できます。Dataverse の標準テーブルは隠しテーブルとして存在しているため、テーブル一覧には表示されませんが、論理名で検索すると見つかります。

make.powerapps.com にアクセスし、左メニューからテーブルを選ぶ
すべてのテーブルを表示に切り替え、検索欄に msdyn_approval と入力する
該当テーブルを開き、データタブでレコードを確認する

実際のレコードを見ながら設計するほうが、どのカラムに何が入るかイメージしやすくなります。フローの設計で詰まったときは一度確認してみることをおすすめします。

まとめ

承認コネクタの裏側では、Dataverse の4つの標準テーブルが連携してデータを管理しています。コメントを取得したい場合は承認応答テーブルを、多段承認の履歴を追いたい場合は承認ステップテーブルを参照する必要があります。

プレミアムライセンスなしでもコメント取得は可能ですが、できることの範囲は変わります。仕組みを理解した上で、自分の環境に合った設計を選んでいきましょう。市民開発とはこういう地道な仕組み理解の積み重ねだと思っています。

テンプレートで始める！Forms 承認フロー作成法｜Excel 台帳への自動記録まで

Wed, 08 Apr 2026 19:21:16 GMT

Power Automate の承認フローは、一から作ろうとすると意外なところでハマります。初心者にとっては、まずテンプレートを使って動くものを作ることが最初の一歩です。

この記事では、Power Automate に用意されている「Microsoft Forms の応答を承認して Excel に追加する」テンプレートを使い、Forms で申請を受け付けて Excel 台帳に記録するところまでの手順を解説します。テンプレートを使うことで、承認フローの骨格をゼロから組む手間が省け、接続設定と判定ロジックの修正に集中できます。承認フロー全体の種類や使い分けについては Power Automate 承認フロー完全ガイドにまとめていますので、全体像を把握したい方はそちらも参照してください。

まずはテンプレートを探す

Power Automate の画面を開き、左メニューのテンプレートをクリックします。検索欄に承認と入力すると、承認に関するテンプレートが一覧表示されます。その中から Microsoft Forms の応答を承認して Excel に追加する、を選んでください。

テンプレートの説明画面が開いたら、接続に使うアカウントが表示されます。Forms・Approvals・Excel・OneDrive の4つのコネクタが並んでいるはずです。すべて自分のアカウントでサインインされていれば、そのまま続行をクリックします。ここで別のアカウントが表示されている場合は、後の手順で接続のズレが起きるので注意が必要です。

準備物を揃える

テンプレートを使う前に、3つのものを先に用意しておくとスムーズです。

Microsoft Forms で申請フォームを作成する（例：書籍購入申請フォーム。申請者名・書籍名・金額・理由の4項目）
Excel ファイルをテーブル形式で作成し、OneDrive に保存する（列は申請者名・書籍名・金額・理由・承認結果の5列を用意する）
OneDrive の保存場所のパスをメモしておく

Excel はテーブル形式でないと Power Automate から正しく認識されません。データを入力した範囲を選択して、挿入 → テーブル、からテーブル化しておきましょう。なお、Excel のデータソースとしての使い方については Excel をデータソースとして使う際の注意点にまとめているので、併せて参考にしてください。

接続設定とフローIDの紐付け

テンプレートを続行すると、フローの編集画面が開きます。最初のトリガー「フォームが送信されたとき」の設定から始めましょう。フォームIDのドロップダウンを開き、先ほど作成した申請フォームを選択します。

次にフォーム応答の詳細を取得するアクション（Get response details）に進みます。ここでも同じフォームを選んだうえで、応答IDの欄に動的コンテンツから応答IDを差し込みます。この応答IDの挿入を忘れると、毎回同じ回答しか取得できないというバグが発生します。私が最初に作ったときもここで詰まりました。動的コンテンツのパネルで応答IDが見つからない場合は、一度フォームIDを別の選択肢にしてから戻すと表示されることがあります。

判定ロジックの修正

テンプレートには承認の開始と待機アクションの後に条件分岐（条件 / Condition）が用意されています。この条件分岐の設定を確認してください。

テンプレートのデフォルトでは、結果が Approve と等しい場合を承認ルートにしていることがあります。しかし、実際の承認コネクタが返す値は Approve です（スペルに問題はありませんが、大文字・小文字が厳密に一致しているかを確認してください）。条件式の右辺の文字列が正しく Approve になっているかを確認し、必要であれば修正してください。特にテンプレートによっては approved と小文字になっているケースがあります。

なお、Power Automate の条件分岐の考え方については If と Switch の使い分けも参考になります。Power Apps の記事ですが、条件の組み立て方は共通する部分が多いです。

アクションのコピペで却下側も設定する

条件分岐の「はい（承認）」ルートには Excel にデータを追加するアクション「テーブルに行を追加」が入っています。却下側にも同じ処理を入れたい場合、ゼロから設定し直す必要はありません。承認ルートのアクションを右クリックしてコピーし、却下（いいえ）ルートにペーストするだけです。

コピーしたアクション内の承認結果列に差し込んでいる動的コンテンツを拒否や却下に書き換えれば、却下された申請も Excel 台帳に記録されるようになります。承認・却下どちらのケースも記録することで、後から申請状況を一覧で確認できる台帳が完成します。

テスト送信して動作確認する

フローを保存したら、まず自分でフォームに回答してテスト送信します。Power Automate のフロー詳細画面から実行履歴を確認すると、各アクションが正常に完了しているかどうかをステップごとにチェックできます。

承認の通知は Teams または Outlook に届きます。承認・拒否いずれかのボタンを押してから実行履歴を再確認し、Excel 台帳にデータが追記されていれば成功です。もし実行履歴でエラーが表示されている場合は、該当のアクション名を展開して入力、出力を確認するのが最速の解決方法です。

フロー全体の変数や命名については Power Automateの変数命名規則も参考になります。テンプレートをそのまま使うと変数名がわかりにくいまま残ることがあるので、自分が後から見てわかる名前に変えておくことをおすすめします。

まずは小規模な申請から始める

書籍購入申請のような、承認者1人・金額も少額な申請から始めるのがおすすめです。最初から経費申請や稟議書に使おうとすると、例外ケースが多くて設定が複雑になります。小さな申請で一度フローを動かし、承認の流れを実感してからステップアップしていくほうが、チーム全体の理解も得やすいです。

承認通知のメール文面や Teams メッセージは、フローの承認の開始と待機アクション内の詳細欄でカスタマイズできます。申請者の名前や申請内容を動的コンテンツで差し込み、承認者がひと目で内容を判断できる文面にしておきましょう。Power Automate 全体の機能マップは Power Automate 入門ガイドで確認できます。

市民開発とは、こういう地道な積み上げだと思っています。テンプレートをベースに、自分たちの業務に合わせて少しずつ改良を重ねていくことで、使い勝手のいいフローに育っていきます。

Power Automate 承認フロー完全ガイド｜作り方・種類・運用のコツを徹底解説

Wed, 08 Apr 2026 19:21:14 GMT

Power Automate の承認フローは、使いこなすまでの道のりが意外と長いです。基本の作り方を覚えた後も、申請者名が自分の名前になってしまう、30日で勝手に止まる、コメントが取得できない、といった問題が次々と出てきます。

この記事では、承認フローの全体像を把握するためのハブ記事として、作り方の種類・通知先の選び方・よくあるトラブルと解決策・上級テクニックまでを一気に整理します。それぞれの詳細は各サテライト記事で解説しているので、気になるテーマに合わせて読み進めてください。

承認フローの基本構造

Power Automate の承認フローは、承認コネクタが提供する承認の開始と待機アクションを中心に組み立てます。このアクションが承認者に通知を送り、承認者がボタンを押すまでフローが一時停止し、応答を受け取ったら後続の処理（記録・通知・ステータス更新など）に進む、という流れです。

トリガーの種類は大きく2つに分かれます。Forms の回答をトリガーにするフォーム型と、SharePoint リストのアイテム作成・変更をトリガーにするリスト型です。どちらを選ぶかは申請の入口（申請者がどこで入力するか）によって決まります。

種類	申請入口	向いているケース
フォーム型	Microsoft Forms	社外からの申請・シンプルな1回限りの申請
リスト型	SharePoint リスト	ステータス管理が必要・証跡を一覧で管理したい
Power Apps型	Power Apps アプリ	入力UIをカスタマイズしたい・複雑な申請フォーム

Power Automate 全体の入門についてはPower Automate 入門——変数・データ処理・通知・デバッグの全体マップで解説しています。承認フローを作る前にフロー全体の基礎を押さえておくと、設計がスムーズになります。

承認の種類：1人・並列・多段

承認コネクタには、承認の種類として単一の承認・全員の承認・最初に応答した人の承認・連続した承認の4種類があります。フローの要件に合わせて選びます。

単一承認と全員承認

単一の承認は、承認者として指定した誰か1人が応答すればフローが進みます。複数人を指定した場合は最初に応答した人の判断が採用されます。全員の承認は、指定した全員が承認しないと次に進みません。役員全員の合意が必要な稟議などに適しています。

連続した承認（多段承認）

連続した承認は、承認者が複数のステップに分かれて順番に承認していく多段承認を実現します。第1承認者が承認したら第2承認者に通知が届く、という直列フローを1つのアクションで組めます。途中で誰かが拒否した時点でフローが終了します。詳しくは多段承認の設定方法と連続した承認の実装で解説しています。

通知先：Teams か Outlook か

承認依頼の通知先は Teams と Outlook の2択です。承認者が Teams を日常的に使っている組織では Teams 通知が圧倒的に反応が早く、メール文化が根強い組織では Outlook 通知のほうが自然に受け取ってもらえます。

どちらを選ぶべきか、それぞれのメリット・デメリット・ハイブリッド設計のアイデアはTeams と Outlook どっちが正解？最適な通知設計でまとめています。

フォーム型承認の作り方

初心者が最初に試すなら、Microsoft Forms と承認フローを組み合わせるフォーム型がおすすめです。Power Automate にはテンプレートが用意されており、Forms の回答を承認して Excel 台帳に記録する、という一連の流れをゼロから作らずに始められます。

テンプレートの使い方・接続設定のポイント・判定ロジックの修正まで、テンプレートで始める Forms 承認フロー作成法で丁寧に解説しています。承認フローを初めて作る方はここから読んでください。

リスト型承認の作り方

証跡管理や複数申請の一覧把握が必要な場合は、SharePoint リストをデータソースにするリスト型が向いています。申請ごとにステータス列を持たせ、フローがステータスを自動更新する設計にすることで、承認待ち・承認済み・却下の状態を一覧で管理できます。

ステータス列の設計・催促機能・取り下げ機能の実装まで、SharePoint リストで構築する本格承認ワークフローで解説しています。

よくあるトラブルと解決策

承認依頼の要求元が開発者の名前になる

自動トリガーで起動する承認フローで起きやすい問題です。承認コネクタの要求元プロパティを指定していないと、コネクタ接続に使われているアカウント（フロー作成者）の名前が表示されてしまいます。トリガーから申請者のメールアドレスを取得して要求元に差し込む設定で解決します。詳細は承認依頼の要求元が開発者になる問題の解決法を参照してください。

30日でフローが止まる

承認者が30日以内に応答しないと、フローが強制終了してエラーになります。役員承認や長期休暇をまたぐ申請で特に起きやすいです。次の実行条件でタイムアウト時の通知を送る設定と、Do Until ループを使った高度な設計の両方を承認フロー30日の期限切れ対策で解説しています。

承認依頼の詳細欄を読みやすくする

承認依頼の詳細欄に申請内容をベタ書きすると、承認者の画面では改行なし・装飾なしの読みにくいテキストになります。Markdown 記法（太字・改行・箇条書き・リンク）と concat 関数を組み合わせることで、承認者が判断しやすい見やすい詳細欄を作れます。

実践的なテンプレートとデバッグ手順は承認依頼を読みやすく装飾する Markdown 実践術にまとめています。

承認コメント・履歴を記録に残す

承認者のコメントを後から参照したい、誰がいつ承認したかを記録したい、という要件は実務でよく出てきます。承認データは Dataverse の4つの標準テーブルに保存されており、コメントは承認応答テーブルを参照しないと取得できません。

Dataverse テーブルの構造・コメント取得の方法・プレミアムライセンスの必要性については承認コネクタの裏側と Dataverse テーブルの仕組みで詳しく解説しています。

まとめ：読む順番のガイド

承認フローに初めて取り組む方は、まずフォーム型承認の記事から手を動かして動くフローを作り、その後でリスト型・多段承認と段階的に発展させていくのが着実です。トラブルが出たら要求元問題・30日制限の記事を参照してください。

運用が安定してきたら、詳細欄の Markdown 装飾・通知先の設計・Dataverse の裏側という順で深掘りしていくと、承認フローの設計力が一段上がります。市民開発は一度に完璧を目指さず、動くものを作りながら改善していくのが長続きのコツです。

承認依頼を読みやすく装飾する Markdown 実践術｜詳細欄に改行・太字・リンクを入れる方法

Wed, 08 Apr 2026 19:21:15 GMT

承認依頼の詳細欄がベタ書きで読みにくい、という声は多いです。改行が反映されず情報が詰まって見える、どこに何が書いてあるかわからない、そういった問題は Markdown 記法を使うだけで一気に解決します。

この記事では、Power Automate の承認アクションの詳細欄で使える Markdown 記法の基本から、文字列補間を使った実践的な組み立て方、デバッグの手順までを解説します。設定変更は不要で、記法を覚えるだけですぐに使えます。

なぜ詳細欄は読みにくくなるのか

Power Automate の承認コネクタには詳細（Details）という項目があります。承認者が通知を受け取ったとき、この欄に書いた内容が申請内容として表示されます。しかしここに普通にテキストを入力すると、改行が無視されてすべての情報が1行にぎゅっと詰まった状態で届いてしまいます。

たとえば申請者名・申請日・申請内容・金額を縦に並べて書いたつもりでも、承認者の画面では全部つながった一文として表示されます。これでは承認者が内容を把握するのに時間がかかり、判断ミスや承認漏れの原因にもなります。私が社内で承認フローを作り始めた頃、承認者から何が書いてあるかわからないとフィードバックをもらい、ここに手を入れるようになりました。

承認フロー全体の設計についてはPower Automate 承認フロー完全ガイドにまとめています。この記事では詳細欄の装飾に絞って解説します。

Markdown 記法の基本：まず覚える5つのルール

Power Automate の承認詳細欄では Markdown 記法の一部が使えます。すべてが使えるわけではありませんが、実務で必要な装飾はほぼカバーできます。

改行：半角スペース2つ＋改行

Markdown の改行は、行末に半角スペースを2つ入れてから改行する必要があります。ただし Power Automate の式エディターでは改行コード \n を使うほうが確実です。テキスト入力欄で直接改行しても反映されないことが多いため、後述する文字列補間と組み合わせて \n で改行を明示するのをおすすめします。

太字：アスタリスク2つで囲む

強調したい語句は **太字にしたい文字** のようにアスタリスク2つで前後を囲みます。申請内容のラベル部分（申請者・申請日・金額など）を太字にすると、承認者が一目で項目を把握しやすくなります。

**申請者**：守屋 祐輔
**申請日**：2026-04-07
**申請金額**：50,000円

箇条書き：ハイフンで始める

ハイフン（-）で始めると箇条書きリストになります。申請内容が複数の項目にわたる場合や、承認条件を列挙する場合に便利です。

- 申請理由：社内備品購入
- 購入先：〇〇株式会社
- 納品予定：2026年4月末

リンク：テキストとURLをセットで書く

承認者に関連資料や申請フォームのリンクを渡したい場合は [リンクテキスト](URL) という形式で書きます。SharePoint の申請ページや添付ファイルへの直リンクを詳細欄に入れておくと、承認者が内容を確認するまでの手間が減ります。

[申請フォームを確認する](https://sharepoint.com/sites/your-site/申請一覧)

水平線：ハイフン3つ

-– とハイフンを3つ並べると水平線が引けます。申請内容と添付情報を区切るなど、セクションを視覚的に分けたいときに使います。

文字列補間で Markdown を動的に組み立てる

実務では申請者名や申請内容は動的コンテンツから取得するため、固定テキストとして書くわけにはいきません。そこで Power Apps の文字列補間（$“…” 記法）の考え方を Power Automate の式でも応用します。

concat 関数で文字列を組み立てる

承認アクションの詳細欄には式を入力できます。concat 関数を使って Markdown の文字列と動的コンテンツを連結するのが基本パターンです。

concat(
  '**申請者**：', triggerOutputs()?['body/申請者名'], '\n',
  '**申請日**：', triggerOutputs()?['body/申請日'], '\n',
  '**金額**：', triggerOutputs()?['body/金額'], '円', '\n',
  '---', '\n',
  '[申請内容の詳細を確認する](', triggerOutputs()?['body/リンク'], ')'
)

\n が改行コードです。concat 関数の引数として文字列リテラルと動的コンテンツを交互に並べていくイメージです。文字列補間と concat の使い方について詳しくは文字列補間 $“…” とアンパサンド記法の比較も参考になります。Power Apps の考え方ですが、文字列連結の感覚は共通しています。

デバッグのコツ：Compose で事前に確認する

組み立てた文字列が意図通りに表示されるかどうかは、実際に承認依頼を送ってみるまでわかりません。しかし毎回承認依頼を送って確認するのは手間がかかりすぎます。そこで作成（Compose）アクションを使って、詳細欄に入れる前に文字列の中身を確認する手順をおすすめします。

Compose で文字列の出力を確認する手順

承認アクションの前に作成（Compose）アクションを追加する
Compose の入力欄に、詳細欄に入れる予定の式をそのまま貼り付ける
フローを手動実行し、Compose の出力結果を実行履歴から確認する
改行や太字が意図通りに組み立てられていれば、その式を承認アクションの詳細欄に移植する

Compose アクションはこういったデバッグ用途でも非常に便利です。式の組み立て方や活用パターンについてはCompose アクションのデバッグと式の整理に使う実践ガイドで詳しく解説しています。

承認者が読みやすい詳細欄のテンプレート

実務で使いやすい詳細欄のテンプレートをまとめておきます。動的コンテンツの部分はフローのトリガーや取得元に合わせて書き換えてください。

concat(
  '**申請者**：', triggerOutputs()?['body/申請者名'], '\n',
  '**部署**：', triggerOutputs()?['body/部署'], '\n',
  '**申請日**：', triggerOutputs()?['body/申請日'], '\n',
  '---', '\n',
  '**申請内容**', '\n',
  triggerOutputs()?['body/申請内容'], '\n',
  '---', '\n',
  '[申請フォームを確認する](', triggerOutputs()?['body/フォームURL'], ')'
)

このテンプレートを使うと、承認者の画面では申請者・部署・申請日が太字のラベル付きで整然と並び、水平線で区切られた後に申請内容の本文が続き、最後に申請フォームへのリンクが表示されます。ベタ書きのときと比べると、承認者の判断スピードが体感的に上がります。

テキスト関数の全体像を理解したい場合はPower Apps テキスト関数完全ガイドも合わせて読んでみてください。文字列操作の考え方は Power Automate の式にも通じる部分が多いです。

まとめ

承認依頼の詳細欄は、ちょっとした工夫で承認者の負担を大きく減らせる場所です。太字・改行・箇条書き・リンクを組み合わせるだけで、読み解くのに苦労していた詳細欄が一目でわかる申請書に変わります。

まずは太字と改行だけでも取り入れてみてください。フローの品質は、こういう細かい積み重ねで上がっていくものです。

Power Automate 承認依頼の要求元が開発者になる問題を解決する｜フロー接続とプロパティ設定

Wed, 08 Apr 2026 19:21:15 GMT

Power Automate で承認フローを作ったとき、承認者に届くメッセージの送り主が自分（フロー作成者）の名前になってしまうことがあります。申請者は別の人のはずなのに、なぜそうなるのか。原因と解決策を整理します。

発生する問題：承認依頼の送り主が開発者になってしまう

自動トリガー（SharePoint リストの項目作成など）を使った承認フローでは、承認者が Teams や Outlook で受け取るメッセージの要求元欄に、フローを作成したアカウントの名前が表示されます。申請者が田中さんなのに、承認者のTeamsには守屋さん（開発者）からの承認依頼と表示される、という状況です。

これは承認者にとって非常に紛らわしく、誰の申請なのかを本文を読まないと判断できません。承認件数が増えてくると、この問題が運用上のストレスになります。社内で承認フローを展開してすぐにこの問題に直面しました。実際に誰からの申請かわからないという声が承認者から上がってきたので、早急に直した経験があります。

Power Automate の基本的なコネクタ構成についてはPower Automate 入門記事でも解説していますが、承認コネクタ特有のこの問題は見落とされやすいポイントです。

原因：コネクタ接続と要求元プロパティの仕組み

承認コネクタの「開始して承認を待機する」アクションには、詳細オプションの中に「要求元」というプロパティがあります。このプロパティを空白のまま使うと、コネクタの接続に使われているアカウント情報が自動的に要求元として使われます。

コネクタの接続はフロー作成時に設定するもので、通常はフロー作成者のアカウントが使われます。つまり、要求元を明示的に指定しない限り、誰が申請してもフロー作成者の名前が表示され続けるのです。

解決策①：トリガーから申請者のメールアドレスを取得する

最もシンプルな解決策は、トリガーの動的コンテンツから申請者のメールアドレスを取得して要求元に差し込むことです。SharePoint リストのトリガーであれば、作成者（Created By）の中にEmailという動的コンテンツが含まれています。これを要求元フィールドにそのまま入れるだけです。

承認アクションの詳細オプションを表示するをクリックして展開する
要求元フィールドをクリックする
動的コンテンツから作成者 Emailを選択する

これだけで、承認者が受け取るメッセージの送り主が申請者のアカウントに変わります。追加のアクションも不要で、設定箇所は1か所だけです。

Formsトリガーの場合の注意点

Microsoft Forms をトリガーにしている場合、動的コンテンツに直接メールアドレスが出てきません。Forms の回答データには「回答者のメール」という項目がありますが、匿名回答を許可している場合は取得できないことがあります。

Formsでログインユーザーのみ回答を許可する設定にしている場合は、回答者のメールを要求元に設定できます。外部ユーザーが申請するケースがある場合は、Formsフォームに申請者メールアドレスの入力欄を用意しておき、その値を要求元に使う方法もあります。

解決策②：Office 365 ユーザーコネクタで表示名を取得する

メールアドレスを要求元に設定するだけでも表示が改善されますが、承認者のTeamsに表示される名前が yamada@company.com のようなメールアドレスのまま表示されることがあります。見た目をより自然にしたい場合は、Office 365 ユーザーコネクタのユーザープロファイルの取得（V2）（Get user profile (V2)）アクションを使って正式な表示名を取得する方法があります。

手順は以下の通りです。

承認アクションの前にユーザープロファイルの取得（V2）アクションを追加する
ユーザー（User (UPN)）フィールドに、トリガーから取得した申請者のメールアドレスを入れる
このアクションの出力表示名（Display Name）を、承認アクションの要求元フィールドに設定する

こうすることで、承認者のTeamsに山田太郎のような正式な表示名が出るようになります。社内ユーザーであればほぼ確実に取得できますが、外部ユーザーやゲストアカウントの場合は取得できないことがあるため注意が必要です。

承認履歴への影響と運用上のメリット

要求元を正しく設定することで得られる恩恵は、見た目の改善だけではありません。Teams の承認アプリや Outlook の承認履歴を振り返ったとき、誰がどの申請を出したかが一目瞭然になります。承認者が複数の案件を同時に抱えている場合、要求元が正しく表示されているほうが優先度の判断がしやすくなります。

また、承認フローの運用ログとして SharePoint リストのステータス列とあわせて管理している場合、申請者情報の一貫性が保たれるため、後から案件を検索・フィルターするときにも役立ちます。Power Apps で申請者別に案件を絞り込むユーザーフィルターの実装と組み合わせると、申請管理アプリとしての完成度がさらに上がります。

接続アカウントの管理：共有フローでの注意

フローを同僚と共有したり、チームの共有環境に移行したりするタイミングで、コネクタの接続アカウントが意図せず変わってしまうことがあります。フローを別のユーザーが編集すると、そのユーザーの接続に切り替わり、要求元の設定が壊れるケースがあります。

予防策としては、要求元に動的コンテンツを使って申請者のメールアドレスを明示的に設定しておくことです。固定値（ハードコード）で誰かのメールアドレスを入れるのは避けましょう。動的コンテンツで取得する限り、接続アカウントが変わっても申請者の名前が正しく表示されます。

承認フロー全体の設計やコネクタの選び方については、承認フロー完全ガイドでより包括的にまとめています。要求元の設定はほんの1手間ですが、申請者・承認者の双方にとって使いやすいフローを作るうえで欠かせない設定です。設計段階で忘れずに組み込んでおきましょう。

Power Automate 連続した承認の設定方法｜多段（ステップ）承認をシンプルに実装する

Wed, 08 Apr 2026 19:21:16 GMT

Power Automate の承認フローで多段承認を実装しようとしたとき、以前はループ処理を組まなければなりませんでした。しかし現在は、承認コネクタに標準搭載された連続した承認機能を使えば、アクション1つで順次承認フローを構築できます。

この記事では、連続した承認の設定手順・宛先の指定方法・判定ルール・制限事項まで、実務ですぐに使えるレベルで解説します。承認フロー全体の種類や使い分けについては Power Automate 承認フロー完全ガイドにまとめていますので、全体像を把握してから読むとより理解が深まります。

連続した承認とは何か

連続した承認とは、承認者を複数設定し、1人目が承認したら2人目へ、2人目が承認したら3人目へ、という順序で承認を回していく仕組みです。以前は Apply to each（それぞれに適用）アクションでループを組み、変数で承認者リストを管理する必要がありました。それが現在は、承認アクションの種類として連続した承認を選ぶだけで実現できるようになっています。

Apply to each を使った方法は Power Automateの「Apply to each」完全攻略で詳しく解説していますが、連続した承認機能が使える場面ではそちらを使うほうがフローがシンプルになります。設定の手間も大幅に減るので、今から多段承認を実装するならまず連続した承認を検討することをおすすめします。

設定手順

承認アクションを追加する

フローの編集画面で承認の開始と待機アクションを追加します。アクションの種類（承認の種類）のドロップダウンを開くと、選択肢の中に連続した承認が表示されます。これを選択してください。

担当者を順番に設定する

連続した承認を選択すると、「担当者 1」「担当者 2」という入力欄が表示されます。ここに承認者のメールアドレスを順番に入力します。担当者を追加したい場合は新しいステップを追加から担当者を増やすことができます。

注意点として、この担当者欄には通常のアクションのようにサジェスト（候補一覧）が表示されないことが多いです。メールアドレスを直接入力する必要があります。動的コンテンツから取得したメールアドレスを差し込む場合は、式（Expression）を使って直接参照するか、事前に作成（Compose）アクションで整形してから参照してください。

複数人を1ステップに入れたい場合は、メールアドレスをセミコロンで区切ります。例えば担当者1欄に user1@example.com;user2@example.com と入れると、そのステップでは2人のどちらかが承認すれば次のステップに進みます。この区切り方については Concat関数でセミコロン区切りの宛先を生成する方法も参考になります。

判定のルールを理解する

連続した承認には、押さえておくべき判定ルールがいくつかあります。これを知らないままフローを組むと、意図しない動きをして原因がわからなくなります。

1人が拒否したら即終了

連続した承認では、途中のステップで1人でも拒否すると、そこでフローが終了します。残りのステップに通知は届きません。例えば担当者が3人いて担当者2が拒否した場合、担当者3には一切通知が行かず、フローは拒否ルートに分岐します。

この仕様は業務フローとして自然なことが多いですが、全員の承認結果を記録したい場合などは別の実装方法を検討する必要があります。

1ステップに複数人いる場合は誰か1人で進む

1つのステップに複数人を設定している場合、そのうちの誰か1人が承認を返せば次のステップに進みます。全員の承認を待つ全員一致型とは異なります。部署内の誰でも承認できる運用に向いています。

全員一致が必要な場合は、承認の種類で全員が承認する必要がありますを選ぶ別の設定を使ってください。連続した承認と全員一致は別の機能です。

途中経過の通知について

各ステップの承認結果（誰が承認したか・拒否したか）は、申請者に自動で通知されます。ただし、第三者（部署全体への共有など）に通知したい場合は、条件分岐の後に別途 Teams や Outlook のアクションを追加する必要があります。

また、各ステップのコメントをすべて記録・参照したい場合は、Dataverse の承認応答テーブルを参照する方法が必要になります。これはプレミアムライセンスが必要な操作です。フロー全体の構造については Power Automate 入門ガイドで全体像を確認しておくと、各アクションの位置づけが理解しやすくなります。

制限事項

連続した承認を使う際には、いくつかの制限事項を把握しておく必要があります。

まず、カスタム応答が使えません。通常の承認アクションでは承認ボタンのラベルを「了承」「要確認」のようにカスタマイズできますが、連続した承認では承認・拒否の2択のみです。ボタンのラベルを変えたい場合は連続した承認は使えません。

次に、承認コネクタのタイムアウト制限（30日）は連続した承認でも同様に適用されます。承認者全員のステップが30日以内に完了しない場合、フローがエラーで停止します。長期にわたる稟議フローなどでは事前に承認者への期限周知が重要です。

また、連続した承認の各ステップに対して個別にタイムアウト設定や催促設定を入れることはできません。フロー全体として1つのアクションとして動くためです。細かい制御が必要な場合は、承認アクションを複数に分けて手動でフローを組む方法を検討してください。

承認者リストを宛先として動的に取得する場合

承認者が固定でなく、申請内容によって変わる場合はどうするか。例えば金額が10万円以上のときは部長承認を追加する、といった場合です。

このような場合は、条件分岐（条件 / Condition）で金額をチェックし、承認ルートを分岐させる方法が現実的です。金額が閾値以下のルートには担当者1人の通常承認、閾値以上のルートには連続した承認（担当者を2人設定）という構成にします。

承認者のメールアドレスを変数（文字列変数 / 変数の初期化）で事前に組み立てておき、担当者欄にその変数を差し込む方法も有効です。変数の初期化・セット・追加の使い方については Power Automateの変数命名規則と合わせて確認しておくと整理しやすいです。

まとめ

連続した承認は、多段承認を最短の設定で実装できる便利な機能です。ただし、カスタム応答が使えない・途中拒否で即終了・30日タイムアウトがあるといった制限もあります。

まずは2段承認の単純なフローから試してみましょう。実際に動かして承認通知を受け取り、各ステップの挙動を体感することが一番の近道です。設定がシンプルなぶん、試行錯誤のコストが低いのも連続した承認の利点です。

SharePoint リストで構築する本格承認ワークフロー｜ステータス管理と催促の実装

Wed, 08 Apr 2026 19:21:16 GMT

Power Automate の承認フローを Forms や Teams で試してみたけど、申請履歴の管理が難しいと感じたことはありませんか。SharePoint リストをデータソースにすれば、ステータスの追跡・証跡管理・催促の仕組みまで一気に整えることができます。

なぜリスト型承認フローが選ばれるのか

承認フローには大きく2つの設計パターンがあります。Microsoft Forms をトリガーにする方法と、SharePoint リストの項目作成をトリガーにする方法です。前者は手軽に始められる反面、申請状況をあとから確認しようとするとExcel台帳を手動で見に行かなければなりません。一方、後者はリスト自体が台帳を兼ねるため、承認担当者が現在どの案件が止まっているかを一覧で把握できます。

私の会社でも最初は Forms 型で運用していましたが、月に30〜40件の申請が走るようになったタイミングであの申請、今どこにあるの？という問い合わせが増えました。リスト型に切り替えてからは、申請者も承認者もリストを見れば状況がわかるようになり、問い合わせがほぼゼロになりました。申請件数が10件を超えてくるあたりで、リスト型への移行を真剣に考えることをおすすめします。

Power Automateの承認フロー全体の設計思想については承認フロー完全ガイドでまとめていますので、あわせて参照してください。

ステータス列の設計

リスト型承認フローの核心は、ステータス列の設計にあります。列の型は選択肢にし、以下の4つの値を用意するのが基本パターンです。

未申請
承認待ち
承認済み
却下

フローの流れとしては、申請者がリスト項目を新規作成した時点でステータスが「未申請」になっています。フローが起動して承認アクションが送信されると「承認待ち」に更新し、承認者が回答したら結果に応じて「承認済み」か「却下」に切り替えます。この更新には SharePoint コネクタの項目の更新（Update item）アクションを使います。

ポイントは、フローの開始して承認を待機するアクションの前後それぞれに項目の更新を入れることです。前の更新でステータスを「承認待ち」にし、後の更新でステータスを結果に応じて分岐させます。SharePoint リストへの基本的な書き込み操作についてはSharePointリストのCRUD操作の基本を参考にしてください。

フロートリガーの設定：無駄な起動を防ぐ

SharePoint リストのトリガーを「項目が作成されたとき」に設定するだけでは、列の更新のたびにフローが動いてしまう場合があります。「項目が作成または変更されたとき」を使う場合は、トリガー条件を設定して、ステータスが「未申請」のときだけフローが走るように絞り込む必要があります。

トリガー条件の式は以下のようになります。

@equals(triggerBody()?['Status']?['Value'], '未申請')

この設定を入れることで、承認結果の書き戻し処理（ステータスを承認済みに更新する処理）によってフローが再起動してしまうループを防げます。トリガー条件の詳しい使い方はトリガー条件とフィルタークエリの解説記事で取り上げています。

添付ファイルの扱いと承認依頼の詳細リンク

稟議書や見積書など、添付ファイルを伴う申請フローでは、承認者が依頼メッセージを受け取った時点でファイルを確認できる状態にしておくことが大切です。承認アクションの詳細欄に SharePoint リスト項目のURLを差し込む方法が最もシンプルです。

動的コンテンツから項目へのリンクを選ぶと、承認者がクリックすれば直接リスト項目のページに飛べます。そのページから添付ファイルを開く流れです。詳細欄に直接ファイルを添付する方法もありますが、ファイルサイズが大きいと承認メールが届かない場合があるため、リンク方式のほうが安定します。

承認依頼の詳細欄には申請内容のサマリーも入れておくと承認者の判断が速くなります。例えば次のような文字列を作成（Compose）アクションで組み立てて、詳細欄に渡します。

申請者：@{triggerBody()?['Author']?['DisplayName']}
申請内容：@{triggerBody()?['Title']}
申請日：@{formatDateTime(triggerBody()?['Created'], 'yyyy/MM/dd')}
リンク：@{triggerBody()?['{Link}']}

催促（フォローアップ）機能の実装

承認者が応答しないケースは必ず発生します。特に役員や部長クラスが承認者になっている場合、メールやTeamsの通知が埋もれてしまうことが多い。こういった状況に備えて、申請者が自分でプッシュできる催促の仕組みを用意しておくと運用がスムーズになります。

実装方法は2段階に分けて考えます。まず1つ目は、承認アクションのリマインダー設定を使う方法です。承認アクションの詳細オプションに承認期限とリマインダーを送信の設定があり、指定した日時を過ぎても未回答の場合に自動でリマインダーメールを送れます。追加のフロー作成は不要なので、まずはこちらを使うことをおすすめします。

2つ目は、申請者が手動で催促できるボタンをPower Apps上に設置する方法です。申請者がリスト項目を選択して催促するボタンを押すと、別途作成した催促フローが起動して承認者にTeamsメッセージを送る、というパターンです。この場合、ステータスが承認待ちの項目のみボタンが押せるよう、ユーザー別フィルターの設計と組み合わせてUIを制御すると完成度が上がります。

取り下げ（キャンセル）機能の考え方

申請を間違えた場合に申請者自身が取り下げられる仕組みも重要です。Power Automate のフローはいったん開始して承認を待機するに入ると、外部から強制停止する手段がほぼありません。そのため取り下げ機能はフローを止めるのではなく、承認アクションが完了した後、キャンセルフラグを確認して処理を分岐させる設計にするのが現実的です。

具体的な手順としては、まずリストに「取り下げ（YesNo型）」列を追加します。申請者がこの列をオンにすると、承認担当者に取り下げの旨を通知する別フローが起動します。本フローでは承認待ちに入った後に取り下げ列がTrueかどうかをチェックする条件分岐を追加しておき、Trueだった場合はステータスを取り下げに更新して処理を終了します。

取り下げのステータス値は最初の設計に含めておくと後から変更しなくて済みます。選択肢に取り下げを追加するのを忘れがちなので注意してください。私はこれを後から追加して、既存フローの条件式を全部書き直す羽目になったことがあります。設計段階でひと手間かけておくと、運用フェーズで楽になります。

Power Apps 連携でUIをリッチにする展望

SharePoint リストとフローの組み合わせができあがったら、次のステップとして Power Apps でフロントエンドのUIを作ることが多いです。リストを直接開いて入力・確認するより、専用アプリのほうが操作ミスが減り、申請件数が増えても管理しやすくなります。

アプリ側では、自分の申請のみ表示、承認待ち案件だけ赤くハイライト、ステータス別にタブを切り替えるといったUIが作りやすくなります。Power Apps でのユーザー別フィルタリングの実装については、別記事で詳しく取り上げています。

承認フローはフロー単体で完結させず、Power Apps・SharePoint・Power Automate の3つをセットで設計することで、申請から承認・記録・通知まで一気通貫のワークフローが完成します。まずはシンプルな1ステップ承認から始めて、運用しながら催促や取り下げ機能を追加していくのが現実的な進め方です。市民開発はこういった地道な積み重ねで完成度が上がっていくものです。

承認依頼は Teams と Outlook どっちが正解？ユーザー環境に合わせた最適な通知設計

Wed, 08 Apr 2026 19:21:14 GMT

Power Automate で承認フローを作るとき、承認依頼の通知先を Teams にするか Outlook にするか迷う場面があります。どちらが正解というわけではなく、組織のコミュニケーション文化と承認者の作業環境によって最適解が変わります。

この記事では Teams 承認と Outlook 承認それぞれのメリット・デメリットを整理し、どちらを選ぶべきかの判断基準と、両方を使いこなすハイブリッド設計のアイデアを紹介します。

Teams 承認のメリットとデメリット

承認コネクタのデフォルトは Teams への通知です。承認者が Teams を普段使いしている組織では、最も導線がシンプルになる選択肢です。

チャット感覚で即レスできる

Teams の承認通知はアクティビティフィードに届き、ポップアップ通知も出ます。承認者はその場でボタンをタップするだけで完了できるため、メールを開いて内容を確認するよりも圧倒的にレスポンスが早くなります。スマートフォンの Teams アプリでも同様に操作できるため、外出中や移動中に承認できる点も実務上の強みです。

私が社内で承認フローを導入したとき、メール通知から Teams 通知に切り替えただけで平均承認時間が半分以下になりました。承認者に余計な操作をさせない設計が、フローの定着に大きく影響します。

承認アプリで一元管理できる

Teams には承認（Approvals）という専用アプリがあります。自分が申請者・承認者として関わっているすべての承認フローの状況を一覧で確認でき、対応漏れを防ぐ管理ハブとして機能します。フローが増えてくると特に重宝します。

承認アプリは Teams の左サイドバーから追加できます。承認者に事前に使い方を案内しておくと、承認依頼が届いたときに迷わず対応してもらえます。

Teams を使っていない承認者には届かない

デメリットとして、承認者が Teams を日常的に使っていない場合に通知を見逃しやすい点があります。特に経営層や外部の取引先など、Teams よりメールを主に使う人が承認者になるケースでは機能しにくいです。そういう組織では Outlook 承認を検討する価値があります。

Outlook 承認のメリットとデメリット

Outlook 承認を選ぶと、承認者にアダプティブカード形式のメールが届きます。メール本文内に承認・拒否ボタンが表示され、メールを開いたままポチッと完結できます。

メール文化の組織にフィットする

チャットよりメールを主なコミュニケーション手段として使っている組織では、承認依頼がメールで届くほうが自然に受け取ってもらえます。Teams の通知設定をしていない人でも、メールなら高確率で目に入ります。稟議フローや役員承認など、メール文化が根強い社内手続きとの相性が特によいです。

アダプティブカードが崩れるリスクがある

Outlook でアダプティブカードが正しく表示されるのは Outlook デスクトップアプリと Outlook on the web です。古いバージョンの Outlook や一部のメールクライアントでは表示が崩れ、ボタンが押せないことがあります。承認者の環境が統一されていない場合は注意が必要です。

また、Outlook 承認では承認アプリのような一覧管理機能がないため、複数の承認フローが同時進行している場合に対応漏れが起きやすい点もデメリットです。

Teams vs Outlook 比較表

比較項目	Teams 承認	Outlook 承認
通知の受け取り方	アクティビティ通知＋ポップアップ	メール受信
承認操作の場所	Teams アプリ内	メール本文内（アダプティブカード）
モバイル対応	非常に良好	環境依存
一覧管理	承認アプリで可能	なし（受信トレイで管理）
向いている組織	Teams を日常使いしている	メール文化が主体
表示の安定性	高い	クライアントに依存

どちらをメインにするか：判断の基準

結論から言えば、承認者が Teams をメインに使っているなら Teams 承認、メールが主体なら Outlook 承認を選ぶのが基本です。ただし実務では承認者が複数いて、Teams 派とメール派が混在することもあります。

承認者に合わせて通知先を切り替える設計

承認アクションの前に条件（Condition）を置き、承認者のメールアドレスや部署情報に応じて Teams 通知と Outlook 通知のどちらを使うか動的に切り替える設計が可能です。少し設計が複雑になりますが、承認者ごとに最適な通知方法を選べます。

ハイブリッド設計：詳細欄に両方のリンクを置く

通知方法をどちらか1つに絞れない場合は、詳細欄に Teams で開くリンクとブラウザで開くリンクの両方を置くハイブリッド設計が現実解になります。承認者は自分の環境や好みに合わせてどちらからでもアクセスできます。

concat(
  '**申請内容**：', triggerOutputs()?['body/申請内容'], '\n',
  '---', '\n',
  '[Teams承認アプリで確認する](https://teams.microsoft.com/l/entity/...)', '\n',
  '[ブラウザで確認する](', triggerOutputs()?['body/申請URL'], ')'
)

Teams の承認アプリのリンクは、承認（Approvals）アプリ内の該当依頼のURLをコピーして使います。承認フローごとに固定リンクを作ることはできませんが、承認アプリへの入口として Teams アプリの一般URLを置くだけでも、承認者の利便性は上がります。

ユーザー教育も合わせて行う

どちらの通知方法を選んでも、承認者に事前に使い方を案内しておくことが定着のカギになります。Teams 通知の場合は承認アプリの場所と使い方、Outlook 通知の場合はメール本文のボタン操作を簡単に説明する社内メモを用意しておくと、問い合わせが減ります。

承認フローの通知設計と合わせて、Teams への自動通知の基本的な仕組みを理解しておくと応用しやすいです。Teams チャットへの自動通知の設定方法で基礎から解説しているので参考にしてください。

承認フロー全体の設計についてはPower Automate 承認フロー完全ガイドにまとめています。通知先の選択は設計の一部に過ぎないため、フロー全体の流れも合わせて確認しておくことをおすすめします。

まとめ

Teams と Outlook のどちらが正解かは、承認者の環境次第です。Teams を日常的に使っている組織なら Teams 承認一択で問題ありません。メールがメインなら Outlook 承認を選び、アダプティブカードの表示確認を忘れずに行いましょう。

どちらを選んでも、詳細欄の情報を Markdown で整理し、承認者が判断しやすい状態にしておくことが大切です。通知方法の選択よりも、承認者が読みやすいかどうかのほうが、フローの定着に影響します。

承認フロー30日の期限切れ対策｜タイムアウトの回避策とエラーハンドリング

Wed, 08 Apr 2026 19:21:15 GMT

Power Automate の承認フローを運用していると、ある日突然フローがエラーで止まっていた、という経験をした方は多いと思います。原因の大半は30日の壁です。承認者が長期間応答しなかっただけで、フロー全体が強制停止してしまうのです。

この記事では、Power Automate の承認フローに存在する30日タイムアウト制限の仕組みを整理したうえで、運用でカバーする方法からエラーハンドリング、さらには高度なフロー設計まで3段階の対策を解説します。

Power Automate の30日の壁とは何か

Power Automate のアクションには、最大実行時間という制限があります。承認（Approvals）コネクタの承認の開始と待機アクションも例外ではなく、承認者が応答しないまま30日が経過すると、アクションが強制的にタイムアウトしてフローはエラー終了します。

問題は、フローがエラーで終了した後に申請者も承認者も気づきにくい点です。Teamsやメールに通知が飛んでいたとしても、30日間放置されていた場合、申請自体が完全に宙に浮いた状態になります。月をまたぐような役員承認や、長期休暇中の代理対応が必要なケースでは特に起きやすい問題です。

私自身も社内の稟議フローを Power Automate で構築した直後、年末年始をまたいだ申請がそのまま止まってしまい、年明けに発覚するという経験をしました。原因を調べるまでフローが壊れたと思っていたほどです。これは仕様なので、最初から対策を組み込んでおくことが大切です。

対策①：運用でカバーする——催促と周知の徹底

一番シンプルな対策は、30日以内に必ず承認してもらうよう運用ルールを整備することです。技術的な対応を入れる前に、まずここから始めるのをおすすめします。

申請時に期限を明示する

承認依頼の詳細欄に「このフローは30日以内に応答がない場合、自動的にエラー終了します」という一文を入れておくだけで、承認者の意識が変わります。システムの制約を明示することは、運用上の誠実さにもつながります。

詳細欄の文字列を組み立てる方法については、作成（Compose）アクションを使って整形するのが便利です。承認依頼の本文をどう作るかという観点は、承認フロー全体の設計を扱ったPower Automate 承認フロー完全ガイドにまとめているので、合わせて参照してください。

Teamsのフォローアップ機能を活用する

Teams の承認通知には、フォローアップのリマインダー設定ができます。承認者が通知を受け取った後、自分でリマインダーをセットできるため、うっかり忘れを防ぐ補助線として有効です。ただしこれはあくまで承認者側の操作に依存するため、申請者が積極的に声がけすることも併用するのが現実的です。

また、承認フローのトリガー起動から一定日数後（たとえば20日後）に自動でリマインドメールを送る、という仕組みを別フローで作っておくと安心です。スケジュール（繰り返し）トリガーと SharePoint リストの申請日を組み合わせれば、承認待ち一覧を定期的にスキャンして催促することもできます。

対策②：エラーハンドリングで止まっても通知する

タイムアウトが発生したとき、フローが黙って止まるのが一番困ります。せめてタイムアウトしました。再申請してくださいという通知を申請者に送れれば、対応の起点にできます。これを実現するのが、アクションの次の実行条件設定です。

次の実行条件でタイムアウト時の分岐を作る

Power Automate では、各アクションに次の実行条件という設定があります。通常は前のアクションが成功したときだけ実行されますが、ここを失敗した場合やタイムアウトした場合に変更することで、エラー発生後の処理を追加できます。

具体的な手順は以下のとおりです。

承認の開始と待機アクションの直後に、メール送信またはTeams通知アクションを追加する
追加したアクションの右上の「…」から設定を開く
次の実行条件セクションでタイムアウトした場合にチェックを入れる（「成功した場合」のチェックは外す）
通知の本文に承認フローが30日間応答なしのためタイムアウトしました。お手数ですが再申請をお願いします、などのメッセージを入れる

この設定をしておくだけで、30日後に自動で再申請依頼の通知が届くようになります。フローが止まっても気づけるだけで、運用の安全性がぐっと上がります。

スコープ（Scope）を使ってエラー処理をまとめる

フロー全体のエラーハンドリングを整理したい場合は、スコープ（Scope）アクションを使う方法が便利です。スコープは複数のアクションをグループ化できるコンテナで、グループ全体が失敗した場合に別処理を走らせるという設計が可能になります。

承認フローの本体をスコープAに入れ、スコープAが失敗したときだけスコープBのエラー通知が動く、という構成にしておくと、フローの見通しがよくなります。スコープを使ったエラー処理の詳しい設計パターンはスコープを使ったエラーハンドリングの実装で解説しているので参考にしてください。

対策③：Do Until ループで30日前に自己完結させる

より根本的な解決策として、フローの設計自体を変えてしまう方法があります。Do Until（実行条件を満たすまで繰り返す）ループと変数を組み合わせて、30日が来る前にフローを一旦正常終了させ、必要なら再トリガーする設計です。

ただしこの方法は実装の難易度が上がるため、まず対策①②を試してから、どうしても解決しない場合の選択肢として考えるのが現実的だと思っています。

Do Until ループの基本的な考え方

通常の承認フローは承認の開始と待機で承認者の応答を待ちますが、この方法では承認の開始と承認の待機を別々のアクションに分割します。承認の開始後、Do Until ループで一定時間ごとに承認状況を確認し、応答があれば後続処理へ、応答がなければリマインド通知を送って再度ループする、という設計です。

Do Until アクションの詳しい使い方についてはDo Until ループで繰り返し処理を実装する方法で解説しています。承認フローに応用する前に、基本的な動作を理解しておくと実装がスムーズです。

変数で経過日数を管理する

Do Until ループの中で変数を使って経過日数をカウントし、たとえば25日を超えたらループを終了してタイムアウト直前の警告通知を送る、という設計が可能です。

変数の初期化で日数カウンターを作り、ループのたびに変数の値を増やすで1日ずつ加算します。Do Until の終了条件として承認済みになっている、またはカウンターが25以上になったを設定するイメージです。

// Do Until の終了条件（式）
@or(equals(variables('ApprovalStatus'), 'Approved'), greaterOrEquals(variables('DayCount'), 25))

上記はあくまで考え方を示すコード例です。実際には Power Automate のデザイナー上でアクションを組み合わせて実装します。フローが複雑になるため、デバッグ時はフロー実行履歴を活用して各ステップの状態を確認しながら進めることをおすすめします。

3つの対策を組み合わせるのが現実解

対策①②③をまとめると、以下のような使い分けになります。

対策	難易度	効果	おすすめのケース
①運用ルール・催促	低	中	まずはここから。全フローに共通して有効
②次の実行条件＋エラー通知	低〜中	高	タイムアウト発生時に気づける最低限の保険
③Do Until ループ	高	最高	月またぎ・役員承認など長期化が確実なフロー

個人的には、まず全フローに対策②を入れておき、長期化が想定されるフローだけ対策③を追加する、という進め方をおすすめします。対策①はどんなフローでも前提として意識しておきたいところです。

承認フローは一度動いたら終わりではなく、運用しながら改善し続けるものです。タイムアウトのエラーログが出たらそのつど記録し、再発防止の設計を積み重ねていくことが大切です。市民開発とはこういう地道な事柄の積み重ねだと思っています。

Power Automateの作成（Compose）アクション。デバッグと式の整理に使う実践ガイド

Mon, 16 Mar 2026 15:46:49 GMT

Power Automateの作成（Compose）アクションは、式の結果を一時的に保存して確認するためのアクションです。デバッグと式の整理、両方の目的で使えます。

式を評価して出力するだけのアクション

作成（Compose）アクションのしくみはシンプルです。入力に式や値を書くと、フロー実行時にその式が評価され、結果が出力として保存されます。保存した値は後続のアクションで動的なコンテンツとして参照できます。

変数とよく似ていますが、作成（Compose）は変数の初期化・設定アクションよりも記述が短く、読み取り専用の中間値を保存するのに適しています。Power Automateの変数の使い方は変数の解説でまとめています。

2つの主な使い方

作成（Compose）を使う場面は大きく2つに分かれます。

1つ目はデバッグ用途です。フローの途中で変数や式の値が想定通りかどうかを確認するために、作成（Compose）に差し込んで実行履歴から中身を見ます。

2つ目は長い式を整理する用途です。後続のアクションで何度も使う長い式を、作成（Compose）で一度計算してから名前で参照すると、フローが読みやすくなります。

デバッグツールとしての作成（Compose）

フローの途中の値を確認する

フローが動かないとき、どのアクションで何がおかしいのかを確認するのは意外と手間がかかります。そんなとき、疑わしい場所に作成（Compose）を差し込んで実行すると、実行履歴でその時点の値を見られます。

例えばFilter arrayの差出人に正しい配列が渡っているか確認したい場合、Filter arrayの前に作成（Compose）を入れてSharePointのアイテムを取得のbody/valueを渡します。実行履歴で作成（Compose）の出力を開くと、配列の中身がJSON形式で表示されます。

実行履歴の確認方法

フローを手動実行またはテスト実行した後、実行履歴のリンクをクリックすると各アクションの実行結果が展開表示されます。作成（Compose）アクションを選ぶと入力と出力の値が確認できます。

私が現場でフローのデバッグをするときは、作成（Compose）を複数箇所に差し込んで、どの段階でデータがおかしくなっているかを追いかけます。問題の箇所が特定できたら作成（Compose）を削除して、フローをスリムな状態に戻します。

式の整理ツールとしての作成（Compose）

長い式に名前をつける

フローの中で何度も使う計算や変換式がある場合、毎回同じ式を書くのは冗長です。作成（Compose）で一度計算した結果を、後続のアクションで outputs(‘作成’) として参照できます。

例えば、現在日時を日本時間で特定のフォーマットにしたい場合を考えます。

// 作成（Compose）アクションの入力欄に書く式
formatDateTime(convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time'), 'yyyy年MM月dd日')

この式を毎回書くより、作成（Compose）でjpDateという名前のアクションに保存して、後続ではoutputs(‘jpDate’)と短く参照するほうがフローが読みやすくなります。

配列や文字列を組み立てる

JSONオブジェクトや配列を手動で組み立てるときも作成（Compose）が便利です。

// SharePointに送るためのオブジェクトを組み立てる
{
  "Title": triggerBody()?['title'],
  "Status": "未対応",
  "CreatedDate": utcNow(),
  "Priority": 2
}

このようなJSONを作成（Compose）で一度組み立てておくと、後続のSharePoint更新アクションに作成（Compose）の出力をそのまま渡せます。Patchや変数アクションで直接書くより、構造が見やすくなります。

変数との使い分け

値を変えない中間計算は作成（Compose）

作成（Compose）と変数は似ていますが、使い分けの基準は明確です。

	作成（Compose）	変数
値の更新	できない（固定）	できる
スコープ	フロー全体で参照可	フロー全体で参照可
初期化アクション	不要	必要（変数を初期化）
記述の手間	少ない	初期化＋設定の2ステップ

ループの中でカウントアップしたいなら変数、一度計算した日付や文字列を使いまわしたいなら作成（Compose）、という使い分けが基本です。

Apply to eachの中では作成（Compose）を使わない

Apply to eachのループ内に作成（Compose）を置いた場合、各ループの実行結果で出力が上書きされます。ループが終わった後に作成（Compose）を参照すると最後のループの値しか残っていません。ループをまたいで値を積み上げたいなら変数を使いましょう。

Apply to eachとループ処理の詳細はApply to eachの解説を参照してください。

作成（Compose）の実践的な使い方まとめ

デバッグのフロー

エラーまたは想定外の動作が起きているアクションの直前に作成（Compose）を追加
確認したい値（配列・オブジェクト・文字列）を作成（Compose）の入力に設定
フローを手動実行
実行履歴で作成（Compose）の出力を確認
問題の原因が特定できたら作成（Compose）を削除してフローを整理

デバッグが終わったら作成（Compose）を残したままにしないことが大切です。不要なアクションが増えるとフローが読みにくくなります。実行履歴の見方やデバッグの手順は Power Automateのデバッグ・実行履歴活用の記事でまとめます。

式整理のフロー

フローの中で複数回使う長い式を特定する
最初に使う箇所の直前に作成（Compose）を追加して、わかりやすい名前をつける（例：FormatDate）
後続のアクションでは outputs(‘FormatDate’) で参照する

作成（Compose）のアクション名はわかりやすい名前に変えておきましょう。デフォルトの名前だと、どれが何のための作成（Compose）か区別がつかなくなります。

まとめ

作成（Compose）はそれ自体が何かを実行するわけではありませんが、デバッグと式の整理という2つの目的でフロー開発をサポートしてくれます。

まずはフローが期待通りに動かないときの確認手段として使ってみてください。データの流れを目で確認できるようになると、Power Automateの式のしくみも自然に理解が深まります。Power Automateの開発に慣れてきたら、長い式の整理にも積極的に使っていきましょう。

Power Automate × Excel Scripts でCSVをXLSXに変換してSharePointリストに取り込む

Sun, 05 Apr 2026 10:18:36 GMT

Power AutomateにはCSVをそのまま処理するアクションがありません。CSVをXLSXのテーブル構造に変換してからSharePointリストに取り込む。Excel ScriptsとPower Automateを組み合わせることで、この流れを自動化できます。

なぜCSV→XLSX変換が必要か

Power AutomateにはCSVファイルを直接読み込んで行データを取得するアクションがありません。一方でExcelファイルのテーブルに対しては「List rows present in a table（テーブルに存在する行の一覧表示）」アクションが使えます。このアクションさえ使えるようになれば、後はCreate item（項目の作成）でSharePointリストに一行ずつ書き込むだけです。

CSVをXLSXのテーブル構造に変換することで、Power Automateの標準アクション群が使えるようになります。そのCSV→XLSX変換を担うのがExcel Scriptsです。SharePointへのデータ書き込みの基礎についてはSharePointのCRUD操作の基礎記事を先に確認しておくとスムーズです。

Excel Scriptsとは

Excel ScriptsはExcelのAutomateタブで作成・管理するTypeScriptベースのスクリプトです。Power Automateの「Run Script（スクリプトの実行）」アクションから引数を渡して実行できます。ブラウザ版ExcelのファイルFの内部でのみ動作するため、ファイル名の変更や外部ファイルへのアクセスはできません。

TypeScriptを知らなくても使えます。後述するようにChatGPTで生成・修正するサイクルを回せばゼロ知識から実用的なスクリプトが完成します。私自身もTypeScriptはほぼ書けませんが、ChatGPTとの対話だけでCSV処理スクリプトを完成させた経験があります。

フロー全体の構成とトリガーの選択

5ステップの全体像

フロー全体の処理は5つのステップで構成されます。

CSVファイルを選択するトリガー（For Selected Item）
CSVファイルのコンテンツを取得（Get file content・ファイルコンテンツの取得）
テンプレートExcelファイルをコピーして新ファイルを生成（Create file・ファイルの作成）
Run Script（スクリプトの実行）でCSVをXLSXテーブルに変換
List rows present in a table → Apply to each（それぞれに適用）→ Create item（項目の作成）でSharePointに取り込み

For Selected Itemトリガーの重要な制約

For Selected Itemトリガーを使うフローには重要な制約があります。このトリガーを使うフローはデフォルト環境で作成しないと、SharePointの自動化メニューに表示されません。他の環境で作成すると一覧に出てこず動作しないため、フロー作成時に最初に環境の選択を確認してください。デフォルト環境以外で作っていてシェアポイントの自動化メニューに出てこないという場合、環境の作り直しが必要になります。最初の一手で確認しておくのが重要です。

テンプレートExcelファイルの設計思想

スクリプトをあらかじめ埋め込んだ空のXLSXをテンプレートとして用意します。フローの実行ごとにCreate file（ファイルの作成）でテンプレートをコピーして新しいExcelを生成する設計にすることで、同名ファイルの上書きや競合を防げます。

ファイル名には日時を付与してユニークにします。

// ファイル名に日時を付与する例（Create fileのNameフィールド）
concat('output_', formatDateTime(utcNow(), 'yyyyMMdd_HHmmss'), '.xlsx')

テンプレートファイルはSharePointの決まったフォルダに置いておきます。Get file content（ファイルコンテンツの取得）でコンテンツを取得してからCreate file（ファイルの作成）で出力先フォルダに複製する流れです。テンプレートを使い回すことで、スクリプトの再設定なしに何度でも実行できます。

動的ファイル名でRun Scriptが動かない問題の回避策

Run Script（スクリプトの実行）アクションでファイルを動的コンテンツで指定すると、スクリプト名やテーブルの選択肢がドロップダウンに表示されなくなります。これはPower Automateのエディターがファイル名を静的に解決できないためです。

回避手順はこうです。まず先にテンプレートファイル（静的なパスで指定）を使ってRun Scriptのパラメーターを設定します。スクリプト名・テーブル名・引数の設定が完了したら、その後でファイルの指定欄を動的コンテンツに差し替えます。設定してから差し替えるという順番を守るだけで解決します。最初から動的コンテンツで指定しようとすると設定が進まないので注意してください。

ChatGPTを活用してスクリプトを作る

TypeScript未経験でもChatGPTとの対話でスクリプトを生成・修正できます。ChatGPTに「Power Automate の Run Script で使用するExcel Scriptを書いてほしい。CSVの文字列を受け取り、データをテーブルとして挿入するスクリプト」と伝えると、そのまま使えるコードを出してくれます。

エラーが出たときはエラーメッセージをそのままChatGPTに貼り付けて修正を依頼します。コードをコピーしてExcelに貼り付けてテスト、エラーが出たら貼り付けて修正依頼、というサイクルを繰り返すだけで実用的なスクリプトが完成します。私が実際にこの方法で組んだとき、コードの中身はほとんど理解していませんでしたが3〜4回のやり取りで動くものができました。

よくあるデータの問題と対処法

カンマを含む住所データで列がずれる

CSV内に「473 Dyer Station, West Virginia」のようなカンマを含むフィールドがあると、単純な分割処理で列がずれます。フィールドをダブルクォートで囲んでいても、スクリプト側でその処理を考慮していない場合は崩れます。

ChatGPTにダブルクォート内のカンマを無視するよう修正してと伝えるだけで、対応したコードに書き直してくれます。住所や名称など文字列フィールドを含むCSVを扱うときは、最初からこの指示を加えておくといいです。

日付がシリアル番号になる

ExcelでCSVの日付を取り込むとデフォルトではシリアル番号（43061など）で保存されることがあります。Run Script（スクリプトの実行）アクションのオプションでDate/Time FormatをISO 8601に変更すると、正しい日付形式に変換できます。フローを組んだ後に日付の列が数字になっているという問題に気づくパターンが多いので、最初からDate/Timeの設定を確認する習慣をつけておくと手戻りが減ります。

SharePointリストへの一括取り込み

Run Script（スクリプトの実行）でCSVをXLSXのテーブルに変換したら、後は通常のExcelデータと同じ扱いです。List rows present in a table（テーブルに存在する行の一覧表示）でExcelの全行を取得し、Apply to each（それぞれに適用）でCreate item（項目の作成）を実行してSharePointリストに一行ずつ書き込みます。

// Apply to each（それぞれに適用）内のCreate item（項目の作成）設定イメージ
// List rows present in a tableのOutputをApply to eachに渡し
// 各フィールドをitems()?['列名']で参照する

Title: items()?['商品名']
数量: items()?['数量']
申請日: items()?['申請日']

一度XLSXテーブルにしてしまえば、通常のExcel連携と完全に同じ操作で扱えます。ExcelをPower Appsのデータソースとして使う方法についてはExcelをPower Appsのデータソースにする記事が参考になります。CSVを生成する側の実装についてはPower AppsでギャラリーのデータをCSVに出力する記事で詳しく扱っています。

Excel Scriptsが広げる可能性

これまでCSVはPower Automateで直接扱えないと答えていた場面が、この方法で扱えるに変わります。スクリプト自体はChatGPTで生成できるため、CSV処理以外にも応用できます。集計・フォーマット変換・テーブル整形など、Excelで手作業でやっていた処理を自動化する方法論として汎用的に使えます。

TypeScriptを書けなくても、エラーメッセージを貼り付けてChatGPTに修正を依頼するサイクルだけで実用的なスクリプトが完成します。今まで諦めていたファイル処理が自動化できるようになると、フロー設計の選択肢が大きく広がります。

まとめ

CSV→XLSX変換の手順は、テンプレートExcelを準備してRun Scriptで変換し、List rows present in a tableで行を取得してSharePointに取り込む流れです。For Selected Itemトリガーの環境制約と、動的ファイル名でRun Scriptのドロップダウンが表示されない問題は最初に押さえておくべきポイントです。

スクリプト開発はChatGPTを使えばTypeScript未経験でも進められます。一度この仕組みを身につけると、CSV処理だけでなくExcel自動化全般に転用できる方法論が手に入ります。楽しみながら、丁寧に組んでいきましょう。

Power Automateのフロー実行履歴の見方とデバッグのコツ。エラーの原因をすばやく特定する

Mon, 16 Mar 2026 15:46:54 GMT

フロー実行履歴を使いこなすと、デバッグの時間が半分になる

Power Automateのデバッグは、実行履歴の読み方を覚えればかなり効率が上がります。エラーが出たとき、なんで動かないんだろうとフローを眺めるだけでは原因はわかりません。実行履歴に答えが全部書いてあります。

最初のころ、私はエラーの原因を探すのに30分以上かけていました。実行履歴の見方を覚えてからは、たいていのエラーは5分以内に特定できるようになりました。この記事で手順を整理します。

実行履歴の場所と開き方

実行履歴はフローの詳細ページに表示されます。Power Automateのマイフロー一覧から確認したいフロー名をクリックすると、フロー詳細ページが開きます。ページ下部に「28日間の実行履歴」というセクションがあり、実行ごとの開始日時・終了日時・ステータスが一覧で確認できます。

ステータスは「成功」「失敗」「キャンセル」の3種類です。「失敗」と表示されている行をクリックすると、その実行の詳細を確認できます。

実行詳細の構成

実行詳細画面を開くと、フローの各アクションが上から順に表示されます。正常に完了したアクションには緑のチェックマーク、失敗したアクションには赤のエラーアイコンが表示されます。どのアクションでエラーが発生したかがひと目でわかります。

エラーアクションの展開と読み方

赤いアイコンのアクションをクリックすると展開されます。展開すると「入力」「出力」「エラー」の3つのセクションが表示されます。

確認すべき3つのセクション

セクション	内容	確認ポイント
入力	そのアクションに渡されたデータ	期待する値が入っているか
出力	そのアクションが返したデータ	次のアクションに渡る値を確認
エラー	エラーコードとメッセージ	原因を読み解く最重要情報

特に「入力」セクションは見落とされがちですが、ここを見るとアクションに何が渡されたかがわかります。式の評価結果が空（null）になっていたり、期待と違う値が入っていたりすることが多いです。

よくあるエラーとその読み方

エラーメッセージはそのまま読むと難解に見えますが、パターンはある程度決まっています。

エラーメッセージ例	原因	対処
The expression is invalid	式の文法エラー	入力セクションで式の評価結果を確認
Resource not found	参照先のリストやファイルが存在しない	サイトURLやリスト名を再確認
Bad request	送信データの形式が不正	入力の型（文字列・数値など）を確認
Unauthorized	接続が切れているか権限不足	接続を再認証する

作成（Compose）を使ったデバッグテクニック

式の評価結果を確認したいとき、作成（Compose）アクションを途中に挿入する方法が便利です。確認したい値を作成（Compose）の入力に入れて実行すると、実行履歴の出力セクションに評価後の値が表示されます。

@{formatDateTime(utcNow(), 'yyyy-MM-dd')}

これを実行すると、実行履歴でこの式が実際に何に評価されたかを確認できます。式が期待どおりに動いているかどうかを確かめるには、この方法が最速です。作成（Compose）の活用については別記事でも詳しく解説しています。

→ Power Automateの作成（Compose）アクション。デバッグと式の整理に使う実践ガイド

再実行機能の活用

実行履歴には「再実行」ボタンがあります。失敗した実行をそのままのデータで再実行できるので、修正後の動作確認に便利です。ただし、メールや通知を送るフローの場合は再実行するとメールが再送されてしまうので注意してください。

実行履歴が表示されない・古い場合

実行履歴は最大28日間保存されます。それより古い実行の履歴は自動で削除されます。もし履歴が空の場合は、フローがそもそもトリガーされていない可能性があります。トリガーの設定を確認するか、インスタントフローの場合は手動で実行して履歴が残るか確認しましょう。

フローが想定通りに動かない場合の詳しいトラブルシューティングは、こちらも参考にしてください。

→ Power Automate入門——変数・データ処理・通知・デバッグの全体マップ

まとめ

Power Automateのデバッグは、実行履歴の「失敗したアクション」を展開して「入力・出力・エラー」を確認するのが基本です。エラーメッセージを読む習慣をつけると、原因特定のスピードが格段に上がります。Composeをデバッグ用に仮挿入する方法も併用すると、式の評価結果を素早く確認できます。

エラーが出たときに慌てず、まず実行履歴を開く。この習慣が身につくと、フロー開発のストレスがかなり減ります。

Power AutomateのDesktopフロー（RPA）とクラウドフローの違い。どちらを使うべき？

Mon, 16 Mar 2026 15:46:46 GMT

Power AutomateにはDesktopフロー（RPA）とクラウドフローの2種類があります。同じ「Power Automate」という名前ですが、仕組みも使いどころもまったく異なります。image

それぞれの仕組みの違い

クラウドフローはMicrosoftのクラウド上で動くフローです。SharePointやTeams、Outlookといったクラウドサービス同士をつなぎ、Web APIを経由してデータをやり取りします。インターネット経由で処理するため、パソコンの電源が入っていなくても自動実行できます。

Desktopフローはパソコン上のアプリケーションをロボットのように操作するRPA（Robotic Process Automation）です。画面上のボタンをクリックしたり、Excelのファイルを開いて値をコピーしたりと、人間が手でやっていることをそのまま自動化します。パソコンが起動していないと動きません。

比較項目	クラウドフロー	Desktopフロー（RPA）
動作場所	Microsoftのクラウド上	手元のパソコン上
PC起動の必要性	不要	必要
操作対象	クラウドサービス（SharePoint, Teams等）	Windowsアプリ、ブラウザ、Excelファイル等
主な用途	承認フロー、通知、データ連携	レガシーシステム操作、画面操作の自動化
必要ライセンス	Microsoft 365に付属（機能制限あり）	Power Automate Desktopは無償だが有人RPA

どちらを選ぶべきか

クラウドフローを選ぶケース

SharePoint・Outlook・TeamsなどのMicrosoft 365サービスを組み合わせた自動化が目的であれば、クラウドフロー一択です。承認フロー、定期レポート配信、フォーム回答の通知といった業務の多くはクラウドフローで対応できます。Microsoft 365のライセンスに含まれている機能で動かせるため、コスト面でも有利です。

Desktopフロー（RPA）を選ぶケース

クラウド連携ができない社内の古いシステム（基幹システム、レガシーなWebアプリ）を操作したいとき、Desktopフローが必要になります。APIが提供されていないシステムでも、画面上の操作を記録して再生することで自動化できます。ただし、画面の構成が変わると動かなくなるリスクがあり、メンテナンスコストが高い点は理解した上で使う必要があります。

個人的な印象では、Microsoft 365が整備されている会社であれば、クラウドフローだけで業務自動化の8割はカバーできます。DesktopフローはどうしてもAPIでつながらないシステムへの最終手段として位置づけるのが現実的です。image

組み合わせて使うケース

クラウドフローとDesktopフローは組み合わせて使うことも可能です。たとえば、SharePointにデータが追加されたことをクラウドフローで検知し、その後Desktopフローを呼び出して社内の基幹システムに入力するという構成が取れます。

ただしこの場合、Desktopフローを動かすパソコンが常時起動している必要があります。実際に会社の共用パソコンをRPA専用機として常時電源を入れて運用しているケースをよく見かけます。管理コストがかかるので、クラウドフローだけで完結できないか先に検討することをおすすめします。

ライセンスの注意点

クラウドフローはMicrosoft 365のライセンスに含まれていますが、プランによって使えるコネクタに制限があります。Desktopフローを有人で動かす（手動実行）分には追加ライセンスは不要ですが、無人で自動実行するには別途有償ライセンスが必要です。RPAの本格導入を検討するなら、ライセンスコストをあらかじめ確認しておくことをおすすめします。

まとめ

クラウドフローとDesktopフローは、それぞれ得意な領域がはっきり分かれています。まずクラウドフローで対応できないかを検討し、どうしても画面操作が必要な場合にDesktopフローを使うというアプローチが、導入・運用コストを抑えるうえで理にかなっています。Power Automateを学ぶ順番としても、まずクラウドフローを習得してからDesktopフローに進むことをおすすめします。

Power AutomateのDo Untilループ。使いどころと無限ループを防ぐ設定方法

Mon, 16 Mar 2026 15:46:46 GMT

Power AutomateのDo Untilループは、条件が満たされるまで処理を繰り返すアクションです。Apply to eachとは違い、件数ではなく状態を基準にループします。使いどころを押さえておくと、待機処理や再試行ロジックをシンプルに書けます。

Do UntilとApply to eachの違い

Power Automateのループ処理には主に2種類あります。

アクション	繰り返しの基準	主な用途
Apply to each	配列の件数分だけ繰り返す	リストの全件処理
Do Until	条件が true になるまで繰り返す	承認待ち、状態チェック、再試行

Do Untilは「あるフラグがオンになるまで待つ」「HTTPリクエストが成功するまで最大3回試す」といった処理に向いています。件数が決まっていない、状態が変わるまで待ちたい——というときはDo Untilの出番です。

設定方法

Do Untilアクションを追加すると、次の3つを設定します。

終了条件：この条件が true になったらループを抜ける
カウント上限：最大何回繰り返すか（デフォルト60回）
タイムアウト：最大でどのくらい実行するか（ISO 8601形式。例：PT1H = 1時間）

カウントとタイムアウトのどちらかに達した時点でも、条件に関わらずループが終了します。無限ループを防ぐために必ず設定しておきましょう。

よく使うパターン

パターン① 承認結果が出るまで待機する

承認アクションの結果をSharePointリストに書き込んでおき、ステータスが「承認済み」または「却下」になるまでDo Untilで待機するという構成です。承認フローを別フローで管理していて、結果の反映タイミングを制御したいときに使います。

ループの中に「アイテムの取得」を置いてステータスを確認し、承認済みか却下になっていればループを抜けるように終了条件を設定します。

パターン② HTTPリクエストの再試行

外部APIを呼び出すとき、ネットワーク状況によって一時的に失敗することがあります。Do Untilで最大3回まで再試行し、成功したらループを抜けるという構成が取れます。

変数（カウンター）をループ内でインクリメントし、成功フラグが立つかカウントが3になったらループ終了という書き方が定番です。

（終了条件）
@or(equals(variables('successFlag'), true), greaterOrEquals(variables('retryCount'), 3))

パターン③ ファイルが存在するまで待つ

別のシステムが特定のSharePointフォルダにファイルを置くまで待機し、ファイルが確認できたら後続処理を進めるというケースでも使えます。ループ内でファイルの存在確認を行い、見つかったらフラグを立てて終了します。

無限ループを防ぐ

Do Untilで最も注意すべきは無限ループです。終了条件の式が間違っていると、カウント上限やタイムアウトに達するまで延々とループし続けます。結果として実行回数を無駄に消費し、フローの課金にも影響します。

対策として必ずやっておきたいのは次の2点です。

カウント上限を適切な値に設定する（再試行なら3〜5回、待機なら処理時間に見合った回数）
タイムアウトを設定して、時間が来たら強制終了させる

ループが意図せず長く続いている場合は、実行履歴でループの繰り返し回数を確認できます。デバッグの方法については実行履歴の見方を参考にしてください。

ループ内のアクションに遅延を入れる

Do Untilで状態チェックを繰り返すとき、処理間隔を空けずにループさせると短時間に大量のAPI呼び出しが発生します。ループ内に「遅延」アクション（Delay）を入れて、1〜5分間隔で確認するようにするのが一般的です。

たとえば承認待ちのフローなら、5分ごとにSharePointのステータスを確認すれば十分です。インターバルなしで回すと、60回の上限にすぐ達してしまいます。

まとめ

Do Untilは「条件が変わるまで待つ」処理を書くための専用ループです。使いどころはApply to eachより少ないですが、承認待ちや再試行ロジックなど、特定の場面では他のアクションでは代替しにくい役割を担います。無限ループへの備えさえ怠らなければ、使い勝手のいいアクションです。

Power Automate でメール添付ファイルをAIで分類してSharePointに自動振り分けする

Sun, 05 Apr 2026 10:18:37 GMT

メールで届いた添付ファイルを手動で確認して保存先を振り分ける作業は、毎日繰り返すと大きな手間になります。Power Automate と AI Builder を組み合わせれば、PDF や画像の内容を AI が自動判定し、SharePoint の適切なフォルダに保存してチームへ通知するまでをフローで自動化できます。

フローの全体設計（5 ステージ）

このフローは次の 5 ステージで構成されます。全体像を先に把握しておくと、後半の各設定が頭に入りやすくなります。

トリガー：新しいメールが届いたとき（添付ファイルあり）
添付取得：Get attachment V2 → 自動生成される ForEach ループ
AI 分類：Run a prompt でファイルの内容を判定
Switch 振り分け：AI の出力結果でフォルダを切り替え
保存 + 通知：SharePoint 保存 → Teams でチームに連絡

トリガーの設定

トリガーは、新しいメールが届いたとき（When a new email arrives V3）、を使います。設定で「添付ファイルを含める：Yes」と「添付ファイルのみ：Yes」を有効にしてください。添付なしのメールでフローが起動するのを防げます。

開発中は、送信者フィルター（From）に自分のメールアドレスを設定するとテストが安全に行えます。テスト用のメールを自分で送るだけでフローが起動するため、本番のメールボックスに影響を与えずに動作確認できます。共有メールボックスに届くメールを処理したい場合も同じトリガーのメールボックスアドレス欄を設定するだけで対応できます。

Get attachment V2 と自動生成される ForEach ループ

添付ファイルの取得（Get attachment V2）アクションを追加して、トリガーの添付ファイル ID を指定します。このとき Power Automate が自動で、それぞれに適用（Apply to each）ループを追加します。初めて見るとなぜループが増えたのかと戸惑いますが、これは正常な動作です。1 件でも複数件でも同じ構造で処理できるようになります。

Apply to each の詳細な仕組みはApply to each 完全攻略記事で解説しています。自動追加されるループを理解しておくと、後続のアクション設定で迷いが減ります。

AI プロンプトでファイルを分類する

ForEach ループ内にプロンプトを実行（Run a prompt）アクションを追加します。取得した添付ファイルをプロンプトのファイル入力に渡し、分類の指示を書きます。

You are a document classifier. Analyze the provided file and classify it as one of: resume, contract, other.
Also provide a brief summary in Japanese (2-3 sentences).
Return a JSON object with keys "category" and "summary".

JSON 出力を指定することが重要です。{"category": "contract", "summary": "..."} という形式で返すよう指示することで、後続の Switch アクションで category を直接参照できます。プロンプトを後から開き直すたびにテストファイルを再アップロードしなければならない仕様があることは把握しておくと開発時に慌てずに済みます。

AI が対応できるファイル形式の制限

Run a prompt アクションが処理できるファイル形式は現時点で PDF・JPEG・PNG・GIF（非アニメーション）に限られます。Word ファイル（.docx）や Excel ファイルはこの方法では処理できません。現実の運用でこれらのファイルが混在する場合は、Switch のその他（other）ケースで未対応ファイルとして別フォルダに保存するか、担当者に確認の通知を送る設計にしておくとよいでしょう。

AI モデルとクレジットの考え方

Run a prompt では複数の AI モデルから選択できます。最上位モデルは精度が高い一方で AI Builder クレジットの消費も大きくなります。要件を満たす最もシンプルなモデルを選ぶがコスト最適化の基本方針です。まず小規模でテストして精度を確認し、必要に応じてモデルをアップグレードする手順が安全です。

Switch 文で振り分け先を制御する

AI の出力 JSON から category を取り出し、Switch（スイッチ）アクションで分岐させます。On には outputs('プロンプトを実行')?['text'] を JSON 解析した上で category を参照します。

作成（Compose）アクションで AI 出力を確認する
JSON の解析アクションで category と summary を個別変数として取り出す
Switch の On に category を指定し、case を “contract” / “resume” / “other” で作る
各 case 内に SharePoint への保存アクションをコピーして配置する

Switch の case は既存のアクションをコピー＆ペーストして量産できます。contract 用のアクションをコピーして resume 用に貼り付け、保存先フォルダだけ変更するという方法が最も速いです。

SharePoint へのファイル保存とメタデータ更新（2 ステップ必須）

SharePoint へのファイル保存とメタデータ（AI 要約など）の書き込みは、別々のアクションで行う必要があります。ファイルの作成（Create file）でファイルを保存した後、ファイルプロパティの更新（Update file properties）で Description 列などに AI 要約を書き込みます。

// ステップ1: ファイルを保存
Create file
  Site Address: [サイト URL]
  Folder Path: /Shared Documents/Contracts
  File Name: @{item()['Name']}
  File Content: @{items('...の添付ファイルの取得')?['contentBytes']}

// ステップ2: メタデータを更新
Update file properties
  Id: 前のステップの ItemId
  Description: @{body('プロンプトを実行')?['summary']}

ファイル作成とメタデータ更新を同時に行うアクションは存在しないため、必ず 2 ステップに分けてください。この点を知らずに 1 アクションでまとめようとして詰まるケースがよくあります。

Teams 通知への添付とリンク埋め込み

各 case の最後に、チャットまたはチャネルでメッセージを投稿（Post a message in a chat or channel）アクションを追加します。Flow Bot として投稿し、SharePoint に保存されたファイルへの直接 URL を本文に埋め込むことで、チームメンバーがワンクリックでファイルをレビューできます。

HTML モードに切り替えてハイパーリンクを設定すると、[ファイル名]を確認するのような表示になりより使いやすくなります。Teams 通知の設定の詳細についてはPower Automate Teams 通知の設定方法を参照してください。

Compose を使ったデバッグの習慣

AI の出力は構造がわかりにくいことがあります。本番フローに組み込む前に必ず作成（Compose）アクションで AI の返り値を確認してください。特に JSON 形式を指示したはずなのに、テキストとして返ってくるケースがあります。信頼するが確認するがフロー開発の鉄則で、特に AI の出力は目視確認を省略しないことをお勧めします。

フローのエラー処理や実行履歴の見方についてはPower Automate デバッグの記事も参考にしてください。AI を含む複雑なフローほど、実行履歴でのステップ別確認が問題特定の近道になります。

まとめ

メール受信 → 添付取得 → AI 分類 → Switch 振り分け → SharePoint 保存 + Teams 通知、の 5 ステージを押さえれば、添付ファイルの自動ルーティングが実現します。旧デザイナーを使うこと、Compose で AI 出力を先に確認すること、SharePoint 保存とメタデータ更新は 2 ステップに分けること、この 3 点が実装で詰まらないためのポイントです。

メール・通知系のアウトプット全体を設計する際はPower Apps / Power Automate アウトプット完全ガイドも参照してください。

Power Automate でHTMLメールに画像を埋め込む｜Base64変換・Office365・SharePoint・OneDrive対応

Sun, 05 Apr 2026 10:18:37 GMT

Power Automate でメール本文に画像を貼り付けたい場合、URL リンクではなく Base64 形式で埋め込む方法が確実です。URL 方式は受信者の環境やセキュリティ設定によってブロックされることがありますが、Base64 埋め込みなら画像データがメール自体に含まれるため、確実に表示されます。Office 365 ユーザー写真・SharePoint ファイル・OneDrive のいずれにも同じパターンで対応できます。

Base64 埋め込みの仕組み

Base64 埋め込みは、HTML の <img> タグの src 属性に画像データを直接書き込む方式です。形式は次のようになります。

<img src="data:image/png;base64,[Base64文字列]" width="100" height="100">

data:image/png;base64, という固定ヘッダーの後に Base64 文字列を続けます。JPEG なら data:image/jpeg;base64,、GIF なら data:image/gif;base64, と画像形式に合わせて変更するだけです。URL が無効になる心配がなく、外部サーバーへのアクセスも不要なため、セキュリティポリシーが厳しい社内環境でも安定して表示できます。

旧デザイナーを使う理由

このフローを作るときは Power Automate の旧デザイナーを使ってください。新デザイナーには HTML コードビュー編集で入力内容が消えるバグがあり、メール本文の HTML を直接編集できません。旧デザイナーへの切り替えはフロー編集画面右上の「旧デザイナーに切り替える」から行えます。

Compose でデータ型を先に確認する

フロー開発の基本は、まず見てから式を書くです。画像取得アクションの直後に作成（Compose）アクションを挟み、出力内容を確認します。Office 365 ユーザー写真や SharePoint ファイルの取得結果は次のようなオブジェクト形式になっています。

{
  "$content-type": "image/jpeg",
  "$content": "/9j/4AAQSkZJRgABAQAAAQABAAD..."
}

この構造を確認してから式を組むことで、なぜ値が取れないのかという無駄なデバッグが減ります。Power Automate のフロー開発全体でこの習慣を持つことが、エラーに強い設計につながります。

base64() 関数でオブジェクトから文字列を取り出す

Power Automate のビルトイン関数 base64(アクション出力) は、上記のオブジェクトから自動的に Base64 文字列を抽出してくれます。もう一つの方法として outputs('アクション名')?['$content'] で $content フィールドを直接取り出すこともできます。

// 方法1: base64() 関数でラップ
base64(outputs('Get_user_photo'))

// 方法2: $content を直接取り出す
outputs('Get_user_photo')?['$content']

どちらも同じ結果になりますが、base64() 関数の方が記述がシンプルで、後から見てもわかりやすいです。

img タグに埋め込む（HTML コードビューの操作）

メールの送信（V2）アクションの Body 欄で、右上のコードビューボタンをクリックして HTML 編集モードに切り替えます。そこに次の形式で img タグを書き込みます。

<img src="data:image/jpeg;base64,@{base64(outputs('Get_user_photo'))}" width="80" height="80">

@{} は Power Automate の動的コンテンツ埋め込み構文です。固定の data:image/jpeg;base64, ヘッダーと Base64 値を連結するだけで、メール本文に動的な画像を埋め込めます。

Office 365 ユーザー写真を埋め込む

ユーザーのプロフィール写真を動的に埋め込む手順は次のとおりです。

ユーザーの写真を取得する（Get user photo）アクションを追加し、User UPN や Email を指定する
作成（Compose）アクションで出力を確認する
base64(outputs('ユーザーの写真を取得する')) で Base64 文字列を取得する
メール本文の HTML コードビューに <img src="data:image/jpeg;base64,@{base64(outputs('ユーザーの写真を取得する'))}" width="50" height="50"> を書き込む

承認メールに承認者の顔写真を表示したり、通知メールに送信者のプロフィール画像を添えたりする場面で使えるパターンです。

SharePoint・OneDrive のファイルを埋め込む

SharePoint や OneDrive に保存された画像ファイルを埋め込む場合は、パスを使用してファイルコンテンツを取得（Get file content using path）アクションで取得します。返ってくるオブジェクト形式はユーザー写真と同じなので、手順は同一です。

<img src="data:image/png;base64,@{base64(outputs('パスを使用してファイル_コンテンツを取得'))}" width="200">

OneDrive や Azure Blob Storage も同じパターンで対応できます。画像ソースが変わってもオブジェクトを base64() でラップして img タグに渡すロジックは共通です。HTML テーブルをメールに送信するパターンについてはPower Automate HTML テーブル送信の記事も参考にしてください。

ファイルサイズと Terminate を使った開発効率化

Outlook が本文に表示できる Base64 サイズには上限があります。大きい画像ファイルで試す前に、必ず小さいファイルで動作確認を先に行ってください。本番で大きいファイルを渡してメールが届かないという事態を防げます。

開発中はフローの途中終了（Terminate）アクションを挟み、ステータスを成功に設定する方法が効果的です。メール送信をスキップして構造確認だけができ、テストのたびにメールボックスにメールが溜まらなくなります。確認が終わったら Terminate を削除して本番に備えます。

添付ファイルとしても送れる

Base64 コンテンツはメール本文への埋め込みだけでなく、添付ファイルとしても送れます。メールアクションの Attachments パラメーターに、名前とコンテンツをオブジェクト形式で渡します。

「本文に埋め込む（視覚的なメール）」と「ファイル添付（保存・転送しやすい形式）」は用途に応じて使い分けてください。組み合わせることも可能で、メール本文に画像を表示しつつ同じ画像をダウンロード用に添付する、という設計もできます。Power Apps からフローを呼び出してこのメールを送信するパターンについてはPower Apps から Outlook でメールを送信する記事と合わせて参照してください。

まとめ

Base64 埋め込みの流れは、画像取得 → Compose で確認 → base64() でラップ → img タグの src に埋め込む、の 4 ステップです。旧デザイナーを使うこと、Compose で出力を先に確認すること、この 2 点を守れば実装で詰まることはほとんどありません。ユーザー写真・SharePoint ファイル・OneDrive のいずれでも同じパターンで対応できるので、一度覚えればどこでも応用できます。

Power Automateのアレイのフィルター処理（Filter Array）。配列を条件で絞り込む方法と式の書き方

Mon, 16 Mar 2026 15:46:49 GMT

Power Automateのアレイのフィルター処理（Filter Array）は、配列の中から条件に合う行だけを抽出するアクションです。Apply to eachでif分岐を書かなくても、配列を一括で絞り込めます。

アレイのフィルター処理（Filter Array）とは

行を条件で絞り込む

SharePointリストから取得した100件のアイテムの中から、ステータスが未完了のものだけを取り出したい。そういうケースで活躍するのがアレイのフィルター処理（Filter Array）です。SQLのWHERE句に近い感覚で使えます。

アレイのフィルター処理（Filter Array）は配列を入力として受け取り、指定した条件に一致する要素だけを含む新しい配列を返します。元の配列の件数が何件あっても、条件に一致しない行はすべて除外されます。Power Automateのデータ加工アクション全体の位置づけはPower Automate入門の全体マップで整理しています。

選択（Select）との使い分け

似た名前の選択（Select）アクションと混同しやすいですが、目的が違います。

アクション	何を変える	出力
アレイのフィルター処理（Filter Array）	行（レコード）	条件を満たす行のみ
選択（Select）	列（プロパティ）	全行、列を変換

アレイのフィルター処理（Filter Array）で行を絞ってから、Selectで列を整形するという流れが現場でよく使うパターンです。

アレイのフィルター処理（Filter Array）の基本設定

アクションの設定項目

アレイのフィルター処理（Filter Array）の設定画面は2つの要素で構成されます。

差出人（From）：フィルタリングしたい配列を指定します。SharePointのアイテムを取得のbody/valueや、別のアクションの出力配列を渡します。

条件（Where）：絞り込みに使う条件を定義します。詳細編集モードとテキストモードの2種類があります。詳細編集モードは左辺・演算子・右辺をドロップダウンで選ぶGUI操作、テキストモードは式を直接書きます。

詳細編集モードで条件を設定する

詳細編集モードでは、左辺に絞り込みに使うプロパティ（動的なコンテンツから選択）、演算子にis equal toなどを選び、右辺に比較する値を入力します。

例えばステータス列が未完了の行を絞り込む場合はこのように設定します。

左辺: item()?['Status']
演算子: is equal to
右辺: 未完了

詳細編集モードは直感的ですが、複数条件を組み合わせるときに制約があります。ANDとORを混在させたい場合はテキストモードのほうが柔軟です。

テキストモードで条件を書く

テキストモードに切り替えると、条件を式として直接書けます。複数条件の組み合わせが自由になります。

// ステータスが未完了の行を取得
@equals(item()?['Status'], '未完了')

// ステータスが未完了かつ担当者が自分の行
@and(
  equals(item()?['Status'], '未完了'),
  equals(item()?['AssignedTo']?['DisplayName'], '守屋祐輔')
)

// ステータスが未完了または期日が今日より前の行
@or(
  equals(item()?['Status'], '未完了'),
  less(item()?['DueDate'], utcNow())
)

テキストモードの式は先頭に@をつけた書き方で評価されます。慣れると詳細編集モードより素早く設定できます。

よく使う絞り込みパターン

文字列の一致で絞り込む

最もよく使うのは文字列の完全一致です。

// カテゴリが営業の行
@equals(item()?['Category'], '営業')

// 特定の人が担当する行
@equals(item()?['AssignedTo']?['DisplayName'], '田中太郎')

日付の比較で絞り込む

期日が今日より前の未対応タスクを抽出するようなケースでは、日付の比較を使います。

// 期日が現在時刻より前の行（期限超過）
@less(item()?['DueDate'], utcNow())

// 期日が今日から7日以内の行
@and(
  greaterOrEquals(item()?['DueDate'], utcNow()),
  less(item()?['DueDate'], addDays(utcNow(), 7))
)

utcNow()はUTC時刻を返すため、日本時間と9時間ずれます。日付比較をする場合は、SharePoint側の日時列がUTCで保存されていることを踏まえた上で設計してください。私が現場で期日アラートを作ったとき、時差を考慮せずに比較してしまい、1日ズレた通知が飛んでしまいました。

数値の比較で絞り込む

// 金額が10万円以上の行
@greaterOrEquals(item()?['Amount'], 100000)

// 優先度が3以上の行
@greaterOrEquals(item()?['Priority'], 3)

アレイのフィルター処理（Filter Array）の結果が空のときの処理

空配列チェックを入れておく

アレイのフィルター処理（Filter Array）の結果が0件になることがあります。その後のアクションで配列の先頭要素を参照するような処理があると、0件のときにエラーになります。

条件分岐アクションを入れて、アレイのフィルター処理（Filter Array）の結果が空かどうかを確認してから後続の処理に進む設計が安全です。

// アレイのフィルター処理（Filter Array）の結果が空かチェックする条件式
empty(body('Filter_array'))

empty()がtrueのときは処理をスキップする分岐を作り、falseのときだけ後続の通知や更新に進むようにします。本番で動かしているフローほど、0件パターンのケアを忘れないようにしてください。

length()で件数を確認する

絞り込んだ結果の件数を取得したいときはlength()を使います。件数を変数に入れておくと、Teams通知のメッセージに差し込めます。

// アレイのフィルター処理（Filter Array）の結果件数
length(body('Filter_array'))

たとえば今日期日のタスクが何件あるかを通知する場合、length()の結果をメッセージに組み込むと実用的な通知になります。

Apply to eachとの使い分け

アレイのフィルター処理（Filter Array）を使えば、Apply to eachの中でif条件を書いてスキップする処理が不要になります。Apply to eachはループのたびにアクションを実行するため、件数が多いと実行時間がかかります。アレイのフィルター処理（Filter Array）で先に絞り込んでからApply to eachに渡せば、処理するループ回数を減らせます。

Apply to eachの中でif分岐を書いて実質的にフィルタリングしている部分があれば、アレイのフィルター処理（Filter Array）に置き換えることを検討してみましょう。Apply to eachとその最適化についてはApply to eachの解説で詳しくまとめています。

まとめ

アレイのフィルター処理（Filter Array）は、配列の行を条件で絞り込むシンプルなアクションです。難しいのは最初の式の書き方だけで、一度覚えれば同じパターンを使いまわせます。

まずは単一条件の完全一致から試してみましょう。慣れてきたらandやorを組み合わせた複数条件に挑戦してみてください。アレイのフィルター処理（Filter Array）で絞った配列をSelectで整形する流れが身につくと、Power Automateのデータ処理がぐっと楽になります。

Power Automateの選択（Select）→HTMLテーブル鉄板パターン。SharePointリストをそのまま表に変換する方法

Mon, 16 Mar 2026 15:46:45 GMT

SharePointリストのデータをそのままメールの表として送りたい。Power Automateを使えばこれが自動化できますが、やり方を知らないとどうやってリストを表にするんだと詰まります。選択（Select）アクションでデータをHTMLテーブル向けに整形し、HTMLテーブル作成アクションで表を生成する、というのが定番の流れです。

流れの全体像

フローの構成はシンプルです。

SharePointの「複数のアイテムの取得」で対象データを取得
選択（Select）アクションで必要な列だけに絞り込み・整形
HTMLテーブルの作成アクションで配列をHTML表に変換
メールの送信アクションでHTMLテーブルを本文に差し込む

選択（Select）アクションはSharePointから取得した配列から必要な列だけを取り出す整形役です。選択（Select）を挟まずにHTMLテーブルに渡すと、SharePointの内部フィールド（_uiVersionStringなど）も全部表示されてしまい、見た目がひどいことになります。

選択（Select）アクションで表の列を定義する

選択（Select）アクションのMapに、HTMLテーブルの列名と値を定義します。左側に列名（自由につけられる）、右側に動的コンテンツから列の値を入れます。

例えば未処理タスク一覧なら、こんな感じになります。

左（列名）	右（値）
タスク名	動的コンテンツ：Title
担当者	動的コンテンツ：担当者 DisplayName
期限	動的コンテンツ：期限日
ステータス	動的コンテンツ：ステータス

選択（Select）の出力は整形済みの配列になります。これをそのままHTMLテーブルに渡します。

HTMLテーブルの作成アクション

HTMLテーブルの作成アクションの設定は実はシンプルです。差し込む値は1か所だけです。

開始：選択（Select）アクションの出力（動的コンテンツ：出力）
列：自動（選択（Select）で整形済みなのでそのまま使える）

列を「自動」にしておくと、選択（Select）で定義した列名がそのままHTMLテーブルのヘッダー行になります。列をカスタムにする必要はほとんどありません。

このアクションの出力はHTMLの<table>タグで囲まれた文字列になります。これをメールの本文にそのまま差し込めば表として表示されます。

メールの本文にHTMLテーブルを差し込む

OutlookやGmailのメール送信アクションで、本文をHTMLモードにしてHTMLテーブルの出力を差し込みます。Outlookの「メールの送信（V2）」アクションなら、本文フィールドの右上のアイコンでHTMLモードに切り替えられます。

本文の例はこうなります。

<p>本日の未処理タスク一覧です。</p>
[HTMLテーブルの作成 - 出力]
<p>よろしくお願いします。</p>

受信側のメールクライアントで表として見やすく表示されます。ただし表のスタイル（罫線・背景色など）はデフォルトでは最低限です。見た目を整えたい場合はHTMLテーブルアクションの出力を変数に受けてから、replaceを使ってstyleタグを差し込む方法もあります。

よくあるつまずきポイント

それぞれに適用（Apply to each）が自動挿入される

HTMLテーブルの作成アクションの差し込み先に配列（選択（Select）の出力）を入れる前に、それぞれに適用（Apply to each）が自動挿入されることがあります。これを防ぐには、差し込みに式で直接 outputs(‘選択’) を指定する方法が有効です。動的コンテンツではなく式モードで入力するとループなしで渡せます。

日本語の日時フォーマットがずれる

SharePointの日付列をそのまま表示すると、UTC時刻で表示されることがあります。日本時間に直すには、選択（Select）のマップで式を使います。

formatDateTime(addHours(item()?['期限日'], 9), 'yyyy/MM/dd')

UTCに9時間を加算してから日本語形式にフォーマットする、という処理です。

選択（Select）アクションの詳細な使い方はこちらで解説しています。

→ Power Automateの選択（Select）アクション——配列から必要な列だけを取り出す整形術

まとめ

SharePointリストをHTMLテーブルにしてメール送信するには、「複数のアイテムの取得」→選択（Select）→HTMLテーブルの作成→メール送信、の4ステップが定番の構成です。選択（Select）で列を整形しておくことで、HTMLテーブルの列名まで自由に設定できます。

定時レポートや承認依頼一覧など、一覧を表形式でメール通知したいという場面で幅広く使えます。一度作ってしまえばあとは全自動なので、ぜひ試してみてください。

Power AutomateでHTTPリクエストを使って外部APIと連携する方法

Mon, 16 Mar 2026 15:46:53 GMT

Power AutomateのHTTPアクションを使うと、Microsoft以外のサービスともデータをやり取りできます。コネクタが用意されていない外部サービスへの連携や、社内システムのAPIを叩く場面で活躍します。

HTTPアクションとは

HTTPアクションは、任意のURLに対してHTTPリクエストを送るアクションです。GET・POST・PUT・DELETEなどのメソッドを選び、URLとヘッダー、必要であればリクエストボディを設定するだけで使えます。簡単にいえば、ブラウザのかわりにPower Automateがページを取りに行ったり、フォームを送信したりするような動作です。

Microsoft 365のサービスはすでに専用コネクタがあるため、通常はHTTPアクションを使う必要はありません。HTTPアクションが必要になるのは、専用コネクタが存在しない社内の基幹システムや、外部のWeb APIと連携したいときです。

基本的な設定項目

設定項目	内容	例
メソッド	リクエストの種類	GET（取得）、POST（送信）、PUT（更新）
URI	リクエスト先のURL	https://api.example.com/items
ヘッダー	認証情報やコンテンツタイプ	Authorization: Bearer トークン
本文	POSTやPUT時に送るデータ	JSON形式のデータ
認証	APIの認証方式	なし、基本認証、Active Directory OAuth等

設定の中で最も重要なのがヘッダーと認証の部分です。多くのAPIはAPIキーやBearerトークンを要求するため、APIのドキュメントを確認して正しい形式で設定する必要があります。

レスポンスを使うにはParse JSONとセット

HTTPアクションが返すレスポンス本文はJSON文字列です。そのままでは後続のアクションで個別の値を取り出せないため、JSON の解析（Parse JSON）アクションと組み合わせて使います。HTTPのレスポンス本文をJSON の解析（Parse JSON）に渡し、スキーマを定義することで、各フィールドが動的コンテンツとして使えるようになります。

JSON の解析（Parse JSON）の記事で詳しく解説しています。

実務でよく使うパターン

パターン① 社内APIとの連携

社内の基幹システムがREST APIを提供している場合、HTTPアクションで呼び出せます。たとえば、SharePointに入力されたデータを基幹システムのAPIを通じて登録するフローが作れます。認証方式は社内のIT部門に確認しておくと確実です。

パターン② チャットボットやAI APIとの連携

OpenAI APIやGoogle APIなど、Microsoftのコネクタが存在しない外部AIサービスを呼び出すときにHTTPアクションを使います。個人的には、社内の問い合わせ対応フローにChatGPT APIを組み込むときに初めてHTTPアクションを使いました。動いたときは感動しました。

パターン③ Webhookでの外部サービス通知

Slack、Chatwork、LINE Works など、Microsoft Teams以外のチャットツールに通知を送りたいときも使えます。各サービスのWebhook URLにHTTP POSTでメッセージを送信する形です。

エラーへの備え

HTTPアクションは外部のサービスに依存するため、ネットワーク障害やAPIの一時停止によってエラーになることがあります。重要なフローであれば、エラー発生時の通知や再試行ロジックをあわせて実装しておくことをおすすめします。

再試行ロジックはDo Untilアクションと組み合わせることで実装できます（Do Untilの記事参照）。エラーハンドリング全般についてはScopeとRunAfterの記事も参考にしてください。

ライセンスの注意

HTTPアクションはPower Automateの「プレミアムコネクタ」に分類されます。Microsoft 365の標準ライセンスには含まれていないため、使用するにはPower Automateのプレミアムライセンスが必要です。利用前にライセンス状況を確認しておきましょう。社内でライセンス管理者に相談するのが確実です。

まとめ

HTTPアクションはPower Automateの中でも応用度の高いアクションですが、使えるようになると連携できるサービスの幅が一気に広がります。専用コネクタがない外部サービスへのアクセスが必要になったとき、まずHTTPアクションで実現できないか検討してみてください。APIドキュメントを読むのに最初は戸惑いますが、一度動かせると次から応用できます。

Power Automate入門——変数・データ処理・通知・デバッグの全体マップ

Mon, 16 Mar 2026 15:46:51 GMT

Power Automateは、繰り返しの手作業をフローとして自動化するツールです。メール通知・データ転記・承認フローといった業務のルーティンをそのまま自動化できます。この記事では、Power Automateで何ができるのか、どの順番で覚えればいいのかを整理します。

Power Automateでできること

Power Automateのしくみは単純です。何かが起きたら（トリガー）、何かをする（アクション）——この2ステップの組み合わせがフローの基本形です。

私が物流現場で最初に作ったフローは、SharePointリストに新しい行が追加されたらTeamsに通知するというものでした。それだけで、毎朝担当者が手動でスプレッドシートを確認していた作業がなくなりました。地味に見えますが、毎日10分が消える作業がなくなるのは積み重ねで効いてきます。

トリガーとアクション

トリガーはフローの起点です。よく使うものは以下の3種類です。

種類	内容	例
自動化	外部のイベントで起動	メール受信、SharePointへのデータ追加
インスタント	手動で起動	ボタンを押して実行、Power Appsから呼び出し
スケジュール	決まった時刻に起動	毎朝9時に集計、毎週月曜に送信

3種類の違いと使い分けはPower Automateのトリガー解説にまとめています。迷ったときはまずここを確認してください。

クラウドフローとデスクトップフロー

Power Automateにはクラウドフロー（オンライン上で動く）とデスクトップフロー（PC操作を自動化するRPA）の2種類があります。SharePointやOutlookといったMicrosoft 365のサービスと連携するならクラウドフロー一択です。この記事ではクラウドフローを前提に話を進めます。

学習の全体マップ

Power Automateは学ぶ順番を間違えると遠回りになります。個人的には、以下の順番で進めるのが一番詰まりにくいと感じています。

ステップ	テーマ	重要度
①基礎	トリガーの種類と選び方	★★★
②基礎	変数の使い方（初期化・セット・追加）	★★★
③基礎	Apply to eachでループ処理	★★★
④デバッグ	Composeとフロー実行履歴の見方	★★★
⑤データ加工	SelectとFilter arrayで配列を絞り込む	★★☆
⑥通知・出力	Teamsへの通知、HTMLテーブル作成	★★☆
⑦応用	Parse JSON、HTTPリクエスト、子フロー	★☆☆

①〜④を押さえれば、現場で使える自動化フローのほとんどは作れます。⑤以降は必要になったタイミングで習得すれば十分です。

① トリガーと変数——フローの土台

変数は最初に覚える

フローの中でデータを一時的に保存したり、ループの中で値を積み上げていくのが変数の役割です。Power Automateの変数は使う前に必ず初期化（Initialize variable）が必要で、これを知らないとエラーで詰まります。初期化・セット・追加の3パターンはPower Automateの変数の使い方で解説しています。

Apply to eachの扱い

SharePointリストからデータを取得すると、結果は配列（複数件のデータのまとまり）で返ってきます。その配列を1件ずつ処理するのがApply to eachです。Power Automateを使い始めると必ずぶつかるアクションなので早めに理解しておくことをおすすめします。動作が遅いときの改善策も含めApply to each完全攻略でまとめています。

② デバッグ——フローが動かないときの対処

作成（Compose）とフロー実行履歴

フローを作っていると、思った通りに動かない場面は必ず来ます。そのときに使うのが作成（Compose）アクションとフロー実行履歴です。作成（Compose）は変数や式の中身を確認するためのデバッグ用途に使えます。実行履歴では各アクションの入出力を確認でき、どのステップで問題が起きているかを素早く特定できます。作成（Compose）の活用術とデバッグの手順については別記事で解説する予定です。

③ データ加工——選択（Select）とアレイのフィルター処理（Filter Array）

配列から必要な列だけを取り出す作成（Compose）アクション、条件に合う行だけを絞り込むアレイのフィルター処理（Filter Array）アクション——この2つのアクションを組み合わせると、データ加工の幅が大きく広がります。SharePointリストを整形してTeamsに通知したり、HTMLテーブルに変換してメールで送ったりという実用的なフローが作れるようになります。こちらも別記事でそれぞれ詳しく解説する予定です。

④ 通知・出力——Teamsへの送信

Power Automateを業務で使う場面の多くは、何かが起きたらTeamsやメールで通知するというパターンです。単純なテキスト通知だけでなく、HTMLテーブルを使って表形式のレポートを送ることもできます。Teams通知の設定方法と実用シーンについては別記事で解説する予定です。

Power Appsとの連携

Power AppsのボタンからPower Automateのフローを呼び出すことができます。アプリ単体では難しいメール送信・PDF生成・外部API連携といった処理をフローに任せる使い方が一般的です。AppsとAutomateを組み合わせると、できることの幅が一気に広がります。Power Platform全体での業務改善のイメージはPower Platformで始めるシンプルな業務改善にまとめているので参照してください。

まとめ

Power Automateは、トリガー・変数・Apply to each・デバッグの4つを押さえれば実用レベルのフローが作れます。最初から全部覚えようとせず、まず1本フローを動かしてみることが大切です。

動かせたフローが1本あると、次に作るときの感覚が全然違います。小さくていいので、自分の現場の繰り返し作業を1つ選んで自動化してみましょう。

Power Automateの結合（Join）アクション。複数の値を1本の文字列にまとめる方法

Mon, 16 Mar 2026 15:46:45 GMT

Power Automateの結合（Join）アクションは、配列の中身をひとつの文字列に結合するだけのシンプルなアクションです。それだけでも、使いこなすと通知メッセージやメール本文の組み立てが一気に楽になります。

結合（Join）アクションとは

結合（Join）アクションは、配列（複数の値をまとめたもの）を指定した区切り文字でつなぎ合わせて、ひとつの文字列として出力するアクションです。設定項目は「配列（From）」と「区切り文字（Join with）」の2つだけで、非常にシンプルです。

たとえば、配列の中に「田中さん」「鈴木さん」「山本さん」という3つの名前が入っていたとします。結合（Join）の区切り文字に「・」を指定すると、出力は「田中さん・鈴木さん・山本さん」という1本の文字列になります。Teamsへの通知文やメールの件名に、こういった文字列をそのまま使いたいことはよくあります。

選択（Select）と組み合わせるのが王道

実務で結合（Join）を使うとき、ほとんどのケースで選択（Select）アクションとセットになります。SharePointリストや配列から特定の列だけを取り出すのが選択（Select）の役割で、そこに結合（Join）をつなぐことで「特定フィールドの値を区切り文字でまとめる」という処理が完成します。

たとえば、SharePointリストの申請者名だけを取り出して、承認通知メールに一覧表示したいケースを考えます。処理の流れはこうなります。

SharePointのアイテムを取得（リストの行を取得など）
Selectアクションで申請者名の列だけを抽出（配列を整形）
結合（Join）アクションで「、」区切りの文字列に変換
メール本文やTeams通知に組み込む

区切り文字の選び方

区切り文字は自由に設定できます。用途によって使い分けると読みやすくなります。

用途	おすすめの区切り文字	出力例
日本語の列挙	、（読点）	田中さん、鈴木さん、山本さん
英語・コード系	,（カンマ）またはパイプ記号	tanaka,suzuki,yamamoto
メール本文の改行列挙	\n（改行コード）	各項目が1行ずつになる
箇条書き風	・（中黒）	田中さん・鈴木さん・山本さん

個人的によく使うのは「、」と改行コードです。Teamsメッセージなら読点でつないでも見やすいですし、メール本文に縦並びで出したいときは改行コードを使います。改行コードは\nを入力するか、数式バーで decodeUriComponent('%0A') などで生成することもあります。

結合（Join）アクションが使えないケース

結合（Join）が機能するのはあくまで「フラットな配列（文字列や数値の1次元配列）」に対してです。SharePointの複数の項目の取得（Get items）で取得した「テーブル形式の配列」をそのまま結合（Join）に渡しても、意図した結果にはなりません。その場合は選択（Select）で整形してから結合（Join）を使う必要があります。

また、配列が空のとき（アイテムが0件のとき）は、結合（Join）の出力も空文字列になります。後続の処理でその文字列を使う場合は、empty()関数で空チェックをしておくと安全です。これを怠ると、通知メッセージに何も出力されないまま送信されてしまうことがあります。

実務でよく使う組み合わせパターン

パターン① 承認依頼の一覧をTeamsに通知

SharePointから未対応の申請を取得 → 選択（Select）で申請者名を抽出 → 結合（Join）で「、」区切りに変換 → Teamsに送信。社内の承認フロー自動化でこの形はほぼ定番です。10件の申請者名を1行にまとめてメンションできるので、受け取る側も把握しやすいです。

パターン② 週次レポートのタスク一覧を整形

その週に完了したタスク名をSharePointから取得 → 結合（Join）で改行区切りに変換 → メール本文に差し込む。個人的には毎週月曜朝にこの形で週報を自動生成して、メールで自分宛てに送るフローを運用しています。手書きよりずっと楽です。

まとめ

結合（Join）アクション自体はシンプルですが、選択（Select）とセットで使うことで配列操作の幅が大きく広がります。複数の値を文字列にまとめる処理が必要になったとき、まず選択（Select）で整形して結合（Join）で結合するというパターンを頭に入れておくと迷わずに済みます。Power Automateの地道なパーツの組み合わせが、業務の自動化を支えています。

Power Automateでそれぞれに適用（Apply to each）が突然出てくる理由

Mon, 16 Mar 2026 15:46:53 GMT

Power Automateを使っていると何もしていないのにそれぞれに適用（Apply to each）が自動で追加されたという経験をした人は多いはずです。これはバグではなく、データが配列（Array）形式だったことへの自動対応です。この仕組みを理解しておくと、余計なループが出てきても慌てずに対処できます。

オブジェクトと配列の違い

Power Automateが扱うデータには主に2種類の形式があります。

種類	形式	例
Object（オブジェクト）	キーと値のペア（1件のデータ）	{ “名前”: “山田”, “部署”: “営業” }
Array（配列）	オブジェクトが複数並んだリスト	[ {“名前”: “山田”}, {“名前”: “田中”} ]

SharePointの「複数のアイテムの取得」アクションの結果は配列です。配列形式のデータから特定の値を取り出そうとすると、Power Automateは「これは複数件ある、1件ずつ処理が必要だ」と判断してそれぞれに適用（Apply to each）を自動挿入します。

オブジェクトのプロパティを参照するとき

1件だけのオブジェクトなら、それぞれに適用（Apply to each）なしでプロパティを直接参照できます。例えばSharePointの「アイテムの取得」（単数形）アクションの結果はオブジェクトなので、そのまま body/Title のように参照できます。

配列からそれぞれに適用（Apply to each）が生まれる理由

配列のデータに対してプロパティを参照しようとすると、Power Automateは「どの要素のプロパティを見ればいいかわからない」ので、1件ずつ処理するためにそれぞれに適用（Apply to each）を挿入します。これが「Apply to eachが突然出てくる」現象の正体です。

それぞれに適用（Apply to each）を避けたいとき

ループを使わずに配列から値を取り出したいケースもあります。配列の先頭1件だけが欲しいときなどがその例です。

first()で先頭の1件だけ取る

first()関数を使うと、配列の先頭要素だけをオブジェクトとして取り出せます。それぞれに適用（Apply to each）が不要になります。

first(outputs('アイテムの取得_複数')?['body/value'])

アレイのフィルター処理（Filter array）で先に絞り込む

配列から条件に合う1件だけを取り出したい場合は、アレイのフィルター処理（Filter array）アクションで絞り込んでからfirst()を使う方法が定番です。

アレイのフィルター処理（Filter array）で条件に合うアイテムだけに絞り込む
first()で先頭1件をオブジェクトとして取り出す
以降はオブジェクトのプロパティを直接参照できる

アレイのフィルター処理（Filter array）の使い方は別記事で詳しく説明しています。

→ Power Automateのアレイのフィルター処理（Filter array）——配列を条件で絞り込む方法と式の書き方

JSON の解析（Parse JSON）で配列の構造を明示する

HTTPアクションや外部APIの戻り値がJSONのとき、Power Automateはそれが配列なのかオブジェクトなのかわかりません。このままプロパティを参照しようとするとそれぞれに適用（Apply to each）が挿入されることがあります。

JSON の解析（Parse JSON）アクションを使ってスキーマを定義しておくと、Power Automateがデータの型を理解でき、不要なそれぞれに適用（Apply to each）の挿入を防げます。また、スキーマ定義後はプロパティが動的コンテンツとして補完されるようになり、式を手書きする必要がなくなります。

スキーマの自動生成

JSON の解析（Parse JSON）のスキーマは「サンプルのペイロードを使用してスキーマを生成する」ボタンを使うと自動生成できます。実際のAPIレスポンスや、フロー実行履歴からコピーしたJSONを貼り付けるだけでスキーマが作れます。手書きする必要はありません。

まとめ：Apply to eachが出たら「配列かどうか」を確認する

それぞれに適用（Apply to each）が自動挿入されたときのチェックポイントはシンプルです。

そのデータは配列か？（複数件の可能性があるか）
1件だけ欲しいならfirst()で取り出せないか
先に条件で絞り込めないか（Filter array）
JSONの型が不明ならJSON の解析（Parse JSON）でスキーマを定義する

このチェックリストを頭に入れておくだけで、それぞれに適用（Apply to each）に振り回されることが減ります。Power Automateのフローが複雑に見えてくるのは型の扱いが原因であることが多いので、オブジェクトと配列の違いを理解しておくことが全体の理解につながります。

→ Power AutomateのComposeアクション——デバッグと式の整理に使う実践ガイド

Power AutomateでJSON の解析（Parse JSON）を使ってデータを取り出す方法

Mon, 16 Mar 2026 15:46:53 GMT

Power AutomateのJSON の解析（Parse JSON）アクションは、API連携や複雑なデータ処理で必ず登場する重要なアクションです。仕組みさえ理解すれば、動的コンテンツとして各項目を取り出せるようになります。

JSON の解析（Parse JSON）とは何をするアクションか

JSON の解析（Parse JSON）は、JSON形式のテキストを解析して、その中に含まれる各項目を後続のアクションで使えるよう、動的コンテンツとして取り出すためのアクションです。JSON の解析（Parse JSON）を使わないと、JSONテキスト全体がひとまとまりの文字列として扱われてしまい、個別の項目を取り出すのが難しくなります。

簡単にいえば、包まれた箱（JSON文字列）を開けて中身を取り出すためのアクション——というイメージです。HTTPアクションで外部APIと連携したとき、作成（Compose）アクションで中間データを整形したとき、または変数に格納したJSON文字列を使いたいときに登場します。

スキーマが鍵

JSON の解析（Parse JSON）を使うには「スキーマ」を定義する必要があります。スキーマとは、JSONの構造（どんなキーがあって、型は何か）を記述したものです。これを設定しないとどの項目を取り出せばいいかをPower Automateが判断できません。

スキーマは手書きする必要はなく、サンプルのJSONをそのまま貼り付けることで自動生成できます。

スキーマの自動生成手順

まずフローを一度実行し、処理対象のJSONデータを確認する（実行履歴から確認できます）
JSON の解析（Parse JSON）アクションを追加し、「スキーマ」欄の下にある「サンプルのペイロードを使用してスキーマを生成する」をクリック
実行履歴からコピーしたJSONを貼り付け、「完了」を押す
スキーマが自動入力されるので、そのまま保存する

実行履歴の確認方法はフロー詳細ページの「28日間の実行履歴」から任意の実行を開き、該当アクションのアウトプットを見ます。詳しいデバッグ方法はフロー実行履歴の見方とデバッグのコツでも解説しています。

型の不一致に注意

スキーマを自動生成した場合、サンプルとして使ったデータの型がそのまま記録されます。ここで注意が必要なのは、実際のデータの型とスキーマで定義した型が一致しないとエラーになるケースがあることです。

よくあるのが「数値か文字列かが状況によって変わる」パターンです。たとえば数量の値が、データによって整数（integer）だったり文字列（string）だったりする場合、どちらか一方の型に固定したスキーマを使うとエラーになります。こういったときはスキーマの該当箇所を手動で修正し、型を "type": ["integer", "string"] のように配列で指定すると対応できます。

JSON の解析（Parse JSON）を使う代表的なシーン

HTTPアクションでAPIを叩いた後

外部のREST APIを呼び出すとき、レスポンスはほぼ必ずJSON形式です。HTTPアクションの出力本文をJSON の解析（Parse JSON）に渡して解析することで、必要な項目だけを取り出してその後の処理に使えます。

作成（Compose）で組み立てた中間データを分解するとき

複数のアクションの出力を作成（Compose）でひとつのJSONオブジェクトに組み立てておき、後の処理で必要な部分だけJSON の解析（Parse JSON）で取り出すという使い方もあります。作成（Compose）アクションの実践ガイドと合わせて使うと、フローの可読性が上がります。

Power AppsからPower Automateにデータを渡したとき

Power AppsからPower Automateを呼び出す際、データをJSON文字列で渡すことがあります。受け取った側でJSON の解析（Parse JSON）を使うことで、Power Appsから送られた各パラメータを個別に扱えます。

JSON の解析（Parse JSON）が不要なケース

SharePointの「アイテムの取得」やFormsの「応答の詳細を取得する」などのコネクタアクションは、最初から各フィールドが動的コンテンツとして使えるよう整形されています。これらはJSON の解析（Parse JSON）を使わなくても構いません。JSON の解析（Parse JSON）が必要なのは主に、整形されていない生のJSON文字列を扱うときだけです。

また、それぞれに適用（Apply to each）が突然出てくる記事でも触れましたが、JSON の解析（Parse JSON）で配列を含むJSONを解析するとき、その配列に後続のアクションでアクセスしようとするとApply to eachが自動的に挟まることがあります。これは仕様なので、予期せず出てきても慌てなくて大丈夫です。

まとめ

JSON の解析（Parse JSON）はAPIやHTTPレスポンスを扱うフローでは避けて通れないアクションです。スキーマを手書きするのは難しそうに見えますが、サンプルから自動生成する機能があるので実際のハードルは高くありません。型の不一致だけ気をつけておけば、あとはそこまで難しいアクションではありません。外部連携が必要になったとき、ぜひ試してみてください。

Power Automateのエラーハンドリングはスコープ（Scope）＋実行条件で解決

Mon, 16 Mar 2026 15:46:52 GMT

Power Automateのエラーハンドリングは、スコープ（Scope）アクションと実行条件を組み合わせることで実現できます。エラーが出たときに何もせず止まるフローより、原因をキャッチして通知まで飛ばせるフローのほうが実運用ではずっと使いやすいです。

スコープ（Scope）アクションとは

Scopeアクション（スコープ）は、複数のアクションをひとつのグループにまとめるコンテナです。フォルダのようなものです。グループ内のいずれかのアクションが失敗すると、スコープ（Scope）自体も失敗扱いになります。この仕組みを使うと、このスコープが失敗したら別の処理を動かすという条件分岐が書けます。

スコープを使わずに個々のアクションに実行条件を設定することもできますが、アクションが増えると管理が煩雑になります。スコープでグループ化してからエラー時の処理を設定するほうが、フロー全体が見やすくなります。

RunAfter（実行条件）の設定

Power Automateの各アクションには実行条件（RunAfter）を設定できます。デフォルトは成功した場合に実行ですが、これを変更することでエラーハンドリングが可能になります。

実行条件	動作
成功した場合	前のアクションが成功したときだけ実行（デフォルト）
失敗した場合	前のアクションが失敗したときだけ実行
スキップされた場合	前のアクションがスキップされたときに実行
タイムアウトした場合	前のアクションがタイムアウトしたときに実行

複数の条件を同時に選択することもできます。たとえば「失敗した場合」と「タイムアウトした場合」の両方にチェックを入れると、どちらの状態でも次のアクションが実行されます。

基本的なエラーハンドリングの構成

実務でよく使う構成を紹介します。

メイン処理をスコープでまとめる（スコープ: メイン処理）
エラー時の処理をスコープでまとめる（スコープ: エラー処理）
エラー処理スコープの実行条件を「失敗した場合」に設定する
エラー処理スコープ内にTeams通知やメール送信アクションを入れる

この構成だと、メイン処理のスコープが失敗したときだけエラー処理が走ります。Teams通知の本文にエラーメッセージを含めることで、何が原因で失敗したかをその場で把握できます。

エラーメッセージの取り出し方

エラー処理のスコープ内でエラーの詳細を取得するには、以下の式を使います。

result('スコープ名')

この式でスコープの実行結果（エラーコードやメッセージを含むオブジェクト）が取得できます。作成（Compose）アクションと組み合わせて内容を確認してから、通知文に組み込むと使いやすいです。

よくあるパターン：エラー時に管理者へTeams通知

個人的には、本番運用しているフローには必ずこのパターンを入れるようにしています。フローが失敗しても気づかずに放置してしまうリスクを防げます。

構成はシンプルで、メイン処理のスコープ失敗時にTeamsのアダプティブカードを管理者チャネルに投稿するだけです。本文にはフロー名・実行日時・エラーメッセージを入れておくと、原因特定がかなり速くなります。実行履歴の見方についてはデバッグのコツも合わせて参考にしてください。

スコープを使うときの注意点

スコープのネストに注意

スコープ内にスコープを入れることもできますが、深くなると可読性が下がります。2階層までを目安にすることをおすすめします。

スキップ状態の伝播

条件分岐でスキップされたアクションが含まれるスコープは、スコープ全体もスキップ扱いになることがあります。RunAfterの条件にスキップも含める必要があるケースがあるので注意してください。

変数はスコープの外で初期化する

変数の初期化はスコープの外に置く必要があります。スコープ内に入れるとエラーになります。これは初心者がよく詰まる点なので、変数を使う場合はフローの冒頭で初期化してからスコープを作るようにしましょう。詳しい変数の使い方は変数命名規則の記事でも触れています。

まとめ

スコープ＋実行条件の組み合わせは、Power Automateのエラーハンドリングにおける基本中の基本です。最初は少し難しく感じますが、一度構成を作ってしまえばコピーして使い回せます。本番フローにはエラー時の通知を必ず入れる習慣をつけると、運用の安心感が大きく変わります。

Power Automateの選択（Select）アクション。配列から必要な列だけを取り出す整形術

Mon, 16 Mar 2026 15:46:51 GMT

Power Automateの選択（Select）アクションは、配列の中から必要な列だけを取り出して整形するためのアクションです。Apply to eachを使わずに配列を変換できるので、フローをシンプルに保てます。

選択（Select）アクションとは

配列の列を絞り込むアクション

SharePointリストから取得したアイテムやHTTPリクエストで受け取ったJSONには、不要な列が大量に含まれていることがよくあります。そのままTeamsに通知したり別のシステムに送ったりすると、必要な情報が埋もれて見づらくなります。

選択（Select）アクションは、配列の各要素から必要なプロパティだけを取り出し、新しい配列に整形します。Excelの列選択に近い感覚で使えます。データ加工アクションの一覧はPower Automate入門の全体マップで整理しています。

Filter arrayとの違い

似た名前のアクションにFilter arrayがありますが、役割は明確に異なります。

アクション	目的	結果
選択（Select）	列（プロパティ）を絞り込む	全行を残して列だけ変換
アレイのフィルター処理（Filter Array）	行（レコード）を絞り込む	条件に合う行だけ残す

選択（Select）は行数を変えず列を変換する、アレイのフィルター処理（Filter Array）は列を変えず行を絞り込む。この使い分けを最初に押さえておくと、組み合わせて使うときに迷いません。

選択（Select）アクションの基本的な使い方

アクションの追加と設定

フローに選択（Select）アクションを追加するときは、データ操作カテゴリから選びます。設定項目は2つだけです。

差出人（From）：変換したい配列を入力します。SharePointのアイテムを取得した後なら、動的なコンテンツからbodyやvalueを渡します。

マップ（Map）：出力したいプロパティを定義します。左側がキー名（出力後の列名）、右側が値（元の配列から取り出す式）です。

具体的な設定例

SharePointのタスク管理リストからタイトル・担当者・期日だけを取り出すケースで考えます。SharePointのアイテムを取得アクションで配列を取得した後、選択（Select）アクションをつなぎます。

差出人には SharePointのアイテムを取得のbody/valueを指定します。マップには以下のように設定します。

キー: タイトル    値: item()?['Title']
キー: 担当者名    値: item()?['AssignedTo']?['DisplayName']
キー: 期日        値: item()?['DueDate']

これで出力される配列は、タイトル・担当者名・期日の3列だけを持つシンプルな配列になります。元のSharePointアイテムにあったIDやバージョン情報、各種システム列はすべて除去されます。

キー名の自由な定義

マップのキー側は、出力したい列名を自由に決められます。元のプロパティ名が英語でも、日本語で出力するように変換できます。

キー: title      値: item()?['Title']
キー: 担当者      値: item()?['AssignedTo']?['DisplayName']
キー: dueDate    値: item()?['DueDate']

Teams通知用にメッセージを整形したり、別サービスのAPIが求めるフォーマットに合わせたりするときに便利です。私が現場で使う場面では、SharePointの内部列名（英語）を人が読みやすい日本語名に変換してから通知メッセージに差し込むことが多いです。

Apply to eachとの使い分け

選択（Select）のほうが処理が速い

配列の各要素から特定のプロパティを取り出したいだけなら、Apply to eachは使わないほうがいいです。Apply to eachはループ処理なので、要素が多いと実行時間が伸びます。選択（Select）アクションは内部でバッチ処理をするため、同じ処理をApply to eachで書くより速く完了します。

Apply to eachが必要なのは、各要素に対して追加のアクション（メール送信・SharePoint更新など）を実行するケースです。単に列の形を変えるだけなら選択（Select）に切り替えましょう。Apply to eachの詳細な使い方と注意点はApply to eachの解説でまとめています。

式で計算した値をマップに使う

マップの値側には式を書けます。単純なプロパティの取り出しだけでなく、フォーマット変換や文字列加工も一括でできます。

// 日付を日本語形式にフォーマット
キー: 期日表示    値: formatDateTime(item()?['DueDate'], 'yyyy年MM月dd日')

// 文字列の先頭に接頭辞をつける
キー: タスク名    値: concat('[未完了] ', item()?['Title'])

ちょっとした加工なら選択（Select）のマップ内で完結させられるので、後続のApply to eachやComposeアクションを減らせます。

選択（Select）の出力をアレイのフィルター処理（Filter Array）や通知につなぐ

配列を整形してから絞り込む

選択（Select）とアレイのフィルター処理（Filter Array）を組み合わせる場合、先に選択（Select）で列を絞ってからアレイのフィルター処理（Filter Array）に渡すのがおすすめです。アレイのフィルター処理（Filter Array）の条件式で参照するプロパティが整理されていると、式を書くときに迷いません。

逆にアレイのフィルター処理（Filter Array）を先に使って行を絞り込んでから、選択（Select）で列を整形する順序でも問題ありません。処理するデータ量を先に減らしたいならアレイのフィルター処理（Filter Array）を先に実行するほうが効率的です。アレイのフィルター処理（Filter Array）の使い方はアレイのフィルター処理（Filter Array）で条件絞り込みの記事でまとめます。

Teams通知への差し込み

選択（Select）で整形した配列をjoin関数でつなぐと、通知メッセージとして成形しやすくなります。

// アレイのフィルター処理（Filter Array）の出力をjoinで1行ずつ改行しながら連結
join(body('選択'), '
')

これだけでは各行がJSON文字列になってしまいますが、マップ側で表示したい文字列をconcatで組み立てておくと、join後にそのまま通知文として使えます。

よくある失敗パターン

item()の書き方を間違える

マップの値側でよく見るミスは、item()の書き方を間違えることです。テキストモードでは item()?[‘列名’] と書きます。?（オプション演算子）を省くと、プロパティが存在しない場合にフローがエラーで止まります。

特にPerson型やLookup型のような複合プロパティを参照するときは、ネストを正確に書く必要があります。

// Person型の表示名を取り出す
item()?['AssignedTo']?['DisplayName']

// Lookup型の値を取り出す
item()?['Category']?['Value']

差出人に配列でないものを渡す

差出人には配列を渡さないとエラーになります。SharePointのアイテムを取得のbodyをそのまま渡すと、配列ではなくオブジェクトが渡されてしまうことがあります。正しくはbody(‘アクション名’)?[‘value’] のvalueプロパティを指定します。

実行テストでエラーが出たときは、差出人に何が入っているか作成（Compose）アクションで確認するのが早いです。

まとめ

選択（Select）アクションは地味ですが、フローの後半で使うデータを整理しておくという意味では非常に実用的なアクションです。Apply to eachで無理に処理しようとしている部分をSelectに置き換えるだけで、フローがスリムになることがあります。

まずはSharePointから取得した配列を選択（Select）で列絞り込みしてみましょう。出力がシンプルになるほど、後続のアクションの式が短く書けます。Power Automateで扱うデータが複雑に感じたときは、選択（Select）で形を整えることから始めてみてください。

Power AutomateのSharePointトリガーが動かないときに確認する5つのこと

Mon, 16 Mar 2026 15:46:54 GMT

Power AutomateのSharePointトリガーは、設定は簡単なのに動かないケースが意外と多いです。原因を知っておくと、トラブルシューティングの時間が大幅に短縮できます。

SharePointトリガーの種類

Power AutomateでSharePointを起点にするトリガーは主に3種類あります。

トリガー名	発火条件	主な用途
アイテムが作成されたとき	リストに新しいアイテムが追加された瞬間	申請受付、通知送信
アイテムが作成または変更されたとき	新規追加または既存アイテムの更新	変更監視、承認フロー
ファイルが作成または変更されたとき	ドキュメントライブラリへのファイル追加・更新	ファイル処理の自動化

「作成されたとき」と「作成または変更されたとき」は似ていますが、後者は既存アイテムを更新しても発火します。承認処理でステータスを変更したときにも動いてほしい場合は後者を選びます。誤って「作成されたとき」にしてしまうと、更新時に発火しないので注意が必要です。

動かないときに確認する5つのこと

① サイトアドレスとリスト名が正しいか

これが原因のことが一番多いです。サイトのURLを手打ちしていると、末尾のスラッシュの有無や大文字小文字の違いで接続できないことがあります。プルダウンから選択するのが確実です。また、SharePointサイトの名前を変更していた場合、以前のURLが使われていてつながらないケースもあります。

② フロー接続のアカウントにリストへのアクセス権があるか

フローを作ったアカウントと、実際にSharePointにアクセスできるアカウントが一致しているか確認します。部署異動や退職でアカウントが変わると、接続が切れたままフローだけ残るというケースがよくあります。フロー詳細画面の「接続」セクションで確認できます。

③ トリガー条件（フィルター）が厳しすぎないか

トリガーにフィルタークエリや列の値による絞り込みを設定している場合、その条件に合致するアイテムだけが発火対象になります。条件を誤って設定していると、更新しても一切発火しません。まずフィルターを外してテストし、発火するか確認するのが最短の切り分け方法です。

④ トリガーのポーリング間隔を確認しているか

SharePointのトリガーはリアルタイムではなく、一定間隔でSharePointを確認するポーリング方式です。デフォルトは3〜5分間隔のことが多く、すぐには発火しません。変更後5分待っても発火しない場合は別の原因を疑いますが、30秒後に確認しても当然動いていません。これを知らずに「動かない」と思い込むケースも多いです。

⑤ フローが有効になっているか

フロー詳細画面でフローがオンになっているか確認します。テスト中にオフにしたまま忘れることがよくあります。また、エラーが連続して発生するとPower Automateが自動的にフローを無効化することがあります。実行履歴でエラーの有無もあわせて確認しましょう。

よくある誤解：アイテム更新時に複数回発火する

「作成または変更されたとき」のトリガーを使っていると、1回の保存で複数回フローが走ることがあります。これはSharePointが内部的に複数回の更新イベントを発生させるためで、Power Automateの不具合ではありません。たとえば添付ファイルを追加すると、アイテム本体の更新と添付ファイルの更新で2回発火することがあります。

この問題への対処としてよく使われるのが、トリガー条件の設定です。特定の列の値が変わったときだけ発火させるように条件を絞ることで、意図しない多重実行を防げます。詳しい設定方法はトリガー条件とフィルタークエリの記事で解説しています。

デバッグのコツ

動かないトリガーのデバッグは、まず手動テストから始めるのがおすすめです。フロー編集画面からテスト→手動でトリガーを選べば、SharePointの変更なしにフロー全体の動作確認ができます。これでフロー自体は動くのにトリガーだけ発火しないと分かれば、上の5つの確認に絞って調査できます。実行履歴とエラー内容の読み方はデバッグのコツの記事を参考にしてください。

まとめ

SharePointトリガーが動かない原因のほとんどは、接続先の誤り・権限切れ・フィルター設定のミス・フローがオフのいずれかです。まずこの4点を確認するだけで、大半のトラブルは解決できます。焦らず順番に確認することをおすすめします。

Power AutomateでTeamsチャットに自動通知する。基本設定から実用シーン7パターンまで

Mon, 16 Mar 2026 15:46:54 GMT

Power AutomateでTeams通知を自動化すると、手動での連絡ミスや報告漏れがほぼなくなります。設定自体は難しくないですが、実務で使える形にするには少しコツが要ります。

Teams通知アクションの基本

Power AutomateでTeamsに通知するアクションは主に2種類あります。

アクション名	投稿先	主な用途
チャットまたはチャネルでメッセージを投稿する	チャネル or チャット	部署への一斉通知、定期レポート
チャットまたはチャネルにアダプティブカードを投稿する	チャネル or チャット	承認ボタン付きの通知、入力フォーム

通常の文字列メッセージを送るだけであれば「チャットまたはチャネルでメッセージを投稿する」で十分です。ボタン操作や入力フォームを通知に組み込みたいときはアダプティブカードを使いますが、設定の難易度は上がります。まずはシンプルなメッセージ投稿から試してみることをおすすめします。

投稿者の設定はFlowボットが無難

メッセージの投稿者を「ユーザー」に設定すると、フローを作成したアカウントの名前でメッセージが届きます。一見いい感じに見えますが、そのアカウントが退職や部署異動でライセンスを失うと、フローが止まります。個人的には投稿者をFlowボットにしておくほうが安定していておすすめです。チャネルへの投稿ならFlowボットを選ぶだけで設定完了です。

実用シーン7パターン

① SharePoint申請の受付通知

SharePointリストにアイテムが追加されたとき、担当チャネルへ自動通知。申請内容の主要項目（申請者名・内容・日付）を動的コンテンツで埋め込むと、受け取った側が一目で内容を把握できます。

② 承認完了の本人通知

承認フローが完了（承認または却下）したとき、申請者本人にTeamsチャットで結果を通知。メールより気づかれやすく、既読も取りやすいです。

③ 定期レポートの自動配信

毎朝9時にSharePointリストの前日データをまとめてチャネルへ投稿。集計はSQLやSharePointの「アイテムの取得」とフィルタを使い、本文を組み立てます。週次で30分かかっていた報告が完全に自動化できます。

④ 期限切れアラート

SharePointリストの期限日列を毎日チェックし、3日以内に期限が来るアイテムを担当者にチャット通知。期限超過の防止に効果的です。

⑤ フォームへの回答通知

Microsoft Formsに回答が届いたとき、内容をTeamsチャネルへ投稿。アンケートや社内申請フォームの運用コストを下げられます。

⑥ ファイル更新の変更通知

SharePoint上の特定ファイルや共有フォルダが更新されたとき、関係者チャネルへ通知。更新したのに誰も気づいていなかったという事態を防げます。

⑦ エラーアラートの自動通知

別のフローがエラーで失敗したとき、管理者チャネルへ自動でエラー内容を通知。フローの監視として使っています。エラーメッセージをそのまま貼るだけで、原因特定のスピードが上がります。

メッセージ本文の組み立て方

Teams通知で地味に大事なのが、メッセージ本文の見やすさです。動的コンテンツをそのまま並べるだけでは、受け取った側が読みにくいことがあります。いくつか工夫するだけでかなり変わります。

件名的な1行目を太字にする（HTMLタグ <b> が使えます）
改行を意図的に入れて、項目ごとに行を分ける
Joinアクションで複数件の名前や値を「、」でつないで1行に収める
リンクを埋め込む場合は <a href=“URL”>リンクテキスト</a> で表示名をつける

TeamsのチャネルへのHTMLについては、試してみないと分からない部分もあるので、テスト投稿を繰り返して確認するのが確実です。

よくあるトラブルと対処法

メッセージが空になってしまう

動的コンテンツの元になるデータが空だと、メッセージ内の変数部分が空白になります。事前に条件分岐でデータが存在するかチェックしてから通知を送るようにしましょう。

投稿先チャネルが見つからない

アクションの設定でチャネルを選ぶとき、プルダウンに表示されないことがあります。チームの表示名が変更されたか、アクセス権がない場合が多いです。手動でチームIDとチャネルIDを入力する方法もあります。

まとめ

Teams通知の自動化は、Power Automateの活用の中でも費用対効果が高い施策のひとつです。最初は送るだけのシンプルなフローでも、現場での気づきを増やすだけで十分な効果があります。まずは小さく始めて、使いながら育てていく——そういう地道な積み重ねが、職場の自動化を前に進めてくれます。

Power Automateのトリガー条件とフィルタークエリ。フローを無駄に動かさないための設定

Mon, 16 Mar 2026 15:46:44 GMT

Power Automateのトリガー条件を使うと、フローを無駄に動かさずに済みます。条件に合わないときは処理を開始する前にスキップされるため、実行回数を減らしてフローをシンプルに保てます。

トリガー条件とは

通常のフローでは、トリガーが発火したら必ず処理が始まります。たとえば「アイテムが作成または変更されたとき」というSharePointトリガーを使うと、リストへのあらゆる変更で発火します。承認済みのアイテムだけを処理したい場合でも、下書き中のアイテムが変更されるたびに発火してしまいます。

トリガー条件は、この発火自体を制御する設定です。「この条件を満たさない場合はフローを開始しない」というフィルターをトリガーレベルで設定できます。フローが起動してから条件分岐で弾くのと違い、トリガー条件に合わない場合は実行回数のカウントにも含まれません。

フロー内の条件分岐との違い

比較項目	トリガー条件	フロー内の条件分岐
処理開始	条件不一致なら開始しない	フローは起動してから分岐する
実行回数へのカウント	カウントされない	カウントされる
デバッグのしやすさ	発火していないと履歴に出ない	履歴に残るので追いやすい
向いているケース	明確に弾きたい条件がある場合	複数の分岐処理が必要な場合

実行回数が月の上限に近づいているフローや、高頻度で発火するトリガーを使っている場合には、トリガー条件を設定することで無駄な実行を大幅に減らせます。

設定方法

トリガー条件はトリガーの「詳細オプション」から設定します。

フロー編集画面でトリガーブロックをクリック
「詳細オプションを表示する」をクリック
「トリガーの条件」入力欄が表示される
式（Expression）で条件を記述する

条件は式として書く必要があり、trueまたはfalseを返す式を指定します。複数の条件を設定することもできますが、その場合はすべての条件が true のときだけ発火します（AND条件）。

よく使う式のパターン

特定の列の値が一致するとき

SharePointリストの「Status」列が「承認済み」のときだけ発火させたい場合：

@equals(triggerOutputs()?['body/Status/Value'], '承認済み')

特定の列が変更されたとき

「担当者」列が更新されたときだけ発火させたい場合（変更前後の値を比較）：

@not(equals(triggerOutputs()?['body/AssignedTo/Email'], triggerOutputs()?['body/{Prior-AssignedTo/Email}']))

数値が閾値を超えたとき

「在庫数」が10以下になったときに発火させたい場合：

@lessOrEquals(triggerOutputs()?['body/StockCount'], 10)

式の書き方はComposeアクションで動作確認してから貼り付けると、文法ミスを減らせます。Composeでテストする方法はComposeアクションの実践ガイドで解説しています。

フィルタークエリとの使い分け

SharePointトリガーには「フィルタークエリ」という設定もあります。これはSharePoint側にODataクエリを渡して、最初から条件に合うアイテムだけを取得する方法です。

設定	仕組み	書き方
トリガー条件	Power Automate側でフィルタリング	式（@equals等）
フィルタークエリ	SharePoint側でフィルタリング	ODataクエリ（Status eq ‘承認済み’）

フィルタークエリはSharePoint側で処理するため、Power Automateへの転送データ量を減らせます。一方、ODataクエリの文法が必要なため、慣れるまで書き方で詰まることがあります。単純な値の一致であればフィルタークエリ、複雑な式が必要ならトリガー条件と使い分けるのが現実的です。

デバッグ時の注意点

トリガー条件が true にならないとフローは起動しないため、実行履歴にも残りません。条件を設定してから「フローが動かない」と思ったら、まずトリガー条件の式が正しいか確認します。式を一時的に削除してテストし、発火するようになれば式の問題と判断できます。デバッグの基本については実行履歴の見方も参考にしてください。

まとめ

トリガー条件はシンプルな設定ですが、正しく使うとフローの効率が大きく変わります。多重発火の防止や、無駄な実行を減らすための最初の一手として、ぜひ活用してみてください。式の書き方に慣れるまでは少し時間がかかりますが、一度覚えると手放せなくなります。

Power Automateのトリガーはどれを選ぶ？自動化・インスタント・スケジュールの違いを徹底解説

Fri, 13 Mar 2026 12:41:00 GMT

Power Automateでフローを作るとき、最初に選ぶのがトリガーです。自動化・インスタント・スケジュールの3種類がありますが、どれを選ぶかによってフローの動き方が根本的に変わります。

3種類のトリガーの違い

まず「何が起点になるか」で選ぶ

トリガーとは、フローが動き出すきっかけのことです。Power Automateでは新しいフローを作るとき、まずこの3つから選びます。

種類	起点	代表的な使い場面
自動化クラウドフロー	外部のイベント（メール受信、リスト更新など）	SharePointに新しい行が追加されたら通知、メールが届いたら転送
インスタントクラウドフロー	人が手動でボタンを押す	Power Appsのボタン、Teams のボタン、スマホのボタン
スケジュールクラウドフロー	指定した日時・間隔	毎朝9時に日報集計、毎週月曜に週次レポート送信

選び方のコツはシンプルで、何かが起きたときに自動で動かしたいなら自動化、人が操作したタイミングで動かしたいならインスタント、定期的に動かしたいならスケジュールです。

自動化クラウドフロー

イベント駆動で動く

自動化クラウドフローは、何らかのイベントが起きたときに自動で動き出します。SharePointリストに新しいアイテムが追加された、Outlookに特定の件名のメールが届いた、Formsに回答が送信された、といったイベントがトリガーになります。

社内でよく使う例を挙げると、SharePointの申請リストに新しいアイテムが登録されたら承認者にTeamsで通知するフローがあります。これは完全に自動なので、申請があった瞬間に承認者に連絡が届きます。誰かが手動でメールを送る必要がなくなります。

代表的なトリガー一覧

自動化フローで選べる主なトリガーを以下に示します。

SharePoint：アイテムが作成されたとき / アイテムが作成または変更されたとき
Outlook：新しいメールが届いたとき / フラグが付いたメールが届いたとき
Microsoft Forms：新しい回答が送信されたとき
Teams：メッセージが投稿されたとき / チャネルにメッセージが届いたとき
OneDrive：ファイルが作成されたとき / ファイルが変更されたとき

SharePointのトリガーは注意点が一つあります。アイテムが作成または変更されたときのトリガーは、アイテムを更新するたびに毎回フローが動きます。フローの中でそのアイテムを更新する処理が入っていると、更新 → トリガー発火 → また更新 → また発火という無限ループになる可能性があります。条件分岐でフローの入り口に最初の申請のときだけ動くという制御を入れておきましょう。

インスタントクラウドフロー

ボタンを押したときだけ動く

インスタントクラウドフローは、人が手動でトリガーを起動します。Power Appsのボタンから呼び出す、Teamsのメッセージからフローを実行する、スマートフォンのPower Automateアプリのボタンから動かす、といった使い方が代表的です。

Power Appsとの連携で一番よく使うのがこのインスタントフローです。Power AppsからPower Automateのフローを呼び出す場合は、インスタントフローでトリガーをPower Appsからにする必要があります。選択画面ではPower Appsというコネクタのトリガーを選びます。

Power Appsから引数を渡す

Power Appsからインスタントフローを呼び出すとき、値（引数）を渡すことができます。たとえばPower Appsで選択された申請IDをフローに渡して、そのIDに対応する処理をPower Automate側で実行するといった連携が可能です。

フロー側でトリガー（Power Appsのボタンのトリガー）の直後にパラメーターを定義しておき、Power Apps側では Run() 関数でフローを呼び出す際に引数を渡します。Power AppsとPower Automateを組み合わせた設計では欠かせない仕組みです。

実行者の権限で動く

インスタントフローは、ボタンを押した人（実行者）の権限でフローが動きます。これは重要なポイントです。フローを作った人のアカウントではなく、実際に実行した人の権限が使われるため、実行者がアクセス権を持っていないリストやメールボックスへの操作はエラーになります。

スケジュールクラウドフロー

時間が来たら自動で動く

スケジュールクラウドフローは、指定した間隔や日時で定期的に動きます。毎日・毎週・毎月といった繰り返し設定ができ、特定の曜日や時刻を細かく指定することも可能です。

業務でよく使うパターンは、毎朝8時に昨日の受注データを集計してTeamsに投稿する、毎週月曜日の朝に未承認の申請一覧をメールで送る、月末最終営業日に請求書一覧を作成してOneDriveに保存する、といったものです。定型的な集計・報告業務との相性が特に良いです。

スケジュールの設定方法

フロー作成時にトリガーで繰り返しを選ぶと、間隔と頻度を設定できます。間隔は1以上の数値で、頻度は分・時間・日・週・月から選びます。さらに詳細設定を開くと、特定の曜日や時刻を指定できます。

毎週月曜日の朝9時に動かしたい場合は、頻度を週・間隔を1にして、詳細設定で月曜日を選び、時刻に09:00を入力します。タイムゾーンの設定を忘れると日本時間と9時間ずれるので、必ず東京標準時（UTC+9）を選ぶようにしてください。最初の設定でここをミスしてフローが深夜に動いていた、という経験が私にもあります。

選び方で迷ったときの判断軸

よくある迷いどころ

実際に作ろうとすると、自動化とスケジュールのどちらにするか迷うことがあります。たとえば毎朝9時にSharePointリストの内容をメールで送りたい場合、これはスケジュールが適切です。リストに変更があったときだけ動かしたいなら自動化を選びます。

迷ったときの判断軸は2つです。タイミングを自分でコントロールしたいかどうか、そしてイベントの発生がトリガーかどうかです。毎日定時に動かしたいならスケジュール。何かが起きたらすぐ動かしたいなら自動化。自分がボタンを押したときだけ動かしたいならインスタントです。

後から変更はできない

一度作成したフローのトリガー種別（自動化・インスタント・スケジュール）は後から変更できません。トリガーを選び直したい場合は、フローを作り直す必要があります。最初の選択が重要ですので、どの種別が適切かを最初にしっかり確認しておきましょう。

Power Automateで変数を使った処理の組み立て方は別の記事で解説しています。また、フローの作り方の基本を学ぶにはPower Appsで使える実用テクニックも参考にしてみてください。

まとめ

3種類のトリガーの選び方は、何が起点になるかで決まります。イベントが起きたとき（自動化）、人が押したとき（インスタント）、時間が来たとき（スケジュール）です。これさえ押さえておけば、フロー作成の最初の迷いはほぼなくなります。

最初はシンプルなスケジュールフローや、Formsへの回答をメール通知する自動化フローから試してみるのがおすすめです。動いたときの達成感があるので、楽しみながら覚えられます。

Power Automateの変数命名規則。後で見てもわかる変数名のつけ方とルール設計

Mon, 16 Mar 2026 15:46:45 GMT

Power Automateのフローを作っていると、変数名を何となくvar1・temp・flagのようにつけてしまいがちです。動いているうちは問題ありませんが、1ヶ月後に修正しようとしたときこれ何の変数だったっけとなります。変数名の付け方をルール化しておくだけで、後のメンテナンスコストが大きく変わります。

おすすめの命名規則：プレフィックス＋意味のある名前

変数の種類ごとにプレフィックスをつける方法が読みやすく、一般的にも広く使われています。

種類	プレフィックス	例
文字列（String）	str	strApplicantName、strMailBody
整数（Integer）	int	intRecordCount、intRetryLimit
真偽値（Boolean）	bln または is	blnIsApproved、isCompleted
配列（Array）	arr	arrTaskList、arrRecipients
オブジェクト（Object）	obj	objCurrentUser、objConfig
日時（DateTime）	dt	dtTodayJST、dtDueDate

プレフィックスをつけることで、変数名を見ただけで型がわかります。Power Automateでは型エラーが出ることがあるので、型を意識した名前をつけておくと原因特定も早くなります。

名前の付け方の3原則

① 何が入っているかを名前にする

変数の用途ではなく、入っている値の内容を名前にします。

NG：strTemp、strWork、str1
OK：strApplicantName、strSubjectLine、strErrorMessage

「何のための変数か」より「何が入っているか」を名前にする方が、後から読んだときにすぐわかります。

② 略語は最小限にする

略語を多用すると名前が暗号になります。一般的に通じる略語（ID、URL、JST、UTCなど）以外は省略しないほうが読みやすいです。

NG：strApNm、intCnt、dtDl
OK：strApplicantName、intCount、dtDeadline

③ 複合語はキャメルケースで書く

複数の単語を組み合わせる場合は、単語の区切りを大文字にするキャメルケースが読みやすいです。

NG：strrecordcount、str_record_count
OK：strRecordCount

スペースやアンダースコアは式で参照するときにエラーの原因になることがあるので、キャメルケースが無難です。

フロー全体での変数管理のコツ

変数の初期化はフロー冒頭にまとめる

Power Automateの変数はフローの途中で初期化できません（使う前に必ず初期化が必要）。フロー冒頭に変数の初期化アクションをまとめておくと、どんな変数を使っているか一目で把握できます。

初期化アクションをまとめる場所が決まっていると、変数の棚卸しもしやすくなります。使われなくなった変数が残っていないかを定期的に確認する習慣もつけておくとよいです。

ループ内の一時変数には local をつける

Apply to each の中だけで使う一時的な変数は、接頭辞にlocalをつけると「このスコープだけで使う変数だ」とわかりやすくなります。

localStr…、localInt… のように命名する
ループを出た後は参照しないことを明示できる

作成（Compose）で定数を管理する

フロー内で固定値として使う文字列（メール送信先、設定値、定型文など）は作成（Compose）アクションに入れておくと管理しやすくなります。変数と違い上書きされる心配がなく、「定数」として扱えます。

// 作成「設定：送信先メールアドレス」
admin@example.com

作成（Compose）に意味のある名前をつけておけば、後から変更が必要なときも一か所を変えるだけで済みます。作成（Compose）アクションの活用方法は別記事でまとめています。

→ Power Automateの作成（Compose）アクション——デバッグと式の整理に使う実践ガイド

チームで運用するフローでの追加ルール

自分だけが使うフローと、チームで共有するフローでは求められる丁寧さが変わります。複数人が触るフローでは、以下も意識しておくとよいです。

アクション名にも説明をつける（デフォルト名のままにしない）
スコープアクションでアクションをグループ化して意図を明示する
コメントアクションで処理の意図を残す

変数名だけでなく、アクション名も「HTTP」「作成」のままにせず「HTTP：〇〇APIを呼び出す」「作成：本文テキストを組み立てる」のように意図を書いておくと、引き継ぎのときに格段に楽になります。

まとめ

Power Automateの変数命名は、プレフィックス＋内容の英語キャメルケースで統一するのがおすすめです。何が入っているかを名前にする、略語は最小限にする、複合語はキャメルケースにする、の3原則を守るだけで後から読んでもわかるフローになります。

変数名の付け方は地味ですが、フローが増えてくると効いてきます。最初から習慣にしておくほうが後から直すより楽なので、今日から取り組んでみてください。

Power Automateで変数を使いこなす。初期化・セット・追加の全パターン

Tue, 17 Mar 2026 10:49:00 GMT

Power Automateの変数は、フローの中で値を一時的に保存しておく仕組みです。使い方のルールを知っておかないと、なぜか値が更新されない、スコープの外で使えないといった詰まりポイントにはまります。

変数の基本：3つのアクション

変数を初期化する・変数の設定・値を増やすなど

Power Automateで変数を扱うアクションは主に3つです。それぞれ役割が明確に分かれています。

アクション	役割	使うタイミング
変数を初期化する	変数を宣言して初期値を設定する	フローの最初に一度だけ
変数の設定	変数の値を上書きする	変数の値を更新したいとき
文字列変数に追加	文字列変数に文字を追加する	テキストを少しずつ積み上げるとき
配列変数に追加	配列変数に要素を追加する	ループ内でリストを組み立てるとき
変数の値を増やす/減らす	整数変数に数値を加算/減算する	カウンターを増やす/減らすとき

変数を初期化するは必ず先に実行する必要があります。初期化されていない変数を変数の設定で使おうとするとエラーになります。フローを作り始めたら、使う変数はすべてフローの最初にまとめて初期化しておくのが基本です。

変数を初期化する：変数の宣言

型と初期値を決める

変数を初期化するでは、変数の名前・型・初期値を設定します。型は以下から選びます。

String（文字列）：テキストを保存する
Integer（整数）：整数の数値を保存する
Float（浮動小数点数）：小数を含む数値を保存する
Boolean（真偽値）：true か false を保存する
Array（配列）：複数の値のリストを保存する
Object（オブジェクト）：キーと値のペアを保存する

初期値は空白にしておいても構いませんが、Integer や Float は初期値に 0 を入れておくと後で変数の値を増やす/減らすや変数の設定で計算するときにエラーが出にくいです。Array 型は初期値に空の配列 [] を入れておくのが定番です。

スコープの外では使えない

変数には重要なルールがあります。変数を初期化するは、Scope（スコープ）や Apply to each、条件分岐（Condition）などのコンテナアクションの中では実行できません。必ずフローのトップレベル（一番外側）に置く必要があります。

Scope の中で変数を初期化しようとするとエラーになる、という経験は多くの人がしています。私も最初にエラーメッセージを見たとき意味がわからなかったのですが、変数の初期化はフローの一番外側でしかできないという制約があるためです。

一方で変数の設定は、Scope や Apply to each の中から使えます。初期化だけが外側に制限されていると覚えておきましょう。

変数の設定：値の上書き

現在の値を新しい値に差し替える

変数の設定は、すでに存在する変数の値を新しい値に上書きします。計算結果を変数に保存したり、条件によって変数の内容を切り替えたりするときに使います。

たとえばステータスを表す変数 varStatus を初期化しておき、後続の処理で条件によって承認済みや却下といった値に切り替えるパターンです。条件分岐の中でそれぞれ変数の設定を使えば、後続の処理では varStatus の値を見るだけで済みます。

式を使った計算も入れられる

変数の設定の値には式を使えます。たとえばカウンターを1増やすなら以下のように書きます。

add(variables('varCount'), 1)

varCount という整数変数に1を足した値で上書きする式です。ループのたびにこれを実行すれば、処理した件数を数えられます。整数の加算なら変数の値を増やすを使うほうがシンプルですが、掛け算や割り算など他の計算が必要なときは変数の設定+ 式の組み合わせが必要です。

文字列変数に追加：値の追加

文字列をつなげる

文字列変数に追加は、文字列変数の末尾に文字を追加します。複数の処理結果をひとつの文字列に積み上げていくときに使います。

たとえばメールの本文を組み立てる場合。それぞれに適用（Apply to each）でリストを1件ずつ処理しながら、各行のテキストを改行コードつきで varMailBody に追記していき、ループが終わったら varMailBody をメール送信アクションの本文に渡します。

concat(items('Apply_to_each')?['Title'], '：', items('Apply_to_each')?['Status'], decodeUriComponent('%0A'))

decodeUriComponent(‘%0A’) は改行コードの入れ方です。メール本文での改行はこれを使うのが確実で、私もよく使います。

配列に要素を追加する

配列変数に追加は、配列変数に新しい要素を1件追加します。条件に合ったアイテムだけを配列に集めて、後でまとめて処理するパターンでよく使います。

たとえばApply to eachで全件を処理しながら、特定の条件を満たすものだけを varFiltered 配列に追加していき、ループ後に varFiltered の中身だけを対象に次の処理をするという使い方です。フィルタリングをPower Automate側でやりたいときに役立ちます。

変数を使うときのよくある失敗と対処

Appendが意図せずループをまたいで蓄積される

フローを複数回実行したとき、前回の実行の値が残っていると思っている人がいますが、変数はフローの実行のたびに変数を初期化するから始まるので、実行をまたいで値が引き継がれることはありません。

ただし同一実行内のループでは当然累積されます。Apply to eachが10回回れば Append も10回実行され、文字列や配列には10件分のデータが蓄積されます。これは意図した動作ですが、テスト時に想定より長いメール本文が生成されて驚くことがあります。

変数名は日本語でも使えるが英語がおすすめ

変数名は日本語でも設定できます。ただし、式の中で変数を参照するとき（variables(‘変数名’) の形）に日本語の変数名が入ると、後で式を見直したときに読みにくくなります。個人的には varStatus、varCount、varMailBody のように先頭に var をつけた英語名にしています。チームで使うフローなら命名規則を最初に決めておくと管理が楽になります。

複雑なデータはObject型で扱う

複数のキーと値のセットをひとまとめに保存したい場合は Object 型の変数が使えます。JSON形式でデータを保持でき、後続のアクションで特定のキーの値だけを取り出すことができます。ただしObject型はやや扱いが難しいので、まずは String・Integer・Array の3つをしっかり使いこなすのが先決です。

Power Automateのトリガーの種類と使い分けはこちらの記事で、Apply to eachとの組み合わせパターンはApply to each完全攻略で解説しています。変数はこれらと組み合わせて使うことが多いので、合わせて確認してみてください。

まとめ

Power Automateの変数は、変数を初期化するで宣言、変数の設定で上書き、Append で追加という3ステップで使います。初期化はフローの一番外側に置く制約さえ覚えておけば、基本的な使い方には困りません。

最初はシンプルなカウンターや文字列の積み上げから試してみましょう。変数を使いこなせるようになると、フローで表現できることが一気に増えます。楽しみながら試してみてください。

Power Automateで使える実用テクニック

Wed, 16 Oct 2024 17:04:09 GMT

Power Automate操作で役立つテクニックを紹介します。

フローは複製できる

作成したフローは「名前をつけて保存」することで複製できます。

バックアップや、大掛かりな変更をかける際に複製しておくと安心です。

アクションはコピーできる

アクションを丸々コピーして貼り付けて使うことができます。

コピーしたいアクションを右クリックしてコピー、もしくはCtrl＋C（Macは⌘＋C）でコピーします。

貼り付けたい箇所のプラスボタンを押し、「アクションの貼り付け」をします。

旧デザイナーはコピーしたアクションの履歴が残るので、複数のアクションを記憶して使い回すことができて便利です。

旧デザイナーのほうが便利

新しいデザイナーはこの機能が廃止されたようで、一度に保持できるアクションは1つになりました。

アクションは任意の名前をつけよう

各アクションは名前をつけることができますので、どんなアクションかわかりやすい名付けをしましょう。

でないと、

複数の項目を取得
複数の項目を取得 1
複数の項目を取得 2
複数の項目を取得 3

のように、一見しても何のアクションか判断がつきません。

この際、アクションの元の名前は消さずに残したまま、その後ろにわかりやすく名前を入れることをおすすめします。

「あれ、これ何のアクションを使ってるんだっけ？」と後々後悔することになりがちです。

メモ書きをうまく使おう

アクションにメモを残すと、後で見返した際に便利です。

そのアクションで具体的に何をどういう処理をしているか、クエリの書き方やコツなど一言メモ書きしておくといいでしょう。

アクションはドラッグ＆ドロップで移動できる

挿入したアクションはドラッグ＆ドロップで任意の場所に移動できます。

順番を入れ替えたい時に便利な機能です。

並列分岐で見やすさアップ

アクションが連続して並ぶと、流れを追ったりアクションの数の把握が難しくなります。

これをうまく並列分岐させることで見やすく、流れがわかりやすくなります。

注意点として、並列処理は実行順番が保証されません。

先にメールを送って、次にTeamsに飛ばすなど、明確に順序が決まっている場合は直列にしましょう。

Apply to eachの処理速度をアップする

繰り返し処理の Apply to eachは、データ量に比例して処理時間が長くなります。

1つの処理を終えて次の処理をし、終わったら次を処理し、と順に進めるためです。

設定から Concurrency control をオンにすると、一度に複数のデータを並行して処理するため、速度がアップします。

注意点として、実行順番が保証されない点と、数値を上げすぎるとうまく処理できないことがあることです。

最初は低い数値（5など）から始め、問題なさそうであれば大きくして調整しましょう。

随時更新します

他にも便利なテクニックがあれば、随時更新します。

Outlook予定を一覧表示するアプリ【Power Apps 活用事例サンプル】

Sat, 26 Oct 2024 09:08:33 GMT

私が作成したPower Apps 業務活用事例のサンプルを紹介します。

Outlook予定を一覧表示するアプリ

名前は仮名です

このアプリの主な特徴

任意の複数人のスケジュールを一覧表示する
予定は30分ごとに最新のものに自動反映
今日を含めて先6日間に対応
出社人数を動的にグラフ表示
部署を切り替えて表示可能
予定に合わせて動的に色とテキストが変更

このアプリのいまいちな点

見せられる予定は1日1件
Power Automateの設定が手間
上限30人が目安

作った背景

コロナを機に私の会社ではテレワークが始まり、出社人数が減少しました。

社内で蔓延を防止するため、部署ごとに出社人数の上限が設けられたのですが、全員のOutlookスケジュールを見て何人出社するか確認する手間があり、パッと把握しづらい状況でした。

そこで、Power Apps から出社人数を視覚的に把握し、誰が出社し、誰がテレワークかわかるアプリを作ろうと思ったのがきっかけです。

土日であっても、アプリを見れば誰が出社か確認しやすいという特徴もあります。

言い訳

実はこのアプリ、私が Power Platform に触れ始めて2番目に作ったものです。

当時は経験が浅く、いま見返すとどうしてこんな面倒な作り方をしたのか頭を悩ませるのですが、それも自身の成長の証としてそのまま紹介します。

最も工夫した点

関係者のスケジュールを Power Automate で自動取得する方法を工夫しました。

全員のPC1台1台から Power Automate を設定し、30分間隔で最新の予定6日分をリストに投稿するようにしたのです。そうです、力技です。

23年10月頃まで、スマホのOutlookアプリに他人のスケジュール表を追加するだけで Power Automate で取得できる仕様でした。

ですので他人の予定を自動取得するのは意外と簡単だったのですが、アップデートでこの方法が使えなくなり、このアプリの根幹を揺るがすことになります。

色々と調べたところ、スケジューラーの編集権限を私に付与してもらえれば全て解決らしいのですが、例え同じ部署の人であってもそれを快くOKしてくれる人はまずいません。

会社のポリシーでそれが禁止されていることもありますし。

自分自身のスケジュールならPower Automateで自動取得可能です。

それなら全員にPCを借りて同じフローを設定すればいけるのではないかという、保守性をガン無視した強硬策を実施しました。

その他の特徴

出社人数のグラフ表示

棒グラフ

その日、[出社]というキーワードをカウントしてグラフが動的に変化します。

土・日・祝は非表示になります。

最上段の出社人数

その日、[出社]というキーワードをカウントしてその数が表示されます。

土・日・祝は0になります。

日付と曜日

アプリを開いた日と曜日を起点にし、その日を含めて先6日間を表示します。

赤い線

これは出社可能人数（6割）の箇所に四角形を変形して配置しています。

背景のグラフ枠

これは画像貼り付けです。

Excelでシンプルなグラフ枠を作成し、それを最背面に配置し、前面にその他の要素を配置しています。

スケジュール

予定の表示

Power Automate を使ってリストに個人のスケジュールを吸い上げます。

それらのタイトルから判断し、[出社][TW][出張][休]を色別に表示しています。

土・日・祝は強制的に[休]が表示されます。

https://shiminkaihatsu.com/powerapps-schedule-textcolor/

https://shiminkaihatsu.com/pa_outlookschedule_listcopy/

氏名

所属する人の名前が入っています。

反省点

Galleryを使えばもっとシンプルに作れたかもしれませんが、当時の私は1つずつLabelで作っています。

人が増えれば増えるほどコントロールが増えてしまい、アプリが重たくなる要因の1つです。

部と課のボタン

関係する人数が多ければ、これらのボタンのように課でわけて表示する機能があってもいいでしょう。

追記：詳細なスケジュールの表示機能の追加

Labelで表示していた名前をボタンに変更し、ボタン押下で6日分の詳細なスケジュールが表示されるように機能を追加しました。

これでわざわざOutlookから詳細スケジュールを見ずとも、アプリから予定確認ができるようになって利便性が向上しました。

https://shiminkaihatsu.com/outlook-schedulelayout/

アプリを作ったことでの気付き

繰り返し表示するものはGalleryを使う

スケジュール表示のように、名前や予定が繰り返し表示されるような箇所にはGalleryが適していると感じます。

1つ目のGallery（縦）で人の名前を表示し、そこにGallery（横）を入れ子にして予定表示させれば、もっと軽くシンプルに設計できるかもしれません。

データソースが多すぎるのは問題

私が実際に会社で使っているものは35前後のリストをデータソースに設定しています。

Power Apps が推奨するデータソースの上限は30ですので、それを越えています。

その影響か、Power Apps Studio（開発画面）がめちゃくちゃ重たいです。

視覚に訴えるものは強い

出社人数のグラフ表示、個人の予定の色付けのように、視覚に訴えるコンテンツは視認性が良く、周りから高い評価を受けています。

削ぎ落とすことも大切

予定が1件しか表示できませんが、そもそもこのアプリの目的は出社人数を把握するためのものなので、そこは割り切って正解だったと思います。

あれもこれもと機能をつけたくなるのはわかりますが、まずは少ない機能でリリースし、本当に必要であれば少しずつ追加するぐらいがいいのかと。

Power AppsとPower Automateでの開発：シンプルなアプリから始めよう

Fri, 18 Oct 2024 17:02:57 GMT

Power AppsやPower Automateを始める方は、まずシンプルなツール作りからスタートするのがおすすめです。いきなり本格的なアプリを目指すと、高い確率で行き詰まります。

いきなり本格的な業務アプリを目指さない

会社で作るツールなんだから仕事に直結したものでないと、と考えてしまいがちですが、初心者がそれをやると行き詰まることが多いです。

経験が少ないと危険

Power Platformの開発経験が少ないうちから本腰を入れてスタートしようとすると、高い確率で進めなくなるポイントにぶち当たります。

エラーが解消できず、考え込み、開発画面を見ることすら嫌になります。

近くに経験者がいればまだマシですが、自分1人でやろうとするとかなりハードルが高いです。

実現可否の判断が難しい

作りたいツールが果たしてPower Platformで実現できることなのか、判断するには経験が必要です。

単純に自分の経験値が足りないのか、技術的にパワープラットフォームでは実現できないのか、その判断が難しくなります。

これもやはり近くに経験者がいればすぐわかりますが、自分1人だと難しくなります。

もし周りからこんな機能をつけられるかと相談を受けたとしても、経験不足が影響して答えるのも難しいでしょう。

所要時間の見積もりが難しい

目指すツールの開発にどれだけ時間を要するか、最初の段階では検討がつきません。

これも開発経験を積む中で、おおよその時間がわかるようになります。

応用を効かせづらい

UdemyやYouTubeを見ながら作ったツールの場合、それを応用して自分の業務に使うのはいきなりだと難しいです。

アプリの仕組みや動きを自分が理解して初めて応用できますので、たとえハンズオンで作ったアプリであっても、それをいきなり業務転用は考えないほうがいいです。

シンプルなツールから学べること

はじめは機能を限定した簡単なアプリやフローを作りましょう。

操作の慣れ

Power Platformの開発は、ウェブ上で専用のツールにアクセスして行います。

その使い方はもちろんですが、操作方法に慣れる必要があります。

関数の慣れ

Power PlatformではPower Fxという専用の関数を使います。Excelに似た感じですが、ここでしか使わない独特なものも多くあり、シンプルなツールを通じて慣れることができます。

Power Automateも同様で、まずは1〜2ステップの簡単なフローから作り始めることをおすすめします。Power Automateの基本的な使い方はPower Automate入門記事で解説しています。

エラーの慣れ

エラーに慣れることができます。

解決方法をネットで調べたり、AIを駆使して行くわけですが、最初は相当苦労することでしょう。

それも数をこなして慣れていく必要があります。

エラーを解消するほどスキルが自然に磨かれて、開発スピードが上がります。

情報の取り方の慣れ

わからないことを調べるうち、どこからどんな情報を取るべきかわかってきます。

解決策は基本的にネット上にありますので、いかにそこに効率的かつ素早く到達できるかが鍵です。

シンプルなツールの作成を通じて慣れていきましょう。

新しいアイディアの発想

作成の数をこなしていくうち、新しいツールの発想に繋がることがあります。

機能を使いまわしたり、より効率的な中身に差し替えたり、これらも経験を重ねる中で身につけることができます。

小さな成功体験に繋がる

作成したツールが動くと単純に嬉しいです。

ユーザーから感想をもらえればやる気に繋がりますし、さらに作りたくなるでしょう。

シンプルなツールの例

作成に慣れるためのシンプルツールの例を紹介します。

アプリ名	概要	学べる機能
くじびきアプリ	ボタンを押すとランダムに結果が表示されるアプリ	ランダム関数、条件分岐、ボタンクリックのイベント
デジタルサイコロアプリ	ボタンを押すとランダムにサイコロの目が表示されるアプリ	乱数生成、UIコンポーネント、データ表示
フラッシュカードアプリ	単語やフレーズを表示して記憶を助けるアプリ	データの表示、ランダム化、暗記用ツール
単語帳アプリ	単語とその意味を保存して学習するアプリ	データ保存、検索機能、暗記支援
メモ帳アプリ	簡単なメモを保存、編集、削除するアプリ	データ保存、編集機能、ユーザー入力の処理
シンプルな計算機	数字と演算子を入力して計算結果を表示するアプリ	計算ロジック、数式処理、リアルタイムデータ表示
TODOリストアプリ	タスクを追加、削除、完了状態にするアプリ	データのCRUD操作、リスト表示、状態管理
カウントダウンタイマー	指定した時間からカウントダウンするタイマーアプリ	タイマー機能、時間の管理、ユーザーインタラクション
クイズアプリ	クイズ形式で質問と回答を行うアプリ	条件分岐、データ管理、インタラクティブなUI
天気予報アプリ	指定した地域の天気予報を表示するアプリ	APIの使用、データ取得、外部データの表示
カレンダーアプリ	イベントや予定をカレンダーに表示するアプリ	日付操作、イベント管理、データの視覚化
買い物リストアプリ	買い物リストを作成し、完了した項目をチェックするアプリ	リスト操作、状態管理、CRUD操作
フィットネス追跡アプリ	毎日の運動や活動を記録するアプリ	データ入力、データ可視化、日次の記録管理
音楽プレイリストアプリ	お気に入りの曲やプレイリストを管理するアプリ	データ管理、リスト表示、CRUD操作
旅行計画アプリ	旅行の計画や行程を管理するアプリ	日付操作、イベント管理、データの視覚化
映画レビューアプリ	映画のレビューや評価を記録するアプリ	フォーム入力、評価システム、データ表示
アンケートアプリ	質問と回答を入力して集計するアプリ	フォームの作成、データ集計、ユーザーインタラクション
レシピ管理アプリ	レシピを追加、閲覧、検索するアプリ	データベースの利用、検索機能、フィルタリング
図書館管理アプリ	借りた本や返却日を管理するアプリ	データ管理、日付操作、通知機能
画像ギャラリー	画像をアップロードしてギャラリーに表示するアプリ	ファイルアップロード、データ表示、画像処理

興味があるものから作ってみることをおすすめします。

少し手を出して、難しそうであれば違うアプリに挑戦します。

はじめのうちは、とにかく手を動かして作成に慣れることが大事ですので、数をこなすようにしましょう。

Power AppsとPower Automateを組み合わせる

Power Appsでアプリに慣れてきたら、次のステップはPower Automateとの連携です。アプリのボタンを押したらTeamsに通知を送る、データを保存したらメールを送る、といった連携が実現できます。

Power AppsからPower Automateのフローを呼び出す方法については、Power AppsからPower Automateを呼び出す記事で詳しく解説しています。シンプルなアプリを作った後の次のステップとして、ぜひ試してみてください。

小さな成功で経験を積む

1度でもアプリを作ることができれば、後の開発で必ず役に立つ時が来ます。

たとえ今は業務に関係ないものに見えたとしても、あの時やっておいてよかったなと思える時が来るでしょう。

開発に慣れてくると、初期に開発した自分のアプリのレベルの低さに驚くことがあります。

それも自分が成長している証拠ですので、良いように捉えて、楽しみながら開発を進めましょう。

Power Apps開発全体の学習ロードマップについては、Power Apps開発の全体マップ記事で整理しています。シンプルなアプリからスタートして、少しずつステップアップしていきましょう。

SharePointリストとMicrosoft Lists。市民開発ならSharePointリストがおすすめ

Sat, 03 Aug 2024 09:21:55 GMT

Power AppsやPower Automateのデータソースとして使う、SharePointリストとMicrosoft Listsの違いを整理します。

どちらを使うか迷った場合は、個人的にはSharePointリストがおすすめです。その理由をこの記事で解説します。

機能に根本的な違いはない

SharePointリストとMicrosoft Listsに、機能的な大きな違いはありません。どちらもデータソースとして使えますし、見た目の違いもほとんどありません。

では何が違いなのかといえば、アクセス権の管理の方法です。

アクセス権の違い

まずSharePointリストは、特定のSharePointサイトの中に作成されます。サイトにアクセス権のあるメンバーであれば、基本的に誰でも編集権限を持っています。

一方のMicrosoft Listsは、作成者のOneDrive (for Business)の中に作成されます。アクセス権は基本的に作成者にしかなく、明示的に共有しない限り他人がアクセスすることはできず、URLを知られる心配もありません。

SharePointリストを使って開発する人の多くは、この誰でも編集権限がある状態を嫌います。これはSharePointサイトとリストの構造上、そういうものだと割り切るしかありません。（もし組織のポリシー上でサイトのアクセス権限を自由に変更できるのであれば対応策は存在します）

ですので、アクセス権を自由に設定できるMicrosoft Listsをデータベースとすれば、Listsごとにアクセス権を設定し、データの改変を防ぐことができるわけです。

	SharePointリスト	Microsoft Lists
機能の違い	なし	なし
見た目の違い	なし	なし
編集権限	サイトメンバー全員あり	自分のみ
格納場所	SharePointサイト	OneDrive(for Business)

しかしMicrosoft Listsは、後々ユーザー管理の煩雑さがネックになってくると思われます。

Microsoft Listsは数が増えると管理が大変

市民開発が進み、アプリもユーザーも増えてくると、ユーザー増減時のMicrosoft Listsのアクセス権管理が大変です。

Microsoft Listsが1つ2つならまだいいですが、アプリが増えていくにつれてListsも増えていきます。新しいメンバーが増えるたびに、すべてのListsにアクセス権を付与しなければならず、メンバーが抜けるたびに全部のListsから権限を削除する必要があります。

個人的には、このユーザー管理の手間を考えるとSharePointリストのほうが長期的な運用に向いていると感じています。SharePointサイトのメンバー管理だけで一括管理できるからです。

リストのアクセス権を変更するには

どうしてもSharePointリストのアクセス権を変更したい場合、以下の手順で対応できます。

STEP1

アクセス許可の管理を開く
STEP2

ユーザー、またはグループどちらかでアクセス権を変更する
STEP3

アクセス権の変更完了

この順番でやればリストごとのアクセス権を変更できます。

このやり方のデメリットは大きく2つあります。

1. アプリからも編集できなくなってしまう

編集権限を制限すれば、当然アプリやPower Automateのデータソースとして使うことができなくなります。閲覧のみ可能とすれば、ツールの用途によってはそれで事足りるかもしれません。

しかし閲覧するにしても、リストの保存場所を知られていると直接リストにアクセスされ、中身全部を閲覧されてしまいます（編集はできませんが）。

2. アクセス権の管理が大変

サイト内のリストが増えると、アクセス権の管理が煩雑になってしまいます。Microsoft Listsの管理よりかは幾分ラクかもしれませんが、人が変われば面倒に感じてくるかもしれません。

以上の2つの理由から、リストのアクセス権を変更するのは個人的にあまりおすすめしません。企業によっては、リストのアクセス権を変更してはならないと決められている可能性もあります（私が所属する会社はそうです）。

開発専用のSharePointサイトを使う

アクセス権の問題を解消するおすすめの方法は、開発専用SharePointサイトを使うことです。アプリ開発に使うリストを専用サイトに集約し、そのサイトへのアクセス権を持つメンバーのみがデータを扱える環境を作ります。

この方法であれば、サイトメンバーの増減管理だけで対応できます。委任問題や5,000件の上限については別途考慮が必要ですが、アクセス権管理の煩雑さからは解放されます。

ただし1つ注意点があります。Teamsを使うと、チャネル-ファイル-三点リーダーから辿ることでSharePointサイトにアクセスできてしまいます。

この方法でサイトの所在を知られてしまう

このTeamsの問題を解消するには、もう1つ別にSharePointサイトを作成し、そちらにも開発サイトと同じメンバーを登録し、そこでTeamsを使います。メンバー増減時の手間は増えますが、こうすれば開発サイトとコミュニケーションサイトを分離し、データソースへのアクセスを限りなく隠したまま進められるでしょう。

SharePoint ListsとPower Appsを使ったデータの読み書き（追加・更新・削除）の具体的な実装方法については、Power AppsでSharePointリストのデータを読み書きする記事で詳しく解説しています。あわせて参考にしてください。

また、フォームコントロールを使ったデータ入力・編集については、Power AppsのEditForm・NewForm・DisplayFormの記事も参考になります。

Dataverseを使う

Dataverseであればデータソースへのアクセス管理を細かく設定できます。SharePointリストのように頭を悩ませる必要はありませんし、Dataverseを利用できる環境であれば迷わず使用することをおすすめします。

ただし、Dataverseはプレミアムライセンスが必要で追加費用がかかります。また委任問題がないなどの利点はある一方、使いこなすための学習コストも高いです。まずはSharePoint Listsから始め、要件に応じてDataverseへの移行を検討するというのが現実的なステップだと思っています。

Power Apps全体のデータソース選びや開発の全体マップについては、Power Apps開発の全体マップ記事でまとめて解説しています。あわせて参考にしてください。