画面を大きくしたのに、ぼやけて見えた。見本を鮮明にするために見直したこと

2026年11月5日 15:30

大きく見せれば、作品も伝わりやすくなる。そう思って用意した画面見本に、「後ろがぼやけてる」と指摘を受けた。

10月27日の自社サイト制作記録に残っている場面だ。PCの枠の中へ長い画面画像を入れ、動かして見せる設計だった。画面そのものが大きくなっても、文字や写真がすっきり読める状態にはなっていなかった。

僕にとって、この件の学びは「高画質の画像を使おう」の一言では収まらなかった。元の画像、置き方、動かし方、後ろの装飾を分けて確かめる必要があったからだ。

ぼかす設定は、入っていなかった

記録を読むと、当時の画像には圧縮したJPEGが使われ、PCには傾きが付き、長い画像全体を変形させながら移動していた。さらに薄い背景文字が重なる構成だった。

一方で、画像へ直接ぼかしを加える設定は見つかっていない。ぼやけて見えるからといって、原因が一つのぼかし効果にあると決められる状態ではなかった。

実際の描画による劣化量も測定していない。だからこの記事でも「GPUが原因だった」「この設定を外せばどんな画面でも直る」とは書けない。確認記録にある変更をたどり、見本をどう確かめ直したかを残したい。

最初に行ったのは、公開されている元の画面を開き、PNGで取得し直すことだった。保存済みのJPEGをPNGへ変換しただけではない。元の表示から取り直した点が大切だと思う。

一度小さくした画像や圧縮した画像を別形式で保存しても、元にあった細部が自動で戻るわけではない。今回は、見せたい画面を元の場所から取得する工程へ戻った。

使ったPC画面の画像は幅1280px。ページ内でどの大きさに表示するかも合わせて見た。元画像の数字だけを基準にせず、実際の枠の中で文字や写真がどう見えるかを確かめるためだ。

写真が遅れて読み込まれるページでは、その場所まで表示してから取り直した。何もない余白が写っていても、画像ファイル自体は正常に保存できてしまう。見たい内容が写っているかまで見る必要があった。

次に、PCの枠を正面へ戻した。画像全体を変形しながら動かす方式もやめ、固定した窓の中で画面をスクロールさせる設計に変えた。

背景の薄い文字を隠し、広い影や背景をぼかす演出も弱めた。画面の内容を読んでほしい場所へ、別の情報を重ねすぎないようにした形だ。

ここで、演出を全部同じように取り払ったわけではない。スマホの動きや作品ごとの見せ場は残している。何を見せたい場面かを考え、PCの文字を読ませたい場所では、その役割を優先した。

これは僕の設計上の判断だ。立体的な見せ方が悪いという話に広げる必要はない。作品の雰囲気を伝える場面と、細部を読ませる場面では、必要な見せ方が変わる。

見栄えのよい大きな写真だけでは、鮮明さを判断しにくい。僕なら、作品の中の小さな見出しや、細い線を比較する場所に選ぶ。元のPNGで読める文字が、表示した枠の中ではつぶれていないかを見るためだ。

確認する幅も、元画像の大きさと同じにするだけでは足りない。PCの枠へ縮めた状態と、スマホで一覧を見る状態を分けて見る。拡大すれば読めることより、実際の見せ方でどう見えるかが問題になる。

今回の記録では、いくつかの画面幅と動きの確認は残っている。それを全端末での評価へ広げず、次に比べる場所が分かる材料として残したい。

変更後の記録には、375px、768px、1280pxの表示幅で、画像の読み込みや枠の収まりなどを確認したことが残っている。スクロールが進み、停止できることも見た。

ただし、これはローカルの確認版について実施した範囲だ。本番への反映、すべての実機、作品品質の最終判断まで一緒に済んだことにはしない。

画面見本を渡す仕事なら、僕は次の三枚を残したい。

一枚目は、元の表示。二枚目は、ページ全体の中で使う大きさ。三枚目は、文字や写真が分かる寄りの表示。同じ対象をこの三つで見ると、元画像の問題か、置き方の問題かを話しやすくなる。

動きを付ける場合は、静止した一瞬に加え、動いている途中も見る。止めた状態は鮮明でも、移動中に読みづらくなる場合があれば、どちらを優先するか相談できるからだ。

AIへ「もっとリアルに」「もっと高画質に」と頼み続ける前に、手元の見せ方も確かめたい。今回の記録では、元画面からの再取得と、表示の整理という具体的な作業へ戻った。

今日の一歩は、自分の制作例を一つ、普段読まれる大きさで開くこと。作品名を知らない人が、その文字や写真を追えるか。作り手が拡大して確認した画面と、読む人の画面を近づけるところから始めたい。

※2026年10月27日の自社制作記録に基づきます。画像・表示方法の変更と、確認した範囲を記載しています。