この記事は Spumote のソースコードから生成した試験出力です。内容は確認中のため、正式な仕様は担当者に確認してください。
この機能でできること
自動処理を安心して本番運用するための機能をまとめています。- 失敗を受け止めて通知や後始末をする（エラーハンドラ）／自動でやり直す（リトライ）
- 「処理は成功したが中身が想定外」を失敗として扱う（結果チェック）
- 同じワークフローが重なって動かないよう制限する
- 過去の期間を指定してまとめて再実行する（バックフィル）、失敗したステップだけやり直す
- 本番の変更に承認（レビュー）を必須にする／緊急時は理由付きで承認を飛ばして公開する
- 実行コストの目安を確認する
- 定義を書き出して、別のワークフローへ移す
画面の場所
- ステップごとの設定: データ › 自動処理（ワークフロー）› 処理一覧 › （ワークフローを開く）› ステップ設定 ›「実行時の振る舞い」
- ワークフロー全体の設定: 同エディタ ›「設定」›「実行制御」
- バックフィル・コスト想定・定義の入出力: 同エディタ ›「…」（その他の操作）
- 承認待ちの一覧: データ › 自動処理（ワークフロー）› 承認（レビュー）
失敗への備え
失敗を受け止めて通知や後始末をするには「エラーハンドラ」ステップを使います（「02-3-2 ステップの種類」参照）。新規作成したワークフローには、ワークフロー全体を監視するエラーハンドラと「失敗通知」があらかじめ入っています。リトライ
「実行時の振る舞い」の「リトライを有効化」にチェックを入れると、失敗時に自動でやり直します。待ち時間は回を追うごとに倍率で伸びます。
リトライはジョブ型のステップ（インポート / プロセス / エクスポート）、ストレージ操作、エラーハンドラで設定できます。
結果チェック（アサーション）
「結果が条件を満たさない場合は失敗扱いにする」にチェックを入れると、ステップ自体は成功しても、結果の値が条件を満たさなければ失敗として扱います。失敗扱いになった場合もリトライが発火するため、「上流テーブルが今日更新されるまで待つ」といった使い方ができます。同時実行の制御
「設定」›「実行制御」›「重複実行防止」で「重複実行を制限する」にチェックを入れると、同時に 1 つだけ動くようになります。
上限に達しているときの扱いは起動経路で異なります。手動実行はエラーで拒否、スケジュール起動はその回を見送り（Catchup で後から拾えます）、アセット駆動とバックフィルは「待機中 ( 同時実行上限 )」として並び、空きが出たら順に実行されます。
バックフィル・再実行
バックフィル（期間を指定して再実行）
「…」›「バックフィル」で、対象期間（パーティション）を並べて指定すると、期間ごとに 1 回ずつ実行します。- 「対象期間を指定」を押します。
- 「パーティション変数名」（各回に値を渡す変数。例: BATCH_DATE）と「パーティション」（1 行に 1 つ、またはカンマ区切り）を入力します。
- 「同時実行数」と、必要なら「下流ワークフローへ連鎖する」を指定し、「再実行を開始」します。
- 一覧から開くと、パーティションごとの状態（待機中 / 実行中 / 成功 / 失敗）を確認でき、「失敗分を再実行」で失敗した期間だけやり直せます。
失敗ステップから再実行
実行履歴の詳細で「失敗ステップから再実行」を押すと、失敗（または部分成功）した実行を、失敗したステップからやり直します。成功済みのステップは再実行されません。再実行は、その実行が動いたときの公開版の定義と変数の値（日付など）で行われます。公開版を直しても、すでにある実行の再実行には反映されません。直した定義で動かしたいときは、新しく実行（今すぐ実行・バックフィル）してください。承認（レビュー）フロー
本番モードでは、下書きを公開するのに承認済みのレビューが必要です。- エディタで「レビュー依頼」を押し、「レビュアー」（1 人以上）を選び、複数選んだ場合は「必要な承認数」を決め、「変更内容の要約」を書いて「依頼する」を押します。
- レビュアーには「承認（レビュー）」の「受信」に依頼が届きます（件数がバッジ表示されます）。依頼した側は「送信」で確認できます。
- レビュアーは内容を確認して承認、または差し戻します。コメントも付けられます。必要な承認数に達するとレビューが承認済みになり、差し戻しが 1 件でもあるとレビュー全体が差し戻しになります。
- 承認済みになったら「公開する」で公開します。
- 本番モードでは自分を指名する・自分の依頼を承認することはできません（試作モードでは可能）。
- 同じワークフローで承認待ちのレビューは同時に 1 件までです。依頼者は依頼をキャンセルできます。
- 承認後に下書きを変更すると、公開には再レビューの承認が必要になります。
緊急公開（break-glass）
承認者不在の障害対応などで、本番ワークフローを承認なしで公開する例外操作です。承認待ちで公開が止まったとき、owner ロールの利用者にだけ「緊急公開」ボタンが表示されます。- 「理由」の入力が必須です（500 文字まで）。
- 実行者・理由が監査ログとリリース履歴に記録され、ワークフローの通知セット（未設定なら組織の既定）の送り先へ、件名「緊急公開 ( 承認レビューなし ): ワークフロー名」の通知が送信されます。
- ワークフローには「緊急公開」バッジが付き、理由はツールチップで確認できます。公開後は速やかに事後レビューを行ってください。
コスト見積もり
「…」›「コスト想定」で、ワークフローの実行コストの目安を日別・ステップ種別別などで確認できます（既定は過去 30 日）。BigQuery のオンデマンド料金と Editions Standard の両方で計算されます（実際の請求は組織の契約によります）。処理一覧でも「集計期間」に応じたコストが表示されます。エクスポート／インポート（定義の移送）
- 「…」›「定義をエクスポート」で、ワークフローと各ステップのジョブ定義（アセットトリガーが使うセンサーを含む）を JSON として書き出し、クリップボードにコピーします。
- 「…」›「定義をインポート」で JSON を貼り付けると、今開いているワークフローの定義を置き換えられます。取り込み前に変更点とジョブ設定の不足がプレビューされます。
活用例
- 上流更新待ち: 集計の先頭ステップで「本日未更新のテーブル数 = 0」を結果チェックし、リトライ 10 回・30 秒から倍々で待つ。
- 障害後の復旧: 3 日間止まっていた日次処理を、バックフィルで 3 日分指定して順に再実行。下流のエンゲージ同期も「下流ワークフローへ連鎖する」で追随。
- 本番変更の統制: 配信に直結するワークフローは本番モードにし、変更は必ずデータ担当者のレビューを通す。
注意点・制限
- バックフィルのパーティションは 1 回 500 件まで（重複は除去）、同時実行数は 1〜20。同時実行の制限設定があるときは小さい方が効きます。
- レビュアーは最大 10 人、要約は 500 文字、コメントは 5,000 文字まで。
- 結果チェックの正規表現は 200 文字まで。評価対象が見つからない・数値にならない場合は失敗扱いになります。
- 緊急公開は本番モードかつ owner ロールのみ。試作モードは通常の公開を使います。
- 試作モードでは組織既定の失敗通知が送られません。通知が必要なら通知セットを明示的に設定してください。
詳しい設定（データ担当者向け）
- 結果チェックの評価対象の目安: プロセス（SQL）は
resultData.<列名>/rowsProcessed、ストレージ操作はfilesProcessed/filesFound/bytesProcessed、インポートはrowsProcessed/bytesProcessed/syncStatus、エクスポートはrowsProcessed/filesUploaded/httpStatus。 - 数値の演算子（≥ など）は数値として比較し、文字列比較には切り替わりません。
- リトライの 0.1 秒刻みの初期遅延と最大遅延（1〜600 秒）は、API・MCP でのみ指定できます（画面では初期遅延を 1 秒単位で入力し、最大遅延は 300 秒に設定されます）。
- 失敗時の動作（中止 / スキップ / 続行）、ステップ実行の時間の上限（最大 86,400 秒）、上流アセット待ちの待ち時間の上限（既定 3,600 秒、最大 86,400 秒。超えたときに「失敗」か「スキップ」）は、画面からは設定できず、API・MCP でのみ指定できます。
- 別の組織（例: 検証用組織から本番組織）への定義の取り込み（
${変数名}を取り込み先の値に置き換える「環境マッピング」を含む。ジョブ 100 件・センサー 50 件まで）は、API でのみ提供されています。