TeamCity 2026.2 MCP は企業で試験導入できますが、Brave Mode を既定で有効にしたり、汎用 AI Agent に本番リリース線を直接操作させたりしてはいけません。今週は安全モード、プロジェクト単位の専用 ID、読み取り専用の障害調査から始め、書き込み操作は検証用プロジェクトに限定してください。

最終更新：2026年9月3日。 TeamCity 2026.2 のリリース情報、MCP 統合、権限、トークン、アップグレードに関する公式資料を基に確認しています。MCP クライアントの互換性、企業ネットワークでの挙動、Mac ノードの復旧結果は実環境での再検証が必要です。

01

まず決めるべき TeamCity 2026.2 MCP 企業権限受け入れ検証の範囲

最初に、操作を4段階へ分けます。TeamCity 2026.2 では、公式に Pipeline の読み取り、作成・更新、削除に関わる MCP ツールが案内されています。したがって「MCP に接続できた」ことだけでは、本番利用の安全性を証明できません。TeamCity 2026.2 のリリースノートと公式 MCP 統合ガイドを、検証対象の根拠にしてください。

操作区分 試験導入時の判断 本番へ広げる条件 必須の証拠
ログ・設定の読み取り 許可 対象プロジェクトを限定 実アクセス結果、監査記録
個人または検証用ビルドの起動 条件付き許可 ブランチ、Agent Pool、実行者を固定 起動履歴、停止手順
Pipeline の作成・更新 テストプロジェクトのみ 差分、承認、ロールバックを記録 構成履歴、承認記録
Pipeline やプロジェクトの削除 保留 明示的な人手承認と復旧確認 削除監査、復元テスト

この表の上2段階を通過しても、下2段階を自動的に許可してはいけません。TeamCity のプロジェクト権限、MCP の認可、Build Agent の実行権限、macOS のローカルアカウントは別々に評価します。

誰がこの検証を担当するか

  • CI プラットフォーム責任者：MCP ツール一覧、接続方式、Agent Pool への振り分けを確認します。
  • セキュリティ責任者：OAuth PKCE、トークンの範囲、権限継承、失効手順を確認します。
  • プロジェクト責任者：Pipeline の読み取り、起動、変更、削除を個別に受け入れます。
  • Mac プラットフォーム担当者：Xcode、署名資格情報、ノードのアカウント分離を確認します。
  • 運用・監査担当者：操作ログ、異常リクエスト、緊急停止、復旧記録を確認します。
02

プラットフォーム責任者が先に固定する接続境界

TeamCity 2026.2 MCP の接続先は、単なるチャット連携ではありません。AI Agent から TeamCity の操作を呼び出す制御面です。TeamCity の公式資料で提供されるツールと、社内で許可する操作を一覧にし、未使用の書き込み経路を最初から開けない構成にします。

第一段階では、安全モードを基準にします。読み取り専用のログ調査、ビルド結果の確認、失敗ジョブの原因抽出だけを対象にし、構成変更や削除は無効化または人手承認の対象にします。Brave Mode は検証用プロジェクト、限定された時間帯、限定 ID の組み合わせでのみ扱います。公式のAI Agent 統合における安全モードと Brave Mode の説明を、社内の許可リストへ落とし込んでください。

ここで見落としやすい制限があります。

  1. MCP 側で対象ツールを制限しても、TeamCity 側のプロジェクト権限が広ければ可視範囲は広がります。
  2. Agent Pool を分けても、同じサービスアカウントや共有秘密情報を使えば実質的な分離になりません。
  3. AI Agent の自然言語指示は変更申請ではありません。差分、承認者、実行結果を既存の変更管理へ戻す必要があります。
03

セキュリティ責任者が確認する OAuth PKCE と最小権限

接続方式は、利用者の OAuth 認可を使うのか、専用のユーザートークンを使うのか、プロジェクト単位の制限付きトークンを使うのかで分けます。TeamCity のアクセス・トークン管理では、トークンの発行と管理を確認できます。OAuth PKCE は認可フローの候補ですが、それだけで TeamCity のプロジェクト権限が狭くなるわけではありません。

外部 Agent を個人の管理者 ID に接続する方式は避けます。専用 ID を発行し、担当部署、用途、責任者、保管場所、失効条件を台帳に記録してください。プロジェクト専用の制限付きトークンを使う場合も、実際に別プロジェクトへアクセスできないことを操作テストで確認します。

TeamCity のロールと権限の説明およびREST API の権限一覧と、次の証拠を突き合わせます。

  • ロールとプロジェクト権限のエクスポート
  • OAuth 認可画面で確認した対象範囲
  • トークンの用途とスコープ
  • 親プロジェクトからの権限継承
  • 許可対象外プロジェクトへの実アクセス結果
  • 失効後に再利用できないことの確認

注意：親プロジェクトの権限継承は、Agent が見られるビルドや構成を意図せず増やす代表的な原因です。子プロジェクトだけを見せたい場合は、継承設定と実アクセスの両方を確認してください。

04

プロジェクト責任者が書き込み操作を段階的に受け入れる

TeamCity MCP は、接続確認の次に操作別の受け入れを行います。読み取りツール、ビルド起動、Pipeline 更新、削除を同じテストとして扱わないでください。

読み取りとビルド起動

