実務ハック

「ローコードでどこまでやれるか」——その境界は難しいかどうかではなく、操作の種類で決まる。行の作成・更新・読み取りはローコードの射程内。多対多の関連付け（所属・権限割り当て）だけは、通常のローコード操作では届かない。Patch 関数での直接書き込みは構造的に不可で、専用の Relate アクションを使うにはプレミアムライセンスと制限の確認が前提になる（2026 年 7 月時点）。 難易度ではなく、操作の種類で境界を引くPower Platform で業務ロジックを組むとき、ほとんどの処理はローコードで通る。Patch 関数でレコードを作成・更新し、Filter 関数で読み取り、条件分岐で制御する——これは難易度の問題ではなく、標準の道具が揃っているということだ。 壁になるのは多対多の「繋ぎ」だ。 比喩にすると：付箋に文字を書く・書き直す・読むことは自在にできる。このカードとあのカードを糸で結ぶ——多対多の関連付け——だけは、道具箱に入っていない。 Dataverse（マイクロソフトのクラウドデータプラットフォーム）の多対多関係には交差テーブル（junction table：テーブル間の関連を管理する中間テーブル）が存在するが、Canvas Apps の Patch / Collect 関数からは内部管理テーブルとして直接露出していない。Microsoft Learnのドキュメントには “the intersecting table is not available to use directly”（交差テーブルは直接使用できない）と明記されている。 操作 種類 Patch / 標準アクション直書き 専用の Relate 手段 レコードを作る / 直す 行の作成・更新 ○ — 階層の追従・廃止判定 行の更新・読み取り ○ — 所属させる 多対多の繋ぎ ✕ △（ライセンス・制限あり） 権限を割り当てる 多対多の繋ぎ ✕ △（ライセンス・制限あり） 覚え方：作れる・直せる・読める。ただ、繋げない（通常操作では）。 「できない」と「制限付きで可能」は別の話Patch 以外の手段として、Relate / Unrelate という専用の関数・アクションが用意されている。ただし、使える範囲は限られている。 手段 ステータス ライセンス要件 主な制限 Power Automate：Relate rows / Unrelate rows GA（正式版） Power Automate Premium フロー経由のみ Canvas Apps：Relate / Unrelate 関数 Preview（2024 年 3 月時点） Power Apps Premium オフライン非対応・フラグ有効化必要 Patch 関数で交差テーブルに直接書き込む 不可 — 構造的制約 設計判断として押さえておきたいのは 2 点。 ...

APIキーや署名鍵をローカルに置くほど、守るべき対象は増え、管理は難しくなる。 専用の保管サービス（以下「金庫」）に移すと、守るものが「秘密の値そのもの」から「誰が触れるか（権限）」へ変わる。 懸念は消えない。より守りやすい場所へ移動する。それが金庫導入で起きる設計上の変化だ。 手元保管の4弱点APIキーや認証トークンをローカル（.envファイル・ソースコード・PCのテキストファイル等）に置くことは、直感的には「手元にあるから安全」に見える。構造上は逆だ。 弱点 内容 複製が散る コード・設定ファイル・ドキュメントに貼るたびに同じ値が複数箇所に存在する 回収不能 一度コミット・共有した秘密は完全には回収できない 追跡不能 「誰がいつ使ったか」を後から確認する手段がない 失効不能 漏洩を疑っても、鍵の更新（ローテーション）の影響範囲が掴めない NIST SP 800-204（Security Strategies for Microservices-based Application Systems、2019年）は「トークンのシークレットキーはライブラリコードに含めてはならない。キー値はデータボルトソリューションに保管すべきである」と明記している（出典PDF）。 NSA/CISA「Defending CI/CD Environments」（2023年6月）も「パイプライン内のいかなる箇所でもシークレットをプレーンテキストで渡してはならない」と規定し、IaCテンプレートへのアクセスキーのハードコードをリスク事例として明示している（出典PDF）。 CISA/FBI「Product Security Bad Practices」v2（2025年1月）は「ソースコード内にハードコードされた認証情報は国家安全保障・経済安全保障・公衆衛生に対するリスクを著しく高める」と踏み込んでいる（出典PDF）。 複数の独立した公的ガイドラインが同じ結論に至っている。「ローカルに持つほど弱くなる」は直感と逆だが、構造的に正しい。 金庫が変えること：守る問いの場所が移動する専用保管サービスを導入すると、秘密の値を日常的に扱う必要がなくなる。代わりに「誰がこの金庫を開けられるか」という権限の管理が日常の守り方になる。 NIST SP 800-57 Part 1 Rev.5（Recommendation for Key Management、2020年5月）は「鍵を暗号境界の外部にプレーンテキスト形式で保管してはならない」原則を規定しており、同文書は鍵のライフサイクル全体（生成・配布・保管・更新・廃棄）を通じた保護要件を定めている（出典PDF）。「廃棄」が含まれている点が重要で、権限（アクセスポリシー）には取り消し・有効期限設定が存在する。ローカルの平文ファイルにそれはない。 守る対象が変わると、何が実現できるか。 ローカル保管：秘密の値を守る → 値が散らばり追跡・失効が困難 専用金庫：金庫を開ける権限を守る → 権限は集中管理でき、取り消し・更新がしやすい Azure Key Vault はすべての認証済みREST API呼び出しを AuditEvent カテゴリとして記録する（ログ仕様）。AWS Secrets Manager は CloudTrail 経由で GetSecretValue・CreateSecret・DeleteSecret 等の操作を記録する（CloudTrail統合）。「誰がいつ金庫を開けたか」を後から確認できる状態は、ローカル保管では再現できない。 秘密管理とは、守る問いをどこに置くかの選択だ。 ただし、金庫が保護するのは「保管中」と「取り出す瞬間まで（API輸送中）」に限定される。取り出した後のAPIキーの平文（生の値）は金庫の管轄外だ。AWS CloudTrail の仕様も「ログ内にシークレット値は含まれない」と明示している——取り出した後の使われ方は追跡対象ではない。この限界があるからこそ、「人が直接鍵を取り出さない（後述のManaged Identity）」方式が推奨される設計になる。 設計で詰めるチェック3点金庫を導入した後、以下3点を確認しないと設計が片手落ちになる。 1. 監査ログを有効化したかAzure Key Vault の AuditEvent ログはデフォルト無効だ。診断設定から手動で有効化しないと「誰がいつ開けたか」が記録されない（設定手順）。 ...

