Azure FunctionsのDurable Functionsでのデータの永続化とシリアル化

Important

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

Durable Functions ランタイムは、関数パラメーター、戻り値、およびその他の状態を task hub に自動的に永続化して、信頼性の高い実行を提供します。ただし、永続的なストレージに永続化されるデータの量と頻度は、アプリケーションのパフォーマンスとストレージトランザクションのコストに影響を与える可能性があります。アプリケーションで格納されるデータの種類によっては、データ保有とプライバシーポリシーも考慮する必要があります。

この記事では、保持されるデータ、大きなペイロードと機密データを処理する方法、サポートされている言語ごとにシリアル化をカスタマイズする方法について説明します。

この記事の内容:

タスクハブの内容 - 格納されるデータとその方法
入力と出力を小さくする - ペイロードサイズを管理するための戦略
機密データの操作 - シークレットと個人を特定できる情報を保護する
タスクハブストレージをセキュリティで保護する - 未承認のアクセスからストレージバックエンドを保護する
シリアル化と逆シリアル化のカスタマイズ - 言語固有のシリアル化オプション

タスクハブの内容

タスクハブには、インスタンスの現在の状態と保留中のメッセージが格納されます。

インスタンスの状態 には、インスタンスの現在の状態と履歴が格納されます。オーケストレーションインスタンスの場合、この状態にはランタイム状態、オーケストレーションの履歴、入力、出力、カスタム状態が含まれます。エンティティインスタンスの場合、エンティティの状態が含まれます。
"メッセージ" には、関数の入力または出力、イベントペイロード、ルーティングやエンドツーエンドの関連付けなどの内部目的で使用するメタデータが格納されます。

メッセージは処理後に削除されますが、インスタンスの状態は、アプリケーションまたはオペレーターによって明示的に削除されない限り保持されます。特に、オーケストレーションの完了後も、オーケストレーションの履歴はストレージに残ります。

状態とメッセージがオーケストレーションの進行状況を表す方法の例については、タスクハブの実行例を参照してください。

ストレージ内の状態とメッセージを表す場所と方法は、ストレージプロバイダーによって異なります。 Durable Task Schedulerを使うと良いです。タスクハブの管理バックエンドを提供し、基盤となる状態ストアを管理してくれるからです。しかし、Azure Storageは既存のワークロードや、自社ストレージリソースを管理したいアプリにとって依然として堅実な選択肢です。

ストレージプロバイダー	状態の保存方法	推奨される使用方法
耐久性のあるタスクスケジューラ	オーケストレーションとエンティティの状態は、タスクハブリソースの背後にあるマネージドスケジューラバックエンドに格納されます。	新しいDurable Functionsアプリやマネージドデプロイの優先オプションです。
Azure Storage	状態とメッセージは、Azure Storageアカウント内のキュー、テーブル、ブロブで表現されます。	既にAzure Storageに依存している既存のアプリやデプロイに適しています。

シリアル化および永続化されるデータの種類

次の一覧は、Durable Functionsの機能を使用するときにシリアル化および永続化されるさまざまな種類のデータを示しています。

オーケストレーター、アクティビティ、およびエンティティ関数のすべての入力と出力には、任意の ID やハンドルされない例外が含まれます。
オーケストレーター、アクティビティ、およびエンティティ関数の名前
外部イベントの名前とペイロード
カスタムオーケストレーションの状態ペイロード
オーケストレーションの終了メッセージ
持続的タイマーペイロード
持続的な HTTP 要求と応答の URL、ヘッダー、およびペイロード
エンティティの呼び出しとシグナルペイロード
エンティティ状態ペイロード

この一覧のペイロードサイズの管理と機密性の高い項目の保護に関するガイダンスについては、次のセクションを参照してください。

Durable Functionsの入力と出力を小さく保つ

Durable Functions API との間で大きな入力と出力をやり取りすると、メモリの問題が発生する可能性があります。入力と出力はオーケストレーション履歴にシリアル化されます。つまり、大規模なペイロードは時間の経過と同時に、無制限の履歴の増加に大きく貢献できます。この増加は、再生中にメモリ例外を引き起こすリスクがあります。

大きな入力と出力の影響を軽減するには、次の操作を行います。

サブオーケストレーターに作業を委任して、複数のオーケストレーター間で履歴のメモリ負荷を負荷分散し、個々の履歴のメモリ占有領域を小さく保ちます。
外部ストレージ (Azure Blob Storage など) に大きなデータを格納し、必要に応じてアクティビティ関数内でそのデータを取得できるようにする軽量識別子を渡します。

