%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
BtoB企業のAI活用では、文章や回答の作成だけでなく、業務に必要な情報を集め、人が判断できる形に整えることが大切です。着手する業務と参照データを先に決めることが、導入設計の出発点になります。
BtoB企業のAI活用では、文章や回答の作成だけでなく、業務に必要な情報を集め、人が判断できる形に整えることが大切です。着手する業務と参照データを先に決めることが、導入設計の出発点になります。
「商談の記録を残したいが、担当者によって書き方が違う」「問い合わせへの回答を探すたびに、複数の資料を開いている」「AIを試したものの、どの業務につなげればよいかわからない」——こうした悩みは、ツールを選ぶ前に現在の作業を整理する手がかりになります。
AIの業務活用とは、社内の情報や業務上の指示をもとに、要約・文章案・回答案などを作り、人が確認して次の仕事につなげることです。AIそのものの概要は「AIとは？ビジネス活用の全体像をわかりやすく解説」もご覧ください。
本記事では、営業・マーケティング・カスタマーサクセス・開発・管理部門のAI活用事例を紹介します。AI活用完全ガイドでは、AI活用の全体像を確認できます。
この記事でわかること
AIを自社のどの業務に使うか検討している方が、事例の読み方と着手する業務の選び方を確認できます。
- 営業・マーケティングでの使い方 — 商談要約や提案書、広告・記事の下書きを、どの業務につなげるか整理します。
- カスタマーサクセスでの使い方 — 回答案の作成に必要なナレッジと、人へ引き継ぐ場面を考えます。
- 開発・管理部門での使い方 — コード、文書、契約書、経費情報を扱う際の確認工程を示します。
- 着手する業務とデータの選び方 — 反復作業から始め、参照資料と記録先を整える順序を解説します。
営業部門の活用事例
営業では、次の業務がAIの対象になります。いずれも文章を作る作業ですが、必要な情報と確認する人は異なります。
- 商談後の記録
- 提案書の作成
- メールの下書き
まず現在の手作業がどこで滞っているかを見て、担当者の判断を残せる工程から選ぶと進めやすくなります。
NTTコミュニケーションズ：商談要約
NTTコミュニケーションズでは、商談録音を要約に使っています。議事録作成に時間がかかる場合は、録音から決定事項、顧客の課題、次の対応を抜き出す作業が候補になります。ただし、要約文だけでは発言の背景や合意の有無を判断しにくいため、営業担当者が録音やメモと照らして確認してから記録する流れが必要です。
現在、担当者ごとのメモがスプレッドシートや個人のファイルに分かれているなら、要約の形式と保存先を先に決めます。商談後に同じ項目が記録されれば、担当者が交代しても経緯を追いやすくなります。プロンプトエンジニアリング実践ガイドも、出力項目を考える際の参考になります。
リクルート：提案書のドラフト
リクルートの例では、過去の案件情報を参照し、顧客に合わせた提案書の初稿を作ります。RAGとは、回答や文章を作る際に、指定した資料を検索して参照する方法です。過去の提案書を使う場合は、再利用できる説明と、その顧客に固有の条件を分けて扱います。
提案書の構成が毎回似ているなら、章立てや確認項目の下書きから試せます。一方、顧客の課題や提案の妥当性まで過去資料から決めてしまうと、今回の商談で聞いた内容とずれるおそれがあります。担当者が課題、提案範囲、記載した根拠を確認し、顧客に渡す文面を完成させます。
Salesforce：営業メールのパーソナライズ
SalesforceのEinstein GPTは、CRM上の顧客情報をもとに営業メールを作る例です。この例から読み取れるのは、文章生成の前に、相手との接点や過去のやり取りを参照できる状態が重要だという点です。顧客情報が古い、または担当者ごとに記録場所が違う場合、個別化したつもりの文面が現在の状況に合わない可能性があります。
まずは定型的なフォローの下書きに使うか、個別の提案メールに使うかを分けます。前者は記載項目をそろえ、後者は商談の文脈や送信の可否を担当者が判断します。メールを送る前に、宛先、過去の接点、依頼内容を確認する工程を置きます。
マーケティング部門の活用事例
マーケティングでは、文章を多く作ること自体が目的にはなりません。次の点を先に決める必要があります。
- 誰に何を伝えるか
- どの反応を見て改善するか
AIは案を広げる工程に置き、公開する内容と評価の基準は担当者が決めます。
サイバーエージェント：広告クリエイティブの案出し
サイバーエージェントの「極予測AI」は、広告コピーの案を作り比較する例です。訴求の方向を複数考えたい場合、AIは見出しや本文の候補を出す作業に使えます。ただし、生成された案の数だけで良し悪しは判断できません。
- 対象読者と伝える価値を先に決める ── その条件から外れる案を除きます
- 掲載する案を選ぶ ── 実際の反応と結びつけて記録します
次回の制作時に参照できるよう、採用した表現だけでなく、採用しなかった理由も残すと改善につながります。
HubSpot：Breezeによるコンテンツの下書き
HubSpotのBreezeは、ブログ記事やメールなどのコンテンツ制作に使う例です。HubSpotの公式資料では、Breezeを使ってブログ記事、ナレッジベース記事、CTAなどの文章を生成・修正できると説明しています（出典：Generate and refine content with AI）。
既存の原稿を整えるなら、最初に対象読者、伝える結論、根拠となる資料を決めます。下書きがその範囲を越えて事実を補っていないか、公開前に原資料と照らします。コンタクトの検討段階に応じて記事を案内する場合も、記事作成から配信、商談での反応の記録までをつなげて考えることが大切です。
Jasper AI：表現の統一
Jasper AIは、ブランドガイドラインや過去のコンテンツを参照する例です。複数の担当者が原稿を作る場合、表現の揺れを見直す用途が考えられます。一方、文体がそろっていても、製品の説明や対象読者が間違っていれば公開できません。
既存原稿で繰り返し直している表現があるなら、まず修正理由をガイドラインにまとめます。AIにはその基準に沿った下書きや修正案を求め、担当者が事実関係と読者への適合を確認します。運用できるルールとして共有しておけば、担当者個人の記憶に頼りすぎずに制作を引き継げます。
カスタマーサクセス部門の活用事例
問い合わせ対応では、回答文を速く作ることより、参照する情報が正しいかが先に問われます。よくある質問には資料を使った回答案を用意し、判断が分かれる内容は人へ引き継ぐ設計が必要です。対応後に未回答の質問をナレッジへ戻すところまで含めて考えます。
三井住友銀行：社内問い合わせへの回答案
三井住友銀行の例では、行内問い合わせに対し、社内規程を参照して回答を生成します。人事・総務・IT関連の問い合わせでは、担当者が資料を探して回答を組み立てる作業が対象になります。資料の版や適用対象が異なる場合には回答も変わるため、回答案と参照した規程を一緒に確認できる形が適しています。
問い合わせを整理する際は、規程の記載だけで答えられる質問と、個別事情の判断が要る質問を分けます。前者から回答案を試し、後者は担当部署へ引き継ぎます。回答できなかった質問は、資料に不足があるのか、検索で見つからないのかを記録して見直します。
Zendesk：サポートチケットへの対応
ZendeskのAIエージェントは、チケットへの回答に使う例です。過去の回答を参照する方法は、同じ質問が繰り返される場面で検討しやすいでしょう。ただし、過去に使われた回答が現在も適切とは限らず、契約条件や障害の状況によって結論が変わる質問もあります。
まず問い合わせを内容ごとに整理し、既存の手順で回答できるものを選びます。回答案の根拠が見つからないものや、顧客ごとの判断が要るものは担当者へ渡します。チケットには質問、参照した資料、対応結果を残し、次の回答を見直す材料にします。
SmartHR：ヘルプページの下書き
SmartHRの例では、開発仕様書からヘルプページの下書きを作ります。仕様書は開発者向けの説明であり、そのままでは利用者が操作を進めにくい場合があります。AIには手順を読み手の言葉に直す役割を任せ、画面上の名称や操作の順序は担当者が照合します。
下書きができたら、利用者の動きを次の順で追います。
- 最初に何を確認するか
- どこで操作するか
- 完了をどう判断するか
説明と実際の画面が合わなければ、文面だけを直す前に仕様書と画面のどちらが正しいかを確認します。公開後の問い合わせも、ヘルプ記事を直す手がかりになります。
HubSpotで顧客対応のナレッジを使う場合、公式資料では、Breezeカスタマーエージェントの情報源としてWebサイトのURLやファイルを追加できると説明しています（出典：Manage the customer agent's content sources）。回答に使う資料を選ぶ際は、顧客に示してよい内容かを確認してから登録します。
以下の画面は、顧客対応エージェントの「トレーニング > ガイドライン」にトーンと応答スタイルの入力欄が表示された例です。
開発部門の活用事例
開発では、コードや文書の下書きを生成できても、動作や仕様との一致は別に確認する必要があります。これらの事例は、次の異なる工程を示しています。
- 補完
- 文書更新
- テスト
作業が滞っている工程を選び、生成物を既存のレビューに通せる形で試します。
Google：コード補完
GoogleのGemini Code Assistは、コード補完の例です。実装中に定型的なコードを提案してもらう使い方は、開発者がその場で内容を読める工程に置けます。一方、提案されたコードが周辺の設計や例外処理に合うかは、生成結果だけでは判断できません。
試す範囲を決める際は、入出力が明確な処理から選びます。採用したコードは開発者が読み、既存のテストとコードレビューに通します。期待した動きにならない場合は、指示文だけでなく、前提となる仕様やテストの不足へ戻って確認します。
Stripe：APIドキュメントの更新案
Stripeの例では、AIでAPIドキュメントを更新します。開発上の変更が文書に反映されないことが課題なら、変更内容から更新箇所の候補を出す使い方が考えられます。ただし、変更されたコードを説明文へ言い換えるだけでは、利用者への影響や移行時の注意は伝わらない場合があります。
まず変更内容と公開文書の対応箇所を特定し、更新案を作ります。次に実装担当者が仕様と照らし、利用者が操作できる説明になっているかを確認します。文書の公開後に質問が残ったら、その質問を次の更新時の確認項目に加えます。
メルカリ：テストコードの下書き
メルカリの例では、既存コードをもとにテストコードの生成を試します。AIがテストの形を作っても、何を守るべきかという期待値が曖昧なら、意味のある確認にはなりません。先に仕様上の正常な動きと、失敗時の動きを言葉で整理する必要があります。
既存のテストで抜けている条件が見つかったら、その条件を入力としてテスト案を作ります。担当者はテストが通ることに加え、意図した失敗を検出できるかを見ます。文章の作成工程に応用する際も、コンテンツマーケティングで扱う原稿の目的と確認基準を先に置く考え方は共通します。
管理部門の活用事例
管理部門には、形式は異なっても人の確認が欠かせない情報があります。たとえば次のものです。
- 契約書
- 経費情報
- 社内文書
AIの出力を判断そのものとして扱わず、確認すべき箇所を示す案として使います。
弁護士ドットコム：契約書レビューの補助
弁護士ドットコムの「クラウドサイン AI」は、契約書の条項を確認し修正案を作る例です。契約書を読む人が確認箇所を探す作業には役立つ一方、条項を変更してよいかは取引内容や相手との合意によって変わります。生成された指摘を、そのまま法的な結論として採用する使い方は避けます。
試す際は、確認したい条項と自社の確認基準を明らかにします。出力された箇所を原文と照合し、修正する場合は担当者が理由を記録します。基準にない指摘が続くなら、使う資料や指示を見直します。
freee：経費情報の入力補助
freeeの例には、領収書の読み取り、勘定科目の分類、仕訳候補があります。スプレッドシートへの転記が続いている場合、画像から読み取った内容を入力候補にする工程から見直せます。ただし、読み取れた文字と、経費としてどう扱うかの判断は同じではありません。
入力作業を整理する際は、領収書の内容、申請者の説明、承認者が見る項目を分けます。候補が出たら原資料と照合し、判断が分かれるものを担当者へ回します。後で修正した理由を残せば、同じ誤りを繰り返さないための運用にもつながります。
富士通：社内ナレッジの検索
富士通の例では、技術文書を横断して探します。複数の保管場所を行き来している場合、自然な言葉で資料を探せるようにすることが候補になります。しかし、古い文書と現行の文書が混在していれば、見つかった文章をそのまま回答に使うことはできません。
最初に文書の管理者、更新状況、参照できる範囲を整理します。検索結果には元資料をたどれる形を求め、利用者が版と適用対象を確認します。答えが見つからなかった質問は検索語だけを増やすのではなく、元資料が存在するかを確認します。
着手する業務とデータの選び方
部門ごとの事例を自社に当てはめるときは、成果の数字ではなく、元の作業と確認工程を比べます。AIを使う場所が決まっても、参照資料が散在していれば下書きの確認に時間がかかります。業務、データ、人の判断をひとつの流れとして整理します。
選定ポイントを実務に落とす
選定ポイントは次のとおりです。これは導入を考える順序として読み、個々の製品の効果を示す表としては扱いません。
| ポイント | 内容 |
|---|---|
| 1. ユースケースの選定 | 「定型的×高頻度×人手で時間がかかる」業務から着手する |
| 2. データ基盤の整備 | RAGで活用する社内データの品質と構造化が成果を左右する |
| 3. ガバナンスの並行構築 | セキュリティポリシー・利用ガイドラインを導入初期から策定する |
まず日常業務から、同じ形式の文章や回答を繰り返し作っている作業を探します。参照する資料と、出力を確認する担当者を指定できるなら試行の候補になります。資料の所在が分からない作業は、AIへの指示を工夫する前に資料を集め直すほうが先です。
下書きと最終判断を分ける
AIには、要約、分類、文章案、検索結果の整理を任せる考え方があります。顧客への提案、公開、送信、契約上の判断は、担当者が元情報と照らして決めます。この分担を決めずに試すと、出力がもっともらしい場合ほど確認が省かれやすくなります。
例えば商談要約なら、AIが決定事項の候補を抜き出し、営業担当者が実際の合意を確認してCRMへ記録します。問い合わせ対応なら、資料から回答案を作り、資料にない質問は人へ渡します。次に何を見れば判断できるかが示せない出力は、業務で使う前に参照資料を見直します。
試行結果を比べるための記録をそろえる
AIの業務利用で何を確認するかは、懸念の種類から決められます。IPA『DX動向2025』の企業調査では、AIを「導入している」「現在、試験利用をしている」「利用に向けて検討を進めている」と答えた企業を対象に、業務活用上の課題を尋ねています。
そのうち日本企業の40.5%が「誤った回答を信じて業務に利用してしまう」を課題として選びました。これは回答企業の懸念の割合であり、AIの実際の誤回答率や個々の製品の性能値ではありません（出典：IPA『DX動向2025』データ集・AIを業務で活用する上での課題（国別））。
この懸念を自社の試行で確かめるなら、同じ種類の作業について、次の項目を一件ずつ対応させて残します。
- 元の依頼
- 参照した資料の版
- AIの出力
- 担当者が採用・修正した箇所
- 修正理由
例えば問い合わせ回答案では、次の回答を分けます。
- 資料に該当箇所がない回答 ── ナレッジの不足や検索方法が見直しの候補です
- 資料はあるが適用条件を取り違えた回答 ── 条件を読む工程の見直しが候補です
修正件数を集計する場合も、対象にした問い合わせの範囲と件数を併記し、別の業務や時期の比率と無条件に比べないようにします。
小さく試し、戻り先を残す
着手する業務が決まったら、同じ種類の仕事で試し、入力資料、出力、担当者の修正を記録します。修正が多い場合は、指示の曖昧さ、資料の不足、対象業務の選び方のどこに原因があるかを分けます。修正理由が説明できるようになってから、別の作業への展開を考えます。
CRMを起点に業務の流れをつなぐ
顧客に関するAI活用は、個々の文書を作って終わるものではありません。次の流れのどこで情報を使い、どこへ記録を戻すかを考えます。
- コンタクトとの接点
- 取引
- 顧客対応
- 請求
CRMを単なる保存先ではなく、部門間で同じ経緯を確認するための基盤として使う設計が重要です。
コンタクトと取引に必要な情報を残す
商談要約や営業メールの下書きでは、顧客の課題や過去の接点が材料になります。担当者ごとのスプレッドシートやメールだけに情報が残っているなら、最初に記録する項目と場所をそろえます。必要な項目は、次の担当者が商談の状況を理解し、対応を決めるために使うものから選びます。
コンタクトの情報がそろったら、取引の進み具合や提案内容と結びつけます。AIが作った文章を残すだけでなく、担当者が何を採用し、何を修正したかを記録すると、次の商談で参照する情報が明確になります。AIとCRMの連携活用ガイドも設計を考える際の参考になります。
顧客対応から資料の改善へ戻す
顧客になった後の問い合わせでは、取引時に決めた内容とサポート用の資料がつながっているかを見ます。回答案が資料と食い違う場合は、AIの文面だけを直しても原因が残ります。顧客との合意、案内資料、実際の対応結果を照らし、どの情報を更新するか決めます。
請求に関する質問が来るなら、契約や取引の記録と請求情報を人が確認できる流れを設けます。回答に必要な情報がそろっていない場合は自動回答の対象から外し、担当者へ引き継ぎます。対応を終えたら、次に同じ質問が来たときに使う資料を更新します。
見直す基準を先に決める
導入後は、AIが作った量より、担当者が業務を進められたかを見ます。判断材料は次のとおりです。
- 商談要約 ── 次の行動が読み取れるか
- 記事の下書き ── 根拠を確認できるか
- 問い合わせ回答 ── 参照資料を示せるか
使えなかった出力も残せば、対象業務を変えるか、資料を整えるかを選べます。
よくある質問
どの部門からAIを試すとよいですか？
部門名だけで決めず、繰り返し発生し、参照資料と確認担当者を指定できる業務を探します。商談メモや問い合わせ回答のように、現在の手作業と完成形を比べられるものが候補です。資料が見つからない業務では、先に保管場所と更新担当を決めます。
RAGを使えば社内資料から適切に回答できますか？
RAGは指定した資料を参照する方法ですが、資料が古い場合や質問に必要な情報がない場合には、回答案の確認が必要です。資料の管理者、更新状況、参照範囲を整理し、回答から元資料をたどれるようにします。根拠が見つからない質問は人へ渡し、資料の不足として記録します。
CRMとの連携では何から整えればよいですか？
顧客との接点、商談の状況、次の対応を、担当者が同じ場所で確認できるようにするところから始めます。入力項目を増やす前に、その項目を誰がどの判断に使うかを決めます。HubSpotのAI活用については「HubSpotのAI活用を総まとめ」もご覧ください。
まとめ
これらの事例は、次のように分けて考えられます。
- 商談要約
- 提案書や記事の下書き
- 問い合わせへの回答案
- コードや文書の作成補助
- 社内資料の検索
共通するのは、AIに渡す情報を整え、出力を人が確認し、その結果を次の業務で使えるよう記録する流れです。
まずは次の順で始めてください。
- 作業を選ぶ ── 自部門で繰り返している文章作成や情報検索の作業をひとつ選びます
- 資料と担当者を決める ── 参照する資料と確認担当者を決めます
- 記録を残す ── 試した結果と修正理由を残します
その記録を見て、資料を整えるか、対象業務を広げるかを判断できます。このテーマの関連記事はAI実務活用ガイドでも確認できます。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
