AIの造語は、どこから来た？回答と資料を点検する4手順

2026年9月29日 07:52

社内AI 実践ノート 06｜全文無料

回答に混ざった造語を、候補・原本・回答記録・修正後の確認の4段階で点検する記録です。本文だけでなく見出し、例文、画面、履歴も見ます。

当時は132回答中36件、約27%で問題の表現を観測し、修正後の33回答では0件でした。この対象と期間での観測で、将来の混入ゼロを保証するものではありません。検索語に合わない造語は拾えず、一般的な日本語を誤って拾うこともあるため、人が候補を確認します。

SQLは件数に加えて、混入回答数÷全回答数×100の割合を出す形に改訂しました。原本の一致はサイズだけで判定せず、内容の差分やハッシュも照合します。

社内AIの回答を読んでいて、「うちでは、こういう言い方はしないんだけどな」と引っかかったことはありませんか。

間違いではないし、意味も通じる。でも、社内の資料にも会議にも出てこない言い回しが、ときどき混ざっている。

わたしはそれを「AIの口ぐせ」だと思って流していました。違いました。混ぜていたのは、作ったわたしの側です。

測ってみたら、社員に返した回答の27%に入っていました。

社内に存在しない言葉を、AIが社員に使っていた

評価やキャリアの相談に答える社内AIを作っています。社員が「次の評価を上げるには何をすればいいか」と聞くと、会社の評価基準を読んだうえで答えます。

ある日、回答にこういう言い方が並んでいることに気づきました。

いまはB段にいるので、A段に上がるには……

「B段」「A段に上がる」。社内でこんな言い方はしません。 うちの評価はアルファベットで付き、社員は「評価はBだった」と言います。「段」は付けません。

記録を調べると、132回答のうち36件（27%）で、AIが社員に「◯段」と言っていました。同じ種類の「現在地」という言い方も9件ありました。

社員が評価シートでも面談でも一度も見たことのない言葉を、会社が配ったAIが使い続けていたわけです。

出どころは、わたしが書いた指示文だった

AIが勝手に作った言葉なら、話はまだ簡単でした。

資料ごとに「◯段」が何回出てくるかを数えました。

人事が確認した評価基準の原本 … 1回
等級ごとの評価項目と配点 … 0回
行動指針の資料 … 2回
AIに毎回渡している補足の指示文 … 3回

補足の指示文は、わたしが書いたものです。会社の資料にはほぼ無く、わたしが書いた文書にだけある。

入った経路も分かりました。

わたしは開発を、コードを書く別のAIと一緒に進めています。指示文の下書きもそのAIに手伝わせています。そのAIが、わたしとの会話の中で「段を渡す」「段を渡さない」と何十回も言っていました。

何十回も目にしたあとで、ようやくこう聞きました。

段って、あなたすごい多用してますが何？

開発の会話の中で生まれた言葉が、指示文に入り、指示文から社員への回答に出ていました。 何十回も見ていたので、わたしの中ではもう普通の言葉になっていました。

誰も指摘しなかったし、作った本人も気づけなかった

利用者は、誰も指摘していません。

当然だと思います。「B段」は、読めば意味が分かります。評価の段階のことだと想像がつく。分かるので、引っかからない。 引っかかった人がいても「AIの言い方だな」で終わります。わざわざ報告する人はいません。

そして作った本人は、もっと気づけません。自分の言葉は、自分には造語に見えないからです。

もう1つ、自分でこたえたことがあります。

画面の名前を決めるとき、候補に「現在地」がありました。わたしはそれを「設計者の造語だから伝わらない」と言って捨てています。 同じ判断を、自分で一度下していたんです。

それなのに、回答の中では「現在地」が9件使われていました。却下した判断が、別の場所に適用されていませんでした。

名前のときは気づけたのに、回答では気づけなかった。違いは、目に入る回数だと思っています。画面の名前は一度決めれば終わりですが、回答は毎日流れていきます。

なぜわたしがこれを書けるのか

エンジニアではありません。 事業部門の人間が、業務の合間に社内AIを作りました。

社員に配ったあとは、記録を全部読み、見つけた問題を原因ごとに分けて直しています。この件もその1つです。

直したあとの数字も測りました。修正後の33回答で、造語は0件です。

ただ、そこまで一直線ではありませんでした。3回つまずいています。

「残りは4件です」と報告を受けて安心したら、実際には31行残っていました。7倍です
本文を直し終えたあとで、AIが毎回読む「見出し」に造語が残っていたのを見つけました
一括置換をかけると、人事確認済みの原本にある正しい日本語の「段」まで壊れることに、途中で気づきました

