AI Data Readiness（AIDR）
AI Data Readiness（AIDR）により業務変革に備える
OpenAIのChatGPT、Google GeminiやGoogle AI Studio、AnthropicのClaude、Perplexityをはじめ、各社が提供する生成AI・LLMは日々体感できるほどの速度で進化しています。
業務変革のためにAI自体の効果的な活用方法を追及することは確かに重要ですが、AI Data Readiness（AIDR）としてデータ活用基盤の導入整備を行っておくことは今後の業務変革のために欠かせない前提となります。
以下に株式会社リクリオが考えるデータ活用基盤設計・構築・運用におけるBest Practiceをホワイトペーパーとして提唱します。
Data Utilization Best Practices
データ活用基盤設計・構築・運用におけるBest Practice
データ活用基盤の設計コンセプト、目指す提供価値、実現アーキテクチャ、運用を考慮したデザインの観点に基づき弊社が考える効果的な指針について以下にリスト形式で内容をまとめます。
Data Centralizization
1. データは1箇所に集約して管理する
- 社内に分散しているデータを一カ所に集めて管理する
- 複数の異なるシステムのトランザクションやログデータ、IoT機器からのセンサーデータ、データ定義、運用に必要なナレッジを一カ所に集約し、技術者だけでなくビジネス側からもすぐに使える状態にしておく
- 異なるデータソースや種類のデータをJOIN・結合することで全社で保有するデータを横断的に活用し、経営およびビジネスの改善に必要な新たな知見やインサイトの獲得を可能とする
- データDictionaryやデータカタログ、メタデータ、データ定義書を統一された仕組や方法で一元管理することを可能とする
- 必要なアカウントへ、必要な時に、必要なデータへアクセス権の付与を実現すると共にセキュリティルール、データガバナンスの一元管理を実現する
Raw Data as a Primary Source
2. データは丸めないでそのまま保存する ～1次データとしてのRawデータの価値～
DataLakeやデータ基盤へのデータ連携時にはデータ集計や変換はかけずにRawデータをそのまま1:1で取り込む
- 連携元sourceシステムと連携先のtargetとなるデータ基盤での件数一致がデータ整合性確認のための最も素早く簡易な検証方法となる
- 連携プロセスの中で件数の集計や変換が行われるような連携を行うとトラブル発生時を含め、簡易で迅速な整合性確認の妨げになる場合がある
- sourceからのRawデータの取り込み時に必要なカラムの絞り込みは行っても良い
- 例: SAP（ERP）などパッケージシステムのデータは予め準備されているカラム数が膨大で、利用されていない不要なカラムも多数存在するためデータ連携にあたり必要なカラムについてあらかじめ取捨選択を行う
データsourceからRawデータをデータ基盤に連携することで、ビジネス側を含めた一次情報としてのデータ活用が可能になる
- 一次情報としてのRawデータをデータ基盤に保持しておくことで今後も含めたあらゆるデータ活用ニーズへの自由度の高いデータ活用の可能性を確保
- 任意のデータソースから任意のタイミングで任意のフォーマットで高い自由度を持ってデータの出力運用が可能になる
- 例:
- CRMのターゲティング
- 帳票出力
- 生成AIで活用するためのRAG環境の構築
- 例:
- データソース側のデータ提供者とデータ基盤側のデータ利用者で同じデータを見ながら共通の理解に基づきディスカッションから始めることが可能となる
- 集計済データを利用者に提供する場合は常に集計ロジックの提供をセットで行えるための仕組を準備しておく
- 変換ロジックや変換に使われるSQLのqueryを機械的にGitHubなどのリポジトリやBIのconfigから抜き出して提供できる仕組を準備しておく
- Transparency、透明性の確保（↔ブラックボックス）
- 良く起きる問題
- 似たような異なるレポートが乱立し、数値の不一致の説明が常に求められる
- Rawデータからどのようなロジックにより結果が出力されたかの説明や対応に追われる
- 似たような異なるレポートが乱立し、数値の不一致の説明が常に求められる
- 変換ロジックや変換に使われるSQLのqueryを機械的にGitHubなどのリポジトリやBIのconfigから抜き出して提供できる仕組を準備しておく
Simple & Universal desgin
3. シンプルETL設計・誰が見てもわかりやすい王道のデザインに基づく設計・実装・運用 ～ユニバーサルデザイン～
ETLやデータ基盤など利用ツールの種類に関わらず常にシンプルで誰が見てもわかりやすい設計を心がける（見出し）
- 属人性を排除しツール依存の機能の利用を低減する
- 同じ人材がデータ連携、基盤の開発・運用・保守をし続ける前提は予め排除する
- シンプルでわかりやすい王道な機能活用に基づいた実装を行うことにより外部人材、オフショア人材、新規プロジェクト人材が着任した時に短時間でのナレッジ共有と速やかなonboardingを実現可能とする
- ツール毎に依存性のある特定の目的のみに特化したGUIや特殊機能の活用についてはデータ基盤の基本レイヤーと分けて考え、上位レイヤーによる付加価値として構築管理する
- ベンダー製品、OSSのPythonなどETLツールに関わらず同じ原則やコンセプトでデータ基盤へのデータ連携構築を実現する
- 一方GUIやノーコードツールの活用はビジネスユーザによるself分析などには有効でありデータ活用の民主化への貢献を可能とする
- 運用を考慮したデザイン
- 一度の実行でリカバリ可能なworkflow、JOB-NETのジョブチェーンの構成による運用時のリカバリを考慮したデザインでの設計と実装を行う
- Jobが失敗した箇所の障害を取り除き、既定のリカバリポイントから再実行することで正しい整合性を持ったデータのリカバリが完了できること
- 何回実行してもデータが不要にappendされていくというようなデザインではなく、正しい状態への復帰が完了できること
- リカバリ完了後はレコードの件数の一致によるシンプルな方法で整合性の確認を完了できること
実現方法・アーキテクチャ
- どのテーブル、カラムを対象として連携元システムから連携先のデータ基盤へ連携を行うか選定を行い、Rawデータのまま変換を加えず1:1のデータ連携を設計構築する
- データ変換、集計などのロジックはクエリにより実現する
- ツールに依存しないユニバーサルな技術による構築の実現が可能になる
- オフショアによる海外人材とのやりとりもツールに依存せずSQLを共通言語として対応可能
- ツールに依存しないユニバーサルな技術による構築の実現が可能になる
- GitHubでConfigやデータ変換ロジックの一元管理を実現する
- 改修、運用、仕様変更に関する厳密な差分をバージョン毎に正確に管理可能とする
- 問題が発生した時にいち早くロールバックによる復旧が可能
- リポジトリにナレッジを集約する
- 長年に渡るデータエンジニア、データサイエンティスト、マーケターの考えたナレッジを1箇所で蓄積管理する
- 先人とのコラボレーション、ナレッジ共有の仕組化を実現する
- 長年に渡るデータエンジニア、データサイエンティスト、マーケターの考えたナレッジを1箇所で蓄積管理する
- 改修、運用、仕様変更に関する厳密な差分をバージョン毎に正確に管理可能とする
- 軽量で低負荷の処理実行が可能な設計によるデータパイプラインを構築する
- 目的とする処理に対して適切なまとまり、セグメントの分割に基づく組み立てを行う
- クエリのチューニングを最適化する
- 統計情報やSQLの実行計画の適切な取得管理によるパフォーマンス最適化を実現する
Leveraging Query Logs
4. より高度で革新的なデータ活用の試み ～クエリログの再利用～
- データ分析基盤側で実行されるクエリログを保存再利用する仕組を構築する
- よく使われるクエリをログからランキング化して再利用する仕組を構築する
- データサイエンティスト、マーケター、その他BIから実行されるクエリ分析を行うことで利用実績の高い効果的なクエリについて組織内で共有して再利用を行うことを可能とする
- シンタックス的にも実行が保証されるクエリを収集カタログ化、再利用することで組織内の技術レベル向上に寄与し組織全体として高次元なデータ分析活用を行う方法の仕組化を実現する
- 各ユーザが実行しているクエリログを保存し、分析する仕組みにより、業務に関係のない不正なクエリが実行されていないかを確認可能
- セキュリティに関わる監査やAuditの観点からも有効
- よく使われるクエリをログからランキング化して再利用する仕組を構築する