Next.js×AI受託の保守時間、繰越と超過を分ける4判断軸

月額保守契約を結んで最初のひと月が終わると、多くの発注者が同じところで立ち止まります。契約時間をほとんど使わなかった月は「損をしたのでは」と不安になり、逆に使い切ってしまった月は「追加で請求されるのでは」と身構える。この記事では、保守時間が余った月・超えた月それぞれで何が起きるのかを、繰越・消滅・追加請求・バッファ吸収という4つの判断軸で整理します。読み終える頃には、契約書のどこを確認すればこの不安が消えるか、具体的に分かっている状態になっているはずです。

保守時間の契約がなぜ「消化」の話になるか

月額保守契約の多くは、「月◯時間まで対応します」という時間の枠を買う形になっています。着手金や成果物ベースの契約に慣れていると、この「時間で買う」という感覚には最初なじみにくいものです。

自分が保守契約を結んだ発注者から一番よく届く質問は、契約直後ではありません。初回の消化率が出た、契約から1ヶ月後です。

「今月は6時間しか使わなかったのですが、損していますか」。同じ月に別の発注者からは「22時間使ってしまったのですが、追加料金が発生しますか」という連絡が来ることもあります。契約時間を月20時間で結んでいたとしても、消化率へのとらえ方は発注者によって正反対に振れます。

消化率という数字は、契約した瞬間から発注者の不安の種になります。

この不安の正体は、時間の契約が「使い切ることが前提」なのか「余っても構わない保険」なのかが、契約書のどこにも書かれていないことにあります。多くの見積書は「月◯時間まで対応」とだけ記載されていて、余った時間・超えた時間の扱いまでは踏み込んでいません。

自分は保守契約を結ぶとき、時給10,000円を最低基準に想定稼働時間を出し、月額に落とし込んでいます。ただしこの金額の説明だけでは、消化率が変動したときに何が起きるかまでは伝わりません。繰越の有無、超過時の精算方法という、金額の外側にあるルールこそが、実際の不安を左右します。

AIを組み込んだシステムの保守は、この消化率のブレが特に出やすい領域です。通常の画面改修は依頼の頻度が比較的読みやすい一方、LLMまわりはモデルの世代交代やAPIの仕様変更が不定期に発生します。ある月は数十分の調整だけで終わり、次の月はプロンプトの作り直しで数時間かかる、ということが起こります。だからこそ繰越と超過のルールを最初に握っておく価値は、AI組み込みのシステムでは通常の保守以上に大きくなります。

次の章から、余った月・超えた月それぞれで何を確認すればよいかを見ていきます。

使い切れなかった月：繰越か消滅か

月20時間の契約で消化が6時間だった月、多くの発注者がまず気にするのは「損したかどうか」です。ですが本当に確認すべきは、余った14時間がどこへ行くかという契約上のルールです。

保守契約の多くは、大きく2つのどちらかになっています。ひとつは、未消化分を翌月以降に持ち越す「繰越あり」。もうひとつは、月末で未消化分がリセットされる「消滅型」です。この違いは契約書の1〜2行に書かれているだけのことが多く、見落とされやすいポイントです。

繰越ありの契約は、依頼が少ない月があっても不公平感が出にくい一方、上限を設計しておかないと保守側の稼働が青天井に積み上がるリスクを抱えます。自分が繰越ありで契約するときは、「繰越できるのは翌月まで」「繰越できる上限は契約時間の50%まで」のように、期間と上限をセットで決めるようにしています。

上限のない繰越は、繰越ではなく先送りになってしまいます。上限を契約時間の50%程度にしているのは、稼働の偏りをある程度許容しつつも、青天井にならない範囲に収めるための自分なりの目安です。

消滅型の契約は、受託側からすると稼働の見通しが立てやすく、月額をやや低めに設定できる傾向があります。発注側にとっては「使わないと消える」ため、依頼を溜め込まずに小まめに出す動機になるという利点もあります。ただし、繁忙期で依頼が出せなかった月がそのまま損失として感じられやすいという弱点も持っています。

どちらが良い悪いという話ではなく、発注側の依頼ペースが安定しているか、波があるかで向き不向きが分かれます。依頼が毎月ある程度コンスタントに出せるなら消滅型でも不公平感は出にくく、逆に繁閑差が大きい事業なら繰越ありのほうが安心材料になります。

契約書やスプレッドシートを既に持っている場合は、「繰越」「翌月」「失効」「リセット」といった言葉が書かれているかどうかをまず探してみてください。何も書かれていない場合は、繰越なしとみなされているケースが多いです。曖昧なまま運用が始まっている契約は、次回更新のタイミングで一度言葉にしておくと後の認識ズレを防げます。

超過した月：追加請求かバッファ吸収か

逆に、月20時間の契約で22時間を使ってしまった月はどうなるのか。ここで発注者が一番身構えるのは「勝手に請求が増えるのでは」という不安です。

超過分の扱いも、契約でだいたい2つのどちらかに分かれます。ひとつは、超過分を時間単価または作業単価で都度追加請求する方式。もうひとつは、契約時間に一定のバッファ枠をあらかじめ乗せておき、多少の超過はそのバッファの中で吸収する方式です。

