AI開発の引き継ぎ｜外注先を変えるときの納品物

外注先を変えるとき、引き継げるかどうかは「何が納品されているか」で決まります。 動いている仕組みが目の前にあっても、ソースコード・仕様の説明・環境の情報・認証情報の所在・運用手順が手元になければ、次の会社は中身を見られず、改修も再現もできません。しかもAI開発には、一般のシステム開発にはない引き継ぎ物があります。プロンプト、精度を測った評価用データ、使っているAIモデルの名称と版、APIキーの契約名義です。

この記事では、切り替えを決めた担当者が、契約が残っているうちに何を回収し、どの順序で動き、次の会社に何を渡せばよいかを整理します。後半では医療法人の事務部門を例に、患者情報を扱う仕組みを引き継ぐときに参照する公的ガイドラインまで扱います。読み手として想定しているのは、外注先の変更を稟議に上げる側、または引き継ぎ先の見積りを比較する側の担当者です。

引き継ぎに必要な納品物の全体像

この6分類が手元にあれば、次の会社は状況を把握できます。 逆に、どれか一つでも欠けると、その分類を復元する作業が見積りに乗ります。とくに「環境」と「認証」は、コードと仕様が揃っていても見落とされやすい分類です。コードは受け取ったのに動かせない、という状態はここが原因で起きます。

見落としを防ぐには、引き継ぎを「コードをもらう作業」ではなく「6分類を一覧にして、揃っているものと欠けているものを仕分ける作業」として始めてください。仕分けの結果がそのまま、次の会社に渡す見積り依頼の前提になります。

AI開発ならではの引き継ぎ物

AI開発で見落とされがちなのは、コードの外側にある部分です。生成AIを使う仕組みでは、出力の質を決めているのはコードそのものより、AIへの指示文（プロンプト）と、その指示文をどのデータで検証したかという記録です。

この4点は、一般のシステム開発の引き継ぎでは出てこない項目なので、6分類とは別に挙げています。 一方で、AI開発で欠けやすいのに6分類の側で受け取るべきものが2つあります。一つは入出力のログです。記録が残っているか、保管期間と保管場所はどこか、患者や顧客の個人情報が含まれ得るかを確認し、「運用」（ログの見方）の項目として棚卸しします。もう一つは、AIが答えずに人に回す条件の定義です。文書になっているかを確認し、「仕様」（判断基準）の一部として受け取ります。どちらもコードの外側にあり、聞かなければ出てこない項目です。

プロンプトは仕様書の一部です。 コードの中に文字列として埋め込まれている場合、次の会社はコード全体を読まないと指示の内容を把握できません。別ファイルに分かれていて、変更履歴が残っているのが望ましい状態です。

モデルの版も重要です。2026年7月時点の主要モデルにはChatGPTのGPT-5.6、ClaudeのOpus 5とFable 5、GeminiのGemini 3.6 Flashなどがありますが、提供元の更新で挙動は変わります。どの版で精度を確認したかの記録がなければ、次の会社は「同じ精度が出るか」を再現できません。評価用データがあれば、モデルを切り替えたときに精度が保たれているかを確認できます。

APIキーが外注先名義で、利用料が外注先経由で請求されている形も多く見られます。この場合、契約終了と同時にキーが無効になり、仕組みが止まります。名義の確認は、切り替えを決めた日にやってください。

契約書で先に確認する項目

引き継ぎで「出してもらえるもの」の範囲は、契約書で決まります。参照点として使えるのが、独立行政法人情報処理推進機構（IPA）の「情報システム・モデル取引・契約書」です。IPAは、ユーザ企業とITベンダ間の取引構造を透明化するために、各開発段階で双方が担うべき責務の解説と契約書のひな型を提供しています。2020年12月22日に公開された第二版は、2020年4月に施行された改正民法に対応し、請負契約における契約不適合責任、契約不適合責任における権利行使の期間制限などを論点として見直したものです。民法改正以外の論点として、セキュリティ、プロジェクトマネジメント義務及び協力義務、複数契約の関係、再構築対応も扱われています（出典1）。

IPAは、ユーザ企業とITベンダの双方が第二版を参照することで、契約のタイミングで仕様やプロジェクト管理方法、検収方法等について共通理解のもと対話を深めることを期待していると述べています（出典1）。引き継ぎの場面に置き換えると、この「共通理解」が契約時にどこまで書面になっていたかが、いま回収できる範囲を決めます。

自社の契約書と照合する項目は次の5点です。

1. 納入物として何が列挙されているか（ソースコード、設計書、運用手順、プロンプトが含まれるか）
2. 権利の帰属（著作権の帰属、または利用許諾の範囲。自社での改修や第三者への委託が許されるか）
3. 契約不適合責任の期間（権利行使の期間制限。引き継ぎ後に不具合が見つかった場合に誰が直すか）
4. 保守契約の終了条件と、終了時の協力義務（引き継ぎへの協力が義務として書かれているか）
5. 再委託の有無（実際に作った会社が別なら、引き継ぎ資料の所在も別になる）

