サーバー監視費用の内訳｜自動監視と有人対応は何が違うのか

サーバー監視の費用が妥当かどうかを確かめようとすると、たいてい最初の一歩でつまずきます。見積書に書かれているのが「サーバー監視費　月額◯万円」の一行だけで、その金額が何の対価なのかが書かれていないからです。ベンダーに聞けば「24時間365日、しっかり監視しています」と返ってくる。しかしその一文からは、夜中に異常が出たときに人が起きるのか、それとも翌朝の営業開始まで誰も見ないのかが分かりません。

この記事は、その一行を分解するための手順書です。監視費用の全国相場を1つ提示することはしません。「監視しています」という言葉を4つの作業に割り、そのうちどれを買っているのかを見積書と契約書から特定するところまでを扱います。

TL;DR｜「監視しています」は4つの別々の作業の総称

• 監視は検知（ツールが測る）／通知（ツールが発報する）／判断（人が見て切り分ける）／対応（人が手を動かす）の4段に分かれます。見積書の「監視費」がこの4段のどこまでを含むかで、必要な人員体制がまるで変わります
• 費用構造の核心は、価格が公開されている段と公開されていない段があることです。 監視ツールの料金は各社が公式サイトで単価まで公開しています。一方、夜間に人を待機させる費用の公式価格表は、まとまった形ではほとんど公開されていません
• そのため本記事では、③④（本記事ではこれを「有人対応」と呼びます）の相場レンジを提示しません。 複数社の公式価格をそろえられていない以上、数字を出すこと自体が推測になります。代わりに、金額ではなく体制を確認するための質問を用意しました
• 「24時間365日」は、それ単体では費用が決まらない言葉です。 契約書で確かめるべきは受付・一次対応・復旧作業の3語で、どれが24時間なのかによって必要な人員数が変わります。IPAが公開している非機能要求の項目一覧でも、システムの稼働時間と人の対応時間は別々の項目として分かれています
• 公開されている例で桁の差を見ると分かりやすくなります。AWSのサポートプランでは、24時間365日つながり30分未満の応答目標が付くことの最低額と、応答目標を15分へ縮めて専任担当を付けることの最低額が、公式ドキュメント上で大きく離れた金額として提示されています（後述）
• サーバー台数への比例は、それ自体は不合理ではありません。 ただし比例が妥当なのは監視の範囲や一次対応（＝最初の切り分けと初動。次章の用語表で開きます）が台数分だけ増える場合で、同じ構成のサーバーを共通基盤へ相乗りさせる場合は増え方が違います。見積書に「何に比例しているか」が書かれているかを見てください
• 高い監視費用より危険なのは、安いのに検知後の行動が定義されていない見積書です。アラートが鳴ったあと誰も動かない体制は、監視していないのとほぼ同じ結果になります

金額の妥当性そのものを検証したい場合は、先にシステム保守費用の相場と妥当性の検証手順を読んでから戻ってくると、本記事の分解結果を金額へ結びつけやすくなります。

「監視」を4段に分ける｜検知・通知・判断・対応

監視という言葉が費用の話でこじれるのは、まったく性質の違う4つの作業が1語にまとめられているからです。まずこの4段を分けます。

一般には③④をまとめて「有人監視」と呼びます。ただし後述のとおり、公的な整理では「監視」という語が指しているのは②までです。混同を避けるため、本記事では③④を「有人対応」と呼び、①②を「自動監視」と呼びます。市場でよく使われる「有人監視」という語は、他社の表現を引くときだけ使います。

この記事で繰り返し出てくる語を、先に開いておきます。

①検知｜ツールが測る

サーバーが生きているか（死活）、CPUやメモリがどれだけ使われているか（リソース）、エラーログが出ていないか、応答時間が遅くなっていないか。こうした情報を一定間隔で収集する段です。ここは完全に自動化されていて、人件費はほぼ発生しません。

どこまで測るかには段階があります。独立行政法人情報処理推進機構（IPA）が公開している「非機能要求グレード2018 システム基盤の非機能要求に関する項目一覧」（2018年4月、独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター発行）では、「監視情報」という指標のレベルが0から5まで定義されています。