Durable Task Schedulerでは、大きなペイロードサポートを使って大きなペイロードをAzure Blob Storageにオフロードします。新しいアプリでは、このパターンはオーケストレーションが持続的な作業間で大きなペイロードを渡す必要がある場合に推奨されます。 Azure Storageプロバイダーを使っても、以下のセクションで示したクレームチェックパターンを適用し、操作間で軽量な参照を渡すことができます。

Tip

大規模なデータを処理するためのベストプラクティスは、外部ストレージに保持し、必要に応じてアクティビティ内でのみそのデータを具体化することです。

大きなペイロードへの参照を渡す

ストレージ提供者に合ったパターンを選びましょう。

耐久性のあるタスクスケジューラ

Durable Task Schedulerを使う場合は、大きなペイロードサポートを有効にして、ランタイムがAzure Blob Storageに大きなペイロードを書き込み、スケジューラを通じて小さな参照を送信します。典型的な構成はスケジューラ文書に示されています:

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "azureManaged",
        "connectionStringName": "DTS_CONNECTION_STRING",
        "payloadStorageEnabled": true,
        "payloadStorageThresholdBytes": 262144
      },
      "hubName": "%TASKHUB_NAME%"
    }
  }
}

Azure Storage

Azure Storageプロバイダーでは、Claim Checkパターンを使ってオーケストレーション履歴を小さく抑えつつ、大きなペイロードを処理できます。オーケストレーターはblobコンテナとblob名を含む軽量参照を渡し、必要に応じてAzure Blob Storageからペイロードを読み書きします。

以下の例は、すでにストレージアカウントにBLOBがあると仮定しています。オーケストレーションは {"container":"large-payloads","blobName":"input/job-123.json"}のような参照から始めましょう。必要に応じて、そのアクティビティは processed-payloads 出力コンテナを作成します。サンプル処理ステップは入力バイトを変更せずにコピーします。それをアプリケーションロジックに置き換えてください。

Important

参照にストレージ認証情報や共有アクセス署名(SAS)を含めてはいけません。システムはオーケストレーション履歴において参照を保持します。これらの例は、ストレージコードを簡潔に保つために PAYLOAD_STORAGE_CONNECTION_STRING という名前のアプリ設定を使っています。本番ワークロードでは、Microsoft Entra IDを使ってブロブデータへのアクセスを許可します。

この例にはAzure.Storage.Blobs NuGet パッケージが必要です。

using System;
using System.Threading.Tasks;
using Azure.Storage.Blobs;
using Microsoft.Azure.Functions.Worker;
using Microsoft.DurableTask;

public record BlobReference(string Container, string BlobName);

public static class LargePayloadFunctions
{
    [Function("ProcessLargePayload")]
    public static async Task<BlobReference> RunOrchestrator(
        [OrchestrationTrigger] TaskOrchestrationContext context)
    {
        BlobReference inputReference = context.GetInput<BlobReference>()
            ?? throw new InvalidOperationException("A blob reference is required.");

        return await context.CallActivityAsync<BlobReference>(
            nameof(ProcessLargePayloadActivity), inputReference);
    }

    [Function(nameof(ProcessLargePayloadActivity))]
    public static async Task<BlobReference> ProcessLargePayloadActivity(
        [ActivityTrigger] BlobReference inputReference)
    {
        string connectionString =
            Environment.GetEnvironmentVariable("PAYLOAD_STORAGE_CONNECTION_STRING")
            ?? throw new InvalidOperationException("Payload storage is not configured.");
        BlobServiceClient service = new BlobServiceClient(connectionString);

        BlobClient inputBlob = service
            .GetBlobContainerClient(inputReference.Container)
            .GetBlobClient(inputReference.BlobName);
        BinaryData inputData = (await inputBlob.DownloadContentAsync()).Value.Content;

        BlobContainerClient outputContainer =
            service.GetBlobContainerClient("processed-payloads");
        await outputContainer.CreateIfNotExistsAsync();

        string outputName = $"processed/{Guid.NewGuid():N}.json";
        await outputContainer.GetBlobClient(outputName)
            .UploadAsync(inputData, overwrite: true);

        return new BlobReference(outputContainer.Name, outputName);
    }
}

この例にはAzure.Storage.Blobs NuGet パッケージが必要です。

