# マスタードキュメント：ナビゲーション再編

> **作成**: 2026-04-07
> **最終更新**: 2026-04-07
> **対象機能**: グローバルナビゲーション再編（トップメニュー整理・カテゴリ再編・PC/スマホ共通情報設計）
> **実装状況**: 仕様策定完了・未実装

---

## 概要

機能追加に伴って共通ナビゲーションのトップレベル項目が増え、画面名ベースで並ぶ構造になってきたため、業務カテゴリ単位で再整理する。

今回の再編では、トップナビを `ホーム / 計画 / 実績 / マスター / 帳票・連携` の 5 分類に絞り、個別画面はドロップダウン配下に集約する。
これにより、利用者が「どの画面名か」ではなく「何をしたいか」で画面を探せる状態を目指す。

また、URL 構造とメニュー構成は意図的に分離して扱う。既存 URL は安定性を優先して原則維持し、アクティブ判定はナビ定義側で吸収する。

### 機能スコープ（IN / OUT）

| IN（今回対象） | OUT（今回対象外） |
|---|---|
| PC ヘッダーのトップメニュー再編 | 各業務画面自体のUI改修 |
| スマホ用ハンバーガーメニュー再編 | 権限別メニュー出し分け |
| メニュー分類、並び順、開閉仕様 | お気に入り、ピン留め |
| アクティブ判定ルール整理 | ダッシュボード内容の刷新 |
| `NavGroup` / `NavItem` ベースのメニュー定義整理 | URL の全面変更 |
| `作物` `品種` を将来のマスター画面として位置づけ | 矢印キー移動を含む高度なメニューアクセシビリティ |

---

## 背景と判断理由

### 現状の課題

- 横並びのトップメニュー数が多く、目的の画面を探しにくい
- `計画` `実績` `設定` `補助機能` が同じ粒度で並んでいる
- 画面名ベースで項目が増えており、業務単位でまとまっていない
- 今後も機能追加が続くと、視認性と拡張性の両方が悪化する

### 採用した考え方

1. トップレベルは日常的に使う業務カテゴリだけに絞る
2. 個別機能名ではなく、業務単位で束ねる
3. URL はリソース識別子として安定性を優先し、メニュー構成とは分離する
4. 例外的な URL 衝突のみナビ定義側のルールで吸収する

### 関連議論

- 判断理由、論点の切り分け、URL とメニューの関係整理は Gitea Issue `#13` に残す
- 実装向けの決定事項は `改善案/ナビゲーション再編仕様書.md` に集約する
- 本ドキュメントは、その内容を長期参照用に固定化したものとして扱う

---

## 情報設計

### トップレベル構成

1. ホーム
2. 計画
3. 実績
4. マスター
5. 帳票・連携

右上ユーザー操作:

- パスワード変更
- ログアウト

### カテゴリ構成

#### ホーム

- ダッシュボード

#### 計画

- 作付け計画
- 施肥計画
- 田植え計画
- 運搬計画

#### 実績

- 散布実績
- 畔塗記録
- 作業記録

#### マスター

- 圃場管理
- 作物
- 品種
- 資材マスタ
- 肥料マスタ

#### 帳票・連携

- 在庫管理
- 帳票出力
- データ取込
- 気象
- メール

### この分類にした理由

#### マスター

- `圃場管理` は圃場マスタとして独立性が高い
- `作物` `品種` も本来マスター管理である
- `資材マスタ` `肥料マスタ` はすでに独立画面が存在する

そのため、基礎データ管理を `マスター` に集約する。

#### 帳票・連携

- `在庫管理` `帳票出力` `データ取込` `気象` `メール` は完全に同質ではない
- ただし、いずれも主作業そのものではなく、補助・参照・出力・連携の性質が強い

そのため、トップ階層を増やしすぎないための受け皿として `帳票・連携` にまとめる。

補足:

- `データ取込` は日常操作ではなく、年度切替時や初期設定時の補助導線とみなす
- `メール` は個別トップにしない
- `設定` は現状パスワード変更のみなので、右上ユーザー操作に残す

---

## 画面と所属カテゴリ

| カテゴリ | ラベル | パス |
|---|---|---|
| ホーム | ダッシュボード | `/dashboard` |
| 計画 | 作付け計画 | `/allocation` |
| 計画 | 施肥計画 | `/fertilizer` |
| 計画 | 田植え計画 | `/rice-transplant` |
| 計画 | 運搬計画 | `/distribution` |
| 実績 | 散布実績 | `/fertilizer/spreading` |
| 実績 | 畔塗記録 | `/levee-work` |
| 実績 | 作業記録 | `/workrecords` |
| マスター | 圃場管理 | `/fields` |
| マスター | 作物 | 未実装（allocation 内管理を独立予定） |
| マスター | 品種 | 未実装（allocation 内管理を独立予定） |
| マスター | 資材マスタ | `/materials/masters` |
| マスター | 肥料マスタ | `/fertilizer/masters` |
| 帳票・連携 | 在庫管理 | `/materials` |
| 帳票・連携 | 帳票出力 | `/reports` |
| 帳票・連携 | データ取込 | `/import` |
| 帳票・連携 | 気象 | `/weather` |
| 帳票・連携 > メール | メール履歴 | `/mail/history` |
| 帳票・連携 > メール | メールルール | `/mail/rules` |
| 右上ユーザー操作 | パスワード変更 | `/settings/password` |

