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

このガイドは、CFOレベルの手法で会社の流動性を管理するためのシンプルな方法を提供します。13週間のローリング・キャッシュフロー予測を構築することで、週単位でキャッシュランウェイを把握し、回収と支払いを戦略的に舵取りし、財務上の不意打ちを排除できます。これはファウンダーのために作られたシステムであり、このページでは実際のモデルを提供します。サンプルデータ付きの数式ベースのワークブックと、その最初の2週間を支えるサンプルBeancount台帳です（下記のダウンロードを参照）。

このガイドがではないもの、それが2つあります。予測とはあなたが入力する将来を見据えた見積もりであり、会計上の実績とはすでに台帳に記帳された銀行の動きです。したがってワークブックは両者を分けて保持します。計画のコピーを日付付きのベースラインとして凍結し、確定した各週の銀行キャッシュを別の実績シートに入力し、その差を差異シートで読み取ります。比較対象の計画が上書きされることは決してありません。ここにあるものは自動同期しません。ワークブックにはマクロも外部接続もなく、どのステップも銀行やBeancountから自動的にデータを取得することはありません。

なぜ13週間なのか？​

13週間予測がオペレーショナル・キャッシュ管理のゴールドスタンダードとされるのには、いくつかの重要な理由があります。

• 短期コントロール： 約1事業四半期をカバーし、当面の流動性を明確に把握できます。この期間は、2〜3回の給与サイクル、納税、一般的なベンダー支払条件を含めるのに十分な長さでありながら、高い精度と実行可能性を保つのに十分な短さです。
• 収入・支出の視点： 予測は「直接法」を用い、純粋にキャッシュ・インとキャッシュ・アウトに焦点を当てます。これは発生主義会計や収益性の話ではありません。実際に銀行口座に出入りするものに注目することで、予測が銀行残高に直接結びつくことを保証します。
• 静的ではなくローリング： これは一度きりの予算ではありません。毎週、過ぎた週を除き、最後に新しい週（第13週）を追加し、前提を更新します。これにより将来を見据える期間が一定に保たれ、予測が動的で毎週の習慣になります。

構築するもの​

1. 1つの予測グリッド： システムの中核は、13列（第1週〜第13週）と明確に定義されたセクション（期首現金、入金、出金、純キャッシュ、期末現金）を持つ1つのシートです。同じ行を持つ3つの付随シートが、その計画の凍結されたベースライン、銀行が記録した実績、そしてそれらの差異を保持します。
2. カテゴリマッピング： 台帳の取引を予測カテゴリにマッピングするシンプルな仕組みです（例：Stripeからのすべての支払いは「顧客入金」に、Gustoの支払いは「給与」にマッピング）。ワークブックのベンダーマッピングタブには、銀行/カードの二重計上防止ルールを含め、このマップがすでに組み込まれています。独自のものを作るのではなく、これを出発点にしてください。
3. 週次のリズム： 実績を記録し、コミットしたベースラインに対する差異をレビューし、今後の週を再見積もりし、財務上のしきい値に達したときに行動を起こすための事前定義されたトリガーのセットという、反復可能なプロセスです。

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

白紙からのセットアップは不要です。このガイドには、サンプルデータ付きの数式ベースのワークブックと、その最初の2週間を支えるサンプル台帳が付属しています。

• 13週間予測ワークブック（XLSX、v1.1.0）— cash-flow-forecast-13-week-ja.xlsx。編集可能な前提、数式で連鎖した週、値のみのベースライン・スナップショット、実績シート、数式のみの差異シート、ベンダーマッピングタブ。サンプルの数値はすべて実例であり、ご自身のものに置き換えてください（下記のサンプルとあなたのデータを参照）。
• サンプル台帳と実績（Beancount台帳、.bean）— sample.bean。バランスの取れたサンプル台帳で、そのW1〜W2の銀行キャッシュは、ワークブックの実績シートが最初の2週間分として保持しているものと正確に一致します。

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

シート。 ワークブック（cash-flow-forecast-13-week-ja.xlsx、v1.1.0）には、次の順序で6つのシートがあります。

