Geminiで用語集を作る手順：顧客に渡せる説明文に整える

結論

顧客向けの用語集をGeminiで作るなら、材料はドライブの資料とGmailに残った問い合わせです。顧客が実際に聞き返してきた言葉を拾い、自社のサービス仕様書に出てくる用例から定義を起こせば、社内で通じる言い方をそのまま並べた用語集にはなりません。20語ほどの規模なら、Googleドキュメントに書き出して社内レビューに回せる状態まで、目安として1時間ほどで進みます。

顧客向けの用語集が読まれない理由

社内で作った用語集が顧客に読まれないのは、説明が足りないからではなく、そもそも顧客がつまずいている言葉が載っていないからです。作る側は、自分が説明に困った言葉を思い出して並べます。顧客が困っているのは、こちらが当たり前に使っていて説明する発想すらない言葉のほうです。

この記事では、社員90名の物流サービス会社が、荷主向けのヘルプページに用語集を載せる場面を例にします。倉庫保管と配送を請け負っていて、荷主は中小の通信販売事業者が中心。問い合わせ窓口に届く質問の多くが、実は用語の行き違いから来ている、という状態からの出発です。

この会社で「締め」と言えば、当日出荷分の出荷指示を受け付ける最終時刻を指します。荷主の多くは請求の締め日と受け取ります。この一語の行き違いだけで、出荷が翌日にずれたという問い合わせが毎月発生していました。用語集に載せるべきなのは、こういう言葉です。

材料はドライブとGmailの中にある

用語の候補を会議室で出し合うと、思いつきの一覧ができます。実際に行き違いが起きた記録から拾うほうが確実です。

集めるのは、ドライブにあるサービス仕様書と料金表、荷主に渡している運用マニュアル、そして問い合わせ窓口に届いたメールです。メールは直近3か月分のうち、顧客が言葉の意味を聞き返しているもの、こちらの説明を誤解したまま話が進んだものを選びます。20通もあれば傾向は出ます。

散らばったまま読ませると、どの資料から起こした定義なのかを後で追えません。用語集用のフォルダを1つ作り、そこに資料を集めてから始めてください。荷主名や注文番号を渡してよいかは社内ルール次第です。判断がつかないときは社名をA社に置き換えます。行き違いの中身を読み取るのに、実名は要りません。

具体例1：問い合わせメールから、説明が必要な言葉を拾わせる

用語の一覧は、こちらが選ぶのではなく、顧客の困り方から逆算させます。

ドライブの「荷主向け用語集」フォルダにあるサービス仕様書と運用マニュアル、
および私が貼り付けた問い合わせメール20通を読んでください。

【やってほしいこと】
顧客が言葉の意味を取り違えた、または聞き返した箇所を探し、
原因になった言葉を抜き出してください。

【出力形式】
表にしてください。列は次の5つです。
・言葉
・顧客がどう受け取ったか
・当社が意図していた意味
・行き違いの結果として何が起きたか
・根拠になったメールの番号と、その一文

【条件】
・メールの中に行き違いの跡がない言葉は、この表に入れない
・同じ言葉で複数の行き違いがあれば、件数を書き添える
・原因が用語ではなく手続きの説明不足である場合は、別の一覧に分ける
・推測で補った箇所には、推測であると明記する

最後の条件が効きます。行き違いの原因は用語とは限らず、手続きそのものを説明していないだけのこともあります。分けて出させると、用語集で直すものと、ヘルプページの本文で直すものが仕分けされた状態で手元に届きます。

物流会社の例では、「締め」のほかに「一次保管」「入庫確定」「返品入庫」が挙がりました。社内では毎日使っていて、説明が必要だと思ったことがない言葉ばかりです。

業界用語の一般的な意味と、自社での意味を分けて書かせる

荷主向けの用語集には、業界では通用する言葉が並びます。そこで一般的な説明だけを載せると、自社の運用と食い違う箇所が残り、かえって問い合わせが増えます。2つに分けて書かせます。

