Azure Functions でリモートサービスへの接続を構成する

この記事は、Azure Functionsがリモートサービスに接続する方法に関する主要な参考資料です。接続の種類や認証方法に基づいた具体的な指針を提供します。

Important

可能な限り管理されたIDとMicrosoft Entra IDを使いましょう。この認証方法は秘密を排除し、最高のセキュリティを提供します。

接続カテゴリ

Azure Functionsの接続は以下の基本的なカテゴリに分類されます:

必要なホスト:機能ホストが動作させるために必要な接続(ストレージや監視など)。
バインディング:ホストがあなたのトリガーやバインディングのために管理する接続。
クライアント SDK: 独自の関数コード内で作成および管理する接続です。

ヒント

Functionsはまた、管理型コネクタ(プレビュー版)をサポートしており、Office 365、Teams、SharePointなどのサービスと、Connector Namespaceを通じてOAuthやWebhook対応を組み込み接続できます。詳細については、「Use connectors in Azure Functions」をご覧ください。

Functionsホストは、関数の実行とログの両方をサポートする以下の特定の名前付き接続をアプリに要求しています。

AzureWebJobsStorage: Functionsはこのデフォルトのストレージアカウントを使って、タイマートリガーのシングルトン実行の調整やファンクションアクセスキーのデフォルトストレージの調整などのコア動作を有効にします。ホストはこの接続をサポートストレージアカウントに要求します。この接続設定がないと関数アプリは起動できません。詳細については、「Azure Functions のストレージに関する考慮事項」を参照してください。
APPLICATIONINSIGHTS_CONNECTION_STRINGまた、ホストがApplication Insightsインスタンスにログを書き込むように設定することも必要です。
WEBSITE_AZUREFILESCONNECTIONSTRING: コンシューマストプランまたはエラスティックプレミアムプランで動作するアプリのみに使用されます。アプリケーションのデプロイメントパッケージを維持するAzure Files共有を含むストレージアカウントを定義します。

リモートサービスに接続するバインディング拡張機能は、アプリ設定に接続情報を保存しなければなりません。これらのトリガーやバインディングには、接続情報を含む設定の名前またはプレフィックスに設定する connection プロパティがあります。これらの設定のキー名と値の正確な要件は、接続で使用される認証の種類によって異なります。バインディング拡張の完全な一覧については、サポートされているサービスを参照してください。

Functionsホストがこれらの接続を管理し、関数からデータの読み込みや書き出しに使います。これらの接続のためにクライアントをコード内で直接使うことはできません。

理にかなっている場合、ストレージバインディングはホストのストレージアカウント(AzureWebJobsStorage)と同じストレージアカウントを使うことができます。詳細は「共有ストレージアカウント」をご覧ください。

認証方法

Important

可能であれば、接続には管理型アイデンティティを使いましょう。この方法により秘密は完全に排除されます。対象サービスがMicrosoft Entra ID認証をサポートしていない場合は、Azure Key Vaultを使って秘密を中央管理してください。共有秘密はアプリの設定で最後の手段として使うだけです。

Functionsはリモートサービスに接続する際の以下の認証方法をサポートしています:

認証方法	セキュリティ	いつ使用するか
マネージド ID	最高	TargetサービスはMicrosoft Entra IDをサポートしています。管理するシークレットはありません。
Azure Key Vault	High	サービスはマネージドIDをサポートしていなかったり、ローテーション付きの集中管理が必要な場合もあります。
共有された秘密	低	レガシーのデフォルトです。できるだけ早くマネージドIDやKey Vaultに移行しましょう。

記事の冒頭で希望する認証方法を選択すると、詳細な設定ガイダンスが表示されます。

接続の定義

実行時には、関数アプリは以下の場所から環境変数として接続情報にアクセスします:

環境	設定が保存されている場所
Azure	アプリケーション設定 (静止時暗号化)
ローカル開発	local.settings.json (暗号化オプション)

どちらの環境でも、設定は環境変数としてコードに露出します。必要な具体的な設定は、接続の種類と選ぶ認証方法によって異なります。

Microsoft Entra認証を使ってAzureサービスに接続する場合、使用するアプリの設定は接続されたサービスや、システム割り当てIDかユーザー割り当てIDの認証かによって異なります。

接続に使うアイデンティティには、意図された動作を実行する権限が必要です。ほとんどのAzureサービスでは、この要件はAzure RBACで役割を割り当てる必要があることを意味します。その役割は組み込みまたはカスタムの権限のいずれかで割り当てられます。詳しくは「アイデンティティへの権限付与」をご覧ください。

マネージド ID を使用して関数アプリを構成するチュートリアルについては、ID ベースの接続を使用した関数アプリの作成に関するチュートリアルを参照してください。

アイデンティティベースの接続を使用する際には以下の点を念頭に置いてください:

Functions でホストされるアプリでは、ID ベースの接続でマネージド ID を使用します。システムが割り当てたアイデンティティはアプリ固有のもので、デフォルトで使われます。しかし、ユーザー割り当てのアイデンティティは、 *__credential や *__clientID プロパティも必要とされ、より柔軟で推奨されます。
アプリがローカル開発など他のコンテキストで動作する場合、代わりに開発者のアイデンティティが使われます。詳細は地域開発の記事をご覧ください。
アイデンティティベースの接続は、Functionsのランタイムバージョン4.x以降でのみサポートされています。もしFunctionsランタイムのバージョン1.xでレガシーC#アプリを動かしているなら、まずバージョン4.xに移行する必要があります。

