Statement Excel → APIダッシュボード化 実現可能性評価

評価日: 2026-03-27 ｜ 対象: IB式三表連動モデル（PL/BS/CF + NWC/税金/Debt/Bank/Personal）

結論

段階移行を推奨。Phase 1（PL + Bank Account）で2〜3週間、Excel並存のまま始められる。

MFクラウドAPIから売上・経費データは取得可能で、PL自動生成は現実的。 一方、税金計算エンジンとBS全勘定科目の自動取得は難易度が高く、Excel完全置き換えには相応の時間がかかる。 「Excelを捨てる」ではなく「Excelに手入力していたデータを自動で集め、グラフで見やすくする」から始めるのが得策。

1. モジュール別 技術的難易度

モジュール 難易度 根拠 データソース
PL（損益計算書） 中 売上: MF請求書APIから取得可能（Billing.total_price）。Consulting/Comme Neige分離はpartner_nameで判別。
経費: MF経費APIのex_transactions + rules.csvの科目マッピングで勘定科目別集計可能。
課題: 減価償却・引当金など非キャッシュ項目はAPIに存在せず、手入力 or ルール定義が必要。 		MF請求書API + MF経費API
BS（貸借対照表） 高 MFクラウドAPIにBS残高を直接返すエンドポイントがない。
勘定科目ごとの期末残高は、取引の積み上げ or MFクラウド会計（別サービス）のAPI連携が必要。
課題: 固定資産台帳・借入金残高・資本金など、経費APIの範囲外のデータが多い。 		MFクラウド会計API（未連携）or 手入力
CF（キャッシュフロー） 中 間接法の理論CFはPLとBSの差分から算出するため、PL・BSが揃えば自動計算可能。
計算ロジック自体はシンプル（当期純利益 ± 非キャッシュ項目 ± NWC変動）。
課題: BSの自動化度合いに完全に依存する。BSが手入力ならCFも半手動。 		PL + BS（派生計算）
NWCウォーターフォール 中 売掛金・買掛金はMF請求書/債務支払APIから取得可能。
棚卸資産（Comme Neige在庫）は外部データ or 手入力。
BoP→増減→EoP展開は前月残高との差分計算。 		MF請求書API + MF債務支払API + 手入力
税金計算エンジン 高 消費税（仮受/仮払/未払）: 取引ごとの税区分情報（dr_excise）はAPIにあるが、申告計算ロジックは複雑。
法人税: 繰越欠損金控除→法人税・地方法人税・事業税・特別法人事業税・住民税の5段階計算。
課題: 税率改正への追従、中間納付の考慮。正確性検証のコストが高い。Excelの計算式を忠実に移植する必要あり。 		PL（派生計算）+ 税率テーブル
Debtスケジュール 低 借入条件（金額・金利・返済スケジュール）は固定。初期設定後は月次で返済額を差し引くだけ。
長短振替・D/E・Net debt/EBITDAは四則演算。 		初期設定（手入力）→ 自動計算
Bank Account 中 税込ベースの実口座残高。MFクラウドの連携明細（スクレイプ済み）に近い情報はある。
ただし銀行API直接連携は未実装。現行のoutgo_list.csvから入出金を集計する形は可能。
課題: 入金側（売上入金）のデータソースが不足。MF請求書の入金ステータスで補完可能。 		MF経費スクレイプ + MF請求書API
Personal 低 手取り: PLの役員報酬から社会保険・所得税を引くだけ。
生活費・投資（iDeCo/NISA/仮想通貨）: 外部APIなし、手入力が前提。
判断: 自動化の価値が低い。ダッシュボードに表示だけすれば十分。 		手入力

2. 段階的実装スコープ

Phase 1 MVP — 月次PL + Bank Account（工数: 小〜中）

目的: 毎月の売上・経費・利益をブラウザで確認できるようにする。Excelへの手入力を減らす。

機能 内容
月次PL自動生成 MF請求書API（売上）+ MF経費API（経費）→ 勘定科目別集計 → EBITDA・営業利益・経常利益を自動計算
Consulting / Comme Neige分離 請求先名（partner_name）で自動分類。ルールはJSON設定ファイル
Bank Account概算 MF経費のスクレイプデータ + MF請求書の入金ステータスから入出金推移を表示
ダッシュボードUI 既存パターン踏襲（HTML+JS+SSE）。月次PL表 + 推移グラフ（棒グラフ/折れ線）

この段階でExcelに残るもの: BS、CF、NWC、税金計算、Debt、Personal全て。PLの非キャッシュ項目（減価償却等）。

Phase 2 実用レベル — 三表連動 + 税金概算（工数: 中〜大）

