【実践】dbtで会計データを整える！仕訳・部門・取引先マスタのモデリング基礎とDX活用

企業の財務状況を可視化する会計データは、ERP（基幹系システム）やSaaS、銀行明細など多岐にわたるソースに分散しています。これらを統合し、経営判断に耐えうる「信頼できる唯一のソース（SSOT：Single Source of Truth）」を構築するには、dbt（data build tool）を用いた高度なモデリングが不可欠です。本ガイドでは、仕訳データや各種マスタの構造化、および実務上のトラブルを回避する具体的な実装手順を解説します。

1. 会計DXを加速させるdbtの役割とデータ基盤の全体像

1.1 会計データの「サイロ化」と「手作業」を技術で解決する

従来の会計業務では、各システムからCSVを出力し、表計算ソフトのVLOOKUP関数や複雑なマクロで突合する作業が常態化していました。しかし、この手法ではデータ加工プロセスがブラックボックス化し、監査対応や再現性の確保が困難です。

dbt（data build tool）とは、データウェアハウス（DWH）内でのデータ変換をSQLで行い、そのプロセスをソフトウェアエンジニアリングのベストプラクティス（バージョン管理、テスト、ドキュメント化）で管理するためのツールです。dbtを導入することで、データ変換ロジックをコードとして管理し、Gitによる履歴管理と自動テストを組み込むことが可能になります。

1.2 ELT（Extract, Load, Transform）におけるdbtの責務

モダンデータスタックにおいて、データ統合の主流はETLから「ELT」へと移行しています。これは、データを抽出（Extract）し、そのままDWHへロード（Load）した後に、DWHのリソースを使って変換（Transform）を行う手法です。dbtはこの「T（Transform）」を担います。

FivetranやTROCCO等のツールで生データをDWHへロードした後、dbtがその生データを会計基準に準拠した形式へと整形します。これにより、生データを汚さずに何度でもロジックの再試行が可能になり、データの「鮮度」と「品質」を両立できます。

関連記事：高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

2. 実務で採用すべきデータスタック：dbtを軸とした構成選定

会計データ基盤を構築する際、連携の安定性とコスト効率、そして監査に耐えうる証跡管理のバランスが重要です。以下に、主要なデータ統合ツールとDWHのスペックを比較します。

2.1 データ統合（EL）ツールの比較

2.2 データウェアハウス（DWH）の比較

dbtを実行するための計算基盤となるDWH選定は、クエリ性能とコストに直結します。

3. 【実践】会計データのモデリング設計：3層構造の定義

会計データのモデリングでは、生データをそのまま加工するのではなく、段階的に抽象度を高めていく「3層構造」が推奨されます。

3.1 ステージング層（Staging）：ソースデータの正規化

最初のステップでは、ERPや各SaaSから抽出された生の仕訳データをクリーニングします。ここでは以下の処理に限定し、複雑なビジネスロジック（配賦や税計算の組み換えなど）は含めません。

• カラム名の統一（例：ent_id → journal_entry_id）
• データ型の変換（例：文字列で入ってきた日付を DATE 型にキャスト）
• 欠損値の補完（例：部門コードがない場合に unknown を入れる）
• 重複削除（APIの再送等による重複レコードの排除）

3.2 中間層（Intermediate）：コンテクストの付与と結合

ステージング層で整えられたデータに対し、部門マスタや取引先マスタを結合（JOIN）します。会計実務で最も厄介なのは、**「マスタの有効期間」**です。例えば、2025年4月に部門名が「営業1課」から「ソリューション営業部」に変更された場合、過去の仕訳データがどちらの名称を表示すべきかをここで定義します。また、税区分コードを「10%標準税率」といった人間が理解できるラベルに変換する処理もここで行います。

関連記事：【完全版】給与ソフトからfreee会計への「部門別配賦」と仕訳連携

3.3 マート層（Mart）：エンドユーザー向け出力

最終的に、財務諸表（B/S, P/L）や予実管理レポート、監査用リストとして出力する層です。この層では、経営会議でそのまま使えるレベルまで集計・加工されます。dbtの tags 機能を使い、「監査用」「管理会計用」といった分類を行うことで、用途に応じたデータの出し分けを管理します。