死活監視だけの契約と、パフォーマンス監視まで含む契約では、設定作業も、鳴るアラートの量も、鳴ったときに読む情報の量も違います。「監視あり」とだけ書かれた見積書は、この0から5のどこにいるかを示していません。

②通知｜ツールが発報する

閾値を超えたときに、メール・チャット・電話へ自動発報する段です。これも自動化されており、①の料金に含まれているのが一般的です。

ここで押さえておきたいのは、前掲のIPAの項目一覧が「監視」という語をどう定義しているかです。同資料は運用監視の項目の備考で、監視とは情報収集を行った結果に応じて適切な宛先に発報することを意味する、と書いています。公的な整理でも、「監視」という語が指しているのは②の発報までです。 発報を受けて誰がどう動くかは、同じ資料の別の項目（後述するC.3.3「システム異常検知時の対応」やC.5.6「サポート要員」）で改めて決める設計になっています。

「監視しています」と「障害に対応します」が別の話である、というのは、ベンダー側の言い逃れではなく、要求定義の標準的な整理でもそうなっている、ということです。

③判断｜人が見て切り分ける

発報が来たあと、それが本物の障害なのか、一時的なスパイクなのか、監視設定の誤りなのかを人が切り分ける段です。ここから先が人件費です。

この段の費用を決めるのは作業量ではありません。「その時間帯に、判断できる人が起きていること」そのものが費用です。深夜3時に発報が来る可能性がある契約では、深夜3時に応答できる人を確保しておかなければならず、実際にはアラートが1件も鳴らなかった月でも費用は発生します。

④対応｜人が手を動かす

ログを取得する、プロセスを再起動する、切り戻す、原因を特定する、報告書を書く。ここは作業時間に比例します。

④は、さらにどこまでやるかで分かれます。切り分けまでなのか、再起動などの復旧操作までなのか、原因究明と報告書の作成まで含むのか。そして「連絡がつく時間帯」と「実際に手を動かす時間帯」は別物です。この点は、後述の「24時間365日」の節で公的な整理とあわせて扱います。

価格が公開されているのは①②だけ、という非対称

ここが監視費用の見積書がわかりにくい最大の理由です。前掲の表の右端の列がそれで、①②のツール費はホスト1台あたりいくら・メトリック1つあたりいくらまで公式料金ページに書かれている一方、「夜間に1人待機させる場合の月額」を公式料金表として掲載している事業者は、まとまった形ではほとんど見当たりません。

見積書に「監視費　月額◯万円」と1行で書かれているとき、この金額のうち何割が公開価格のある①②で、何割が公開価格のない③④なのかは、書かれていなければ分かりません。そして分からないままでは、比較も交渉も成立しません。

本記事がこのあと扱うのは、この1行を①②側と③④側に割り、それぞれ別の方法で確認していく手順です。

見積書では、この4段がどう1行に潰れているか

実際の保守見積書で見かける書かれ方と、そこから決まらないことを並べます。

このうち、もっとも危険なのは「監視含む」と括弧書きされているパターンです。監視の金額が独立していないため、監視の範囲を変えても金額が動かせず、他社と比較することもできません。

「これは保守に含まれるのか、別料金なのか」で揉めている場合は、金額より先に契約書の別紙を確認したほうが早いことがあります。判定手順は保守契約の範囲を4状態で判定する方法にまとめています。

ツール側の費用は「台数×メトリック数」で決まる｜公開価格で確認する

①②のツール費は、公式価格が公開されています。ここは自分で概算できます。

以下は2026年8月19日に各社の公式料金ページで確認した内容です。通貨・税区分・契約期間が事業者ごとに違うため、金額の大小をそのまま比べないでください。 揃っていないものを揃っているように書かないことが、この表の目的です。

出典はMackerel 料金ページおよびDatadog 価格設定ページ。いずれも2026年8月19日取得。Mackerelの価格体系は2024年10月1日付の公式告知のとおり2024年11月1日利用分から変更されており（スタンダードホストが1,833円から2,180円へ、税込。「メトリック」単位と最低利用料金を新設）、上表は変更後の現行表示です。Datadogの金額は各プランの「最小価格」として表示されているもので、機能追加により上振れします。

