Azure Functions 開発者ガイド

Azure Functions の特定の関数は、使用する言語またはバインドに関係なく、いくつかの中核となる技術的な概念とコンポーネントを共有します。 特定の言語またはバインド固有の詳細を学習する前に、それらすべてに当てはまるこの概要をお読みください。

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

関数のコード

関数 は Azure Functions の主要な概念です。 関数には 2 つの重要な要素が含まれています。さまざまな言語で記述できるコードと、いくつかの構成、つまり function.json ファイルです。 コンパイル式の言語の場合、この構成ファイルはコード内の注釈から自動的に生成されます。 スクリプト言語の場合は、構成ファイルを自分で用意する必要があります。

function.json ファイルには、関数のトリガー、バインド、その他の構成設定を定義します。 すべての関数には、1 つだけトリガーがあります。 ランタイムはこの構成ファイルを使用して、監視対象のイベントを特定し、関数の実行との間でデータを渡したりデータを受け取ったりする方法を判断します。 以下に function.json ファイルの例を示します。

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

詳しくは、「Azure Functions でのトリガーとバインドの概念」をご覧ください。

bindings プロパティで、トリガーとバインドの両方を構成します。 各バインドは、いくつかの一般的な設定と、バインドの特定の種類に固有の設定を共有します。 すべてのバインドには次の設定が必要です。

プロパティ Type 説明
type バインドの名前。

たとえば、「 queueTrigger 」のように入力します。
string
方向 in, out string バインドが関数への受信データか、関数からの送信データかを示します。
name 関数識別子。

たとえば、「 myQueue 」のように入力します。
string 関数のバインドされたデータに使用される名前。 C# の場合は引数の名前です。JavaScript の場合はキー/値リストのキーです。

関数アプリ

関数アプリからは、関数が実行される、Azure における実行コンテキストが提供されます。 そのため、これが関数のデプロイと管理の単位となります。 関数アプリは、まとめて管理、デプロイ、およびスケールされる 1 つまたは複数の個々の関数で構成されます。 関数アプリ内のすべての関数は、同じ料金プラン、デプロイ方法、およびランタイム バージョンを共有します。 関数を整理し、まとめて管理する方法として関数アプリを考えてください。 詳しくは、関数アプリの管理方法に関する記事をご覧ください。

注意

関数アプリ内のすべての関数は、同じ言語で作成する必要があります。 Azure Functions ランタイムの以前のバージョンでは、これは必須ではありませんでした。

フォルダー構造

特定の関数アプリ内のすべての関数のコードは、ホスト構成ファイルを含むルート プロジェクト フォルダーにあります。 host.json ファイルにはランタイム固有の構成が含まれています。このファイルは関数アプリのルート フォルダーにあります。 bin フォルダーには、関数アプリに必要なパッケージやその他のライブラリ ファイルが含まれています。 関数アプリが必要とする特定のフォルダー構造は、言語によって異なります。

Functions ランタイムのバージョン 2.x およびそれ以上では、関数アプリ内のすべての関数が同じ言語スタックを共有する必要があります。

上記は、関数アプリの既定の (そして推奨される) フォルダー構造です。 関数のコードのファイルの場所を変更するには、function.json ファイルの scriptFile セクションを変更します。 また、パッケージ デプロイを使用して Azure の関数アプリにプロジェクトをデプロイすることもお勧めします。 継続的インテグレーションとデプロイや Azure DevOps など、既存のツールを使用することもできます。

注意

パッケージを手動でデプロイする場合は、必ず host.json ファイルと関数フォルダーを直接 wwwroot フォルダーにデプロイします。 デプロイに wwwroot フォルダーを含めないでください。 そうしないと、wwwroot\wwwroot フォルダーができてしまいます。

ローカル ツールの使用と公開

関数アプリは、Visual StudioVisual Studio CodeIntelliJEclipseAzure Functions Core Tools など、さまざまなツールを利用して作成し、公開できます。 詳細については、「Azure Functions をローカルでコーディングしてテストする」を参照してください。

Azure portal で関数を編集する方法

Azure portal に組み込まれている関数エディターを使用すると、コードと function.json ファイルを直接インラインで更新できます。 これは、軽微な変更や概念実証の場合にのみお勧めします。ベスト プラクティスは、VS Code などのローカル開発ツールを使うことです。

並列実行

