Azure Functions runtime 1.x legacy reference

本記事では、ランタイム1.xを依然として使用している関数アプリの重要な歴史的情報と詳細な参考文献へのリンクを保持しています。 新しい関数アプリにはランタイム1.xは使わないでください。

ランタイム 1.x スコープ

Azure Functions ランタイム1.xは2026年9月14日にサポート終了となり、新規または既存の関数アプリには対応していません。 ランタイム1.xには以下の特徴がありました:

• Windowsでのみ動作しました。
• .NETフレームワークやJavaScriptアプリを対象としたC#アプリをサポートしていました。
• C#アプリはプロセス中に実行されました。 ランタイム1.xは孤立ワーカーモデルをサポートしていませんでした。
• ローカル開発にはAzure Functions Core Toolsのバージョン1.xを使用していました。 Core Tools 1.xはWindowsでのみ動作します。
• ランタイムには対応するバインディングが含まれていました。 後のランタイムバージョンでは、別途バージョン管理されたバインディング拡張や拡張バンドルが使用されます。

ランタイム、拡張、プログラミングモデルのバージョン

Azure Functionsのランタイムバージョンは、バインディング拡張、拡張バンドル、言語プログラミングモデルで使われているバージョンとは異なります。 他のコンポーネントのバージョンラベルは、そのアプリがAzure Functions runtime 1.xを使用していることを示すものではありません。 例えば次が挙げられます。

• Python v1およびv2のプログラミングモデルはランタイム4.x上で動作します。
• Node.js v3およびv4のプログラミングモデルはランタイム4.x上で動作します。
• 拡張バンドルおよびバインディング拡張パッケージのバージョンはランタイムバージョンとは独立しています。

ランタイム4.xへの移行

アプリを完全なサポートに戻すには、 ランタイム1.xからランタイム4.xへ移行してください。 移行ガイドは以下の作業をカバーしています:

• ランタイム1.xをターゲットにしたアプリを特定しましょう。
• C#またはJavaScriptに対応した対象を選びます。
• プロジェクト、バインディング、アプリ設定、 host.json ファイルを更新してください。
• ローカルでアプリをテストし、関数アプリをAzureで更新してください。

FUNCTIONS_EXTENSION_VERSIONアプリの設定だけを変えないでください。 ランタイムアップグレードには、プロジェクト、コード、バインディング、設定の変更が必要になることがあります。

ランタイム1.x専用のアプリ設定

廃止された AzureWebJobsDashboard 設定はランタイム 1.x のみでサポートされています。 このツールには、ログを保存しAzureポータルのMonitorタブに表示するためのオプションの汎用ストレージアカウント接続文字列が含まれています。

ランタイム1.xは AZURE_FUNCTIONS_ENVIRONMENT アプリ設定をサポートしていません。

FUNCTIONS_EXTENSION_VERSION値は関数アプリを実行時1.xにピン留め~1。 ファイルシステムキーストレージ(AzureWebJobsSecretStorageType=files)がデフォルトです。

functionsRuntimeAdminIsolationEnabledサイトプロパティはランタイム1.xでは利用できません。 FUNCTIONS_V2_COMPATIBILITY_MODE設定はランタイム1.xアプリには適用されません。

Projectと言語の違い

ランタイム1.x C#クラスライブラリプロジェクトは.NET Frameworkを対象とし、Microsoft.NET.Sdk.Functionsパッケージの1.xバージョンを使用していました。 伐採に TraceWriter を使うこともできます。 現在のC#プロジェクトモデルおよび移行に関する考慮事項については、.NETクラスライブラリの開発ガイドおよびランタイム1.x移行ガイドをご覧ください。

C#クラスライブラリプロジェクト

以下の例は、ランタイム1.xプロジェクトファイルの関連部分を示しています:

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

