COLUMN
よく検索されるキーワード
2026/08/19
デザイン・ブランディングWebサイトにアニメーションは必要？印象と操作性を高めるモーションデザイン
Webサイトのアニメーションは「動かせばおしゃれ」ではない ホームページ制作の打ち合わせで、 「スクロールしたら文字を動かしたい」 「もっと動きのあるサイトにしたい」 「最近のサイトみたいにアニメーションを入れたい」 という要望をいただくことがあります。 確かに、アニメーションはWebサイトの印象を大きく変える要素です。 しかし、動けば動くほど良いサイトになるわけではありません。 アニメーションには本来、 ユーザーの視線を誘導する 操作結果を分かりやすくする 情報同士の関係を伝える ブランドの世界観を表現する といった役割があります。 目的のない動きを増やしてしまうと、かえって「読みにくい」「操作しづらい」「表示が遅い」サイトになる可能性があります。 まず結論：アニメーションは「ユーザーの理解と操作を助ける時」に使う アニメーションを入れるか迷ったときは、次の質問をしてみてください。 「この動きがあることで、ユーザーにとって何が分かりやすくなるのか？」 答えがあるなら、そのアニメーションには意味があります。 逆に、 なんとなく今っぽいから 動かないと寂しいから 他社サイトも動いているから だけであれば、本当に必要か一度検討した方がよいでしょう。 良いモーションデザインとは、装飾ではなく、ユーザーとのコミュニケーションを助ける設計の一部です。 Webサイトでアニメーションを使う5つの目的 視線を誘導して、重要な情報に気づかせる ページ内のすべてを同時に見せると、ユーザーはどこから見ればよいか迷うことがあります。 そこで、 見出しを先に表示する 次に説明文を表示する 最後にCTAを表示する といった順番を作ることで、視線を自然に誘導できます。 重要なのは、読ませたい順番と動く順番を一致させることです。 操作結果を伝えて「ちゃんと動いた」と感じてもらう モーションデザインは、操作へのフィードバックにも使えます。 例えば、 ボタンを押したら色や形が少し変化する メニューを開くと滑らかに展開する フォーム送信中に「送信中」と表示する お気に入り登録後にアイコンが変化する といったものです。 こうした小さな動きには、ユーザーへ「操作が受け付けられた」ことを伝える役割があります。 情報の変化や関係性を分かりやすくする 文章だけでは説明しづらい情報も、動きを加えることで理解しやすくなる場合があります。 例えば、 サービス利用までの流れ Before／After 数値の変化 グラフの推移 製品の仕組み システムの処理フロー などです。 「何が、どのように変わったのか」を伝える場面では、静止画よりモーションが適していることがあります。 スクロール体験にリズムを作る 長いページでは、同じレイアウトが続くと単調に感じられることがあります。 そこで適度に、 写真をフェードインさせる 見出しを少し遅れて表示する 数字をアニメーションで見せる などの変化を加えることで、ページ全体にリズムを作れます。 ただし、すべてのセクションを動かす必要はありません。 重要な場所に絞って使用するからこそ、動きが効果を発揮します。 ブランドの世界観や個性を表現する 動きにも「性格」があります。 例えば、 ゆっくり滑らかに動く→ 上質・落ち着き・高級感 軽快に素早く動く→ 親しみ・若さ・スピード感 直線的でシャープに動く→ 先進性・テクノロジー・合理性 というように、動き方によってブランドの印象は変わります。 色・フォント・写真と同じように、モーションもブランドを構成するデザイン要素として設計できます。 効果的なモーションデザイン｜使いやすい7つのパターン フェードイン｜コンテンツを自然に見せる スクロールに合わせて、文章や写真が少しずつ表示される表現です。 比較的使いやすく、 トップページ サービス紹介 会社紹介 採用サイト など幅広いページで利用できます。 ただし、表示速度を遅くしすぎないことが重要です。 ユーザーが読みたいのに、アニメーションが終わるまで待たされる状態は避けましょう。 ホバー・タップ｜操作できることを伝える PCでカーソルを合わせた際に、 色が変わる 少し浮き上がる 矢印が動く 写真がわずかに拡大する といった変化を加える方法です。 これは装飾というより、「ここは押せる場所です」と伝えるUI上のフィードバックとして機能します。 スマートフォンではホバー操作が基本的にないため、通常状態でもリンクやボタンであることが分かり、タップ時にも適切な反応が返る設計にしましょう。 ボタンフィードバック｜操作結果を返す CTAやフォームの送信ボタンでは、 押した瞬間に状態を変える 送信中であることを表示する 完了したことを伝える といったフィードバックが重要です。 「押したのに何も起きない」と感じると、連続クリックや離脱につながる可能性があります。 数字・グラフ｜変化や実績を理解しやすくする 例えば、 制作実績 300件 と表示するだけでなく、数字が自然にカウントアップする演出があります。 ただし、ここで大切なのは数字そのものの信頼性です。 演出を強くしても、根拠のない実績表示が許されるわけではありません。 「○件」「No.1」「○％改善」などを掲載する場合は、集計期間・条件・根拠を確認したうえで表示しましょう。 スクロール連動｜ストーリーを順番に伝える スクロールに合わせて、 課題 原因 解決方法 成果 のように順番に内容を見せる方法です。 ブランドストーリーや、複雑なサービス内容の説明と相性があります。 一方で、背景が大きく動くパララックスなどは、ユーザーによって不快感やめまいを感じる場合があります。 必要な場所に絞り、後述する「動きを減らす設定」への対応も検討しましょう。 ローディング｜待ち時間の不安を軽減する データ処理などで待ち時間が発生する場合、 スピナー プログレスバー スケルトンスクリーン などを表示することで、処理中であることを伝えられます。 目的は、かっこいいローディング画面を見せることではありません。 「サイトが止まったわけではない」とユーザーに伝えることです。 ページ遷移｜サイト全体の世界観をつなぐ ページを切り替える際に軽いトランジションを入れると、サイト全体を一つの体験として見せることができます。 ブランドサイトや採用サイトなど、世界観を重視するサイトでは効果的です。 一方で、ページを開くたびに長い演出が入ると、それ自体が待ち時間になります。 演出より、ユーザーが必要な情報へ早くアクセスできることを優先するのが基本です。 逆効果になるアニメーション7つ｜やりすぎに注意 何でもスクロールで動かす すべての文章や画像が、 下から出る → 横から出る → 回転する → 拡大する という状態になると、どこが重要なのか分からなくなります。 動かす場所と動かさない場所を分け、メリハリをつけましょう。 表示されるまで待たされる スクロールしたにもかかわらず、コンテンツが1秒後、2秒後まで表示されない。 これは演出ではなく、ユーザーにとって待ち時間になる可能性があります。 文章や重要情報は、すぐに確認できることを優先しましょう。 CTAまで動かして押しにくくする 問い合わせボタンを常に揺らしたり、大きく動かしたりすると、注意を引くどころか不快感につながる場合があります。 CTAは、 目立つことより、見つけやすく押しやすいこと を優先します。 パララックスを多用する パララックスは印象的な表現ですが、使いすぎると、 読みにくい スクロール位置を把握しづらい 動作が重くなる 動きに不快感を感じる人がいる といった問題が生まれます。 ブランド表現として必要な場所だけに限定するのがおすすめです。 自動再生を止められない 自動で動き続けるスライダーやコンテンツは、ユーザーの注意を奪う可能性があります。 一定時間以上自動で動き続けるコンテンツでは、必要に応じて、 一時停止 停止 非表示 などの操作を用意します。 そもそも、自動で動かす必要があるのかから検討することも大切です。 スマホで重くなる PCでは滑らかでも、スマートフォンでは動作が重くなる場合があります。 特に、 大きな動画 複雑なJavaScript 大量のスクロールアニメーション 重いぼかしや描画処理 などは注意が必要です。 PCブラウザだけで判断せず、実際のスマートフォンで確認しましょう。 「動かすこと」が目的になっている 最も避けたいのが、アニメーションを入れること自体が目的になる状態です。 演出が優先され、 ユーザーの目的 ＜ 制作側の演出 になってしまえば、サイト本来の役割から離れてしまいます。 迷ったら、 「なくしても情報は伝わるか？」「入れることで、理解・操作・印象の何が良くなるのか？」 を確認しましょう。 表示速度への影響｜アニメーションとCore Web Vitalsの考え方 アニメーション自体がSEOで直接評価されるわけではありません。 一方で、実装方法によってページの読み込みや操作性、表示の安定性などを悪化させれば、ユーザー体験へ影響します。 GoogleのCore Web Vitalsでは、 LCP：読み込みパフォーマンス INP：操作への応答性 CLS：表示の視覚的安定性 が主要指標として使われています。 そのため、アニメーションを実装した際には、 「動きが追加されたことで、表示や操作が重くなっていないか」 まで確認することが重要です。 アニメーション実装ではtransform・opacityを中心に検討する CSSアニメーションでは、実装方法によってブラウザへの負荷が変わります。 一般的には、 transform opacity など、レイアウト計算への影響が比較的小さいプロパティを中心に使用すると、滑らかなアニメーションを実装しやすくなります。 一方で、要素の大きさや位置を直接変更し、頻繁なレイアウト再計算を発生させる実装は、動作が重くなることがあります。 デザインだけでなく、実装後のパフォーマンスまで含めてモーションを設計することが重要です。 アクセシビリティも重要｜「動きを減らしたい人」への配慮 アニメーションは、すべてのユーザーにとって快適とは限りません。 大きな移動、ズーム、パララックスなどによって、不快感やめまいなどを感じる人もいます。 Webでは、OSなどで「動きを減らす」設定を利用しているユーザーを検知するprefers-reduced-motionという仕組みがあります。 例えば、 大きなスライド移動をフェードに変更する パララックスを停止する 装飾アニメーションを無効にする 不要な自動再生を停止する といった対応が考えられます。 重要なのは、「アニメーションが動かなくても情報や機能を利用できる状態」にしておくことです。 モーションを重要情報の唯一の伝達手段にしないようにしましょう。 ブランドらしいアニメーションを作る3つのルール 動きの速さを統一する 同じサイト内で、 あるボタンは非常に速い 別のボタンはゆっくり 写真はさらに遅い となると、統一感が失われます。 例えば、 小さな操作 コンテンツ表示 ページ遷移 など用途ごとに、ある程度速度のルールを決めておくと整いやすくなります。 動き方を2〜3種類に絞る 例えば、 基本：フェード 強調：軽いスライド 操作：ホバー・タップ時のフィードバック という程度でも十分です。 色やフォントと同じように、モーションにもルールを設けることで、サイト全体の統一感を作れます。 ブランドの性格から動きを決める ブランドの方向性を言葉にしてから、動きへ落とし込む方法も有効です。 例えば、 誠実／安心／上質→ ゆっくり・滑らか・動きは少なめ 親しみ／活発／楽しい→ 軽快・反応が分かりやすい・適度な弾み 先進的／合理的／シャープ→ 素早い・直線的・無駄の少ない動き というように、モーションをブランド表現の一部として設計できます。 導入前に考えるべき判断基準｜そのアニメーション、本当に必要？ アニメーションを実装する前に、次の6点を確認しましょう。 目的は何か？ 視線誘導・操作フィードバック・情報理解・ブランド表現のどれを目的としているか明確にします。 動かなくても情報は伝わるか？ アニメーションが停止した場合でも、必要な情報や機能を利用できる状態にします。 表示を待たせないか？ ユーザーが情報を確認する邪魔になっていないか確認します。 スマホでも快適か？ PCだけでなく、実際のスマートフォンで操作・スクロールを確認します。 動きを減らしたいユーザーにも対応できるか？ 不要なモーションを停止・軽減できる設計か確認します。 サイト全体で統一されているか？ ページごとに異なる動きを追加せず、一定のルールで運用します。 この6点に答えられれば、目的のあるアニメーションになりやすくなります。 このまま使えるモーションデザイン改善チェックリスト 目的 アニメーションを入れる理由を説明できる 「おしゃれだから」だけになっていない ユーザーの理解・操作・視線誘導のいずれかを助けている ブランドの世界観と動き方が合っている 見やすさ コンテンツ表示を必要以上に待たせていない 動きが多すぎて文章を読みにくくしていない CTAが動きすぎていない スクロール位置を把握しやすい 動かなくても必要な情報が伝わる 操作性 ボタン操作後に適切なフィードバックがある メニューの開閉が分かりやすい 処理中であることが分かる 自動で動き続ける要素を必要に応じて停止できる パフォーマンス スマートフォン実機で確認している アニメーション追加前後で表示速度を確認している Core Web Vitalsへ大きな悪影響が出ていない 不要に重い動画・JavaScriptを使用していない 実装方法も含めてエンジニアと確認している アクセシビリティ 大きなパララックスやズームを多用していない 不要な点滅・激しい動きを避けている 動きを減らしたいユーザーへの対応を検討している アニメーションがなくても情報や機能を利用できる 運用 使用する動きの種類が決まっている ページ追加のたびに新しいアニメーションを増やしていない デザインガイドラインにモーションのルールがある まとめ：良いアニメーションは「気づかれないくらい自然」に機能する Webサイトのアニメーションは、必須ではありません。 動きがほとんどなくても、情報が分かりやすく、使いやすく、ブランドらしさが伝わるサイトは作れます。 一方で、適切に使えば、 重要な情報へ視線を誘導する 操作結果を分かりやすく伝える 複雑な情報を理解しやすくする サイトを心地よく読み進めてもらう ブランドの個性を表現する といった効果が期待できます。 重要なのは、 「どこを動かすか」ではなく、「なぜ動かすのか」。 目立つアニメーションより、ユーザーが意識しなくても自然に操作できるモーションの方が、優れたデザインであることも少なくありません。 アニメーションは「足し算の装飾」ではなく、理解・操作・ブランド体験を整えるための設計要素として考えましょう。 アニメーションを活かしたWebサイト制作・改善もRefuにご相談ください Refuでは、見た目のインパクトだけを目的にアニメーションを追加するのではなく、サイトの目的・ブランド・ユーザー導線を整理したうえで、必要な場所に必要な動きを設計します。 デザインだけでなく、スマートフォンでの操作性や表示速度、アクセシビリティにも配慮しながら、サイト全体の体験としてモーションを設計します。 「動きのあるサイトにしたいけれど、やりすぎたくない」「今のアニメーションがユーザーの邪魔になっていないか確認したい」「ブランドらしい動きを取り入れたい」 といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら “かっこいいだけ”では伝わらない。成果を生むデザイン思考とは UI/UXとは何か？成果を左右するユーザー体験設計の基本｜使いやすさで変わるサイトの成果 ファーストビューで離脱させない｜コピー×デザインの最適バランス ブランドを言語化する「3語ルール」｜デザインがブレない軸の作り方 スマホで差がつくUI改善｜押しやすさ・読みやすさのチェックポイント デザイン改修で成果を出すA/Bテスト入門｜小さく検証して勝ちパターンを作る Webアクセシビリティを意識したデザインとは？中小企業サイトの改善ポイント
2026/08/17
ホームページ制作の基本問い合わせフォームに迷惑メールが届く原因｜スパム対策と安全な運用方法
問い合わせフォームに迷惑メールが届くのはなぜ？ ホームページを運用していると、突然、 英語や外国語のメッセージ 意味のない文字列 大量のURLが記載された投稿 仮想通貨・SEO・営業サービスなどの宣伝 同じ内容が短時間に何十件も送られてくる といった迷惑メールが届くことがあります。 「メールアドレスが漏えいしたのでは？」 と心配になるかもしれませんが、問い合わせフォーム経由の迷惑メールの場合、必ずしもメールアドレスが流出しているとは限りません。 多くの場合は、Bot（自動プログラム）がWeb上のお問い合わせフォームを発見し、自動的に情報を送信していることが原因です。 現在のWebサービスでは、不正な自動アクセスを完全に一つの仕組みだけで防ぐのは難しく、OWASPもBot対策について、WAF・レート制限・行動判定・Honeypot・CAPTCHAなどを組み合わせた多層的な対策を推奨しています。 そのため、 「迷惑メールが来た＝サイトが乗っ取られた」 と判断するのではなく、まずはどこから送信されているのかを切り分けることが重要です。 まず確認｜「フォームスパム」と普通の迷惑メールは別物 迷惑メール対策を始める前に、まず確認したいのが、 「ホームページのフォーム経由なのか」 という点です。 フォームスパム ホームページの入力フォームをBotなどが自動送信し、その内容が管理者宛ての通知メールとして届いている状態です。 この場合は、 CAPTCHA・Bot対策 Honeypot 送信回数制限 WAF 入力チェック など、ホームページ側の対策が有効です。自動化された不正利用については、一つの防御だけではなく複数レイヤーを組み合わせることがOWASPでも推奨されています。 メールアドレスに直接届く迷惑メール 一方、 info@example.jp など、公開しているメールアドレスへ直接迷惑メールが送られている場合は、問い合わせフォームとは別問題です。 このケースではフォームにCAPTCHAを追加しても解決しません。 メールサーバー側の迷惑メールフィルターや、メールアドレスの公開方法などを確認する必要があります。 まずは、 「フォームから送信されたものなのか、メールアドレスへ直接届いているのか」 を確認しましょう。 問い合わせフォームが狙われる主な原因 問い合わせフォームへのスパムが増える理由には、いくつかあります。 誰でも送信できる公開フォームだから お問い合わせフォームは、基本的にログインせず誰でも利用できます。 正規ユーザーにとって便利である一方、Botから見てもアクセスしやすい場所です。 Bot対策が設定されていない フォームを設置しただけで、 CAPTCHA Honeypot レート制限 WAF などが設定されていない場合、自動送信を繰り返されやすくなります。 同じフォームへ短時間に何度でも送信できる 送信回数に制限がなければ、Botが同じフォームへ大量のリクエストを送ることができます。 OWASPはBot対策においてレート制限を基礎的な防御策の一つと位置付けています。 CMS・プラグインの管理が不十分 WordPressなどのCMSでは、お問い合わせフォームをプラグインで実装することが多くあります。 フォームや関連機能を長期間放置している場合は、スパム対策だけでなく、サイト全体の保守状況も確認した方が安全です。 迷惑メール対策で効果的な7つの方法 迷惑メールを減らすには、一つの対策に頼るのではなく、複数の方法を組み合わせることが重要です。 reCAPTCHA・TurnstileなどのBot対策を導入する 代表的なのが、 Google reCAPTCHA Cloudflare Turnstile などのBot判定サービスです。 GoogleのreCAPTCHA v3では、ユーザーに毎回画像認証をさせるのではなく、操作をスコアで評価し、リスクに応じた処理を行うことができます。 また、Cloudflare Turnstileは、通常のCAPTCHAのような画像選択を常に求めることなく、ユーザーやブラウザの状態からBot判定を行う仕組みを提供しています。 問い合わせフォームでは、 「Botを防ぎたいけれど、本物のお客様にはできるだけ手間をかけさせたくない」 というバランスが重要です。 そのため、サイトの利用者やフォームの重要度に合わせて適切な方式を選びましょう。 Honeypot（ハニーポット）を設置する Honeypotとは、通常のユーザーには見えない入力欄などを用意し、Botだけが入力した場合に送信を拒否する方法です。 人間には追加操作を求めないため、フォームの使いやすさを維持しやすいメリットがあります。 ただしHoneypotだけですべてのBotを防げるわけではありません。 OWASPも、HoneypotやCAPTCHA、レート制限などをアプリケーション層で組み合わせる方法を示しています。 Honeypot＋Bot判定＋送信制限 のように組み合わせる方が効果的です。 短時間の大量送信を制限する 同じ送信元から、 数秒間に何十件も問い合わせが届く のであれば、通常のユーザー行動とは考えにくいでしょう。 そこで有効なのがレート制限（Rate Limiting）です。 たとえば、 同一IPから一定時間内に送信できる回数を制限する フォームへの連続アクセスを制限する 異常な送信パターンを検知して一時的にブロックする といった対策があります。 OWASPもレート制限をBot対策の基礎的なコントロールとして挙げています。ただしIPだけに依存すると回避される可能性もあるため、複数のシグナルを組み合わせる考え方が重要です。 入力内容をサーバー側で検証する お問い合わせフォームでは、 メールアドレス 電話番号 郵便番号 選択項目 お問い合わせ内容 などに適切な入力ルールを設定します。 たとえば電話番号欄に大量のURLや異常に長い文字列が入力されている場合、通常の問い合わせとは考えにくいでしょう。 OWASPは入力値について、形式や長さなどを検証し、セキュリティ上のチェックはブラウザ側だけでなくサーバー側でも実施することを推奨しています。JavaScriptなどクライアント側だけのチェックは回避できるためです。 ポイントは、 「画面上で入力できないようにしたから安心」ではない ということです。 フォームの送信先へ直接リクエストされる可能性も考慮し、サーバー側で確認する必要があります。 WAF・Bot対策を活用する 大量の不正アクセスが続く場合には、フォームだけでなくサイト全体で対策する方法もあります。 代表的なのがWAF（Web Application Firewall）です。 WAFやCDNなどのエッジ側で、 不審なアクセス 異常な送信回数 Botらしい通信 特定条件に一致するリクエスト などを検知・制御します。 OWASPでも、CDN・WAF・Bot対策と、アプリケーション側のレート制限やCAPTCHA等を組み合わせる多層防御が示されています。 問い合わせフォームへのスパムが非常に多いサイトでは、フォーム単体ではなく、サイト全体のアクセス対策まで確認するとよいでしょう。 CMS・プラグインを最新状態に保つ WordPressなどを利用している場合は、 WordPress本体 フォームプラグイン テーマ その他のプラグイン を適切に管理します。 ただし、 「最新にすれば迷惑メールがゼロになる」 わけではありません。 アップデートはサイトを安全に運用するための基本であり、スパム対策とは分けて考えながら、両方を継続することが重要です。 更新前にはバックアップを取得し、更新後はフォーム送信まで正常に動くか確認しましょう。 特定ワードやURLによるフィルタリングは補助的に使う スパムに共通する、 特定の単語 特定ドメイン 大量のURL 不自然な文字列 などを検知して拒否する方法もあります。 ただし、 「この文字が入っていたら全部拒否」 という単純な設定は、正規のお客様までブロックする可能性があります。 OWASPも、禁止ワードだけを並べるようなDenylistだけに依存する方法は回避されやすく、補助的な対策として使うべきとしています。 キーワードフィルターは主役ではなく、CAPTCHA・レート制限などを補う目的で使いましょう。 「CAPTCHAを入れれば安心」ではない理由 問い合わせフォームにスパムが増えたとき、 「とりあえずCAPTCHAを付けよう」 となりがちですが、それだけでは十分とは限りません。 OWASPは、自動化対策について一つのコントロールだけに頼るのは脆弱であり、複数レイヤーを組み合わせるべきとしています。 さらに重要なのが、実装方法です。 たとえばCloudflare Turnstileでは、画面上にウィジェットを表示するだけでは不十分で、発行されたトークンをサーバー側で検証することが必須と公式ドキュメントに明記されています。 GoogleのreCAPTCHA v3でも、取得したスコアやアクションなどをバックエンド側で検証する仕組みになっています。 つまり、 「見た目上CAPTCHAが付いている」＝「正しく守られている」 とは限りません。 導入するときは、制作会社やエンジニアに、 「サーバー側の検証まで実装されていますか？」 と確認すると安心です。 正規ユーザーを取りこぼさないフォーム設計も重要 スパムを完全に止めることだけを考えて対策を強くしすぎると、本物のお客様まで問い合わせできなくなる可能性があります。 たとえば、 何度も画像認証を求められる 少し時間をかけただけで送信できなくなる 海外からのアクセスをすべて拒否する 特定単語が入っただけでエラーになる エラー理由が表示されない といったフォームでは、問い合わせ前にユーザーが離脱してしまいます。 OWASPも、視覚的なCAPTCHAを主たる防御策として過度に頼るのではなく、より負担の少ないリスク判定などと組み合わせる考え方を示しています。 フォーム対策で重要なのは、 「迷惑メールをゼロにすること」ではなく、正規ユーザーの利便性を維持しながら迷惑メールを実用上問題ないレベルまで減らすこと です。 対策後は必ず、 PC iPhone Android 異なるブラウザ などから実際にフォームを送信し、正常に問い合わせできるか確認しましょう。 迷惑メールが急増したときの確認手順 突然フォームスパムが増えた場合は、次の順番で確認すると原因を整理しやすくなります。 ステップ1：本当にフォーム経由か確認する 管理者通知メールの形式などから、ホームページのフォーム経由なのか確認します。 ステップ2：どのフォームから届いているか確認する 複数のフォームがある場合、 お問い合わせ 資料請求 採用応募 見積もり依頼 予約 のどこが狙われているかを確認します。 ステップ3：送信パターンを見る 次のような特徴を確認します。 同じ文章が繰り返されている URLが大量に含まれている 短時間に集中している 同じ送信元から繰り返されている 特定フォームだけ大量に送られている ステップ4：現在のBot対策を確認する reCAPTCHAはあるか Turnstileはあるか Honeypotはあるか レート制限はあるか WAFは有効か などを確認します。 ステップ5：正規フォームの送信テストを行う 対策を変更したら、必ず自分たちでフォーム送信を行います。 「スパムは止まったが、お客様からの問い合わせまで止まった」 という状態は避けなければなりません。 ステップ6：一定期間モニタリングする 対策後、 スパム件数 正常な問い合わせ件数 フォームエラー CAPTCHA・Bot判定の失敗状況 などを確認します。 Cloudflare Turnstileでもチャレンジや検証状況を分析する機能が提供されており、Bot対策は導入して終わりではなく、状況を見ながら調整する考え方が重要です。 WordPressのお問い合わせフォームで確認したいポイント WordPressサイトで迷惑メールが増えている場合は、最低限次を確認しましょう。 どのフォームプラグインを使っているか Bot対策機能が有効になっているか reCAPTCHAやTurnstileが正しく接続されているか Honeypotなどを追加できるか フォームプラグインが更新されているか WordPress本体・テーマも管理されているか サーバー側でWAFが利用できるか 大量送信を制限できるか 特に注意したいのが、 「以前CAPTCHAを入れたから大丈夫だと思っている」 というケースです。 APIキーや設定変更、プラグインの変更などによって正常に機能していない可能性もあるため、実際に現在のフォーム環境を確認しましょう。 また、CAPTCHA系サービスを新しく導入する場合は、利用するサービスの規約やデータの取り扱いを確認し、プライバシーポリシーへの記載が必要かもあわせて確認することをおすすめします。Bot判定ではサービスによってブラウザ情報などが利用されるため、プライバシー面も含めた選定が重要です。 問い合わせフォームのスパム対策チェックリスト 迷惑メールが増えてきたら、次の項目を確認してください。 フォーム経由のスパムか確認したか どのフォームが狙われているか特定したか reCAPTCHA・Turnstileなどを導入しているか Bot判定をサーバー側でも検証しているか Honeypotを利用できるか 同一送信元からの大量送信を制限しているか WAF・Bot対策を利用しているか 入力値をサーバー側でも検証しているか フォームプラグインを最新状態にしているか WordPress・CMS本体を適切に管理しているか キーワード拒否だけに頼っていないか 対策後にPC・スマートフォンから送信テストをしたか 正常な問い合わせまでブロックしていないか スパム件数を対策前後で比較しているか 導入サービスのプライバシー条件を確認したか すべてを一度に導入する必要はありません。 まずは、 Bot判定 → Honeypot → レート制限 → WAF・監視 というように、現在のスパム量やサイト規模に合わせて対策を追加していきましょう。 まとめ：一つの対策ではなく“多層防御”で守る 問い合わせフォームの迷惑メールは、ホームページを運用していれば発生する可能性があります。 重要なのは、 「迷惑メールが届いたから危険」 と慌てるのではなく、原因を切り分けて必要な対策を行うことです。 基本的な考え方は、 Bot判定を導入する Honeypotを組み合わせる 大量送信をレート制限する 入力内容をサーバー側でも検証する 必要に応じてWAFを活用する CMS・プラグインを適切に保守する 正規ユーザーが問い合わせできるか必ず確認する という流れです。 現在のBot対策では、一つの仕組みだけにすべてを任せるのではなく、複数の防御を組み合わせる「多層防御」が基本的な考え方です。 そして、もう一つ忘れてはいけないのが、 お問い合わせフォームは“守るため”だけでなく、“問い合わせを受けるため”に存在する ということです。 セキュリティを高めながらも、ユーザーに余計な負担をかけないフォームを目指しましょう。 無料相談 Refuでは、ホームページ制作だけでなく、既存サイトのお問い合わせフォーム確認、WordPress・プラグインの保守、Bot対策、WAFなども含めて運用環境を確認しています。 「突然迷惑メールが増えた」「CAPTCHAを入れているのにスパムが止まらない」「本物のお問い合わせまで止めてしまわないか不安」といった場合も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら SSL（https）って何？ホームページの信頼性とSEOに必須な理由 ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック お問い合わせが増える導線設計｜CTA・ボタン・フォーム最適化の基本 ホームページの保守・更新費用の相場｜何が含まれて何が別料金？ ホームページの表示速度を改善する方法｜Core Web Vitalsと画像最適化の基本
2026/08/12
デザイン・ブランディングWebアクセシビリティを意識したデザインとは？中小企業サイトの改善ポイント
Webアクセシビリティは「一部の人向け」ではなく、誰でも使いやすいサイトを作る考え方 「Webアクセシビリティ」と聞くと、 障害のある人だけを対象にしたもの 公共機関のサイトだけが対応すればいいもの デザインの自由度が下がるもの というイメージを持つ方もいるかもしれません。 しかし、本質はもっとシンプルです。 年齢、障害の有無、利用している端末や操作方法などにかかわらず、できるだけ多くの人がWebサイトの情報や機能を利用できる状態にすること。 これがWebアクセシビリティの基本的な考え方です。 例えば、 文字が薄すぎて読みにくい ボタンが小さくて押しにくい 画像だけで内容を説明している キーボードではメニューを操作できない フォームのエラー理由が分からない といった問題は、特定のユーザーだけではなく、スマートフォンを使う人、高齢者、一時的に手をけがしている人、明るい屋外で画面を見る人など、多くのユーザーに影響します。 デジタル庁も、Webアクセシビリティについて、専門知識がない担当者や事業者が実務で取り組むためのガイドを公開しており、スマートフォン対応を含めた考え方を整理しています。 まず結論：中小企業サイトは「見える・読める・押せる・操作できる」から改善する Webアクセシビリティには多くの基準があります。 すべてを一度に理解しようとすると難しく感じますが、中小企業サイトで最初に見るべきポイントは、大きく4つです。 見える文字・ボタン・情報が認識できる 読める文章や画像の意味を理解できる 押せるボタンやリンクを間違えず操作できる 操作できるマウス以外の方法でも必要な機能を利用できる まずこの4つを基準に既存サイトを見るだけでも、多くの改善点を発見できます。 Webアクセシビリティとは？まず知っておきたい基本 WCAG 2.2とは？世界的に参照されるアクセシビリティガイドライン Webアクセシビリティを考えるうえで重要なのが、W3Cが策定するWCAG（Web Content Accessibility Guidelines）です。 2026年8月時点では、WCAG 2.2がW3C Recommendationとして公開されています。WCAG 2.2では、従来からの文字コントラストやキーボード操作などに加え、フォーカスが他の要素に隠れないことや、操作対象のサイズなども追加されています。 WCAGには、達成基準として主に A AA AAA というレベルがあります。 企業サイトでアクセシビリティを検討する際は、まずA・AAレベルの考え方を理解しながら改善すると現実的です。 日本ではJIS X 8341-3:2016も重要な基準 日本では、JIS X 8341-3:2016がWebアクセシビリティに関する規格として広く参照されています。 デジタル庁の2025年10月更新の「ウェブアクセシビリティ導入ガイドブック」でも、JIS X 8341-3:2016が現在も参照されることの多い規格として紹介され、スマートフォンなど、その後重要性が増した課題も含めた実践方法が整理されています。 「どこまで対応すればアクセシブルなのか」を考える際は、感覚だけで判断せず、こうした基準を参照することが重要です。 中小企業も無関係ではない｜合理的配慮との関係 日本では、2024年4月1日から、障害者差別解消法に基づく事業者による合理的配慮の提供が義務化されています。 ただし、ここは誤解しないことが重要です。 「すべての民間企業サイトが一律にWCAG 2.2へ完全適合しなければ法律違反になる」という単純な話ではありません。 合理的配慮は個別の場面・状況や事業者への負担なども踏まえて判断されます。Webサイトに求められる具体的な対応も、サービス内容や利用状況によって異なります。 とはいえ、企業がWebを重要な顧客接点として利用する以上、最初から利用しづらい状態を減らしておくことは、ユーザー体験とリスク管理の両面で重要になっています。 まず改善したい8つのポイント 文字と背景のコントラストを確保する おしゃれなサイトで特に起きやすいのが、 「薄いグレーの文字 × 白背景」 です。 見た目は洗練されていても、コントラストが不足すると読みにくくなります。 WCAG 2.2のレベルAAでは、通常サイズのテキストについて少なくとも4.5:1、大きな文字については少なくとも3:1のコントラスト比が基準として示されています。 特に確認したいのは、 本文 小さな注釈 ボタン内の文字 フォームのラベル 画像上に重ねた文字 です。 ブランドカラーだからといって、そのまま文字色に使えるとは限りません。 ブランドカラーの色相を守りながら、明度などを調整して読みやすさを確保するという設計が必要です。 色だけで情報を伝えない 例えばフォームで、 「入力エラーは赤色にします」 だけでは不十分です。 色の違いを認識しにくいユーザーには、何が間違っているのか分からない可能性があります。 そのため、 赤色＋「必須項目です」 赤色＋エラーアイコン＋説明文 グラフなら色＋柄・ラベル のように、色以外の情報も組み合わせることが重要です。 これはアクセシビリティだけでなく、誰にとっても分かりやすいデザインにつながります。 文字サイズ・行間・拡大時の読みやすさを確認する 文字が読みにくい原因は、文字サイズだけではありません。 行間が狭い 文字が細すぎる 1行が長すぎる 拡大するとレイアウトが崩れる スマホで文字が極端に小さくなる こうした問題も確認します。 特に重要なのは、デザインカンプ上で美しく見えるかではなく、実際の端末で読めるかです。 PC・スマートフォンの両方で、 文章を拡大する ブラウザのズームを使う 画面幅を狭くする などの確認をしておきましょう。 画像には内容に応じた代替テキストを設定する 画像だけに重要な情報が含まれていると、画像を認識できない環境では内容が伝わりません。 例えば、 商品写真 施工事例 グラフ サービスの仕組みを説明する図 バナー画像 などです。 意味のある画像には、内容に応じてalt属性などによる代替テキストを設定します。 一方で、純粋な装飾画像にまで説明文を付ければよいわけではありません。 重要なのは、 「この画像が表示されなくても、必要な情報が伝わるか？」 という視点です。 Google Search Centralも、画像などの視覚コンテンツについて、テキストによる説明を用意し、セマンティックなHTMLを使用することを案内しています。Googleはサイトについて、検索だけでなく、あらゆるユーザーに対するアクセシビリティも高めるよう推奨しています。 ボタン・リンクを押しやすくする スマートフォンでは、見えていても押せなければ使いやすいサイトとは言えません。 例えば、 小さな「×」ボタン 密集したテキストリンク 小さなページネーション タップ範囲が文字だけのメニュー などです。 WCAG 2.2では、新しいレベルAAの基準として、ポインター操作のターゲットサイズについて原則24×24 CSSピクセル以上とする基準が追加されています。ただし、要素間の間隔など複数の例外があります。 ここで重要なのは「24pxにすれば終了」ではありません。 実際のサイトでは、 十分なボタンサイズ ボタン同士の余白 タップしやすい位置 誤操作しにくいレイアウト まで含めて確認しましょう。 キーボードだけでも操作できるか確認する Webサイトはマウスやタッチ操作だけで利用されるとは限りません。 キーボードのTabキーなどを使って、 メニュー リンク ボタン フォーム モーダル を操作できるか確認します。 さらに重要なのが、今どこを選択しているのか分かることです。 WCAG 2.2では、キーボードフォーカスが視覚的に確認できることがレベルAAの達成基準として示され、さらにフォーカスされたUIが固定ヘッダーなどで完全に隠れないこともレベルAAの基準に含まれています。 デザイン上、 outline: none; などでフォーカス表示を消してしまうと、キーボード利用者が現在位置を把握できなくなる場合があります。 「デザイン的に邪魔だから消す」ではなく、ブランドに合った見やすいフォーカス表現へ調整することが重要です。 フォームの項目名・エラー内容を分かりやすくする 問い合わせフォームもアクセシビリティで重要な場所です。 特に確認したいのは、 入力欄に項目名がある 必須・任意が分かる エラー理由が具体的 色だけでエラーを表現していない 入力欄とラベルが正しく対応している キーボードでも順番に操作できる といったポイントです。 例えば、 ×「入力内容に誤りがあります」 だけではなく、 ○「メールアドレスを『example@example.com』の形式で入力してください」 のように、修正方法まで伝えます。 アクセシビリティ対応は、結果的にフォーム離脱の改善にもつながる考え方です。 動画・アニメーションは情報を取り残さない設計にする 動画やアニメーションはブランド表現に有効ですが、使い方には注意が必要です。 例えば、 動画でしか説明していない 字幕がない 自動再生され続ける 動きが激しく、情報を追いにくい カルーセルが自動で切り替わり、止められない といった状態です。 重要な情報は動画だけに閉じ込めず、必要に応じて 字幕 テキスト 操作ボタン 停止手段 などを用意します。 「動かすこと」自体を目的にしないことが重要です。 “アクセシブル＝地味”ではない｜ブランドデザインと両立する考え方 アクセシビリティ対応について、 「色が使えなくなる」「デザインが普通になる」「ブランドらしさがなくなる」 と心配されることがあります。 しかし、これは誤解です。 アクセシビリティが求めているのは、デザインを地味にすることではありません。 例えばブランドカラーのコントラストが足りない場合でも、 背景側を調整する 色の明度を調整する ボタンだけ別のアクセントカラーを使う 文字色ではなく装飾にブランドカラーを使う など、ブランドを守りながら改善できます。 むしろ、 「美しいけれど読めない」より、「ブランドらしく、しかも伝わる」ことが本当のデザインです。 アクセシビリティはデザインの制約ではなく、デザインの完成度を高める条件のひとつとして考えるのがおすすめです。 中小企業サイトで優先順位をつけるならどこから？ アクセシビリティ改善を「全ページ一気にやる」と考えると、ハードルが高くなります。 既存サイトであれば、重要度の高い場所から段階的に進める方法があります。 最優先：問い合わせ・予約などCVに直結する場所 最初に確認したいのは、 問い合わせフォーム 予約フォーム CTA 電話ボタン 資料請求 などです。 ここが利用できないと、ビジネス成果そのものを取りこぼします。 まず「相談したい人が最後まで操作できるか」を確認するのが優先です。 次に：トップ・サービス・料金など主要ページ 次に確認するのは、アクセスや比較検討で重要なページです。 トップページ サービスページ 料金ページ 実績・事例 FAQ 特に、 文字色／文字サイズ／リンク／画像／見出し構造／ボタン を重点的に確認します。 最後に：サイト全体へルールを展開する 主要ページを改善したら、個別対応で終わらせず、デザインルールにします。 例えば、 本文色はこの色以上のコントラストを確保 ボタンサイズはこのルール リンクには共通表現を使う フォームのエラー表示はこの形式 画像登録時はaltを確認 フォーカス表示は削除しない といったルールです。 これをCMSの運用ルールやデザインガイドラインに組み込めば、更新するたびにアクセシビリティが悪化する状態を防げます。 このまま使えるWebアクセシビリティ改善チェックリスト 文字・色 本文と背景のコントラストを確認した 薄すぎるグレー文字を多用していない 色だけで「正解・エラー・重要」などを表現していない 文字を拡大しても情報が読める スマホでも本文が小さすぎない 画像・動画 意味のある画像に適切な代替テキストがある 画像の中だけに重要情報を閉じ込めていない 動画だけで重要情報を説明していない 必要な動画には字幕などを用意している 自動再生・アニメーションが操作を邪魔していない 操作 ボタン・リンクが押しやすい タップ要素同士が近すぎない キーボードだけでも主要機能を操作できる Tabキーで現在位置が確認できる 固定ヘッダーなどでフォーカス位置が隠れない フォーム 項目名が入力後も確認できる 必須・任意が分かる エラー内容が具体的 色だけでエラーを示していない エラー後も入力内容が保持される 送信ボタンの役割が明確 運用 新規ページ作成時の確認ルールがある 更新担当者にもアクセシビリティ基準を共有している PCだけでなくスマホでも確認している 自動チェックだけで終わらず、実際に操作して確認している まとめ：アクセシビリティは“制約”ではなく、伝わるデザインの基本 Webアクセシビリティは、特別なユーザーだけを対象にした対応ではありません。 見える。読める。押せる。迷わず操作できる。 この基本を整えることです。 そして、この考え方は、 UI/UX スマホ対応 問い合わせフォーム改善 コンテンツ設計 ブランドへの信頼 とも密接につながっています。 Google Search Centralも、Webサイトについて安全性・速度・デバイス対応と並び、あらゆるユーザーにとってのアクセシビリティを高めることを案内しています。アクセシビリティを「SEOの裏技」と考えるのではなく、ユーザーにも検索エンジンにも内容を適切に届けるサイトづくりの土台として考えるのが適切です。 中小企業サイトであれば、最初から完璧を目指す必要はありません。 まずは問い合わせフォーム、CTA、トップページ、サービスページなど重要度の高い場所から確認し、改善したルールをサイト全体へ広げていきましょう。 法務面の注意 2024年4月1日から、民間事業者にも障害のある人への合理的配慮の提供が義務化されています。 ただし、「民間企業のWebサイトはすべてWCAG 2.2のAAに適合しなければならない」と一律に解釈するのは適切ではありません。 実際の法的義務や必要となる対応は、事業内容・利用者・具体的な申出・過重な負担の有無などによって判断されます。 そのため、公共性の高いサービスや、予約・申請・購入などWeb上で重要な手続きを提供している企業では、「法律でどこまで必須か」だけではなく、利用者がサービスへアクセスできる状態をどう確保するかという視点で対応することが重要です。 無料相談 Refuでは、見た目のデザインだけでなく、文字の読みやすさ・色のコントラスト・スマホ操作・CTA・フォーム・キーボード操作など、実際のユーザー体験を含めたサイト改善をご提案しています。 「アクセシビリティと言われても何から直せばいいか分からない」「デザイン性を保ったまま改善したい」といった場合も、現在のサイトを確認し、優先順位から整理します。 ▶ 無料相談はこちらから その他おすすめ記事はこちら スマホで差がつくUI改善｜押しやすさ・読みやすさのチェックポイント 問い合わせフォームのデザイン改善｜入力離脱を防ぐ項目・エラー表示・確認画面 “信頼される文章”に見せるデザイン｜行間・段落・余白の文章レイアウト術 配色に迷わない｜メイン・サブ・アクセントの黄金比と運用ルール ヘッダー・グロナビの正解は？迷わせないメニュー設計の基本 更新しても世界観が崩れない｜デザインガイドライン（簡易版）の作り方
2026/08/11
リニューアル・運用ノウハウCore Web Vitalsの改善方法｜LCP・INP・CLSを初心者向けに解説
Core Web Vitalsとは？ホームページの「使いやすさ」を測る3つの指標 Core Web Vitals（コアウェブバイタル）とは、Webページを利用したユーザーが感じる読み込み速度・操作への反応・表示の安定性を測るための指標です。 現在のCore Web Vitalsは、次の3つで構成されています。 LCP（Largest Contentful Paint）→ メインコンテンツがどれくらい早く表示されるか INP（Interaction to Next Paint）→ クリックやタップなどの操作にどれくらい早く反応するか CLS（Cumulative Layout Shift）→ ページ表示中にレイアウトがどれくらいズレるか つまりCore Web Vitalsは、単純な「ページの速さ」だけを見る指標ではありません。 表示されるまで待たされないかボタンを押したのに反応しない状態にならないか読んでいる途中で文字やボタンが突然動かないか といった、実際のユーザー体験を数値化する考え方です。Googleも、Core Web Vitalsを実際のユーザー体験を測定する指標として位置づけています。 Core Web VitalsはSEOにどこまで影響する？ Core Web Vitalsについて、「数値を改善すれば検索順位が上がる」と考えている方もいます。 しかし、これは少し違います。 GoogleはCore Web Vitalsを、検索ランキングを決定する際に考慮するページエクスペリエンス関連の要素の一つとして扱っています。一方で、Core Web Vitalsだけを改善すれば上位表示できるわけではなく、検索意図に合った有益なコンテンツであることの方が重要です。 例えば、 Aサイト：Core Web Vitalsは非常に良いが、内容が薄いBサイト：表示速度は少し劣るが、検索ユーザーの疑問に詳しく答えている という場合、単純にAサイトが上位になるわけではありません。 そのため、Core Web Vitals改善の目的は、 「SEOの点数を上げること」ではなく、ユーザーがストレスなく利用できる環境を整えること と考えるのが重要です。 問い合わせや採用を目的とした企業サイトなら、ユーザー体験の改善は離脱防止やフォーム到達にもつながるため、SEO以外の意味でも取り組む価値があります。 まず覚えたいLCP・INP・CLSの基準値 Googleが示している「良好」の目安は次のとおりです。 LCP：2.5秒以下INP：200ミリ秒以下CLS：0.1以下 Core Web Vitalsでは一部の高速ユーザーだけを見るのではなく、実際のユーザー体験を広く捉えるため、ページ訪問の75パーセンタイルで3指標すべてが推奨値を満たしているかが重要な基準になります。 指標何を測る？良好の目安LCP読み込み速度2.5秒以下INP操作への反応200ms以下CLS表示の安定性0.1以下 まずは、この3つの意味を理解することから始めましょう。 LCPとは？ページの「表示速度」を改善する方法 LCPは、ページを開いてから、ファーストビュー内の大きな画像やテキストなど、主要なコンテンツが表示されるまでの時間を測ります。 Googleが推奨する良好なLCPは2.5秒以下です。 企業サイトでLCPの対象になりやすいのが、 メインビジュアル 大きな写真 メインコピーを含む大きなテキスト領域 などです。 ファーストビューの大きな画像を軽くする 企業サイトでLCPが悪化する代表的な原因の一つが、ファーストビューの大きな画像です。 例えば、 5MB以上ある写真をそのまま掲載 PC用の巨大画像をスマホでも読み込む 必要以上に高解像度な画像を使用 といった状態です。 改善する場合は、 適切な画像サイズへリサイズするWebPなど効率的な画像形式を検討する端末サイズに合った画像を配信する必要以上に高画質な画像を使用しない といった方法を検討します。 LCPはメインコンテンツが表示されるまでの時間を測るため、特にファーストビュー画像の読み込み方法は重要な改善ポイントです。 サーバーの応答速度を見直す 画像だけではなく、サーバー側の応答が遅ければページ表示全体が遅くなります。 例えば、 サーバースペックが不足している アクセス集中で処理が遅れている CMS側の処理が重い キャッシュが適切に利用されていない といった原因が考えられます。 画像を圧縮してもLCPが改善しない場合は、フロント側だけでなくサーバー・CMS環境まで確認することが大切です。 不要なCSS・JavaScript・外部読み込みを減らす ページを開く際に大量のCSSやJavaScriptを読み込んでいると、重要なコンテンツの表示が後回しになることがあります。 よくあるのが、 使用していないプラグイン 大量のアニメーション 計測タグ チャットツール SNS埋め込み Webフォント などです。 「便利だから」「以前から入っているから」と残すのではなく、本当に必要なものか定期的に棚卸しすることが重要です。 LCP画像を遅延読み込みしすぎない 画像の遅延読み込み（lazy load）は、ページ全体の読み込み量を減らすためには便利です。 しかし、最初から表示されるメインビジュアルなど、LCPの対象になる重要画像まで不必要に遅延させると、逆に表示が遅くなることがあります。 「すべての画像を遅延読み込みする」のではなく、ファーストビュー画像と下層画像を分けて設計することが大切です。GoogleのLCP最適化ガイドでも、LCPリソースを早く発見・読み込み・レンダリングできる状態にすることが重要とされています。 INPとは？クリック後の「反応の遅さ」を改善する方法 INPは、ユーザーがページ内で行ったクリック・タップ・キーボード操作などに対して、画面がどれだけ早く反応したかを評価する指標です。 良好な目安は200ミリ秒以下です。INPはページ滞在中に発生した対象インタラクションの応答性を継続的に見て、ページ全体として反応が悪くないかを評価します。 例えば、 メニューを押したのに開かない フォームの選択肢を押しても反応が遅い 「もっと見る」を押してから表示まで時間がかかる といった状態は、INP悪化につながる可能性があります。 重いJavaScript処理を減らす INPが悪い場合、代表的な原因の一つがJavaScriptです。 JavaScriptの処理中は、ブラウザがユーザー操作への反応をすぐに返せない場合があります。 不要なスクリプトを削除する 処理内容を見直す 必要なタイミングまで読み込みを遅らせる などによって改善を検討します。GoogleのINP最適化ガイドでも、入力遅延・イベント処理・次の描画までの時間を短縮することが重要とされています。 長時間メインスレッドを占有する処理を分割する 一つの重い処理が長時間実行されていると、その間ユーザー操作への反応が遅れます。 処理を小さく分けたり、不要な処理を減らしたりすることで、ユーザー操作を処理できる余裕を作ります。 専門的な実装になるため、INPに問題がある場合は制作会社やエンジニアへの相談をおすすめします。 外部ツール・タグを整理する 企業サイトでは公開後、さまざまなツールが追加されていきます。 GA4 GTM 広告タグ ヒートマップ チャット MAツール SNS関連 一つひとつは必要でも、積み重なることでサイトが重くなる場合があります。 リニューアル時には、現在使っているタグをすべて棚卸しするのがおすすめです。 「昔の広告用タグが残っていた」「使っていないヒートマップが動いていた」 というケースは珍しくありません。 フォームやメニューの操作感を実機で確認する 数値だけでなく、自分でスマートフォンを操作することも重要です。 ハンバーガーメニュー 問い合わせフォーム アコーディオン 検索機能 スライダー モーダル など、ユーザーが触る機能を実際に試してみましょう。 INPはユーザー操作への応答性を見る指標なので、「自分で触って遅いと感じる場所」が改善箇所を探すヒントになります。 CLSとは？突然レイアウトがズレる問題を改善する方法 CLSは、ページを閲覧している途中にレイアウトが予期せず移動する現象を評価します。 良好な目安は0.1以下です。 例えば、 ボタンを押そうとした瞬間に広告が表示され、位置がずれる 文章を読んでいたら上から画像が読み込まれて文章が移動する Webフォント読み込み後に文字サイズが変わる といった状態です。 ユーザーにとって非常にストレスの大きい現象なので、改善する価値があります。 画像・動画の表示領域をあらかじめ確保する 画像のwidth・heightなどが適切に設定されていないと、ブラウザは画像が読み込まれるまで必要なスペースを判断できません。 結果として、 文章が先に表示↓画像読み込み↓文章が下へ移動 というレイアウトシフトが発生します。 画像や動画のサイズ・アスペクト比を事前に指定し、読み込み前から表示領域を確保することが、CLS改善の基本です。 後から表示されるバナーやコンテンツに注意する Cookieバナー、広告、キャンペーン案内などをページ上部へ後から挿入すると、既存コンテンツを押し下げることがあります。 対策として、 あらかじめ表示スペースを確保する 既存コンテンツを押し下げない表示方法にする ユーザー操作後の表示方法を見直す などを検討します。サイズを確保していない動的コンテンツは、CLS悪化の代表的な原因の一つです。 Webフォントによる文字ズレを抑える Webフォントの読み込み前後で文字幅や高さが大きく変わると、文章の位置がずれることがあります。 日本語サイトでは文字量が多いため、フォント選択や読み込み方法による影響が大きくなるケースもあります。 デザイン性だけでなく、 読み込み速度 可読性 レイアウトへの影響 まで考えてフォントを選択しましょう。 Core Web Vitalsの確認方法｜まず見るべき3つのツール Google Search Console Search ConsoleにはCore Web Vitalsのレポートがあり、実際のユーザーデータをもとにサイトの問題を確認できます。GoogleもCore Web Vitals改善時の確認手段としてSearch Consoleのレポートを案内しています。 「サイト全体として問題があるページ群を探す」用途に向いています。 まずは、 良好 改善が必要 不良 となっているページがどれくらい存在するのか確認しましょう。 PageSpeed Insights PageSpeed Insightsは、URLを入力するだけでパフォーマンスを確認できるGoogleのツールです。 利用可能な場合は実際のユーザー環境から収集されたフィールドデータを確認でき、同時にLighthouseによるラボ環境での診断も改善箇所の特定に役立ちます。フィールドデータとラボデータは測定環境が異なるため、数値が一致しない場合があります。 重要なのは、 点数だけを見るのではなく、「何が遅くしているか」を見ること です。 Chrome DevTools・Lighthouse 具体的な原因を調べたい場合は、Chrome DevToolsやLighthouseを利用します。 例えば、 どの画像がLCP対象か どの処理が重いか どの要素がレイアウトシフトしているか など、問題の原因をより細かく分析できます。Googleは、Core Web Vitalsは実際のユーザーデータで評価しつつ、Lighthouseなどのラボツールを問題診断に活用するワークフローを案内しています。 「PageSpeed Insightsで100点」を目標にしなくていい理由 Core Web Vitals改善でよくある失敗が、 「とにかくPageSpeed Insightsを100点にする」 ことが目的になってしまうことです。 Google自身も、Core Web Vitalsのスコアが良いからといって検索上位が保証されるわけではなく、SEOだけを理由に満点を追い求めることは有効な時間の使い方とは限らないと説明しています。 例えば、100点を取るために、 必要な写真を極端に小さくする 便利な機能を削除する ブランド表現をすべてなくす となってしまえば、本末転倒です。 目指すべきなのは、 ユーザーがストレスなく閲覧できる伝えたい情報がきちんと伝わる問い合わせ・応募につながるそのうえでCore Web Vitalsも良好 という状態です。 リニューアル時にCore Web Vitalsが悪化しやすい原因 「古いサイトより新サイトの方が遅くなった」ということは実際に起こります。 原因として考えられるのは、 大きなメインビジュアルを追加した動画をファーストビューへ追加したアニメーションを増やしたWebフォントを増やしたJavaScriptライブラリが増えた計測・広告・チャットタグが増えたWordPressプラグインが増えた などです。 つまり、デザインを豪華にすることと、快適に使えることは必ずしも同じではありません。 リニューアルではデザイン確認だけでなく、公開前にPageSpeed Insightsや実機でパフォーマンス確認を行いましょう。 Core Web Vitals改善チェックリスト LCP｜読み込み速度 ファーストビュー画像が必要以上に大きくない 画像を適切なサイズ・形式にしている LCP対象画像を不必要に遅延読み込みしていない 不要なCSS・JavaScriptを減らしている サーバー応答が極端に遅くない 不要な外部ツールを削除している INP｜操作への反応 ボタン・メニューがすぐ反応する 重いJavaScript処理を見直している 不要なタグ・外部スクリプトを整理している フォームを実際のスマートフォンで操作確認している アニメーションやUI機能を増やしすぎていない CLS｜表示の安定性 画像に表示サイズ・アスペクト比を設定している 動画・iframeの領域を確保している 後から挿入されるバナーの領域を確保している フォント読み込みによる大きなズレがない ページをスクロールしても突然コンテンツが動かない 計測・運用 Search ConsoleでCore Web Vitalsを確認している PageSpeed Insightsで重要ページを確認している トップページだけでなくサービスページも確認している PC・スマートフォンの両方を確認している リニューアル公開後も継続して数値を監視している まとめ：数字を良くすることではなく“快適に使えるサイト”を目指す Core Web Vitalsは、 LCP＝表示されるまでの速さINP＝操作への反応の速さCLS＝画面の安定性 という、ユーザーがホームページを利用するときの基本的な体験を数値化したものです。 現在Googleが示している良好の目安は、LCP 2.5秒以下・INP 200ミリ秒以下・CLS 0.1以下です。 ただし、Core Web Vitalsだけを改善すればSEOで勝てるわけではありません。 検索意図を満たすコンテンツ企業としての信頼性分かりやすい導線問い合わせしやすい設計快適なページ体験 これらを総合的に整えることが重要です。Googleも、特定のページエクスペリエンス指標だけに集中するのではなく、全体として良いページ体験を提供することを推奨しています。 Core Web Vitalsは「SEOのための点数」ではなく、ユーザーが快適にサイトを利用できているかを確認する健康診断として活用しましょう。 無料相談 Refuでは、PageSpeed Insights・Search Consoleなどを活用した現状分析から、画像最適化、JavaScript・外部タグの整理、WordPress・サーバー環境の見直しまで、サイトごとの原因に合わせた改善をご提案しています。 「リニューアルしたらサイトが重くなった」「PageSpeed Insightsの数値をどう見ればいいか分からない」「SEOと問い合わせの両方を考えて改善したい」 など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら ページスピード改善で成果が変わる！画像・構造の見直し術 画像サイズとページ速度の関係を理解する｜表示速度を改善する実践テクニック リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 リニューアル時のアクセス解析「引き継ぎ」完全ガイド｜GA4設定・GTM・計測の落とし穴 リニューアル後の改善ロードマップ｜公開後90日でやるべき施策チェックリスト
2026/08/06
集客・マーケティング戦略AI検索時代のSEO対策｜AI Overviews・AI Modeで選ばれるコンテンツの作り方
AI検索が広がってもSEOの基本は変わらない Google検索では、従来の検索結果に加えて、AI OverviewsやAI Modeなど、生成AIを活用した検索体験が広がっています。 そのため、 従来のSEOは通用しなくなるのか AIに引用されるための特別な対策が必要なのか AEOやGEOに取り組まなければならないのか と不安を感じる企業担当者も増えています。 しかし、Googleは公式ガイドで、生成AIを活用した検索でも従来のSEO施策は引き続き重要であり、AI OverviewsやAI Modeに表示されるための特別な技術要件はないと説明しています。 AI検索が広がったからといって、SEOの基本をすべて作り直す必要はありません。 重要なのは、これまで以上に、独自性があり、信頼でき、ユーザーの判断に役立つ情報を作ることです。 まず結論：特別な「AI専用SEO」より基本施策の徹底が重要 AI検索への対応で優先すべきことは、特殊なファイルや新しいテクニックを導入することではありません。 まずは、次の基本を徹底します。 ユーザーの疑問に明確に答える 他サイトにはない経験や情報を加える 著者・運営会社・根拠を明確にする 関連ページを内部リンクで整理する Googleがクロール・インデックス登録できる状態にする ページをスマートフォンでも読みやすくする 公開後も情報を更新する Googleは、生成AI検索においても、明確な技術構造と、独自性・価値のあるコンテンツが基盤になると説明しています。 「AIに選ばれる文章」を考えるよりも、ユーザーが読んで納得し、次の行動を選べるページを作ることが先です。 AI Overviews・AI Modeとは？従来の検索との違い AI Overviewsは複雑な質問の概要を提示する AI Overviewsは、ユーザーが検索した内容について、複数の情報を整理した概要と、詳しく調べるためのリンクを検索結果上に表示する機能です。 特に、 複数の要素を整理する必要がある質問 一つの回答だけでは解決しにくい質問 比較や判断材料が必要な検索 などで表示される可能性があります。 すべての検索で表示されるわけではなく、Googleが従来の検索結果に追加する価値があると判断した場合に表示されます。 AI Modeは比較・検討・深掘り検索に対応する AI Modeは、複雑な質問や比較、追加質問を重ねながら情報を深掘りする検索体験です。 例えば、ホームページ制作を検討している人が、 自社に必要なページ数 制作費用 SEO対策の範囲 制作会社の選び方 公開後の運用方法 などを一度に比較・検討する場面で活用される可能性があります。 従来は複数回に分けて検索していた内容を、より会話的に整理できる点が特徴です。 複数の関連検索を行う「クエリファンアウト」 AI OverviewsやAI Modeでは、ユーザーの質問を理解するために、関連する複数のテーマや情報源を調べる「クエリファンアウト」と呼ばれる仕組みが使われる場合があります。 例えば「中小企業がホームページから問い合わせを増やす方法」という質問には、次のような関連テーマが含まれます。 SEO対策 サービスページの内容 CTA設計 実績・事例 料金ページ フォーム改善 アクセス解析 つまり、単一のキーワードだけを繰り返すよりも、中心テーマと関連する疑問をサイト全体で整理している方が、さまざまな検索意図に対応しやすくなります。 AI検索で選ばれやすいコンテンツの6つの条件 他サイトでは得られない独自情報がある AI検索時代に特に重要になるのが、簡単に代替できない情報です。 例えば、次のような内容が該当します。 自社で実際に対応した事例 顧客からよく相談される課題 現場で起きた失敗と改善策 自社独自の調査やアンケート 実務で使用しているチェックリスト 専門家による判断基準 Googleも、独自の情報・分析・調査や、検索結果にある他のページを上回る実質的な価値があるかを、コンテンツの自己評価項目として挙げています。 他サイトの情報を整理し直しただけの記事ではなく、自社だから書ける情報を加えることが重要です。 質問への答えと根拠が明確に書かれている 記事の冒頭で結論が分からず、長い説明を読まなければ答えにたどり着けないページは、ユーザーにとって使いにくいものです。 基本構成は、次の順番にすると分かりやすくなります。 結論 その理由 具体例・根拠 注意点・例外 次に取るべき行動 ただし、AIに読み取らせることだけを目的に、文章を不自然に細切れにする必要はありません。 あくまで、ユーザーが内容を理解しやすい見出しと文章構造にすることが目的です。 実務経験・事例・一次情報が含まれている 一般的な説明に加えて、実際の経験を記載します。 例えば、 実際にはどこで失敗しやすいか 顧客がどの段階で迷うのか どの施策から始めると改善しやすいか 理論と現場で異なる部分は何か などです。 一次情報は、コンテンツの独自性だけでなく、E-E-A-Tにおける「経験」を伝える要素にもなります。 誰が発信しているか分かる 情報の内容だけでなく、発信者も明確にします。 記事には、可能な範囲で次の情報を掲載します。 執筆者名 監修者名 担当分野 経歴・実績 所属会社 著者プロフィールへのリンク 参考にした公式情報 特に専門性や判断の正確性が重要なテーマでは、誰が、どのような根拠で書いているかが信頼性につながります。 関連情報がサイト内で整理されている 1ページですべてを説明しようとすると、情報が長くなり、検索意図も曖昧になります。 そのため、 親ページでテーマの全体像を説明する 個別記事で疑問を深掘りする 記事からサービスページへ誘導する 料金・事例・FAQへ内部リンクを設置する という構造を作ります。 Googleは、生成AI検索においても、重要なページを内部リンクで見つけやすくすることを基本施策として挙げています。 クロール・インデックス登録が可能な状態になっている どれだけ有用な記事でも、Googleがページを取得・認識できなければ検索結果には表示されません。 最低限、次を確認します。 robots.txtでクロールを誤って拒否していない noindexが設定されていない ページがSearch Consoleで認識されている 重要な文章が画像内だけに記載されていない 内部リンクからページに到達できる スマートフォンで問題なく表示できる ページの読み込みが極端に遅くない AI OverviewsやAI Modeの参照リンク候補になるには、ページがGoogle検索にインデックス登録され、検索結果にスニペットを表示できる状態であることが前提です。 AI検索を意識したコンテンツ制作の手順 検索キーワードではなく「質問」を整理する キーワードだけでなく、ユーザーが実際に知りたい質問を整理します。 例えば「ホームページ制作 費用」であれば、次のように分解できます。 ホームページ制作はいくらかかるのか 何によって費用が変わるのか 制作費以外に必要な費用はあるか 安い制作会社と高い制作会社は何が違うのか 自社には何ページ必要か 見積書のどこを比較すべきか 一つの検索語の裏にある複数の疑問を把握することで、内容の抜け漏れを防げます。 結論→理由→具体例→注意点の順で書く 各見出しでは、最初に答えを示します。 基本テンプレート 結論：まず何をすべきか 理由：なぜ必要なのか 具体例：どのようなケースがあるか 注意点：例外や失敗しやすい点 次の行動：読者は何を確認すべきか この順番にすると、ユーザーが必要な情報を見つけやすくなります。 独自の経験・数値・判断基準を追加する 一般論を書いた後に、必ず自社の情報を追加します。 例えば、 実際の相談で多い課題 制作現場で確認している項目 成果が出た事例 改善前後の数値 依頼を断るケース 自社が重視する判断基準 などです。 数字を掲載できない場合でも、どのような状態から、何を変え、どのような変化が起きたかを具体的に説明すれば、十分な一次情報になります。 関連記事とサービスページを内部リンクでつなぐ 記事を読んだ後の行動まで設計します。 例えば、 AI検索の記事↓キーワード設計の記事↓サービスページSEOの記事↓実績・料金・問い合わせ という流れです。 内部リンクはSEO評価のためだけでなく、ユーザーが検討を進めるための案内として設置します。 公開後も事例や最新情報を追記する 公開時点で完成と考えず、定期的に更新します。 新しい事例を追加する 公式情報の変更を反映する Search Consoleで新しい検索クエリを確認する 読者から寄せられた質問をFAQに追加する 古くなった画面や手順を差し替える 更新すること自体が目的ではありません。 検索する人にとって、現在も正確で役立つ状態を保つことが重要です。 AI検索対策として無理にやらなくてよいこと Google検索のためだけにllms.txtを設置する Googleは、Google検索や生成AI検索に表示されるために、llms.txtなどの特別なAI向けファイルを設置する必要はないと説明しています。 llms.txtを利用する別のサービスのために設置すること自体は問題ありませんが、Google検索での表示や順位を高める効果はないとされています。 AI専用の特殊な構造化データを追加する AI OverviewsやAI Mode専用のschema.orgマークアップはありません。 通常の検索結果でリッチリザルトの対象になる構造化データは引き続き活用できますが、ページに表示している内容と一致させる必要があります。 文章を細かく分割することだけを目的にする 「AIに読み取らせるため、すべての文章を短い塊に分けるべき」という考え方に、Google公式の必須要件はありません。 ページの長さや文章の区切りは、AIのためではなく、テーマとユーザーの理解しやすさに合わせて決めます。 検索語の言い換えページを大量に作る AI検索は同義語や質問全体の意味を理解するため、細かな言い換えごとに別ページを大量作成する必要はありません。 例えば、 ホームページ制作費用 ホームページ制作料金 ホームページ制作価格 ホームページ制作相場 をすべて別記事にすると、内容が重複し、サイト内で評価が分散する可能性があります。 同じ検索意図であれば、原則として一つのページにまとめます。 不自然な口コミ・言及・被リンクを増やす AI検索で紹介されることを目的に、実態のない口コミ、言及、被リンクを作るのは避けます。 Googleは、生成AI検索を操作する目的を含むスパム行為にも、従来のスパムポリシーを適用しています。 長期的には、取材、事例、地域活動、調査データ、役立つテンプレートなど、自然に紹介される理由を作ることが重要です。 生成AIを記事制作に使う場合の正しい運用方法 AIは調査・構成・下書きの補助として使う 生成AIは、次のような作業と相性があります。 関連する疑問の洗い出し 記事構成の整理 長文資料の要点整理 表現の調整 誤字脱字のチェック 見出し候補の作成 Googleも、生成AIはテーマの調査や、独自コンテンツの構造化に役立つ場合があると説明しています。 人が事実確認と独自情報の追加を行う AIの出力をそのまま公開するのではなく、次を人が確認します。 事実関係は正しいか 情報は現在も有効か 公式な根拠があるか 自社の経験が反映されているか 既存記事と重複していないか 読者の判断に役立つ具体性があるか 生成AIなどを使い、ユーザーへの価値を追加せずに大量のページを作る行為は、Googleの「大量生成されたコンテンツの不正使用」に該当する可能性があります。 問題になるのはAIを使うこと自体ではなく、独自性や価値のないページを検索順位の操作目的で大量に公開することです。 誰が・どのように・なぜ作ったかを説明できる状態にする コンテンツ制作では、次の3点を説明できる状態が理想です。 Who：誰が作成・監修したか How：どのように調査・制作したか Why：なぜこの記事を公開したか AIを使用した場合も、読者にとって意味があるなら、使用方法や人による確認体制を説明します。 大切なのは「AIを使ったかどうか」ではなく、情報の正確性と責任の所在が明確になっているかです。 Search ConsoleとGA4でAI検索からの成果を測る方法 生成AIパフォーマンスレポートを確認する GoogleはSearch Consoleに、生成AI検索でのサイトの表示状況を確認する「Generative AI performance report」を提供しています。 このレポートでは、生成AI検索における表示の推移や、表示されているページ、デバイス、国などを確認できます。 ただし、段階的に展開されているため、すべてのSearch Consoleプロパティで表示されるとは限りません。 AI検索から閲覧されるページを把握する レポートが利用できる場合は、次を確認します。 どのページが表示されているか 表示が増えているテーマは何か デバイスや国による違いがあるか 表示されるページに共通する特徴は何か 順位だけを追うのではなく、どのテーマやページが生成AI検索で発見されているかを確認します。 GA4で回遊・問い合わせへの貢献を確認する 検索上で表示されること自体が最終目的ではありません。 GA4では、検索経由で訪問したユーザーについて、次を確認します。 サービスページへの遷移 事例・料金ページの閲覧 CTAクリック フォーム到達 問い合わせ・資料請求 エンゲージメント時間 Search Consoleで「見つけられているか」を確認し、GA4で「成果につながっているか」を確認することで、改善の優先順位を判断しやすくなります。 このまま使えるチェックリスト｜AI検索時代のSEO対策 コンテンツ ユーザーの質問に対する結論が明確に書かれている 結論に対する理由・根拠・具体例がある 自社独自の経験・事例・データが含まれている 他サイトの要約だけで終わっていない 読者が次に取るべき行動が分かる 著者・監修者・運営会社が明確になっている 公式情報や信頼できる情報源を確認している サイト構造 関連記事がテーマごとに整理されている 親ページと子記事が内部リンクでつながっている 記事からサービス・事例・料金ページへ移動できる 重要ページが孤立していない 同じ検索意図の記事が重複していない 技術面 Search Consoleに登録されている 重要ページにnoindexが入っていない robots.txtでクロールを拒否していない スマートフォンで読みやすい 主要な情報がテキストでも掲載されている 構造化データと画面上の内容が一致している AI活用 AIの文章をそのまま公開していない 人による事実確認を行っている 自社独自の知識や経験を追加している 量産を目的にしていない 定期的に内容を見直している 効果測定 Search Consoleで表示ページを確認している GA4で回遊・CTA・CVを確認している 表示だけでなく問い合わせへの貢献を見ている 成果の弱いページをリライトしている まとめ：AIに向けて書くのではなく、ユーザーにとって最も役立つ情報を作る AI検索時代のSEOでも、根本的な考え方は変わりません。 重要なのは、 ユーザーの疑問に明確に答える 独自の経験や一次情報を加える 根拠と発信者を明確にする サイト内の関連情報を整理する Googleがページを取得できる状態にする 公開後の成果を測定して改善する ことです。 AI専用のテクニックを追いかけるのではなく、ユーザーが読んで納得し、比較・判断・行動できるコンテンツを作ることが、従来の検索にも生成AI検索にも共通するSEO対策です。 無料相談 Refuでは、検索キーワードだけでなく、AI検索で深掘りされる関連質問や検索意図まで整理し、記事構成・サイト構造・内部リンク・サービスへの導線を設計しています。 「AI検索の普及で流入が減らないか不安」「今の記事をAI検索時代に合わせて見直したい」「生成AIを使った記事運用のルールを整えたい」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら SEOに強いサイト構造とは？カテゴリ設計と内部リンク最適化の基本 検索意図から逆算するキーワード設計｜中小企業のためのKWマップ作成法 E-E-A-Tを高めるコンテンツ設計｜信頼されるホームページの作り方 サービスページで上位を取るSEO｜「比較・不安・決め手」を埋める書き方 ホームページの回遊率を上げる導線改善｜内部リンクと関連記事設計のコツ 被リンクを増やす広報・PR設計｜中小企業でもできる獲得ルート7選
2026/08/05
デザイン・ブランディング問い合わせフォームのデザイン改善｜入力離脱を防ぐ項目・エラー表示・確認画面
問い合わせフォームは、サイト成果を左右する「最後の接客ページ」です。 ホームページを見てサービスに興味を持ち、実績や料金を確認したユーザーが、最後に訪れるのが問い合わせフォームです。 ここまで順調に比較検討が進んでいても、フォームが使いにくければ問い合わせにはつながりません。 例えば、次のような状態です。 入力項目が多く、面倒に感じる 何を書けばよいのか分からない エラーが表示されたものの、直す場所が分からない 送信後に営業されそうで不安になる スマホでは入力しづらい 問い合わせフォームは、単なる入力欄ではありません。 サイトを訪れたユーザーに対し、最後に「安心して相談できる」と感じてもらうための接客ページです。 まず結論：入力項目を減らすだけではなく「迷い・手間・不安」を減らす フォーム改善というと、「入力項目を少なくすればよい」と考えられがちです。 もちろん項目数は重要ですが、項目を減らすだけでは十分ではありません。 改善すべきポイントは、次の3つです。 迷いを減らす 何を、どのように入力すればよいかを明確にする 手間を減らす 文字入力や画面移動をできるだけ少なくする 不安を減らす 送信後の対応や個人情報の扱いを分かりやすくする この3点が整うと、ユーザーは途中で止まりにくくなります。 問い合わせフォームで離脱が起きる主な原因5つ 入力項目が多く、完了までの負担が大きい フォームを開いた瞬間に入力欄が何十個も並んでいると、それだけで「時間がかかりそう」と思われます。 特に初回問い合わせで、次のような情報をすべて必須にすると、入力の負担が大きくなります。 住所 部署名 役職 従業員数 予算 希望納期 詳細な相談内容 自社を知ったきっかけ 情報収集の目的は理解できますが、問い合わせ前に必要な情報と、問い合わせ後のヒアリングで確認できる情報は分けて考える必要があります。 必須項目と任意項目の違いが分かりにくい どの項目を入力しなければ送信できないのか分からないフォームは、ユーザーに余計な判断をさせます。 特に避けたいのが、次のような表示です。 必須項目にだけ小さな記号がある ページ下部に「※は必須です」とだけ書かれている 任意項目なのか必須項目なのか表示されていない 各項目の近くに、「必須」「任意」を分かりやすく表示しましょう。 入力方法や回答例が分からない 入力欄があっても、ユーザーが何を書けばよいか分からなければ、入力は進みません。 例えば「お問い合わせ内容」とだけ書かれているよりも、次のような補足がある方が答えやすくなります。 記入例 「既存サイトのリニューアルを検討しています。ページ数は10ページ程度で、問い合わせ増加を目的としています」 相談内容がまだ整理できていないユーザーに向けて、次のような一文を添える方法も有効です。 内容がまとまっていない段階でも問題ありません。現在のお悩みやご希望を分かる範囲でご記入ください。 エラーの場所と直し方が伝わらない 入力エラーが発生した際に、ページ上部へ「入力内容に誤りがあります」とだけ表示しても、ユーザーはどこを直せばよいか分かりません。 エラー表示では、次の2点を具体的に伝える必要があります。 どの項目に問題があるか どのように直せばよいか 例えば、「メールアドレスが正しくありません」だけでなく、次のように表示します。 メールアドレスの形式を確認してください。例：info@example.com ユーザーを責める表現ではなく、修正方法を案内する表現にすることが重要です。 送信後の流れが分からず不安になる ユーザーはフォームを送信する前に、送信後に何が起きるのかを気にしています。 いつ返事が来るのか 電話がかかってくるのか 営業連絡が増えないか 相談だけでもよいのか 費用が発生しないか 送信ボタンの近くに、次のような情報を記載すると安心感が高まります。 通常〇営業日以内に返信します ご相談・お見積りは無料です 内容を確認後、担当者よりメールまたは電話でご連絡します ご相談内容に応じてオンライン打ち合わせをご案内します 記載内容は、実際の対応方法と一致させる必要があります。 入力離脱を防ぐフォームデザインの改善ポイント 項目は「問い合わせ対応に必要か」で判断する 入力項目を決める際は、「あると便利」ではなく、初回対応に本当に必要かで判断します。 一般的なBtoBの問い合わせフォームであれば、最初は次の項目でも対応できます。 会社名 氏名 メールアドレス 電話番号 問い合わせ種別 問い合わせ内容 住所や予算、詳細な要件などは、問い合わせ後に確認できる場合があります。 ただし、問い合わせ内容によって事前情報が必要なサービスでは、必要項目を無理に削る必要はありません。 重要なのは、項目ごとに必要な理由を説明できる状態にすることです。 入力順はユーザーが答えやすい流れにする フォームの入力順は、運営側が管理しやすい順番ではなく、ユーザーが答えやすい順番にします。 おすすめの流れは次の通りです。 問い合わせ種別 相談内容 会社名・氏名 連絡先 希望する連絡方法や時間帯 最初から個人情報を求めるよりも、まず相談内容を選べる方が、ユーザーがフォームに入りやすい場合があります。 一方で、短いフォームであれば、会社名・氏名から始めても大きな問題はありません。 サイトの目的や項目数に合わせて、自然な順番を設計しましょう。 ラベルとプレースホルダーを正しく使い分ける 入力欄の上や横に表示する項目名をラベル、入力欄の中に薄く表示する例文をプレースホルダーと呼びます。 プレースホルダーだけで項目名を表示すると、文字を入力した後に項目名が見えなくなります。 そのため、基本的には次のように使い分けます。 ラベル：項目名を常に表示する プレースホルダー：入力例や補足を表示する 例 メールアドレス【必須】 プレースホルダー：info@example.com ラベルと入力例の役割を分けることで、入力途中でも内容を確認しやすくなります。 選択式を活用して文字入力を減らす スマホでは、文字入力そのものが負担になります。 回答内容がある程度決まっている項目は、次のような選択式を活用します。 ラジオボタン チェックボックス プルダウン 日付選択 希望時間帯の選択 例えば、問い合わせ種別であれば次のように設定できます。 ホームページの新規制作 ホームページのリニューアル 更新・保守について Web集客について その他 ただし、選択肢が多すぎるプルダウンは、かえって探しにくくなります。 選択肢が少ない場合は、ラジオボタンなど、最初から内容が見える形式が分かりやすいでしょう。 必須・任意の表示を統一する 必須項目だけに「必須」と表示する方法と、すべての項目に「必須」「任意」を表示する方法があります。 どちらを採用する場合でも、ページ内でルールを統一することが重要です。 おすすめは、次のような表記です。 会社名 必須 電話番号 任意 色だけで区別すると分かりにくい場合があるため、文字でも明示します。 また、必須項目が多すぎる場合は、本当にすべて必要なのかを見直しましょう。 エラーは入力欄の近くに具体的に表示する エラーが発生した項目は、次のように分かりやすくします。 入力欄の近くにエラーメッセージを表示する エラーがある入力欄を枠線などで示す ページ上部から該当項目へ移動しやすくする 入力済みの正常な内容は消さない エラーメッセージは、短く具体的にします。 悪い例 入力内容に誤りがあります。 良い例 電話番号は半角数字で入力してください。 エラーが起きたことではなく、次に何をすればよいかを伝えましょう。 送信ボタンは「押した後」が分かる文言にする 「送信」だけでは、押した後の状態が分かりにくい場合があります。 フォームの種類に合わせて、具体的な文言を設定します。 入力内容を確認する この内容で問い合わせる 無料相談を申し込む 見積りを依頼する 資料を請求する 確認画面へ進むボタンと、最終送信ボタンは、文言を分けることも重要です。 入力画面：入力内容を確認する 確認画面：この内容で送信する これにより、誤って送信してしまう不安を減らせます。 確認画面は必要？省略する場合の判断基準 確認画面には、入力内容を見直せるというメリットがあります。 一方で、画面が1つ増えるため、問い合わせ完了までの手順も増えます。 確認画面を設けた方がよいケースは、次の通りです。 入力項目が多い 長文や重要情報を入力する 予約内容や希望日時を確定する 送信後の修正が難しい 個人情報や契約に関わる情報を扱う 一方で、項目数が少ない簡易フォームであれば、入力画面上で内容を確認しやすくしたうえで、確認画面を省略する方法もあります。 重要なのは、確認画面の有無ではなく、誤送信の不安と完了までの負担のバランスです。 スマホで入力しやすいフォームを作るポイント スマホでは、PC以上にフォームの使いやすさが成果を左右します。 特に確認したいポイントは次の通りです。 入力欄が画面幅に合っている 文字が小さすぎない 項目同士の間隔が狭すぎない ボタンが指で押しやすい 電話番号入力時に数字用キーボードが表示される メールアドレス入力時に適切なキーボードが表示される エラー表示後、該当項目が見つけやすい 入力途中で内容が消えない また、横並びの項目は、スマホでは縦並びにした方が入力しやすい場合があります。 PC画面だけで確認せず、必ず実際のスマホで入力テストを行いましょう。 問い合わせの目的別｜おすすめ入力項目テンプレート 一般的なBtoB問い合わせフォーム 会社名【必須】 氏名【必須】 メールアドレス【必須】 電話番号【任意】 問い合わせ種別【必須】 問い合わせ内容【必須】 個人情報保護方針への同意【必須】 見積り依頼フォーム 会社名【必須】 氏名【必須】 メールアドレス【必須】 電話番号【任意】 希望サービス【必須】 希望時期【任意】 予算の目安【任意】 相談内容【必須】 予算を必須にすると離脱につながる場合があります。 予算が決まっていないユーザーのために、「未定」「相談したい」という選択肢を用意すると回答しやすくなります。 無料相談フォーム 会社名【必須】 氏名【必須】 メールアドレス【必須】 相談したい内容【必須】 希望する連絡方法【任意】 希望日時【任意】 日時調整を後から行う場合は、希望日時を無理に入力させる必要はありません。 計測と改善｜フォームのどこで離脱しているかを確認する フォームは公開して終わりではありません。 可能であれば、次のような行動を計測します。 フォームページの閲覧数 入力開始数 確認画面への到達数 送信完了数 エラーの発生数 各入力項目での離脱 例えば、フォームページは多く見られているのに送信完了が少ない場合、フォーム内に問題がある可能性があります。 確認画面までは進んでいるのに送信されない場合は、確認画面の見せ方や最終送信ボタンを見直します。 項目を変更した際は、変更前後で送信完了率を比較すると、改善効果を判断しやすくなります。 このまま使える問い合わせフォーム改善チェックリスト 入力項目は初回対応に必要なものへ絞られている 必須項目が多すぎない 必須・任意の表示ルールが統一されている 項目名が入力後も見える 入力例や補足説明がある 選択式で回答できる項目は文字入力を減らしている エラーが該当項目の近くに表示される エラーの修正方法が具体的に書かれている 入力エラー後も、入力済みの内容が保持される 送信ボタンの文言で、次の動作が分かる 送信後の返信時期や対応方法が書かれている 個人情報保護方針への導線がある スマホで入力・確認・送信までテストしている フォーム到達数と送信完了数を計測できている まとめ：フォームは入力欄ではなく「安心して相談できる体験」を設計する 問い合わせフォームの改善で重要なのは、単に入力項目を減らすことではありません。 迷わず入力できる 少ない負担で完了できる エラーが起きても修正できる 送信後の流れが分かる 安心して個人情報を預けられる この一連の体験を整えることが、問い合わせ完了につながります。 サイトへのアクセス数を増やしても、最後のフォームで離脱していれば成果は伸びません。 まずは実際に自社のフォームをスマホから入力し、ユーザーと同じ手順で、迷う場所や負担に感じる場所を確認してみましょう。 無料相談 Refuでは、問い合わせフォームを単体で見るのではなく、サービスページからフォームへの導線、入力項目、エラー表示、スマホでの操作性、送信後の案内まで一貫して確認します。 「フォームまでは見られているのに問い合わせが増えない」「入力項目をどう整理すべきか分からない」といった場合も、現状を整理したうえで改善方法をご提案します。 ▶ 無料相談はこちらから その他おすすめ記事はこちら CTA（問い合わせ・資料請求）を押したくなるデザイン改善チェックリスト スマホで差がつくUI改善｜押しやすさ・読みやすさのチェックポイント “なんとなく見づらい”を解決する情報設計｜見出し・箇条書き・図解の使い分け 料金ページのデザインで失注を防ぐ｜見せ方・不安解消・注意点まとめ ヘッダー・グロナビの正解は？迷わせないメニュー設計の基本
2026/08/04
リニューアル・運用ノウハウホームページの404エラーとは？SEOへの影響と正しい対処法
404エラーとは？ページが見つからない時に表示される状態 404エラーとは、ユーザーがアクセスしたURLに、該当するページが存在しない時に返されるHTTPステータスコードです。 ホームページを閲覧していて、次のような表示を見たことがある方も多いでしょう。 「ページが見つかりません」 「404 Not Found」 「お探しのページは削除または移動された可能性があります」 これらは、サーバーには接続できているものの、指定されたURLにページが存在しないことを示しています。 404エラーが発生したからといって、必ずしもサイトに重大な不具合が起きているわけではありません。重要なのは、なぜ404になっているのかを確認し、状況に合った処理をすることです。 404エラーが発生する主な原因 404エラーが発生する原因は、主に次のようなものです。 ページを削除した 古いサービスや終了したイベントなどのページを削除した場合、旧URLへアクセスすると404になります。 ページのURLを変更した リニューアルやサイト構造の変更でURLが変わり、旧URLから新URLへの転送が設定されていないケースです。 リンク先のURLが間違っている サイト内のリンクに入力ミスがある場合、存在しないURLへ移動してしまいます。 ユーザーがURLを間違えて入力した URLのスペルミスや文字の入力漏れでも404が発生します。 外部サイトに古いURLが掲載されている 取引先やポータルサイト、過去のSNS投稿などに旧URLが残っている場合もあります。 リニューアル直後に404が急増した場合は、URL変更に伴う301リダイレクトの設定漏れを最初に疑う必要があります。 404エラーはSEOに悪影響を与える？ 結論として、正しく返されている404エラーが存在するだけで、サイト全体の検索順位が下がるわけではありません。 Googleも、存在しないURLが正しい404レスポンスを返している場合、通常はサイトの検索パフォーマンスに影響しないと説明しています。 したがって、存在したことのないURLや、代替ページのない削除済みページまで、無理に修正する必要はありません。 ただし、次のような404は問題になります。 検索流入があった重要ページが404になっている 外部サイトからリンクされているページが404になっている サイト内の主要導線が404へつながっている リニューアル後に大量の404が発生している XMLサイトマップに404のURLが残っている 問題なのは404というステータスそのものではなく、本来ユーザーを案内すべきページが失われ、検索流入や導線が途切れていることです。 404エラーを修正すべきケース・修正しなくてもよいケース ページのURLを変更した場合 ページの内容は残っているものの、URLだけを変更した場合は、旧URLから新URLへ301リダイレクトを設定します。 例 旧URL /service-old/ 新URL /service/ この場合、旧URLを404のままにすると、検索評価や外部リンクからの流入が途切れる可能性があります。 ページを統合した場合 複数のページを1ページへまとめた場合は、それぞれの旧URLから統合先へ301リダイレクトを設定します。 ただし、内容の関係が薄いページへ無理に転送するのは避けましょう。旧ページで説明していた内容を引き継いだ、関連性の高い受け皿ページへ転送することが重要です。 ページを完全に削除した場合 ページを完全に削除し、代わりとなるページも存在しない場合は、404を返して問題ありません。 Googleは、コンテンツを完全に削除し、関連する代替ページがない場合は、404または410を返す方法を案内しています。また、Google検索では410も404と同じように扱われます。 「404があるとSEOに悪い」と考え、関係のないトップページへ転送する必要はありません。 サイト内のリンク先が間違っている場合 自社サイト内のリンクミスで404が発生している場合は、リンク先を正しいURLへ修正します。 特に確認したい場所は次のとおりです。 グローバルメニュー フッターメニュー バナー 記事内の内部リンク 事例からサービスページへのリンク 問い合わせボタン PDFや画像へのリンク サイト内リンクの間違いは、ユーザーの離脱だけでなく、検索エンジンによるページ発見にも影響するため、優先的に修正します。 Googleも、ページの発見やサイト内の関係性の理解にリンクが利用されると説明しています。 存在したことのないURLの場合 ユーザーの入力ミスや、不正なボットによって生成されたURLなど、もともと存在したことのないURLが404になる場合があります。 このような404は、基本的に修正しなくても問題ありません。 ただし、同じ入力ミスが繰り返されている場合や、外部サイトから間違ったURLでリンクされている場合は、正しいページへの転送を検討します。 301リダイレクトと404の正しい使い分け 301リダイレクトと404は、次の基準で使い分けます。 ページが移動した → 新しいURLへ301リダイレクト 複数ページを統合した → 内容を引き継いだ統合先へ301リダイレクト 同じ内容の代替ページがある → 関連性の高い代替ページへ301リダイレクト ページを完全に削除し、代替ページがない → 404または410 存在したことのないURL → 404のままで問題なし 避けたいのは、すべての404をトップページへ一括転送する方法です。 ページの内容とトップページの関連性が低い場合、ユーザーは探していた情報にたどり着けません。また、Googleからソフト404と判断される可能性があります。 Googleも、存在しないページをホームページなどへ転送したり、robots.txtでブロックしたりする対応を控えるよう案内しています。 ソフト404とは？通常の404との違い ソフト404とは、実際にはページが存在しない、または「ページが見つかりません」と表示されているにもかかわらず、サーバーが正常表示を示す「200」のステータスを返している状態です。 通常の404 ページが存在しない → HTTPステータスも404 ソフト404 ページが存在しないように見える → HTTPステータスは200など ソフト404になると、ユーザーにも検索エンジンにもページの状態が正しく伝わりません。 よくある原因は次のとおりです。 404ページを表示しているがステータスコードが200 削除ページをすべてトップページへ転送している 内容がほとんどないページを公開している 検索結果が0件のページを正常ページとして返している Googleは、存在しないページで404や410以外のコードを返したり、無関係なページへ転送したりすると、ソフト404として扱われる可能性があると説明しています。 404ページを使いやすくする改善ポイント ページが見つからないことを明確に伝える まずは、ユーザーに現在の状況を分かりやすく伝えます。 例 「お探しのページは見つかりませんでした」 「ページが移動または削除された可能性があります」 「URLが正しく入力されているかご確認ください」 専門用語だけでなく、ユーザーが次に何をすればよいかまで説明することが大切です。 トップページや主要ページへの導線を設置する 404ページに行き止まりしかないと、そのまま離脱されてしまいます。 次のようなリンクを設置しましょう。 トップページ サービス一覧 制作実績・導入事例 よくある質問 お知らせ・ブログ お問い合わせ ただし、サーバーが返すステータスコードは正しい404のままにします。 404ページ内にリンクを設置することと、URL自体をトップページへ転送することは別です。 サイト内検索や問い合わせ導線を用意する ページ数が多いサイトでは、サイト内検索を設置すると目的の情報を探しやすくなります。 また、サービスや商品を探しているユーザーを取りこぼさないように、問い合わせ導線を設置する方法もあります。 例 「お探しのサービスが見つからない場合は、お問い合わせください」 「ご相談内容に応じて担当者がご案内します」 404ページも、ユーザーを正しい情報へ戻すための導線として設計できます。 404エラーの確認方法 Google Search Consoleで確認する Google Search Consoleでは、インデックス関連のレポートやURL検査を使って、404として認識されているURLを確認できます。 確認するポイントは次のとおりです。 重要ページが404になっていないか サイトマップに記載したURLが404になっていないか リニューアル前のURLが大量に404になっていないか ソフト404が発生していないか リダイレクトエラーが出ていないか ただし、Search Consoleに404が表示されたからといって、すべてを修正する必要はありません。 そのURLに流入や代替ページがあるかを確認してから判断します。 サイト内リンクをチェックする サイト内のリンク切れは、定期的に確認しましょう。 目視だけでは漏れが出るため、ページ数が多い場合はリンクチェックツールやクロールツールを活用します。 特に確認したいのは次の場所です。 共通メニュー 古い記事 過去のキャンペーンページ 事例ページ PDF・画像ファイル 外部予約システムへのリンク リニューアル後は旧URLを重点的に確認する リニューアル後は、旧URLと新URLの対応表をもとに確認します。 旧URLへアクセスする 正しい新URLへ転送されるか確認する 最終ページが正常に表示されるか確認する 多段リダイレクトになっていないか確認する 転送先の内容が旧ページと関連しているか確認する 公開直後だけでなく、Search Consoleの情報が更新される期間も継続して確認します。 404エラー対応でよくある失敗 すべての404をトップページへ転送する 関連性のない一括転送は、ユーザーを迷わせ、ソフト404の原因にもなります。 404をrobots.txtでブロックする 検索エンジンがページの状態を確認できなくなるため、404を隠す目的でのブロックは避けます。 重要ページの404を放置する 流入や被リンクがあるページは、関連する新ページへ引き継ぐ必要があります。 404ページを正常な200ステータスで表示する 見た目だけ404でも、ステータスが200ならソフト404になる可能性があります。 404をゼロにすること自体を目標にする 存在しないURLが正しい404を返すのは正常です。 数を減らすことではなく、重要な導線が失われていないかを確認します。 404エラーチェックリスト 旧URLと新URLの対応表を作成している 移動したページには301リダイレクトを設定している 完全に削除したページは正しい404または410を返している すべての旧URLをトップページへ一括転送していない 404ページが200ステータスを返していない サイト内のリンク切れを確認している XMLサイトマップから削除済みURLを除外している Search Consoleで404・ソフト404を確認している 外部リンクや検索流入のあるURLを把握している 404ページに主要ページへの導線を設置している まとめ：すべての404を消すのではなく、原因に合わせて処理する 404エラーは、存在するだけでサイト全体のSEO評価を下げるものではありません。 重要なのは、404になっている理由を確認し、次のように処理を分けることです。 ページを移動したなら301リダイレクト 関連する代替ページがあるなら適切なページへ転送 完全に削除したなら404または410 サイト内リンクの間違いならリンクを修正 存在したことのないURLなら基本的に対応不要 リニューアル後やページ整理後は、404・リダイレクト・内部リンクをまとめて確認し、検索流入とユーザー導線を守りましょう。 無料相談 Refuでは、サイト内の404調査から、旧URLと新URLの整理、301リダイレクト設定、内部リンク修正、Search Consoleでの公開後確認まで一括で対応しています。 「リニューアル後に404が増えた」「どのURLを転送すべきか分からない」など、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら 301リダイレクト完全ガイド｜SEOを落とさずURL変更する手順と注意点 リニューアル後に検索順位が落ちた時の原因チェック｜最短で戻す改善手順 コンテンツ移行で失敗しないために｜旧サイト資産の棚卸しと移行判断基準 SEOを落とさないページ統合・削除の進め方｜残す/統合/消す判断基準と301設計 Googleサーチコンソールの基本操作と改善への活かし方
2026/08/03
ホームページ制作の基本ホームページの表示速度を改善する方法｜Core Web Vitalsと画像最適化の基本
ホームページの表示速度が重要な理由 ホームページを開いたとき、なかなか画面が表示されなかったり、ボタンを押しても反応しなかったりすると、ユーザーはストレスを感じます。 特にスマートフォンでは、通信環境や端末の性能によって表示速度が左右されるため、パソコンでは問題なくても、スマートフォンでは遅く感じられることがあります。 表示速度が遅い状態を放置すると、次のような問題につながります。 ページが表示される前に離脱される サービス内容や強みを読んでもらえない お問い合わせや予約まで進んでもらえない 企業や店舗に対する信頼感が下がる 検索結果で競合サイトに負けやすくなる 表示速度は、単なる技術的な問題ではありません。 ホームページを通じて成果を上げるための、ユーザー体験と導線設計の一部として考える必要があります。 Googleも、Core Web Vitalsを検索ランキングで考慮する要素の一つとしています。ただし、表示速度の点数が良ければ必ず上位表示されるわけではなく、コンテンツの関連性や有用性を含めた総合的なページ体験が重要です。 Core Web Vitalsとは？確認すべき3つの指標 Core Web Vitals（コアウェブバイタル）とは、実際のユーザーがページを利用したときの体験を、主に次の3つの視点から測定する指標です。 読み込みの速さ 操作に対する反応の速さ 表示の安定性 2026年7月時点では、LCP・INP・CLSの3つが主要な指標として使用されています。 LCP｜主要コンテンツが表示されるまでの速さ LCP（Largest Contentful Paint）は、画面内の主要な画像やテキストが表示されるまでの時間を測る指標です。 Googleが示す良好な目安は、2.5秒以内です。 LCPが遅くなる主な原因には、次のようなものがあります。 ファーストビューの画像容量が大きい サーバーからの応答が遅い 表示前に大量のJavaScriptを読み込んでいる 画像の読み込み開始が遅れている ホームページを開いても、メイン画像や見出しがなかなか表示されない場合は、LCPに問題がある可能性があります。 INP｜操作に対する反応の速さ INP（Interaction to Next Paint）は、ボタンのクリックやメニュー操作などに対して、ページがどれだけ素早く反応するかを測る指標です。 良好な目安は、200ミリ秒未満です。 INPが悪化しやすいケースとしては、次が挙げられます。 JavaScriptの処理が多い 外部の計測タグや広告タグが多い 複雑なアニメーションを使用している 問い合わせフォームの処理が重い 見た目は表示されていても、メニューやボタンの反応が遅い場合は、INPの改善が必要です。 CLS｜表示中のレイアウトの安定性 CLS（Cumulative Layout Shift）は、ページの読み込み中に、画像やボタン、文章などの位置が突然ずれる現象を測る指標です。 良好な目安は、0.1未満です。 たとえば、ボタンを押そうとした瞬間に広告や画像が表示され、違う場所を押してしまう状態は、CLSが悪い典型例です。 画像や動画の表示領域が事前に確保されていないことや、後から読み込まれるコンテンツ、Webフォントなどが主な原因になります。 まずは現状を測定する｜表示速度の確認方法 表示速度を改善するときは、感覚だけで判断せず、まず現在の状態を測定しましょう。 代表的な確認方法は、次の3つです。 PageSpeed Insights URLを入力すると、スマートフォンとパソコンの表示状況を確認できます。 主に次の情報が表示されます。 Core Web Vitalsの評価 実際のユーザーによる利用データ テスト環境で測定したパフォーマンス 改善できる項目 容量の大きい画像や不要なコード 実際のユーザーデータが表示される場合は、テスト時の点数だけでなく、実際のユーザーがどのような体験をしているかを優先して確認することが重要です。 Search ConsoleのCore Web Vitalsレポート Search Consoleでは、サイト内のページをグループ単位で確認できます。 特定の1ページだけでなく、サイト全体に共通する問題を見つけたい場合に向いています。Search Consoleのレポートは、実際の利用状況に基づくデータを使用しています。 Lighthouse Lighthouseは、表示速度だけでなく、アクセシビリティやSEOなども確認できる診断ツールです。 PageSpeed InsightsやChromeの開発者ツールから実行でき、具体的な問題を調査する際に役立ちます。 ホームページの表示が遅くなる主な原因 表示速度が遅くなる原因は、一つとは限りません。 よくある原因は次のとおりです。 画像の容量が大きい 動画をそのまま読み込んでいる JavaScriptやCSSが多い 外部サービスの読み込みが多い サーバーの応答が遅い WordPressのプラグインが多い キャッシュが正しく設定されていない Webフォントを多く使用している 広告やSNSの埋め込みが多い 古いテーマやコードを使用している まずはPageSpeed Insightsなどで問題を確認し、影響の大きい項目から改善することが大切です。 表示速度を改善する7つの方法 画像を圧縮・最適化する 企業サイトで表示速度を遅くしている原因として、特に多いのが画像です。 デジタルカメラやスマートフォンで撮影した写真を、そのまま掲載すると、1枚で数MBになることがあります。 次の方法で画像を最適化しましょう。 掲載場所に合ったサイズへ縮小する JPEG・PNGを適切に使い分ける WebPやAVIFなどの軽量な形式を検討する 画質を保てる範囲で圧縮する 画面外の画像は遅延読み込みを利用する ただし、ファーストビューの主要画像まで遅延読み込みにすると、LCPが悪化する可能性があります。 最初に表示する重要な画像は早く読み込み、それ以外の画像を遅らせるという使い分けが必要です。 不要なJavaScriptやCSSを減らす JavaScriptやCSSが多すぎると、ブラウザが画面を表示するまでの処理が増えます。 特に注意したいのが、次のような外部ツールです。 アクセス解析タグ 広告計測タグ SNS埋め込み チャットツール ヒートマップ アニメーション用ライブラリ すべて必要かを見直し、使っていないタグや機能は削除しましょう。 ファイルの圧縮や読み込み順序の変更も有効ですが、専門的な作業になるため、制作会社やエンジニアに確認するのが安全です。 サーバーとキャッシュ設定を見直す 画像を軽くしても改善しない場合は、サーバー側に原因がある可能性があります。 確認したいポイントは次のとおりです。 サーバーの処理性能 PHPなどの実行環境 ページキャッシュの有無 ブラウザキャッシュの設定 CDNの利用 データベースの状態 LCPを改善するには、画像だけでなく、HTMLの最初のデータが届くまでの時間や、主要コンテンツの読み込み開始時期など、ページ全体の読み込み工程を確認する必要があります。 アクセス数やサイト規模に対してサーバー性能が不足している場合は、プラン変更やサーバー移転も選択肢になります。 ファーストビューの読み込みを優先する ファーストビューとは、ページを開いたときに最初に表示される範囲です。 ここに大きな画像、動画、複雑なアニメーションを多く配置すると、ユーザーが内容を確認できるまでに時間がかかります。 改善方法としては、次が挙げられます。 メイン画像の容量を小さくする 背景動画の自動再生を見直す 最初に必要なCSSを優先して読み込む ファーストビューに不要な外部ツールを置かない メイン画像を早い段階で読み込ませる 見た目の華やかさだけでなく、ユーザーがすぐに内容を理解できるかを基準に設計しましょう。 Webフォントを使いすぎない Webフォントは、デザインの統一感を出すうえで便利です。 一方で、種類や文字の太さを多く読み込むと、表示速度に影響します。 次のような見直しが有効です。 使用するフォントを絞る 使用する文字の太さを減らす 不要な言語のフォントデータを読み込まない システムフォントの使用を検討する フォントの読み込み中も文字を表示できる設定にする デザイン性と表示速度のバランスを考えることが大切です。 画像や広告によるレイアウトのずれを防ぐ 画像や動画、地図、広告などの表示領域が決まっていないと、読み込み後にコンテンツが押し下げられます。 CLSを改善するためには、次の対策が有効です。 画像に幅と高さを設定する 動画や地図の表示領域を先に確保する 後から表示するバナー用のスペースを用意する ページ上部へ突然コンテンツを追加しない Webフォントによる文字幅の変化を抑える ユーザーが操作しようとしているボタンやリンクを動かさないことが重要です。 WordPressのプラグインを整理する WordPressでは、プラグインを追加するだけでさまざまな機能を利用できます。 しかし、プラグインが増えすぎると、次の問題が起こりやすくなります。 不要なファイルが読み込まれる データベース処理が増える プラグイン同士が競合する 管理画面やページ表示が遅くなる セキュリティ管理が複雑になる 使用していないプラグインは停止するだけでなく、必要に応じて削除しましょう。 ただし、削除によってフォームや表示が動かなくなることもあるため、バックアップを取ってから作業することが重要です。 症状別｜優先して改善すべきポイント ページ全体の表示開始が遅い 確認する項目 サーバーの応答速度 キャッシュ設定 リダイレクトの回数 WordPressやデータベースの処理 メイン画像の表示が遅い 確認する項目 画像容量 画像形式 読み込みの優先順位 ファーストビュー画像への遅延読み込み ボタンやメニューの反応が遅い 確認する項目 JavaScriptの処理 外部タグの数 アニメーション フォームや検索機能の処理 読み込み中に画面が大きくずれる 確認する項目 画像の幅・高さ 動画や地図の表示領域 後から表示されるバナー Webフォント 原因によって対応方法が異なるため、PageSpeed Insightsの点数だけで判断せず、どの指標に問題があるかを確認しましょう。 表示速度改善でよくある失敗と注意点 失敗1：PageSpeed Insightsで100点を取ることが目的になる 点数を上げること自体が目的ではありません。 Googleも、Core Web Vitalsの良好な結果だけで検索上位が保証されるわけではなく、SEOのためだけに満点を目指すことは必ずしも有効ではないと説明しています。 重要なのは、ユーザーが快適にページを利用できることです。 失敗2：必要な画像や機能まで削除してしまう 画像や動画、フォーム、チャットなどは、ビジネス上必要な場合があります。 単純に削除するのではなく、次の視点で判断しましょう。 問い合わせに貢献しているか 信頼感を高めているか ユーザーの理解を助けているか 軽量化や読み込み方法の変更で残せないか 失敗3：トップページだけを確認する ユーザーが最初に訪れるのは、トップページとは限りません。 検索からブログ記事、サービスページ、事例ページへ直接アクセスすることもあります。 次のページは個別に確認しましょう。 トップページ 主要サービスページ アクセス数の多い記事 お問い合わせフォーム 採用ページ 広告やSNSのリンク先 失敗4：一度改善して終わる 画像やプラグイン、外部タグは運用中に増えていきます。 公開時は速くても、数年後には遅くなっていることがあります。 月次や四半期ごとなど、定期的に確認する仕組みを作りましょう。 表示速度の改善チェックリスト スマートフォンとパソコンの両方で測定したか 実際のユーザーデータを確認したか LCP・INP・CLSのどこに問題があるか把握したか ファーストビュー画像を圧縮したか 画像の表示サイズに合ったデータを使用しているか 不要なJavaScriptや外部タグを整理したか キャッシュ設定を確認したか WordPressの不要なプラグインを整理したか 画像や動画の表示領域を事前に確保したか 主要ページを個別に確認したか 改善後にフォームや表示の動作確認をしたか 定期的に測定する担当者と頻度を決めたか すべてを一度に改善する必要はありません。 まずは、容量の大きい画像・不要な外部タグ・サーバーの応答速度など、影響の大きい部分から着手しましょう。 まとめ：点数ではなくユーザー体験を改善する ホームページの表示速度は、SEOのためだけに改善するものではありません。 ユーザーがストレスなく情報を確認し、問い合わせや予約、応募へ進める状態を作ることが本来の目的です。 表示速度を改善するときは、次の順番で進めましょう。 PageSpeed InsightsやSearch Consoleで現状を確認する LCP・INP・CLSのどこに問題があるか把握する 画像・コード・サーバーを影響の大きい順に見直す 改善後に表示とフォームの動作を確認する 定期的に測定して、遅くなる前に対処する 点数だけを追うのではなく、ホームページの目的や必要な機能を維持しながら、ユーザーにとって快適な状態を目指すことが重要です。 無料相談 Refuでは、PageSpeed InsightsやSearch Consoleを活用した現状分析から、画像最適化・サーバー環境・WordPressの構成まで確認し、優先順位を付けた表示速度改善をご提案しています。 「ホームページの表示が遅い」「改善項目が多く、どこから手を付ければよいか分からない」という方も、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら スマホ対応は必須！レスポンシブデザインの基本 ドメイン・サーバーの選び方｜初心者でも失敗しない基礎知識と注意点 ホームページ公開後にやるべき初期設定10選｜最低限の運用準備チェック ホームページのKPI設計｜アクセス・CV・問い合わせを“数字で改善”する方法 GA4で最低限見るべき指標7つ｜初心者でも分かる分析のはじめ方 Search Consoleの見方入門｜流入キーワードと改善ポイントの見つけ方
2026/07/16
集客・マーケティング戦略失注を減らす問い合わせ対応術｜返信テンプレと追客フローの作り方
問い合わせは“獲得”より「初動」で勝負が決まる SEO・広告・SNSなどで問い合わせが増えても、その後の対応が弱いと受注にはつながりません。 実務では、次のようなケースがよくあります。 返信が遅い 返信内容が薄く、次のステップが分からない 見積り後に追客できず自然消滅する 問い合わせは、獲得した瞬間がゴールではありません。 むしろ、問い合わせ後の初動対応こそが受注率を左右します。 特に最初の24時間の対応で、相手の印象は大きく変わります。 まず結論：失注の多くは「遅い・薄い・放置」で起きる 問い合わせ後の失注は、サービス品質以前に次の3つで起きることが多くあります。 遅い：返信が遅く、相手の熱が冷める 薄い：返信内容がテンプレ的で不安が残る 放置：追客がなく、自然消滅する 逆に言えば、この3つを改善するだけで、同じ問い合わせ数でも受注率を高められる可能性があります。 失注が増える問い合わせ対応の落とし穴 返信が遅い 比較検討中のユーザーは、複数社へ同時に問い合わせていることが少なくありません。 返信が1営業日以上遅れるだけで、候補から外れてしまう可能性があります。 次のステップが分からない 「お問い合わせありがとうございます。追ってご連絡します。」 だけでは、相手は次に何が起こるのか分かりません。 いつ連絡が来るのか 何を準備すればよいのか どのように進むのか を伝えることが重要です。 ヒアリング不足で提案がズレる 要望や背景を十分に聞かないまま見積りを出すと、提案内容がズレやすくなります。 ズレた提案は、「この会社は分かっていない」という印象につながります。 見積りの根拠が弱い 金額だけを提示しても、納得感は生まれません。 何が含まれているのか どこまで対応するのか 追加費用はあるのか を明確にしましょう。 追客ができていない 返信が止まったからといって、必ずしも失注とは限りません。 相手が忙しいだけ、社内確認中、比較検討中というケースもあります。 追客の仕組みがないと、そのまま自然消滅してしまいます。 まず整えるべき問い合わせ対応ルール 返信スピードの基準を決める おすすめの目安は次の通りです。 自動返信：即時 一次返信：当日〜翌営業日午前中 見積り・提案の初回提示：3営業日以内 明確な基準があるだけで、対応漏れや返信遅れを防ぎやすくなります。 対応する役割を決める 問い合わせ対応では、役割分担が重要です。 基本の役割 受付：一次返信・日程調整 担当者：ヒアリング・提案 決裁者：見積り確認・最終判断 1人で対応する場合でも、この順番を決めておくと対応が止まりにくくなります。 ヒアリング項目を固定する 最低限、次の5つは確認しましょう。 目的 現状 期限 予算感 意思決定者 聞く内容を固定すると、提案の精度が上がります。 管理表を用意する CRMがなくても、最初はスプレッドシートで十分です。 重要なのは、問い合わせを管理し、次の対応を忘れない仕組みを作ることです。 初動返信テンプレート 資料請求・相談向け 件名 【ご連絡ありがとうございます】資料のご案内／次のステップについて 本文 〇〇様 この度はお問い合わせありがとうございます。株式会社〇〇の△△です。 資料は本メールにてご案内いたします。 より的確なご案内のため、差し支えなければ下記について教えていただけますでしょうか。 ご検討の目的 現在の状況 ご希望時期 ご返信いただけましたら、状況に合わせておすすめの進め方や概算の考え方をご案内いたします。 どうぞよろしくお願いいたします。 見積り依頼向け 件名 【お見積りの件】ヒアリングのお願い 本文 〇〇様 お見積りのご依頼ありがとうございます。株式会社〇〇の△△です。 正確なお見積りのため、以下を確認させてください。 分かる範囲で構いません。 ご相談の目的 参考サイト 必要なページや機能 ご希望納期 ご予算感 いただいた内容をもとに、概算費用と進め方をご案内いたします。 必要であれば、30分ほどのオンラインヒアリングも可能です。 どうぞよろしくお願いいたします。 緊急相談向け 件名 【ご相談内容を確認しました】本日・明日のご相談も可能です 本文 〇〇様 ご相談ありがとうございます。株式会社〇〇の△△です。 内容を確認いたしました。 お急ぎの場合、本日または明日で30分ほどのオンライン相談が可能です。 下記よりご都合の良い時間をお知らせください。 本日 〇〇：〇〇 明日 〇〇：〇〇 事前に、現状のURLと最も困っていることを1行でお送りいただけると、当日のご案内がスムーズです。 どうぞよろしくお願いいたします。 追客フローで自然消滅を防ぐ 追客はしつこさではなく親切 追客は、相手を急かすためではありません。 迷っているポイントや不安を解消するための対応です。 価値ある情報を添えた追客であれば、不快感を与えにくくなります。 追客は3回で十分 おすすめの追客タイミングは次の通りです。 1回目：提案・見積り送付の2日後 2回目：1週間後 3回目：2週間後 それ以上は、相手の温度感を見ながら判断します。 追客メールテンプレート 件名 先日のご提案について補足です 本文 〇〇様 先日はありがとうございました。 ご提案内容はご確認いただけましたでしょうか。 検討時によくご質問いただく点を簡単にまとめました。 追加費用が発生するケース：＿＿＿＿ スケジュールの目安：＿＿＿＿ 近い事例：＿＿＿＿ ご不明点があれば、1点だけでもお気軽にご返信ください。 短く回答いたします。 どうぞよろしくお願いいたします。 反応がない理由を切り分ける 反応がない理由は、主に次のどれかです。 忙しくて後回しになっている 社内決裁で止まっている 予算で迷っている 競合と比較している 追客では、「どこで止まっているか」を確認すると前に進みやすくなります。 失注を減らす提案・見積りの出し方 比較される前提で出す 問い合わせ後の提案は、他社と比較される前提で作ります。 そのため、 何が含まれているか 何が含まれていないか 自社の強みは何か を明確にしましょう。 見積りの根拠を明記する 金額だけではなく、内訳や前提条件を伝えることで納得感が高まります。 記載したい内容 作業項目 想定ページ数 打ち合わせ回数 修正回数 制作範囲 追加費用の条件を明確にする 追加費用が曖昧だと、「後から増えそう」という不安につながります。 最初の提案段階で、追加費用が発生する条件を伝えておきましょう。 次のアクションを決めて終える 提案後に「ご検討ください」で終わると止まりやすくなります。 最後に、 次回打ち合わせ候補日 決裁までの流れ 追加確認事項 を提示しましょう。 CRMなしでも回る管理表テンプレート 必須項目 問い合わせ管理表には、最低限次の項目を入れます。 問い合わせ日時 氏名・会社名 連絡手段 問い合わせ内容 温度感 担当者 ステータス 次回アクション日 メモ ステータス例 未返信 一次返信済み ヒアリング中 提案済み 追客中 受注 失注 特に重要なのは「次回アクション日」です。 これがあるだけで対応漏れを大きく減らせます。 見るべきKPI 月1回は次の数字を確認しましょう。 初動返信までの平均時間 問い合わせから商談化した割合 商談から受注した割合 失注理由 問い合わせ数だけでなく、受注までの歩留まりを見ることが重要です。 このまま使える問い合わせ対応チェックリスト 自動返信が即時で届く 一次返信が当日〜翌営業日午前中にできている 返信テンプレートが温度感別に用意されている ヒアリング項目が固定されている 見積りに内訳・前提条件がある 追加費用の条件が明記されている 追客が3回設計されている 管理表に次回アクション日がある 月1回、返信速度・商談化率・失注理由を確認している まとめ：問い合わせ対応は“文章”より“設計”で改善できる 問い合わせが来ているのに受注につながらない場合、原因は集客ではなく対応設計にあるかもしれません。 重要なのは、 早く返信する 次のステップを明確にする ヒアリング項目を固定する 見積りの根拠を示す 追客を仕組み化する ことです。 問い合わせ対応を整えるだけで、同じ問い合わせ数でも受注率を高められる可能性があります。 無料相談 Refuでは、問い合わせ対応の返信テンプレート作成、追客フロー設計、管理表の整備、失注理由の分析まで含めて、受注につながる運用改善をサポートしています。 「問い合わせは来るのに受注につながらない」「追客ができず自然消滅してしまう」という方は、お気軽にご相談ください。 ▶ 無料相談はこちらから その他おすすめ記事はこちら お問い合わせが増えるCTA設計｜ボタン文言・配置・タイミングの鉄則 料金ページのデザインで失注を防ぐ｜見せ方・不安解消・注意点まとめ BtoBのリード獲得を加速する「資料請求」導線の作り方 Web集客に必要なKPIとは？成果を数値で管理する方法｜中小企業が“改善できるサイト”を作る基礎知識 GA4で“集客のムダ”を見つける方法｜チャネル別に成果を伸ばす分析手順
