2026年 越境 Apple デリバリー：notarytool 公証アップロードのタイムアウトと尾部遅延を、マルチリージョン物理 Mac ノード選定でどう安定化するか（閾値マトリクス・実行パラメータ・FAQ）
複数国にまたがるリリース／プラットフォーム組織では、notarytool のアップロードが途中で止まり、Accepted 直前で CI が落ちる、「ランダム」に見える長尾が実は地理と経路由来、という現象が起きがちです。本稿では誰がどんな痛みを抱えるかを明示し、症状ルーティング用とリージョンプール選定用の 2 つの閾値マトリクス、コピペ可能な notarytool／stapler、7 ステップの展開、引用用の時間目安、FAQ をまとめ、単一の混線ホップではなくリージョン別の物理 Mac プールへ標準化する手順を示します。
読了の目安 約 14 分
1. 痛みの分解：notarytool はバイナリだけでなく「経路」に敏感
- Apple 向け経路が悪い単一リージョンの Mac。 小さな Git 操作は通っても、数百 MB 級の公証アップロードが越境区間の損失やバッファブロートで何時間も再試行に見えることがあります。
- 公証 P99 より短い CI タイムアウト。 コンパイル基準でジョブ時間を決め、
--waitのキュー待ちとスキャン時間を忘れ、尾部が週次 SLO 違反の主因になります。 - 不安定な再試行の隠れコスト。 再提出のたびに submission ID が増え、ダッシュボードが散らかり、「幽霊失敗」として人が溶けるが実態はネットワークポリシー、というパターンです。
- プロキシと検査ポリシー。 ブラウザでは動く企業 TLS ミドルボックスが、長寿命の CLI アップロードでは壊れることがあり、Apple エンドポイントの許可はファイアウォール 1 枚ではなく監査とセキュリティの話になります。
マルチリージョンのガバナンスと CapEx／OpEx が Mac プールにどう交差するかは、 2026年 越境 Apple チーム：Mac mini 購入かマルチリージョンレンタルか（3 年 TCO マトリクス） を参照してください。TLS と損失の測り方の土台は マルチリージョン物理 Mac 受入：RTT／ジッター／損失 SLO と合わせると、公証ジョブのルーティング根拠が一本化されます。
2. 症状 → 想定原因 → 初動のマトリクス
インシデントレビューで使う表です。「今日は Apple が遅かった」ではなく、測定可能な信号に議論を固定します。
| 症状 | 想定原因 | 初動 |
|---|---|---|
| アップロードで進捗が止まり CPU はアイドル | RTT 尾部、損失、プロキシのバッファリング | 最寄りのクリーンなリージョンにラベル付き Mac から再実行し、TLS 接続時間を採取（セクション 4）。 |
| 即時の認証エラー | アプリ用パスワード誤り、Team ID 違い、キーチェーン項目の期限切れ | クレデンシャルを修正。ネットワークと混同しないよう notarytool history で確認。 |
| ログは Accepted だがユーザーに Gatekeeper 警告 | stapler 未実行または別バンドル | 返却／ビルドした成果物そのものに staple；stapler validate で確認。 |
| ツールから断続的な HTTP 5xx | Apple 側または中間経路の混雑 | 指数バックオフ（セクション 6）。同一ビルド ID の無思考な並列再提出は避ける。 |
3. マルチリージョン物理 Mac プールの意思決定マトリクス
Runner に notary:eu や notary:us-west のようにラベルを付け、PM の所在地ではなくその Mac から測った TLS 実測 でジョブを振り分けます。
| 候補 Mac からの測定 | プール判断 | メモ |
|---|---|---|
| Apple ホストへの TLS 接続中央値 ≤ 80 ms、損失 < 0.3% | 主系 notary プール | 既定リリースと夜間署名ビルドをここに載せる。 |
| P95 TLS 接続 80〜200 ms で安定 | 副系／DR プール | オーバーフロー用。主系比で CI タイムアウトを +10〜20 分広げる。 |
| P95 > 200 ms または損失 > 1% | notary ラベルを付けない | コンパイル専用にするかリージョン中継 Mac 経由に変更。キャリア変更後に再測定。 |
エンドツーエンドの iOS デリバリーでも本質は同じで、署名済みアーカイブがネットワーク上どこから出ていくかです。プールラベルは組織図のリージョンではなくアップロード経路に従わせます。
4. 実行可能な notarytool／stapler パラメータ
プレースホルダを置き換えてください。シークレットはキーチェーンに置き、可能なら @keychain: で参照します。Xcode CLT 導入済みを前提とします。
4.1 公証を実行する Mac からの TLS タイミング基線
# ピーク帯でも繰り返し実行し、メトリクスに記録
for i in $(seq 1 60); do
curl -o /dev/null -s -w "%{time_connect} %{time_appconnect} %{time_total}\n" \
"https://developer.apple.com/"
sleep 2
done | tee /tmp/apple-tls-mac.txt
4.2 提出して終端状態までブロック
xcrun notarytool submit ./Release/MyApp.zip \ --apple-id "[email protected]" \ --password "@keychain:AC_NOTARY_PASSWORD" \ --team-id "ABCDE12345" \ --wait \ --verbose
フラグ： --wait は Accepted／Rejected までプロセスを開けたままにします。--verbose は HTTP 層の再試行をログ相関用に出します。
4.3 ブロックしない提出（オーケストレータ向け）
xcrun notarytool submit ./Release/MyApp.zip \ --apple-id "[email protected]" \ --password "@keychain:AC_NOTARY_PASSWORD" \ --team-id "ABCDE12345" \ --verbose # 標準出力から submission id を取得してから: xcrun notarytool log <submission-id> \ --apple-id "[email protected]" \ --password "@keychain:AC_NOTARY_PASSWORD" \ --team-id "ABCDE12345"
4.4 staple と検証
xcrun stapler staple "./build/MyApp.app" xcrun stapler validate "./build/MyApp.app"
リモート Mac mini 上でのビルドから配布までの流れは、別稿「リモート Mac mini での iOS ビルドと配布」で手順を追えます。
5. 7 ステップの展開
- 候補 Mac すべてに計装：セクション 4.1 の TLS ループを営業週 1 週間回し、P50／P95 接続時間を保存。
- Runner ラベルを作成：リージョン＋役割をエンコード（
notary-primary-eu）。リリースにmacos-latestだけは使わない。 - notary スクリプトを 1 本に標準化：提出、submission id の成果物化、staple、validate をリポジトリ管理。
- CI タイムアウト：計測した公証ステップ P99 の 125% 程度にハードキル。警告閾値で事前アラート。
- 再試行ポリシー：輸送クラスの失敗に限定（セクション 6）、ビルド ID で重複排除。
- プロキシ規則を文書化：セキュリティと共有。検査をバイパスする Apple ホスト名とパケットキャプチャ証跡。
- 四半期ごとの再ベースライン：キャリアやオフィス SD-WAN 変更後。中央値が 20% 以上ズレたら主系プールを入れ替え。
6. 引用用の閾値（SLO 草案の出発点）
--wait込みの壁時計： 典型的なアプリアーカイブで混雑帯は 25〜50 分 をバジェットの出発点に。巨大バイナリは自前ヒストグラムを引く。- CI ジョブタイムアウト： コンパイル単体ではなく、観測した公証ステップの P99 + 30〜45 分 をハードキルに。
- 輸送エラーのバックオフ： 3 回、間隔 5／15／45 分 でオンページまで。同一成果物の盲目的な並列 submit は禁止。
7. FAQ
notarytool は必須ですか？
新規の自動化ではその前提でよいです。従来の altool は非推奨です。notarytool submit|log|history と stapler を同一スクリプトにまとめてください。
Linux や Windows から公証できますか？
Apple 公式 CLI では不可です。notarytool／stapler には macOS が必要で、このステップを載せるためにリージョン別の物理 Mac プールが存在します。
Mac のリージョンをまたぐと Apple ID 規約に触れますか？
組織の Apple Developer Program 契約とアカウントセキュリティポリシーに従ってください。運用上はマネージドキーチェーン、アプリ用パスワードのローテ、提出可能なマシンの監査が効きます。
健全なプールが 1 リージョンだけのときは？
一時的に全公証をそこへ寄せ、同時実行上限だけ慎重に上げ、悪いリージョンはキャリア／ISP チケットを切る。セクション 3 のマトリクスでどの経路が緑かは既に見えているはずです。
8. 公証パイプラインに Mac mini 級ハードが向く理由
公証そのものは長時間 CPU フルではありませんが、安定した TLS セッション、信頼できるキーチェーンアクセス、macOS ネイティブのツールチェーンへの依存が強いです。Apple Silicon の Mac mini は署名まわりのシングルスレッド性能、Xcode 級ワークロード向けのユニファイドメモリ、数ワット級に抑えやすい待機電力を兼ね備え、常時稼働のリージョン Runner に向きます。
macOS は Gatekeeper、SIP、FileVault を積み上げ、クレデンシャルでデベロッパプログラムに代わってソフトウェアを提出する文脈では、野良 VM より改ざんリスクを下げやすいです。
マルチリージョンの物理ノードで公証の尾部だけを削りたいなら、同一 OS ビルドと予測しやすいネットワークを揃えた Mac mini 級フリートが、後から iOS コンパイルクラスタへ拡張するときも摩擦が少ない選択肢です。
24/7 の CI 負荷でも熱と騒音を抑えたハードでこのパイプラインを回したいなら、Mac mini M4 は各リージョンの notary プールを押さえるコスト効率の高い起点のひとつです。上記マトリクスと組み合わせ、最も健全なリージョンを主系に昇格させてください。
リージョンごとに公証用の物理 Mac が必要ですか？
チームの近くに専用 macOS ホストを置き、notarytool のアップロードをクリーンな TLS 経路に乗せられます。各国で機材を買い切る前に検証できます。