MAS-057: Solo-CEO Financial Navigator アンブレラ（BRD 派生・MAS-056 / MAS-011 / MAS-013 / MAS-048 / MAS-141 統括）

概要

BRD docs/brd_solo_ceo_financial_navigator.md 派生案件（v1.2 で年収最適化スコープに転換・v1.4 でフロー × ストックのバランス最適化に再整理・v1.8 で UI を離散単位ドロップダウンに統一）。MAS-056 が提供する Chat ベース UX（対話で任意数シナリオを探索）を補完する「ドロップダウン + サンキーダイアグラム型のビジュアル財務コックピット」をアンブレラ仕様として定義し、1 人社長の「年収（月額報酬 × 12 + 賞与）の単純最大化 → 単年の手取り（フロー）と累積純資産（ストック）のバランス最適化」へのパラダイムシフトを実現する。両指標はトレードオフしうる（法人留保でストックを積めば今期手取りは減る）ため、システムは単一最大化ではなく両軸の同時可視化とユーザーによる最適点選択を中核価値とする。UI は連続スライダーではなく離散単位ドロップダウン（ai_agent_tips.md §7 準拠）で構成し、税務・社保等級境界との整合性を確保する。

MAS-056 は自然言語でシナリオを会話的に探索する意思決定ハブであり、MAS-057 は同じ計算エンジン（SocialInsuranceTierEngine.calcPremiums / calcBonusPremiums / PersonalTaxEngine 等）を年収ドロップダウン + 月額/賞与配分ドロップダウン + リアルタイム流出可視化という視覚優位の UX で再提供する第 2 レイヤーとなる（離散単位選択・ai_agent_tips.md §7 準拠）。商用化時は両者が「Chat タブ」「Visual Cockpit タブ」として共存する Web アプリとなり、BRD Vision の「財務のコックピット」を完成させる。

目的

• BRD 全体（Solo-CEO Financial Navigator）のエントリポイントとしてスコープ管理: MAS-056 / MAS-011 / MAS-013 / MAS-048 / MAS-141 の個別案件を「1 人社長の単年手取り（フロー）と累積純資産（ストック）のバランス最適化」という単一の経営課題に束ね、機能重複・抜け漏れを可視化する（v1.4 でフロー × ストックの 2 軸評価に再整理）。
• BRD §3.1「社会保険料の壁」ロジックの初期実装（年収の月額 × 賞与 2 軸最適化）: (a) 標準報酬月額等級表をマスタ化し厚生年金保険料の月額上限（標準報酬月額 65 万円等級・2026 年時点）突破戦略の損益分岐点を計算、(b) **賞与側の上限ロジック（厚年 1 回上限 150 万・健保年累計上限 573 万）**を calcBonusPremiums として並列実装し、「月額を抑えて賞与に振る逆方向最適化」の効果を定量化する。年収を固定した配分最適化と年収そのものの最適化を等価に扱う。MAS-056 の calculateOptimalCompensation() からも呼び出せる共通コアエンジンとして設計する。
• BRD §3.2「法人 vs 個人税率のデッドヒート」可視化: Constants.TAX_RATES.brackets（法人税）と Constants.INCOME_TAX_BRACKETS（個人所得税・本案件で新設）を対比し、年収の交点（デッドヒート分岐点）を UI 上で強調表示する。税制改正時の更新箇所を 002_constants.js 一元化（Gemini レビュー v1.1 反映）。
• BRD §4.3 生活最適化パラメータの追加: 社宅家賃（賃貸料相当額ベース按分）、出張日当（規程テンプレベース非課税枠計算）、共済（小規模企業共済 + 経営セーフティ共済、MAS-141 ロジックを参照）を主要 3 ドロップダウン（離散単位選択・ai_agent_tips.md §7 準拠）として実装する。
• BRD §6 UX 戦略「2 段ドロップダウン + サンキー + インサイト」の具体化（v1.8 でスライダー全廃に統一・ai_agent_tips.md §7 準拠）: 年収ドロップダウン（50-100 万円単位）+ 月額/賞与配分ドロップダウン（月額 5 万円単位で標準報酬月額等級境界と整合・賞与 50 万円単位）の 2 段構成。パラメータ変更（onChange）と同時に手残り推移がリアルタイム反映される UI（クライアントサイド計算で即時応答・google.script.run 通信レイテンシ排除）。年収 → 所得税/住民税/健保/厚年（賞与分・月額分）/法人税 → 手残りの流出をサンキーダイアグラムで可視化（厚年賞与 1 回上限突破部分は「社保ゼロ流入」として色分け）。callClaudeApiOnVertex_() または callGeminiForReasoningOnVertex_() でインサイト「年収 600 万のうち月額 30 万 × 12 + 賞与 240 万に再配分すると、厚年賞与上限突破で社保が年 N 万円減り、手残りが X 万円増加」を自動生成する。
• 齋藤 Baseline（BRD §8・v1.2 更新）の手残り最大化ポイントを数値証明: 年商 1,680 万 / 原価 0 / 固定費 240 万 / **年収 600 万（月額 50 万 × 12 + 賞与 0）**を起点に、(1) **年収 600 万固定 × 配分 4 パターン（A: 全額月額 / B: 夏冬賞与各 60 万 / C: 賞与 240 万 × 1 回 / D: 賞与 150 万 × 2 回）**の社保総額逆転点、(2) 年収を 300 万〜1,000 万で上下させた場合のデッドヒート分岐点、の 2 軸で合算純資産の最大値を特定する。

現在のコード

既存の財務計算エンジン（MAS-057 から Tool Use で横断呼び出し）

400_domain/ の採番状況（2026-04-24 時点・grep 確認）

実装済ファイル: 400_rpa_common / 401-406_rpa_* / 407_rpa_orchestrator / 410_subledger_engine / 412_hiring_tco_simulator / 413_invoice_matcher / 414_wage_tax_credit_simulator / 420_project_profitability / 430_what_if_simulator / 431_investment_analyzer。

MAS-056 用の 440_conversational_ui.js / 441_compensation_optimizer.js は仕様書に記載されているが実装未着手（ディレクトリに存在しない）。MAS-057 は 442/443/444 台を新規カテゴリとして確保する。

参照する既存 API（コアコード実在関数のみ・failure_patterns #18-#20 遵守）

参考にする既存 Repository 構造（対称実装の手本・failure_patterns #25）

AccountRepository（200_data/202_repository.js:304）/ PartnerRepository（同:356）/ PositionTemplateRepository（同:433）/ HurdleRateRepository（同:505）が読み取り専用マスタの共通構造を持つ:

var XxxRepository = {
  _getSheet: function() { return Utils.getSheetByKey('SYS_KEY', 'fallback_sheet_name'); },
  findAll: function() { return readSheetAsDtos_(XxxRepository._getSheet()); },
  findAsMap: function() { /* 有効フラグ FALSE 除外 + 重複ID は先着採用 + Utils.persistLog('WARN', ...) */ },
  _cache: null,
  resetCache: function() { XxxRepository._cache = null; },
};

MAS-057 で新設する 3 Repository（SocialInsuranceTierRepository / IncomeTaxBracketRepository / PerDiemPolicyRepository）はこの 5 要素を完全対称に配置する。

appsscript.json OAuth スコープの現状（failure_patterns #26 予防）

確認済（2026-04-24）: 既存 oauthScopes に https://www.googleapis.com/auth/cloud-platform（Vertex AI 用）が含まれている。MAS-057 での追記は不要。oauthScopes への部分追記は「既存スコープの自動検出が完全オフ」となるため、本案件で appsscript.json を編集しない方針を注意事項に明記する。

MENU_DEFINITION カテゴリの現状

000_infra/002_constants.js:206 の MENU_DEFINITION に存在するカテゴリ: 🚀 BizLP / 💾 バックアップ / 📋 サイドバー: 📊 マート更新 / 📋 サイドバー: 🔧 開発・設定 / 📋 サイドバー: 📒 経理業務 (RPA / Action) / 📋 サイドバー: 🔍 消込・マッチング / 📋 サイドバー: 📝 費用登録 / 📋 サイドバー: ⚙️ メンテナンス / 📋 サイドバー: 🔧 マイグレーション / 📋 サイドバー: 🔄 開発用 (dev) / 📋 サイドバー: 🧪 テスト。

MAS-057 用の新規カテゴリ追加は MAS-056 が先行して追加予定の 🧭 意思決定対話（Web App） に相乗りし、コックピット URL コピー項目を同カテゴリに追加する方針とする（MAS-056 仕様書 PR #350 で規定済）。

修正方針

Phase 1 — 社会保険料壁エンジン + 等級マスタ（約 1.0 ヶ月・週 10h 前提）

ゴール: 400_domain/442_social_insurance_tier_engine.js が単体で動作し、月額報酬 → 標準報酬月額等級 → 健保料・厚年保険料を算出できること。本 Phase は MAS-056 実装状態に依存せず独立完成（v1.1 Major 3 反映・依存方向反転）。MAS-056 が後から実装される際に、MAS-056 側から SocialInsuranceTierEngine.calcPremiums() 等を呼び出す形とする。

1. 100_config/101_sys_config.js 拡張:

   • confSheet.appendRow(['MST_SOCI', '', '17_mst_soci_tier', 'マスタ_社会保険標準報酬月額等級表 (F-57 壁エンジン)']) を追加。
   • schemas['MST_SOCI'] = { headers: ["有効フラグ","等級","標準報酬月額下限","標準報酬月額上限","健保料率","厚年料率","介護保険料率","子ども子育て支援金率","適用開始年月","備考"], color: "#666666", validations: { ... } }。v1.7 Minor 反映: 適用開始年月列に { type: 'regex', pattern: '^20[2-3]\\d-(0[1-9]|1[0-2])$', helpText: 'YYYY-MM 形式で入力してください（例: 2026-03）' } のバリデーションを追加し、「2026/03」「R8-3」等のブレを防止。
   • DDL 実行後の初期データ投入スクリプトは 800_ops/ 配下に 812_migration_f57_tier_seed.js として新設（migrationF57TierSeed() 関数・マイグレーション運用ガイドライン準拠・冪等性必須）。日本年金機構 2026 年 3 月分〜の料率表（全国一律・健保 50 等級 + 厚年 32 等級）を投入する。出張日当規程テンプレは Phase 2 で別関数 migrationF57PerDiemSeed() として追加する。

2. 000_infra/002_constants.js に INCOME_TAX_BRACKETS 定数追加（v1.1 Critical 2 反映・法人税 TAX_RATES.brackets と対称な一元管理）:

   /**
    * 個人所得税 累進課税ブラケット (2026 年時点・総合課税)
    * brackets: 課税所得の低い方から順にマッチ
    * rate: 税率 / deduction: 控除額（速算表）
    * 毎年 3 月税制改正後に本定数を直接編集して更新する。
    */
   INCOME_TAX_BRACKETS: {
     brackets: [
       { upTo: 1950000,  rate: 0.05, deduction: 0 },
       { upTo: 3300000,  rate: 0.10, deduction: 97500 },
       { upTo: 6950000,  rate: 0.20, deduction: 427500 },
       { upTo: 9000000,  rate: 0.23, deduction: 636000 },
       { upTo: 18000000, rate: 0.33, deduction: 1536000 },
       { upTo: 40000000, rate: 0.40, deduction: 2796000 },
       { upTo: Infinity, rate: 0.45, deduction: 4796000 },
     ],
     residentTaxRate: 0.10,  // 住民税（都道府県民税 + 市町村民税 合算）
     applicableFrom: '2026-01-01',
   },
   

3. 200_data/202_repository.js に Repository 追加:

   • SocialInsuranceTierRepository を HurdleRateRepository の直後に追加。_getSheet('MST_SOCI', '17_mst_soci_tier') / findAll() / findAsMap()（キー = 等級コード・重複先着・有効フラグ FALSE 除外・Utils.persistLog('WARN', ...) で警告）/ _cache / resetCache()。
   • 個人所得税用の Repository は新設しない（v1.1 Critical 2 反映）。呼び出し元は Constants.INCOME_TAX_BRACKETS.brackets を直接参照する。

