指値単価の運用とシステム保守：SLAの読み方と、停止時に単価を守る備え方

◆監修・編集責任者　小園 将隆　2026年11月10日

B2B EC-COLUMN

指値単価の運用で、保守が止まると困るのはどの業務場面か

価格改定日の前日や注文の締め時刻の直前に、システムが止まる。
あるいは、取引先と決めた指定単価（指値）とは違う単価で注文が入る。
そんな不安から保守契約を見直すとき、最初に読むのは「稼働率◯%」の数字ではありません。
SLA（サービス品質の取り決め）が、何を停止時間から除いているかです。
確認できたある製品のSLAでは、計画メンテナンスや顧客側の環境が原因の停止は稼働率の計算外で、告知の期限は別に定められていました¹。
まず、除外事項とメンテナンスの告知を、自社の改定日・締め時刻に重ねます。
そのうえで、ベンダーに任せられない部分を、単価の履歴と代替手順として自社で持ちます。
この順で備え方を決めていきます。

単価の登録・更新が止まる場面

ここでいう保守は、指定単価を登録して注文に適用する受発注・EC・購買システムの保守のことです。
保守部品やメンテナンス作業そのものを指値で発注する話は別の論点なので、以下ではシステム側に絞って考えます。

指値単価の運用で最も時間の制約がきついのは、価格改定に合わせた登録・更新です。
取引先から新しい指定単価を受け取り、単価マスタ（取引先ごとの単価を持つ台帳）へ登録し、社内の承認を通し、適用開始日を設定します。
この一連の作業は、改定日より前に終わっていなければ意味がありません。

改定日の前日に管理画面へ入れない状態が続くと、新しい単価は登録されないまま改定日を迎えます。
その日から入る注文には旧単価が適用され、受注確認書や納品書、請求書まで旧単価で作られていきます。
復旧後に単価を直しても、すでに流れた注文の訂正、取引先への説明、請求書の差し替えという後始末が残ります。
停止そのものは短くても、影響は改定日をまたいだ注文の数だけ広がります。

承認の仕組みを使っている場合は、もう一段の注意が要ります。
登録担当者が入力を終えていても、承認者の画面が使えなければ単価は有効になりません。
止まったのが入力の段階か承認の段階かで、その間に取れる手も変わります。

注文時の単価適用が崩れる場面

もう一つの困りごとは、システムは動いているのに、注文に載る単価が想定と違う場面です。
取引先別の指定単価が効かずに標準価格で注文が入る、適用開始日の設定がずれて改定前の単価が残る、メンテナンスの前後で設定が変わったように見える、といった状況です。
画面は開けて注文も通るため、こうした状況には気づくのが遅れやすくなります。

ここで押さえておきたいのは、この場面が「停止」とは別物だという点です。
稼働率の保証は、サービスが使えるかどうかを測る取り決めです。
稼働率の算式が数えるのは止まっていた時間なので、単価が誤って適用されている間の問題はその計算に入りません。
単価の不整合を誰が調べ、誰が直すのかは、稼働率とは別の条項を読まないと分からないのです。

原因も一つとは限りません。
考えられるのは、システムの不具合、自社の設定ミス、自社の基幹システムから単価を取り込む連携の不具合などです。
どれが原因かによって保守の対象になるかどうかが変わるため、次の節では規定の読み分けを扱います。

買い手側と売り手側で見る箇所が違う

同じ指値単価でも、単価を指定する買い手と、それを受け取って登録する売り手とでは、止まったときに困る箇所が違います。
買い手は、購買システムで発注書に単価を載せて送る側です。
購買システムが止まれば発注書を出せず、単価が誤っていれば誤った指値がそのまま取引先へ届きます。

売り手は、受け取った指定単価を受発注システムやECの取引先別価格に登録し、注文へ適用する側です。
登録が遅れれば旧単価のまま受注し、買い手の発注書と自社の受注データとで単価が食い違います。
買い手の発注書は正しく、売り手のシステムだけが古い単価を持っている状態は、請求の段階で初めて表に出ることもあります。

立場によって、保守契約で重点的に読む箇所も変わります。
買い手なら、発注書の送信と単価の指定が止まらないかが中心です。
売り手なら、単価の登録と注文への適用が止まらないかが中心になります。
仕入れと販売の両方を担う卸のような事業者は、仕入側と販売側の二つのシステムで、それぞれ同じ確認が必要です。

