2026 GitHub Actionsの並列テストでメールが混線したら？

まず「送信」「到着」「読み取り」を切り分ける

失敗のたびにGitHub Actionsの不具合と決めつけるのではなく、どの段階で食い違ったかを確かめます。実行順を変えると結果が変わる、別のテストの認証コードが返る、再実行すると通る、といった症状は共有状態の干渉を疑う手掛かりです。ただし、それだけで原因が確定するわけではありません。

問題の切り分けでは、テスト結果だけでなく、実行識別子、検索条件、見つかったメールの宛先も照合します。本文に実在する利用者情報を記録する必要はありません。テストデータに個人情報を混ぜない設計は、メールアドレスのプライバシーと露出リスクを確認する際にも役立ちます。

共有受信箱では「届いたメール」と「今回のメール」が同じとは限らない

GitHub Actionsは、同時実行を明示的に制限していないワークフローやジョブが並行して動く構成を許容します。マトリックスでは複数の組み合わせを実行できるため、各ジョブが登録メールを送ると、共有受信箱へほぼ同時に複数のメッセージが届く設計になり得ます。GitHub Actionsのマトリックス実行と並行実行の仕様を踏まえ、受信状態はテスト側で分けてください。

たとえば、複数タスクが同じ箱をポーリングし、「新着の先頭」や「認証コードを含む最初のメール」をそのまま採用すると、先に届いた別タスク宛てのメッセージを読む可能性があります。これは共有状態を扱う実装で起こり得る問題であり、メールサービスやGitHub Actionsに共通する欠陥だと断定するものではありません。

第一歩：並列実行の単位に合わせて受信先を分ける

隔離の粒度は、同時にメールを送受信する単位に合わせます。ジョブごとに独立して登録操作を行うならジョブ単位、ジョブ内で複数テストを並行させるならそのテスト単位で区別できる宛先を割り当てます。受信箱を分けられない場合は、宛先だけでなくメールに付ける識別マークも併用します。

• [ ] どのジョブ・テストが登録や再設定メールを送るかを一覧にします。
• [ ] 同時に実行される単位ごとに、区別できる受信先を割り当てます。
• [ ] 受信先を分けられないときは、今回の実行を示す識別マークをテストデータに付けます。
• [ ] メール検索で宛先と識別マークを両方確認し、条件に合わないメッセージは採用しません。
• [ ] 待機には終了条件を設定し、失敗時は実行識別子、検索条件、照合結果を出力します。
• [ ] ログや成果物に認証コードや個人情報を不用意に残さないよう、マスキングを確認します。

この設計では、受信先の分離が最も直接的な対策です。別名アドレスなどで受信先を区別する方式もありますが、サービスごとに受け付け方や受信の扱いが異なるため、自社製品のテスト環境で期待どおり識別できるかを先に確認してください。方式の違いは一時アドレスとメール別名の比較も参考になります。

第二歩：今回の実行を示す印でメールを照合する

受信先を使い回す場合でも、テストが作るデータに実行固有の印を含めると、対象メッセージを特定しやすくなります。GitHub Actionsのコンテキストには実行や再実行を区別する情報があり、マトリックスの値と組み合わせて識別子を作れます。コンテキストの参照資料で使用可能な値を確認し、テストコード側で宛先や対象データへ反映します。

env:
  TEST_RUN_MARKER: "${{ github.run_id }}-${{ github.run_attempt }}-${{ matrix.case }}"

この値はテスト対象のアカウントやメール本文に含める識別用データとして扱います。受信処理では、宛先、件名または本文の識別マーク、必要なリンクや認証コードが今回の操作と一致することを確認してください。認証コードだけが一致しても、宛先やアカウントが異なれば成功扱いにしないことが重要です。

第三歩：待機切れを「混線」と混同しない

メールが見つからない失敗は、ただちに串号とは限りません。製品側が送信処理を行っていない、メールがまだ到着していない、検索条件が実際の件名や宛先と合っていない、といった可能性があります。待機処理には明確な終了条件を設け、終了時に「メールなし」「条件不一致」「別の実行マークを検出」のどれだったかを記録します。

同じ受信箱から今回と別の識別マークを持つメールが見つかった場合は、他のタスクによる読み取りやフィルターの誤りを調べます。何も見つからない場合は、製品の送信ログとメール側の受信状態を照合します。到着時間や再試行回数を根拠なく固定せず、テスト環境で観測できる挙動に応じて待機条件を設計してください。

