TeamCityのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

TeamCityのシステム開発は、ソースコードの変更を起点にビルド・テスト・成果物作成・デプロイを自動化するCI/CD基盤を、要件整理から定着まで段階的に設計する進め方が基本です。

「TeamCityを導入したいものの、CloudとOn-Premisesのどちらを選ぶべきか分からない」「既存のJenkinsや手作業のリリースをどの範囲で移行すればよいか迷っている」という方に向けて、実務で使える6つのフェーズ、費用相場、見積もりの確認項目、失敗を防ぐチェックポイントを解説します。単にビルドを動かすだけでなく、セキュリティ、運用担当者への引き継ぎ、開発チームへの定着まで見通せる構成です。

▼全体ガイドの記事
・TeamCityのシステム開発の完全ガイド

TeamCityのシステムの全体像とは？

結論から言うと、TeamCityは受注や在庫を管理する業務アプリケーションではなく、開発・テスト・リリースの流れを標準化するソフトウェア開発の業務基盤です。まず何を自動化し、誰が承認し、どの環境へ、どの証跡を残して配備するのかを決めてから、製品の設定に入る必要があります。

TeamCity Serverはプロジェクト、ビルド構成、権限、履歴を管理し、Build Agentは実際のコンパイル、テスト、パッケージ作成を実行します。GitHub、GitLab、Bitbucket、PerforceなどのVCSから変更を取得し、成果物をArtifactとして保管し、ビルドチェーンで「ビルド完了後に統合テスト、その後にステージング配備」という依存関係を表現します。ServerとAgentを同一のマシンに詰め込むと、管理情報と実行環境の権限が近づくため、本番用途では原則として分離を検討します。

TeamCity CloudはJetBrainsがServerを運用するため、サーバーのインストール、アップデート、可用性対策の負担を減らしやすい方式です。一方、On-Premisesは自社または委託先がServer、データベース、ネットワーク、バックアップ、更新を管理するため、閉域網、データ所在地、独自の認証や運用統制を細かく設計できます。Cloudでも自社クラウドや社内ネットワークのセルフホストAgentを接続できるため、機密コードを実行環境に残したい場合はハイブリッド構成も候補になります。

選定時は「Cloudなら全て安全」「On-Premisesなら全て自由」と単純化しないことが重要です。Cloudではコミッター数、ビルド時間、Build Credits、ストレージ、データ転送量を確認し、On-PremisesではAgent数、同時実行数、保守担当者、脆弱性対応時間を確認します。2026年7月にはOn-Premisesの全バージョンを対象とするCVE-2026-63077が公表され、2025.11.7または2026.1.3への更新が推奨されました（出典: JetBrains TeamCity公式セキュリティ告知、2026年）。方式選定は初期構築だけでなく、更新を続けられる体制まで含めて判断します。

TeamCityのシステム開発の進め方は？6つのフェーズで解説します

TeamCityの導入は、要件整理、方式選定、設計・開発、テスト、稼働、定着の6フェーズに分けると、抜け漏れを発見しやすくなります。小さなPoCで代表的なサービスを通してから標準化し、段階的に対象を増やす進め方が、全社一斉移行よりもリスクを抑えやすい方法です。

最初に、リポジトリ数、対象言語、ビルドツール、テストの種類、成果物、デプロイ先、1日のビルド回数、ピーク時の同時実行数を棚卸しします。現行ジョブをそのまま移すのではなく、手動承認、環境変数の設定、成果物の受け渡し、失敗時の再実行などを一つずつ洗い出します。成功指標は「ビルドを作れた」だけでなく、平均ビルド時間、Agent待ち時間、失敗率、失敗からの復旧時間、リリース頻度に置くと効果を評価しやすいです。

要件整理のチェックリストとして、少なくとも「誰がコミットするか」「どのブランチを対象にするか」「どのテストを必須にするか」「どの段階で人が承認するか」「ログと成果物を何日保存するか」「本番障害時に誰が止めるか」を決めます。個人情報や顧客データをテストに使う場合は、マスキング、アクセス権限、保存場所、削除期限も要件に含めます。

方式選定では、機密コードや閉域網を扱うか、サーバーを運用する担当者がいるか、独自プラグインが必要か、ピーク時に何本を並列実行したいかを軸にします。運用負担を小さくし、標準的なGit・Docker・クラウド連携を早く始めたい場合はCloudが候補です。データ所在地、ネットワーク分離、独自の監査要件、既存オンプレ基盤との密接な連携を優先する場合はOn-Premisesが候補になります。

