2026-06-03

AI搭載の要件管理WebアプリをPower AutomateでSharePointと連携してみた

コンサル業務で毎回作る「機能要件一覧」。ゼロから手入力して、SharePointに手動アップ…この手間を Claude AI × Power Automate で自動化した実装記事です。セキュリティ設計も含めて解説します。

🛠 技術スタック

レイヤー	技術
フロントエンド / BFF	Next.js 16（App Router）
データベース	Supabase（PostgreSQL）
認証	NextAuth v5 + Microsoft Entra ID（Azure AD）
AI	Anthropic Claude API
ホスティング	Vercel
SharePoint連携	Power Automate（HTTPトリガー）

🏗 アーキテクチャ全体図

🌐 ブラウザ（ユーザー）

↕

Vercel / Next.js 16

App Router
Server Components

↔

API Routes
Serverless Functions

↓ ↙ ↘

🗄 Supabase
PostgreSQL DB

projects / features
schedules

🤖 Claude API
Anthropic

機能一覧を自動生成

⚡ Power Automate
HTTP Trigger

↓

📊 SharePoint
Excel自動生成

↕

Microsoft 365

🔐 NextAuth v5

→

Microsoft Entra ID
Azure AD（テナント固定）

1. 認証設計：2段階アクセス制御

Microsoftサインイン

Azure ADで組織アカウント認証
他テナントは遮断

→

アクセスコード入力

アプリ独自の合言葉
HttpOnly Cookieで管理

→

案件一覧へ

8時間有効
再入力不要

1-1. Azure ADによる組織限定ログイン

issuer にテナントIDを固定することで、自社以外のMicrosoftアカウントでは認証が通りません。/common エンドポイントは使用しません。

src/lib/auth.ts

export const { handlers, auth, signIn, signOut } = NextAuth({
  secret: process.env.AUTH_SECRET,
  providers: [
    MicrosoftEntraID({
      clientId:     process.env.AZURE_AD_CLIENT_ID,
      clientSecret: process.env.AZURE_AD_CLIENT_SECRET,
      // テナントIDを固定 → 他組織のアカウントはログイン不可
      issuer: `https://login.microsoftonline.com/${process.env.AZURE_AD_TENANT_ID}/v2.0`,
    }),
  ],
  pages: { signIn: '/', error: '/' },
})

1-2. アクセスコードによる二重ロック

Azure ADサインイン後でも、独自のアクセスコードを入力しないと案件一覧を見れません。状態は HttpOnly Cookie で管理するため、JavaScriptから読み取り不可です。

src/app/api/unlock/route.ts

export async function POST(req: NextRequest) {
  const { password } = await req.json()

  // 環境変数で管理 → ソースコードに値が入らない
  if (!password || password !== process.env.SITE_PASSWORD) {
    return NextResponse.json({ error: 'Invalid' }, { status: 403 })
  }

  const res = NextResponse.json({ ok: true })
  res.cookies.set('site_unlocked', 'true', {
    httpOnly: true,   // JSから読み取り不可
    secure:   true,   // HTTPS限定
    sameSite: 'lax',  // CSRF対策
    maxAge:   60 * 60 * 8, // 8時間有効
  })
  return res
}

💡 ポイント：Edge Runtime vs Node.js Runtimeの罠

NextAuthの auth() と cookies() をミドルウェア（Edge Runtime）で組み合わせると動作が不安定になる問題がありました。
解決策： 認証チェックをEdge Runtimeから外し、Node.jsランタイムで動く layout.tsx（Server Component）に移しました。

2. Claude APIによる機能一覧自動生成

2-1. APIキーはサーバーサイドのみ

Claude APIのシークレットキーは API Route内でのみ参照 します。クライアントコンポーネントから直接呼び出す設計は取っていません。

src/app/api/features/parse/route.ts

const client = new Anthropic({
  // ANTHROPIC_API_KEY はサーバー環境変数 → ブラウザに一切露出しない
  apiKey: process.env.ANTHROPIC_API_KEY,
})

const message = await client.messages.create({
  model:      'claude-opus-4-5',
  max_tokens: 4096,
  system:     SYSTEM_PROMPT,
  messages:   [{ role: 'user', content: text }],
})

2-2. システムプロンプト：推測・水増し禁止

AIが勝手に機能を追加しないよう、明示的に制約をかけています。

システムプロンプト（抜粋）

const SYSTEM_PROMPT = `
あなたはシステム要件を機能一覧に変換するアシスタントです。

【厳守ルール】
- 入力から明示的に読み取れる内容だけを根拠にする
- 推測・補完・水増しは厳禁
- 入力に書かれていない機能を追加しない

【出力形式】JSON配列で返すこと
- category, title, description
- priority: 'Must' | 'Should' | 'Could'
- impl_type: '標準機能'|'設定'|'カスタム'|'外部連携'|'対象外'
`

2-3. DB制約違反への対処：正規化関数

SupabaseのCHECK制約に通らない値をAIが返すことがあるため、INSERT前にサーバーサイドで正規化します。

impl_type 正規化関数

function normalizeImplType(val: string): string | null {
  const v = val?.trim() ?? ''
  if (v.includes('標準'))               return '標準機能'
  if (v === '設定')                    return '設定'
  if (v.includes('外部') || v.includes('連携')) return '外部連携'
  if (v.includes('対象外'))             return '対象外'
  if (v.includes('カスタム'))           return 'カスタム'
  return null // DBエラーではなくバリデーションエラーとして処理
}

3. Power Automate連携：SharePoint Excel自動生成

3-1. 設計方針

SharePoint APIを直接呼ぶ場合、OAuthトークン取得・ファイル操作・テーブル書き込みを全て自前実装する必要があります。
Power AutomateのHTTPトリガーに委譲することで、SharePoint操作をノーコードで実現し、アプリ側のコードを最小化しました。

3-2. フロー構成

📡

① HTTP 要求の受信時（HTTPトリガー）

アプリからPOSTされたJSONを受け取る。JSONスキーマで受信データの型を定義することで、後続ステップで各フィールドを参照可能にする。

📋

② ファイルのコピー（SharePointコネクタ）

s_template.xlsx をコピーして日時名で新しいファイルを作成。
concat('機能一覧_', convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyyMMdd_HHmm'), '.xlsx')

🔁

③ Apply to each → 表に行を追加（Excel Online Business）

featuresの配列をループし、コピーしたファイルのテーブルに1行ずつ書き込む。機能が50件あれば50回ループが回る。

3-3. アプリ側のコード（export API Route）

src/app/api/features/export/route.ts

export async function POST(req: NextRequest) {
  const { projectId, projectName } = await req.json()

  // Webhook URLは環境変数 → SASトークン付きURLがソースに入らない
  const url = process.env.POWER_AUTOMATE_URL
  if (!url) return NextResponse.json({ error: 'URL未設定' }, { status: 500 })

  // Supabaseからデータ取得
  const { data: features } = await supabase
    .from('features')
    .select('*')
    .eq('project_id', projectId)

  // Power AutomateにPOST（アプリはデータを渡すだけ）
  await fetch(url, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ projectId, projectName, features }),
  })

  return NextResponse.json({ ok: true })
}

