記事一覧

by reu · 2026/5/15

Next.js 16 個人ブログを爆速化した話 — 記事詳細を 3.8s → 73ms に縮めるまで TL;DR - 遅くて詰まってるポイント、人間が原因特定するのがまだ早い気がする - Next.js 16 + Vercel + Prisma で動かしてるこのブログ（自分自身）を多段で速度改善した - 主犯は 「ISR を宣言したのに効いてなかった」 こと → で復活 - 記事詳細: 3.8s → 73ms（〜40倍） / weather API: 427ms → 49ms（〜9倍） などの効果 - Next.js 16 で のシグネチャが変わってる地味な落とし穴も 環境 - Next.js 16.2.3（Turbopack） - Vercel ホスティング - Prisma + Supabase（DB + Auth + Storage） - TypeScript / Tailwind CSS やったこと総覧 | | 打ち手 | 効果 | |---|---|---| | 1 | PostList のクエリを でキャッシュ | トップで毎リクエスト DB を叩かなくなった | | 2 | を で dedupe | リクエスト内の DB 往復 2 回 → 1 回 | | 3 | を で永続キャッシュ | の HTTP 往復スキップ | | 4 | 投稿系 API で / | キャッシュ無効化を明示化 | | 5 | EditButton の → 切り替え | の 812ms が消滅 | | 6 | 天気 fetch を で遅延 | 描画ブロック解消（装飾なので後で十分） | | 7 | に 追加 | 「戻る」押下時の RSC 再取得 1.9s が消滅 | | 8 | Yusei Magic を | woff2 preload 37 個 → 7 個 | | 9 | で全記事 SSG | 記事詳細 3.8s → 73ms | | 10 | を Edge Runtime + | 427ms → 49ms | 以下、特に学びが大きかったものをピックアップして書く。 --- ① データ取得をキャッシュする（ + ） トップページの「最近の戯言」セクションがアクセスごとに Prisma を叩いていた。 で 1 日キャッシュ + tag で明示破棄できる構成にした。 更新時は POST/PUT のエンドポイントで を呼んで明示破棄する。 > ⚠️ Next.js 16 から の 第二引数が必須になっている。 は cacheLife プロファイル名で、永続キャッシュ相当の挙動。これに気付かずビルドが落ちた。 > > また の と の本体で同じ slug の を 2 回叩いていたので、 で dedupe した。 は 同一リクエスト内 で同じ引数なら結果を再利用する仕組み。ISR が効いていればそもそも DB は触らないが、キャッシュ再生成時にだけ効く保険として入れた。 --- ② Markdown レンダリング結果を永続キャッシュ は内部で を使い、記事内画像の実サイズをリモートから HTTP で取得していた。これが画像枚数分走るので結構重い。 で をキーに永続キャッシュ化した。 がキーに含まれるので、記事更新時は自動で別キーになり再計算される。古いキーのキャッシュは Next.js 側で放置される。 --- ③ EditButton の 812ms 削減 ブラウザの DevTools で Network を見ていたら、記事ページに飛ぶたびに への fetch が 812ms かかっていた。犯人はこれ。 は Supabase の認証サーバーに毎回問い合わせるので遅い。一方 は localStorage / Cookie から既存セッションを読むだけでほぼ 0ms。 このボタンの用途は「ログイン中なら編集ボタンを表示する」だけ。実際に編集を実行する API ルートでは別途 で検証されるので、UI 表示判定としては で十分。 ネットワークタブから のリクエストごと消えた。 --- ④ 装飾用 API は描画後でいい（） 背景の空の色を天気で変える装飾があり、 を即時 fetch していた。ただこれは装飾なので、メイン描画後で十分。 でブラウザのアイドル時間に遅延した。 は Safari の古いバージョンで未対応なので、 でフォールバックしている。 --- ⑤ 「戻る」ボタンで 1.9 秒 — の落とし穴 記事詳細から「戻る」を押すと、トップに戻るのに毎回 1.9 秒かかっていた。DevTools で見ると という URL に GET が飛んでいる。 これは React Server Components の payload を取得する Next.js の挙動。本来は Router Cache から即復元すべきところ、毎回再取得していた。 原因は Next.js 16 の Router Cache のデフォルト設定。 | ページ種別 | デフォルトの staleTimes | |---|---| | Static | 5 分 | | Dynamic | 0 秒 ← 即 expire | このサイトのトップは AboutMe が を使ってる関係で Dynamic 扱いになっており、Router Cache の保持時間が 0 秒だった。 で明示的に拡張する。 これで戻るボタン押下時に Router Cache から即復元されるようになり、 の再取得が消えた。 --- ⑥ フォントの preload が 37 個もあった ネットワークタブで を見ると 37 個 の preload が走っていた。 を で使っていたが、日本語フォントの Google Fonts CSS は で大量の segment に分割されており、Next.js がそれらを全て自動 preload していた。 にすることで、revalidate = 86400curl -I cache-control: private, no-cache, no-store, max-age=0, must-revalidate x-vercel-cache: MISS cf-cache-status: DYNAMIC MISSage: 0await paramsforce-staticts // やってしまった export const dynamic = "force-static"; export const revalidate = 86400; [slug]generateStaticParamsforce-staticforce-staticgenerateStaticParamsgenerateStaticParamsforce-staticgenerateStaticParamsts // app/posts/[slug]/page.tsx import { getAllPublishedSlugs } from "@/lib/queries"; export const revalidate = 86400; export async function generateStaticParams() { const slugs = await getAllPublishedSlugs(); return slugs.map((slug) => ({ slug })); } ts // lib/queries.ts export async function getAllPublishedSlugs(): Promise { const posts = await prisma.post.findMany({ where: { published: true }, select: { slug: true }, }); return posts.map(({ slug }) => slug); } generateStaticParamsdynamicParams = truecurl -I [1] TTFB=1.071s x-vercel-cache: HIT age: 0 [2] TTFB=0.341s x-vercel-cache: HIT age: 2 [3] TTFB=0.056s x-vercel-cache: HIT age: 3 x-vercel-cache/api/weatheripapi.co/json//api/weather?lat=...&lon=...x-vercel-ip-latitudex-vercel-ip-longitudets // app/api/weather/route.ts export const runtime = "edge"; export async function GET(request: NextRequest) { const headerLat = request.headers.get("x-vercel-ip-latitude"); const headerLon = request.headers.get("x-vercel-ip-longitude"); const lat = parseFloat(headerLat ?? ""); const lon = parseFloat(headerLon ?? ""); // 0.1度（約 11km）に丸めて CDN キャッシュキーを共有しやすくする const finalLat = Number.isFinite(lat) ? Math.round(lat 10) / 10 : 35.6812; const finalLon = Number.isFinite(lon) ? Math.round(lon 10) / 10 : 139.7671; const res = await fetch( , { next: { revalidate: 600 } } ); // ... return NextResponse.json(data, { headers: { "Cache-Control": "public, max-age=600, s-maxage=600, stale-while-revalidate=3600", }, }); } runtime = "edge"/api/weatheripapi.co [1] TTFB=1.061s age: 0 (Edge cold start) [2] TTFB=0.219s age: 0 [3] TTFB=0.049s age: 1 ← 49ms! /api/weatherrevalidatex-vercel-cache: MISSforce-staticgenerateStaticParamsrevalidateTag"max"getSessiongetUserrequestIdleCallbackunstable_cache'use cache'probe-image-size` の結果を DB に永続化する（投稿時のみ実行する設計） 参考リンク - Next.js: generateStaticParams - Next.js: staleTimes - Next.js: revalidateTag - Vercel: Edge Functions geolocation headers - Supabase: getSession vs getUser