目的: PL/BS/CFが連動し、月次の財務状態をダッシュボードで把握できる。

機能 内容
BS自動生成 MFクラウド会計API連携（新規）or 勘定科目残高の手入力UI。売掛・買掛はAPI自動取得
CF自動計算 間接法CF（PL + BS差分）。営業CF・投資CF・FCF・財務CF
NWCウォーターフォール 売掛金・買掛金のBoP→EoP展開。増減要因のドリルダウン
税金概算 消費税（仮受-仮払）の概算表示。法人税は簡易計算（実効税率×税引前利益）
Debtスケジュール 借入条件を設定→返済スケジュール自動生成。D/E・Net debt/EBITDA指標
手入力UI APIで取れないデータ（減価償却・固定資産・棚卸等）をブラウザから入力

この段階でExcelに残るもの: 詳細税金計算（繰越欠損金控除等）、Personal。

Phase 3 フル機能 — Excel完全置き換え（工数: 大）

目的: Excelを完全に不要にする。

機能 内容
詳細税金エンジン 法人税・地方法人税・事業税・特別法人事業税・住民税の5税計算。繰越欠損金控除。中間納付。税率テーブル管理
Personal 役員報酬→手取り計算。iDeCo/NISA/仮想通貨の資産管理。銀行口座別残高
シナリオ分析 「売上が10%増えたら」「新規借入したら」等のwhat-ifシミュレーション
Excel出力 ダッシュボードのデータをExcel形式でエクスポート（顧問税理士共有用）

3. 推奨アーキテクチャ

┌─────────────────────────────────────────────────────────────┐ │ データフロー全体像 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ MF経費API │ │ MF請求書API │ │ MF債務支払API │ │ │ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │ │ │ │ │ │ │ └─────────┬─────────┴─────────┬─────────┘ │ │ ▼ │ │ │ ┌─────────────────┐ │ │ │ │ Fetcher層 │ │ │ │ │ (API → JSON取得) │◀──────────┘ │ │ └────────┬────────┘ │ │ ▼ │ │ ┌─────────────────┐ ┌──────────────┐ │ │ │ 集計エンジン │◀───│ 手入力JSON │ │ │ │ (PL/BS/CF計算) │ │ (減価償却等) │ │ │ └────────┬────────┘ └──────────────┘ │ │ ▼ │ │ ┌─────────────────┐ │ │ │ data/statement/ │ ← 月次スナップショット保存 │ │ │ 202603.json │ │ │ └────────┬────────┘ │ │ ▼ │ │ ┌─────────────────┐ ┌──────────────┐ │ │ │ REST API │───▶│ ダッシュボード │ │ │ │ (dashboard/ │◀───│ (HTML+JS) │ │ │ │ server.py拡張) │SSE │ │ │ │ └─────────────────┘ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘

設計判断

項目 判断 理由
ストレージ JSON ファイル（DB不要） 月次データは12ヶ月×1ファイルで済む。一人法人でマルチユーザー不要。
既存パターン（tasks.json, worker_status.json）と一貫。
SQLiteやPostgreSQLは過剰。将来必要になれば移行は容易。
フロントエンド 既存ダッシュボードにタブ追加 現在「Dashboard / Monthly Pipeline / History」の3タブ構成。
4つ目に「Financial Statement」タブを追加するのが最小コスト。
同じSSEパターン、同じスタイル、同じサーバーで動く。
更新頻度 バッチ（月次） + オンデマンド 財務データはリアルタイム性不要。月末に集計パイプラインを実行し、結果をJSONに保存。
CLIコマンドで任意タイミングの更新も可能にする。
SSEは表示切替時のUI更新用（データ変更検知）。
計算エンジン Python モジュール（ops/statement/） Excelの計算式をPython関数に移植。テスト可能、バージョン管理可能。
pydanticモデルで型安全。金額はint（円単位）。
配置 ops/ 配下に新パッケージ ops/accounting/ の拡張ではなく ops/statement/ として独立。
accounting は「経費仕訳」、statement は「財務諸表生成」で責務が異なる。
ただし ops/accounting/app/mf_client/ 等のAPIクライアントは共有する。

想定ディレクトリ構造（Phase 1）

ops/statement/ ├── app/ │ ├── config.py # pydantic-settings │ ├── models.py # PL/BS/CFのpydanticモデル │ └── engine/ │ ├── pl.py # PL集計ロジック │ ├── bank.py # Bank Account計算 │ └── fetcher.py # MF API → 生データ取得 ├── pipeline/ │ ├── cli.py # python -m statement.pipeline run │ └── steps/ │ ├── fetch.py # APIからデータ取得 │ ├── aggregate.py # 勘定科目別集計 │ └── export.py # JSON出力 ├── data/ │ ├── config.json # 事業区分ルール等 │ ├── manual/ # 手入力データ │ │ └── 202603.json │ └── output/ # 月次スナップショット │ └── 202603.json └── __init__.py