💡 ポイント：Power Automateを使う理由

SharePoint APIを直接叩く場合、OAuth 2.0トークンの取得・リフレッシュ、ファイルID管理、テーブルへの書き込みAPIなど実装コストが高い。Power AutomateのExcel Online Businessコネクタに任せることで、この部分を完全ノーコードで実現できます。

4. 環境変数の管理

全てのシークレットをVercelのEnvironment Variablesに登録しています。ソースコード・.env.local・GitHubには一切含みません。

変数名	用途	公開範囲
AUTH_SECRET	NextAuthセッション署名	サーバーのみ
AZURE_AD_CLIENT_ID	Azure ADアプリID	サーバーのみ
AZURE_AD_CLIENT_SECRET	Azure ADシークレット	サーバーのみ
AZURE_AD_TENANT_ID	自社テナントID	サーバーのみ
NEXT_PUBLIC_SUPABASE_URL	SupabaseプロジェクトURL	公開可（RLS制御）
NEXT_PUBLIC_SUPABASE_ANON_KEY	Supabase匿名キー	公開可（RLS制御）
SUPABASE_SERVICE_ROLE_KEY	Supabase管理者キー	サーバーのみ
ANTHROPIC_API_KEY	Claude APIキー	サーバーのみ
SITE_PASSWORD	アプリ独自アクセスコード	サーバーのみ
POWER_AUTOMATE_URL	Webhook URL（SASトークン含む）	サーバーのみ

⚠️ NEXT_PUBLIC_ プレフィックスの使い分け

NEXT_PUBLIC_ が付いた変数はビルド時にバンドルされブラウザに露出します。Supabaseの匿名キーは仕様上公開可能（RLSで制御）ですが、それ以外のシークレットには絶対に NEXT_PUBLIC_ をつけないようにしています。

5. ハマったポイントと対処法

🔥 Edge Runtime vs Node.js Runtime の罠

NextAuthの auth() と cookies() をミドルウェア（Edge Runtime）で組み合わせると、クッキーの読み取りが不安定になる問題がありました。

✅ 解決策： 認証チェックをEdge Runtimeのmiddlewareから完全に除外し、Node.jsランタイムで動くServer Component（layout.tsx）に移しました。

🔥 Power AutomateのApply to eachループ名参照エラー

新しいデザイナーでコードビューを手書きすると、ループ名が Apply_to_each ではなく それぞれに適用する_1 のような日本語名になり InvalidTemplate エラーが発生しました。

✅ 解決策： 式を手書きせず、動的コンテンツパネルから選択することで自動的に正しい名前が入ります。

🔥 AIのimpl_type出力がDB制約に違反する

Claude APIが 'カスタム開発' や 'JS実装' など、SupabaseのCHECK制約に含まれない値を返すことがありました。

✅ 解決策： サーバーサイドに正規化関数を実装し、INSERT前に必ず変換を通すようにしました。

6. セキュリティ設計まとめ

🔐 Claude APIキー

API Route内でのみ参照。NEXT_PUBLIC_ なし。クライアントには一切露出しない。

⚡ Power Automate URL

SASトークン付きURLを環境変数に格納。クライアントには渡さず、サーバーからのみPOST。

🏢 Azure ADシークレット

Vercel環境変数のみ。テナントID固定で他組織のアカウントを遮断。

🍪 アクセスコード

HttpOnly + Secure + SameSite=lax のCookieで管理。JSから読み取り不可。

まとめ

✦Claude AIに要件テキストを渡すだけで機能一覧が自動生成できる。推測・水増し禁止のプロンプト設計が重要。

✦Power AutomateのHTTPトリガーを使えば、SharePoint操作をノーコードで実現できる。SharePoint APIの自前実装コストを大幅削減。

✦Next.js App RouterのServer Components / API Routeの境界を活かすことで、シークレットをサーバーサイドに閉じ込めやすい。

✦全シークレットをVercel環境変数で管理し、ソースコード・GitHubには一切含まない設計が前提。

Next.jsのApp RouterはServer ComponentsとAPI Routeの境界が明確なので、セキュリティを保ちながらAIやSaaSと連携する構成を作りやすいと感じています。
「コードで書くべきか、ノーコードツールに任せるか」の判断軸も今後の開発で意識していきたいと思います。

2026-05-26

Dynamics 365,Power Platformのキュレーションサイトを公開しました。

Dynamics 365 Power Platform

d365-hub.vercel.app

ぜひ、ご活用ください

2026-04-23

D365クエスト

劉備

諸葛亮

関羽

顧客

【劉備】

BGM:

進捗

2026-04-21

PL-600廃止になるけどドラクエぽいで遊んでみた

PL-600

2026-04-21

アーキテクトクイズ①

PL-600

2026-04-19

細かいところメモ

PL-600 Power Platform Dynamics 365

Microsoft公式の情報は頻繁にアップデートされているため、本記事は2026年4月時点の仕様に合わせて整理しています。昔の学習サイトや古い情報では Process Advisor や Per User Plan といった古い名称がまだ残っていますが、今はそれぞれ名称・構成が変わっている点も補足していきます。

📑 目次

PART 1 ── 要件分析とソリューション構想
PART 2 ── 実装・トラブルシュート・運用監視
振り返って気づいた3つの学び

PART 1 ── Solution Envisioning

① 要件分析とソリューション構想の勘所

PL-600の出題比率で最も大きいのが「ソリューションの構想と要件分析」で、45〜50%を占めています（2024年9月のスタディガイド改訂以降）。ここでは意思決定のフレームを5つに分けて整理します。

1-1. 標準機能で足りないときの判断軸 ── ISVとPoCの使いどころ

アーキテクトが最初にぶつかるのは「OOB（Out of the Box）で賄えるか、ISVを選ぶか、カスタム開発するか」の三叉路です。ここの判断軸がブレると、後工程のライセンス設計・運用コストすべてがズレていきます。

SMS送信は標準機能に存在しない

Power Platformの標準コネクタにはキャリアグレードのSMS送信機能は含まれていません。試験で「SMS通知を実装したい」と出てきたら、反射的にTwilio / Telesign などのISVソリューションまたはサードパーティコネクタを推奨する、と覚えておけば良いです。

なぜ？ Power Automateには「テキストメッセージを送信」系のアクションは存在するものの、これはDataverse内のToast通知やTeams通知系に近い話で、電話番号宛のキャリアSMSとは別物。電話番号宛の送信は常にキャリア回線を経由するため、キャリアと契約しているISV経由で送るのが実務の標準解です。

電子サイン（eSignature）はAppSourceから導入する

