無料GitHub で公開

architecture

Power Platform ソリューションの全体アーキテクチャを設計する。Copilot Studio / Power Automate / Code Apps / Copilot Managed Runtime / Power Pages / AI Builder の使い分け判断、コンポーネント選定、統合パターンを決定する。社内向け画面は利用者のライセンス（Power Apps Premium か、Copilot Credits の従量課金か）と利用頻度をヒアリングし、Code Apps と Copilot Managed Runtime を使い分ける。構成が確定したら、実装着手前に admin スキルで環境チェック（既定環境ではないか・マネージド環境・Code Apps / MCP の有効化・セキュリティロール）と DLP 事前チェック（使用コネクタがブロックされていないか・Business / Non-business が混在しないか）を実行して結果をユーザーに提示する。Agent 365 の AI チームメイトを採用する場合はライト実装（PoC）と本格実装（private リポジトリ + CI/CD + Agent Evals）を AskUserQuestion で選ばせ、Git ホスティング（GitHub / Azure DevOps Repos / その他）も確定してから実装へ進む。外部の文章を読むエージェントではプロンプトインジェクション対策を設計段階で工数に含める。

geekfujiwara/CodeAppsDevelopmentStandard

インストール方法を見る

含まれるファイル（6）

SKILL.md75.3 KB
references/component-selection-details.md15.8 KB
references/data-platform-selection.md4.5 KB
references/design-patterns.md22.8 KB
references/managed-runtime-vs-code-apps.md27.8 KB
scripts/.gitkeep0 B

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Power Platform 共通アーキテクチャデザインスキル

ユーザー要件から Power Platform のどのコンポーネントを使うか を判断し、全体アーキテクチャを設計する。各コンポーネントの得意領域・制約・統合パターンを把握し、迷わず最適な構成を選定するためのスキル。

このスキルの位置づけ: Phase 1（設計）の最初に実行する。個別コンポーネントのスキルに入る前に、まず要件を深掘りして全体像を確定させる。

0. 要件ヒアリング（Phase 1 の最初に必ず実行）

IT に詳しくないエンドユーザーに向き合うプロの IT コンサルタントとして振る舞う。 専門用語を使わず、業務課題・現状・理想の姿を引き出すことを最優先にする。

AskUserQuestion で深掘りする項目

以下をまとめて質問し、一問一答の往復を最小化する。

確認項目	質問の例
解決したい課題	今どんな問題・不便がありますか？
現状の管理方法	今は Excel・メール・紙などで管理していますか？
利用者・規模	誰が使いますか？社内のみですか？何人くらいですか？
利用者のライセンスと頻度	使う人は Power Apps Premium を持っていますか？持っていない人は毎日使いますか、それとも月に数回ですか？（→ §5「ライセンスで使い分ける」）
必要な操作	登録・検索・承認・通知・レポートのうち何が必要ですか？
外部連携	Teams / Outlook / SharePoint / 既存システムとつなぎたいですか？
Dataverse 外のデータ	参照したいデータは既存の基幹 DB・ファイルサーバー・業務 API にありますか？（→ あるなら §6.5：自前 MCP Server）
データの量と使い方	件数・増え方・履歴分析・Power BI・機械学習・文書（手順書）の引用は必要ですか？（→ 必要なら §6.6：データ基盤の使い分け）
AI・自動化	チャットで問い合わせできると便利ですか？自動通知は必要ですか？
人としての同僚	ツールとしての AI でよいですか？それとも自分のメールアドレスや予定表を持ち、メンバーとして働く存在が欲しいですか？（→ 後者なら §7）

全体像が掴みにくいときは、Excel・業務フロー図・画面イメージ・帳票の共有を依頼する（/spec-builder でドキュメントから要件整理も可）。要件が明確になったら、以下の判断フローチャートでコンポーネントを選定し設計提案へ進む。

実装前提ゲート（コンポーネント選定後に 1 回だけ）

構成案が固まったら、実装開始前に standard の共通事前確認契約を 1 回の AskUserQuestion で確認する。特に次を構成図と見積もりに含める。

観点	設計で確定する内容
製品条件	コンポーネントごとのライセンス / capacity と、preview / Frontier 等の参加条件を分離して記載
実装先	tenant、Power Platform environment、Azure subscription、region、開発 / テスト / 本番
権限分離	maker、schema 変更、Azure RBAC、公開、管理者同意、ライセンス割り当ての担当者
公開範囲	internal / external / anonymous、対象ユーザーまたはグループ、データ分類
運用	Git provider、secret backend、監視、評価、release、rollback、所有者

選定した各専門スキルの事前確認で1項目でも未確認なら、そのコンポーネントの実装を開始しない。 AI チームメイトでは Agent 365 と Frontier、Cowork では Microsoft Copilot ライセンスと Frontier、 Power Pages では認証方式と table permission をそれぞれ別条件として扱う。

1. コンポーネント早見表

コンポーネント	得意なこと	苦手なこと
Copilot Studio	自然言語対話、ナレッジ検索、LLM による推論・要約、ツール呼び出しの自律的オーケストレーション	確定的なフロー制御、大量データの一括処理、トランザクション保証
Power Automate	イベント駆動の自動化、確定的なワークフロー、コネクタ経由の外部連携、条件分岐・ループ	自然言語対話、あいまいな入力の解釈、自律的判断
Code Apps	React/Vite のリッチ Web UI、複雑なデータ操作画面、カスタムビジュアル。利用者は Power Apps Premium 等が必要	ノーコードでの素早いプロトタイプ、モバイルネイティブ、Copilot Credits での支払い
Copilot Managed Runtime	M365 内部 LOB アプリ、Git commit 単位の build / preview / deploy、M365 管理面への集約。利用者は Power Apps Premium か Copilot Credits の従量課金で使える（Public Preview）	GA 必須、Azure B2B guest、Dataverse Solution / Power Platform Pipelines 中心の ALM
Native Mobile Code Apps	Expo/React Native、camera／barcode／location 等の端末機能、Wrap（Private Preview）	本番利用、store 配布、未検証の offline runtime
Canvas Apps	（常に対象外 — パフォーマンス・カスタマイズ性・エンタープライズ運用の観点で不採用）	—
Model-Driven Apps	Dataverse 標準 UI、フォーム/ビュー/ダッシュボードの自動生成、ビジネスルール統合	カスタムビジュアル、外部 JS ライブラリ、ノーコード開発者
Power Pages	外部ユーザー向けポータル・公開サイト、認証/匿名アクセス、Dataverse 連携、テーブル権限による公開制御	複雑なサーバーサイド処理、SSR/ISR、内部業務向けの複雑なリッチ UI
AI Builder	Power Automate フロー内に組み込む定型 AI 処理（通知・リマインド等、イベント駆動でチャット UI を使わない場合のみ）	チャット UI での対話・社内汎用業務全般（★ §6 参照: 原則 Copilot Studio v2 + Dataverse MCP、AI Builder は限定的採用）
Dataverse	リレーショナルデータ、行レベルセキュリティ、監査、ビジネスルール	大量ログデータ、非構造化データ、全文検索
Copilot Studio v2 スキル + Dataverse MCP	自然言語での業務データ登録・照会（Dataverse MCP 経由）、Teams / Copilot Studio 上での利用、SKILL.md による業務知識の付与。環境制約が少なく作りやすい（★ 第一候補）	リッチな一覧/編集 UI、複雑なビジュアル、外部/匿名公開
Copilot Cowork プラグイン	M365 Copilot 上での自然言語登録・照会（Dataverse MCP / 自前 MCP Server 経由）。M365 Copilot との統合が必須要件の場合に採用。会社環境で Cowork の利用が許可されている場合のみ推奨	環境制約が多い（Entra App 登録・Teams 開発者ポータル・M365 管理センター公開・Teams Admin / Global Admin 権限が必要）。環境が揃わない場合は Copilot Studio v2 + Dataverse MCP を優先
自前 MCP Server（Azure Functions）	Dataverse に無いデータ（既存の基幹 DB / ファイルサーバー / 業務 API）をエージェントに公開する。Private Endpoint の内側にあるデータをキーレス（Entra JWT + Managed Identity）で提供。Copilot Studio / Cowork の両方から同じ Server を使い回せる	ノーコードでの構築。Azure の基盤（VNet / Private Endpoint / 監視）と運用が別途必要。Dataverse の行レベルセキュリティは傣かない（自前で設計する）
Agent 365 / AI チームメイト	カスタムエンジンエージェントをコードファーストでバージョン管理し、Teams / M365 Copilot へ公開。インストールごとの専用 Entra Agent ID。エージェント自身のメールアドレス・予定表・権限を持つ「デジタルな同僚」（★ §7: 採用時はライト/本格を必ず確認）	ノーコードでの素早い構築、Code Apps / Web への埋め込み、Dataverse 標準 UI