3回とも、「直した」と思った直後です。

この記事を読み終わると、こうなります

自分のAIに混ざっている造語の候補を、今日のうちに一覧にできます
社員への回答の何%に混ざっているかを測れます
その言葉がどの資料・どの指示文から入ったかを突き止められます
原本を壊さずに外し、外したあとに混入を抑える指示の書き方ができます

必要なのは、AIに渡している資料と指示文、それと回答の記録だけです。 記録が無くても、4ステップのうち3つはできます。

全体の地図：4ステップです

やることは4つです。順番を変えないでください。

ステップ1  候補を出す
　　　　　 → 指示文と資料から、社内で使わなそうな言葉を洗い出す
　　　　　 → 完了条件：候補が一覧になっている

ステップ2  原本で判定する
　　　　　 → 候補ごとに、会社の原本と自分の文書での出現回数を数える
　　　　　 → 完了条件：「会社の言葉」と「自分の言葉」に分かれている

ステップ3  回答の記録で測る
　　　　　 → 自分の言葉が、社員への回答の何%に出ているかを日別に出す
　　　　　 → 完了条件：直す前の数字が手元にある

ステップ4  入口を全部ふさいで、もう一度測る
　　　　　 → 5つの入口から外し、禁止を「型」で書く
　　　　　 → 完了条件：修正後の回答で0件

3を飛ばさないでください。 直す前の数字が無いと、直したあとに0件になっても、それが直ったからなのか、もともと少なかったのかが分かりません。

ステップ1：造語の候補を出す

目的：自分には普通に見えている言葉を、外に出す。

自分で読み返しても見つかりません。何十回も見た言葉は、もう造語に見えないからです。別の目を使います。

やり方は2つです。

1つめ：開発に使っているAIに洗い出させる

会社の原本と、自分が書いた指示文の両方を渡して、これを貼ります。

これから2種類の文書を渡します。
A：会社が作った原本（評価基準・規程など）
B：わたしがAI用に書いた指示文・補足資料

Bに出てくる言葉のうち、Aには出てこない名詞・言い回しを全部挙げてください。

条件：
- 一般的な日本語でも、Aで使われていない言い方なら挙げる
- 特に「評価・等級・レベル・状態」を言い表す言葉は漏らさない
- それぞれについて、Bでの出現回数を添える
- Aに近い意味の言葉があれば、Aでの言い方を添える
- 判断に迷うものも挙げる。消すかどうかはわたしが決める

最後の1行を消さないでください。 ここでの目的は、漏れなく挙げさせることだけです。造語かどうかの判定は、ステップ2で人がやります。

「評価・等級・レベル・状態」を名指ししているのは、造語が生まれやすいのが「人の状態を言い表す言葉」だからです。うちの「段」も「現在地」も、どちらも社員がいまどこにいるかを言う言葉でした。仕組みを説明しようとすると、人は自分なりの呼び名を作りがちだと思っています。

2つめ：社内の言い方を知っている人に確かめる

候補を見せて「これ、普段使いますか」と聞きます。

うちの場合は、社内の言い方をわたし自身が知っていたので、確認は一瞬でした。「評価はBだった」と言い、段は付けません。自分が詳しくない領域の資料なら、現場の人に1回聞いてください。 1回で済みます。

完了条件：候補が一覧になっている。多すぎて困るくらいでちょうどいいです。

候補が出たら、次はそれが本当に自分の言葉なのかを判定して、社員への回答に何%出ているかを測り、入口をふさぎます。わたしが3回つまずいたのは、全部そこから先です。

ステップ2：原本で判定する

目的：候補を「会社の言葉」と「自分の言葉」に分ける。

候補ごとに、資料別の出現回数を数えます。数えるのは、AIに渡している文書全部です。原本、原本を加工した資料、補足の指示文、システムプロンプト（AIに毎回渡している「こう答えて」の指示文）。

判定の基準は3つです。

原本に0回、自分の文書に1回以上 → 自分の言葉。外す
原本に1回だけ → 原本の文脈を読む。 呼び名として使っているのか、たまたま出てくるだけなのか
原本に何度も出てくる → 会社の言葉。残す

うちの「段」は、原本に1回、配点の資料に0回、わたしの指示文に3回でした。会社がその言葉で社員を呼んでいないことは、この時点ではっきりしました。

「4件」と報告されて、31行あった

ここに落とし穴があります。検索の仕方で、数が変わります。

