Next.js保守運用の費用と契約｜月額固定・チケット制の確認項目

Next.jsで作った業務システムを納品してもらった後、「保守費用って結局いくら払い続けることになるのか」がはっきりしないまま契約してしまい、後から見積もりを見て驚いた——そんな声を、開発を検討している経営者・情シス担当の方からよく聞きます。初期の開発費用は複数社から見積もりを取って比較しても、保守費用は「月額○万円〜」という一言で済まされ、何にいくらかかっているのか分からないまま契約するケースが少なくありません。

先に、要点をまとめます。

• 当社の開発費用は1時間11,000円（税込）が基準です。ヒアリング後、ご依頼に応じて、要件定義・現状調査、相談内容のすり合わせ・仕様合意、開発・移行・公開準備、テスト・受入確認、不確実な作業へのバッファを当社で見積もり、概算をご案内します。お客様が開発工数を推測する必要はありません。
• 保守の範囲・対応時間・体制・費用は契約によります。開発費に対する固定率では算定しません。
• 契約形態は月額固定制・従量課金制・チケット制の3種類があり、それぞれ向き・不向きが分かれます

なお、Next.jsの開発費用そのものについてはNext.js受託開発の相場と見積書の内訳3点の読み方で扱っています。本記事は「作った後、動かし続けるためにいくらかかるか」という保守運用のコストに絞って解説します。

保守費用は何によって決まりますか？

保守の対象、対応時間、待機の有無、障害調査・パッチ対応・機能追加の分担によって変わります。当社の保守体制と費用は契約によるため、一般的な月額レンジをそのまま当社の料金として提示しません。

保守費用には具体的に何が含まれている？

保守費用の中身は大きく分けて「障害対応」「監視」「問い合わせ対応」「軽微な改修」「インフラ保守」の5つです。

GeNEE社の解説によると、保守契約に含まれる業務は次のように整理できます。

• 障害対応・トラブルシューティング: システムが停止した、エラーが出る、といった問題が発生したときの調査と復旧作業
• システム監視: サーバーやアプリケーションの稼働状況を継続的に確認し、異常があればアラートを検知する
• 問い合わせ対応: 現場の担当者からの「この操作方法が分からない」「この画面はどう使うのか」といった軽微なサポート
• 軽微な改修: 表示テキストの修正、選択肢の追加といった、設計変更を伴わない小さな改修
• インフラ保守: サーバーのバージョンアップ、セキュリティパッチの適用、証明書の更新など基盤側の維持管理

ここで見落とされがちなのが、保守契約に「機能追加」は基本的に含まれないという点です。保守契約はあくまで「今動いているものを、今の状態のまま安定して動かし続ける」ための契約であり、業務フローの変更に伴う新機能の開発は、別途見積もりが必要な追加開発として扱われるのが一般的です。契約前に「どこまでが保守で、どこからが追加開発か」の線引きを確認しておかないと、いざ改修を依頼したときに想定外の追加費用が発生し、担当者間の認識ズレにつながります。

保守の契約形態はどう選ぶべき？

予算を安定させたいなら月額固定制、対応が不定期で読みにくいならチケット制や従量課金制が向いています。

保守契約の形態は、主に3つに分類されます。

FUNBREW社の解説でも触れられている通り、月額固定制は「毎月一定の稼働を前提にした安定運用」に向く一方で、使わない月も費用が発生するという裏返しのデメリットがあります。逆に従量課金制は、実作業に応じた支払いになる分、年間の総コストが事前に読みにくいという難点があります。

判断のポイントは、自社のシステムが「日常的に何らかの対応が発生する運用フェーズ」にあるのか、「一度安定稼働に入れば、ほとんど手がかからないフェーズ」にあるのかです。リリース直後で不具合の洗い出しがまだ続いている時期は月額固定制、リリースから半年〜1年が経ち安定稼働に入った後はチケット制や従量課金制に切り替える、という段階的な選び方も現実的です。

保守と機能追加、どこで線引きすべき？

「今の仕様のまま動かし続ける」のが保守、「業務フローや画面構成そのものを変える」のが機能追加、という線引きが基本です。