デフォルトのストレージアカウント(AzureWebJobsStorage)やその他のホスト必須接続に接続する際、機能アプリで接続文字列の代わりにIDを使うように設定できます。

AzureWebJobsStorageのマネージドアイデンティティサポートはホスティングプランによって異なります:

ホスティングプラン	ホストストレージのためのMI	Azure Files の要件	レコメンデーション
フレックス消費	完全なサポート	None(Azure Filesなし)	心筋梗塞に推奨
専用 (App Service) プラン	完全なサポート	なし(動的スケーリングなし)	完全な心筋梗塞、回避策は不要です
消費	ブロブ、キュー、テーブル	Key Vault または Azure Files を削除	`WEBSITE_AZUREFILESCONNECTIONSTRING`をKey Vaultに保管してください
エラスティックプレミアム	ブロブ、キュー、テーブル	Key Vault または Azure Files を削除	`WEBSITE_AZUREFILESCONNECTIONSTRING`をKey Vaultに保管してください

ホスト要求接続にマネージドIDを使用する前に、以下の制限を考慮してください:

Consumption PlanやPremiumプランについては、Azure Files向けに以下の回避策を実装してください:
- WEBSITE_AZUREFILESCONNECTIONSTRING 接続文字列だけをKey Vaultに保存するのが次に安全な方法です。
- Azure Filesなしで動作するConsumption PlanまたはPremiumプランアプリを作成しましょう。 Azure Filesなしで動作するとパフォーマンスに影響があります。詳しくは、「Azure Files を使わずにアプリを作成する」をご覧ください。
これらのトリガーは正しく動作するために AzureWebJobsStorage に依存しています:
- Azure Blob Storage
- Azure Event Hubs
- Durable Functions(デフォルト)
- Timer
もしアプリがこれらの拡張機能を使っているなら、そのバージョンが管理されたIDもサポートしているか確認してください。
AzureWebJobsStorage は、Linux Consumption プランのサーバー側（リモート）ビルドでデプロイアーティファクトを保持します。この場合、外部デプロイメントパッケージからアプリをデプロイし実行する必要があります。
関数アプリの他のコンポーネントはAzureWebJobsStorage接続を再利用することもあり、例えばストレージバインディング拡張やAzure SDKを使って作成されたストレージクライアントなどが含まれます。マネージドIDを使用する場合は、管理IDをサポートしている場合でも、これらの非ホストコンポーネントに対して新しいアプリケーション設定を作成しましょう。

これらの特定のアプリ設定は、 AzureWebJobsStorage と APPLICATIONINSIGHTS_CONNECTION_STRINGの両方に対するアイデンティティベースのつながりを定義します。

Setting	Description
`AzureWebJobsStorage__blobServiceUri`	デフォルトのストレージアカウントにあるBlob StorageのURIです。ソブリンクラウドやカスタムストレージDNSに必要です。例えば: `https://mystorageaccount.blob.contoso.com`。 `HTTPS` は必須です。
`AzureWebJobsStorage__queueServiceUri`	デフォルトのストレージアカウントにあるキューストレージ用のURIです。ソブリンクラウドやカスタムストレージDNSに必要です。例えば: `https://mystorageaccount.queue.contoso.com`。 `HTTPS` は必須です。
`AzureWebJobsStorage__tableServiceUri`	デフォルトのストレージアカウントにあるテーブルストレージ用のURIです。ソブリンクラウドやカスタムストレージDNSに必要です。例えば: `https://mystorageaccount.table.contoso.com`。 `HTTPS` は必須です。
`AzureWebJobsStorage__credential`	管理ID認証を使用するために `managedidentity` に設定します。管理型アイデンティティはホスティング環境で利用可能でなければなりません。
`AzureWebJobsStorage__clientId` または `AzureWebJobsStorage__managedIdentityResourceId`	管理ID認証のためのアクセストークンを取得するために使われる特定のユーザー割り当てIDを返します。どちらも設定されていない場合は、アプリケーションにシステム割り当ての識別子が使われます。
`APPLICATIONINSIGHTS_AUTHENTICATION_STRING`	Microsoft Entra認証を用いてApplication Insightsへの接続を可能にします。 `Authorization=AAD`(システム割り当て)または`ClientId=<YOUR_CLIENT_ID>;Authorization=AAD`(ユーザー割り当て)に設定します。

ダブルアンダースコア値(__)は実行時にコロン(:)として解釈されるため、設定の列は AzureWebJobsStorage オブジェクトのプロパティとして解釈されます。例えば、以下の AzureWebJobsStorage 接続設定を考えてみましょう。

AzureWebJobsStorage__blobServiceUri=https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net
AzureWebJobsStorage__queueServiceUri=https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net
AzureWebJobsStorage__tableServiceUri=https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net
AzureWebJobsStorage__credential=managedidentity
AzureWebJobsStorage__clientId=<MY_USER_ASSIGNED_IDENTITY_ID>

実行時には、ホストはこれらの設定を複雑な AzureWebJobsStorage 設定として解釈します。

"AzureWebJobsStorage":
{
    "blobServiceUri": "https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net",
    "queueServiceUri": "https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net",
    "tableServiceUri": "https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net",
    "credential": "managedidentity",
    "clientId": "<MY_USER_ASSIGNED_IDENTITY_ID>"
}

また、ホストが必要なタスクを実行するために十分な権限を持つために、デフォルトのストレージアカウントでIDの権限を付与する必要があります。詳細については、「 Grant permissions to a identity(識別子への権限付与)」をご覧ください。

