#5 で「いつ動かすか」は cron に任せると書きました。では cron の時刻は何を根拠に決めるのか。この記事は、サイボウズが公開しているメンテナンス情報と障害情報、kintone の API 制限、そして各社のバッチが集中しそうな時間帯の想定から、 kintone に対するバッチの実行枠 を決める手順をまとめます。対象は kSQL-Flow / kSQL-FlowNet に限らず、kintone の REST API を夜間に叩くバッチ全般です。

公開情報だけから「唯一の安全な時間帯」は決められません。そこで、材料を 3 つの層に分けて扱います。

層	何か	この記事での扱い
事実	公開情報に書かれていること(メンテナンスの日時、API 制限の値)	そのまま引用する
観測	公開情報から数えて分かること(障害の時刻分布)	数えた範囲と数えられないことを併記する
仮説・暫定ルール	自社運用に当てはめるための想定と初期案(混雑の想定、推奨枠)	実測で調整する前提で書く

この回で分かること

定期メンテナンスの枠(確認した 10 か月すべてで第 2 日曜 1:00〜7:00 JST)と、そこに cron を重ねない方法
公開されている障害情報から読み取れる「高負荷が起きやすい時間帯」と、読み取れないこと
同時接続 100 と 1 日 1 アプリ 10,000 リクエストという制限が、時間帯の選び方にどう効くか
日次・月次・ポーラーそれぞれの初期案と、枠を外れたときに kSQL-FlowNet がどう振る舞うか

前提

