Power Appsデータ連携の最適解：Excelからの脱却とSharePointリスト徹底活用術（基本～応用編）

公開: 2026年8月14日 更新: 2026年8月13日
#ノーコード・ローコードツール

【はじめに】PowerAppsでのデータ連携、ExcelとSharePointリストどちらを選ぶべきか？

Power Appsでアプリを作成する際、最初の分岐点となるのが「データをどこに保存するか」という問題ですね。
Microsoft 365ライセンスの範囲内で利用できるデータソースとしては、Excel（OneDrive for Business）とSharePointリスト（Microsoft Lists）が二大候補となります。

結論から申し上げますと、個人のタスク管理やプロトタイプ作成であればExcelでも十分ですが、部署単位や全社で利用する業務アプリであれば、迷わずSharePointリストを選択すべきです。

Excelは「表計算ソフト」であり、データベースとして設計されていませんので、複数人が同時に書き込みを行った際のデータの整合性や、数千件を超えるデータの検索速度において、構造的な限界を持っています。
一方、SharePointリストは簡易的とはいえ「データベース」としての振る舞いを持ち、行レベルのセキュリティ設定や、大量データのクエリ処理（委任）に対応しています。

本記事では、現在Excelで運用しているアプリをSharePointリストへ移行したいと考えている方や、SharePointリストを使っているものの「ユーザー列の更新ができない」「委任の警告が消えない」といった具体的な実装課題に直面している方に向けて、実践的な解決策を提示します。
「基本編／実践編／応用編」「自動化編／上級編」と２段階に分け、今回は基本編～応用編について、解説します。

※Power Platformは機能アップデート（委任可能な関数の追加など）が頻繁に行われます。本記事は、執筆時点（2026年8月）での仕様に基づいています。

【徹底比較】Excel vs SharePointリスト、データソースとしての実力差

まずは、適切なデータソース選定に向け、それぞれの特性を正しく理解しておきましょう。
以下の比較表は、Power Appsのバックエンドとして利用した場合の主な違いをまとめたものです。

機能・特性Excel (OneDrive)SharePointリスト
同時編集（排他制御）× 弱い（ファイルロックが発生しやすい）◎ 強い（行単位での制御が可能）
データ容量・件数△ 行数が増えると極端に重くなる○ 数万件でもインデックス設定で対応可
委任（Delegation）× ほとんどの関数で委任不可◎ Filter, Sort, LookUp等で委任可能
セキュリティ× ファイル単位の権限設定のみ◎ リスト単位、アイテム単位で設定可
データ型△ 文字列、数値、日付のみ◎ ユーザー、参照、選択肢、画像など豊富
画像・添付ファイル× 直接扱えない（工夫が必要）◎ 標準機能でサポート

Excelをデータソースにするメリットと致命的なデメリット（排他制御）

Excelをデータソースにする最大のメリットは、「手軽さ」と「親しみやすさ」です。
既存の業務データをそのままアプリ化でき、データの修正もExcelを開いて直接編集できるため、開発のハードルは非常に低いです。

しかし、業務アプリとして運用する場合、「排他制御（ロック）」の問題が致命的なデメリットとなります。
Excelはファイルベースで管理されるため、誰かがExcelファイルを開いて編集している間、Power Appsからの書き込みがロックされ、エラーになる頻度が高いです。
また、Power Appsがデータにアクセスしている間、人間がExcelを開こうとすると「読み取り専用」になることもあります。これは、複数人が利用するアプリにおいては運用停止に直結するリスクです。

SharePointリストが「データベース」として優れている理由（委任・セキュリティ）

SharePointリストが優れている点は、「委任（Delegation）」と「セキュリティ」にあります。

委任とは、データの検索や並べ替えの処理をPower Apps側（端末側）ではなく、サーバー側（SharePoint側）に任せる機能です。
Excelではこの委任がほとんど効かないため、データが2000件を超えると検索結果が正しく表示されなくなります。

対してSharePointリストは、適切な関数を使えば大規模なデータセットでも正しく処理できます。
また、セキュリティ面でも、SharePointリストは「作成者のみが自分のデータを編集できる」といった高度なアクセス権限設定が可能です。
Excelではファイルへのアクセス権を与えると全データが見えてしまいますが、SharePointリストなら必要なデータだけをユーザーに見せることが可能です。

関連記事：Power Appsが重い・委任警告が出る？原因とエラー処理・高速化ガイド【2000件問題解決】

【基本編】PowerAppsとExcelを連携させる手順と注意点

まずは基本として、Excelをデータソースとして利用する場合の正しい手順と、初心者が必ずと言っていいほど遭遇するエラーの回避策を解説します。

Excelデータの準備：テーブル化とOneDriveへの配置

