TeamCityのシステム開発の完全ガイド - ブログ

TeamCityの導入では、ビルドやテスト、配備のどこを自動化するかと、CloudかOn-Premisesかを最初に決めます。

運用の担当と移行の範囲を整理し、代表的なサービスのPoCから段階的に広げると、品質とリリース速度の向上につながります。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

TeamCityの仕組み

管理とビルド実行を担う要素が分かれています。

TeamCityは、継続的インテグレーションと継続的デリバリーを支えるCI/CDサーバーです。開発者が変更を登録すると、あらかじめ決めた処理を実行し、結果を一か所で管理します。

導入効果を見るには、製品の機能だけでなく、自動化する工程と運用を担当する人も合わせて決めておく必要があります。

自動化できる開発工程

ソースの取得からパッケージ作成まで、ビルドの工程をひととおり自動化できます。そのなかには、依存ライブラリの解決や単体テスト、静的解析も含まれます。

テスト結果やログは保存されるため、失敗した変更を早い段階で見つけ、原因をさかのぼって追えます。また、承認後はステージング配備から本番リリース、成果物の保存までを、ビルドチェーンでつなげられます。

これまで人が手で行っていたコマンド実行やテスト確認、成果物のサーバー転送も自動化できます。同じ条件で検証を繰り返せるため、作業時間の面だけでなく、リリース品質の安定にもつながります。

主な構成要素

構成要素を分けて把握すると、管理画面と実行処理それぞれの責任範囲が見えてきます。

On-Premisesで導入する場合は、自社で管理する範囲と、構成を自社で制御しやすい点を、運用負荷と合わせて比べます。

TeamCity Server：プロジェクトやビルド構成を管理し、権限や通知、履歴も扱います。
Build Agent：指定したOSやツールの環境で、実際のビルドを実行する役割です。
連携・保管機能：VCS設定、ビルドチェーン、成果物領域を扱います。認証・権限と監査ログも必要です。
拡張・設定機能：複数OSでの並列実行とコンテナAgentに対応し、REST APIも使えます。設定はKotlin DSLやYAMLで書けます。

複数OSやコンテナ、クラウド上のAgentを扱う規模になると、設定をコードで管理することが重要になります。

TeamCity CloudとOn-Premisesの選び方

サーバーの保守や初期構築の手間を減らして早く始めたいなら、Cloudが候補になります。一方、閉域網での運用やデータ管理、実行環境の制御を重視する場合は、On-Premisesが候補です。

Cloudでも、自社ネットワーク内や自社クラウドにあるセルフホストAgentを接続できます。さらに、管理サーバーと実行環境を分けたハイブリッド構成も選べます。

Cloudを選ぶメリットと注意点

Cloudは、環境の構築よりもパイプラインの改善に時間を使いたい小規模チームに向いています。

保守を任せやすい：サーバーの設置とDB保守をサービス側が担い、更新や障害対応の多くも任せられます。
Agentを追加しやすい：需要に合わせてクラウドAgentを増やし、待ち時間の短縮につなげられます。
利用量を確認する：料金はビルド時間、ストレージ、データ転送の量で変わります。
自社管理も残る：テストデータやログ、接続元の管理に加え、セルフホストAgentやリポジトリ権限、配備先も自社で管理します。

Cloudを選んでも、運用責任がなくなるわけではありません。そのため、自社で管理する範囲は導入前に決めておきます。

On-Premisesを選ぶメリットと注意点

On-Premisesを選ぶ際は、自社で管理する範囲と、環境を自社で制御できる利点を確かめておきます。

管理範囲：ServerやDB、Agentを、自社か委託先が管理します。ネットワークやバックアップ、更新も、自社か委託先が担います。
適する環境：閉域網での開発や、保管場所・経路を自社ポリシーに合わせる場合、特殊ツールや社内認証と連携する場合に向きます。
実行環境：AgentのスペックとOSを固定でき、同じ条件の環境を再現しやすいのが利点です。
運用上の注意：冗長化と容量計画が必要です。脆弱性対応やプラグイン検証、復旧訓練も欠かせません。