自分のサーバー台数で概算してみる

各社の公開単価から、10台構成のツール費だけを月額換算すると次のようになります。

この概算は前提を置いた計算であり、実際の請求額を保証するものではありません。それでも、手元の見積書の監視費を仮に月額15万円と置いたときに、そのうちツール費部分がどのくらいの規模なのかを掴むには十分です。差額が大きい場合、それは不当な上乗せとは限らず、③④の人の費用が入っている可能性が高い、というだけのことです。差額の正体を聞くための材料として使ってください。

台数だけを見ると外す｜メトリック数という第2の軸

Mackerelの料金体系が分かりやすい例になっています。同社の公開価格にはホスト単価とは別にメトリック単価（1メトリックあたり11円・税込）があり、スタンダードホスト1台あたりホストメトリックは200メトリックまで含む、と明記されています（マイクロホストは30メトリックまで）。ホストに紐づかないサービスメトリックなどはこの含有枠の対象外です。

つまりツール費は、台数だけでは決まりません。

• 台数は同じでも、1台あたりのメトリックを増やせば費用は増える
• 台数が倍でも、取るメトリックが死活監視の分だけなら費用の増え方は小さい

見積書が「サーバー台数×単価」だけで書かれている場合、その単価に何メトリック分が含まれているのかを聞く価値があります。含有枠を超えた分がどう課金されるかが決まっていないと、監視を手厚くした翌月に請求が跳ねる、という事故が起きます。

なお、ここでいう「メトリック」はツール側の課金単位です。後半で扱う「監視の範囲」は、契約側でどこまでを見る約束にするかの話で、両者は必ずしも一致しません。課金単位に余裕があっても、契約で見る約束になっていなければ、その項目は監視されません。

ツール提供元のサポートは、たいてい24時間ではない

見落としやすい点をひとつ。監視ツールを導入することと、24時間誰かが見ていることは別です。

Mackerelの料金ページのよくあるご質問では、テクニカルサポート（メールのみ）の対応時間は同社の営業日の10:00〜19:00である、と記載されています（2026年8月19日取得）。監視ツール自体は24時間動きますが、そのツールのベンダーに問い合わせて人が答えるのは営業時間内ということです。

これはMackerelが不十分だという話ではまったくありません。ツールはツールとして正しく動いています。ここで確認したいのは、「24時間監視ツールを入れています」というベンダーの説明が、24時間人が対応することを意味しないという一点です。

人側の費用を決めるのは、台数ではなく「待機の形」

③④の費用は、サーバーが何台あるかではほとんど決まりません。決めるのは、どういう形で人を待たせているかです。

前掲のIPAの項目一覧は、サポート体制の中に「エスカレーション対応」という指標を置き、そのレベルを次の4段階で定義しています。

適用範囲に注意してください。同資料はこの指標を、障害発生時にエスカレーション対応が必要となるISV/IHV製品について、エスカレーション先の有識者の待機方法を確認するもの、と説明しています。本記事はこれを待機形態の分類として借りているのであって、監視要員一般の水準として原典が定めているわけではありません。右端の列も原典にはない本記事の補足です。

同じ資料は「ベンダ側常備配置人数」も、常駐しない／1人／複数人の3段階で分けています。さらに「駆けつけ到着時間」は、駆けつけ無し／数日中／ユーザの翌営業日中／ユーザの翌営業開始時まで／数時間内／保守員が常駐、の6段階です。

サーバーが1台でも10台でも、深夜に電話を取れる人を1人確保するコストは変わりません。 逆に、オンコール待機を現地待機に変えれば、サーバー台数が同じでも費用は大きく変わります。監視費用が「台数×単価」だけで組まれている見積書は、この軸を持っていないということです。

なお、これらのレベル値は要求水準を段階的に示したものであって、IPAが推奨値として示しているものではありません。自社がどのレベルであるべきかは、システムが止まったときの業務影響から決めてください。

