Azure Functions開発者ガイド

Azure Functionsでは、すべての関数は、好みの言語や開発環境に関係なく、いくつかの主要な技術的概念とコンポーネントを共有します。 この記事は言語固有のものです。 記事の上部で好みの言語を選んでください。

この記事では、Azure Functionsの概要を既に確認していることを前提としています。

コード プロジェクト

Azure Functionsの中核となるのは、functions と呼ばれる 1 つ以上のコード実行ユニットを実装する言語固有のコード プロジェクトです。 関数は、イベント、HTTP 要求への応答、またはスケジュールに基づいて、Azure クラウドで実行されるメソッドです。 Azure Functions コード プロジェクトは、Azureで実行されているときに、プロジェクト内の個々の関数を整理、配置、およびまとめて管理するためのメカニズムと考えてください。 詳しくは、「関数を整理する」をご覧ください。

すべての関数には、関数の開始方法を定義し、関数に入力を提供できるトリガーが必要です。 関数では、必要に応じて、入力バインドと出力バインドを定義できます。 これらのバインドにより、他のサービスへの接続が簡単になり、クライアント SDK を使う必要はありません。 詳細については、「Azure Functions トリガーとバインドの概念を参照してください。

Azure Functionsでは、新しいコード プロジェクトを簡単に作成し、プロジェクトに関数を追加できるようにする、一連の言語固有のプロジェクトおよび関数テンプレートが提供されます。 Azure Functions開発をサポートする任意のツールを使用して、これらのテンプレートを使用して新しいアプリと関数を生成できます。

開発ツール

次のツールは、お好みの言語でAzure Functionsの統合された開発および発行エクスペリエンスを提供します。

• Visual Studio Code

• Azure Functions Core Tools (コマンド プロンプト)

これらのツールは Azure Functions Core Tools と統合されているため、Functions ランタイムを使用してローカル コンピューターで実行およびデバッグできます。 詳細については、「ローカルでのAzure Functionsのコード化とテストを参照してください。

デプロイ

コード プロジェクトをAzureに発行するときは、基本的にプロジェクトを既存の関数アプリ リソースにデプロイします。 関数アプリは、関数を実行するAzureで実行コンテキストを提供します。 そのため、それが関数のデプロイと管理の単位になります。 Azure リソースの観点から見ると、関数アプリは、web アプリと同等のサイト リソース (Microsoft.Web/sites) Azure App Serviceに相当します。

関数アプリは、まとめて管理、デプロイ、スケーリングされる 1 つまたは複数の個々の関数で構成されます。 関数アプリ内のすべての関数が、同じ価格プラン、デプロイ方法、ランタイム バージョンを共有します。 詳しくは、関数アプリの管理方法に関する記事をご覧ください。

関数アプリとその他の必要なリソースがまだAzureに存在しない場合は、プロジェクト ファイルを配置する前に、まずこれらのリソースを作成する必要があります。 これらのリソースは、次のいずれかの方法で作成できます。

• Visual Studio Code

• プログラムで、Azure CLI、Azure PowerShell、ARM テンプレート、または Bicep ファイル

• Azure ポータルで

Functions では、ツールベースの発行に加えて、既存の関数アプリにソース コードをデプロイするための他のテクノロジもサポートされています。 詳細については、「deployment technologies in Azure Functions」を参照してください。

サービスへの接続

クラウドベースのコンピューティング サービスの主要な要件は、他のクラウド サービスとの間でデータの読み取りとデータの書き込みを行うことです。 Functions にはさまざまなバインドが用意されており、クライアント SDK を使わなくても簡単にサービスに接続できます。

Functions で提供されているバインド拡張機能を使う場合でも、クライアント SDK を直接使う場合でも、接続データを安全に格納し、コードには含めないでください。 詳細については、「接続」を参照してください。

バインド

Functions は、多くのAzure サービスと、拡張機能として実装されているいくつかのサードパーティ サービスのバインドを提供します。 詳しくは、サポートされているバインドの詳細な一覧をご覧ください。

バインド拡張機能は入力と出力の両方をサポートでき、多くのトリガーも入力バインドとして機能します。 バインドを使うと、Functions ホストがデータ アクセスを自動的に処理できるようにサービスへの接続を構成できます。 詳細については、「Azure Functions トリガーとバインドの概念を参照してください。

バインドからのエラーに関する問題が発生した場合は、Azure Functions バインド エラー コード ドキュメントを参照してください。

クライアント SDK

Functions には関数コードでのデータ アクセスを簡単にするバインドが用意されていますが、必要に応じて、プロジェクトでクライアント SDK を使って特定のサービスに直接アクセスすることもできます。 関数で必要な基になる SDK の機能がバインド拡張機能でサポートされていない場合は、クライアント SDK を直接使うことが必要になる場合があります。

クライアント SDK を使うときは、バインド拡張機能で使われる接続文字列の格納とアクセスに同じプロセスを使う必要があります。

接続

