不安を数値化することから始めます。コミット量については、GitHub の COO Kyle Daigle と CTO Vlad Fedorov が 4 月に「AI エージェントが毎週 GitHub へ約 2.75 億コミットを投入し、年間で約 140 億コミットに到達する見込み」と公表しました。これは 2025 年全体の 10 億コミットの 14 倍に相当します。リクエスト量では、AI エージェントが起こす PR が 2025 年 9 月の月間 400 万件から、2026 年 3 月には月間 1700 万件まで急増しています。計算リソースでは、GitHub Actions の週次使用分が 2023 年の 5 億分から、2026 年 4 月には単週 21 億分に達しました。安定性では、2 月だけで 37 件の障害が発生し、4 月 9–13 日にはエージェントセッションの待ち時間が通常の 15–40 秒から 54 分まで伸び、失敗率は最大 97.5% に達しました。5 月 6 日の Copilot Cloud Agents 障害時には、Actions Runner 全体の失敗率が約 17.1% を記録しています。

GitHub 側もこれを認めており、Fedorov は容量計画を 10x から 30x へ書き換え、パフォーマンスクリティカルな Ruby 経路を Go に移植し、Git と Actions のサービスを分離し、Stacked PRs を導入し、メンテナが PR 受付自体を停止できるオプションを検討しています。ただし供給側の拡張は中長期の話であり、2026 年下半期は「キューの裾延と散発的な失敗が初期値である」状態が iOS パイプライン全体の前提になります。「もう少し待てば収まる」期待は捨ててください。

これら 4 組の数値が示すことはひとつです。パイプラインの安定性を単一の中央 Runner プールに縛り付けるコストが、AI エージェント時代に入って再評価されているのです。次節では macOS Runner と「人 vs エージェント」という 2 つの軸でさらに掘り下げます。

GitHub ホスト型 Linux Runner は大規模で汎用的な x86_64 プール上で動作し、容量基盤が広く、スケジューリングの自由度も高い構成です。macOS Runner は Apple Silicon の物理機供給とソフトウェアライセンスの制約により、プール規模が Linux に比べて大幅に小さく、分単位の課金は約 10 倍になります。AI エージェントが大量参加していない 2024–2025 年であれば、キュー長と retry でこの差を吸収できました。AI エージェント時代に入ると、1 リポジトリの夜間リファクタが数時間で数十件の PR を生成し、各 PR が lint・unit・integration・archive・notary の各ワークフローを順次起動するようになるため、macOS Runner の利用率 ρ は容易に 1 に接近します。待ち行列理論上、平均待ち時間は ρ が 1 に達する遥か手前から急増し、P50 は秒単位から分単位、P95 は十数分まで伸びます。

さらに厳しいのは retry 嵐とコールドスタートの重畳です。flaky test が 1 回失敗すると、エージェントが自動 retry で即座に再申請を行い、複数のエージェントが同時に「申請→失敗→再申請」のループに入ることで、Runner 割当サービスに対する thundering herd を形成します。ホスト型 macOS Runner のコールドスタートは 60–120 秒であり、lint や PR 検証のような短時間ジョブには非常に高いオーバーヘッドとなる一方、archive や TestFlight アップロード、notary などの長時間ジョブでは「キュー段階で十数分待たされた後にようやく実行が始まる」状態になり、タイムアウトを連発します。下表は AI エージェント負荷下での Linux、ホスト型 macOS、KVMNODE 専用セルフホスト macOS の差分を整理した比較表で、そのまま RFC や調達文書に貼り付けて利用できます。

既に GitHub Actions セルフホスト Runner ガイドに沿って組織レベルの Runner と並行制限グループの分離まで進めている場合、次に行うべきは「AI エージェント PR と人手 PR の Runner をラベルで分割すること」です。まだ完全ホスト型のチームは、§4 の移行しきい値と判定木を確認してください。

2026 年 5 月、CI/CD と AI ツールチェーンを狙った 2 件のサプライチェーン攻撃が、「自動化されたコミットは監査対象外」という暗黙の前提を完全に破壊しました。Mini Shai-Hulud は npm ワームで、GitHub Actions の OIDC トークンを盗み取って正規の SLSA／Sigstore provenance を偽造し、被害者の開発環境で長期的に存続するために ~/.claude/settings.json や .vscode/tasks.json といった AI エディタ／エージェントが信頼する設定ファイルに悪意あるフックを書き込みました。Linux 環境では gh-token-monitor.service も併設され、開発者が GitHub トークンを更新した瞬間にホームディレクトリを破壊するトリップワイヤを仕掛けています。Megalodon はもっと直接的で、5 月 18 日 11:36–17:48 UTC のわずか 6 時間で、攻撃者が build-bot、auto-ci、ci-bot、pipeline-bot 等の偽造 ID を用いて 5,561 のリポジトリへ 5,718 件の悪意あるコミットを投入し、GitHub Actions ワークフローを差し替えて OIDC トークン、SSH 鍵、Docker 認証情報、各種クラウドキーを 216.126.225.129:8443 へ流出させました。両攻撃の共通点は、コミットメッセージや author フィールドが通常の CI 自動メンテと見分けがつかないこと、そして低シグナルの時間帯を意図的に選んでいることです。

