全案件マスタテーブル (統合版 / SSoT) | BizLinkPartners 社内ドキュメント

📌 本ドキュメントの位置付け: bizlp 管理会計システム (MAS) の全 215+ 案件 (MAS-XXX) をカテゴリ別・パイプライン別・SaaS 化展開別に整理したマスタテーブル。各案件の優先度・ステータス・概要・価値・検討事項を網羅。

2026-04-30 移動: 本ドキュメントは元々 docs/_internal/TODO_future.md §3 に記載されていたが、TODO_future.md (999 行) の構造改革 Phase 2 として独立移動 (PR #420)。

関連ドキュメント:

追加開発案件 (TODO_future.md) — 概観・サマリー・ロードマップ・ギャップ分析・Out of Scope

登録→消込パターンカタログ (spec_payment_flow_patterns.md) — Phase 1 で切出し済の関連付録

ID マッピング表 (id_mapping_table.csv) — 旧 ID (F-/S-/I-/N-/G-/DS-/X-/BUG-/RQ-) と新 MAS- prefix の対応

本システムで計画する全案件を 3 つのサブセクションに統合。各テーブルは案件の SSoT（Single Source of Truth） として機能し、ステータス・優先度・仕様書リンクを一元管理する。

🚀 3.1 カテゴリ別マスタテーブル（統合 SSoT）

2026-04-29 再編: 旧 §3.1 短期改善 / §3.2 中長期 FP&A / §3.3 NFR を カテゴリ別に統合。15 バケット + その他/対象外で全 215 件を整理。自動入力パイプライン (§3.2) と SaaS 化展開 (§3.3) は narrative 構造を保持するため別セクション化。

slice_id 列の自動同期 (ADR-0026): 本ファイルの slice_id 列 (将来追加) は docs/_internal/usecase_dev_mapping.md (UC 軸 SSoT) を起点として GitHub Actions が自動同期する。同期メカニズム: .github/workflows/sync_slice_id.yml / 同 scripts/sync_slice_id.mjs。命名規則 (ADR-0025): slice_id 形式 UC-{N}-S{NN} (例: UC-4-S01) など。詳細は usecase_dev_mapping.md §2 命名規則。 本ファイルの slice_id 列は手動編集禁止 (自動上書き対象)。SSoT 側 (usecase_dev_mapping.md) を編集すること。

バケット別件数サマリー

カテゴリ	件数	主な領域
💰 経費・仕訳・会計	12	(詳細は下記サブセクション参照)
📈 パイプライン・売上計画	8	(詳細は下記サブセクション参照)
📊 データマート・財務諸表	6	(詳細は下記サブセクション参照)
📥 データ取込・自動化	5	(詳細は下記サブセクション参照)
🔄 データ整合性・再同期	4	(詳細は下記サブセクション参照)
🗂️ DDL・マスタ	9	(詳細は下記サブセクション参照)
🧮 PJ別損益・原価計算	3	(詳細は下記サブセクション参照)
🧠 シミュレーション・FP&A	51	(詳細は下記サブセクション参照)
🎨 UX・UI	18	(詳細は下記サブセクション参照)
🛡️ セキュリティ	20	(詳細は下記サブセクション参照)
🏗️ プラットフォーム・アーキテクチャ	19	(詳細は下記サブセクション参照)
🛠️ DevOps・運用ツール	21	(詳細は下記サブセクション参照)
🔬 R&D・税務	7	(詳細は下記サブセクション参照)
🤖 AI活用	5	(詳細は下記サブセクション参照)
🏢 事業・組織・BizDev	16	(詳細は下記サブセクション参照)
🗃️ その他・対象外	13	(詳細は下記サブセクション参照)

💰 経費・仕訳・会計（12 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-073	Story	📊 Report	未払法人税等の適切な処理	経費・仕訳	P1	★★	仕様書完了	04-16	みなし法人税から正式な税金仕訳への移行。確定申告後の納付フロー対応。→ 移行ガイド / 正式処理（派生: MAS-137 対話メニュー）	決算数値の正確性向上	税理士と納付タイミング・仕訳パターンを確認
MAS-074	Story	🧠 Domain	給与INVの未決済残高に仕訳振替分を反映	経費・仕訳	P1	★★★	完了	2026-04-16	仕訳振替INV(源泉・社保預り等)を仮想消込として残高計算に含める。→ 開発仕様書	残高表示の適正化	仮想消込のルール（全額 or 部分）の決定
MAS-075	Story	💾 Data	立替精算INVの発生日＝支払期限バリデーション	経費・仕訳	P1	★★★	完了	2026-04-15	発生日と決済日_計画が同月の場合のエラー/警告表示。→ 開発仕様書	期ずれの防止	警告のみか、入力ブロックかの判断
MAS-076	Story	🧠 Domain	isDuplicate_ 冪等性バグ修正	経費・仕訳	P1	★★★	完了	2026-04-14	FALSEにしたINVをRPA再実行で再作成してしまう問題の修正。→ 開発仕様書	冪等性の担保	なし（明確なバグ。即修正）
MAS-077	Story	🧠 Domain	32タブに決済日列を追加	経費・仕訳	P1	★★	完了	2026-04-16	33タブの決済日_実績を32タブに転記。→ 開発仕様書	計画B/Sの期ずれ精度向上	列追加の DDL 変更タイミング
MAS-088	Story	📊 Report	役員賞与引当金の自動計上	会計指針	P2	★	仕様書完了	04-19	科目マスタ予約済み。来期有効化し月次按分で自動計上。→ 開発仕様書	中小企業会計指針準拠	引当額の算定方法と金額の決定
MAS-089	Story	📊 Report	消費税税抜方式への切替え	会計指針	P2	★★	仕様書完了	04-17	免税→課税移行時に仮受/仮払振り分け+期末精算。→ 開発仕様書。前提案件: MAS-073（未払法人税等）、MAS-110（発生日基準）、MAS-201（バックアップ）	中小企業会計指針準拠	移行日（課税事業者の開始事業年度）の確定
MAS-090	Story	—	受取利息の源泉所得税	会計指針	P3	★	仕様書完了	04-19	受取利息のグロス記録+源泉所得税の法人税等振替。→ 開発仕様書	中小企業会計指針準拠	銀行口座の利息発生頻度・金額の確認
MAS-091	Story	📊 Report	月次残高試算表（T/B）の自動生成	経理実務	P2	★★	未着手	—	科目ごとに「月初残高＋借方発生＋貸方発生＋月末残高」を集計したタブの新設。	経理実務の必須要件対応	T/B の出力フォーマット（税理士との擦り合わせ）
MAS-110	Story	—	証憑日カラムの新設と日付自動補完	電帳法・データ基盤	P1	★★	仕様書完了	—	電子帳簿保存法の検索要件（取引年月日）を満たすため「証憑日」列を新設。現場は証憑日のみ入力し、発生日・決済予定日はシステムが推論・自動補完。DDLスキーマ更新+onEdit Auto-fill+既存データマイグレーション。NULL徹底排除のDWH設計思想。詳細: 開発仕様書	電帳法準拠+現場の入力負荷軽減+NULL排除によるデータ品質向上	証憑日の列挿入位置（インデックスズレの影響調査が最重要）。calculateSettlementDate()のフォールバックロジック。取引先マスタ連携時の決済条件設計
MAS-114	Story	🧠 Domain	インボイス適格請求書の要件チェック	電帳法・消費税	P2	★★	未着手	—	35_wrk_receiptにT番号（適格請求書発行事業者登録番号）の記録はあるが、インボイス制度の形式要件チェックが未実装。T番号の桁数・チェックディジット検証、必要記載事項の有無チェック。	インボイス不備による仕入税額控除の否認リスクを防止	課税事業者への移行時期（MAS-089と連動）
MAS-137	Story	🧠 Domain	未払法人税等の対話形式決算メニュー（MAS-073 派生）	経費・仕訳（決算処理）	P1	★★	仕様書完了	04-19	期末の法人税等の計算→プレビュー→承認→仕訳追記をエンドツーエンドで支援する対話フロー。MAS-073（移行ガイド / 正式処理）の前提を活用し、仕訳生成そのもののギャップを埋める。→ 開発仕様書	決算整理仕訳の自動化	税理士レビューの運用手順・例外処理（更正・修正申告）の扱い

📈 パイプライン・売上計画（8 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-078	Story	📊 Report	84タブにパイプライン売上を合流	パイプライン	P1	★★	仕様書完了	04-18	32タブINVのみ→パイプライン見込みも反映。→ 開発仕様書（派生: MAS-138 Repository 新設版）	入金予測の精度向上	確度加重の閾値（何%以上を計画に含めるか）
MAS-079	Story	📊 Report	51タブをデータソース化（読み込み対応）	パイプライン	P2	★	仕様書完了	04-18	51タブを計画計算の入力ソースにし、手動調整→シミュレーション可能に。→ 開発仕様書（派生仕様: MAS-136 手動調整値の売上計画への加算）。前提案件: MAS-078（84タブへのパイプライン合流・完了）、MAS-003（KPI ダッシュボード・完了）	柔軟な売上計画	手動調整値の上書きルール（リセットタイミング等）
MAS-080	Story	🎨 UI	21タブ管理IDの早期採番	パイプライン	P1	★★★	完了	2026-04-16	受注前の案件にも管理IDを自動採番。→ 開発仕様書	案件トラッキングの強化	なし（UX改善。即実装可）
MAS-081	Story	🧠 Domain	請負契約の売上計上ロジック	パイプライン	P1	★★	仕様書完了	04-19	MRR月額ではなく契約完了月に全額一括計上。→ 開発仕様書。前提案件: MAS-080（21タブ管理IDの早期採番・完了済）	収益認識基準への準拠	進行基準 vs 完了基準の選択（会計方針の決定）
MAS-082	Story	📊 Report	計画B/Sに仕訳振替ペアのB/S表示を追加	パイプライン	P2	★	仕様書完了	—	jePairSetで除外している預り金等を計画B/Sに表示。→ 開発仕様書	B/Sの完全性向上	表示対象とする B/S 科目の範囲
MAS-083	Story	🧠 Domain	パイプライン売上の消費税対応	パイプライン	P1	★★	仕様書完了	—	免税事業者では不要な`×1.1`の税込計算。課税/免税の切り替え対応。→ 開発仕様書。前提案件: MAS-080（21タブ管理ID早期採番）、MAS-116（マイグレーションスクリプト基盤）	消費税計算の適正化	課税事業者への移行時期の確認
MAS-136	Story	📊 Report	51タブ手動調整値の売上計画への加算（MAS-079 派生）	パイプライン	P2	★	仕様書完了	04-19	MAS-079 のデータソース化に加え、51タブにトップダウンの手動調整値（科目・対象年月・金額）を入力すると 60番台 P/L 計画・80番台 CF 計画に加算合流する設計。→ 開発仕様書	トップダウン調整による柔軟な売上計画	手動調整値の保存形式（同月複数行の合算ルール）、マスタ未登録科目の扱い
MAS-138	Story	📊 Report	84タブにパイプライン売上を合流（Repository 新設版 / MAS-078 派生）	パイプライン / 資金繰り予測	P1	★★	仕様書完了	04-19	MAS-078（フック型）の代替案として、`PipelineRepository` / `PipelineDTO` / `PIPELINE_PROBABILITIES` を新設する Repository パターン採用版。32_wrk_invoice に「親パイプラインID(PIP)」列を追加するなど DDL 変更を伴う。→ 開発仕様書	Repository/DTO 化によって FP&A マートとの接続も再利用可能にする	MAS-078 フック型との二択判断（DDL 追加と既存コード改修のトレードオフ）

📊 データマート・財務諸表（6 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-084	Story	🧠 Domain	貸倒引当金繰入額を32タブにINVレコード化	データマート	P1	★★	仕様書完了	—	マート更新時に自動仕訳INV生成。→ 開発仕様書	費用計上の漏れ防止	繰入INVの承認ステータス（自動承認 or 要手動承認）
MAS-093	Story	📊 Report	81/81b CFタブの実績専用モード対応	データマート	P1	★★★	完了	2026-04-15	61 P/L・71 B/Sと同じ isActualOnly パターンをCFタブに適用。一貫性の確保。→ 開発仕様書	実績タブの統一（改修パターン確立済み・小規模）	なし（パターン確立済み。即実装可）
MAS-094	Story	📊 Report	実績集計の基準年月プルダウン選択	データマート	P2	★★	完了	04-16	61/62/71等の実績タブで、集計対象の末月をプルダウンで選択可能に。デフォルトは前月。→ 開発仕様書	任意月での実績確認（月次締め前の仮集計等）	プルダウンの配置場所（シート上 or ダイアログ）
MAS-095	Story	📊 Report	72_bs_snap（B/Sスナップショット）の実績専用化	データマート	P2	★★	仕様書完了	—	71_bsと同様に実績のみ表示。月末時点の確定残高スナップショットとして活用。→ 開発仕様書	B/S実績表示の一貫性	スナップショットの用途（月次報告 or 期末確定）
MAS-113	Story	📊 Report	株主資本等変動計算書の科目マスタ動的参照化	データマート	P2	★★	未着手	—	604_datamart_bs.jsのdmBuildEquityChanges_()で「資本準備金」がハードコードされている。科目マスタ(表示区分=純資産)から動的に読み取る方式に変更。科目の有効フラグ=FALSEの場合に非表示となるよう対応。	科目マスタとレンダリングの一貫性確保	純資産の部に表示する科目の順序ルール
MAS-115	Story	📊 Report	財務諸表タブの統合（プルダウン切替方式）	データマート	P2	★★	未着手	—	現在12タブに分散している財務諸表の出力を、表示モードのプルダウン切替で大幅に削減する。①P/L統合: 61/62/63/64 → 1タブに統合。プルダウンで「単月/累積」×「実績のみ/計画含む」を選択。既存の `isActualOnly` フラグを拡張し、表示モード（ACT_M / ACT_Y / PLAN_M / PLAN_Y）で分岐。②B/S統合: 71/72/73 → 1タブ。「実績/スナップショット/計画」をプルダウンで切替。③CF統合: 81/81b/82/82b → 1タブ。「実績/計画」×「単月/累積」。83/84/85（日次CF）は性質が異なるため別タブ維持。④統合後のタブ構成: P/L(1) + B/S(1) + CF間接法(1) + CF日次(1-2) = 4-5タブ。現状12タブから60%以上削減。	スプレッドシートのタブ肥大化を解消。ユーザーが迷わず目的のデータにたどり着ける。MAS-094（基準年月プルダウン）と組み合わせて「1タブで全ての切り口を見られる」UXを実現	プルダウンの配置場所（A1セル固定 or フローティング）。切替時の再描画速度（データ量が多いと遅延する可能性）。既存タブの廃止タイミング（並行稼働期間の設定）。GCP移行(MAS-238)後はWebUIで実現するため、GASフェーズでの投資対効果の判断

📥 データ取込・自動化（5 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-086	Story	🔧 Infra	領収書→26タブ登録時の税区分自動判定	データ取込	P1	★★	仕様書完了	04-19	→ §3.2 自動入力パイプライン（集約先）を参照。詳細は開発仕様書	領収書登録時の税区分手選択を排除	—
MAS-126	Story	🧠 Domain	発注→INV自動展開（継続契約）	自動化	P2	★★	未着手	—	継続案件のORD確定時に月次INVを自動生成する機能。例: 毎月発生するコンサル委託、固定費的な業務委託など、23_bud_subscription 以外で定額の継続契約を31タブだけで完結させる。①契約パターン: 契約形態=継続、開始年月〜終了年月、月額金額を指定 → 自動で月次INVを32タブへ展開。②冪等性: 既に生成済みのINVはスキップ（発注ID+対象年月でキー照合）。③RPA統合: 407_rpa_orchestrator.js に新ユースケース追加。	継続契約の起票工数を削減。20番台予算タブの分類に迷うケース（サブスクでもadhocでもない業務委託等）を31タブに集約可能	23_bud_subscription との棲み分け（SaaSは23、人的継続契約は31など）。途中解約時のINV削除/無効化ルール
MAS-189	Task	🧠 Domain	HRIS/ATS（人事・採用システム）連携	自動化	P3	★	未着手	—	人事システムと連携し、給与・福利厚生・採用パイプラインを自動同期。	人員計画の精緻化	利用中/導入予定のHRISの特定
MAS-190	Task	🧠 Domain	CRM（Salesforce等）連携	自動化	P3	★	未着手	—	CRMと連携し、パイプライン・販売サイクルデータを自動マッピング。	収益予測モデルの自動化	CRM導入の有無と選定
MAS-235	Task	💾 Data	補助金・助成金管理台帳（D.8 / D.9 派生）	自動化	P2	★★	未着手	—	D.8 §2.f-4 / D.9 §8 抽出案件。`37_wrk_subsidy`（新規シート・DDL 管理・`101_sys_config.js` 追加）。カラム: 案件名 / 管轄省庁 / 申請日 / 採択日 / 受給予定額 / 入金予定日 / ステータス。入金予定日と受給予定額を `84_cf_daily_plan` の将来キャッシュフロー計算に自動反映。反映タイミング（採択時 or 入金確定時）はパラメータ化。対象制度例: ものづくり補助金 / デジタル化・AI 導入補助金 2026 / 小規模事業者持続化補助金 / キャリアアップ助成金 / 人材開発支援助成金 / 越前市小規模事業者未来開拓サポート補助金 / 福井県新規創業支援事業補助金。助成金は事後精算（立替払）が原則で受給まで最短 16 ヶ月・最長 2 年のため、CF 計画への反映設計が重要。	補助金の申請漏れ・入金予定の失念防止。資金繰り計画の精度向上。特に IT 導入補助金・キャリアアップ助成金等の活用促進。既存 FP&A 機能は費用・売上が主対象、補助金という条件付きキャッシュインフロー（不課税売上）に特化した専用管理機能はギャップ領域	CF 計画への反映条件（採択確定 or 入金確定 or 確率按分）、補助金の消費税仕訳（不課税売上）の会計処理との連携要否、ステータスの粒度定義（申請準備中 / 申請済 / 採択 / 不採択 / 入金済）、受給までのラグ（16〜24 ヶ月）の運転資金確保方針との整合

🔄 データ整合性・再同期（4 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-087	Story	🎨 UI	元データ修正→下流タブ再同期 (RPA再生成)	データ再同期	P2	★	仕様書完了	—	元データ→32タブ→42タブ連動。冪等性の担保。→ 開発仕様書	データ修正の容易化	再同期の範囲（全件 or 差分のみ）の設計判断
MAS-122	Story	💾 Data	ORD↔INV 消化状況の整合性チェック	データ整合性	P1	★★★	仕様書完了	—	MAS-297(発注残高二重減算)の恒久対策として、ORD↔INVの消化整合性を自動検証する仕組みを新設。①検証項目: (a) 親ORDなしINVの検知 (b) ORD税込金額_発注 < 紐づくINV.税込金額_計画合計（超過紐付け） (c) 発注残高 ≠ 税込金額_発注 − 計上済INV合計（乖離検知） (d) 有効FLG=FALSE化されたINVが発注残高に反映されているか。②実装: `901_test_runner.js` にテストケース追加＋Action A 実行後に `201_data_validator.js` でWARNING色分け。③再計算ツール: 「発注残高を再計算する」メニュー（mas/800_ops/配下）を追加し、有効INVのみから残高を逆算して強制同期できるようにする。→ 開発仕様書	発注残高の健全性を継続的に担保。MAS-297類似の不整合を早期検知。税理士提出前のデータ整合性確認に活用	再計算ツールの実行タイミング（Action A 前後 / 手動のみ / 月次自動）。超過紐付けの判定閾値（完全一致 or 税込端数許容）
MAS-124	Story	🧠 Domain	31タブ発注残高エイジング＆超過発注アラート	データ整合性	P2	★★	未着手	—	発注残高の滞留・異常値を検知する監視機構。①超過発注検知: 発注残高がマイナス（INV過剰紐付け）を🔴で強調表示（現状は `201_data_validator.js` のO01で警告のみ→本案件で色分け+アラート通知）。②長期未消化エイジング: 契約終了年月を過ぎても残高>0のORDを「長期滞留」として抽出。滞留日数別（30日/60日/90日/長期）に分類。③発注ステータス自動更新: 残高=0かつ全紐づきINV計上済で「完納」ステータスに遷移。	発注統制の強化。予算オーバーランの早期検知。ステータス手動更新の手間を排除	エイジング区分の閾値（事業部門との合意）。契約形態別の滞留判定ルール（継続/スポットで期待挙動が異なる）
MAS-178	Task	📊 Report	堅牢なエラーハンドリングとリカバリー機構	信頼性	P1	★★	仕様書完了	—	データ不整合、API制限、GAS実行時間超過等に対するエラー通知とリカバリー。→ 開発仕様書	システムの安定稼働	エラー通知先（メール or Slack）の選定

🗂️ DDL・マスタ（9 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-111	Story	—	科目マスタに「説明」列を追加（DDL）	DDL・マスタ	P1	★★★	完了	2026-04-14	DDLスキーマに「説明」列が未定義。→ データ整備ページ D-04 に切り出し済み	科目の意味がスプレッドシート上で参照可能に	なし（即対応可）
MAS-112	Story	—	新規科目3件のマスタ登録	DDL・マスタ	P1	★★★	完了	2026-04-14	194開業費・301資本準備金・217役員借入金が未登録。→ データ整備ページ D-01〜D-03 に切り出し済み	創業初年度に必須の科目が使用可能に	資本準備金の金額の確認
MAS-119	Story	🧠 Domain	22タブ人件費予算の入力簡素化（保険料率・税率マスタ化）	DDL・マスタ	P2	★★	未着手	—	22_bud_headcountで健保/介護/厚年/雇保/子ども子育て拠出金率をEMP毎に手入力している構造を解消。新規マスタ `18_mst_tax_rate`（適用年度×雇用形態×各種料率）を追加し、22タブは「適用年度」をキーに料率をルックアップ。401_rpa_hc.js をマスタJOIN方式に改修し、32タブINVへのRPA生成レコードは現状と同一フォーマットを維持。源泉所得税額・住民税額はEMP個別金額のため22タブに残す。既存EMPレコード→18マスタへのマイグレーション（`809_migration_headcount_rates.js`）を冪等実装。	人件費予算の入力負荷を大幅削減。料率改定時は18マスタ1箇所の更新で全EMPに反映。人為的な料率入力ミスを排除	期中に料率改定された場合の適用ルール（開始年月ベース or 発生日ベース）。免税フラグの配置（マスタ側 or EMP個別）。既存22タブの列削除に伴うDDL/データ互換性の検証
MAS-120	Story	🎨 UI	取引先マスタ拡張による20番台予算タブの入力簡素化（横断）	DDL・マスタ	P2	★★	完了	2026-04-20	→ 開発仕様書	21/23/26タブで取引先毎にほぼ固定の決済条件（決済手段/決済ラグ(月)/支払基準日/休日調整/CF計上）がEMPレコード毎に手入力されている構造を解消。`12_mst_partner` に「標準決済手段」「標準決済ラグ(月)」「標準支払基準日」「標準休日調整」「標準CF計上区分」列を追加。21_bud_pipeline / 23_bud_subscription / 26_bud_adhoc のonEditトリガーで取引先選択時に該当列へ自動補完（値は書き込み確定するためオーバーライド可能）。RPA生成レコードは現状と同一フォーマットを維持。既存20番台タブのデータから取引先別の最頻値を12マスタへ抽出するマイグレーション（`810_migration_partner_payment_terms.js`）を冪等実装。前提案件: MAS-110（証憑日カラム / 日付自動補完）、MAS-116（マイグレーション基盤）、MAS-118（起票ターゲット月列）	予算計画立案の入力負荷を大幅削減。取引先の支払条件が変わった時も12マスタ1箇所の更新で一貫性を担保。表記ゆれ・設定漏れによる決済日計算のズレを防止
MAS-121	Story	🧠 Domain	24タブCAPEX特有の償却・借入条件マスタ化	DDL・マスタ	P2	★★	未着手	—	24_bud_capexで資産科目・借入パターンに依存する固定値（償却月数/返済月数/月額返済額/月額支払利息/頭金分割回数/返済日）がCPXレコード毎に手入力されている構造を解消。①償却月数: 科目マスタ(`11_mst_account`)に「標準償却月数」列を追加し、資産科目選択時に自動補完（例: ソフトウェア60ヶ月、什器備品48ヶ月、建物付属設備180ヶ月）。②借入条件: 新規マスタ `19_mst_loan_pattern`（借入パターン名×金利×返済方式×返済月数×頭金分割回数×返済日×休日調整）を追加。24タブに「借入パターン」列を新設し、パターン選択で関連列を自動補完。月額返済額・月額利息は借入金額×金利から算出。③RPA影響: 403_rpa_capex.js はマスタJOIN方式に改修し、32タブINVの生成レコードは現状と同一フォーマットを維持。④マイグレーション: 既存CPXから借入パターンの最頻値を抽出→19マスタへ登録（`811_migration_capex_loan_patterns.js`）、冪等実装。	設備投資・借入シミュレータの入力負荷を劇的削減。元利均等/元金均等の計算をシステム側で担保し、手計算ミスによる資金繰り予測のズレを排除。借入条件改定時は19マスタ1箇所の更新で全CPXに反映	元利均等返済と元金均等返済の両対応（月額返済額の計算式分岐）。金利期中変動の扱い（固定金利のみサポートか）。資産科目毎の償却月数の確定（税法耐用年数表との整合）。既存CPXの借入パターン抽出ロジック（同一取引先でも案件別に条件が異なる場合）
MAS-135	Story	🧠 Domain	決済手段マスタの新設（決済条件マスタ化）	DDL・マスタ	P2	★★	未着手	—	決済手段（JCB / 楽天カード / 口座振替 / 銀行振込 / 立替精算 / 現金等）ごとに決まる決済条件（決済ラグ(月) / 支払基準日 / 休日調整）をマスタ化し、20番台予算タブ・32タブINVでの毎レコード入力を削減。①新規マスタ: `18_mst_payment_method`（決済手段コード × 決済手段名 × 標準決済ラグ(月) × 標準支払基準日 × 休日調整方向 × 備考）。②決済日計算ロジックの優先順位: (a) 取引先マスタに標準決済条件あり(MAS-120) → それを使う (b) なければ決済手段マスタから引く (c) どちらもなければ個別入力値を使う。③対象タブの改修: 21/22/23/24/26タブのonEditで決済手段選択時に該当列を自動補完。32タブでも適用。④既存データマイグレーション: 既存レコードから決済手段別の最頻値を抽出→18_mst_payment_methodへ登録（`812_migration_payment_method.js`、冪等）。⑤RPA影響: 400_rpa_common.jsの決済日計算ヘルパーを (a)→(b)→(c) の優先順位に改修。	カード会社の締日改定を1箇所で反映可能。新カード追加時はマスタ1行追加で完了。取引先マスタ(MAS-120)と組み合わせて契約ベース/決済手段ベースの両方の決済条件管理が自然にできる	MAS-120（取引先マスタ標準決済条件）との優先順位設計。カード会社の締日が月中改定された場合の扱い（発生日ベース or 決済予定日ベースで切替）。「未定」「現金」等の決済手段の扱い（マスタ登録の要否）。既存INVのマイグレーション粒度（全INVバックフィル or 新規分のみ）
MAS-139	Story	🎨 UI	各入力項目にセル単位の入力範囲（データバリデーション）を追加	DDL・データ品質	P1	★★★	仕様書完了	04-20	→ 開発仕様書 `setupAllSchemas` の DDL ロジックに `setDataValidation` を組み込み、各入力列にセル単位の入力ルールを宣言的に適用する。①対象ルール: (a) 数値範囲（割合 0-100、日数 0-365 等）、(b) 日付範囲（事業年度内のみ等）、(c) リスト選択（マスタ参照のプルダウン強化）、(d) 文字長制限、(e) 正規表現（T番号 `^T\d{13}$`、メールアドレス等）。②宣言方式: `mas/100_config/101_sys_config.js` のスキーマ辞書（`schemas`）に `validations` キーを追加し、列ごとに `{ type: 'range', min, max, errorMessage }` 等の DSL で記述。setupAllSchemas 実行時に DDL 適用と一緒に `Range.setDataValidation()` を発行。③違反時挙動: `requireDate / requireNumberBetween / requireValueInList` の `setAllowInvalid(false)` で原則ブロック、ただし RPA 起票・マイグレーション等の機械書き込みは事前に `clearDataValidations()` でガードを外して回避。④既存 201_data_validator.js との棲み分け: 同モジュールは「行全体の整合性チェック」を担う一方、本案件は「セル単位の即時ブロック」を担う（入力時点でユーザーに警告 → エラー前段防御）。⑤マスタ参照プルダウンの自動更新: マスタタブ（11_mst_account 等）の行追加時に、参照側タブのプルダウンソース範囲も自動拡張（`onEdit` フック or 定期再適用）。	誤入力をシステム側で物理的に防止。201_data_validator.js が事後検知なのに対し、本案件は事前防止。データ品質の最初の砦になる	厳格モード `setAllowInvalid(false)` で運用するか、警告のみの寛容モードか。RPA・マイグレーションでガードを外すタイミングと再適用の責務分担。プルダウンソース範囲の動的拡張方式（GAS API のクォータ消費）。エラーメッセージの多言語化要否
MAS-140	Story	💾 Data	MAS-120 後追い対応（プルダウン名前付き範囲追加・数値書式 `#,##0` 設定）	DDL・UI 仕上げ	P3	★	未着手	—	MAS-120（取引先マスタ拡張）実装時に後送りした 2 件の小規模仕上げ作業。①18_dropdown シートに名前付き範囲追加: `UI休日調整`（前営業日 / 当日 / 翌営業日）・`UICF計上`（営業活動 / 投資活動 / 財務活動）の 2 つを追加し、12_mst_partner / 21/23/26 タブのプルダウンソースを名前付き範囲参照に統一。②数値書式 `#,##0` の一括適用: 12_mst_partner の「標準決済ラグ(月)」「標準支払基準日」列、および 21/23/26 タブの該当列に `setNumberFormat('#,##0')` を `setupAllSchemas` の DDL に組込。	MAS-120 を完成形に。プルダウン値の表記揺れを根絶し、桁区切り表示で視認性向上。MAS-139（セル単位データバリデーション）とも整合（MAS-139 が本格対応するまでの暫定的な品質向上）	名前付き範囲名のネーミング規則（`UI` プレフィックスで統一）。MAS-139 実装時に本案件のロジックを統合できるか（重複の解消）
MAS-212	Task	🎨 UI	論理削除の理由記録＋物理削除アーカイブ	データ管理	P2	★★	未着手	—	①削除理由列の追加: 31/32/33/42 等の主要タブに「無効化理由」「無効化日時」列を DDL 追加。有効フラグを FALSE にした際に `onEdit` トリガーで自動記録（操作者名＋日時＋任意コメント）。MAS-179（監査証跡）と連携し、誰がなぜ無効化したかをトレース可能に。②物理削除アーカイブ: 有効フラグ=FALSE かつ無効化日時から N ヶ月経過した行を専用アーカイブシート（99_archive）に移動＋元タブから物理削除。アーカイブ実行はメニューから手動 or 月次締め（MAS-148）に組み込み。保持期間は 03_sys_params で設定（デフォルト: 6ヶ月）。	論理削除データの蓄積によるシート肥大化を防止。削除理由の記録で「なぜ消したか」が追跡可能に。税務調査時の説明責任にも対応	保持期間の基準（6ヶ月 or 年度末 or 決算確定後）。アーカイブシートの構造（全タブ統合 or タブ別）。アーカイブからの復元手順

🧮 PJ別損益・原価計算（3 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-085	Story	🧠 Domain	78タブ全社合計と92タブ営業利益の整合性チェック	PJ別損益	P1	★★★	完了	2026-04-15	不一致の原因を自動検証し、マート更新時に警告表示。→ 開発仕様書	データ整合性の担保	なし（検証ロジックのみ。即実装可）
MAS-105	Story	🧠 Domain	工数入力・PJ原価連携	PJ管理	P2	★★	未着手	—	現行の27_bud_resource（稼働率%）を拡張し、実際の作業時間（工数）を記録。要員×PJ×月の工数マトリクスから人件費按分を精緻化。HC RPA の月額給与×稼働率で PJ別原価を自動計算→78_pj_pl（PJ別損益）に反映。現状の稼働率%ベースの按分より正確な原価把握が可能。	PJ別原価の精度向上。稼働率%の「ざっくり按分」から実工数ベースに進化	工数の入力粒度（日次 or 週次 or 月次）。入力UIの設計（シート直接 or フォーム）。勤怠管理(MAS-099)との連携
MAS-117	Story	🧠 Domain	PJ別配賦計算の丸め誤差解消	PJ別損益	P2	★★	仕様書完了	04-18	78_pj_plの共通費配賦計算で端数が累積し、92_fs_plの営業利益と最大¥439の差異が発生（MAS-085で検出）。配賦率按分時の端数処理（最大PJに残差を寄せる等）を導入し、全社合計が92タブと完全一致するようにする。MAS-006仕様書（`dev_mas-006_project_overhead_allocation.md`）に統合。	PJ別損益の正確性向上	端数処理方式の選定（最大PJに残差寄せ or 按分比率の再計算）

🧠 シミュレーション・FP&A（51 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-001	Story	📊 Report	予実差異分析 (Variance Analysis)	FP&A	P1	★★★	完了	2026-04-15	差異額・差異率列追加、閾値超過の色分けアラート、YTD累計サマリー。→ 開発仕様書	予実管理の高度化	アラート閾値（差異率何%で赤/黄表示するか）
MAS-002	Story	🧠 Domain	予算スナップショット/バージョン管理	FP&A	P2	★★	未着手	—	予算確定時のスナップショット保存、当初予算 vs 修正予算 vs 実績の比較。	計画変更のトラッキング	スナップショットの保存タイミング（月次 or 四半期 or 任意）
MAS-003	Story	📊 Report	KPIダッシュボード/経営指標	FP&A	P1	★★	完了	2026-04-17	売上総利益率、営業利益率、損益分岐点、ランウェイ、労働分配率の自動算出。93_kpi_dashboard 新設、条件付き書式で閾値警告、SPARKLINE で6ヶ月トレンド。→ 開発仕様書。前提案件: MAS-024（BEP・完了）、MAS-020（前年同月比較・完了）、MAS-001（予実差異・完了）	経営状態の可視化	表示するKPIの選定と優先順位
MAS-004	Story	🧠 Domain	ローリングフォーキャスト	FP&A	P3	★	未着手	—	常に「直近実績月＋向こう11ヶ月」を表示。実績確定月はロックし以降を再計算。	継続的な予測精度の向上	予測期間（12ヶ月 or 18ヶ月）、更新頻度（月次 or 週次）
MAS-005	Story	🧠 Domain	動的シナリオプランニングUI	シミュレーション	P3	★	未着手	—	ベース・楽観・悲観などの複数シナリオを定義し、タブ等で瞬時に切り替えて比較。	リスクシナリオへの備え	シナリオの定義（楽観/悲観の前提条件を何にするか）
MAS-006	Story	🧠 Domain	PJ別管理会計の共通費配賦	FP&A	済	—	完了	—	✅ 実装済み (420_project_profitability.js)。仕様書 `dev_mas-006_project_overhead_allocation.md` で MAS-117（丸め誤差解消）を統合した高度化改修設計を公式ドキュメント化。前提案件: MAS-085（78_pj_pl と 92_fs_pl の整合性チェック・実装済 L761-789）	プロジェクト別損益の精緻化	—
MAS-007	Story	🧠 Domain	ドライバーベース計画の拡張	FP&A	P3	★	未着手	—	ARPU、チャーンレート等のKPIやマクロ経済指標をパラメータとして自動計算。	ビジネスモデルに即した計画	モデル化するドライバー変数の選定（業種固有のKPI）
MAS-008	Story	📊 Report	資金繰り予測の高度化 (Cash Runway)	FP&A	P2	★★	仕様書完了	04-18	ランウェイ計算、月末現預金推移予測。バーンレート(過去Nヶ月の営業CF流出平均、財務CF除外)+現預金÷バーンレートでランウェイ算出。03_sys_paramsでパラメータ化、条件付き書式で警告表示。→ 開発仕様書	資金ショートの未然防止	ランウェイの最低ライン（何ヶ月分を安全水準とするか）
MAS-009	Story	🧠 Domain	資金ショート警告アラート	シミュレーション	P3	★	未着手	—	資金繰り予測に基づき、数ヶ月先の資金ショートリスクをSlack等で自動通知。	経営陣への早期アラート	通知先（Slack/メール）と閾値の設定
MAS-010	Story	📊 Report	中長期（5カ年）財務モデリング	シミュレーション	P2	★★	仕様書完了	2026-04-22	→ 開発仕様書。過去 12〜36 ヶ月実績から CAGR + 季節性指数 + 変動費率 + 固定費月平均を自動抽出し、60 ヶ月月次 P/L ベースライン予測を `94_fs_longterm_forecast` に出力。新規 `mas/600_report/611_financial_modeling.js`（`FinancialModelingService`）。MVP は P/L のみ先行、B/S・CF は MAS-018 連動エンジン完成後に段階拡張。Gemini Pro + Claude Sonnet 添削パイプライン経由で生成。2026-04-22 `simulateWithOverlay` 公開 API 追加 (MAS-011 連携用)	中長期経営計画の起点・銀行融資説明の基礎資料・MAS-013 投資案件 CF 重ね合わせのベース	成長率デフォルト値妥当性、CAGR vs 直近平均、調整額列、MAS-013 連携運用、シナリオ UI 統合、バックテスト機能
MAS-011	Story	📊 Report	ボトムアップ型What-ifシミュレーション	シミュレーション	P3	★	MVP 完了	2026-04-23	「営業を1人増やしたら」など、ドライバーを操作してP/L・CFへのインパクトを即時確認。MVP 範囲: HC_ADD + SAAS_ADD + 5カ年 MAS-010 連携（PR #315）。Polish として実績平均精度向上・変動費比率連動・5カ年表示改善を追加（PR #320）。HC_REMOVE / PIPELINE_SPOT_ADD は V2 残件（MAS-044 テンプレマスタ / MAS-045 予算転記で補完予定）	投資対効果の事前検証	シミュレーション対象のドライバー一覧の決定、V2 残件の着手順序（MAS-044/MAS-045 先行 or HC_REMOVE/PIPELINE_SPOT_ADD 先行）
MAS-012	Story	📊 Report	目標逆算型人員計画シミュレーション	シミュレーション	P3	★	完了	2026-04-23	→ 開発仕様書 / 実装完了 (PR #337、`mas/600_report/612_sim_headcount.js` 新設)。推計された売上目標を達成するために必要な人員数・採用タイミングを逆算。売上貢献フラグにより顧問会計士・顧問社労士等のコスト型 HC を平均算出から除外する機能を含む。MAS-048 採用 TCO と逆方向（MAS-012 = 目標売上 → 必要人員逆算 / MAS-048 = 1 人採用コスト順算）の相補関係。	採用計画の最適化	一人当たり売上高や稼働率の前提値
MAS-013	Story	📊 Report	投資回収シミュレーション	シミュレーション	P3	★★	完了	2026-04-23	→ 開発仕様書 / 実装完了 (PR #329、`mas/600_report/610_service_investment_analysis.js` 新設・429 行)。`30_bud_investment_case`（DDL 管理・29 列・5 カ年版、PR #325 でシート番号 25→30 / PR #324 で 10→5 年縮小）+ `67_report_investment_analysis`（DDL 管理外動的上書き）の 2 枚構成。NPV / IRR / 回収期間 / ROI / ROIC（年次 + 加重平均）計算エンジン、`Constants.TAX_RATES` 累進税率適用。MAS-010 への重ね合わせ接続口 `generateFiveYearCashImpact_` と感度分析マトリクス（売上 ±20% / CAPEX ±10% / WACC ±2pp）は補強で定義済、Web アプリ (doGet) からも実行可能 (`_notifyUser_` フォールバック)	投資判断の定量化 + MAS-010 連結 5 年予測への即時反映 + ROIC による資本効率評価	割引率デフォルト、シナリオ保存機能、MAS-010 複数案件合算運用、MAS-018 エンジン委譲タイミング、MAS-042（Go/No-Go 判定）との連携運用
MAS-016	Story	📊 Report	営業ファネル連動型売上予測	シミュレーション	P3	★	仕様書完了	04-14	リード獲得→商談→提案→受注の各フェーズのコンバージョン率から将来の売上を予測。→ 開発仕様書	パイプライン管理の高度化	ファネルのフェーズ定義と各フェーズの確率設定
MAS-017	Story	📊 Report	資金調達シミュレーション	シミュレーション	P3	★	未着手	—	シナリオ分析から、資金ショートを回避するために「いつ・いくら」の資金調達が必要かを逆算。	財務戦略の立案支援	調達手段の選択肢（エクイティ/デット/助成金等）
MAS-018	Story	—	財務3表の完全連動モデリング	FP&A	P2	★★	仕様書完了	2026-04-21	→ 開発仕様書（2026-04-22 補強追記: 運転資本連動 + MAS-010/MAS-013 共通エンジン化）。CAPEX 1 ドメインの P/L-B/S-CF 連動を初版で実装、補強で `F18LinkageService.computeBsCfLinkage(plRows, prevBsSnapshot, paramsMap)` 公開 API を定義し MAS-010 / MAS-013 から共通利用。後続 F-18b（別起票候補）で在庫・売掛金・買掛金の運転資本変動を追加連動	経営の健全性・一貫性の担保 + MAS-010/MAS-013 の B/S・CF 推計エンジン統一	連動インプット優先順位（HC/SaaS/Pipeline/Adhoc の順序）、CF区分マスタ列追加判断、F-18b 別起票タイミング、『自動計上案』ステータス運用
MAS-020	Story	📊 Report	前年同月比較（YoY）の自動表示	FP&A	P2	★★	完了	2026-04-16	61 P/L実績タブに前年同月との差異列を自動追加。MAS-177(多年度基盤)が前提。→ 開発仕様書	経営トレンドの可視化	前年データの保持方法（別シート or 同一シート内）
MAS-022	Story	📊 Report	予実差異の要因ドリルダウン（INV単位）	FP&A	P2	★★	未着手	—	MAS-001の発展版。差異が大きい科目をクリック→原因INVレコード一覧を表示。	差異要因の即時特定	ドリルダウンの表示方式（別シート or サイドバー）
MAS-024	Story	📊 Report	損益分岐点（BEP）の月次自動算出	FP&A	P2	★★★	完了	04-15	科目マスタの固変区分を活用し、BEP売上高を月次で自動計算。→ 開発仕様書	経営判断の即時支援（既存データで算出可）	固変区分の正確性の確認（科目マスタのレビュー）
MAS-025	Story	📊 Report	予算vs実績差異分析（41_trn_budget ベース）	FP&A	P1	★★★	仕様書完了	04-19	MAS-001(65タブ)は着地見込みvs実績（承認漏れ検出）。本案件は 41_trn_budget を計画側に使用した本来の予実差異分析を 66_pl_budget_variance に出力する。→ 開発仕様書	予算策定→実績対比のPDCAサイクル実現	41_trn_budget のデータ整備状況
MAS-026	Story	🧠 Domain	TDABC（時間主導型ABC：活動基準原価計算）	FP&A	P3	★★	未着手	—	MAS-006（現行の配賦）を進化させ、実際の作業時間ベースで間接費を配賦。①時間単価の算出: 人件費総額÷実稼働時間=1時間あたりコスト（キャパシティレート）。②活動時間の記録: MAS-105（工数入力）の実績データ or MAS-027（M365ログ）の自動推定データを使用。③配賦計算: PJ別の消費時間×時間単価で間接費を配賦→78_pj_plに反映。現行の稼働率%ベース（MAS-006）より正確。④一人法人の場合: 最大の間接コスト=経営者の労働時間。これを正確に配賦できれば「究極の原価管理」が完成。	「売上Aランクだが実は時間を食って赤字」のような隠れた不採算案件を発見。MAS-039(ABC分析)の精度を飛躍的に向上	MAS-105(工数入力)が前提。工数の入力粒度（30分単位 or 1時間単位）。未配賦時間（管理業務・移動等）の扱い
MAS-039	Story	—	ABC分析（パレート分析）ダッシュボード	FP&A	P2	★★	未着手	—	PJ別・取引先別の利益貢献度を降順に並べ、累積構成比でA/B/Cランクを自動分類。①PJ別ABC: 78_pj_pl の限界利益データを利益額降順でソート→累積70%=A、70-90%=B、90-100%=Cに自動タグ付け。パレート曲線（棒グラフ+累積折れ線）を自動描画。②取引先別ABC: 32_wrk_invoice を取引先×収支区分で集計→同様にランク付け。「売上はAランクだが利益はCランク」の案件を炙り出す。③閾値設定: A/B/C の境界%(70/90)は03_sys_paramsで設定可能。④経営判断支援: Aランク=リソース集中投下、Cランク=自動化 or 撤退検討、の意思決定材料を提供。	「どの事業・顧客に集中すべきか」をデータで即座に判断。売上ベースのざっくり判断ではなく、MAS-006の正確な配賦に基づく「真の利益」でランク付け	ABCの分類対象（PJ/取引先/科目のどれを主軸にするか）。ランク変動のトレンド表示（前月比でA→Bに落ちた案件の警告）。MAS-006(配賦)の精度がABC分析の精度を決める
MAS-040	Story	📊 Report	法人税計算の会計年度ベース化（MAS-010/MAS-013/MAS-018 共通）	FP&A 改善	P2	★	未着手	—	MAS-010 / MAS-013 / MAS-018 の法人税計算は現状暦年（1-12 月）ベースで年税額を 12 等分する簡易実装。これを `CFG_FISCAL_START_MONTH`（例: 8）ベースの会計年度単位に変更し、FY 境界で `Constants.TAX_RATES` の累進閾値判定（800 万円境界）と均等割年割り計算（設立初年度の月数按分）を正確に行う。対象: `mas/600_report/611_financial_modeling.js` の `computeCorporateTax_` / `projectMonthlyPL_` の `byCalYear` ループ、MAS-013 の `calcEffectiveTaxRate_`、MAS-018 の連動エンジン。前提: MAS-010 / MAS-013 / MAS-018 Phase 2 実装完了後。	会計年度決算書の税額と MAS-010 予測値のズレ解消。初年度・急成長期（売上が 800 万円境界を跨ぐタイミング）の予測精度向上、投資家向け損益予測の信頼性向上	既存の暦年ベース実装と併存させるか切替えるか（`03_sys_params` の `CFG_TAX_YEAR_MODE` フラグで `calendar` / `fiscal` 切替を提供する案）、FY 境界で既存データが暦年集計されている場合の移行運用、複数法人（将来 SaaS）での会計年度バラバラ対応
MAS-041	Story	—	繰越欠損金・税制優遇の計算反映（MAS-010/MAS-013 法人税推計の精緻化）	FP&A 改善	P3	★	未着手	—	MAS-010 / MAS-013 の法人税計算に以下 4 項目を反映し、スタートアップ初期の赤字期〜成長期の税額予測を精緻化。①繰越欠損金 10 年繰越控除: 中小法人は欠損金 100% 控除、過去 10 年分を `94_fs_longterm_forecast` で追跡し翌年以降の税引前利益から減算。②所得拡大促進税制: 給与支給総額の前年比増加率に応じた税額控除（中小企業賃上げ促進税制）。③中小企業軽減税率特例: 資本金 1 億円以下かつ年所得 800 万円以下部分への 15% 軽減（Constants.TAX_RATES の 21.4% とは別枠の特例措置）。④MAS-038（R&D 税制）との統合: 試験研究費の税額控除（中小企業基盤強化税制、控除上限 25% 等）を MAS-010 / MAS-013 の税引後 CF に反映。対象: MAS-010 の `computeCorporateTax_`、MAS-013 の `calcFcfYearly_`。	赤字期の将来税額が過大推計されるズレを解消（欠損金繰越控除で税額 0 となる年を正確に予測）。投資家向け損益予測・銀行融資審査用ランウェイ計算の精度向上。MAS-038 完了後は R&D 税制効果が 3-5 年累計で 50-200 万円規模に達し予測への影響が無視できなくなる	どの優遇税制まで自動化するか（顧問税理士との運用範囲の切り分け）、繰越欠損金の期末残高を `03_sys_params` or 専用タブ（`30_bud_loss_carryforward`）で管理するか、所得拡大促進税制の賃上げ率閾値の毎年の改正追従、MAS-038 研究開発税制との統合スコープ（中小企業基盤強化版 vs 一般試験研究版の切替判定）
MAS-042	Story	🧠 Domain	投資ハードルレートマスタ & Go/No-Go 判定（MAS-013 補完）	FP&A	P3	★★	MVP 完了	2026-04-23	→ 開発仕様書 / MVP 実装完了 (PR #336)。`29_mst_investment_hurdle` マスタ DDL 追加 + `431_investment_analyzer.js` に Go/No-Go 判定ロジック統合 + `68_report_investment_gonogo` 出力。採用 / 委託 / 設備 / SaaS の 4 カテゴリで Go/グレー/No-Go の 3 段階ラベル自動付与。残件は業務委託→正社員化損益分岐アラート・WACC 連携（MAS-017 完了後）。	MAS-013（投資回収シミュレーション）の計算結果に対して、投資カテゴリー別のハードルレート閾値と照合し Go / グレー / No-Go の 3 段階ラベルを自動付与する判断補助エンジン。①ハードルレートマスタ `29_mst_investment_hurdle`（新規・DDL 登録）: カテゴリー別（採用/設備/SaaS/ERP/IT小物/一般 CAPEX）に WACC+α、Payback 閾値、ROI 閾値、年商比上限を登録。初期値は 2026 年水準（設備 Payback 2 年、SaaS 1.5 年、ERP 3 年、ROI 20%、中小経営強化税制 B 類型 7%）。②採用投資スクリーニング: 採用費用 + オンボーディング工数（年収の 20-30%）+ 離職リスク係数（厚労省小規模法人 3 年以内離職率 52.7% 適用）から実効 Payback を算出し、職種別閾値（コンサル/営業 6-12 か月、エンジニア 12-18 か月、新卒 24-36 か月）で Go/No-Go 判定。入力は `22_bud_headcount` の採用予定行を拡張するかたちで実装。③業務委託→正社員化損益分岐アラート: `402_rpa_subscription` の継続中の業務委託契約から「月 50 万円 × 継続 12 か月超」を検知し、正社員化した場合の年間コスト差（20-30% 減）を自動試算。④MAS-013 連携: MAS-013 の `67_report_investment_analysis` に判定ラベル列を追加、`29_mst_investment_hurdle` からカテゴリー別閾値を引き当て。MAS-017（WACC 計算）完了後はそちらから WACC 値を参照。	MAS-013 は計算エンジン、MAS-042 は判断エンジンとして補完関係。税制改正（経営強化税制 B 類型 5%→7%、2025 年改正）や業界相場変動をマスタ側で吸収でき、閾値のハードコード禁止原則に適合。採用・委託・設備・SaaS の 4 カテゴリーで「いくらなら Go / いくらなら No-Go」を即断できる経営判断基盤
MAS-043	Story	🧠 Domain	ハイブリッド 2 トラック採算管理（RICE/VALUE/SEED）	FP&A	P2	★★	未着手	—	ブティック・一人ファーム構造の BLP において、案件を 3 トラック（RICE=ライスワーク / VALUE=バリューワーク / SEED=仕込み・非課金）に分離して採算を追跡する仕組み。汎用中小企業ルール「人件費 × 3 倍ルール」が一人ファームには構造的に過剰（販管費 15-20% で、存在しない 20% 分を価格に織り込むことになる）という認識に基づき、価格戦略に連動した採算管理を実現。①PJマスタ拡張: PJマスタ（`14_mst_project` 相当）に `案件種別` 列を追加し、各案件を RICE/VALUE/SEED のいずれかに分類。②`420_project_profitability` 拡張: Cost Multiplier（請求単価÷内部原価時給）をトラック別に集計し、`79_pj_monthly` に種別列を追加。全社平均の単一倍率は出さない。③稼働時間配分の可視化: 月次で RICE 50-60% / VALUE 20-30% / SEED 10-30% の目標レンジを `93_kpi_dashboard` に追加、レンジ外れを色分け。④失敗パターン検知: (a) 月次 RICE 時間キャップ到達時の新規受注推奨ブロック、(b) VALUE 仕込み時間フロア割れの赤信号、(c) 同一クライアントに RICE/VALUE 両案件がある場合の VALUE 単価コンタミネーション警告。⑤健全値追跡: 一人ファーム目標（販管費率 15-20%、営業利益率 30-45%）を `93_kpi_dashboard` の新規セクションで追跡。	「倍率で価格を決める」汎用ルールから脱却し、ライスワーク 2 倍台 + バリューワーク実質 5-10 倍のハイブリッド構造を数値で見える化。MAS-032（プロダクト別 P/L・事業ポートフォリオ軸）とは別軸（案件種別・価格戦略軸）。MAS-042 の採用投資 Payback 計算の単価前提にも影響（VALUE 単価で採用を正当化する誤謬を回避）	RICE/VALUE/SEED の境界定義（価格倍率で機械判定 or PM が手動タグ付け）、VALUE 単価の閾値（倍率ではなく絶対額ベースで管理する場合のマスタ構造）、MAS-032 との集計整合性（同一案件が MAS-032 で「受託」、MAS-043 で「RICE」となる二重計上防止）、失敗パターン検知の通知チャネル（色分け / メール / Slack）、案件種別の年次見直し運用（RICE 単価が自然に 2.3→2.5 倍へスライドした際の VALUE への昇格基準）
MAS-044	Story	💾 Data	ポジション別 HC テンプレートマスタ（MAS-011 MVP 後継、HC 限定）	FP&A	P3	★★	完了	2026-04-23	→ 開発仕様書 / 実装完了 (PR #339)。`18_tmpl_hc_position` DDL 新設 + `PositionTemplateRepository` + MAS-011 サイドバー dropdown 拡張 + 採用費/PC費/稼働率連動。`MST_HC_TMPL` schema に追加 4 列（月次追加固定費 / 立ち上がり月数 / 売上貢献 / 稼働率）を実装。SaaS カタログ部分は MAS-055 に切出（PR #338）。	人員追加の What-if (HC_ADD) で毎回手入力しているポジション別給与水準・採用費デフォルト・PC 費デフォルト等をマスタ化。新規シート: `18_tmpl_hc_position`（列: 有効フラグ / 管理ID / ポジション名 / 想定雇用形態 / 標準月額給与 / 想定月次売上貢献 / 想定変動費比率 / 採用費デフォルト / PC 費デフォルト / 備考、`MST_HC_TMPL` / DDL 管理）。Repository: `PositionTemplateRepository`（`AccountRepository` パターン準拠）。MAS-011 サイドバー拡張: HC_ADD ドライバーフォームにテンプレート選択 dropdown を追加 → 選択で全フィールド自動入力。実績ゼロ期（創業直後・新ポジション）のフォールバック補完として機能。ポジション例: 営業 Jr/Sr、エンジニア Jr/Mid/Sr、CSM、Manager、Executive。2026-04-23 に SaaS カタログ部分を MAS-055 に切り出し、本案件は HC テンプレに限定された（main スペースの採用判断機能群への注力方針を反映）	毎回手入力の手間削減、社内基準の標準化、MAS-011 実績ゼロ時のフォールバック、MAS-048 採用 TCO シミュレーター / MAS-045 予算転記の入力源として連携
MAS-045	Story	💾 Data	What-if 結果を `22_bud_headcount` / `23_bud_subscription` へ転記する機能（MAS-011 MVP 後継）	FP&A	P3	★★	未着手	—	MAS-011 MVP 後継案件（PR #315 / #320 完了後に起票）。MAS-011 What-if で設定した値を実際の予算シート（`22_bud_headcount` / `23_bud_subscription`）に新規行として転記する機能。「検討 → 実行」を 1 サイクルで完結させる。①UI 拡張: サイドバー結果表示後に `📥 この条件で予算に反映` ボタンを表示。②Human-in-the-Loop: 転記前に確認ダイアログ、転記後は背景色を一時的にハイライトして視認性確保。③実装パターン: `Contracts.toRow` で DTO を生成し、既存 `InvoiceRepository.append` 類似のパターンで末尾追加（`mas/200_data/202_repository.js` の `HeadcountRepository` / `SubscriptionRepository` 新設も検討）。④監査ログ: `98_audit_log` に `operation='CREATE'` / `targetSheet='22_bud_headcount'` 等で記録。⑤MAS-010 連携: 5 カ年モードで確定した採用計画をそのまま MAS-010 連携ベースラインに取り込めるようになる（期間指定または年次複数行の選択運用）。	What-if の検討と実行予算化が 1 サイクルで完結 → 意思決定の流速向上。「人員を増やすシミュレーションを何度も回して最終確定 → 予算シートに手入力」の二重作業を解消。MAS-010 連携ベースラインへの反映が 1 アクションで完結	転記後の `有効フラグ`（TRUE で即反映 or FALSE で「承認待ち下書き」扱い）、監査ログのフォーマット（どの payload を `afterValue` に入れるか）、5 カ年モードで確定した場合の複数年分の定員増の表現（1 行で期間指定 or 年次複数行）、MAS-044 のテンプレート選択情報（テンプレ ID）を転記行に記録するか、転記後に取り消せる仕組み（`有効フラグ=FALSE` 運用 or 専用の「取消」メニュー）
MAS-046	Story	💾 Data	投資カタログマスタ整備（D.8 派生）	FP&A	P2.5	★★	未着手	—	D.8 §1.3, §2 抽出案件。D.8 の 8 大投資カテゴリー（a.マーケ / b.R&D / c.IP / d.人材 / e.IT / f.財務 / g.ガバナンス / h.M&A）を `19_mst_investment_catalog`（仮採番・要変更: MAS-055 で `19_tmpl_saas_catalog` 確定済のため衝突。実装着手時に別番号を採番すること）で DDL 管理。実装は `101_sys_config.js` への DDL 定義追加のみ（新規 GAS ファイル不要）。カラム: カテゴリコード / カテゴリ名 / 典型投資額レンジ / 主要 KPI / ハードルレート参照値。MAS-047 / MAS-052 の共通データソースとして機能。	投資選択肢の網羅的管理と意思決定の抜け漏れ防止。DDL 追加のみなので実装コストは軽量。FP&A 機能群の共通マスタ基盤。`11_mst_account`（会計科目マスタ）と異なり経営上の「投資カテゴリー」を管理するビジネスレイヤーの概念	M&A カテゴリーを 1 人法人フェーズで含めるか（見送り推奨）、MAS-047・MAS-052 が先行実装されない場合の本マスタ単体価値の再評価、典型投資額レンジの根拠と更新頻度、シート番号の確定（MAS-044 の `19_tmpl_saas_catalog` と衝突する可能性）
MAS-047	Story	🌐 Cross	RICE スコアリング機能（D.8 派生）	FP&A	P2.5	★★	未着手	—	D.8 §5.1 / D.10 抽出案件。`30_bud_investment_case`（MAS-013 定義）に RICE スコア関連列（Reach / Impact / Confidence / Effort / Score）を DDL で追加（`101_sys_config.js` 更新）。スコア計算は `mas/400_domain/` または `mas/600_report/` の既存ファイルへの関数追加で対応。`301_ui_assist.js` のサイドバー UI から入力・確認。Effort は人月単位入力、`22_bud_headcount` の時間単価から概算コストを自動算出。	財務指標化しにくいプロダクト開発・マーケ施策の優先順位付けを定量化。感覚的な意思決定からの脱却。MAS-042 との差別化: MAS-042 は財務指標（NPV/IRR）による Go/No-Go 判定、本案件は定性評価フレームワークで財務計算以前のフィルタリング機能として補完的	Impact / Confidence の 5 段階評価の組織内定義、Effort（人月）の算出基準（実績 or 見積もり）、スコアのレビュー・更新プロセスとその頻度、MAS-042 との連携運用（RICE でスクリーニング → MAS-042 で財務判定の二段フィルタ）
MAS-048	Story	🧠 Domain	採用 TCO & BEP シミュレーター（D.9 派生）	シミュレーション	P1.5	★★★	完了	2026-04-24	→ 開発仕様書 / 実装完了 (PR #343、`mas/400_domain/412_hiring_tco_simulator.js` 新設)。`69_report_hiring_tco` 出力シート（DDL 管理外・動的上書き）、`03_sys_params` で法定福利費率 15.68% 等 13 パラメータ管理、離職率 52.7% 調整 Payback 計算、MAS-044 テンプレ連携（PositionTemplateRepository.findAsMap の 11 フィールド自動入力）。D.9 §2, §5 抽出案件。Jr 採用 D-180（2026 年 10 月入社想定）の採用可否判断基盤。`mas/400_domain/` に採用コスト計算 namespace（新規ファイル）を追加。入力: 想定年収・雇用形態・採用チャネル費用。出力: TCO（法定福利費・採用費・研修費・設備按分を含む実コスト）と損益分岐点売上。`22_bud_headcount` から既存人件費率を参照。各パラメータ（法定福利費率 15.68% 等）は `03_sys_params` で管理。UI は `301_ui_assist.js` のサイドバー。	給与 600 万 → 実コスト 900 万の可視化。採用可否の財務判断を定量化。MAS-012（目標売上から必要人員数逆算）と異なり、「1 人採用したときの実コストと採算ライン」を順算する特化型シミュレーション	法定福利費率の年次更新方法、業務委託との比較モード追加の要否、定着率リスク（3 年以内離職率 52.7%）の感応度分析をオプション機能として付加するか、オンボーディング工数の按分ルール
MAS-049	Story	🧠 Domain	賃上げ促進税制効果シミュレーター（D.9 派生）	シミュレーション	P2	★★	完了	2026-04-24	→ 開発仕様書 / 実装完了 (PR #346、`mas/400_domain/414_wage_tax_credit_simulator.js` 新設)。令和 8 年度改正後の中小企業版（最大 45% / 法人税額 20% 上限 / 5 年繰越）を実装。創業期シナリオ（前期役員報酬のみ → 今期採用で増加率 100% 超）で D.9 §9.1 例示の 126 万円控除と一致。MAS-048 と連携し採用 1 名の税額控除寄与を計算。D.9 §9.1 抽出案件。`mas/400_domain/` に `TaxCreditSimulator` namespace（新規ファイル）を追加。前年度給与支払総額（役員報酬のみ = 創業期）と採用者想定給与を入力 → 増加率・控除率（中小企業通常 15〜45%）・控除上限（法人税額の 20%）から税額控除額を計算。法人税額は `03_sys_params` への入力値を使用。結果を `93_kpi_dashboard` に表示。税制改正追従ポリシーの明文化が設計上必須（令和 8 年度改正等を考慮）。	創業初期の採用が控除額 100 万円超につながる可能性を可視化（前期役員報酬のみ → 今期採用で増加率 100% 超のシナリオ）。採用タイミングの最適化判断をデータで支援。MAS-041（繰越欠損金）とは別枠で賃上げ促進特化	控除上限算出に必要な「法人税額」の取得方法（実績入力 or 予測値）、教育訓練費・女性活躍等の加算要件のスコープ、税制改正への追従タイミングと対応責任者の決定（毎年 3 月法案成立 → 7 月料率更新サイクル）
MAS-050	Story	—	投資回収期間ベンチマーク比較機能（D.10 派生）	FP&A 改善	P2.5	★★	未着手	—	D.10 §2, §4 抽出案件。D.10 記載の職種別・投資対象別 Payback ベンチマーク値を `18_mst_kpi_benchmark`（仮採番・要変更: MAS-044 で `18_tmpl_hc_position` 確定済のため衝突。実装着手時に別番号を採番すること）で DDL 管理。MAS-013 の計算結果シート `30_bud_investment_case` と自動照合し「業界標準比」評価ラベルを付与。評価結果の出力先は要調査（`mas/600_report/` レイヤーの既存ファイル `601〜608` の空き番または既存ファイルへの追記を確認すること）。	自社投資効率の客観的評価。「この回収期間は業界水準と比較して妥当か」をデータで即答可能に。MAS-013 は NPV/IRR/Payback 計算エンジン、本案件は計算結果を「評価」する機能。MAS-042（ハードルレート = 社内基準）と異なり、業界ベンチマーク（社外基準）比較	ベンチマークデータの出典と更新頻度（D.10 の数値は定点観測か）、評価ラベルの閾値設計（例: 「早い」= ベンチマーク 75 パーセンタイル以下）、ベンチマーク未存在カテゴリーの扱い、シート番号の確定（MAS-044 の `18_tmpl_hc_position` と衝突する可能性）
MAS-051	Story	—	PSF 特化 KPI ダッシュボード（D.8 派生）	FP&A	P2.5	★★	未着手	—	D.8 §4.4 抽出案件。`420_project_profitability.js` から Billable Utilization・Realization Rate を集計し `93_kpi_dashboard` に追加。データソース `27_bud_resource` は要調査（CLAUDE.md 未記載シート。MAS-218 Time Tracking 導入前の暫定データソースを別途検討）。SPI Research 2025 ベンチマーク値（Utilization 68.9% / EBITDA 9.8% 等）は MAS-050 で作成する `18_mst_kpi_benchmark` に統合して管理。	ブティックファームの経営健全性を業界標準と比較評価。稼働率・利益率の改善目標設定に活用。MAS-003（汎用経営指標）と異なり Billable Utilization・Revenue per Consultant 等 PSF 業態特有の KPI を追加する特化型ダッシュボード拡張	`27_bud_resource` の代替データソース特定（MAS-218 導入まで工数データをどこから取得するか）、Billable Utilization の計算定義（有給・学習時間の除外ルール）、ベンチマーク値の年次更新フロー、MAS-043 との整合運用（RICE/VALUE/SEED 配分表示との棲み分け）
MAS-052	Story	—	軽量版 Stage-Gate ワークフロー（D.8 派生）	FP&A 改善	P3	★	未着手	—	D.8 §5.4 抽出案件。`30_bud_investment_case` に `stage` 列（値域: ACTIVE / REVIEW / CLOSED の 3 段階 ← 1 人法人向けに 5 段階から簡略化）を DDL で追加（`101_sys_config.js` 更新）。`onEdit` トリガーでステージ変更時に変更ログを記録（書き込み先シートは要調査: `802_audit.js` が実際に使用しているシート名を確認）。ゲート条件はセル内コメントで管理。	投資案件のライフサイクル可視化と Kill 閾値の運用基盤。1 人法人では形式的なゲートレビューより「いつ止めるか」の基準設定が主目的。MAS-047（投資開始前の優先順位付け）と異なり、本案件は開始後の進捗管理	REVIEW ゲートの判定基準（KPI 達成率 or 経過期間）、CLOSED への遷移権限（1 人法人ではトリガー変更者 = 承認者で問題ないか）、`802_audit.js` 書き込み先シート名の事前確認、MAS-042 のハードルレート判定を REVIEW ゲートの自動判定に応用する拡張の将来検討
MAS-054	Story	🧠 Domain	Monte Carlo シミュレーションエンジン（D.8 派生）	シミュレーション	P3	★	未着手	—	D.8 §6.5 抽出案件。MAS-053 は欠番（1 人目採用前フェーズで premature として削除、論点は MAS-048 に吸収）。`mas/400_domain/` に新規ファイルで Monte Carlo エンジンを実装。三角分布ベースの乱数生成を純粋 JavaScript（`Math.random()`）で 1,000 回実行し営業利益の確率分布（p10 / p50 / p90）を算出。GAS 6 分制限対策: `SpreadsheetApp` 呼び出しはシミュレーション後の結果書き込み 1 回のみとし、全反復をメモリ内処理（インメモリ処理で数秒以内完了の見込み）。結果は新規シートまたはダイアログで出力。試行回数は `03_sys_params` で可変設定。	固定 3 シナリオ分析より現実的なリスク評価。「営業利益がマイナスになる確率は X%」という確率論的示唆を提供。MAS-005（固定 3 シナリオ切替 UI）の上位互換として位置づけ	試行回数のデフォルト値と上限（上限超過時の警告）、入力 UI 設計（最小・最頻・最大値の入力とパラメータ数の上限）、結果可視化の形式（p 値テーブル推奨、ヒストグラムは要調査）、MAS-005 との統合 or 並列運用の判断
MAS-055	Story	💾 Data	SaaS カタログマスタ（MAS-044 から派生）	FP&A	P3	★★	未着手	—	MAS-011 の What-if SAAS_ADD で毎回手入力している SaaS 費用をマスタ化。新規シート: `19_tmpl_saas_catalog`（列: 有効フラグ / 管理ID / サービス名 / 費用科目 / 標準月額 / 決済ラグ(月) / 想定利用者数 / ベンダー / 備考、`MST_SAAS_TMPL` / DDL 管理）。Repository: `SaasTemplateRepository`（MAS-044 の `PositionTemplateRepository` と完全同型）。MAS-011 サイドバー拡張: SAAS_ADD ドライバーフォームに dropdown 追加で選択 → 全フィールド自動入力。SaaS 例: ChatGPT Team / Notion Plus / GitHub Team / AWS 基本枠 / Slack Pro / Figma / Zoom。2026-04-23 に MAS-044 から独立起票（main スペースの採用判断機能群への注力方針を反映し、MAS-044 の HC 部分と並列独立）。MAS-044 実装後に Repository パターンを流用して着手推奨	毎回手入力の手間削減、契約中 SaaS の一元管理、MAS-011 の実績ゼロ時フォールバック、MAS-044 と並列実装対称性（failure_patterns #25）を確保	マスタ更新頻度（契約改定のたび手動 or `23_bud_subscription` から自動生成）、利用者数列を持つか、ベンダー名正規化ルール（`12_mst_partner` の `UI用取引先名` 参照）、契約情報の機密性（MAS-200 個人情報保護連携）、複数契約プラン（月額 vs 年額）の管理 ID 採番、MAS-044 との運用統合（統合ダッシュボード検討）
MAS-056	Epic	—	一人社長の意思決定対話 UI（Web App + Chat + シナリオ管理、D.11 派生）	シミュレーション・UX	P2	★★★	仕様書完了	2026-04-24	→ 開発仕様書。D.11 の 9 ステップ財務意思決定プロセスを対話型 UI で実現する主力機能。スプレッドシート外の独立 Web アプリ（GAS `doGet(e)` ベース、MAS-245 の初のキラーユースケース）として提供。🔎 MAS-332 調査完了（2026-04-24・更新版で精緻化）: ①Chat UI 基盤=Vite + React (TS) + `vite-plugin-singlefile` で単一 HTML ビルド → `doGet` 返却、②通信=`google.script.run` + クライアント側ポーリング（GAS 側で重い AI 往復は時間差トリガー起動に逃がし、クライアントから数秒おきに `checkStatus(id)` を問い合わせ、30/60 秒タイムアウト完全回避）、③AI モデル=ハイブリッド構成（対話・ルーティング=Gemini 2.5 Flash $0.03〜$0.30 / $1.50 per 1M、複雑な財務 JSON 抽出・考察=Claude 3.7 Sonnet $3/$15 or Gemini 2.5 Pro $1.25-$2.50/$10-15）、④Tool Use オーケストレーション=クライアント（React）主導型「AI → React → GAS → React → AI」連鎖（GAS は 1 回 1 ツール実行で必ず Return）、⑤UX=カード並列型 UI（モバイルは横スワイプカルーセル）、シナリオは React State `[{scenarioId, title, drivers, metrics}, ...]` で明示管理、LLM には差分情報のみ注入（トークン節約・ハルシネーション予防）、⑥永続化=`40_scenario_registry`（親、空き確認済）+ `44_scenario_drivers`（子、Deep Research 推奨 41 は `41_trn_budget` 衝突のため 44 に修正）のハイブリッド、会話履歴本体は Drive JSON ファイルに保存し file_id を親テーブルに記録（セル 50,000 字制限回避）、⑦個人 B/S 統合=新規 `calculateOptimalCompensation()` で役員報酬を総当たり（Brute-force）探索、2026 年福井県料率（健保 9.71% / 介護 1.62% / 子ども子育て支援金 0.23%）+ 軽減税率 15%（800 万以下） + インボイス経過措置 70%控除（2026 年 10 月〜）を考慮した合算税コスト最小化、⑧機密情報=個人資産額を平文シート保存せず `PropertiesService.getUserProperties()` に保存した AES 暗号化キーで暗号化、⑨キャッシュ=`CacheService`（100KB/key・6 時間 TTL・In-memory）でマスタ事前ロード、⑩コスト試算=月額 1,000 円未満（Flash メイン 1 セッション 100K トークン → 数円、1 日 3 回 × 30 日）。⑪実装ロードマップ（計 4 ヶ月・週 10h 前提）: Phase 1 MVP (1.0 ヶ月) Vite+React 基盤 + Flash 連携 + MAS-048 採用 TCO のみ Tool 化（永続化なし）→ Phase 2 マルチ (1.5 ヶ月) MAS-011/MAS-013 統合 + カード並列 UI + 親子テーブル永続化 → Phase 3 統合 (1.0 ヶ月) 個人 B/S 統合 + Claude 3.7 ルーティング + MAS-045 連動 → Phase 4 最適化 (0.5 ヶ月) CacheService 高速化 + モバイル洗練。MAS-005 を吸収・再定義（固定 3 シナリオ切替 → 対話による任意数シナリオ管理）。MAS-054 Monte Carlo は拡張点。⚠️ 前提依存: MAS-232（Vite+React SPA 基盤）が Phase 1 の前提 → MAS-232 先行実装 or Phase 1 と統合着手の判断必要。	一人法人の「経営方針と数字を紐付ける」意思決定を AI 対話で支援（D.11 3 設計原則）。D.11 Step 9「個人 B/S + 法人 B/S 統合」論点を単独案件化せず本機能に吸収。MAS-005 の固定シナリオ UI を置き換え、MAS-011/MAS-013/MAS-048 の計算エンジンを会話から横断呼び出しする「意思決定ハブ」になる。商用化後の最大の差別化機能（MAS-332 でも「一人法人 × 個人 B/S 統合」は SaaS 空白領域と確認、Causal/Runway は法人単体のみ）	✅ MAS-332 にて主要 8 論点は調査済（更新版 2026-04-24）。本格仕様書で確定すべき 10 項目（Deep Research チェックリスト）: ①Vite + React (TS) + `vite-plugin-singlefile` で進めるか、②ポーリング制御実装に同意するか、③Flash + Claude 3.7 / Pro のハイブリッドルーティング vs 単一統一、④「AI → React → GAS → React → AI」クライアント仲介連鎖に同意するか、⑤カード並列型 UI（モバイル横スワイプ）採用、⑥`40_scenario_registry` + `41_scenario_drivers`（→ 44 に修正要）親子構造新設、⑦会話履歴を Drive JSON 保存でよいか、⑧個人資産を `PropertiesService` で暗号化するか、⑨2026 年福井県料率 + インボイス 70%控除を前提とするか、⑩Phase 1（MVP）は MAS-048 単一対話のみに集中するか。+ Claude 追記 9 点: ①シート 41 衝突回避（44 に修正、↑反映）、②MAS-232 先行実装の優先度引き上げ（Phase 1 前提基盤）、③MAS-005 吸収の明記タイミング、④MAS-045 実装順序（Phase 1 前 or Phase 3 統合時）、⑤ポーリング周期既定値（2/5/10 秒）、⑥AI モデルルーティング閾値設計（system prompt vs Router 関数）、⑦個人 B/S データ MAS-200 アクセス制御・監査ログ、⑧Flash 精度不足時の Sonnet フォールバック UI（明示切替 vs サイレント）、⑨時間差トリガー結果保存先（CacheService vs 専用シート）と 6 時間 TTL 切れの扱い
MAS-057	Epic	—	Solo-CEO Financial Navigator アンブレラ（BRD 派生・MAS-056 / MAS-011 / MAS-013 / MAS-048 / MAS-141 統括）	シミュレーション・UX	P2	★★★	Phase 3 + Step 6 完了	2026-04-28	→ 開発仕様書 / ✅ 全 Phase + Step 6 完了: Phase 1 (PR #354) + Phase 1.5 (PR #356) + Phase 2 (PR #360) + Phase 3 (PR #379・2026-04-27・Vite+React SPA・主要 4 ドロップダウン + サンキー D3 + 5 カ年チャート Chart.js + AI インサイト Vertex Gemini モデルセレクタ + Deep Think トグル) + Step 6 (PR #394・2026-04-27・33 コミット・spec 未記載機能を 15 項目以上追加実装・spec v2.1 として整合追従済)。Step 6.1〜6.15 細項目: (6.1) 3 区分テーブル基本構造 + 法人負担詳細 4-5 行展開 + サンキー副次化 / (6.2) Y1-Y5 単年タブ / (6.3) ~~Y1-~~Y5 累積セクション (累積純資産 + 累積負担金額 + 平均実効税率 + 平均実効負担率 + 節税金額) / (6.4) 実効税率 (税理士定義 ETR) + 実効負担率 (社保込み売上比) 併記 / (6.5) 生命保険料 + 損金算入率 4 段階 (法人税基本通達 9-3-5・2019/7 改正準拠・100%/60%/40%/0%) / (6.6) 社長稼働限界 Burnout メーター (Gemini Deep Think MAS-334 Section MAS-239 発見の先行実装・100% 超で🔴 物理破綻ゾーン警告) / (6.7) 純資産 3 用途分解 (💵 流動 / 🏛️ 老後 / 🛡️ 万一) / (6.8) 創業費 + 初年度フラグ + 月数按分 (繰延資産だが簡易扱いで全額一括損金) / (6.9) シナリオ・前提条件 localStorage 二系統保存 (`f57_cockpit_scenarios_v1` / `f57_cockpit_assumptions_v1`・「前提 × シナリオ」マトリクス試算可能・旧スキーマ migration) / (6.10) 前提条件 (黄系・16 項目) と入力 (灰系・Variables 7 項目) のセクション分離 / (6.11) 月単位入力 + 変動費比率 (cogsRate ラベルを「経費比率（外注費含む・人件費除く）」に明示・2.5% 単位 29 段階に細粒度化) / (6.12) 月額報酬の年次増加額 / (6.13) 役員報酬最低月額 (Gemini Deep Think MAS-334 発見の先行実装・default 30 万・AI インサイト制約活用は v2.2 候補) / (6.14) 法人期首預金残高 + 住宅ローン減税 (2022 年改正後制度・所得税控除しきれない分を住民税からも控除) / (6.15) 想定貢献月商の参考表示 (`AssumptionsPanel` read-only + `CompensationDropdowns` の「想定値」ボタン)。簡易実装の明示 (注意事項 #20): 住宅ローン減税は年額固定 × 5 年 (本来残高×0.7%・13 年) / 老後備え個人は NISA・iDeCo 未対応 / 万一の備え給付倍率は払込総額 (実際 3-10 倍) / 退職所得控除 5 年/19 年ルール未実装 / 創業費全額一括損金。Step 6 新規追加ファイル: `webapp_client/src/cockpit/{AssumptionsPanel,AssumptionsStore,ScenarioBar,ScenarioStore,ThreeSectionTable}.tsx` 5 ファイル。クライアント計算 SSoT は `mas/400_domain/{442-445}.js` (`webapp_client/scripts/sync-engines.mjs` で同期 + window 露出方式・TypeScript 複製ゼロ)。仕様書 v2.1 で実装フィードバック反映済。`mas/400_domain/442_social_insurance_tier_engine.js`（239 → 339 行）: `SocialInsuranceTierEngine`（`findTier` / `calcPremiums` / `calcBonusPremiums`* / `calcBreakEvenPoint`）+ `PersonalTaxEngine` 別名前空間 + `17_mst_soci_tier` マスタ + `812_migration_f57_tier_seed.js`（番号 810→812 繰上・v1.5 で追従 PR #355）。Phase 1.5 `calcBonusPremiums` は賞与社会保険料計算（千円未満切り捨て・厚年 1 回上限 150 万・健保年累計上限 573 万・反復呼び出し対応）+ 単体テスト 18 件（F57-22〜F57-39）。BRD `docs/brd_solo_ceo_financial_navigator.md` 派生案件。MAS-056（意思決定対話 UI）が提供する Chat ベース UX を補完する「ドロップダウン + サンキーダイアグラム型のビジュアル財務コックピット」をアンブレラ仕様として定義（離散単位選択 UX、`ai_agent_tips.md §7` 準拠）し、1 人社長の「額面給与の最大化 → 純資産の最大化」へのパラダイムシフトを実現する。①新規追加要件（MAS-056 にないもの）: (a) 社会保険料の壁ロジック — 標準報酬月額等級表（健保 50 等級 / 厚年 32 等級・全国統一）を JSON マスタ化し、厚生年金上限（月収 65 万 = 標準報酬月額 65 万等級）を突破する戦略の損益分岐点を計算、(b) 法人 vs 個人税率のデッドヒート可視化 — 法人実効税率（軽減 15% / 標準 23.2%）vs 個人累進（所得税 5-45% + 住民税 10% + 社保 15% 相当）の交点をグラフ表示、(c) 社宅家賃 / 出張日当 / 共済積立のパラメータ化 — 社宅は税務上の賃貸料相当額（固定資産税評価ベース）+ 従業員負担割合から個人⇆法人移転効果を算出、日当は規程上限（出張日数×単価）を非課税枠として処理、共済は小規模企業共済（月 7 万・年 84 万・全額所得控除）+ 経営セーフティ共済（月 20 万・年 240 万・全額損金）、(d) ドロップダウン UI + サンキーダイアグラム — 役員報酬・社宅負担率・共済積立額の主要 3 ドロップダウン（離散単位・`ai_agent_tips.md §7` 準拠）、売上 → 経費 → 税 → 社保 → 手残りの流出をサンキーで可視化、(e) 5 カ年推移 + 複利効果 — 共済積立の所得控除効果、法人内部留保の運用益（`03_sys_params` で年利率設定可能）、(f) インサイトの自動提示 — 「役員報酬をあと N 万円下げると等級が M 下がり、合算手残りが X 万円増える」形式の構造化アドバイスを Gemini/Claude で生成。②既存案件との役割分担: MAS-056 = 対話 UI + `calculateOptimalCompensation()` コアエンジン（総当たり探索、本案件の社会保険料計算ロジックを流用）、MAS-011/MAS-013 = 5 カ年推移の計算エンジン、MAS-048 = 採用 TCO、MAS-141 = 共済節税効果の詳細ロジック。MAS-057 は UI 層 + BRD の全パラメータ網羅の統括。③アーキテクチャ方針: BRD §7「関心の分離」に従い、(a) Logic Layer = `mas/400_domain/442_social_insurance_tier_engine.js`（新規・標準報酬月額マスタ検索 + 壁突破 BEP 計算、純粋関数）、`mas/400_domain/443_corporate_housing_optimizer.js`（新規・社宅家賃の個人/法人按分計算）、`mas/400_domain/444_per_diem_policy_engine.js`（新規・出張規程ベース非課税日当計算）、(b) Parameter/Config Layer = `15_mst_social_insurance_tier`（標準報酬月額等級表・DDL 管理・全国一律）+ `03_sys_params` 拡張（`F57_` キー群）、(c) Presentation Layer* = MAS-056 の `conversational_ui.html` に「ビジュアルコックピット」タブを追加 or 独立 Web App として `mas/templates/financial_cockpit.html` を新設（要判断）。④新規シート番号の確保（v1.1 更新・grep 確認済・2026-04-24）: v1.1 Critical 2 で所得税テーブルは Constants 化（`20_mst_income_tax_bracket` 廃止）。既使用 = `11_mst_account` / `12_mst_partner` / `14_mst_project` / `15_mst_dictionary` / `16_wrk_master` / `18_tmpl_hc_position` / `19_tmpl_saas_catalog`（MAS-055 計画）/ `21-28` 全て bud 系で使用済 / `29_mst_investment_hurdle`（MAS-042）。本案件は `17_mst_soci_tier`（健保 50 + 厚年 32 = 82 行の等級マスタ・全国一律）、`13_tmpl_per_diem_policy`（出張日当規程テンプレ）の 2 シートのみ採番。⑤税制パラメータ集中管理: 2026 年福井県料率（MAS-056 で既に `F56_FUKUI_` キーで管理）を本案件では `F57_` にコピーせず MAS-056 のキーを参照（DRY 原則）。累進税率表は `Constants.INCOME_TAX_BRACKETS` 定数で管理（v1.1 反映・法人税 `TAX_RATES.brackets` と対称）、毎年 3 月税制改正後に `002_constants.js` を直接更新。⑥サンプルデータ（BRD §8 齋藤ケース）: 年商 1,680 万 / 原価 0 / 固定費 240 万 / 役員報酬月 50 万を Baseline とし、役員報酬を月 25 万〜85 万で 5 万刻みスキャン（13 パターン）→ 法人手残り + 個人手残り + 合算純資産の推移表を標準出力とする。⑦前提依存: MAS-056 Phase 3（個人 B/S 統合）完了後に着手推奨（`calculateOptimalCompensation()` エンジン成熟後）。MAS-232（Vite+React SPA 基盤）も前提。MAS-011/MAS-013 の 5 カ年シミュレーションエンジン完了後に連動。⑧実装ロードマップ（計 3 ヶ月・週 10h 前提）: Phase 1 (1.0 ヶ月) 社会保険料壁エンジン + 等級表マスタ + 単体テスト、Phase 2 (1.0 ヶ月) 社宅/日当/共済の追加パラメータ統合 + MAS-056 対話 UI 拡張、Phase 3 (1.0 ヶ月) ドロップダウン + サンキー UI + インサイト自動提示 + 5 カ年推移統合（`ai_agent_tips.md §7` 準拠）。	BRD 全体（Solo-CEO Financial Navigator）のエントリポイントとしてスコープ管理。MAS-056（対話 UX）/ MAS-011/MAS-013/MAS-048（計算エンジン）/ MAS-141（共済節税）の個別案件を「1 人社長の純資産最大化」という単一の経営課題に束ね、機能重複・抜け漏れを可視化。BRD §6 UX 戦略（ドロップダウン・リアルタイム・サンキー・インサイト・`ai_agent_tips.md §7` 準拠）を具体化することで、MAS-056 の対話 UI では届きにくい「数字で見て直感的に動かす」ペルソナ（データ型・視覚優位の経営者）にも対応する第 2 の UX レイヤーを提供。商用化時は MAS-056 と MAS-057 が「Chat UI タブ」「Visual Cockpit タブ」として共存する Web アプリとなり、BRD Vision の「財務のコックピット」を完成させる	Deep Research 推奨 10 論点: ①MAS-056 と MAS-057 の UI 統合形態（単一 Web App 内タブ切替 vs 独立 Web App 2 つ）、②標準報酬月額マスタを DDL 管理（`15_mst_social_insurance_tier`）とする場合の番号空き確認と年次更新フロー、③社宅家賃の賃貸料相当額計算ロジック（固定資産税評価額ベース vs 簡便法 50%）の採用基準、④出張日当の規程テンプレ化の深さ（単価固定 vs 距離・宿泊有無別テーブル）、⑤小規模企業共済 + 経営セーフティ共済の「解約時益金算入リスク」を本 UI で警告表示するか（MAS-141 との役割分担）、⑥累進税率テーブルを DDL（`16_mst_income_tax_bracket`）で管理 vs JSON ファイル（`docs/_internal/tax_rates_2026.json` 等）で管理、⑦サンキーダイアグラムライブラリ選定（D3.js vs Plotly vs Chart.js サンキー拡張）、⑧5 カ年推移の法人内部留保運用益率の既定値（0% vs 3% vs 5%）と設定方法、⑨インサイト自動提示のアルゴリズム（ルールベース vs LLM 生成 vs ハイブリッド）と MAS-056 対話 UI との統合方式、⑩「額面 → 手残り」パラダイムシフトのオンボーディング UX（初回起動時のチュートリアルダイアログ要否）。+ Claude 追記検討事項: ①MAS-056 `calculateOptimalCompensation()` をリファクタしてコアエンジンを `mas/400_domain/442_social_insurance_tier_engine.js` に切り出すか否か（リスク: MAS-056 実装に手戻り）、②本案件着手時点で MAS-056 Phase 3 が完了しているかの前提確認、③`15_mst_social_insurance_tier` は全国共通か都道府県別か（健保料率は都道府県別だが等級境界は全国一律）、④経営セーフティ共済は 2024/10 改正で解約後 2 年以内再加入は損金算入不可となった点を UI 上の警告として表示するか、⑤BRD に明記の齋藤ケース（Baseline: 年商 1680 万・役員報酬 50 万）は本仕様書の「実データ検証」セクションに必ずサンプル計算として記載し、手残り最大化ポイントを数値で証明する。
MAS-058	Story	🧠 Domain	希望年収逆算型必要年商シミュレーター（MAS-057 逆方向・財務健全性制約ソルバー）	シミュレーション	P2	★★	仕様書完了	2026-04-25	→ 開発仕様書 / v1.0 (442 行・章単位 Edit 方式で idle timeout ゼロで完走)。MAS-057 の逆問題。MAS-057 が「年商・原価・固定費・年収 → 手取り最適化」の順方向なのに対し、本案件は「希望年収 Y1-Y5 + 健全性制約 → 必要年商・必要粗利率・必要人月単価」を逆算する。①想定ユースケース: (a) コンサル/受託開発の一人社長が「Y5 で年収 1,200 万円を目指すなら最低年商はいくら必要か」を即座に試算、(b) 5 カ年で段階的に年収を上げる前提で各年の最低年商ラインと健全圏ラインを提示、(c) 原価率（受託なら外注費・コンサルなら 0%）をパラメータ化。②健全性制約（4 条件の同時充足）: (1) P/L 黒字（年商 − 原価 − 固定費 − 役員報酬 − 法人社保 − 法人税 > 0）、(2) ランウェイ ≥ N ヶ月（`03_sys_params` で設定・default 6、`MAS-008` の KPI と整合）、(3) 税引後留保率 ≥ X%（default 20% 内部留保・緊急予備）、(4) 労働分配率（役員報酬 ÷ 粗利） ≤ Y%（default 50%・`MAS-003` の KPI 閾値）。③3 段階出力: (a) Minimum（赤字化しない下限年商）、(b) Healthy（制約 (1)-(4) 全充足）、(c) Buffered（Healthy + 緩衝 20%）。各年それぞれ算出。④コンサル/受託特有の示唆: 必要粗利率から逆算して「必要人月単価」（1 人月あたり必要売上額）を提示。例: Y5 年商 3,000 万必要 / 稼働月 10 ヶ月 → 月単価 300 万/人月。営業力・顧客ポートフォリオ設計の判断材料。⑤新規ファイル: `mas/400_domain/445_required_revenue_solver.js`（新規・純粋関数・MAS-057 の `SocialInsuranceTierEngine` + `PersonalTaxEngine` + `Constants.TAX_RATES` を逆順で呼ぶソルバー・二分探索 or 解析解）。`03_sys_params` に `F58_RUNWAY_MIN_MONTHS` / `F58_RETENTION_RATE` / `F58_LABOR_SHARE_MAX` / `F58_BUFFER_RATE` の 4 キーを追加。⑥前提依存: MAS-057 Phase 1/1.5（✅ 完了 = 社保・税計算エンジン）/ Constants.TAX_RATES（既存）/ Constants.INCOME_TAX_BRACKETS（MAS-057 Phase 1 で新設済）。⑦MAS-056 連携: MAS-056 対話 UI から「年収 1,200 万目指したい」→ 本ソルバーが必要年商 3 段階を返す Tool として登録。⑧MAS-057 Phase 3 との統合: Phase 3 ドロップダウン UI（`ai_agent_tips.md §7` 準拠）に「年商も逆算する」切替 toggle を追加 → 本ソルバー呼出で Minimum/Healthy/Buffered を表示。⑨テスト: 齋藤 Baseline（固定費 240 万・原価 0）で以下の期待値を単体テスト化: Y1 年収 600 → 必要年商 Minimum 約 1,000 万 / Healthy 約 1,680 万（実績） / Buffered 約 2,000 万、Y5 年収 1,200 → Minimum 約 1,720 万 / Healthy 約 2,400 万 / Buffered 約 2,880 万（概算・実装時に精緻化）。⑩起票経緯: 2026-04-25 web ワークスペースで MAS-057 5 カ年シミュレーションの検討時、「コンサル/受託売上前提で健全な財務体質を維持しつつ希望年収を取れる年商水準を推測する仕様が欠けている」とユーザー指摘。MAS-024 BEP（一般 P/L 損益分岐）/ MAS-012 目標逆算人員計画（売上→人員）/ MAS-048 採用 TCO BEP（採用→必要売上）はいずれも類似するが、役員報酬を変数扱いした財務健全性制約下の逆ソルバーは空白領域。	コンサル/受託一人社長の「どこまで営業を伸ばせば希望年収を実現できるか」を即座に可視化。MAS-057 は「与えられた年商で年収をどう取るか」、本案件は「希望年収を実現するために年商をいくら取るか」の相補関係。5 カ年の成長軌跡を引く際の目標年商設定のアンカーとして機能。コンサル業態では必要人月単価が営業力・案件ポートフォリオ設計の判断基準になる	健全性制約 4 条件のデフォルト値（ランウェイ 6/12/24 ヶ月のどれが標準か）、原価率の入力粒度（単一値 or 年別推移）、労働分配率の閾値（50% は一般論・コンサル業態では適正か要調整）、「必要人月単価」の算出における稼働月数の前提（10/11/12 のどれを default にするか）、MAS-056 対話 UI への Tool 登録タイミング（Phase 1 MVP で含めるか Phase 2 以降か）、ソルバーアルゴリズム（二分探索か解析解か・収束保証）、MAS-008 ランウェイ計算ロジックとの統合方式、MAS-057 Phase 3 ドロップダウン UI への toggle 追加 vs 独立メニュー化のどちらが UX 上自然か、仕様書起票タイミング（MAS-057 Phase 2 着手時 or Phase 3 UI 設計時）
MAS-059	Epic	🌐 Cross	一人法人成長計画ワークスペース（統合意思決定ツリー UI・F-57b 候補の具体化）	シミュレーション・UX	P2	★★★	未着手	—	🔎 MAS-333 完了 (2026-04-25 / Claude Research × Gemini Deep Research 突合): 推奨スタック確定 = LangGraph + Cloud SQL Postgres checkpointer (※Firestore 公式 checkpointer 不在のため変更) + LangSmith + Vertex AI Gemini 1.5 Pro (月 $56-95)。真のツリー UI は世界の主要 FP&A SaaS で誰一人採用していないため Runway 型カード並列 UI + Progressive Disclosure 採用に方針変更。Causal AI = DAG 思考フレームのみ採用、do-calculus エンジンは v1 不採用 (arXiv 2506.00844 等で SMB データ N<100 では推定誤差大と否定)。LLM は計算結果を復唱せず Function Calling で取得した数値を UI 直接渡し (Air Canada v. Moffatt 型責任回避)。HITL = 金額閾値 (役員報酬±20% / 資金調達 / 採用 1 名以上は強制) + Autonomy Slider (Conservative/Balanced/Autonomous)。差別化 3 機会の確証: ①日本社会保険料壁ロジック ②個人 B/S × 法人 B/S 統合 ③ソロ CEO 年収最適化はいずれも世界空白。詳細は `docs/_internal/research_prompts/RQ-035__synthesis.md`。MAS-056（Chat UX）/ MAS-057（ドロップダウン UX・`ai_agent_tips.md §7` 準拠）/ MAS-058（逆算ソルバー）/ MAS-012 / MAS-048 / MAS-017 を連鎖オーケストレーションする意思決定ツリー層。既存の個別機能は「点」で完成度が高いが、「希望報酬 → 必要売上 → 人員計画 → 採用投資可否 → 資金調達 or 計画調整」という試行錯誤ループ全体を 1 画面で回せる UI/ロジックは空白領域。F-57b 候補（2026-04-24 会話で合意された左右分割ワークスペース UI）の具体化案件として位置付ける。①想定ワークフロー: (a) ユーザーが Y1-Y5 の希望年収を入力 → MAS-058* で必要年商 (Min/Healthy/Buffered) 逆算、(b) Healthy 年商を MAS-012 に渡して必要人員・採用タイミングを逆算、(c) 採用計画を MAS-048 で TCO 計算し採用月別の CF 影響をシミュレーション、(d) CF が制約違反（ランウェイ < 6 ヶ月 or 緊急予備 < 3 ヶ月）なら以下のサジェストを自動提示: [i] MAS-017 資金調達シミュレーションで融資額/タイミング逆算、[ii] MAS-011 What-if で計画後ろ倒し（採用遅延・年収軌跡下方）、[iii] MAS-058 再逆算で希望年収を現実レベルに下方修正、(e) ユーザーが選択 → 分岐シナリオを MAS-056 のマルチシナリオ永続化に保存、(f) 再度 (a) からループ。②新規実装: `mas/400_domain/446_decision_tree_orchestrator.js`（新規・意思決定ツリーのオーケストレーション・各仕様書の計算エンジンを順次呼出・制約違反を検知して Next Actions を返却する純粋関数）。UI 層は F-57b 候補の左右分割ワークスペースとして MAS-232 Stage 2 以降の SPA 基盤上に実装（右パネル = 操作・入力 / 左パネル = 意思決定ツリー可視化 + シナリオ比較 + AI インサイト）。③サジェストエンジン: 制約違反の種類 → 推奨 Next Action の判定ルール（例: 採用 BEP > 12 ヶ月 → 資金調達検討、営業 CF < 0 → 年収下方 or 原価削減、人月単価 > 300 万 → 案件ポートフォリオ見直し）をルールベース or LLM ハイブリッドで実装。`callClaudeApiOnVertex_` でユーザー選好を読み取った自然言語提案も併用。④シナリオ分岐管理: MAS-056 の `40_scenario_registry` + `44_scenario_drivers` に「親シナリオ ID」列を追加し、分岐ツリーを再現可能にする。各シナリオは (年収軌跡・採用計画・資金調達額・計画開始月) の 4 ディメンションをスナップショット保存。⑤前提依存: MAS-056 Phase 2 完了（マルチシナリオ永続化 + MAS-048 Tool 化）/ MAS-057 Phase 3 完了（ドロップダウン UX + 個人 B/S 統合）/ MAS-058 実装完了（逆算ソルバー）/ MAS-017 実装（資金調達シミュレーション・P3 未着手）/ MAS-232 Stage 2 完了（SPA 基盤・✅ 2026-04-25 PR #363）。⑥実装タイミング: 前提 5 件のうち MAS-017 以外は仕様書完了済。MAS-017 仕様書起票と本案件キックオフを同時期に行うのが筋。前提揃う想定: 2026 Q3 以降。⑦起票経緯: 2026-04-25 web ワークスペースで「希望報酬 → 必要売上 → 人員計画 → 採用投資可否 → 資金調達 or 計画後ろ倒しの試行錯誤」をユーザーが明示的に要望。既存の個別機能では連鎖オーケストレーション層が空白。新案件 MAS-059 として切出。F-57b 候補（左右分割ワークスペース UI）の具体化形にもなる。	商用化後の最大の差別化機能（UI レイヤー）。MAS-056 Chat と MAS-057 ドロップダウンは「個別の意思決定を支援する道具」だが、MAS-059 は「意思決定ループ全体を駆動するオーケストレーター」。一人法人の「希望年収実現までの道のりを数値と画面で探索する」経営体験を提供。MAS-057 BRD Vision「財務のコックピット」の完成形	F-57b 候補と MAS-059 の統合方針（MAS-059 = F-57b 正式案件化 or 別レイヤーか）、左右分割 UI のレスポンシブ対応（モバイルで縦分割 or 横スワイプ切替）、意思決定ツリーの可視化ライブラリ選定（D3.js / React Flow / 自作）、サジェストエンジンのアルゴリズム（ルールベース vs LLM vs ハイブリッド）、制約違反時の「どの Next Action を提示するか」の優先順位設計、シナリオ分岐ツリーの世代管理（無限分岐防止の深さ制限）、MAS-056 `40_scenario_registry` の親シナリオ ID 列追加の後方互換性、商用化時のマルチテナント対応（MAS-219 ADR-0009 テナント抽象化との整合）、MAS-017 資金調達シミュレーションの先行実装の必要性、仕様書起票タイミング（MAS-057 Phase 3 着手時 or MAS-017 仕様書作成と同時か）、計画後ろ倒しの UX 設計（タイムライン上でドラッグ操作にするか数値入力にするか）
MAS-060	Story	🧠 Domain	組織構成シミュレーター（役員 / 従業員 / 業務委託の比率最適化）	シミュレーション・組織	P2	★★	未着手	—	企業規模拡大時（SZ-1 → SZ-2 → SZ-3）の組織ミックス最適化。既存の MAS-012（人員逆算）/ MAS-044（ポジションテンプレ）/ MAS-048（採用 TCO）/ MAS-049（賃上げ税制）/ MAS-057（社保ロジック・代表役員のみ）はいずれも「個別の役職を扱う」前提で、「役員 / 従業員 / 業務委託の比率最適化」を扱う仕様は空白領域。新案件 MAS-060 として独立起票。①入力次元: (a) 役職タイプ 7 種（代表役員 / その他役員 / 正社員 / 契約社員 / 業務委託（個人）/ 業務委託（法人）/ アルバイト・パート）、(b) 目標規模 5/10/30 名等（SZ-1〜SZ-4 連動）、(c) 業種前提（BZ-1 コンサル / BZ-2 SaaS / BZ-5 ハイブリッド・use_cases.md v1.2 連動）、(d) Y1-Y5 各年で異なるミックス。②役職別コスト構造の差: 代表役員 = 役員報酬 + 法人社保 + 法定福利費（MAS-057 既存）、その他役員 = 同上 + 取締役会対応・株主総会、正社員 = 給与 + 社保 + 雇保 + 退職金引当 + 採用、契約社員 = 同上短期 + 5 年無期転換ルール、業務委託（個人）= 外注費（社保なし）+ インボイス影響 + 偽装請負リスク + フリーランス新法（MAS-143）、業務委託（法人）= 同上 + インボイス T 番号控除、アルバイト = 時給 × 時間 + 130/106 万の壁。③出力（MAS-058 風 3 段階 + ミックス推奨）: コスト合計 / 月別 CF 影響 / 税務最適化指数（MAS-049 賃上げ + MAS-218 R&D 連動）/ リスクスコア（偽装請負 + 解雇規制 + 社保適用拡大）/ 3 段階推奨ミックス（保守型: 社員多め・固定費高・低リスク / バランス型: 推奨 / アグレッシブ型: 業務委託多め・変動費高・スピード優先）/ 必要売上（MAS-058 連携で再計算）。④新規実装: `mas/400_domain/447_workforce_mix_optimizer.js`（純粋関数・組合せ最適化・探索的か発見的かは仕様化時に決定）。`03_sys_params` に `F60_` キー追加（業務委託比率上限 / 役員報酬上限率 / 賃上げ税制適用閾値等）。⑤連携先: MAS-012（必要 HC 総数 → ミックス内訳提案）/ MAS-044（ポジションテンプレに「役職タイプ」次元追加）/ MAS-048（役職タイプ別 TCO 分岐）/ MAS-049（給与増加額の集計範囲 = 業務委託除外）/ MAS-057（代表役員報酬は委譲）/ MAS-058（コスト合計 → 必要年商再計算）/ MAS-059（意思決定ツリー Tool 登録）/ MAS-143（フリーランス新法リスクスコア参照）。⑥前提依存: MAS-012（✅完了）/ MAS-044（✅完了）/ MAS-048（✅完了）/ MAS-049（✅完了）/ MAS-058（📝仕様書完了 v1.1）/ MAS-143（📝仕様書完了）。前提案件は揃っているためMAS-058 実装後に着手可能。MAS-059 とは並行起草可能（MAS-059 が MAS-060 を Tool として呼び出す関係）。⑦想定ユースケース: SZ-1 → SZ-2 遷移期の経営者が「初採用は正社員 vs 業務委託どちらか / 業務委託 1 名 + 正社員 1 名のミックス効果 / 5 名体制での最適配分」を即座に試算。⑧起票経緯*: 2026-04-25 ユーザー要望「自分だけじゃなく企業の規模が増えてきた時の他の役員・従業員・業務委託等の比率のシミュレーションもできたらいい」を受け、SZ-1 → SZ-2/SZ-3 遷移期の組織ミックス最適化が既存仕様空白領域と確認。新案件 MAS-060 として切出。	企業規模拡大時の組織ミックス最適化を SaaS 化。既存の海外 FP&A SaaS（Pigment/Causal/Runway）は HC 配分を扱うが、日本の業務委託（インボイス影響・フリーランス新法）と社員（社保適用拡大）の非対称性を扱える製品は不在。bizlp の差別化機会の追加カード	役職タイプ 7 種の細分化粒度（アルバイトは含めるか・契約社員と正社員を分けるか）、業務委託の偽装請負リスクスコアの定量化方法（労務管理研究所等のチェックリストをスコア化するか）、最適化アルゴリズム（探索的 = 全パターン総当たり vs 発見的 = ヒューリスティック）、MAS-044 ポジションテンプレへの「役職タイプ」次元追加の後方互換性、賃上げ税制適用範囲の集計境界（業務委託は除外明示）、フリーランス新法（MAS-143）の発効日と仕様反映タイミング、MAS-059 意思決定ツリーへの Tool 登録時の HITL 強制条件（採用 1 名以上で強制 HITL 維持か）、商用化時のマルチテナント対応（テナント別の業種・規模プリセット）
MAS-061	Story	🧠 Domain	キャッシュ実効税率（Cash ETR）トラッキング機能（合法節税範囲・税負担抑制案サジェスト）	FP&A・税務分析	P2	★★	未着手	—	法定実効税率（約 34%）と実際のキャッシュアウト税率（中小法人軽減税率・税額控除・繰越欠損金等の効果反映後）の乖離を継続トラッキング。節税施策の費用対効果検証および中期キャッシュフロー予測の精度向上に活用。直接の用途 2 つ: (a) 節税設計の効果測定 = 小規模企業共済・経営セーフティ共済・賃上げ促進税制・研究開発税制等の各施策が Cash ETR をどれだけ圧縮できているかを定量化、(b) ランウェイ計算の精度向上 = 月次キャッシュアウトに税金支払を組み込み、より現実的な残月数を算出（MAS-008 連携）。①計算式の二系統実装: 系統 A (Cash Tax Rate) = 実際の納付日ベースで集計した税金キャッシュアウト ÷ 税引前当期純利益 / 系統 B (Effective Tax Rate) = 当期事業年度に帰属する税金（未払計上含む）÷ 税引前当期純利益。系統 B をダッシュボードのデフォルト、系統 A はドリルダウンで提供。②分子の構成: 法人税（国税）+ 地方法人税 + 法人住民税（法人税割 + 均等割）+ 法人事業税 + 特別法人事業税の合計。消費税（預り金性質）と源泉所得税（前払法人税）は分子から除外する判定ロジックを実装。③仕訳データからの自動抽出: 既存会計仕訳から `tax_payment` フラグまたは勘定科目（法人税等 / 租税公課のうち所得課税分）でフィルタし、`TaxPayment` レコード（date, taxType, amount, fiscalYearApplied）として正規化。前提タスク: 勘定科目マスタ（11_mst_account）への「税目分類」属性追加 OR 別マスタ `12_mst_tax_classification` の新設（DDL 拡張・実装着手前に Step 0 として完了必須）。④3 年移動平均（Normalized Cash ETR）: Σ(過去 3 年税金キャッシュアウト) ÷ Σ(過去 3 年税引前利益) を算出（4 年目以降に有効化、創業初期は単年運用）。⑤期ズレ補正: 中間納付と確定納付の期ズレ（X1 期確定分が X2 期 5 月納付等）を fiscalYearApplied フィールドで明示管理。⑥ダッシュボード統合: 既存 `93_kpi_dashboard`（MAS-003 完了）に `tax_paid_cumulative_fy` / `pretax_profit_cumulative_fy` / `cash_etr_ytd` の 3 フィールドを追加 OR 新設 `40_KPIMonthly` シートに分離（仕様化時に判断）。条件付き書式で信号機表示（🟢<20% / 🟡20-30% / 🔴>30%）+ 極端に低い期は翌期反動の警告アノテーション（繰越欠損金食い潰しの跳ね返り検知）。GCP 移行後（PH-4）は Looker Studio スコアカードでも同等表示。⑦予測 Cash ETR: 翌期の予想 Cash ETR を節税施策プランから逆算するシミュレーション機能（共済掛金額・役員報酬水準・税額控除見込みをパラメータに）。MAS-058/MAS-059 と連携して意思決定ツリーの一要素化。⑧合法節税の優先順位サジェスト: 当期想定 PL + 個人 B/S + ライフイベントを入力に、節税策の優先順位付きリスト（合法範囲のみ）を出力。連携策: 賃上げ税制控除（MAS-049 ✅）/ R&D 税制控除（MAS-218 + 計算機能新設）/ 繰越欠損金活用（MAS-041 📝）/ 小規模企業共済（MAS-141 📝・月 7 万・年 84 万・全額所得控除）/ 経営セーフティ共済（MAS-141 📝・月 20 万・年 240 万・全額損金）/ 役員報酬最適化（MAS-057/MAS-058）/ 社宅家賃按分（MAS-057 §4.3）/ 出張日当規程（MAS-057 §4.3）/ 法人 vs 個人税率最適化（MAS-057 §3.2 デッドヒート）/ 中小企業軽減税率活用（800 万境界）/ 設備投資減税（MAS-013 + 検討）。⑨ガードレール（脱税範囲を絶対提示しない）: 租税回避行為（同族会社の行為計算否認・法人税法 132 条）警告 / 国税通則法 68 条重加算税相当の警告 / 過大役員給与認定リスク（MAS-057 既存ロジック延長）/ 業務委託の偽装請負リスク（MAS-060 連携）/ 海外移転価格・タックスヘイブン回避（スコープ外として明示）/ Disclaimer 必須「本提案は税理士の個別助言に代わるものではない」。⑩新規実装: `mas/400_domain/448_cash_etr_simulator.js`（純粋関数・既存税務エンジン群を順次呼び出して統合指標を算出）+ `mas/200_data/202_repository.js` に `TaxPaymentRepository` 追加 + `mas/100_config/101_sys_config.js` に `tax_classification` マスタ DDL（前提タスク完了後）+ `03_sys_params` に `F61_` キー追加（信号機閾値・予測パラメータ・繰越欠損金フェーズ判定閾値等）。⑪連携先: MAS-003（KPI ダッシュボード ✅）/ MAS-008（ランウェイ・既存）/ MAS-040（法人税会計年度ベース）/ MAS-041（繰越欠損金 📝）/ MAS-049（賃上げ税制 ✅）/ MAS-141（共済シミュレーター 📝）/ MAS-218（R&D タイムトラッキング・控除エビデンス）/ MAS-057（個人/法人統合）/ MAS-058（必要年商）/ MAS-059（意思決定ツリー Tool 化）/ MAS-060（組織構成・税務最適化指数で連携）。⑫前提依存: MAS-049 ✅完了 / MAS-041 📝完了 / MAS-141 📝完了 / MAS-218 未着手（タイムトラッキング・R&D 控除エビデンス用）/ MAS-057 Phase 2-3 未着手（社保ロジック）/ 税目分類マスタ整備（前提タスク Step 0）。実装着手は MAS-049/MAS-041/MAS-141 が出揃う段階で可能（2026 Q3 以降想定）。⑬想定ユースケース: SZ-1〜SZ-3 全フェーズで月次レビュー対象化。特に PH-2（黎明期・インボイス課税移行）以降に効果が出始め、PH-3（成長期・採用本格化）で賃上げ税制と組合せた最適化が最大化。⑭顧客向けサービス化: Cash ETR 算出ロジックを汎用ライブラリ（仕訳データ + 勘定科目マスタ + 税目分類で完結）として切り出し、bizlp の管理会計支援サービスのテンプレート資産化を視野（PH-4 商用化期）。⑮起票経緯*: 2026-04-25 軽量 FP&A 機能設計の検討中、ユーザー要望「キャッシュ実効税率（見込み）を試算、および抑制案を検討する機能も欲しい・あくまでも節税の範囲で」を受け、MAS-049/MAS-041/MAS-141 個別税務最適化が空白の統合指標領域として独立起票。	法定実効税率 34% との乖離を可視化し、節税設計の費用対効果を月次レビュー対象化 / 13 週キャッシュフロー予測・ランウェイ計算の精度向上（税金支払を予測ベースで織込み）/ 繰越欠損金の食い潰しタイミングと反動の事前察知（Cash ETR の不自然な低下 → 翌期跳ね返りリスクをアラート）/ 顧客向け管理会計支援サービスの差別化要素（同様の Cash ETR ダッシュボードを顧客に提供可能なテンプレート資産化）	「世帯ベース実効税率」（法人税 + 個人所得税 + 住民税 + 社会保険料 ÷ 法人税引前利益 + 役員報酬）を併設するか否か（一人法人特有の最適化視点として有用だが個人税務情報の取込でスコープ拡大）/ 系統 A・系統 B のどちらをデフォルト表示にするか（推奨は系統 B、系統 A はドリルダウン）/ Cash ETR 信号機の閾値（🟢<20%）が、繰越欠損金フェーズの「人為的な低 Cash ETR」を健全と誤判定しないためのコンテキスト判定ロジック設計 / 税額控除（賃上げ促進税制・研究開発税制等）の控除前後の両方を表示するか、控除後のみにするか / 顧客向けサービス化を視野に汎用ライブラリ化するかの判断（仕訳データ + 勘定科目マスタ + 税目分類で完結） / 勘定科目マスタへの「税目分類」属性追加 vs 別マスタ `12_mst_tax_classification` 新設の判断（後者は DDL 拡張が必要・前提タスク化）/ 予測 Cash ETR の信頼区間表示（点推定 vs 範囲推定）/ ID 採番の整合性: 税務系新規プレフィックス（TAX-XX/FIN-XX）を切らず F-* 系列継承（MAS-040/MAS-041/MAS-049 と並列）の方針継続可否
MAS-062	Story	🧠 Domain	PSF プロフィタビリティ指標拡張（Rule of Three 動的分解 + 価値ベース課金移行可視化）	FP&A・PSF KPI	P2	★★	未着手	—	PSF（Professional Services Firm）の価格戦略を P/L 上で可視化。既存の MAS-003（KPI ダッシュボード ✅）/ MAS-024（BEP 分析 ✅・P/L 末尾拡張の前例）/ MAS-051（PSF KPI ダッシュボード仕様書未着手）/ MAS-043（RICE/VALUE/SEED 2 トラック採算）はカバー範囲が断片的で、「Rule of Three の構造分解 + 価値ベース課金への移行可視化」を扱う統合仕様は空白。①背景の戦略思考（戦略メモ `docs/_internal/biz/pricing_strategy_rule_of_three.md` 参照）: 伝統的な「Rule of Three（時間単価×3 倍）」は稼働率 70% + 十分なレバレッジ + 安定した受注フローが前提だが、ブティック（数人規模）では稼働率 40-55%（創業者が営業・経営・経理兼務）+ レバレッジ不在 + 安定受注の弱さで前提が崩れる。「3 倍の時間単価を追うより、6-10 倍相当の利益率を出す案件設計」を目指す方が筋が良い。②P/L 末尾セクションの実装（MAS-024 BEP と同パターン）: 「PSF メトリクス（時間単価モデル分解）」と「価値ベース指標（バリューベース課金分解）」の 2 ブロック。前者は時間単価/人件費単価倍率・目標倍率（業態 default 3.0）・稼働率（業態 default ブティック 50% / 大手 70%）・実効回収率（倍率 × 稼働率）・間接費比率・純粋利益率 vs 実際利益率。後者はバリューベース売上比率（リテイナー + 固定価格 + IP）・価値ベース実効倍率（売上 / 投入時間原価・6-10 倍ターゲット）・リテイナー収益安定率・IP/フレームワーク売上比率。③入力次元: 時間単価 = 売上 ÷ Billable hours（MAS-218 タイムトラッキング連携）/ 人件費単価 = HC RPA 給与 ÷ 投入時間 / 稼働率 = MAS-218 `F-ClientWork` タグ ÷ 総労働時間 / 業態 default = use_cases.md BZ-1〜BZ-5 連動 / バリューベース判別 = INV の契約形態タグ（リテイナー / 固定価格 / 時間ベース / IP）。④信号機シグナル: 🟢 倍率 ≥ 3 ∧ 稼働率 ≥ 60% = 健全な時間単価モデル / 🟡 倍率 < 3 ∨ 稼働率 < 50% = 価値ベースへの移行検討推奨 / 🔵 バリューベース売上比率 ≥ 50% ∧ 実効倍率 ≥ 6 = bizlp が目指す形（6-10 倍相当利益率の達成）。⑤新規実装: `mas/400_domain/449_psf_profitability_engine.js`（純粋関数・倍率/稼働率/実効回収率算出）+ `mas/600_report/603_datamart_pl.js` 拡張（P/L 末尾に新セクション）+ 32_wrk_invoice の契約形態タグ拡張（リテイナー/固定価格/時間ベース/IP）+ 93_kpi_dashboard（MAS-003）に Rule of Three 信号機追加 + `03_sys_params` に `F62_TARGET_MULTIPLIER`（default 3.0）/ `F62_TARGET_UTILIZATION`（default 0.6 ブティック / 0.7 大手）/ `F62_VALUE_BASED_TARGET_RATIO`（default 0.5）等。⑥連携先: MAS-003（KPI ダッシュボード）/ MAS-024（BEP・P/L 拡張パターンの先例）/ MAS-051（PSF KPI 業界ベンチマーク・SPI Research 2025 Billable Utilization 68.9%）/ MAS-043（RICE/VALUE/SEED 2 トラック・バリューベース売上を VALUE トラックとして分類）/ MAS-029（Unit Economics）/ MAS-218（タイムトラッキング・倍率と稼働率の分母）/ MAS-081 進行基準収益認識（INV 契約形態タグの拡張連携）。⑦前提依存: MAS-003（✅完了）/ MAS-024（✅完了）/ MAS-218（未着手・タイムトラッキング基盤）。MAS-218 着手後に MAS-062 着手可能。⑧bizlp 自身の現在地での適用（戦略メモ §5 参照）: 倍率推計 2-2.5 倍（コンサル相場下限）/ 稼働率 40-55% / 6-10 倍相当案件設計を目指す。⑨想定ユースケース: SZ-1〜SZ-2 で月次 KPI レビュー時にバリューベース移行進捗を確認 / 価格改定検討時の判断材料 / 顧客向けサービス化時のテンプレート資産（PH-4 商用化期）。⑩起票経緯: 2026-04-25 ユーザー分析「Rule of Three の前提が数人ブティックで崩れる構造を、価値ベース課金移行の戦略で解決する」を受け、MAS-049/MAS-041/MAS-141 等の個別税務最適化と並列で「価格戦略の P/L 可視化」が独立領域として必要と確認。新案件 MAS-062 として独立起票し、戦略メモ `pricing_strategy_rule_of_three.md` を根拠資料化。	bizlp 経営者の「3 倍を追うより 6-10 倍相当の案件設計」戦略を P/L 指標として常時可視化。MAS-049/MAS-041/MAS-141 等の節税系とは異なる「売上構造そのものの差別化」軸。世界の海外 FP&A SaaS（Pigment/Causal/Runway/Mosaic）は時間単価ベースの稼働率管理は扱うが「時間単価モデル vs バリューベースモデルの並列対比」と「6-10 倍相当利益率の達成度シグナル」は不在で、bizlp の差別化機会となる	業態 default の妥当性（ブティック 50% / 大手 70% / コモディティ 40% 等の細分化粒度）/ バリューベース売上の判別ロジック（INV 契約形態タグ拡張で対応 vs 別途プロジェクト属性管理）/ 6-10 倍ターゲットの根拠（業界ベンチマーク確認・SPI Research 等の二次ソース）/ MAS-218 タイムトラッキング着手前の暫定運用（手動入力 vs 計算スキップ）/ MAS-043 RICE/VALUE/SEED との整合性（VALUE トラック ≒ バリューベース売上の対応関係）/ 顧客向けサービス化時のテンプレート粒度（PSF 業態専用 vs 汎用化）/ 戦略メモ更新時の MAS-062 spec 同期フロー
MAS-063	Story	🧠 Domain	P/L 営業外損益指標拡張（営業外損益率 + Interest Coverage Ratio + 段階的昇格機構）	FP&A・財務体質	P2	★★	未着手	—	営業利益率と経常利益率の乖離を P/L 上で可視化し、財務体質の異常検知 + 借入返済余力モニタリングを段階的に拡充。既存 MAS-003（KPI ダッシュボード ✅）/ MAS-008（Cash Runway）はランウェイと一般 KPI を扱うが、「営業外損益の構造分解 + Interest Coverage の段階的昇格機構」を扱う仕様は空白。①背景の戦略思考（戦略メモ `docs/_internal/biz/pl_metrics_non_operating_strategy.md` 参照）: 経常利益率 − 営業利益率 = 営業外損益率（売上比）が本質的な評価軸。bizlp 規模（PH-1 + SZ-1 + BZ-5）では営業外損益が小さいので両者が一致するのが正常で、乖離 ±0.5% 超で異常検知アラートするのが実用的。借入活用フェーズで Interest Coverage Ratio を昇格する段階運用が筋。②段階別実装方針（ユーザー文書の優先順位を反映）: v1（必須・現在）= 営業外損益率（経常利益率 − 営業利益率） / v1.1（公庫融資申請時に昇格）= Interest Coverage Ratio 基本版（営業利益 ÷ 支払利息）/ v1.2 = ICR 厳密版（(営業利益 + 受取利息 + 受取配当金) ÷ 支払利息）/ v2（投資収益が増えてから・SZ-3 以降）= 事業利益率 + 財務収支比率 + 営業外損益依存度。③P/L 末尾セクションの実装（MAS-024 BEP / MAS-062 PSF と同パターン・3 つ目の P/L 拡張ブロック）: 「財務外損益指標（v1）」と「Interest Coverage（公庫融資フェーズで有効化・v1.1）」の 2 ブロック。前者は営業利益率・経常利益率・営業外損益率（差分・🟢 ±0.5% 以内 / 🔴 超過時アラート）+ うち支払利息・受取利息配当金・その他（為替差損益等）。後者は ICR・閾値判定（🔴<1.0 / 🟡 1.0-3.0 / 🟢 ≥3.0 / 💎 ≥10.0）+ 借入金残高・実効金利・covenant 維持可否。④段階的昇格機構: `03_sys_params` の `F63_ENABLED_METRICS` キーで段階制御（"operating_non_op_diff" / "operating_non_op_diff,interest_coverage" / 全部）。フェーズに応じて表示指標を切替。⑤評価の枠組み（実務的アプローチ）（戦略メモ §3 参照）: 経常＞営業（営業外プラス・受取配当などヘルシー / 為替差益で一時上振れ警戒）/ 経常＜営業（営業外マイナス・支払利息重い / 為替差損や持分法投資損失警告）/ 両者ほぼ一致（理想的・中小企業お手本）の 3 パターン診断ロジックを内蔵し、UI で「この期はパターン X です」とコメント自動生成。⑥新規実装: `mas/400_domain/450_pl_non_operating_engine.js`（純粋関数・営業外損益分解 + ICR 算出 + パターン診断）+ `mas/600_report/603_datamart_pl.js` 拡張（P/L 末尾に新セクション）+ 11_mst_account への「営業外損益サブ分類」属性追加（受取利息 / 受取配当金 / 支払利息 / 為替差損益 / 持分法投資 / その他の 6 区分）+ `03_sys_params` に `F63_` キー（信号機閾値・ICR 段階別判定値・covenant 閾値等）。⑦bizlp 規模感での運用方針（戦略メモ §5 参照）: 営業外損益は雑収入（振込手数料・わずかな受取利息）程度で営業利益率と経常利益率がほぼ一致が正常 → 乖離 ±0.5% を超えたら警告するアラート指標として運用。⑧将来拡張: 公庫融資（新規開業・スタートアップ支援資金）活用時に ICR を昇格し、銀行 covenant（financial covenant）として「ICR を一定水準以上に維持すること」のモニタリング指標化。⑨海外指標との対応関係（戦略メモ §7 参照）: 経常利益率 ≒ EBIT Margin / 事業利益 = Operating income + Equity in earnings of affiliates / ICR は同名。海外顧客が増えたら IFRS 的な EBIT 軸への切替を検討する場面が来る可能性あり（多通貨対応 MAS-064 候補と連動）。⑩連携先: MAS-003（KPI ダッシュボード）/ MAS-008（Cash Runway・ICR で 13 週 CF 予測精度向上）/ MAS-017（資金調達シミュレーション・ICR と DSCR の二重判定）/ MAS-073（法人税・経常利益から先で連動）/ MAS-058（必要年商シミュレーター・借入返済余力を制約条件として組込検討）/ MAS-024（BEP・P/L 拡張パターンの先例）/ MAS-062（PSF・3 つ目の P/L 拡張ブロックとして並列配置）。⑪前提依存: MAS-003（✅完了）/ MAS-024（✅完了）/ MAS-073（✅完了）。前提案件は揃っているため即時着手可能（v1 の営業外損益率のみなら短期実装可・優先度判断のみ）。⑫想定ユースケース: 月次決算時に自動表示・乖離 ±0.5% 超で警告表示 / 公庫融資申請時に v1.1 昇格 / 関連会社設立時に v2 昇格（事業利益率 + 持分法投資利益）。⑬深掘り論点（将来 TODO 候補）: 借入 vs 自己資金判断（MAS-017 + MAS-063 ICR の二重判定）/ 為替差損益処理（MAS-064 候補・多通貨対応起票で対応）/ 関連会社設立時の指標再設計（MAS-063 v2 + MAS-065 候補・連結会計起票・SZ-3〜SZ-4）。⑭起票経緯*: 2026-04-25 ユーザー分析「経常利益率と営業利益率の差を継続トラッキングし、財務体質の異常検知 + 借入返済余力モニタリングを段階的に拡充する仕様を欲しい」を受け、MAS-062 PSF と並列で独立起票。戦略メモ `pl_metrics_non_operating_strategy.md` を根拠資料化（フェーズ別優先順位 + 海外指標対応 + 段階的昇格機構を網羅）。	財務体質の異常検知 + 借入返済余力モニタリングを月次 P/L で常時可視化。MAS-062 PSF（売上構造の差別化）/ MAS-061 Cash ETR（税務最適化）/ MAS-063 営業外損益（財務体質）の 3 軸で P/L 拡張ブロックが完成し、bizlp の経営者が「本業 vs 財務外 vs 税務」を月次 P/L 1 枚で全把握できる体験を提供。Interest Coverage Ratio は世界標準指標で銀行 covenant にも使えるため、商用化時に顧客向けテンプレート資産化も視野	営業外損益サブ分類（11_mst_account 属性追加 vs 別マスタ）の DDL 拡張判断 / アラート閾値 ±0.5% の妥当性（業種・規模で変える可能性）/ ICR 昇格タイミング（公庫融資申請時に手動有効化 vs 借入金残高 > 0 で自動有効化）/ パターン診断（経常＞営業 / ＜ / ＝）の自動コメント生成 UI（テンプレ vs LLM）/ 為替差損益が出始めた時の処理（MAS-063 サブ分類の 1 つ vs MAS-064 多通貨対応へ移譲）/ 関連会社設立時の事業利益率昇格と MAS-065 連結会計起票のトリガー条件（持分法投資が出た時点で v2 自動昇格か）/ 海外顧客が増えた場合の IFRS 軸切替判断（multi-currency = MAS-064 連動）
MAS-066	Story	🧠 Domain	配当ミックス最適化（役員報酬 + 賞与 + 配当の 3 軸最適化）	シミュレーション・税務	P3	★★	仕様書完了 v1.0	2026-04-27	→ 開発仕様書 (v1.0・約 700 行・`tasks/prompts/task_F-66.md` (PR #383) + `task_F-66.gemini.md` (PR #385) を統合 input として Claude Opus 4.7 (1M context) で本体起草)	MAS-057 Phase 3 実装完了 (PR #379) 後の振り返り派生案件。MAS-057 の役員報酬最適化 (給与・賞与の 2 軸) に株式配当 (loan-out 法人からの分配) を加えた 3 軸最適化。配当は社保ゼロ + 法人税後利益から支払 + 配当控除あり (10% / 12.8%) の特性を持ち、特に年収 1,500 万超のゾーンで社保頭打ち + 個人累進高税率の組合せにより、役員報酬を抑えて配当ミックスにする方が手取り最大化に有利になる可能性。①新規ロジック: (a) 配当所得計算 + 配当控除（上場 vs 非上場・所得 1,000 万境界の控除率変動・住民税非申告制度の選択肢）、(b) 利益剰余金累積制約（1 期目決算後・配当原資が法人税後利益限定）、(c) 株主総会決議の事務工数、(d) 配当受領者の所得税確定申告要否。②UI: MAS-057 cockpit のドロップダウン拡張ではなく、新規 cockpit (MAS-066) または MAS-057 cockpit に「配当年額」を 4 つ目のドロップダウンとして追加するか要判断（人間検討事項）。③前提依存: MAS-057 Phase 1/1.5/2/3 完了（✅ PR #354 / #356 / #360 / #379）。④BRD 改訂: 本 PR で `docs/brd_solo_ceo_financial_navigator.md` §3.2 / §4 / §5 / §8 に配当配分セクション追加済。⑤MAS-061 Cash ETR との連携: MAS-061 の「合法節税の優先順位サジェスト」に配当ミックスを追加候補として含める（本 PR で MAS-061 spec v1.1 改訂）。MAS-061 の `40_KPIMonthly` ダッシュボードに「配当 vs 役員報酬の節税効果」スコア追加（v1.1）。⑥着手条件: MAS-058 Step 5（UI / SPA 連携）完了後 + MAS-057 Step 6（3 区分テーブル）完了後を推奨（UI フレームの安定後に配当軸を追加）。⑦新規ファイル想定: `mas/400_domain/449_dividend_mix_optimizer.js`（MAS-057 442-444 系を継承する命名・MAS-058 445 / MAS-061 448 と並列・446-448 が MAS-061 想定なので配当エンジンは 449 が空き）。⑧新規定数想定: `Constants.DIVIDEND_TAX_BRACKETS`（上場 / 非上場・所得帯別控除率・住民税非申告制度フラグ等を統合）。⑨ID 採番衝突の教訓: 当初 main 側プロンプトは「MAS-060 として起票」だったが、MAS-060 は既に「組織構成シミュレーター」（2026-04-25 起票）として確定使用済のため衝突。MAS-066 に振り直し。新規案件起票プロンプト発行前に main → origin/main で fetch + grep で番号予約状況を確認するワークフローを `dev_spec_prompt_template.md` に追記する案件として TODO 新設候補（任意）。⑩起票経緯: 2026-04-27 main 側 MAS-057 Phase 3 実装後の振り返りで「MAS-057/MAS-058 は給与系のみで配当を扱っていない・特に高所得帯で配当ミックスが手取り最大化に有利」気付きから sub 側に依頼。	BRD `solo_ceo_financial_navigator` 拡張。MAS-057 は「給与系（報酬 + 賞与）のみ」のスコープに留め、MAS-066 で「配当を含む 3 軸最適化」を扱う設計。BRD §3.2「法人 vs 個人税率のデッドヒート」に配当の第 3 ルートを加えることで、年収帯別の最適配分曲線が得られる（ローカルの配分最適化問題を、年収・配分・配当ミックスの 3 次元最適化に拡張）。MAS-061 Cash ETR の節税優先順位リストに新項目として追加可能。商用化時の高所得層顧客（コンサル独立系・年収 1,500 万超）への差別化機能候補。
MAS-067	Epic	🧠 Domain	マルチイヤー計画ワークスペース + ステージ準備度ダッシュボード (5 軸モデル・Gemini 精緻化版)	シミュレーション・UX	P2	★★★	🟡 Phase A + B-1/B-2/B-3 完了 v1.6	2026-04-30	→ 開発仕様書 (v1.6 Phase A + B-1/B-2/B-3 実装完了反映 — Phase A PR #418 / Phase B-1 PR #423 (5 軸ダッシュボード) / Phase B-2 PR #425 (ガードレール 10 件) / Phase B-3 PR #426 (Burnout + Section G 3/5 件)・残: B-4 配当連携 / C / D)	MAS-057 Phase 3 実装後の振り返り派生案件。Claude Opus 4.7 暫定合成 + Gemini 3 Pro Preview Deep Think 精緻化 (MAS-334) 反映版。①機能 4 分解: (a) Y1-Y5 マルチイヤー入力、(b) 計画 PL/BS/CF 引継ぎ、(c) 5 軸ステージ準備度ダッシュボード、(d) サジェストエンジン。②5 軸モデル (1 人社長メンタルモデル直結・Gemini 精緻化で 6→5 に再編・退職金重複解消): 🏦 Liquidity (流動性・防衛) / 🛡️ Tax & Social (節税・社保) / ⚔️ Scale (事業拡張) / 💰 Accumulation (蓄積) / 🚪 Exit (出口・承継)。③v1 採用 10 アクション (Gemini 精緻化版): A1 役員報酬最適化 (MAS-057)、A2 役員社宅 (MAS-057)、A3 出張日当 (MAS-057)、A4 親族役員化 (MAS-066 配当とは独立・税引前損金で即効性最強)、A5 小規模企業共済 (MAS-141)、A6 経営セーフティ共済 (MAS-141・2024.10 改正出口パズル要対応)、A7 少額減価償却資産特例 (年 300 万枠)、A8 業務委託活用 (MAS-011/MAS-008・フリーランス新法サイト負け検知必須)、A9 公庫融資準備 (MAS-013/MAS-008・閾値変更: 自己資本比率 → 債務償還年数 ≤ 10 年 + 現預金 ≥ 3 ヶ月)、A10 退職金制度設計 (MAS-141・5 年/19 年ルール対応)。+ 表示のみ A11 賃上げ促進税制 (MAS-049・1 人法人は構造的に対象外を🔴 明示)。④v1 で除外: インボイス・電帳法 (Day 1 法定要件・オンボーディングチェックリストに移譲)、SaaS 開発投資 (v1 スコープ重い・少額減価償却 A7 に置換)、正社員採用 (S3-S4 のみ・v2+)、補助金マッチング (MAS-068・P3 降格)、HD/M&A (MAS-069・P3)、マイクロ法人 (MAS-070 棄却・実質所得者課税で否認)、サイバーセキュリティ等。⑤プログレッシブ・ディスクロージャー: S1 Survival (Runway < 6 ヶ月) = Liquidity のみ / S2 Optimization (Runway ≥ 6 ヶ月) = + Tax & Social + Accumulation / S3 Expansion (利益剰余金蓄積) = + Scale / S4 Exit (設立 5 年以上) = + Exit。⑥循環参照解消: 3↔6↔9 の三すくみは「最優先ポリシー A/B/C セレクター」で解消 (A 手取り・節税優先 / B 信用・融資優先 / C 出口・退職金優先・齋藤 Baseline default = A)。⑦行為計算否認ガードレール 10 件: spec § 注意事項に文言ハードコード (MAS-334 Section C 参照)。⑧Deep Think 独自必須機能 5 件 (MAS-334 Section G): (i) フリーランス新法サイト負け検知 (元請 90 日 vs 委託先 60 日のギャップ)、(ii) 退職所得控除「枠の食い合い」5 年ズラしガードレール、(iii) セーフティ共済「出口パズル」マッピング、(iv) 社長稼働限界 (Burnout) メーター 100% 超🔴、(v) インボイス 2 割特例 2026/9 終了の崖検知。⑨GAS 実装制約: 債務償還年数等で営業 CF ≤ 0 → Infinity/NaN 発生 → google.script.run silent null 化 (failure_patterns #29) を `Math.min(val, 999)` サニタイズで予防。⑩新規実装ファイル: `mas/400_domain/451_multiyear_planner.js` + `webapp_client/multiyear_cockpit.html` + `src/MultiyearApp.tsx` + `src/multiyear/{YearTabs,BSCarryover,StageDashboard,SuggestPanel,GuardrailPanel,BurnoutMeter}.tsx` (Phase B でガードレール + Burnout 追加で 6 コンポーネント)。`03_sys_params` に `F67_DEBT_REDEMPTION_YEARS_MAX = 10.0` / `F67_CASH_RUNWAY_MONTHS_MIN = 3.0` / `F67_BURNOUT_OCCUPANCY_RED_THRESHOLD = 100` / `F67_INVOICE_TRANSITION_END_DATE = 2026-09-30` / `F67_OPTIMIZATION_POLICY_DEFAULT = A` 等を追加。⑪Phase 分割: A = マルチイヤー入力 + B/S 引継ぎ / B = 5 軸ダッシュボード + ガードレール 10 件 + Burnout メーター + サイト負け検知 + インボイス崖検知 / C = サジェストエンジン + 退職控除 5 年ズラし + セーフティ共済出口パズル / D = AI 連動 (Vertex Gemini)。⑫前提依存: MAS-057 Phase 3 (✅) / MAS-008 (✅) / MAS-011 (✅) / MAS-013 (✅) / MAS-048 (✅) / MAS-058 Step 1-4 (✅) / MAS-058 Step 5 完了待ち / MAS-057 Step 6 完了待ち (3 区分テーブル UI が B/S 引継ぎ表示で再利用)。⑬連携先 (主要): MAS-057 / MAS-058 / MAS-066 配当 (任意・親族役員化は MAS-067 単独で扱う) / MAS-141 共済 / MAS-144 規程ジェネレーター (旧提案 MAS-142 から ID 衝突回避で振直し・並列起票推奨)。⑭起票経緯: 2026-04-27 main 側で MAS-057 Phase 3 実装後の振り返り → Deep Research → Claude 合成 → Gemini Deep Think 精緻化 (MAS-334) で確定。	MAS-057 BRD Vision「財務のコックピット」の単年スコープを複数年に拡張。1 人社長の「次のステージへの準備度」を 5 年計画の俯瞰で評価。「5 軸モデル + 行為計算否認ガードレール 10 件 + フリーランス新法サイト負け検知 + 社長稼働限界 (Burnout) メーター + インボイス 2 割特例終了の崖」は海外 FP&A SaaS (Pigment/Causal/Runway) でも空白で差別化機会大。商用化時の主要 UI レイヤー候補。
MAS-068	Story	🧠 Domain	補助金・助成金適合性自動マッチングエンジン (MAS-334 Section F・P3 降格)	FP&A・資金調達	P3	★★	未着手	2026-04-27	MAS-334 Section F で起票案発見 + Gemini Deep Think で P1 → P3 降格 (DB メンテコストが SaaS 死の谷・v1 見送り推奨)。機能想定: 福井県等の県・市町村レベル補助金 DB を定期スクレイピング → 法人プロファイル (業種・従業員数・売上規模・所在地) と要件を LLM で照合 → 適合性スコア順に提示。P3 降格理由: 自治体 DB の構造が標準化されておらず手動メンテが SaaS 商用化で死の谷化する懸念 (Gemini 指摘)。MAS-067 v1 リリース後 1 年で再評価。	MAS-067 v1 リリース後 1 年で再評価。福井県等の県・市町村レベル補助金 DB スクレイピングは商用化フェーズで本格化検討	自治体 DB API 不在の場合のスクレイピング法的可否 / 補助金要件マッチング精度 (LLM 経由か rule-based か) / 商用化時の自治体別カバレッジ / DB メンテ頻度と人件費試算
MAS-069	Story	🧠 Domain	持株会社 (HD化) ・ M&A エグジット・シミュレーター (MAS-334 Section F)	FP&A・出口戦略	P3	★★	未着手	2026-04-27	MAS-334 Section F で起票案発見 + Gemini Deep Think で P2 → P3 (1 人社長に時期尚早・対象 S4 限定)。機能想定: レーマン方式 (5%/4%/3%) + 株式譲渡税 + HD コスト分岐点の 3 要素を計算。P3 設定理由: 対象が S4 (法人設立 5 年以上) 限定 + 株価評価実装重い + 1 人社長の現実的選択肢として時期尚早。MAS-067 v1 リリース + 法人設立 5 年経過後に再評価。	法人成熟期の出口戦略が必要になった時点で着手判断 (S4 = 設立 5 年以上の局面)	レーマン方式の現行手数料率検証 / 株式評価実装の精度 (DCF・類似会社比較・純資産価額の使い分け) / HD 化の継続コスト計算 (連結会計事務 + 別法人の管理費) / 中小 M&A 特例措置 (経営資源集約化税制) との連動
MAS-072	Story	🧠 Domain	企業価値（時価評価額）スコアボード機能 (MAS-057 cockpit 拡張・3 評価手法統合)	KPI 可視化・経営の通信簿	P2	★★	未着手	2026-04-30	→ 開発仕様書 (v0.1)。MAS-057 Solo-CEO Visual Cockpit の役員報酬シミュレータに連動する「企業価値スコアボード」。バイアウト目的ではなく「自社の経営の通信簿 (KPI)」として企業価値をリアルタイムに把握し、企業価値向上を数値目標として追えるようにする。役員報酬の設定が企業価値にどう影響するか (あるいは正常化調整によって影響しないか) を可視化。①入力: OP_pre (役員報酬控除前営業利益) / C (実報酬) / TC (理論報酬・MAS-071 から取得) / D&A (減価償却) / NetAssets (帳簿純資産) / OffBalanceAssets (簿外資産・MAS-141 共済解約返戻金) / Multiple (EBITDA 倍率・default 5)。②3 評価手法: (1) 経営力スコア (EBITDA マルチプル法) = `max(0, (OP_pre - TC + D&A) × Multiple) + NetAssets + OffBalanceAssets` ※ 役員報酬を理論値で正常化調整するため C を変えても EV は変わらない (ごまかせない指標) / (2) 蓄積スコア (時価純資産法) = `NetAssets + OffBalanceAssets` ※ 過去の利益蓄積を示す・C を抑えて内部留保を積むほど確実に上がる / (3) 税務評価スコア (財産評価基本通達簡易版) = `(OP_pre - C) × 0.5 + NetAssets × 0.5` ※ 資産管理会社移転等で使う税務上株価・C を上げると下がる (1/2 と逆動)。③ID 採番経緯: F-72 → MAS-072 mapping は stale (実 spec は MAS-058 に統合) だったため、本案件で MAS-072 を正式利用 (failure_patterns #31 適用 + 過去の F-71→MAS-071 と同パターン)。④ファイル番号: `mas/400_domain/455_valuation_engine.js` (当初ユーザー提案 `446_.js` だったが、sub workspace で MAS-059 が 446 を既に予約済と判明したため 455 に振直し・failure_patterns #31 適用・MAS-059/060/061/063/144/062 が 446-453 を予約済のため 455 が次空き)。⑤UI: スコアボード形式で 3 スコアを並列表示・既存役員報酬ドロップダウン変更時にリアルタイムアニメーション再計算・ゲーミフィケーション要素 (現在の企業価値は〇〇円・スコア帯バッジ 🌱 新興 / 🚀 成長 / 🏆 一流)・正常化調整ツールチップ解説 ("役員報酬 (C) を下げても TC で正常化されるため EV は変わらない")。⑥連携先: MAS-057 (OP_pre/C/D&A 入力源) / MAS-071 (TC 理論報酬供給) / MAS-141 (OffBalanceAssets 共済解約返戻金) / MAS-067 (initialBS から NetAssets 起点)。⑦免責*: 「実際の M&A 価格は本数値とは大きく異なる可能性 (買い手・タイミング・シナジー等)」常時表示で誤用防止 (MAS-057 注意事項 #15 税務否認リスクと同型のガードレール)。	MAS-057 cockpit を「節税最適化ツール → 経営の通信簿ツール」に進化。1 人社長がバイアウト視点ではなく KPI 視点で企業価値を追える仕組みは海外 FP&A SaaS でも空白で差別化機会大。役員報酬を上下しても経営力スコアが変わらないことの体感学習効果が高い (正常化調整の概念理解促進)。期末スナップショット保存で時系列推移可視化への発展余地 (v2 候補・MAS-067 マルチイヤー連携)。	検討事項: ①Multiple のレンジと業種別 default (IT 5-7 / コンサル 3-5 / SaaS 8-15 等) の業種マスタ化、②TC の供給源 (MAS-071 vs ロールバリュー積算 vs 業界統計)、③簿外資産入力 UX (MAS-141 連携 vs 手動)、④経営力スコア帯の閾値設計 (新興/成長/一流境界)、⑤税務評価スコア (OP_pre-C)×0.5 + NetAssets×0.5 算式の妥当性レビュー (税理士)、⑥期末スナップショット + 時系列推移 (v2)、⑦バイアウト目的転用時の追加考慮 (DCF / 類似企業比較)、⑧KPI 通知 (前年同月比 +5% で🎉等)、⑨配偶者株主の評価ロジック (MAS-066 配当連携)、⑩多通貨化 (MAS-064 連動・out of scope)
MAS-071	Story	🧠 Domain	稼働率連動型役員報酬シミュレーター (MAS-057 cockpit 拡張・4 アプローチ統合)	シミュレーション・役員報酬最適化	P2	★★★	未着手	2026-04-30	→ 開発仕様書 (v0.1)。MAS-057 Solo-CEO Visual Cockpit の役員報酬決定機能の高度化。1 人社長が役員報酬を決定する際、単なる「節税」だけでなく*「自身の稼働割合（時間の使い方）」と「4 つの財務的アプローチ」を統合的に評価して最適報酬額をシステマティックに導出。①入力: (a) 限界利益 OP_pre = 売上 - 固定費（役員報酬控除前）、(b) 稼働率 R_d/R_i/R_m（合計 100%・直接業務 / 投資業務 / 管理業務）、(c) 市場価値 V_d/V_i/V_m（職務代行コスト法・default 1,000 万 / 1,200 万 / 800 万）、(d) L_min 個人最低額面年収（default 480 万）、(e) Buffer 法人最低固定バッファ、(f) TargetProfit 融資対策用法人利益。②計算式: (1) 理論報酬 TC = V_d × R_d + V_i × R_i + V_m × R_m （税務調査時の「不相当に高額」防御の根拠 = 法人税法施行令 70 条 1 号倍半基準準拠）、(2) アプローチ A（ボトムアップ・生活防衛） = max(L_min, min(TC, OP_pre))、(3) アプローチ B（トップダウン・内部留保） = OP_pre - (Buffer + OP_pre × R_i)、(4) アプローチ C（税務最適化） = min(C_opt, TC) ※ 既存 SocialInsuranceTierEngine + PersonalTaxEngine を再利用して合算手残り最大化を 12 万刻みでスキャン探索、(5) アプローチ D（融資対策） = TC × (1 - R_i)・OP_pre - 報酬 ≥ TargetProfit クランプ。③ID 採番経緯: 当初ユーザー提案ファイル名 `mas/400_domain/445_compensation_strategy_engine.js` だが既存 MAS-058（445_required_revenue_solver.js）と衝突 → `454_compensation_strategy_engine.js` に振直し (440〜453 全使用済確認済・failure_patterns #31 適用)。④UI 配置: MAS-057 cockpit「目標逆算レイヤー」(MAS-058 健全性診断パネル直下) に新規 `CompensationStrategyPanel.tsx` として統合配置 (MAS-057 spec v2.2 の「現状把握↑ vs 目標逆算↓」境界原則に準拠)。⑤稼働率 UI: R_d/R_i/R_m の 3 連動スライダー（合計 100% 自動制御）。⑥4 アプローチ比較: 棒グラフで並列表示 + 推奨レンジ（A〜C 範囲）ハイライト。⑦既存エンジン再利用: SocialInsuranceTierEngine（MAS-057 Phase 1 実装済 442_）+ PersonalTaxEngine（MAS-057 Phase 1 実装済 444_）。⑧クライアント実行: GAS レイテンシ排除のため React 側で計算 (MAS-057 / MAS-066 同パターン・sync-engines.mjs 経由でエンジン同期)。⑨前提依存: MAS-057 Phase 3 + Step 6 完了 (✅) / MAS-058 Step 5 完了 (✅・PR #400)。⑩税務調査防衛論理*: 理論報酬 TC が「ロールバリュー積算」(CEO + CTO + COO 兼務の市場価値合算) として法人税法施行令 70 条 1 号「同種事業類似規模 0.5〜2 倍」の正当化根拠を提供。Gemini Deep Research + Claude Research の調査結果（粗利 1,500-2,000 万・固定費 240 万のスイートスポット = 月 50-65 万・年 600-800 万）を spec 内に検証データとして反映。	MAS-057 cockpit を「節税最適化ツール → 統合的経営判断ツール」に進化。一人社長の役員報酬決定における4 軸統合最適化（生活防衛 / 内部留保 / 税務最適 / 融資対策）は海外 FP&A SaaS（Pigment / Causal / Runway）でも空白で差別化機会大。「稼働率」を統合した報酬正当化ロジックは税務調査防衛策としても価値が高い。MAS-067 マルチイヤー化での年次連動への発展余地（v2 候補）。	検討事項: ①稼働率自己申告の客観性担保（事後ログ集計 vs ヒアリング）、②市場価値ベンチマーク（労政時報 / SMBC 調査）の更新頻度、③4 アプローチの重み付け自動化 vs 手動セレクター（MAS-067 ポリシー A/B/C と整合）、④配偶者役員化（MAS-066 配当連携）の組込タイミング（v2+）、⑤退職金算定基礎（月額報酬ベース）との整合（MAS-141 共済 + MAS-144 退職金規程と連動）、⑥定期同額給与改定 3 ヶ月ルールの UI 警告表示、⑦事前確定届出給与による賞与寄せ型シミュレーション（社保削減 vs 退職金枠縮小トレードオフ）、⑧業績悪化改定事由の厳格性 UX、⑨多通貨化対応（MAS-064 連動・out of scope）、⑩MAS-067 マルチイヤー化への発展（年次稼働率変動 + 4 アプローチ最適化の 5 年連結）
MAS-123	Story	📊 Report	31タブ発注残高・予算執行ダッシュボード	FP&A	P2	★★	未着手	—	発注済だが未請求のコミットメント残高（= 発注残高）を科目別/取引先別/PJ別に集計し、予算執行率を可視化するマート新設。①新設タブ: `68_ord_commitment`（発注残高ダッシュボード）。科目×月別のコミットメント残高、予算消化率（発注累計 ÷ 予算）、未請求残の推移。②実績との重ね表示: 41_trn_budget(予算) / 32_wrk_invoice(請求済) / 31_wrk_order 残高(発注済未請求) を三層で表示。③ビルダー: mas/600_report/ 配下に `609_datamart_commitment.js` を新設。	隠れた将来支出（コミットメント）を可視化。予算執行管理の精度向上。請求書到着前でも発注段階で予算超過を検知	集計粒度（月次 / 累計）の既定値。発注残高の定義（税込 or 税抜）。長期契約の按分表示（契約期間に均等展開するか）
MAS-141	Story	🧠 Domain	節税・共済効果シミュレーター（D.8 派生）	シミュレーション	P1.5	★★★	未着手	—	D.8 §2.f-6 抽出案件（Sonnet 提案 MAS-140 → 既使用のため ID シフト）。`mas/400_domain/` に `TaxSavingSimulator` namespace（新規ファイル）を追加。小規模企業共済（掛金上限月 7 万円・年 84 万円・全額所得控除）と経営セーフティ共済（月 20 万円・年 240 万円・全額損金算入・積立上限 800 万円）を対象に、想定当期利益・役員報酬・掛金から法人税・所得税の軽減額を計算。掛金 0 〜上限のスキャンで「限界節税額」を一覧提示。`301_ui_assist.js` にサイドバーエントリ追加、パラメータは `03_sys_params` で永続化。	1 人法人の最重要節税手段を定量化し、最適掛金設定を支援。手元資金の最大化に直結。MAS-041（繰越欠損金）/ MAS-049（賃上げ税制）は法人税額控除、本案件は役員個人の所得控除を含む複合節税シミュレーション（より包括的な「税引後キャッシュ最大化」を扱う）	所得税率の適用区分（課税所得ブラケット）の入力方法、経営セーフティ共済の解約時益金算入（出口リスク、2024/10 改正で解約後 2 年以内再加入は損金算入不可）の表示有無、税率パラメータの年次更新フロー

🎨 UX・UI（17 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-014	Story	🎨 UI	プロジェクト別予実ダッシュボード	UX	P2	★★	未着手	—	各PMが自身の担当プロジェクトの予算消化状況や利益率をリアルタイムで確認。	現場のコスト意識向上	PM向けに公開する情報の範囲（原価のみ or 利益率含む）
MAS-015	Story	🎨 UI	リソース稼働率のヒートマップ可視化	UX	P3	★	未着手	—	メンバーごとのプロジェクト稼働率をヒートマップ形式で可視化。	リソース配分の最適化	稼働率の目標値（100% or 80%を標準とするか）
MAS-021	Story	📊 Report	財務諸表のPDF/Excelエクスポート	UX	P2	★★	未着手	—	P/L・B/S・CFをフォーマット済みPDFまたはExcelで出力。	社外共有の効率化	出力フォーマット（銀行提出用 vs 取締役会用の違い）
MAS-023	Story	🎨 UI	月次経営コメント入力機能	UX	P3	★★	未着手	—	61/71の各月列に経営者コメントを紐付けて保存。NLP自動生成(MAS-191)の前段階。	定性情報の蓄積（小規模で導入可）	コメントの保存先（専用シート or セルノート）
MAS-118	Story	🧠 Domain	20番台予算タブに「起票ターゲット月」列を追加	UX・データ基盤	P1	★★	完了	2026-04-16	「最終起票年月日」が実績と指示の両方の意味で使われている問題を解消。「起票ターゲット月」列を新設し、指示（ここまで起票）と実績（ここまで起票済み）を分離する。→ 開発仕様書	RPA起票時の意図の明確化、入力ミス防止	DDL列追加による既存データの列ズレ影響、空欄時の挙動（スキップ vs フォールバック）
MAS-125	Story	—	発注ステータス遷移ワークフローの標準化	UX・ワークフロー	P2	★★	未着手	—	発注ステータス（見積中→発注済→納品完了→完納）の遷移ルールとログを標準化。①遷移ルール: 見積中→発注済（発注書送付時）、発注済→納品完了（検収時）、納品完了→完納（全INV計上済で自動）。②遷移ログ: ステータス変更日時・変更者・変更前後を履歴タブ（`38_ord_status_log`）に記録。③UI: onEditトリガーでステータス変更時にバリデーション（後戻り禁止 or 承認必須など）。	受発注プロセスの統制強化。「誰がいつ発注確定したか」の監査証跡。MAS-104（支払依頼ワークフロー）の前段階	ステータス後戻りの可否（取消・差戻しをどう表現するか）。検収日の定義（ORD側で管理 or 別タブ）
MAS-127	Story	🧠 Domain	発注書PDF発行（見積・注文・納品書）	ドキュメント生成	P3	★	未着手	—	MAS-100（請求書PDF発行）の兄弟機能として、発注書/注文書/納品書のPDFをテンプレートから自動生成。①対象: 31_wrk_order の「見積中」「発注済」「納品完了」の各ステータスで対応する帳票を発行。②テンプレート: Googleドキュメントテンプレート or HTML→PDF変換。T番号・自社情報・発注詳細を差し込み。③送付: 生成したPDFを証憑URLに自動紐付け、取引先へのメール送付機能（オプション）。	発注書の書類発行を自動化。取引先向けの書類整備で対外信頼性向上	テンプレートデザイン。帳票番号の採番ルール。MAS-100と共通化すべきコード範囲
MAS-130	Story	🎨 UI	フィルタービュープリセット配布（行積み上がり対策A）	UX・可視性	P1	★★★	未着手	—	行が数千行に達すると目視が困難になる問題への即効対策。WRK系タブ（31/32/33）と20番台予算タブに、用途別のフィルタービューをGASで生成・配布する。①プリセット例: 「未処理のみ」「当月発生」「今週締め分」「未消込STL」「承認待ち」など。②実装: `mas/300_ui/302_filter_presets.js` に `applyFilterPresets()` メニューを追加。各タブに対して `Sheet.getFilter()` をクリア→新規フィルタを作成し、ステータス列に条件付与。③配布: メニュー「🔍 表示フィルター」から任意プリセットを一発適用。④永続化: 最後に選んだプリセットをスクリプトプロパティに保存し、次回起動時に復元。	行数の多さによる体感速度・UX劣化を解消。実装1時間程度で効果絶大。MAS-131と合わせて行積み上がり問題のファーストライン対策	プリセットの列名依存（DDL変更時の追従）。フィルタ範囲の自動追従（行追加時）。複数ユーザーで別々のプリセットを使いたい場合の扱い（GASの制約で共有フィルタのみサポート）
MAS-131	Story	🔧 Infra	完了行の視認性向上（条件付き書式による自動グレーアウト）（行積み上がり対策B）	UX・可視性	P1	★★★	未着手	—	ステータスが「計上済」「完納」「消込済」「承認済」等の完了状態になった行を、条件付き書式で自動的に薄いグレー＋取り消し線風にし、アクティブ行と視覚的に区別する。①対象タブ: 31_wrk_order（発注ステータス='完納'）、32_wrk_invoice（請求ステータス='完了' or 自動仕訳JNL_ID あり）、33_wrk_bank（決済ステータス='消込済'）、35_wrk_receipt（処理結果='消込済'）、20番台予算タブ（最終起票年月日 ≠ 空）。②実装: `mas/100_config/101_sys_config.js` の `setupAllSchemas` 内で `SpreadsheetApp.newConditionalFormatRule()` を各シートに適用。背景色 `#EEEEEE`、文字色 `#999999`。③メニュー: 「🎨 書式を再適用」で手動再実行も可能に。	アクティブ行だけを即座に見分けられる。MAS-130のフィルタと併用すれば行数が多くても実質的に未処理分しか視界に入らない	条件付き書式の過多による描画速度低下（数万行規模）。DDL列追加時の書式範囲自動追従。ステータス名称変更時の書式ルール更新
MAS-132	Story	🎨 UI	月次行グルーピングの自動生成（行積み上がり対策D）	UX・可視性	P2	★★	未着手	—	行数が数千を超えた際の中期対策。32_wrk_invoice・33_wrk_bank 等の時系列タブで、発生日（P/L計上日）の年月別に行をグループ化し、過去月はデフォルトで折り畳み表示する。①実装: `mas/300_ui/303_row_grouping.js` に `rebuildMonthlyGroups()` を追加。発生日列を読み、同年月の連続行を `Sheet.getRange().shiftRowGroupDepth(1)` でグループ化。過去月は `Group.collapse()` で折り畳み。②自動再構築: マート更新後 or 月次締め完了後に自動実行。③UI: 「📂 月次グループ再構築」メニュー。	過去データを保持したまま視界を当月分のみに絞れる。MAS-130/MAS-131 では足りない数千行規模で効く	時系列順にソートされていないデータがある場合のグループ境界判定。グループ境界の再計算コスト（数万行で数十秒かかる可能性）。行追加時のグループ範囲自動拡張（GAS APIの制約）
MAS-184	Task	🎨 UI	コラボレーション・通知 (軽量版)	UX	P4	★	未着手	—	Action完了通知、月次締めリマインダー、承認待ち一覧の通知。	業務の円滑化	通知チャネル（Slack/Chatwork/メール）の選定
MAS-185	Task	🎨 UI	コンテキスト付きチャット連携	UX	P4	★	未着手	—	スプレッドシート上のコメントをSlack/Chatworkに自動通知。	コミュニケーションの迅速化	使用するチャットツールの確定
MAS-214	Task	—	自動生成型メニューカタログタブ (00_menu)	UX / 基盤	P1	★★	仕様書完了	04-20	→ 開発仕様書 `00_menu` タブを自動生成し、2 セクション構成で 1 枚に集約。セクション A (操作カタログ): `Constants.MENU_OPERATIONS` を SSOT として新設し、98_audit_log（MAS-179）と連携して各機能の最終実行日時 / 最終実行者 / 累計実行回数 / ステータス（⚠️未使用 / ✅稼働中）を可視化。`validateMenuRegistry_` で HTML サイドバーとの整合性を自動チェック。セクション B (シートナビゲーション): `01_sys_config` の GID を使った `HYPERLINK` で全タブへのワンクリック遷移、番号プレフィックス（00/10/20…）でカテゴリ自動グルーピング。前提案件: MAS-179 監査証跡（実装済 PR #157/#158/#205）、MAS-201 バックアップ（実装済 PR #209）	操作 SSOT 化 + 未使用機能検出 + 登録漏れ検知 + 40タブ超へのナビゲーション迷子解消の 1 タブ集約	集計期間設定、セクション配置順、シート保護の適用可否、シート単位のクイックアクション列追加
MAS-217	Task	—	サイドバー項目を MENU_DEFINITION に統合 + 視認性改善	UX / 観測性	P2	★★	仕様書完了	04-20	→ 開発仕様書。前提: MAS-214 完了。①MENU_DEFINITION 統合: `mas/templates/operations_sidebar.html` の 9 セクション・41 項目 (📒 経理業務 9 / 🔍 消込 7 / 📝 費用登録 1 / 📊 マート更新 5 / ⚙️ メンテナンス 4 / 🔧 開発・設定 7 / 🔧 マイグレーション 6 / 🔄 dev 1 / 🧪 テスト 1) を `Constants.MENU_DEFINITION` に追加。`updateMenuCatalog_` が自動展開し `00_menu` でサイドバー項目も利用状況を可視化。HTML 側は本 PR では変更しない (動的生成化は別案件)。②サイドバー視認性改善: CSS のみで (1) セクション別左ボーダー色 (2) 操作カテゴリ別背景色 (読取/書込/破壊) (3) 高頻度操作強調 (4) 検索ボックス (5) 折りたたみの 5 案を提示。推奨組合せは 1+2+4。	運用上ほぼ全ての操作の利用状況を `00_menu` で把握可能に。9 セクション 41+ ボタンの探索負荷を視認性改善で低減	description 41 項目の業務的妥当性レビュー、視認性改善案の採用選択 (1/2/3/4/5 の組合せ)、左ボーダーカラーパレット決定、条件付き項目 (dev/テスト) の扱い、サイドバー動的生成化の後続起票要否
MAS-232	Task	🎨 UI	サイドバー UI の SPA 化（Vite + React）	UX / 基盤	P2	★★	Stage 1 完了 / Stage 2 廃止（GAS 操作パネル廃止方針）	2026-04-25	→ 開発仕様書 / v1.0 初版 → v1.1 Gemini レビュー反映 → v1.2 PoC Stage 1 実地反映（PR #361 commit `274b67d`）。採用技術スタック確定: Vite 5.4.10 / React 18.3.1 / TypeScript 5.6.0 (`strict: true`) / vite-plugin-singlefile 2.0.3。ディレクトリ確定: `webapp_client/`（repo root 直下）。bundle 145KB (gzip 47KB)・CSP 違反 0・`google.script.run` 疎通 OK。Stage 1 PoC 完了（4/4 検証クリア）・`webapp_client/` 基盤は Cockpit（MAS-057/MAS-364 等）で継続利用中。Stage 2（`operations_sidebar.html` SPA 移行）は GAS 操作パネル廃止方針（2026-05-11）により中断。	→ MAS-217（サイドバー統合）の続編。段階 2 として SPA 化で 5-20 倍の応答改善。①現状: `mas/templates/operations_sidebar.html` は 9 セクション 41+ 項目の素の HTML + vanilla JS。ボタン毎に `google.script.run` ラウンドトリップ（500ms-2s）が発生。②移行先: Vite + React（TypeScript）で SPA 化。初回ロード時に `google.script.run.getInitialState()` で全マスタ + 必要データを 1 往復取得、以降の画面遷移・フィルタ・検索はクライアント完結。③実装構成: `mas/templates/sidebar_spa/src/` に React ソース、`vite.config.ts` で `dist/bundle.js` を生成、`HtmlService.createHtmlOutputFromFile('sidebar_spa_shell.html')` が bundle を読み込む。④段階移行: (a) MAS-147 v2 HitL サイドバー / (b) MAS-175 OCR 失敗フォーム / (c) MAS-174 小口現金入力 / (d) MAS-217 既存サイドバー統合版の順で 4 段階展開。⑤状態管理: Zustand or Jotai（Redux はオーバースペック）。⑥型安全 API bridge: `api/gas-bridge.ts` で `google.script.run` を typed wrapper 化、サーバー関数シグネチャを `docs/spec/sidebar_api.d.ts` に集約。⑦Jr 向け好案件: React/TS 経験者にとって会計ロジックを深く知らずに進められる独立領域。前提: MAS-224 CI（ESLint / Vite build）、MAS-230 採用要件（React/TS 優遇）	サイドバー操作の体感 5-20 倍改善 + Jr の初期戦力化で一石二鳥。`google.script.run` ラウンドトリップを 1/10 以下に削減
MAS-358	Story	🎨 UI	Cockpit 折りたたみ式左サイドバーナビゲーション（GAS スプレッドシートメニュー廃止）	UX / 基盤	P2	★★★	未着手（仕様書完了 v1.1）	2026-05-03	→ 開発仕様書。推奨実装順: MAS-356 → MAS-358 → MAS-357。Phase 1: `webapp_client/src/cockpit/CockpitNavSidebar.tsx` 新設 — Cockpit（`CockpitApp.tsx`）と MultiyearApp（`MultiyearApp.tsx`）に折りたたみ式左サイドバーを追加。スプレッドシートメニューとの並行稼働期。`getInitialStateForSpa('cockpit')` の戻り値に `menuDefinition: Constants.MENU_DEFINITION` が既に含まれているため GAS 側追加変更不要。Phase 2: `101_sys_config.js` の `createMenu` 呼び出し削除でスプレッドシートメニューを廃止。前提: MAS-232（`webapp_client/` 基盤・Stage 1 完了）。関連: MAS-356（Tremor UI 先行推奨）/ MAS-357（Firebase Hosting 移行・後続）/ MAS-057（Cockpit）/ MAS-067（Multiyear）/ MAS-364（受取領収書・Cockpit 拡張）。	GAS 操作パネル廃止後の操作導線を Cockpit 内サイドバーに集約。Cockpit を主動線とする UX 統一・SaaS 化（MAS-357）の前提工事。MAS-364 等の各画面固有サイドバーと組み合わせて 2 層ナビ（左ナビ + 画面固有）を実現	MAS-356 完了を待つか同時着手か、各画面固有サイドバー（MAS-364 等）との実装分担、Phase 2 メニュー廃止タイミング（並行稼働期間の設計）、MultiyearApp への適用範囲
MAS-249	Story	—	Attestation 検証の顧客向け提供機構	UX・セキュリティ	P3	★★	未着手	—	顧客が「本当に運営者でも閲覧不能な環境で計算されている」を自ら検証できる仕組み。①Attestation レポート取得 API: 顧客向け REST エンドポイントで現在の Enclave の計測値・署名情報を取得可能に。②検証ツール提供: 顧客側で Attestation レポートの署名検証・Enclave ハッシュ比較を自動化する CLI または Web ツールを提供。③非技術顧客向け説明: 「第三者（学術機関・監査人）が同じ検証をしている」ことを添える運用。④ソースコード公開: Enclave 内で動く集計ロジックを OSS 化し、ハッシュ一致を誰でも確認可能にする。	「信頼しろ」ではなく「検証できる」プロダクト。「信頼設計」ブランドとの完全整合	検証ツールの提供形態（CLI / Web / SDK）、技術顧客 vs 非技術顧客向けの説明レイヤー分離、OSS 化範囲の決定、検証サービス自体を付加価値として有料化するか
MAS-364	Story	🎨 UI	Cockpit 受取領収書 PDF インポートタブ（月次財務諸表の左に新規タブ追加）	UX / データ取込	P2	★★★	未着手	—	Cockpit Web アプリに `receipt_import` タブを新設（月次財務諸表タブの左に配置）。①タブ UI: `ReceiptImportPanel.tsx` コンポーネント新規作成。処理済 / 未処理の PDF 一覧、ステータス表示（消込済 / OCR 待ち / 手動確認要）。②インポート起点: Google Drive 指定フォルダから PDF を取り込み、既存 `502_receipt_reader.js` の Gemini OCR パイプラインに連携。③マッチング: OCR 結果を `35_wrk_receipt` に登録し、INV / STL との消込候補を提示。④GAS ブリッジ: `302_spa_bridge.js` に `handleReceiptAction()` を追加。取込・消込・再 OCR アクションを統一エンドポイントで受け付ける。前提案件: MAS-232（Cockpit SPA 基盤）、MAS-157（写真 OCR）、MAS-216（Vertex AI 移行）	領収書 PDF の取込〜消込を Cockpit から一貫して実施できる UX 統合。Drive を都度開かずに月次処理が完結。MAS-157 / MAS-147 で整備された OCR 基盤を UI から利用可能にする	Drive フォルダの権限設計（領収書取り込み専用フォルダ）、タブ配置順（月次財務諸表の左確定 or ユーザー設定可）、MAS-157（写真 OCR）と MAS-147（請求書 OCR）との処理フロー統合方針、サイドバー `receipt_import` タブと既存メニュー「📥 経理業務」との重複整理

🛡️ セキュリティ（20 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-179	Task	🧠 Domain	監査証跡の強化 (Audit Trail)	セキュリティ	P1	★★	完了	2026-04-20	「誰が・いつ・何を・どう変更したか」を記録する専用ログシート。98_audit_log 新設、Utils.auditLog API、6 種類の計装点。→ 開発仕様書	内部統制の強化	ログの保持期間と容量制限の設定
MAS-187	Task	🛠️ Ops	ロールベースのアクセス制御 (RBAC)	セキュリティ	P2	★★	未着手	—	役割に基づく閲覧/編集/承認の権限管理。①ロール定義: 経営者（全権限）、経理（マスタ編集+仕訳+決算）、PM（PJ系タブ+工数のみ）、一般社員（経費申請+自分の給与明細のみ）。②GAS実装: `Session.getActiveUser()` でメールアドレスを取得→ロール判定テーブル（03_sys_params or 専用シート）照合→メニュー表示/非表示を切替え。保護シート（`sheet.protect()`）で編集権限をロール別に設定。③給与データ保護: 22_bud_headcount は経営者+経理のみ閲覧可。PM・一般社員にはシート非表示+保護。	情報漏洩・誤操作の防止。会社規模拡大時の内部統制の基盤	ロール数と粒度（4段階で十分か）。Google Workspace のグループ/OU との連携方法。GAS のシート保護 API の制限
MAS-188	Task	—	エンタープライズ・セキュリティ要件対応（FISC/J-SOX/PCI DSS/SOC 2）	セキュリティ	P3	★★	未着手	—	金融業界・内部統制の主要セキュリティ基準に段階対応。GAS+スプレッドシートで現実的に実装可能な範囲を明確化。【FISC安全対策基準】 ①アクセス管理: MAS-187(RBAC)で対応 ②ログ管理: MAS-179(監査証跡)+GAS関数実行ログ(関数名・実行者・日時・処理件数)を専用シートに自動記録 ③データ保護: MAS-201(バックアップ)+シート保護自動設定(setupAllSchemas時にautoCols編集不可化) ④障害対策: バックアップからの復元手順書。【J-SOX IT統制】 ①職務分掌: MAS-187のロール別権限で「入力者≠承認者」を担保 ②アクセス権管理: 四半期ごとの棚卸し(共有設定レビュー) ③変更管理: Git履歴+clasp push前のレビュー体制 ④ログ監査: 月次で操作ログの異常パターン検出(大量削除・時間外操作等)。【PCI DSS】 GASでカード番号は保持しない方針（CC明細は金額・日付・加盟店名のみ）。34_wrk_cardにカード番号列が無いことを定期検証。【SOC 2】 ①可用性: MAS-201(バックアップ) ②機密性: MAS-200(個人情報保護) ③処理の完全性: MAS-179(監査証跡)+データバリデーション(201_data_validator.js)。【共通】 APIキー管理: ローテーション手順書+最終更新日記録+有効期限アラート。	金融業界水準のセキュリティ体制を段階的に構築。IPO準備・金融機関取引・監査対応の基盤。GASの制約内で各基準の「対応可能項目」と「対象外項目」を明確にし、過不足なく実装	GASの技術的制約（通信の暗号化はGoogle基盤任せ、ScriptPropertiesは平文保存）。Google Workspace Business以上の機能（Vault・DLP・コンテキストアウェアアクセス）との棲み分け。外部監査人への説明資料の準備
MAS-200	Task	🛠️ Ops	個人情報保護・給与データのアクセス制限	セキュリティ	P2	★★	未着手	—	個人情報保護法対応として、給与・報酬データ（22_bud_headcount）のアクセスを厳格化。①シートレベル保護: 22tab を経営者+経理のみ編集可、他ユーザーにはシート非表示。②マスキング表示: PM 向けに人件費の「PJ 別合計額」は表示するが個人別金額は非表示（78_pj_pl の人件費行は合算値のみ）。③マイナンバー等の機密情報: GAS スプレッドシートでは管理しない方針を明文化（MAS-261 スコープ外と連動）。④共有リンクの管理: スプレッドシートの共有設定を定期チェック（不要な共有者の検出・通知）。関連: MAS-254 プライバシーマーク取得と統合運用。	個人情報の漏洩リスクを最小化。従業員の信頼確保。個人情報保護法の安全管理措置に対応	共有設定の監査頻度。外部委託先（会計士等）への共有範囲。退職者のアクセス権即時剥奪のフロー
MAS-201	Task	🛠️ Ops	スプレッドシート定期バックアップ	セキュリティ	P1	★★★	完了	2026-04-20	→ 開発仕様書	GAS 時間トリガーで自動バックアップ。①週次バックアップ: スプレッドシート全体を `SpreadsheetApp.copy()` で別フォルダにコピー。ファイル名に日付付与（`BizLP_backup_YYYYMMDD`）。②世代管理: 直近12週分を保持、13週目以降は自動削除。月末バックアップは12ヶ月保持。③復元手順書: バックアップからの復元方法をドキュメント化。④バックアップ検証: 月1回、バックアップファイルを開いてデータ件数を検証する自動チェック。	「うっかり全消し」からの復元を保証。Google Sheets のバージョン履歴は30日で切れるため独自バックアップが必要
MAS-205	Task	🔧 Infra	GASフェーズ: MFA義務化と特権アカウント分離	セキュリティ	P3	★★★	完了	2026-04-21	財務データを扱う全ユーザーに2段階認証(MFA)を義務化。日常業務用と特権管理者アカウントを分離し、システム設定(setupAllSchemas等)は特権アカウントでのみ実行。→ 開発仕様書。Part 2 (GAS 特権アカウント分離): `isPrivilegedUser_` + MENU_DEFINITION privileged フラグ + Defense in Depth 実装済。Part 1 (MFA 義務化): 2026-04-21 に Workspace 管理コンソールで 8 項目設定完了、代表者のパスキー登録完了、ログイン時に 2FA 要求が発動することを確認済。Admin レポートの「適用」列は新規登録期間 7-14 日の猶予表示で後日「適用済み」に自動更新予定	アカウント乗っ取りによる財務データ漏洩の防止。GAS構築フェーズの最優先セキュリティ対策	Workspace管理コンソールへのアクセス権限。特権アカウントの命名規則と運用フロー
MAS-206	Task	🛠️ Ops	GASフェーズ: 外部共有の制限と警告設定	セキュリティ	P3	★★★	完了	2026-04-20	予算・実績データを含むスプレッドシートが意図せず社外に流出するのを防止。Google Workspace管理コンソールでドメイン外共有を制限、または共有時に警告ダイアログを必須表示に設定。Drive監査ログで外部共有イベントを定期チェック。→ 開発仕様書	財務データの社外流出リスクの排除。MAS-200(個人情報保護)と連携	ドメイン外共有を完全禁止 or 警告のみにするかの判断。外部税理士・会計士への共有の例外ルール
MAS-207	Task	🛠️ Ops	GCP移行: IAM最小権限とコンピュート/ストレージ分離	セキュリティ	P4	★	未着手	—	GCP(BigQuery等)移行時のIAMアーキテクチャ設計。プロジェクトレベルの広範な権限付与を避け、コンピュート(クエリ実行: `roles/bigquery.jobUser`)とストレージ(データ閲覧: `roles/bigquery.dataViewer`)の権限を完全分離。最小権限の原則を厳格に適用。	権限の過剰付与による内部不正・誤操作の防止	GCPプロジェクト構成（本番/開発/ステージング）。サービスアカウントの設計。Workload Identity Federation の検討
MAS-208	Task	🛠️ Ops	GCP移行: VPC Service Controls によるデータ持ち出し防御	セキュリティ	P4	★	未着手	—	IAMに加えてVPC-SCを導入し、アクセス元のコンテキスト(IPアドレス、デバイス)を制限。財務データの外部への不正持ち出し(エクスフィルトレーション)を境界防御で防止。BigQueryからの大量エクスポートをブロック。	ゼロトラストアーキテクチャの実現。IAM突破時のフォールセーフ	VPC-SCの対象サービス(BigQuery, GCS, Cloud Functions)の範囲。アクセスレベルの設計（社内IP/VPN）
MAS-209	Task	🛠️ Ops	GCP移行: Cloud KMS による顧客管理暗号鍵(CMEK)	セキュリティ	P4	★	未着手	—	Googleデフォルト暗号化に加え、Cloud KMSで顧客管理の暗号鍵(CMEK)を導入。BigQueryデータセット・GCSバケットをCMEKで暗号化。鍵のローテーションポリシー(90日)を自動設定。	暗号鍵の完全な管理権限を自社で保持。コンプライアンス要件への対応	CMEK vs Google管理鍵のコスト比較。鍵の管理責任者の任命。鍵消失時のリスク対策
MAS-210	Task	🛠️ Ops	GCP移行: Security Command Center と監査ログの自動化	セキュリティ	P4	★	未着手	—	Security Command Center(SCC)とCloud Audit Logsを活用し、異常なデータ大量エクスポート・権限変更・不正アクセスを継続的に監視。アクセス制御とインフラ構成をTerraform(IaC)で管理し、手動設定の逸脱を自動検出。	セキュリティ監視の自動化。手作業による設定ドリフトの防止	SCC Standard vs Premium の選定。Terraform の導入計画。アラート通知先と対応フローの設計
MAS-211	Task	🛠️ Ops	GCP移行: SOC 2 / ISO 27001 準拠とゼロトラスト設計	セキュリティ	P4	★	未着手	—	財務システムとしてSOC 2 Type IIおよびISO/IEC 27001の認証基準に準拠する設定を維持。ゼロトラスト原則(すべてのアクセスを検証)とSecurity by Designに基づくアーキテクチャを設計。BeyondCorp Enterprise等の導入を検討。関連: MAS-251 第三者監査・学術パートナー連携プログラムの認証取得フェーズと統合。	IPO準備・大企業取引・グローバル展開時のコンプライアンス基盤	認証取得のタイミング(IPO計画との連動)。認証取得コストと維持コストの見積もり。外部監査法人の選定
MAS-213	Task	🔧 Infra	監査ログシート(98_audit_log)の編集禁止保護	セキュリティ	P1	★★★	仕様書完了	—	MAS-179（監査証跡）の続編。現在 98_audit_log は通常ユーザーが手動編集・削除できてしまい、改ざん耐性（WORM: Write Once Read Many）が担保されていない。①シート保護: `Sheet.protect()` で 98_audit_log 全体を保護し、編集者を Workspace 管理者アカウント（特権アカウント, MAS-205 と連動）に限定。一般ユーザーは閲覧のみ可。②setupAllSchemas での自動適用: DDL 実行時に保護設定も冪等に再適用（手動解除されても元に戻る）。③自動再生成の挙動: ユーザーが誤ってシートを削除した場合、次回 `Utils.auditLog()` 呼び出しで自動再作成し、保護も再付与（dev_N-03 §"検討事項" を参照）。④GAS スクリプトからの追記は許可: シート保護下でも GAS 実行時はオーナー権限で書き込み可能なことを動作確認。⑤運用ドキュメント: 「監査ログを編集してはいけない理由」と「不正アクセス疑い時の確認手順」を docs/ops に追記。→ 開発仕様書	監査ログの改ざん耐性を確保。内部統制・税務調査・SOC2 における監査証跡の信頼性を担保。MAS-205（特権アカウント分離）と組み合わせることで、ログを改ざんできるのは Workspace 管理者のみとなる	編集権限を持たせる管理者アカウントの粒度（経営者のみ / 経理リーダーまで含めるか）。GAS の Protection API がトリガー実行（onEdit）にも適用される挙動の検証。GitHub Actions の prod デプロイ時に保護設定が剥がれないか確認
MAS-216	Task	—	本番 AI API を Vertex AI に移行 (Claude 実装 + Gemini 移行)	プラットフォーム・セキュリティ	P2	★★	完了	2026-04-24	→ 開発仕様書 / ADR-0008 / 実装完了 (PR #347・領収書 OCR に Claude Sonnet フォールバック ADR-0007 含む)。MAS-215 完了後に着手。①Vertex AI 基盤: 両プロジェクトで Vertex AI API 有効化、`asia-northeast1` 優先 / `us-east5` フォールバックでリージョン選定、認証方式を Service Account ベースに統一。②`callClaudeApi_()` Vertex 実装（ADR-0007 残タスク）: `mas/000_infra/004_utils.js` に Vertex AI Claude エンドポイント経由で新規実装。JSON パース失敗・必須フィールド欠落時のエラーハンドリングを含む。③Gemini OCR の Vertex 移行: `mas/500_import/502_receipt_reader.js` の `callGeminiForReceipt_()` を `generativelanguage.googleapis.com` から Vertex AI エンドポイント (`{region}-aiplatform.googleapis.com`) に書き換え。既存領収書 PDF での回帰テストで同等精度を確認。④既存スクリプトプロパティの整理: `CLAUDE_API_KEY` / `GEMINI_API_KEY` は移行完了後に削除。⑤並行稼働期間: 新旧両系統を一時的に維持し、dev 環境で検証後 prod に切替。	商用 SaaS 前の本番 AI 契約の整備。subprocessor を Google 1 社に集約し、DPA・監査ログ・課金・認証を GCP で一元管理。Anthropic 直契約が不要になり運用負荷削減	認証方式の選定（Service Account JSON vs `ScriptApp.getOAuthToken()`）、並行稼働期間の長さ、Gemini モデル ID (`gemini-2.5-flash`) の Vertex 側同名利用可否、リグレッションテスト手順、移行後のコスト差分検証、MAS-147/MAS-150 等の新規 Claude 利用案件との着手順序
MAS-222	Task	🛠️ Ops	開発端末・リモート開発環境のセキュリティポリシー整備	セキュリティ	P3	★★	未着手	—	現状ギャップ: プロダクト側のセキュリティ (MAS-200/MAS-205/MAS-206/MAS-213、NFR-S01〜S06) は整備済だが、開発者側の端末・環境に関する規定が不在。本案件で以下 4 領域のポリシー文書（`docs/_internal/biz/dev_environment_security.md` 新設）を整備する。①開発端末 (MacBook) 基本要件: FileVault 2 有効化 / 自動画面ロック 5 分 / OS 自動アップデート / マルウェア対策 (XProtect で基本可) / 使用中以外の退席時ロック。②機密情報のローカル保管ルール: `creds.json` (clasp OAuth)、`.env` (GEMINI_API_KEY / CLAUDE_API_KEY 等)、バックアップ JSON ファイルの保管場所 (暗号化ディスク内のみ)・共有禁止・盗難紛失時の失効手順 (Google アカウント・Anthropic Console での即時失効)。③リモート開発環境の利用可否: GitHub Codespaces / Gitpod / Cloud Workstations / VPS SSH / devcontainer / JetBrains Gateway 等のクラウド IDE を利用する場合の要件（顧客データにアクセスしない dev 環境限定 / リポジトリに commit 可能な情報のみ / Anthropic API キーは環境変数注入で commit しない）。claude.ai Web アプリ / Mac アプリ利用時の機密データ扱い (プロンプト送信時の自動学習オプトアウト確認)。④BYOD / 個人 PC での作業規定: 一人会社段階では代表者の MacBook のみのため実質 BYOD 状態。将来委託・協力者を迎える際の PC 要件 (会社貸与 or 個人 PC + MDM)、個人 PC 撤退時のデータ削除証跡。⑤連動案件: MAS-205 (MFA) / MAS-206 (外部共有) / MAS-200 (個人情報) / MAS-254 (P マーク取得) の運用規程群に本案件で開発端末パートを追加補完	プロダクト側は固めたが開発者の手元が無防備という非対称リスクの解消。パスキー登録・MFA 済の代表者 PC が盗難された場合でも、FileVault + 画面ロックで財務データ流出を阻止。将来の外注・協力者拡大・プライバシーマーク (MAS-254) 取得時の必須規程として先行整備	開発端末要件の強度 (FileVault のみ or EDR 導入まで踏み込むか)、リモート IDE の許可リスト (Codespaces は許可 / Gitpod は不可等の判断基準)、claude.ai アプリ利用時のプロンプト送信ポリシー (顧客機密を含む調査の送信可否)、個人 PC での作業範囲 (OSS / ドキュメント OK、顧客データアクセスは貸与 PC のみ等)、顧客委託契約におけるセキュリティ要件との整合 (顧客から要求される水準を先取り)、MDM 導入の費用対効果 (Google Workspace Business Standard の Endpoint Management は有効化可能)
MAS-229	Task	🛠️ Ops	Jr 特権分離（GAS / GCP / Workspace 権限最小化）	セキュリティ・組織	P3	★★	未着手	—	→ Jr が参加しても本番データに事故でアクセスしない権限設計。MAS-205（MFA 義務化・特権分離）の発展形。①Workspace 権限: Jr には Business Standard 以上のユーザー追加。Drive の `Corporate` 共有ドライブ（機密契約書・給与情報）は閲覧権限も付与しない。開発用共有ドライブ `Dev` のみアクセス可。②GAS 権限: Jr は dev プロジェクト（`bizlp-gas-accounting-dev`）のみ編集可。prod プロジェクトは閲覧（読取）まで、デプロイ不可。`.clasp.prod.json` の credentials は Sr のみ保持。③GCP 権限: Jr に dev プロジェクトの `Editor` 権限、prod は `Viewer` まで。課金情報・IAM 管理は Sr のみ。④GitHub 権限: bizlp リポジトリの `Write` 権限（main への直 push は MAS-225 で禁止）、`Admin` は Sr のみ。secrets へのアクセス不可。⑤スプレッドシート本体: 実データの入った本番スプレッドシートは閲覧不可。テスト用スプレッドシートを複製して Jr に共有。⑥離脱時チェックリスト: Workspace アカウント停止 / GitHub 権限剥奪 / GCP IAM 削除 / Slack 退出 / PC 回収 / データ消去証跡取得。`docs/_internal/biz/offboarding_checklist.md` を MAS-228 と同時整備。⑦監査: 月次で IAM 設定を自動エクスポートして差分レビュー（将来 MAS-210 と連動）	最小権限原則で Jr 参加時の事故リスクを構造的に減らす。prod データ消失・情報漏洩・誤デプロイを権限設計で防ぐ。SOC 2 / P マーク取得時も有利	閲覧を許可する本番スプレッドシートの範囲（集計結果のみ / 全く見せない）、dev/prod の完全分離 vs 一部共有の判断、Jr に secrets の何を渡すか（Gemini API キー等、dev 用は OK か）、緊急対応時の一時権限付与フロー、監査ログ定期レビューの担当（Sr 月次 30 分）、離脱時のデータ消去証跡の形式（スクショ or IAM ログ）
MAS-234	Epic	—	セキュリティ基準準拠ロードマップ（CIS Controls v8 + NIST CSF 2.0 + ISO 27001 + FISC）	セキュリティ・ガバナンス	P1	★★★	仕様書完了	2026-04-22	→ 開発仕様書 / マッピング台帳。投資家アピール・金融機関顧客監査・P マーク取得（MAS-254）の前提基盤。CIS Controls v8 を骨格に段階的セキュリティ統制を実装する 7 Phase ロードマップ。Phase 0 現状把握（1-2h・即着手）: `mas/800_ops/814_audit_security_config.js` で GAS / Workspace / GCP 設定を `99_security_audit` に出力。Phase 1 基礎衛生（4-6h・即着手）: gitleaks + `appsscript-json-guard.yml` で failure_pattern #26 再発防止。Phase 2 アクセス管理（4-6h）: Drive 権限月次監査 + GCP SA 最小権限化。Phase 3 監査・ログ（6-8h）: MAS-213 実装 + Gemini 異常操作検知。Phase 4 データ保護（4-6h）: 暗号化証跡 + 証憑改竄防止。Phase 5 インシデント対応（仕様書起票のみ）: `incident_runbook.md` / `incident_log.md`。Phase 6 ガバナンス（仕様書起票のみ）: `ADR-0010 security_policy.md` / データ分類。既存案件 MAS-179/MAS-201/MAS-205/MAS-206/MAS-213/MAS-214/MAS-215/MAS-216/MAS-222/MAS-229/MAS-152 を横断マッピングし、MAS-234 の実質スコープは各 Phase のギャップ埋めに集約。エッジケース 10 件 + 人間検討事項 10 件	セキュリティインシデントの構造的予防 + 外部監査対応基盤の確立。failure_pattern #26 再発防止・CIS IG1 充足率 80%+ 目標・将来の SOC 2/ISO 27001 認証（MAS-211）の下敷き	Phase 5-6 実装タイミング、Gemini 異常検知の妥当性、CIS IG1 充足率目標、FISC 対応の深さ、SOC 2/ISO 27001 着手時期、外部監査依頼タイミング、Jr 教育カリキュラム、インシデント連絡フローの個人情報管理、マッピング台帳の半期更新運用、コスト試算
MAS-246	Story	🔧 Infra	TEE（Trusted Execution Environment）基盤構築	プラットフォーム・セキュリティ	P3	★★★	未着手	—	主要クラウド事業者の Confidential Computing 機能を中核に、顧客データを「計算時も含めて運営者から見えない」実行環境を構築。①基盤選定: 主要クラウドベンダーの Confidential Computing サービスから選定（成熟度・日本リージョン対応・Attestation 機能の堅牢性で評価）。②Enclave 内処理: 集計ロジック・DP ノイズ付与・暗号化出力までを Enclave 内で完結。③Attestation レポート: Enclave 起動時の計測値・署名を顧客に開示し、「このコードがこの環境で動いている」を暗号学的に証明する機構を実装。④ホスト分離: Enclave 外には生データ・集計中データが一切出ない設計を担保。⑤接続基盤連携: 顧客環境 → Enclave の接続経路も同時設計（MAS-248 参照）。前提/連携: MAS-240 (データ移行) の前段階として組み込み、または並列配置。	「秘密計算×管理会計」という国内で実装事例ほぼ皆無のポジション確立。既存プライバシーテック事業者との差別化軸（業務ドメイン特化）	クラウドベンダー選定基準、Enclave メモリ制約下でのランタイム環境構築方式、Attestation 検証ツールの顧客提供形態、Enclave 外からの監視・ログ取得の粒度
MAS-248	Story	🛠️ Ops	顧客環境 ↔ TEE 接続基盤	ネットワーク・セキュリティ	P3	★★	未着手	—	顧客環境から TEE（Enclave）への暗号化済みデータ転送路を WireGuard ベースのメッシュ VPN 技術で構築。①初期導入: SaaS 型メッシュ VPN の個人プランで開始、一人会社規模では機能要件を満たしビジネス利用も公式に許可されている範囲。②将来的な自己ホスト化検討: 認証基盤のメタデータ主権まで確保したい場合の OSS 自己ホスト移行パス。③WireGuard E2E 暗号化: 通信内容はサービス事業者にも見えない設計を前提。④接続アーキテクチャ: 顧客環境側にエージェント常駐、TEE 側にエンドポイント配置、P2P 直結を優先しリレー経由を例外とする。	VPN・ポート開放・固定 IP 不要で顧客環境と Enclave を安全接続。クラウド IDE 経由接続等の単一アカウント依存リスクも回避	SaaS プラン移行タイミング、自己ホスト化の判断基準、リレーサーバー自前化の要否、顧客環境側のエージェント導入承認プロセス
MAS-254	Story	🛠️ Ops	プライバシーマーク取得	認証・事業	P3	★★★	未着手	—	顧客の個人情報を扱う位置づけである以上、早期取得を推奨。①取得要件確認: 認定機関の要件チェック、取得支援コンサル会社候補選定。②個人情報取扱い棚卸: `bizlp-gas-accounting` 内で個人情報に該当する項目の整理（従業員情報、取引先担当者情報等）。③社内規程整備: 個人情報保護規程、従業員教育計画、インシデント対応手順。④審査対応: 書類審査 → 現地審査の準備。⑤更新対応: 2 年ごとの更新審査への継続対応。前提/連携: MAS-200 個人情報保護・給与データのアクセス制限と統合、MAS-253 契約書条項との整合性強化。	BtoB 営業における信頼性の基礎要件クリア。MAS-253 の契約書条項との整合性強化	取得時期（PoC獲得前 or 後）、外部コンサル利用の要否と費用、社内運用体制の構築、取得後の社内監査頻度

🏗️ プラットフォーム・アーキテクチャ（19 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-133	Story	💾 Data	年度跨ぎアーカイブ機構（行積み上がり対策E）	データ基盤	P2	★★	未着手	—	行数が数万に達する長期運用時の対策。毎年度終了時に前年度分のデータを別タブ or 別スプレッドシートへ自動退避し、現行タブは当年度分のみに絞る。①退避先: `32_wrk_invoice_archive_YYYY` のような年度別アーカイブタブ（同一スプレッドシート内） or 別スプレッドシート（大規模時）。②マート影響: mas/600_report/ 配下のマート集計関数を、現行タブ＋アーカイブタブの両方を読むように改修。③実装: `mas/800_ops/812_migration_fiscal_year_rollover.js` に `archiveFiscalYear(yyyy)` を新設。冪等性あり（既退避分はスキップ）。④監査対応: アーカイブデータは読み取り専用に設定（保護範囲）。⑤対象タブ: WRK系3タブ + 42_trn_journal が優先。	長期運用時のスプレッドシート肥大化・速度劣化を根本解決。5年10年運用時の必須基盤	アーカイブ粒度（年度単位 / 月単位）。別スプレッドシート化の判断基準（セル数 / 行数）。マート集計の横断読み込みコスト。アーカイブ後のデータ修正が必要なケースの運用
MAS-142	Story	💾 Data	`workType` 列の DDL 追加とデータモデル拡張（D.8 派生）	インフラ	P2	★★	未着手	—	D.8 §1.2 抽出案件（Sonnet 提案 MAS-141 → MAS-140 既使用の連鎖シフト）。`14_mst_project` および `42_trn_journal` に `workType` 列（値域: RICE / VALUE / RND / OVERHEAD）を DDL で追加（`101_sys_config.js` 更新）。既存データへのデフォルト値適用は `mas/800_ops/810_migration_s70.js` として実装（CLAUDE.md 記載の次空き番号 810 を使用）。冪等性チェック必須。`101_sys_config.js` のマイグレーションメニューに登録。	MAS-043（ハイブリッド 2 トラック採算管理）の実装前提データ基盤の整備。工数種別の分析軸を統一し PSF のビリング稼働率計算を可能にする。MAS-043 は `workType` を用いた分析・可視化機能、本案件はデータモデル変更そのもので責務を明確に分離	`42_trn_journal` への列追加が Action A/B の既存処理に影響しないか事前確認、`workType` のデフォルト値（OVERHEAD 適用予定）、過去仕訳への遡及適用の範囲と判断基準、MAS-043 の「案件種別」列（RICE/VALUE/SEED）との命名整合（`workType` は 4 値で RND / OVERHEAD を含む）
MAS-143	Story	🌐 Cross	フリーランス新法対応管理機能（D.9 派生）	インフラ	P2	★★	未着手	—	D.9 §9.6 抽出案件（Sonnet 提案 MAS-142 → MAS-140 既使用の連鎖シフト）。フリーランス保護新法（2024 年 11 月 1 日施行）への準拠。`12_mst_partner` に `freelance_contract_date`（最終契約日）/ `payment_cycle_days`（支払サイト日数）列を DDL で追加（`101_sys_config.js` 更新）。`mas/800_ops/` または `mas/400_domain/` に支払サイト 60 日超過チェック関数を追加し `301_ui_assist.js` の定期チェックメニューから実行可能に。`31_wrk_order` のステータス更新時に中途解除 30 日前予告アラートをトリガー。	フリーランス保護法の意図せぬ違反リスクを低減（違反で 50 万円以下罰金 + 公表）。業務委託先との法令準拠な取引関係の維持。既存取引先管理は会計処理が主目的、本案件はコンプライアンス（法令遵守）特化機能で罰則リスク回避という非財務的価値	支払サイト超過時のアラートレベル（警告 or 取引ブロック）、契約書テンプレート管理は GDrive 等外部システムと割り切るか、年次契約更新の確認リマインダーを含めるか、MAS-223 Jr オンボーディングとの重複チェック
MAS-177	Task	🔧 Infra	多年度データ基盤の構築	アーキテクチャ	P1	★★	未着手	—	複数年度にまたがるデータを保持・集計できる構造。	全シミュレーションの前提基盤	保持年数（過去3年+将来5年等）の決定
MAS-192	Task	🧠 Domain	Repository パターンの完全移行＋ドメイン別モジュール分割	アーキテクチャ	P2	★★	完了	2026-04-16	401_bat_rpa.js（93KB・6ドメイン混在）を業務ドメイン別に分割し、Repository/DTO パターンを完全適用。①ファイル分割: `401_rpa_hc.js`（給与・MAS-099残業・MAS-108源泉税・MAS-109賞与）、`402_rpa_subscription.js`（SaaS定期）、`403_rpa_capex.js`（設備投資・償却）、`404_rpa_finance.js`（財務取引）、`405_rpa_adhoc.js`（単発経費）、`406_rpa_pipeline.js`（売上パイプライン）に分割。`410_subledger_engine.js`（Action A/B）、`420_project_profitability.js`（PJ損益）は番号繰り上げ。②Repository移行: 各RPAモジュールの読取側を `OrderRepository`/`InvoiceRepository` 経由に統一。直接の `sheet.getDataRange()` を排除。③共通関数の抽出: ID生成（`generateInvId_`等）・冪等性チェック（`isDuplicate_`）・日付計算をmas/400_domain/400_rpa_common.jsに集約。④段階実施: 新機能（MAS-099/MAS-109等）実装時に該当部分を切り出す形で段階的に進める。一括リファクタリングは避ける。→ 開発仕様書	93KBの巨大ファイルを保守可能なサイズに分割。freeeのようなドメイン別モジュール構成に近づく。新機能追加時の影響範囲が明確に	分割時のGASロード順序（番号体系の再設計）。共通関数の依存関係整理。テスト（901_test_runner.js）の関数参照更新
MAS-193	Task	💾 Data	DTO バリデーション層の追加	アーキテクチャ	P2	★★	未着手	—	Repository.append() 時に必須項目・型チェックを自動実行。	データ品質の自動担保	バリデーションエラー時の動作（ブロック or 警告のみ）
MAS-215	Task	🔧 Infra	GCP プロジェクトを bizlp 組織配下に整備 (dev/prod 分離)	プラットフォーム	P2	★★	完了	2026-04-21	→ 開発仕様書 / ADR-0008 の前提整備。AI Studio 自動生成の "default gemini project" を廃止し、bizlp.co.jp 組織配下に `bizlp-gas-accounting-dev` / `bizlp-gas-accounting-prod` を新規作成。①プロジェクト新設: 組織 `bizlp.co.jp` の配下、法人 billing 紐付け、IAM 設計（オーナー/編集者/閲覧者のロール粒度）。②API 有効化: Vertex AI API、Cloud Audit Logs、Cloud Monitoring 等。③既存プロジェクトの段階的廃止: "default gemini project" からの移行完了後にシャットダウン（30 日猶予）。④スクリプトプロパティ整備: `GCP_PROJECT_ID_DEV` / `GCP_PROJECT_ID_PROD` を Env モジュールに追加。	商用 SaaS 化に必要な法人ガバナンス基盤。IAM 監査・請求分離・dev/prod 事故防止。MAS-216（Vertex AI 移行）の前提	プロジェクト ID 命名規則、サービスアカウント設計、IAM ロール粒度、既存プロジェクトの移行タイミング、Gemini/Claude 利用リージョンの制約確認
MAS-219	Task	💾 Data	既存コードの bizlp 固有ハードコード洗い出し + テナント抽象化リファクタリング	アーキテクチャ	P2	★★	未着手	—	→ ADR-0009 Phase 3 への布石。bizlp 本体も「テナント `T-001`」として扱う抽象化を今から徹底。①洗い出し: スプレッドシート ID、Drive フォルダ ID、特定マスタキー、bizlp 固有判定条件等のハードコード箇所を Grep で検出。②優先度付け: 商用化時の切り出しコストが高い箇所から優先。③抽象化方式: `Env` モジュール / `03_sys_params` / 環境変数への外出し。④段階実施: MAS-192 (Repository 分割) と連動しつつ、新機能実装時に該当部分を切り出す形で段階的に進める	Phase 3 の商用展開時の切り出しコスト最小化。bizlp 固有ロジックが SaaS コードベースに混入することを防ぎ、マルチテナント化への布石	抽象化の粒度 (完全 parameterize vs デフォルト値許容)、過剰抽象化の回避、既存 Env モジュールとの整合、`03_sys_params` の命名規則
MAS-236	Story	🔧 Infra	認証・ユーザー管理基盤	プラットフォーム	P3	★★	未着手	—	Firebase Authentication or Cloud Identity Platform でのログイン基盤。メール+パスワード / Google SSO / SAML対応。ユーザー登録・招待・パスワードリセット・セッション管理。MFA必須化（MAS-205のGCP版）。	スプレッドシートの共有設定依存から脱却。外部ユーザーへの提供に必須	認証プロバイダの選定（Firebase Auth vs Cloud Identity Platform）。既存 Google Workspace ユーザーとの統合方法
MAS-237	Story	🔧 Infra	マルチテナントデータ分離	プラットフォーム	P3	★★	未着手	—	複数企業（テナント）のデータを安全に分離。①論理分離: BigQuery のデータセット or 行レベルセキュリティでテナント別にアクセス制御。②物理分離（大規模時）: テナントごとに GCP プロジェクトを分離。③テナント管理: テナントID の発行・企業情報・契約プランの管理テーブル。	外部提供の大前提。データ漏洩の防止	論理分離 vs 物理分離の判断基準（テナント数・データ量）。テナント間のデータ完全隔離の検証方法
MAS-238	Story	🔧 Infra	Web UI / フロントエンド	プラットフォーム	P3	★★	未着手	—	スプレッドシート UI から Web アプリへの移行。①技術選定: React / Next.js + Cloud Run でホスティング。②画面構成: ダッシュボード（KPI一覧）、財務3表ビューア、PJ損益、RPA実行、設定画面。③レスポンシブ対応: モバイルでの閲覧（経営者のスマホ確認ユースケース）。	スプレッドシートの制約（同時編集・表示速度・UI自由度）からの解放	フロントエンドフレームワークの選定。UI/UXデザインの外部委託要否。スプレッドシートUIとの並行稼働期間
MAS-239	Story	🔧 Infra	API層（REST / GraphQL）	プラットフォーム	P3	★★	未着手	—	GAS の関数呼び出しを REST API 化。①Cloud Functions or Cloud Run: 仕訳エンジン・RPA・マート更新等のコアロジックを API エンドポイントとして公開。②認証連携: MAS-236 の JWT トークンで API 認証。③レート制限・バリデーション: API Gateway でリクエスト制御。	外部連携（給与SaaS・銀行API等）の基盤。フロントエンド（MAS-238）からの呼び出し先	API設計方針（REST vs GraphQL）。GAS ロジックの移植戦略（段階的 vs 一括）
MAS-240	Story	💾 Data	データ移行（スプレッドシート → BigQuery / Cloud SQL）	プラットフォーム	P3	★★	未着手	—	スプレッドシートの全タブを BigQuery（分析用）or Cloud SQL（トランザクション用）に移行。①スキーマ変換: DDL（setupAllSchemas）のスキーマ定義を SQL DDL に変換。②データマイグレーション: 既存データの一括移行スクリプト。③二重書き込み期間: 移行期間中はスプレッドシートと DB の両方に書き込み、データ整合性を検証。関連: MAS-246 TEE 基盤構築の前段階または並列配置で、生データを Enclave 内で処理するデータフロー設計と整合を取る。	GAS の 6分実行制限・スプレッドシートの行数制限（500万セル）からの解放	BigQuery（分析特化）vs Cloud SQL（OLTP）の使い分け。移行中のダウンタイム許容度。ロールバック手順
MAS-241	Story	🔧 Infra	管理者用ダッシュボード	プラットフォーム	P4	★	未着手	—	システム管理者向けの運用画面。①テナント管理: 企業の追加・停止・プラン変更。②ユーザー管理: ユーザー一覧・ロール変更・アクセスログ。③システム監視: API レスポンスタイム・エラー率・DB 使用量のダッシュボード。④ジョブ管理: RPA・マート更新等のバッチジョブの実行状況・スケジュール管理。	SaaS 運用に必須の管理機能。障害検知・顧客サポートの基盤	管理者ロールの階層（スーパー管理者 / テナント管理者）。Cloud Monitoring / Logging との連携
MAS-242	Story	🔧 Infra	課金・サブスクリプション管理	プラットフォーム	P4	★	未着手	—	プロダクトの課金基盤。①Stripe連携: サブスクリプション作成・プラン変更・解約・請求書発行。②プラン設計: Free / Starter / Pro 等のティア別機能制限。③使用量ベース課金（将来）: テナントのデータ量・API呼び出し回数による従量課金。④MAS-028（ARR/MRR）連携: Stripe のデータを自動取込し、自社のプロダクト事業メトリクスに反映。	外部提供の収益化基盤。MAS-028〜MAS-033 のプロダクト事業メトリクスの実データソース	初期のプラン設計と価格設定。Stripe vs 他の決済プロバイダ（PAY.JP等）。請求書のインボイス対応
MAS-244	Story	🔧 Infra	Clean Architecture + フィーチャー分割への再構成	プラットフォーム・アーキテクチャ	P3	★★★	未着手	—	GCP移行時に GAS のレイヤー分割（000〜900のフラット番号prefix構造）をそのままコピーするのではなく、現代的なコード構成に再構成する。①フィーチャー分割（Package by Feature）: `invoice/` `order/` `subledger/` `pipeline/` `headcount/` `capex/` など業務ドメイン単位にディレクトリを切り、各ドメインの `domain/ usecase/ adapter/` を内包。横串のレイヤー分割（controllers/ services/ repositories/）は採用しない。②Clean Architecture の依存方向ルール: 中心に Entities（純粋ドメイン）、外側に UseCases、さらに外側に Interface Adapters（Cloud SQL / BigQuery / Stripe リポジトリ実装）、最外層に Frameworks（Cloud Run / Next.js）。依存は外→内のみ。③純粋TypeScript化: Entities / UseCases は GCP サービスに一切依存しない純粋 TypeScript として実装。単体テストを GCP モック無しで実行可能に。④ports & adapters: 外部サービス（DB / 認証 / メール送信 / PDF生成）は全てインターフェース経由で抽象化し、Adapter 実装を差し替え可能にする。⑤段階的適用: MAS-239（API層）の実装時、ドメイン1つずつリファクタリング（Invoice→Order→Subledger の順）。一括書換は行わない。⑥ESLint依存方向プラグイン: `eslint-plugin-boundaries` 等で依存方向ルールをコードレベルで強制。	GAS時代のModular Monolith構造から卒業し、教科書通りのモダン構成へ移行。DB交換可能性・単体テスト容易性・機能削除の局所化を獲得。新メンバーのオンボーディングコスト激減（一般的なDDD/Clean Archの知識がそのまま通用）	移行期間中の旧構造と新構造の並行稼働期間。TypeScript 厳格モード（strict: true）の導入タイミング。Entities の共通化（例: Money/DateRange 等の値オブジェクト）。Use Case と Repository インターフェースの境界設計。ESLint依存方向ルールのチーム合意
MAS-245	Story	🎨 UI	GAS Web App 独立化（MAS-238 先行切出 / スプレッドシート外 URL で運用 UI 提供）	プラットフォーム	P3	★★	廃止（MAS-232 Stage 1 + Cockpit SPA で目標達成済）	2026-05-11	→ 段階 3: スプレッドシートを開かずに操作できる独立 Web アプリ化。MAS-238（Phase 5 完全 Web UI）の前段として中間ステップを切り出す。①方式: `doGet(e)` で React アプリをホスト → `https://script.google.com/macros/s/XXX/exec` で公開。認証は Workspace ドメイン限定。②MAS-232 との関係: MAS-232 でビルドした React SPA を、そのまま Web App エントリに流用可能（`HtmlService` の埋込先を `doGet` に切替）。③向く機能: ダッシュボード閲覧、経費入力（MAS-174）、承認作業、マスタ編集、モバイルからの簡易操作。④向かない機能: 数式依存のレポート、手動セル編集が前提の業務。これらはスプレッドシート UI を引き続き利用。⑤認証: Workspace 認証（`@bizlp.co.jp` 限定アクセス）+ `SpreadsheetApp.openById()` で明示参照。⑥URL 共有運用: Slack / メールで直接 URL 共有できる利便性。⑦モバイル最適化: レスポンシブ CSS、PWA 化まで含めるか（オフライン対応は段階 4 送り）。⑧段階 4 への橋渡し: Web App の React SPA は Cloud Run 移行時にそのまま流用可能（バックエンドだけ差し替え）	商用化前にスプレッドシート UI の重さから解放。MAS-238 を前倒しで享受し、GCP 移行を急がなくても体感高速化	`doGet(e)` の実行ユーザー指定（`"UserDeploying"` vs `"UserAccessing"`）、共有スプレッドシートの参照方式（ID 直指定 or パラメータ化）、deploy 毎の URL 変更対応（Exec URL 固定 or Dev URL 頻変更）、モバイル対応の粒度、PWA 化の優先度、GAS 実行時間制限（6 分）との兼合い、Web App の同時接続数上限（Google quota）
MAS-247	Story	—	差分プライバシー（DP）集計ライブラリ統合	データ基盤・R&D	P3	★★★	未着手	—	集計結果に数学的プライバシー保証を付与する DP 機構を導入。①ライブラリ選定: プロトタイプ段階は軽量バインディング、本番は学術界で広く採用されている成熟ライブラリへ移行。②感度（sensitivity）算出ロジック: 管理会計の各集計指標（売上平均、件数、分散等）ごとの感度を事前計算。③ε パラメータ管理: 初期値を設定した上で 03_sys_params 相当の仕組みで管理、指標別に調整可能な構造に。④プライバシー予算管理: クエリ回数制限で累積プライバシー損失を抑える機構。⑤メカニズム実装: Laplace / Gaussian mechanism の使い分けロジック。⑥合成可能性: composition theorem に基づく長期運用設計。	「個社データを特定不可能な形で集計公開できる」技術的担保。研究発表・業界ベンチマーク販売の前提基盤	ε の妥当値決定プロセス（学術パートナーとの協議必須）、感度の算出方法（理論値 vs 経験値）、プライバシー予算の再充填ポリシー、ε 値の顧客向け説明方法
MAS-250	Story	—	研究用匿名化データパイプライン（MAS-259 の技術実装）	データ基盤・R&D	P3	★★	未着手	—	§3.3.1 MAS-259 の技術実装版。①DP + TEE の組み合わせ: 顧客同意済みデータを TEE 内で匿名化集計 → DP ノイズ付与 → 研究用 DB へ転送。②決定的ハッシュによる擬似化: 顧客ID + salt のハッシュで集計整合性を保ちつつ識別可能情報を除去。③同意管理システム: 顧客ごとのR&D同意ステータス・撤回履歴を管理するシート/DB。④収集粒度: 科目比率・業種別 KPI・取引頻度分布など構造的特徴のみ。⑤削除保証: 解約 or 撤回時の 30 日以内全消去を TEE + DP の特性で技術的に担保。⑥Access Transparency: 「運営者が顧客データにいつ何をしたか」を顧客が確認可能な監査ログ。	業界ベンチマーク機能（「御社の労働分配率は業界平均より X% 高い」等）を他社模倣困難な独自資産として構築。MAS-259 の法務・同意面と技術面の両面で差別化を確立	MAS-259（法務・同意）と MAS-250（技術実装）の統合 or 分離管理、ハッシュ salt の管理方式、同意撤回時のベンチマーク統計への反映ロジック、顧客への透明性提供 UI

🛠️ DevOps・運用ツール（21 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-096	Story	—	clasp push 時の意図しないファイル混入防止	DevOps	P1	★★★	完了	2026-04-15	`.claspignore` にルート直下の非GASファイル除外ルールを追加。→ 開発仕様書	デプロイの安全性確保（実障害の再発防止）	なし（設定変更のみ。即対応可）
MAS-097	Story	🧠 Domain	未使用変数の一括クリーンアップ	コード品質	P1	★★★	完了	2026-04-14	TypeScript診断で検出済みの settleYm, appType, iRefType, hasNewDraft 等を削除。→ 開発仕様書	コード可読性の向上（作業15分程度）	なし（機械的な削除。即対応可）
MAS-098	Story	🧪 Test	RPA起票の冪等性テスト自動化	テスト	P1	★★★	完了	2026-04-15	テストランナーに「同一条件で2回実行→2回目は0件」の冪等性検証を追加。→ 開発仕様書	MAS-076の回帰テスト（小規模で効果大）	テスト対象のRPA関数の範囲（全6種 or 主要のみ）
MAS-116	Story	—	データ整備のマイグレーションスクリプト基盤	DevOps	P1	★★★	完了	2026-04-16	データ整備（マスタ追加・DDLスキーマ変更等）をコードとして記述し、dev/prod 両方で実行する仕組み。①スクリプト配置: mas/800_ops/ に案件ごとのマイグレーションファイルを配置（例: `804_migration_d01_d03.js`）。②冪等性: 「既に存在したらスキップ」のチェックを必ず含める。何度実行しても同じ結果になること。③実行ログ: 適用結果（追加N件/スキップN件）をダイアログで表示。④手順: dev で実行・検証 → `clasp push:prod` → prod で実行。Git でコードレビュー可能。⑤MAS-202（DDL自動マイグレーション）の前段階: MAS-202 はバージョン管理+自動適用だが、MAS-116 は手動実行の簡易版。→ 開発仕様書	dev で検証したデータ整備を prod に安全・確実に反映。手動コピペによるミスを排除。Git で「何をいつ適用したか」が追跡可能	マイグレーションファイルの命名規則。実行済みマイグレーションの記録方法（03_sys_params に適用済みリストを保持？）。ロールバック手順の要否
MAS-134	Story	🔧 Infra	setupAllSchemas の高速化	パフォーマンス・DevOps	P1	★★★	完了	2026-04-17	→ 開発仕様書	`mas/100_config/101_sys_config.js` の `setupAllSchemas()`（約600行）が全シートに対して重い処理を多数実行し、DDL 適用に数十秒〜数分かかる問題を解消。①setFontFamily 全範囲適用の廃止（済 or 部分適用）: L419で `ss.getSheets().forEach(sheet => sheet.getRange(1,1,maxRows,maxCols).setFontFamily(...))` を実行している。これが最大のボトルネック。テーマ適用（L418 `theme.setFontFamily`）だけで font は全シートに伝播するため、L419 は廃止可能。②Sheets API v4 batchUpdate 導入: 各タブの `setNumberFormat()` 20〜30回の個別呼び出しを `spreadsheets.batchUpdate` の 1 リクエストに集約。5-10倍高速化を見込む。③増分モード: スキーマ定義のハッシュをスクリプトプロパティに保存し、前回と同じなら処理をスキップ。2回目以降のデプロイ時にほぼゼロ秒。④カテゴリ別メニュー分割: 「🔧 マスタのみ更新」「🔧 WRK系のみ更新」「🔧 書式のみ再適用」などの部分更新メニュー。開発中の繰返し実行負荷を軽減。⑤進捗ダイアログ: 処理中のシート名をトースト通知（`SpreadsheetApp.getActive().toast()`）で表示し、停止しているのか動いているのか可視化。	テナント追加・DDL変更時のセットアップ時間を 10-20倍短縮。開発サイクルの高速化。GCP移行前でもSaaS的な運用負荷に耐えられる基盤
MAS-194	Task	🛠️ Ops	GAS実行時間の最適化（マート更新の分割実行）	パフォーマンス	P2	★★	未着手	—	buildBudgetTrendDataMart() の分割実行（P/L→B/S→CF）。GAS6分制限対策。	スケーラビリティの確保	分割実行時のメニューUI（一括 or 個別選択）
MAS-195	Task	—	clasp push 前の自動リントチェック（pre-push フック）	DevOps	P1	★★★	完了	2026-04-15	npm scripts に pre-push フックを追加し、非GASファイル検出や構文エラーを自動チェック。→ 開発仕様書	デプロイ事故の未然防止（MAS-096の恒久対策）	なし（開発ツール設定のみ。即対応可）
MAS-196	Task	🧪 Test	テストランナーの Repository/Contracts 層テスト追加	テスト	P1	★★★	完了	2026-04-15	toDto/toRow の変換正確性、findAll の戻り値構造、キャッシュ動作を検証。→ 開発仕様書	新基盤層の品質担保（小規模で効果大）	なし（テストコード追加のみ。即対応可）
MAS-197	Task	💾 Data	dev/prod 環境間のスキーマ差分検出ツール	DevOps	P2	★★	未着手	—	803_sync_tool.js の発展版。ヘッダー構造（DDL）の差分を検出・レポート。	環境間の不整合の早期発見	差分検出時のアクション（自動修正 or レポートのみ）
MAS-202	Task	💾 Data	DDLスキーマの自動マイグレーション	DevOps	P2	★★	未着手	—	MAS-197（差分検出）の発展版。setupAllSchemas にバージョン番号を導入し、スキーマ変更を段階的に自動適用。①バージョン管理: 03_sys_params に `SCHEMA_VERSION` を追加。setupAllSchemas 実行時に現バージョンと目標バージョンを比較。②マイグレーションスクリプト: mas/800_ops/ にバージョン間の差分を定義（列追加・列リネーム・デフォルト値設定）。NetSuiteの自動アップデート思想をGASに適用。③ロールバック: マイグレーション失敗時にMAS-201（バックアップ）から復元する手順を自動化。④変更履歴: 適用済みマイグレーションのログを専用シートに記録。	DDL変更のデプロイが安全・確実に。「setupAllSchemas実行したらデータ消えた」事故を防止。ERP的な自動アップデート体験	マイグレーションの粒度（列単位 or シート単位）。dev→prod のマイグレーション順序。既存の RENAME_MAP との統合方法
MAS-204	Task	—	仕様書体系のメタ管理・自動整合性チェック	DevOps	P3	★	未着手	—	docs/spec/ の28ファイルとGASコードの整合性を自動検証。①仕様書インデックス: 全spec/adr/devファイルの一覧と、対応するGASファイル・シート名の対応表を自動生成。②仕様とコードの乖離検出: spec記載のカラム名・関数名がコード上に存在するかをGrepベースでチェック。乖離があればレポート出力。③CLAUDE.md との同期: CLAUDE.md の記載内容（ファイル番号体系・名前空間・コーディング規約）と実コードの整合性を自動検証。	「仕様書は書いたがコードと合っていない」問題を防止。ドキュメントの信頼性を自動担保	チェック頻度（PR時 or 定期）。許容する乖離の範囲。GitHub Actions での自動実行
MAS-220	Task	🔧 Infra	フリート管理型デプロイ基盤の設計調査 (clasp + GitHub Actions で 1 コード → N 顧客環境)	DevOps	P3	★	未着手	—	→ ADR-0009 Phase 3 準備。商用化時のデプロイ戦略として「1 モノリスリポジトリ → 顧客別 GAS プロジェクト + スプレッドシートに一斉デプロイ」のフリート管理型 CI/CD を設計する調査案件。①先行事例調査: 日本の GAS 系 SaaS のデプロイ方式の事例収集。②`.clasp.json` 管理: 顧客別 `.clasp.<tenant_id>.json` を動的生成するスキーム。③GitHub Actions 設計: matrix 戦略で顧客別デプロイ並列化、失敗時のロールバック手順。④テナント追加時のオンボーディング自動化: 新規顧客追加 → GAS プロジェクト複製 → スプレッドシート初期化 → `.clasp` 登録のワンストップフロー。⑤本案件はあくまで調査 / 設計のみ。実装は Phase 3 着手時 (初 PoC 契約確定後) に別案件で起票	商用展開の技術基盤。1 コードベースのメンテナンス性とシングルテナントの堅牢性 (GAS 6 分制限等の回避) を両立	顧客別の GAS 実行アカウント設計、スプレッドシート容量 / セル数上限の監視、デプロイ失敗時のリカバリ、顧客データバックアップ方式、課金計測の粒度
MAS-221	Task	🛠️ Ops	TODO_future.md 自動生成スクリプト (SSoT → 派生 view の同期自動化)	DevOps	P2	★★	未着手	—	背景: §3 全案件マスタテーブル (SSoT) と §1 の派生 view (件数サマリ / Top 14 / Phase 別内訳) の手動同期が更新漏れ・上書き事故の原因。2026-04-21 の Phase 1 整理で詳細テーブル 2 件を削除し更新箇所を 6→4 に減らしたが、残る 4 箇所もスクリプト化で自動化する。実装: `scripts/3_rebuild_todo_summary.js` を新規作成し、§3 SSoT を parse して §1 の以下を自動再生成: ①件数サマリ (完了/仕様書完了/未着手の集計)、②Top N バックログ (優先度・依存関係ソート + 完了案件除外)、③Phase 別内訳 (件数のみ)、④横断テーマの該当案件自動マッピング。運用: `npm run todo:rebuild` で手動実行、`husky` 等で TODO_future.md 編集時に pre-commit hook で自動実行、GitHub Actions で PR 時にチェック (diff 発生したら失敗)。将来拡張 (Phase 3): ステータスの機械判定 (`docs/dev/dev_*.md` ファイル存在 → 仕様書完了 / `gh pr list --state merged --search 'N-XX'` → 実装完了) を SSoT に自動反映。	案件管理の更新漏れ・上書き事故を根絶。SSoT 更新のみで派生 view が全て追従。手動同期負荷を 4→1 に削減、将来の機械判定で 1→0 まで到達可	スクリプト言語 (Node.js / Python)、Markdown テーブル parse ライブラリ、pre-commit hook の導入可否 (`husky` か `lefthook` か)、自動生成マーカー (`<!-- AUTO-GENERATED:START -->` 等) の設計、CI での diff チェック厳格度
MAS-223	Task	🛠️ Ops	Jr オンボーディングドキュメント整備（1 日環境構築 + 1 週目 PR）	DevOps・組織	P3	★★★	未着手	—	→ Jr 入社 D+1 から稼働開始できる状態を作る。`docs/_internal/onboarding_jr.md` 新設。①1 日目チェックリスト: Google Workspace アカウント付与、支給 PC セットアップ（FileVault / 画面ロック / 2FA）、Git / Node / clasp 導入、.clasp.dev.json 取得、最初の `clasp push:dev` 完了、CLAUDE.md 通読、テストスプレッドシート共有。②1 週目ランプアップ: good-first-issue（MAS-226 で選定）から 2-3 件着手、1 件目は Sr ペアで実装、2 件目以降は独力で PR、テスト実行手順の習得。③GAS 入門パス: GAS 不問採用のため、`docs/ops/gas_primer.md`（新設）に 4 時間で読める入門（V8 ランタイム / SpreadsheetApp / clasp 運用 / 既存コード読解）を用意。④質問ルール: 15 分ルール（15 分悩んだら質問）、質問テンプレ（目的・試したこと・エラー内容）、Slack スレッド化。⑤CLAUDE.md 補強: Jr 向け節を追加（「既存パターンを必ず Read してから書く」「main に直 push しない」「失敗パターン #18-#20 対策」）。前提: MAS-230（採用要件確定後に Jr 想定スキルに合わせて教材の粒度を決める）	Jr 入社後 1 週で戦力化。Sr の都度指導コストを時給換算で 50% 削減。質問の属人化を防ぎドキュメント駆動の文化を確立	GAS 入門パスの粒度（4 時間 / 1 日 / 1 週）、ペアプログラミングの頻度（初週毎日 2h → 2 週目以降週 1 減らす）、質問ツール（Slack / Discord / GitHub Discussions）、1 日目セットアップの所要時間実測、Sr 自身による予行演習の要否
MAS-224	Task	🛠️ Ops	GitHub Actions CI パイプライン構築（lint / テスト / clasp 構文チェック）	DevOps	P3	★★★	未着手	—	→ Sr のレビュー負荷を機械化で先取り。採用プロセス開始前（D-150 目安）に着手すべき整備案件。①Workflow 構成: `.github/workflows/ci.yml` に 3 ジョブ配置。(a) lint: ESLint（`eslint-config-google` or `@airbnb/javascript`）で GAS V8 準拠の構文チェック。(b) syntax-check: `node -c` を全 `.js` に走らせて構文エラー検出（clasp push 前の最小ガード）。(c) test-runner-dry: `mas/900_test/901_test_runner.js` の関数呼び出し対応表を静的解析で検証（実行はオーナー権限必要のため dry-run）。②PR 自動コメント: reviewdog 等で lint 結果を PR にインラインコメント。③キャッシュ最適化: node_modules / eslint キャッシュで実行時間を 30 秒以内に。④Branch protection 連動: 次案件 MAS-225 で「CI パス必須」を Required checks に登録。⑤dev デプロイプレビュー: PR 内で `clasp push` の dry-run（構文チェックのみ、実デプロイはなし）。本物のデプロイは merge 後の別ワークフローで分離。関連: GitHub Actions の既存 `deploy.yml`（main push 時 prod デプロイ）に並行して ci.yml を追加	Jr の PR 品質を機械チェックで底上げ。Sr は「人間にしかできない観点（設計・命名・意図）」のレビューに集中。CI 落ちる PR は Sr が読む前に Jr 自身が直せる	eslint 設定の厳格度（airbnb 厳格 vs google 緩め）、reviewdog vs 独自スクリプト、GAS 特有の warning 抑制（`SpreadsheetApp` の top-level 呼び出し等）、CI 実行時間の SLA（30 秒目標 / 1 分上限）、secrets 管理（本 CI は秘密情報不要）、テストランナーの完全 dry-run 手法
MAS-225	Task	🛠️ Ops	Branch protection + CODEOWNERS + PR テンプレート整備	DevOps	P3	★★★	未着手	—	→ main 直 push を物理的に防ぎ、レビュー必須化。MAS-224 CI 完了後に本案件を重ね、ガード機構を完成させる。①Branch protection (main): GitHub Settings で以下を ON。 (a) Require pull request reviews (1 approval)、(b) Require status checks to pass（MAS-224 の lint/syntax-check/test を Required）、(c) Require branches to be up to date、(d) Include administrators（Sr も例外にしない）、(e) Do not allow bypassing the above settings。②CODEOWNERS 設定: `.github/CODEOWNERS` で自動レビュアー指定。`mas/000_infra/` `mas/100_config/` `mas/200_data/` `mas/appsscript.json` `docs/_internal/` は Sr 承認必須（Jr 単独承認不可）。`docs/dev/` `docs/spec/` `mas/400_domain/` 等は Jr 承認で可。③PR テンプレート: `.github/pull_request_template.md` に以下のチェックリスト。(a) CLAUDE.md 規約チェック、(b) 該当仕様書へのリンク、(c) 動作確認手順（dev でのテスト結果）、(d) changelog 追記、(e) _config.json 更新（新規 .md 作成時）、(f) 関連 failure_patterns の参照、(g) 影響範囲セルフ宣言。④CODEOWNERS 運用ルール: 一時的例外（緊急バグ修正等）のエスカレーション手順を `docs/_internal/review_policy.md`（MAS-227 で作成）に記載	規約違反を Git 側で物理的にブロック。Sr の "見落とし" を減らし、Jr は「機械にダメ出しされる」形で学習。prod 事故リスクを構造的に予防	1 approval vs 2 approval（3 人体制では 1 で十分）、レビュー待ち SLA（24h 以内）、Sr 不在時の緊急マージフロー、Force push の完全禁止判断（現状許容中）、Stale PR 自動クローズの要否、Draft PR の使い分けルール
MAS-226	Task	🛠️ Ops	Good-first-issue セレクション + GitHub Labels 運用	DevOps・組織	P3	★★	未着手	—	→ Jr が入社後 2-3 日で着手できる "安全な" 案件を事前選別。MAS-223 オンボーディングと対を成す案件。①選定基準: (a) 仕様書が既に完了していて詳細度が Jr 水準、(b) 影響範囲が狭く事故時のロールバック容易、(c) 既存パターンの横展開（新規設計判断不要）、(d) 所要時間 1-4h の小粒。②候補リスト（10-15 件）: MAS-086 (税区分自動判定) / MAS-122 (ORD↔INV 整合性チェック) / MAS-164 (銀行摘要自動学習) / MAS-153 (証憑リンク再構築) / MAS-167 (STL 重複検出) / MAS-075 等バリデーション系 / MAS-213 (監査ログ保護) の後半分 / 他バグ修正系 2-3 件。③GitHub Labels: `good-first-issue` / `jr-friendly` / `needs-spec` / `needs-sr-review` / `blocked` / `priority-high` / `priority-medium` / `priority-low` を整備。色分け規約を `.github/labels.md` に記載。④Issue テンプレ化: 各候補を GitHub Issue として予め作成（既存 TODO_future.md からインポートスクリプトで一括変換、MAS-221 と連動）。各 Issue に仕様書リンク + 推定所要時間 + 前提条件 + Sr レビュー観点を記載。⑤運用: Jr が自ら pick する方式（Sr が割当しない）。完了したら次の Issue を pick、困ったら Sr に相談	Jr の初期立ち上がりを "詰まらない" 体験にする。Sr が割当する方式だと Jr の自発性が育たず、選択肢が多すぎても迷う。10-15 件のキュレーションが最適	候補選定の粒度（1-4h 内の範囲）、Issue 化のスクリプト自動化（MAS-221 と統合）、ラベル命名規則（英語 / 日本語混在可否）、完了後に Jr が次を pick する運用トリガー、「難しすぎた」判定の差戻しフロー、Sr が事前に仕様書詳細度を 1 件ずつ確認する要否
MAS-227	Task	🛠️ Ops	コードレビュー運用ルール整備（ADR-0010 候補）	DevOps・組織	P3	★★	未着手	—	→ レビューの観点・SLA・差戻し基準を明文化し属人化を防ぐ。`docs/adr/0010-code-review-policy.md` を ADR として作成。①レビュー観点テーブル: (a) 動作正しさ（仕様書と一致 / エッジケース対応 / テスト通過）、(b) 既存規約準拠（CLAUDE.md / failure_patterns 反映）、(c) 保守性（命名 / 関数分割 / コメント）、(d) セキュリティ（入力検証 / 権限分離）。優先度: (a) > (b) > (d) > (c)。②応答 SLA: Sr の初回コメント 24h 以内、Jr の応答 48h 以内、総ターン 3 往復以内で決着目標。③差戻し基準: (a) 仕様書記載の動作と差異あり = Request Changes、(b) 規約違反 = コメント + 修正依頼、(c) スタイル微調整 = Approve + 次回反映。④マージ権限: Sr のみマージボタン押下可（Jr は Approve までで待機）。緊急時の Jr セルフマージ許容条件を明記。⑤プッシュバック許容: Sr の指摘に Jr が異議を出してよい文化（「なぜ？」と聞ける心理的安全性）。③スタイル軽微指摘への異議は積極推奨。⑥監査ログ: レビュー履歴は GitHub PR に残るため特別管理不要。学習ポイント（典型的な差戻し理由）は月次で failure_patterns.md に追記	レビュー文化を属人的スキルから仕組みに昇華。新規 Jr が増えても同じ水準のレビューが提供される。Sr の「なんとなく気持ち悪い」を言語化して Jr の学習機会に	初回コメント SLA を 24h にすべきか 48h にすべきか（Sr の非専任度合い次第）、Request Changes の発動条件の厳格度、スタイル指摘は suggestion コミットに統合するか、ペアプログラミング時間を正式にカウントするか、Sr が不在の日の Jr の進め方（Draft PR で積んでおく等）
MAS-231	Task	💾 Data	GAS パフォーマンス最適化パス 1（バッチ I/O + キャッシュ + 数式静的化）	DevOps・パフォーマンス	P1	★★★	未着手	—	→ MAS-233 計測結果に基づき、段階 1 の王道テクニックを適用して体感 3-5 倍改善。①バッチ I/O 化: `getValues()` / `setValues()` を全箇所で範囲指定一括実行（セル単位ループを配列操作に置換）。対象: Action A/B、マート更新、RPA 起票、Repository.save / append。②マスタキャッシュ層: `mas/200_data/202_repository.js` に `CacheService` レイヤーを追加。`PartnerRepository.findAsMap()` / `AccountRepository.findAsMap()` 等を 6h キャッシュ、書込時にキー無効化。③`flush()` の削減: 途中の `SpreadsheetApp.flush()` を削除し、最後の 1 回だけに集約。④Volatile 関数の除去: `NOW()` / `TODAY()` / `RAND()` を使っているセルを GAS 側で静的値セットに置換。⑤条件付き書式の削減: 複雑な数式条件付き書式を GAS 側 `setBackground()` に置換（特に財務 3 表 / マート系シート）。⑥ onEdit の軽量化: 重い処理は Installable trigger で非同期化、onEdit 本体は `CacheService.put` してすぐ return。⑦効果測定: 全適用後、MAS-233 の 99_perf_log で P95 が半減〜1/5 になっていることを確認	既存コードの 10-20% の書換で体感 3-5 倍高速化。SPA 化や GCP 移行の前段として最小投資で最大効果。Jr 入社後の好例題としても適切	着手順序（バッチ I/O → キャッシュ → flush → 書式）、キャッシュ無効化の粒度、数式静的化で失われる再計算自動性の許容、onEdit 非同期化による UX 変化、Volatile 関数の検知手法（grep or 実行時）、効果測定の合格基準（P95 の何%減を目標にするか）
MAS-233	Task	💾 Data	GAS パフォーマンス診断ツール（実行時間計測 + ボトルネック特定）	DevOps・パフォーマンス	P1	★★	未着手	—	→ 「何が遅いのか」を数値で把握するための計測基盤。MAS-231 最適化パス 1 の着手前に必須。①計測ヘルパー関数: `Utils.perfStart(label)` / `Utils.perfEnd(label)` を追加し、ラベル別に `console.time` + `CacheService` に累積記録。1 実行の呼出回数と総経過時間を保存。②主要関数への埋込: Action A/B、マート更新、RPA 起票、サイドバー初期化、OCR 処理の各エントリに自動挿入。③レポートシート: `99_perf_log` を DDL に追加し、`関数名 / 実行日時 / 処理件数 / 所要時間(ms) / P50 / P95` を日次で集計。④可視化: Looker Studio or シート内スパークライン / 条件付き書式で「赤:>5秒 / 黄:>1秒 / 緑:<1秒」を可視化。⑤ボトルネック検知ルール: (a) 同一関数が週平均 P95 > 10 秒なら自動アラート、(b) `SpreadsheetApp.flush()` 呼出箇所の特定、(c) `google.script.run` ラウンドトリップ件数計測。⑥着手順序: 計測埋込 → 2 週間データ蓄積 → 上位 5 ボトルネック特定 → MAS-231 で対策実装のループ	"遅い" の体感を定量化し改善効果を測定可能に。経験則で改善すると「効いたかわからない」が発生するため先行必須	計測ラベルの粒度（関数単位 / 処理ブロック単位）、CacheService 書込頻度（毎回 vs バッファリング）、99_perf_log 保持期間（90 日 / 無期限）、Looker Studio 連携の要否、ユーザー操作計測（サイドバーボタン押下〜応答）の捕捉方法（クライアント側タイマー埋込）
MAS-243	Story	🛠️ Ops	CI/CD パイプライン（Cloud Build / GitHub Actions）	DevOps	P3	★★	未着手	—	clasp push ベースのデプロイから、本格的な CI/CD パイプラインへ移行。①ビルド: TypeScript コンパイル・リント・テスト実行。②ステージング: dev → staging → prod の段階デプロイ。③ロールバック: デプロイ失敗時の自動ロールバック。④IaC: Terraform で GCP リソース（Cloud Run / BigQuery / IAM）を宣言的管理。	デプロイの安全性と速度の両立。MAS-195（pre-push フック）の発展形	Cloud Build vs GitHub Actions の選定。ステージング環境のコスト。Terraform の学習コスト

🔬 R&D・税務（7 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-034	Story	—	R&D費用の自動分類・集計	R&D	P2	★★	未着手	—	工数・外注費・クラウド費用等をR&D活動に自動紐付け。研究フェーズ（費用処理）と開発フェーズ（資産計上）を区分し、会計基準に準拠した自動仕訳を生成。	R&D投資額の正確な把握。税制優遇（研究開発税制）の適用漏れ防止	研究/開発フェーズの判定基準（「技術的実現可能性の確立」の社内定義）。資産計上の開始時点
MAS-035	Story	—	知的財産ポートフォリオ管理	R&D	P3	★	未着手	—	特許・商標・意匠・著作権等の出願状況・登録日・更新期限・費用を一元管理。維持費用の年次予測と更新期限のアラート通知。	知財の棚卸と維持コストの可視化。更新期限切れによる権利失効の防止	管理対象の知財カテゴリ（特許のみ or 商標・意匠含む）。外部の特許管理システムとの連携要否
MAS-036	Story	—	R&D投資対効果（ROI）ダッシュボード	R&D	P3	★	未着手	—	R&Dプロジェクトごとの累積投資額と、そこから生まれたプロダクト収益（MAS-032）・ライセンス収入・特許収入を紐付けて投資回収状況を可視化。	「このR&Dテーマにいくら投資して、いくら回収できたか」の定量的把握。R&D予算配分の意思決定材料	R&D成果とプロダクト収益の紐付けルール（直接帰属 vs 間接貢献）。回収期間の目安
MAS-037	Story	—	ソフトウェア資産の減価償却管理	R&D	P2	★★	未着手	—	開発フェーズで資産計上したソフトウェアの取得価額・償却期間・月次償却額を自動計算。B/S（無形固定資産）とP/L（減価償却費）に自動反映。	自社開発ソフトウェアの資産計上と償却の自動化。現行は全額費用処理のため、B/Sに開発投資が反映されていない	償却期間の設定（税法上の耐用年数：3年 or 5年）。減損判定の基準
MAS-038	Story	—	研究開発税制の適用シミュレーション	R&D	P3	★	未着手	—	試験研究費の税額控除（総額型・中小企業型）の適用可否判定と控除額の自動計算。R&D費用の集計（MAS-034）と連動。	税制優遇の最大活用。「R&Dにこれだけ投資すると税額控除がいくらになるか」の事前シミュレーション	税制改正への追従方法。顧問税理士との適用判定フローの整理
MAS-144	Story	🧠 Domain	役員社宅・出張日当・退職金規程自動ジェネレーター（MAS-334 派生）	業務効率化・節税補助	P1	★★	未着手	2026-04-27	MAS-334 Section F（Gemini 3 Pro Preview Deep Think 精緻化で P1 確定・Claude 暫定合成版から維持）。MAS-067 v1 と並列起票推奨。ID 採番: 当初 Gemini Deep Think は「MAS-142」を提案したが、既存 MAS-142（workType DDL・MAS-043 関連）と衝突 → sub 側で次空き番号 MAS-144 に振直し（failure_patterns #31 適用・MAS-142/MAS-143 既使用確認済）。機能: MAS-067 ダッシュボードで「役員社宅 (A2) / 出張日当 (A3) / 退職金 (A10)」が🟢 実行可能になった時点で、ユーザーが事業規模・家賃額・出張距離・役員勤続年数等を入力 → 国税庁通達準拠の (a) 社宅管理規程・(b) 旅費交通費規程・(c) 役員退職金規程を PDF 自動生成。実装方式: LLM 不要・静的テンプレート（HTML or Markdown）+ 入力差込（Mustache or テンプレートリテラル）+ PDF 出力（jsPDF or GAS HTML to PDF）。新規実装想定: `mas/400_domain/452_regulation_generator.js`（純粋関数・テンプレート差込・約 200 行）/ `webapp_client/src/regulation/{SHATAKU,TRAVEL,RETIREMENT}.tsx`（3 React コンポーネント・約 300 行）/ テンプレートは `mas/templates/regulations/{shataku.md, travel.md, retirement.md}` で SSoT 管理。連携: MAS-067 のステージ準備度ダッシュボード信号機が🟢になった時に「📄 規程ダウンロード」ボタンを表示（MAS-067 cockpit から本案件 UI に遷移）。	MAS-067 を「分析ツール → 自動化プラットフォーム」に進化させるクイックウィン機能。商用化時のアップセル契機（テンプレート無料 / 自動生成 + クラウド保管 = サブスク）。海外 FP&A SaaS でも規程ジェネレーターは空白領域	規程テンプレートの法的妥当性（税理士 / 社労士監修必要）/ 雛形バージョン管理（法改正時の差分管理 + 顧客通知）/ PDF 生成ライブラリ選定（jsPDF / GAS HTML to PDF / Google Docs API）/ 規程内容の業種別カスタマイズ（IT / コンサル / 製造業で差異）/ 社宅家賃の国税庁算式（小規模住宅 vs それ以外）の入力 UX
MAS-218	Task	🛠️ Ops	タイムトラッキング (Toggl Track 等) 導入 + R&D / クライアントワーク時間分離記録ルール整備	税務・運用	P3	★★★	未着手	—	→ ADR-0009 Phase 1 アクション。【重要前提】bizlp の売上は 100% クライアントワーク (F) で発生しており (初年度 7 ヶ月で 1,000 万円)、bizlp-gas-accounting は売上ゼロの R&D 投資。この構造ゆえに、研究開発税制の役員報酬按分 (Gemini A 派積極算入) を主張するには F 時間の正確な分離記録が絶対条件。①ツール選定: Toggl Track / Clockify / Harvest 等から選定 (個人プラン可)。②タグ設計: 活動領域別タグ `D-RnD` (研究開発) / `C-ProductDev` (プロダクト開発) / `B-SelfOps` (自社会計運用) / `A-Corporate` (法人運営) / `F-ClientWork` (クライアントワーク・受託) の 5 タグ体系。③日次入力運用: 作業開始時にタイマー起動、終了時に停止の運用を定着。クライアントワーク中は `F-ClientWork` タグで記録 (顧客貸与 PC では bizlp ログインしないため、別デバイス / 個人スマホから Toggl で記録)。④月次エクスポート: 月末に CSV で Drive 保管、決算期に税理士協議の資料として使用。⑤試験研究費割合の月次集計: 「R&D (C+D) 時間 / 全労働時間 (A+B+C+D+F)」の割合を月次トラッキングし、役員報酬按分率を算出。高水準要件 (試験研究費 / 売上 ≥ 10%、すなわち 150 万円以上) 到達見込みを監視。⑥即時着手推奨: 決算期 (2027 春想定) までに 1 年分の記録を蓄積するため、今月から記録開始。⑦過去分 (2025-12〜2026-04) の遡及計上方針: 記録開始前の約 4 ヶ月分は以下のエビデンスで推計する。(a) R&D 時間: `git log --author='ts_kuma' --since='2025-12-20' --pretty=format:'%ad %s'` で bizlp-gas-accounting リポジトリの commit 時刻を抽出し、commit 直前 2 時間 (保守的にやるなら 1 時間) を「R&D 従事」として推計。GitHub PR の作成・コメント・マージ時刻も合算。(b) クライアントワーク時間: 受託契約書・月次請求書の稼働時間から機械的に確定 (請求書ベースなので強い客観証拠)。(c) 税務調査時の主張強度は Toggl 記録より弱いため、遡及計上の範囲は顧問税理士と事前協議**して決定。git log 抽出と遡及集計は MAS-218 着手時に併せて実施	税務上の役員報酬按分主張の成否を決める絶対条件。これなしでは Gemini 指摘の A 派 (積極算入) は主張不能となり B 派 (保守除外・API 代のみ計上) しか選べず、試験研究費が高水準要件 (150 万円) に届かない。R&D 税制効果を 3 年累計約 43 万〜205 万円の幅で左右する (売上シナリオ × 賞与パターン次第、基準ケース: 売上 1800/1800 万 × 賞与 300 万で累計約 105 万円)。詳細は rd_tax_credit_estimation_2026.md の 3 シナリオ × 4 賞与パターンのマトリクス参照。記録がなければ A 派 (積極算入) を主張できず、B 派 (保守) で累計 22 万円程度しか達成できないため、即時着手が合理的。商用化成功時 (4 年目以降売上 5000 万超) は控除限度が拡大し年 100 万円超の控除も射程	ツール選定 (無料版の制約 / 有料版の必要性)、タグ体系の粒度、クライアントワーク時間の記録デバイス (貸与 PC では bizlp ツール起動できないため個人スマホ or 別 PC が必要)、過去 4 ヶ月分の遡及計上の強度 (commit 直前 1 時間 or 2 時間)、タイマー記録漏れ時の事後記入ルール、税理士との協議タイミング、クライアントワーク案件別の粒度を Toggl プロジェクト機能で管理するか

🤖 AI活用（5 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-019	Story	📊 Report	予測的分析と外部シグナル統合	AI活用	P4	★	未着手	—	マクロ経済、天候、業界トレンドなどの外部データをAPIで取り込み、需要予測に反映。	予測精度の飛躍的向上	取り込む外部データソースの選定とAPI費用
MAS-027	Story	📥 Import	M365監査ログ連携→作業時間の自動推定	AI活用	P3	★	未着手	—	Microsoft 365の監査ログ（Outlook, Teams, SharePoint, OneDrive等の操作履歴）をGraph API経由で取得し、「どのPJにどれくらい時間を使ったか」をAIで自動推定。①ログ取得: Graph API → Activity Reports / Audit Logs。メール送受信・ファイル編集・Teams会議の時刻とコンテキストを収集。②PJ推定: Gemini or Claude でログのコンテキスト（件名・フォルダ名・参加者）からPJを推定。14_mst_project のPJ名と照合。③時間配分: 活動ログの時刻差分からPJ別の推定作業時間を算出→MAS-026(TDABC)の入力データとして連携。④MAS-105の代替: 手動工数入力(MAS-105)を補完 or 完全代替。「入力忘れ」問題を解消。	工数入力すら不要に。M365を普通に使うだけで、PJ別の作業時間が自動で記録される。TDABC(MAS-026)の究極形	M365テナントの監査ログ保持期間（E3以上で180日）。推定精度の検証方法。プライバシーへの配慮（個人の活動を細かく追跡することへの抵抗感）
MAS-182	Task	🧠 Domain	異常値検知・監査アシスタント	AI活用	P4	★	未着手	—	過去の仕訳パターンから逸脱した異常をAIが自動検知。	監査業務の効率化	異常判定の閾値（統計的基準 or ルールベース）
MAS-191	Task	🧠 Domain	NLPによる自動ナラティブ（文章）生成	AI活用	P4	★	未着手	—	ダッシュボードの数値からインサイトを文章で自動生成。	報告業務の劇的な効率化	生成する文章のトーン・フォーマットの決定
MAS-203	Task	—	AIプロンプトライブラリの版管理	AI活用	P2	★★	未着手	—	Gemini OCR（502_receipt_reader.js）やClaude Code 運用ガイド（MAS-156）で使用するプロンプトを、コードにハードコードせず外部管理する仕組み。①プロンプトシート: 新規シート or docs/prompts/ にプロンプトテンプレートを集約。用途別（OCR抽出, 科目推定, 法改正問合せ, 取引先略称生成等）にカテゴリ管理。②バージョニング: プロンプト変更時に旧版を保持し、精度比較（A/Bテスト）を可能に。③Git管理: docs/prompts/ 配下に .md or .txt で管理し、変更履歴をGitで追跡。CLAUDE.md からの参照リンク。④品質指標: プロンプトごとにOCR正答率・推定精度などのメトリクスを記録し、改善サイクルを回す。	AI活用の品質・再現性を組織的に管理。プロンプトの属人化を防止。法改正追従（MAS-156）やOCR強化（MAS-180）の土台	プロンプトの保持先（シート vs ファイル vs ScriptProperties）。プロンプトのテスト方法（自動評価 or 手動レビュー）。Gemini と Claude で異なるプロンプト最適化の管理

🏢 事業・組織・BizDev（16 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-028	Story	📊 Report	ARR/MRR トラッキング	BizDev	P2	★★	未着手	—	プロダクト別の月次定期収益（MRR）と年換算（ARR）を自動集計。新規MRR・Expansion MRR・Churn MRR・Net New MRRの4分類で推移を可視化。	プロダクト事業の成長速度をリアルタイムに把握。Compound Growth の実績トラッキング	MRRの計上基準（契約日 vs 入金日）。年額契約の月割り方法
MAS-029	Story	📊 Report	ユニットエコノミクス（LTV/CAC）	BizDev	P2	★★	未着手	—	顧客獲得コスト（CAC）と顧客生涯価値（LTV）を自動算出。LTV/CAC比率、Payback Period（回収期間）を月次で表示。	「顧客1社を獲得するコストに対してどれだけの利益を得られるか」の定量化。投資判断の基礎	LTVの計算方法（ARPU ÷ チャーンレート or コホートベース）。CACに含める費用の範囲
MAS-030	Story	—	コホート分析	BizDev	P3	★★	未着手	—	顧客を獲得月別にコホートに分類し、月次のリテンション率・チャーン率・Expand率を追跡。コホートごとの収益推移（Land & Expand の可視化）。	「いつ獲得した顧客がどう育っているか」を可視化。Atlassian型の Land & Expand（初期$4,800→11年後$1M+）を自社で追跡可能に	コホートの粒度（月次 vs 四半期）。Expand の定義（アップセル・クロスセル・追加ライセンスの区別）
MAS-031	Story	—	Compound Growth シミュレーション	BizDev	P3	★	未着手	—	成長率×年数の複利計算でARR推移を予測。T2D3モデルとの比較表示。「現在の成長率が続くとN年後にARR Xに到達する」を可視化。	事業計画の数値的根拠。投資家・経営陣への説明資料の自動生成	成長率の前提（過去実績ベース vs 目標ベース）。季節変動の補正方法
MAS-032	Story	—	プロダクト別P/L	BizDev	P2	★★	未着手	—	受託事業とプロダクト事業のP/Lを分離して表示。プロダクト事業の売上原価（開発人件費の按分）・粗利率・営業利益率を個別に算出。	受託の利益でプロダクト投資を賄っている構造を定量的に把握。事業ポートフォリオの意思決定材料	開発者の工数按分方法（受託 vs プロダクト vs R&D）。共通費の配賦ルール（MAS-006の拡張）
MAS-033	Story	—	Rule of 40 スコアボード	BizDev	P3	★	未着手	—	プロダクト事業の成長率＋利益率が40%以上かを月次で判定・表示。閾値割れ時にアラート。	健全な成長と収益性のバランスをモニタリング	利益率の定義（営業利益率 vs EBITDA margin）。成長率の算出期間（MoM vs YoY）
MAS-100	Story	🧠 Domain	請求書発行（見積書・納品書・請求書PDF生成）	請求管理	P2	★★	未着手	—	売上パイプライン(21tab)の受注確定データ or 手動入力から、見積書→納品書→請求書のPDFを自動生成。テンプレートはGoogleドキュメント or HTML→PDF変換。インボイス制度対応（T番号・適格請求書フォーマット）。発行済み請求書は32_wrk_invoiceに収入INVとして自動登録→売上計上連動。	売上サイクルの完結。現状は売上INVの記帳のみで顧客向け請求書の発行機能がない	テンプレートのデザイン。請求書番号の採番ルール。メール送付の自動化要否
MAS-101	Story	📊 Report	債権管理・売掛金エイジング	債権管理	P2	★★	未着手	—	収入INV（収支区分=収入）の未決済残高を取引先別×経過日数別に集計し、売掛金エイジングレポートを自動生成。区分: 当月/30日超/60日超/90日超/長期滞留。長期滞留は貸倒引当金（MAS-084）と連動。アラート: 60日超過で警告色表示。回収予定日と実績の乖離を可視化。	売掛金の回収リスクを可視化。資金繰り予測(MAS-008)の精度向上にも貢献	エイジング区分の閾値。取引先ごとの支払条件（net30/net60等）の管理方法
MAS-104	Story	🧠 Domain	支払依頼ワークフロー	ワークフロー	P3	★	未着手	—	経費や仕入の支払依頼を申請→承認するフロー。現状は32tabで直接ステータス変更しているが、申請者→承認者の2段階ワークフローを導入。申請シート or GASダイアログで入力→メール通知→承認者が承認→32tabに自動反映。代表1名体制では簡易版（申請→自動承認+ログ記録）でも可。	内部統制の基礎。「誰が申請し誰が承認したか」の記録。会社規模拡大時の準備	承認者の設定方法。金額閾値による自動承認（N万円以下は自動）。MAS-264（承認チェーン）との関係整理
MAS-128	Story	🎨 UI	発注承認ワークフロー（金額閾値ベース）	ワークフロー・内部統制	P3	★	未着手	—	発注金額に応じて承認者を自動決定するワークフロー。①閾値ルール: N万円未満=自動承認、N万円以上=代表承認など、03_sys_params で金額閾値を設定。②UI: 31タブで発注ID発番時に承認状態を判定し、承認必要なら「承認待ち」ステータス+メール通知。③ログ: 承認者・承認日時を記録。MAS-104（支払依頼ワークフロー）と共通基盤化を検討。	内部統制の基礎。会社規模拡大時の承認プロセス整備	MAS-104との共通化範囲。代表不在時の代理承認ルール。閾値未満でも特定取引先は承認必須などの例外設計
MAS-129	Story	🧠 Domain	見積中ORDの複数見積比較機能	調達統制	P3	★	未着手	—	同一案件に対する複数の見積（見積中ステータスのORD）を並列管理し、比較→採用決定を行う機能。①案件キー: 「案件ID」列を新設し、同一案件の複数見積を紐付け。②比較ビュー: 金額・納期・取引先・条件を横並びで表示するダイアログ or 専用タブ。③採用決定: 採用見積を「発注済」に昇格、他の見積を「失注」ステータスに自動遷移。	調達プロセスの統制。相見積の記録化により妥当性説明が可能に	案件IDの採番ルール（手動 or 自動）。失注見積の保持期間。MAS-125（ステータス標準化）と合わせた設計
MAS-228	Task	🛠️ Ops	業務委託契約書テンプレ + 社労士連携窓口整備	組織・法務	P3	★★★	未着手	—	→ 採用内定から契約締結までを 2 週間以内で回せる状態を作る。MAS-230 と並行着手。①業務委託契約書テンプレ作成: 以下を含む雛形を `docs/_internal/biz/contract_templates/gyoumu_itaku_base.docx`（Word）+ `_base.md`（差分管理用）で整備。(a) 業務範囲（GAS 実装 / PR 提出 / レビュー対応）、(b) 成果物と納期、(c) 月額報酬・支払日、(d) 稼働時間の目安・稼働報告書様式、(e) 秘密保持条項（顧客データ・財務データ・ソースコード）、(f) 競業避止（同業他社への委託制限、期間 6 ヶ月）、(g) 成果物の知的財産権（bizlp への帰属）、(h) データ取扱い・貸与物返還、(i) 離脱時手順（アカウント削除・データ消去証跡・バックアップ削除）、(j) 再委託の可否（原則禁止）、(k) 契約解除条項（両者 30 日前通知）。②正社員雇用契約雛形: 別途社労士相談（月額 3-5 万）で雇用契約書 + 就業規則 + 36 協定 + 労働保険加入手続き。内定者確定後に着手。③インターン契約雛形: 業務委託（学生フリーランス扱い）ベース + 学業優先条項。④社労士選定: 法人経営の顧問として中小企業対応経験のある社労士 1-2 名を比較（月額顧問 vs スポット契約）。⑤NDA 先行締結: 面接前カジュアル面談段階で NDA（`nda_template.md`）を締結。⑥弁護士レビュー: 最終版は弁護士に 1 回レビューさせる（10-20 万円程度のスポット）	採用パイプラインが詰まらないよう法務を先回り整備。契約書作成から締結まで 2 週間 → 2 日に短縮。MAS-222 開発端末ポリシーと一体運用で情報漏洩リスク最小化	社労士選定基準（月額顧問 vs スポット）、弁護士スポットレビューのタイミング（テンプレ完成時 or 初契約時）、競業避止の期間と範囲（6 ヶ月 / 1 年の判断）、成果物帰属の範囲（個人貢献 vs 共同成果の区別）、知的財産権の Academic Use 例外、遠隔勤務時の労働時間管理義務（正社員のみ該当）
MAS-230	Task	🛠️ Ops	採用要件定義（Jr スキル要件・3 契約形態対応・評価基準）	組織・採用	P3	★★★	未着手	—	→ 2-3 人体制（Sr + Jr × 1-2）整備の最優先案件。D-180（2026-10 入社想定）向け採用準備の起点。①スキル要件: GAS 経験不問、React / TypeScript / Git / GitHub PR 運用の経験を優遇。会計知識は育成前提。コーディングテスト（Findy / Track Test 等）で基礎力スクリーニング。②契約形態別条件の確定: (a) 正社員 = 月額 35-45 万 + 社保負担、就業規則・36 協定整備が前提 → 社労士相談必須。(b) 業務委託 = 月額 40-60 万、6-12 ヶ月契約、成果物ベース。(c) インターン = 時給 2000-2500 円、週 20h、学生要件確認。③評価基準: 1 ヶ月試用期間の KPI（PR 数・差戻し率・質問の質）。3 ヶ月評価で継続 / 契約変更 / 終了を判断。④採用ルート: Findy or Forkwell（成功報酬 30-35%）+ Wantedly 直接求人の並行運用。D-150 公開、D-90 内定、D-30 入社準備。⑤面接プロセス: Sr による技術 1 次（60min）+ 人柄カジュアル（30min）。Junior 以外と紛れないよう「チーム構成（一人会社＋AI）」を冒頭で明示。前提: 本案件確定後に MAS-223/MAS-227/MAS-228 の内容が具体化する	採用プロセスを始められる土台。スキル要件と予算を確定させないと求人公開・面接基準がブレる。採用戦略全体の SSoT	正社員雇用時の社労士費用レンジ（月額 3-5 万）、コーディングテストツール選定（Findy Code / HackerRank / Track Test）、エージェント 2 社比較（Findy vs Forkwell）、候補者属性（第二新卒 / 経験 1-3 年 / 職種転換）の絞り込み、リファラル採用の検討、競合他社の Jr 採用条件調査
MAS-251	Story	🛠️ Ops	第三者監査・学術パートナー連携プログラム	事業・ガバナンス	P2	★★★	未着手	—	MAS-246〜05 の技術的妥当性を外部検証する体制構築。①学術パートナー（Phase 1）: 国内の差分プライバシー・秘密計算研究を牽引する研究室 / 国立研究機関との共同研究契約 or 技術顧問契約を締結。ε 妥当性・暗号理論的妥当性をレビュー依頼。②商用監査（Phase 2）: MVP 完成後に国内プライバシーテック専門事業者、または暗号実装監査に定評ある国内外の専門会社による実装監査を実施。③公的認証（Phase 3）: 公的機関の暗号モジュール評価・認証スキーム、登録監査法人による情報セキュリティ監査。④継続検証（Phase 4）: バグバウンティプログラム、OSS 公開によるコミュニティレビュー、年次レッドチーミング演習。前提/連携: MAS-211 (SOC 2 / ISO 27001) の認証取得フェーズと統合。	「雰囲気セキュリティ」ではなく「検証可能なセキュリティ」を事業資産化。研究開発税制（試験研究費）対象としての認定も強化	特定事業者との利害関係の事前整理、学術パートナー第一選択、論文共著時のオーサーシップ基準、監査結果公開範囲
MAS-252	Story	🛠️ Ops	データ主権プロダクトの HP 公開戦略	マーケティング・事業	P2	★★	未着手	—	3 段階の HP 公開戦略を自社コーポレートサイトに実装。①Phase A（MVP 完成時）: 「秘密計算 × 差分プライバシーによる管理会計基盤を開発中」で設計思想ページを公開。アーキテクチャ図・ロードマップ・研究開発パートナー告知。②Phase B（初期顧客獲得後）: アーキテクチャ詳細・Attestation 検証方法・ε パラメータ公開。技術ブログ連載開始。③Phase C（実績蓄積後）: OSS 化・学会/カンファレンス発表・論文化・メディア露出。④避ける表現: 「絶対安全」「完全に見えません」等の断定、脅威モデルを示さない曖昧な謳い文句。⑤使う表現: 「検証可能」「ε=X.X のプライバシー保証」「第三者監査済み（実施後）」など具体的・測定可能な言葉。	「信頼設計 × データ主権」という他社模倣困難なポジショニング確立。中小企業向け管理会計分野での差別化	既存コーポレートサイトのトーン整合、技術詳細ページと一般向けページの分離、OSS 化時のリポジトリ戦略（公開/一部公開/private）、発表先カンファレンス選定
MAS-253	Story	🛠️ Ops	顧客契約書のデータ主権条項テンプレート整備	法務・事業	P2	★★	未着手	—	MAS-246〜05 の技術的担保を法的にも裏付ける契約書テンプレート。①データ主権条項: 「甲は乙の生データにアクセスしない。アクセス不能な技術的措置（TEE/DP）を講ずる」を明記。②責任範囲: TEE 脆弱性発覚時の対応プロトコル、運営側の免責範囲、損害賠償上限。③R&D 同意書（MAS-259 と連携）: 匿名化データの研究利用同意を本契約と分離して取得。撤回可能性を明記。④研究成果公表条項: 論文・ブログで公表する際の顧客同意プロセス、匿名化水準の取り決め。⑤解約時データ削除保証: 30 日以内削除・削除完了報告書の発行。⑥インシデント対応: データ漏洩疑い発生時の通知義務・調査協力・損害補填。	技術・法務・契約が三位一体となったデータ主権の担保。顧客側の法務部門への説明コスト削減	外部弁護士レビュー要否（プライバシー法務に強い専門弁護士が候補）、個人情報保護法との整合、インボイス制度・電帳法との整合、英文版の要否（将来の海外展開）

🗃️ その他・対象外（13 件）

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
~~MAS-092~~	Story	—	~~税務申告用データ抽出エクスポート~~	—	—	—	対象外	—	→ MAS-282 に移動。税務申告は顧問税理士の責務。必要データは freee/MF → 税理士で完結	—	—
~~MAS-099~~	Story	—	~~残業代の計算・HC RPA連携~~	—	—	—	対象外	—	→ MAS-279 に移動。給与計算SaaS（freee人事労務等）の責務	—	—
~~MAS-102~~	Story	—	~~振込データ自動作成（全銀フォーマット）~~	—	—	—	対象外	—	→ MAS-283 に移動。ネットバンキング or 給与計算SaaSの振込機能の責務	—	—
~~MAS-103~~	Story	—	~~給与明細PDF生成・配布~~	—	—	—	対象外	—	→ MAS-284 に移動。給与計算SaaS（freee人事労務等）の標準機能	—	—
~~MAS-106~~	Story	—	~~年末調整データ生成~~	—	—	—	対象外	—	→ MAS-285 に移動。年末調整は給与計算SaaS（freee人事労務等）+ 顧問税理士の責務	—	—
~~MAS-107~~	Story	—	~~算定基礎届データ生成＋社保年齢判定の自動化~~	—	—	—	対象外	—	→ MAS-278 に移動。給与計算SaaS（freee人事労務等）の責務	—	—
~~MAS-108~~	Story	—	~~源泉所得税の月額表自動計算~~	—	—	—	対象外	—	→ MAS-280 に移動。給与計算SaaS（freee人事労務等）の責務	—	—
~~MAS-109~~	Story	—	~~賞与計算・役員賞与・決算賞与~~	—	—	—	対象外	—	→ MAS-281 に移動。給与計算SaaS（freee人事労務等）の責務	—	—
MAS-180	Task	📥 Import	~~AI-OCR連携による証憑自動起票~~	—	—	—	未着手	—	→ Section 5（自動入力・運用パイプライン）に移動	—	—
MAS-181	Task	🗑️ Deprecated	~~銀行API連携による入出金明細の自動取得~~	—	—	—	未着手	—	→ Section 5（自動入力・運用パイプライン）に移動	—	—
MAS-183	Task	🗑️ Deprecated	~~月次決算チェックリストの自動化~~	—	—	—	未着手	—	→ Section 5（自動入力・運用パイプライン）に移動	—	—
MAS-186	Task	🗑️ Deprecated	~~経費精算のSlack/Chatwork連携~~	—	—	—	未着手	—	→ Section 5（自動入力・運用パイプライン）に移動	—	—
MAS-198	Task	—	Backlog API連携（課題管理同期）	外部連携	P2	★★	仕様書完了	—	96_backlog_tasks シートから Backlog へ課題一括登録・ステータス双方向同期。既知の不整合タスク自動投入。→ 開発手順	外部課題管理との連携基盤	Backlog スペース・プロジェクトの設定値

⚡ 3.2 自動入力・運用パイプライン

ゴール

「4つの証憑（領収書・請求書・カード明細・銀行入出金）を入れたら、あとはポチポチするだけで実績の集計・見える化ができる」

現状フロー（月次約30分の手動作業）

カード明細 ─[手動CSV貼付]─→ 34tab ─[手動マッチ確認]─→ [手動消込実行]─┐
領収書PDF ─[手動Drive投入]→ 35tab ─[手動マッチ確認]─→ [手動消込実行]─┤
請求書    ─[手動で32tab入力]────────────────────────────────────────────┤
銀行入出金 ─[手動で33tabに決済日入力]─[手動でステータス変更]────────────┤
                                                                       ↓
               [Action Aクリック] → [Action Bクリック] → [マート更新クリック]
                                                                       ↓
                                                              財務3表(P/L・B/S・CF)

ボトルネック: 銀行入出金の手動入力（決済日・ステータス）、消込確認の目視チェック、メニュー3回クリック

目標フロー（月次約5分）

カード明細CSV ─[貼付]──→ ✅自動マッチ＋高信頼度は自動消込 → 残りだけ確認
領収書PDF   ─[Drive投入]→ ✅自動OCR＋自動マッチ＋税区分推定 → 残りだけ確認
請求書PDF   ─[Drive投入]→ ✅自動OCR＋INV自動起票＋科目推定 → 科目だけ確認
銀行CSV     ─[貼付]──→ ✅自動マッチ＋決済日自動入力＋自動消込 → 残りだけ確認
                                        ↓
                          🔘 ワンクリック月次締め（A＋B＋マート一括）
                                        ↓
                                財務3表(P/L・B/S・CF)

削減される手動ステップ: 決済日の手入力、ステータス変更、低リスク消込の目視確認、メニュー3回→1回

案件一覧

ID	Type	Layer	案件名	Phase	優先度	ステータス	完了日	概要	削減される手動ステップ	検討事項
MAS-145	Story	📥 Import	法人口座CSV取込・自動マッチング	P1	★★★	完了	04-16	銀行の入出金明細CSVを取り込み、33_wrk_bank の未処理STLと自動マッチング。決済日_実績・決済ステータスを自動設定。福井銀行フォーマット対応。36_wrk_bank_importタブ新設、3パスマッチング（完全一致→合算候補→候補提案）、確認FLG+消込実行の2段階。→ 開発仕様書	銀行入出金の手動入力を完全排除（現状最大のボトルネック）	—
MAS-146	Story	📥 Import	カード明細の高信頼度自動消込	P1	★★★	仕様書完了	—	既存のCC明細マッチング（501_cc_importer.js）に「自動承認」モードを追加。金額完全一致＋取引先辞書ヒットの場合は確認FLGなしで即消込。閾値は03_sys_paramsで設定可能。→ 開発仕様書	CC消込の目視確認を95%削減（辞書ヒット分は自動）	自動消込の閾値（金額一致のみ or 日付±N日も条件に含めるか）。誤消込時のロールバック手順
MAS-147	Story	—	請求書PDF→INV自動起票 (v2 Document AI ハイブリッド)	P1	★★★	完了 (v2)	2026-04-24	→ 開発仕様書 (v2) / MAS-306 設計検討結果。v2 設計: 責務分離 (Fact = Document AI / Reasoning = Gemini)、T 番号カラム必須化、多段 Pass 0〜6、複合確信度スコア (baseFactConf × 0.8 + geminiConf × 0.2) と即死ルール、1:N 分割マッチ実装格上げ、フォルダ分離・電帳法リネーム運用 (MAS-152 統合)、非同期キュー 1〜2 件化、採否判断マトリクス (30 枚/200 枚/1000 枚)。前提案件: MAS-215 (GCP プロジェクト整備・Document AI 有効化)、MAS-152 (電帳法リネーム、フォルダ運用統合先)、MAS-157 (写真 OCR)、MAS-120 (PartnerRepository・完了)、MAS-154 (normalizePartnerName・完了)。関連: MAS-171 (Subset Sum 共通ヘルパー)。v1 資産: feat/MAS-147-invoice-ocr-auto-posting ブランチに凍結、v2 で必要部分のみ cherry-pick 再利用	請求書の手入力を排除。Auto-Link 率 85% 超、HitL 工数を月 60 分 → 月 7.5 分に削減 (月間 100 通想定)	DocAI プロセッサリージョン、Gemini → Vertex AI 移行タイミング、T 番号未登録取引先の扱い、1:N 分割マッチ閾値チューニング、HitL サイドバー幅、失敗時リトライ戦略
MAS-086	Story	🔧 Infra	領収書→26タブ登録時の税区分自動判定	P1	★★	仕様書完了	—	課税事業者移行後に消費税額から税区分を自動判定（税抜額×10%≒税額なら「課税10%」等）。→ 開発仕様書	領収書登録時の税区分手選択を排除	税区分の判定ルール（税率からの逆算精度。軽減税率8%との判別）
MAS-157	Story	📥 Import	写真(JPEG/PNG)対応の証憑OCR + 電帳法品質チェック	P1	★★★	仕様書完了	04-16	現行の502_receipt_reader.jsはPDFのみ対応。スマホで撮影した領収書・レシートの写真（JPEG/PNG/HEIC）もGemini OCRで読み取れるよう拡張。→ 開発仕様書	紙の領収書を写真で撮るだけで自動入力完了。電帳法の品質要件も自動検証し、不適合な画像は再撮影を促す	HEIC(iPhone標準形式)→JPEG変換の要否。解像度チェックの閾値（200dpi相当のピクセル数をレシートサイズから逆算）。1枚に複数レシートが写っている場合の扱い。タイムスタンプ要件への対応方針（Drive更新日時で代替可能か、別途タイムスタンプサービス必要か）
MAS-180	Task	📥 Import	AI-OCR連携による証憑自動起票（強化版）	P2	★★	未着手	—	現行Gemini OCR（502_receipt_reader.js）の精度向上。①T番号の正規化 ②取引先名の表記ゆれ→マスタ照合 ③複数ページ請求書の合算処理。エラー時のフォールバック（手動確認キュー）。MAS-157（写真対応）実装後は画像特有のノイズ除去も含む。	OCR後の手動修正を削減（現状は抽出結果の目視確認が必要）	Gemini APIコスト上限。プロンプトチューニングの工数
MAS-148	Story	🧠 Domain	ワンクリック月次締め	P1	★★★	仕様書完了	—	メニュー「📊 月次締め実行」1つで Action A → Action B → マート更新を連続実行。事前バリデーション（未マッチSTL・未承認INVの警告）付き。完了後にサマリーダイアログ表示。→ 開発仕様書	メニュー3回クリック→1回に統合。事前チェックで差戻し漏れも防止	GAS 6分実行制限への対策（MAS-194と連携）。途中エラー時のリカバリー方針
MAS-149	Story	—	取込進捗ダッシュボード	P2	★★	未着手	—	月次締め前の取込状況を一覧化するサマリーシート（97_import_status等）。CC未マッチ件数、領収書未処理件数、STL未消込件数、INV未承認件数をリアルタイム集計。	「あと何をやれば締められるか」の可視化（現状は各タブを個別確認）	シート形式 or サイドバーUI。自動更新トリガー（onOpen or 手動）
MAS-160	Story	—	月次締め前未処理アラート・サマリーUI	P1	★★	仕様書完了	04-20	月次締め実行前に未処理項目（未消込STL・未承認INV・差戻し保留など）を能動検知してダイアログ表示。MAS-148 ワンクリック月次締めの前段フックとして機能。→ 開発仕様書。前提案件: MAS-148（ワンクリック月次締め）	月次締め前の各タブ目視チェックを排除。「締め忘れ」「未処理放置」をシステム側で検知	検知する未処理項目の粒度（STL のみ or INV/差戻しも含む）。締めをブロックするか警告のみか。通知形式（ダイアログ or サマリーシート表示）
MAS-183	Task	🗑️ Deprecated	月次決算チェックリスト	P2	★★	未着手	—	月次締めの前提条件を自動判定し可視化。「CC取込済✅」「領収書処理済✅」「全STL消込済✅」「Action A実行済✅」等。MAS-149のダッシュボードと統合可能。	月次締め前の確認作業を構造化。抜け漏れ防止	チェック項目の洗い出し（経理業務フローの棚卸し）
MAS-181	Task	🗑️ Deprecated	銀行API連携（将来）	P3	★	未着手	—	MAS-145のCSV取込を置き換え、銀行APIで日次自動取得。Money Forward等のアグリゲーション経由 or 銀行直接API。	CSV貼付すら不要に（完全自動化の最終ゴール）	銀行API契約要件。アグリゲーションサービスのコスト。セキュリティ要件
MAS-186	Task	🗑️ Deprecated	経費精算のチャット連携（将来）	P3	★	未着手	—	Slack/Chatwork上で領収書画像を送信→Gemini OCR→26_bud_adhocに自動登録→RPA起票。	経費精算の入力デバイスをスマホに拡張	チャットツールの選定。Bot開発の工数。承認フローの要否
MAS-150	Story	📥 Import	証憑取込→20番台マスタ自動起票（取込後の提案型）	P1	★★	仕様書完了	04-18	銀行CSV・カード明細・領収書を取り込んだ際、対応する予算マスタ（23_bud_subscription / 26_bud_adhoc 等）が存在しなければ自動生成する取込後の提案型アプローチ。取引先名＋科目推定（aiSuggestAccount）で候補行を作成し、ユーザーは金額・科目を確認するだけ。→ 開発仕様書（代替アプローチは MAS-169 参照）。前提案件: MAS-145（銀行CSV取込・完了済）、MAS-154（取引先略称・完了済）、MAS-146（カード自動消込）	取込データの「行き先なし」問題を解消。予算マスタの手動追加が不要に	自動起票先の判定ロジック（SaaS定期 vs 単発経費 vs 財務取引）。既存マスタとの重複判定基準
MAS-151	Story	—	実績ベースの中期予算自動生成	P2	★★	未着手	—	過去〜当年度の実績（42_trn_journal / 32_wrk_invoice）を科目×取引先で集計し、来年度以降最大3〜5年分の予算見込みを自動生成。Step 1 (翌期): SaaS系は月額実績→23tab、人件費は直近給与→22tab、単発経費は月平均→26tab に振り分け。Step 2 (2年目以降): 科目カテゴリ別に成長率を適用（売上=前年比×成長率、固定費=据置き、変動費=売上連動）。成長率は03_sys_paramsで設定可能（デフォルト: 売上+10%、コスト+3%等）。ユーザーは生成結果を確認・調整してから有効化。MAS-177(多年度基盤)実装後は年度別シートへの展開も可能。	予算ゼロからの手入力を排除。「去年実績＋成長率」で数年分の予算が5分で作れる。事業計画・資金計画の基礎データとしても活用	成長率の設定単位（全社一律 or 科目別 or 取引先別）。季節変動の扱い（月平均 vs 同月実績）。MAS-177未実装時の暫定運用（単年度×N回生成で代替可能か）
MAS-152	Story	📥 Import	証憑ファイル名の電帳法準拠リネーム	P1	★★★	仕様書完了	04-18	電子帳簿保存法（スキャナ保存）の検索要件に準拠し、領収書・請求書PDFを自動リネーム。Gemini OCR で抽出済みの取引年月日・取引先名・取引金額を使い `YYYYMMDD_取引先名_金額_元ファイル名.pdf` 形式に変換。処理済みフォルダへの月別整理（`processed/YYYY-MM/`）も併せて実施。502_receipt_reader.js の `importReceiptPdfs()` 後処理として組み込み。MAS-153の前提。→ 開発仕様書。前提案件: MAS-154（取引先略称自動生成・完了済）	電帳法の検索要件3項目（日付・取引先・金額）をファイル名で充足。税務調査時の証憑検索が即座に可能。Drive検索でも機能する	ファイル名の最大長（Drive制限）。取引先名の略称化ルール（長い正式名称の短縮方法）。複数ページPDFで金額が複数ある場合の扱い
MAS-154	Story	📥 Import	取引先マスタの論理略称カラム追加＋自動生成	P1	★★	完了	04-16	12_mst_partner に「略称」「銀行摘要名」列を新設。略称は法人格除去で自動生成（807_migration_i10.js）。銀行摘要名はMAS-145の名寄せマッチングで使用。→ 開発仕様書	取引先名の表記ゆれ問題を根本解決	—
MAS-153	Story	🛠️ Ops	ファイル名ベースの証憑リンク再構築	P1	★★★	仕様書完了	04-18	会計士へのデータ共有時、証憑PDFを別のGoogle Driveフォルダにコピーすると証憑URL（ファイルID）が切れる問題を解決。指定フォルダ内のファイル名を走査し、35_wrk_receipt の`ファイル名`列と照合して`証跡リンク`を再生成。さらに32_wrk_invoice・31_wrk_order・42_trn_journal の`証憑URL`列も連鎖更新。MAS-152で電帳法準拠のファイル名が統一されていれば照合精度100%。スクリプトプロパティ `EVIDENCE_FOLDER_ID` で対象フォルダを切替え可能にし、社内用／会計士共有用を使い分け。→ 開発仕様書	Drive移動・コピー後のリンク切れを一括修復。会計士提出用データの証憑参照性を維持	同名ファイルが複数存在する場合の優先ルール（最新日時 or エラー）。会計士共有フォルダの権限設定（閲覧のみ or 編集可）
MAS-155	Story	—	Outlookメールからの請求書・領収書自動取得	P2	★★	未着手	—	Microsoft Graph API 経由で Outlook 受信トレイを定期走査し、PDF添付ファイルを自動で Google Drive の領収書フォルダに保存。①件名・送信元で請求書/領収書メールをフィルタ（キーワード: 請求書, invoice, 領収書, receipt, ご利用明細等） ②PDF/画像添付を抽出→Drive保存 ③既存の502_receipt_reader.js のOCRパイプラインに自動連携。Power Automate（無料枠）経由で Drive 投入する軽量版も選択肢。GASの `UrlFetchApp` + Graph API トークンで直接実装も可能。	「Drive に PDF を手動アップロード」の手間を完全排除。メール受信→OCR→マッチング→消込の全自動化が実現	Microsoft 365 テナント設定（Graph API のアプリ登録・権限）。OAuth2 トークンの管理方法（GAS の ScriptProperties vs 外部）。重複取込防止（処理済みメールのマーキング方法: 既読/ラベル/カテゴリ）
MAS-158	Story	📥 Import	給与計算SaaSデータ取込（freee人事労務 / MFクラウド給与）	P1	★★★	仕様書完了	—	給与計算SaaSのCSVエクスポート or APIから、従業員別の月次給与データ（基本給・残業代・各種手当・源泉税・住民税・社保従業員負担・社保会社負担・差引支給額）を取得し、22_bud_headcount の各列に自動反映。現状の手入力（源泉税額・社保額等）を置き換える。①CSV取込: SaaSの給与明細CSVを Drive にアップロード→ 管理ID で22タブの従業員行と照合→ 各控除額列を上書き。②API取込（将来）: freee人事労務 API or MFクラウド給与 API で月次確定後に自動取得。OAuth2認証はMAS-155(Outlook連携)と同様のパターン。③差分検知: 前月比で大幅な変動があった場合（昇給・異動等）にアラート表示。→ 開発仕様書	給与計算は専門SaaSに任せ、本システムは確定額の取込と管理会計への反映に専念。手入力ミスの排除、月次の転記作業ゼロ化	利用する給与計算SaaSの選定。CSV/APIのデータ項目と22タブ列のマッピング定義。取込タイミング（給与確定後の何日目？）
MAS-156	Story	—	運用ナビゲーター（スケジュール通知＋対話型ガイド＋法改正追従）	P2	★★★	未着手	—	月次経理の「次に何をすべきか」を自動で教えてくれる運用アシスタント。3段階+法改正追従機能。Tier 1 (GAS通知): 運用カレンダーシート（98_ops_calendar）に月次タスクを定義（例: 5日=CC明細取込、10日=銀行CSV取込、25日=月次締め）。GAS時間トリガーで毎朝チェック→当日タスクをメール通知。未完了タスクはリマインド。Tier 2 (Claude Code運用エージェント): CLAUDE.md に運用手順書を組み込み、Claude Codeで `/ops` 実行→MCP経由でスプレッドシートの状態を確認（未消込STL件数、未承認INV件数等）→「今日やるべきこと」を状況に応じて対話的にガイド。Tier 3 (自律エージェント): Claude Agent SDK で運用専用エージェントを構築。スプレッドシートを定期監視し、異常検知・タスク提案・一部自動実行まで担う。Slack/Teams 連携で通知。法改正追従（Tier 2で実現）: Claude Code はコードベース全体を把握しているため、`/law-check` 等のコマンドで「今年の税制改正でこのシステムに影響するのは何？」→影響ファイル・定数・シートを特定→修正コード提案まで対話的に実行可能。具体例: ①源泉税額表の年次改定→MAS-108マスタ更新 ②社保料率の改定→MAS-107等級表更新 ③インボイス制度改正→MAS-100テンプレート修正 ④電帳法要件変更→MAS-152/MAS-157のチェック基準更新。従来は社労士・税理士に都度相談（数万円+数日）だった法改正対応が、Claude Code への質問（0円+数分）で完結。	「何をいつやればいいか分からない」を解消。属人化した経理知識をシステムに定着させる。法改正の影響分析と修正を社労士/税理士への依頼なしで自社対応可能に。Tier 2 なら Claude Code の既存基盤で実現可能	Tier 1: 運用カレンダーの項目定義（経理業務の棚卸し）。通知手段（メール or Slack）。Tier 2: MCP サーバーの設定（Google Sheets API 接続）。運用手順の CLAUDE.md 記載粒度。法改正情報の取得元（国税庁/厚労省のRSS or 手動確認）。Tier 3: Agent SDK のホスティング環境。自律実行の権限範囲（読取のみ or 書込みも許可）
MAS-169	Story	🧠 Domain	証憑取込→20番台マスタ自動起票（仕訳直前インライン自動登録 / MAS-150 派生）	P1	★★	仕様書完了	04-18	MAS-150（取込後の提案型）の代替アプローチ。仕訳生成ロジックの直前に 20 番台マスタ存在チェックを挟み、欠落時はインラインで自動登録してから仕訳を発行する方式。BudgetSubscriptionRepository / BudgetAdhocRepository / BudgetFinanceRepository などを新設し、MasterAutoRegistrar で begin/ensureMaster/commit のバッチ API を提供。→ 開発仕様書	取込データの「行き先なし」問題をインライン解消。MAS-150 提案型との二択設計	MAS-150 提案型とのどちらを本採用にするか（あるいは共存するか）の判断
MAS-171	Story	📥 Import	クレカ明細 N:1 消込（複数カード明細 → 1 銀行STL 合算マッチ）	取込・マッチング	P2	★★	仕様書完了	04-20	→ 開発仕様書 MAS-162（銀行CSV合算マッチ・銀行側 N:1、実装済）のカード側対称版。1 枚の銀行引落 STL に対して複数のカード明細が紐づくケース（カード会社からの月次一括引落）に対応。①合算対象: 同一カード会社・同一締日・同一引落日の複数カード明細をグルーピング。②マッチングロジック: 合算金額が銀行STL金額と完全一致、または差額が規定額以内であれば MATCHED。③N:1 の STL 解消: 親STL（銀行側1件）に子STLs（カード側複数件）を紐付け。前提案件: MAS-159（完了済 PR #221）。参考: MAS-162（銀行側 N:1・実装済）	カード会社月次一括引落の消込を自動化。現状は手動で合算計算が必要
MAS-172	Story	—	クレカ MATCHED 自動承認化の検討（HITL 緩和案）	UX・データ品質	P3	★	未着手	—	MAS-159 実装検討時に論点化。現状 CC MATCHED 行は `確認FLG=FALSE` で人間レビュー必須（Human-in-the-Loop）。Pass 1 条件を「金額完全一致」に厳格化できれば `確認FLG=TRUE` 自動承認も選択肢。方向性: (1) 現状維持（最も安全）、(2) Pass 1 を金額完全一致化 → MATCHED=TRUE 自動承認、(3) 信頼度別分岐（完全一致=TRUE / ±20%=FALSE）。前提: MAS-146（カード明細自動消込）実装完了時に方針確定。	消込オペレーションの工数削減。ただし監査観点の「必ず人間が確認」原則とトレードオフ
MAS-175	Story	🧠 Domain	OCR 失敗 PDF の手動取込・分類ツール	自動入力パイプライン・OCR	P2	★★	仕様書完了	2026-04-22	→ 開発仕様書。前提: MAS-147 v2 の Step 4-C `runInvoiceBatch_` / `99_error/` フォルダ運用完了。ユースケース: MAS-147 v2 で DocAI 抽出失敗した PDF（画像化 PDF / スキャン画質低 / 手書き混在 / 請求書以外（見積書・納品書・契約書）/ DocAI 未対応の縦書き・枠線過密フォーマット / 必須フィールド `total_amount` / `vendor` 抽出不能）を救済する。設計 5 機能: (A) 99_error/ PDF 一覧 UI（サイドバー「🚨 OCR 失敗 PDF」セクション。ファイル名・サイズ・プレビュー・失敗理由・アクション 4 種）、(B) 手動メタデータ入力フォーム（取引先名 / 税込金額 / 発生日 / 決済日 / 税抜金額 / 消費税 / T 番号 / docNumber / 摘要 / 証憑種別を PartnerRepository プルダウン + 三者整合検証付き）、(C) 書類種別分類（請求書 / 見積書 / 領収書 / 契約書 / その他、請求書以外は `06_not_invoice/` 退避して 32_wrk_invoice に入れない）、(D) Gemini `gemini-2.5-flash` 直接投入フォールバック（`callGeminiForReceiptOnVertex_` 知見流用、成功時は MAS-147 v2 通常フローに合流、失敗時は (B) 手動入力へ）、(E) フロー分岐（Step 4-D HitL サイドバー合流 / 直接新規 INV 作成 + 26_bud_adhoc 新規登録提案 / 対象外別フォルダ保管）。関連案件: MAS-147 v2（HitL サイドバー）、MAS-157（写真レシート OCR・画像化 PDF との統合余地）、MAS-216（Vertex AI 移行・Gemini 直接投入基盤）	OCR 失敗を「闇に消さず」に救済パスを用意。DocAI の苦手領域（画像化 / 手書き / 非請求書）を人手 + Gemini 直接投入で最後まで処理し、月末締めで「取込漏れ PDF が放置されている」事象をゼロに
MAS-173	Story	📥 Import	複合機スキャン→Drive 自動投入→OCR 連携（紙証憑の電子化パイプライン）	取込・自動化	P2	★★	未着手	—	§6.2 Flow 8「スキャナ経由（紙→電子化）」の未案件化を解消。紙の請求書・領収書を複合機（富士フイルム / リコー / キヤノン等）でスキャン→PDF化→Drive 特定フォルダへ自動投入→既存 `mas/500_import/502_receipt_reader.js` の OCR パイプラインに連携する。①複合機側設定: Scan-to-Email（Drive サブアドレス）または Scan-to-Folder（SMB/WebDAV）経由で Drive 同期。②電帳法スキャナ保存要件の自動検証: 解像度（200dpi 相当のピクセル数計算）、カラー/白黒モード（赤記載確認のためカラー推奨）、ファイルサイズ・タイムスタンプ整合性。不適合は検疫フォルダへ隔離しアラート。③MAS-157 との住み分け: MAS-157（スマホ写真 JPEG/PNG/HEIC）vs MAS-173（複合機 PDF）で取込経路を分離、共通 OCR 基盤（`importReceiptPdfs()`）を流用。④1 枚 1 ファイル vs 連結 PDF: 複合機側の既定値に合わせて分離/合算ポリシーをスクリプトプロパティで切替。前提案件: MAS-152（電帳法リネーム）、MAS-157（写真 OCR）、MAS-180（OCR 精度強化）	Drive 手動アップロードの完全排除 + 電帳法スキャナ保存要件の物理的充足。紙証憑運用の最終ピースを自動化
MAS-174	Story	🎨 UI	小口現金・事後発生経費の即時登録 UI（設計変更: GAS サイドバー → Cockpit パネル）	UX・取込	P2	★★	未着手（設計変更要）	—	⚠️ 2026-05-11 設計変更: GAS 操作パネル廃止方針により、当初の「GAS HtmlService サイドバー」実装は破棄。Cockpit 内パネル（`webapp_client/src/cockpit/` 配下の新規コンポーネント）として再設計する。MAS-358（Cockpit 左ナビ）の画面固有サイドバーに「💰 即時登録」メニューを追加し、そこから入力パネルを起動する設計とする。§6.5「手入力のみ 25%（9 パターン）」のうち構造化入力可能なものを UI 化。現在 32/35 タブに直接手入力されている事後発生系経費（弔慰金・急な会食・交通系 IC チャージ・小口現金等）を、Cockpit から 3 クリックで登録できるようにする。①入力フォーム: 取引日・取引先（サジェスト）・科目（aiSuggestAccount）・金額・決済手段（プリセット選択）・証憑有無フラグ。②自動補完: 取引先未登録なら MAS-169 のインライン自動登録パターンを流用、科目は直近 30 日の類似パターンをショートカット化。③証憑リンク: サイドバー内から写真アップロード（MAS-157 経由）→OCR 結果を入力フォームに自動反映。④バッチ入力: 1 日分の複数経費をカード形式でまとめて登録可能に。⑤手動入力パターンの可視化: 併せて Flow 10 の 9 パターン内訳（本質的手入力 vs 自動化可能）を調査ドキュメントとして整理。前提案件: MAS-169（マスタ自動起票）、MAS-157（写真 OCR）	事後発生系経費の手入力を「32/35 タブ直接編集」から「サイドバー構造化入力」に置換。科目選択の迷い・取引先マスタの事前登録・位置指定ミスを同時に排除
MAS-176	Story	🌐 Cross	開発者向け AI ツール投資 ROI 管理（D.8 派生）	自動化	P1.5	★★★	未着手	—	D.8 §2.e-6 抽出案件。`23_bud_subscription` シートに `est_hours_saved_per_month`（想定月間削減時間）列を DDL で追加（`101_sys_config.js` 更新）。`22_bud_headcount` の役員年収÷稼働時間で算出した時間単価を乗じて月次 ROI を計算し `93_kpi_dashboard` に出力。計算ロジックは `mas/600_report/` または `mas/400_domain/` の既存ファイルへの関数追加で対応可能（新規 GAS ファイル不要の可能性あり）。対象ツール例: Cursor Pro $20 / Claude Max 5x $100 / GitHub Copilot Pro $10 / v0 $20 / ChatGPT Plus $20（合計月 $170 ≒ 25,500 円）。	月 2.5 万円のツール投資が月 10 万円相当の生産性を生むことを定量証明。継続的な AI ツール投資の正当化と予算確保に貢献。MAS-013（大型一時投資向け NPV/IRR）と異なり月額 SaaS というマイクロ規模の継続投資を、サブスクマスタと連動した月次自動モニタリングで評価
MAS-170	Story	—	法人番号自動取得（国税庁法人番号公表サイト Web-API 連携）	外部連携・マスタ自動補完	P1	★★	仕様書完了	—	取引先マスタ（12_mst_partner）の法人番号 / T番号入力を自動化。①API: 国税庁の法人番号公表サイト Web-API（`https://api.houjin-bangou.nta.go.jp/`、無料・APIキー不要だが利用申込制）を使用。法人名（漢字・カナ）から法人番号を引き、住所・本店所在地も取得。②呼び出しタイミング: (a) 12_mst_partner の `法人名` 列入力時の onEdit でリアルタイム検索、(b) 一括補完メニュー（既存マスタの空欄行を一括埋め）。③候補が複数ヒット時: モーダルで候補一覧表示→ユーザーが選択（同名異社対策）。④T番号への自動展開: 取得した法人番号 13 桁を `T` プレフィックス付きで保存（インボイス登録番号は法人番号と原則一致するため）。ただしインボイス登録の有無は別 API（適格請求書発行事業者公表サイト）で確認が必要な点に注意。⑤キャッシュ: API レスポンスを `99_cache_houjin_api` 等に 30 日キャッシュし、同一名再検索を抑制。⑥更新検知: 月次で全件再取得して名称変更・住所変更を検知（任意、運用負荷とのトレードオフ）。→ 開発仕様書	取引先マスタの手入力品質を向上。法人番号の打ち間違い防止、T番号の整合性担保、MAS-152（電帳法リネーム）/ MAS-114（インボイス検証）の前提精度を確保。MAS-120（取引先マスタ拡張）と組み合わせるとマスタ運用がほぼ自動化される

推奨実装順序

順番	ID	案件名	所要時間目安	理由
1	MAS-145	法人口座CSV取込	3-4時間	最大のボトルネック解消。決済日手入力が不要に。他の自動消込の前提
2	MAS-146	CC自動消込	2時間	既存501_cc_importer.jsの小改修。確認FLGスキップロジック追加
3	MAS-086	税区分自動判定	1時間	領収書登録の手間削減。小規模改修
4	MAS-148	ワンクリック月次締め	2-3時間	Action A+B+マート統合。UX改善の即効性が高い
5	MAS-157	写真(JPEG/PNG)対応の証憑OCR	1-2時間	即効。502_receipt_reader.jsのMIMEタイプ判定追加のみ。Gemini APIは画像対応済み
6	MAS-154	取引先の論理略称カラム＋自動生成	2-3時間	MAS-152のファイル名で使う略称の基盤。DDL変更+一括生成+UxAssist連携
7	MAS-152	証憑ファイル名の電帳法リネーム	1-2時間	MAS-154の略称を使用。OCR抽出済みデータ活用
8	MAS-153	証憑リンク再構築	1-2時間	MAS-152とセット。会計士共有時のリンク切れ一括修復
9	MAS-150	証憑→20番台マスタ自動起票	3-4時間	取込データの「行き先なし」解消
10	MAS-147	請求書PDF→INV起票	4-6時間	Gemini OCR拡張+INV自動生成
11	MAS-180	OCR精度強化	2-3時間	MAS-147/MAS-157の品質向上。画像ノイズ・取引先名正規化
12	MAS-151	実績ベース中期予算生成	3-4時間	実績→翌期〜数年分の予算をドラフト一括生成
13	MAS-149	取込ダッシュボード	2-3時間	月次締め前の可視化。MAS-183と統合
14	MAS-183	月次チェックリスト	1-2時間	MAS-149に統合する形で実装
15	MAS-156	運用ナビゲーター (Tier 1→2)	Tier1: 2-3時間 / Tier2: 4-6時間	Tier 1(GAS通知)は即効。Tier 2(Claude Code)でMCP基盤と連携
16	MAS-155	Outlookメール自動取得	4-6時間	Drive手動アップロードを排除。写真添付もMAS-157で処理可能
17	MAS-181	銀行API連携	未定	銀行契約が前提。MAS-145のCSV取込で当面は十分
18	MAS-186	チャット経費精算	未定	Bot開発が必要。優先度低

技術詳細

各案件の実装詳細（ファイル配置・関数設計・API仕様）は docs/dev/ に別途作成する。

→ 開発手順: 自動入力パイプライン全体設計 (`docs/dev/dev_I-00_auto_import_pipeline.md` 作成予定)

🏢 3.3 SaaS化・事業展開（テナントセットアップ・ハードコード外出し）

GCP移行（Phase 5）前にGAS版で複数テナント運用するための改修・手順をまとめる。詳細な事業展開戦略は PRD: 事業展開戦略を参照。

テナントセットアップ手順（オンボーディング）

#	作業	担当	自動化可否
1	テンプレートスプレッドシートを複製	PO	スクリプト化可能
2	GASプロジェクトを新規作成 & clasp push	開発者	CI/CD化可能
3	スクリプトプロパティ設定（ENV, SPREADSHEET_ID, GEMINI_API_KEY, RECEIPT_FOLDER_ID）	開発者	セットアップスクリプト化可能
4	03_sys_params に会社固有パラメータ投入	PO + 顧客	テンプレートで半自動化
5	科目マスタ（11tab）の初期データ投入	PO + 顧客	業種別テンプレートで対応
6	取引先マスタ（12tab）の初期データ投入	顧客	手動（顧客固有データ）
7	setupAllSchemas 実行	開発者	手順 2 に統合可能
8	銀行アダプター設定（利用銀行の選択）	PO	マスタ化後はパラメータ設定のみ
9	動作確認テスト（テストランナー実行）	開発者	自動

ハードコード外出し改修一覧

現在コードにハードコードされているテナント固有値を、03_sys_params またはマスタシートに外出しする改修。

ID	対象	現在の場所	外出し先	優先度	概要
T-01	銀行アダプター (BANK_ADAPTERS)	`502_bank_importer.js` L6-50	新規マスタ `16_mst_bank_adapter` or 03_sys_params	★★★	銀行名・口座キー・CSVパース仕様がハードコード。顧客の利用銀行に合わせてアダプターを選択可能にする
T-02	CC加盟店辞書 (CC_MERCHANT_MAP)	`501_cc_importer.js`	12_mst_partner の「CC加盟店名」列 or 新規マスタ	★★★	カード会社の加盟店表記→取引先名の変換辞書。テナントごとに異なる
T-03	法人税ブラケット	`607_datamart_fs.js`	03_sys_params	★★	税率区分（〜800万/超）と税率のハードコード。将来の税制改正にも対応
T-04	決算期（会計年度開始月）	複数ファイル（4月始まり前提の箇所）	03_sys_params `CFG_FISCAL_YEAR_START`	★★★	現在4月始まり前提。3月決算・12月決算等に対応するには全集計ロジックの期間判定を可変にする必要あり
T-05	除外摘要パターン (EXCLUDE_MEMO_PATTERNS)	`502_bank_importer.js` L154	03_sys_params or マスタ	★	「ﾌｸｲｶｰﾄﾞ」等の除外パターン。銀行・カード構成がテナントごとに異なる
T-06	社保・源泉の控除科目名	`401_rpa_hc.js`	科目マスタ参照で動的化	★	科目マスタに登録必須のため影響小。テンプレートの科目セットで対応可能
T-07	テナント表示名・ロゴ	なし（新規）	03_sys_params `CFG_TENANT_NAME`	★	財務諸表ヘッダーやレポート出力に会社名を表示する場合に必要
T-08	ヘッダー名の定数化	全ファイル（`indexOf('列名')` 約300箇所）	定数マップ `H.WRK_BANK.ACCOUNT` 等	★	現在ヘッダー名を文字列で直接参照。定数マップ経由にすればヘッダー変更時の影響を局所化できる。ただし日本市場限定なら現状の日本語ヘッダーで問題なく、GCP移行（Phase 5）でDB化する際に自然と解決する領域。当面は現状維持（案C）で可

顧客ヒアリング項目（オンボーディング時に確認が必要な設定値）

テナントセットアップ時に顧客企業から聞き取る必要がある情報の一覧。営業・導入時のチェックリストとしても使用する。

#	カテゴリ	ヒアリング項目	設定先	必須	備考
1	基本情報	会社名（正式名称・略称）	03_sys_params `CFG_TENANT_NAME`	○	財務諸表ヘッダー等に表示
2	基本情報	決算期（会計年度開始月）	03_sys_params `CFG_FISCAL_YEAR_START`	○	例: 4（4月始まり）、1（1月始まり）
3	基本情報	課税事業者 or 免税事業者	03_sys_params	○	消費税処理の有無。免税なら税込一本
4	基本情報	顧問税理士の有無・利用SaaS	—	—	freee/MFとの棲み分け確認。記帳はどこでやるか
5	銀行	メインバンク名・支店・口座番号	T-01 銀行アダプター	○	CSV取込フォーマットの判定に必要
6	銀行	利用銀行の数（複数口座の有無）	T-01 銀行アダプター	○	アダプター追加開発の要否判断
7	カード	利用クレジットカード（会社名・ブランド）	T-02 CC辞書	△	カード明細CSVのフォーマット確認
8	人事	従業員数・役員数	22_bud_headcount	○	HC RPAのマスタデータ。立替精算者の特定にも使用
9	人事	給与計算SaaS（freee人事労務 / MF等）	—	—	MAS-158（給与SaaS取込）の対応要否
10	人事	立替精算の運用（誰が立て替えるか）	03_sys_params `CFG_REIMBURSEMENT_PAYEE`	△	1名なら現行パラメータ、複数名ならMAS-168対応要
11	経費	主なSaaS・サブスク契約の一覧	23_bud_subscription	○	初期マスタデータ投入用
12	経費	設備投資・借入の有無	24_bud_capex_loan	△	CAPEXなければ空でOK
13	売上	売上の計上方法（月額/スポット/請負）	21_bud_pipeline	○	MRR/スポット/完了基準の使い分け
14	売上	PJ管理の要否・PJ数	28_bud_allocation	△	PJ別損益が不要なら配賦設定スキップ
15	科目	業種（テンプレート選択用）	11_mst_account	○	コンサル/SaaS/小売/汎用から選択
16	科目	独自の勘定科目の有無	11_mst_account	△	テンプレートにない科目の追加要否
17	運用	月次決算のサイクル（何日締め？）	—	○	オンボーディング後の運用フロー設計に必要
18	運用	領収書の管理方法（紙/PDF/写真）	スクリプトプロパティ `RECEIPT_FOLDER_ID`	△	OCR取込（MAS-157）の設定要否

○: 必須（これがないとセットアップ不可） △: 該当する場合のみ —: ヒアリング用（設定作業なし）

科目マスタの業種別テンプレート

テナントオンボーディングの最大のハードルは科目マスタの初期設定。業種別テンプレートを用意することで顧客の初期設定負荷を軽減する。

テンプレート	対象業種	特徴
コンサルティング業（現行）	IT/経営コンサル、士業	人件費中心、PJ別原価管理、SaaS費用多め
SaaS事業者向け	自社SaaS開発・運営	ARR/MRR管理、サーバー費用、開発人件費の資産計上
小売・EC向け	物販、EC	売上原価（仕入）中心、在庫関連科目、配送費
汎用（最小構成）	業種不問	最小限の科目セットで開始、必要に応じて追加

推奨実装順序（ハードコード外出し）

順番	ID	理由
1	T-04	決算期が異なる顧客に対応できないと導入不可。最も影響範囲が広い
2	T-01	銀行が異なる顧客の銀行CSV取込に必須
3	T-02	カード会社が異なる顧客のCC消込に必須
4	T-03	法人税率の外出し。改修は小規模
5	T-07	テナント名表示。改修は小規模
6	T-05, T-06	影響小。テンプレートの初期値で当面対応可能
—	T-08	当面不要。GCP移行時に自然解決する領域

3.3.1 事業展開・フリート運用（GASのまま販売拡大する場合）

GCP移行（Phase 5）に進まず、GASテンプレート販売モデルで事業拡大する場合に必要となる事業企画・運用ツール群。MAS-237（マルチテナント）を採らずに「顧客ごとに独立したGAS+スプレッドシート」を配布・管理する前提。

ID	Type	Layer	案件名	カテゴリ	Phase	優先度	ステータス	完了日	概要	期待される効果 / 備考	人間が検討すべき事項
MAS-255	Story	🛠️ Ops	GASテンプレート販売モデルの事業企画	事業・戦略	P2	★★★	未着手	—	GCP本格SaaS化(MAS-236〜MAS-244)に先立ち、GASのまま顧客に配布する販売モデルを事業として成立させる企画。①価格設計: 初期セットアップ費(買切) + 年間ライセンス料(サブスク)のハイブリッドモデル。業種別テンプレート単位で価格差。②販売チャネル: 税理士法人・中小企業診断士・経営コンサルとの提携販売（マージン20-30%）、自社直販の併用。③差別化ポジショニング: 「Google Workspace Native」「顧客のDrive内にデータが残る（データ主権）」「freee/MFより高度なFP&A機能」。④顧客ターゲット: 従業員10-50名のBizFin成熟期のSMB。⑤収益シミュレーション: 顧客単価・CAC・Churn率・LTV の仮説から3年間の売上計画を策定。⑥Go/No-Go基準: 初期10社導入 × 顧客満足NPS50以上で GCP移行(Phase 5)に進む判定基準を設定。関連: §3.1 セキュリティ・プラットフォームカテゴリ内の MAS-246〜MAS-254 全体が本モデルの差別化要素として作用（「秘密計算×管理会計」の唯一性・「検証可能なデータ主権」の法務裏付け・プライバシーマーク等の信頼基盤）。	GCP移行の巨大投資前にマーケットフィットを検証。初期キャッシュフローで自走しながらプロダクトを磨く現実的な成長路線	ターゲット顧客の絞り込み（業種 / 規模 / 成長ステージ）。提携パートナー候補の選定。価格感度調査（3-5社ヒアリング）。GCP移行との意思決定基準の合意
MAS-256	Story	🛠️ Ops	顧客別GASインスタンス管理ツール（フリート管理）	運用ツール	P2	★★★	未着手	—	複数顧客のGASインスタンスを一元管理するダッシュボード。①テナント一覧: 顧客名・スプレッドシートURL・GASプロジェクトID・契約プラン・契約開始日・最終稼働日・利用バージョン。②稼働状況監視: 各テナントのログ収集（GASの実行ログを親スプレッドシートへ日次転送）、エラー発生検知。③バージョン管理: どの顧客がどのコードバージョンで稼働しているかの可視化。④技術選定: GASプロジェクト×N個を管理する親GASプロジェクト（管理側）を別途用意。clasp + GitHub Actions で一斉デプロイ。⑤サポート対応: 各テナントへのアクセス権を親管理者が持ち、障害時に顧客のGASを直接操作できる運用体制。	顧客数が10社を超えた時点で手動管理が破綻するのを防ぐ。MAS-257のパッチ展開・MAS-199同期ツール・MAS-201バックアップなど全ての運用基盤の前提	管理者が全顧客のデータへアクセスする権限設計（NDA・監査証跡の整備）。テナント情報の保存先（自社GAS / Notion / Airtable）。管理規模の上限（〜100社までGASで耐えられる想定）
MAS-257	Story	🔧 Infra	顧客環境への一斉パッチ展開機構	運用ツール	P2	★★	未着手	—	バグ修正や機能追加を全顧客のGASインスタンスに一斉配信する仕組み。①配信方式: GitHub Actions で全顧客の .clasp.json を順次読み込み → clasp push で自動デプロイ。認証は Service Account で一元化。②段階デプロイ: カナリアテナント（1-2社）→β（10%）→全体の3段階ロールアウト。③ロールバック: 問題発生時は前バージョンへ一括巻戻し。④差分通知: 顧客へ変更内容をメール通知。⑤テナント固有カスタマイズの保護: 顧客がスクリプト編集したケース（あってはいけないが）の差分検知。	10社以上を手動デプロイする運用負荷を排除。セキュリティパッチの即時展開が可能に	Service Account への顧客GAS編集権限付与の是非（顧客の同意取得）。カスタマイズされた顧客GASの扱い（上書き禁止ポリシーの明文化）。ロールバック時のデータ互換性
MAS-258	Story	🛠️ Ops	ライセンス認証・利用期限管理	運用ツール	P2	★★	未着手	—	購入した顧客のみがGASスクリプトを実行できる認証機構。①ライセンスキー: 顧客ごとに発行されるUUID。初回セットアップ時にスクリプトプロパティへ保存。②検証エンドポイント: 自社サーバー(Cloud Functions等)にライセンスキー検証APIを置き、主要機能実行時に軽量チェック。③オフラインモード: ネットワーク断時も72時間は稼働可能（直近の検証結果をキャッシュ）。④利用期限: 契約終了後はRead-only化（新規データ登録不可、閲覧は可能）。⑤不正対策: 同一キーの複数環境利用を検知。	解約後の無許可利用を防止。サブスクモデル成立の前提	ライセンス検証サーバーのホスティングコスト（GCPを使うなら実質MAS-236の先行投資）。オフライン猶予期間（72h以外）の設計。解約時のデータエクスポート保証
MAS-260	Story	🛠️ Ops	初期セットアップウィザード（過去データ自動シード）	運用ツール・オンボーディング	P2	★★★	未着手	—	新規顧客のオンボーディングを自動化する初期セットアップ機能。①基本データ・設定の入力: 顧客は会社情報・科目マスタ・取引先マスタ・組織マスタ・予算（21〜26番台）等の必要なマスタと `03_sys_params` の設定値を投入。②カットオーバー日の指定: 「いつから本システムで実運用するか」の年月日を指定（例: 2026-04-01）。③過去データの自動シード: 指定日までの過去データ（仕訳・INV・STL・CC明細・銀行明細等）を、既存マスタと整合する形で自動生成し、各タブに「手入力した状態」として書き込む。RPA で自動起票したものではなく、ユーザーが過去に手で入れたかのように見える状態を作る（自動仕訳JNL_ID 空・申請種別=`手入力(MAN)` 等）。④シード方式の選択肢: (a) freee/MFクラウドからのCSVインポート、(b) ユーザー提供のExcelテンプレートから一括投入、(c) 過去 N ヶ月の月次総額のみから按分生成（簡易モード）。⑤検証ダッシュボード: シード完了後、期初B/S・期中P/L・現預金残高が外部資料と一致するかを画面で確認・微修正できる UI。⑥ロールバック: 検証で不整合発覚時、「シード行（特定の摘要マーカー `[SEED:MAS-06]`）」を一括削除して再実行可能に。	新規顧客導入時のリードタイムを数週間→数時間に短縮。MAS-255（テンプレート販売モデル）の成立要件。手入力相当のデータが入った状態でシステムを引き渡せるため、初日から既存マートが正常に動作する	カットオーバー日の標準化（月初？期首？任意？）。過去どこまで遡って入れるか（直近1期 or 全期）。シード元データの形式仕様（freee/MF以外への対応）。検証ダッシュボードの粒度（科目別 or 月別）。シード後の自動マスタ生成（取引先マスタ等を実績から自動構築するか）。MAS-256（フリート管理）との連携でテナント作成と一括化できるか
MAS-259	Story	—	研究開発用データ収集・匿名化パイプライン（法務・事業設計版）	データ基盤・ガバナンス	P2	★★	未着手	—	顧客の同意を得た上で、プロダクト改善・AIモデル学習・業界ベンチマーク構築のためにテナントデータを収集する仕組み。①オプトイン同意: 利用規約とは別の「R&D同意書」で明示的な個別同意を取得（GDPR/個人情報保護法準拠）。同意は撤回可能。②匿名化パイプライン: 顧客名・取引先名・従業員氏名・口座番号・金額の絶対値等、識別可能な情報を除去または擬似化。擬似化は決定的ハッシュ（顧客ID+salt）で集計整合性を保つ。科目比率・業種別KPI・取引頻度分布など構造的特徴のみを保持。③収集方式: 各顧客GASから自社のGCPプロジェクト（R&D専用）へ日次で集計データを送信。生データは顧客側にのみ留める（集計結果のみ転送）。④利用目的の限定: ①AIモデル学習（MAS-146/MAS-157/MAS-191のOCR/NLPの精度向上）②業界ベンチマーク（MAS-028 SaaS KPI、MAS-014 PJ利益率の相場提示）③プロダクト改善（機能利用ログ分析）。営業・マーケ目的への転用禁止。⑤透明性: 収集項目・利用目的を一覧化したデータカタログを顧客に開示。Access Transparency ログで「自社が顧客データにいつ何をしたか」を顧客が確認可能。⑥削除保証: 解約時・同意撤回時に収集済みデータを30日以内に全消去（集計統計から当該顧客分を除外）。関連: 技術実装版は MAS-250 研究用匿名化データパイプライン（TEE + DP 組合せ）、法務条項テンプレは MAS-253 顧客契約書のデータ主権条項テンプレート整備。	差別化の源泉となる独自データセット構築。業界ベンチマーク機能（「御社の労働分配率は業界平均より15%高い」等）は他社が模倣困難。OCR/NLP精度向上が顧客体験の継続的改善に直結	同意書の法務チェック（外部弁護士レビュー推奨）。匿名化の粒度（業種別集計で k-匿名性 k=5 を担保できるか）。収集データの保存先（GCP R&D プロジェクトの独立運用）。顧客価値への還元方法（ベンチマーク機能の提供 or 対価減額）。インセンティブ設計（同意した顧客への割引・優遇）。MAS-179監査証跡との統合