NexaScience

name-candidate-generator

AI/テック系のサービス名・プロダクト名・ブランド名の候補を、命名技法(造語・音象徴・語根・接尾辞パターン等)を 使って多数生成し、読み(カナ)・由来・タイプ付きの構造化リストで返すスキル。 ユーザーが「名前を考えて/出して/生成して」「ネーミング」「サービス名/プロダクト名/ブランド名の候補を出して」「命名」「名前案」 「いい名前ない?」など “まだ候補を作る” 段階の依頼をしたら必ずこのスキルを使う。 これは“生成”専用。商標/ドメイン/SNSの空き調査はしない(「使えるか調べて」「空き確認」「商標チェック」は brand-name-availability スキルの役割)。 生成後は人間がショートリストを選び、その後 brand-name-availability で調査する流れ。

NexaScience 0 Updated 1mo ago

Resources

1
GitHub

Install

npx skillscat add nexascience/name-candidate-generator

Install via the SkillsCat registry.

SKILL.md

ネーミング候補ジェネレーター(AI/テック向け)

サービス/プロダクトの名前候補を多数出すスキル。1案に賭けず15〜25個を幅広い切り口で生成し、
人間が選びやすいよう構造化リストで渡す。空き調査(商標/ドメイン/SNS)はここではやらない(責務分離)。

入力を確認する(揃っていなければ短く聞く)

  • 何のサービスか(1〜2行。何をする、誰向け)
  • トーン/イメージ(例: 力強い/知的/やわらかい/未来的/信頼感)
  • 避けたい語・既存名(競合名、社内で却下済みの案、入れたい/外したいキーワード)
  • 主な市場・言語(日本中心か、グローバルか。読みの基準になる)
  • 任意: 文字数・音節数の好み、.ai/.io狙いなど(短さの基準)

足りなくてもまず叩き台を出してから詰めてよい(生成は安いので、対話で収束させる)。

最重要原則: 「ありそうでない造語」を狙う

候補は**“実在しそうなのに実在しない単語”**にする。ランダムな文字列に見えるものはNG。

  • ✅ 良い: 発音できて綴りも自然で、英語/ラテン語根の手触りがある疑似単語(例の質感: Verluna, Kintava, Soluvio)。
    初見で1通りに読めて、「どこかの言語の普通名詞かも」と思える滑らかさ。
  • ❌ 悪い: 子音が連続して読めない / 母音が無い / キーボードを叩いたような無意味列(例: Lnar, Xqzy, Vbrtk)。
    ※元の Lnar が読みづらい(L+n)のはこの失敗例。母音を入れて発音可能にする。
  • 判定の目安: 声に出して一発で読めるか。読めなければ却下。語根や音の連想で意味のかけらが宿るとなお良い。
  • 読みやすさは必須(客観): 子音クラスタ・濁音連続・難読な音写は却下(例: 「コンドゥヴァ」「Lj-」はNG)。
    英語話者・日本語話者の双方が一読で読めることを必須にする。
  • 美しさ・好みでは生成段階で落としすぎない(主観): 「心地よい響き」はモデルの主観で実ユーザーと外れやすい。
    流音・開母音を意識はするが、美観を理由に幅を削らず多めに出し、最終的な響きの好みは人間に選ばせる
    say等の音声合成は実行者が音を聞けず無意味なので使わない。)
  • 語尾・音形に多様性を持たせる(重要): 候補リスト全体で同じ語尾に偏らせない
    特に -ra / -va / -o に集中しがちなので意識的に散らす。
    • 語尾を分散: -en, -el, -on, -in, -is, -us/-os, -or, -an, -a, -o, -yn などを混ぜ、同じ語尾は最大2件まで
    • 母音終わり/子音終わり、2音節/3音節も混ぜる。似た響きの語ばかりにしない。
  • 近すぎる既存名も避ける(厳格・基準を緩めない): 既存のAI/テックサービスと綴り・響きが近いものは生成段階で外す
    (例: veldervelerin / LnarLunar.dev / ReedmereReed.ai / BolsenaBolna はNG)。
    • 「完全一致」でなくても、語頭・語幹・リズムが近いAIサービスが1つでもあれば除外
      "やや近い(△)"を「許容」して通してはいけない。△は通さない=実質✕扱い
    • 理由: 近い音を残すと、後の本調査や市場投入で大きな手戻りになる。最初から弾くのが安い。
    • 最終的な実在/商標確認は brand-name-availability に委ねるが、少しでも似ている語は出さない

独特性: 「混んでいるゾーン」を避ける(経験則・重要)

