Power Pages でシングルページアプリケーションを作成して展開する

Power Pagesでは、GitHub Copilotなどの次世代の AI 支援ツールを使用して作成されたシングルページアプリケーション (SPA) コードの統合がサポートされています。この機能により、開発者は自然言語をコーディングインターフェイスとして使用して、最新のコンポーネントベースのフロントエンドエクスペリエンスをPower Pagesに取り込むことができます。

AI が生成したコードを導き、テストし、洗練させることで、作成者は反復的な実装作業から、より高度なオーケストレーションに重点を移すことができます。このアプローチにより、エンタープライズレベルの品質と標準を維持しながら、より直感的でクリエイティブな開発が可能になります。

この記事では、次の方法について説明します:

Power Platform CLI (PAC CLI) を使用してPower Pages用の SPA プロジェクトを作成して設定します。
Power Pages サイトにコード資産をアップロードしたり、ダウンロードしたりします。
安全で保守しやすいプロジェクト構造を設定します。
SPA ベースの実装と従来のPower Pages実装の主な違いについて説明します。

Note

SPA サイトは、ユーザーのブラウザー (クライアント側のレンダリング) で完全に実行されるPower Pages サイトです。従来のPower Pages サイトとは異なり、SPA サイトはソースコードとコマンドラインインターフェイス (CLI) ツールを使用してのみ管理します。
Power Platform Git 統合は、Power Pages の Single-Page アプリケーション (SPA) Web サイトではサポートされていません。

前提条件

開始する前に、以下の項目があることを確認します:

管理者特権を持つ Power Pages 環境。
Power Platform CLI (PAC CLI) バージョン 1.44.x 以降がインストールされ、認証されました。
バージョン 9.7.4.x 以降の Power Pages サイト。
Dataverse 環境での JavaScript ファイルのアップロードを許可します。
React、Angular、Vue などのカスタムフロントエンドプロジェクトを含むローカル Git リポジトリ。

JavaScript ファイルのアップロードを許可する

既定では、一部の Dataverse 環境では JavaScript (.js) ファイルのアップロードがブロックされます。 "インポートに失敗しました: 添付ファイルが有効な種類ではないか、大きすぎます。アップロードまたはダウンロードできません。このファイルの種類を許可するように環境設定を更新してください。

環境の Power Platform 管理センターで設定を調整するには、次の手順に従います:

Power Platform 管理センターにサインインします。
ナビゲーションウィンドウで、[管理] を選択 します。
管理ウィンドウで環境を選択します。
環境を選択します。
コマンドバーで、設定を選択します。
製品を展開し、プライバシー + セキュリティ を選択します。
[ ブロックされた添付ファイル] セクションで、ファイル拡張子の一覧から js を削除します。
保存を選びます。

SPA サイトの作成と展開

Power Pages SPA サイトは、PAC CLI コマンド upload-code-site と download-code-site を使用して管理されます。サイトをアップロードすると、Power PagesInactive sites リストに表示されます。サイトのライセンス認証を行ってユーザーが利用できるようにします。

SPA サイトのアップロード

pac pages upload-code-site コマンドを使用して、ローカルソースとコンパイル済みアセットをPower Pages環境にアップロードします。

構文

pac pages upload-code-site `
  --rootPath <local-source-folder> `
  [--compiledPath <build-output-folder>] `
  [--siteName <site-display-name>]

Parameters

パラメーター	エイリアス	必須	Description
`--rootPath`	`-rp`	Yes	サイトのソースファイルを含むローカルフォルダー
`--compiledPath`	`-cp`	No	React などのコンパイル済みアセットへのパス `build`
`--siteName`	`-sn`	No	Power Pages サイトの表示名

Example

pac pages upload-code-site `
  --rootPath "../your-project" `
  --compiledPath "./build" `
  --siteName "Contoso Code Site"

既存のプロジェクトがない場合は、 React、Angular、Vue を使用して SPA サイトのサンプル実装を試してください。

アップロードパラメーターを`powerpages.config.json`で定義する

サイトのルートフォルダーにupload-code-site ファイルを含めることで、powerpages.config.json コマンドの動作をカスタマイズします。このファイルが存在する場合は、upload-code-site パラメーターのみを使用して--rootPathを実行します。このコマンドは、構成ファイルから残りの値を読み取ります。コマンドライン引数と構成値の両方を指定すると、コマンドライン引数が優先されます。