▼ 図の内容を文字で読む

• 買い手側（単価を指定する）
  • 購買システムが止まると発注書を出せない
  • 単価が誤っていると誤った指値が取引先へ届く
  • 読む箇所は発注書の送信と単価の指定が止まらないか
• 売り手側（受け取って登録する）
  • 登録が遅れると旧単価のまま受注する
  • 発注書と受注データの単価が請求の段階で食い違う
  • 読む箇所は単価の登録と注文への適用が止まらないか
• 仕入れと販売の両方を担う卸
  • 仕入側と販売側の二つのシステムがある
  • それぞれで同じ確認が必要になる

保守・サポート規定は何を対象にし、何を除外しているか

対象範囲と除外事項の読み分け

ベンダーとの取り決めは、複数の文書に分かれていることがあります。
サービスの稼働をどこまで保証するかを定めたSLA、問い合わせや障害対応の受付方法を定めたサポート規定、そして利用契約や保守契約の本体です。
前の節で挙げた困りごとのうち、停止とデータの不整合は別の文書で扱われている場合があります。
一つの文書だけを読んで安心しないことが出発点になります。

読むときは、書かれている内容を「対象」「除外」「顧客側要因」の三つに分けると整理しやすくなります。
対象は、ベンダーが保証や対応を約束している範囲です。
除外は、停止や不具合が起きてもベンダーの保証の外に置かれる事柄です。
顧客側要因は除外の一種ですが、自社の環境や操作が原因とされるもので、備える主体が自社になる点で分けておく価値があります。

確認できたZoho CRMのSLAでは、Zohoの管理外の要因として、ISPの障害、自然災害、DoS攻撃などによる停止が停止時間から除かれています¹。
同じSLAでは、AI機能（Zia等）の停止も稼働時間の対象外とされています¹。
これは一つの製品の例であり、受発注・EC・購買システムの規定が同じ除外を置いているとは限りません。
ただ、稼働率の保証には除外の欄があり、その中身次第で保証の実質が変わることは、この例からも読み取れます。

顧客側の環境が原因の停止の扱い

同じSLAでは、顧客側のハードウェア、ソフトウェア、ネットワーク構成に起因する停止も、停止時間から除外されています¹。
指値単価の運用に当てはめると、自社の回線が落ちて管理画面に入れない、自社のパソコンやブラウザの設定で画面が動かない、といった状況は、ベンダーの保証の外に置かれる可能性があります。

見落としやすいのは、単価の取り込みです。
自社の基幹システムや表計算ファイルから、取引先別の単価を一括でシステムへ取り込んでいる場合、契約によってはその連携の仕組みが自社側の構成と扱われます。
改定日の前に取り込みが失敗しても、原因が自社側の連携にあれば、稼働率の保証の話にはなりません。

とはいえ、自社側が原因のトラブルを、すべて自力で解決しなければならないとは限りません。
サポート規定で問い合わせに応じる範囲が、稼働率の除外より広いこともあり得ます。
停止時間の計算から除かれることと、問い合わせに応じてもらえないことは別の話です。
両方を分けて確かめる必要があるのはそのためです。

データ修正・設定変更が対象かを確かめる

指値単価の運用で最も気になるのは、単価データの誤りをベンダーがどこまで扱ってくれるかでしょう。
今回確認したZoho CRMのSLAのページには、データの修正や設定変更の扱いは書かれていませんでした。
稼働率の取り決めは稼働を測るものであり、データの中身の正しさまで約束しているとは読めません。

そのため、データ修正や不整合の調査が対象に含まれるかどうかは、契約書や保守規定の該当条項で一つずつ確かめることになります。
質問の仕方を具体的にしておくと、回答のあいまいさが減ります。

• 単価が想定と違って注文に載ったとき、原因の調査（不具合か、仕様か、設定か）を依頼できるか
• 原因が不具合だった場合、誤った単価で作られた注文データの修正まで対応範囲に入るか
• 単価マスタの一括修正や設定変更を代行してもらえるか。
  その場合、保守の範囲か別料金か
• 改定日の直前など、急ぎの調査を受け付ける窓口と時間帯があるか