• Forecast — あなたのライブ計画：日付付きの13週、前提、入金、出金、純/期末現金。好きなだけ何度でも編集できます。
• Baseline — Forecastの2〜29行の値のみのスナップショットで、B31にバージョン、B32に基準日がラベル付けされています。数式を一切含まないため、他の場所での操作がこれを変更することはありません。
• Actuals — 確定した各週に銀行キャッシュが実際に動いた額をあなたが入力します。3行目にステータス（completeまたはpartial）、Forecastと同じ行にカテゴリ金額、任意で30行目に明細残高を入力します。
• Variance — 数式のみ：すべてのカテゴリと合計について実際 − ベースラインを、週開始日で照合し、各ステータス語を説明する凡例を付け加えます。Forecastを読むことは決してありません。
• Vendor Mapping — 台帳→カテゴリのマップで、ソースごとの銀行/カード現金計上ルールを含みます。
• Notes — 仕組み、週次レビュー、シナリオトグル、バージョン。ジェネレーターから複製されているため、ファイルはオフラインで自己説明的です。

4つの週グリッドはすべて1つのレイアウトを共有します。週W1〜W13は列B〜N、2行目に各週の開始日、期首現金は10行目、入金は12〜14行目（合計15行目）、出金は17〜26行目（合計27行目）、純は28行目、期末は29行目です。したがって、B12はそのどれにおいてもW1の顧客入金です。

時間基準。 週は月曜日開始で、W1は2026-09-14に始まり、W13は2026-12-07に始まります（Forecastの2行目。モデルを採用する際にこれらの日付を編集してください。すべての数式は週相対なので連鎖は維持されます。ベースラインを取得する際は、それらをBaselineとActualsにも引き継いでください）。取引はその記帳日を含む週（月曜日から日曜日）に属します。

単位。 全体を通して整数のUSD（数値形式 #,##0）。サンプル企業はシード期のSaaSで、85,000で開始し、週次給与は0 / 11,000を交互に、月次家賃、週900のローン自動引き落としがあります。

入力するものと計算されるもの。 Forecastでは、青いセルが手動入力で、それ以外はすべて数式です（Actualsも独自の入力を用いて同様に機能します。詳細は後述のベースラインの取得と週次レビューを参照）。

• 入力：期首残高 B5（85,000）、トグル B6/B7（1.0）、下限 B8（40,000）、3つの入金カテゴリ基準額、10の出金カテゴリ基準額、Forecast上の週開始日。
• 数式（列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はファイルを再度開き、すべての合計セルが実際の数式を保持していることを検証します）。

サンプルとあなたのデータ。 3つのものが事前入力されていますが、そのすべてが実例であり、あなたのビジネスではありません。

• Forecastの青いセル（サンプル企業の現在の計画）。
• Baselineのスナップショット、バージョンB1、2026-09-11時点 — 最初の2週間が確定する前の計画。
• ActualsのW1〜W2の入力（列B〜C）。これはサンプル台帳（sample.bean、上記）の銀行キャッシュです。W3〜W13は空白のままです。

サンプルのBaselineとActualsが異なるため、差異シートは現実の比較で開きます。W1は計画より**+500先行して終わり、W2は+300です（下記の差異レビュー**を参照）。ご自身の最初のレビューの前に、3つすべてを置き換えてください。Forecastに計画を入力し、サンプルのActuals入力を消去し、B1に対して独自のBaselineを取得します（以下の手順）。2つのトグル（B6は全顧客入金をスケール、B7は全前払いをスケール）だけが汎用的に保たれるべきもので、シナリオ検討用です。

v1.0.0からの移行ですか？ Forecastシートのレイアウトは変わっていないので、計画を意図的に持ち越せます。古いファイルで入力範囲のみ（B2:N2（日付）、B5:B8、B12:N14、B17:N26）をコピーし、新しいファイルのForecastの同じアドレスに値として貼り付けてください。数式行の上には決して貼り付けないでください。v1.0.0はベースラインを保持していなかったため、実績で上書きした過去の週には復元可能な計画がありません。それらの週の銀行キャッシュをActualsに入力し、今日のForecastから最初のBaselineを始めてください。

構造（必要な行）​

予測シートは、すべてのキャッシュの動きを捉えるために、以下の行で構成すべきです。ワークブックのレイアウト： 以下の行はForecastにあり（日付付きの13週と期首現金、3つの入金カテゴリ、10の出金カテゴリ、純および期末）、Baseline、Actuals、Varianceがそれらを行ごとに繰り返します。Vendor Mappingは台帳ソースをこれらのカテゴリにマッピングし（銀行/カードの二重計上防止ルールを含む）、Notesはオフラインで仕組みを説明します。Forecastでは、入金は顧客入金、新規契約/前払い、その他の流入にグループ化され、出金は給与、業務委託、クラウド/ホスティング、ソフトウェア/SaaS、マーケティング、家賃、法務・会計、税・手数料、債務返済、一時的支出にグループ化されます。合計は期首→総入金→総出金→純→期末へと連なります。