これらのバインディング拡張は現在、アイデンティティベースの接続をサポートしています:

バインド拡張機能	最小拡張パッケージバージョン(.NET)	最小拡張バンドルバージョン
Azure BLOB Storage	5.0.0	3.3.0
Azure Cosmos DB (NoSQL API)	4.0.0	4.0.2
Azure Event Grid	3.3.0	3.3.0
Azure Event Hubs	5.0.0	3.3.0
Azure OpenAI	0.19.0-alpha	4.32.0
Azure Queues storage	5.0.0	3.3.0
Azure Tables storage^*	1.0.0	3.3.0
Azure Service Bus	5.0.0	3.3.0
Azure SignalR	1.7.0	3.6.1
Azure SQL Database	3.0.0	3.3.0
Durable Functions	2.7.0	3.3.0

^*また、Azure Cosmos DB Table APIもサポートしています。

マネージドIDの場合、全体の接続は複数の個別設定で構成されており、それぞれに接頭辞が <CONNECTION_NAME_PREFIX>付加され、バインディング固有の接続設定に固有のものがあります。 <CONNECTION_NAME_PREFIX> その場合は、あなたの特定のサービス接続に必要な connection 財産の価値として使われます。

管理型アイデンティティ接続プロパティの作成方法は、使用するアイデンティティの種類によって異なります。

IDの種類	必要な接続プロパティ
システム割り当て済み	`<CONNECTION_NAME_PREFIX>__credential=managedidentity`
ユーザー割り当て(クライアントID)	`<CONNECTION_NAME_PREFIX>__credential=managedidentity` `<CONNECTION_NAME_PREFIX>__clientId=<CLIENT_ID>`
ユーザー割り当て済み (リソース ID)	`<CONNECTION_NAME_PREFIX>__credential=managedidentity` `<CONNECTION_NAME_PREFIX>__managedIdentityResourceId=<RESOURCE_ID>`

バインディングの管理されたアイデンティティ接続を定義する際には、アイデンティティの種類に応じて、以下の設定のいずれかを含める必要があります。

設定名	Description
`<CONNECTION_NAME_PREFIX>__clientId`	アクセストークンを取得するときに使用する特定のユーザー割り当て ID を設定します。 `<CONNECTION_NAME_PREFIX>__credential`が`managedidentity`に設定されている必要があります。このプロパティは、アプリケーションに割り当てられたユーザー割り当て ID に相当するクライアント ID を受け取ります。リソース ID とクライアント ID の両方を指定することは無効です。指定されていない場合、システム割り当て ID が使用されます。 `credential` を設定すべきではないローカル開発シナリオでは、このプロパティは異なる方法で使用されます。
`<CONNECTION_NAME_PREFIX>__credential`	接続のaccess トークンを取得する方法を定義します。マネージド ID 認証には `managedidentity` を使用します。この値は、ホスティング環境でマネージド ID が使用できる場合にのみ有効です。
`<CONNECTION_NAME_PREFIX>__managedIdentityResourceId`	`credential` が `managedidentity` に設定されると、このプロパティによって、トークン取得時に使用されるリソース ID を指定できます。プロパティは、ユーザー定義マネージド ID のリソース ID に対応するリソース識別子を受け取ります。リソース ID とクライアント ID の両方を指定することは無効です。両方とも指定されていない場合は、システム割り当て ID が使用されます。このプロパティは、ローカル開発環境では、`credential`を設定すべきでない場合に、通常とは異なる方法で使用されます。

ダブルアンダースコア値(__)は実行時にコロン(:)として解釈されるため、設定の列は <CONNECTION_NAME_PREFIX> オブジェクトのプロパティとして解釈されます。例えば、Azure Event Hubsの拡張機能設定を考えてみてください:

MyEventHubConnection__fullyQualifiedNamespace=<MY_EVENT_HUB_DNS>.servicebus.windows.net
MyEventHubConnection__credential=managedidentity
MyEventHubConnection__clientId=<MY_USER_ASSIGNED_IDENTITY_ID>

実行時に、これらの設定は、次のような単一の MyEventHubConnection 設定としてホストによってまとめて解釈されます。

"MyEventHubConnection":
{
    "fullyQualifiedNamespace": "<MY_EVENT_HUB_DNS>.servicebus.windows.net",
    "credential": "managedidentity",
    "clientId": "<MY_USER_ASSIGNED_IDENTITY_ID>"
}

その他の設定は特定のバインディング拡張によって必要です:

