Posts

「基幹に持たせよう」という一言は善意で出る。ただし、判断基準が利用者数でも設計の美しさでもないとすれば、何なのか。 答えは一点だけだ。「他システムがそのデータを取り込んで書き足す共有物に育ったかどうか」——これがSoR（System of Record：組織のデータ管理における権威的ソース）への昇格の唯一の引き金だ。この一軸で判断できれば、会議での問いに根拠を持って返せる。 受益者の有無が唯一の判断軸SoRという概念の産業界定義は、Geoffrey MooreとAIIMが2011年に策定した白書が原典だ。「組織の重要マスターデータを管理するトランザクション処理の権威的ソース」——核心条件は、他システムがそのデータを取り込んで書き足す「共有物になっているかどうか」だ。 利用者数・設計の美しさ・担当者の熱意は、この定義に入らない。「月1,000人が参照する」と「他システムから書き込まれる」は別の概念だ。前者はアクセス頻度、後者はデータ所有権の問題だ。 Microsoftの公式参照アーキテクチャ「Synchronize data across Dataverse environments」（2024年）も「一方をプライマリ（権威的ソース）と定め、他はセカンダリ（コピー）として設計する」と明示している。SoRを定めることは自然に決まるものではなく、明示的な意思決定だ。 データ設計の判断とは、受益者を先に確認する作業だ。 2つの取り違えを潰す会議でよく起きる取り違えは2つある。 利用者が多い ＝ 共有物 「多くの部門が参照している」は昇格の引き金でない。読み取り専用の利用がいくら増えても、他システムからの書き込みが発生しなければSoRの条件を満たさない。 コピーを基幹に流す ＝ 正本が基幹に移った 「基幹DBにデータをコピーして同期している」と「基幹が正本（SoR）になった」は別の意思決定だ。どちらが権威的ソースかを明示的に決めなければ、障害時・更新競合時に「どちらが正しいか」の判断がつかなくなる。 Microsoft公式ドキュメント「Data ownership models for synchronization」（2024年、DataverseとBusiness Centralの統合設計）はこう規定している——「どちらかをSoR（正本）と定め、他はコピーとして扱う」。写しがいくら出回っても、正本は動いていない。 昇格に付く4つの恒久コスト昇格を選んだ瞬間から、以下4つのコストが恒久的に積み上がる。 コスト 内容 同期コスト 2システム間のデータを常に一致させるための配管メンテナンス 維持コスト スキーマ変更・バージョンアップのたびに統合コードを更新する工数 責任分界 障害時・更新競合時に「どちらが正しいか」の所管整理（担当部門間の調整） 部門間調整 マスタ変更・スキーマ変更の影響範囲を関係部門と合意し続けるコスト IPAが示す業界慣行では、システム保守費用は初期開発費の15〜20%が目安だ。Fivetranの調査（参考値・商業調査機関）によれば、エンジニア時間の53%がデータパイプライン・統合のメンテナンスに費やされるという。Ampersandの調査（参考値・商業調査機関）では、統合1件あたりの年間保守コストは構築コストの2倍以上に達するとされている。 昇格した日から始まる構造的なコストだ。 受益者がいなければ、コストだけが積み上がる他システムが書き足す受益者がいない状態で昇格すると、便益はゼロのままこれらのコストが恒久的に積み上がる。 経産省のDXレポート（2018年）は「既存システムの集約が必ずしもサイロ化を解消するわけではなく、新たな統合コストを生む」と指摘している。「あった方がいい」という根拠だけで昇格する場合、この指摘は直接当てはまる。 受益者の有無という一軸で判断できれば、「昇格しておけば将来使えるかもしれない」という根拠のない期待を機械的に排除できる。 データ種別で答えが変わるSoR定義（Geoffrey Moore/AIIM 2011）から整理すると、判断が異なるデータ種別が2つある。この判断フレームが主な対象とするのはフロント入力データ（ユーザー入力・業務記録・申請フォームへの回答等）だ。 参照データ（コード表・マスタ等）は、通常すでにSoRが存在している。問いは「どこのSoRから取るか」になる。フロント入力データは「そもそも昇格すべきか」から判断が必要だ。 Microsoftも「バーチャルテーブル（参照のみ）とデータ同期（コピーを持つ）の選択肢」を公式に並べており、どちらが適切かは状況に依存すると示している。この種別の区別を持っておくと、「なぜ基幹に集約しないのか」という問いに対して、まずデータ種別から答えを絞り込める。 → M365 Developer Tenant でのローカル検証環境構築：顧客テナントに時間を吸わせる構造へ、資産を渡すな まとめフロント入力データをSoRに昇格させるかどうかは、他システムが書き足す受益者がいるかどうかだけで決まる。受益者がいなければ、昇格は4つの恒久コストを無償で積む選択だ。 次の一歩：会議で「基幹に持たせよう」と言われたら、まず「そのデータを書き足す他システムが今あるか、3ヶ月以内に現れるか」を確認する。Yesなら昇格を検討する。Noならコピー運用の設計を選ぶ。ただしコピー運用には写しのライフサイクル管理と参照タイムラグの許容範囲の合意が別途必要になる。 関連記事 認可の恒久資産——アプリが消えても残す設計の選択（「アプリが消えても残すか」という引き金の考え方が共通） 取込時の正規化と代替キーLookup——昇格しないと決めたあとの設計 Power Automateで写しを安全に運ぶ疎結合設計

