무료GitHub에 공개

architecture

Power Platform のコンポーネント選定と統合アーキテクチャを設計する。社内画面はライセンスと頻度で Code Apps / Copilot Managed Runtime を選ぶ。SharePoint URL は明示指定がなければ Dataverse への移行元とし、Code Apps の開発・初回デプロイを優先する。

環境チェックは明示依頼時・障害時だけ admin へ委譲する。Agent 365 は実装レベルと Git ホスティングを確定し、外部文書を読むエージェントはプロンプトインジェクション対策を含める。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard

연동 도구Excel SharePoint GitHub Azure OpenAI

설치 방법 보기

포함된 파일(6)

SKILL.md75.2 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（設計）の最初に実行する。個別コンポーネントのスキルに入る前に、まず要件を深掘りして全体像を確定させる。

SharePoint URL だけでは直接接続の指示と解釈しない。 Code Apps の業務データは、直接接続・継続利用が明示された場合を除き Dataverse に移行する。URL は仕様・移行元の参照情報として扱う。 dataverse でスキーマを構築し、data-migration で承認付き移行・照合を行う。ナレッジとしての文書参照と Code Apps の業務データ保存先は区別する。

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

クイックスタート時は提案先行モードを優先する

standard/references/quickstart.md から来た場合は、環境情報・資料・spec-builder の結果を引き継ぎ、以下の通常ヒアリング表を一から質問しない。資料がなければワークスペース名からアプリ案を先に提案し、 AskUserQuestion で方向性を確認する。業界知識とベストプラクティスを使って、事実・仮説・推奨を分けた To-Be 業務、AI 改善、 Code Apps + Dataverse を既定とする構成、段階的な実装計画まで具体化する。未確認の固有規程・人数・価格・契約は創作せず、仮説または要確認とする。白紙の要件ヒアリングや既存システムの単純なリフト&シフトで終わらせない。

業務フロー図とアーキテクチャ図を Mermaid コードブロックでチャットと Markdown の両方へ出力する。 業務フローは spec/output/docs/business-requirements.md、構成・AI 改善・実装計画は spec/output/docs/design-requirements.md に既存内容を保護して統合する。推奨案・代替案・判断材料を見せてから、本人が決める必要のある事項だけ AskUserQuestion で 1 問ずつ確認する。認証や環境選択の回答後に利用者へ工程を投げ返さず、提案・判断確認まで同じタスクで進める。設計・実装・デプロイ・移行・追加費用の承認範囲は区別する。

通常モードのヒアリング

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

AskUserQuestion で深掘りする項目

既知の情報は再質問せず、必要な不足事項だけを 1 問ずつ確認する。

確認項目	質問の例
解決したい課題	今どんな問題・不便がありますか？
現状の管理方法	今は 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、所有者

既知の事項は再質問しない。Code Apps は共通契約の開発優先方針に従い、環境設定・DLP・管理者権限の未調査を理由に実装を止めず、必要な実装先・承認範囲だけを確認して進む。それ以外の製品固有の公開・プレビュー承認は各専門スキルに従う。 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 採用後は DLP / ACP・Code Apps 許可・マネージド環境・MCP を先に調べず、 scaffold → init → predeploy / build → 初回 push を優先する。全テーブル構築・移行・ローカライズ完了は待たない。障害時だけ §10 の権限確認付き復旧へ進む。既知の禁止設定や組織ポリシーを回避してはならない。

★ 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	用途で移行を分ける	既存基幹データを移さずエージェントへ公開する要件なら MCP で読む。ただし Code Apps 向けの SharePoint URL は、直接接続・継続利用の明示がなければ Dataverse への移行元とする
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. 環境診断は明示依頼時・障害時だけ

通常は code-apps の初回デプロイへ直行し、環境確認のために admin を呼ばない。チェックを明示依頼された場合、または実操作が環境・接続・ポリシーの問題で失敗した場合だけ admin と権限確認付き復旧を使う。

失敗した操作・対象環境・エラーを固定し、依頼者の現在有効な委任権限と対象範囲を確認する。必要な診断を読める場合だけ実行し、修復権限とユーザー承認が揃えば最小変更・読み戻し後に元の操作を 1 回リトライする。権限なし・不明なら管理操作は行わず環境管理者へ依頼し、影響しないローカル開発は継続する。ポリシー回避、無断の環境変更、管理者ロールの自己付与はしない。

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

같은 저장소의 스킬

admin

무료

Power Platform のテナント / 環境ガバナンスを確認・設定する。通常開発では事前チェックせず、環境チェックの明示依頼時または開発・デプロイ障害時だけ診断する。依頼者の現在有効な委任権限と対象範囲を確認し、権限内の最小診断・承認済み修復・限定リトライ、権限不足なら管理者への依頼へ分岐する。環境・DLP・ACP・環境グループ・テナント戦略の確認と dry-run 付き管理操作を提供する。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard742026년 10월 19일 업데이트

