%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}
この記事の結論
AIマルチツール統合活用の設計とは、業務の各工程でAIが担う作業と人が確認する内容を決め、複数のAIツールの役割と使い分けを定めることです。「AIツールをいくつも契約したけれど、結局いつも同じものを開いている」「担当者によって使うツールも、顧客情報の入力先も違う」。複数のAIを使う職場では、こうした状態から使い分けを考えることがあります。
AIマルチツール統合活用の設計とは、業務の各工程でAIが担う作業と人が確認する内容を決め、複数のAIツールの役割と使い分けを定めることです。「AIツールをいくつも契約したけれど、結局いつも同じものを開いている」「担当者によって使うツールも、顧客情報の入力先も違う」。複数のAIを使う職場では、こうした状態から使い分けを考えることがあります。
AIマルチツール統合活用では、使うツールの数を決める前に、業務の各工程でAIが担う作業と人が確認する内容を決めます。 対象業務を一つ選び、入力、作成、確認、記録の流れを書き出すことが出発点です。
この記事では、ChatGPTやClaudeなどを比較する軸から、業務別の使い分け、ツール間の受け渡し、HubSpotを含む顧客業務での確認点までを順に整理します。ツールを選ぶ担当者や業務手順を整える担当者が、何を試し、どの結果なら運用へ進めるかを判断できるようにします。品質や情報管理の条件を満たせない工程は、AIを使う範囲から外す判断も必要です。
以下の画像は、本記事で扱う複数ツールと業務フローの関係を示すイメージです。自社の業務に当てはめる際は、情報を渡す工程ごとに、参照元、受け取る担当者、確認してから進める条件を書き添えてください。
この記事でわかること
対象業務の選び方から試行、運用後の見直しまでを、判断する順序に沿って解説します。各節では、比較の前にそろえる条件、作業を先へ進める条件、条件を満たさなかった場合の戻り先を示します。自社の手順に当てはめる際は、判断した理由も残してください。
- 選定の考え方 — 入力形式、必要な出力、人が確認できる根拠を明らかにしてから比較します。
- 業務別の使い分け — 文章、調査、開発、CRM運用で、同じ条件を使って出力と修正の手間を比べます。
- AIポートフォリオの設計 — 中核、専門、試行の役割を分け、利用実態と管理負荷から継続を判断します。
- 業務フローへの組み込み — 直列、並列、役割別の進め方と、工程を先へ進める条件を示します。
- HubSpotとの連携と注意点 — 顧客情報の正本、アクセス設定、CRM更新前の確認事項を整理します。
AIツールは業務の流れから選ぶ
最初に決めるのは製品名ではなく、AIを試す業務です。現在の業務で情報がどこから来て、どこで止まり、何を記録するかを追います。
そのうえで成果物と受け取る人を明確にすると、AIを使う工程と人が確認する工程を分けられます。
まず手作業と情報の分散を見つける
業務の情報がスプレッドシート、メール、CRM、チャットに分かれていると、担当者は最新の内容を探し、必要に応じて転記します。この流れを残したままAIを追加すると、AIへの入力や結果の記録にも手作業が増えます。
営業メールを例にすると、次の流れが一連の工程です。
- 顧客情報の参照
- 文面の下書き
- 担当者の確認
- 送信
- CRMへの記録
最初に各工程の担当者と情報源を並べ、顧客情報の正本、送信を判断する人、送信後の記録先を決めます。情報源が特定できない場合は、AIによる下書きより先に参照先を整えます。
業務を書き出すときは、「顧客名はCRMで確認する」「納期は担当者が確認する」のように、情報ごとの確認先まで具体化します。
メールとCRMで内容が食い違うなら、どちらを採用するか担当者が判断してから入力を作ります。この判断が未了のままでは、AIの出力が自然な文章でも送信には進めません。
作業が止まる場所も記録します。止まる場所ごとに、次の対応から始めます。
- 資料を探す段階で止まる ── 情報源の整理
- 下書きの修正で止まる ── 指示と入力の見直し
- 承認で止まる ── 確認責任者と判断条件の明確化
たとえば承認待ちが原因なら、別のAIを試す前に、誰がどの記述を承認するか決めます。止まる理由に対応する工程を直してから、その工程にAIを使うか判断してください。
工程を整理したら、AIを使う前後で担当者が何を受け渡すかも書きます。営業メールなら次のような形です。
- 確認済みの顧客情報と伝える用件 ── 下書き担当へ渡す
- 確認済みの文面だけ ── 送信担当へ渡す
受け渡す情報と判断者を書けない工程は、ツールの比較に進む前に業務手順を整えます。
この段階の記録には、次の項目を工程ごとに並べます。
- 参照する情報
- AIへ渡す情報
- AIから受け取る成果物
- 人が照合する情報
- 完了後の記録先
営業メールなら、顧客名と対応履歴はCRMで照合し、顧客への約束は担当者が確認し、実際に送った内容をCRMへ記録する、と書けます。
各欄を埋める際に正本や担当者が不明になったら、製品の選定を止め、その欄を決めることを先行作業にします。
比較対象を業務上の評価軸でそろえる
業務と情報源が定まったら、同じ入力と評価項目でツールを比較します。業務ごとに見るものは次のとおりです。
- 文章 ── 事実の保持、指定した文体、修正の手間を確認します
- 調査 ── 主張に対応する出典をたどれるかを見ます
- 開発 ── 変更差分と実行結果を確認できるかを見ます
次の表を使い、その業務で欠かせない条件を先に選んでください。
| 評価軸 | 確認すること | 判断の目安 |
|---|---|---|
| 入力との相性 | 文書、表、画像、コードなどを扱えるか | 必要な形式を扱えない場合は候補から外します |
| 出力の確認性 | 根拠や引用、処理結果を人が確かめられるか | 根拠をたどれない業務では人の確認工程を残します |
| 業務との接続 | CRMや開発環境など既存の作業場所とつながるか | 転記が増える場合は連携方法を再検討します |
| 再現性 | チームで同じ指示と手順を使えるか | 担当者ごとに品質がぶれる場合は指示と確認表を整えます |
| 運用負荷 | 管理、教育、契約の手間に見合うか | 継続利用の根拠がなければ試行にとどめます |
比較前に、各評価軸を「満たす条件」と「運用しながら調整できる条件」に分けます。営業メールなら、次のように分けられます。
- 必須 ── 宛先と顧客への約束を確認できること
- 調整できる ── 文体の細かな違いは担当者が直せるかを試せます
必須条件を満たさない出力は、文章の読みやすさで埋め合わせず、その理由を記録します。
比較結果には、評価だけでなく判断の根拠を添えます。
- 「修正が必要」なら ── 修正した箇所と参照先を書きます
- 「確認できない」なら ── 不足した資料や権限を書きます
参照資料そのものが欠けている場合はツールを替えても比較条件が整いません。資料がそろっていて特定の出力だけ確認しにくい場合に、別のツールや出力形式を試します。この順序で切り分けると、製品の差と業務側の準備不足を混同しにくくなります。
比較の記録には、次の項目を対応させます。
- 入力資料
- 依頼文
- 出力
- 担当者による修正
- 採用または見送りの理由
たとえば事実は正しくても毎回CRMへの転記で内容を確認し直すなら、出力品質だけで採用せず、受け渡しを含む手順で比べます。
比較対象の間で入力できる情報が異なる場合は、その違いを明記し、製品だけの優劣として扱わないようにします。
判断に迷うときは、評価軸を合計点にせず、先に必須条件を確認します。
たとえば調査業務で文章の読みやすさは十分でも、公開元の原文と主張を照合できなければ、その成果物は調査結果として採用しません。
必須条件を満たすもの同士で初めて、修正の手間、受け渡し、管理負荷を比べます。この順序なら、業務上必要な確認を便利さで置き換えずに済みます。
小さな範囲で適合性を確かめる
試行する業務は、成果物を人が評価でき、従来の作業手順と比較できるものから選びます。
既存の方法とAIを使う方法で同じ種類の成果物を作り、次のものを残します。
- 事実の誤り
- 修正内容
- 確認と記録までに要した手間
入力資料、依頼内容、評価者が異なる結果を並べると、ツールによる差と条件による差を見分けにくくなります。
試行前には、成果物を使える状態を文章で定義します。たとえば営業メールなら、次の状態です。
- 参照した顧客情報と文面の事実が一致している
- 担当者が約束となる表現を確認できる
- 送信後の記録先が決まっている
評価時は「使える・使えない」だけで終えず、どの箇所を誰が直したかを残します。宛先や約束に関する誤りは送信を止める条件とし、表現の調整とは分けて扱います。
評価後は、問題の種類ごとに戻り先を決めます。
- 参照資料に必要な情報がなければ ── 情報源と入力を直します
- 資料はそろっているのに指示を取り違えたなら ── 依頼文と出力形式を直します
- 評価者によって判定が分かれるなら ── 許容する表現と止めるべき誤りを確認表に書き、同じ条件で再評価します
再評価では、修正した条件と結果を対応させます。
- 入力を直したなら ── 以前に不足した事実を確認できるかを見ます
- 指示を直したなら ── 指定した形式や表現が守られるかを見ます
原因と異なる箇所をまとめて変えると、何が改善につながったか判断できません。
たとえば「納期に触れない」という指示を守れず、確認されていない日付を下書きに加えた場合は、まず入力資料にその日付が含まれていないか確認します。
- 資料に含まれていたなら ── 渡す情報を絞ります
- 含まれていなかったなら ── 出力時の確認項目に「納期の記述は正本と照合する」を加えます
どちらの場合も、日付の記述を除いた文面で用件が成立するか確認してから、下書きに任せる範囲を決めます。
運用へ進める前に、試行を担当していない人が確認表と情報源だけで成果物の採否を判断できるか確かめます。
- 判断に迷った箇所 ── 参照先や確認方法を手順に追記し、同じ条件で再評価します
- それでも重要な誤りを見つけられない場合 ── AIに任せる情報や作業の範囲を狭め、担当者が正本を確認する工程を残します
運用へ進めるかは、次のように判断します。
- 必須条件を満たし、担当者が確認を続けられると判断できた工程 ── 使用範囲、確認責任者、記録先を定めて運用に進みます
- 条件を整えても必要な品質を確認できない工程 ── 扱う情報や作業を狭めて試すか、AIの適用範囲から外します
- 別の業務へ広げる際 ── 入力情報、成果物の使い道、確認者が試行時と同じかを確かめ、変わった条件を再評価してください
主要ツールは得意領域と接続方法で比べる
比較する業務が決まったら、製品を同じ条件で試します。AIツールの名称やモデルは変わるため、固定の順位で選ぶと業務との適合を見落とします。
実際に扱うデータ、作業環境、結果の確認方法を先に決め、その条件で製品を比べます。以下の表は選定時の観点を整理したものであり、個別製品の性能を保証するものではありません。
比較では製品名より作業の特徴を見る
| ツール | 検討しやすい用途 | 選定時に確かめること |
|---|---|---|
| ChatGPT | 汎用的な文章作成、画像を含む作業、データ整理 | 必要な入力形式と利用環境で使える機能を確認します |
| Claude | 長い資料の整理、文章の構成、コードを含む検討 | 入力できる情報の範囲と出力の確認方法を試します |
| Gemini | Google Workspace上の資料を使う業務や情報整理 | 利用アカウントで使える連携範囲と権限を調べます |
| Cursor | 開発環境内でのコード作成や修正 | 対象リポジトリ、編集範囲、変更差分の確認手順を決めます |
| Manus | 複数段階の調査や作業をまとめて進めたい場面 | 実行内容と結果を追跡でき、人が止めたり修正したりできるか確かめます |
| Perplexity | 出典をたどりながら情報を調べる業務 | 引用先が一次情報か、主張と根拠が対応しているか確認します |
| Cursor | 開発環境内でのコード作成・修正とリアルタイムコード補完 | 対象リポジトリ、編集範囲、変更差分の確認手順を決めます |
この表から製品を選ぶ際は、「何を作れるか」に加え、「担当者がどこまで検証できるか」を見ます。
- 調査結果 ── 出典への移動だけでなく、引用した箇所が本文の主張を支えているかを確認します
- コード修正 ── 提案の説明だけでなく、実際の差分と実行結果を確認します
確認方法を用意できない用途は、作業範囲を狭めて試します。
同じ用途に複数の製品が当てはまる場合は、成果物を使う担当者が確認できた内容を並べます。
- 調査 ── 出典を開いて確認できた主張
- 文書 ── 資料と照合して修正した記述
- 開発 ── 意図した変更と検証結果
どちらの出力も条件を満たすなら、受け渡しや記録まで含めた業務手順で選びます。一方だけ根拠や差分を確認できないなら、その用途では確認できる方法を優先します。
出力の検証方法も業務ごとに変えます。
- 調査 ── 「主張、公開元、原文の該当箇所」を対応させ、原文が主張を支えなければその記述を使いません
- 開発 ── 「依頼した変更、実際の差分、実行結果」を対応させ、意図しない変更があれば採用前に範囲を戻します
- 文章作成 ── 「入力した事実、出力した記述、修正理由」を対応させます
同じ「品質がよい」という評価でも、確認できた中身を残して選ぶことが大切です。
業務別に使う製品を絞る
同じツールでも、依頼する業務と入力する情報によって出力は変わります。まず業務の代表例を選び、各ツールに渡す条件をそろえます。
そのうえで、成果物の品質に加え、人がどの箇所を直し、何を確認できなかったかを比較します。
| 業務 | 候補を選ぶ視点 | 人が確認する点 |
|---|---|---|
| 記事や長文資料の下書き | 構成の一貫性、指定条件の保持 | 数字、固有名詞、出典、公開表現 |
| 営業メールの下書き | 顧客情報を参照できるか、文面を調整しやすいか | 宛先、事実関係、約束、送信可否 |
| 市場や企業の調査 | 出典を示し、原文へ移動できるか | 公開元、発表時期、主張との対応 |
| コードの修正 | 開発環境との接続、差分の把握 | 変更範囲、既存機能への影響、実行結果 |
| CRM情報の整理 | CRM内のデータや権限と接続するか | 対象レコード、更新項目、変更後の値 |
| プレゼン資料の構成案づくり | Claude（次点：Gemini） | 論理構成の整理に強い |
評価結果は、業務ごとに次の内容を並べて残します。
- 入力した資料
- 確認できた内容
- 修正した内容
- 確認できずに止めた内容
調査で原文を確認できない、コード修正で変更範囲を追えないなど、業務に必要な確認ができない場合は、その工程での使用を見送ります。出力の見た目だけで採用を決めず、担当者が結果を検証できるかを判断条件にします。
- 確認できなかった理由がアクセス権や資料の不足なら ── その条件を整えて再評価できます
- 出力そのものから変更箇所や根拠を追えないなら ── 別の方法で検証できるかを先に確かめます
検証方法が決まらないまま、成果物を顧客対応や公開に使わないようにします。
用途を絞る際は、同じ製品を複数の業務に広げる場合も業務ごとに評価します。
- 記事で出典を確認できたこと ── 営業メールで顧客への約束を確認できることの根拠にはなりません
- 新たな業務 ── その成果物を使う人が必要な確認を実行できた場合にだけ、利用手順へ加えます
業務ごとの結果を並べたら、製品名の一覧ではなく「この業務では何を任せ、どの確認を人が行うか」を決定事項として残します。作業の終点は、次のように明記します。
- 記事 ── 構成の下書きまで
- 営業メール ── 確認済み情報を使った文案まで
- CRM ── 更新候補の提示まで
終点を越える新しい使い方が出たときは、既存の評価を流用せず、必要な確認を追加してから試します。
製品仕様は公式情報で確認する
AI製品の対応機能や連携条件は変わります。実際に利用するアカウントで必要な機能と権限を確認し、試行時の条件を記録してください。
- 製品の案内で利用可能とされる機能でも ── 自社の利用環境で使えるか、必要な情報にアクセスできるかは別に確かめます
- 使えることを確認できなければ ── その機能を前提に業務手順を決めません
確認するときは、使いたい機能名だけでなく、次の内容を整理します。
- その機能を使う担当者
- 対象データ
- 期待する出力
確認の結果ごとの対応は次のとおりです。
- 機能が使えても必要なデータにアクセスできなければ ── 入力方法を見直します
- 権限を広げる必要があるなら ── 情報管理の条件から判断します
- 権限変更が必要な場合 ── 対象データと利用目的を確認してから設定を判断し、変更後に利用者が実際に扱える範囲を確かめます
HubSpotのAI機能についても、利用者に開放する機能とAIが参照するデータの範囲を管理者が確認する必要があります（出典：HubSpot AI機能を利用するためのアカウント設定）。
AIポートフォリオは役割を絞って組み立てる
業務ごとの比較結果が出たら、各ツールをどの役割で使うか整理します。AIポートフォリオは、利用するツールを業務上の役割に沿って整理する考え方です。
- 中核ツール ── 日常業務を支える
- 専門ツール ── 特定業務に使う
- 試行中のツール ── 適合性を確かめる
配置を決めた後も、利用状況、成果物の品質、確認の手間、情報管理の条件を見て見直します。
中核と専門ツールの役割を分ける
- 日常的な文章の下書きや要約 ── 共通の手順を設けます
- 開発や出典付き調査など ── 業務ごとの確認手順を設けます
- 試行中の用途 ── 入力できるデータと評価方法を決めてから始めます
- どの役割にも当てはまらないツール ── 対象業務を明確にしてから継続を判断します
| 役割 | 対象にする業務 | 運用上の扱い |
|---|---|---|
| 中核 | 複数部門で繰り返す文章作成や要約 | 共通の利用ルールと確認方法を整えます |
| 専門 | 開発、調査、CRM分析など特定分野 | その業務の担当範囲と責任者を定めます |
| 試行 | 適合性を確かめている新しい用途 | 対象データと期間を限定して評価します |
役割を決めるときは、ツール名だけでなく「どの業務で使い、誰が結果を確認し、どこへ記録するか」をセットで書きます。
- たとえば文章作成に複数のツールを使うなら ── 共通の下書きと専門的な資料整理で役割が分かれるかを確認します
- 役割を説明できなければ ── 使い分けを増やす前に既存の手順で対応できるか試します
試行から運用へ移す際は、試行を担当した人だけが確認できる状態になっていないかも確かめます。
- 別の担当者が同じ資料と手順で成果物を確認できれば ── 入力条件と確認方法を共有できます
- 確認に追加の説明が必要なら ── その内容を手順へ反映してから利用範囲を広げます
- 担当者が交代すると確認できない根拠が出る場合 ── 出典や判断理由の残し方を先に直します
役割表には、使い始める条件だけでなく見直す条件も添えます。たとえば次の場合です。
- 中核として使う業務の確認項目が変わった
- 専門用途の担当者が交代した
- 試行の対象データが変わった
変化した条件を特定し、影響する業務だけ再評価します。試行で確認した範囲と運用する範囲が一致しない場合は、その差を埋める確認を終えるまで利用を広げません。
契約は利用実態と成果で見直す
契約を見直す際は、誰がどの業務で使い、成果物にどのような修正が必要だったかを確認します。利用が少ない場合は、次の点を分けて考えます。
- 対象業務が定まっていないのか
- 業務に合っていないのか
対象業務と評価方法を定めても使われないなら、継続の理由を再検討します。
利用が続いていても、状況に応じて次のように判断します。
- 確認や修正に手間がかかる場合 ── 入力情報と手順を調整し、調整後は同じ種類の成果物で修正内容と確認の手間を比べ直します
- 業務上の条件を満たせなければ ── その工程は人が担う形に戻します
- 使う場面が限られていても ── 担当者が成果と必要性を説明できる専門用途なら、その役割を明記して判断します
費用を見る際は、契約額だけを切り出さず、入力準備、確認、修正、権限管理に必要な作業も同じ業務単位で確認します。
- 複数の契約を残す場合 ── それぞれが担う工程と、片方を使わない場合に困る条件を書き出します
- 違いを示せなければ ── 同じ入力と確認基準で改めて比較します
- 成果物は同程度でも受け渡しや確認に差があるなら ── 工程全体の手順に沿って選びます
見直しの結論は、利用が多いか少ないかだけで決めません。
- 対象業務が定まっているのに使われないなら ── 担当者が使いにくい工程と理由を確認します
- 成果物は使えるものの管理や受け渡しが難しいなら ── その工程を直してから再評価します
- 用途を説明できず、手順を整えても継続する根拠が示せない場合 ── 契約を維持する理由を見直します
たとえば下書きの品質は条件を満たしていても、担当者が毎回同じ情報を複数の場所へ入力し、内容を照合し直しているなら、契約判断の前に情報の受け渡しを調べます。
受け渡しを整えた後も確認までの手間が従来の方法に見合わないなら、その用途で使い続ける理由を再検討します。成果物の品質、確認の手間、管理負荷のどこが判断を左右したかを分けて残してください。
機能の重複と管理負荷も比較する
似た機能を複数使う場合は、次の点を確認します。
- 同じ情報をどこに保存するか
- 利用権限を誰が管理するか
- 担当者がどの業務でどのツールを選ぶか
使い分けを説明できない場合は、既存の手順で対応できるかを先に試します。機能が重なっていても、入力形式や作業環境が違えば用途を分けられます。
- 対象業務、選ぶ理由、結果の記録先を一覧にする ── 担当者が迷ったときに参照できるようにします
- 業務や扱う情報が変わり、一覧にない使い方が生じたとき ── 従来の許可をそのまま広げず、入力条件と確認責任者を見直します
ワークフローにAIと人の確認点を組み込む
使用ツールを決めたら、業務の開始条件、AIに渡す情報、期待する出力、人の確認、記録先を一つの流れにします。
進め方は、次のどれかを選びます。
- 工程を順番に渡す
- 同じ依頼を比較する
- 業務段階で役割を分ける
次の工程へ進む条件も定めておくと、根拠のない情報や未確認の判断を引き継がずに済みます。
直列型は工程ごとに受け渡す
直列型は、調査、要約、下書き、確認のように工程を順番に進める方法です。各工程で何を受け取り、何を次へ渡すかを決めます。
記事制作なら、次の順に進めます。
- 調査 ── 出典と確認できた内容を整理します
- 構成と本文の作成 ── 調査をもとに作ります
- 編集者の確認 ── 事実と表現を確認します
根拠が欠けている場合は執筆へ進まず、情報収集へ戻します。受け渡しには前工程の全文を無条件に使わず、決定事項、参照先、未確認点を分けて記録します。
受け取る側は、次のことを確かめます。
- 出典が開けること
- 出典と記述が対応すること
- 未確認点が本文で断定されていないこと
問題があれば、どの情報を調べ直すかを示して前工程へ戻します。たとえば出典は開けても主張を支える記述が見つからないなら、その主張を確認済みとして引き渡しません。
前工程に戻せない情報がある場合は、その情報を使わずに成果物が成立するか判断します。
- 成立するなら ── 該当する記述を外して確認を続けます
- 成立しないなら ── 作業を止めて情報源の確認を優先します
受け渡しの記録には、次の項目を分けて書きます。
- 確認済みの事実
- 参照先
- 担当者が判断したこと
- 未確認のこと
下書き担当は確認済みの事実だけを本文の根拠に使い、未確認のことは調査担当へ戻します。編集者が後から確認するときも、どの記述をどの資料で照合すればよいか分かる状態を完了条件にします。
並列型は同じ条件で結果を比べる
並列型は、同じ依頼を複数のAIに渡し、結果を比較する方法です。文章案や分類結果のように、採用基準を事前に決められる業務で検討します。
比較する入力情報、依頼文、評価項目をそろえ、人が違いと採用理由を記録します。
- 判断が分かれた場合 ── どの条件が曖昧だったかを確認して評価項目を直します
- たとえば二つの文章案で顧客への約束の表現が異なるなら ── 読みやすさを比べる前に、どの表現が確認済みの事実に沿うかを調べます
- 採用した出力が期待した品質に届かなければ ── 実際の業務で確認し、使い方を見直します
出力を比べた結果ごとの対応は次のとおりです。
- 両方の出力に同じ誤りがあれば ── ツールを選び直す前に共通の入力資料を確認します
- 異なる箇所で誤りが出たなら ── どの確認項目で発見できたかを残します
- 比較そのものが確認の手間を増やす場合 ── 並列で使う理由と対象業務を見直します
- 採用理由が説明できない場合 ── 評価項目を明確にしてから比較し直してください
両方とも必須条件を満たした場合は、採用した案だけでなく、採用しなかった案との違いも記録します。
- 違いが表現だけなら ── 確認と受け渡しが簡単な手順を選べます
- 事実関係や根拠の示し方が異なるなら ── 正本との照合結果を先に確定します
並列で得た案を混ぜる場合も、組み合わせた文面を新たな成果物として確認してから次へ渡します。
役割別型は選択の迷いを減らす
役割別型は、調査、文書作成、CRM記録などの業務段階ごとに使用ツールを決める方法です。段階ごとに担当者と確認内容を明記し、出力を採用する人が分かるようにします。
| 段階 | AIが支援する作業 | 人が確認する内容 |
|---|---|---|
| 情報収集 | 公開情報の検索や資料の要約 | 出典、公開日、顧客情報の扱い |
| 下書き | メール、記事、提案内容の草案 | 事実、表現、顧客への約束 |
| CRM記録 | 入力候補や要約の作成 | 対象レコード、値、関連付け |
| 対外アクション | 返信や更新の準備 | 送信先、更新内容、実行可否 |
この表を業務手順にする際は、各段階の完了条件も書き添えます。
- CRM記録なら ── 担当者が対象レコードと更新後の値を照合できてから完了とします
- 対外アクションなら ── 送信先、添付情報、約束となる記述を確認できてから実行を判断します
どの進め方でも、担当者が確認できない出力は次の工程へ渡しません。
- 確認で繰り返し同じ問題が見つかる場合 ── 担当者への注意だけで済ませず、入力や受け渡しの手順を直します
- 手順を直した後 ── 問題が見つかった工程の成果物で確認項目が働くかを確かめます
進め方を選ぶ際は、次のように検討します。
- 工程間で確認済みの情報を渡す必要があれば ── 直列型
- 同じ成果物の採用基準を確かめたいなら ── 並列型
- 担当業務ごとに確認責任者が異なるなら ── 役割別型
どれを選んでも、受け取る人が確認できる情報と、問題があった場合の戻り先を手順に記載してから運用します。
手順を実際に使うときは、担当者が不在でも次の人が判断できるか確認します。たとえば下書きからCRM記録へ進む際に、確定した内容と保留中の内容が区別されていなければ、記録担当は作業を止めて確認者へ戻します。引き継ぎ先が推測で埋めなくても進められることを、工程の完了条件にしてください。
HubSpotを含む顧客業務ではCRMを正本にする
顧客情報をAIで扱う業務では、参照する情報の置き場所と更新責任を決めます。スプレッドシートやメールに分散した内容を個別にAIへ渡すと、古い情報を使う可能性があります。
コンタクト、会社、取引などの記録をCRMで関連付け、AIが下書きや要約を支援し、人が内容と更新結果を確認する流れを設計します。
顧客接点から記録までをつなげる
営業メールでは、次の流れで進めます。
- 担当者が参照すべき顧客情報を確認する ── AIが文面を下書きします
- 担当者が事実関係、顧客への約束、宛先を照合する ── そのうえで送信を判断します
- 送信後に対応内容をCRMに記録する ── 必要な取引や次のタスクに結び付けます
記録するときは、下書きに使った情報と実際に送った内容が異なっていないかも確かめます。
- 送信後の記録が抜けるなら ── 下書きの品質だけを改善しても次の担当者は経緯を追えません
- 対応の完了条件 ── 送信結果と関連レコードの確認を含めます
顧客情報に食い違いが見つかった場合は、どの記録を正本として扱うかを担当者が確認し、必要な更新を終えてから下書きを作ります。
AIが示した更新候補は、そのまま正本として扱わず、次のものを照合します。
- 対象レコード
- 更新項目
- 根拠となる情報
更新後も値と関連付けを読み直し、意図した記録に反映されたことを確かめます。
更新候補の根拠がメールにあり、CRMの値と異なる場合は、担当者が情報の時点と確認先を調べます。
- どちらが正しいか決められない間 ── AIに値を選ばせて更新しません
- 確認できた値 ── 対象レコードへ反映し、更新後の値を読み直してから次の対応に使います
たとえば顧客からのメールに新しい担当者名が書かれていても、それが既存担当者の交代なのか、その案件だけの連絡先なのかは文面だけでは決められない場合があります。
- CRMの担当者情報 ── すぐに置き換えず、連絡を受けた担当者が確認先と更新する項目を決めます
- 更新した後 ── 対象レコードと関連付けを読み直し、次の連絡に使う情報が意図どおりか確かめます
受注後の対応や請求に関わる業務も、どこに何を記録するかを整理します。請求処理までCRMに集約するかは既存の会計・販売管理の運用によって異なるため、連携の責任範囲を先に確認します。
企業様によって最適な形は異なります。まず現在の正本と担当者を確かめ、そのうえでAIに任せる作業を決めてください。
Breezeへ渡す情報と権限を管理する
HubSpotのBreezeを顧客業務で使う際は、AI機能へのアクセスと、AI機能が参照するデータの設定を確認します。対象業務に必要な情報、利用者の権限、確認責任者を整理してから設定を判断します（出典：AI機能を利用するためのHubSpotアカウント設定）。
設定を確認した後も、利用者が実際に参照できる情報と、業務上参照してよい情報を照らし合わせます。
- 必要なデータが見えなければ ── 業務の設計に戻ります
- 不要なデータまで扱えるなら ── 入力範囲や権限を見直します
扱う情報や担当者が変わった場合も、従来の設定でよいか確認してから利用範囲を広げます。
設定の確認結果は、「誰が」「どの業務で」「どの情報を使うか」に結び付けて記録します。
- 権限があることと、その情報を特定の用途へ入力してよいこと ── 別に判断し、判断できない情報は入力対象から外します
- 必要な情報を外すと成果物を確認できない場合 ── 入力範囲を広げる前に、業務を分けて人が正本を確認する方法を検討します
確認時には、実際に業務を行う担当者が、次の点を順に確かめます。
- 必要なレコードを参照できるか
- 業務に不要な情報を入力対象に含めていないか
- 出力をどの正本と照合するか
必要な情報が見えない場合は権限変更を即決せず、担当者による確認で作業が成立するか検討します。担当者や対象データが変わったときは、この確認をやり直してから手順を更新します。
AIの提案を業務ルールに接続する
AIによる要約や分類は、担当者が結果を確認してから顧客対応やCRM更新に使います。
- 問い合わせを分類する場合 ── 分類結果と根拠を担当者が確かめ、対応先を判断します
- 判断が分かれる内容や根拠が不足する内容 ── 確認待ちにし、必要な情報を調べてから進めます
管理項目は、業務上の判断やレポートに使うものを選び、更新する人とタイミングを決めます。
- 入力漏れが繰り返される場合 ── 必須項目、通知、確認工程のどこを直せば防げるかを調べます
- 修正後 ── 対象レコードと更新後の値を確認し、記録先が違う問題なのか、入力内容が違う問題なのかを分けて見直します
分類に迷う問い合わせが続くなら、担当者が判断した理由を集め、分類条件に不足している情報を確認します。
- 条件を直した後 ── 判断が分かれた内容で再び評価し、対応先を説明できてから手順へ反映します
- 根拠を確認できない分類 ── 対応先を推測して確定せず、確認待ちとして担当者へ戻します
たとえば一つの問い合わせに契約内容の確認と操作方法の質問が含まれている場合は、分類名だけで対応先を確定しません。
- 担当者がそれぞれの用件を確認する ── 対応を分ける必要があるか判断します
- 分類条件を見直す際 ── このように判断が分かれた問い合わせを使い、担当者が対応先と理由を説明できるか確かめます
導入後は品質、コスト、情報管理を見直す
試行時に合っていたツールも、業務の内容や利用条件が変われば見直しが必要です。次の点を同じ業務単位で確認し、継続、修正、停止を判断します。
- 成果物の品質
- 確認を含む作業の手間
- 費用
- 扱う情報の条件
見直した理由を手順にも残すと、担当者が変わっても判断を引き継げます。
品質は修正内容と確認漏れから評価する
出力を評価するときは、次の問題を分けて記録します。
- 事実の誤り
- 指示の取り違え
- 文体の不一致
- 必要情報の抜け
入力を整えれば直せる問題なのか、人が確認しても発見しにくい問題なのかによって、次の対応が変わります。
まず対象業務と評価項目を固定し、従来の方法とAIを使う方法で同じ種類の成果物を比べます。事実関係など、顧客へ出す前に満たすべき条件は試行前に決めます。
- 条件を満たし、担当者が確認を続けられるなら ── 運用を検討します
- 満たさない場合 ── 入力や指示を修正して再評価し、それでも改善しなければ適用範囲を狭めます
評価条件と測定結果を記録して判断する際は、NIST AI RMF Coreも参照できます。
判定に使う閾値は、過去の修正記録を表現の調整と事実の誤りに分け、業務上の許容条件と照らして決めます。修正件数だけでは、公開や送信を止めるべき誤りを区別できません。
- 修正内容と停止条件への該当有無 ── 記録し、同じ基準で判定できるか確認します
- 過去の記録が不足している場合 ── 件数から閾値を決めず、停止条件を個別に確認します
見直す順序は、次の形にします。
- 止めるべき誤りがないか
- 担当者が根拠を確認できるか
- 表現の修正と作業の手間を評価する
結果に応じた戻り先は次のとおりです。
- 事実の誤りがあれば ── 入力資料へ戻ります
- 確認しても発見しにくい誤りなら ── 人の確認方法かAIに任せる範囲を見直します
- 表現だけに修正が集中するなら ── 指示文と見本を調整して同じ種類の成果物で確かめます
たとえば営業メールの評価では、顧客名や約束に誤りがあれば送信を止め、正本と入力を照合します。
- 正本は正しいのに誤った文面が続くなら ── 指示や下書きの対象範囲を見直します
- 担当者が誤りを見つけられなかった場合 ── 確認表の項目と確認に使う資料を見直します
この切り分けを終えてから、表現の修正や作業時間を比較します。
判断記録には、次の項目を対応させます。
- 問題のあった記述
- 照合した正本
- 発見した工程
- 修正した内容
誤りが見つかった場合の対応は次のとおりです。
- 入力資料と出力の両方に同じ誤りがあれば ── 情報源へ戻ります
- 正本にはない誤りが出力だけにあれば ── 指示と確認方法を見直します
- 担当者の確認を通過した後に誤りが見つかった場合 ── 確認表に項目を加えるだけでなく、その項目を担当者が正本と照合できるか試します
発見できないなら、AIに任せる作業を狭めてください。
作業時間は、AIが出力するまでではなく、入力の準備、事実確認、修正、承認、記録までを含めて比べます。
- 品質が条件を満たしても全体の手間が増える場合 ── 重複した入力や確認工程がないかを調べます
- 手順を直しても改善しないなら ── 継続する理由を業務上の成果と照らして判断します
品質の条件を満たさない状態で確認工程だけを減らして運用に進めず、必要な確認を続けられる作業範囲に絞ってください。
情報管理は入力前に判断する
顧客情報や機密情報を扱う場合は、まず入力予定の情報を分類します。次に利用するサービスについて、次の条件を確認し、業務上の条件に合うか判断します。
- 契約条件
- データの保存先
- 学習への利用
- アクセス権
- 保持期間
判断の順序は、次のとおりです。
- その情報が作業に必要かを確認し、不要な項目を外す
- 個人や顧客を識別できる記述を伏せても作業が成り立つか、要約で目的を満たせるかを試す
加工した情報でも文脈から顧客を特定できるなら、匿名化できたと判断せず、入力内容を見直します。
たとえば下書きに必要なのが問い合わせの種類と回答方針なら、顧客名や連絡先を渡さずに作業できるかを確かめます。
- 担当者が顧客固有の契約条件を判断する必要があるなら ── その判断をAIへの入力から切り離し、人が正本を確認してから文面へ反映する方法を検討します
- 加工後の情報で成果物を評価できなければ ── 入力項目を増やす前に業務の分担を見直します
入力内容を絞った試行では、担当者が出力のどこを正本と照合するかも決めます。顧客名を伏せた下書きなら、AIが示した文面を担当者が対象顧客の状況に合わせて確認し、固有の条件は正本から補います。
- 伏せた情報がないと文面の妥当性を判断できない場合 ── その判断を人の工程へ移せるか検討します
- 移せなければ ── その業務での入力方法を採用しません
入力の可否を決める記録には、次の項目を対応させます。
- 情報の種類
- 必要な理由
- 加工後に残る識別情報
- 利用条件を確認した担当者
- 出力を照合する正本
たとえば顧客名を伏せても、取引内容や経緯の組み合わせから顧客が分かるなら、名前だけを消した状態で入力可能とは判断しません。さらに情報を減らしても下書きの目的を果たせるか試し、果たせないなら顧客固有の判断を人が行う工程に戻します。
次に進める条件は、次のとおりです。
- 入力内容が業務上必要な範囲に収まる
- 利用するサービスの条件と利用者の権限を確認できる
- 担当者が出力を評価できる
どれかを確認できなければ、その情報を使う試行は止めます。条件を満たせない情報は入力せず、機密情報を使わない部分だけをAIに任せるか、従来の方法で作業します。
利用するデータの範囲、サービスの条件、利用者の権限が変わったときは、同じ順序で確認し直します。
使われない契約と手順を整理する
見直しでは、次の項目を確認します。
- 利用者
- 対象業務
- 成果物の品質
- 修正を含む作業の手間
- 費用
使われていないツールは、試す業務と評価方法を明らかにしてから継続を判断します。似た機能が重複している場合は、用途の違いを説明できるか確かめます。
判断した内容はツール一覧だけでなく業務手順にも反映します。次の内容を更新し、担当者が変わったときも同じ基準で進められるようにします。
- 使用する工程
- 入力方法
- 確認責任者
- CRMへの記録先
業務手順を変えた後は、実際の成果物で確認項目が機能しているかを確かめ、同じ修正が続くなら入力条件か役割分担を再検討します。
- 業務が変わったとき ── 以前の試行結果をそのまま当てはめず、新たに扱う情報と成果物の使い道を確認します
- 顧客へ出す内容やCRMへ記録する項目が変われば ── 確認責任者と完了条件も見直します
見直しの結論は、継続、手順の修正、利用範囲の縮小、利用の停止のいずれかとして、理由とともに残します。
- 継続する場合 ── どの業務と入力条件で確認できたかを明記します
- 手順を修正した場合 ── 問題が起きた成果物で修正後の確認が機能するか確かめます
- 利用範囲を変える場合 ── 担当者が新しい範囲を判断できるよう、対象外にする情報や工程も手順に反映します
よくある質問
ここでは、複数ツールの契約判断、顧客情報の入力、対外送信、チーム内の手順づくりで迷いやすい点を整理します。それぞれについて、先に確かめること、次へ進める条件、確認できなかった場合の対応を示します。
ChatGPTとClaudeは両方使うべきですか？
両方を使う前提にする必要はありません。代表的な業務で入力と評価項目をそろえ、出力品質、修正の手間、情報管理の条件を比べてください。片方で必要な条件を満たすなら、その手順で運用できます。
異なる業務でそれぞれを使う場合は、用途と確認責任者を明記します。役割の違いを説明できなくなったときは、同じ業務条件で比較し直します。比較前に必要な情報を両方へ入力できるかも確認し、入力条件をそろえられなければ結果の優劣を判断しません。両方が必須条件を満たす場合は、成果物を使うまでの確認、受け渡し、記録の手順を比べて判断します。
複数のAIへ同じ顧客情報を入力してもよいですか？
利用サービスごとのデータ利用条件と社内ルールを確認してから判断します。入力する情報を業務に必要な範囲へ絞り、匿名化や要約で代替できるか検討してください。加工後も顧客を特定できる内容が残るなら、その内容を含めて扱いを判断します。条件を満たせない場合は、その顧客情報を外部AIへ入力しない手順にします。
比較が目的なら、顧客を識別できる情報を使わずに出力の確認方法を試せるかを先に検討してください。代替した情報では評価できない場合は、比較する業務の範囲を変えるか、担当者が正本を確認する工程を残します。サービスごとに入力条件が異なるなら、その差を記録し、同じ情報を入力できたものとして結果を比較しないでください。
AIの回答をそのまま顧客へ送ってもよいですか？
送信前に担当者が内容を確認します。顧客の状況、契約や納期に関する記述、約束となる表現、宛先と添付情報を照合してください。確認できない内容があれば送信を止め、情報源に戻って確かめます。確認を終えた文面を担当者が送信すると判断した後、対応内容をCRMへ記録します。
情報源を確認できない記述があっても、その記述を外して用件が成立するなら文面を直して再確認できます。成立しないなら送信を保留します。送信後は、確認した文面と実際に送った内容、記録した対象レコードが対応しているか確かめてください。
チームで使い方をそろえるには何を決めますか？
業務ごとに、使用ツール、入力できる情報、指示文のひな形、確認項目、確認責任者、記録先を決めます。加えて、確認できない出力をどの工程へ戻すかを定め、実際に起きた修正や入力漏れを手順へ反映してください。使い方が定着しない場合は、教育に加えて工程や入力項目が複雑すぎないかを確認します。
手順を直したら、担当者が成果物と記録先を迷わず確認できるかを試します。担当者によって判断が分かれる項目は、判断理由を持ち寄って確認表の条件を具体化します。担当者が交代しても、同じ正本を参照し、同じ理由で進行または保留を判断できれば、その手順を共有できます。
まとめ
AIマルチツール統合活用は、対象業務の情報源と成果物を明らかにし、同じ条件でツールを比較して、AIと人の役割を手順に落とし込む進め方です。選定後も、品質、確認の手間、情報管理の条件から継続を判断します。
まずは、繰り返し発生していて成果物を担当者が評価できる業務を一つ選び、次の順序で試してください。
- 入力、作業、確認、記録の流れを書き出し、情報の正本と担当者を決めます。正本が分からなければ、参照先を整えてから試行します。
- AIを使う工程を選び、従来の方法と同じ評価項目で成果物と作業の手間を比べます。誤りがあれば、参照資料、指示、評価条件のどこを直すべきか分けて記録します。
- 品質と情報管理の条件を満たした工程だけを手順に組み込みます。満たさない工程は入力や使い方を見直し、同じ条件で改善を確認できなければAIの適用範囲から外します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。現在の情報の正本、担当者ごとの確認範囲、AIを試したい業務を整理したうえでご相談いただくと、見直す工程と試行時に確認する条件を具体化できます。
あわせて読みたい
ツールごとの比較を詳しく進めたい場合は、ChatGPTとClaudeの記事で文章作成などの評価軸を整理できます。開発や調査を含む業務の使い方を検討する場合は、CursorやManusの記事を参照してください。顧客接点での確認責任や、複数工程をつなぐ手順を具体化する際は、AIエージェントに関する記事も役立ちます。各記事を読む際は、自社で扱う入力、成果物を確認する人、次の工程へ渡す条件に照らして検討してください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
