ストーリー
田
田中VPoE
「AI適用判断の4軸のうち、最も重要なのがデータだ。AIの性能はデータの質と量に直結する。今回はデータ可用性を深掘りしよう。」
あなた
「データがなければAIは動かないですからね。」
あ
田
田中VPoE
「その通り。しかも、データがあるだけでは不十分だ。量は足りるか、品質は十分か、アクセスできるか、この3つを評価する必要がある。」
あなた
「データの棚卸しですね。」
あ
田
田中VPoE
「そうだ。そしてデータが不足している場合のギャップ分析と対策も考えよう。」
データ可用性の3つの評価軸
| 評価軸 | 質問 | 評価ポイント |
|---|---|---|
| 量（Volume） | 十分なデータ量があるか | レコード数、期間、バリエーション |
| 質（Quality） | データは信頼できるか | 正確性、完全性、一貫性、鮮度 |
| アクセス性（Accessibility） | データに到達できるか | 権限、フォーマット、取得方法 |
軸1: データ量の評価
AI手法別の必要データ量の目安
| AI手法 | 必要データ量の目安 | 例 |
|---|---|---|
| ルールベース | データ不要 | IF-THENルール |
| 生成AI（プロンプト） | 少量のFAQデータ | RAG用ナレッジベース100記事程度 |
| 生成AI（ファインチューニング） | 数百〜数千件 | 業界特化の言語モデル調整 |
| 分類モデル（ML） | 各クラス100件以上 | レビューのポジティブ/ネガティブ分類 |
| 回帰モデル（ML） | 数千件以上 | 需要予測、売上予測 |
| 画像認識 | 各カテゴリ数百枚以上 | 商品分類、検品 |
| 異常検知 | 正常データ数千件以上 | 不正注文検知 |
NetShop社のデータ量評価
| データ | 蓄積量 | 必要量 | 判定 |
|---|---|---|---|
| 問い合わせログ | 月3万件（年36万件） | RAG用: 数百記事 | 十分 |
| 注文データ | 月1.5万件（年18万件） | 需要予測: 数千件 | 十分 |
| 商品データ | 10万SKU | 分類: 数百件/カテゴリ | 十分 |
| アクセスログ | 月数億PV | レコメンド: 数百万件 | 十分 |
| 入荷検品画像 | なし | 画像認識: 数百枚/カテゴリ | 不足 |
| 不正注文データ | 月50件（年600件） | 異常検知: 数千件 | 不足 |
軸2: データ品質の評価
データ品質の6次元
| 次元 | 定義 | 評価方法 | 基準値の目安 |
|---|---|---|---|
| 正確性 | データが事実を正しく反映 | サンプリング検証 | 99%以上 |
| 完全性 | 必須項目に欠損がない | NULL/空白チェック | 95%以上 |
| 一貫性 | システム間で矛盾がない | クロスチェック | 98%以上 |
| 鮮度 | 最新の情報に更新されている | 更新日時チェック | 24時間以内 |
| 一意性 | 重複データがない | 重複チェック | 99%以上 |
| 適合性 | 定義されたフォーマットに準拠 | スキーマ検証 | 99%以上 |
NetShop社のデータ品質評価
| データ | 正確性 | 完全性 | 一貫性 | 鮮度 | 総合評価 |
|---|---|---|---|---|---|
| 商品マスタ | 95% | 85% | 90% | 週次更新 | やや不足 |
| 注文データ | 99% | 99% | 98% | リアルタイム | 良好 |
| 問い合わせログ | 90% | 80% | 85% | リアルタイム | 要改善 |
| 在庫データ | 95% | 90% | 80% | 日次更新 | やや不足 |
| 顧客データ | 92% | 88% | 85% | 月次更新 | やや不足 |
品質問題の具体例
| データ | 品質問題 | 影響 |
|---|---|---|
| 商品マスタ | サイズ・重量の入力漏れ15% | 物流の梱包サイズ選定に支障 |
| 問い合わせログ | カテゴリ分類の不統一20% | AI学習用データとして品質不足 |
| 在庫データ | EC在庫とWMS在庫の不一致20% | 在庫切れによる機会損失 |
| 顧客データ | 住所の表記揺れ | 配送トラブルの原因 |
軸3: データアクセス性の評価
アクセス性の評価項目
| 項目 | 説明 | 評価 |
|---|---|---|
| 権限 | 誰がアクセスできるか | 個人情報はアクセス制限あり |
| フォーマット | 構造化/非構造化か | CSV、JSON、自由記述テキスト等 |
| 取得方法 | APIか手動エクスポートか | API連携の可否 |
| リアルタイム性 | どの頻度で取得できるか | リアルタイム、バッチ、手動 |
| コスト | データ取得にかかるコスト | API利用料、ストレージ費用 |
NetShop社のデータアクセス性
| データソース | フォーマット | 取得方法 | リアルタイム性 | 課題 |
|---|---|---|---|---|
| BigQuery（EC系） | 構造化 | API / SQL | リアルタイム | 特になし |
| Zendesk（CS系） | 構造化＋テキスト | API | リアルタイム | テキスト解析が必要 |
| WMS（物流系） | 構造化 | ファイル連携 | 日次バッチ | リアルタイム取得不可 |
| GA4（マーケ系） | 構造化 | API | 準リアルタイム | API制限あり |
| 経理ソフト（管理系） | 構造化 | 手動エクスポート | 月次 | API連携不可 |
データギャップ分析
ギャップの特定と対策
| AI活用候補 | 必要データ | 現状 | ギャップ | 対策 |
|---|---|---|---|---|
| FAQ自動回答 | FAQ記事、問い合わせログ | あり（品質要改善） | カテゴリ分類の不統一 | カテゴリマスタ整備、過去データの再分類 |
| 需要予測 | 注文履歴、季節要因、イベントデータ | 注文履歴あり、外部データなし | 外部要因データの不足 | 天気API、カレンダーデータの連携 |
| 出荷検品 | 検品画像 | なし | 学習用画像データがない | カメラ設置、3ヶ月間の画像収集 |
| 在庫最適化 | リアルタイム在庫データ | 日次バッチのみ | リアルタイム性の不足 | WMSとのAPI連携構築 |
データ整備のロードマップ
| フェーズ | 期間 | アクション | 対象データ |
|---|---|---|---|
| Phase 1 | 0-1ヶ月 | データ棚卸しと品質評価 | 全データソース |
| Phase 2 | 1-3ヶ月 | データクレンジングと標準化 | 商品マスタ、問い合わせログ |
| Phase 3 | 2-4ヶ月 | データ連携基盤の整備 | WMS-BigQuery連携 |
| Phase 4 | 3-6ヶ月 | 新規データ収集の開始 | 検品画像、外部データ |
まとめ
| 項目 | ポイント |
|---|---|
| 3軸評価 | データの量・質・アクセス性を総合的に評価 |
| 量の目安 | AI手法によって必要量は大きく異なる |
| 品質の6次元 | 正確性・完全性・一貫性・鮮度・一意性・適合性 |
| ギャップ分析 | 不足データの特定と取得方法の計画策定 |
| 整備ロードマップ | 棚卸し→クレンジング→連携基盤→新規収集の段階 |
チェックリスト
- データ可用性の3軸評価を説明できる
- AI手法別の必要データ量の目安を理解した
- データ品質の6次元を把握した
- データギャップ分析の手順を理解した
次のステップへ
次は「技術フィット評価」として、生成AI、ML、RPA、ルールベースの使い分けを詳しく学ぼう。
推定読了時間: 30分