公式の価格ページでは、Professionalが無料で、3台のBuild Agentと100件のビルド構成を含みます。Enterpriseの料金は年額2,399ドルです。

追加Agentは1台あたり年額359ドルです（出典: TeamCity公式購入ページ、2026年8月確認）。税と為替、インフラ費と構築費は、別途見積もる必要があります。

ポイント

CloudかOn-Premisesかは、保守の手間を減らしたいか、閉域網やデータ管理を優先したいかで考えます。どちらを選んでも、自社で管理する範囲は導入前に決めておきます。

TeamCityの導入の進め方

代表サービスでの検証を経て、運用を社内へつなぎます。

導入は、現在のジョブをすべて移す作業からは始めず、まず現状を棚卸しするところから始めます。あわせて成功条件を先に決めておくと、導入後に評価が曖昧になるのを防げます。

棚卸しでは、リポジトリや言語、テストの状況を整理します。成果物と配備先の情報も洗い出します。秘密情報と承認手順も合わせて整理し、代表サービスで小さく検証します。

現状調査と要件整理

現状調査では、ビルド環境と運用条件を把握します。そのうえで、自動化する作業と人が承認する作業を分けておきます。

開発状況：リポジトリ数と主要言語、ビルドツールを記録します。1日の回数と同時実行数も控えておきます。
品質状況：平均時間や失敗率、テスト種別を確認し、手動の確認と自動化しない承認を切り分けます。
配備・運用：成果物の保管先と、配備先の承認者を定めます。失敗時に復旧を担う人も決めておきます。
データ管理：成果物やログに、顧客情報や個人情報、秘密鍵が含まれる可能性があるかを確かめます。

保存期間や閲覧者、削除方法を決めてから構成を選ぶと、作り直すリスクを抑えられます。外部サービスへの転送の可否も、あわせて決めておきます。

PoCでの代表的なサービス検証

PoCでは、1〜2個の代表的なリポジトリを使い、コミットからテスト、成果物作成、ステージング配備までを一通り動かします。

案件が複雑な場合は、依存関係が多いもの、テストが遅いもの、複数環境へ配備するものも対象に含めます。そうすると、実運用に近い検証になります。

性能：ビルド時間とAgentの待ち時間を測定します。
品質：失敗率と失敗からの復旧時間を記録します。
効果：リリース頻度と手作業の削減時間を比較します。

たとえば、平均待ち時間を半分にする、失敗原因を30分以内に特定するなど、導入前後で比べられる数値を目標に置きます。

PoCの間に権限や秘密情報、ログのマスキングも検証しておくと、本番移行を安全に進めやすくなります。

コード化・段階移行・引き継ぎ

本番展開に向けて、命名規則やブランチ戦略を標準化します。権限や成果物・ログの保持期間も、あわせて揃えます。

画面上の操作だけで設定を増やすと、担当者が代わったときに再現できなくなります。そこで、Kotlin DSLやYAMLベースのPipelines、テンプレートで設定を管理し、変更をレビューできるようにします。

段階移行：重要度の低いサービスから始め、手順を改善して対象を広げます。
一斉移行を避ける：資格情報の失効、Agent不足、依存ジョブ漏れのリスクを抑えます。配備停止のリスクも和らげられます。
担当を引き継ぐ：日次確認と失敗の一次切り分けに加えて、バックアップや更新の担当者と期限を決めます。障害連絡と復旧訓練も忘れずに含めます。

引き継ぎ先は内製チームとし、継続して運用できる担当体制を整えます。

ポイント

導入は、現状の棚卸しから始めて、代表的なサービスのPoCで効果を確かめてから広げます。一斉に移すと、資格情報や依存ジョブの漏れが起きやすいため、段階的に進めます。

TeamCityのシステム開発費用と料金相場

費用は、ライセンスまたはCloud利用料と、サーバーやAgentのインフラ費に分けて考えます。さらに、設計・構築費、既存環境からの移行費、保守運用費も含めて見ておきます。

初年度の金額だけでなく、3年・5年の総保有コストで比べておきます。特に、TeamCity単体の価格だけを見ると、Agentを増やしたときの待ち時間やストレージの費用を見落としがちです。更新や障害対応の費用も、見落としやすい項目です。