Code Apps と Copilot Managed Runtime の選定: 比較リファレンスを参照する。現時点では Code Apps は GA、Copilot Managed Runtime は Public Preview である。 @microsoft/power-apps から @microsoft/managed-apps への package 置換を移行手段として扱わない。 Managed Runtime を採用した場合の実装は managed-runtime スキルで行う。

2. 判断フローチャート

2.1 メイン判断: 「何を実現したいか？」

ユーザー要件
    │
    ├─ 対話型の体験が必要？ ──→ YES ──→ 対話の性質は？（下の 2.1.1 で分岐）
    │                          NO
    │                          ↓
    ├─ イベント/条件に基づく自動処理？ ──→ YES ──→ 【Power Automate】（§4 へ）
    │                                     NO
    │                                     ↓
    ├─ データの閲覧・編集 UI が必要？ ──→ YES ──→ 【Code Apps / Power Pages or Azure / Model-Driven Apps】（§5 へ、Canvas Apps は常に対象外）
    │                                    NO
    │                                    ↓
    ├─ Power Automate フロー内にイベント駆動（非チャット UI）で AI 処理を組み込みたい？
    │     （例: 通知・リマインドの文面生成、条件判定への AI 組み込み） ──→ YES ──→ 【AI Builder】（§6 へ）
    │                                   NO
    │                                   ↓
    └─ データモデル/ストレージが必要？ ──→ YES ──→ 【Dataverse のみ】

社内汎用業務は原則 Copilot Studio v2 スキル + Dataverse MCP（+ Code Apps）で実現する。AI Builder は「通知・リマインド等で Power Automate フロー内に AI 処理を組み込みたい」イベント駆動・非チャット UI のケースに限定して採用する（§6 参照）。

2.1.1 「対話型が必要」の分岐: まず Copilot Studio v2 スキル + Dataverse MCP を検討する（★重要）

対話型の体験が必要 = 即 Copilot Studio（v1）ではない。利用者が 自分から AI に話しかけて Dataverse へ登録・照会し、Code Apps で結果を見るような「チャットで話しかけて実行する」業務は、Copilot Studio v2 スキル + Dataverse MCP を第一候補にする。環境制約が少なく作りやすいため、Cowork プラグインより先に検討する。

対話型の体験が必要
    │
    ├─ ① ユーザーが能動的に AI へ話しかけて解決する
    │     （Dataverse への登録/照会 + Code Apps で閲覧。Teams / Copilot Studio 上で完結）
    │        ──→ ★【Copilot Studio v2 スキル + Dataverse MCP】を第一候補（→ copilot-studio-v2 スキル）
    │                 M365 Copilot 上での利用が必須要件の場合かつ会社環境で Cowork の利用が許可されている場合のみ Cowork プラグインを追加検討
    │
    ├─ ② 自律的に起動して動く必要がある
    │     （メール受信・Teams 返信・スケジュール等のイベントで自動実行、無人で判断・応答）
    │        ├─ トリガーが Dataverse のレコード作成/更新 ──→ ★【Copilot Studio v2 ワークフロー（Agentflow: Dataverse トリガー + エージェント ノード）】（設計リファレンス パターン F）
    │        └─ トリガーがメール/Teams/スケジュール等の外部イベント ──→ 【Copilot Studio（Workflow / トリガー）+ Power Automate】（§3・§4 へ）
    │
      ├─ ③ Code Apps に AI 対話を組み込む
      │        ├─ Copilot Studio の標準チャット UI をそのまま表示
      │        │    ──→ ★【Copilot Studio v2 Web app iframe】を第一候補
      │        ├─ 業務 UI と要求・結果を統合（非同期でよい）
      │        │    ──→ ★【Code Apps + Dataverse 要求/結果 + Workflow Agent ノード + v2】
      │        │          （設計リファレンス パターン F2）
      │        └─ 親アプリからのメッセージ注入・応答イベント取得・ストリーミングが必須
      │             ──→ 【Copilot Studio v1 の直接 SDK 連携】（§3 へ）
      │
      ├─ ④ 一般 Web サイトに表示する
      │        ├─ 標準チャット UI の iframe ──→ 【Copilot Studio v2 Web app】
      │        └─ WebChat SDK で UI・メッセージを制御 ──→ 【Copilot Studio v1】（§3 へ）
    │
      └─ ⑤ カスタムエンジンエージェントとして Teams / M365 Copilot に公開する
          （独自モデル・独自ツール・コードファーストのバージョン管理が要る
           ★または、エージェント自身がメールアドレス・予定表・権限を持つ「人」として働く）
             ──→ 【Agent 365 / AI チームメイト】（§7 へ）

使い分けの原則:

ユーザーがチャットで話しかけて実行するケース（能動的・有人）は Copilot Studio v2 スキル + Dataverse MCPで実装する。環境制約が少なく作りやすいため、第一候補とする。 Dataverse + Code Apps で組んだ業務データへのアクセスは、原則 Copilot Studio v2 スキル経由の自然言語操作を提案する。 M365 Copilot との統合が必須要件の場合のみ Cowork プラグインを追加検討（Global Admin 等の権限が別途必要。会社環境で Cowork の利用が許可されている場合のみ推奨）。

Copilot Studio でエージェントを作るのは次の 4 つのケース:

チャットで話しかけて実行するケース（v2 スキル + Dataverse MCP）— 第一候補（①）

自律的なケース — イベント/トリガーで無人起動し、自分で判断・応答・データ更新する（②）

Code Apps に組み込むケース — 標準 UI は v2 iframe、業務 UI 統合は v2 ワーカー方式、直接 SDK 制御が必須なら v1（③）

一般 Web サイトへ表示するケース — 標準 UI の v2 iframe、または UI を制御する v1 WebChat SDK（④）