サーバーレス DB は「停止中コストゼロ」が前提だが、監視クエリや接続プールが DB を起こし続けると provisioned（常時起動）より高くつく。課金の主役は保存容量ではなく**起きている時間（計算 vCore）**であり、稼働率が上がるにつれてコストが逆転する構造を持つ。Azure SQL Serverless と Amazon Aurora Serverless v2 の課金構造、稼働率 48% のクロスオーバー試算、keep-alive の正体と監査手順を整理する。 課金の主役は「起きている時間」Azure SQL Database Serverless の課金は vCore 秒（per-second billing）単位で動く。DB が起きている間は vCore単価 × 使用vCore数 が積み上がり、停止中は計算コストがゼロになる。ストレージは起動・停止にかかわらず消費分だけ課金が続くが、実際の PoC 請求を分解すると計算 vCore が約 8 割、ストレージが約 1 割だった。節約効果の大半は「起きている時間を削る」ことで生まれる。 Amazon Aurora Serverless v2 も同じ構造で、$0.12/ACU-hour 課金・停止中は計算コストゼロ。2024 年 11 月からは最小 ACU を 0 に設定できるゼロスケール対応になり、完全停止によるコストゼロが可能になった。 Azure Cosmos DB は別モデル。 消費した RU（Request Unit: データ操作の処理量の単位）の実量に対して課金される（$0.25 / 100 万 RU）ため、接続がなければ RU 消費ゼロ = 請求ゼロとなる。自動一時停止の設定自体が不要で、以降で説明する keep-alive（DB を起こし続ける動作）の問題は Cosmos DB には直接当てはまらない。主軸は Azure SQL Serverless と Aurora Serverless v2 の話になる。 ...

フローが「オン」でも、Dataverse 側の webhook 購読が登録できていなければ、イベントは永久に届かない。実行履歴が空でエラーも出ない場合、ロジックより先に「購読レコードが実在するか」を確かめる。とくにサービスプリンシパル（機械 ID）接続では、業務権限と購読登録権限は独立した別レイヤーにあり、権限不足で静かに失敗する。 「オン」は「購読が開通した」を意味しないDataverse の「行が追加されたとき」などのイベントトリガーは、フローを有効化した時点で Dataverse 側に購読（webhook）を登録しにいく。内部的には ServiceEndpoint テーブル（エンドポイント本体・contract = 8 が webhook を示す）と SdkMessageProcessingStep テーブル（どのテーブル・イベント・ステージで発火するかの設定）の 2 テーブルにレコードが立つ。この登録が成功してはじめて、回線が開通した状態になる。 フローの「オン」表示は、購読の登録成否とは独立して維持される。権限不足で登録が失敗してもステータスは ON のまま残り、エラーメッセージはユーザーに提示されない。Microsoft 公式ドキュメントには次の一文がある。 “Missing permissions or an invalid connection can silently cause triggers to not fire.” （権限不足または無効な接続により、トリガーは静かに発火しない） 結果として、フローは ON のまま実行履歴は空のまま残る。健康診断ツールが「◯日間、一度も実行されていません」と表示するだけで、ログもエラーも出ない。 「フローがオン」と「購読が開通した」は、独立した別の事実だ。 サービスプリンシパル接続で静かに失敗する理由Dataverse コネクタはサービスプリンシパル接続を公式にサポートしている。ただし、この構成では権限の二層構造に注意が必要だ。 サービスプリンシパルを Dataverse 接続として使う場合、Entra ID にアプリ登録を作成し、Dataverse 環境に Application User（Dataverse 側の機械 ID）として追加したうえで、セキュリティロールを割り当てる。このロールに 2 つのレイヤーがある。 レイヤー 内容 典型的なロール 業務データ層 対象テーブルへの読み書き（CRUD） カスタムセキュリティロール プラットフォーム層 購読登録（ServiceEndpoint / SdkMessageProcessingStep の作成） System Customizer / System Administrator 業務データ層の権限だけを付与した Application User は、テーブルへのアクセスはできる。しかし購読の登録は失敗する。この 2 レイヤーは独立しているため、業務ロジックが動作する別の接続で確認済みであっても、機械 ID での購読登録成功を意味しない。 ...

