Azure Functions の JavaScript 開発者向けガイドAzure Functions JavaScript developer guide

このガイドでは、JavaScript を使用した Azure Functions の開発を成功させるために役立つ詳細情報について説明します。This guide contains detailed information to help you succeed developing Azure Functions using JavaScript.

Express.js、Node.js、または JavaScript の開発者が、Azure Functions を初めて使用する場合は、まず次のいずれかの記事を読むことをお勧めします。As an Express.js, Node.js, or JavaScript developer, if you are new to Azure Functions, please consider first reading one of the following articles:

作業の開始Getting started 概念Concepts ガイド付き学習Guided learning

JavaScript 関数の基本JavaScript function basics

JavaScript (Node.js) 関数はエクスポートされた function であり、トリガーされると実行します (トリガーは function.json で構成します)。A JavaScript (Node.js) function is an exported function that executes when triggered (triggers are configured in function.json). 各関数に渡される最初の引数は context オブジェクトで、バインディング データの送受信、ログ記録、ランタイムとの通信に使用されます。The first argument passed to every function is a context object, which is used for receiving and sending binding data, logging, and communicating with the runtime.

フォルダー構造Folder structure

JavaScript プロジェクトでは、次のようなフォルダー構造が必要です。The required folder structure for a JavaScript project looks like the following. この既定値は変更可能です。This default can be changed. 詳しくは、後の scriptFile に関するセクションをご覧ください。For more information, see the scriptFile section below.

 | - MyFirstFunction
 | | - index.js
 | | - function.json
 | - MySecondFunction
 | | - index.js
 | | - function.json
 | - SharedCode
 | | - myFirstHelperFunction.js
 | | - mySecondHelperFunction.js
 | - node_modules
 | - host.json
 | - package.json
 | - extensions.csproj

プロジェクトのルートには、関数アプリの構成に使用できる共有 host.json ファイルがあります。At the root of the project, there's a shared host.json file that can be used to configure the function app. 各関数には、独自のコード ファイル (.js) とバインド構成ファイル (function.json) が含まれるフォルダーがあります。Each function has a folder with its own code file (.js) and binding configuration file (function.json). function.json の親ディレクトリの名前は常に関数の名前です。The name of function.json's parent directory is always the name of your function.

Functions ランタイムのバージョン 2.x に必要なバインディング拡張機能は extensions.csproj ファイル内に定義されており、実際のライブラリ ファイルは bin フォルダーにあります。The binding extensions required in version 2.x of the Functions runtime are defined in the extensions.csproj file, with the actual library files in the bin folder. ローカルで開発する場合は、バインド拡張機能を登録する必要があります。When developing locally, you must register binding extensions. Azure portal 上で関数を開発するときに、この登録が実行されます。When developing functions in the Azure portal, this registration is done for you.

関数のエクスポートExporting a function

module.exports (または exports) を使用して、JavaScript 関数をエクスポートする必要があります。JavaScript functions must be exported via module.exports (or exports). エクスポートする関数は、トリガーされたときに実行される JavaScript 関数である必要があります。Your exported function should be a JavaScript function that executes when triggered.

既定では、Functions ランタイムは index.js で関数を検索します。index.js は、対応する function.json と同じ親ディレクトリを共有します。By default, the Functions runtime looks for your function in index.js, where index.js shares the same parent directory as its corresponding function.json. 既定では、エクスポートされる関数は、そのファイルからの唯一のエクスポートである必要があります (run または index という名前のエクスポート)。In the default case, your exported function should be the only export from its file or the export named run or index. 関数のファイルの場所とエクスポートの名前を構成する方法については、後の「関数のエントリ ポイントを構成する」をご覧ください。To configure the file location and export name of your function, read about configuring your function's entry point below.

