実務ハック

支援先からアカウントをもらって顧客テナントに入ろうとしたら弾かれた——それは壁の1層目しか解けていないからだ。 壁は3層あり、借用アカウントが解くのは「ID認証」という1層目だけ。本丸は2層目のデバイス準拠で、アカウントではなくデバイスの問題だ。 越えるには、支援先の設定変更1本と、自前テナント+Intuneによる個人PC準拠化の2本が必要になる。 壁は3層ある——借用アカウントが解くのは最初の1層だけ支援先から発行してもらうアカウントには2通りある。B2Bコラボレーション招待によるゲストアカウントと、支援先テナントの正規ユーザーとして発行されるメンバー相当のアカウントだ。 どちらを受け取っても、3層の壁はそれぞれ別の鍵が必要になる。 壁 内容 借用アカウントで解けるか ① ID認証 有効なアカウントで認証を通す ✓ 解ける ② デバイス準拠 条件付きアクセスポリシーが「準拠デバイス」を要求 ✗ 解けない ③ 環境設定 テナント側の外部アクセス設定・Dataverse設定 ✗ 解けない（管理者操作が必要） 2層目が本丸だ。多くの企業環境では条件付きアクセスポリシー（Conditional Access Policy：特定条件を満たさないアクセスを自動ブロックする仕組み）が有効になっており、「準拠デバイス（Compliant Device）」でなければ弾かれる。 問題は、デバイスをどのテナントが管理するかにある。準拠デバイスかどうかは、そのデバイスを管理しているテナントが判定する。支援先が貸与したPCなら支援先の基準で準拠になる。しかし個人PCは、あなたが持っているホームテナントでしか管理できない。借用アカウントはこのデバイスの問題を解かない。 Entra ID（旧称 Azure Active Directory：クラウドのID管理サービス）のクロステナントアクセス設定には「Trust compliant devices（外部テナントのデバイス準拠クレームを信頼する）」という設定がある。この設定が閉じている限り、あなたのホームテナントで準拠にした個人PCを支援先テナントは「準拠デバイス」とみなさない。 そしてこの設定は既定でオフだ（MicrosoftDocs/entra-docs, 2025）。支援先管理者が明示的にオンにしない限り、準拠状態のPCを持ち込んでも認識されない。 これは鍵の問題ではなく、錠前の設定の問題だ。 ゲストアカウントでは Power Platform に実質入れない理由「ゲストでいいのでは」という判断が割れるケースがある。だが Power Platform を使う支援業務では、ゲストに固有の壁がさらに重なる。 Microsoft の公式ドキュメントには次の記載がある（Microsoft Learn, 2025）： By default, guest access to Dataverse is restricted for all new environments. 新規のPower Platform環境では、Dataverse（Power Appsのデータ基盤）へのゲストアクセスが既定で遮断されている。設定値は restrictGuestUserAccess = true だ。支援先管理者が Power Platform管理センターのCLIで明示的に false に変更しなければ、ゲストはDataverseに触れない。 ...

先に結論を出す。DataverseのGit統合は開発環境と対象環境の両方をManaged Environmentsとして有効化することが前提であり、Developer PlanにはManaged Environmentsの使用権が含まれていない。 環境前提：Managed Environments必須・Developer Planでは使用権外。 Developer Plan環境でALMを組む実務解は pac solution export → pac solution unpack → 普通のgit。純正のGit統合機能を使わなくても、ALMとして十分足りる。 Git統合に何が要るかMicrosoft Learnの公式ドキュメント（Power Platform ALM Git Integration Overview、2025）に次のように明記されている。 “Development and target environments must be enabled as managed environments.” 開発環境だけでなく、対象環境（本番・テスト）も両方をManaged Environments（マネージド環境：Microsoftが提供する高度な管理・ガバナンス機能付きのPower Platform環境）として有効化する必要がある。 同FAQには「All users within the environment must meet license requirements for managed environments」ともある。環境内のすべてのユーザーがライセンス要件を満たしていなければならない。 Git統合を試みる前に確認すべきことは、この2点だ。 チェック項目 確認すること 開発環境 Managed Environmentsとして有効化されているか 対象環境（本番・テスト） Managed Environmentsとして有効化されているか どちらか1つでも欠けていれば、Git統合は動かない。機能評価より前に、この前提を確認する。 Developer Planでは実質使えないManaged Environmentsのライセンス要件について、公式ドキュメント（Managed Environment Licensing、2025）は次のように明記している。 “A managed environment isn’t included as an entitlement in the Developer Plan when users run their assets.” ...

