生成AIに社内用語集のたたき台を作らせたいとき、最初から社内文書をまとめて渡すことから始める必要はありません。最初の1回は、非機密または合成した短い業務資料を1件だけ選び、候補を5〜10語程度に抑えます。
各行に、次の4項目を持たせます。
- 定義候補
- 原資料の箇所
- 基準日または更新日
- 確認状態
AIは候補の整理、人は原資料との照合と採用判断を担当します。4項目、5〜10語、資料1件という単位は、公的ガイドラインが指定する様式ではありません。確認範囲を小さくするための、この記事の編集提案です。
まず区別する3つ
事実:公的資料が支える範囲
AI事業者ガイドライン(METI/経済産業省)は、事業者によるAIの開発・提供・利用に関する幅広いガバナンス上の論点を扱っています。デジタル庁の「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン(第2.0版)」を策定しました|デジタル庁は、政府の生成AIの調達・利活用に関するルールと対応事項を扱っています。
両者は目的と適用主体が異なりますが、入力や出力の扱い、利用時の確認・管理を検討する際の背景資料にはなります。ただし、E2は政府情報システム・政府職員向けの資料です。民間中小企業の法的義務や、社内用語集の標準を定めるものではありません。
編集上の提案:原資料へ戻れる確認台帳を作る
この記事では、公的資料の考え方を民間業務へそのまま適用するのではなく、1つの資料を起点に候補を確認する小さな方法へ翻訳します。AIの出力を正本にするのではなく、人が原資料へ戻れる状態を作るのが目的です。
MASTER key側の発信仮説
一般的なAIツール紹介ではなく、業務資料、定義候補、人の確認、保留を1つの試行へ接続する。この角度は、MASTER key株式会社とAX事業部が今後発信したい業務変革の論点になり得ます。ただし、独自性、顧客成果、認知向上を示す観測結果ではありません。
用語表は正本ではなく、原資料へ戻るための確認台帳にする
| 欄 | 記入するもの | 判断の目安 |
|---|---|---|
| 用語候補 | 原資料に現れる業務名、サービス名、略語 | 原資料に表記がなければ採用候補にしない |
| 定義候補 | AIが作った短い説明 | 原資料の記述と一致するか人が確認する |
| 原資料の箇所 | ページ、章、見出し、段落など | 場所を示せない行は保留する |
| 基準日または更新日 | 資料の版、作成日、更新日 | 日付が不明なら不明のまま記録し、保留を検討する |
| 確認状態 | 未確認、確認済み、保留 | 確認済みは人が原資料を見た行だけにする |
| 保留理由 | 原資料に定義がない、表記が揺れる、日付が不明など | 次に誰が何を確認するかを残す |
この表の役割は、AIの回答を正式名称へ昇格させることではありません。どの行が原資料へ戻れて、どの行がまだ戻れないかを分けることです。
5ステップで1業務だけ試す
1. 入力する資料を1件に決める
まず、公開可能な短い資料、または内容を置き換えた合成資料を1件選びます。公開可能だからといって自動的に入力してよいとは限りません。使用するAIサービスの利用条件と、社内での入力可否を確認してから進めます。
資料名、対象業務、正本候補とする理由、版または基準日、確認担当を先に記録します。顧客情報、個人情報、契約上の秘密、認証情報、未公開情報は、この試行の入力にしません。正本候補かどうか判断できない資料も、先に保留します。
2. AIには候補抽出だけを依頼する
依頼文に、使ってよい資料の範囲と、推測をしない条件を含めます。例えば次のようにします。
対象資料はこの1件だけです。
文書に実際に現れる業務名・サービス名・略語を最大10件抽出してください。
出力列:用語候補/定義候補/原資料の箇所/基準日または更新日/要確認理由/確認状態
文書にない正式名称、意味、日付を補わないでください。
該当箇所を示せない候補は保留候補として出してください。
確認状態は未確認とし、採用判断はしないでください。
AIに定義を断定させるのではなく、確認が必要な候補を表に並べさせます。
3. 人が原資料へ戻る
候補ごとに、次の順で確認します。
- その用語が原資料に実際に書かれているか。
- AIの定義候補を、原資料のどの記述が支えているか。
- 正式名称と略語が混ざっていないか。
- 適用範囲が勝手に広がっていないか。
- 基準日または更新日が記録できるか。
1つでも確認できない項目があれば、確認済みにはしません。原資料にない正式名称をAIが補った場合、行を削除するか、保留理由を残して採用しない扱いにします。
4. 状態を3つに分ける
| 状態 | 条件 | 次の処理 |
|---|---|---|
| 未確認 | AIが候補を出しただけ | 原資料との照合待ち |
| 確認済み | 用語、意味、箇所、日付を人が確認した | 同じ業務の内部下書きでのみ使用を検討 |
| 保留 | 根拠箇所がない、意味が複数ある、日付が不明など | 責任者または資料管理者へ確認を戻す |
保留は失敗ではなく、確認できないものを確認済みに混ぜないための状態です。保留の理由と、次に確認する人を残すと、後で再開しやすくなります。
5. 確認済みの行だけを1業務の下書きに使う
最初は、同じ業務の内部下書き、たとえば手順書の見出し案や社内説明のたたき台に限定します。承認済みの共有資料、顧客向け説明、業務システム、自動実行へ接続する前に、責任者へ戻します。
この用語表自体を自動承認、自動更新、自動公開の仕組みにしないことも重要です。今回扱うのは、1業務の言葉を確認するための小さな試行です。
仮想例:合成資料1件で3語だけを見る
以下は実在の社内資料・顧客資料ではない、説明用の仮想例です。文言、ページ番号、日付はすべて合成しています。
資料名:合成した問い合わせ対応手順 2026年4月版
| 用語候補 | 定義候補 | 原資料の箇所 | 基準日または更新日 | 確認状態 |
|---|---|---|---|---|
| 一次受付 | 問い合わせを最初に受け付ける工程 | p.1、3行目 | 2026年4月1日 | 確認済み |
| 案件化 | 対応候補として営業担当へ渡すこと | p.2の見出しに表記のみ | 2026年4月1日 | 保留:本文に定義がない |
| 緊急度A | 当日中の確認が必要な区分 | p.2、5行目 | 2026年4月1日 | 確認済み |
この例で、案件化をAIの説明どおりに正式定義へ入れてはいけません。原資料に意味の説明がないため、資料管理者へ確認する行として残します。
この試行で扱わないこと
- 実在する秘密情報、顧客情報、個人情報、契約情報、認証情報、未公開情報の入力
- AIが補った正式名称や意味の正本化
- 用語表の自動承認、自動更新、自動公開
- RAG、API、AIエージェント、外部システム、自動実行への接続
- 人事評価、採用、与信、価格、法務、医療、金融などの高影響判断への直接利用
- 公的ガイドラインがこの4項目や語数を義務付けているという説明
最初の判断カード
実際に始めるときは、次の欄だけを先に埋めます。
対象業務:
正本候補資料:
対象範囲:
資料の版または基準日:
確認担当:
用語候補:
定義候補:
原資料の箇所:
更新日:
確認状態:未確認/確認済み/保留
保留理由:
次回確認日:
空欄をAIに推測で埋めさせず、分からない欄は分からないまま残します。確認できない行を保留にできることが、この小さな表の判断上のポイントです。
まとめ
生成AIで社内用語集を作る最初の一歩は、社内資料を大量に読み込ませることではありません。
- 非機密または合成した資料を1件選ぶ。
- 5〜10語程度の候補を出す。
- 定義候補、原資料の箇所、基準日または更新日、確認状態を並べる。
- 人が原資料へ戻り、確認できない行を保留する。
- 確認済みの行だけを、まず1業務の内部下書きで使う。
この方法は、社内用語集の需要やAI導入効果を証明するものではありません。検索質問も読者課題も現時点では仮説です。それでも、AIの提案をそのまま正式名称や社内ルールにしないための、確認可能な最小単位として試すことはできます。