[Brazil調査] インシデントの自動クローズ：暦日から営業日に変わった数え方
Brazil にアップグレードしたあと、「解決済みのインシデントが、前より遅く閉じるのはなぜか」と問われたら、どう答えますか。公式の差分ノートには、自動クローズの日数が暦日から営業日に変わったと書かれています。では、その営業日とは何を指すのでしょうか。
実機を調べると、営業日を決めているのは「24 hours on weekdays」という月曜から金曜の24時間スケジュールでした。祝日は入っていません。平日に解決した場合、7営業日の既定値は解決から9〜11暦日にあたります。
検証環境：Brazil PDI（Australia からメジャーアップグレード）/ OOTB / 2026-10-09 確認
押さえておくこと
変わったのは数え方です。プロパティ glide.ui.autoclose.time は、Resolved から Closed までの「営業日数」を表します
営業日の定義は、ビジネスルールの中で指定された cmn_schedule（スケジュール）の1件です。公式ページには、そのスケジュール名が載っていません
テスト用に Resolved のインシデントを7件作って1回実行したところ、暦日7日なら閉じるはずの2件が、Resolved のまま残りました
公式の説明
Australia から Brazil への差分ノート（Incident Management）の Changes に、次の記述があります。
The resolved incidents are now automatically closed after a specific number of business days instead of calendar days. You can use configure the number of business days using Number of days (integer) after which Resolved incidents are automatically closed. Zero (0) disables this feature [glide.ui.autoclose.time] property.
（訳：Resolved のインシデントは、暦日ではなく指定した営業日数のあとに自動で Closed になる。営業日数は glide.ui.autoclose.time プロパティで設定する）
引用元：Combined Incident Management release notes for upgrades from Australia to Brazil
プロパティの説明ページと設定手順のページにも、同じ趣旨の記述があります。
プロパティ表：「Set the duration in number of business days for the incident auto-close function.」（自動クローズの期間を営業日数で指定する）。引用元：Incident Management properties
設定手順：「By default, the value is set to 7 business days.」（既定値は7営業日）。引用元：Configure incidents to close automatically
手順のページには、Autoclose Incidents というスケジュールジョブが Incident Autoclose ビジネスルールを実行して閉じる、という説明もあります。一方で、営業日をどのスケジュールで数えるのかは、この3ページのどこにも書かれていません。新しく追加されたプロパティも確認できませんでした。既存のプロパティの意味が変わっただけです。
営業日の定義
実機では、仕組みは次の流れで動いています。
起点はスケジュールジョブ、橙は判断や分岐、緑は処理の実行、灰色は何もしない経路です。
営業日を定義しているのは、cmn_schedule の「24 hours on weekdays」でした。画面の①が名前、②が説明です。説明には「Used for incident autoclose business days calculation」と書かれています。
時間帯：月曜から金曜の終日（エントリは「Weekdays 24 hours」の1件）
祝日：入っていません。子スケジュールも0件でした
Time zone：Floating（特定のタイムゾーンを持たない設定）
つまりこの機能の「営業日」は、土日だけを除いた24時間です。営業時間や会社の休日カレンダーは反映されません。
1営業日の計算
ビジネスルール incident autoclose の中身を見ると、このスケジュールが使われる箇所は2か所です。
var businessDayMs = pn * 24 * 60 * 60 * 1000;pn はプロパティの値です。7なら、7×24時間が基準になります。スケジュールのIDは、コメントに「24 hour schedule」と書かれた1か所に固定されています。
var duration = schedule.duration(effectiveDate, now);
var elapsedBusinessMs = duration.getNumericValue();スケジュールの稼働時間は、土日を飛ばして数えられます。Resolved のあとに土日を挟むと、その分だけ Closed が遅くなります。
基準日時（effectiveDate）は、プロパティ com.snc.incident.autoclose.basedon.resolved_at が true のとき、解決日時（resolved_at）になります。公式の手順ページによると、このプロパティが true になっているのは London リリース以降の新規顧客だけで、既存の顧客は手動で true にする必要があります。この PDI では true でした。スクリプトには、解決後に依頼者がコメントしていれば、そのコメント日時を基準にする処理もあります。この動きは、コードを読んだだけで、実行して確かめていません。
日数のプロパティと実行の仕組み
日数の設定は、システムプロパティ glide.ui.autoclose.time です。
説明文（Description）は次のとおりです。
Number of days (integer) after which Resolved incidents are automatically closed. Zero (0) disables this feature.
（訳：Resolved のインシデントが自動で Closed になるまでの日数（整数）。0にするとこの機能は無効になる）
引用元：/sys_properties_list.do?sysparm_query=name=glide.ui.autoclose.time
値は7で、公式の既定値と一致しています。説明文には営業日の語が入っておらず、画面のプロパティ名も「days」のままです。営業日への変更は、画面の説明では分かりません。
実行は、スケジュールジョブ「Autoclose Incidents」が1時間おきに行います。
ビジネスルール incident autoclose 自体は、Insert・Update・Delete・Query のどれにもチェックが入っていません。
レコードを保存しても動かず、ジョブからだけ呼ばれる作りです。解決の条件を満たしたインシデントが閉じるのは、条件を満たした時点ではなく、次のジョブ実行のときです。
なお、このビジネスルールの更新日は2026-05-19、スケジュールの更新日は2026-05-04でした。Brazil へのアップグレードで入った変更かどうかは、アップグレード前の記録がないため確認できていません。
解決の曜日による閉じるまでの日数
既定値の7は、7×24＝168時間の平日の稼働時間です。土日は数えないため、閉じるまでの暦日は解決した曜日で変わります。平日に解決した場合は9〜11暦日で、旧方式の7暦日より最大4日延びます。
月〜水曜の朝に解決：9暦日後の朝ごろに閉じる（月曜の朝9時なら、翌週の水曜の朝9時）
木〜金曜に解決：11暦日後ごろに閉じる（木曜の朝9時なら、11日後の月曜の朝9時）
土曜に解決：月曜0時から数え始め、11暦日後ごろに閉じる
日曜に解決：月曜0時から数え始め、10暦日後ごろに閉じる
金曜の夕方に解決した場合：金曜の残りの時間も数える。土日に解決した場合だけ、月曜0時から数え始める
祝日を挟む場合：祝日も平日として数える。そのぶん実際のカレンダーでは短く閉じることがある
テスト結果でも同じ計算になります。木曜9/24の17:42（PDT）に解決した場合、金曜0時までの約6時間、金曜の24時間、翌週月〜金の120時間と数え、翌週の月曜10/5の17:42ごろに168時間に達します。11暦日後です。
Australia までは、同じ設定の7が暦日で、解決から7日後に閉じていました。同じ値のままアップグレードすると、平日の解決でも閉じるまでが2〜4日延びます。
対象外と閉じるときの記録
営業日の数え方とは別に、自動クローズの対象から外れる条件がいくつかあります。公式の手順ページとスクリプトから分かる範囲を整理します。
自動クローズの対象外になるもの
大規模インシデント：公式は、プロパティによる自動クローズの対象にならないと説明しています。大規模インシデントは別の手順で閉じます。引用元：Close a major incident。スクリプトにも、major_incident_state が Accepted のものを外す条件があります
OT インシデント：Operational Technology Incident Management のプラグインが有効なとき、sn_ot_incident テーブルとその子テーブルを対象から外す条件がスクリプトにあります。この PDI で有効かどうかは確認していません
依頼者が解決を却下したインシデント：状態が In Progress に戻るため、Resolved の条件に当てはまりません。公式の手順ページにも同じ説明があります
解決後に更新され続けるインシデント：公式は、インシデントに Inactivity Monitor（無操作の監視）がある場合、動くたびに自動クローズの時計がリセットされると説明しています。防ぐには、Reset Condition を「Incident state is not Resolved」にします
閉じるときに残る記録
スクリプトは、閉じるときに次の値を入れます。
incident_state と state を Closed にして、active を false にする
closed_by に resolved_by（解決した人）を入れる
コメント欄に「Incident auto-closed after {days} business days in Resolved state with no caller response」の文言を残す
{days} には、プロパティの値がそのまま入ります。この文言も営業日で書かれています。
更新者（Updated by）は、ジョブを実行したユーザーになります。公式の手順では、ジョブの Job context に fcRunAs=ユーザー名 を足すと、実行ユーザーを固定できると説明しています。引用元：Configure default user for auto-closing incidents
この PDI のジョブの Job context には fcScriptName=incident autoclose の1行だけが入っていました。fcRunAs は設定されていません。
テスト7件の結果
解決日をずらしたテスト用インシデントを7件作り、ビジネスルールを無改変で1回実行しました。PDI に Resolved のインシデントは他にありませんでした。メール送信（glide.email.smtp.active）は false です。
結果は次のとおりです。
表の内容を文字でも書き出します。
9/24（木）解決：暦日13.7日、平日233.0時間。Closed
9/26（土）解決：暦日11.7日、平日202.7時間。Closed
9/28（月）解決：暦日9.7日、平日185.0時間。Closed
9/29（火）解決：暦日8.7日、平日161.0時間。Resolved のまま
9/30（水）解決：暦日7.7日、平日137.0時間。Resolved のまま
10/1（木）解決：暦日6.7日、平日113.0時間。Resolved のまま
10/3（土）解決：暦日4.7日、平日82.7時間。Resolved のまま
しきい値は7×24＝168時間です。161時間の1件は、あと7時間足りず閉じませんでした。暦日の7日で判定するなら、8.7日と7.7日の2件も閉じていたはずです。
実行結果の出力でも、同じ結果を確認できます。
テスト用のインシデントは、確認後にすべて削除しました。実行でできた副産物のうち、テストの7件に紐づく sysrule_escalate_history 6件と、実行時に作られた sys_notification_execution 6件も削除しています。システムが非同期で作った sys_notification_execution 3件、後片付けで作られた sys_trigger（Online Alter Truncate Delayed Drop Table）2件、監査ログは残っています。プロパティの値は7のまま、変更していません。
運用への影響
ここからは、実機の事実から考えた運用の見方です。実機で確かめた内容とは分けて読んでください。
日次の件数や KPI
解決から Closed までの日数が伸びると、Closed の件数が出る日が後ろにずれます。月末や四半期末に「その月に Closed になった件数」を集計している場合、アップグレードの直後は、前の月の末に解決した分が翌月に入ります。アップグレードの前後で数字を比べるときは、解決日（resolved_at）で集計し直すと、方式の違いによる差が出ません。
利用者への案内
利用者向けの文書に「解決から7日で自動的にクローズします」と書かれている場合は、実際の動きと食い違います。月曜に解決した案件は、翌週の水曜ごろまで Resolved のままです。この間、依頼者は再オープンの機会を得られます。案内の文言は、「7営業日（土日を除く）」に直します。
調整するときの考え方
営業日方式で日数を決めるときは、次の2点を先に決めます。
Australia までと近い期間にしたいか、営業日方式の新しい運用に合わせて決め直すか
祝日をどう扱うか。この PDI のスケジュールには祝日が入っていないため、祝日を挟むと、実際のカレンダーでは短く閉じる
日数を変えるときは、プロパティの値を変える方法が一番小さな変更です。スケジュールとビジネスルールは出荷時のレコードです。変更する場合は、アップグレード後の挙動を別途確かめます。
自分の環境で確認すること
アップグレード後に、次の4点を確認します。
プロパティ glide.ui.autoclose.time の値。7のままなら、平日の解決で9〜11暦日後に閉じます。Australia までと同じ7暦日前後で閉じたいなら、5に下げるのが近い値です（5営業日は、平日の解決でおよそ7暦日）
営業日の定義に使われているスケジュール。ビジネスルール incident autoclose の scheduleId と、cmn_schedule の中身を見ます。このスケジュールに祝日を足せば祝日を飛ばして数えられるのかは、この記事では試していません
社内の運用ルールの文言。「解決から7日後に自動クローズ」と書いてあれば、「7営業日後」に直します。利用者や委託先への案内も対象です
日数を0にしている環境。0は機能の無効化のままで、営業日になっても意味は変わりません
見る場所を一覧にすると、次のとおりです。
表の内容を文字でも書き出します。
日数：プロパティ glide.ui.autoclose.time。営業日数のしきい値で、この PDI は7
基準日時：プロパティ com.snc.incident.autoclose.basedon.resolved_at。解決日時か更新日時かを決め、この PDI は true（解決日時）
営業日の定義：ビジネスルール incident autoclose の scheduleId。使うスケジュールが分かり、この PDI は 24 hours on weekdays
実行：スケジュールジョブ Autoclose Incidents。実行間隔と実行ユーザーが分かり、この PDI は1時間間隔で fcRunAs なし
確認用のURLは、次のとおりです。自分のインスタンスで開くと、同じ記述と値を見られます。
プロパティ：/sys_properties_list.do?sysparm_query=name=glide.ui.autoclose.time
スケジュールジョブ：/sys_trigger_list.do?sysparm_query=name=Autoclose Incidents
スケジュール：/cmn_schedule_list.do?sysparm_query=name=24 hours on weekdays
関連する設定は、別の記事にまとめています。
実機を見て気づいたこと
スケジュール名の公式記述
公式の3ページは、営業日で数えるとだけ説明していました。実際の定義は、ビジネスルールのスクリプト内に固定された1件のスケジュールです。プロパティの画面からは、営業日の中身にたどり着けません。
営業日の数え方を変えたいときは、プロパティではなく、このスケジュールのレコードかビジネスルールを見ることになります。スケジュールに祝日を足す案は候補にとどまり、動きは試していません。
Floating の日付境界
スケジュールの Time zone は Floating でした。実行したユーザーの Time zone は空で、計算の日付境界は PDI のタイムゾーン（太平洋時間）になっていました。表の「平日の経過時間」は、この境界で数えた値です。
日本時間で運用する環境では、月曜の0時の境界が、この PDI とは数時間ずれると見られます。ずれが数時間で収まるのか、スケジュールにタイムゾーンを指定したほうがよいのかは、確かめていません。
説明文と数え方のずれ
プロパティの説明も、画面のラベルも「days」のままでした。値の7も、記録上は2026-01-05のままです。見た目が同じまま、解釈だけが変わっています。設定を引き継いだ管理者が気づきにくい変更です。
用語
暦日：土日も含めて数える日数
営業日：この機能では、月曜から金曜の24時間（祝日なし）。会社の営業時間や休日カレンダーとは別の定義
スケジュール（cmn_schedule）：稼働する曜日と時間帯を定義するレコード。SLA などでも使われる
Floating：スケジュールに固定のタイムゾーンを持たせず、使う側のタイムゾーンに合わせる設定
ビジネスルール：レコードの保存や表示などに合わせてサーバー側のスクリプトを実行する仕組み。ここではジョブから呼ばれる
調査で使ったURL
公式ドキュメントは、次の6ページです。
自分のインスタンスで開く画面は、本文の「自分の環境で確認すること」にまとめています。
検証範囲とおことわり
検証したのは、Australia からアップグレードした1つの PDI です。Australia 時点の挙動との直接比較はしていません。「Australia までは暦日」は、公式の差分ノートの説明にもとづきます
試験は、7件のテスト用インシデント、1回の実行です。しきい値の近辺は161時間と185時間の2点で、168時間ちょうどの境界は試していません
依頼者のコメントによるクロックのリセット、sys_updated_on 基準（basedon.resolved_at が false）の動き、別のタイムゾーンでの計算は、コードを読んだだけで実行していません
祝日をスケジュールに足したときの動きは、試していません
画面の更新日（2026-01-05、2026-05-04、2026-05-19）が、アップグレードによる変更かどうかは分かりません
On-hold の自動解決の機能（公式の別項目）は、新規インスタンス専用のため、アップグレードしたこの PDI の対象外です
テスト用のインシデントは削除し、プロパティと設定は変更していません。この検証では外部への通信は行っていません
