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

TeamCityのシステムとは、ソースコードの変更を起点に、ビルド、テスト、成果物の作成、デプロイまでを自動化するソフトウェア開発・運用の基盤です。受注や在庫を管理する業務アプリケーションではなく、開発品質とリリース速度を継続的に高める仕組みとして導入されます。

本記事では、TeamCityの全体像、構成要素、CloudとOn-Premisesの違い、導入の進め方、2026年時点の料金、構築費の相場、セキュリティ、開発会社やベンダーの選び方までを一つにまとめます。初めて検討する担当者でも、社内稟議や発注時に必要な条件を整理できるよう、判断基準を具体的に解説します。

TeamCityのシステムとは何ですか？

TeamCityは、継続的インテグレーションと継続的デリバリーを支えるCI/CDサーバーです。開発者がリポジトリへ変更を登録すると、あらかじめ定義した処理を実行し、結果を一元管理します。導入効果を正しく評価するには、製品の機能だけでなく、現在の開発工程のどこを自動化し、誰が運用するかまで含めて考えることが重要です。

開発工程のどこを自動化する仕組みですか？

TeamCityは、ソースコードを取得して依存ライブラリを解決し、コンパイル、単体テスト、静的解析、パッケージ作成を順番に実行します。テスト結果やログを保存できるため、失敗した変更を早期に発見し、原因を担当者が追跡しやすくなります。さらに、承認を挟んだステージング環境への配備、本番リリース、成果物の保存までをビルドチェーンとしてつなげられます。

たとえば、これまで担当者が手作業で実行していた「ビルド用コマンドの実行」「テスト結果の確認」「成果物のサーバー転送」を自動化できます。自動化の目的は単に作業時間を短くすることではなく、同じ条件で繰り返し検証し、リリースの品質を安定させることです。

主な構成要素は何ですか？

中心になるのは、設定や結果を管理するTeamCity Serverと、実際の処理を実行するBuild Agentです。Serverはプロジェクト、ビルド構成、権限、通知、履歴を管理し、Agentは指定されたOSやツールが入った実行環境でビルドを動かします。両者を分離することで、管理画面と実行処理の責任範囲を分けやすくなります。

このほか、ソースコードと接続するVCS設定、複数処理の依存関係を表すビルドチェーン、テスト結果と成果物を保管する領域、認証・権限、監査ログが必要です。複数OSでの並列実行、コンテナやクラウド上のAgent、REST API、Kotlin DSLやYAMLによる設定のコード化も、規模が大きくなるほど重要になります。

TeamCity CloudとOn-Premisesはどちらが適していますか？

結論として、サーバーの保守や初期構築を減らして早く始めたい場合はCloud、閉域網やデータ管理、実行環境を自社で細かく制御したい場合はOn-Premisesが候補です。ただし、Cloudでも自社ネットワーク内や自社クラウドのセルフホストAgentを接続できます。二者択一ではなく、管理サーバーと実行環境を分けたハイブリッド構成も検討できます。

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

Cloudは、管理サーバーの設置、データベースの保守、アップデート、障害対応の多くをサービス側に任せられます。小さなチームや、CI/CD担当者が少ない組織では、環境構築よりパイプライン改善に時間を使える点がメリットです。需要が増えたときにクラウドAgentを追加しやすく、ビルドの待ち時間を短縮しやすい点も特徴です。

一方で、料金はコミッター数だけで決まらず、ビルド時間、ストレージ、データ転送などの利用量も確認が必要です。テストデータやログに機密情報が混入しない仕組み、接続元の制限、セルフホストAgentの更新責任も残ります。Cloudを選べば運用責任がゼロになるわけではなく、リポジトリ権限やデプロイ先の管理は自社で継続します。

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

On-Premisesは、Server、データベース、Agent、ネットワーク、バックアップ、更新を自社または委託先が管理します。閉域網で開発する場合、保管場所やアクセス経路を自社ポリシーに合わせる場合、特殊なツールや社内認証と深く連携する場合に適しています。AgentのスペックやOSを用途別に固定し、安定した再現環境を作りやすいことも利点です。

