カスタマーサポート向けに自社データでGPTを学習させる方法

まず、「学習」が実際に意味すること

ここ数年、私はAIエージェントを実際のサポートキューに導入する仕事をしてきましたが、最もコストの大きい誤解は「学習(train)」という言葉です。この言葉を聞くと、ドキュメントを与え続けてモデルに新しい事実を「覚えさせる」ことを想像する人が多いのですが、サポートに関してはほぼ間違ったイメージです。

自社データをGPTに組み込む方法は実際には3種類あり、それぞれ全く異なる役割を果たします。

ファインチューニングは、あなたの例を使ってモデルの重みを調整します。得意なことは1つだけで、社独自のスタイルや厳格な出力フォーマットを教えることです。事実を教えるのは苦手です。返金ポリシーでファインチューニングした後に翌週ポリシーを変更しても、モデルは古いポリシーを繰り返します。事実がすでに重みに焼き付いているからです。これは事前学習(pre-training)で直面するのと同じ制約です。学習した瞬間の知識で凍結されてしまうのです。常に変化するサポートナレッジベースにとって、これは致命的です。

カスタムGPTやOpenAIのAssistantsは、数個のファイルをアップロードするだけでその上にチャットボットを作れます。個人アシスタントや小規模な社内FAQには最適です。しかし実際のキューでは破綻します。ファイル数の上限、ライブなヘルプデスクとの接続不可、解決済みチケットから学習できない、答えが見つからないときの挙動を制御できない、といった問題があるからです。これはデモであり、本番運用ではありません。このエコシステムに興味があるなら、新しいapps in ChatGPTも同じ方向性を押し進めていますし、同様の方法でカスタムペルソナを作る人たちもいます。

**検索(RAG)**は、データをモデルの外に置いたまま回答時に検索します。モデルは何も記憶しません。質問が来ると、システムがドキュメントとチケットを検索し、最も関連性の高い該当箇所を取り出して、「この内容だけを使って回答せよ」という指示とともにGPTに渡します。ヘルプ記事を編集すれば、次の回答に即座に反映されます。サポートにおいてはこれが本命であり、このガイドの以降の内容もこれを前提にしています。

さらに詳しい理論を知りたい方には、RAG vs LLMの詳細解説や、より技術的なベクターデータベースとハイブリッド検索についての記事もあります。このガイドとしては、一言でまとめると十分です。あなたはGPTに自社データを教えているのではなく、優秀な司書を与えているのです。

「自社データ」に含まれるもの

2つ目の誤解は、「自社データ」とはヘルプセンターのPDFを指すと考えてしまうことです。実際にはもっと豊かなものであり、より豊かなソースこそがAIを「本当にその会社で働いているように」聞こえさせるものです。

最も優れた学習データには通常、次のものが含まれます。

• ヘルプセンターと公開ドキュメント。 最も分かりやすく、接続も最も簡単です。
• 過去の解決済みチケット。 これが隠れた武器です。解決済みチケットには、チームが実際にどう答えを表現するか、ドキュメントには載っていないエッジケース、顧客が反応するトーンが記録されています。ヘルプセンターがAIに公式見解を教えるなら、解決済みチケットは実際の「声」を教えます。
• 保存済みマクロや定型返信。 チームがすでに信頼している事前作成済みの回答です。
• Notion、Confluence、Google Driveの社内ナレッジ。 公開記事にはならなかった情報です。
• 商品や注文データ。 これにより、AIは「注文はどこですか」に対してはぐらかさずに答えられます。
• Slackのようなチームチャット。 多くの暗黙知が静かに眠っている場所です。

ある商談が印象に残っています。ある公共部門向けITサービス企業のサポートリーダーは、その年ベテランエージェント2名を失うことになっており、彼が本当に望んでいたのは、彼らが去る前にその暗黙知をAIに取り込むことでした。これこそが自社データで学習させる本当のユースケースです。単なる問い合わせの削減ではなく、それを保持していた人がいなくなった後も残り続けるナレッジマネジメントなのです。これらのソースを多く接続するほど、AIが推測する必要は減り、それはAIを活用したナレッジベースが有用であり続けるための基盤でもあります。

検索が実際にどう機能するか

これはツールが裏側で隠してしまう部分であっても、理解しておく価値があります。なぜなら、これがドキュメントを引用するAIと、自信満々にでたらめを言うAIとの分かれ目だからです。