先ほど選んだ12語について、定義を書いてください。
定義は、私が登録した資料に出てくる用例からだけ起こしてください。

【各用語の出力形式】
・言葉
・物流業界で一般に使われる意味 … 1文。当社の運用は入れない
・当社のサービスでの意味 … 2文以内
・一般的な意味との違い … 違いがある場合のみ、どこが違うかを1文で
・根拠 … 参照した資料名と、読み取りの元になった一文

【条件】
・当社での意味が資料から読み取れない語は、その欄を「用例なし」として空けておく
・一般的な意味の欄で確信が持てない語には「要確認」と書く
・料金、日数、時刻は、資料に書かれている場合のみ引用する。
  資料にない数値を書かない
・カッコを使った補足や英語の併記をしない

数値を勝手に書かせないという条件は外せません。顧客向けの用語集に誤った締め時刻が載ると、そのまま運用の食い違いに直結します。資料に時刻が書かれていない語は空欄で返させ、運用部門に確認して自分で埋めます。

根拠の欄を埋めさせておくと、社内レビューのときに「この定義はどこから来たのか」という質問が消えます。レビューする運用部門の担当者は、根拠に示された一文だけを読めば、定義が合っているかを判断できます。

同じ言葉を部署が違う意味で使っているとき

顧客向けの用語集を作る過程で、社内の意味のずれが表に出ます。物流会社の例では「返品」がそうでした。営業担当は、荷主の顧客から戻ってきた荷物全般を返品と呼びます。倉庫部門では、検品を通って在庫に戻せると判断されたものだけを返品と呼び、破損して戻せないものは別の扱いにしています。

このずれを抱えたまま用語集を公開すると、顧客は営業の説明と倉庫からの連絡が食い違う場面に出くわします。

この用語集の候補語について、社内で意味が分かれている疑いがあるものを探してください。

【探し方】
・同じ言葉が、営業部門が作った資料と倉庫部門が作った資料で、
  異なる対象を指していないか調べる
・顧客とのメールでの使われ方も照合する

【見つかった語の出力形式】
・言葉
・営業部門での指す範囲と、その用例
・倉庫部門での指す範囲と、その用例
・顧客がこの違いに出会う場面を1つ

【条件】
・どちらが正しいかを決めない。両方を並べて返す
・用例が片方にしかない語は、判断せずに確認事項として返す

出てきた語は、用語集に載せる前に社内で意味をそろえます。そろえる判断はGeminiにはできません。決まったら、用語集には決まったほうの意味だけを載せ、もう一方の使い方は社内向けの注意として別に残します。顧客向けの文書は、迷いのない1つの定義だけを見せるほうが役に立ちます。

読む人の知識に合わせて説明を2段階にする

荷主向けの用語集は、読み手の幅が広くなります。初めて物流を外部に委託する事業者と、複数の委託先を使い分けている事業者では、必要な説明の量が違います。

読み手	定義の長さ	添えるもの
委託が初めての荷主	60字以内	どの場面で目にするかと、関連する画面の名前
他社からの切り替え荷主	60字以内	他社で違う呼び方をしている可能性への注記
荷主の現場担当者	100字以内	実際の作業手順のどこに関わるか
荷主の経理担当者	60字以内	請求項目との対応

1つの用語集で全員に応えようとすると長くなります。短い定義を本体に置き、詳しい説明は折りたたむ構成にすると、どちらの読み手も止まりません。

確定した定義を、ヘルプページに載せる2段階の形式に整えてください。

【形式】
・1行目 … 60字以内の短い定義。これだけ読めば場面が分かる書き方にする
・2行目以降 … 詳しい説明。100字以内。手順や画面との対応を含める
・最後 … 関連する用語を2語まで

【条件】
・物流を委託した経験がない読み手を想定し、社内でしか通じない言い方を残さない
・根拠の欄は社内確認用に残し、公開版では外せるように別の行にする
・見出しは用語名だけにし、説明を見出しに入れない