外す作業の途中で、開発用のAIに残りを数えさせました。返ってきたのは「4件」です。実際は31行ありました。

原因は、`D段` `C段` のような「英字＋段」の形しか探していなかったことでした。「段の判定」「次の段」のような、「段」単独の使い方を全部見落としていました。

見落とさない探し方は、この3手順です。

手順1：いちばん短い形で、全部拾う

「段」なら「段」1文字で検索します。「B段」や「段に上がる」で探してはいけません。形を決めて探すと、その形以外は全部漏れます。

手順2：拾った行を全部並べて、正しい日本語を人の目で除外する

「特段」「一段上」「段階」「手段」「段落」のような言葉です。

手順3：残ったものが対象

狭く探して「少ない」と安心するのが、いちばん危ないです。 広く拾ってから、人の目で除外する。この順番を逆にしないでください。

正しい「段」は残す

原本の中にも、日本語として正しい「段」がありました。「特段」が1箇所、「一段上」が2箇所です。

機械で一律置換すると、この3箇所まで壊れます。 しかも壊れるのは、人事が確認した原本です。ここが置換のいちばん危ないところでした。

完了条件：候補が「会社の言葉」と「自分の言葉」に分かれていて、自分の言葉ごとに、どのファイルの何行目にあるかが分かっている。

ステップ3：回答の記録で測る

目的：直す前の数字を持っておく。

回答の記録がデータベースに入っているなら、これで日別の混入率が出ます。

WITH daily AS (
 SELECT DATE(ts) AS d, COUNT(*) AS answers,
 COUNTIF(REGEXP_CONTAINS(
   REGEXP_REPLACE(answer, r'特段|一段|段階|手段|段落|階段|段取り', ''),
   r'段|現在地'
 )) AS coined
 FROM chat_log
 WHERE kind = 'answer' AND eval_run IS NULL
 GROUP BY d
)
SELECT d, answers, coined,
 ROUND(100 * SAFE_DIVIDE(coined, answers), 1) AS coined_percent
FROM daily ORDER BY d

やっていることは、ステップ2の3手順と同じです。

内側の `REGEXP_REPLACE` で、正しい日本語（特段・段階など）を先に消す
外側の `REGEXP_CONTAINS` で、残った文章に「段」1文字が入っているかを見る
`eval_run IS NULL` は、動作確認のために自分で投げた質問を除くための条件です。これを入れないと、テストの回答で数字が汚れます

`段|現在地` の部分を、ステップ2で「自分の言葉」と判定したものに入れ替えて使ってください。除外する語の一覧も、自分の候補に合わせて足します。

日別に出すのは、直した日の前後を比べるためです。 全期間の合計だけだと、直した効果が見えません。

うちは直す前が132回答中36件（27%）、直したあとが33回答中0件でした。

記録がスプレッドシートにある場合は、回答の列に対して同じことをします。まず「段」で検索して件数を出し、正しい日本語の行を目で除いて数え直すだけです。件数が数十件なら、それで十分です。

完了条件：直す前の件数と割合が、日付つきで手元にある。

ステップ4：入口を全部ふさいで、もう一度測る

目的：造語が二度とAIに渡らないようにする。

造語がAIに渡る5つの入口

本文を直せば終わり、ではありません。AIが読むものは、本文だけではないからです。 うちでは5つの入口から入っていました。

入口1：補足の指示文

資料と一緒に毎回渡している「こう答えて」の文書です。今回の本体で、「段」が3回ありました。

入口2：システムプロンプト

「段」は0回でした。ただし「現在地」が3回ありました。1つの入口を直して安心すると、別の造語が残ります。

入口3：プログラムの中に書いた出力ルール

回答の形を決めるルールを、プログラムの中にも書いていました。うちは6箇所を直しています。文書だけ直すと、ここが残ります。

入口4：フォルダ名・見出し

いちばん見落としていたのがここです。

資料をAIに渡すとき、フォルダ名を見出しとして付けていました。そして評価面談用の資料を入れたフォルダの名前が、「段の判定」でした。

フォルダ名が、資料の見出しとして毎回AIに渡っていたんです。 本文をいくら直しても、見出しに残っていたら、AIには「段の判定」という章があるように見えます。

フォルダ名は「評価レベルの判定」に変えました。AIに渡す仕組みを自分で書いている人は、そのプログラムが何を見出しにしているかを1回確かめてください。 フォルダ名、ファイル名、シート名。どれかが渡っているはずです。

入口5：変更履歴

AIが読む文書の中に「◯◯を××に直した」と書くと、AIは「◯◯」がいまも存在すると読みます。

