この記事では、Azure Functionsでタイマー トリガーを操作する方法について説明します。 タイマー トリガーを使用すると、スケジュールに基づいて関数を実行できます。
これは、Azure Functions開発者向けのリファレンス情報です。 Azure Functionsを初めて使用する場合は、次のリソースから始めます。
C# 開発者向けリファレンス:
タイマーによってトリガーされる関数を手動で実行する方法については、「HTTP によってトリガーされない関数を手動で実行する」を参照してください。
このバインドのサポートは、すべての開発環境で自動的に提供されます。 手動でパッケージをインストールしたり、拡張機能を登録したりする必要はありません。
タイマー拡張機能パッケージのソース コードは、azure-webjobs-sdk-extensions GitHub リポジトリにあります。
Important
この記事では、タブを使用して、Node.js プログラミング モデルの複数のバージョンに対応しています。 v4 モデルは一般提供されており、JavaScript と TypeScript の開発者にとって、より柔軟で直感的なエクスペリエンスが得られるように設計されています。 v4 モデルの動作の詳細については、Azure Functions Node.js 開発者ガイドを参照してください。 v3 と v4 の違いの詳細については、移行ガイドを参照してください。
Azure Functionsでは、Python用の 2 つのプログラミング モデルがサポートされています。 バインドを定義する方法は、選択したプログラミング モデルによって異なります。
Python v2 プログラミング モデルを使用すると、Python関数コードでデコレーターを使用してバインドを直接定義できます。 詳細については、Python 開発者ガイドを参照してください。
この記事は、両方のプログラミング モデルをサポートしています。
Example
この例では、分の値が 5 の倍数になるたびに実行される C# 関数を示します。 たとえば、関数が 18:55:00 に開始された場合、次の実行は 19:00:00 になります。
TimerInfo オブジェクトが関数に渡されます。
A C# 関数は、次の C# モードのいずれかを使用して作成できます。
-
分離されたワーカー モデル: ランタイムから分離されたワーカー プロセスで実行されるコンパイル済みの C# 関数。 分離ワーカー プロセスは、.NETおよび .NET Framework の LTS および LTS 以外のバージョンで実行されている C# 関数をサポートするために必要です。 分離ワーカー プロセス関数の拡張機能では、
Microsoft.Azure.Functions.Worker.Extensions.*名前空間が使用されます。 -
インプロセス モデル: Functions ランタイムと同じプロセスで実行されるコンパイル済みの C# 関数。 このモデルの一部では、主に C# ポータルの編集のためにサポートされている C# スクリプトを使用して Functions を実行できます。 インプロセス関数の拡張機能では、
Microsoft.Azure.WebJobs.Extensions.*名前空間を使用します。
Important
インプロセス モデルのサポートは 2026 年 11 月 10 日に終了します。 完全なサポートのために、分離ワーカー モデルにアプリを移行することを強くお勧めします。
[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));
logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus?.Next}");
}
次の例の関数は、5 分ごとにトリガーして実行します。 関数の @TimerTrigger 注釈は、 CRON 式と同じ文字列形式を使用してスケジュールを定義します。
@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を使用するかによって異なります。
import datetime
import logging
import azure.functions as func
app = func.FunctionApp()
@app.function_name(name="mytimer")
@app.timer_trigger(schedule="0 */5 * * * *",
arg_name="mytimer",
run_on_startup=False)
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)
次の例は、タイマー トリガー TypeScript 関数を示しています。
import { app, InvocationContext, Timer } from '@azure/functions';
export async function timerTrigger1(myTimer: Timer, context: InvocationContext): Promise<void> {
context.log('Timer function processed request.');
}
app.timer('timerTrigger1', {
schedule: '0 */5 * * * *',
handler: timerTrigger1,
});
次の例は、タイマー トリガー JavaScript 関数を示しています。
function.json ファイルのバインディング データを次に示します。
{
"schedule": "0 */5 * * * *",
"name": "myTimer",
"type": "timerTrigger",
"direction": "in"
}
次に示すのは、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"
Attributes
In-process C# ライブラリは、Microsoft の TimerTriggerAttribute を使用します。Azure。WebJobs.Extensions 一方、isolated worker process C# ライブラリは、Microsoft の TimerTriggerAttribute を使用します。Azure。Functions.Worker.Extensions.Timer 関数を定義します。 C# スクリプトでは、代わりに function.json 構成ファイルを使います。
| Attribute プロパティ | Description |
|---|---|
| Schedule |
CRON 式または TimeSpan 値。
TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリの設定に含めて、% 記号で囲まれたアプリ設定名にこのプロパティを設定できます (例: %ScheduleAppSetting%)。 |
| RunOnStartup |
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変更されたために関数アプリが再起動されたとき、および関数アプリがスケールアウトされたとき。注意してください。RunOnStartupは、特に運用環境でtrueに設定されることはほとんどありません。 |
| UseMonitor |
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。 |
Decorators
Python v2 プログラミング モデルにのみ適用されます。
デコレーターを使用して定義Python v2 関数の場合、scheduleの次のプロパティ。
| Property | Description |
|---|---|
arg_name |
関数コード内のタイマー オブジェクトを表す変数の名前。 |
schedule |
NCRONTAB 式または TimeSpan 値。
TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリ設定に含めて、たとえば "%ScheduleAppSetting%" のように、% 記号で囲まれたアプリ設定名にこのプロパティを設定できます。 |
run_on_startup |
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を に設定する必要があるとしても、(運用環境では特に) まれなことです。true |
use_monitor |
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。 |
function.json を使用して定義Python関数については、「Configuration」セクションを参照してください。
Configuration
Python v1 プログラミング モデルにのみ適用されます。
次の表では、options メソッドに渡される app.timer() オブジェクトに対して設定できるプロパティについて説明します。
| Property | Description |
|---|---|
| schedule |
NCRONTAB 式または TimeSpan 値。
TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリ設定に含めて、たとえば "%ScheduleAppSetting%" のように、% 記号で囲まれたアプリ設定名にこのプロパティを設定できます。 |
| runOnStartup |
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を に設定する必要があるとしても、(運用環境では特に) まれなことです。true |
| useMonitor |
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。 |
次の表は、function.json ファイルで設定したバインド構成のプロパティを説明しています。
| function.json のプロパティ | Description |
|---|---|
| type | "timerTrigger" に設定する必要があります。 このプロパティは、Azure ポータルでトリガーを作成するときに自動的に設定されます。 |
| 方向 | "in" に設定する必要があります。 このプロパティは、Azure ポータルでトリガーを作成するときに自動的に設定されます。 |
| name | 関数コード内のタイマー オブジェクトを表す変数の名前。 |
| schedule |
NCRONTAB 式または TimeSpan 値。
TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。 スケジュール式をアプリ設定に含めて、たとえば "%ScheduleAppSetting%" のように、% 記号で囲まれたアプリ設定名にこのプロパティを設定できます。 |
| runOnStartup |
true の場合、関数はランタイムの開始時に呼び出されます。 たとえば、ランタイムが開始するのは、関数アプリが非アクティブになってアイドル状態に移行した後で起動したとき、 関数が変化したために関数アプリが再起動するとき、関数アプリがスケールアウトするときなどです。"使うときは注意してください"。runOnStartup を に設定する必要があるとしても、(運用環境では特に) まれなことです。true |
| useMonitor |
true または false に設定し、スケジュールを監視する必要があるかどうかを示します。 スケジュールの監視はスケジュールの発生を維持し、関数アプリのインスタンスが再起動するときでもスケジュールが正しく維持されることを保証するのに役立ちます。 このプロパティを明示的に設定しない場合、繰り返し間隔が 1 分以上のスケジュールの既定値は true です。 1 分間に 2 回以上トリガーするスケジュールの既定値は false です。 |
ローカルで開発する場合は、 コレクション内の Valuesにアプリケーション設定を追加します。
Caution
runOnStartup を運用環境でtrueに設定しないでください。 この設定を使用すると、まったく予期できないときにコードが実行されます。 特定の運用環境の設定では、これらの追加の実行によって、従量課金プランでホストされるアプリのコストが大幅に高くなる可能性があります。 たとえば、 runOnStartup を有効にすると、関数アプリがスケーリングされるたびにトリガーが呼び出されます。 運用環境で runOnStartup を有効にする前に、関数の運用動作を十分に理解しておいてください。
完全な例については、セクションの例を参照してください。
Usage
タイマー トリガー関数が呼び出されると、タイマー オブジェクトが関数に渡されます。 次の 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
}
{
"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}
各フィールドは、次の種類の値のいずれかを持つことができます。
| タイプ | Example | トリガーされたとき |
|---|---|---|
| 特定の値 | 0 5 * * * * |
1 時間ごとに 1 回、1 日の毎時 5 分 |
すべての値 (*) |
0 * 5 * * * |
5 時の間、1 時間に 1 分ごと |
範囲 (- 演算子) |
5-7 * * * * * |
1 分間に 3 回 - 各日、各時間、毎分 5 秒から 7 秒 |
値のセット (, 演算子) |
5,8,10 * * * * * |
1 分間に 3 回 - 各日、各時間、毎分 5 秒、8 秒、10 秒 |
間隔値 (/ 演算子) |
0 */5 * * * * |
1 時間に 12 回 - 各日、毎時 5 分 0 秒 |
月や曜日を指定するには、数値、名前、または名前の省略形を使用できます。
- 曜日については、数値は 0 から 6 で指定します (0 は日曜日です)。
- 名前は英語で指定します。 たとえば、
Monday、January。 - 名前の大文字と小文字は区別されません。
- 名前は省略形でも指定できます。 省略形には 3 文字を使用することをお勧めします。 たとえば、
Mon、Jan。
NCRONTAB の例
Azure Functionsのタイマー トリガーに使用できる、NCRONTAB 式の例をいくつか次に示します。
| Example | トリガーされたとき |
|---|---|
0 */5 * * * * |
5 分ごとに 1 回 |
0 0 * * * * |
毎正時に 1 回 |
0 0 */2 * * * |
2 時間に 1 回 |
0 0 9-17 * * * |
午前 9 時から午後 5 時まで、1 時間に 1 回 |
0 30 9 * * * |
毎日午前 9 時 30 分 |
0 30 9 * * 1-5 |
平日の毎日午前 9 時 30 分 |
0 30 9 * Jan Mon |
1 月の毎週月曜日の午前 9時 30分 |
Note
NCRONTAB 式は、 5 つのフィールド と 6 つのフィールド 形式の両方をサポートします。 6 番目のフィールド位置は、式の先頭に配置される秒の値です。 CRON 式が無効な場合、Application Insights が接続されている場合は、Azure ポータルの関数テストに 404 エラーが表示されます。詳細がログに記録されます。
NCRONTAB タイム ゾーン
NCRONTAB 式の数値は、期間ではなく、時刻と日付を参照します。 たとえば、hour フィールドの 5 は、5 時間ごとではなく、午前 5 時 00 分を示します。
CRON 式で使用する既定のタイム ゾーンは、協定世界時 (UTC) です。 別のタイム ゾーンに基づく CRON 式を使うには、Function App 用に WEBSITE_TIME_ZONE という名前のアプリ設定を作成します。
この設定の値は、関数アプリを実行するオペレーティング システムとプランによって異なります。
| オペレーティング システム | Plan | Value |
|---|---|---|
| Windows | All | Windows コマンドによって指定された各ペアの 2 行目で指定された、目的のタイム ゾーンの名前に値を設定tzutil.exe /L |
| リナックス | Premium Dedicated |
tz データベースに示すように、目的のタイム ゾーンの名前に値を設定します |
Note
WEBSITE_TIME_ZONE および TZ は、 Flex 従量課金 プランまたは 従量課金 プランで Linux 上で実行する場合、現在サポートされていません。 この場合、設定 WEBSITE_TIME_ZONE または TZ によって SSL 関連の問題が発生し、メトリックがアプリの動作を停止する可能性があります。
たとえば、米国東部標準時 (Eastern Standard Time (Windows) または America/New_York (Linux) で表されます)、標準時は UTC-05:00、夏時間は UTC-04:00 が使用されています。 タイマー トリガーを毎日午前 10 時 00 分に起動するには、WEBSITE_TIME_ZONE という名前の関数アプリのアプリ設定を作成し、値を Eastern Standard Time (Windows) または America/New_York (Linux) に設定してから、次の NCRONTAB 式を使用します。
"0 0 10 * * *"
WEBSITE_TIME_ZONEを使用すると、夏時間や標準時の変更など、特定のタイムゾーンの時間変化に合わせて時刻が調整されます。
TimeSpan
TimeSpan は、App Service プランで実行している関数アプリに対してのみ使うことができます。
NCRONTAB 式とは異なり、 TimeSpan 値は各関数呼び出し間の時間間隔を指定します。 指定された間隔より長く実行した後で関数が完了すると、タイマーがすぐに関数を再び呼び出します。
TimeSpan は文字列として表され、hh:mm:ss が 24 未満のときの形式は hh です。 最初の 2 つの数字が 24 以上のときの形式は dd:hh:mm です。 次に例をいくつか示します。
| Example | トリガーされたとき |
|---|---|
| "01:00:00" | 1 時間ごと |
| "00:01:00" | 毎分 |
| "25:00:00:00" | 25 日ごと |
| "1.00:00:00" | 毎日 |
Scale-out
関数アプリが複数のインスタンスにスケールアウトする場合は、タイマーによってトリガーされる関数の 1 つのインスタンスだけがすべてのインスタンスで実行されます。 未処理の呼び出しがまだ実行されている場合は、再度トリガーされません。
ストレージを共有する関数アプリ
App Service にデプロイされていない関数アプリの間でストレージ アカウントを共有している場合は、ホスト ID を各アプリに明示的に割り当てることが必要な場合があります。
| Functions バージョン | Setting |
|---|---|
| 2.x (以上) |
AzureFunctionsWebHost__hostid 環境変数 |
| 1.x |
id
inhost.json |
識別値を省略するか、各関数アプリの識別構成に異なる値を手動で設定することができます。
1 つの関数アプリが複数のインスタンスにスケールアウトされる場合、タイマー インスタンスが 1 しか存在しないようにするために、タイマー トリガーではストレージ ロックが使用されます。 2 つの関数アプリで同じ識別構成が共有されていて、それぞれでタイマー トリガーが使用されている場合は、1 つのタイマーのみが実行されます。
再試行の動作
キュー トリガーとは異なり、タイマー トリガーは関数が失敗した後で再試行しません。 失敗した関数は、次のスケジュール時刻まで再び呼び出されることはありません。
タイマー トリガーを手動で呼び出す
Azure Functionsのタイマー トリガーは、関数を手動でトリガーするために呼び出すことができる HTTP Webhook を提供します。 これは、次のようなシナリオで非常に役立ちます。
- 統合テスト
- スモーク テストまたはウォームアップ アクティビティの一部としてのスロット スワップ
- データベース内のキャッシュまたはルックアップ テーブルに直ちにデータを入力する関数の初期デプロイ
タイマーによってトリガーされる関数を手動で呼び出す方法の詳細については、HTTP によってトリガーされない関数を手動で実行する方法に関するページを参照してください。
Troubleshooting
タイマー トリガーが期待どおりに動作しない場合の対処方法については、「タイマーによってトリガーされる関数が起動しないに関する問題の報告」を参照してください。
Connections
タイマー トリガーは、Azure Functions Core Tools を介してローカルに実行される場合を除き、BLOB ストレージに暗黙的な依存関係があります。 システムは BLOB ストレージを使用して、アプリがスケールアウト 複数のインスタンス間で調整します。ホスト ストレージ (AzureWebJobsStorage) 接続を使用して BLOB ストレージにアクセスします。
ID ベースの接続を使用するようにホスト ストレージを構成する場合、ID にはストレージ BLOB データ所有者ロールが必要です。これは、ホスト ストレージの既定の要件です。