「承認したのに、いつの間にか本番にデプロイされていた」——Power Platform の委任デプロイ（Delegated Deployment）を初めて設定した担当者に、この疑問はよく生まれる。管理画面に承認ボタンがなく、どこで実行が走ったのか見えにくい。 結論から言う。承認者に本番環境への書き込み権限は要らない。承認者の役割は「実行してよい」という信号を送ることだけであり、実際の書き込みはサービスプリンシパル（機械 ID）が担う。この構造を把握すると、GUI の見え方と権限設計の両方が整合して見えてくる。 なお、2026 年 2 月より Managed Environments がパイプラインの対象環境に自動有効化されている（Microsoft Learn「Overview of pipelines in Power Platform」2026-01-12）。既存テナントで意図せず委任デプロイが必要になるケースが増えている。 承認は「実行の引き金」であって記録ではない筆者の整理として提示する。Power Platform Pipelines の委任デプロイは、凍結された状態機械 として動作する。 maker がデプロイを要求すると、パイプラインのステージは「承認待ち（Pending）」で止まる。そこから先に進む唯一の手段が、UpdateApprovalStatus（status: 20 = 承認）の呼び出しだ。これが凍結を解除し、パイプラインを再始動させる制御信号になる。 承認を「台帳に承認印を押す記録行為」として捉えると、権限設計がずれる。委任デプロイで承認が果たすのは、凍結した状態を次のステップに進ませる制御信号としての役割だ。この捉え方が、以降の設計読み解きの出発点になる。 判断する人間と実行する機械 ID を別主体に割り当てるPower Platform の公式ブログ（2023 年 10 月）は委任デプロイの設計をこう説明している。 “developers of any skill level can request deployments without needing elevated (or any) permissions in target environments.” 開発者（要求者）は本番環境への権限を持たなくていい。本番に書き込むのはサービスプリンシパルだ。 役割 主体 本番環境への書き込み権限 デプロイを要求する maker（開発者） 不要 「可」の信号を送る 承認者（人間） 不要 本番に書き込む サービスプリンシパル 必要（System Administrator） 承認者が Power Automate の承認タスク（メール / Teams 通知）をクリックすると、フローの内部でサービスプリンシパルの Dataverse 接続を通じて UpdateApprovalStatus が呼び出される。承認者は本番環境を開かずに承認を完了できる。 ...