pac CLI の導入方式は3つある。どれを選ぶかは後で使うランナー OS と直結していて、好みで決めると後から変えにくい。 dotnet tool を選べば Windows でも Linux でも macOS でも同じコマンドが動く。それが Ubuntu ランナーを選べる前提になる。 Ubuntu ランナーで CI を回せば Windows より分数消費が半分になる——この順番で決めておくと、後で迷わない。 3方式の選び分けと根拠Microsoft Learn 公式が示す3方式は以下のとおり。 方式 手段 主な用途 dotnet tool dotnet tool install --global Microsoft.PowerApps.CLI.Tool 個人 PC 開発 + CI（クロスプラットフォーム） Windows MSI GUI インストーラー Windows 端末・認証プロファイルの GUI 確認 VS Code 拡張 Power Platform Tools 拡張 エディタ統合 3方式は併用可能。開発機に Windows MSI を入れながら、CI ランナー（Linux）では dotnet tool を使う構成も成立する。 個人 PC 開発と CI を両方回すなら dotnet tool が軸になる。理由はクロスプラットフォームの一点で、Ubuntu ランナーを選べる状態を作るには Linux でも動くインストール手順が前提になる。 ...

CIサーバが使えない環境でも、納品前検品を捨てる理由はない。 pac solution check（Power Platform CLIが提供する静的解析コマンド）はローカルマシンから直接Microsoftのチェッカーサービスに接続して実行できる。CIサーバは要件に含まれていない。 4検査を1本のスクリプトに集約し、全部通ってからzipを渡す——この設計をチェックリストの第1項目に置けば、走らせ忘れを構造的に防げる。 4検査の選択基準：最小十分条件を決める顧客資産をクラウドに置けない・またはCIを組む余裕がない個人受託環境で、検品に組み込めるツールの組み合わせは自ずと絞られる。実務で機能してきた組み合わせがこの4つだ。 検査 目的 pac solution check Microsoftの静的解析ルールセットによる構造検証 命名規約lint エンティティ・フロー名の別名化ルール一貫性チェック スクラブ検査 実値混入・0行CSV検出（顧客データの誤り込みを防ぐ） Playwright E2E Canvas App / モデル駆動アプリの最低動作確認 命名規約lint・スクラブ検査・Playwright E2Eの「それで十分か」を示す公的データはない。これは実務経験ベースの組み合わせであり、プロジェクトの規模や契約要件によって調整が必要になる。 pac solution check を実行する前に確認する3点pac solution checkを使うにはいくつかの前提がある。「顧客資産をクラウドに置かない」方針を取っている場合は、特に3点目を読んでほしい。 1. インターネット接続が必要 pac solution checkはPower Apps Checker Cloud APIにアクセスして静的解析を行う設計になっている。完全オフライン環境では実行できない。 （出典：Microsoft Learn「pac solution - Power Platform CLI reference」2026-02-25 https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/solution） 2. 認証プロファイルが必要 実行前にpac auth createで認証プロファイルを作成する必要がある。作成済みであれば--environmentパラメータは省略可能だ。コマンド例： pac solution check --path c:\solutions\MySolution.zip --outputDirectory c:\results --geo UnitedStates 3. 解析対象ZIPがMicrosoftサービスに一時送信される 「顧客資産を外部クラウドに置かない」方針と緊張する点がここだ。pac solution checkは解析のためにZIPをCheckerサービスにアップロードする。「保存」ではなく「解析のための一時送信」だが、Microsoftが保存しないことを明示した公式保証文書は今回のリサーチでは確認できていない。顧客のNDAや契約上の機密レベルによっては利用不可のケースもあり得る。送信が発生するという事実を理解した上で、利用可否を判断してほしい。 Solution Checkerの頻出違反3パターンデフォルトルールセット名は「Solution Checker」で、2024年以降20以上のルールが追加されており動的に更新される設計だ。Critical重大度の違反はManaged Environments設定時にインポートがブロックされる。 （出典：Microsoft Learn「managed-environment-solution-checker」2025 https://learn.microsoft.com/en-us/power-platform/admin/managed-environment-solution-checker） ...