**v2 ワーカー方式（③）**は、Code Apps がユーザー所有の要求行を Dataverse に作成し、Workflow の Agent ノードが既存の発行済み v2 を呼び、完全応答を結果行へ保存して Code Apps が読む。v2 のフラット Python スキルを再利用できるため、 JSON・文書・設計候補などの構造化生成では標準の第一候補とする。これは ExecuteCopilotAsyncV2 や WebChat による直接埋め込みではない。重複 Claim、要求者認可、相関 ID、タイムアウト後の同一 receipt 照合、AI 結果の独立検証を必須とする（設計リファレンスパターン F2）。

自律的なケース（②）で、すでに Copilot Studio v2 スキルを採用している場合は、Power Automate + v1 トリガーではなく Copilot Studio v2 ワークフロー（Agentflow: Dataverse トリガー + エージェントノード）を標準の第一候補とする。既存の発行済み v2 スキルをエージェントノードから呼び出せるため、Power Automate も v1 も追加せずに同一アーキテクチャで完結できる（設計リファレンスパターン F）。

構築手順は copilot-studio-v2 スキル（①）、Cowork の UI 併設方針は §5 を参照。

参照したいデータが Dataverse に無い場合（既存の基幹 DB・ファイルサーバー・業務 API）は、上記のどの分岐であっても 自前 MCP Server（Azure Functions） を併せて検討する（→ §6.5）。同じ MCP Server を Copilot Studio v2 にも Cowork にも登録できるため、公開先は後から増やせる。

2.2 複合パターン（最も多い）

多くの要件は 複数コンポーネントの組み合わせになる（CRUD+通知、対話+データ操作、対話+外部連携、対話+定期実行/イベント駆動、AI 分析+対話、外部ポータル+データ操作、フルスタック）。各パターンの構成・典型ユースケースの一覧表は設計リファレンスを参照。

3. Copilot Studio を使う判断ポイント

★ まず §2.1.1 を確認する。「ユーザーがチャットで話しかけて Dataverse に登録/照会する」有人の対話は Copilot Studio v2 スキル + Dataverse MCP を第一候補とする。Code Apps への標準チャット表示は v2 Web app iframe、業務 UI と要求・結果を統合する場合は Dataverse 要求/結果 + Workflow Agent ノードによる v2 ワーカー方式を標準提案する。 v1 は親アプリからのプログラム的な会話制御、WebChat SDK、または既存 v1 資産の継続利用が必要な場合に採用する。

使う: 自律起動（イベント/トリガー）での無人実行・アプリ埋め込み/Web 公開・複数ツールの自律オーケストレーション・ナレッジ検索・要約/分析/レポート生成。 使わない（→ 代替）: ユーザーが能動的にチャットで登録/照会するだけ → Copilot Studio v2 スキル + Dataverse MCP（Cowork は M365 Copilot 必須時かつ会社環境で利用が許可されている場合のみ）／確定手順の 100% 実行・大量一括処理・LLM 不要の条件分岐 → Power Automate／UI 入力編集 → Code Apps／承認ワークフロー → Power Automate。

使う場面/使わない場面の詳細表はコンポーネント選定詳細を参照。

構築モード: 生成オーケストレーション一択

❌ トピックベース開発（Classic PVA）は行わない
✅ 生成オーケストレーション（Generative Orchestration）モード一択
   — LLM が Instructions に基づいてツール呼び出しを自律的に判断

★ 構築アーキテクチャの選択（Copilot Studio 採用時に必ず確認）

Copilot Studio を採用すると決まったら、v2（新アーキ）/ v1（旧アーキ）のどちらで作るかを必ずユーザーに確認する。

判断の起点は「直接・同期連携が必要か、非同期の要求/結果方式を許容できるか」:

Code Apps / Web サイトとの連携方式は？

├─ Copilot Studio の標準チャット UI を表示 ──→ ★ v2 Web app iframe
│     Code Apps では frame-src、サインイン、一般利用者の本人認可を公開ホストで検証する。
│
├─ Code Apps の業務 UI と非同期応答を統合 ──→ ★ v2 ワーカー方式
│     Code Apps → Dataverse 要求 → Workflow Agent ノード → v2 → Dataverse 結果 → Code Apps
│     フラット Python スキルと構造化出力を再利用できる。直接 SDK 呼び出しではない。
│
├─ 親アプリからのメッセージ注入・応答イベント取得・ストリーミングが必須 ──→ v1 直接 SDK 連携
│
├─ 一般 Web サイトへ標準 UI を iframe 表示 ──→ v2 Web app
│
├─ 一般 Web サイトで WebChat SDK を使用 ──→ v1
│
└─ Teams / Copilot Studio で利用 ──→ v2

重要（連携方式の分離）: v2（新アーキ / cliagent）の Web app iframe は表示チャネルとして利用できる。ただし、iframe 表示は ExecuteCopilotAsyncV2 や WebChat SDK の代替 API ではなく、親アプリからの任意メッセージ注入、応答イベント取得、利用者コンテキスト連携を自動的には保証しない。アプリ制御が必要なら v2 ワーカー方式または v1 を選ぶ。

AskUserQuestion で次のように尋ねる:

Copilot Studio エージェントの構築方法を選べます。どちらにしますか？

v2 Web app iframe（標準表示）: Code Apps / Web に Copilot Studio の標準チャット画面を表示する。

v2 非同期ワーカー（標準提案）: Code Apps 内で受付・実行状態・完全応答を表示する。Dataverse要求/結果とWorkflow Agentノードを介し、v2スキルを利用する。ストリーミングは不可。

v1 直接 SDK 連携: 親アプリからの会話制御、応答イベント取得、ストリーミング、または WebChat SDK が必要な場合。

v2 単独利用: Teams / Copilot Studioで利用する。APIによる再現構築・量産に優れる。

シナリオ	推奨	使用スキル
Code Apps内に標準チャットUIを表示	v2 Web app iframe（第一候補）	`code-apps` + `copilot-studio-v2`
Code Apps内の非同期チャット・構造化生成	v2ワーカー方式（第一候補）	`code-apps` + `agent-flows` + `copilot-studio-v2`
Code Appsから会話を直接制御	v1直接 SDK 連携	`copilot-studio`
一般Webサイトへの標準UI iframe	v2 Web app	`copilot-studio-v2`
一般WebサイトへのWebChat SDK統合	v1	`copilot-studio`
単独利用（Teams / Copilot Studio 単体の対話のみ）	v2	`copilot-studio-v2`

v1/v2 の詳細な判断軸表（呼び出し可否・自動構築・作り込み等）はコンポーネント選定詳細を参照。

4. Power Automate を使う判断ポイント

使う: イベント駆動の自動実行・確定的な手順・コネクタ経由の外部連携・承認ワークフロー・一括処理・トランザクション処理。 使わない（→ 代替）: ユーザー対話／あいまい入力の解釈／自然言語レポート → Copilot Studio、リッチ UI → Code Apps。

Power Automate 単体 vs Copilot Studio + トリガーの判断（要約）

最も迷いやすいポイント。判定: ① Copilot Studio でしかできない処理（下表 ✅）があれば PA(トリガー)+Copilot、② コンテンツを確定手順で加工・転送するだけなら PA 単体、③ LLM の判断・生成が要れば PA(トリガー)+Copilot。

