「保守の提案書に『24/365対応』と書いてあるが、これは結局、夜中に何かあったら直してもらえるという意味なのか」——保守運用の契約を前にした事業会社のご担当者から、こうした相談をよく受けます。読み方も自信がない、社内で聞ける相手もいない、それでいて役員には金額の理由を説明しなければならない。この記事は、そういう立場の方に向けて書きます。
結論から言うと、24/365は「24時間365日」の略記で、英語圏で使われる24/7と同じものを指します。問題は、その4文字が何を24時間やるのかまでは決めていないことです。システムが24時間動いていることと、24時間人が対応することは、まったく別の約束です。そして人が関わる側は、監視だけ24時間なのか、一次対応まで24時間なのか、復旧まで24時間なのか、という3段階に分かれます。
この区別は私の造語ではありません。IPA(独立行政法人情報処理推進機構)の「非機能要求グレード2018」でも、システムの稼働時間を決める項目と、異常を検知したときに保守員が作業する時間帯を決める項目は、別々の要求項目として定義されています。設計の話と、人の体制の話だからです。費用のかかり方も、まったく違います。
本記事では、24/365の読み方と表記ゆれ、稼働と有人対応を分けて考えるための3段階、有人監視と無人監視・オンコールとシフトの違いと必要な人数の目安、費用が跳ね上がる理由と自社に24/365が要るかを判断する5つの問い、要らない場合の代替3つ、よくある質問の順に解説します。費用については、出典を示せる数字だけを書きました。公開情報から確認できなかったことは、確認できなかったと明記しています。
私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。保守運用の相談で繰り返し見てきたのが、「監視は24時間だが作業着手は翌営業日」という契約を、24時間いつでも直してもらえる契約だと読み違えていたケースです。この記事を読み終えるころには、手元の提案書が3段階のどれを売っているのか、そして自社にそれが必要なのかを、自分の言葉で判断できるはずです。
目次
- 24/365とは
- 読み方と表記ゆれ
- 24/7との違いは「慣習」だけ
- 「24/365運用」と「24/365保守」で指すものが変わる
- 最も混同されるのは「システムが動いている」と「人が見ている」
- IPAの非機能要求グレードでも、稼働時間と対応可能時間は別の項目
- 24/365の3段階(表)
- 提案書のどこを読めば3段階が分かるか
- 「監視は24時間、作業着手は翌営業日」という契約は珍しくない
- 有人監視と無人監視、オンコールとシフト
- 無人監視(自動)と有人監視(人が常時見る)の違いと、できること・できないこと
- オンコールとシフトの違い(表)
- 必要な人数の目安
- 費用が跳ね上がる理由と、自社に24/365が本当に要るかを判断する5つの問い
- 跳ね上がるのは「人が起きる」段階から
- 公開情報で確認できた実額と、確認できなかったこと
- 自社に24/365が要るかを判断する5つの問い(チェックリスト)
- 24/365が要らないときの代替3つと、当社が提供できる範囲
- 代替3つ(表)
- 当社の立場——24時間365日のオンコール体制は標準では提供していません
- 24/365に関するよくある質問
- Q1. 24/365と24/7は違うものですか
- Q2. 契約書に24/365と書いてあれば、夜中に障害が起きても直してもらえますか
- Q3. 無人監視(自動監視)だけでは不十分ですか
- Q4. 自社で24時間365日の体制を作るには何人必要ですか
- Q5. いったん24/365で契約したら、あとから縮小できますか
- まとめ: 24/365は「24時間365日」
24/365とは——「24時間365日」の略記。24/7・24H365Dとの違いと、どこで使われる表記か
24/365は、「24時間365日」を略した書き方です。読み方は「にじゅうよん さんろくご」または「にじゅうよんじかん さんびゃくろくじゅうごにち」で、決まった正式名称があるわけではありません。ITの保守運用、コールセンター、医療・警備・インフラなど、休みなく動き続ける業務の文脈で使われます。まずは表記のゆれと、この言葉がどの場面に出てくるのかを押さえてください。
読み方と表記ゆれ——24/365、24365、24時間365日、24H365D、24/7
同じ意味で使われる表記は次のとおりです。どれが正しいというルールはなく、書き手の習慣で決まっています。
表記 | よく使われる場面 | 補足 |
|---|---|---|
24/365 | 保守運用の提案書、サービス名 | 最も一般的。スラッシュは「時間/日数」の区切り |
24365 | 見出し、タグ、URL | スラッシュを省いた形。検索されるのはこの形も多い |
24時間365日 | 契約書、営業資料の本文 | 最も誤解が少ない。正式な文書ではこの表記が無難 |
24H365D | 図表、社内資料 | Hはhour、Dはday |
24/7 | 英語の資料、外資系ベンダーの資料 | 24 hours a day, 7 days a week の略 |
契約書や要件定義書を書く立場になったときは、略記ではなく「24時間365日」と書くことをおすすめします。略記は読み手によって解釈の幅が出るためです。そして後述するとおり、実務で問題になるのは表記ではなく「何を24時間やるのか」が書かれていないことです。
24/7との違いは「慣習」だけ——同じ会社の同じページが英語で24/7、日本語で年中無休と書く
24/365と24/7は、指しているものが同じです。違うのは、英語圏が「1日24時間・週7日」と週単位で言い慣わしてきたのに対し、日本語圏では「24時間365日」と年単位で言い慣わしてきた、という慣習の差だけです。
分かりやすい実例があります。AWSのサポートプラン紹介ページは、英語版ではテクニカルサポートの提供を「24/7 phone, web, chat, email」と書いていますが、同じ内容の日本語版では「年中無休の電話、ウェブ、チャット、電子メール」と書かれています(いずれも2026年9月16日確認)。同一企業の同一ページでこれだけ表記が変わるのですから、「24/7だから海外式、24/365だから国内式」といった区別に意味はありません。
「24/365運用」と「24/365保守」で指すものが変わる——運用は動かし続ける、保守は直す
もう一つ、表記より大事な違いがあります。24/365が「運用」に付くか「保守」に付くかで、指している作業が変わることです。
一般に、運用はシステムを正常に動かし続けるための日常業務(監視、バックアップ、ログの確認、アカウント管理など)を指し、保守は不具合が起きたときの原因究明と復旧、およびソフトウェアの更新や改修を指します。ただし、この線引きは会社によって揺れます。運用会社が保守まで担当しているケースも、保守ベンダーが監視を持っているケースもあり、契約書の中で定義されていなければ、どちらの意味で使われているかは読み取れません。
当社の実績でも、たとえばLLMを使ったAIチャットボットは24時間稼働しています。ただしこれは「システムが24時間動いている」という意味であって、「24時間人が待機している」という意味ではありません。ここを混ぜて理解してしまうと、提案書の読み方を間違えます。次の章で、この区別を正面から扱います。
最も混同されるのは「システムが動いている」と「人が見ている」——24/365には3段階ある
ここがこの記事の核心です。「24/365」と書かれた提案書を受け取ったとき、確かめるべきは表記ではなく「何を24時間やるのか」です。システムが24時間止まらずに動いていることと、24時間人が対応することは、別の約束です。前者は設計で実現し、後者は人の体制で実現します。混同したまま要件を書くと、要らない人件費を払うか、検知だけして朝まで止まったままになるかのどちらかになります。
IPAの非機能要求グレードでも、稼働時間と対応可能時間は別の項目
この区別は、現場の経験則ではなく、公的な要件定義の枠組みにも明記されています。IPA(独立行政法人情報処理推進機構)が公開している「非機能要求グレード2018」は、システムの非機能要件を6つのカテゴリに整理した枠組みで、官公庁や電力・金融などの調達仕様書で参照されています。
このグレードでは、次の2つが別々の要求項目として定義されています(項目番号・レベル値は、電力広域的運営推進機関の調達資料に添付された活用シートの記載による。2026年9月16日確認)。
項目 | カテゴリ | 何を決める項目か | 最上位レベルの内容 |
|---|---|---|---|
A.1.1.1 運用時間(通常) | 可用性 | 「オンライン/バッチを含みシステムが稼動している時間帯」 | レベル5「24時間無停止」 |
C.3.3.1 対応可能時間 | 運用・保守性 | 「システムの異常検知時に保守員が作業対応を行う時間帯」 | レベル2「24時間対応を行う」 |
前者はシステムを止めない設計の話で、冗長化やクラスタ構成、クラウドの自動復旧などで実現します。後者は人の話で、深夜に作業できる保守員をどう確保するかの話です。同じ「24時間」でも、費用のかかり方がまったく違います。
さらに、運用時間のレベルは「規定無し / 定時内(9時〜17時) / 夜間のみ停止(9時〜21時) / 1時間程度の停止有り(9時〜翌朝8時) / 若干の停止有り(9時〜翌朝8時55分) / 24時間無停止」の6段階で定義されています。対応可能時間のほうは3段階(ベンダの営業時間内 / ユーザの指定する時間帯 / 24時間対応)で、別項目の「ベンダ側対応時間帯」ではさらに細かく、「対応無し / 定時内(9〜17時) / 夜間のみ非対応(9〜21時) / 引継ぎ時に1時間程度非対応有り(9〜翌8時) / 24時間対応」の5段階が用意されています。つまり、24時間か否かの二択ではなく、その手前に段階があるという前提で設計されているということです。
24/365の3段階(表)——①監視だけ24時間 ②一次対応まで24時間 ③復旧まで24時間
人が関わる側を、実務で使う粒度に分けると3段階になります。提案書の「24/365対応」がどれを指しているのかを、この表で当ててください。
段階 | 24時間やること | 夜中に障害が起きたら | 必要な体制 | 費用の水準 |
|---|---|---|---|---|
① 監視だけ24時間 | 異常の検知と通知(メール・電話・チャットへの発報) | アラートは飛ぶ。ただし動く人がいなければ朝まで止まったまま | 監視ツールと通知設定。人は不要(無人監視) | 最も安い。自動化で完結する |
② 一次対応まで24時間 | 検知+決められた手順の実施(再起動、切り離し、待機系への切り替え、報告とエスカレーション) | 手順書にある範囲は夜中に着手される。手順外は翌営業日 | オンコール待機またはシフト。手順書と権限の事前付与が必須 | ①より大きく上がる |
③ 復旧まで24時間 | 原因の切り分けから除去まで、時間帯を問わず人が動き続ける | 原因が何であれ、復旧まで担当者が張り付く | 設計を理解した技術者の常時確保。交代要員と引き継ぎの仕組み | 最も高い。②とさらに差がつく |
多くの提案書が「24/365監視」と書くとき、実態は①か②です。③まで含む契約は、金額も体制も別物になります。なお、この3段階は、私が保守運用の相談を受けるときに必ず確認する順番でもあります。
提案書のどこを読めば3段階が分かるか——確認する4つの文言
見出しに「24/365」と書いてあっても、本当の範囲は細かい条項に書かれています。次の4つの文言を探してください。
- 「受付時間」と「作業時間」が分けて書かれていないか。 受付は24時間、作業着手は翌営業日、という書き分けは一般的です。実在の事業者の公開サービス仕様でも、24時間365日の有人監視をうたいながら「緊急性の低い作業は営業時間(10:00〜19:00)での対応」と明記している例があります(2026年9月16日確認)
- 約束されているのが「応答」か「復旧」か。 多くのサービスは初回応答時間を約束しますが、復旧時間は約束しません。たとえばAWSのサポートプランは、ビジネス/ミッションクリティカルなシステム停止に対する初回応答時間を「30分未満」(ビジネスサポート+)、「15分未満」(エンタープライズサポート)としていますが、これは応答の時間であって復旧の時間ではありません
- 一次対応の「範囲」が具体的に書かれているか。 「再起動まで」「待機系への切り替えまで」のように、夜間に実施できる作業が列挙されていれば②、「切り分けと連絡のみ」なら実質①です
- エスカレーション先が夜間も稼働しているか。 一次対応チームが24時間でも、その先の開発ベンダーが日中しかいなければ、原因がアプリケーション側にある障害は朝まで直りません
障害が起きたあとに現場で何をどの順番でやるのか、原因の切り分けはどう進めるのかは、「サーバー障害 原因 対応」の記事で詳しくまとめています。本記事は「契約書の24/365が何を約束しているか」に絞ります。
「監視は24時間、作業着手は翌営業日」という契約は珍しくない
私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。保守運用の相談で繰り返し見てきたのが、「提案書に24/365と書いてあるから、夜中でも直してもらえると思っていた」という読み違いです。契約書を一緒に読むと、監視は確かに24時間だが、作業着手は翌営業日の9時から、と書かれている。これは業者が不誠実なのではなく、買う側が3段階を意識せずに読んでいただけ、というのが実情です。
逆のパターンもあります。社内システムしか動いていないのに、③の水準を要件に書き込んでいたケースです。夜間に誰も使わないシステムのために深夜の人員を確保する契約になっており、更新時に②へ落として費用を下げました。要件は、高く書けば安全になるものではありません。何を24時間やるのかを決めずに「24/365」と書くのが、失敗のもとです。
有人監視と無人監視、オンコールとシフト——体制の違いと、必要な人数の目安
3段階のうち②と③を選ぶなら、次に決めるのは体制です。ここで出てくるのが「有人監視か無人監視か」「オンコールかシフトか」という2つの軸です。言葉は似ていますが、決めているものが違います。前者は見張る側の話、後者は動く側の話です。そして人数と費用に直結するのは後者です。
無人監視(自動)と有人監視(人が常時見る)の違いと、できること・できないこと
監視そのものは、機械に任せられます。IPAの非機能要求グレードでも、監視の内容は「死活監視 / エラー監視 / エラー監視(トレース情報を含む) / リソース監視 / パフォーマンス監視」の段階で、監視の間隔は「不定期(手動監視) / 定期(1日間隔) / 定期(数時間間隔) / リアルタイム(分間隔) / リアルタイム(秒間隔)」の段階で定義されています。秒単位のリアルタイム監視を人間の目でやる必要はなく、ここは自動化の領域です。
方式 | やっていること | 向いていること | 苦手なこと |
|---|---|---|---|
無人監視(自動) | ツールが死活・エラー・リソース・応答速度を常時チェックし、閾値を超えたら発報する。再起動などの定型アクションまで自動化することもある | 24時間の検知、記録の蓄積、人間より速い反応、費用の安さ | 閾値に引っかからない異常、複数の症状から原因を推測すること、顧客への説明判断 |
有人監視 | 人がダッシュボードを見て、アラートの意味を判断し、手順を実行する。緊急度の判定と連絡も行う | 誤報の切り分け、手順外の判断、エスカレーションの判断、社外への報告 | 費用。そして夜間の集中力を保つための交代体制が必須になること |
実務では、検知は無人、判断と実行は有人、という組み合わせが普通です。実在の事業者の公開情報を見ても、24時間365日の有人監視をうたうサービスは、外形監視と内部監視(公開URL・プロセス・リソースの稼働状況)を有人体制で行い、検知後の作業着手を「30分以内」といった目標に置いています(2026年9月21日に当該事業者の公開サービス仕様で再確認)。監視が有人かどうかより、検知した後に誰がいつ動くかのほうが重要です。
オンコールとシフトの違い(表)——待機して起きるのか、起きている人がいるのか
夜間に人が動く形は、大きく2つです。
方式 | 体制 | 反応の速さ | 人への負担 | 向く条件 |
|---|---|---|---|---|
オンコール(待機) | 担当者が自宅などで待機し、アラートで呼び出されて対応する。普段は寝ている | 起床・接続の時間が加わる。数分〜数十分 | 呼び出し頻度が低ければ成立する。頻度が上がると疲弊する | 夜間の障害がまれで、10〜30分の遅れを許容できる |
シフト(常時在席) | 夜勤者が起きて常駐している。交代制で24時間を埋める | 即座に着手できる | 深夜勤務が常態化する。人数と労務管理の負荷が大きい | 停止が直ちに売上・人命・法令に響き、分単位の着手が要る |
オンコールを選ぶ場合、呼び出しの頻度が体制の成否を決めます。Googleが公開しているSRE Bookでは、オンコール担当者の負荷について「12時間のオンコールシフトあたりインシデントは最大2件」という上限を示し、その理由を「1件のインシデント対応に平均6時間かかるため」と説明しています。また、SREが業務時間のうちオンコールに充てる割合は25%を超えないこととされています。呼び出しが多い夜間体制は、続きません。
必要な人数の目安——法定労働時間から計算すると下限4.2人、実務基準では8人
「24時間365日をカバーするのに何人必要か」は、算数で下限が出ます。
計算項目 | 値 | 根拠 |
|---|---|---|
1年間にカバーする時間 | 8,760時間 | 24時間×365日 |
1人が1年間に働ける法定労働時間 | 約2,085時間 | 法定労働時間は1日8時間・週40時間(厚生労働省)。40時間×52.14週 |
1ポジションあたりの必要人数(下限) | 約4.2人 | 8,760÷2,085 |
実務上の目安 | 8人(単一拠点) | Google SRE Bookは「単一拠点のチームでオンコールに必要な最小人数は8人」としている。複数拠点で時差を使う場合は各拠点6人 |
4.2人というのは、有給休暇も、研修も、引き継ぎの重なりも、急な欠員も一切考えない数字です。実際にはそこに休暇と交代の余裕を足す必要があり、Google SRE Bookが示す8人という数字のほうが、体制として現実的な目安になります。しかもこれは「1ポジション」あたりです。監視を見る人と、実際にサーバーを触れる技術者を分けるなら、その両方に人数が要ります。
自社で24/365を作るという話が、なぜ「まず無理」という結論になりやすいのか。答えは単純で、既存の情シス担当2〜3名では、そもそも24時間を法令の範囲内で埋められないからです。あなたの会社で、夜間に呼び出される人を8人分用意できるでしょうか。できないとしたら、外部に頼むか、24/365そのものを見直すかの二択になります。
費用が跳ね上がる理由と、自社に24/365が本当に要るかを判断する5つの問い
見積もりを見て「なぜこんなに高いのか」と感じたなら、その理由は分解できます。そして分解できれば、削ってよい部分と削ってはいけない部分が分かれます。ここでは費用が上がる構造を4つに分け、そのうえで自社に24/365が要るかを判断する5つの問いを示します。
跳ね上がるのは「人が起きる」段階から——割増賃金・交代人数・二重化・手順書
前章の3段階でいうと、①(監視だけ)から②(一次対応まで)に移るところで費用の性質が変わります。①はツールとサーバーの費用で、使う量に応じて増える程度です。②と③は人件費で、次の4つが積み上がります。
要因 | 何が起きるか | 根拠 |
|---|---|---|
1. 深夜・休日の割増賃金 | 深夜(午後10時〜午前5時)は25%以上、法定休日の労働は35%以上の割増賃金が必要。時間外かつ深夜なら50%以上、休日かつ深夜なら60%以上になる | 労働基準法に基づく割増率(厚生労働省) |
2. 交代人数 | 1ポジションを24時間365日埋めるだけで下限4.2人、実務目安で8人。人数が増えれば、待機しているだけの時間にも費用が発生する | 法定労働時間からの計算、Google SRE Book |
3. 二重化(バックアップ要員) | 1人が対応できない事態(病欠、同時多発、対応の長期化)に備え、第2待機を置く。交代人数がさらに増える | オンコール運用の一般的な構成 |
4. 手順書と教育 | 夜間に判断を誤らせないため、作業手順、連絡経路、権限、エスカレーション基準を文書化し、定期的に訓練する。これは初期費用でも月額でもコストになる | 一次対応を「手順の実行」に落とす必要があるため |
つまり、24/365の費用は「人数×単価」だけでなく、「割増率」「待機時間の対価」「訓練の維持費」が乗った形になります。逆に言えば、夜間に人が動かなくてよいなら、この4つはすべて不要です。ここが判断の分かれ目になります。
公開情報で確認できた実額と、確認できなかったこと
費用については、出典を示せるものだけを書きます。
確認できたのは、実在の事業者が自社サイトで公開している料金です。24時間365日の有人監視を明記しているあるサービスは、1ドメインあたり月額33,000円(税込)から、2ドメイン目以降は1ドメインあたり月額11,000円(税込)からと公開しています。別の事業者の定額プランは、初期費用10,000円から、月額10,000円から(最下位プラン)〜40,000円から(上位プラン)と公開しています(いずれも2026年9月16日確認)。これらはいずれも監視にとどまらず、前者は原因の調査・報告と復旧作業まで、後者は障害1次対応(OS／サービスの再起動)までを公開仕様に明記しています(2026年9月21日再確認)。
一方、「24/365保守の費用相場は月額◯万円」といった業界横断の相場は、一次情報としては確認できませんでした。 検索上位に出てくる金額の多くは運用会社のコラムが独自に示した試算で、元になった調査や統計にはたどり着けません。本記事では、根拠を示せない相場観は書かないことにします。自社の見積もりを評価したいときは、相場と比べるのではなく、前掲の4要因のどれが含まれているかを見積書の内訳で確認してください。なお、保守や改修そのものの費用の見方は「システム改修 保守 外注」の記事で扱っています。
稼働率(99.9%など)の数値が何時間の停止に相当するかという換算も、判断材料としてよく使われます。これは「サーバー障害 原因 対応」の記事で時間換算の表とあわせて整理しているので、SLAの数値を評価する段階になったらそちらを参照してください。
自社に24/365が要るかを判断する5つの問い(チェックリスト)
次の5つに答えてください。3つ以上が「はい」なら②または③を検討する価値があります。0〜1つなら、次章の代替で足ります。
No | 問い | 「はい」が意味すること |
|---|---|---|
1 | 深夜・早朝にシステムが止まったとき、売上・人命・法令順守のいずれかに直ちに影響が出るか | 止まっている時間そのものが損失。②以上が必要 |
2 | 夜間・休日にも実際に利用者がいるか(アクセスログで確認したか) | 印象ではなくログで確認する。夜間アクセスが実質ゼロなら①で足りる |
3 | 1時間の停止で失う金額を計算できるか。それは夜間体制の月額を上回るか | 上回らないなら、費用対効果が成立しない |
4 | 夜間に動いてもらう作業を、手順として書き出せるか | 書き出せないなら、夜中に人を起こしても判断できず、朝まで待つのと変わらない |
5 | 自動復旧や縮退運転で代替できない障害か | 代替できるなら、人ではなく設計に投資したほうが安く確実 |
実務では、問い2と問い4で止まるケースが多いというのが実感です。夜間アクセスを調べたら1時間あたり数件だった、あるいは夜間の手順が書けず「気づいたら連絡してほしい」以上のことが決まっていない。その状態で③の契約を結んでも、支払う金額に見合う効果は出ません。まず①(監視だけ24時間)から始め、夜間に本当に事故が起きるのか、起きたとき手順で対処できるのかを半年ほど記録してから②へ上げる、という順番を勧めています。
24/365が要らないときの代替3つと、当社が提供できる範囲——提供していないことも書きます
前章の5つの問いで「要らない」と判断できたなら、夜間を空白にするのではなく、代替を組み合わせて埋めます。ここでは代替3つを整理し、最後に当社が提供できる範囲と提供していないことを、率直に書きます。
代替3つ(表)——平日日中+緊急連絡網 / クラウドの自動復旧 / 縮退運転
代替手段 | 中身 | 効くケース | 限界 |
|---|---|---|---|
1. 平日日中+緊急連絡網 | 保守は営業時間内。夜間はアラートを責任者の携帯に飛ばし、「連絡する人」「判断する人」「作業できる人」と連絡手段だけを事前に決めておく。作業は原則翌営業日 | 夜間利用が少ない業務システム、社内システム | 実際に人が動くかは属人的。連絡先と権限を最新に保つ運用が要る |
2. クラウドの自動復旧 | 仮想サーバーやコンテナの異常を自動検知し、別のホストへ移動または再作成する。ロードバランサのヘルスチェックで異常なノードを自動的に切り離す | ハードウェア障害、単一ノードの異常、突発的な負荷 | 万能ではない。AWSのインスタンス自動復旧は、システムステータスチェックの失敗が対象で、インスタンスステータスチェックのみの失敗では動作しない。メモリ上のデータは失われる |
3. 縮退運転 | 重い機能や周辺機能を落とし、中核機能だけを生かして動かし続ける。あらかじめ「落としてよい順番」を決めておく | 一部の機能障害、負荷の急増、外部APIの停止 | 設計時に組み込む必要がある。後付けは難しい |
3つ目の縮退運転は、思いつきの回避策ではなく、非機能要件として定義される項目です。IPAの非機能要求グレードにも、性能・拡張性のカテゴリに「縮退時レスポンス」「縮退時処理時間」という要求項目があり、通常時・ピーク時・縮退運転時のそれぞれで目標値を決める前提になっています。クラウドの仕組みそのものについては「クラウドとは」の記事で整理しています。
この3つは、どれも「人を夜中に起こさずに、停止時間を短くする」ための手段です。②や③の人件費と比べれば、はるかに安く済みます。まず設計で減らし、それでも残るリスクにだけ人を当てる。これが費用対効果の高い順番です。
当社の立場——24時間365日のオンコール体制は標準では提供していません
ここは率直に書きます。当社は、24時間365日のオンコール体制を標準では提供していません。 深夜・早朝に人を起こして即時に復旧することが事業要件であれば、その体制を持つ運用専門の会社を選んでください。この記事の3段階でいえば、当社が標準で担えるのは①と、営業時間内での②までです。
当社が提供できるのは次の範囲です。日本人PMまたはブリッジSEをフロントに置いたベトナムの専属チームで、新規開発だけでなくリリース後の継続的な保守運用を担当します。たとえば決済アプリの案件では、Stripeを使った決済、二要素認証、ウォレット、帳票のPDF出力までを新規開発し、リリース後は週次の保守運用へ移行しました。介護記録SaaS「CareViewer」では、日本語のブリッジSE1名とフルスタックエンジニア2名の体制で、週次の優先順位の判断を挟みながら開発と改善を継続しています。品質は人ではなく仕組みで担保する方針で、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックを型にしており、インフラ面ではAWS認定11冠のメンバーが在籍しています。
体制面では、ベトナムと日本の時差は2時間で、ホーチミンの営業時間は日本の営業時間とほぼ重なります。日中の障害連絡に当日中に反応できるのは、この時差のおかげです。人財は2,000名以上のIT人財データベースから直接アサインするため、協力会社を経由する仲介マージンは発生しません。1名から契約でき、最短2週間で開始、増員は約1週間、縮小と交代は1か月単位で調整できます。公開単価は実務3年目安で1,500USD(約22.5万円、1USD=150円換算目安)、ブリッジSEで3,000USDです。なお、ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)で、2026年のテト(旧正月)は2月14日から22日にあたります。この期間の対応体制は契約時に決めておく必要があります。
向く案件は、営業時間帯の保守運用で足りるサービス、監視の設計と設定を任せたい案件、障害後の原因究明と再発防止を作り込みながら継続的に改修していきたい案件です。向かない案件は、深夜・早朝の即時復旧が契約要件になっているサービス、医療や金融など停止が直ちに人命や資産に及ぶ領域です。合わないと判断した場合は、その旨を率直にお伝えしています。持っていない体制を持っているように書くほうが、結果として双方の損になるからです。
24/365に関するよくある質問
最後に、保守運用の相談でよく受ける質問を5つまとめます。いずれも、ここまでに書いた「稼働と有人対応は別」「人が動く側は3段階」という前提で答えています。
Q1. 24/365と24/7は違うものですか
同じものを指します。24/7は「24 hours a day, 7 days a week」の略で、英語の資料で使われます。24/365は「24時間365日」の日本語圏での言い方です。実際、AWSのサポートプラン紹介ページは英語版で「24/7」、日本語版で「年中無休」と表記しており、同じ内容を言い換えているだけです。どちらの表記でも、何を24時間やるのかは別途確認してください。
Q2. 契約書に24/365と書いてあれば、夜中に障害が起きても直してもらえますか
そうとは限りません。多くの契約は、24時間の監視と通知、あるいは決められた手順の一次対応までを約束していて、復旧そのものの時間は約束していません。受付時間と作業時間が分けて書かれていないか、約束されているのが初回応答か復旧か、一次対応の範囲が列挙されているか、エスカレーション先が夜間も稼働しているかの4点を確認してください。
Q3. 無人監視(自動監視)だけでは不十分ですか
夜間に人が動く必要がないなら、無人監視で足ります。検知そのものは機械のほうが速く正確です。不十分になるのは、検知した後に誰も動かず、朝まで止まったままになる場合です。逆に言えば、自動復旧や縮退運転で自動的に回復できる障害なら、無人監視のままでも停止時間は短く抑えられます。
Q4. 自社で24時間365日の体制を作るには何人必要ですか
1ポジションを埋めるだけでも、法定労働時間(1日8時間・週40時間)から計算して下限で約4.2人です。休暇・研修・引き継ぎを含めた実務上の目安として、Google SRE Bookは単一拠点なら8人、複数拠点で時差を使うなら各拠点6人としています。監視担当と実作業担当を分けるなら、その両方に人数が必要です。情シスが2〜3名の会社で内製するのは、法令の面からも現実的ではありません。
Q5. いったん24/365で契約したら、あとから縮小できますか
契約条件次第ですが、段階を下げる見直しは実務上よくあります。夜間のアラート件数と実際に人が動いた件数を半年ほど記録し、②が本当に使われているかを確認したうえで更新時に交渉するのが現実的です。当社の場合、開発チームの体制は縮小・交代とも1か月単位で調整でき、増員は約1週間が目安。ただし24時間365日のオンコールは、そもそも標準の提供範囲外です。
まとめ: 24/365は「24時間365日」——買うのは稼働ではなく、人が動く時間帯
24/365は24時間365日の略記で、英語圏の24/7と同じものを指します。表記のゆれ(24365、24H365D)に意味の差はありません。重要なのは、その4文字が「何を24時間やるのか」までは決めていないことです。システムが24時間動いていること(設計の話)と、24時間人が対応すること(体制の話)は別物で、IPAの非機能要求グレード2018でも「運用時間」と「対応可能時間」は別々の要求項目として定義されています。
人が関わる側は3段階です。①監視だけ24時間(検知と通知)、②一次対応まで24時間(手順にある作業の実施)、③復旧まで24時間(原因除去まで人が動く)。提案書の「24/365対応」がどれなのかは、受付時間と作業時間が分けて書かれていないか、約束が初回応答か復旧か、一次対応の範囲が列挙されているか、エスカレーション先が夜間も稼働しているか、の4点で読み分けてください。費用が跳ね上がるのは②以降で、深夜25%以上・法定休日35%以上の割増賃金、1ポジションあたり下限4.2人(実務目安8人)の交代人数、第2待機、手順書と訓練が積み上がるためです。業界横断の相場は公開情報からは確認できませんでした。見積もりは相場と比べるのではなく、この4要因が含まれているかを内訳で確認してください。
自社に24/365が要るかは、5つの問い(夜間停止の実害 / 夜間アクセスの実績 / 1時間の損失額 / 夜間手順を書けるか / 自動復旧や縮退で代替できるか)で判断できます。要らないなら、平日日中+緊急連絡網、クラウドの自動復旧、縮退運転の3つで夜間を埋めるほうが安く確実です。なお当社は、24時間365日のオンコール体制を標準では提供していません。深夜の即時復旧が事業要件なら、その体制を持つ運用専門の会社を選ぶべきです。当社が担えるのは、時差2時間で日本の営業時間と重なる時間帯での保守運用、監視の設計と設定、原因究明と再発防止、そして継続的な改修です。障害が起きた後の手順はサーバー障害の原因と対応、保守や改修を外部に頼むときの費用と頼み先はシステム改修・開発保守の外注もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、保守運用を外部チームで持つ場合の体制と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。