デザイナーやフロントエンド開発者は、自分で認めるよりずっと頻繁に「画像をパレットに変換する」作業をしている。新しいクライアントが資料を渡してきて「同じ雰囲気の Web サイトを作って」と言う。フォトグラファーは、ポートフォリオの全体的なクロムをヒーローイメージと響き合わせたい。マーケティングチームは、トップに置いた製品ショットがランディングページの色調を主導するレイアウトを欲しがる。これらのシナリオはすべて同じ問いから始まる:この画像には実際どんな色が含まれているのか、そして視覚的な重みを担っているのはどれか?

手作業の方法はこうだ:Figma に画像を放り込み、スポイトを長押しし、代表的に見える 5~6 箇所をサンプリングして、HEX をスタイルシートに書き、当たっていることを願う。アルゴリズムの方法はこうだ:すべての可視ピクセルを k 個のグループにクラスタリングし、各グループの平均色とそれが原画像の中で占める割合を返す。占有率メタデータ付きのパレットが下流の判断にそのまま使える。

ブラウザはこの作業に最適なランタイムだ。画像はロード完了の時点でメモリ上にある。Canvas はピクセルデータを直接公開する。数百行の JavaScript で k-means を「即座」に感じる速さで走らせられる。アップロードもラウンドトリップも、第三者があなたの作業を覗くこともない。

画像カラーパレット抽出ツールを開く →

画像駆動のパレットが活きる場面

画像駆動のパレットが輝くのは、ある一連の繰り返しシナリオだ。パターンは常に同じ:ビジュアル素材は固定で、パレットはそれに従わなければならない。

シナリオなぜ画像抽出が手作業に勝るのか
新規クライアントのオンボーディング既存ブランド素材それ自体がパレット。リバースエンジニアリングは、ロゴに合う HEX を当てるより数桁速い。
フォトグラファーポートフォリオサイトのクロムはヒーロー写真と響き合うべき。画像から色を取れば調和は保証される。
EC 商品詳細ページ商品ショットの主要トーンが accent 色、バッジ、CTA ボーダーを駆動し、ページ全体の視覚的連続性を担保する。
ストック画像のランディングページストック画像は厳しい――accent を間違えるとレイアウトが「貼り付けた感」になる。accent を画像自体から取れば外さない。
競合分析自社ヒーロー画像と競合のヒーロー画像の重み割合を並べると、配色戦略が主観から定量に変わる。
編集系カバー画像カバーから 5 色パレットを抽出し、最大占有色をタイトルに、2 番目を著者名に、3 番目を区切り線に。

出発点が「HEX を持っていてカラースキームが欲しい」なら、適切なツールは カラーパレットジェネレーター(補色、類似色、トライアド、テトラッドなどをベース HEX から生成)。出発点が「画像を持っている」なら、リバース抽出が原素材を尊重するワークフローだ。

k-means がパレットを構築する仕組み

k-means はデザイナー向けの結果を出せる最もシンプルなクラスタリングアルゴリズム。4 ステップループ:

1. 画像から k 個のピクセルをランダムに初期セントロイドとして選ぶ。
2. 各ピクセルを RGB 距離が最小のセントロイドに割り当てる。
3. 各セントロイドを所属ピクセル群の平均位置に動かす。
4. セントロイドが動かなくなる(または 24 反復、先に来た方)まで 2、3 を繰り返す。

興味深い設計判断はループ自体ではなく、その周辺にある。

ダウンサンプリング。 4K 写真で k-means を回すと、反復ごとに 800 万回のピクセル比較が必要になり、「即座」に感じるべきブラウザツールには遅すぎる。最長辺を 200 ピクセルにリサイズすれば、約 4 万のサンプルピクセルに圧縮される。8 セントロイド × 24 反復 ≈ 800 万回の距離計算。最近のラップトップで 100 ミリ秒以内に収まる。ダウンサンプリングは重要な色情報を失わない――失うのはどうせ使わない空間情報だ。

初期化。 純粋ランダム選択では、たまに 2 つのセントロイドが極めて近いピクセルに着地する。ツールは初回反復前にサンプリングしたセントロイドを重複排除して最悪ケースを避けるが、k-means 自体は依然として確率的だ。同じ画像、同じ k で 2 回走らせると、わずかに異なるクラスタへ収束することがある。対処は再実行で別シードを試すか、k を大きくしてセントロイドが色空間をより決定論的にカバーするようにする。