Microsoft.NET.Sdk.Functionsパッケージの依存関係にはトリガーとバインディングが含まれます。 1.xプロジェクトとは、.NETフレームワークをターゲットにしているため、1.xトリガーやバインディングを指します。 パッケージは Newtonsoft.Json や間接的にまた WindowsAzure.Storageに依存します。 これらの依存関係により、プロジェクトは対象となるFunctionsランタイムと互換性のあるバージョンを使用します。 例えば、Framework 4.6.1を対象としたFunctionsランタイムは、バージョン11ではなく.NETNewtonsoft.Json 9.0.1と互換性があります。

Runtime 1.xでは、Application Insightsのログ作成に TraceWriter が使用されていました。 TraceWriter 構造化されたログングをサポートしていません。

以下の例では TelemetryClient を作成し、 TrackEvent、 TrackMetric、 TrackDependency を使ってカスタムテレメトリを記録します。 また、関数実行コンテキストを利用してカスタムテレメトリと現在の呼び出しを関連付けます。

カスタムテレメトリの例

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

namespace functionapp0915
{
	public static class HttpTrigger2
	{
		private static string key = TelemetryConfiguration.Active.InstrumentationKey =
			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;
			string name = req.GetQueryNameValuePairs()
				.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
				.Value;
			dynamic data = await req.Content.ReadAsAsync<object>();
			name = name ?? data?.name;

			var evt = new EventTelemetry("Function called");
			UpdateTelemetryContext(evt.Context, context, name);
			telemetryClient.TrackEvent(evt);

			var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
			UpdateTelemetryContext(metric.Context, context, name);
			telemetryClient.TrackMetric(metric);

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

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

ランタイム1.xはC#スクリプト(.csx)やJavaScript関数もサポートしていました。 C#スクリプトはランタイム1.x専用ではないので、一般的なスクリプトの指導は C#スクリプト開発者の参考 書を参考にしてください。 実行時固有の変更については移行ガイドをご利用ください。

初期のC#構文の例については、 ランタイム1.x関数テンプレートを参照してください。

C#スクリプトアセンブリとパッケージ

ランタイム1.x C#スクリプト関数では、以下のアセンブリを単純名称で参照できます:

• Newtonsoft.Json
• Microsoft.WindowsAzure.Storage
• Microsoft.ServiceBus
• Microsoft.AspNet.WebHooks.Receivers
• Microsoft.AspNet.WebHooks.Common

ランタイム1.xでは、依存関係を定義するために project.json ファイルを使用していました。 以下の例は Microsoft.ProjectOxford.Face NuGetパッケージを追加します。

{
	"frameworks": {
		"net46": {
			"dependencies": {
				"Microsoft.ProjectOxford.Face": "1.1.0"
			}
		}
	}
}

拡張バンドルはランタイム1.xではサポートされていません。 カスタムNuGetフィードを使用するには、function appのrootフォルダ内の NuGet.Config ファイルでフィードを指定します。 詳しくは、「NuGet の動作の構成」をご覧ください。

Core Tools 1.xによるローカル開発

Azure Functions Core Toolsのバージョン1.xはランタイム1.xとペアリングされており、Windowsでのみ動作します。 ランタイムを始めるために、 func host startを実行しました。 現在のローカル開発ガイダンスについては、「Core Toolsを使ってローカルでAzure Functionsを開発する」をご覧ください。

Visual Studio%USERPROFILE%\AppData\Local\Azure.Functions.Cliに1.x Core Toolsの実行時バージョンを保存し、そこに保存された最新バージョンを使用していました。 プロジェクトを実行すると、コンソール出力で選択したバージョンが確認できました:

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

ランタイム1.x host.json 参照

host.json スキーマと設定はランタイム1.x以降に変更されました。 既存構成を確認する際には ランタイム1.x host.json 参照 を参照し、移行時に 現在の host.json 参照 と比較してください。

Application Insightsでランタイム1.xアプリをモニターする

ランタイム1.xは以下のApplication Insightsログカテゴリを使用しています:

ログ レベルを構成する

ランタイム1.xは host.jsonでログレベルをlogger.categoryFilter未満に設定します:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Host.Results": "Information",
				"Host.Aggregator": "Trace",
				"Function": "Information"
			}
		}
	}
}