構成フィールド

フィールド	タイプ	必須	Description
`siteName`	文字列	Yes	Power Pages サイトの表示名。
`compiledPath`	文字列	Yes	`dist`を基準にしてコンパイルされた出力ディレクトリ (Vite `build` や React `powerpages.config.json` フォルダーなど) へのパス。
`defaultLandingPage`	文字列	Yes	`compiledPath` (通常は`index.html`) を基準にして、サイトルートを開いたときに提供される HTML ページ。
`bundleFilePatterns`	string[]	No	新しいビルドをアップロードする前に CLI によって削除される、サイトの `web-files` 内のファイルを識別するワイルドカードパターンの一覧。古いアセットがサイトに蓄積されないように、古いコンテンツハッシュバンドルをクリーンアップするには、このフィールドを使用します。コードの分割とバンドルのクリーンアップを参照してください。
`includeSource`	boolean	No	`true`すると、コマンドはコンパイル済みのアセットに加えてソースコードをアップロードします。既定値は `false` です。
`sourceExcludePatterns`	string[]	No	アップロードから除外するソースファイルのワイルドカードパターン。 `includeSource`が`true`されている場合にのみ適用されます (たとえば、`node_modules`やローカル環境ファイルをスキップする場合)。

最も正確で最新のフィールド参照については、powerpages.config.json スキーマを参照してください。一致する $schema プロパティを構成ファイルに追加して、JSON スキーマをサポートするエディターで検証とオートコンプリートを有効にします。

サンプル `powerpages.config.json`

{
  "$schema": "https://www.schemastore.org/powerpages.config.json",
  "siteName": "Contoso Bank",
  "compiledPath": "dist",
  "defaultLandingPage": "index.html",
  "bundleFilePatterns": [
    "index-*.js",
    "index-*.css"
  ]
}

SPA サイトをダウンロードする

pac pages download-code-site コマンドを使用して、編集やバックアップのために既存のサイトのコードをローカルディレクトリにダウンロードします。

構文

pac pages download-code-site `
  [--environment <env-url-or-guid>] `
  --path <local-target-folder> `
  --webSiteId <site-guid> `
  [--overwrite]

Parameters

パラメーター	エイリアス	必須	Description
`--environment`	`-env`	No	Dataverse 環境 (GUID または完全な URL)。既定はアクティブな認証プロファイルです
`--path`	`-p`	Yes	サイトコードをダウンロードするローカルディレクトリ
`--webSiteId`	`-id`	Yes	Power Pages SPA サイトの Web サイトレコード GUID
`--overwrite`	`-o`	No	ターゲットディレクトリに既存のファイルがある場合は上書きします

Example

pac pages download-code-site `
  --environment "https://contoso.crm.dynamics.com" `
  --path "./downloaded-site" `
  --webSiteId "11112222-bbbb-3333-cccc-4444dddd5555" `
  --overwrite

サイトをアクティブ化してテストする

Power Pages に移動します。
非アクティブなサイトを選択し、サイトを見つけて、再アクティブ化を選択します。
サイトがアクティブになったら、サイトの URL にアクセスして展開を確認します。

Tip

それ以降の upload-code-site コマンドは、自動的にアクティブなサイトを更新します。

プロジェクト構造と構成

一貫性のあるプロジェクトレイアウトは、正しいアップロード動作の保証に貢献します。

/your-project
│
├─ src/                       ← Your source code, like React components
├─ build/                     ← Compiled assets, output of the `npm run build` command
├─ powerpages.config.json     ← Optional CLI configuration file
└─ README.md

オプションの powerpages.config.json ファイルを使用して、upload-code-site コマンドの動作方法をカスタマイズします。

コード分割とバンドルのクリーンアップ

シングルページアプリケーションが拡大すると、1 つの JavaScript バンドルが大きくなり、読み込みに時間がかかります。最新のビルドツールは 、コード分割でこの問題を解決します。この手法により、ブラウザーがオンデマンドでダウンロードする小さな チャンク にアプリが分割されます (たとえば、ユーザーが特定のルートに移動した場合のみ)。各チャンクはファイル名に コンテンツハッシュ ( Dashboard-BSbmIXoe.js など) で出力されるため、ブラウザーは長期間キャッシュし、コンテンツが変更されたときにのみ再ダウンロードできます。

