こんにちは。システムソリューション営業本部の吾妻です。


Power Platformによるシステム構築の特長の1つとして、クロスプラットフォームなアプリを簡単につくれることが挙げられます。

Power Platform製品群の中でも、特にPower Pagesを用いることで、Android / iOS / Windows / Chromeの各OS、かつ、モバイル / デスクトップ / タブレットの各フォームファクターに対応したPWA（プログレッシブWebアプリ）を、簡単に実装することができます。

今回の記事では、この特長を活かしたアプリ化のサンプルとして、ファイル共有アプリを作ってみたのでご紹介したいと思います。

iOS vs Android

この記事をお読みの皆さんは、どのようなモバイルOSを利用されているでしょうか？一般的に、全世界ではiOSよりもAndroidが多く利用されており、日本国内では、AndroidよりもiOSが多く利用されていると言われています。

国内の状況について、例えばMMD研究所による「2025年法人向け携帯電話の利用実態調査」の結果を見てみると、以下のグラフのように、iPhoneが6割程度、残りがAndroid（ガラホも含む）やフィーチャーフォンとなっています。どちらかにシェアが偏ることなく、ほぼ拮抗している状態なので、幅広い利用者層にWebアプリケーションを使ってもらおうと思うと、双方で同等の機能、同等の操作性をサポートするように気を付ける必要があります。


（https://mmdlabo.jp/investigation/detail_2450.html よりグラフを引用）

モバイルOSのシェアが二分されているために生じる、ユーザー視点でのデメリットとして、異なるOSを利用している人同士でファイルを簡単に共有できないことが挙げられます。iOS同士の場合はAirDropが、Android同士の場合はQuick Share（旧Nearby Share）がOSの機能として用意されているので、簡単にファイルを共有することができますが、iOSとAndroidの間で送受信する機能は用意されていないので、サードパーティ製のアプリなどが必要になります（開発者視点でのデメリットはとても書き切れないので割愛します）。

QESの場合、社用スマートフォンの機種（とOS）は、全員統一されているのでこのような問題はありません。しかし、会社によっては、会社全体ではなく部署単位で管理していたり、全く管理しておらず1人ずつ異なる機種を利用していたりと、さまざまな機種が入り乱れている状況があるかと思います。

そこで今回は、異なるOSのスマートフォン同士で、AirDropやQuick Shareに近い操作性（手軽さ）でファイルを送り合うことができるアプリを実現する方法を、検討してみたいと思います。

Power Pagesとは

このように、異なるOS向け、異なるフォームファクター向けのWebアプリケーションを、共通のコードからひとまとまりで構築するためのローコード製品として、Power Pagesがあります。通常のネイティブアプリ開発の場合は、OSごとに、利用する開発環境やプログラミング言語が異なるため、iOS向けとAndroid向けのアプリを個別に開発しなければなりませんが、Power Pagesの場合は、Webの技術で開発して、作成したアプリはPWAとして公開することができるため、iOSでもAndroidでも同じ操作性で利用することができます（アプリストアで配布することもできます）。

Power Pagesの「デザインスタジオ」では、WYSIWYGでコンポーネントを追加していくことも、組み込みのVisual Studio Code for the WebでHTMLやCSS、JavaScript、Liquidなどのコードを記述することもできるので、画面を簡単に構築することができます。また、Dataverseテーブルに格納したデータをページに埋め込んだり、CRUD処理をさせたりすることができるので、データの管理はPower Appsのモデル駆動型アプリで行い、お客様に見せるUIはPower Pagesで用意する、といった使い分けが可能です。




以前は、Power Appsの一部であるPower Appsポータルとして提供されていましたが、2022年10月にPower Pagesにリブランディングされました。本ブログでは、Power Appsポータルだった頃のチュートリアルはこちらの連載で、Power Pagesの概要についてはこちらの記事で、それぞれご紹介していますので、併せてご覧ください。

作成するアプリの仕様

今回Power Pagesで作成するアプリの主な仕様は、以下のように設定したいと思います。

①送信者はサインインした状態で利用でき、受信者たち（複数人もあり）はアカウント認証など面倒な操作を求められることなく利用できること
②画像ファイルやPDFファイルなど、数MBから数十MB程度のバイナリファイルを、スマートフォン同士で送受信できること
③ファイルは、共有を開始してから一定期間経過したら自動的に削除されること
④QRコードなどの手段で、送信者が共有したいと思っている人だけがファイルを受信できること

また、全社で統一されている社用スマートフォンを使わずに、私物のスマートフォン同士でファイルを共有したいシナリオとして、飲み会やレクリエーションの後に写真を受け渡すために使うことを想定して話を進めたいと思います。つまり、酔っていても使えるくらい簡単で、意図しない相手にファイルを送ることがないように操作ミスが起きにくいUIが求められます。


上に挙げたそれぞれの要件を、より具体的に検討していきたいと思います。

①受信者が認証を求められない

Power Appsのキャンバスアプリやモデル駆動型アプリは、Microsoft 365テナントに所属している組織アカウント（ゲストユーザーも含む）でサインインした状態で利用することが前提の製品なので、この要件には適していません。一方で、Power Pagesは、組織外の利用者が認証ユーザーまたは匿名ユーザーとしてサイトにアクセスすることもできる製品なので、今回の要件にぴったりです。