• 期首現金残高（これは前週の期末現金残高と一致しなければならない）

• 入金（キャッシュ・イン）

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

• 出金（キャッシュ・アウト）

  • 給与： 従業員への手取りを含む全現金コストと、すべての雇用者側給与税。
  • 業務委託・フリーランサー： 非従業員への支払い。
  • クラウド/ホスティング（売上原価）： AWS、GCPなどの主要なインフラコスト。
  • SaaS/ツール： すべてのソフトウェア購読。
  • マーケティング： 広告費、代理店手数料、その他ブランド関連コスト。
  • 家賃/オフィス： 物理的なオフィスコスト。
  • 法務・会計： 専門サービス手数料。
  • 税・手数料： 売上税の納付やその他の政府への支払い。
  • 債務返済： ローンの元本と利息の両方の支払い。
  • 一時的支出： 年次保険料、敷金、ハードウェア/設備投資（ノートPC、機器）など、まとまってまれに発生する支払い。上記に独自の行がないものはすべてここに入ります。

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

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

実例13週間サンプル（USD）​

以下の表は、サンプル企業のワークブックのForecastシートを週ごとに示したものです。W1とW2が確定した後に再予測された現在の計画なので、その2列は銀行が実際に行ったことを保持しています。W1とW2は台帳実績です。それらはyarn check:cash-flow-actualsがsample.beanから導出する合計（入金12,200 / 13,200、出金9,700 / 17,200、期末87,500 / 83,500）と一致します。W3〜W13はワークブックの前提で、ジェネレーターのサンプル基準額からのものです（台帳には記帳されていません）。企業が事前にコミットした計画はBaselineに別途保持されており、これらのW1〜W2の列とは異なります。下記の差異レビューが両者を比較します。通貨は整数USD、期末 = 期首 + 入金 − 出金が毎週です。

ローリングの仕組み（ワークブックでの実装）​

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

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

同じ行がActualsにも単純な合計として存在します（B15 = SUM(B12:B14)、B27 = SUM(B17:B26)、B28 = B15-B27、B29 = B10+B28、C10 = B29）。その週の実際の期首現金はActuals!B10に一度だけ入力します。Actualsにはトグルがなく、他のシートを参照することもありません。

ベースラインの取得（期間ごとに1回）​

Forecastが、測定対象にしたい計画を保持したら、最初の週が確定する前にこれを行います。

1. 計画を値としてコピー。 Forecast!B2:N29を選択してコピーします。Baseline!B2を選択し、値のみを貼り付けます。Excel：形式を選択して貼り付け → 値。LibreOffice：形式を選択して貼り付け → 値のみ。Numbers：編集 → 計算結果をペースト。通常の貼り付けでは生きた数式が持ち込まれ、「ベースライン」が後のすべての編集に黙って追随してしまいます。
2. ラベルを付ける。 Baseline!B31にバージョン（例えばB1）を、Baseline!B32に今日の日付を入力します。どちらも貼り付けたブロックの下にあるので、後の取得がこれらを上書きすることはありません。
3. 週を揃える。 Baseline!B2:N2をコピーし、Actuals!B2に値として貼り付け、両シートが同じ13の週開始日を示すようにし、Actuals!B10に開始する銀行残高を入力します。

ここから、実績の入力、Forecastの編集、トグルの移動は、ForecastとVarianceを再計算し、Baselineは取得したままに保ちます。

週次の月曜レビュー（このワークブックに対して）​

