standard

Power Platform 包括開発標準スキル

全スキル共通の開発基盤。このスキルが扱うのは 認証 / .env / ソリューション運用 の 3 テーマのみ。 個別コンポーネントの設計・構築ルールは各専門スキルが持つ（→ スキルカタログ README）。

サブリファレンス（必要に応じて参照）

共有ユーティリティ（複数スキルから参照される横断リファレンス）

以下は単一の専門スキルに属さず複数スキルから参照されるため、共通基盤である standard/references に置いている。各スキルの SKILL.md からリンク済み。

大前提: 一つのソリューション内に開発

Dataverse テーブル・Code Apps・Power Automate フロー・Copilot Studio エージェントは すべて同一のソリューション内 に含める。 .env の SOLUTION_NAME と PUBLISHER_PREFIX を全フェーズで統一して使用する。

共通の事前確認契約（会話の最初に 1 回だけ）

専門スキルで設計を開始する前に、1 回の AskUserQuestion で次の共通事項とスキル固有事項を まとめて確認する。以降の Step で同じ内容を聞き直さない。

実装前に、次の項目を1回の回答で確認してください。
1. 対象テナント、Power Platform 環境、Azure サブスクリプションなどの実装先
2. 開発、テスト、本番のどこまで実施するかと、デプロイまたは公開の承認範囲
3. 必要な製品ライセンス、容量、プレビュー参加条件が満たされているか
4. 作成・変更・公開・管理者同意・ロール割り当てを行う担当者と最小権限
5. 対象ソリューション、パブリッシャー、命名、利用者または公開対象
6. 認証方式、接続、シークレットストア、データ分類と外部共有の可否
7. 検証担当者、受け入れ条件、ロールバックまたはクリーンアップ方針

各専門スキルは、この7分類から不要な項目を省き、必要な固有質問を加えた 「事前確認（会話の最初に 1 回だけ）」を持つ。最低限、次を守る。

• 製品ライセンスとプレビュー制度を別項目として扱う。
• 「管理者権限が必要」とだけ書かず、工程ごとの最小ロールまたは必要な具体的権限を示す。
• 開発者が全ロールを持つと仮定せず、ライセンス、公開、管理者同意、Azure RBAC の担当者を分けて記録する。
• Global Administrator、Owner、System Administrator は、より狭いロールで完了できない工程に限定する。
• デプロイや公開の前に前提条件を再検証し、満たさない場合は処理を停止する。
• 検証チェックリストに、事前確認を1回で完了したことと、実際の対象環境・公開範囲・権限を確認したことを含める。

共通基盤: .env と認証

すべてのデプロイスクリプトは以下の 共通パラメータ と 共通認証 を使用する。 各スキルから個別に認証を設定する必要はない。

.env 共通パラメータ

推奨: インタラクティブセットアップ で pac CLI から対話的に .env を構成する（PAC 認証 → 環境選択 → パブリッシャー/ソリューション選択を AskUserQuestion で進行）。

PAC 認証プロファイルがない場合（PAC CLI 未インストール・auth create 不可）は、Power Apps ポータル > 設定（右上の⚙）> セッション詳細 から以下の値を取得して手動設定する（インタラクティブセットアップの Step 2 参照）。

# === 必須（全フェーズ共通）===
DATAVERSE_URL=https://{org}.crm7.dynamics.com/   # セッション詳細: Instance URL
TENANT_ID={your-tenant-id}                       # セッション詳細: Tenant ID
SOLUTION_NAME={YourSolutionName}
PUBLISHER_PREFIX={prefix}

# === オプション ===
PAC_AUTH_PROFILE={YourProfileName}         # PAC CLI 認証プロファイル名
[email protected]              # Power Automate 通知先
BOT_ID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  # Copilot Studio Bot ID（URL でも可）

セッション詳細の Environment ID は pac auth create --environment {env-id} でも使用する。

共通認証: auth_helper.py

./auth_helper.py が全デプロイスクリプトの認証を一元管理する。 同一マシン上では、どのプロジェクトでもデバイスコード認証は最初の1回だけで済む 2 層キャッシュ構成。

層1: AuthenticationRecord (~/.power-platform-cli/auth_record_{TENANT_ID}.json)
  - アカウント情報（テナント・ユーザー ID）を保存
  - ホームディレクトリ配下の固定パスに永続化（プロジェクトフォルダに依存しない）
  - そのため、別プロジェクトを新規に開いても再度デバイスコード認証を求められない

層2: TokenCachePersistenceOptions (MSAL OS 資格情報ストア)
  - リフレッシュトークン・アクセストークンを永続化（同一マシンで共有）
  - サイレントリフレッシュでデバイスコード不要

初回（このマシンで最初の1回のみ）: DeviceCodeCredential → ブラウザで認証 → グローバルキャッシュに保存
2回目以降（別プロジェクトでも）: キャッシュから自動取得（認証プロンプトなし）
テナント/アカウント切替時のみ: ~/.power-platform-cli/auth_record.json を削除して再認証

条件付きアクセスポリシーでデバイスコード認証（AADSTS50199 等）がブロックされているテナントでは、 .env に AUTH_MODE=interactive を設定するとローカルブラウザでのインタラクティブ認証 （InteractiveBrowserCredential）に切り替わる（既定は AUTH_MODE=device_code）。 キャッシュの仕組みは共通のため、モードを切り替えても初回のみ再認証すればよい。

認証の公開 API・パターンの詳細実装は 認証リファレンス を参照。

設計・要件ヒアリングは architecture スキルへ

要件ヒアリング → コンポーネント選定 → 全体アーキテクチャ設計は architecture スキル が担当する。 Phase 1（設計）の最初に必ず architecture を参照し、IT に詳しくないユーザーから業務課題を引き出して設計提案・承認を得てから、各専門スキルでの構築に進む。

→ 詳細: architecture スキル

関連スキルと推奨開発フロー

各スキルの説明・カテゴリ・推奨開発フローは スキルカタログ に一元化している（standard には重複記載しない）。

→ Power Platform Skills カタログ（README）

クイックリファレンス: standard が扱うテーマ

このスキルが扱うのは以下の 共通基盤テーマのみ。

個別の構築ルール・トラブルシューティング（Copilot Studio・Code Apps・Power Automate・Dataverse・Security Role・AI Builder・Model-Driven App 等）は 各専門スキルの SKILL.md / references に記載している。standard には重複して持たない。 どのスキルに何があるかは スキルカタログ README を参照。