複数のカテゴリ名が同じ文字列で始まる場合、より特定のカテゴリが先にマッチングされます。 以下の例は、Errorレベルで除いてHost.Aggregatorを除くすべてをログに記録しています。

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Information",
			"categoryLevels": {
				"Host": "Error",
				"Function": "Error",
				"Host.Aggregator": "Information"
			}
		}
	}
}

サンプリングを構成する

デフォルトの最大テレメトリーレートは1秒あたり5項目です。 Runtime 1.xは以下のサンプリングを applicationInsights.sampling以下で設定します:

{
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

以下の例は、カテゴリーフィルタリングとサンプリングを組み合わせたものです。

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Function": "Error",
				"Host.Aggregator": "Error",
				"Host.Results": "Information",
				"Host.Executor": "Warning"
			}
		}
	},
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

ランタイム1.xは関数ごとの設定をサポートしていません。

アプリケーションインサイトの機能

ランタイム1.xはリクエスト、例外、パフォーマンスカウンタを自動的に収集しました。 HTTP、Service Bus、Event Hubs、SQL依存関係を自動的に収集することはありませんでした。 QuickPulse/Live Metricsは安全な制御チャネルなしで対応し、サンプリングもサポートしましたが、心拍、Service BusやEvent Hubsの相関、または完全に設定可能なテレメトリー収集には対応していませんでした。

ランタイム1.xにおけるサポートされていない機能と挙動

• 再試行ポリシーはサポートされていません。
• 仮想ネットワークトリガーの動的スケール監視はサポートされていません。
• プレミアムプランや専用プランでは、デフォルトの関数実行タイムアウトは無制限です。 消費プランでは、デフォルトのタイムアウトは5分、最大10分です。
• リモートデプロイメントパッケージを使う関数型アプリは、Azure Files共有なしでは動作できません。

ランタイム1.xに含まれるバインディング

Azure Functions runtime 1.x is retired. ランタイム4.xに移行する際は、現在のバインディング拡張や拡張バンドルを使い、各バインディングの設定や型の変更を確認しましょう。

以下のバインディングはランタイム1.xに含まれていました。 C#属性列はコードで使われるショートネームを示します。 対応するクラス名にはBlobTriggerAttributeなどのAttribute接尾辞が付けられます。 C#スクリプト関数は代わりに function.json ファイル内でバインディングを定義します。

ランタイム1.xを使用する関数型アプリは、自動的にMicrosoft.Azureを参照します。WebJobs NuGetパッケージ(バージョン2.x)。

Blob Storage、Queue Storage、Table Storageのトリガーとバインディングは、WindowsAzure.Storage NuGetパッケージのバージョン7.2.1を使用しています。 異なるバージョンのStorage SDKを参照し、関数シグネチャでStorage SDKの型にバインドすると、Functionsランタイムがその型にバインドできないと報告することがあります。 プロジェクトがWindowsAzure.Storage 7.2.1を参照していることを確認してください。

ランタイム1.xにおけるBlob Storageのバインディング

Runtime 1.x は廃止された Microsoft.WindowsAzure.Storage 名前空間からの型を公開しています。 Azureの新しいタイプです。Storage.Blobは、後の拡張とランタイム4.xが必要です。

ランタイム1.xにおけるキューストレージバインディング

Runtime 1.x は廃止された Microsoft.WindowsAzure.Storage 名前空間からの型を公開しています。 Azureの新しいタイプです。Storage.Queueは、後の拡張とランタイム4.xが必要です。