using System;
using System.Threading.Tasks;
using Azure.Storage.Blobs;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;

public class BlobReference
{
    public string Container { get; set; } = string.Empty;
    public string BlobName { get; set; } = string.Empty;
}

public static class LargePayloadFunctions
{
    [FunctionName("ProcessLargePayload")]
    public static async Task<BlobReference> RunOrchestrator(
        [OrchestrationTrigger] IDurableOrchestrationContext context)
    {
        BlobReference inputReference = context.GetInput<BlobReference>()
            ?? throw new InvalidOperationException("A blob reference is required.");

        return await context.CallActivityAsync<BlobReference>(
            "ProcessLargePayloadActivity", inputReference);
    }

    [FunctionName("ProcessLargePayloadActivity")]
    public static async Task<BlobReference> RunActivity(
        [ActivityTrigger] BlobReference inputReference)
    {
        string connectionString =
            Environment.GetEnvironmentVariable("PAYLOAD_STORAGE_CONNECTION_STRING")
            ?? throw new InvalidOperationException("Payload storage is not configured.");
        BlobServiceClient service = new BlobServiceClient(connectionString);

        BlobClient inputBlob = service
            .GetBlobContainerClient(inputReference.Container)
            .GetBlobClient(inputReference.BlobName);
        BinaryData inputData = (await inputBlob.DownloadContentAsync()).Value.Content;

        BlobContainerClient outputContainer =
            service.GetBlobContainerClient("processed-payloads");
        await outputContainer.CreateIfNotExistsAsync();

        string outputName = $"processed/{Guid.NewGuid():N}.json";
        await outputContainer.GetBlobClient(outputName)
            .UploadAsync(inputData, overwrite: true);

        return new BlobReference
        {
            Container = outputContainer.Name,
            BlobName = outputName,
        };
    }
}

この例では @azure/storage-blob のnpmパッケージが必要です。

const { randomUUID } = require("crypto");
const { BlobServiceClient } = require("@azure/storage-blob");
const df = require("durable-functions");

df.app.orchestration("processLargePayload", function* (context) {
    const inputReference = context.df.getInput();
    return yield context.df.callActivity(
        "processLargePayloadActivity", inputReference);
});

df.app.activity("processLargePayloadActivity", {
    handler: async (inputReference) => {
        const connectionString =
            process.env.PAYLOAD_STORAGE_CONNECTION_STRING;
        if (!connectionString) {
            throw new Error(
                "PAYLOAD_STORAGE_CONNECTION_STRING is not set.");
        }

        const service = BlobServiceClient.fromConnectionString(
            connectionString);

        const inputBlob = service
            .getContainerClient(inputReference.container)
            .getBlockBlobClient(inputReference.blobName);
        const inputData = await inputBlob.downloadToBuffer();

        const outputContainer =
            service.getContainerClient("processed-payloads");
        await outputContainer.createIfNotExists();

        const outputName = `processed/${randomUUID()}.json`;
        await outputContainer.getBlockBlobClient(outputName)
            .uploadData(inputData);

        return {
            container: outputContainer.containerName,
            blobName: outputName,
        };
    },
});

この例では azure-storage-blob パッケージが必要です。 requirements.txtに加えてください。

import os
import uuid

import azure.functions as func
import azure.durable_functions as df
from azure.core.exceptions import ResourceExistsError
from azure.storage.blob import BlobServiceClient

app = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)


@app.orchestration_trigger(context_name="context")
def process_large_payload(context: df.DurableOrchestrationContext):
    input_reference: dict = context.get_input()
    return (yield context.call_activity(
        "process_large_payload_activity", input_reference))


@app.activity_trigger(input_name="input_reference")
def process_large_payload_activity(input_reference: dict) -> dict:
    connection_string = os.getenv("PAYLOAD_STORAGE_CONNECTION_STRING")
    if not connection_string:
        raise ValueError(
            "PAYLOAD_STORAGE_CONNECTION_STRING is not set.")

    service = BlobServiceClient.from_connection_string(connection_string)

    input_blob = service.get_blob_client(
        container=input_reference["container"],
        blob=input_reference["blobName"])
    input_data = input_blob.download_blob().readall()

    output_container = service.get_container_client("processed-payloads")
    try:
        output_container.create_container()
    except ResourceExistsError:
        pass

    output_name = f"processed/{uuid.uuid4()}.json"
    output_container.upload_blob(
        name=output_name, data=input_data, overwrite=True)

    return {
        "container": output_container.container_name,
        "blobName": output_name,
    }