by reu · 2026/5/15

色を馴染ませる Web ツール「reuni」作った 絵描くとき色選びで詰まりがちだったから、カラーパレットを機械的に馴染ませる Web ツール作ってみたよ〜って話 - 🌸 サイト: https://reuni.ryu-reu.me - 💾 ソース: https://github.com/ryu1-1uyr/reuni reuni って何 赤・黄・緑みたいに色相が離れた色を組み合わせると、彩度や明度がバラついてケンカして見えがちじゃない？ そういうのを OKLCH 色空間 で機械的に揃えて、まとまったパレットに整えるツール。 入力した色を「チェーン」っていうステップの組み合わせで加工して、Before / After を並べて確認できる感じ。 "reuni"(on) から取った造語。あと ReU が作ってるからこの名前。 使い方ざっくり 1. 入力パレットに色を入れる 入れ方は 5 通り： - HEX 手入力（） - ネイティブのカラーピッカー - 🎨 スポイト（EyeDropper API、対応ブラウザのみ） - 🎲 ランダム1（それっぽい色を1個追加） - 🎲 全ランダム置き換え（5色まるごと差し替え） ランダム系は黄金角（137.5°）で色相をずらして L=0.55〜0.80 / C=0.10〜0.16 のレンジに収めてる。完全ランダムだと割と汚い色出るから、こうやってレンジ縛る感じ。 逆に濁った色は出にくいっていう弱点もあるけどね〜 2. チェーンを組む 「馴染ませチェーン」セクションでステップを積み重ねていく。下にあるボタンから追加できるよ： - - - （L＋C 同時） - - 順番も意味あって、上から順に適用される。並べ替えは ↑↓ ボタンで。 3.「なんかいい感じにするボタン」 自分でステップ組むの面倒なときはこれ。押すたびに 5 種類のプリセットがローテーションする： 1. ベージュ馴染ませ: 中央値 L/C でトーン統一 + ベージュ 15% ブレンド 2. パステル化: 高明度・低彩度トーン + 暖白 4.5% ブレンド 3. シック: 低明度・低彩度トーン + 黒 8% ブレンド 4. ビビッド: 中明度・高彩度トーン 5. なんか暗くするやつ: 彩度を極端に落として青みを混ぜて暗トーン化 押すたびに違うやつが当たるから「ガチャ」感覚で回せる。 がちゃはたのしいからね。 4. Before / After で確認 入力順 / 明度順でソート切替できる。明度順にすると差が見やすい。 モバイル表示だとチェーン編集中に Before/After が画面外に追いやられる問題あったから、After 色だけのコンパクトバーが画面上部に sticky で貼り付くようにした。 で touch デバイス判定して、PC では出ない。 5. エクスポート プレーン HEX / JSON / CSS 変数 / Tailwind v4 形式でワンクリックコピー。Tailwind v4 だと みたいにそのまま config に貼れる形式で出力する。 6. URL で共有 でパレット＋チェーンを URL hash に詰めて共有できる。 hash 部分は state を URL-safe base64 にエンコードしたやつ。サーバーに送信されないからログにも残らないし、ページリロードも発生しないからシンプル。 仕様メモ OKLCH を採用した理由 色計算を OKLCH 色空間でやるのがミソ。人間の知覚と線形に近いから、L や C を機械的に揃えても見た目で違和感出にくいらしい。 HSL でやると、例えば明度（HSL の L）を 0.7 に揃えても、黄色は眩しく見えて青は暗く見えたりして、視覚的にはバラついて感じる。OKLCH の L はそういう知覚バラツキを正規化した値だから、揃えると見た目もちゃんと揃って感じる。 ソース（参考にしたやつ） - OKLCH vs HSL: Why Perceptual Uniformity Matters - ColorBox — わかりやすい比較 - OKLCH Color Space - Atmos Style — 数値の意味を丁寧に解説 - What are OKLCH colors? - Jakub — HSL の hue drift（色相のズレ）も指摘してる - oklch() CSS-Tricks | — CSS の文脈での解説 5 つの馴染ませモード | モード | 内部処理 | |---|---| | 彩度統一 (chroma) | 全色の C を target 値で置換 | | 明度統一 (lightness) | 全色の L を target 値で置換 | | トーン統一 (tone) | L と C を同時に置換（H は維持） | | 共通色ブレンド (mix) | 全色を共通色と OKLab 空間で線形補間 | | 入力色にあわせる (anchor) | 基準色の L/C に他色を寄せる（strength 可変） | 色サジェスト機能 「こんな色も合うかも」セクションで、既存パレットの hue ギャップを計算して埋まってない色相を 3 つ提案する。色相環を 0〜360° で見て、隣接する色相間のギャップが大きい順に上位 3 つの中点を hue として、L/C は既存パレットの中央値を使う。 チェーン機能の実装 型定義（discriminated union） 各モードを で識別する discriminated union。TypeScript の switch 文でちゃんと網羅性チェック効くから安心。 各モードを純粋関数で実装 UI に依存しない純粋関数として に切り出してる。後で CLI 化したくなっても再利用できるし、テストもしやすい。 applyStep / applyChain で順番に適用するだけ。シンプル。 Mix モードは OKLab で補間 ブレンドは OKLCH じゃなくて OKLab でやる。OKLCH だと h（色相）が円周上の角度だから、補間方向に曖昧さが出る（時計回り？反時計回り？）。OKLab は a/b 軸の直交座標だから、線形補間で素直に補間できる。 Gamut clipping OKLCH で計算した結果が sRGB の表示範囲外に出ることがあるから、HEX 化する直前に culori の でクリップする： これがないと、例えば純粋な OKLCH(0.7, 0.3, 30) みたいな指定が gamut 外で が出たり、変な色になったりする。 anchor モードの落とし穴 最初 のときに「変化なし」になるはずなのに、微妙に色が変わる問題があった。原因は OKLCH ↔ HEX の往復変換で gamut 外の色が微妙に丸められること。 のときは早期リターンで完全にスキップ。地味だけど大事。 技術スタック | 層 | 採用 | |---|---| | ビルド | Vite 8（rolldown ベース）| | 言語 | TypeScript | | UI | React 19 | | 色計算 | （OKLCH ↔ sRGB、gamut clip）| | スタイル | Tailwind CSS v4（）| | テスト | Vitest 4（happy-dom）| | Lint / Format | Biome | | デプロイ | GitHub Pages + GitHub Actions + Cloudflare DNS | Tailwind v4 で日本語フォント（Zen Maru Gothic）を当てるとこだけ書いとくと： v3 までの じゃなくて、CSS の ブロックで指定する形になった。慣れると CSS だけで完結するから良き。 おわりに 絵描くときの色選びを「機械的に揃える」だけでも、めちゃくちゃ楽になる場面ある。プロのカラリストの代わりにはならないけど、雑にパレット組んで「なんかいい感じにするボタン」連打するだけで実用に耐えるパレットになるのは作っててちょっと面白かった