キューストレージのバインディング設定については、 ランタイム1.x host.json 参照のキューセクションを参照してください。 ランタイム1.xでは、 maxPollingInterval 設定はミリ秒単位で表されます。 後のランタイムバージョンでは、そのデータ型は TimeSpanになっています。

ランタイム1.xにおけるテーブルストレージのバインディング

Runtime 1.xは、廃止されたMicrosoft.の型を公開しました。WindowsAzure.Storage.Table名前空間。 Azureの新しいタイプ。Data.TablesはAzure Tables拡張とruntime 4.xが必要です。

入力例

次のC#関数は単一のテーブル行を読み込みます。 キューに送られたすべてのメッセージに対して、その関数がトリガーされます。 行キーの値 {queueTrigger} は、メッセージのメタデータ (メッセージ文字列) に行キーをバインドします。

public class TableStorage
{
	public class MyPoco
	{
		public string PartitionKey { get; set; }
		public string RowKey { get; set; }
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition", "{queueTrigger}")] MyPoco poco,
		ILogger log)
	{
		log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
	}
}

以下のC#関数は、 MyPoco クラスが TableEntityから派生する複数のテーブル行を読み込みます。

public class TableStorage
{
	public class MyPoco : TableEntity
	{
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition")] IQueryable<MyPoco> pocos,
		ILogger log)
	{
		foreach (MyPoco poco in pocos)
		{
			log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
		}
	}
}

入力の使用

キーによって特定のエンティティを返すには、 Tableentity から派生するバインド パラメーターを使用します。 特定の TableName、 PartitionKey、 RowKey は、テーブルから特定の存在を取り出すために使われます。

複数のエンティティを返すクエリを実行するには、 IQueryable<T> から継承する型の IQueryable<T> にバインドします。

出力使用状況

out パラメーターと戻り値の型では、次の型がサポートされています。

• PartitionKey のプロパティと RowKey のプロパティを含む 、単純な従来のオブジェクト (POCO)。 これらのプロパティは、ITableEntity を実装、または TableEntity を継承することで、付随させることができます。
• ICollector<T> または IAsyncCollector<T> には、T のプロパティと PartitionKey のプロパティが含まれています。 これらのプロパティは、ITableEntity を実装、または TableEntity を継承することで、付随させることができます。

メソッド パラメーターとして Storage SDK からCloudTableにバインドすることもできます。 その後、そのオブジェクトを使用してテーブルに書き込むことができます。

Event Hubs bindings in runtime 1.x

ランタイム1.xにはEvent Hubsバインディングが含まれており、別の拡張を必要としませんでした。 廃止されたMicrosoft.Azure.を公開しました。EventHubs.EventData型。 Event Hubsのトリガーは、単一のイベントに対して EventData、JSONシリアライゼル型、 string、 byte[] をサポートし、バッチに対して EventData[] と string[] をサポートしていました。 出力バインディングは EventData、JSONシリアライズ可能な型、 string、 byte[]をサポートしていました。

イベントハブのトリガーや出力バインディングの場合、 function.jsonのランタイム1.xはイベントハブ名に path プロパティを使用します。 後のランタイムバージョンでは eventHubNameが使われています。 イベントハブ名が接続文字列に含まれている場合、その値は実行時にプロパティを上書きします。

ランタイム1.x host.json ファイルはトップレベルの eventHub オブジェクトを使用します:

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}

完全な構成参照については、ランタイム1.x host.json 参照のeventHubセクションを参照してください。

ランタイム1.xにおけるEvent Gridバインディング

3.x以前のEvent Grid拡張バージョンは CloudEventsスキーマをサポートしていません。 このスキーマを利用するには、HTTPトリガーを使用するか、ランタイム4.xおよびEvent Grid拡張3.xに移行してください。

Event Gridの出力バインディングはランタイム2.x以降でのみ利用可能です。

バインドの種類

ランタイム1.x拡張は以下のパラメータ型をサポートしています。 CloudEventsスキーマをサポートしておらず、Event Grid拡張3.xが必要です。