コード分割では、Power Pages SPA サイトに固有の展開の考慮事項が導入されています。すべてのビルドで新しいハッシュファイル名が生成されるため、upload-code-site の実行を繰り返すと、古いハッシュされたファイルはサイトに残ります。何度も展開を繰り返すうちに、こうした孤立したチャンクがサイトの web-files に蓄積されます。 bundleFilePatterns内の powerpages.config.json フィールドは、それらをクリーンアップするために存在します。

コード分割を有効にする

コード分割は、Power Pagesではなくフロントエンドビルドツールによって処理されるため、このアプローチは使用するフレームワークとバンドルによって異なります。最も一般的な手法は、動的インポートを使用してアプリの一部を読み込み、多くの場合、ルートまたはビューレベルで適用され、各セクションがユーザーが移動したときにのみダウンロードされるようにすることです (遅延読み込み)。

Vite、webpack、esbuild などのバンドルは、モジュールを名前付きチャンクに明示的にグループ化することもできます。正確な構成については、フレームワークとバンドルのドキュメントを参照してください。

dist/assets/
├─ index-BJltBIP-.js        ← app entry
├─ index-DMwMk7hv.css       ← styles
├─ Dashboard-BSbmIXoe.js    ← lazy route chunk
├─ InvoiceList-DwjrGrAI.js  ← lazy route chunk
└─ InvoiceDetail-D3DVGkeM.js← lazy route chunk

どちらの方法を選択しても、結果は同じであり、デプロイに重要な部分です。ビルドは複数の出力ファイルを出力し、それぞれが名前にコンテンツハッシュを含みます。これらのハッシュはファイルの内容が変更されるたびに変更されるため、ビルドごとに異なるファイル名のセットが生成されます。次のセクションでは、名前の変更に合わせて Dataverse 環境をクリーンに保つ方法について説明します。

`upload-code-site` が古いバンドルをクリーンアップする方法

コンパイル済みアセットをアップロードする前に、upload-code-siteは、web-filesのワイルドカードパターンに一致するサイトのbundleFilePatterns内のすべてのファイルを削除してから、現在のビルドをアップロードします。この delete-then-upload 動作により、デプロイされたファイルセットは、前のビルドの上に各ビルドを重ねて配置するのではなく、最新のコンパイル済み出力と同じに保たれます。

クリーンアップを機能させるには、 bundleFilePatterns のワイルドカードパターンがビルドで出力されるファイル名と一致している必要があります。ビルドツールでファイルの名前を付ける方法に応じて、正確に保つ方法は 2 つあります。

オプション 1: ワイルドカードパターンを直接一覧表示する

多くのビルドツールでは、安定した名前プレフィックスが保持され、 index-[hash].jsなどのコンテンツハッシュのみが変更されます。出力ファイル名が次のような予測可能なパターンに従う場合は、 bundleFilePatternsの各パターンのワイルドカードパターンを一覧表示します。追加のツールは必要ありません。

{
  "$schema": "https://www.schemastore.org/powerpages.config.json",
  "siteName": "Contoso Bank",
  "compiledPath": "dist",
  "defaultLandingPage": "index.html",
  "bundleFilePatterns": [
    "index-*.js",
    "index-*.css"
  ]
}

index-*.jsなどのワイルドカードパターンは、ハッシュに関係なく、すべてのビルドでそのファイルと一致します。出力ファイルごとに 1 つのエントリを追加し、ビルドで新しい出力ファイルの生成が開始されるたびに新しいパターンを追加します。

オプション 2: ビルド後スクリプトを使用してワイルドカードパターンを生成する

この方法は、出力ファイル名が予測可能なパターンに従わない場合、またはルートの追加と削除時に名前が変更される多数のファイルをアプリが生成する場合に使用します。これにより、手動で管理されるリストのエラーが発生しやすくなります。ビルド後に実行される短いスクリプトは、コンパイルされた出力をスキャンし、出力される各ファイルのワイルドカードパターンで bundleFilePatterns を書き換えます。たとえば、ビルドツールでファイルに[name]-[hash].[ext]として名前を付けると、スクリプトはパターン Dashboard-BSbmIXoe.jsにDashboard-*.jsを減らします。

scripts/postbuild.js:

