リリースエンジニアおよび iOS リードがアーカイブ、公証、Transporter によるアップロードをシンガポール、日本、韓国、香港、米国東部、米国西部にまたがるリモート Mac に移すとき、失敗の多くは「コード署名の仕方」ではなく公証キュー、キーチェーンの文脈、出口ネットワーク、再試行ポリシーにあります。本稿ではリリース手順書上の摩擦六項目、公証とアップロードをどこで実行するかのマトリクス、オンコールと揃えられる三つの指標、非対話の notarytool 例と Stapler の前提条件、そして六ステップの手順書を示します。Fastlane と証明書同期、再現可能なクリーンビルド、マルチリージョンのレンタルガイドと併読してください。最初の二つは署名の一貫性を守り、本稿はApple の公証サービスと App Store Connect の出口までを閉じます。
Apple の公証経路はツールチェーンの版、利用可能な資格情報、Apple エンドポイントへの TLS の品質に依存します。リモートデスクトップでは画面ロックセッション、プロキシ、企業の出口方針が加わります。CI の再試行ヒストグラムと並べて次の六項目を追跡してください。リージョン役割をまだ固定していない場合は、先にマルチリージョンガイドを読んでください。
notarytool submit が ID を返したあとは info をポーリングする必要があります。高いクロスリージョン RTT のもとで過密なポーリングはレート制限に感じられやすく、遅いポーリングはリリース枠を伸ばします。.pkg、.dmg、アプリバンドルでは手順が異なります。省略すると QA の Gatekeeper 挙動が本番とずれます。この六つをHTTP ステータス分布、再試行回数、同一成果物を別ホストで通した成功率と組み合わせ、「もう一度実行」から出口とパラメータの実際の変更へ置き換えてください。
調達レビューで使う表です。失敗時に誰がデバッグしやすいかとどの列が監査項目に写るかを比較し、生の速度だけで決めないでください。該当する場合はピーク機の項目を予算統制の記事と揃えてください。
| 観点 | 成果物ホームリージョン上のビルドホスト | アップロードと人的ゲート用の専用「リリースノード」 |
|---|---|---|
| ネットワーク経路 | Git／レジストリ取得と公証出口が揃い、大洋横断の二重転送が減る | 短く単目的な経路。Transporter と手動確認に向く |
| 失敗の帰属 | ビルドと公証ログが同一ホスト文脈を共有 | 成果物から上流パイプライン ID への明示的な写像が必要 |
| キーチェーン方針 | CI ユーザーとデーモンモデルに結びつく。長寿命向き | アップロード専用アカウントで露出を減らせる。署名ホストと証明書ビューを混ぜない |
| タイムゾーンと人 | 無人の夜間バッチに強い | オンコール時間と重なるリージョンを優先し、「デスクトップに届かない」ブロックを減らす |
| ディスクと 1TB／2TB | DerivedData、アーカイブ、公証の一時領域を保持。ピーク週向けにサイズ | クリーンアップが厳格なら小さめでも可。方針なしではディスク起因の失敗は依然として多い |
| レンタルの組み合わせ | 月次ベースラインに、リリース周辺の短期ピーク（マルチリージョンガイドどおり） | 短期レンタルでアップロードのスパイクを賄い、長期アイドルコストを抑えられる |
社内ダッシュボードで収集してください。以下の数値は説明用のプレースホルダーであり、チームのベースラインに置き換えてください。
notarytool info ループの代わりに指数バックオフ（例：5 秒→10 秒→20 秒、上限 60 秒）を使い、最大待機をリリース枠に合わせます。クロスリージョン RTT が約 180ms を超えると、サービスが健全でもポーリングがきつすぎるとスロットリングに感じられます。xcrun stapler staple を走らせるボリュームでは、アーカイブサイズの2.5 倍以上の空きを一時領域込みで確保します。足りなければ再現可能ビルドのチェックリストに沿ってキャッシュとアーカイブを整理してから再試行します。2025〜2026 年も Apple は公証とアップロードのツールを Xcode CLI 経路に集約し続けています。xcode-select と notarytool の版を固定せずに Xcode を混在させると、古典的な「CI とデスクトップのドリフト」が再発します。
# Non-interactive notary submit (replace TEAM_ID, secrets, and paths; never commit keys) xcrun notarytool submit ./dist/MyApp.pkg \ --apple-id "[email protected]" \ --password "@keychain:AC_NOTARY_PASSWORD" \ --team-id "XXXXXXXXXX" \ --wait # App Store Connect API key profile (preferred alignment with Fastlane issuer) # xcrun notarytool store-credentials --keychain "notary-profile" ... # xcrun notarytool submit ./dist/MyApp.pkg --keychain-profile "notary-profile" --wait
ヒント：リモートデスクトップではキーチェーンプロファイルや CI から注入する読み取り専用の鍵パスを優先し、シェル履歴に平文パスワードを残さないでください。ローテーションの周期は Fastlane の記事と揃えます。
署名とアーカイブがすでに成功している前提です。そうでなければ先に Fastlane と再現可能ビルドの記事に戻ってください。
xcode-select -p と xcrun notarytool --version をリリースチケットに記録し、リリース当日の不意の切り替えを防ぎます。stapler staple を実行し、spctl でスポットチェックします。コマンドのハッシュをチケットに残します。テレメトリに公証ログのダウンロードが遅い、一時ディレクトリが不安定、ローカルノート PC の方が速いといった兆候があるとき、CPU を足しても端到端は短くなりにくいです。マルチプロジェクトのプール記事の DSM とキャッシュ戦略に戻り、M4 Pro へ飛びつく前に同一リージョンの成果物パス、十分なディスク余裕、安定した出口を優先してください。リモート Mac の意味は、この連鎖を契約上のリージョンとレンタル条件に落とせることにあり、ノート PC の一対一の置き換えではありません。
個人ノートに公証とアップロードを頼ると、コンプライアンスレビュー、引き継ぎ、24 時間体制のリリース枠のもとで見えないコストが出ます。鍵は個人のキーチェーンにあり、出口は場所で変わり、失敗は CI チケットにきれいに写りません。公証とアップロードをリージョン戦略に沿ったリモート Mac プールへ移すと、出口、ディスク、レンタル条件が監査可能になり、同じリージョンの OpenClaw Gateway のような長寿命自動化とも組み合わせやすくなります。
汎用クラウドデスクトップや短命 VM でも CLI は動きますが、グラフィカルセッション、USB、キーチェーンの意味論が崩れ、リリース週に調整コストがかさみます。MACCOME はMac mini M4 および M4 Pro の物理ノードをシンガポール、日本、韓国、香港、米国沿岸で提供し、専用ビルド、公証、アップロード出口に合わせた柔軟なレンタル条件を用意しています。まず公開料金ページをマトリクスの行と揃え、そのうえで NPI、URW、DSM をダッシュボードに接続してください。
パイロットでは二週間は署名を固定し、成果物ホームのリモート Mac 一台だけで出口と再試行パラメータを変えてください。多くの「謎の失敗」は、説明可能な少数のクラスに収まります。
FAQ
公証は Fastlane と証明書の記事の前と後、どちらで実行すべきですか？
まず署名とプロファイルを安定させ、その後に公証とアップロードを行います。Fastlane と証明書同期の記事をレンタル料金と並べて開き、リージョンと契約期間を一行に揃えてください。
リージョンと出口はどう選びますか？
マルチリージョンのレンタルガイドを読み、ビルド・公証・アップロードが同一ホストを共有するかをレビュー資料に記録してください。
請求とアクセスの説明はどこにありますか？
ヘルプセンターでオンボーディングと代表的な請求上の注意をご確認ください。