Azure Functionsを使用して従来の C# クラス ライブラリ関数を開発する

この記事では、.NET クラス ライブラリで C# を使用してAzure Functionsを開発する方法について説明します。 これらのクラス ライブラリは、Functions ランタイムでインプロセスを実行するために使用されます。 .NET関数は、Functions runtime から_isolatedを実行することもできます。この方法には、いくつかの利点があります。 詳細については、分離ワーカー モデルに関するページをご覧ください。 2 つのモード間の包括的な比較については、インプロセス モデルと分離ワーカー プロセスの違いに関するページを参照してください。

C# 開発者は、次のいずれかの記事にも関心がある場合があります。

Azure Functionsでは、C# および C# スクリプトプログラミング言語がサポートされています。 Azure ポータルでの C# の使用<>に関するガイダンスについては、C# スクリプト (.csx) 開発者向けリファレンスを参照してください。

サポートされているバージョン

Functions ランタイムのバージョンでは、特定のバージョンの.NETがサポートされます。 Functions のバージョンの詳細については、「Azure Functions ランタイム バージョンの概要を参照してください。 バージョンのサポートは、関数がインプロセスで実行されるか、分離ワーカー プロセスで実行されるかによっても異なります。

次の表は、特定のバージョンの Functions で使用できる.NETまたは .NET Framework の最上位レベルを示しています。

¹ .NET 6 は以前は両方のモデルでサポートされていましたが、2024年11月12日に公式サポートの終了に達しました。 .NET 7 は以前は隔離ワーカーモデルでサポートされていましたが、2024 年 5 月 14 日に公式サポートの終了を迎えました。

² ビルド プロセスには、.NET SDK も必要です。

³ サポートは、2026 年 9 月 14 日にAzure Functions ランタイムのバージョン 1.x で終了します。 詳細については、こちらのサポートに関するお知らせを参照してください。 引き続き完全なサポートを受けるには、アプリをバージョン 4.x に移行する必要があります。

⁴ インプロセス モデルのサポートは 2026 年 11 月 10 日に終了します。 詳細については、こちらのサポートに関するお知らせを参照してください。 完全なサポートを受け続けるには、分離ワーカー モデルにアプリを移行する必要があります。

⁵ 従量課金プランでは Linux で 10 個のアプリ.NET実行することはできません。 Linux で実行するには、代わりに Flex 従量課金プランを使用する必要があります。 詳細な移行手順については、「 従量課金プラン アプリを Flex Consumption プランに移行する」を参照してください。

特定の古いマイナー バージョンの削除など、Azure Functionsリリースに関する最新のニュースについては、Azure App Service のお知らせを監視します。

.NET 8 をターゲットに更新する

インプロセス モデルを使用するアプリは、このセクションで説明する手順に従って、.NET 8 をターゲットにすることができます。 ただし、このオプションを実行する場合でも、2026 年 11 月 10 日 にインプロセス モデルのサポートが終了する前に、分離ワーカー モデルへの移行計画を開始する必要があります。

多くのアプリでは、コードの更新や再デプロイを行わずに、Azureで関数アプリの構成を変更できます。 インプロセス モデル.NET 8 を実行するには、次の 3 つの構成が必要です。

• アプリケーション設定FUNCTIONS_WORKER_RUNTIME は、値 "dotnet" で設定する必要があります。
• アプリケーション設定 FUNCTIONS_EXTENSION_VERSION は、値 "~4" で設定する必要があります。
• アプリケーション設定 FUNCTIONS_INPROC_NET8_ENABLED は、値 "1" で設定する必要があります。
• .NET 8 を参照するには、スタック構成を更新する必要があります。

.NET 8 のサポートでは、Functions ランタイムのバージョン 4.x が引き続き使用されるため、構成済みのランタイム バージョンを変更する必要はありません。

ローカル プロジェクトを更新するには、まず、最新バージョンのローカル ツールを使用していることを確認します。 次に、プロジェクトが Microsoft.NET の version 4.4.0 以降を参照していることを確認します。Sdk.Functions。 その後、TargetFramework を "net8.0" に変更できます。 また、local.settings.json を更新して、"dotnet" に設定されている FUNCTIONS_WORKER_RUNTIME と、"1" に設定されている FUNCTIONS_INPROC_NET8_ENABLED の両方を含める必要もあります。

