営業AIエージェントの発注・外注ガイド|依頼方法と委託先の選び方

営業AIエージェントの外注は、要件・予算・社内体制を整え、PoCで効果を確かめながら段階的に進めます。

AI開発は不確実性を伴うため、その点を踏まえずに発注すると、費用の膨張やプロジェクトの頓挫につながります。経済産業省の2021年モデル契約書も、この点について考え方を示しています。

▼全体ガイドの記事
・営業AIエージェント開発・構築の完全ガイド

内製と外注の比較:それぞれの特性と選び方

営業AIエージェントを内製するか外注するかは、組織の状況によって変わります。担当者は、それぞれの特性を理解したうえで、自社に合う方法を選びます。

内製のメリット・デメリット

内製は、自社の営業プロセスや業務ノウハウをシステムに深く反映でき、外部に頼らない運用体制を作れる方法です。内製では、柔軟性と専門人材の確保を合わせて考えておく必要があります。

  • 自社への適合:社内にナレッジを蓄積でき、自社のペースで改善を重ねられるため、競合との差別化につながります。
  • 必要な専門性:担当するエンジニアには、LLM(大規模言語モデル)やRAG設計、SFA/CRMとのAPI連携の実装知識が求められます。
  • 立ち上げの負担:エンジニアの採用と育成に時間と費用がかかり、その間の機会損失も生じます。

AI開発では、精度改善や運用チューニングのノウハウが蓄積されるまでに、相当の試行錯誤が必要です。この期間も含めて、長期の運用体制と立ち上げ期間の負担を並べて比べます。

外注のメリット・デメリット

外注は、AIエージェント開発を専門とするベンダーに構築を依頼する方法です。専門会社の実績を活用できる一方で、自社側の準備も欠かせません。

  • 導入速度と品質:既存の開発実績や技術ノウハウを使えるぶん、立ち上げが速く、初期品質も安定しやすくなります。
  • 初期投資:社内での採用や教育にかかる費用を省き、高度なシステムを早期に稼働させられます。
  • 依存と追加費用:技術が社内に残りにくいため、ベンダーを替える際のリスクや、仕様変更時の追加コストに注意が必要です。

要件定義が不十分なままだと、想定と異なるシステムが納品される場合もあります。そのため、発注側にも一定の技術理解と、要件を明確にする力が求められます。

内製と外注の判断基準:ハイブリッド型という現実的な選択肢

内製と外注は、社内の専門性や稼働期限、予算、将来の体制を照らし合わせて判断します。

  • 社内の専門性:AI開発に精通したエンジニアの在籍の有無
  • 稼働期限と予算:12ヶ月以内の稼働が必要か、概算予算がどの程度かを洗い出します。
  • 将来の体制:長期的に内製化を目指す意向の有無

小〜中規模では、外注のほうが効率的な場合があります。そこで、まず外注で立ち上げ、運用を通じてノウハウを蓄積しながら、段階的に内製化する方法が現実的です。

最初から完全内製にこだわると、時間とコストが膨らみがちです。だからこそ、自社の状況に合わせて柔軟に選ぶことが、早期の実現につながります。

ポイント

内製はノウハウを社内に残せる一方、採用と育成に時間がかかります。小〜中規模では、まず外注で立ち上げてから段階的に内製化する道も現実的です。

発注前の準備:要件・予算・社内体制

要件・予算・社内体制・現場の参加を整理した発注前準備のチェックリスト図解
曖昧なまま相談せず、必要な準備を先にそろえる。

発注前の準備では、要件・予算・社内体制の3つを整えます。曖昧なまま相談すると的確な提案を得にくいため、自社の状況を先に整理しておきます。

要件の整理:自動化したい業務の具体化

最初に、どの営業業務を自動化・効率化するかを決めます。抽象的な目標のままでは開発会社も提案を組めないため、業務のボトルネックを数値でつかんでおきます。

  • 業務と利用者:誰が何をどの頻度で行うか、利用ユーザー数と利用頻度を洗い出します。
  • 連携と出力:SalesforceやHubSpotなどのSFA/CRMについて、API対応状況と必要な出力形式を押さえます。
  • データの機密性:扱うデータの種類と、顧客情報の取り扱いの決まりを整理します。

