システム保守の見積もりの見方｜月額一式を4区分に分解し、複数社を同条件でそろえる

システム保守の見積もりを受け取って最初に困るのは、金額の大きさではありません。その金額が何に対して払われるのかが、紙の上に書かれていないことです。「システム保守費　一式　月額35万円」。行はこれだけ。裏面にも内訳はない。この状態では、高いとも安いとも言えません。

この記事は、その1行を分解して読めるようにするための手順書です。相場や比率の話はしません（そちらはシステム保守費用の相場と妥当性の検証手順にまとめています）。ここで扱うのは、手元の見積書のどの行に何を書き足させ、複数社の見積もりをどうやって同じ土俵に載せるかです。

根拠には、公的機関が事業者へ示している保守見積もりの様式2件と、料金体系を公開しているクラウド3社の価格表を使います。いずれも民間の受託開発会社の保守相場を示すものではありません。使えるのは金額ではなく、きちんとした保守見積もりには何が書かれているのかという形のほうです。

TL;DR｜見るのは金額ではなく「1行が何を買っているか」

• 見積書の行項目名だけで確定することは、驚くほど少ない。「サーバー監視費」は監視という役務があることしか示さず、自動か有人か、検知後に誰が動くかは確定しない。確定しない部分が、そのままベンダーへの質問になる
• 保守の見積もりは、実費／人の作業／システムの作業／待機の4区分に割り振れて初めて判断できる。割り振れない行が残っているうちは、金額の議論に進めない
• 公的機関が事業者へ示している見積内訳様式のうち、三重県警のものは保守費を作業項目 × 職種 × 人月 × 単価まで、茨城県のものは区分 × 単価 × 数量まで分けさせている。本記事で確認した2件の様式では、月額一式で提出できる形になっていない
• 料金体系を公開しているクラウド3社の書き方を突き合わせると、最低額・課金のベース・対応時間帯・重大度別の応答目標・最低契約期間と更新条件の5要素が浮かぶ（最低契約期間はGoogle Cloudの当該ページでは確認できなかった）。手元の見積書にこの5つが揃っていなければ、足りないのは値引きではなく記載
• 相見積もりの結論は「A社が安い」ではない。同条件なら安い／条件が違うため比較不能／責任範囲が広いため高い可能性の3つに分かれる。ほとんどの初回比較は2つめになる
• 「安い」見積もりのほうが危険なこともある。復旧テスト、セキュリティ更新、依存ライブラリ・ミドルウェアの更新、ドキュメントの更新、改修時の回帰試験、月次の作業実績報告の6項目は、金額を下げるときに真っ先に落ちる
• 契約先と実際に作業する会社が違うこと自体は問題ではない。確認すべきは責任主体・情報の受け渡し範囲・障害時の指揮系統の3点

判断は「高い／安い」ではなく、説明済み／要確認／高リスク／判断不能の4状態で持ってください。値引き交渉より先に、判断不能の行を減らすほうが早く終わります。

保守の見積もりが、開発の見積もりより読みにくい3つの理由

同じ会社が出した開発の見積書は読めたのに、保守の見積書になると急に読めなくなる。これは読み手の力量の問題ではなく、書かれ方が構造的に違うからです。

理由1｜成果物がないので、金額の裏付けを成果物に求められない

開発の見積もりなら、要件定義書・設計書・テスト仕様書・納品されるプログラムというように、金額の向こう側に受け取るものがあります。「この設計書に80万円」という対応が成立します。

保守はそうなりません。1年間保守を受けても、手元に残るのは障害報告書と作業報告書くらいです。成果物で金額を検証できない以上、代わりに検証できるのは「どの時間帯に、どれだけの速さで、誰が動ける体制を維持しているか」だけになります。見積書がその3つを書いていなければ、検証の手がかりがゼロになります。

理由2｜他人への支払い（実費）と、自社への支払い（役務）が同じ月額に溶けている

クラウド利用料、ソフトウェアライセンス、回線費用、SSL証明書。これらはベンダーが立て替えて外部へ払っているお金で、ベンダー自身の働きに対する対価ではありません。

この2つが「保守費　月額35万円」に溶けていると、おかしなことが起きます。クラウドの利用料が下がっても保守費が下がらない。逆に、円安でクラウド料金が上がったときに、その分が誰の負担になるのかも決まらない。実費と役務は増減の理屈がまったく違うので、同じ行に入れてはいけません。

理由3｜「作業していない時間」にも正当な費用が発生する

これが保守特有の難しさです。障害が起きていない月でも、起きたときに30分で人が動ける状態を維持するには費用がかかります。この待機の対価は実在するコストであり、「今月は何もしていないのに同額なのはおかしい」という直感は、必ずしも正しくありません。

