担当者が抜けてもAIを止めない引き継ぎ5点

AI を使った業務システムで、担当者の異動・退職によって最初に止まるのは「モデルの中身」ではありません。止まるのはアカウントと支払い、プロンプトの改訂履歴、例外処理の判断基準、ベンダーとの窓口です。逆に言えば、この4系統を文書とアカウント設計で引き継げる形にしておけば、担当者が1人抜けても業務は翌日も動きます。

本記事では、中小企業で AI 機能を業務に組み込んだあと、担当者の交代時に何が止まり、何を残しておけば止まらないのかを、実務の手順に落として整理します。難しい技術的な知識は前提にしていません。

担当者が抜けたとき、最初に止まるのはどこ？

AI を組み込んだ業務システムは、見た目には「動き続けている」ように見えます。問題が表に出るのは、たいてい最初のトラブルが起きたときです。よくある順番は次のとおりです。

1. 支払いが止まる:API（外部のサービスを自社システムから呼び出すための接続口）の利用料が個人名義のカードで決済されていて、退職後に引き落としが失敗する。
2. 認証が切れる:API キー（接続の鍵となる文字列）やクラウドの管理者アカウントが本人のメールアドレスに紐づいていて、再発行も権限変更もできない。
3. 精度の低下に気づけない:「この出力はおかしい」と判断していたのが担当者の頭の中だけで、後任が良し悪しを判断できない。
4. 例外の対応が止まる:AI が処理できなかった案件を、担当者が毎朝こっそり手で直していた。その手順が誰にも共有されていない。
5. ベンダーと話が通じなくなる:開発会社側の担当者も「前の方とのやり取り」を前提にしており、仕様の経緯が双方で失われる。

1と2は数日で表面化しますが、3と4は数週間から数か月かけて静かに悪化します。使われなくなるAIの共通点4つと立て直し方でも触れたとおり、AI が使われなくなる過程は「突然止まる」より「じわじわ信用されなくなる」形を取ることが多く、担当者交代はその引き金になりやすいのです。

引き継げる形にするものは何？

引き継ぎ資料を「全部書く」と考えると終わりません。後任が困るのは、本人の頭の中にしかない判断と、本人の名義にしかない権限の2種類だけです。この観点で整理すると、残すべきものは次の表に収まります。

重要なのは、この5区分のうち「権限」と「費用」は台帳さえあれば引き継げるという点です。一方で「設計」「品質」「運用」は、文章として残すだけでは不十分で、後任が自分で検証できる状態まで持っていく必要があります。

アカウントと支払いをなぜ最優先にするのか

AI 関連のサービスは、試験導入のしやすさが特徴です。担当者が自分のアカウントで契約し、少額から試して、そのまま本番で使い続ける——という流れが起きやすい。これ自体は立ち上げの速さとして悪いことではありませんが、本番運用に移った時点で名義を法人に移す作業が抜けがちです。

最低限、次の状態にしておきます。

• 管理者を必ず2人以上にする。1人は現場担当、もう1人は経営層または情報システム担当。1人しか管理者がいないサービスは、その時点で単一障害点です。
• 支払い名義を法人にする。立て替え精算で回っている契約がないか、経理側の視点で確認します。
• API キーは個人の端末に置かない。パスワード管理ツールまたはクラウドの秘密情報保管機能に集約し、誰が取り出せるかを決めておきます。
• 無料枠・試用版のまま本番で使っていないか確認する。利用規約上、業務利用が想定されていない区分で動いている場合があります。

契約が増えて把握しきれない場合は、増えたAI契約の整理は統合より棚卸しからで説明した手順で、まず一覧化するところから始めると進みます。統合や解約の判断は、一覧ができたあとで構いません。

プロンプトと評価データはどう残す？

ここが引き継ぎでいちばん抜けやすい部分です。プロンプト（AI への指示文）は、たいてい何度も書き換えられています。問題は、最新版だけが残っていて、なぜそう書き換えたのかが残っていないことです。

たとえば次のような場面です。プロンプトに「社名は正式名称で出力すること」という一文が入っている。後任から見ると冗長なので削ってしまう。すると以前に起きた、略称と正式名称が混在して検索に引っかからなくなる不具合が再発する——という流れです。一文ごとに「いつ、何の問題に対応して入れたか」を併記しておくだけで、この種の逆戻りはかなり防げます。

そしてプロンプト以上に引き継ぎ価値が高いのが、評価データです。評価データとは、代表的な入力と、それに対して期待する出力をセットにしたものです。これがあると、後任は「この修正をしたら今までどおり動くか」を自分で確かめられます。無ければ、変更のたびに感覚で判断することになります。

