AIアプリは作って終わりではない｜公開後の保守運用で発生する作業と体制の決め方

AIアプリの開発では、公開する日を目標に計画を立てることが多いでしょう。しかし、実際に業務で使い始めてから、資料の更新や回答の誤りへの対応といった作業が次々に出てきます。公開後の作業を想定していないと、担当者が決まらないまま使われなくなってしまうこともあります。

不具合の修正やサーバーの管理といった保守の作業は、一般的な業務システムでも必要です。AIアプリの場合は、それに加えてAI特有の作業が発生します。

この記事では、AIアプリの公開後に発生する主な作業と、保守運用の体制を決めるときの考え方を説明します。開発を依頼する前に読んでおくと、見積もりや契約の内容を確認しやすくなるはずです。

通常のシステム保守と共通する作業

AIアプリも、通常の業務システムと同じ保守の作業が必要です。サーバーやクラウドの環境の管理、利用しているソフトウェアの更新、障害が起きたときの調査と復旧などが含まれます。

ソフトウェアの更新は、セキュリティの面からも欠かせません。AIアプリでは、AIのサービスと接続するための部品や、資料を検索するための部品など、外部のソフトウェアを多く使う構成になりがちです。それぞれの更新情報を確認し、必要に応じて入れ替える作業が発生します。

こうした共通の作業に加えて、AIアプリには固有の作業もあります。以下で順に見ていきましょう。

参照する資料とデータの更新

社内の資料を検索して回答を作るアプリでは、資料の更新が保守の中心になります。規程が改定された、商品の価格が変わった、新しいマニュアルができたといった変化があるたびに、登録している資料を差し替える必要があります。

更新が止まれば、アプリは古い資料をもとに回答を作り続けることになるでしょう。利用者が誤りに気づくと、アプリそのものが信用されなくなるおそれもあります。

資料の更新は、内容を一番よく知る部署の担当者が行うのが理想です。そのため、専門知識がなくても資料を追加・削除できる管理画面を用意するかどうかを、開発の段階で検討しておきます。

出力の品質を定期的に確認する

AIの出力は、同じアプリでも資料や質問の内容によって品質が変わります。公開後は、利用者の質問とAIの回答の記録を定期的に見て、誤った回答や答えられなかった質問がないかを確認しましょう。

利用者が回答に「役に立った」「役に立たなかった」と評価できるボタンを設けておくと、確認すべき回答を見つけやすくなります。評価の低い回答を調べれば、資料が足りないのか、検索がうまくいっていないのか、指示文に問題があるのかが分かってきます。

開発時に作った評価用の例、つまり入力と期待する出力の組も、公開後に役立つ資料です。指示文や検索の設定を変えたときに同じ例で試せば、改善のつもりの変更で別の質問の回答が悪くなっていないかを確かめられます。

AIモデルの更新や提供終了への対応

AIアプリは、外部の事業者が提供するAIのモデルを使って動くことが多いです。モデルは提供元の方針によって新しい版が出たり、古い版の提供が終了したりすることがあります。提供の条件は事業者ごとに異なり、変わることもあるため、利用中のサービスの公式情報を確認してください。

新しいモデルに切り替えると、同じ指示文でも出力の傾向が変わる場合があります。切り替えの前に評価用の例で試し、回答の品質や長さ、応答時間に問題がないかを確かめる作業が必要です。

特定のモデルに強く依存した作りになっていると、切り替えのたびに大きな修正が発生します。開発の段階で、モデルを入れ替えやすい構成にしておくかどうかも相談しておきたい点です。モデルを選ぶ観点は、業務で使うAIモデルの選び方で整理しています。

利用料と権限の見直し

AIのサービスの利用料は使った量に応じてかかる仕組みが多く、利用者や入力する文章が増えれば費用も増える点に注意が必要です。月ごとの利用量を確認し、想定より増えていれば原因を調べる作業も保守に含まれます。費用の考え方はAI導入の費用構成もご覧ください。

利用者の権限も、定期的に見直す必要があります。異動や退職があったときに、アプリの利用権限や閲覧できる資料の範囲を変更しなければ、見るべきでない人が情報にアクセスできる状態が残ってしまいます。

