キャッシュフロー予測：13週ローリング予測法

このガイドでは、会社の流動性を管理するための、シンプルでありながらCFO級の手法を提供します。13週のローリングキャッシュ予測を構築することで、週単位でキャッシュ・ランウェイを把握し、回収と支払いを戦略的にコントロールし、財務上のサプライズを排除できます。これは創業者のために作られたシステムです。このページでは、実際のモデルを提供します。サンプルデータ入りの数式対応ワークブックと、その最初の2週間の背後にあるサンプルBeancount台帳です（下のダウンロードを参照）。

このガイドがそうではない点が2つあります。予測は、あなたが入力する将来予想であり、会計上の実績は、台帳にすでに記帳された銀行取引です。下記の月曜日のルーティンでは、後者を前者に手動でコピーします。ここで自動的に同期されるものはありません。ワークブックにマクロや外部接続はなく、銀行やBeancountから自動的にデータを取得するステップもありません。

なぜ13週なのか？​

13週予測は、運用上のキャッシュ管理におけるゴールドスタンダードです。その理由はいくつかあります。

• 短期管理： おおよそ1事業四半期をカバーし、当面の流動性を明確に把握できます。この期間は、2〜3回の給与支払いサイクル、税金の納付、一般的な仕入先への支払い条件を含むのに十分な長さでありながら、精度と実効性を高く保つことができるほど短い期間です。
• 収入と支出の把握： この予測は「直接法」を使用し、現金の流入と流出のみに焦点を当てます。これは発生主義会計や収益性ではなく、実際に銀行口座に入金または出金されるものに関するものであり、予測が銀行残高に直接結びつくことを保証します。
• 静的ではなくローリング： これは一度きりの予算ではありません。毎週、終わった週を落とし、最後（13週目）に新しい週を追加し、前提条件を更新します。これにより、将来を見通す期間が一定に保たれ、予測が毎週の動的な習慣となります。

構築するもの​

1. 単一のスプレッドシート： システムの中核は、13列（第1週から第13週）と明確に定義されたセクション（期首残高、収入、支出、純キャッシュ、期末残高）を持つ1つのシートです。
2. カテゴリマッピング： 台帳から予測カテゴリへの取引をマッピングするためのシンプルなシステム（例：Stripeからのすべての支払いは「顧客からの入金」にマッピング、Gustoの支払いは「給与」にマッピング）。ワークブックのベンダーマッピングタブには、このマップがすでに組み込まれており、銀行/カードの二重計上防止ルールも含まれています。独自に作成するのではなく、これを使用してください。
3. 毎週のリズム： 予測を更新し、差異（予測と実績）を追跡し、財務上のしきい値に達したときにアクションを起こすための事前定義されたトリガーを備えた、繰り返し可能なプロセス。

スターターファイルをダウンロード​

空白のページから始める必要はありません。このガイドには、数式対応のワークブック（サンプルデータ入り）と、その最初の2週間の背後にあるサンプル台帳が含まれています。

• 13週予測ワークブック（XLSX、v1.0.0）— cash-flow-forecast-13-week-ja.xlsx。編集可能な前提条件、数式で連結された週、ベンダーマッピングタブ。青色のサンプルセルを独自の数値に置き換えてください。
• サンプル台帳と実績（Beancount台帳、.bean）— sample.bean。ワークブックの最初の2週間に対応する、計算済みのW1〜W2銀行実績を含むバランスの取れたサンプル台帳。

スターターファイルの仕組み（入力する前にお読みください）​

シート。 ワークブック（cash-flow-forecast-13-week-ja.xlsx、v1.0.0）には3つのシートがあります。

• 予測 — 日付が入った13週、前提条件、収入、支出、純/期末残高。
• ベンダーマッピング — ソースごとの銀行/カード現金カウントルールを含む、台帳→カテゴリのマップ。
• メモ — 仕組み、シナリオトグル、バージョン。ファイルがオフラインでも自己説明できるように、ジェネレーターから複製されています。

時間基準。 週は月曜日始まりで、W1は2026-09-14、W13は2026-12-07に始まります（予測の2行目。このモデルを採用する際はこれらの日付を編集してください。すべての数式は週相対であるため、チェーンは維持されます）。取引は、その転記日（月曜日から日曜日）を含む週に属します。

