大手コンサルに1億円払って、生成AI 導入プロジェクトを完了させた。契約が終わり、担当パートナーは去った。残ったのは分厚い最終報告書だけで、日々の運用で参照できるものはほとんどない。半年後、システムに不具合が出て、社内の誰も「なぜこの設計になっているか」を説明できない。DX 推進担当のあなたは、この状況を再演したくないと感じていないでしょうか。
コンサル引き上げ後に「何も残らない」のは偶然ではなく、契約設計と受け止め体制の噛み合わせで起きる構造的な問題です。何が残らないか、なぜ残らないか、次のプロジェクトで防ぐには何を押さえるべきか、を整理します。
残るはずのもの一覧と、実際に残るもの
コンサル引き上げ後、理想的には残るはずの成果物と、実際に残るものにはギャップがあります。
| 残るはずのもの | 実際に残ることが多い | 実際に残らないことが多い |
|---|---|---|
| システム構成図 | ◎ 最終報告書に一枚絵で | 詳細な各コンポーネント設計、更新履歴 |
| API 仕様 | △ 一部の Swagger など | 内部で使ったカスタム関数、非公開API |
| 権限設計 | △ 概要図のみ | 具体的な IAM ポリシー、ロール別の細かな設定 |
| 運用手順書 | △ サンプル | 実運用で必要な障害対応、監視、メンテナンス手順 |
| 業務プロンプト集 | × ほぼ残らない | 業務別の実効プロンプト、失敗パターン |
| 意思決定履歴（なぜその設計にしたか） | × 議事録の断片 | 重要な設計判断の背景、代替案、選定理由 |
| 運用ノウハウ | × 属人的知見 | 「こう来たらこう対応する」の暗黙知 |
| 継続改善のパイプライン | × ほぼ残らない | モデル更新への追随、Playbook 更新の仕組み |
なぜ残らないのか
残らないものが偏る理由は、次の3つに整理できます。
| 理由 | 起きること |
|---|---|
| 契約範囲の限界 | 「システム構築」が契約範囲で、「運用引き継ぎ」は追加費用または対象外 |
| 暗黙知の性質 | コンサル担当者の頭の中にある「なぜそう設計したか」は文書化しにくい |
| 受け手側の準備不足 | 社内側に受け止める担当者・組織がいないと、残そうとしても残せない |
契約時に押さえるべき納品物リスト
次のプロジェクトで「残らない」を避けるには、契約段階で納品物を明示的に指定します。汎用的な「最終報告書一式」では足りません。
| カテゴリ | 指定すべき納品物 |
|---|---|
| システム | 構成図（詳細版）、API 仕様、権限設計（実 IAM ポリシー付き）、データフロー図 |
| 運用 | 運用手順書（障害対応・監視・メンテナンス）、SLA、エスカレーション経路 |
| 業務 | 業務別プロンプト Playbook（20〜30プロンプト）、失敗パターン集、Q&A |
| 意思決定 | 設計判断の背景資料（少なくとも主要 10 件、代替案と選定理由付き） |
| 継続改善 | モデル更新への追随計画、Playbook 更新プロセス、KPI ダッシュボード仕様 |
| 引き継ぎ | 社内担当者との 3〜6 ヶ月の並走期間、質問対応の SLA |
受け止める体制の設計
納品物を指定しても、社内に受け止める体制がないと形骸化します。次の役割を、コンサル契約と並行して社内で立てます。
| 役割 | 責任 | 工数 |
|---|---|---|
| プロジェクトオーナー | 契約全体の意思決定、経営層との橋渡し | 週5時間 |
| システム引き受け担当（情シス） | システム構成・API・権限設計の理解、日々の運用引き受け | 週10〜15時間 |
| 業務引き受け担当（各部門） | 業務プロンプト・運用ノウハウの理解、部門内展開 | 部門ごと週5時間 |
| ドキュメント担当 | 納品物の受入検査、社内 wiki への転載、更新責任 | 週5〜8時間 |
この体制がゼロの状態でコンサルを入れると、契約終了と同時に納品物が本棚に眠ります。1億円のプロジェクトなら、社内側で少なくとも3〜4名の並走担当が必要です。
並走期間の設計
コンサル引き上げの前後3〜6ヶ月は、並走期間として設計します。この期間の設計を怠ると、引き継ぎは失敗します。
| 時期 | 並走のポイント |
|---|---|
| 引き上げ 3ヶ月前 | 納品物の初版レビュー、社内担当者が理解できるかチェック |
| 引き上げ 1ヶ月前 | 運用ドキュメントを社内担当者だけで読み解いてみる、コンサルは質問対応のみ |
| 引き上げ 1ヶ月後 | 社内担当者だけで運用、コンサルはリモート相談窓口として週2時間 |
| 引き上げ 3ヶ月後 | コンサル相談窓口を月2時間に縮小、社内で完全自走 |
| 引き上げ 6ヶ月後 | コンサル相談窓口を四半期に1回のヘルスチェックに切り替え |
既に「何も残らない」状態からの復元
すでにコンサルが去って半年、残ったものが不十分、というケースからの復元は次の3ステップで進めます。
| ステップ | 内容 | 所要 |
|---|---|---|
| 1. 残っているものの棚卸し | 文書、コード、設定ファイル、Slack ログ、メール履歴を全部集める | 1〜2週間 |
| 2. 抜けの特定 | 「残るはず vs 実際」の対比表で、抜けている項目をリスト化 | 1週間 |
| 3. 抜けを埋める作業 | システムを実際に触りながら、抜けた文書を復元する | 2〜3ヶ月 |
この復元作業を全部社内でやるのは非現実的なケースが多く、外部支援で「システムを読み解いて文書化する」パートを補うのが実務的です。
大手コンサル / FDE / 中堅ブティックの引き継ぎ姿勢の違い
引き継ぎの丁寧さは、業者の規模や姿勢で差があります。次を把握して選定します。
| 業者タイプ | 引き継ぎの傾向 | 納品物の充実度 |
|---|---|---|
| 大手戦略コンサル | 戦略・設計は充実、運用引き継ぎは薄い | △〜○ |
| 大手 SIer / FDE 派遣型 | システム構築は充実、業務ドメイン理解は薄い | ○ |
| 中堅ブティック（データ・AI特化） | 納品物を厚くしないと次の案件が来ない、事業直結の資料が多い | ◎ |
| フリーランス個人 | 属人性が高い、引き継ぎは契約で明示しないと危うい | △ |
まとめ
AI 導入コンサルが去った後に何も残らないのは、契約範囲の限界・暗黙知の性質・受け手側の準備不足の3つが重なって起きます。次のプロジェクトでは、納品物リストを契約段階で明示、社内で受け止める体制を並行して立てる、引き上げ前後 3〜6 ヶ月の並走期間を設計する、の3点を押さえます。既に何も残らない状態からの復元は、外部支援で「システムから文書を復元する」パートを補うのが現実解です。
「うちの場合はどこから手をつけるべきか」の見立てを掴みたい場合は、AI浸透支援 by DE-STKのAI浸透スコア診断（2週間・25万円）が入口として使えます。現状の利用実態、構造的な原因、次に打つべき手の候補まで、社内の投資判断に耐える粒度でお出しします。
あわせて読みたい
- 生成AI導入後の「使われない」を解消する：現場浸透の設計と実装
- Forward-Deployed Engineer（FDE）が去った後、AIプロジェクトを引き取る組織設計
- 生成AI導入が本番後にストールする5段階の兆候と切り分け方
- 生成AIの社内推進役の設計：兼任1名で回らない構造をどう解体するか
- AI現場浸透のためのプロンプトPlaybookを作る手順とテンプレート
よくある質問
Q. 契約時に納品物を厳密に指定すると、コンサル側の見積が跳ね上がりませんか？
A. 見積は上がることが多いです。ただし、後で追加費用や、復元作業のコストを別途出すよりトータルで安いケースがほとんどです。1億円の案件で納品物を厳密化して1割上がっても、後で復元に3千万かかるより安い、という試算になります。
Q. 社内側の並走担当を出せない場合、どうすればいいですか？
A. その時点で、コンサル引き上げ後に何も残らない状態が高い確率で起きます。並走担当を出せないなら、コンサル選定時に「引き継ぎ支援を月次で継続する契約」を追加で結ぶのが現実解です。または、規模を絞ってでも社内担当を1名出せる体制を作る方向で経営層と交渉します。
Q. 既に去られてしまい、システムの中身が分からない場合、どう始めますか？
A. まず「動いているシステム」を触りながら、機能単位で「何が動いているか」を棚卸しします。この作業は 2〜3 ヶ月かかります。外部支援でこのパートを任せると、社内担当者はシステム理解に集中できます。文書化と実務理解を並行で進めるのが、時間を無駄にしない進め方です。