この記事で分かること

  • 粒度設計＝「どこまで細かく作るか」を意図的に決める作業であること
  • 細かくすべきドライバーと、まとめてよい項目を切り分ける判断基準
  • 整数設例で見る、粒度を上げても結論が動かない領域の存在
  • 過剰な精緻化（オーバーエンジニアリング）が招く実害

30秒で分かる定義

モデルの粒度設計（Model Granularity、読み方：もでるのりゅうどせっけい）とは、財務モデルの各項目をどこまで細かく分解して予測するかを、意思決定への影響度に応じて意図的に決めることです。詳細度の設計とも呼ばれ、過剰な細分化はオーバーエンジニアリングと呼ばれて戒められます。粒度は細かいほど良いものではありません。結論を動かすドライバーには労力を集中させ、動かさない項目は思い切ってまとめる——この配分こそが実務家の腕の見せどころです。

なぜ実務で重要なのか

案件には期限があります。1週間でIC資料を仕上げなければならないとき、200のSKUを個別に予測する時間はありません。仮に時間があっても、細分化した分だけ前提の数が増え、更新のたびに200か所を触ることになり、案件終盤の修正に耐えられなくなります。逆に、収益の8割を占める主力事業を「売上成長率5%」の一行で済ませてしまえば、その5%の根拠を問われた瞬間に議論が終わります。粒度設計とは、限られた時間をどこに投下するかという資源配分の問題です。売上予測とドライバー設計で扱う「成長率5%から卒業する」という発想も、この配分判断の一部です。

計算式（または仕組み）

粒度を上げるべきかどうかは、次の3つの問いで判断できます。

① その項目は結論（企業価値・IRR・EPS）を有意に動かすか
② 分解した先の前提について、根拠となるデータを実際に持っているか
③ 分解することで、相手（IC・クライアント）との議論が具体的になるか

3つすべてがYesなら分解します。特に②が重要で、データが無いのに分解すると、根拠の無い前提を数だけ増やすことになります。「製品Aの数量成長5%、製品Bは4%」と細かく書いても、その差の根拠が無ければ、全体を4.5%と置いたのと情報量は変わりません。むしろ、精緻に見えることで前提の脆弱さが隠れる分、有害です。

項目推奨される粒度理由
主力事業の売上数量×単価まで分解結論への影響が最大で、議論の的になる
人件費人員数×単価、または売上比率固定費の中心で、シナジー議論の対象になる
その他販管費売上比率で一括個別分解しても根拠となるデータが無い
その他流動資産・負債横置き、または売上比率金額が小さく、結論を動かさない

整数設例で確認する

設例（架空数値）。単位は百万円。売上高12,000の会社を、2つの粒度で予測することを考えます。

粒度A：200SKUを個別に予測。1SKUあたりの平均売上は 12,000 ÷ 200 ＝ 60 です。仮に1つのSKUの予測を10%誤ったとしても、影響は 60 × 10% ＝ 6 にすぎず、全社売上に対して 6 ÷ 12,000 ＝ 0.05% です。200個の前提を管理する労力に対して、1つあたりの重要性はほぼゼロに等しいことが分かります。

粒度B：3つの製品カテゴリで予測。カテゴリA 6,000／カテゴリB 4,000／カテゴリC 2,000とします。ここでカテゴリAの成長率を10%誤ると、影響は 6,000 × 10% ＝ 600、全社売上の 600 ÷ 12,000 ＝ 5% に達します。一方、カテゴリCを同じく10%誤っても影響は 2,000 × 10% ＝ 200、全社の約1.7%です。

この比較が示すのは明快な事実です。労力を投下すべきはカテゴリA一点であり、200SKUへの分解はほぼ純粋な浪費です。実務では、カテゴリA（全体の50%）については数量と単価まで分解して議論の材料を作り、カテゴリCとその他は一括して率で置く、という配分を選びます。

さらにEBITDAへの波及も確認します。EBITDAマージンを10%とすると、カテゴリA予測の600のズレはEBITDAで 600 × 10% ＝ 60 の差になります。EV/EBITDA 8.0倍で評価しているなら事業価値では 60 × 8.0 ＝ 480 の差です。同じ計算をカテゴリCで行うと 200 × 10% × 8.0 ＝ 160 にとどまります。結論への影響を金額で示せば、どこに時間を使うべきかは議論の余地なく決まります。

投資判断への影響

粒度設計の失敗は、2つの方向で投資判断を誤らせます。第一に、粒度が粗すぎる場合、事業の実態が数字に反映されず、リスクが見えません。主力製品の特許が数年内に切れる、主要顧客との契約が更新期を迎える——こうした事象は、事業を一本の成長率で括った瞬間にモデルから消えます。第二に、粒度が細かすぎる場合、前提の数が多すぎてどの前提が結論を左右しているのか誰も把握できなくなります。感応度分析を回そうにも、振るべき変数を選べません。

実務では、粒度を決める前に感応度分析の設計を先に考えるのが有効です。「どの3つの前提について、投資委員会に感応度を示すか」を先に決めれば、その3つは細かく、それ以外は粗く、という配分が自動的に導かれます。感応度分析の設計は感応度分析・シナリオ分析の作り方で扱っています。

