FDE支援終了後も社内で運用するには？引き継ぎ8項目と内製化の確認手順

FDE支援の引き継ぎは、資料を受け取るだけでなく、社内担当者が自社の権限で通常処理・設定変更・障害対応を確認できる状態を目指します。支援会社しかログインできない、連携が止まると原因を調べられない、月額費用の支払先が分からない。このような状態は、契約終了前に解消しておきたい課題です。

この記事では、中小企業がFDEによるAI導入を内製化につなげるための引き継ぎ項目と確認方法を紹介します。図解・台帳画面・期限は説明用の例であり、実在の顧客や導入実績を示すものではありません。

執筆：86研究所 ／ 内容確認日：2026年10月5日

FDE支援の終了後、何を自社で持つべきか

まず「自社が日常運用する範囲」と「外部へ保守を依頼する範囲」を分けます。担当者がソースコードをすべて修正できる必要はありません。一方で、稼働確認、利用者の変更、費用の把握、障害時の連絡先など、社内で判断する仕事は明確にします。

FDEの役割自体はFDEの仕事内容と他の支援との違いで解説しています。本記事は、その支援で作った仕組みを契約終了後も使い続けるための確認に絞ります。

契約終了前に確認する8つの引き継ぎ項目

次の表は、引き継ぎ打ち合わせのたたき台です。「受領済み」と「社内で確認済み」は分けて記録します。

APIキーやパスワードの値を、このような一般の台帳へ貼り付ける必要はありません。管理場所と取得権限、更新する担当者を記録し、秘密情報は合意した管理方法で扱います。支援者個人の認証に依存する連携がないかも確認します。

個人のアカウントに資産を残さない

マニュアルを共有しても、保管先の管理者が外部担当者だけなら、異動や契約終了の影響を受けます。自社が管理できる組織・保管先を決め、閲覧できるだけなのか、更新や権限管理までできるのかを区別してください。

Googleの公式説明では、共有ドライブのファイルは個人ではなくチームに属し、メンバーが離れても残る仕組みが案内されています。利用できる機能は契約や管理設定によるため、自社環境で確認します。移動によって共有範囲や連携への影響が出る場合もあるので、単純にフォルダーを移すだけで完了にはしません。参照：Google Workspace：共有ドライブとは。

GitHubは、組織へのアクセスが失われることを防ぐため、少なくとも2人を組織のオーナーにすることを推奨しています。これはGitHubの管理上の推奨であり、すべての利用者に広い権限を与えるという意味ではありません。主担当と代替担当を決め、役割に必要な権限を確認する考え方が参考になります。参照：GitHub Docs：組織の所有権の継続性を維持する。

実画面：未完了を残さない引き継ぎ台帳

引き継ぎの進捗は「説明した」だけでなく、確認方法と結果まで記録します。下の画面は架空の問い合わせ分類業務を題材にした台帳デモを、実際にブラウザーで開いて撮影したものです。

「未完了だけを表示」の切り替えで、確認の残っている項目を表示できることを確認しました。注目点は、未完了の項目に次の行動・担当者・期限・確認資料を残していることです。掲載画面は台帳の表示デモであり、実際の問い合わせ分類や障害復旧を検証した結果ではありません。

台帳は次の形式でも作れます。「対象業務／資産の場所／運用担当／確認手順／期待する結果／確認結果／未完了事項／期限」。完了条件は、資料の有無だけでなく担当者の操作結果と対応させます。

引き継ぎの場で社内担当者が試す3つの操作

1．通常の仕事を一度終わらせる

FDEが画面を操作して説明するだけでなく、社内担当者が手順書を見て、テスト用の入力から結果確認まで進めます。どの画面を見るか、出力が正しいか、処理が完了したかを判断できるかが確認点です。実顧客への送信や本番データの更新を伴うテストは、影響範囲を決めてから行います。

2．小さな設定変更と戻し方を試す

テスト環境で、通知先や分類ラベルなど、合意した小さな変更を行います。変更箇所、反映方法、確認方法、元に戻す手順までを一続きにします。プロンプトを変える場合も、以前のテスト質問で意図しない回答の変化がないか確認します。

3．失敗時の連絡と復旧を練習する

本番を故障させるのではなく、テスト環境や保存したエラー例を使います。社内担当者がログを見つけ、手順書の該当箇所を選び、対応できない場合に必要情報を添えて窓口へ連絡できるかを確認します。バックアップがあることと、そこから復元できることも別なので、復元の検証範囲を合意します。

処理のやり直しには二重送信・二重登録への配慮も必要です。具体的な運用設計はAI自動化の承認・例外処理・復旧ガイドで説明しています。

支援会社のアクセスを外す順番

契約終了日に外部ユーザーを一括削除すると、その認証で動いていた処理が止まることがあります。まず、ログイン利用者、連携に使う認証、通知先、請求先を棚卸しします。必要な認証を自社管理へ切り替え、通常処理と定期実行を確認した後で、不要になった支援者の権限を整理します。

キーを更新する場合も、連携先への反映と動作確認をセットで計画します。支援終了後も保守を委託するなら、対象のシステム・許可する操作・連絡経路を明確にしておきます。「全部残す」「全部消す」の二択ではなく、実際の依存関係から決めます。

内製化と継続保守をどう分けるか

日常運用は社内、機能追加や難しい障害対応は外部、という分担も選べます。社内担当者の時間と技術、業務が止まったときの影響、変更の頻度で決めましょう。外部費用だけでなく、社内の確認・修正時間も含めた比較が必要です。費用の考え方はFDEの費用と費用対効果の計算シートも参考になります。

86研究所のFDE伴走支援では、内製化・自走支援としてマニュアル整備や担当者育成を案内し、継続契約も選択肢としています。個別の成果物、アカウント、保守範囲、終了時の確認方法は、対象業務に応じて相談時に整理します。

相談時には「終了後に社内でできるようにしたい操作」を挙げていただくと、必要な引き継ぎを具体化しやすくなります。無料AI業務診断はこちら。

よくある質問

コードを受け取れば他社にも保守を頼めますか？

コードだけでは判断できません。利用条件、依存するサービス、設定、データ、動かし方、必要な権限まで確認します。第三者が変更・保守できる範囲も個別の契約やライセンスに沿って整理してください。

社内にエンジニアがいなくても引き継げますか？

日常点検や操作を社内、技術的な変更を外部と分担する方法があります。自社で担う操作を先に決め、それを担当者が再現できる手順に落とします。

引き継ぎは契約終了直前から始めればよいですか？

管理先、成果物、確認方法は開始時から決めておく方が整理しやすくなります。支援中に台帳と手順書を更新し、終了前には社内担当者による操作確認へ時間を使います。