同じロジックでも、接続の方式が違うだけで片方だけ止まる。退職者が出た、パスワードが期限切れになった、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 アクション含む

委任が「やむを得ない選択」になる基盤では、はしごを登る以前に別の対策が要る。サービスアカウント専用ユーザーの管理と接続オーナーの引き継ぎ手順の明文化が次善の設計になる。

Logic Apps や Azure Functions を実行基盤に選べる場面では、はしごの最上段が選択肢に入る。

唯一の弱点と IaC 動的参照による解消

Managed Identity を採用したときに残る弱点は一つだ。リソースを作り直すと Managed Identity の principalId（プラットフォームが発行する身元 ID）が変わり、付与していた RBAC（Azure Role-Based Access Control：ロールベースのアクセス制御）ロール割り当てを貼り直す必要が生じる。

この弱点は Bicep（Azure リソースをコードで宣言するテンプレート言語。Infrastructure as Code の一形態）の動的参照で解消できる。

resource managedIdentity 'Microsoft.ManagedIdentity/userAssignedIdentities@2025-01-31-preview' = {
  name: managedIdentityName
  location: location
}

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  // guid() でロール割り当て名を決定論的に生成（べき等性の保証）
  name: guid(resourceGroup().id, managedIdentity.id, roleDefinitionResourceId)
  properties: {
    roleDefinitionId: roleDefinitionResourceId
    principalId: managedIdentity.properties.principalId  // 動的参照（ハードコード不要）
    principalType: 'ServicePrincipal'  // 必須：省略すると断続的エラーが発生する
  }
}

principalId をハードコードせず managedIdentity.properties.principalId で動的参照することで、リソースを作り直しても ID を人が打ち込まずに済む。guid() 関数でロール割り当て名を決定論的に生成することで、何度デプロイしても同じ状態を再現できる（べき等性）。

principalType: 'ServicePrincipal' の明示は必須。 省略すると断続的なデプロイエラーが発生し、原因が追いにくい障害になる（Microsoft Learn「Use Bicep to create Azure RBAC resources」2025 に明記）。

出典：Microsoft Learn「Use Bicep to create Azure RBAC resources」（2025）

設計前に把握しておく限界

Managed Identity を採用しても解消しない問題が複数ある。

権限反映の待ち時間（Microsoft Learn「Troubleshoot Azure RBAC」/ Managed identities FAQ、2025 より）：

操作最大待機時間備考
Azure RBAC 直接ロール割り当て最大 30 分通常は数秒〜数分
グループ経由ロール割り当て数時間（several hours）公式に明記
Managed Identity トークンキャッシュ約 24 時間強制リフレッシュ不可

デプロイ直後のテストで権限エラーが出るのは、この待ち時間が原因のことが多い。特にトークンキャッシュの 24 時間は、障害対応時に調査の方向を誤りやすい。これは「SLA ではなく上限の目安」として扱う。

コネクタ制約：上述のとおり、Power Automate の標準コネクタは現時点で Managed Identity に対応していない。委任でしか繋がらない接続先には、別の設計で補う必要がある。

越境不可：現時点の仕様上、Managed Identity が有効なのはテナント内（または仮想ネットワーク内）のリソースに限られる。テナント外のサービスとの接続には API キー等が引き続き必要であり、その管理には Key Vault（クラウド上での秘密情報の安全な保管サービス）を使う。

最小権限は別途設計が必要：Managed Identity を採用しても、付与するロールの範囲を絞る設計は別途行う。身元の管理と権限の最小化は別問題だ。

テンプレートを手元で確かめる

上記の Bicep テンプレートを自分の手で動かすなら、Azure 無料アカウントで Logic Apps Standard の環境を立てて試せる。RBAC ロール割り当てを実際にデプロイし、反映待ち時間を体感してから本番設計に持ち込む順序が最短ルートだ。Power Automate の実行基盤であれば M365 Developer Program（月額無料）が Power Platform フル環境を提供している。

まとめ

「楽に設定できる」認証方式は「壊れやすい」認証方式でもある。Managed Identity を選べる基盤では最上段を選ぶ、選べない基盤では委任接続を前提に別の設計で補う——この二段構えが、2026 年時点での現実的な認証設計の判断だ。

次の一歩

  1. 実行基盤が Logic Apps / Azure Functions かを確認する（Power Automate の標準コネクタは現時点で Managed Identity 非対応）
  2. Managed Identity を選べる場合は上記 Bicep テンプレートを出発点に設定する。principalType: 'ServicePrincipal' の明示を忘れない
  3. 委任接続が避けられない場合は、接続オーナーの引き継ぎ手順を今のうちに文書化する

関連記事：実行基盤別の鍵なし適合度——許す側と名乗る側の設計 / DB 接続のパスワード共有をやめる——Managed ID 移行の 4 段階 / 認可設計：環境とグループの 3 層で権限をアプリの外に出す