資料 How it works

The short version: two upstream sources fused into a single static artifact at build time.

• 3 sources sumo-api.com (bouts and banzuke), Wikipedia (photos + pre-1958 yokozuna lineage), JSA (photo fallback)
• 67 years deep Nov 1958 - May 2026, the modern six-basho era
• 1 artifact one derived.json baked at deploy time, no DB or CMS

sumo-api.com

The primary data source. An unofficial but well-maintained REST API mirroring the Japan Sumo Association's official banzuke and bout records.

{
  "rikishis": [
    {
      "id": 8854,
      "shikonaEn": "Aonishiki",
      "shikonaJp": "安青錦　新大",
      "currentRank": "Ozeki 1 West",
      "heya": "Ajigawa",
      "shusshin": "Ukraine, Vinnytsia Oblast",
      "height": 182,
      "weight": 141,
      "debut": "202307",
      "birthDate": "2004-03-23T00:00:00Z"
    }
    // ... 620 more rikishi
  ],
  "total": 621
}

{
  "id": 8854,
  "totalMatches": 177,
  "totalWins": 135,
  "totalLosses": 42,
  "yusho": 4,
  "basho": 16,
  "sansho": {
    "Gino_sho": 3,
    "Kanto_sho": 2,
    "Shukun_sho": 1
  }
}

{
  "bashoId": "202507",
  "startDate": "2025-07-13T00:00:00Z",
  "endDate": "2025-07-27T00:00:00Z",
  "yusho": [
    {
      "division": "Makuuchi",
      "rikishiId": 8854,
      "shikonaEn": "Aonishiki"
    }
    // ... 5 more divisions
  ]
}

{
  "bashoId": "202507",
  "division": "Makuuchi",
  "rikishi": [
    {
      "rikishiId": 19,
      "shikonaEn": "Hoshoryu",
      "rank": "Yokozuna 1 East",
      "records": [
        { "day": 1, "result": "win",  "opponentId": 44,   "kimarite": "sotogake" },
        { "day": 2, "result": "loss", "opponentId": 13,   "kimarite": "yorikiri" },
        { "day": 3, "result": "loss", "opponentId": 8854, "kimarite": "watashikomi" }
        // ... 12 more days
      ]
    }
    // ... 41 more rikishi
  ]
}

Pulls last 6 bashos by default (~1 year window). Re-run npm run data daily during a basho to refresh.

Wikipedia / Wikimedia Commons