concurrencyは共有資源の制御に使い、受信箱の分離と混同しない

GitHub Actionsのconcurrencyは、同じグループに属するワークフローやジョブの実行を調整する仕組みです。設定によっては進行中の実行をキャンセルでき、保留中の実行の扱いにもルールがあります。グループの動作とキャンセル条件を公式の並行制御ガイドで確かめてから適用してください。

ただし、並行制御を設定しても、メールアドレスや受信箱がテストごとに割り当てられるわけではありません。共有データベースなど、同時操作が実際に衝突する資源だけを対象にし、メールの誤読には受信先分離とメッセージ照合を優先します。失敗を避けるためだけに広い範囲を制限し、必要なテストまでキャンセルしないよう、対象グループを絞ります。

失敗時の調査資料を残す場合は、実行識別子やマスキング済みの判定結果に限定します。GitHub Actionsのワークフロー成果物の仕様を確認し、認証コードや実在するメールアドレスを成果物へ保存しない運用にしてください。

方式ごとの向き不向き

適合度はメール到着の実測値ではなく、混線を防ぐ設計としての使いやすさを示しています。まず受信先を分け、分離できない箇所だけ識別マークで補い、concurrencyは本当に共有資源が衝突する範囲に限るのが基本です。

よくある確認事項

同時実行で別テストの認証コードを読むのはなぜですか

共有受信箱を複数タスクが検索し、検索条件を宛先や実行識別子で絞り込んでいないと、別のテスト宛てのメールを取得する可能性があります。各タスクの受信先と実行マークを照合し、再現時にどのメールが選ばれたかを記録してください。

CIのメールテストでは毎回別の受信先にするべきですか

複数タスクが同じ受信箱を読む構成なら、並行実行単位ごとに区別できる受信先を用意するのが安全です。受信箱を分けられない場合は、宛先だけに頼らず、メールに埋め込んだ実行識別子と対象アカウントを合わせて検証します。

concurrencyだけでメールの取り違えをなくせますか

concurrencyはワークフローやジョブの実行を制御しますが、受信箱を自動で分ける機能ではありません。共有資源を守るために範囲を絞って使い、メールの特定には宛先分離や識別マークを別途組み合わせます。

メールが届かずテストが落ちた場合、遅延と混線をどう区別しますか

終了条件に達した時点でメールが存在しないなら、送信処理、到着状態、検索条件を順に確認します。別の実行マークを持つメールが見つかるなら、共有受信箱の読み取りやフィルターを調べます。結果には実行識別子と判定理由を残し、個人情報は記録しません。

自社製品が実際に送ったメールを手作業で確認する段階なら、テスト用の一時受信先も選択肢になります。VoidFwdは登録なしですぐ使える一時メールの確認先として利用でき、主メールアドレスをテスト用サービスへ渡さずに済みます。ただし、CIの並行制御や製品側の送信不具合を解決するものではありません。用途に合う場合はVoidFwdの一時受信で、実メールの目視確認から試せます。

よくある質問

並列実行中に別のテストの認証コードを取得するのはなぜですか？

同じ受信箱を複数のテストが同時に確認し、宛先や件名などの条件を十分に絞らず最初に見つかったメールを使うと、別タスク宛てのメッセージを拾う可能性があります。実行ごとの受信先と識別マークを設け、メールの宛先、本文のマーク、操作対象を合わせて照合してください。

CIのメールテストではタスクごとに別の受信先が必要ですか？

同じ受信箱を並行タスクが読み取る構成なら、タスクまたは実行ごとに区別できる受信先を使うのが安全です。受信箱を分けられない場合は、受信先に加えて実行識別子をメールとテスト結果に持たせ、対象メッセージを厳密に絞り込みます。

GitHub Actionsのconcurrency設定だけでメールの混線を防げますか？

防げません。concurrencyは指定したグループ内のワークフローやジョブの実行を調整しますが、受信箱やメールをテストごとに分ける機能ではありません。共有資源を守る目的で使い、メールの分離と照合はテスト側で別に設計してください。

メールテストの失敗が遅延か混線かをどう見分けますか？

待機処理が終了した時点で対象メールが存在しないなら、遅延や送信側の問題を確認します。メール自体は届いているのに宛先、実行識別子、認証コードが今回のテストと合わない場合は、フィルター条件の誤りや共有受信箱からの誤読を疑います。ログには実行識別子と照合結果を残します。