AI保守とは｜「AIで保守を効率化する」と「AIを組み込んだシステムを保守する」は別物

この記事は、AIを組み込んだシステムを外注して稼働させている、またはこれから稼働させる中小企業の経営者と情報システム担当者に向けたものです。はじめに用語を切り分けます。「AI 運用保守」で検索すると、性質の違う2種類の記事が混ざって出てきます。

種類	内容	この記事での扱い
AIで保守業務を効率化する	監視や障害対応にAIを使う	委託先の話として扱います
AIを組み込んだシステムを運用保守する	稼働しているAIシステムを維持する	本記事の対象

前者を探して来た場合も、次の節で誰の話なのかを整理しています。この記事の本題は後者、つまり自社が決めなければ誰も決めない部分です。

一般的な情報システムでは、運用は障害を防ぎながら日々安定して動かし続けること、保守は不具合の修正や環境変化への対応を指します。AIを組み込んだシステムでは、この保守の対象に、モデルの提供終了、出力の変化、参照しているデータの鮮度が加わります。以下はこの3つを中心に扱います。

結論

AIを組み込んだシステムは、自社が何も変えなくても提供元の側が変わります。提供元によっては、提供終了日と通知期間があらかじめ定められています。Azureの場合、提供終了日は延長されません。自社の契約先がどうなっているかを、まず確認します。

備えは複雑ではありません。呼んでいるモデル名と終了予定日を1枚に書き、月1回だけ提供元の告知を確認する。従量課金の上限と通知先を設定する。回答の元になっているデータをどの頻度で更新するか決める。障害時に見る順序を整理しておく。これで大半は防げます。

「AIで保守を効率化する」ほうは、誰の話か

この語で検索して出てくる記事の多くは、監視や障害予測にAIを使って保守作業そのものを減らす、という話を扱っています。運用を担う側が自分たちの手間を減らすための取り組みで、書いているのもシステムを預かる企業です。10〜20名の会社にとって、これは自社が実行する話ではありません。保守を委託している相手が何をしているか、という話になります。

自社の側でできることは3つに絞られます。1つ目は、委託先がそうした仕組みを持っているかを確認すること。持っているなら、障害の検知から連絡までにかかる時間が短くなる可能性があります。2つ目は、社内の問い合わせ対応のほうにAIを使うこと。これは自社で決められる範囲で、社内ヘルプデスクをAIに任せるで扱っています。3つ目が、この記事の本題である、AIを組み込んだシステムそのものを維持する側の準備です。

どちらの話か	実行するのは誰か	自社が決めること
AIで保守業務を効率化する	保守を委託している相手、または情報システム部門	委託先が持っているかを確認する。持っていないことを理由に切り替える必要はない
社内の問い合わせをAIで捌く	自社	対象の質問と、答えられなかったときの引き継ぎ先を決める
AIを組み込んだシステムを保守する	自社と開発会社	提供終了への対応、費用の上限、障害時の切り分け、契約の範囲

1行目を自社でやろうとして止まる会社があります。監視の仕組みを入れる前に、預けている相手が何を見ているかを聞くほうが早く進みます。以下は3行目、つまり自社が決めなければ誰も決めない部分を扱います。

通常のシステムとの3つの違い

従来の業務システムは、自社が何もしなければ基本的に同じ動きを続けます。AIを組み込んだシステムは違います。

違い	起きること	従来システムとの差
提供元が変える	モデルが更新され、同じ入力でも出力の傾向が変わる	自社が変更していないのに挙動が変わる
提供が終わる	使っていたモデルが提供終了になり、呼び出せなくなる	期限が外から決まっている
費用が変動する	使った量に応じて課金され、月ごとに額が変わる	定額でない

この3つは保守契約の範囲外になっていることが多く、「誰が追随するか、費用は誰が持つか」を決めていないと、ある日動かなくなったときに責任の所在が決まりません。

使っているモデルには提供終了日が設定されていることがある

最も見落とされるのがこれです。使っているモデルは、いつまでも使えるとは限りません。ライフサイクルを事前に公表している提供元があります。公表の有無そのものが確認項目です。例として、Microsoft が Azure 上で提供するモデルについては、公式ドキュメントで次のように定められています。