この線引きが曖昧なまま契約すると、後になって「これは保守の範囲内でやってもらえると思っていた」「いや、これは追加開発の見積もりが必要です」という食い違いが起きやすくなります。特に、社内の担当者が変わったタイミングで、過去の契約内容の認識が引き継がれずにトラブルになるケースは珍しくありません。

契約時に確認しておきたいのは、次のような具体的な線引きの例です。

• テキストや金額の表示単位を修正する → 保守の範囲内であることが多い
• 新しい入力項目やステータスを追加する → 機能追加として別見積もりになることが多い
• エラーで止まった処理を復旧する → 保守の範囲内
• 承認フローそのものを組み替える → 機能追加として別見積もりになることが多い

境界線上のケースも当然出てきます。「軽微な改修」とみなされる範囲がどこまでかは開発会社によって基準が異なるため、契約前に具体例をいくつか挙げて、それぞれ保守内か追加開発かを確認しておくと、後々のトラブルを減らせます。

ここで一つ、後半で回収する話を挟んでおきます。保守費用の相場は上で紹介した通りですが、この相場感がそのまま自社に当てはまるとは限らない一つの理由があります。それは、システムの作られ方によって保守にかかる手間そのものが変わってくるという点です。詳しくは次のセクションで説明します。

Next.js特有の保守項目には何がある？

Next.jsやフレームワーク自体のバージョンアップ対応、ホスティング基盤（Vercel/AWS/Firebase App Hosting等）の運用が、Next.js特有の保守項目として発生します。

一般的な業務システムの保守項目に加えて、Next.jsで構築したシステムには次のような保守作業が発生します。

• フレームワークのバージョンアップ対応: Next.jsは継続的にマイナーバージョンがリリースされ、セキュリティパッチや破壊的変更を含むアップデートが行われることがあります。放置すると、依存ライブラリとの互換性問題や脆弱性リスクが蓄積します
• ホスティング基盤の運用: Vercel・AWS・Firebase App Hostingなど、選択したホスティング環境の設定変更、リソース使用量に応じたプラン見直し
• 依存パッケージの脆弱性対応: npm audit等で検出される依存ライブラリの脆弱性への対応。放置期間が長いほど、まとめて対応するときの工数が膨らみやすくなります

この観点は、中小企業のNext.jsフルスクラッチで、セキュリティをどう担保するかで扱ったセキュリティ対策とも重なります。セキュリティパッチの適用を怠ると、脆弱性が公表されてから実際に悪用されるまでの期間が短くなっている昨今、保守を軽視することが直接的なリスクにつながります。

AI駆動開発は保守費用にどう影響する？

軽微な改修や既存コードの調査にかかる時間がAIコーディング支援で短縮される分、同じ保守内容でも工数ベースの費用が抑えられる余地があります。

保守の費用は契約範囲を揃えて比較します。保守費用の多くは、実際には人件費（エンジニアの作業時間）に紐づいています。障害対応も軽微な改修も、対応するエンジニアが状況を把握し、原因を特定し、修正する時間がベースになって費用が積み上がる構造です。

Claude CodeのようなAIコーディング支援ツールを保守作業に組み込むと、次のような場面で作業時間を短縮できます。

• 既存コードの調査: 「このエラーはどのファイルのどの処理で起きているか」をAIに一次調査させ、人間は原因の特定と修正方針の判断に集中する
• 軽微な改修の実装: テキスト修正や表示条件の変更のような、パターン化しやすい改修はAIに実装させ、人間がレビューして反映する
• 依存パッケージの更新確認: バージョンアップに伴う変更点の洗い出しをAIに任せ、影響範囲の最終判断を人間が行う

ただし、AIに任せられるのはあくまで「パターン化された作業」の範囲です。業務ロジックの根幹に関わる判断（金額計算のルール変更、権限設計の見直し等）は、引き続き人間が実データを見ながら判断する必要があります。この役割分担——パターン化された作業はAI、業務仕様の最終判断は人——は、PHPリプレイス費用と手順の記事で紹介したリプレイス時の考え方と同じ構図です。開発時にAI駆動開発を前提に設計されたシステムは、保守フェーズでも同じ効率化の恩恵を受けやすいという意味で、開発会社を選ぶ段階から保守コストを見据えておく価値があります。