「設定はお客様の責任」という回答なら、設定の誤りを自社で見つけて直す手順を持つことが前提になります。
その手順の土台になるのが、後の節で扱う単価一覧と変更履歴です。

▼ 図の内容を文字で読む

• 対象
  • ベンダーが保証や対応を約束している範囲
  • 備える主体はベンダー
• 除外
  • 計画メンテナンス、ISPの障害、自然災害、DoS攻撃
  • AI機能の停止
  • 保証の外に置かれ、自社が代替手順で備える
• 顧客側要因
  • 自社のハードウェア・ソフトウェア・ネットワーク構成
  • 単価を取り込む連携の仕組み
  • 自社が環境と連携を点検する

稼働率の保証とメンテナンス時間帯は、締め時刻・改定日にどう影響するか

稼働率の算式と、計画メンテナンスの位置づけ

稼働率は、一定の期間のうちサービスが使えた時間の割合です。
Zoho CRMのSLAでは、毎月のサービスの稼働時間（アップタイム）が99.9%と定められています¹。
算式は、毎月の時間の合計から停止時間の合計を引き、毎月の時間の合計で割って100を掛けるものです¹。

この算式から分かるのは、稼働率が月全体をならした数字だということです。
深夜の停止も、注文締めの直前の停止も、停止時間としては同じ重さで数えられます。
稼働率が目標に届いていても、止まった時間帯が締め時刻に重なれば、業務への影響は数字が示すより大きくなります。

さらに、同じSLAでは、計画メンテナンスが停止時間の計算から除外されています¹。
計画メンテナンスとは、ベンダーが事前に予定して行う保守作業のための停止です。
計算から除かれる以上、計画メンテナンスでどれだけ止まっても、稼働率の数字は下がりません。
つまり、稼働率が高いからといって、改定日や締め時刻に計画メンテナンスが重ならないとは言えないのです。

事前告知の期限と、改定日の準備期間を比べる

同じSLAでは、計画メンテナンスについて、48時間以上前に通知が送信されると定められています¹。
この期限で足りるかどうかは、自社が改定日の準備にどれだけ前から取りかかるかで決まります。

改定日に向けた作業を、改定日からさかのぼって並べてみます。
取引先から新しい指定単価を受け取る、単価マスタへ登録する、承認を通す、テスト用の注文で単価の適用を確かめる、関係部署や取引先へ切り替えを知らせる。
これらを改定日の数日前から順に進めているなら、告知が届いた時点ですでに登録作業の途中、ということもあり得ます。
告知の期限が守られていても、作業の山場とメンテナンスが重なれば、段取りの組み直しが必要になります。

もう一つ見ておきたいのは、告知が誰に、どの経路で届くかです。
管理者のメールアドレスにだけ届き、単価を登録する担当者が知らないまま改定日を迎えるといった行き違いは、期限を長くしても防げません。
告知の受け手に価格改定の担当者を含める、告知を受けたら改定日と締め時刻の予定表と突き合わせる、といった社内の流れは、期限の交渉より先に整えられる部分です。

なお、この48時間という期限はZoho CRMのSLAでの値で、他の製品にそのまま当てはまるものではありません。
自社のシステムで告知の期限がどう定められているか、月末や改定日が集中する時期を避けて予定を組んでもらえるかは、契約の際に確かめる事柄です。

補償条件を契約書で確かめる

稼働率が目標を下回ったとき、どう扱われるかもSLAを読むうえでの論点です。
今回確認したZoho CRMのSLAのページには、補償の条件は書かれていませんでした。
補償の取り決めがあるか、あるならどう申請するかは、契約書や別の規定で確かめる必要があります。

ただし、指値単価の運用から見ると、補償で埋められる範囲には限りがあります。
仮に利用料について何らかの補償を受けられても、改定日に旧単価で流れた注文の訂正や、取引先への説明、請求書の差し替えにかかる手間は戻ってきません。
補償条件は契約を比べる材料として確かめつつ、単価を守る備えは別に用意する、という分け方が現実的です。

▼ 図の内容を文字で読む

1. 計画メンテナンスは停止時間の計算から除外
   • どれだけ止まっても稼働率の数字は下がらない
2. 稼働率が高くても重なりは残る
   • 改定日や締め時刻に計画メンテナンスが重なる可能性