• 一般提供のモデルは、起動から18か月後に提供終了となる
• 立ち上げから12か月後に非推奨となり、既存の利用者のみが使える状態になる
• 提供終了の通知は、一般提供のモデルで少なくとも60日前、プレビューのモデルで少なくとも30日前に行われる
• 提供終了後、推論の要求はエラーを返す
• 提供終了日は延長されない
• Azure上で提供される一部のモデル（Anthropic・DeepSeek・Fireworks・Mistral AI の一般提供モデル）は、18か月ではなく12か月のライフサイクルに従う

重要なのは最後から2番目です。期限は延長されません。気付いたときには動かなくなっている、という事態が起こりえます。また、契約形態によっては自動的に新しいモデルへ切り替わらず、手動での移行が必要になる場合があります。

上記は Microsoft の Azure における方針であり、提供元やサービスごとに条件は異なります。自社が使っているサービスの公式ドキュメントを確認します。原文はMicrosoft Learn のライフサイクルとサポートポリシーのページで参照できます。

呼んでいるモデルを台帳に書く

終了日を管理するには、自社のシステムがどのモデルを呼んでいるかを知っている必要があります。多くの場合、発注側はこれを把握していません。開発会社に確認し、次を1枚に書きます。

記録する項目	確認先	書き方の例
使っているサービス名	開発会社	提供元の名称
呼んでいるモデルの識別名	開発会社	設定ファイルまたはコードに書かれている名前
提供終了の予定日	提供元の公式ページ	公表されていれば日付、未定なら「未公表」
非推奨になる日	同上	同上
切り替えの担当	保守契約	自社／開発会社／未定
切り替えの費用負担	保守契約	保守料に含む／別途／未定
確認日	自社	日付

下の3行が空欄なら、それが最初に埋めるべき項目です。「未定」と書いてある状態は、提供終了の通知が来た時点で交渉が始まることを意味します。通知期間は提供元によって異なります（Azureの場合は一般提供のモデルで60日前、プレビューで30日前）。自社の契約先の通知期間を調べて、台帳に書きます。そこが空欄なら、猶予が何日あるかも分からない状態です。確認する頻度は月1回で足ります。提供元の廃止予定の一覧を開き、自社のモデルが載っていないかを見るだけです。5分で終わります。

従量課金の止め方

使った量に応じた課金は、想定を超えたときに自動では止まりません。中小企業では、費用の暴走が利用停止の理由になり得ます。

導入前に確認する3点

上限額を設定できるか。設定した場合、上限に達したら止まるのか、超過して課金され続けるのか。一定額に達した時点で通知が届くか。届く場合、宛先は誰か。単位時間あたりの実行回数に制限をかけられるか。

1番目の答えが「超過して課金され続ける」である場合、上限設定は費用の歯止めになりません。その場合は2番目と3番目で備えます。通知の宛先が開発会社のみになっていることがあるため、自社の担当者にも届く設定にします。

上限に達したときの動作を決める

動作	内容	向いている業務
止める	処理を停止する	止まっても業務が回る
縮退する	AIを使わない従来の処理に切り替える	止まると業務が滞る
続ける	課金を継続し、後で精算する	止めるほうが損失が大きい

2番目を選ぶ場合、従来の処理が残っている必要があります。移行時に旧処理を完全に削除していると、この選択肢は取れません。設計時に確認します。

障害時の一次切り分け

「動かない」という連絡を受けたとき、原因は3つのどれかです。順に確認すると、開発会社へ連絡する前に切り分けられます。

確認する順序	見る場所	該当した場合
自社のネットワークや端末	他の業務システムは使えるか	自社側の問題。従来の切り分けを行う
提供元の稼働状況	提供元が公開している稼働状況のページ	提供元の障害。復旧を待つ
自社システム側の設定や不具合	上記2つに該当しない場合	開発会社へ連絡する

2番目を確認する発想が抜けやすい項目です。提供元が公開している稼働状況のページのURLを、あらかじめ台帳に書いておきます。障害時に探すところから始めると時間が失われます。提供元の障害である場合、開発会社に連絡しても復旧は早まりません。その時間帯に業務をどう回すかを、事前に決めておくほうが有効です。

保守契約に書かせること

通常の保守契約は、自社システムの不具合修正を対象としています。提供元起因の変更や障害は、範囲外になっていることが多くあります。次の4点を契約時に確認し、書面に残します。

項目	決めること
モデルの提供終了への対応	誰が切り替え作業を行うか。保守料に含むか別途か
出力の傾向が変わった場合	調整を行うか。行う場合の範囲と費用
提供元の障害	保守の対象外であることの明示と、その場合の連絡方法
料金改定への対応	誰が把握し、誰が判断するか

