# ナビゲーション再編仕様書 > 作成日: 2026-04-07 > 対象: `frontend/src/components/Navbar.tsx` > 方針: 第一候補「上段5分類 + ドロップダウン」 --- ## 0. 背景 現状のグローバルナビゲーションは、機能追加のたびに横並びのボタンを増やしており、以下の問題が出ている。 - 上位階層の導線が多すぎて、目的の画面を探しにくい - 「計画」「実績」「設定」「補助機能」が同じ粒度で並んでいる - メール関連のように、単独トップに置くほどではない機能が場所を取りやすい - 今後も機能追加が続くと、横幅不足と認知負荷の両方が悪化する このため、トップナビは「日常的に使う業務カテゴリ」だけを見せ、個別画面はドロップダウン配下へ整理する。 --- ## 1. 目的 ### 1-1. 目指す状態 - 1階層目では「何をしたいか」で探せる - 似た役割の画面を同じカテゴリに集約する - 画面数が増えても、トップレベルの見た目を増やしすぎない - PC とスマホで同じ情報設計を維持する ### 1-2. 今回の対象 - 共通ヘッダー内のグローバルナビゲーション再編 - メニュー分類、ラベル、並び順、開閉仕様の定義 - 各画面がどのカテゴリに属するかの明確化 ### 1-3. 今回やらないこと - 各業務画面そのものの UI 改修 - 権限別メニュー出し分け - お気に入り機能、ピン留め機能 - ナビゲーションと連動したダッシュボード内容の刷新 --- ## 2. 基本方針 ### 2-1. トップレベル構成 トップナビでは以下の 5 項目のみを常時表示する。 1. ホーム 2. 計画 3. 実績 4. 資材・帳票 5. その他 右端には従来どおりユーザー操作を置く。 - パスワード変更 - ログアウト ### 2-2. 設計ルール - 毎日使う業務カテゴリだけをトップに置く - 個別機能名ではなく、業務単位で束ねる - 設定、履歴、通知、補助系は単独トップにしない - 同じ業務の前後工程は可能な限り同じカテゴリに寄せる --- ## 3. 情報設計 ### 3-1. カテゴリ構成 #### ホーム - ダッシュボード #### 計画 - 作付け計画 - 施肥計画 - 田植え計画 - 運搬計画 #### 実績 - 散布実績 - 畔塗記録 - 作業記録 #### 資材・帳票 - 圃場管理 - 在庫管理 - 帳票出力 - データ取込 #### その他 - 気象 - メール - 設定 ### 3-2. メールの扱い メール関連はトップ階層に個別表示しない。 `その他 > メール` の中にまとめる。 内訳: - メール履歴 - メールルール ### 3-3. 設定の扱い 現状はパスワード変更のみだが、将来の設定追加を見越して `その他 > 設定` という置き方を前提にする。 ただし初期実装では、右上アイコンからのパスワード変更導線は維持してよい。 --- ## 4. 画面とメニューの対応 ### 4-1. 現在の主要画面の所属 | カテゴリ | ラベル | パス | |---|---|---| | ホーム | ダッシュボード | `/dashboard` | | 計画 | 作付け計画 | `/allocation` | | 計画 | 施肥計画 | `/fertilizer` | | 計画 | 田植え計画 | `/rice-transplant` | | 計画 | 運搬計画 | `/distribution` | | 実績 | 散布実績 | `/fertilizer/spreading` | | 実績 | 畔塗記録 | `/levee-work` | | 実績 | 作業記録 | `/workrecords` | | 資材・帳票 | 圃場管理 | `/fields` | | 資材・帳票 | 在庫管理 | `/materials` | | 資材・帳票 | 帳票出力 | `/reports` | | 資材・帳票 | データ取込 | `/import` | | その他 | 気象 | `/weather` | | その他 > メール | メール履歴 | `/mail/history` | | その他 > メール | メールルール | `/mail/rules` | | その他 > 設定 | パスワード変更 | `/settings/password` | ### 4-2. アクティブ表示ルール - その画面自身、またはその配下詳細画面にいる場合、所属カテゴリをアクティブにする - ドロップダウン内の該当項目も個別にアクティブ表示する - パス接頭辞だけで判定するとカテゴリが衝突する画面があるため、より具体的なパスを優先して判定する - 特に `施肥計画` と `散布実績` はともに `/fertilizer` 配下を使うため、`/fertilizer/spreading` を先に判定し、`計画` 側から明示的に除外する - 例: - `/fertilizer` は `計画` をアクティブ - `/fertilizer/new` は `計画` をアクティブ - `/fertilizer/[id]` および `/fertilizer/[id]/edit` は `計画` をアクティブ - `/fertilizer/spreading` は `実績` をアクティブ - `/fertilizer/spreading?...` も `実績` をアクティブ - 例: - `/fields/123` の場合は `資材・帳票` がアクティブ - `/fertilizer/10/edit` の場合は `計画` がアクティブ - `/mail/history` の場合は `その他` と `メール履歴` がアクティブ --- ## 5. PC 表示仕様 ### 5-1. レイアウト PC ではヘッダーを 3 ブロック構成とする。 1. 左: ブランド名 `KeinaSystem` 2. 中央: トップメニュー 5 項目 3. 右: パスワード変更、ログアウト ### 5-2. トップメニューの見せ方 - `ホーム` は単独リンク - `計画` `実績` `資材・帳票` `その他` はドロップダウン付きメニュー - ラベルの横に開閉アイコンを表示する - 開いたメニューは白背景のパネルとして表示する ### 5-3. 開閉ルール - クリックで開閉 - 開いている他メニューがある場合は、それを閉じてから新しいメニューを開く - メニュー外クリックで閉じる - `Esc` キーで閉じる - 項目クリック後は遷移して閉じる ### 5-4. ドロップダウンの表示内容 各項目は以下の順で並べる。 #### 計画 1. 作付け計画 2. 施肥計画 3. 田植え計画 4. 運搬計画 #### 実績 1. 散布実績 2. 畔塗記録 3. 作業記録 #### 資材・帳票 1. 圃場管理 2. 在庫管理 3. 帳票出力 4. データ取込 #### その他 1. 気象 2. メール 3. 設定 `メール` と `設定` は 2 段構造にする方法と、直接展開せず一覧モーダル風に見せる方法があるが、初期実装ではシンプルさを優先し、`その他` ドロップダウン内に個別リンクを直接置く。 初期実装の並び: 1. 気象 2. メール履歴 3. メールルール 4. パスワード変更 なお情報設計上の名称としては `メール` `設定` を維持し、将来的に機能が増えた時点で再度サブグループ化する。 --- ## 6. スマホ表示仕様 ### 6-1. 基本方針 スマホではハンバーガーメニューを採用する。 PC と同じカテゴリ構成を維持し、見た目だけ縦並びにする。 ### 6-2. 表示ルール - 初期状態ではロゴ、メニューボタン、ログアウト系導線のみ表示 - メニューボタン押下で全画面または右スライドのメニューを開く - カテゴリはアコーディオン形式で開閉する ### 6-3. 並び順 1. ホーム 2. 計画 3. 実績 4. 資材・帳票 5. その他 6. パスワード変更 7. ログアウト ### 6-4. 開閉ルール - カテゴリ見出しタップで開閉 - 現在表示中の画面が属するカテゴリは初期状態で展開してよい - 項目タップ後はメニューを閉じて画面遷移する --- ## 7. ラベル方針 ### 7-1. トップ階層ラベル - 短く、役割が伝わる言葉を使う - 詳細機能名は 2 階層目へ寄せる ### 7-2. 用語ルール - `ホーム` は利用者に最も分かりやすいため維持 - `計画` は作付け、施肥、田植え、運搬を含む包括名として使用 - `実績` は記録系業務のまとめ先とする - `資材・帳票` はやや広いが、現状機能数とのバランスを優先 - `その他` は補助機能置き場として扱う 将来 `その他` に機能が増えすぎた場合は、次の再編を検討する。 - `連携` - `設定` - `通知` --- ## 8. アイコン方針 ### 8-1. トップ階層 トップ階層には必要最低限のアイコンのみ使用する。 - ホーム: 家またはダッシュボード系 - 計画: 作物または計画系 - 実績: チェック、記録系 - 資材・帳票: 箱またはファイル系 - その他: 省略記号または設定系 ただし、文字認識を優先し、アイコンは補助扱いとする。 ### 8-2. ドロップダウン内 現行アイコンを流用してよいが、すべてに付ける必要はない。 視認性よりも一覧性を優先し、テキスト中心でも可。 --- ## 9. 操作性・アクセシビリティ要件 - キーボードでトップメニューにフォーカス移動できること - `Enter` または `Space` でドロップダウンを開閉できること - `Esc` で閉じられること - 現在位置が視覚的に分かること - タップ領域は十分に確保すること - スマホで誤タップしにくい行間と余白を確保すること --- ## 10. 実装方針 ### 10-1. コンポーネント構成案 `Navbar.tsx` を以下の責務に分ける。 - ブランド表示 - トップメニュー定義 - ドロップダウン表示 - モバイルメニュー表示 - 右端ユーザー操作 必要に応じて次のような補助構成へ分割してよい。 - `navGroups` 定数 - `DesktopNav` - `MobileNav` ### 10-2. メニュー定義データ化 個別ボタンの直書きはやめ、カテゴリ配列で管理する。 想定イメージ: ```ts const navGroups = [ { key: 'home', label: 'ホーム', type: 'link', href: '/dashboard', }, { key: 'planning', label: '計画', type: 'group', items: [ { label: '作付け計画', href: '/allocation' }, { label: '施肥計画', href: '/fertilizer' }, { label: '田植え計画', href: '/rice-transplant' }, { label: '運搬計画', href: '/distribution' }, ], }, ]; ``` ### 10-3. アクティブ判定 アクティブ判定は、現在の `pathname` と各項目の対応パターンで管理する。 例: - `/fertilizer` - `/fertilizer/new` - `/fertilizer/[id]/edit` はすべて `施肥計画` 所属として扱う。 --- ## 11. 段階導入案 ### Phase 1 - PC ナビを 5 分類へ再編 - `その他` は単純なリンク群として実装 - モバイルも同じ情報設計へ変更 ### Phase 2 - `その他` 内を `メール` `設定` にサブグループ化 - よく使う画面の履歴や最近使った機能を補助表示 ### Phase 3 - 将来マルチユーザー化した場合の再設計検討 - 権限や担当業務ごとの表示最適化の要否整理 - 単独利用を前提とする間は、Phase 3 は実施対象外とする --- ## 12. 受け入れ条件 - トップレベルに常時表示される業務メニューが 5 項目に収まっていること - 現在存在する主要画面が、いずれかのカテゴリに漏れなく所属していること - 各画面でアクティブ状態が期待通りに表示されること - PC とスマホで同じカテゴリ構成になっていること - メニューが増えても、トップレベルの項目数を増やさずに拡張できること --- ## 13. 想定される懸念と対応 ### 13-1. 「資材・帳票」が少し広すぎる 現時点では機能数のバランスを優先し、この分類を採用する。 今後、帳票やマスタ管理が増えた場合は `資材` と `帳票・管理` に再分割する。 補足: - `圃場管理` は本来、圃場マスタとして独立性の高い機能であり、`資材` と完全に同質ではない - ただし現時点では、単独トップにするほどの件数ではなく、`資材・帳票` にまとめるのが最も全体バランスが良い - 将来、圃場関連の設定や地図系機能が増えた場合は、`圃場・マスタ` のような独立カテゴリ化を再検討する ### 13-2. 「その他」が曖昧 現時点では補助機能数が少ないため許容する。 メール、設定、外部連携系が増えた段階で再分割を検討する。 ### 13-3. 「データ取込」は日常操作ではない `データ取込` は日常的に何度も使う画面ではなく、年度切替時や初期設定時に使う補助導線である。 そのためトップレベル常設には置かず、`資材・帳票` 配下に置く判断は妥当とする。 ただし今後、取込対象や運用頻度が増えた場合は、`設定` または `運用` 系カテゴリへの移設も検討対象とする。 ### 13-4. 既存ユーザーが場所を見失う 初期導入時は以下を行う。 - 並び順をできるだけ業務の流れに合わせる - ドロップダウン内で既存画面名は変更しない - ダッシュボード上に主要導線を残す --- ## 14. 結論 現行の 1 画面 1 ボタン方式は、今後の機能追加に対して拡張性が低い。 そのため、トップナビは `ホーム / 計画 / 実績 / 資材・帳票 / その他` の 5 分類へ再編し、個別画面はドロップダウン配下に置く。 この構成により、利用者は「画面名」ではなく「やりたい業務」から機能を探せるようになり、将来の機能追加にも耐えやすくなる。