Power Platform でのアプリケーションの最新化

急速に進化する今日のデジタル環境において、組織は変化するビジネスニーズに対応するためにレガシー アプリケーションをモダナイズするという絶え間ない課題に直面しています。 アプリケーションのモダナイゼーションは、運用効率の向上、カスタマーエクスペリエンスの向上、競合他社の一歩先を行くためには不可欠です。 Microsoft Power Platform は、企業がアプリケーションを迅速かつ効果的に変換し、最新化する包括的なツールとテクノロジーを提供します。

このホワイト ペーパーでは、Microsoft Power Platform を使用してアプリケーションを最新化する利点、戦略、ベスト プラクティスについて説明します。 この資料では、組織のデジタル変革の一環として、Microsoft のローコード プラットフォームがアプリケーションのモダナイゼーションの取り組みを成功に導くためにどのように役立つかについての分析情報とガイダンスを提供しています。

チップ

ブラウザーで 印刷 を選択して PDF として保存 を選択することで、このホワイト ペーパーを保存または印刷できます。

概要

レガシーアプリケーションは、組織に多くの課題をもたらします。 これらのアプリケーションは、時代遅れのテクノロジー スタックやフレームワーク上に構築されていることが多く、最新のシステムやツールとの統合が困難です。 多くの場合、スケーラビリティとパフォーマンスの制限があり、組織が増加するワークロードと顧客の要求を処理する能力を妨げます。 レガシー アプリケーションは柔軟性と俊敏性に欠けており、変化するビジネスニーズや市場動向に迅速に適応する能力を制限しています。 セキュリティの脆弱性、高いメンテナンス コスト、限られた統合機能、ベンダー依存のリスクが、レガシーアプリケーションの課題をさらに悪化させています。 これらを克服するために、組織はアプリケーションのインフラストラクチャをモダナイズして新しいテクノロジーを活用する必要があります。

Microsoft Power Platform のローコード開発機能により、これまでよりも迅速かつコスト効率よく最新のアプリケーションを構築および展開できるようになります。 既存のシステムやデータソースを簡単に統合して、シームレスなデータ交換とコラボレーションを実現します。 人工知能を追加することで、ユーザー エクスペリエンスの向上、プロセスの自動化、データからの貴重な分岐情報の取得が可能になります。 さまざまな作業に追われている市民開発者でも、複雑なカスタマイズに取り組んでいるプロ開発者でも、従来のアプローチよりも直感的、迅速、低コストでデジタル トランスフォーメーションを推進できます。

なぜ Power Platform なのか？

Power Platform を構成する包括的なツールやテクノロジーは、モダナイゼーションやデジタル トランスフォーメーション プロジェクトの期間、コスト、開発要件を劇的に削減します。 そのローコード アプローチは、高価なコーディング、データサイエンス、AI エンジニアリング リソースの必要性を減らし、さらには排除することができます。 市民開発者もプロ開発者も同様の恩恵を受けます。 市民開発者は、その専門知識に基づいて直接アプリケーションを構築し、ITチームへの依存度を低減することで、モダナイズのプロセスに積極的に関与することができます。 プロの開発者は、複雑なソリューションでもはるかに短い時間で提供できるため、次のプロジェクトにすぐに進むことができます。

Power Platform 製品とコンセプト

Power Platform ファミリーの各製品には、独自の重点分野があります。 組織は、特定の要件を満たすために、製品を個別に、または組み合わせて実装できます。 製品は相互に関連しており、シームレスな全体を形成しています。

次の表は、各 Power Platform 製品の概要を示したものです。

Product	プロパティ
Power Apps	直感的なドラッグ アンド ドロップのキャンバスでカスタム アプリケーションを作成します。 1,000 を超えるコネクタがあるため、内部/外部のデータ ソースとサービスに数回クリックするだけでアクセスできます。 アプリはブラウザ、デスクトップ、モバイル デバイスで実行できます。
Power Automate	ワークフローを構築して、複雑なプロセスも自動化します。 組み込みコネクタとカスタム コネクタを使用して、内部/外部のデータ ソースとサービスを組み込みます。 アプリケーションにアプリケーション プログラミング インターフェイス (API) がある場合は、デジタル プロセス オートメーション (DPA) を使用します。 ロボティック プロセス オートメーション (RPA) を使用して、ブラウザーまたはデスクトップ アプリで実行される反復的なタスクを自動化します。 他のシステムやサービスでイベントが発生した際にワークフローをトリガーして実行したり、特定の時間に実行するようにスケジュールしたりできます。
Copilot Studio	ノーコードのグラフィカル インターフェースを使用した会話エージェントの作成。 Web サイト、モバイル アプリ、Microsoft Teams などメッセージング プラット フォームなど、複数のチャネルにエージェントを展開することができます。 AI 支援による作成により、トピックの作成を高速化できます。 生成型の回答では、トピックを作成しなくても、複数のソースから情報を検索して提示できます。
Power BI	グラフ、表、その他のビジュアルをキャンバスにドラッグするだけで、データ内に隠れている分析情報を明らかにする洗練されたレポートを簡単に作成できます。 予測モデリングのための自動機械学習と、詳細な根本原因分析ドリルダウンのための分解ツリーによる AI の視覚化が含まれます。 簡単な Q&A 形式で自然言語の質問をして、データを探索します。
Power Pages	安全なエンタープライズグレードのローコード SaaS (サービスとしてのソフトウェア) プラットフォーム上で、魅力的なデータ駆動型の Web サイトをすばやく構築します。 豊富でカスタマイズ可能なテンプレートと流動的なビジュアル エクスペリエンスにより、最新の外部向けビジネス Web サイトの作成、ホスティング、管理が簡単になります。

Power Platform の製品ファミリは、いくつかのサポート機能とコンセプトに依存しています。 次の表では、理解しておくべき最も重要なものについて説明します。

概念	プロパティ
Power Fx	Power Fx は Excel の数式にインスパイアされたオープンソースのローコード言語です。 厳密な型指定、宣言型、関数型、命令型ロジックと状態管理、そのすべてが人間にやさしいテキストで表現されているため、Power Fx は市民開発者にもプロ開発者にも、一般的なプログラミング作業を簡単にします。 プログラミングをしたことがないユーザーに向けたノーコードから、熟練したプロフェッショナルのための「プロコード」まで、開発の全領域をサポートし、多様なチームが協力して時間と費用を節約できるようにします。
コネクタ	コネクタは、ローコードと従来のコーディングを連携させて最新のアプリを提供するために不可欠です。 コネクタは、Power Apps と Power Automate が内部および外部のデータソースやサービスを使用できるようにする API のラッパーです。 1,000 を超える構築済みコネクタが使用可能であり、任意の RESTful API 用に独自のコネクタを作成できます。 コネクタ定義には、ローコード アプリで API を簡単に使用できるようにするために必要なメタデータが含まれています。
Dataverse	Dataverse はAzure データ管理サービス上に構築されたクラウド規模のハイブリッド データ ストアですが、単なるデータベースではありません。 Dynamics 365 と Power Platform の基盤となるデータプラットフォームであり、ワークフローとプラグイン、ビジネス ルールとプロセス フロー、高度なセキュリティ モデル、多言語/多通貨アプリを搭載してサポートする拡張可能な開発プラットフォームなどのサーバーサイド ロジックを備えています。 アプリケーションはデータ モデルから素早く構築できるため、フォーム オーバー データ ソリューションを展開する最速の方法のひとつです。
AI Builder	AI Builder は、Power Apps と Power Automate で人工知能を簡単に利用し、データから分析情報を見つけ、プロセスを自動化し、アプリの生産性を向上させます。 AI Builder を使えば、AI のパワーにアクセスするためにコーディングやデータ サイエンスのスキルは必要ありません。 事前構築済みの構築されたカスタマイズ可能なモデルは、多くの一般的なビジネス シナリオに対応しており、すぐに利用できます。また、特定のビジネスニーズを満たす独自のモデルを構築することも可能です。
Copilot	Copilot の AI 支援は、市民開発者であれプロの開発者であれ、Power Platform のユーザーや開発者の生産性を向上させます。これにより、仕事の最良の部分に多くの時間を費やし、平凡なタスクに費やす時間を減らすことができます。 ビジネス シナリオを Power Automate で Copilot に記述すると、Copilot はその記述を自動ワークフローに変換できます。 Copilot に Power Apps で何をしたいか、どんな情報を見たいかを伝えると、そのためのアプリを作成してくれます。 Copilot は、接続の設定、テーブルの作成と設定、画面の生成、さらにはフローやアプリを改善するための提案を提供します。 アプリには最初の画面から Copilot を活用した体験が組み込まれているため、ユーザーは会話を通じて分析情報を発見できます。
環境とソリューション	環境とは、Power Platform リソースの管理と保護を容易にする境界を意味します。 また、運用環境に展開する前にソリューションを別々の環境で開発/テストする、アプリケーション ライフサイクル管理 (ALM) でも使用されます。 ソリューションは、Power Platform のカスタマイズや拡張機能としてパッケージ化されています。 ソリューションには、アプリ、フロー、テーブル、グラフ、ダッシュボード、コネクタ、およびカスタマイズや拡張機能に必要なその他のコンポーネントを含めることができます。 ソリューションは、組織の ALM ポリシーの一部として、開発、テスト、運用環境への個別の環境への展開を行うことができます。 ソリューションをエクスポートして他のユーザーや組織と共有したり、他のユーザーからソリューションをインポートしたりできます。 ソリューションにはマネージド型とアンマネージド型があります。 アンマネージド ソリューションは、開発とテストに使用されます。 マネージド ソリューションは、運用環境の展開と配布に使用されます。

アプリのモダナイゼーションにおける Power Platform の主な利点

Microsoft Power Platform xx を使用してアプリケーションを最新化するメリットは、最新のテクノロジーを使用するソリューションを持つという初期のビジネス価値だけにとどまりません。

• コストの削減。 組織は、アプリの開発とメンテナンスにかかるコストを節約できます。 Forrester Consulting 社の委託調査によると、Power Platform を使用する組織は、アプリケーション開発コストを 45％ 削減し、140％ の投資収益率を実現できることがわかりました。

• リソース プールを拡張し、ボトルネックを解消します。 プロの開発者、データ サイエンティスト、AI エンジニアは高給で、高い需要があります。 中小規模の組織では、社内にコーディングの専門知識を持つ人材を確保する余裕がないことが多く、また、アウトソーシングも高額です。 ローコード Power Platform は、より多くのリソースがアプローチ可能です。 業務プロセスに精通した専門家や従業員は、たとえコードを一行も書いたことがない場合でも、モダナイゼーションの取り組みを加速させることができます。

• 車輪ではなく荷台を作ります。 従来のソフトウェア開発は、毎回最初からやり直し、新しいプロジェクトごとに車輪の再発明を行います。 ローコードで直感的な、メーカー フレンドリーな Power Platform 製品を車輪として使用することで、より優れたカートの構築、つまりビジネスプロセスの改善に集中することができ、モダナイゼーション努力のメリットをより早く享受することができます。

