まずllms.txtが意味がないのは周知の事実として、
身のある話をしたいと思います。

と、こういうことをいうんでしょうが、
私の個人的な研究結果から現在わかっている答えを言います。

ずばり「AIってどういうルールで検索してるの？」に答えます。

例えば「転職サービスでおすすめの会社」のケースで話します。

GPTのような生成AIが「転職サービスでおすすめの会社」を探そうとする場合、単純に "転職サービス おすすめ 会社" という1つのキーワードで機械的に検索するわけではなく、意図を理解して複数の関連クエリに分解・変換して検索します。

---

じゃあ、どういう変換が起きるか

1. 表現のバリエーション展開

• 転職サービス おすすめ 会社
• 転職サイト 人気 ランキング
• 求人サービス 比較
• キャリア支援 企業 評判
• 就職エージェント 評判

→ 人間が自然に調べるときに使うであろう類似語・言い換えを広く検索。

---

2. 検索意図の分解

ユーザー意図は「転職支援を行う信頼できる会社を知りたい」なので、AIは以下のような意味分解をします：

• 転職サイト／求人サイト（doda、リクナビNEXTなど）
• 転職エージェント（リクルートエージェント、マイナビエージェントなど）
• 口コミ・評判（実際の利用者評価）
• 比較・ランキング記事（専門メディアの記事）

---

3. 情報の信頼性を補強する検索

• 「厚生労働省 転職 サービス 調査」
• 「転職サービス 利用者数 データ」
• 「大手転職サイト シェア」

→ 単に「おすすめ」という曖昧な表現だけでなく、統計・利用者数・公式資料など客観的な裏付け情報も探しに行く傾向があります。

---

4. 同義語・関連語をAIが自動展開

AIは検索前に 埋め込み（embedding） を作り、意味的に近い単語を広げます。
たとえば「転職サービス」→「求人サイト」「人材紹介会社」「キャリア支援」「リクルートサービス」など。
これにより単一の検索クエリよりもカバー範囲が広い検索が可能になります。

---

もっと専門的に解説します。

「GPT が“意図を理解して複数クエリへ言い換える”」ときの仕組み（ロジック）を、ソースで裏づける前提で設計図レベルまで分解することで真理に近づけてみます。

言い換え＝「クエリ拡張」を“ソース付き”でやる設計

1) 意図の分解（Intent → Slots）

• GPTは意図理解をしようとします: 「転職サービスでおすすめの会社」の意図
• スロット抽出をして分解します。
  • 領域/ドメイン＝「転職」
  • 対象エンティティ＝「サービス/会社」
  • 評価軸＝「おすすめ/人気/評判/ランキング」
  • 行為＝「比較/選定」
    → ここで “転職サイト/転職エージェント/人材紹介会社/求人サイト/ヘッドハンティング” などの候補カテゴリを洗い出します。

2) 言い換え候補の生成チャネル

必ず「候補ごとに根拠（source）」を付ける想定で、複数チャネルから候補を作ります。
言い換えの手法がいろいろあります。
それを使って言葉を入れ替えていきます。

1. 辞書・シソーラス系
   • 日本語WordNet、国語辞典、業界用語集など→同義語・上位語/下位語
   • 例: 「転職エージェント ≒ 人材紹介会社」
   • ソース例: 辞書定義、業界団体の用語集、（法令・ガイドラインがあれば最優先）
2. 法令・行政資料（業界語の正式対応）
   • 例: 職業安定法や厚労省ガイドラインの「職業紹介事業」定義⇔一般語「転職エージェント」
   • ソース: 該当法令・省庁PDF
3. コーパス統計（共起・PMI）
   • ニュース/信頼メディア/学術コーパスでの共起語や見出し表現
   • 例: 「評判」「口コミ」「満足度」「おすすめ」「人気」「ランキング」が「転職サービス」と高PMI
4. 埋め込み近傍（意味ベクトル）
   -（日本語SBERTや独自埋め込み）で意味距離の近い語を抽出
   • “転職サービス”→「求人サイト」「キャリア支援」「人材紹介」「ヘッドハンティング」など
5. パターン規則（言い換えテンプレ）
   • 「おすすめ→人気/評判が高い/満足度が高い」「会社→事業者/提供企業」「比較→ランキング/一覧」
   • 形態素（MeCab/Sudachi）で品詞を見て置換
6. 翻訳ピボット（多言語）
   • ja→en→ja で安定に戻る表現群（“recruitment agency”, “job board”, “headhunter”, “placement firm”…）
   • ソース: 対訳辞書/用例コーパス

重要：候補がどのチャネルから来たかをメタデータ化し、あとでスコアと一緒にログ保存します。

3) エビデンス（ソース）付与と検証

候補語ごとに最低1つ以上のソースを紐づけ、意味同値/言い換え妥当性を検証します。

• 定義整合：辞書/法令定義と一致（最強ソース）
• 文脈整合：信頼サイト本文で「A と B を同義に用いている用例」を抽出
• NLI（自然言語推論）：A→B、B→A が相互含意（entailment）かを確率判定
• 統計裏付け：高PMI・高共起の確認
• ブランド写像：一般語⇔固有名詞（「転職サイト」⇔doda/リクナビNEXT など）をカテゴリ定義記事で裏づけ

スコア例（重みは運用で学習）

