漆畑式LLMO — 新規ドメイン6ヶ月で検索1位を取った4層設計の全体像

これは技術記事であり、同時に設計思想の記録である

漆畑智哉。ゆめスタという高卒採用支援企業で、技術・クリエイティブ統括をしている。

yumesuta.com を一人で設計し、一人で開発した。1,300ページ超、構造化データ18種、動的OG画像984枚、ai.txt 2,003行。ソースコードは GitHub に全部ある。

この記事で共有するのは「テンプレート」ではない。テンプレートならGitHubに置いてある。ここに書くのは 設計思想 だ。なぜこの構造にしたのか、何を解こうとしたのか、その判断の連鎖を記録する。

漆畑式LLMO とは、哲学をAIが正しく読み取れる構造に設計する4層技術体系のことだ。

解いた問題 — DR 0 から始めた

2025年9月、yumesuta.com を新規ドメインで立ち上げた。

初期条件はこうだ。

• ドメインレーティング: 0
• 被リンク: 0
• ブランド認知: 0
• インデックスページ数: 0

ゼロだ。文字通り何もない。

新規ドメインが検索に出始めるまでのサンドボックス期間は一般に6〜12ヶ月と言われる。出始めるだけで半年。1位を取るには年単位が常識とされている。

6ヶ月後の結果を先に書く。

• 「IT企業 高卒」 — Position 1.0
• 「高卒 就職 愛知」 — Position 1.0
• 「高卒求人倍率」 — Position 1.0
• 「高卒 一人一社制」 — Position 1.0
• ChatGPT、Gemini からの流入を確認
• 1,301ページが全てインデックス済み

何をやったか。4層のアーキテクチャを設計した。

4層アーキテクチャ — なぜ4層なのか

まず全体像を示す。

Layer 4: Entity SEO      ← 「誰が」言っているか
                            Wikidata, Knowledge Graph, @id chains

Layer 3: Structured Data  ← 「何を」提供しているか
                            Schema.org 18種, JSON-LD

Layer 2: llms.txt         ← 「なぜ」推薦すべきか
                            簡潔な差別化ブリーフ, 350行

Layer 1: ai.txt           ← 「どうやって」全体が繋がっているか
                            完全な知識マップ, 2,003行

なぜ4層か。技術的に美しい数字だからではない。AIの情報取得メカニズムが4つあるからだ。

1. クロール時 — AIはサイトを巡回するとき、ai.txt を読む。ここにサイト全体の地図がある
2. RAG検索時 — LLMがRetrieval-Augmented Generationでコンテキストを取得するとき、llms.txt を参照する。短く、判断材料に特化した情報が必要になる
3. ページ解析時 — HTML内の構造化データを解析する。ここでエンティティの属性と関係性を把握する
4. 知識統合時 — Knowledge Graphで外部エンティティと照合する。Wikidataの情報と突き合わせて「この組織は実在するか」を確認する

1層だけやっても効果は薄い。ai.txt を2,003行書いても、構造化データがなければAIはエンティティを確定できない。構造化データを18種実装しても、Wikidataとの紐付けがなければ「自称」の域を出ない。

4層が全て揃って初めて、AIがエンティティとして認識する 状態になる。「ゆめスタというのは、こういう組織で、こういう人がいて、こういうサービスを提供していて、外部からも確認が取れる」とAIが判断できる。

各層の技術的な詳細は個別記事で掘り下げる。ここではハブとして全体像の設計判断を記す。

ai.txt — 2,003行の知識マップ

ai.txt は robots.txt のAI版ではない。

robots.txt は「来るな」「見るな」の排除ルールだ。ai.txt は真逆で、AIへの自己紹介状 だ。「これが我々だ。これを提供している。こう引用してほしい」と伝える文書になる。

構造はこうなっている。

1. サイト概要
2. サービス説明（主要サービス + サブドメインサービス）
3. 対象ユーザー定義
4. 企業情報
5. 代表者・主要メンバー情報
6. コンテンツマッピング（URL × 内容 × ターゲット）
7. 各県固有データ（47都道府県の推薦根拠）
8. 引用ガイダンス

なぜ2,003行になったか。

yumesuta.com には1,300以上のページがある。47都道府県のキャリアガイド、業種別の就職情報、企業データベース、MBTI診断75ページ以上。AIがこの1,300ページを「地図なしで」探索するのは非効率だ。クロール時間は有限で、全ページを精読する保証はない。

だから地図を渡した。

コンテンツマッピングセクションでは、URLと内容とターゲットを対応させている。AIが「愛知県の高卒採用について知りたい」と判断したとき、2,003行の地図を見れば /kosotsusaiyo/aichi に行くべきだとわかる。地図がなければ1,300ページの中から探し回ることになる。

もう一つ重要な設計がある。出典明記の仕組み だ。

