実務ハック

アプリごとに権限を作り込む設計は、アプリが廃止・移行された瞬間に価値を失う。組織改編のたびにアクセス権を全件触り直すのは、うっかりではなく構造の問題だ。 結論を先に置く。セキュリティ境界は環境（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 より） ...

役職名をもとにアクセスグループを設計しているなら、例外が増えるたびに設計が崩れていく構造に入っている。 同じ「課長」でも決裁権限が違う人がいる。部門によって「支社長」と呼ぶポジションが、別部門では「部長」と呼ばれる。 この2つの問題を役職名で解こうとすると、例外グループが増え続けるか、手動判断が常態化するかのどちらかに向かう。 判定軸を役職名から「その人が管理する範囲（スコープ）」に移すことで、例外を構造の外に出せる。以下、破綻のパターンと修正設計を整理する。 役職名が「表示」である理由アクセス設計で役職名を使う発想は自然だ。人事システムやMicrosoft 365（以下M365）のユーザー属性に役職名は入っているし、「課長以上はこのリソースへアクセス可」というルールは口頭でも伝わりやすい。 ただし、役職名は名刺の文字——つまり表示のための情報であって、アクセスを決める判定軸ではない。 アクセスを決めるべきは管轄地図の区画だ。「その人がどの範囲の業務・データを担当しているか」という情報は、役職名から計算では導けない。同じ「課長」でも、担当課が違えば見るべきデータは違う。同じ「部長」でも、特定プロジェクトの都合で一段上の権限を持つケースがある。この差は人事システムの役職コードには含まれていない。 NIST SP 800-162（Guide to Attribute Based Access Control、2014年・2023年更新）は、役職・職責を軸にするRBAC（Role-Based Access Control：役割ベースアクセス制御）が、兼務・例外・部門横断業務に対応しようとするとロール数が増加し続ける構造的問題を公式に認識している。また、Gartner IAM Summit 2024の場では「誰が何にアクセスできるか？そもそもアクセスすべきか？」という基本問を答えられないIAM（Identity and Access Management：アイデンティティとアクセスの管理）担当者が多いという指摘がなされた（Axoniusブログ経由・2次ソース）。名前軸の設計が崩れるのは運用の問題ではなく、設計の構造上の必然だ。 破綻が起きる3つのパターン役職名ベースの設計が壊れるとき、たいていこの3パターンのどれかが起きている。 パターン1: 同じ役職名で権限が違う「課長グループ」にアクセス権を設定した後、「A課長は経営企画も兼務しているので一段上の権限が必要」という依頼が来る。グループに例外フラグを付けるか、別グループを作るか——どちらを選んでもその場しのぎになる。次の例外が来るたびに同じ判断を繰り返す。 パターン2: 部門ごとに呼称が揃わない営業部門では「支社長」、本社管理部門では「部長」、製造部門では「工場長」——これらが同じ権限スコープを持つとき、呼称の等級を比較して共通グループに収める作業が発生する。組織変更のたびにこの比較表が更新の対象になる。 パターン3: 異動・兼務のたびに設定変更が必要になる役職名軸の設計では、異動や兼務が発生するたびに「旧グループから削除して新グループに追加する」という手作業が伴う。作業が常態化し、設定漏れが権限の過不足を生む。業界の実務知見として、1,000名規模の組織でもロール（グループ）定義が数千に達するケースが広く認識されている（Evolveum IAMドキュメント・2次ソース）。 設計パターン3点セット判定軸を管理範囲に移すとき、以下の3点を設計に組み込む。 1. 名前→範囲の対応表を1枚に隔離する役職名と管理範囲の対応関係を、権限グループとは別の1枚のテーブルに切り出す。 [ユーザー] → [名前→範囲対応表] → [スコープ定義] → [リソース権限] 権限グループ側は「スコープA担当」「スコープB管理者」という管理範囲ラベルを持ち、役職名は対応表の入力値になるだけで権限グループ側には現れない。 組織変更や呼称変更があったとき、更新するのは対応表だけでよく、権限グループ側は無改修になる。 設計の比較 役職名軸 管理範囲軸 例外対応 新グループを追加 対応表に1行追加 呼称変更 グループ名も変更 対応表だけ変更 組織変更 グループ構成を再設計 スコープ定義のみ見直し 異動処理 複数グループを更新 対応表のエントリを更新のみ 2. 例外は「人ごとの上書き」データで吸収する同じ役職名でも権限が違うケースをスコープ計算で解こうとすると、ルールの置き場所がなくなる。「この人だけ一段上」という例外は、計算ロジックではなく人ごとの上書きエントリで持つ。 実装上は、ユーザーに紐づく「スコープオーバーライド」テーブルを対応表の隣に用意し、上書き値がある場合はそちらを優先する構造にする。 [ユーザーID] × [上書きスコープ] × [有効期限] × [申請理由] 有効期限と申請理由を必須フィールドにしておくことで、いつ・なぜ付与された例外かを追跡できる状態を保てる。過剰権限が放置されるとセキュリティインシデントにつながる経路は実際にある（IDSA「Trends in Securing Digital Identities」2024：過去の調査データで不適切な権限管理が侵害の36%、過剰権限が21%に関与）。上書きデータは定期的にレビューし、不要になった時点で削除する運用とセットにする。 ...