#!/usr/bin/env node

/**
 * Post-build script: scans dist/assets/ and updates powerpages.config.json
 * with bundleFilePatterns that match all Vite-generated chunks.
 *
 * This ensures `pac pages upload-code-site` cleans up old hashed bundles
 * on each deploy instead of accumulating stale files.
 *
 * Usage: node scripts/postbuild.js
 * Or via npm: "postbuild": "node scripts/postbuild.js" in package.json
 */

import { readdirSync, readFileSync, writeFileSync } from 'fs'
import { join } from 'path'

const ROOT = join(import.meta.dirname, '..')
const DIST_ASSETS = join(ROOT, 'dist', 'assets')
const CONFIG_PATH = join(ROOT, 'powerpages.config.json')

// Vite output format: [name]-[hash].[ext]
// We want to extract "name" and "ext" to produce "name-*.ext" patterns
const HASH_PATTERN = /^(.+)-[A-Za-z0-9_-]{6,12}\.(js|css)$/

try {
  const files = readdirSync(DIST_ASSETS)
  const patternSet = new Set()

  for (const file of files) {
    const match = file.match(HASH_PATTERN)
    if (match) {
      const [, baseName, ext] = match
      patternSet.add(`${baseName}-*.${ext}`)
    }
  }

  const patterns = [...patternSet].sort()

  if (patterns.length === 0) {
    console.log('No hashed bundles found in dist/assets/ — skipping config update.')
    process.exit(0)
  }

  // Read current config
  const config = JSON.parse(readFileSync(CONFIG_PATH, 'utf-8'))
  const oldPatterns = config.bundleFilePatterns || []

  // Check if update is needed
  const oldSet = new Set(oldPatterns)
  const newSet = new Set(patterns)
  const changed = oldSet.size !== newSet.size || [...newSet].some(p => !oldSet.has(p))

  if (!changed) {
    console.log(`bundleFilePatterns already up-to-date (${patterns.length} patterns).`)
    process.exit(0)
  }

  // Update config
  config.bundleFilePatterns = patterns
  writeFileSync(CONFIG_PATH, JSON.stringify(config, null, 2) + '\n', 'utf-8')

  console.log(`Updated powerpages.config.json with ${patterns.length} bundle patterns:`)
  for (const p of patterns) {
    console.log(`  ${p}`)
  }
} catch (err) {
  console.error('postbuild error:', err.message)
  process.exit(1)
}

スクリプトをビルドに接続して、バンドルの後で常に実行されるようにします。

{
  "scripts": {
    "build": "tsc -b && vite build && node scripts/postbuild.js"
  }
}

これによって、展開は 2 つのコマンドで済むようになるため、サイトに孤立したチャンクが蓄積されることもなくなります。

npm run build
pac pages upload-code-site --rootPath .

ビルド後、 powerpages.config.json には現在のバンドルが正確に反映されます。次に例を示します。

{
  "$schema": "https://www.schemastore.org/powerpages.config.json",
  "siteName": "Contoso Bank",
  "compiledPath": "dist",
  "defaultLandingPage": "index.html",
  "bundleFilePatterns": [
    "Dashboard-*.js",
    "InvoiceDetail-*.js",
    "InvoiceList-*.js",
    "index-*.css",
    "index-*.js"
  ]
}

認証と承認

POWER PAGES SPA サイトでは、従来のPower Pages サイトと同じセキュリティモデルを使用します。

ID プロバイダーを構成する

Power Pages に移動します。
サイトを検索し、編集を選択します。
[ セキュリティ>識別プロバイダー] を選択します。
Microsoft Entra IDのように、identity プロバイダーを追加または設定します。
新しい各サイトには、既定のMicrosoft Entra ID プロバイダーが自動的に設定されます。

コードでユーザーコンテキストにアクセスする

クライアントで認証メタデータを取得する:

オーソリティ URL:

Microsoft Entra IDの機関またはサインイン URL は次のとおりです。
```
https://login.windows.net/<tenantId>
```
他の構成済みのIDプロバイダーのAuthority URLを見つけるには、Power Pages><your site>>セキュリティ>IDプロバイダー>の構成設定に移動してください。

ユーザーの詳細:

window["Microsoft"].Dynamic365.Portal.User

サンプルの React フロー

