内製したAIエージェントの運用・保守｜壊れたときに誰が直すかと、外部支援を外すタイミング

運用で困るのは、直し方よりも誰が受けるか

社内でAIエージェントを作って業務に載せたあと、最初に問題になるのは技術的な難しさではないことが多いです。「昨日まで通っていたのに、今日は空欄で返ってくる」と現場から声が上がったとき、それを誰が受けて、どこまで自分で見て、どこから先へ渡すのかが決まっていない状態が続きます。

決まっていないと、作った本人へ直接連絡が飛びます。作った人が別の業務に移っていたり、休んでいたりすると、その日の処理は手作業へ戻ります。数日それが続くと、現場は元のやり方へ戻り、作ったものは使われなくなります。

止まらないようにするために必要なのは、常駐できる担当者ではありません。起きうる不具合を種類ごとに分け、種類ごとに一次対応を持つ人を決めておくことです。種類が分かれていれば、対応できる人も分かれます。どこまでを社内で持ち、どこから外部の支援を受けるかという全体の線引きは生成AI・AIエージェントの内製化とはにまとめています。

不具合を3つに分ける

現場から上がる症状は多様に見えますが、対応する人という観点で見ると、多くは次の3つに収まります。

起きること	見分け方	一次対応を持つ人
出力の中身が業務の期待とずれる	処理は最後まで通っている。エラーは出ず、値の入り方だけが違う	その業務を日常的に回している人
つないでいる先の仕様が変わった	特定の連携部分だけが失敗する。取り込んだ項目が空になる、項目名が変わっている	技術面を引き受けている人
権限やアカウントで止まる	実行そのものが始まらない。認証や許可に関する表示が出る、特定の人だけ動かない	情報システム部門

1つ目は、業務側の言葉で直せる範囲です。新しい書式の書類が届くようになった、例外の扱いが変わった、判定してほしい条件が増えた。原因は業務の変化にあり、技術の問題ではありません。指示文や判定の条件を書き足せば戻ります。ここを技術担当へ回すと、そのつど業務内容を説明する往復が発生し、待ち時間が伸びます。

2つ目は、相手側の都合で起きます。連携している会計システムやチャットツールの更新で、項目名や返ってくる形式が変わることがあります。予告される場合もありますが、気づくのは動かなくなってからということも珍しくありません。ここは業務側では直せないため、技術面を引き受けている人が一次で受けます。

3つ目は、AIとは直接関係のない領域です。アカウントの有効期限、利用しているサービスの契約変更、共有フォルダの権限設定。異動や退職の手続きに連動して起きることが多く、情報システム部門の既存の手順に載せられます。

症状を3つに切り分けておくと、一次対応を持つ人が決まり、作った本人へ連絡が集中しなくなる。

受付の窓口と渡し先を1枚に書いておく

分類だけを決めても、現場は自分の症状がどれに当たるか判断できません。運用に載せるときは、次の3点を1枚にまとめて業務側から見える場所に置きます。

連絡先 … 誰に、どの手段で伝えるか。個人名ではなくチャットのチャンネルや共有のメールアドレスにする
止めるかどうかの目安 … その日の処理を手作業へ戻す条件。判断を現場に委ねると人によってばらつく
渡し先 … 一次対応で直らなかったときに誰へ回すか。外部の支援を受けている場合は、その窓口と受付時間も書く

個人名で書かないのは、異動や休みで宛先が消えるのを避けるためです。チャンネルにしておけば、担当が代わっても連絡先は変わりません。

止めるかどうかの目安は、業務の性質で決まります。件数が多く1件あたりの影響が小さい処理なら、誤りが混ざっても後から直せるため止めない判断もできます。締切や社外への提出が絡む処理は、疑わしい時点で止めて手作業へ戻す方が安全です。

月次で点検する項目

不具合として声が上がるのは、動かなくなったものだけです。動いてはいるが少しずつずれているものは、誰も報告しません。月に1回、次の項目を見る時間を取ります。