次の例は、これらの変更を含む最小限の project ファイルです。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.4.0" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

次の例は、これらの変更を含む最小限の local.settings.json ファイルです。

{
    "IsEncrypted": false,
    "Values": {
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "FUNCTIONS_INPROC_NET8_ENABLED": "1",
        "FUNCTIONS_WORKER_RUNTIME": "dotnet"
    }
}

アプリで Microsoft.Azure.DurableTask.Netherite.AzureFunctions を使用している場合は、バージョン 1.5.3 以降を対象にしていることを確認します。 .NET 8 での動作変更により、古いバージョンのパッケージを使用するアプリは、曖昧なコンストラクター例外をスローします。

他の依存関係のバージョン サポートに基づいて、アプリに他の変更を行うことが必要になる場合があります。

Functions ランタイムのバージョン 4.x は、.NET 6 と .NET 8 に同等の機能を提供します。 インプロセス モデルには、新しい.NET 8 つの機能と統合された他の機能や更新プログラムは含まれていません。 たとえば、ランタイムはキー付きサービスをサポートしていません。 最新の .NET 8 の機能と拡張機能を最大限に活用するには、分離されたワーカー モデルにmigrateする必要があります。

関数クラス ライブラリ プロジェクト

Visual Studioでは、Azure Functions プロジェクト テンプレートは、次のファイルを含む C# クラス ライブラリ プロジェクトを作成します。

• host.json - ローカルまたはAzureで実行するときに、プロジェクト内のすべての関数に影響を与える構成設定を格納します。
• local.settings.json - ローカルで実行される場合に使用されるアプリ設定および接続文字列を格納します。 このファイルにはシークレットが含まれており、Azureの関数アプリには発行されません。 代わりに、関数アプリにアプリ設定を追加します。

プロジェクトをビルドするときに、次の例のようなフォルダー構造がビルドの出力ディレクトリに作成されます。

<framework.version>
 | - bin
 | - MyFirstFunction
 | | - function.json
 | - MySecondFunction
 | | - function.json
 | - host.json

このディレクトリは、Azureで関数アプリにデプロイされます。 Functions ランタイムのバージョン 2.x に必要なバインディング拡張機能は、NuGet パッケージとしてプロジェクトに追加されます。

関数として認識されるメソッド

次の例に示すように、クラス ライブラリでは、関数は FunctionName とトリガー属性を使用したメソッドです。

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
    }
} 

FunctionName 属性は、関数のエントリ ポイントとしてメソッドをマークします。 名前はプロジェクト内で一意であり、文字で始まり、英数字、_、- のみが含まれ、127 文字以下にする必要があります。 Projectテンプレートでは、多くの場合、Run という名前のメソッドが作成されますが、メソッド名には任意の有効な C# メソッド名を指定できます。 前の例は、使用されている静的メソッドを示していますが、関数を静的にする必要はありません。

トリガー属性は、トリガーの種類を指定し、メソッド パラメーターに入力データをバインドします。 例の関数は 1 つのクエリ メッセージによってトリガーされ、そのクエリ メッセージは myQueueItem パラメーターでメソッドに渡されます。

メソッド シグネチャのパラメーター

メソッド シグネチャには、トリガー属性で使用されるパラメーター以外のパラメーターが含まれている場合があります。 含めることができるその他のパラメーターの一部を以下に示します。

• 属性で修飾することによってそのようにマークした入出力のバインド。
• ILoggerのための TraceWriter または (バージョン 1.x のみ) パラメーター。
• CancellationTokenのための パラメーター。
• トリガー メタデータを取得するためのバインド式パラメーター。

関数シグネチャ内のパラメーターの順序は問題ではありません。 たとえば、トリガー パラメーターは、他のバインドの前後に配置できます。また、ロガー パラメーターは、トリガー パラメーターまたはバインド パラメーターの前後に配置できます。

出力バインディング

関数には、出力パラメーターを使って、0 個または複数の出力バインドを定義できます。