import { IconButton, Tooltip } from '@mui/material';
import {
    Login,
    Logout
} from '@mui/icons-material';
import React from 'react';
export const AuthButton = () => {
    const username = (window as any)["Microsoft"]?.Dynamic365?.Portal?.User?.userName ?? "";
    const firstName = (window as any)["Microsoft"]?.Dynamic365?.Portal?.User?.firstName ?? "";
    const lastName = (window as any)["Microsoft"]?.Dynamic365?.Portal?.User?.lastName ?? "";
    const tenantId = (window as any)["Microsoft"]?.Dynamic365?.Portal?.tenant ?? "";
    const isAuthenticated = username !== "";
    const [token, setToken] = React.useState<string>("");

    React.useEffect(() => {
        const fetchAntiForgeryToken = async (): Promise<string> => {
            try {
                const tokenEndpoint = "/_layout/tokenhtml";

                const response = await fetch(tokenEndpoint, {});

                if (response.status !== 200) {
                    throw new Error(`Failed to fetch token: ${response.status}`);
                }

                const tokenResponse = await response.text();                
                const valueString = 'value="';
                const terminalString = '" />';
                const valueIndex = tokenResponse.indexOf(valueString);

                if (valueIndex === -1) {
                    throw new Error('Token not found in response');
                }

                const requestVerificationToken = tokenResponse.substring(
                    valueIndex + valueString.length,
                    tokenResponse.indexOf(terminalString, valueIndex)
                );

                return requestVerificationToken || '';
            } catch (error) {
                console.warn('[Impersonation] Failed to fetch anti-forgery token:', error);
                return '';
            }
        };

        const getToken = async () => {
            try {
                const token = await fetchAntiForgeryToken();
                setToken(token);
            } catch (error) {
                console.error('Error fetching token:', error);
            }
        };
        getToken();
    }, []);

    return (
        <div className="flex items-center gap-4">
            {isAuthenticated ? (
                <>
                    <span className="text-sm">Welcome {firstName + " " + lastName}</span>
                    <Tooltip title="Logout">
                        <IconButton color="primary" onClick={() => window.location.href = "/Account/Login/LogOff?returnUrl=%2F"}>
                            <Logout />
                        </IconButton>
                    </Tooltip>
                </>
            ) : (
                <form action="/Account/Login/ExternalLogin" method="post">
                    <input name="__RequestVerificationToken" type="hidden" value={token} />
                    <Tooltip title="Login">
                        <IconButton name="provider" type="submit" color="primary" value={`https://login.windows.net/${tenantId}/`}>
                            <Login />
                        </IconButton>
                    </Tooltip>
                </form>
            )}
        </div>
    );
};

Power Pages Web API を使用する

開発者は、Power Pages Web API を使用して、UI にコンテンツを読み込んだり、レコードを作成、更新、削除したりできます。これらの API を使用する前に、必要な Web API が有効になっており、適切なテーブルのアクセス許可と Web ロールが正しく構成されていることを確認してください。


// Create query to get all cards from Dataverse
const fetchCards = async () => {
    const response = await fetch("/_api/cr7ae_creditcardses");
    const data = await response.json();
    const cards = data.value;
    const returnData = [];

    // Loop through the cards and get the name and id of each card
    for (let i = 0; i < cards.length; i++) {
        const card = cards[i];
        const cardName = card.cr7ae_name;
        const cardId = card.cr7ae_creditcardsid;
        const features = card.cr7ae_features
            ?.split(',')
            .map((feature: string) => feature.trim());
        const type = card.cr7ae_type;
        const image = card.cr7ae_image;
        const category = card.cr7ae_category
            ?.split(',')
            .map((cat: string) => cat.trim());
        
        // ...additional processing/pushing to returnData...
    }

    return returnData;
};

Microsoft Entra ID 認証を使用して localhost からの Web API 呼び出しを有効にして、ローカル開発を設定する

開発者は、アプリケーションのビルド時に、より高速な反復サイクル、ローカルデバッグ、ホットリロード機能を必要とします。 SPA では、Microsoft Entra ID (Azure AD) v1 認証を使用して localhost からのセキュリティで保護された Web API 呼び出しを有効にすることで、これらのワークフローをサポートしています。

このセットアップでは、次のことができます。