1. Actualsに週を記録する — Forecastには決して記録しない。 2行目の日付が確定した月曜日である列で、その週の銀行キャッシュをカテゴリごとに12〜14行目と17〜26行目に入力します（下記のマッピング）。現金が動かなかった箇所には0を入力します。空白セルは「まだ未入力」を意味し、ゼロではありません。銀行明細の期末残高を30行目に入力すると、31行目は0を示すはずです。そうでなければマッピングエラーです（多くの場合、計上したカード請求か、保持したスイープ）であり、銀行のエラーではありません。
2. 週が完了しているか確認する。 すべてのカテゴリ行に数値が入ったら3行目にcompleteを、週がまだ進行中ならpartialを入力します（ドロップダウンが両方を提供します）。差異は、週がcompleteで、すべてのカテゴリが入力され、Actualsの日付が同じ列のBaselineの日付と一致する場合にのみ、その週を比較します。
3. 差異を読む。 3行目は各週の状態を示します。comparedの週だけが数値を示し、その他の状態はn/aを示し、決して0ではありません。したがって、未入力の週が「計画どおり」と見なされることはありません。符号は実際 − ベースラインです（O列がそれらを繰り返します）。入金、純、期末の正は計画より多くの現金、出金の正は計画より多い支出を意味します。29行目は累積で、それ以前のすべての週を含み、そこまでのすべての週がcomparedである場合にのみ存在します。32〜35行目は合計をベースラインの割合として表します（ベースラインがゼロの場合n/a）。
4. Forecastで将来を再見積もりする。 次の2〜4週間について、最も新しい情報（新たに送付した請求書、今後のベンダー支払い、確定した給与日）で青いセルを更新します。完全な13週間の先読みを保つには、Forecastウィンドウをローリングします。青い入力を、2行目の日付を含めて1列左にシフトし（旧第2週が第1週になる）、N列をクリアして新しい第13週の日付を割り当てます。繰り越し数式は自動的に再アンカーされ、Baseline、Actuals、Varianceは触れられません。

レビュー期間のローリング（週次ではなく意図的なステップ）​

BaselineとActualsは、移動させると決断するまで、取得した期間にとどまります。通常、Forecastが1か月または四半期先にローリングしたとき、あるいは計画が十分に変わって新しい基準が欲しいときに移動します。

1. アーカイブ。 ワークブックのコピーを保存します（例えばcash-flow-forecast-B1.xlsx）。古いベースライン、その実績、それらの差異を一緒に保ちます。作業ファイルは履歴を保持しません。
2. 実績入力をクリアする。 Actualsで、列B〜Nの3、12〜14、17〜26、30行目とB10をクリアします。C10:N10、15行目と27〜29行目、31行目はそのままにします。これらは数式です。
3. 新しいベースラインを取得する。今日のForecastから次のバージョン（B2）と今日の日付で取得し、上記のベースラインの取得とまったく同じようにActualsの日付と期首残高を揃えます。

週の列を挿入または削除しないでください。ベースラインを再取得したのにActualsの日付を変更し忘れると、影響を受けるすべての週が、ある週を別の週の計画と比較する代わりにdate mismatchを示します。

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

銀行現金スコープ（二重計上を防ぐルール）。 週次実績はAssets:Bank:*への記帳のみです。これは両方の罠を解消する単一のスコープです。

• クレジットカード： カード購入はLiabilities:CreditCard:*に記帳され、銀行現金を動かさないため、請求時に計上されません。現金は決済時（銀行→カードの支払い）に一度だけ出ていきます。請求と決済を計上すると、同じ支出を二重に数えてしまいます。サンプル台帳では、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を支えるBeancount抜粋​

以下のすべての記帳は、提供されているsample.beanにも存在します。これ単独で保存すると、この抜粋はuvx --from beancount bean-checkを通過し、上記の銀行現金スコープを適用すると（普通預金↔貯蓄のスイープを両側から除外、Amexの決済を計上し、負債の請求は計上しない）、この表のW1入金（12,200）、出金（9,700）、期末（87,500）を生成します。

option "title" "Cash forecast sample — W1 excerpt"
option "operating_currency" "USD"
 
2026-09-13 open Assets:Bank:Checking USD
2026-09-13 open Assets:Bank:Savings USD
2026-09-13 open Liabilities:CreditCard:Amex USD
2026-09-13 open Liabilities:Loan USD
2026-09-13 open Equity:Opening-Balances USD
2026-09-13 open Income:Sales USD
2026-09-13 open Income:Interest USD
2026-09-13 open Expenses:Contractors USD
2026-09-13 open Expenses:Cloud USD
2026-09-13 open Expenses:Software USD
2026-09-13 open Expenses:Marketing USD
2026-09-13 open Expenses:Rent USD
2026-09-13 open Expenses:Interest USD
 
2026-09-13 * "Opening balances"
  Assets:Bank:Checking            80000.00 USD
  Assets:Bank:Savings              5000.00 USD
  Liabilities:CreditCard:Amex      -600.00 USD
  Liabilities:Loan               -20000.00 USD
  Equity:Opening-Balances        -64400.00 USD
 
2026-09-14 * "Stripe" "Customer receipts W1"
  Assets:Bank:Checking            12000.00 USD
  Income:Sales                   -12000.00 USD
 
2026-09-15 * "Contractor" "Contractors W1"
  Expenses:Contractors              1500.00 USD
  Assets:Bank:Checking             -1500.00 USD
 
