「個人 PC での開発は不可」で会話が終わるとき、足りないのは熱意ではなく答えだ。
相手が確認したいのは 3 点しかない。その端末は誰の管理下にあるか / 顧客テナントのどこまで入るのか / AI は何に触るのか。
この 3 つに具体的な答えを持てば、依頼の中身が「PC を貸してください（規程の例外承認）」から「設定を 1 つ入れてください（設定変更）」に変わる。

顧客の規程には、外部の個人が AI ツールを使って開発することを記述する欄そのものが無いことが多い。欄が無ければ、正しさとは無関係に通り道が存在しない。この状況がなぜ続くのかは本番データは外に出さない方が安全だ——それでも声が上がらない理由で扱った。ここでは「では何を持てば審査に答えられるか」だけを書く。

前提を 1 つ置いておく。基本線は顧客テナントに触らずに作り切ることで、この記事の装備はその代わりではない。 入館を求められたときと、「触っていない」ことを証明する必要が出たときに要るものだ。

先に、顧客側に発生するコストを書く

この経路は無料の抜け道ではない。顧客側に作業と費用が生まれる。提案の後で判明すると信用を失うので、最初に開示する。

顧客側に発生するもの中身誰が実施するか
クロステナントアクセス設定の変更受信側の信頼設定で「準拠しているデバイスを信頼する」を有効化Entra の Security Administrator 以上
ゲストユーザーのライセンスDataverse にアクセスさせるならゲスト側もライセンス要件を満たす必要がある顧客のライセンス管理者
Dataverse セキュリティロールゲストにロールを割り当てる。既定では何も付かない環境管理者 / システム管理者
環境ごとの設定変更ゲストアクセスの開閉は環境単位。まとめて一括では入らないPower Platform 管理者
監査の見直し外部ユーザーが増えるぶんの証跡確認情報セキュリティ担当

この表を先に出せる状態が、審査を通る前提になる。交渉の相手を、規程の例外承認から設定変更 1 件に移す。

問い①：その端末は誰の管理下にあるか

既存の答えは貸与 PC だ。ID とデバイスと開発環境を一度に片付けるので有効だが、届くまでの待ち時間に報酬は出ない。

別解は 3 段構えになる。

  1. 受託側が自分の Microsoft Entra テナントを持つ（M365 や Power Platform の職場アカウントを自分の名義で確保する）
  2. 個人 PC を自分のテナントの Intune に登録し、デバイス準拠ポリシーを満たす（Intune ＝ 端末の設定と準拠状態を管理する Microsoft のサービス）
  3. 顧客側で、受信側の信頼設定を有効にしてもらう

3 が要になる。Microsoft Entra のクロステナントアクセス設定には、外部ユーザーのホームテナントが出す「この端末は準拠している」というクレームを信頼するかどうかの選択肢がある。公式ドキュメントの記述はこうだ。

“In your cross-tenant access settings, you can choose to trust claims from an external user’s home tenant about whether the user’s device meets their device compliance policies or is Microsoft Entra hybrid joined.” （Cross-tenant access settings for B2B collaboration）

顧客側の操作は、Microsoft Entra 管理センターの 外部 ID > クロステナントアクセス設定 > 組織設定 > 受信アクセス > 信頼設定 で「準拠しているデバイスを信頼する（Trust compliant devices）」にチェックを入れる、というものになる。既定は信頼しないので、必ず明示的な依頼になる。

なぜ 1（自前テナント）が省略できないのか。デバイスはユーザーのホームテナントでしか管理できないためだ。他社の Intune に自分の端末を準拠させることはできない。個人アカウントのままだと、そもそも準拠を主張する発行元が存在しない。

顧客側の条件付きアクセス（利用者・端末・場所などの条件でアクセスの可否を判定する Entra の仕組み）で準拠デバイスを要求する設定についても、公式は適用範囲を限定して書いている。

“Only select the Require device to be marked compliant or Require Microsoft Entra hybrid joined device if everyone outside your organization is using a device that is managed by your organization or by a trusted Microsoft 365 or Microsoft Entra organization.” （How to Require Device Compliance with Conditional Access）

「信頼できる組織が管理している端末」の側に自分を置けるかどうかが、この問いの答えになる。個人という肩書きのままでは箱に入らない。管理主体を持ったサプライヤとしてなら入る。

貸与 PC とどちらを選ぶかは、案件の長さで決まることが多い。

貸与 PC自前テナント + 準拠デバイス
立ち上がり発行・配送・アカウント作成の待ち時間初回のテナント構築と Intune 登録（案件をまたいで再利用できる）
顧客側の作業端末調達・キッティング・回収信頼設定の有効化 1 件
案件終了時返却顧客側の設定を戻す
蓄積先顧客資産自分の環境に残る