Power Apps Developer Plan で作った環境は、30 日間何も操作しないと自動的に無効化される。無効化後 15 日が過ぎれば削除され、削除後 7 日以内なら Power Platform Admin Center（PPAC）から復旧できるが、それも過ぎると完全に消える。合計 52 日——これが「触らないまま忘れた環境」の末路だ。 個人 PC 側に検証テナントを持って開発を進めているなら、案件の繁忙期が続いたあと久しぶりに環境を開いたとき、何も残っていない——という事態は十分ありうる。月 1 回の操作規律と、無料枠の天井・有償移行の判断軸をここで整理する。 なぜ環境が消えるのか——30 日タイムラインの構造タイムラインは 3 ステップで進む。 ステップ 内容 30 日無活動 環境が自動的に無効化される 無効化後 15 日 再有効化されなければ削除される 削除後 7 日以内 PPAC（Power Platform Admin Center）から復旧可能 無効化・削除の前には環境オーナーへメール通知が届く。通知に気づいて再有効化すればカウントはリセットされる。ただし削除後 7 日を過ぎると復旧手段はない。 一点注意がある。2026 年 4 月以降に作成された管理対象 Developer 環境の場合は閾値が 60 日に延長されている。個人開発者が単独で取得する通常の Developer Plan 環境は 30 日が基準だ。 出典：Microsoft Learn – Power Platform automatic-environment-cleanup（2026 年確認済） https://learn.microsoft.com/en-us/power-platform/admin/automatic-environment-cleanup 「活動あり」に数えられる操作・数えられない操作ここが誤解を生みやすいポイントだ。画面を開いたりサインインしたりするだけでは、活動記録として扱われない。 活動とみなされる操作（CRUD 操作が基本単位） アプリの起動 フローの実行（自動・手動） アプリ・フロー・ボットの作成・更新・削除 環境のコピー・バックアップ・復元・リセット 活動とみなされない操作（重要） ...

managed だけで納品を終わらせると、顧客環境にはソースを復元できない状態が残る。 正本は受託者側にあり続け、案件が完了しても保守依頼が続くか、受託者が環境を消せば顧客が困るかの二択になる。 unmanaged を顧客の DEV 環境に渡す設計に変えると、正本は顧客側へ移り、受託者は案件を何も抱えずに終わらせられる。 managed だけで納品すると何が起きるかmanaged ソリューション（管理済みソリューション）は、Power Platform 上でアプリやフローをパッケージ化して配布する形式だ。顧客環境にインストールできるが、インストールされた状態からソースを取り出すことはできない。 Microsoft Learn の公式ドキュメントには明示されている。 “You can’t export a managed solution.” — Export solutions | Microsoft Learn 顧客が managed を受け取っても、そこからソースを復元する手段はない。受託者のテナントにある unmanaged（非管理済み）ソリューションが唯一の正本として残り続ける。 これは「managed-only で納品する」という選択が、意図するかどうかに関わらず生み出す構造だ。 正本が受託者側に残り続けると起きること正本が手元にある状態では、案件が終わっても受託者はそのソリューションを保持し続けることになる。顧客が機能追加や障害対応を必要とするたびに、受託者に連絡が来る。消したければ顧客が困る。持ち続ければ自分が抱える。 この構造を事後に解消するには、unmanaged から managed の ALM（Application Lifecycle Management：アプリのライフサイクル管理）への正規化作業が必要になる。Microsoft が FastTrack 専門チームの解説ビデオを用意するほどの移行コストが存在しており、後から解決できるとは言いにくい。 参考：Move from unmanaged to managed ALM | Microsoft Learn 正本の移転は後回しにするほど重くなる。 unmanaged 納品フロー：どこに入れるか解決策は一つだ。unmanaged ソリューションを顧客の DEV（開発）環境に渡す。 フローはこうなる。 受託者 DEV → unmanaged エクスポート ↓ 顧客 DEV → unmanaged インポート（ここで正本が顧客側へ移る） ↓ 顧客が単体テスト ↓ 顧客 DEV から managed エクスポート ↓ ステージング → UAT → 本番（本番には managed のみ） 「unmanaged を顧客に渡す」と「unmanaged を本番に入れる」は別の判断だ。顧客 DEV に unmanaged が入ることで正本が移転し、その後のステージング以降は managed だけが動く。 ...