score = 0.35 * cosine(emb(A), emb(B))
      + 0.25 * PMI(A,B)
      + 0.25 * NLI_bidirectional(A,B)
      + 0.10 * DefMatch(A,B)     # 定義一致/類似度
      + 0.05 * SourceTrust       # 出典の信頼度(法令>政府>学会>新聞>企業サイト…)

• 閾値：score ≥ τ、かつ「法令・辞書ソース」または「相互含意+高PMI」を満たす、等。

4) 重複排除と多様化（MMR）

• 類似候補はクラスタリング（embeddings）で代表表現を選定
• 検索ポートフォリオは MMR（最大限マージナルリレバンス）で多様化
  • 例：
    • 「転職サイト 人気 ランキング」
    • 「人材紹介会社 比較 評判」
    • 「転職エージェント 満足度 調査」
    • 「ヘッドハンティング 会社 口コミ」
    • 「利用者数 統計 転職サービス」

5) 実行時の検索クエリ生成（“ソース前提”）

各クエリはソース種類も意識して組む：

• 「site:go.jp」「site.mhlw.go.jp」→行政資料
• 「site:or.jp / 学会誌 / 白書」→統計・定義
• 「news 大手メディア」→時事・調査
• 「site:company.example 事業概要」→固有名詞の正確性
• 期間・地域・言語フィルタを明示（日本/直近12–24か月 など）

6) ログと再学習

• 候補ごとの {表現, ソースURL/書誌, スコア, 採否, 成果(CTR/精度)} を保存
• 次回以降、CTRやNLI誤判定のオンライン学習で重み最適化

---

今回のケースに当てはめた候補（設計テンプレ）

意図：「転職サービスでおすすめの会社」

カテゴリ言い換え（要ソース）

• 転職サービス ≒ 転職サイト（一般語/メディア用語）
• 転職サービス ≒ 人材紹介会社（法令上の「職業紹介事業」）
• 転職サービス ≒ 転職エージェント（俗称→行政定義にマップ）
• 関連：求人サイト / キャリア支援サービス / ヘッドハンティング会社

評価軸言い換え（辞書・用例・統計で裏づけ）

• おすすめ → 人気 / 評判 / 満足度 / 口コミが高評価 / ランキング上位
• 会社 → 事業者 / 提供企業 / サービス

サンプル出力（保存レコードの形）

[
  {
    "phrase": "転職エージェント",
    "maps_to": "人材紹介会社(職業紹介事業)",
    "evidence": [
      {"type": "law/gov", "title": "職業紹介事業の定義", "url": "（厚労省の該当ページURL）"}
    ],
    "scores": {"embed": 0.89, "pmi": 0.72, "nli_bi": 0.93, "def": 0.95, "trust": 0.98},
    "approved": true
  },
  {
    "phrase": "転職サイト",
    "maps_to": "求人広告媒体型サービス",
    "evidence": [
      {"type": "dictionary", "title": "求人サイトの定義", "url": "（辞書/業界団体のURL）"},
      {"type": "media", "title": "利用者数・市場説明", "url": "（白書/調査レポートURL）"}
    ],
    "scores": {"embed": 0.84, "pmi": 0.69, "nli_bi": 0.88, "def": 0.80, "trust": 0.85},
    "approved": true
  }
]

みたいな感じです。
とてもわかりやすいですよね。
評価項で分解して、言い換えのロジックを展開して、重み付けして
最適解の組み合わせを統計的にとっている、それだけです。

---

疑似コード（最小構成）

intent = parse_intent(user_query)                  # "転職, おすすめ, 会社"
slots  = extract_slots(intent)

cands = []
cands += lexicon_synonyms(slots)                   # WordNet/用語集
cands += law_mappings(slots)                       # 行政・法令用語マップ
cands += corpus_cooc(slots)                        # PMI/共起
cands += embed_neighbors(slots)                    # 埋め込み近傍
cands += pattern_rules(slots)                      # 「おすすめ→人気/評判…」
cands += pivot_translate(slots)                    # ja↔en ピボット

cands = dedupe_cluster(cands)

for c in cands:
    ev = []
    ev += fetch_defs(c)                            # 辞書/用語集
    ev += fetch_gov(c)                             # 行政資料
    ev += find_parallel_usage(c)                   # 同義用例
    nli = nli_bidirectional(slots.core_term, c)    # 相互含意
    score = combine_scores(c, ev, nli)
    approve = (score >= THRESHOLD and has_strong_source(ev))
    save_record(c, ev, score, approve)

portfolio = diversify_mmr([c for c in cands if c.approve])
queries = build_queries(portfolio, source_filters=True)  # gov/news/辞書/企業サイト等に分散

---

AIサーチのチェックリスト

• 定義ソース（辞書/法令/行政）で言い換えの同値性が担保できる
• 文脈ソース（信頼メディア/白書）に同義使用の実例がある
• NLI/PMI/埋め込みで意味距離が十分近い
• ログに URL とスコアが残る（監査可能）
• 検索先ごとにクエリを用意（gov/news/review/corp）
• MMRでクエリが重複・偏在しない

つまり、
高速で、各理論でサポートされる言い換え展開で、
各ドメインに各テーマの記事を作りまくる必要がでてきます。

そんなことをやるのは経済合理性が合わない。

そこでステルマッハ弊社のサービスです。
１ブログ１０００記事でも一瞬で作れますので、
評価言い換えごとのサイトをバンバン作っていけばAIをハックできます。