認証ユーザーとは、Power PagesでつくられたサイトごとにID・パスワードを登録するローカルサインインで認証したり、Microsoftアカウント（組織用ではなく個人用のアカウント）やGoogleアカウントなどのOAuth認証プロバイダーで認証したりして、一意に区別できる状態でサイトにアクセスするユーザーを指します。

また、匿名ユーザーとは、Entra IDでも、ローカルサインイン・OAuthでも認証しない状態でサイトにアクセスするユーザーを指します。匿名ユーザーのカウントは、ブラウザのCookieに保管される匿名ユーザーIDを利用して行われるので、利用者がブラウザのCookieを消去したり、別のブラウザからアクセスしたりした場合には、匿名ユーザー数が多くカウントされ、余計に課金される可能性があります。匿名ユーザー数のカウントは月ごとに行われるため、同じ匿名ユーザーIDをもつ利用者が、サイトに1か月のうち何回アクセスしても、「1回」とカウントされます。

尚、今回のアプリでは、不特定多数の人々にファイルアップロードをさせることは想定していないので、送信者については、Entra IDでサインインした状態で利用することを前提として、キャンバスアプリまたはモデル駆動型アプリからDataverseテーブルにアクセスさせることにします。

②画像ファイルなどのバイナリファイルを格納できる

Dataverseのファイル列では、既定で32768KB（32MB）、設定を変更すれば128MBまでのファイルをアップロードすることができるので、ファイルアップロード用にDataverseテーブルを用意して、そこにファイル列を作成して、格納することにします。
（設定変更をした場合の上限は10GBですが、モデル駆動型アプリなどのコントロールで直接アップロードすることはできず、Dataverse Web APIでチャンクに分けて送る必要があり、チャンクの上限が128MBです）

ファイル列の制約として、ファイルサイズだけでなく、ファイルの種類についても確認しておく必要があります。アップロードしようとしたファイルの拡張子またはMIMEタイプが、環境で設定されているブラックリスト／ホワイトリストの項目と一致するかチェックされます（拡張子はブラックリストのみ設定できます）。

Teams会議の録画などでサイズがGBオーダーのファイルや、exeファイルなどのリスクが高い種類のファイルをアップロードしたい場合は、Azureのサービス（BLOBストレージなど）に格納することも検討すると良いと思います。

③共有を開始してから一定期間経過したらファイルが自動的に削除される

ファイルの共有を開始したあと、停止操作を行うまで共有を継続し続ける仕様にしてしまうと、意図した受信者以外にファイルが共有されてしまうリスクが増えてしまうので、必要最小限の時間だけファイルを保持して、不要になったファイルは速やかに削除する必要があります。

④受信者を制限する

参加者以外にファイルを共有しないように制限するために、GPSによる位置情報、音波通信の届く範囲、QRコードの読み取り、合い言葉（パスフレーズ）といった物理的な制約を利用します。受信者に認証を求めないという仕様があり、厳密に共有先を制限することはできないので、トレードオフのどの程度まで許容するか、検討する必要があります。

「酔っていても使えるくらいの簡単さ」という観点から、送信者がQRコードを表示して、受信者がQRコードを読み取る、という操作を採用します。後述しますが、Power Pagesでフォームに表示するレコードを切り替えるためのクエリ文字列では、テーブルの主キー（テーブル名と同じ名前のGUID列）が利用されます。そのため、QRコードにも主キーの値を含めることになります。

ここで、一点だけ懸念事項があり、Dataverseの主キー列に生成されるGUIDは、UUIDとは異なり、乱数を用いるのではなくシーケンシャルに振られるらしく、予測困難性が低いと考えられます。次に生成されるレコードのGUIDを推測しにくくするために、ランダムな個数の空のレコードを作成して、すぐ削除するようなクラウドフローを必要に応じて実行することを検討したほうが良いかもしれません。

構成例

先ほど定義したアプリ仕様をもとに、システム構成を考えていきたいと思います。



上の図に示すように、今回は、Power Apps、Power Automate、Power Pages、Dataverseの各製品を組み合わせて実現します。それぞれの役割は、以下の通りです。

・Power Apps（キャンバスアプリまたはモデル駆動型アプリ）
　…ファイルをアップロードするためのUIと、QRコード生成機能を提供する

・Power Automateクラウドフロー
　…Dataverseテーブルにレコードが作成された（＝ファイルがアップロードされた）ことをトリガーに起動され、「有効時間」が経過したあとにレコードを削除する

・Power Pages
　…ファイルをダウンロードするためのUIを提供する（Power PagesのページにアクセスするためのQRコード読み取りは、ブラウザに組み込まれている機能を活用するので独自実装はしない）


Power Pagesで行う主な設定事項も挙げておきます。

＜ホーム＞
・リスト / フォームへの導線をなくす

＜リスト＞
・匿名ユーザーが閲覧できないようにする（Dataverseレコードが列挙されてしまうと、意図しないファイルにアクセスできてしまうため）
・レコードの作成や編集、削除をできないようにする

＜フォーム＞
・読み取り専用にする
・CAPTCHAを非表示にする

＜テーブルのアクセス許可＞
・Webロール「匿名ユーザー」にグローバルアクセスのアクセス許可「読み取り」を付与する


また、これ以外にも、以下のコンポーネントも用意しておきます。