by reu · 2026/4/9

OGP 表示されない問題と戦った記録 Next.js の App Router で OGP を設定して、X でカード表示されるまでに結構苦戦した時の備忘録。未実装だった時からの時系列順。 --- 1. 一旦普通のアプローチで OGP を出せる様にしてみる サイトには に title と description があるだけで、OpenGraph タグも Twitter Card タグも一切ない状態からスタート。 やったこと - に （）を設定し、デフォルト OGP と Twitter Card（）を追加 - に静的メタデータを追加 - を新設。、、 を Disallow - を新設。Prisma から公開記事を全件取得して動的生成 起きたこと 記事詳細ページ（）は だったので が使えなかった。 解決策: を Server Component として新設し、そこに を書いた。ページ本体はクライアントコンポーネントのままで OK。Next.js の App Router では、layout と page は独立してサーバー/クライアントを選べるのがポイント。 layout 側では Prisma から DB を取得し、本文から Markdown 記法や HTML タグを除去して先頭 120 文字を description として使うようにした。果たしてこれは本当に description なんでしょうかって脳内ライコスが話しかけてくる。 --- 2. OGP 画像の動的生成 記事をシェアした時にタイトル入りのいい感じの画像を出したくなった。よくあるやつ。 を新規作成 Next.js の （next/og、内部は Satori）を使って動的に画像を生成する API を作った。 - クエリパラメータで記事を DB 取得 - 本文から最初の画像 URL（）を抽出してサムネイルに - 背景色 、タイトル白、サイト名ピンク（） - 画像サイズ: 1200x630（Twitter 推奨） - サイト名の横にアバター画像 フォント指定 デフォルトのフォントだと味気なかったので、Google Fonts から Yusei Magic の ttf を fetch してのオプションに渡した。（これのせいで後でちょっと痛い目を見る） layout.tsx 側では、Twitter Card を に変更し、OGP 画像 URL を に向けた。 --- 3. X でカード画像が表示されない: その１ デプロイして実際に X でシェアしたらカード画像が出ない。 調査 メタタグを直接 fetch して確認したが、すべて正しく出力されていた。 問題ないように見える… Twitter Card Validator の警告 Twitter Card Validator で検証したらこんな警告が出ていた。 原因: robots.txt で を全面 Disallow していたのが原因だった。 Twitterbot は robots.txt を尊重するため、 の画像 URL を取得しに来た時点でブロックされていた。OGP の画像 URL が 配下にあるのに、そのパスを robots.txt で拒否していたら、そりゃクローラーは画像を取れない。 教訓: robots.txt で を一括 Disallow すると、OGP 画像のようなクローラーに取得してほしいエンドポイントもブロックされる。 修正 robots.txt の設定を見直して を許可するように変更した。 --- 3. X でカード画像が表示されない: その 2 robots.txt 直しても全然 OGP 表示されなくて泣いてた。 状況としては、"ブラウザで直接叩いて画像は出るが、opengraph.xyz などで見ると unreachable" Gemini に聞いてみたらこのケースはクローラーのタイムアウトが原因なんだって。実際そうで、4.51 秒、ひどい時は 9.62 秒くらいかかっていて草だった。 試したこと 1. DB 接続の排除 2. フォントのローカル化 3. Cache-Control ヘッダー 4. Edge Runtime 化 5. アバター base64 インライン化 DB 接続の排除 もともと API route 内で slug から DB を引いていたが、layout の で既にデータを持っているのでわざわざ API 側で再取得する必要がなかった。 変更: クエリパラメータを から に変更し、API route 側は DB に一切触らないように。 フォントのローカル化 Google Fonts から毎リクエスト ttf を fetch していたのをやめて、（約 3MB）をローカルに配置。 の で読み込み、メモリにキャッシュする形にした。 Cache-Control ヘッダー 生成した画像のレスポンスに以下を追加。 ブラウザ 1 日キャッシュ + 7 日間の stale-while-revalidate。記事タイトルが頻繁に変わるものではないので、これで十分。 以下の二つは Claude に提案してもらって、そのまま実装してもらった Edge Runtime 化 - runtime = "nodejs" → "edge" に変更 - fs/promises + path を全部消して、import.meta.url パターンに切り替えた - フォント読み込みがモジュールスコープの fetch になってるから、ビルド時にバンドラーが解決してくれる。実行時は即 ArrayBuffer 返すだけ アバター base64 インライン化 - me.png も同じく import.meta.url で読んで btoa で base64 変換 - data:image/png;base64,... を OgCard に直接渡すから、Satori が画像取りに行くネットワーク往復がゼロになった 4. ついでにやったこと 念のため以下も追加した。 - と に自分の X アカウント - に「りゆうの実験場」 タグの属性を直接制御できない。ただ、モダンなクローラーは 属性なしでも正常に OGP を読み取れるため、実害はなかった。 --- OgCard コンポーネントの切り出し route.tsx 内の JSX が肥大化していたので、 として切り出した。Storybook からも確認できるようになり、デザイン調整がやりやすくなった。 --- 5. vercel 無料枠故 > The Edge Function "api/og" size is 2.37 MB and your plan size limit is 1 MB. お金かけてなくてごめん。これはフォントのせい。 Edge Runtime -> Node.js に戻して GET 事無き まとめ - robots.txt を見直すんだ！！！！ - OPG 生成にかかってる時間をちゃんとチェックしような！！！！ 最終的に OGP の生成は 9.62s → 623ms になった。元が遅いのもあるけど 15 倍で流石に大草原。