なぜこの記事は有人対応の相場を出さないのか

ここで金額の目安を出したくなるところですが、出しません。理由を明示しておきます。

「有人監視は月額◯万円から」といった数字は多くの記事で見かけますが、そのほとんどは監視代行を提供している事業者自身が自社ブログに書いた目安であって、公式料金表ではありません。同じ税区分・同じ対応時間帯・同じ一次対応範囲で正規化された複数社の公開価格をそろえられていない段階でレンジを書けば、それは調査結果ではなく推測です。

代わりに使えるのが、金額ではなく体制を聞くやり方です。待機形態・配置人数・到着時間の3つが決まれば、金額の妥当性はベンダー間で比較できるようになります。この記事の後半に載せた確認質問は、そのために作っています。

「24時間365日」という表記の中身

見積書と提案書でもっとも頻繁に出てきて、もっとも意味が決まっていない言葉がこれです。

「24時間365日」は稼働・受付・監視・対応のどれを指しているか

この4つは、同じ「24時間365日」という言葉で書かれていても、コストの桁が違います。受付だけ24時間なら、夜間に連絡はつくが誰も作業を始めない、という状態がありえます。

このうちシステムの稼働時間は構築側の設計、監視はツール側の設定の話です。保守費用の交渉で時間帯を確定させるべきなのは、残る受付・一次対応・復旧作業の3つになります。以降はこの3語で進めます。

公的な整理でも、これは別の項目として分かれている

前掲のIPA「非機能要求グレード2018 項目一覧」を見ると、この区別が別々の項目として設計されていることが確認できます。

右端の列は本記事による対応づけで、原典が定めた分類ではありません。C.1.1.1 と C.3.3.1 は備考に「システムが稼動している時間帯」「保守員が作業対応を行う時間帯」と書かれているので迷いませんが、C.5.6.2 には備考がなく、その「対応」が受付までなのか復旧作業まで含むのかを原典は書いていません。だからこそ、契約書では自分で聞き分ける必要があります。

同資料は「運用時間」について、これはオンライン／バッチを含みシステムが稼動している時間帯を指す、と説明しています。つまり運用時間の「24時間」は、システムが動いている時間の話であって、人が対応する時間の話ではありません。

一方でC.3.3.1とC.5.6.2は、どちらも人側の時間帯を扱いますが、C.3.3.1の備考は「システムの異常検知時に保守員が作業対応を行う時間帯」と書いており、作業まで踏み込んでいます。ここが、④対応の節で保留にした「連絡がつく時間帯」と「実際に手を動かす時間帯」の違いです。

見積書に「24時間365日」と一度しか書かれていない場合、それが運用時間・対応可能時間・ベンダ側対応時間帯のどれを指しているかは決まりません。確認するときは「24時間対応ですか」ではなく、受付・一次対応・復旧作業の3つについて、それぞれ何時から何時までかを答えてもらってください。

公開されている例で、桁の違いを見る

日本の受託保守ベンダーの公式価格表はほとんど公開されていませんが、クラウド事業者が自社サービスに提供するサポートは公開されています。構造の例として見ておく価値があります。

AWSの「AWS Support Plans」ユーザーガイド（2026年8月19日取得）には、次のように書かれています。

• AWS Business Support+：クラウドサポートエンジニアへ電話・ウェブ・チャットで24時間365日アクセスできる。ビジネスクリティカルなシステム停止のケースでは30分未満で人が対応にあたる。最低額は1アカウントあたり月29 USD
• AWS Enterprise Support：専任のTechnical Account Manager（TAM）が付き、本番稼働に影響するケースへの応答は最大15分。最低額は5,000 USD

どちらも24時間365日つながる点は同じで、応答目標も両方に付いています。差はその目標をどこまで縮め、誰を専任で付けるかです。30分未満の応答目標なら月29 USDから、15分以内へ縮めて専任担当を付けると最低5,000 USD。いずれも「最低額（minimum）」として書かれているので、実際の請求はこれ以上になりえます。