▶ 詳細はこちら：TeamCityのシステム開発の見積相場や費用/コスト/値段について

ライセンスとCloud利用料の見方

On-PremisesとCloudでは料金の単位が異なるため、ライセンス費用と利用枠を分けて見積もります。

On-Premises：ProfessionalとEnterpriseで料金が分かれます。
Cloud料金：コミッター数に応じて月額で課金され、最低人数も決まっています。
Cloudの利用枠：クレジットやストレージ、データ転送量を確認します。
試算条件：利用実績と契約条件を突き合わせて見積もります。

2026年8月時点では、On-Premises Professionalは無料で、3台のBuild Agentと100件の構成を含みます。Enterpriseは年額2,399ドルで、追加Agentは1台あたり年額359ドルです（出典: TeamCity公式購入ページ、2026年8月確認）。

Cloudはコミッター1人あたり月額15ドルで、最低3人からです。年払いの最低額は年額540ドルです。

最低プランには、月24,000 Build Credits、ストレージ120GB、月600GBの転送が含まれます。追加の25,000クレジットは20ドルです（出典: TeamCity公式購入ページ、2026年8月確認）。

重いテストや成果物が多いと利用量は増えます。そのため、過去のビルド時間と成果物の容量で試算し、税や為替、契約条件も確かめたうえで、最新の見積を取得します。

構築・移行費の参考レンジ

TeamCity固有の国内受託構築費を示す公的統計はありません。そのため、次の金額は、業務システムの人月単価とCI/CDの作業範囲から算出した参考値です。

小規模PoC：1リポジトリと1〜3本のビルドが対象です。Git連携、単体テスト、権限設定も含みます。費用は50万〜150万円、期間は2〜6週間が目安です。
標準導入：複数リポジトリと10〜30本の構成が対象です。連携や成果物保管のほか、通知と運用手順も含みます。費用は150万〜500万円、期間は1〜3か月程度です。
中〜大規模移行：数十〜数百のビルドと複数環境が対象です。SSOや監査も含みます。費用は500万〜1,500万円以上、期間は3〜9か月程度です。
周辺開発も含む場合：Kubernetesや複数クラウドを扱い、検査、自動配備、内製化支援まで含めると、1,000万〜3,000万円以上になる可能性があります。

中〜大規模移行では、冗長化やIaC、教育も扱います。

これらの金額は、TeamCity本体ではなく、周辺の開発基盤を設計・構築する費用です。要件や既存ジョブの品質で変わるほか、対象数やセキュリティ、教育の有無にも左右されます。

保守・運用費と3年TCOの考え方

長期の費用は、日々の保守項目、ライセンス更新の条件、見積の範囲に分けて把握します。構築後もビルド構成は増えていくため、初期費用だけでは実際の負担とずれてしまいます。

運用費の内訳：インフラとクラウド実行料、保存とバックアップを含みます。更新や監視、脆弱性対応も必要です。OS更新やプラグイン検証、失敗調査も対象です。
保守費の目安：類似システムでは、初期構築費の年15〜25％程度を見ておくことがあります。運用量に応じて再見積もりします。
更新割引：新規分と既存分で、更新割引の条件が異なります。
見積の分け方：要件定義と設計、構築と移行に分けて見積もります。テストや教育、保守も個別に示します。ライセンスとインフラは、別枠で扱います。

2025年11月3日以降に購入する新規のOn-Premisesライセンスは、従来の50％更新割引の対象外です。一方、購入前の既存ライセンスは、期限内に更新条件を満たせば割引の対象になります。なお、2026年に追加するライセンスと更新単価が混在する可能性があります（出典: TeamCity公式ブログ「On-Premises更新価格の変更」、2025年）。

ポイント

費用は、初年度の金額だけでなく、3年・5年の総保有コストで比べます。構築費は対象の範囲で大きく変わるため、PoCと本格導入を分けて見積もります。

TeamCityの開発会社・ベンダーの選び方

販売窓口かどうかより、支援の範囲を確かめます。CI/CDの設計や移行、テスト自動化に加えて、セキュリティや運用の引き継ぎまで支援できるかを見ます。