短期・単発なら貸与 PC のほうが速い。複数案件を並行するなら、毎回ゼロから交渉するコストが消えるぶん自前側が効いてくる。どちらに時間を貯めるかという観点は顧客テナントに時間を吸わせる構造へ、資産を渡すなで扱っている。

問い②：顧客テナントの中に、どこまで入るのか

端末の管理主体が決まっても、Dataverse（Power Platform が使うデータ基盤）に入れるかは別の話になる。ここは既定が閉じている。

“By default, guest access to Dataverse is restricted for all new environments.” （Control guest access to Microsoft Power Platform environments）

制限されている状態でゲストができないことは、公式が具体的に書いている。Dataverse への接続もクエリもデータ変更も新規コネクション作成もできず、Dataverse を使う Power Apps の実行も、アプリの作成・編集もできない。既存のゲスト所有のコネクションは無効化される（削除はされない）。

開閉は環境単位で、Power Platform 管理センターの Security Hub > Identity and access > Guest access のトグル、または CLI で届く。実体は restrictGuestUserAccess というフラグだ。

# 現在の設定を確認する
pac env list-settings --environment "your-environment-url" --filter "guest"

# ゲストアクセスを許可する（制限を外す）
pac env update-settings --environment "your-environment-url" --name "restrictGuestUserAccess" --value false

同じページで Microsoft 自身が、この使い分けを公式のユースケースとして挙げている。

“Enable controlled collaboration with partners, contractors, or clients by allowing guest access in a development or testing environment but restricting it in production.”

開発・検証環境では開き、本番では閉じる。外部の受託者を入れる前提が公式に書かれているので、提案時にこの一文を示せる。

同じページの Limitations に、見落とすと事故になる但し書きがある。

“Doesn’t override tenant-level guest access policies set in Microsoft Entra ID or through Conditional Access.”

環境の設定を開いても、テナント側の Entra ポリシーや条件付きアクセスは上書きされない。問い①の端末側が揃って初めて、この経路は成立する。ゲスト自身がライセンス要件とセキュリティロールを満たす必要がある点も同じページに明記されている。

ここは断定できない。 ゲスト招待 + 受信側のデバイス信頼 + restrictGuestUserAccess=false の 3 点を同時に満たして Dataverse に到達できるかどうかは、公式記述からそう読めるというところまでで、通し確認は実施していない。実案件で採用する前に、検証環境で 3 点を揃えた状態を一度作って確かめること。越境した後に 401 や 403 で止まる場合の切り分けは同意しても 401 が返る理由と 403 との切り分け方に分けてある。

問い③：AI は何に触るのか

エージェント型のハーネスは、コードベースを読み、シェルコマンドを実行し、MCP（Model Context Protocol：AI から外部ツールやデータ源に接続するための共通規格）経由で外部サービスを呼ぶ。補完だけの支援ツールとは、開示すべき事項の量が違う。

聞かれる前に用意しておく項目は 4 つで足りる。

開示項目書いておく内容
モデル提供者どのベンダーのどのモデルを、どの契約形態で使うか
データ保持の条件送信内容が学習に使われるか、保持期間はどうか
MCP の到達範囲接続を許可しているサーバーの一覧。顧客システムに届く経路があるかどうか
操作の記録エージェントが何を読み、何を実行したかが後から追えるか

この 4 つを 1 枚にして先に渡す。質問票が来てから調べ始めるのと、最初から添付してあるのとでは、審査に乗るまでの時間が変わる。

鍵と組織データを顧客側から出さないための役割分担そのものは鍵もデータも渡さない設計の判断軸で扱った。ここでは装備の申告に話を限る。

まとめ

「個人でも許してください」は審査の様式に乗らない。乗るのは、端末の管理主体・テナント境界の入り方・AI の到達範囲という 3 点に、設定名とコストまで含めて答えられる状態だ。様式が固まる前に答えを持っている側が、質問票が配られたときに先に通る。

次の一歩：自分名義の Entra テナントを 1 つ確保し、手元の PC を Intune に登録して準拠状態になるところまで通す。その後、検証用の Power Platform 環境で pac env list-settings --environment "your-environment-url" --filter "guest" を叩き、既定値が制限側であることを自分の目で確認する。顧客に依頼する前に、自分の側で再現しておく。

関連記事：「環境をもらえないと作れない」は、もう前提ではない——顧客テナントに触らずに作り切るための地図 — 触らずに作る側の全体像