アプリケーション上部に横並びで配置されるトップレベルメニュー群。「ファイル」「編集」「表示」などの機能カテゴリをクリックするとドロップダウンが展開する、デスクトップアプリの操作体系をWebアプリに持ち込むコンポーネント。テキストエディタ・スプレッドシート・IDEなど、機能数が多いプロダクティビティアプリで使われる。
この記事を読むと、MenubarとTop nav・ContextMenuの使い分け・キーボードショートカット表示・ARIA role="menubar" の実装基準が自分でできるようになります。
1. UI例（Preview / Live）
実装で見る（GunjoUI）
この部品を、デザインシステム GUNJO の実装で確かめられます。
2. 定義（Definition）
アプリケーション上部に横並びで配置されるトップレベルのメニュー群。各メニュー項目をクリックするとドロップダウン（プルダウン）が展開し、関連するコマンドやサブメニューを表示する。macOS / Windows のデスクトップアプリのメニューバーをWebに移植したパターン。
Top nav との違い：Top nav はページ間のナビゲーションに使う。Menubar はアプリ内コマンド（ファイル操作・編集・表示切替など）の実行に使う。リンクではなくアクションのランチャー。
ContextMenu との違い：ContextMenu は右クリックで出現するコンテキスト依存のメニュー。Menubar は常時表示されており、全コマンドを網羅する。
3. 使い分け（When to use / When NOT to use）
3.1 When to use
- テキストエディタ・スプレッドシート・IDEなど、コマンド数が多いプロダクティビティアプリ
- ユーザーがキーボードショートカットを活用するパワーユーザー向けアプリ
- macOS / Windows のネイティブアプリと操作感を揃えたいWebアプリ
3.2 When NOT to use
- 一般的なWebサイト・ECサイト → Top nav で十分
- モバイルアプリ → タップ操作に不向きで項目数も多すぎる
- コマンド数が少ない軽量アプリ → Toolbar / ContextMenu の方がシンプル
3.3 代替UI（Alternatives）
- ページ間ナビゲーション →
Top nav - コンテキスト依存のコマンド →
ContextMenu（右クリック） - よく使うコマンドのみ →
Toolbar（アイコンボタン群） - コマンド検索 →
Command Palette（⌘K でキーワード検索）
4. 設計判断の核（Decision Principles）
Menubar のメニュー項目はコマンドのカテゴリ——「何ができるか」の全体像を見せる地図であり、ナビゲーションリンクではない。
判断の優先順位：① コマンドのカテゴリ整理 → ② キーボードショートカットの表示 → ③ セパレータによるグループ化 → ④ チェック項目・ラジオ項目の状態表示
- キーボードショートカットは必ず表示する：メニュー項目の右端にショートカットを表示することで、ユーザーがキーボード操作を自然に習得できる
- セパレータで意味的グループを区切る：「新規・開く」「保存」「終了」のように意味のまとまりをセパレータで区切る
- 状態を持つ項目は
menuitemcheckbox/menuitemradio：「折り返し表示」のようなON/OFF項目はチェックマークで状態を示し、role="menuitemcheckbox"とaria-checkedを使う - サブメニューは最大1段まで：2段以上のネストは操作コストが高くなりすぎる。コマンドパレットへの誘導も検討する
5. 状態設計（States）
5.1 必須状態（Required）
- Default：メニューバーが閉じた状態。トップレベルのカテゴリ名のみ表示
- Open：トップレベル項目がクリックされドロップダウンが展開した状態
- Hover（item）：ドロップダウン内でカーソルが当たっている項目を強調
- Focus：キーボードでフォーカスされた項目にフォーカスリング表示
5.2 条件付き状態（Conditional）
- Checked（menuitemcheckbox）：ON/OFF のチェック項目がオンの状態。チェックマークを表示
- Radio selected（menuitemradio）：排他選択項目で選択されている状態
- Disabled：現在実行できないコマンド。薄いグレーで表示
5.3 State Gallery
| 状態 | 必須 | 何を伝えるか |
|---|---|---|
| Default | ✅ | 利用可能なコマンドカテゴリの全体像 |
| Open | ✅ | 選択中のカテゴリに属するコマンド一覧 |
| Hover | ✅ | このコマンドを実行できることを示す |
| Focus | ✅ | キーボードユーザーに今どの項目にいるかを示す |
| Checked | — | 設定・表示オプションのON状態を示す |
| Disabled | — | コンテキスト上実行できないコマンドを示す |
6. バリエーション設計（Variants）
Menubar のバリアントは「表示するコマンドの種類」と「ショートカット表示の有無」で決まる。
| バリアント | 目的 |
|---|---|
| Standard | ファイル・編集・表示などの標準カテゴリ構成 |
| With Checkboxes | 表示オプションなどON/OFFの切替を含むメニュー |
| With Submenus | カテゴリ内にサブカテゴリを持つ1段ネスト構成 |
| With Shortcuts | ショートカットキーを右端に表示するパターン（推奨） |
禁止パターン：メニュー内にページ遷移リンクを混在させる → MenubarはコマンドのランチャーでありナビゲーションのTop navと役割が混同する。
7. パターン集（Good / Bad / How to fix）
7.0 よく崩れる設計パターン（3つ）
- ショートカット非表示：ショートカットキーを表示しないため、ユーザーがメニュー操作のみに依存し生産性が向上しない
- カテゴリが多すぎる：トップレベルのメニューカテゴリが10個以上あり、どこに何があるか分からなくなる
- ARIA role の欠落：
<div>でMenubarを実装し、role="menubar"/role="menuitem"/aria-haspopupがなく、スクリーンリーダーに「ボタンの羅列」としか認識されない
7.1 Bad（典型3つ）
- ドロップダウン項目にショートカットキーが表示されず、マウス操作しか習得できない
- トップレベルに14カテゴリあり、目的のコマンドがどこにあるか探すのに時間がかかる
role="menu"/role="menuitem"なしで実装され、スクリーンリーダーユーザーが操作できない
7.2 Good（対になる3つ）
- 各メニュー項目の右端にショートカット（
⌘S・⌘Zなど）を表示し、学習を促進する - トップレベルのカテゴリを「ファイル・編集・表示・ヘルプ」の4〜6個に絞り、コマンドを適切に分類する
role="menubar"→role="menuitem" aria-haspopup="menu"→role="menu"→role="menuitem"の階層でARIAを正しく実装する
7.3 How to fix（手順）
- ショートカットキーを
<span>で右端に追加し、見た目をtext-gray-400など控えめなスタイルにする - カテゴリ数を6個以内に絞り、コマンドをグループごとにセパレータで区切る
role="menubar"でラップし、各トップレベルボタンにrole="menuitem" aria-haspopup="menu" aria-expandedを付与する- ドロップダウンに
role="menu"、各項目にrole="menuitem"を付与する
8. ルール（Must / Better）
Must（守らないと壊れる）
Better（品質が跳ねる）
9. アクセシビリティ要件（必須）
Keyboard
TabでMenubar全体にフォーカスできること←/→でトップレベルメニュー間を移動できること（WAI-ARIA Menubar Pattern）Enter/Space/↓でドロップダウンを開けること↑/↓でドロップダウン内の項目を移動できることEscapeでドロップダウンを閉じてトップレベルボタンにフォーカスを戻すこと
Focus
- フォーカスリングはMenubarの背景色と4.5:1以上のコントラストを持つこと
Screen Reader
role="menubar"+aria-labelでMenubar全体を識別させるaria-haspopup="menu"でサブメニューがあることを伝えるaria-expandedでドロップダウンの開閉状態を伝えるmenuitemcheckboxにはaria-checkedで状態を伝える
<!-- 基本パターン -->
<div role="menubar" aria-label="アプリケーションメニュー">
<button role="menuitem" aria-haspopup="menu" aria-expanded="false">
ファイル
</button>
<div role="menu">
<button role="menuitem">新規作成 <span>⌘N</span></button>
<div role="separator"></div>
<button role="menuitemcheckbox" aria-checked="true">折り返し表示</button>
</div>
</div>
Touch / Pointer
- モバイルではMenubarを使わず、別のナビゲーションパターン（Sheet・Bottom nav）に切り替えることを推奨
Contrast / Readability
- メニュー項目のテキストは背景色と4.5:1以上のコントラスト比を確保する
- Disabled項目は読み取り可能な程度のグレー（3:1以上）を維持する
10. 実装メモ（Implementation Notes）
- shadcn/ui の
Menubarコンポーネントは WAI-ARIA Menubar Pattern に準拠しており、キーボードナビゲーションも実装済み。新規プロジェクトでは積極的に活用する - Radix UI の
@radix-ui/react-menubarも同様に ARIA 対応済み - キーボードナビゲーションを自前実装する場合、
useRefでメニュー項目のDOMを管理し、onKeyDownでフォーカス移動ロジックを実装する。WAI-ARIA Authoring Practices の Menubar Pattern を参考にする
11. 関連リンク
- 関連するUIデザイン原則: ナビゲーション設計 (Navigation Design), 情報設計 (Information Architecture), アフォーダンス (Affordance)
- 用語集（定義）: ナビゲーション・ファティーグ (Navigation Fatigue), アフォーダンス (Affordance)
- 関連するUIコンポーネント（横）: Sidebar / Side nav（サイドバー）, Tabs（タブ）, Button（ボタン）
12. まとめ
Menubarの設計は「コマンドのカテゴリ分け」と「ショートカットの表示」の2点が品質を決めます。迷ったら 4. 設計判断の核 に戻り、カテゴリ数・ショートカット表示・role="menubar" の実装を確認してください。一般的なWebサイトにMenubarは不要——テキストエディタやスプレッドシートなどのコマンド数が多いプロダクティビティアプリに限定して使うことが、過剰な複雑さを避ける最善の設計判断です。