2026-09-15 * "AWS" "Cloud hosting W1"
  Expenses:Cloud                    2200.00 USD
  Assets:Bank:Checking             -2200.00 USD
 
2026-09-16 * "Bank" "Checking -> Savings sweep"
  Assets:Bank:Savings               3000.00 USD
  Assets:Bank:Checking             -3000.00 USD
 
2026-09-17 * "SaaS vendor" "Amex SaaS charges"
  Expenses:Software                  250.00 USD
  Liabilities:CreditCard:Amex       -250.00 USD
 
2026-09-17 * "SaaS vendor" "Amex SaaS charges"
  Expenses:Software                  170.00 USD
  Liabilities:CreditCard:Amex       -170.00 USD
 
2026-09-18 * "Amex" "August statement settlement"
  Liabilities:CreditCard:Amex        600.00 USD
  Assets:Bank:Checking              -600.00 USD
 
2026-09-19 * "Landlord" "Rent W1"
  Expenses:Rent                     3500.00 USD
  Assets:Bank:Checking             -3500.00 USD
 
2026-09-19 * "Agency" "Marketing W1"
  Expenses:Marketing                1000.00 USD
  Assets:Bank:Checking             -1000.00 USD
 
2026-09-19 * "Bank" "Interest W1"
  Assets:Bank:Checking               200.00 USD
  Income:Interest                   -200.00 USD
 
2026-09-19 * "Lender" "Loan autopay W1"
  Liabilities:Loan                   800.00 USD
  Expenses:Interest                  100.00 USD
  Assets:Bank:Checking              -900.00 USD

実例週：W1を端から端まで（2026-09-14 – 2026-09-20）​

期首銀行現金は85,000.00です（2026-09-13時点で普通預金80,000 + 貯蓄5,000）— Actuals!B10の値です。台帳のW1銀行レッグは、3,000.00のスイープペアを除外した後、Actualsシートの列Bに入ります。記載のないすべてのカテゴリは0として入力し、3行目はcompleteに設定します。

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 — まさにActualsのワークブックのW2列（そして再予測されたForecastシート）です。明細残高87,500と83,500はActuals!B30:C30にあり、31行目は両週とも0を示します。これがマッピングが機能している証拠です。その週が計画に対してどうだったかは別の問題で、下のVarianceで答えられます。

再現する（検証済み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表明が各週の期末現金を証明します）、下記のエクスポートクエリ、そして3つすべてが一致することを表明する独立したPythonロールフォワードを実行します — 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:*への記帳をエクスポートし（上記のクエリを実行するか、銀行口座から取引をダウンロードします — カードの請求は除外し、決済の支払いのみを計上します）、それらをActualsシートに入力します。その週のActualsの期末現金が、実際の合計銀行残高（普通預金 + 貯蓄）と完全に一致することを確認します — 31行目が0を示します。この照合は譲れません。
2. 売掛金をレビュー（10分）： すべての未払請求書をリストアップし、支払いを見込む週に割り当てます。保守的に、過去の実績に基づく現実的な回収ラグを適用します。
3. 買掛金と給与をレビュー（10分）： 既知の今後の請求書すべての期日を割り当てます。四半期全体の給与日と金額を事前入力します。重要でない出金は金曜日にずらし、週の間の現金の選択肢を保ちます。
4. 差異ミーティング（10分）： Varianceシートを開き、その週のcompared列をたどります。どのカテゴリが、どの方向に動き、それが累積期末現金に何をもたらしたか。大きな差異の原因を記録し、今後の予測ルールを調整する必要があるか判断します。

精度と意思決定​

精度の経験則​

• 第1〜2週： **±5〜10%**の誤差を目指します。これらの日付と金額は非常に確実であるべきです。
• 第3〜6週： **±10〜20%**の誤差を見込みます。この期間は既知の請求書とパターンベースの見積もりの混合になります。
• 第7〜13週： 予測のこの部分は方向性です。営業パイプラインと経常的な費用によって決まります。

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

トリガーとアクション（事前に決めておく）​

計画がなければ予測は無意味です。特定のしきい値に達したときのアクションを事前に定義します。