4. 勘定科目・部門・取引先マスタの「履歴管理（Snapshots）」実装手順

会計組織変更に対応するために、dbtの Snapshots 機能を活用します。これは、データの変更履歴を保持する SCD（Slowly Changing Dimensions）Type 2 を自動的に実装する仕組みです。

4.1 SCD Type 2が必要な理由

通常のデータベース更新では、部門名が上書きされると過去のデータまで新しい部門名で表示されてしまいます。これでは「当時の組織図に基づいた分析」が不可能です。Snapshotsを使用すると、データの「有効開始日」と「有効終了日」をカラムとして保持し、任意の時点の組織状態を再現できます。

4.2 実装の具体的な流れ

1. dbtプロジェクト内に snapshots ディレクトリを作成：ここにSQLファイルを配置します。
2. ユニークキーの特定：部門IDなど、不変のIDを unique_key に設定します。
3. 監視対象カラムの定義：部門名や責任者名など、変更を検知したいカラムを check_cols に指定します。
4. 戦略の選択：タイムスタンプで追跡するか、ハッシュ値で比較するかを選択します（会計マスタは check 戦略が一般的です）。
5. dbt snapshot コマンドの実行：コマンドを実行すると、DWH側に履歴保持用のテーブルが生成されます。

この履歴テーブルを参照することで、「2023年度決算時点の部門マスタ」をいつでも正確に呼び出すことが可能になります。

5. 会計データ特有の「異常系」シナリオとdbtでの対処

システム導入後に最も現場を悩ませるのは、正常なフローではなく「イレギュラーなデータ」への対応です。dbtを用いた堅牢なパイプライン構築には、以下のシナリオへの備えが必要です。

5.1 取消・修正仕訳の「二重計上」リスク

ERPでは、一度確定した仕訳を「赤黒（マイナス仕訳）」で打ち消したり、直接修正したりすることがあります。dbtの incremental（増分更新）モデルを使用している場合、過去にロード済みのレコードが修正されても、デフォルトの設定では反映されません。

解決策： unique_key を設定し、merge 戦略を採用します。さらに、処理対象期間を「過去N日間」として常にオーバーラップさせてスキャンすることで、直近の修正を漏れなく取り込みます。

5.2 振込手数料ズレと合算払いの名寄せ

銀行明細と売掛債権を突合する際、手数料分が差し引かれたり、複数請求が1件で振り込まれたりします。dbtでは、こうした不一致を解消するための「名寄せ（Matching）」ロジックを中間層に実装します。

• 閾値処理：±500円以内の差分は「支払手数料」として自動的に仕訳を補完するロジック。
• 名義の正規化：銀行明細のカナ名称と取引先マスタのカナ名称を REPLACE 関数等で標準化して結合。

関連記事：【完全版】freeeの「自動消込」が効かない？ 振込手数料ズレと合算払いを撲滅する「バーチャル口座」決済アーキテクチャ

5.3 APIレートリミットによるデータ欠損

クラウド会計SaaS（freee, マネーフォワード等）からデータを取得する場合、APIの短時間での大量リクエスト制限がボトルネックとなります。

解決策： 取得ツール側で「指数バックオフ（Exponential Backoff）」を有効にします。これは、エラー時に待機時間を徐々に延ばしながら再試行するアルゴリズムです。また、dbtのテスト機能（dbt test）を使い、レコード件数が前日比で極端に減っていないかを監視する「ボリュームテスト」を実装します。

6. 実務者のためのdbt導入10ステップ：初期設計から運用まで

会計データ基盤を成功させるための標準的な導入プロセスを整理しました。

7. 導入事例の深掘り：会計データ基盤がもたらした変革

事例1：成長著しいスタートアップの予実管理（SaaS企業）

【課題】 複数の決済手段（Stripe, 銀行振込）とSalesforceの商談データがバラバラで、月次決算が終わるまで着地予想が立てられなかった。

【導入】 dbtを軸としたモダンデータスタックを構築。Salesforceの受注データとStripeの入金実績をdbt上で統合。

