「AIが『システム障害』の報告をまた無視しました。これでお客様からのクレームは今週3件目です。正解率95%というのは本当でしょうか？」
AI導入プロジェクトにおいて、開発側のレポートではモデルの精度（Accuracy）が95%を超え、テストデータでの検証も問題なかったにもかかわらず、現場からこのような厳しいフィードバックを受けるケースは少なくありません。なぜ、高い精度を示しているはずのAIが、現場では実用的ではないと評価されてしまうのでしょうか。
AIプロジェクト、特に分類タスクにおいて、開発チームはしばしば「数字の罠」に陥ります。全体の正解率が高ければ、モデルは優秀だと判断しがちです。しかし、ビジネスの現場において、すべてのデータが等しく重要であることは稀です。
この記事では、SaaS企業などでよく見られるケースをもとに、多クラス分類における「マイクロ平均（Micro-Average）」と「マクロ平均（Macro-Average）」の決定的な違いについて解説します。教科書的な定義にとどまらず、評価指標の選択ミスがプロジェクトに与える影響と、そこからのリカバリーに向けた実践的なプロセスを体系的に整理します。
不均衡なデータを扱うプロジェクトにおいて、「数値は良いのに現場の評価が伴わない」という課題に直面している場合の解決の糸口となるはずです。
プロジェクト概要：高精度なはずのカスタマーサポートAIが直面した「信頼の危機」
急成長中のB2B SaaS企業が、月間5万件にも及ぶ問い合わせ対応の効率化を目指し、AIによる自動分類プロジェクトを立ち上げたケースを想定してみましょう。
月間5万件の問い合わせ自動分類プロジェクト
サポートチームのリソース不足は、多くの企業が抱える明確な課題です。問い合わせ内容は多岐にわたり、「パスワードリセット」のような定型的なものから、「API連携エラー」「課金トラブル」、そして最重要課題である「システム全体の障害報告」まで、多数のカテゴリが存在します。
プロジェクトの目的は、これらのお問い合わせメールをAIで解析し、適切な担当部署へ自動で振り分けることです。ベテランのオペレーターが目視で行っていた作業を自動化できれば、対応スピードは劇的に向上し、人的リソースをより高度な業務に集中させることが可能になります。
開発プロセスにおいて、BERTベースのモデルを採用し、過去のログデータを学習させたとします。PoC（概念実証）段階での評価指標として、一般的な「Accuracy（正解率）」と、クラスごとのF1スコアの平均値を採用するケースは一般的です。
テストデータに対するAccuracyが96.5%、F1スコア（Micro-Average）も96%台という結果が出れば、開発チームは高い精度が実現できたと判断し、本番リリースへと進むことになります。
リリース直後の現場からのクレーム
しかし、リリース直後に現場から「重要なアラートを見逃している」という深刻な報告が上がることがあります。
全体の問い合わせ件数から見ればごくわずかな「システム障害報告」や「セキュリティインシデント」といった緊急度の高いメールが、AIによって「一般的な質問」や「その他」といった優先度の低いカテゴリに誤分類されてしまう現象です。
一方で、大量に寄せられる「パスワードリセット」や「ログイン方法」の質問は正確に分類されています。全体の9割以上を占めるこれらのカテゴリが正解しているため、システム上の「正解率」は依然として95%以上を維持しています。
「画面上の数字は優秀でも、緊急案件を拾えないAIは現場では実用的ではない」という現場の指摘は、ビジネスの真実を突いています。これは、「正解率」という単一の指標に依存し、ビジネスにおいて「何を絶対に間違えてはいけないか」という視点が欠落しているために起こる問題です。
課題の深掘り：なぜ「マイクロ平均」だけでは不十分だったのか
なぜ、開発側の評価と現場の評価にこのような乖離が生まれるのでしょうか。評価指標の計算ロジックとデータの分布を論理的に分析すると、「不均衡データ（Imbalanced Data）」と「マイクロ平均」の相性の悪さが原因として浮かび上がってきます。
「正解率の罠」とデータ不均衡の実態
一般的なB2B SaaS企業のデータ分布を例に考えてみましょう。月間5万件の問い合わせがある場合、その内訳は極めて偏っていることが多く見られます。
- パスワードリセット・ログイン関連: 約35,000件（70%）
- 機能の使い方・設定: 約10,000件（20%）
- 請求・契約関連: 約4,500件（9%）
- システム障害・バグ報告: 約500件（1%）
このように、システム障害に関する問い合わせは全体のわずか1%に過ぎない場合があります。しかし、ビジネスインパクトの観点から見れば、この1%こそが最も迅速に対応すべき「クリティカルな案件」です。
ここで、評価指標として「マイクロ平均（Micro-Average）」を採用している場合の性質が問題になります。マイクロ平均は、クラスの区別なく、全サンプルの予測結果を集計して計算します。
極端な例ですが、もしAIが「すべての問い合わせを『パスワードリセット』と予測する」というモデルだったとしても、このデータ分布なら正解率は70%になります。さらに「機能の使い方」まで正解できるようになれば、それだけで正解率は90%に達します。
つまり、全体の90%を占める多数派クラスさえ正解していれば、残りの1%である「システム障害」をすべて見逃していても、全体のスコア（マイクロ平均）は極めて高く算出されてしまうのです。
マイクロ平均が隠蔽していた少数クラスの悲劇
実務の現場で直面するのは、まさにこの現象です。詳細な混同行列（Confusion Matrix）を確認すると、以下のような実態が判明することがあります。
- パスワードリセットのF1スコア: 0.98（極めて優秀）
- 機能の使い方のF1スコア: 0.95（優秀）
- システム障害のF1スコア: 0.28（実用困難）
システム障害の問い合わせに対し、AIは3回に1回も正しく検知できていない状態です。しかし、これらを全て合算して計算する「マイクロ平均F1スコア」は0.96という高い数値を示します。
マイクロ平均は「データ全体の処理効率」を評価するには適していますが、「頻度は低いが重要度は高い」クラスが存在する場合、その分類精度の低さを多数派の成功で覆い隠してしまいます。この特性を理解せずにモデルを評価すると、ビジネス上の重大なリスクを見落とすことにつながります。
解決策の選定：ビジネスゴールを「マクロ平均」で定義し直す
問題の本質が「評価指標の選び方」にあることは明白です。このような場合、プロジェクトの方針を転換し、モデルの評価基準を「マクロ平均（Macro-Average）」に変更することが論理的な解決策となります。
評価指標の再選定プロセス
マクロ平均とは、各クラスごとの指標（F1スコアなど）を個別に計算し、それらを単純平均する手法です。データ数の多寡に関わらず、すべてのクラスを平等に扱います。
前述の例で言えば、35,000件ある「パスワードリセット」クラスも、500件しかない「システム障害」クラスも、マクロ平均の計算上では同じ重みを持ちます。
もし「システム障害」の精度が低ければ、たとえ他のクラスが完璧でも、マクロ平均のスコアは大きく低下します。つまり、マクロ平均は「どのカテゴリも苦手としないこと」をモデルに要求する指標と言えます。これは、「レアケースの見逃しを許さない」というビジネス要件に合致するアプローチです。
マクロ平均（Macro-Average）採用の意思決定
しかし、この指標変更には課題も伴います。現状のモデルでマクロ平均F1スコアを計算し直すと、数値が0.96から0.68まで急落するといった事態が発生します。
技術的な実装は変わっていないにもかかわらず、評価の物差しを変えただけで、見かけ上の精度が大幅に低下したように見えます。開発現場からは「モチベーションが下がる」「目標が高すぎる」といった懸念の声が上がることも少なくありません。
しかし、プロジェクトマネジメントの観点からは、0.96という数字がビジネス上のリスクを隠蔽している状態を認識し、0.68という数字こそが直視すべき現実の性能であるとチーム全体で共有することが重要です。
社内ステークホルダーへの説明ロジック
さらに重要なのは、経営層やステークホルダーへの論理的な説明です。「なぜ急に精度が下がったのか」という疑問に対し、以下のようなロジックで説明を構築します。
- ビジネスリスクの提示: 「現在のAIは、99件の一般質問に正解しても、1件の重大なシステム障害を見逃す可能性があります。この1件の見逃しが、重大な損失や解約リスクにつながります」
- 指標の意味の翻訳: 「これまでの指標（マイクロ平均）は『作業の自動化率』を示していました。新しい指標（マクロ平均）は『リスクの検知能力』を示します」
- 新たなゴールの設定: 「見かけの数字を追うのではなく、全体の自動化率が多少下がっても、重大なアラートを確実に検知できるAIを目指します。そのために、スコア表記を現実に即した値に修正します」
リスク管理とROI最大化の観点からこのロジックを提示することで、ステークホルダーの理解を得やすくなります。これにより、「マクロ平均の向上」を新KPIとして設定し、モデルの再構築を推進することが可能になります。
実装とモデル改善：指標変更がもたらした技術的アプローチの変化
評価指標を変えるということは、目指すべきゴールが変わるということです。ゴールが変われば、当然そこに至るための技術的なアプローチも変化します。少数クラスの精度を引き上げるためには、主に以下の3つの施策が有効です。
損失関数の調整と重み付け
まず検討すべきは、損失関数（Loss Function）の調整です。一般的な交差エントロピー誤差（Cross Entropy Loss）では、データ数の多いクラスの影響を強く受けます。そこで、クラスごとのデータ数に反比例した「重み（Class Weight）」を設定します。
具体的には、「システム障害」クラスのデータで誤分類した場合のペナルティを、「パスワードリセット」クラスで誤分類した場合の70倍（データ比率の逆数）に設定するといった手法です。これにより、モデルは「システム障害の誤分類は、パスワードリセットの70回の誤分類と同等のペナルティである」と学習するようになります。
さらに、難易度の高いサンプルに焦点を当てる「Focal Loss」の導入も選択肢となりますが、まずはシンプルなClass Weightの実装でベースラインを構築することが推奨されます。
データ拡張（Oversampling）の適用
次に、データの物理的な不均衡を解消するために、サンプリング手法を見直します。少数クラスのデータを複製して増やす「Oversampling」の適用が効果的です。
単純な複製だけでなく、テキストデータ特有のData Augmentation（データ拡張）も有効なアプローチです。例えば、「システムに繋がらない」という文章を、「サーバーに接続できない」「アクセス障害が発生している」といった同義語に置換してバリエーションを増やし、モデルが特定の言い回しに過学習しないよう工夫します。
新指標に基づくモデルチューニングの結果
これらの施策を適用し、マクロ平均F1スコアを最大化するようにハイパーパラメータをチューニングすることで、モデルの挙動は大きく改善されます。
再学習後のスコアの変化例は以下の通りです。
- マイクロ平均F1: 0.96 → 0.93（微減）
- マクロ平均F1: 0.68 → 0.89（大幅向上）
全体の正解率（マイクロ平均）はわずかに低下する傾向があります。これは、少数クラスを重視した結果、多数派クラスの一部で誤検知（過敏な反応）が増加するためです。しかし、ビジネス要件として設定したマクロ平均は大幅に向上させることができます。
成果と検証：数値には表れない「現場の安心」をどう獲得したか
再構築したモデルを現場に投入することで、以前のような深刻な課題は解消に向かいます。現場からも「AIが実用的になった」という評価が得られるようになります。
緊急アラート検知率の劇的改善
最も重要な成果は、「システム障害」クラスの検知率（Recall）の改善です。30%未満だった検知率が、85%を超える水準まで向上するケースもあります。
もちろん、100%の精度を達成することは困難です。一定の見逃しは発生しますし、逆に「通常の質問」を「障害」と誤検知してアラートを出すことも増える可能性があります。しかし、現場の運用においては「重大な障害を見逃される」よりも「空振りでもアラートを出してくれる」方が、リスク管理の観点から安全性が高く評価されます。
運用担当者の信頼回復プロセス
現場のオペレーターからは、以下のようなフィードバックが得られることが多くなります。
「以前のAIは簡単な分類のみを行い、重要な判断を人間に委ねている状態でした。しかし改善後のAIは、最も神経を使う『障害検知』をサポートしてくれます。多少の誤検知は人間が修正すればよく、重要な事象を見逃さないという安心感があります」
AIの真の価値は、単なる正解率の高さではなく、人間の業務における「不安」や「リスク」をどれだけ軽減できるかによって決まります。プロジェクトマネジメントにおいては、この視点を持つことが不可欠です。
定量的成果と定性的評価のギャップ解消
ビジネス的な成果として、障害発生から一次対応までの平均時間が大幅に短縮される効果が期待できます。AIが障害報告を即座に特定し、エンジニアチームへ通知を連携するワークフローが機能し始めるためです。
全体の自動化率が数パーセント低下したとしても、顧客満足度（CSAT）と対応スピードの向上が実現します。「マイクロ平均」という見かけの数字ではなく、「マクロ平均」というビジネス要件に即した指標を選択することで、真のビジネス価値を創出することが可能になります。
結論とアドバイス：多クラス分類における評価指標選定チェックリスト
これらのプロセスから導き出される結論は明確です。不均衡データを扱うAIプロジェクトにおいて、安易にAccuracyやマイクロ平均を絶対視することは避けるべきです。それは時に、重大なビジネスリスクを覆い隠す要因となります。
最後に、AI導入を進めるプロジェクトマネージャーやエンジニアに向けた、評価指標選定のための実践的なチェックリストを提示します。
ビジネス要件から逆算する指標の選び方
プロジェクト開始時に、以下の観点をチーム内で確認することが重要です。
- データの偏りは存在するか
- 主要クラスと最小クラスの比率が1:10以上の場合、不均衡データとしての対策が必要です。
- 「少数派」のデータはビジネス上重要か
- 少数クラスが見逃してはならないリスク（障害、不正検知など）を含む場合、マクロ平均を重視した評価が求められます。
- 「全体効率」と「リスク回避」の優先順位は明確か
- 全体の処理数を最大化したい場合はマイクロ平均が適していますが、特定のリスク見逃しを防ぎたい場合はRecall（再現率）やマクロ平均が適切です。
導入前に確認すべき「データの偏り」診断
現在進行中のプロジェクトにおいては、混同行列（Confusion Matrix）を出力し、クラスごとのF1スコアを確認することを推奨します。もし全体のAccuracyと、最小クラスのF1スコアに20ポイント以上の乖離が見られる場合、そのプロジェクトは「マイクロ平均の罠」に陥っている可能性があります。
これから導入する企業への提言
AI導入は、単なる正解率の追求ではなく、現場のビジネス課題を解決するための手段です。時には、全体の自動化率という数字を下げてでも、ビジネス上守るべき重要なポイントを確実に対処する論理的な判断が求められます。
自社のデータや課題に対して、どの評価指標を設定すべきか迷っている、あるいは現状のAIの評価に違和感がある場合は、専門家に相談することをおすすめします。数値の裏に隠れた本当の課題を体系的に分析し、適切なアプローチを設計することが重要です。
ビジネス要件に合致した正しい評価指標を持つことが、ROIを最大化し、成功するAIプロジェクトの第一歩となります。
コメント