Extension	設定名	Description
Azure Blob Storage	`<CONNECTION_NAME_PREFIX>__blobServiceUri`^*	接続しているブロブストレージサービスのURI、例えば `https://<STORAGE_ACCOUNT_NAME>.blob.core.windows.net`です。 Blob Storageトリガーには、同じアカウントのキューストレージURIにも`<CONNECTION_NAME_PREFIX>__queueServiceUri`を設定しなければなりません。これは毒の塊を追跡するために使われます。
Azure Cosmos DB	`<CONNECTION_NAME_PREFIX>__accountEndpoint`	`https://<database_account_name>.documents.azure.com:443/` などの Azure Cosmos DB アカウントのエンドポイント URI。
Azure Event Hubs	`<CONNECTION_NAME_PREFIX>__fullyQualifiedNamespace`	イベントハブの完全限定名前空間、例えば `<MY_EVENT_HUB_DNS>.servicebus.windows.net`。
Azure Event Grid (出力)	`<CONNECTION_NAME_PREFIX>__topicEndpointUri`	出力バインディングがトピックに書き込みするために使用するトピックエンドポイント(例: `https://<TOPIC_NAME>.centralus-1.eventgrid.azure.net/api/events`)。
Azure OpenAI	`<CONNECTION_NAME_PREFIX>__endpoint`	Azure OpenAIサービスのURIエンドポイントを設定します。この設定は常に必須です。
Azure Queue storage	`<CONNECTION_NAME_PREFIX>__queueServiceUri`^*	接続しているキューストレージサービスのURI(例えば `https://<STORAGE_ACCOUNT_NAME>.queue.core.windows.net`)です。
Azure Service Bus	`<CONNECTION_NAME_PREFIX>__fullyQualifiedNamespace`	完全適格のService Busネームスペース、例えば`<service_bus_namespace>.servicebus.windows.net`
Azure SignalR	`<CONNECTION_NAME_PREFIX>__serviceUri`	SignalRサービスのURIは、 `https://<SIGNALR_RESOURCE_NAME>.service.signalr.net`。
Azure テーブルストレージ	`<CONNECTION_NAME_PREFIX>__tableServiceUri`^*	接続しているテーブルストレージサービスのURI(例えば `https://<STORAGE_ACCOUNT_NAME>.table.core.windows.net`)です。
Durable Functions	`<CONNECTION_NAME_PREFIX>__blobServiceUri` `<CONNECTION_NAME_PREFIX>__queueServiceUri` `<CONNECTION_NAME_PREFIX>__tableServiceUri`	また、Blobストレージ、キューストレージ、テーブルストレージサービスのデータプレーンURIも設定しなければなりません。

^* <CONNECTION_NAME_PREFIX>__serviceUriを別名として使うことができます。両方の形が提供されている場合は、 blobServiceUriのようなより具体的な形が使われます。接続構成全体が複数のブロブ、キュー、テーブルサービスをサポートしなければならない場合、一般的な serviceUri フォームは使えません。

各バインディングごとに、リモートサービス内のアイデンティティにも権限を付与し、アプリが必要なタスクを実行するための十分な権限で接続できるようにします。詳細については、「 Grant permissions to a identity(識別子への権限付与)」をご覧ください。

クライアントSDKを使って、他のAzureやサードパーティサービスへの接続を手動で作成・管理しましょう。多くのAzure SDKでは、管理されたIDでMicrosoft Entra IDを使い、共有シークレットの使用を回避できます。管理されたIDを使って接続する方法については、お使いのAzure SDKのガイダンスに従ってください。

Caution

Azure SDKのEnvironmentCredential環境変数は使わないでください。意図せず他の接続に影響を与える可能性があります。 Azure Functionsは、デプロイ時にこれらの環境変数を完全にはサポートしていません。

Azure SDKのEnvironmentCredential環境変数も設定可能ですが、Functionsは消費プランでこれらの変数をスケーリングのために処理しません。これらの環境変数は特定の接続に特有のものではなく、対応するプロパティが設定されていない限りデフォルトとして適用されます。例えば、AZURE_CLIENT_ID を設定すると、接続では <CONNECTION_NAME_PREFIX>__clientId が設定されている場合と同じようにそれが使用されます。明示的に <CONNECTION_NAME_PREFIX>__clientId を設定するとこのデフォルトが上書きされます。

ID に権限を付与する

管理型アイデンティティとMicrosoft Entra ID認証を組み合わせる場合、リモートサービスに接続する際にアプリが使用するアイデンティティに権限を明確に割り当てる必要があります。アプリに最小権限権限を付与する最も簡単な方法は、組み込みの役割を割り当てることです。

アプリのIDにRBAC権限を与える際には以下の推奨事項を念頭に置いてください:

可能な限り、アイデンティティに最低限必要な特権のみを与えるという 最小特権の原則 を守ってください。例えば、アプリがデータソースからのみ読み込む必要がある場合は、読み書き権限のみを持つ役割を使いましょう。
アプリを動かすためだけでも、オーナーのような広範な内蔵ロールは使わないでください。
役割割り当てを作成または修正した後、変更が伝播するまでに最大10分かかることがあります。この期間中、役割が正しく割り当てられていても、あなたの機能が認可エラー(403)を受けることがあります。ロール割り当てを作成してすぐにエラーが発生した場合は、数分待ってから再試してみてください。
複数の接続が同じサービスへの権限を必要とする場合は、そのサービスへのすべての接続に対して最小限の権限部分集合としての役割を用いてください。
いくつかのバインディングは、 AzureWebJobsStorage 接続で必要とされるよりも広い権限をストレージアカウントに要求します。
管理されたIDを使ってKey Vaultの鍵にアクセスするには、アプリをKey Vault Secrets Userロールに割り当ててください。また、管理IDに「秘密取得」権限を割り当てるために、Key Vaultアクセスポリシーを使うこともできます。詳細については、アプリ内の ID にキーコンテナーへのアクセス権を付与するを参照してください。
この記事では、最低限の権限を提供する組み込みロールのみを指しています。アプリの要件によっては、自分でカスタムロールを作成する必要があるかもしれません。

必要な権限は接続の種類によって異なります:

AzureWebJobsStorage: ストレージブロブデータオーナーの役割は、ホストが必要とする AzureWebJobsStorage 接続の最小限のストレージアカウント権限を提供します。この役割は、 最小権限の原則に従いながら、関数ホストが必要とするストレージアクセスレベルを提供します。