短く綺麗な造語ほど既に取られている。実測で「5文字前後・単一ラテン語根の造語」は AI 商標/サービスと猛烈に競合した
(ある回は16件中13件が衝突。Solis→NVIDIA ORIN系/Solis AI、Lumel→Lumel社、Auro→Auro.AI 等)。被りを減らすには:

  • 飽和した語根・接頭辞を避ける: sol, lumen/lumi, nova, aur/oryn, nex/nexus, helio, luna, kine, ai-, neo, syn などは皆が使う。
    これらに寄せると確実に混む。もっと珍しい語根(古語・神話・地学・植物・楽器・職人技 等)から取る。
  • 少し長く・二語結合で固有性を上げる: 4〜5文字の単音より、6〜9文字/2語根の結合の方が空いている。
    ただし読みやすさ(一読で読める)は死守する。長くても言いやすければ可。
  • 音の組み合わせに“引っかかり”を作る: ありふれた Co-/Ve-/Lu-/Au- 始まりに偏らせず、子音の選び方で独自の手触りを出す。
  • 目安: 候補を見て「いかにもAIスタートアップにありそう」と感じたら、それは既に在る可能性が高い。半歩ずらす。

飽和の実態と対策(実測の学び・必読)

AI命名空間は異常に飽和している。実測で、ラテン語根の綺麗な造語は1バッチ14件が全滅したこともある
(Veylan/Zephyr AI/Tavro.ai/Calden/Orenza/Mavon… と同名・同音が次々ヒット)。短く綺麗=ほぼ取られている。

  • 飽和した語幹・語尾を避ける(同音の既存AI社が密集):
    • 語幹: Cal-, Orv-, Tav-, Niv-, Mav-, Val-, Vel-, Vei-, Zeph-, Lum-, Sol-, Aur-, Nex-, Sev-
    • 語尾: -len, -lan, -valen, -ven, -eon, -eo, -en は飽和気味。-on/-ar/-is/-yn/-ix/-a 等へ散らす。
  • 未開拓な音源から取る(ラテン/ギリシャは掘り尽くされ気味):
    日本語・フィンランド語・ウェールズ語・サンスクリット・トルコ語・ハワイ語などの語根や、
    職人技・地学・植物・楽器・神話のマイナー語。英語圏のAI企業が手を付けていない音は衝突が少ない。
  • 数で当てる: 1バッチ十数件では全滅しうる。多めに生成→実在+音被りを一括スクリーニング→生き残りだけ提示、を前提にする
    (少数の生き残りを得るのに大きめのプールが要る、と織り込む)。

生成方針(AI/テックでよく効く技法)

上の「ありそうでない造語」を満たす前提で、幅を出すため複数の技法を混ぜて候補を作る:

  1. 2語融合(portmanteau)— 1単語に溶かす。これが本命の技法。
    • 2つの語を融合させて“1つの新しい単語”にする。例: fire+base→Firebase / super+base→Supabase /
      net+simplify→Netlify / mail+chimp→Mailchimp。読むと1語に見える・聞こえる。
    • 滑らかに繋ぐ: 境目で音を重ねる/1字省く(elision/overlap)と自然になる(例: super+baseで重なるr/bをうまく繋ぐ)。
      ただゴツく2語を貼っただけ(例: 〇〇+〇〇が不自然に分かれて聞こえる)はNG。
    • NG(やってはいけない): Lunar AI のような2単語に並べる形、Lunar Baseのようなスペース区切り、〇〇+AI/Labs/HQの付け足し。
      必ず融合した1トークンにする。空白・大文字2つ(CamelCaseでもブランドはOKだが)で“2語感”が残るものは避ける。
    • 素材語根: ラテン/ギリシャ+実在英短語(nexus, aether, cogni, vox, arc 等は飽和注意。地形/自然/織り/光/動き の短語を組むと空きやすい)。
  2. 音象徴(sound symbolism) — 響きで印象を作る。
    • 破裂音(k/t/p/b/d/g)=力強い・技術的、流音(l/m/n/r)=滑らか・知的、母音多め=やわらかい。
    • 2〜3音節・初見で読める綴りを優先(人工的すぎる子音連続は避ける)。
  3. メタファー/連想 — AIの価値を象徴する語: 速度・知能・光・接続・成長・基盤・実行。
  4. 「悪い意味のない実在語」の転用(モノ・地名・現象 等/中立〜好印象・AIで未使用が多い・最有力) ★並列で必ず使う
    • AI/ITと無関係で、元の意味が中立〜ポジティブな実在語を、そのまま or 少し美しくひねった造語にして候補にする。
    • 対象は具体物に限らず広く取る:
      • モノ: ランプ/照明、布・織物・編み・刺繍・レースのパターン名、家具・椅子型、陶器・器・茶器・花瓶、道具・工具、
        結び目・ロープ・船具、植物・ハーブ・花・果実・木、宝石・鉱物、楽器・楽器部品、建築部材、文具・製本、菓子。
      • 地名: 小さな町・村・谷・湖・河川・島・峠など(世界的に超有名でないもの)。
      • 現象・自然: 気象・光学・天文・地学などの現象名(中立で美しいもの)。
    • これらが良いのは (1)覚えやすい (2)悪い意味が無い (3)AIスタートアップにまだ使われていないことが多い、の3拍子(例: Coniston)。
    • そのままでも、少しだけ綴り/音をひねった造語でもよい(読みやすさは維持。ひねると固有性が上がる)。
    • 集めるコツ: 「○○ types / ○○ patterns / named ○○ / list of ○○」(lamp types, fabric weaves, knot names, minor towns, optical phenomena…)で
      固有名・型名を多数列挙 → 読みやすく・中立〜好印象・短め(2〜3音節)を抜き、そのまま/微修正して候補化。
    • 除外: 元の意味が否定的・きな臭い・きわどいもの(武器・病気・毒・蔑称由来等)/世界的に超有名で強く占有された語(Amazon, Sahara, Tokyo 級)。
    • 素検索の扱い: その語の“元の意味”(モノ/地名/現象)がSERPに出るのは問題なし=中立
      失格にするのは ①AI/テック/競合企業がヒット ②世界的超有名で混同される、の2つだけ。
  5. 実在語の転用(一般) — 上記以外の普通名詞も別ドメインに転用(自然・天体・神話・幾何 等)。
  6. 接尾辞でテック感-ai, -labs, -mind, -flow, -scale, -base, -stack, -grid 等(飽和気味なので使いすぎ注意)。
  7. 頭字語/イニシャル — 事業フレーズの頭文字を読みやすい綴りに整える。