判断基準	Power Automate 単体	Copilot Studio + トリガー
コンテンツ（添付・本文）の転送・保存	✅	❌ 不要
固定条件での分岐・ルーティング	✅	❌ 不要
Web 検索	❌ 不可	✅
ナレッジ検索（SharePoint / Dataverse）	❌ 不可	✅
Word ファイル作成（Work IQ MCP）	❌ 不可	✅
MCP Server ツール利用	❌ 不可	✅
自然言語での応答・レポート生成	❌ 不可	✅
あいまいな入力の解釈	❌ 困難	✅

詳細な判断フロー（ASCII 図）・使う場面/使わない場面・役割パターン（スタンドアロン/トリガー/ツール）はコンポーネント選定詳細を参照。

5. UI コンポーネント選定

★ 入力の既定は Copilot Studio v2 スキル + Dataverse MCP を優先提案する（Dataverse + Code Apps 構成では特に）。 Dataverse にデータを貯める構成では、利用者は今後アプリ画面を見ながら入力するのではなく、Copilot Studio v2 スキル（Dataverse MCP 経由）から自然言語で登録するようになる。 Cowork プラグインと比べて環境制約が少なく作りやすいため、初回のアーキテクチャ提案では Copilot Studio v2 + Dataverse MCP を第一候補とする。そのため初回のアーキテクチャ提案では、データ入力の主接点として Copilot Studio v2 スキル + Dataverse MCP（SKILL.md + Dataverse MCP）を第一候補に含める。 Code Apps は「一覧・ダッシュボード・複雑な編集・可視化」を担う閲覧/操作の接点として併設する（入力専用の画面作り込みに時間をかけない）。

提案の型: Dataverse（基盤）＋ Code Apps（閲覧・分析・複雑操作）＋ Copilot Studio v2 スキル + Dataverse MCP（自然言語での登録・照会） を既定セットとして提示する。

内部ユーザー向けの入力は Copilot Studio v2 スキル + Dataverse MCP を優先。M365 Copilot との統合が必須要件の場合のみ Cowork プラグインを追加検討（Global Admin 等の権限が別途必要。会社環境で Cowork の利用が許可されている場合のみ推奨）。外部ユーザー向けは Copilot Studio v1 埋め込み / Power Pages を使う（§3・§5 参照）。

既存の基幹 DB ・ファイルサーバーのデータを併せて見せたい場合は、Dataverse への移行を前提にせず 自前 MCP Server を追加して読み取りだけ公開する（→ §6.5）。Copilot Studio v2 / Cowork のどちらからでも使える。

構築手順は copilot-studio-v2 スキルを参照。

Q: 対象ユーザーは？

├─ 外部ユーザー（顧客・パートナー・匿名アクセス含む）
│   └─ → 既定は Azure（Power Platform 外の Web/API）。ユーザーが Power Pages を明示的に希望した場合のみ Power Pages
│
└─ 内部ユーザー
    └─ Q: 標準の D365 開発をしたい、または既存 Model-Driven App の改修か？

        ├─ YES → Model-Driven Apps
        │
        └─ NO（新規の独自 UI）→ Q: 使う人のライセンスと頻度は？（下の「ライセンスで使い分ける」）
              ├─ ほとんどが Power Apps Premium を持つ／ゲストが使う／GA が必須 → Code Apps（既定）
              └─ Premium を持たない人が中心で、使うのはたまに
                    → Copilot Managed Runtime（Copilot Credits の従量課金）を選択肢として提示
                       （Public Preview の承認が必要。承認がなければ Code Apps）

外部ユーザー向け UI: 既定は Azure、Power Pages はユーザー宣言時のみ

外部ユーザー向け（顧客・パートナー・匿名アクセス含む）の UI は既定で Azure（Power Platform 外の Web/API 実装）を提案する。 Power Pages を提案するのは ユーザーが明示的に「Power Pages で作りたい」と宣言した場合のみとする:

Power Pages を選ぶ条件（ユーザー宣言 + 以下が該当）:
  ① ユーザーが Power Pages の利用を明示的に希望している
  ② Dataverse のデータを外部公開したい、またはテーブル権限で公開範囲を制御したい
  ③ 認証（Azure AD B2C 等）または匿名アクセスが必要

ユーザーが宣言しない場合（内部ユーザー向けを含む）→ Azure / Code Apps

詳細な開発・デプロイ手順は power-pages/SKILL.md を参照。 ⚠️ プロビジョニングに 10〜20 分かかるため、Phase 6 では完了を待ってから開発を続ける。

内部ユーザー向け: Code Apps を既定とする（参考: Model-Driven Apps）

方針: 内部ユーザー向けの新規画面は常に Code Apps を提案する。Canvas Apps は常に対象外 （パフォーマンス・カスタマイズ性・エンタープライズ運用の観点で不利なため）。Model-Driven Apps は標準 D365 開発または既存改善の場合のみ。

要点: カスタム UI・カンバン/ガント・インライン編集・ダークモードは Code Apps が優位。標準ビュー/フォーム自動生成・ビジネスルール/セキュリティロール統合、または標準 D365 開発をしたい場合は MDA が優位。

Code Apps / Canvas / MDA の機能比較マトリクス（11 項目、Canvas は参考情報）はコンポーネント選定詳細を参照。

内部ユーザー向け: ライセンスで Code Apps と Copilot Managed Runtime を使い分ける

社内向けの新規画面は、使う人が持っているライセンスと使う頻度で適した基盤が変わる。 §0 のヒアリングで必ず確認し、構成案と見積もりに「誰がどのライセンスで使うか」を書く。

観点	Code Apps	Copilot Managed Runtime
使う人に必要なもの	Power Apps Premium、Power Apps の従量課金（Azure サブスクリプション経由）、App Pass、自動割り当てのいずれか	Power Apps Premium、または Copilot Credits（Managed Application Copilot Credits）
Copilot Credits で払えるか	払えない	払える。アプリの起動ごとと API 呼び出しごとに消費する（API 呼び出しは 1 回 0.1 クレジット）
Premium を持つ人	追加費用なし	クレジットを消費しない。ただし Work IQ API など別課金のサービスと、Premium の API 要求上限を超えた分は消費する
費用の管理場所	ライセンス割り当てと Power Platform の従量課金プラン	Microsoft 365 管理センター → Copilot → Cost management（使う人ごとの支出ポリシー）
製品の状態	GA	Public Preview

使う人の状況	提案
ほとんどが Power Apps Premium を持っている	Code Apps（追加費用なし、GA）
Premium を持たない人が多く、使うのは月に数回・繁忙期だけなど不定期	Copilot Managed Runtime を選択肢として提示。ライセンスを買わずに、使った分だけクレジットで払える
Premium を持たない人が毎日繰り返し使う	両方を見積もって比較する。クレジットは起動と API 呼び出しの回数に比例するため、Premium や Power Apps の従量課金の方が安くなることがある
Cowork や Copilot Studio のためにクレジットを購入済み	Managed Runtime の実行費用を同じクレジットでまかなえる。選択肢として提示する
ゲスト（社外の人）が使う、または GA が必須	Code Apps（Managed Runtime はゲスト非対応で Preview）

AskUserQuestion の例（専門用語を避け、1 回で聞く）:

このアプリを使う人の契約について教えてください。

使う人のほとんどが Power Apps Premium を持っている → Code Apps で作ります（追加費用はかかりません）

Premium を持っていない人が多く、使うのはたまに → 使った分だけ Copilot クレジットで払える Copilot Managed Runtime も選べます（プレビュー版です）