ただし、サーバーの冗長化、容量計画、脆弱性対応、プラグイン検証、障害時の復旧訓練まで運用範囲が広がります。公式価格ページではProfessionalが無料で、3台のBuild Agentと100件のビルド構成が含まれます。Enterpriseは年額2,399ドル、追加Agentは1台あたり年額359ドルと表示されています（出典: TeamCity公式購入ページ、2026年8月確認）。税や為替、インフラ費、構築費は別途見積もる必要があります。

TeamCityのシステム開発・導入はどのように進めますか？

導入は、現在のジョブをすべて移す作業から始めないことが重要です。リポジトリ、言語、テスト、成果物、デプロイ先、秘密情報、承認手順を棚卸しし、代表的なサービスで小さく検証します。成功条件を先に定めておくと、導入後に「便利になった気がする」という曖昧な評価を避けられます。

現状調査と要件整理を行います

最初に、リポジトリ数、主要言語、ビルドツール、1日のビルド回数、同時実行数、平均ビルド時間、失敗率、テスト種別を記録します。続いて、成果物をどこへ保管するか、どの環境へ誰の承認で配備するか、失敗時に誰が復旧するかを確認します。ここで「毎回手動で行っている確認」と「自動化してはいけない承認」を分けることがポイントです。

成果物やビルドログに顧客情報、個人情報、秘密鍵が含まれる可能性も確認します。データの保存期間、閲覧者、削除方法、外部サービスへの転送可否を決めてから構成を選ぶと、後から作り直すリスクを抑えられます。

PoCで代表的なサービスを通します

PoCでは、1〜2個の代表的なリポジトリを選び、コミットからテスト、成果物作成、ステージング配備までを一続きにします。複雑な案件ほど、最も簡単なサンプルだけではなく、依存関係が多いサービス、テストが遅いサービス、複数環境へ配備するサービスを1つ含めると実運用に近い検証になります。

評価指標には、ビルド時間、Agentの待ち時間、失敗率、失敗からの復旧時間、リリース頻度、手作業の削減時間を置きます。たとえば、平均待ち時間を半分にする、失敗原因の特定を30分以内にするなど、導入前後で比較できる数値にします。PoCで権限、秘密情報、ログのマスキングまで検証しておくと、本番移行が安全になります。

コード化・段階移行・引き継ぎを行います

本番展開では、プロジェクト名、命名規則、ブランチ戦略、権限、成果物の保持期間、ログの保持期間を標準化します。画面上だけで設定を増やすと、担当者が変わったときに再現できません。Kotlin DSL、YAMLベースのPipelines、テンプレートなどで設定をバージョン管理し、変更をレビューできる状態にします。

移行は、重要度の低いサービスから始め、テンプレートと運用手順を改善しながら対象を広げます。全社一斉移行は、資格情報の失効、Agent不足、依存ジョブの漏れ、デプロイ停止を招きやすいためです。最後に、日次確認、失敗ビルドの一次切り分け、バックアップ、更新、障害連絡、復旧訓練の担当者と期限を決め、内製チームへ引き継ぎます。

TeamCityのシステム開発費用・料金相場はいくらですか？

費用は、ライセンスまたはクラウド利用料、サーバーやAgentのインフラ費、設計・構築費、既存環境からの移行費、保守運用費に分けて考えます。TeamCity単体の価格だけを見ると、Agent数やビルド量が増えたときの待ち時間、ストレージ、更新、障害対応の費用を見落とします。初年度だけでなく、3年・5年の総保有コストを比較することが大切です。

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

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

2026年8月時点の公式購入ページでは、On-Premises Professionalは無料で、3台のBuild Agentと100件のビルド構成が含まれます。Enterpriseは年額2,399ドル、追加Build Agentは1台あたり年額359ドルです。Cloudはコミッター1人あたり月額15ドルで、最低3人から始まり、年払いでは最低年額540ドルと表示されています（出典: TeamCity公式購入ページ、2026年8月確認）。料金は税、為替、契約条件で変わるため、発注前に最新の見積を取得します。