点検する対象	見る条件	外れていたときにすること
人が直した割合	出力をそのまま使えた件数と、手を入れた件数の比率が前月から動いていないか	直した内容を10件ほど読み、同じ種類の修正が続いていないか調べる
処理できずに止まった件数	対象外として弾かれた件数が増えていないか	弾かれたものの中身を見て、業務側の変化か接続の問題かを切り分ける
つないでいる先の変更予告	利用しているサービスの更新情報に、項目や仕様の変更が出ていないか	変更日を控え、影響のありそうな連携を事前に確認する
アカウントと権限	使っているアカウントの有効期限、異動者の権限が残っていないか	情報システム部門の棚卸しの手順に合流させる
手順書と設定の記載	直近1か月の変更が手順書に反映されているか	直した本人が、その場で追記する運用に戻す

人が直した割合は、最も早く変化が出る項目です。出力が使える水準にあるかどうかを最初に決めた基準と合わせて見ます。合格ラインの決め方と測り方は AIエージェントの精度をどう評価するかで扱っています。

手順書の点検を入れているのは、運用のなかで最も抜けやすいためです。直した本人はその場で内容を覚えているので、書かなくても困りません。困るのは半年後に別の人が見たときです。

精度が下がったことに気づく仕組み

出力の質がゆっくり落ちる場合、エラーは出ません。現場は「たまに間違うが、まあ直せる」と受け止め、修正の手間を吸収してしまいます。気づいたときには、手作業に近い量の確認が発生していることがあります。

気づくために置くのは、大がかりな監視ではなく次の2つです。

1つは、人が直した記録を残す形にすることです。出力をそのまま採用したのか、手を入れたのかを1クリックで残せるようにしておきます。承認の操作に組み込めば、現場に追加の作業は発生しません。この記録があれば、月次の点検で比率を見るだけで変化が分かります。

もう1つは、同じ検査用データを定期的に流し直すことです。稼働前の評価に使った正解つきのデータを取っておき、月に1回、同じものを通します。業務の実データは月ごとに中身が変わるため、比率が動いた理由が業務側の変化なのか、AIの挙動の変化なのかを切り分けられません。中身が変わらないデータを1つ持っておくと、この切り分けができます。

利用しているモデルの提供元が挙動を更新した場合も、この流し直しで差が見えます。更新の告知を追い続けるより、手元で同じ入力を通す方が確実です。

担当者が代わっても止まらないようにする

内製したものが止まる原因として多いのは、不具合そのものではなく、作った人がいなくなることです。異動や退職の時点で、設定がどこにあるか、なぜその条件にしたのかが分からなくなります。

引き継ぎのために残す資料は、次の内容があれば足ります。分量を増やすより、更新され続ける形にする方が重要です。

項目	書く内容	無いと起きること
対象業務と対象外	どの範囲を任せているか、意図的に外した例外は何か	外したはずの例外を「対応漏れ」と誤解し、直そうとして壊す
判定の条件と、その理由	どういう条件で分けているか。なぜその閾値にしたか	触ってよいか分からず、誰も条件を変えられなくなる
接続している先の一覧	連携先の名称、使っているアカウント、更新の窓口	相手側の変更に気づけず、止まってから調べ始める
設定と手順書の置き場所	実際の設定がどこにあるか、変更手順はどれか	個人の環境にしか無く、退職と同時に触れなくなる
直した履歴	いつ、何を、なぜ変えたか	過去に一度戻した変更を、後任がまた入れてしまう

判定の理由を残すことが、最も効きます。条件そのものは設定を見れば分かりますが、なぜその値にしたかは書かなければ残りません。理由が分からない条件は、後任にとって触れない箇所になり、業務が変わっても直されないまま残ります。

置き場所は、作った人の個人フォルダではなく部門の共有領域にします。人事の手続きでアカウントが停止されると、個人領域の中身は取り出せなくなることがあります。

外部の支援を段階的に外す

作るところを支援会社に手伝ってもらった場合、契約をいつ縮小するかの判断が必要になります。判断材料にできるのは、支援期間の長さではなく、社内で回せた実績があるかどうかです。