特定の問題タイプでは、Functionsはアプリが起動しなくてもトラブルシューティングを助ける診断イベントを発生させます。また、診断イベントが永続化されるテーブルストレージへのアクセスを提供するストレージテーブルデータ貢献者の役割も追加する必要があります。これらの追加権限がなければ、ログにこれらのイベントを書き込めない警告が表示されるかもしれません。

他のいくつかのバインディングでは、もう少し広い役割を使う必要があるかもしれません。テーブルの「Bindings」タブのホスト要求ストレージ列には、これらの役割要件が記載されています。
APPLICATIONINSIGHTS_AUTHENTICATION_STRING: Monitoring Metrics Publisherの役割は、ホストがログ作成のためにApplication Insightsに接続するために必要な最低限の権限を付与します。

注意

APPLICATIONINSIGHTS_AUTHENTICATION_STRING を使用して Microsoft Entra 認証で Application Insights に接続する場合、Application Insights のローカル認証を無効にすることが必要です。この構成では、テレメトリをワークスペースに取り込むために、Microsoft Entra認証が必要です。

最小の役割ベースのアクセス権限は、特定のバインディングタイプによって異なります。この表は、特定のトリガーやバインディングに対してあなたのアイデンティティに割り当てるべき推奨ロールを示しています:

Extension	トリガー	入力バインド	出力バインド	ホスト必要ストレージ¹
Azure BLOB Storage	ストレージ BLOB データ所有者ストレージキューデータ貢献者⁴	ストレージブロブデータリーダー	ストレージ BLOB データ所有者	ストレージキューデータ共同作成者ストレージアカウント共同作成者
Azure Cosmos^DB2	Cosmos DB 組み込みデータコントリビューター3	Cosmos DB 組み込みデータリーダー	Cosmos DB 組み込みデータ共同作成者	なし
Azure Event Grid	なし	なし	EventGrid寄稿者 Event Grid データ送信者	なし
Azure Event Hubs	Azure Event Hubs データ受信機 Azure Event Hubs データ所有者	なし	Azure Event Hubs データ送信者	ストレージ BLOB データ所有者
Azure Queue Storage	ストレージキューデータリーダーストレージキューデータメッセージプロセッサ	なし	ストレージキューデータ共同作成者ストレージキューデータメッセージ送信者	なし
Azure Service Bus	Azure Service Bus Data Receiver⁵ Azure Service Bus データ所有者	なし	Azure Service Bus データ送信ユニット	なし
Azure SignalR	SignalR Service 所有者	SignalR Service 所有者	SignalR Service 所有者	なし
Azure SQL Database6	`db_datareader`	`db_datareader`	`db_datawriter`	なし
Azure テーブルストレージ	なし	ストレージテーブルデータ閲覧者	ストレージテーブルデータ共同作成者	なし
タイマートリガー	なし	なし	なし	Storage Blob Data Owner⁷

拡張機能トリガーは、 AzureWebJobsStorage 接続が必要とする権限を超えて、デフォルトのストレージアカウントで追加の権限が必要です。
Azure Cosmos DB for NoSQL はデータ操作に Azure RBAC を使いません。代わりに、類似の概念に基づいたカスタムRBACシステムを使用しています。これらのAzure Cosmos DB固有ロールの設定方法を学びたい方は、「Azure Cosmos DB for NoSQLでデータプレーンロールベースのアクセス制御を活用する」をご覧ください。
管理型アイデンティティを使用する場合、トリガーするコンテナはすでに存在している必要があります。
Blob Storageトリガーは、同じストレージアカウント内のキューにポイズンブロブを書き込む権限も必要です。
Service Bus トピックをトリガー元とする場合、ロールの割り当ては Service Bus サブスクリプションリソースに対して有効なスコープを持っている必要があります。トピックのみが含まれている場合は、エラーが発生します。 Azure portal などの一部のクライアントは、ロール割り当てのスコープとして、Service Bus サブスクリプションリソースを公開しません。この場合、代わりにAzure CLIを使うことができます。詳しくは、Azure Service Busの組み込みロールをご覧ください。
権限はデータベース上で直接管理されるアイデンティティに付与されます。詳細については、「管理型アイデンティティへのSQLデータベースアクセスを許可」をご覧ください。
イベントごとに1回の実行を確保するために、ロックは AzureWebJobsStorage 接続を用いてブロブで取得されます。

Durable Functions拡張機能を使う際は、以下のロールが提供する最小限のストレージアカウント権限を付与してください:

Durable Functionsでは、BLOB、キュー、テーブルを使用してアクティビティ関数を調整し、オーケストレーションの状態を維持します。これらすべてにデフォルトでAzureWebJobsStorage接続を使用しますが、Durable Functions拡張設定で別の接続を指定することもできます。

注意

Key Vaultは、現在Microsoft Entra IDをサポートしていない接続とAzure管理IDのみに使ってください。

一部のサービスはまだMicrosoft Entra認証をサポートしていないため、場合によってはアプリがシークレットを必要としている場合があります。このような場合、Azure Key Vaultはシークレットベースの認証の管理ライフサイクルを効率化するのに役立ちます。アプリはKey Vaultを使って、デフォルトのストレージアカウント接続文字列を含む共有秘密をより安全に保存・アクセスできます。接続は共有秘密を使用していますが、Key Vaultは鍵の管理や回転を含め、秘密のセキュリティレベルが高まります。あなたのアプリは、サービス自体がまだ管理されたIDベースの接続をサポートしていなくても、管理されたIDを使ってKey Vaultに接続できます。

