「とりあえず 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 で接続できる（出典）。
Power Automate の標準コネクタには注意が必要だ。公式ページには「Azure OpenAI リソース名と API キーを入力する」と明記されており（出典）、Managed Identity 対応は現時点で存在しない。将来 GA 化する可能性はあるが、2026 年 7 月時点では確認できていない。
Power Automate から Keyless で AI を呼ぶ 3 つの経路
Power Automate の標準コネクタが API キー前提でも、以下の迂回路がある。
経路 1：カスタムコネクタを自作する（2026-03 GA） Power Platform のカスタムコネクタ（独自の接続定義を作成する機能）が 2026 年 3 月に Managed Identity 認証をサポートした（Microsoft Learn）。Security タブで「Azure Active Directory / Managed Identity」を選択する形で自作すれば、API キー不要の接続が実現できる。「自作」という手間はあるが、一度テンプレートを作れば再利用できる。
経路 2：Keyless 中継レイヤーを挟む Logic Apps Standard または Azure Functions（コードをサーバーレスで実行できる基盤）を Managed Identity 認証の中継として置き、Power Automate からはその中継を呼ぶ設計。AI 基盤の鍵が Power Automate 側に直接渡らない。
経路 3：AI 基盤側で API キー認証を禁止する Azure OpenAI リソースの設定で「Disable API key access」を有効にする。基盤側がキー接続を拒否するため、接続経路全体で Keyless が強制される設計だ。
設計時に詰める 4 つのチェック
1. AI 基盤側の許可設定を先に確認する
どの認証方式が「許可」されているか、「禁止」できるかを最初に確認する。基盤側で API キーを禁止できれば、呼ぶ側も Keyless に揃えるしかなくなる。
2. 実行基盤と認証方式のマッチングを確認する
上記の表を参照し、選択する実行基盤が Managed Identity をネイティブサポートするか確認する。Power Automate 標準コネクタを使う場合は、上記 3 経路のどれを選ぶか先に決める。
3. RBAC 反映時間を設計に折り込む
Managed Identity にロール（権限）を割り当ててから権限が有効になるまで、時間がかかる場合がある（RBAC：Role-Based Access Control、役割ベースのアクセス制御）。公式の目安は以下の通り：
| シナリオ | 反映時間（公式） |
|---|---|
| 直接ロール割り当て | 数分〜最大 10 分（出典） |
| ARM キャッシュ最悪ケース | 最大 30 分（出典） |
| グループ経由ロール付与 | 数時間〜最大 24 時間（出典） |
デプロイ直後に接続テストが失敗しても、RBAC 反映待ちの可能性がある。自動化パイプラインに組み込む場合は「ロール付与 → 待機 → 次ステップ」の順序制御を設計しておく。グループ経由でロールを付与した場合は最大 24 時間の遅延が別途発生しうるため、特に注意が必要だ。
4. Keyless は「認証の入口」にすぎない
鍵なし接続が実現しても、最小権限（必要最小限の権限のみ割り当てる設計）・監査ログ・ネットワーク境界（VNet やプライベートエンドポイント）は別途設計する。「鍵がないから安全」ではなく、Keyless は認証設計の一手段にすぎない。
M365 Developer Tenant があれば、Logic Apps Standard + built-in コネクタや Power Automate カスタムコネクタの認証挙動を顧客環境の外で事前確認できる。
まとめ
AI サービスへの認証は呼ぶ側と呼ばれる側の両面から確認して決まる。実行基盤が Managed Identity をネイティブサポートするかを確認してから設計を始めると、方針の修正が最小化される。
次の一歩
- 使う AI 基盤（Azure OpenAI 等）の設定で「API キー禁止」が有効にできるか確認する
- Logic Apps Standard を使う場合は built-in コネクタ + Managed Identity の RBAC 割り当てから着手できる
- Power Automate を使う場合は、カスタムコネクタ自作・中継構成・基盤側キー禁止設定のどれを選ぶか先に決める
関連記事
- 認証と認可の 2 層構造については：crossing-in-is-not-being-allowed
- 外部委託先に AI の鍵を渡さない設計については：ai-delivery-no-keys-no-pii