AI導入の責任者になったものの、社内にAIの専門人材がおらず、次のような疑問を抱えていないでしょうか。
- 要件定義をどこまでベンダーに任せてよいのか
- ツールやAIモデルは自社とベンダーのどちらが決めるのか
- AIの精度基準や合格ラインは誰が設定するのか
- 運用開始後も外注し続けてよいのか
AI導入では、「すべて内製する」「すべて外注する」という会社単位の二択で考えると、役割や責任が曖昧になりやすくなります。大切なのは、AIを導入する対象業務を工程まで細分化し、工程ごとに次の4つを割り当てることです。
- 自社が判断すること
- 自社とベンダーが共同で設計すること
- 外部へ実行を任せること
- 導入後に自社へ残す資産
さらに、各工程について「決める人」「実行する人」「承認する人」「知識を受け取る人」を分けておけば、ベンダーへ依頼する範囲と自社が担う責任が明確になります。

結論|AI導入は会社単位ではなく「業務×工程×役割」で分ける
AI導入の内製・外注を考えるとき、最初に決めるべきなのは「自社は内製型か、外注型か」ではありません。最初に行うべきなのは、対象業務を工程に分解することです。
たとえば、問い合わせへの回答案を生成するAIを導入する場合、少なくとも次のような工程があります。
- 解決したい業務課題の整理
- 現在の問い合わせ対応フローの可視化
- AIに参照させるデータの選定
- 個人情報や機密情報の確認
- 要件定義
- ツールやAIモデルの選定
- PoCによる検証
- 精度評価
- 本番環境の構築
- 利用ルールの策定
- 現場への教育
- 運用監視
- 改善
- 契約終了時の引き継ぎ
これらすべてを同じ担当者や同じ会社が行う必要はありません。業務目的や顧客対応方針は自社が決め、AIモデルの技術検証はベンダーへ任せる。精度の測定方法は共同で設計し、テスト作業はベンダーに実行してもらう、という分け方も可能です。
4つの迷いに対する結論
| 迷い | 基本的な役割分担 |
|---|---|
| 要件定義をどこまで任せるか | 業務目的、優先順位、例外、許容できない失敗は自社が決め、技術要件への変換や文書化はベンダーと共同で行う |
| ツールやAIモデルを誰が選ぶか | 自社が評価基準を決め、ベンダーが候補を比較・検証し、自社が最終承認する |
| 精度基準を誰が決めるか | 自社が業務上の許容範囲を決め、ベンダーが測定可能な指標へ変換し、双方で合意する |
| 運用を外注し続けてよいか | 監視や調整などの作業は継続外注できるが、KPI、変更判断、データ定義、リスク受容、知識は自社に残す |
つまり、AI導入で外注しやすいのは「作業」です。完全に外部へ渡してはいけないのは、「なぜ導入するのか」「何をもって成功とするのか」「どのリスクまで許容するのか」という事業上の判断です。
AI導入における内製・外注・ハイブリッドとは?
AI導入における内製と外注は、「AIモデルを自社で開発するかどうか」だけで決まるものではありません。業務設計、データ管理、評価、運用、改善なども含めて考える必要があります。