Key Vaultを使う場合は、実際の秘密の代わりにKey Vault参照を使って接続のアプリケーション設定を作成してください。詳細については、 Key VaultのSourceアプリ設定をご覧ください。

Key Vaultでの接続を維持する際には以下の点を念頭に置いてください:

キーコンテナー内のキーにアクセスするには、アプリ内の ID にキーコンテナーへのアクセス権を付与する必要があります。
管理IDベースの接続設定をKey Vaultで保存できます。アプリがKey Vaultを使う場合、参照は:などの/またはStorage1:blobServiceUriのキー区切りを使わなければなりません。通常のアプリケーション設定区切り文字を使うと、参照名が正しく解決されません __。

エンドツーエンドの完全な例については、チュートリアルをご覧ください:秘密ではなくIDを使ってAzureサービスに接続する関数アプリを作成してください。

AzureWebJobsStorage設定を設定すれば、接続文字列自体を返すのではなく、接続文字列を含むKey Vault参照を返すように設定できます。方法については、「アプリ設定として Key Vault 参照を使用する」をご覧ください。

Azure Filesは現在マネージドID接続をサポートしていません。この制限があるため、Key Vaultを使ってWEBSITE_AZUREFILESCONNECTIONSTRING設定を確保してください。これは消費プランとプレミアムプランの両方で動的スケーリングに必要です。 Flex Consumptionプランも動的プランで、Azure Filesを使わず、マネージドID接続を完全にサポートしています。

Caution

共有された秘密に直接関わるのは避けましょう。可能な限り、接続に対してより安全な認証方法を使用してください。

管理されたアイデンティティとMicrosoft Entra ID認証を組み合わせることで、秘密の喪失や漏洩のリスクを軽減しましょう。リモートサービスが管理型IDをサポートしていない場合は、少なくとも共有秘密をより安全に管理するAzure Key Vaultを使うべきです。

もしより安全な認証方法が使えない場合、プラットフォームは静止時にアプリケーション設定でデータを暗号化します。共有秘密の使用から、より安全な認証方法にアプリを移行しましょう。

AzureWebJobsStorage設定でデフォルトのストレージアカウントの接続文字列を設定します。この設定は関数アプリを作成する際のデフォルトの接続動作です。

SDKクライアント接続の管理

関数コードでクライアントSDK接続を作成する際は、新しいインスタンスを作成するのではなく、インボーケーション間でクライアントインスタンスを再利用してください。このベストプラクティスはすべてのホスティングプランで遅延を削減し、ソケットの枯渇を防ぎ、リソース効率を向上させます。

クライアントインスタンスの再利用

Azure Functionsアプリケーションでサービス固有クライアントを使用する際は、以下のガイドラインに従ってください:

関数呼び出しごとに新しいクライアントを作成しないでください。
すべての関数呼び出しが再利用可能な単一の共有クライアントを作成してください。
異なる関数が同じサービスを使う場合、ヘルパークラスで単一の共有クライアントを作成することを検討してください。

推奨されるアプローチは言語によって異なります:

依存注入を使ってシングルトンまたはスコープ付きクライアントを登録してください。

各言語の完全なパターンについてはクライアントコード例を参照してください。

消費プランにおける接続制限

注意

本節で述べたハード接続制限は、レガシー消費プランにのみ適用されます。フレックスコンシューマープランは同じサンドボックス環境で運用されておらず、これらの制限を課しません。しかし、最適なパフォーマンスのためにクライアントの再利用は依然として推奨されています。

レガシーのConsumption プランでは、関数アプリはサンドボックス環境で動作し、インスタンスあたりのアウトバウンド接続数を600件(合計1,200件)に制限しています。この制限に達すると、Functionsホストはログに次のメッセージを書き込みます: Host thresholds exceeded: Connections。詳細については、Functions のサービスの制限に関する記事を参照してください。

この制限はインスタンスごとに適用されます。より多くの要求を処理するために、スケールコントローラーによって関数アプリインスタンスが追加されると、インスタンスごとに接続の制限が適用されます。つまり、グローバルな接続制限がなく、すべてのアクティブなインスタンスで600以上のアクティブな接続を持つことができます。

接続問題のトラブルシューティングでは、機能アプリでApplication Insightsが有効になっていることを確認してください。 Application Insights では、実行など、関数アプリのメトリックを表示できます。詳細については、「Application Insights でテレメトリを表示する」を参照してください。

クライアントコードの例

このセクションでは、関数のコードからクライアントを作成および使用するためのベストプラクティスを示します。

HTTPリクエスト

依存注入を使って共有 HttpClient を登録し、すべての関数呼び出しが同じインスタンスを再利用できるようにします。この場合、クライアントを処分する必要はありません。なぜなら、ランタイムがそのライフタイムを管理しているからです。

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddHttpClient();
    }
}

