飲食チェーンと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ステップで構成されます。

1. Extract（抽出）：freee APIを叩き、仕訳帳（deal/wallet_txs）、部門（partners）、取引先（items）などのデータを取得。
2. Load（格納）：取得したJSONデータをBigQueryのRawデータ層（Staging領域）にそのまま格納。
3. Transform（変換）：dbtなどのツールを用い、Rawデータを会計報告用・分析用の「データマート」へ加工。

ETLツールの選定：自社開発 vs SaaS

このパイプラインを「Pythonなどで自作」するか、「SaaS（ETLツール）」を使うかは、保守コストに直結します。以下の比較表を参考にしてください。

飲食チェーンの実務においては、専任のデータエンジニアが不在であれば、SaaSツールを活用して「データの鮮度」を優先することをお勧めします。特にfreee APIは定期的にバージョンアップや仕様変更が行われるため、自社メンテナンスの負荷は想像以上に高くなります。

BigQuery上での「店舗別PLマート」作成の実務

BigQueryにデータが入っただけではダッシュボードは作れません。分析しやすい形に「マート化」する作業が必要です。

店舗（部門）マスタの正規化とマッピング

freeeの「部門」は階層構造を持つことができますが、BigQuery側ではこれをフラットなマスタとして展開する必要があります。例えば、「東京エリア ＞ 新宿店」という親子関係を、分析用のカラムとして分離します。また、POSレジ側の店舗コードとfreeeの部門コードが一致していない場合、BigQuery上で「マッピングテーブル」を別途作成し、JOIN（結合）させる処理が必須となります。

FLコストを算出するクエリの勘所

飲食店の健全性を測る最重要指標「FLコスト」を算出するためには、勘定科目の紐付けをロジック化します。

• F（Food）：勘定科目「仕入高」「材料費」などを集計。
• L（Labor）：勘定科目「給料手当」「法定福利費」「福利厚生費」を合算。

ここで重要なのが、「部門別配賦」のデータです。本社の共通経費を各店舗にどう割り振るか、freee側で配賦仕訳を切っているか、あるいはBigQuery側のロジックで按分するかを設計段階で決めておく必要があります。

Looker Studio / Looker によるダッシュボード実装ガイド

可視化ツールには、無料で始められる Looker Studio、または高度なガバナンスが効く Looker が一般的です。

店長・エリアマネージャー・経営層がみるべき3つの階層

すべての層に同じ情報を見せると、情報過多で誰も見なくなります。以下の構成でページを分けるのが実務的です。

1. 経営層向け（エグゼクティブ・サマリー）：全店合計の売上、営業利益、前年比推移、予算達成率。
2. エリアマネージャー向け（店舗間比較）：担当エリア内の店舗ランキング（利益率順）、特定店舗の異常値（水道光熱費の急騰など）の検知。
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の公式ドキュメントを参照し、常に最新の仕様を確認することをお勧めします。実務に即したセキュアで堅牢なデータ基盤を構築し、多店舗展開のスピードを加速させていきましょう。