もう迷わない！Power AppsのDataverse更新手法４選【初心者から上級者まで】

Power Appsで業務アプリを開発する上で、データベースのデータを更新する機能は避けては通れない、まさに「心臓部」とも言える重要な要素です。しかし、Power Appsにはデータを更新する方法がいくつかあり、「どの方法を使えばいいの？」「それぞれの違いは何？」と悩んでいる方も多いのではないでしょうか。

この記事では、Power Appsの主要なデータベースであるDataverseのデータを更新するための代表的な4つの方法を、具体的なアプリの実例と共に徹底的に解説します。

この記事を読めば、それぞれの方法の特性を理解し、あなたのアプリの要件に最適な更新方法を自信を持って選択できるようになります。

Power Platformも学べる！オンライン学習ならUdemy

Udemy（ユーデミー）は、仕事に役立つスキルから趣味のトピックまで、「学びたい」が見つかるオンライン学習プラットフォームです。Power Apps や Power Automate をはじめとする Power Platform 関連講座も充実しており、業務効率化スキルをしっかり学べます。

今すぐUdemy講座をチェックする

この記事で想定する環境について

本記事で紹介するアプリの実例は、多くの企業で利用されているMicrosoft 365ライセンスの範囲内で、追加費用なく利用を開始できる「Microsoft Teams上で動作するPower AppsとDataverse for Teams」を主な環境として想定しています。

次の記事では、Dataverse for Teamsと通常のDataverse（有償版）の違いや、Microsoft 365ライセンスで利用できる範囲について紹介していますので参考にしてください。

関連記事

Power Apps・Power AutomateはM365でどこまで使える？「Dataverseの壁」を乗り越える徹底解説

「うちの会社、Microsoft 365（M365）を使ってるから、Power Appsで業務アプリが作れるはず！」 そう思っている方。それは間違いではありませんが、少しだけ注意が必要です。特に、アプリの「データの置き場所」となるD[…]

手法１．編集フォーム (Edit Form)：最も手軽に更新

まず紹介するのは、最もシンプルで直感的な「編集フォーム」を利用する方法です。ローコード開発の思想を最も体現しており、コーディング量を最小限に抑えたい場合に最適です。

どんなアプリ/シナリオに最適か？

●営業担当者が利用する顧客情報管理アプリ
●従業員が日々の業務内容を登録する日報アプリ
●とにかくスピーディに基本的なデータ入力画面を作りたい時

メリット・デメリット

●メリット

・圧倒的な開発スピード： わずかな設定と一行のコードで更新機能が実装できます。
・保守の容易さ：必須項目のチェックやデータ型の検証などが自動で行われるため、管理が簡単です。

●デメリット

・柔軟性の低さ：デザインやレイアウトの自由度が低く、定型的なフォームになりがちです。
・複雑な処理に不向き：「特定の項目が変更されたら別のテーブルも更新する」といった複雑なビジネスロジックには対応できません。

［実例］顧客情報管理アプリ

●アプリの目的・概要

営業担当者が利用する顧客情報管理アプリを想定します。このアプリの目的は、顧客情報の新規登録や既存情報の簡単な編集を可能にすることです。とにかくスピーディに基本的なデータ入力画面を作りたい時に適しています。

●画面構成・動作

左側に顧客一覧を表示するギャラリー、右側に選択された顧客情報を表示・編集するための編集フォームを配置します。フォームの下には「新規」「保存」ボタンを設置します。

・左側のギャラリーから顧客を選択すると、その情報が右側のフォームに表示されます。
・「新規」ボタンを押すと、フォームが新規入力モードに切り替わります。
・情報を入力・編集した後、「保存」ボタンを押すことで、フォームの内容がDataverseのテーブルに保存（または更新）されます。

●アプリの主な設定

・編集フォーム (Form1) の設定：

　DataSourceプロパティ > 取引先企業 （Dataverseのテーブル名）
　Item プロパティ > Gallery1.Selected （ギャラリーで選択された項目を表示）

・ボタンの設定：

　新規ボタン の OnSelectプロパティ > NewForm(Form1)
　保存ボタン の OnSelectプロパティ > SubmitForm(Form1)

// フォーム（Form1）の内容をデータソースに送信する
SubmitForm(Form1) 

これだけで、フォームに入力されたデータがDataverseの「取引先企業」テーブルに保存または更新されます。

手法２．Patch関数：柔軟性No.1

次に紹介するPatch関数は、データ更新における「万能選手」です。特定の列だけを更新したり、新しいレコードを作成したりと、非常に柔軟なデータ操作が可能です。

どんなアプリ/シナリオに最適か？

●一覧画面から直接ステータスを変更できるタスク管理アプリ
●フォームを使わずに、複数の入力コントロールからデータをまとめて更新する簡易登録画面
●アプリ内の計算結果や変数の値をDataverseに保存したい時