managed ソリューションで納品した後、特定のコンポーネントだけ更新が当たらない——この状況で最初に疑うべきはコードではなくソリューションレイヤーだ。 新版をインポートしても変わらない。「カスタマイズを上書き」オプションを選んでも変わらない。その原因の多くは非管理レイヤー（unmanaged layer）が managed レイヤーの上に乗っていることにある。メンテの第一手はレイヤーを確認することから始まる。 更新が反映されない理由：非管理レイヤーが上に乗っているからPower Platform のソリューションには「レイヤー」という構造がある。managed（管理済み）と unmanaged（非管理）の変更が重なるとき、どちらが実行時の動作を決めるかを示す順番だ。managed solution とは編集できない状態でパッケージ化されたソリューションで、本番配布を前提に作られる。 顧客が本番の Maker ポータルでコンポーネントを直接編集すると、その変更は非管理レイヤーとして managed レイヤーの上に積み重なる。 Microsoft のドキュメント（「Solution layers in Power Platform」2024年）はこう明示している： “Unmanaged customizations reside at the top layer for a component and subsequently define the runtime behavior of the component.” 非管理レイヤーは常にトップ——つまり、常に優先される。新しい managed ソリューションを何度インポートしても、非管理レイヤーが存在するコンポーネントにはその更新が届かない。 なお、model-driven app・フォーム・サイトマップはこの原則の例外で「マージ」動作（双方の変更を統合する）になる。それ以外のコンポーネントは「上のレイヤーが全体を決める」ため、非管理レイヤーが存在する限り managed 側の変更は実行時の動作に影響しない。 どこで確認するか：ソリューションレイヤービューを開く確認は Maker ポータルから直接できる。 対象ソリューションを開く 更新が当たっていないコンポーネントのオプションメニューを開く 「ソリューションレイヤーを表示」を選択 ここで非管理レイヤーがリストの上部に表示されていれば、それが原因だ。 XrmToolBox のような補助ツールでレイヤーを探索することもできる可能性があるが、ツールによって検出できないコンポーネント種別がある場合もある。Maker 画面での直接確認が最も確実な手段だ。 見つかったら何をするか：削除は不可逆、顧客 GO が必須非管理レイヤーが確認できたら、次の順で対処する。 ステップ 1：顧客の変更を自分の正本（管理ソリューション）に取り込む 非管理レイヤーを削除すると、そこに加えられた変更は消える。削除前に、顧客が加えた変更が正式な仕様として必要かどうかを確認し、必要であれば自分の管理ソリューションに反映しておく。これは公式手順には明示されていない工程だが、後から「消えた」とならないための前処理として位置づける。 ステップ 2：顧客に Remove active customizations（アクティブなカスタマイズを削除）を依頼する ...

Power Apps Test Engine のリポジトリは 2026 年 11 月 1 日に削除される。いま YAML テストを積み上げると来年丸ごと作り直しになる。移行先は Power Platform Playwright samples（TypeScript + 標準 Playwright ランナー）で、Canvas / Model-Driven を含む 4 種別に対応済み。 何がいつ消えるのかMicrosoft は 2026 年 4 月に Power Apps Test Engine を正式に非推奨とし、GitHub リポジトリを 2026 年 11 月 1 日に削除すると明記している（2026 年 9 月 6 日時点で延期確認なし）。 “Test Engine is deprecated and this repository will be removed on November 1, 2026.” — github.com/microsoft/PowerApps-TestEngine 公式の非推奨通知は learn.microsoft.com — Power Platform の重要な変更点 に掲載されている。理由は使用率の低さと、Power Fx 依存が AI 連携の制約になっていた点。削除日は変更される可能性があるため、実際に移行作業を開始する前に GitHub ページで最新情報を確認する。 ...