完全な認証サポートを使用して、アプリをローカルで実行します。
ホットリロードや迅速なフィードバックには 、Vite などの最新の開発ツールを使用します。
Power Pages Web API を呼び出すときに CORS の問題を回避する。
ポータルに変更をデプロイすることなく、開発を高速化します。

この構成により、SPA の生産性の高いローカル開発エクスペリエンスが可能になるため、開発者は完全な API アクセスと認証のサポートを使用して迅速にビルド、テスト、反復処理を行うことができます。

Important

認証には Microsoft Entra v1 エンドポイントのみを使用します。
ベアラー認証は、ポータルバージョン 9.7.6.6 以降でのみサポートされます。
これらの設定は開発環境でのみ適用します。

コンフィギュレーションの手順

SPA 認証を有効にする
1. Azure portal で、ポータルに登録されているMicrosoft Entra アプリを開きます。
2. シングルページアプリケーション (SPA) 認証を有効にします。
3. localhost プラットフォーム構成を使用して、リダイレクト URI としてを追加します。詳細については、「アプリケーションにリダイレクト URI を追加する方法」を参照してください。
  - リダイレクト URI: http://localhost:<port>/。

サイト設定を追加する

Power Pages に次のサイト設定を追加します。

Authentication/BearerAuthentication/Enabled = true
Authentication/BearerAuthentication/Protocol = OpenIdConnect
Authentication/BearerAuthentication/Provider = AzureAD

認証に ADAL.js を使用する
- ADAL.jsを使用してクライアント側認証を実装します。
Note

Power Pages では Microsoft Entra v1 エンドポイントが使用され、MSAL では v2 が使用されるため、MSAL.js は互換性がありません。発行者の形式はバージョンによって異なります。
承認ヘッダーを追加する
- すべての Web API 要求に次のヘッダーを含めます。
```
Authorization: Bearer <id_token>
```
サイトの可視性をパブリックに設定する
- この設定により、 localhost 開発およびテスト目的でサイトにアクセスできます。

開発プロキシを構成する

Vite を使用する場合は、CORS の問題を回避するために、次のコードをvite.config.jsに追加します。

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      '/_api': {
        target: 'https://site-foo.powerappsportals.com',
        changeOrigin: true,
        secure: true
      }
    }
  }
});

既存のPower Pages サイトとの違い

次の表は、この機能を使用して作成された SPA サイトと従来のPower Pages サイトの主な違いをまとめたものです。

特徴	SPA サイトの動作
サーバー側更新	常にサイトのルートページを返し、クライアント側ルーターはサブルートをレンダリングします。
ルートの競合	クライアント側のルートが優先され、ハードリフレッシュはルートにフォールバックします。
ページワークスペース	ページワークスペースはサポートされていません。クライアントルーティングとクライアントサイトページを使用します。ページレベルのセキュリティのために、割り当てられた Web ロールをグローバルユーザーオブジェクトでチェックし、UI を条件付きでレンダリングします。
スタイルワークスペース	ワークスペーススタイルを使用したスタイル設定はサポートされていません。 CSS、CSS-in-JS、ユーティリティクラスなど、フレームワークのスタイルを使用します。
ローカライゼーション	ひとつの言語のサポート。クライアント側リソースの読み込みを実装する。
Liquid テンプレート	Liquid コードと Liquid テンプレートはサポートされていません。フレームワークのテンプレートエンジンと Web API を使用してデータにアクセスします。

FAQ

単体テストおよび統合テストのために利用可能なサポートは何ですか?

現在のところ、単体テストと統合テストのサポートは組み込まれていません。作成者は、これらのテストをローカルで、または CI/CD パイプライン内で書いて実行する必要があります。

WebAssembly を使用した Power Fx の統合はサポートされていますか?

この機能は、現在サポートされていません。

ソースコードはPower Pagesで使用できますか?

現時点では、作成者は TypeScript または GitHub Copilot Agent を使用して Web サイトを構築できます。コンパイルされた JavaScript ファイルと CSS ファイルにアクセスでき、Visual Studio Codeで編集できます。ただし、HTML ファイルの直接的かつ大規模な編集は現在サポートされていません。

この機能を使用して外部でコンポーネントを作成し、Power Pages サイトに持ち込むことはできますか?

いいえ。この機能を使用して、外部で生成されたコンポーネントを既存のPower Pages サイトに移動することはできません。