システムプロンプトを書き直したとき、最初の案の冒頭に変更履歴を入れていました。そこに「旧番号を新番号に直した」と書いてあり、それを読んだAIが旧番号が存在すると思うことに気づいて、履歴ごと消しました。

ところが、原本を加工した行動指針の資料の側にも、同じ変更履歴が残っていました。 「項目番号を旧形式から新形式に統一した。AIが旧番号で答えていた」という一文です。旧番号を消すための記録が、旧番号をAIに教えていました。

ついでに見つかったものもあります。システムプロンプトの旧版には、試作していた頃の手順書が丸ごと入っていました。 「このツールを開いて、下の文章を貼る」という人間向けの手順が、全部の相談の前にAIへ渡っていました。

結論はこうです。

経緯は開発の記録に書く。AIが読む文書には書かない。

いまはシステムプロンプトの冒頭に、こう書いてあります。

※この文書はそのままAIの人格になる。変更の経緯は書かない（AIが指示として読むため）。

これは、自分への注意書きです。 次に編集するときの自分が、履歴を足さないようにするためです。

禁止は「型」で書く。値は書かない

外したあとは、もう入らないように禁止を1行足します。 ここで書き方を間違えると、逆効果になります。

同じ指示文の中に、たまたま比較できる2つの禁止がありました。

効いた書き方（型だけ書いた）

✗ レベルに「段」を付ける言い方

修正後の33回答で、0件です。

逆効果だった書き方（値そのものを書いた）

別の間違いを止めるために、存在しない番号を「こういう番号は使わない」という例として書いていました。

✗ 「No.◯◯ ◯◯◯◯」のような番号は使わない

（実際にはここに、具体的な偽の番号と項目名が入っていました）

書く前は0件だったのに、書いたあと6件に増えました。 しかも6件とも、利用者は「No.」と一言も書いていません。AIが自分から持ち出していました。

型は伝わる。値は再生産される。

禁止したい言葉そのものを例として並べると、AIはそれを「使ってよい言葉の一覧」のように扱います。書くのは「どういう形の言い方か」だけにします。

貼るだけで使える「言い方のルール」の型

上の「効いた1行」を、ほかの造語にも使える形に整えたのがこれです。指示文の先頭側に置いてください。 長い指示文の中盤に置くと効きにくくなります。

【言い方のルール】
回答では、会社の資料に書かれている呼び方だけを使う。
資料に無い呼び名で、社員の状態や立場を言い表さない。

評価のレベルは、資料のとおりアルファベットだけで言う。
（例：「評価はBだった」「Aを目指す」）

✗ レベルに「段」を付ける言い方
✗ 社員の状態を、資料に無い比喩（場所・段・階層など）で呼ぶ言い方

使い方は3つです。

2行目と3段落目の「評価のレベル」の部分を、自分の会社の正しい言い方に書き換える。正しい例は書いてよいです。書いてはいけないのは、間違いの例の中身だけです
✗の行は、ステップ2で見つけた造語の「形」を書く。造語そのものを並べるのではなく、「◯◯を付ける言い方」「◯◯で呼ぶ言い方」のように形で書く
貼ったら、ステップ3のSQLをもう一度流す

原本を壊さずに外す3手順

最後に、資料から造語を外すときの手順です。ここで原本を壊すと、造語よりも大きな事故になります。

手順1：手で打ち直さない

元の文章を機械で取り出して、スクリプトで置換します。人が見ながら書き直すと、関係ない行が抜けます。

手順2：行単位で差分を取る

置換の前後で、「消えた行」「足した行」を全部並べます。意図した箇所だけが変わっているかを、目で確かめます。

うちは1回目の確認で「意図せず消えた行が7行ある」と出ましたが、これは確認する側の数え方の誤りでした。取り直して問題ないことを確かめています。確認の仕組みも間違えます。 おかしな結果が出たら、直す前に確認のほうを疑ってください。

手順3：戻したあとに内容とバイト数を照合する

手元のファイルと、保存先に置いたファイルの大きさを比べます。うちは手元が15,170バイト、保存先が15,171バイトでした。差は末尾の改行1バイトだけです。ここがずれていたら、どこかで文字が落ちています。

人事確認済みの原本だけは、打ち直していません。 該当する語だけを、人が置き換えました。

理由は、前に原本を画像から手で書き写して、記述が抜け落ちる事故を起こしているからです。人が確認した文書は、人が確認した形のまま使います。