iOS／macOS チームにとっての意味は明確です。Match keychain、App Store Connect API Key、notary 認証、profile、provisioning がすべて macOS Runner と keychain に集約されており、これらこそが OIDC トークンとワークフロー注入の標的そのものです。「PR をレビュアーに見てもらう」という防衛線は、AI エージェント流量下ではほぼ機能しません。レビュアーは週に数百件のエージェント PR を相手にして注意力が薄れ、しかも正規のエージェントもワークフローファイル（actions のバージョン更新、cache key の調整）を頻繁に書き換えるため、悪意ある変更との視覚的区別が成立しなくなります。以下の 6 つの方針は、防衛線をパイプラインそのものに下ろすための最小集合です。プラットフォームエンジニアリングの四半期ロードマップに組み込んでください。

これらの対策は単体ではいずれも目新しくありません。新しいのは、AI エージェント時代において「実施しなければインシデントを引き受けることになる」必須項目に格上げされた点です。100% ホスト型 Runner ではプラットフォーム既定により対応の深度が制限されますが、専用セルフホストノードであれば上記 6 項目すべてを macOS keychain、launchd、pf ファイアウォール、Actions Runner ラベルの層で具体的に実装できます。

すべてのプロジェクトが直ちに GitHub ホスト型 macOS Runner を離れる必要はありません。以下 4 つの定量しきい値で評価してください。① 月間 macOS Runner 請求額が同等の専有 Mac Mini 月額を超えているか、② P95 キュー待ちが平日朝晩で 10 分を超えてマージを阻害しているか、③ 資格情報の集中度として複数 workflow が同一 keychain と広い OIDC スコープを共有していないか、④ AI エージェント PR の比率がリポジトリ全体の 30% を超えていないか。2 つ以上に該当する場合、専用セルフホスト macOS Runner を次四半期の技術ロードマップへ載せてください。下記の判定木はそのまま計画書に貼って利用できます。

name: ios-ci
on: [pull_request]
permissions: {}
jobs:
  lint-and-unit:
    runs-on: [self-hosted, macos, agent]
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/lint.sh
      - run: ./scripts/test-unit.sh
  archive-and-notary:
    if: github.event.pull_request.user.type != 'Bot'
    runs-on: [self-hosted, macos, human]
    permissions:
      id-token: write
      contents: read
    environment: prod-signing
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/archive.sh
      - run: ./scripts/notarize.sh

上記の最小骨格には 3 つの方針が組み込まれています。トップレベルの permissions: {} による deny-by-default、ラベルによる lint／unit と archive／notary の分離、そして if: github.event.pull_request.user.type != 'Bot' によりエージェント PR からの本番署名を拒否です。これらはホスト型 Runner でも表面的には記述できますが、専用ノードでなければ macOS keychain、launchd、pf 出口許可リストと連動して実効化することはできません。複数席 SSH ガバナンス 文書の席数とキューの命名規約と組み合わせれば、「人＋AI エージェント＋複数開発者」が同一専用ノードを共用する完全な Runbook が完成します。

サイジングについて。PR 検証中心で人手開発者が少数、AI エージェント PR が中程度の中規模 iOS リポジトリであれば、M4 16GB·256 か 24GB·512、月次ベースラインに高ピーク日のスポット課金で十分です。シミュレータマトリクス、エージェント回帰、同居 OpenClaw Gateway が並走する混合負荷では、最初から M4 Pro 64GB·2TB を選択してください。多地域展開やグローバル展開のチームは、六地域選定と賃料 文書の RTT と同地域原則に従って Git 主要リージョンに合わせ、予算が許せば別リージョンに第二ノードをフェイルオーバとして配備し、単一リージョン障害による停止を避けてください。

前 4 節を、調達文書とプラットフォームエンジニアリング四半期計画にそのまま転記できる3 つの硬い方針に集約します。① AI エージェント Runner は専用ラベル＋専用 keychain／専用アカウントとし、人手開発者 Runner と隔離します。② OIDC スコープと PAT は短 TTL、最小権限、自動ローテーションを必須とし、本番署名ジョブは environment 保護で開発ジョブと物理的に切り離します。③ AI エージェント commit は verified author を必須とし、すべての .github/workflows/*.yml 改変は保護ブランチ＋二人レビュー＋必須 lint を経由させます。1 つでも欠ければ次の Mini Shai-Hulud／Megalodon 級攻撃を被弾する確率が幾何級数的に上昇します。

代替案を比較しておきます。100% GitHub ホスト型を継続すれば、課金とキュー裾延がエージェント流量に応じて線形あるいは指数的に増加し、資格情報サンドボックスは workflow 粒度が上限となり、Megalodon 級攻撃時には公式アナウンスを待つしかありません。蓋を閉じた Mac mini や私物改造で Runner を動かすと、物理安定性が低く、launchd と遠隔管理の整備が薄いため、休日のネットワーク断で出荷が止まります。汎用クラウド VM（Apple ハードウェア以外）で macOS を実行するのは Apple ライセンス違反であり、性能劣化も顕著です。iOS／macOS CI/CD と AI エージェント自動化が共存する本番環境において、KVMNODE Mac Mini クラウドレンタルがより良い解になります。専用 Apple Silicon、7×24 稼働、六地域選択、日／週／月の弾力的契約に加え、二重キュー・資格情報サンドボックス・OIDC 締め付けを 1 枚の変更チケットに収められるからです。プランは 料金ページ、運用は ヘルプセンター、ノートの発注は 注文ページ をご覧ください。