自動ビルド・リリースパイプライン（fastlane + CI の最小導入）

2026/9/17

背景与問題

OPC（B 方向）。リリース作業が手動（ビルド→証明書→アップロード→申請）で、証明書切れや手順ミスのたびに時間を溶かす。solo の標準解である fastlane + CI の最小構成を、導入の引き金つきで設計する。

（出典はいずれも 2026-09-17 アクセス）

fastlane はモバイルのビルド〜リリース自動化の事実上の標準（オープンソース、Android/iOS 両対応）——solo が全部を手でやっている部分を置き換える定番（fastlane.tools）。
構成の定石：fastlane の「lane」で自動化ステップを束ね、GitHub Actions / GitLab CI と組む（Runway の Android 手順、Mad Devs の GitLab 手順）。
証明書管理は match に寄せて手元依存を消すのが定石（GitLab 手順の構成）。
ベータ配布は Firebase App Distribution + fastlane + CI の公式ベストプラクティスがある（Firebase 公式）。
store スクリーンショットの自動生成も pipeline に組める（Mad Devs 手順に含まれる）——c-localization-transcreation のスクショ手直し工数に直結。
推测：solo の手動リリースは「年に数回しかやらない」ため、毎回手順を忘れる。自動化の価値は時短より手順の記憶不要化。

最小構成は 1 lane：タグ push → ビルド → store 提出（fastlane + GitHub Actions）。証明書は match 管理。ここから拡張する。
ベータ配布は Firebase App Distribution を第一候補に（公式ベストプラクティスあり）——japan-testflight-vs-play-testing の両ストア運用と並走させて複雑さを増やさない。
スクショ自動生成を第 2 段で追加：言語追加時のスクショ再生成（transcreation 課題のセットタスク）を pipeline に載せる。
導入の引き金：手動リリースでの失敗（証明書切れ・手順ミス）が年 1 回起きたら導入。起きていないなら手動継続でもよい——自動化は目的でなく手段（推测：失敗頻度が薄い solo では CI 運用自体の維持が逆に負担になり得る）。