AIにドメインモデル・用語を整理させる｜認識のズレを早めに潰す
打ち合わせで「顧客の一覧画面を作ってほしい」と頼まれて、作りました。出してみると、営業の人は「会社ごとに並んでいないと困る」と言い、サポートの人は「問い合わせてきた人の名前で探したい」と言う。
あとから分かったのは、同じ「顧客」という言葉で、営業は契約している会社を、サポートは問い合わせてきた個人を指していたということでした。コードの中では、そのどちらでもない User というテーブルが使われていた。
ここで誰かを責めなくて大丈夫です。現場の言葉は、部署ごとの仕事に合わせて自然に育つもので、ずれていることに誰も気づかないのが普通です。気づいたのは、あなたが作るところまで進めたからです。
この記事では、このずれを作り始める前に見つけるために、AIにドメインモデル（業務に出てくる「もの」と、その関係を整理した図や一覧）と用語集の下書きを作ってもらう方法を整理します。
結論：順番は3つです。①拾う——仕様書、チケット、議事録、コードから、業務の言葉をAIに拾い出させる。②突き合わせる——「同じ言葉で違う意味」「違う言葉で同じ意味」の候補をAIに挙げさせ、決めつけずに質問の形で返させる。③決める——どの言葉をどの意味で使うかは人が決め、関係者に確かめてから用語集にし、コードの名前も揃えていく。
覚え方は 拾う → 突き合わせる → 決める。AIに任せるのは「ずれの候補を見つける」ところまで。言葉の意味を決めるのは、その業務をしている人です。
今日ぜんぶやる必要はありません。いま関わっている機能の仕様書かチケットを1つだけAIに渡して、出てくる言葉を拾ってもらう。それだけで、ずれの入口がいくつか見えてきます。
何が起きているのか——言葉は同じなのに、指しているものが違う
打ち手の前に、なぜ用語のずれは起きやすく、見つけにくいのかを整理します。
1つ目は、言葉が部署ごとの仕事に合わせて育つこと。営業にとっての「顧客」は契約の相手、経理にとっては請求先、サポートにとっては電話の向こうの人。それぞれの仕事では、その意味でまったく正しいので、誰も違和感を持ちません。
2つ目は、ずれが文章の上では見えないこと。仕様書に「顧客ごとに履歴を表示する」と書いてあっても、読む人が自分の意味で読めば、全員が納得してしまいます。ずれが見えるのは、画面や数字になって出てきたときです。
3つ目は、コードの名前が別の言葉で増えていくこと。業務では「顧客」、画面では「お客様」、テーブルは user、APIは account。同じものに名前が4つあると、どれとどれが同じなのか、新しく入った人には分かりません（既存コードにAIを馴染ませる文脈の渡し方｜実務の型）。
ここでAIが役に立ちます。たくさんの文書から言葉を拾い出し、「この2つの文書では、同じ言葉の使われ方が違うようです」と並べて見せるのは、AIが得意な作業です。ただし、AIはどちらの意味が正しいかを知りません。そこを取り違えないことが、この記事の要です。
具体例——つい、こうなりがちという形
どれも「早く形にしたい」という前向きな気持ちから生まれます。心当たりのある行があれば、そこだけ見れば十分です。
- 「このシステムのドメインモデルを作って」とだけ頼む：AIは、一般的な業務システムによくある「顧客・注文・商品」のきれいな図を出してくれます。でもそれはよくある形であって、あなたの会社の業務の形とは限りません。きれいに見える分、そのまま採用してしまいがちです。
- AIが言葉の意味を決めてしまう：「顧客は契約企業を指すものとします」と、AIが一方の意味に寄せて定義を書く。読んだ人は、それが社内で決まったことだと受け取ります（AIのハルシネーションの見抜き方｜開発現場で気づく型）。
- 関係の数が抜けている：「会社」と「担当者」が線でつながっているけれど、1つの会社に担当者が何人いるのか、担当者が2つの会社にまたがることはあるのかが書かれていない。ここは、あとでテーブル設計に直接響くところです（AIにDB設計を相談する｜前提の渡し方と鵜呑みにしない確認）。
- 「キャンセル」と「取消」と「返品」がひとまとめにされる：業務では、出荷前に止めるのか、出荷後に戻すのかで手続きがまったく違う。AIは似た言葉を「同じもの」としてまとめてしまうことがあります。
- 議事録をそのまま貼る：顧客企業の名前や、個人名が混じったまま渡してしまう（社内データをAIに渡す前の線引き｜情報漏えいを防ぐ型）。
- 用語集を作って満足する：きれいな一覧ができたけれど、関係者の誰にも見せていない。コードの名前もそのまま。そのうち、誰も開かなくなります。
影響——ずれは、作ったあとに見つかるほど直すのが大変になる
急いで全部を整理しないと大変、という話ではありません。ただ、時間がたつほど効いてくる種類の問題なので、書いておきます。
- 作り直しが起きる：「顧客」を個人だと思って作った画面を、会社単位に作り替える。画面だけでなく、テーブルや集計まで手が入ることがあります。
- 数字が合わなくなる：営業の「顧客数」と、システムの「顧客数」が合わない。どちらも間違っていないのに、会議のたびに説明が必要になります。
- テストが的外れになる：受け入れ条件に書いた言葉の意味がずれていると、テストは通るのに「これじゃない」と言われることになります（AIに受け入れ条件を言語化させる｜仕様の曖昧さを先に潰す）。
- AIへの指示もずれる：コードを書かせるときに「顧客」と書けば、AIはどちらかの意味で解釈します。言葉が揃っていないと、AIの出力も毎回違う方向にぶれます。
少し安心できる話をすると、この領域は小さく始められます。立派なモデリング手法を学ぶ必要はありません。1つの機能で使う言葉だけを拾って、ずれの候補を確かめる。それだけで、作り直しの芽をいくつか早めに摘めます。
明日からやること（拾う・突き合わせる・決める）
上から順に、小さく始められます。今日は①だけでも構いません。
1. 拾う——いま関わっている機能の文書から、業務の言葉を拾わせる
最初から会社全体の用語を整理しようとすると、終わりません。範囲を1つの機能に絞るのがコツです。
- 材料を集める。その機能の仕様書、チケット、打ち合わせの議事録、関係するテーブル定義やクラス名。完璧に揃っていなくて大丈夫です。2〜3種類あれば、ずれは見えてきます。
- 秘密の情報は伏せてから渡す。顧客企業の名前や個人名は、「取引先A」「担当者B」のように置き換えてから渡します。社内でAIに渡してよい範囲のルールがあれば、それに従います。
- AIに「業務の言葉」を一覧にしてもらう。名詞（顧客、注文、契約など）と、業務の動き（キャンセル、承認、締めなど）に分けて、どの文書のどこに出てきたかも添えてもらいます。
- コードの名前も並べてもらう。
user、account、customerなど、業務の言葉に対応しそうなコード上の名前を、候補として横に並べます。この時点では「対応しそう」で十分です。
2. 突き合わせる——ずれの候補を、質問の形で返させる
一覧ができたら、AIにずれていそうなところを探してもらいます。ポイントは、AIに答えを決めさせず、質問で返させることです。
- 「同じ言葉で違う意味」を探させる。「顧客」が、ある文書では会社、別の文書では個人として使われている、のような候補です。
- 「違う言葉で同じ意味」を探させる。「会員」「ユーザー」「アカウント」が同じものを指しているように見える、のような候補です。
- 関係の数を確かめる質問を出させる。「1つの取引先に担当者は何人いますか」「担当者が2つの取引先にまたがることはありますか」。ここはAIが推測で埋めやすいので、必ず質問として出してもらいます。
- 似た動きの違いを聞かせる。「キャンセル」と「取消」と「返品」は、いつ、誰が、何を戻す手続きなのか。違いがあるなら、それぞれ別の言葉として残します（AIを設計の壁打ち相手にする｜問いの立て方の型）。
3. 決める——人が意味を決め、関係者に確かめて、見える場所に置く
ここからは人の仕事です。AIが出した質問に答えながら、言葉の意味を決めていきます。
- 質問は、その業務をしている人に聞く。「顧客」の意味を開発チームだけで決めない。営業、サポート、経理など、その言葉を毎日使っている人に、短く確認します。質問の一覧をそのまま見せると、相手も答えやすくなります。
- 1つの言葉に1つの意味を決める。どうしても部署ごとに意味が違うなら、無理に1つにまとめず、「契約先」「問い合わせ者」のように言葉を分けるほうが、あとで迷いません。
- 用語集は短く、置き場所を決める。言葉、意味、使わない言い換え、対応するコードの名前、の4列くらいで十分です。リポジトリの中か、チームがいつも開く場所に置きます（AIにADRのドラフトを書かせる｜設計判断の「なぜ」を残す型）。
- コードの名前は、触るときに少しずつ揃える。いきなり全部を改名する必要はありません。新しく書くコードから用語集の言葉を使い、既存のコードは手を入れるついでに揃えていきます（「動くけど読めない」AI生成コードを保守可能にする手直し手順）。
- AIへの指示にも用語集を添える。コードを書かせるときに用語集を一緒に渡すと、AIの出力の言葉もぶれにくくなります（AIにコードを書かせる前に渡す前提と制約｜伝え方の型）。
AIに頼むときのプロンプト（コピーして使えます）
何も言わないと、AIは一般的な業務システムの形で空白を埋めてしまいます。材料にないことは決めないこと、ずれは質問で返すことを、最初に伝えるのがコツです。
下の材料をもとに、業務で使われている言葉の整理を手伝ってください。
①材料に出てくる業務の言葉（もの・人・業務の動き）を一覧にしてください。それぞれ、材料のどこに出てきたかを短く添えてください。
②材料の中で、同じ言葉が違う意味で使われていそうな箇所と、違う言葉が同じものを指していそうな箇所を、候補として挙げてください。
③言葉どうしの関係（例：1つのAに対してBはいくつあるか）は、材料に書かれていなければ推測せず、質問として挙げてください。
④どちらの意味が正しいかは決めないでください。一般的な業務システムの形で補うこともしないでください。
⑤最後に、業務の担当者に確認したい質問を、作り直しにつながりやすい順に10個まで挙げてください。
対象の機能：（ ） 材料（仕様書・チケット・議事録・テーブル定義など。社名・個人名は伏せる）：（ ）
質問に答えたあとは、こう続けます。
質問への答えを下に書きます。これを反映して、用語集（言葉／意味／使わない言い換え／対応するコードの名前）の表にしてください。私の答えにも材料にもないことは「要確認」のままにしてください。
④の「どちらが正しいかは決めない」が効きます。AIが決めた定義が、社内で決まったことのように残るのを防げます。
出てきた用語集は、次の3点だけ自分の目で確かめます。（1）材料にも自分の答えにもない定義が混じっていないか、（2）関係の数（1対多など）を推測で書いていないか、（3）「要確認」を推測のまま埋めていないか。
用語をAIと整理するチェックリスト（コピーして使えます）
全部に○が要るわけではありません。気になった行だけで十分です。
① 拾う
- 範囲を1つの機能に絞ったか
- 仕様書・チケット・議事録・テーブル定義などを2〜3種類集めたか
- 社名・個人名などは伏せてから渡したか
- 業務の言葉を、出てきた場所つきで一覧にしてもらったか
- 対応しそうなコード上の名前も並べてもらったか
② 突き合わせる
- 「同じ言葉で違う意味」の候補を挙げてもらったか
- 「違う言葉で同じ意味」の候補を挙げてもらったか
- 関係の数（1対多など）を推測させず、質問で出してもらったか
- 似た業務の動き（キャンセル・取消・返品など）の違いを確かめたか
③ 決める
- 言葉の意味を、その業務をしている人に確認したか
- 1つの言葉に1つの意味を決めたか（必要なら言葉を分けたか）
- 用語集をチームがいつも開く場所に置いたか
- 新しく書くコードから、用語集の言葉を使い始めたか
- AIにコードを書かせるとき、用語集を一緒に渡しているか
この記事のまとめ
用語のずれが起きるのは、誰かが間違えているからではなく、言葉がそれぞれの仕事に合わせて自然に育ち、文章の上ではずれが見えないからです。
やることは3つ。①拾う——1つの機能の文書から業務の言葉をAIに拾わせる。②突き合わせる——同じ言葉で違う意味、違う言葉で同じ意味の候補を、質問の形で返させる。③決める——その業務をしている人に確かめて意味を決め、用語集にしてコードの名前も少しずつ揃える。
AIに頼むときは、「どちらの意味が正しいかは決めないで」と一言添える。それだけで、AIの定義が社内の決まりのように残るのを防げます。
「そういう意味じゃなかった」と言われたとき、自分の聞き方が悪かったのかと落ち込んだかもしれません。でもそれは、あなたの理解が足りなかったからではなく、同じ言葉の中に、違う仕事の意味が重なっていただけです。
言葉を揃える仕事は、目立ちません。でも、営業とサポートと開発が同じものを指して話せるようになるのは、チームにとって大きな前進です。そのきっかけを作れるのは、両方の話を聞いて、実際に形にしている開発者だからこそです。
今日は、いま関わっている機能の仕様書を1つ、AIに渡してみる。返ってきた質問を1つだけ、その言葉を毎日使っている人に聞いてみてください。それだけで、次に作るものは、きっと少し「これこれ」に近づきます。
よければ、こちらも
- 完成の条件を言葉にするならAIに受け入れ条件を言語化させる｜仕様の曖昧さを先に潰す
- 整理した言葉をテーブルに落とすならAIにDB設計を相談する｜前提の渡し方と鵜呑みにしない確認
- 決めた理由を残すならAIにADRのドラフトを書かせる｜設計判断の「なぜ」を残す型
- 仕様書の叩き台は仕様書・設計書のドラフトをAIで作る｜叩き台の作り方と注意点
- 言葉の意味が分からない古いコードにはレガシーコードの仕様をAIに読み解かせる｜仕様復元の進め方
- 問いの立て方はAIを設計の壁打ち相手にする｜問いの立て方の型
- もっともらしい誤りへの備えはAIのハルシネーションの見抜き方｜開発現場で気づく型