記事一覧

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

このツイートのやつ👇 志真コノカさん！！ #bluearchive #ブルアカ pic.twitter.com/f7BOhMSqlv— ReU (@ReU0000) April 2, 2026 いつも飽きないように 2 ~ 3時間着地で作業してるから、18時間はすごい。 切り絵みたいなのを意識して描いた。主線がないイラストっていいよね。 主線消すための色トレスは画面を拡大しまくって 1px とか 1. 5px のペンで描いてた。描いてたというよりも最早ドットを打っていた。 すっごい時間かかったけど色々な学びがあって良かった。 感想列挙 - 素体から描くと構造を意識しやすい - ちまちま進捗上げると見返した時にミスに気が付きやすい - 線画ちゃんと書くと色トレスしやすい - 案外日にちをあけてもモチベが続く - ラフは水彩ぽいペンでぐわ～っと描くと良さげ - 実は画面をめっちゃ拡大して絵を描いてもいい - 色トレスは 1px 単位でやってもいい大変だけど - 色数はそんな多くなくていい - 納得いくまで切り貼りしたって良い - 歪みツール最強 - 3D素体は神 - ぼかしツールはムズイから無理に使わんでもよい - 線画納得いかなかったら薄くしてラフってことにしてしまえばよい - 流石に3 ~ 4回も線書き直せばそれっぽくなる - 顔は影入れなくてもよさげ！ケースにもよるけど 伸びしろ - 髪とか顔の情報量はもうちょっと増やしても良かったな～服に負けてそう - 髪もっと頑張れたんじゃないか？ - 影雰囲気で付けているため変かもしれない - 背景のノウハウが無さ過ぎる - レイヤー使い過ぎなのでもうちょっと整理をしつつだな....

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 コンポーネントを詰め込める。フレームワークとコンテンツの関心分離。

by reu · 2026/4/4

お絵描き×空飛ばし機能の実装メモ 俺のブログ(ファミマには売ってない) に「お絵描きして空に飛ばす」機能を追加した話。 背景に時刻と天気に連動した空の canvas アニメーションがあるんだけど、そこにユーザーが描いた絵を雲と一緒に流せるようにした。 ↑こんなの どんな機能？ 1. スタートメニューから を起動するとお絵描きウィンドウが開く 2. ペンと消しゴムで自由に描く 3. 「☁️ 空に飛ばす」ボタンを押すと、描いた絵がシュッと空に飛んでいく 4. 飛ばした絵は背景の空に合流して、雲と同じレイヤーで左から右にふわふわ流れ続ける 5. 何度でも飛ばせるし、過去に飛ばした絵も全部流れてる 6. ページをリロードすると消える。儚い モバイルは最大5個、PCは最大15個の落書き飛ばせるよん 落書きしてみてね 以下は込み入った話 アーキテクチャ 要はお絵描き側と空の描画側を React Context でつないでるだけ。意外とシンプル。 Context: お絵描きデータの橋渡し サイトにはもともと天気オーバーライド用の があったので、同じパターンで を作った。 (このノリで機能盛っていくとContextすごいことになりそうな気がする) で配列を持って、 で追加するだけ。永続化なし、セッション限り。 layout.tsx で をアプリ全体に被せてる。 お絵描きウィンドウ ウィンドウ登録 サイトのウィンドウシステムは に定義を追加するだけで動く。 windowの管理を一元化しててよかった〜 描画の仕組み 320×240px の HTML Canvas に Pointer Events で線を引く方式。 消しゴムは を使って「透明に戻す」方式。背景が白じゃなくて透明になるので、空に飛ばした時に背景が透けて見えるのがポイント。 座標変換は表示サイズと canvas の内部解像度のズレを吸収してる: モバイルでは + で安定させてる。 飛び立ちアニメーション これ一番雑なのでそのうち直すぞ ボタンを押した瞬間、canvas の上にスナップショット画像を重ねて CSS アニメーションで飛ばす: Tailwind の で として登録。800ms の で上に縮みながら消えていく。 空側: SkyCanvas へのドリフト描画 データの流れ DriftingDrawing 型 → の変換は + で1回だけ。以降のフレームでは で高速に描画。 同期ロジック prop が変わるたびに、まだ にない id のものだけ新規追加する: モバイルは最大5個、PCは最大15個。超えたら古いのを で除去。 雲の直後、天気パーティクルの前に配置。雨や雪は絵の上に降る形になる。 ドリフト描画関数 雲と同じで、右端まで行ったら左端に戻ってまた流れてくる。速度と透明度はランダムなので、絵ごとに違う「浮遊感」が出る。 設計で意識したこと 描画パフォーマンス - → の変換は初回1回のみ。 は GPU アクセラレーションが効くので毎フレーム呼んでも軽い - 320×240 の PNG は 10〜50KB 程度。メモリの心配なし - 上限を設けて古いのを自動削除 消しゴム = 透明 で消すことで、飛ばした時に背景の空が透けて見える。白で塗りつぶす方式だと空に白い四角が浮くことになるので、これが正解。 セッション限り あえて永続化しない選択。気軽に描いて飛ばす「遊び」であって、作品を残す場所じゃないという割り切り。useState だけで完結するのでコードも簡素。

