Claude Codeに出させたタイトル案をそのまま使って、記事を公開した。数日して読み返し、そこで気づいた。タイトルに入れた言葉が、自分とAIの間でしか通じない。

2ヶ月前の作業中にAIが付けた名前だった。やがてファイル名になり、複数のスキルファイルから参照され、毎日目にしていた。読んでいる間は一度も引っかからなかった。

これらのドキュメントは、自分が指示してAIに書かせたものだ。自分は読んで承認する側で、文面を一から書いてはいない。そこが後で効いてくる。

気になって、ドキュメント一式を数えてみた。

27ファイル・145,190字に、24語が285回

自分が引っかかった語を書き出し、そこから似た性質のものを拾ってリストにした。そのリストで ~/.claude/skills/ 配下のMarkdownを全部走査した。

下は結果の一部で、AIが作った造語のほうは伏せてある。ここに並べても読む人には意味が取れないし、広める必要もない。

対象: 27ファイル / 145,190字

moat        42回 / 11ファイル
堀          28回 /  7ファイル
墓標        27回 /  3ファイル
premortem   12回 /  5ファイル
...

合計 285回 / 24語

分類すると4種類あった。

AIが作った言葉 … 一般には存在しない造語
業界用語だが日本語圏で一般的でない … 「moat」「premortem」「need-zero」
別分野の専門語を借りたもの … 「律速」（化学）「交絡」（統計）「直積」（数学）
一般的な語に、AIが独自の意味を与えたもの … 「堀」「墓標」

どれも読んでいる自分の中では意味が完全に定まっている。だから読んでいて引っかからない。

4種類目が一番たちが悪かった。ドキュメントの中で「堀」は競争優位（英語の moat の直訳）を、「墓標」は失敗して残った先行事例を指していた。どれも日本語として存在する語なので、読む側は知らない言葉に出会ったと気づけない。そのまま別の意味で読み進めてしまう。造語なら「これ何だ」で止まるが、こちらは止まらない。

なぜAIは言葉を作るのか

長い説明を短い名前に置き換えると、以降のやりとりが短くなる。「案を落とした理由を構造化して記録したファイル」と毎回書くより、1語のほうが短い。LLMは限られた文脈の中で動くので、繰り返し出てくる概念を圧縮するのは動作として合理的な方向に働く。

技術文書は、そもそも用語を定義して使う形式で書かれている。設計書も論文も仕様書も「本稿では〜をXと呼ぶ」という構造を持つ。その形式を学習しているので、概念のかたまりを見つけると名前を付ける方向に寄る。〔ここは推測。学習データの内訳は公開されていないので確かめていない〕

そして、一度使った語を揺らさない。ここが人間と違う。人間が同じ資料を書くと、同じものを「あの記録」「例のファイル」と揺れた呼び方をする。揺れると読み手が引っかかって、「これ何て呼ぶんだっけ」という会話が起きる。AI相手にはそれが起きない。初出から最後まで同じ語で通るので、最初から定着した用語のように見えてくる。

言葉が生まれる仕組みより、生まれた言葉が訂正されない仕組みのほうが効いている。

自分は一度も使っていなかった

記事を書きながら、ひとつ確かめたくなった。自分はこれらの言葉を使って指示していたのか。

過去のやりとりのログを全部検索した。テキストで残っている自分の発言1,585件が対象。

結果は0件だった。 24語のどれも、自分は一度も打っていない。ヒットしたのは、システムが出す通知と、今回「この言葉は変では」と指摘したとき自分の発言だけだった。

自動で進める設定で作業していたので、ドキュメントの更新はAIが判断して行う。自分は結果を読んで承認する。つまり名前を作ったのもAI、書いたのもAI、2ヶ月使い続けたのもAIで、自分は一度もその言葉を発していない。

それでも285回書かれ、ファイル名になり、最後は自分名義の記事のタイトルに入って公開された。

訂正が入らない理由

読む側が意味を取れてしまうからだった。

自分は読んで承認していた。文脈があるので意味は分かる。分かるから止めない。「意味が分かるか」と「外の人に通じるか」は違う判定なのに、承認するときは前者しか見ていなかった。

そしてAIは意味を聞き返さない。通じているかどうかを試す機会が、2ヶ月間で一度も発生しなかった。

チーム開発ならここが違う。新しく入った人が「これ何ですか」と聞く。その質問が検証になる。1人で作業していると、その質問が永久に来ない。

ファイル名になると戻せなくなる

本文の言葉なら書き換えられる。厄介なのは、造語が識別子になる場合だ。

自分の場合、造語のひとつがそのままファイル名になっていた。7つのスキルファイルから参照され、相対パスで書かれ、運用手順の中にも登場する。名前を変えるなら参照側を全部直すことになる。

コードでも同じことが起きる。AIと設計を詰めているとき、概念に名前が付く。その名前がクラス名になる。テーブル名になる。APIのパスになる。本文の造語は直せるが、識別子になった造語は移行コストを持つ。

名前が固まる前に一度止まったほうがいい。

「用語辞書を作れ」の先にあるもの

Claude Codeで開発するとき、ユビキタス言語辞書を作るべきだという主張がある。AIが作業開始時に必ず用語辞書を読み、コード内の用語は辞書の定義に従う、という運用だ。

これは正しい。用語が揺れるのは実害があるし、AIは指示された定義を守る。

ただし、この運用が想定しているのはチームがいる状況だと思う。チームなら、辞書に載っている言葉が外に通じるかを、別の人間が指摘できる。

1人とAIだけの場合、その指摘が発生しない。用語は完璧に統一されているが、統一された内容が内輪に閉じているかを誰も見ていない。 統一と、外部への通用性は別の問題だった。

自分は前者だけをやって、後者を2ヶ月やっていなかった。

数えるところまでは10分で終わる

~/.claude/skills/ でも CLAUDE.md でも、設計ドキュメントでも同じことができる。

一番難しいのは、AIが付けた名前を洗い出す作業だった。自分の中で自然になっている言葉ほど出てこない。

最初は、使わない語をリストにして投稿前に検査する仕組みを作った。これは効かなかった。リストに入れた「母数」と「天井」はどちらも辞書に載っている普通の語で、他人に指摘されるまで気づかなかった。そもそもリストは既に知っている語しか止められない。気づけないから問題になっているのに、気づくことが前提になっている。

効いたのは、文脈を持たない読み手に読ませることだった。

新しいセッションのAI、あるいはそのプロジェクトを知らない人に文書を渡して、分からない語を挙げてもらう。これならリストを維持しなくていいし、まだ名前も付いていない新しい造語も拾える。作業に使っているAIは文脈を持っているので、この役はできない。文脈が無いことが条件になる。

分かったこと

AIと作業すると用語は自然に統一される。統一されるのは良いことなのに、それが外に通じるかは別に確かめないといけない。

2ヶ月で24語混ざっていた。自分は一度も使っていないのに、ひとつはファイル名になり、ひとつは公開記事のタイトルに入っていた。

止まって確認する機会が、2ヶ月で1回もなかった。

参考

Claude Codeで開発する時こそ「ユビキタス言語辞書」を作ろう！