飲食チェーンのfreee会計×BigQuery連携｜店舗別PLダッシュボード設計
目次 クリックで開く
多店舗展開する飲食チェーンにおいて、経営判断のスピードを左右するのは「店舗ごとの損益（PL）」がいかに解像度高く、かつタイムリーに可視化されているかです。しかし、多くの現場では、freee会計からCSVをエクスポートし、POSレジの売上データや勤怠ソフトの人件費データとExcel上で突き合わせる「手作業の限界」に直面しています。
本記事では、freee会計を核とし、Google Cloudのデータウェアハウス（DWH）であるBigQueryを活用して、店舗別PLダッシュボードを構築するための実務的なアーキテクチャを詳解します。単なるツール連携の解説に留まらず、飲食業特有の「FLコスト（原材料費・人件費）」の管理に耐えうるデータ設計の勘所を解説します。
飲食チェーンにおける店舗別損益管理の課題とデータ基盤の必要性
飲食業は、原材料費の変動、シフト管理による人件費の増減、天候による客数の振れ幅など、極めて変数の多いビジネスです。freee会計はクラウド会計として優れた操作性を持ちますが、分析基盤として利用する際にはいくつかの壁が存在します。
freee会計標準機能による店舗別管理の限界
freee会計には「部門」タグを利用した店舗別損益の把握機能が備わっています。しかし、以下のニーズには標準機能だけでは対応が困難です。
- 非会計データとの統合：客数、客単価、天候、Web広告のインプレッション数といった「仕訳にならないデータ」との相関分析。
- 独自のKPI算出：坪単価売上、FL比率（Food & Labor）、あるいは「店長の人件費を除いた現場人件費率」などの柔軟な計算。
- ドリルダウンの制約：試算表から異常値を見つけた際、その場で取引先別・品目別に多角的に深掘りする操作性は、BIツールに軍配が上がります。
なぜ飲食業にはBigQueryが必要なのか
BigQueryをデータ基盤（シングルソース・オブ・トゥルース）に据える最大のメリットは、「データの民主化」です。経理担当者だけでなく、エリアマネージャーや店長が、自分たちの店舗のパフォーマンスをリアルタイム（または日次）で確認できる環境を作ることで、現場の改善サイクルが劇的に加速します。
特に、freee会計の「経営可視化・高度連携」フェーズにおいては、APIを通じてデータを外部に持ち出し、計算負荷の高い集計をBigQuery側で処理する構成がベストプラクティスとなります。
freee会計 × BigQuery 連携のアーキテクチャ設計
構築の第一歩は、どのようにしてfreeeのデータをBigQueryへ運ぶかというパイプラインの設計です。
データフローの全体像
一般的なアーキテクチャは以下の3ステップで構成されます。
- Extract（抽出）：freee APIを叩き、仕訳帳（deal/wallet_txs）、部門（partners）、取引先（items）などのデータを取得。
- Load（格納）：取得したJSONデータをBigQueryのRawデータ層（Staging領域）にそのまま格納。
- Transform（変換）：dbtなどのツールを用い、Rawデータを会計報告用・分析用の「データマート」へ加工。
ETLツールの選定：自社開発 vs SaaS
このパイプラインを「Pythonなどで自作」するか、「SaaS（ETLツール）」を使うかは、保守コストに直結します。以下の比較表を参考にしてください。
| 選定軸 | SaaS利用（TROCCO / CData等） | 自社開発（Python + Cloud Functions等） |
|---|---|---|
| 導入スピード | 極めて早い（数時間〜数日） | 遅い（API仕様の理解と実装に数週間） |
| 初期費用 | 数万円〜（月額） | 開発工数（人件費）のみ |
| 保守性 | 高い。API仕様変更もSaaS側が吸収 | 低い。freeeのAPI更新に追随が必要 |
| 柔軟性 | ツールが対応する範囲に限定 | 無限（独自の差分更新ロジックなど） |
飲食チェーンの実務においては、専任のデータエンジニアが不在であれば、SaaSツールを活用して「データの鮮度」を優先することをお勧めします。特にfreee APIは定期的にバージョンアップや仕様変更が行われるため、自社メンテナンスの負荷は想像以上に高くなります。
飲食チェーン 店舗別PL集計設計パターン × BigQueryテーブル構成 × Looker活用ポイント 早見表
前のセクションでfreee×BigQuery連携のアーキテクチャ全体を解説しましたが、「どの粒度で店舗別PLを集計するか」によってBigQueryのテーブル設計とLookerのダッシュボード設計が変わってきます。売上・費用を月次で見るだけの集計と、曜日・時間帯・席数あたりの効率まで掘り下げる集計では、必要なデータソースと集計ロジックが根本的に異なります。以下の表は、集計粒度・目的別の設計パターンをまとめたものです。
| 集計粒度・目的 | 必要なデータソース | BigQueryテーブル設計のポイント | Looker Studio / Lookerのダッシュボード活用 |
|---|---|---|---|
| 月次・店舗別PL （基本的な損益管理） |
freee会計（仕訳データ）・POSレジ（売上日計）・給与計算データ（人件費） | 店舗コードをディメンション軸に持つ「fact_pl_monthly」テーブルを作成。freee仕訳の補助科目に店舗コードを統一して、取込後にBigQueryで科目×店舗の集計テーブルを生成する設計が基本 | 店舗比較バー、前月比トレンドライン、利益率ヒートマップ（店舗×月）の3ビューを標準化する。本部経営者向けと店長向けでフィルタ権限を分けて、店長は自店のみ参照可にする |
| 日次・品目別売上 （在庫・発注最適化） |
POSレジの品目別販売データ・仕入れ伝票データ・廃棄記録 | 「fact_sales_daily」テーブルに品目コード・店舗コード・販売数・廃棄数を格納。日次取込はCloud Schedulerで自動化し、前日分のデータを毎朝7時に更新する設計が一般的 | ABC分析（売上上位/中位/下位品目）、廃棄率ランキング、在庫回転率トレンドを可視化。発注担当者が毎朝確認する「発注判断ダッシュボード」として設計する |
| 時間帯・曜日別売上分析 （シフト最適化・ピーク管理） |
POSの時間帯別売上データ・Airシフト等のシフト管理データ・来客数データ | 「fact_sales_hourly」テーブルに時間帯（1時間単位）・曜日・売上・来客数を格納。シフトデータとJOINして「売上/シフト時間」の労働生産性指標を計算するカラムを追加する | 時間帯別売上ヒートマップ（曜日×時間）でピーク帯を可視化。「人件費率が高い時間帯（売上が低いのにシフトが厚い）」をアラートとして自動表示するダッシュボードにする |
| 席あたり売上・回転率分析 （立地・業態評価） |
POSの来客数・席数マスタ・営業時間データ・坪数・テナント賃料データ | 「dim_store」マスタテーブルに席数・坪数・賃料を登録し、「fact_pl_monthly」とJOINして「席あたり月次売上」「坪あたり売上」「賃料売上比率」の計算カラムをBigQueryのビューで定義する | 店舗スコアカード（席あたり売上/賃料比率/利益率の3指標をレーダーチャートで表示）で業態・立地ごとの収益性を一目で比較。出店判断・閉店判断の経営会議資料に直接活用できる形に設計する |
この表で最初に着手すべきは「月次・店舗別PL（基本集計）」です。多くの飲食チェーンで実態として発生している問題は、精緻な時間帯分析ではなく「店長が自店の損益をリアルタイムに把握できていない」という基本的なデータ可視化の欠如です。freee会計の仕訳データをBigQueryに流し込み、Looker Studioで店舗比較ができる状態を作ることを最優先とし、そこから日次・時間帯分析へ段階的に高度化する設計を推奨します。
BigQuery上での「店舗別PLマート」作成の実務
BigQueryにデータが入っただけではダッシュボードは作れません。分析しやすい形に「マート化」する作業が必要です。
店舗（部門）マスタの正規化とマッピング
freeeの「部門」は階層構造を持つことができますが、BigQuery側ではこれをフラットなマスタとして展開する必要があります。例えば、「東京エリア ＞ 新宿店」という親子関係を、分析用のカラムとして分離します。また、POSレジ側の店舗コードとfreeeの部門コードが一致していない場合、BigQuery上で「マッピングテーブル」を別途作成し、JOIN（結合）させる処理が必須となります。
FLコストを算出するクエリの勘所
飲食店の健全性を測る最重要指標「FLコスト」を算出するためには、勘定科目の紐付けをロジック化します。
- F（Food）：勘定科目「仕入高」「材料費」などを集計。
- L（Labor）：勘定科目「給料手当」「法定福利費」「福利厚生費」を合算。
ここで重要なのが、「部門別配賦」のデータです。本社の共通経費を各店舗にどう割り振るか、freee側で配賦仕訳を切っているか、あるいはBigQuery側のロジックで按分するかを設計段階で決めておく必要があります。
Looker Studio / Looker によるダッシュボード実装ガイド
可視化ツールには、無料で始められる Looker Studio、または高度なガバナンスが効く Looker が一般的です。
店長・エリアマネージャー・経営層がみるべき3つの階層
すべての層に同じ情報を見せると、情報過多で誰も見なくなります。以下の構成でページを分けるのが実務的です。
- 経営層向け（エグゼクティブ・サマリー）：全店合計の売上、営業利益、前年比推移、予算達成率。
- エリアマネージャー向け（店舗間比較）：担当エリア内の店舗ランキング（利益率順）、特定店舗の異常値（水道光熱費の急騰など）の検知。
- 店長向け（店舗詳細）：日次のFL推移、客数・客単価の相関、シフト表と連動した人時生産性の可視化。
予算対比・昨年対比のビジュアライズ
freeeの「予算管理」機能のデータもAPIで取得可能ですが、より柔軟な予算編成をExcelやGoogleスプレッドシートで行っている場合は、そのシートを直接BigQueryの「外部テーブル」として読み込み、実績値とマージさせます。これにより、「昨日の着地時点での今月の予算達成見込み」を自動算出できるようになります。
こうしたデータ活用の高度化は、単なる経理の自動化を超え、広告効果と売上の相関分析など、マーケティング領域への拡張性も秘めています。
実装時によくあるエラーと回避策
データパイプラインを運用し始めると、必ずと言っていいほど以下の問題に遭遇します。
APIレートリミット（429 Too Many Requests）
freee APIには「1分間に○回まで」というコール制限があります。数万行の仕訳データを持つ飲食チェーンが、毎回「全件取得」を試みると、途中でエラーになります。
【対処法】：前回の実行日時を記録しておき、updated_at パラメータを使用して、更新があった仕訳のみを取得する「差分更新」を実装してください。
会計データの「修正・削除」の反映
freee上で過去の仕訳が修正された場合、単純な差分更新（追記）だけでは、BigQuery側に古いデータと新しいデータが重複して残ってしまいます。
【対処法】：BigQueryの MERGE 文を使用し、id（仕訳ID）をキーにして「存在すれば更新、なければ挿入」というUpsert処理を行うか、あるいは定期的に該当月を洗い替える（Delete & Insert）処理を組み込みます。
認証認可の期限切れ
freee APIはOAuth 2.0を採用しており、アクセストークンの有効期限が短いです。
【対処法】：リフレッシュトークンを用いて、トークンを自動更新する仕組みが必要です。自社開発の場合はこの実装が最も漏れやすく、バッチが止まる原因の1位です。
まとめ：会計データを経営の「武器」に変えるために
飲食チェーンにおける「freee会計 × BigQuery」の活用は、単なる業務効率化ではありません。それは、「勘と経験」の経営から「データに基づく」経営への転換を意味します。
会計ソフトは「結果」を記録する場所ですが、BigQueryはその結果に「理由（なぜ利益が出たのか、なぜコストが増えたのか）」を紐付ける場所です。まずはスモールステップとして、freeeの部門別損益をLooker Studioで自動更新するところから始めてみてはいかがでしょうか。
導入にあたっては、freee公式のデベロッパーコミュニティや、Google Cloudの公式ドキュメントを参照し、常に最新の仕様を確認することをお勧めします。実務に即したセキュアで堅牢なデータ基盤を構築し、多店舗展開のスピードを加速させていきましょう。
経理・会計DXと仕訳／請求／債権自動化のご相談
仕訳・請求・入金消込・債権管理といった経理業務の自動化と、会計データの可視化までを一気通貫で支援します。ツール選定や既存運用の見直しについて、導入前後のセカンドオピニオンとしてもご相談いただけます。