【授業レポート】システム開発入門 第29週目 〜改善実装の検証＆A/Bテスト入門〜
第29週目は、先週のログ解析で見つかった課題に対する改善実装を行い、その効果を測るための**再テストとA/Bテスト（比較検証）**の基礎を学びました。実装→検証→比較という一連のサイクルを体験することで、「改善はやって終わりではなく、数値で確かめる」姿勢を養う週です。
■ 先生の導入：「仮説を立てて、確かめて、また改良する」
田中先生：「良くなったつもりでも、数字で確かめないとわからない。A/Bテストは『どちらが本当に良いか』を客観的に判断するための便利な手法です。」
■ 今日の目標
- 先週の改善（キャッシュTTL延長・入力長制限・フォールバック調整など）を実装する。
- 改善前後で応答時間・成功率・再生成率など主要指標を比較する。
- シンプルなA/Bテストを設計して、2案のうちどちらが効果的かを測ってみる。
■ 実習①：改善案の実装とデプロイ（学習環境内で）
各班は前回の解析で上げた改善案のうち優先度の高いものを2〜3個選び、実装してテスト環境に反映しました。代表的な実装例：
- キャッシュTTL延長：300秒 → 900秒に変更（短時間の重複リクエストを削減）
- 入力前処理の強化：長すぎる入力は要約プロンプトに差し替える
- フォールバック文言の改善：ユーザーに具体的な次の行動（「公式サイトで確認」等）を提示
実装後、同じ負荷スクリプトで再び負荷テストとログ収集を行いました。
■ 実習②：主要KPIの計測と比較
収集したログから、改善前（コントロール）と改善後（テスト）の主要指標を比較しました。授業で扱った指標例：
- 平均応答時間（ms）
- 成功率（ok / 全リクエスト）
- 再生成要求率（ユーザーが再生成を押した割合）
- フォールバック発生率（fallbackステータスの割合）
簡単な集計スニペット（授業用）：
# logs_control / logs_test はそれぞれのログリスト
def summarize(logs):
total = len(logs)
ok = sum(1 for l in logs if l["status"]=="ok")
return {"total":total, "ok_rate": ok/total, "avg_latency": sum(l["latency_ms"] for l in logs)/total}
生徒の観察例：
- キャッシュTTL延長で平均応答時間が約15%改善。
- 入力要約を入れた班ではタイムアウトが減り、成功率が向上。
（※数値は授業内の実測値の例で、班ごとに差が出ました）
■ 実習③：A/Bテストの設計と実行（簡易版）
A/Bテストの目的・設計手順を学び、実際にクラス内で簡易A/Bを回しました。
A/Bテストの基本ステップ
- 仮説を立てる：例）「キャッシュTTLを延ばすと平均応答時間が短くなり、再生成率が下がる」
- 比較案を作る：A = 現行（TTL=300）、B = 改善（TTL=900）
- トラフィック分割：リクエストを半分ずつ割り振る（学習環境ではランダム割当や時間帯割当で模擬）
- 十分なサンプルを集める：短すぎる期間はブレが大きくなる
- 指標で比較する：主要KPIの差を比較し、統計的に意味があるかを議論（授業では有意差検定の紹介のみ）
- 結論を出し、次の改善へ繋げる
授業では簡易に「時間帯でA/Bを分けて1時間ずつ実行→指標を比較」する方法で実施しました。
■ ディスカッション：結果の読み方と注意点
結果を読み解く際のポイントをクラスで確認しました。
- サンプルサイズが小さいと誤判定しやすい
- 季節やネットワーク条件で揺らぎが出ることがある
- 指標は複数見て総合判断する（応答時間だけでなく成功率やUX指標も重要）
- 改善による副作用（例：TTL延長で情報の鮮度が落ちる）を考慮する
生徒の感想：「Aの方が速いけどBの方が再生成率が低い…どちらを優先するかは目的次第だね」
■ 先生のひとこと
「A/Bテストは“数字で学ぶ文化”を育てます。小さく仮説を立てて検証し、結果を次の仮説に繋げることがエンジニアの良い習慣です。重要なのは、結果に素直に向き合う姿勢です。」
■ 生徒のふり返りコメント
- 「実際に比較すると、思っていた効果と違うことがよく分かった」
- 「A/Bの設計は単純そうで難しい。偏りをどう避けるかがポイント」
- 「改善→検証を短いサイクルで回すのが一番学べると感じた」
■ 来週の予告：改善の恒常化とドキュメンテーション
次週は、今回の改善を**本番的に運用するための手順化（チェックリスト作成）**と、変更履歴／効果報告のドキュメント化を行います。継続的改善を支える“仕組み作り”に取り組みます。
改善を実行し、数値で確かめた29週目。生徒たちは「仮説→実装→検証→再仮説」のサイクルを体験し、現場で使える改善スキルを一歩深めました。