ただし、これはベンダー側にとって便利な説明でもあります。待機の対価が契約に明示されていて、対応時間帯と応答目標が数字で書かれている場合にだけ、この説明は成立します。 書かれていなければ、それは「何もしていない月の請求根拠」ではなく、単に内訳が無いだけです。

見積書の行項目名から、何が確定して何が確定しないか

まず、手元の見積書に書かれている項目名を、下の辞書に当ててみてください。左列がよくある書かれ方、中列がその文言だけで確定すること、右列が確定しないことです。右列がそのまま質問になります。 後掲の確認質問10問に入っていない項目は、10問に足して送ってください。

この表の使い方には順番があります。まず右列を潰し、そのあとで金額を見ます。 順番を逆にすると、「高いと思うので下げてほしい」という交渉になり、ベンダー側は範囲を狭めることで応じてしまいます。範囲が狭まったことに後から気づくのが、保守見積もりでいちばん多い事故です。

「一式」が1行でもあると、そこは動かせない

上の表で「何も確定しない」に当たる行があると、その行の金額は4状態のうち判断不能から動きません。

したがって最初にやることは金額の比較ではなく、判断不能の行を減らすことです。以降のセクションは、そのための手順になっています。

公的機関は、保守の見積もりをここまで分けさせている

「内訳を出してほしい」と依頼したとき、どの粒度まで求めてよいのかが分からないと、依頼そのものが曖昧になります。ここでは、実際に公的機関が事業者へ示している見積内訳の様式を2件見ます。どちらもWeb上で誰でも取得できます。

先に適用条件を書いておきます。 2件とも自治体・警察の情報システム調達で使われた様式です。5〜6年の長期契約、機器のリースやパッケージを含む大きめの案件が前提で、月額数十万円の中小規模システムの保守にそのまま当てはめるものではありません。それでも参考になるのは、発注側が正当に要求できる内訳の粒度が、実物として示されているからです。

茨城県の見積内訳書｜5つの大区分と、税区分・年度展開

茨城県が2024年（令和6年）2月9日に公告した「茨城県食品衛生及び環境衛生業務システム導入等業務のプロポーザルの公募に関する公告」（担当：茨城県保健医療部生活衛生課）の様式一覧には、「【様式4-6】見積内訳書」が用意されています。履行期間は契約締結の日から令和12年3月31日までです。

この様式は費用を次の5つの大区分に分けています。

見積合計額（税込）は【①】＋【②】＋【③】＋【④】＋【⑤】として算出させ、さらに末尾には【年度ごとの支出見込み】として、令和6年度から令和11年度までの6年度分を大区分ごとに書かせる欄があります。5つの費用表の列は「項番／項目／単価／数量／費用／備考」です。

読み取ってほしいのは3点です。

1. 一度きりの作業（1 導入等作業費）と、続く費用（2 サービス利用料・4 運用保守作業費）が最初から別の表に分かれている。 導入作業費と移行作業費が月額に混ざる余地がない
2. 区分ごとに税区分を書かせている。 区分1・4・5は税抜／消費税等額／税込の3段、区分3は月額リース料の税抜・消費税額・税込と60ヶ月分合計（税込）、区分2は消費税等額と税込の合計。総額の税込だけで済ませられない構造になっている
3. 「単価」と「数量」の列がある。 金額だけの記入は様式上できない

なお、この様式には注記があり、「以下の構成は、見積内訳を記載する上で一例として示すものである」「当該構成を参考とし、提供するシステムの内容に応じて適宜構成を改変の上、見積内訳を記載すること」「各項目については、必要に応じて細分化し、見積根拠について詳細に記載すること」とされています。固定の型ではなく、細分化する方向への改変を求める様式という性格です。

三重県警察の様式｜作業項目 × 職種 × 人月

もう1件は、三重県警察本部警務部広聴広報課が平成25年（2013年）7月12日付で出した「三重県警察行政文書管理システムの再構築に伴う新たな文書管理システム等にかかる情報提供依頼」の別添1にあたる見積書様式です。10年以上前の資料であり、金額の水準としては使えません。使えるのは分け方です。

この様式は様式0から様式4までの5シートで構成され（ほかにExcel既定の空シートが3枚含まれています）、うち【様式4】が「（明細）運用保守委託」にあたります。ここでは運用保守費を、作業項目（縦）× 職種（横）× 人月の行列で書かせています。

さらに右端には「見積根拠・明細資料名など」という列が置かれています。金額の隣に、その金額の出どころを書く欄があるということです。

上位の【様式2】見積額一覧では、運用保守委託が次の4行に整理されています。

