2026 年 10 月 21 日の午後から 23 日にかけて、国内の業務システムが次々に止まりました。プログラミング言語 PHP に重大な脆弱性が見つかり、提供元が修正を当てて安全を確かめ終わるまで、自分からサービスを止めたからです（予防的な停止）。いわゆる「PHP 祭り」です。
では、この止まり方は、ふだんの計画メンテナンスや障害と、何が同じで何が違ったのでしょうか。IT連携マップ編集部が集めている提供元の告知 751 件（計画メンテナンス 309 件・予防的な停止 9 件・国内の障害 94 件・海外と AI の障害 339 件）で比べました。
答えは次の 3 つです。
- 計画メンテナンス: 59% が夜（21〜6 時）に、35% が週末に始まり、夜に始まったものの 95% は朝 9 時までに終わります。長さの中央値は 5 時間です。
- 予防的な停止（臨時メンテナンス）: 計画メンテナンスと同じく夜に始まるものが多い（67%）のですが、長さの中央値は 14.9 時間と約 3 倍で、63% が平日の 9〜18 時にかかりました。
- 障害: 平日の昼に起きます（81% が平日の 9〜18 時にかかる）。多くは一部の機能だけが止まり、つながらない・ログインできない障害は 15% でした。
止まった理由と時刻は、提供元の公式の情報（ステータスページ・お知らせのページ・公式の X の投稿）を正としました。利用者の報告は補いに使い、IT連携マップ編集部の観測は参考にとどめて、この集計には使っていません。
では、先週は何が起きたのでしょうか。
1. 先週の PHP 祭りでは、何が起きたのか？
2026 年 10 月 21 日の午後から 22 日の午前にかけて、表の 11 のサービスが自分からサービスを止めました。理由に PHP の脆弱性と書いたのは、そのうち 5 つです。提供元の告知で止まった時刻と範囲を確かめると、止まっていた時間は約 1 時間 15 分から約 41 時間 40 分でした。IPA（情報処理推進機構）も、PHP の脆弱性の注意喚起で、暫定の対策が難しい場合は「外部からのアクセス遮断やサービスの一時停止が必要か判断してください」と求めています。
| サービス | 止まった時間 | 止まった範囲 | 告知に書かれた理由（提供元の告知） |
|---|---|---|---|
| Chatwork | 約 1 時間 15 分（10/21 23:00〜10/22 0:15） | サービス全体 | PHP の脆弱性への予防的な対策 |
| TKC | 約 25〜49 時間（10/21 23:00〜10/23・再開の時刻の記載なし） | 会計事務所向けなどの一部 | PHP の脆弱性 |
| SPIDERPLUS | 33 時間（10/22 8:00〜10/23 17:00） | 5 つのサービス | PHP の脆弱性への予防的な対応 |
| ジンジャー | 12 時間（10/21 17:00〜10/22 5:00・終わりは予定の時刻） | 勤怠など 4 つ以外の全サービス | セキュリティを取り巻く状況 |
| Garoon（クラウド版） | 6 時間 1 分（10/21 21:00〜10/22 3:01） | サービス全体 | セキュリティ上の予防的な措置 |
| 弥生のかんたん会社設立 | 約 22 時間（10/22 0:00〜10/22 22:00） | サービス全体 | 予防措置 |
| 弥生のかんたん開業届 | 約 41 時間 40 分（10/22 0:00〜10/23 17:40） | サービス全体 | 予防措置 |
| freee の 4 サービス | 17 時間 52 分（10/21 19:04〜10/22 12:56） | FREENANCE など 4 つ | 書かれていない（告知） |
| LoGo フォーム | 5 時間 9 分（10/21 21:00〜10/22 2:09） | PDF 帳票の機能 | 書かれていない（告知） |
| BASE | 16 時間 10 分（10/21 15:50〜10/22 8:00） | サービス | PHP の脆弱性 |
| 国税庁 | 約 5 時間 50 分（10/22 10:20 頃〜16:10 頃） | 国税庁ホームページ等 | PHP の脆弱性 |
サービスの名前は IT連携マップの稼働状況のページへ、理由は提供元の告知へつないでいます（弥生の 2 つ・freee の 4 サービス・国税庁は、IT連携マップに同じ製品のページが無いので、理由の列の告知だけです）。
表の最後の 2 つ（BASE と国税庁）は、告知が公式の X の投稿と PDF だけだったので、後から原文を確かめて足しました。2 節からの図と数（予防的な停止 9 件）は、表の上から 9 行で数えています。
告知に書かれた理由は 3 通りに割れました。表の 11 のうち、PHP の脆弱性と書いたのが 5 つ、「予防」「セキュリティ」とだけ書いたのが 4 つ、理由を書かなかったのが 2 つです。告知の場所も、お知らせのページ・ステータスページ・X の投稿・PDF に分かれました。告知の名前も「緊急メンテナンス」（Garoon）と「臨時メンテナンス」（freee）に分かれました。止まったことは、攻撃されたことを意味しません。ジンジャーは不正アクセスが発生したためではないと書き、TKC は攻撃を確認していないと書いています。
では、この止まり方は、ふだんのメンテナンスと比べて、いつ始まり、いつ終わったのでしょうか。
2. いつ始まり、いつ終わるのか？ — 計画メンテナンスは夜と週末、障害は平日の昼
計画メンテナンスの多くは、夜中に始まり、朝までに終わります。最も多い開始は 1 時（23%）で、22 時（15%）と 0 時（9%）が続き、曜日は日曜（20%）が最も多くありました。夜に始まったものの 95% は、朝 9 時までに終わりました。提供元は、使う人の少ない時間を選んで止めています。
予防的な停止は、9 つのうち 6 つが水曜（10/21）の 17 時以降に、3 つが木曜（10/22）の 0 時と 8 時に始まりました。始まりは計画メンテナンスと同じ夜でも、平日の夜だったので、63% が翌日の業務時間（平日の 9〜18 時）にかかりました。
障害は逆に、平日の昼に始まります。国内の障害の 81% は平日の 9〜18 時にかかり、夜に始まったのは 11%、週末に始まったのは 4% でした。曜日では月曜が最も多く、51% は 3 時間以内に復旧しました。海外の業務システムと AI のサービスの障害は、55% が日本時間の夜（米国の朝から昼）に始まりました。
では、止まっていた長さはどう違ったのでしょうか。
3. 何時間くらい止まるのか？ — 予防的な停止は計画メンテナンスの約 3 倍
計画メンテナンスの長さの中央値は 5 時間で、65% は 3〜12 時間でした。12 時間を超えたのは 11% です。予防的な停止は、長さの分かる 8 つのうち 5 つが 12 時間を超え、中央値は 14.9 時間でした。SPIDERPLUS のように、サーバーごとに順に再開したところは長くなりました。
国内の障害の、復旧までの時間の中央値は 2.8 時間ですが、症状で大きく違います。遅い・つながりにくい障害は中央値 48 分で復旧し、つながらない障害は 3 時間、一部の機能の不具合は復旧まで 16.6 時間かかりました。
では、止まっている間、何が使えなくなるのでしょうか。
4. 何が止まるのか？ — 全体か、一部か、遅いだけか
計画メンテナンスの 44% はサービス全体が止まり、30% は一部の機能だけが止まり、4% は遅い・つながりにくいだけでした。22% は、止まるものを告知に書いていませんでした。予防的な停止は 9 つのうち 5 つがサービス全体を止め、freee は 4 つのサービスだけを、LoGo フォームは PDF 帳票の機能だけを止めました。
国内の障害では、一部の機能が使えないものが 32%、遅い・つながりにくいものが 29% で、つながらないものは 15% でした。どの止まり方でも、止まる範囲はサービス全体とは限りません。告知の対象の欄で、自分が使う機能が入っているかを確かめる必要があります。
計画メンテナンスの告知で作業の中身を書いていた 76 件では、連携先のメンテナンスで止まるものが 52 件と最も多くありました。たとえば マネーフォワード クラウド社会保険 は、e-Gov やマイナポータルのメンテナンスの時間帯に、電子申請の操作ができなくなると書いています。自分の使うシステムが正常でも、つながっている先が止まれば、その機能は止まります。
では、障害のときは、どこで止まっているのでしょうか。
5. 障害はどこで起きるのか？
原因を書いた国内の障害の告知 29 件のうち、15 件は提供元の内部（更新作業・設定・プログラム）、10 件は負荷・アクセスの集中でした。たとえばサイボウズは、kintone の障害の原因を「システム更新作業の手順に不備があった」と書いています。遅い・つながりにくい障害で原因を書いた 11 件のうち 9 件は、サーバーの高負荷かアクセスの集中でした。回線や CDN（Content Delivery Network・コンテンツ配信ネットワーク）が原因だったのは 2 件、連携先などの外部のサービスが原因だったのは 2 件です。Greenfile.work は、建設キャリアアップシステム（CCUS）との連携が止まった理由を「CCUSへのアクセス集中のため」と書いています。
利用者の PC や社内ネットワークの不調は、提供元の告知には載りません。ステータスページが正常なのに使えないときは、自分の側から確かめる手順に進みます。
では、海外のサービスや AI では、止まり方と知らせ方は同じなのでしょうか。
6. 日本・海外・AI では、何が違うのか？
いちばん違うのは、知らせ方です。日本の業務システムの 74% は、障害とメンテナンスを会社のお知らせのページ（ニュースの一覧）に載せ、専用のステータスページを持つのは 13% でした。海外の業務システムの 60%、AI・ツールの 80% は、専用のステータスページで知らせ、機能ごとの小さな障害まで載せます。ステータスページは、いま使えるかと過去の障害を 1 か所に並べるページです。障害の告知は 1 システムあたり 1 か月に中央値 4.08 回（海外の業務システム）と 5.34 回（AI・ツール）で、日本の 0.5 回より多くなりました。告知が多いことは、止まることが多いことと同じではありません。小さな障害まで知らせている、ということです。
稼働率（サービスが使えた時間の割合）の数字は、AI・ツールの 10 システム中 8 システムがステータスページに出していました（直近 90 日でいちばん低い機能が 99.29〜100%）。海外の業務システムは 15 システム中 2 システムで、日本の業務システムは、IT連携マップが告知の場所を見ている 69 システムのどれも出していませんでした。
メンテナンスの扱いも違います。日本の業務システム（69 システム）は、2026 年 8〜10 月に計画メンテナンスを 1 システムあたり 1 か月に 1.21 回告知し、夜に止めます。海外と AI のサービスで、止まる時間を前もって告知した計画メンテナンスは、IT連携マップが集めた告知にはほとんどありませんでした（1 か月に 0〜0.07 回）。
では、利用者はどう備えればよいのでしょうか。
7. 利用者はどう備え、どこで状況を確かめればよいのか？
備えは 2 つです。告知の場所を決めておくことと、止まる時間に要る作業や定時の処理を前後に動かすことです。
画面で使う人は、告知の場所をブックマークし、告知を見たら止まる時間に要る作業を前に動かします。予防的な停止のように告知が直前のときもあるので、締め切りの近い申請や請求は早めに済ませておきます。
連携を作った人は、止まる時間の定時の処理を止めるか後で再実行する形にし、失敗を記録して知らせます。予防的な停止は再開の時刻が決まっていないことがあり、SPIDERPLUS は止めたときの告知に、再開の予定は「決まり次第改めてお知らせいたします」と書いていました。待って再試行する形にしておけば、再開の時刻が分からなくても困りません。
いま止まっているかは、IT連携マップの「稼働状況・障害情報」（https://renkeimap.jp/status）で確かめられます。システムごとのページの上の「ただいまの状況確認」に、提供元の公式発表へのリンク、提供元の告知の題、利用者の報告、編集部の観測を並べています。
読むときは、提供元の公式の告知を正とし、利用者の報告を補いに使い、編集部の観測は参考にとどめてください。画面の各欄の読み方は、完全版の システム障害とは の 5 節 に画面の例で説明しています。
まとめ — 4 つの止まり方の共通点と違い
| 計画メンテナンス | 臨時メンテナンス（予防的な停止） | 障害（国内） | |
|---|---|---|---|
| 誰が止めるか | 提供元 | 提供元 | 誰も止めようとしていない |
| 告知 | 前もって予告 | 直前か、止めてから | 起きてから |
| 夜（21〜6 時）に始まる | 59% | 67% | 11% |
| 長さ（中央値） | 5 時間 | 14.9 時間 | 2.8 時間 |
| 平日の 9〜18 時にかかる | 16% | 63% | 81% |
| サービス全体が止まる | 44% | 56% | 15%（つながらない） |
共通点は 2 つです。1 つ目は、どの止まり方でも、止まる範囲はサービス全体とは限らないことです。2 つ目は、告知の場所と書き方がシステムごとにばらばらなことです（お知らせのページ・ステータスページ・X の投稿・PDF）。
違いは、告知のタイミングと長さです。計画メンテナンスは前もって知らせ、夜の数時間で終わります。予防的な停止は直前に知らせ、平日の昼まで長くかかりました。障害は平日の昼に起き、多くは一部の機能だけが止まります。
調べ方
- IT連携マップ編集部が 2026 年 10 月 26 日に、IT連携マップが集めている提供元の告知を読み、始まった時刻・長さ・止まった範囲・症状・原因で分けました。止まった範囲・症状・原因は、告知の文の語で分けた近似です。
- 稼働率は、提供元が自分で出している数字だけを使いました。障害の告知の時間から稼働率を計算することはしていません。
📎 集計したシステムの数と期間、分け方の決まり、出典の原文は、完全版の メンテナンスとは の「調査の詳細」 と システム障害とは の「調査の詳細」 にまとめています。
読者アンケート実施中
このテーマをもっと深掘りしてほしい方は、記事に「いいね」をお願いします。「いいね」の多いテーマから順に追加調査し、結果は新着記事でお知らせします（フォローしていただくと通知が届きます）。
【転載OK】本記事の転載について
本記事の文章・図表は、すべて転載 OK です。図は加工しないままお使いください。転載の際は、出典として、この記事の完全版 『メンテナンスとは』（renkeimap.jp）へのリンクをお願いします。事前の連絡は不要です。