---

## URL とナビゲーションの関係

### 基本原則

1. URL はリソース・機能識別子として安定性を優先する
2. メニュー構成とは意図的に分離して扱う
3. メニュー再編のたびに URL を変更しない
4. アクティブ判定はナビ定義側のルールで吸収する

### 採用理由

- URL をメニュー階層に合わせて変更すると、既存リンク、ブックマーク、テストへの影響が大きい
- メニュー構成は将来も変わりうるため、URL にメニュー階層を埋め込むと変更コストが増える

### 衝突する既存パス

| 優先判定するパス | 所属カテゴリ | 除外される側 |
|---|---|---|
| `/fertilizer/spreading` | 実績 | 計画 > 施肥計画 |
| `/materials/masters` | マスター | 帳票・連携 > 在庫管理 |

通常判定:

- `/fertilizer` `/fertilizer/new` `/fertilizer/[id]/edit` は `施肥計画`
- `/materials` `/materials?tab=...` は `在庫管理`

---

## 表示仕様

### PC

- 左: ブランド名 `KeinaSystem`
- 中央: トップメニュー 5 項目
- 右: パスワード変更、ログアウト

表示ルール:

- `ホーム` は単独リンク
- `計画` `実績` `マスター` `帳票・連携` はドロップダウン
- 開いているメニューがある状態で別メニューを開く場合は、前のメニューを閉じる
- メニュー外クリック、`Esc` キーで閉じる
- 項目選択後は遷移して閉じる

### スマホ

- ハンバーガーメニューを採用する
- `ホーム` は単独リンクで `/dashboard` へ遷移する
- それ以外のカテゴリはアコーディオン形式で開閉する
- 現在表示中の画面が属するカテゴリは初期状態で展開してよい
- 項目タップ後はメニューを閉じて画面遷移する

---

## アクセシビリティ方針

- トップメニューへキーボードでフォーカス移動できること
- `Enter` または `Space` でドロップダウンを開閉できること
- ドロップダウン展開後、各項目へ `Tab` で到達できること
- `Esc` で閉じられること
- 現在位置が視覚的に分かること

### 初期実装でやらないこと

- 矢印キーによるドロップダウン項目間移動

これは Phase 1 の必須要件には含めず、将来のアクセシビリティ強化項目として扱う。

---

## 実装方針

### メニュー定義

メニュー定義はフラットな `group` 管理ではなく、階層構造で持つ。

```ts
type NavItem = {
  label: string;
  href: string;
  match?: (pathname: string) => boolean;
};

type NavGroup = {
  key: string;
  label: string;
  type: 'link' | 'group';
  href?: string;
  items?: NavItem[];
};
```

方針:

- グループ構成そのものが定義から読み取れることを優先する
- 通常ケースは `href` ベースで扱う
- `href` ベースで判定しきれない例外ケースだけ `match` を持つ
- `match` は全件定義用ではなく、衝突回避用の最小限の逃げ道として使う

### Next.js App Router との関係

- Route Groups は、URL を変えずにコード構造を整理する手段として有効
- ただし Route Groups はナビ判定そのものの代替ではなく、実装整理の補助手段として扱う

---

## 段階導入

### Phase 1

- トップナビを 5 分類へ再編する
- `マスター` 配下に表示するのは `圃場管理` `資材マスタ` `肥料マスタ` のみ
- `作物` `品種` はマスター体系には含めるが、独立画面がまだないため Phase 1 ではメニューに表示しない
- PC / スマホともに同じ情報設計にそろえる

### Phase 2

- `作物管理` `品種管理` を独立画面として追加
- `帳票・連携` 内の `メール` を必要に応じてサブグループ化

### Phase 3

- 将来マルチユーザー化した場合のみ再検討
- 単独利用前提の間は実施対象外

---

## 受け入れ条件

- トップレベルに常時表示される業務メニューが 5 項目に収まっていること
- 現在存在する主要画面が、いずれかのカテゴリに漏れなく所属していること
- 各画面でアクティブ状態が期待通りに表示されること
- PC とスマホで同じカテゴリ構成になっていること
- メニューが増えても、トップレベルの項目数を増やさずに拡張できること

---

## 参照

- 議論の背景・判断理由: Gitea Issue `#13 メニューがごちゃごちゃしてきたので、整理する`
- 実装向け詳細仕様: `改善案/ナビゲーション再編仕様書.md`