Core Tools を使用してローカルで Azure Functions を開発する

Azure Functions Core Tools を使用すると、ローカル コンピューター上で関数を開発およびテストできます。 準備ができたら、Core Tools を使用してコード プロジェクトを Azure にデプロイし、アプリケーション設定を操作することもできます。

この記事の C# バージョンが表示されています。 記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の Java バージョンが表示されています。 記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の JavaScript バージョンが表示されています。 記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の PowerShell バージョンが表示されています。 記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の Python バージョンが表示されています。 記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

この記事の TypeScript バージョンが表示されています。 記事の冒頭で、必ず好みの Functions のプログラミング言語を選択してください。

すぐに作業を開始したい場合は、「Core Tools のクイックスタートに関する記事」を完了してください。

Azure Functions Core Tools のインストール

Core Tools をインストールするための推奨される方法は、ローカル開発用コンピューターのオペレーティング システムによって異なります。

次の手順で、Windows インストーラー (MSI) を使用して Core Tools v4.x をインストールします。 その他のパッケージベースのインストーラーの詳細については、Core Tools の Readme をご覧ください。

Windows のバージョンに応じて、 以下の Core Tools インストーラーをダウンロードして実行します。

以前に Windows で Windows インストーラー (MSI) を使用して Core Tools をインストールした場合は、最新のバージョンをインストールする前に、[プログラムの追加と削除] から古いバージョンをアンインストールする必要があります。

バージョン関連の問題のヘルプについては、「Core Tools のバージョン」を参照してください。

ローカル プロジェクトを作成する

重要

Python の場合は、仮想環境で Core Tools コマンドを実行する必要があります。 詳細については、「クイック スタート: Azure でコマンド ラインから Python 関数を作成する」を参照してください。

ターミナル ウィンドウまたはコマンド プロンプトで次のコマンドを実行して、MyProjFolder フォルダーにプロジェクトを作成します。

func init MyProjFolder --worker-runtime dotnet-isolated 

既定では、このコマンドは、現在の長期サポート (LTS) バージョンの .NET Core で Functions ホストを使用してインプロセスで実行されるプロジェクトを作成します。 --target-framework オプションを使用して、.NET Framework を含む、サポートされている特定のバージョンの .NET をターゲットにすることができます。 詳しくは、func init のリファレンスを参照してください。

2 つの .NET プロセス モデル間の比較については、プロセス モードの比較に関する記事を参照してください。

Java では、Maven アーキタイプを使用して、最初の HTTP によってトリガーされる関数と共にローカル プロジェクトを作成します。 func initfunc new を使用する代わりに、コマンド ライン クイックスタートの手順に従ってください。

func init MyProjFolder --worker-runtime javascript --model V4

このコマンドは、必要なプログラミング モデルのバージョンを使用する JavaScript プロジェクトを作成します。

func init MyProjFolder --worker-runtime typescript --model V4

このコマンは、必要なプログラミング モデルのバージョンを使用する TypeScript プロジェクトを作成します。

func init MyProjFolder --worker-runtime powershell
func init MyProjFolder --worker-runtime python --model V2

このコマンドは、必要なプログラミング モデルのバージョンを使用する Python プロジェクトを作成します。

--worker-runtime オプションを指定せずに func init を実行すると、プロジェクトの言語を選択するよう求められます。 func init コマンドで使用できるオプションの詳細については、func init リファレンスを参照してください。

関数を作成する

プロジェクトに関数を追加するには、--template オプションを使用して func new コマンドを実行し、トリガー テンプレートを選択します。 次の例では、MyHttpTrigger という名前の HTTP トリガーを作成します。

func new --template "Http Trigger" --name MyHttpTrigger

この例では、MyQueueTrigger という名前の Queue Storage トリガーを作成します。

func new --template "Azure Queue Storage Trigger" --name MyQueueTrigger

関数を追加する場合は、次の考慮事項が適用されます。

  • --template オプションを指定せずに func new を実行すると、テンプレートを選択するよう求められます。

  • 各言語で使用可能なテンプレートの完全な一覧を表示するには、func templates list コマンドを使用します。

  • サービスに接続するトリガーを追加する場合は、接続文字列またはマネージド ID を参照するアプリケーション設定を local.settings.json ファイルに追加する必要もあります。 この方法でアプリケーション設定を使用すると、コードに資格情報を埋め込む必要がなくなります。 詳細については、「アプリケーション設定の操作」を参照してください。

  • Core Tools では、特定のバインド拡張機能への参照も C# プロジェクトに追加されます。