回線使用料とASP・SaaS利用料、つまり実費にあたる2行にだけ「業者提示の明細を添付すること」という指定が付いています。実費は金額を書くだけでは足りず、外部事業者が出した明細を添えさせるという設計です。

【様式0】の見積書には「見積前提」の記入欄もあり、記入例として「設計開発・運用保守等委託業務にかかる現地までの交通費、通信連絡費用については、本見積に含まれるものとする」「ユーザ教育研修は集合研修形式を想定しており、各拠点で個別に教育研修を行う場合は、見積について別途調整が必要である」といった前提条件が置かれています。前提を書く欄が様式の側に用意されている、という点が重要です。

2つの様式に共通している4つの要求

年代も発注者も規模も違う2件ですが、要求している構造は共通しています。

この4つは、発注者の立場や規模にかかわらず要求してよいものです。 公的機関が事業者へ求めている粒度であり、無理な要求ではありません。手元の見積書がこの4つを満たしていないなら、足りないのは値引きではなく記載です。

月額一式を4区分へ分解する手順

ここからは手元の紙を使います。目標は、すべての金額を実費／人の作業／システムの作業／待機の4区分のどれかに置くことです。この4区分はシステム保守費用の相場と妥当性の検証手順で整理した5つのコストドライバーのうち、見積書の行として現れる4つ（⑤引き継ぎ困難性を除く）と同じものです。本記事ではそれを行単位の作業手順に落とすため、最初に外へ出す実費を先頭、最後まで残差として残る待機を末尾に置き替えています（人の作業とシステムの作業の順は同じです）。

セキュリティ関連の行項目をさらに細かく分ける場合は、セキュリティ保守費用の内訳でパッチ適用・脆弱性診断・事故対応の分け方を解説しています。

保守費を実際に生んでいるのは、次の4つのどれかです。4つは増える理由がそれぞれ違うため、まとめて「保守費」と呼んでいる限り、なぜ増えたのか・なぜ下がらないのかを説明できません。 逆に言えば、4区分に割れた時点で、増減の理由をどの区分の議論として扱えばよいかが決まります（なぜその単価なのか、という背景は別に残ります）。

ステップ1｜1行が複数区分にまたがるなら、行を割ってもらう

「運用保守費　月額35万円」という1行は、実際には実費・人の作業・システムの作業・待機のすべてを含んでいる可能性があります。ここで自分で推測して割り振ってはいけません。割れない行は割れないまま「判断不能」に置き、ベンダーに割ってもらいます。

依頼するときは「内訳を出してください」ではなく、区分名を指定します。指定しないと、多くの場合「基本保守20万円／監視10万円／その他5万円」のような、名前が変わっただけの内訳が返ってきます。

ステップ2｜実費を役務の外へ出す

実費に当たる行を、金額の大小にかかわらず先に外へ出します。確認するのは変動の有無・証憑の閲覧可否・手数料の分離の3点で、それぞれの見方はシステム保守費用の相場と妥当性の検証手順のステップ2に詳述しています。

本記事で足すのは1点だけです。三重県警の様式は実費の2行にだけ「業者提示の明細を添付すること」と指定していました。実費は金額を書かせるだけでは足りず、提供元事業者が出した明細を添えさせるという設計です。同じことを依頼して差し支えありません。

ステップ3｜役務を人の作業・システムの作業・待機に分ける

残った役務を3つに分けます。起点になる質問は1つです。

障害も問い合わせも改修依頼も1件も発生しなかった月に、請求額はいくらになりますか。

この質問の答えは2通りに分かれ、分け方も変わります。

「◯万円に下がります」なら、引き算で分解できます。下がったあとの金額から実費とシステムの作業（自動監視・自動バックアップなど、件数に関係なく動き続けるもの）を除いた部分が待機の対価で、直近数か月の平均的な月の請求額との差額が人の作業です（実費が月ごとに動く場合は、実費を除いた金額どうしで比べてください）。ただし、初期費用を分割して月額に載せている分（ステップ4）も、この残りに入ります。待機の対価が想定より大きく出たときは、ステップ4を先に済ませてから引き算し直してください。

「同額です」なら、この引き算では分解できません。人の作業の対価も月額に溶けている状態だからです。この場合はまず確認質問1で4区分別の金額を出してもらってください。それが出てこないときは、月額に含まれる作業時間の上限と超過単価（確認質問2）を押さえ、上限×超過単価を人の作業の上振れ側の目安に置きます。超過単価は月額に含まれる分の単価より高く設定されているのが普通なので、この数字は人の作業を多めに見たものになります。上限そのものが設けられていない場合、この方法は使えません。 そのときは確認質問2で「上限を設けない代わりに範囲をどう限定しているか」を聞き、確認質問8の作業実績（時間）を人の作業の実測値として使ってください。「同額です」という答えそのものは異常ではありません。 ただ、待機と人の作業の境目が契約に書かれていないことを示しています。