AI導入の内製とは
AI導入の内製とは、AIに関する工程を社内の人材が担うことです。ただし、必ずしも自社で独自のAIモデルを開発することだけを意味しません。外部の生成AIサービスを利用していても、次の内容を自社で管理していれば、一定の内製能力があるといえます。
- AIを使う業務の選定
- プロンプトや指示文の管理
- AIに参照させる社内文書の管理
- 利用ルールの策定
- テストケースの作成
- 出力結果の評価
- 改善の優先順位付け
- 社員への教育
- 問い合わせや障害の一次対応
内製の本質は、技術をすべて自社で作ることではなく、AIを業務で使い続けるための判断能力と改善能力を社内に持つことです。
AI導入の外注・外部委託とは
AI導入の外注とは、専門的な調査、設計、開発、設定、運用などを外部のベンダーや専門家へ委託することです。外部委託しやすい業務には、ヒアリング、現行業務の整理、技術的な実現可能性の調査、データの整形、ツール比較検証、PoC環境の構築、システム連携、管理画面構築、セキュリティ設定、テスト実施、運用監視、チューニング、障害調査などがあります。
社内にAI専門人材がいない場合、こうした作業を外部へ委託することは現実的な選択です。ただし、外部へ任せる範囲が曖昧なまま契約すると、追加費用や手戻り、ベンダー依存が発生しやすくなります。
工程別ハイブリッドとは
AI導入では、工程ごとに内製と外注を組み合わせる「工程別ハイブリッド」が基本になります。重要なのは、会社全体を「ハイブリッド型」と呼んで終わらせないことです。どの工程を誰が担当するかまで落とし込まなければ、実際のプロジェクトでは使えません。
内製・外注のメリットとデメリット
| 比較項目 | 内製 | 外注 |
|---|---|---|
| 導入スピード | 人材や経験が不足していると時間がかかる | 経験のあるベンダーなら短縮しやすい |
| 技術力 | 社内人材のスキルに左右される | 専門知識を活用しやすい |
| 業務理解 | 自社のルールや例外を反映しやすい | ヒアリングと情報共有が不足するとずれやすい |
| 初期費用 | 採用や育成を含めると大きくなる場合がある | 見積もりにより予算を把握しやすい |
| 社内工数 | 多くなりやすい | 実作業の負担を減らしやすい |
| 変更のしやすさ | 社内で対応できれば迅速 | 契約や追加費用が必要になる場合がある |
| 知識の蓄積 | 社内に残りやすい | 知識移管を設計しなければ残りにくい |
| 品質管理 | 評価できる人材が必要 | 専門的な検証を依頼できる |
| セキュリティ | 社内管理しやすいが、対策能力が必要 | 外部提供範囲や再委託先の確認が必要 |
| ベンダー依存 | 比較的抑えやすい | 設定やノウハウが外部だけにあると依存しやすい |
| 継続運用 | 担当者の退職や異動がリスクになる | 継続費用や契約終了時の移行が課題になる |
| 他業務への展開 | 知識があれば横展開しやすい | 案件ごとに追加依頼が必要になる場合がある |
費用を比較するときは、初期費用だけでなく、運用、改修、教育、障害対応、契約終了時の移行まで含めた総費用で考えることが重要です。
生成AIの内製・外注は「独自モデルを作るか」だけではない
生成AIの導入では、「既存サービスを使うなら外注」「独自モデルを開発するなら内製」という分け方は適切ではありません。既存の生成AIサービスを使う場合でも、どの業務で使うか、どの情報を入力してよいか、どの社内文書を参照させるか、出力をそのまま利用できるか、どの場面で人が確認するか、誰が設定を変更できるかといった設計が必要です。
生成AIの内製化を考えるときは、モデル開発の有無ではなく、業務ルール、評価データ、プロンプト、参照文書、改善手順を自社で管理できているかを確認しましょう。
AI導入の対象業務を工程まで分解する
内製と外注の役割を決める前に、対象業務を工程へ分解します。「問い合わせ対応をAI化する」といった大きな単位のままでは、誰が何を担当するのかを決められません。

