UIXHERO

Right Rail(ライトレール)

コンテンツエリアの右側に配置する補助的なサイドカラム。関連リンク・広告・目次・ウィジェットなどを収容する設計・スティッキー配置・レスポンシブでの折り畳み・コンテンツとの優先順位付けを解説する。

2026年3月3日
更新: 2026年9月14日
約15分
by Dengen Yosho(DGYS)

メインコンテンツエリアの右側に配置する補助的なサイドカラム。関連リンク・目次(ToC)・タグ・著者情報・広告・おすすめコンテンツなどを収容する。Left Sidebar(用)と異なり、Right Rail はコンテンツに関連する補助情報の提供を目的とする。ブログ・ニュースサイト・ドキュメントサイト・ECサイトのサイドバーで広く使われる。

この記事を読むと、Right Rail に置くべき情報の優先順位・スティッキー配置の設計・レスポンシブでの折り畳みと再配置・Left Sidebar との使い分けが自分でできるようになります。


1. UI例(Preview / Live)

実装で見る(GunjoUI)

この部品を、デザインシステム GUNJO の実装で確かめられます。

2. 定義(Definition)

メインコンテンツエリアの右側に配置する補助的なサイドカラム(通常200〜320px幅)。メインコンテンツを補完する情報を収容し、ユーザーがスクロールしながらでも参照できる。

Left Sidebar vs Right Rail:

Left SidebarRight Rail
用途ナビゲーション・サイト構造補助情報・関連コンテンツ
重要度高(主要機能)低(補足)
コンテンツ例メニュー・フォルダツリー目次・タグ・関連記事・広告
モバイルドロワーとして維持折り畳みまたは下部移動

3. 使い分け(When to use / When NOT to use)

3.1 When to use

  • 記事・ブログページ:目次・タグ・著者情報・関連記事
  • ECサイトの商品詳細:フィルター・絞り込み・広告
  • ドキュメントサイト:ページ内目次・関連ドキュメント
  • ダッシュボード:アクティビティフィード・通知・ショートカット

3.2 When NOT to use

  • モバイルファーストの狭い画面:Right Rail はデスクトップ(1024px以上)向けに検討する
  • フォーム・入力画面:補助情報が入力の邪魔になる
  • シンプルなランディングページ:コンバージョンに集中すべき場面

4. 設計判断の核(Decision Principles)

Right Railの核は「補助であること」——メインコンテンツより目立ってはいけない。幅・色・フォントサイズすべてにおいてメインを引き立てる脇役として設計する。

判断の優先順位:① Right Railに置く情報の優先順位付け → ② スティッキー配置 → ③ 幅の → ④ レスポンシブでの再配置

  • Right Rail の幅はメインコンテンツの1/3以下にする:一般的な比率はメイン:レール = 2:1 または 3:1。Right Rail が広すぎるとメインコンテンツが狭くなり可読性が下がる
  • スティッキー配置でユーザーの視線を補助する:position: sticky; top: 20px; で目次やウィジェットを常に見えるようにする。ただし Right Rail の高さがビューポートより高い場合は overflow-y: auto と max-height: calc(100vh - 40px) を組み合わせる
  • 情報の優先順位を決める:Right Rail に何でも入れると散漫になる。目次・関連記事・タグを1〜2つに絞り、残りはコンテンツ末尾に移動する
  • モバイルでは Right Rail をコンテンツ下部に移動する:flex-col lg:flex-row でデスクトップのみ横並びにし、モバイルではメインコンテンツの後に Right Rail を配置する。重要な情報はコンテンツ内に組み込む

5. 状態設計(States)

状態表示
デスクトップ(≥1024px)右側に固定配置、スティッキー
タブレット(768〜1023px)非表示またはコンパクト化
モバイル(<768px)コンテンツ下部に移動または非表示
スクロール中(スティッキー時)画面上部に固定して常時表示

6. バリエーション設計(Variants)

バリアントコンテンツ使用場面
目次レールページ内アンカーリスト長文記事・ドキュメント
関連コンテンツレール関連記事・おすすめブログ・メディアサイト
アクティビティレール通知・最近の操作ダッシュボード・SaaS
フィルターレール絞り込み条件EC・検索結果
広告レールバナー・スポンサーメディアサイト

7. パターン集(Good / Bad / How to fix)

7.1 Bad(典型3つ)

  • Right Rail の幅が400pxあり、メインコンテンツが狭くなって読みにくい
  • モバイルで Right Rail がメインコンテンツの前に表示され、ユーザーがスクロールしないと本文にたどり着けない
  • <div class="right-rail"> でマークアップし、スクリーンリーダーが補助情報として認識できない

7.2 Good(対になる3つ)

  • grid-cols-[1fr_280px] でメインと Right Rail の比率を固定し、レスポンシブで grid-cols-1 に切り替える
  • flex-col lg:flex-row でモバイルは縦積み、デスクトップのみ横並びにして Right Rail を右側に配置する
  • <aside aria-label="関連情報"> でセマンティックにマークアップし、スクリーンリーダーが main から独立した補助領域として認識する