この例は Az.Storage モジュールを必要とします。 requirements.psd1に追加し、host.jsonで管理依存が有効になっていることを確認してください。

編曲者 run.ps1:

param($Context)

$OutputReference = Invoke-DurableActivity `
    -FunctionName 'ProcessLargePayloadActivity' `
    -Input $Context.Input

return $OutputReference

活動 run.ps1:

param($InputReference)

if ([string]::IsNullOrEmpty(
        $env:PAYLOAD_STORAGE_CONNECTION_STRING)) {
    throw 'The PAYLOAD_STORAGE_CONNECTION_STRING app setting is not configured.'
}

$StorageContext = New-AzStorageContext `
    -ConnectionString $env:PAYLOAD_STORAGE_CONNECTION_STRING
$InputFile = New-TemporaryFile

try {
    Get-AzStorageBlobContent `
        -Container $InputReference.container `
        -Blob $InputReference.blobName `
        -Destination $InputFile.FullName `
        -Context $StorageContext `
        -Force | Out-Null

    # Process $InputFile here. This example uploads it unchanged.
    $OutputContainer = 'processed-payloads'
    New-AzStorageContainer `
        -Name $OutputContainer `
        -Context $StorageContext `
        -ErrorAction SilentlyContinue | Out-Null

    $OutputName = "processed/$([guid]::NewGuid()).json"
    Set-AzStorageBlobContent `
        -File $InputFile.FullName `
        -Container $OutputContainer `
        -Blob $OutputName `
        -Context $StorageContext `
        -Force | Out-Null

    return @{
        container = $OutputContainer
        blobName = $OutputName
    }
}
finally {
    Remove-Item $InputFile.FullName -Force
}

orchestrationTriggerで説明されている標準の activityTrigger バインドとバインドを使用してください。

この例には com.azure:azure-storage-blob と com.microsoft:durabletask-azure-functions Mavenパッケージが必要です。

import com.azure.core.util.BinaryData;
import com.azure.storage.blob.BlobContainerClient;
import com.azure.storage.blob.BlobServiceClient;
import com.azure.storage.blob.BlobServiceClientBuilder;
import com.microsoft.azure.functions.annotation.FunctionName;
import com.microsoft.durabletask.TaskOrchestrationContext;
import com.microsoft.durabletask.azurefunctions.DurableActivityTrigger;
import com.microsoft.durabletask.azurefunctions.DurableOrchestrationTrigger;

import java.util.Objects;
import java.util.UUID;

public class LargePayloadFunctions {
    public static class BlobReference {
        public String container;
        public String blobName;

        public BlobReference() {
        }

        public BlobReference(String container, String blobName) {
            this.container = container;
            this.blobName = blobName;
        }
    }

    @FunctionName("ProcessLargePayload")
    public BlobReference runOrchestrator(
            @DurableOrchestrationTrigger(name = "ctx")
            TaskOrchestrationContext ctx) {
        BlobReference inputReference = Objects.requireNonNull(
            ctx.getInput(BlobReference.class),
            "A blob reference is required.");
        return ctx.callActivity(
            "ProcessLargePayloadActivity",
            inputReference,
            BlobReference.class).await();
    }

    @FunctionName("ProcessLargePayloadActivity")
    public BlobReference runActivity(
            @DurableActivityTrigger(name = "inputReference")
            BlobReference inputReference) {
        String connectionString = Objects.requireNonNull(
            System.getenv("PAYLOAD_STORAGE_CONNECTION_STRING"),
            "PAYLOAD_STORAGE_CONNECTION_STRING is not configured.");
        BlobServiceClient service = new BlobServiceClientBuilder()
            .connectionString(connectionString)
            .buildClient();

        BinaryData inputData = service
            .getBlobContainerClient(inputReference.container)
            .getBlobClient(inputReference.blobName)
            .downloadContent();

        BlobContainerClient outputContainer =
            service.getBlobContainerClient("processed-payloads");
        outputContainer.createIfNotExists();

        String outputName =
            "processed/" + UUID.randomUUID() + ".json";
        outputContainer.getBlobClient(outputName)
            .upload(inputData, true);

        return new BlobReference(
            outputContainer.getBlobContainerName(), outputName);
    }
}