構築の品質や障害対応の力は、「TeamCityを使える」という説明からは分かりにくいものです。そこで、自社の要件に近い実績と、担当者の役割分担を確認します。

TeamCityとCI/CD移行の実績

実績は、導入社数だけでなく、構成と成果を見ます。公開できない案件でも、匿名化した図や手順、障害対応の例から経験を判断できます。

環境：CloudかOn-Premisesか、Agent台数を確認します。対象リポジトリ数と移行元も確かめます。
連携：SSOや秘密情報管理、コンテナとKubernetesを確認します。IaCや配備先との連携も確かめます。
運用：運用期間や障害対応の経験、具体的な移行手順を見ます。

TeamCity本体を開発する案件か、TeamCityを中心にCI/CD基盤を構築する案件かを区別しておきます。通常は後者です。

後者の場合は、プラグインやスクリプトを追加開発します。社内ポータルや監査連携も開発対象に入ります。区別が曖昧だと、見積の範囲と完成物が食い違います。

見積と提案の比較条件

候補となる会社に同じ要件書を渡し、工程ごとに見積もってもらうと、抜けや削減余地を比べやすくなります。

費目：PoCや設計、構築、移行を分けて示してもらいます。テストや教育、保守も個別に分けます。
作業範囲：ジョブの整理や秘密情報の移行を含むかを確認します。バックアップと復旧訓練も対象に入るかを見ます。
契約条件：前提と対象外、納品物を確認します。検収基準や変更管理、連絡時間も見ておきます。
権利と責任：脆弱性報告やライセンス、秘密情報の扱いを明確にします。成果物の著作権と再利用権も含めます。

一括計上の提案では削減箇所が見えにくく、作業の漏れは追加費用につながります。

設定ファイルやKotlin DSL、YAMLの著作権と再利用権は、契約で定めます。IaCやスクリプトに加えて、テストコードと運用手順についても決めておきます。

担当者が交代しても運用できるよう、教育と引き継ぎが含まれるかを確かめます。

保守体制と内製化支援

契約の前に、運用を誰が担い、どこまで社内へ移すかを決めておきます。

保守対象：言語やテストツール、コンテナイメージが変わるたびに保守します。OSや認証方式が変わる場合も対象です。
対応時間と役割：平日や夜間、休日の対応が必要かを、SLAに定めます。一次切り分けと復旧を、誰が担うかも決めます。
内製化支援：設定の読み方やログ調査を社内へ移します。Agentの追加や更新の検証も、段階的に内製化します。

▶ 詳細はこちら：TeamCityのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：TeamCityのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：TeamCityのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、販売窓口かどうかより、CI/CDの設計から運用の引き継ぎまで支援できるかで選びます。見積は同じ要件書をもとに工程別に取り、作業範囲と契約条件をそろえて比べます。

TeamCityのセキュリティと運用上の注意

認証情報の扱いは権限設計と復元訓練まで含めて考えます。

資格情報やクラウドトークン、署名鍵が集まるうえ、配備権限も持つため、TeamCityは重要な認証基盤として扱います。そのうえで、最小権限とアクセス制御、監査の仕組みを設計します。バックアップと更新手順も決めておきます。

秘密情報とアクセス権の分離

資格情報が漏れないようにし、必要な人と処理だけがアクセスできる構成にします。

秘密情報：パスワードやトークンは、リポジトリや設定に直接書きません。環境変数やログへ出すことも避けます。
必要最小限：秘密情報管理サービスや短期トークンを使い、ビルドごとに権限を絞ります。
権限分離：管理者と開発者、閲覧者を分けます。Agentの実行ユーザーも別に扱います。
アクセス管理：SSOや多要素認証を確認します。監査ログ、成果物の取得権限、配備先の変更権限も見ておきます。

コマンド引数や環境変数をログに出さない設定も確かめます。公開する場合は、VPNなどの追加制御を検討し、ServerはAgentと別のホストに置きます。

バックアップは取るだけでなく、復元できるかを定期的に訓練しておきます。

脆弱性対応とAI連携の運用

脆弱性の修正状況を追うとともに、AI連携で扱う権限とデータの範囲を定めます。