単位。 全体がUSD（数値形式#,##0）。サンプル企業は、85,000で開業するシードステージのSaaSであり、毎週の給与は0 / 11,000を交互に繰り返し、毎月の家賃、週900のローン自動支払いがあります。

入力するものと計算されるもの。 青色のセルは手動入力です。それ以外はすべて数式です。

• 入力：期首残高B5（85,000）、トグルB6/B7（1.0）、下限B8（40,000）、収入ベース（12〜14行目）、支出ベース（17〜26行目）、2行目の週の日付。
• 数式（列B、第1週で表示。後の週は列文字がシフトします）：期首残高B10 = $B$5（第2〜13週は繰り越し、例：C10 = B29）；総収入B15 = B12*$B$6+B13*$B$7+B14；総支出B27 = SUM(B17:B26)；純額B28 = B15-B27；期末残高B29 = B10+B28。
• 再計算は自動で、ファイルはfullCalcOnLoadを設定しているため、Excel、LibreOffice、Numbersは開いたときに再計算します（ファイルは計算済みの数式値を保存しません）。青色のセルを変更すると、13週すべてが動きます。たとえば、回収トグルB6を1.2に設定すると、W1の収入が12,200から14,600に、W1の期末残高が87,500から89,900になります。
• いつでもyarn generate:cash-flow-forecastで元のファイルを再生成できます（ジェネレーター：scripts/generate-cash-flow-forecast.py、ライター openpyxl 3.1.5。--verifyはファイルを再度開き、すべての合計セルが実際の数式を保持していることを検証します）。

サンプルとあなたのデータ。 すべての青色のセルにはサンプル番号が含まれています。これらは計算例であり、あなたのビジネスではありません。毎週、独自の数値に置き換えてください。2つのトグル（B6はすべての顧客からの入金をスケーリングし、B7はすべての前受金をスケーリング）のみが、シナリオプレイ用に一般的なままにすることを意図されています。サンプル台帳のW1〜W2実績は、構造上、ワークブックのW1〜W2サンプル予測と等しいため、そこでの予測と実績の差異はゼロです。それが照合の目標であり、あなたの帳簿に関する主張ではありません。

構造（必要な行）​

予測シートは、すべてのキャッシュフローを捉えるために、次の行で構成する必要があります。これは、ダウンロード内の予測シートのレイアウトです（収入は12〜14行目、支出は17〜26行目、合計は10/15/27〜29行目）。これを2番目の仕様ではなく、マップとして読んでください。

• 期首残高（これは前週の期末残高と一致している必要があります）

• 収入（入金）

  • 顧客からの入金： 既存の請求書（売掛金）から回収が見込まれる現金。
  • 新規受注/前受金： 13週間の期間内に成立する見込みの新しい取引からの前払い金。
  • その他の流入： 税金還付、利息収入、助成金など、入ってくるその他の現金。

• 支出（出金） — シートには10行（17〜26行目）があります：

  • 給与： 従業員への手取り額と雇用主負担の給与税すべてを含む、現金ベースの総コスト。
  • 契約社員/フリーランサー： 従業員以外への支払い。
  • クラウド/ホスティング（売上原価）： AWS、GCPなどの中核的なインフラストラクチャコスト。
  • SaaS/ツール： すべてのソフトウェアサブスクリプション。
  • マーケティング： 広告費、代理店手数料、その他のブランド関連コスト。
  • 家賃/オフィス： 物理的なオフィスコスト。
  • 法務/会計： 専門サービス料金。
  • 税金/手数料： 消費税の納付やその他の政府への支払い。
  • 債務返済： あらゆるローンの元本と利息の両方の支払い。
  • 一時費用： 毎年の保険料、保証金、ハードウェア/設備投資（ノートパソコン、機器）など、変動が大きく頻度の低い支払い。上記に専用の行がないものはすべてここに該当します。

• 純キャッシュフロー（= 総収入 − 総支出）

• 期末残高（= 期首残高 + 純キャッシュフロー）

ローリングの仕組み（ワークブックに組み込まれているとおり）​

ローリング予測のロジックはシンプルかつ強力で、ダウンロードでは予測シートに数式としてすでに組み込まれています（行番号は括弧内）。

