このブラウザーはサポートされなくなりました。

Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。

この記事では、Azure Functions でタイマー トリガーを使用する方法について説明します。 タイマー トリガーを使用すると、スケジュールに基づいて関数を実行できます。

これは、Azure Functions の開発者向けリファレンス情報です。 Azure Functions を初めて使用する場合は、先に次のリソースを参照してください。

タイマーによってトリガーされる関数を手動で実行する方法については、「 HTTP によってトリガーされない関数を手動で実行する 」を参照してください。

このバインドのサポートは、すべての開発環境で自動的に提供されます。 手動でパッケージをインストールしたり、拡張機能を登録したりする必要はありません。

タイマー拡張機能パッケージのソース コードは、 azure-webjobs-sdk-extensions GitHub リポジトリにあります。

Azure Functions では、Python の 2 つのプログラミング モデルがサポートされています。 バインドを定義する方法は、選択したプログラミング モデルによって異なります。

この例では、分の値が 5 の倍数になるたびに実行される C# 関数を示します。 たとえば、関数が 18:55:00 に開始された場合、次の実行は 19:00:00 になります。 TimerInfo オブジェクトが関数に渡されます。

A C# 関数は、次の C# モードのいずれかを使用して作成できます。

[FunctionName("TimerTriggerCSharp")]
public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log)
    if (myTimer.IsPastDue)
        log.LogInformation("Timer is running late!");
    log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
//<docsnippet_fixed_delay_retry_example>
[Function(nameof(TimerFunction))]
[FixedDelayRetry(5, "00:00:10")]
public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,
    FunctionContext context)
    var logger = context.GetLogger(nameof(TimerFunction));
