AI開発 納品後の保守契約｜決める6項目と費用の目安

結論：納品後の保守で決めるのは「誰が・いくらで・どこまで」

AI システムの納品後の保守契約で決めることは、突き詰めると「誰が・いくらで・どこまで面倒を見るのか」の3点です。通常のシステム保守と決定的に違うのは、使っているモデルそのものが、貴社の都合と関係なく提供終了になる点にあります。Anthropic は公開モデルについて「提供終了の最短60日前に通知する」と方針を明記しており、実際に Claude Opus 4.1 は2026年6月5日の告知から同年8月5日に提供終了しました（Anthropic 公式のモデル提供終了ページ）。

つまり契約書に「モデルが止まったときに誰が動き、その費用を誰が持つか」が書かれていないと、2か月で判断と支払いを迫られます。ここを空欄にしたまま検収を終えた案件が、半年後に「これは保守の範囲か、追加開発か」で止まるのが典型的な形です。

この記事は検収後の保守・運用フェーズだけを扱います。開発委託契約そのものの論点はAI開発の契約で揉めやすい注意点に分けて整理しています。

AI の保守が通常のシステム保守と違う4点

従来のシステム保守は「作ったものは変わらない」前提で組まれています。障害が出たら直す、OS やライブラリが上がったら追随する、という設計です。AI システムはこの前提が崩れており、放置すると何もしていないのに壊れます。ここが保守費用の根拠になる部分です。

モデルの提供終了と API 仕様変更への追随

各社とも旧モデルを恒久的には維持しません。OpenAI は一般提供モデルについて「最低6か月前」、特定用途の派生モデルは「最低3か月前」、プレビュー版は「2週間程度」の予告を目安として公表しています（OpenAI Deprecations）。予告があること自体は誠実な運用ですが、予告に気づく人が貴社側にいなければ、ある朝いきなり業務が止まります。

やることは「監視して、差し替えて、出力を再検証する」の3つです。差し替えは API のモデル名を1行変えれば済む一方、出力の傾向は変わるため、プロンプトの調整と回帰テストが必ず発生します。監視の当番と検証の工数を保守契約に含めるのか、都度見積りにするのかを最初に決めてください。手順はAIモデルの提供終了に企業がどう備えるかで扱っています。移行そのものにかかる工数の見積り方も、あわせて確認しておくと予算が組みやすくなります。

精度劣化（データドリフト）の監視

入力されるデータや業務の言い回しが変われば、同じモデル・同じプロンプトでも精度は落ちます。障害と違ってアラートが鳴らないため、現場が「最近あまり当たらない」と感じた頃には数か月経っているのが普通です。月次で何件かをサンプリングして正解率を記録するだけでも、劣化に気づく速度は大きく変わります。

契約側で決めるのは、この計測を誰がやるか、どの数値を割り込んだら調査に入るか、調査の結果として必要になった調整は保守費に含むのか別見積りか、の3点です。「精度を保証する」と書かせるのは現実的ではなく、開発会社も飲めません。保証ではなく計測と報告の義務として書くのが実務的です。

プロンプトと RAG 索引の更新

社内文書を検索して答えるいわゆる RAG 構成では、参照元の文書が更新されれば索引も作り直す必要があります。規程が改訂されたのに索引が古いままだと、AI は堂々と旧ルールを答えます。索引の再作成を定期実行にするのか、文書更新のたびに依頼するのかを運用フローとして決め、その頻度を保守契約の対応範囲に書き込んでください。

API の従量課金は誰が払うのか

ここが最も揉めます。AI の利用料は使った分だけかかるため、保守費とは別に毎月の変動費が発生します。整理の仕方は主に3通りです。

• 貴社が API アカウントを持ち、直接支払う：使用量が見えて中間マージンもかからない。アカウント管理と支払い手続きは貴社側の仕事になる。
• 開発会社が立て替え、実費を請求する：手間は減るが、明細の開示範囲を決めておかないと金額の根拠が見えない。
• 定額に含める：予算は読みやすいが、想定を超えた利用が続くと必ず条件見直しの話になる。上限利用量を明記するのが前提。

どの形でも、想定利用量と、それを超えたときにどうするかを数字で書いておいてください。「使いすぎたので止めました」も「黙って請求が倍になっていた」も、書いていなかったから起きます。

保守契約の3つの型と、向いている条件

保守契約の形は大きく3つです。どれが優れているという話ではなく、止まったときに困る度合いで選びます。対外サービスに組み込んでいるのにスポット対応にすると復旧が待てず、社内の一部だけが使う仕組みに SLA 付き運用を付けると費用が過剰になります。

迷ったら、月額固定から始めて実績を見て調整するのが無難です。1年運用すれば、実際に何件の依頼が来て何時間かかったかが分かるので、そこで枠を見直せます。

保守費用の置き方：月額固定と従量をどこで割るか

先に正直に書きますと、AI システムの保守費について、相場と言い切れる公的な統計は確認できませんでした。システム開発一般では「初期開発費の年15〜20%程度」を保守料率として提示する開発会社が多く見られますが、これは各社が自社サイトで示している目安であり、公的機関が調査した数値ではありません。相場として鵜呑みにせず、内訳の妥当性で判断してください。見積書の読み方はAI開発の見積書の内訳の見方で解説しています。