• 期首残高（第1週） = 期首残高の前提 — セルB10 = $B$5。
• 期首残高（第n週） = 期末残高（第n−1週） — 例：C10 = B29（10行目、第2〜13週）。
• 総収入（第n週） = 顧客からの入金 × 回収トグル + 前受金 × 受注トグル + その他 — 例：B15 = B12*$B$6+B13*$B$7+B14（15行目）。
• 総支出（第n週） = 10のカテゴリ行の合計 — 例：B27 = SUM(B17:B26)（27行目）。
• 純キャッシュ（第n週） = 総収入 − 総支出 — 例：B28 = B15-B27（28行目）。
• 期末残高（第n週） = 期首残高 + 純キャッシュ — 例：B29 = B10+B28（29行目）。

毎週月曜日の朝のリズム（このワークブックを使用する場合）：

1. ウィンドウをロール： 予測全体を1週間前進させます。毎週の青色の入力を1列左にシフトし（旧第2週が新しい第1週になります）、最後の列をクリアし、2行目で新しい第13週として日付を設定します。繰り越し数式（C10 = B29、...）は自動的に再アンカーされます。新しい第1週の期首残高が先週の期末残高と等しいことをスポットチェックします。
2. 実績で更新： 先週の青色の予測セルを、下記のマッピングに基づくその週の実際の銀行取引で上書きします（クエリ、分割、貼り付けを手動で行います）。次に、その週の期末残高セルが、実際の合計銀行残高（Assets:Bank:Checking + Assets:Bank:Savings）と一致することを確認します。一致しない場合、間違っているのはマッピングであり、銀行ではありません。
3. 将来を再評価： 今後2〜4週間分の青色のセルを、最新の情報（新しく送信された請求書、予定されている仕入先への支払い、確定した給与支払日）で更新します。

Beancountから予測へのマッピング​

銀行キャッシュスコープ（二重計上を防ぐルール）。 毎週の実績は、Assets:Bank:*のみへの転記です。この1つのスコープで、2つの落とし穴の両方を解決します。

• クレジットカード： カードでの購入はLiabilities:CreditCard:*に転記され、銀行の現金は動かないため、請求時にはカウントされません。現金が流出するのは、決済時（銀行→カードへの支払い）の一度だけです。請求と決済の両方をカウントすると、同じ支出を2回カウントすることになります。サンプル台帳では、W1に420.00 USDのAmex SaaS請求（負債のみ、無視）と、600.00 USDの8月分明細の決済（カウント）があります。W1の素朴な「銀行流出+カード請求」合計は10,120.00 USDで、正確に420.00多く、ワークブックでは9,700.00をカウントします。
• 内部振替： 当座↔普通のスイープは、銀行側に2つの反対の記録があるため、このスコープ内ではゼロになり、収入と支出の両方から除外されます。サンプルの3,000.00 USD（W1）と1,500.00 USD（W2）のスイープは、そうでなければ両側をその分だけ膨らませることになります。
• 当然の帰結： 銀行側の記録をマッピングし、収益/費用の記録はマッピングしないでください。ローンの元本は費用ではありませんが、銀行からの流出ではあります（サンプルの900.00 USDの自動支払い = 元本800 + 利息100で、すべて債務返済にカウント）。カードでの購入は費用ですが、まだ銀行からの流出ではありません。

収入/支出の分割。 エクスポートされた銀行記録から：プラスの記録は収入、マイナスの記録は支出、振替の記録は除外されます。カテゴリマップ（ベンダーマッピングタブと同じ）：Stripe/PayPalのペイアウト → 顧客からの入金；新規顧客からの送金 → 新規受注/前受金；銀行利息/助成金 → その他の流入；Gusto/ADP → 給与；AWS/GCP → クラウド/ホスティング；銀行引き落としのSaaS → ソフトウェア/SaaS；大家 → 家賃；法律事務所 → 法務/会計；税務当局 → 税金/手数料；ローンの自動支払い → 債務返済。

• 消費税の処理： 消費税は収益ではありませんが、キャッシュフロー項目です。消費税の回収は現金収入として扱い、政府への納付は支出として扱います。収益への影響は発生主義の帳簿にありますが、ここで重要なのはキャッシュフローです。

計算例：W1を最初から最後まで（2026-09-14 – 2026-09-20）​

期首銀行残高は85,000.00（2026-09-13時点で当座80,000 + 普通5,000）。台帳のW1銀行記録から3,000.00のスイープペアを除外した後：

