MAS-058: シナリオ健全性診断 + 必要年商逆算（Scenario Health Diagnostic + Required Revenue Solver）

⚠️ 2026-04-28 v2.0 で主機能変更: 当初 v1.0-v1.2 では「希望年収から二分探索で必要年商を逆算」を主機能としていたが、ユーザーフィードバックで主機能を「現シナリオ（前提条件 + 月商）で希望年収を取った時に健全性 6 制約を満たすかを 1 点診断する」に変更（PR #400・commit ff61a29）。逆算機能は副機能（折りたたみ表示）として保存 + キャパシティ ギャップ分析 に発展拡張。1 点診断モードでは binding 制約の入れ替わり問題が発生しないため健全性 6 指標が安定。

概要

目的

MAS-057 cockpit が「年商・原価・固定費・年収 → 手取り最適化」の順方向診断なのに対し、本案件 (v2.0) は MAS-057 cockpit に統合された 2 機能 を提供する。

主機能: シナリオ健全性診断（Scenario Health Diagnostic・PR #400）

「現シナリオ（前提条件 + 月商）で希望年収を取った時に、Y1-Y5 各年期末で財務健全性 6 制約を満たすか」を二分探索なしで 1 点評価するパネル。MAS-057 cockpit の「累積純資産 + 平均実効負担率」セクションの直下に配置（現状把握↑ vs 目標逆算↓ の境界・default ON）。

• 6 制約 × Y1-Y5 期末 matrix: フロー（黒字 / 営業利益率 / 留保率 / 労働分配率）→ ストック（ランウェイ / 緊急予備金）の順
• ヘルシーを保てる年間投資余力: 各年で X 円追加支出した時の期末残高で 6 制約を維持できる最大の X を binary search
• 現状との累積純資産比較: 累積範囲タブ（Y1-Y5）+ 適用開始年タブ（Y1 から-Y5 から）+ 差分原因の箇条書き
• 適用開始年は Y2 から default: 翌年から希望年収を取る運用を想定。Y1 から-Y5 から の 5 タブで部分適用可能
• ランウェイ計算ロジック:
  • 6 制約 matrix: 期初累積純資産（= 前期末）÷ monthlyBurn
  • 投資余力: 期末累積純資産（= 期初 + 当年単年純資産増）÷ monthlyBurn
  • 月 burn = (固定費 + 役員報酬 + 法人社保) / 12（旧 v1.x の固定費のみは廃止・教科書的「ランウェイ」概念に整合）
• Y1 評価: inputs.isFirstYear / firstYearMonths / foundingCost を反映（短縮事業年度 + 創業費）
• Y2-Y5: 通年定常状態
• 緑列ハイライト = 希望年収を適用した年

副機能: 必要年商の逆算 + キャパシティ ギャップ分析（折りたたみ）

旧 v1.0-v1.2 の二分探索ソルバーは**副機能（折りたたみ表示）**として保持。Min / Healthy / Buffered の 3 段階年商を提示しつつ、代表取締役の単価 × 稼働率 × 12 = 想定貢献年商と必要年商のギャップを表示（キャパシティ ギャップ分析）。単価アップ案 / 稼働率アップ案を併記し、100% 超は警告。

v1 → v2.0 で発生しなくなった問題

旧 v1.x の二分探索モードでは「逆算 binding 制約の入れ替わりで Healthy 解の指標が成り行き改善する」（例: Y3 で労働分配率 binding → Y5 で営業利益率 binding に交代）という直感的でない挙動があったが、v2.0 主機能（1 点評価）では発生しない。副機能（二分探索）では引き続き発生しうるため注意事項 #14 で明記。

現在のコード

本案件は MAS-057 Phase 1/1.5 が提供する計算エンジンを逆順に呼び出す形で実装する。新規ロジックはソルバーと健全性判定のみで、税・社保の計算は既存関数を流用する。

MAS-057 Phase 1/1.5（✅ 完了）の利用関数

MAS-003 KPI ダッシュボード（✅ 完了）の既存閾値

労働分配率・営業利益率は 93_kpi_dashboard で既に計測されている。本案件の制約閾値は MAS-003 と同じ閾値基準を採用し、「KPI 画面で赤色になる水準 = MAS-058 の Healthy 失格ライン」として一貫させる。

MAS-008 Cash Runway（既存）のランウェイ計算

既存のランウェイ計算ロジック（現金残高 ÷ 月平均固定費）を参照し、MAS-058 の制約 #2「ランウェイ ≥ N ヶ月」の判定で流用する。

修正方針

📌 v2.0 Step 構造変更: Step 1（制約定義）と Step 5（cockpit 統合）は v2.0 で大幅書換。Step 2-4（ソルバーアルゴリズム / 3 段階出力 / 必要人月単価）は副機能（折りたたみ）として保存・記述は v1.0 から維持。新設 Step 1.5（主機能 API: evaluateScenarioHealth） が PR #400 で実装された主軸機能。

Step 1 — 健全性制約 6 項目の定義

コンサル/受託一人法人向けの default を採用（ai_agent_tips.md §6 事例ベースの調整値）。業態別に変更する場合は 03_sys_params を上書きする運用。