セキュリティのベスト プラクティスとして、Azure FunctionsはAzure App Serviceのアプリケーション設定機能を利用して、他のサービスに接続するために必要な文字列、キー、およびその他のトークンをより安全に格納するのに役立ちます。 Azureのアプリケーション設定は暗号化されて格納され、実行時に環境変数 namevalue ペアとしてアクセスできます。 接続プロパティを必要とするトリガーとバインドの場合は、実際の接続文字列の代わりにアプリケーション設定名を設定します。 接続文字列またはキーを使用してバインドを直接構成することはできません。

たとえば、 プロパティを含むトリガー定義があるとします。 接続文字列の代わりに、connection を、接続文字列を含む環境変数の名前に設定します。 このシークレット アクセス戦略を使うと、アプリの安全性を高め、環境間で接続を簡単に変更できます。 セキュリティをさらに強化するには、ID ベースの接続を使用できます。

既定の構成プロバイダーでは環境変数を使用します。 これらの変数は、Azureで実行する場合は アプリケーション設定ローカルで開発するときにローカル設定ファイルで定義されます。

接続値

接続名が 1 つの正確な値に解決されると、ランタイムは値を 接続文字列 (通常はシークレットを含む) として識別します。 接続文字列の詳細は、接続先のサービスによって異なります。

ただし、接続名は、複数の構成アイテムのコレクションを参照することもできます。これは、ID ベースの接続を構成する場合に役立ちます。 2 つのアンダースコア で終わる共有プレフィックスを使用して、環境変数をコレクションとして扱うことができます。 このプレフィックスに接続名を設定することによって、グループを参照できます。

たとえば、Azure BLOB トリガー定義の connection プロパティは Storage1 である可能性があります。 という名前の環境変数で構成された単一の文字列値がない限り、 という名前の環境変数を使用して、接続の プロパティを通知できます。 接続のプロパティはサービスによって異なります。 接続を使用するコンポーネントのドキュメントを参照してください。

ID ベースの接続を構成する

Azure Functionsの一部の接続は、シークレットではなく ID を使用するように構成できます。 サポートは、ランタイム バージョンによって、また、接続を使用する拡張機能によって異なります。 接続先のサービスで ID ベースの接続がサポートされている場合でも、Functions で接続文字列が引き続き必要になる場合があります。 マネージド ID を使用して関数アプリを構成するチュートリアルについては、ID ベースの接続を使用した関数アプリの作成に関 するチュートリアルを参照してください。

ID ベースの接続は Functions 4.x でのみサポートされます。バージョン 1.x を使用している場合、最初にバージョン 4.x に移行する必要があります。

次のコンポーネントは、ID ベースの接続をサポートしています。

Azure Functions サービスでホストされている場合、ID ベースの接続では、管理 ID が使用されます。 ユーザー割り当て ID を および プロパティで指定できますが、システム割り当て ID が既定で使用されます。 リソース ID を使用したユーザー割り当て ID の構成はサポートされていないことに注意してください。 ローカル開発などの他のコンテキストで実行する場合は、代わりに開発者 ID が使用されますが、カスタマイズすることもできます。 ID ベースの接続によるローカル開発に関するページをご覧ください。

ID にアクセス許可を付与する

使用されている ID が何であれ、目的のアクションを実行するためのアクセス許可が必要です。 ほとんどのAzure サービスでは、これらのアクセス許可を提供する組み込みロールまたはカスタム ロールを使用して、Azure RBAC でロールを割り当てする必要があります。

各コンポーネントのアクセス許可については、次のいずれかのタブを選んでください。

ID ベース接続に共通のプロパティ

Azure サービスの ID ベースの接続では、次の共通プロパティを受け入れます。ここで、<CONNECTION_NAME_PREFIX> はトリガーまたはバインド定義の connection プロパティの値です。

特定の接続の種類に対して、他のオプションがサポートされている場合があります。 接続を確立するコンポーネントのドキュメントを参照してください。

Azure SDK環境変数

Azure SDKのEnvironmentCredentialに関連付けられている環境変数も設定できますが、これらは従量課金プランのスケーリングのために Functions サービスによって処理されません。 これらの環境変数は 1 つの接続に固有のものではなく、特定の接続に対応するプロパティが設定されていない限り、既定として適用されます。 たとえば、 が設定されている場合、 が構成されているかのように使用されることがあります。 を明示的に設定すると、この既定値がオーバーライドされます。

ID ベースの接続によるローカル開発

関数プロジェクトをローカル環境で実行している場合、上記の構成は、ローカル開発者 ID を使うようランタイムに指示します。 接続では次の場所から順番にトークンを取得しようとします。

• Microsoft アプリケーション間で共有されるローカル キャッシュ
• Visual Studioの現在のユーザー コンテキスト
• Visual Studio Codeの現在のユーザー コンテキスト
• Azure CLIの現在のユーザー コンテキスト

これらのオプションのいずれも成功しなかった場合は、エラーが発生します。