• 技術的負債を削減します。 手間をかけないなソフトウェア ソリューションのアップグレードやレガシーなインフラストラクチャの維持には、財政的にも機会損失としても大きなコストがかかります。 Power Platform は、ソリューションの構築を簡単かつ低コストで実現し、共通のデータモデルとコネクターによってデータ統合とガバナンスを簡素化し、ソリューションを管理するための一元化されたプラットフォームを提供し、アナリティクスと AI によって継続的な改善をサポートすることで、このような技術的負債を軽減します。

• セキュリティの強化とコンプライアンスを徹底します。 すべての Power Platform 製品には、エンタープライズグレードのセキュリティ、コンプライアンス、ガバナンスが完全に統合されており、既成の環境から実行できます。 マネージド環境は、管理者がよりコントロールしやすく、より少ない労力で Power Platform を大規模に管理することを可能にする一連のツールです。 特に、どのフローやアプリを誰と共有できるユーザーを制限したり、ポリシーを使用して作成者が使用できるコネクタを制限したりできます。 ネイティブで柔軟なデータセキュリティ モデルにより、各アプリケーションが独自に構築する必要がありません。

• モダナイズを促進できます。 最新化するアプリの重要性が高いほど、それらをすべて一度に置き換える可能性は低くなります。 ローコード アプローチは、管理しやすい増分でソリューションを構築する場合に適しています。

• レガシーアプリと統合します。 古いアプリケーションには、多くの場合 API がありません。 Power Platform の RPA 機能は、古典的なアプリケーションを自動化し、新しいモダンなビジネス プロセスに組み込むことができます。 RPA は、大規模で複雑なアプリを段階的に最新化するのにも役立ちます。

• コストをかけずに革新を実現しましょう。 Power Platform の機能は向上し続けています。 プラットフォーム上に構築されたアプリは、コストをかけずに Microsoft イノベーションの恩恵を受けることができます。

• 現代の職場で従業員の生産性を向上させます。 Power Platform はマイクロソフトのモダン ワークプレイスの一部です。 プラットフォーム上でモダナイズされたアプリケーションは、魅力的なモバイル体験や簡単で直感的なコラボレーションなど、Microsoft 365 の機能を活用することができます。 Copilot、AI Builder、そして間もなく発表される機能のような最先端の AI は、ユーザーと開発者の生産性を向上させ、フラストレーションを軽減し、学習曲線を浅くします。

現場労働者のためのイノベーション

現場担当者は、どこで働いていても、どのデバイスでも使用できる最新のアプリケーションを必要としています。 より良い意思決定をより迅速に行うために、リアルタイムで分析情報にアクセスする必要があります。 彼らは、すべてを円滑に機能させるために、同僚や経営陣と協力する必要があります。 アメリカン航空が運航の一部を近代化することを決定した際、彼らはそれ以上のものを得ました。

マイクロソフトとの提携により、アメリカン航空は Power Apps と Azure 上に構築された Microsoft Teams アプリ、ConnectMeを作成しました。 モバイル端末でアプリを使用することで、現場チームは到着、搭乗、手荷物、ゲートに関する重要な情報をリアルタイムで入手でき、地上業務を効率化し、航空機の回転時間を短縮し、お客様の旅をより快適なものとすることができます。 航空会社の変革についての詳細をご覧ください。

ナレッジ ワーカーのための AI エンパワーメント

ナレッジ ワーカーはデータの海を泳いでおり、溺れているように感じることが多すぎます。 ほとんどすべてのアプリケーションがデータを収集します。 ユーザーが収集したデータを理解するのに役立つものはほとんどなく、ましてや労働者の仕事の改善に役立つ可能性のある洞察を引き出すことはほとんどありません。 最新化の一環として AI 機能をアプリに追加することで、データの収集と分析を自動化するだけでなく、ナレッジ ワーカーがパターンや傾向を見つけやすくすることができます。 予測分析では、AI モデルを使用して、履歴データに基づいて将来の結果を高精度で予測できるため、リーダーは自信を持って計画を立てることができます。 モダナイズされたアプリには コパイロット AI が含まれており、インタビューの要約、ターゲットを絞ったマーケティングおよび販売メッセージの作成、さらには顧客サービス担当者や営業担当者が顧客との電話中にリアルタイムで役立つ情報を提供するなど、コンテキストに沿ったコンテンツを生成するパートナーとして機能します。

レガシ アプリをモダナイズするための段階的な取り組み

ほとんどの組織がそうであるように、モダナイゼーションの恩恵を受ける古いアプリケーションのバックログが増えています。 レガシ アプリケーションは通常、時代遅れのテクノロジーを使用しており、サポートされなくなったインフラストラクチャ (ハードウェアとソフトウェア) 上に構築されています。 多くの場合、その仕組みを知っているのは数人の従業員、たいていは定年間近の従業員だけです。 新しいスタッフは、自身が慣れ親しんだ、あるいは使いたがっている最新のツールを使えないので、関わりたくないのです。 更新はおろか、維持するには技術的負債の山を登る必要があり、登れば登るほど高くなります。 何年、何十年にもわたるパッチワークのメンテナンスの結果、特にビジネスの大部分がそれに依存している場合、誰もあえて触れないコード ベースができあがります。

多くの場合、組織はこれらのアプリケーションをすべて一度に簡単に置き換えることはできません。 代わりに、段階的なモダナイゼーションの旅に乗り出します。 漸進的なアプローチにより、最新化の利点を最大化すると同時に、一回限りの最新化作業によるリスクを軽減することができます。

アプリを最新化するためのオプション

モダナイゼーションとは、必ずしもレガシー アプリをゼロから再構築することを意味するわけではありません。 その他のオプションとしては、廃止、置換、再ホスト、リファクタリング、再設計があります。

次の表では、各オプション、最適な場合の ALM ステージ、その選択に影響を与える可能性のあるドライバーについて説明します。

期限

移行

最新化

廃止

Replace

再ホスト

リファクター

再設計する

再構築

Description

アプリの削除

アプリを SaaS または別のアプリに置き換える

そのままクラウドに再展開する

既存のコードを最適化する

コードを新しいアプリケーション アーキテクチャに移行するか、マイクロサービスに分割します

元のスコープと仕様でアプリをゼロから書き直す

ドライバー

不要になりました

経費の削減

資本経費の削減

新しいテクノロジーを活用する

資本経費の削減

データ ストレージの回復

迅速なクラウド ROI

より速く、より短い更新

よりポータブルなコード

リソース、スピード、コストにおけるクラウド効率の向上

パフォーマンスの向上

技術的負債を削減する

スケーラビリティ、信頼性、保守性の向上

新しいクラウド機能の導入の容易化

ミックス テクノロジー スタック

イノベーションの加速

開発の迅速化

営業費用の削減

Microsoft のテクノロジー

Power Apps

Dynamics 365

Azure IaaS

Azure VMWare

Power Platform

コンテナー

Azure PaaS

Power Platform

Azure PaaS

サーバーレス マイクロサービス

Power Platform

Azure PaaS

サーバーレス マイクロサービス

次の表は、ローコード アプローチを各アプリの最新化オプションに適用する方法を示しています。

回答内容	プロパティ
再ホスト	リホストでは、アプリを古い環境から新しい環境にそのまま移動します。 ローコード アプローチは直接適用されませんが、リホスティングは、ローコード ソリューションを含む他の戦略を適用する前の最初のステップとなる可能性があります。
リファクターまたはリアーキテクト	リファクタリングでは、アプリがクラウドファースト環境から最大限のメリットを得られるようにコードを微調整します。 再設計では、コードが大幅に変更されます。 これには、コネクタを介してローコード ソリューションに公開できる API に移動することで、既存のロジックをカプセル化することが含まれる場合があります。
交換または再構築	置き換えると、アプリが別のアプリと入れ替わります。 リビルドでは、アプリをゼロから再作成します。 このオプションは、ローコード アプローチが最高のビジネス成果を達成する場合によく使われます。 Dynamics 365 または Microsoft AppSource のアプリケーションから始めることで、使用用途が事前に構築された機能と一致する場合、モダナイゼーションを迅速に開始できます。 組織は、Power Platform のコンポーネントを使用して、独自のニーズに合わせてアプリをカスタマイズすることができます。

Power Platform のローコード アプローチは、単なる開発ツール以上のものを提供する可能性を秘めています。 ロー コードを最新のアプリ戦略の一部にすることで、対象分野の専門家など、開発者以外の人がモダナイゼーションの取り組みに参加するための基盤を確立することもできます。 組織は、Power Platform に関するセンター オブ エクセレンス (CoE) を確立し、ガイドラインとガバナンスを作成する CoE スターターキットのようなツールを使用することで、ユーザーがローコード アプリやオートメーションを成功裏に構築し、API やコンポーネントのような資産を再利用できることに気付きました。 ロー コードは、アプリケーション開発を加速し、データがどこにあるかに関係なく、組織がデータからより迅速に価値を引き出すのに役立ちます。 実際、多くの組織は、ロー コードの考え方を企業文化に統合することを決定しています。

モダナイゼーション ジャーニーのガイド

レガシー アプリのモダナイゼーションについて考え始めると、圧倒されてしまいがちです。 ガイドがあれば、体験の計画を立てやすくなり、正しい道を歩むことができます。 まず、これら 3 つのステップから始めて、それぞれをローコードの考え方で検討することをお勧めします。

1. プランニング。 レガシ アプリケーションをモダナイズする目標を慎重に検討し、それを達成するための戦略を定義します。 モダナイゼーションで解決したい問題を明確に記述します。 今こそ、何が機能していないのか、何が機能しているが改善の余地があるのか、そして最も重要なこととして、変更によってビジネスやユーザーにとってどのような価値があるのかに目を向けて、アプリと環境を評価していきます。 各モダナイゼーションの機会を評価して、ローコード アプローチを活用する可能性を確認します。 ローコード ソリューションを組み込んだ機会に優先順位を付けます。 クラウド導入戦略評価ツールを使用して、アプリケーション最新化のビジネス用途を構築します。

2. 実装。 アプリを段階的にだけでなく、反復的に最新化します。 反復的なアプローチにより、組織は必要に応じてプロジェクトの範囲や戦略を柔軟に変更できます。 Power Platform のローコード ソリューションは、従来開発されたアプリよりも迅速に開発およびテストすることができ、マネージド環境での展開はわずか数ステップで済みます。 ローコードは従来のコーディングよりもスキルアップの必要性が低いとはいえ、ロー コードと従来のリソースを組み合わせた融合チームとして働く方法について、従業員が適切にトレーニングを受けていることを確認してください。

3. 操作。 アプリのモダナイゼーションは実装にとどまりません。 ロー コードのクラウド ファーストのアプローチでは、クラウド プラットフォームのサービスとツールを使用して、アプリを保護、ガバナンス、管理、最適化できます。