業態別調整のガイド（spec 上の参考値・03_sys_params 変更で対応）:

Step 1.5 — 主機能 API: evaluateScenarioHealth(input) （v2.0 新設・PR #400）

v2.0 で追加された主軸 API。年商を二分探索せず固定して 6 制約を 1 点評価することで、binding 制約の入れ替わり問題を排除し、健全性 6 指標を経営者の直感に整合させる。

シグネチャ

RequiredRevenueSolver.evaluateScenarioHealth({
  annualRevenue,        // 現在のシナリオの年商（円・月商×12 等）
  desiredAnnualIncome,  // 希望年収（円・役員報酬総額として扱う）
  cogsRate,             // 原価率（0 以上 1 未満）
  fixedCostAnnual,      // 年間固定費（円・役員報酬と社保を除く）
  monthlyFloor,         // 月額報酬下限（任意・default 30 万）
  isOver40,             // 40 歳以上フラグ（任意・default false）
  tierMap,              // SocialInsuranceTierRepository.findAsMap()
  constraints,          // 健全性 6 制約（任意・未指定時は F58_* sys_params から読込）
  dividendAmount,       // 配当年額 (任意・default 0・F-66 連携で v2.1 追加・PR #402)
})
// → {
//   isHealthy:   boolean,         // 6 制約全充足
//   snapshot:    PLSnapshot,      // _computePLSnapshot_ 結果（売上・粗利・営業利益・税引後利益・社保・労働分配率・etc）
//   constraints: ConstraintsObj,  // 適用された閾値
//   judgments:   {
//     profitable:      { actual, threshold, ok, op: '>',  label: '黒字 (税引後利益 > 0)' },
//     runway:          { actual, threshold, ok, op: '>=', label: 'ランウェイ' },
//     emergency:       { actual, threshold, ok, op: '>=', label: '緊急予備金' },
//     operatingMargin: { actual, threshold, ok, op: '>=', label: '営業利益率' },
//     retention:       { actual, threshold, ok, op: '>=', label: '留保率' },
//     laborShare:      { actual, threshold, ok, op: '<=', label: '労働分配率' },
//   },
//   failing: string[],  // 違反した制約のキー配列
// }

【v2.1 追加・PR #402 で実装】配当統合（MAS-066 連携）

_computePLSnapshot_ に dividendAmount input を追加（default 0）し、配当による法人留保減少を以下の指標に反映:

corporateRetainedAfterDividend = netProfit - dividendAmount
retentionRate                  = corporateRetainedAfterDividend / netProfit  // 配当影響あり
runwayMonths                   = corporateRetainedAfterDividend / monthlyBurn  // 配当影響あり
operatingMargin                = operatingProfit / annualRevenue              // 税引前指標 → 配当影響なし
laborShare                     = directorComp / grossProfit                   // 税引前指標 → 配当影響なし

設計判断 (v2.1):

• dividendAmount (絶対額) を採用: 旧 v1.x で想定していた dividendMixRatio (役員報酬比率) ではなく、dividendAmount (絶対額) を採用。MAS-066 cockpit 側の入力 UI と整合 (役員報酬とは独立した配当ドロップダウン)
• operatingMargin / laborShare は税引前指標 (会計通念上の定義に従う) のため、配当を引いても変動しない設計とする → 配当を増やすと「営業利益率は維持されるが留保率・ランウェイが悪化する」という直感的な挙動を実現
• default 0 のため既存 F58 テスト (F58-01〜F58-13) には影響なし: 配当を入力しないシナリオでは v2.0 と同一動作