ID には、開発に使用Azureリソースに対するロールの割り当てが既に存在している場合がありますが、これらのロールでは必要なデータ アクセスが提供されない場合があります。 所有者のような管理ロールでは十分ではありません。 各コンポーネントの接続に必要なアクセス許可を再確認し、それらが自分に割り当てられていることを確認してください。

場合によっては、別の ID の使用を指定したい場合があります。 Microsoft Entra サービス プリンシパルのクライアント ID とクライアント シークレットに基づいて、代替 ID を指す接続の構成プロパティを追加できます。 この構成オプションは、Azure Functions サービスでホストされている場合はサポートされません。 ローカル コンピューターで ID とシークレットを使うには、次の追加のプロパティを使って接続を定義します。

Azure BLOB への ID ベースの接続に必要な local.settings.json プロパティの例を次に示します。

{
  "IsEncrypted": false,
  "Values": {
    "<CONNECTION_NAME_PREFIX>__blobServiceUri": "<blobServiceUri>",
    "<CONNECTION_NAME_PREFIX>__queueServiceUri": "<queueServiceUri>",
    "<CONNECTION_NAME_PREFIX>__tenantId": "<tenantId>",
    "<CONNECTION_NAME_PREFIX>__clientId": "<clientId>",
    "<CONNECTION_NAME_PREFIX>__clientSecret": "<clientSecret>"
  }
}

ID を使用してホスト ストレージに接続する

Azure Functions ホストは、AzureWebJobsStorage のストレージ接続セットを使用して、タイマー トリガーのシングルトン実行や既定のアプリ キー ストレージの調整などの主要な動作を有効にします。 この接続は、ID を使うように構成することもできます。

に ID ベースの接続を使うには、次のアプリ設定を構成します。

同様に ID ベース接続に共通のプロパティを設定することもできます。

グローバル Azureの既定の DNS サフィックスとサービス名を使用するストレージ アカウントを使用して AzureWebJobsStorage を構成する場合は、https://<accountName>.[blob|queue|file|table].core.windows.net 形式に従って、代わりに AzureWebJobsStorage__accountName をストレージ アカウントの名前に設定できます。 各ストレージ サービスのエンドポイントは、このアカウントに対して推測されます。 ストレージ アカウントがソブリン クラウドにある場合、またはカスタム DNS を持っている場合、これは機能しません。

実行時に "AzureWebJobsStorage" のストレージ アカウントへのアクセスを提供するロールの割り当てを作成する必要があります。 所有者のような管理ロールでは十分ではありません。 ストレージ BLOB データ所有者ロールでは、Functions ホスト ストレージの基本ニーズが対処されます。ランタイムでは、BLOB の読み取りと書き込みの両方が必要であり、また、コンテナーを作成できる必要があります。 いくつかの拡張機能では、この接続を BLOB、キュー、テーブルの既定の場所として使用するため、これらの使用により、次の表に示されている要件が追加される可能性があります。 他の目的で "AzureWebJobsStorage" を使用する場合は、他のアクセス許可が必要になる場合もあります。

¹ 一部の種類の問題では、Azure Functions問題によって関数アプリが起動できない場合でも、トラブルシューティングに役立つ診断イベントを発生させることができます。 ストレージ テーブル データ共同作成者が割り当てられていない場合は、これらのイベントを書き込めないことを示す警告がログに表示されることがあります。

別のテナント内のリソースへの接続

関数が別のMicrosoft Entra テナント内のリソースに接続する必要がある場合は、接続で federated ID 資格情報を使用する必要があります。 これには、ユーザー割り当てマネージド ID とマルチテナント Entra ID アプリの登録が必要です。 テナント間接続にシステム割り当てマネージド ID を使用することはできません。

テナント間 ID ベースの接続を構成するには、まず、次の手順を使用してインフラストラクチャを設定する必要があります。

1. 関数アプリがデプロイされているテナントで、 新しいユーザー割り当てマネージド ID を作成します。
2. その ID を関数アプリに割り当てます 。
3. 同じテナントで、アクセスするテナント間リソースを表す マルチテナント Entra アプリ登録を作成 します。
4. アプリ登録のフェデレーション ID 資格情報としてマネージド ID を追加します。
5. リソースがデプロイされているテナントで、 アプリ登録用のエンタープライズ アプリケーションを作成します。
6. リソースにアクセスするためのアクセス許可をエンタープライズ アプリケーションに割り当てます。

テナント間 ID ベースの接続では、次のプロパティが使用されます。ここで、 はトリガーまたはバインド定義の プロパティの値です。

1 が に設定されている場合、接続では、 、 、または のいずれかを正確に指定する必要があります。

これは、Azure SDK によって JSON 形式でドキュメント化されます。

問題の報告

オープン ソース リポジトリ

Azure Functionsのコードはオープンソースされており、次のGitHub リポジトリに主要なコンポーネントがあります。

• Azure Functions

• Azure Functions host

• Azure Functions テンプレート

• Azure WebJobs SDK

• Azure WebJobs SDK Extensions

次のステップ

詳細については、次のリソースを参照してください。

• Azure Functions シナリオ
• ローカルでAzure Functionsをコード化してテストします
• Azure Functions