3. 告知を自社の予定表と突き合わせる
   • 告知は48時間以上前（確認できた製品の値）
   • 受け手に価格改定の担当者を含める
4. 改定準備の期間と比べる
   • 間に合わなければ段取りを組み直す

注文が止まったとき、指定単価を崩さずに受発注を続ける手順

停止前に用意しておく単価一覧

停止中に受発注を続けようとして最初に困るのは、「いまの正しい単価はいくらか」が分からなくなることです。
単価がシステムの中にしかなければ、システムが止まった瞬間に参照先がなくなります。
そこで、取引先別の指定単価を、システムの外で参照できる一覧として持っておくことを提案します。

一覧に入れておきたい項目は、取引先、品目、指定単価、適用開始日、改定前の単価、そして一覧を書き出した日時です。
改定前後の単価を両方持つのは、改定日をまたいで停止したとき、どちらを適用するかを判断できるようにするためです。
書き出した日時は、一覧がいつの時点の内容かを後から確かめるために残します。

一覧は、単価を登録・承認した直後に書き出すと決めておくと、システムとのずれが生まれにくくなります。
保管先は、そのシステムが止まっても開ける場所を選びます。
誰が更新し、停止時に誰が参照するのかを決めておかないと、いざというときに複数の版が出回るおそれがあります。

代替受注での単価の確認

次に、システムが止まっている間に、FAXやメール、電話で注文を受ける、あるいは発注書を送る場面を考えます。
このとき、注文の文面に単価を明記するかどうかで、後の手間が大きく変わります。
品目と数量だけでやり取りすると、復旧後に再入力した時点でシステム側の単価がそのまま使われます。
そして、それが合意した単価と一致するかを誰も確かめないまま進みかねません。

売り手の立場なら、受けた注文について単価を記した受注確認を買い手へ返し、一覧のどの時点の単価を使ったかを控えておきます。
買い手の立場なら、発注書に指定単価を書き、一覧の書き出し日時を添えておくと、売り手側の登録と照らし合わせやすくなります。
どちらの場合も目的は同じで、双方が同じ単価を見ていたことを文面で残すことです。

改定日をまたぐ停止では、旧単価と新単価のどちらを適用するかが争点になりやすくなります。
受注日で決めるのか、納品日で決めるのかは、取引先との取り決めによって違います。
取り決めがあいまいなまま代替受注に入ると、復旧後に解釈が分かれます。
改定の連絡を受けた段階で、適用の基準日を取引先と確かめておくと安心です。

復旧後の照合

復旧後は、停止中に受けた注文をシステムへ再入力します。
このときの照合では、システムに入った単価、手元の単価一覧、代替受注で取り交わした文面の三つを突き合わせます。
三つが一致すれば問題ありません。
どれか一つでも食い違えば、それがどこで誤りが生じたかの手掛かりになります。

照合の対象は、停止中の注文だけではありません。
停止の直前に入っていた注文や、処理の途中で停止をまたいだ注文も、単価が正しく保存されているかを見ておく必要があります。
停止中にシステム側でデータがどう扱われたかは外から見えにくいため、停止の前後で区切って確かめるほうが漏れを減らせます。

食い違いが見つかったら、その内容を記録し、単価一覧の更新や手順の見直しに戻します。
この流れを一度回しておけば、次の停止でどの手順に手間取ったかが分かり、一覧の項目や担当の分け方を直す材料になります。

▼ 図の内容を文字で読む

1. 登録・承認の直後に単価一覧を書き出す
   • システムが止まっても開ける場所に保管
   • 書き出した日時を残す
2. 停止中は注文の文面に単価を明記する
   • 売り手は単価を記した受注確認を返す
   • 買い手は発注書に指定単価を書く
3. 復旧後に三つを照合する
   • システムに入った単価
   • 手元の単価一覧
   • 代替受注の文面
4. 食い違いを記録し一覧と手順を見直す
   • 見直した内容を次の一覧の書き出しに反映する

買い手が指定する単価を、売り手との協議と記録の面から見直す

取適法の価格協議の規定

ここまでは、システムの停止や誤りから単価を守る話でした。
しかし、単価の履歴を自社で持つ理由はそれだけではありません。
指定単価は買い手と売り手のあいだの取引条件そのものであり、その決め方にも決まりがあります。

