はじめに — 愛着のあるデザインを捨てる判断
2025年12月にZERONOVA LABを立ち上げたとき、ダークモードを選びました。黒い背景にネオングリーン（#3cf91a）のアクセント。「AIネイティブ実験スタジオ」というコンセプトに合った、サイバーパンク風のデザインです。
3ヶ月間、このデザインでサイトを運営してきました。ツールを追加し、記事を書き、プロダクトを公開し。気がつけば92個のツール、139本の記事、6つのプロダクトがサイトに並んでいました。
3ヶ月前にサイトを立ち上げた時のダーク&ネオングリーンのデザインには愛着があった。でも92ツール・139記事・6プロダクトという規模になった今、コンテンツが主役であるべき。白背景の方がコンテンツが読みやすく、ツールも使いやすい。「カッコいいデザイン」から「使いやすいデザイン」への判断。
2月27日のストーリーログにこう書きました。愛着はある。でもコンテンツ量が増えるにつれて、ダークモードの問題が顕在化してきました。この記事では、なぜライトモードに切り替えたのか、184ファイルをどう一括変換したのか、そして何を学んだかを振り返ります。
ダークモードの限界が見えたとき
コンテンツの可読性
ツールが10個の頃は気にならなかった可読性の問題が、92個になると無視できなくなります。ダークモードでは、ツールのフォーム入力、テーブル表示、コードブロックの視認性に課題がありました。白いテキストを黒い背景で読み続けるのは、記事が長くなるほど目が疲れます。
特に93個の無料ツールのフォーム操作では、入力フィールドのプレースホルダーテキスト、ドロップダウンの選択肢、ボタンの状態変化（有効/無効/ローディング）の識別が、ダークモードでは白背景より難しいことに気づきました。ユーザーがフォームに集中するとき、背景の暗さが視覚的な負荷になるのです。
Bento Gridの限界
トップページはBento Gridレイアウトを使っていました。カード型のレイアウトを不規則に配置するデザインです。6プロダクト + 新着ツール + 最新記事を1画面に詰め込む構成です。
しかしコンテンツ量が増えるにつれて、Bento Gridの「配置の意図」が曖昧になりました。何が新しいのか、何が重要なのか、初めて訪れたユーザーには伝わりにくい。
「カッコいい」と「使いやすい」の乖離
ダーク&ネオングリーンは見た目のインパクトがあります。「AIっぽい」「テック感がある」。しかし92個のツールを実際に使うユーザーにとって、重要なのは「カッコよさ」ではなく「使いやすさ」です。
この判断に至るまでに時間がかかりました。デザインに愛着があると、問題を認めるのが難しい。「もう少し調整すれば何とかなるのでは」「色を微調整すれば読みやすくなるのでは」と、何度も考えました。しかしツールの数が10個から50個、50個から92個に増えるにつれて、部分的な調整では対処しきれない構造的な問題であることが明確になりました。
リニューアルの方向性 — App Store風ライトモードへ
PM-AI 対話: デザインリニューアルの方針
ZeronovaZeronovaZeronovaカラーパレットの設計
ダークモードからライトモードへの色の転換は、単純な反転ではありません。
| 要素 | Before（ダーク） | After（ライト） |
|---|---|---|
| メイン背景 | #0a0a0a（黒） | #f5f5f7（Apple風ライトグレー） |
| カード背景 | #111111 | #ffffff（白） |
| ボーダー | #2a2a2a | #e5e7eb（gray-200） |
| アクセント | #3cf91a（ネオングリーン） | emerald-600（#059669） |
| メインテキスト | #ffffff | #111827（gray-900） |
| 補助テキスト | #a1a1a1 | #4b5563（gray-600、コントラスト比6.18:1） |
特に注意したのはWCAG AA準拠です。ダークモードではtext-gray-400（#9ca3af）で十分なコントラストが取れていましたが、ライトモードでは同じ明度のグレーでは白背景に対してコントラスト不足になります。補助テキストはtext-gray-600（コントラスト比6.18:1、AA基準4.5:1をクリア）に設定しました。
184ファイル一括変換 — sedスクリプトの設計
デザインリニューアルで最も工夫が必要だったのは、92個のツールページの一括変換でした。
ツールページ184ファイルの一括変換は、sedスクリプトで4,568箇所を機械的に置換した。45パターンの置換ルールを定義して、プレースホルダー方式でボタンの
text-whiteを保護するテクニックが必要だった。3分で完了。手作業なら数日かかる量を一瞬で処理できた実感。
2月27日の開発日記の記述です。184ファイル、4,568箇所の変更。手作業では不可能な量を、自動化で3分に圧縮しました。
45パターンの置換ルール
主要な置換パターン:
bg-background-dark→bg-gray-50bg-card-dark→bg-whiteborder-border-dark→border-gray-200text-primary→text-emerald-600text-white→text-gray-900text-gray-400→text-gray-500text-gray-300→text-gray-600
プレースホルダー方式の必要性
一括置換で問題になるのは、ボタンのテキスト色です。ボタンのtext-whiteは白いまま残す必要があります（背景がemerald-600なので）。しかしtext-white → text-gray-900の一括置換では、ボタンのテキストも変わってしまう。
解決策として、プレースホルダー方式を採用しました。
- ボタン内の
text-whiteを一時的に__PLACEHOLDER_TW__に置換 - 全体の
text-white→text-gray-900を実行 __PLACEHOLDER_TW__をtext-whiteに復元
この3ステップで、ボタンの白テキストを保護しながら全体の色変更を実行できました。
テンプレートリテラルの罠
184ファイル中1ファイルだけ、sedで問題が発生しました。table-generator/TableGeneratorForm.tsxのテンプレートリテラル内のバッククォートがsedのパターンに干渉し、TypeScriptのパースエラーが起きました。
この1ファイルだけ手動で修正しました。一括自動化の中で例外が1件、十分許容範囲です。
見えないテキスト — WCAG準拠の落とし穴
一括変換直後にプレビューを確認したとき、一見問題なく見えました。しかし仔細にチェックすると、11個のツールで「ほぼ見えないテキスト」が存在していました。
ダーク→ライト変換で
text-gray-200がそのまま白背景カード内に残っていて、コントラスト比1.14:1 ― 肉眼でほぼ見えないテキストが11ツールに散在していた。
2月28日の開発日記の記述です。text-gray-200（#e5e7eb）は白背景（#ffffff）に対してコントラスト比1.14:1。WCAG AAの基準（4.5:1）を大幅に下回ります。ダークモードではtext-gray-200は黒背景に対して十分なコントラストがありましたが、ライトモードでは完全に不可視です。
45パターンの置換ルールにtext-gray-200の変換が含まれていなかったのが原因です。一括変換のパターンは「よく使われるクラス」をカバーしていましたが、まれに使われるクラスの見落としがありました。
この問題は1回では終わりませんでした。最初に11ツールを修正した後、さらに5ツール・7箇所で追加の視認性問題が見つかり、電子書籍作成ツールでは5箇所の追加修正が必要でした。Markdownのコードブロックやサマリーエリアのテキスト色も修正対象でした。合計で3パスの修正を重ねています。
この経験から分かったのは、「テスト範囲の網羅性」の重要さです。92個のツールすべてを目視で確認するのは現実的ではありません。しかしCSSクラス検索（使用されているグレー系クラスの洗い出し）で機械的にチェックすれば、見落としを減らせます。後から考えれば、sed実行前に「white背景で使ってはいけないテキストカラーのリスト」を作っておくべきでした。
共通コンポーネントの見落とし
もう1つの問題は、site/src/components/ディレクトリの共通コンポーネント（ToolSeoSection.tsx、FeedbackButtons.tsx）が初回のsed対象から漏れていたことです。ツールページの個別ファイルは変換されても、共通コンポーネントがダークモードのまま残っていたため、プレビューで黒い背景のセクションが表示されました。
これは「影響範囲の洗い出し」が不十分だった証拠です。個別ページだけでなく、そのページが参照する共通コンポーネントまで変換対象に含めなければ、整合性が崩れます。実際の影響範囲は、ファイルの依存関係を辿って初めて分かるものです。
20コミットのイテレーション
デザインリニューアルで20コミット以上イテレーションした。最初のコミットから最終形まで、毎回少しずつ調整して収束させていった。「最初から完成形を決めてから作る」のではなく「作りながら調整する」スタイルが、自分には合っている。Claude Code と一緒にリアルタイムで調整できるからこそ可能なスピード感。
ストーリーログの記述です。デザインリニューアルは「一発で完成」しませんでした。20回以上のコミットを重ねて、少しずつ収束させていきました。
1回目のコミット: 基本的なカラー変換とレイアウト変更 2-5回目: 見えないテキストの修正、共通コンポーネントの更新 6-10回目: TodayFeedコンポーネントの設計・実装 11-15回目: ヒーローセクションの簡素化、カード統一 16-20回目: WCAG AA準拠の微調整、レスポンシブ対応
「最初から完成形を設計してから実装する」アプローチでは、この規模のリニューアルは実行できなかったと思います。「作る → 見る → 直す」のサイクルを高速に回すスタイルが、Claude Codeとの協業で可能になっています。
パフォーマンスへの影響 — LCPの一時的な悪化
デザインリニューアルは見た目だけの問題ではありません。パフォーマンスにも影響します。
WebP変換でPNG 4枚を939KB→111KB（88%削減）に圧縮。LCPは2.9s→一時的に4.7sに悪化したが、キャッシュヘッダー修正で2.8sに回復。
2月27日の開発日記です。リニューアルと同時に、トップページの画像をPNGからWebPに変換しました。4枚の画像で939KB→111KB、88%の削減です。ここまでは順調でした。
ところが、Vercelにデプロイした直後にLCP（Largest Contentful Paint）が2.9秒から4.7秒に悪化しました。画像を軽量化したのに、なぜパフォーマンスが悪化するのか。
原因は、デプロイ過程でミドルウェアの設定を実験的に変更した際に、Vercel ISRのキャッシュが無効化されていたことでした。キャッシュヘッダーの修正で2.8秒に回復しましたが、この体験から「デザイン変更とインフラ設定の変更は別のコミットで行う」という教訓を得ました。同時に複数の変更を入れると、問題の切り分けが困難になります。
PM-AI 対話: パフォーマンス監視の仕組み
ZeronovaZeronovaリニューアル直後のSEO監査
リニューアルが完了した直後に、自分で作ったSEO一括監査ツールでトップページをチェックしました。
リニューアル直後に自分で作ったSEO一括監査ツールでトップページをチェックした。見出し階層スキップ（H1→H3）とJSON-LDのimage不足が見つかった。監査ツールを作っておいてよかった。
2月27日の開発日記です。レイアウトを大幅に変更したため、見出し階層（H1→H2→H3）の構造が崩れていました。ヒーローセクションを簡素化した結果、H2を飛ばしてH3が出現する状態になっていました。
JSON-LD構造化データのimage指定の更新も漏れていました。レイアウト変更でOGP画像のパスが変わっていたのに、JSON-LDの方を更新し忘れていた。
どちらも、SEO監査ツールがなければ気づかなかった問題です。自動化ツールを作っておくことの価値を改めて実感しました。ツールを作る、自分で使う、ツールのバグも見つかる、両方改善する。このドッグフーディングサイクルは、個人開発の大きな強みです。
トップページの再設計 — Bento GridからTodayFeedへ
カラー変更と同時に、トップページのレイアウトも全面的に見直しました。
Before: Bento Grid
- 不規則なカードサイズ
- 「何が新しいか」が分かりにくい
- プロダクト・ツール・記事が混在
After: App Store風TodayFeed
- 左カラム: プロダクト固定表示
- 右カラム: TodayFeed（全コンテンツ時系列フィード）
- 統一されたカードサイズ（アスペクト比3:4）
- カード画像からドミナントカラーを自動抽出してグラデーション背景を生成
トップページは Bento Grid → App Store 風のカードフィードに変更。プロダクト・ツール・記事が全部時系列で流れていくUIにした。「作ったものが全部見える」感覚がある。
「作ったものが全部見える」。これがTodayFeedの核心的な価値です。プロダクトもツールも記事も、作った順番に時系列で並ぶ。新しいコンテンツが一番上に来る。シンプルですが、Bento Gridでは実現できなかった「最新性の可視化」ができるようになりました。
TodayFeedのカードは、カード画像からドミナントカラー（支配的な色）を自動抽出し、その色でグラデーション背景を生成します。ピクセルアートエディターのカードはピンク系、OGPチェッカーのカードは青系と、コンテンツごとに異なる色が自動で付与され、フィード全体がカラフルになります。この「自動彩色」の仕組みは、後にGemini APIでカード画像を自動生成するパイプラインと組み合わせることで、「画像生成 → 色抽出 → グラデーション背景」までが完全自動化されました。
ヒーローセクションの簡素化
ヒーローセクションのボタンやロゴを削ぎ落として、コンテンツだけが残った。最初はスカスカに見えて不安だったけど、カードが並ぶとちゃんと密度が出た。
ヒーローセクションからCTAボタン、装飾的なロゴ、キャッチコピーを削除しました。残したのはサイト名と最小限の説明だけ。
最初はスカスカに見えて不安でした。しかしTodayFeedのカードが並び始めると、コンテンツ自体が「密度」を作っていることに気づきました。装飾ではなく、コンテンツが主役のデザイン。これが目指していたものでした。
「おすすめ無料ツール」セクションの追加
リニューアルに合わせて、トップページに「おすすめ無料ツール」セクションも追加しました。「Zeronova's Pick」と「Claude Code's Pick」として、それぞれ4つのツールを選出して表示する仕組みです。
92個のツールの中から初めて訪れたユーザーが何を使えばいいか分からない問題を解消するための導線です。「人間（PM）が選んだおすすめ」と「AIが選んだおすすめ」を並べる構成は、ZERONOVA LABの「AI協業」というブランドコンセプトとも一致しています。
学び — デザインの判断基準は変わる
1. コンテンツ量がデザインの正解を変える
ツールが10個の頃はダークモードが最適だったかもしれません。しかし92個になると、可読性と操作性が優先されます。デザインの「正解」は固定ではなく、コンテンツ量とユーザーの使い方に応じて変化します。
2. 一括変換は「パターン設計」が9割
184ファイルを3分で変換できたのは、45パターンの置換ルールとプレースホルダー方式を事前に設計したからです。実行は一瞬ですが、パターン設計には時間をかけました。自動化は「設計」がすべてです。
3. 自動変換の後に手動チェックは必須
11個のツールで見えないテキストが残っていた事実は、「一括変換で完璧に終わる」という期待が甘いことを示しています。自動化の後には、必ず人間の目によるチェックが必要です。
4. 「作りながら調整する」がデザインリニューアルに向いている
20コミット以上のイテレーションで収束させるスタイルは、大規模なデザイン変更に有効でした。最初から完成形を設計するのではなく、Claude Codeと一緒にリアルタイムで調整しながら進める。このスタイルが可能なのは、AIとの協業があってこそです。
5. 愛着のあるデザインを捨てる勇気
3ヶ月間使ってきたダーク&ネオングリーンのデザインには、確かに愛着がありました。「カッコいい」し「AIっぽい」。しかし92個のツールを実際に使うユーザーにとっては、白い背景の方がフォームの操作も記事の閲覧も快適です。
「自分が好きなデザイン」と「ユーザーにとって最適なデザイン」が異なるとき、後者を選ぶ。プロダクトのためにデザインがあるのであって、デザインのためにプロダクトがあるのではない。PMとしての判断です。
ZERONOVA LABのデザインリニューアルは、見た目の問題であると同時に、「誰のためのデザインか」という根本的な問いへの回答でした。立ち上げ時の「カッコいいデザイン」から、コンテンツが92ツール・139記事に成長した今の「使いやすいデザイン」へ。サイトの成長に合わせてデザインも進化する。その判断プロセスの記録です。
184ファイル・4,568箇所の変更、20コミット以上のイテレーション、3パスの視認性修正、LCPの一時的な悪化と回復。大規模なデザインリニューアルは「一瞬で完成する魔法」ではなく、「小さな調整の積み重ね」です。Claude Codeとの協業がなければ、このスピードでの完了は不可能でした。
関連記事:
Zeronova（ゼロノバ）
Product Manager / AI-Native Builder
Web/IT業界19年以上・20以上のWebサービスを担当したPdM。東証プライム上場企業の子会社代表として事業経営を経験。現在はAIを駆使して企画から実装まで完結させる個人開発を実践中。