Dataverseで階層アクセス制御（BU単位でのデータスコープ設定）を設計すると、セキュリティロールの行数が数万〜十万に膨らむことがある。 管理できないと感じた場合、数え方が違っている可能性が高い。実際に管理すべきは行数ではなく、定義の数——より正確には RoleTemplate（ロール定義の実体エンティティ）の数だ。 BU（Business Unit：ビジネスユニット、組織単位）がいくつ増えても、RoleTemplate は一セットだけ存在する。行数が膨らんでも、管理対象の定義数は環境規模にかかわらず百数十件の範囲に収まる。 なぜ行数が「BU数×定義数」に膨らむのかDataverse のセキュリティロール（特定のテーブルへの操作権限をまとめた権限グループ）は、BU ごとに個別の行として発行される仕組みになっている。BU が 10 あり、ロール定義が 20 あれば、行数は 200 になる。BU が数十〜数百規模の組織では、行数が数万を超えることも珍しくない。 Microsoft の公式ドキュメント（Security roles and privileges、2024 年更新）には次のように明示されている。 “A security role can exist in the root business unit (BU) and replicated to different BU’s, and therefore the role ID is not unique across environments.” Dataverse は内部で Role エンティティ（行として BU ごとに複製される側）と RoleTemplate エンティティ（ロール定義の実体）を分離して設計している。この二層構造が行数の爆発を生む一方で、管理の複雑さを大幅に抑えてもいる。 複製された行が「空の殻」とはどういう意味か複製された Role 行が格納しているのは次の 3 点だけだ。 格納情報 内容 roleId この行固有の識別子（BU ごとに異なる GUID） BusinessUnitId この行がどの BU に属するかの参照 roleTemplateId どの RoleTemplate を参照するか（全環境・全 BU で固定の GUID） 権限の中身——どのテーブルへの読み書き・削除が可能か、という情報——は Role 行に存在しない。それは参照先の RoleTemplate が保持する。 ...