同じロジックでも、接続の方式が違うだけで片方だけ止まる。退職者が出た、パスワードが期限切れになった、MFA（多要素認証）設定を変えた——そのたびにフローが落ちる設計と、まったく連動しない設計が、同じ組織の中に並走している。 認証方式を「どれが楽か」で選んだ結果が、運用負債として戻ってくるパターンは一定だ。判断軸を「耐久性」に置き換えるだけで、同じフローの壊れ方の構造が変わる。 認証設計は「依存設計」の別名認証方式の選択は、実質「何に依存するかの選択」だ。 人（委任トークン）に依存するフローは、その人の人事状態に連動する。退職・異動・MFA 変更・ライセンス変更が起きれば止まる 秘密（API キー・共有シークレット）に依存するフローは、その秘密の有効性に連動する。漏洩・期限切れ・ローテーションのたびに更新が要る プラットフォームが管理する身元（Managed Identity：マネージド ID）に依存するフローは、人事情報にも秘密の有効性にも連動しない この 3 段階を、ここでは「耐久性はしご」と呼ぶ（筆者による整理）。はしごを登るほど、人為的な作業に起因する失効トリガーが減る。 方式 依存先 代表的な失効トリガー 委任トークン（ユーザー接続） 特定の人間のアカウント 退職・MFA 変更・ライセンス変更・長期不使用 API キー / 共有シークレット 秘密情報の有効性 漏洩・期限切れ・ローテーション未更新 Managed Identity プラットフォーム管理の身元 リソースの作り直し（principalId 変更のみ） 認証設計とは、依存設計の別名だ。何に依存するかが、同じフローの壊れやすさを決める。 判断が割れるケース——登れない基盤があるManaged Identity が常に選べるわけではない。 Microsoft 公式ドキュメント（「Support for service principal owned flows」2025）によると、Power Automate Cloud Flow のサードパーティコネクタは Managed Identity に非対応であり、SharePoint / Outlook / Teams コネクタは委任ユーザーコンテキストが設計上必須となっている。Power Platform の Managed Identity は 2026 年時点では Dataverse プラグイン（Dataverse はローコードアプリのデータ基盤）に限定されており、カスタムコネクタへの対応はプレビュー段階だ。 実行基盤 Managed Identity 補足 Power Automate（標準コネクタ） 不可 ユーザー委任接続が必須（Microsoft 公式） Power Automate（カスタムコネクタ） プレビュー段階（2026） 一般提供前 Dataverse プラグイン 対応（GA） Microsoft 公式 Azure Functions / App Service 対応 Microsoft 公式 Logic Apps Standard 対応 HTTP アクション含む 委任が「やむを得ない選択」になる基盤では、はしごを登る以前に別の対策が要る。サービスアカウント専用ユーザーの管理と接続オーナーの引き継ぎ手順の明文化が次善の設計になる。 ...

アプリごとに権限を作り込む設計は、アプリが廃止・移行された瞬間に価値を失う。組織改編のたびにアクセス権を全件触り直すのは、うっかりではなく構造の問題だ。 結論を先に置く。セキュリティ境界は環境（Environment）であってアプリではない。グループを「組織の写し」と「使ってよい人の束」の 2 家系に分離すれば、アプリが増減しても土台は揺らがない。 前提の明記：本記事が扱う「環境」は Power Platform の Environment を指す。Dataverse を持つ環境が前提であり、SharePoint リスト単体や Teams タブアプリのみの構成では環境設計の条件が異なる。 境界はアプリではなく環境Microsoft の公式ドキュメント「Security in Microsoft Dataverse」（2026 年）には次の一文がある。 “Environments act as security boundaries allowing different security needs to be implemented in each environment.” 環境がセキュリティ境界として機能するという明示的な表明だ。さらに「Power Platform environments overview」（2026 年）はアプリとデータの関係を次のように規定する。 “When you create an app in an environment, that app is only permitted to connect to the data sources that are also deployed in that same environment.” アプリが参照できるデータは同じ環境内に限られる。ただし、アプリの UI を通らなくても API（コネクタ・Dataverse Web API 等）経由でアクセスできる。アプリを壁として扱うと、API という窓から入られる。 ...