Cloudには月間のBuild Creditsが含まれ、公式ページでは最低プランに月24,000クレジット、ストレージ120GB、月600GBのデータ転送が含まれると案内されています。追加25,000クレジットは20ドルです（出典: TeamCity公式購入ページ、2026年8月確認）。コミッター数が少なくても、重いテストや大量の成果物を扱えば利用量が増えるため、過去のビルド時間と成果物容量を使って試算します。

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

TeamCity固有の日本市場の受託構築費を示す公的統計はありません。そのため、以下は業務システムの人月単価とCI/CDの作業範囲から算出した参考レンジです。要件、既存ジョブの品質、対象リポジトリ数、セキュリティ要件、教育の有無によって大きく変動します。

1リポジトリで1〜3本のビルド、Git連携、単体テスト、権限設定を行う小規模PoCは、50万〜150万円、期間は2〜6週間が目安です。複数リポジトリ、10〜30本のビルド構成、コンテナやクラウド連携、成果物保管、通知、運用手順を含む標準導入は、150万〜500万円、1〜3か月程度が参考になります。

既存CI/CDから数十〜数百のビルドを移行し、複数環境、SSO、監査、冗長化、IaC、教育まで行う中〜大規模移行は、500万〜1,500万円以上、3〜9か月程度です。Kubernetesや複数クラウド、セキュリティ検査、デプロイ自動化、内製化支援まで含める場合は、1,000万〜3,000万円以上になる可能性があります。これらはTeamCity本体の開発費ではなく、周辺の開発基盤を設計・構築する費用です。

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

運用費には、ServerやAgentのインフラ、クラウド実行料金、ストレージ、バックアップ、ライセンス更新、監視、脆弱性対応、OS更新、プラグイン検証、失敗ビルドの調査が含まれます。構築後もビルド構成は増えるため、初期費用だけで比較すると実際の負担とずれます。類似する業務システムの保守目安として、初期構築費の年15〜25％程度を置くことがありますが、TeamCityの運用量に応じて再見積もりが必要です。

さらに、2025年11月3日以降に購入する新規On-Premisesライセンスは、従来の50％更新割引の対象外と案内されています。購入前の既存ライセンスは期限内の更新条件を満たせば割引対象ですが、2026年に追加するライセンスと更新単価が混在する可能性があります（出典: TeamCity公式ブログ「On-Premises更新価格の変更」、2025年）。見積書では、要件定義、設計、構築、移行、テスト、教育、保守、ライセンス、インフラを分けて記載します。

TeamCityの開発会社・ベンダーはどのように選びますか？

TeamCityのシステム開発を外注するときは、製品の販売窓口だけでなく、CI/CDの設計、既存ジョブの移行、テスト自動化、セキュリティ、運用引き継ぎまで支援できるかを確認します。「TeamCityを使える」という説明だけでは、実際の構築品質や障害対応力を判断できません。自社の要件に近い実績と、担当者の役割分担を確認することが重要です。

TeamCityとCI/CD移行の実績を確認します

実績を聞くときは、単に導入社数を尋ねるのではなく、構成と成果を確認します。たとえば、CloudかOn-Premisesか、Agentの台数、対象リポジトリ数、移行元、SSO、秘密情報管理、コンテナ、Kubernetes、IaC、デプロイ先、運用期間を質問します。公開できない案件でも、匿名化した構成図や移行手順、障害対応の例を説明できるかで経験の深さを見極められます。

また、TeamCity本体を新しく開発する案件なのか、TeamCityを中心にCI/CD基盤を構築する案件なのかを明確にします。通常は後者であり、必要に応じてプラグイン、スクリプト、社内ポータル、監査連携を追加開発します。この区別が曖昧だと、見積範囲と完成物の認識が食い違います。

見積と提案の比較条件をそろえます

複数の候補から比較するときは、同じ要件書を渡し、少なくともPoC、設計、構築、移行、テスト、教育、保守を分けた見積を依頼します。安い提案でも、既存ジョブの整理、秘密情報の移行、バックアップ、復旧訓練が抜けていれば、後から追加費用が発生します。逆に、すべてを一括計上した提案は、どこを削減できるか検討しにくくなります。