読み取りでは、ログ、ビルド結果、対象ブランチ、失敗理由が許可範囲に収まるかを確認します。個人ビルドや検証用ビルドの起動では、実行者、対象ブランチ、Agent Pool、成果物の保存先を固定します。

ビルドが無限に再実行されない仕組みも必要です。連続起動、重複起動、失敗時の再試行を監視し、異常時には担当者が手動でキャンセルできることを確かめます。

Pipeline の更新と削除

更新はテストプロジェクトと非本番ブランチに限定します。変更前後の差分、承認者、実行時刻、ロールバック操作が記録されることが条件です。TeamCity のユーザー操作追跡に関する公式資料で、誰がどの操作を行ったかを追跡できる状態にします。

削除は、試験段階では保留が妥当です。削除権限を持つ Agent を作らず、どうしても確認する場合は隔離プロジェクトと復旧用バックアップを使います。復元できることを確認できない削除試験は、受け入れ証拠として不十分です。

05

Mac プラットフォーム担当者が署名経路を分離する

MCP は TeamCity の制御面です。MCP の権限を持たせたからといって、AI Agent に本番の Mac へ直接ログインさせたり、Keychain を読み取らせたりしてはいけません。

Xcode の通常診断、信頼できないコードの検証、正式な署名・公開は、別の Agent Pool へ分けます。正式な署名ノードでは、レビュー済みの固定 Pipeline だけを受け付けます。TeamCity のAgent Pool 設定とAgent の通信方式を確認し、MCP の操作権限とノード上の実行権限を混同しないことが重要です。

AI Agent が iOS ビルドを起動する場合は、次の経路にします。

  1. Agent は検証用 TeamCity プロジェクトだけを参照します。
  2. TeamCity が許可済みのビルド構成へ要求を渡します。
  3. 非署名の検証ジョブは隔離された Agent Pool で実行します。
  4. 署名が必要なジョブは、承認済みの固定 Pipeline のみが専用 Mac ノードへ送ります。
  5. 証明書、秘密鍵、プロビジョニング情報は Agent の会話やログへ返しません。

VpsMesh のMac のプライバシーポリシーも、署名ノードへ扱わせるデータを決める際の確認材料になります。実際の Xcode プロジェクト、資格情報の流れ、ノード再起動後の復旧は、契約前に隔離環境で確認してください。公式文書だけから、特定の Mac ノードが安全に復旧すると推定してはいけません。

06

運用・監査担当者が止血能力を検証する

本番候補へ進める前に、失控時の停止を実演します。トークン失効、OAuth セッション終了、Brave Mode の無効化、異常ビルドのキャンセルを個別に行い、Agent が再び操作できないことを確認します。

監視対象は、単発の失敗だけではありません。高頻度の REST リクエスト、同一ビルドの反復起動、Pipeline の意図しない変更、削除操作、対象外プロジェクトへのアクセスを検出できるようにします。監査記録は TeamCity の操作履歴だけでなく、認証基盤、Agent、Mac ノードのログと時刻を照合します。

第一歩：失敗時の降格経路を決める

TeamCity 制御面が停止した場合は、承認済みの手動リリース手順へ戻せるようにします。Mac Agent が停止した場合は、署名ジョブを自動的に別ノードへ流すのではなく、資格情報の再利用条件を確認してから切り替えます。

TeamCity の更新前には、公式アップグレードノートで MCP、認証、権限の変更点を確認します。2026.2.x の修正版やセキュリティ告知でツール権限が変わった場合は、今回の受け入れ結果を無期限に使わず、対象操作を再試験してください。

07

技術管理層が試験導入の判定を出す

最終判定は「接続できるか」ではなく、役割ごとの証拠で行います。

  • 試験導入を承認：読み取り診断、限定ビルド、プロジェクト単位の ID、監査、緊急停止が確認済みです。
  • 制限付き運用：Pipeline 更新や Mac 実行に未確認項目があり、検証用プロジェクトだけへ範囲を限定します。
  • 保留：管理者トークンの共有、親プロジェクトの過剰継承、署名ノードへの直接経路、操作ログ欠落のいずれかがあります。

タスク量が増えた後の判断では、ビルド待ち時間だけを見ません。検証用、通常ビルド用、署名用の Agent Pool を維持できるか、Mac ノードの再起動や交換時に資格情報を安全に扱えるかを確認します。必要なら、まず一台の隔離されたリモート Mac で下流のテスト Agent Pool を作り、実際の Xcode プロジェクト、タスク振り分け、再起動後の復旧を検証します。

自社で Mac を購入する場合は、初期費用、余剰時間の設備、故障対応、交換管理を負担します。特に短期の試験導入では、遊休時間が発生しやすく、署名ノードと通常ビルドノードを分けるほど管理対象も増えます。一方、リモート Mac のレンタルなら、試験期間に合わせて専用環境を確保し、通過後に長期のビルド池へ拡張する判断がしやすくなります。

まずはVpsMesh の Mac レンタル環境で隔離 Agent Pool の検証条件を確認し、Xcode の実案件で受け入れ証拠を揃えてください。恒常的な高負荷処理や物理ポートが必要な用途では自社設備が適する場合もありますが、MCP の安全な試験環境や一時的なビルド容量が必要なら、専用のリモート Mac を先に使う方が判断を誤りにくいです。