次に関数クラスに IHttpClientFactory または HttpClient を注入します:

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyFunction(HttpClient httpClient, ILogger<MyFunction> logger)
{
    [Function("MyFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var response = await httpClient.GetAsync("https://example.com");
        logger.LogInformation("Response status: {Status}", response.StatusCode);
    }
}

Azure Cosmos DB clients

スタートアップでシングルトンのCosmosClient を登録し、すべての関数が1つの接続を共有しるようにしましょう。 Azure Cosmos DBのドキュメントでは、アプリケーションのライフ期間中シングルトンクライアントを使用することを推奨しています。

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection;

[assembly: FunctionsStartup(typeof(MyNamespace.Startup))]

namespace MyNamespace;

public class Startup : FunctionsStartup
{
    public override void Configure(IFunctionsHostBuilder builder)
    {
        builder.Services.AddSingleton(_ =>
        {
            var connectionString = Environment.GetEnvironmentVariable("CosmosDBConnection");
            return new CosmosClient(connectionString);
        });
    }
}

次に関数クラスに CosmosClient を注入します:

using Microsoft.Azure.Cosmos;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace MyNamespace;

public class MyCosmosFunction(CosmosClient cosmosClient, ILogger<MyCosmosFunction> logger)
{
    private readonly Container _container = cosmosClient.GetContainer("mydb", "mycontainer");

    [Function("MyCosmosFunction")]
    public async Task Run([TimerTrigger("0 */5 * * * *")] TimerInfo timer)
    {
        var item = new { id = "myId", partitionKey = "myPartitionKey", data = "example" };
        await _container.UpsertItemAsync(item, new PartitionKey("myPartitionKey"));
        logger.LogInformation("Item upserted");
    }
}

HTTPリクエスト

共有 HttpClient を静的フィールドとして作成し、同じインスタンスがすべての呼び出しで再利用されるようにします:

import com.microsoft.azure.functions.*;
import com.microsoft.azure.functions.annotation.*;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.URI;

public class MyFunction {
    // Shared HttpClient instance across all invocations
    private static final HttpClient httpClient = HttpClient.newHttpClient();

    @FunctionName("MyFunction")
    public void run(
        @TimerTrigger(name = "timer", schedule = "0 */5 * * * *") String timerInfo,
        final ExecutionContext context
    ) throws Exception {
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create("https://example.com"))
            .build();
        HttpResponse<String> response = httpClient.send(request, 
            HttpResponse.BodyHandlers.ofString());
        context.getLogger().info("Response status: " + response.statusCode());
    }
}

Azure Cosmos DB clients

一度初期化され、すべての呼び出しで共有される静的 CosmosClient を作成します:

import com.azure.cosmos.*;
import com.microsoft.azure.functions.*;
import com.microsoft.azure.functions.annotation.*;

public class MyCosmosFunction {
    private static final CosmosClient cosmosClient = new CosmosClientBuilder()
        .endpoint(System.getenv("COSMOS_API_URL"))
        .key(System.getenv("COSMOS_API_KEY"))
        .buildClient();

    private static final CosmosContainer container = cosmosClient
        .getDatabase("mydb")
        .getContainer("mycontainer");

    @FunctionName("MyCosmosFunction")
    public void run(
        @TimerTrigger(name = "timer", schedule = "0 */5 * * * *") String timerInfo,
        final ExecutionContext context
    ) {
        container.upsertItem(new MyItem("myId", "myPartitionKey", "example"));
        context.getLogger().info("Item upserted");
    }
}

HTTPリクエスト

より良い接続管理のためにネイティブ http.agent クラスを使いましょう。 Functionsで接続制限を設定する推奨方法は、最大数をグローバルに設定することです。

const http = require('http');
http.globalAgent.maxSockets = 200;

特定のリクエスト用にカスタムHTTPエージェントを作成することもできます:

const http = require('http');
const httpAgent = new http.Agent({ maxSockets: 200 });
const options = { agent: httpAgent };
http.request(options, onResponseCallback);

Azure Cosmos DB clients

関数ハンドラの外側に CosmosClient を作成し、すべての呼び出しが単一の接続を共有しるようにします。 Azure Cosmos DBのドキュメントでは、アプリケーションのライフ期間中シングルトンクライアントを使用することを推奨しています。

const { CosmosClient } = require('@azure/cosmos');

const client = new CosmosClient({ 
    endpoint: process.env.COSMOS_API_URL, 
    key: process.env.COSMOS_API_KEY 
});
const container = client.database("MyDatabaseName").container("MyContainerName");

module.exports = async function (context) {
    const { resources: items } = await container.items.readAll().fetchAll();
    context.log(items);
}

HTTPリクエスト

PowerShellでは、関数スクリプト内で静的なシングルトンを簡単に作成できません。代わりに、 profile.ps1 ファイルを使ってワーカーインスタンス内の呼び出し間で永続する共有状態を初期化します:

# profile.ps1 - runs once when the worker starts
# Nothing special needed for HTTP; PowerShell manages connections internally

関数では、接続プーリングを自動的に処理する Invoke-RestMethod を使いましょう:

# run.ps1
param($Timer)

$response = Invoke-RestMethod -Uri "https://example.com" -Method Get
Write-Host "Response received with $($response.Length) characters"

Azure Cosmos DB clients

Azure Cosmos DBの場合、profile.ps1の共有クライアントをAzure SDKを使って初期化します:

# profile.ps1 - runs once per worker instance
if (-not $global:CosmosContainer) {
    $cosmosClient = New-Object Microsoft.Azure.Cosmos.CosmosClient(
        $env:COSMOS_API_URL, $env:COSMOS_API_KEY)
    $global:CosmosContainer = $cosmosClient.GetDatabase("mydb").GetContainer("mycontainer")
}

そして、共有クライアントを関数内で使います:

# run.ps1
param($Timer)

$items = $global:CosmosContainer.ReadContainerAsync().GetAwaiter().GetResult()
Write-Host "Container accessed successfully"

注意

PowerShell関数は.NET Cosmos DBのSDKクラスを使用します。 Microsoft.Azure.Cosmos管理依存関係にrequirements.psd1を追加する必要があります。

HTTPリクエスト