1番目と2番目を「別途」とする契約は珍しくありません。それ自体は妥当ですが、別途であることを知らないまま運用していると、通知が来たときに想定外の見積もりが出てきます。契約の考え方については、IPA（独立行政法人情報処理推進機構）が「情報システム・モデル取引・契約書」を公開しています。IPAの掲載ページから入手でき、責任分担を整理する下地として使えます。

保守契約がない場合

作りきりで納品され、保守契約がないまま稼働している。中小企業では珍しくない状態です。この場合、提供終了の通知が来た時点で対応できる相手がいません。先に次を確保します。動いているうちにしかできません。

呼んでいるモデルの識別名。設定ファイルまたはコードのどこに書かれているかを確認します。提供元のアカウントの名義。開発会社の名義になっていないかを見る。課金に使っているカードや口座の名義。ソースコードの現物と、その置き場所。設定を変更できる管理画面の権限も押さえます。

2番目と3番目が開発会社の名義になっている場合、自社では設定変更も解約もできません。この状態は、連絡が取れなくなった時点で手詰まりになります。稼働中に名義の移管を進めます。

仕様が分からないシステムを抱えている場合の進め方はブラックボックス化した基幹システムとどう向き合うかで扱っています。

出力品質の劣化を検知する

モデルが更新されると、同じ入力でも出力の傾向が変わることがあります。「最近うまくいかない」という声が上がってから調べるのでは、いつから変わったのかが分かりません。

簡単な方法があります。検証用の入力を5件ほど決めて固定し、月1回同じものを流して結果を保存します。過去の結果と見比べれば、変化が起きた時期が分かります。

検証用の入力は、実際の業務でよく出るものから選びます。個人情報や取引先情報を含まないものにする。結果はファイルに保存し、日付を付けます。5件で足ります。増やすと続きません。

変化が見つかった場合、対処は指示文の調整か、モデルの切り替えです。どちらも保守契約の範囲に含まれるかを、前章で確認しておきます。

参照しているデータが古くなっていないかを確認する

出力が変わる原因は、モデルの更新だけではありません。AIが参照している社内データ（料金表、FAQ、在庫、規程など）が更新されないまま、古い情報で回答を続けているケースがあります。モデルは変わっていないのに、答えが実態とずれていきます。

確認方法は単純です。価格や制度など、直近で変更があった項目を一つ選び、AIに聞いてみます。古い内容で答えた場合、参照データの更新が止まっている可能性があります。誰がいつ更新するかを、モデルの確認と同じ台帳に書いておきます。

費用の補助について

運用にかかる費用の一部が補助の対象になる場合があります。中小機構が実施している「中小企業デジタル化・AI導入支援事業」では、相談対応等のサポート費用やクラウドサービス利用料等も補助対象に含まれるとされています。詳細と最新の条件は事業の公式ページで確認します。

補助率や上限額、対象となる期間は制度によって変わります。この記事では断定せず、申請を検討する場合は必ず公募要領を確認します。

運用中に異常が起きたとき、まず必要になるのは止める手段です。止める操作の確認と、止めた後の戻し方はAIエージェントの止め方で扱っています。

契約そのものの確認事項はAIツールの費用で、値上げや解約の条件まで含めて整理しています。

よくあるご質問

モデルの提供終了はどう知りますか

提供元の告知ページと開発者向けの案内を、四半期に一度確認します。利用者向けの通知だけでは、開発者向けの変更が届かないことがあります。確認する担当と時期を決めておく必要が出てきます。

従量課金が想定を超えるのが不安です

上限額の設定と、一定額を超えたときの通知を先に有効にします。そのうえで、想定を超えた場合に誰が止めるかを決めます。通知だけを設定して、止める権限のある人が決まっていない状態が最も危険です。

保守を頼める会社が見つかりません

AI部分と、それ以外のシステム部分を分けて考えます。多くの場合、保守が難しいのはAIを呼び出している箇所の設定であり、そこは仕様が文書化されていれば引き継げます。まず文書化を依頼します。

今週着手するなら、開発会社に「どのモデルを呼んでいますか」と聞くところまでです。答えが返ってこない、あるいは連絡が取れない場合は、前述の5項目の確保を優先します。運用費用を含めた効果の測り方はAI導入の費用対効果をどう測る？で扱っています。

判断の材料が足りないと感じた場合は、お問い合わせからご相談いただけます。