トリガーの使用方法

プロセス中のC#クラスライブラリ関数は、以下のイベントグリッドトリガータイプをサポートしています:

• Newtonsoft.Json.Linq.JObject
• System.String

Webhookエンドポイントとシステムキー

ランタイム1.xイベントグリッドトリガーのホストウェブフックエンドポイントは、以下のURLパターンを使用します。

https://{functionappname}.azurewebsites.net/admin/extensions/EventGridExtensionConfig?functionName={functionname}&code={systemkey}

管理者APIからイベントグリッドシステムキーを取得するには、以下のリクエストで関数アプリのマスターキーを使用します。

https://{functionappname}.azurewebsites.net/admin/host/systemkeys/eventgridextensionconfig_extension?code={masterkey}

ローカルテストでは、イベントグリッドトリガーエンドポイントは以下のURLパターンを使用します。

http://localhost:7071/admin/extensions/EventGridExtensionConfig?functionName={FUNCTION_NAME}

ランタイム1.xにおけるService Busバインディング

ランタイム1.xは、廃止されたMicrosoft.の型を公開しました。ServiceBus.メッセージング名前空間。 Azureの新しいタイプ。Messaging.ServiceBusはService Bus拡張5.x以降とruntime 4.xが必要です。

2026年9月30日、Azure Service Bus SDKライブラリのWindowsAzure.ServiceBus、Microsoft.Azure。ServiceBus、およびcom.microsoft.azure。ServiceBusは廃止されます。 これらのライブラリはAzure SDKガイドラインに準拠していません。 Service Bus Messaging Protocol(SBMP)のサポートも終了します。 旧ライブラリは廃止後も引き続き利用できますが、Microsoftからの公式サポートやアップデートはもはや受けられません。 詳細については、 サポート終了のお知らせを参照してください。

トリガーの使用方法

キューまたはトピックメッセージトリガーは、以下のパラメータタイプをサポートします:

• BrokeredMessage は BrokeredMessage.GetBody<T>() メソッドでデシリアル化されたメッセージを提供します。
• MessageReceiver はメッセージコンテナからのメッセージを受け取り、確認します。 このタイプは autoComplete が falseに設定されている場合に必要です。

C#クラスライブラリでは、属性のコンストラクタはキュー名やトピック名、サブスクリプション名を名乗ります。 また、接続のアクセス権を指定することもできます。 アクセス権を指定しない場合、既定値は Manage になります。

Service Busアカウント選択

ServiceBusAccountAttributeを使ってService Busアカウントを指定します。 コンストラクターは、Service Bus 接続文字列を含むアプリ設定の名前を受け取ります。 パラメータ、メソッド、クラスレベルで属性を適用します。 以下の例はクラスレベルおよびメソッドレベルの属性を示しています:

[ServiceBusAccount("ClassLevelServiceBusAppSetting")]
public static class AzureFunctions
{
	[ServiceBusAccount("MethodLevelServiceBusAppSetting")]
	[FunctionName("ServiceBusQueueTriggerCSharp")]
	public static void Run(
		[ServiceBusTrigger("myqueue", AccessRights.Manage)]
		string myQueueItem, ILogger log)
	{
		// ...
	}
}

以下の順序で、どのService Busアカウントを使用するかが決まります。

1. ServiceBusTrigger 属性の Connection プロパティ。
2. ServiceBusAccount 属性と同じパラメーターに適用された ServiceBusTrigger 属性。
3. 関数に適用される ServiceBusAccount 属性。
4. クラスに適用される ServiceBusAccount 属性。
5. AzureWebJobsServiceBus アプリ設定。

メッセージのメタデータ

以下のプロパティは BrokeredMessage および MessageReceiver クラスのメンバーです。

出力使用状況

