本文へスキップ
NeoLogic
NeoLogic

試作できた点検画面、そのまま取引先に使ってもらえる?Power Appsを入れる前の確認

社員の申請、取引先の利用、圏外での点検を同じ要件表で比べます。利用者、端末、保存先、承認・帳票、ライセンス、保守担当を整理すると、既存機能で足りる範囲と専用Web開発を検討する条件が分かります。

点検アプリを社内、取引先、圏外で利用する条件の違い

Power Appsで業務アプリを作る前には、社外の人も使うか、圏外で使うか、どのデータへつなぐかの三つを確かめます。この三つで、既存機能で足りるか、Dataverseや別の方式が必要かが変わります。

たとえば、点検の受付画面を試作できたので、そのまま取引先にも使ってもらいたい。現場からは、電波が届かない場所でも入力したいという要望が出た。この段階では、画面に項目を追加する前に、利用条件を整理する必要があります。

三つの問いは次のとおりです。

  • 社外の人も使うか。指名した担当者の招待か、不特定の人に開く窓口か。
  • 圏外でも使うか。会社PCのブラウザーか、管理スマホのアプリか。
  • どのデータへつなぐか。既存のSharePointか、Dataverseか、外部システムか。

同じ点検受付でも、この条件で候補が変わります。以下は画面を自由に配置するキャンバスアプリを中心とした比較です(想定例)。公式仕様は2026年9月15日時点です。

点検受付の用途 最初に検討する案 選定を左右する条件
社員の申請 既存SharePointリストで運用し、不足する入力だけPower Appsで補う 申請者・承認者の利用権、差戻し後の状態
指名した取引先の利用 ゲスト共有とDataverseを比較 認証、他社データを見せない設定、利用権、外部API契約
圏外の点検 管理スマホのPower Apps MobileとDataverseを比較 ブラウザーは圏外不可。初回同期と再接続後の受付確認が必要

作った人の画面だけで、三用途を合格にしない

社員用の申請、取引先の受付、圏外の点検では、同じアプリでも確認する利用者と端末が変わります。作成者のアカウントで動いた後に、次の三場面を試用条件へ加えます。以下は実機試験の成績ではなく、導入前に埋める確認例です。

場面 試す人・条件 保存する結果
作成者が休み・退職した後 日常運用を引き継ぐ担当者が自分のアカウントで接続し、接続設定を更新する 申請、承認、帳票のどこまで継続できたか
取引先が一件だけ照会する 実際に予定する外部利用者と同じ契約・認証条件 他社の受付を探せないこと、必要な利用権と追加費用
圏外で写真を付け、再接続する 対象端末で保存後にアプリを閉じ、開き直してから送信 本文と写真の受領、重複、訂正競合、失敗時の再開方法

Microsoftの利用権FAQは、開発者向けの試用と本番利用、アプリとフローの権利を分けて確認する入口です(2026年10月26日確認)。現在持つMicrosoft 365の席数だけで三用途を見積もらず、使う人、接続先、フローの実行者を見積条件へ添えます。

圏外時は、訂正競合と写真IDの受領を分けた例を使い、「画面の送信済み表示」と「相手側に本文・写真がそろった結果」を別々に記録してください。採用する方式は、対象機でこの一連の操作を通した後に決めます。

3用途の保存先・利用権・保守担当を照合する

3用途の保存先・利用権・保守担当の記入例を見る

次の表は、製品にある機能と、自社の契約で使えるかを分けて書く記入例です。社員申請と取引先利用は「要契約確認」、圏外点検は「要実機確認」としています。圏外点検では、実機での動作と契約条件の両方を確かめます。

表1. 点検受付3用途の詳しい要件比較

