「Create a canvas app with data from a list – Power Apps」は、Microsoft ListsまたはSharePoint Onlineのリストを元に、Power Appsのキャンバスアプリを作成する公式手順です。2026年5月21日時点で実務上の結論を先に言うと、SharePointリストからアプリを作る仕組み自体に大きな機能変更は確認できません。既存のSharePointリストやPower Appsを急いで移行する必要はありませんが、管理者はライセンス、DLPポリシー、環境、共有権限、委任の影響を確認しておくべきです。MicrosoftDocsの更新履歴では2026年5月20日に該当ファイルへ1行の更新があり、差分は導入文の英語表現修正にとどまっています。(GitHub)
Create a canvas app with data from a list – Power Appsとは
「Create a canvas app with data from a list – Power Apps」は、Microsoft ListsまたはSharePointのデータを使って、モバイルやWebで使えるキャンバスアプリを作成する手順を説明したMicrosoft Learnの公式ドキュメントです。リストをデータソースとして接続し、閲覧、詳細表示、編集の3画面を持つアプリをPower Apps Studioで生成する流れが中心です。(Microsoft Learn)
ポイントは、SharePointリストを「単なる一覧表」ではなく、業務アプリのデータ基盤として使えることです。たとえば、備品申請、問い合わせ管理、承認前の依頼一覧、棚卸し記録、社内FAQの登録画面など、Excelで管理しがちな小規模業務をPower Apps化しやすくなります。
公式手順では、アプリの作成方法として次の2つが示されています。1つ目はPower Appsにサインインし、「Start with data」からSharePointを選んでリストへ接続する方法です。2つ目はSharePointまたはMicrosoft Listsのリスト画面から「Integrate > Power Apps > Create an app」を選ぶ方法です。(Microsoft Learn)
| 作成方法 | 向いているケース | 注意点 |
|---|---|---|
| Power AppsからSharePointリストを選ぶ | 複数のデータソースや画面設計を意識して作り始めたい場合 | 最初に接続先サイトURLや最近使ったサイトを選ぶ |
| SharePoint / Microsoft Listsのリスト画面から作る | 既存リストをすばやくアプリ化したい場合 | リスト設計が未整理だと、生成後の修正が増える |
| 既存アプリにSharePointリストを追加する | すでにあるアプリに一覧・申請・マスターを追加したい場合 | データ型、権限、委任の確認が必要 |
今回の変更点は「機能追加」ではなく手順確認の意味合いが強い
2026年5月21日時点で確認すべき変更点は、Power AppsやSharePoint Onlineの新機能追加というより、公式手順の記述を最新の画面・表現に合わせて読むことです。MicrosoftDocsの履歴では、2026年5月20日のコミットで「no coding required」に関する導入文の表現が1行修正されています。画面遷移、作成方法、生成される3画面、保存・公開の流れは大きく変わっていません。(GitHub)
管理者や開発者にとって重要なのは、「リストから簡単にアプリを作れる」こと自体ではありません。重要なのは、誰が作れるのか、どの環境に作るのか、誰に共有されるのか、SharePointリストの権限とPower Appsの共有が一致しているのかを確認することです。
| 確認項目 | 公式情報で分かること | 実務上の判断 |
|---|---|---|
| 対象データ | Microsoft ListsまたはSharePointのリストデータ | SharePoint Onlineリスト運用が主対象 |
| 作成ルート | Power Appsから作成、またはリスト画面から直接作成 | 現場ユーザーでも作成しやすい |
| 生成画面 | 閲覧、詳細、編集の3画面 | そのまま本番利用せず、入力検証や権限設計を追加する |
| データ更新 | アプリで追加・編集するとリスト側も更新される | アプリとリストを別物として扱わない |
| オンプレミスSharePoint | データゲートウェイ経由で接続可能 | ライセンスとゲートウェイ管理が別途必要 |
SharePoint / OneDrive管理者が受ける影響
今回の公式情報の主対象はSharePointリストとMicrosoft Listsです。OneDrive上のExcelファイルからアプリを作る話ではありません。ただし、Power Apps全体の運用ではOneDrive for Business上のExcelファイルをデータソースにするケースもあるため、SharePoint / OneDrive管理者は「アプリ共有」と「元データ共有」を分けて考える必要があります。
Power Appsのアプリを共有しても、接続先データへの権限が自動的に適切になるとは限りません。Microsoftの共有手順では、アプリがOneDrive for Business上のExcelファイルなど外部データソースを使う場合、そのデータソースも利用者に共有する必要があるとされています。SharePointリストでも同じ考え方で、アプリ利用者にリストの読み取り・編集権限がなければ、アプリ側で期待どおりに操作できません。(Microsoft Learn)
管理者が最初に見るべき設定
| 項目 | 確認する理由 | 実務アクション |
|---|---|---|
| Power Appsの利用権 | ユーザーがアプリを作成・実行できるかを左右する | Microsoft 365に含まれるPower Apps権利と追加ライセンスの要否を確認 |
| 環境 | アプリが既定環境に乱立すると管理しにくい | 開発、検証、本番の環境方針を決める |
| Environment Makerロール | キャンバスアプリ作成に必要 | 作成者に必要なロールだけを付与する |
| DLPポリシー | SharePointデータが外部サービスへ流れるリスクを抑える | SharePoint、OneDrive、Outlook、外部コネクタの分類を確認 |
| 共有範囲 | アプリの過剰共有を防ぐ | 大人数共有ではセキュリティグループを使う |
| 元データの権限 | アプリ共有だけではデータ権限が不足する場合がある | SharePointリスト、サイト、OneDriveファイルの権限を確認 |
| オンプレミス接続 | ゲートウェイ利用時は追加の管理が必要 | ゲートウェイ管理者、接続、ライセンスを確認 |
Power Apps for Microsoft 365では、Microsoft 365データへの接続、標準コネクタの利用、ブラウザーやモバイルでの実行、データポリシーのサポートなどが含まれます。一方、オンプレミスデータ、プレミアムコネクタ、カスタムコネクタを使う場合は、より上位のPower Appsライセンスが必要になる場合があります。(Microsoft Learn)
DLPポリシーで確認すべきポイント
SharePointリストからPower Appsを作ると、SharePointコネクタが使われます。SharePointコネクタはPower Appsで利用できる標準コネクタとして扱われ、SharePoint OnlineやオンプレミスSharePoint 2016 / 2019への接続に対応しています。(Microsoft Learn)
ただし、標準コネクタだからといって無条件に許可してよいわけではありません。Power Platformのデータポリシーは、コネクタを制御して組織データの意図しない外部流出を抑えるための仕組みです。ポリシーでコネクタの組み合わせを禁止したり、ブロックしたりすると、アプリ作成時だけでなく実行時にも影響が出る可能性があります。(Microsoft Learn)
実務では、SharePointを「Business」側に分類し、SNS、個人向けストレージ、外部通知サービスなどと不用意に組み合わせられないようにするのが基本です。例外申請が必要な業務アプリは、専用環境を用意し、その環境だけに必要なコネクタを許可するほうが管理しやすくなります。
開発者・作成者が注意すべきリスト設計
SharePointリストからキャンバスアプリを自動生成すると、すぐに動くアプリができます。しかし、生成されたアプリは完成品というより、業務アプリのたたき台です。公開前に、列設計、入力チェック、検索、表示速度、委任、権限を必ず確認してください。
特に注意したいのは列名です。Power Appsでは、SharePointやExcelの列名にスペースが含まれる場合、数式内ではスペースが _x0020_ に置き換えられて表示されることがあります。たとえば「Employee Name」は、数式上で Employee_x0020_Name のように扱われる場合があります。後から数式を修正する開発者にとって読みづらくなるため、初期設計では列の内部名をシンプルにしておくと運用が楽になります。(Microsoft Learn)
自動生成前に整えておきたい列
| 列の種類 | おすすめの使い方 | 失敗しやすいポイント |
|---|---|---|
| 1行テキスト | 件名、管理番号、担当者メモ | 長文入力に使うと画面が読みにくい |
| 選択肢 | ステータス、分類、承認結果 | 選択肢を増やしすぎると検索・集計が難しい |
| 日付 | 申請日、期限、完了日 | タイムゾーンや未入力時の扱いを決めておく |
| ユーザー | 申請者、担当者、承認者 | 表示名とメールアドレスのどちらで判定するか決める |
| 数値 | 数量、金額、優先度 | 文字列として保存すると並べ替えで崩れる |
| 複数行テキスト | 理由、詳細説明、対応履歴 | 履歴管理が必要なら別リスト化も検討する |
大きなリストでは委任を必ず確認する
SharePointリストをPower Appsのデータソースにする場合、最も見落とされやすいのが委任です。Power Appsで委任できない数式を使うと、既定ではデータソースの最初の500件だけを取得してからアプリ内で処理します。設定で最大2,000件まで増やせますが、データ件数がそれを超えると、検索や絞り込みの結果が不正確になる可能性があります。(Microsoft Learn)
たとえば、10,000件の申請リストで「未処理だけを表示」する画面を作ったとします。数式が委任できない場合、Power Appsは10,000件全体から未処理を探すのではなく、最初に取得した500件または2,000件の中だけで処理する可能性があります。画面上は動いているように見えても、実際には一部の申請が表示されないという危険があります。
SharePointに対しては、データ型によって委任できる操作が異なります。公式情報では、Filter、Lookup、Sort、SortByColumns、StartsWithなどの扱いがデータ型ごとに示されています。特に検索画面を作る場合は、Power Apps Studioの委任警告を見ながら、委任可能な関数と列を使っているか確認してください。(Microsoft Learn)
委任で失敗しやすい例
| やりたいこと | 危険な作り方 | 改善の考え方 |
|---|---|---|
| 部分一致検索 | 非委任の検索式を大規模リストに使う | 前方一致や選択肢フィルターに寄せる |
| ステータス絞り込み | 複雑な条件をアプリ側で処理する | SharePoint側の列設計とビューで絞りやすくする |
| 最新順表示 | 取得後にローカルで並べ替える | 委任可能なSort / SortByColumnsを使う |
| 担当者検索 | 表示名、メール、ユーザー列を混在させる | 判定に使うサブフィールドを統一する |
| 一括更新 | UpdateIf / RemoveIfを大規模リストにそのまま使う | 対象件数を限定し、処理結果を検証する |
作成手順：SharePointリストからキャンバスアプリを作る流れ
Power Appsから作る場合は、まずSharePointリストを準備します。公式例では、デバイス注文を追跡するリストとして、従業員名、デバイスタイプ、申請日、理由、承認または拒否、ステータスなどの列が示されています。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | SharePointまたはMicrosoft Listsでリストを作成 | 列名、データ型、必須項目を先に決める |
| 2 | Power Appsにサインイン | 正しい環境を選んでいるか確認 |
| 3 | ホーム画面で「Start with data」を選択 | 新規アプリの作成ルートを確認 |
| 4 | 「SharePoint」を選択 | 接続先がSharePointリストであることを確認 |
| 5 | SharePoint URLまたは最近使ったサイトを選ぶ | 誤ったサイトに接続しないよう注意 |
| 6 | 対象リストを選び「Create app」 | サンプルではなく本番リストを選んでいるか確認 |
| 7 | Power Apps Studioでプレビュー | 閲覧、詳細、編集画面を確認 |
| 8 | 保存して公開 | 公開後に利用者へ共有 |
リスト画面から直接作る場合は、SharePointまたはMicrosoft Listsでリストを開き、「Integrate > Power Apps > Create an app」を選びます。SharePointからリストを開くとMicrosoft Listsへ移動して表示されますが、リストはSharePointとMicrosoft Listsの両方で利用可能です。これはデータが別物に移行されるという意味ではなく、リスト体験の入口がMicrosoft Lists側に寄っていると理解するとよいでしょう。(Microsoft Learn)
共有時は「アプリ」と「データソース」を分けて考える
Power Appsで作ったアプリは、保存して公開しただけでは組織内の全員が適切に使えるわけではありません。利用者へアプリを共有し、必要に応じてデータソース側の権限も付与する必要があります。
大人数に共有する場合、Microsoftは100人を超えるユーザーに共有するときはセキュリティグループの利用を推奨しています。また、アプリにプレミアムコンポーネントが含まれる場合は利用者にPower Appsライセンスが必要になることがあります。(Microsoft Learn)
SharePointリストアプリの場合、次の3点をセットで確認してください。
| 確認対象 | 確認内容 |
|---|---|
| Power Appsの共有 | 利用者またはセキュリティグループにアプリが共有されているか |
| SharePointリストの権限 | 利用者が必要な読み取り・投稿・編集権限を持つか |
| 接続とDLP | 利用するコネクタが環境のデータポリシーに違反していないか |
よくある失敗は、アプリだけを共有して、SharePointリストの権限を忘れることです。この場合、アプリは起動できてもデータが表示されない、保存時にエラーが出る、特定ユーザーだけ編集できないといった問い合わせにつながります。
オンプレミスSharePointを使う場合の注意点
公式ページでは、データゲートウェイを使ってオンプレミスSharePointリストに接続できることも示されています。オンプレミスSharePointを使う場合は、SharePoint Onlineリストよりも確認項目が増えます。(Microsoft Learn)
オンプレミスデータゲートウェイは、クラウドのPower Appsとオンプレミスのデータソースをつなぐために使われます。Microsoftのゲートウェイ管理ドキュメントでは、ゲートウェイ管理権限と、オンプレミスデータアクセスをサポートするライセンスが前提として示されています。(Microsoft Learn)
| 確認項目 | 内容 |
|---|---|
| ゲートウェイの所有者 | 退職者や異動者の個人管理になっていないか |
| 認証方式 | Windows認証やドメイン形式の資格情報を正しく管理しているか |
| 可用性 | 業務時間中にゲートウェイPCやサーバーが停止しないか |
| ライセンス | オンプレミスデータ利用に必要なPower Appsライセンスを満たすか |
| ネットワーク | ファイアウォール、プロキシ、名前解決が安定しているか |
小規模な検証なら動くだけで十分に見えるかもしれません。しかし本番運用では、ゲートウェイの停止がアプリ停止に直結します。申請、棚卸し、問い合わせ管理など日次業務に使う場合は、ゲートウェイの運用責任者を明確にしておくべきです。
移行・展開で確認すべきポイント
今回の公式情報を理由に、既存のSharePointリストアプリをすぐ移行する必要はありません。ただし、これからSharePointリストを使ったPower Appsを展開するなら、最初から開発、検証、本番を分ける設計にしておくと後の手戻りを減らせます。
Power Platformでは、環境がアプリやデータの境界になります。Microsoftの環境戦略ガイダンスでも、組織規模でPower Platformを採用するには、環境戦略が管理性とセキュリティの土台になると説明されています。既定環境に業務アプリを作り続けると、所有者、共有範囲、DLP、不要アプリの棚卸しが難しくなります。(Microsoft Learn)
キャンバスアプリの移行にはパッケージのエクスポート・インポートも使えますが、MicrosoftはALMを適切に管理するにはソリューションの利用を推奨しています。パッケージでは接続そのものはエクスポートされず、インポート先で接続を作り直す必要があります。また、既存アプリを更新した場合は、変更をユーザーに反映するために公開が必要です。(Microsoft Learn)
展開前チェックリスト
| フェーズ | 確認すること |
|---|---|
| 開発前 | 対象リスト、列設計、データ件数、利用者数を確認 |
| 開発中 | 委任警告、入力チェック、エラー処理、画面表示速度を確認 |
| 検証 | 一般ユーザー権限で起動・閲覧・編集・保存を確認 |
| 展開 | アプリ共有、SharePoint権限、DLP、ライセンスを確認 |
| 運用 | 所有者、問い合わせ窓口、変更履歴、バックアップ方針を決める |
| 改修 | 検証環境で修正し、公開手順を定型化する |
組織的にPower Appsを増やす場合は、Power Platformのパイプラインも検討できます。Microsoftは、Power Platformパイプラインを、管理者、作成者、開発者がより扱いやすくALMやCI/CDを実現する仕組みとして説明しています。(Microsoft Learn)
OneDrive利用者が混同しやすいポイント
SharePoint / OneDrive管理者の現場では、「リストから作るPower Apps」と「OneDrive上のExcelから作るPower Apps」が混同されることがあります。今回の「Create a canvas app with data from a list – Power Apps」は、Microsoft ListsまたはSharePointリストが中心です。
OneDrive上のExcelをデータソースにする場合、リストとは違ってファイルの共有、テーブル形式、同時編集、ファイル移動、所有者変更の影響を受けやすくなります。小規模な検証ならExcelでも始めやすいですが、複数人で継続的に登録・更新する業務では、SharePointリストやDataverseのほうが管理しやすいケースが多くあります。
判断基準はシンプルです。
| 業務の状態 | 向いているデータソース |
|---|---|
| 数人で試すだけ | OneDrive上のExcelでも可 |
| 部署内で申請・管理する | SharePointリスト / Microsoft Lists |
| 権限、履歴、業務ロジックが複雑 | Dataverseを検討 |
| オフラインや大規模データが重要 | Dataverseや専用設計を検討 |
すぐに取るべき対応
管理者は、まずPower Platform管理センターでDLPポリシーと環境方針を確認してください。SharePointリストを使うアプリが既定環境に集中している場合は、棚卸しを行い、業務アプリは専用環境へ分ける方針を検討します。
開発者や作成者は、リストから自動生成したアプリをそのまま本番公開せず、委任警告、入力チェック、リスト権限、共有設定を確認してください。特に500件を超えるリストでは、検索・絞り込みの結果が正しいかを実データに近い件数で検証することが重要です。
SharePoint / OneDrive担当者は、アプリ共有とデータ共有を同じものとして扱わないことが大切です。Power Appsは業務アプリの入口であり、SharePointリストやOneDriveファイルはデータの実体です。両方の権限、ライセンス、DLPをそろえて初めて、現場で安定して使えるアプリになります。
今回の公式情報は、SharePointリストからPower Appsキャンバスアプリを作る基本手順を再確認するよいタイミングです。新機能への追随よりも、環境、権限、DLP、委任、展開手順を整えることが、管理者と開発者にとって最も実務的な対応です。
コメント