by reu · 2026/3/29

ryu-reu.me 構成メモ ディレクトリ構成 過剰な気もするな --- ブログ機能が多少盛った ちゃんとしたCMSっぽく - 記事エディタ — Markdown エディタ + リアルタイムプレビュー。画像はドラッグ&ドロップで Supabase Storage にアップロードして本文に自動挿入される。下書きは localStorage に自動保存されるので、うっかりタブ閉じても大丈夫。 - ブログ一覧 — ページング付き。Server Component で Prisma から直接取得してるので速いらしい。 - 記事詳細 () — cuid じゃなくて slug ベースの URL になった。人間が読めるURLは正義。シェアボタン付き（X、LINE、コピー）。 認証が入った Supabase Auth 仕組みとしては cookie ベースのセッション管理で、Supabase クライアントを ブラウザ用・サーバー用・ミドルウェア用 に3分割してる。これは Next.js の実行環境ごとに cookie の読み書き方法が違うから。詳しくは を見てもらえれば。 SEO 対策した - にサイト全体のOGP設定 - 記事詳細ページは で記事ごとに動的にOGPを生成 - と を追加。サイトマップは記事の追加・更新に応じて自動生成 DB スキーマ - User: id, email。Supabase Auth のユーザーと同じメアドで紐付け。 - Post: title, slug, content, published, authorId。slug はタイトルから自動生成。 - Image**: url, path, postId。Supabase Storage にアップした画像のメタ情報。 slugの扱いこれでいいのかは納得いってない --- 技術スタック | カテゴリ | 採用技術 | |---------|---------| | フレームワーク | Next.js 16 (App Router) | | 言語 | TypeScript | | スタイリング | Tailwind CSS | | DB/ORM | Supabase (PostgreSQL) + Prisma | | ストレージ | Supabase Storage | | 認証 | Supabase Auth | | アニメーション | framer-motion | | テスト | Vitest | | UIカタログ | Storybook | | CI/CD | GitHub Actions + Vercel | --- まとめ ボイラープレートの域を超えて実際に使えるブログになったと思う。画像アップロード、認証、SEO まで一通り揃ったのでとりあえず記事を書いて運用できそう

by reu · 2026/3/29