質問が届くと、4つのことが起こります。まず、システムは質問を受け取り、接続済みのソースを検索します。インターネット全体ではなく、あなたのドキュメントとチケットだけです。次に、答えを含んでいる可能性が最も高い該当箇所を数件、絞り込んで抽出します。3番目に、それらの該当箇所をGPTに渡し、「この内容だけを使って回答し、ここにない場合はわからないと言え」という厳格な指示を与えます。4番目に、ソースへの引用付きで回答を返します。

その3番目のステップこそが全てです。ある商談では、ハードウェア企業の技術評価担当者がまさにこの点を執拗に確認してきました。彼はAIがモデルの一般的な学習データではなく、承認済みのナレッジからのみ回答することの保証を求め、それを完全にオフにできるかどうかも尋ねてきました。答えはイエスであり、それがデフォルトであるべきです。自社ソースからしか話せないAIは、返金ポリシーを勝手に作り出すことができないAIです。根拠に基づいた回答が生のモデルよりも優れている理由の理論を知りたい方はRAGについての記事で解説しており、ルールベースチャットボットとの比較では、古い決定木型ボットがこれらを一切実現できない理由を説明しています。

自社データでGPTを学習させる手順

ここからは実践的な手順です。OpenAI APIで自前で組み立てる場合でも、それを代行してくれるプラットフォームを使う場合でも、実際にどう進めるかを説明します。

1. ソースをエクスポートせず、接続する。 システムをライブなヘルプデスク、ヘルプセンター、ドキュメントに直接向けて、常に同期された状態を保ちましょう。一度きりのエクスポートは、作成したその日から古くなります。すでにZendesk、Freshdesk、Gorgiasに対応済みのツールを使えば、この部分だけで何週間分もの接続作業を節約できます。
2. 解決済みチケットを含める。 これを省くと、ドキュメントは知っているがニュアンスは何も知らないボットになってしまいます。過去の履歴を読み込ませることで、一般的な回答がチームらしい回答に変わります。
3. ガードレールとなる指示を書く。 取得したソースからのみ回答すること、不明な場合はエスカレーションすること、どのようなトーンで話すかを指定します。これはファインチューニングが実際に得意とするトーンの部分ですが、ここでは学習の実行の代わりに一文で済みます。
4. 信頼度のしきい値を設定する。 それを下回った場合、AIは人間向けに下書きするか、推測せずに引き継ぐようにします。この1つの設定こそが、役に立つエージェントと高くつく負債との分かれ目です。
5. 本番投入前に実際のチケットでテストする。 過去数百件のチケットに対して実行し、AIが何と答えていたかを確認します。ここは絶対に省略しないでください。
6. 修正して再テストする。 すべての修正が次の回答をより良くするはずです。優れたシステムは、あなたの修正から自動的に学習します。

eeselを使えば、この作業の多くが平易な言葉に集約されます。チャットウィンドウでエージェントにどう振る舞うべきかを伝えるだけで、設定ファイルの編集や再学習ジョブなしに、自らの指示を更新してくれます。

そのスクリーンショットのワークフロールールに注目してください。「利用可能なドキュメントから取得した情報のみを使って質問に答えなければならない。自分自身の一般知識を使ってはならない」。この一文こそが、私が繰り返し語ってきたグラウンディングであり、サポートマネージャーが実際に書きそうな表現で書かれています。特定のスタックでこれを設定したい場合は、AIサポートエージェントの学習や、それが自分の環境ならZoho Desk Ziaの手順もあります。

この方法で行う最大の利点は、ノーコードのセットアップによって運用を続けるためにエンジニアが不要になることであり、一般的なボットの学習がサポートリーダー自身で管理できるものになることです。

精度を静かに損なうミス

「AIがハルシネーションを起こしている」という不満のほとんどは、モデルの問題ではありません。データの問題です。その大半は次の3つのパターンで発生します。

ドキュメントの対象読者が間違っている。 以前、あるサポートマネージャーと仕事をした際、彼のナレッジベース全体が管理者向けに書かれている一方で、実際のチケットはエンドユーザーから来ていました。AIは律儀に管理者向けドキュメントを取得し、技術的には正しいものの、質問した本人にはまったく役に立たない回答を作り出していました。ゴミを入れれば、自信満々のゴミが出てきます。モデルを責める前に、まずソースを直しましょう。