保守費用が想定より膨らみやすいパターンは何か？

「保守範囲の未定義」「ドキュメント不在」「担当者の属人化」の3つが、保守費用が後から膨らむ典型パターンです。

• 保守範囲を契約時に明文化していない: 上で説明した「保守と機能追加の線引き」が曖昧なまま契約すると、依頼のたびに「これは追加費用です」と言われ、当初想定していた月額を上回るケースが発生します
• 仕様書やドキュメントが整備されていない: システムの仕様がコードにしか残っていないと、対応する担当者が変わるたびに調査コストが発生し、同じ問い合わせでも対応に時間がかかるようになります
• 保守担当者が固定の1人に依存している: その担当者が離脱すると、後任が仕様を把握するまでの引き継ぎ期間、対応スピードが大きく落ちます。開発会社を選ぶ際は、チーム体制で対応しているか、属人化していないかも確認しておきたいポイントです

これらは、いずれも契約前の段階で防げるリスクです。特に「保守範囲の明文化」は、見積書や契約書に具体例として書き込んでもらうことで、後からの認識ズレをかなり減らせます。

保守契約前にどこまで確認しておくべきか？

契約書や見積書に「保守範囲の具体例」「対応時間の目安」「緊急時の連絡フロー」の3点が明記されているかを、契約前に必ず確認してください。

保守費用の妥当性は、金額の大小だけでは判断できません。同じ月額10万円でも、対応内容が具体的に決まっている契約と、「何かあれば対応します」程度の曖昧な契約とでは、いざというときの安心感がまったく違います。契約前のチェックポイントを整理すると次の通りです。

• 保守範囲の具体例が書面にあるか: 「軽微な改修」のような抽象的な表現だけでなく、「テキスト修正は保守範囲内」「新規画面の追加は別見積もり」といった具体例が契約書または見積書に記載されているか
• 対応時間の目安があるか: 問い合わせを送ってから初動対応までにどのくらいの時間がかかるか（当日中、翌営業日中等）が示されているか。特に外部公開している業務システムでは、障害発生時の対応スピードが業務影響に直結します
• 緊急時の連絡フローが決まっているか: 夜間・休日にシステムが停止した場合、誰にどう連絡すればよいかが事前に共有されているか
• 契約の見直しタイミングが決まっているか: システムの利用状況が変わったとき（利用者数の増加、機能追加等）に、保守内容や費用を見直すタイミングが契約に組み込まれているか

これらは、契約後に追加交渉するよりも、発注前の見積もり比較の段階で複数社に同じ質問を投げて回答を比べたほうが、条件の良し悪しが見えやすくなります。開発費用だけで比較して決めてしまうと、保守フェーズに入ってから「思っていた対応と違う」というギャップに気づくことになりかねません。

まとめ：この記事で持ち帰れること

この記事を読むことで、次の2点が判断できるようになります。

• 自社のシステム規模に対して、月額保守費用がどのくらいの水準であれば妥当と言えるかの目安
• 契約前に確認しておくべき「保守と機能追加の線引き」「契約形態の選び方」の具体的なチェックポイント

保守費用は、開発費用のように複数社を比較検討する機会が少なく、契約したまま何年も見直されないケースが多いコストです。まずは現在契約している保守内容が、上で紹介した5つの項目（障害対応・監視・問い合わせ対応・軽微な改修・インフラ保守）のうちどこまでをカバーしているか、契約書や見積書を一度見返してみることをおすすめします。

保守費用の妥当性や、これから始めるNext.js開発の保守体制について相談したい方は、15分のカジュアル相談からお気軽にご相談ください（要件が固まっていなくても大丈夫です／営業はしません）。

すでにNext.js開発を具体的に検討している方は、Next.js受託開発の相場と見積書の内訳3点の読み方、セキュリティ対策まで含めた保守体制を検討したい方は中小企業のNext.jsフルスクラッチで、セキュリティをどう担保するかもあわせてご覧ください。