生成 AI は同じプロンプトで毎回異なる回答を返す。「入力 X を渡したら出力 Y が返るか」という決定論的テストは、そのままでは機能しない。 BLEU（n-gram 一致率で精度を測る代表的な指標）を日本語生成タスクに当てると、意味的に正しい回答がゼロ点近くになる現象が起きる。 固定データセット＋複数の評価器で順位を比較する——この基本形を押さえてから「精度◯%」の数字を語る。 非決定的な AI の評価ハーネスの基本形生成 AI を評価するとき、最初に用意するのは「固定評価データセット」だ。本番または想定ユースケースから代表的な問いを 50〜100 件選んでファイルに保存する。モデルバージョンやプロンプトが変わるたびにこの問題群を使い回し、変更前後の出力を比較する。 採点には LLM-as-judge（採点専用の別モデルを審査員として使う方式）を組み合わせる。Zheng et al. 2023（NeurIPS）は MT-Bench という固定評価セットと LLM-as-judge を組み合わせた評価枠組みを確立した。GPT-4 クラスの審査員モデルは人間評価との一致率 80% 超を達成しており、人間同士の一致率（MT-Bench: 63%、AlpacaFarm: 66%）と同等水準だ（https://arxiv.org/abs/2306.05685）。 日本語の生成タスク（対話・要約・指示追従）については、JGLUE（Yahoo Japan）・llm-jp-eval が BLEU/ROUGE ではなく LLM-as-judge または人間評価を推奨する公式設計方針を採っている（https://github.com/yahoojapan/JGLUE）。 BLEU/ROUGE が日本語生成でほぼ機能しない理由BLEU と ROUGE は、生成文と参照文の n-gram（単語・文字の連続パターン）が字句一致するかを見る。言い換えに根本的に弱い。 SAGE Benchmark 2025（arXiv 2509.21310）は、パラフレーズのケース（意味は同じだが表現が異なる回答）で 60% 超の意味的等価性を BLEU/ROUGE が見逃すことを実証している。ACL 2023 starsem 研究では、人間が生成した意味的に正しいパラフレーズの BLEU スコアが 17.1 という実測値が報告されており、正解回答がゼロ点近くになる現象の一次エビデンスとなっている（https://aclanthology.org/2023.starsem-1.29.pdf）。 日本語固有の問題もある。スペース区切りを前提に設計された BLEU は、形態素解析器（MeCab / SentencePiece / Sudachi 等）の選択でスコアが大きく変動する。同じ正解文でも分かち書きの粒度次第でスコアが動く——これは日本語 NLP 実務では既知の問題だ。 ただし、機械翻訳では BLEU が人間評価と 0.78〜0.91 の相関を示す領域がある（ExPerT ACL 2025 Findings・BERTScore と BLEU の比較研究）。BLEU/ROUGE の限界は「対話・要約・指示追従などの生成タスク」への適用に集中しており、機械翻訳の全否定ではない。生成タスクに使うときに代替指標が必要という話だ。 ...

「とりあえず API キー」で AI サービスへの接続を仮組みした場合、セキュリティレビューで方針からやり直しになるケースがある。 認証方式は「呼ぶ側」だけでなく「呼ばれる側（AI 基盤）」も決める——この二面の構造を把握すれば、鍵を発行しない接続（Keyless）を設計の起点にできる。 ただし実行基盤によって Keyless の通じやすさは違う。環境前提を先に言うと：Power Automate の標準 Azure OpenAI コネクタは 2026 年 7 月時点で API キー必須のままだ（Microsoft Learn）。 判断軸の核心——認証は「二面契約」AI サービスへの接続認証は、「呼ぶ側（コード・ワークフロー・ローコードツール）」が一方的に決めるものではない。「呼ばれる側（AI 基盤）」も、許可する認証方式を設定し、強制する権限を持っている。 呼ばれる側（AI 基盤）が担う： どの認証方式を受け付けるか（Managed Identity / API キー / 証明書など） API キー認証を丸ごと無効化する設定（Azure OpenAI では「Disable API key access」が設定可能） ネットワーク境界（VNet 統合・プライベートエンドポイント） 呼ぶ側（実行基盤）が担う： 身元の持ち方（Managed Identity：クラウドリソース自体に割り当てるサービス身元 / サービスプリンシパル / API キー） その身元を実行基盤がネイティブに扱えるか 認証設計とは、この二面の契約を事前に合わせる工程だ。合わせずに接続すると「基盤側はキー禁止だが呼ぶ側はキーしか使えない」という詰まりが発生する。 実行基盤別 Keyless 適合度——どこで差が出るか2026 年 7 月時点での主要ツール別の認証方式（一次情報：Microsoft Learn 各ドキュメントより）： ツール ネイティブ認証方式 Keyless 可否 Power Automate（Azure OpenAI managed connector） API キー必須 ✗ Power Automate（カスタムコネクタ） API キー または Managed Identity ○（2026-03 GA・自作要） Logic Apps Standard（built-in コネクタ） Managed Identity ✓ Logic Apps Consumption（managed connector） API キー ✗ Copilot Studio Federated credentials（自動） ✓ AI Builder Platform managed（設定不要） N/A Logic Apps Standard + built-in コネクタが現時点で最も素直な Keyless 経路だ。Azure OpenAI と Azure AI Search の両方を Managed Identity で接続できる（出典）。 ...

