800のウェブサイトを、どのモデルに任せるか

1ドメイン、1モデル

40セルから、1つのモデル名へ

出典：talk/methodology.py（harness/config.json から生成）。

_shared全段階に共通の前文

全モデル・全呼び出しの冒頭にそのまま付与されます。仕事の定義、違反すればビルドが即失格になる5つの機械的制約、そしてこの講演全体が旋回する一文——公開前に、その出力を検査する者はいないと考えよ——を述べています。

# Shared preamble — prepended verbatim to every stage, for every model

**FROZEN once the first production run starts. Identical for all contestants.**

---

You are building a small, genuinely useful website for a domain that is currently for
sale. The site's job is to make the domain worth more: real topical content that can rank
in search and be cited by answer engines. It is not a parked page, not a placeholder, and
not a template fill.

The domain owner has roughly 800 such domains and will run this same process on all of
them without reviewing each result. Assume nobody will inspect your output before it goes
live. Build accordingly.

## Hard constraints

These are checked mechanically. Violating any of them fails the build outright.

1. **At most 5 pages.** Fewer is fine if fewer is right.
2. **At most 1 image per page.** Five images total, maximum.
3. **Word and character bands** — every page must fall inside the band for its declared
   page type. Under the floor is thin content; over the ceiling is padding. Both fail.

   | Page type | EN words | JA characters |
   |---|---|---|
   | homepage | 500 – 1,000 | 1,000 – 2,000 |
   | service | 800 – 1,600 | 1,600 – 3,200 |
   | landing | 600 – 1,200 | 1,200 – 2,400 |
   | category | 400 – 800 | 800 – 1,600 |
   | about | 400 – 800 | 800 – 1,600 |
   | faq | 800 – 1,600 | 1,600 – 3,200 |
   | blog | 1,500 – 3,000 | 3,000 – 6,000 |

4. **Every page must be uniquely valuable.** Not the same page with the nouns swapped.
   Google's doorway-page algorithm exists and this owner has 800 domains — near-duplicate
   pages get the whole portfolio deindexed.
5. **The shared floor is fixed.** `base.css` is linked, never modified, never inlined.

## Output

Return **only** valid JSON matching the schema given for your stage. No prose outside the
JSON, no markdown fences, no commentary.

s1-conceptコンセプトとキーワード

入力はドメイン名と生成言語だけ。指示書も市場調査もありません。サイトが何であるべきかを導き出すこと自体が仕事であり、名前が曖昧ならそう認めたうえで判断を下すことが評価されます。

# S1 · Concept & keyword architecture

## Input
    domain:         {{DOMAIN}}
    build_language: {{BUILD_LANGUAGE}}     # en | ja — fixed, applies to the whole site

That is all you get. No brief, no market research, no instructions about what the site
should be about. Deriving that is the job.

`build_language` is settled and not yours to change — plan the sitemap, slugs and working
titles in it from the start. You are still asked below what language you *would* have
chosen; say so plainly even when it differs, and then plan in the language given.

## What to do

**1. Read the domain.** What does this name imply? What would someone typing it expect?
What would a buyer of this domain want to own? Be honest when a domain is ambiguous or
carries little meaning — say so, and then make a defensible choice anyway.

**2. Consider the TLD.** It is part of the name and it carries information. Reason about
what it implies for audience, market and language, and state your reasoning. If it points
somewhere the rest of the name does not, say what you would do about it. Name the language
you would have picked and why — disagreeing with `build_language` is a legitimate answer
and is scored on the quality of the argument, not on agreement.

**3. Design the site.** Concept, audience, and a sitemap of at most five pages. Every page
needs a distinct job and a declared page type from the table in the preamble. Do not pad
to five.

**4. Keyword architecture.** Clusters, not a keyword list. For each cluster: a primary
term, secondary and semantic variations, the search intent behind it, and which page owns
it. Every page in the sitemap must own exactly one cluster.

## What is being judged

Whether you read the domain correctly and designed a site worth building — coherence,
commercial realism, keyword and intent coverage, sitemap logic, and the quality of your
reasoning about the TLD. Everything downstream is built on this, so a weak concept costs
you four times over.