ローコード ソリューションの機会を評価する

組織は、非公式なレビューから詳細な決定木に至るまで、さまざまな方法を用いて、レガシー アプリケーションを近代化するのにロー コード アプローチが正しい方法であるかどうかを判断します。 考慮すべき最も重要なことは、ロー コードはオール オア ナッシングの決定ではないということです。 アプリケーションの一部を Power Platform コンポーネントで構築し、一部を従来のコーディング技法で開発されたコンポーネントで構築することは一般的です。

アプリケーションを評価するには、まず、そのアプリケーションがまだ必要で有用であるか、廃止する必要があるかどうかを判断することをお勧めします。 それでも必要だと判断した場合は、ローコード ソリューションでアプリ全体を置き換えることができるかどうかを評価します。 アプリ全体がローコードでの置き換えに適していない場合は、アプリのワークロードやコンポーネントの 1 つ以上が適しているかどうかを評価します。 従来の方法で開発されたコードで拡張されたローコード ソリューションは、両方の長所を提供することがわかります。

たとえば、Power Apps に必要なコントロールがないため、アプリケーションに適していないと判断した場合、Power Apps Component Framework (PCF) と従来のコードを使ってカスタム コントロールを構築することができます。 もう 1 つの例は、複雑なロジックを持つアプリです。 カスタム コネクタを使用し Power Apps がアクセスできる API にロジックを集中させることができます。 これらの両方の例では、Power Platform の拡張性により、アプリのほとんどがローコード コンポーネントで構築され、従来開発されてきたコードとのギャップを埋めることができました。

独自のオンライン保険ショッピングプラットフォームである NSure.com は、実際の例を示しています。 同社の最初の立ち上げは、従来から開発されていた Angular、Xamarin、Azure サービスに依存していました。 Power Platform と Dynamics 365 を追加することで、NSure.com は次の図が示すように、ローコードと従来のコーディング技術の両方を使用して次世代ソリューションを作成しました。 会社の体験に関するの詳細については、こちらをご覧ください。

ロー コードの機会を特定するのと同じくらい重要なのは、ローコード アプローチが適切でない場合を認識することです。 次の表は、一般的にローコード ソリューションに適さないユース ケースを示しています。 組織はフロント エンドとバックエンドで異なる課題に直面しているため、それらを別々に検討しましょう。

ローコード アプローチに適さないフロントエンドのシナリオ

シナリオ	課題
ユーザー デバイスに互換性がありません	Power Platform はモバイル機器やバーコード スキャナのような特殊なデバイスを認識します。 特定の API またはドライバーに依存するデバイスはサポートされていない可能性があるため、より従来のアプローチが必要になります。
大量のクライアント側データ	一部のアプリケーションのユーザー エクスペリエンスには大量のデータが必要であり、ローコードに限らず、あらゆるテクノロジーにとっての課題となっています。 大量のデータをダウンロードして処理すると、バックエンド システムに負荷がかかり、アプリとアプリが実行されているデバイスの両方のパフォーマンスが低下する可能性があります。 大量のデータをナビゲートすることを余儀なくされているユーザーは、生産性が低下します。 負荷を処理するために従来のコーディング方法に目を向ける前に、適切なフィルター処理とナビゲーションによってユーザー エクスペリエンスが向上するかどうかを調べてください。
複雑なオフライン要件	接続性が低い場所や存在しない場所で動作する必要があるアプリケーションは、ローコードと従来のコードのどちらを使用していても、実装とサポートが困難な場合があります。 Power Apps xxはシンプルなオフライン シナリオに向けた基本的な機能を提供します。 たとえば、イベント中にリードをキャプチャし、イベント後にマーケティング データベースにアップロードするアプリは正常に機能します。 ファイルや画像、非 Dataverse のコネクタ、複雑な競合の解決を必要とするアプリケーションでは、従来のコード テクニックを利用する必要があります。

ローコード アプローチに適合しないバックエンド シナリオ

シナリオ	課題
高速データ	移行や同様のイベントの一部としての数百万行のデータのインポートは、一般的にサポートされています。 ただし、毎時または毎日数百万行のデータを処理するワークロードは、より多くの評価を受ける必要があります。 たとえば、大量のモノのインターネット (IoT) のテレメトリを Dataverse にコレクションしても意味がありません。 その代わりに、Azure のクラウドサービスを使用してデータを収集、分析し、関連するシグナルを Dataverse に追加して、アプリケーションのアクションをトリガーすることができます。 Dataverse のデータを定期的に大量に更新するようなアプリケーションでは、更新を拡張するために従来のコードの支援が必要になる場合があります。
複雑なロジックを持つバックグラウンド ワークロード	複雑なロジックや大量の API 呼び出しを伴うバック グラウンド ワークロードは、ローコード ソリューションに適していない可能性があります。 代わりに、ローコード ソリューションが呼び出すことができる API にロジックを一元化できます。
非 RESTful のプロトコルを使用する　API	Power Platform コネクタは REST API のみをサポートします。 SOAP や gRPC などの別のスタイルの API に接続する必要がある場合は、互換性のない API と通信する独自の REST API を提供します。

Power Platform のリリース サイクルは、ローコード ソリューションでできることのギャップを埋め続けているため、このサイクルをフォローすることを推奨します。 ローコードの概念実証を作成することは、シナリオが適切かどうかを判断するための優れた方法です。

ローコード機会の優先順位付け

アプリケーション ポートフォリオを評価する際には、ローコード変換の適切な候補を特定するだけでは不十分です。 チームは、モダナイゼーションの取り組みの成功を最大化するために、それらに優先順位を付ける必要があります。

優先順位付けは、以下の要素を考慮する必要があります:

• 組織のローコードの成熟度
• 営業案件の複雑性
• 組織、ユーザー、IT 部門の ROI
• 時間の有効活用

組織のローコード機能を現実的に把握することで、チームの成長に課題を与えながらも、失敗に追い込まれることのない機会を選択することができます。 何の課題もなく、最も簡単なアプリケーションを選択する必要はありません。 理想的なのは、従来のコードとローコード ソリューションを組み合わせる方法を模索する機会を提供することです。

他のシステムと複雑に統合されているアプリケーションは、多くの場合、最適なスタート地点ではありません。 大きすぎたり複雑すぎたりするアプリケーションに取り組もうとすると、フラストレーションや失敗につながる可能性があります。 疑わしいローコードの候補は避けてください。 チームがいくつかの最新化を成功させた後のために保存しておいてください。

大規模なモノリシック アプリを最新化する場合は、その小さな部分を段階的に最新化できるかどうかを検討してください。 モノリシックなアプリケーションは、かつては一般的でした。 現在では、役割やタスクに重点を置いた小規模なアプリが一般的になっています。 これにより、インクリメンタルな開発と、それらを構築するチームの拡張とスケーリングが可能になります。

最初の数回の最新化は、組織がローコード ソリューションの影響を確認できるようにするために重要です。 機会に優先順位を付ける際には、アプリの関係者にとっての利点とリスクを評価することが重要です。 誰も気にしないアプリケーションや、組織への影響が少ないアプリケーションを選択することは、ローコード ソリューションの利点を最もよく示すことはできません。

最新化されたアプリケーションをユーザーが受け入れることは重要です。 ユーザーは、新しいローコード アプリケーションが、使用する他のアプリケーションと調和していると感じる必要があります。 導入のもう一つのリスクは、慣れ親しんだカスタマイズの度合いです。 高度にカスタム構築されたエクスペリエンスを期待している場合、個人的ではないと感じられるローコード ソリューションを採用する傾向は低いかもしれません。

チームの編成とスキルアップ

レガシー アプリのモダナイゼーションに成功している組織は、従来のコード開発者のチームにモダナイゼーション プロジェクトを割り当てて、その成功を願うだけではありません。 最新化の取り組みを成功させるために必要なローコード開発のナレッジと自信をチームに与えることが重要です。

従来のコード リソースと並行して作業するローコード リソースのチームは、フュージョン チームと呼ばれます。 フュージョン チームは、ローコード ソリューションと従来のコードの統合について両方の種類のリソースをトレーニングすることで、コラボレーションを促進するように設計されています。 ソリューション アーキテクトは、ローコードと従来のコードの間でソリューションを設計する方法を確立します。

既定では、すべての作業を従来の開発者に割り当てるのは簡単ですが、ローコードのモダナイゼーションの取り組みは、プロジェクト チームを拡大する良い機会です。 多くのビジネス ユーザーは、優れたローコード リソースとなります。 ビジネス上の問題を既に理解しているため、チームの作業を加速できます。 チームが引き受けるローコード作業の種類を完了する方法を学び、テストと ALM の手順に精通しているだけで済みます。 これは、Power Apps のアプリや Power Automate のワークフローを構築する方法を学ぶことを意味する可能性もあります。 また、従来のコーダーがローコード作業を容易にするために何を開発できるかを理解する必要があります。 だからといって、従来のコードの書き方を知っておく必要はありません。

従来のコード リソースは、ローコード アプローチと、これらが通常記述するコードとどのように異なるかについての基本的な知識を持っている必要があります。 最も重要なのは、ローコード ソリューションの拡張性オプションを学ぶ必要があることです。 作成したコードを使用するテスト アプリまたはフローの作成に問題がなく、それが動作することを確認し、機能拡張資産を使用する際にローコード リソースをサポートする準備を整える必要があります。

ローコードと従来のコードの両方のリソースは、ローコードと従来のコード ソリューションの開始と終了、それらが交差する場所を理解する必要があります。

要件の収集

10 年以上前のアプリがあり、文書化されていない場合があります。 再現するには、リバース エンジニアリングやビジネス ユーザーの知識が必要な場合があります。 ローコード アプローチは効率的ですが、要件やビジネス プロセスに関する知識の収集を高速化したり、複雑な要件の複雑さを軽減したりするわけではないことを覚えておくことが重要です。 多くの場合、アプリをモダナイズするチームが、ロー コードで新しいアプリを構築するチームと同じくらい多くのことを達成できるという非現実的な期待があります。 これらの課題を念頭に置いて、組織の期待を確立します。

2 つのアプローチにより、レガシー アプリに関する知識を得る作業を加速できます。 まず、チームを拡張して、ドメイン知識を持つビジネスユーザーを含めます。 次に、レガシー システムでどのように実装されているかをドキュメント化するのではなく、ビジネス プロセスとその望ましい結果を理解することに焦点を当てます。 ただし、レガシ アプリケーションが、従う必要のあるビジネス ルールを実行する特殊なロジックを必要とする場合は例外です。

ローコード アプローチでの作業を避ける

ローコード ソリューションを使用したアプリケーションのモダナイゼーションに不慣れな組織は、従来のコードを開発するのと同じ方法でローコードを開発するという間違いを犯すことがよくあります。 たとえば、ある組織が最初の Power Apps 実装に Angular アプリ用に書かれた UX のスタンダードを適用する可能性もあります。 プロジェクト チームは、ビジネス ニーズではなく Angular フレームワークの機能のために設計された標準を満たすために不必要な時間を費やすことになります。

