「コード生成の次は「検証」！AI開発で生き残るための3つの防衛策」～【python】今週の人気記事TOP5（2026/09/06）
- AI開発で生き残るための3つの防衛策が提案された
- 不変条件を使ったテスト設計、サイレントバグの発見方法、ドキュメント運用の重要性が挙げられている
- AIの誤動作を防ぐには検証プロセスをしっかり設計する必要がある
#テスト
E2Eテストの合否判定をAIに任せる「AIテスター」を作った件
- E2Eテストの実行結果をAIで一次判定し、人間がズレを修正する仕組みを構築
- 失敗トレース解析・カバレッジギャップ検出・弱いアサーション検出・モック監視の4機能を実装、スキルDBで人間の判断をAIに反映
- 判定のズレをスキルDBに記録し、AIの精度を改善する運用を開始
テストを生成するな、信頼を生成しろ
- AIにテストコードを丸投げするのではなく、信頼できるテストを生成する責任は実装者とレビュワーにある
- テストコードが内部実装をモックしすぎたり、細かい処理を固定しすぎたりする問題、リファクタリングに役立つテストの基準
- テストコードの信頼性は実装者とレビュワーが判断し、テストを通すだけでは意味がないと指摘している
不具合はCIに刻もう。「Red-Green Stacked PR」のすすめ
- 不具合修正のPRをRed-Green Stacked PRとして分割し、CIに再現テストと修正の両方を記録する手法を紹介
- test.failsでテストの成否を反転させ、gh stackでPRをスタック化してCIに履歴を残す
- PR1のCIがGreenになることで現在のコードでテストが落ちることを証明し、PR2のCIがGreenになることで修正後のテストが通ることを証明する
少しずつ変化するシステムこそ「定量指標」で評価する ― 文字起こし精度の検証基盤を作った話
- 文字起こし精度の改善は感覚ではなく統計的指標で評価する仕組みを構築した
- 処理を4層に分けてデータ取得・正規化・検定・可視化を独立させ、CER/WER/DER/RTFなどの複数指標とWilcoxon/McNemar検定を組み合わせた
- 正解データの作成コストが最も重く、統計的検定の結果をレポートで明確に表現する必要がある
「動けばよい」から「壊れにくい」設計へ。QA出身SEが学んだ「失敗を先回りする」視点
- QA経験を活かして設計段階で不具合を先回りする視点を持つようになった
- ユーザー操作フローからバックエンド処理を逆算し、QA目線で設計案にツッコミを入れる
- 設計レビューでの手戻りが減り、異常系やパフォーマンスの考慮が強化された
AWSの資格で使う対象サービス一覧から Snow ファミリーが消えていた話
- AWSのCloud Practitioner試験対象サービス一覧からSnowファミリーが外れた
- In-ScopeサービスにAWS BackupやAmazon S3が含まれるが、SnowballやSnowmobileは含まれない。Out-of-ScopeにAWS Network FirewallやAWS Transfer Familyが挙がっている
- 試験範囲の変更を反映した学習教材を選ぶ際は公式ガイドを確認し、模擬問題の内容と照らし合わせる必要がある
カバレッジ100%にこだわってきた結果、閾値の考え方が変わった話（理論編）
- テストカバレッジを100%にすることを基本方針として、コード構造やテスト設計を見直す
- ガード節や述語関数による分岐の簡略化、test.eachによるパラメータ化テスト、DIによる到達困難な分岐の対応
- カバレッジ100%は品質の保証ではなく、テストの網羅性を確保するための必要条件であり、ミューテーションテストとの併用が推奨される
テスト見積もりは掛け算2つで出せる
- テストケース数はテストオブジェクトとテスト観点の掛け算で出せる
- テストオブジェクト×観点でケース数を算出し、生産性係数で工数に換算する
- 自社の生産性係数を測定し、過去データで補正する際の注意点が記載されている
900件のテストが緑でも、本番では壊れる──LLM製プロダクトの品質保証で学んだこと
- LLMで開発したプロダクトで本番環境で不具合が発生し、テストとレビューの限界が明らかになった
- テストダブルの契約と本番実装の差、監視値の嘘、0件と障害の区別、終了処理の不備、LLMレビューの収束が問題点
- テストの観測対象を本番の契約に合わせる、監視値の正しさをテストする、障害を型として区別する必要がある
開発経験がない自分がE2E環境構築の経験から学んだこと
- レコメンドプロジェクトにPlaywrightを使ったE2Eテスト環境を構築した
- ローカル環境と開発コンテナの違い、テストケースの共通化と保守性の向上
- テストコードの重複を減らすだけでなく、確認したい観点を明確にすることが重要だった
インフラエンジニアでもない私がGradleをいじってチームイベント向けの計測ツールを作った話
- JUnitテストカバレッジを計測するGradleカスタムタスクを実装した
- Test型タスクで対象パッケージのテストを実行、JacocoReportで対象パッケージのカバレッジを集計
- テスト実行範囲を制限し、CSVに出力してGoogleスプレッドシートで可視化する仕組みが具体的に説明されている
購入フローのテスト組合せ爆発対策で形式検証に入門した
- 購入フローのテスト組合せ爆発を形式検証で対策
- 状態遷移と不変条件を定義し、TLA+でモデル検証。AIで事前条件・事後条件を抽出して擬似コード生成
- 冪等性の欠如や多重実行時の不整合を検出。監査ワークフローで数百kトークン使用が必要
ノーコードプラットフォームからPlaywrightへテストを移行した話。Part 3. MarkdownからPlaywrightコードへ
- ノーコードテストケースをMarkdownからPlaywrightコードに変換するパイプラインを構築した
- 実装ループでロケーター調整とリファクタリング、セルフ監査で不在チェックの罠を検出
- テストの独立性を保つため共有状態の変更テストをシリアル実行し、マルチユーザーテストでブラウザコンテキストを分離する
AIに作らせたコードを、まっさらな環境で動かしてみた
- AI生成コードをクリーン環境で動かすと68.3%が成功したが、再現実験では4本中4本が一発で動いた
- 依存の三層モデル（Dc/Dw/Dr）と、Python/JavaScriptのプロジェクト成功率が比較されている
- 依存のギャップよりコードのバグが失敗の主因で、テストを書くことで改善できることが示されている
週15分「バグに3つの問いを投げる」だけで、テストの先が動き出した
- 週15分のバグ振り返りでテストからQCへの第一歩を踏み出す
- 3つの問い（偏り・再発・防げたか）を投げて分析、1行の記録を残す
- 15分の短い時間で習慣化し、テストの後に振り返りを組み込むことで改善を進める
「テスト自動化したいけど、何から始める？」を手探りで進めた記録
- テスト自動化の実装を手探りで進めた過程を紹介
- Playwright MCPとPythonテストコードの使い分け、再利用可能な関数の設計、失敗時の対応ルール
- 1ケースから始め、失敗内容をルールとして残すことで運用負荷を下げる手法が有効だった
AIにテストを書かせると、決まって同じ場所が抜ける
- AIが生成したテスト仕様書は78件のテストケースを自作し、要件の矛盾も指摘したが、規格で測ると平均63.12%の網羅性だった
- 同値分割（EP）のvalidのみでinvalidを抜ける、境界値分析（BVA）の下限を無視、決定表（DT）の条件を1つずつしか動かさない
- テストケースの網羅性は基準によって100%から25%まで変化し、同じ文書でも異なる結果になることが分かった
基本情報｜科目B「アルゴリズム問題」、パズルが好きな人はたぶん好き
- 科目Bの疑似言語は新しいプログラミング言語ではなく、日本語ベースの共通ルール
- 変数宣言・代入・配列・コメント・条件分岐・繰り返しの基本構文が中心
- プログラムの動作を紙に書きながら1行ずつ追うことで理解が深まる
【さくらのAI Engine」C#のモジュールをソースコードレビューしてみた！
- C#のコードにエラーハンドリングと入力検証を追加した
- Int32.Parseをint.TryParseに変更し、例外処理をtry-catchで囲んだ
- 入力が不正な場合に適切なエラーメッセージを出力するようにした