Agent数は開発者数と同じではありません。例えば、1本のビルドが長時間かかり、朝のコミットが集中するチームでは、開発者が10人でもAgentを3台から増やす意味があります。反対に、ビルドが短く、夜間実行が中心なら、Agentを増やすよりキャッシュ、テストの分割、不要なトリガーの整理が有効です。実測するため、Enterpriseの試用や小規模PoCで待ち時間と同時実行数を記録します。

設計では、プロジェクト、ビルド構成、ビルドチェーン、Agentプール、権限、VCS接続、Artifact保持期間、通知ルールを定義します。画面上の設定を担当者の記憶に残さないため、Kotlin DSLやYAMLベースのPipelinesなど、バージョン管理できる設定を優先します。命名規則、ブランチ戦略、共通テンプレートを先に決めると、サービスが増えたときのパイプライン増殖を抑えられます。

実装では、コミット、単体テスト、静的解析、成果物作成、統合テスト、ステージング配備を一つの流れとして作ります。Productionへのデプロイだけは最初から完全自動にせず、承認者、変更チケット、ロールバック手順を設定する方法も有効です。資格情報はリポジトリ、設定ファイル、環境変数、ビルドログへ直書きせず、TeamCityのパスワード型パラメータやVaultなどの秘密情報管理を使います。

テストは正常系だけでなく、VCS接続失敗、テスト失敗、Agent不足、成果物の破損、デプロイ先の停止、権限不足、ネットワーク断を意図的に起こします。各ケースで、失敗が誰に通知され、どのログを見れば原因を絞り込め、何分以内に再実行またはロールバックできるかを確認します。CI/CD基盤では「成功したビルド」よりも「失敗したビルドを安全に扱えること」が運用品質を左右します。

移行テストでは、旧環境とTeamCityで同じコミットをビルドし、生成物のハッシュ、テスト結果、デプロイ結果を比較します。特に時刻、OS、JavaやNode.jsなどのランタイム、キャッシュ、外部サービスのテストデータが違うと、同じコードでも結果が変わります。テスト計画書には、受け入れ条件、テストデータ、担当者、証跡の保存場所、未解決の既知問題を記録します。

稼働開始は、重要度の低いサービスを先行させ、成功パターンをテンプレート化して対象を増やす段階展開が安全です。切り替え前に、旧ジョブの停止日時、TeamCityの利用開始日時、連絡先、リリース凍結の有無、旧環境へ戻す条件を共有します。初週はビルド成功率、失敗理由、Agent待ち時間、実行時間、通知の見落としを毎日確認し、設定の不備を早めに修正します。

On-Premisesでは、Serverのバックアップと復元、データベース、HTTPS、監視、ログの保管、アップデート手順を稼働条件に含めます。JetBrainsの公式セキュリティノートでも、ServerとAgentの分離、最小権限、HTTPS、秘密情報の外部管理、使い捨てに近いAgent、定期更新が推奨されています（出典: JetBrains「Security Notes | TeamCity On-Premises Documentation」、2026年版）。Cloudでも、セルフホストAgent、VCSトークン、デプロイ先の権限は利用企業の責任として残ります。

定着フェーズでは、パイプラインを作れる人を増やすだけでなく、壊れたときに直せる人を増やします。開発者向けにブランチとビルドの使い方、運用者向けにAgent追加、ログ調査、権限変更、バックアップ復元、セキュリティ更新を教育し、操作手順をWikiやリポジトリに残します。属人的な「詳しい人に聞く」を避けるため、問い合わせ窓口、一次切り分け、エスカレーション先、対応時間を決めます。

月次または四半期ごとに、ビルド失敗の上位原因、平均復旧時間、Agentの稼働率、待ち時間、不要なビルド構成、古いプラグイン、未使用の資格情報を見直します。2026.1ではTeamCity CLIやMCP、AI Assistantなど、ビルド調査やパイプライン操作を支援する機能が追加されています（出典: JetBrains「TeamCity 2026.1」、2026年）。便利な機能ほど、読み取り専用から試し、対象プロジェクトを限定し、実行操作には人の承認を挟む運用から始めることが重要です。

TeamCityのシステム開発にかかる費用相場と内訳

TeamCityの費用は、JetBrainsへのライセンス費、ServerやAgentを動かすインフラ費、導入・移行を支援する構築費、導入後の保守費に分けて考えます。製品価格だけを見て安いと判断すると、既存ジョブの移行、テスト自動化、秘密情報管理、教育、クラウド実行費が後から膨らみやすいため、1年目・3年目・5年目の総保有コストで比較します。

2026年8月に確認したJetBrains公式購入ページでは、On-Premises Professionalは無料で、3 Build Agentと100 Build Configurationが含まれます。Enterpriseは年額2,399ドル、追加Build Agentは1台あたり年額359ドルです。Cloudは最低3コミッターで、年額540ドルの表示があり、Build Credits、ストレージ、データ転送の利用条件も関係します（出典: JetBrains「Buy TeamCity」、2026年8月確認）。為替、税、契約条件で円換算は変わるため、概算ではドル表示を円に置き換えた幅として扱い、最終的には公式見積もりを再確認します。