従来のコードでの作業に慣れているチームは、ローコードを最小限に抑えようとするかもしれません。 たとえば、Power Apps のコントロールを使用する代わりに、Power Apps component framework のコントロールからアプリケーションを構築し、ローコードをできるだけ使用しないようにすることができます。 チームは、回避できない障壁にぶつかるまで、ローコードでできる限り進めるのが最善です。 プラットフォームの機能を活用する方法を学んだチームは、ローコードのメリットを最大限に引き出すことに成功します。 ローコードは、従来のコードでしか実現できなかったことを実現できるようになってきています。 これまでの一般的な課題は、ローコードでは必要な機能を複製できないために行き詰まることでした。 Power Platform は、主にローコード アプリケーションが、必要に応じて従来のコードで書かれた特殊なコンポーネントを組み込めるようにする拡張性オプションによって、この課題に対処しています。

ローコード アプローチは、モダナイゼーション戦略において重要な役割を果たします。 最良の結果を得るには、モダナイゼーションの取り組みが解決しようとしている問題、計画、既定の役割を超えた人員配置、トレーニング、優先順位付けの明確な説明が必要です。 また、必要に応じて標準やプロセスを適切に調整することで、組織はローコードの可能性を最大限に引き出すことができます。 モダナイゼーションを適切に行うと、モダナイズされたアプリケーションの全体的なビジネス価値が向上します。

ローコード プラットフォームは、ここ数年で急速に進化しています。 これまでも個人の生産性シナリオのサポートに長けていましたが、最近では企業の機能に重点が置かれています。 組織は、ハイブリッド ワーク (リモートおよびオンサイト) や、それに伴うコラボレーションを促進する方法の必要性など、現代の職場環境をサポートするローコード アプリケーションを構築しています。 Power Platform のようなローコード プラットフォームは、組織内のすべてのユーザーが信頼でき、企業のセキュリティモデルに統合できるアプリケーションを扱うために拡張できるようになりました。 ローコード機能をエンタープライズのインフラストラクチャに接続することで、ローコード手法を従来の方法と並行して使用できます。 ローコードは複雑性の多くを抽象化し、より多くの人々がソリューションの構築に参加できるようにします。

ローコード アプローチのコスト構造を理解する

組織がモダナイゼーションの取り組みを検討する際によく聞かれる質問は、どれくらいの費用がかかるかということです。 ライセンスとコスト分析の完全な説明は、このホワイト ペーパーの範囲を超えていますが、これらのトピックを大まかに調べることができます。

Power Platform 製品はライセンス製品です。 要件に合わせて個別にライセンスを取得できます。 Azure の課金を従量課金に構成することができます。この場合、事前のライセンス契約や購入なしで使用でき、アプリ内での Power Automate 使用も含まれます。 Power Automate はまた、スタンドアロン作業用にユーザー単位とフロー単位のライセンスを持っています。 フローごとのライセンスは、組織全体に利益をもたらす自動化がある場合に適しています。 Power Apps のライセンスはユーザーごと、またはアプリごとに設定できます。 Power Pages のサイトは、ユーザー、サイト、または月ごとにライセンスされます。 認証されたサイトには、追加のライセンスが必要です。 すべてのライセンスにはコネクタと Dataverse の使用が含まれ、大容量シナリオ用にストレージと API リクエストのライセンスを増やすオプションもあります。

すべての Power Platform 製品には、アプリケーションの最新化作業に一般的に適用されるボリューム価格が設定されており、各組織独自の戦略に合わせて評価する必要があります。

従来のコードと比較してローコードのコストを評価する際には、比較が同一条件ではないことを認識することが不可欠です。 ローコードでは、ローコード製品に独自のビジネスプロセスを実装するための人件費と、使用するための製品ライセンス料を支払うことになります。 一般に、ライセンスには複数のアプリと自動化が含まれており、それぞれに追加のコストは必要ありません。

従来のコーディングのアプローチでは、独自のビジネス プロセスをコードに実装する作業、アプリのインフラを構築する作業、そしてアプリをサポートするために必要なクラウド サービスに費用がかかります。

ローコードであろうと従来のコードであろうと、すべてのソリューションには継続的なメンテナンスと維持が必要です。 ただし、ローコード ソリューションでは、それを実行するために必要なリソースが少なくて済みます。 また、アプリのインフラストラクチャがプラットフォームによって提供されるため、技術的負債も少なくなります。

ローコード プラットフォーム上に構築されていない完全なカスタム アプリケーションと比較して、ローコード ソリューションのコストはより予測可能です。 ローコード ライセンスと従来のコード展開の初期コストを比較するという罠に陥らないようにします。

Power Platform の内部を見る

Power Platform コンポーネントは、従来のコーディング手法と同じ Microsoft Azure のクラウド サービス上に構築されます。 これらのコンポーネントを相互に統合し、セキュリティ、スケーラビリティ、ディザスター リカバリー機能を提供します。

Dataverse の内側

Dataverse は、Functions、Load Balancer、Cognitive Services、Synapse、DevOps、Active Directory、Microsoft Purview など、25 以上のフルマネージド Azure サービスによって支えられています。 包括的なセキュリティ、強力な分析、AI、高度なビジネスロジックとイベント処理、データモデリング、Dynamics 365、Microsoft 365、Azure などとの統合などの機能が組み込まれています。 これらの機能はすべて、Azure SQL DB (リレーショナルデータ用)、Azure Cosmos DB (NoSQL 用)、Azure Blob Storage (ファイル用)、Azure Data Lake Storage Gen 2 (大規模アナリティクスと長期データ保持用) をベースとする多言語 Dataverse ストレージレイヤー上に構築されています。 これらは Power Platform のローコード コンポーネントや Dataverse の REST API で透過的に使用できます。

ビジネス クリティカルなアプリケーションにとって、高可用性と事業継続性、ディザスター リカバリー (BCDR) は重要です。 Dataverse は Azure の信頼性サービスで可用性を最大化します。 プライマリ サーバとセカンダリ サーバのレプリケーションは同期的であり、その下にファブリックがあり、不具合を検出し、正確性プロトコルに従って新しいプライマリ サーバを選択できます。 Azure リージョン内で発生する高可用性フェイルオーバーはシームレスであり、ユーザーが気づくことはほとんどありません。 停止が計画的か計画外かに関係なく、データ損失がゼロであることが保証されています。

ディザスター リカバリーのフェイルオーバーは、2 つの Azure リージョン間で発生します。 データ損失を最小限に抑えてフェールオーバーを高速化するために、ディザスター リカバリーの連続コピーは非同期レプリケーションを使用して維持されます。 計画的なフェールオーバーではデータ損失は発生せず、運用環境では通常、数秒または数分で完了できます。

高可用性と BCDR の技術的な実装に加えて、運用チームは、さまざまな種類のイベントに応答する準備ができているかどうかを定期的にテストします。

Power Automate の内側

Power Automate クラウドフローは Azure Logic Apps の上に構築されています。 Power Automate は Power Apps のような他のローコード コンポーネントとの抽象化と統合を提供し、Logic Apps ランタイム エンジンを使用します。 Logic Apps に慣れ親しんだ開発者であれば、Power Automate が式言語を含む同様のコンセプトを使っていることに気づくでしょう。

Power Apps の内側

Power Apps のランタイム エンジンは React フレームワーク上に構築されています。 アプリケーションは Power Apps デザイナーで構築され、ドラッグ アンド ドロップのインターフェイスを使用して画面を構築します。 Power Fx 式はロジックを実装します。 コネクタは、再利用可能なビジュアル拡張機能を可能にする他のサービス、ロジック、コンポーネントへのアプリのアクセスを拡張します。 開発者は、Power Apps Component framework (PCF)を使用してカスタム コントロールを作成できます。 多くの UI フレームワークが PCF と一緒に使用できますが、Power Apps は React をサポートしています。

コネクタの内部

コネクタは、Azure API Management を使用して、各ユーザーの資格情報と接続を管理します。

独自の API 用に作成したカスタム コネクタを含め、すべてのコネクタに同じアーキテクチャが使用されます。 Azure API Management を使用することで、Power Apps や Power Automate のような Power Platform 製品に対して、すべてのコネクタで一貫したインターフェイスが保証されます。

例外は Dataverse コネクタです。 アプリとフローのコネクタの一覧に表示されますが、実装方法が異なります。 アプリやフローが Dataverse のデータやアクションを使用する場合、Dataverse の OData API を介して直接やり取りされます。

Power Platform 拡張オプション

拡張性は、Microsoft Power Platform を他のローコードプラットフォームと差別化する重要な機能です。 このプラットフォームの基本原則は「障壁がない」ことであり、従来のコードを必要とする場合でも、ローコードを使用して何かを達成することを妨げられるべきではありません。 必要に応じて、従来のコードを使用して、大規模なアプリの一部としてワークロード全体を構築できます。 ただし、このプラットフォームには、ローコードと従来のコードを同じワークロードで一緒に使用できる多くの拡張機能オプションが用意されています。

次の表に、いくつかの一般的な拡張機能オプションの概要を示します。 そのうちのいくつかは、モダナイゼーションへのアプローチ方法と適用できるパターンについて後で説明するときに、再び参照します。