実行サーバーの cron から kintone へ HTTPS で発信するバッチ(#1 の構成)。サーバーのタイムゾーンは Asia/Tokyo
時刻はすべて JST

事実 1: 定期メンテナンス

メンテナンス情報に載る「cybozu.com 定期メンテナンス」の案内を、2025 年 12 月度から 2026 年 9 月度まで 10 か月分確認しました。

月度	実施日	時刻	更新対象の記載
2025-12	12 月 14 日(日)	1:00〜7:00	kintone、Garoon、API
2026-01	1 月 11 日(日)	1:00〜7:00	kintone、API
2026-02	2 月 8 日(日)	1:00〜7:00	kintone、Garoon、API
2026-03	3 月 8 日(日)	1:00〜7:00	kintone、Garoon、API、cybozu.com 共通管理
2026-04	4 月 12 日(日)	1:00〜7:00	kintone、Garoon、API
2026-05	5 月 10 日(日)	1:00〜7:00	kintone、Garoon、サイボウズ Office、API
2026-06	6 月 14 日(日)	1:00〜7:00	kintone、Garoon、サイボウズ Office、API
2026-07	7 月 12 日(日)	1:00〜7:00	kintone、Garoon
2026-08	8 月 9 日(日)	1:00〜7:00	kintone、API
2026-09	9 月 13 日(日)	1:00〜7:00	kintone、Garoon、サイボウズ Office、API

10 か月すべてが 第 2 日曜の 1:00〜7:00 です。各回に「全サービス、およびサイボウズドットコムストアをご利用いただけないことがあります」とあり、更新対象には毎回 kintone が含まれ、7 月度(kintone と Garoon のみ)を除く 9 か月で API の更新が明記されています。案内はおおむね実施の 2〜3 週間前に出ます(1 月度は 12 月 19 日、9 月度は 8 月 28 日)。

バッチにとっての意味は 2 つです。

枠の中は API が返らない前提で組む。 「利用いただけないことがある」なので、返るときもあります。返ったり返らなかったりする状況は、全断より扱いにくい
枠の直後は API が更新されているかもしれない。 影響があるとは限りませんが、あるとすれば枠の後の初回実行に出ます。API 変更の影響を早く検知するため、月曜朝のバッチ結果は重点的に確認します

「第 2 日曜」はサイボウズが方針として明文化しているものではなく、案内から読み取った規則性です。運用では毎月の案内を確認してください。案内は前月の中旬から下旬に出るので、月初に当月分を見れば足ります。

観測: 障害情報

障害情報には 2025 年 12 月 21 日から 2026 年 9 月 3 日までの 20 件が載っています(2026-09-09 時点)。このうち kintone または cybozu.com 共通基盤のアクセスに影響し、発生時刻が書かれているものを抜き出しました。

発生	曜日	時刻	継続	内容	原因の記載
2025-12-20	土	23:47〜0:02、0:15〜0:36	15 分 + 21 分	kintone・Garoon の書込処理の遅延	一部サーバーの高負荷
2026-02-06	金	8:33〜13:54	5 時間 21 分	kintone に断続的にアクセスしづらい	一部サーバーの高負荷
2026-04-21	火	9:09〜10:38	1 時間 29 分	複数サービスに断続的にアクセスしづらい	一部システムの高負荷
2026-06-12	金	22:07〜22:59	52 分	cybozu.com 全体に断続的にアクセスしづらい	一部サーバー処理の不具合
2026-07-30	木	14:55〜15:11	16 分	kintone に一時的にアクセスできない	一部サーバー処理の不具合
2026-08-31	月	9:56〜12:07	2 時間 11 分	cybozu.com 全体に断続的にアクセスしづらい	内部システムの高負荷(リソース増強で解消)
2026-09-03	木	16:28〜16:45	17 分	kintone に断続的にアクセスしづらい	高負荷

次の 2 件は kintone の REST API への影響を示す事例ではないので、時間帯の観測から外しました。1 月 21 日(水)22:28〜22:44 はメール共有オプションとメールワイズの障害で kintone 本体は正常、3 月 24 日(火)17:13〜翌 9:50 は特定のセキュリティサービス利用環境で画面が白くなる現象です。

読み取れることは限られていますが、次は言えます。

抽出した公表事例には 1:00〜7:00 の発生がない(定期メンテナンスの枠を除く)。ただし障害情報は時間帯別の稼働統計ではないので、この時間帯が安全であることを示すものではありません
高負荷を原因とする公表事例 5 件のうち 4 件は 業務時間帯(8〜17 時) で、1 件は 23 時台です。サーバー処理の不具合 2 件は 14 時台と 22 時台。22 時以降にも 2 件ありますが、各社のバッチが原因だったかは公開情報から判断できません
最も長かったのは 2 月 6 日の 5 時間 21 分。8 月 31 日は月末・月曜・始業直後が重なった日で 2 時間 11 分でした

障害情報は「一部のお客様」の範囲を明かさず、API への影響を個別に書きません。9 か月・7 件は傾向を語るには少なく、時間帯の選定は避けられる混雑を避けるための確率の話です。

事実 2: API 制限

API の制限は時間帯の選び方に 2 つの形で効きます。サイボウズ全体の混雑とは別の、自社ドメインの中の話です。

同時接続数の上限は 1 ドメイン 100。同じドメインのアプリや連携(プラグイン、外部サービス、他部署のバッチ)が枠を共有し、上限を超えたリクエストは 429 になります(同時接続数の制限)。自分のバッチが直列でも、同じ時刻に自社の別の連携が走っていれば枠を食い合う。時間帯をずらして 429 を減らせるのは、自社ドメイン内の連携が同じ時刻に集中している場合です
1 日の上限は 1 アプリ 10,000 リクエスト(スタンダード)/ 100,000(ワイド) で、9:00〜翌 8:59 が集計単位です(API リクエスト数の上限)。8:00 に始めて 9:30 に終わるバッチは 2 日分の枠にまたがります。上限に近いバッチは、集計単位をまたがない時間に置くと数えやすい

kSQL-FlowNet はノードを 1 つずつ直列に起動し、kSQL-Flow はプロファイルで読取行数と API 呼出数の上限を持つので、同時接続を大量に使う構造ではありません。それでも枠は自社ドメイン内で共有です。

仮説: 混雑の想定

サイボウズの性能ガイドは「始業/終業などにアクセスが集中すると処理が遅延する場合がある」とし、定期処理は「業務時間外や夜間など利用者の少ない時間帯」を推奨しています。これに、kintone を使う各社のバッチがどこに集まるかの想定を重ねます。想定の根拠は業務慣行と上の観測だけで、実測ではありません。

時間帯・期間	何が集まるか(想定)	根拠
0:00〜1:00	「日付が変わったら」で組まれた日次バッチ	想定(cron の `0 0 * * *` は最も安易な既定値)
7:30〜10:00	始業前後のアクセス、朝一の集計・通知	性能ガイド、観測(8:33、9:09、9:56)
9:00	API 日次上限のリセット直後に再開する連携	想定(9:00 にリセットされる事実 2 から)
17:00〜19:00	終業時のアクセス、日報・締め処理	性能ガイド、観測(16:28)
22:00〜24:00	各社の夜間バッチの開始	想定。観測(22:07、23:47)は原因が各社のバッチとは公表されていない
月初 1〜3 営業日・月末最終営業日	締め・請求・月次集計	業務慣行、観測(8/31)
第 2 日曜 1:00〜7:00	定期メンテナンス	事実 1

時間帯マップ

上の材料を 24 時間に並べます。

日次バッチの開始候補は 3:00〜6:00 とし、平日の始業前アクセスを避けるため 7:30 までの完了 を目標にします。日付切替の混雑が引き、始業前の混雑が始まる前で、抽出した公表事例に発生がない帯です。開始時刻は実測した所要時間から逆算します。第 2 日曜はこの帯がまるごとメンテナンスに重なるので、日曜だけ別の時刻にします。実際の枠は、自社ユーザーのアクセスと他の連携の実測を見て調整します。

暫定ルール: 種類ごとの枠

バッチの種類	初期案	避ける	補足
日次(取込・集計)	平日と土曜は 3:00〜6:00 に開始し 7:30 までに完了。日曜はメンテナンス終了後の 8:00 以降	0:00〜1:00、平日の 7:30〜10:00、22:00〜24:00	日曜を一律 8:00 にすれば第 2 日曜の判定が要らない。日曜の利用者アクセスが少ない運用を前提とし、利用実態を確認してから決める
月次(締め・請求)	1 日の早朝に開始し 7:30 までに完了、または第 1 営業日の同時刻	1 日 0:00 直後、月末最終営業日の業務時間	1 日は第 2 日曜になり得ないのでメンテナンスと重ならない
週次	土曜の 3:00〜6:00	月曜の朝	月曜朝は週初のアクセスと重なる。特に第 2 月曜は前日の定期メンテナンス後(API 更新後)でもある
操作要求のポーラー(5 分間隔)	常時	なし	メンテナンス枠では GET が失敗し、何も書かずに終わる(後述)
手動の補正・再実行	業務時間内でもよいが、月末・月初の午前は避ける	月末月曜の 9〜12 時	8/31 の障害のような日は、急がない再実行を午後か翌日に回す

枠は「開始時刻」ではなく「完了時刻」で考えます。処理に 2 時間かかるバッチを 6:00 に始めると 8:00 に終わり、始業前の帯に入ります。所要時間を測り、7:30 までに終わる開始時刻に置きます。

月次と日次が同じ日に並ぶ日(1 日が日曜のときの月次 6:00 と日次 8:00 など)は、時刻差に頼らず #5 のパターン 1(直列連結スクリプト)で順序を固定します。network が違えば Network ロックは別ですが、同じジョブを共有していればジョブロックで競合し、API の枠も共有だからです。

初回本番導入で使った「毎月 1 日 7:00」は、30 分以内に完了することを前提とした枠の末端です。1 日は第 2 日曜と重ならず、7:30 までに終われば始業前の帯に入りません。30 分以上かかる場合は開始を前倒しします。

cron の書き方

日曜だけ時刻を変えるのは、cron 2 行で済みます。第 2 日曜だけを判定する必要はありません。

# 日次: 月〜土は 4:17、日曜は 8:17(定期メンテナンス 1:00〜7:00 を避ける)
17 4 * * 1-6 . /root/.ksql-flownet.env && /opt/ksql/my-ksql-jobs/run_daily_chain.sh >> /var/log/ksql/flownet-daily.log 2>&1
17 8 * * 0   . /root/.ksql-flownet.env && /opt/ksql/my-ksql-jobs/run_daily_chain.sh >> /var/log/ksql/flownet-daily.log 2>&1
# 月次: 毎月 1 日 6:17
17 6 1 * *   . /root/.ksql-flownet.env && /opt/ksql/my-ksql-jobs/run_monthly_summary.sh >> /var/log/ksql/flownet.log 2>&1
# 操作要求のポーラー: 常時 5 分
*/5 * * * * . /root/.ksql-flownet.env && cd /opt/ksql/my-ksql-jobs && ksql-flownet poll-requests >> /var/log/ksql/flownet-requests.log 2>&1

分を 00 ではなく 17 にしているのは、各社の cron が 00 分ちょうどに集中しやすいからです。サイボウズ側の瞬間的な負荷を避ける効果は測れませんが、自社ドメイン内の他の連携が 00 分に始まる場合、特に短時間の処理とは重なりにくくなります(00 分起動の処理が 17 分以上続けば重なります)。17 という値に意味はないので、環境ごとに 07、13、23 のような端数へ散らしてください。

run_daily_chain.sh の中で --scheduled-for に当日 0:00 を渡しているので(#5 のパターン 1)、日曜の 8:17 に動いても業務キーは同じ日付になります。土曜の 4:17 と日曜の 8:17 の間隔が 28 時間になることは、業務キーが日付で決まる限り問題になりません。

枠を外れたときに kSQL-FlowNet はどう振る舞うか

時間帯を選んでも、臨時メンテナンスや障害には当たります。そのときの振る舞いは #6 の fail-closed そのものです。

状況	振る舞い	人がすること
実行中に kintone へ届かなくなった(メンテナンス枠、障害)	lease の再確認を lease 期間の上限まで繰り返し、回復しなければ確認できない結果を推測で確定せず、最後に確定した状態を残して終了する(`NETWORK_LEASE_INTERRUPTED`)。実機で通信を全遮断して確認済み(#9 の `m7-02`)	通信回復後、失敗した Run と最後に確定した状態をボードで確認し、同じ `--scheduled-for` を指定して明示的に再開する(#5 の `SCHEDULED_FOR`)。翌日の通常 cron は翌日分の業務キーを処理するので、前日分を自動では再開しない
cron の発火時刻にサーバーが止まっていた	cron は過ぎた発火を補完しない。その日の Run は作られない	ボードの「未実行」に気づいたら `SCHEDULED_FOR` で対象日を指定して実行(#5)
メンテナンス後に API の挙動が変わっていた	その影響が件数やテストデータ混入といった定義済みの条件違反として現れた場合は、先頭の ASSERT ゲートが止め、書込ノードまで進まない。ASSERT の対象外の変化までは検知できない	月曜朝にボードで `FAILED` を確認し、原因を見てからリラン。合格した Run も結果値を一度は目で確認する
ポーラーがメンテナンス枠に当たった	要求の GET が失敗した周期は要求・state・audit のどれにも書かない(#9 の `p2-01-06`)	何もしない。次の周期で拾う。ログには失敗が残る
同一ノードが 3 回連続で同じ失敗	自動再実行を止める(`RETRY_BRAKE`)	原因を直してから `--rerun-from` で解除

fail-closed の価値は「何も残らない」ことではなく、 確認できない結果を確定して書かない ことです。中断前に書いた Run や Attempt の記録は残ります。再開時にはその孤児 Attempt を JOBログと突き合わせ、終端ログがあればその結果を適用し、照合できなければ UNKNOWN にして人の判断に回します(#6)。翌朝の判断材料が「最後に確定した状態」と「確定できなかった Attempt」に分かれているので、推測で埋める必要がありません。

まとめ

定期メンテナンスは確認した 10 か月すべてで第 2 日曜 1:00〜7:00。案内は実施の 2〜3 週間前に出るので、月初に当月分を確認する
障害情報から言えるのは「抽出した公表事例に 1〜7 時の発生はない」「高負荷は業務時間帯に多く、22 時以降にもある」まで。時間帯別の稼働統計ではないので保証にはならない
同時接続 100 は自社ドメイン内で共有、1 日上限は 9:00 区切り。サイボウズ全体の混雑とは別に、自社の連携どうしの時刻をずらす
初期案は日次 3:00〜6:00 開始・7:30 完了、日曜だけ 8:00 以降、月次は 1 日の早朝。cron 2 行で第 2 日曜を避け、分は 00 からずらす。枠は完了時刻で考え、実測で調整する
枠を外れたら fail-closed。確認できない結果は書かず、同じ --scheduled-for で明示的に再開する
#5 スケジュール連携編: https://qiita.com/rex0220/items/b182371cfafea79af2da
#6 障害対応編: https://qiita.com/rex0220/items/32bd31431142e9f852cb
メンテナンス情報: https://cs.cybozu.co.jp/maintenance/
障害情報: https://cs.cybozu.co.jp/trouble/
kintone の性能上の考慮点: https://kintone.cybozu.co.jp/kintone-signpost/guide/performance.html
API リクエスト数の上限: https://cybozu.dev/ja/kintone/tips/best-practices/performance/kintone-api-request-limit-exceeded-guide/