並列活動が複数の大きな結果を生み出した場合、参照リストを返し、そのリストを最終的な集約活動に渡します。集約活動はペイロードを読み込み結合し、最後に1つの出力ブロブを書き込むべきです。大きな結果をオーケストレーターで読み込んだり連結したりしないでください。

機密データを操作する

Durable Functions API との間の入力と出力 (例外を含む) は、選択した storage プロバイダーに永続的に保持されます。これらの入力、出力、または例外に機密データ (シークレット、接続文字列、個人を特定できる情報など) が含まれている場合は、ストレージプロバイダーのリソースへの読み取りアクセス権を持つすべてのユーザーがそれらを取得できます。

機密データを安全に処理するには、アクティビティ関数内のデータをAzure Key Vaultまたは環境変数からフェッチし、オーケストレーターまたはエンティティとの間でそのデータを直接またはやり取りしないようにします。この方法は、機密データがストレージリソースに漏えいするのを防ぐのに役立ちます。

同様に、ストレージリソースへの書き込みアクセスは厳密に制御する必要があります。ストレージ内の改ざんされたデータによってオーケストレーションの動作が変更される可能性があります。タスクハブストレージのセキュリティ保護の詳細については、「タスクハブストレージのセキュリティ保護」を参照してください。

Tip

このガイダンスは、 CallHttp オーケストレーター API にも適用され、要求と応答のペイロードがストレージに保持されます。ターゲット HTTP エンドポイントで認証が必要な場合は、アクティビティ内に HTTP 呼び出しを実装するか、 CallHttp によって提供される組み込みのマネージド ID サポートを使用します。これは、資格情報をストレージに保持しません。

Note

ログへの読み取りアクセス権を持つすべてのユーザー (Application Insights など) がそれらのシークレットを取得する可能性がある場合は、シークレットを含むデータをログに記録しないようにします。

静止時の暗号化

Azure Storage プロバイダーを使用すると、すべてのデータが保存時に自動的に暗号化されます。ただし、ストレージアカウントへのアクセス権を持つユーザーは、暗号化されていない形式でデータを読み取ることができます。機密データのより強力な保護が必要な場合は、事前に暗号化された形式でデータが永続化されるように、最初に独自の暗号化キーを使用してデータを暗号化することを検討してください。

または、.NETユーザーには、自動暗号化を提供するカスタムシリアル化プロバイダーを実装するオプションがあります。暗号化を使用したカスタムシリアル化の例は、このGitHubサンプルで確認できます。

Note

アプリケーションレベルの暗号化を実装する場合は、オーケストレーションとエンティティが無期限に存在する可能性があることに注意してください。オーケストレーションまたはエンティティはキーのローテーションポリシーよりも長く実行される可能性があるため、暗号化キーをローテーションするときにこれが重要になります。キーのローテーションが行われると、データの暗号化に使用されたキーが、次にオーケストレーションまたはエンティティを実行したときに復号化できなくなる可能性があります。そのため、カスタム暗号化は、オーケストレーションとエンティティが比較的短時間実行されることが予想される場合にのみ推奨されます。

タスクハブストレージをセキュリティで保護する

タスクハブをホストするストレージバックエンドは、重要な信頼境界です。 Durable Task Framework は、オーケストレーションの再生とメッセージ処理中にストレージから読み取ったデータを信頼します。タスクハブストレージへの書き込みアクセス権を持つすべてのユーザーは、オーケストレーション状態、保留中のメッセージ、または格納されているペイロードを改ざんできます。これにより、アプリケーションの動作が変更されたり、意図しないアクションがトリガーされたり、関数アプリのコンテキスト内でリモートでコードが実行されたりする可能性があります。

Important

タスクハブのストレージ資格情報を公開したり、信頼されていない関係者に書き込みアクセス権を付与したりしないでください。タスクハブストレージへの書き込みアクセスは、任意のコード実行のトリガーなど、アプリケーションの動作を変更するために使用できます。

共有責任

ストレージバックエンドのセキュリティ保護は、アプリケーションの状態またはコードを格納するデータベースのセキュリティ保護と同じです。 Durable Task Framework は、保存されたデータに対して整合性検証を実行しないため、未承認の変更を防ぐためにストレージ層のアクセス制御に依存します。