Dataverse でビジネスユニット（BU：データレベルの境界を形成する組織区画）を「無効化」しても、配下ユーザーの権限は一つも切れない。累積加算式のアクセスモデルでは、ロールを明示的に除去しない限り有効な権限として機能し続ける。廃止設計における「無効化」と「権限剥奪」は、独立した 2 工程だ。 無効化フラグの正体——アクセス評価に参加しない状態変数Microsoft の公式ドキュメント（delete-business-unit.md、2026 年確認）は無効化の効果をこう記述する。 “All users and teams associated with the business unit or child business units won’t be able to sign in.” 遮断されるのは「サインイン」だ。セキュリティロールは削除されない。 Dataverse のアクセスモデルは累積加算式で構築されている（Security concepts in Dataverse）。 “all privilege grants are accumulative with the greatest amount of access prevailing” 複数ロールを持つユーザーはすべての権限の和を持つ。無効化フラグはこの評価ロジックの外にある。BU が無効になっても、配下ユーザーのロールは削除されず、アクセス評価エンジンはそのロールを有効として扱い続ける。 無効化とは表示上の印であり、アクセス制御のスイッチではない。 この構造は公式ドキュメント自身が示している。BU を削除する前の手順として「ユーザーとチームを別の BU に移動し、セキュリティロールを再割り当てせよ」と指示していること自体が、無効化操作だけではロール除去が起きないことを前提にしている。 無効化後に通ってしまう操作以下は Dataverse 開発者テナントを用いた検証環境での確認結果だ。公式ドキュメントに明示された記述は見つかっておらず、実測を根拠とする記述であることを最初に断る。 無効化済みの BU 配下に対して次の操作を確認した。 操作 確認結果 配下 BU への新規メンバー追加 完了（セキュリティロール付きで追加できる） 配下 BU を所有者とするレコード作成（Dataverse Web API 経由） 完了 配下 BU の下に子 BU を新規作成 完了 ロールが残存している限り、権限評価はフルに機能する。無効化フラグが権限評価エンジンに影響を与えていないことが、こうした動作を可能にしている構造だ。 ...

フラットな Excel や CSV を Dataverse の関連テーブルに載せるとき、Azure Data Factory（ADF）のような重い基盤は必要か。答えは条件付きで「否」だ。単一の Dataflows（Power Platform の ETL ツール。Power Query で変換ロジックを定義し、Dataverse へデータを投入する）で設計上の安全性を担保できる——ただし「自己正規化」という設計原則と、Dataflows の fail-open 挙動（エラーが出ても処理を続け、失敗行だけを落とす動作）を正しく理解している場合に限る。 環境前提として確認しておく：Dataflows 単独では削除の自動検知はできない。デルタ同期・変更検知の設計は別途必要だ。 なぜ自己正規化は孤児を消せるのか参照整合性エラー——いわゆる「孤児」——が生まれる原因は単純だ。子テーブルのレコードが指す親が、まだ存在していない。これだけだ。 自己正規化の設計は、この問題を構造で封じる。手順は 3 ステップだ。 移行対象のフラット表から、親テーブル相当の列を重複排除して抽出する 抽出した親マスタを Dataflows で先に投入する 同じフラット表から子レコードを投入する この順序を守る限り、子が指す親は必ず存在する。なぜなら、親マスタは同じフラット表の重複排除から作っているからだ。フラット表に存在しない親を子が参照する、という事態は原理的に起きない。これは論理の帰結であり、ツール依存の話ではない。 欠損が生じる場合は「順序のズレ」だけが原因になる。親の投入が終わる前に子を流してしまった場合だ。対処は親→子の順で再実行するだけで収束する。「本物の孤児」——設計上解決できない孤児——は、この構成では原理的に生まれない。 判断が分かれる境界線とはいえ、Dataflows 1 本で完結できる条件には限界がある。以下で対照する。 観点 Dataflows で十分 ADF 等が必要になる 規模感 数万〜10万件（後述の速度実測を参照） 数百万件の継続的デルタ同期 データ鮮度要件 初回移行・週次バッチ リアルタイム / 1 分以内 変換の複雑さ Power Query M で表現できる範囲 複数システム横断の複雑なジョイン・集計 監査・ガバナンス 手動モニタリングで許容できる SLA・自動アラート・再実行の完全自動化が必須 保守体制 業務担当者または情シス 1 名が触れる 専任インフラチームが SLA を持って管理 上記の左列すべてに当てはまる初回移行であれば、ADF を持ち出す必要はない。 速度の正体——固定費を畳む速度に関して、よく聞く「Dataflows は遅い」という印象は比較対象次第だ。 ...

「基幹に持たせよう」という一言は善意で出る。ただし、判断基準が利用者数でも設計の美しさでもないとすれば、何なのか。 答えは一点だけだ。「他システムがそのデータを取り込んで書き足す共有物に育ったかどうか」——これが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 アクション含む 委任が「やむを得ない選択」になる基盤では、はしごを登る以前に別の対策が要る。サービスアカウント専用ユーザーの管理と接続オーナーの引き継ぎ手順の明文化が次善の設計になる。 ...