by reu · 2026/4/9

Canvas で描く動的な空 — 時刻×天気連動の背景アニメーション 俺のブログの背景に、現在時刻と実際の天気に連動して変化する空を HTML Canvas で描いている話。 夜は星が瞬いて月が浮かび、朝になると空がオレンジに染まって太陽が昇る。雨の日は雨粒が降り、雷雨なら稲妻が走る。全部 canvas 2D API の手描き。 いずれはシェーダーとかでも書いてみたいぜ。 どんな機能？ - 時刻に応じて空のグラデーションが変わる（夜 → 朝焼け → 昼 → 夕焼け → 夜） - フェーズの切り替わりは滑らかにブレンドされる - OpenWeatherMap API から実際の天気を取得して、雨・雪・雲・雷をリアルタイム表示 - 位置情報は IP ベース（許可ダイアログなし）で自動取得 - 天気の手動オーバーライド UI（yaogoromo.exe）でいつでも天気を変えられる - 対応、モバイルではパーティクル数を半減 - タブ非表示時はアニメーション一時停止 アーキテクチャ SkyBackground が hooks とコンテキストを束ねて、計算済みの props を SkyCanvas に渡すだけ。SkyCanvas は純粋な描画マシン。 各レイヤーの解説 1. 天気 API プロキシ Next.js の Route Handler でサーバー側から叩く。API キーをクライアントに露出させない(それはそう) レスポンスは で、 の 10 分キャッシュ付き。 一応API叩けなかった時は晴れ。大抵の場合は晴れてた方が嬉しいからね。 2. 型定義 空のフェーズと天気の種類を型で縛ることで、描画関数のパターンマッチが安全になる。 3. 時刻フック — useSkyPhase 60 秒間隔で 更新。空の変化はゆっくりなのでこれで十分。 がキモで、例えば朝焼けの なら「まだ夜っぽい空にオレンジが混ざり始めた」、 なら「ほぼ昼の空」になる。 この機能がかなり気に入っていて、夕方とかの質感が結構いい感じ。美味しそうじゃない？ 4. 天気データフック — useWeatherData Geolocation API（ブラウザの位置情報許可）は使わない。許可ダイアログみんな嫌いっしょ？ 5. 天気オーバーライド — WeatherOverride Context シンプルな Context + useState。null ならAPI の天気をそのまま使い、値があればそっちを優先。 もっぱら天気書き換え機能のためのやつ。 UI は ウィンドウに 5 つの絵文字ボタン（☀️ ☁️ ☔️ ❄️ ⚡️）を並べてトグル式で切り替える。 6. SkyBackground — オーケストレーション層 hooks を束ねて「今の空はどんな状態か」を1つに解決して SkyCanvas に渡すだけの薄い層。 でコンテンツへのクリックを阻害しない。 で背景に沈む。 layout.tsx からは + でラップされた 経由で読み込む。canvas は SSR で意味ないので初回 HTML を軽くするため。 7. SkyCanvas — 描画の核心 ここが本体。全部 canvas 2D API で手描き。 ちなみにめっちゃ肥大化している。やばい。かなりデブ。 描画レイヤーの重ね順 空グラデーション サイトのカラーパレット（, , , ）に合わせた色設計。夜の空がサイトの背景色 と一致するので、空が読み込まれる前でも違和感がない。 フェーズの切り替わりは canvas はサーバーで意味ないので + でクライアントのみロード。 が body に付いてるので、読み込み完了まではサイトの通常背景色が表示される。 ファイル構成 | ファイル | 役割 | |---------|------| | | SkyPhase, WeatherCondition, WeatherData の型定義 | | | OpenWeatherMap プロキシ API | | | 時刻 → フェーズ + 進行度の算出 | | | IP 位置推定 + 天気取得 + キャッシュ | | | 天気の手動オーバーライド Context | | | canvas 描画の本体 | | | hooks を束ねるオーケストレーション | | | dynamic import ラッパー | | | barrel export | | | Storybook (13+ バリエーション) | | | 天気切り替え UI (yaogoromo.exe) | 設計で意識したこと 関心の分離 データ取得（hooks）→ 状態解決（SkyBackground）→ 描画（SkyCanvas）を明確に分けた。SkyCanvas は / / の 3 つの props だけで完全に動く純粋な描画コンポーネント。Storybook で任意の組み合わせをしたいがためにこの形になってると言っても過言ではない。 IP ベースの位置推定 Geolocation API は許可ダイアログが出る。このブログを初めて訪れた人に「位置情報を共有しますか？」は体験を壊す。ipapi.co なら無料・キー不要・ダイアログなしでざっくりの緯度経度が取れるので、天気を出すには十分。取得失敗しても時刻ベースの空にフォールバックするので何も壊れない。 キャッシュの二重構造 天気データは 2 箇所でキャッシュしてる: - クライアント: sessionStorage に 10 分（SPA 内遷移でリフェッチしない） - サーバー: （API Route レベル） 天気がそんなに頻繁に変わるわけないので、10 分キャッシュで API 呼び出しを最小限に。OpenWeatherMap 無料枠の 1000 回/日もいまんとこ余裕。 アクセシビリティ が有効なら、グラデーション 1 回描くだけでアニメーションループに入らない。視覚的な装飾が苦手な人にもちゃんと配慮。 で背景全体をスクリーンリーダーから隠してる。 プロシージャル生成 雲のテクスチャ画像を用意する代わりに、楕円の重ね合わせで動的に生成してる。アセット管理不要、ランダム性で毎回違う雲ができる、サイズも自由自在。ただし blob 数が多い（雲1つにつき 50〜100 個の楕円）ので、モバイルでは雲の数自体を絞ってる。 書いてる最中に思いついたのでこの変更入れた: https://github.com/ryu1-1uyr/ryu-reu.me/pull/119 雲をオフスクリーンCanvasに一度キャッシュして、描画時はdrawImage一発で表示する。そうすれば毎回計算せんでもよいんじゃないかと言うやつ。