導入目的と成果指標を決める
最初に、自社がAIを導入する目的を明確にします。AIを使わない選択肢と比較したうえで、改善したい指標(回答作成時間、修正率、初回返信時間、エスカレーション率、誤案内件数など)も決めます。成果指標は、ベンダーではなく業務を所有する自社が決める必要があります。
現行業務と例外処理を洗い出す
AI導入で失敗しやすい原因の一つが、通常の業務フローだけをベンダーへ説明し、例外処理を共有していないことです。上長確認が必要な条件、法務確認が必要な条件、顧客ごとに異なる契約条件、返金・苦情・事故などの例外、回答してはいけない内容まで洗い出します。現場で「その都度判断している」部分は、AI導入時に重要な要件になります。
データ・権限・リスクを確認する
AIが利用するデータについては、内容だけでなく管理責任も確認します。データの種類、管理部署、個人情報や機密情報の有無、AIサービスへの送信可否、学習への利用可否、保存場所、保存期間、アクセス権限、契約終了時の削除方法などを整理します。「ベンダーだから安全だろう」と判断せず、実際の契約条件とデータフローを確認することが重要です。
要件定義とツール選定を分ける
先に製品を決めると、その製品で実現できる範囲だけで業務設計を行うことになり、本来解決したかった課題からずれる可能性があります。先に、AIが支援する業務、利用者、必要な機能、回答してよい範囲、人が確認する範囲、必要な応答速度、データ連携、予算、導入時期などの要件を整理し、その後に複数のツールやAIモデルを比較します。
PoCと精度評価を設計する
PoCは、AIを試しに動かすことだけが目的ではありません。「本番導入へ進むかどうかを判断するために、何を確認するのか」を明確にする必要があります。検証範囲、テストデータ、代表的なケース、絶対に誤ってはいけないケース、合格条件、評価担当者、本番導入を承認する人を事前に決めます。テストデータや合格条件までベンダー任せにしないことが重要です。
本番構築・教育・運用も工程に含める
AIが技術的に動くだけでは、導入は完了しません。アカウント設定、権限設定、業務システムとの連携、利用マニュアル、入力してよい情報の周知、誤回答の報告方法、問い合わせ窓口、利用者教育まで工程に含めます。教育や運用を要件定義から外すと、AIは導入されたものの現場で使われない状態になりやすくなります。
改善と終了判断まで設計する
業務ルール、社内文書、AIモデル、外部サービスの仕様などが変わるため、継続的な確認が必要です。どの指標を定期確認するか、誤回答を誰が分析するか、改善の優先順位を誰が決めるか、重大な問題時に誰が停止するか、契約終了時に受け取るデータや文書まで、あらかじめ決めておきます。
AI導入の役割を「決める・実行する・承認する・知識を受け取る」に分ける
工程を分解したら、それぞれに4つの役割を設定します。