どちらの場合も、続けて待機の中身を決める3つの条件を確認します。

対応時間帯が「平日日中」と「24時間365日」では、カバーすべき時間が単純計算で3〜4倍になり、必要な人員も大きく変わります（週45時間前後と週168時間の比較。あくまで目安です）。この3条件が書かれていない月額固定は、金額の当否以前に、何を買っているのかが決まっていません。

「作業が1件もなかった月に同額を払うのは妥当か」という論点そのものを社内で説明する必要がある場合は、システム保守の月額固定は何の対価かに、待機の対価をどう位置づけるかと、契約に書かせる上限・超過単価・繰越の3点をまとめています。

2つめの応答目標については、書かれている数字が「連絡までの時間」なのか「復旧までの時間」なのかで意味がまったく変わります。同じ「1時間以内」でも約束している範囲が違うため、定義の読み分けはシステム保守のSLAと費用を参照してください。

ステップ4｜一度きりの作業を月額から外す

人の作業のうち、繰り返し発生しないもの（初期のデータ移行、導入時の操作説明、環境構築、制度変更への一度きりの対応など）が月額に溶けていないかを確認します。本記事で見るのは終期です。月額へ含めること自体が合理的なケースもあります。初期費用を抑えたい発注側の要望で分割払いにしている場合や、実際には毎月継続的に発生している場合です。判定は単純で、「その作業は来年も同じ量で発生しますか」と聞き、発生しないなら、いつまで月額に含まれるのかを確認します。 終期が定まっていない分割は、実質的な値上げと同じ効果を持ちます。

分解ワークシート

ここまでの4ステップを、1枚に落とすとこうなります。単位は万円でも円でもかまいません。

見るのは金額の大小ではなく、未分類の合計が総額の何割を占めるかです。 上の記入例なら未分類は40.0／54.2で約74%です。 2割未満なら内訳は分解されており、次の比較の段階へ進めます。2割以上5割未満なら、主要な費目は見えているものの確認が残っている状態です。金額の大きい未分類行から順に分解を依頼したうえで比較へ進んでください。5割以上なら、この見積書だけでは判断できません。この2割・5割は実務上の目安として置いた区切りで（システム保守費用の相場記事と共通です）、公的基準や統計調査に基づく数値ではありません。

本記事で強調したいのは、5割以上の状態で他社に声をかけてはいけないということです。比較のしようがない見積もりが1枚増えるだけで終わります。まず現行ベンダーへ内訳の分解を依頼してください。

依頼を空振りさせない2つのコツ

送る文面は本記事末尾の確認質問にまとめてあるので、そちらをそのままお使いください。依頼が空振りしないためのコツを2つだけ書きます。

「値下げの相談ではない」と最初に書くこと。 これを書かないと、内訳ではなく割引案が返ってくることがあります。割引案が返ってくると、内訳は永久に出てきません。

期限を切ること。 期限のない依頼は後回しになります。1〜2週間程度が現実的です。

公開されている料金表は、何を書いているか

「保守の料金表を公開している会社なんてあるのか」と思われるかもしれません。日本の受託開発会社ではほとんど公開されていませんが、クラウド事業者のサポート契約は公開されています。ここでは3社の公開料金を、同じ条件へそろえて並べます（いずれも2026年8月19日取得）。

適用条件を先に書きます。 これはクラウド基盤のサポート契約であり、受託開発したシステムの保守契約ではありません。金額の水準を保守費の相場として読み替えることはできません。 見てほしいのは、料金体系を公開する事業者が「何を書かないと料金表として成立しないと考えているか」です。

クラウド3社の公開料金を同じ条件へそろえる

下表の行の並びは最低額の水準でそろえたものです。原典での位置づけは各社で異なり、たとえばAWSはビジネスサポート+を本番ワークロードの最小推奨プランとしています。

対応時間帯と応答目標は、プランごとに数字で書かれている

料金だけでなく、その料金で何が約束されるかも公開されています。

Google Cloudの表記に注目してください。24時間365日は「大きな影響およびクリティカルな影響のある事象」に限られると明記されています。すべての問い合わせが24時間受け付けられるとは書かれていません。「24時間365日対応」という文言があったら、対象がどの事象かを確認する必要がある、ということです。

応答時間は「保証」ではない、と提供側が脚注で書いている