4. 400_domain/442_social_insurance_tier_engine.js 新設（v1.2 賞与 API 追加 + v1.3 Pure Function 厳格化）:

   • SocialInsuranceTierEngine = { findTier, calcPremiums, calcBonusPremiums, calcBreakEvenPoint, ... } の構造で実装。
   • 完全な純粋関数（v1.3 Critical 反映・Pure Function 厳格化）:
     • SpreadsheetApp / UrlFetchApp への依存なし
     • Utils / Constants への依存も排除: Utils.parseAmt / Utils.persistLog / Constants.getParam を関数内で直接呼ばず、呼び出し元（Repository または UI 層）がパース済みの値と料率（healthRate / pensionRate など）を引数として渡す
     • この「完全な依存排除」により、GAS 環境 / ブラウザ環境 / Jest テスト環境で同じ .js ファイルを一切の変更なしに使い回せる（v1.3 Critical 反映・単一ソース共有）
     • ログ出力が必要な場合は、戻り値に warnings: [{ level, message }] 配列を含めて呼び出し元で Utils.persistLog を呼ぶ
   • findTier(monthlyCompensation, tierMap, targetYm): 月額報酬額と対象年月（"YYYY-MM"）から、該当期間に適用される等級を返す（v1.3 Minor 反映・targetYm で適用開始年月と突合）。最大等級超過時は最大等級に丸め、戻り値に { ..., isOverCap: true, warnings: [...] }。
   • calcPremiums(tier, { isOver40, healthRate, pensionRate, nursingCareRate, childcareLevyRate, targetYm }): 月額報酬に対する健保料 + 厚年 + 介護（40 歳以上のみ）+ 子ども子育て支援金を算出。料率は引数で注入（Constants.getParam 直接呼ばない）。targetYm で tier の「適用開始年月」との整合確認。
   • calcBonusPremiums(bonusAmount, tierMap, options) 実装済（v1.2 計画 → v1.6 で Phase 2 から Phase 1.5 に前倒し実装完了 PR #356・実装実態を反映）:
     • options = { isOver40, accumulatedBonusThisFiscalYear, singleBonusCapPension, yearlyBonusCapHealth }（実装シグネチャに準拠）
     • 料率は tierMap 内の等級レコードから _extractUniformRates_ で抽出（厚年料率 > 0 の等級を優先採用・全等級統一前提）。v1.3 で計画していた「料率の直接引数注入」は実装で tierMap 経由に統合されたが、クライアント側でも tierMap を bootstrap 配信して渡せば等価に機能する（Pure Function 性は保持）。targetYm は実装で省略（tierMap が既に適用期間でフィルタ済前提）
     • 標準賞与額: Math.floor(bonusAmount / 1000) * 1000（千円未満切り捨て）を内部で適用
     • 厚年 1 回上限: Math.min(standardBonus, singleBonusCapPension) で丸めた額に厚年料率適用。デフォルト singleBonusCapPension = 1_500_000（DEFAULT_BONUS_PENSION_CAP_SINGLE 定数・03_sys_params の F57_BONUS_PENSION_CAP_SINGLE から注入）
     • 健保年累計上限: yearlyCapHealth - accumulated の残枠まで健保対象、超過部分は健保・介護対象外。デフォルト yearlyBonusCapHealth = 5_730_000（DEFAULT_BONUS_HEALTH_CAP_YEARLY 定数・03_sys_params の F57_BONUS_HEALTH_CAP_YEARLY から注入）
     • 子ども子育て拠出金: 厚年ベース（pensionBase に料率適用）のため 1 回上限に従う
     • 戻り値（実装確定値）: { standardBonus, healthPremium, pensionPremium, carePremium, childcareLevy, total, pensionBase, healthBase, newAccumulatedHealthBase, isPensionCapped, isHealthYearlyCapped }
       • v1.3 計画の isOverPensionCap / isOverHealthCap は実装で isPensionCapped / isHealthYearlyCapped にリネーム（受動態で状態を表現）
       • newAccumulatedHealthBase は実装で追加: 呼び出し元は次回賞与呼び出し時に accumulatedBonusThisFiscalYear として渡して反復呼び出し
       • total は実装で追加: 健保 + 厚年 + 介護 + 子育て の合算
     • 単体テスト 18 件（F57-22 〜 F57-39・901_test_runner.js）で精度担保: 通常賞与 / 介護 40 歳以上 / 千円未満切り捨て / 厚年 1 回上限突破 / 健保年累計上限突破 / 夏冬反復呼び出し / ゼロ・負値
   • calcBreakEvenPoint({ annualRevenue, fixedCost, annualIncome, monthlyAllocationRatio, targetYm, ... }): 年収固定 × 配分最適化の BEP を計算。厚年賞与 1 回上限突破効果を含めた合算社保最小化ポイントを返す。月額上限突破 BEP も従来通り返す。

   PersonalTaxEngine の税法上必須の端数処理（v1.7 Major 反映・Gemini 指摘）:

   • 課税所得の端数処理: 所得計算時に Math.floor(taxableIncome / 1000) * 1000（1,000 円未満切り捨て）を適用してからブラケット判定・税率乗算を行う。
   • 最終算出税額の端数処理: 所得税額の計算結果に Math.floor(incomeTax / 100) * 100（100 円未満切り捨て）を適用。住民税も同様（100 円未満切り捨ての慣行）。
   • この 2 段階の切り捨ては国税通則法・地方税法に基づく税額計算の実務慣行であり、シミュレータの手残り計算を実額（源泉徴収票・確定申告書の数値）と一致させるために必須。端数処理なしでは数百〜数千円単位の誤差が生じ、ユーザーの実データとの整合検証が取れなくなる。
   • 単体テストケースとして「課税所得 3,300,999 円 → 切り捨て後 3,300,000 円 → 税額計算 → 最終税額の 100 円未満切り捨て」を必ず含める。

5. 900_test/901_test_runner.js にテストケース追加:

   • 齋藤 Baseline（月収 50 万）→ 等級判定 + 健保・厚年保険料計算の手計算値と ±1 万円以内一致。
   • 境界値: 等級下限ジャスト / 等級上限ジャスト / 上限超過 / 下限未満。

Phase 2 — 社宅・日当・共済統合 + MAS-056 対話 UI 拡張（約 1.0 ヶ月）

ゴール: BRD §4.3 の 3 パラメータ（社宅家賃負担率・出張日当・共済積立額）が Phase 1 エンジンと合算され、MAS-056 の calculateOptimalCompensation() が役員報酬最適化時にこれらを考慮できるようになる。

1. 13_tmpl_per_diem_policy DDL 追加:

   • schemas['TMPL_PDIEM'] = { headers: ["有効フラグ","規程ID","規程名","出張区分","宿泊有無","日当単価","交通費上限","適用開始年月","備考"], ... }。
   • confSheet.appendRow(['TMPL_PDIEM', '', '13_tmpl_per_diem_policy', 'テンプレ_出張日当規程 (F-57)'])。
   • 初期データ投入は 800_ops/812_migration_f57_tier_seed.js に migrationF57PerDiemSeed() 関数として追加（冪等性必須）。

2. PerDiemPolicyRepository を 200_data/202_repository.js に追加: PositionTemplateRepository と完全対称の 5 要素構造。

3. 400_domain/443_corporate_housing_optimizer.js 新設:

   • CorporateHousingOptimizer = { calcRentAllocation({ totalRent, taxableRentEquivalent, employeeShareRate }) } で税務上の賃貸料相当額 vs 実際家賃 vs 従業員負担割合から個人⇔法人の移転額を算出。
   • 賃貸料相当額の計算は 2 方式（固定資産税評価額ベース正式法 / 簡便法 50%）をパラメータ化し、F57_HOUSING_CALC_METHOD キー（デフォルト SIMPLE_50）で切り替え可能とする。
   • 純粋関数のみ。

4. 400_domain/444_per_diem_policy_engine.js 新設:

   • PerDiemPolicyEngine = { calcMonthlyAllowance({ policyMap, businessTripCount, includeAccommodation }) } で非課税日当総額を算出。
   • PerDiemPolicyRepository.findAsMap() を外部から渡して依存性注入する。純粋関数。

5. MAS-056 統合の検証:

   • MAS-056 実装が完了している場合のみ、440_conversational_ui.js の calculateOptimalCompensation() が本 Phase 1 エンジンを参照するよう組み込む。
   • MAS-056 未実装時は MAS-057 エンジンを単体で動作させ、MAS-056 実装時に統合する方針を「人間が検討すべき事項」に明記する。

Phase 3 — ドロップダウン + サンキー UI + インサイト + 5 カ年推移統合（約 1.0 ヶ月・クライアントサイド計算設計・ai_agent_tips.md §7 準拠）

ゴール: templates/financial_cockpit.html が Web アプリとして動作し、主要 3 ドロップダウン（役員報酬・社宅負担率・共済積立額）の onChange 操作で合算手残り推移がリアルタイム反映、サンキーダイアグラムで流出可視化、AI インサイトが明示的トリガーで更新される。

🔴 v1.1 Critical 1 維持（v1.8 でドロップダウン化に統一）: GAS の google.script.run 通信レイテンシ（1〜3 秒）とリアルタイム UX は根本的に非互換のため、シミュレーション計算はクライアントサイド JS で実行し、GAS 側 API は初期ロード時のマスタ配信 + AI インサイト生成（重処理）のみに限定する設計を維持。v1.8 で UI を連続スライダーから離散単位ドロップダウンに変更したが、レイテンシ排除の方針は引き続き有効（ドロップダウン onChange でも同等の即応性を担保）。

1. クライアントサイド計算エンジン（v1.3 Critical 反映・単一ソース共有に変更）:

   • GAS 側と同一の .js ファイルをクライアントでも直接読み込む方式に変更（v1.2 で想定した「TypeScript として複製」「バンドル時に定数埋め込み」は撤回・DRY 違反回避）
   • 400_domain/442_social_insurance_tier_engine.js / 443_corporate_housing_optimizer.js / 444_per_diem_policy_engine.js を 依存のない Pure JS（ES Modules または UMD 互換） で書く（Phase 1/2 で既に Pure Function 化済）
   • Vite のビルド設定で ../../400_domain/442_*.js から直接 import（または vite-plugin-file-copy 等で同一ソースをコピー）してバンドル。GAS 側更新時にクライアント側ビルドも自動で最新版に追従する
   • マスタデータと料率はすべて action=F57_BOOTSTRAP で配信（v1.3 Major 反映・バンドル埋め込みは廃止）: 17_mst_soci_tier 全件（82 行・約 8KB） / 13_tmpl_per_diem_policy 全件 / Constants.INCOME_TAX_BRACKETS.brackets / Constants.TAX_RATES.brackets / F56_FUKUI_* 料率キー / F57_* パラメータキー（F57_BONUS_PENSION_CAP_SINGLE / F57_BONUS_HEALTH_CAP_YEARLY 等）。合計 20KB 以内。GAS 側で定数更新時にクライアント再ビルド不要
   • ドロップダウン onChange は純粋にブラウザ内で再計算（GAS へのラウンドトリップなし）。応答時間 < 50ms（離散選択の即時反映で十分・スライダー時代の 60fps 要件は不要）を実現

2. GAS 側 doGet(e) のマスタ配信 API:

   • F57_BOOTSTRAP アクション: ?action=bootstrap で上記 JSON 一式を返す。レスポンスに ETag を含め、クライアントは localStorage + 有効期限 1 時間でキャッシュ。
   • F57_INSIGHT アクション: ?action=insight&payload=... で役員報酬 + 現在試算値を受け取り callClaudeApiOnVertex_ で 1 インサイト生成。同期応答（Phase 3 時点で MAS-056 のポーリング基盤を流用するか、シンプル同期で 5 秒以内応答を保証するか判断）。

3. 5 カ年推移への連動:

   • 5 カ年計算はロジックが大きいため、MAS-011 WhatIfSimulator.run() はサーバーサイド維持。ドロップダウン選択が確定（onChange から 2 秒間追加変更なし）したタイミングで 1 回だけ google.script.run.withSuccessHandler(...).runFiveYearForF57(params) を呼び出し、法人内部留保の運用益（F57_INVESTMENT_YIELD）と共済積立の所得控除複利を含めた 5 カ年推移を取得する。
   • 折れ線グラフ + 積み上げ棒グラフで可視化。描画は Chart.js or D3.js。

4. AI インサイト提示のトリガー変更（v1.1 Major 4 反映）:

   • debounce 500ms による連続呼び出しは廃止（Vertex AI クオータ枯渇 + コスト高騰リスク）。
   • 発火条件を以下 2 択から F57_INSIGHT_TRIGGER_MODE で切替:
     • ONCHANGE_2SEC（デフォルト・v1.8 でドロップダウン化に伴い ONMOUSEUP_2SEC から改名）: ドロップダウン onChange イベント発火後、さらに 2 秒間追加の選択変更がない場合のみ AI 呼び出し
     • EXPLICIT_BUTTON: 「💡 インサイトを更新」ボタンのクリックでのみ AI 呼び出し（コスト最重視）
   • UI に「最終更新: HH:MM」を表示し、現在値と AI 応答時点の差分をユーザーが認識できるようにする。

5. サンキーダイアグラム + 2 段ドロップダウン入力 UI（v1.8 でスライダー全廃に統一・v1.9 で位置付けを「概観タブ」に再定義・ai_agent_tips.md §7 準拠）:

   • v1.9 で UI 構造を 2 階層化: サンキーダイアグラムは「概観タブ」として補助的に残し、主要表示は新設 Step 6 の 3 区分テーブル（個人 / 法人 / 合計）に変更。サンキーは数値精度と改善示唆性が弱いため経営判断には Step 6 を優先利用する。
   • サンキーダイアグラムライブラリは D3.js sankey-diagram / Plotly sankey / Chart.js sankey 拡張から選定（「人間が検討すべき事項」参照）。サンキーダイアグラム自体は離散値の流量可視化用途として維持（スライダーと別概念・ai_agent_tips.md §7 明記）。
   • F57_INCOME_INPUT_MODE モード:
     • DROPDOWN_DISCRETE（デフォルト・v1.8 で確定・推奨）: 1 段目 = 年収ドロップダウン（300 万〜1,500 万・50-100 万円単位の <select>）、2 段目 = 月額ドロップダウン（5 万円単位で標準報酬月額等級境界と整合）+ 賞与ドロップダウン（50 万円単位）。onChange 毎に 1 回の純粋 JS 再計算 → SVG 再描画。±ボタン併用可。
     • SLIDER（廃止予定・互換用のみ残置・v1.8 以降の新規実装非推奨）: v1.0-v1.7 で採用していた連続スライダー UI。ai_agent_tips.md §7 廃止理由（パフォーマンス / GAS クォータ / 離散単位の意思決定整合性 / 等級境界整合）により本モードは新規採用しない。既存実装が残っている場合の互換用にのみ存置（テスト網羅対象外）。
   • 賞与上限突破のビジュアル表示: サンキーダイアグラムで「厚年賞与 1 回上限 150 万を超える部分」を別色（緑）で描画し「社保ゼロ流入」として明示。健保年累計上限 573 万突破時も同様。
   • 計算トリガー分離: onChange = クライアントサイド計算 / onChange + 2sec or 明示ボタン = 5 カ年サーバー計算 + AI インサイト呼び出し。