シングル スレッドの関数ランタイムが処理できるより速く複数のトリガー イベントが発生する場合、ランタイムは関数を並列で複数回呼び出す場合があります。 関数アプリが従量課金ホスティング プランを使用している場合、関数アプリは自動的にスケールアウトできます。 アプリが従量課金ホスティング プランと標準の App Service ホスティング プランのどちらで実行されていても、関数アプリの各インスタンスは、複数の同時関数呼び出しを、複数のスレッドを使用して並列に処理します。 各関数アプリ インスタンスでの同時関数呼び出しの最大数は、使用されるトリガーの種類と、関数アプリ内の他の関数によって使用されるリソースに応じて異なります。

Functions ランタイムのバージョン管理

FUNCTIONS_EXTENSION_VERSION アプリ設定を使用して、Functions ランタイムのバージョンを構成できます。 たとえば、"~3" の値は、関数アプリがそのメジャー バージョンとして 3.x を使用することを示します。 関数アプリは、リリースされたときにそれぞれの新しいマイナー バージョンにアップグレードされます。 お使いの関数アプリの正確なバージョンを表示する方法など、詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」をご覧ください。

リポジトリ

Azure Functions のコードはオープン ソースであり、GitHub リポジトリに保存されています。

バインド

サポートされるすべてのバインドを次の表に示します。

この表は、Azure Functions のメジャー バージョンのランタイムでサポートされているバインディングを示しています。

種類 1.x 2.x 以降1 トリガー 入力 Output
Blob Storage
Azure Cosmos DB
Dapr3
Event Grid
Event Hubs
HTTP と Webhook
IoT Hub
Kafka2
Mobile Apps
Notification Hubs
Queue Storage
RabbitMQ2
SendGrid
Service Bus
SignalR
Table Storage
Timer
Twilio

1 バージョン 2.x ランタイム以降では、HTTP と Timer を除くすべてのバインドを登録する必要があります。 「バインディング拡張機能を登録する」を参照してください。

2 トリガーは従量課金プランでサポートされていません。 ランタイム駆動のトリガーが必要です。

3 Kubernetes、IoT Edge、およびその他の自己ホスト型モードでのみサポートされます。

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

接続

関数プロジェクトでは、接続情報を構成プロバイダーからの名前で参照しています。 接続の詳細を直接受け入れないため、環境間で変更できます。 たとえば、トリガー定義に connection プロパティが含まれるとします。 これは接続文字列が参照されている場合がありますが、接続文字列を function.json に直接設定することはできません。 代わりに、connection を、接続文字列を含む環境変数の名前に設定します。

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

接続値

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

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

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

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

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

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

接続元 サポートされているプラン 詳細情報
Azure BLOB のトリガーとバインディング All 拡張機能バージョン 5.0.0 以降
Azure キューのトリガーとバインディング All 拡張機能バージョン 5.0.0 以降
Azure Event Hubs のトリガーとバインディング All 拡張機能バージョン 5.0.0 以降
Azure Service Bus のトリガーとバインディング All 拡張機能バージョン 5.0.0 以降
Azure Cosmos DB のトリガーとバインディング - プレビュー エラスティック Premium 拡張機能バージョン 4.0.0-preview1 以降
ホスト (必須) ストレージ ("AzureWebJobsStorage") - プレビュー All ID を使用してホスト ストレージに接続する

注意

ID ベースの接続は、Durable Functions ではサポートされません。

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

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

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

重要

すべてのコンテキストに必要ではない一部のアクセス許可がターゲット サービスによって公開される場合があります。 可能であれば、最小限の特権の原則 に従い、必要な特権だけを ID に付与します。 たとえば、アプリがデータ ソースからの読み取りのみを行う必要がある場合は、読み取りアクセス許可のみを持つロールを使用します。 サービスへの書き込みも可能なロールを割り当てることは、読み取り操作に対するアクセス許可が過剰になるため、不適切です。 同様に、ロールの割り当てが、読み取る必要のあるリソースだけに限定されていることを確認する必要があります。

以下のタブを選択して、各コンポーネントのアクセス許可について学習します。

実行時に BLOB コンテナーへのアクセスを提供するロールの割り当てを作成する必要があります。 所有者のような管理ロールでは十分ではありません。 次の表は、通常の操作で Blob Storage の拡張機能を使用するときに推奨される組み込みロールを示しています。 アプリケーションでは、記述したコードに基づいて追加のアクセス許可が必要になる場合があります。