そして重要なのが限定表現です。日本語のAWS サポートプランの比較ページ（2026年8月19日取得）で、この時間が並んでいる行の見出しは「人による応答時間」であり、注記には、最初のリクエストに対応する時間内に応答するよう合理的な範囲でできる限りの努力を払う、と書かれています。復旧までの時間ではなく、応答の努力目標です。

同ページではさらに、技術サポートの行とは別に「プロアクティブな監視／年中無休のワークロードのモニタリング」という行が置かれ、AWS Managed ServicesやAWS Incident Detection and Responseは「追加料金でご利用いただけます」と記載されています。受付・監視・踏み込んだ対応が別々の行として値付けされている、という構造がそのまま読み取れます。

なお、この金額は日本の運用保守の相場ではありません。クラウド事業者が自社サービスについて提供するサポートの価格であり、他社が構築したシステムの障害対応とは対象が違います。ここで持ち帰るのは金額ではなく、「同じ24時間でも売り物が3種類ある」という構造だけにしてください。

契約書で確認する3つの語｜受付・一次対応・復旧作業

契約書や業務仕様書を開いたら、次の3語を探してください。3つとも見つからないなら、24時間365日の中身は契約上決まっていません。

とくに一次対応は、誰がやるかが契約で分かれます。IPAの項目一覧も「一次対応役割分担」という小項目を置き、全てユーザが実施／一部ユーザが実施／全てベンダが実施の3段階で分けたうえで、この小項目では一次対応の役割分担・対応時間・配備人数を決める、と説明しています。「一次対応は含まれます」だけでは、その3つのうち1つしか決まっていません。

一次応答時間と復旧目標時間の数字そのものの読み方、たとえば「1時間以内」が何から何までの1時間なのかは、本記事の範囲外です。本記事で扱うのは監視の中身と費用構造であり、SLAに書かれた数字の定義そのものではありません。数字の定義のほうは「システム保守のSLAと費用」で扱っています。見積書に並ぶ保守項目の読み解き方は「システム保守の見積もりチェックリスト」を参照してください。

夜間・休日の追加費用はどこに書かれるか

24時間365日を謳っていても、夜間・休日の作業に割増料金が発生する契約は珍しくありません。これ自体は不当ではなく、割増があること自体より、割増の条件が事前に書かれているかどうかが判断材料です。

確認すべきは次の5点です。

1. 割増の対象時間帯：何時から何時までが夜間か。土日祝は別扱いか。年末年始はどうか
2. 割増率と最低課金単位：1.25倍・1.5倍などの率と、最低1時間から／最低4時間から、といった課金の下限
3. 月額に含まれる分と、含まれない分の境目：月額に夜間の待機費が含まれているのか、待機は含むが作業は別料金なのか
4. 誰の判断で割増作業が始まるか：ベンダーが自主判断で着手できるのか、発注側の承認が必要か。承認が必要なら、深夜に承認する人を自社側で決めておく必要があります
5. 割増作業の月次報告：実際に何時間発生したかが毎月報告されるか

3番目と4番目は特に見落とされます。深夜2時に承認を求められる相手が自社側で決まっていない契約は、24時間対応の契約であっても、実質的には朝まで動きません。

「サーバー台数に比例」は妥当か

「サーバー1台につき月額◯円」という料金体系をどう判断するか。ここでも先に結論を固定しないでください。台数比例が妥当なケースと、説明が足りないケースの両方があります。

台数比例の説明が付くケース

このうちライセンスやエージェントの実費は、そのまま実費として別行に出せるはずのものです。実費が保守費に溶けている場合は、内訳を求める根拠になります。クラウド利用料と運用保守費の分け方はAWSの実費・請求代行・運用保守を分解する方法で扱っています。

台数比例の説明が足りないケース

ここでも「比例するのはおかしい」と決めつけないでください。 問題は比例そのものではなく、何に比例しているのかが書かれていないことです。同じ「台数×単価」でも、中身がライセンス実費なら比例が正しく、待機費なら比例しないほうが自然です。

数量課金全般の見方はシステム保守費用の相場と妥当性の検証手順でも扱っています。

