Azure Functions の Azure Blob Storage トリガー

[アーティクル]
05/14/2024

Blob ストレージトリガーは、新しいまたは更新された BLOB が検出されたときに関数を開始します。 BLOB の内容は、関数への入力として提供されます。

ヒント

ストレージコンテナー内の BLOB に対する変更に基づいて関数コードを実行するには、いくつかの方法があります。 BLOB ストレージトリガーを使用する場合は、ポーリングベースのトリガー (この記事で参照) とイベントベースの 2 つの実装が提供されることに注意してください。 event ベースの実装を使用することをお勧めします他の実装よりも待機時間が短くなります。また、Flex 従量課金プランでは、イベントベースの Blob Storage トリガーのみがサポートされます。

BLOB ストレージトリガーの 2 つの実装の違いと、その他のトリガーオプションの詳細については、「 BLOB を使用した作業を参照してください。

セットアップと構成の詳細については、概要に関するページをご覧ください。

重要

この記事では、タブを使用して、Node.js プログラミングモデルの複数のバージョンに対応しています。 v4 モデルは一般提供されており、JavaScript と TypeScript の開発者にとって、より柔軟で直感的なエクスペリエンスが得られるように設計されています。 v4 モデルの動作の詳細については、Azure Functions Node.js 開発者ガイドを参照してください。 v3 と v4 の違いの詳細については、移行ガイドを参照してください。

Azure Functions では、Python の 2 つのプログラミングモデルがサポートされています。バインドを定義する方法は、選択したプログラミングモデルによって異なります。

Python v2 プログラミングモデルでは、Python 関数コードでデコレーターを使用してバインドを直接定義できます。詳細については、「Python 開発者ガイド」を参照してください。

この記事は、両方のプログラミングモデルをサポートしています。

例

A C# 関数は、次の C# モードのいずれかを使用して作成できます。

分離されたワーカーモデル: ランタイムから分離されたワーカープロセスで実行されるコンパイル済みの C# 関数。分離ワーカープロセスは、LTS および非 LTS バージョンの .NET および .NET Framework で実行されている C# 関数をサポートするために必要です。分離ワーカープロセス関数の拡張機能では、Microsoft.Azure.Functions.Worker.Extensions.* 名前空間が使用されます。
インプロセスモデル: Functions ランタイムと同じプロセスで実行されるコンパイル済みの C# 関数。このモデルの一部では、主に C# ポータルの編集のためにサポートされている C# スクリプトを使用して Functions を実行できます。インプロセス関数の拡張機能では、Microsoft.Azure.WebJobs.Extensions.* 名前空間が使用されます。

重要

インプロセスモデルのサポートは 2026 年 11 月 10 日に終了します。完全なサポートのために、分離ワーカーモデルにアプリを移行することを強くお勧めします。

分離ワーカーモデル
インプロセスモデル

次の例は C# 関数であり、分離ワーカープロセスで実行され、BLOB 入力と BLOB 出力の両方の BLOB バインドを持つ BLOB トリガーを使用します。この関数は、test-sample-trigger コンテナーの BLOB の作成によってトリガーされます。 test-samples-input コンテナーからテキストファイルを読み取り、トリガーされたファイルの名前に基づいて、出力コンテナーに新しいテキストファイルを作成します。