[バインドの種類] 組み込みロールの例
トリガー ストレージ BLOB データ所有者1
入力バインド ストレージ BLOB データ閲覧者
出力バインド ストレージ BLOB データ所有者

1 一部の構成では、BLOB トリガーにストレージ キュー データ共同作成者が追加で必要になる場合があります。

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

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

プロパティ 環境変数テンプレート 説明
トークン資格情報 <CONNECTION_NAME_PREFIX>__credential 接続のためにトークンを取得する方法を定義します。 "managedidentity" に設定する必要がある場合の、ユーザー割り当て ID の指定時にのみ推奨されます。 これは Azure Functions サービスでホストされるときにのみ有効です。
クライアント ID <CONNECTION_NAME_PREFIX>__clientId credential が "managedidentity" に設定されると、このプロパティによって、トークンの取得時に使用されるユーザー割り当て ID が指定されます。 このプロパティは、アプリケーションに割り当てられたユーザー割り当て ID に相当するクライアント ID を受け取ります。 指定されていない場合、システム割り当て ID が使用されます。 このプロパティは、credential を設定しないとき、ローカル開発シナリオで異なる方法で使用されます。

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

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

注意

IDベースの接続を使用したローカル開発には、 Azure Functions Core Toolsの更新バージョンが必要です。 func -v コマンドを入力することによって、現在インストールされているバージョンを確認できます。 Functions v3 の場合は、バージョン以降を使用 3.0.3904 します。 Functions v4 の場合は、バージョン以降を使用 4.0.3904 します。

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

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

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

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

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

プロパティ 環境変数テンプレート 説明
テナント ID <CONNECTION_NAME_PREFIX>__tenantId Azure Active Directory のテナント (ディレクトリ) ID。
クライアント ID <CONNECTION_NAME_PREFIX>__clientId テナント内のアプリの登録のクライアント (アプリケーション) ID。
クライアント シークレット <CONNECTION_NAME_PREFIX>__clientSecret アプリの登録で生成されたクライアント シークレット。

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

注意事項

Functions の他のコンポーネントは、既定の動作では "AzureWebJobsStorage" に依存します。 この種の接続をサポートしていない古いバージョンの拡張機能 (Azure BLOB および Event Hubs のトリガーとバインディングを含む) を使用している場合は、それを ID ベースの接続に移動させないでください。 同様に、 AzureWebJobsStorage は、Linux でのサーバー側ビルドの使用時に配置アーティファクトに使用されます。これを有効にする場合は、 外部デプロイパッケージを使用してデプロイする必要があります。

また、一部のアプリでは、トリガー、バインディング、関数コード内の他のストレージ接続に "AzureWebJobsStorage" が再利用されます。 接続文字列からこの接続を変更する前に、"AzureWebJobsStorage" のすべての用途で ID ベースの接続形式を使用できるようにしてください。

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

設定 説明 値の例
AzureWebJobsStorage__blobServiceUri HTTPS スキームを使用する、ストレージ アカウントの BLOB サービスのデータ プレーン URI。 https://<storage_account_name>.blob.core.windows.net
AzureWebJobsStorage__queueServiceUri HTTPS スキームを使用する、ストレージ アカウントのキュー サービスのデータ プレーン URI。 https://<storage_account_name>.queue.core.windows.net

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

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

設定 説明 値の例
AzureWebJobsStorage__accountName ストレージ アカウントのアカウント名。アカウントがソブリン クラウドに存在せず、カスタム DNS が与えられていない場合にのみ有効。 <storage_account_name>

実行時に "AzureWebJobsStorage" のストレージ アカウントにアクセスできるようにするロールの割り当てを作成する必要があります。 所有者のような管理ロールでは十分ではありません。 ストレージ BLOB データ所有者ロールでは、Functions ホスト ストレージの基本ニーズが対処されます。ランタイムでは、BLOB の読み取りと書き込みの両方が必要であり、また、コンテナーを作成できる必要があります。 BLOB トリガーの使用時のように、[ストレージ キュー データ共同作成者]も必要になることがあります。 他の目的で "AzureWebJobsStorage" を使用する場合は、追加のアクセス許可が必要な場合があります。

問題の報告

Item 説明 Link
ランタイム スクリプト ホスト、トリガー、バインド、言語のサポート 問題のファイリング
テンプレート 作成テンプレートに関するコードの問題 問題のファイリング
ポータル ユーザー インターフェイスまたはエクスペリエンスの問題 問題のファイリング

次のステップ

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