決める人
「決める人」は、どの業務を対象にするか、何を優先するか、どの機能を必須とするか、どの誤りを許容しないか、どこまで人が確認するかといった業務上の判断を行います。業務内容に関する決定は、業務責任者や現場責任者が担います。技術的な選択には助言を受けられますが、業務上の目的をベンダーだけで決めることはできません。
実行する人
「実行する人」は、調査、設計、開発、設定、テスト、教育、監視などの作業を担当します。工程によって、社内担当者とベンダーのどちらも実行者になれます。「実行する人」と「決める人」を分けることで、ベンダーへ作業を任せながら、自社が判断権を維持できます。
承認する人
「承認する人」は、予算、契約、要件定義書、セキュリティ対策、PoC結果、本番公開、利用ルール、サービス停止、契約終了などを正式に認める役割です。日常的に判断する人と、経営・リスク面から正式に承認する人を区別しておくと、責任が明確になります。
知識を受け取る人
「知識を受け取る人」は、ベンダーから報告書やマニュアルを受け取るだけの人ではありません。仕組みの概要を説明でき、利用データや主な設定を把握し、精度評価の方法を説明でき、一次切り分けができ、ベンダー変更時の引き継ぎを主導できる状態を目指します。知識を受け取る人を決めないまま外注すると、担当ベンダーだけが設定や経緯を理解している状態になりやすくなります。
4人を別々にする必要はない
中小企業では、一人が複数の役割を兼ねても問題ありません。重要なのは、人数を増やすことではなく、4つの役割に空欄を作らないことです。部署名だけではなく、できる限り主担当者名、代替担当者名、決められる範囲、承認が必要になる条件まで記載します。
【役割分担表】自社判断・共同設計・外部実行・自社に残す資産
以下は、AI導入の工程別に役割を整理した表です。自社の業務や組織体制に合わせて、項目を追加・変更してください。
表1|業務・工程別の作業振り分け表
| 工程 | 自社判断 | 共同設計 | 外部実行 | 自社に残す資産 |
|---|---|---|---|---|
| 導入目的・対象範囲 | 解決する課題、対象業務、KPI、対象外、予算上限 | 実現可能性、導入範囲、優先順位 | ヒアリング支援、資料化 | プロジェクト方針書、KPI、判断記録 |
| 現行業務の整理 | 実際の業務ルール、例外、責任範囲 | AI導入後の業務フロー | ヒアリング、業務フロー作成 | 業務フロー、用語集、例外一覧 |
| データ確認 | データ所有者、利用目的、外部提供の可否 | 必要データ、匿名化、更新方法 | データ調査、整形、連携 | データ台帳、項目定義、更新手順 |
| 権限・セキュリティ | 利用者、承認者、アクセス方針 | 権限設計、ログ、認証方式 | 技術設定、テスト | 権限一覧、構成図、セキュリティ設定 |
| 要件定義 | 必須機能、優先順位、許容できない失敗 | 技術要件、非機能要件、代替案 | 要件定義書のドラフト、調査 | 要件定義書、論点一覧、決定履歴 |
| ツール・モデル選定 | 評価基準、予算、契約上の条件 | 候補比較、採用構成 | ベンチマーク、技術検証 | 比較表、選定理由、見送り理由 |
| PoC設計 | 成功条件、代表ケース、対象外 | 指標、測定方法、検証計画 | 試作環境構築 | PoC計画書、テストデータ |
| 精度評価 | 業務上の合否、許容範囲 | 合格ライン、再評価条件 | テスト実行、結果集計、原因分析 | 評価結果、正解例、失敗例 |
| 本番構築 | 権限、接続先、業務上の制約 | 構成、移行計画、障害対応 | 開発、設定、連携、技術テスト | 構成図、設定一覧、ソースや仕様 |
| 検収・公開 | 業務で利用できるか | 未達項目への対応 | 測定、修正、報告 | 検収記録、初期基準値、残課題 |
| 教育・展開 | 利用ルール、対象者、禁止事項 | 研修内容、問い合わせフロー | マニュアル、研修支援 | 研修資料、FAQ、利用ルール |
| 運用 | KPI、変更の優先順位、停止判断 | 運用フロー、定例会、報告内容 | 監視、保守、調整、レポート | ログ、運用記録、改善履歴 |
| インシデント対応 | 停止・再開、社内外への対応 | 原因分析、再発防止 | 技術調査、復旧、改修 | 対応履歴、原因、再発防止策 |
| 契約終了・引き継ぎ | 終了条件、移行先、残す機能 | 移行計画、スケジュール | データ出力、文書化、移行支援 | データ、設定、評価資産、運用文書 |

