経営レポートの信頼性を高める！Dataformで実現する会計データマートのブレない定義管理と活用術

経営会議の席上で、部署ごとに売上や利益の数値が異なり、本来議論すべき経営戦略ではなく「どの数字が正しいのか」という確認に時間を費やしていないでしょうか。この問題の本質は、会計データの集計ロジックが各担当者のExcelやBIツールの計算フィールド、あるいは属人化したSQLクエリに分散し、ブラックボックス化していることにあります。

本ガイドでは、Google Cloudのデータ変換ワークフロー管理サービスであるDataformを活用し、全社で統一された定義を持つ「会計データマート」を構築する実務的な手法を解説します。SQLによる定義のコード化（Infrastructure as Code：コードによるインフラ管理の考え方）を会計領域に導入することで、数値の信頼性と監査性を劇的に向上させることが可能です。

1. なぜ会計データの統制にDataformが必要なのか

従来の会計データ管理では、ERPや会計ソフト（freee会計、マネーフォワード クラウド会計、SAP等）から出力したデータをExcelで加工する、あるいはBIツール上で場当たり的に計算式を組む手法が一般的でした。しかし、これらの手法には「定義の変更履歴が追えない」「ロジックが特定の担当者に依存する（属人化）」「データの整合性チェックが手動」という重大なガバナンス上のリスクが存在します。

Dataformは、BigQuery上で動作するデータ変換パイプラインの管理ツールです。SQLをベースとした「SQLX」という言語を用い、ソフトウェア開発と同様の「バージョン管理（Git連携）」や「自動テスト」をデータ加工プロセスに持ち込みます。これにより、経理・経営企画・データエンジニアの三者が、同一のコードを参照して数値の根拠を確認できる「単一の真実（Single Source of Truth）」を構築できます。

Dataformと主要ツールの機能・料金比較

モダンデータスタックにおける主要な変換ツールであるdbtと比較した場合、Dataformは特にGoogle Cloud環境における統合性とコスト効率において優位性があります。

DataformはGoogle Cloudに完全に統合されているため、IAM（IDとアクセスの管理）による権限制御が容易であり、企業内のセキュリティポリシーに準拠させやすいのが特徴です。

2. 会計データマートを構築するメリットと実務への影響

単なる「集計の自動化」に留まらない、Dataform導入による実務上のメリットは以下の通りです。

• 監査対応の迅速化： 「なぜこの売上原価の数値になったのか」というロジックがすべてコードとしてGit履歴に残るため、監査法人への説明責任を容易に果たせます。
• 異常値の自動検知： 「仕訳の二重計上」や「予期せぬマイナス売上」などを自動テスト（アサーション）で検知し、誤ったレポートが経営陣に届くのを未然に防ぎます。
• 再利用性の向上： 一度定義した「月次確定利益」のロジックを、管理会計用レポート、予算管理ツール、広告運用最適化など、複数の用途で使い回すことができます。

関連記事：楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャ

3. Dataformによる会計データマート構築の10ステップ

正確で揺るぎないデータマートを構築するための詳細な手順を解説します。

Step 1：BigQueryへの生データ集約（ELフェーズ）

freee会計やマネーフォワード等のSaaS、または既存のERPからデータをBigQueryの「Raw Layer（生データ層）」にロードします。この際、加工（変換）は一切行わず、ソースシステムのスキーマをそのまま維持することが鉄則です。API連携にはGoogle Cloud Data Transfer Serviceや、Fivetran、TroccoなどのETLツールを活用します。

Step 2：Dataformリポジトリの作成と初期化

Google CloudコンソールからDataformを起動し、リポジトリを作成します。開発、ステージング、本番の環境ごとにワークスペースを分ける設計が推奨されます。

Step 3：Git連携の設定

GitHubやGitLabなどのリモートリポジトリと連携させます。これにより、SQLの変更履歴をコミット単位で管理し、問題が発生した際に過去の状態へ即座にロールバック（差し戻し）できる体制を整えます。

Step 4：宣言（Declaration）によるソース定義

BigQuery上の生データテーブルをDataform内で「source」として宣言します。これにより、後続のSQLXファイルで${ref(“table_name”)}という形式でテーブルを安全に参照できるようになります。