Power AppsはExcelのシートを直接読み込むことはできません。
データとして認識させるためには、Excel内で範囲を「テーブル」として定義する必要があります。

  • 1.Excelを開き、データ範囲を選択します。
  • 2.[挿入] タブから [テーブル] をクリックし、「先頭行をテーブルの見出しとして使用する」にチェックを入れて作成します。
  • 3.重要： [テーブル デザイン] タブで、テーブル名（例: tbl_ProductList）を分かりやすい名前に変更してください。デフォルトの テーブル1 のままだと、後で管理が困難になります。
  • 4.ファイルをOneDrive for Business（またはSharePointドキュメントライブラリ）に保存します。ローカルPC上のファイルには接続できません。

PowerAppsからの接続手順と「読み取り専用」エラーの回避策

Power Apps Studioを開き、[データの追加] > [Excel Online (Business)] コネクタを選択し、保存したファイルとテーブルを指定すれば接続は完了します。
ここでよくあるトラブルが、アプリからデータを更新しようとした際に発生する「変更しようとしているデータは読み取り専用です」というエラーです。この原因は主に2つあります。

  • 一意のID列が存在しない： Power Appsがレコードを特定するために必要な「一意のキー」がテーブルにない場合、更新ができません。Power Appsが自動的に __PowerAppsId__ という列をExcelに追加することがありますが、これが生成されていない、または破損している場合にエラーになります。
  • Excelファイルが開かれている： 誰か（または自分）がバックグラウンドでそのExcelファイルを開いていると、ロックがかかり更新できません。ブラウザでExcelを開いているタブがあれば、必ず閉じてください。

【実践編】SharePointリストとの連携とアプリ構築のベストプラクティス

次に、推奨されるSharePointリストとの連携手順です。
Excelからスムーズに移行する方法と、開発時にハマりやすい「列名」の罠について解説します。

ExcelデータからSharePointリストを素早く作成する方法

手動でSharePointリストの列を一つずつ作成するのは手間がかかります。
既存のExcelデータがある場合、それをインポートしてリストを自動生成するのが効率的です。

  • 1.SharePointサイトの「サイト コンテンツ」またはMicrosoft Listsアプリを開きます。
  • 2.[新規] > [リスト] を選択し、[Excel から] をクリックします。
  • 3.テーブル化されたExcelファイルをアップロードします。
  • 4.各列のデータ型（「1行テキスト」「数値」「日付と時刻」など）を確認・修正し、[作成] をクリックします。

この方法を使えば、数千件のデータも一瞬でSharePointリストに移行できます。
ただし、画像や添付ファイルは移行されないため、別途対応が必要です。

PowerAppsでの接続設定とギャラリーコントロールへのデータ表示

Power Appsでの接続はExcelと同様に簡単です。[データの追加] > [SharePoint] コネクタを選択し、サイトURLを入力して対象のリストを選択します。

データを表示するには、画面に「ギャラリー（縦）」コントロールを配置し、Items プロパティにリスト名（例: ProductList）を指定します。
ラベルコントロールの Text プロパティには ThisItem.タイトル や ThisItem.価格 のように記述することで、行ごとのデータを表示できます。

内部列名と表示名の違い：ハマりやすいポイントの解説

SharePointリスト連携で最もトラブルになりやすいのが、「内部列名」と「表示名」の不一致です。

  • 表示名： リストの設定画面やPower Appsの候補に出てくる名前（例: 商品名）。後から自由に変更可能。
  • 内部列名： リスト作成時にシステムが割り当てる固有の名前。一度作成すると変更不可。

特に注意が必要なのは、日本語で列を作成した場合です。
最初に「商品名」という列を作ると、内部列名は OData__x5546__x54c1__x540d_ のような複雑な文字列になります。これが原因で、ODataフィルターやPower Automateでの指定時にエラーが頻発します。

  • ベストプラクティス： 列を作成する際は、まず半角英数字（例: ProductTitle）で作成して保存し、その後に日本語（商品名）に名前を変更してください。こうすることで、内部列名は ProductTitle となり、開発時のトラブルを激減させることができます。

【応用編】Patch関数を極める！複雑なデータ型の更新テクニック

ここが本記事の核心です。
SubmitForm 関数を使えばフォームの更新は簡単ですが、より自由度の高いUIを作るために Patch 関数を使う場合、SharePoint特有の「複雑なデータ型」の更新で多くの開発者が躓きます。

SubmitFormとPatch関数の使い分け：自由度の高いUIを作るには

SubmitFormとは、編集フォームコントロールとセットで使う関数です。
設定が簡単でバリデーションも自動で行われますが、UIのデザインや動作に制約があります。

一方、Patch関数とは、任意のタイミングで、任意のデータを、任意の形式で更新できる強力な関数です。
「ボタンを押した瞬間にステータスだけを更新したい」「複数のリストを一括で更新したい」といった要件にはPatch関数が必須です。
しかし、SharePointの「ユーザー列」や「参照列」を更新するには、特殊なJSON形式（レコード型）を記述する必要があります。