日本円の過去の公式価格表では、2025年1月13日開始の価格としてCloudが年額25,200円／コミッター、On-Premises Enterprise Serverが新規335,860円、追加Agentが新規50,260円と掲載されていました（出典: JetBrains「JPY price 2025 TeamCity」、2025年）。ただし、現在の価格や更新条件を保証するものではありません。また、2025年11月3日以降の新規On-Premisesライセンスは、従来の更新割引の扱いが変わる方針も示されているため、既存ライセンスと新規追加分を分けて確認します。

TeamCity固有の受託開発費を示す公的な日本市場統計は確認できないため、以下はリサーチノートに記載したシステム開発の人月単価と作業範囲から算出する参考レンジです。1リポジトリでGit連携、数本のビルド、単体テスト、権限設定だけを行う小規模PoCは、50万〜150万円程度、期間は2〜6週間が目安になります。価格は要件、既存環境、支援範囲で変わるため、固定料金として断定しません。

複数リポジトリ、10〜30本程度のビルド構成、Dockerやクラウド連携、成果物保管、通知、運用手順まで含む標準導入は、150万〜500万円程度、1〜3か月が参考になります。Jenkinsなどから数十〜数百のビルドを移行し、SSO、監査、冗長化、IaC、教育まで含める中〜大規模移行は、500万〜1,500万円以上、3〜9か月程度のレンジを置くことがあります。Kubernetes、複数クラウド、セキュリティ検査、内製化支援まで含める場合は、1,000万〜3,000万円以上になる可能性があります。

導入後は、ライセンス更新だけでなく、ServerとAgentのOS更新、TeamCityのアップデート、プラグイン検証、バックアップ、失敗ビルド調査、パイプライン改善、クラウドAgentの実行料金が発生します。類似する業務システム保守の目安として、初期構築費の年15〜25％程度を保守費の起点に置く方法がありますが、24時間対応、SLA、月次改善の有無で大きく変わります。保守費とクラウド費を一つの定額にせず、固定費と従量費を分けて確認します。

費用を抑えるには、最初から全サービスを移行せず、代表的な1〜2サービスで効果を測定します。ビルド時間が長い原因をテストの分割やキャッシュで改善できる場合、Agentを増やす費用を減らせます。反対に、Agent待ち時間が業務を止めている場合は、追加Agentや自動スケールの費用を投資対効果で比較します。

TeamCityの見積もりを取る際のポイント

見積もりの精度を上げるには、「TeamCityを構築する」という一言を、要件定義、方式設計、標準化、移行、テスト、稼働支援、教育、保守に分解して依頼します。ベンダーが同じ言葉で見積もっているように見えても、ビルド構成の本数、テストの自動化範囲、デプロイの責任、運用引き継ぎの深さが違えば、金額を比較できません。

依頼時には、リポジトリ一覧、利用言語とバージョン、現在のCIツール、既存ジョブ数、平均ビルド時間、1日の実行回数、ピークの同時実行数、テストの種類、成果物の保管先、デプロイ先、ネットワーク制約を渡します。さらに、CloudとOn-Premisesの希望、SSOやSAMLの要否、Vaultなどの秘密情報管理、Agentの配置、バックアップ方針、監査ログの保存期間を明示します。

成果物には、構成図、ビルド構成一覧、命名規則、権限一覧、移行対象と対象外、テスト計画、操作手順、教育計画、運用開始後の問い合わせ窓口を含めます。受け入れ条件は「全て移行」ではなく、「指定したリポジトリでコミットからテストまでが成功する」「失敗時に担当者へ通知される」「本番デプロイには承認が必要」「旧環境へ戻せる」など、確認可能な文にします。

比較する会社には、同じ対象リポジトリ、同じビルド本数、同じAgent数、同じCloud・On-Premises条件を提示します。確認したいのはTeamCityの設定経験だけでなく、Jenkinsなどからの移行、Git・Docker・Kubernetes・AWSとの連携、SSO、Vault、IaC、監査、24時間対応、内製化支援の実績です。TeamCityの公開実績が見当たらない会社は、CI/CD一般の経験とTeamCity固有の経験を分けて説明してもらいます。

提案デモでは、コミットからテスト、Artifact生成、ステージング配備、失敗通知、承認、再実行までを一つのシナリオで見ます。画面がきれいかより、失敗原因を誰がどのログで調べるか、設定をコードレビューできるか、権限をプロジェクト単位で分けられるか、Agent不足時にどうスケールするかを質問します。