契約書への電子署名を要件に含む場合、DocuSign / Adobe Sign といったISVソリューションをAppSourceから導入するのが正解です。「AppSourceからダウンロード」という言い方は正確ではなく、AppSourceは環境にインストールするプラットフォームなので、「導入する／構成する」という表現の方が実装イメージに近いです。

なぜ？ Dynamics 365やPower Platformには、法的拘束力のある電子署名機能が OOB で提供されていないため。法的有効性を持つ電子署名には認証局との連携、タイムスタンプ、監査ログなどが必要で、これらを全部自前で作るのは現実的ではありません。

要件が曖昧な場合はPoCとトライアル環境

「顧客が何を欲しいか具体化できていない」状況でフル実装に突っ込むのはアーキテクトとして最悪の選択。まずPoC（概念実証）またはトライアル環境で要件を具体化するのが鉄則です。

なぜ？ 手戻りコストが開発後期に指数関数的に膨らむから。PoCで3日間〜1週間のサンドボックス検証を挟むだけで、要件の誤解で数十人月を溶かすリスクを大幅に下げられます。試験では「フル開発で提案する」という選択肢が必ず罠として入っているので、そちらに飛びつかないこと。

ISV選定時はロードマップとライセンスコストの両輪で評価

ISVソリューションを採用するときは、機能の有無だけでなくロードマップ（製品が更新され続けるか）と独自のライセンスコストの2点を必ず評価します。ベンダー都合で更新が止まれば、数年後に全置換が必要になります。

1-2. ライセンスと権限モデルの境界線

コールセンターエージェントは Portalライセンス不要

Power Pages（旧Portal）のライセンスは外部ユーザー（B2Cの顧客や取引先など）向けに設計されたもの。社内のコールセンターエージェントは内部ユーザーなので、Dynamics 365 Customer Service などのD365ライセンスで足ります。

なぜ？ Power Pagesライセンスは匿名・認証済みの外部訪問者向けに最適化されており、Dataverseへの直接的な読み書き操作は限定的。一方、内部エージェントはDataverseのモデル駆動型アプリでケース管理やナレッジベース検索を行うため、D365 Customer Serviceの機能フルセットが必要になります。ライセンスは「誰が、どの入り口から、どのレベルの機能を使うか」で切り分けられている、と理解しておくと応用がききます。

ポータルのIDプロバイダーは1つに絞るのが基本

Power Pagesで外部顧客のサインインを受ける際、IDプロバイダーは原則1つに絞るのが設計の標準解です。複数のIDプロバイダーを混在させることは技術的には可能ですが、運用複雑化・UX分断・アカウント重複のリスクが跳ね上がります。

なぜ？ 同じユーザーがAzure ADでもLocal認証でも登録できてしまうと、Dataverse上に二重の連絡先レコードが生まれ、マイページや注文履歴が分裂します。B2Bパートナー向けと一般消費者向けでサイトを分ける場合など例外はありますが、1サイト1プロバイダーが基本線。

1-3. データ戦略の全体像

製品情報の一次保存場所はDataverseテーブル

製品マスタのようなビジネスの中核データは、原則としてDataverseテーブルで管理します。SharePointリストやExcelに置くのはリスクが大きく、トランザクションの整合性・参照整合性・セキュリティロールによるアクセス制御を欠きます。

Dataverse → データレイク連携は2025年重要更新

ここは情報のアップデートが激しいエリアなので要注意です。「DataverseのデータをAzure Data Lakeへ」と聞くと昔は Export to Data Lake という機能名が出てきましたが、これは2024年11月1日で非推奨、2025年3月25日から段階的に廃止されています。

現在推奨されているのは以下の2択です。

選択肢	特徴	向いているシナリオ
Azure Synapse Link for Dataverse	自社のストレージアカウントにDelta/Parquet形式で連続エクスポート。BYOD的な使い方。	既存のデータパイプライン資産がある。ストレージを自分で管理したい。
Link to Microsoft Fabric	No-copy, No-ETL。Dataverseの境界内にデータを保持したまま、Fabric側から読み取り可能（read replica）。	Fabric/Power BIで分析中心。データ移動のコスト・運用を減らしたい。

試験対策上の注意：「Synapse LinkとDataflowを使う」という古い参考書の記述は今もまだ出回っていますが、2026年時点では「Synapse Link（またはLink to Fabric）＋必要に応じてDataflow」と理解しておくのが正しいです。Fabric Linkが選択肢に入ってくる可能性も高いので、両方押さえておきたいところ。

金額予測にCustomer Insightsはズレている

「売上金額を予測したい」という要件で Customer Insights を選ぶと減点対象です。Customer Insightsは顧客データ統合・セグメンテーション・CLTV分析を主眼にしたプラットフォームで、「売上金額の将来予測」は主戦場ではありません。

なぜ？ 売上予測（Revenue Forecast）はD365 Salesの予測機能が一次候補。商談（Opportunity）のパイプラインを分析して売上予測を行うネイティブ機能です。より汎用的な予測モデルを作りたいなら AI Builder の予測モデルも選択肢になります。Customer Insightsは「顧客が誰か・何を買うか」の予測寄りで、「いくらになるか」の予測とは目的関数が違います。

チャートの主戦場はD365ダッシュボード vs Power BI

用途	選ぶもの	根拠
シンプルな積み上げ・円・棒グラフで十分	Dynamics 365 標準ダッシュボード	Dataverseと直結。構築・共有コスト低。
クロスデータソース、複雑な計算、DAX、階層ドリルダウン	Power BI	DAX・リレーションシップ・RLSが強力。

Power PagesとD365ダッシュボードは「OOBで埋め込めない」

Power PagesにDynamics 365の標準ダッシュボードをOOBで埋め込む機能は用意されていません。これは試験に頻出する引っ掛けポイントです。

なぜ？ D365標準ダッシュボードはモデル駆動型アプリの内部コンポーネントで、Power Pagesの外部ユーザー向けレンダリングパイプラインとは異なるランタイムで動いているため。一方でPower BIレポートの埋め込みは公式にサポートされているので、ポータル上で分析ビューを見せたいときはPower BIレポートを設計するのが正解です。なお、Power PagesとPower BIの「標準統合」はなく、Power BI埋め込みの設定を自分で行う必要があります。

1-4. 非機能要件として整理すべきもの

試験では「これは機能要件か、非機能要件か？」を見分ける問題がよく出ます。「システムが何をするか」が機能要件、「どのように振る舞うべきか・品質特性」が非機能要件。

クレジットカード情報の非保存 → 非機能要件（セキュリティ）

なぜ？ 「カード情報を保存しない」というのは、システムの機能そのものを定義していない。むしろPCI-DSS準拠やデータ保護という品質特性を定義している。機能要件は「決済処理を実装する」。非機能要件は「決済処理が完了後、カード情報を24時間以上保持しない」。この切り分けが重要。

役割ベースアクセス制御 → 非機能要件（セキュリティ）