Wrestler photos via the Wikipedia REST APIs. Two endpoints are tried in sequence for each rikishi in the union of the active roster (610 wrestlers across all divisions) and the historical Makuuchi corpus (558 wrestlers since 1958) — 1,095 unique lookups in total. Three quality guards keep the search fallback honest: a title gate (the rikishi's shikona must start the matched Wikipedia page title — rejects "Mudoho" → "Taihō Kōki" because Mudoho is Taihō's grandson with no own article), a description filter (rejects list pages, "X stable", manga, fictional characters with "sumo wrestler" descriptions), and cross-ID dedupe (a Wikipedia URL claimed by one rikishi can't be reclaimed by another with a similar shikona).

{
  "title": "Aonishiki Arata",
  "thumbnail": {
    "source": "https://upload.wikimedia.org/wikipedia/commons/thumb/...",
    "width": 320,
    "height": 427
  },
  "originalimage": {
    "source": "https://upload.wikimedia.org/wikipedia/commons/5/5a/...",
    "width": 1200,
    "height": 1600
  },
  "content_urls": {
    "desktop": {
      "page": "https://en.wikipedia.org/wiki/Aonishiki_Arata"
    }
  }
}

{
  "pages": [
    {
      "key": "Aonishiki_Arata",
      "title": "Aonishiki Arata",
      "thumbnail": {
        "url": "https://upload.wikimedia.org/wikipedia/commons/thumb/...",
        "width": 200,
        "height": 267
      }
    }
    // ... more results
  ]
}

Cached locally in data/raw/wiki-photos.json with resolved: "summary" | "search" | "jsa" | "miss" and source: "wikipedia" | "jsa". Wikipedia photos hotlink at the Wikimedia thumbnail URL (CC BY-SA).

JSA official profile (fallback)

When both Wikipedia lookups miss, fall back to the Japan Sumo Association's official rikishi profile page. JSA has an authoritative headshot for every currently-ranked rikishi — this lifts portrait completeness for the active banzuke to ~100%. JSA has no presence for retired wrestlers (their nskId is 0), so the historical Makuuchi corpus relies entirely on Wikipedia for the 55% of profile-page rikishi that resolve; the rest fall through to a 力 silhouette card.

JSA's robots.txt returns 404 (no rules → default-permissive). nskId is the JSA's internal rikishi identifier; it ships with the sumo-api crawl so no extra lookup needed.

Static / authored content

What snapshot you're seeing

Coverage windows

Refresh cadence

No history kept

1. A
   scripts/fetch-data.ts

   Hits sumo-api with throttle (80-200ms between calls). Pages through all rikishis, fetches stats for sekitori, fetches the most recent 6 bashos. Writes raw JSON files into data/raw/.

2. B
   scripts/fetch-photos.ts

   Cached lookup of Wikipedia summaries for current Makuuchi sekitori. Direct title match first, falls back to keyword search. Idempotent (skips entries already resolved). Run with --refresh to re-check everyone.

3. C
   scripts/build-data.ts

   Reads data/raw/* and produces src/data/derived.json. All the heavy lifting happens here: filtering to Makuuchi, parsing ranks, computing aggregates, generating per-tier breakdowns, photo merge.

4. D
   Astro build

   src/pages/index.astro imports derived.json; each component reads what it needs and emits HTML. Output is fully static - one index.html, hashable + CDN-friendly. Zero client-side data fetches.

Historical pipeline (/history)

The /history page draws on a separate corpus spanning November 1958 through the current basho (~67 years, 406 tournaments). Two additional scripts feed it: fetch-historical.ts crawls sumo-api for every Makuuchi banzuke and rikishi bio since 1958 (cached in data/raw/historical/); build-historical.ts aggregates those into src/data/historical.json with decade-level trends -- kimarite shifts, yokozuna reigns, the Mongolian-wave line chart, and win rates by rank tier.

Body-stats note: wrestler height and weight are JSA-reported career values from the bio endpoint, not per-basho time series. The decade averages on the body-stats chart reflect all wrestlers who appeared in Makuuchi during that decade, averaged with their static measurements -- not a snapshot of what they weighed during those specific years.

Repo layout

sumo/
├── package.json              # scripts: data, data:fetch, data:photos, data:build, dev, build
├── astro.config.mjs          # Astro config, port 4327
├── tsconfig.json
├── data/
│   └── raw/                  # gitignored - sumo-api dumps + wiki photo cache
├── scripts/
│   ├── fetch-data.ts         # sumo-api crawl (rikishis, stats, basho, banzuke)
│   ├── fetch-photos.ts       # Wikipedia photo lookup w/ cache
│   └── build-data.ts         # raw → derived.json, all transforms here
└── src/
    ├── data/
    │   └── derived.json      # the single source of truth at build time
    ├── lib/
    │   ├── types.ts          # all schema types (Derived, Rikishi, BanzukeEntry, etc.)
    │   ├── historical-cache.ts  # shared loader for the 1958-present corpus
    │   └── rikishi-profile.ts   # per-wrestler aggregation for the profile pages
    ├── layouts/
    │   ├── Base.astro
    │   └── MethodologyLayout.astro
    ├── pages/
    │   ├── index.astro       # the main dashboard
    │   ├── history.astro     # the longitudinal /history page (1958-present)
    │   ├── rikishi/[id].astro # 558 per-wrestler profile pages
    │   └── methodology/      # this section
    ├── styles/
    │   └── global.css        # paper/sumi-ink design tokens
    └── components/           # ~22 dashboard sections + RikishiLink (the name → profile link)

Profileable entities

Beyond the main dashboard, the site generates deep-link dossier pages for four entity types, each backed by its own build-time aggregation module:

• Rikishi (/rikishi/[id]) - per-wrestler dossiers covering career rank arc, head-to-head history, kimarite preferences, sansho honors, and post-active kabu tenure.
• Heya (/heya/[slug]) - per-stable profiles with full roster, all-time yusho/sansho/yokozuna output, and ichimon affiliation.
• Basho (/basho/[YYYYMM]) - per-tournament pages for every honbasho from 1958 to the present.
• Kabu (/kabu/[slug]) - the 104 currently-active toshiyori-kabu (年寄株), the fixed pool of inheritable elder names that retired wrestlers acquire from the Japan Sumo Association. Each kabu has a per-name lineage page tracing successive holders generation-by-generation, drawn from Japanese Wikipedia. The directory page groups all 104 by their ichimon affiliation. Data source and match-quality detail on data shape.

Stack

Core

• Astro 5 - Static site generator with file-based routing and scoped CSS. Chosen for zero-runtime output: the build emits one index.html and static assets; no JS framework ships to the browser.
• TypeScript end-to-end - Both the data pipeline scripts (scripts/) and Astro components are TypeScript. One type system for the whole repo; src/lib/types.ts is the shared schema.
• Plain CSS + custom-property tokens - No Tailwind, no CSS framework. The parchment palette lives in src/styles/global.css as --paper / --paper-2 / --ink / etc. Components reference tokens, never raw hex.
• No client framework - Sidebar nav, sunburst hover, scroll-spy, and other interactive behaviors are vanilla TypeScript in <script> blocks per component. No React, Vue, or Svelte.
• Hand-rolled SVG - All visualizations (sankey, sunburst, weight distribution) are authored directly as SVG with TypeScript math. No D3, no chart library.
• One derived.json artifact - The single source of truth at build time. Every component reads from it; no database, no CMS, no client-side state. Deterministic and cacheable: same inputs always produce the same HTML.

Tooling & hosting

• tsx - Runs TypeScript pipeline scripts directly without a separate compile step (tsx scripts/fetch-data.ts). Dev-dependency only; not in the Astro build.
• @resvg/resvg-js - SVG-to-PNG rendering for OG image generation. Dev-dependency.
• @astrojs/sitemap - Sitemap plugin; generates /sitemap-index.xml at build time.
• Node 22 - Pinned via .nvmrc. Both local dev and Cloudflare Pages build use the same version.
• Cloudflare Pages - Hosting with auto-deploy from main. Every PR gets a preview at a unique <hash>.sumofans-com.pages.dev URL. Build command: npm run data && npm run build; output: dist/.