ホームページのメニューに「何個まで」という絶対の上限はありません。5〜7個という目安を見かけることはありますが、実際に直すべきかを左右するのは、利用者が項目の違いを見分けられるか、重要な入口が埋もれていないか、スマホで開いて選べるか――この三点。増えすぎたと感じたらページをいきなり削らず、訪問目的を洗い出し、上位に残す親項目、親項目の下へまとめる詳細、フッターやページ内へ移す補助情報の三層に分けて置き場所を決めます。

メニューはページ一覧ではなく、利用者が次の行き先を選ぶための案内。会社側が見せたい情報を同じ強さで並べると、選択肢が増えるだけでなく、似た言葉の違いまで利用者に考えさせかねません。そこで採るのが、残す・まとめる・下げる・削るの順で整理し、メガメニューやスマホ表示まで含めて確かめる手順。

ホームページのメニューに絶対の上限はない

ここでいうメニューは、各ページの上部に共通して表示されるグローバルナビゲーションが中心です。項目が4個でも「サービス」と「事業案内」の違いが曖昧なら迷いやすい一方、8個あっても役割が明確で短い言葉に分かれていれば、必ずしも破綻しているとは限りません。個数は判断の入口にすぎず、それだけで合否を決めることはできない――これが出発点。

同じ個数でも、ヘッダーにロゴ、検索、言語切替、問い合わせボタンが並ぶサイトと、メニューだけのサイトでは使える横幅が変わり、日本語では収まっても英語表記で折り返す場合があります。文字を小さくして押し込めば読みやすさとタップしやすさを損なうため、他サイトの目安を借りる前に、自社のラベルと周辺要素を入れた画面で確かめるのが先決。

見直しの兆候は、項目名を短くするために意味を削っている、重要な項目が端へ追いやられている、同じような親項目が並ぶ、スマホでは長い一覧を何度も開閉しなければならない、さらにトップ階層へ採用・投資家情報・規約・会員向け情報まで同列に置いて主要な見込み客向けの入口が埋もれている、といった状態です。Nielsen Norman Groupも、主要ナビゲーション、補助ナビゲーション、ローカルナビゲーション、フッターを役割別に置き、フッターは主要ではない利用者層向けのカテゴリにも使えると整理しており、重要なのは情報を消すことではなく、役割に応じて置き場所を分けることです。（参考：Nielsen Norman Group「Menu-Design Checklist: 17 UX Guidelines」）

では、「10個だから多すぎる」「6個なら問題ない」と決めてよいのでしょうか。まず下の4点を原寸のパソコン表示とスマホ表示で見て、どこが崩れているかを特定した後に数を調整します。ラベルの曖昧さや階層のねじれを放置して項目だけ減らしても、利用者の迷いは解けないまま。

メニュー数を目的の違い、ラベル、重要項目、スマホ操作の4状態で判断する図

最初に「誰が何をしに来るか」を並べる

整理を始めるとき、現在のページ名や社内の部署名から考えると、既存構造に引っ張られます。先に書き出すのは「初めて来た人がサービスを比較する」「取引中の人がサポート窓口を探す」「応募者が募集条件を確認する」といった訪問目的。同じページが複数の目的に関わることもあるため、ページ名ではなく行動を主語にすると、上位に必要な入口が見えやすくなります。

訪問目的を「サービスを見る」のような広い言葉で止めてはいけません。何を比較し、どの不安を解消し、次に何を決めるのか。初回利用者が対応範囲を知りたい場合と、検討中の人が料金や事例を比べたい場合では、同じ「サービスを見る」でも必要な入口が異なるため、ここまで具体化して初めて、上位に置く親項目と親ページ内で案内する情報を分けやすくなります。

  1. 主な利用者を、見込み客・既存顧客・応募者などの立場で分ける
  2. それぞれが最初に確認したいことと、最終的に取りたい行動を書く
  3. 目的を達成するために必要なページをひも付ける
  4. 事業上の重要度、利用頻度、緊急性の三つから優先度を仮置きする

アクセス解析があっても、クリック数だけで順位を決めないでください。クリックが少ない理由には、需要が低い場合だけでなく、言葉が分かりにくい、位置が悪い、メニューを開かないと見えない場合もあります。そこで重ねて見たいのが、問い合わせ内容、サイト内検索語、営業担当がよく受ける質問。利用者が探しているのに見つけられていない情報を拾うためです。

優先度を決める会議で避けたいのは、各部署が一つずつ枠を確保する方式。上位メニューは組織図ではなく、利用者の経路です。部署ごとの要望に求めたいのは、どの訪問目的を支えるか、既存の親項目の下へ入れられないかまでの説明。

上位メニューに残す項目を決める

上位に残す候補は、主要な訪問目的へ直結すること、複数の関連ページを受け止められること、隣の項目と意味が重ならないこと、事業が少し変わっても使い続けられることの四条件で見ます。たとえばサービスが三つあっても、三つとも上位へ並べる必要はありません。「サービス」という親項目の下で比較できるなら、上位は一つの入口で十分。全体像と詳細の両方を示せます。