Backend	セキュリティ責任	Guidance
耐久性のあるタスクスケジューラ	Microsoftは基盤となるストレージのバックエンドを管理しています。アイデンティティ、タスクハブへのアクセス、アプリレベルのセキュリティを管理します。	新しいDurable Functionsアプリの推奨デフォルト。
Azure Storageおよびその他のBYOプロバイダー	ストレージアカウントやデータベースとそのセキュリティ管理を管理します。	既にAzure Storageに依存している既存のワークロードやデプロイには適しています。

Note

信頼されていないテナント間で 1 つのタスクハブを共有しないでください。タスクハブはユーザー間のアクセス境界を強制しないため、タスクハブに対して読み取りまたは書き込みを行うことができるテナントは、その中のすべてのオーケストレーションとエンティティに影響を与える可能性があります。同様に、セキュリティ境界と同じバックエンド内の個別のタスクハブに依存しないでください。 Durable Task Scheduler は個々のタスクハブを対象とした RBAC をサポートしますが、IP 許可リストやプライベートエンドポイントなどのネットワーク制御はスケジューラレベルでのみ適用されるため、スケジューラ内のタスクハブはセキュリティ分離境界ではありません。 BYO ストレージプロバイダーについても同様です。ストレージアカウントまたはデータベースにアクセスできるテナントは、そのバックエンド上のすべてのタスクハブにアクセスできます。テナント間でセキュリティを分離する必要がある場合は、テナントごとに個別のインフラストラクチャ (BYO プロバイダー用の個別のストレージアカウントまたはデータベース、または個別の Durable Task Scheduler インスタンス) をプロビジョニングします。

ストレージのセキュリティ強化チェックリスト

タスクハブストレージを保護するには、次のベストプラクティスを適用します。

選ぶバックエンドにはアイデンティティベースの接続を使いましょう。
- Durable Task Schedulerでは、スケジューラやタスクハブにマネージドIDとRBACを頼りにできます。
- Azure Storageや他のBYOプロバイダーでは、可能な限り接続文字列よりもマネージドIDを優先してください。
Durable Functions 用マネージド ID を構成するを参照してください。
最小特権 RBAC ロールを適用します。必要な最小限のアクセス許可のみを付与します。不要なユーザーやサービスに広範なストレージアクセスを付与するのは避けましょう。
プライベートエンドポイントやサービスエンドポイントを使ってストレージアカウントやスケジューラ展開へのネットワークアクセスを制限しましょう。この制限により、タスクハブデータへの不正なネットワークレベルアクセスを防ぐことができます。
ストレージアクセスを監視するには、ストレージアカウントで Azure Monitor のリソースログ、特に StorageWrite ログカテゴリを有効にします。これらのログを、Log Analyticsなどの監視対象ストレージアカウントの外部の宛先にルーティングして、改ざんできないようにします。ストレージログを参照してください。
接続文字列を使用する場合は、資格情報を定期的にローテーションします。ストレージアカウントキーは、他の高い特権の資格情報と同じ注意を払って扱います。
マネージドストレージバックエンドについて考えてみましょう。 Durable Task Schedulerは認証、RBAC、ネットワーク隔離などのストレージセキュリティを自動的に管理し、Azure Storageは明示的なストレージ制御を提供します。

シリアル化と逆シリアル化をカスタマイズする

シリアル化のカスタマイズオプションは言語によって異なります。 [言語] タブを選択すると、使用可能なオプションが表示されます。

.NET Isolated と System.Text.Json

.NET隔離ワーカープロセスで動作するDurable Functions、Azure Functionsアプリ全体でグローバルに設定された同じオブジェクトシリアライザーを使用します(WorkerOptions参照)。このシリアライザーはNewtonsoft.JsonではなくデフォルトでSystem.Text.Jsonされています。 WorkerOptions.Serializerの変更は推移的にDurable Functionsに適用されます。

.NET での JSON シリアル化の組み込みサポートの詳細については、.NET の概要ドキュメントで JSON シリアル化と逆シリアル化を参照してください。

既定のシリアル化のロジック

.NET 用 Durable Functions のインプロセスでは、内部で Json.NET を使用して、オーケストレーションとエンティティのデータを JSON にシリアル化します。使用される既定の Json.NET 設定は次のとおりです。

入力、出力、および状態:

JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.None,
    DateParseHandling = DateParseHandling.None,
}

例外：

JsonSerializerSettings
{
    ContractResolver = new ExceptionResolver(),
    TypeNameHandling = TypeNameHandling.Objects,
    ReferenceLoopHandling = ReferenceLoopHandling.Ignore,
}