TeamCity ServerにはVCSの資格情報、クラウドのトークン、署名鍵、デプロイ権限が集まりやすいため、権限設計をオプション扱いにしないことが重要です。誰がトークンを発行・更新・失効するか、秘密情報をどこに保管するか、AgentのOS権限をどう制限するか、ログに秘密が出ないことをどう確認するかを見積項目に含めます。外部委託では、TeamCity設定、Kotlin DSLやYAML、IaC、スクリプト、テストコード、手順書の帰属と引き渡しも契約に記載します。

脆弱性が公開された場合の初動も確認します。JetBrainsは2026年7月のCVE-2026-63077について、On-Premisesを2025.11.7または2026.1.3へ更新するよう案内し、インターネットからのアクセスをVPNなどで制限する長期対策も推奨しています（出典: JetBrains「CVE-2026-63077」、2026年）。見積書に「保守一式」とだけ書かれている場合は、緊急パッチ、休日対応、影響調査、復旧訓練が含まれるかを確認します。

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

ここでは、TeamCityを導入する企業から特に相談されやすい疑問に回答します。判断に迷った場合は、製品機能だけでなく、チームの運用能力、既存環境、セキュリティ要件、将来の変更頻度を基準に考えます。

運用負担を減らして早く始めたい場合はCloud、閉域網やデータ所在地、独自の統制を優先する場合はOn-Premisesが基本的な判断軸です。ただし、CloudにセルフホストAgentを接続するハイブリッド構成もあるため、機密コードの実行場所とServerの管理主体を分けて検討します。

必要台数は開発者数ではなく、ピーク時の同時実行数とビルドの待ち時間で決めます。まず既存の実行時間と時間帯別のキューを測定し、テストの分割やキャッシュで短縮できるかを確認したうえで、待ち時間が許容値を超える場合に追加Agentや自動スケールを比較します。

1リポジトリの小規模なPoCや、単純なビルドであれば自社で始められる可能性があります。一方、既存CI/CDから多数のジョブを移行する場合、デプロイ権限、テストデータ、監査、失敗時の復旧まで設計する必要があるため、最初の設計と標準化だけ外部支援を受け、運用は自社へ引き継ぐ方法も現実的です。

最初から自動実行まで任せる必要はありません。TeamCity 2026.1のCLIやMCPはビルド状態やログの調査を支援できますが、ビルド再実行、設定変更、デプロイを許すトークンには強い権限が含まれる可能性があります。まず読み取り専用の調査に限定し、対象プロジェクト、ログの外部送信、承認者、監査記録を定義してから段階的に広げます。

まとめ

TeamCityを導入するときは、機能の多さよりも、導入後も安全に改善を続けられる設計になっているかを確認します。ここまでの要点を、これから着手する担当者が使える判断材料にまとめます。

TeamCity導入の成否を分けるのは、製品の設定量よりも、対象範囲と成功指標を先に決めることです。要件整理でビルド、テスト、デプロイ、権限、証跡を具体化し、PoCでAgent待ち時間と失敗時の復旧を測定してから、標準テンプレートを横展開します。

最初の一歩は、リポジトリ一覧、既存ジョブ一覧、ビルド時間、同時実行数、デプロイ先、秘密情報の種類、運用担当者を1枚にまとめることです。その資料をもとに、代表サービスを1〜2件選び、Cloud・On-Premisesの候補、移行範囲、費用の内訳、受け入れ条件を複数社へ同じ前提で提示すると、比較可能な提案を得やすくなります。

TeamCityのシステム開発は、製品をインストールして終わる作業ではなく、開発プロセスを継続的に改善する基盤づくりです。要件整理でリポジトリ、ビルド、テスト、成果物、デプロイ、権限、成功指標を明確にし、Cloud・On-Premises・ハイブリッドを運用体制とセキュリティ要件で選びます。

進め方は、要件整理、選定、設計・開発、テスト、稼働、定着の6フェーズに分け、小さなPoCから段階的に展開します。費用はライセンス、Agent、インフラ、移行、テスト、教育、保守を分けて見積もり、50万〜150万円程度のPoC、150万〜500万円程度の標準導入、500万〜1,500万円以上の大規模移行という参考レンジを、自社の対象本数と作業範囲に照らして評価します。

最後に、TeamCity ServerとAgentの分離、秘密情報の外部管理、最小権限、バックアップ、定期更新、脆弱性発生時の責任分界を、導入後の運用として最初から設計します。判断材料を整理したうえで、自社だけで不足する設計・移行・教育の範囲を切り出すと、過剰な外注や導入後の手戻りを防ぎやすくなります。

▼全体ガイドの記事
・TeamCityのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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