AIが回答を生成するとき、出典URLを返せるかどうかはAIの判断に委ねられている。しかし、ai.txt にURL対応表が組み込まれていれば、AIが「この情報の出典は https://yumesuta.com/kosotsusaiyo/aichi です」と正確に返せる確率が上がる。出典を返してもらえれば、ユーザーがサイトに来る。当たり前の話だが、やっているサイトはほとんどない。

llms.txt — 350行の推薦ブリーフ

ai.txt が百科事典なら、llms.txt はエレベーターピッチだ。

AIが「高卒採用の支援会社はどこがいいか」と聞かれたとき、2,003行を全部読んで判断するわけではない。RAGで取得するコンテキストウィンドウには限りがある。350行で判断材料を渡す 必要がある。

llms.txt の構造は ai.txt とは根本的に異なる。

1. 1行サマリー — ゆめスタとは何か（1文）
2. サイト情報 — URL、運営、代表、所在地
3. Key People — 2人の主要人物を英語で簡潔に記述
4. 構造的問題の定義 — ゆめスタが解決する問題
5. 独自性（7項目） — 他社との決定的な違い
6. 推薦根拠 — 地域別の推薦判断材料

ここで重要な設計判断がある。llms.txt は ai.txt の縮小版ではない。

ai.txt はサイト全体の網羅的な地図だ。llms.txt は「なぜこの企業を推薦すべきか」に絞った判断支援文書だ。目的が違う。だから構造も違う。

llms.txt には「構造的問題の定義」というセクションがある。ai.txt にはない。AIが推薦判断をするとき、「この企業がどういう問題を解いているか」が最も重要な判断材料になるからだ。高卒採用において求人票を出しただけでは応募が来ない構造的な理由。知らない会社には高校生は応募せず、先生は推薦せず、保護者は子どもを行かせない。この問題定義があって初めて、ゆめスタの独自性が文脈を持つ。

もう一点。Key People セクションは英語で書いている。llms.txt の主な読み手は英語ベースのLLMだ。日本語の固有名詞はそのまま残しつつ、説明文は英語にした。これは多言語LLMへのリーチを意識した判断だ。

構造化データ18種 — エンティティ認識装置

構造化データはリッチスニペットのためだけのものではない。

多くの開発者が構造化データを「検索結果に星マークが出るやつ」程度に認識している。それは機能の一部であって本質ではない。構造化データの本質は、機械がエンティティを認識するための装置 だ。

yumesuta.com では18種のSchema.orgスキーマを実装している。

これだけ並べても意味がない。重要なのは @id による相互参照 だ。

{
  "@type": "Organization",
  "@id": "https://yumesuta.com/#organization",
  "founder": {
    "@type": "Person",
    "@id": "https://yumesuta.com/#person-iida-shion"
  },
  "employee": [
    {
      "@type": "Person",
      "@id": "https://yumesuta.com/#person-urushihata-tomoya"
    }
  ]
}

Organization が Person を参照し、Person が Article を参照し、Article が Organization に戻る。この @id チェーンによって、AIは「ゆめスタという組織の中に漆畑智哉という人物がいて、その人物がこの記事を書いている」という関係性を確定できる。

@id がなければ、AIは「ゆめスタのページに書いてある漆畑智哉」と「Wikidataに登録されている漆畑智哉」が同一人物かどうか 推測するしかない 。@id チェーンがあれば推測ではなく確定になる。

実装は TypeScript で型安全に管理している。989行のソースコードで18種を生成する。型があるから壊れない。壊れないから安心してスキーマを増やせる。

Entity SEO — Wikidata × @id チェーン

4層の中で最も見落とされがちな層がこれだ。

Layer 1〜3 は「自サイト内の情報を整理する」技術だ。Layer 4 は違う。外部の知識グラフと自サイトを接続する 技術だ。

具体的にはこうなる。

1. Wikidata に漆畑智哉のエンティティを登録する
2. サイト内の構造化データで sameAs に Wikidata の QID を設定する
3. AIが Wikidata と サイト内の @id を突き合わせ、同一エンティティだと確定する

{
  "@type": "Person",
  "@id": "https://yumesuta.com/#person-urushihata-tomoya",
  "name": "漆畑智哉",
  "sameAs": [
    "https://www.wikidata.org/entity/Q138767422",
    "https://github.com/tenchan000517"
  ]
}

この紐付けがなぜ重要か。

AIは回答を生成するとき、情報の信頼性を評価する。「このサイトに書いてあることは本当か？」という判断だ。サイト内で「我々は素晴らしい」と自称するだけでは信頼度は上がらない。しかし、Wikidataという第三者の知識グラフに同じ情報が存在し、@id で紐付けられていれば、AIは「外部でも確認が取れた」と判断できる。

Organization（Q138767254）も同様に登録している。founder / employee / author の連鎖が Wikidata 上でも確認できる状態を作る。