比較項目 社員申請 取引先利用 圏外点検
利用者区分 社員(申請者・承認者) 指名した取引先担当者+社員の受付担当 社員の点検員
端末 会社PC/ブラウザー/常時接続 取引先PC/ブラウザー/常時接続 管理スマホ/Power Apps Mobile/圏外利用あり
データ保存先 SharePoint Onlineリスト Dataverse(候補) Dataverse+端末内データ
連携先 SharePoint/Standard approvals 外部受付API/カスタム接続の追加候補 端末内保存は同期待ち。再接続後に同期状態と受付側の記録を確認して引き継ぐ
機能区分 既存設定を優先。独自の入力画面は追加候補 ゲスト共有と権限を設定。APIは追加設計 オフライン機能を設定。同期失敗などの例外に対応
ライセンス根拠 対象Microsoft 365の権利と標準接続を照合(①②③) ゲストの利用権と、Dataverseと同じテナントでの割当てを確認(①④) Dataverseの利用権を確認。ブラウザーの圏外利用は不可(①⑤⑥⑦)
保守担当 業務責任者/Microsoft 365管理者 取引先窓口/環境管理者/連携担当 点検責任者/環境管理者/端末管理者
確認状態 要契約確認 要契約確認 要実機確認
次の確認・確定条件 契約・リスト権限・差戻し後の状態を確認する 認証・他社データの非公開・API契約を確認する 初回同期・再送・競合・紛失時の手順と、受付側記録の確認方法

表の出典:①Power Platform licensing FAQs、②SharePoint - Connectors、③Standard approvals - Connectors、④Share a canvas app with guest users、⑤Work with canvas apps offline、⑥Develop offline-capable canvas apps、⑦Set up mobile offline for canvas apps

Standard/Premiumは接続のライセンス分類です。「機能区分」は本稿の作業区分です。保守担当はいずれも役割案です。

記入用XLSXには、同じ列の記入例と未記入版、読み比べ用の掲載表、出典を収録しています。未記入版では自社の条件を一行ずつ書き、根拠URLと適用条件、確認者、確認日を残してください。空欄や「たぶん使える」を「条件確認済」に置き換えず、機能・契約・権限・運用の確認がそろってから状態を更新します。

社員・取引先・圏外利用で、必要な条件は変わる

社外利用は「誰がログインするか」まで決める

申請者だけでなく、承認者、閲覧者、管理者も利用者として書き出します。社員申請は社員の申請と承認を会社PCで行う想定です。取引先利用では、取引先ごとの担当者を招待して使うのか、不特定の人がアクセスする公開窓口なのかを先に分けます。

キャンバスアプリのゲスト利用はMicrosoft Entra IDでの認証を前提とし、アプリの共有とは別に、接続先データへのアクセス権も必要です。独立したアプリの利用権を、SharePointのカスタムフォームの条件と混同しないでください。取引先利用は指名した担当者を招待する案とし、他社の受付情報が見えないことを確認項目に残します(出典:Microsoft「Share a canvas app with guest users」)。

圏外での入力と受付完了は別の状態にする

キャンバスアプリのオフライン利用は、iOS・Android・WindowsのネイティブなPower Apps Mobileが対象です。モバイル端末でも、Webブラウザーで動くキャンバスアプリは圏外で使えません。圏外点検は管理スマホ上のPower Apps Mobileを前提にします(出典:Microsoft「Develop offline-capable canvas apps」)。

オフライン対応として設計したアプリでも、必要データの初回同期を終える準備が必要です。圏外点検では、出発前に初回同期、現場で端末内に保存、再接続後に同期状態と受付側の記録を確認、という順にします。「同期待ち」やエラーを「受付完了」と扱わないための運用案です。承認は、同期後に担当者が内容を確かめてから進めます(出典:Microsoft「Work with canvas apps offline」)。

既存リストで足りる条件と、業務データを保存・関連付けるDataverseを比べる条件

社員申請のように、受付日・設備名・依頼内容・処理状態を社内で管理するなら、まず既存のSharePoint Onlineリストと運用で足りるかを見ます。入力、一覧、権限、承認後の記録まで不足なく回せるなら、専用画面を作らずに運用を整える案も残せます。SharePointコネクタの契約条件は、「利用する人と処理から、契約を確かめる」の表で照合します(出典:Microsoft「SharePoint - Connectors」)。