「ユーザーが自分の役割に必要なデータと機能にのみアクセスできる」も非機能要件です。RBAC（Role-Based Access Control）はセキュリティという品質特性を定義するもの。

1-5. プロセス改善の選択肢2025年重要更新

ここも名称変更が激しいエリアです。「タスクマイニング」と「プロセスマイニング」の両方を含むソリューションで、昔は Process Advisor と呼ばれていましたが、現在はPower Automate Process Miningに統合されています。

古い名称（2023年以前）	現在の名称（2025〜）	カバー範囲
Process Advisor	Power Automate Process Mining	プロセスマイニング（システムログ起点）＋タスクマイニング（画面録画起点）の両方を統合

補足： 2025年1月から Process Mining thin client app（Webクライアント）が利用可能になり、インストール不要でプロセス分析が可能に。また Fabric OneLake からのデータ取り込みもサポートされるようになりました。試験では新機能そのものが問われる可能性は低いですが、「プロセス分析にはProcess Miningを推奨」と答えられれば十分です。

PART 2 ── Implementation & Operations

② 実装・トラブルシュート・運用監視の勘所

要件を固めた後、実装フェーズとGo-live後のトラブルシュートで押さえるべき論点を、15項目に分けて整理します。ここは「現象 → 調査すべき場所 → 対処法」の型で覚えると効きます。

2-1. Power Pagesのコンポーネント設計

空き情報・在庫・予約可能レコードの一覧表示 → List

「ポータルに空き情報を並べたい」「予約可能な会議室を一覧表示したい」といった要件の答えは、ほぼ例外なくListコンポーネントです。

なぜ？ Power PagesのListは、Dataverseのビューをポータルページに直接マッピングする公式コンポーネント。どのテーブル・どのビュー・どのフィルター条件で見せるかをノーコードで設定できます。検索・ソート・ページング、Create/Edit/Delete権限の細かい制御もLiteパーミッションで対応可能。Basic Formと組み合わせれば「選択して申し込む」まで完結します。

ポータルから外部APIを呼ぶ → コンポーネント＋Web Template＋Site Settings

Power Pagesから外部APIを呼びたいときは、以下の3点セットで実装します。

要素	役割
コンポーネント（Web Component / React）	UI描画とユーザー操作の受付
Web Template（Liquid）	サーバサイドで外部API呼び出しのラッパを作る
Site Settings	APIエンドポイントや認証トークンの設定値を外部化

なぜ？ クライアントJavaScriptから直接外部APIを呼ぶとCORSと認証情報漏洩のリスクがあるため、Web TemplateというサーバサイドのLiquid経由で呼び出すパターンが安全。エンドポイントや認証情報をSite Settingsで管理しておけば、本番/検証でURLや鍵を切り替える運用も楽になります。

429エラー（Too Many Requests）への対策最新パターン

ピーク時に429エラーが出る場合、以下の2方向で対策します。

レイヤ	対策
クライアント側	`Retry-After` ヘッダに従う指数バックオフ（exponential backoff）
サーバ側	Custom API を作り、リトライ処理や操作のスロットリング制御を集約

なぜ？ 429 は「短時間に送りすぎた」を意味する標準的なレート制限応答。HTTP標準では Retry-After（または retry-after-ms）ヘッダが返るので、クライアントはこれに従って待機＆再送するのが基本線。ただしポータルから直接Dataverse操作を連発する構成だとボトルネックが可視化しづらいので、操作をCustom API側にまとめてサーバサイドで制御する方がエンタープライズ運用では保守しやすいです。「操作の集約＋リトライの一元化」がキーワード。

メンテナンスモードはPower Platform管理センターから有効化

オムニチャネル強化や大型アップデートの前に、ダウンタイム中のメッセージを出したい場合は以下の手順です。

Power Platform管理センター → Power Pagesサイト → 対象サイトを選択
「Site Actions」→「Enable maintenance mode」
「Custom page」を選び、独自のカスタムHTMLページのURLを指定

カスタムHTMLページの注意点：

そのページは公開アクセス可能であること
x-frame-options: SAMEORIGIN ヘッダを含めない（iframeで表示されるため）
同じPower Pagesサイト上にホストしない（サイト自身がダウンしているとメンテページも落ちる）

この3点は実装上の落とし穴なので、面接や現場の会話でも高確度で役立ちます。

2-2. Canvasアプリの実装パターン

CanvasにGoogleマップを出す → Launch + Image

Canvasアプリに地図機能を組み込むとき、Googleマップを使う場合は以下の組み合わせになります。

やりたいこと	関数・コントロール	しくみ
アプリ内に地図を画像として表示	`Image` コントロール + Google Static Maps API URL	緯度経度をURLパラメータに渡すと画像PNGが返ってくる
別アプリ（Googleマップ）を起動	`Launch("https://maps.google.com/...")`	ブラウザまたはモバイルのマップアプリを外部で開く

補足： Bing Mapsコンポーネントは標準で用意されています（Map control）。Googleマップ縛りでなければBing側で実装する方が楽。案件でGoogleマップ指定があった場合のみ上記のLaunch + Imageパターンを使います。

決済処理中のローディング表示 → Context変数＋Visible

保険会社のCanvasアプリで「決済が完了するまでローディングアイコンを出したい」ような要件の実装は以下のパターン。

決済ボタンのOnSelectで UpdateContext({isProcessing: true}) を実行
ローディングコントロールの Visible プロパティに isProcessing をバインド
決済完了後、UpdateContext({isProcessing: false}) で非表示に戻す

なぜContext変数か？ グローバル変数（Set）はアプリ全体で共有されるので、画面ローカルな表示制御には向きません。Context変数（UpdateContext）は画面内スコープに閉じるため、ボタン状態・ローディング表示・フォーム検証メッセージのような「この画面だけの一時的な状態」を管理するのに最適です。

起動が遅いときに調べる2つの数字

Canvasアプリの起動が遅い場合、確認するのは「データソース数」と「コントロール数」の2点です。

観点	目安	対策
データソース数	30を超えると起動時間が顕著に増加	統合ビュー／集計ビューに置き換える、不要なものを削除
コントロール数	500超で操作レスポンス悪化	コンポーネント化、画面分割、仮想化

Canvasアプリの監視ツール3種の使い分け

ツール	見えるもの	主な用途
Application Insights	ユーザー操作ログ、エラー、カスタムテレメトリ	画面単位の利用状況把握、エラーの原因調査
Power Apps Analytics	アプリ・接続・サービスの稼働状況	「アプリやコネクタに障害がないか」の俯瞰
Dataverse Analytics	API呼び出し回数、ストレージ消費	API制限に近づいていないかの確認、ライセンス最適化

覚え方： Application Insights はユーザー行動を見る、Power Apps Analyticsはアプリ健全性を見る、Dataverse Analyticsはデータプラットフォームの消費量を見る。3つのレイヤに分けて覚えると混乱しにくいです。

2-3. 複数アプリを使う場合のライセンス設計2024年以降の名称で整理

