引き継ぎで止まるのは、動かし方ではなく所在
ベンダーに任せていたAIを社内へ引き取るとき、多くの会社が最初に用意するのは操作の手順書です。ところが実際に業務が止まるのは、操作が分からないときではありません。動かすために必要なものが、どこにあるか分からないときです。
たとえば、外部サービスとの接続が切れたとします。復旧に必要なのは接続用の鍵ですが、その鍵は外注先の担当者が自分のアカウントで発行していて、社内には控えがない。契約はすでに終わっている。この状態になると、操作手順をいくら整えても直せません。
引き継ぎで確認するのは、成果物が動くかどうかではなく、動かし続けるために必要なものが自社の管理下にあるかどうかです。以下では、受け取るものを5種類に分けて一覧にし、それをどの順で移すと稼働を止めずに済むかを整理します。どこまでを自社で持つかという全体の線引きは 生成AI・AIエージェントの内製化とは を先に押さえておくと、引き継ぎの範囲も決めやすくなります。
契約終了前に受け取るものの一覧
引き継ぎ物は、性質で5つに分かれます。分けて扱う理由は、受け取り方も、受け取れなかったときの影響も違うためです。
| 引き継ぐもの | 何を受け取るか | 受け取れていないと起きること |
|---|---|---|
| 指示文（プロンプト） | AIへ渡している文面そのもの。改訂の履歴と、なぜその書き方にしたかの補足 | 出力がずれたときに、どこを直せばよいか分からない。文面を一から書き直すことになる |
| 設定値 | 使っているモデルの種類、出力の長さや形式の指定、再実行の条件、しきい値 | 同じ入力でも結果が変わる。原因が指示文か設定かを切り分けられない |
| 接続先の情報 | つないでいるシステムの一覧、接続用の鍵とその発行元、更新期限、通信の許可設定 | 接続が切れた時点で復旧できない。期限切れの日に予告なく止まる |
| アカウントと権限 | 各サービスの契約者名義、請求先、管理者権限を持つアカウント、利用者の一覧 | 契約が切れると全体が止まる。権限を追加・削除できず、退職者のアカウントも消せない |
| 運用手順 | 定期作業の内容と頻度、異常時の一次対応、過去に起きた不具合とその対処 | 何が正常かを社内で判断できない。異常に気づくのが業務側からの申告のときだけになる |
上から2つは、動いているものを読めば復元できる余地があります。時間はかかりますが、社内で書き起こせます。復元できないのは、下の3つです。 接続用の鍵は再発行に相手方の手続きが要り、契約者名義は外注先の協力なしには変えられず、過去の不具合の記録は外注先の頭の中にしか残っていません。
そのため、引き継ぎの交渉では下の3つを優先します。上の2つは受け取れれば作業が減るという性質で、受け取れなくても致命的にはなりません。
指示文と設定値で見落としやすいもの
指示文は1つのファイルにまとまっているとは限りません。処理の段階ごとに別の文面を使っていたり、業務の種類で分岐していたりします。「全部でいくつあるか」を先に聞き、数を確認したうえで受け取ります。
設定値で抜けやすいのは、正常時に意識しない項目です。エラーが出たときに何回まで再実行するか、応答が遅いときにどこで打ち切るか、判定の確信度がどこを下回ったら人へ回すか。これらは動いている間は見えませんが、値が変わると挙動が変わります。判定のしきい値をどう決めるかは AIエージェントの精度をどう評価するか で扱っています。
アカウントは名義と権限を分けて確認する
アカウントの確認は、2段階で見ます。
- 契約者名義と請求先が自社になっているか … 外注先の名義で契約されている場合、契約終了とともにサービスも止まります。名義変更は先方の申請手続きに従うため、社内の都合では短縮できません
- 管理者権限を持つアカウントを自社が持っているか … 名義が自社でも、実際に設定を変えられるアカウントを外注先しか持っていないことがあります。名義の確認だけでは足りません
この2つは、引き継ぎ物の中で唯一、期限が外部の都合で決まる部分です。契約終了の直前に着手すると間に合わないことがあるため、引き継ぎを決めた時点で最初に手をつけます。
止めずに移す順序
引き継ぎ物を全部そろえてから一斉に切り替えると、切り替えた日に何かが動かなくなったときに、原因が特定できません。順序を分けて、1つずつ移します。
この順序にする理由は、後戻りできる状態を保ったまま進めるためです。アカウントを先に移しても業務の動き方は変わりませんし、社内で監視を始めても直すのは外注先のままです。どの段階でも、うまくいかなければ前の段階に戻れます。逆に、指示文の改修から始めると、直したものが壊れたときに外注先へ戻す手段がありません。
STEP 1 でアカウントと接続情報を移す
最初に着手する理由は、外部の手続きに時間がかかるからです。クラウドサービスの名義変更は申請から反映まで日数がかかり、社内の予定では動かせません。契約終了までの残り期間が短いなら、他を後回しにしてもここだけは先に進めます。
移し終えたかの確認は、書類ではなく操作で行います。自社のアカウントだけでログインし、設定画面を開き、利用者を1人追加してみる。これができれば移っています。「名義変更の申請書を出した」時点では、まだ移っていません。
STEP 2 で監視だけを社内へ移す
運用手順を受け取り、社内が動作を見る役割を持ちます。この段階では、直すのは外注先のままです。社内がやるのは、異常に気づいて連絡することだけです。
やることは3つに絞れます。定期的に動いているかを確認する、出力を抜き取って中身を見る、業務側から声が上がる前に気づく。この段階を置く意味は、何が正常かを社内が知ることにあります。正常な状態を知らないまま改修へ進むと、直した結果が正しいかを判断できません。
社内で監視する項目の具体は 内製したAIエージェントの運用・保守 が詳しく、点検の頻度や記録の残し方はそのまま使えます。
STEP 3 で改修だけを社内へ移す
指示文と設定値を受け取り、社内で直し始めます。外注先との契約はまだ続いている状態で進めるのが要点です。直したものが期待どおりに動かなかったとき、聞ける相手がいる状態で試します。
最初に手をつけるのは、判定の基準や出力の書式のように、業務側で正解が分かる部分です。接続先の設定や基盤の更新には触れません。この範囲の切り分けは、そのまま内製後の分担にもなります。
進み具合の確認は、件数で見ます。社内だけで修正を3件通せたら次へ進みます。3件という数に厳密な根拠はありませんが、1件では偶然うまくいった可能性が残り、同じ種類の修正を繰り返すだけでは判断材料にならないためです。種類の違う修正を3件通せれば、手順として身についていると見ます。
STEP 4 で外注先の関与を絞る
全部を切る必要はありません。頻度が低く専門性が高い領域だけ、スポット契約として残します。基盤やライブラリの更新、外部審査への対応、業務そのものが変わるような大きな改修が該当します。
残す場合は、対象範囲・連絡方法・応答までの目安時間を書面にします。「何かあったら相談する」という形で残すと、実際に何か起きたときに対応の可否から交渉が始まります。
段階ごとに社内で必要な人数
各段階で社内に何人要るかは、持つ役割の数で決まります。1人が複数の役割を兼ねられる場合もあるため、人数ではなく役割で見たほうが実態に合います。
| 段階 | 社内で持つ役割 | 人数の目安 | 兼任できるか |
|---|---|---|---|
| STEP 1（名義と権限） | アカウント管理、契約の手続き | 1〜2名 | 情報システムと総務・購買で分かれることが多い |
| STEP 2（監視） | 動作の確認、異常の一次受け | 業務側1名＋情報システム側1名 | 業務側は担当者が兼任できる。不在時の代理は決めておく |
| STEP 3（改修） | 指示文の修正、判定基準の決定、修正の確認 | 業務側1〜2名＋情報システム側1名 | 修正する人と確認する人は分ける |
| STEP 4（内製後） | 上記すべて＋外部への発注判断 | 3名前後 | 発注判断は責任者が持つ。他の役割との兼任は可能 |
最終的に3名前後という規模は、内製でAIを作る場合の最小構成とおおむね同じです。役割ごとの詳しい分担は 内製でAIエージェントを作る体制と分担 で扱っています。
数だけを見て少ないと感じるかもしれませんが、引き継ぎで難しいのは人数の確保ではありません。同じ人が最後まで担当し続けられるかです。STEP 1 の担当者が STEP 3 の頃には別の業務に移っていると、受け取った情報が引き継がれず、社内で二度目の引き継ぎが発生します。段階を分けて進めるからこそ、担当者を固定する必要があります。
契約更新の前に頼んでおくこと
引き継ぎの成否は、契約が続いているうちに何を頼んだかでほぼ決まります。契約が終わってから依頼すると、外注先には応じる義務がなく、応じてもらう場合も別途の見積になります。
次の契約更新のタイミングで、以下を確認・追加します。内製へ移す予定がまだ無くても、確認しておくと選択肢が残ります。
| 頼むこと | 契約のどこに入れるか | 頼まなかった場合 |
|---|---|---|
| 指示文・設定値を納品範囲に含める | 成果物の定義 | 動くものだけが手元にあり、中身を読めない |
| 契約者名義と請求先を自社にする | 委託の範囲、費用の取り扱い | 契約終了と同時にサービスが止まる |
| 管理者権限を自社アカウントが持つ | 運用の役割分担 | 名義は自社でも設定を変えられない |
| 接続情報の一覧と更新期限を定期提出 | 報告の義務 | 期限切れの日に予告なく止まる |
| 対応した不具合の記録を残す | 保守の範囲 | 過去の経緯が外注先にしか残らない |
| 契約終了時の引き渡し範囲を明記 | 契約終了時の取り扱い | 引き渡し自体が交渉事になる |
一番下の行が抜けていることは珍しくありません。着手時は終わり方を想定しないためです。ただ、追加そのものは相手に不利益がなく、既存の契約でも更新時に追記を求めやすい項目です。
発注の段階でこれらをどう確認するかは AI内製化支援サービスの選び方 で、費用面から内製へ戻す判断をどう立てるかは AI開発の外注費用 で扱っています。
移せる状態かを先に確かめる
引き継ぎ物がそろっていても、社内の状態によっては移さないほうがよい場合があります。判断の材料は3つです。
- 改修の頻度 … 年に数回しか直していない領域は、内製へ移しても社内の担当者の手が慣れません。移す作業の負担だけが残ります
- 業務そのものの安定性 … 対象業務が数か月後に大きく変わる予定があるなら、変わったあとに移します。移行中に仕様が変わると、どちらの理由で動かなくなったか分からなくなります
- 業務側に仕様を書ける人がいるか … 判定の基準や例外の扱いを、外部へ説明できる形で書ける人がいるかどうか。いなければ、STEP 3 で修正の判断ができません
3つのうち改修の頻度が高く、業務が安定していて、書ける人がいる場合は、段階を進める意味があります。当てはまらない場合は、STEP 1 と STEP 2 だけを済ませて外注を続ける形が現実的です。名義と権限を自社が持ち、社内が監視できていれば、外注先を変える選択肢も、後から内製へ進む選択肢も残ります。
対象業務をどう選ぶかは 生成AI内製化の最初の1業務の選び方 に絞り込みの基準がまとまっています。
まとめ：外注していたAIを社内へ引き取る要点
- 引き継ぎで止まるのは操作が分からないときではなく、動かすために必要なものの所在が分からないとき。確認するのは成果物が動くかではなく、自社の管理下にあるか
- 受け取るものは指示文・設定値・接続先の情報・アカウントと権限・運用手順の5種類。社内で復元できないのは後ろの3つで、交渉ではここを優先する
- 移す順序は、名義と権限 → 監視 → 改修 → 関与を絞る。後戻りできる状態を保ったまま進めるため、段階ごとに条件を満たしてから次へ行く
- アカウントの名義変更は外部の手続きに従うため社内の予定では動かせない。引き継ぎを決めた時点で最初に着手する
- 段階ごとに必要なのは役割であって人数ではない。最終的に3名前後で回るが、同じ担当者が最後まで持ち続けることのほうが難しい
- 引き渡し範囲・名義・管理者権限・接続情報の提出は、契約が続いているうちに契約へ入れておく。終わってから頼むと交渉と追加費用になる
- 改修の頻度が低い、業務がこれから変わる、仕様を書ける人がいない場合は、STEP 1 と STEP 2 だけ済ませて外注を続けるほうが妥当
Augueでは、外注していた業務の棚卸しから、非エンジニアの方がご自身の業務のAIを直せるようになるまでの伴走支援を行っております。どこまでを社内へ引き取り、どこを外部に残すかの切り分けから一緒に整理できますので、ご興味がある方は是非ご相談ください。
関連する記事
自社で持つ範囲の決め方は 生成AI・AIエージェントの内製化とは、引き取ったあとの点検と一次対応は 内製したAIエージェントの運用・保守、社内の役割分担は 内製でAIエージェントを作る体制と分担、費用面から内製へ戻すかを判断する手順は AI開発の外注費用 を参照してください。
よくある質問
引き継ぎにはどれくらいの期間を見ておけばよいですか？
一律の目安は出せません。つないでいる外部サービスの数と、契約者名義の変更が要る範囲で大きく変わるためです。期間の見当をつけるなら、引き継ぎ物の一覧を作った時点で「名義変更が要る契約が何件あるか」を数えます。名義変更は先方の申請手続きに従うため社内の都合で短縮できず、ここが期間を決めます。指示文や手順書の受け取りは並行して進められます。
引き継ぎの作業に費用は発生しますか？
契約時に納品範囲へ含めていれば追加費用は生じませんが、契約終了が近づいてから依頼すると、資料作成の作業として別途見積が出るのが通例です。金額は資料の量ではなく、外注先が記録を残しているかどうかで変わります。記録が無ければ、動いているものから仕様を書き起こす作業になるためです。見積を受け取る前に、どこまでが既存資料の整理でどこからが新規作成かを分けて確認します。
外注先が引き継ぎに応じてくれない場合はどうすればよいですか？
まず契約書と発注書で、成果物の定義と著作権・利用権の帰属を確認します。指示文や設定が成果物に含まれていれば、引き渡しは契約上の義務として求められます。含まれていない場合は交渉になるため、対価を払って追加で依頼するか、社内に残っている記録から書き起こすかの判断になります。次の契約からは、着手前に納品範囲へ明記しておくことで同じ状況を避けられます。
社内に技術者がいなくても内製へ移せますか？
段階によります。動いているものを見て異常に気づき、外注先へ連絡する段階までは、業務側の担当者だけで成立します。指示文を直す段階も、対象を業務の判定基準に限れば非エンジニアで回ります。一方、アカウントと権限の管理、接続先の設定変更、基盤の更新は情報システム側の担当が必要です。技術者がいない場合は、この部分だけ外部へ残す形が現実的です。
引き継いだ後、外注先との関係はどうすればよいですか？
全部を切らず、頻度の低い領域だけスポット契約として残す形が扱いやすくなります。基盤の更新、外部審査への対応、大きな仕様変更が該当します。この形にする場合は、引き継ぎの完了時点で「どの範囲を、どういう連絡方法で、どれくらいの応答時間で受けてもらうか」を書面にします。関係を残す前提であれば、引き継ぎそのものも協力を得やすくなります。