Microsoft Foundry を「エージェント製品」「ワークフロー製品」「API を叩くもの」のどれかに決めようとするから、整理がつかなくなる。 実体は積み上げ構造だ——モデルの層の上にエージェントの層が乗り、その上にワークフローの層が乗る。 「今どの層を触っているか」で問い直すと、混乱は消える。この記事はその3層の地図を渡す。 混乱の正体——AI 基盤を「一枚看板」で決めようとしているから「Foundry って、エージェントを作るやつですよね？」「ワークフロー製品の話ですよね？」——会議室でよく聞く問いだ。発言者はどちらも正しいことを言っているが、会話は噛み合わない。 問い方の型が共通しているからだ。「何をする製品か」という一枚看板を貼ろうとする限り、Foundry の全貌は見えない。Foundry は製品名ではなく、スタック（積み上げ構造）の名称だ。複数の層がそれぞれ独立した責務を持ちながら積み重なっている。「今どの層の話をしているか」が決まれば、問いへの答えは自ずと決まる。 本記事では便宜上この積み上げを L1 / L2 / L3 と呼ぶ。Microsoft の公式製品ライン名は Foundry Models（L1 相当）/ Foundry Agents（L2 相当）/ Foundry Workflows（L3 相当） であり、L1/L2/L3 は著者の概念整理フレームだ。公式名と照合しながら、地図として使う。 3層の地図——L1 モデル・L2 エージェント・L3 ワークフローは何をするのか各層を「何をするか・いつ使うか」で横に並べる。 層（本記事の呼称） 公式製品名 何をするか いつ使うか L1（モデル=API） Foundry Models OpenAI・Anthropic Claude・Meta Llama など 1,800+ のモデルをカタログから選び、API エンドポイントとして提供する 常に。L2・L3 もこの層を経由する L2（エージェント） Foundry Agent Service L1 の上にメモリ・社内知識（RAG）・ツール呼び出し機能を積む。OpenAI 互換の Responses API ベースで GA 済。Python / JavaScript / Java / .NET SDK 対応 「会話の履歴を保ちたい」「社内ドキュメントを参照させたい」「外部 API を自律的に呼ばせたい」 L3（ワークフロー） Foundry Workflows 複数のエージェントを段取りで繋ぎ、繰り返し可能なプロセスとして回す。旧 PromptFlow の後継（PromptFlow は 2027年4月20日に廃止予定） 複数の専門エージェントを連携させる複雑なマルチステップ処理が必要なとき 横断（評価・監視・ガバナンス） Operate 層（Build 2026 公式フレーム） トレース・評価・エージェントオプティマイザー。本番稼働中の挙動を測定し、改善提案を閉ループで回す L1〜L3 のどの層でも必要。スタック全体に掛かる 全ての始まりは「サービス化」だ。 エージェントもワークフローも、最終的には API で叩けるサービスとして動く。L1 はすべての基点であり、L2・L3 はその上に積む「便利さの追加」だ。「どの層が必要か」を問うことが、「何をする製品か」という問いの本来の立て方になる。 ...

Admin consent を実行しても Dataverse に弾かれるとき、エラーコードで問題の層が特定できる。 401：サービスプリンシパル（SP）が相手テナントに存在しない——入館証が未発行の状態。 403：入館後のセキュリティロールが不足——室内で許可された操作がない状態。 この2層は独立して動く。片方を解決しても、残りはそのままだ。 入館証と室内権限は別物クロステナントアクセスを「オフィスビルへの入館」で考えると、構造が見える。 入館証（越境）：相手テナントの管理者が同意（Consent）を実行し、自テナント内に SP を実体化させること。SP ができてはじめて、アプリは「入館者」として認識される。 室内権限（認可）：Dataverse の中で何をしていいかを、セキュリティロールで決めること。 Microsoft 公式（cross-tenant-access-overview・2025）は、クロステナントアクセス設定とテナント制限が独立して動作することを明記している。 “they operate separately from inbound and outbound access settings” 設定 何を制御するか SP を作るか クロステナントアクセス設定 テナント間のインバウンド・アウトバウンド しない テナント制限 v2 外部アカウントへの入口制御（門番） しない 同意（Consent） SP の実体化（入館証の発行） する Dataverse セキュリティロール Dataverse 内の操作許可（室内権限） — テナント制限 v2（Tenant Restrictions v2）は Entra ID P1 または P2 が必要で、設定に Security Administrator ロール以上が要求される（2026年7月時点・出典：Microsoft Learn「Configure Tenant Restrictions v2」2025）。 401 の正体SP が対象テナントに存在しないと、Entra ID は次のエラーを返す。 The client application {appId} is missing a service principal in the tenant {tenantId}. （出典：Microsoft Learn「Create an enterprise application from a multitenant application」2024） ...