顧客からの質問そのものを整理する作業は、GeminiでFAQを作る手順と合わせて進めると、用語集とFAQで説明が食い違わなくなります。

具体例2：Googleドキュメントに書き出してレビューを回す

定義がそろったら、会話の中に置いたままにせず文書に出します。GeminiにはGoogleドキュメントへ書き出す導線が用意されていて、書き出した後は共有とコメントでレビューを回せます。プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。

レビューを頼む相手は3者に分けます。運用部門の担当者には、定義が実際の作業と合っているかだけを見てもらいます。問い合わせ窓口の担当者には、この説明で問い合わせが減るかを見てもらいます。営業担当には、荷主に見せて差し支えない表現かを見てもらいます。見る観点を指定しないと、全員が文章の言い回しにコメントを付けて、肝心の中身が確認されません。

コメントが集まったら、修正は用語ごとに依頼します。全文を作り直させると、確認済みの定義まで書き換わります。

Googleドキュメントに書き出した用語集のうち、「入庫確定」の項目だけを直してください。

【運用部門からの指摘】
現在の定義では、検品が終わった時点で入庫確定としていますが、
実際には数量の照合が終わり、システムに在庫として反映された時点を指します。

【条件】
・この指摘を反映して定義を書き直す。他の用語には触れない
・短い定義と詳しい説明の両方を直す
・根拠の欄は「運用部門の指摘による修正」に書き換える
・文字数の上限は元のまま守る

書き出した後の見出しや表の整形には手作業が残ります。文書の体裁を整える手順はGeminiで書式を整える手順にまとめています。

うまくいかないときの対処

定義が一般的な説明にしかならない。 資料の中にその言葉の用例が足りていません。「この定義は、どの資料のどの一文から起こしましたか」と聞き返すと、根拠のない語が判別できます。用例のない語は、運用部門に一文書いてもらってから渡し直します。

社内でしか通じない言い方が定義文に残る。 読み手の条件を「当社の業務を一度も見たことがない人」と明示して書き直させます。それでも残るなら、残った言葉自体を用語集の項目として追加します。

用語が多すぎて後半が雑になる。 資料の単位で区切って進めます。仕様書から起こす回、メールから起こす回と分けると、根拠の追跡も楽になります。

公開後も同じ問い合わせが減らない。 用語集の場所が見つかっていないか、顧客が読む前に問い合わせています。問い合わせ窓口の返信に用語集の該当箇所を引用する運用にすると、次から読まれるようになります。

公開前に人が確認し、更新を止めない

Geminiの出力をそのまま公開しないことを、作業の手順に組み込みます。根拠に示された一文を資料と突き合わせ、数値と時刻は運用部門に確認する。この2つを通していない用語集は、顧客に誤った案内をする文書になります。

更新は、問い合わせの記録から起こすのが続きます。四半期ごとに、その間に届いた問い合わせメールだけを読ませ、「現在の用語集に載っていない言葉で、行き違いが起きたものを挙げてください」と頼みます。新しい用語を思いつきで足すより、実際に困った記録から足すほうが、載せる価値のある言葉が残ります。

サービスの仕様が変わったときは、変更前後の仕様書を両方読ませ、「この変更で定義を直す必要がある用語」を挙げさせます。用語集の全面改訂は誰も手を付けたがらないので、直す箇所を10語以内に絞って提示させるほうが、実際に更新されます。他のツールで同じ作業を進める手順は、ChatGPTで用語集を作る手順とClaudeで用語集を作る手順にまとめています。

まとめ

直近3か月の問い合わせメールから、顧客が言葉の意味を聞き返しているものを20通選んでください。そこに出てくる言葉が、用語集の最初の項目になります。ドライブに用語集用のフォルダを作って仕様書と運用マニュアルを置き、根拠を必ず書かせる条件を先に伝えてから定義を起こさせます。数値と時刻の欄は空けさせ、運用部門に確認して自分で埋める。Googleドキュメントに書き出したら、運用部門と問い合わせ窓口と営業に、それぞれ見る観点を指定してレビューを頼みます。