4. 既存資産との統合方針

既存資産 方針 詳細
ops/accounting/app/mf_client/ 共有 MF経費APIクライアント・OAuth基盤をそのまま利用。importパスで参照。
ops/accounting/app/mf_invoice/ 共有 MF請求書APIクライアントをそのまま利用。売上データの取得に使用。
ops/accounting/app/mf_payable/ 共有 MF債務支払APIクライアントをそのまま利用。買掛金データの取得に使用。
ops/accounting/data/rules.csv 参照 科目マッピングルールを参照し、経費の勘定科目分類に使用。
ops/shared/oauth.py 共有 BaseOAuthクラスを継承。トークン管理は既存の仕組み。
dashboard/server.py 拡張 /api/statement エンドポイント追加。SSEに "statement" イベント追加。
dashboard/index.html 拡張 「Financial Statement」タブ追加。PL表・グラフのレンダリング関数追加。

5. Excel置き換え / 並存 / 段階移行の比較

選択肢 概要
A. 一括置き換え 全モジュールを実装してからExcelを廃止
B. 並存（読み取り専用） Excelは維持。ダッシュボードは閲覧用のみ
C. 段階移行 Phase 1から使い始め、機能追加のたびにExcelの該当シートを廃止

A. 一括置き換え

問題点

B. 並存（読み取り専用）

問題点

推奨: C. 段階移行

Phase 1のPL自動生成から始め、ダッシュボードで確認→Excelの該当列を埋める手間が消える、という実感を得る。 信頼できるモジュールから順にExcelのシートを「参照不要」にしていく。

この方式のポイント:

6. リスク・注意点

リスク 影響 対策
税金計算の正確性 高 税金計算は最後に実装。実装時はExcelの計算結果と突合テストを必ず行う。
繰越欠損金・税率変更等のエッジケースはExcelの数式を忠実に移植。
最終的には顧問税理士のチェックを経てから本番運用。
MFクラウドAPIの制約 中 レート制限: 経費APIは429レスポンスあり（既に対応済み）。
データ範囲: 経費APIは「明細」単位で、「勘定科目残高」は返さない。集計はこちら側で行う。
API変更: v1 APIのため将来のバージョンアップリスク。変更通知をウォッチ。
BS自動化の壁 中 MFクラウド会計（freeeの対抗サービス）のAPIが必要だが、現在未契約/未連携。
Phase 2ではBS項目の一部を手入力UIで補う設計にし、会計API連携は追加オプション扱い。
Excelとの数値不一致 中 移行期間中はExcelとダッシュボードの数値を月次で突合する運用を入れる。
不一致の原因（タイミング差・端数処理・手入力漏れ）を特定し、ルールに反映。
個人資金繰り（Personal）の自動化限界 低 iDeCo/NISA/仮想通貨の残高はAPIがない（or 連携コストが高い）。
Personalは手入力UIのみ提供し、自動化は諦める。
銀行口座残高も同様（銀行API連携はコスト対効果が合わない）。
MFクラウド会計との二重管理 低 MFクラウド会計自体にもレポート機能がある。ダッシュボード化の意義は「IB式三表連動」と「個人資金繰り統合」にある。
MFのレポートでは不足する分析軸（事業別PL、NWCウォーターフォール等）を提供することで差別化。

7. Phase 1 実装の具体イメージ

Phase 1を始める場合の具体的な作業内容:

# 作業 内容
1 データモデル定義 PLLineItem, ProfitLoss, BankTransaction 等のpydanticモデル。金額はint。
2 Fetcher実装 MF請求書APIから月次Billing一覧取得。MF経費APIから月次ExTransaction一覧取得。既存クライアントを利用。
3 PL集計エンジン 売上をConsulting/Comme Neigeに分類。経費をrules.csvの科目マッピングで分類。売上総利益→EBITDA→営業利益→経常利益→当期純利益を算出。
4 Bank Account集計 入金（請求書の入金ステータス）と出金（経費明細）から月次キャッシュ推移を計算。
5 CLI python -m statement.pipeline run --year 2026 --month 3 で月次データ生成。JSON出力。
6 ダッシュボードUI 既存dashboard/index.htmlにタブ追加。PL表（月次）+ 売上・利益の推移グラフ（直近12ヶ月）。
7 検証 直近3ヶ月分をExcelと突合し、数値が一致することを確認。

MNML Architect ｜ Statement Dashboard 実現可能性評価 ｜ 2026-03-27