WebRTCをテーマにした連載の最終回として、運用フェーズで重要となるパフォーマンス品質の測定と監視手法を解説します。WebRTCが提供する getStats() APIを用いた統計的分析と、Chromeのデバッグ機能 webrtc-internals によるリアルタイム監視の2つの方法を紹介。特に画面共有アプリケーションで重要となるフレームレート、解像度、CPU負荷などの観点や、確認すべき具体的なStats項目、 clumsy を用いたネットワーク劣化テストの実践的な確認方法にも触れます。

こんにちは、タイミーのバックエンド/Webフロント基盤チーム マネージャーの新谷（ @euglena1215 ）です。 先日開催された RubyKaigi 2026 に参加してきました。その中で特に気になったのが、Shopify の Alexandre Terrasa さんによる「 Blazing-fast Code Indexing for Smarter Ruby Tools 」という発表です。 この発表では rubydex という Rust 製の Ruby Code Indexer が紹介されていました。RubyLSP や Tapioca に統合することで最大10倍の高速化と2倍のメモリ削減を実現したという内容でした。また、Ruby ツールのための統一的なコードインデックス基盤としてのビジョンも示されていました。Shopify の Ruby DX チームが9名関わっているということで、Shopify への rubydex への本気度が伺えます。 発表の中では、Experimental ながら MCP サーバー（rubydex-mcp） も提供されていることが紹介されていました。Claude Code などの AI アシスタントからセマンティックにコードベースを検索できるようになっています。 AI Coding Agent にコードベースを調査させると、 Grep → Read → また Grep …というループが延々と続き、トークンがみるみる消費されていきます。rubydex-mcp を使えば、クラス定義やリファレンス、継承ツリーといった構造的な情報を、1回の MCP ツール呼び出しで取得できます。そのため、このループを大幅に削減できそうです。 実際にどの程度効果があるのか、タイミーのバックエンドリポジトリで定量的に検証してみました。 rubydex とは rubydex は Shopify が開発した Ruby Code Indexer です。 github.com Rust 製の Indexer がコードベースを解析し、MCP（Model Context Protocol）サーバーとして以下のツールを提供します。 ツール 機能 search_declarations 名前によるファジー検索（クラス、モジュール、メソッド、定数） get_declaration 完全修飾名による定義情報の取得（ドキュメント、祖先チェーン、メンバー） find_constant_references 定数の参照箇所をコードベース全体から検索 get_descendants クラス/モジュールの継承ツリーを取得 get_file_declarations ファイル内の構造一覧 codebase_stats コードベース全体の統計情報 通常、AI Coding Agent がコードベースを調査する際は grep や find でファイルを探し、 Read で中身を読み、また grep で次のファイルを探し…というループを繰り返します。rubydex を使うと、このループの多くが1回の MCP ツール呼び出しで完結できる可能性があります。 検証方法 概要 claude -p （Claude Code の非インタラクティブモード）を使い、rubydex あり/なし の2条件で同じプロンプトを実行し、トークン消費量と回答品質を比較しました。 検証環境 ツール：Claude Code CLI ( claude -p ) モデル：claude-sonnet-4-6 rubydex_mcp バージョン：0.1.0 対象リポジトリ：タイミーのバックエンド（モジュラーモノリス、70パッケージ） 条件の制御 外部要因を排除するため、以下の共通オプションを使用しました。 claude -p "<prompt>" \\ --output-format json \\ # トークン使用量を含む JSON 出力 --model sonnet \\ # モデル固定 --bare \\ # hooks, CLAUDE.md 等を無効化 --strict-mcp-config \\ # .mcp.json を無視し引数の MCP 設定のみ使用 --mcp-config <config> \\ # 条件別の MCP 設定 --tools "Read,Bash,Edit" \\ --no-session-persistence --bare で CLAUDE.md の自動読み込み等の副作用を排除し、 --strict-mcp-config により MCP サーバーの有効/無効を制御しています。これにより、2条件間の差は rubydex の有無のみになります。 プロンプト rubydex のツール群が効果を発揮しそうな質問を5種類用意しました。 ID プロンプト class_hierarchy XXXモデルのクラス継承チェーンと、includeしているモジュールの一覧を教えてください。それぞれのモジュールがどのファイルで定義されているかも含めてください。 find_references YYYモデルがコードベース全体でどこから参照されているか調査してください。参照元をコントローラ、モデル、サービス等のカテゴリ別に分類して一覧にしてください。 descendants ApplicationRecordを継承しているクラスの一覧を取得し、packs/ディレクトリ配下のパッケージごとに何個のモデルが存在するか集計してください。上位10パッケージを表示してください。 method_investigation XXXモデルに定義されているpublicインスタンスメソッドのうち、名前に'status'を含むものをすべてリストアップしてください。各メソッドの定義場所（ファイルパスと行番号）と、そのメソッドが何をしているかの簡単な説明を付けてください。 codebase_overview このRailsプロジェクトのpacks/ディレクトリ配下のパッケージ構成を調査してください。各パッケージに含まれるモデル数、主要なクラス名を一覧にし、パッケージ間の依存関係で特に密結合なものがあれば指摘してください。 各条件 × 各プロンプトで5回ずつ、合計50回実行しました。LLM の出力は非決定的なので、複数回実行して平均を取ることでばらつきの影響を軽減しています。 結果 トークン消費量 プロンプト rubydex なし（平均トークン） rubydex あり（平均トークン） 変化率 class_hierarchy 144,076 85,958 -40.3% codebase_overview 1,187,722 664,761 -44.0% descendants 46,501 165,795 +256.5% find_references 770,404 332,369 -56.9% method_investigation 986,840 636,411 -35.5% 5つ中4つのプロンプトで 35〜57% のトークン削減 を達成しました 🎉 コスト・速度 プロンプト コスト変化 実行時間変化 ターン数変化 class_hierarchy -16.7% -48.6% -35.4% codebase_overview -34.3% -19.6% -13.7% descendants +294.6% +261.0% +62.7% find_references -33.5% -19.0% -11.9% method_investigation -30.7% -50.1% -38.1% ターン数（エージェントのツール呼び出し回数）の削減がトークン削減の主因です。rubydex のセマンティック検索が Grep → Read の繰り返しを置き換えることで、エージェントループが短縮されています。 回答品質（LLM-as-a-Judge） トークンが減っても回答品質が下がっては意味がありません。別の Claude セッションを立ち上げ両条件の回答を渡し、正確性・網羅性・有用性の3観点で5点満点のスコアリングを行いました。 プロンプト rubydex なし（平均） rubydex あり（平均） 差分 class_hierarchy 4.33 4.00 -0.33 codebase_overview 4.33 4.00 -0.33 descendants 3.00 4.67 +1.67 find_references 4.00 4.00 0.00 method_investigation 3.33 4.33 +1.00 平均 3.80 4.20 +0.40 回答品質はむしろ改善しています 👏 Judge のコメントから見えた傾向を簡単にまとめます。 rubydex ありで改善した点（正確性） rubydex なしの場合、grep の結果をもとに関連しそうなクラスやメソッドを補足情報として列挙する傾向があった。目視では誤情報は確認できなかったが、裏取りが不十分な状態で情報を出しているため信頼性の判断がしにくい（ method_investigation など） rubydex ありではインデックスに基づいた情報を返すため、出力の根拠が明確になっている rubydex なしが勝った点（網羅性・有用性） grep ベースの調査は探索範囲が広いため、rubydex が返さないカテゴリ（Policy、Mailer 等）の参照元も拾えていた（ find_references ） rubydex なしの回答はファイルのフルパスや構造図を含むなど、開発者がすぐに使える形に整理されている傾向があった（ class_hierarchy , codebase_overview ） 総じて、 rubydex ありは正確性で優位、rubydex なしは網羅性で優位 という傾向が見られました。また、いくつかのプロンプトの回答を目視でも確認しましたが、rubydex ありで明らかにおかしな内容を回答しているケースは見られませんでした。 descendants が悪化したケース 唯一、 descendants プロンプトではトークンが +256.5% と大幅に悪化しました。 このプロンプトは「ApplicationRecord の子孫クラスをパッケージ別に集計する」という内容です。rubydex の get_descendants ツールは全子孫を忠実に返します。（我々の環境では346クラス）一方、rubydex なしの場合は grep -r "< ApplicationRecord" のような検索で主要なものだけを拾うため、結果的にトークンが少なく済んでいました。 つまり、 大量の結果を返すような網羅的な検索では、rubydex がかえってトークンを増やす ケースがあります。ただし、品質面では rubydex ありの方が +1.67pt と最も大きく改善しており、正確性とのトレードオフと言えます。 まとめ 5つ中4つのプロンプトで 35〜57% のトークン削減 と 17〜34% のコスト削減 を達成しつつ、回答品質は LLM-as-a-Judge の評価で同等以上（5点満点で 3.80 → 4.20）でした。特に「クラスの参照元を探す」「メソッドの定義場所を調べる」といった構造的な検索タスクで効果が顕著です。 一方、全件取得のような網羅的検索ではトークンが増えるケースもあり、万能ではありません。rubydex が提供するツールの特性を理解した上で導入すると、より効果的に活用できそうです。 また、現状 rubydex-mcp を利用するには Rust ツールチェーン（cargo）が必要で、ソースからのビルドが求められます。開発環境の依存が増えることになるため、チーム全員が使える形に整備するかどうかはもう少し見極めたいところです。とはいえ、トークン35〜57%削減という効果は十分に大きく、rubydex-mcp への期待はとても高まる結果となりました。 検証の制約 今回の検証にはいくつかの制約があります。結果を解釈する際の参考にしてください。 --bare モードでの検証 : CLAUDE.md 等が無効化されているため、通常利用時とはベースのトークン消費量が異なります キャッシュの影響 : 実行順序や間隔によってキャッシュヒット率が変わるため、コスト比較は参考値です 回答品質の評価 : LLM-as-a-Judge による自動評価のみで、正解データとの突合は行っていません プロンプトの偏り : rubydex が得意そうなタスクを選んでいるため、実際の利用での改善幅はこれより小さくなる可能性があります

