データ分析プロジェクトの現場で、最も多くの時間を費やしている作業は何でしょうか。
高度な予測モデルの構築でしょうか。それとも、ダッシュボードのデザインでしょうか。
答えは「データクレンジング（前処理）」です。
「全角と半角が混在しているID」「『株式会社』がついたりつかなかったりする社名」「謎の空白文字が含まれるCSV」といったデータの汚れと格闘することに、多くのリソースを割いているケースは決して珍しくありません。
データ分析の現場では、次のような疑問の声がよく聞かれます。
「ChatGPTにSQLを書かせても、微妙に間違っていて修正に時間がかかる。結局自分で書いた方が早いのではないか？」
この疑問はもっともです。確かに以前の環境では、生成されたコードの微修正に手間取ることが多くありました。しかし、最新のアップデートにより状況は大きく変化しています。OpenAIの公式情報によれば、GPT-4oなどのレガシーモデルが廃止され、GPT-5.2（InstantおよびThinking）が新たな標準モデルへと移行しました。このモデル更新によって、長い文脈の理解力やツール実行の正確性、構造化されたコード生成の能力が飛躍的に向上しています。
結論として、「AIにコードを書かせる」という選択肢は、現在では極めて有効な手段であると考えます。ただし、それを最大限に活かすためには、これまでの「ゼロから自分でコードを書く」というマインドセットを捨て、「AIが書いたコードの意図を理解し、正確性を検品する」という役割へシフトチェンジする必要があります。
本記事では、データアナリストの視点から、最新のAIモデルを用いたデータクレンジングの実践的なアプローチについて、具体的なステップを論理的に解説します。
なぜ「データの前処理」はいつまでも終わらないのか
データ分析の世界には、「80:20の法則」があります。分析プロジェクトの80%の時間はデータ準備に費やされ、実際にインサイトを導き出す分析作業は残りの20%に過ぎない、というものです。
分析時間の80%を奪う「作業」の正体
例えば、POSデータとECサイトの会員データを統合するだけでも時間を要することがあります。理由は単純で、入力フォームの自由度が高すぎて、住所や氏名の表記があまりにもバラバラだからです。
データアナリストの仕事は、本来「データから価値ある知見を見つけ出すこと」です。しかし現実は、ExcelやPythonのエラーログと睨めっこし、REPLACE 関数や正規表現（RegEx）のパズルを解くことに忙殺されることがあります。
これは単なる時間の浪費ではありません。モチベーションの低下を招き、優秀なアナリストが離職してしまうリスクすらあります。
ルールベース処理の限界と属人化のリスク
従来、こうしたクレンジング作業は「ルールベース」で行われてきました。
- 「東京都」が含まれていれば抽出する
- 電話番号のハイフンを取り除く
- NULLの場合は「不明」という文字列を入れる
これらをSQLの CASE 文やPythonの if 文で記述していくわけですが、ビジネス環境は常に変化します。新商品が出れば新しいカテゴリコードが増え、海外展開すれば住所フォーマットが変わります。
そのたびに誰かが手動でルールを追加・修正しなければなりません。結果として、誰も全容を把握できない「継ぎ接ぎだらけのスパゲッティコード」が出来上がります。担当者が退職したら、そのクレンジングスクリプトは誰も触れない「ブラックボックス」と化す可能性があります。
ここでAIの出番です。AIは、こうした「ルールのメンテナンス」という呪縛から私たちを解放してくれる可能性を秘めています。
実証実験：AIエージェントに「汚いデータ」を投げたらどうなるか
では、実際にAI（ここでは大規模言語モデルを活用したコード生成エージェント）は、どれほどの実力を持っているのでしょうか。具体的なデータを使って検証してみましょう。
表記ゆれ・欠損・異常値を含むデータでのテスト
以下のような、実務でよく見かける顧客データフレーム（pandas DataFrame）を想定します。
| user_id | name | age | signup_date | |
|---|---|---|---|---|
| 1001 | 山田 太郎 | yamada@example.com | 28 | 2023/04/01 |
| 1002 | 鈴木 一郎 | suzuki_ichrio@example | ２９ | 2023-04-02 |
| 1003 | Tanaka, Hanako | tanaka.h@test.co.jp | -1 | 2023/04/05 10:00 |
| 1004 | 佐藤 | sato@example.com | NaN | None |
課題:
nameの全角・半角スペースを統一し、英語表記は日本語へ（可能なら）。emailのフォーマット不正を検知。ageの全角数字を半角に、負の値や欠損値を適切に処理。signup_dateの日付フォーマットを統一。
この要件をAIエージェントに投げ、Pythonコード（pandas）を生成させてみました。
SQL vs Python：AIが得意な処理パターンの比較
AIが生成したPythonコード（抜粋）：
import pandas as pd
import numpy as np
import re
# データ読み込み（略）
# 1. 名前のスペース統一
df['name'] = df['name'].str.replace(' ', ' ').str.strip()
# 2. Email検証（簡易版）
email_pattern = r'^[\w\.-]+@[\w\.-]+\.\w+'
df['is_valid_email'] = df['email'].apply(lambda x: bool(re.match(email_pattern, str(x))))
# 3. 年齢の正規化
def clean_age(x):
if pd.isna(x): return np.nan
# 全角を半角に変換
x = str(x).translate(str.maketrans('０１２３４５６７８９', '0123456789'))
try:
val = int(x)
return val if val > 0 else np.nan # 負の値は欠損扱い
except:
return np.nan
df['age_clean'] = df['age'].apply(clean_age)
# 4. 日付統一
df['signup_date'] = pd.to_datetime(df['signup_date'], errors='coerce')
評価:
AIが生成したコードは、概ね要件を満たしています。
特に translate メソッドを使った全角数字の変換や、pd.to_datetime の errors='coerce'（変換できないものはNaTにする）という定石を押さえている点は評価できます。
SQLの場合も同様に検証しましたが、AIは一般的なANSI SQLだけでなく、BigQueryやSnowflake特有の関数（例：SAFE_CAST や TRY_TO_DATE）を使い分ける指示にも対応しました。
生成までの所要時間と初稿の完成度
人間がこのコードをゼロから書く場合、正規表現の確認やテストを含めて時間を要するでしょう。しかし、AIはプロンプト入力から生成まで短時間で完了します。
もちろん、修正は必要です。しかし、「白紙の状態から書き始める」のと、「ある程度完成したコードを修正する」のとでは、精神的な負荷が全く違います。この点が、AIを導入し業務効率化を図る大きなメリットです。
AI任せは危険？生成コードに見られる典型的な3つのミス
しかし、ここで手放しに喜んではいけません。「AIが書いたから大丈夫だろう」とそのまま本番環境にデプロイするのは危険です。
実務の現場でよく見られる、AI生成コードの「落とし穴」を3つ紹介します。
1. ビジネスロジックを無視した欠損値埋め
最も多いミスが、データの意味（コンテキスト）を理解していない処理です。
例えば、AIに「売上データの欠損値を補完して」と依頼したところ、単純に「平均値（Mean）」で埋めるコードを生成することがあります。技術的には正しいコードです。
しかし、そのデータは「特定期間のキャンペーン商品」の売上でした。欠損しているのは「売れなかった日（売上0）」ではなく、「在庫切れで販売できなかった日」だったのです。これを平均値で埋めてしまうと、在庫さえあれば売れたという過大な予測につながり、需要予測AIや発注計画の精度を大きく狂わせることになります。
AIは「Pythonの文法」は知っていても、「ビジネスルール」は知りません。
2. パフォーマンスを考慮しない非効率なクエリ
SQL生成においてよくあるのが、動くけれど重すぎるクエリです。
数億行あるトランザクションデータに対して、AIは SELECT DISTINCT や複雑な JOIN を提案してくることがあります。さらに、パーティションキー（日付など）による絞り込みを忘れることも多々あります。
AIが生成したクエリをそのままクラウドDWH（データウェアハウス）で実行し、高額な課金が発生しそうになるケースも報告されています。実行前のドライランによる確認が不可欠です。
3. 微妙なニュアンスの取り違えによる集計ズレ
言葉の定義の曖昧さもリスクです。
例えば「先月の売上を出して」と指示した際、AIによって解釈が分かれます。
- 注文日ベース（Order Date）なのか、出荷日ベース（Ship Date）なのか？
- キャンセル分は除外するのか、含めるのか？
- 消費税は抜きか、込みか？
人間同士なら「これって税抜ですよね？」と確認し合えますが、AIは（指示がない限り）勝手に仮定してコードを書いてしまいます。結果、経理部門の数字と合わないというトラブルが発生します。
人間が担うべき「検品」プロセスとROIの最大化
AIのリスクを理解した上で、それでもAIを使うべきです。なぜなら、リスクは管理可能であり、得られるリターン（時間短縮）が大きいからです。
重要なのは、役割を「作成者（Writer）」から「検品者（Reviewer）」へと再定義することです。
構文チェックではなく「意味チェック」に集中する
これからのデータアナリストに必要なスキルは、美しいコードを書く能力よりも、「このコードはビジネス的に正しい挙動をしているか？」を見抜く能力です。
AIが生成したコードに対して、以下の視点でレビューを行います。
- ロジックの妥当性: 欠損値処理や異常値の除外基準は、業務ルールと合致しているか？
- エッジケースの対応: データが0件の場合や、想定外の文字が入った場合にエラーで止まらないか？
- パフォーマンス: 大量データに対して効率的な処理になっているか？
構文エラー（Syntax Error）は実行すればすぐに分かりますが、論理エラー（Logic Error）は人間が頭を使って見つけなければなりません。ここにこそ、専門家の価値があります。
AIコード検証のためのチェックリスト
AI生成コードの受入検査項目の一部を共有します。
- 集計粒度の確認:
GROUP BYのキーはユニークになっているか？（意図しない重複が発生していないか） - JOINの整合性:
INNER JOINで必要なデータが脱落していないか？LEFT JOINで意図しないNULLが発生していないか？ - フィルタ条件:
WHERE句でNULLの扱いが考慮されているか？（SQLのNULLは=では判定できない） - データ型の確認: 文字列として比較すべきIDが数値になっていないか？（先頭の
0落ちなど）
削減できた時間で何をするか：分析の本質へ
AIを活用してデータ前処理の時間を削減できたとしましょう。浮いた時間で何をするかが、ROI（投資対効果）を最大化する鍵です。
ビジネスへの貢献を考えるなら、以下のような活動に時間を割くべきです。
- データの背景を探る: 現場担当者にヒアリングを行い、データの発生源における事情を理解する。
- 仮説を深める: 表面的な数字の変動だけでなく、「なぜそうなったのか」という因果関係の統計解析に時間をかける。
- 対話する: 分析結果をステークホルダーに分かりやすく伝え、アクションにつなげるための資料作成やミーティングを行う。
AIは「作業」を代行してくれますが、「思考」や「対話」は代行してくれません。
まとめ：AIを「アシスタント」として活用する
データクレンジングにおけるAI活用は、「使うか使わないか」の議論ではなく、「どう品質を管理するか」というフェーズに入っています。
AIエージェントは、手が早く、大量のコードを生成してくれるアシスタントです。しかし、ビジネスの文脈を知らず、誤った情報を生成することもあります。
専門家の役割は、成果物を「検品」し、正しい方向へ導くことです。そうすることで初めて、データ分析の生産性は向上します。
AIという強力な武器を使いこなし、データ分析の泥沼から抜け出して、本来あるべき「価値創造」の時間を取り戻しましょう。
コメント