たとえば、商談後のSFA入力に営業担当1人あたり1日30分かかっている、といった現状を把握しておきます。また、展示会後のフォローメールが2〜3日後になり、機会損失が生じている場合も対象になります。

出力形式には、SFAへの自動入力、メール文面の生成、レポート作成などがあります。どの形式を求めるかは、業務内容と合わせて決めます。

予算の設定:規模別の費用感と総コスト計画

費用はシステムの規模と複雑さによって変わります。初期開発費だけでなく、運用と改善を含めた総コストで捉えます。

  • PoC:概念実証レベルのシステムは、150万〜250万円程度が目安です。
  • 中規模開発:SFAと本格連携するシステムは、900万〜1,600万円程度とみておきます。
  • 運用保守:毎月10万〜30万円程度の費用を見込んで、予算を組みます。

さらに、LLM APIの従量課金、プロンプトチューニング、データ更新に伴う継続的な改善費も、予算に計上します。IT導入補助金などの公的支援を使えれば、初期費用の一部を抑えられる場合があります。

社内体制の整備:現場を巻き込む推進体制

外注する場合でも、社内の推進体制は欠かせません。発注側は、窓口と意思決定の仕組み、現場の協力の形をあらかじめ決めておきます。

  • 窓口の一本化:ベンダーと調整するプロジェクトオーナーを一人決め、意思決定の権限を持たせます。
  • 現場の参加:営業担当者を早い段階から巻き込み、要件定義やPoCでフィードバックを集めます。
  • 業務知識の共有:製品知識、商談の勝敗パターン、顧客の業界特性といったドメイン知識を、ベンダーに渡します。

責任者が曖昧だと、仕様確認や承認に時間がかかり、プロジェクトが停滞します。また、現場の声を仕様に反映させないまま進めると、完成しても使われない形骸化を招きます。

AIの品質は、営業担当者の業務知識に大きく左右されます。だからこそ、現場の協力体制を整えておくことが、成否を分けます。

ポイント

発注前には、要件・予算・社内体制を具体的に整えます。曖昧なまま相談すると的確な提案を得にくいため、業務の数値や総コスト、現場の協力体制を先に押さえておきます。

委託先の選び方:評価の観点と確認事項

要件定義力・導入実績・API連携・運用支援を2×2で比較する委託先評価の図解
業務への適合と導入後の支援をまとめて見る。

委託先は、技術力だけで選ばず、業務理解、導入実績、継続支援などの観点で比べます。そのうえで、自社に合った提案内容と運用体制を確かめます。

委託先を評価する5つの観点

委託先は、要件定義力や導入実績から運用支援まで、5つの観点で評価します。

  • 要件定義力と導入実績:営業フローを理解し、自社の規模と予算に合う段階的な導入を提案できるかを見ます。
  • 再利用資産と連携実績:開発テンプレートやコンポーネントの有無と、Salesforce・HubSpot・kintoneとの接続実績です。
  • 運用支援:プロンプト調整、モデル更新、現場への定着支援まで、長期に伴走できる体制かどうかを確かめます。

要件定義では、コンサルティングの質が問われます。インサイドセールス、フィールドセールス、カスタマーサクセスの各部門の業務を聞き取り、AIと人の承認範囲を設計できる会社を選びます。

業務に合わないAIは、使われなくなります。また、大企業向けのベンダーが中小企業に過剰な仕様を提案する場合もあるため、スモールスタートから広げられるかを確かめます。

フルスクラッチは、費用対効果が低くなりがちです。一方で、再利用できる資産があれば、期間とコストの削減につながります。AIは既存のSFA・CRMとの連携で価値を発揮するため、接続先を具体的に詰めておきます。

初期ヒアリングの確認事項

提案依頼の前後には、実績がどれだけ具体的か、開発中の不確実性にどう対応するかをたずねます。

  • 類似案件:営業AIエージェントの事例で、業務課題と解決へのアプローチを具体的に説明できるかを見ます。
  • PoC設計:成果指標と評価基準の合意方法、本番移行の進め方を尋ねます。
  • 変更管理:開発中に仕様が変わった場合の対応と、契約の進め方の柔軟性を見極めます。