AWSのプラン比較ページでは、応答時間表のうちビジネスサポート+とエンタープライズサポートの最上位の重大度のセルに脚注が付されており、次のように書かれています。

お客様からの最初のリクエストに、対応する時間内に応答するよう、合理的な範囲でできる限りの努力を払います。

つまり、少なくとも脚注が付されたこの2プランの最上位の重大度については、公開されている応答時間は努力目標です。未達時の返金や補償についても、当該ページに記載がありません。料金体系を公開している大手ですらこう書いている、という事実は覚えておく価値があります。

手元の見積書に「1時間以内に対応」とだけ書かれていた場合、確認すべきは3つです。それは受付か、一次応答（人が着手すること）か、復旧か。目標か、保証か。保証なら達成できなかったときに何が起きるか。 ここを聞かずに数字だけ比べても意味がありません。

3社の書き方から浮かぶ5要素

3社の書き方を突き合わせると、料金表を成立させている要素が5つ浮かびます。

この5つのうち、手元の見積書に書かれていない項目が、そのまま質問リストになります。 なお3社とも公開ページに税の記載がありませんでした。海外事業者の価格ページでは珍しくないことですが、日本国内の保守見積もりで税区分が書かれていない場合は、必ず確認してください。 税抜と税込では総額が1割違います。

ベンダー側の言い分が正当と言える条件

ここまで「分けてもらう」話をしてきましたが、分けられていないことが常に問題というわけではありません。ベンダー側の言い分が正当と言えるケースを整理します。

いちばん右の列に当てはまったからといって、不当だと決まるわけではありません。「要確認」というだけです。 説明を聞いて条件が満たされれば「説明済み」になります。

なお、細かく分けることには実際にコストがかかります。毎月の作業実績を記録し、区分ごとに集計し、報告書にまとめる工数は無料ではありません。分けることを求めるなら、その手間が価格に反映されうることも受け入れる必要があります。 全項目を最小粒度で求めるのではなく、金額の大きい行から順に分けてもらうのが現実的です。

確認が必要なケース｜見積書の10の危険信号

保守見積もりの費用・内訳まわりで実際に問題になりやすい論点を10件に整理しました。左が見積書の状態、中央が起きうること、右が「説明済み」に動かすために必要な証拠です。

10件はいずれも、後掲の確認質問10問のどれかで聞けます（1→質問1、2と6→質問7、3→質問5、4と5→質問9、7→質問10、8と9→質問2、10→質問2と質問8）。

「安い」ほうが危険なこともある

見積もりを比べたとき、金額の低いほうが常に得とは限りません。金額を下げるときに最初に落ちる項目は決まっています。

最後の1つが要点です。報告がないと、他の5項目が実施されているかを検証する手段がなくなります。 報告書は付随的なサービスではなく、月額固定契約における対価の証明です。金額を下げる相談をするときも、報告だけは残してください。

なおシステム保守費用の相場と妥当性の検証手順では、同じ論点を8項目で整理しています。本記事の6項目は、そのうち相見積もりで各社の差が出やすい5項目を取り、月次の作業実績報告を1つ足したものです（あちらの「障害の一次切り分け体制」「移行・データ整備」「保守側のプロジェクト管理」は本記事では扱いません）。とくに保守側のプロジェクト管理は、月額に含まれているかどうかで受付と進捗管理の属人化が変わるため、相場記事の該当箇所と併せて確認してください。

4状態への割り当て

10件の危険信号を、状態として整理します。総額に対して1つの判定を出すのではなく、行ごとに判定します。

契約書の側で「これは保守に含まれるのか、追加開発なのか」を確定させたい場合は、システム保守契約の範囲に判定の手順をまとめています。本記事が扱っているのは見積書の金額内訳、そちらが扱っているのは契約書の範囲条項です（そちらも4状態で判定しますが、状態の中身は「含む／別料金／対象外／不明」で、本記事の4状態とは別のものです）。

複数社の保守見積もりを、同じ条件へそろえる

ここからが相見積もりの話です。保守の相見積もりで最も多い失敗は、金額を比べる前に条件をそろえていないことです。同じシステムで金額が2倍違ったとき、原因は単価ではなく対応範囲であることがほとんどです。

比較する前にそろえる6分類

比較軸は次の6つに整理できます。この6分類のすべてで条件が一致して初めて、金額の比較が意味を持ちます。

6分類のうち、初回の見積もりで揃っていることが最も少ないのは4と5です。 監視とバックアップは「あります」で終わっていることが多く、復旧テストと月次報告は書かれていないほうが普通です。ここが揃っていない見積もりを金額で比べると、削った会社が安く見えるという逆の結果になります。