public static class BlobFunction
{
    [Function(nameof(BlobFunction))]
    [BlobOutput("test-samples-output/{name}-output.txt")]
    public static string Run(
        [BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
        [BlobInput("test-samples-input/sample1.txt")] string myBlob,
        FunctionContext context)
    {
        var logger = context.GetLogger("BlobFunction");
        logger.LogInformation("Triggered Item = {myTriggerItem}", myTriggerItem);
        logger.LogInformation("Input Item = {myBlob}", myBlob);

        // Blob Output
        return "blob-output content";
    }
}

次の例は、samples-workitems コンテナーで BLOB が追加または更新されたときにログを書き込む C# 関数を示しています。

[FunctionName("BlobTriggerCSharp")]        
public static void Run([BlobTrigger("samples-workitems/{name}")] Stream myBlob, string name, ILogger log)
{
    log.LogInformation($"C# Blob trigger function Processed blob\n Name:{name} \n Size: {myBlob.Length} Bytes");
}

BLOB トリガーパス samples-workitems/{name} の文字列 {name} は、トリガーする BLOB のファイル名にアクセスするために関数コードで使用できる、{name}を作成します。詳しくは、後述の「BLOB 名のパターン」をご覧ください。

BlobTrigger 属性の詳細については、「属性」を参照してください。

この関数は、myblob コンテナーで BLOB が追加または更新されたときにログを書き込みます。

@FunctionName("blobprocessor")
public void run(
  @BlobTrigger(name = "file",
               dataType = "binary",
               path = "myblob/{name}",
               connection = "MyStorageAccountAppSetting") byte[] content,
  @BindingName("name") String filename,
  final ExecutionContext context
) {
  context.getLogger().info("Name: " + filename + " Size: " + content.length + " bytes");
}

モデル v4
モデル v3

次の例は、BLOB トリガーの TypeScript コードを示しています。関数は、samples-workitems コンテナーで BLOB が追加または更新されたときにログを書き込みます。

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

export async function storageBlobTrigger1(blob: Buffer, context: InvocationContext): Promise<void> {
    context.log(
        `Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
    );
}

app.storageBlob('storageBlobTrigger1', {
    path: 'samples-workitems/{name}',
    connection: 'MyStorageAccountAppSetting',
    handler: storageBlobTrigger1,
});

モデル v4
モデル v3

次の例は、BLOB トリガーの JavaScript コードを示しています。関数は、samples-workitems コンテナーで BLOB が追加または更新されたときにログを書き込みます。

const { app } = require('@azure/functions');

app.storageBlob('storageBlobTrigger1', {
    path: 'samples-workitems/{name}',
    connection: 'MyStorageAccountAppSetting',
    handler: (blob, context) => {
        context.log(
            `Storage blob function processed blob "${context.triggerMetadata.name}" with size ${blob.length} bytes`
        );
    },
});

次の例は、function.json ファイルの BLOB トリガーバインドと、バインドを使用する JavaScript コードを示しています。関数は、samples-workitems コンテナーで BLOB が追加または更新されたときにログを書き込みます。

function.json ファイルを次に示します。

{
    "disabled": false,
    "bindings": [
        {
            "name": "myBlob",
            "type": "blobTrigger",
            "direction": "in",
            "path": "samples-workitems/{name}",
            "connection":"MyStorageAccountAppSetting"
        }
    ]
}

function.json ファイルプロパティについて詳しくは、これらのプロパティについて説明している「構成」セクションをご覧ください。

JavaScript コードを次に示します。

module.exports = async function(context) {
    context.log('Node.js Blob trigger function processed', context.bindings.myBlob);
};

次の例は、source BLOB ストレージコンテナーにファイルが追加されたときに実行される関数を作成する方法を示しています。

関数構成ファイル (function.json) には、type が blobTrigger で、direction が in に設定されたバインドが含まれています。

{
  "bindings": [
    {
      "name": "InputBlob",
      "type": "blobTrigger",
      "direction": "in",
      "path": "source/{name}",
      "connection": "MyStorageAccountConnectionString"
    }
  ]
}

run.ps1 ファイルに関連するコードを次に示します。

param([byte[]] $InputBlob, $TriggerMetadata)

Write-Host "PowerShell Blob trigger: Name: $($TriggerMetadata.Name) Size: $($InputBlob.Length) bytes"

この例では、SDK の種類を使用して、Blob Storage トリガーによって提供される基になる BlobClient オブジェクトに直接アクセスします。

import logging

import azure.functions as func
import azurefunctions.extensions.bindings.blob as blob

app = func.FunctionApp(http_auth_level=func.AuthLevel.ANONYMOUS)
@app.blob_trigger(
    arg_name="client", path="PATH/TO/BLOB", connection="AzureWebJobsStorage"
)
def blob_trigger(client: blob.BlobClient):
    logging.info(
        f"Python blob trigger function processed blob \n"
        f"Properties: {client.get_blob_properties()}\n"
        f"Blob content head: {client.download_blob().read(size=1)}"
    )

他の SDK の種類の使用例については、 ContainerClient と StorageStreamDownloader のサンプルを参照してください。

プロジェクトで SDK 型バインドを有効にする方法など、詳細については、「 SDK 型バインドを参照してください。

この例では、受信 BLOB メタデータからの情報をログに記録します。

import logging
import azure.functions as func

app = func.FunctionApp()

@app.function_name(name="BlobTrigger1")
@app.blob_trigger(arg_name="myblob", 
                  path="PATH/TO/BLOB",
                  connection="CONNECTION_SETTING")
def test_function(myblob: func.InputStream):
   logging.info(f"Python blob trigger function processed blob \n"
                f"Name: {myblob.name}\n"
                f"Blob Size: {myblob.length} bytes")

関数は、samples-workitems コンテナーで BLOB が追加または更新されたときにログを書き込みます。 function.json ファイルを次に示します。

{
    "scriptFile": "__init__.py",
    "disabled": false,
    "bindings": [
        {
            "name": "myblob",
            "type": "blobTrigger",
            "direction": "in",
            "path": "samples-workitems/{name}",
            "connection":"MyStorageAccountAppSetting"
        }
    ]
}

function.json ファイルプロパティについて詳しくは、これらのプロパティについて説明している「構成」セクションをご覧ください。

Python コードを次に示します。

import logging
import azure.functions as func


def main(myblob: func.InputStream):
    logging.info('Python Blob trigger function processed %s', myblob.name)

属性

インプロセスと分離されたワーカープロセスの C# ライブラリはどちらも、BlobAttribute 属性を使って関数を定義します。 C# スクリプトでは、C# スクリプトガイドで説明されているように、代わりに function.json 構成ファイルを使用します。

この属性のコンストラクターは、次のパラメーターを受け取ります。

パラメーター	説明
BlobPath	BLOB へのパス。
接続	Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。「接続」を参照してください。
Access (アクセス)	読み取りと書き込みのどちらを行うかを示します。
ソース	トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには `BlobTriggerSource.EventGrid` を使用します。これにより、待機時間が大幅に短縮されます。既定値は `BlobTriggerSource.LogsAndContainerScan` です。これは、標準のポーリングメカニズムを使用してコンテナー内の変更を検出します。

分離ワーカーモデル
インプロセスモデル

メソッドシグネチャでの BlobTrigger 属性を次に示します。

[Function(nameof(BlobFunction))]
[BlobOutput("test-samples-output/{name}-output.txt")]
public static string Run(
    [BlobTrigger("test-samples-trigger/{name}")] string myTriggerItem,
    [BlobInput("test-samples-input/sample1.txt")] string myBlob,
    FunctionContext context)

C# クラスライブラリの属性のコンストラクターは、監視するコンテナーを示すパス文字列と、必要に応じて BLOB 名のパターンを受け取ります。次に例を示します。

[FunctionName("ResizeImage")]
public static void Run(
  [BlobTrigger("sample-images/{name}")] Stream image,
  [Blob("sample-images-md/{name}", FileAccess.Write)] Stream imageSmall)
{
  ....
}

属性は Connection プロパティを受け取りますが、 Connection を使用してストレージアカウント接続を指定することもできます。これは、ライブラリ内の他の関数とは異なるストレージアカウントを使用する必要がある場合に実行できます。コンストラクターは、ストレージ接続文字列を含むアプリ設定の名前を受け取ります。属性は、パラメーター、メソッド、またはクラスレベルで適用できます。次の例では、クラスレベルとメソッドレベルを示します。

[StorageAccount("ClassLevelStorageAppSetting")]
public static class AzureFunctions
{
    [FunctionName("StorageTrigger")]
    [StorageAccount("FunctionLevelStorageAppSetting")]
    public static void Run( //...
{
    ...
}

使用するストレージアカウントは、次の順序で決定されます。

トリガーまたはバインド属性の Connection プロパティ。
トリガーまたはバインド属性と同じパラメーターに適用された StorageAccount 属性。
関数に適用される StorageAccount 属性。
クラスに適用される StorageAccount 属性。
AzureWebJobsStorage アプリケーション設定で定義されている、関数アプリの既定のストレージアカウント。

ローカルで開発する場合は、Values コレクション内の local.settings.json ファイルにアプリケーション設定を追加します。

デコレーター

Python v2 プログラミングモデルにのみ適用されます。

デコレーターを使用して定義された Python v2 関数の場合、blob_trigger デコレーターの次のプロパティによって Blob Storage トリガーが定義されます。

プロパティ	説明
`arg_name`	関数シグネチャのパラメーター名を宣言します。関数がトリガーされると、このパラメーターの値にはキューメッセージの内容が含められます。
`path`	監視するコンテナー。 BLOB 名パターンの場合があります。
`connection`	ストレージアカウントの接続文字列。
`source`	トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには `EventGrid` を使用します。これにより、待機時間が大幅に短縮されます。既定値は `LogsAndContainerScan` です。これは、標準のポーリングメカニズムを使用してコンテナー内の変更を検出します。

function.json を使用して定義された Python 関数については、[構成] セクションを参照してください。

注釈

@BlobTrigger 属性を使用すると、関数をトリガーした BLOB にアクセスできます。詳細については、「トリガー - 例」を参照してください。トリガーイベントのソースを設定するには、source プロパティを使用します。 Event Grid ベースの BLOB トリガーには EventGrid を使用します。これにより、待機時間が大幅に短縮されます。既定値は LogsAndContainerScan です。これは、標準のポーリングメカニズムを使用してコンテナー内の変更を検出します。 |

構成

"Python v1 プログラミングモデルにのみ適用されます。"

モデル v4
モデル v3

次の表では、app.storageBlob() メソッドに渡される options オブジェクトに対して設定できるプロパティについて説明します。

プロパティ	説明
path	監視するコンテナー。 BLOB 名パターンの場合があります。
connection	Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。「接続」を参照してください。
ソース	トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには `EventGrid` を使用します。これにより、待機時間が大幅に短縮されます。既定値は `LogsAndContainerScan` です。これは、標準のポーリングメカニズムを使用してコンテナー内の変更を検出します。

次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。

プロパティ	説明
type	`blobTrigger` に設定する必要があります。このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。
direction	`in` に設定する必要があります。このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。例外は、使用方法のセクションに記載しています。
name	関数コード内の BLOB を表す変数の名前。
path	監視するコンテナー。 BLOB 名パターンの場合があります。
connection	Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。「接続」を参照してください。
ソース	トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには `EventGrid` を使用します。これにより、待機時間が大幅に短縮されます。既定値は `LogsAndContainerScan` です。これは、標準のポーリングメカニズムを使用してコンテナー内の変更を検出します。

次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。

function.json のプロパティ	説明
type	`blobTrigger` に設定する必要があります。このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。
direction	`in` に設定する必要があります。このプロパティは、Azure Portal でトリガーを作成するときに自動で設定されます。例外は、使用方法のセクションに記載しています。
name	関数コード内の BLOB を表す変数の名前。
path	監視するコンテナー。 BLOB 名パターンの場合があります。
connection	Azure Blob への接続方法を指定するアプリ設定または設定コレクションの名前。「接続」を参照してください。
ソース	トリガーイベントのソースを設定します。 Event Grid ベースの BLOB トリガーには `EventGrid` を使用します。これにより、待機時間が大幅に短縮されます。既定値は `LogsAndContainerScan` です。これは、標準のポーリングメカニズムを使用してコンテナー内の変更を検出します。

完全な例については、セクションの例を参照してください。

Metadata

BLOB トリガーは、いくつかのメタデータプロパティを提供します。これらのプロパティは、他のバインドのバインド式の一部として、またはコードのパラメーターとして使用できます。これらの値は、CloudBlob 型と同じセマンティクスを持ちます。

プロパティ	タイプ	説明
`BlobTrigger`	`string`	トリガーする BLOB のパス。
`Uri`	`System.Uri`	プライマリロケーションの BLOB URI。
`Properties`	BlobProperties	Blob のシステムプロパティ。
`Metadata`	`IDictionary<string,string>`	BLOB のユーザー定義メタデータ。

次の例では、コンテナーを含むトリガーとなる BLOB へのパスをログに記録しています。

public static void Run(string myBlob, string blobTrigger, ILogger log)
{
    log.LogInformation($"Full blob path: {blobTrigger}");
}

Metadata

BLOB トリガーは、いくつかのメタデータプロパティを提供します。これらのプロパティは、他のバインドのバインド式の一部として、またはコードのパラメーターとして使用できます。

プロパティ	説明
`blobTrigger`	トリガーする BLOB のパス。
`uri`	プライマリロケーションの BLOB URI。
`properties`	Blob のシステムプロパティ。
`metadata`	BLOB のユーザー定義メタデータ。

モデル v4
モデル v3

次の例に示すように、指定した context オブジェクトの triggerMetadata プロパティからメタデータを取得できます。この場合、コンテナーを含め、トリガーとなる BLOB (blobTrigger) へのパスがログに記録されます。

context.log(`Full blob path: ${context.triggerMetadata.blobTrigger}`);

次の例に示すように、指定した context オブジェクトの bindingData プロパティからメタデータを取得できます。この場合、コンテナーを含め、トリガーとなる BLOB (blobTrigger) へのパスがログに記録されます。

module.exports = async function (context, myBlob) {
    context.log("Full blob path:", context.bindingData.blobTrigger);
};

Metadata

メタデータは、$TriggerMetadata パラメーターを介して使用できます。

使用

BLOB トリガーでサポートされるバインドの種類は、拡張機能パッケージのバージョンと、関数アプリで使用される C# モダリティによって異なります。

分離ワーカーモデル
インプロセスモデル

BLOB トリガーは、次の型にバインドできます。

Type	説明
`string`	BLOB コンテンツを表す文字列。 BLOB コンテンツが単純なテキストのときに使用します。
`byte[]`	BLOB コンテンツのバイト数。
JSON シリアル化可能な型	BLOB に JSON データが含まれているとき、Functions は JSON データを単純な従来の CLR オブジェクト (POCO) 型に逆シリアル化しようとします。
Stream¹	BLOB コンテンツの入力ストリーム。
BlobClient¹、 BlockBlobClient¹、 PageBlobClient¹、 AppendBlobClient¹、 BlobBaseClient¹	BLOB に接続されているクライアント。この型のセットには BLOB の処理に対する最大限の制御機能が備わっています。接続に十分なアクセス許可がある場合は、BLOB への書き戻しに使用できます。

¹ これらの型を使用するには、Microsoft.Azure.Functions.Worker.Extensions.Storage.Blobs 6.0.0 以降と SDK 型バインドの一般的な依存関係に関する記事を参照する必要があります。

string または Byte[] へのバインドが推奨されるのは、BLOB のサイズが小さい場合のみです。これが推奨されるのは、BLOB 全体の内容がメモリに読み込まれるためです。ほとんどの BLOB では、Stream 型または BlobClient 型を使用します。詳細については、「コンカレンシーとメモリ使用量」を参照してください。

Storage SDK タイプの 1 つにバインドしようとしてエラーメッセージが表示された場合は、適切な Storage SDK バージョンへの参照があることを確認してください。

StorageAccountAttribute を使用して、使用するストレージアカウントを指定することもできます。これは、ライブラリ内の他の関数とは異なるストレージアカウントを使用する必要がある場合に実行できます。コンストラクターは、ストレージ接続文字列を含むアプリ設定の名前を受け取ります。属性は、パラメーター、メソッド、またはクラスレベルで適用できます。次の例では、クラスレベルとメソッドレベルを示します。

[StorageAccount("ClassLevelStorageAppSetting")]
public static class AzureFunctions
{
    [FunctionName("BlobTrigger")]
    [StorageAccount("FunctionLevelStorageAppSetting")]
    public static void Run( //...
{
    ....
}

使用するストレージアカウントは、次の順序で決定されます。

BlobTrigger 属性の Connection プロパティ。
BlobTrigger 属性と同じパラメーターに適用された StorageAccount 属性。
関数に適用される StorageAccount 属性。
クラスに適用される StorageAccount 属性。
AzureWebJobsStorage アプリケーション設定で定義されている、関数アプリの既定のストレージアカウント。

@BlobTrigger 属性を使用すると、関数をトリガーした BLOB にアクセスできます。詳細については、「トリガー - 例」を参照してください。

モデル v4
モデル v3

関数の最初の引数として BLOB データにアクセスします。

function.json ファイルのバインドの name パラメーターで指定されている名前と一致するパラメーターを使用して、BLOB データにアクセスします。

InputStream に型指定したパラメーターを使用して BLOB データにアクセスします。詳細については、「トリガー - 例」を参照してください。

Functions では、Azure Blob Storage の Python SDK 型バインドもサポートされています。これにより、基になる SDK の種類を使用して BLOB データを操作できます。

重要

Python の SDK の種類のサポートは現在プレビュー段階であり、Python v2 プログラミングモデルでのみサポートされています。詳細については、Python の SDK 型を参照してください。

接続

connection プロパティは、アプリを Azure BLOB に接続する方法を指定する環境構成への参照です。次が指定される場合があります。

接続文字列を含むアプリケーション設定の名前
まとめて ID ベースの接続を定義する、複数のアプリケーション設定の共有プレフィックスの名前。

構成された値が、1 つの設定に完全一致し、プレフィックスがその他の設定とも一致する場合は、完全一致が使用されます。

接続文字列

接続文字列を取得するには、「ストレージアカウントアクセスキーを管理する」の手順に従います。接続文字列は、BLOB ストレージアカウントではなく汎用ストレージアカウントに対するものである必要があります。

この接続文字列は、バインディング構成の connection プロパティで指定した値と同じ名前のアプリケーション設定に格納する必要があります。

アプリ設定の名前が "AzureWebJobs" で始まる場合は、ここで名前の残りの部分のみを指定できます。たとえば、connection を "MyStorage" に設定した場合、Functions ランタイムは "AzureWebJobsMyStorage" という名前のアプリ設定を探します。 connection を空のままにした場合、Functions ランタイムは、アプリ設定内の AzureWebJobsStorage という名前の既定のストレージ接続文字列を使用します。

ID ベースの接続

バージョン 5.x 以上の拡張機能を使用している場合 (non-.NET 言語スタックの場合は bundle 3.x 以上)、シークレットで接続文字列を使用する代わりに、アプリで Microsoft Entra ID を使用できます。 ID を使用するには、トリガーとバインドの構成の connection プロパティにマップされる共通のプレフィックスに設定を定義します。

connection を "AzureWebJobsStorage" に設定する場合は、「ID を使用してホストストレージに接続する」を参照してください。その他のすべての接続では、拡張機能に次のプロパティが必要です。

プロパティ	環境変数テンプレート	説明	値の例
Blob Service の URI	`<CONNECTION_NAME_PREFIX>__serviceUri`¹	HTTPS スキームを使用して接続している BLOB サービスのデータプレーン URI。	https://<storage_account_name>.blob.core.windows.net

¹ <CONNECTION_NAME_PREFIX>__blobServiceUri はエイリアスとして使用できます。接続構成が BLOB トリガーによって使用される場合、blobServiceUri には queueServiceUri も指定する必要があります。以下を参照してください。

全体の接続構成が BLOB、キュー、テーブル間で使用される場合、serviceUri 形式は指定できません。 URI では BLOB サービスのみを指定できます。別の方法として、サービスごとに専用の URI を指定して、1 つの接続を使用できるようにすることができます。両方のバージョンが指定された場合、マルチサービス形式が使用されます。複数のサービス用の接続を構成するには、<CONNECTION_NAME_PREFIX>__serviceUri の代わりに次を設定します。

プロパティ	環境変数テンプレート	説明	値の例
Blob Service の URI	`<CONNECTION_NAME_PREFIX>__blobServiceUri`	HTTPS スキームを使用して接続している BLOB サービスのデータプレーン URI。	https://<storage_account_name>.blob.core.windows.net
Queue Service URI (BLOB トリガーに必要²)	`<CONNECTION_NAME_PREFIX>__queueServiceUri`	HTTPS スキームを使用したキューサービスのデータプレーン URI。この値は、BLOB トリガーにのみ必要です。	https://<storage_account_name>.queue.core.windows.net

² BLOB トリガーは、複数回にわたる再試行の失敗を、有害な BLOB をキューに書き込むことで処理します。 serviceUri 形式では、AzureWebJobsStorage 接続が使用されます。ただし、blobServiceUri を指定する場合は、queueServiceUri でキューサービス URI も指定する必要があります。 BLOB サービスと同じストレージアカウントからサービスを使用することをお勧めします。また、トリガーでは、ストレージキューデータ共同作成者のようなロールを割り当てて、構成されたキューサービスのメッセージを読み書きできるようにする必要があります。

接続をカスタマイズするには、他のプロパティを設定します。「ID ベース接続に共通のプロパティ」を参照してください。

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

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

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

重要

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

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

[バインドの種類]	組み込みロールの例
トリガー	ストレージ BLOB データ所有者およびストレージキューデータ共同作成者¹ AzureWebJobsStorage 接続にも追加のアクセス許可を付与する必要があります。²
入力バインド	ストレージ BLOB データ閲覧者
出力バインド	ストレージ BLOB データ所有者

¹ BLOB トリガーは、複数回にわたる再試行の失敗を、接続によって指定されたストレージアカウント上のキューに有害な BLOB を書き込むことにより処理します。

² AzureWebJobsStorage 接続は、トリガーを有効にする BLOB やキューのために内部的に使用されます。 ID ベースの接続を使用するように構成されている場合は、既定の要件を超える追加のアクセス許可が必要になります。必要なアクセス許可は、ストレージ BLOB データ所有者、ストレージキューデータ共同作成者、およびストレージアカウント共同作成者の各ロールによって満たされます。詳細については、「ID を使用してホストストレージに接続する」を参照してください。

BLOB 名のパターン

in function.json の path プロパティまたは BlobTrigger 属性コンストラクターで BLOB 名のパターンを指定することができます。名前のパターンは、フィルターまたはバインド式にすることができます。以下のセクションで、例を示します。

ヒント

名前パターンでは、コンテナー名に競合回避モジュールを含めることはできません。

ファイル名と拡張子の取得

次の例は、BLOB ファイル名と拡張子を別々にバインドする方法を示します。

"path": "input/{blobname}.{blobextension}",

BLOB の名前が original-Blob1.txt の場合、関数コード内の blobname 変数と blobextension 変数の値は original-Blob1 と txt です。

BLOB 名のフィルター

次の例は、文字列 "original-" で始まる input コンテナーの BLOB でのみトリガーします。

"path": "input/original-{name}",

BLOB 名が original-Blob1.txt の場合、関数コード内の name 変数の値は Blob1.txt です。

ファイルの種類のフィルター

次の例は、 .png ファイルでのみトリガーします。

"path": "samples/{name}.png",

ファイル名の中かっこのフィルター

ファイル名の中かっこを検索するには、2 つの中かっこを使用して中かっこをエスケープします。次の例は、名前に中かっこを含む BLOB をフィルター処理します。

"path": "images/{{20140101}}-{name}",

BLOB の名前が {20140101}-soundfile.mp3 の場合、関数コード内の name 変数の値は soundfile.mp3 です。

ポーリングと待ち時間

ポーリングは、ログの検査と定期的なコンテナースキャンの実行のハイブリッドとして機能します。 BLOB は、間隔の間で使用される継続トークンを使用して、一度に 10,000 のグループ単位でスキャンされます。関数アプリを従量課金プランで使用しているときに、関数アプリがアイドル状態になっている場合、新しい BLOB の処理が最大で 10 分間遅延する可能性があります。

警告

ストレージログは "ベストエフォート" ベースで作成されます。すべてのイベントがキャプチャされる保証はありません。ある条件下では、ログが欠落する可能性があります。

より高速で信頼性の高い BLOB 処理が必要な場合は、Always On が有効になっている App Service プランを使用するようにホスティングを切り替えることを検討してください。その結果、コストが増加する可能性があります。クラシックポーリング BLOB トリガー以外のトリガーの使用も検討できます。 BLOB ストレージコンテナーのさまざまなトリガーオプションの詳細と比較については、「 BLOB コンテナーでのトリガーを参照してください。

BLOB の配信確認メッセージ

Azure Functions ランタイムでは、BLOB トリガー関数は、同一の新規または更新された BLOB について 2 回以上呼び出されることはありません。特定の BLOB バージョンが処理されているかどうかを判断するために、BLOB の配信確認メッセージが維持されます。

Azure Functions では、BLOB の配信確認メッセージは (アプリ設定 AzureWebJobsStorage で指定した) 関数アプリの Azure ストレージアカウント内の azure-webjobs-hosts というコンテナーに格納されます。 BLOB の配信確認メッセージには次の情報が含まれています。

トリガーされた関数 (<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME>。例: MyFunctionApp.Functions.CopyBlob)
コンテナーの名前
BLOB の種類 (BlockBlob または PageBlob)。
BLOB の名前
ETag (BLOB のバージョン識別子。例: 0x8D1DC6E70A277EF)

BLOB を強制的に再処理する場合は、azure-webjobs-hosts コンテナーからその BLOB の配信確認メッセージを手動で削除します。再処理がすぐに行われない場合がありますが、後で必ず行われます。すぐに再処理するには、azure-webjobs-hosts/blobscaninfo 内の scaninfo BLOB を更新できます。 LatestScan プロパティの後に最後に変更されたタイムスタンプを持つすべての BLOB が再びスキャンされます。

有害な BLOB

指定された BLOB に対する BLOB トリガー関数が失敗すると、Azure Functions は既定で最大 5 回その関数を再試行します。

試行が 5 回とも失敗した場合、Azure Functions は webjobs-blobtrigger-poison という名前のストレージキューにメッセージを追加します。再試行回数の最大値の設定は変更可能です。同じ MaxDequeueCount 設定は、有害な BLOB の処理と有害キューメッセージの処理に使用されます。有害な BLOB のキューメッセージは次のプロパティを持つ JSON オブジェクトです。

FunctionId (<FUNCTION_APP_NAME>.Functions.<FUNCTION_NAME> の形式)
BlobType (BlockBlob または PageBlob)
ContainerName
BlobName
ETag (BLOB のバージョン識別子。例: 0x8D1DC6E70A277EF)

メモリ使用量とコンカレンシー

stringやByte[]などのストリーミングをサポートしない出力型にバインドする場合ランタイムは、処理中に BLOB 全体を複数回メモリに読み込む必要があります。これにより、BLOB の処理時に予想以上のメモリ使用量が発生する可能性があります。可能な場合は、ストリームサポート型を使用します。型のサポートは、C# モードと拡張機能のバージョンによって異なります。詳細については、「バインドの種類」を参照してください。

現時点では、ランタイムは処理中に BLOB 全体を複数回メモリに読み込む必要があります。これにより、BLOB の処理時に予想以上のメモリ使用量が発生する可能性があります。

複数の関数インスタンスが BLOB データを同時に処理している場合、メモリ使用量がさらに影響を受ける可能性があります。 BLOB トリガーを使用してメモリの問題が発生する場合は、許可される同時実行の数を減らすことを検討してください。もちろん、コンカレンシーを減らすと、処理されるのを待っている BLOB のバックログが増えるという副作用があります。関数アプリのメモリ制限は、プランによって異なります。詳細については、サービスの制限に関する記事を参照してください。

同時実行の数を制御する方法は、使用しているストレージ拡張機能のバージョンによって異なります。

拡張機能 5.x 以上
拡張前 5.x

Storage 拡張機能のバージョン 5.0.0 以降を使用する場合は、host.jsonの blobs 構成のmaxDegreeOfParallelism設定を使用して、トリガーのコンカレンシーを制御します。

制限は、BLOB トリガーを使用する各関数に個別に適用されます。

host.json プロパティ

host.json ファイルには、BLOB トリガーの動作を制御する設定が含まれています。使用可能な設定の詳細については、「host.json 設定」を参照してください。

次の方法で共有

Azure Functions の Azure Blob Storage トリガー

例

属性

デコレーター

注釈

構成

Metadata

Metadata

Metadata

使用

接続

接続文字列

ID ベースの接続

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

BLOB 名のパターン

ファイル名と拡張子の取得

BLOB 名のフィルター

ファイルの種類のフィルター

ファイル名の中かっこのフィルター

ポーリングと待ち時間

BLOB の配信確認メッセージ

有害な BLOB

メモリ使用量とコンカレンシー

host.json プロパティ

次のステップ

フィードバック

その他のリソース