段階	社内で回せていることの確認	支援に残す範囲
立ち上げ直後	手順書のとおりに実行でき、止まったときに連絡できる	不具合の一次対応から改修まで
出力のずれを社内で直せる	業務の変化に合わせて、判定の条件を社内だけで2〜3回変更できた	接続と権限、基盤の更新
接続の変更にも対応できる	連携先の仕様変更を、社内で調べて直せた実績が1回以上ある	基盤の更新と、年に数回の相談
新しい業務へ展開できる	2本目を、支援を受けずに要件定義から本番まで通せた	相談窓口としてのスポット契約

段階を飛ばさないことが要点です。1回も自分たちで直したことがない状態で契約を終えると、最初の不具合で止まります。逆に、業務側の変更を毎回依頼している状態が続いているなら、その部分だけでも社内へ移す価値があります。依頼のたびに待ち時間と費用が積み上がるためです。

判断の材料として、支援先へ依頼した内容を種類ごとに数えておきます。3か月分を並べたとき、業務の変化に伴う修正が多いなら、その領域は社内へ移せます。基盤や認証に関するものだけが残っているなら、その部分は外に置いたままで構いません。工程ごとの費用の出方と、どこを社内へ戻せるかは AI開発の外注費用で扱っています。

契約を縮小するときは、期限を決めた併走期間を挟みます。窓口だけ残した状態で1〜2か月動かし、社内で受けきれるかを確かめてから終える形です。工程ごとに社内と外部がどう分担するかは AIエージェントの内製と導入支援にまとめています。

まとめ：内製したAIを持ち続けるための要点

不具合は、出力のずれ、接続先の仕様変更、権限の問題に分け、種類ごとに一次対応を持つ人を決める
受付の窓口は個人名ではなく共有のチャンネルにし、止めるかどうかの目安と渡し先を1枚に書いて現場から見える場所に置く
月に1回、人が直した割合、止まった件数、連携先の変更予告、アカウント、手順書の5点を点検する
精度の低下は、直した記録を残す仕組みと、中身の変わらない検査用データの流し直しで気づく
引き継ぎ資料には、判定の条件そのものより「なぜその条件にしたか」を残す
外部支援は期間ではなく、社内で直せた実績の段階で外していく

Augueでは、AIエージェントの開発だけでなく、運用の体制づくりや社内への引き継ぎまでを含めた内製化の支援を行っています。作ったあとの保守を誰が持つか、支援をどこまで縮小できるかでお悩みの方は、是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

運用・保守のために、社内でどれくらいの時間を確保しておけばよいですか？

一律の目安は出せません。対象業務の変更頻度と、つないでいる外部サービスの数で大きく変わるためです。判断材料になるのは、稼働から3か月分の対応記録です。1件ごとに「気づいてから直るまで」と「誰が手を動かしたか」を残しておけば、月あたりに必要な時間と、その時間が誰に寄っているかが見えます。最初から枠を決めるより、記録を取ってから枠を置く方が実態に合います。

保守を月額で外部へ委託する場合、契約書には何を書いておくべきですか？

対象の範囲を、作業の種類で書き分けておきます。基盤やライブラリの更新、接続先の仕様変更への追随、障害時の調査までを含めるのか、判定基準の変更まで含めるのかで金額も応答も変わります。あわせて、依頼から着手までの目安時間と、設定や手順書の所有がどちらにあるかを書いておきます。所有が曖昧だと、契約を終えたときに手元へ残らないことがあります。

つないでいるサービス側の障害で止まった場合、どこまで自社で調べるべきですか？

提供元の稼働状況ページを見て、同じ時間帯に障害の告知が出ているかを確認するところまでで十分です。出ていれば復旧を待ち、自社の設定は触りません。障害中に設定を変えると、復旧後にどちらが原因だったか分からなくなります。告知が無い場合は自社側の変更を疑い、直近で権限や接続情報に手を入れていないかを先に見ます。

実行の記録はどこまで残しておく必要がありますか？

少なくとも、実行した日時、渡した入力、返ってきた出力、人が直した内容の4点を残します。不具合の切り分けにも、精度が下がっていないかの確認にも同じ記録を使うためです。保存期間は社内の文書管理の規程に合わせます。個人情報や取引先の情報を含む場合は、保管場所と閲覧できる人の範囲を、AIを使わない業務と同じ基準で決めます。