分類4のうちバックアップは、取得・復旧テスト・実際の復元作業を別の費用として読む必要があります。3つの切り分け方はバックアップの保守費用にまとめました。分類5の更新条件については、自動更新のたびに料金が改定される契約が珍しくありません。CPI連動・上限・通知期限の読み方はシステム保守の自動更新で値上げされる条件が扱っています。

条件そろえシート

各社の見積もりを1枚に並べます。金額欄はいちばん最後に埋めてください。

現行ベンダーの列を必ず作ってください。 相見積もりの目的は乗り換えではなく、現行契約に何が入っていて何が入っていないかを確定させることです。現行の列が埋まらないなら、まず現行ベンダーへの内訳依頼が先です。

出力は「A社が安い」ではなく、3判定

シートが埋まったら、金額差を次の3つのどれかに分類します。

初回の比較でいちばん多いのは2つめです。 これは失敗ではありません。何が揃っていないかが分かった時点で、相見積もりは半分成功しています。1回目で3社を横並びにできることは、まずありません。

比較しても差が説明できないとき

条件を揃えたうえで、それでも金額差の理由が説明されない場合があります。このとき考えられるのは主に2つです。

1. 他社が現行システムの中身を把握できていない。 設計書がない、構成が分からない状態で見積もると、リスク分を上乗せするか、逆に見落として安く出すかのどちらかになります。安すぎる見積もりは、契約後に「これは範囲外です」が続く形で調整されます
2. 現行ベンダーの価格に、他社が持っていない前提が乗っている。 過去の経緯、既存の改修履歴の知識、緊急時の即応体制。これらは実在する価値ですが、金額として妥当かどうかは別の判断です

どちらの場合も、次に確認するのは価格ではなく他社が正確に見積もれる状態かどうかです。設計書・構成図・運用手順書・管理者権限が自社側にない場合、そもそも公平な相見積もりは成立しません。この構造はベンダーロックインで保守費用が下がらない理由で公的調査データとともに整理しています。

開発案件の相見積もりについては、開発会社の見積もり比較ガイドが対応します。開発と保守では比較すべき軸が違うので、混ぜないでください。

契約先と、実際に作業する会社が違うとき

見積書に書かれた会社名と、実際に障害対応をする会社が違うことがあります。これ自体は珍しくもなければ、不当でもありません。 特定の技術領域を専門会社へ委託する、地方拠点の現地対応を地元の事業者へ依頼する、といった形は合理的な体制設計です。

問題になるのは、その事実を発注側が知らないまま契約している場合です。障害が起きてから「弊社の委託先が対応しますので、確認に時間がかかります」と言われて初めて知る、というのが典型です。

確認すべきは3点です。

1｜責任主体はどちらか

再委託先が起こした問題について、契約先が発注者に対して責任を負うのか、それとも「委託先の問題なので」と切り離されるのか。契約書に再委託の条項があるかどうかと、責任の帰属がどう書かれているかを確認します。

再委託を認めるかどうかの書き方は事業者によって大きく違い、事前承諾を必要とするものから、承諾なしで委託できるとするものまであります。手元の契約書がどちらの型かを読んでください。

2｜情報の受け渡し範囲

システムの保守では、業務データに個人情報が含まれることが少なくありません。この場合、発注側にも法律上の義務が生じます。

個人情報の保護に関する法律（平成十五年法律第五十七号）第25条は、委託先の監督について次のように定めています。

個人情報取扱事業者は、個人データの取扱いの全部又は一部を委託する場合は、その取扱いを委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならない。

再委託がある場合の扱いは、個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（通則編）」（平成28年11月、令和8年6月一部改正）3-4-4に書かれています。同ガイドラインは、委託先が再委託を行おうとする場合、委託元は、委託先が再委託する相手方・再委託する業務内容・再委託先の個人データの取扱方法等について、委託先から事前報告を受け又は承認を行うこと、および定期的な監査の実施等により、委託先が再委託先に対する監督を適切に果たすこと、再委託先が法第23条に基づく安全管理措置を講ずることを十分に確認することが望ましいとしています。再委託先がさらに再々委託を行う場合以降も同様、とされています。

同ガイドラインは冒頭で、「努めなければならない」「望ましい」等と記述している事項についてはこれらに従わなかったことをもって直ちに法違反と判断されることはないと述べています。つまりここは法的義務ではなく推奨にあたる記述です。ただし同ガイドラインには注記があり、委託元が委託先について「必要かつ適切な監督」を行っていない場合で、委託先が再委託をした際に再委託先が不適切な取扱いを行ったときは、元の委託元による法違反と判断され得るので注意を要する、とされています。

