次の方法で共有


Azure FunctionsのAzure Blob storage トリガー

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

ヒント

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

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

セットアップと構成の詳細については、overviewを参照してください。

重要

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

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

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

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

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

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

重要

2026 年 11 月 10 日 にインプロセス モデルのサポートが終了します。 完全なサポートのために、分離された worker モデル>にアプリを<することをお勧めします。

次の例は 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";
    }
}

この関数は、 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");
}

次の例では、Event Grid トリガーを使用します。

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

この SDK 型の例 では、BlobClient を使用して BLOB のプロパティをaccessします。

@FunctionName("processBlob")
public void run(
        @BlobTrigger(
                name = "content",
                path = "images/{name}",
                connection = "AzureWebJobsStorage") BlobClient blob,
        @BindingName("name") String file,
        ExecutionContext ctx)
{
    ctx.getLogger().info("Size = " + blob.getProperties().getBlobSize());
}

このSDK 型の例では、BlobContainerClient を使用して、関数をトリガーしたコンテナー内の BLOB に関する情報をaccessします。

@FunctionName("containerOps")
public void run(
        @BlobTrigger(
                name = "content",
                path = "images/{name}",
                connection = "AzureWebJobsStorage") BlobContainerClient container,
        ExecutionContext ctx)
{
    container.listBlobs()
            .forEach(b -> ctx.getLogger().info(b.getName()));
}

この SDK の種類の例 では、 BlobClient を使用して、実行をトリガーした BLOB に関する入力バインディングから情報を取得します。

@FunctionName("checkAgainstInputBlob")
public void run(
        @BlobInput(
                name = "inputBlob",
                path = "inputContainer/input.txt") BlobClient inputBlob,
        @BlobTrigger(
                name = "content",
                path = "images/{name}",
                connection = "AzureWebJobsStorage",
                dataType = "string") String triggerBlob,
        ExecutionContext ctx)
{
    ctx.getLogger().info("Size = " + inputBlob.getProperties().getBlobSize());
}

この例では、Storage BLOB トリガーと HTTP トリガーの入力バインドの両方から BlobClient を取得する方法を示します。

import "@azure/functions-extensions-blob"; // This is the mandatory first import for SDK binding
import { StorageBlobClient } from "@azure/functions-extensions-blob";
import { app, InvocationContext } from "@azure/functions";

export async function storageBlobTrigger(
  blobStorageClient: StorageBlobClient, // SDK binding provides this client
  context: InvocationContext
): Promise<void> {
  context.log(`Blob trigger processing: ${context.triggerMetadata.name}`);

  // Access to full SDK capabilities
  const blobProperties = await blobStorageClient.blobClient.getProperties();
  context.log(`Blob size: ${blobProperties.contentLength}`);

  // Download blob content
  const downloadResponse = await blobStorageClient.blobClient.download();
  context.log(`Content: ${downloadResponse}`);
}

// Register the function
app.storageBlob("storageBlobTrigger", {
  path: "snippets/{name}",
  connection: "AzureWebJobsStorage",
  sdkBinding: true, // Enable SDK binding
  handler: storageBlobTrigger,
});

この例では、HTTP トリガーを使用して、Storage BLOB 入力バインディングの両方から ContainerClient を取得する方法を示します。

import "@azure/functions-extensions-blob"; // This is the mandatory first import for SDK binding
import { StorageBlobClient } from "@azure/functions-extensions-blob";
import {
  app,
  HttpRequest,
  HttpResponseInit,
  input,
  InvocationContext,
} from "@azure/functions";

const blobInput = input.storageBlob({
  path: "snippets",
  connection: "AzureWebJobsStorage",
  sdkBinding: true,
});

export async function listBlobs(
  request: HttpRequest,
  context: InvocationContext
): Promise<HttpResponseInit> {
  // Get input binding for a specific container
  const storageBlobClient = context.extraInputs.get(
    blobInput
  ) as StorageBlobClient;

  // List all blobs in the container
  const blobs = [];
  for await (const blob of storageBlobClient.containerClient.listBlobsFlat()) {
    blobs.push(blob.name);
  }

  return { jsonBody: { blobs } };
}

app.http("listBlobs", {
  methods: ["GET"],
  authLevel: "function",
  extraInputs: [blobInput],
  handler: listBlobs,
});

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

BLOB トリガー パス samples-workitems/{name} 内の文字列 {name}は、binding 式を作成します。この式を関数コードで使用して、トリガーする BLOB のファイル名をaccessできます。 詳しくは、後述の「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,
});

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