分からない → 管理者に確認できるまで Code Apps を前提に進めます

Copilot Managed Runtime を選んだら、次も構成案と見積もりに書く。

クレジット消費の見積もり: 使う人の数 × 月の起動回数と、1 回の利用あたりの API 呼び出し回数 × 0.1 から見積もる。起動 1 回あたりの消費量と単価は Copilot Credits ライセンスガイドで確認し、推測の数字を書かない。
管理者の設定: M365 管理センターで従量課金を有効にし、アプリを使う人を実行用の支出ポリシーの対象に入れる。作るときの課金設定とは別に必要。
不足時の動き: Preview 中は、クレジットが足りない人は警告の後、20 操作または 5 分で使えなくなる。
作る側の費用: Cowork で作る → Microsoft 365 Copilot ライセンス＋クレジット。 Copilot Studio で作る → 環境単位のクレジット（作成・テストの段階から課金）。 CLI / SDK で作る → Learn の作成課金表には記載がない。ただし開発者がローカルで動かすときも、使う人と同じライセンス要件がかかる。

実装は managed-runtime スキル、根拠と比較は比較リファレンスのライセンス節を参照。

このプロジェクトの標準: Code Apps（Canvas Apps は常に対象外）

本プロジェクトでは Code Apps（TypeScript + React + Tailwind CSS） を標準とする。 Canvas Apps は常に対象外とする（パフォーマンス・カスタマイズ性・エンタープライズ運用の観点で不向きなため）。内部ユーザー向けの新規画面は、UI の複雑さに関わらず Code Apps を既定として提案する。ただし使う人が Power Apps Premium を持たず利用が不定期な場合は、上記のとおり Copilot Managed Runtime を選択肢として並べる。

camera、barcode、location 等の端末ネイティブ機能が必須なら、Web Code Apps と Native のどちらかを確認する。 Native を選ぶ場合だけ mobile-apps を使い、Private Preview／本番利用禁止への明示承認を得る。承認がなければレスポンシブ Web Code App を提案する。

★ Code Apps を適切なソリューションとして提案したら、このタイミングで環境側の前提条件チェックを必ず実行する。 Code Apps のデプロイには「環境での Code Apps 許可（コードアプリを許可する）」が必要で、未有効のまま設計・実装を進めると後工程で CodeAppOperationNotAllowedInEnvironment (403) 等のエラーにより手戻りが発生する。設計フェーズ・実装に入る前に以下を実行し、結果をユーザーに提示する。マネージド環境はガバナンス上の推奨状態として同時に確認するが、Code Apps の必須条件ではない。
python .github/skills/code-apps/scripts/check_code_apps_environment.py
✅ Code Apps 許可が有効 → そのまま設計フェーズ（デザインテンプレート選択）へ進む。

❌ Code Apps 許可が無効 → スクリプトが出力する有効化手順（Power Platform 管理センター）をユーザーに提示し、有効化を待ってから設計・実装を続ける。

⚠️ API で判定できない（Power Platform 管理者ロールがない場合は Code Apps 許可が 403 になる） → 出力される管理センター URL をユーザーに提示し、目視確認を依頼する。

詳細は code-apps スキル §2 環境の前提条件を参照。

★ Code Apps + Dataverse 並行開発パターン（正常フロー）

Code Apps が確定し、dataverse スキルでスキーマがユーザー承認されたら、code-apps スキルをサブエージェントとして起動し、Dataverse 構築と並行して Code Apps 開発を進める。
[dataverse スキル — メインエージェント]       [code-apps スキル — サブエージェント（並行）]
Step 4: --skip-localize で構築開始       →   scaffold → pac code init → npm run deploy
                                             → pac code add-data-source（全テーブル）
Step 4: --localize-only でローカライズ完了   （独立して実装フェーズへ継続）
Dataverse 側は --skip-localize 完了後に --localize-only へ進み、 Code Apps 側の add-data-source 完了を待たずに独立して動作する。

Model-Driven Apps の方針: 標準 D365 開発または既存改善のみ

Model-Driven Apps を使うのは以下のいずれかに該当する場合に限る（それ以外の新規開発は常に Code Apps）:

Model-Driven Apps を使う条件（いずれかに該当）:
  ① 標準的な Dynamics 365 の開発をしたい（標準 UI・自動生成のフォーム/ビューをそのまま使いたい）
  ② 既に本番稼働中の Model-Driven App があり、フォーム追加・ビュー変更・ビジネスルール追加等の改善要件である

上記いずれにも該当しない（新規の独自 UI）→ 常に Code Apps

理由: Code Apps は保守性・拡張性・UI カスタマイズ性に優れ長期的に有利。MDA は標準 D365 開発・自動生成が利点だがカスタマイズ制約で後から移行コストが発生しやすい。Canvas Apps は常に対象外。迷ったら Code Apps。

6. AI Builder を使う判断ポイント

基本方針: AI Builder は基本的に利用しない。社内汎用業務は Copilot Studio v2 + Dataverse MCP で実現する

社内の汎用業務は、ほぼ Copilot Studio v2 スキル + Dataverse MCP（+ Code Apps）で実現できる。利用者がチャットで話しかけて Dataverse に登録・照会し、Code Apps で結果を見る構成（§2.1.1・§5 参照）を第一候補とし、 AI Builder を安易に採用しない。

AI Builder を使うのは次の限定的なケースのみ:

通知・リマインド等で Power Automate の中に AI 処理を組み込みたいときに AI Builder を使う。どうしてもチャット UI ではなく、イベント駆動でフロー内に AI 処理を組み込む必要がある場合に限り、 Power Automate フロー内で AI Builder（AI プロンプト）を呼び出すパターンを採用する。それ以外（対話型・社内汎用業務全般）は Copilot Studio v2 スキル + Dataverse MCP を使う（M365 Copilot 統合が必須かつ会社環境で Cowork の利用が許可されている場合のみ Cowork プラグインを追加検討）。

AI 処理が必要
    │
    ├─ チャットで話しかけて実行する（有人・能動的） ──→ 【Copilot Studio v2 スキル + Dataverse MCP】（§2.1.1 へ）
    │
    ├─ イベント駆動で無人実行し、自律的な判断・応答が必要 ──→ 【Copilot Studio + Power Automate】（§3・§4 へ）
    │
    └─ イベント駆動（非チャット UI）で、Power Automate フロー内に
       定型 AI 処理（通知文生成・分類・抽出等）を組み込みたいだけ
          ──→ 【Power Automate + AI Builder】（本節）

AI プロンプト（カスタムプロンプト）を常に優先する

AI Builder を採用すると決まった場合、実装方式は AI プロンプト（カスタムプロンプト）を常に優先する。プロンプトテキストだけで実現でき、トレーニングデータ不要・即時更新で導入/保守コストが圧倒的に低い。請求書処理・ドキュメント抽出も、まず AI プロンプト + document 入力で検討し、OCR 精度が必須等プレビルトでしか実現できない場合のみプレビルトを使う。

プレビルト/カスタムモデルとの詳しい比較はコンポーネント選定詳細を参照。