2026年1月1日から、下請法は「中小受託取引適正化法（取適法）」に変わりました²。
改正後の法律は、中小受託事業者から価格協議の求めがあったのに、委託事業者が協議に応じない、必要な説明を行わないなど、一方的に価格を決める行為を禁止しています²。

この規定がかかるかどうかは、取引の種類や、委託する側と受託する側の事業者の規模などの条件によります。
指値で単価を指定している取引が、すべてこの法律の対象になるわけではありません。
自社の取引が対象かどうかは、公正取引委員会や中小企業庁が示す要件で確かめる必要があります。

対象となる取引で買い手が委託事業者にあたる場合、指定単価の変更について取引先から協議を求められたら、それに応じて必要な説明をしなければなりません。
売り手が中小受託事業者にあたる場合、協議を求めたのに応じてもらえない、説明がないといった扱いは、この規定が問題にする行為にあたります。
どちらの立場でも、いつ誰がどの単価を示し、協議があったかどうかが、後から確かめられる形で残っているかが大事になります。

単価の変更履歴を残す提案

ここからは、法律が直接求めていることではなく、運用上の提案です。
指定単価を変更するたびに、いつ、誰が、どの単価を示し、協議があったか、どう合意したかを、システムとは別に履歴として残しておくことを勧めます。

履歴があると、二つの場面で判断が速くなります。
一つは、単価が想定と違って注文に載ったときです。
合意した単価と適用の開始時期が分かれば、誤りがシステムの登録側にあるのか、合意の解釈にあるのかを切り分けられます。
もう一つは、価格協議を求められたとき、または求めるときです。
過去の改定の経緯を示せれば、説明の材料を一から集め直す手間が減ります。

残す項目は、変更前と変更後の単価、適用開始日、単価を示した側、協議の有無と日付、合意を記した文書の保管場所、システムへの登録日と登録者です。
形式は、取引先や担当者が変わっても読める表形式で足ります。
前の節の単価一覧と同じ場所に置き、一覧は「いまの単価」、履歴は「そこに至った経緯」と役割を分けておくと、停止時の参照と協議の記録を一つの仕組みでまかなえます。

契約・更新時にベンダーへ確認する項目と、自社で持つ情報

ベンダーに確認する項目

契約や更新の場で確かめる事柄を、ここまでの話から拾い直すと次のようになります。
どの項目も、指値単価の運用で困る場面と結び付けて質問すると、ベンダーの回答が具体的になります。

• 障害の定義：単価が誤って適用される状態を障害として扱うか、稼働の停止だけを障害とするか
• データ修正の扱い：単価の不整合の調査、誤った注文データの修正、一括修正の代行が保守の範囲に入るか
• 問い合わせの受付時間：改定日の直前や注文締めの前に連絡できる窓口と時間帯
• 計画メンテナンスの告知：告知の期限と届く経路、受け手を追加できるか、時期の調整に応じるか
• 除外事項：稼働率の計算から除かれる停止の種類と、自社側の要因とされる範囲
• 補償条件：稼働率が目標を下回ったときの扱いと、申請の方法

回答を受け取ったら、自社の改定日と締め時刻の予定と並べて読みます。
告知の期限が自社の準備期間より短い、データ修正は範囲外、といった答えが返ってきた項目が、自社で備える部分になります。

自社で持つ情報

ベンダーの範囲の外に残った部分は、次の情報と役割を自社で持つことで補います。

• 単価の変更履歴：変更前後の単価、適用開始日、協議と合意の記録
• 単価一覧の定期的な書き出し：システムが止まっても開ける場所に、書き出した日時とともに保管
• 連絡窓口：ベンダーの障害・問い合わせ窓口と、主な取引先の受発注担当者
• 代替手順の担当者：停止時に一覧を参照し、代替受注と復旧後の照合を受け持つ人

これらは一度用意すれば終わり、というものではありません。
取引先が増える、担当者が替わる、システムを更新する、といった変化のたびに内容は古くなります。
保守契約の更新はベンダーとの取り決めを見直す機会です。
同じ時期に自社側の一覧と手順も見直すと、両方のずれに気づきやすくなります。