Power Apps Developer Plan に登録しようとして、Gmail や Outlook.com で試みると弾かれる。ツールの不具合でも設定ミスでもない。登録条件が構造的に個人メールを排除しているためだ。 先に結論を示す。Power Apps Developer Plan の登録には Microsoft Entra ID（旧 Azure Active Directory：Microsoft が提供する企業・学校向けの ID 管理サービス）に紐づいた職場/学校アカウントが必須で、これは個人アカウントでは満たせない。ツール選定より先に、Entra テナントの確保が来る。 なぜ Gmail では登録できないのかMicrosoft 公式ドキュメント（learn.microsoft.com/ja-jp/power-platform/developer/plan、2026年確認）には次のように明記されている。 “Anyone with a work or school email address backed by Microsoft Entra ID can sign up” “You currently can’t sign up with a personal account” Power Apps Developer Plan が要求しているのは Entra ID テナントに紐づくアカウントだ。Gmail・Outlook.com・Hotmail などの個人メールは Entra ID の管理外にあるため、どう試みても登録できない。 個人PC で Power Platform 開発を始めようとした場合、ツール一覧を調べる前にこの構造を理解しておく必要がある。Entra テナントを先に手に入れてから、Developer Plan に進む——この順序が変わることはない。 ...

Dataverse MCPプラグインの導入は1コマンドで完了する。Claude Codeで /plugin install dataverse@claude-plugins-official を実行すれば、Python3・PAC CLI・.NET SDK・Azure CLI・Node.js・Dataverse CLI・Gitの一式が自動で揃う。 難しいのはその先だ。接続を成立させるには、テナント全体の管理者同意（G1）と環境ごとの許可リスト登録（G2）という2段のゲートが待つ。どちらも迂回できない。そしてG2にはManaged Environmentが必須条件であり、Developer Plan環境ではデフォルトで設定画面が現れない可能性がある。 この記事では「どのテナントでMCPが通るか」の判断軸を整理する。対象読者は、Claude CodeやCursorからDataverseを操作しようとしている個人開発者・受託開発者。前提：Power Platformの環境概念（Dataverseテナント・環境・Managed Environment）について基礎知識があること。 2段ゲートの全体像：先に地図を見ておくMCP接続が成立するまでの構造はこうなっている。 [Claude Code] ↓ プラグイン導入 (/plugin install 1コマンド) [G1: テナント全体の管理者同意] ↓ グローバル管理者 or 特権ロール管理者が承認 [G2: 環境ごとの許可リスト登録] ↓ Managed Environment が有効な環境のみ設定可能 [Dataverse MCP Server] ↓ [Dataverseデータ操作（読み取り・書き込み・削除系）] G1→G2の順に通過が必要で、G1を通過していてもG2が設定されていなければMCPは機能しない。2段とも「自分が管理者でないと動かせない」仕組みになっている。 G1：テナント全体の管理者同意承認者：Azure ADのグローバル管理者、または特権ロール管理者。 プラグインはテナントIDとクライアントID入りの同意URLを自動生成して案内する。承認操作そのものはプラグインでは代行できない。一次ソース：Dataverse Plugin Is Now on the Claude Marketplace（Microsoft Power Platform Blog） 顧客テナントでは、G1の時点で顧客側のグローバル管理者の承認が必要になる。管理者を説得できなければMCP接続は始まらない。 G2：環境ごとの許可リスト登録G1通過後、使いたい環境ごとに許可リストへの追加が必要だ。 操作パス：Power Platform管理センター → 管理 → 環境 → （対象環境名）→ 設定 → 製品 → 機能 →「Dataverse MCP Server」セクション →「Allow MCP clients to interact with Dataverse MCP server」をオン。 ...