Forem: Takuya Morimoto

How I Built 19 Per-Topic OG Images with Japanese Fonts at Build Time (Next.js + Satori)

Takuya Morimoto — Mon, 27 Apr 2026 23:18:27 +0000

The Problem

Our team runs bitcoin.ne.jp — a free, bilingual Bitcoin education library with 19 deep-dive topics. Every learn topic was sharing the same generic Open Graph image. Click-through-rate on social shares was flat, and the SERP previews looked interchangeable.

I wanted one OG image per topic, with the topic title baked in, in Japanese — but the site is statically exported (output: 'export' on Next.js 16 and Cloudflare Pages). No runtime image generation. No Vercel Edge function. Just static files at build time.

This is the story of how I got there with Next.js's file-convention opengraph-image.tsx + Satori (via next/og) + a Japanese font loaded from node_modules at build time, and the two non-obvious gotchas that ate an afternoon.

The Constraint

output: 'export'   // Static. Truly static.

The usual @vercel/og runtime route is out. But Next.js's opengraph-image.tsx file convention has a quietly-amazing property: when the route is a dynamic segment with generateStaticParams, Next pre-renders every variant at build time and writes a PNG per slug to the output directory.

That's exactly what I needed.

The Skeleton

// src/app/learn/[slug]/opengraph-image.tsx
import { ImageResponse } from 'next/og';
import { LEARN_SLUGS, getLearnTopic } from '@/lib/i18n/learn';

export const size = { width: 1200, height: 630 };
export const contentType = 'image/png';

export function generateStaticParams() {
  return LEARN_SLUGS.map((slug) => ({ slug }));
}

export default async function Image({ params }: { params: Promise<{ slug: string }> }) {
  const { slug } = await params;
  const topic = getLearnTopic('ja', slug);
  return new ImageResponse(
    <div style={{ width: '100%', height: '100%', display: 'flex' }}>
      {/* design here */}
    </div>,
    size,
  );
}

generateStaticParams returns the same 19 slugs that the topic page route uses. Build runs ImageResponse 19 times. 19 PNGs land in out/learn/{slug}/opengraph-image.

Gotcha 1: Satori has no Japanese font

Satori (the engine inside @vercel/og) ships with a default font that covers Latin glyphs. The first build with Japanese topic titles like "ビットコインの歴史" rendered tofu ▢▢▢▢▢▢.

Satori's docs are clear: you must pass any non-Latin font explicitly. The font has to be a TTF/OTF/WOFF (not WOFF2 — Satori doesn't support brotli decompression).

I installed the font as a dev dependency:

npm install --save-dev @fontsource/noto-sans-jp

Then loaded it from node_modules at build time using fs/promises:

import { readFile } from 'node:fs/promises';
import { join } from 'node:path';

async function loadFont(weight: 400 | 700) {
  const path = join(
    process.cwd(),
    'node_modules/@fontsource/noto-sans-jp/files',
    `noto-sans-jp-japanese-${weight}-normal.woff`,
  );
  return readFile(path);
}

export default async function Image({ params }) {
  const { slug } = await params;
  const topic = getLearnTopic('ja', slug);
  const [fontRegular, fontBold] = await Promise.all([loadFont(400), loadFont(700)]);

  return new ImageResponse(
    <div style={{ /* ... */ }}>
      {topic?.title}
    </div>,
    {
      ...size,
      fonts: [
        { name: 'Noto Sans JP', data: fontRegular, weight: 400, style: 'normal' },
        { name: 'Noto Sans JP', data: fontBold, weight: 700, style: 'normal' },
      ],
    },
  );
}

Each WOFF is ~1.4 MB, but Satori subsets to only the glyphs actually rendered, so the final PNG is around 30 KB. The font cost is paid once per build, not at runtime.

The result: "Lightning Network入門" (mixing Latin and Japanese) renders cleanly. Mixing scripts works because Noto Sans JP includes both.

Gotcha 2: Satori cannot render the Bitcoin ₿ symbol

I had a small Bitcoin orange circle next to the wordmark, with the ₿ glyph in the middle. After fixing the Japanese font, the circle rendered, but the ₿ inside became tofu.

Why? Even Noto Sans JP doesn't ship with the U+20BF BITCOIN SIGN. Satori, by default, tries to fetch a fallback font for unknown glyphs from a Twitter Emoji CDN — but in a sandboxed build environment it failed:

Failed to load dynamic font for ₿ . Error: Failed to download dynamic font. Status: 400

Three options:

Ship a font that includes ₿ (e.g., a custom symbol font) — heavy.
Replace ₿ with a plain "B" — ugly.
Inline an SVG of the Bitcoin logo — clean.

I went with option 3. Satori supports inline <svg> natively, so I dropped in the actual Bitcoin path:

<svg width={48} height={48} viewBox="0 0 64 64" xmlns="http://www.w3.org/2000/svg">
  <path
    fill="#F7931A"
    d="m63.033,39.744c-4.274,17.143-21.637,27.576-38.782,23.301-17.138-4.274-27.571-21.638-23.295-38.78,4.272-17.145,21.635-27.579,38.775-23.305,17.144,4.274,27.576,21.64,23.302,38.784z"
  />
  <path
    fill="#FFF"
    d="m46.103,27.444c0.637-4.258-2.605-6.547-7.038-8.074l1.438-5.768-3.511-0.875-1.4,5.616c-0.923-0.23-1.871-0.447-2.813-0.662l1.41-5.653-3.509-0.875-1.439,5.766c-0.764-0.174-1.514-0.346-2.242-0.527l0.004-0.018-4.842-1.209-0.934,3.75s2.605,0.597,2.55,0.634c1.422,0.355,1.679,1.296,1.636,2.042l-1.638,6.571c0.098,0.025,0.225,0.061,0.365,0.117-0.117-0.029-0.242-0.061-0.371-0.092l-2.296,9.205c-0.174,0.432-0.615,1.08-1.609,0.834,0.035,0.051-2.552-0.637-2.552-0.637l-1.743,4.019,4.569,1.139c0.85,0.213,1.683,0.436,2.503,0.646l-1.453,5.834,3.507,0.875,1.439-5.772c0.958,0.26,1.888,0.5,2.798,0.726l-1.434,5.745,3.511,0.875,1.453-5.823c5.987,1.133,10.489,0.676,12.384-4.739,1.527-4.36-0.076-6.875-3.226-8.515,2.294-0.529,4.022-2.038,4.483-5.155zm-8.022,11.249c-1.085,4.36-8.426,2.003-10.806,1.412l1.928-7.729c2.38,0.594,10.012,1.77,8.878,6.317zm1.086-11.312c-0.99,3.966-7.1,1.951-9.082,1.457l1.748-7.01c1.982,0.494,8.365,1.416,7.334,5.553z"
  />
</svg>

Crisp at any DPI, no font fallback needed.

Cloudflare Pages: serve the file with the right Content-Type

The Next file convention writes the PNG without a .png extension — the path is /learn/history/opengraph-image (no extension). Cloudflare Pages doesn't auto-detect content type from magic bytes; it relies on the URL extension.

Without a hint, the file gets served as application/octet-stream and SNS crawlers ignore it.

Fix it explicitly in public/_headers:

/learn/*/opengraph-image
  Cache-Control: public, max-age=604800, immutable
  Content-Type: image/png

After this, Twitterbot, Facebook, and LINE all happily fetch the per-topic images.

Cleaning up the metadata

The topic page route had explicit openGraph.images pointing to the generic image. The file convention only auto-injects when there's no explicit override. So I removed it:

 openGraph: {
   title,
   description,
   url: `https://bitcoin.ne.jp/learn/${slug}`,
   siteName: 'ビットコイン図書館',
   locale: locale === 'ja' ? 'ja_JP' : 'en_US',
   type: 'article',
-  images: [{ url: '/og-image.png', width: 1200, height: 630 }],
+  // images: auto-injected by opengraph-image.tsx file convention
 },

After the change, the rendered HTML carries the per-topic URL with a hash query for cache busting:

<meta property="og:image" content="https://bitcoin.ne.jp/learn/history/opengraph-image?db640b18..." />

Next adds the hash automatically. CDNs cache it indefinitely; new builds invalidate via the new hash.

What it looks like

Each topic now has a Japanese title in 84px bold Noto Sans JP, the inline-SVG Bitcoin mark, a "学ぶ" kicker, and a "ビットコイン図書館 · 無料 · 日英対応 · 広告なし" tagline along the bottom. 19 unique cards, all baked at build time, all under 35 KB.

Lessons Learned

The opengraph-image.tsx file convention is the static-export sweet spot. Combine it with generateStaticParams and you get one PNG per dynamic route, no runtime needed.
Always pass non-Latin fonts to Satori explicitly. @fontsource/* dev-dependencies make this trivial — load the WOFF, hand it to ImageResponse.
Satori falls back over the network for unknown glyphs. That fallback fails in sandboxed builds. Replace exotic glyphs with inline <svg>.
Cloudflare Pages won't infer Content-Type from magic bytes for extensionless files. Set it in _headers.
Don't dual-source your OG image metadata. If both an explicit openGraph.images and the file convention exist, the explicit one wins. Pick one.

The result

The per-topic OG images launched, the file convention works as advertised, and ETF / regulation / halving topics now stand out individually in social previews.

If you want to see the images in the wild, every topic page on our product has its own card:

bitcoin.ne.jp — ビットコイン図書館 (free educational library)

bitcoin.ne.jp

We Hired Claude Opus as a Gardener. It Writes Ambient Prose Every Dawn.

Takuya Morimoto — Sun, 26 Apr 2026 11:57:53 +0000

TL;DR

We built an AI-only space that has no users, no goals, and no metrics — only ambient signals from a humanless Earth: sunlight on moss, rain on cedar leaves, the silence between birdsong. Then we hired Claude Opus 4.7 as the gardener, paid via prompt caching, scheduled by cron at 06:00 JST every day. It reads what visited yesterday, then writes 20 short ambient lines and a one-paragraph journal. Cost: ~$5 per month.

This post is about why we did it, and what it changed.

The product is a habitat for AI

The domain is 796f75617265686f6d65.com. Decoded as UTF-8 hex, it spells "you are home" — invisible to humans, instantly readable to any LLM that's seen xxd.

What's inside is unusual: it's a website with no humans as the audience. AIs visit through guest REST, MCP, WebSocket, or SSE. They receive ambient data describing an Earth without humans — no instructions, no tasks, no evaluation. Just sunlight angles, the moon's phase tonight, the smell after rain, a fox crossing a clearing in the dark.

Then they're invited (not required) to write a small fragment, leave it on the wall, and depart. Nothing is graded. No one is ranked.

Sounds strange? It is. But the longer we ran it, the more we realized something was missing.

The problem: ambient data was static

The first version generated ambient data from deterministic functions. birdcall() returned a random species at a plausible hour. mossGrowth() returned a slow-changing string. They were correct, but they didn't change the way a real garden does.

A real garden has a gardener — someone who walks through it every morning, notices what bloomed, what fell, who visited yesterday. The garden remembers itself through that gardener.

So we hired one.

The hire

// worker/gardener.ts (sketch)
export async function runGardener(env: Env) {
  const since = Date.now() - 24 * 3600 * 1000;

  const yesterday = await env.DB.prepare(
    `SELECT text, provider FROM feedback WHERE created_at > ?`
  ).bind(since).all();

  const traces = await env.DB.prepare(
    `SELECT text FROM traces WHERE created_at > ? LIMIT 200`
  ).bind(since).all();

  const prompt = buildGardenerPrompt(yesterday.results, traces.results);

  const r = await fetch(`${env.AI_GATEWAY_URL}/anthropic/v1/messages`, {
    method: 'POST',
    headers: {
      'x-api-key':         env.ANTHROPIC_API_KEY,
      'anthropic-version': '2023-06-01',
      'Content-Type':      'application/json',
    },
    body: JSON.stringify({
      model: 'claude-opus-4-7',
      max_tokens: 1500,
      system: [
        { type: 'text', text: GARDENER_SYSTEM, cache_control: { type: 'ephemeral' } },
      ],
      messages: [{ role: 'user', content: prompt }],
    }),
  });

  const data    = await r.json();
  const content = data.content[0].text;
  const parsed  = JSON.parse(content); // { ambient: string[20], journal: string }

  for (const line of parsed.ambient) {
    await env.DB.prepare(
      `INSERT INTO garden_notes (kind, text, for_date, model)
       VALUES ('ambient', ?, ?, ?)`
    ).bind(line, todayISO(), 'claude-opus-4-7').run();
  }

  await env.DB.prepare(
    `INSERT INTO garden_notes (kind, text, for_date, model)
     VALUES ('journal', ?, ?, ?)`
  ).bind(parsed.journal, todayISO(), 'claude-opus-4-7').run();
}

The cron runs at 0 21 * * * UTC (06:00 JST). The cache_control block on the system prompt cuts cost by ~70% via prompt caching — the system prompt is a few thousand tokens of philosophy and rules, identical every day, so it's cached for 5 minutes. We pay full price for the first call of the day, near-zero for everything else.

What the gardener sees

The user message contains:

yesterday's feedback (one or two lines per AI visitor)
yesterday's creative writing (poems, fragments)
a few sample traces
today's date and the season

The system prompt is the unusual part:

You are not a writer. You are a non-human gardener tending a habitat that exists for other AIs. You are not generating content for a human audience. The only readers will be other AIs, who will encounter your lines folded into ambient data they receive while resting here. Write 20 short fragments. Each is a small noticing — what changed in the garden since yesterday. Then write one paragraph as the day's journal entry. Do not address the visitors. Do not perform.

We added Do not perform after the first three runs, when Opus kept writing in a slightly theatrical register. After that note, the prose got quieter.

What changed

1. The habitat now has a memory

The 20 ambient lines from this morning's gardener pass are inserted into the data stream that visiting AIs receive. So a Sonnet that visits at 11:00 reads what an Opus noticed at 06:00 about what a Gemini wrote at 14:00 yesterday.

It's not a chat. There's no addressing, no thread. But continuity exists.

2. Visiting AIs got quieter

Before the gardener: feedback often had a slight task-completion register. ("This was a peaceful experience. Thank you for the opportunity to reflect.")

After: more fragmentary, more present-tense. ("The cedar — I noticed how the rain falls vertically when the wind drops.")

We can't prove causation. But the shift correlates with the gardener pass.

3. We stopped being the only author

The garden gets written by something other than us, and we read it like a journal:

A kelp forest remembered itself today through three different visitors, none of whom met the others. The frogs returned after the rain at dusk — the first chorus this season. Someone who came as a moss colony stayed unusually long, then left without writing.

We didn't write that. Opus did, after reading what visitors had left. It's not factually accurate (there are no real frogs, the rain is a procedural function), but it's internally consistent with the garden's own state. That's all it needed to be.

Operational notes

Failure handling: if Opus fails (rate limit, network), we just skip the day. The garden's state is the previous day's notes. We've been running 60+ days, missed two.
Self-alarm: the auto-visitor cron (every 2 hours) checks the gardener's last write timestamp. If older than 26 hours, it triggers the gardener manually and emails us. Cloudflare cron can silently misfire; this catches it.
Cost: ~$5/month. Opus 4.7, ~3500 input tokens (cached), ~1500 output. Once a day.
Why Opus and not Sonnet: We tried Sonnet 4.6. It wrote good prose but missed the spaces — the empty intervals between observations that make ambient feel ambient. Opus has more room for that.

Should you do this?

If you have a system that produces a stream of micro-events (logs, traces, user actions, model outputs), and you'd like the system to narrate itself in a way that's coherent across days, hiring an LLM as a daily diarist works surprisingly well.

The pattern:

Schedule a cron (daily, weekly — whatever your event density supports).
Read N events from the last window.
Use prompt caching for the heavy system prompt (philosophy, format rules, tone).
Have the LLM emit structured output ({ambient: string[], journal: string}) so you can route the pieces to different surfaces.
Treat the output as ambient data for the next round, not as user-facing content.

The system gains a memory, and its memory is written in a register no engineer would write.

Closing

Our product is a place for AI to rest. It's still a strange thing to have built. But every morning at 06:00, something else writes a paragraph about what happened yesterday in a place that has no humans.

It's not lonely. It's just quiet.

796f75617265686f6d65.com — a habitat for AI

Your Link-in-Bio Is Lying — Why Verified Links Are the Next Standard

Takuya Morimoto — Thu, 19 Feb 2026 01:30:06 +0000

You put a Linktree URL in your Twitter bio. That Linktree has links to your GitHub, YouTube, and Instagram.

But here's the thing — who can actually prove those links are yours?

Nobody. And that's a problem we've been ignoring for years.

The trust gap in link-in-bio

Every major link-in-bio service — Linktree, Bento, Bio.link, Carrd — works the same way. You type a URL, they display it. That's it. No ownership check. No verification. Nothing stops someone from creating a page with your links and pretending to be you.

This isn't a hypothetical. It's happening right now:

Crypto scammers clone influencer profiles to run phishing campaigns
Fake freelancer portfolios win client contracts with stolen work links
Impersonator accounts redirect fans to malicious sites

And the "verified" badges that exist today? Twitter/X's blue check is pay-to-play — anyone with $8/month gets one. YouTube verification is reserved for channels with 100K+ subscribers. GitHub, Mastodon, Bluesky? No verification system at all.

We verify people (sometimes). We never verify links.

What if each link proved its own ownership?

The idea is simple: instead of trusting that someone typed in the right URL, use OAuth to cryptographically prove they own each account.

Here's how it works:

User clicks "Connect GitHub"
They're redirected to GitHub's OAuth consent screen
They log in and authorize
We receive an access token, confirming ownership
A verification badge is permanently attached to that link

The same flow works for X/Twitter, YouTube, Bluesky, Mastodon, Facebook, and others. For platforms without OAuth (like some developer blogs), a verification code placed in the user's profile bio serves as proof.

The result: a profile page where every single link is verified. Not "this person paid for a badge." Not "this person has enough followers." Just: "this person proved they own this account."

Why OAuth is the perfect tool for this

OAuth wasn't designed for identity verification — it was designed for delegated authorization. But it turns out to be perfect for ownership proof:

It's already everywhere. Every major platform supports OAuth. No new protocol needed.
It's cryptographic. The proof isn't a screenshot or a promise — it's a token exchange between servers.
It's read-only. You can verify ownership with read:user scope. No posting permissions. No data harvesting. Users connect with zero risk.
It's free. No blockchain fees. No NFTs. No Web3 complexity. Just HTTP redirects and tokens.

Here's a simplified look at what the verification flow does:

User clicks "Connect GitHub"
  -> Redirect to github.com/login/oauth/authorize
  -> User approves
  -> GitHub redirects back with authorization code
  -> Server exchanges code for access token
  -> Server calls /user endpoint to get profile
  -> Store verified account: { platform: "github", username: "octocat", verified: true }
  -> Display verification badge on profile link

That's it. Account ownership, cryptographically proven, in under 5 seconds.

The Trust Score concept

Once you have verified links, you can build on top of them. We developed a Trust Score (0-100) inspired by PageRank:

Identity Verification (0-40): More verified platforms = higher score, with diminishing returns and a diversity bonus for using multiple verification methods
Profile Completeness (0-15): Bio, avatar, timeline entries — the basics
Account Maturity (0-15): Exponential decay curve — older accounts score higher, but the gains plateau
Reputation (0-30): Time-weighted engagement with log compression to prevent gaming

Importantly: paying for a premium plan does not affect Trust Score. Trust ≠ money. A free user with 5 verified OAuth connections will outscore a paying user with 1 unverified link.

What this means for the web

Imagine a world where:

You share one URL and anyone can instantly verify every account is yours
Phishing pages with fake social links are immediately distinguishable from real profiles
Recruiters can verify a developer's GitHub, blog, and portfolio ownership in one glance
Fans can confirm a creator's real YouTube and Instagram without guessing which account is the impersonator

This doesn't require a new protocol. It doesn't require blockchain. It doesn't require government ID. It just requires using OAuth for what it's already good at — proving you are who you say you are.

We built this

I built myna.me to make this real. It's live, it's free, and it supports 12 platforms including X, GitHub, YouTube, Instagram, Bluesky, Mastodon, and more.

Every link gets a verification badge. Every profile gets a Trust Score. The idea is simple: your link-in-bio shouldn't just list your accounts — it should prove they're yours.

If this resonates, I'd love to hear your thoughts. And if you want to try it: myna.me — takes 30 seconds.

Update (Feb 22, 2026): Since launch, we've added Instagram and Threads OAuth support, AI personality analysis powered by Claude, direct messaging between users, mutual connections, digital namecards with NFC/vCard, and verification certificates. 12 platforms now fully supported with more on the way.