ベンダーに任せる部分と自社で持つ部分の境目は、契約ごとに違います。
稼働率の数字だけで比べず、除外事項と告知、データ修正の扱いを確かめたうえで、自社の改定日と締め時刻に照らして境目を引く。
これが、指定単価を守るための現実的な順序です。

SLAや保守規定の条項は、自社の改定日や締め時刻と重ねて読まないと、どこが備えの穴になるかが見えにくいためです。

手元の契約条項と価格改定の予定を並べ、ベンダーへ確認すべき項目と、自社で持つべき情報の切り分けを一緒に確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
稼働率の数字	計画メンテナンスなど除外される停止を確かめてから読む
計画メンテナンスの告知	期限を自社の改定準備の期間と比べ、受け手に価格改定の担当者を含める
単価データの修正	原因調査・注文データの修正・一括修正の代行に分けて、保守の範囲か確かめる
停止時の単価	システム外の単価一覧と、単価を明記した代替受注の文面で守る
単価の履歴	変更前後の単価・適用開始日・協議と合意の記録を表形式で自社に残す

代替受注や復旧後の照合の手順は、取引先との単価の取り決めや自社の受発注の流れによって組み方が変わるためです。 自社の受発注の流れに合わせて、単価一覧と変更履歴の持ち方、停止時の担当の分け方をどう組むかを確かめられます。

よくある質問

稼働率99.9%でも、改定日にシステムが止まることはありますか。

あります。
確認できたZoho CRMのSLAでは、稼働率は月全体の時間をならした割合で、計画メンテナンスは停止時間の計算から除外されています¹。
そのため、稼働率の目標が守られていても、計画メンテナンスや予定外の停止が改定日や締め時刻に重なる可能性は残ります。
他の製品の算式や除外事項は、各社の規定で確かめる必要があります。

計画メンテナンスの告知は、どの時点までに来れば改定日の準備に間に合いますか。

自社がいつ改定の準備を始めるかで決まります。
Zoho CRMのSLAでは48時間以上前に通知が送信されるとされています¹が、改定日の数日前から登録や承認を進めているなら、告知が届いた時点で作業の途中ということもあり得ます。
単価の受け取りから登録、承認、テスト注文、取引先への連絡までの期間を書き出して告知期限と比べ、足りない場合は予定の早めの共有や時期の調整に応じてもらえるかをベンダーに確かめます。

指定単価のデータ修正や不整合の調査は、保守契約の対象に含まれますか。

契約によって異なり、一概には言えません。
稼働率の取り決めは稼働を測るもので、単価データの正しさまで約束しているとは読めません。
不整合の原因調査、誤った注文データの修正、単価マスタの一括修正の代行のそれぞれについて、保守の範囲か別料金かを分けて確かめることをお勧めします。

停止中にFAXやメールで受注するとき、単価はどう確認すればよいですか。

注文の文面に単価を明記し、相手と同じ単価を見ていることを文面で残します。
参照する単価は、システムの外に保管した単価一覧から取り、一覧の書き出し日時も控えておきます。
改定日をまたぐ場合は、受注日と納品日のどちらを基準に単価を決めるかを取引先と確かめておくと、復旧後の照合で解釈が分かれにくくなります。

単価の変更履歴は、自社でどの形式で持っておけばよいですか。

取引先や担当者が変わっても読める表形式で足ります。
変更前後の単価、適用開始日、単価を示した側、協議の有無と日付、合意文書の保管場所、システムへの登録日と登録者を列にし、システムが止まっても開ける場所に置きます。
法令で定められた様式ではなく、運用上の提案です。

買い手として単価を指定する場合と、売り手として受け取る場合で、確認する項目はどう違いますか。

買い手は、発注書に単価を載せて送る購買システムが止まらないか、誤った指値が取引先へ届かないかを中心に確認します。
売り手は、受け取った単価の登録と注文への適用が止まらないか、登録の遅れで旧単価のまま受注しないかが中心です。
また、取適法の対象となる取引では、価格協議の求めに応じない、必要な説明をしないといった一方的な価格決定が禁止されています²。
対象かどうかは、取引の種類や事業者の規模などの条件によります。

1. 1　出典：Zoho「Zoho CRMの稼働時間に関するSLAと達成状況」（2026年）
2. 2　出典：中小企業庁（ミラサポplus）「下請法から中小受託取引適正化法（取適法）への改正の解説」（2026年）