W2へのロールフォワード。 C10 = B29なので、W2は87,500.00で始まります。その銀行記録から、収入は8,000（Stripe）+ 5,000（前受金）+ 200（利息）= 13,200.00、支出は11,000（Gusto給与）+ 1,500 + 2,200 + 600（銀行引き落としSaaS）+ 1,000 + 900 = 17,200.00。純額は−4,000.00、期末残高は83,500.00で、ワークブックのW2列と完全に一致します。構造上、この2週間の予測と実績の差異はゼロです。これはマッピングが機能していることの証明であり、W3以降は1週間ずつ適用されます。

再現方法（2026-09-09、Beancount 3.2.3 + beanquery 0.2.0で検証済み）​

uvx --from beancount bean-check public/downloads/cash-flow-forecast/sample.bean
yarn check:cash-flow-actuals

チェッカーは、bean-check（台帳自体のbalanceアサーションが毎週の期末残高を証明）、以下のエクスポートクエリ、および独立したPythonによるロールフォワードを実行し、3つすべてが一致することを検証します — W1 12,200.00 / 9,700.00 / 87,500.00、W2 13,200.00 / 17,200.00 / 83,500.00：

SELECT date, narration, account, position
FROM date >= 2026-09-14 AND date <= 2026-09-20
WHERE account ~ "^Assets:Bank" ORDER BY date;
 
SELECT sum(position) AS net
FROM date >= 2026-09-14 AND date <= 2026-09-20
WHERE account ~ "^Assets:Bank";
 
SELECT sum(position) AS bank_cash
FROM close ON 2026-09-21 WHERE account ~ "^Assets:Bank";

（W2の場合は日付を7日ずらし、2026-09-28に締めます。）知っておくべきBQLの制限が1つあります。このbeanqueryバージョンは転記を符号でフィルタリングできないため、収入/支出の分割はエクスポートされた行に適用されます。プラスの銀行記録は収入に、マイナスは支出に、スイープペアは除外されます。これはチェッカーが行うのとまったく同じです。

更新リズム（毎週30〜45分）​

1. 実績の取得（15分）： その週のAssets:Bank:*への転記をエクスポートします（上記のクエリを実行するか、銀行口座から取引をダウンロードします。カードの請求は除外し、決済の支払いのみをカウントします）。先週の「期末残高」が実際の合計銀行残高（当座+普通）と完全に一致することを確認します。この照合は必須です。
2. 売掛金の確認（10分）： 未処理の請求書をすべてリストアップし、支払いが見込まれる週に割り当てます。慎重になり、過去の実績に基づいて現実的な回収ラグを適用します。
3. 買掛金と給与の確認（10分）： 既知の今後の請求書の支払期日をすべて割り当てます。四半期全体の給与支払日と金額を事前に入力します。緊急ではない支出は金曜日に予定し、週の間のキャッシュの柔軟性を維持します。
4. 差異ミーティング（10分）： 先週の予測と実際の結果を簡単に比較します。大きな差異の原因をメモし、今後予測ルールを調整する必要があるかどうかを判断します。

精度と意思決定​

精度の目安​

• 第1〜2週： **±5〜10%**の誤差を目指します。これらの日付と金額は、高い確実性を持つべきです。
• 第3〜6週： **±10〜20%**の誤差を想定します。この期間は、既知の請求書とパターンに基づく見積りの混合になります。
• 第7〜13週： この部分の予測は方向性を示すものです。売上パイプラインとランレート費用によって決まります。

信頼度コード： 予測を読みやすくするために、各予測行に信頼度コードを付けます。確定（例：給与、家賃）、可能性が高い（例：優良顧客への請求書）、または上方（例：パイプラインからの新規取引）。

トリガーとアクション（事前に決定する）​

計画なしに予測は役に立ちません。特定のしきい値に達したときのアクションを事前に定義します。

• 最低現金下限： たとえば、「常に次の給与総額の1.5倍以上の現金を維持しなければならない」というルールがあるとします。予測がこの下限を下回ることを示した場合、事前に合意された計画（回収の集中実施、裁量的支出の一時停止など）を直ちに実行します。
• ランウェイのガードレール： たとえば、「第13週の期末残高がXヶ月分のバーンレート未満を示唆する場合、資金調達計画を開始する」とします。これには、タームシートの取得、収益の前払いに対する顧客への割引提供、クレジットラインの利用などが含まれます。
• 大口支出ルール： たとえば、「現在の現金残高の5%を超える単一の非給与支出は、2週間前に承認を得て、フォールバックプランを用意しなければならない」とします。