表2|決める人・実行する人・承認する人・知識を受け取る人
| 主な工程 | 決める人 | 実行する人 | 承認する人 | 知識を受け取る人 |
|---|---|---|---|---|
| 対象業務・KPI | 業務責任者 | AI導入責任者、現場担当者 | 経営者、部門長 | AI導入責任者 |
| 現行業務の整理 | 業務責任者 | 現場担当者、ベンダー | 部門長 | 業務改善担当者 |
| 要件定義 | 業務責任者、AI導入責任者 | 現場担当者、ベンダーPM | 部門長、情報システム責任者 | 社内PM、運用担当者 |
| ツール・モデル選定 | AI導入責任者、情報システム | ベンダー、社内IT担当者 | 部門長、セキュリティ責任者 | 社内IT担当者 |
| データ管理 | データ管理者、業務責任者 | 社内担当者、ベンダー | 情報管理責任者 | データ管理担当者 |
| セキュリティ | 情報システム責任者 | 社内IT、ベンダー | セキュリティ責任者 | 社内IT担当者 |
| PoC・精度評価 | 業務責任者 | ベンダー、現場テスト担当者 | 部門長 | 社内評価担当者 |
| 本番公開 | AI導入責任者 | ベンダー、社内IT | 部門長、情報管理責任者 | 運用担当者 |
| 教育・利用ルール | 業務責任者 | 運用担当者、ベンダー | 部門長 | 教育担当者、運用担当者 |
| 運用・改善 | 業務責任者、AI導入責任者 | 運用担当者、ベンダー | 部門長 | 社内運用責任者 |
| 障害対応 | AI導入責任者、情報システム | ベンダー、社内IT | 情報システム責任者 | 社内IT、後任担当者 |
| 契約終了・移行 | AI導入責任者 | ベンダー、社内担当者 | 経営者、部門長 | 後任担当者、社内IT |
最初からすべてを確定させる必要はありません。まずは自社側で仮の分担を記入し、ベンダーとの打ち合わせで見直します。自社判断の列が空欄になっていないか、外部実行と最終決定が混同されていないか、知識を受け取る担当者が決まっているかを確認しましょう。
AI導入で自社がやることとベンダーに任せる範囲
ここからは、AI導入責任者が特に迷いやすい4つのポイントを詳しく解説します。