― 基礎から理解し、AIで劇的に効率化する ― データ分析を始めようとしたとき、多くの担当者が最初につまずくのは「分析手法の選び方」ではありません。その前段階にある、データを「使える状態」に整える工程――データクレンジング――です。 本記事では、非エンジニアの方や意思決定者の方でも全体像をつかめるよう、データクレンジングの基礎から実務上の課題、そしてAIによる新しいアプローチまでを体系的に解説します。 第1章　データクレンジングの全体像と重要性 1-1. データ分析は「準備」で8割決まる データサイエンスの現場では、長年にわたって同じ事実が繰り返し確認されています。 「データクレンジング・前処理が、プロジェクト全体の工数の70〜80%を占める」 （出典：IBMデータサイエンティスト調査、Kaggleデータサイエンティスト実態調査 等） これは「整理整頓に時間がかかって困っている」という話ではありません。逆説的に言えば、データの準備さえ正しくできれば、分析の精度と信頼性は大きく高まる、ということです。 「Garbage In, Garbage Out（ゴミを入れればゴミしか出ない）」という言葉があります。どれだけ最新のAIモデルを使っても、入力データが汚ければ出力される結果も信用できません。データクレンジングは、分析の根幹を支える最重要工程なのです。 1-2. なぜ「そのままのデータ」は使えないのか？ 企業の業務システムに蓄積されたデータは、現場の担当者が入力したものが多く、さまざまなばらつきや誤りが含まれています。以下は典型的な例です。 問題のあるデータ（変換前） クレンジング後（変換後） 売上：「１，２３４，５６７円」 売上：1234567（数値型） 日付：「R5.4.1」／「Apr 1 2023」 日付：2023-04-01（統一形式） 顧客名：「㈱山田商事」 顧客名：株式会社山田商事 年齢：312（入力ミス） 年齢：null（異常値として除外） 売上高：（空白） 売上高：前後値の平均で補完 こうした問題は1件1件は些細に見えますが、数万〜数百万レコードのデータになると、放置すれば分析結果を根本から歪める原因になります。 1-3. データクレンジングの全体像 データクレンジングとは、分析・モデリングに使えるよう「データの品質を高める」一連の作業の総称です。一言で「クレンジング」と言っても、その中身は目的・手法の異なる4つの領域に分類されます。 ◆ 領域① 構造・型の整備 データの「形」を正しく揃える作業です。分析ツールやモデルがデータを読み込む前提として必要であり、技術的・機械的に対処できるものが多い領域です。 データ型の修正：数値カラムに文字列が混入している、日付が文字列として格納されているなど。 スキーマ統一：複数システムからのデータでカラム定義が食い違っている場合の統一。 ◆ 領域② 統計的データクレンジング　※本記事が詳しく解説する範囲 統計的な手法を用いてデータの「値」の品質を高める作業です。データクレンジングの中核をなす領域であり、実務で最も工数がかかる部分でもあります。 欠損値処理：空白・NULLの検出と、補完または除去。 外れ値処理：統計的に異常な値（ZスコアやIQRで検出）の対処。 重複データの削除：同一内容のレコードを検出して統合・除去。 表記ゆれの統一：全角／半角、略称／正式名称、スペースの有無など。 フォーマット統一：日付・数値・単位などの形式を標準化。 ◆ 領域③ 整合性・ビジネスルールチェック データが「業務的に正しいか」を検証する作業です。統計的な手法だけでは検出できず、ドメイン知識（業務知識）が不可欠な領域です。 ビジネスルール違反の検出：年齢＝200、負の売上、未来の注文日付など、ありえない値の除去。 一貫性チェック：売上合計と明細合計が一致しない、開始日＞終了日になっているなど。 参照整合性チェック：注文テーブルに存在しない顧客IDが含まれる、マスタとの不一致など。 ◆ 領域④ ノイズ・異常データの除去 システム的な欠陥や入力ミスによって混入した「意味をなさないデータ」を取り除く作業です。正解の定義が曖昧で判断が難しく、非構造データ（テキスト）で特に問題になります。 ゴミ文字・記号の混入：文字化け、制御文字、HTMLタグの混入など。 フリーテキストの異常：本来は住所を入力するフィールドに「なし」「未定」などが入っているケース。 本記事では、4領域の中でも最も実務上の比重が大きい「領域②：統計的データクレンジング」にフォーカスして詳しく解説します。 1-4. データクレンジングをなぜ理解すべきか 非エンジニアや経営層の方にとっては「技術者に任せればいい」と思われるかもしれません。しかしデータクレンジングには、ビジネス上の判断が不可欠な局面が多くあります。 欠損値を削除するか補完するかは、分析の目的によって変わる。 外れ値が「入力ミス」か「重要な異常信号」かは業務知識がないと判断できない。 重複データの統合ルールは、自社のビジネスロジックに基づく必要がある。 つまりデータクレンジングは、技術者とビジネス担当者が連携して進める工程なのです。全体像を理解することが、意思決定の質を高めることに直結します。 第2章　統計的データクレンジングの作業内容（詳細） 第1章で整理した「統計的クレンジング」の各作業について、「どんなデータに対して、どういう処理を行うのか」を具体的に見ていきます。 2-1. 欠損値処理（Missing Value Handling） 欠損値とは、本来あるべきデータが存在しない状態（空白・NULL・NaN）のことです。分析モデルの多くは欠損値をそのまま扱えないため、必ず何らかの対処が必要になります。 ◆ 具体例：顧客購買データの欠損 加工前のデータ 処理後のデータ 顧客ID：C001／購買金額：（空白）／年齢：35 購買金額：過去3か月の平均値（45,000円）で補完 顧客ID：C002／購買金額：28,000／年齢：NULL 年齢：同セグメントの中央値（42歳）で補完 顧客ID：C003／全項目：NULL 行ごと削除（リストワイズ削除） ◆ 主な対処法と使い分け ① 削除（リストワイズ削除）： 欠損が全体の5%未満、かつランダムに発生している場合に有効。欠損が多い場合は情報ロスが大きい。 ② 平均値・中央値補完： 数値データに有効。外れ値の影響を受けやすい平均値より、偏りがある場合は中央値を推奨。 ③ 前後値補完（補間）： 時系列データに有効。センサーログや株価など、時間軸に連続性がある場合に使用。 ④ モデルベース補完： 他のカラムの値をもとに、AIや回帰モデルで欠損値を予測・補完。精度は最も高いが実装コストも高い。 補完方法の選択ひとつで分析結果が変わります。「とりあえず平均値」は危険な場合があるため、データの性質と分析目的に応じて慎重に選択することが重要です。 2-2. 重複データの削除（Deduplication） 同じ情報が複数のレコードとして存在している状態です。集計を行うと数値が2倍になるなど、分析結果を著しく歪めます。 ◆ 具体例：顧客マスタの重複 問題のあるデータ（変換前） 対処法 ID:001 ／ 山田商事 ／ 03-1234-5678 代表レコードとして保持 ID:002 ／ （株）山田商事 ／ 03-1234-5678 電話番号が同一のため ID:001 に統合して削除 ID:003 ／ 山田　商事 ／ 03-1234-5678 スペースを含む表記ゆれ → 同様に統合して削除 重複の検出は「完全一致」だけでなく、「会社名の表記ゆれ＋電話番号が一致」など複数条件の組み合わせで判定するケースが多く、ビジネスロジックの理解が不可欠です。 2-3. 表記ゆれの統一（Normalization） 表記ゆれとは、同じ意味を持つデータが異なる文字列で表現されている状態です。検索・集計の正確性に直結します。 ◆ 代表的な表記ゆれのパターン 全角／半角：「Ａ社」 vs 「A社」 大文字／小文字：「TOKYO」 vs 「Tokyo」 vs 「tokyo」 略称／正式名称：「㈱」「(株)」「株式会社」 空白の有無：「山田 太郎」 vs 「山田太郎」 単位表記の違い：「100万円」 vs 「1,000,000円」 vs 「1M円」 完全に自動化することが難しい領域のひとつであり、業界固有の辞書（名寄せ辞書）の整備が必要になることも多いです。 2-4. フォーマット統一（Data Standardization） 異なるシステムから集まったデータは、同じ「日付」「金額」でも形式がバラバラなことがあります。フォーマットが統一されていないと、並べ替えや集計で誤った結果が出ます。 ◆ 具体例：日付フォーマットの混在 元の表記（バラバラ） 統一後（YYYY-MM-DD形式） R5.4.1 2023-04-01 2023/4/1 2023-04-01 Apr 1, 2023 2023-04-01 20230401 2023-04-01 令和5年4月1日 2023-04-01 このような変換処理は、フォーマットのパターン数が多いほど対応が複雑になります。特に和暦を含む場合は、変換テーブルの整備が必要です。 2-5. 外れ値処理（Outlier Detection） 外れ値とは、統計的に他の値と大きくかけ離れた値のことです。入力ミスの場合もあれば、不正取引の兆候などビジネス上重要な異常信号の場合もあります。 ◆ 具体例：売上データの外れ値 データの内容 判断と対処 月次売上：120万、130万、125万、12,500万（!）、118万 12,500万→Zスコア検定で外れ値と判定。入力ミスの可能性が高いためNullに変換。 気温センサー：22℃、23℃、21℃、−999℃、24℃ −999→センサーエラー値。除外して前後値で補間。 EC注文：通常100〜5,000円の中、580,000円の注文 高額注文→業務的に有効な可能性あり。除外せず別フラグを付与して保持。 ◆ 主な外れ値検出手法 Zスコア法： 平均からの標準偏差距離を計算し、|Z|>3の場合に外れ値と判定。正規分布に近いデータに有効。 IQR法（四分位範囲）： 第1四分位数（Q1）〜第3四分位数（Q3）の範囲外を外れ値と判定。歪んだ分布にも対応可能。 モデルベース検出： Isolation ForestやLOFなど、機械学習による多変量での外れ値検出。 重要：外れ値は「必ず除去すべき」ではありません。不正検知・設備異常検知の文脈では、外れ値こそが最も重要な情報である場合があります。除去前に必ず業務的な意味を確認することが必要です。 第3章　なぜデータクレンジングはこれほど大変なのか 「大切な工程だとはわかった。でも実際どれくらい大変なのか？」という疑問に答えます。ここでは、実際の現場で起きている課題を具体的な工数とともに解説します。 3-1. データサイエンティストの工数実態 まず現実の数字を見てみましょう。一般的な分析プロジェクト（1〜3か月規模）における工数配分の目安です。 作業フェーズ 目安工数（1案件） 主な理由 データ収集・調査 1〜2週間 どのデータがどこにあるかの把握、アクセス権の取得 データクレンジング・前処理 3〜6週間 欠損・外れ値・表記ゆれ処理、フォーマット統一、ルール設計 探索的データ分析（EDA） 1〜2週間 傾向把握、仮説立案 モデル開発・チューニング 1〜2週間 分析手法の選択と学習 評価・レポーティング 1週間 精度検証、ステークホルダーへの説明 合計 7〜13週間 うちクレンジングが全体の約50〜60%を占める 1案件あたりのデータクレンジング工数：3〜6週間（データサイエンティスト1名換算）。 これが年間複数案件発生すると、組織全体では莫大な人的リソースが「前処理」に費やされていることになります。 3-2. 技術的な参入障壁（エンジニア頼み問題） データクレンジングを実施するには、以下のような専門スキルが必要です。 SQL：データベースから必要なデータを抽出・加工する言語。 Python：Pandas・NumPyなどのライブラリを用いた処理。 データ基盤の知識：どのシステムにどのデータがあるかの把握。 つまり、ビジネス部門の担当者が「このデータを分析したい」と思っても、自力では着手できないという状況が生まれます。IT部門やデータエンジニアへの依頼が必要になり、そこでリードタイムが発生します。 【よくある現場の声】 「分析をお願いしたら、まずデータを整理するのに3週間かかると言われた。その間、施策が止まってしまった。」 3-3. ルール設計の難しさ（正解がない問題） データクレンジングには「唯一の正解」がありません。状況によって最適な処理が変わるため、その判断に多くの時間が費やされます。 例① 欠損値の扱い方： 「先月の売上が空欄」→ 前月の値で補完すべきか。ゼロとみなすべきか。それとも除外すべきか。 業界・業種・分析目的によって判断が異なる。 例② 外れ値の扱い方： 「通常の10倍の注文が入った」→ 入力ミスか。本物の大口顧客か。キャンペーン効果か。 業務知識がないと判断できない。 こうした判断を1案件で数十〜数百箇所行う必要があり、それぞれについて担当者との確認・合意が必要になります。 3-4. 試行錯誤コストの高さ データクレンジングの結果は、モデルを動かしてみるまで「良かったかどうか」がわかりません。 Step 1：欠損値を平均値補完でクレンジング。 Step 2：モデルを学習・評価。 Step 3：精度が出ない → 補完方法を変えて最初からやり直し。 このフィードバックループが1回転するのに数日〜1週間かかることもあり、手動では最適な処理を探索しきれないという構造的な問題があります。 3-5. 属人化とブラックボックス化 特定のエンジニアしか把握していない処理がドキュメント化されないまま蓄積されていくと、担当者の異動・退職で過去の分析が再現できなくなります。これは特に「前処理スクリプト」で起きやすい問題です。 3-6. 運用の継続コスト データクレンジングは「一度やれば終わり」ではありません。業務システムが更新されるたび、データの追加・変更のたびに処理を見直す必要があります。 月次でデータが更新されるたびに手動で処理を流す。 フォーマットが変わるたびにスクリプトを修正する。 ミスが混入しても気づきにくい。 結論：データクレンジングは「一時的な技術作業」ではなく、組織の継続的な競争力を左右する「インフラ」です。にもかかわらず、多くの組織でいまだに人手と属人的スキルに依存しています。 第4章　dotDataのAIアプローチ ― 特徴量探索と前処理の自動化― 第3章で見てきた課題を解決するのが、dotDataのAIを活用したアプローチです。dotDataは「特徴量探索（Feature Engineering）」を核心技術としながら、その前段階にあるデータクレンジング・前処理もAIが自動で実行します。 4-1. dotDataの根幹技術：特徴量探索とは AIモデルの精度を決める最大の要因は「どんな変数（特徴量）を使うか」です。従来は経験豊富なデータサイエンティストが何日も費やして手作業で設計していましたが、dotDataはAIがこの探索を自動で行います。 複数のテーブルをまたいで数千〜数万の特徴量候補を自動生成。 モデル精度への貢献度をAIが評価して最適な特徴量を選択。 データサイエンティストが数週間かけて行う作業を数時間に圧縮。 そしてこの特徴量探索の精度を高めるために、前段階のデータクレンジングもAIが実施します。「きれいなデータから良い特徴量が生まれる」という一貫したパイプラインが実現されています。 4-2. AIが自動実施するデータクレンジング処理 dotDataが自動で対応するクレンジング処理の具体例を紹介します。ルールをプログラムで書く必要はなく、AIが判断して最適な処理を適用します。 ◆ 数値型データのクレンジング 「数値カラムのはずなのに、テキストが混入している」というケースに対して、以下を自動実行します。 数値前後の余分な空白文字を自動除去（例：「　12345　」→「12345」）。 全角数字を半角に自動変換（例：「１２３」→「123」）。 カンマ区切りの数値を変換（例：「1,234,567」→「1234567」）。 指数表記の解釈（例：「1.2e5」→「120000」）。 数字と数字の間に異質な文字が混入している場合はnull値に変換（例：「12abc34」→ null）。 例：元データ「　１，２３４，５６７円　」→ 自動処理後「1234567」（数値型） これが数万行あっても、AIが一括で判断・変換します。 ◆ 日付・タイムスタンプ型のクレンジング 日付の表記バラバラ問題も自動処理します。 指定フォーマット（例：%Y-%m-%d）に当てはまらない不要文字を自動除去。 「2023/4/1」「令和5年4月1日」「Apr 1 2023」など多様な形式を統一フォーマットに変換。 連続する空白文字（スペース、タブなど）を単一スペースに統一。 ◆ AIによる新しいカラムの自動生成 dotDataの特徴量探索技術を活かして、既存のカラムから新しい分析軸を自動生成します。 複数の日時カラムから「注文から納品までの日数」などの新カラムを自動生成。 売上・数量・原価などから「粗利率」「客単価」などの比率・合計値カラムを自動生成。 テキストカラムから日時情報を抽出してタイムスタンプカラムを新規作成。 従来のアプローチ：「受注日」と「出荷日」を別々に保持していたが、リードタイム（日数差）の計算はエンジニアへの依頼が必要だった。 → dotData：AIが「この2カラムの差分が分析に有用」と自動判断し、新しい特徴量として生成。 4-3. モデル精度に直結する最適化 dotDataのクレンジングが他のツールと根本的に異なるのは、「きれいにする」ことが目的ではなく、「モデル精度を上げる前処理を探索する」ことが目的である点です。 欠損値補完：平均値・中央値・モデルベースなど複数パターンを試し、精度が最も高い方法を選択。 外れ値処理：除去・保持・フラグ付与などの選択肢をAIが評価。 スケーリング：正規化・標準化など、モデルに最適な変換方法を自動選択。 従来であれば手動での試行錯誤に数週間かかっていた処理選択を、AIが数時間で探索します。 4-4. 非エンジニアでも使える設計 dotDataはGUIベースで操作できるため、PythonやSQLの知識がなくても使用可能です。 データをアップロードするだけで自動解析が開始。 クレンジングの処理内容はログとして自動記録され、属人化を防止。 処理パイプラインが自動生成されるため、次回以降も再現可能。 【比較】 従来：データサイエンティストが3〜6週間かけて手動でクレンジングルールを設計・実装。 dotData：設定後、数時間〜1日でクレンジング＋特徴量探索まで完了。 → 工数を最大80%削減。担当者1名で複数案件を並行して進めることが可能に。 4-5. 組織全体へのインパクト 属人化の解消：処理ロジックが自動記録されるため、誰でも引き継ぎ可能。 再現性の確保：同じパイプラインを繰り返し実行でき、ミスが減少。 スケーラビリティ：データ量が増えても処理速度は変わらない。 ビジネス部門の自律化：IT部門への依頼待ちなしに、ビジネス部門が主体的に分析を推進できる。 第5章　まとめ ― これからのデータ活用に必要なこと ― この記事で解説してきた内容を整理します。 5-1. 本記事のポイント整理 データ分析の成否は、AIモデルではなく「データの準備」で7〜8割が決まる。 データクレンジングは欠損値・外れ値・重複・表記ゆれ・フォーマットなど多岐にわたる。 1案件あたりのクレンジング工数は3〜6週間が目安。組織全体では莫大なリソースが費やされている。 技術的参入障壁・ルール設計の難しさ・試行錯誤コストが組み合わさり、多くの組織でボトルネックになっている。 dotDataは特徴量探索を核心技術としながら、前処理もAIが自動実施。工数を最大80%削減し、非エンジニアでも活用可能。 5-2. 今後のトレンド データ量は今後も増加し続けます。手動での前処理は、スピードの面でも精度の面でも限界を迎えつつあります。 「分析する人を増やす」より「準備できる仕組みを作る」ことが、データ活用組織の次のステージです。 5-3. こんな課題をお持ちの方へ データ準備に時間を取られ、本来の分析に集中できていない。 分析をエンジニアに頼むと、着手まで数週間かかる。  属人化していて、担当者が変わると再現できない。 ビジネス部門が自律的にデータ活用できる体制を作りたい。 このような課題をお持ちであれば、AIを活用したデータクレンジング・特徴量探索の自動化は、最もROIの高い改善ポイントになるはずです。貴社のデータ状況やビジネスの課題に合わせた最適なステップをご提案いたします。まずは、ぜひお気軽に お問い合わせ ください。 The post 【初心者でもわかる】データ分析で最も重要な「データクレンジング」とは？AIで変わる最新アプローチ appeared first on dotData .