テンプレートとシナリオ​

シンプルなカテゴリセット（シードステージSaaS向け）​

• 収入： 顧客からの入金、その他の流入（利息、返金、助成金）
• 支出： 給与（手取り+雇用主負担税）、契約社員、クラウド/ホスティング（売上原価）、ソフトウェア/SaaS（営業費用）、マーケティング（有料/ブランド）、家賃/オフィス、法務/会計、税金/手数料、債務返済、一時費用/年次費用
• 計算： 純キャッシュ、期末残高

テンプレート（ダウンロードに組み込み済み。空白で再構築する場合はこれをコピー）​

以下の表は、予測シートの形です。同じ行、同じ数式で、空白のシートに再構築するためのものです。ダウンロードでは、2行目にすでに週開始日（W1 2026-09-14からW13 2026-12-07）が設定され、すべての合計が配線されています。3行目以下と列Aの右側（ファイルではB4）を固定して一致させます。

シナリオトグル（軽量に保つ）​

複雑なモデルを作成せずに、シンプルなシナリオプランニングを構築できます。主要なドライバーについて、シートの上部に「トグル」セルを追加します。たとえば：

• 回収遅延トグル B6: [1.0]（1.2に変更すると、回収の20%遅延をモデル化。毎週の総収入はCOL15 = COL12*$B$6+COL13*$B$7+COL14で再計算されます）
• 新規受注トグル B7: [1.0]（0.8に変更すると、計画比20%の未達をモデル化）

これらは予測シートの実際の前提セルであり、追加の配線は不要です。

学習と間違いの回避​

差異トラッキング（学習を複利にする）​

終了した週に、「先週の予測」と「実績」の2列を追加します。差異を計算します。確認するときは、大きな差異の理由（回収遅延、スコープのずれ、計画外のベンダー購入、タイミングのずれ）にタグを付けます。同じタイプの差異が繰り返される場合は、モデルの基礎となるルールを変更します。たとえば、回収が一貫して1週間遅れる場合は、デフォルトの回収ラグの前提を21日から28日に変更します。

よくある落とし穴（これらを避ける）​

• 発生主義と現金の混在： この予測は現金のみを対象としています。収益認識、減価償却、その他の発生主義の概念は、メインの台帳に属し、ここにはありません。
• 変動の大きい年次費用を忘れる： 毎年の保険料、大規模なSaaS更新、四半期ごとの税金支払いは、大きなサプライズになる可能性があります。それらを知ったらすぐに予測に組み込みます。
• 消費税の現金を無視する： 通過負債であっても、納付するまで現金は銀行口座にあります。流入と流出の両方をモデル化します。
• 照合しない： 予測の期末残高が実際の合計銀行残高（当座+普通。カード残高は除外）と一致しない場合、マッピングエラーがあります。通常は、カード請求をカウントしたか、スイープを保持したかです。予測を信頼できるようになる前に、修正する必要があります。
• 明確な所有者がいない： 毎週予測を更新する責任者を1人割り当てます。休暇のための代理も指名します。

クイックBeancount連携​

• 勘定科目表： 現金バケットをクリーンに保ちます（例：Assets:Bank:Checking、Assets:Bank:Savings、Liabilities:CreditCard:Amex）。毎週の実績はAssets:Bank:*の記録のみです。カード口座は、決済の送金元があるために存在するのであり、支出の2番目のソースではありません。
• 損益計算書をチェックに使用しない： Favaの損益計算書は発生主義であり、カードでの購入を請求時に計上し、ローンの元本を無視するため、設計上、この現金予測とは一致しません。現金チェックは、上記のbean-queryエクスポート+ロールフォワード（yarn check:cash-flow-actuals）であり、毎週期末残高と一致する必要があります。
• ドキュメント化： 大きな一時項目がある場合は、請求書PDFをBeancountのdocuments/フォルダに添付し、予測のメモ列にリンクします。

取締役会/投資家向けパック（1スライド）​

1. グラフ： 13週間すべての週ごとの期末残高のシンプルな折れ線グラフ。最低現金下限を示す水平線を追加します。
2. 表： W1〜W13の期末残高の数字を示す小さな表と、四半期に予想される上位5つの大きな流入と流出の箇条書きリスト。
3. メモ： 前回の更新から変更された主要な前提と、達成した、または達成が見込まれるトリガーについてのいくつかの箇条書き。