生成AI導入で用語集が必要な理由
生成AIの導入会議では、同じ言葉を使っていても見ている範囲が違います。経営者の「自動化」は作業時間を減らすこと、現場担当者の「自動化」は下書きを作ること、開発担当者の「自動化」は人の操作なしで処理を完了することかもしれません。この差を残したまま製品や機能を選ぶと、試験後に「思っていたものと違う」という評価になります。
特に曖昧になりやすいのが「AIに任せる」という表現です。候補抽出、分類、要約、下書き、承認、送信は別の作業です。下書きだけを任せる計画でも、誰かが送信まで自動化されると受け取れば、安全性や費用の議論がかみ合いません。まず業務を分ける方法はAI導入前の業務棚卸し質問でも確認できます。
用語集の目的は、全員に技術を覚えてもらうことではありません。「この会社では、この言葉を使った時にどの範囲を指し、次に誰が判断するか」を明らかにすることです。公開されているAIスキルや一般知識はコピーできますが、過去に止めた理由、顧客対応で守る条件、例外時の引き継ぎは会社固有です。用語集は記憶の保管ではなく、次の担当者の判断を補完する入口になります。
最初に定義する8つの言葉
| 用語 | 社内で決める意味 | 記載例 |
|---|---|---|
| 1. 生成AI | 利用を認めるサービスと用途 | 承認済み環境で文章・画像等の候補を生成する仕組み |
| 2. 入力 | AIへ渡す情報の範囲 | 匿名化した問い合わせ文。氏名や契約情報は含めない |
| 3. 出力 | AIが作る候補と利用先 | 返信の下書き。顧客へ直接送る完成文ではない |
| 4. 正本 | 最終判断で参照する情報源 | 最新の商品台帳、承認済みFAQ、契約原文 |
| 5. 人間確認 | 誰が何を確認するか | 担当者が事実、責任者が価格・契約条件を確認 |
| 6. 例外 | 通常処理を止める条件 | 苦情、返金、情報不足、本人確認、規程の矛盾 |
| 7. 機密情報 | 入力・共有しない情報 | 認証情報、未公開価格、顧客一覧、契約上の秘密 |
| 8. 判断ログ | 残す判断と改善先 | 止めた理由、確認者、最終判断、次回のルール修正 |
辞書的な意味だけでは足りません。たとえば「正本」を「正しい情報」と書いても、担当者はどのファイルを開けばよいか分かりません。「商品名と価格は商品台帳」「契約条件は締結済み契約書」のように、業務ごとの参照先まで示します。正本が複数ある場合は、優先順位と更新責任者も決めます。
「人間確認」も、単に「最後は人が確認」と書かないことが大切です。事実、表現、金額、契約、個人情報、送信先など確認対象を分け、誰が承認できるかを書きます。役割が集中している場合は生成AI導入後の責任者と役割分担を使い、実行者・確認者・業務責任者を分けます。
「例外」には、珍しい出来事だけでなく、情報不足や担当者不在も含めます。AIが答えられない時を失敗として隠すのではなく、人へ戻す正常な経路として定義します。導入前にAI導入の例外ケース一覧を作ると、用語と停止条件を結び付けやすくなります。
一般用語集と業務用語集の違い
| 一般用語集 | 業務で使える社内用語集 |
|---|---|
| ハルシネーション＝AIが誤った情報を生成すること | 正本で確認できない固有名詞・数値・日付が含まれたら送信を止める |
| プロンプト＝AIへの指示文 | 承認済みの入力様式。顧客情報を貼らず、目的と出力形式を指定する |
| 人間参加型＝人が処理に関与すること | 担当者が下書きの事実を確認し、責任者が価格変更を承認する |
| ログ＝利用履歴 | 入力本文を保存せず、業務名、停止理由、最終判断、改善先を残す |
技術用語を増やしすぎる必要はありません。RAG、MCP、エージェントなどの言葉は、その仕組みを導入候補として扱う時に追加します。先に必要なのは、現場が毎日使う「入力」「出力」「確認」「例外」です。技術名から始めると、製品の比較はできても、会社として何を決めたかが残りません。
また、同じ用語でも業務ごとに条件が違います。公開ブログの「人間確認」は事実・引用・公開可否の確認ですが、問い合わせ返信では本人、価格、契約、苦情の確認が加わります。共通定義の下に業務別の補足を置き、全社用語集を巨大にしない設計が実用的です。
社内用語集を作る5つの手順
- 最近の認識違いを一件選ぶ：会議、試験運用、確認作業で言葉がずれた場面を起点にする。
- 動詞で範囲を分ける：集める、分類する、作る、確認する、承認する、送るを別作業にする。
- 8語へ具体例を付ける：抽象定義の横に、自社で安全な例と停止する例を書く。
- 業務責任者が承認する：AI担当者だけで決めず、元の業務で責任を持つ人が確認する。
- 変更理由を残す：例外や誤解が起きたら、定義、変更日、理由、影響する手順を更新する。
作成会議は一業務に絞ります。たとえば「問い合わせ返信の下書き」を選び、過去の一件を入力から送信までたどります。誰かが「ここもAIに任せると思っていた」と言った場所が、用語集へ追加すべき境界です。最初から完璧な辞書を作るより、一件の判断に使える表を作ります。
更新の合図も先に決めます。利用サービス、入力データ、商品・価格、担当者、社内規程、顧客反応が変わった時は、用語の意味と例が古くなっていないか確認します。見直しの具体的なきっかけはAI運用ルールを見直す7つの変更イベントにまとめています。
そのまま使える用語集テンプレート
表計算や社内READMEに、次の9列を作ります。「用語／短い定義／対象業務／安全な例／停止する例／正本／確認者／更新日／変更理由」です。1セルに長い規程を貼らず、詳細手順へのリンクを置きます。新しい担当者が一分で判断の入口を見つけられる長さを目安にします。
公開用READMEと社内用語集は分けます。公開側には一般的な方針や安全なテンプレートを置けますが、顧客名、内部の権限、非公開URL、具体的な機密区分は載せません。社内側も認証情報そのものは保存せず、承認された保管先と確認手順だけを示します。
運用開始後は、用語が使われたかを確認します。会議資料、試験結果、承認依頼で別の表現が増えていたら、単に禁止せず、既存語との違いを話します。新語が必要なら追加し、同じ意味なら表記を統一します。用語集は言葉を縛るためではなく、迷った時に判断へ戻る手すりです。
用語集が機能しているかは、暗記テストではなく実際の判断で確かめます。新しい担当者へ一件の例を渡し、「この入力は使えるか」「この出力は誰が確認するか」「どの条件なら止めるか」を説明してもらいます。答えが人によって分かれた項目は、本人の理解不足と決めつけず、定義、具体例、正本へのリンクが足りない可能性を確認します。
更新時には古い定義を完全に消さず、変更理由を短く残します。「機密情報の対象に見積原価を追加。外部AIへ貼り付けた事例ではなく、新しい価格管理方針に合わせた予防更新」のように、事実と判断を分けます。後から見た人は、なぜ厳しくなったのか、いつ再検討できるのかを理解できます。判断ログの書き方は中小企業向けAI運用ログの7項目にもつながります。
用語の増やしすぎにも注意します。似た言葉が三つ並んだら、違いを一文で説明できるか確認してください。説明できなければ統合するか、上位語と業務別の補足に分けます。読む人が検索しやすい表記を主語にし、社内だけの略語は別名として添えます。用語集を軽く保つことも、継続して使われるための運用ルールです。
よくある質問
生成AIの社内用語集は何語から始めればよいですか？
最初はこの記事の8語で十分です。対象業務を一つ選び、各語に具体例を一つ付けます。利用製品や技術が増えた時だけ用語を追加し、長い辞書を先に作らないようにします。
一般的なIT用語集をそのまま使ってよいですか？
意味を知る参考にはなりますが、そのままでは業務判断に使えません。「当社では何を指すか」「誰が確認するか」「どの条件で止めるか」を追記してください。外部資料の定義と違う場合は、その違いも明記します。
用語集は誰が更新しますか？
文書の管理担当者を一人決めつつ、意味の承認は対象業務の責任者が行います。AI担当者が技術面を補助しても、顧客対応、価格、契約、公開などの責任は元の業務から移しません。
次の一歩：一業務の8語を30分でそろえる
まず導入候補の業務を一つ選び、8語の表を埋めてください。空欄になった「正本」「人間確認」「例外」は、ツール選定より先に補うべき判断です。社内承認へ進む場合は、これらを生成AI導入の稟議書10項目へ移すと、試験範囲と停止条件を一枚で確認できます。Miraigentの無料AI導入診断では、用語のずれを対象業務、任せる範囲、確認者、停止条件へ翻訳し、小さく試す順番を整理します。