納入物の定義が契約書にない場合は、今からでも書面で合意してください。 口頭で「コードは渡します」と言われても、後で範囲がずれます。メールでもよいので、何を、いつまでに、どの形式で受け取るかを残します。

切り替えを決めたら最初にやること

現在の契約が続いているうちに動いてください。 契約終了後は、引き継ぎ作業が有償の依頼になり、先方の協力を得にくくなります。

1. 契約書で納入物の範囲と権利帰属を確認する
2. 納入物として明記されているものの提供を、書面で依頼する
3. 提供されたものが実際に動くかを、別の環境で確認する
4. 認証情報とサービス契約の一覧を作る
5. 既知の課題を、文書で受け取る

3番を飛ばさないでください。 コードを受け取っても、それだけでは動かないことがあります。依存ライブラリの版、環境変数、外部サービスの設定が揃って初めて起動します。自社で確認できない場合は、次の会社に短時間の作業として立ち会ってもらう方法があります。次の会社に渡す前に動く状態を確認しておくと、見積りの精度が上がり、手戻りが減ります。

認証情報とサービス契約の棚卸し

引き継ぎで最も詰まるのがここです。次の形で一覧にしてください。

契約名義が外注先になっているものは、切り替え前に自社名義へ移してください。 そのままだと、契約終了と同時にサービスが止まります。名義の移管には提供元ごとの手続きが要り、数週間かかる場合もあります。切り替えの期日から逆算して、最初に着手する項目です。

通知先の変更も忘れやすい項目です。APIの利用量が上限に近づいたときの警告や、支払いの失敗の通知が外注先にだけ届く設定のままだと、止まってから気づくことになります。

引き継ぎ資料に含めてもらうもの

現在の外注先に依頼する内容です。

1. ソースコード一式（動く状態のもの。依存ライブラリの版を含む）
2. システムの構成図（何がどこで動いているか。外部サービスとの接続を含む）
3. 仕様の説明（主要な処理が何をしているか。プロンプトと、人に引き継ぐ条件を含む）
4. 評価用データと結果（どのデータで精度を確認し、どの水準を合格としたか）
5. 既知の課題（未修正の不具合、保留になっている要望）
6. 運用手順（定期的に行っている作業、障害時の対応、ログの見方）

5番目を落とさないでください。 引き継いだ後に発覚すると、前の会社と次の会社の間で責任の所在が曖昧になります。「今のところ問題はない」と言われても、保留にしている要望は聞き出せます。

もう一つ、資料に書かれにくいのが「どの水準で動くことを合意していたか」です。可用性、性能、バックアップ、復旧までの時間といった非機能の要件です。IPAの「非機能要求グレード」は、非機能要求についてのユーザと開発者との認識の行き違いを防ぐことを目的に、項目を網羅的にリストアップして分類し、要求レベルを段階的に示したツール群で、項目は6つの大項目ごとに階層化されています。重要な項目から順に要求レベルを設定しながら、両者で確認していく使い方が示されています（出典3）。引き継ぎ資料に「どのレベルで合意していたか」がなければ、次の会社との最初の作業は、このレベル合わせになります。合意の水準が不明なまま「止まった」「遅い」と言っても、前の設計が悪かったのか、そもそも合意していなかったのかが分かりません。

揃っていない場合の選択肢

「作り直し」は損とは限りません。 当初の要件と現在の業務が変わっている場合、使っているモデルの提供が終了に向かっている場合は、作り直したほうが実態に合うことがあります。引き継ぎでは、前の設計の制約を引き受けることになります。

引き継ぎの見積りと、作り直しの見積りを両方取って比べてください。 比べるときは初期費用だけでなく、その後の改修のしやすさと、運用にかかる費用を含めます。安く引き継いだ結果、改修のたびに費用が膨らむ設計を抱え続けることもあります。

業種×部門で当てはめる

ここまでの手順を、実際の業務に当てはめて確認します。以下は想定の典型例で、特定の顧客の実績ではありません。

例：医療法人の事務部門で、外注先を変えるときに引き継ぐ納品物

複数のクリニックを運営する医療法人の事務部門が、患者からのメールとWebフォームの問い合わせを一次分類し、回答の下書きを作るAIツールを外注で開発したとします。分類の対象は、診療時間や持ち物の確認、予約の変更希望、書類の発行依頼、費用の質問などです。運用を始めて1年、対応速度と改修費用を理由に外注先を変えることになりました。