財務モデル・Excelでの使い方

粒度をコントロールするための実装上の工夫です。

  • 集計行を必ず設ける。細かく分解した場合も、カテゴリ計・全社計の行を明示的に置き、3表へ接続するのは集計行だけにします。こうすれば、後から粒度を粗くしたくなったとき、下位の行を差し替えるだけで済みます
  • グループ化（アウトライン）で折りたたむ。詳細行はグループ化しておき、通常は折りたたんだ状態で保存します。レビュアーは全体像を見て、必要なときだけ展開できます
  • 粒度の異なるブロックを混在させない。数量×単価で組む事業と率で置く事業を同じブロックに並べると、行の意味が読めなくなります。ブロック見出しで明確に区切ります
  • 時間軸の粒度も設計対象です。年次で足りるか、四半期・月次が必要かは、意思決定の内容で決まります。資金繰りの逼迫が論点なら月次が必要ですが、5年後の企業価値が論点なら年次で十分です。判断の考え方は四半期・月次モデルへの展開を参照
  • 粒度を後から上げる余地を残す。集計行経由で3表へ繋いでおけば、詳細行を追加してもモデル全体の構造は変わりません。モデルの三層構造が守られていれば、この拡張は容易です

この用語をExcelで「組める」状態にする

主力事業だけ数量×単価まで分解し、残りは率で一括する混在構造を集計行経由で3表へ繋ぎ、後から粒度を変えられるモデルを設計できるようになる。

3表連動モデルの教材で実装する →

実務家が確認するポイントとよくある誤解

誤解1：「細かいモデルほど精度が高い」→ 正しくは、精度を決めるのは前提の質であって行数ではありません。根拠の無い前提を200個並べても、根拠のある前提3個に精度で劣ります。

誤解2：「クライアントに詳細を求められたら細かくすべき」→ 正しくは、詳細を求める理由を確認するのが先です。「主力製品の内訳が知りたい」のか「全体の根拠が薄いと感じている」のかで、打ち手は全く変わります。後者なら、分解ではなく前提の裏づけを厚くするのが正解です。

誤解3：「粗く作れば速い」→ 正しくは、粗すぎるモデルは後で必ず作り直しになります。結論に効くドライバーだけは最初から分解しておくべきで、そこを省くと議論のたびにモデルを触ることになります。

確認ポイント：モデルの前提数が50を超えたら、一度立ち止まって「このうち結論を1%以上動かす前提はいくつあるか」を数えてみます。多くの場合、答えは5個以下です。残りは横置きにできないかを検討する余地があります。

日本実務での扱い

日本企業から提供される事業計画は、部門別・製品別に細かく積み上げられているのが一般的で、Excelのシート数が数十枚に及ぶこともあります。この詳細さは現場の実感を反映している点で価値がありますが、そのままモデルに取り込むと更新不能になります。実務では、受領した積み上げ計画をまず結論への寄与度で並べ替え、上位を残して下位を集約するという粒度の再設計を行います。このとき、どの積み上げをどうまとめたかを前提一覧の出典欄に記録しておかないと、後日マネジメントとの数字の突合ができなくなります。前提の記録方法は前提一覧シートを参照してください。

また、日本の会計基準に基づく開示では、セグメント情報の区分がマネジメント・アプローチにより社内管理区分と対応しています（2026年7月時点）。外部からモデルを組む場合、開示されているセグメントより細かい粒度で予測しても検証手段が無いため、セグメントが事実上の粒度の上限になります。この制約は、上場企業を対象とするバリュエーションでは常に意識すべき点です。セグメント情報の読み方はセグメント情報の読み方で解説しています。

面接・モデルテストで問われるポイント

Q：3日でモデルを作れと言われたら、どこに時間を使いますか？
「まず結論を動かす変数を特定します。多くの案件では、売上ドライバー、EBITDAマージン、そして評価であれば割引率か出口倍率の3つに集約されます。この3つについては、数量×単価やコスト構造まで分解して根拠を作り、感応度も示せる状態にします。それ以外の項目——その他販管費、その他資産負債、非事業性の項目——は売上比率か横置きで処理します。全項目を均等に作り込むと、結論に効かない部分で時間切れになり、肝心の議論に耐えられないモデルが出来上がるためです。」

深掘りでは「どうやって重要なドライバーを特定するか」「粒度を上げるべきだと判断する具体的な基準」が問われます。

よくある質問（FAQ）

Q. 粒度が適切かどうかを客観的に判断する方法はありますか？
A. 各前提を±10%動かしたときの結論への影響額を計算し、大きい順に並べる方法が有効です。上位に来た前提が粗い粒度で置かれているなら分解を検討し、下位の前提が細かく分解されているなら集約を検討します。この一覧はトルネードチャートとして可視化できます。

Q. モデルを作った後で粒度を変えるのは大変ですか？
A. 集計行を経由して3表へ接続していれば、比較的容易です。逆に、詳細行から直接3表の各項目へ参照が飛んでいると、粒度の変更はモデルの再構築に近い作業になります。この意味で、粒度変更のしやすさは構造設計の質に依存します。

出典・参考（2026-07-21確認）

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための架空数値です。