要件定義はどこまでベンダーに任せてよいか
要件定義書を自社だけで完成させてからベンダーへ相談する必要はありません。ヒアリング、論点整理、技術要件への変換、要件定義書の作成支援はベンダーへ依頼できます。ただし、ベンダーへ任せられるのは「整理」「提案」「技術への変換」です。業務上の目的や判断まで、すべて任せてはいけません。
自社が決めること
- AIを導入する目的
- 対象業務と対象外業務
- 現場の業務ルールと例外処理
- 必須機能と優先順位
- 予算の上限
- 許容できない失敗
- 人による確認が必要な場面
- セキュリティや法務上の制約
- 最終的な本番利用の可否
ベンダーへ任せられること
- ヒアリング項目の設計
- 現行業務の整理・課題の構造化
- 技術要件への変換
- 実現方法の提案・複数案の比較
- 要件定義書のドラフト作成
- 開発工数の見積もり・スケジュール作成
要件定義を外注する際は、完成した文書だけを受け取るのではなく、なぜその要件になったのかという決定経緯も残しましょう。
ツールやAIモデルの選定は誰が決めるか
ツールやAIモデルについては、ベンダーの提案を受けながら、自社が最終決定する形が基本です。自社が決めるべきなのは、ツールを評価するための条件です。
- 対象業務に必要な機能があるか
- 個人情報や機密情報を入力できる条件か
- 入力データがモデルの学習に使われるか
- データの保存場所と保存期間
- 既存システムと連携できるか
- 必要な日本語性能・応答速度があるか
- 契約終了時にデータを取り出せるか
- 別のモデルやベンダーへ変更できるか
特定製品を扱うベンダーに相談する場合は、その製品だけでなく、代替手段や採用しない場合の選択肢も確認しましょう。比較表には「採用しなかった理由」も残しておくと、将来の見直しに役立ちます。
精度基準は自社とベンダーのどちらが決めるか
精度基準は、自社とベンダーが共同で設計します。ただし、役割は異なります。自社は「どの誤りを許容できるか」を決め、ベンダーは業務条件を測定可能な指標へ変換し、双方でテスト方法と合格ラインを合意し、最終的な業務利用は自社が承認します。
AIの評価では、単一の正解率だけでなく、業務上の失敗を種類別に確認することが重要です。
| 評価項目 | 確認する内容 |
|---|---|
| 事実の正確性 | 社内規程や商品情報と異なる回答をしていないか |
| 根拠の明示 | 参照した文書や情報源を確認できるか |
| 回答範囲 | 対象外の質問に無理に回答していないか |
| 禁止事項 | 法務確認が必要な内容を断定していないか |
| 重要情報の網羅 | 回答に必要な条件や注意事項が抜けていないか |
| 表現品質 | 顧客に適した言葉遣いになっているか |
| 一貫性 | 同じ条件で大きく異なる回答をしていないか |
| 回答不能時の動作 | 分からない場合に適切に人へ引き継げるか |
| 応答時間 | 業務で許容できる時間内に回答するか |
| 修正負担 | 担当者による修正にどれくらい時間がかかるか |
特に重要な業務では、平均的な精度よりも「重大な誤りが発生しないこと」を重視する場合があります。100件中95件が正しくても、残り5件に返金条件や契約内容の重大な誤案内が含まれていれば、本番利用には適さない可能性があります。
メール送信や発注などを自動で行うAIエージェントでは、文章の正確性だけでなく、どの操作を実行できるか、実行前に人の確認が必要か、金額や件数に上限があるか、異常時に停止できるか、外部からの不正な指示に影響されないか、といった「行動」の評価も必要です。
運用開始後も外注し続けてよいか
AI導入後の運用を継続して外注すること自体に問題はありません。ただし、「運用を外注すること」と「運用を把握しないこと」は異なります。
継続して外注しやすい業務
- 稼働状況の監視
- 技術的な障害対応
- バージョン更新・プロンプトの調整
- データ連携の保守
- 定期レポートの作成
- 改修作業・バックアップ・セキュリティ更新
自社に残すべき役割
- 業務KPIの管理
- 利用ルールの決定
- 改善の優先順位
- 出力を業務で採用するかの判断
- データの意味と管理責任
- 本番停止と再開の判断
- ベンダー変更・契約終了の判断
- 社内への知識蓄積
外注先から毎月レポートを受け取っていても、その内容を社内で判断できなければ、実質的な管理はできていません。
内製・外注の役割分担を決める7つの判断基準
工程ごとの役割分担は、次の7つの基準で判断します。
1. 業務の競争力への影響
自社独自のノウハウや顧客価値に直結する判断は、自社が主導します。技術的な実装は外注しても、業務ルールの所有者は自社に置きましょう。
2. 現場の暗黙知の多さ
マニュアルだけでは説明できない判断が多い業務では、現場担当者の参加が不可欠です。実際の業務を見てもらう、例外ケースを共同で整理するといった進め方が必要です。
3. データの機密性
顧客情報や営業秘密を扱う場合は、外部へ渡す範囲を限定します。社内環境で作業してもらう方法や、匿名化したデータで検証する方法も検討します。
4. 必要な技術の専門性
高度なデータ処理やモデル開発は外部の専門知識を活用しやすい工程です。ただし、評価や承認までベンダーだけに任せる必要はありません。
5. 変更頻度
頻繁に業務ルールが変わる部分を完全に外注すると、変更のたびに費用や待ち時間が発生します。日常的に変更する設定は自社で更新できる構成にすることも検討します。
6. 失敗した場合の影響
誤りの影響が大きい業務では、自社による確認と承認を厚くします。AIの自動実行範囲を限定し、最終判断を人が行う設計も必要です。
7. 知識を社内へ蓄積する価値
複数業務へ展開する予定があるなら、業務分解の方法、データ定義、評価データ、運用手順などを自社資産として残す価値が高くなります。
業務別に見るAI導入の内製・外注の分け方
社内ナレッジ検索・生成AIチャット
- 自社判断:参照させる文書、回答してよい範囲、回答禁止事項
- 共同設計:検索方法、引用表示、回答不能時の動作
- 外部実行:検索基盤の構築、データ取り込み、既存システム連携
- 自社資産:文書一覧、評価用の質問、正解例、更新手順、利用ルール
問い合わせ対応・回答案生成
- 自社判断:顧客対応方針、回答禁止事項、エスカレーション条件
- 共同設計:AIが作成する範囲、担当者が確認する範囲、CRM連携
- 外部実行:回答生成機能の構築、CRM連携、ログ管理
- 自社資産:回答基準、FAQ、テストケース、エスカレーションルール
需要予測・売上予測
- 自社判断:予測を何の判断に使うか、許容誤差、最終的な発注判断
- 共同設計:利用データ、予測単位、評価指標、再学習条件
- 外部実行:データ加工、モデル構築、予測処理、システム連携
- 自社資産:データ定義、基準となる従来手法、評価結果、予測利用ルール
AI導入を外部委託する前にベンダーと合意すること
外部委託では、作業範囲だけでなく、成果物、品質、データ、知識移管、契約終了時の対応まで合意します。