評価データの作り方と運用の考え方は、AI の「良くなった気がする」を卒業する — 評価データセットの作り方と運用で詳しく扱っています。引き継ぎのためだけに新しく作る必要はなく、日々の運用で「これは間違い」と判断した事例を貯めていけば、それがそのまま引き継ぎ資料になります。

「人に戻す条件」を文書にする

もうひとつ、担当者の頭の中に残りやすいのが例外処理の基準です。AI が自信を持って処理できない入力を、どの条件で人間に回すのか。この境界線は運用しながら調整されるため、調整した本人しか理由を知らない状態になりがちです。設計時点で明文化しておく考え方は、問い合わせAIの振り分けは「人に戻す条件」から決めるで整理しています。

ベンダーとの契約で確認しておくことは何か

外部に開発を委託している場合、引き継ぎの論点は自社内だけでは閉じません。契約書と仕様書を、次の観点で読み直してください。

• 成果物の範囲にプロンプトと設定値が含まれているか。ソースコードは納品されても、プロンプトや調整済みのパラメータが「ノウハウ」として外れている契約があります。
• 学習や調整に使ったデータの扱い。自社データの利用範囲、契約終了後の削除、第三者への提供の可否。
• 保守の連絡窓口が個人か、組織か。先方の担当者が変わったときにも同じ品質で対応されるか。
• モデルの提供終了・仕様変更が起きたときの対応と費用負担。

最後の点は、担当者交代と重なると影響が大きくなります。外部の AI モデルは提供元の都合で仕様が変わったり、旧版の提供が終了したりします。その対応を「誰が、いくらで」やるのかが決まっていないと、引き継いだ後任が突然その判断を迫られます。考え方はAI機能の保守費は「モデルが変わる日」を先に見積もるで整理しました。

なお、委託開発における権利やデータの扱いについては、経済産業省が公表している「AI・データの利用に関する契約ガイドライン」が参考になります。個別の契約がこれに従う義務があるわけではありませんが、論点の抜け漏れを確認する目安として使えます。また、顧客情報や従業員情報を AI に入力している場合は、個人情報保護法上の取扱いの整理が引き継ぎ資料に含まれているかも確認してください。担当者が代わっても、法令上の責任は会社に残ります。

引き継ぎを「退職時のイベント」にしない

ここまで挙げた項目を、退職が決まってから2週間で作るのは現実的ではありません。そもそも引き継ぎ資料は、作るタイミングを決めると形骸化し、更新のきっかけを決めると残ります。

運用に組み込む方法として、次のような形が取りやすいでしょう。

• プロンプトを変更したら、変更理由を1行添えて保存する(変更の都度)
• AI の出力に手直しを入れたら、その入力と正しい出力を評価データに追加する(都度)
• 新しいサービスを契約したら、台帳に1行追加し、管理者を2人設定する(契約の都度)
• 四半期に一度、台帳の支払い名義と管理者一覧を経理・総務の側から確認する(四半期)
• 年に一度、ベンダーとの契約書で成果物の範囲とデータの扱いを読み直す(年次)

このうち最初の2つは、担当者本人の作業の一部として組み込むのが要点です。「引き継ぎ資料を作る」という別タスクにすると、忙しい時期に必ず後回しになります。

後任が最初にやるべきこと

引き継ぐ側ではなく、引き継いだ側の動き方も決めておくと復旧が早くなります。おすすめは、引き継ぎ初日に「小さな変更を1つ入れて、評価データで検証し、元に戻す」という練習をすることです。これができれば、権限・評価の仕組み・変更の手順の3つが揃っていることが確認できます。できなければ、そこが引き継ぎの穴です。

まとめ

AI を使った業務システムで担当者が交代したとき、止まるのは技術ではなく、権限・費用・判断基準・窓口です。引き継ぎのために残すものは、権限台帳、費用台帳、プロンプトの改訂理由、評価データ、例外時の手順の5つに整理できます。

このうち台帳2つは今日から作れます。プロンプトの改訂理由と評価データは、日々の運用のなかで1行ずつ貯めていくものです。そして契約面は、年に一度読み直す習慣をつけるだけで、交代時の混乱はかなり減ります。

「担当者が1人抜けても、翌日も同じ品質で動くか」——この問いに即答できない状態であれば、まずはアカウントの管理者が1人になっているサービスがないかを確認するところから始めてください。そこが最も短時間で、最も確実に効く一手です。