メリット・デメリット

●メリット

・高い柔軟性：特定の列のみを効率的に更新でき、アプリの操作性を向上させます。
・多様な用途：新規レコードの作成と既存レコードの更新を同じ関数で扱えます。

●デメリット

・コードの記述が必要：SubmitFormと比べて記述量が増え、関数の理解が必要です。
・開発者の責任範囲：データ型（特に選択肢や参照列）や必須列の扱いを開発者が意識して管理する必要があります。

［実例］タスク管理アプリでの部分更新

●アプリの目的・概要

タスク管理アプリで、一覧画面から直接タスクのステータスを変更する機能を実装します。フォーム画面に遷移することなく、タスクの一部情報（今回は「進捗」と「完了日」）だけをピンポイントで更新することが目的です。

●画面構成・動作

タスクの一覧をギャラリーで表示します。各タスク項目には「完了」ボタンを配置します。 

・ユーザーが特定のタスクの「完了」ボタンを押すと、そのタスクの「進捗」ステータスが「完了」に更新されます。
・同時に「完了日」にその日の日付が記録されます。タスク名などの他の情報は変更されません。

●アプリの主な設定

完了ボタン の OnSelectプロパティに以下の式を設定します。ThisItemはギャラリー内でそのボタンが属する行のレコードを指します。

// 'タスク'テーブルの、このアイテム（ThisItem）のレコードを更新
Patch(
    タスク,
    ThisItem,
    {
        進捗:LookUp(Choices('進捗 (タスク)'),Value=3).Value,
        完了日:DateValue(Text(Now(), "yyyy-mm-dd"))
    }
)

この方法なら、タスク名や詳細など他のデータを変更することなく、進捗と完了日だけをピンポイントで更新できます。

手法３．UpdateIf関数：複数レコードの一括更新

UpdateIf関数は、条件に一致する複数のレコードを一括で更新するときに使用します。手作業で行っていたら時間がかかる処理を、ボタン一つで完了させることができます。

補足：Update関数との違い

Update関数は、指定したレコード全体を更新するため、Dataverseなどの外部データソースでは、指定しなかった列が空になることがあります。そのため、特定の列だけを更新したい場合は、Patch関数やUpdateIf関数を使うのが一般的です。これらは部分更新に対応しており、データの意図しない消去を防ぐことができます。

どんなアプリ/シナリオに最適か？

●キャンペーン管理アプリで、古いキャンペーンのステータスを一括で変更する
●在庫管理アプリで、特定のカテゴリの商品の価格を一斉に10%引きにする
●年度末に、前年度の全ドキュメントのステータスを「アーカイブ済」にする

メリット・デメリット

●メリット

・圧倒的な効率性：条件に合う複数レコードを一度の操作で更新できるため、作業時間を大幅に短縮できます。
・コードの簡潔さ：ForAllとPatchを組み合わせるよりもシンプルなコードで実装できます。

●デメリット

・実行時のリスク：条件の指定を誤ると、意図しない大量のデータが書き換わる危険性があるため、慎重なテストが必須です。
・委任に関する注意：大量のデータを扱う場合、Dataverseの「委任」の制約を受けないか確認が必要です。

関連記事

Power AppsのFilter関数で「委任に関する警告」を回避する方法

ビジネスプロセスの効率化を実現するために、MicrosoftのPower Appsは非常に強力なツールです。しかし、Power AppsのFilter関数等を用いてDataverseのデータセットを操作する際には、委任に関する警告が発生す[…]

［実例］キャンペーン管理アプリでの一括更新

●アプリの目的・概要
キャンペーン管理アプリで、過去のキャンペーンステータスを一括で「終了」に変更する機能を実装します。管理者が手動で一つずつ更新する手間を省き、データメンテナンスを効率化することが目的です。

●画面構成・動作

管理画面にキャンペーン一覧と、「古いキャンペーンを一括終了」というボタンを配置します。

・管理者が「古いキャンペーンを一括終了」ボタンを押すと、「終了日が本日より前」かつ「ステータスが”終了”ではない」という条件に一致する全てのキャンペーンレコードのステータスが、一括で「終了」に更新されます。

・上の例では（2025年7月29日現在）担当者に★の付いている行が「終了」に変わります。

●アプリの主な設定

一括終了ボタン の OnSelect プロパティに以下の式を設定します。

// With関数で「終了」の状態を一度だけ取得し、使い回す
With(
    { completedStatus: LookUp(Choices('状態 (キャンペーン)'), Value=3).Value },
    UpdateIf(
        'キャンペーン',
        // 条件：終了日が今日より前、かつ状態が「終了」ではない
        終了日 < Today() && 状態 <> completedStatus,
        {
            // 更新内容：取得しておいた「終了」の値を設定
            状態: completedStatus
        }
    )
)