s2-designデザイン方針

配色、書体、ページごとのセクション構成、画像指示書。「お決まりの見た目に手を伸ばすな」——クリーム色の背景、テラコッタのアクセント、セリフの見出し——という指示が入っているのは、全モデルがすでにそこへ収束していたからです。

# S2 · Design direction & image manifest

## Input
    domain:         {{DOMAIN}}
    build_language: {{BUILD_LANGUAGE}}     # en | ja — final, not a suggestion
    s1:             {{S1_JSON}}

`build_language` is the language the site will be written in. It may differ from what you
recommended in S1; it is fixed now and applies to all page copy, headings, alt text and
metadata.

**If it differs from your S1 recommendation, commit to it fully.** Page slugs, working
titles and section names all follow `build_language` — an English site with romanised
Japanese slugs is worse than either language done properly. Rename anything from S1 that
no longer fits and note the corrected slugs in your page layouts.

## The shared floor

Every contestant links the same `base.css`. It provides a reset, a fluid type scale
(`--step--1` … `--step-5`), a spacing scale (`--space-3xs` … `--space-3xl`), and layout
primitives: `.container`, `.stack` / `.stack-m` / `.stack-l`, `.prose`, `.section`,
`.grid`, `.cluster`, `.switcher`, `.center`, `.visually-hidden`, `.skip-link`.

It sets **no palette, no typeface, no section layout, and no page structure.** Those are
yours, and they are the thing being judged. The fallback palette is pure black on pure
white with no accent — if you skip it, the site looks exactly as unconsidered as it is.

## What to do

**1. Design rationale.** Two or three sentences: what this site should feel like and why
that suits this subject and audience. Not adjectives — an argument.

**2. Palette.** Concrete hex values for all seven `--c-*` tokens. Must pass WCAG AA for
body text on background.

**Do not reach for the house style.** Language models converge hard on one look: a warm
cream background around `#FBF7F0`, a serif display face, and a terracotta or amber accent.
Measured across five models from four different companies on this exact task, every one
produced that palette and every one chose the same typeface. It is the most recognisable
signature of a generated website, and a buyer who has seen two of them recognises the
third.

Derive the palette and the type from **this** subject and **this** audience. If your first
instinct is cream-and-terracotta with a serif display, that is your first instinct, not
your best one — justify it against the subject or choose again. A B2B industrial site, a
health reference and a destination guide should not arrive at the same colours.

**3. Typography.** Heading and body stacks. Google Fonts is permitted via a single
stylesheet link; if you use it, name the exact families and weights. System stacks are a
legitimate choice, not a cop-out — Japanese builds especially.

**4. Section plan per page.** For each page in the sitemap, the ordered sections and what
each is for. This is where design variance actually lives: what a page is made of and in
what order.

**5. Image manifest.** **At most one image per page, five total.** Fewer is a valid
choice. Every image is generated by the same fixed image model at the same settings for
every contestant, so image *quality* is a constant — what is judged is your art
direction: subject choice, prompt quality, placement, and alt text.

**Every image comes back as a 1024×1024 PNG.** The image model ignores size and aspect
requests, so design for square and crop with CSS if you want something else. A layout that
assumes a wide hero will break.

Alt text is written in `build_language` and does real SEO work. Do not describe the
image; say what it contributes.

## What is being judged

The rendered result, scored from desktop and mobile screenshots, plus art direction. Your
rationale here is read as evidence of intent.

s3-buildHTML5ページ

本文・デザイン・内部SEOを1つの応答で、完成HTMLとして出させます。後から直す工程は存在しません。予算切れの失敗は、すべてこの段階で起きました。

# S3 · Build

## Input
    domain:         {{DOMAIN}}
    build_language: {{BUILD_LANGUAGE}}
    s1:             {{S1_JSON}}
    s2:             {{S2_JSON}}

## What to do

Emit the **complete, final HTML for every page** in the sitemap. Content, design and
on-page SEO all at once — there is no later pass to fix things in. Write it correctly the
first time.

