MAS-217: サイドバー項目を MENU_DEFINITION に統合 + 視認性改善

概要

目的

MAS-214 で GAS トップメニュー (🚀 BizLP / 💾 バックアップ) を Constants.MENU_DEFINITION に集約し、updateMenuCatalog_ で 00_menu タブへ自動展開する基盤が完成した。しかし運用上利用される操作の大半は サイドバー (templates/operations_sidebar.html) に存在しており、9 セクション・41 項目のボタンが MENU_DEFINITION 外でハードコードされたままになっている。本案件では次の 2 点を達成する。

1. カタログの完全性: サイドバーの 41 項目を MENU_DEFINITION に統合し、00_menu から運用上ほぼ全ての操作の利用状況を把握できるようにする
2. サイドバー視認性: 9 セクション・41+ ボタンが単色で並ぶ現状の探索負荷を、色分け・検索等で低減する

現状のコード

サイドバー現況 (templates/operations_sidebar.html)

9 セクション・41 ボタンの構成:

既存 CSS は 4 クラスのみ (btn / btn.primary / btn.warn / btn.danger) で、primary は「🤖 全RPA一括実行」「財務3表の更新」の 2 箇所、warn は孤立 TRN/重複行削除、danger は空行物理削除/本番データ同期で使われている。

MENU_DEFINITION 現況 (MAS-214 実装済)

Constants.MENU_DEFINITION には現在、GAS トップメニュー分 (🚀 BizLP 4 項目 + 💾 バックアップ 5 項目 + MAS-214 で追加された メニューカタログを更新 1 項目の 計 10 項目) のみが登録されている。サイドバー項目は一切含まれない。

修正方針

Step 1 — サイドバー項目の MENU_DEFINITION 追加

templates/operations_sidebar.html から全 41 項目を逐語抽出し、Constants.MENU_DEFINITION に追加セクションとして統合する。onOpen() のメニュー生成対象外 (サイドバー由来) の項目には category として「📋 サイドバー: <元セクション>」のプレフィックスを付けて区別する。

データ追加例 (000_infra/002_constants.js の MENU_DEFINITION 末尾に追記):

// --- サイドバー項目 (operations_sidebar.html 由来) ---
{
  category: '📋 サイドバー: 📒 経理業務',
  source: 'sidebar',
  items: [
    { label: '🤖 全RPA一括実行', funcName: 'generateAllRpaInvoices', description: '全 RPA モジュール (HC/SaaS/CAPEX/Finance/Adhoc/Pipeline) を一括起票' },
    { label: '📥 SaaS月次請求', funcName: 'generateSaasInvoices', description: 'SaaS 定期利用料の月次 INV を自動起票' },
    // ... (以下 9 項目)
  ]
},
// ... 他 8 セクション

全 41 項目の抽出結果 (逐語引用):

📒 経理業務 (RPA / Action) — 9 項目

🔍 消込・マッチング — 7 項目

📝 費用登録 — 1 項目

📊 マート更新 — 5 項目

⚙️ メンテナンス — 4 項目

🔧 開発・設定 — 7 項目

🔧 マイグレーション — 6 項目

🔄 開発用 (dev) — 1 項目 (dev 環境のみ)

🧪 テスト — 1 項目 (テストランナー有効時のみ)

条件付き項目の扱い: isDev / hasTestRunner の条件で表示切替される 2 セクションは、MENU_DEFINITION に項目オブジェクトの追加フィールド condition: 'isDev' / condition: 'hasTestRunner' を持たせる。updateMenuCatalog_ は全項目を展開するが、description 末尾の「(dev 環境限定)」等で運用者が認識できるようにする。サイドバー動的生成化 (後述の後続案件) でこの condition フィールドを実際の表示制御に使う。

Step 2 — サイドバー視認性改善 (HTML/CSS のみ)

9 セクション・41+ ボタンの探索負荷を低減するため、以下 5 案のうち採用案を組み合わせて適用する。

推奨組合せ: 1 + 2 を基本採用。工数低く視認性改善効果が大きい。4 (検索) は工数中だが効果大なので採用推奨。3 と 5 はユーザー選択依頼。

