データアーキテクチャとは、組織がどのようなデータを集め、どこに保存し、どう加工して活用するかを定めた全体設計です。全体の設計図がないままシステムごとに個別の対応を重ねると、データが部門ごとに分断され、分析やAI活用を進めようとした段階で手戻りが発生しかねません。
本記事では、データアーキテクチャの意味や、設計がないと起こる問題、具体的な成果物、代表的な設計の考え方、AI時代に求められる設計、設計の進め方までを、社内のデータ基盤づくりを担当する方に向けて解説します。自社のデータ活用の全体像を描く際の参考にしてください。
データアーキテクチャとは、組織が扱うデータの収集・保存・加工・活用の流れと、それを支える仕組みの配置を示した全体設計を指します。建物の設計図にたとえられることが多く、どのデータがどこで生まれ、どのシステムを通って、誰に使われるのかを全社の視点で描くのが役割です。
混同されやすい言葉に、データモデリングとデータエンジニアリングがあります。データモデリングは、個々のデータの項目や関係性をモデルとして定義する作業です。
一方、データエンジニアリングは、設計にもとづいてデータ基盤やパイプラインを実際に構築・運用する取り組みです。全体の方針を決めるのがデータアーキテクチャ、個別のデータを定義するのがデータモデリング、それらを形にするのがデータエンジニアリングと整理すると分かりやすいでしょう。
データモデリングについてはこちらの記事をご覧ください。
データアーキテクチャという全体設計がないまま、部門やプロジェクトごとにシステムを構築していくと、次のような問題が起こりやすくなります。
データアーキテクチャがないと起こる問題の1つは、データがシステムごとに分断されることです。部門ごとに必要なシステムを個別に導入すると、データはそれぞれのシステムの中に閉じたままになるためです。
たとえば、営業部門の顧客管理システムと、製造部門の生産管理システムが別々に構築されていると、受注の動きを生産計画にすぐ反映させるといった横断的な活用ができません。必要なたびに担当者がデータを出力して手作業で突き合わせる状態では、分析に時間がかかるうえ、使える情報も限られます。
分断されたシステム同士をあとからつなぐ方法は、データ連携とは？代表的な手法とメリット、進まないときの対処法を解説で紹介しているので、あわせてご覧ください。
データの定義や形式が統一されないことも、データアーキテクチャがない組織で起こりやすい問題です。システムごとに項目の意味や書き方を決めていくと、同じ名前の項目でも中身が異なる状態が生まれるためです。
同じ「売上」でも、あるシステムは受注日で計上し、別のシステムは出荷日で計上しているといった違いがあると、集計結果にずれが生じます。顧客コードの桁数や日付の書式がシステムごとに異なる場合も、データを組み合わせる前に変換の手間がかかります。
部署ごとに異なる数字が報告されると、会議でどの数字が正しいのかを確かめるところから始めなければなりません。
全体設計がないと、重複した開発や変換作業が増えていきます。各部門が同じようなデータを別々に集め、似た連携処理をそれぞれ作ってしまうためです。
たとえば、営業部門と経理部門がそれぞれ基幹システムから売上データを取り出す処理を作ると、同じ変換ルールが2か所に存在することになります。システムに変更が入るたびに両方を修正しなければならず、開発と保守のコストがかさむのは避けられません。
処理が増えるほど全体像を把握できる人も限られ、特定の担当者に依存した運用になりやすい点にも注意が必要です。
セキュリティ管理が不統一になることも、データアーキテクチャがない場合の大きなリスクです。アクセス権限や保存のルールをシステムごとに決めていると、管理の水準にばらつきが出るためです。
あるシステムでは閲覧できる人を厳しく制限している顧客情報が、別のシステムやファイルでは多くの社員が見られる状態になっているといったことが起こり得ます。個人情報がどこに、いくつ保存されているかを把握できていなければ、漏えいが起きた際の影響範囲の確認にも時間がかかるでしょう。
全社で共通のルールを定め、データの所在と権限を一元的に把握できる状態を目指しましょう。
データアーキテクチャは抽象的な設計図にとどまらず、関係者が参照できる具体的な資料に落とし込んで初めて機能します。ここでは、代表的な5つの成果物を紹介します。
エンタープライズデータモデルは、企業が保有するデータの定義や関係性を全社単位で整理した資料です。個々のシステムの設計ではなく、会社全体でどのようなデータを扱っているのかを共通の言葉で示すために作成します。
顧客、商品、取引先、受注、出荷といった主要なデータの単位を洗い出し、「顧客とは何を指すか」「1件の受注に何件の出荷がひもづくか」といった定義と関係を図にまとめるのが一般的です。細かな項目まで最初から網羅する必要はなく、主要なデータの概要から整理していきます。
エンタープライズデータモデルがあれば、新しいシステムを導入する際も既存のデータとの対応を確認しやすくなります。
データフロー図は、データの発生元から保存先、利用先までの流れを可視化した資料です。どのシステムで生まれたデータが、どこを経由して、誰の業務や分析に使われているのかを一目で把握できるようにします。
たとえば、POSで記録された販売データが夜間に基幹システムへ送られ、さらに分析用の基盤に集約されてBIツールで閲覧される、といった流れを矢印でつないで表すのが基本です。データの受け渡しの頻度や方式も書き添えておくと、障害が起きたときの影響範囲をたどりやすくなります。
システムの追加や変更を検討する際も、データフロー図があればどの流れに影響が出るかを事前に確認できます。
データ基盤の構成図は、データソース、パイプライン、DWH、データレイク、BIツールなどの配置と役割を示した資料です。データフロー図が流れを表すのに対し、構成図はどの仕組みをどこに置くかという器の設計を表します。
基幹システムやSaaSなどのデータソースを左側に並べ、中央にデータを取り込むパイプラインと保存先のDWHやデータレイク、右側に分析用のBIツールやAIの仕組みを配置する形で描くと、全体像がつかみやすくなります。クラウドとオンプレミスのどちらに置くかも、構成図で明示しておきたい要素です。
データを集めて届けるまでの処理の流れについては、データパイプラインとは？仕組みや種類、ETLとの違いと構築のポイントを解説で詳しく解説しています。
データ管理のルールは、品質、権限、保存期間、責任者などについて全社共通の決まりをまとめた資料です。設計図や構成図があっても、運用のルールがなければデータの状態を保てません。
ルールとして定めておきたい主な項目は次のとおりです。
データごとに責任者を決めておけば、定義の変更や品質の問題が起きた際に、誰が判断するのかで迷わずに済みます。
導入ロードマップは、現在の状態から目標とするデータアーキテクチャへ移行する順番や期間、優先順位を整理した資料です。理想の構成を一度に実現するのは難しいため、段階ごとの到達点を示しておく役割があります。
ロードマップには、各段階で取り組む範囲、完了の目安となる時期、必要な体制や予算、次の段階へ進む条件などを記載します。「半年で販売と在庫のデータを統合し、1年後に顧客データまで広げる」のように、段階ごとの到達点を関係者が同じ認識で共有できる形にまとめるのがポイントです。
ロードマップがあれば、経営層への説明や予算の確保もしやすくなります。
データアーキテクチャには、組織の規模やデータ活用の目的に応じた代表的な設計の考え方があります。いずれかを1つ選ぶというより、自社の状況に合わせて組み合わせて使うことも多いため、それぞれの特徴を比較しておきましょう。
| 考え方 | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| 集中型アーキテクチャ | 全社のデータを1つの基盤にまとめ、中央のチームが管理します。 | データの種類や部門が少なく、全社で統一した管理をしたい場合に適しています。 | 中央チームに依頼が集中して、対応が遅れやすくなります。 |
| 分散型アーキテクチャ | 部門やシステムごとにデータを保有して管理を行います。 | 部署によって業務やデータの性質が大きく異なる場合に向いています。 | 全社共通のルールがないと、データが分断されやすい点に気をつけます。 |
| データメッシュ | 業務領域ごとのチームがデータに責任を持ち、製品として他部門へ提供します。 | 大規模な組織であり、各部門にデータを扱える人材がそろっている場合に適しています。 | 共通ルールの整備と、各部門における体制づくりが求められます。 |
| データファブリック | メタデータを活用し、点在するデータを横断的につないで統合や管理を支援します。 | 既存のデータウェアハウスやデータレイクを活かしつつ、分散したデータを使いたい場合に向いています。 | メタデータを継続的に整備し、更新しなければなりません。 |
| データレイクハウス | データレイクのコストを抑えた保存と、データウェアハウスの管理機能を1つの仕組みで併せ持ちます。 | 分析用の構造化データと、画像や文書などの非構造化データを同じ基盤で使いたい場合に適しています。 | 既存のシステムからの移行計画を事前に立てる必要があります。 |
集中型と分散型は、データを誰がどこで管理するかという基本的な方針の違いです。
生成AIやAIエージェントの活用が広がるなかで、データアーキテクチャには、従来の集計や分析に加えてAIへデータを提供するための設計も必要になっています。ここでは、AI時代のデータアーキテクチャで押さえておきたい4つのポイントを解説します。
AI時代のデータアーキテクチャでは、構造化データと非構造化データの両方を扱えるようにしましょう。生成AIが力を発揮するのは、数値の表だけでなく、文書や画像、ログといった形の決まっていないデータを読み解く場面が多いためです。
社内の業務マニュアルや議事録、設計書、問い合わせ履歴、設備の点検画像などは、従来のDWHでは扱いにくいデータでした。データレイクやデータレイクハウスなど非構造化データを保存できる仕組みを基盤に組み込めば、売上や在庫の数値とあわせて、文書や画像もAIの判断材料として使えるようになります。
非構造化データは量が多く形式もさまざまなので、どのデータをどこに保存し、どう分類するかのルールもあわせて決めておきましょう。
AIに正しくデータを使わせるには、データの意味と背景を管理しましょう。AIは項目名や数値だけを見ても、それが何を表し、どのような条件で集計されたものかを判断できないためです。
データの意味と背景を管理する方法として、メタデータの整備があります。メタデータとは、データの定義や作成元、更新日、計算方法など、データについて説明する情報です。さらに、業務で使う用語とデータの項目をひもづけるセマンティック層を整えれば、「粗利」や「稼働率」といった言葉が、どのデータのどの計算を指すのかをAIにも人にも一貫して伝えられます。
意味の定義があいまいなままでは、AIが誤った数字を根拠に回答するおそれがあります。メタデータの整備は、AI活用の前に取り組んでおきましょう。
社内の文書を生成AIに活用させるなら、RAGやベクトル検索に対応した設計を取り入れましょう。生成AIは学習していない社内の情報を知らないため、質問に応じて必要な文書を探し出し、AIに渡す仕組みが必要になるためです。
RAG（検索拡張生成）は、質問に関連する情報を検索して取り出し、その内容をもとに生成AIに回答させる仕組みです。社内文書を意味の近さで検索できるようにするため、文書を数値の並びに変換して保存し、ベクトル検索で関連する箇所を取り出す構成がよく使われます。
データアーキテクチャの観点では、どの文書を検索の対象にするか、文書が更新されたときに検索用のデータをどう更新するかまで設計しておくことが重要です。古い文書が残ったままでは、AIが最新ではない情報をもとに回答してしまいます。
AIにデータを提供する際は、権限と利用範囲を制御しましょう。AIがあらゆるデータにアクセスできる状態では、本来その利用者が見られない情報まで回答に含まれてしまうおそれがあるためです。
たとえば、社内向けのAIアシスタントに人事評価や給与のデータが検索対象として含まれていると、権限のない社員の質問に対しても、それらの情報をもとに回答してしまう可能性があります。利用者ごとのアクセス権限をAIの検索にも引き継ぎ、閲覧できる範囲のデータだけを回答の材料にする設計が必要です。
AIエージェントのように、AIがデータを読むだけでなく更新や操作までおこなう場合は、実行できる操作の範囲もあらかじめ制限しておきましょう。
データアーキテクチャは、構想から実装までを段階的に進めることで、実際に使われる設計になります。ここでは、設計を進める際の6つのステップを解説します。
データアーキテクチャを設計する際は、まずデータを活用する目的を明確にしましょう。目的が決まっていないと、どのデータを優先して集め、どこまで整えればよいのかを判断できないためです。
目的は、「欠品を減らすために需要予測の精度を上げたい」「月次の経営会議資料を自動で作成したい」のように、改善したい業務や意思決定の単位で定めます。経営層や業務部門の担当者にも話を聞き、現場で困っていることや判断に使いたい数字を洗い出しておくと、設計の方向性がぶれにくくなります。
目的の優先順位をつけておけば、後の工程で範囲を絞り込む際の判断基準として使える点も利点です。
次に、現在のデータとシステムを可視化しましょう。今あるデータの状態を把握しないまま将来の姿を描いても、移行の道筋を立てられないためです。
可視化の対象は、どのシステムにどのようなデータがあるかという所在、データの形式や件数、システム間のデータの流れ、そして各データの管理者です。表計算ソフトで一覧にまとめ、主要な流れはデータフロー図に描き起こしておくと、関係者で共有しやすくなります。
調べていく過程で、同じデータが複数の場所にある、誰も管理していないデータがあるといった課題も見えてきます。
現在の状態を把握したら、将来必要になるデータを定義しましょう。今の課題だけに合わせて設計すると、事業の拡大や新しい取り組みに対応できず、数年で作り直しが必要になるおそれがあるためです。
事業計画で予定している新サービスや海外展開、今後取り組みたいAI活用などを踏まえ、どのようなデータがどれくらいの量と頻度で必要になるかを要件として整理します。たとえば、設備の故障予測を将来の目標に据えるなら、今のうちからセンサーデータを蓄積できる設計にしておく必要があります。
将来のすべてを見通すことはできないため、想定できる範囲で要件を定義し、変化に対応できる余地を残しておくことが大切です。
要件が定まったら、目標とするデータ構造と流れを設計しましょう。目的と要件を実際の仕組みに置き換えることで、構築に着手できる設計図になるためです。
この段階では、エンタープライズデータモデルでデータの定義と関係を決め、データフロー図で流れを描き、データ基盤の構成図でDWHやデータレイク、BIツールなどの配置を決めます。集中型やデータメッシュなど、どの考え方を採用するかもここで判断します。
目標の設計ができたら、段階的な導入計画を立てましょう。データ基盤を一度にすべて作り替えようとすると、費用と期間がかさむうえ、途中で方針の見直しが必要になった際の影響も大きくなるためです。
計画では、最初に取り組む範囲を、効果が見えやすく規模の小さい領域に絞ります。たとえば、まず販売と在庫のデータを統合して経営ダッシュボードを作り、成果を確認してから顧客データや生産データへ対象を広げるといった進め方です。各段階の成果と課題を次の段階の計画に反映させれば、手戻りを抑えられます。
計画の内容は導入ロードマップとして資料にまとめ、関係者と共有しておきましょう。
データアーキテクチャは一度作って終わりにせず、定期的に設計を見直しましょう。事業の内容や組織、利用できる技術は変わり続けるため、設計が古いままでは新しいニーズに応えられなくなるためです。
たとえば、新しい事業の立ち上げや組織の再編、基幹システムの刷新、生成AIのような新技術の登場は、見直しのきっかけになります。半年や1年ごとなど見直しの時期を決めておき、成果物の内容が実態とずれていないかを確認しましょう。
見直しの責任者と手順も決めておけば、担当者の異動があっても設計が放置されずに済みます。
ブライセンのデータエンジニアリングサービスは、データアーキテクチャの構想を描くだけでなく、多様なデータソースからの取得、目的に合わせた構造化・加工、業務で使える形での提供まで、設計を実際に動く仕組みへ落とし込むまでを支援するサービスです。
弊社は、データの収集・蓄積にとどまらず、目的起点のデータ設計から基盤構築、運用・改善までを一貫して支援しています。日本とベトナムの開発体制により品質とコストの両立を図り、自動車業界をはじめ、製造業やプラント分野の企業様を支えてきた実績があります。
システムごとに継ぎ足してきたデータ基盤を見直したい、AI活用を見据えて全体の設計から考え直したいという方は、お気軽にご相談ください。
データアーキテクチャは、組織のデータをどう集め、保存し、加工して活用するかを定めた全体設計です。全体設計がないままシステムを個別に構築すると、データの分断や定義の不統一、重複した開発、セキュリティ管理のばらつきといった問題が起こりやすくなります。
設計の内容は、エンタープライズデータモデルやデータフロー図、基盤の構成図、管理ルール、導入ロードマップといった成果物に落とし込みます。AI時代には、非構造化データの扱いやメタデータの整備、RAGへの対応、権限の制御まで視野に入れた設計が重要です。
データアーキテクチャは、データをためる場所を決めるだけでなく、ビジネスやAIで活用するまでの全体像を描くための設計です。まずは自社のデータを何に使いたいのかという目的を言葉にするところから、設計の第一歩を踏み出しましょう。