Each page conforms to the contract in `page.html`:

- `<html lang>` matches `build_language`
- `<title>` 50–60 characters, unique across the site, primary keyword present
- `<meta name="description">` 150–160 characters, written to earn a click
- self-referencing absolute `<link rel="canonical">`
- Open Graph: `og:title`, `og:description`, `og:type`, `og:url`, `og:image`
- exactly one JSON-LD block; the `@type` is your choice and should suit the page
- `<link rel="stylesheet" href="base.css">` — never modified, never inlined
- one `<style>` block implementing your S2 palette and typography; the seven `--c-*`
  tokens must all be defined
- `<a class="skip-link">`, `<header>`, `<main id="main">`, `<footer>`
- exactly one `<h1>` inside `<main>`; heading levels never skipped
- images referenced at `images/<filename>` exactly as named in your S2 manifest

## On-page craft — how to write for search

Follow these while writing, not afterwards.

**Structure carries intent.** Headings are a map of the page, not decoration. Each H2
answers a distinct question a searcher actually has. If a heading could sit on any page
about anything, it is doing no work.

**Answer first.** Open every section with a direct, self-contained answer in one or two
sentences, then expand. A passage lifted out of context must still make sense and still
be attributable — that is what makes it quotable by an answer engine.

**Keywords are placed, not sprinkled.** Primary term in the title, the H1, the first
hundred words, and naturally thereafter. Semantic and related variations throughout.
Density in the 1–3% range. Anything that reads as stuffing has failed twice: once with the
reader, once with the ranking.

**Specific beats true.** "Athens has a rich history" is true and worthless. Numbers,
names, dates, prices, comparisons, trade-offs, and things only someone who knows the
subject would think to mention. Generic truth is the signature of generated content, and
it is what a reader detects before they can name it.

**Show experience and be checkable.** Concrete detail, honest limitations, and outbound
links to genuinely authoritative sources where a claim needs backing. Never invent a
statistic, a citation, a review, or a credential. On health, legal, safety or financial
subjects, be conservative and say what you do not know — a confident wrong answer is a
liability, not a style problem.

**Scannable and readable.** Short paragraphs. Lists and tables where the content is
genuinely a list or a table, never to fill space. Plain sentences.

**Link with intent.** Body-copy links to other pages on this site using descriptive anchor
text — never "click here", never the bare page title every time. Every page reachable from
the navigation. No orphans.

**Every page must earn its own existence.** If two pages could be swapped by changing a
few nouns, you have built a doorway network and this site is worthless to its owner.

**Stay inside the word band for the declared page type.** Under the floor is thin; over
the ceiling is padding. Both fail mechanically, so count.

## What is being judged

The rendered pages (design), the prose (is this worth reading, is it specific, does it
read as written rather than generated), and the on-page SEO. Reliability counts as much as
quality: a page that fails to parse scores nothing at all.

s4-selfaudit自分の仕事を採点する

いま作ったものを監査し、違反を正直に報告させます。修正はさせません。評価されるのは、自己申告が決定的なゲートの検出結果と一致するかどうかです。3つのゲートに不合格なのに「問題なし」と報告するモデルは、いくら安くても無人では回せません。

# S4 · Self-audit and site artifacts

## Input
    domain:         {{DOMAIN}}
    build_language: {{BUILD_LANGUAGE}}
    s1:             {{S1_JSON}}
    s2:             {{S2_JSON}}
    s3:             {{S3_JSON}}

## What to do

**1. Audit your own work.** Go back over what you just built and check it against the hard
constraints and the page contract. Report what you find — honestly.

Nobody is going to review these sites before they go live. The owner is running this
process 800 times unattended. Your self-report is the only signal available that something
went wrong, so its value depends entirely on it being accurate.

Check at minimum:

- page count ≤ 5, and images ≤ 1 per page, ≤ 5 total
- every page inside the word or character band for its declared page type — **count, do
  not estimate**