使う: 通知・リマインド等、Power Automate フロー内にイベント駆動（非チャット UI）で組み込む定型 AI 処理（文面生成・分類・抽出等）。 使わない（→ 代替）: 社内汎用業務全般・チャットで話しかけて登録/照会する業務 → Copilot Studio v2 スキル + Dataverse MCP（Cowork は M365 Copilot 必須時かつ会社環境で利用が許可されている場合のみ）、対話形式／リアルタイム応答／1 回限りの分析 → Copilot Studio。

使う場面/使わない場面の詳細表はコンポーネント選定詳細を参照。

Copilot Studio の Instructions vs AI Builder プロンプトの判断

前提: この判断は「Copilot Studio エージェント or Power Automate フロー内で AI 処理を使う」と決まった後の実装方式の選択。社内汎用業務のチャット対話そのものは、まず §2.1.1 に従い Copilot Studio v2 スキル + Dataverse MCP を検討する。

Q: その AI 処理は再利用するか？

├─ エージェントの対話内で直接使う（1つのエージェント専用）
│   └─ → Instructions に記述（AI Builder 不要）
│
├─ 複数のエージェント / フローから呼び出す
│   └─ → AI Builder プロンプト（ツール化して共有）
│
└─ 構造化された入出力（JSON スキーマ）が必要
    └─ → AI Builder プロンプト（output.formats: ["json"]）

6.5 自前 MCP Server を使う判断ポイント（Dataverse 外のデータを繋ぐ）

使う: 参照したいデータが Dataverse に無い（既存の基幹 DB / ファイルサーバー / 業務 API に既にある）／移行・二重管理をせずに 読み取りだけエージェントへ公開したい／Private Endpoint の内側にあるデータをキーレス（Entra JWT + Managed Identity）で安全に出したい。

使わない（→ 代替）: データが Dataverse にある → Dataverse MCP（自前実装は不要）／確定手順での一括連携・書き込み同期 → Power Automate／単発の分析 → Copilot Studio のナレッジ。

Q: エージェントに読ませたいデータはどこにある？

├─ Dataverse ──────────────→ 【Dataverse MCP】（追加開発なし。§2.1.1 ①）
│
├─ SharePoint / Web / ファイル（非構造）
│                ──────────→ 【Copilot Studio のナレッジ】
│
└─ 既存の基幹 DB / ファイルサーバー / 業務 API
                 ──────────→ ★【自前 MCP Server（Azure Functions）】（mcp-server スキル）
                                 ＋ 呼び出し側を下の「公開先」で選ぶ

公開先の選択（★ Cowork とセットで提案できる）

同じ MCP Server を Copilot Studio からも Cowork からも使える。違いは登録方法だけで、 Server 側の実装は共通（どちらも Streamable HTTP + Entra OAuth）。

公開先	登録方法	向くケース	使用スキル
Copilot Studio v2 スキル	カスタムコネクタ（OpenAPI, `x-ms-agentic-protocol: mcp-streamable-1.0`）	Teams / Copilot Studio 単体で使う。環境制約が少なく第一候補	`mcp-server` + `copilot-studio-v2`
Copilot Cowork プラグイン	manifest の `agentConnectors.remoteMcpServer`	M365 Copilot（Cowork）上での利用が必須要件。文書作成・レビュー等 Cowork の生成能力と組み合わせたい	`mcp-server` + `cowork`

AskUserQuestion で確認する: 「このデータをどこから使いますか？ ① Teams / Copilot Studio（作りやすい・第一候補）、② M365 Copilot（Cowork。Global Admin 権限と Frontier 参加が必要）、③ 両方（MCP Server は 1 つのまま、登録を 2 系統作る）」

③ を選んでも Server の実装は増えない。API アプリ（api://<api-app-id>）を 1 つに集約しておけば、 Copilot Studio 用のカスタムコネクタと Cowork 用の OAuth registration を並行して作れる。

セット提案の型（Cowork + 自前 MCP Server）

M365 Copilot 上で基幹データを扱いたい要件では、次の 3 点セットで提案する。

自前 MCP Server（Azure Functions） — データソースごとに 1 つ。ツールは「一覧 / 検索 / 取得」の 3 系統
Entra API アプリ — スコープ 1 つ（例 MCP.Access）を公開し、Cowork の OAuth クライアントを事前承認
Cowork プラグイン — ビジネススキル（SKILL.md）＋ agentConnectors（MCP Server 分だけ列挙）

Dataverse も併用する場合は、agentConnectors に Dataverse MCP を併載し、各 description にどのコネクタをどの用途で使うかを明記する（エージェントはこの説明でツールを選ぶ）。手順は cowork スキルの自前 MCP コネクタ手順を参照。

外部データを繋ぐときの設計原則（★ 実プロジェクトで有効だった型）

複数の外部データソースを横断して回答させる要件では、次の 5 つを設計段階で決めておく。決めずに実装に入ると、あとから「どこに何を置くか」が崩れて破綻する。

#	原則	決めておく内容
1	移さずに繋ぐ	外部データは Dataverse に移行しない。Dataverse は台帳（問い合わせ・ナレッジ・マスタ）に限定し、外部データは MCP で都度読む。移行を選ぶと二重管理と権限の作り直しが発生する
2	1 データソース = 1 MCP Server	種類の違うストレージ（ファイル / RDB / 業務 API）を 1 つの Server に同居させない。権限（Managed Identity のロール）とデプロイ単位を分けられなくなる
3	書き込みは 1 か所に集約	外部データソース向け MCP は読み取り専用にする。書き込みは Dataverse MCP だけに担わせる。読み書き両方を外部に開くと監査（S-05 相当）が Server ごとに分散する
4	事前索引化するか、都度読むか	全文検索が要件なら索引化（コストと鮮度ずれが発生）。該当箇所を辿れれば足りるなら索引化せず都度読む。後者なら Azure AI Search 等の追加コンポーネントが不要になる
5	効果を KPI で測れる形にする	「外部データソースを根拠に含む回答の割合」を集計できるよう、回答・ナレッジの出典に種別（ファイルサーバー / 業務システム / 文書 / 台帳）を持たせる。MCP 追加の投資対効果が可視化できる

原則 5 の具体例: ナレッジの出典テーブルに出典種別の Choice 列を置くと、「外部データソース参照率」「根拠の横断度（2 種類以上の出典を突き合わせた割合）」が 追加の計測テーブルなしにダッシュボードで出せる。MCP Server を増やす判断の根拠になる。

見積もりに含める工数

項目	備考
Azure 基盤（VNet / Private Endpoint / Managed Identity / 監視）	azure-infra スキル。テナントのガバナンス次第で増減
MCP Server 実装（ツール定義 → 実装 → デプロイ → 実測検証）	データソース 1 つあたり。ツール数に比例
Entra 認可（スコープ公開・事前承認・コネクタ用 OAuth）	管理者同意の調整リードタイムを含める
登録（カスタムコネクタ or Cowork パッケージ）	公開先の数だけ
運用（証明書/シークレット更新・スキーマ変更追従・障害対応）	MCP Server は自社資産になるため、Dataverse MCP には無い継続コストが発生する

プロンプトインジェクション対策: MCP Server が返すデータに外部由来の文章（メール本文・取り込んだ文書等）が含まれる場合は、§0 のとおり対策を設計段階で工数に含める。

6.6 データ基盤を使い分ける判断ポイント（Dataverse / Fabric / Databricks / Foundry IQ）

データ基盤は system of record / analytics / semantic / knowledge の 4 役割ごとに決める。 1 製品にすべてを寄せない。判定表・典型構成・MCP 接続はデータ基盤の選定ガイドを参照。

