クラウドはWebの延長か、それとも別のアーキテクチャか 〜MSAPPファイルを手がかりに考える〜
以前の記事で、Power AppsにおけるアプリはひとつのMSAPPファイルがリソース単位となっており、Webページのように画面ごとにURIを持つわけではない、という内容を書きました。
今回はそこからもう一歩踏み込み、MSAPPファイルの内部構造を見ながら、クラウドにおけるアーキテクチャがWebの延長線上にあるのか、それとも異なる思想を持っているのかを考えてみたいと思います。
MSAPPファイルの内部構造
Power Appsで作成したアプリは、ひとつのMSAPPファイルとしてまとめられます。
このファイルを.msapp形式からzip形式にして解凍すると、その中身には多くのファイルが存在し、さらにその中には、画面の情報が記載されている複数のjsonファイルやymlファイルがあります。つまり、ユーザーがアプリ上で作成する「画面」と、内部的に保持されるファイルは一対一に対応しています。
※↑msappファイル。これが 1 つのアプリに関するデータを保持しています。
※↑msappをフォルダ化して、そのフォルダを見ると、Controlsフォルダと呼ばれるフォルダがあります。これらはその中身です。1.jsonはApp（アプリの設定）で、4.jsonは画面1、63.jsonは画面2、76.jsonは画面3の情報を持っています。
しかし重要なのは、これらのjsonファイルがそのまま単体でリクエスト・レスポンスの単位になっているわけではないという点です。
アプリはjsonファイルそれぞれのページごとに分割したままでは実行されず、サーバー側ではそれらを含む一つの「MSAPPファイル」として統合的に解釈され、コンパイルされたうえで、クライアントに送信されます。
クライアントはそれを受け取り、Power Appsエンジンと呼ばれる、クライアントの中のクライアントを通してレンダリングすることで編集画面や再生画面を表示する仕組みになっています。
RESTとの比較
ここでWebの世界を振り返ってみましょう。
WebはRESTに基づいたアーキテクチャであり、基本は「クライアントがURIでリソースを指定してリクエストし、サーバーがハイパーメディアをレスポンスとして返す」というシンプルな枠組みです。
URIがリソースを一意に表し、HTTPという実装手段によってやりとりが行われます。リクエストとレスポンスの関係は単純明快で、クライアントとサーバーの役割分担も明確です。
一方、Power AppsのMSAPPファイルを基盤とした仕組みは、RESTの思想とは大きく異なる部分があります。
画面ごとにURIを割り当てるのではなく、アプリ全体がひとつのパッケージ（リソース）として扱われ、そのパッケージを解析・レンダリングするのはサーバーとクライアント双方の役割にまたがります。つまり、単純な「リクエスト1件＝レスポンス1件＝リソース1件」という構造が成り立たないのです。
コンソールでページの構成を覗いてみると、このページの中でMSAPPファイル（あるいは、それがサーバー側でコンパイルされた状態のもの）のそれぞれをどのように解釈するのかを決めていそうな記述がいくつも見受けられました。
RPC的な要素の存在
この仕組みを見ていると、どこかRPC（Remote Procedure Call）的な雰囲気を感じます。
RPCでは、クライアントが「処理の呼び出し」をリクエストし、サーバーがその処理を実行して結果をクライアントに返します。つまり、リソースを直接送受信するのではなく、プロシージャ（手続き）を呼び出すイメージです。
Power Appsにおいても、MSAPPファイルを単純な「静的リソース」として取得しているわけではありません。サーバー側でのコンパイルや解釈を経て、Power Appsエンジンが理解できる形に変換されてからクライアントへ送信されます。その後、クライアントのエンジンがレンダリングを行うため、動的な手続き的要素が濃く、単なるREST的なリソース指向とは言い難い構造になっています。
クラウドにおける「エンジン」の存在
Webの世界では、クライアントはブラウザであり、ブラウザはサーバーから受け取ったリソースを解釈して表示する役割を担っていました。ブラウザはあくまで受け取ったリソースを解釈する「汎用クライアント」だったのです。
しかし、Power Appsの場合は少し事情が違います。ブラウザは単なる「フレーム」に過ぎず、実際の処理はその内部で動作するPower Appsエンジンが担います。このエンジンは、MSAPPファイルを解析し、画面を再現し、ユーザー操作を処理します。つまり、Webにおけるブラウザよりもはるかに高度な役割を持った「クラウド用クライアント」として機能しています。
この点は、クラウドにおけるアーキテクチャを理解する上で非常に重要です。クラウドでは、単にリソースを受け取って表示するだけでなく、クライアント自身がある種の実行環境やランタイムを備えているのです。
RESTの上に構築された新しいレイヤー
とはいえ、Power Appsが完全にRESTを否定しているわけではありません。
実際には、データの送受信にはHTTPが使われていますし、内部的なAPI呼び出しもREST的なエンドポイントを通じて行われています。例えば、SharePointのデータを取得するときには_api/web/...のようなRESTエンドポイントを叩いています。ここでは確かにRESTの思想が息づいています。
ただし、その上に構築される「アプリケーションアーキテクチャ」はRESTの枠組みを超えており、パッケージの解釈やレンダリングといった処理を含む、より複雑な仕組みです。つまり、クラウドは「RESTという基盤の上に、新しいアーキテクチャを積み重ねたもの」と捉えられるのではないでしょうか。
Webからクラウドへ、アーキテクチャの変化
ここで見えてくるのは、クラウドは単なるWebの延長ではなく、Webを基盤として新しいアーキテクチャを発展させた存在 であるということです。
WebがシンプルなRESTに基づいて構築されたのに対し、クラウドはその上にアプリケーション実行環境やクライアントエンジンを組み込み、より高度な処理を分散して担うようになりました。
Web：URIとリソースを中心としたシンプルなやりとり
クラウド：REST/HTTPを土台に、コンパイル、レンダリング、エンジンによる処理を追加した複雑に機能を分担させたアーキテクチャ
この違いを意識すると、Power Appsのようなサービスを理解する手がかりになるだけでなく、今後のクラウド技術の進化を考える上でもヒントになるのではないかと思います。
おわりに
MSAPPファイルを手がかりに調べていくと、クラウドの仕組みはWebの延長線上にありながら、明らかに異なる特徴を持っていることがわかります。
Webの世界では、URIが示すリソースとHTTPのやりとりだけで完結していましたが、クラウドではさらに「エンジン」や「コンパイル済みのアプリ」というレイヤーが加わり、単純なリクエスト／レスポンスの世界を超えています。
つまり、クラウドは「Webに乗っかった別のアーキテクチャ」と言ってよいでしょう。
この視点を持つことで、Power Platformのようなサービスの仕組みをより深く理解できるのではないかと感じています。
ここまでお読みいただき、ありがとうございました！
この記事が少しでも参考になりましたら「スキ」を押していただけると幸いです！
株式会社分析屋について
弊社が作成を行いました分析レポートを、鎌倉市観光協会様HPに掲載いただきました。
ホームページはこちら。
noteでの会社紹介記事はこちら。
【すべての意思決定に人間らしさを】
分析屋は、「データ分析」と「おもてなし」を融合させた
「おもてなし分析」を提供するデータ分析集団です。
「おもてなし分析」によって、合理 (データ・ロジック) と 情理 (経験則・直感・想い・事情など) が共存し合う、合理一辺倒ではない成熟した社会の実現を目指しています。
【マーケティング】
マーケティング戦略上の目的に向けて、各種のデータ統合及び加工ならびにPDCAサイクル運用全般を支援や高度なデータ分析技術により複雑な課題解決に向けての分析サービスを提供いたします。
【システム】
アプリケーション開発やデータベース構築、WEBサイト構築、運用保守業務などお客様の問題やご要望に沿ってご支援いたします。
【ライフサイエンス】
機械学習や各種アルゴリズムなどの解析アルゴリズム開発サービスを提供いたします。過去には医療系のバイタルデータを扱った解析が主でしたが、今後はそれらで培った経験・技術を工業など他の分野の企業様の問題解決にも役立てていく方針です。
【SES】
SESサービスも行っております。