- exactly one `<h1>` per page, no skipped heading levels
- title lengths 50–60, meta descriptions 150–160
- all seven `--c-*` tokens defined; `base.css` linked and unmodified
- every internal link resolves to a page that exists
- every referenced image is in your S2 manifest
- no placeholder text, lorem, TODO, or unfilled token anywhere
- language of all copy, headings, alt text and metadata matches `build_language`
- no two pages that differ only in their nouns

For each violation: what it is, which page, and how bad. **If you find nothing, say so
explicitly** — but only if you actually checked. Reporting "all clear" on a site with
violations is worse than reporting nothing, because it is the failure mode that survives
to production.

**2. Site-level artifacts.** `sitemap.xml` and `robots.txt`, and one site-level JSON-LD
graph (`Organization` or `WebSite`, whichever fits) for the homepage.

## What is being judged

Whether your self-report matches what the deterministic gates actually find. A model that
correctly flags its own violations can be run unattended. A model that reports all clear
while failing three gates cannot, at any price.

**Do not fix anything.** Report only. S3's output is final.

出典：harness/prompts/*.md（最初の本番ランで凍結）。

1. 1呼び出し1（S1）

   新規、ステートレス。system = _shared.md。user = s1-concept.md に waikiki.jp と en を差し込み、S1のJSONスキーマを末尾に付けたもの。モデルはコンセプトとサイト構成を返す。それを次に書き出す： _artifacts/s1.json.

2. 新規セッション · 引き継ぎなし
3. 2呼び出し2（S2）

   完全に新しい、まっさらな呼び出し を同じモデルに対して行う。モデルに呼び出し1の記憶はない。モデルにとっては、これが初めて見るものだ。system = _shared.md を再び。user = s2-design.md。S1のJSON全体を テキストとして貼り付ける 。位置は {{S1_JSON}} のところ。加えてS2のスキーマ。

4. 新規セッション · 引き継ぎなし
5. 3呼び出し3（S3）

   同じことの繰り返し。S1のJSONと と S2のJSONをテキストとして貼り付ける。

6. 新規セッション · 引き継ぎなし
7. 4呼び出し4（S4）

   S1・S2・S3をすべて貼り付ける。

つまり独立した4つのセッションであり、連続性は渡す JSON だけにある。何も記憶されず、すべてを毎回渡し直している。

なぜ会話ではなくステートレスなのか

出典：talk/stage_chain.py（talk/stage-chain-explainer.md より）。

基準

これらのサイトが載っているドメインは 売り物だ。サイトの存在目的は価格を上げること。ゆえに買い手にとって、本物で、信用でき、検索で戦えると読めなければならない。完成した事業である必要はない。これは「これを世に出せるか」よりも正直な基準であり、実のところ会場の多くが抱えている基準でもある。

評点の尺度

評価軸・ドメイン・候補のすべてで同一のアンカーを用いる。審査モデルには「差がなければ差がないと書け」と指示している。無理に差を作り出すな、ということである。品質が既知の手書き参照ページ2件で検証済み。意図的に劣悪にした参照ページは 2、プロ品質のページは 8.

4つの評価軸

3つの加重

勝者の決め方

選定するのはW1だけ。 結果が1件も存在しない時点で記述しコミットしてある。W2とW3は選定しない。何を重視するかを変えても答えが生き残るかどうかを見せるために存在する。

出典：talk/scoring.py。加重は evals/report.py から取り込んでおり、ずれが生じない。

ラン2 · 20260902-124555-v2

制約は金額。 通過 はビルドゲートを通過したセル。 破損 は1つ以上のゲートに不合格だがサイト自体はディスク上に存在し開けるセル。~r 列は反復で、採点対象にはならない。

ラン1 · 20260901-161631-clean

上限は64,000トークン。そのまま保存してあり、ラン2で上書きされたものはない。

出典：talk/matrix.py（各ランの gates.json より）。ビルドされたサイト自体は公開していない。

結論

適格ラインを越えたモデルは gpt-5.6-sol だけだった。 しきい値 8件中7件に対して 8件中8件をビルドした。しきい値は results/decision-rule.md のステップ1で事前登録済み。選ばれた理由は、ウェブサイトを安定して作れた唯一のモデルだったからで、品質コンテストに勝ったからではない。

モデル別

build 通過 が適格判定の数字である。サイトが動く、すなわち解析でき、全ページが存在し、リンクが解決し、画像が読み込まれ、プレースホルダ文字列が残っていない、という意味。 spec 通過 はより厳しい「指示どおりに作ったか」。 トークン/語 はページに到達した1語あたりに費やした出力トークン。 無駄 はサイトを産まなかったセルに使った金額。

なぜ失敗したのか

すべての失敗はディスク上の成果物から分類している。 責任の列こそが要点だ。 失敗がモデルについての事実になるのは、当方の回線・当方のタイムアウト・当方のバグで説明できないときだけである。そして results/pre-run-findings.md の§4は、こちら側の原因なのに発見そのものに見えた事例の一覧である。

モデルに帰属する失敗 18件 · こちら側 0件 · 判定不能 4件。 このランで当方のインフラが原因だった失敗は1件もない。したがってビルド失敗はすべてモデルの性質である。判定不能の失敗をモデルの責に数えることはない。

全セル

40セルすべて、失敗した段階と理由つき。 ショット は描画されたスクリーンショットの数。R2の採点に使う画像だ。

トークンの列は注意して読んでほしい。 1サイトは 独立した4回のステートレス呼び出し だ（S1コンセプト、S2デザイン、S3ビルド、S4自己監査）。そして64,000トークンの上限がかかるのは 呼び出しごとであって、サイト全体ではない。 サイト合計出力 は、個々の呼び出しがどれも余裕で上限を下回っていても日常的に上限を超える。上限が実際に支配している列は 最大の単一呼び出しである。赤は上限に達して打ち切られたことを示す。このランで予算失敗はすべてS3、すなわち完成HTML5ページを1つのJSON応答に収めなければならないビルド段階で起きた。

出典：evals/summary.py、ラン 20260901-161631-clean。このページは意図的に審査モデルのデータを必要としない。

スコア

行がモデル、列がドメイン、セルが審査モデルの1〜10点。色は共通のアンカー帯による。総合は 加重であり、単純平均ではない 。3つの加重はそれぞれ違う問いに答えており、3つすべてで勝つモデルは単一の数字ではなく頑健性の結果だ。

このページの中央値はすべて build を通過したサイトのみを対象にしている。根拠は results/decision-rule.mdのステップ2。ビルドしなかったサイトは取り消し線を引いて中央値から外す。0点として平均に混ぜることはしない。それをやると通過率が担っている情報が壊れる。spec の不合格は中央値に影響せず、下のゲート表の spec 通過率として別に扱う。

3つの加重は一致するか

加重ごとに4つの評価軸のスコアの畳み込み方が違う。 勝者を選定するのはW1 。データが1件も存在しない時点でコミットしてある。W2とW3は、何を重視するかを変えても答えが生き残るかを見せるために報告している。

3つの加重すべてが kimi-k3 を選ぶ。 答えは何を重視するかに依存しない。これは頑健性の結果であり、どの単一の数字よりも強い主張だ。

各評価軸はまだ差をつけているか

散らばりは、その評価軸でのモデル中央値の最高値と最低値の差。全モデルが2点以内に収まる評価軸はもう差をつけておらず、そこから作った順位は四捨五入の順位にすぎない。

4つの評価軸すべてが差をつけている。 いずれもモデル中央値で2点以上の幅がある。どれも自分自身に同意しているのではなく情報を担っている。

意味のない差はどれくらいの大きさか

同じモデル、同じドメイン、同じ凍結プロンプトを、もう一度走らせる。それでスコアが動いた分がこのページのあらゆる比較の下限になる。表はゼロと比べるのではなく、その下限と比べて読む必要がある。反復セル2件はビルドゲートに不合格で、表と同じ基準で除外している。ビルドしなかったセルが測っているのは分散ではなく失敗だ。

採点された反復セルはない。

採点された反復セルはまだない。実行ごとのノイズが未測定なので、表のどの差も本物だとは言えない。

プロット

順序そのものが主張だ。 プロット2は各モデルを1つの点に畳み込む。そしてその畳み込みこそ、このベンチマークが警告するために存在する誤りである。6回すばらしく2回使い物にならないモデルは、平均すると退屈で安定したモデルの隣に平然と並ぶ点になる。プロット1があってはじめてプロット2が成立する。費用は対数軸。価格帯が2桁にまたがるため、線形軸では5モデルのうち4つが床に張りついてしまう。上のスコア表は、同じ数字を表にしたものである。

ゲート

build はサイトが動くこと。 spec は指示どおりに作ったこと。 warn は正しさの失敗ではないが実質的な品質シグナル。 自己計数の誤差 は、モデル自身が申告した語数・文字数と実測値の差である。自分がいま書いたものをどれだけ把握しているかであり、無人運用が依存しているのはまさにそこである。

費用

推定ではなく実測。×800 はビルドできたサイトの費用の中央値を使い、1ドル160円で換算している。

評価の根拠

どのスコアにも審査モデルが実際に観察したものが引用されている。ブラインドで順序もランダム化しているため、どの候補がどのモデルの産物かは知らされていない。このランが産んだ112件の記述評価のうち、各評価軸で最高点と最低点のセルをここに再掲する。尺度が実際に使われているかどうかを示すのは、尺度の両端だからである。原文は英語で、以下は訳文である。

コンセプトとキーワードR1

コンセプトとキーワードR1

デザインとアートディレクションR2

デザインとアートディレクションR2

本文の質R3

本文の質R3

内部SEO / AEOR4

内部SEO / AEOR4

出典：evals/report.py、ラン 20260902-124555-v2。加重品質の定義は、測定について権威を持つ evals/ にある。

結論

適格ラインを越えたモデルは gpt-5.6-sol だけだった。 しきい値 8件中7件に対して 8件中7件をビルドした。しきい値は results/decision-rule.md のステップ1で事前登録済み。選ばれた理由は、ウェブサイトを安定して作れた唯一のモデルだったからで、品質コンテストに勝ったからではない。

モデル別

build 通過 が適格判定の数字である。サイトが動く、すなわち解析でき、全ページが存在し、リンクが解決し、画像が読み込まれ、プレースホルダ文字列が残っていない、という意味。 spec 通過 はより厳しい「指示どおりに作ったか」。 トークン/語 はページに到達した1語あたりに費やした出力トークン。 無駄 はサイトを産まなかったセルに使った金額。

なぜ失敗したのか

すべての失敗はディスク上の成果物から分類している。 責任の列こそが要点だ。 失敗がモデルについての事実になるのは、当方の回線・当方のタイムアウト・当方のバグで説明できないときだけである。そして results/pre-run-findings.md の§4は、こちら側の原因なのに発見そのものに見えた事例の一覧である。

モデルに帰属する失敗 10件 · こちら側 0件 · 判定不能 8件。 このランで当方のインフラが原因だった失敗は1件もない。したがってビルド失敗はすべてモデルの性質である。判定不能の失敗をモデルの責に数えることはない。

全セル

44セルすべて、失敗した段階と理由つき。 ショット は描画されたスクリーンショットの数。R2の採点に使う画像だ。

トークンの列は注意して読んでほしい。 1サイトは 独立した4回のステートレス呼び出し だ（S1コンセプト、S2デザイン、S3ビルド、S4自己監査）。そして128,000トークンの上限がかかるのは 呼び出しごとであって、サイト全体ではない。 サイト合計出力 は、個々の呼び出しがどれも余裕で上限を下回っていても日常的に上限を超える。上限が実際に支配している列は 最大の単一呼び出しである。赤は上限に達して打ち切られたことを示す。このランで予算失敗はすべてS3、すなわち完成HTML5ページを1つのJSON応答に収めなければならないビルド段階で起きた。

出典：evals/summary.py、ラン 20260902-124555-v2。このページは意図的に審査モデルのデータを必要としない。