この仕組みで引き継ぐ納品物は、6分類とAI特有の4点に沿って洗い出します。コードと構成図に加えて、プロンプトには「回答のトーン」「診療内容に関わる判断は答えず、担当者に回す」「予約変更は確定させず、受付が確認する」といった人への引き継ぎ条件が書かれているはずで、これが仕様の中核です。評価用データは、過去の問い合わせを匿名化したものと、それぞれの正しい分類の組です。どの版のプロンプトとモデルで測ったかを一緒に受け取ります。APIキーの名義と請求先、そして入出力のログに患者の氏名や症状が含まれ得るかどうか、その保管場所と保管期間を確認します。

患者情報に触れる仕組みであれば、参照すべき公的な基準があります。 厚生労働省の「医療情報システムの安全管理に関するガイドライン」は、第7.0版（令和8年6月）が概説編・経営管理編・企画管理編・システム運用編・保守委託機関編の5編で構成されています。編の名称が示すとおり、経営層、企画や管理を担う部門、システムを運用する担当、保守を委託される事業者と、立場ごとに分冊されています。事務部門は企画管理編とシステム運用編を、新旧の外注先は保守委託機関編を、それぞれ手元に置いて引き継ぎの項目を照合します（出典2）。

同じページには「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」（令和8年6月）が掲載され、医療機関・薬局確認用と事業者確認用の2つの様式があります。医療機関、薬局及び医療情報システム・サービス事業者は、マニュアルを参照しつつチェックリストを活用して対策を行うこととされています（出典2）。外注先を変える場面では、事業者確認用のチェックリストを前の会社と次の会社の両方に記入してもらい、並べて比べる使い方ができます。どちらかが記入できない項目があれば、それが引き継ぎで埋めるべき穴です。

さらに、同ページには「サイバー攻撃を想定した事業継続計画（BCP）策定の確認表」と「医療情報システム部門等におけるBCPのひな形」（令和6年6月発出）、参考資料として経済産業省の「医療情報システムの契約における当事者間の役割分担に関する確認表」へのリンクと「運用管理規程文例」も置かれています（出典2）。引き継ぎ後の運用手順には、AIツールが止まったときに問い合わせ対応を手作業に戻す手順を含め、新しい契約では役割分担の確認表に沿って責任の分界を明文化します。

切り替え当日にやることは、認証情報の変更と、前の外注先の管理者権限の削除、ログの保管場所の自社管理への移管です。誰がいつ何を変更したかの記録を残しておくと、後の監査や点検で説明できます。事務部門にとっての引き継ぎは、コードを受け取ることではなく、患者情報に触れる仕組みの管理責任を自法人の側に戻す作業だと捉えると、優先順位がはっきりします。

次の会社に伝えること

引き継ぎを依頼する際、次を伝えると見積りの精度が上がります。

• なぜ切り替えるのか（費用、対応速度、技術的な限界、担当者の変更など）
• 今の仕組みで困っていること（誤った分類が多い、止まる、改修に時間がかかる）
• 引き継ぎ物として何が揃っているか（6分類とAI特有の4点の仕分け結果）
• 今後やりたいこと（対象業務を広げたい、内製化したい）

1番目を率直に伝えてください。 切り替えの理由が分かると、同じ問題を繰り返さない設計を提案できます。費用が理由なら、改修のたびに見積りが要る構造そのものを変える提案になり、対応速度が理由なら、自社の担当者が軽微な変更を自分でできる形にする提案になります。理由を伏せたまま「引き継いでほしい」と依頼すると、前の設計をそのまま延命する見積りが返ってきます。

引き継ぎ後にやること

認証情報の変更を忘れないでください。 前の外注先がアクセスできる状態が残ります。変更した日付と対象を一覧に残し、権限を削除したことを先方にも通知します。

3ヶ月以内の仕様書の更新は、次に外注先を変えるときのための作業でもあります。引き継いだ時点の資料は、前の会社の視点で書かれています。運用して分かったこと、変えた箇所を反映して、自社の資料として作り直しておくと、次の切り替えで同じ苦労を繰り返しません。

当社が自社で運用して分かったこと

当社は自社サイト500ページ超をAIで開発・運用し、記事の自動公開パイプラインとサイト上のAIチャットも自社で構築して運用しています。運用を続けて分かったのは、「引き継げる状態」は自然には保たれないということです。設定や手順は、担当者の頭の中と個々の端末に散らばっていきます。

そこで当社では、コードと設定と運用手順を一つの場所で管理し、環境変数の一覧、使っているモデルの名称と版、プロンプトの変更履歴を残す形を取っています。誰かが抜けても、別の担当者が同じ手順で公開と改修を続けられる状態を保つためです。この経験から、引き継ぎの可否判断では「資料があるか」より「その資料で別の人が動かせるか」を見ています。お客様の仕組みを引き継ぐときも、納品するときも、同じ基準を使っています。