監視の「範囲」という、課金単位とは別の軸

台数の議論に抜けやすいのが、1台あたり何を監視する約束になっているかです。前掲のIPA「非機能要求グレード2018 項目一覧」は、運用監視という小項目のもとに9つの指標を置いています。

このうち1番目の「監視情報」が、記事の冒頭で挙げた0〜5のレベル表です。3〜9はいずれも、監視を行わない／一部監視を行う／全て監視を行う、の3段階で定義されています。「サーバー10台を監視」という同じ表現で、死活監視のみ一部対象と、9つすべてを全対象で監視するのとでは、設定作業も運用も費用も別物です。

とくに2番目の「監視間隔」は、レベルが監視を行わない／不定期監視（手動監視）／定期監視（1日間隔）／定期監視（数時間間隔）／リアルタイム監視（分間隔）／リアルタイム監視（秒間隔）の6段階で定義されています。「24時間監視」と書かれていても、監視間隔が1日間隔なら、深夜の障害に気づくのは翌日です。 24時間という語と監視間隔は、別々に確認してください。

冗長化構成では「1台増える」の意味が変わる

冗長化された構成では、サーバーが1台増えることの意味が単純な足し算ではなくなります。

• 冗長化していない構成：1台落ちればサービスが止まる。検知したら即座に復旧作業に入る。判断は比較的単純
• 冗長化した構成：1台落ちても縮退運転でサービスは続く。しかし「今は動いているが冗長性を失っている」という状態を検知し、次の1台が落ちる前に復旧させる判断が要る

後者のほうが、監視項目も判断の難易度も上がります。冗長化はシステムを止まりにくくしますが、運用の手間を減らすとは限りません。 冗長構成なのに監視費が非冗長時と同額の見積書は、安いのではなく、冗長性の監視が入っていない可能性があります。

台数課金の見積書に足りていない3行

台数比例の見積書を受け取ったら、次の3行が書かれているかを見てください。

1. 1台あたりの監視項目（何を、どの間隔で見るか）
2. アラート発生時に人が行う作業の範囲（切り分けまでか、復旧作業までか）
3. 台数に依存しない固定費（監視基盤、待機体制、報告作業）が別行になっているか

3が独立していれば、台数が増えたときの増分が正しく見積もられているかを検証できます。すべてが台数単価に溶けている場合、台数を減らしても費用があまり下がらないという結果になりがちです。

その料金体系が合理的といえる条件

ベンダー側の言い分が正当と言えるのは、次の条件を満たすときです。

下の2行が重要です。 高いことにも安いことにも理由がありえます。理由が説明できるなら、その見積もりは検証可能な見積もりです。

確認が必要なケース・高リスクのケース

判断は「妥当／不当」ではなく、説明済み／要確認／高リスク／判断不能の4状態で行います。監視の見積行を、この4状態に仕分けてください。

「判断不能」の行が3つ以上あるなら、金額の交渉に入る前に情報を揃えてください。 情報がないまま値下げ交渉をすると、下がるのはたいてい③④の人の待機時間帯です。それは費用ではなく体制を削る決定であり、経営判断として扱われるべきものです。

手元の見積書を実際に仕分けたい場合は、保守見積書の契約範囲チェック（登録不要）が使えます。見積書のテキストはブラウザ内で識別情報をマスクしたうえで診断にかけられ、結果を見るまでメールアドレスの入力は不要です。返ってくるのは「高い／安い」の判定ではなく、上表と同じく確認すべき項目とベンダーへの質問です。

「安い監視」のほうが危険な場合

見積書の検証というと高すぎないかを見がちですが、監視費用は安すぎるほうが危険な領域です。過小見積もりの典型を挙げます。

とくに2行目は頻出です。 「24時間365日監視」と書かれていて金額が安い場合、監視ツールが24時間動くだけで、発報の受け手が発注側になっていることがあります。契約上は間違っていませんが、自社で夜間の当番を組む必要があるという意味です。その工数は見積書には現れません。

ベンダーへそのまま送れる確認質問8問