次の例の関数は、5 分ごとにトリガーして実行します。 関数の @TimerTrigger 注釈では、@TimerTriggerと同じ文字列形式を使用してスケジュールが定義されています。
@FunctionName("keepAlive")
public void keepAlive(
  @TimerTrigger(name = "keepAliveTrigger", schedule = "0 */5 * * * *") String timerInfo,
      ExecutionContext context
     // timeInfo is a JSON string, you can deserialize it to an object using your favorite JSON library
     context.getLogger().info("Timer is triggered: " + timerInfo);
次の例では、タイマー トリガー バインドと、バインドを使用する関数コードを示します。関数にはタイマーを表すインスタンスが渡されます。 この関数では、この関数呼び出しがスケジュールのミスの発生によるものかどうかを示すログが書き込まれます。 この例は、v1 と v2 のどちらの Python プログラミング モデルを使用するかによって異なります。
@app.function_name(name="mytimer")
@app.schedule(schedule="0 */5 * * * *", 
              arg_name="mytimer",
              run_on_startup=True) 
def test_function(mytimer: func.TimerRequest) -> None:
    utc_timestamp = datetime.datetime.utcnow().replace(
        tzinfo=datetime.timezone.utc).isoformat()
    if mytimer.past_due:
        logging.info('The timer is past due!')
    logging.info('Python timer trigger function ran at %s', utc_timestamp)
JavaScript コードを次に示します。
module.exports = async function (context, myTimer) {
    var timeStamp = new Date().toISOString();
    if (myTimer.isPastDue)
        context.log('Node is running late!');
    context.log('Node timer trigger function ran!', timeStamp);   
次に示すのは、run.ps1 ファイルのタイマー関数コードです。
# Input bindings are passed in via param block.
param($myTimer)
# Get the current universal time in the default string format.
$currentUTCtime = (Get-Date).ToUniversalTime()
# The 'IsPastDue' property is 'true' when the current function invocation is later than scheduled.
if ($myTimer.IsPastDue) {
    Write-Host "PowerShell timer is running late!"
# Write an information log with the current time.
Write-Host "PowerShell timer trigger function ran! TIME: $currentUTCtime"
次に示す Python コードで関数に渡されるオブジェクトの型は、azure.functions.TimerRequest オブジェクトです。
import datetime
import logging
import azure.functions as func
def main(mytimer: func.TimerRequest) -> None:
    utc_timestamp = datetime.datetime.now(datetime.timezone.utc).isoformat()
    if mytimer.past_due:
        logging.info('The timer is past due!')
    logging.info('Python timer trigger function ran at %s', utc_timestamp)
インプロセス C# ライブラリでは Microsoft.Azure.WebJobs.Extensions の TimerTriggerAttribute を使用しますが、分離ワーカー プロセス C# ライブラリでは、Microsoft.Azure.Functions.Worker.Extensions.Timer の TimerTriggerAttribute を使用して関数を定義します。 C# スクリプトでは、C# スクリプト ガイドで説明されているように、代わりに function.json 構成ファイルを使用します。
インプロセス
分離プロセス
[スケジュール]
CRON 式または TimeSpan 値。 TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリの設定に含めて、% 記号で囲まれたアプリ設定名にこのプロパティを設定できます (例: %ScheduleAppSetting%)。
runOnStartup
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を true に設定する必要があるとしても、(運用環境では特に) まれなことです。
UseMonitor
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。
[スケジュール]
CRON 式または TimeSpan 値。 TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリの設定に含めて、% 記号で囲まれたアプリ設定名にこのプロパティを設定できます (例: %ScheduleAppSetting%)。
runOnStartup
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を true に設定する必要があるとしても、(運用環境では特に) まれなことです。
UseMonitor
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。
schedule
CRON 式または TimeSpan 値。 TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリ設定に含めて、たとえば "%ScheduleAppSetting%" のように、 % 記号で囲まれたアプリ設定名にこのプロパティを設定できます。
run_on_startup
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を true に設定する必要があるとしても、(運用環境では特に) まれなことです。
use_monitor
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。
function.json を使用して定義された Python 関数については、[構成] セクションを参照してください。
関数の @TimerTrigger 注釈では、CRON 式と同じ文字列形式を使って schedule が定義されています。 この注釈では、次の設定がサポートされます。
dataType
schedule
"Python v1 プログラミング モデルにのみ適用されます。"

次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。
function.json のプロパティ
schedule
CRON 式または TimeSpan 値。 TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリ設定に含めて、たとえば "%ScheduleAppSetting%" のように、 % 記号で囲まれたアプリ設定名にこのプロパティを設定できます。
runOnStartup
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を true に設定する必要があるとしても、(運用環境では特に) まれなことです。
useMonitor
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。
運用環境では、runOnStartup を true に設定しないでください。 この設定を使用すると、まったく予期できないときにコードが実行されます。 特定の運用環境の設定では、これらの追加の実行によって、従量課金プランでホストされるアプリのコストが大幅に高くなる可能性があります。 たとえば、runOnStartup を有効にすると、ご利用の関数アプリがスケーリングされるたびに、トリガーが呼び出されます。 runOnStartup を運用環境で有効にする前に、ご利用の関数の運用環境での動作を十分に理解しておく必要があります。
完全な例については、セクションの例を参照してください。
タイマー トリガー関数が呼び出されると、タイマー オブジェクトが関数に渡されます。 次の JSON は、タイマー オブジェクトの 1 つの表現例です。
    "Schedule":{
        "AdjustForDST": true
    "ScheduleStatus": {
        "Last":"2016-10-04T10:15:00+00:00",
        "LastUpdated":"2016-10-04T10:16:00+00:00",
        "Next":"2016-10-04T10:20:00+00:00"
    "IsPastDue":false
現在の関数の呼び出しがスケジュールより遅い場合、isPastDue プロパティは true になります。 たとえば、関数アプリが再起動すると、呼び出しが行われない可能性があります。
NCRONTAB 式
Azure Functions では、NCRONTAB 式を解釈するのに NCronTab ライブラリが使用されます。 NCRONTAB 式は CRON 式に似ていますが、秒単位の時間精度に使用するために、追加の 6 番目のフィールドが最初に含まれている点が異なります。
{second} {minute} {hour} {day} {month} {day-of-week}
各フィールドは、次の種類の値のいずれかを持つことができます。
トリガーのタイミング
曜日については、数値は 0 から 6 で指定します (0 は日曜日です)。
名前は英語で指定します。 例: Monday, January。
名前の大文字と小文字は区別されません。
名前は省略形でも指定できます。 省略形は 3 文字にすることをお勧めします。  例: Mon, Jan。
NCRONTAB の例
Azure Functions のタイマー トリガーに使用できる NCRONTAB 式の例をいくつか示します。
トリガーのタイミング
NCRONTAB 式は、5 フィールドと 6 フィールドの両方の形式をサポートしています。 6 番目のフィールド位置は、式の先頭に配置される秒の値です。
NCRONTAB タイム ゾーン
CRON 式に出現する値は、時間間隔ではなく時刻と日付を示します。 たとえば、hour フィールドの 5 は、5 時間ごとではなく、午前 5 時 00 分を示します。
CRON 式で使用する既定のタイム ゾーンは、協定世界時 (UTC) です。 別のタイム ゾーンに基づく CRON 式を使うには、Function App 用に WEBSITE_TIME_ZONE という名前のアプリ設定を作成します。
この設定の値は、関数アプリを実行するオペレーティング システムとプランによって異なります。
オペレーティング システム
Windows
Windows コマンド tzutil.exe /L によって指定された各ペアの 2 行目に指定されているように、この値を目的のタイム ゾーンの名前に設定します。
Linux
Premium
専用
この値を、tz データベースに関するページに示されている目的のタイム ゾーンの名前に設定します。
Linux 従量課金プランでは、現在 WEBSITE_TIME_ZONE および TZ はサポートされていません。
たとえば、米国の東部標準時 (Eastern Standard Time (Windows) または America/New_York (Linux)) では現在、標準時では UTC-05:00、夏時間では UTC-04:00 を使用します。 タイマー トリガーが毎日東部標準時の午前 10 時に発生するように設定するには、関数アプリのアプリ設定を WEBSITE_TIME_ZONE という名前で作成し、その値を Eastern Standard Time (Windows) または America/New_York (Linux) に設定して、次の NCRONTAB 式を使用します。
"0 0 10 * * *"
WEBSITE_TIME_ZONE を使用すると、夏時間などの特定のタイムゾーンでの時間変更や標準時での変更に対応するように、時刻が調整されます。
TimeSpan
TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。
CRON 式とは異なり、TimeSpan の値は各関数呼び出しの間の時間間隔を指定します。 指定された間隔より長く実行した後で関数が完了すると、タイマーがすぐに関数を再び呼び出します。
TimeSpan は文字列として表され、hh が 24 未満のときの形式は hh:mm:ss です。 最初の 2 つの数字が 24 以上のときの形式は dd:hh:mm です。 次に例をいくつか示します。
トリガーのタイミング
スケールアウト
関数アプリが複数のインスタンスにスケールアウトする場合は、タイマーによってトリガーされる関数の 1 つのインスタンスだけがすべてのインスタンスで実行されます。 未処理の呼び出しがまだ実行中の場合は、再度トリガーされません。
ストレージを共有する関数アプリ
App Service にデプロイされていない関数アプリの間でストレージ アカウントを共有している場合は、ホスト ID を各アプリに明示的に割り当てることが必要な場合があります。
Functions バージョン
識別値を省略するか、各関数アプリの識別構成に異なる値を手動で設定することができます。
1 つの関数アプリが複数のインスタンスにスケールアウトされる場合、タイマー インスタンスが 1 しか存在しないようにするために、タイマー トリガーではストレージ ロックが使用されます。 2 つの関数アプリで同じ識別構成が共有されていて、それぞれでタイマー トリガーが使用されている場合は、1 つのタイマーのみが実行されます。
再試行の動作
キュー トリガーとは異なり、タイマー トリガーは関数が失敗した後で再試行しません。 失敗した関数は、次のスケジュール時刻まで再び呼び出されることはありません。
タイマー トリガーを手動で呼び出す
Azure Functions のタイマー トリガーには、手動で関数をトリガーするために呼び出すことができる HTTP Webhook が用意されています。 これは、次のようなシナリオで非常に役立ちます。
統合テスト
スモーク テストまたはウォームアップ アクティビティの一部としてのスロット スワップ
データベース内のキャッシュまたはルックアップ テーブルに直ちにデータを入力する関数の初期デプロイ
タイマーによってトリガーされる関数を手動で呼び出す方法の詳細については、HTTP によってトリガーされない関数を手動で実行する方法に関するページを参照してください。
トラブルシューティング
タイマー トリガーが期待どおりに機能しない場合の対処方法については、タイマー トリガーが設定された関数が発生しない問題の調査と報告に関するページを参照してください。
次のステップ
タイマー トリガーを使用するクイックスタートに進む
Azure Functions のトリガーとバインドの詳細情報