agent-flows

무료

Copilot Studio 新 UI の Agent flows / Workflows を構築・公開・検証する。Dataverse レコード作成/更新トリガーから既存の発行済み Copilot Studio v2 を Agent ノードで呼ぶ標準経路、Code Apps との非同期要求/結果連携、および手動 Start + inline Agent の API ライフサイクル検証を扱う。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard742026년 10월 19일 업데이트

agm-qa-authoring

무료

株主総会の想定問答を、IR 抜粋（決算短信・説明資料・招集通知など）を根拠に下書きし、利用者の確認後に Dataverse の想定問答テーブルへ「下書き」として登録するスキル。 Use when ユーザーが「配当について想定問答を作って」「この論点の想定問答を 3 件追加して」「招集通知から想定問答を作って」「想定問答を登録して」と依頼したとき。 Dataverse MCP コネクタ（describe / read_query / search_data / create_record / update_record）を使用する。削除・テーブル変更のツールは使わない。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard742026년 10월 19일 업데이트

agm-qa-review

무료

株主総会の想定問答を点検し、根拠の IR 抜粋に無い数値・存在しない根拠 ID・回答者や注意事項の抜け・趣旨の重複・下書きのまま残っているものを一覧にするスキル（書き込みはしない）。 Use when ユーザーが「想定問答を点検して」「根拠の無い数値が無いか確認して」「下書きの想定問答を一覧にして」と依頼したとき。 Dataverse MCP コネクタ（describe / read_query / search_data）を使用する。書き込み・削除のツールは使わない。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard742026년 10월 19일 업데이트

agm-rehearsal-script

무료

株主総会の質疑応答のリハーサル台本（議長・株主・回答役員の読み上げ原稿）を、承認済みの想定問答から作り、Dataverse のリハーサル台本テーブルへ登録するスキル。 Use when ユーザーが「リハーサルの台本を作って」「QA-001〜QA-010 で読み上げ原稿を作って」「番号を言わない株主も入れた台本を作って」と依頼したとき。 Dataverse MCP コネクタ（describe / read_query / search_data / create_record / update_record）を使用する。削除・テーブル変更のツールは使わない。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard742026년 10월 19일 업데이트

ai-builder

무료

AI Builder の AI プロンプト（GPT Dynamic Prompt）を Dataverse API で作成し、Copilot Studio エージェントにツール（アクション）として追加する。Power Automate フローとの統合パターンも含む。

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

geekfujiwara/CodeAppsDevelopmentStandard742026년 10월 19일 업데이트

geekfujiwara의 스킬 모두 보기

이 스킬의 문제 신고

설치

명령으로 설치

npx skills add https://github.com/geekfujiwara/CodeAppsDevelopmentStandard --skill architecture

터미널에 붙여 넣고 실행합니다(Node.js 필요). Claude Code, Codex 등 설치할 에이전트를 고를 수 있습니다.

에이전트에게 부탁하기

다음 Agent Skill을 설치해 주세요.
https://github.com/geekfujiwara/CodeAppsDevelopmentStandard/tree/main/.github/skills/architecture

먼저 SKILL.md와 첨부 파일의 내용을 확인해 수상한 처리(외부 전송, 인증 정보 읽기 등)가 없는지 확인한 뒤 Claude Code는 ~/.claude/skills/architecture/, Codex는 ~/.agents/skills/architecture/ 에 배치해 주세요.

이 문장을 그대로 Claude Code나 Codex에 보내면 내용을 확인한 뒤 설치해 줍니다.

GitHub에서 소스 보기

저장소: geekfujiwara/CodeAppsDevelopmentStandard
스타: 74
포크: 20
카테고리: 인프라·DevOps
라이선스: MIT
원문 언어: 일본어
최종 업데이트: 2026년 10월 19일

스킬은 에이전트를 위한 지시와 스크립트의 묶음입니다. cccskills는 내용의 안전성을 보증하지 않습니다. 설치하기 전에 내용을 확인하세요.

포함된 파일(6)

SKILL.md(원문)

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

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

クイックスタート時は提案先行モードを優先する

通常モードのヒアリング

AskUserQuestion で深掘りする項目

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

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

2. 判断フローチャート

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

見積もりに含める工数

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

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

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

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

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

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

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

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

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

10. 環境診断は明示依頼時・障害時だけ

리뷰

댓글

같은 저장소의 스킬

admin

agent-flows

agm-qa-authoring

agm-qa-review

agm-rehearsal-script

ai-builder

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

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