ライセンス計算は頻出トピックなので、2024年以降の名称で整理しておきます。

シナリオ	適切なライセンス	金額目安
Canvasアプリ1つだけを使う	Power Apps per app（1人1アプリ）	$5/user/app/月
Canvas 2つ + モデル駆動型 3つ（合計5アプリ）	Power Apps Premium（旧 Per User Plan）	$20/user/月

名称変更の注意： 昔「Power Apps per user」と呼ばれていたものは、現在Power Apps Premiumに改名されています（内容は同じ）。古い教材ではいまだに「per user」「P1/P2」という表記が残っていますが、現行の公式ドキュメントとPL-600の最新出題はPremiumベース。

なぜ5アプリならPremiumか？ Per Appは1人1アプリで$5/月。5アプリなら5×$5 = $25/月になり、Premium $20/月より高くつきます。損益分岐点は1人あたり4アプリ。5アプリ以上使うユーザーがいるならPremium、3アプリ以下ならPer Appの方が経済的です。試験では「per appはstackable（積み重ね可能）」という仕様を押さえた上で、計算させる問題が出ます。

2-4. 外部連携トラブル：調査の3点セット

同期がズレる・余計なビジネスロジックが走る

外部システムとDataverseを同期する構成で「データが合わない」「想定外のロジックが発火する」場合、確認する場所は以下の3点です。

確認先	見るもの
SDK（プラグインのトレース）	サーバサイドのカスタムロジックが何を実行したか
トレースログ	プラグイン・ワークフローの実行履歴と例外スタック
監査（Audit）	レコード単位の変更履歴（誰が・いつ・何を）

なぜこの3つか？ 異なる粒度で「何が起きたか」を追跡するため。監査は「データの変化」、トレースログは「コードの実行結果」、SDK（プラグイン開発・登録ツール）は「どのコードが動いたか」という違うレイヤーで切り分けられます。3つを突き合わせることで「外部システムから来たデータが、どのプラグインによって書き換えられ、最終的にどうなったか」が追えます。

Go-live後にルックアップに値がない・重複・望ましくない更新

本番切り替え直後に起きがちな以下のような現象です。

ルックアップ列の参照先が空になっている
データが重複して入っている
意図しない上書き更新が走っている

このときの調査順は次の3点。

SDK（プラグイン登録ツール）で、どのプラグインがどのイベントに登録されているか確認
プロセス（ワークフロー）セッションで、実行履歴とエラーを確認
投入順序の確認 ── 参照元テーブル（マスタ）より先に参照先（トランザクション）を投入していないか

なぜ投入順序が重要？ Dataverseはルックアップ列で参照整合性を取るため、参照先レコード（例：商品マスタ）が存在しない状態でトランザクション（例：受注）を投入すると、ルックアップが埋まらずに欠損します。データ移行時はマスタデータ → トランザクションデータの順が鉄則。

ポータル移行後「このメールアドレスは既に使用されています」

ポータル移行で旧システムから顧客データをDataverseに取り込んだ後、顧客がサインアップしようとすると「メールアドレスが既に使われています」とエラーになるケースがあります。

解決手順は次の2ステップ。

該当顧客にポータル招待を再送する（adx_invitationの仕組み）
ポータル側のSite Settingsで、Dataverse連絡先テーブルとのマッピング設定を確認

なぜ？ 移行データの連絡先レコードは既に存在するが、ポータル認証アカウントとのリンクがない状態。招待リンクを再送することで、Microsoftアカウントやローカル認証と既存連絡先レコードを紐付けできます。Site SettingsのAuthentication/Registration/InvitationEnabled などが正しく有効化されている必要があります。

2-5. ポータルにサインインできない

「ログインできない」症状への定番チェックは以下の2ステップ。

ブラウザでサードパーティCookieとローカルデータを有効化
ブラウザの履歴とキャッシュをクリア

なぜサードパーティCookieか？ Power Pagesの認証フローでは、IDプロバイダー（Azure AD B2Cなど）のドメインとポータルドメインが異なるケースが多く、その間の認証トークン受け渡しにサードパーティCookieを使っています。ブラウザ側でこれを無効化していると、認証成功後にセッションが確立できずループします。最近のブラウザはデフォルトで制限が厳しいので、このチェックは実務でも頻出します。

2-6. Dataverseコネクタ経由の文書移行

旧システムからDynamics 365へ文書（Note、Attachment、File列）を移行する際、Dataverseコネクタを使う構成が基本形。Dataflows、Azure Data Factory、カスタムアプリなどで取り込み元を作り、Dataverseコネクタを介してD365側に書き込みます。

ポイント： 文書はサイズが大きくAPI呼び出し回数も多いので、APIレート制限（前述の429）に当たりやすい領域。バッチサイズを小さくして分散投入するのがセオリーです。

2026-04-13

ソリューションの構想と要件分析

PL-600 Power Platform

📋 このドキュメントの構成

1. ソリューション計画の開始
2. ビジネス要件の評価
3. コンポーネント特定（製品選択）
4. Fit/Gap分析
5. 比較表まとめ
6. マニアック知識＆落とし穴
7. 試験頻出パターン

SECTION 1 ソリューション計画の開始

💡 なぜここが重要か

試験では「まず何をすべきか」という順序・優先度を問う問題が多い。アーキテクトは実装前にビジネス理解を先行させることが本質。「技術よりも先にビジネスを理解せよ」がPL-600の根幹思想。

🎯 成功基準（KPI）の確認

KPIは「ビジネス価値」として定義する
測定可能な指標（定量的）を優先
ステークホルダーと合意形成が必須
プロジェクト開始前に定義する（後付け不可）
例：応答時間削減率、手動作業削減時間、コスト削減額

⚠️ リスク評価の観点

技術的リスク（統合複雑性、データ品質）
組織リスク（変更管理、ユーザー採用）
ライセンスリスク（コスト超過）
スコープリスク（要件拡大）
コンプライアンスリスク（データ居住地制限）

🔄 ビジネスプロセス改善機会の特定フロー

Step 1

現状プロセスの把握
As-Is分析

→

Step 2

ペイン・ポイント特定
非効率・ボトルネック

→

Step 3

理想プロセス定義
To-Be分析

→

Step 4

ギャップ特定
何が足りないか

→

Step 5

優先度付け
Impact × Effort

⚠️ 試験の落とし穴

「プロセス改善 = 自動化」ではない。まずプロセス自体の見直しが先で、自動化はその後。不良プロセスを自動化しても問題は解決しない。

👥 ステークホルダー分析と関与方法