コード解説：ユーザー列（Person）を更新するためのClaims設定とOData記述

SharePointリストの「ユーザーとグループ」列（Person列）は、単なるメールアドレスの文字列ではなく、Claims（クレーム）やDepartmentなどの情報を含むレコード型です。Patch関数で更新する場合、以下のような記述が必要です。

シナリオ： 担当者（Person列）を、現在ログインしているユーザーで更新する。

Patch(
    案件管理リスト,
    LookUp(案件管理リスト, ID = ThisItem.ID),
    {
        担当者: {
            '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedUser",
            Claims: "i:0#.f|membership|" & User().Email,
            Department: "",
            DisplayName: User().FullName,
            Email: User().Email,
            JobTitle: "",
            Picture: ""
        }
    }
)

重要なポイント：

  • ‘@odata.type’ の指定が必須です。これがないと型不一致のエラーになります。
  • Claims には “i:0#.f|membership|” というプレフィックスが必要です（Microsoft 365環境の場合）。
  • Department や JobTitle は空文字でも構いませんが、プロパティ自体は記述しておくのが安全です。

※Claimsの形式について：「i:0#.f|membership|」一般的な組織アカウント（M365）環境ではこの形式ですが、ゲストユーザー（B2B）環境など一部特殊な構成では環境によっては異なる場合があります。

コード解説：参照列（Lookup）と選択肢列の正しい更新ロジック

参照列（Lookup）も同様にレコード型です。参照先のリストの ID と Value（参照されている列の値）を指定する必要があります。

シナリオ： 部署参照（参照列）を、コンボボックス（ComboBox1）で選択された値で更新する。

Patch(
    社員名簿,
    Defaults(社員名簿),
    {
        部署参照: {
            '@odata.type': "#Microsoft.Azure.Connectors.SharePoint.SPListExpandedReference",
            Id: ComboBox1.Selected.ID,
            Value: ComboBox1.Selected.Title
        }
    }
)

選択肢列（Choice）の場合も、単なるテキストではなくレコードとして渡す必要がある場合があります（特に複数選択可能な場合）。

Patch(
    ...
    {
        ステータス: {
            Value: "対応中"
        }
    }
)

単純なテキストとして 「ステータス: “対応中”」 と書いても動く場合がありますが、バックグラウンドの処理によってはエラーになるため、{ Value: … } の形式を推奨します。

新規作成（Defaults）と既存更新（LookUp）を条件分岐でスマートに実装する

Patch関数の第2引数によって、新規作成か更新かが決まります。

  • 新規作成： Defaults(リスト名)
  • 既存更新： レコードそのもの（例: LookUp(…) や ThisItem）

これらを If 関数で分岐させることで、一つの保存ボタンで「新規・更新」を兼ねるロジックが組めます。

Patch(
    商品リスト,
    If(
        IsBlank(varSelectedRecord), // 変数が空なら新規
        Defaults(商品リスト),
        varSelectedRecord           // 空でなければそのレコードを更新
    ),
    {
        商品名: TextInput_Name.Text,
        単価: Value(TextInput_Price.Text)
    }
)

【まとめ】定義から実装まで、失敗しないデータ連携のために

Power AppsとExcel、SharePointリストの連携は、ローコード開発の基礎でありながら、奥が深いテーマですよね。
手軽なExcelからスタートし、アプリの成長に合わせてSharePointリストへ移行し、最終的にはPatch関数やPower Automateを駆使して複雑な要件を実現する。
このステップアップこそが、Power Apps開発者としての成長プロセスそのものです。

特に「委任」と「複雑なデータ型の更新」は、多くの開発者が一度は躓くポイントですが、本記事で紹介したテクニックを理解していれば恐れることはなく、適切なデータ設計とロジックで、ユーザーにとって使いやすく、運用管理者にとっても安心できる堅牢なアプリを構築しましょう。

この記事を通じて、PowerAppsとExcel・SharePointリストを組み合わせた円滑なデータ連携が実現できれば幸いです。

万が一、自社でのトラブル対応や実装が困難な場合には、ぜひハイペリオンまでお気軽にお問い合わせください。

記事を探す

Search keywords

サービスから探す

# CRM・BI # Webシステム # ノーコード・
ローコードツール # モバイルアプリ

業界から探す

# 製薬業 # 製造業・化学工業

ナレッジ

その他事例

資料ダウンロード

DXやデータ活用の実践に役立つ資料をご用意しております。
お気軽にダウンロードください。

ダウンロードする

お問い合わせ・ご相談

「課題はあるけど、何から着手すれば良いかわからない」など、
どうぞお気軽にお問い合わせください。

お問い合わせする