PoCの設計を明確に説明できる会社は、実務経験を判断する材料になります。AI開発には探索的な要素があるため、仕様変更が起こり得る前提で、あらかじめ合意しておきます。

ポイント

委託先は、業務理解や導入実績、継続支援の観点で比べます。迷うときは、自社規模に合う段階的な提案ができるかを基準にします。

契約形態と発注の流れ:請負・準委任・多段階型の違い

企画・要件定義から本稼働・継続調整までの発注の流れを示すタイムライン図解
PoCで不確実性を確かめ、工程に合わせて契約を切り替える。

AI開発は技術的な不確実性を伴うため、通常のシステム開発とは異なる契約の考え方が求められます。経済産業省の2021年モデル契約書も、この点について考え方を示しています。

請負契約と準委任契約:民法上の差異と使い分け

代表的な契約は、請負契約と準委任契約の2つです。目的と義務の違いを理解したうえで、要件の確定度やAIの検証段階に合わせて選びます。

  • 請負契約:民法第632条に基づき、成果物を仕様どおりバグなく完成させる仕事の完成義務を負います。
  • 準委任契約:民法第656条・第643条に基づき特定業務を委託する契約で、成果の完成や特定精度の保証は義務になりません。
  • 善管注意義務:準委任の場合は、専門家として注意深く業務を進める義務(民法第644条)があります。

請負では、納品物に不具合があった場合、契約不適合責任として無償で修正する義務が生じます(民法上の担保責任)。仕様が確定し、変更が少ないウォーターフォール型に向いています。

AI開発のように不確実性が高い場合は、精度が出ないことを理由に完成義務違反を争うリスクがあります。

準委任は、仕様変更の多いアジャイル開発や、適合性・精度を検証するPoCに適しています。完成義務や精度保証ではなく、善管注意義務のみを負う形なので、柔軟に協業を進められます。

成果完成型準委任契約と経産省2021年モデル契約書

成果完成型準委任契約は、準委任として精度保証や完成責任を負わないようにしつつ、一定の成果物の納入を支払いの条件にする契約です。

  • 発注側の確認:定義された成果物を確かめてから支払える形にします。
  • ベンダーの負担:過大なリスクを負わず、不確実性のある開発に集中できる形です。
  • モデル契約書:経済産業省の2021年版の第6条第2項は、技術検証やPoCの準委任型契約を標準案としています。

同条項では、仕事の完成義務と、成果物の特定の性能や結果に対する保証責任を、ベンダーが負わない旨を明記しています。

発注側が不当な完成義務を課さず、実データに合わせて柔軟に開発するための指針です。開発は、アジャイルな協力関係のもとで進めます。

初期段階から請負の完成義務を求めると、見積もりに高額な安全マージンが加わる場合があります。さらに、契約締結を断られる可能性もあります。

多段階契約(探索的段階型)の実務フロー

初期から本番運用まで一括で契約するとリスクが高いため、段階に応じて契約を切り替えます。経産省ガイドラインも、多段階契約(探索的段階型契約)を推奨しています。

企画から継続運用まで、工程ごとに目的と契約形態を対応させます。

  1. ステップ1:企画・要件定義:時間や稼働に基づく準委任契約で、業務整理、適合分析、API連携仕様を調べます。
  2. ステップ2:PoC・プロトタイプ検証:準委任契約か成果完成型準委任契約を使い、実際の営業データで精度を検証して、リスクを洗い出します。
  3. ステップ3・ステップ4:本番開発やAPI統合は請負かアジャイル型準委任で、本稼働と継続調整は月額型の保守運用契約で進めます。

企画段階は作るものが未確定なため、柔軟に動ける準委任が適しています。PoCは挙動の確認が主な目的です。そのため、完成保証ではなく、精度や処理速度などの成功基準を数字で合意します。

本番開発では、要件が固まったUI実装やSFAのカスタム項目への書き込みを請負に移せます。流動的な部分は、アジャイル型準委任で並行して進めます。

月額保守では、再学習、プロンプト調整、SFAのアップデートに対応します。段階を分けることで、認識違いや精度低下へのペナルティなど、法的トラブルを抑えられます。

ポイント