ステークホルダー種別	主な関心事	アーキテクトの対応	試験での頻出観点
エグゼクティブ（CxO）	ROI、コスト、リスク	ビジネス価値を数値で提示	KPIとROIの定義主体
業務部門マネージャー	業務効率、使いやすさ	As-Is/To-Beプロセス整理	要件収集の主要対象者
IT部門	技術整合性、保守性	既存システムとの統合検討	エンタープライズアーキテクチャ評価
エンドユーザー	操作性、日常業務への影響	ユーザー受け入れテスト設計	変更管理・採用戦略の対象
法務・コンプライアンス	データ保護、規制対応	データ居住地・セキュリティ要件定義	セキュリティレビュー要件

SECTION 2 ビジネス要件の評価

💡 なぜここが重要か

既存アーキテクチャの評価は「何を作るか」ではなく「何と共存するか」を決める。試験では「新規開発 vs 既存活用」の判断問題が頻出。

🏗️ エンタープライズアーキテクチャ評価の観点

評価軸	確認内容	Power Platform設計への影響
既存データソース	SQL Server、SAP、SharePoint等の存在と接続性	コネクター選択、Dataverseへの移行 vs 仮想テーブル利用
ID管理（Entra ID）	シングルテナント vs マルチテナント、ゲストユーザー	環境設計、セキュリティグループ構成
既存のD365アプリ	Sales、CS、F&O等の導入状況	Fit/Gap分析の基点。追加カスタマイズか別アプリか
ネットワーク・インフラ	オンプレミス資産、VPN、ファイアウォール	オンプレミスデータゲートウェイの要否判断
データガバナンス要件	GDPR、業界規制、データ保持ポリシー	環境数・地理的分離・DLP設計

📊 データ品質基準の定義

完全性：必須項目の充足率
正確性：実際の値との一致度
一意性：重複レコードの有無
適時性：データの鮮度・更新頻度
一貫性：複数ソース間の整合性

⚠️ 重要

データ品質の評価はマイグレーション計画より前に行う。不良データのまま移行しても解決しない。

🔒 セキュリティ要件レビュー観点

ビジネスルール（業務ロジックでのアクセス制御）
セキュリティロール（行・列レベルのアクセス）
Entra ID要件（MFA、条件付きアクセス）
セキュリティ境界（環境間・テナント間）
データ損失防止（DLP）ポリシー

📋 機能要件 vs 非機能要件の区別（試験頻出）

種別	定義	具体例	Power Platformでの考慮先
機能要件	システムが「何をするか」	案件の承認ワークフロー、顧客情報の表示	アプリ設計、Automate フロー、D365設定
非機能要件	システムが「どう動くか」	99.9%可用性、3秒以内の応答速度、1万ユーザー対応	環境設計、ライセンス、Azure統合判断
制約条件	設計の制限・前提	既存システムとの互換性、予算上限、期限	コンポーネント選択の絞り込み条件

SECTION 3 コンポーネントの特定：Power Platform製品の適切な使い分け

💡 なぜここが最重要か

「どの製品を選ぶべきか」は試験最頻出トピック。選択理由（なぜ）を答えられないと正解できない。機能の有無だけでなく「ユーザー・データ・プロセスの性質」から選ぶのが正しいアプローチ。

📱 Power Apps：Canvas vs Model-Driven vs Pages

比較軸	Canvas App	Model-Driven App	Power Pages
データ基盤	任意（SharePoint、SQL、Dataverse等）	Dataverse必須	Dataverse必須
UI設計	ピクセル単位で自由設計	データモデルから自動生成	Webサイト標準デザイン
主なユーザー	現場・特定タスク向け	CRM/ERP業務担当者	外部ユーザー（匿名含む）
ビジネスロジック	数式ベース（Power Fx）	サーバーサイド（プラグイン/ビジネスルール）	Liquid テンプレート＋Power Automate
向いているケース	現場検査、スキャン入力、モバイル特化	複雑な業務プロセス、D365拡張	顧客ポータル、パートナーサイト
ライセンス	Premium（Dataverse接続時）	Premium	ページビュー課金 or ログインユーザー課金
ALM（ソリューション管理）	ソリューション対応	ソリューション対応（完全）	Webサイト単位でエクスポート

🚨 マニアック：よく混同される判断基準

「UIの自由度が欲しい → Canvas」は正しいが、「複雑な業務ロジックがある → Canvas」は誤り。複雑なサーバー側ロジックはModel-Driven＋プラグインが正解。Canvas Appのビジネスロジックはクライアントサイドのみで、プラグインは使えない。

⚡ Power Automate：フロー種別の選択基準

フロー種別	トリガー	実行環境	向いているケース	注意点
クラウドフロー（自動/インスタント/スケジュール）	イベント・ボタン・スケジュール	クラウド	SaaS連携、通知、承認ワークフロー	実行回数制限あり（ライセンス依存）
デスクトップフロー（RPA）	クラウドフローから呼び出し or 手動	ローカルPC・仮想マシン	レガシーシステム操作、画面操作の自動化	Attended/Unattended の区別重要
ビジネスプロセスフロー	レコード操作	Dataverse上	段階的な業務プロセス誘導、ステージ管理	Model-Driven App専用。Canvasでは使えない
Dataverse for Teams フロー	Teams内	クラウド（Teams環境）	Teamsユーザー向け軽量プロセス	Teams環境のみ。Premiumコネクター不可

⚠️ Attended vs Unattended RPA（試験頻出）

	Attended（有人）	Unattended（無人）
ユーザーログイン	必要（ユーザーPCで実行）	不要（バックグラウンドで実行）
実行タイミング	ユーザーが起動	スケジュール・クラウドフローから起動
ライセンス	Power Automate Premium	Power Automate Process（追加ライセンス必要）
向いているケース	ユーザーが介在する半自動化	夜間バッチ、完全自動処理

📊 Power BI：設計判断の観点

判断軸	考慮すべき選択肢	選択理由
データ接続方式	Import vs DirectQuery vs Live Connection	Import：高速・定期更新。DirectQuery：リアルタイム必要時だがパフォーマンス注意。Live Connection：SSAS/Power BI Datasetへの接続
行レベルセキュリティ（RLS）	静的RLS vs 動的RLS	動的RLSはDAX式で`USERNAME()`を使用。ユーザー数が多い場合に推奨
共有・配布方法	ワークスペース共有 vs アプリ vs 埋め込み	外部ユーザーへの配布にはPower BI Embeddedが必要（Azure SKU）
Microsoft Fabric連携	Fabric Lakehouse / Warehouse	大規模データ・エンタープライズ分析ではFabricが推奨。F64以上のSKUが必要

🤖 Copilot Studio（旧 Power Virtual Agents）選択基準

Copilot Studioを選ぶ理由

自然言語での問い合わせ対応（FAQ自動化）
24時間対応が必要なサポートチャネル
Power Automate フローとの統合が必要
Microsoft 365 / Teams チャネルへの展開
コーディング不要でボット構築が必要

Copilot Studioを選ばない理由

複雑なカスタムロジック（Azure Bot Serviceが適切）
リアルタイム音声対応（Azure Cognitive Services）
高度なNLP・機械学習モデル統合
完全にコード制御が必要なシナリオ

