%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}
この記事の結論
カスタムGPTsは、業務の指示や参照資料を設定し、特定の仕事を支援するAIアシスタントです。導入の要点は、AIに任せる作業と人が判断する範囲を先に決めることです。
カスタムGPTsは、業務の指示や参照資料を設定し、特定の仕事を支援するAIアシスタントです。導入の要点は、AIに任せる作業と人が判断する範囲を先に決めることです。
「ChatGPTを使うたび、同じ前提やルールを入力している」
「社内FAQや製品情報がExcelや資料に分散し、回答を探すのに時間がかかる」
「顧客情報をもとに提案書を作りたいが、AIにどこまで任せてよいかわからない」
こうした場面では、先に業務の流れを整理すると、カスタムGPTsに任せる範囲が見えてきます。カスタムGPTsとは、ChatGPT上で指示や知識、利用する機能を組み合わせ、特定の目的に合わせて設定するGPTです。資料の検索や回答案の作成を支援できますが、顧客への回答内容や業務上の判断は担当者が確定します。
使い始める前に決めたいのは、どの資料を根拠にするか、条件が足りないときに何を聞き返すか、どの時点で人へ引き継ぐかです。本記事では、営業FAQ、社内問い合わせ、データ分析、CRM情報の参照を例に、設計からテスト、運用の見直しまでを順に説明します。
この記事でわかること
社内FAQや営業準備にカスタムGPTsを使いたい業務担当者と、参照資料やアクセス範囲を管理する担当者に向けたガイドです。読み進めると、自社で最初に試す業務を選び、回答できる条件と保留する条件を定め、利用範囲を広げる前に何を確認すべきか整理できます。
次の画像を見ながら、業務の選定、参照資料の整理、GPT Builderでの設定、Actionsを使う場合の確認、共有後の見直しという順序を確認してください。各段階で決める担当者と、次へ進むために確認する出力も本文で示します。
- カスタムGPTsの役割 — 業務を「探す・整理する・判断する・記録する」に分け、GPTの出力と担当者の確定作業の境界を決めます。
- ユースケースと設計項目 — 営業FAQや社内問い合わせを例に、入力情報、回答の根拠、条件不足時の聞き返し、引き継ぎ先を整理します。
- 構築とテストの流れ — GPT Builderで設定した内容を、答えがある質問、答えがない質問、条件が足りない質問で確かめ、資料と指示のどちらを直すか判断します。
- ActionsとHubSpotの連携 — CRM情報を参照する場合の対象特定、取得結果の照合、更新を検討する前に決める手順を説明します。
- 運用で見直すポイント — 資料の改定や誤回答が起きたとき、影響する質問を特定し、修正後の利用再開を判断する方法を示します。
カスタムGPTsを業務フローのどこに置くか
カスタムGPTsを設定する前に、対象業務の開始点と終了点を書き出します。その間の作業を「探す」「整理する」「判断する」「記録する」に分けると、GPTに任せる作業を選びやすくなります。資料を探して回答案を作るところは支援対象にできます。顧客に伝える内容を確定する人と、対応履歴を残す場所も業務上の手順として決めます。
この切り分けは、GPTの回答が正しいかを評価する際にも使えます。資料を探せなかったのか、見つけた資料を読み違えたのか、判断が必要な場面で断定したのかを分ければ、直すべき箇所が明確になります。
業務フローの入口と出口を決める
営業担当者が打ち合わせ前に製品FAQを確認する場合、入口は担当者の質問と参照可能な製品資料です。GPTの出口は、資料に基づく回答案、参照箇所、資料だけでは判断できない点とします。担当者は原資料を確認し、顧客への回答内容や約束できる条件を確定します。
設計には、実際に受けた質問を使います。次の順に確認します。
- 質問の特定 ── 質問だけで製品や適用条件を特定できるかを見ます。特定できなければ、回答に進む前に何を聞き返すか決めます
- 根拠の確認 ── 資料のどの箇所が回答の根拠になるかを確認します。根拠が見つからなければ、推測した回答案を作らせず、確認先を示す動作にします
たとえば質問に製品名だけがあり、利用条件が書かれていない場合は、製品の一般的な説明と、その顧客に適用できるという判断を分けます。前者は資料の記載を案内できても、後者は条件の確認が必要です。期待する出力に「答えられる部分」「不足する条件」「確認先」を書いておくと、回答文が自然かどうかだけに評価が偏りません。
最後に、その出力を誰が確認し、確定した対応をどこへ記録するかを決めます。確認者が決まっていなければ、顧客向けの回答案として運用する前に担当を定めます。試験時には「質問」「期待する出力」「担当者の確認結果」を対応させて残すと、GPTの回答が整っていても業務の出口が曖昧なケースを見つけられます。
CRMを利用している場合は、コンタクトや会社の情報、過去の活動、取引の状況を担当者が確認する流れが土台です。GPTが作った下書きと確定した顧客対応を混同しないよう、下書きの確認方法と対応履歴の記録先を分けて決めます。
| 業務の段階 | カスタムGPTsが支援する作業 | 人が確認すること |
|---|---|---|
| 問い合わせ受付 | 質問の整理、関連資料の検索 | 緊急性と担当部署 |
| 商談準備 | 顧客情報や商談メモの要約 | 商談方針と優先事項 |
| 提案書作成 | 構成案や文章の下書き | 提案内容、条件、費用 |
| CRMへの記録 | 登録候補の整理 | 顧客情報と取引内容の確定 |
Excelや共有資料の分散を整理する
社内ルールやFAQをスプレッドシート、共有フォルダ、個別のメモで管理していると、同じ質問に対して異なる版を参照することがあります。まず実際の問い合わせを選び、担当者が回答するときに開いた資料をたどります。見つかった資料について、該当箇所、適用対象、改定状況、更新担当を比べます。
例えば製品資料と営業担当者のメモで条件が異なるなら、文書名や作成者だけで正本を推測しません。担当部署に「どの条件を、どの対象に適用するか」を確認し、決まるまではその条件についてGPTに確定的な回答をさせない設計にします。確認後は、正本に沿って回答できる質問、追加の条件を聞けば回答できる質問、個別判断が必要な質問に分けます。
資料に必要な条件そのものが書かれていない場合は、GPTの指示で空白を埋めようとせず、資料を整えるか、その質問を回答範囲から外します。正本と更新担当が決まったら、試験に使う質問ごとに根拠の箇所を対応させます。担当者がその箇所をたどれない資料は、登録前に構成や記載を見直します。
資料の整理では、文書全体を採用するかどうかだけでなく、質問に必要な箇所を特定できるかを確認します。同じ条件が別の資料にも書かれているなら、どちらを更新するか、記載が食い違ったとき誰に確認するかを決めます。この対応が決まらない間は、資料を増やす前に管理方法を整えます。
目的を小さな業務単位に絞る
対象業務は、問い合わせの種類、利用者、参照資料、回答を確定する担当者を特定できる範囲で選びます。社内FAQでも、規程の記載を案内する質問と、個別事情への適用判断が必要な質問では、GPTに求める動作が異なります。
試す業務を比べるときは、それぞれについて正本、回答に必要な条件、保留時の案内先を書き出します。いずれも示せる業務から試験運用へ進みます。正本が決まらない業務は資料の整理へ、案内先が決まらない業務は担当部署と判断手順の整理へ戻します。
試した質問ごとに、根拠を示した回答、条件不足の聞き返し、担当者への引き継ぎのどれができたかを記録します。結果は単に「正解」「不正解」とせず、期待した動作、実際の動作、根拠の有無、担当者が取った対応を残します。そうすれば、正しい説明を含みながら必要な聞き返しを省いた回答も見つけられます。
誤りは資料や指示の該当箇所を直し、同じ質問で改善を確認してから対象を広げます。根拠が見つからない質問は回答範囲に含めず、担当者が確認します。よくある質問でも例外条件によって判断者が変わるなら、その例外を試験質問に加えてから共有を検討します。
用途別に見るカスタムGPTsの設計
カスタムGPTsの設計は、機能を選ぶ前に、業務上の質問と回答に必要な情報を洗い出すところから始めます。用途ごとに対象者、参照資料、回答範囲、引き継ぎ先を決め、その組み合わせで実際の質問を扱えるか確認します。複数の用途を一つにまとめる場合も、資料の優先順位や回答基準が食い違わないかを先に比べます。
営業FAQと商談準備
営業FAQでは、質問を「資料に答えがある」「条件を聞けば資料で判断できる」「個別判断が必要」に分けます。最初の質問には参照箇所を示した回答案を作り、条件が不足する質問には必要な情報を聞き返します。個別見積もりや契約条件は担当者へ回します。
例えば「この条件で利用できるか」という質問なら、先に資料で適用条件を確認します。質問から適用対象を特定できなければ、その対象を聞き返します。対象が分かっても例外の承認が必要なら、GPTは資料の記載と未確認の条件を分けて示し、担当者の判断につなぎます。テストでは、同じテーマについて条件が揃った質問と欠けた質問を比べると、聞き返しの指示が働くか確認できます。
商談準備では、顧客情報や過去のやり取りから確認事項の案を作れます。まず入力した記録と対象顧客が一致するかを見ます。次に、要約に含まれない重要な経緯や、記録にない断定がないかを原情報と比べます。対象顧客が違えば対象の特定方法を直し、経緯が抜けていれば参照する記録を確認します。提案に使う事実、顧客への約束、商談方針は担当者が確定します。
確認事項の案を評価するときは、「記録にある未解決事項を拾えているか」と「記録にない課題を顧客の事実として扱っていないか」を別々に見ます。後者が起きた場合は、推測を確認事項として表すよう指示を直し、元の記録と照合してから使います。
社内問い合わせ
人事、総務、ITなどの定型問い合わせでは、社内規程や手順書を参照資料として使えます。回答には参照元を添え、資料に記載のない質問は担当部署へ案内します。質問の文面が似ていても、対象者や状況によって扱いが変わるなら、回答前に必要な条件を聞き返すようにします。
運用前には、正本、更新担当、誤りの連絡先を決めます。規程の変更を把握したら、変更箇所を根拠にしていた質問を洗い出し、その回答を確認対象にします。資料を差し替えた後は、従来どおり案内できる質問と、変更によって扱いが変わった質問を比べます。個別事情への適用を担当部署へ引き継げることまで確認してから、利用者を広げます。
問い合わせの分類に迷う場合は、規程の文面をそのまま案内できる質問か、質問者の事情を当てはめる必要がある質問かで分けます。後者について担当部署への案内文を用意しておけば、GPTが回答を保留した後も、利用者は次に何を伝えればよいか分かります。
データ分析と提案書の下書き
表形式のデータを使った分析補助では、対象の列、集計の考え方、空欄や重複の扱い、出力形式を指定します。集計結果を見るときは、元データの対象範囲と除外した行を確認し、同じ条件で原データをたどれるかを確かめます。
条件を変えて比較する場合は、変えた条件と、そのために対象から外れたデータを明示します。含めた行を判断できない結果は採用せず、元データと集計条件を確認してから作り直します。経営上の解釈は担当者が行います。
たとえば空欄を「対象外」とするか「未入力」として確認するかで、結果の読み方が変わります。集計前にその扱いを決め、出力には採用した条件を添えます。比較するときは条件をそろえ、条件を変更した結果は別の結果として扱います。数値の整合が取れても、分類の意味が業務上の定義と違えば、元データの項目定義へ戻ります。
提案書の下書きでは、読み手、課題、提案の骨子、使用してよい資料を指定します。確認時には、原資料にある事実、そこから整理した課題、これから判断する提案内容を分けます。数値、顧客名、費用、契約条件を原資料と照合し、入力にない実績や約束が加わっていたら修正します。事実を照合できてから、提案の妥当性を担当者が判断します。
| 用途 | 参照資料や入力 | 回答ルール | 人が確定する内容 |
|---|---|---|---|
| 営業FAQ | 製品資料、FAQ | 資料の範囲で回答し、不明点を示す | 顧客への正式回答 |
| 社内問い合わせ | 規程、業務手順 | 参照元と問い合わせ先を示す | 個別事情への適用 |
| データ分析 | 表データ、分析条件 | 集計条件と前提を明記する | 経営上の解釈 |
| 提案書の下書き | 顧客情報、提案資料 | 指定した構成で初稿を作る | 提案内容と条件 |
GPT Builderで用途を設定し、テストする
GPT Builderで設定する前に、扱いたい質問と期待する動作を用意します。答えを出してほしい質問だけでなく、聞き返してほしい質問、担当者へ引き継いでほしい質問も含めます。設定前後で同じ質問を使えば、指示や資料を変えた結果を比べられます。作成できる範囲は利用環境によって異なるため、自社の設定も確認します。
試験に使う質問は、利用者が実際に書く言葉に近づけます。資料の見出しをそのまま質問にすると根拠を見つけやすくても、現場の言い回しでは見つからない場合があります。意味が同じで表現が異なる質問も試し、参照箇所を示せるか確かめます。
役割と回答範囲を書く
最初に、誰が何のために使うGPTかを定義します。営業FAQ用なら「営業担当者が製品資料を確認し、顧客への回答案を作るための支援」といった役割です。そのうえで、回答に必要な条件、資料に根拠が見つからないときの応答、担当者へ引き継ぐ内容を書きます。
Instructionsには、質問の状態ごとの対応を記します。
- 資料に根拠がある質問 ── 該当箇所と回答案を示すよう指定します
- 適用対象を特定できない質問 ── 回答に必要な条件を聞き返すよう指定します
- 個別の費用や契約条件に関する質問 ── 資料に書かれた内容と未確認の条件を分け、担当者へ確認を促します
回答形式も「資料に書かれた内容」「不足している条件」「担当者の確認事項」に分けると、各ルールに沿っているか確認しやすくなります。
指示を書いたら、各ルールに対応する質問を試します。期待と違う回答が出た場合は、まず原資料に答えがあるかを確認します。答えがなければ資料や回答範囲を直します。答えがあるのに使われなければ、指示や資料の構成を見直します。条件不足でも断定した場合は、何を聞き返すべきかを明示して再テストします。
修正箇所を決める際は、質問と資料と出力を並べて確認します。資料に答えがあり、回答に反映されなかったなら、参照しやすい資料の構成か、指示の書き方を見直します。資料同士が矛盾しているなら、先に業務担当者が正本を決めます。出力だけを手直ししても次の質問で同じ問題が起こるため、原因に対応する設定を直します。
| 指示に含める項目 | 記述する内容 |
|---|---|
| 役割 | 誰のどの作業を支援するか |
| 根拠 | どの資料を優先して参照するか |
| 回答形式 | 要約、箇条書き、確認事項など |
| 回答できない条件 | 資料に記載がない場合や条件が不足している場合 |
| 引き継ぎ先 | 担当部署や人に確認すべき問い合わせ |
| 禁止事項 | 推測、条件の確約、未確認情報の追加など |
| 禁止事項 | 競合製品を批判せず、中立的に説明する。 |
Knowledgeに登録する資料を整える
Knowledgeに登録する資料は、用途に関係する文書から選びます。同じテーマの資料が複数ある場合は、タイトルだけで選ばず、該当箇所、適用対象、改定状況を照合して正本を決めます。旧版や重複を整理したうえで、担当者自身が質問に対応する記載を見つけられるか確かめます。
登録前には、実際の質問ごとに「答えが書かれた箇所」「回答に必要な追加条件」「資料に答えがない場合の案内先」を対応させます。該当箇所が見つからなければ資料を整えるか、回答範囲から外します。資料間で記載が矛盾するなら、GPTに優先順位を推測させず、業務担当者が正本を決めます。
登録後も、正本が変わったら更新担当が資料と関連するテスト質問を見直します。変更箇所に関係する質問で、新しい記載に沿った回答または適切な保留ができることを確認します。変更に追随できない情報は、最新の回答を求める用途に含めず、確認先を示します。
資料の差し替え後は、変更した条件を問う質問に加え、変更の影響を受けない質問も試します。前者で新しい記載に沿うこと、後者で従来の案内が崩れていないことを確認できれば、その資料を使う範囲の再開を判断できます。
実際の質問でプレビューを試す
プレビューでは、質問ごとに期待する動作を先に書き、出力と比べます。資料に答えがある質問では、回答文だけでなく参照箇所を確認します。条件が足りない質問では、必要な条件を聞き返すかを見ます。個別判断が必要な質問では、誰へ何を引き継ぐかが伝わるかを確認します。
- 資料に明記された質問に、根拠に沿って回答するか
- 資料にない質問で、事実を補ってしまわないか
- 質問が曖昧なとき、必要な条件を聞き返すか
- 個別判断が必要な内容を、担当者に引き継ぐか
- 指定した形式や口調を守るか
確認結果には、質問、期待した動作、実際の回答、参照すべき資料、修正した箇所を対応させて残します。判定では、結論だけでなく、根拠をたどれるか、不足する条件を正しく挙げたか、担当者が次の対応を取れるかを見ます。引き継ぎを求める質問で正しい一般論を述べても、担当者への案内が欠けていれば期待した動作には達していません。
修正後は失敗した質問を再度試し、別の質問への回答も崩れていないかを見ます。根拠を示す回答、聞き返し、引き継ぎのいずれかが不安定なら、その質問を利用範囲から外すか、設定を見直してから運用へ進みます。
Actions連携は読み取りから業務フローに加える
Actionsは、カスタムGPTsから外部サービスのAPIを呼び出すための仕組みです。外部の情報が必要な用途では、取得する情報だけでなく、対象をどう特定するか、取得結果を誰が確認するか、確認後に何を判断するかを決めます。参照資料だけで質問に対応できるなら、その用途にActionsが必要かを先に見極めます。
Actionsで実現する範囲を定める
CRMから取引状況を参照して商談準備を支援するなら、質問に対応する顧客を特定し、必要な情報を取得して、担当者向けに要点を整理する流れが考えられます。同名の顧客がいるなど対象を特定できない場合は、推測して進めず、担当者に確認を求めます。
設計時には、質問に必要な情報を「登録済みの資料で足りるもの」「CRMから取得する必要があるもの」「取得できても担当者の判断が必要なもの」に分けます。CRMから取得する場合は、対象レコードの特定方法と、照合に使う項目を先に決めます。取得結果には担当者が原情報へ戻るための手がかりを残し、対象を取り違えたまま整った要約を作らないようにします。
Actionsの設定に必要な認証情報やOpenAPIスキーマなどは、Configuring actions in GPTsを参照し、自社の設定画面と接続先の条件を確認します。接続できた後は、想定した対象が取得されるか、必要な項目が揃うか、担当者が原情報と照合できるかを別々に確かめます。
ほかの接続先と組み合わせる場合は、次のとおりです。
- タスク管理ツール ── 参照したいタスクを先に特定し、作成まで扱うなら登録先、入力項目、実行前の確認者を決め、登録後に元のツールで結果を読み返せることを確かめます
- カレンダー ── 対象者や対象期間を特定し、取得した予定を元のカレンダーと照合します（Googleカレンダーを接続先として検討する場合も、自社の接続設定と閲覧権限を確認してから試します）
- 会計ソフト ── 対象の取引や期間、閲覧してよい項目を業務担当者と決め、取得結果だけで経費精算などの状態を確定せず、元の記録と照合できる範囲で利用します
- メール ── メールから業務に必要な情報を参照する用途を対象に含めます
参照から更新へ段階を分ける
最初は検索や参照に範囲を絞り、対象レコード、取得項目、要約の順に確認します。対象が違えば、要約を評価する前に検索条件を直します。対象は合っていても必要な項目が欠けるなら、取得範囲や権限を確認します。項目が揃って初めて、要約が原情報と一致するかを見ます。
例えば商談準備で取引の状況を尋ねた際、同名の会社が複数見つかったなら、会社を選ぶための情報を担当者に求めます。会社を特定できても、必要な取引記録が取得できなければ、要約で不足を補いません。対象と必要な記録が揃い、担当者が原情報へ戻って照合できる場合に、対応案の下書きへ進めます。
更新が必要になったら、対象の特定方法、変更してよい項目、実行条件、確認者を先に決めます。実行前には、対象を識別する情報、元の値、変更後の値、変更理由を並べ、承認内容と照合します。いずれかが一致しない場合は実行せず、確認者に戻します。実行後は元のシステムで対象レコードと変更結果を読み返し、一致を確認できるまで完了と扱いません。
誤操作への備えは、連絡先だけでなく対応の順序まで決めます。誤りを見つけた担当者が対象レコードと操作内容を伝え、権限を持つ担当者が原記録と変更履歴を確認し、訂正方法を判断する流れです。変更前の状態を確認できない、訂正の担当者が決まらない、または実行結果を読み返せない場合は、更新機能を加えず、参照と下書きの範囲で運用します。
| 段階 | GPTが行うこと | 次へ進む判断 |
|---|---|---|
| 参照 | CRMや社内DBから情報を取得する | 対象と取得項目が意図どおりに表示される |
| 下書き | 取得内容を要約し、対応案を作る | 担当者が原情報と照合できる |
| 更新候補 | 更新内容を示し、実行前に確認する | 権限と承認手順が定義されている |
| 更新 | 承認された操作をAPI経由で実行する | 変更履歴と誤操作時の対応を確認できる |
HubSpot上の情報とつなぐ
HubSpotを利用する場合は、コンタクトや会社、取引、活動履歴などから、質問に必要な情報を選びます。まず担当者が普段どの画面や記録を根拠に判断しているかを確認します。その情報がGPTの支援にも必要なら、対象レコードの特定方法と取得項目を決めます。CRMへの入力が不足していれば、要約や提案の前に記録を整えます。
営業活動では、コンタクトの情報を整理し、取引の進捗を管理し、受注後の顧客対応や請求に必要な情報へ引き継ぎます。カスタムGPTsは、その流れの中で検索、要約、下書きを支援します。営業プロセスや取引ステージの定義は人が設計し、GPTの出力をきっかけに変更を検討する場合も、担当者が根拠を確認します。
商談準備に必要な項目と、顧客への回答を確定するために担当者が確認する項目は分けて考えます。取得した記録の一部だけでは判断できないなら、GPTは不足する記録を示します。確定した対応は、担当者が定められた記録先に残し、次の担当者が経緯を追えるようにします。
HubSpotのAI機能であるBreezeとの役割も、扱う情報と作業の場所から整理します。CRM上の情報を使う作業はHubSpot側の機能を確認し、CRM外の資料や業務知識を使う作業はカスタムGPTsでの支援を検討します。いずれも、出力を確認する人と、確定した情報の保存先を決めてから使います。
組織で共有するときの運用設計
個人で試す段階と組織で共有する段階では、質問する人と扱う情報の範囲が変わります。試用中に適切な回答が出ても、新たな利用者が別の規程や顧客情報について尋ねる可能性があります。共有範囲、業務オーナー、資料の更新担当、誤りの連絡先を決め、質問の種類が変わったときに見直せる状態にします。
アクセス範囲と責任者を決める
社内向けGPTでは、利用できる人と参照させる資料の組み合わせを確認します。資料に含まれる情報を、その利用者へ案内してよいかは業務オーナーが判断します。想定外の質問や個別事情への判断が必要な質問を受けた場合の案内先も明示します。
共有前には、試験運用で扱った質問と、新たな利用者が尋ねそうな質問を比べます。新しい質問に別の正本や閲覧範囲が必要なら、共有範囲を広げる前に資料と権限を確認します。案内してよい範囲を決められない情報は回答対象から外し、担当部署への確認方法を示します。
GPTごとに業務オーナーと資料の更新担当を置き、指示、参照資料、テスト質問、変更履歴を引き継げる形で残します。担当者が変わっても、どの質問を回答し、どの条件で保留するかを確認できるようにします。
利用状況と回答品質を見直す
継続の判断には、実際の質問と回答を使います。問い合わせ対応なら、次の質問や回答を記録します。
- 担当者が修正した回答
- 資料が不足した質問
- 引き継ぎ先が適切でなかった質問
顧客向けの下書きなら、含まれた事実や条件を原資料と照合できたかも確認します。
記録を見直すときは、同じ原因による失敗が別の表現の質問にも出ていないかを確かめます。たとえば条件不足の質問で断定したなら、その条件を含まない別の質問も試します。引き継ぎ先が違ったなら、どの質問の種類で案内先が変わるかを業務担当者と整理します。
誤りを見つけたら、まず影響する質問の利用を保留し、原因に応じて直す場所を分けます。
- 資料に答えがない ── 正本や回答範囲を見直します
- 資料に答えがあるのに使われない ── 指示や資料の構成を点検します
- 対象を取り違えた ── 回答文を整える前に対象の特定方法を直します
- 条件不足のまま答えた ── 聞き返す条件を明確にします
利用が進まない場合も、使い方が伝わっていないのか、扱える質問が少ないのか、資料が不足しているのかを分けて確認します。原因に応じて修正した後、同じ質問で動作を確かめ、別の質問への影響も見てから運用範囲を判断します。
小さく試して広げる
試験運用では対象業務と利用者を絞り、よくある質問と例外質問の両方を集めます。回答ルールや資料を修正した後、根拠を示す回答、条件不足の聞き返し、担当者への引き継ぎが期待どおりにできるか確認します。
利用範囲を広げる前には、新たな利用者が資料を参照してよいか、質問の判断者は同じか、誤りを伝える窓口を案内できるかを確かめます。新しい部署で正本や判断者が変わるなら、その部署の質問を使って改めて試します。共有後も、資料の改定や新しい種類の質問が見つかった時点で、影響する回答を見直します。
共有の判断は、試験した質問への回答だけで行いません。新しい利用者が問い合わせを受けたときに、根拠を確認でき、保留した質問を担当部署へ渡せるかまで確かめます。その手順を実行できない場合は、利用者を広げる前に案内方法を整えます。
作成や共有の範囲はアカウントとワークスペースの設定に左右されるため、導入時には自社の設定画面とSharing and publishing GPTsを確認します。利用できる範囲を確かめたうえで、資料へのアクセス範囲と試験運用の対象者を合わせて決めます。
カスタムGPTsの限界と見直し方
カスタムGPTsは、参照資料や指示があっても誤った内容を出す可能性があります。資料を更新しないまま使えば、古い情報に基づく回答も起こり得ます。業務で使う際は、誤りを見つけた人が誰へ伝え、どの質問の利用を保留し、何を確認できたら再開するかまで決めます。
重要な回答は人が確定する
次のような内容は、担当者が原資料を確認して確定します。
- 価格
- 契約条件
- 顧客への約束
- 社内規程の個別適用
GPTが参照元を示せない、必要な条件が揃わない、複数の資料が食い違う場合は回答を保留します。
保留した質問については、欠けている条件、確認する担当者、判断の根拠にする資料を記録します。担当者の確認で条件が確定したら、その質問を今後もGPTの回答範囲に含めるか判断します。含めるなら正本や回答ルールの更新担当へつなぎ、含めないなら引き継ぎ先を明示します。同じ質問が再び来たときに、担当者だけが経緯を知っている状態を避けます。
最新情報が必要な場合は参照元を整える
情報が変わったときは、まず影響する質問を探します。Knowledgeを使うなら、正本の変更に合わせて資料を見直し、影響する質問を再テストします。Actionsで参照するなら、取得した情報の対象と内容を原情報に照らして確認します。
どちらを使うかは、情報の置き場所と更新手順で判断します。管理された資料を根拠に案内するなら、その資料を誰が差し替えるかを決めます。接続先の記録を参照するなら、対象をどう特定し、取得結果を誰が照合するかを決めます。両方の情報を使う質問では、記載が食い違ったときの確認者も必要です。
更新担当を定められない場合は、まず資料の管理方法を決めます。取得結果を照合できない場合は、対象の特定方法と原情報への戻り方を見直します。それまでは該当する情報を確定的な回答の対象から外し、担当窓口を案内します。影響を受けた質問で期待どおりに回答または保留できることを確認してから利用を再開します。
再開時には、変更した記載を直接問う質問と、変更前後で扱いが変わる質問を使います。前者で新しい根拠を示せても、後者で古い条件を案内するなら再開せず、資料と指示の関係を見直します。
複雑な承認や分岐は専用の業務設計と組み合わせる
複数の承認や例外がある業務では、GPTが作る案と、実際に承認された内容を区別します。GPTには必要情報の整理や申請文の下書きを任せ、承認者、実行条件、結果の記録先は業務手順に沿って定めます。例外時の判断者が決まっていなければ、処理を進めず人へ引き継ぎます。
承認後の作業にGPTの出力を使う場合は、承認記録と下書きの対象、条件、実行内容を照合します。内容が異なるなら下書きに沿って処理せず、承認者へ確認します。誰が確定し、どこに結果を残すかが明確になってから、その部分を業務フローに組み込みます。
よくある質問
カスタムGPTsはどの業務から試すとよいですか？
回答の根拠になる正本があり、利用者と回答範囲を限定できる業務から始めます。社内FAQなら、資料で案内できる質問、条件を聞けば案内できる質問、個別判断が必要な質問に分けます。正本、更新担当、引き継ぎ先を決め、それぞれに回答・聞き返し・引き継ぎができることを確認してから利用者を広げます。
Knowledgeに入れる資料は多いほどよいですか？
資料の数より、質問に対応する正本を特定できることが大切です。旧版や重複資料があれば該当箇所を照合し、更新担当を決めてから登録します。登録後は、実際の質問で参照箇所を確認します。資料に答えがない質問は推測で補わせず、資料を整えるか回答範囲から外します。
Actionsで顧客情報を更新できますか？
利用できる操作は、設定したAPIやスキーマ、接続先とワークスペースの条件によります。まず参照で対象を正しく特定し、取得した項目を原情報と照合できるかを確認します。更新を検討する場合は、変更項目、元の値と変更後の値、実行前の確認者、実行後の読み返し、誤操作時の対応を決めます。対象や変更内容を確認できない間は、参照と下書きの範囲にとどめます。
GPTの回答をそのまま顧客に送ってもよいですか？
送信前に担当者が根拠と内容を確認します。特に価格、契約条件、機能の提供範囲は原資料や社内で確定した内容と照合します。根拠が見つからない点や条件が不足する点は、確認が済むまで回答を保留します。確認後は担当者が送信内容を確定し、必要な対応履歴を定められた場所に残します。
よくある質問
Q1. カスタムGPTsは無料プランでも作れますか？
作成できる範囲は、利用中のプランやワークスペースの設定によって確認します。まず自社アカウントの作成画面で利用可能な操作を確かめ、組織で共有する場合は管理者に共有範囲も確認してください。作成できない場合は、必要な用途と利用者を整理してから、利用条件を確認します。
Q2. KnowledgeにアップロードしたデータはOpenAIの学習に使われますか？
データの扱いを、プラン名だけで判断せず、利用するアカウントの設定と適用される条件で確認してください。OpenAIの利用規約を確認する際は、自社が利用するサービスに適用されるかを確かめます。社内資料を登録する前に、業務オーナーが資料の内容と利用者の範囲を確認し、判断できない資料は登録を保留します。
Q3. 1つのカスタムGPTsにアップロードできるファイル数と容量の上限は？
上限や扱えるファイル形式は、利用時点の製品案内と自社の設定画面で確認してください。資料を選ぶ際は、上限まで登録することを目標にせず、質問に必要な正本を特定します。登録後、実際の質問で該当箇所を参照できなければ、資料の構成や回答範囲を見直します。
Q4. Actions連携にプログラミングスキルは必要ですか？
接続先のAPI、認証、扱うデータ、操作内容を理解できる担当者が必要です。設定方法はConfiguring actions in GPTsで確認し、まず読み取り対象を特定して取得結果を原情報と照合します。Zapier AI Actionsなどの連携手段を検討する場合も、利用できる操作と実行権限を確認し、更新を伴う操作は承認手順と結果の読み返し方を決めてから試します。
Q5. カスタムGPTsの応答精度を上げるコツは？
期待と違う回答を、次の状態に分けて確認します。
- 根拠が見つからない
- 条件不足でも断定する
- 対象を取り違える
- 担当者への引き継ぎができない
資料に答えがなければ正本や回答範囲を見直し、答えがあるのに使われなければInstructionsや資料の構成を点検します。修正後は失敗した質問で再テストし、別の質問への回答も確認してから利用範囲を広げます。
まとめ
カスタムGPTsを業務で使うときは、対象となる質問を選び、資料の正本、GPTが作る出力、人が確定する内容を順に決めます。次に、答えがある質問だけでなく、答えがない質問や条件が足りない質問でも試します。根拠を示す回答、聞き返し、担当者への引き継ぎを確認できた範囲から利用します。
ActionsやHubSpot上の情報を使う場合は、参照対象、取得項目、要約の順に原情報と照合します。対象を特定できなければ検索条件を見直し、必要な項目が欠けていれば取得範囲を確認します。更新が必要なら、実行前の確認、実行後の読み返し、誤操作時の対応を決めてから次へ進みます。
- 対象業務と、AIに任せる作業、人が確定する内容を決めます。
- 参照資料の正本、更新担当、回答できない場合の案内先を整理します。
- 答えがある質問、条件が足りない質問、個別判断が必要な質問でテストします。
- 誤りの原因に応じて資料や指示を修正し、同じ質問と別の質問で確かめます。
- 新たな利用者のアクセス範囲と判断者を確認してから、利用範囲を広げます。
企業様によって最適な形は異なります。まずは対象業務で使う資料と判断者を確認し、試験運用で見つかった不足を直しながら設計してください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。対象業務の選び方、参照資料と顧客情報の整理、回答を確定する担当者の決め方からご相談いただけます。
あわせて読みたい
業務に使う資料の整え方や、AIの出力を人が確認する手順をさらに検討する際は、次の記事も参照してください。画面録画から手順書を整える方法、音声入力を業務へ取り入れる際の比較、Microsoft Copilot for 365の活用を、それぞれの用途から確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