生成時の自己フィルタ(軽い事前チェック。本調査ではない)

候補を出す前に、最低限こちらで篩って“当たり”を増やす(手戻り削減)。ただし正式な可否判断はしない(それはB)。

  • 軽い実在チェック(推奨・追加): 最終候補を WebSearch で軽く素引きし、明白な衝突は出力前に外す:
    • 素の検索: <候補> 単体/<候補> 意味 で、既に有名な企業・ブランド・別の強い意味に占有されていないか。
    • AI同分野: "<候補>" AI で同名サービスが一発で出ないか。
    • 音被り: 近綴り/同音の変種を2〜3個(語幹共有・母音1つ違い)も "<変種>" AI で当て、Skyford→Skyfire/Skyflow 型を避ける。
      深追いはしない(網羅的な商標/ドメイン/音被り確認はBの段1へ)。これで「大半が衝突」を避ける。
  • 読みやすさ: 初見で発音が割れないか。口頭でドメインを伝えられるか。
  • 被り感: 明らかな大手既存名・一般名詞すぎる語・飽和語根は避ける。
  • 語感: ぱっと見で他言語の悪い意味を連想しないか(厳密チェックはBの語感軸へ)。
  • .ai/.io狙いでも、短さより固有性を優先(短い綺麗語は取られている。6〜9文字で言いやすければ可)。

自己フィルタは“当たり”を増やす軽い配慮。正式な可否判断はしない。最終確認はB+弁理士。

出力フォーマット

3カテゴリ程度に分け、各候補を表で。読み(カナ)は後段の商標称呼検索に必須なので必ず付ける。

### 造語・語根系
| 候補 | 読み(カナ) | 由来・意味 | 狙い/トーン |
|------|-----------|-----------|-----------|
| Lumina | ルミナ | lumen(光)+-a | 知性・明るさ |

### メタファー系
| 候補 | 読み(カナ) | 由来・意味 | 狙い/トーン |
...

### 短い/ドメイン向き
| 候補 | 読み(カナ) | 由来・意味 | 狙い/トーン |
...

末尾に、生成側として特に推せる3〜5案のおすすめを理由付きで添える(参考。最終選択は調査後に人間が行う)。

次の工程(全候補を調査へ → 調査後に人間が選ぶ)

このスキルは生成で完結する。空き調査はしない。

重要(順序): 生成後に人間へショートリストを求めない。理由は手戻り防止 ——
人間が選んだ後に「全部ドメイン取得不可/商標衝突」だと選び直しが大量発生する。
正しい順序は 生成 → (brand-name-availability が)自動で空き調査 → 生き残りだけ人間に提示 → 人間が選ぶ
つまり人間が選ぶのは調査の後。このスキルは生成した全候補(15〜25件)をそのまま調査へ渡す

  • 引き渡し形式(そのまま brand-name-availability に渡せる形。生成時に得た情報を落とさない):
    • 候補: [{name: "Lumina", kana: "ルミナ"}, ...]全候補。絞らない)
    • 併せて、判明していれば 事業分野(区分の手掛かり)/ 狙いTLD(.ai/.io等)も添える → B側の再質問を防ぐ。
  • 連携の段取り(生成→自動調査→人間が選ぶ)はメインエージェント/CLAUDE.md側が管理する。
    このスキルからB側の判断を先取りしない(責務分離)。
  • 末尾のショートリスト案は「生成側のおすすめ」を示す参考であり、人間の最終選択は調査後に行う(ここでは確定させない)。

注意

  • 1案に絞らない。幅(技法の多様性)を優先し、似た語ばかりにしない。
  • 読み(カナ)を必ず付ける(Bの商標称呼検索で使う)。
  • 生成は安い。ブリーフが曖昧でも叩き台→対話で収束、を優先する。
  • 商標/ドメイン/SNSの「空いている」断定はしない。確認はBスキル+最終は弁理士。

Categories