SECTION 4 Fit/Gap分析：D365・AppSource・カスタム開発の判断

💡 なぜここが重要か

試験では「この要件にはD365標準機能で対応できるか、カスタム開発が必要か」という判断を問う。アーキテクトとして「まず標準機能の活用を優先する」が原則。カスタム開発は最後の手段。

⚖️ Fit/Gap判断の優先順位フレームワーク

Level 1 ✓ 最優先

D365標準機能
OOB機能・設定で対応

→

Level 2

AppSource ISVソリューション
業界特化・追加機能

→

Level 3

設定・構成でのカスタマイズ
フォーム・ビュー・ビジネスルール

→

Level 4

Low-code拡張
Power Apps・Automate

→

Level 5 ⚠️ 最終手段

カスタム開発
プラグイン・PCF・API

🚨 試験の核心

「カスタム開発は保守コスト・アップグレードリスクが高い」ため、標準機能で70%以上を満たせる場合はD365を推奨する。この判断基準が試験問題の選択肢分岐点になる。

🏢 Dynamics 365 主要アプリのFit/Gap判断基準

D365アプリ	主な対象業務	向いている要件	Gapが出やすい場面
Sales	営業管理・CRM	商談管理、予測、AI提案	非標準の承認フロー、業界特化ロジック
Customer Service	サポート・ケース管理	SLA管理、エスカレーション、ナレッジ	高度な請求連携、現場サービス（FSが別）
Field Service	現場保守・派遣	スケジュール最適化、作業指示	製造固有の品質検査、特殊資材管理
Finance & Operations	ERP（財務・SCM）	財務諸表、在庫、調達	Power Platform との直接Dataverse統合（Dual Write必要）
Customer Insights	CDP・マーケティング	顧客統合プロファイル、セグメント	リアルタイムEvent処理（カスタムAPI必要）

🛒 AppSource活用の判断基準

AppSourceを検討するタイミング

業界特化要件（医療・金融・製造）がある
D365標準機能に明確なGapがある
カスタム開発コストを抑えたい
既に市場で実績のあるソリューションがある
短期間での導入が求められる

AppSource採用時のリスク評価

ISVのサポート継続性（倒産リスク）
D365のメジャーアップデート時の互換性
カスタマイズ可能範囲の制限
追加ライセンスコストの発生
データプライバシー・セキュリティ審査

🔌 マイグレーション vs 統合の判断

判断軸	マイグレーション（移行）	統合（インテグレーション）
定義	データをDataverseに完全移行し元システム廃止	元システムを残しリアルタイム/バッチ同期
向いているケース	レガシーシステムの廃止、単一SoR（信頼できる唯一のソース）化	基幹系は変えられない、複数システムの継続運用
主なツール	Dataverse import、Data Migration Tool、Azure Data Factory	Dataverseコネクター、Azure Logic Apps、API Management
主なリスク	データ品質、変換ロジックの複雑さ、ロールバック困難	データ不整合、同期遅延、障害時の対応
試験のポイント	移行前のデータクレンジング・マッピングが必須	SoR（Single Source of Record）を明確に定義すること

SECTION 5 混同しやすい概念の比較表まとめ

🔄 Power Automate vs Azure Logic Apps vs Azure Functions（統合選択）

比較軸	Power Automate	Azure Logic Apps	Azure Functions
主なユーザー	業務ユーザー・市民開発者	IT/開発者（エンタープライズ統合）	開発者（コードベース）
開発方法	GUI（ローコード）	GUI＋JSON定義（ローコード/プロコード）	コード（C#、JavaScript等）
コネクター数	1000以上（DLP対象）	500以上（一部共通）	コードで任意のAPI呼び出し
複雑な処理	△（ループ・条件は可だが限界あり）	○（複雑なワークフロー定義が可能）	◎（制限なし）
ガバナンス	Power Platform管理センター・DLP	Azureリソースグループ・IAM	Azureリソースグループ・IAM
長時間実行	△（30日制限）	○（Standard: 無制限、Consumption: 90秒）	△（Durable Functionsで対応）
試験選択の判断軸	市民開発者が管理 / M365・D365との緊密な統合	IT管理者が管理 / エンタープライズ統合 / B2B EDI	複雑なカスタムロジック / 高パフォーマンス

🚨 試験で問われる典型シナリオ

「業務担当者がメンテナンスできるようにしたい → Power Automate」「外部SAP・SAPとの大量バッチ統合 → Azure Logic Apps」「ミリ秒単位の高速処理・AIモデル呼び出し → Azure Functions」

🏛️ 環境設計の判断基準（試験頻出）

環境分離の理由	推奨構成	なぜそうするか
開発/テスト/本番の分離	最低3環境（Dev / Test / Prod）	ALMの基本。本番への直接変更は禁止（試験原則）
地理的データ要件（GDPR等）	地域別の環境を設ける	データ居住地（Data Residency）規制への対応
部門間のデータ分離	ビジネスユニット or 別環境	過度な分離は管理コスト増。まずBU活用を検討
外部ユーザー向けポータル	本番環境内でPower Pages	別環境不要。Power Pagesは環境内で外部公開可能
Microsoft Teams利用者向け軽量アプリ	Dataverse for Teams環境	Premiumライセンス不要。Teamsユーザーは無料で利用可

💰 ライセンス選択の判断基準（弱点対策）

シナリオ	適切なライセンス	理由（なぜか）
全社員がSharePointデータのみ使うシンプルなアプリ	Microsoft 365付属（追加不要）	Dataverse・Premiumコネクター不使用ならM365で足りる
Dataverseを使うモデル駆動型アプリのみ利用	Power Apps Premium（旧:Per App / Per User）	Dataverse利用にはPremiumライセンスが必須
社員全員がRPAを使う（有人自動化）	Power Automate Premium（Per User with RPA）	デスクトップフロー実行にはRPA追加が必要
1台のPCでバックグラウンドRPA（無人）	Power Automate Process（旧:Unattended RPA Add-on）	Unattendedはマシン単位のライセンス。ユーザー課金と別
外部顧客向けPortalサイト（月10万PV）	Power Pages（ページビュー課金 or ログインユーザー）	匿名ユーザーはPV課金。認証ユーザーはログインユーザー課金
Power BI レポートをアプリに埋め込み（外部公開）	Power BI Embedded（A SKU / Azure課金）	外部ユーザーへのPower BI埋め込みはPro/Premiumでは不可

SECTION 6 マニアック知識と落とし穴

🚨 重要度は低いが出たら迷う項目

以下は「範囲内だが試験の中心ではない」または「知識があると選択肢を絞れる」項目。深追い不要だが概念は押さえておく。

🔗 仮想テーブル（Virtual Tables）

外部データをDataverse内のテーブルとして見せる
データはDataverseに保存されない
リアルタイムで外部システムから取得
OData 4.0準拠の外部サービスが必要

⚠️ 誤解しやすい点