func new コマンドで使用できるオプションの詳細については、func new リファレンスを参照してください。

関数にバインドを追加する

Functions には一連のサービス固有の入出力バインディングが用意されているため、サービス固有のクライアント SDK を使用しなくても、関数で他の Azure サービスに簡単に接続できます。 詳細については、「Azure Functions でのトリガーとバインドの概念」を参照してください。

既存の関数に入力または出力のバインドを追加するには、関数の定義を手動で更新する必要があります。

次の例は、キュー ストレージの出力バインドHTTP によってトリガーされる関数に追加した後の関数の定義を示しています。

HTTP によってトリガーされる関数は HTTP 応答も返すため、この関数は、HTTP とキューの両方の出力を表す MultiResponse オブジェクトを返します。

[Function("HttpExample")]
public static MultiResponse Run([HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequest req,
    FunctionContext executionContext)
{

この出力バインディングを含む MultiResponse オブジェクトの定義の例をこちらに示します。

public class MultiResponse
{
    [QueueOutput("outqueue",Connection = "AzureWebJobsStorage")]
    public string[] Messages { get; set; }
    public IActionResult HttpResponse { get; set; }
}

この例を独自のプロジェクトに適用する際には、ASP.NET Core 統合を使用しているかどうかによって、HttpRequestHttpRequestData に、IActionResultHttpResponseData に変更する必要がある場合があります。

メッセージは、関数が完了したときにキューに送信されます。 出力バインドを定義する方法は、プロセス モデルによって異なります。 参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

@FunctionName("HttpExample")
public HttpResponseMessage run(
        @HttpTrigger(name = "req", methods = {HttpMethod.GET, HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS) 
        HttpRequestMessage<Optional<String>> request, 
        @QueueOutput(name = "msg", queueName = "outqueue", 
        connection = "AzureWebJobsStorage") OutputBinding<String> msg, 
        final ExecutionContext context) {

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

Node.js モデル v4 のバインド例は、まだ提供されていません。

出力バインドを定義する方法は、Node.js モデルのバージョンによって異なります。 参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

$outputMsg = $name
Push-OutputBinding -name msg -Value $outputMsg

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

@app.route(route="HttpExample")
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpExample(req: func.HttpRequest, msg: func.Out [func.QueueMessage]) -> func.HttpResponse:
    logging.info('Python HTTP trigger function processed a request.')

出力バインドを定義する方法は、Python モデルのバージョンによって異なります。 参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

Node.js モデル v4 のバインド例は、まだ提供されていません。

出力バインドを定義する方法は、Node.js モデルのバージョンによって異なります。 参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

バインドを関数に追加する場合は、次の考慮事項が適用されます。

  • サービスに接続するトリガーを追加する場合は、接続文字列またはマネージド ID を参照するアプリケーション設定を local.settings.json ファイルに追加する必要もあります。 詳細については、「アプリケーション設定の操作」を参照してください。
  • サポートされているバインドを追加する場合、アプリで拡張機能バンドルを使用している場合は、拡張機能が既にインストールされている必要があります。 詳細については、「拡張機能のバンドル」参照してください。
  • 新しいバインド拡張機能を必要とするバインドを追加する場合は、その特定のバインド拡張機能への参照も C# プロジェクトに追加する必要があります。

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

参照できるバインド コードの例へのリンクなど、詳細については、「関数へのバインドの追加」を参照してください。

Functions ランタイムを開始する

プロジェクトで関数を実行またはデバッグする前に、プロジェクトのルート ディレクトリから Functions ホストを起動する必要があります。 ホストによって、プロジェクトのすべての関数に対するトリガーが有効になります。 ローカル ランタイムを起動するには、次のコマンドを使用します。

mvn clean package 
mvn azure-functions:run
func start
npm install
npm start     

このコマンドは仮想環境で実行する必要があります。

Functions ホストが起動すると、次の例のように、HTTP によってトリガーされる関数の URL を含む、プロジェクト内の関数の一覧が出力されます。

Found the following functions:
Host.Functions.MyHttpTrigger

Job host started
Http Function MyHttpTrigger: http://localhost:7071/api/MyHttpTrigger

関数をローカルで実行する場合は、次の点に注意してください。

  • 既定では、HTTP エンドポイントに対して承認はローカルで適用されません。 つまり、ローカルの HTTP 要求はすべて、authLevel = "anonymous" として処理されます。 詳細については、HTTP バインディングに関する記事を参照してください。 --enableAuth オプションを使用して、ローカルで実行するときに認可を要求できます。 詳細については、func start を参照してください

  • Azure Storage サービス (Queue Storage、Blob Storage、および Table Storage) へのアクセスを必要とする関数を Azure 内のこれらのサービスに接続することなくローカルで実行するには、ローカル Azurite エミュレーターを使用することができます。 ローカル エミュレーションを使用する際には、ローカル ホスト (func.exe) を開始する前に Azurite を起動するようにしてください。 詳細については、「ローカル ストレージ エミュレーション」を参照してください。

  • ローカル Azurite エミュレーションを使用して、Python v2 worker のストレージ要件を満たすことができます。
  • ライブ サービスに接続しなくても、HTTP 以外の関数をローカルでトリガーできます。 詳細については、「ローカル関数を実行する」を参照してください。

  • local.settings.json ファイルに Application Insights 接続情報を含めると、ローカル ログ データが特定の Application Insights インスタンスに書き込まれます。 ローカル テレメトリ データを運用データから分離するには、開発とテストに個別の Application Insights インスタンスを使用することを検討してください。

  • Core Tools のバージョン 1.x を使用する場合は、代わりに func host start コマンドを使用してローカル ランタイムを開始します。

ローカル関数を実行する

実行中のローカルの Functions ホスト (func.exe) を使用して、個々の関数をトリガーして関数コードを実行およびデバッグできるようになりました。 個々の関数を実行する方法は、トリガーの種類によって異なります。

Note

このトピックの例では、cURL ツールを使用してターミナルまたはコマンド プロンプトから HTTP 要求を送信します。 お好みのツールを使用して HTTP 要求をローカル サーバーに送信できます。 Linux ベースのシステムと Windows 10 ビルド 17063 以降では既定で cURL ツールを使用できます。 以前の Windows では、最初に cURL ツールをダウンロードし、インストールする必要があります。

HTTP トリガーは、func.exe 出力に表示されるように、次の一般的な形式のローカル エンドポイントとポートに HTTP 要求を送信することによって開始されます。

http://localhost:<PORT>/api/<FUNCTION_NAME>

この URL テンプレートで、<FUNCTION_NAME> は関数またはルートの名前であり、<PORT> は func.exe がリッスンしているローカル ポートです。

たとえば、この cURL コマンドは、MyHttpTrigger クイックスタート関数を、クエリ文字列で渡された name パラメーターを使用して、GET 要求からトリガーします。

curl --get http://localhost:7071/api/MyHttpTrigger?name=Azure%20Rocks

この例は、要求本文で name を渡す POST 要求から呼び出される同じ関数であり、Bash シェルと Windows コマンド ラインの両方で示されています。

curl --request POST http://localhost:7071/api/MyHttpTrigger --data '{"name":"Azure Rocks"}'
curl --request POST http://localhost:7071/api/MyHttpTrigger --data "{'name':'Azure Rocks'}"

HTTP エンドポイントをローカルで呼び出す場合は、次の考慮事項が適用されます。

  • ブラウザーから GET 要求を行ってクエリ文字列でデータを渡すことが可能です。 その他すべての HTTP メソッドについては、cURL、Fiddler、Postman、または POST 要求をサポートする類似の HTTP テスト ツールを使用する必要があります。

  • Functions ホストがリッスンしているのと同じサーバー名とポートを使用していることを確認してください。 このようなエンドポイントは、関数ホストの起動時に生成される出力で確認できます。 トリガーでサポートされている任意の HTTP メソッドを使用して、この URL を呼び出すことができます。

Azure に発行する

Azure Functions Core Tools は、次の 3 種類のデプロイをサポートしています。

展開の種類 コマンド 説明
プロジェクト ファイル func azure functionapp publish zip デプロイを使用し、関数プロジェクト ファイルを関数アプリに直接デプロイします。
Azure Container Apps func azurecontainerapps deploy コンテナー化された関数アプリを既存の Container Apps 環境にデプロイします。
Kubernetes クラスター func kubernetes deploy Linux 関数アプリを、カスタム Docker コンテナーとして Kubernetes クラスターにデプロイします。

Core Tools から Azure に発行できるようにするには、Azure CLI または Azure PowerShell のいずれかがローカルにインストールされている必要があります。 既定では、Core Tools はこれらのツールを使用して Azure アカウントで認証します。

これらのツールがインストールされていない場合は、代わりに、展開中に使用する有効なアクセス トークンを取得する必要があります。 デプロイ コマンドの --access-token オプションを使用して、アクセス トークンを提示できます。

プロジェクト ファイルのデプロイ

Azure で ローカル コードを関数アプリに発行するには、次の例のように func azure functionapp publish publish コマンドを使用します:

func azure functionapp publish <FunctionAppName>

このコマンドは、プロジェクト ファイルを現在のディレクトリから .zip 展開パッケージとして <FunctionAppName> に発行します。 プロジェクトにコンパイルが必要な場合は、展開中にリモートで実行されます。

Java では、Maven を使用して、Core Tools ではなくローカル プロジェクトを Azure に発行します。 次の Maven コマンドを使用して、プロジェクトを Azure に発行します:

mvn azure-functions:deploy

このコマンドを実行すると、pom.xml ファイルの設定に基づいて、初期デプロイ中に Azure リソースが作成されます。 詳細については、「関数プロジェクトを Azure にデプロイする」を参照してください。

このデプロイには、次の考慮事項が適用されます。

  • 発行すると、リモート関数アプリのデプロイ内の既存のファイルが上書きされます。

  • 既に Azure サブスクリプションで関数アプリを作成してある必要があります。 Core Tools は、プロジェクト コードをこの関数アプリ リソースにデプロイします。 Azure CLI または Azure PowerShell を使用してコマンド プロンプトまたはターミナル ウィンドウから関数アプリを作成する方法については、「サーバーレス実行用の Function App を作成する」を参照してください。 これらのリソースを Azure portal で作成することもできます。 サブスクリプションに存在しない <FunctionAppName> を公開しようとすると、エラーが表示されます。

  • プロジェクト フォルダーには、発行するべきではない言語固有のファイルやディレクトリが含まれている場合があります。 除外された項目は、ルート プロジェクト フォルダーの .funcignore ファイルにリストされます。

  • 既定では、プロジェクトがデプロイ パッケージから実行されるようにデプロイされます。 この推奨されるデプロイ モードを無効にするには、--nozip オプションを使用します。

  • コンパイルされたプロジェクトでリモート ビルドが実行されます。 これは、--no-build オプションを使用して制御できます。

  • --publish-local-settings オプションを使用して、local.settings.json ファイルの値に基づいて、関数アプリにアプリ設定を自動的に作成します。

  • 関数アプリの特定の名前付きスロットに公開するには、--slot オプションを使用します。

コンテナーをデプロイする

Core Tools を使用すると、マネージド Azure Container Apps 環境と、管理する Kubernetes クラスターの両方にコンテナー化された関数アプリをデプロイできます。

次の func azurecontainerapps deploy コマンドを使用して、既存のコンテナー イメージを Container Apps 環境にデプロイします:

func azurecontainerapps deploy --name <APP_NAME> --environment <ENVIRONMENT_NAME> --storage-account <STORAGE_CONNECTION> --resource-group <RESOURCE_GROUP> --image-name <IMAGE_NAME> [--registry-password] [--registry-server] [--registry-username]

Azure Container Apps 環境にデプロイする場合は、次の考慮事項が適用されます。

  • 環境とストレージ アカウントが既に存在している必要があります。 指定したストレージ アカウント接続文字列は、デプロイされた関数アプリによって使用されます。

  • Container Apps にデプロイするときは、別の関数アプリ リソースを作成する必要はありません。

  • ストレージ接続文字列とその他のサービス資格情報は重要なシークレットです。 func azurecontainerapps deploy を使用してスクリプト ファイルを安全に格納し、パブリックにアクセス可能なソース管理システムには保存しないようにしてください。 local.settings.json ファイルを暗号化して、セキュリティを強化することができます。

詳細については、「Azure Functions の Azure Container Apps ホスティング」を参照してください。

ローカルでアプリの設定を操作する

Azure の関数アプリで実行する場合、関数に必要な設定はアプリ設定に安全に保存されます。 ローカル開発中は、これらの設定は代わりに local.settings.json ファイルの Values コレクションに追加されます。 local.settings.json ファイルには、ローカルの開発ツールによって使用される設定も格納されます。

プロジェクトの local.settings.json ファイルの Values コレクションにある項目は、Azure の関数アプリのアプリケーション設定にある項目をミラー化するためのものです。

ローカル設定ファイルを使用する場合は、次の考慮事項が適用されます。

  • local.settings.json には接続文字列などのシークレットが含まれている場合があるため、リモート リポジトリには絶対に格納しないようにしてください。 Core Tools は、このローカル設定ファイルを暗号化してセキュリティを強化するのに役立ちます。 詳細については、「ローカル設定ファイル」を参照してください。 local.settings.json ファイルを暗号化して、セキュリティを強化することもできます。

  • 既定では、プロジェクトが Azure に発行されても、これらの設定は自動的に移行されません。 プロジェクト ファイルを発行する際に --publish-local-settings オプションを使用し、これらの設定が Azure 内の関数アプリに追加されるようにしてください。 ConnectionStrings セクション内の値は発行されません。 また、いつでも local.settings.json ファイルから設定をアップロードすることができます。

  • local.settings.json ファイルの設定をダウンロードして、Azure の関数アプリの設定で上書きすることができます。 詳細については、「アプリケーション設定のダウンロード」を参照してください。

  • 関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。 詳細については、「環境変数」を参照してください。
  • 関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。 詳細については、「環境変数」を参照してください。
  • 関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。 詳細については、「環境変数」を参照してください。
  • 関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。 詳細については、「環境変数」を参照してください。
  • 関数アプリの設定値は、コードの中で環境変数として読み込むこともできます。 詳細については、「環境変数」を参照してください。
  • AzureWebJobsStorage に有効なストレージ接続文字列が設定されておらず、ローカル ストレージ エミュレーターが使用されていない場合は、エラー メッセージが表示されます。 Core Tools を使用して、任意の Azure Storage アカウントから特定の接続文字列をダウンロードできます。

アプリケーション設定をダウンロードする

プロジェクトのルートから、次のコマンドを使用して、Azure の myfunctionapp12345 アプリからすべてのアプリケーション設定をダウンロードします。

func azure functionapp fetch-app-settings myfunctionapp12345

このコマンドは、local.settings.json ファイル内のすべての既存の設定を Azure の値で上書きします。 既に存在していない場合は、新しい項目がコレクションに追加されます。 詳細については、func azure functionapp fetch-app-settings コマンドを参照してください。

ストレージ接続文字列のダウンロード

また、Core Tools を使用すると、アクセスできる任意のストレージ アカウントの接続文字列を簡単に取得できます。 プロジェクトのルートから、次のコマンドを使用して、mystorage12345 という名前のストレージ アカウントから接続文字列をダウンロードします。

func azure storage fetch-connection-string mystorage12345

このコマンドは、mystorage12345_STORAGE という名前の設定を local.settings.json ファイルに追加します。この設定には、mystorage12345 アカウントの接続文字列が含まれています。 詳細については、func azure storage fetch-connection-string コマンドを参照してください。

開発中のセキュリティを強化するために、local.settings.json ファイルの暗号化を検討してください。

Azure にローカル設定をアップロードする

--publish-local-settings オプションを使用せずにプロジェクト ファイルを Azure に発行する場合、local.settings.json ファイルの設定は関数アプリでは設定されません。 プロジェクト ファイルを再発行せずに設定のみをアップロードする --publish-settings-only オプションを使用して、いつでも func azure functionapp publish を再実行できます。

次の例では、local.settings.json ファイルの Values コレクションから設定のみを myfunctionapp12345 という名前の Azure の関数アプリにアップロードします。

func azure functionapp publish myfunctionapp12345 --publish-settings-only

ローカル設定ファイルを暗号化する

ローカル設定の接続文字列やその他の重要なデータのセキュリティを強化するために、Core Tools では local.settings.json ファイルを暗号化できます。 このファイルが暗号化されると、Azure のアプリケーション設定と同じように、必要に応じてランタイムが設定の暗号化を自動的に解除します。 ローカルで暗号化されたファイルの暗号化を解除して、設定を操作することもできます。

次のコマンドを使用して、プロジェクトのローカル設定ファイルを暗号化します。

func settings encrypt

ローカル設定を操作できるように、次のコマンドを使用して、暗号化されたローカル設定の暗号化を解除します。

func settings decrypt

設定ファイルが暗号化され、暗号化解除されると、ファイルの IsEncrypted の設定も更新されます。

バインド拡張機能を構成する

Functions のトリガーとバインドは .NET 拡張機能 (NuGet) パッケージとして実装されています。 特定のバインド拡張機能を使用できるようにするには、その拡張機能をプロジェクトにインストールする必要があります。

このセクションは、Functions ランタイムのバージョン 1.x にはあてはまりません。 バージョン 1.x では、サポートされたバインドはコア製品拡張機能に含まれていました。

C# クラス ライブラリ プロジェクトに対しては、関数に必要なバインド拡張機能のための特定の NuGet パッケージへの参照を追加します。 C# スクリプト (.csx) プロジェクトでは、拡張機能バンドルを使用する必要があります。

Functions には、プロジェクト内のバインド拡張機能を操作しやすくするための拡張機能バンドルが用意されています。 host.json ファイルでバージョン管理され、定義される拡張機能バンドルは、アプリのための互換性のあるバインド拡張機能パッケージの完全なセットをインストールします。 host.json で拡張機能バンドルが既に有効になっている必要があります。 何らかの理由で host.json ファイルの拡張機能バンドルを追加または更新する必要がある場合は、「拡張機能バンドル」を参照してください。

サポートされているバンドルにないバインド拡張機能または拡張機能のバージョンを使用する必要がある場合は、拡張機能を手動でインストールする必要があります。 このようなまれなシナリオについては、func extensions install コマンドを参照してください。

Core Tools のバージョン

Azure Functions Core Tools のメジャー バージョンは、Azure Functions ランタイムの特定のメジャー バージョンとリンクしています。 たとえば、Core Tools のバージョン 4.x では、Functions ランタイムのバージョン 4.x がサポートされています。 これは、Functions ランタイムと Core Tools の両方で推奨されるメジャー バージョンです。 最新の Core Tools リリース バージョンは、Azure Functions Core Tools リポジトリで確認できます。

次のコマンドを実行して、現在の Core Tools インストールのバージョンを確認します。

func --version

特に記載がない限り、この記事の例ではバージョン 4.x を対象にしています。

Core Tools のインストールには、次の考慮事項が適用されます。

  • 特定のコンピューターには、1 つのバージョンの Core Tools のみをインストールできます。

  • 最新バージョンの Core Tools にアップグレードする場合は、元のインストールの使用したのと同じ方法を使用してアップグレードを実行する必要があります。 たとえば、Windows で MSI を使用した場合は、現在の MSI をアンインストールし、最新のものをインストールします。 または、npm を使用した場合は、npm install command を再実行します。

  • Core Tools のバージョン 2.x と 3.x は、サポート終了になった Functions ランタイムのバージョン 2.x と 3.x で使われていました。 詳細については、「Azure Functions ランタイム バージョンをターゲットにする方法」をご覧ください。

  • Core Tools のバージョン 1.x は、まだサポートされているバージョン 1.x の Functions ランタイムを使用する場合に必要です。 Core Tools のこのバージョンは、Windows コンピューターでのローカル実行のみが行えます。 現在バージョン 1.x で実行している場合は、今すぐにでもアプリをバージョン 4.x に移行することを検討する必要があります。

Visual Studio Code を使用している場合は、Rosetta を組み込みのターミナルと統合できます。 詳細については、「Visual Studio Code でエミュレーションを有効にする」を参照してください。

次のステップ

Azure Functions Core Tools を使用した Azure Functions の開発、テスト、および発行方法について学習します。 Azure Functions Core Tools はオープン ソースであり、GitHub でホストされています。 バグまたは機能要求を提出するには、GitHub の問題をオープンしてください。