判断の軸は率ではなく、その金額で毎月何をするのかが書いてあるかです。「保守費 月額15万円」の一行だけの見積りは、金額の高低以前に検証できません。次の3つに分けて出してもらうと比較できます。

1. 月額固定に含める作業：稼働監視、問い合わせ窓口、軽微な修正、モデル提供終了の情報監視、月次レポート。それぞれ何時間・何件までかを書く。
2. 実費で通すもの：AI の API 利用料、クラウドの利用料、外部サービスのライセンス。明細の開示方法も一緒に決める。
3. 都度見積りにするもの：機能追加、モデル移行に伴う再検証、大幅なプロンプト作り直し。単価と、見積りを出す期限を決めておく。

この3分割ができていれば、来年「高い」と感じたときに、どこを削るかの議論ができます。分割されていない契約は、値下げ交渉が「全部やめる」しか選択肢のない話になりがちです。

契約書で必ず決める6項目

経済産業省は2025年2月18日に「AIの利用・開発に関する契約チェックリスト」を公表しており、インプット37項目・アウトプット29項目という形で、AI を利用する側が確認すべき論点を整理しています（経済産業省の公表資料）。以下は、そのうち納品後の保守フェーズに関わるものを、発注側の実務に落として6つに絞ったものです。

1. 対応範囲：障害対応・軽微な修正・問い合わせ対応・監視のどこまでを含むか。「軽微」の定義（例：1件あたり何時間まで）も数字で書く。
2. SLA と応答時間：受付時間帯、一次応答までの時間、復旧の目標時間。目標を外したときにどうするか（次月費用の調整など）まで書く。
3. 再学習・調整と、改修の線引き：精度が落ちたときの調整は保守に含むのか、追加開発なのか。判断基準を先に決める。
4. モデル切替時の費用負担：提供元の都合による提供終了は、どちらの責任でもありません。だからこそ、誰が作業し誰が費用を持つかを最初に決めます。工数上限付きで保守に含める形が、実務では現実的です。
5. ソースコード・プロンプト・学習データの権利：納品物にプロンプトや設定ファイルが含まれるか、貴社が第三者に保守を引き継げるか。ここが曖昧だと、実質的にその会社から離れられなくなります。
6. 解約と引き継ぎ：解約予告期間、引き継ぎ資料の範囲（構成図・環境情報・運用手順）、引き継ぎ作業の費用。契約終了時に何をもらえるかを、契約開始時に書いておく。

特に5と6は、機嫌よく進んでいる時期には話題にしにくい項目です。だからこそ、力関係がフラットな契約時点で書いておく価値があります。

なお、システム保守・運用の契約書そのものの雛形が必要であれば、IPA が「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）で受託開発と保守運用のモデル契約書を公開しており、無償で参照できます（IPA のモデル契約書ページ）。AI 固有の論点は含まれないため、上の6項目を足す形で使うことになります。

私たちも、AI の開発から納品後の運用までを同じ体制で見る形で独自AI開発サポートを行っております。社内に運用の担い手を置きにくい場合の選択肢のひとつとして、参考程度にご覧いただければ幸いです。

揉めやすい3つの実例と、入れておく一文

実際に止まりやすいのは、技術の難所ではなく言葉の解釈です。よくある3つを挙げます。

「精度が落ちた」は保守か、追加開発か

発注側は「動かなくなったのだから直してほしい」と考え、開発側は「納品時の仕様は満たしている。入力データが変わったのだから追加開発だ」と考えます。どちらも筋が通っているため、決着がつきません。納品時の精度を数値で記録し、それを下回った場合の調査までは保守に含むと書けば、少なくとも調査までは自動的に動きます。

例：納品時に測定した正解率を基準値とし、月次計測で基準値を10ポイント以上下回った場合、受託者は原因調査と報告までを本契約の範囲で行う。改修の要否と費用は報告後に協議する。

モデル提供終了の対応費を誰が持つか

「提供元の都合なので当社の責任ではない」は開発側の言い分として正しく、「使えるものを納品する契約だったはずだ」も発注側として正しい。責任論では決まらないので、費用の話に置き換えます。年間◯時間までは保守に含み、超過分は時間単価で精算するという上限付きの折半が、双方が飲みやすい形です。

API 利用料の想定超過

利用が広がるのは良いことですが、請求が想定の3倍になれば必ず問題になります。月間の想定利用量と、超過が見込まれた時点で通知する義務を書いておけば、事故ではなく相談になります。社内に運用の担当者を置けていない場合の進め方は社内AIの運用担当がいない会社の進め方にまとめました。

まとめ：検収前に、保守契約の骨格を決める

納品後の保守契約は、検収が終わってから相談すると必ず立場が弱くなります。開発の見積りを受け取る段階で、保守の型・月額の内訳・モデル切替時の負担・解約時の引き継ぎまでを同時に聞くのが最も安く済む進め方です。開発会社にとっても、後から揉めるより先に握れる方が助かります。

すでに納品を受けていて保守契約が曖昧なままの場合も、更新のタイミングで6項目を埋め直せば間に合います。全部を一度に整えようとせず、まずは「モデルが止まったとき誰が動くか」の1点だけでも書面にしてください。