保守運用の体制を決める

ここまでの作業を、社内と開発会社のどちらが担当するかを決めておくことが、公開後の運用を続けるうえで欠かせません。分担の一例を表にまとめました。

この分担は会社の体制によって変わります。社内に情報システムの担当者がいない場合は、開発会社に任せる範囲が広くなるでしょう。

開発会社と保守の契約を結ぶ場合は、対応する作業の範囲、問い合わせの受付方法、障害時の連絡の流れを確認しておくと安心です。改善や機能の追加が保守の範囲に含まれるのか、別の見積もりになるのかも、事前に確かめておくべき点といえます。

誤った回答が見つかった日の対応例

架空の社内FAQアプリで、廃止した申請方法を案内していると社員から連絡が入ったとします。まず運用窓口が、質問、回答、表示された出典、発生時刻を確認します。利用者に同じ質問を何度も試してもらうより、記録から原因を調べられるようにしておくと負担を減らせます。

次に、業務の責任者が誤案内の影響を判断します。対象のFAQだけを停止すればよいのか、ほかの回答にも同じ原因があるのかを確認します。全機能を止める場合と、該当資料を検索対象から外す場合を、影響に応じて選びます。

開発担当者は、元資料、検索された文章、回答生成の順に調査します。元資料が古いなら資料を更新します。最新版があるのに旧版を検索しているなら、検索対象の整理や更新処理を確認します。資料は正しいのに回答が違うなら、指示や出力確認を見直します。

復旧の確認では、報告された質問だけでなく、言い方を変えた質問と関連する手順も試します。修正した箇所だけが通れば再開してよい、と決めると別の誤りを見落とすためです。対応後は利用者へ正しい参照先を示し、原因と対処を運用記録へ残します。

定例点検の項目を担当ごとに分ける

点検の頻度は、扱う情報の変化と業務への影響から決めます。次は社内FAQを運用する場合の一例であり、すべてのアプリに同じ頻度が必要という意味ではありません。

作業項目を並べるだけでなく、完了した証拠を決めます。資料更新なら登録日時と確認した質問、モデル変更なら比較結果と切り戻し方法を残します。担当者が不在でも、別の人が状況を把握できる形が望ましいでしょう。

更新を公開する前に戻し方を用意する

設定変更では、以前の指示文、対象資料の版、モデルの設定を記録してから試します。変更後に誤回答が増えたとき、何を戻せばよいか分からなければ復旧に時間がかかります。資料の誤登録とモデル変更を同時に行うと原因を切り分けにくいため、影響を確認しながら進めます。

ただし、提供終了したモデルなど、元へ戻せない変更もあります。その場合は、別のモデルへの切り替えや、AIを使わない受付手順を事前に用意します。「元へ戻す」という文言だけでなく、実際に実行できる操作かを確認してください。

保守契約で曖昧になりやすい境界

障害対応と改善開発は分けて確認します。決めた仕様どおり動かない不具合と、新しい種類の資料にも対応したいという要望では、必要な作業が違います。問い合わせ窓口に連絡できることと、休日にも復旧作業を行うことも同じではありません。

契約前には、受付時間、初動の目安、社内で判断する範囲、外部サービスの障害時の対応を具体的に確認します。問い合わせ履歴や評価資料を契約終了後に引き継げるかも、長く運用するための確認項目です。費用と作業の範囲が対応していれば、公開後の追加作業について話し合いやすくなります。

まとめ

AIアプリの公開後には、通常のシステム保守に加えて、資料の更新、出力の品質確認、AIモデルの更新への対応、利用料と権限の見直しといった作業が発生します。これらの作業の担当者を決めないまま公開すると、回答の質が下がり、アプリが使われなくなるおそれもあるでしょう。

開発の計画を立てる段階で、公開後に誰が何をするかをあわせて決めておきましょう。

e-Grantsでは、AIアプリケーションの課題の整理から設計・開発に加えて、公開後の保守運用まで対応しています。保守運用まで含めて相談したい方は、AIアプリケーション受託開発のページをご覧ください。