Azure Functions 開発者ガイド

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

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

コード プロジェクト

Azure 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 Resource の観点から見ると、関数アプリは Azure App Service のサイト リソース (Microsoft.Web/sites) に相当し、これは Web アプリに相当します。

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

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

• Visual Studio Code を使用する

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

• Azure Portal で次のように実行します

Functions では、ツールベースの発行に加えて、既存の関数アプリにソース コードをデプロイするための他のテクノロジもサポートされています。 詳細については、「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 プロパティを含むトリガー定義があるとします。 接続文字列を含む環境変数の名前には、接続文字列ではなく connection を設定します。 このシークレット アクセス戦略を使うと、アプリの安全性を高め、環境間で接続を簡単に変更できます。 セキュリティをさらに強化するには、ID ベースの接続を使用できます。

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

接続値

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure SDK 環境変数

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

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 を使うように構成することもできます。

AzureWebJobsStorage に 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 はトラブルシューティングに役立つ診断イベントを発生させることができます。 ストレージ テーブル データ共同作成者が割り当てられていない場合は、これらのイベントを書き込めないことを示す警告がログに表示されることがあります。

問題の報告

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

Azure Functions のコードはオープン ソースであり、次の GitHub リポジトリで主要なコンポーネントを見つけることができます。

• Azure Functions

• Azure Functions のホスト

• Azure Functions テンプレート

• Azure WebJobs SDK

• Azure WebJobs SDK 拡張機能

次のステップ

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

• Azure Functions のシナリオ
• Azure Functions をローカルでコーディングしてテストする
• Azure Functions のベスト プラクティス