短期キャッシュフロー予測は「当面の資金残高がいつ、どれだけ上下するか」を、現場で更新できる形で可視化するためのモデルです。ここでは、今日から作り始められる最小構成と、破綻しやすい前提条件の置き方を整理します。
1. まず決めるべき3つ：粒度・地平・基準残高
- 粒度：日次 / 週次。運用負荷と意思決定速度で決めます。資金繰りの意思決定が週次なら週次で十分なことも多いです。
- 地平：2〜13週が一般的。資金ショートが起こり得る期間をカバーしつつ、入力可能な情報量に合わせます。
- 基準残高：予測開始日の実残高。ここがぶれると全ての精度が崩れるので、銀行口座残高の取得タイミングを固定します。
2. モデルの最小構造（レイヤー設計）
スプレッドシートでも実装できる「3レイヤー」を守ると、変更に強くなります。
- 前提（Assumptions）：入金サイト、支払サイト、締日、週末補正、税金の支払月など。
- ドライバー（Drivers）：売上、回収、仕入、給与、固定費、借入返済など、入出金の発生源を分解。
- 出力（Output）：日/週別の入金・出金・ネット・残高推移。意思決定に必要な粒度だけ表示します。
ポイント：前提と計算式を同じ表に混ぜると、更新のたびに壊れやすくなります。前提は「人が触る場所」、計算は「極力触らない場所」に分離します。
3. よく使う入出金カテゴリ（実務での落とし穴つき）
カテゴリは細かすぎると入力が止まり、粗すぎると原因分析ができません。まずは次の8〜12本から始め、必要に応じて分解します。
- 売上入金：請求・入金サイト、入金ずれ（遅延）を別行で管理できると強い。
- 仕入・外注支払：締日と支払日を明示。月末締め翌月末払い等は週次予測だと段差になりやすい。
- 人件費：給与、社会保険、賞与を分ける。賞与月は「単月の例外」として扱うのが安全。
- 固定費：家賃、SaaS、リース。契約更新の年次支払があるなら別途「一過性」に寄せます。
- 税金：消費税・法人税など。支払月が固定なら前提に落とし込みやすい。
- 借入関連：元本返済と利息は分離。返済日は銀行営業日補正の対象になりやすい。
- 投資/設備：金額が大きく、意思決定で動くため、シナリオのスイッチ候補です。
- その他の一過性：保険料、訴訟関連、補助金入金など。定常モデルに混ぜないのがコツです。
4. 「更新できる」運用ルールを先に作る
精度を上げるより先に、毎週回せる形にします。次のルールを最初から文章で固定するとブレにくいです。
| 項目 | 推奨ルール |
|---|---|
| 更新頻度 | 週1回（同じ曜日・同じ時刻に残高取得） |
| 確定と見込み | 直近1〜2週は確定（予定表/請求書）、それ以降は見込み（ドライバー） |
| 例外処理 | 一過性は専用カテゴリに集約し、次回更新で必ず消し込み |
5. 計算の基本：残高の再帰（シンプルで壊れない）
計算はできるだけ単純にします。残高は「前期残高＋ネットキャッシュ」でつなぐだけで十分です。
NetCash[t] = Inflow[t] - Outflow[t]
Balance[t] = Balance[t-1] + NetCash[t]
MinBalance = MIN(Balance[1..H])
複雑な回収/支払ロジックは、まず「いつ現金化するか」という日付付けの問題に分解し、ドライバー側に寄せるのが安全です。
6. 前提条件で事故りやすいところ（チェックリスト）
- 営業日補正：週末・祝日で入出金日がずれると、短期では見た目の谷が誤解を生みます。
- 締日効果：月末締めは週次グラフで段差に見える。意思決定単位と表示単位を揃えます。
- 税・賞与などの大型支出：定常費に埋めず、イベントとして明示します。
- 入金遅延：一律%で落とすより、主要顧客だけでも「遅延日数の前提」を持つと改善します。
次は、ローリング更新の設計に進みましょう。
テンプレを整えると、毎週の更新が短時間で回ります。
サイトの他の記事一覧は Kiji から参照できます。