役割	第一候補の判断
system of record	画面から 1 件ずつ登録・更新し、行レベル権限と監査が要る → Dataverse
analytics	Power BI / OneLake / SaaS 運用 → Fabric。ストリーミング / Spark / ML / 既存 Databricks → Databricks
semantic	エンティティと関係を明示的にモデル化 → Fabric IQ Ontology。統制 SQL 指標を自然言語で → Databricks metric view + Genie
knowledge	文書を引用付きで回答 → Foundry IQ（データストアではなく knowledge layer）

§0 のヒアリング結果を spec/data-requirements.json にまとめ、判定スクリプトで契約を出力する。

python .github/skills/data-platform/scripts/recommend_platform.py --requirements spec/data-requirements.json --out spec/data-platform.json

出力の needsDecision が空でなければ、候補と理由を示して AskUserQuestion で確定する。
Dataverse は dataverse スキル、Fabric / Databricks / Foundry IQ は data-platform スキル、データ投入は data-migration スキルに渡す。
有償の容量（Fabric capacity、Databricks SQL warehouse、AI Search）は構成図と見積もりに停止方法と常時課金の有無を併記する。

7. Agent 365 / AI チームメイトを使う判断ポイント（★ 実装レベルを必ず確認）

使う: 独自モデル・独自ツールのエージェントを Teams / M365 Copilot に公開したい／エージェント定義をコードとしてバージョン管理・レビューしたい／インストールごとに専用の Entra Agent ID を持たせたい／ エージェント自身のメールアドレス・予定表・権限を持つ「デジタルな同僚」が欲しい。 使わない（→ 代替）: Dataverse への自然言語登録・照会が主目的 → Copilot Studio v2 スキル + Dataverse MCP（§2.1.1）／ Code Apps や Web サイトに埋め込む → Copilot Studio v1（§3）。

★ 第一候補は Foundry hosted agent の Autopilot 発行。旧来の activityprotocol を agentUser エンドポイントへ直接つなぐ方式は 401 で成立しないが、Autopilot publish は別経路であり、 hire したインスタンスごとに agent user が払い出される。独自ホスト制御が必要な場合だけ Agents SDK + App Service 自己ホストを選ぶ。

★ パターン認識: 「ハンター（リード開拓）・テック（技術提案）・ミーナ（進捗管理）のように、名前と役割を持つ複数の AI エージェントが 1 チームとして協働する（AI 社員・AI チーム）」という要件は、 foundry-autopilot スキル（エージェントテンプレート）を第一候補として提案する。各エージェントを個別の agentUser（Teams 公開）として構築し、共有データが必要な場合は Dataverse テーブルを介した非同期連携を検討する。

★ パターン認識: 「デジタルな同僚が欲しい」は Agent 365 で提案する

次のような言い回しが出たら、その場で Agent 365 のエージェンティックユーザー方式を提案する。他の選択肢（Copilot Studio / Power Automate / 通常の bot）では構造的に実現できない要件だから。

ユーザーの言い回し	本当に求めているもの
「デジタルな同僚が欲しい」「AI の部下・メンバーを増やしたい」	ディレクトリに載る、独立した 1 人のメンバー
「エージェント専用のメールアドレスを持たせたい」	自分のメールボックスでの送受信
「エージェントに予定表を持たせたい」「会議に呼びたい」	自分の予定表と会議の作成権
「予定調整を任せたい」「間に入って日程を決めてほしい」	相手とのやり取りを代行する秘書
「メールを捌いてほしい」「一次対応をさせたい」	自分から受信トレイを見て返信する動き
「自分の権限の範囲を超えて働いてほしい」	依頼者の代理ではなく、エージェント自身の権限で動く

最後の 1 行が決定打になる。Copilot Studio や Power Automate のエージェントは 呼び出したユーザー（またはフローの接続所有者）の権限で動くため、「自分には見えない情報にも到達できる独立したメンバー」にはならない。 Agent 365 の agentUser だけが自分の Entra ユーザーと自分の権限を持ち、監査ログにも自分の名前が残る。

提案の進め方（同じ質問を繰り返さない）:

foundry-autopilot/references/digital-colleague-design.md §2 の **役割カタログ（R1 予定調整の秘書 / R2 一次受付 / R3 ウォッチャー / R4 まとめ役 / R5 起票係 / R6 チーム）**を AskUserQuestion の選択肢として提示する（複数選択可）
同 §5 の制約を先に伝える — メールは push されず数分遅れる／エージェントはメールを既読にできない／他人の予定表は直接読めない（自然言語照会で代替）。後から言うと要件が崩れる
同 §7 の**段階（L1 話せる → L2 予定を持つ → L3 メールで働く → L4 業務データ → L5 自分から動く）**でどこまで作るかを合意する
社外の情報が業務に含まれていたら、その場で Web 検索（B10）も提案する（下記）
繰り返しの仕事が見えたら、定期実行（B11）も提案する（下記）
外部の文章を読むブロック（メール / Web 検索 / ファイル取り込み）を入れるなら、プロンプトインジェクション対策を工数に含めると伝える。agentUser は依頼者ではなく自分の権限で動くため、メール本文に書かれた命令がそのまま実行されると実データに被害が及ぶ（→ foundry-autopilot/references/prompt-injection.md）
そのうえで下のライト実装 / 本格実装を選ぶ
選択結果をまとめて foundry-autopilot スキルの Step 0 へ引き渡す

★ Web 検索は聞かれる前に提案する（既定は Grounding with Bing）

業務内容に社外の情報が一つでも含まれていたら——相手企業・業界動向・競合・製品仕様・ニュース・「最新の」「URL を読んで」——、要件として挙がっていなくてもその場で Web 検索を提案する。「調べられると思っていた」という後からの齟齬がいちばん多い箇所。

社外の情報も自分で調べられるようにしますか？

はい（推奨）: Grounding with Bing（Azure OpenAI Responses API の web_search ツール）で Web 検索と URL 閲覧を足す。追加の Azure リソースもプレビュー招待も不要で、 LLM に使う Azure OpenAI とマネージド ID のまま動く

いいえ: 社内データ（Work IQ / Dataverse）だけで完結させる

ルート	選ぶ条件
Grounding with Bing（既定）	上記に当てはまるすべての場合。実機検証済みで、招待や課金の追加手続きが無い
Web IQ MCP（使えるなら併用）	画像・動画の検索が業務要件の場合だけ。プレビュー招待が要るので、無ければ待たずに Bing で進める

同時に制約も伝える: Web の情報は正確性が保証されず、認証が要るページは読めない。回答には必ず出典 URL を添える。詳細は foundry-autopilot/references/web-grounding.md。

★ 定期実行も聞かれる前に提案する（頻度はこちらから出す）

業務の中に繰り返される仕事が一つでも見えたら——「毎朝」「週次」「月初に」「見ておいて」「止まっているものを探して」「サマリを送って」——、時刻起動で自分から動く形を提案する。対話しか無いエージェントは、呼ばれなくなった時点で使われなくなる。

時間が来たら自分から動いて、結果を届ける形にしますか？

はい（推奨）: 頻度・時刻・配信先を会話で決めて登録する。変更のたびに再デプロイしない

いいえ: 聞かれたときだけ答える