同ガイドラインが挙げる「監督を行っていない事例」には、再委託に関するものが2件あります。ひとつは、再委託の条件に関する指示を委託先に行わず、かつ委託先の個人データの取扱状況の確認を怠り、委託先が個人データの処理を再委託した結果、当該再委託先が個人データを漏えいした場合。もうひとつは、契約の中に委託元が委託先による再委託の実施状況を把握することが盛り込まれているにもかかわらず、委託先に対して再委託に関する報告を求めるなどの必要な措置を行わず、委託元の認知しない再委託が行われた結果、当該再委託先が個人データを漏えいした場合です。

つまり、「知らなかった」という説明だけでは、必要かつ適切な監督を果たしたことにはならない、という整理です。 保守の見積もりを受け取る段階で、個人データがどこまで渡るのかを確認しておく実務上の理由がここにあります。なお、自社の具体的な取扱いが法令に適合するかどうかの判断は、弁護士など専門家の領域です。

3｜障害時の指揮系統

深夜にシステムが止まったとき、誰が誰に連絡し、誰が復旧作業の判断をするのか。契約先の担当者を経由するのか、再委託先へ直接つながるのか。経由が1段増えると、一次応答の目標時間はその分だけ実質的に長くなります。

見積書に「一次応答30分以内」と書かれていても、実作業者への連絡経路が定義されていなければ、その30分は契約先の受付までの時間かもしれません。応答時間の数字を比べる前に、経路を確認してください。

再委託まわりのチェック項目

前掲の条件そろえシートには、次の5項目を入れてあります。再委託がある場合は、この5行を先に埋めてください。

「中抜きされているのではないか」という疑いから入ると、話が進みません。確認するのは体制の透明性であって、利益率ではありません。 体制が書面で確認できていれば、複数社が関わる形でも問題ありません。

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

ここまでの内容を、そのまま送れる10問にまとめました。1問ずつ聞くのではなく、まとめて送ってください。

ひとつ先にお断りしておくと、文面では4区分の呼び方を変えています。 本記事で使っている区分名は社内で費用を整理するための言葉で、そのままベンダーへ送ると意図が伝わりにくいためです。対応は次のとおりなので、返ってきた内訳を分解ワークシートへ転記するときは、この表で読み替えてください。

システム保守費用の相場と妥当性の検証手順にも9問の文面がありますが、あちらは現行契約の実績を検証するための質問、こちらは見積書の記載を埋めるための質問です。両方を送る必要はありません。

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

○○株式会社 ○○様

お世話になっております。△△株式会社の□□です。

保守のご提案について、社内で内容を確認するにあたり、以下10点についてご回答をお願いできますでしょうか。金額の見直しをお願いするものではなく、契約内容を正確に把握するためのご確認です。

1. 月額費用の内訳と算定の前提 月額費用を「外部への支払い（実費）」「人が実施する作業」「自動化されている作業」「体制維持（待機）」の4つに分けると、それぞれいくらになりますか。月額の算定が「開発費の◯%」などの料率による場合は、分母となる金額に何を含めているかを教えてください。また、障害・問い合わせ・改修依頼が1件も発生しなかった月の請求額はいくらになりますか（作業量が少ない月でも下回らない最低額の定めがある場合は、その金額も併せてお願いします）。

2. 作業量の上限と超過 月額に含まれる作業時間または対応件数の上限はありますか。上限を超えた場合の単価と、超過前に当社の承認をいただく手続きはございますか。未使用分の繰越可否と失効条件も併せてお願いします。上限を設けていない場合は、月額に含まれる作業の範囲をどのように限定しているかを教えてください。また、「軽微な改修」に当たるかどうかは誰が判定しますか。改修後に、変更していない機能が壊れていないことを確認する試験（回帰試験）は月額に含まれますか。

3. 対応時間帯 受付、一次応答、復旧作業のそれぞれについて、対応時間帯を教えてください。祝日・年末年始の扱いと、時間外に発生した場合の追加費用の有無も含めてお願いします。対象システムと環境（本番／検証／開発）、および明示的に対象外となる作業の一覧も併せてお願いします。

4. 応答と復旧の目標 障害発生時の一次応答の目標時間と、復旧の目標時間をそれぞれ教えてください。これらは目標でしょうか、契約上の保証でしょうか。保証の場合、未達時にどのような扱いになりますか。重大度（優先度）の区分がある場合は、その定義と、どの区分に当たるかを誰が決めるかも教えてください。