メタデータを含むメッセージを送信する場合は、BrokeredMessage 型を使います。 パラメータを return タイプの属性として定義します。 関数が終了した時点でパラメータ値がnullなら、Functionsはメッセージを作成しません。

function.json バインディングの場合、accessRightsmanageまたはlistenを受け入れ、デフォルトでmanageに切り替えます。 接続文字列に管理権限がない場合は、accessRightsをlistenに設定して、実行時が管理操作を試みられないようにしてください。

もし存在しなければ、ランタイムがキューを作成し、 accessRights を manageに設定します。

ホストの設定

Service Busバインディング設定については、ランタイム1.x host.json リファレンスを参照してください。

ランタイム1.xにおけるHTTPおよびウェブフックのバインディング

HTTPトリガー関数はデフォルトで HTTP 200 OK 体の空のまま返されます。 後のランタイムバージョンでは HTTP 204 No Contentが戻っています。

function.jsonのHTTPトリガーの場合、webHookTypeプロパティを使って指定されたプロバイダーのウェブフック受信機としてトリガーを設定する。 このプロパティはランタイム1.xに特有のものです。

ランタイム1.xは認証済みクライアント情報へのアクセスをサポートしていません。

ウェブフックモード

WebhookテンプレートはWebhookペイロードに対して追加の検証を提供します。 webHookTypeバインディングプロパティはウェブフック提供者を示し、サポートされるペイロードを制御します:

webHookType設定するときは、methodsプロパティを設定しないでください。

GitHubウェブフックに応答するには、HTTPトリガーで関数を作成し、webHookTypeをgithubに設定し、そのURLとAPIキーをGitHubリポジトリのAdd webhookページにコピーします。

Slackのウェブフックはトークンを生成するので、そのトークンで関数固有のキーを設定してください。

ウェブフック受信コンポーネントはウェブフック認証を担当します。 メカニズムはウェブフックの種類によって異なりますが、それぞれのメカニズムはキーに依存しています。 デフォルトでは、 default という関数キーが使用されます。 別のキーを使用するには、ウェブフックプロバイダーに以下のいずれかの方法でキー名を送信するように設定します。

• clientidクエリ文字列パラメータ(例えばhttps://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>)において。
• x-functions-clientidリクエストヘッダーに記載されています。

HTTPバインディングの設定については、 ランタイム1.x host.json 参照のHTTPセクションを参照してください。

ランタイム1.xでのウォームアップトリガー

ランタイム1.xはウォームアップトリガーをサポートしていません。

ランタイム1.xにおけるSendGridバインディング

プロジェクトにこの拡張機能を追加するには、NuGet パッケージ バージョン 2.x をインストールします。

SendGridのバインディング設定については、 ランタイム1.x host.json リファレンスのSendGridセクションを参照してください。

Twilio binding in runtime 1.x

NuGet パッケージバージョン 1.x をインストールして、拡張機能をプロジェクトに追加します。

ランタイム1.xでは、 function.json ファイル内の以下のバインディング設定プロパティを使用します。

この記事に保存されている拘束情報は、既存のアプリを理解するためにのみ使用してください。 アプリを更新する際は、ランタイム移行ガイドと現在のバインディングドキュメントに従ってください。

よく寄せられる質問

Azure Functions ランタイム 1.x はまだサポートされているのでしょうか?

No. Azure Functions ランタイム1.xのサポートは2026年9月14日に終了しました。 影響を受けたアプリはランタイム4.xに移行して完全なサポートを行ってください。

Python v1 または v4 Node.js プログラミングモデルは Runtime 1.x を使っていますか?

No. 言語プログラミングモデルのバージョンはランタイムバージョンとは独立しています。 Python v1およびv2のプログラミングモデル、Node.js のv3およびv4のプログラミングモデルはランタイム4.x上で動作します。

関連するリソース

• Compare Azure Functions runtime versions
• Azure Functions runtime 1.x support announcement
• Migrate apps from Azure Functions runtime 1.x to 4.x