「タイムアウト0件、合格」という結果が出た。だが、その数値は本当に測りたいものを測っていたか。 実機検証でもっとも見落とされがちなのは、対象システムの不具合ではなく計器（測定の前提）の誤りだ。 きれいな結果ほど疑われず、そのまま結論に変わりやすい。 「計器を疑う」という視点パイロットが視界ゼロの気象条件で飛行するとき、コックピットの計器だけを根拠に操縦する。FAA（米連邦航空局）はこの飛行方式をIFR（Instrument Flight Rules）と定義している（FAA Pilot/Controller Glossary 2024年）。計器が正しいことを前提とした運用だ。 この話を逆にすると、ソフトウェア検証への応用になる。「計器が正しい」という前提を意識せずに検証結果を読むと、計器が狂っていても気づかない。「計器を先に疑う」というのは著者が航空のアナロジーを逆転させた言い方で、正式な学術用語ではない。ただ、実機検証の現場で繰り返しぶつかった構造を説明するのに、航空のアナロジーを逆転させた視点が有効だった。 SREやDevOpsのオブザーバビリティ文脈では、instrumentation（計器化）は「センサー・ゲージ・アラームの集合体でシステム状態を観測可能にする行為」を指す（SRE School 2026年）。その計器自体が誤った値を出していたら、オブザーバビリティは機能しない。 以下で、実機検証で実際に踏んだ4種類の計器の嘘と、それぞれへの対処を整理する。 計器の嘘1: 環境の汚染前回の検証データが環境に残留していて、新しい測定が汚染される。典型的なのは「解決済み件数が投入件数を上回る」という数値が出るケースだ。物理的にあり得ない値なので、見た瞬間に気づけば問題ない。だが、きれいな数値の場合はそのまま通過してしまう。 対処：サニティチェックを先に走らせる。 サニティチェックとは、「主張や計算結果が正しい可能性があるかを素早く評価する基本テスト」（Wikipedia – Sanity check 2024年）だ。明らかに誤った結果クラスを除外するための確認で、IEEEやSEIの正式標準用語ではなく業界慣用語にとどまるが（Software Testing Help 2024年）、実務では有効なファーストステップになる。 チェック観点 確かめること あり得ない値 件数の逆転、マイナス値、100%超え 前回データの残存 ジョブテーブルに旧データが混在していないか 環境の初期化 本当にクリーンな状態から始めているか 測定を始める前に、「この環境は本当に前回と切れているか」を確かめる。これが最初の手続きだ。 計器の嘘2: 指標の取り違え「処理時間を測った」という記録が、実際には「キュー待ち時間＋実行時間」の合計だったというケースがある。見たかったのは実行時間だけなのに、待機時間が混入していると、数値の意味が変わる。 たとえばキューが詰まっている状況では総経過時間が長くなるが、実行自体は速い場合がある。反対に、キューが空いていれば見かけ上速く見えるが実行処理が重いこともある。指標の定義を事前に明示せずに測ると、「速い/遅い」の結論が的外れになる。 対処：測定対象の定義を測定開始前に書き留める。 「どこからどこまでを時間とするか」「何個のジョブを対象とするか」「並列度はいくつか」——これらを検証レポートの冒頭に書いておく。指標の定義は後付けにしない。 なお、このパターンの技術的な詳細（Dataverse非同期ジョブのキュー構造とタイムアウトの関係）は関連記事「async-timeout-diagnosis」を参照。 計器の嘘3: データ消失（成功ジョブの自動削除）Power Platform（Dataverse）の非同期ジョブ処理で遭遇する、見落としやすい仕様がある。 Microsoft Learnの公式ドキュメントによれば、Dataverse AsyncOperationテーブルの成功済みシステムジョブは、デフォルトで30日後に自動削除される（Microsoft Learn 2025年）。失敗・キャンセルの場合は60日間保持されるが、成功ジョブの保持期間はそれより短い。 “All environments are configured with out-of-box bulk delete jobs to delete successfully completed workflow system jobs that are older than 30 days.” — Microsoft Learn, Delete completed system jobs and process log ...