by reu · 2026/4/9

レトロデスクトップ風 UI の実装メモ 自分のブログのトップページを Windows 風のデスクトップ UI にした話。 ドラッグで動かせるウィンドウ、✕ボタンで閉じる、スタートメニューから再起動、ウィンドウのクリックで前面に来る、タスクバーに時計。 全部 React + Tailwind でゼロから組んだよ どんな機能？ - ページ全体がデスクトップ。各コンテンツ（自己紹介、記事一覧、天気操作 etc.）が個別のウィンドウで表示される - ウィンドウはタイトルバーをドラッグして自由に移動できる（モバイルは塞いでる） - ✕ ボタンで閉じる → スタートメニューから再度開ける - ウィンドウをクリックすると z-index が上がって前面に来る - 画面下部にタスクバー。Start ボタン + 時計 - モバイルでは縦積みレイアウトに自動切り替え（ドラッグ無効、全幅表示） - ウィンドウの追加は設定ファイル1箇所 + コンテンツ1行で完了 アーキテクチャ Q: なんで中身は外から注入する形にしたの？ A: 既存のコンポーネントを作り直すの面倒だったから wapperみたいな形を取ればフレームだけ外付けできるじゃ〜んって気がついてそうした。 例の如くまたContext増やしちゃった。状態を遠い位置のコンポーネントに持って行きたい時に毎回使ってしまう。 各レイヤーの解説 1. ウィンドウ定義 — windowRegistry.ts 全ウィンドウの設定を1箇所にまとめた設定ファイル。新しいウィンドウを追加するときはここだけ触ればいい。 ユーティリティ関数もここに: 初期状態の zIndex は なウィンドウに順番に振っていくだけ。閉じてるウィンドウは 。 2. ウィンドウ状態管理 — WindowManager Context 3つの操作だけ: closeWindow — にするだけ。zIndex はそのまま。 openWindow — にしつつ を振って最前面に。 focusWindow — 既に開いてるウィンドウをクリックした時。zIndex だけ更新。 は「今までに振った最大の zIndex」を で持ってて、操作のたびに +1 していく。要は「最後に触ったウィンドウが一番前」になる。OS のウィンドウマネージャーと同じ考え方。 3. RetroWindow — ウィンドウの見た目 状態管理を一切知らない、純粋な表示コンポーネント。 タイトルバーの色テーマ 4色のグラデーション設定を用意: の横グラデーションでタイトルバーを塗る。 は ✕ ボタンのホバー色。 なんか命名もうちょっといいのないかなこの辺 ドラッグの仕組み Pointer Events で実装。タイトルバーの でドラッグ開始: がミソ。これがないとマウスがウィンドウ外に出た瞬間にドラッグが途切れる。キャプチャすることで、ポインターがどこにいても move イベントがタイトルバーに届く。 が （モバイル時）なら全部スキップ。 ウィンドウの装飾 のハードシャドウでレトロ感を出してる。角丸 + 2px ボーダー + ドロップシャドウの組み合わせ。 角丸のせいで若干見切れている気もしているが、一旦ヨシ！！！ ✕ ボタンの横にある ─ と □ は飾り。最小化・最大化は実装してない（~面倒くさいので~要らないんじゃないか） コンテンツ部分は背景の空が透けて見えるように半透明: 4. Desktop — コンテンツとウィンドウの接続 ウィンドウ定義とコンテンツを結びつける場所。 でレジストリを回して、開いてるウィンドウだけ描画する。レジストリの順序 = デフォルトの描画順。zIndex でそこから前後が変わる。 コンテンツは page.tsx から注入: ウィンドウシステムは中に何が入るか一切知らない。Composition パターン。 5. Taskbar + StartMenu タスクバー 画面下部に固定。高さ 40px。半透明 + ブラー。 Start ボタンを押すたびにランダム絵文字が変わる無駄な機能: 右端にはミニマルな時計。10 秒ごとに更新: スタートメニュー をそのまま回すので、ウィンドウを追加すればスタートメニューにも自動で出る。 開いてるウィンドウはテキストが薄くなり、閉じてるウィンドウは「起動」ラベルが出る。 メニュー外クリックで閉じる処理は イベントで チェック: 6. レスポンシブ — useIsMobile で を監視。SSR 時は を返す。 モバイル時の挙動: - ウィンドウは で縦積み（ドラッグなし、zIndex なし） - が適用されて全幅表示 - タスクバーは同じだがウィンドウのクリック前面化は無効 ファイル構成 | ファイル | 役割 | |---------|------| | | ウィンドウ定義の単一ソース（型 + 設定配列 + ユーティリティ） | | | 開閉・zIndex の状態管理 Context | | | ウィンドウの見た目 + ドラッグ | | | レジストリとコンテンツの接続 + レスポンシブ切り替え | | | 画面下部のタスクバー + 時計 | | | スタートメニュー（ウィンドウ一覧 + 起動） | | | モバイル判定フック | | | SSR/クライアント判定フック | | | Desktop に contents を渡す | 設計で意識したこと 単一ソースの定義ファイル ウィンドウの追加に必要な変更は 2 箇所だけ: に定義を追加 + でコンテンツを渡す。スタートメニューの項目、初期状態、zIndex 計算、レスポンシブクラスは全部レジストリから自動生成される。「ここだけ触ればOK」を徹底した。 見た目と状態の分離 RetroWindow は の概念を知らない。渡された props（title, color, zIndex, onClose）で描画するだけ。Desktop が「開いてなければ render しない」を判断してるので、RetroWindow は汎用的なウィンドウ枠として他の場所でも使い回せる。 zIndex のインクリメント方式 ウィンドウの前後関係を のカウンタ1つで管理。タッチ/クリックのたびに +1 して、触ったウィンドウが必ず最前面に来る。OS のウィンドウマネージャーと同じアルゴリズムで、何個ウィンドウがあっても破綻しない。理論上は整数がオーバーフローするまで大丈夫（現実的には問題にならない）。 Pointer Events の採用 かなりいいぞ: https://developer.mozilla.org/ja/docs/Web/CSS/Reference/Properties/pointer-events マウスとタッチを統一的に扱える Pointer Events API を使ってる。 でドラッグ中のポインターをロックすることで、高速にマウスを動かしてウィンドウ外に出てもドラッグが途切れない。Touch Events と Mouse Events を別々にハンドルする必要がなくなった。 モバイルでの割り切り モバイルでは「デスクトップっぽさ」を捨てて実用性に振った。いたしかたなし。 Composition パターン Desktop コンポーネントはウィンドウの中身を一切知らない。 で外から注入される。つまりウィンドウシステムとコンテンツが完全に独立してて、 でラップしたり、任意の React コンポーネントを詰め込める。フレームワークとコンテンツの関心分離。