Power Pages Code Site (SPA) の開発・ビルド・デプロイ。pac pages upload-code-site でサイト作成からデプロイまで完結する。
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
公式リファレンス: Power Pages でシングルページ アプリケーションを作成して展開する | Microsoft Learn 新スキル参照: microsoft/power-platform-skills - power-pages
| リファレンス | 内容 |
|---|---|
| upstream 優先構成ガイド | microsoft/power-platform-skills 基準での責務分離・実行順序・刷新方針 |
| Dataverse クライアント実装 | powerPagesFetch/powerPagesFetchResponse・WebApiErrorCode・OData ヘルパー・ページネーション・サービスレイヤーパターン・Code Apps との対比 |
| 認証実装 | SSO・サインアウト・ログインボタン・認証ガード・UI フローの実コード一式・サーバー側 IdP/サイト設定・Code Apps との対比 |
| 認証・認可・テーブル権限（詳細） | EDM 2.0 Code Site の認証/認可/テーブル権限・Web API 共有クライアント・SSO+プロフィール編集・Web ロール管理・テーブル Web API 有効化・site-settings 永続化 |
| Enhanced Data Model テーブル権限 | EDM 2.0 のテーブル権限設定・3 レイヤー権限・N:N バグ・ワークアラウンド |
| 運用と落とし穴 | ビルド・デプロイ・サイト再起動・よくあるエラーと解決策 |
| トラブルシューティング | エラーコード早見表・デバッグ用 Site Settings・既知の無害な警告 |
| レガシー参照用チェックリスト | 旧構成の参照用チェックリスト |
| デザインシステム | UI コンポーネント・テーマ・レイアウトの指針 |
| デザインテンプレート集 | 5 種類の配色テンプレート定義。設計時に提案→選択→適用 |
| アクセススコープ設計（Self / Account） | Self / Account の比較・scope 値・権限マトリクス・管理者への依頼テンプレート・セキュリティ根拠 |
| 紐づけ依頼メールフロー | 未紐づけユーザーから管理者への依頼テーブル設計・Power Automate フロー定義 |
| 管理者用紐づけ画面 | contact ↔ account を管理者が割り当てる Code Apps 画面の仕様（実装は code-apps/templates/account-link-admin） |
Dataverse 接続と認証の実装方法はこのファイルで概要を説明し、完全なサンプルコードは上記 References にまとめている。
このスキルは microsoft/power-platform-skills/plugins/power-pages の以下 4 スキルを優先参照して構成する。
| 領域 | upstream スキル | このスキル内の着地 |
|---|---|---|
| 認証・認可 | setup-auth | references/authentication.md |
| Web ロール | create-webroles | references/enhanced-data-model-permissions.md |
| Dataverse CRUD | integrate-webapi | references/dataverse-client.md |
| 権限監査 | audit-permissions | reviews/* + scripts/review_pre_deploy.py |
標準実行順序（刷新後）
.powerpages-site 作成）⚠️ デプロイ後の必須ステップ:
pac pages upload-code-siteでテーブル権限 YAML をデプロイしても、 type=18 の content JSON 内adx_entitypermission_webroleが空のまま残り、Web ロール紐付けが効かない。デプロイ直後にpython scripts/setup_permissions.pyを実行して content のadx_entitypermission_webroleを書き込み、review_pre_deploy.pyの チェック 3.7 が ✅ になることを確認する（さもないと管理者を含む全ユーザーが 403）。詳細は教訓 14。
詳細な責務分離と判断基準は upstream 優先構成ガイド を正本として扱う。
| 観点 | ユーザー認証・Webロール認可 | Dataverse Web API 連携 CRUD |
|---|---|---|
| 上流スキル | setup-auth + create-webroles | integrate-webapi |
| 主目的 | ログイン/ログアウト、認証状態判定、ロールベース UI 制御 | /_api 経由の読み書き（powerPagesFetch/powerPagesFetchResponse、OData ヘルパー） |
| 主な成果物 | authService.ts（AUTH_PROVIDERS 配列）・use-auth.ts・ログイン UI・Web ロール YAML（.powerpages-site/web-roles/） | powerPagesApi.ts、テーブル別 service/hooks、CRUD 画面 |
| サーバー側必須設定 | IdP site settings、Web ロール、テーブル権限へのロール紐付け | テーブル権限（type=18 + adx_entitypermission_webrole）、必要時のみ Webapi 設定 |
| 失敗時の代表症状 | ログインループ、/profile 強制遷移、未認証判定ミス | 401(90040107) / 403 / 404(9004010C, 9004010D) |
| 依存関係 | 先に認証導線を整える（ユーザー実体: contact） | 認証済みセッション Cookie 前提で CRUD を実行 |
推奨適用順:
setup-auth で認証導線を整備create-webroles でロールを確定integrate-webapi で CRUD 実装audit-permissions で権限妥当性を最終監査pac pages upload-code-site がサイト作成とデプロイの両方を行う — API でサイトを事前作成する必要はない2022-03-01-preview) で activate_site.py を使ってアクティブ化upload-code-site は既存テーブル権限の Web ロール紐付けを消すため、毎回 scripts/relink_table_permissions.py（または統合の scripts/deploy_site.py）で再付与する（教訓 15）。npm run deploy（build && upload-code-site だけ）で終わらせないupload-code-site が header/footer/page を正しく構成する.powerpages-site/ は upload-code-site が自動管理する — ただし site-settings/ YAML は手動追加して永続化できる（下記参照）adx_website レコードは絶対に削除しない — EDM 2.0 でもランタイムが起動時に参照するcredentials: "same-origin" を使う — "include" ではない（same-site Cookie 認証）powerpagesitelanguageid が必須 — 未設定だと 404 になるcreatedby はアプリケーションユーザーになるため使えない。ログインユーザーの Contact 情報を自動取得し入力不要にする（教訓 19）npm run dev（localhost）で見た目を確認してから本番デプロイする — 本番デプロイ → ブラウザ確認 → 再デプロイのループは 1 サイクルあたり数十秒〜数分かかり非効率。レイアウト・配色・レスポンシブ崩れは localhost で先に潰し、本番デプロイは最終確認のみに留める（教訓 20）。ただし Power Pages 本体のテーマ CSS（Bootstrap 既定の見出し色など）はローカルには存在せず本番でのみ衝突しうるため、色指定は見出し要素に明示的な color を必ず設定し、デプロイ後の最終確認も省略しない（詳細は トラブルシューティング）account）配下の「業務テーブル」は Account スコープ（756150002）で権限を切る — 全件公開になるグローバルアクセスで逃げない。子テーブル権限（accountrelationship + create）を作り、POST 時に account Lookup を @odata.bind する。read は通るのに create だけ 403 になる典型パターンの原因（教訓 21）account テーブル自身に Account スコープを設定してはいけない — Web API が 500（9004010A）を返し、会社名の参照も子レコードの bind も一切できなくなる。正解は Contact スコープ（756150001）＋ contact_customer_accounts。これで「自分の parentcustomerid が指す 1 件」だけが返る（実機検証済み）You don't have permission to associate or disassociate table X to Y が出たら、まず不足している側の権限を疑う（実機で 4 通りの真理値表を検証済み）null を検知する二段構えにする（実機検証済み）初回:
npm run build
→ pac pages upload-code-site ← Inactive Sites に作成
→ py portal/scripts/activate_site.py ← PP API でアクティブ化 (api-version=2022-03-01-preview)
→ py portal/scripts/setup_contact_webapi.py
→ py .github/skills/power-pages/scripts/setup_inquiry_reporter.py ← 報告者 Contact Lookup (教訓 19)
→ py .github/skills/power-pages/scripts/relink_table_permissions.py ← ★ロール再付与＋再起動
2回目以降（推奨: 統合スクリプトで一括実行）:
py .github/skills/power-pages/scripts/deploy_site.py
（ビルド → upload-code-site → ★relink → 検証 → 再起動 を 1 コマンドで実行）
2回目以降（手動の場合）:
npm run build → pac pages upload-code-site
→ py .github/skills/power-pages/scripts/relink_table_permissions.py ← ★必須（省くと 403）
Account アクセスを採用する場合（初回デプロイ後に 1 回だけ・実機検証済みの順序）:
py .github/skills/power-pages/scripts/setup_access_scope.py --scope account
→ py .github/skills/power-pages/scripts/setup_account_link_request.py
→ py .github/skills/power-pages/scripts/deploy_flow_account_link_request.py
→ 管理者用 Code App をデプロイ（code-apps/templates/account-link-admin）
→ py .github/skills/power-pages/scripts/setup_access_scope.py --scope account --verify-only
⚠️
PAGES_SITE_NAMEを.envに必ず設定する。未設定だと最終更新のサイトが暗黙で選ばれ、 別サイトに権限を書き込む事故が起きる。
⚠️
npm run build && pac pages upload-code-siteだけで終わらせると、既存テーブル権限の Web ロール紐付けが消えて全件 403 になる（教訓 15）。relink_table_permissions.pyを 毎回実行するか、deploy_site.pyで一括実行すること。両スクリプトともハードコードなし・ すべて.env管理（DATAVERSE_URL/ENV_ID/PAGES_WEBSITE_ID/PP_SUBDOMAIN/RELINK_WEBROLE_NAMES/PORTAL_DIR）。
初回の pac pages upload-code-site はサイトを Inactive Sites に作成する。
アクティブ化は Power Platform API (api-version=2022-03-01-preview) で行う。
POST https://api.powerplatform.com/powerpages/environments/{ENV_ID}/websites?api-version=2022-03-01-preview
Body:
{
"name": "<PAGES_SITE_NAME>",
"subdomain": "<PAGES_SUBDOMAIN>",
"templateName": "DefaultPortalTemplate",
"dataverseOrganizationId": "<org_id>",
"selectedBaseLanguage": 1033,
"websiteRecordId": "<powerpagesiteid>" ← pac pages upload-code-site が作った ID
}
Response: 202 Accepted + Operation-Location ヘッダー
→ Operation-Location を 10 秒間隔でポーリング
→ OperationComplete = 成功、OperationFailed = 失敗
| パラメータ | 取得方法 |
|---|---|
ENV_ID | .env |
PAGES_SITE_NAME | .env / powerpages.config.json の siteName |
PAGES_SUBDOMAIN | .env / ユーザー指定 |
dataverseOrganizationId | GET /api/data/v9.2/organizations?$select=organizationid |
websiteRecordId | GET /api/data/v9.2/powerpagesites から name で検索 |
⚠️ API バージョン注意: 2022-03-01-preview を使用すること。2024-10-01 ではアクティベーションが正しく動作しない。
作業開始前に、standard の共通契約に加え、 1 回の AskUserQuestion で次をまとめて確認する。
| # | 質問 | 合格条件 |
|---|---|---|
| 1 | 対象環境、サイト名、subdomain、サイト種別は何か | 新規 / 更新、公開 URL、開発・テスト・本番の対象が確定している |
| 2 | Power Pages のライセンス / capacity は利用可能か | 認証ユーザー / 匿名ユーザーの想定数と課金方式を確認している |
| 3 | 認証方式とアクセス scope は何か | anonymous / authenticated、Self / Account、IdP、Web role、table permission を承認済みである |
| 4 | サイトと Dataverse を変更する担当者は誰か | Code Site の upload、site settings、Web role、table permission を変更できる担当者を記録している |
| 5 | 公開データとセキュリティ検証は何か | 公開列、PII、未認証時の期待値、403 / 200 のテスト担当者を確定している |
| 6 | デプロイ後の relink / restart を実施できるか | deploy_site.py または upload → relink → restart の一連を実行することで合意している |
環境全体の System Administrator を既定にせず、サイト管理と対象 Dataverse 構成に必要な
権限を持つ担当者を使用する。認証、scope、Web role、table permission のいずれかが未確定なら
外部公開へ進まない。
| ツール | バージョン | 用途 |
|---|---|---|
pac (Power Platform CLI) | 1.44+ | サイト作成・アップロード |
node + npm | 18+ | SPA ビルド |
| Python 3 | 3.10+ | デプロイスクリプト（任意） |
pac CLI 注意: サブコマンドは
pac pages（例:pac pages list,pac pages upload-code-site）。pac power-pagesは無効。pac pages helpでコマンド一覧を確認できる。
DATAVERSE_URL=https://{org}.crm.dynamics.com/
ENV_ID= # Power Platform 環境 ID
PAGES_SITE_NAME= # サイト名 (powerpages.config.json の siteName と一致)
PAGES_SUBDOMAIN= # サブドメイン (例: myportal → myportal.powerappsportals.com)
# Account アクセススコープを使う場合（Step 4）
ACCESS_SCOPE=account # self | account
ACCOUNT_CHILD_TABLES= # 論理名:リレーションスキーマ名 のカンマ区切り
ACCOUNT_LINK_REQUEST_TABLE= # 紐づけ依頼テーブルの論理名
ACCOUNT_LINK_REQUEST_RELATIONSHIP= # contact との 1:N スキーマ名
ACCOUNT_LINK_ADMIN_RECIPIENT= # 依頼通知メールの宛先（配布リスト推奨）
portal/
├── src/
│ ├── App.tsx ← ルート (HashRouter + Routes)
│ ├── main.tsx ← エントリポイント
│ ├── index.css ← Tailwind CSS
│ ├── components/
│ │ ├── site-layout.tsx ← ヘッダー・ナビ・プロフィールドロップダウン
│ │ ├── require-auth.tsx ← 認証ガードコンポーネント
│ │ ├── mode-toggle.tsx ← ダーク/ライト切替
│ │ └── ui/ ← shadcn/ui コンポーネント
│ ├── hooks/
│ │ └── use-auth.ts ← SSO 認証フック
│ ├── shared/
│ │ ├── powerPagesApi.ts ← ★ Web API 共有クライアント (powerPagesFetch/buildODataUrl 等)
│ │ └── services/
│ │ └── <table>Service.ts ← テーブルごとの CRUD サービス
│ ├── types/
│ │ └── <table>.ts ← エンティティ型・ドメイン型・マッパー
│ ├── lib/
│ │ └── utils.ts ← cn() ユーティリティ
│ ├── config.ts ← サイト名・ロゴ等のブランディング設定（.env の VITE_* を集約）
│ └── pages/
│ ├── home.tsx ← ランディングページ
│ └── profile.tsx ← プロフィール編集 (★ powerPagesApi.ts を使用)
├── dist-site/ ← ビルド出力 (compiledPath)
├── .powerpages-site/ ← upload-code-site が管理 + site-settings YAML 手動追加可
│ └── site-settings/ ← Webapi/* 設定を YAML で永続化
├── .env.example ← ★ ブランディング等の VITE_* 変数サンプル（コピーして .env を作成）
├── powerpages.config.json ← CLI 設定ファイル (必須)
├── package.json
├── vite.config.ts
└── scripts/
├── deploy.py ← デプロイスクリプト (Build→Upload→Restart)
├── activate_site.py ← PP API サイトアクティベーション
├── setup_auth.py ← Entra ID SSO 認証設定 (Site Settings + Liquid 注入)
└── setup_contact_webapi.py ← Contact Web API 有効化 (EDM 2.0 対応)
.env / src/config.ts）デプロイごとに変わるブランディング値はコードに直書きせず、ビルド時の環境変数で差し替える。
テンプレートの .env.example を .env にコピーして値を編集する（.env は .gitignore 済み）。
cp .env.example .env # 値を編集してから npm run build
| 変数 | 用途 | 既定値 |
|---|---|---|
VITE_SITE_NAME | サイト/ブランド表示名（ヘッダーロゴ・フッター・ブラウザタブのタイトル） | Power Pages |
VITE_SITE_LOGO_MARK | ヘッダーロゴのマーク（1〜2 文字の頭文字） | P |
VITE_ プレフィックス必須（Vite はこの接頭辞の変数のみクライアントへ公開）。src/config.ts（SITE_NAME / SITE_LOGO_MARK）に集約し、未設定時は既定値へフォールバック。home.tsx / site-layout.tsx は @/config を import して参照、main.tsx が document.title を設定。{
"siteName": "MySite",
"compiledPath": "dist-site",
"defaultLandingPage": "index.html"
}
pac pages upload-code-site は古いバンドルファイルを自動クリーンアップする。
デフォルトパターン: main.*.js, main.*.css, vendor.*.js, index-*.js, index-*.css 等 10 種。
Vite のデフォルト出力（index-{hash}.js）はカバーされるが、カスタムの命名規則を使う場合は明示指定する:
{
"siteName": "MySite",
"compiledPath": "dist-site",
"defaultLandingPage": "index.html",
"bundleFilePatterns": ["app.*.js", "app.*.css", "style.*.css"]
}
| フォルダ | 種別 | 内容 | 使いどころ |
|---|---|---|---|
| templates/corporate-lp/ | プロジェクト雛形 | React + TypeScript + Vite + shadcn/ui。認証導線・/profile・Dataverse クライアント込み | 新規開発の既定の出発点。コピーして中身を差し替える |
| templates/minimal-code-site/ | プロジェクト雛形 | ビルド不要の素の HTML/CSS/JS 1 セット | upload-code-site → アクティブ化 → 再起動の配線だけを疎通確認したいとき |
| templates/access-scope/ | 部分テンプレート（コード片） | 取引先企業の読み取り専用表示と紐づけ依頼ボタン | 既存アプリに機能として追加する（雛形ではない） |
| samples/portal/ | 参照用サンプル | 動作済みサイトの実体（.powerpages-site の web-templates / page-templates を含む） | 実装の答え合わせ・生成物の構造確認。コピー元にはしない |
templates/= コピーして使うもの、samples/= 読んで参考にするもの。 プロジェクト雛形は共通スキャフォルダーで生成し、部分テンプレートは空のステージング先へ 生成してから該当ファイルだけを既存のsrc/hooks/やsrc/components/に配置する。
生成計画を確認し、問題がなければ --dry-run を外して実行する。
# React + TypeScript + Vite の既定プロジェクト
python .github/skills/update-skills/scripts/scaffold_from_template.py `
--template .github/skills/power-pages/templates/corporate-lp `
--target portal --var PAGES_SITE_NAME="My Site" --dry-run
# 配線確認用の最小 Code Site
python .github/skills/update-skills/scripts/scaffold_from_template.py `
--template .github/skills/power-pages/templates/minimal-code-site `
--target portal-smoke --var PAGES_SITE_NAME="My Smoke Site" --dry-run
# Account アクセス用アドオン（空のステージング先へ生成する）
python .github/skills/update-skills/scripts/scaffold_from_template.py `
--template .github/skills/power-pages/templates/access-scope `
--target .scaffold/access-scope --dry-run
access-scopeを既存プロジェクト直下へ--forceで生成しない。生成後に必要な2ファイルを ホストプロジェクトへ統合する。
// vite.config.ts
export default defineConfig({
base: "./", // 相対パス（必須）
build: {
outDir: "dist-site", // powerpages.config.json と一致
rollupOptions: {
output: { inlineDynamicImports: true }, // 単一バンドル（推奨）
},
},
});
| 制約 | 理由 |
|---|---|
base: "./" | Power Pages のパス構造に対応 |
inlineDynamicImports: true | コード分割するとロード順問題が発生 |
| Hash ルーティング必須 | History API モードは直接 URL アクセスで 404 |
| 静的 SPA のみ | SSR / ISR 非対応 |
{
"scripts": {
"dev": "vite",
"build": "tsc -b && vite build",
"upload": "pac pages upload-code-site --rootPath . --compiledPath ./dist",
"deploy": "py ../.github/skills/power-pages/scripts/deploy_site.py"
}
}
レイアウト・配色・レスポンシブ対応など見た目に関わる変更は、本番デプロイ前に必ず npm run dev で確認する。
cd portal
npm run dev # http://localhost:5173 などで起動
# ブラウザで表示・配色・レスポンシブを確認してから次のコミット/デプロイへ進む
| 確認できること | 確認できないこと（デプロイ後に要再確認） |
|---|---|
| コンポーネント構造・レイアウト崩れ・レスポンシブ | Power Pages 本体のテーマ CSS との衝突（例: Bootstrap 既定の見出し色が明示指定のない <h1> 等に強制適用される） |
| 自前 CSS の配色・グラデーション・アニメーション | 認証リダイレクト・Web ロール・テーブル権限まわりの挙動 |
| コンポーネント間の状態遷移・フォームバリデーション | Power Pages ランタイムが注入する外部スクリプト/スタイルとの相互作用 |
教訓 20:
<h1>等の見出し要素は、親要素にcolor: #fffを設定していても Power Pages 本体のテーマ CSS（h1への既定色指定）に上書きされることがある（継承より明示指定が常に優先されるため）。見出し要素には必ず明示的にcolorを指定し、ローカル確認だけで満足せず本番デプロイ後にも目視確認する。
環境で .js がブロックされている場合:
js を削除cd portal
npm run build
pac pages upload-code-site --rootPath .
py portal/scripts/activate_site.py
スクリプトが以下を自動実行:
カスタムサブドメインを指定する場合:
py portal/scripts/activate_site.py --subdomain my-portal
py portal/scripts/setup_contact_webapi.py
py .github/skills/standard/scripts/_restart.py
アクティブ化後、URL にアクセスできるまで 60〜90秒 かかる。
cd portal
py ../.github/skills/power-pages/scripts/deploy_site.py
# ビルド → upload-code-site → ★ロール再付与 → 検証 → 再起動 を 1 コマンドで実行する。
# upload-code-site が消す Web ロール紐付けを毎回必ず再付与するため、relink 忘れによる
# 全件 403 事故（教訓 15）を構造的に防ぐ。ハードコードなし・すべて .env 管理。
cd portal
npm run build
pac pages upload-code-site --rootPath . --compiledPath ./dist
# ★ upload-code-site は既存 type=18 の content.adx_entitypermission_webrole を消すため、
# デプロイのたびに全テーブル権限の Web ロールを再付与する（教訓 15）。これを省くと 403。
py ../.github/skills/power-pages/scripts/relink_table_permissions.py
# → relink スクリプトが PAGES_WEBSITE_ID（推奨）または PP_SUBDOMAIN 設定時に自動で再起動する
# （未設定の場合は手動再起動）
/profile（contact Self）を使う場合は、初回のみsetup_contact_self.pyで contact 権限とWebapi/contact/enabled|fieldsを作成しておく（教訓 16）:py ../.github/skills/power-pages/scripts/setup_contact_self.py
取引先企業（
account）配下のレコードを扱う場合や、参照可能範囲を Self / Account から 選ぶ場合は Step 4 を実行する（教訓 21）。
サインインユーザーが誰のデータを見られるかを確定し、そのスコープで権限・UI・運用を揃える。 背景と根拠は アクセススコープ設計。
テーブル権限を作る前に必ず質問する。 ここを飛ばすと権限・UI・運用を同時にやり直すことになる。
| # | 質問 | 選択肢 |
|---|---|---|
| 1 | サインインユーザーの参照可能範囲は? | Self アクセス（本人のレコードだけ）/ Account アクセス（所属する取引先企業配下） |
| 2 | （Account のときのみ）管理者が contact ↔ 取引先企業を紐づける Code Apps 管理画面をどう用意しますか? | テンプレートから作成する（既定） / 作成しない（モデル駆動型アプリで運用） |
contact と本人が作成したレコードのみ。BtoC・個人利用向け。contact に紐づく 取引先企業（account）配下を同僚と共有。BtoB ポータル向け。回答を .env の ACCESS_SCOPE（self / account）と ADMIN_LINK_APP（true / false）に記録し、
以降の分岐に使う。迷っている場合の既定は Self（後から Account を足せるが、逆は利用者影響が大きい）。
Account を選んだら紐づけ手段は必須。
contact.parentcustomeridが空のままではどのデータも見えないため、 質問 2 は「作る／作らない」ではなく「Code Apps 管理画面か、モデル駆動型アプリ運用か」の選択である。 既定は templates/account-link-admin からの作成（ADMIN_LINK_APP=true）。
権限に指定するのはリレーションのスキーマ名であり、表示名でも Lookup 列名でもない。
cd portal
python ../.github/skills/power-pages/scripts/setup_access_scope.py --list-relationships
python ../.github/skills/power-pages/scripts/setup_access_scope.py --scope self
contact: scope=756150004（Self）read/write、appendto=truescope=756150001（Contact）＋ contactrelationship、read/write/createWebapi/{table}/enabled=true と Webapi/{table}/fieldsサインイン時に作られた contact に関連付いている account を
参照できるが編集・削除はできない権限セットにする。
# .env の ACCOUNT_CHILD_TABLES（論理名:リレーションスキーマ名 のカンマ区切り）を使う
python ../.github/skills/power-pages/scripts/setup_access_scope.py --scope account
| # | テーブル | scope | リレーション | read | write | create | delete | append | appendto |
|---|---|---|---|---|---|---|---|---|---|
| 1 | account | Contact（756150001） | contact_customer_accounts | ✅ | ❌ | ❌ | ❌ | ✅ | ✅ |
| 2 | 業務テーブル | Account（756150002） | accountrelationship | ✅ | ✅ | ✅ | ❌ | ✅ | ✅ |
| 3 | contact | Self（756150004） | なし | ✅ | ✅ | ❌ | ❌ | ✅ | ✅ |
account テーブル自身を Account スコープにすると
Web API が 500（9004010A）を返し、参照も bind もできなくなる（実機検証済み）。
Contact スコープ + contact_customer_accounts（account 1:N contact = parentcustomerid）にすれば
自社 1 件だけが返る。verify() は旧構成が残っていたら NG を出す。write/delete は必ず false。スクリプトは送信直前に検証し、true なら中止する。append/appendto は編集権限ではない。Lookup バインドには
参照する側とされる側の両方で append と appendto が必要で、片側だけだと 403 になる。ACCESS_SCOPE_WEBROLE_NAME を設定する
（存在しなければ作成されるが、contact への割り当ては別途必要）。756150000）で代用しない。全社の取引先企業が全ユーザーに見えてしまう。/profile に会社情報を表示専用で出す（入力欄にしない）。
const me = await powerPagesFetch<{ _parentcustomerid_value: string | null }>(
`/_api/contacts(${user.contactId})?$select=_parentcustomerid_value`
);
const accountId = me._parentcustomerid_value; // null = 未紐づけ
実装は templates/access-scope/ の use-account-access.ts /
AccountProfileSection.tsx を src/hooks/・src/components/ に配置する。
なぜユーザーに選ばせないのか: 取引先企業を自由に選べると、他社を選ぶだけで 他社データにアクセスできてしまう（権限昇格）。紐づけはアプリ管理者だけが行う。
Webapi/contact/fieldsにparentcustomeridを含めない運用にすると PATCH 自体が拒否され二重に安全。
依頼テーブル {prefix}_accountlinkrequest を作成する（dataverse スキル、
列定義は 紐づけ依頼メールフロー）。
依頼テーブルの権限と Web API を作成する（作成と自分の依頼の参照だけを許可）。
python ../.github/skills/power-pages/scripts/setup_account_link_request.py
依頼メール送信フローをデプロイする。
python ../.github/skills/power-pages/scripts/deploy_flow_account_link_request.py
接続参照の作成 → フロー作成 → 有効化 → Webhook 登録（/start）までを自動で行う。
事前に Dataverse と Office 365 Outlook の接続を make.powerautomate.com で作っておく（API では作れない）。
トリガーは Dataverse「行が追加されたとき」、アクションは Office 365 Outlook「メールの送信」。
宛先は .env の ACCOUNT_LINK_ADMIN_RECIPIENT。
プロファイル画面のボタンから依頼レコードを POST する（テンプレート実装済み）。
HTTP トリガーのフローを直接呼ばない。匿名で叩ける URL は踏み台になる。 認証済みセッションで Dataverse にレコードを作り、サーバー側のフローで送信する。
アドオンテンプレート code-apps/templates/account-link-admin を使う。
code-apps スキルで generic-base から scaffold し、テンプレートの src/ を重ねて
ルート（/account-link）とナビ項目を追加するだけで動く。データソースは
shared_commondataserviceforapps を 1 回追加すれば contacts / accounts /
{prefix}_accountlinkrequests をすべて扱える。
画面仕様・更新処理・監査の考え方は 管理者用紐づけ画面 に従う。 「作成しない」を選んだ場合は、モデル駆動型アプリの取引先担当者フォームで 取引先企業を設定する運用手順を README に記載する（紐づけ手段そのものは省略できない）。
python ../.github/skills/power-pages/scripts/setup_access_scope.py --scope account --verify-only
.env の ACCESS_SCOPE に記録したaccount 権限は Contact スコープ + contact_customer_accounts で read のみ（write/delete が false）account / 業務テーブル / contact のすべてに append と appendto があるaccountrelationship（スキーマ名）と create=true があるWebapi/{table}/enabled|fields がアクセスする全テーブルにあるupload-code-site の後に relink_table_permissions.py を実行した（省くと全件 403）再起動の反映には 60〜90 秒かかる。確認は InPrivate ウィンドウで行う。 異常系は トラブルシューティング を参照。
Power Pages の品質を標準的に維持するための 設計前レビュー と デプロイ前レビュー を提供する。
| レビュー | タイミング | ドキュメント | スクリプト |
|---|---|---|---|
| 設計前レビュー | テーブル設計完了後、SPA 実装開始前 | reviews/pre-design-review.md | scripts/review_pre_design.py |
| デプロイ前レビュー | npm run build 後、pac pages upload-code-site 前 | reviews/pre-deploy-review.md | scripts/review_pre_deploy.py |
# 設計前レビュー（ローカル静的チェックのみ、Dataverse 接続不要）
cd portal
python ../.github/skills/power-pages/scripts/review_pre_design.py
# デプロイ前レビュー（ビルド出力 + Dataverse API チェック）
cd portal
python ../.github/skills/power-pages/scripts/review_pre_deploy.py
# CI/CD でリモートチェックをスキップする場合
SKIP_REMOTE=1 python ../.github/skills/power-pages/scripts/review_pre_deploy.py
標準フロー: 設計前レビュー → 実装 →
npm run devでローカル確認（デザイン変更時は必須・教訓 20） → ビルド → デプロイ前レビュー → デプロイ → 本番での目視確認
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Power Platform のテナント / 環境ガバナンスを確認・設定する。通常開発では事前チェックせず、環境チェックの明示依頼時または開発・デプロイ障害時だけ診断する。依頼者の現在有効な委任権限と対象範囲を確認し、権限内の最小診断・承認済み修復・限定リトライ、権限不足なら管理者への依頼へ分岐する。環境・DLP・ACP・環境グループ・テナント戦略の確認と dry-run 付き管理操作を提供する。
The English summary is being prepared. Showing the original description.
Copilot Studio 新 UI の Agent flows / Workflows を構築・公開・検証する。Dataverse レコード作成/更新トリガーから既存の発行済み Copilot Studio v2 を Agent ノードで呼ぶ標準経路、Code Apps との非同期要求/結果連携、および手動 Start + inline Agent の API ライフサイクル検証を扱う。
The English summary is being prepared. Showing the original description.
株主総会の想定問答を、IR 抜粋（決算短信・説明資料・招集通知など）を根拠に下書きし、利用者の確認後に Dataverse の想定問答テーブルへ「下書き」として登録するスキル。 Use when ユーザーが「配当について想定問答を作って」「この論点の想定問答を 3 件追加して」「招集通知から想定問答を作って」「想定問答を登録して」と依頼したとき。 Dataverse MCP コネクタ（describe / read_query / search_data / create_record / update_record）を使用する。削除・テーブル変更のツールは使わない。
The English summary is being prepared. Showing the original description.
株主総会の想定問答を点検し、根拠の IR 抜粋に無い数値・存在しない根拠 ID・回答者や注意事項の抜け・趣旨の重複・下書きのまま残っているものを一覧にするスキル（書き込みはしない）。 Use when ユーザーが「想定問答を点検して」「根拠の無い数値が無いか確認して」「下書きの想定問答を一覧にして」と依頼したとき。 Dataverse MCP コネクタ（describe / read_query / search_data）を使用する。書き込み・削除のツールは使わない。
The English summary is being prepared. Showing the original description.
株主総会の質疑応答のリハーサル台本（議長・株主・回答役員の読み上げ原稿）を、承認済みの想定問答から作り、Dataverse のリハーサル台本テーブルへ登録するスキル。 Use when ユーザーが「リハーサルの台本を作って」「QA-001〜QA-010 で読み上げ原稿を作って」「番号を言わない株主も入れた台本を作って」と依頼したとき。 Dataverse MCP コネクタ（describe / read_query / search_data / create_record / update_record）を使用する。削除・テーブル変更のツールは使わない。
The English summary is being prepared. Showing the original description.
AI Builder の AI プロンプト（GPT Dynamic Prompt）を Dataverse API で作成し、Copilot Studio エージェントにツール（アクション）として追加する。Power Automate フローとの統合パターンも含む。
The English summary is being prepared. Showing the original description.