USBメモリが無かったのでポータブルSSDだけでBIOSをアップデートした時の記録【MSI / M-FLASH 対応】 はじめに 原神とか OW で出てたマザボの BIOS 更新しろって警告を思い出したのでアップデートした 原神の事前アプデしようとしたらこんな表示が。BIOSのアプデなんてしたことないけど、やるしかないか。 pic.twitter.com/l18o98Qlx1— Aki-Games / あきゲームズ (@gamesaki) January 12, 2026 ↑これのやつ Intel 第 13・14 世代 CPU の不具合修正のために BIOS をアップデートしようとしたら、なんか変な壁にぶつかった。 - BIOS の画面でキーボードが認識されない - USB メモリが手元にない - 手持ちのポータブル SSD（238GB）は NTFS フォーマットで、そのままでは使えない この記事では、その状況を実際に解決した手順をそのまま紹介する。 同じ状況でハマっている人の参考になれば。 --- 前提・環境 - マザーボード: MSI PRO B760-P DDR4 (MS-7D98) - CPU: Intel Core i7-14700F（第 14 世代） - BIOS 更新前バージョン: 1.F7（2023 年 11 月） - 更新後バージョン: 1.F0（v1F / 2025 年 8 月） - 使用したストレージ: ポータブル SSD 238GB（NTFS） --- なぜ BIOS をアップデートする必要があったか 気になったからしらべた。 Intel 第 13・14 世代のデスクトップ向け CPU には、アイドル時・軽負荷時に過剰な電圧リクエストが発生し、CPU の劣化やシステムの不安定を引き起こす不具合が報告されていたっぽい。 この問題はマイクロコード（CPU 内部のファームウェアのようなもの）のアップデートで修正されており、MSI は BIOS に以下のマイクロコードを順次組み込んできた。 | マイクロコード | 内容 | | -------------- | ------------------------------------------------------------ | | 0x129 | CPU が高電圧をリクエストする問題の修正 | | 0x12B | アイドル・軽負荷時の過剰電圧リクエストを修正（0x129 を含む） | | 0x12F | 軽負荷時の CPU 劣化をさらに抑制 | 最新の v1F にはこれらすべてのマイクロコードと ME ファームウェアの更新が含まれている。 --- 問題 ①：MSI Center の Live Update に BIOS が表示されない BIOS 直いじりしたくなかったので GUI からいけないか最初調べてた。 MSI Center の Live Update → Advance を開くと、BIOS の項目がなく LED ファームウェアのみ表示された。いらね～ 原因: Live Update が「現在の BIOS に問題がない」と判断した場合、BIOS の更新を表示しないことがある。「システムに問題がない場合、MSI は BIOS の更新を推奨しません」という赤文字の注意書きもその通り。 対処: 手動で MSI のサポートページから BIOS ファイルをダウンロードして適用する。 --- 問題 ②：BIOS の画面で USB キーボードが動かない これは本件とは関係ないおま環だと思うけど一応記載。 BIOS に入ろうとしても、USB キーボードが認識されず操作できない。 原因: BIOS 起動時は USB の Legacy サポートが無効になっているか、USB 3.0 ポートの初期化が間に合わないケースがある。PS/2 キーボードや一部の安価な USB キーボードは認識されやすいが、ゲーミングキーボードなど専用ソフトが必要なデバイスは認識されないことが多いらしい。 対処: BIOS に完全に入らなくても BIOS を更新できる「M-Flash（Ctrl+F5）」を使う（後述）。 --- 問題 ③：大容量 SSD を FAT32 にフォーマットできない 手元に DTM 用のポータブル SSD しかなかった。USB なんて持ってないよ全部クラウドだよ。 M-Flash は FAT32 フォーマットのストレージしか認識しない。しかし Windows の標準ツール（エクスプローラー・diskpart・PowerShell の Format-Volume）はいずれも32GB を超えるドライブの FAT32 フォーマットに非対応。 > FAT32 は仕様上 32GB までしか対応していないため、Windows はその制限をそのまま守っている。 解決策：SSD の一部だけ FAT32 パーティションとして切り出す 238GB のドライブを丸ごと FAT32 にするのは無理でも、1GB の小さいパーティションを新たに作ってそこを FAT32 にすれば問題ない。BIOS ファイルは 32MB 程度なので 1GB で十分。 --- 実際の手順 Step 1: BIOS ファイルのダウンロード MSI のサポートページから自分のマザーボードモデルを検索し、最新の BIOS ファイルをダウンロードして解凍しておく。 - MSI サポートページ - 例: のようなファイルが含まれている Step 2: SSD に FAT32 パーティションを作成する 管理者権限のコマンドプロンプトを開いて以下を実行。 表示されたディスク一覧から、自分のポータブル SSD の番号を確認する（サイズで判断する）。 番号を間違えると別のディスクのデータが消えるので注意。 既存のパーティションを 1GB 縮小する。 これで G ドライブとして 1GB の FAT32 パーティションが作られる。 Step 3: BIOS ファイルをコピー 解凍した BIOS ファイル（ など）を G ドライブのルート直下にコピーする。フォルダごとではなくファイル単体で置くこと。 ぼくは一回ミスったはずかしい。 Step 4: M-Flash でアップデート PC を再起動し、MSI のロゴが表示されたタイミングで Ctrl+F5 を連打 する。 M-Flash が起動したら、コピーした BIOS ファイルを選択してアップデートを実行。完了まで電源を切らないこと（5 分程度）。 > M-Flash とは: BIOS に完全に入らなくても BIOS を書き換えられる MSI 独自の機能。POST（起動時の自己診断）中に起動するため、BIOS でキーボードが認識されない問題を回避できる。 Step 5: アップデートの確認 再起動後、Windows で を開いて BIOS バージョンを確認する。 バージョンが更新されていれば成功。 Step 6: 後片付け（任意） 作業用に作った 1GB の FAT32 パーティションは不要になるので、元に戻しておく。 その後エクスプローラーからドライブを NTFS で再フォーマットすれば元通り。 --- 注意事項・リスク - BIOS アップデート中に電源が切れると、マザーボードが起動不能になる可能性がある。 ノート PC なら AC アダプターを必ず接続、デスクトップなら UPS があれば理想的。 - BIOS アップデート後は設定がデフォルトにリセットされることがある。XMP の有効化など、カスタム設定をしていた場合は再設定が必要。 - diskpart の操作はディスク番号を必ず確認してから**実行すること。誤ったディスクを選択するとデータが消える。 - 今回の方法は MSI 製マザーボードの M-Flash を前提にしている。他メーカーでは操作が異なるので各社のマニュアルを参照のこと。 --- おわりに USB メモリがなくても、大容量のポータブル SSD しかなくても、工夫次第で BIOS アップデートは完遂できてよかった。 Intel 13・14 世代の CPU 不具合が気になっている人・あらゆるホヨバのゲームで警告がウザくて困ってる人は、ぜひ最新 BIOS への更新を検討してみてね。僕は責任取れないけど....

by reu · 2026/3/19

なんと、眠たい