【セッションレポート】テスト自動化環境の運用で見えた課題と、再設計による解決事例 ～テスト回数、端末台数、テスト内容、プラットフォームのスケールアップ事例～ #CEDEC2026
はじめに
CEDEC2026 で聴講したセッションのレポートです。長期運営中の Unity 製対戦アクションゲームを対象に、テスト自動化環境を運用しながら段階的に拡張してきた事例が、株式会社セガの開発者から紹介されました。
セッションの概要は次の通りです。
- タイトル: テスト自動化環境の運用で見えた課題と、再設計による解決事例 ～テスト回数、端末台数、テスト内容、プラットフォームのスケールアップ事例～
- 登壇者: 里中 美耶 氏、廣島 岳史 氏 (いずれも株式会社セガ 技術本部 開発技術部 技術開発セクション)
- 日時: 2026 年 7 月 24 日 11:10 から 12:10
- 会場: 第 8 会場
本セッションは、環境構築を扱った CEDEC 2023 の発表の続編にあたり、運用の中で顕在化した課題とその解決に焦点を当てたものです。
旧環境の課題と再設計の方針
対象のゲームは、複数のルールを持つ通信対戦アクションゲームです。端末同士をマッチングさせる E2E テストを、自社製フレームワーク ATC で動かしています。テスト自動化環境を開発・運用する ATC チームと、ゲーム本体を開発するタイトルチームは、独立したフローで並行して開発を進めています。
ここには制約がありました。CI 環境の Jenkins や共有ストレージはタイトルチームと共有しており、ATC チーム側から環境を更新したり機能を追加したりできません。旧環境は Jenkins 上に構築されていましたが、パイプラインが複雑に肥大化し、更新のたびにテスト全体を停止する必要がある、デバッグしにくいといった問題を抱えていました。
そこで、責務を分離する方針で再設計されました。CI である Jenkins は起動のトリガーに役割を絞り、実行制御や状態管理、成果物管理、通知といった処理を CI の外へ切り出すという考え方です。
内製パイプラインツール AutomagicPipeline
CI の外で実行制御を担うために作られたのが、内製ツールの AutomagicPipeline (AmPl) です。C# と .NET8 で書かれた Windows 向けのコンソールアプリケーションで、テスト自動化の各処理をまとめて制御します。
AmPl は、単一の責務を持つジョブと、それらを組み合わせたパイプラインで構成されます。ジョブは失敗時のリトライなどを個別に設定でき、パイプラインはジョブを直列や並列に組み合わせて定義します。挙動は設定ファイルで切り替えられ、ブランチや Unity バージョンなどをパラメータとして渡せます。これにより、CI の外側で実行の流れを柔軟に変更・検証できるようになりました。
再設計後は、1 つのテストに必要な処理を、ビルド、テスト実行、結果集約の 3 つのパイプラインに分割しています。全体は Jenkins、AmPl、ゲームサーバ、ログ基盤の Elasticsearch と Kibana、録画に使う OBS Studio などで構成されます。
4 つのスケールアップ
後半では、運用しながら環境をスケールさせた 4 つの事例が紹介されました。
1 つ目はテスト実行回数です。テスト専用のゲームサーバを用意し、その更新も AmPl で行うことで、タイトルチームの手を借りずにテストを回せるようにしました。
2 つ目は端末台数です。各端末のログを集約する仕組みを整え、全端末の結果を毎朝まとめてチャットツールへ通知します。あわせて、増え続ける録画などの成果物に対して、一定期間で削除するライフサイクル管理を導入しました。
3 つ目はテスト内容です。2 台の端末をマッチングさせるために、共有ストレージ上のフラグファイルで両端末のゲーム起動タイミングを同期する仕組みを実装しました。
4 つ目はプラットフォームです。iOS では Appium と WebDriverAgent で実機を操作し、画面と音声は Mac 上の OBS Studio でミラーリングします。今後は映像と音声を IP ネットワークで送る AVoIP の活用も検討しているとのことです。Android では adb と scrcpy を用いる構成が示されました。
感想
同じ CI や環境を共有し、勝手に変更できないという現実的な制約の中で、責務を切り出して内製ツールに寄せていく進め方が具体的で、示唆に富む発表でした。長期運営タイトルでは、テスト自動化そのものより、それを止めずに育てていく運用の設計こそが難しいのだと感じました。
