チャットボットは内製か外注か｜運用責任で選ぶ判断表

問い合わせ対応を自動化したい一方で、チャットボットを内製するか、外注するか、SaaSを利用するか決めきれない場面があります。判断の起点は、構築できるかどうかではなく、公開後の仕事を誰が継続して担うかです。正本の更新、回答内容の確認、有人対応への引継ぎ、障害時の連絡、改善の判断まで含めて担当範囲を整理すると、自社に合う方式を選びやすくなります。 ## チャットボットの内製・外注は公開後の仕事で決める チャットボットは、公開すれば作業が終わる仕組みではありません。商品情報や営業時間、手続きが変われば、回答の根拠となる正本を更新する必要があります。利用者から想定外の質問が届いたときは、回答内容に問題がないかを確認し、必要に応じて設定や案内を修正します。自動回答の対象外となる問い合わせを、どの部署へ引き継ぐかも決めておかなければなりません。 そのため、開発担当者がいるという理由だけで内製を選ぶのは適切ではありません。技術面を担当できても、業務上の正しい回答を判断する責任者がいなければ、内容を更新できないからです。反対に、開発を外注しても、委託先が自社の商品、契約、店舗運営に関する最終判断まで担えるとは限りません。 方式を選ぶ前に、公開後に発生する仕事を次のように分けてください。 - 問い合わせ範囲を決める - 回答の根拠となる正本を作成し、更新する - 公開前後に回答内容を確認する - 対応範囲外の質問を判定する - 有人対応への引継ぎ先と条件を管理する - 障害発生時に一次確認し、適切な窓口へ連絡する - 利用状況を踏まえて改善の要否を判断する このうち、自社でなければ判断できない仕事と、外部へ依頼できる技術作業を切り分けます。業務知識と回答責任は自社が持ち、設定、開発、技術保守など不足する部分を外注先やSaaSで補う方法もあります。全面内製か全面外注かの二択にする必要はありません。 ## 内製・外注・SaaSの担当範囲を比較する 内製では、問い合わせ範囲の決定から開発、回答テスト、公開後の保守まで、自社の担当範囲が広くなります。業務責任者と技術担当者が直接連携できるため、変更の判断や反映方法を社内で決められます。一方で、担当者の異動や繁忙によって更新が止まらない体制が必要です。開発した担当者しか設定を理解していない状態では、継続運用が難しくなります。 外注では、初期開発や連携、技術保守などを委託できます。ただし、委託先が担う範囲は契約によって異なります。納品後の回答修正、正本の更新、障害時の一次確認、改善提案まで含まれるとは限りません。発注前に、自社と委託先の作業を具体的に分ける必要があります。 SaaSでは、提供される機能の範囲で、自社が設定と運用を行う形が基本です。独自開発を行わずに設定できる場合でも、どの問い合わせへ回答するか、何を正本とするか、どの回答を公開するかは自社で決めます。システム上の障害は提供事業者へ連絡し、回答内容の誤りは自社の業務責任者が確認するなど、問い合わせ窓口も分けておく必要があります。 三つの方式を比較するときは、構築時と運用時を分けて確認します。構築時には、問い合わせ範囲の決定、正本の作成と承認、初期設定または開発、回答テスト、公開判断が発生します。運用時には、正本更新、回答確認、有人引継ぎの見直し、障害時の一次確認、システム改修、改善判断が続きます。 | 業務 | 内製 | 外注 | SaaS | |---|---|---|---| | 問い合わせ範囲の決定 | 自社の業務責任者が決定 | 自社が決定し、委託先が要件整理を支援する場合がある | 自社が提供機能の範囲を確認して決定 | | 正本の作成・承認 | 自社が作成・承認 | 自社が承認。作成支援の有無は契約による | 自社が作成・承認 | | 初期設定・開発 | 自社の技術担当者が実施 | 委託先が契約範囲で実施 | 自社が設定。導入支援の範囲は製品・契約による | | 回答テスト | 自社が質問と回答を確認 | 委託先が試験を実施しても、自社が業務上の正しさを確認 | 自社が提供機能を使って確認 | | 公開判断 | 自社が最終判断 | 自社が最終判断。委託先の作業範囲は契約による | 自社が最終判断 | | 正本更新 | 自社が更新 | 自社が更新するか、契約範囲で委託 | 自社が更新。反映方法は製品仕様による | | 回答確認 | 自社の業務責任者が確認 | 自社が確認するか、確認作業を契約範囲で委託 | 自社が確認。確認手段は製品仕様による | | 有人引継ぎの設計 | 自社が窓口と条件を設計 | 自社が方針を決め、委託先が契約範囲で設定 | 自社が方針を決め、提供機能の範囲で設定 | | 障害時の一次確認 | 自社が原因を切り分ける | 自社または委託先が対応。連絡順序は契約による | 自社が回答内容とシステム障害を切り分け、必要に応じて提供事業者へ連絡 | | システム改修 | 自社の技術担当者が実施 | 委託先が契約範囲で実施 | 提供事業者の製品仕様に依存。自社設定で対応できる範囲もある | | 改善判断 | 自社が業務上の優先順位を判断 | 自社が判断し、委託先が提案する場合は契約による | 自社が判断。利用できる情報や変更範囲は製品仕様による | 表の「外注」は契約内容、「SaaS」は製品仕様と契約内容によって担当範囲が変わります。候補を比較するときは、各欄をそのまま前提にせず、契約書や公式情報で自社と外部事業者の担当を確認してください。 業務責任と技術作業を分ける具体例は、後述の「全面内製・全面外注にしない分担方法」で整理します。ここでは、方式名だけで担当者を決めず、回答内容の問題とシステム障害の連絡先を分けて記入してください。 いずれの方式でも、自社固有の正しい回答を決める仕事や、公開可否の最終判断が自動的に社外へ移るわけではありません。外部へ任せる範囲が広い場合ほど、誰が承認するか、どの方法で依頼するか、何を成果物とするかを明確にする必要があります。 ## 自社に合う方式を選ぶ判断表 方式を選ぶ際は、「どの方式が一般的に優れているか」ではなく、自社が必要な担当者と作業時間を確保できるかを確認します。次の項目ごとに、担当者名または担当部署を記入できるかを確かめてください。 - 業務知識を持ち、回答内容を承認する責任者がいるか - 設定や開発、変更後の検証を担当できるか - 公開後の回答を定期的に確認できるか - 独自システムとの連携が必要か - 正本を更新した際に回答への反映を確認できるか - 障害時の一次確認と連絡経路を維持できるか - 外注する場合に、依頼内容と成果物を確認できるか 確認結果は、次の判断表に当てはめます。 | 確認条件 | 候補方式 | 選ぶ際の確認点 | |---|---|---| | 業務責任者と技術担当者を確保でき、変更の検証や障害対応も自社で継続できる | 内製 | 担当者の異動時にも設定、権限、正本、連絡先を引き継げるか | | 業務要件と正しい回答は自社で決められるが、開発・保守担当が不足している | 外注 | 初期開発、保守、設定変更、障害調査の委託範囲が契約で明確か | | 標準機能の範囲で運用でき、自社で正本更新と回答確認を続けられる | SaaS | 必要な設定や運用方法が製品仕様と契約範囲に含まれるか | | 業務責任者はいるが、技術作業の一部だけ不足しているなど、条件が混在する | 併用 | 自社が持つ承認責任と、外部へ任せる設定・開発・保守の境界が明確か | 一つの行だけで決めず、自社の条件に最も近い候補を選んだうえで、満たせない確認点を洗い出してください。独自システムとの連携が必要でも自社に技術担当者がいない場合などは、併用を含めて検討します。 業務責任者と技術担当者を確保でき、設定変更や障害対応も自社で継続できるなら、内製が候補になります。ただし、担当者が一人に限られる場合は、休職や異動によって運用が止まる可能性があります。設定手順、権限、正本の保管場所、連絡先を共有し、別の担当者が引き継げる状態にしておく必要があります。 自社で業務要件や回答内容は決められるものの、開発や技術保守の担当者が不足している場合は、外注が候補になります。この場合も、「チャットボットを作る」とだけ依頼するのでは不十分です。初期開発、公開前の修正、納品後の保守、設定変更、障害調査のうち、どこまでを委託するか決めます。 標準機能の範囲で設定し、自社で正本と回答を管理できる場合は、SaaSが候補になります。選定時には、自社が必要とする設定や運用が提供範囲に含まれるかを公式情報で確認してください。個別の機能や対応条件は製品ごとに異なるため、名称や一般的な分類だけでは判断できません。 ## 全面内製・全面外注にしない分担方法 条件が混在する場合は、役割ごとに方式を組み合わせます。自社固有の正しい回答、問い合わせ範囲、公開可否は、自社の業務責任者が判断します。そのうえで、初期設定、開発、システムへの反映、技術保守など、自社で継続しにくい作業だけを外部へ任せます。 たとえば、商品仕様を改定した場合は、商品担当者が正本を更新し、カスタマーサポート責任者が回答を確認して公開を承認します。システムへの反映作業だけを外注先へ依頼すれば、回答責任を自社に残したまま技術作業を補えます。 SaaSを使う場合は、自社担当者が質問と回答を設定し、回答できない質問を有人窓口へ案内する分担が考えられます。回答内容の誤りは自社の業務責任者が確認し、システムの不具合はSaaS提供事業者へ連絡します。障害対応と回答品質の管理を同じ窓口へまとめないことが重要です。 外部へ仕事を任せる場合は、承認者、依頼方法、対応期限、成果物、契約終了時のデータ返却や引継ぎ条件を決めます。担当範囲を口頭の認識だけで済ませると、回答の誤りが見つかった際に、自社と外部事業者のどちらが修正するのか分からなくなります。分担表には、少なくとも「自社の承認者」「外部の作業担当」「修正依頼の窓口」を並べて記録してください。 運用体制から方式を絞った後は、必要な設定、管理方法、支援条件も比較します。製品やサービスの比較軸については、[チャットボットの選び方](/usage/chatbot-selection-guide)で確認できます。 ## 方式を決める前に問い合わせ範囲を切り分ける 内製、外注、SaaSを比較する前に、チャットボットが対応する問い合わせの範囲を決めます。範囲が曖昧なままでは、必要な設定、開発、連携、有人対応を見積もれません。自社と外部事業者の責任分担も決めにくくなります。 まず、現在受けている問い合わせを次の四つに切り分けます。 1. 定型情報で回答できるもの 2. 顧客情報や契約内容の確認が必要なもの 3. 担当者による判断や例外対応が必要なもの 4. 苦情、解約、緊急性のある連絡など、担当者へ渡すもの 店舗の営業時間やアクセス方法は、公式情報を正本として更新担当者を決めれば、自動回答の対象にしやすい問い合わせです。営業時間が変わった際に誰が正本を更新し、チャットボットへの反映を確認するかまで決めておきます。 一方、個別の予約変更や返金の判断には、顧客情報の確認や例外対応が伴います。このような問い合わせは、一律の回答を返すのではなく、有人対応へ渡す設計が必要です。チャットボットには、対応できないことを明示し、連絡先や受付方法を案内させます。 切り分ける際は、問い合わせの件名だけで判断しないでください。同じ「予約」に関する質問でも、予約方法の案内は定型回答にできる一方、個別予約の変更可否は担当者の確認が必要です。「何について聞かれたか」に加えて、「回答に顧客情報や個別判断が必要か」を確認します。 次に、それぞれの問い合わせについて、正本の所在、更新担当者、承認者、有人引継ぎ先を記録します。正本は、社内規程、商品資料、公式サイトの案内など、回答の根拠として扱う情報です。複数の資料で内容が異なる場合は、チャットボットの設定を始める前に、どれを優先するか決めます。 最後に、対象外の質問を受けた場合の動きを決めます。回答しないだけで終わらせず、問い合わせフォーム、電話、店舗スタッフなど、適切な有人窓口へ案内します。営業時間外にも問い合わせが届く場合は、その場で担当者につながらないことを前提に、受付時間や対応方法を明示する必要があります。 この整理を行うと、独自の判断や連携が多いため開発支援が必要なのか、定型的な範囲をSaaSで設定できるのかを検討しやすくなります。方式の比較より先に、対応範囲と有人対応の境界を確定させることが重要です。 ## 小さく始めて分担を見直す手順 最初からすべての問い合わせへ対応させると、正本の整備、回答確認、有人引継ぎの調整が同時に発生します。まずは正本が明確で、担当者が回答を確認できる範囲に限定して公開します。次の順序で進めると、問題の原因と担当範囲を切り分けやすくなります。 1. 対象とする問い合わせを限定します。候補は、営業時間、アクセス方法、手続きの案内など、回答の根拠と更新担当者が明確なものです。 2. 正本の保管場所と承認者を決めます。あわせて指定するのは、内容変更時の更新担当者と公開前の確認責任者です。 3. 回答できない場合の案内と有人引継ぎ先を設定します。個別判断が必要な質問は、自動回答の対象外として扱ってください。 4. 公開前に回答を確認します。確認対象には、代表的な質問のほか、表現を変えた質問、対象外の質問、個別判断が必要な質問も含まれます。 5. 限定した範囲で公開します。公開前に、回答の確認担当者と問題の記録先を決めておきましょう。 6. 回答できなかった質問や、誤解を招く可能性がある回答を分類してください。 7. 最後に、正本、設定、担当範囲のどこを修正するか判断します。 回答できない原因は一つではありません。正本に必要な情報がなければ、業務部門が情報を追加します。正本には記載されているのに回答へ反映されない場合は、設定や登録方法を確認します。必要な処理が製品やシステムの提供範囲を超える場合は、対象外として有人対応へ渡すか、開発や連携を検討します。 限定公開では、回答の正誤だけでなく、聞き返しや有人引継ぎが想定どおりに機能するかも確認します。たとえば、同じ内容を異なる表現で質問した場合、回答できないときに不確かな案内を続けず、決められた窓口へ誘導できるかを見ます。 確認結果を踏まえ、日常的な設定変更は自社で行い、技術的な改修だけを外注するなど、分担を調整します。問題が知識不足なのか、設定不足なのか、システム上の制約なのかを切り分けてから見直せば、不要な開発や委託範囲の拡大を避けられます。 ## よくある失敗と契約前の確認 よくある失敗は、構築や契約の完了を運用の完了と考えてしまうことです。外注先が初期開発を終えた後、回答内容を更新する担当者が決まっていなければ、古い案内が残ります。納品前に、正本の保管場所、更新担当者、承認者、修正依頼の窓口を決めてください。 正本の所在が決まっていない状態も問題です。公式サイト、社内資料、担当者の記憶で案内が異なると、何を正しい回答として登録するか判断できません。最初に正本を一つに定め、更新履歴と承認者を確認できる状態にします。 回答の承認者が不明な場合は、修正案を作っても公開判断が止まります。商品仕様は商品担当者、手続きは管理部門など、内容ごとに確認者が異なる場合は、問い合わせ分類と承認先を対応させます。 有人引継ぎ先を設定していても、営業時間外に機能しなければ利用者は次の行動を取れません。即時対応できない時間帯は、受付時間、連絡方法、回答時期の案内方法を決めておきます。また、障害の窓口と回答品質の窓口も分けます。画面が動作しない問題と、案内内容が誤っている問題では、確認すべき担当者が異なります。 外注やSaaS利用の契約前には、少なくとも次の点を確認します。 - 自社と外部事業者の作業範囲 - 各作業の責任者と承認者 - 連絡方法と修正依頼の流れ - 成果物と検収条件 - 公開後の保守対象 - データの取扱いと権限管理 - 契約終了時のデータ返却および移行方法 対応時間、修正回数、保証範囲などは、事業者や契約によって異なります。一般論で判断せず、契約書、見積書、提供事業者の公式資料で確認してください。特に「運用支援」や「保守」という表現だけでは、正本更新や回答確認が含まれるか分かりません。具体的な作業名に分解して確認します。 外注する担当範囲、成果物、保守条件を発注要件へ落とし込む場合は、[RFPの作り方](/usage/chatbot-rfp-writing-guide)を参照してください。開発全体ではなく、正本更新や回答確認、改善作業など運用の一部を委託したい場合は、[運用外注の整理](/usage/chatbot-operation-outsourcing)で委託範囲を確認できます。 ## よくある質問 **専任のエンジニアがいなくても内製できますか。** SaaSを利用し、提供範囲内で設定する方法は候補になります。ただし、業務責任者、回答内容を確認する担当者、有人引継ぎ先、障害時の連絡担当は必要です。設定できることと、回答責任を持って運用できることは分けて判断してください。 **外注すれば公開後の運用も任せられますか。** 契約範囲によります。初期開発だけを委託する契約では、納品後の正本更新や回答確認が含まれない場合があります。また、作業を委託できても、自社固有の正しい回答や公開可否の承認まで委託先が判断するとは限りません。作業名、責任者、依頼方法、対応条件を契約前に確認してください。 **SaaSと外注は併用できますか。** 併用できます。たとえば、SaaSの選定、初期設定、必要な連携の支援を外注し、日常の正本更新と公開承認を自社が担当する分担が考えられます。外注先とSaaS提供事業者のどちらへ何を問い合わせるかも決めておく必要があります。 **途中で方式を変えられますか。** 変更を想定するなら、正本、設定内容、対応履歴、連携仕様、権限を整理しておきます。外注契約やSaaS利用を終了する際のデータ取扱いと引継ぎ条件も事前に確認してください。特定の担当者や委託先だけが設定内容を把握している状態では、移行時の確認作業が増えます。 チャットボットの内製・外注・SaaSは、構築方法だけで選ぶものではありません。問い合わせ範囲、正本更新、回答確認、有人引継ぎ、障害対応、改善判断の担当者を具体的に置ける方式を選びます。業務知識と回答責任を自社が持ち、不足する設定、開発、保守だけを外部へ任せる分担も有効です。 Socratesでは、回答させる問い合わせの範囲と有人対応へ渡す境界を、自社の業務に合わせて整理できます。内製、外注、SaaSを決める前に、自社が持つ担当範囲と外部へ任せる作業を確認したい場合は、ご相談ください。