この記事の対象: 既存サイトのUIを直したいWeb制作者・事業会社のWeb担当者
読了時間: 約12分
「UIを改善したい」と言われたとき、まず何を見るか。配色でもフォントでもなく、迷いが発生している一点です。ボタンの色を変えるより、ボタンが押される直前に読まれている文章を直したほうが効くことは珍しくありません。この記事では、UI改善の事例を「どこを直したか」ではなく「どんな型で直したか」で7つに整理します。Soreiine!!ギャラリーに掲載されているサイトの実装も具体的に見ながら、明日そのまま使える手順まで落とします。
UI改善事例を見る前に決めておくこと

「改善」の定義が曖昧だと事例は役に立たない
UI改善事例を集めても実務で使えないのは、事例の多くが「変更前後のスクリーンショット」で終わっているからです。何をもって改善と呼んだのかが書かれていないと、自分のサイトに移し替えるときの判断基準が作れません。
改善と呼べる状態は、次の3つのどれかに当てはまります。
| 型 | 何が変わるか | 見る指標 |
|---|---|---|
| 迷いを減らす | 選ぶまでの時間・戻る回数 | 直帰率、スクロール到達率、同一ページ内の往復 |
| 手間を減らす | 入力項目数・タップ数 | フォーム離脱率、各ステップの通過率 |
| 不安を減らす | 送信・購入の直前で止まる人 | 最終ステップの完了率、電話問い合わせの比率 |
このどれにも当てはまらない変更は、改善ではなくリニューアルです。悪いことではありませんが、効果を測る設計が別物になるので混ぜないほうが安全です。
変更前の数字を持っていない改善は評価できない
一番よくある失敗が、直してから「効果を測りたい」と言い出すパターンです。比較対象がないので、季節変動なのか改善なのか永久に分かりません。
最低限、着手前に次の4つは控えておきます。
- 対象ページのセッション数(直近28日)
- 対象ページからの遷移先トップ5
- フォームがあるなら各ステップの通過率
- 検索流入の主要クエリと平均掲載順位
計測の道具立てをどう組むかは、こちらに詳しくまとめています。
UI改善事例の7つの型