次の例では、myQueueItemCopy という名前の出力キュー バインドを追加することで、前のものを変更しています。 この関数は、関数をトリガーするメッセージの内容を、異なるキュー内の新しいメッセージに書き込みます。

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source")] string myQueueItem, 
        [Queue("myqueue-items-destination")] out string myQueueItemCopy,
        ILogger log)
    {
        log.LogInformation($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

出力バインドに代入された値は、関数が終了したときに書き込まれます。 複数の出力パラメーターに値を割り当てることで、関数で複数の出力バインドを使用できます。

バインドの参照についての記事 (たとえば「Storage キュー」) では、トリガー、入力、または出力のバインド属性で、どのパラメーターの種類を使用できるかを説明しています。

バインド式の例

次のコードでは、アプリ設定から監視するキューの名前を取得し、insertionTime パラメーターで、キュー メッセージの作成時刻を取得しています。

public static class BindingExpressionsExample
{
    [FunctionName("LogQueueMessage")]
    public static void Run(
        [QueueTrigger("%queueappsetting%")] string myQueueItem,
        DateTimeOffset insertionTime,
        ILogger log)
    {
        log.LogInformation($"Message content: {myQueueItem}");
        log.LogInformation($"Created at: {insertionTime}");
    }
}

自動生成される function.json

ビルド処理では、ビルド フォルダー内の関数フォルダーに function.jsonファイルを作成します。 前述のとおり、このファイルに対しては直接編集が行われません。 このファイルを編集して、バインド構成を変更したり、関数を無効にしたりすることはできません。

このファイルの目的は、従量課金プランでのスケーリングの判断に使用するスケール コントローラーに情報を提供することです。 このため、ファイルにはトリガー情報のみが含まれ、入力および出力バインドは含まれません。

生成された function.json ファイルには、configurationSource 構成ではなく、バインドに.NET属性を使用するようにランタイムに指示する プロパティが含まれています。 次に例を示します。

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "queueTrigger",
      "queueName": "%input-queue-name%",
      "name": "myQueueItem"
    }
  ],
  "disabled": false,
  "scriptFile": "..\\bin\\FunctionApp1.dll",
  "entryPoint": "FunctionApp1.QueueTrigger.Run"
}

Microsoft.NET.Sdk.Functions

function.json ファイルの生成は、NuGet パッケージ Microsoft.NET によって実行されます。Sdk.Functions。

次の例は、同じ .csproj パッケージの異なるターゲット フレームワークを持つ Sdk ファイルの関連部分を示しています。

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" />
</ItemGroup>

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

Sdk パッケージ間の依存関係はトリガーとバインドです。 1.x プロジェクトは 1.x トリガーとバインドを参照します。これらのトリガーとバインドは .NET Framework をターゲットとし、4.x トリガーとバインドは Core .NETターゲットであるためです。

Sdk パッケージも、Newtonsoft.Json に依存しており、間接的に WindowsAzure.Storage に依存します。 これらの依存関係により、ユーザーのプロジェクトでは、必ずそのプロジェクト用の Functions ランタイム バージョンで動作するパッケージ バージョンが使用されます。 たとえば、Newtonsoft.Json には .NET Framework 4.6.1 のバージョン 11 がありますが、.NET Framework 4.6.1 を対象とする Functions ランタイムは、Newtonsoft.Json 9.0.1 とのみ互換性があります。 この場合は、そのプロジェクトの関数コードも Newtonsoft.Json 9.0.1 を使用する必要があります。

Microsoft.NET.Sdk.Functions のソース コードは、GitHub リポジトリ azure-functions-vs-build-sdk で入手できます。

ローカルのランタイム バージョン

Visual Studioでは、Azure Functions Core Tools を使用して、ローカル コンピューターで Functions プロジェクトを実行します。 Core Tools は、Functions ランタイム用のコマンド ライン インターフェイスです。

Windows インストーラー (MSI) パッケージまたは npm を使用して Core Tools をインストールした場合、Visual Studioで使用される Core Tools のバージョンには影響しません。 Functions ランタイム バージョン 1.x の場合、Visual Studioは Core Tools のバージョンを %USERPROFILE%\AppData\Local\Azure に格納します。Functions.Cli、そこに格納されている最新バージョンを使用します。 Functions 4.x の場合、コア ツールは Azure Functions および Web ジョブ ツール 拡張機能に含まれています。 Functions 1.x の場合、Functions プロジェクトを実行すると、コンソール出力で使用されているバージョンを確認できます。

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

ReadyToRun