精度が見えない段階は準委任、要件が固まった部分は請負と、工程ごとに契約の形を選びます。迷ったときは、まず準委任で検証を進められるかを基準にします。

失敗しないための実践ポイント:外注発注の落とし穴と対策

外注の失敗には、いくつか共通するパターンがあります。要件の曖昧さ、検証の省略、業務知識の不足は、発注前の段階で防ぎます。

よくある失敗パターンと原因

「AIで営業を効率化したい」というだけでは、一般的な提案にとどまり、自社の業務に合わないシステムになる場合があります。課題、検証の方法、参照する情報を、具体的に示しておきます。

  • 曖昧な要件:業務フローのAs-Is(現状)とTo-Be(あるべき姿)を文書に残し、仕様変更と追加費用の増大を防ぎます。
  • PoCの省略:特定の営業チームや商談チャネルで小さく検証し、成果を見てから本格導入に進みます。
  • ドメイン知識の不足:製品カタログやFAQ、業界用語集、過去提案書をナレッジベースに整え、RAGで参照させます。

PoCなしで全社向けのシステムを発注すると、稼働後に精度不足や連携不具合が見つかった際の修正コストが膨らみます。だからこそ、実際に動かすまで分からない部分を、小規模で確かめておきます。

汎用LLMは、自社の製品名や業界用語、取引の背景、独自の営業ルールを知りません。そこで、RAG(検索拡張生成)によるコンテキスト・エンジニアリングが、実用性を左右します。

発注を成功に導く実践ポイント

発注を成功に導く実践ポイントは3つです。PoCの評価、人による承認、商談データの同意管理を、初期から設計に組み込みます。

  • 成功基準の合意:文字起こしの精度○○%以上、処理時間○秒以内、担当者の確認なしで送信できる割合○○%以上などを事前に決めます。
  • Human-in-the-Loop:営業メールや提案資料など、顧客に届く出力は、人が確認してから送る設計にします。
  • 録音と同意の管理:商談の録音・録画を公式な運用規定に定め、顧客から同意を得る手順を整えます。

PoCの合否基準を開始前に合意しておけば、終了後の認識のずれを防げます。また、人の確認を組み込むことは、現場の受け入れ率向上にもつながります。

「Suggest(提案)→ Draft(起案)→ Approve(承認)→ Commit(確定・実行)」の順で、段階を管理します。この進め方によって、安全な自動化と現場への定着を両立させられます。

品質の前提は、商談という一次情報にあります。Web会議の開始時の自動通知、対面商談の開始時の口頭確認、メール招待への録音ポリシーの記載を、標準の手順にします。

ポイント

PoCで確かめた範囲と、本番で求める範囲がずれていないかを、発注前に照らし合わせます。成功基準と人の承認の設計を初期から合意しておくと、稼働後の認識のずれを防げます。

まとめ:営業AIエージェントの発注・外注の要点

営業AIエージェントを内製するか外注するかは、AI開発スキル、導入速度、予算を見て判断します。外注で立ち上げ、ノウハウを蓄積しながら段階的に内製化する方法もあります。

発注前には、業務課題の数値化、初期費とランニング費を含む予算、現場を巻き込む体制の3つを整えておきます。委託先は、技術力に加えて、要件定義力、自社規模への適合、伴走支援の3点で選びます。

契約は、完成義務を負う請負と、善管注意義務を負う準委任の違いを理解して選びます。経済産業省の2021年モデル契約書を踏まえ、段階に合わせて組み合わせます。

PoCは準委任か成果完成型準委任とし、本番開発では請負を部分的に取り入れる多段階契約が選択肢になります。加えて、Human-in-the-Loop、ナレッジ設計、録音の同意管理も組み込みます。

まず、自社の課題と優先順位を整理します。曖昧なまま発注せず、小さなPoCから進めることが、外注を成功させる第一歩になります。

▼全体ガイドの記事
・営業AIエージェント開発・構築の完全ガイド

・営業のAIエージェント活用事例|商談・インサイドセールスを変える実例

・営業AIエージェントの開発・構築の進め方|導入プロセスと成功のポイント

・営業AIエージェント開発に強い開発会社・ベンダー6選|選び方も解説

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。