親項目を設けるなら、クリックしても何も起きない見出しだけにせず、親ページでも全体像を示してください。サービスごとの対象、違い、選び方、関連する料金や事例への入口がなければ、サブメニューを使えない環境や検索から直接来た人に次の経路が残りません。親項目の役割は、下位ページを隠す箱ではなく、関係を説明する案内役。

ラベルで優先したいのは、社内で使う部門名や独自の造語より、利用者が中身を予測できる言葉。「ソリューション」「価値創造」のように範囲が広すぎる語は、見た目が短くても選択の助けになりませんが、「料金」「導入事例」「採用情報」のように行き先を想像しやすい語なら、読む前から判断材料になります。Nielsen Norman Groupが示す指針も同じで、明確・具体的・馴染みのある言葉を使い、重要語を前へ置くというものです。（参考：Nielsen Norman Group「Menu-Design Checklist: 17 UX Guidelines」）

次の図は、ページ単位で十項目を並べる状態から、利用目的を表す五つの親項目へまとめる例。五つを正解とする図ではなく、サービスA・B・Cや代表挨拶を消さず、上位で選ばせる単位だけを変えています。詳細ページは親項目の下で一覧化し、親ページには各選択肢の違いが分かる説明を置く構成。

十個のページ名を五つの上位メニューへまとめ、詳細を下層へ置く前後比較図

「お問い合わせ」を常に上位へ置くかは、サイトの目的次第。相談や予約が主要成果なら目立つ位置が合理的ですが、既存顧客のログインや資料検索が中心なら、別の行動を優先する方が自然です。判断基準は、項目名の人気ではなく、主要な利用者が目的を達成する順序。

「まとめる・下げる・削る」で置き場所を分ける

上位に残さない項目を、すべて削除する必要はありません。「まとめる」は複数ページを親項目の下に置くこと、「下げる」は補助ナビゲーション、フッター、各ページ内の関連リンクへ移すこと、「削る」はページ自体の役割をなくすこと。この三つを混同すると、メニューは短くなっても必要な情報へ到達できないため、置き場所の判断とページの存廃を切り分けます。

判断 向いている項目 置き場所の例 確認すること
上位に残す 主要目的へ直結し、他と役割が重ならない ヘッダーの主ナビゲーション 初めて来た人が名前だけで中身を予測できるか
まとめる 同じ利用目的で比較されるサービスや情報 親項目の下層、カテゴリ一覧 親ページで違いと選び方を説明できるか
下げる 規約、プライバシー、補助窓口、対象が限られる情報 フッター、補助ナビ、ページ内リンク 直接流入した人にも現在地と次の経路が分かるか
削る・統合する 内容が重複し、今後も独立した役割がない 近いページへ統合、必要に応じて転送 外部リンク、検索流入、既存案内の行き先を失わないか

フッターへ移すのは「重要でないから隠す」ためではなく、主要な選択を妨げず、必要な人には見つけられる場所へ分けるためです。採用が主要な目的なら上位、採用頻度が低く見込み客向け情報を優先するサイトならフッターや会社情報の配下。同じ項目でも、事業目標と利用者構成によって置き場所は変わります。

下げる候補を決める際は、情報の重要度と表示頻度を混同しないでください。プライバシーポリシーや特定商取引法表記は頻繁に選ばれなくても、必要な場面で確実に到達できることが条件。上位に常時出さない代わりに、フッターの名称を明確にし、関連するフォームや手続きページからも近い経路を用意します。

ページを統合・削除する場合、分けて確認したいのが、メニューから外す作業とURLをなくす作業。検索結果、ブックマーク、他サイト、営業資料から直接開かれるページは、メニューに見えなくても入口として機能するためです。移転先があるなら内容を引き継ぎ、古いURLから適切な行き先へつなぐところまでが変更範囲。

主要目的、意味の重複、常時表示の必要性を問い、ページの置き場所を決める判断フロー

メガメニューは選択肢が多い理由がある時に使う

メガメニューは、広いパネル内に複数のグループと下位項目をまとめて表示する仕組みです。商品カテゴリや拠点、用途が多く、利用者が一覧を見比べる必要があるサイトなら、深い階層を一段飛ばして選べるのが利点。ただし、上位カテゴリ自体が重複したまま大きな箱をかぶせても、情報設計の問題は解決しません。

採用するなら、関連する選択肢を意味のあるまとまりに分け、グループは細かすぎず大きすぎない粒度にし、ラベルを短く具体的にします。重要なグループを先に置き、同じリンクを複数箇所へ重ねないことも欠かせない条件。Nielsen Norman Groupが勧めているのも、選択肢を関連集合へ分け、各選択肢を一度だけ示し、単純さを保つ設計です。（参考：Nielsen Norman Group「Mega Menus Work Well for Site Navigation」）

操作はマウスのホバーだけに依存させず、クリック・タップ・キーボードでも開閉できる形が前提。手の動きを細かく制御しにくい人は、ポインターを一定範囲へ保つフライアウト操作が難しい場合があります。W3Cが親項目のページにも下位リンクを置くなど別の到達手段を案内するのは、メニューを開けない状況でも情報へ進める経路を残すためです。見た目の豪華さより、まず代替経路。（参考：W3C Web Accessibility Initiative「Fly-out Menus」）

