これは何か
自動テスト・自動配布構成は、プログラムの変更が合流したときに、どのテストが自動で動き、合格したものがどの環境へ自動で配られ、どこで人の確認や承認を挟むかを、段階ごとに決めた成果物です。
自動テストは、人が毎回手で確かめなくても、決めた確認をプログラムが代わりに行う仕組みです。自動配布は、合格した版をテスト環境や本番へ、決めた手順どおりに置く仕組みです。この 2 つをつなげた流れ（パイプライン）が、09-04 自動テストと自動配布 で学ぶ「人の手を介さずに、同じ手順で、何度でも」を実現します。
なぜ作るか
- 変更のたびに同じ確認を同じ順で行い、人による抜けをなくす
- 問題を早く見つける（合流の直後に分かれば、直すのは簡単）
- テスト環境・本番への配布を手順書と人の操作に頼らず、記録が自動で残る形にする
- どこまで自動で進み、どこから人の承認が要るかを、はっきり分ける（本番への配布は人が決める）
誰が使うか・いつ作るか
- 作る人：開発・CI/CD 基盤を担当する会社と、開発の取りまとめ役。テストの担当が確認の段階を決める
- 使う人：すべての開発者、テストの担当、リリースを決める人、運用の担当
- 一般的には、開発が本格的に始まる前に最初の形を作り、テストの段階が増えるたびに育てます
- アステリア案件のテストの段階、自動化の範囲、配布の承認の仕組みは、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
自動化に関係する記載
- システムに SYS-09 開発・CI/CD基盤、SYS-10 AI開発エージェント、SYS-11 監視・ログ基盤がある
- Vendor B クラウドブリッジの担当範囲に CI/CD、監視が含まれる
- 約120人規模のプロジェクト、マルチベンダー、AI活用あり
- 本番移行承認、Go / No-Go は、AIへ最終委任しない事項
アステリア案件で、どのテストを自動化し、どの環境へ自動で配り、誰が本番への配布を承認したかは、正本に記載がありません。未確定
主な項目
一般的には、次の項目で構成します。
- 流れの全体図：合流 → 自動テスト（段階別） → テスト環境へ配布 → 追加のテスト → 本番への配布（人の承認）という段階と、各段階の入口・出口
- テストの段階と範囲：部品ごとのテスト、つなげたテスト、画面を通したテスト、性能のテスト、安全のチェック（脆弱性・秘密情報の混入）。どれを毎回動かし、どれを夜間や週次にするか（10-02 小さい単位から全体へテストする）
- 合格の基準：段階ごとに「次へ進んでよい」条件（テストの合格、カバレッジの下限、重大な指摘ゼロ）
- 配布先と環境：どの枝の合格版がどの環境へ行くか（DEV-004 環境・リリース対応表、09-03 開発・テスト・本番をなぜ分けるのか）
- 人の承認を挟む場所：本番への配布、データを変える処理、業務に影響する設定の変更
- 失敗したときの扱い：止める、通知する、誰が見るか。失敗したまま次へ進ませない
- 記録：いつ、どの版が、どのテストに合格し、誰の承認でどこへ配られたか
- AI が作った変更の扱い：同じ流れを通す。AI の「テストに合格した」という報告ではなく、流れの記録で確かめる（AI-003 AI変更実行記録）
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 段階ごとの確認と配布先
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、構成の書き方を学ぶための例です。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 段階（教材上の例） | いつ動くか | 何を確かめるか | 次へ進む条件 | 失敗したら |
|---|---|---|---|---|
| 1 合流前 | 合流の申請ごと | 書式のチェック、部品ごとのテスト、秘密情報の混入チェック | すべて合格 | 合流できない。申請者に通知 |
| 2 合流後 | 本線に入るごと | つなげたテスト、主要な画面のテスト | 合格、重大な指摘ゼロ | 本線を「赤」にし、当番が 1 時間以内に見る |
| 3 テスト環境 | 1 日 1 回 | 業務の流れを通したテスト、連携の模擬テスト | 合格率の基準を満たす | 翌日の配布を止める |
| 4 性能・安全 | 週 1 回と、リリース前 | 負荷をかけた応答、脆弱性のチェック | 性能の目標内、重大な脆弱性ゼロ | リリース候補から外す |
| 5 本番 | リリースのたび | 配布の手順の自動実行と、配布後の動作確認 | 人の承認（リリースを決める人） | 自動で前の版に戻す手順を実行 |
| 配布先（教材上の例） | 元になる枝 | 自動か人か | 承認者 |
|---|---|---|---|
| 開発環境 | 作業用の枝 | 自動 | なし |
| 結合テスト環境 | 本線 | 自動（段階 2 合格後） | なし |
| 受入テスト環境 | リリース用の枝 | 自動（段階 3・4 合格後） | テストの責任者 |
| 本番 | リリース用の枝のタグ | 人の承認後に自動 | 本番移行の承認者 |
読み方
- 段階ごとに「何を確かめ、何を満たせば次へ進むか」が書かれているか
- 本番への配布に人の承認が置かれているか。自動で本番まで行く経路がないか
- 失敗したときの扱い（止める、誰が見る、いつまでに）が書かれているか
- 性能や安全の確認が「リリース前だけ」になっていないか（遅く見つかるほど直しにくい）
- AI が作った変更が、同じ流れを通る前提になっているか
書き方
- 流れの全体図を先に描き、段階の入口と出口を決める
- 段階ごとに、確かめること・合格の基準・失敗時の扱いを表にする
- 配布先と承認者を、環境・リリース対応表と合わせる
- 最初は小さく（段階 1〜2）始め、テストが増えるたびに段階を育てる
- 流れが止まったときの連絡先と、当番の決め方を運用の担当と決める
何を書いてはいけないか
- 「十分にテストしてから配布する」のような、基準のない決まり
- 本番の秘密情報を流れの設定に直接書くこと
- 失敗しても次へ進める「とりあえず通す」設定（赤が当たり前になり、誰も見なくなる）
- 実在の製品名を、案件の正式な採用として書くこと（正本に記載がない）
どこを見るか
- 段階ごとの確認と、次へ進む条件
- 本番への配布の承認者
- 失敗したときの扱いと見る人
- 性能・安全の確認がいつ動くか
- 記録（どの版が、何に合格し、誰の承認でどこへ）
赤信号
- 本線が長い間「赤」のままで、誰も直していない
- テストを飛ばして配布する「緊急用」の経路が日常的に使われている
- 本番への配布が自動で行われ、誰が承認したかの記録がない
- 流れの設定を変更できる人が多く、変更の記録がない
よくある失敗
- テストの時間が長くなりすぎ、開発者が流れを待たずに合流を重ね、失敗の原因が分からなくなる（段階を分けて、毎回動かすものを絞る）
- 性能や安全の確認をリリース直前にまとめて行い、問題が見つかっても直す時間がない
- AI の「すべてのテストに合格しました」という報告を信じ、流れの記録を見ない
関係するUnit・成果物・危機演習
- Unit：09-04 自動テストと自動配布、10-02 小さい単位から全体へテストする、09-03 開発・テスト・本番をなぜ分けるのか、09-05 AIにコードを書かせる場合の基本
- 成果物：DEV-001 Git・ブランチ運用方針、DEV-004 環境・リリース対応表、TST-001 テスト戦略書、AI-003 AI変更実行記録
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、流れの記録から、段階を飛ばした配布や、失敗したまま進んだ配布を探す下書きに役立ちます。
「次の配布の記録一覧を読み、配布ごとに『通った段階』『合格の記録の有無』『承認者の有無』を表にしてください。欠けている項目は空欄のまま示し、理由を推測しないでください。」
REVIEW
- AIが「合格」と読み取った根拠が、元の記録にあるか
- 流れの記録を AI に渡してよいか（プログラムや設定の扱い）を事前に確かめたか
- 段階を飛ばした配布が見つかったとき、了解された例外かどうかを人が確かめたか
人間が判断すること
- どのテストを毎回動かし、どれを週次にするか
- 合格の基準をどこに置くか
- 本番へ配布してよいか
本番移行承認と Go / No-Go は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 09｜120人で安全に開発する の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この構成を読んだ開発者は、「自分の変更を合流させたあと、何が自動で確かめられ、どこまで自動で配られ、どこから人の承認が要るか」を説明できますか？