はじめに — 実務でよくあるつまずきに寄り添う
AI機能を現場に載せるとき、最初につまずきやすいのは「どの段階で何をテストすればよいか」が不明瞭な点です。データは通っているけれど前処理で壊れる、モデルは学習時は良いが本番で精度が落ちる、APIは動くがレイテンシで顧客に影響が出る――こうした現場の悩みに焦点を当て、実務で使える手順とテンプレートを示します。
この記事のゴール
データ・前処理・モデル・統合の各段階で必要なテストを整理し、pytest／Great Expectations等を用いたPythonでの自動化テンプレートとCI組み込み手順を、現場でそのまま使える形で提示します。理論よりも実務性を重視します。
テスト種類の一覧（俯瞰）
| テスト領域 | 目的 | 代表的ツール/手法 |
|---|---|---|
| データ品質テスト | NULL率、分布差異、期待レンジの検証 | Great Expectations, Pandas, SQL |
| 前処理ユニットテスト | 変換ロジックの再現性とエッジケース検証 | pytest |
| モデル振る舞いテスト | KPI・境界ケース・予測分布の検査 | pytest, numpy, scikit-learn |
| 統合/E2Eテスト | API経由での実運用フロー検証 | requests, HTTPクライアント |
| 回帰テスト | 性能悪化の検出 | 評価スクリプト、履歴DB |
| 負荷/スモークテスト | 可用性と初期健全性のチェック | 簡易スクリプト、監視ツール |
各テストの実務手順とPython実装例
1) データ品質テスト（Great Expectationsの例）
目的：本番に入るデータが契約（スキーマ・欠損率・分布）を満たすかを自動で検証します。
短い定義例：
expectation_suite = {
"expectations": [
{"expect_column_to_exist": {"column": "age"}},
{"expect_column_values_to_not_be_null": {"column": "user_id"}},
{"expect_column_mean_to_be_between": {"column": "score", "min_value": 0.4, "max_value": 0.9}}
]
}
運用のポイント：
- 閾値は業務KPIとコストを基に決める（例：null率は業務で許容できる最大値を設定）。
- Feature Store／本番DBからのサブセットを定期抽出し、現実に近いデータで検証する。
2) 前処理ユニットテスト（pytestの例）
目的：前処理関数が期待どおりにデータを変換するかを小さな単位で検証します。
pytestの短いサンプル（htmlに貼れる形）：
def test_normalize_age():
data = {"age": ["25"," 30","NA"]}
out = normalize_age(data)
assert out["age"][0] == 25
assert out["age"][2] is None
実務的注意点：
- 境界値（最小/最大/空文字/異常文字）を必ず用意する。
- 外部依存（APIやDB）はモック化して安定したテストを維持する。
3) モデル振る舞いテスト（KPIと分布チェック）
目的：主要KPIが最低許容値を満たすこと、確率予測の分布に異常がないことを確認します。
短い例：
def test_model_auc_threshold(model, X_val, y_val):
preds = model.predict_proba(X_val)[:,1]
auc = roc_auc_score(y_val, preds)
assert auc >= 0.70
def test_prediction_distribution(model, X_sample):
preds = model.predict_proba(X_sample)[:,1]
assert preds.mean() >= 0.05 and preds.mean() <= 0.5
注意点：AUCなどの閾値は、ビジネスコスト（誤検知のコストや見逃しコスト）をベースに決めること。
4) 統合 / E2E スモークテスト（HTTPリクエスト例）
目的：API経由での実運用フローが通るかを確認します。デプロイ直後やスモークとして実行します。
import requests
resp = requests.post('https://api.example.com/predict', json={"feature": 1.2})
assert resp.status_code == 200
data = resp.json()
assert 'prediction' in data
実務ポイント：本番環境を直接叩く代わりにステージングで実行し、レスポンスのスキーマとレイテンシを計測する。
CI/CDへの組み込み（第65回との接続）
テストを品質ゲート化する基本手順：
- テスト実行→結果に閾値を設定→失敗ならデプロイ停止
- 品質指標は履歴DBに保存し、回帰を自動検出する
GitHub Actionsのワークフロー雛形（要約）：
name: CI
on: [push]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v2
with: {python-version: '3.9'}
- name: Install
run: pip install -r requirements.txt
- name: Run tests
run: pytest -q
失敗時の実務対応：
- Slack通知＋自動で障害チケットを作成（Webhook/IFTTTやZapierで実装可）。
- 閾値の緩和は人が判断し、必ずレビュー履歴を残す。
詳細なCI/CDの組み方は第65回の記事も参照してください：第65回 CI/CD 記事
監視との連携と運用ルール（第60回との接続）
テストはデプロイ前のゲートだけでなく、本番稼働後の監視と連動させることが重要です。第60回で述べた監視方針と合わせ、次のように運用します。
- 本番メトリクス（リクエスト失敗率、平均レイテンシ）をSLAとして定義する。
- データドリフトや特徴分布の変化は週次で自動レポート化し、閾値超過でアラート発報。
参考：第60回 監視運用方針（https://manageai.online/60）
テストデータとFeature Storeの実務活用（第72回との接続）
実務的には、完全な本番データは使えないことが多いので「本番準拠のサブセット」「シードデータの管理」「Feature Storeからの再現可能な抽出」が鍵です。第72回のFeature Storeの話と接続して、以下を実施してください。
- Feature Storeにテスト用タグを付け、固定シードで取り出せるAPIを作る。
- Syntheticデータでドリフトや極端値をシミュレートして境界条件を網羅する。
第72回のFeature Store記事も参照してください：第72回
品質基準と受け入れ条件のテンプレート
| 対象 | 基準（例） | 注意点 |
|---|---|---|
| データ品質 | null率 < 1%, 主要数値の分布KS距離 < 0.1 | 業務特性により許容値は要調整 |
| モデル性能 | AUC >= 0.70（目安）／F1最低値指定 | コストベースで閾値を決める |
| API可用性 | 成功率 >= 99.5%, p95 レイテンシ < 500ms | サービスSLAに合わせる |
運用上の注意点とよくある失敗
- 前処理テストばかり充実させて統合テストを怠ると本番で破綻する。
- テストデータの陳腐化を放置するとドリフト検知が効かなくなる。
- 閾値を固定化しすぎると過剰アラートで運用負荷が増える。
- テストの実行コスト（時間・クラウド費用）を見積もり、夜間バッチ化やサンプル化で抑える。
チェックリスト（導入初週・月次レビュー・障害時）
| タイミング | やること |
|---|---|
| 導入初週 | 基本的なデータ品質チェック、前処理ユニットテストの整備、簡易E2Eスモークの実行 |
| 月次レビュー | モデルKPI履歴の確認、閾値の妥当性評価、テストデータの更新 |
| 重大障害発生時 | 直近デプロイのロールバック、テストログの集約、原因分析と恒久対策の実施 |
すぐ使える次の一歩（テンプレートリポジトリ／最小CI）
- まずはリポジトリを一つ用意し、pytestとGEの簡易テストを置く。
- 最小のGitHub Actionsでpushごとにpytestを回し、失敗でマージ禁止にする。
- Slack通知と障害チケットの自動生成を組み合わせる（小さく始める）。
まとめ
実務でAIを「壊れにくく」するには、単体のテストだけでなくデータ→前処理→モデル→APIという流れ全体を意識したテスト設計が必要です。Great Expectationsでデータ契約を守り、pytestで前処理とモデルの振る舞いを検証し、CIで品質ゲート化して初動の運用ルールを作る。さらにFeature StoreやSyntheticデータを活用して再現性の高いテストデータを用意することが、稼働後の安定につながります。
まずは「小さく確実に」テストを回すパイプラインを作り、月次で閾値やテストデータを見直す運用を始めてください。詳しいCI/CD手順は第65回、Feature Storeやデータの扱いは第72回、監視は第60回の記事と合わせて実装すると効果的です。