AIの前に整えるデータ基盤：2四半期以内に投資を回収できる改善策

多くのAI計画は、自社のデータはすでに整っており、課題はモデルの選定にあると想定しています。既存企業では、データはたいてい正しいシステムに入っていますが、かたちが正しくありません。同じ顧客が3通りの形で登録され、製品コードがECサイトと倉庫で別の意味を持ち、売上高がアナリティクスのプロパティと元帳とで食い違っています。

何を直すべきかを最も早く見つける方法は、実際の記録を追うことです。注文、請求書、在庫移動のサンプルを取り、ECサイトや見積もりツールから決済事業者、CRM、倉庫を経て、会計ソフトとレポーティング層に至るまで、それに関わるすべてのシステムを1件ずつたどります。記録が手で打ち直される箇所、表計算ファイルに転記される箇所、識別子が変わる箇所、記録が消える箇所を書き留めます。それらが取り組むべき課題の一覧になります。

以下に挙げるのは、2四半期以内に投資を回収できると私たちが見込んでいる改善策です。いずれも、すでにコストを生んでいる手作業やレポーティングの誤りを取り除くものであり、後に同じ記録を読むことになるあらゆるAI機能の前提条件でもあります。

下流でのあらゆる活用は、データの結合に依存しています。顧客別の売上を出すには、受注システムと元帳が共通の顧客キーを持っている必要があります。製品別の利益率を出すには、ECサイト、倉庫、仕入元帳が製品コードの意味について一致している必要があります。注文や製品に関する質問に答えるAIアシスタントは、キーに含まれる曖昧さをそのまま引き継ぎます。

確認作業はすぐに実施できます。識別子ごとに、値が入力されているか、そして全体を通じて一意であるか、つまり一つのコードが一つの製品を指しているかを検証します。この二つは別々のテストです。製品コードの項目がすべての記録で埋まっていても、二つの異なる品目で共有されていることがあります。それだけで、アシスタントが自信満々に誤った製品を説明したり、取引先に送るカタログで正しいコードの下に誤った品目が記載されたりします。

投資の回収は、この改善によって不要になる作業から生まれます。誤出荷に伴う返金伝票、顧客への取引明細の突合に費やす時間、二つのシステムの数字が合わないために毎月手作業で作り直しているレポートなどです。

Google Analytics 4の標準プロパティでは、ユーザー単位とイベント単位のデータの保持期間は既定で2か月、最長でも14か月です。イベントデータをそれより長く保持できるのは、有料の360プランだけです。標準レポートは集計済みのテーブルで動いており、過去の合計値は表示され続けるため、誰かが前年比の探索レポートや目標到達プロセスを作り、前の期間が空であることに気づくまで、この消失は見えません。保持期間の設定を引き上げても、守られるのはまだ削除されていないデータだけです。

恒久的な解決策は、生のイベントを自社が所有するデータウェアハウスに複製するBigQueryエクスポートです。標準プロパティは、日次エクスポートで1日あたり最大100万件のイベントを送ることができます。ストリーミングエクスポートには量の上限がなく、費用は1ギガバイトあたり$0.05で、Googleはこれをおよそ60万件のイベントに相当するとしています。この料金であれば、中規模企業のストレージ費用は、前年の行動データなしで繁忙期を計画するコストに比べてわずかなものです。

この改善策には、期限が最初から組み込まれています。先延ばしにした月の数だけ、取り戻せないイベント履歴が失われます。そして2027年の計画サイクルでは、2026年の繁忙期のデータがすべて必要になるはずです。

電子請求書の導入により、顧客マスタデータはコンプライアンス上の依存関係になります。ドイツでは、前年の売上高が€800,000を超える事業者は2027年1月1日から国内の企業間取引の請求書を構造化された電子形式で発行しなければならず、それ以外のすべての事業者も2028年1月1日から続きます。受領については2025年1月1日からすでに義務化されています。英国では、政府が2029年4月からすべてのVATインボイスを電子化しなければならないと表明し、交換ネットワークとしてPeppolを採用することを確認したうえで、詳細な導入ロードマップを10月28日に予定されている2026年予算案とともに示すとしています。

投資を回収できる作業は両国で共通しており、どの期限よりもずっと前に始まります。顧客マスタ上の顧客のVAT識別番号、税務番号、電子的な送信先アドレスを揃えて検証します。請求書明細の製品コードと税コードを標準化します。受注システムと請求書の間にある手作業の手順をなくします。差し戻された請求書は入金を遅らせます。そのため、マスタデータを整えることは、規則を満たすだけでなく回収期間の短縮にもつながります。そして、今四半期にドイツ法人向けに構築したデータモデルは、後に英国でも再利用できます。

最後の改善策は、システムというより規律の問題です。経営管理レポートは、売上をECサイトやCRMから、コストを元帳から、マーケティングの成果を広告プラットフォームから取ってきますが、三つが一致することはまずありません。取締役会資料と財務諸表とが誰にも説明できない金額で食い違えば、資料のすべての数字が信頼を失い、どの数字が正しいかをめぐる議論の間、意思決定は滞ります。

これに決着をつけるのが、毎月の調整表です。月次決算の締め後、月次経営報告パックの主要な数字を一つずつ元帳と突合し、差額を、期ずれ、返金、税金、グループ内取引、テスト注文といった名前のついた定例の項目に分解します。調整表は手作業で組み立てるのではなく、システムから生成します。合意したしきい値を超える説明のつかない残差は、パックを配布する前に調査します。定例の項目に名前がつけば、残るのはたいてい、誰も文書化していなかった業務プロセスの短いリストです。

これは、あらゆるAIレポーティングアシスタントが必要とする土台でもあります。ある地域で利益率が下がった理由を問われたモデルが正しく答えられるのは、読み取る数字がすでに突合されている場合だけです。私たちがこうした調整表を元帳から外側に向けて組み立てるのは、すべてのプロジェクトを注文、元帳、ログから始めるのと同じ理由からです。ダッシュボードの質は、その下にある記録の質を超えられません。

2026年11月、実際の注文、請求書、在庫移動のサンプルをすべてのシステムでたどり、記録が打ち直される箇所、転記される箇所、新たな識別子が付けられる箇所を一つずつ洗い出します。

11月末までに、すべてのプロパティでGA4のイベントデータの保持期間を14か月に設定し、各プロパティをBigQueryにリンクして、2026年の繁忙期のデータを完全な形で残します。

12月末までに、システムをまたいで顧客、製品、注文の識別子の一意性と網羅性を確認し、AI機能や取引先向けカタログがそれに依存する前に、重複した製品コードを修正します。

ドイツ法人については、2027年1月1日より前に€800,000のしきい値を超えているかどうか、請求業務と顧客マスタデータの準備ができているかを確認し、ロードマップが公表され次第、同じデータモデルで英国の義務化への対応を計画します。

2027年1月の締めからは、名前のついた調整項目と残差のしきい値を備えた、月次経営報告パックから元帳への調整表を毎月公表します。

2027年6月までに、突合済みのデータをもとに最初のAIユースケースを選び、同じ記録からそのベースラインを測定します。