依頼前に自社で整理する項目
- AI導入を検討している業務と現在の業務フロー
- 現場が困っていること・改善したい指標
- 利用できるデータと個人情報・機密情報の有無
- 既存システムとセキュリティ上の制約
- 導入希望時期と予算の考え方
- 社内の決定者と承認者
詳細な要件定義書がなくても相談できます。ただし、業務課題と現状を説明できる状態にしておくと、提案を比較しやすくなります。
成果物として受け取るもの
- 要件定義書・業務フロー・システム構成図
- データ項目定義書・権限一覧
- 評価設計書・テストデータ・評価結果
- プロンプト・設定パラメータ・API仕様
- 操作マニュアル・運用マニュアル・障害対応手順
- 変更履歴・研修資料・引き継ぎ資料
「一式」「必要な資料」などの曖昧な表現ではなく、具体的な名称と形式を決めます。
契約で確認する項目
- 委託する作業範囲・作業対象外・成果物・納品形式
- 検収条件・精度未達時の対応・追加作業の費用
- データの利用目的・保存場所・学習利用・再委託
- 契約終了後のデータ削除・AI生成物の利用条件・知的財産権
- セキュリティ事故時の連絡・保守運用の対象
- 知識移管・契約終了時の引き継ぎ・データや設定の出力方法
生成AIは、同じような入力でも出力が変化することがあり、一定の精度を成果として保証することが難しい場合があります。そのため契約では「達成すべき品質や完成条件」と「品質向上のために実施する作業」を分けて考えます。重要なデータや知的財産を扱う場合は、法務担当者や弁護士にも確認してください。
知識移管の完了条件を決める
「マニュアルを納品したため知識移管は完了」としないことが重要です。完了条件として次の状態を設定します。
- 社内担当者が基本操作を行える
- 社内担当者が主要な設定を説明できる
- データ更新・定期作業・評価テストを再実行できる
- 問題発生時に一次切り分けができる
- 後任者へ説明できる/ベンダー変更時の資料を把握している
AI導入の役割分担を決める6つの手順