脆弱性：2026年7月、On-Premisesの全バージョンに影響するCVE-2026-63077が公表されました。
修正対応：修正版は2025.11.7と2026.1.3です。更新できない場合には、パッチプラグインも案内されています。
Cloudの管理：脆弱性対応は不要とされていますが、Agentなどの権限管理は必要です。
AI連携：2026.1でCLIとMCP、AI Assistant、Pipelinesが拡張されました。AIによるビルド状態やログの調査支援も示されています。
利用制限：AI連携は読み取り専用や人の承認から始めます。

この脆弱性では、認証回避とOSコマンド実行の可能性も示されています。

Cloudでも、セルフホストAgentやリポジトリ、配備先の権限管理は必要です（出典: TeamCity公式セキュリティ告知、2026年7月）。

強い権限を持つトークンは、ビルドや成果物の取得、配備を可能にする場合があります。そこで、AI連携の対象を限定し、秘密情報や顧客データを外部AIへ送らない規則を定めます（出典: TeamCity 2026.1公式リリース記事、2026年5月）。

ポイント

TeamCityは認証情報や配備権限が集まるため、脆弱性対応と権限の管理を、導入後も続く運用の前提として扱います。AI連携も、権限を絞った範囲から始めると安全です。

TeamCityのシステム開発でよくある質問

無料版の範囲や既存のCI/CDからの移行、外注の必要性など、導入前によくある疑問に答えます。

TeamCityは無料で使えますか？

On-Premises Professionalは無料で、公式の購入ページでは3台のBuild Agentと100件のビルド構成を含みます。

小規模チームやPoCに向いています。ただし、構成数や並列実行、サポートなどが要件を超える場合は、EnterpriseやCloudも比べます。監査や運用体制が要件を超える場合も同様です。

既存のJenkinsなどから移行できますか？

移行はできますが、ジョブを機械的にコピーするだけでは足りません。まず、ビルドやテスト、成果物を分解します。承認や配備の流れ、資格情報、通知も整理します。

不要な処理は整理したうえで、TeamCityのビルド構成やビルドチェーンへ置き換えます。代表的な数本で、ログや時間、成果物の再現性を確かめてから広げます。

TeamCityの構築は外注したほうがよいですか？

小規模なPoCは、自社でも試せます。閉域網やSSO、複数クラウドが絡む場合は、専門会社への相談が有効です。既存CI/CDの移行や監査、24時間運用が絡むときも同じです。

外注時は、成果物と教育、引き継ぎを契約の対象に含めます。障害対応についても、責任の範囲を契約で定めます。自社の担当者が将来変更できる状態までを納品条件にすると、長期費用を抑えやすくなります。

CloudとOn-Premisesは途中で変更できますか？

移行はできますが、計画を立てて進める必要があります。設定や成果物、Agentの構成を確認し、ネットワークや認証の設定、保存データ、契約条件も見ます。

CloudとセルフホストAgent、On-Premises ServerとクラウドAgentを組み合わせる構成もあります。設定をコード化し、特定サーバーだけの手作業を減らすと、将来の変更に備えられます。

TeamCityのシステム開発完全ガイドまとめ

TeamCityは、ビルドからテスト、成果物作成、配備までを自動化する基盤で、安全なリリースを支えます。導入では、まず現状を棚卸しし、PoCで効果を測りながら段階的に広げます。

導入判断で押さえるポイント

運用負担を減らしたいならCloud、閉域網やデータ管理を重視するならOn-Premisesを起点に比べます。

料金は、コミッター数やAgent数に加えて、3年・5年のTCOで確かめます。TCOには、ビルド時間や成果物のほか、インフラや更新、保守の費用も入ります。

構築費は、PoCの50万〜150万円から、大規模移行の500万〜1,500万円以上まで幅があります。対象の範囲を分けて見積もります。

次に行うこと

まず、リポジトリ数とビルド回数、同時実行数を一覧にします。平均時間やテストに加えて、成果物や配備先も書き出します。秘密情報と運用者も加えます。

その情報をもとに、代表サービスのPoC条件と、会社やベンダーに確認する質問をそろえます。構築だけでなく、運用の引き継ぎも計画に入れます。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。