距離尺度。 RGB 空間でのユークリッド距離は教科書的選択で、視覚抽出には十分。デザイナーは時に「Oklab のような知覚均等空間ならもっと『自然な』クラスタが出る」と主張するが、実用上の利得は微々たるもの――出力パレットは人の目で見るためのもので、ユーザーは結果を受け取った後に色相や明度で並べ替えできる。RGB のままにしておけば数学は速く、実装は監査可能だ。

クラスタ統合。 重複排除した初期化でも、k-means は時々肉眼で識別できないほど近い 2 つのセントロイドで収束する。ツールは RGB 距離合計が 6 未満の任意の 2 セントロイドを統合し(知覚困難な距離)、ピクセル重みを足し合わせる。結果:k がいくつでも、出力スウォッチが見た目同一になることはない。

プリフィルター。 2 つのフィルターがアルゴリズムから主導権を取り戻す。透明ピクセルを除外(alpha < 128)はデフォルト ON――PNG の alpha チャンネルは可視内容を記述するパレットに含めるべきではない。白に近いピクセルを除外(輝度 > 0.95)はオプション。プロダクトショットでスタジオ白背景がある場合は ON にすればセントロイドが本当の被写体を見つけられる。エディトリアルレイアウトで白それ自体がデザインの一部の場合は OFF。

4 つのカラースペース――それぞれいつ使うか

パレットは次のツールにそのまま貼れて初めて有用になる。本ツールはスウォッチごとに 4 つのカラースペースを出力し、パイプラインで手動変換が必要にならないようにする。

空間強み用途
HEX汎用相互運用性、最短のトークンチャット、GitHub、Figma ファイルメタデータでの共有
RGBモダンなスペース区切り構文 rgb(160 90 44)手書きスタイルシート、CSS 変数
HSL色相 + 彩度 + 明度を単軸でクイックバリエーション、ホバー状態(明度 +10%)
OKLCH知覚均等な L、C、Hデザイントークン、自動パレット生成、コントラスト感応シフト

OKLCH は現場コードで未だ過小評価されているので、もう少し詳しく語る価値がある。HSL の L 軸は数学的にシンプルだが、知覚的には不均一だ――L=50 から L=70 への変化は、青よりも黄色で大きく見える。OKLCH はその軸を Oklab から導出された知覚均等な L で置き換える。結果として、自動変換(10% 明るくする、色相を 30° 回転させる)の出力が人間の目に等間隔のステップに見える。予測可能な明度ランプが必要なデザイントークンシステムを構築するなら、OKLCH が正しい出力フォーマットだ。

典型的な落とし穴

自動パレット抽出を初めて使う人を躓かせるパターンがいくつかある。

画像に巨大な白に近い背景がある。 8 個のセントロイドのうち 3 つがオフホワイト域に着地し、写真の実際の被写体は 1~2 スウォッチしか貢献しない。「白に近い色を除外」を ON に――アルゴリズムが輝度 > 0.95 のピクセルを無視し、解放されたセントロイドが本当のコンテンツを見つける。

画像のほとんどが透明。 Alpha プリフィルターは一般的なケース(透明背景上の PNG アイコン)を処理する。完全透明の場合、ツールは「フィルター適用後、可視ピクセルが残っていません」と報告し、空のパレットをレンダリングしない。

実行ごとに結果が変わる。 これは k-means のランダム初期化のせい。修正は k を大きくする(セントロイドが多いほどランダムシードが広く分散する)か、「主要 3~4 色は安定、後ろの 4~5 色は揺れる」を受け入れる。気にする色がロックインするまで再抽出を押す。

抽出された色がスポイトサンプルと違う。 k-means が報告するのは各クラスタの平均値で、サンプリングしたピクセルではない。写真が左の深紅から右のオレンジへグラデーションしている場合、k-means はおそらくクラスタ中心が落ち着いた中間色を返す。スポイトはその点の色を返す。両方とも正しいが、別の問いに答えている。写真の特定の特徴と一致する accent 色が必要なら手動サンプリング、画像の語気を要約するトーンパレットなら k-means。

シンプルな画像に多すぎる色を要求する。 黒地のロゴはせいぜい 3~5 色。16 を要求すると k-means はほぼ同一のグループを分割してマイクロクラスタを発明する。出力は問題ないが実質的に重複を含む。クラスタ統合ステップが極小距離を除外するが、画像の実際の色数に合わせて k を下げる方が良い。