手順1|対象業務を一つに絞る
課題が明確で評価しやすい業務を一つ選びます。「営業部門全体」ではなく「商談後のお礼メール案作成」など、具体的な作業まで絞ります。
手順2|業務を工程と判断ポイントに分解する
通常の作業だけでなく、例外、承認、差戻し、記録、障害時の対応まで整理し、各工程で「誰が何を見て判断しているか」を確認します。
手順3|4つの区分へ振り分ける
各工程を「自社判断」「共同設計」「外部実行」「自社に残す資産」へ振り分けます。一つの工程に複数の区分があっても問題ありません。
手順4|4つの役割へ担当者名を入れる
「決める人」「実行する人」「承認する人」「知識を受け取る人」ごとに、主担当者と代替担当者を設定します。
手順5|成果物と自社に残す資産を決める
ベンダーから何を受け取るかを、提案依頼や見積もりの段階で一覧にします。
手順6|ベンダーと見直し、契約へ反映する
自社で作成した役割分担は仮案です。ベンダーの意見を受けて修正し、分担、成果物、検収条件、知識移管を契約書や要件定義書へ反映します。
役割分担表は契約後も更新します。担当者、対象業務、使用モデル、データ、運用方法が変わった場合は、分担も見直しましょう。
AI導入の内製・外注でよくある失敗
ベンダーに業務目的まで決めてもらう
ベンダーは技術的な解決方法を提案できますが、自社の経営課題や優先順位を最終決定する立場ではありません。
ツールを先に決めてから対象業務を探す
製品に業務を合わせることになりやすくなります。まず課題と要件を決め、その後に候補を比較しましょう。
「精度が高いこと」だけを要件にする
誤回答、見逃し、対象外回答、回答不能、修正時間など、業務上の失敗に分けて評価します。
PoCのテストデータをベンダー任せにする
自社固有の難しいケースが抜ける可能性があります。現場担当者が代表・例外・重大リスクのケースを選びます。
納品物に評価データや設定情報が含まれていない
後から改善や再評価を行えません。将来必要になる資産まで成果物に含めます。
知識を受け取る担当者を決めていない
判断経緯や技術的な知識が社内へ蓄積されません。継続して知識を受け取る担当者を決めます。
契約終了時の移行条件を確認していない
データ、設定、プロンプト、ログ、評価資産をどの形式で受け取れるか確認しましょう。
AI導入の内製・外注に関するよくある質問
AI導入は社内にAI専門人材がいなくても進められますか?
進められます。技術調査、PoC、開発、システム連携、運用監視などは外部へ委託できます。ただし、業務目的、対象範囲、許容できない失敗、最終的な利用可否を判断する社内担当者は必要です。ベンダーから設定や評価方法を引き継ぐ担当者も決めておきましょう。
AI導入の要件定義をすべてベンダーに任せてもよいですか?
要件定義書の作成、技術要件への変換、実現方法の比較などは依頼できます。一方、解決したい業務課題、現場のルール、優先順位、対象外業務、許容できない失敗は自社が決める必要があります。要件定義は、共同で作るものと考えるとよいでしょう。
AIの精度目標は何%に設定すればよいですか?
一律に決めることはできません。平均的な正解率だけでなく、重大な誤回答、見逃し、対象外質問への回答、修正にかかる時間などを分けて評価します。誤りが顧客や経営に与える影響、人による確認の有無を踏まえて合格条件を設定してください。
AIの運用を継続して外注しても内製化できますか?
実作業を外注していても、業務KPI、評価基準、データ定義、変更判断、運用知識を自社に残していれば、一定の内製能力を確保できます。内製化は、すべての作業を社員が行うことではありません。
生成AIの内製化とは、独自のAIモデルを開発することですか?
独自モデルの開発だけではありません。既存の生成AIサービスを利用していても、プロンプト、参照データ、評価方法、利用ルール、業務フロー、改善履歴を自社で管理していれば、業務活用に必要な知識を内製化できます。
まとめ|実行は外注できても、判断と知識は自社に残す
AI導入の内製・外注は、会社全体をどちらかに分類して決めるものではありません。対象業務を工程に分解し、工程ごとに自社とベンダーの役割を割り当てます。重要なポイントは次の4つです。
- 内製・外注は業務と工程単位で決める
- 決める人、実行する人、承認する人、知識を受け取る人を分ける
- 技術的な作業は外注しても、業務目的と最終判断は自社に残す
- システムだけでなく、評価データ、設定、判断記録、運用知識を自社資産として受け取る
社内にAI専門人材がいなくても、AI導入を進めることは可能です。まずは一つの対象業務を選び、「自社判断」「共同設計」「外部実行」「自社に残す資産」の4区分で整理するところから始めましょう。
