Posts

「承認したのに、いつの間にか本番にデプロイされていた」——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） ...

PAYG（従量課金）の有効化は、Power Platform 管理センターでチェックボックスを入れるだけに見える。実際には Azure 側に専用リソースが自動作成される工程を伴い、ガバナンスの効いたテナントでは japan と japaneast という名前体系のズレでポリシーに弾かれる。加えて、Production または Sandbox 環境が存在しない場合や、テナントの Dataverse 容量が 1 GB に満たない場合は、有効化の手前で詰まる。壁の構造が分かれば、回避の判断軸は絞られる。 有効化の裏で何が起きているかPAYG を有効化すると、Power Platform 側の操作に連動して Azure 側に Microsoft.PowerPlatform/accounts というリソースが自動作成される（Microsoft Learn – pay-as-you-go-set-up、2024）。 Power Platform 管理センター（プラットフォーム側）の操作が、Azure サブスクリプション（クラウド側）への書き込みを誘発する構造だ。この2段構造を意識しないと、エラーの原因が Power Platform にあるのか Azure にあるのかが判断できない。 詰まりやすい壁は、この境界で2種類出現する： 壁1：Azure Policy がリソース作成リクエストを拒否する（ポリシーの名前体系ズレ） 壁2：対応環境がない、または容量が足りない（環境種別・容量の制約） 壁1——japan と japaneast は別体系Azure のリージョン名と Power Platform のジオ名（地理区分名）は、別の名前体系で管理されている。 名称 種別 補足 Japan Geography（地理区分） デプロイ先として直接指定不可 japaneast ARM リージョン名 Japan East・東京/埼玉 japanwest ARM リージョン名 Japan West・大阪 （Microsoft Learn – Azure Regions List、2024） ...

Power Apps PAYG（従量課金：使った量に応じて後払いする課金モデル）のコストは、機能の利用量でも処理件数でもなく、**「アプリを開いたユーザー数」**で決まる。入力ゼロ・閲覧のみでも、その月に1回でも開けば1人ぶん課金が発生する。「使った分だけ払えばいい」という前提で導入を進めている場合、この定義を先に確認してほしい。 環境前提を整理しておく。本記事が対象とするのは、Power Platform 環境で PAYG を有効化し、per-user ライセンスを持たないユーザーへアプリを公開する設計判断だ。フロー実行課金（Premium Cloud Flow $0.60/実行）と Dataverse ストレージ課金（$48/GB/月）は別メーターであり、本記事のスコープ外として扱う。課金の全体像については、Power Apps PAYG の課金単位——月間ユニーク利用者数の定義と落とし穴 を参照してほしい。 「開く」が課金イベントであるMicrosoft の公式定義は次のとおりだ。 “An active user is someone who opens an app at least once in the given month.” “Repeat access of an app by a user isn’t counted.” — Microsoft Learn: Pay-as-you-go meters（2026年時点） 月に何度開いても1カウントのみ。同じユーザーが30回アクセスしても、その月の課金は $10 のまま（本記事公開時点の単価。最新は公式ページで確認してほしい）。逆に言えば、1回でも開けばその月 $10 が確定する。 課金対象と対象外の基本整理は次の表のとおりだ。 ユーザーの状態 PAYG メーターの扱い Power Apps per-user ライセンス保有者 対象外（カウントされない） Dynamics 365 ライセンスで per-user アクセスを持つ者 対象外 M365 ライセンスで標準コネクターのみ使用する者 対象外 上記以外でアプリを開いたユーザー 対象（$10/アプリ/月） さらに、ユーザーがその月に3本の異なるアプリを開いた場合は、3 × $10 が計上される。「ユーザー数 × アプリ数」の掛け算で課金額が決まる構造だ。複数アプリを一括展開するタイミングは、この掛け算が最大値をとる瞬間でもある。 ...

Power Apps の従量課金（PAYG）が数えているのは、回数でも存在でもない。月間にアプリを1回以上開いた、異なる利用者の人数だ。この定義を誤解したまま現場展開すると、見積もりが構造的に外れる。 環境前提：Azure サブスクリプション経由で PAYG を有効化した Power Apps 環境を対象とする（本記事公開時点の情報。単価・課金条件の最新は公式の Power Apps 料金ページを確認）。 「使った分」の正体PAYG の per-app メーターが数えるのは、月間アクティブユーザー数 × アプリ数だ。 アクティブユーザー（active user）の定義は公式に明確に定まっている。 “An active user is someone who opens an app at least once in the given month.” （Microsoft Learn / pay-as-you-go-meters より） その月に1回以上アプリを開いた利用者を1カウントとして計上し、同一ユーザーの2回目以降のアクセスは数えない。この構造から、現場でくり返し見かける3種の誤解が生まれる。 3つの誤解を潰す誤解1：ヘビーユーザーがいると高くなる実際には、回数は課金に影響しない。 “Repeat access of an app by a user isn’t counted.” “Pay-as-you-go billing only counts unique monthly active users of an app. Repeat access of the same app by a user in a single month results in only one charge for that user that month.” （Microsoft Learn / pay-as-you-go-issues-faq より） ...