6. 個人 / 法人 / 合計 の 3 区分テーブル UI + 大型機能群（v1.9 で 3 区分テーブル新設 → v2.1 で Step 6.1〜6.15 に細分化・PR #394 実装完了）:

   v1.9 では「Step 6 = 個人/法人/合計の 3 区分テーブル UI」のみが設計されていたが、main 側 PR #394 で 33 コミットにわたりspec 未記載機能を 15 項目以上追加実装。経営者ユーザー指摘「サンキーは直感的だが数字としてわかりづらい・改善するための情報には利用しにくい」をベースに、Y1-Y5 単年タブ・累積セクション・実効税率併記・生命保険料・社長稼働限界メーター・純資産 3 用途分解・創業費・シナリオ保存・月単位入力・変動費比率・住宅ローン減税 等を Step 6.1〜6.15 として体系化。Gemini Deep Think (MAS-334) で発見された複数の独自機能 (社長稼働限界・最低月額制約等) も先行実装（注意事項 #19 参照）。

   Step 6.1: 3 区分テーブル基本構造（v1.9 設計を踏襲・実装で詳細展開を 7 行に拡張）

   • 「誰が負担するか」軸でグループ化（個人 / 法人を主軸・MAS-057 BRD のデッドヒート分析と整合）
   • 4 グループ × 3 列構造: 収入 / 👤 個人負担合計 / 🏢 法人負担合計 / 🔄 法人→個人移転 / 💰 手取り（フロー）/ 🏦 純資産（ストック）
   • 2 階層展開構造: デフォルトはサマリー行のみ、各グループ右端の [▼] クリックで詳細展開
     • 個人負担合計: 4 行展開（所得税 / 住民税 / 健保本人 / 厚年本人）
     • 法人負担合計: 4-5 行展開（法人社保 / 固定費 / 経費（変動費・cogsRate ベース） / 創業費（初年度のみ） / 法人税）— v2.1 で経費・変動費・創業費を追加して 3 行 → 4-5 行に拡張
   • 数値精度: 万円単位 1 桁まで表示（例: 113.5 万）。大値は整数表示（例: 1,680 万）
   • 色分け: ▲ 赤（負担）/ + 緑（収入・移転）/ % 青（税率）
   • サンキーは「概観タブ」として <details> で折りたたみ補助化（v1.9 では並列表示だったが、v2.1 で主要 UI を 3 区分テーブルに完全シフト）

   Step 6.2: Y1-Y5 単年タブ（v1.9 にない・v2.1 新設）

   3 区分テーブルに Y1/Y2/Y3/Y4/Y5 のラジオタブを追加し、各年単独の収入・負担合計・手取り・実効税率を表示。

   • Y1: isFirstYear フラグに従う（短縮月数 + 創業費を一時費用として加算）
   • Y2-Y5: 通年 12 ヶ月 + 月額報酬の年次増加額を Y_n offset で適用
   • 純資産表示: 単年純増分（流動 + 老後 + 万一）を表示
   • 5 年分の result 配列は yearResults useMemo で一括生成

   Step 6.3: Y1-Y5 累積セクション（v1.9 にない・v2.1 新設）

   3 区分テーブルの下に独立セクションを追加し、Y1/Y2/Y3/Y4/~Y5 タブで累積期間選択。

   • 累積純資産: 流動 + 老後 + 万一 + 法人期首預金残高加算（Step 6.14）
   • 累積負担金額: 税 + 社保
   • 平均実効税率（税理士定義）: 期間内の (税/利益) の年次平均
   • 平均実効負担率（社保込み売上比）: 期間内の (税+社保/売上) の年次平均
   • 節税金額: vs baseline（参考値・住宅ローン減税を含めない baseline と比較）
   • 個人列の注記: 個人列は実質「累積手取り（+ 個人保険料払込）」の旨を注記表示（純資産概念との混同防止）

   Step 6.4: 実効税率（税理士定義）と実効負担率（社保込み売上比）の併記（v1.9 にない・v2.1 新設）

   経営者・税理士両方の語彙でアクセス可能にするため両指標を併記。

   • 実効税率（税/利益・国際標準 ETR）:
     • 個人 = (所得税 + 住民税) / 課税所得
     • 法人 = 法人税 / 税引前利益
   • 実効負担率（税 + 社保 / 売上）:
     • 個人 = (個人税 + 個人社保) / 役員報酬
     • 法人 = (法人税 + 法人社保) / 売上
     • 合計 = 全税社保 / 売上

   Step 6.5: 生命保険料 + 損金算入率（v1.9 にない・v2.1 新設）

   • 個人生命保険料 年額入力: 新制度・段階式所得控除（上限 4 万円）
   • 法人契約生命保険料 年額入力
   • 法人保険損金算入率: 4 段階ドロップダウン（法人税基本通達 9-3-5・2019/7 改正準拠）
     • 100%（掛捨て型）
     • 60%（低中返戻率）
     • 40%（高返戻率）
     • 0%（全額資産計上）
   • 資産計上分は累積純資産（法人）の「老後の備え」用途に分類（Step 6.7）

   Step 6.6: 社長稼働限界（Burnout）メーター（Gemini Deep Think 発見 #4・先行実装・v1.9 にない・v2.1 新設）

   ナレッジワーカー型 1 人社長の物理破綻ゾーンを可視化（MAS-334 Section MAS-239 の発見を MAS-067 着手前に MAS-057 で先行実装）。

   • 入力: 代表取締役 月額単価 + 売上貢献稼働率
   • 想定貢献年商 = 月額単価 × 稼働月数 × 売上貢献率
   • 実効稼働率 = 実売上 / 想定貢献年商
   • 100% 超で WARN 警告（ガードレールバナー）— 物理破綻ゾーン
   • 単価を上げずに売上 2 倍の計画を入力した瞬間に🔴警告

   Step 6.7: 純資産 3 用途分解（v1.9 にない・v2.1 新設）

   純資産行を expandable 化し、▶ で 3 用途を展開。

   • 💵 流動資産（いま使えるお金）: 個人手取り + 法人現預金 - 法人保険資産計上分
   • 🏛️ 老後の備え（退職金原資）: 共済 + 法人保険資産計上分
   • 🛡️ 万一の備え（保険給付想定）: 個人/法人保険料の払込累計（実給付額は商品で異なる旨注記・注意事項 #20）

   Step 6.8: 創業費 + 初年度フラグ + 月数按分（v1.9 にない・v2.1 新設）

   • 初年度フラグ ON で N ヶ月稼働（1-12）を月数按分
   • 創業費（前提条件・default 100 万）: 初年度のみ一時費用として加算
   • 繰延資産だが本実装は全額一括損金算入の簡易扱い（将来改修候補・注意事項 #20）
   • 単年テーブル Y1 と Y2-Y5 で計算を分岐（firstYearResult / annualResult）
   • Y1 月数 0 入力時は Math.max(1, ...) で 1 にクランプ（エッジケース #26）

   Step 6.9: シナリオ・前提条件プリセット保存・呼出（v1.9 にない・v2.1 新設・v2.2 で前回選択自動復元追加 (PR #400)）

   localStorage ベースで保存（個人デバイスに閉じる・チーム共有は v2 候補）。

   • ScenarioStore（Variables のみ）: localStorage キー f57_cockpit_scenarios_v1
   • AssumptionsStore（前提条件 16 項目）: localStorage キー f57_cockpit_assumptions_v1
   • 旧スキーマ migration: revenueAnnual → revenueMonthly (/12) 等を _migrateInputs / _migrateAssumptions で自動変換（エッジケース #22）
   • シナリオ呼出時は前提条件を維持（Variables のみ上書き）— 「前提 × シナリオ」のマトリクス試算が可能に（エッジケース #23）
   • 【v2.2 追加・PR #400】Variables 自動復元: 前回選択シナリオ・プリセットを起動時に自動ロード
     • f57_cockpit_last_selected_scenario_v1: 最後に選択したシナリオ名（ScenarioBar.tsx 担当）
     • f57_cockpit_last_selected_assumption_v1: 最後に選択した前提条件プリセット名（AssumptionsBar.tsx 担当）
     • 起動時に該当キーを読み、対応するシナリオ・プリセットがまだ存在すれば自動的に呼び出す
     • cockpit を一度閉じても 「前提 × シナリオ」マトリクス試算の継続性 を担保

   Step 6.9-extension: 健全性診断機能（MAS-058 統合・v2.2 新設・PR #400）

   MAS-058 「シナリオ健全性診断パネル」が cockpit に統合（詳細は MAS-058 spec v2.0 参照）:

   • 配置: 「累積純資産 + 平均実効負担率」セクションの直下（現状把握↑ vs 目標逆算↓ の境界）
   • 6 制約 × Y1-Y5 期末 matrix: 黒字 / 営業利益率 / 留保率 / 労働分配率 / ランウェイ / 緊急予備金
   • ヘルシーを保てる年間投資余力テーブル: 期末残高で 6 制約を維持できる最大の追加支出を binary search
   • 適用開始年タブ: Y1 から / Y2 から (default) / Y3 から / Y4 から / Y5 から で部分適用
   • 副機能: 必要年商の逆算（折りたたみ）+ キャパシティ ギャップ分析（単価 × 稼働率 vs 必要年商・100% 超で警告）

   MAS-057 cockpit の配置原則: 現状把握 vs 目標逆算 の境界

   v2.2 で MAS-058 panel を「累積純資産 + 平均実効負担率」セクション直下に配置することを確定。設計原則: cockpit を上から下に「現状把握 → 目標逆算」の流れとして構成し、3 区分テーブル + 累積純資産 + 平均実効負担率 までが「現状把握」レイヤー、MAS-058 健全性診断パネル以降を「目標逆算」レイヤーとする概念分離。今後追加される MAS-066（配当ミックス）/ MAS-067（マルチイヤー計画）等の cockpit 拡張機能は、この境界線に従って配置を決める運用ルール。

   Step 6.10: 前提条件 / 入力 セクション分離（v1.9 にない・v2.1 新設）

   ユーザーが頻繁に動かす変数と、業種・モデル選定で半固定の前提条件を視覚的に分離。

   • 「⚙️ 前提条件」セクション（頻繁に変えない・16 項目）: 黄系背景 + プリセットバー（AssumptionsPanel.tsx）
   • 「📊 入力」セクション（頻繁に動かす Variables・7 項目）: 灰系背景 + シナリオバー（CompensationDropdowns.tsx + ScenarioBar.tsx）

   Step 6.11: 月単位入力 + 変動費比率（v1.9 にない・v2.1 新設）

   • revenueAnnual → revenueMonthly（月商入力・内部で × 12）
   • fixedCostAnnual → fixedCostMonthly（月固定費入力）
   • 二軸化: 売上原価率 (cogsRate) + 変動費比率 (variableCostRate)
   • cogsRate のラベル変更: 「経費比率（外注費含む・人件費除く）」に明示（役員報酬は別枠）
   • cogsRate を 2.5% 単位ドロップダウンに細粒度化（0-70% / 29 段階）

   Step 6.12 / 6.13: 月額報酬の年次増加額 + 役員報酬の最低月額（v1.9 にない・v2.1 新設）

   • Step 6.12: Y2 以降に毎年加算される月額報酬の増加額（前提条件）
     • yearResults useMemo で 5 年分の result 配列を生成
     • 例: 月 5 万増 → Y1=50 万, Y2=55 万, ..., Y5=70 万
   • Step 6.13: 役員報酬の最低月額（Gemini Deep Think 発見 #1・先行実装・前提条件・default 30 万）
     • 生活費ベースの月額下限
     • AI インサイトの制約として活用予定（現状: 入力フィールドのみ実装・buildInsightPrompt_ への反映は v2.2 候補・人間検討事項 #15）

   Step 6.14: 法人期首預金残高 + 住宅ローン減税（v1.9 にない・v2.1 新設）

   • 法人期首預金残高（前提条件・default 0）: 累積純資産（法人）に加算
   • 住宅ローン減税（前提条件・default 0・2022 年改正後制度）:
     • 所得税から先に控除
     • 控除しきれない分を住民税から控除（上限: 課税所得 × 5% または 97,500 円）
     • baseline で 0 にして節税金額に含める
     • 簡易実装: 年額固定 × 5 年（本来は残高 × 0.7% で年々減少・13 年期間）— 注意事項 #20

   Step 6.15: 想定貢献月商の参考表示（v1.9 にない・v2.1 新設）

   • AssumptionsPanel に read-only 表示（月額単価 × 売上貢献稼働率）
   • CompensationDropdowns の月商入力に**「想定値」ボタン**（一発設定）
   • Burnout メーター（Step 6.6）の入力値と連動

   Step 6.16: シート保存 + UX 統一 + プルダウン即時反映（v2.3 新設・PR #454）

   背景: Step 6.9 の localStorage 二系統保存 (v2.1 / v2.2) は単一端末内では機能していたが、(a) 端末跨ぎ共有不可 (PC ↔ スマホでシナリオ移行不可) / (b) 業種別テンプレ配布の手段がない / (c) 削除済シナリオの復元不可 等の限界が顕在化。F-67 ScenarioPanel が同様の課題を解決した経緯と並行して、F-57 のプリセット・シナリオもシート保存に移行 + UX を F-67 と統一 + プルダウン即時反映 (Phase E v2 同等) を一括実装。

   移行スコープ:

   • 旧版: ScenarioStore (フル CockpitInputs) / AssumptionsStore (前提条件 16 項目) を localStorage 保存
   • 新版: 2 タブにシート保存
     • 38_f57_assumptions (前提条件プリセット・業種別テンプレ配布可能)
     • 39_f57_scenarios (フル CockpitInputs シナリオ)
   • 自動移行: 初回 SPA ロード時に旧 localStorage 内容を 1 回だけシートにアップロード (f57_cockpit_assumptions_migrated_to_sheet_v1 / f57_cockpit_scenarios_migrated_to_sheet_v1 フラグで再実行抑制)
   • 旧 localStorage: 安全のため残置 (手動削除可・将来 migration 完了確認後に廃止予定)

   データモデル (F57_AS / F57_SC 共通スキーマ):

   列	内容
   有効フラグ	TRUE / FALSE (削除は論理削除で FALSE 化)
   プリセットID / シナリオID	F57AS_xxxx / F57SC_xxxx (4 桁連番・Constants.ID_PREFIXES.F57AS / F57SC で発番)
   プリセット名 / シナリオ名	ユーザ入力 (例: コンサル業・1000 万資本)
   作成日時 / 更新日時	new Date() (上書時に更新日時のみ更新)
   payloadJSON	値オブジェクトの JSON 文字列 (前提条件 16 項目 or フル CockpitInputs)
   備考	任意

   公開 API (300_ui/302_spa_bridge.js・_f57Crud_ ファクトリで重複排除):

   各タブに対し 4 関数 = 計 8 個:

   関数	用途
   listF57Assumptions() / listF57Scenarios()	values 込みのフルレコードを返す (prefetch 用・即時反映の核)
   saveF57Assumption(payload) / saveF57Scenario(payload)	id 未指定で新規発番、指定で同 ID 上書
   loadF57Assumption(id) / loadF57Scenario(id)	単一フェッチ (現状は使用箇所なし・後方互換用)
   deleteF57Assumption(id) / deleteF57Scenario(id)	論理削除 (有効フラグ=false)

   戻り値は全て JSONSafe<T> ラップ。型定義は docs/spec/sidebar_api.d.ts の F57RecordMeta (.values? 含む) / F57RecordSavePayload / F57RecordFull を参照。

   UX 統一 (F-67 ScenarioPanel と同一構造):

   • 同一スタイル: myr-scenario-panel (緑色テーマ) を F-57 / F-67 で共有
   • 同一構造: インライン名前入力 + 4 ボタン (🔄 再取得 / 💾 上書保存 / ➕ 新規保存 / 🗑️ 削除)
   • AssumptionsBar (📋 前提条件プリセット) と ScenarioBar (📚 シナリオ) で同一 UI

   即時反映 (Phase E v2 同等):

   • list API が values 込みで返却するため SPA は初回 1 回の取得で全件 prefetch
   • プルダウン onSelect で即座に値反映 (sheet roundtrip なし) — 体感サクサク化
   • 📂 読込 → 🔄 再取得 (他タブ更新取込用) に役割変更
   • F-57 / F-67 両方で同パターン適用 (UX 統一の実装裏付け)

   適用ロジック (Bar 別の差分):

   Bar	上書対象	維持対象
   AssumptionsBar 読込時	前提条件 16 項目のみ	Variables (報酬・配分系) は維持
   ScenarioBar 読込時	Variables のみ	前提条件 16 項目は維持
   (参考) F-67 ScenarioPanel	yearInputs / initialBS / optimizationPolicy / exitPlan を全て上書き	(なし・state 完全復元)

   新規追加ファイル / 変更ファイル (PR #454):

   • DDL: 100_config/101_sys_config.js に 38_f57_assumptions / 39_f57_scenarios + flagTabs 登録 + F57_AS / F57_SC スキーマ
   • ID 発番: 000_infra/002_constants.js に F57AS_ / F57SC_ プレフィックス追加
   • Repository: 200_data/202_repository.js に F57AssumptionsRepository / F57ScenarioRepository 新設
   • API: 300_ui/302_spa_bridge.js に _f57Crud_ ファクトリで重複排除し list/save/load/delete を assumption/scenario 各 4 = 計 8 個追加
   • 型: docs/spec/sidebar_api.d.ts に F57RecordMeta / F57RecordSavePayload / F57RecordFull 型追加
   • Store: webapp_client/src/cockpit/{ScenarioStore.ts, AssumptionsStore.ts} を sync localStorage から async sheet ベースに書換

   テスト: 900_test/901_test_runner.js に testF57ScenarioSheetMigration_ を追加 (12 ケース):

   ケース	内容
   F57-SHEET-01	API 関数 8 個の存在
   F57-SHEET-02	_f57Crud_ ファクトリの存在
   F57-AS-01〜06	前提条件プリセット ラウンドトリップ (新規 / load / 上書 / 上書 load / 削除 / 削除後 load エラー)
   F57-SC-01〜04	シナリオ ラウンドトリップ (新規 / load monthlySalary / load dividendType / 削除)

   「実装が spec を先行 → spec を整合追従」のパターン累計 9 例目 (F-57 v2.1 PR #395 + 均等割修正 PR #399 + F-58 v2.0 PR #401 + F-66 v1.2 PR #403 + F-67 v1.5 PR #424 + F-67 v1.6 PR #427 + F-67 v1.7 PR #449 + F-66 v1.2 + 本 v2.3 で 9 例目)。

   Step 7: cockpit 拡張パネル群（v2.4 新設・PR #459）

   背景: v2.3 まで MAS-057 cockpit は「単年の節税最適化ツール」として完成していたが、ユーザーから「(a) 4 アプローチ A/B/C/D の P/L を横並びで見たい (1 画面で比較したい) / (b) F-67 マルチイヤー planner の B/S 引継ぎロジックを cockpit にも統合し、6 年分の財務 3 表 (P/L · B/S · CF) を一気通貫で確認したい / (c) 各年の役員報酬を個別アプローチで切替できるようにしたい / (d) 本年 (Y0) は当期着地見込み (64_pl_ytd_plan + 73_bs_plan) で上書きできるようにしたい」という要望が出た。これに応えるため、main 側 PR #459 (commit 8f45430) で cockpit 拡張パネル群 (Step 7-A/B/C/D) を一括実装し、cockpit を「節税最適化ツール → 多年経営ダッシュボード」に進化させた。

   Step 7 の 4 サブパネル全体像:

   サブステップ	パネル / API	配置 / 役割
   7-A	ApproachComparisonPanel.tsx	MAS-071 戦略シナリオパネル直下・4 アプローチ + AVG の 5 列均等 P/L 比較
   7-B	SoloFinancialStatementsPanel.tsx	7-A の直下・Y0-Y5 の 6 年分 P/L · B/S · CF 連結表示
   7-C	getSoloCEOY0Forecast() GAS API	7-B の Y0 上書きトグル用・64_pl_ytd_plan + 73_bs_plan 集約
   7-D	cockpit-main.tsx 副作用 import 拡張	451_multiyear_planner.js 追加 (failure_patterns #33 対策)

   Step 7-A: ApproachComparisonPanel — 4 アプローチ別 P/L 比較

   • ファイル: webapp_client/src/cockpit/ApproachComparisonPanel.tsx
   • 配置: MAS-071 戦略シナリオパネル (CompensationStrategyPanel) の直下
   • 目的: A/B/C/D の 4 アプローチ + その平均 (AVG) の計 5 アプローチで役員報酬を採用した場合の単年 P/L を並列比較し、戦略選択の妥当性を 1 画面で吟味する
   • データ供給元:
     • 役員報酬月額 = MAS-071 戦略シナリオの推奨額を直接参照 (rounding 誤差回避のため戦略推奨値を SSoT とする)
     • isFirstYear=false を強制 (短縮事業年度按分を排除し通年ベースで純粋比較)
     • 既存 computeYearlyBreakdown(modifiedInputs) を 5 回呼出 (A/B/C/D/AVG 別 modifiedInputs)
   • 表示行 (12 行):
     • 年商 / 変動費 / 固定費 (法人社保含む) / 役員報酬 / 営業利益 / 法人税等 (国税 + 地方税) / 住民税均等割 / 税引後利益 / 個人税 / 個人社保 / 個人手取り / 家族純資産フロー
   • UI: <table style="table-layout: fixed"> + 各列 width: 16% (5 列均等 + ラベル列 1 列)・列幅崩れ防止
   • MAS-071 との接続: compensationStrategy prop で MAS-071 推奨役員報酬 4 値を受け取る (端末 onChange だけでは rounding が入るため SSoT で連結)

   Step 7-B: SoloFinancialStatementsPanel — 多年 P/L · B/S · CF

   • ファイル: webapp_client/src/cockpit/SoloFinancialStatementsPanel.tsx
   • 配置: ApproachComparisonPanel の直下
   • 目的: Y0 (本年) を左端とした 6 年分の財務 3 表 (P/L · B/S · CF) を年次連結で表示し、節税戦略の長期的影響を可視化
   • 計算エンジン: F-67 simulateMultiyearClient (451_multiyear_planner.js) を流用 (B/S 引継ぎロジックを F-57 / F-67 で共有)
   • F67MultiyearBootstrap の合成: F57 boot を起点に MultiyearBootstrap を合成 (perDiemPolicies / mas071Params は F-57 では不要なため省略合成)
   • 各年で役員報酬を選択可能 (6 dropdown):
     • 各年 (Y0-Y5) ごとに dropdown を 1 つ用意・選択肢は A / B / C / D / AVG / 現状 の 6 つ
     • Y0 のみ「現状」を default 選択 (Y0 は当期着地見込みとの併用シナリオが多いため)
     • Y1-Y5 は「AVG」を default 選択 (戦略平均で安定運用するシナリオを想定)
   • 本年 (Y0) 事業継続月数入力 (1-12 ヶ月・短縮事業年度対応):
     • default 12・clamp [1, 12]
     • 按分は Y0 のみ実施: revenueMonthly / fixedCostMonthly / monthlySalary / dividendAnnual を y0Months / 12 で scale (Y1 以降は通年でフル計上)
     • 短縮事業年度の P/L 月割按分 + 法人税均等割の月割 (既存 calc 流用) で精緻化
   • Y0 を当期着地見込みで上書きトグル:
     • default OFF (理論計算ベース)
     • ON 時に getSoloCEOY0Forecast() (Step 7-C) を 1 回呼出・結果 P/L で Y0 を直接上書き + B/S を Y1 期首 BS に初期値投入
     • planner は horizon=5 (Y1-Y5) で実行・initialBS = forecast.bs を渡す → Y1 期首 BS が Y0 forecast 期末 BS で連結性維持
     • トグル文言は 「64 + 73」 で表記 (旧「64 + 71」は誤り・64 は計画なので 73 が正しいペア)
   • CF 表示: 営業 CF / 投資 CF / 財務 CF / FCF (FreeCashFlow) を含む簡易 4 行表示

   Step 7-C: Y0 当期着地見込み API — getSoloCEOY0Forecast()

   • ファイル: 300_ui/302_spa_bridge.js
   • 関数名: getSoloCEOY0Forecast()
   • 戻り値: { pl: { revenue, cogs, sga, operatingIncome, ordinaryIncome, pretaxIncome, corporateTax, netIncome }, bs: { capital, retainedEarnings, cash, fixedAssets, debt, equity }, source: { plSheet, bsSheet, fallbackUsed } }
   • 集約ロジック:
     • P/L 集約: 64_pl_ytd_plan の通期列 (column B) から主要 8 項目 (売上 / 売上原価 / 販管費 / 営業利益 / 経常利益 / 税引前 / 法人税等 / 純利益) を抽出
     • B/S 集約: 73_bs_plan の最右列 (期末計画) から主要 6 項目 (資本金 / 利益剰余金 / 現預金 / 固定資産 / 借入金 / 純資産) を抽出
     • フォールバック: 73_bs_plan が未生成のとき → 71_bs (実績) 最右列を代替使用 (source.fallbackUsed = true で SPA 側に通知)
   • failure_patterns #29 対策: 戻り値全体を _scrubInfinityForJSON_ 経由で返却 (V8 → Java シリアライズ時に Infinity / NaN が silent null 化する致命的落とし穴を予防)
   • SoloFS パネルとの接続: トグル ON 時に planner を horizon=5 (Y1-Y5) で実行 + initialBS = forecast.bs を渡し、Y1 期首 BS = Y0 forecast 期末 BS で連結性維持

   Step 7-D: cockpit-main.tsx 副作用 import 拡張

   • ファイル: webapp_client/src/cockpit/cockpit-main.tsx
   • 背景: failure_patterns #33 (SPA 副作用 import 漏れによる engine 未ロード) の予防
   • 副作用 import の旧 / 新:

   状態	import 一覧
   旧 (v2.3)	442_social_insurance_tier_engine.js / 443_corporate_housing_optimizer.js / 444_per_diem_policy_engine.js / 445_solo_ceo_calc_engine.js / 449_*.js / 454_*.js
   新 (v2.4)	上記 + 451_multiyear_planner.js を追加 (SoloFS 多年版で simulateMultiyearClient 再利用)

   • 実装ファクト: F-57 SPA 起動時に window.MultiyearPlanner (もしくは同等の global) が確実に解決されるよう、副作用 import を追加することで simulateMultiyearClient が SoloFS パネルから即座に呼出可能になる
   • failure_patterns #33 必須対策: 「engine 未ロード → SoloFS パネル白画面」を防ぐ予防策・ビルド時に確実にバンドル含有させる目的

   CockpitApp.tsx 配置順序 (v2.4 最新)

   v2.3 までは MAS-058 RequiredRevenuePanel の上は MAS-071 戦略シナリオパネルだけだったが、Step 7-A / 7-B が間に挟まる:

   1. GuardrailBanners (税務否認リスク警告等・最上部固定)
   2. CompensationStrategyPanel (MAS-071 戦略シナリオパネル)
   3. ApproachComparisonPanel (Step 7-A・4 アプローチ P/L 比較)         ← v2.4 新規
   4. SoloFinancialStatementsPanel (Step 7-B・多年 P/L · B/S · CF)    ← v2.4 新規
   5. AssumptionsBar / ScenarioBar / CompensationDropdowns (既存・前提 + Variables 入力群)
   6. RequiredRevenuePanel (MAS-058 シナリオ健全性診断パネル・既存)
   

   MAS-067 / MAS-071 との連携 (Step 7 由来)

   • MAS-067 マルチイヤー planner: simulateMultiyearClient (451_multiyear_planner.js) を SoloFS で流用するため、MAS-067 v1.9 の B/S 引継ぎロジック改修は MAS-057 SoloFS にも自動適用される (SSoT)
   • MAS-071 報酬戦略シミュレーター: ApproachComparisonPanel が MAS-071 推奨額を直接参照するため、MAS-071 の 4 アプローチ算出ロジック更新は cockpit に即反映される

   Step 7 関連テスト

   Step 7 はクライアントサイド SPA + GAS API 両方をまたぐため、テストは複数レイヤで実施:

   テスト	種別	内容
   getSoloCEOY0Forecast() 単体	GAS テスト	64_pl_ytd_plan / 73_bs_plan 存在ケース + 73 未生成 → 71 フォールバックケース
   ApproachComparisonPanel 表示	手動 SPA 確認	A/B/C/D/AVG 5 列の数値整合 (computeYearlyBreakdown 5 回呼出結果と一致)
   SoloFS Y0 月数按分	手動 SPA 確認	y0Months=6 設定 → revenueMonthly / fixedCostMonthly / monthlySalary / dividendAnnual が Y0 のみ 1/2 にスケール
   SoloFS Y0 上書きトグル	手動 SPA 確認	トグル ON → Y0 P/L が forecast 値に切替 + Y1 期首 BS が forecast 期末 BS に連結

   「実装が spec を先行 → spec を整合追従」のパターン累計 13 例目 (F-57 v2.1 PR #395 + 均等割修正 PR #399 + F-58 v2.0 PR #401 + F-66 v1.2 PR #403 + F-67 v1.5 PR #424 + F-67 v1.6 PR #427 + F-67 v1.7 PR #449 + F-57 v2.3 PR #454 + F-66 v1.2 + 本 v2.4 PR #459 で 13 例目)。

   MAS-058 / MAS-061 / MAS-141 との連携（v1.9 から維持）

   • MAS-058 必要年商シミュレーター: MAS-058 の Healthy 年商を入力した際、3 区分テーブルの「収入」「手取り」「純資産」が連動更新
   • MAS-061 Cash ETR: 「法人税」行に Cash ETR の信号機（🟢/🟡/🔴）を併記し、節税余地を明示
   • MAS-141 共済シミュレーター: 「純資産」行（特に老後の備え用途・Step 6.7）に共済積立の累積額を反映

   「サンキー vs 3 区分テーブル」の使い分け（v2.1 で更新）

   UI	主用途	表示優先度
   3 区分テーブル（Step 6・15 細項目）	数値精度 + デッドヒート分析 + Y1-Y5 + 累積 + 改善示唆との連動	デフォルト表示・主要 UI
   サンキーダイアグラム（Step 5・既存）	流出構造の概観・初見ユーザーへの説明	<details> で折りたたみ補助化（v2.1 で副次化）

   実装ファイル（PR #394 で新規追加）

   • webapp_client/src/cockpit/AssumptionsPanel.tsx — 前提条件 16 項目入力 UI
   • webapp_client/src/cockpit/AssumptionsStore.ts — 前提条件 localStorage 永続化
   • webapp_client/src/cockpit/ScenarioBar.tsx — シナリオ保存/呼出 UI
   • webapp_client/src/cockpit/ScenarioStore.ts — シナリオ localStorage 永続化（migration 含む）
   • webapp_client/src/cockpit/ThreeSectionTable.tsx — 3 区分テーブル本体（Y1-Y5 タブ + 累積セクション）

7. MENU_DEFINITION への追加:

   • MAS-056 が追加予定の 🧭 意思決定対話（Web App） カテゴリに { label: '🎛️ ビジュアルコックピット URL をコピー', funcName: 'copyF57CockpitUrl', description: 'F-57 ビジュアルコックピットの公開 URL をクリップボードにコピー' } を追加。MAS-056 未着手時は本案件内で同カテゴリを新規追加する。

03_sys_params に追加する MAS-057 固有パラメータ

影響範囲

注意事項

本案件の実装時に注意すべき既知の落とし穴・設計制約を failure_patterns.md の番号付きで列挙する。

1. #18-#20（命名造語禁止）: 新設ファイル名・関数名・シート名・sysKey・メニュー名は Phase 1 の調査で実在確認した形（MST_SOCI / MST_INCM / TMPL_PDIEM / 442_social_insurance_tier_engine.js 等）を厳密に使う。特に calculateOptimalCompensation() は MAS-056 実装未着手時点では架空関数扱いであり、仕様書・コード内で参照する際は必ず「MAS-056 Phase 3 実装後に本エンジンを呼び出す」と明記し、未実装の関数を直接呼び出すコードを本案件で書かない。

2. #25（並列実装対称性）: 3 つの新設 Repository は _getSheet / findAll / findAsMap / _cache / resetCache の 5 要素を完全対称に実装する。IncomeTaxBracketRepository のみ findAsMap の代わりに findAsBrackets を返す点は意図的な差分（所得税はブラケット順序依存のため）としてコメントに明記し、他の 2 Repository との非対称性が「書き忘れではない」ことを示す。

3. #26（oauthScopes 部分宣言禁止）: 確認済（2026-04-24）— appsscript.json に既に https://www.googleapis.com/auth/cloud-platform が含まれているため、MAS-057 では appsscript.json を一切編集しない。部分的に追記すると GAS の自動スコープ検出が完全に無効化され、既存の全機能でスコープ不足エラーが発生する。

4. #27（Admin SDK API 変動）: 該当なし（本案件は Vertex AI / スプレッドシート操作のみで Admin SDK を使用しない）。理由を注意事項に明記し「該当なし」と判断した旨を残す。

5. #21（getLastColumn() 列範囲膨張）: 該当なし。新設マスタシートは列数固定・DDL 管理のため getLastColumn() を動的使用しない。sheet.getRange(1, 1, 1, headers.length) のように列数を明示する。

6. #22（String.trim() で全角スペース残留）: findAsMap() のキー正規化では .trim() だけでなく .replace(/[\s　]+/g, '') で全角スペースも明示除去する（等級名・規程名の入力ゆらぎ対策）。

7. #23（setValue("YYYY-MM") 日付自動パース）: 適用年度・開始年月は Utils.parseDateToYm(val) で正規化済みの文字列として管理し、setValue() で直接 "YYYY-MM" を渡さない（Google Sheets が YYYY-MM-01 として日付型に自動変換する事故を防止）。

8. #24（ARRAYFORMULA + MATCH 脆弱性）: 該当なし。サンキー・ドロップダウン UI は templates/financial_cockpit.html 上の JavaScript（D3.js / Plotly 等）で計算描画するため、Sheets 数式によるラベル解決を行わない。

9. DRY 原則（MAS-056 パラメータの非複製）: 2026 年福井県料率（健保 9.71% / 介護 1.62% / 子ども子育て支援金 0.23% / 厚年 9.15% / 軽減税率 15% / インボイス 70% 控除）は MAS-056 が F56_FUKUI_* キーで管理済。MAS-057 ではこれを**F57_* にコピーせず** Constants.getParam('F56_FUKUI_HEALTH_RATE', 0.0971) 等で直接参照する。税制改正時の更新箇所を MAS-056 側に一元化する。

10. 税制改正追従ポリシー: 個人所得税累進税率（20_mst_income_tax_bracket）・法人税軽減税率（Constants.TAX_RATES.brackets）・社会保険料率（17_mst_soci_tier）は毎年 3 月の税制改正後に手動更新する。更新責任者と更新 SOP を「人間が検討すべき事項」に明記し、MAS-049（賃上げ税制）仕様書の税制改正追従ポリシーと整合させる。

11. MAS-056 との依存方向反転（v1.1 Major 3 反映）: 当初案では MAS-057 が MAS-056 Phase 3 完了を待つ設計だったが、MAS-056 実装未着手のまま待つと MAS-057 もブロックされるため、依存を逆転する。MAS-057 Phase 1/2 で計算エンジン（442_social_insurance_tier_engine.js / 443_corporate_housing_optimizer.js / 444_per_diem_policy_engine.js）を独立した公開 API として完成させ、MAS-056 実装時に MAS-057 エンジンを呼び出す形とする。MAS-057 Phase 3 UI のみ MAS-056 Phase 3 + MAS-232 SPA 基盤完了後に着手。

12. クライアントサイド計算設計の堅持（v1.1 Critical 1 / v1.3 / v1.7 / v1.8 更新）: Phase 3 UI は GAS google.script.run 通信レイテンシ（1〜3 秒）を避けるため、ドロップダウン onChange 時の再計算をクライアントサイド JS で実行する。v1.8 で UI を連続スライダーから離散ドロップダウンに変更したが、レイテンシ排除の方針は引き続き有効（ai_agent_tips.md §7 準拠・ドロップダウン化で 60fps 要件は不要になったが、即応性確保のため GAS 通信は引き続き最小化する）。v1.3 / v1.7 で「TypeScript 複製」方針を撤回し、単一ソース共有（SSoT）に変更済（詳細は注意事項 #14 参照）。同一入出力の担保は Phase 1 のテスト（901_test_runner.js）に加えて、クライアント側では同じ .js ファイルをそのまま読み込むため Jest 統合テストで同一ファイルを呼べる構成とする。

13. Constants vs DDL の責務分離（v1.1 Critical 2 反映）: 税率・料率パラメータは「毎年 3 月税制改正で全国一律に更新されるもの」と「会社固有で動的に更新するもの」で管理場所を分ける。全国一律の固定値（個人所得税ブラケット・法人税ブラケット・住民税率）は 002_constants.js の定数、都道府県別・会社固有の動的値（社会保険料率の等級別・出張日当規程）は DDL シートに格納する。この方針を新規案件にも踏襲する。

14. Pure Function 厳格化と単一ソース共有（v1.3 Critical / v1.7 で GAS-Vite ブリッジ方式を具体化）: 400_domain/442_*.js / 443_*.js / 444_*.js の新設ドメインエンジンは、SpreadsheetApp / UrlFetchApp だけでなく Utils / Constants への直接依存も排除する。Utils.parseAmt / Utils.persistLog / Constants.getParam は関数内で呼ばず、呼び出し元（Repository / UI 層）が引数として値を注入する。ログ出力が必要な場合は戻り値に warnings: [{ level, message }] 配列を含め、呼び出し元で Utils.persistLog を呼ぶ。
    
    GAS と Vite のモジュールシステム非互換への対処（v1.7 Critical 反映・Gemini 指摘）: GAS V8 ランタイムは export / import の ESM 構文をネイティブサポートしないため、.js に ESM 構文を書くと GAS 実行時に SyntaxError になる。そのため新設エンジンの .js ファイルは GAS 側で直接動作する var SocialInsuranceTierEngine = (function () { ... return { findTier, calcPremiums, ... }; })(); の IIFE + グローバル変数宣言パターン とする（Phase 1 実装 442_social_insurance_tier_engine.js の方式に準拠）。Vite 側の import には以下のいずれかを採用:
      (a) vite-plugin-commonjs / CJS 変換プラグイン で GAS 側のグローバル変数宣言を CJS モジュールとして読み込む
      (b) window オブジェクトへの露出: ビルド時に .js の末尾で if (typeof window !== 'undefined') window.SocialInsuranceTierEngine = SocialInsuranceTierEngine; をラップ（GAS 側では window が未定義なので安全）
      (c) UMD ラッパー生成: 既存の var 宣言コードを Rollup 等で後付け UMD 化するビルドステップを Vite 設定に組み込む
    これにより GAS 環境 / ブラウザ環境 / Jest テスト環境で同じ .js ファイルを変更なしに使い回せる（TypeScript 複製は禁止）。MAS-232（Vite+React SPA 基盤）の PoC で (a)(b)(c) のどれを採用するか実測で決定する（「人間が検討すべき事項」参照）。

15. 税務否認リスクへの UI ガードレール（v1.3 Major 反映・BRD §5/§8 免責事項と整合）: 本システムは数値シミュレータであり、税理士・社労士の個別助言に代わるものではない。Phase 3 UI 実装時に以下を必須とする: (a) 賞与比率 ≥ 40% 検知時の赤枠警告バナー、(b) 月額が最低等級に到達した際の「社保免脱目的と認定されるリスク高」警告、(c) 画面下部の常時表示免責文（「本シミュレータの出力は税理士・社労士の個別助言に代わるものではありません」）、(d) 事前確定届出給与の届出期限アラート（BRD §6 参照）。これらは F57_INSIGHT_AI_MODEL 等の AI 生成ではなくルールベースで常時表示とし、AI 障害時も機能する設計とする。

16. 【v2.0 追記】V8→Java シリアライズの Infinity / NaN silent null（Phase 3 実装時に実機検出）: GAS Web App から google.script.run 経由で関数を呼んだ際、戻り値オブジェクトのどこかに Infinity / -Infinity / NaN が含まれていると、V8→Java ブリッジでのシリアライズが失敗し、withSuccessHandler に null が渡る（withFailureHandler は呼ばれない・throw もない・GAS エディタ直接実行では JSON.stringify も成功するため検知困難）。HAR で見ると: op.exec[0, null, "<Java HashMap.toString>"] — 第二要素が null・第三要素に Java toString が入る。対策: bootstrap で Constants.INCOME_TAX_BRACKETS.brackets[6].upTo = Infinity のような既知 Infinity を Number.MAX_SAFE_INTEGER（9007199254740991）に scrub。Repository 経由で取得する値も Number.isFinite() で防御的にチェック。切分テクニック（実装時の手順）: ①静的 probe 関数（Date と string のみ返す）で通信経路を確認 → ②関数内で JSON.stringify を呼んで length を console.log → ③それでも null なら必ず Infinity / NaN / 関数 / 循環参照を疑う → ④最終手段は HAR エクスポートで op.exec[0, ...] の中身を確認。failure_patterns.md #29 も参照。

17. 【v2.0 追記】Vertex AI Gemini 3 系は dev 未有効化（Phase 3 実装時に実機検出）: gemini-3-pro-preview / gemini-3.1-pro-preview は bizlp-gas-accounting-dev の Vertex AI で HTTP 404 (Publisher Model not found)。Model Garden で個別 Enable + 48h 課金履歴経過が必要。MAS-057 Phase 3 実装時点では gemini-2.5-pro を default に運用し、UI の CUSTOM オプション + F57_GEMINI_MODEL_OVERRIDE_PRO 経由で 3.x 系の有効化検証が可能な設計とした。failure_patterns.md #30 も参照。

18. 【v2.0 追記】deployment ID の二重管理リスク（Phase 3 copyF57CockpitUrl 実装時に判明）: ScriptApp.getService().getUrl() は GAS が認識する最新の deployment URL を返すが、scripts/deploy.sh で固定運用している共有 deployment ID（チーム標準 URL）と異なる ID を返す場合がある（手動デプロイ等で枝分かれ）。copyF57CockpitUrl では deploy.sh の deployment ID をハードコード（Env.isDev() で dev/prod 切替）し、URL のホスト・ドメイン部だけ getService().getUrl() から流用する形を採用。

19. 【v2.1 追記】Gemini Deep Think 発見の MAS-067 機能を MAS-057 Step 6 で先行実装: PR #394 では MAS-067 (マルチイヤー計画) の MAS-334 議論と Step 6 実装が並行して進められた結果、Gemini Deep Think (MAS-334 Section G) で発見された複数の独自機能を MAS-067 着手前に MAS-057 Step 6 で先行実装している。具体的には: (a) Step 6.6 社長稼働限界 (Burnout) メーター = MAS-334 Section MAS-239 (ナレッジワーカー型 1 人社長の物理破綻ゾーン検知)、(b) Step 6.13 役員報酬最低月額 = MAS-334 由来の AI インサイト制約 (生活費ベースの下限制約)、(c) Step 6.12 月額年次増加額 = MAS-334 マルチイヤー判定の前提となる Y_n offset。これらは MAS-067 v1 spec にも別途記載されているが、MAS-057 Step 6 の単年×Y1-Y5 タブで「マルチイヤー計画の入口」として先行体験できる構成にすることで、MAS-067 実装着手時の UI 設計判断材料を確保している。MAS-067 実装時は MAS-057 Step 6.6 / 6.13 の入力値を引き継ぐ前提で設計する。

20. 【v2.1 追記】簡易実装の明示が必要な機能リスト（PR #394 実装時の妥協点を spec に明示記録・v2.1.1 で (f) は ✅ 解決済化）: Step 6 の以下 6 機能のうち (a)-(e) は v1 スコープを優先して簡易実装としており、ユーザーへの注記表示と将来改修候補としての記録を残す。(f) は v2.1 → v2.1.1 で PR #397 により実装修正完了:

    • (a) 住宅ローン減税 (Step 6.14): 年額固定 × 5 年で実装。本来は 残高 × 0.7% で年々減少・13 年期間・住宅種別 (認定長期優良住宅 / 一般住宅 等) 別の上限差。精密計算は別案件 (人間検討事項 #16) として切出推奨
    • (b) 老後の備え (個人) (Step 6.7): 共済 + 法人保険資産計上分のみ計算。NISA / iDeCo / 個人年金保険は未対応 (v2 候補・人間検討事項 #17)
    • (c) 万一の備え (Step 6.7): 個人/法人保険料の払込累計をそのまま給付想定として表示。実際の給付倍率は 3-10 倍が一般的であるため、UI に「実給付額は商品で異なる」旨の注記を必ず併記
    • (d) 退職所得控除の 5 年/19 年ルール (Gemini Deep Think 発見 #2): 小規模企業共済と法人退職金の枠の食い合いトラップは未実装。MAS-067 v1 で本格対応予定
    • (e) 創業費 (Step 6.8): 全額一括損金算入の簡易扱い。本来は 5 年定額償却 or 任意償却の繰延資産
    • (f) 法人住民税 均等割 70,000円/年 (2026-04-28 ユーザー指摘で発覚 → ✅ 同日 PR #397 で解決済・v2.1.1 で追従): Constants.TAX_RATES.localMinimumAnnual = 70000 は元々定義済だったが Step 6 cockpit 実装の calcResult 内で加算されていなかった (黒字でも常に + 7 万円が税法上の正解・「ミニマム値」ではない)。齋藤 Baseline (税引前利益約 750 万・21.4% ブラケット) で実効税率を約 +0.9pt 過小評価していた。MAS-013 投資分析 600_report/610_service_investment_analysis.js:227-246 も「ミニマムモデル」(赤字時のみ 7 万・黒字時は加算なし) で実装されており税法上バグだった。PR #397 修正内容: (1) 300_ui/302_spa_bridge.js の bootstrap に localMinimumAnnual を追加配信、(2) webapp_client/src/cockpit/calc.ts で corporateTax 累進計算後に Math.round(localMinimumAnnual * monthsActive / 12) を常時加算 (Y1 短縮事業年度は monthsActive で月割按分・法人住民税均等割の月割が原則)、(3) 600_report/610_service_investment_analysis.js の calcEffectiveTaxRate_ で黒字時にも minAnnual を加算、(4) docs/spec/sidebar_api.d.ts の F57CockpitBootstrap 型に localMinimumAnnual: number 追加。法人住民税の構造: 均等割 (固定費・資本金 + 従業員数で決まる・赤字でも黒字でも常に発生) + 法人税割 (法人税 × 7%・所得連動) の 2 層構造。MAS-057 cockpit と MAS-013 投資分析の両方で前者が抜けていたが、PR #397 で両方とも税法準拠 (常に + 7 万円) に統一済。

エッジケース

実装時に必ずテーブル記載の 26 件（v1.0 で 14 件 → v1.1 で +3 件 → v1.2 で +1 件 → v2.0 で +4 件 → v2.1 で +5 件）を単体テストでカバーする。条件 / 検知方法 / 期待される挙動 / ログ出力を明示。

実データ検証

実装完了後に以下の数値を GAS 実行 or MCP で確認し、手計算値と一致することを仕様書完成の必須条件とする。

齋藤 Baseline（BRD §8・Phase 1 検証データ）

入力: 月収 500,000 円 / 福井県料率（2026 年 3 月〜）/ 40 歳未満（介護保険なし）

13 パターンスキャン（Phase 3 検証データ）

役員報酬 月 25 万 / 30 万 / 35 万 / ... / 85 万（5 万刻み 13 パターン）× 齋藤 Baseline 固定費 → 各シナリオで法人手残り / 個人手残り / 合算純資産を算出し、合算純資産が最大となる役員報酬額を特定する。

期待される定性的結論: 厚年上限（標準報酬月額 65 万・月収目安 63.5 万）付近で「厚年は頭打ち、健保と所得税は上昇し続ける」局面に入るため、純資産最大化ポイントは標準報酬月額 50 万〜65 万の等級帯に落ち着く可能性が高い（齋藤 Baseline の年商 1,680 万 / 固定費 240 万 / 原価 0 の前提下）。実装後に数値で検証する。

個人所得税ブラケットの整合確認

20_mst_income_tax_bracket の 2026 年時点値（総合課税・所得控除後の課税所得に対し）:

これを住民税 10% と合算したものが「個人側実効税率」となり、Constants.TAX_RATES.brackets（法人実効 21.4% / 33.6%）との交点がデッドヒート分岐点となる。

賞与配分による社保総額逆転点（v1.2 追加・v1.7 で main Phase 1.5 実装と ±1 円一致に更新・齋藤 Baseline 年収 600 万固定 × 配分 4 パターン）

年収 600 万円を固定し、月額 × 賞与の配分を 4 通り変えた場合の年間社保総額（労使合算）。下表は calcBonusPremiums / calcPremiums 実装（PR #354 Phase 1 + PR #356 Phase 1.5）と ±1 円一致する数値（v1.7 で main 実装に整合、単体テスト F57-22 〜 F57-39 で担保）。福井県 2026 年 3 月料率（健保 9.71% / 厚年 9.15% / 介護 0%（齋藤 40 歳未満想定・40 歳以上の場合は健保 base に 1.62% 加算） / 子ども子育て支援金 0.23%）を使用。

重要: 月額側の社保は月額報酬そのものではなく、17_mst_soci_tier の標準報酬月額等級に丸めた額に料率を乗じる（例: 月額 40 万 → 健保 27 等級 = 標準 41 万）。spec v1.5 までは等級丸め前の raw 月額で試算していたため実装と差が出ていた（v1.7 で修正）。

パターン C の上限突破内訳（±1 円一致の計算根拠）

賞与 240 万円 × 1 回（齋藤 40 歳未満・他の賞与なし）:

• 標準賞与額 = Math.floor(2_400_000 / 1000) * 1000 = 2,400,000 円（千円未満切り捨て・元々切り捨て対象なし）
• 健保 base = min(2_400_000, yearlyCapHealth=5_730_000 - accumulated=0) = 2,400,000 円（年累計上限 573 万以内のため全額対象）
• 厚年 base = min(2_400_000, singleCapPension=1_500_000) = 1,500,000 円（1 回上限ちょうどで丸め）
• 子ども子育て base = 厚年と同様 1,500,000 円（上限共通）
• 健保 = round(2_400_000 × 0.0971) = 233,040 円
• 厚年 = round(1_500_000 × 0.0915) = 137,250 円
• 子ども子育て = round(1_500_000 × 0.0023) = 3,450 円
• 介護 = 0（40 歳未満）
• 賞与側合計 = 233,040 + 137,250 + 3,450 = 373,740 円
• 上限突破効果（Baseline A 比）: 240 万 - 150 万 = 90 万円部分について「厚年 0.0915 + 子ども子育て 0.0023 = 0.0938」の料率がゼロ化 → 900,000 × 0.0938 ≒ 84,420 円の社保削減 が主因

定性的結論（v1.7 更新）

齋藤 Baseline（年収 600 万・40 歳未満）の範囲では、**パターン C（賞与 240 万 × 1 回で厚年 1 回上限 150 万超過）**が社保年 約 8.4 万円削減で唯一の最有利。

• パターン B/D は逆に Baseline より約 2.3 万円増加: 月額を下げると標準報酬月額等級も下がるが、丸め後の標準額（B: 41 万 / D: 26 万）で計算した月額側社保が Baseline A を上回るほどではない。しかし賞与側の社保が加算されるため、賞与で上限突破が起きない配分（B: 60 万 × 2 / D: 150 万ちょうど × 2）では配分のメリットゼロ + 賞与社保分だけ増えて損になる。
• パターン D の誤認注意: v1.5 spec では「150 万ちょうどなら上限ギリギリで突破効果あり」と誤解していたが、実装では min(1_500_000, 1_500_000) = 1_500_000 で丸めが発生せず突破効果ゼロ。151 万以上にしないと厚年上限突破は発動しない。
• パターン A（Baseline）は同率で 2 位: D と同じ年間合計（1,168,308 円）だが、A は賞与ゼロなので届出リスクなし（定量的に同じなら A が実務的に安全）。

実装後に本計算値と ±1 円で一致することを単体テスト基準とする（F57-22 〜 F57-39 で担保済・901_test_runner.js）。

上限の種類を混同しないこと

この非対称性（厚年は 1 回単位・健保は 年累計）が「パターン C で厚年だけ頭打ちになり賞与を 1 回に集約すると有利」の本質的理由。両方とも 1 回上限と誤認してはならない。

実務上の制約警告: パターン C は事前確定届出給与の届出が必須。届出タイミング（株主総会決議日から 1 ヶ月以内、または事業年度開始日から 4 ヶ月以内の早い日）を逃すと損金算入不可となり、逆に不利になるリスクがある点を UI インサイトで常時表示する。また税務否認リスク（BRD §5 / §8 参照・年収の 40% 以上の賞与配分は「社会保険料免脱目的」と認定されるリスク）も併記する。

40 歳境界値テスト（v1.1 Minor 5 反映・Phase 1 単体テスト）

介護保険料の適用有無が分かれる境界。calcPremiums(tier, { isOver40 }) の isOver40 フラグ切替で以下を確認:

実装時に 901_test_runner.js に「境界 age = 39/40/41 で介護保険料が 0 / 8100 / 8100」を期待値として追加。会計期間内に 40 歳到達する場合の月割り対応は将来拡張として「人間が検討すべき事項」参照。

AI インサイト出力検証（Phase 3）

齋藤 Baseline + 月報酬 45 万入力時に callClaudeApiOnVertex_ で生成されるインサイトが以下の要件を満たすこと:

• 数値が具体的（「5 万円下げる」「手残り X 万円増」など）
• 社会保険料壁ロジックを言及（「等級が下がる」「厚年保険料が Y 円減る」）
• 3 文以内で簡潔

関連ドキュメント

• BRD: docs/brd_solo_ceo_financial_navigator.md — 本案件の起点となる Vision / Mission / ドメインロジック / UX 戦略
• MAS-056 意思決定対話 UI: docs/dev/dev_mas-056_conversational_scenario_ui.md — Chat UX 側の姉妹案件。calculateOptimalCompensation() の仕様元。MAS-057 UI 統合時の HTML 構造参照元
• MAS-011 What-if: docs/dev/dev_mas-011_what_if_simulation.md — 5 カ年推移計算エンジン
• MAS-013 投資分析: docs/dev/dev_mas-013_investment_simulation.md — NPV/IRR 計算エンジン
• MAS-048 採用 TCO: docs/dev/dev_mas-048_hiring_tco_bep_simulator.md — 将来採用時の TCO 計算（1 人法人フェーズでは参考のみ）
• MAS-049 賃上げ税制: docs/dev/dev_mas-049_wage_increase_tax_credit_simulator.md — 税制改正追従ポリシーの前例
• 失敗パターン: docs/_internal/failure_patterns.md — 特に #18-#20（命名造語）/ #25（並列実装対称性）/ #26（oauthScopes 部分追記）
• PRD プロダクトポリシー: docs/prd.md — Human-in-the-Loop 原則
• CLAUDE.md: プロジェクトルール、ブランチ運用、ファイル番号体系、コーディング規約
• D.11 財務意思決定プロセス: MAS-056 派生元。9 ステップ意思決定プロセスの Step 9「個人 B/S + 法人 B/S 統合」が本案件の中核

人間が検討すべき事項

実装着手前に決定が必要な論点を列挙。Deep Research 論点 10 件 + Claude 追記 17 件の計 27 件（v1.2 で +3 / v2.1 で +3）。

Deep Research 推奨論点（BRD 由来・10 件）

1. MAS-056 と MAS-057 の UI 統合形態: 単一 Web App 内タブ切替（Chat タブ / Visual Cockpit タブ）vs 独立 Web App 2 つ（別 doGet エントリ）。推奨は単一 Web App だが、URL 共有の観点で独立化も検討余地あり。
2. 標準報酬月額マスタの年次更新フロー: 17_mst_soci_tier を DDL 管理（setupAllSchemas で初期化）+ 812_migration_f57_tier_seed.js でデータ投入、とした場合、毎年 3 月の料率更新をどう運用するか（手動 SQL 的更新 or 新マイグレーションスクリプト発行）。
3. 社宅家賃の賃貸料相当額計算方式の選定: 正式法（固定資産税評価額ベース）vs 簡便法（賃料の 50%）。正式法は評価証明書取得コスト、簡便法は税務調査リスクのトレードオフ。F57_HOUSING_CALC_METHOD パラメータで切替可能に設計するが、デフォルトをどちらにするかは税理士判断が必要。
4. 出張日当規程テンプレの粒度: 単価固定（1 日 N 円）vs 距離別・宿泊有無別テーブル（JR 片道 200km 超で M 円等）。13_tmpl_per_diem_policy のカラム設計を単価固定でスタート、将来拡張で距離別に追加する方針で問題ないか。
5. 共済の出口リスク警告表示: MAS-141 の責務だが、MAS-057 UI で積立額ドロップダウンを操作する際に「経営セーフティ共済は解約後 2 年以内再加入不可（2024/10 改正）」等の注意喚起を同じ画面で表示するか、MAS-141 画面に誘導するか。
6. 累進税率テーブルの管理形態: DDL（20_mst_income_tax_bracket シート）vs JSON ファイル → ✅ v1.1 確定: Constants.INCOME_TAX_BRACKETS 定数で管理（Gemini レビュー Critical 2 反映）。法人税 Constants.TAX_RATES.brackets と対称な Constants 一元管理とし、税制改正時の更新箇所を 002_constants.js に集約する。
7. サンキーダイアグラムライブラリ選定: D3.js sankey-diagram（カスタマイズ性高・学習コスト）/ Plotly.js sankey（簡潔・ブランディング制約）/ Chart.js sankey 拡張（軽量・機能限定）。MAS-056 Vite+React 基盤との親和性も考慮。
8. 法人内部留保運用益率のデフォルト値: F57_INVESTMENT_YIELD のデフォルト 0%（控えめ）/ 3%（インフレ連動）/ 5%（積極運用）。保守的デフォルト推奨だが、UX 上「運用しない」が前提のように見えるとリアリティ欠如のリスクあり。
9. インサイト生成アルゴリズム: ルールベース（「等級が下がる」テンプレ文字列 + 数値埋め込み）/ LLM 生成（callClaudeApiOnVertex_ / callGeminiForReasoningOnVertex_ 経由）/ ハイブリッド（数値計算はルール・自然言語整形は LLM）。ハイブリッド推奨だが、コスト試算が必要。
10. 「額面 → 手残り」パラダイムシフトのオンボーディング UX: 初回起動時にチュートリアルダイアログ表示（BRD Vision を文章で説明）/ ツールチップのみ / 何もしない。認知シフトを起こすための初期教育の強度。

Claude 追記論点（実装時リスク・17 件・v1.2 で +3 / v2.1 で +3）

1. MAS-056 との依存方向反転の整合確認（v1.1 Major 3 反映・✅ 方針確定）: MAS-057 Phase 1/2 は MAS-056 実装状態に依存せず独立完成する方針に変更した。MAS-056 実装時に calculateOptimalCompensation() が MAS-057 エンジン（442_social_insurance_tier_engine.js 等）を呼び出す設計とするため、MAS-056 仕様書（PR #350）側にも「MAS-057 エンジンを内部で使用する」旨を追記する必要がある（PR 別途）。

2. シート番号 17 / 20 / 13 の二度採番リスク: 2026-04-24 grep 時点では空きだが、他案件（例: MAS-055 が 19_tmpl_saas_catalog を予約済）と同様に他の未着手案件が同番号を狙っている可能性。実装着手直前に再 grep 確認する旨を Phase 3 チェックリストに含める。

3. 812_migration_f57_tier_seed.js の番号採番（v1.5 で確定）: v1.3 時点では 810 を想定していたが、main 側実装着手時に 810/811 が他マイグレーション案件で先行採用されたため 812 に繰り上げで確定（実装コミット 242e0a9）。マイグレーション運用ガイドライン（CLAUDE.md 記載）に従い着手時再確認するフローが機能した実例。今後の同様ケースでも仕様書番号は意図記録として維持し、実装時に着手直前 grep で最終番号を確定する運用とする。

4. 健保料率の都道府県別管理: 健保料率は都道府県別（協会けんぽ）だが等級境界は全国一律。17_mst_soci_tier は「全国一律の等級境界」+「料率列は福井県値」とし、他県対応時にシート分割 or 列追加する設計方針を事前決定しておく必要がある。

5. 経営セーフティ共済の 2024/10 改正反映: 解約後 2 年以内の再加入は損金算入不可。MAS-141 で詳細ロジックを扱うが、MAS-057 UI で積立額ドロップダウンを操作する際に警告表示を出すか否か。

6. BRD 齋藤 Baseline の「実データ検証」セクション配置: 本仕様書では §実データ検証で期待値を記載したが、MAS-056 との重複を避けるため、実装時は 900_test/901_test_runner.js の MAS-057 テストケース内にのみ配置し、仕様書側には期待値の出典（BRD §8）のみを残すか検討。

7. MAS-232（Vite+React SPA 基盤）未着手時のフォールバック: Phase 3 の templates/financial_cockpit.html が MAS-232 前提だが、MAS-232 が着手されない場合の代替（GAS HtmlService.createHtmlOutputFromFile + Chart.js 単一ファイル）で段階的に動作させるか。

8. F57_INSIGHT_AI_MODEL のデフォルト選定: Phase 3 インサイト生成を Claude Sonnet / Gemini Flash / Gemini Pro Preview のどれをデフォルトにするか。コスト vs 応答品質のトレードオフ。2026-04-24 時点で Gemini 3 Pro Preview が最新で、Deep Think 有効時の応答が MAS-057 の深い税務推論に適する可能性あり。

9. コックピット URL の公開範囲: appsscript.json 既存の "access": "MYSELF" のまま運用する（齋藤氏のみアクセス可）か、"access": "DOMAIN" に拡張して将来のチーム利用を想定するか。1 人社長フェーズでは MYSELF のままで問題ないが、商用化時に再検討。

10. クライアント側ロジック二重実装の SOP 確立（v1.1 Critical 1 反映 → ✅ v2.0 で解決済）: Phase 3 で純粋関数を ES Module に移植すると、GAS 側（400_domain/442_*.js）とクライアント側（tools/webapp-client/src/engines/*.ts）の両方で同一ロジックを保守する必要がある → 採用方式: 注意事項 #14 (b) window 露出方式を採用。webapp_client/scripts/sync-engines.mjs で 400_domain/{442,443,444,445}_*.js を webapp_client/src/engines/ にコピー + 末尾に if (typeof window !== 'undefined') window.SocialInsuranceTierEngine = SocialInsuranceTierEngine; を自動付与するビルドステップを設置（PR #379 で実装）。SSoT は 400_domain/ 維持・webapp_client/src/engines/ は .gitignore 化。GAS 側更新時は npm run sync:engines で同期するだけ。TypeScript 複製ゼロを実現。Jest 統合テストは 400_domain/ を直接 import で同一性検証可能。

11. AI インサイトトリガーモードのデフォルト選定（v1.1 Major 4 反映）: F57_INSIGHT_TRIGGER_MODE のデフォルトを ONMOUSEUP_2SEC（自動・低コスト）とするか EXPLICIT_BUTTON（完全手動・ゼロコスト）とするか。初期 UX は自動推奨だが、商用化時のコスト見通しが立つまでは EXPLICIT_BUTTON で運用する慎重論もあり。03_sys_params で切り替え可能なので実運用で判断可能。

12. 事前確定届出給与の届出タイミング制約（v1.2 追加・BRD 年収スコープ転換で新規論点）: 本 BRD の賞与配分シナリオ（パターン C/D 等）は事前確定届出給与の届出が前提。届出タイミング（株主総会決議日から 1 ヶ月以内 or 事業年度開始日から 4 ヶ月以内の早い日）を逃すと損金算入不可となり、節税効果が逆転するリスクあり。顧問税理士への事前ヒアリング必須、UI 上でもインサイトと併せて常時警告文を表示する必要がある。届出内容（支給額・支給日）は実行時に「そのまま」支給しないと損金不算入となる点も含めて UX 設計する。

13. 賞与の税務上の扱い（定期同額給与との関係）（v1.2 追加）: 本 BRD で扱う役員賞与は「定期同額給与の例外」として事前確定届出給与の枠組みで損金算入される。月中の月額報酬変更（定期同額から外れる支給）は原則として損金不算入となるため、「年収を維持したまま月額を途中で増減させる」配分変更は通常不可。Phase 1/2 の計算エンジンではこの税務制約を「固定的な配分として事前に設計する」前提で実装し、月次配分の動的変更機能は実装しない方針。

14. 22_bud_headcount への賞与列追加の是非（v1.2 追加・Phase 2 以降の別案件切出推奨）: 現行 22_bud_headcount は月額報酬（月額給与・報酬）中心の設計で、賞与を明示的に管理する列がない。MAS-057 の配分シナリオを実行する場合、HC マスタにも「年間賞与額」「支給回数」「届出済フラグ」等の列追加が必要になる可能性がある。ただし本変更は DDL 影響が大きく HC マスタ全体への波及があるため、別案件（MAS-058 候補: 役員賞与 HC マスタ拡張）として切り出し、MAS-057 Phase 1/2 は既存 22_bud_headcount に触れない方針とする。MAS-057 の計算エンジンは「年収・月額・賞与」を引数として受け取る純粋関数であり、データソースは後付け可能。

15. 【v2.1 追加】AI インサイトの最低月額制約反映（Step 6.13 由来）: 現状の Step 6.13 は入力フィールドのみ実装で、buildInsightPrompt_ への反映は未着手。v2.2 候補として、AI インサイトの payload に livelihoodMinimumSalary を追加し、プロンプト末尾に「最低月額 X 円を下回る役員報酬の提案をしないこと」を明記する設計。F57_INSIGHT_MINIMUM_SALARY_DEFAULT 等の 03_sys_params キーを追加する想定（Step 6 は localStorage ベースのため現状は 03_sys_params 拡張なし・本対応時のみ追加）。実装着手前に「AI 提案の質低下リスク」（最低月額が高すぎると有効提案ゼロになる）を税理士レビューで確認。

16. 【v2.1 追加】住宅ローン減税の精密計算（Step 6.14 由来・別案件として将来起票候補）: 現状は年額固定 × 5 年の簡易実装。本来は 残高 × 0.7% で年々減少・13 年期間・住宅種別 (認定長期優良住宅 / ZEH 水準 / 一般住宅 等) 別の上限差・子育て世帯特例 (2024 改正) 等の精密計算が必要。MAS-057 単独で対応するか、住宅ローンシミュレーター案件として独立切出するかは将来判断。注 (2026-04-30): v2.1 当初は「MAS-071 候補?」と仮押さえしていたが、MAS-071 が稼働率連動型役員報酬シミュレーター (dev_mas-071_compensation_strategy_simulator.md) として正式確定したため、住宅ローン減税精密計算は別 ID で再アサイン (優先度高まり次第起票)。1 人社長の住宅ローン額は個人差が大きいため、簡易実装でも実用上問題ない可能性も高い。

17. 【v2.1 追加】老後の備え (個人) の NISA / iDeCo 対応（Step 6.7 由来・MAS-066 配当ミックスとの境界判断）: 現状の老後の備え (Step 6.7 個人列) は「個人保険料の払込累計」のみ。NISA (新 NISA 1,800 万枠) や iDeCo (掛金所得控除 + 受取時退職所得控除) は未対応。MAS-066 配当ミックス最適化と機能境界が近接する (個人の蓄積資産配分という観点) ため、MAS-066 実装着手前にスコープ分担を確定させる必要あり。案 A: MAS-057 Step 6.7 に NISA/iDeCo 入力を追加 (1 人社長単独最適化)。案 B: MAS-066 配当 spec に統合 (配当 vs NISA/iDeCo の代替関係を明示)。案 C: 別案件として独立 (個人ライフプラン軸)。

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

本案件は 3 Phase に分割し、各 Phase を独立プロンプトとして使う。着手順序は Phase 1 → Phase 2 → Phase 3。Phase 1 は MAS-056 実装状態に依存せず単独で着手可能だが、Phase 2 以降は MAS-056 Phase 3 実装完了を確認してから着手する。

Phase 1 実装プロンプト（Claude Sonnet 推奨）

## 案件
MAS-057 Phase 1 — 社会保険料壁エンジン + 等級マスタ + 個人所得税 Constants（約 1 ヶ月・MAS-056 実装状態に依存せず単独実装可・v1.1 反映）

## 事前調査（必ず Read する）
1. `000_infra/002_constants.js` — `TAX_RATES.brackets` 構造 / `getParam` シグネチャ / `SHEET_DEFAULTS` 配列型 / `ID_PREFIX_MAP` 既使用番号
2. `000_infra/003_contracts.js` — `Contracts.toDto(headers, row)` / `Contracts.toRows(headers, dtos)` シグネチャ
3. `000_infra/004_utils.js` — `Utils.getSheetByKey(key, fallbackName)` / `Utils.persistLog(level, funcName, message, detail)` / `Utils.parseDateToYm` / `Utils.parseAmt`
4. `200_data/202_repository.js` — `readSheetAsDtos_` / `AccountRepository` / `PartnerRepository` / `HurdleRateRepository` の完全構造（_getSheet / findAll / findAsMap / _cache / resetCache の 5 要素対称性）
5. `100_config/101_sys_config.js` — `setupAllSchemas` の `confSheet.appendRow` パターンと `schemas` オブジェクト追加パターン
6. `900_test/901_test_runner.js` — 既存テストケースの命名規約と実行パターン
7. `800_ops/` ディレクトリ配下のマイグレーションスクリプト構造（809_backup_tool.js が最新）

## 実装対象
1. **`100_config/101_sys_config.js` 編集**:
   - `confSheet.appendRow(['MST_SOCI', '', '17_mst_soci_tier', 'マスタ_社会保険標準報酬月額等級表 (F-57 壁エンジン)'])` 追加
   - `schemas` オブジェクトに以下 1 エントリ追加（`MST_HURDLE` の直後、`#666666` 色、validation は range 型）
     - `MST_SOCI`: headers = ["有効フラグ","等級","標準報酬月額下限","標準報酬月額上限","健保料率","厚年料率","介護保険料率","子ども子育て支援金率","適用開始年月","備考"]
     - `MST_SOCI.validations`: `{ "適用開始年月": { type: 'regex', pattern: '^20[2-3]\\d-(0[1-9]|1[0-2])$', helpText: 'YYYY-MM 形式で入力（例: 2026-03）' } }`（v1.7 追加）

2. **`000_infra/002_constants.js` 編集**（v1.1 Critical 2 反映）:
   - `Constants` オブジェクト内、`TAX_RATES` の直後に `INCOME_TAX_BRACKETS` を追加
   - 構造: `{ brackets: [{ upTo, rate, deduction }], residentTaxRate: 0.10, applicableFrom: '2026-01-01' }`
   - 2026 年時点の 7 段階累進テーブル（5% / 10% / 20% / 23% / 33% / 40% / 45%）を初期値とする

3. **`200_data/202_repository.js` 編集** — `HurdleRateRepository` の直後に 1 Repository を追加（5 要素対称実装・failure_patterns #25）:
   - `SocialInsuranceTierRepository`: `findAsMap()` はキー = 等級コード、重複は先着 + WARN ログ、`有効フラグ FALSE` 除外
   - **個人所得税用 Repository は新設しない**（v1.1 Critical 2 反映・Constants で代替）

4. **`400_domain/442_social_insurance_tier_engine.js` 新規作成** — `SocialInsuranceTierEngine` 名前空間:
   - `findTier(monthlyCompensation, tierMap)`: 線形 or 二分探索で等級を返す（上限超過時は最大等級 + `isOverCap: true` フラグ）
   - `calcPremiums(tier, { isOver40, prefectureKey = 'F56_FUKUI' })`: 健保 + 厚年 + 介護（40 歳以上のみ）+ 子ども子育て支援金を算出。料率は `Constants.getParam(prefectureKey + '_HEALTH_RATE', 0.0971)` 等で取得（MAS-056 キーを DRY で参照）
   - `calcBreakEvenPoint({ annualRevenue, fixedCost, ... })`: 厚生年金上限突破 BEP を計算
   - **純粋関数のみ**（SpreadsheetApp / UrlFetchApp を呼ばない）

5. **`800_ops/812_migration_f57_tier_seed.js` 新規作成** — マイグレーション運用ガイドライン準拠:
   - `migrationF57TierSeed()` 関数（冪等性必須: 既存データが 82 行ある場合はスキップ）
   - 日本年金機構 2026 年 3 月分〜の料率表（全国一律・健保 50 等級 + 厚年 32 等級）をハードコードで投入
   - `000_infra/002_constants.js` `MENU_DEFINITION` の `📋 サイドバー: 🔧 マイグレーション` カテゴリに `{ label: 'F-57 社会保険等級データを投入', funcName: 'migrationF57TierSeed', description: '17_mst_soci_tier シートに 82 行の等級データを投入 (冪等)' }` を追加

6. **`900_test/901_test_runner.js` にテスト追加**:
   - 齋藤 Baseline（月 50 万円）→ 等級 + 保険料の手計算値との ±100 円以内一致
   - 境界値テスト: 等級下限・上限ジャスト / 上限超過 / 下限未満
   - **40 歳境界テスト**（v1.1 Minor 5 反映）: `age = 39 / 40 / 41` で介護保険料が `0 / 8100 / 8100`
   - エッジケース #1 #2 #3 #4 #11 #12 #16 のカバー

## Phase 1 デプロイ手順
- dev 環境で `setupAllSchemas` → `migrationF57TierSeed` → テストランナーの順で実行
- 問題なければ `npm run push:prod` → prod で同順実行
- コミットメッセージ: `feat(F-57): 社会保険料壁エンジン + 等級マスタ + 所得税ブラケットマスタ (Phase 1)`

## failure_patterns チェック
- #18-#20: 新設ファイル名・sysKey・関数名は事前調査 Read で実在確認したもののみ使用
- #25: 2 Repository の対称性（意図的な `findAsBrackets` 差分はコメントで明示）
- #26: `appsscript.json` を一切編集しない（cloud-platform 済）

Phase 2 実装プロンプト（Claude Opus 4.7 推奨）

## 案件
MAS-057 Phase 2 — 社宅・日当・共済統合 + MAS-056 対話 UI 拡張（約 1 ヶ月・MAS-056 Phase 3 完了後に着手）

## 前提確認
- MAS-056 Phase 3 完了（`calculateOptimalCompensation()` が `400_domain/440_conversational_ui.js` or `400_domain/441_compensation_optimizer.js` に実在）を Read で確認
- MAS-057 Phase 1 が完了しており `SocialInsuranceTierEngine` が動作する

## 実装対象
1. **`100_config/101_sys_config.js` 編集**: `TMPL_PDIEM` スキーマ追加 + `confSheet.appendRow(['TMPL_PDIEM', '', '13_tmpl_per_diem_policy', 'テンプレ_出張日当規程 (F-57)'])`。**`validations` フィールド必須**（v1.3 Minor 反映）:

```js
'TMPL_PDIEM': {
  headers: ["有効フラグ","規程ID","規程名","出張区分","宿泊有無","日当単価","交通費上限","適用開始年月","備考"],
  color: "#666666",
  validations: {
    "日当単価":   { type: 'range', min: 0,     max: 50000,  helpText: '0〜5 万円の範囲で入力（1 日あたり）' },
    "交通費上限": { type: 'range', min: 0,     max: 200000, helpText: '0〜20 万円の範囲で入力' },
    "宿泊有無":   { type: 'regex', pattern: '^(有|無)$', helpText: '「有」または「無」を入力' },
  }
}
```
2. **`200_data/202_repository.js`**: `PerDiemPolicyRepository` を `PositionTemplateRepository` と完全対称に追加
3. **`400_domain/443_corporate_housing_optimizer.js` 新設**: `CorporateHousingOptimizer.calcRentAllocation()` を純粋関数で実装。`F57_HOUSING_CALC_METHOD` で `SIMPLE_50` / `FORMAL_FIXED_ASSET` 切替
4. **`400_domain/444_per_diem_policy_engine.js` 新設**: `PerDiemPolicyEngine.calcMonthlyAllowance()` を純粋関数で実装
5. **MAS-056 統合**: `440_conversational_ui.js` の `calculateOptimalCompensation` が `SocialInsuranceTierEngine.calcPremiums` + `CorporateHousingOptimizer.calcRentAllocation` + `PerDiemPolicyEngine.calcMonthlyAllowance` を呼び出すよう改修

Phase 3 実装プロンプト（Claude Opus 4.7 1M context 推奨）

## 案件
MAS-057 Phase 3 — ドロップダウン + サンキー UI + インサイト + 5 カ年推移（約 1 ヶ月・クライアントサイド計算設計・v1.1 Critical 1 / v1.8 ドロップダウン化反映・`ai_agent_tips.md §7` 準拠）

## 前提確認
- MAS-056 Phase 3 完了 + MAS-057 Phase 1/2 完了
- MAS-232（Vite+React SPA 基盤）完了 or MAS-056 が Vite+React で稼働中
- MAS-011 `WhatIfSimulator.run()` が 5 カ年モードで動作

## 設計原則（v1.1 反映・厳守）
- **シミュレーション計算はクライアント側**: GAS `google.script.run` 通信レイテンシ（1〜3 秒）を避けるため、ドロップダウン `onChange` 時の再計算はブラウザ内 JS で実行
- **GAS 側 API は 2 種のみ**: (1) 初期ロード時のマスタ一括配信 (2) AI インサイト生成（重処理）
- **AI インサイトは明示的トリガー**: `F57_INSIGHT_TRIGGER_MODE` に従い `onChange + 2sec` or `EXPLICIT_BUTTON` のみで発火。`onChange` 毎の自動呼び出し禁止

## 実装対象
1. **クライアントサイド計算エンジンの単一ソース共有**（v1.7 更新・TypeScript 複製禁止）:
   - **GAS 側 `400_domain/442_*.js` / `443_*.js` / `444_*.js` をそのままクライアントでも読み込む**（TypeScript ES Module として複製する方式は v1.3 / v1.7 で撤回済）
   - GAS ファイルは `var EngineName = (function(){ ... return {...}; })();` の IIFE + グローバル変数宣言パターンで実装（既に Phase 1 `442_social_insurance_tier_engine.js` はこの形式）
   - Vite 側の import ブリッジは **注意事項 #14 の (a) `vite-plugin-commonjs` / (b) `window` 露出 / (c) UMD ラッパー生成** の 3 方式から MAS-232 PoC で採用を決定
   - Jest 統合テストでも同一の `.js` ファイルを直接読み込み、GAS 側 `901_test_runner.js` と同じ期待値（MAS-057: F57-01 〜 F57-39）を検証する
   - `Constants.INCOME_TAX_BRACKETS` は**バンドル時に定数埋め込みではなく**、`action=F57_BOOTSTRAP` で JSON 配信（v1.3 Major 反映・バンドル埋込は再ビルド必須のため廃止）

2. **`templates/financial_cockpit.html` 新設** or MAS-056 `conversational_ui.html` にタブ追加:
   - ドロップダウン 3 本（役員報酬 / 社宅負担率 / 共済積立額）を `<select>` で実装（`ai_agent_tips.md §7` 準拠・離散単位・±ボタン併用可）
   - `onChange` → クライアント JS エンジン再計算 → SVG 即時再描画（< 50ms 応答）
   - `onChange` から 2 秒間追加変更なし → GAS `runFiveYearForF57()` + AI インサイト API 呼び出し
   - サンキーダイアグラム（`F57_SANKEY_LIBRARY` で切替・D3.js / Plotly / Chart.js・離散値の流量可視化用途として維持）
   - 5 カ年折れ線 + 積み上げ棒（サーバー計算結果を表示）

3. **`400_domain/440_conversational_ui.js` 拡張**（MAS-056 実装の doGet エントリを流用）:
   - `action=F57_BOOTSTRAP`: 17_mst_soci_tier 全件 + 13_tmpl_per_diem_policy 全件 + `Constants.INCOME_TAX_BRACKETS` + `Constants.TAX_RATES.brackets` + `F56_FUKUI_*` + `F57_*` を JSON 返却
   - `action=F57_INSIGHT`: ドロップダウン現在値 + シナリオを受け取り `callClaudeApiOnVertex_` で 1 インサイト生成。**自然言語プロンプトの組み立ては専用ビルダー関数 `buildInsightPrompt_(currentValues, diff)` に分離**（v1.7 Major 反映・Gemini 指摘）。`currentValues = { annualIncome, monthlySalary, bonusYearly, allocationRatio, cashflowTake, netWorth5y }` と `diff = { vsBaseline, vsPrevious }` を受け取り、「年収 N 万円・月額 X × 12 + 賞与 Y の配分から、賞与を Z 万円増やすと厚年上限突破で社保 W 万円減少・手取り V 万円増」形式のプロンプト文字列を返す純粋関数。テンプレート（配分変更型 / 年収変更型）を 2 種内蔵し、LLM 呼び出しを安定化。
   - `action=F57_FIVE_YEAR`: `WhatIfSimulator.run({ mode: 'FIVE_YEAR', ... })` を呼び出し 5 カ年推移を返却

4. **AI インサイト発火ロジック**（v1.1 Major 4 反映）:
   - `F57_INSIGHT_TRIGGER_MODE === 'ONCHANGE_2SEC'`（v1.8 で `ONMOUSEUP_2SEC` から改名）: ドロップダウン `onChange` から 2 秒間追加の選択変更がない場合のみ AI 呼び出し。操作再開時は既存タイマーキャンセル
   - `F57_INSIGHT_TRIGGER_MODE === 'EXPLICIT_BUTTON'`: 「💡 インサイトを更新」ボタンクリックのみで AI 呼び出し
   - UI に「最終更新: HH:MM」を表示し現在値との差分を可視化

5. **MENU_DEFINITION 更新**: MAS-056 の `🧭 意思決定対話（Web App）` カテゴリに `🎛️ ビジュアルコックピット URL をコピー` を追加

6. **テスト**:
   - 齋藤 Baseline 13 パターンスキャン検証（§実データ検証・クライアント側 Jest で実行）
   - GAS 側 Phase 1 テスト vs クライアント側 Jest で同一入出力を担保（CI で両方実行）
   - **40 歳境界** の介護保険料オン/オフ（v1.1 Minor 5 反映）

推奨実行モデル

Phase 別に推奨モデルを使い分け、トークン消費と応答品質を最適化する。

変更履歴

仕様書作成プロンプト

本仕様書は BRD docs/brd_solo_ceo_financial_navigator.md を入力に、以下 2 段階パイプラインで生成された:

1. Gemini 3 Pro Preview + Deep Think（scripts/1_generate_prompts_gemini.js）: BRD + コアコード 4 ファイル（002/003/004/202）+ TODO_future.md を入力に、アーキテクト視点のメタプロンプトを生成
2. Claude Sonnet 4.6 添削（scripts/1_generate_prompts_gemini.js 内 reviewByClaude）: 実行者視点で Phase 1 調査ステップの具体化・架空関数排除・タイムアウト回避原則を反映

添削後のプロンプトは tasks/prompts/task_F-57.md（297 行）として保存され、本仕様書は同プロンプトの Phase 1-3 を実行して作成された。原版プロンプトは tasks/prompts/task_F-57.gemini.md（67 行・Gemini 生出力）。

# 再生成する場合
TASK_IDS=MAS-057 node scripts/1_generate_prompts_gemini.js

# Gemini レビュー実行
SPEC_FILES=docs/dev/dev_mas-057_solo_ceo_cockpit.md node scripts/4_review_specs_by_gemini.js