AI を組み込んだ業務システムの見積もりで、最ももめやすいのが保守費用です。従来の業務システムであれば「サーバーの面倒を見て、OS やライブラリの更新に追従し、不具合があれば直す」という範囲で合意できました。ところが AI 機能、特に大規模言語モデル（LLM：大量の文章を学習し、文章の生成や分類ができる AI モデル）を使った機能は、こちらが何も触っていないのに挙動が変わるという性質を持っています。
この記事では、モデルの更新・廃止を前提にしたときに保守で何が発生するのか、それをどう見積もりに織り込むのか、そして設計側で影響を小さくする手立ては何か、を中小企業の経営者・システム担当者向けに整理します。
なぜ AI 機能は「放っておくと動かなくなる」のか
原因は大きく四つあります。
- モデルの廃止（デプリケーション）：クラウド事業者が提供する特定バージョンのモデルには、提供終了日が設定されるのが一般的です。終了すると API（外部のプログラムを呼び出す窓口）呼び出しがエラーになり、機能そのものが停止します。
- 同じ名前のモデルの中身が変わる：バージョンを固定せずに呼び出していると、提供側の更新で出力の傾向が変わることがあります。精度が上がる方向の変更でも、既存のプロンプト（AI への指示文）や後続処理の前提が崩れれば「業務上は不具合」です。
- API 仕様・料金の変更：パラメータ名の変更、新しい出力形式の追加、単価改定などが起こります。
- 入力データ側の変化：帳票レイアウトの変更、取扱商品の増加、社内用語の変化などで、以前は正しく処理できていた入力が外れ値になります。これは AI 特有というより、AI が「過去の傾向」に依存するために顕在化しやすい問題です。
重要なのは、これらが障害として分かりやすく落ちるとは限らない点です。API が止まればすぐ気づきますが、分類精度が少し下がった、要約の粒度が変わった、といった劣化は現場が我慢してしまい、数か月後に「最近このシステム使っていません」という形で発覚します。
保守で実際に発生する作業を分解する
見積もりを作るには、まず作業を具体名で並べる必要があります。代表的なものを整理します。
| 作業項目 | 想定頻度 | 内容 |
|---|---|---|
| モデル廃止への追従 | 年1回程度を想定 | 後継モデルへの切り替え、プロンプト調整、再評価、リリース |
| 精度の定点観測 | 月次 | 評価用データで出力を再計算し、基準を割っていないか確認 |
| プロンプト改修 | 随時 | 現場からの「こう出してほしい」への対応、誤出力パターンの封じ込め |
| 参照データの更新 | 随時〜月次 | 社内文書を検索して回答させる構成（RAG）での、文書追加・削除・再インデックス |
| コスト監視 | 月次 | 利用量と単価の確認、上限アラートの調整 |
| ログ・監査対応 | 随時 | 入出力ログの保全、問い合わせ時の調査 |
| 一般的なシステム保守 | 随時 | ライブラリ更新、脆弱性対応、インフラ保守 |
このうち AI 固有で費用が読みにくいのは、上から三つです。特にモデル廃止への追従は「いつ来るか分からないが、必ず来る」費用であり、ここを見積もりから落とすと、発生したときに追加費用の交渉から始めることになります。
見積もりへの入れ方 — 三層に分ける
実務的には、保守費を次の三層に分けて提示すると合意しやすくなります。
| 区分 | 性質 | 見積もりの考え方 |
|---|---|---|
| 固定保守費（月額） | 監視・定点観測・軽微な調整 | 作業時間を工数換算して月額化 |
| 従量費（月額） | API 利用料・インフラ費 | 想定処理件数×単価。上限と超過時の扱いを明記 |
| モデル移行費（都度または年次引当） | モデル切替・再評価・再リリース | 1回分の工数を算出し、年1回分を積むか都度見積もりとするかを契約で決める |
モデル移行費を見積もる際の目安として、「初期開発における AI 部分の調整・評価工数の何割か」という置き方があります。ゼロから作り直すわけではないものの、プロンプト調整と評価のやり直しは発生するためです。重要なのは正確な比率より、その費目が見積書に存在していることです。存在していれば、発生時の議論は金額の調整で済みます。
また、初期開発の見積もりに評価用データセットの作成と自動評価の仕組みを必ず含めてください。これは保守フェーズでのコストを直接下げます。評価の仕組みがないと、モデルを切り替えるたびに人手で数十件を目視確認することになり、移行のたびに費用が膨らみます。
設計側で影響を小さくする実装の勘所
「壊れる前提」で設計するとは、具体的には次のような実装を指します。
- モデル呼び出しを一か所に閉じ込める：アプリケーションのあちこちから直接 API を呼ばず、自社側に薄い中継レイヤーを一枚置きます。切り替え時の修正箇所が一か所に収まります。
- バージョンを明示的に固定する：日付やバージョン番号付きのモデル名を指定し、更新は人間が意図して行う形にします。
- プロンプトをコードから外に出す：設定ファイルや DB で管理し、変更履歴を残します。誰がいつ何を変えて精度がどうなったかを追えるようにします。
- 出力形式を構造化する：自由文ではなく JSON などの決まった形式で返させ、形式が崩れた場合は後続処理に流さず検知します。多くの提供事業者が構造化出力の機能を用意しています。
- 評価用データ（ゴールデンデータ）を育てる：正解が決まっている入出力の組を数十〜数百件用意し、変更のたびに自動で回します。現場で見つかった誤りをここに追加していくと、同じ失敗の再発を防げます。
- フォールバックと人間の確認を設計に入れる：確信度が低い、形式が崩れた、API が応答しない、といった場合に業務が止まらない経路を用意します。たとえば次のような場面です — 請求書の自動仕分けで判定が曖昧なものだけ「要確認」トレイに溜め、担当者が目視で処理する、といった設計です。
- 知識はモデルの外に置く：社内規程や商品情報をプロンプトに埋め込むのではなく、検索して渡す構成にすると、情報更新のたびにプロンプトを触らずに済みます。
契約とガバナンスで決めておくこと
技術以前に、文書で握っておくべき項目があります。
- モデル変更時の費用負担：提供事業者都合の廃止は誰の負担か。保守契約に含むのか別途見積もりか。
- 精度の表現：「正答率◯%保証」といった形は、入力データが変われば守れません。評価データセットに対する基準値と、下回ったときの対応手順として書くほうが現実的です。
- データの取り扱い：入力内容が提供事業者の学習に使われない設定になっているか、保存期間はどうか。個人情報を扱うなら個人情報保護法の観点、委託先管理の整理が必要です。
- 運用ルールの整備：国内では総務省・経済産業省によるAI 事業者ガイドラインが公表されており、開発・提供・利用の各立場での留意点が整理されています。海外向けサービスがあれば EU AI Act のような地域規制の対象可能性も確認対象になります。いずれも最新版の原文で要件を確認してください。
- 乗り換え可能性：特定事業者固有の機能にどこまで依存しているかを把握しておきます。完全な中立化はコストがかかるため、「切り替えに何人日かかるか分かっている」状態を目標にするのが現実的です。
まとめ
AI 機能の保守見積もりで押さえるべきは、次の三点です。
- モデルは必ず変わるという前提を、見積書の費目として可視化する。固定保守費・従量費・モデル移行費の三層に分け、移行費の扱いを契約時に決めておく。
- 評価の仕組みを初期開発に含める。評価用データセットと自動評価があるかどうかで、その後の移行コストは大きく変わる。
- 設計で影響範囲を絞る。呼び出しの一元化、バージョン固定、プロンプトの外出し、構造化出力、フォールバック経路。これらは「変更が起きたときに何日で戻せるか」を短くするための投資です。
AI 機能は、作った瞬間が完成形ではなく、継続的に手入れをする前提の資産です。見積もりの段階でその前提を共有できていれば、モデルの更新は想定内の作業になります。逆に共有できていないと、同じ出来事が「追加費用をめぐるトラブル」に変わります。導入を検討される際は、初期費用だけでなく3年間の総額と、そのうち AI 固有の保守にいくら割いているかを提案書で確認することをおすすめします。