仮想テーブルはDataverseの機能だが、データ量が多い場合やレイテンシーが高い場合はパフォーマンス問題が出る。大量データには向かない。

🌐 Dataverse for Teams の制限

Premiumコネクターは使えない
外部アプリからのAPIアクセス不可
環境あたりの容量上限：2GB
本番業務の重要データ保管には不適

Microsoft 365ライセンスのみで利用可能
Teams内でのチーム向け軽量アプリに最適
必要になればPower Apps環境にアップグレード可

📡 Dual-write（D365 F&O ↔ Dataverse）

F&O（ERP）とDataverse間のリアルタイム双方向同期
Customer Engagement（CE）アプリとの統合に使用
マッピングテーブルの設定が必要

⚠️ 注意

Dual-writeは複雑な設定を要し、パフォーマンスリスクがある。軽量な統合には Power Automate コネクターや Finance and Operations Data Entities が適切。

🔑 Power Platform Well-Architected Framework

信頼性：回復力・フェイルオーバー設計
セキュリティ：最小権限・ゼロトラスト
運用効率：ALM・監視・DevOps
パフォーマンス効率：スケーラビリティ設計
経験優位性：UX・採用・変更管理

※ 試験では設計判断の根拠として参照される

SECTION 7 試験頻出パターン：シナリオ → 正解の思考法

🎯 ケーススタディで使う思考フレームワーク

📖 読み解き手順

①誰がユーザーか（内部 or 外部 / 技術者 or 業務担当）→ ②データはどこにあるか → ③プロセスの複雑さ → ④保守・管理は誰がするか → ⑤ライセンスコスト制約 → 製品・設計を選ぶ

シナリオのキーワード	示唆する正解方向	なぜか
「外部のパートナー・顧客が使う」	Power Pages	外部ユーザーへのポータルはPower Pagesが専用製品
「業務担当者が自分でメンテナンスする」	Power Automate / Canvas App（ローコード）	プロコード不要。市民開発者が維持できる仕組みが求められる
「複雑なビジネスロジック・サーバー処理」	Model-Driven App ＋プラグイン	プラグインはサーバーサイドで確実に実行される。Canvasでは不可
「レガシーシステムのGUI操作を自動化」	Power Automate Desktop（RPA）	APIがない画面操作にはRPAが唯一の手段
「Microsoft Teamsユーザー向けの軽量ツール」	Dataverse for Teams ＋ Power Apps for Teams	追加ライセンスなし。Teams内で完結する軽量ユースケース
「大量データのリアルタイム分析・AI」	Power BI ＋ Microsoft Fabric	Fabricはエンタープライズデータ分析基盤。大規模はFabricが適切
「D365をすでに持っており機能を拡張したい」	AppSource ISV → カスタム開発の順で検討	標準機能→AppSource→カスタムの優先順位が試験の基本原則
「オンプレミスのSQLに接続が必要」	オンプレミスデータゲートウェイ	クラウドから社内SQLにアクセスするにはゲートウェイが必須
「複数テナントのデータを1つのアプリで扱う」	マルチテナント Entra ID 設定＋ゲストアクセス	テナント間共有にはEntra IDのゲストユーザーまたはB2B設定が必要

❌ よくある誤答パターン（なぜ間違えるか）

誤った選択	正しい選択	誤答の原因と正しい理解
「UIが複雑 → Canvas App」	要件次第でModel-Driven	UIの自由度だけで選ばない。データモデルの複雑さ・ロジックの種類で選ぶ
「全員に同じアプリを共有」	セキュリティロールで制御	アプリ共有はアクセス許可の一部。データアクセスはセキュリティロールで別途制御
「データ統合 → 全部Power Automate」	大量データはADF or Logic Apps	Power AutomateはAPIベースの統合向き。大量バッチはAzure Data Factoryが適切
「Dataverse for Teams → 本番利用OK」	重要業務には通常のDataverse環境	容量制限・Premiumコネクター不可・外部API不可。軽量用途のみ

🛠 技術スタック

🏗 アーキテクチャ全体図

1. 認証設計：2段階アクセス制御

1-1. Azure ADによる組織限定ログイン

1-2. アクセスコードによる二重ロック

2. Claude APIによる機能一覧自動生成

2-1. APIキーはサーバーサイドのみ

2-2. システムプロンプト：推測・水増し禁止

2-3. DB制約違反への対処：正規化関数

3. Power Automate連携：SharePoint Excel自動生成

3-1. 設計方針

3-2. フロー構成

3-3. アプリ側のコード（export API Route）

4. 環境変数の管理

5. ハマったポイントと対処法

6. セキュリティ設計まとめ

まとめ

クイズゲーム — 直前対策版

① 要件分析とソリューション構想の勘所

1-1. 標準機能で足りないときの判断軸 ── ISVとPoCの使いどころ

SMS送信は標準機能に存在しない

電子サイン（eSignature）はAppSourceから導入する

要件が曖昧な場合はPoCとトライアル環境

ISV選定時はロードマップとライセンスコストの両輪で評価

1-2. ライセンスと権限モデルの境界線

コールセンターエージェントは Portalライセンス不要

ポータルのIDプロバイダーは1つに絞るのが基本

1-3. データ戦略の全体像

製品情報の一次保存場所はDataverseテーブル

Dataverse → データレイク連携は2025年重要更新

金額予測にCustomer Insightsはズレている

チャートの主戦場はD365ダッシュボード vs Power BI

Power PagesとD365ダッシュボードは「OOBで埋め込めない」

1-4. 非機能要件として整理すべきもの

クレジットカード情報の非保存 → 非機能要件（セキュリティ）

役割ベースアクセス制御 → 非機能要件（セキュリティ）

1-5. プロセス改善の選択肢2025年重要更新

② 実装・トラブルシュート・運用監視の勘所

2-1. Power Pagesのコンポーネント設計

空き情報・在庫・予約可能レコードの一覧表示 → List

ポータルから外部APIを呼ぶ → コンポーネント＋Web Template＋Site Settings

429エラー（Too Many Requests）への対策最新パターン

メンテナンスモードはPower Platform管理センターから有効化

2-2. Canvasアプリの実装パターン

CanvasにGoogleマップを出す → Launch + Image

決済処理中のローディング表示 → Context変数＋Visible

起動が遅いときに調べる2つの数字

Canvasアプリの監視ツール3種の使い分け

2-3. 複数アプリを使う場合のライセンス設計2024年以降の名称で整理

2-4. 外部連携トラブル：調査の3点セット

同期がズレる・余計なビジネスロジックが走る

Go-live後にルックアップに値がない・重複・望ましくない更新

ポータル移行後「このメールアドレスは既に使用されています」

2-5. ポータルにサインインできない

2-6. Dataverseコネクタ経由の文書移行

セクション1：ソリューションの構想と要件分析Solution Envisioning & Requirement Analysis

セクション1：ソリューションの構想と要件分析
Solution Envisioning & Requirement Analysis