ちなみにこの場面で、開発用のAIは「直すのは4語だけなので、部分的に置換するほうが安全です」と反論してきました。4語ではなく31行でした。 根拠が、ステップ2の落とし穴そのものでした。

完了条件：5つの入口すべてを確認し、ステップ3のSQLを流して、修正後の回答で0件になっている。

つまずきやすい3点

「うちのAIは、社内の言葉しか使っていないはず」

作った本人が、いちばん気づけません。わたしは何十回も目にしてから、ようやく気づきました。自分の目を信用しない前提で、ステップ1を別の目でやってください。

「回答の記録を残していない」

ステップ1・2・4はできます。できないのはステップ3だけです。ただしステップ3が無いと、直ったかどうかが分かりません。 記録を残すなら、今日から始めても来週には比べられます。

「消すと意味が通らなくなる言葉がある」

消すのではなく、社内の言い方に置き換えてください。 うちは「B段」を「評価はB」に戻しただけで、意味は何も失われませんでした。

置き換え先がどうしても見つからないなら、その考え方自体が、社内に存在しない可能性があります。その場合は、AIに持たせるべき言葉かどうかから考え直したほうがいいと思っています。

検討して捨てた選択肢

造語を並べた禁止リストを作る → 捨てた

見つけた造語を全部並べて「これらを使わない」と書く。いちばん手軽です。

捨てました。 上に書いたとおり、値そのものを書くと再生産されます。0件が6件に増えた実例があります。並べるほど、AIに教えることになります。

全部の文書に一括置換をかける → 捨てた

「段」を「レベル」に一括で置き換える。速いです。

捨てました。 原本の「特段」「一段上」まで壊れます。そして壊れたことに、読み返すまで気づけません。

原本も含めて、全部AIに書き直させる → 捨てた

該当箇所を直した版を、開発用のAIに丸ごと作らせる。原本以外の資料では、実際にこの方法を使いました（手順1〜3つき）。

原本だけは捨てました。 人が確認した文書を機械に写させると、確認した事実そのものが無くなります。原本は、人が該当語だけを置き換えます。

公開前チェックリスト

洗い出し

指示文・資料の両方を渡して、原本に無い言葉を挙げさせたか
「評価・等級・レベル・状態」を言い表す言葉を、特に確認したか
判定をAIに任せず、人が決めたか

判定

候補ごとに、原本と自分の文書での出現回数を数えたか
いちばん短い形（1文字）で検索したか
正しい日本語（特段・段階など）を、人の目で除外したか

測定

直す前の件数と割合を、日付つきで持っているか
動作確認の質問を除いて数えているか
直したあとに、同じ条件でもう一度数えたか

入口

補足の指示文とシステムプロンプトの両方を確認したか
プログラムの中の出力ルールを確認したか
AIに渡るフォルダ名・ファイル名・見出しを確認したか
AIが読む文書に、変更履歴を書いていないか

書き方

禁止を「型」で書いたか。造語そのものを例として並べていないか
原本を打ち直していないか。差分・ハッシュ・バイト数で確かめたか

明日からやること

今日：AIに渡している指示文を開いて、社内の資料で見たことのない言葉に3つ印をつける
明日：その3つを、回答の記録で検索して件数を出す
件数が出たら：5つの入口を順に開いて、どこに書いてあるかを探す
外したら：「言い方のルール」の型を指示文の先頭側に貼り、1週間後にもう一度数える

今日の最初の一歩

この記事で伝えたかったのは1つです。

社内AIの回答に混ざる見慣れない言葉は、たいてい作った人の言葉です。

AIが勝手に作ったのではなく、作った人の頭の中の呼び名が、指示文や見出しを通ってAIに渡っています。だから、作った本人ほど気づけません。

今日やることは、ステップ1の前半だけで十分です。

AIに毎回渡している指示文を開いて、社内の資料で一度も見たことのない言葉に、印を3つつけてください。

特に、社員の状態やレベルを言い表している言葉です。10分で終わります。

わたしは、自分で「造語だから伝わらない」と言って捨てた言葉を、自分のAIに9回使わせていました。自分の言葉は自分には見えません。 見えないことを前提に、一度だけ外から数えてみてください。

社内AI 実践ノート

このシリーズは全文無料です。構築、取り込み、架空回答、評価、会社の見解、造語の順で読めます。

AIへの依頼を、日々の仕事で使うなら

管理職が無料で試せる依頼文で、小さな調査・比較から試せます。Excel・7種類の実務別指示文・完成サンプルが必要な方には、AI業務委任・検品キット（980円）を用意しています。