エクスポートされる関数には、実行時に多数の引数が渡されます。Your exported function is passed a number of arguments on execution. 受け取る最初の引数は常に、context オブジェクトです。The first argument it takes is always a context object. 関数が同期の場合 (Promise を返しません)、正しく使用するためには context.done の呼び出しが必要なので、context オブジェクトを渡す必要があります。If your function is synchronous (doesn't return a Promise), you must pass the context object, as calling context.done is required for correct use.

// You should include context, other arguments are optional
module.exports = function(context, myTrigger, myInput, myOtherInput) {
    // function logic goes here :)

async function をエクスポートするExporting an async function

async function 宣言またはバージョン 2.x の Functions ランタイムでプレーンな JavaScript の Promise を使用するときは、context.done コールバックを呼び出して関数が完了したことを明示的に通知する必要はありません。When using the async function declaration or plain JavaScript Promises in version 2.x of the Functions runtime, you do not need to explicitly call the context.done callback to signal that your function has completed. エクスポートされた async function/Promise が完了すると、関数は完了します。Your function completes when the exported async function/Promise completes. バージョン 1.x ランタイムを対象とする関数では、引き続きコードの実行が完了した際に context.done を呼び出す必要があります。For functions targeting the version 1.x runtime, you must still call context.done when your code is done executing.

次の例で示すのは、トリガーされてすぐに実行が完了したことを記録する簡単な関数です。The following example is a simple function that logs that it was triggered and immediately completes execution.

module.exports = async function (context) {
    context.log('JavaScript trigger function processed a request.');

async function をエクスポートするときは、return の値を取得するための出力バインドを構成することもできます。When exporting an async function, you can also configure an output binding to take the return value. これは、出力バインドが 1 つしかない場合に推奨されます。This is recommended if you only have one output binding.

return を使用して出力を割り当てるには、function.jsonname プロパティを $return に変更します。To assign an output using return, change the name property to $return in function.json.

  "type": "http",
  "direction": "out",
  "name": "$return"

この場合、関数は次の例のようになります。In this case, your function should look like the following example:

module.exports = async function (context, req) {
    context.log('JavaScript HTTP trigger function processed a request.');
    // You can call and await an async method here
    return {
        body: "Hello, world!"


JavaScript では、バインドが構成され、関数の function.json で定義されます。In JavaScript, bindings are configured and defined in a function's function.json. 関数は、さまざまな方法でバインドを操作します。Functions interact with bindings a number of ways.


Azure Functions では、入力は、トリガー入力と追加入力という 2 つのカテゴリに分けられます。Input are divided into two categories in Azure Functions: one is the trigger input and the other is the additional input. 関数は、トリガーと他の入力バインド (direction === "in" のバインド) を 3 つの方法で読み取ることができます。Trigger and other input bindings (bindings of direction === "in") can be read by a function in three ways:

  • [推奨] 関数に渡されるパラメーターを使用します。[Recommended] As parameters passed to your function. それらは、function.json に定義されている順序で関数に渡されます。They are passed to the function in the same order that they are defined in function.json. function.json で定義されている name プロパティは、パラメーターの名前と一致する方が望ましいですが、必ずしもそうする必要はありません。The name property defined in function.json does not need to match the name of your parameter, although it should.

    module.exports = async function(context, myTrigger, myInput, myOtherInput) { ... };
  • context.bindings オブジェクトのメンバーを使用します。As members of the context.bindings object. 各メンバーの名前は、function.json で定義されている name プロパティによって決まります。Each member is named by the name property defined in function.json.

    module.exports = async function(context) { 
        context.log("This is myTrigger: " + context.bindings.myTrigger);
        context.log("This is myInput: " + context.bindings.myInput);
        context.log("This is myOtherInput: " + context.bindings.myOtherInput);
  • JavaScript の arguments オブジェクトの入力を使用します。As inputs using the JavaScript arguments object. これは、基本的にパラメーターとして入力を渡すのと同じですが、動的に入力を処理することができます。This is essentially the same as passing inputs as parameters, but allows you to dynamically handle inputs.

    module.exports = async function(context) { 
        context.log("This is myTrigger: " + arguments[1]);
        context.log("This is myInput: " + arguments[2]);
        context.log("This is myOtherInput: " + arguments[3]);


関数は、さまざまな方法で出力 (direction === "out" のバインド) に書き込むことができます。Outputs (bindings of direction === "out") can be written to by a function in a number of ways. どの場合も、function.json で定義されているバインドの name プロパティは、関数に書き込むオブジェクトのメンバーの名前に対応しています。In all cases, the name property of the binding as defined in function.json corresponds to the name of the object member written to in your function.

次の方法のいずれかで (これらの方法を組み合わせることはできません)、出力バインドにデータを割り当てることができます。You can assign data to output bindings in one of the following ways (don't combine these methods):

  • [出力が複数の場合に推奨] オブジェクトを返します。[Recommended for multiple outputs] Returning an object. 非同期関数または Promise を返す関数を使用している場合は、割り当てられた出力データを含むオブジェクトを返すことができます。If you are using an async/Promise returning function, you can return an object with assigned output data. 次の例の出力バインドは、function.json で "httpResponse" および "queueOutput" という名前が付けられています。In the example below, the output bindings are named "httpResponse" and "queueOutput" in function.json.

    module.exports = async function(context) {
        let retMsg = 'Hello, world!';
        return {
            httpResponse: {
                body: retMsg
            queueOutput: retMsg

    同期関数を使用している場合、context.done を使用してこのオブジェクトを返すことができます (例を参照)。If you are using a synchronous function, you can return this object using context.done (see example).

  • [出力が 1 つの場合に推奨] 直接値を返し $return バインド名を使用します。[Recommended for single output] Returning a value directly and using the $return binding name. これは、関数を返す非同期/Promise でのみ機能します。This only works for async/Promise returning functions. async function をエクスポートする」の例を参照してください。See example in exporting an async function.

  • context.bindings に値を割り当てます。 context.bindings に直接値を割り当てることができます。Assigning values to context.bindings You can assign values directly to context.bindings.

    module.exports = async function(context) {
        let retMsg = 'Hello, world!';
        context.bindings.httpResponse = {
            body: retMsg
        context.bindings.queueOutput = retMsg;

バインドのデータ型Bindings data type

入力バインドのデータ型を定義するには、バインド定義の dataType プロパティを使用します。To define the data type for an input binding, use the dataType property in the binding definition. たとえば、バイナリ形式で HTTP 要求のコンテンツを読み取るには、binary 型を使用します。For example, to read the content of an HTTP request in binary format, use the type binary:

    "type": "httpTrigger",
    "name": "req",
    "direction": "in",
    "dataType": "binary"

dataType のオプションは、binarystreamstring です。Options for dataType are: binary, stream, and string.

context オブジェクトcontext object

ランタイムは context オブジェクトを使用して、関数とランタイムとの間でデータを受け渡します。The runtime uses a context object to pass data to and from your function and the runtime. バインドからのデータの読み取りと設定や、ログへの書き込みのために使用される context オブジェクトは常に、関数に渡される最初のパラメーターです。Used to read and set data from bindings and for writing to logs, the context object is always the first parameter passed to a function.

同期コードを備えた関数の場合は、context オブジェクトに、その関数が処理を完了したときに呼び出す done コールバックが含まれています。For functions featuring synchronous code, the context object includes the done callback which you call when the function is done processing. 非同期コードを記述する場合は、done を明示的に呼び出す必要はありません。done コールバックは暗黙的に呼び出されます。Explicitly calling done is unnecessary when writing asynchronous code; the done callback is called implicitly.

module.exports = (context) => {

    // function logic goes here

    context.log("The function has executed.");


関数に渡されるコンテキストでは、次のプロパティを持つオブジェクトである executionContext プロパティが公開されます。The context passed into your function exposes an executionContext property, which is an object with the following properties:

プロパティ名Property name TypeType 説明Description
invocationId StringString 特定の関数呼び出しのための一意識別子を提供します。Provides a unique identifier for the specific function invocation.
functionName StringString 実行中の関数の名前を提供します。Provides the name of the running function
functionDirectory StringString 関数のアプリ ディレクトリを提供します。Provides the functions app directory.

次の例は、invocationId を返す方法を示しています。The following example shows how to return the invocationId.

module.exports = (context, req) => {
    context.res = {
        body: context.executionContext.invocationId

context.bindings プロパティcontext.bindings property


バインド データの読み取りまたは割り当てに使用される名前付きオブジェクトを返します。Returns a named object that is used to read or assign binding data. 入力およびトリガー バインド データには、context.bindings のプロパティを読み取ることでアクセスできます。Input and trigger binding data can be accessed by reading properties on context.bindings. 出力バインド データは、context.bindings にデータを追加することで割り当てることができます。Output binding data can be assigned by adding data to context.bindings

たとえば、function.json で次のようなバインド定義を使用すると、context.bindings.myInput からキューの内容にアクセスし、context.bindings.myOutput を使用して出力をキューに割り当てることができます。For example, the following binding definitions in your function.json let you access the contents of a queue from context.bindings.myInput and assign outputs to a queue using context.bindings.myOutput.

// myInput contains the input data, which may have properties such as "name"
var author =;
// Similarly, you can set your output data
context.bindings.myOutput = { 
        some_text: 'hello world', 
        a_number: 1 };

context.binding オブジェクトの代わりに context.done メソッドを使用して、出力バインド データを定義できます (下記参照)。You can choose to define output binding data using the context.done method instead of the context.binding object (see below).

context.bindingData プロパティcontext.bindingData property


トリガーのメタデータと関数呼び出しデータを含む名前付きオブジェクトを返します (invocationIdsys.methodNamesys.utcNowsys.randGuid)。Returns a named object that contains trigger metadata and function invocation data (invocationId, sys.methodName, sys.utcNow, sys.randGuid). トリガーのメタデータの例については、こちらのイベント ハブの例をご覧ください。For an example of trigger metadata, see this event hubs example.

context.done メソッドcontext.done method


ランタイムにコードが完了したことを知らせます。Lets the runtime know that your code has completed. 関数で async function 宣言を使用する場合、context.done() を使用する必要はありません。When your function uses the async function declaration, you do not need to use context.done(). context.done コールバックは暗黙的に呼び出されます。The context.done callback is implicitly called. 非同期関数は Node 8 以降のバージョンで使用できますが、それにはバージョン 2.x の Functions ランタイムが必要です。Async functions are available in Node 8 or a later version, which requires version 2.x of the Functions runtime.

関数が非同期関数ではない場合、関数が完了したことをランタイムに通知するために呼び出す必要があります context.doneIf your function is not an async function, you must call context.done to inform the runtime that your function is complete. これがない場合、実行はタイムアウトします。The execution times out if it is missing.

context.done メソッドを使用すると、ランタイムに対するユーザー定義のエラーと、出力バインド データを含む JSON オブジェクトの両方を、戻すことができます。The context.done method allows you to pass back both a user-defined error to the runtime and a JSON object containing output binding data. context.done に渡されるプロパティは、context.bindings オブジェクトで設定されているすべてのものを上書きします。Properties passed to context.done overwrite anything set on the context.bindings object.

// Even though we set myOutput to have:
//  -> text: 'hello world', number: 123
context.bindings.myOutput = { text: 'hello world', number: 123 };
// If we pass an object to the done function...
context.done(null, { myOutput: { text: 'hello there, world', noNumber: true }});
// the done method overwrites the myOutput binding to be: 
//  -> text: 'hello there, world', noNumber: true

context.log メソッドcontext.log method


既定のトレース レベルでストリーミング関数ログに書き込むことができます。Allows you to write to the streaming function logs at the default trace level. context.log には、他のトレース レベルで関数のログを書き込むことができる追加のログ記録メソッドがあります。On context.log, additional logging methods are available that let you write function logs at other trace levels:

MethodMethod 説明Description
error(message)error(message) エラー レベルのログ、またはそれ以下に書き込みます。Writes to error level logging, or lower.
warn(message)warn(message) 警告レベルのログ、またはそれ以下に書き込みます。Writes to warning level logging, or lower.
info(message)info(message) 情報レベルのログ、またはそれ以下に書き込みます。Writes to info level logging, or lower.
verbose(message)verbose(message) 詳細なレベルのログに書き込みます。Writes to verbose level logging.

次の例では、警告トレース レベルでログを書き込んでいます。The following example writes a log at the warning trace level:

context.log.warn("Something has happened."); 

host.json ファイルでは、ログに対するトレース レベルのしきい値を構成することができます。You can configure the trace-level threshold for logging in the host.json file. ログの書き込みについて詳しくは、後の「トレース出力をコンソールに書き込む」をご覧ください。For more information on writing logs, see writing trace outputs below.

関数のログの表示とクエリについて詳しくは、「Azure Functions を監視する」をご覧ください。Read monitoring Azure Functions to learn more about viewing and querying function logs.

トレース出力をコンソールに書き込むWriting trace output to the console

関数で、context.log メソッドを使用してトレース出力をコンソールに書き込みます。In Functions, you use the context.log methods to write trace output to the console. Functions v2.x では、console.log を使用するトレース出力は Function App レベルでキャプチャされます。In Functions v2.x, trace outputs using console.log are captured at the Function App level. つまり、console.log からの出力は特定の関数呼び出しに関連付けられておらず、特定の関数のログには表示されません。This means that outputs from console.log are not tied to a specific function invocation and aren't displayed in a specific function's logs. ただし、Application Insights に伝達されます。They do, however, propagate to Application Insights. Functions v1.x では、console.log を使用してコンソールに書き込むことはできません。In Functions v1.x, you cannot use console.log to write to the console.

context.log() を呼び出すと、既定のトレース レベルである、情報 トレース レベルでコンソールにメッセージが書き込まれます。When you call context.log(), your message is written to the console at the default trace level, which is the info trace level. 次のコードは、情報トレース レベルでコンソールに書き込みます。The following code writes to the console at the info trace level:

context.log({hello: 'world'});  

次のコードは、上記のコードと同等です。This code is equivalent to the code above:{hello: 'world'});  

このコードは、エラー レベルでコンソールに書き込みます。This code writes to the console at the error level:

context.log.error("An error has occurred.");  

エラー は最高のトレース レベルであるため、ログ記録が有効になっている限り、このトレースはすべてのトレース レベルで出力に書き込まれます。Because error is the highest trace level, this trace is written to the output at all trace levels as long as logging is enabled.

すべての context.log メソッドは、Node.js の util.format メソッドでサポートされているのと同じパラメーター形式をサポートしています。All context.log methods support the same parameter format that's supported by the Node.js util.format method. 既定のトレース レベルを使用して関数ログに書き込む次のようなコードについて考えます。Consider the following code, which writes function logs by using the default trace level:

context.log('Node.js HTTP trigger function processed a request. RequestUri=' + req.originalUrl);
context.log('Request Headers = ' + JSON.stringify(req.headers));

同じコードを次の形式で記述することもできます。You can also write the same code in the following format:

context.log('Node.js HTTP trigger function processed a request. RequestUri=%s', req.originalUrl);
context.log('Request Headers = ', JSON.stringify(req.headers));

コンソール ログのトレース レベルを構成するConfigure the trace level for console logging

関数 1.x を使用して、コンソールに書き込むためのしきい値のトレース レベルを定義できます。これによって、関数からコンソールにトレースを書き込む方法を簡単に制御できます。Functions 1.x lets you define the threshold trace level for writing to the console, which makes it easy to control the way traces are written to the console from your function. コンソールに書き込まれるすべてのトレースのしきい値を設定するには、host.json ファイルの tracing.consoleLevel プロパティを使用します。To set the threshold for all traces written to the console, use the tracing.consoleLevel property in the host.json file. この設定は、関数アプリのすべての関数に適用されます。This setting applies to all functions in your function app. 次の例では、詳細ログ記録が有効になるようにトレースのしきい値を設定します。The following example sets the trace threshold to enable verbose logging:

    "tracing": {
        "consoleLevel": "verbose"

consoleLevel の値は、context.log メソッドの名前に対応します。Values of consoleLevel correspond to the names of the context.log methods. コンソールへのすべてのトレース ログ記録を無効にするには、consoleLeveloff に設定します。To disable all trace logging to the console, set consoleLevel to off. 詳細については、host.json のリファレンスを参照してください。For more information, see host.json reference.

HTTP トリガーとバインディングHTTP triggers and bindings

HTTP、webhook トリガー、および HTTP 出力バインディングでは、要求オブジェクトと応答オブジェクトを使用して HTTP メッセージングを表します。HTTP and webhook triggers and HTTP output bindings use request and response objects to represent the HTTP messaging.

要求オブジェクトRequest object

context.req (要求) オブジェクトには、次のプロパティがあります。The context.req (request) object has the following properties:

プロパティProperty 説明Description
bodybody 要求の本文を格納するオブジェクト。An object that contains the body of the request.
headersheaders 要求ヘッダーを格納するオブジェクト。An object that contains the request headers.
methodmethod 要求の HTTP メソッド。The HTTP method of the request.
originalUrloriginalUrl 要求の URL。The URL of the request.
paramsparams 要求のルーティング パラメーターを格納するオブジェクト。An object that contains the routing parameters of the request.
queryquery クエリ パラメーターを格納するオブジェクト。An object that contains the query parameters.
rawBodyrawBody 文字列としてのメッセージの本文。The body of the message as a string.

応答オブジェクトResponse object

context.res (応答) オブジェクトには、次のプロパティがあります。The context.res (response) object has the following properties:

プロパティProperty 説明Description
bodybody 応答の本文を格納するオブジェクト。An object that contains the body of the response.
headersheaders 応答ヘッダーを格納するオブジェクト。An object that contains the response headers.
isRawisRaw 応答の書式設定をスキップすることを示します。Indicates that formatting is skipped for the response.
statusstatus 応答の HTTP 状態コード。The HTTP status code of the response.
cookiescookies 応答に設定される HTTP Cookie オブジェクトの配列。An array of HTTP cookie objects that are set in the response. HTTP Cookie オブジェクトには、namevalue、およびその他の Cookie プロパティ (maxAgesameSite など) があります。An HTTP cookie object has a name, value, and other cookie properties, such as maxAge or sameSite.

要求と応答へのアクセスAccessing the request and response

HTTP トリガーを使用する場合、HTTP 要求オブジェクトと応答オブジェクトにアクセスする方法がいくつかあります。When you work with HTTP triggers, you can access the HTTP request and response objects in a number of ways:

  • context オブジェクトの req プロパティと res プロパティから。From req and res properties on the context object. この方法で、完全な パターンを使用する代わりに、従来のパターンを使用して context オブジェクトから HTTP データにアクセスできます。In this way, you can use the conventional pattern to access HTTP data from the context object, instead of having to use the full pattern. 次の例では、contextreq オブジェクトと res オブジェクトにアクセスする方法を示します。The following example shows how to access the req and res objects on the context:

    // You can access your HTTP request off the context ...
    if(context.req.body.emoji === ':pizza:') context.log('Yay!');
    // and also set your HTTP response
    context.res = { status: 202, body: 'You successfully ordered more coffee!' }; 
  • 名前付きの入力バインディングと出力バインディングから。From the named input and output bindings. この方法で、HTTP トリガーとバインディングは他のバインディングと同じように動作します。In this way, the HTTP trigger and bindings work the same as any other binding. 次の例では、名前付き response バインディングを使用して、応答オブジェクトを設定します。The following example sets the response object by using a named response binding:

        "type": "http",
        "direction": "out",
        "name": "response"
    context.bindings.response = { status: 201, body: "Insert succeeded." };
  • [応答のみ] context.res.send(body?: any) の呼び出し。[Response only] By calling context.res.send(body?: any). HTTP の応答は、入力 body を応答本文として使用して作成されます。An HTTP response is created with input body as the response body. context.done() は暗黙的に呼び出されます。context.done() is implicitly called.

  • [応答のみ] context.done() の呼び出し。[Response only] By calling context.done(). これは、context.done() メソッドに渡される応答を返す特殊な種類の HTTP バインディングです。A special type of HTTP binding returns the response that is passed to the context.done() method. 次の HTTP 出力バインディングで、$return 出力パラメーターを定義します。The following HTTP output binding defines a $return output parameter:

      "type": "http",
      "direction": "out",
      "name": "$return"
     // Define a valid response object.
    res = { status: 201, body: "Insert succeeded." };
    context.done(null, res);   

スケーリングと同時性Scaling and concurrency

既定では、Azure Functions は、アプリケーションの負荷を自動的に監視し、必要に応じて node.js 用の追加のホストインスタンスを作成します。By default, Azure Functions automatically monitors the load on your application and creates additional host instances for Node.js as needed. 関数は、さまざまなトリガー型の組み込み(ユーザー設定不可)しきい値を使用して、メッセージの経過時間や QueueTrigger のキューサイズなど、インスタンスを追加するタイミングを決定します。Functions uses built-in (not user configurable) thresholds for different trigger types to decide when to add instances, such as the age of messages and queue size for QueueTrigger. 詳細については、「従量課金プランと Premium プランのしくみ」をご覧ください。For more information, see How the Consumption and Premium plans work.

ほとんどの Node.js アプリケーションでは、このスケーリング動作で十分です。This scaling behavior is sufficient for many Node.js applications. CPUにバインドされたアプリケーションの場合、複数の言語ワーカープロセスを使用して、パフォーマンスをさらに向上させることができます。For CPU-bound applications, you can improve performance further by using multiple language worker processes.

既定では、すべての Functions ホスト インスタンスに 1 つの言語ワーカー プロセスがあります。By default, every Functions host instance has a single language worker process. FUNCTIONS_WORKER_PROCESS_COUNT アプリケーション設定を使用して、ホストごとのワーカー プロセスの数を増やすことができます (最大 10)。You can increase the number of worker processes per host (up to 10) by using the FUNCTIONS_WORKER_PROCESS_COUNT application setting. 次に、Azure Functions は、これらのワーカー間で同時関数呼び出しを均等に分散しようとします。Azure Functions then tries to evenly distribute simultaneous function invocations across these workers.

FUNCTIONS_WORKER_PROCESS_COUNT は、要求に応じてアプリケーションをスケールアウトするときに、関数作成する各ホストに適用されます。The FUNCTIONS_WORKER_PROCESS_COUNT applies to each host that Functions creates when scaling out your application to meet demand.

Node バージョンNode version

次の表は、Functions ランタイムの各メジャー バージョンに対して現在サポートされている Node.js バージョンをオペレーティング システムごとに示しています。The following table shows current supported Node.js versions for each major version of the Functions runtime, by operating system:

Functions バージョンFunctions version Node バージョン (Windows)Node version (Windows) Node バージョン (Linux)Node Version (Linux)
1.x1.x 6.11.2 (ランタイムによりロック)6.11.2 (locked by the runtime) 該当なしn/a
2.x2.x ~8~8
~10 (推奨)~10 (recommended)
~8 (推奨)~8 (recommended)
3.x3.x ~10~10
~12 (推奨)~12 (recommended)
~12 (推奨)~12 (recommended)

*Node ~12 は現在、Functions ランタイムのバージョン 2.x で許可されています。*Node ~12 is currently allowed on version 2.x of the Functions runtime. ただし、最適なパフォーマンスを得るには、Node ~12 の Functions ランタイム バージョン 3.x を使用することをお勧めします。However, for best performance, we recommend using Functions runtime version 3.x with Node ~12.

ランタイムが使用している現在のバージョンを確認するには、上記のアプリ設定を調べるか、または任意の関数から process.version を出力します。You can see the current version that the runtime is using by checking the above app setting or by printing process.version from any function. WEBSITE_NODE_DEFAULT_VERSION アプリ設定を、サポートされている LTS バージョン (~10 など) に設定して、Azure のバージョンをターゲットにします。Target the version in Azure by setting the WEBSITE_NODE_DEFAULT_VERSION app setting to a supported LTS version, such as ~10.

依存関係の管理Dependency management

JavaScript コードでコミュニティ ライブラリを使用するには、次の例で示すように、Azure 内の関数アプリにすべての依存関係がインストールされている必要があります。In order to use community libraries in your JavaScript code, as is shown in the below example, you need to ensure that all dependencies are installed on your Function App in Azure.

// Import the underscore.js library
var _ = require('underscore');
var version = process.version; // version === 'v6.5.0'

module.exports = function(context) {
    // Using our imported underscore.js library
    var matched_names = _
        .where(context.bindings.myInput.names, {first: 'Carla'});


関数アプリのルートに package.json ファイルを定義する必要があります。You should define a package.json file at the root of your Function App. このファイルを定義することによって、アプリのすべての関数を同じキャッシュされたパッケージで共有し、最高クラスのパフォーマンスを得ることができます。Defining the file lets all functions in the app share the same cached packages, which gives the best performance. バージョンの競合がある場合は、個別の関数のフォルダーに package.json ファイルを追加することで競合を解決できます。If a version conflict arises, you can resolve it by adding a package.json file in the folder of a specific function.

ソース管理から関数アプリをデプロイする場合、リポジトリ内に存在する package.json ファイルはすべて、デプロイ中にそのフォルダー内の npm install をトリガーします。When deploying Function Apps from source control, any package.json file present in your repo, will trigger an npm install in its folder during deployment. ただし、ポータルまたは CLI 経由でデプロイする場合は、パッケージを手動でインストールする必要があります。But when deploying via the Portal or CLI, you will have to manually install the packages.

関数アプリにパッケージをインストールするには 2 つの方法があります。There are two ways to install packages on your Function App:

依存関係と共に展開するDeploying with Dependencies

  1. npm install を実行して、すべての必要なパッケージをローカルにインストールします。Install all requisite packages locally by running npm install.

  2. コードを展開し、node_modules フォルダーが展開に含まれることを確認します。Deploy your code, and ensure that the node_modules folder is included in the deployment.

Kudu を使用するUsing Kudu

  1. https://<function_app_name> にアクセスします。Go to https://<function_app_name>

  2. [デバッグ コンソール] > [CMD] をクリックします。Click Debug Console > CMD.

  3. D:\home\site\wwwroot に移動し、ページの上半分にある wwwroot フォルダーに package.json ファイルをドラッグします。Go to D:\home\site\wwwroot, and then drag your package.json file to the wwwroot folder at the top half of the page.
    関数アプリにファイルをアップロードする方法は、他にもあります。You can upload files to your function app in other ways also. 詳細については、「関数アプリ ファイルを更新する方法」を参照してください。For more information, see How to update function app files.

  4. package.json ファイルがアップロードされたら、Kudu リモート実行コンソールnpm install コマンドを実行します。After the package.json file is uploaded, run the npm install command in the Kudu remote execution console.
    この操作によって、package.json ファイルに示されているパッケージがダウンロードされ、関数アプリが再起動されます。This action downloads the packages indicated in the package.json file and restarts the function app.

環境変数Environment variables

Functions では、サービス接続文字列などのアプリ設定は、実行中に環境変数として公開されます。In Functions, app settings, such as service connection strings, are exposed as environment variables during execution. 2 つ目と 3 つ目の context.log() の呼び出しで示されているように、process.envを使用してこれらの設定にアクセスできます。ここでは AzureWebJobsStorageWEBSITE_SITE_NAME の環境変数をログに記録します。You can access these settings using process.env, as shown here in the second and third calls to context.log() where we log the AzureWebJobsStorage and WEBSITE_SITE_NAME environment variables:

module.exports = async function (context, myTimer) {
    var timeStamp = new Date().toISOString();

    context.log('Node.js timer trigger function ran!', timeStamp);
    context.log("AzureWebJobsStorage: " + process.env["AzureWebJobsStorage"]);
    context.log("WEBSITE_SITE_NAME: " + process.env["WEBSITE_SITE_NAME"]);

関数アプリの設定は、いくつかの方法で追加、更新、削除できます。There are several ways that you can add, update, and delete function app settings:

ローカルで実行する場合、アプリ設定は local.settings.json プロジェクト ファイルから読み取られます。When running locally, app settings are read from the local.settings.json project file.

関数のエントリ ポイントを構成するConfigure function entry point

function.json のプロパティ scriptFileentryPoint を使用して、エクスポートされた関数の名前と場所を構成できます。The function.json properties scriptFile and entryPoint can be used to configure the location and name of your exported function. これらのプロパティは、JavaScript がトランスパイルされる場合に重要になることがあります。These properties can be important when your JavaScript is transpiled.

scriptFile の使用Using scriptFile

既定では、JavaScript 関数は index.js から実行されます。これは、対応する function.json と同じ親ディレクトリを共有するファイルです。By default, a JavaScript function is executed from index.js, a file that shares the same parent directory as its corresponding function.json.

scriptFile を使用すると、次の例のようなフォルダー構造を取得できます。scriptFile can be used to get a folder structure that looks like the following example:

 | - host.json
 | - myNodeFunction
 | | - function.json
 | - lib
 | | - sayHello.js
 | - node_modules
 | | - ... packages ...
 | - package.json

myNodeFunction に対する function.json には、エクスポートされた関数を実行するファイルを指し示す scriptFile プロパティが含まれている必要があります。The function.json for myNodeFunction should include a scriptFile property pointing to the file with the exported function to run.

  "scriptFile": "../lib/sayHello.js",
  "bindings": [

entryPoint の使用Using entryPoint

scriptFile (または index.js) では、関数が発見されて実行されるためには、module.exports を使用して関数をエクスポートする必要があります。In scriptFile (or index.js), a function must be exported using module.exports in order to be found and run. 既定では、トリガーされたときに実行される関数は、そのファイルからの唯一のエクスポートです (run という名前のエクスポート、または index という名前のエクスポート)。By default, the function that executes when triggered is the only export from that file, the export named run, or the export named index.

これは、次の例で示すように、entryPointfunction.json を使用して構成することができます。This can be configured using entryPoint in function.json, as in the following example:

  "entryPoint": "logFoo",
  "bindings": [

Functions v2.x では、ユーザー関数内の this パラメーターがサポートされており、関数のコードは次の例のようになります。In Functions v2.x, which supports the this parameter in user functions, the function code could then be as in the following example:

class MyObj {
    constructor() { = 1;

    logFoo(context) { 
        context.log("Foo is " +; 

const myObj = new MyObj();
module.exports = myObj;

この例では、オブジェクトはエクスポートされていますが、実行間で状態が保持される保証はないことに注意することが重要です。In this example, it is important to note that although an object is being exported, there are no guarantees for preserving state between executions.

ローカル デバッグLocal Debugging

Node.js プロセスは、--inspect パラメーターを指定して起動されると、指定されたポートでデバッグ クライアントをリッスンします。When started with the --inspect parameter, a Node.js process listens for a debugging client on the specified port. Azure Functions 2.x では、環境変数またはアプリ設定 languageWorkers:node:arguments = <args> を追加することで、コードを実行する Node.js プロセスに渡す引数を指定できます。In Azure Functions 2.x, you can specify arguments to pass into the Node.js process that runs your code by adding the environment variable or App Setting languageWorkers:node:arguments = <args>.

ローカルでデバッグするには、local.settings.json ファイルの Values の下に "languageWorkers:node:arguments": "--inspect=5858" を追加し、デバッガーをポート 5858 に接続します。To debug locally, add "languageWorkers:node:arguments": "--inspect=5858" under Values in your local.settings.json file and attach a debugger to port 5858.

VS Code を使用してデバッグするときは、プロジェクトの launch.json ファイルの port 値を使用して、--inspect パラメーターが自動的に追加されます。When debugging using VS Code, the --inspect parameter is automatically added using the port value in the project's launch.json file.

バージョン 1.x では、設定 languageWorkers:node:arguments は機能しません。In version 1.x, setting languageWorkers:node:arguments will not work. デバッグ ポートは、Azure Functions Core Tools の --nodeDebugPort パラメーターを使用して選択できます。The debug port can be selected with the --nodeDebugPort parameter on Azure Functions Core Tools.


Functions ランタイムのバージョン 2.x を対象とする場合、Visual Studio Code 用の Azure FunctionsAzure Functions Core Tools の両方によって、TypeScript 関数アプリ プロジェクトをサポートするテンプレートを使用して関数アプリを作成することができます。When you target version 2.x of the Functions runtime, both Azure Functions for Visual Studio Code and the Azure Functions Core Tools let you create function apps using a template that support TypeScript function app projects. テンプレートは、package.json および tsconfig.json プロジェクト ファイルを生成します。これらのプロジェクト ファイルは、これらのツールによって TypeScript コードから JavaScript 関数のトランスパイル、実行、発行を容易にします。The template generates package.json and tsconfig.json project files that make it easier to transpile, run, and publish JavaScript functions from TypeScript code with these tools.

生成された .funcignore ファイルは、プロジェクトが Azure に発行されるときに除外するファイルを指定するために使用します。A generated .funcignore file is used to indicate which files are excluded when a project is published to Azure.

TypeScript ファイル (.ts) は、dist 出力ディレクトリ内の JavaScript ファイル (.js) にトランスパイルされます。TypeScript files (.ts) are transpiled into JavaScript files (.js) in the dist output directory. TypeScript テンプレートは、function.jsonscriptFile パラメーターを使用して dist フォルダー内の対応する .js ファイルの場所を示します。TypeScript templates use the scriptFile parameter in function.json to indicate the location of the corresponding .js file in the dist folder. 出力場所は、tsconfig.json ファイルの outDir パラメーターを使用することで、テンプレートによって設定されます。The output location is set by the template by using outDir parameter in the tsconfig.json file. この設定またはフォルダーの名前を変更した場合、ランタイムは実行するコードを見つけることができません。If you change this setting or the name of the folder, the runtime is not able to find the code to run.

TypeScript プロジェクトからローカルで開発およびデプロイする方法は、開発ツールによって異なります。The way that you locally develop and deploy from a TypeScript project depends on your development tool.

Visual Studio CodeVisual Studio Code

Visual Studio Code 用の Azure Functions の拡張機能を使用すると、TypeScript を使用して関数を開発することができます。The Azure Functions for Visual Studio Code extension lets you develop your functions using TypeScript. Core Tools は Azure Functions の拡張機能の要件です。The Core Tools is a requirement of the Azure Functions extension.

Visual Studio Code で TypeScript 関数アプリを作成するには、関数アプリを作成するときに言語として TypeScript を選択します。To create a TypeScript function app in Visual Studio Code, choose TypeScript as your language when you create a function app.

F5 を押してアプリをローカルで実行すると、ホスト (func.exe) が初期化される前にトランスパイルが実行されます。When you press F5 to run the app locally, transpilation is done before the host (func.exe) is initialized.

[Deploy to function app... (関数アプリにデプロイする...)] ボタンを使用して関数アプリを Azure にデプロイすると、Azure Functions の拡張機能はまず、TypeScript ソース ファイルから実稼働可能な JavaScript ファイルのビルドを生成します。When you deploy your function app to Azure using the Deploy to function app... button, the Azure Functions extension first generates a production-ready build of JavaScript files from the TypeScript source files.

Azure Functions Core ToolsAzure Functions Core Tools

Core Tools の使用に関して、TypeScript プロジェクトと JavaScript プロジェクトでは異なる点がいくつかあります。There are several ways in which a TypeScript project differs from a JavaScript project when using the Core Tools.

Create projectCreate project

Core Tools を使用して TypeScript 関数アプリ プロジェクトを作成するには、関数アプリを作成するときに TypeScript 言語オプションを指定する必要があります。To create a TypeScript function app project using Core Tools, you must specify the TypeScript language option when you create your function app. これは、次の方法のいずれかで実行できます。You can do this in one of the following ways:

  • func init コマンドを実行し、言語スタックとして node を選択してから typescript を選択してください。Run the func init command, select node as your language stack, and then select typescript.

  • func init --worker-runtime typescript コマンドを実行します。Run the func init --worker-runtime typescript command.

ローカルで実行するRun local

Core Tools を使用して関数アプリのコードをローカルで実行するには、func host start ではなく次のコマンドを使用します。To run your function app code locally using Core Tools, use the following commands instead of func host start:

npm install
npm start

npm start コマンドは次のコマンドと同等です。The npm start command is equivalent to the following commands:

  • npm run build
  • func extensions install
  • tsc
  • func start

Azure に発行するPublish to Azure

func azure functionapp publish コマンドを使用して Azure にデプロイする前に、TypeScript ソース ファイルから JavaScript ファイルの運用対応のビルドを作成します。Before you use the func azure functionapp publish command to deploy to Azure, you create a production-ready build of JavaScript files from the TypeScript source files.

Core Tools を使用し、次のコマンドで TypeScript プロジェクトを準備して発行します。The following commands prepare and publish your TypeScript project using Core Tools:

npm run build:production 
func azure functionapp publish <APP_NAME>

このコマンドでは、<APP_NAME> を実際の関数アプリの名前に置き換えます。In this command, replace <APP_NAME> with the name of your function app.

JavaScript 関数に関する考慮事項Considerations for JavaScript functions

JavaScript 関数を使用するときは、以下のセクションに記載されている事柄に注意する必要があります。When you work with JavaScript functions, be aware of the considerations in the following sections.

シングル vCPU App Service プランを選択するChoose single-vCPU App Service plans

App Service プランを使用する関数アプリを作成するときは、複数の vCPU を持つプランではなく、シングル vCPU プランを選択することをお勧めします。When you create a function app that uses the App Service plan, we recommend that you select a single-vCPU plan rather than a plan with multiple vCPUs. 今日では、関数を使用して、シングル vCPU VM で JavaScript 関数をより効率的に実行できるようになりました。そのため、大規模な VM を使用しても、期待以上にパフォーマンスが向上することはありません。Today, Functions runs JavaScript functions more efficiently on single-vCPU VMs, and using larger VMs does not produce the expected performance improvements. 必要な場合は、シングル vCPU VM インスタンスを追加することで手動でスケールアウトするか、自動スケーリングを有効にすることができます。When necessary, you can manually scale out by adding more single-vCPU VM instances, or you can enable autoscale. 詳細については、「手動または自動によるインスタンス数のスケール変更」を参照してください。For more information, see Scale instance count manually or automatically.

コールド スタートCold Start

サーバーレス ホスティング モデルで Azure 関数を開発するときは、コールド スタートが現実のものになります。When developing Azure Functions in the serverless hosting model, cold starts are a reality. コールド スタートとは、非アクティブな期間の後で初めて関数アプリが起動するとき、起動に時間がかかることを意味します。Cold start refers to the fact that when your function app starts for the first time after a period of inactivity, it takes longer to start up. 特に、大きな依存関係ツリーを持つ JavaScript 関数の場合は、コールド スタートが重要になる可能性があります。For JavaScript functions with large dependency trees in particular, cold start can be significant. コールド スタート プロセスをスピードアップするには、可能な場合、パッケージ ファイルとして関数を実行します。To speed up the cold start process, run your functions as a package file when possible. 多くの展開方法ではパッケージからの実行モデルが既定で使用されますが、大規模なコールド スタートが発生していて、この方法で実行していない場合は、変更が大きな向上につながる可能性があります。Many deployment methods use the run from package model by default, but if you're experiencing large cold starts and are not running this way, this change can offer a significant improvement.

接続の制限Connection Limits

Azure Functions アプリケーションでサービス固有のクライアントを使用する場合は、関数呼び出しごとに新しいクライアントを作成しないでください。When you use a service-specific client in an Azure Functions application, don't create a new client with every function invocation. 代わりに、グローバル スコープに 1 つの静的クライアントを作成してください。Instead, create a single, static client in the global scope. 詳細については、Azure Functions での接続の管理に関するページを参照してください。For more information, see managing connections in Azure Functions.

asyncawait を使用するUse async and await

Azure Functions を JavaScript で記述する場合、asyncawait のキーワードを使用してコードを記述することをお勧めします。When writing Azure Functions in JavaScript, you should write code using the async and await keywords. コールバックや Promise の .then および .catch の代わりに asyncawait を使用してコードを記述することにより、2 つの一般的な問題を回避できます。Writing code using async and await instead of callbacks or .then and .catch with Promises helps avoid two common problems:

  • Node.js プロセスをクラッシュさせる、キャッチされない例外のスロー。他の関数の実行に影響する可能性があります。Throwing uncaught exceptions that crash the Node.js process, potentially affecting the execution of other functions.
  • 適切に待機しない非同期呼び出しによって発生する、context.log からのログの欠落などの予期しない動作。Unexpected behavior, such as missing logs from context.log, caused by asynchronous calls that are not properly awaited.

以下の例では、その 2 番目のパラメーターとしてエラーファースト コールバック関数を使用して非同期メソッド fs.readFile が呼び出されます。In the example below, the asynchronous method fs.readFile is invoked with an error-first callback function as its second parameter. このコードは上記の両方の問題の原因となります。This code causes both of the issues mentioned above. 正しいスコープでは明示的にキャッチされない例外によって、プロセス全体がクラッシュします (問題 1)。An exception that is not explicitly caught in the correct scope crashed the entire process (issue #1). コールバック関数のスコープ外で context.done() を呼び出すことは、ファイルが読み取られる前に関数呼び出しが終了する可能性があることを意味します (問題 2)。Calling context.done() outside of the scope of the callback function means that the function invocation may end before the file is read (issue #2). この例では、context.done() の呼び出しが早すぎるため、結果として Data from file: で始まるログ エントリが欠落します。In this example, calling context.done() too early results in missing log entries starting with Data from file:.

const fs = require('fs');

module.exports = function (context) {
    fs.readFile('./hello.txt', (err, data) => {
        if (err) {
            context.log.error('ERROR', err);
            // BUG #1: This will result in an uncaught exception that crashes the entire process
            throw err;
        context.log(`Data from file: ${data}`);
        // context.done() should be called here
    // BUG #2: Data is not guaranteed to be read before the Azure Function's invocation ends

async および await のキーワードを使用すると、これらの両方のエラーを回避しやすくなります。Using the async and await keywords helps avoid both of these errors. Node.js のユーティリティ関数 util.promisify を使用して、エラーファースト コールバック スタイルの関数を、待機可能な関数に変更してください。You should use the Node.js utility function util.promisify to turn error-first callback-style functions into awaitable functions.

次の例では、関数の実行中にスローされたハンドルされない例外により、例外を発生させた個々の呼び出しのみが失敗します。In the example below, any unhandled exceptions thrown during the function execution only fail the individual invocation that raised an exception. await キーワードは、readFileAsync に続くステップが、readFile の完了後にのみ実行されることを意味しています。The await keyword means that steps following readFileAsync only execute after readFile is complete. asyncawait を使用することで、context.done() コールバックを呼び出す必要もありません。With async and await, you also don't need to call the context.done() callback.

// Recommended pattern
const fs = require('fs');
const util = require('util');
const readFileAsync = util.promisify(fs.readFile);

module.exports = async function (context) {
    let data;
    try {
        data = await readFileAsync('./hello.txt');
    } catch (err) {
        context.log.error('ERROR', err);
        // This rethrown exception will be handled by the Functions Runtime and will only fail the individual invocation
        throw err;
    context.log(`Data from file: ${data}`);

次のステップNext steps

詳細については、次のリソースを参照してください。For more information, see the following resources: