AIの保守は作った会社に任せるか｜範囲と費用で決める

「納品されて半年たったら、差し戻しが目に見えて増えていました」「直してもらおうとしたら、それは保守の範囲外だと言われました」——AIを作ってもらった会社から、この2つはたいてい続けて届きます。別々の不満に見えますが、原因は同じところにあります。モデルを提供する側の公開文書には、公開したモデルの提供終了を少なくとも60日前に通知するという方針が書かれ、2026年に入ってからも通知から2か月で使えなくなった記録が並んでいます。自社が何も変えていなくても、AIの土台は入れ替わっていく。この記事では、AIの保守で決める範囲を整理し、預け先の3つを費用と速さと乗り換えの自由度で比べます。

場面：受け入れた半年後に、差し戻しが2倍になっていた

具体的な場面を1つ置いて、記事の最後まで同じ題材で追います。従業員600人規模の建材の卸で、取引先から届く注文の文書を読み取って社内の受注の仕組みに登録する部分を、外部の開発会社に作ってもらいました。月に3,500件、担当は2人。受け入れの時点では、担当が直す件数は1日に10件前後でした。

半年たって、直す件数が1日20件台になりました。担当者は自分の作業が増えたことに気づいていましたが、原因が仕組みの側にあるとは思っていませんでした。止まっていないので、不具合として報告する発想が出てこなかったのです。気づいたのは、月次の作業時間を集計した管理者でした。

開発会社に連絡すると、返ってきた答えは2つでした。1つは、読み取りに使っている土台の世代が春に切り替わっていること。もう1つは、精度が落ちたことへの対応は保守の範囲外で、調整は追加の開発になるという説明でした。契約書を見ると、保守の項目には「障害が発生した場合の復旧対応」とだけ書かれていました。

この記事では、この案件を題材に進めます。なお、受け入れの時点で合否をどう決めるかという話には踏み込みません。ここで扱うのは、受け入れたあとに動かし続けるための取り決めです。合否の基準づくりと、動かし続ける約束は、決める人も時期も違うので分けて考えます。

普通のシステムの保守と、AIの保守が違う3点

先に結論を並べます。AIを業務に入れたときの保守が難しくなる理由は、3つに絞れます。この3つを共有できていない相手と契約すると、冒頭のような食い違いが起きます。

1つ目は、自社が何も変えていないのに挙動が変わることです。土台になっているモデルは提供する側の判断で新しい世代に切り替わり、古い世代は使えなくなります。2つ目は、壊れるのではなく静かに精度が落ちること。止まらないので、監視の対象になっていなければ誰も気づきません。3つ目は、直すのに元の指示文と参照している資料の中身が要ることです。ここが渡されていないと、作った会社しか触れません。

普通のシステムの保守は、この3つがどれも当てはまりません。自社が変えなければ挙動は同じで、壊れれば止まって気づき、直すための資料は納品物に含まれています。だから保守の条文を、普通のシステムの様式から流用すると必ず穴が空きます。以下、3点をそれぞれ具体的に見ていきます。

違い1：自社が何も変えていないのに、土台の側が入れ替わる

最初の違いは、外から見えにくい割に影響が大きい点です。土台になるモデルには寿命が設定されていて、その期限は提供する側が決めています。実際の方針が公開されているので、数字で確かめられます。

ある大手のクラウドが公開している「モデルのライフサイクルとサポートポリシー」（2026年8月20日更新の版）では、一般に提供されるモデルの提供終了日が公開から18か月後に設定され、12か月後には新しい利用者が使えなくなると書かれています。提供元によっては18か月ではなく12か月の周期になるとも記されています。通知については、一般提供のモデルは提供終了の少なくとも60日前、試験版のモデルは少なくとも30日前と示されています。

同じ文書には、実務で効く記述が3つあります。代替になるモデルが選ばれて公表されるのは提供終了の約90日から120日前であること。提供終了日の延長は認められないこと。そして自動で新しい世代へ上げる設定を3通りから選べて、上げない設定にした場合は提供終了日に動作が止まることです。つまり放っておくと、ある日から処理が通らなくなります。

別の提供元の公開文書（2026年8月時点）でも同じ方針が読めます。モデルの状態を4つの言葉で示し、利用を推奨する状態、更新が止まった状態、推奨されないが動く状態、利用できない状態と分けています。公開されたモデルについては提供終了の少なくとも60日前に通知するとされ、記録を追うと2026年4月14日の通知で6月15日に提供終了、2026年6月5日の通知で8月5日に提供終了と、通知から約2か月で消えていることが分かります。

この文書には、もう1つ実務で見落とせない記述があります。細かい指定の一部が新しい世代では受け付けられず、そのまま渡すと誤りが返るという説明です。自社が1行も変えていないのに、渡し方の側が使えなくなるという形の変化も起きます。だから保守の取り決めには、世代の切り替わりに追随する作業を誰が行うかが必要になります。

違い2：壊れずに静かに落ちる。止まらないから気づかない

2つ目の違いは、気づき方の問題です。処理は最後まで通り、結果も返ってきます。ただし当たる割合だけが下がっていきます。冒頭の案件で差し戻しが2倍になっても不具合として報告されなかったのは、この性質が理由です。

落ちる原因は2種類に分かれます。1つは土台の側の変化で、これが違い1で見た世代の切り替わりです。もう1つは入ってくるデータの側の変化です。取引先が注文の書式を変える、扱う品目が増える、季節で文面の傾向が変わる。作ったときに想定した入力と、いま届いている入力がずれていくことで、同じ仕組みでも当たらなくなります。

気づく仕組みを作るときに、実務でつまずく点が1つあります。正しい答えが後から分かる業務と、分からない業務があることです。冒頭の案件では、担当者が直した記録が残るので、直した件数の推移を見れば落ちたことが分かります。ところが、人が見ない工程に入れている場合は、比べる相手が存在しません。誰も直さない工程は、落ちても記録に出ません。

だから保守の取り決めには、監視の中身まで書き込みます。何を数えるか（直した件数、差し戻しの割合、処理できなかった件数）、どの頻度で見るか、誰が見るか、どの線を下回ったら連絡するか。基準の線を先に決めておかないと、落ちたかどうかの議論が印象論になります。冒頭の案件では、1日あたりの直し件数が15件を超えた月の翌月に協議する、という線を後から追加しました。

違い3：直すには元の指示文と参照資料の中身が要る

3つ目の違いは、直す作業の性質です。普通のシステムなら、動きを変えるための材料は納品された成果物の中にあります。AIを使った仕組みでは、動きを決めている材料の一部が、成果物の外に置かれていることがあります。

動きを決めているのは主に4つです。渡している指示文。参照させている社内の資料とその範囲。土台のモデルとその世代。そして出力の形式の指定です。このうち指示文と参照資料は、作った会社が自分の手元で調整して仕上げていることが多く、納品物の一覧に入っていないまま運用が始まることが起きます。

この状態で精度が落ちると、直せるのは作った会社だけになります。発注側は中身を見られないので、直すのに何日かかるのか、いくらかかるのかを検証できません。見積の妥当さを判断する材料が、相手の手元にしかないという構図です。ここが後半で扱う囲い込みの入口になります。

保守の4区分を借りて、どこまでが保守かを言葉にする

範囲を決めるときに、ゼロから言葉を作る必要はありません。ソフトウェアの保守については日本産業規格が区分を定めていて、これを土台にすると議論が早くなります。

日本産業規格の「ソフトウェア技術 ソフトウェアライフサイクルプロセス 保守」（規格番号は JIS X 0161、2008年制定。国際規格の ISO/IEC 14764 に対応）は、保守を4つに分けています。引渡し後に発見された問題を訂正する是正保守。潜在的な障害が運用障害になる前に見つけて直す予防保守。変化した環境で使い続けられるようにする適応保守。新しい要求を満たすための改良保守です。前の2つは訂正、後の2つは改良に分類されます。

この区分をAIの案件に当てると、揉める場所がはっきり見えます。土台の世代が切り替わったことへの追随は、環境の変化に合わせる作業なので適応保守に当たります。入ってくるデータのずれで精度が落ちたときの調整は、是正保守と改良保守のどちらとも読めるため、ここが解釈の分かれ目になります。冒頭の案件で追加の開発になると言われたのは、改良の側に置いたという主張です。

保守の区分（規格の定義）	AIの案件で対応する作業	契約でよく揉める点
是正保守（引渡し後に見つかった問題の訂正）	処理が通らない、形式が崩れる、明らかな誤りが出る	止まっていない状態を問題と呼ぶかどうか
予防保守（潜在的な障害を運用障害の前に直す）	監視の指標を見て、落ちる前に指示文や参照範囲を手当てする	監視そのものが保守の範囲に入るか、別料金か
適応保守（環境の変化に合わせて使い続ける）	土台の世代の切り替わりに追随する、指定の書き方の変更に合わせる	世代の載せ替えの工数を、どちらが負担するか
改良保守（新しい要求を満たす）	扱う書式を増やす、対象の業務を広げる、精度の目標を上げる	データのずれによる調整を、改良と呼ぶか訂正と呼ぶか

表の使い方は単純です。契約の協議の場にこの4行を出して、自社の案件で起こりそうな作業を1つずつどの行に置くかを決める。置き場所が決まれば、費用の負担も自動的に決まります。決めずに済ませた行が、後で追加費用の請求として戻ってきます。

決める範囲1：精度が落ちたときの直しは、保守に入るのか

4つの範囲のうち、最初に決めるのがここです。金額への影響がいちばん大きく、そして最も書かれていない項目です。

決め方は2段構えにすると実務に乗ります。1段目は線です。受け入れの時点で測った成績を基準として、同じ手順で測り直した結果がその基準から一定の幅を下回った場合を、保守の対象とする。2段目は原因による分岐です。土台の世代の切り替わりが原因なら受注側の負担、扱う書式や品目が増えたことが原因なら発注側の負担、原因が分からない場合はまず原因を切り分ける作業までを保守に含める。

この2段構えが効くのは、原因の切り分け自体に手間がかかるからです。冒頭の案件では、直し件数が増えた原因を切り分けるだけで数日かかりました。切り分けを誰の仕事にするかを書いていないと、そこで協議が止まります。切り分けまでを保守に入れておけば、少なくとも調べることは始まります。

測り直す手順も、この項目に一緒に書きます。受け入れのときに使った材料と同じ形で測れるようにしておく、という約束です。測り直せない仕組みでは、落ちたことを示せません。冒頭の案件では受け入れ時の検証用の材料が保存されておらず、まず材料を作り直すところから始めることになりました。

決める範囲2：世代の載せ替えは、どちらの負担にするのか

2つ目は、避けられない作業の割り振りです。土台の世代は必ず切り替わります。前に見たとおり、通知から提供終了までは2か月程度、寿命そのものは12か月から18か月です。契約の期間が3年なら、期間中に2回から3回は起きます。

この作業は3つに分かれます。切り替わりの告知を受け取ること。新しい世代で同じ成績が出るかを試すこと。そして差が出た場合に指示文や参照範囲を調整することです。1つ目は誰が受け取るかを決めるだけですが、受け取る担当を決めていない案件が実務では最も多い。通知は契約の名義になっている側に届くので、名義と担当がずれていると誰も読みません。

2つ目と3つ目は工数が発生します。ここを月額に含めるか、発生時の実費にするかを選びます。実務では、試す作業は月額に含め、差が出たときの調整は上限を決めた実費にする形が扱いやすいです。試す作業は回数が読めるので固定に向き、調整は差の大きさで工数が変わるので固定に向きません。

あわせて、切り替わりを前提にした仕組みの作り方も注文しておきます。土台のモデルを指定している箇所を1か所にまとめてもらう、切り替えの前後で同じ材料を通して結果を並べる手順を残してもらう。載せ替えを前提に作られた仕組みは、載せ替えの費用が安くなります。ここは作る段階で言わないと、後から直せません。

決める範囲3：窓口と応答の期限、報告の頻度

3つ目は、普通のシステムの保守と共通する項目です。ただしAIの案件では、期限の書き方に1つ工夫が要ります。

よくある書き方は、連絡から何時間以内に応答するという形です。これは処理が止まる種類の不具合には合いますが、精度が落ちる種類には合いません。落ちたかどうかは1件では判断できず、期間で見る必要があるからです。だから期限を2種類に分けます。止まる不具合は時間で、落ちる問題は報告と協議の周期で書きます。

報告の周期は月に1回が実務では続きます。報告に載せる中身も指定しておきます。処理した件数、人が直した件数と割合、処理できなかった件数、土台の側の変更の有無、そして前月との差。数字が3か月分並ぶと、傾向として落ちているのかどうかが読めます。1か月だけの数字では、繁忙期の影響と区別できません。

窓口については、担当者の個人名ではなく組織の窓口にしてもらいます。加えて、参考にできる公的な整理もあります。デジタル庁の「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（2025年5月27日決定）では、運用の段階で、出力が期待する品質を満たしているかと、目的の外で使われていないかを定期的に検証することが挙げられています。定期的に検証するという言葉を契約に入れるなら、頻度と見る項目まで書くのが実務です。

決める範囲4：引き渡す物の一覧を、契約の時点で決める

4つ目が、後の自由度を左右する項目です。何を引き渡してもらうかを契約の時点で一覧にします。運用が始まってから頼むと、追加の作業として費用が発生します。

引き渡す物は、成果物そのものとは別に考えます。動いている仕組みの一式ではなく、動きを決めている材料と、動きを確かめる手順です。以下の一覧を協議の場に出して、1行ずつ渡す・渡さないを決めます。渡さないと決めた行があるなら、その理由を書き残します。

• 渡している指示文の現行の版と、変更の履歴（いつ何を変えたか）
• 参照させている社内の資料の一覧と、参照する範囲の設定
• 使っている土台のモデルの名称と世代、指定している箇所の場所
• 出力の形式の定義と、形式が崩れたときの扱いの決めごと
• 受け入れのときに使った検証用の材料と、その正解
• 測り直すための手順書（同じ結果を発注側が再現できる形）
• 監視で見ている指標の定義と、しきい値の設定値
• 処理を止める手順と、止めている間の代替の運用
• 人が確認する工程の設定と、直した記録の保存場所
• 外部の道具とつないでいる箇所の一覧と、その資格情報の持ち主

この10行のうち、実務でとくに落ちやすいのは5行目と6行目です。受け入れのときの材料と手順が残っていないと、精度が落ちたかどうかを示せません。示せない状態では、保守の範囲の議論そのものが成立しません。冒頭の案件がまさにこれで、範囲の話をする前に材料を作り直す作業が発生しました。

囲い込まれる形は、悪意ではなく手順の省略から生まれる

引き渡す物を決めていないと、結果として他社に移せない状態になります。この状態を囲い込みと呼びますが、相手が意図して作っているとは限りません。多くは手順を省略した副産物です。

作る側の事情も見ておきます。指示文は納品後も細かく調整され続けます。参照させる資料の範囲も、動かしながら詰めます。この作業を毎回文書にして渡すのは手間なので、手元で直して結果だけ良くする進め方が自然に選ばれます。悪意ではなく、そのほうが早いからです。

ただし結果として起きることは同じです。別の会社に見積を取ろうとした段階で、渡せる材料がありません。見積を取れないので、いまの相手の提示額が高いかどうかも判断できません。乗り換えの選択肢がないと、費用の交渉の材料も無くなります。

防ぐ方法は1つで、契約の時点で引き渡す物を決めることです。加えて、渡す頻度も決めます。運用が始まったあとに指示文を変えたら、変更の履歴とあわせて月次の報告に添える。1回だけ渡す約束は、半年後には古くなって使えません。渡し続ける約束にして初めて、乗り換えの選択肢が残ります。

3つの預け方を、費用と速さと乗り換えの自由度で比べる

ここまでの4つの範囲を、誰に預けるかで3通りに分かれます。作った会社に任せる、自社で見る、別の会社に頼む。それぞれの向き不向きを並べます。

預け方	費用の傾向	直るまでの速さ	乗り換えの自由度	向く状況
作った会社に任せる	月額は中くらい。追加の調整は割高になりやすい	速い（中身を知っている）	低い（渡す物を決めていない場合はほぼ無い）	仕組みが複雑で、中身の把握に時間がかかる
自社で見る	月額は不要。人を置く費用と育てる時間がかかる	案件による（人が育つまでは遅い）	高い	同じ形の仕組みを今後も増やす予定がある
別の会社に頼む	月額は比較で下げやすい。把握の期間の費用が別に要る	最初は遅い（把握に時間が要る）	高い（渡す物がそろっている前提）	引き渡す物がそろっていて、複数社から見積が取れる

表の3行目は、引き渡す物がそろっていることが前提です。そろっていない状態で別の会社に頼むと、把握のための作業を有償で発注することになり、当初の見積より膨らみます。乗り換えの自由度は、契約の時点で作られていて、乗り換えるときには作れません。

冒頭の案件は1行目を選びました。ただし選び方を変えました。作った会社に任せる契約を1年で結び直し、その中に引き渡す物の一覧と月次の報告を入れたのです。1年後に別の会社から見積を取れる状態を作ってから、任せるという順序です。任せる相手を変えなくても、選べる状態を作ること自体が交渉の材料になります。

費用の見方：月額固定と実費、上限の書き方

費用の形は大きく2つです。月額を固定する形と、作業が発生したときに実費で払う形。どちらが合うかは、作業の読みやすさで決まります。

読みやすい作業は固定に向きます。月次の報告、監視の指標の確認、土台の世代の切り替わりを試す作業。これらは回数が読めるので、固定に入れたほうが安くなります。読みにくい作業は実費に向きます。精度が落ちた原因の切り分け、指示文の調整、扱う書式を増やす作業。読みにくい作業を固定に押し込むと、相手は余裕を乗せて見積ります。

実費の部分には上限を書きます。書き方は2段です。1件あたりの単価の上限と、月または年での合計の上限。合計の上限だけを書くと、単価が高くても上限内なら通ってしまいます。上限に達した場合の扱いも一緒に書きます。止めるのか、協議して枠を増やすのか。書いていないと、上限に達した時点で作業が止まって業務が困ります。

もう1つ、費用の議論で抜けやすい項目があります。土台のモデルを使う費用そのものです。処理する件数に応じて動くので、保守の費用とは別に動きます。件数が2倍になったときの金額を、契約の前に2点で出してもらうと、費用の効き方が見えます。1点だけで出させると、件数が増えたときに跳ねる形に気づけません。

契約を結ぶまでの5工程

順番を置きます。多いのは、月額の金額から議論を始めてしまう形です。範囲が決まっていない状態で金額を比べても、比べているものが違うので判断できません。

この5工程で最も飛ばされるのは3番目です。測り直す手順を決める作業は、契約の交渉としては地味で、金額に直結しないように見えます。ところがこの工程を省いた案件は、精度の議論が全部印象論になります。冒頭の案件の遠回りも、ここを省いたことから始まっていました。

保守の取り決めでやりがちな失敗

実際に起きた形を並べます。どれも条文の巧拙ではなく、決めていない項目が残ったことから起きています。

• 普通のシステムの保守の様式を流用する。障害の復旧だけが書かれ、精度が落ちる場合の扱いが無い
• 土台の世代の切り替わりの通知を、受け取る担当を決めていない。契約の名義に届いて誰も読まない
• 受け入れのときの検証用の材料を残さない。落ちたことを示せず、範囲の議論が始まらない
• 指示文と参照資料の範囲を渡してもらわない。他社に見積を頼めず、いまの金額の妥当さも判断できない
• 1回だけ引き渡す約束にする。半年後には内容が古くなり、乗り換えの材料として使えない
• 実費の部分に合計の上限だけを書く。単価が高くても上限内なら通り、作業量が減らない
• 月額の金額から比較を始める。範囲が違う見積を並べて、安いほうを選んでしまう

この7つのうち、1つ目が最も広く起きています。保守の条文は前例を流用するのが普通なので、AIの案件でも同じ様式が使われます。流用そのものが悪いのではなく、3つの違いに対応する条文を足していないのが問題です。足す行は多くありません。精度が落ちた場合の扱い、世代の切り替わりの負担、引き渡す物の一覧の3つです。

• この記事で土台と呼んでいるのは、仕組みの中で文章や画像を扱っているモデルとその世代を指します
• 測り直すとは、受け入れのときと同じ材料と同じ手順で成績を出し直すことを指します
• 契約の条文の妥当さについては、自社の法務や専門家の確認を受けてください。ここでの整理は確認の観点です

よくある質問

相談の場で繰り返し出る問いを4つ、短く整理します。

作った会社に任せるほうが、結局は安く済むのではないですか

直るまでの速さでは有利です。中身を知っているので、切り分けの時間が短くなります。ただし比べる見積が取れない状態が続くと、追加の調整の単価が下がりません。任せる選択と、任せるしかない状態は別です。引き渡す物をそろえたうえで任せるなら、速さの利点だけを取れます。

精度が落ちたかどうかは、どのくらいの期間で判断すべきですか

業務の件数によりますが、1か月では繁忙期の影響と区別できないことが多いです。月次の数字を3か月並べて傾向を見る形が扱いやすいです。あわせて、土台の世代が切り替わった月には別に測り直します。切り替わりの前後は、期間ではなく事象で測るという使い分けです。

保守を自社で見るには、どんな人が必要ですか

モデルを作れる人は要りません。必要なのは、指示文と参照資料の範囲を読んで直せる人と、数字を並べて落ちたかどうかを判断できる人です。前者は業務を知っている人が近く、後者は集計ができる人が近いです。2つの役割を1人に寄せると、判断と作業が同じ人になって歯止めが効かなくなります。

複数の会社に見積を取るとき、条件をそろえるコツはありますか

保守の4区分に自社の作業を割り当てた表を、そのまま各社に渡すのが早いです。どの行を月額に含め、どの行を実費にするかを各社に書かせると、範囲の差が表の上で見えます。金額の欄だけを比べるのではなく、行の埋まり方を比べると判断できます。

まとめ

AIの保守は、不具合を直す約束ではなく精度を保ち続ける約束です。普通のシステムと違うのは3点で、自社が何も変えていないのに土台の側が入れ替わること、壊れずに静かに落ちるので止まらないまま気づけないこと、直すのに元の指示文と参照資料の中身が要ることでした。この3つに対応する条文を足していない保守の契約は、必ず解釈の食い違いを生みます。

決める範囲は4つです。精度が落ちたときの直しを保守に入れるかどうか、世代の載せ替えをどちらの負担にするか、窓口と応答の期限と報告の頻度、そして引き渡す物の一覧。範囲の議論には、日本産業規格が定めるソフトウェア保守の4区分を土台にすると早く進みます。是正、予防、適応、改良のどこに置くかが決まれば、費用の負担も決まります。

預け先は3通りで、費用と速さと乗り換えの自由度で比べます。ここで外せないのが、乗り換えの自由度は契約の時点で作られるという点です。指示文と参照資料の範囲を渡し続ける約束が無ければ、選択肢は残りません。そして記録の要約と異常の抽出はAIに任せて構いませんが、直すかどうかの判断は人が持ちます。落ちた原因が土台の側か業務の側かの切り分けは、業務を知っている人でなければ分けられないからです。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。