提案書では、前提条件、対象外、納品物、検収基準、変更管理、障害時の連絡時間、脆弱性の報告期限、ライセンスと秘密情報の責任分界を確認します。設定ファイル、Kotlin DSLやYAML、IaC、スクリプト、テストコード、運用手順の著作権・再利用権も契約で明確にします。担当者が交代しても運用できる教育と引き継ぎが含まれているかも重要です。

保守体制と内製化支援を確認します

CI/CDは一度作って終わりではありません。開発言語、テストツール、コンテナイメージ、OS、認証方式が変わるたびにパイプラインの保守が必要です。平日営業時間だけでよいのか、夜間や休日の障害対応が必要なのか、一次切り分けと復旧を誰が担当するのかをSLAに落とし込みます。

外注先へ依存しすぎると、簡単なビルド構成の変更にも時間と費用がかかります。定例レビュー、設定の読み方、失敗ログの調べ方、Agent追加の手順、アップデートの検証方法を社内担当者へ移管してもらい、段階的に内製化できる計画を組みます。

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

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

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

TeamCityのセキュリティと運用で注意することは何ですか？

TeamCityにはリポジトリの資格情報、クラウドのトークン、署名鍵、デプロイ権限が集まりやすいため、開発サーバーとしてだけでなく重要な認証基盤として扱います。管理画面とAgentを同じ権限・同じネットワークに置かず、最小権限、アクセス制御、監査、バックアップ、更新手順を設計段階から組み込みます。

秘密情報とアクセス権を分離します

パスワードやトークンをリポジトリ、設定ファイル、環境変数、ビルドログへ直接書き込まないことが基本です。秘密情報管理サービスや短期トークンを使い、ビルドごとに必要な権限だけを付与します。ログにコマンドライン引数や環境変数が出力されない設定、成果物のダウンロード権限、デプロイ先の変更権限も別々に確認します。

管理者、開発者、閲覧者、Agentの実行ユーザーを分け、SSOや多要素認証、監査ログを有効にします。インターネットへ公開する場合は、VPNや追加のアクセス制御を検討し、ServerをAgentと別ホストに配置します。バックアップは取得するだけでなく、復元できるかを定期的に訓練することが必要です。

脆弱性対応とAI連携を運用に組み込みます

2026年7月には、On-Premisesの全バージョンに影響するCVE-2026-63077が公表され、認証を回避してOSコマンドを実行される可能性が示されました。修正版は2025.11.7と2026.1.3で、更新できない場合のパッチプラグインも案内されています。Cloudはこの脆弱性への対応が不要とされていますが、セルフホストAgent、リポジトリ、デプロイ先の権限管理は引き続き必要です（出典: TeamCity公式セキュリティ告知、2026年7月）。

2026.1ではCLI、MCP、AI Assistant、Pipelinesの機能が拡張され、AIがビルド状態やログを調べたり、パイプライン操作を支援したりする方向が示されています。便利な反面、強いトークンをAIへ渡すと、ビルド実行、成果物取得、デプロイまで可能になる場合があります。最初は読み取り専用、対象プロジェクト限定、人の承認を必須にする運用から始め、秘密情報や顧客データを外部AIへ送らない規則を定めます（出典: TeamCity 2026.1公式リリース記事、2026年5月）。

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

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で確認します。構築費はPoCの50万〜150万円から、大規模移行の500万〜1,500万円以上まで幅があるため、対象範囲を分解して見積を取得します。

次に行うこと

まず、リポジトリ数、ビルド回数、同時実行数、平均時間、テスト、成果物、デプロイ先、秘密情報、運用者を一覧にします。その情報をもとに代表的なサービスのPoC条件と、開発会社やベンダーへ確認する質問をそろえます。TeamCityは導入後の標準化と更新が成否を左右するため、構築だけでなく運用引き継ぎまで含めて計画することが大切です。