UI 側の実装 (PR #402):

• webapp_client/src/cockpit/RequiredRevenuePanel.tsx に panel-local の desiredDividendAnnual ドロップダウンを追加
• シナリオの inputs.dividendAnnual (cockpit 全体の配当ドロップダウン) とは独立: MAS-058 健全性診断パネル内では別の配当額で what-if 試算が可能

今後の拡張 (実装スコープ外・将来 PR):

• dividendMixRatio (役員報酬総額に対する配当比率) を入力に追加し、必要年商再計算時に役員報酬と配当の最適配分を逆算する MAS-058 v2 機能 — MAS-066 とは別軸の追加開発案件
• MAS-067 マルチイヤー連携時に各年の配当方針 (ステップアップ / 一定 / ステップダウン) を入力できる UI — F67_DIVIDEND_INTEGRATION_ENABLED フラグで段階導入

設計原則

1. 二分探索なし: 年商は input で固定 → _computePLSnapshot_ で 1 回計算 → 6 制約をそれぞれ判定するだけ。binding 制約の入れ替わりが構造的に発生しない
2. 判定形式: judgments[key].ok (boolean) と op (比較演算子) と label (UI 表示文言) を返却 → SPA 側で表形式に整列して表示
3. 複数年呼出は SPA 側で実施: API 自体は 1 点評価。Y1-Y5 期末 matrix は SPA 側で evaluateScenarioHealth を Y1-Y5 各年の input を変えて 5 回呼ぶ
4. adversarial input への防御: _validateInput_ で desiredAnnualIncome > 0 / cogsRate ∈ [0, 1) / fixedCostAnnual >= 0 を確認

Y1-Y5 期末 matrix を SPA 側で構成する流れ（PR #400 RequiredRevenuePanel.tsx）

各年で input を変化させながら evaluateScenarioHealth を呼ぶ:

ランウェイ評価の使い分け（PR #400 確定）:

• 6 制約 matrix 用: 期初累積純資産（前期末）÷ monthlyBurn → 「期初時点で X ヶ月持つか」評価
• 投資余力テーブル用: 期末累積純資産（期初 + 当年単年純資産増）÷ monthlyBurn → 「期末時点で追加 X 円支出可能か」評価
• monthlyBurn 計算: (固定費 + 役員報酬 + 法人社保) / 12 （旧 v1.x の固定費のみは廃止）

MAS-057 cockpit 統合（PR #400・配置と default）

📁 以下 Step 2-4 は副機能（折りたたみ表示）の仕様: v1.0-v1.2 で書かれた二分探索ソルバー（solveRequiredRevenue）と Min/Healthy/Buffered 3 段階出力、必要人月単価の記述。v2.0 では UI 上「折りたたみ」になり主機能ではないが、API は維持されキャパシティ ギャップ分析（単価 × 稼働率 vs 必要年商）として発展拡張されている。注意事項 #14: 二分探索モードでは binding 制約の入れ替わりが発生しうる（v2.0 主機能では発生しない）。

Step 2 — ソルバーアルゴリズム（二分探索）

「希望年収 + 健全性 6 制約」から「最低必要年商」を求める問題は、年商に対して単調（年商を上げると黒字化・営業利益率・留保率はすべて改善方向）であるため、二分探索で解析的に収束可能。Monte Carlo や勾配降下法は不要。

// 400_domain/445_required_revenue_solver.js (純粋関数)

/**
 * 希望年収と健全性制約から必要年商を逆算する。
 *
 * @param {Object} input
 * @param {number} input.desiredAnnualIncome  希望年収（円）
 * @param {number} input.cogsRate             原価率（0-1）
 * @param {number} input.fixedCostAnnual      年間固定費（円・役員報酬を除く）
 * @param {number} input.monthlyFloor         月額報酬の下限（生活要件・円）
 * @param {boolean} input.isOver40            40 歳以上フラグ（介護保険料）
 * @param {Object} input.tierMap              SocialInsuranceTierRepository.findAsMap()
 * @param {Object} [input.constraints]        健全性制約（未指定時は F58_* から取得）
 * @returns {{minimum:number, healthy:number, buffered:number, breakdown:Array}}
 */
function solveRequiredRevenue(input) {
  var constraints = input.constraints || _loadConstraintsFromSysParams_();

  // 探索範囲: 下限 = 希望年収 + 固定費（絶対最低）/ 上限 = 希望年収 × 10
  var lower = input.desiredAnnualIncome + input.fixedCostAnnual;
  var upper = input.desiredAnnualIncome * 10;
  var epsilon = 10_000; // 1 万円精度で収束

  var minimum = _binarySearch_(lower, upper, epsilon, function (revenue) {
    return _checkMinimum_(revenue, input);  // 制約 #1 のみ（赤字回避）
  });

  var healthy = _binarySearch_(lower, upper, epsilon, function (revenue) {
    return _checkAllConstraints_(revenue, input, constraints);  // 制約 #1-#6 全充足
  });

  var buffered = Math.ceil(healthy * (1 + constraints.bufferRate)); // Healthy × 1.20

  return { minimum: minimum, healthy: healthy, buffered: buffered, breakdown: _buildBreakdown_(healthy, input) };
}

二分探索の収束保証: 年商 R に対して checkAllConstraints(R) は単調増加（より多い年商ほど制約を満たしやすい）なので、R_low:fail → R_high:pass の範囲で 30 回反復すれば 10 万円精度に収束（1e9 → 10^0 縮約）。

_checkAllConstraints_ の内部ロジック:

function _checkAllConstraints_(annualRevenue, input, c) {
  var p = _computePLSnapshot_(annualRevenue, input);  // P/L + 社保 + 税計算
  if (p.netProfit <= 0) return false;                                   // 制約 #1
  if (p.runwayMonths < c.runwayMin) return false;                       // 制約 #2
  if (p.emergencyReserveMonths < c.emergencyMin) return false;          // 制約 #3
  if (p.operatingMargin < c.operatingMarginMin) return false;           // 制約 #4
  if (p.retentionRate < c.retentionMin) return false;                   // 制約 #5
  if (p.laborShare > c.laborShareMax) return false;                     // 制約 #6
  return true;
}

_computePLSnapshot_ は MAS-057 エンジンを順呼び出しする（本案件で新規実装するのはソルバーと制約判定のみ）。

【v1.2 追記】v1 実装でのランウェイ計算の解釈（main 側 PR #376 で確定）:

spec 上部 §現在のコード「MAS-008 ランウェイ計算ロジック（現金残高 ÷ 月平均固定費）」を、MAS-058 v1 では input に「現金残高」が含まれないため以下のように解釈・実装している:

• 手元現金 = 年間税引後利益（前年度繰越なし前提）
• 月平均固定費 = fixedCost / 12（役員報酬と法人社保は同じ年商サイクルから支払われる前提で除外）

この解釈で齋藤 Baseline Y5 において労働分配率 65% が binding になり、spec 著者の hand calc（12M÷0.65=1,846万）と完全一致する数学的に正確な解（実装値 1,847 万）が得られる。役員報酬を burn に含めると runway が極端に厳しくなり、spec 期待値より +20% 上振れする結果になる（実装試行で確認済）。v2 で currentCashBalance を input に追加した場合は、実額ベースで再計算する仕様への拡張を検討（注意事項 #13 参照）。

Step 3 — 3 段階出力（Minimum / Healthy / Buffered）

3 レベル出力により、ユーザーは自分のリスク許容度に応じて目標を選べる。

5 カ年の年収軌跡に対する出力例（齋藤 Baseline: 原価 0 / 固定費 240 万 / 40 歳未満 / default 制約・v1.2 で main 側 PR #376 実装値ベースに更新）:

齋藤 Baseline の実年商 1,680 万は Y1 時点で Buffered 以上、Y3 では Healthy を上回るが Y5 では Healthy を下回る。→ 年商成長を意識しないと Y5 で年収 1,200 万が取れなくなる、という示唆（v1.2 実装値での再評価）。

Step 4 — コンサル/受託特有の示唆（必要人月単価）

年商 R を実現するための「1 人月あたり必要売上額」を逆算する。営業力・顧客ポートフォリオ設計の判断材料。

var MU_PER_YEAR_DEFAULT = 10;  // 稼働月数 default（10/12 = 83% 稼働想定・祝日+バケーション考慮）

function computeRequiredMonthlyRate(annualRevenue, utilizationMonths) {
  var months = utilizationMonths || Constants.getParam('F58_UTILIZATION_MONTHS', MU_PER_YEAR_DEFAULT);
  return {
    monthlyRate: Math.ceil(annualRevenue / months),
    utilizationMonths: months,
    utilizationRate: months / 12,
  };
}

例: Y5 Healthy 年商 1,847 万（v1.2 実装値）/ 稼働 10 ヶ月 → 必要月単価 約 185 万/人月。コンサル相場と照らして「現実的な顧客単価か」を判断できる。月単価 200 万を超えるとエンタープライズ案件比率を上げる必要がある、等のシグナル。

Step 5 — MAS-057 cockpit SPA 統合（v2.0 全面書換・PR #400 実装完了）

✅ PR #400 (commit ff61a29) で実装完了。当初の v1.x で計画していた「メニュー統合 + 独立シート出力」設計は廃止。実装は MAS-057 cockpit SPA 内のパネルとして完全統合する形に変更。

配置と起動 UX（PR #400 確定）

主機能 UI 構造（webapp_client/src/cockpit/RequiredRevenuePanel.tsx・909 行）

┌─ 🎯 シナリオ健全性診断（F-58 主機能）────────────────────┐
│ 希望年収: [600 万 ▼]  適用開始年: [Y1][Y2 ★][Y3][Y4][Y5]  │
├──────────────────────────────────────────────────────────┤
│ 📊 現状との累積純資産比較                                  │
│   累積範囲タブ: [~Y1][~Y2][~Y3][~Y4 ★][~Y5]             │
│   [比較テーブル: 現状 vs 希望年収シナリオ + 差分原因]      │
├──────────────────────────────────────────────────────────┤
│ 🛡️ 健全性 6 制約 × Y1-Y5 期末 matrix                     │
│   フロー: 黒字 / 営業利益率 / 留保率 / 労働分配率          │
│   ストック: ランウェイ / 緊急予備金                       │
│   緑列ハイライト = 希望年収を適用した年                   │
├──────────────────────────────────────────────────────────┤
│ 🪙 ヘルシーを保てる年間投資余力（Y1-Y5 期末残高ベース）    │
│   違反時は箇条書きで該当制約・現値・閾値を表示             │
├──────────────────────────────────────────────────────────┤
│ ▼ 副機能: 必要年商の逆算 + キャパシティ ギャップ分析（折りたたみ）│
│   Min / Healthy / Buffered の 3 段階                       │
│   想定貢献年商 = 月額単価 × 稼働率 × 12                    │
│   単価アップ案 / 稼働率アップ案（100% 超は警告）           │
└──────────────────────────────────────────────────────────┘

MAS-057 cockpit 全体への副次変更（PR #400）

前回選択シナリオ/プリセットの自動復元:

localStorage に最後に選択した名前を記憶し、cockpit 起動時に自動ロード。

ScenarioBar / AssumptionsBar は起動時に該当キーを読み、対応するシナリオ・プリセットがまだ存在すれば自動的に呼び出す。「前提 × シナリオ」マトリクス試算の継続性を担保。

旧 Step 5 計画から廃止された項目

影響範囲

注意事項

1. MAS-057 計算エンジンの引数互換性維持: 本案件は SocialInsuranceTierEngine.calcPremiums / calcBonusPremiums / PersonalTaxEngine.calcIncomeTax を純粋呼出で使う。MAS-057 側のシグネチャを変更する改訂が入った場合、本案件も追従が必要（失敗ケース: 引数追加で戻り値形状が変わると MAS-058 の _computePLSnapshot_ が壊れる）。MAS-057 spec の変更履歴を追跡する。

2. 二分探索の単調性前提: 「年商を上げると全制約が緩む」という単調性は、原価率が一定 と 固定費が年商非依存 の条件下でのみ成立する。原価率が年商依存（規模の経済）のシミュレーションを後から入れると単調性が崩れ解が非一意になるため、cogsRate は単一値入力に限定する（v0.x で拡張判断）。

3. 月額下限制約で解なしのケース: monthlyFloor × 12 > desiredAnnualIncome だと「月額下限を守れない配分」になり solver は希望年収自体が実現不能と判定すべき。このケースは前処理でバリデーションし、ユーザーに「月額下限 50 万 × 12 = 600 万より希望年収が低いため、希望年収の引き上げか月額下限の引き下げが必要」と返す。

4. 二分探索の収束失敗 = 解なし: upper = 希望年収 × 10 でも健全性制約 6 項目を充足しない場合（例: 固定費 1 億円 × 年収 1,200 万希望）、Healthy 解は存在しないと判定して null を返す。Minimum のみ返却し、UI 側で「Healthy 圏は到達不能・事業構造を見直してください」と警告表示。

5. 失敗パターン #18-#20 遵守: 関数名 solveRequiredRevenue / computeRequiredMonthlyRate は既存命名と整合（動詞 + 目的語）。パッケージ名・API 名の造語禁止。MAS-057 エンジンへの呼出は Read で裏取りしてから使う。

6. 失敗パターン #25 遵守: MAS-048（採用 TCO & BEP）と対称な構造を保つ。MAS-048 が「採用 1 人の必要売上 BEP」を計算するのに対し、MAS-058 は「役員報酬の必要売上 BEP」。両者の計算エンジンは同じ Repository パターンで実装する。

7. 業態 default の一人法人想定: 本 spec の default（ランウェイ 6 / 労働分配率 65% 等）はコンサル/受託一人法人前提。商用化で複数業態を扱う際は 03_sys_params の業態別プリセット機構を別案件で追加する（MAS-058 v2 候補）。

8. MAS-003 KPI ダッシュボードとの整合: MAS-058 で Healthy 判定した年商・年収で実運用を開始したら、MAS-003 KPI が赤色にならないことを実機検証する（「Healthy なのに MAS-003 赤」は閾値不整合）。

9. MAS-056 対話 Tool 登録時の権限設計: MAS-056 Phase 2 で Tool 登録する際、個人資産額（B/S 統合データ）を含む計算になるため、MAS-056 Phase 3 の AES 暗号化基盤が前提。MAS-056 Phase 1/2 段階では MAS-058 Tool は法人データのみで呼出とする。

10. 失敗パターン #26 遵守: appsscript.json の OAuth スコープは変更不要（既存スコープ内で完結）。

11. 【MAS-333 反映】Causal AI（do-calculus エンジン）は v1 で不採用: 本案件のソルバーは決定論的二分探索のみ。Causal Forest / DoubleML / SCM 等の因果推論エンジンは v1 で組み込まない。理由は (1) SMB データ量 N<100 で推定誤差が経営判断水準に達しない、(2) 観察不能 confounder で back-door が塞ぎきれず推定値が systematically biased、(3) arXiv 2506.00844 / 2506.21215 等の 2025 年最新研究が「LLM に causal discovery を直接させるべきでない・Non-Decisional Support に限定すべき」と明確に提言している。ただし DAG 思考フレーム（経営者主導でエッジを描き弾力性を入力する決定論的 what-if）は採用する（Pearl Level 1.5 相当）。詳細は docs/_internal/research_prompts/RQ-035_*_synthesis.md 参照。

12. 【MAS-333 反映】LLM に計算結果を復唱させない: 本ソルバーが返す数値（必要年商 Min/Healthy/Buffered・人月単価 等）は MAS-056 / MAS-059 等の上位 UI 層で LLM の Function Calling 応答として直接ユーザーに渡す。LLM テキスト応答中で数値を復唱させると hallucination で桁が変わるリスク（Financial Planning Gone Wrong 事例: ローン月額 1,350 → 850 誤算）。LLM は「なぜこの提案か」「何を見て判断したか」の自然言語生成のみ担当。Air Canada v. Moffatt（2024 BCCRT 149）型の運営者責任を最小化するための法的設計上の最重要原則。

13. 【v1.2 追記・v2.0 で廃止】v1 ランウェイ解釈の制限: 本案件 v1 は currentCashBalance を input に取らないため、ランウェイ = 年間税引後利益 ÷ 月平均固定費（役員報酬・法人社保除く） の概算で代用する。 → v2.0 で月 burn 計算式を変更（注意事項 #15 参照）。v2.0 では月 burn = (固定費 + 役員報酬 + 法人社保) / 12 に統一し、教科書的「ランウェイ」概念に整合させた。旧解釈（固定費のみ）は副機能（二分探索）の Healthy 解算出時のみで残存している（齋藤 Baseline Y5 Healthy 1,847 万との互換維持のため）。

14. 【v2.0 追記】binding 制約の入れ替わりは副機能でのみ発生: 副機能（二分探索ソルバー）では「Y3 で労働分配率 binding → Y5 で営業利益率 binding に交代」のような binding 制約の入れ替わりで Healthy 解の指標が成り行き改善する直感的でない挙動が起きうる。これは「6 制約をすべて満たす最小年商」を探索する以上、各年で binding 制約が変わるのは数学的に自然だが、ユーザーには「Y3 の数字が Y5 で勝手に良くなった」と見える。v2.0 主機能（evaluateScenarioHealth・1 点評価）では発生しないため、UI の主軸は健全性診断パネル側に置き、二分探索結果は副機能の折りたたみで補助的に提供する設計とした。

15. 【v2.0 追記】月 burn 計算式の変更（旧 v1.2 → v2.0）: 旧 v1.2 では月 burn = 固定費 / 12（役員報酬と法人社保を除外）だったが、v2.0 では月 burn = (固定費 + 役員報酬 + 法人社保) / 12 に変更（PR #400）。理由: (a) 教科書的「ランウェイ」概念と整合（事業継続に必要な月次支出すべてを含める）、(b) MAS-057 cockpit Step 6 の累積純資産・実効負担率と分母をそろえる、(c) 経営者直感「役員報酬を払えなくなったら法人破綻」と一致。旧 v1.2 期待値（Y5 Healthy 1,847 万）は副機能（二分探索）の労働分配率 65% binding ケースで維持しているため、F58-01〜F58-13 単体テストは引き続き PASS する。

16. 【v2.0 追記】TDZ エラー（Temporal Dead Zone）: useMemo factory 内で参照する isError ヘルパーを const arrow function で後ろに宣言すると初回 render で TDZ エラーが発生する。PR #400 実装中に発見された再発防止メモ。対処: ヘルパー関数は useMemo 呼出より前に宣言する、または function 宣言（hoisted）を使う。failure_patterns.md への追加候補として記録。

エッジケース

実データ検証

1. 齋藤 Baseline（原価 0 / 固定費 240 万 / 40 歳未満 / default 制約）での期待値

v1.2 で実装値ベースに更新（main 側 PR #376 / commit d459649 の Step 1-4 Domain 実装結果反映）。実装値は spec 著者の hand calc（v1.0/v1.1 記載値）より平均 -14% 低く、原因は spec hand calc に含まれる padding 余力分の差。実装側は労働分配率 65% binding（Y5 で laborShare = 0.6497 ≒ 0.65）の数学的に正確な解を返す。±20% 以内で一致を合格基準とする（v1.0 の ±5% から実装精度に合わせて緩和）。

Y2 / Y4 は実測未取得（Y1/Y3/Y5 の実測から補間）。テスト追加時に実測値で update。

手計算のロジック（Y5 Healthy の検証）:

• 希望年収 1,200 万（月額 100 万）→ 法人社保合算 188 万（MAS-057 Y5 A の実計算値）
• 固定費 240 万
• 役員報酬 + 法人社保 + 固定費 = 1,200 + 188 + 240 = 1,628 万
• 労働分配率 65% 制約 → 粗利 ≥ 1,200 ÷ 0.65 = 1,846 万 → 年商 ≥ 1,846 万（原価 0 想定）
• 営業利益率 10% 制約 → 年商 × 0.10 ≤ (年商 - 1,628 万) → 年商 ≥ 1,809 万
• 留保率 20% 制約 → 営業利益 × 0.80 ≥ 0.20 × 税引後利益... → 最も厳しい制約は労働分配率
• → 実装値 1,847 万は労働分配率 65% binding に完全一致（12M÷0.65=1,846万・差は四捨五入のみ）。spec v1.0 で記載の概算 2,150 万は手計算時の padding 余力分で、実装側は数学的に正確な解を返す。

実装時に手計算と乖離が 20% 超なら spec 側の試算ロジックを見直す（v1.2 で許容幅緩和）。

2. MAS-003 KPI ダッシュボード閾値との整合確認

Healthy 解で動作中の数値を 93_kpi_dashboard に反映し、以下を確認:

3. 業界ベンチマーク（SPI Research 2025）との比較

• コンサル業中央値 EBITDA 9.8% → MAS-058 営業利益率 default 10% と整合（MAS-051 spec で既定義）
• Billable Utilization 68.9% → MAS-058 稼働月数 default 10/12 = 83% は理論値（実運用で 70% 程度に補正）

4. MAS-057 年収最適化結果との相互検証

MAS-058 Healthy 年商で MAS-057 Phase 1/1.5 を順方向実行 → MAS-058 で指定した希望年収が手取り最大化ポイントと一致することを確認（解の相互整合性）。

5. エッジケース検証（単体テスト）

単体テスト F58-01 〜 F58-13 を 901_test_runner.js に追加。エッジケースセクションの 13 項目それぞれを 1 テストケースとして実装。

関連ドキュメント

人間が検討すべき事項

実装着手前に決定が必要な論点を列挙。

1. 健全性制約 6 項目 default の業態別調整基準: 本 spec の default（ランウェイ 6 / 労働分配率 65% 等）はコンサル/受託一人法人前提。SaaS / 物販 / 製造業 など他業態向けプリセットを v1 時点で用意するか、v2 に持ち越すか。商用化時期を見据えた判断が必要。

2. 稼働月数 default（10 vs 11 vs 12）: F58_UTILIZATION_MONTHS のデフォルト値。10 は祝日 + バケーションを控えめに見積もった保守値、11 は業界慣例、12 は理論値（稼働率 100%）。一人法人コンサルの実態調査データ（Toggl Track 等）で決めるべきだが、MAS-218 タイムトラッキング未着手の現状では 10 を暫定採用。

3. 二分探索 vs 解析解: 二分探索は O(log N) で十分高速（30 反復で 10 万円精度）だが、解析解（健全性制約 6 項目の連立不等式を代数的に解く）も理論上可能。可読性・保守性で二分探索採用を推奨するが、Phase 3 UI のリアルタイム応答性能（< 100ms）が問題になる場合は解析解検討。

4. MAS-057 Phase 3 UI 統合 vs 独立メニュー: MAS-057 Phase 3 のドロップダウン UI（ai_agent_tips.md §7 準拠）に「年商を逆算する」toggle として組み込むか、独立メニュー 💰 必要年商シミュレーション にするか。UX 上は MAS-057 統合が自然だが、MAS-058 独立実装 → MAS-057 Phase 3 着手時に統合する段階的実装が実務的。

5. MAS-056 対話 Tool 登録のタイミング: MAS-056 Phase 2（マルチシナリオ永続化）で Tool 登録するか、Phase 3（個人 B/S 統合）で統合するか。Phase 2 で法人データのみの呼出を許可し、Phase 3 で個人データ連携を解禁するのが段階実装として妥当。

6. 98_sim_required_revenue シートの DDL 管理化: 現状 spec は動的生成（DDL 外）とした。MAS-057 Phase 3 で UI 統合した際にシート化不要になる可能性もある。DDL 管理に格上げするタイミング要判断。

7. 原価率の年商依存（規模の経済）対応: 注意事項 #2 で記載の通り、現状は cogsRate 単一値。受託開発では年商規模で外注比率が変化するケースあり。v1 では単一値固定、v2 で配列入力（cogsRate: [{upTo, rate}]）に拡張するか。

8. 業態プリセット機構の切り出し（MAS-058 v2 候補）: 03_sys_params の F58_* キー 6 個を業態ごとに切替える仕組み。マルチテナント（MAS-219 ADR-0009 連携）時の前提になる。

9. 労働分配率 default 65% のコンサル業妥当性: 業界ベンチマーク数値の確認が必要。SPI Research 2025 では EBITDA 9.8% / Billable Utilization 68.9% の記載はあるが、労働分配率（役員報酬 / 粗利）の直接的ベンチマーク値は未確認。税理士・業界団体データ取得を別途。

10. MAS-003 KPI 閾値との更新同期フロー: MAS-058 の default を変更したら MAS-003 の条件付き書式閾値も同期変更が必要。両者を同じ Constants.HEALTH_THRESHOLDS 等に集約し、1 箇所変更で両方反映する設計を検討。

11. MENU 配置カテゴリ: 現状 spec は 📊 マート更新 に配置。シミュレーション系なので 🔧 開発・設定 or 新規カテゴリ 🎯 目標逆算 の方が適切か。MAS-011/MAS-012/MAS-048/MAS-049 等の他シミュレーション系との並びで要判断。

12. 賞与配分 40% 超の税務否認警告: solver が最適化過程で 40% 超の賞与配分を提案した場合、結果を返却するが UI で警告表示（BRD §5 / §8 継承）。警告ロジックを MAS-057 と共通化するか MAS-058 独立にするか。

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

14. 【v2.0 追加】適用開始年 default の選定: 現状 default は Y2 から（翌年から希望年収を取る運用想定）。一方で「Y1 から即適用」を default に変更する案もありえる（ユーザーが今すぐ希望年収を取りたい意図で操作することが多ければ）。実運用データ収集後に再判断（β 版で適用開始年の選択分布を計測する）。

15. 【v2.0 追加】二分探索副機能のコンテキスト位置付け: 副機能（折りたたみ）の二分探索ソルバーは「キャパシティ ギャップ分析」（単価 × 稼働率 vs 必要年商）として価値が拡張されたが、主機能と機能境界が曖昧になりがち。1 つの spec/UI に主・副の両方を持つ複雑性を正当化するか、副機能を将来別案件（MAS-072 候補: キャパシティ プランナー）に切出すかは v2.x で再判断。

16. 【v2.0 追加】MAS-067 マルチイヤー計画との健全性診断ロジック共通化: MAS-067 spec でも「ステージ準備度 5 軸モデル」で類似の健全性評価が登場する。evaluateScenarioHealth API を MAS-067 でも再利用するか、MAS-067 独自エンジンを別実装するかの判断が MAS-067 着手時に必要。両者の制約定義の差分（MAS-058: 6 制約 / MAS-067: 5 軸）を整理して共通基盤化検討。

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

Claude Opus 4.7（1M context）推奨。純粋関数ソルバー + MAS-057 エンジン結合で中〜高難易度。

## 案件
MAS-058 — 希望年収逆算型 必要年商シミュレーター（MAS-057 Phase 1/1.5 の逆問題）

## 事前調査（必ず Read する）
1. `docs/dev/dev_mas-058_required_revenue_solver.md` 全文（本仕様書）
2. `docs/brd_solo_ceo_financial_navigator.md` §4.1 事業プロファイル
3. `400_domain/442_social_insurance_tier_engine.js` 全文
   — SocialInsuranceTierEngine / PersonalTaxEngine の関数シグネチャと戻り値形状を確認
4. `docs/dev/dev_mas-057_solo_ceo_cockpit.md` §実データ検証（齋藤 Baseline の期待値）
5. `000_infra/002_constants.js` — Constants.TAX_RATES.brackets / INCOME_TAX_BRACKETS / getParam
6. `docs/dev/dev_mas-048_hiring_tco_bep_simulator.md` — 対称実装の手本（Repository パターン）
7. `docs/dev/dev_mas-003_kpi_dashboard.md` — 閾値整合確認
8. `docs/_internal/failure_patterns.md` #18-#20 / #25 / #26

## 実装対象

1. `400_domain/445_required_revenue_solver.js` 新規（純粋関数・IIFE 名前空間パターン）:
   - `RequiredRevenueSolver.solveRequiredRevenue(input)` — メイン API
   - `RequiredRevenueSolver.computeRequiredMonthlyRate(annualRevenue, months)` — 必要人月単価
   - 内部ヘルパ: `_loadConstraintsFromSysParams_` / `_binarySearch_` /
     `_computePLSnapshot_` / `_checkMinimum_` / `_checkAllConstraints_` / `_buildBreakdown_`
   - MAS-057 エンジンを順呼出: SocialInsuranceTierEngine.findTier/calcPremiums/calcBonusPremiums /
     PersonalTaxEngine.calcIncomeTax/calcResidentTax / Constants.TAX_RATES.brackets 法人税

2. `000_infra/002_constants.js` の `MENU_DEFINITION`:
   - `📊 マート更新` カテゴリに「💰 必要年商シミュレーション (希望年収逆算)」エントリ追加
   - funcName は `openRequiredRevenueSimulator`（445_required_revenue_solver.js 内で定義）

3. `400_domain/445_required_revenue_solver.js` に UI エントリ `openRequiredRevenueSimulator()`:
   - HTML サイドバー or ダイアログで入力フォーム（希望年収 Y1-Y5 / 原価率 / 固定費 / 月額下限 / 40 歳フラグ）
   - 結果を `98_sim_required_revenue` タブ（動的生成）に書き出し

4. `03_sys_params` の 6 キー追加（default 値はシード or Constants.getParam の第 2 引数で対応）:
   - F58_RUNWAY_MIN_MONTHS = 6
   - F58_EMERGENCY_RESERVE_MONTHS = 3
   - F58_OPERATING_MARGIN_MIN = 0.10
   - F58_RETENTION_RATE_MIN = 0.20
   - F58_LABOR_SHARE_MAX = 0.65
   - F58_BUFFER_RATE = 0.20

5. `900_test/901_test_runner.js` に単体テスト F58-01〜F58-13:
   - 齋藤 Baseline Y1-Y5 の Minimum/Healthy/Buffered 期待値検証（±5% 許容）
   - エッジケース 13 項目（希望年収 0 / 原価率境界 / 月額下限違反 / 収束失敗 等）

## 動作確認（§実データ検証の 5 項目）
1. 齋藤 Baseline Y5 希望年収 1,200 万 → Healthy 約 1,847 万（±20%・v1.2 実装値）
2. MAS-003 KPI ダッシュボードと閾値整合（Healthy = MAS-003 緑色）
3. SPI Research 2025 ベンチマーク（営業利益率 9.8%）との整合
4. MAS-057 Phase 1/1.5 順方向実行で手取り最大化点が一致
5. エッジケース 13 項目すべて想定通りの挙動

## Phase デプロイ手順
1. dev 環境で `npm run push:dev` → メニュー「💰 必要年商シミュレーション」実行
2. §実データ検証 5 項目で Go/No-Go 判定
3. Go なら `npm run push:prod`（prod は F58_* キー未設定で default 動作）
4. コミットメッセージ: `feat(F-58): 希望年収逆算型 必要年商シミュレーター (ソルバー + 齋藤 Baseline 検証)`

## failure_patterns チェック
- #18-#20: 関数名 solveRequiredRevenue / computeRequiredMonthlyRate を Read で裏取り（既存に同名なし確認）
- #25: MAS-048 HiringTcoSimulator と Repository パターン対称
- #26: appsscript.json は変更なし

推奨実行モデル

変更履歴