モジュールレベルで共有セッションを作成し、すべての関数呼び出しが同じ接続プールを再利用できるようにします:

import azure.functions as func
import requests

# Shared session reuses TCP connections across invocations
session = requests.Session()
session.mount("https://", requests.adapters.HTTPAdapter(pool_maxsize=200))

app = func.FunctionApp()

@app.timer_trigger(schedule="0 */5 * * * *", arg_name="timer")
def my_function(timer: func.TimerRequest) -> None:
    response = session.get("https://example.com")
    logging.info(f"Response status: {response.status_code}")

Azure Cosmos DB clients

CosmosClientはモジュールレベルで作成し、呼び出しごとに永続します:

import azure.functions as func
from azure.cosmos import CosmosClient
import os

# Singleton client shared across all invocations
cosmos_client = CosmosClient(
    os.environ["COSMOS_API_URL"], 
    credential=os.environ["COSMOS_API_KEY"]
)
container = cosmos_client.get_database_client("mydb").get_container_client("mycontainer")

app = func.FunctionApp()

@app.timer_trigger(schedule="0 */5 * * * *", arg_name="timer")
def my_cosmos_function(timer: func.TimerRequest) -> None:
    items = list(container.read_all_items())
    logging.info(f"Read {len(items)} items")

HTTPリクエスト

モジュールスコープで共有クライアントを作成します。 v4プログラミングモデルでは、モジュールレベルの状態は呼び出し間で持続します:

import { app, InvocationContext, Timer } from "@azure/functions";

// Shared across all invocations in this worker instance
const baseUrl = "https://example.com";

async function myFunction(timer: Timer, context: InvocationContext): Promise<void> {
    // Node.js 18+ native fetch reuses connections automatically
    const response = await fetch(baseUrl);
    context.log(`Response status: ${response.status}`);
}

app.timer("myFunction", {
    schedule: "0 */5 * * * *",
    handler: myFunction,
});

Azure Cosmos DB clients

すべての呼び出しが単一の接続を共有するように、ハンドラーの外側に CosmosClient を作成します:

import { app, InvocationContext, Timer } from "@azure/functions";
import { CosmosClient, Container } from "@azure/cosmos";

const client = new CosmosClient({
    endpoint: process.env.COSMOS_API_URL!,
    key: process.env.COSMOS_API_KEY!,
});
const container: Container = client.database("MyDatabaseName").container("MyContainerName");

async function myCosmosFunction(timer: Timer, context: InvocationContext): Promise<void> {
    const { resources: items } = await container.items.readAll().fetchAll();
    context.log(`Read ${items.length} items`);
}

app.timer("myCosmosFunction", {
    schedule: "0 */5 * * * *",
    handler: myCosmosFunction,
});

SqlClient の接続

関数コードでは、SQL リレーショナルデータベースに接続するために、.NET Framework Data Provider for SQL Server (SqlClient) を使用できます。このプロバイダーはまた、Entity FrameworkのようなADO.NETに依存するデータフレームワークの基盤プロバイダーでもあります。 HttpClient や DocumentClient の接続とは異なり、ADO.NET は接続プールを既定で実装します。ただし、それでも接続を使い果たす可能性があるため、データベースへの接続を最適化する必要があります。詳しくは、「SQL Server の接続プール (ADO.NET)」をご覧ください。

ヒント

Entity Framework などの一部のデータフレームワークは、通常、構成ファイルの ConnectionStrings セクションから接続文字列を取得します。その場合は、関数アプリの設定およびローカルプロジェクトの local.settings.json ファイルの接続文字列コレクションに、SQL データベースの接続文字列を明示的に追加する必要があります。関数コードでSqlConnectionのインスタンスを作成する場合は、他の接続と一緒にアプリケーション設定に接続文字列の値を保存してください。

Azure App Configuration

Azure App Configurationは、アプリケーション設定を一元管理するために使えるAzureサービスです。 App Configurationは階層的なキー-値ペアとバージョン管理をサポートし、Azure Key Vaultと連携してより安全な秘密管理を実現します。詳細については、「Azure App Configuration とは」を参照してください。

セキュリティ向上のために、ファンクションアプリは管理されたアイデンティティとMicrosoft Entra認証を使ってアプリケーションストアの設定にアクセスします。詳細については、「Use App Configuration references for Azure Functions」をご覧ください。

注意

管理型アイデンティティベースの接続の設定をAzure App Configurationで使用する場合、参照はフォーマット:の/または<CONNECTION_NAME_PREFIX>:fullyQualifiedNamespaceのキー区切りを使用しなければなりません。通常のアプリケーション設定区切り文字を使うと、参照名が正しく解決されません __。

Azure Functionsでコネクターを使う — Office 365、Teams、SharePointなどのサービスに接続するには、組み込みのOAuthおよびウェブフック対応を備えたマネージドコネクターを使用します。
なぜ静的クライアントを使うのかについての詳細は、「 Improper Instantiation Antipattern」をご覧ください。
Azure Functions のパフォーマンスに関するその他のヒントについては、「Azure Functions のパフォーマンスと信頼性を最適化する」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-07-21

Azure Functions でリモート サービスへの接続を構成する

接続カテゴリ

認証方法

接続の定義

ID に権限を付与する

SDKクライアント接続の管理

クライアントインスタンスの再利用

消費プランにおける接続制限

クライアント コードの例

SqlClient の接続

Azure App Configuration

関連するコンテンツ

フィードバック

その他のリソース

Azure Functions でリモートサービスへの接続を構成する

クライアントコードの例