関数アプリは ReadyToRun バイナリとしてコンパイルできます。 ReadyToRun は、事前コンパイル形式であり、起動時のパフォーマンスを向上させることができます。これは、従量課金プランで実行される場合にコールドスタートの影響を軽減するのに役立ちます。

ReadyToRun は .NET 6 以降のバージョンで使用でき、Azure Functions ランタイムの version 4.0 が必要です。

プロジェクトを ReadyToRun としてコンパイルするには、<PublishReadyToRun> および <RuntimeIdentifier> 要素を追加して、プロジェクト ファイルを更新します。 次の例は、Windows 32 ビット関数アプリに発行するための構成です。

<PropertyGroup>
  <TargetFramework>net8.0</TargetFramework>
  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
  <PublishReadyToRun>true</PublishReadyToRun>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

コマンド ラインから ReadyToRun を使用してアプリをビルドすることもできます。 詳細については、「-p:PublishReadyToRun=true」の dotnet publish オプションの説明を参照してください。

バインドでサポートされる型

各バインドには独自にサポートされる型があります。たとえば、BLOB トリガー属性は文字列パラメーター、POCO パラメーター、CloudBlockBlob パラメーター、またはサポートされるその他の複数の型のいずれかに適用できます。 BLOB バインディングのバインド リファレンスに関する記事に、サポートされるすべてのパラメーター型の一覧が示されています。 詳細については、トリガーとバインドに関する記事と、各バインドの種類に対応するバインド リファレンス ドキュメントをご覧ください。

メソッドの戻り値へのバインド

出力バインドのメソッドの戻り値を使用するには、属性をメソッドの戻り値に適用します。 例については、トリガーとバインディングに関するページを参照してください。

正常な関数の実行によって、常に戻り値が出力バインドに渡される場合のみ、戻り値を使用してください。 それ以外の場合は、次のセクションに示すように ICollector または IAsyncCollector を使用してください。

複数の出力値の書き込み

出力バインドに複数の値を書き込む場合、または関数の呼び出しが成功しても出力バインディングに何も渡さない場合は、ICollector 型または IAsyncCollector 型を使用します。 これらの型は、メソッド完了時に出力バインドに書き込まれる、書き込み専用接続です。

この例では、ICollector を使用して複数のキュー メッセージを同じキューに書き込みます。

public static class ICollectorExample
{
    [FunctionName("CopyQueueMessageICollector")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-3")] string myQueueItem,
        [Queue("myqueue-items-destination")] ICollector<string> myDestinationQueue,
        ILogger log)
    {
        log.LogInformation($"C# function processed: {myQueueItem}");
        myDestinationQueue.Add($"Copy 1: {myQueueItem}");
        myDestinationQueue.Add($"Copy 2: {myQueueItem}");
    }
}

非同期

関数を非同期にするには、async キーワードを使用して Task オブジェクトを返します。