リストやフォームなどの標準コンポーネントを追加できますか?

リストやフォームのような既成コンポーネントの追加は現在サポートされていません。ただし、React フレームワークと Web API を使用して、カスタムフォームとリストを作成できます。

[セットアップ] ワークスペースから SPA サイトを PWA として有効にできますか?

No. SPA サイトでは、セットアップワークスペースのプログレッシブ Web アプリ (PWA) 設定はサポートされていません。この制限は、 Mobile セクションを使用してサイトを PWA として有効にできないことを意味します。インストール可能なアプリエクスペリエンスやオフラインページなどの PWA 機能を追加するには、それらをフレームワークコードに実装します。たとえば、Web アプリマニフェストとサービスワーカーを追加します。

ソース管理はどのように機能しますか？

開発者はソース管理のために Power Platform Git 統合を使用できます。ただし、リポジトリに追加されるのはコンパイルされた Web ファイルのみで、完全なソースコードは追加されません。

これらのサービス拠点は SEO をサポートしていますか?

SPA サイトは React フレームワークで構築され、クライアントサイドのレンダリングを使用するため、SEO のサポートは限定的です。

SPA サイトで提供Power Pagesセキュリティとガバナンスのサポートは何ですか?

Power Pagesは、Web API 呼び出しでテーブルのアクセス許可とセキュリティ Web ロールを適用し、データアクセスがユーザーロールと一致することを保証します。 window["Microsoft"].Dynamic365.Portal.User オブジェクトを使用して、基本的なユーザー属性を取得し、ユーザーペルソナに基づいてエクスペリエンスをカスタマイズします。

また、SPA サイトでは次のことがサポートされています:

非公開と公開のサイト構成
匿名データアクセスの制御を含む、ガバナンス設定
認証とプロバイダー構成

これらの機能は、Power Pages内のカスタムコンポーネントの安全で準拠した統合を保証するのに役立ちます。

Microsoft Power Platform CLI
チュートリアル: Microsoft Power Platform CLI を Power Pages で使用する方法
Visual Studio Code 拡張機能を使用する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-21

Power Pages でシングルページ アプリケーションを作成して展開する

前提条件

JavaScript ファイルのアップロードを許可する

SPA サイトの作成と展開

SPA サイトのアップロード

構文

Parameters

Example

アップロードパラメーターをpowerpages.config.jsonで定義する

構成フィールド

サンプル powerpages.config.json

SPA サイトをダウンロードする

構文

Parameters

Example

サイトをアクティブ化してテストする

プロジェクト構造と構成

コード分割とバンドルのクリーンアップ

コード分割を有効にする

upload-code-site が古いバンドルをクリーンアップする方法

オプション 1: ワイルドカード パターンを直接一覧表示する

オプション 2: ビルド後スクリプトを使用してワイルドカード パターンを生成する

認証と承認

ID プロバイダーを構成する

コードでユーザー コンテキストにアクセスする

サンプルの React フロー

Power Pages Web API を使用する

Microsoft Entra ID 認証を使用して localhost からの Web API 呼び出しを有効にして、ローカル開発を設定する

コンフィギュレーションの手順

既存のPower Pages サイトとの違い

FAQ

単体テストおよび統合テストのために利用可能なサポートは何ですか?

WebAssembly を使用した Power Fx の統合はサポートされていますか?

ソース コードはPower Pagesで使用できますか?

この機能を使用して外部でコンポーネントを作成し、Power Pages サイトに持ち込むことはできますか?

リストやフォームなどの標準コンポーネントを追加できますか?

[セットアップ] ワークスペースから SPA サイトを PWA として有効にできますか?

ソース管理はどのように機能しますか？

これらのサービス拠点は SEO をサポートしていますか?

SPA サイトで提供Power Pagesセキュリティとガバナンスのサポートは何ですか?

関連情報

フィードバック

その他のリソース

Power Pages でシングルページアプリケーションを作成して展開する

アップロードパラメーターを`powerpages.config.json`で定義する

サンプル `powerpages.config.json`

`upload-code-site` が古いバンドルをクリーンアップする方法

オプション 1: ワイルドカードパターンを直接一覧表示する

オプション 2: ビルド後スクリプトを使用してワイルドカードパターンを生成する

コードでユーザーコンテキストにアクセスする

ソースコードはPower Pagesで使用できますか?