【結果】 決算確定を待たずに、毎日「未入金リスク」と「当月の売上着地」が可視化された。監査法人へのデータ提出もdbtのリネージ図を提示することで、加工プロセスの透明性が認められ、監査工数が大幅に削減された。

事例2：多拠点展開する小売チェーンの原価計算

【課題】 店舗ごとに異なるPOSシステムを使用しており、全社共通の在庫評価と原価計算に膨大なExcel作業が発生していた。

【導入】 全POSデータをBigQueryに集約し、dbtで移動平均法による原価計算ロジックを実装。マスタの履歴管理により、店舗の統廃合も正確に反映。

【結果】 従来10日かかっていた原価算出が、翌朝には完了する体制へ。各店長がリアルタイムで粗利を確認できるようになった。

成功の共通要因と失敗を避ける条件

• 成功の型：最初から全データを統合しようとせず、まずは「仕訳と部門マスタ」だけに絞ってSSOTを作るなど、スモールスタートを徹底している。
• 失敗の条件：データの「意味（セマンティクス）」を定義せずにツールだけを導入すること。例えば「売上」の定義が事業部と経理でズレていると、どれだけ最新の技術を使っても不信感を招く。

8. よくある誤解と正しい理解（FAQ）

9. まとめ：会計データを「死んだ数字」にしないために

会計データのモデリングは、単なる技術的な課題ではなく、経営指標の信頼性を担保する重要なプロセスです。dbtによる厳格な管理を通じて、属人化を排除し、変化に強い財務基盤を構築しましょう。データが整えば、それは単なる「過去の記録」から、次の打ち手を示す「羅針盤」へと変わります。

関連記事：【完全版・第5回】freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術

version: 2
models:
  - name: fct_journal_entries
    columns:
      - name: journal_id
        tests: [unique, not_null]
      - name: posting_date
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: "'2020-01-01'"
              max_value: "current_date"
      - name: account_code
        tests:
          - not_null
          - relationships:
              to: ref('dim_account')
              field: account_code
      - name: amount_jpy
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= -1e10 AND amount_jpy <= 1e10"
    tests:
      - dbt_utils.equal_rowcount:
          compare_model: ref('stg_journal_entries')
      - dbt_utils.expression_is_true:
          expression: "ABS(SUM(debit_amount) - SUM(credit_amount)) < 1"
          name: balance_check_journal

models/
  staging/
    accounting/
      stg_freee__journal.sql
      stg_freee__account.sql
      stg_mf__journal.sql
      _accounting__sources.yml
      _accounting__models.yml
  intermediate/
    accounting/
      int_journal_normalized.sql
      int_account_with_hierarchy.sql
      int_fx_rate_daily.sql
  marts/
    finance/
      fct_journal_entries.sql
      dim_account.sql
      dim_department.sql
      fct_pl_monthly.sql
      fct_bs_monthly.sql
      fct_cash_flow_monthly.sql
      _finance__models.yml
macros/
  fiscal_year.sql
  fx_convert.sql
  account_normalize.sql
seeds/
  account_master.csv
  department_master.csv
  fx_rate.csv
  allocation_rules.csv

name: dbt_ci
on: [pull_request]
jobs:
  dbt_test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install dbt-bigquery
      - name: Get production manifest
        run: gsutil cp gs://my-bucket/manifest.json ./prod-manifest.json
      - run: dbt deps
      - run: dbt build --defer --state ./prod-manifest.json --select state:modified+ --target ci
      - name: Upload test results
        uses: actions/upload-artifact@v4
        with: { name: dbt-target, path: target/ }

semantic_models:
  - name: pl_monthly
    model: ref('fct_pl_monthly')
    entities:
      - name: company
        type: primary
    dimensions:
      - name: posting_month
        type: time
        type_params: { time_granularity: month }
    measures:
      - name: revenue
        agg: sum
        expr: amount_jpy
        agg_filter: account_type = 'revenue'
      - name: cogs
        agg: sum
        expr: amount_jpy
        agg_filter: account_type = 'cogs'
metrics:
  - name: gross_profit
    type: derived
    type_params:
      expr: revenue - cogs
      metrics: [revenue, cogs]