01決定行列：M4メモリ、SSD、並列Transport
予算フリート向け目安であり公式保証ではありません。
| プロファイル | 16対24GB | 256対512GB | 並列しきい値 |
|---|---|---|---|
| 単夜間TF | 16GB単一Transport | 週次掃除で256GB可 | 一本推奨 |
| 二本線CI | 索引重複なら24GB | 常時逼迫なら512GB | 16GBは二本で分割 |
| OpenClaw同居 | 常駐分4GB相当を先取り | 最大ipa後も空き40GB前後 | 冷起動時BG一本 |
常時14GB超が残るなら24GBへ。ディスク約七割超で並列停止しログ回収後に再開します。
02三つの制約
- 深層ログ：原因行が末尾から遠く、再試行だけではリースを浪費します。
- トークン散逸：プロファイル直書きは監査に不利です。
- ジッター：夕方帯のRTT跳ねでTLSが切れやすく、ワーカーとスライス長を揃えます。
03七段チェックリスト（米西海岸）
1 SSHでApple系解決とApp Store Connect向け基準RTTを記録。
2 curlでOpenClaw導入、npmロック固定、ゲートウェイ疎通後にスキル接続。
3 APIキーは短命環境注入、IssuerとVendorはリポ外、sudo拒否。
4 Transporter／iTMSTransporterログをローテtailしITMS／ERRORでgrep、失敗コードごと末尾約二百行を切り出し。
5 失敗時WebhookへJSONでバンドルID・ビルド・終了コード・再試行・スライス参照をPOST。
6 成功も同スキーマ要約し経理側が版把握できるようにする。
7 再試行前にipaチェックサムを照合し破損部分が良品を上書きしないよう制御。
セキュリティ：共有NFSに鍵を置かず単一ワークスペースに閉じ、一時間以内に認証失敗Webhookが二度ならキーローテ。
04OpenClawでログと再試行要約
読み取り主体でログdirと狭いPOSTのみ許可し、失敗を五箇条＋ITMSコードへ圧縮。メタデータのみ配信も同JSON形へ流し込みます。部分アップロード時は三十〜百二十秒の指数バックオフにジッターを混ぜ、mutexで二エージェントの同時再起動を防ぎます。
約200行
ログスライス上限目安
2本
16GB並列Transport上限
70%
ディスクで並列停止
05FAQ：認証とジッター
認証：Issuer更新で再発行しJWT audience確認、キーチェーン読み出しを徹底。
ジッター：損失一パーセント超帯は単線優先、再開フラグ有効、WebhookへRTTサンプル添付。
引用：16GBは対話Transporter一窓＋ヘッドレス一本、24GBは待機下で二本が緩む目安。手順はドキュメント、索引はブログ。
しきい値はヒューリスティクスでありSLAではありません。確定金額は購入画面を正とします。