小規模なコーポレートサイトで下位項目が数件しかないなら、通常の親ページと一段のサブメニューで足りることも多いでしょう。メガメニューを選ぶ条件は、「項目を減らせない事情」と「一覧比較させる価値」の両方があること。装飾や流行だけで導入しない方が、保守もしやすくなります。

スマホは項目数より「開いて選べるか」で確認する

スマホでは多くのサイトがメニューをボタンの中へ隠しますが、隠れた時点で項目数が見えなくなるため、パソコン版を縮めただけでは判断できません。Nielsen Norman Groupの調査では、隠れたナビゲーションは見つけにくく、表示されているナビゲーションや一部を表示する組み合わせより利用指標が悪化しました。限られた画面で問われるのは、メニューボタンを使うかどうかだけではなく、サイト名、現在地、重要な入口のどこまでを見せたままにするか。（参考：Nielsen Norman Group「Hamburger Menus and Hidden Navigation Hurt UX Metrics」）

確認は、360px前後の幅でメニューを開き、片手で目的項目まで進むところから始めます。見るべきは、ラベルが二行になって区切りを見失わないか、下位階層を開いた後に一段戻れるか、長い一覧の末尾までスクロールできるか、閉じた後に元のページへ戻れるかの四点。さらに、タップ領域の狭さ、開閉ボタンと親ページへのリンクの競合、背景まで一緒に動く問題も、項目数とは別に確認してください。

パソコンではマウスで使えても、キーボードのTabキーで下位項目へ入れない場合があります。実機で確かめたいのは、クリックで開く、開閉状態が伝わる、フォーカスの位置を見失わない、親ページからも下位へ進める、の四点。特に二段、三段と横へ開くカスケード型は操作が難しくなりやすいため、深い構造は一覧ページへ渡した方が安定するでしょう。（参考：Nielsen Norman Group「Menu-Design Checklist: 17 UX Guidelines」）

公開前後は実際の経路で検証する

整理案ができたら、担当者が項目名を眺めて終わりにせず、「初めて来た人が三つのサービスの違いを知る」「既存顧客が連絡先を探す」「応募者が勤務条件を確認する」など、最初に書き出した訪問目的をそのまま課題にして確かめます。制作に関わっていない人へ操作してもらうと、社内では自明だった言葉の曖昧さが見つかることも。

検索や広告から下層ページへ直接入る経路も試してください。トップページを経由しない人にとって、現在地を示す表示、同じカテゴリのローカルナビゲーション、親ページへのリンクが次の判断材料。ヘッダーメニューだけを簡素化しても、下層ページで自分の位置が分からなければ回遊は改善しないため、パンくずや関連導線も一緒に確認します。

見るのはクリック数の少なさではなく、最初の選択が合っていたか、途中で戻ったか、別の項目を何度も開いたか、目的ページへ着いた後に次の行動が分かったか。上位項目を減らした結果、下層で探し直す時間が増えたなら、単に負担を移しただけかもしれません。必要なのは、親ページの説明、下位項目の並び、現在地表示まで含めた調整。

公開後は、メニュー開閉、主要リンクのクリック、サイト内検索、問い合わせ内容を期間を決めて比べます。ただし、数字の増減だけで即座に項目を戻すのは禁物。季節要因や広告、採用時期など別の変化も確認し、低クリックでも法的・契約上必要な情報は残します。高クリックでも他の導線から十分届くなら、上位に置かない判断はあり得るでしょう。

再び増やさないために必要なのは、新しいページを作るたび「既存の親項目へ入るか」「上位へ出すほど主要な訪問目的か」「期間限定ならページ内告知で足りるか」を確かめる運用ルール。追加のたびに全員の希望を足すのではなく、既存項目との入れ替えまで決める仕組みにすれば、上位メニューの役割を保てます。

メニューだけを直しても解決しないケース

サービス同士の違いを社内でも説明できない、同じ内容のページが部門ごとに存在する、古い事業名と新しい事業名が混在する場合、メニューだけを並べ替えても曖昧さは残ります。先に整理すべきなのは、事業のまとまり、各ページの役割、誰に何を伝えるかという土台。ナビゲーションはサイト構造の表面にすぎず、下にある情報の重複や欠落までは隠せません。

ページを減らす判断がURL変更、文章の統合、問い合わせ経路の変更まで広がるなら、小さなメニュー修正ではなくリニューアルの範囲。現行ページの一覧、残す内容、統合先、公開後の更新担当までを一緒に決めることが、見た目だけ整えて再び増える状態を避ける条件です。ページ構成や言葉、導線から見直す進め方は、Bäm（バム）の「相談から始めるホームページ制作」でも確認してください。

まず現行メニューを一行ずつ書き出し、その横に「誰の、どの目的を支えるか」を記入してください。答えが重なる項目はまとめる候補、主要目的と結び付かない項目は下げる候補、独立した役割を説明できないページは統合・削除の候補。個数を先に決めるのではなく、利用者が迷わない選択単位を作り、その結果として必要な数へ落ち着かせます。

参考資料