案 1 + 2 の CSS 実装例:

/* 案 1: セクション別の左ボーダー色 (h3 カテゴリと連動) */
.section[data-cat="rpa"]         .btn { border-left: 4px solid #34a853; }  /* 緑系 */
.section[data-cat="match"]       .btn { border-left: 4px solid #4285f4; }  /* 青系 */
.section[data-cat="regist"]      .btn { border-left: 4px solid #fbbc04; }  /* 黄系 */
.section[data-cat="mart"]        .btn { border-left: 4px solid #673ab7; }  /* 紫系 */
.section[data-cat="maintenance"] .btn { border-left: 4px solid #fb8c00; }  /* 橙系 */
.section[data-cat="devops"]      .btn { border-left: 4px solid #5f6368; }  /* 灰系 */
.section[data-cat="migration"]   .btn { border-left: 4px solid #9c27b0; }  /* 桃系 */
.section[data-cat="dev"]         .btn { border-left: 4px solid #ea4335; }  /* 赤系 */
.section[data-cat="test"]        .btn { border-left: 4px solid #00acc1; }  /* 水色 */

/* 案 2: 操作カテゴリ別の背景色 (読取/書込/破壊の 3 段階) */
.btn.read    { background: #f0f7ff; }  /* 薄青 = 読取系 (参照・一覧) */
.btn.write   { background: #ffffff; }  /* 白   = 書込系 (既存: 通常) */
.btn.destroy { background: #fdf2f2; border-color: #e57373; }  /* 薄赤 = 破壊的 */

HTML 側は各 <div class="section"> に data-cat="..." を追加し、必要な <button> に .read / .write / .destroy を追加する。

案 4 (検索ボックス) の実装例:

<input type="search" id="menuSearch" placeholder="🔍 メニュー検索..."
       style="width: 100%; padding: 6px; margin-bottom: 10px; border: 1px solid #d0d0d0; border-radius: 3px; font-size: 12px;">
<script>
  document.getElementById('menuSearch').addEventListener('input', function(e) {
    var q = e.target.value.toLowerCase();
    document.querySelectorAll('.btn').forEach(function(btn) {
      var hit = q === '' || btn.textContent.toLowerCase().indexOf(q) >= 0;
      btn.style.display = hit ? '' : 'none';
    });
    document.querySelectorAll('.section').forEach(function(sec) {
      var visibleBtns = sec.querySelectorAll('.btn:not([style*="display: none"])');
      sec.style.display = visibleBtns.length > 0 ? '' : 'none';
    });
  });
</script>

Step 3 — 動作確認

1. npm run push:dev で dev 環境にデプロイ
2. スプレッドシートをリロードし、サイドバー表示の回帰確認 (全 41 項目が表示、既存 primary/warn/danger のスタイルが保持、動作 (run 実行) が変わらないこと)
3. '💾 バックアップ → メニューカタログを更新' を実行し、00_menu にサイドバー 41 項目が追加されて表示されることを確認
4. 新 CSS の表示確認 (ボーダー色・背景色・検索挙動)
5. 98_audit_log にサンプル実行履歴がある状態で再実行し、サイドバー項目の実行回数・最終実行日時が正しく集計されることを確認

影響範囲

注意事項

1. サイドバー HTML ファイルは動的生成化しない: operations_sidebar.html を MENU_DEFINITION からレンダリングする案 (動的生成化) は本案件の対象外。別案件 (後続の N-XX) として切り出す。本案件では HTML と MENU_DEFINITION が二重管理になることを許容し、代わりに Step 3 の動作確認 2 でラベル・関数名の一致を目視確認する。
2. primary の拡張は Step 2 の案 3 に含める: 既存の primary 2 箇所を変更する場合はユーザー判断が必要。本案件のデフォルトでは既存 primary を維持。
3. 条件付き項目 (isDev / hasTestRunner) の MENU_DEFINITION 扱い: condition フィールドを持たせるが、updateMenuCatalog_ は無条件に全項目を展開する。description で環境条件を明記。
4. category 命名規則: GAS トップメニュー由来の既存カテゴリ (🚀 BizLP / 💾 バックアップ) と区別するため、サイドバー由来には「📋 サイドバー: 」プレフィックスを統一付与する。00_menu カタログ上でもこの prefix でグループ識別できる。
5. description 執筆のレビュー必須: 41 項目の description (20-50 字) は仕様書作成時点で逐語読解に基づくドラフト。実装前にユーザー (業務オーナー) が内容確認すること。機能ごとの精度差があり得る。

エッジケース

関連ドキュメント

• dev_mas-214_menu_catalog.md — 前提案件。MENU_DEFINITION 設計・updateMenuCatalog_ 実装
• docs/_internal/failure_patterns.md #20 — 固有名詞 (関数名・ラベル) の造語禁止
• docs/_internal/TODO_future.md — MAS-214 / MAS-217 案件情報

人間が検討すべき事項

1. description 41 項目の内容レビュー: 仕様書のドラフト description はコード逐語読解ベース。業務オーナー (代表者) が運用目線で全項目の description を確認し、実装前に調整すること。特に「📥 単発経費」「📥 パイプライン受注」「プロジェクト別 採算」「タブ名一括変更」等は誤解の余地がある。
2. Step 2 視認性改善の採用案選択: 5 案のうち採用するものを選ぶ (推奨: 1 + 2 + 4、オプション: 3 / 5)。採用範囲で工数・実装難度が変わる。
3. 左ボーダー色のカラーパレット決定: 案 1 の CSS 例は暫定色。既存 Constants.COLORS との整合、ブランドカラー適合は要レビュー。
4. 検索ボックスの a11y 要件: 案 4 採用時、スクリーンリーダー対応 (aria-label 付与) やキーボードフォーカス制御が必要か判断。個人利用範囲なら省略可。
5. 条件付き項目 (dev / テスト) の MENU_DEFINITION 扱い: condition フィールド方式で良いか、別の表現方式 (例: category 自体に dev-only suffix) で良いか要決定。
6. サイドバー動的生成化 (後続案件 候補): 本案件完了後、operations_sidebar.html を MENU_DEFINITION から動的レンダリングする案件を別起票するか判断。PR #230 の動的化 C 案と合流する。
7. 📋 サイドバー: プレフィックスの妥当性: 00_menu カタログ上で GAS トップメニュー由来とサイドバー由来を区別する命名が必要か、別手段 (source 列の追加等) で良いかを検討。
8. description 重複ロジック: 同一 funcName が GAS メニューとサイドバー両方に登録された場合 (例: 将来メニュー重複があり得る)、00_menu でどう表示するか要検討 (現状は重複定義を禁止する前提)。

実装プロンプト（Claude Code 用）

あなたはGAS会計システムのシニア開発者です。
案件 MAS-217「サイドバー項目を MENU_DEFINITION に統合 + 視認性改善」を実装してください。

## 実行前タスク
1. `templates/operations_sidebar.html` を Read し、9 セクション・41 項目の label / onclick 関数名を逐語確認する (行 32〜111)。推測・記憶で書くことは禁止 (失敗パターン #20)。
2. `000_infra/002_constants.js` の `Constants.MENU_DEFINITION` 現況 (MAS-214 で追加済) を Read し、既存のオブジェクト構造・末尾位置を確認する。
3. `100_config/101_sys_config.js` の `updateMenuCatalog_` (MAS-214 実装) を Read し、`condition` フィールドに対する挙動を確認する (本案件では無条件展開で良い)。
4. `docs/dev/dev_mas-217_sidebar_catalog_and_readability.md` を Read し、41 項目の description ドラフトと視認性改善の採用案をユーザー選択結果として受け取る。
5. `docs/_internal/failure_patterns.md` #20 を確認し、ラベル・関数名の逐語引用ルールを守る。

## 修正対象ファイル
- `000_infra/002_constants.js`: `Constants.MENU_DEFINITION` 末尾にサイドバー由来 9 セクション・41 項目を追加。既存項目は一切変更禁止。
- `templates/operations_sidebar.html`: (Step 2 採用案に応じて) CSS クラス追加、`<div class="section">` に `data-cat` 属性付与、該当 `<button>` に `.read` / `.write` / `.destroy` 付与、検索ボックス HTML/JS 追加。既存 `primary/warn/danger` 付与箇所および onclick 関数名は一切変更禁止。
- `100_config/101_sys_config.js`: 変更不要。

## 実装内容
- Step 1: `Constants.MENU_DEFINITION` への 9 セクション・41 項目追加
  - 配置: 既存の最後のセクション (MAS-214 で追加された `💾 バックアップ` の次) の直後に追加
  - 各セクション: `{ category: '📋 サイドバー: <元セクション絵文字付き名>', source: 'sidebar', items: [...] }`
  - 各項目: `{ label, funcName, description }` (description は仕様書 §修正方針 Step 1 の表から逐語コピー)
  - 条件付き項目 (`syncProdToDev` / `runAllTests`) には `condition: 'isDev'` / `condition: 'hasTestRunner'` を追加
- Step 2: サイドバー視認性改善
  - 採用案 (ユーザー選択結果): [ ユーザー指示に従う。仕様書推奨は 1 + 2 + 4 ]
  - 案 1: 各 `<div class="section">` に `data-cat="rpa|match|regist|mart|maintenance|devops|migration|dev|test"` を付与。CSS ルール追加
  - 案 2: 該当 `<button>` に `.read` / `.write` / `.destroy` を追加。CSS ルール追加
  - 案 4: 検索ボックス HTML (`<input type="search" id="menuSearch">`) を `<h2>` 直後に追加。JS フィルタリングロジック追加
- Step 3: 動作確認
  - `npm run push:dev` でデプロイ
  - サイドバー目視確認 (全項目表示・既存スタイル維持・動作回帰なし)
  - `updateMenuCatalog_` 実行 → `00_menu` に 41 項目追加確認
  - CSS 適用確認 (ボーダー色・背景色・検索)

## 制約
- ラベル文字列・関数名は `templates/operations_sidebar.html` からの逐語引用のみ使用。造語・推測禁止 (失敗パターン #20)。
- CSS クラス付与は段階適用可 (全ボタンに付ける必要はない)。
- `onclick` 属性の関数名を変更しない。
- 既存 `primary/warn/danger` の付与箇所を変更しない。
- 条件付きセクション (`<? if (isDev) { ?>` / `<? if (hasTestRunner) { ?>`) の HTML 構造は維持。

## エッジケース
- サイドバーの条件付き項目は `MENU_DEFINITION` に無条件追加 (`condition` フィールドで区別)
- `98_audit_log` データゼロ → 実行回数 0 / 最終実行日時 `-` で `00_menu` 表示
- `operations_sidebar.html` と `MENU_DEFINITION` の二重管理は許容 (動的生成化は別案件)
- `data-cat` / `.read|.write|.destroy` 未付与ボタン → 既存スタイル維持
- 検索ヒット 0 件 → 全 btn / section が hidden

## 動作確認
1. `npm run push:dev` でデプロイする
2. スプレッドシートをリロードし、サイドバーの 41 項目が既存の表示・動作と変わらず出ることを確認 (回帰チェック)
3. `'💾 バックアップ → メニューカタログを更新'` を実行し、`00_menu` にサイドバー由来 41 項目が「📋 サイドバー: 」プレフィックスで新規追加されていることを確認
4. CSS 改善 (ボーダー色・背景色・検索ボックス) が採用案通りに適用されていることを目視確認
5. 検索ボックスに「領収書」と入力し、該当ボタンのみが表示されることを確認
6. `98_audit_log` にサンプル履歴がある状態で再度 `updateMenuCatalog_` を実行し、サイドバー項目の実行回数・最終実行日時が正しく集計されることを確認

### 拡張思考の使用状況
| フェーズ | 拡張思考 | 備考 |
|---------|---------|------|
| 実行前タスク (Read・description 内容確認) | あり | label / funcName の逐語引用、description の業務妥当性レビュー |
| 実装 (コード書き下し) | なし | 確定済み内容の清書に徹する |

推奨実行モデル

変更履歴