以下はコピーしてそのまま送れる文面です。金額を聞く質問を意図的に入れていません。 体制が確定してから金額を比べるほうが、比較として成立します。

そのまま送れるメール文面

お世話になっております。
現在ご提示いただいている保守見積書のうち、監視・障害対応の項目について、
社内で費用の内訳を確認しております。
恐れ入りますが、下記8点について書面でご回答をお願いできますでしょうか。

1. 監視の対象項目と監視間隔を一覧でご提示ください。
   死活監視・エラー監視・リソース監視・パフォーマンス監視のどこまでを含み、
   それぞれ何分（何時間）間隔で取得しているかをお願いします。

2. 監視で異常を検知した後の流れを、時系列でご説明ください。
   どこへ発報され、誰が最初に確認し、何分以内に確認を開始するのかを
   お聞かせください。

3. 「24時間365日」と記載いただいている箇所について、
   （a）連絡の受付時間、（b）一次対応（切り分け・初動）を行う時間帯、
   （c）復旧作業に着手する時間帯、の3つを、それぞれ何時から何時かで
   お示しください。あわせて、システム自体の運用時間（稼働している時間帯）も
   ご記載ください。

4. 夜間・休日に作業が発生した場合の追加費用について、対象時間帯・割増率・
   最低課金単位・作業着手に弊社の承認が必要かどうかをご教示ください。

5. 一次対応の範囲を具体的にご定義ください。
   切り分けまでか、再起動等の復旧操作まで含むか、原因調査と報告書作成を
   含むかについて、含む／含まないでお示しください。

6. 月額のうち、監視ツールやライセンスなどの実費に相当する金額と、
   人の体制に相当する金額を分けてご提示ください。

7. サーバー台数に比例する費用について、台数が増えたときに実際に増える作業と、
   台数によらず発生する固定費をそれぞれお示しください。
   併せて、サーバーを1台減らした場合の減額幅もご教示ください。

8. 直近6か月のアラート発生件数と、そのうち貴社が対応した件数、
   夜間・休日に発生した件数の実績をご提示ください。

お手数をおかけしますが、よろしくお願いいたします。

回答をどう読むか

質問8に答えが返ってこない場合は、監視の運用実態を記録していない可能性があります。 これは金額の問題ではなく、月次報告の取り決めがない問題です。IPAの項目一覧も、定期報告会の頻度と報告内容のレベル（障害報告のみ／運用状況報告を含む／改善提案まで）を別々の指標として定義しています。契約更新のタイミングで、報告の頻度と内容を条項として追加する交渉材料になります。

質問6と7に対して「一体で算定しているため分けられない」という回答が続き、監視項目一覧や作業実績といった資料の提供も断られる場合は、価格の問題ではなく引き継ぎ可能性の問題として扱ったほうが早いことがあります。監視設定を他社が引き継げる状態にあるか、監視基盤の管理者権限を自社が持っているかを、金額とは別に確認してください。

根拠資料と適用条件

本記事で使用した資料と、その適用条件です。

本記事で提示していないもの、およびその理由です。

なお本記事は、法的・会計的な最終判断を提供するものではありません。契約解釈や税務上の取り扱いは、それぞれの専門家にご確認ください。

この記事を読んだあとに進む順番

1. 見積書の監視関連の行をすべて書き出す。「保守費（監視含む）」のように括弧書きになっているものも含めます
2. 各行を①検知②通知③判断④対応に割り振る。割り振れない行が「判断不能」です
3. ①②の概算を公開価格で出す。台数とメトリック数が分かれば、この記事の表で概算できます
4. ③④について、金額ではなく体制を聞く。上の8問をそのまま送れます
5. 回答が揃ってから、他社と比較する。体制が揃っていない見積書どうしを金額で比べても、比較になりません

途中で「これは保守契約に含まれるのか」という論点に当たったら保守契約の範囲を4状態で判定する方法へ、金額そのものの妥当性に当たったらシステム保守費用の相場と妥当性の検証手順へ進んでください。検証の結果、現行ベンダーの体制が業務内容に対して妥当だという結論になることも普通にあります。

よくある質問