当社の費用

引き継ぎのご相談では、まず現状の資料を拝見し、引き継げるか、何が欠けているかをお伝えします。引き継ぎ後の改修や機能追加は業務自動化ミニ開発（300,000円〜・税抜・単発）、作り直しが必要な規模であればAI組込み開発（800,000円〜・税抜・要件見積）、外注先への依存を減らして社内で改修できる体制を作りたい場合はAI開発顧問（300,000円/月・税抜・最低3ヶ月）でご一緒します。

引き継ぎの見積りと作り直しの見積りは、両方お出しできます。「作り直したほうが安い」と判断した場合は、その旨をお伝えします。 引き継ぎが常に有利とは限りません。初回30分の相談は無料・オンライン対応・秘密厳守です。

商談で聞かれる質問

Q1. 作業範囲はどこまでですか

当社が担うのは、現状の資料の確認と可否判断、欠けている分類の洗い出し、別環境での動作確認、認証情報とサービス契約の移管手順の設計、引き継ぎ後の改修、運用手順の整備です。発注側にお願いするのは、契約書の確認と前の外注先への提供依頼、名義変更の手続き、既知の課題の聞き取りです。前の外注先との契約上のやり取りは、発注側が主体になります。 当社が同席して技術的な確認事項を整理することはできますが、提供を求める権利は契約の当事者にあるためです。

Q2. 引き継ぎ後の運用は誰がやりますか

日常の運用は発注側の担当者が担います。定期作業の実施、利用量と費用の確認、利用者からの「答えてくれなかった」の受け付けが中心です。納品時に、これらの手順を画面付きで引き渡します。改修が必要になった場合は都度見積り、または開発顧問で継続的にご一緒する形のどちらかです。内製化を進めたい場合は、社内の担当者が軽微な変更を自分でできるように、プロンプトの変更手順と評価用データでの確認手順を先に引き渡します。「納品後の窓口はどこか」は契約前に確認してください。

Q3. 依頼前に何を用意すればよいですか

3点です。第一に、現在の外注先との契約書と、納入物として受け取っているものの一覧。第二に、使っているサービスと契約名義の一覧（分かる範囲で構いません）。第三に、切り替えの理由と、今の仕組みで困っていることの整理。いずれも完成している必要はなく、初回の相談で一緒に整理できます。契約書に納入物の定義があるかどうかが分かるだけでも、引き継ぎの難易度はその場で見えます。

まとめ

• 引き継げるかは「コード・仕様・環境・認証・運用・既知の課題」の6分類で決まる
• AI開発ではさらに「プロンプト・評価用データ・モデルの版・APIの契約名義」を回収する
• 契約が続いているうちに、納入物の範囲を契約書で確認し、書面で提供を依頼する
• 契約名義が外注先のサービスは、切り替え前に自社名義へ移し、通知先も変える
• 非機能の合意水準が資料になければ、次の会社との最初の作業はレベル合わせになる
• 患者情報を扱う仕組みは、厚生労働省ガイドライン第7.0版と事業者確認用チェックリストを新旧の外注先に当てる
• 引き継ぎと作り直しの見積りを両方取って比べる
• 引き継ぎ後は認証情報を変更し、前の外注先の権限を削除する

あわせて読みたい

• AI開発は内製か外注か｜判断の分岐点と、途中で切り替える方法
• AI受託開発の進め方｜発注から納品までの流れ
• AI開発の保守・運用費用｜納品後にかかるAPI利用料・改修コストの内訳
• AI開発のセキュリティ｜発注前に確認すべきデータの扱い・学習利用・保管場所
• AI開発の相見積もり｜同じ条件で比べる
• AI開発顧問とは｜月300,000円で何をしてくれるか・内製化伴走の中身
• AI開発の記事一覧

出典

1. 独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開） — 2020年4月施行の改正民法に対応した契約不適合責任・権利行使の期間制限の見直し、セキュリティ・プロジェクトマネジメント義務及び協力義務・複数契約の関係・再構築対応の論点、契約時に仕様・プロジェクト管理方法・検収方法等の共通理解を持つことへの期待
2. 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版（令和8年6月）」 — 概説編・経営管理編・企画管理編・システム運用編・保守委託機関編の5編構成、医療機関・薬局におけるサイバーセキュリティ対策チェックリスト（医療機関・薬局確認用と事業者確認用）、サイバー攻撃を想定したBCP策定の確認表とひな形、契約における当事者間の役割分担に関する確認表への参照
3. 独立行政法人情報処理推進機構（IPA）「非機能要求グレード」 — ユーザと開発者の非機能要求に関する認識の行き違いを防ぐ目的、項目の網羅的なリストアップと分類、6つの大項目による階層化、要求レベルを段階的に確認する使い方