public static class AsyncExample
{
    [FunctionName("BlobCopy")]
    public static async Task RunAsync(
        [BlobTrigger("sample-images/{blobName}")] Stream blobInput,
        [Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
        CancellationToken token,
        ILogger log)
    {
        log.LogInformation($"BlobCopy function processed.");
        await blobInput.CopyToAsync(blobOutput, 4096, token);
    }
}

非同期関数では out パラメーターを使用できません。 出力バインドには、代わりに関数の戻り値またはコレクター オブジェクトを使用します。

キャンセル トークン

関数は CancellationToken パラメーターを受け付けることができます。これにより、オペレーティング システムは、その関数をいつ終了しようとしているかをコードに通知できます。 この通知を使用すれば、関数が予期せず終了してデータが不整合な状態になることを防止できます。

メッセージをバッチで処理する関数を持っている場合について考えてみましょう。 次のAzure Service Busトリガーされた関数は、特定の関数呼び出しによって処理される受信メッセージのバッチを表すServiceBusReceivedMessage オブジェクトの配列を処理します。

using Azure.Messaging.ServiceBus;
using System.Threading;

namespace ServiceBusCancellationToken
{
    public static class servicebus
    {
        [FunctionName("servicebus")]
        public static void Run([ServiceBusTrigger("csharpguitar", Connection = "SB_CONN")]
               ServiceBusReceivedMessage[] messages, CancellationToken cancellationToken, ILogger log)
        {
            try
            { 
                foreach (var message in messages)
                {
                    if (cancellationToken.IsCancellationRequested)
                    {
                        log.LogInformation("A cancellation token was received. Taking precautionary actions.");
                        //Take precautions like noting how far along you are with processing the batch
                        log.LogInformation("Precautionary activities --complete--.");
                        break;
                    }
                    else
                    {
                        //business logic as usual
                        log.LogInformation($"Message: {message} was processed.");
                    }
                }
            }
            catch (Exception ex)
            {
                log.LogInformation($"Something unexpected happened: {ex.Message}");
            }
        }
    }
}

ログ記録

関数のコードで、Application Insights でトレースとして表示されるログに出力を書き込むことができます。 ログ書き込みには、ILogger という種類のパラメーターを含める方法をお勧めします。これは通常 log という名前です。 Functions バージョン 1.x のランタイムでは TraceWriter が使用されていました。ここでは Application Insights への書き込みは行われますが、構造化ログはサポートされていません。 このデータは Application Insights によってキャプチャされないため、ログの書き込みに Console.Write を使用しないでください。

アイロガー

関数定義に、構造化ログをサポートする ILogger パラメーターを含めます。

ILogger オブジェクトで、Log<level>拡張メソッド (ILogger 上) を呼び出して、ログを作成します。 次のコードでは、カテゴリが Information の Function.<YOUR_FUNCTION_NAME>.User. ログが書き込まれます。

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger logger)
{
    logger.LogInformation("Request for item with key={itemKey}.", id);

関数がどのように ILogger を実装しているかについて詳しくは、「利用統計情報の収集」を参照してください。 Function で始まるカテゴリは、ILogger インスタンスを使用していると想定しています。 代わりに ILogger<T>を使用する場合は、カテゴリ名が Tに基づいている可能性があります。

構造化ログ

ログ メッセージで使用するパラメーターは、プレースホルダーの名前ではなく順序によって決定されます。 次のコードがあるとします。

string partitionKey = "partitionKey";
string rowKey = "rowKey";
logger.LogInformation("partitionKey={partitionKey}, rowKey={rowKey}", partitionKey, rowKey);

同じメッセージ文字列を維持しながらパラメーターの順序を逆にすると、結果のメッセージ テキストではそれらの値が誤った場所に配置されます。

プレースホルダーはこのように処理されるため、構造化ログを実行できます。 Application Insights では、パラメーターの名前と値のペア、およびメッセージ文字列を保存します。 そのため、メッセージ引数はクエリ可能なフィールドになります。

前の例のようなロガー メソッド呼び出しでは、フィールド customDimensions.prop__rowKey をクエリできます。 prop__ プレフィックスを追加して、ランタイムが追加したフィールドと、ご使用の関数コードが追加したフィールドとの間に競合が起こらないようにします。

フィールド customDimensions.prop__{OriginalFormat} を参照することで、元のメッセージ文字列をクエリすることもできます。

customDimensions データの JSON 表現の例を次に示します。

{
  "customDimensions": {
    "prop__{OriginalFormat}":"C# Queue trigger function processed: {message}",
    "Category":"Function",
    "LogLevel":"Information",
    "prop__message":"c9519cbf-b1e6-4b9b-bf24-cb7d10b1bb89"
  }
}

カスタム テレメトリをログに記録する

関数から Application Insights にカスタム テレメトリ データを送信するために使用できる、関数固有のバージョンの Application Insights SDK があります:Microsoft.Azure。WebJobs.Logging.ApplicationInsights。 コマンド プロンプトから次のコマンドを使用して、このパッケージをインストールします。

dotnet add package Microsoft.Azure.WebJobs.Logging.ApplicationInsights --version <VERSION>

Install-Package Microsoft.Azure.WebJobs.Logging.ApplicationInsights -Version <VERSION>

このコマンドでは、<VERSION> を、インストールされているバージョンの Microsoft.Azure をサポートするこのパッケージのバージョンに置き換えます。WebJobs。

次の C# の例では、カスタム テレメトリ API を使用します。 この例は .NET クラス ライブラリ用ですが、Application Insights コードは C# スクリプトでも同じです。

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;

using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using System.Linq;

namespace functionapp0915
{
    public class HttpTrigger2
    {
        private readonly TelemetryClient telemetryClient;

        /// Using dependency injection will guarantee that you use the same configuration for telemetry collected automatically and manually.
        public HttpTrigger2(TelemetryConfiguration telemetryConfiguration)
        {
            this.telemetryClient = new TelemetryClient(telemetryConfiguration);
        }

        [FunctionName("HttpTrigger2")]
        public Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)]
            HttpRequest req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.Query
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Write an event to the customEvents table.
            var evt = new EventTelemetry("Function called");
            evt.Context.User.Id = name;
            this.telemetryClient.TrackEvent(evt);

            // Generate a custom metric, in this case let's use ContentLength.
            this.telemetryClient.GetMetric("contentLength").TrackValue(req.ContentLength);

            // Log a custom dependency in the dependencies table.
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            dependency.Context.User.Id = name;
            this.telemetryClient.TrackDependency(dependency);

            return Task.FromResult<IActionResult>(new OkResult());
        }
    }
}