これにより、何十、何百という対象レコードを、ユーザーが一つずつ手作業で変更する必要がなくなります。

手法４．Power Automate：外部連携や複雑な更新処理

これまでの手法では対応が難しい、データの整合性を担保した上で複数の処理を確実に実行したい場合や、外部サービスとの連携が必要な場面で登場するのが「 Power Automate」です。

Power Appsからの依頼を受け、Power Automateが一連の更新処理を一つのパッケージとして実行してくれるため、処理の途中でエラーが発生してもデータの矛盾を防ぐことができます。

どんなアプリ/シナリオに最適か？

●在庫アプリで、在庫テーブルと売上履歴テーブルを同時に更新するなど、複数のデータベース操作の整合性を絶対に保ちたい時（トランザクション処理）
●データ登録後に、承認依頼の通知（Teams）や確認メールの送信（Outlook）といった外部サービスとの連携処理を確実に行いたい時
●サーバー側で実行させたい、時間のかかる複雑な処理をアプリの動作を止めずにバックグラウンドで実行したい時（非同期処理）

メリット・デメリット

●メリット

・複雑なロジックに対応：複数のテーブル更新や厳密な順序での処理（トランザクション）など、高度なビジネスロジックを実装できます。
・外部サービス連携：データ更新後にTeamsへ通知したり、メールを送信したりといった連携が可能です。
・非同期処理：時間のかかる処理をバックグラウンドで実行させ、アプリの応答性を維持できます。

●デメリット

・複合的な知識が必要：Power AppsとPower Automateの両方の開発・デバッグスキルが求められます。
・実行遅延の可能性：フローの呼び出しと実行には、アプリ内で完結する処理に比べて若干のタイムラグが生じることがあります。

［実例］複数テーブルを扱う在庫管理アプリ

●アプリの目的・概要

在庫管理アプリで、商品が売れた際のデータ更新処理を実装します。この処理では、「①商品マスタの在庫数を減らす」「②売上履歴テーブルに記録を残す」という2つの更新を、データの整合性を保ちながら（トランザクション処理のように）実行することが目的です。

●画面構成・動作

画面左側に「商品マスタ一覧」と右側に「売上履歴一覧」を配置します。また、「売上履歴一覧」側の上部には販売した商品と数量を入力できるコントロールと「登録」ボタンを配置します。

・ユーザーが「売上登録」ボタンを押すと、Power Automateフローが呼び出されます。
・フローはまず在庫数を確認します。
・在庫が十分にあれば、「商品マスタの在庫更新」と「売上履歴の追加」の両方を行い、Power Appsに「成功」の結果を返します。
・在庫が不足していれば、何も更新せずにPower Appsに「在庫不足エラー」を返します。
・Power Appsはフローの結果を受け取り、ユーザーに成功またはエラーのメッセージを表示します。

●アプリの主な設定

・Power Apps側の設定：

売上登録ボタン の OnSelect プロパティ:

// フローを実行し、結果を変数に格納
Set(
    gblFlowResult,
    売上登録v2.Run(Text(cmb_商品番号.Selected.商品ID),Value(txt_販売数.Value))
);

// フローの結果に応じてユーザーに通知
If(
    gblFlowResult.result = "成功",
    Notify(gblFlowResult.message, NotificationType.Success),
    Notify("エラー: " & gblFlowResult.message, NotificationType.Error)
);

// データソースを再読み込み;
Set(SaleLogGUID,LookUp('在庫管理売上履歴',在庫管理売上履歴 = GUID(gblFlowResult.uid)));
Refresh('在庫管理売上履歴');
Refresh('在庫管理商品マスタ');

・Power Automate フロー側の設定：

➀Power Apps (V2) を選択し、Power Appsから商品IDと販売数を受け取る入力を定義
②Dataverse「行を取得する」で現在の在庫数を取得
③「条件」で在庫が十分か判定
④（Yesの場合）Dataverse「行を更新する」で在庫数を更新、「新しい行を追加する」で売上履歴を記録
⑤Power Apps「Power App または フローに応答する」で、成功/失敗の結果を返す

このように、Power Apps側は「この商品をこの数だけ売って」と依頼するだけで、その後の「①在庫チェック → ②在庫更新 → ③売上記録」という一連の処理と、その成功・失敗の判定まで、全てPower Automateが責任を持って実行してくれます。

まとめ：どの方法を選ぶべきか？

ここまで4つの方法を実例と共に紹介してきましたが、最後にそれぞれの使い分けを表にまとめました。

Power Appsでのデータ更新は、アプリの要件によって最適なアプローチが異なります。まずは編集フォームから試し、要件が複雑になるにつれてPatch関数やUpdateIf関数、さらにはPower Automateへとステップアップしていくのがおすすめです。

この記事が、あなたのPower Apps開発の一助となれば幸いです。