実務で繰り返し出てくる改善パターンを7つに分けます。事例を見るときも、この型のどれに当たるかで分類すると自分のサイトに移し替えやすくなります。
迷いを減らす
- ①入口の選択肢を絞る
- ②ラベルを行動の言葉にする
- ③現在地を常に見せる
手間を減らす
- ④入力項目を削る
- ⑤エラーをその場で返す
不安を減らす
- ⑥判断材料を直前に置く
- ⑦次に起きることを予告する
上から順に着手すると、改修コストが小さいものから効果を確認できます。
上の3群は改修コストの順にも並んでいます。①〜③はテキストとレイアウトの調整で済むことが多く、④⑤はフロントの実装、⑥⑦はコンテンツ側の追加が必要になります。予算が限られているなら上から潰します。
①入口の選択肢を絞る
トップページに導線を12本並べると、ユーザーは12本とも読まずに検索窓かハンバーガーメニューへ行きます。選択肢が多いほど選ばれないのは、選ぶこと自体がコストだからです。
やることは単純で、ファーストビューに置く選択肢を3つまでに減らします。減らすのではなく、階層をひとつ足して束ねるのがコツです。
実装のポイント
/* 主要導線を3つに絞り、視覚的な重みも3段階にする */
.hero-actions {
display: flex;
flex-wrap: wrap;
gap: 1rem;
}
.hero-actions__primary {
flex: 1 1 14rem;
padding: 1rem 2rem;
background: #1a1a1a;
color: #fff;
border-radius: 4px;
font-weight: 700;
}
.hero-actions__secondary {
flex: 1 1 14rem;
padding: 1rem 2rem;
border: 1px solid #1a1a1a;
border-radius: 4px;
}
.hero-actions__text {
flex: 0 0 auto;
align-self: center;
text-decoration: underline;
}
3つを同じ見た目にしないことが要点です。同じ強さで並べると、結局どれを押せばいいか分からなくなります。主・副・テキストリンクの3段階にすると、迷う時間が目に見えて短くなります。
つまずきやすい点: flex: 1 1 14rem の基準値を小さくしすぎると、狭い画面で2つ並んで文字が折れます。日本語のボタンラベルは全角6〜8文字を想定して基準値を決めます。
対応ブラウザ: Flexbox、gap ともに Chrome 84 / Safari 14.1 / Firefox 63 以降。2026年時点で実質すべてのモダンブラウザで動きます。
②ラベルを行動の言葉にする
「詳しく見る」「お問い合わせ」のような一般名詞のラベルは、押した先で何が起きるか分かりません。押した先の動詞に変えるだけで、クリック率は動きます。
| 変更前 | 変更後 | なぜ効くか |
|---|---|---|
| お問い合わせ | 見積もりを依頼する | 得られるものが明示される |
| 詳しく見る | 施工事例を20件見る | 量が分かると押す理由になる |
| 送信 | この内容で送信する | 直前の確認行動とつながる |
| ダウンロード | 資料をPDFで受け取る(1.2MB) | 形式と重さの不安が消える |
ラベルの長さを恐れる必要はありません。ボタンの中の文字が2行になっても、意味が通るほうが押されます。
③現在地を常に見せる
複数ステップのフローで離脱が起きるとき、原因の多くは「あと何回入力すれば終わるのか分からない」ことです。ステップインジケーターを置くだけで最終ステップの完了率は動きます。
<nav class="steps" aria-label="申し込みの進行状況">
<ol>
<li class="is-done"><span class="steps__num">1</span>内容の選択</li>
<li class="is-current" aria-current="step"><span class="steps__num">2</span>お客様情報</li>
<li><span class="steps__num">3</span>確認</li>
<li><span class="steps__num">4</span>完了</li>
</ol>
</nav>
.steps ol {
display: flex;
list-style: none;
padding: 0;
margin: 0;
counter-reset: step;
}
.steps li {
flex: 1;
text-align: center;
font-size: 0.8125rem;
color: #999;
padding-block: 0.75rem;
border-top: 3px solid #e5e5e5;
}
.steps .is-done { color: #555; border-top-color: #555; }
.steps .is-current { color: #1a1a1a; font-weight: 700; border-top-color: #1a1a1a; }
.steps__num {
display: block;
font-size: 0.75rem;
margin-bottom: 0.25rem;
}
aria-current="step" を入れる理由は、スクリーンリーダーに現在地を伝えるためです。見た目だけで現在地を示すと、読み上げでは4つのステップが等価な項目として読まれます。
つまずきやすい点: モバイルでステップ名が折り返して高さが揃わなくなることが多いので、4ステップ以上なら番号のみ表示に切り替えるメディアクエリを用意しておきます。
④入力項目を削る
フォーム改善は、装飾より項目削除のほうが効きます。判断基準は「この項目が空欄でも、次の一手を打てるか」です。打てるなら消すか任意にします。
残す(必須)
- 連絡先(メールか電話のどちらか)
- 相談内容の自由記述
- 名前
消すか任意にする
- 会社名・部署名
- 郵便番号・住所
- 予算帯・希望納期のセレクト
- 「知ったきっかけ」
右側の項目は「返信してから聞けばいい」ものばかりです。営業側が欲しい情報と、ユーザーが送信できる状態は別物として扱います。
⑤エラーをその場で返す
送信ボタンを押してからエラーが出るフォームは、入力し直しの手間で離脱を生みます。入力欄を離れた時点で検証するだけで体感がまったく変わります。
<div class="field">
<label for="email">メールアドレス</label>
<input type="email" id="email" name="email" required
autocomplete="email" aria-describedby="email-error">
<p class="field__error" id="email-error" role="alert" hidden></p>
</div>
document.querySelectorAll('.field input').forEach((input) => {
const errorId = input.getAttribute('aria-describedby');
const error = errorId ? document.getElementById(errorId) : null;
if (!error) return;
// 入力を離れた時点で検証する(入力中は邪魔しない)
input.addEventListener('blur', () => {
if (input.validity.valid) {
error.hidden = true;
input.removeAttribute('aria-invalid');
return;
}
error.textContent = input.validity.valueMissing
? '入力してください'
: '形式を確認してください';
error.hidden = false;
input.setAttribute('aria-invalid', 'true');
});
// 一度エラーを出した欄だけ、入力中に再検証して消す
input.addEventListener('input', () => {
if (input.hasAttribute('aria-invalid') && input.validity.valid) {
error.hidden = true;
input.removeAttribute('aria-invalid');
}
});
});
input イベントではなく blur で最初の検証をかけるのが要点です。1文字打つたびに赤字が出るフォームは、正しく入力している最中でも責められている感覚になります。一度エラーを出した欄だけ input で追従させると、直した瞬間に赤が消えて気持ちよく進みます。
対応ブラウザ: Constraint Validation API(validity)は Chrome / Edge / Safari 10.1 / Firefox すべてで利用可。autocomplete="email" はモバイルの入力補完に効くので必ず入れます。
つまずきやすい点: hidden 属性は CSS で display: flex などを当てると効かなくなります。エラー表示に Flexbox を使うなら [hidden] { display: none !important; } を書いておきます。
⑥判断材料を直前に置く
フォームの直前や購入ボタンの直前に、判断材料が何もないサイトは多いです。ここに置くべきは会社の歴史ではなく、「送ったあと自分に何が起きるか」と「他の人はどうだったか」です。
- 返信までの目安時間(「翌営業日中に返信します」)
- 相談だけで終わってよい旨の一文
- 直近の実績や口コミ
ECなら口コミの置き方が直接効きます。集め方と見せ方の設計はこちらで扱っています。
⑦次に起きることを予告する
送信ボタンの直上に「送信後、確認メールが届きます」と1行あるだけで、押す前の躊躇が減ります。ECなら送料と配送日の明示が同じ役割を果たします。送料条件を購入直前まで隠している構成は、カート離脱の定番の原因です。
ギャラリー掲載サイトから読む実装のヒント

Soreiine!!のギャラリーには、上の型が実際にどう形になっているかが見える事例が並んでいます。スクリーンショットではなく、実際に触って挙動を確かめられるのが利点です。
見るときの順番を決めておく
ギャラリーを流し見しても学びは残りません。次の4点に絞って見ると、自分のサイトに移し替えられる情報だけが残ります。
この4つをメモしながら10サイト見ると、業種ごとの標準形が見えてきます。BtoBは④の項目数が多めでも通る、飲食・小売は①の選択肢の少なさが効く、といった傾向が自分の手元のデータとして溜まります。
講評から読み取れること
ギャラリーの各サイトには講評と見どころが付いています。「きれい」で終わらせず、なぜその判断をしたのかが言語化されているものを優先して読むと、自分が施主に説明するときの語彙がそのまま増えます。
たとえばレイアウトの選択について。3カラムを古いと切り捨てるか、情報量の多いサイトでは今も有効と判断するかは、扱う情報の性質で変わります。この判断軸そのものを別記事で整理しています。
そのまま真似してはいけない部分
ギャラリーで見た実装をコピーするとき、注意すべき点が2つあります。
- 前提となるコンテンツ量が違う — 実績200件を前提にしたフィルタUIを、実績8件のサイトに載せると空白が目立つだけになります。
- 運用体制が違う — 週次で更新する前提のUIを、年2回しか更新しないサイトに入れると、古い情報が目立つ場所に居座ります。
見た目の型だけ持ってきて、それを支えるコンテンツ供給がない。UI改善が失敗する典型的な原因はここです。
UI改善を検証する手順

1回の改修で触る箇所を絞る
一度に5か所直すと、効いた箇所が特定できません。予算の都合で同時に直さざるを得ないときは、せめて「迷い」「手間」「不安」のどれを狙ったかを記録して、指標を分けて見ます。
「待つ」を飛ばして1週間で判断するケースが多いのですが、曜日の構成が違うと業種によっては数字が大きくブレます。28日単位で切ると曜日が揃うので、比較が素直になります。
検索流入を見るときの注意
UI改善は検索順位に直接は効きませんが、滞在時間や再訪の動きを通じて間接的に影響することはあります。ただし、順位が動かない理由の大半はUIではなくコンテンツの不足です。
分かりやすい例を挙げます。あるキーワードで表示回数は出ているのに、クリックが0件というケース。このとき見るべきは平均掲載順位です。
| 状態 | 数字の例 | 打ち手 |
|---|---|---|
| 順位が低い(30位以下) | 表示は一定数あるがクリックはほぼ0 | UIではなくコンテンツを作る |
| 順位は高いがクリックされない(10位以内) | 表示が多くCTRが低い | タイトルと説明文を直す |
| クリックはあるが成果が出ない | 流入はあるが離脱が高い | ここで初めてUI改善 |
これは決して珍しい状態ではありません。公開したばかりの記事や競合の強いキーワードでは、表示は出てもクリックがほとんど発生しない期間がしばらく続きます。順位が30位より下にとどまっている間は、どれだけUIを磨いてもクリックは増えません。検索結果の1ページ目に出ていない状態は、店の看板が見えない場所に立っているのと同じだからです。
UI改善に着手する前に、そもそも人が来ているかを確認する。順序を間違えると、正しい改修が成果ゼロに見えてしまいます。
CMSごとの改修コストの違い
同じUI改善でも、載っているCMSによって工数はまったく変わります。
- WordPress — 子テーマ側で上書きできる範囲なら比較的安全に触れます。親テーマを直接編集すると更新で消えるので、最初に子テーマの構成を整えておきます。 → WordPress子テーマの作り方|最小構成とfunctionsの書き方
- Shopify — アプリで足すか、テーマを改修するかで保守性が変わります。UI改善の多くはテーマ側で完結しますが、判断の線引きは事前に決めておくべきです。 → Shopifyはアプリとテーマ改修どちらを選ぶか|制作会社の線引き
- 静的サイト — 実装の自由度は高い一方、更新のたびに制作側の手が要ります。頻繁に文言を変えたいならこの前提を先に共有しておきます。
Shopifyでアプリを足してUIを解決しようとすると、月額が積み上がっていくのも見落としがちです。
改善事例を社内・クライアントに説明するとき

スクリーンショットの前後比較だけで出さない
「こうなりました」の画像2枚では、なぜその形になったのかが伝わりません。次の3行をセットで添えると、承認が早くなります。
- 何が問題だったか(数字で)
- どの型で直したか(迷い/手間/不安のどれか)
- 何日後に何の数字を見るか
3つ目が入っていると、改修が「やって終わり」ではなく検証まで含んだ提案に見えます。
期間と費用の話は先に出す
UI改善は範囲が曖昧になりやすい領域です。「ついでにここも」が積み上がると、当初の見積もりから離れていきます。改修の規模や求める品質によって工期・費用感は案件ごとに変わるため、工程ごとに縮められるもの・縮められないものを先に共有しておくと、後半で揉めません。
よくある質問
UI改善の効果はどのくらいで出ますか?
改修そのものは公開した瞬間から効きますが、判断できるだけのデータが溜まるまでに最低28日は必要です。1週間で見ると曜日構成のブレを効果と誤認します。アクセス数が少ないサイトでは、2〜3か月見てようやく傾向が読める場合もあります。
UI改善とリニューアルはどう違いますか?
UI改善は既存の構造を保ったまま、迷い・手間・不安のどれかを減らす部分的な改修です。リニューアルは情報設計から作り直すので、比較対象が消えて効果検証ができなくなります。数字で効果を見たいならUI改善、そもそもの方向性を変えたいならリニューアルと考えてください。
どこから手をつければいいですか?
フォームの直前と、フォームそのものです。この2か所はサイト内で最も離脱が起きやすく、改修コストも小さい割に効果が読みやすい場所です。トップページのビジュアルは、この2つを直したあとで構いません。
検索順位が低くてもUI改善する意味はありますか?
意味はありますが、優先順位は下がります。順位が30位以下なら検索結果に実質存在していないため、UIを磨いても流入は増えません。その状態ではコンテンツの追加が先です。ある程度流入がある状態で初めて、UI改善が数字に表れます。
参考にする事例はどう選べばいいですか?
自社と同じ業種ではなく、同じ課題を持つサイトを探します。BtoBの製造業なら、業種を問わず「フォームに辿り着くまでが長いサイト」の解決例が参考になります。業種で絞ると見た目のトレンドだけを真似することになりがちです。
まとめ
UI改善事例を実務に落とすには、見た目の変化ではなく「何を減らしたか」で読むのが近道です。迷い・手間・不安の3つのどれを減らす改修なのかを先に決めれば、見るべき指標も自然に決まります。
- 着手前に変更前28日分の数字を控える
- 7つの型から、改修コストの小さいものを先に潰す
- 1回の改修で触る箇所を絞り、28日待って判定する
- 順位が30位以下なら、UIではなくコンテンツが先
Soreiine!!のギャラリーは、この型がどう形になっているかを実際に触って確かめられる場所です。入口の数・CTAの文言・フォームの項目数・送信ボタン直上の一文。この4点だけをメモしながら回ると、自分の案件で使える判断材料が溜まっていきます。