5. 監視とセキュリティ更新 監視は自動監視でしょうか、有人監視でしょうか。監視対象の項目と、異常を検知したあと人が行う作業の内容、および対応開始までの目標時間を教えてください。併せて、OS・ミドルウェア・依存ライブラリのセキュリティ更新は月額に含まれますか。含まれる場合は対象範囲と、緊急の脆弱性が公表されたときの適用の判断基準・目標時間を教えてください。また、サポート終了（EOL）が近いOS・ミドルウェア・ライブラリのバージョンアップは、セキュリティ更新とは別に月額へ含まれますか。別料金の場合は費用の考え方も教えてください。併せて、体制維持（待機）について対応可能な担当者は何名体制でしょうか（1名か交代制か、休暇時の代替の有無）。

6. バックアップと復旧テスト バックアップの取得頻度・保管世代・保管場所を教えてください。また、退避したデータから実際に戻せるかを試す復旧テストは、契約に含まれますか。含まれる場合は実施頻度も教えてください。誤削除・誤更新からの復元作業を依頼した場合の扱い（月額に含むか別料金か）も併せてお願いします。

7. 実費の扱い クラウド利用料・ライセンス・回線などの外部への支払いについて、提供元事業者の明細をご提示いただけますか。請求代行の手数料が含まれる場合は、その率を教えてください。リザーブドインスタンスやコミット割引などが適用されている場合は、割引適用前と適用後の金額を分けて教えてください。外貨建ての費用を円換算されている場合は、為替レートの基準日と換算方法も併せてお願いします。

8. 実績報告 毎月ご提出いただく報告書には、作業実績・障害履歴・残時間のうちどれが含まれますか。提出時期と形式も教えてください。また、設計書・手順書の更新は月額に含まれますか。含まれる場合は対象範囲と更新の時期を教えてください。

9. 一度きりの作業の扱い 初期設定・データ移行・操作説明など、一度きりで終わる作業が月額に含まれている場合は、その項目名と、いつまで月額に含まれるかを教えてください。該当する作業がある場合は、直近の実績量（件数または時間）と、量が減ったときに月額がどう変わるかも教えてください。

10. 実際の作業体制と契約条件 実際に作業を担当されるのは御社のみでしょうか、他社への委託がありますか。委託がある場合、責任の所在と、障害時の連絡経路を教えてください。併せて、個人データを再委託先が取り扱う場合の範囲、クラウド・ドメイン・リポジトリの管理者権限の所在、契約終了時の引き継ぎ支援の時間・単価・成果物も教えてください。各費用の税区分（税抜／税込）、支払サイクル（月次／年間一括前払いなど）、最低利用期間、解約予告期間、中途解約した場合の精算方法（返金の有無）、自動更新の有無、値上げの条件についてもお願いします。

お手数をおかけしますが、○月○日ごろまでにご回答いただけますと助かります。

よろしくお願いいたします。

回答をどう読むか

回答が返ってきたら、金額を見る前に次の観点で読んでください。

いちばん下の行が要点です。内訳のないまま安くなった契約は、根拠が無いまま金額だけが動いた状態なので、翌年の更新時に同じ問題が繰り返されます。

質問6と質問8は、金額の大小と無関係に優先度が高い項目です。バックアップは取得しているだけでは復旧できず、報告書がなければ月額固定契約の対価を検証する手段がありません。

回答が揃ったあとの進め方

進め方は次の4つに分かれます。これは前掲の行ごとの4状態とは別で、残っている行のうちいちばん重いものに合わせて見積書全体の進め方を選ぶための表です。上から順に見て、最初に当てはまったものを採ってください。「乗り換える」が正解とは限りません。

現行ベンダーの継続が合理的、という結論も十分にあり得ます。 費目の大半が説明済みで、毎月の作業報告が提出され、引き継ぎに必要な資料と権限をいつでも受け取れる契約になっているなら、切り替える理由は薄くなります。切り替えには移行費用と、稼働中システムの知識が失われるリスクが伴います。

重要なのは金額を下げることではなく、金額の根拠をいつでも確認できる状態を維持することです。その状態が確保されていれば、次の更新時にも同じ検証ができます。

手元の見積書について、行項目の分解と確認質問の作成を自動で進めたい場合は、見積書の登録不要レビューをご利用ください。ブラウザ内でテキストを抽出し、結果の閲覧までメールアドレスの入力は不要です。匿名化された抽出結果を画面で確認したうえで診断へ進む形になっています。

根拠資料と適用条件

本記事で使用した資料と、その適用範囲です。資料ごとに前提が違うため、まとめて扱わないでください。

公開価格は改定されるため、実際の判断時には出典元の最新情報を確認してください。日本の受託開発会社が公開している保守の標準料金表は、本記事の調査時点では複数社を横並びにできる形では確認できませんでした。そのため本記事では、料金水準ではなく料金表の構造のみを公開情報から引用しています。

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

よくある質問