設備・点検・取引先などの関連を持たせ、利用者ごとの操作や閲覧範囲を細かく設計するなら、Dataverseも比較します。Dataverseにはテーブル間の関連、業務ルール、行や列を含むアクセス制御の仕組みがあります。取引先利用では、参照・作成・更新などの権利と、対象レコードの範囲を設定して確かめます(出典:Microsoft「What is Microsoft Dataverse?」、Microsoft「Security roles and privileges for Dataverse」)。

比較条件は同じにします。保存する項目、添付ファイル、保存期間、閲覧・修正できる人、検索条件、データの取り出し方を先に書き、その条件でSharePointとDataverseを比べてください。アプリ画面で項目を隠すだけで、保存先のアクセス制御を済ませないことも確認点です(出典:Microsoft「Share a canvas app with your organization」)。

管理・実装担当者へ:容量、検索の取りこぼし、オフライン同期

容量は本文データと添付、履歴を分けて算出します。Dataverseはデータベース・ファイル・ログの使用量と権利を確認する仕組みです。また、検索処理を保存先に任せる「委任」ができない式では、取得範囲が限られ、結果を取りこぼすことがあります。保存できる容量と全件を正しく検索できることは別です。少量の試作データだけで判断せず、予定する検索条件でも確認します(出典:Microsoft「Dataverse capacity-based storage details」、Microsoft「Query limitations: Delegation and query limits」)。

圏外点検ではDataverseのオフライン機能を候補にします。対象テーブル、端末へ取得するデータの範囲、利用権限を設定する必要があります。SharePointなどDataverse以外で端末保存を作る場合は、再接続や競合の扱いを別に設計する前提で比べます。Dataverse for Teamsを選ぶ場合は、通常のDataverseとの利用範囲の違いも、「利用する人と処理から、契約を確かめる」の表で照らし合わせます(出典:Microsoft「Set up mobile offline for canvas apps」、Microsoft「Develop offline-capable canvas apps」、Microsoft「Power Platform licensing FAQs」)。

申請から承認・帳票まで、一件を通して考える

「承認ができるか」だけでなく、申請、差戻し、再申請、承認、受付担当への引継ぎまでを並べます。社員申請では、承認者が差し戻したときに受付状態も戻るか、申請を修正した後に何を再確認するかを決めます。承認通知を送れたことと、業務データが正しい状態になったことを分けて確認する運用案です。

標準コネクタでも、設定や契約の確認は残る

コネクタは、アプリやフローから別のサービスへ接続する部品です。公式資料では、SharePointとStandard approvalsはStandard、Word Online (Business)はPower Apps・Power AutomateでPremiumです。社内の承認に標準接続を使っていても、Wordテンプレートへ値を差し込む帳票処理を加えると、追加する処理の契約条件も確かめます(出典:Microsoft「SharePoint - Connectors」、Microsoft「Standard approvals - Connectors」、Microsoft「Word Online (Business) - Connectors」)。

ここでは「既存設定で対応」「Power Apps等で追加設定・開発」「別方式を比較」を、作業量を整理する区分として使います。これはライセンス上のStandard/Premiumとは別軸です。Standardでも、画面やフローの作成に必要な作業量を見積もる必要があります。Premiumについても、設定でできる範囲とコードを書く範囲を機能ごとに見ます。

外部APIへ渡す情報と、失敗後の対応を決める

取引先利用では外部受付APIとのカスタム接続を追加候補にしています。送る項目、認証方法、相手側の利用契約、失敗の通知先、再送しても重複登録しない方法を連携担当が確認します。APIの存在を、利用許可や開発完了の根拠にしません。Power Platform側のデータポリシーでコネクタが制限される場合もあるため、管理者の確認が必要です(出典:Microsoft「Data policies」)。

圏外点検では端末入力とオンラインの承認処理を分け、同期後に何をもって受付担当へ渡すかを決めます。

利用する人と処理から、契約を確かめる

契約名と、アプリが使う機能を対応させる