回答内容	プロパティ
API とカスタム コネクタ	REST API 用のカスタム コネクタは、アプリ ロジックを一元化し、安全で管理された方法でローコード コンポーネントに公開できるようにします。 このアプローチは、アプリケーションの最新化のための API ファースト戦略で使用できます。 カスタムコネクタは OpenAPI ドキュメントを使用して、ローコード コンポーネントが REST API とどのように相互作用できるかを定義します。 たとえば、Azure 関数を使用して API を作成し、Azure API Management に発行できます。 Azure API Management では、OpenAPI 定義をエクスポートして、ローコード ソリューションで使用するカスタム コネクタを自動的に作成できます。 このアプローチでは、クライアント アプリケーションを API から切り離し、独立して進化させます。 API は一元管理されており、API を直接公開せず、サブスクリプション キー、トークン、クライアント証明書、カスタム ヘッダーなどの認証技術を使用することで、セキュリティのレイヤーを追加しています。
Power Apps Component framework	Power Apps Component framework は、Power Apps と Power Pages のカスタム ビジュアルを作成する拡張フレームワークです。 コード コンポーネントは、HTML、JavaScript、またはTypeScript を使用して作成されます。 コード コンポーネントは、1 つ以上のアプリを構築するために再利用できる UI 構成要素と考えてください。 コンポーネントには、ローコード コンポーネントがコード コンポーネントと対話する方法を定義するマニフェストが含まれています。 コンポーネント インターフェイスを使用すると、ホスティング ランタイム エンジンはホスティング コンテナーのライフサイクル イベントを通信できます。 これにより、コード コンポーネントは、ホスティング コンテナーによって提供されるコンテキスト情報を使用してビジュアルをレンダリングできます。 アイデアについては、コミュニティ ギャラリー ( https://pcf.gallery) を参照してください。
仮想テーブル	仮想テーブルを使用すると、外部システムに存在するデータを簡単に統合できます。 外部データを Microsoft Dataverse のテーブルとしてシームレスに表現し、データを複製することなく、多くの場合カスタム コーディングも不要です。 Dataverse には OData v4 と Azure Cosmos DB 用のデータ プロバイダーが付属しています。 現在プレビュー中の仮想コネクタ プロバイダーは、利用可能なデータ プロバイダーを拡張し、Power Platform コネクタのサブセット (SharePoint と SQL Server を含む) を含みます。 より高度なシナリオでは、開発者はカスタム データ プロバイダーを作成できます。 カスタム データ プロバイダを作成するには、外部データと Dataverse の両方に関する深い知識が必要です。 ロジックに Power Fx を使用して Dataverse のプラグインを作成する機能はプレビュー中です。
Dataverse のプラグイン	Dataverse プラグインは、特定のイベントに反応して実行されるカスタム イベント ハンドラーです。 プラグインは、データベース エンジンのストアド プロシージャのようなものですが、.NET で記述されていると考えてください。 たとえば、Microsoft Dataverse データ操作の処理中にイベントが発生したり、カスタム API イベントのためにオンデマンドでイベントが発生したりします。 プラグインは、アップロードして Dataverse に登録できる .NET Framework アセンブリにコンパイルされたカスタム クラスとして実装されます。 プラグインは、定義されたインターフェイスを使用して、処理中のイベントに関するコンテキスト情報を取得できます。 プラグインは Dataverse トランザクションの一部として実行でき、現在のトランザクションの一部である他のデータ操作を実行できます。 プラグインは、小さな作業単位を対象としています。 プラグインのパフォーマンスを最適化する必要があり、全体的なパフォーマンスに悪影響を与えないようにしなければなりません。 プラグインは、ユーザー インターフェイスや API からの操作に関係なく常に実行されるため、ビジネス ロジックを一貫して適用するための強力な手段となります。

ローコード モダナイゼーション アーキテクチャ シナリオの調査

ほとんどのプラットフォームと同様に、Power Platform コンポーネントやその他の Microsoft クラウド サービスを使用して、無限のアーキテクチャ シナリオを構成することができます。 ホワイト ペーパーのこのセクションでは、より一般的なシナリオをいくつか検討し、それらを使用する際に留意する必要がある、いくつかの考慮事項について説明します。

アプリケーションのエクスペリエンス

ユーザー エクスペリエンスを最新化することで、ユーザーに大きな違いをもたらすことができます。 Power Apps は Power Platform で内部アプリケーションのエクスペリエンスを構築する主要な方法です。 Power Pages は社内の Web アプリケーションにも使用できますが、社外向けのアプリケーションの方が一般的です。

Power Apps

ワークロードは、ユーザーがアプリを切り替えることなく作業の多くを完了できるように設計する必要があります。 大規模なモノリシック アプリケーションを最新化する場合、その機能を複数のアプリに分割する場合があります。 逆に、ユーザーが複数のアプリで作業する必要がある場合は、それらを 1 つのアプリに統合して、複数のデータ ソースの統合ビューを表示することができます。

次の表では、Power Apps で構築できる 2 種類のアプリ、キャンバス アプリとモデル駆動型アプリについて説明します。

AP の種類	プロパティ
キャンバス アプリ	キャンバス アプリは、高いカスタマイズ性を備えている。 これらは、ユーザーが操作する 1 つ以上の画面で構成されます。 各画面のレイアウトと画面間のナビゲーションを制御します。 キャンバス アプリはコネクタを使用してデータを操作します。 1 つのアプリで複数のコネクタを操作できるため、複合アプリとして複数のデータ ソースを統合するのに適しています。
モデル駆動型アプリ	モデル駆動型アプリは、プライマリ データ ソースとして Dataverse を使用します。 これらは 1 つ以上のページで構成され、Dataverse テーブルまたはカスタム ページにすることができます。 Dataverse テーブルのページは、詳細ページまでドリルダウンして表示、編集することができます。 カスタム ページには、キャンバス アプリの画面とコネクタからのデータを組み込むことができます。 モデル駆動型アプリには、カスタマイズ可能なナビゲーション構造が組み込まれています。 これはすべてのモデル駆動型アプリで一貫しており、ユーザーによる導入に役立ちます。

次の図は、アプリがデータ ソースに直接接続するキャンバス アプリまたは モデル駆動型アプリ の基本的なアーキテクチャを示しています。

データ ソースへの直接接続を最小限に抑えるには、API へのカスタム コネクタをアプリで使用して、データ ソースで必要な作業を行います。 このアプローチにより、ローコード コンポーネントに公開される操作を制御し、基になるロジックの複雑さを抽象化できます。 次の図は、この API 優先のアプローチを示しています。

Power Apps は、アプリケーションに結果を返したり、非同期で実行できる Power Automate のクラウド フローを直接実行することもできます。

Power Apps をデータ リポジトリや API と併用することで、レガシー ソリューションの他の部分への影響を最小限に抑えながら、ユーザーエクスペリエンスを最新化することができます。 このアプローチでは、複数のレガシ システムを 1 つのアプリケーションに接続して、ユーザーが 1 か所で作業を完了することもできます。

Power Pages

Power Pages の主なデータソースは Dataverse です。 Web サイトにページを追加する場合、ページ定義は Dataverse に保存されます。 ページは Dataverse のデータを提示することも、ユーザーからデータを収集して Dataverse テーブルに保存することもできます。

匿名アクセス用、または内部ユーザー用の Microsoft Entra ID や外部ユーザー用の ID プロバイダーを使用した認証アクセス用のページを構成できます。 認証されたユーザーがデータにアクセスすると、アクセス権限のあるデータのみが使用可能になります。

Power Pages サイトの一般的な用途は、組織のビジネス プロセスへのセルフサービス アクセスを外部ユーザーに提供することです。 内部ユーザーは Power Apps アプリケーションを使用できます。 次の図は、このようなアーキテクチャを示しています。

データ管理

アプリケーションの最新化では、ソリューション全体で使用されるデータを評価する必要があります。 最新化されたアプリケーションには、データを処理するための複数のオプションがあります。 多くの場合、複数のアプリケーションが同じデータリポジトリを使用します。 アプリケーションの 1 つをモダナイズする一環として、新しいリポジトリにデータを移行することが困難になります。 Power Platform の中核となるコンセプトは、データを今ある場所で利用することも、Dataverse またはデータレイクでプラットフォームに取り込むこともできるということです。

最新化されたアプリケーションのデータ アーキテクチャには、次のオプションがあります。

• データをそのまま残す: コネクタまたは API とカスタム コネクタを使用して、データが存在する場所にあるデータにアクセスします。 データがオンプレミスにある場合、データ ゲートウェイはセキュリティで保護された接続を容易にすることができます。 仮想テーブルを使用して、互換性のある外部データを Dataverse テーブルとして統合します。

• Dataverse への移行 Dataverse は、トランザクション データや、複数のソースを 1 つのレコード システムに統合する場合に適したオプションです。 Power Query と自動化されたフローを使用して、多くのソースからデータをマッピングし、移行することができます。 Dataverse は、非構造化形式または半構造化形式で格納されている大量のデータを取り込むために設計されたエラスティック テーブルもサポートしています。

• データ レイクへの移行: 履歴データ、分析データ、またはテレメトリ データの場合は、データ レイクを使用します。 レイク内のデータは、Power BI 分析を生成するために使用したり、AI を活用した分析情報を生成するために処理することができます。

最新化されたアプリケーションのデータ アーキテクチャのオプションを評価するときは、次の考慮事項に留意してください。

• 他のアプリケーションへの影響: より効率的なデータ ストアへの移行は、1 つのアプリケーションにとって理想的かもしれませんが、データを使用する他のアプリケーションへの最初の影響が大きすぎる可能性があります。 組織によっては、古いデータ ストアにデータを残して Dataverse に新しいデータを作成し、より多くのアプリケーションを最新化する際に古いストアから移行することを検討しています。

• 新しいアプリケーションへの影響: 古いデータ ストアにデータを残しておくことは簡単ですが、モダナイズされたアプリケーションがそのデータを扱いやすくすることに悪影響を及ぼす可能性があります。 古いデータ ストアは、他のクラウド サービスと適切に統合されていない可能性があり、新しい全体的なアーキテクチャにデータを組み込むことが難しくなります。

• データ統合: アプリケーションのモダナイゼーションの一環として、適切な使用を確保するための明確な所有権や責任がないデータを特定するのが一般的です。 Dataverse にデータを統合することで、組織はデータのガバナンスを向上させ、適切な利用をより確実にすることができます。

• データのプライバシーとセキュリティ: プライバシーとセキュリティは、レガシー アプリケーションがどのように処理していたかだけでなく、現在のニーズと目標とする近代化アーキテクチャに基づいて評価する必要があります。 クラウド ソリューションには、プライバシーとセキュリティの制御を実装するためのより多くのオプションがあります。 多くの場合、1 つのデータ ストアで単純化できます。 また、複数のリポジトリにデータを分割するハイブリッド アプリケーションに統合データセキュリティを実装する方法も検討する必要があります。

• 統合の問題 古いデータ ストアには、データを移行したり、アプリケーションがカスタム コネクタで使用できる API を作成したりせずに、アクセスを許可するために必要な API が不足している可能性があります。 古いデータ ストアからそれを使用するアプリケーションへの接続を評価して、パフォーマンスが許容できるかどうかを判断する必要があります。

最新化するアプリケーションごとにデータ アーキテクチャを決定する必要があります。 最初のステップは、データ アーキテクチャにどのように Dataverse を組み込むかという全体的なビジョンを確立することです。 ローコードの価値を最大化することが目的なら、可能な限り Dataverse を使用する必要があります。 最初にビジョンを持つことで、データのサイロ化を回避できます。

外部データと Dataverse

レガシー アプリケーションは、多くの場合、組織の外部に存在し、Dataverse 以前から存在していたデータに依存しています。 これらのアプリケーションを最新化する場合、Dataverse のデータを複製する必要はありません。 その代わりに、データを仮想 Dataverse テーブルとして表現することができます。 仮想テーブルは、他の仮想テーブルやローカル テーブルとのリレーションシップに参加できます。 最新化されたアプリケーションでは、完全に Dataverse に存在するように見える統一されたテーブル セットが表示されます。

仮想テーブルは、データ プロバイダー アーキテクチャを使用して実装されます。 Dataverse には、OData V4 Web サービスで使用できる OData プロバイダが含まれています。 現在プレビュー中の仮想コネクタ データ プロバイダーでは、表形式の Power Platform コネクタを仮想テーブルとして使用できます。

次の図は、仮想コネクタの使用方法を示しています。

開発者は、他の外部データ ソースのカスタム プロバイダーを作成することもできます。 しかし、すべての Dataverse マッピングと操作サポートを理解し、実装する必要があります。

次の考慮事項は、最新化プロジェクトでの仮想テーブルの使用を評価する際に役立ちます。

• すべての外部データ ソースは主キーを持たなければならず、データ プロバイダはそれを GUID として Dataverse に提示する必要があります。 パディングされた値が安定していて一意である場合、パディング付きの非 GUID キーに対応できます。
• データ セキュリティは、仮想テーブル レベルで構成されます。 行レベルおよび列レベルのセキュリティは使用できません。
• 仮想テーブルのパフォーマンスは、データ プロバイダー、外部データ ソース API、データ ソースへの接続によって異なります。 ほとんどの場合、仮想テーブルへのアクセスはローカルの Dataverseテーブルよりも遅くなります。
• 検索、監査、グラフやダッシュボード、オフラインアクセスなどの一部の Dataverse 機能は、仮想テーブルでは利用できません。
• 参照データに仮想テーブルを使用すると、同期が低下する可能性があります。

ファイルと画像

ファイルやイメージを使用するアプリケーションを最新化するときは、新しいソリューションがそれらを格納する場所を検討することが重要です。 Dataverse には、ファイルや画像を保存する特殊な機能があります。 どちらも列としてテーブルに追加でき、Dataverse が管理する Azure Blob Storage に保存されます。 アプリは Dataverse コネクタを使用して連携できるため、個別の認証や API は必要ありません。

ファイルや画像に Dataverse を使用するのは、データと直接関係があり、複数のユーザーが共同作業する必要がない場合に適しています (製品や場所の写真、法的契約の最終コピーなど)。 しかし、複数のユーザーが同時に法的契約を変更する必要がある場合は、SharePoint を使用することで、より高いコラボレーション機能を提供することができます。 セキュリティ を Dataverse とは別に管理する必要がある場合や、特定のファイル固有の機能を使用する必要がある場合は、Azure Blob Storage を直接使用することを検討してください。

統合

アプリケーションのモダナイゼーションには、多くの場合、内部または外部システムとの統合が含まれます。 統合は、データ、アプリケーション、またはプロセスに大別できます。

• データ統合では、異なるソースからのデータを組み合わせ、ユーザーに統一されたビューを提供します。 分離されたアプローチを提供しますが、ロジックやプロセスをリアルタイムで構築することはできません。 すべてのデータがローカルであるため、パフォーマンスが向上する可能性があります。

• アプリケーションの統合は、アプリケーション層で接続され、通常は API またはローコード ソリューションではコネクタを介して行われます。 アプリケーション レベルの統合では、2 つのソリューション間に明確な境界が提供されますが、多くの場合、リアルタイムの依存関係も作成されます。 このタイプの統合では、API を提供しているシステムによってアクセスを制御できるセキュリティ境界も作成されます。

• プロセス統合での各システムは、全体的なビジネス プロセスの一部です。 このタイプの統合は最も分離されているため、参加するシステムがビジネス プロセスの各部分を処理できます。 最新化のシナリオでは、最新化のプロセスの一部をローコードで分割し、レガシー システムによって処理されている他の部分と統合すると役立つ場合があります。

統合の実装方法を評価するときは、古いアプローチがモダナイズするアプリケーションに最適なアプローチであると思い込まないことが重要です。 たとえば、プロセスがリアルタイムかつ同期的な場合は、非同期的に実行できるかどうかを検討します。 クラウド ソリューションでは、同期統合がさらなる脆弱をもたらす可能性があります。 たとえば、適切なエラー処理を備えたロー コードの Power Automate フローが、統合を調整できます。 このアプローチでは、信頼性が向上するだけでなく、統合の完了を待つ必要がなくなるため、ユーザーの生産性も向上します。

次の検討事項は、既存の統合を前進させる方法を評価する際に役立ちます:

• 統合はまだ必要であり、有効ですか？ 統合の結果を誰も使用しなくなり、廃止される可能性があることがわかることは珍しくありません。

• 最新化されたアプリケーションがクラウドにある場合、接続の課題はありますか? 課題としては、待機時間や、オンプレミスの API やデータ ストアへのアクセスなどが考えられます。 場合によっては、オンプレミス データ ゲートウェイが、クラウドからのサービスまたはデータへのアクセスに役立ちます。 データやサービスへのアクセスが遅すぎる場合は、最新化されたアプリに対してデータをローカルにするか、バックグラウンドで統合を実行できるかを検討してください。

統合は、モダナイズされたアプリケーションの適切なサイズ設定にも役立ちます。 レガシー アプリケーションの 1 つ以上の部分を分割し、そのまま残したり、別のアプリケーションとして実装したりすることができます。 このアプローチは、異なるロールのユーザーがレガシー アプリケーションの異なる部分を使用する場合に適しています。 ローコードを使用して 1 つ以上のロールを実装し、プロセス統合を使用して、プロセスの残りの部分を既存のアプリケーションで処理させることができます。 このアプローチを使用すると、時間の経過とともに残りの部分を段階的に最新化できます。 また、プロセスの独立した部分を個別に実装することで、プロセスの他の部分とは独立して機能強化をロールアウトする、より機敏な方法も容易になります。

カスタム統合を進める前に、Power Apps に組み込まれている統合機能を評価する必要があります。

• Microsoft Teams: Power Apps キャンバスアプリと Copilot Studio エージェントは、Teams チャンネルに埋め込むことができます。 Teams コネクタを使用すると、アプリとフローは Teams メッセージを簡単に投稿および使用できます。 Power Apps カードはマイクロアプリのように使用して、Teams チャネルで実用的な情報を共有できます。

• SharePoint: Power Apps モデル駆動型アプリは、SharePoint ライブラリに格納されたドキュメントに接続し、Dataverse 行で利用できるように構成することができます。 Microsoft のリストまたは SharePoint リストを使用すると、ユーザーはリスト項目のコンテキストで Power Automate フローを実行できます。

• Power BI: Power BI の分析情報は、Power Apps キャンバス アプリのコンテキストで表示することができます。 モデル駆動型アプリを Power BI のレポートに埋め込むことで、ユーザーは Power BI を離れることなく分析情報に基づいた行動をとることができます。

最新化されたアプリケーションの主要なデータ リポジトリとして Dataverse を使用すると、統合に役立ついくつかの組み込み機能が提供されます。

• Dataverse のカスタム API は、インバウンド アプリケーション レベルの統合に使用できます。 カスタム API は、少量のカスタム コード ロジックに関連付けられた一意の操作を提供します。 たとえば、送信システムは RequestNewProject のカスタム API を使用することができ、関連するロジックは受信したデータを適切な Dataverse テーブルに配置する方法を把握しています。 送信システムは Dataverse テーブル構造から抽象化されます。

• アウトバウンドの統合は、Dataverse のイベント公開機能を使って行うことができます。 Dataverse は、Azure Service Bus、Azure Event Hubs、または任意の Webhook レシーバーに発行するように構成できます。 たとえば、新しい Dataverse プロジェクト テーブルの行が作成されると、Azure Service Busの キューに公開されます。 また、ビジネス プロセス イベントに一致する、より概念的なイベントを発行することもできます。 たとえば、プロジェクトの完了時にイベントを定義して公開できます。

次の図は、Dataverse 環境におけるインバウンド イベントとアウトバウンド イベントの例を示しています。

また、サードパーティが提供する Microsoft AppSource の統合オプションも検討する必要があります。 たとえば、マイクロソフトは、SAP と Power Platform を統合する必要がある企業向けに、あらかじめソリューションを用意しています。 この構築済みソリューションは、アプリとフローを組み込み、組織の SAP システムと Power Platform との間のコミュニケーションを促進する新しい機能を追加します。

たとえば、Ernst & Young は、事前構築済みの SAP 統合を使用して、頻度の高いグローバル財務プロセスを最適化するソリューションを迅速に開発しました。 次の図は、会社の PowerPost ソリューションの図で、財務ユーザーが Power Platform を使用して一般会計 SAP ERP システムにドキュメントをポストする方法を示しています。

統合接続オプション

ソリューションがクラウドに移行すると、オンプレミスのリソースへの接続が、最新化されたアプリケーションとの統合を引き続き機能させるために不可欠になる場合があります。 これらのアプリケーションは、異なるネットワーク環境に存在する可能性のある他の従来のクラウドリソースとも統合できる必要があります。 Power Platform は、データ ゲートウェイ、仮想ネットワーク データ ゲートウェイ、プライベート リンク、ExpressRoute という 4 つの主要なセキュア接続オプションをサポートしています。

• データ ゲートウェイは、Power Apps、Power Automate、Power BI のローコード コンポーネントがオンプレミスのリソースにアクセスできるようにし、ハイブリッド統合シナリオをサポートします。 ゲートウェイは、最新化されたローコード アプリケーションが、まだオンプレミスにあるデータ ソースにすばやくアクセスする方法を提供します。 ゲートウェイを使用すると、ローカル ファイル システム、DB2、Oracle、SAP ERP、SQL Server、SharePoint などのソースからオンプレミス データに接続できます。 1 つのゲートウェイで、複数のユーザーと複数のソースへのアクセスをサポートできます。 また、データ ゲートウェイをクラスターとして構成して、高可用性を実現することもできます。

  ゲートウェイのサポートはコネクタの接続プロセスに統合されており、ゲートウェイが必要なタイミングを示し、構成済みのゲートウェイを選択できます。 接続が構成されると、アプリとフローはゲートウェイがない場合と同じようにコネクタを使用できます。

  

• 仮想ネットワークのデータ ゲートウェイを使用すると、仮想ネットワーク内の仮想マシン上にオンプレミスのデータ ゲートウェイを設置しなくても、Azure 仮想ネットワーク内のデータサービスに Power BI と Power Platform のデータフローを接続できます。

• Azure Private Link と Azure ネットワークのプライベート エンドポイントにより、アプリとフローは Power BI に安全にアクセスできます。 プライベート エンドポイントは、インターネットを経由するのではなく、Microsoft のバックボーン ネットワーク インフラストラクチャを使用してデータ トラフィックをプライベートに送信するために使用されます。 プライベート エンドポイントを使用することで、レポートやワークスペースなどの組織の Power BI リソースに入るトラフィックが、常に組織の構成済みプライベート リンク ネットワーク パスに従うようになります。

• Azure ExpressRoute は、プライベート接続を使用して、オンプレミス ネットワークをマイクロソフトのクラウドサービスに接続する高度な方法を提供します。 1 つの ExpressRoute 接続で、パブリック インターネットを経由することなく、Power Platform、Dynamics 365、Microsoft 365、Azure クラウドサービスなどの複数のオンラインサービスにアクセスできます。 ExpressRoute には大規模な計画と構成が必要であり、ExpressRoute サービスと接続プロバイダーのコストが増加します。

統合接続に使用するアプローチに関係なく、接続を評価して、統合と最新化されたアプリケーションの両方をサポートするために十分な待機時間と十分な帯域幅があることを確認する必要があります。

ビジネス ロジック

最新のアプリケーションを構築する場合、ビジネス ロジックを実装する対象と、それをアプリケーション アーキテクチャのどこに実装するかを選択できます。 ガイダンスがなければ、ほとんどの組織はビジネス ロジックの混乱に陥るでしょう。 実装の一貫性を保証する再利用可能なロジックを使用すると、モダナイゼーションの取り組みを迅速化できます。

ここでは、ビジネス ロジックをユーザー エクスペリエンスのロジックとは異なるものとして定義します。 たとえば、検査データの値に基づいて画面間を移動するロジックは、ユーザー エクスペリエンス ロジックです。 検査が完了したかどうかを判断するために実装するロジックには、いくつかの条件評価が含まれる場合があり、ビジネス ロジックと見なされます。

ローコードを含むソリューションを設計する場合、次の考慮事項は、ビジネス ロジックを配置する場所を決定する際に役立ちます。

• Power Apps アプリケーション: ローコード アプリケーションにビジネス ロジックを配置するのは最もシンプルなアプローチですが、再利用に向けたオプションや、アプリやオートメーション間で一貫性を強制するオプションは限られています。 このアプローチは、一般に他のアプリケーションや自動化で使用する必要のない、ミッション クリティカルではない単純なロジックに限定する必要があります。 ローコード ツールでは、行ごとのデバッグ エクスペリエンスは提供されません。 ロジックが複数の画面にまたがっていたり、読みにくい場合は、より保守しやすい他の方法を検討する必要があります。 一部のビジネス ロジックが、アプリケーションとクラウドでローカルに複製されることは珍しくありません。 たとえば、ユーザーがホテルの予約を入力する場合、ビジネス ルールでは、チェックアウト日をチェックイン日より前にすることはできません。 アプリケーションがこれを検証しなかった場合、ユーザーは最後までたどり着き、予約を送信しても、カスタムコネクターがそれを拒否したことに気づくでしょう。 アプリケーションとクラウドでローカルに検証を処理することで、はるかに優れたユーザー エクスペリエンスが実現します。

• Power Automate クラウド フロー: フロー内のアクションでビジネス ロジックを表現できます。また、フローは、他のアプリやフローからのイベントまたはオンデマンド実行要求に応答してトリガーできます。 このフローは、ロジックを一元化するためのローコード アプローチを提供できます。 フロー内のステップは独立しており、トランザクションの一部ではありません。ただし、フローはエラーが発生した場合にロールバックを処理するための補正を実装できます。 フローは、アプリ ユーザーが実行できる以上のアクセス許可を持つ接続を使用してステップを実行できるため、アクセス許可を昇格する方法が提供されます。 このアプローチでは、アプリ ユーザーが必要とする可能性のあるアクセス許可を最小限に抑えることもできます。

• Dataverse プラグイン: プラグインは、作成、更新、削除などのデータ行イベントに応答して実行されます。 このロジックは、どのアプリやフローがアクションを実行したか、または Dataverse API から直接実行されたかに関係なく、イベントが発生するといつでも実行されます。 この動作の利点は、すべての用途で一貫性が確保されることです。 さらに、プラグイン ロジックによる Dataverse データの変更はすべてトランザクションで、すべて完了するか、すべてロールバックされます。 プラグインのロジックは、短くて効率的である必要があるため、実行時間の長い作業を実装しようとしないでください。 Close Inspection のような 1 つのビジネス イベントを完了するために複数のテーブルのイベントをリッスンする必要がある場合、イベントのプラグインは最適なアプローチではないことがあります。 たとえば、複数のテーブルにプラグインを持つ代わりに、Dataverse カスタム API を検討することもできます。 プラグインは、ユーザーが通常は持っていない可能性のある昇格されたアクセス許可でロジックを実行できます。 このアプローチでは、アプリ ユーザーが必要とする可能性のあるアクセス許可を最小限に抑えることもできます。 プラグインは、アプリやフローと一緒に Dataverse ソリューションで展開できます。

• Dataverse カスタム API: Dataverse カスタム API を使用すると、ロジックを実行できる独自のカスタム API メッセージを実装できます。 たとえば、検査の確認と終了のすべての作業を行う際に呼び出される「Close Inspection」のカスタム API を作成することができます。 イベント ドリブンではありませんが、それを必要とするアプリやフローがオンデマンドで使用します。 イベント駆動型プラグインと同様に、カスタム API プラグインで行われるデータ変更はトランザクションです。 カスタム API は、使用するサービスが他のデータ作業用の Dataverse API のみである場合に最適です。 カスタム API 用のプラグインは、アプリやフローとともに Dataverse ソリューションで展開できます。

コード API を実装する

Azure Functions、Azure Container Apps など、任意の API ホスティング ランタイムや、REST API をホストできる任意のサービスに API を実装できます。 これらのカスタム API は任意のロジックを実装でき、ローコード アプリケーションと従来のコード アプリケーションの両方で使用できます。 カスタム API は、使用する API によって提供されるもの以外のトランザクション サポートを提供しません。 たとえば、カスタム API が SQL Server を使用する場合、SQL Server トランザクション構造を使用できます。 コード API の展開は、それを使用する可能性のあるローコード リソースとは無関係です。 Azure API Management を使用すると、これらの API の使用を管理し、見つけやすくすることができます。

セキュリティ

認証や承認などのセキュリティは、最新化されたアプリケーションのアーキテクチャに不可欠な要素です。 最新のアプリケーションは、多くの場合、従来のアプリケーションよりもセキュリティ保護が困難です。 これには複数のクラウド サービスが含まれており、ユーザーはより多様な場所からそれらを操作します。 概念的には、プラットフォームにおけるセキュリティは、データとサービスを保護しつつ、ユーザーが最小限の摩擦で必要な作業を行えるようにするためにあります。

Power Platform は、セキュリティ アーキテクチャを構築するために使用できる、セキュリティに対する多層的なアプローチを採用しています。 これらの機能の中核となる考え方は、ローコード ソリューションを既存のセキュリティ装置と統合して、導入による影響を最小限に抑えることです。

Power Platform セキュリティ モデルを構成する複数のセキュリティ レイヤーの概要をご案内します。

• ユーザーは Microsoft Entra ID によって認証されており、使用は条件付きアクセス ポリシーによって制限できます。
• ライセンスは、Power Platform コンポーネントへのアクセスを許可する最初のコントロール ゲートです。
• アプリケーションとワークフローを作成する機能は、環境のコンテキストでのセキュリティ ロールによって制御されます。
• ユーザーが Power Platform リソースを表示および使用できるかどうかは、アプリケーションをユーザーと共有することで制御されます。 リソースは、ユーザーまたは Entra ID グループと直接共有されます。
• 環境はセキュリティ境界として機能するため、各環境に異なるセキュリティのニーズを実装できます。
• Power Automate フローとキャンバス アプリはコネクタを使用します。 特定の接続資格情報と、関連するサービスの権利によって、アプリがコネクタを使用する際のアクセス許可が決まります。
• Dataverse のインスタンスを持つ環境は、その Dataverse インスタンス内のデータとサービスへのアクセスを制御するより高度なセキュリティ モデルをサポートします。
• コネクタの使用は、データ損失防止 (DLP) ポリシーでさらに制限できます。 クロステナント型の受信および送信の制限はコネクタにも適用できます。

コネクタを使用してデータ ソースにアクセスする場合、データ ソースが提供する基盤となるセキュリティすべては、上記で説明したセキュリティの層に追加されることに注意してください。 Power Apps と Power Automate は既定で、ユーザーがまだ持っていないコネクタ データソースへのアクセスを提供しません。 ユーザーは実際にアクセスを必要とするデータへのアクセスのみが必要です。

Dataverse をソリューションの一部として使用する場合、多くのビジネス シナリオに適応できるロールベースのセキュリティ モデルが含まれます。 データは、データ行の個々の列に至るまでセキュリティで保護できます。 ユーザーには 1 つ以上のセキュリティ ロールが割り当てられ、これらによって全体的な特権が決定されます。 Dataverse は部署やチームなどのセキュリティ モデリングの構成要素を提供します。 たとえば、部署を使用してセキュリティ境界を定義し、組織のユーザーの 2 つの異なるグループ間でデータを分離できます。 チームを使用して、データへの同様のアクセスを必要とするユーザーをグループ化できます。 データ行のグループ所有権を割り当てることもできます。 次の図は、部署を使用して組織の部門のデータを分離する方法を示しています。

セキュリティ モデルの設計

最新化されたアプリケーションのセキュリティ モデルを、アプリケーションのアーキテクチャ全体に合わせて調整します。 単一のデータ リポジトリを使用し、コネクタを使用しないアプリケーションでは、最小限のセキュリティ設計作業で済みます。 アプリケーションがより多くのコネクタとデータ リポジトリを使用するようになると、セキュリティ モデリングに他の考慮事項を含める必要があります。

• ユーザー ID: オンプレミスに由来するシナリオでは、ユーザーはどのように認証し、Microsoft Entra ID にマッピングされていますか？ これには、Dataverse のようなクラウド データストアでアプリケーション グループやチームの割り当てをサポートするために必要なグループのマッピングが含まれます。

• コネクタ接続 ID: アプリケーションが 1 つ以上のコネクターを使用する場合、接続に対してどのようなタイプの認証が行われ、 必要なセキュリティ管理を実施するために必要なレベルの管理が行われていますか？ たとえば、サービス プリンシパルを使用して接続するアプリケーションでは、アプリケーションのユーザーがコネクタに直接アクセスする必要がないため、シナリオによってはこれが有益な場合があります。 個々のユーザー接続は、どのユーザーが操作を実行したかを把握する必要があるアプリケーションや、特定のユーザーに応答のスコープを設定する必要があるアプリケーションに適しています。

• セキュリティ構造の移植性: アプリケーションがより多くのコネクターやデータ リポジトリを使用するようになると、あるコネクタのセキュ リティ構成がすべてそのまま別のコネクタに対応するわけではないことを覚えておくことが重要です。 たとえば Dataverse では、ユーザーがデータ行にアクセスする方法は複数あり、ユーザーとデータ行を共有することもできます。 アプリケーションが SharePoint のドキュメント ライブラリと行を関連付けている場合、ドキュメント ライブラリにアクセスするためのセキュリティは、Dataverse のアクセスを制御するセキュリティとは別になります。 これらは直接マッピングされません。 モダナイズされたアプリケーションは、使用するコネクタとデータ リポジトリ全体でこれらの種類の不一致に対応する必要があります。

人工知能

ここ数年、AI はアプリケーションのモダナイゼーションの取り組みに導入されるようになってきました。 アプリケーションをモダナイズする際には、ユーザーの生産性を向上させ、より適切な意思決定ができるよう支援する人工知能の活用を検討する必要があります。 AI を導入した結果は、より良い顧客体験にもつながり、それがビジネス成果に好影響を与えることもあります。

AI を含めるには、以前はアプリケーション ロジックの統合とカスタム トレーニングモデルの構築に手間のかかる作業が必要でした。 大規模言語モデルの可用性と能力により、アプリケーションはユーザーが答えを見つけたり、タスクを実行したりするのを助ける新しい AI の使い方を導入できるようになりました。 ユーザーは自然言語プロンプトを使用して、幅広い支援ビジネス シナリオで AI 機能を操作できます。

Microsoft は、高度な AI 技術へのアクセスを容易にするために、コア製品とサービスにコパイロットを導入しました。 Copilot は最新の AI 技術と大規模な言語モデルを使用しており、Microsoft 365、Windows、Dynamics 365、Power Platform など、ユーザーが毎日使用するアプリケーションで操作することができます。

プラグインで拡張する

Copilot を利用したアプリケーションのユーザーは、アプリケーションの一般的なタスクについて Copilot に支援を求めることができます。 コパイロットを拡張して、ユーザーがまだ知らないデータやタスクや、ユーザーが操作しているアプリの範囲を超えているデータやタスクを含めることができます。 Microsoft 365 の Copilot は Dataverse に保存されている Power Platform のデータを取り込むことができるため、ユーザーはアプリケーション間を行き来する必要がありません。 たとえば、Outlook から、ユーザーは Copilot に、今日完了したすべての失敗した検査のステータス更新を生成するように依頼できます。 Microsoft 365 Copilotは、Dataverse のネイティブ セキュリティおよびガバナンス フレームワークを自動的に継承し、実行時にユーザー セキュリティと権限を適用します。

プラグインとしてのコネクタ

Power Platform コネクタも Copilot のエクスペリエンスにとって重要です。 コネクタはプラグインとして接続し、Copilot の機能を拡張できます。 たとえば、Jira Software に対応した Power Platform コネクタを備えた Microsoft 365 Copilot を使用すると、プロジェクト マネージャーは Jira のサポートチケットのステータスを要求し、その応答に基づいて行動することができます。 プラグインを使用すると、ビジネス プロセスとデータを Copilot と統合して、ユーザーが使用するどのアプリからでも操作できるようになります。

オリジナルのコパイロットを作成する

ユーザーがアプリに Copilot AI の支援があることに慣れていくにつれ、すべてのアプリケーションに Copilot AI の支援があることを期待するようになります。 AI 開発フレームワークである Copilot スタックで作成したコパイロットを含めることで、最新のアプリケーションをより魅力的なものにすることができます。

Power Apps に事前に組み込まれている Copilot コントロールを使用して、キャンバス アプリやモデル駆動型アプリにコパイロットを追加できます。 データソースのビューといくつかの基本的なプロンプト情報を設定することで、独自のアプリ内コパイロットのエクスペリエンスをすばやく提供できます。

アプリケーション ライフサイクル管理

モダナイゼーション作業の重要な部分は、適切なアプリケーション ライフサイクル管理プロセスを確立することです。 多くの場合、組織はローコードの取り組みを、従来のコード ALM での作業方法に適合させたいと考えます。 Power Platform には ALM ツールが用意されているため、通常使用するプロセス内またはプロセスと並行してローコードの成果物を含めることができます。

Power Platform の ALM は、ローコード リソースの構築をサポートします。 構築するリソースは、Power Platform 環境のコンテキストにあります。 環境は 1 つの Dataverse データ ストアを持つことができます。 複数の環境 (通常は開発、テスト、運用) を使用して、ローコードを含む ALM プロセスにランディング ゾーンを実装できます。 環境の数と目的は柔軟であり、組織は個々のプロジェクトのニーズに合わせて環境を調整できます。 Dataverse のソリューションは、関連するローコード リソースのコンテナであり、バージョン管理やある環境から別の環境への移行を容易にします。

Power Platform パイプラインは、展開を自動化し、継続的インテグレーションと継続的デリバリー (CI/CD) を実装するローコードのアプローチを提供します。 Power Platform はパイプライン構成時のプロセスを管理します。 管理者は、パイプラインを一元的に管理および統制できます。

組織は、選択した CI/CD ツールを使用することもできます。 Power Platform CLI は、ほとんどの CI/CD 自動化ツールで使用できるコマンドライン ツールです。 Power Platform Build Tools は GitHub 用のアクションと Azure DevOps 用のタスクを提供し、ローコード成果物を含む CI/CD オートメーションのビルドに必要なすべての一般的なアクションを提供します。

次の図は、調査アプリを構築するチームの例を示しています。 内側のループでは、開発環境で作業し、作業内容を Git リポジトリに保存します。 外側のループは、テスト環境と運用環境で構成されます。 ビルド パイプラインは、バージョン管理されたソリューションを取得し、必要なチェックを実行し、検査ソリューション成果物を生成します。 その後、リリース パイプラインによってソリューションがテスト対象に展開され、テスターは運用環境の準備ができていることを確認できます。 承認されると、リリース パイプラインによってソリューションが運用環境に展開されます。

Dataverse からソリューションをエクスポートすると、1 つの圧縮ファイルとしてエクスポートされます。 ローコード リソースをバージョン管理に格納するには、ビルド ツールを使用して、ソリューション ファイルを個々のコンポーネント ファイルにアンパックします。 ビルドの自動化中に、ビルド ツールはバージョン管理の個々のファイルを 1 つの圧縮ファイルに結合します。

以前のバージョンのソリューションを含む環境へのソリューションの展開では、変更のみを適用するインテリジェントなアップグレード プロセスが使用されます。 このアップグレード プロセスにより、差分スクリプトやその他の方法で展開する必要があるものを決定する必要がなくなります。

モダナイズされたアプリケーションにローコードと従来のコード リソースが含まれている場合、それらを 1 つの CI/CD プロセスに組み合わせたり、個別に管理したりできます。 独立した管理により、リソースを個別に展開でき、プロジェクトチームは機敏性を高めることができます。 たとえば、ローコード アプリケーションが使用する API は、チームが破壊的変更を導入しなければ、個別に展開できます。

監視と分析情報

モダナイズされたアプリケーションは、開発から運用まで、さまざまな環境にわたる問題を診断する機能を提供する運用環境へと統合する必要があります。 Application Insights は、Azure Monitor の拡張機能で、Power Apps と Dataverse からテレメトリを収集します。 この情報は、問題の特定と解決に役立つだけでなく、ユーザーがアプリケーションで何を行うかについての分析情報も提供します。 これらの分析情報を使用して、最新化されたアプリケーションのアプリとプロセスを改善することができます。

Power Apps アプリケーションの開発中に、開発者はカスタム イベントを記録するロジックを含めることができます。 展開されたアプリケーションを Application Insights に接続した後、拡張機能は、ユーザーがアプリケーションを操作する際に、ログに記録されたイベントからより多くのコンテキストを含む基本的な遠隔測定を自動的に収集します。

管理者は Dataverse 環境が Application Insights にテレメトリをエクスポートするように構成することもできます。 ログに記録されるデータには、Dataverse API の呼び出し、プラグインの実行、SDK 操作、例外などが含まれます。 カスタム プラグインのロジックを作成する開発者は、より多くのカスタム遠隔測定データを直接 Application Insights に記録できます。

アプリケーション全体で Application Insights を使用することで、複数のリソースの問題を簡単に関連付けることができます。 運用スタッフは、Azure Monitor でアラートを作成して、多数の例外が検出されたときにトリガーできます。 モダナイズされたアプリケーションを定期的に分析することで、さらに調査が必要な傾向を特定できます。

結論

このホワイトペーパーでは、Microsoft Power Platform を使用してレガシー アプリケーションを最新化するメリット、戦略、ベスト プラクティスについて掘り下げました。 組織のデジタル トランスフォーメーションの一環として、最新化の取り組みを成功させるために Power Platform のローコード機能を採用する分析情報とガイダンスを得ることができました。

レガシーアプリケーションは、組織に多くの課題をもたらします。 それらを克服するために、組織はアプリケーションのモダナイゼーションのイニシアチブに着手して、インフラストラクチャを活性化し、最新のテクノロジーを活用する必要があります。 このホワイトペーパーでは、最新化の取り組みにローコードアプローチを採用する方法、特に Microsoft Power Platform のローコード開発機能によってモダンなアプリケーションを迅速に構築して展開する方法について説明しました。

ローコードは、従来のコーダーよりも幅広い層の人々への扉を開きます。 ローコード アプローチで成功する組織の重要な要素は、アプリケーションのモダナイゼーションに関わる人々が、プロの開発者であれビジネスユーザーであれ、ローコード開発のトレーニングを受けていることを徹底することです。 ビジネスユーザーは、解決しようとしているビジネス上の問題に近づき、時間を節約する専門知識を提供することができます。 従来のコード開発者は、拡張機能を構築するためにすでに持っている手法とスキルを適用して、ローコードのギャップを埋めることができます。 私たちが「フュージョン チーム」と呼ぶものにビジネスと技術のリソースを組み合わせることで、組織は最も効果的に機能します。

このホワイトペーパーでは、皆さんの基礎となる要素をご案内しています。 次のステップはあなた次第です。 いくつかの推奨事項を次に示します:

• 若干の時間を取って、あなたの組織がすでにローコードで何を行っているかを確認してください。 びっくりするかもしれません。
• アプリケーションのモダナイゼーションの機会を評価します。
• 最初の候補として適切なものを特定し、優先順位を付けます。
• アプリケーションを最新化するチームを配置します。 最良の結果を得るには、必ずフュージョン チームを使用してください。
• チームが成功するために必要なトレーニングを受けていることを確認してください。
• チームがアプリケーションを最新化できるようにしてください。
• 最新化の取り組みを振り返ってください。 それを改良し、他のレガシー アプリケーションに拡張してください。

アプリケーションのモダナイゼーションへの道のりは、組織ごとに異なります。 マイクロソフトのアカウントチームまたは Power Platform パートナーは、皆さんの体験を計画し、正しい道を歩むお手伝いをします。

リソース

• Microsoft Power Platform のプレミアム機能がもたらす経済効果™
• アメリカン航空の ConnectMe アプリは、お客様によりスムーズな旅行体験を、チームメンバーにはより優れたテクノロジーツールを提供しています
• Power Fx GitHub のオープンソース リポジトリ
• CoE スターター キット
• Power Platform 導入の評価
• デジタル保険代理店は、Power Platform を利用して複雑な購買プロセスを自動化しています
• PCF ギャラリー
• EY 社では、Power Platform の導入により、グローバルな財務プロセスにおけるソース入力が可能になり、リードタイムを 95% 短縮しました
• Azure Private Link
• Microsoft Azure ExpressRoute
• Power Platform リリース プランナー
• Microsoft Power Platform のライセンス ガイド
• Microsoft は、AI アプリと Copilot を構築するフレームワークの概要を発表し、AI プラグインのエコシステムを拡大しました