「請求画面のバグを AI に直してもらったら直った。でも翌週、なぜか見積画面の合計が合わなくなった」――この『直したはずが別が壊れる』現象が、リグレッション（デグレ）です。 AI 生成コードは「動くコード」を素早く出しますが、そのコードが正しいことを証明するテストは、頼まない限りほとんど書きません。書かせても、正常系を 1 ケースなぞるだけの薄いものになりがちです。
テストが無いコードは、変更するたびにロシアンルーレットになります。1 箇所を直すと、その共通関数に依存していた別の機能が静かに壊れる。気づくのは顧客からのクレーム電話か、月末の数字が合わないときです。専門家が常駐しない中堅企業（年商 30〜300 億・情シス 1〜3 名）では、この「静かな破壊」が本番障害として表面化しやすいといえます。
本記事は連載「バイブコーディング危機」第 19 回として、なぜ AI コードでテストが抜けるのか、リグレッションが起きる典型シナリオ、テストの種類とテストピラミッド、CI 自動実行・PR ゲート・カバレッジの最低限、AI にテストを書かせるコツ（ただし人がレビュー）、悪い例 / 良い例、リリース前チェック、30 分チェックリスト、そして 今日から小さく始める回帰テスト を整理します。
**連載「バイブコーディング危機」**は、AI で自社システムを開発する中堅企業向けに、専門家不在で起きるリスクを順に解説していきます。 第 4 回（サービス停止の財務影響・江崎グリコの教訓） 第 11 回（脆弱性スキャン SAST / DAST / SCA で機械的に検出する） 第 14 回（属人化・引き継げないシステムの再生）
目次
- なぜ AI 生成コードはテストが抜けるのか
- リグレッション（デグレ）とは何か：1 箇所直すと別が壊れる構造
- 変更起因の本番障害：公開事例から学ぶ
- リグレッションが起きる典型 4 シナリオ
- テストの種類とテストピラミッド
- 悪い例 / 良い例：薄いテストと回帰テスト
- 最低限の入れ方：CI 自動実行・PR ゲート・カバレッジ
- AI にテストも書かせるコツ（ただし人がレビュー）
- 今日から小さく始める回帰テスト（4 ステップ）
- リリース前チェックリスト
- 中堅企業向け 30 分チェックリスト
- who should read / いつ GXO に相談すべきか
- まとめ
- 参考一次ソース
なぜ AI 生成コードはテストが抜けるのか
AI コーディングアシスタント（Claude / GitHub Copilot / Cursor など）に「この機能を作って」と頼むと、機能本体のコードは出てきます。しかし、テストコードは明示的に頼まない限り、ほとんど付いてこないか、付いても薄いものになりがちです。理由は構造的です。
理由 1: プロンプトが「動くもの」を求めている
バイブコーディングの会話は「○○ができるようにして」「エラーを直して」が中心です。「テストも書いて」「壊れていないことを確認できるようにして」と頼む人は少数派です。AI はプロンプトに忠実なので、求められないテストは省略します。
理由 2: 「動いた」が成功体験になり、検証が後回しになる
画面で動けば成功に見えます。テストは「動かない可能性」に備える保険であり、動いている今は価値が見えにくい。結果、「後でまとめて書く」が永遠に来ません。
理由 3: AI が書くテストは「自分のコードに通るテスト」になりがち
AI に「テストを書いて」と頼むと、いま生成したコードがそのまま通るテストを書く傾向があります。仕様ではなく実装をなぞるため、バグもろとも「正しい」と固定してしまう（実装と同じ間違いを期待値に書く）ことがあります。境界値・例外系・異常系は薄くなりがちです。
理由 4: テストの「土台」がそもそも無い
中堅企業のバイブコーディング環境では、テストを自動実行する仕組み（CI）も、テスト用のデータベースも、フォルダ構成も無いことが多い。土台が無いとテストは書きにくく、書いても誰も実行しないため、すぐ陳腐化します。
| 抜ける理由 | 中堅企業で起きること |
|---|---|
| プロンプトがテストを求めない | 機能だけ増え、検証は丸ごと無い |
| 「動いた」で満足 | リリースのたびに祈るしかない |
| 実装をなぞるテスト | バグを「正しい」と固定する |
| CI・土台が無い | 書いても実行されず腐る |
専門家がレビューしない環境では、これら 4 つが同時に成立します。 だからこそ「テストの最低限」を仕組みで強制する必要があります。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。ROI 試算シート・失敗要因チェックリストをその場で共有します。
リグレッション（デグレ）とは何か：1 箇所直すと別が壊れる構造
リグレッション（regression、現場では「デグレ／デグレード」とも） とは、以前は正しく動いていた機能が、別の変更がきっかけで壊れることを指します。新しいバグではなく「過去に潰したはずのバグの復活」や「無関係に見える機能の破壊」が含まれます。
なぜ起きるのか。ソフトウェアの機能は目に見えない依存関係でつながっているからです。
- 請求画面と見積画面が、同じ「税込金額を計算する関数」を共有している
- 在庫数を更新するコードが、複数の画面から呼ばれている
- ある API のレスポンス形式を、3 つの別画面が前提にしている
このとき、請求画面のために共通関数を 1 行直すと、その関数を使っている見積画面・受注画面も同時に挙動が変わります。直した人は請求画面しか見ていないので、他が壊れたことに気づきません。テストが無ければ、壊れたことを誰も検知できないまま本番に出ます。
リグレッションの本質：変更の影響範囲が「自分が見ている画面」を超えて広がること。テスト（特に回帰テスト）は、この「見えない影響範囲」を機械的に監視する仕組みです。
テスト不在のまま機能追加を重ねるほど、依存関係は複雑になり、1 行の変更が引き起こす連鎖の規模が大きくなります。最初は「たまに壊れる」だったものが、半年後には「触るのが怖いシステム」になります。これは連載第 14 回（属人化・引き継げないシステム）で扱う「変更が怖くて誰も触れない」状態と地続きです。
変更起因の本番障害：公開事例から学ぶ
「1 つの変更が本番を壊す」は、世界的な大企業でも繰り返し起きています。以下は公開資料で確認できる事例です。いずれもバイブコーディングが直接の原因ではありませんが、「変更の検証が不十分なまま本番に出ると何が起きるか」を経営層が直視するための教材として参照します。
事例 1: Knight Capital 2012（デプロイ不整合・45 分で約 4 億 4,000 万ドルの損失）
2012 年 8 月 1 日、米国の証券会社 Knight Capital Group は、新しい取引ソフトウェアの導入時に 8 台中 7 台のサーバーにしか新コードが配信されず、残り 1 台に古い機能（過去に使われていたコード）が残った状態で取引が始まりました。再利用されたフラグが古いコードを意図せず再起動させ、大量の誤発注が発生。同社は SEC への 8-K 報告で、誤った取引ポジションの解消により 税引前で約 4 億 4,000 万ドル（約 $440 million）の実現損失 を計上したと開示しています。同社は資本基盤が大きく毀損し、緊急の資本注入（約 4 億ドル）を受けて存続しました。
- 本質：本番に出す前に「全台が同じ状態か」「古いコードが残っていないか」を検証する仕組みが無かった
- 教訓：デプロイは「一部だけ更新される」事故が起きる。リリース後のスモークテストと整合性チェックが不可欠
- 出典：SEC EDGAR — Knight Capital Group 8-K (2012)
事例 2: CrowdStrike 2024（設定更新の検証不足で世界規模の障害）
2024 年 7 月 19 日、セキュリティ製品 CrowdStrike Falcon の コンテンツ更新（Channel File 291） に論理エラーが含まれ、世界中の Windows 端末がクラッシュ（ブルースクリーン）しました。CrowdStrike の事後報告（PIR / RCA）によれば、入力フィールド数の不整合（テンプレートは 21、実際の入力は 20）と、それを検出すべき Content Validator のロジック不備・実行時の境界チェック欠落 が重なって発生しました。CISA も広域 IT 障害として注意喚起を出しています。
- 本質：「検証する仕組み（Validator）」自体にバグがあり、不正な更新がそのまま本番に流れた
- 教訓：境界値・入力数の不一致は、テストが薄いと最も見逃しやすい典型。検証の仕組みも検証対象になる
- 出典：CrowdStrike — Channel File 291 Incident RCA / CISA — Widespread IT Outage Due to CrowdStrike Update
中堅企業への含意
これらは大企業の事例ですが、構造は中堅企業のバイブコーディングと共通です。
| 共通する失敗構造 | 中堅企業のバイブコーディングでの現れ方 |
|---|---|
| 変更前後の整合性を検証しない | 直した画面しか確認せず本番反映 |
| 境界値・入力数の不一致を見逃す | 「件数 0 件」「桁あふれ」で別画面が落ちる |
| 検証の仕組みが無い／弱い | テスト無し・CI 無しで手動目視のみ |
| リリース後の確認が無い | デプロイして「動くはず」で放置 |
規模は違っても、原因は同じです。 違いは「検証を仕組みにしているか」だけです。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
リグレッションが起きる典型 4 シナリオ
中堅企業のバイブコーディングで、特に頻発する 4 つのパターンを整理します。
シナリオ 1: 共通関数の変更（最も多い）
例：消費税計算の関数 calcTaxIncluded() を、軽減税率対応のために修正。請求画面は直ったが、同じ関数を使う見積画面・定期請求バッチの合計が変わってしまった。請求担当しか見ていないので、見積の異常は翌週まで気づかない。
- 危険サイン：「共通」「util」「helper」「common」と名の付くファイルを触ったとき
- 守り方：その関数を呼んでいる全箇所を grep で洗い出し、各呼び出し元のテストを通す
シナリオ 2: 暗黙の依存（誰も知らないつながり）
例：API のレスポンスに含まれる status フィールドを「不要だから」と削除。実は管理画面のフィルタ機能がそのフィールドに依存していて、管理画面が空白になった。コード上は無関係に見えるため、レビューでも見落とす。
- 危険サイン：API のレスポンス形式・DB のカラム・共通の定数を変えるとき
- 守り方：契約（インターフェース）を変えるときは「誰が使っているか」を必ず確認。E2E テストで横断的に検知
シナリオ 3: 境界値（0 件・最大・null）
例：一覧表示を改善したら、データが 0 件のときにエラー画面になった。あるいは桁数の多い金額で表示が崩れた。AI が書くコードは「正常な件数のデータ」を前提にしがちで、0 件・1 件・最大件数・null・空文字 が抜けやすい。
- 危険サイン：一覧・集計・ページング・検索結果が空のとき
- 守り方：境界値（0 / 1 / 最大 / null / 空）を必ずテストケースに入れる
シナリオ 4: 例外系（失敗したときの動き）
例：決済 API がタイムアウトしたとき、注文だけ確定して決済が抜ける（または二重決済）。AI コードは「成功したとき」の処理は書くが、失敗・タイムアウト・リトライ・中断時の整合性 は薄い。連載第 4 回で扱った「例外未処理によるサーバー停止」と同根です。
- 危険サイン：外部 API・決済・在庫引き当て・メール送信など「失敗があり得る」処理
- 守り方：異常系テスト（API が落ちた / 遅い / 不正な値を返した）を必ず用意する
| シナリオ | 見逃される理由 | 最低限のテスト |
|---|---|---|
| 共通関数の変更 | 呼び出し元が複数あると気づけない | 呼び出し元ごとのユニットテスト |
| 暗黙の依存 | コード上は無関係に見える | E2E / 結合テストで横断検知 |
| 境界値 | 正常データしか試さない | 0 / 1 / 最大 / null を網羅 |
| 例外系 | 「成功」だけを書く | 異常系・タイムアウトを再現 |
テストの種類とテストピラミッド
テストは粒度によって種類が分かれます。中堅企業が最低限知っておくべき 4 種類と、それらの**バランス（テストピラミッド）**を整理します。テストピラミッドは Mike Cohn が提唱し Martin Fowler が広めた考え方で、速くて安いテストを土台に多く、遅くて高いテストを頂点に少なく配置します。
4 種類のテスト
| 種類 | 何を確かめるか | 速度 | コスト | 目安の量 |
|---|---|---|---|---|
| ユニットテスト | 関数 1 つの入出力（税計算など） | 速い（ミリ秒） | 安い | 一番多く |
| 結合テスト | 複数部品の連携（API ↔ DB など） | 中 | 中 | 中くらい |
| E2E テスト | 画面操作の一連の流れ（ログイン→注文→完了） | 遅い（秒〜分） | 高い | 少なく |
| スモークテスト | 「最低限ここだけは動く」の即時確認 | 速い | 安い | リリース毎に必ず |
テストピラミッドのイメージ
▲ E2E（少数・重要な業務フローだけ）
▲▲▲ 結合（API・DB の連携）
▲▲▲▲▲ ユニット（関数単位・最も多く）
━━━━━━━━━ 土台：CI で全部自動実行
なぜこの形が良いのか
- ユニットテストは速くて安いので、数百本あっても数秒〜数十秒で回ります。リグレッションを最も早く・安く検知できます
- E2E は本物に近い反面、遅く・壊れやすく・メンテが重い。ここに頼りすぎると「テストが遅くて誰も回さない」状態になります
- スモークテストは「リリース直後の安心」。主要な数画面が開くか、ログインできるか、注文が通るかだけを 1〜2 分で確認します
中堅企業の現実的な始め方
最初から全部は要りません。優先度はこの順です。
- スモークテスト：主要 3〜5 画面が開くか（即効・最小コスト）
- ユニットテスト：金額計算・在庫計算・権限判定など「壊れると金や信頼に直結する関数」から
- E2E テスト：売上に直結する 1〜2 本の業務フロー（注文確定など）だけ
- 結合テスト：余力が出たら API ↔ DB の主要経路に追加
**「全部を完璧に」ではなく「壊れたら困る順に薄く」**が、情シス 1〜3 名の現実解です。
悪い例 / 良い例：薄いテストと回帰テスト
悪い例 1: 実装をなぞるだけのテスト（バグを固定する）
// 悪い例：AI が「自分のコードが通るように」書いたテスト
test("税込計算", () => {
// 実装が「* 1.1」になっているのを、そのまま期待値にしている
expect(calcTaxIncluded(1000)).toBe(1100);
// → 軽減税率(8%)も標準税率(10%)も区別していないのに、
// このテストは「正しい」と言ってしまう
});
仕様（軽減税率は 8%）を確認せず、実装の出力をそのまま期待値にしているため、仕様バグを「正しい」と固定します。
良い例 1: 仕様に基づき、境界値・異常系を入れる
// 良い例：仕様から期待値を決め、境界・異常系も網羅
test("税込計算：標準税率10%", () => {
expect(calcTaxIncluded(1000, "standard")).toBe(1100);
});
test("税込計算：軽減税率8%", () => {
expect(calcTaxIncluded(1000, "reduced")).toBe(1080);
});
test("税込計算：0円・端数・null", () => {
expect(calcTaxIncluded(0, "standard")).toBe(0); // 境界値
expect(calcTaxIncluded(99, "standard")).toBe(108); // 端数(切り捨て規則を確認)
expect(() => calcTaxIncluded(null, "standard")).toThrow(); // 異常系
});
悪い例 2: 直すたびに手で全画面を目視
新機能を入れるたびに、担当者が目視で主要画面を一通りクリックして確認。時間がかかる上、見ていない画面のリグレッションは検知できません。人によって確認範囲がバラつきます。
良い例 2: 小さな回帰テストを足していく
バグを 1 つ直すたびに、「そのバグを再現する小さなテスト」を 1 本書いてから直す。これを繰り返すと、同じバグの再発（リグレッション）を機械が永久に見張ってくれます。
// 良い例：見つけたバグごとに「再発防止テスト」を1本足す
test("回帰: 在庫0件のとき一覧がエラーにならない（2026-06 障害対応）", () => {
const result = renderInventoryList([]); // 0件
expect(result).not.toThrow();
expect(result.message).toBe("在庫はありません");
});
**回帰テストは「最初から網羅」ではなく「壊れた箇所から 1 本ずつ増やす」**のが続けやすいコツです。
最低限の入れ方：CI 自動実行・PR ゲート・カバレッジ
テストは「書く」だけでは腐ります。書いたテストを誰が・いつ・どう実行するかを仕組みにして初めて効きます。
1. CI で自動実行（人の意志に頼らない）
GitHub Actions / GitLab CI などで、コードを push するたびにテストを自動実行します。人が「テスト回すの忘れてた」を物理的に起こさせないのが目的です。
# 最小例（GitHub Actions）：push のたびにテストを回す
name: test
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test # ユニット・結合
- run: npm run test:smoke # スモーク
2. PR ゲート（テストが落ちたらマージできない）
プルリクエスト（PR）でテストが失敗したら、本番ブランチにマージできないように設定します（ブランチ保護ルール）。これにより「テストが赤いまま本番に出る」を構造的に防ぎます。脆弱性スキャン（連載第 11 回）も同じ PR ゲートに組み込むと、品質とセキュリティを一度に守れます。
3. カバレッジの考え方（数字を目的化しない）
カバレッジ（テストがコードのどれだけを通ったか）は便利ですが、100% を目的にすると本末転倒です。中堅企業の現実的な方針はこうです。
- 金や信頼に直結する箇所（金額計算・権限・決済・在庫）は厚く（80% 目安）
- 管理画面の表示など影響が小さい箇所は薄くてよい
- **「カバレッジを下げる変更は PR で警告」**にして、じわじわ増やす
- 数字より 「壊れて困る経路がテストされているか」 を優先する
| 仕組み | 目的 | 中堅企業の最小実装 |
|---|---|---|
| CI 自動実行 | 実行忘れを物理的に防ぐ | push でテストを回す |
| PR ゲート | 赤いまま本番に出さない | ブランチ保護＋必須チェック |
| カバレッジ | 手薄な箇所を可視化 | 重要経路だけ閾値、全体は参考値 |
これらは個別の DevSecOps 設計（GXO の DevSecOps 支援）として整備すると、テスト・スキャン・リリースを一本のパイプラインにまとめられます。
AI にテストも書かせるコツ（ただし人がレビュー）
テストを書く工数は、AI に任せると大きく下がります。**ただし「AI に書かせて、人が必ずレビューする」**が原則です。AI 任せにすると、前述の「実装をなぞるバグ固定テスト」を量産します。
コツ 1: 仕様を先に言語化してから書かせる
「このコードのテストを書いて」ではなく、**「仕様はこう（標準税率 10% / 軽減税率 8% / 端数切り捨て / null は例外）。この仕様を検証するテストを書いて」**と、期待値の根拠を仕様で与えます。実装ではなく仕様に基づくテストになります。
コツ 2: 境界値・異常系を明示的に要求する
「0 件・1 件・最大件数・null・空文字・桁あふれ・外部 API 失敗時 のケースも入れて」と具体的に指示します。AI は言われれば書きますが、言われないと正常系だけになりがちです。
コツ 3: 「テストを通すためにテストを緩めるな」と縛る
AI に修正を頼むと、**テストが落ちたときに『テスト側を実装に合わせて緩める』**ことがあります。「テストが落ちたら実装を直す。テストの期待値は仕様に基づくので勝手に変えない」と明示します。
コツ 4: 人のレビューでここを見る
| レビュー観点 | 確認内容 |
|---|---|
| 期待値の根拠 | 仕様（社内ルール・法令）に基づくか。実装の出力を写しただけでないか |
| 境界・異常系 | 0 / null / 最大 / 失敗が入っているか |
| 意味のある検証か | expect(true).toBe(true) のような無意味テストでないか |
| 壊れたら気づくか | わざとバグを入れたとき、本当にテストが落ちるか（変異テスト的に確認） |
「AI が書いたテストが緑だから安心」ではなく、「人が見て、壊したときに落ちる」ことを確認して初めて、テストは資産になります。
今日から小さく始める回帰テスト（4 ステップ）
「テストをゼロから全部」は挫折します。壊れて困るところから 1 本ずつ始めるのが続くコツです。
ステップ 1: 「壊れたら一番困る関数」を 3 つ選ぶ（30 分）
金額計算・在庫引き当て・権限判定・決済など、間違うと金か信頼が飛ぶ関数を 3 つだけ選びます。全部はやりません。
ステップ 2: その 3 つにユニットテストを書く（半日）
正常系 1〜2 本＋境界値（0 / 最大 / null）＋異常系を AI に下書きさせ、人が仕様に照らしてレビューします。この時点で「変更の地雷原」に最初の見張りが立ちます。
ステップ 3: スモークテストを 1 本作る（半日）
「ログイン → 主要 1 画面表示 → 1 件登録 → 表示確認」の 一本道の E2E を 1 本だけ用意します。リリース直後にこれを回せば「全部死んでいないか」が 2 分で分かります。
ステップ 4: CI に載せ、PR ゲートにする（半日）
push でテストが自動で回り、落ちたらマージできない設定にします。ここまでで「変更のたびに最低限の安全網が働く」状態になります。
合計でおよそ 2 人日。これだけで、共通関数の変更・境界値・主要フロー破壊という頻発リグレッションの大半に、最初の網がかかります。 あとはバグを直すたびに回帰テストを 1 本ずつ足していけば、網は自動的に密になっていきます。
その後の拡張（カバレッジ可視化、結合テスト追加、E2E の本数増、テスト用データ整備）は、リリース頻度と障害の痛みに応じて段階的に進めます。設計から内製化したい場合は内製開発レディネス診断で、自社のテスト・CI 体制の現在地を確認できます。
リリース前チェックリスト
機能を本番に出す前に、毎回確認する項目です。チームで共有し、PR テンプレートに貼ると形骸化しにくくなります。
- 変更した共通関数を呼んでいる全箇所を確認したか（grep で洗い出し）
- 新規・修正したロジックにユニットテストを足したか
- 境界値（0 件 / 1 件 / 最大 / null / 空）を試したか
- 異常系（外部 API 失敗 / タイムアウト / 不正入力）を試したか
- CI が緑か（テストが全部通っているか）
- API レスポンス・DB カラム・共通定数を変えた場合、使っている全画面を確認したか
- リリース直後にスモークテストを回す段取りがあるか
- ロールバック手順（戻し方）が決まっているか
- 影響範囲を PR の説明に書き、もう 1 人がレビューしたか
特に「共通関数」「API 形式」「DB カラム」を変えた PR は、影響範囲が広いので二重レビューを徹底します。
中堅企業向け 30 分チェックリスト
今すぐ自社の状態を診断する、30 分で終わる確認項目です。「いいえ」が多いほどリグレッション地獄に近い状態です。
| # | 確認項目 | はい / いいえ |
|---|---|---|
| 1 | 自動テストが 1 本でも存在するか | |
| 2 | テストは push のたびに自動実行されるか（CI） | |
| 3 | テストが落ちたらマージできない設定があるか（PR ゲート） | |
| 4 | 金額・在庫・権限など重要関数にテストがあるか | |
| 5 | 境界値（0 / null / 最大）のテストがあるか | |
| 6 | 外部 API 失敗時の異常系テストがあるか | |
| 7 | リリース後に主要画面を確認する手順（スモーク）があるか | |
| 8 | 共通関数の変更時、呼び出し元を洗い出す習慣があるか | |
| 9 | バグを直すとき再発防止テストを足しているか | |
| 10 | リリースを戻すロールバック手順があるか |
結果の見方
- 「はい」7 以上：基礎はできています。カバレッジの薄い経路と E2E の充実を
- 「はい」4〜6：部分的にあるが穴が多い。CI・PR ゲートの整備を最優先に
- 「はい」3 以下：リグレッションがいつ起きてもおかしくない状態。今日から「小さく始める回帰テスト」4 ステップを
who should read / いつ GXO に相談すべきか
この記事を読むべき人
- AI に書かせた業務システム（受注 / 在庫 / 請求 / 顧客管理）をテスト無しで本番運用している中堅企業の経営者・情シス
- 「修正するたびに別のところが壊れる」「リリースが毎回怖い」と感じているチーム
- バイブコーディングで開発スピードは出たが、品質と安心が伴っていないと感じる現場
いつ GXO に相談すべきか（相談トリガ）
以下のいずれかに該当したら、自力で抱え込まず外部の手を入れる段階です。
- リグレッションが月に複数回起きている（直すと別が壊れるが定常化）
- テストも CI も無く、リリースが毎回「祈り」になっている
- 金額・決済・在庫など、間違うと金が飛ぶ処理にテストが無い
- 属人化していて、担当者以外は怖くて触れない（第 14 回の状態）
- テスト・CI・リリースの仕組みを内製で立ち上げたいが、設計の勘所が分からない
GXO は中堅企業向けに、テスト戦略の設計（テストピラミッドの当てはめ）、CI / PR ゲートの構築、AI 生成コードの品質レビュー、回帰テストの優先順位づけ、そしてシステム開発・改善支援からDevSecOps パイプライン整備までを、情シス 1〜3 名の体制に合わせて段階的に支援します。内製化を見据えるなら、まず内製開発レディネス診断で現在地を測ることをおすすめします。
まとめ
本記事の要点を 7 行でまとめます。
- AI 生成コードはテストを書かない／書いても薄い。理由はプロンプト・「動いた」満足・実装なぞり・土台不在の 4 つです
- リグレッション（デグレ）は「1 箇所直すと別が壊れる」現象。原因は目に見えない依存関係です
- Knight Capital 2012（約 4 億 4,000 万ドル）・CrowdStrike 2024 は「変更の検証不足が本番を壊す」公開事例。規模は違えど構造は中堅企業と同じです
- 典型は 4 つ：共通関数の変更 / 暗黙の依存 / 境界値 / 例外系です
- テストピラミッド＝ユニット多め・結合中・E2E 少・スモーク必須。中堅企業は「壊れて困る順に薄く」始めます
- CI 自動実行 + PR ゲート + 重要経路カバレッジで、テストを「腐らせず効かせる」仕組みにします
- **今日から 4 ステップ（約 2 人日）**で頻発リグレッションに最初の網。バグを直すたび回帰テストを 1 本ずつ増やします
「動いた」はリリースの答えにはなりません。**「変更しても壊れていないことを、機械が証明できるか」**が、AI 時代に中堅企業のシステムを守る基準です。
次回（連載第 20 回）は ログとオブザーバビリティの欠如を取り上げ、「障害が起きても何が起きたか分からない」状態をどう脱するかを整理します。
参考一次ソース
本記事の事実認定で参照した一次／公式ソース一覧です。
公開事例（一次資料）
- SEC EDGAR — Knight Capital Group, Inc. Form 8-K (2012)
- CrowdStrike — Channel File 291 Incident Root Cause Analysis
- CISA — Widespread IT Outage Due to CrowdStrike Update (2024-07-19)
テスト・品質の標準的考え方
- Martin Fowler — The Practical Test Pyramid
- Martin Fowler — TestPyramid（bliki）
- Google Testing Blog — Test Sizes
ガイドライン・公的資料
関連記事
- 第 4 回 サービス停止の財務影響（江崎グリコの教訓と BCP 設計）
- 第 11 回 脆弱性スキャン（SAST / DAST / SCA で機械的に検出する）
- 第 14 回 属人化・引き継げないシステムの再生
- 連載ハブ：バイブコーディング危機（全話一覧）
「直すたびに別が壊れる」を、仕組みで止めませんか
テストも CI も無いまま機能を足し続けると、リリースは毎回「祈り」になります。
GXO は中堅企業（年商 30300 億・情シス 13 名）向けに、外部 CTO / セキュリティ顧問、AI 生成コードの脆弱性・品質レビュー、テスト戦略と CI / PR ゲートの整備までを段階的に支援します。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
著者: GXO株式会社 初回公開: 2026 年 6 月 9 日 最終更新: 2026 年 6 月 9 日 連載: バイブコーディング危機 第 19 回（全 20 回予定）