「Microsoft 365を契約している」だけで結論を出さず、実際の契約名、割り当てられた利用者、対象アプリ、保存先、コネクタ、フローの実行方法を管理者と照合します。Premium・カスタム接続や自社内のサーバー等との接続には追加の利用権確認が必要です。Developer Planで試作できたことも、本番利用の根拠にはなりません(出典:Microsoft「Power Platform licensing FAQs」)。

使い方 管理者と確認する契約条件
社員の申請・承認 申請者と承認者に割り当てたMicrosoft 365の権利、SharePoint・標準接続の範囲
指名した取引先の利用 ゲストに必要な利用権。Dataverseではデータを置く管理環境での割当て
圏外点検 Dataverseの利用権。端末の購入だけではアプリの利用権を満たさない
帳票・外部連携 Word Online (Business)のPremium接続、カスタム接続、相手サービスの契約
自動処理 アプリに関連するフローか、別目的の処理か。作成者・実行者とユーザー/容量ライセンスの対応

Power PlatformのライセンスFAQ、ゲスト共有の条件、Power Automateのライセンス区分で対象機能を照合します。料金は、契約経路と利用人数をそろえて比較します。

保守の役割と引き継ぐ担当者を決める

業務責任者は入力項目や承認ルール、環境管理者は利用権と接続許可、連携担当は再送や障害対応、端末管理者は持出しや紛失時の連絡を受け持つ、といった分担を書きます。同じ人が兼ねる場合も、担当が未定の仕事を残さないために役割を分けます。

アプリ、フロー、データ、接続には、それぞれ権限があります。所有者の異動時は、共有相手だけでなく、接続に使うアカウント、設定資料、障害通知先、引継ぎ後の動作を確認する対象にします。試作環境から本番へ移す際も、利用者と接続先を変えた状態で確認します(出典:Microsoft「Share a canvas app with your organization」、Microsoft「Data policies」)。

専用Webアプリも含めて、三つの用途を比べる

利用者が特定の取引先から不特定の人へ広がると、認証や契約の前提が変わります。認証付き・匿名のWeb利用を扱うPower Pagesや専用Webも候補に加え、公開する範囲に合う方式を比べます(出典:Microsoft「Share a canvas app with guest users」)。

比較では、対象人数と利用頻度、ログイン方法、他社データの分離、必須の画面操作、帳票、外部連携、圏外要件、保守と終了時のデータ取り出しをそろえます。標準の設定では満たしにくい処理がある場合は、Power Platform側で追加対応する範囲と、外部の処理基盤や専用Webへ分担する範囲を分けます。併用も可能性として残し、全部を作り直す前提にはしません。

社員申請は既存機能で足りれば追加開発を見送れます。取引先利用はゲスト利用の条件を満たすか、公開窓口の別方式が必要かを確認します。圏外点検はDataverseとPower Apps Mobileの条件、同期失敗時の扱いを確かめます。専用Webにも、圏外対応と保守を設計する仕事があります。その費用と担当まで含めて比べてください。Power Appsに限らず、Webアプリ、スマホアプリ、PWAのどれにするかは、利用端末と必要機能からの選び方で比べられます。

要件表に残った不明点を、業務責任者・契約管理者・開発保守担当に振り分けます。誰に何を確かめれば候補を選べるかが決まれば、次の相談も具体的になります。

利用期間や終了時の費用まで含めて方式を比べる際は、SaaS・パッケージ・独自開発|3年・5年の費用比較で、既製品や現状維持も含む判断軸を比べられます。

自社の利用者、保存先、連携先が整理でき、申請・承認・通知をどう追加するかが具体的になった段階では、「Power Apps・Power Automate開発相談」をご覧ください。未確認事項を残した要件表を使い、既存機能で運用する範囲と、追加開発する範囲を相談できます。

要件比較表(Excel) / 要件比較表(PDF)

圏外での入力と同期は、圏外での現場入力|端末保存と同期の確認項目で詳しく説明しています。

製品を選ぶ前に、試作後の権限・外部連携・継続費を開発方式ごとに比べることもできます(ノーコード・ローコード・独自開発の選び方)。

参考出典

以下はMicrosoft公式資料です(2026年9月15日時点)。

あわせて読む