• 最低現金下限： 例えば、「常に現金 ≥ 次の完全な給与額の1.5倍を維持しなければならない」というルール。予測がこの下限を割ると示したら、事前に合意した計画を即座に実行します。例えば回収スプリントとすべての裁量的支出の停止など。
• ランウェイ・ガードレール： 例えば、「第13週の期末現金がXか月分未満のバーンを意味する場合、資金調達計画を開始する」。これにはタームシートの模索、収益の前払いに対する顧客への割引、クレジットラインの引き出しなどが含まれます。
• 大口流出ルール： 例えば、「給与以外の単一の出金が現在の現金残高の5%を超える場合、2週間前の承認とフォールバック計画を必要とする」。

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

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

• 入金： 顧客入金、その他の流入（利息、返金、助成金）
• 出金： 給与（手取り + 雇用者税）、業務委託、クラウド/ホスティング（売上原価）、ソフトウェア/SaaS（販管費）、マーケティング（有料/ブランド）、家賃/オフィス、法務/会計、税・手数料、債務返済、一時的支出/年次費用
• 計算： 純キャッシュ、期末現金

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

以下の表はForecastシートの形です — 同じ行、同じ数式 — 空白シートで再構築するためのものです。ダウンロードでは、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%の未達をモデル化）

これらはForecastシートの実際の前提セルです — 追加の配線は不要です。

学習と間違いの回避​

差異レビュー（学習を複利にする）​

ワークブックは差異の記帳をあなたに代わって行います。差異 = 実際 − ベースライン、カテゴリごとおよび合計ごと、ActualsがcompleteでBaselineと同じ日付のすべての週について。あなたの仕事は数値を説明することです。レビューの際、大きな差異の理由にタグを付けます。回収遅延、スコープのずれ、計画外のベンダー購入、タイミングのずれ。同じ種類の差異が繰り返されるなら、モデルの根底にあるルールを変更します。例えば、回収が一貫して1週間遅れるなら、デフォルトの回収ラグの前提を21日から28日に変更します。

実例比較（提供されたサンプル）。 ベースラインB1は2026-09-11に85,000の期首から取得されました。Actualsはサンプル台帳の銀行キャッシュです。符号は差異シートに従います。入金、純、期末の正は計画より多くの現金、支出の正は計画より多い支出を意味します。

差異シートが示す通りに読むと：

• W1、+500。 顧客入金は計画の11,800を200上回り（Variance!B12 = +200）、AWSは計画の2,500に対して2,200を請求しました（Variance!B19 = −300：支出が少なく、有利）。85,000 + 12,200 − 9,700 = 87,500の実際に対して、85,000 + 12,000 − 10,000 = 87,000の計画。
• W2、+300。 入金は計画どおりに着地しましたが、銀行払いのSaaS請求は計画の400に対して600でした（Variance!C20 = +200：支出が多く、不利）。その週の純は−200なので、累積期末のリードは+500から+300に縮みます（Variance!C29）：87,500 + 13,200 − 17,200 = 83,500に対して、87,000 + 13,200 − 17,000 = 83,200。
• W3以降、not observed。 何も入力されていないため、すべてのセルがn/aを示します — 慰めの0ではありません。
• 割合として（32〜33行目）：W1入金+1.67%、支出−3.00%。W2入金0.00%、支出+1.18%。

ここから2つのタグが出てきます。AWSの見積もりが高めに推移していること、銀行払いのSaaS行が200低く計画されていたこと。どちらもForecastの前提の修正です — ベースラインB1はそのままに保たれるので、次の四半期に元の計画がどれだけずれていたかをまだ見られます。

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

• 計画の上書き： Forecastセルに実績を入力する（または毎週Baselineを再貼り付けする）と、測定されるべき計画が破壊されます。実績はActualsに入ります。Baselineは期間を意図的にローリングするときだけ変わります。
• 発生主義と現金の混同： この予測は現金のみのためです。認識収益、減価償却、その他の発生主義の概念は主要な台帳に属し、ここではありません。
• むらのある年次費用を忘れる： 年次保険料、大きなSaaS更新、四半期の納税は大きな不意打ちになりえます。知った時点で予測に組み込みます。
• 売上税の現金を無視する： 通過負債であっても、現金は納付するまで銀行口座にあります。流入と流出の両方をモデル化します。
• 照合しない： Actualsのその週の期末現金が、実際の合計銀行残高（普通預金 + 貯蓄、カード残高は除外）と一致しないなら、マッピングエラーがあります（多くの場合、計上したカード請求か、保持したスイープ）。予測を信頼する前に修正しなければなりません。
• 明確な担当者がない： 毎週予測を更新する責任を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. ノート： 前回の更新以降に変わった主要な前提と、到達した、または到達が見込まれるトリガーに関するいくつかの箇条書き。