Step 5：ステージング層（Staging Layer）の構築

生データのクリーニングを行います。具体的には、「数値型の統一（文字列からNUMERICへ）」「タイムゾーンのJST変換」「NULL値のデフォルト値埋め」「不要カラムの削除」など、会計集計の「下地」を作る工程です。

Step 6：中間変換層（Intermediate Layer）でのロジック実装

複数のテーブルを結合し、会計特有のロジックを実装します。例えば、仕訳データと部門マスタ、配賦ルールを結合し、部門別の費用按分計算を行うといった処理をこの層で行います。

Step 7：データマート層（Mart Layer）の完成

BIツールやレポートから直接参照される最終的なテーブルを定義します。会計用語で言えば「試算表（TB）」や「管理損益計算書（PL）」の形式に整えるフェーズです。

Step 8：アサーション（自動テスト）の実装

データの品質を担保するためのテストコードを書きます。

• non_null: 必須項目（仕訳日、金額など）に空値がないか
• row_count: データが0件になっていないか
• unique_key: 主キー（仕訳IDなど）が重複していないか

これらをSQLXのassertionsブロックに記述します。

Step 9：ワークフローのスケジュール設定

Cloud SchedulerやDataformの「リリース構成」機能を用い、月次決算のタイミングや日次更新のスケジュールに合わせてジョブを実行させます。

Step 10：権限設計と監査ログの有効化

データの閲覧権限、編集権限を厳密に分離します。また、Cloud Loggingを通じて「誰がいつジョブを実行したか」の証跡を残します。

4. 会計実務における「異常系」への対処シナリオ

データパイプラインは常に正常に動くとは限りません。会計業務において特に注意すべき異常系シナリオと、Dataformでの対処法をまとめました。

5. 運用・管理のベストプラクティス

5-1. サービスアカウントの最小権限原則

Dataformの実行には、デフォルトのサービスアカウントではなく、特定のBigQueryデータセットへの読み書き権限のみを持つカスタムサービスアカウントを使用することを推奨します。詳細はGoogle CloudのIAMドキュメント^[2]を確認してください。

5-2. SQLXによる「ビジネスロジック」のドキュメント化

Dataformでは、SQLXファイル内に直接テーブルやカラムの説明（description）を記述できます。これがそのままBigQueryのメタデータとして反映されるため、データカタログとしての役割も果たします。
「このカラムは税抜金額か税込金額か」といった実務上の疑問が、コードとドキュメントの両面で解消されます。

5-3. 依存関係の可視化

Dataformの依存関係グラフ（DAG）を活用し、複雑になりがちな会計データの流れを可視化します。これにより、上流の計算ロジックを変更した際に、どのレポートに影響が出るかを事前に把握できます。

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

6. 導入事例：日本経済新聞社におけるデータ基盤刷新

Dataform（およびその前身技術）の活用事例として著名なのが、日本経済新聞社です。同社では膨大な購読データや広告データをBigQueryに集約し、Dataformを用いてデータ変換の民主化を推進しました。

• 課題： データ加工ロジックが各部署のエンジニアに分散し、保守性が低下していた。
• 施策： Dataformを導入し、データ変換をSQLベースで一元管理。非エンジニアでもロジックを理解・修正できる体制を構築。
• 成果： データパイプラインの構築スピードが向上し、数値定義の不一致が解消。エンジニアの負担軽減とデータ利活用の加速を両立させた。^[3]

このように、会計データに限らず「信頼性が求められる全社的な数値」の管理において、Dataformは強力な武器となります。

7. 会計データ活用を高度化するアーキテクチャ

Dataformで整備された高品質なデータマートは、単なる可視化を超えたビジネス価値を生み出します。

7-1. 広告最適化（リバースETL）への応用

会計上の「確定利益」データをBigQueryからGoogle広告やMeta広告に書き戻す（リバースETL）ことで、見かけの売上ではなく、真の粗利に基づいた広告運用の自動最適化が可能になります。これには、コンバージョンAPI（CAPI）との連携が不可欠です。

関連記事：広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

7-2. SFA/CRMへの実績値フィードバック

