В облачном пилоте всё работает, но служба безопасности требует контроля сети и данных? Не покупайте Mac только из-за слова «самостоятельно»: оставьте облако, если оно проходит требования; переходите к Runner под вашим управлением лишь при конкретной потребности, а для Xcode сначала отдельно подтвердите поддержку macOS.
Кому пригодится: IT-руководителям, которым нужно проверить сетевые ограничения, данные и ответственность за среду Claude Code. Платформенным инженерам, которые сравнивают облачное исполнение с собственным Runner и оценивают нагрузку на сопровождение. Руководителям Apple-платформ, которым необходимо разделить обычные задачи агента и сборки Xcode с подписью.
Последняя проверка: 25 сентября 2026 года; сведения сверены с официальным объявлением и документацией Claude Code, а также документацией Apple. Доступность функций, условия участия и поддерживаемые платформы могут измениться, поэтому перед закупкой повторите проверку по актуальным официальным страницам.
Разведите облако, собственный Runner и Remote Control
Это три разных варианта исполнения, а не три названия одной архитектуры. При облачном сценарии вы используете размещённую поставщиком среду. В сценарии с самостоятельно размещаемой средой вычисления выполняются на инфраструктуре, которой управляет ваша организация; это меняет обязанности по подготовке и сопровождению Runner, но само по себе не означает, что модель работает локально. Remote Control относится к продолжению работы с сессией на личном компьютере пользователя, а не к общей машине сборки для команды. Сверяйте назначение и расположение сессий с описанием идентичности и исполнения сессий.
По официальному объявлению, функция самостоятельного размещения перешла в публичное тестирование для организаций Team и Enterprise; она выключена по умолчанию и недоступна организациям, использующим ZDR. Это три важных ограничения для планирования пилота: сначала подтвердите право вашей организации на использование, отдельно согласуйте включение функции и не считайте её доступной при действующем ZDR. Эти условия приведены в объявлении о самостоятельном запуске с собственной вычислительной инфраструктуры.
Чем облачный вариант отличается от собственного Runner? В облачной схеме меньше инфраструктурных обязанностей у вашей команды. Собственный Runner даёт возможность исполнять работу на управляемой вами инфраструктуре, но ответственность за доступность, подготовку и жизненный цикл среды не исчезает. Ни один из вариантов нельзя оценить только по месту запуска: проверяйте и путь запросов к модели, и то, кто управляет средой, и доступность нужных инструментов.
Не путайте собственный Runner с Remote Control. Если разработчик подключается к личной сессии на своей машине, это не создаёт общего пула исполнителей, не обеспечивает одинаковую сборочную среду для команды и не снимает зависимость от доступности компьютера пользователя. Для платформенной команды это принципиальное различие: личная сессия — рабочий процесс человека, а общий Runner — инфраструктурный компонент, который нужно проектировать, мониторить и администрировать.
Проверка платформы и операционной нагрузки
Перед пилотом составьте карточку совместимости, не заполняя её предположениями. Зафиксируйте, какие операционные системы и способы запуска прямо названы в актуальной документации для самостоятельной среды; отдельно отметьте, кто отвечает за Runner, образ, обновления, секреты, планирование задач и восстановление после отказа. В документации по самостоятельным средам сверяйте именно поддерживаемые варианты исполнения, а в инструкции по производственному развёртыванию — требования к внедрению и операционным обязанностям.
Не делайте вывод «самостоятельное размещение объявлено — значит, macOS уже поддерживается». В предоставленных официальных материалах факт запуска функции не доказывает совместимость с целевой версией macOS, доступность Xcode, работу симулятора или возможность использовать сертификаты подписи в нужном режиме. Если в вашей документации нет прямого подтверждения целевой платформы, пометьте поддержку как «не подтверждена» и не закладывайте Mac в производственную архитектуру на основании демонстрации входа в систему.
| Критерий | Облако | Runner под управлением организации | Что зафиксировать в пилоте |
|---|---|---|---|
| Сетевой путь | Сверяется с политикой доступа к облачному сервису | Можно проверять исполнение внутри выбранного сетевого контура, если вариант поддержан | Маршруты к репозиториям, моделям, пакетам и внутренним API |
| Управление средой | Меньше инфраструктурной работы со стороны команды | Команда отвечает за подготовку и сопровождение среды в согласованных границах | Владелец Runner, обновлений, образов и мониторинга |
| Платформенная совместимость | Проверяется по требованиям конкретной задачи | Подтверждается только документацией и реальным запуском на целевой платформе | ОС, инструменты, доступ к артефактам и воспроизводимость |
| Данные | Требуется проверить, что передаётся для обработки и какие действуют политики хранения | Собственное расположение Runner не исключает передачи данных для вывода модели | Промпты, ответы, результаты инструментов, журналы и секреты |
| Стоимость владения | Учитываются опубликованные условия использования и внутренние затраты на управление | Учитываются вычисления, сопровождение, резервирование и простой | Заполненная модель затрат без неподтверждённых скидок |
Решение платформенной команды
Когда предприятию действительно нужна собственная среда? Когда есть проверяемое требование, которое облачный вариант не выполняет: например, ограничение на сетевой маршрут, необходимость управлять набором инструментов или обязательство запускать работу в определённом контуре. Запишите конкретное требование и способ его проверки. Формулировка «так безопаснее» без модели угроз и подтверждённого потока данных недостаточна для закупки.
Пройдите проверку в таком порядке:
- Сопоставьте требования сетевой команды с фактическими маршрутами, необходимыми облачному варианту. Если маршруты разрешены и политика организации выполнена, оставьте облачный вариант кандидатом по умолчанию.
- Попросите владельца безопасности определить классификацию репозитория, промптов, результатов инструментов, журналов и секретов. Отдельно зафиксируйте, какие данные разрешено передавать для обработки моделью.
- Получите у платформенной команды подтверждение операционной модели Runner: кто поставляет и обновляет среду, кто управляет исполнителями, кто следит за доступностью и кто реагирует на сбои.
- Сверьте целевую операционную систему и инструменты с действующей документацией. Пока поддержка нужной платформы не подтверждена, не считайте задачу прошедшей технический допуск.
- Проведите пилот на репозитории и задаче, которые соответствуют реальному рабочему процессу. Проверьте не только запуск, но и получение исходников, доступ к зависимостям, передачу результата и очистку временной среды.
- До закупки назначьте владельца каждого риска и установите условие остановки: неподтверждённая платформа, неприемлемая передача данных или отсутствие ответственного за сопровождение означают возврат к облаку либо к текущему утверждённому процессу.
Проверка границ данных службой безопасности
Собственное место исполнения и локальная обработка модели — разные свойства. Копия репозитория, создаваемая или используемая в вашем контуре, может оставаться в управляемой вами инфраструктуре, но для получения вывода модели могут передаваться промпт, ответ и результаты вызванных инструментов. Поэтому схема «Runner внутри сети — значит, данные никуда не уходят» не является достаточным описанием архитектуры. Поток данных необходимо подтвердить по актуальной документации и настройкам конкретной организации.
Нарисуйте поток от пользователя до результата и обозначьте на нём как минимум: источник сессии, Runner, хранилище исходников, внешние конечные точки, модель, журналы и место хранения артефактов. Для каждого ребра укажите владельца и класс данных. Подтвердите, включаются ли в запрос фрагменты кода или вывод команд, как журналируются сессии и какие исключения применяются к репозиториям с ограниченным доступом.
Не смешивайте контроль над журналами и контроль над каждым запросом. В официальной статье о настраиваемых сроках хранения данных для корпоративных планов проверьте доступные параметры и их область действия. Если ваша организация полагается на Zero Data Retention, отдельно сверяйте официальное описание применимости ZDR к продуктам: объявление о тестировании собственного окружения прямо указывает на несовместимость с организациями, использующими ZDR. Не пытайтесь устранить это ограничение простым размещением Runner внутри сети.
Критерий допуска службы безопасности — не наличие сетевого сегмента как такового, а проверенная схема данных и политики, применённые именно к нужному продукту и сценарию. Включите в проверку управление идентичностью сессии, права пользователя, срок хранения, исключения для чувствительных репозиториев, работу с токенами и процедуру отзыва доступа. Для сомнительных случаев сначала уменьшите объём доступных секретов и выберите тестовый репозиторий без производственных данных.
Разделение задач Apple-платформы
Поддерживает ли самостоятельный Runner macOS? Не считайте это подтверждённым, пока актуальная документация не называет macOS среди поддерживаемых вариантов для нужного способа исполнения. Объявление функции и описание общей модели Runner не заменяют явного подтверждения операционной системы.
Можно ли выполнять сборку Xcode в такой среде? Только после отдельной проверки поддержки платформы и сквозного прогона на реальной целевой инфраструктуре. Нужно подтвердить наличие требуемой версии Xcode, доступ к симуляторам и зависимостям, сохранение артефактов, а для подписываемой сборки — безопасную подачу и изоляцию идентичностей подписи. Отдельно проверьте, кто может читать секреты и как они удаляются после завершения задачи.
Документ Apple о предоставлении внешним агентам доступа к инструментам Xcode описывает взаимодействие внешних агентов с инструментами Xcode. Он не подтверждает совместимость самостоятельного Runner Claude Code с macOS и не доказывает, что Runner способен выполнить промышленную сборку, тестирование симулятора и подписание приложения. Это разные вопросы, и у каждого должен быть собственный проверяемый результат.
Разделите план работ на две группы. Анализ кода, редактирование и общие проверки оценивайте по доступности исходников, зависимостей и требуемых инструментов. Задачи, которым нужны macOS, Xcode, симулятор или сертификаты подписи, рассматривайте как отдельный контур Mac CI. Не связывайте допуск первой группы с автоматическим допуском второй: успешный запуск агента не является приемочным тестом сборки iOS-приложения.
Когда вы дойдёте до планирования Mac-узла, сначала определите его роль, необходимый набор инструментов и требования к изоляции. Руководство по Mac M4 поможет перейти к отдельной оценке аппаратного узла; это не заменяет подтверждение платформы Runner или тестирование вашей Xcode-цепочки.
Расчёт FinOps без выдуманной экономии
Сравнивайте полную стоимость, а не только цену вычислительного часа. Для облака учитывайте применимые официальные условия использования, объём фактической работы и внутренние затраты на управление доступом и политиками. Для собственного Runner учитывайте вычислительную инфраструктуру, подготовку и обновление образов, оркестрацию, мониторинг, резервирование, простой и время инженеров на устранение сбоев. Пока у вас нет проверяемых цен и журналов загрузки, не выводите процент экономии.
Используйте формулу как шаблон для финансовой модели:
- Облачная стоимость за период = официально подтверждённые начисления за использование + внутренняя стоимость управления политиками и доступами.
- Стоимость Runner под вашим управлением = инфраструктура + подготовка и обслуживание образов + оркестрация + мониторинг + резервирование + время эксплуатации + стоимость незагруженной ёмкости.
- Стоимость Mac CI = подтверждённая стоимость Mac-ресурса + Xcode-эксплуатация + изоляция подписания + хранение артефактов + реагирование на сбои.
Условия выбора и выхода из пилота
Используйте ветвление как решение, а не как формальность:
- Если облачный вариант удовлетворяет сетевым, информационным и операционным требованиям, то оставьте его основным: переход на собственный Runner не оправдан одной только потребностью в «контроле».
- Если внутреннее сетевое ограничение, контролируемый набор инструментов или требование комплаенса не выполняются в облачной схеме, то оценивайте самостоятельный Runner — но только после подтверждения его доступности для вашей организации и целевой платформы.
- Если задаче необходимы Xcode, симулятор, macOS или подпись, то сначала получите подтверждение платформы, затем выполните сквозную сборку с проверкой изоляции подписывающих секретов. При отсутствии подтверждения не назначайте такой Runner производственным Mac CI.
- Если у команды нет владельца обновлений, мониторинга и реакции на сбои, то не утверждайте самостоятельное развёртывание как готовое к эксплуатации; вернитесь к облаку или к уже принятому процессу, пока обязанности не распределены.
Повторно открывайте решение при изменении условий публичного тестирования, доступности для вашего плана, требований ZDR, перечня поддерживаемых платформ или политики хранения. Если одно из условий меняется, заново прогоните соответствующую часть проверки, а не считайте прежний протокол бессрочным.
Если Xcode-задачам действительно нужен реальный Mac, но вы пока не подтвердили поддержку macOS для самостоятельного Runner, не покупайте оборудование в расчёте на неподтверждённую интеграцию. Сначала проверьте требования и проведите сквозной пилот на целевой цепочке. Для временного или пилотного Mac-ресурса аренда у MACGPU может оказаться практичнее собственного узла: вам не нужно заранее принимать на себя покупку оборудования, обслуживание и риск простаивающей мощности. Но при постоянной высокой загрузке или требованиях к физическим интерфейсам сравните аренду с покупкой по своей модели затрат, а не по общему обещанию экономии.