実用的なワークフロー

最も速くアウトプットが出る流れ:

1. 元画像をドロップ。デフォルトは k=8、頻度順ソート。
2. 画像にスタジオ白背景があれば「白に近い色を除外」を ON。
3. 「再抽出」を 1~2 回押し、主要色が安定することを確認。
4. 任意のスウォッチの色ブロック部分をクリックして HEX をコピー。
5. 「CSS 変数をコピー」で :root ブロック全体を取得。
6. デザイントークンに貼り付ける。
7. 最も重要な色対をカラーコントラストチェッカー
   (https://zerotool.dev/ja/tools/color-contrast-checker/) で確認、
   テキスト + 背景の組み合わせが WCAG AA を満たすか検証。

Tailwind config を保守しているなら、「Tailwind をコピー」ボタンが theme.extend.colors.palette 配下に直接ドロップできるスニペットを c1 から cN の命名で吐く。後でドメインに合わせて (primaryaccentsurface 等) 改名すれば完了。

プライバシーとパフォーマンス

ブラウザはこの種の作業に対してプライバシー友好的なランタイムだ。画像は FileReader.readAsDataURL で読み込まれ、HTMLImageElement にデコードされ、サンプリング解像度で隠し Canvas に描画され、JavaScript で CPU 上にクラスタリングされる。画像バイトとピクセルデータはデバイスから出ない――ページ上の唯一のネットワーク要求は、ツールがロードされた時の静的アセットのみ。

Apple Silicon Mac で実測したパフォーマンスデータ:

画像デコード + 描画k-means (k=8)合計
800×600 PNG~12 ms~35 ms~47 ms
1920×1080 JPEG~25 ms~40 ms~65 ms
3840×2160 JPEG~70 ms~45 ms~115 ms
8000×6000 写真~180 ms~50 ms~230 ms

k-means の実行時間はダウンサンプリング後のバッファサイズに制約され、ソース画像とは無関係なので、巨大な写真は主にデコード描画フェーズで遅くなる。

Adobe Color、Coolors との違い

Adobe Color の「画像から抽出」タブはこの分野の確立されたベンチマークで、美しい 5 色パレットを産出する。サーバーサイドで動き、Creative Cloud ライブラリにパレットを保存するためにサインインを要求し、Adobe エコシステムの中で既に生活しているデザイナー向けに最適化されている。Coolors の画像ピッカーもスコープは似ている。両方ともインスピレーション探しには良いが、結果をコードに出荷するときには少しずれを感じる。

ZeroTool の抽出器は別の niche に位置する:別タブでスタイルシートを開いている開発者のための「タブを開けばすぐ使える」ツール。トレードオフ:

  • スウォッチごとに 4 つのカラースペース(HEX、RGB、HSL、OKLCH)を並列表示――コードへのコピーで変換ステップが省ける。
  • パレット画像ではなく、CSS 変数、JSON、Tailwind 設定への一括エクスポート。
  • k は 3 から 16 で調整可能、固定 5 ではない。
  • スウォッチごとの占有率パーセント――どの抽出色をブランド accent にするか決めるときに重要。
  • ページロード後 100% オフライン。
  • 履歴パレット保存なし、クラウドライブラリなし、チーム共有なし――意図的。「保存」はアカウントを必要とし、アカウントはデータがブラウザを離れることを意味するから。

チームで共有できるライブラリにパレットを保存する必要があるなら Adobe Color が正解。:root ブロックに 30 秒以内にパレットを落とし込む必要があるなら、このツールがその用途で作られている。

日本のフロントエンド現場での補足

Qiita / Zenn 記事の表紙画像から色を取って記事内ヘッダー色に使う、note の見出し画像と一致するアクセント色を本文側に入れる、こうしたユースケースは小さく見えてやってみると効果が大きい。Adobe Color を毎回開くより、別タブで開くだけの軽量ツールの方が癖になる流れ。

もう一つの実用例:プロダクトのスクリーンショットから抽出した色を、その UI のスクリーンショットを引用するブログポストの装飾色として使う。コンテンツとビジュアルの色温度が揃い、読者にストレスをかけない。

さらなる読み物

画像カラーパレット抽出は ZeroTool のカラーツールファミリの一員。出荷前にコントラストチェッカーで検証し、抽出色を完全な明度ランプに展開する必要があるときはシェード生成器とペアで使う。