社内でしか通じない略語、自社の商品名、部署の呼び方。毎回説明するのは手間です。
かといって、モデルは会話をまたいで覚えてくれません。
覚えない理由
学習が終わった時点で、モデルの中身は固まっています。使いながら覚えていくわけではありません。
会話の中で教えたことは、その会話のあいだだけ有効です。新しい会話を始めれば消えます。対話画面が前のやりとりを覚えているように見えるのは、画面側が会話全体を毎回送り直しているからです。
記憶する機能を持つサービスもありますが、何を覚えたかを利用者が把握しにくい。業務で使うなら、明示的に渡す形のほうが確実でしょう。
用語集を作る
いちばん単純で、いちばん効く方法です。
用語、読み方、意味、使う場面。この4列で一覧を作り、指示の頭に貼る。それだけで、略語の解釈違いがほぼ消えます。
全部を入れる必要はありません。実際にその作業で出てくる語だけで足ります。20語もあれば、たいていの用は足りるはずです。
紛らわしい語から手を付けるのが効率的。一般的な意味と社内での意味が違うもの。「案件」「対応」「確認」のような普通の言葉が、社内では特定の工程を指していることがある。
入れてはいけないもの
用語集を作るとき、線を引いておく必要があります。
取引先の実名、顧客の情報、未公開の数字。これらは用語集に入れない。指示文は共有される場面が多く、そこに書いた社内の事情まで一緒に渡ることになります。
認証情報や社内の権限構造も同じです。システムプロンプトは秘密として扱うべきではない、というのが公開されている指針でもあります。
その文面がそのまま外に出ても困らないか。これが判断の目安になります。
資料を渡す形にする
用語が多い場合は、一覧を毎回貼るより資料として渡すほうが現実的です。
社内の用語集や手順書をファイルで渡し、それを見て答えさせる。量が増えたら、質問に関係する部分だけを探して渡す仕組みが要る。
仕組みを作るかどうかの目安は、文書が数百件を超えたあたり、あるいは同じ質問が繰り返し来るようになったあたりでしょう。それ以下なら、丸ごと渡したほうが早い。
誤解しやすい点
用語集を渡しても、完全には守られません。
特に、一般的な意味が強い語では引きずられます。「本部」を特定の部署の意味で定義しても、一般的な用法で使われることがある。
対処は、出力を確認する工程を残すことです。用語の解釈が正しいかは、成果物を読めば分かります。
それから、長い資料の真ん中に用語集を置かないこと。長い入力では中盤の扱いが弱くなるので、頭か末尾に置きます。
読み方も書いておく
見落とされやすいのが、読み方です。
音声で扱う場面や読み上げさせる場面では、読みが違うと使い物になりません。社名や製品名の読みは、一覧に入れておくと後で効きます。
人名も同様。同じ漢字でも読みが分かれる姓は多く、間違えると失礼にあたります。
部署ごとに分ける
全社共通の用語集を1つ作ろうとすると、たいてい膨らみすぎて使われません。
営業で使う語と、開発で使う語は違います。それぞれの現場で20語程度の一覧を持つほうが、実用的でしょう。
共通する語だけを別に切り出しておけば、組み合わせて使えます。
育てていく
最初から完璧な用語集は作れません。
使ってみて、解釈がずれた語を1つずつ足していく。数週間で実用的なものになります。
できあがった用語集は、新入社員への説明にも使えます。そもそも社内で言葉の定義が揃っていなかった、と気づくこともあるでしょう。
結局は資料を渡すのが早い
用語集を工夫するより、その用語が出てくる実際の文書を渡したほうが伝わる場面もあります。
過去の議事録、手順書、社内向けの説明資料。文脈ごと渡せば、語の使われ方まで一緒に伝わります。
ただし量が増えれば費用も上がり、長い入力では中盤が弱くなります。渡す資料は絞ったほうがよい。
用語集と資料を組み合わせる形が、現実的な落としどころでしょう。
言葉が揃っていない状態は、AIに限らず社内のやりとりでも摩擦を生んでいます。
用語集を作る作業そのものが、その整理になる。副産物のほうが価値を持つこともあります。
まずは20語から。それで足りるかを見てから増やせばよい。
出典
指示文に機密情報を置かない理由と、長い入力での扱いについては、下記に基づきます。