using System;
using System.Net;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using System.Linq;

namespace functionapp0915
{
    public static class HttpTrigger2
    {
        private static string key = TelemetryConfiguration.Active.InstrumentationKey = 
            System.Environment.GetEnvironmentVariable(
                "APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

        private static TelemetryClient telemetryClient = 
            new TelemetryClient() { InstrumentationKey = key };

        [FunctionName("HttpTrigger2")]
        public static async Task<HttpResponseMessage> Run(
            [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
            HttpRequestMessage req, ExecutionContext context, ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");
            DateTime start = DateTime.UtcNow;

            // Parse query parameter
            string name = req.GetQueryNameValuePairs()
                .FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
                .Value;

            // Get request body
            dynamic data = await req.Content.ReadAsAsync<object>();

            // Set name to query string or body data
            name = name ?? data?.name;
         
            // Track an Event
            var evt = new EventTelemetry("Function called");
            UpdateTelemetryContext(evt.Context, context, name);
            telemetryClient.TrackEvent(evt);
            
            // Track a Metric
            var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
            UpdateTelemetryContext(metric.Context, context, name);
            telemetryClient.TrackMetric(metric);
            
            // Track a Dependency
            var dependency = new DependencyTelemetry
            {
                Name = "GET api/planets/1/",
                Target = "swapi.co",
                Data = "https://swapi.co/api/planets/1/",
                Timestamp = start,
                Duration = DateTime.UtcNow - start,
                Success = true
            };
            UpdateTelemetryContext(dependency.Context, context, name);
            telemetryClient.TrackDependency(dependency);
        }
        
        // Correlate all telemetry with the current Function invocation
        private static void UpdateTelemetryContext(TelemetryContext context, ExecutionContext functionContext, string userName)
        {
            context.Operation.Id = functionContext.InvocationId.ToString();
            context.Operation.ParentId = functionContext.InvocationId.ToString();
            context.Operation.Name = functionContext.FunctionName;
            context.User.Id = userName;
        }
    }    
}

関数呼び出しの要求が重複しているため、 TrackRequest または StartOperation<RequestTelemetry> を呼び出さないでください。 Functions ランタイムでは、要求が自動的に追跡されます。

telemetryClient.Context.Operation.Id は設定しないでください。 このグローバル設定により、多くの関数が同時に実行されていると、正しくない相関関係が発生します。 代わりに、新しいテレメトリ インスタンス (DependencyTelemetry、EventTelemetry) を作成し、その Context プロパティを変更してください。 その後、テレメトリ インスタンスを、Track (TelemetryClient、TrackDependency()、TrackEvent()) の対応する TrackMetric() メソッドに渡します。 このメソッドにより、現在の関数呼び出しについて、テレメトリが必ず正しい相関関係の詳細を持つようになります。

関数のテスト

以下の記事では、テストを目的として、インプロセス C# クラス ライブラリ関数をローカルで実行する方法について説明します。

• Visual Studio
• Visual Studio Code
• コマンド ライン

環境変数

環境変数またはアプリ設定値を取得するには、次のコード例のように、 System.Environment.GetEnvironmentVariableを使用します。

public static class EnvironmentVariablesExample
{
    [FunctionName("GetEnvironmentVariables")]
    public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log)
    {
        log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
        log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
        log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
    }

