
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関数は覚えるべきことが多いように見えますが、基本パターンを一度体で覚えれば、列型が変わっても「形式が違うだけ」と冷静に対処できます。社内の業務改善アプリを自分の手で作るという目標に向かって、一歩ずつ積み上げていきましょう。