営業担当者が日常的に使用するSalesforce等の画面に、会計側で確定した入金状況や未払残高を表示させます。これにより、営業と経理の「数値のズレ」による確認コストを排除し、債権回収リスクの早期発見につなげることができます。

8. Dataform運用に関するFAQ（よくある質問）

Q: SQLXは習得が難しいですか？

A: 基本は標準SQLです。テーブル参照を${ref("...")}と書くなどの特有の記法はありますが、エンジニアやSQLが書ける経理担当者であれば、数日で慣れることが可能です。JavaScriptを用いた動的なクエリ生成も可能ですが、保守性を考慮して最小限に留めるのが実務上の定石です。

Q: Dataform自体の利用料金は本当に無料ですか？

A: はい。Dataformの機能利用自体に料金はかかりません。ただし、Dataformが発行するSQLによってBigQuery側で発生するスキャン料金や、リポジトリを保存するCloud Source Repositories等の料金は発生します。dbt Cloudのような「1ユーザーあたり月額○ドル」というライセンス費用がかからない点は大きなメリットです。

Q: 既存のdbtプロジェクトから移行できますか？

A: 可能です。ただし、dbtのJinja2テンプレートをDataformのSQLX/JavaScript形式に書き換える必要があるため、大規模なプロジェクトでは移行ツールや検証期間が必要です。Google Cloudへの集約を優先する場合に検討すべき選択肢です。

Q: データの機密性（給与データなど）をどう守りますか？

A: BigQueryのカラムレベルのアクセス制御（Policy Tags）を併用します。Dataformで変換後のマートに対しても、特定の属性を持つユーザーしか閲覧できないよう制限をかけることで、ガバナンスと利便性を両立できます。

Q: 小規模な経理チームでも導入すべきですか？

A: スプレッドシートの関数が複雑化し、作成者以外がメンテナンスできなくなっている（いわゆる「Excel秘伝のタレ」状態）のであれば、小規模であってもDataformによるコード管理への移行は長期的なメンテナンスコストを下げ、リスクを軽減します。

Q: データの更新が失敗したとき、どう通知を受け取りますか？

A: Cloud LoggingおよびCloud Monitoringと連携させ、Slackやメール、PagerDutyなどへアラートを飛ばす設定が一般的です。Dataform内のワークフロー実行履歴からも詳細なエラーログを確認できます。

まとめ：数値の信頼性が組織のスピードを決定する

Dataformを活用した会計データマートの構築は、単なるシステムの導入ではありません。「経営数値の定義をコードとして一元管理し、その正しさを自動で検証する」という、データガバナンスの確立そのものです。

誰が計算しても同じ結果になる、根拠が透明化されたデータマートこそが、迅速かつ的確な意思決定の基盤となります。まずは、最も属人化が進んでいる特定の勘定科目や、月次レポートの1セクションからコード化を始めてみてはいかがでしょうか。

// definitions/marts/finance/fct_pl_monthly.sqlx
config {
  type: "incremental",
  uniqueKey: ["posting_month", "department_code"],
  description: "月次PL by 部門",
  schema: "marts_finance",
  assertions: {
    nonNull: ["posting_month", "department_code", "revenue_amount"],
    uniqueKey: ["posting_month", "department_code"]
  }
}

WITH source_data AS (
  SELECT
    DATE_TRUNC(posting_date, MONTH) AS posting_month,
    department_code,
    SUM(IF(account_type = 'revenue', amount_jpy, 0)) AS revenue_amount,
    SUM(IF(account_type = 'cogs', amount_jpy, 0)) AS cogs_amount,
    SUM(IF(account_type = 'opex', amount_jpy, 0)) AS opex_amount
  FROM ${ref("stg_journal_normalized")}
  ${when(incremental(), `WHERE posting_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)`)}
  GROUP BY 1, 2
)
SELECT
  posting_month,
  department_code,
  revenue_amount,
  cogs_amount,
  revenue_amount - cogs_amount AS gross_profit,
  opex_amount,
  revenue_amount - cogs_amount - opex_amount AS operating_profit
FROM source_data

config {
  type: "assertion"
}
SELECT
  posting_month,
  department_code,
  COUNT(*) as duplicate_count
FROM ${ref("fct_pl_monthly")}
GROUP BY 1, 2
HAVING duplicate_count > 1