    private static string GetEnvironmentVariable(string name)
    {
        return name + ": " +
            System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
    }
}

アプリ設定は、ローカルで開発するときと、Azureで実行する場合の両方で、環境変数から読み取ることができます。 ローカルでの開発時、アプリ設定は Values ファイルの コレクションから取得します。 ローカルとAzureの両方の環境で、GetEnvironmentVariable("<app setting name>")は名前付きアプリ設定の値を取得します。 たとえば、ローカルでの実行中、local.settings.json ファイルに { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } } が含まれている場合は、"My Site Name" が返されます。

System.Configuration.ConfigurationManager.AppSettings プロパティは、アプリ設定値を取得するための代替 API ですが、次に示すように GetEnvironmentVariable を使用することをお勧めします。

実行時のバインド

C# やその他の .NET 言語では、属性内での 宣言型（デクララティブ） バインディングではなく、命令型（インペラティブ） バインディング パターンを使用できます。 命令型のバインドは、設計時ではなくランタイム時にバインド パラメーターを計算する必要がある場合に便利です。 このパターンを使用すると、サポートされている入力バインドと出力バインドに関数コード内でバインドできます。

次のように命令型のバインドを定義します。

• 必要な命令型のバインドの関数署名に属性を含めないでください。

• 入力パラメーター Binder binder または IBinder binder を渡します。

• 次の C# パターンを使用してデータ バインドを実行します。

  using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
  {
      ...
  }
  

  BindingTypeAttribute はバインディングを定義する.NET属性であり、T はそのバインド型でサポートされている入力または出力の種類です。 T を out パラメーター型 (out JObject など) にすることはできません。 たとえば、Mobile Apps テーブルの出力バインドでは、six 出力の種類がサポートされます。 ただし、ICollector<t> または IAsyncCollector<T> を命令型バインディングで使用することしかできません。

単一属性の例

次のコード例は、実行時に BLOB パスが定義された Storage Blob の出力バインドを作成し、この BLOB に文字列を書き込みます。

public static class IBinderExample
{
    [FunctionName("CreateBlobUsingBinder")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-4")] string myQueueItem,
        IBinder binder,
        ILogger log)
    {
        log.LogInformation($"CreateBlobUsingBinder function processed: {myQueueItem}");
        using (var writer = binder.Bind<TextWriter>(new BlobAttribute(
                    $"samples-output/{myQueueItem}", FileAccess.Write)))
        {
            writer.Write("Hello World!");
        };
    }
}

BlobAttribute では、Storage blob の入力または出力バインドが定義され、TextWriter はサポートされている出力バインドの種類です。

複数属性の例

前の例では、関数アプリのメインストレージ アカウントの接続文字列 (AzureWebJobsStorage) に対するアプリ設定を取得します。 ストレージ アカウントに使用するカスタム アプリ設定を指定するには、StorageAccountAttribute を追加し、属性配列を BindAsync<T>() に渡します。 Binderではなく、IBinder パラメーターを使用します。 次に例を示します。

public static class IBinderExampleMultipleAttributes
{
    [FunctionName("CreateBlobInDifferentStorageAccount")]
    public async static Task RunAsync(
            [QueueTrigger("myqueue-items-source-binder2")] string myQueueItem,
            Binder binder,
            ILogger log)
    {
        log.LogInformation($"CreateBlobInDifferentStorageAccount function processed: {myQueueItem}");
        var attributes = new Attribute[]
        {
        new BlobAttribute($"samples-output/{myQueueItem}", FileAccess.Write),
        new StorageAccountAttribute("MyStorageAccount")
        };
        using (var writer = await binder.BindAsync<TextWriter>(attributes))
        {
            await writer.WriteAsync("Hello World!!");
        }
    }
}

トリガーとバインド

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

1. HTTP とタイマーを除くすべてのバインディングを登録します。 Azure Functions バインド拡張機能の登録を参照してください。 Functions ランタイムのバージョン 1.x を使用する場合、この手順は必要ありません。
2. 2026 年 9 月 14 日にAzure Functions ランタイムのバージョン 1.x のサポートが終了。 完全なサポートのためにアプリをバージョン 4.x に移行します。
3. トリガーは従量課金プランではサポートされていません。 このバインドの種類には 、ランタイム 駆動型のトリガーが必要です。
4. このバインドの種類は、Kubernetes、Azure IoT Edge、およびその他のセルフホステッド モードでのみサポートされます。

次のステップ