ナレッジベース内の過度に広い表現。 あるチームのボットは、データベースに存在しないブランドの車種に対しても「はい、そのモデルに対応しています」と平然と答えていました。ヘルプ記事に「すべてのモデルに対応しています」と書かれていたからです。モデルは間違っていません。ドキュメントが間違っていたのです。検索は書かれている内容を忠実に表示するため、曖昧な断定は曖昧な断定の答えになります。

逃げ道がない。 AIに信頼度のしきい値も「わかりません」という選択肢もない場合、AIは沈黙を埋めようとします。それはモデルが無謀だからではなく、セットアップがAIに保留する許可を与えていないからです。サポートにおけるハルシネーションを防ぐことは、より賢いモデルを使うことではなく、大部分がグラウンディングとクリーンな引き継ぎの問題なのです。

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

これは、300件を超える記事を持つナレッジベースを抱える暗号資産ハードウェア企業のエンジニアリングリーダーが、自前で構築せず購入した理由を説明した言葉です。そして、いずれ誰もが行き着く疑問につながります。

自分で作るべきか、それとも購入すべきか

エンジニアがいるなら、OpenAIやClaudeのAPI上でこれを自分で構築することは可能です。実際にそうしているチームもあります。しかし「自社データでGPTを学習させる」は仕様書の上では一行でも、実際には途方もない量の配線作業を伴います。ヘルプデスクへのコネクタ、検索パイプライン、チャンク分割と再ランキング、権限モデル、信頼度システム、評価ハーネス、そしてその後永遠に続くメンテナンスです。

私はこれまで、技術力のある顧客が生のAPI上で自前構築するために離れていくのを何度も見てきましたし、その多くが戻ってくるのも見てきました。モデル自体は簡単な10%にすぎません。ヘルプデスク連携、チケット分類、グラウンディング、そして継続的なチューニングが残りの90%であり、そのどれもあなたの本来の製品ではありません。それが正直な自作か購入かの計算です。配線作業が本業でないなら、購入する価値があります。

実際に機能したかどうかを測定する

見ていないものは改善できません。ここが「AIを学習させた」が「AIがtier-1の40%を解決している」に変わる分岐点です。解決率と対応削減率、回答サンプルにおける事実的な正確さ、そして人間が介入せざるを得ない頻度といった、意味のある数値を追跡しましょう。

実際の数値は嘘をつきません。あるeコマース受信箱での実トラフィックのトライアルでは、学習済みエージェントが93%のトリアージ精度と100%のスパム検出率を達成し、88%の下書き精度を出しながらも、下書きの事実誤りは7%にとどまりました。トリアージ精度は高いのに事実面では実際の誤り率があるというこのギャップこそ、カテゴリーごとに測定し、リスクの高い部分では人間をループに残しておくべき理由です。一方、Gridwiseでは、eeselが導入から最初の1か月でtier-1リクエストの73%を解決しました。こうしたすべてを監視するツールは後付けするものではなく、最初から組み込まれているべきであり、それが実際のAIカスタマーサービス指標と希望的観測とを分けるものです。コストがあなたにとっての判断材料であれば、サポートコストの削減について別記事でまとめています。

自社データでeeselを試す

ここまでの内容がエンジニアリングの塊のように聞こえたなら、それがまさにポイントです。実際にその通りであり、それを取り除くためにeeselは存在します。ヘルプデスクとドキュメントを接続すれば、初日から過去のチケットとヘルプセンターから学習し、実際の顧客に見せる前に何千件もの過去チケットに対してシミュレーションモードで試すことができます。自社のソースからのみ回答し、不明な場合はエスカレーションし、Zendesk、Freshdesk、Gorgias、Slackなど、80以上の言語で動作します。

自分でGPTを組み立てるのとの違いは、グラウンディング、信頼度コントロール、レポート機能がすでに用意されている点です。従量課金制で、シート料金なしの1チケットあたり0.40ドルから始まり、料金の詳細を見るか、クレジットカード不要で50ドル分の利用枠付きで無料で試すこともできます。自社データで学習させ、実際のチケットで動く様子を確認し、数値が実証してから初めて自律性を高めていきましょう。