BLOB トリガー パス samples-workitems/{name} 内の文字列 {name}は、binding 式を作成します。この式を関数コードで使用して、トリガーする BLOB のファイル名をaccessできます。 詳しくは、後述の「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`
        );
    },
});

次の例では、ファイルが source blob storage コンテナーに追加されたときに実行される関数を作成する方法を示します。

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

{
  "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 オブジェクトを直接accessします。

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

app = func.FunctionApp(http_auth_level=func.AuthLevel.FUNCTION)
@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 型のバインドを含める方法の詳細なチュートリアルについては、Python SDK Bindings for BLOB サンプルに従ってください。

他の SDK 型バインドがサポートされているものも含め、詳細については、 SDK の型バインドに関するページを参照してください。

この例では、受信 BLOB トリガーの BLOB 名とサイズをログに記録します。

import logging
import azure.functions as func

app = func.FunctionApp()

@app.function_name(name="BlobTrigger1")
@app.blob_trigger(arg_name="myblob", 
                  path="samples-workitems/{name}",
                  connection="MyStorageAccountAppSetting")
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")

属性

in-processisolated worker process C# ライブラリはどちらも、BlobAttribute 属性を使用して関数を定義します。 C# スクリプトでは、C# スクリプト ガイドで説明されているように、代わりに function.json 構成ファイルを使用します。

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

パラメーター 説明
BlobPath BLOB へのパス。
接続 Azure BLOB への接続方法を指定するアプリ設定または設定コレクションの名前。 「接続」を参照してください。
Access 読み取りと書き込みのどちらを行うかを示します。
ソース トリガーイベントのソースを設定します。 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)

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

デコレーター

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

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

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

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

注釈

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

構成

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

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

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

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

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

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

メタデータ

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}");
} 

メタデータ

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

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

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

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

メタデータ

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

使用

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

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

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

1 これらの型を使用するには、Microsoft を参照する必要があります。Azure。Functions.Worker.Extensions。Storage。BLOB 6.0.0 以降および SDK 型バインドのcommon 依存関係

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

Storage SDK の種類のいずれかにバインドしようとしたときにエラー メッセージが表示される場合は、正しいStorage SDK バージョン

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

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

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

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

SDK の種類へのバインドのサポートは現在プレビュー段階であり、Azure Blob Storage SDK に限定されています。 詳細については、Java リファレンス記事の SDK の種類 を参照してください。

関数の最初の引数として BLOB データをAccessします。

function.json ファイルのバインドの名前パラメーターで指定された名前と一致するパラメーターを使用して BLOB データをAccessします。

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

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

同期 SDK の種類のみがサポートされています。

重要

Python の SDK の種類のサポートは一般提供されており、Python v2 プログラミング モデルでのみサポートされています。 詳細については、Python の SDK 型を参照してください。

接続

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

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

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

Connection string

connection stringを取得するには、アカウントstorageキーの管理accessに示されている手順に従います。 connection stringは、Blob storage アカウントではなく、汎用storage アカウントである必要があります。

このconnection stringは、バインド構成の connection プロパティで指定された値と一致する名前を持つアプリケーション設定に格納する必要があります。

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

ID ベースの接続

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

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

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

1<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 トリガーに必要2) <CONNECTION_NAME_PREFIX>__queueServiceUri HTTPS スキームを使用したキュー サービスのデータ プレーン URI。 この値は、BLOB トリガーにのみ必要です。 https://<storage_account_name>.queue.core.windows.net

2 blob トリガーは、poison blobs をキューに書き込むことで、複数の再試行でエラーを処理します。 serviceUri 形式では、AzureWebJobsStorage 接続が使用されます。 ただし、blobServiceUri を指定する場合は、queueServiceUri でキュー サービス URI も指定する必要があります。 BLOB サービスと同じstorage アカウントのサービスを使用することをお勧めします。 また、Storage キュー データ共同作成者 などのロールを割り当てることで、構成されたキュー サービス内のメッセージをトリガーが読み書きできることを確認する必要>。

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

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

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

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

重要

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

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

[バインドの種類] 組み込みロールの例
トリガー Storage BLOB データ所有者andStorage Queue Data Contributor1

AzureWebJobsStorage 接続にも追加のアクセス許可を付与する必要があります。2
入力バインド Storage BLOB データ リーダー
出力バインド Storage BLOB データ所有者

1 BLOB トリガーはpoison blobs を接続で指定されたstorage アカウントのキューに書き込むことで、複数の再試行の失敗を処理します。

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

BLOB 名のパターン

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

ヒント

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

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

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

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

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

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 分間遅延する可能性があります。

警告

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

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

BLOB の配信確認メッセージ

Azure Functions ランタイムは、同じ新規または更新された BLOB に対して BLOB トリガー関数が複数回呼び出されないようにします。 特定の BLOB バージョンが処理されているかどうかを判断するために、BLOB の配信確認メッセージが維持されます。

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

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

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

有害な BLOB

特定の BLOB に対して BLOB トリガー関数が失敗した場合、Azure Functionsはその関数を既定で合計 5 回再試行します。

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

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

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

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

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

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

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

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

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

host.json プロパティ

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

次のステップ