都度追加請求の方式は、超過分の精算単価さえ事前に決まっていれば、発注側にとってもシンプルです。「月20時間の契約時間、超過分は1時間◯円」という一行があるだけで、追加請求のたびに金額交渉が発生することはなくなります。単価が未定のまま超過が起きると、そのたびに見積もりのやり取りが挟まり、対応のスピードも信頼感も落ちます。

バッファ吸収の方式は、自分が継続案件でよく提案している形です。契約時間20時間に対して、実際の対応可能枠は22〜24時間程度に幅を持たせておき、ここまでは追加請求をしないという合意を先に作っておきます。多少の超過が発生しても発注側が身構えずに依頼を出せる、という心理的な効果が大きいです。

バッファは受託側の善意ではなく、契約に書かれた数字であるべきです。

実際には、この2つを組み合わせている契約も少なくありません。まずバッファ枠までは追加請求なしで吸収し、バッファを超えた分だけ精算単価で都度請求する、という二段構えです。バッファ内に収まる月がほとんどなら、追加請求が発生する月自体がまれになり、発注側の心理的な負担はさらに下がります。

どちらの方式を選ぶかは、案件のフェーズにも左右されます。要件が固まりきっていない立ち上げ期はバッファ吸収で心理的なハードルを下げ、運用が安定してきたら都度請求に寄せて実際の工数と金額を一致させていく、という移行も自然な流れです。

バッファ吸収を選ぶ場合は、バッファの幅を毎月使い切ることが常態化していないかを定期的に振り返る必要があります。バッファの中に収まっているからといって、実質的な稼働が契約時間を恒常的に超えている状態が続いているなら、それは超過ではなく契約時間そのものの見直しのサインです。

どちらの方式を選ぶにしても、超過が起きた時点で初めて話し合うのではなく、契約前にどちらの方式かを決めておくことが前提になります。ここが未定のまま走り出すと、繰越と同じく、超過のたびに認識をすり合わせる手間が発生します。

消化率を安定させる依頼側の工夫

繰越・超過のルールを決めておくことは前提として大事ですが、それとは別に、発注側の工夫で消化率そのものを安定させることもできます。ここでは自分が発注者に実際に勧めている3つの工夫を紹介します。

1つ目は、依頼をまとめて出すことです。思いついた修正をその都度小分けに依頼すると、依頼ごとに状況確認のやり取りが挟まり、同じ作業量でも消化する時間が増えやすくなります。週に1回、あるいは月の頭に依頼リストをまとめて共有するだけで、同じ内容でも消化時間を抑えられることがあります。

2つ目は、優先順位をつけて渡すことです。すべての依頼を「なるべく早く」で出されると、受託側は着手順を都度判断する必要が生まれ、そこにも時間がかかります。「今月中に必要」「余裕があれば」の2段階だけでも分けてもらえると、対応の組み立てが早くなり、結果として消化時間が読みやすくなります。

優先順位は、受託側のためではなく発注側の消化率を守るための情報です。

3つ目は、緊急対応の扱いを切り分けておくことです。サービス停止のような即日対応が必要な依頼と、通常の改修依頼を同じ枠で扱うと、緊急対応が起きた月だけ消化率が跳ね上がり、その月の他の依頼が後回しになります。緊急対応だけ別枠にしておくと、通常の消化率が安定して見えるようになります。

3つの工夫に加えて、月に一度、消化時間の実績を受託側と一緒に振り返る場を持つことも効果があります。「今月は依頼が多かったので消化が多めだった」という背景まで共有できると、翌月以降の依頼の出し方を発注側自身で調整できるようになります。振り返りは大げさな会議である必要はなく、チャットで数行のやり取りでも十分です。

これらはどれも、受託側に頼らなくても発注側だけで始められる工夫です。契約の繰越・超過のルールを握ったうえで、この3つを組み合わせておくと、消化率の月ごとのブレそのものが小さくなり、余らせた・超えたという不安に立ち返る回数自体が減っていきます。

まとめ

保守時間の消化は、余っても超えても発注者を不安にさせる数字です。繰越か消滅か、追加請求かバッファ吸収か、この2つの軸を契約前に確認しておくだけで、月々の消化率に振り回されることは大きく減ります。加えて、依頼をまとめる・優先順位をつける・緊急対応を切り分けるという発注側の工夫を組み合わせれば、消化率そのものが安定していきます。次に保守契約を結ぶ、あるいは見直すときは、この4つの判断軸を契約書のどこかで言葉にできているか、確認してみてください。

自分（kanehara32）はココナラで、Next.js×AI/LLM組み込みの受託と保守をお受けしています。今回の4つの判断軸をもとにした、既存の保守契約のセカンドオピニオンから、これから結ぶ保守契約への繰越・超過条項の設計まで対応できます。「保守契約は結んだが、繰越と超過のルールが曖昧なまま運用している」という段階のご相談も歓迎です。本記事のURLを添えていただけると、こちらの理解が早く、お話がスムーズに進みます。

Next.js受託開発のサービスはこちらに出品しています。実際にこの種の保守契約の条項設計を含む案件を受けています →

保守時間が余ったか超えたかは、発注者の使い方の問題ではなく、契約のルールが決まっていたかどうかの問題です。決まっていないなら、次の更新までに決めておけばいいだけの話です。