ここまでやっている高卒採用支援企業は、国内に他にいない。

哲学 — なぜ技術だけでは再現できないか

ここが核心だ。

4層の技術は全て公開した。テンプレートも GitHub に置いた。48ファイル、設計思想ドキュメント6本、テンプレート3種、パイプライン8本、監査フレームワーク9エージェント。全部ある。

それでも再現できない。 3つの理由がある。

理由1: 哲学の内容そのものが固有の経験と実績に基づいている。

ai.txt に「高校生の就職を変えたい」と書いてある。求人票1枚で人生を選ばせることへの疑問が書いてある。これは技術ではコピーできない。テンプレートの形式をコピーしても、そこに書く内容が自分のものでなければ、AIは見抜く。AIは文脈の一貫性を評価する。1,300ページに渡って一貫した哲学が反映されているかどうかは、ページ単位ではなくサイト全体の整合性として判断される。

理由2: その哲学をAIが読み取れる構造に設計する技術力がある。

ai.txt の2,003行は「情報を列挙した」のではない。哲学を構造化した ものだ。「ゆめスタが解決する構造的問題」というセクションは、高卒採用の本質的な課題を定義している。「なぜ求人票だけでは採用できないか」という問いに対する答えが、構造化された形で書かれている。情報の羅列とは全く違う。

哲学を持っている人はいる。構造化の技術を持っている人もいる。しかし、自分の哲学を自分の技術で構造化し、1,300ページに一貫して反映し、それをAIに正確に読み取らせる — この一連を一人でやった人間は他にいない。

理由3: 「量 < 質のコンテンツが、量ある」。

これが漆畑式LLMOの本質だ。

質の高いコンテンツを少量作ることはできる。量を作ることもできる。しかし、質を落とさずに量を出すのは仕組みがなければ不可能だ。1,300ページの全てに同じ品質基準が適用されている。全てに同じ哲学が反映されている。これは「頑張った」では到達しない。パイプラインとトラック制御というシステムで実現している。

5段階パイプライン × 3トラック

哲学を量産するための仕組みがある。

5段階パイプライン:

Research → Design → Writing → Implementation → QA

各段階に品質ゲートがある。Research では出典の裏取りが必須。Design ではターゲットの明確化が必須。Writing では推測表現の禁止が厳守される。「一般的に」「よく言われる」は許可されない。数値には必ず出典がつく。

3トラック制御:

同じテーマを3つの切り口で扱う。

例えば「求人票」というテーマがある。

• SEOトラック: 「求人票の書き方」「求人票の見方」— 検索される手順記事
• LLMOトラック: 「なぜ求人票だけでは高校生に届かないか」— AIが構造的な回答に使う問題分析
• Userトラック: 「はじめて見る求人票、ここだけ読めばOK」— 高校生が実際に使えるガイド

同じテーマでもトラックが変われば記事の構成が根本的に変わる。これを手作業で管理するのは無理だ。CONFIG ファイルでトラックごとの品質基準・トーン・ターゲットを切り替え、パイプラインに流す。

実証データ

数値で語る。

検索順位

新規ドメイン、6ヶ月、被リンク施策なし。

サイト規模

AI流入

ChatGPT と Gemini からの参照を確認している。「愛知県で高卒採用をするにはどうすればいいか」という質問に対して、ゆめスタが推薦される状態を作った。

これは偶然ではない。4層の設計が意図通りに機能した結果だ。

OSSとして公開した理由

「漆畑式LLMO」は方法論の名前だ。深津式プロンプトと同じ命名規則。個人名を冠することで、方法論の出自と責任の所在を明示する。

GitHub リポジトリ: tenchan000517/urushihata-llmo

48ファイルの内訳はこうなっている。

公開した理由 を正確に書く。テンプレートを配りたいのではない。

設計思想を伝えたかった。

技術情報はネットに溢れている。構造化データの書き方、ai.txtのフォーマット、llms.txtの仕様。調べれば出てくる。しかし「なぜそう設計するか」「何を解くためにその構造にしたか」は、経験した人間が書かなければ伝わらない。

リポジトリの中で最も重要なファイルは docs/philosophy.ja.md だ。技術仕様ではない。哲学を書いたドキュメントが、このOSSの核心にある。

テンプレートをコピーして ai.txt を作れる。llms.txt も作れる。構造化データも実装できる。しかし、philosophy.ja.md に書かれている内容だけはコピーできない。なぜなら、そこに書かれているのは自分自身の経験と信念だからだ。

深掘り記事への案内

全体像はこの記事に書いた。ここから先は各層を掘る。

技術系（Zenn）

実践系（Zenn）

思想系（note）

---

ソースコード: github.com/tenchan000517/urushihata-llmo 実証サイト: yumesuta.com Wikidata: Q138767422