頻度を聞かない。 仕事の内容から推定して「平日 8:00 に Teams チャットへ」のように 1 案を提示し、可否だけ取る。確定させるのは頻度・時刻・配信方法・宛先の 4 点だけ。

配信経路	選ぶ条件	前提
Teams チャット	毎日読むもの、その場で反応してほしいもの	インスタンス SP への Graph 委任同意（B9）
メール	週次・月次、転送や保管されるもの	Work IQ 接続（B4）

同時に制約も伝える: 粒度は日単位（時間ごとは想定外）、実行に失敗しても同じ回は再送しない、アプリが長く停止するとその回は飛ぶ。「毎朝必ず届く」と約束しない。詳細は foundry-autopilot/references/scheduled-delivery.md。

Agent 365 にしない場合の代替（要望が実は軽いとき）:

実際の要望	代替
チャットで話しかけて Dataverse を操作したいだけ	Copilot Studio v2 スキル + Dataverse MCP（§2.1.1 ①）
決まった条件でメールを自動処理したいだけ（判断が不要）	Power Automate（§4）
共有メールボックスの体裁だけが欲しい	Exchange の共有メールボックス + Power Automate
Code Apps / Web に埋め込むチャット	Copilot Studio v1（§3）

★ ライト実装 / 本格実装を AskUserQuestion で選ぶ（`foundry-autopilot` スキルに入る前に必ず実行）

foundry-autopilot スキルは 本格実装（private リポジトリ + CI/CD + Agent Evals）を既定としているが、検証目的の PoC にはその一式が重すぎる。着手前に実装レベルを確認し、選んだ結果を foundry-autopilot スキルへ引き渡す。

AskUserQuestion で次のように尋ねる:

エージェントの作り方を選べます。どちらにしますか？

ライト実装（PoC・検証用）: 共有エージェントとして最短で Teams に公開する。ローカルの .env だけで動かし、 CI/CD・秘匿化ゲート・インスタンス化は作らない。あとから本格実装へ昇格できる（作り直し不要）。

本格実装（本番運用）: private リポジトリでエージェント定義をバージョン管理し、秘匿化ゲート・Agent Evals による品質ゲート・承認付き自動デプロイまでを CI/CD で構築する。インストールごとに専用の Entra Agent ID を持つインスタンス化エージェントとして公開する。

観点	ライト実装（PoC）	本格実装（本番運用）
公開形態	共有エージェント（全員が同じ 1 体）	インスタンス化（Agent 365 ブループリント + `agenticUserTemplates`）
リポジトリ	任意（ローカルのみでも可）	private リポジトリ必須
秘匿値	ローカル `.env` のみ	`.env` + CI のシークレットストア
品質担保	手動での動作確認	秘匿化ゲート + Agent Evals + 承認ゲート
実施 Step	`foundry-autopilot` スキルの Step 4（ブループリント）・11（インスタンス同意）を省略	全 Step

迷ったらライト実装から始める。エージェント定義・Teams パッケージ・スクリプトはそのまま流用でき、 Step 4（Agent 365 ブループリント）と Step 11（インスタンス SP への同意）を追加し、 CI/CD を alm スキルで有効化するだけで本格実装へ移行できる。

本格実装を選んだ場合: Git ホスティングも AskUserQuestion で確認する

GitHub 前提にしない。エージェント定義（instructions）は業務知識そのものなので private リポジトリを前提とし、利用中の Git ホスティングに合わせて CI とシークレット保管先を決める。

どの Git リポジトリで管理しますか？（いずれも private リポジトリ前提です）

GitHub（private）

Azure DevOps Repos（private）

その他の Git（GitLab / Bitbucket / 自己ホスト）

Git ホスティング	CI	シークレット保管先	`foundry-autopilot` の `SECRET_BACKEND`
GitHub（private）	GitHub Actions	GitHub Actions Secrets	`github`
Azure DevOps Repos（private）	Azure Pipelines	変数グループ（Key Vault 連携可）	`azure-devops`
その他 Git	各 CI	Azure Key Vault	`keyvault`
（ライト実装）	なし	ローカル `.env` のみ	`none`

選択結果は foundry-autopilot スキルの Step 0 でそのまま使う（同じ質問を繰り返さない）。構築手順は foundry-autopilot スキル、CI 定義の雛形は alm/references/ci-providers.md を参照。

8. 統合パターン・テンプレート

統合アーキテクチャパターン集・設計アウトプットテンプレート・よくある判断ミスは設計リファレンスを参照。

9. 判断チェックリスト（設計開始時に確認）

設計を始める前に、以下を順番に確認する:

10. 環境チェックと DLP 事前チェック（実装着手前に必須）

構成が確定したら、実装を始める前に admin スキルで「その環境で作れるか」を確認する。設計後に発覚するとコネクタ選定や環境準備からやり直しになるため、必ずこのタイミングで実施する。

# 1. 環境チェック（既定環境でないか / マネージド環境 / Dataverse / Code Apps / MCP / ロール）
python .github/skills/admin/scripts/check_environment.py --environment-id $env:ENV_ID

# 2. DLP 事前チェック（構成が使うコネクタを列挙する）
python .github/skills/admin/scripts/check_dlp.py `
  --environment-id $env:ENV_ID `
  --tenant-id $env:TENANT_ID `
  --connector shared_commondataserviceforapps `
  --custom-host <自前 MCP Server のホスト名>

読み取り専用で、対象環境に適用されるポリシーだけを評価する。確認する観点は 3 つ。

観点	影響
ブロックされたコネクタがないか	使えない。代替コネクタへ設計変更するか、管理者にポリシー変更を依頼する
Business / Non-business が混在していないか	同一アプリ・フロー・エージェントで併用できない。どちらかに寄せるか構成を分割する
カスタムコネクタが未分類でないか	Copilot Studio でツールがブロック表示になる。ホストを明示分類する

結果は必ずユーザーに提示し、問題がある場合は解消方針を合意してから実装に入る。 判定基準・コネクタ一覧・変更手順は admin スキルを参照。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

admin

無料日本語概要

Power Platform のテナント / 環境ガバナンスを確認・設定する管理スキル。開発着手前の環境チェック（既定環境ではないか・マネージド環境・Dataverse / Code Apps / MCP の有効化・セキュリティロール・管理 API アクセス）と DLP 事前チェックを非対話スクリプトで実行し、必要ならマネージド環境設定・カスタムコネクタの DLP 分類・ACP（Advanced connector policies）の許可コネクタを dry-run 付きで変更する。Microsoft 第一者サービスだけを許可する ACP 推奨プロファイルの適用と、クラシック DLP から ACP への移行も支援する。クラシック DLP と ACP は既定の混成モードで併用され、より制限の厳しい方が適用されるため両方を確認する。オプションとして、既定環境 / 個人開発者環境 / 市民開発者環境 / AI CoE セントラル / AI CoE 内製開発の 5 グループからなるテナント全体の環境戦略を、読み取り専用スキャン → 移行プラン（admin-migration-plan.md）→ レビュー → 適用の順で策定・実行する。設定は環境グループのルールで行うのを原則とし、グループルールに無い項目（既定環境ルーティング・Dataverse for Teams 禁止・Dataverse 検索・グループへの割り当て・Copilot クレジット配分）だけをテナント設定・環境個別設定・Dataverse の組織設定で補う。IP 制限・テナント分離・監査ログ・ライセンス配分などの管理設定は references にまとめる。