7.3 How to fix(手順)

  1. Right Rail の幅を max-width: 320px に制約する
  2. <aside aria-label="[補助情報の説明]"> で実装する
  3. position: sticky; top: 20px; max-height: calc(100vh - 40px); overflow-y: auto; でスティッキー配置を設定する
  4. flex flex-col lg:flex-row でモバイルはコンテンツ下部に Right Rail が来るように順序を制御する

8. ルール(Must / Better)

Must(守らないと壊れる)

Better(品質が跳ねる)


9. アクセシビリティ要件(必須)

Screen Reader

<div class="flex flex-col lg:flex-row">
  <main class="flex-1" aria-label="メインコンテンツ">
    <!-- 記事・本文 -->
  </main>

  <aside aria-label="補助情報" class="w-72 shrink-0">
    <!-- 目次・関連記事・タグ -->
  </aside>
</div>

<aside> は <main> とは独立した補助的なコンテンツ領域として認識される。aria-label で何の補助情報かを明示する。

Focus Order

Right Rail 内のリンクはキーボードのTab順序でメインコンテンツの後に来るように、DOMの順序はメイン→Right Railにする。CSSのFlexboxで見た目を制御しても、DOMの順序はアクセシブルな順序を維持する。


10. 実装メモ(Implementation Notes)

  • TailwindCSS での実装例:<div className="flex flex-col lg:flex-row gap-8"> → <main className="flex-1 min-w-0"> + <aside className="w-72 shrink-0 lg:sticky lg:top-8 lg:self-start">
  • lg:sticky と lg:self-start を組み合わせることで、デスクトップのみスティッキー配置になる(モバイルでは通常フローに従う)
  • Right Rail 内の目次(Table of Contents)の実装には、IntersectionObserver でスクロール位置に応じてアクティブな見出しをハイライトする実装が一般的

11. 関連リンク


12. まとめ

Right Railの設計で最重要なのは「補助であること」の徹底です。幅・情報量・視覚的強度すべてにおいてメインコンテンツを引き立てる脇役として設計してください。<aside> + aria-label のセマンティックな実装と、モバイルでのコンテンツ下部への再配置は必須実装です。スティッキー配置は目次など参照頻度の高い情報に限定的に使用し、Right Rail 全体をスティッキーにするとコンテンツが隠れるケースがあるため max-height を必ず設定してください。

更新のお知らせ

サイトに載せていない実例や、新しい記事のお知らせはこちらで出しています。

読んだ内容を、自分の画面に当てるとき

UIXHEROは、記事を書くほかに、画面の検品・判定、デザインシステムの構築、実装と改善の伴走を受けています。何を頼めばいいか決まっていない段階の相談も、同じ窓口で受けます。

UIXHEROに頼めることを見る

※ 記事の内容についての質問や、書いてほしいテーマの要望も同じ窓口で受けています

記事をシェア

メールでお知らせを受け取る

最終更新: 2026年9月14日

この記事を書いた人

Dengen Yosho(DGYS)

Dengen Yosho(DGYS)

UI/UXデザイナー兼デザインエンジニア デザイン歴25年以上 情報設計〜UIデザイン〜React/TypeScriptによる実装までを一気通貫で担当 大手企業のDXプロジェクトや決済アプリ領域で、デザインリードとして改善と構築を経験 現在はフリーランスとして、プロダクトのUI/UX改善とデザインシステム構築を支援 長年の実務の中で感じてきたのは、 「良いUI」はセンスではなく、再現可能な判断の積み重ねであるということ UIXHEROは、 心理学や行動科学の知見を、現場で使える設計言語に翻訳するための場所 関心領域は「ユーザーの行動が変わるUI」 人の認知・注意・意思決定の構造を理解し、 “なぜそのUIが機能するのか”を言語化することを目指している

あわせて読みたい

この記事に関連する記事をご紹介します

Day Band(いちにちの帯)

1日を1本の帯にして、時間帯を面で、節目を印で、いまの時刻とつまみを重ねて見せるUIコンポーネント。器が1日に固定されることの意味、4つの層の重ね方、印のラベルと時刻の数字を分ける理由、触った瞬間に動かさない理由を解説する。

2026年9月14日
約24分

Live Badge(LIVEの札)

隣の数字がいまの値かどうかを示す小さな札。状態を表す語を枠で囲って独立させる理由、明滅と色を補助に留める理由、実時間から外れたときに「古い」ではなく「いつの値か」を出す設計判断とARIA実装を解説する。

2026年9月14日
約21分

Time Transport(時間の操作盤)

いま映している時刻を、名前をつけた速さの段で動かし、決まった幅で飛ばし、ひと押しで「いま」へ戻すための操作盤。速さを連続値にしない理由、向きをアイコンに持たせる理由、状態を大きい表示の色で示さない理由を解説する。

2026年9月14日
約25分

もっと深く知りたいですか?

ここに掲載されていないトピックについても、リクエストがあれば解説記事を追加します。 わかりにくい点や、具体的な事例について知りたいことがあれば教えてください。

リクエストを送る