JsonSerializerSettings に関する詳細なドキュメントについては、こちらを参照してください。

.NET属性を使用してシリアル化をカスタマイズする

シリアル化時に、Json.NET では、データのシリアル化と JSON からの逆シリアル化の方法を制御するクラスおよびプロパティのさまざまな属性を検索します。 Durable Functions API に渡されるデータ型のソースコードを所有している場合は、シリアル化と逆シリアル化をカスタマイズするために、これらの属性を型に追加することを検討してください。

依存関係挿入を使用してシリアル化をカスタマイズする

.NETを対象とし、Functions V3 ランタイムで実行する関数アプリは、Dependency Injection (DI) を使用して、データと例外のシリアル化方法をカスタマイズできます。次のサンプルコードは、DI を使用して、IMessageSerializerSettingsFactory および IErrorSerializerSettingsFactory サービスインターフェイスのカスタム実装を使用して、既定の Json.NET シリアル化設定をオーバーライドする方法を示しています。

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;
using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using System.Collections.Generic;

[assembly: FunctionsStartup(typeof(MyApplication.Startup))]
namespace MyApplication
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddSingleton<IMessageSerializerSettingsFactory, CustomMessageSerializerSettingsFactory>();
            builder.Services.AddSingleton<IErrorSerializerSettingsFactory, CustomErrorSerializerSettingsFactory>();
        }

        /// <summary>
        /// A factory that provides the serialization for all inputs and outputs for activities and
        /// orchestrations, as well as entity state.
        /// </summary>
        internal class CustomMessageSerializerSettingsFactory : IMessageSerializerSettingsFactory
        {
            public JsonSerializerSettings CreateJsonSerializerSettings()
            {
                // Return your custom JsonSerializerSettings here
            }
        }

        /// <summary>
        /// A factory that provides the serialization for all exceptions thrown by activities
        /// and orchestrations
        /// </summary>
        internal class CustomErrorSerializerSettingsFactory : IErrorSerializerSettingsFactory
        {
            public JsonSerializerSettings CreateJsonSerializerSettings()
            {
                // Return your custom JsonSerializerSettings here
            }
        }
    }
}

シリアル化と逆シリアル化のロジック

Azure Functions Node アプリケーションでは、シリアル化に JSON.stringify()、逆シリアル化に JSON.Parse() を使用。ほとんどの型は、シームレスにシリアル化および逆シリアル化する必要があります。既定のロジックが不十分な場合は、オブジェクトに toJSON() メソッドを定義すると、シリアル化ロジックがオーバーライドされます。ただし、オブジェクトの逆シリアル化にはアナログは存在しません。

シリアル化/逆シリアル化パイプラインを完全にカスタマイズする場合は、独自のコードでシリアル化と逆シリアル化を処理し、データを文字列として渡すことを検討してください。

シリアル化と逆シリアル化のロジック

Durable Functionsがデータを正しくシリアル化およびデシリアライズするために、型注釈を使用することを推奨します。多くの組み込み型は自動的に処理されますが、一部の組み込みデータ型では、逆シリアル化中に型を保持するために型の注釈が必要です。

カスタム・データ・タイプの場合、データ・タイプ・クラスでクラス・メソッド to_json および from_json を定義することにより、JSONシリアライゼーションおよびデシリアライゼーションを可能にします。これらのメソッドは、オーケストレーター関数からの戻り値に対しては呼び出されないため、戻り値はネイティブに JSON シリアル化可能である必要があることに注意してください。詳細については、「バインディング」を参照してください。

デシリアライズされたペイロードを期待される型に対して検証し、必要に応じて厳格モードへのオプトインは、Pythonの「Migrate to type-safe serialization in Durable Functions」を参照してください。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-15

Azure FunctionsのDurable Functionsでのデータの永続化とシリアル化

タスク ハブの内容

シリアル化および永続化されるデータの種類

Durable Functionsの入力と出力を小さく保つ

大きなペイロードへの参照を渡す

耐久性のあるタスクスケジューラ

Azure Storage

機密データを操作する

静止時の暗号化

タスク ハブ ストレージをセキュリティで保護する

共有責任

ストレージのセキュリティ強化チェックリスト

シリアル化と逆シリアル化をカスタマイズする

.NET Isolated と System.Text.Json

次のステップ

フィードバック

その他のリソース

タスクハブの内容

タスクハブストレージをセキュリティで保護する