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

TeamCityのシステム開発は、要件整理に始まり、稼働と定着へと続く6つの段階で進めます。この流れに沿うと、安全なCI/CD基盤の構築につながります。

全体像については、TeamCityのシステム開発の完全ガイドもあわせてご覧ください。

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

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

TeamCityのシステムの全体像

TeamCityは、開発・テスト・リリースの流れを標準化するソフトウェア開発の業務基盤です。受注や在庫を管理する業務アプリケーションとは、役割が異なります。

製品の設定に入る前に、自動化の対象、承認者、配備先、残す証跡を決めておきます。発注側と開発会社がこの4点を共有しておくと、設定の打ち合わせが進めやすくなります。

Server・Agent・VCSの役割の分け方

TeamCityの構成要素は、それぞれ役割が異なります。そのため、管理機能、実行環境、変更取得、成果物保管を分けて把握します。

• Server：プロジェクト、ビルド構成、権限、履歴を管理する役割です。
• Build Agent：コンパイル、テスト、パッケージ作成を実行します。
• VCS・Artifact：GitHub、GitLab、Bitbucket、Perforceなどから変更を取得し、成果物の保管先になります。
• ビルドチェーン：ビルド、統合テスト、ステージング配備などの依存関係を表します。

本番で使う場合は、ServerとAgentを分けて置くことを検討します。同じマシンに置くと、管理情報と実行環境の権限が近づくためです。

CloudとOn-Premisesの違い

方式が変わると、運用を任せられる範囲と自社で設計する範囲も変わります。

• Cloud：Server運用をJetBrainsに任せるため、保守の負担を減らしやすい方式です。
• On-Premises：自社または委託先が運用し、ネットワークや認証を細かく設計できます。
• ハイブリッド：Cloudに、自社クラウドや社内ネットワークのセルフホストAgentを接続する構成です。

Cloudを選ぶ場合でも、機密コードを実行環境に残したいときは、ハイブリッド構成が候補になります。

Cloudでは、コミッター数とビルド時間を見ます。Build Credits、ストレージ、データ転送量も関係します。

一方、On-PremisesではAgent数と同時実行数を見ます。保守担当者と脆弱性への対応時間も、あわせて見ておきます。

「Cloudなら全て安全」「On-Premisesなら全て自由」と単純には言えません。方式を選ぶときは、更新を続けられる体制も含めて判断します。

2026年7月には、On-Premisesの全バージョンを対象とするCVE-2026-63077が公表されました。このとき、2025.11.7または2026.1.3への更新が推奨されました（出典：JetBrains TeamCity公式セキュリティ告知、2026年）。

TeamCityのシステム開発の進め方と6つのフェーズ

6つのフェーズに分けると、導入時の抜け漏れを見つけやすくなります。まず小さなPoCで代表的なサービスを試し、標準化してから対象を増やします。全社一斉の移行より、リスクを抑えられます。

1. 要件整理：自動化の対象と成功指標

要件整理では、導入後に改善を評価できるよう、現状を具体的に洗い出します。

• 対象：リポジトリ数、言語、ビルドツール、テスト、成果物、デプロイ先。
• 実行量：1日のビルド回数とピーク時の同時実行数。
• 作業：手動承認、環境変数、成果物受け渡し、失敗時の再実行。
• 成功指標：平均ビルド時間、Agent待ち時間、失敗率、復旧時間、リリース頻度。

現行ジョブは、そのまま移すより、各作業を洗い出してから移す内容を決めます。成功指標は、ビルド作成の速さだけでなく、導入効果を評価できる値にします。

要件では、コミットする人と対象ブランチ、必須テスト、人の承認段階を決めます。さらに、ログと成果物の保存日数、本番障害時の停止担当者も要件に含めます。

テストに個人情報や顧客データを使う場合は、マスキングも要件に含めます。加えて、アクセス権限、保存場所、削除期限も定めます。

2. 選定：Cloud・On-PremisesとAgent数の比較

実行待ちを減らしつつ、自社の運用制約にも合う方式と実行能力を選びます。

• Cloud：運用負担を抑え、標準的なGit・Docker・クラウド連携を早く始めたい場合。
• On-Premises：閉域網、データ所在地、独自監査、既存基盤との連携を優先する場合。

選定では、機密コードや閉域網の有無、サーバー運用者を見ます。独自プラグインの必要性と、ピーク時の並列実行数も選定材料です。

Agent数は、開発者数よりもビルドの実行状況で考えます。たとえば、1本のビルドが長時間かかり朝にコミットが集中する場合は、開発者が10人でも、Agentを3台から増やす意味があります。

一方、ビルドが短く夜間の実行が中心なら、Agentを増やすよりも、キャッシュやテスト分割、不要なトリガーの整理が有効です。そのうえで、Enterpriseの試用や小規模PoCで、待ち時間と同時実行数を記録します。

3. 設計・開発：標準テンプレートと安全な連携の構築

サービスを追加した後も設定が属人化しないよう、共通ルールを作っておきます。

• 構成：プロジェクト、ビルド構成、ビルドチェーン、Agentプール。
• 管理：権限、VCS接続、Artifact保持期間、通知ルール。
• 標準化：命名規則、ブランチ戦略、共通テンプレート。

画面での設定を担当者の記憶だけに頼らないよう、Kotlin DSLやYAMLベースのPipelinesなど、バージョン管理できる設定を優先します。また、標準化しておくと、サービスが増えてもパイプラインの増殖を抑えられます。

実装では、コミットから単体テストと静的解析までをつなぎます。そのあとに、成果物作成、統合テスト、ステージング配備へ進む流れを組みます。

Productionへのデプロイは、最初は完全自動にせず、承認者、変更チケット、ロールバック手順を設定する方法もあります。

資格情報は、リポジトリや設定ファイルに直接書かないようにします。環境変数やビルドログにも残さず、TeamCityのパスワード型パラメータやVaultなどで管理します。

4. テスト：失敗時の復旧までの検証

VCS接続やネットワークの異常を、あえて起こして復旧手順を確かめます。

• VCS接続やネットワークの失敗。
• テスト失敗、Agent不足、成果物の破損。
• デプロイ先の停止や権限不足。

各ケースで、通知先、原因を調べるログ、何分以内に再実行またはロールバックできるかを確認します。成功した場合だけでなく、失敗したビルドを安全に扱えるかどうかが、運用品質を左右します。

移行テストでは、旧環境とTeamCityで同じコミットをビルドし、結果を比べます。比べる項目は、生成物のハッシュ、テスト結果、デプロイ結果です。

時刻やOS、JavaやNode.jsなどのランタイムが違うと、同じコードでも結果が変わります。キャッシュや外部サービスのテストデータが違う場合も、結果は変わり得ます。

テスト計画書には、受け入れ条件、テストデータ、担当者を記録します。さらに、証跡の保存場所と未解決の既知問題も書いておきます。

5. 稼働：小さな切り替えと監視

段階的に稼働させるときは、対象の広げ方、切り替えの条件、初週の監視項目をあらかじめ決めておきます。

• 対象の広げ方：重要度の低いサービスから始め、成功パターンをテンプレート化してから対象を広げます。
• 切り替えの条件：旧ジョブの停止日時とTeamCityの利用開始日時、連絡先、リリース凍結の有無、旧環境へ戻す条件を共有します。
• 初週の監視：毎日、成功率と失敗理由を確認し、Agent待ち時間や実行時間、通知の見落としから設定不備を早めに修正します。

対象を段階的に広げるほうが、一斉移行より安全です。

On-Premisesでは、Serverのバックアップと復元、データベースを稼働条件に含めます。さらに、HTTPSと監視、ログ保管、更新手順も条件に加えます。

JetBrainsは、ServerとAgentの分離、最小権限、HTTPSを推奨しています。また、秘密情報の外部管理、使い捨てに近いAgent、定期更新も挙げています（出典：JetBrains「Security Notes | TeamCity On-Premises Documentation」、2026年版）。

Cloudを使う場合も、セルフホストAgentやVCSトークン、デプロイ先の権限は、利用企業の責任として残ります。

6. 定着：運用ルールと改善サイクルの整備

障害時に動ける人を育て、運用手順と定期的な見直しを整えます。

• 教育：開発者にはブランチとビルド、運用者にはAgent追加、ログ調査、権限変更、復元、セキュリティ更新を教えます。
• 運用手順：Wikiやリポジトリに残し、問い合わせ窓口、一次切り分け、エスカレーション先、対応時間を定めておきます。
• 定期改善：月次または四半期ごとに、失敗原因、平均復旧時間、Agent稼働率と待ち時間、不要な構成、古いプラグイン、未使用の資格情報を見直します。

TeamCity 2026.1では、TeamCity CLI、MCP、AI Assistantなどの機能が追加されました。これらの機能は、ビルド調査やパイプライン操作を支援します（出典：JetBrains「TeamCity 2026.1」、2026年）。

便利な機能は、まず読み取り専用で試します。対象プロジェクトを限定し、実行操作には人の承認を挟みます。

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

費用は、ライセンスやインフラ、構築・移行、導入後の保守に分けて捉えます。製品価格だけを見ても、総額は判断できません。

移行やテスト自動化の費用も、総額に含めて考えます。さらに、秘密情報管理、教育、クラウド実行費も含めます。比べるときは、1年目・3年目・5年目の総保有コストで見ます。

コミッター数・Agent数・利用量で変わるライセンス費

ライセンス費は、提供形態ごとの価格と、含まれる枠を確認して比べます。

• On-Premises Professional：無料。3 Build Agentと100 Build Configurationが含まれます。
• Enterprise：年額2,399ドル。追加Build Agentは1台あたり年額359ドルです。
• Cloud：最低3コミッター、年額540ドルと表示されています。
• 2025年のCloud価格：1月13日開始で年額25,200円／コミッターでした。
• 2025年のOn-Premises：On-Premises Enterprise Serverは新規335,860円、追加Agentは新規50,260円でした。

Cloudでは、Build Credits、ストレージ、データ転送量も関係します（出典：JetBrains「Buy TeamCity」、2026年8月確認）。

日本円の過去価格は、JetBrains「JPY price 2025 TeamCity」（2025年）に掲載されています。

円換算は、為替や税、契約条件によって変わります。そのため、ドル表示は概算の幅として扱い、最終的には公式見積もりで再確認します。

ここに挙げた価格は、現在の価格や更新条件を保証するものではありません。また、2025年11月3日以降の新規On-Premisesライセンスは、従来の更新割引の扱いが変わる方針も示されています。

見積もりでは、既存ライセンスと新規追加分を分けて確認します。

構築費の規模と移行本数による違い

TeamCity固有の受託開発費を示す公的な日本市場の統計は確認できません。そのため、次の金額は、リサーチノートのシステム開発人月単価と作業範囲から算出した参考レンジです。

構築費は規模ごとに幅があり、要件、既存環境、支援範囲によって変わります。固定料金とは言い切れません。

• 小規模PoC：50万〜150万円程度、2〜6週間。
• 標準導入：150万〜500万円程度、1〜3か月。
• 中〜大規模移行：500万〜1,500万円以上、3〜9か月程度。
• 拡張支援を含む場合：1,000万〜3,000万円以上になる可能性があります。

小規模PoCは、1リポジトリでGit連携を行い、数本のビルドと単体テスト、権限設定を進めます。

標準導入は、複数リポジトリと10〜30本程度のビルド構成を対象とし、Dockerやクラウド連携、成果物保管も含みます。通知や運用手順も、範囲に入ります。

中〜大規模移行は、Jenkinsなどから数十〜数百のビルドを移す範囲です。SSOや監査、冗長化を含みます。さらに、IaCや教育も範囲に入ります。

Kubernetesや複数クラウド、セキュリティ検査、内製化支援まで含む場合は、拡張支援の参考額になります。

保守・クラウド・改善に分けたランニングコスト

運用費は、次の4項目に分けて見ます。費用を調整するときは、項目ごとに見方を変えて考えます。

• 保守作業：ライセンス更新、Server・AgentのOSやTeamCityの更新、プラグイン検証、バックアップ、失敗ビルド調査、パイプライン改善。
• クラウドAgent：実行料金がかかります。保守費に含めず、固定費と従量費に分けて見ます。
• 移行範囲：費用を抑える進め方として、全サービスを一度に移さず、代表的な1〜2サービスで効果を測ります。
• 実行効率：テスト分割やキャッシュと、追加Agentや自動スケールを、投資対効果で比べます。

類似する業務システムの保守では、初期構築費の年15〜25％程度を保守費の起点とする方法があります。金額は、24時間対応やSLA、月次改善の有無で変わります。

待ち時間が業務を止める場合は、Agentの増設も比較の対象になります。

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

見積もりは、工程と成果物に分けて依頼します。各社の対象範囲をそろえておけば、金額を並べて比較できます。

工程は、要件定義、方式設計、標準化の順に並べます。そのあとに移行、テスト、稼働支援が続き、教育と保守も別の項目として加えます。

見積もりでは、ビルド本数とテスト自動化を確認します。さらに、デプロイ責任と引き継ぎの深さも見ます。

依頼前の現状資料と受け入れ条件

見積もりの差を減らすには、各社と現状や想定範囲の認識を合わせておきます。

• 開発環境：リポジトリ、言語とバージョン、現在のCIツール、既存ジョブ数。
• 実行状況：平均時間、1日の実行回数、ピーク同時実行数、テスト、成果物の保管先。
• 接続条件：デプロイ先、ネットワーク制約、Cloud・On-Premisesの希望。
• 運用要件：SSOやSAML、Vault、Agent配置、バックアップ、監査ログ保存期間。

成果物には、構成図やビルド構成一覧、命名規則、権限一覧を含めます。さらに、移行対象と対象外、テスト計画も加えます。操作手順、教育計画、運用開始後の問い合わせ窓口も、成果物に含めます。

受け入れ条件は、「全て移行」といった曖昧な書き方を避け、確認できる文で書きます。たとえば、指定リポジトリでテストまで成功する、失敗時に通知される、といった条件です。本番デプロイに承認が要る、旧環境へ戻せる、といった条件も同じように書けます。

複数社への同じ前提での提案とデモ依頼

提案を比べるには、TeamCity自体の経験と、周辺運用への対応力を確かめます。

対象リポジトリとビルド本数、Agent数は、各社でそろえます。Cloud・On-Premisesの条件も同じにします。

• 移行・連携：Jenkinsなどからの移行、Git・Docker・Kubernetes・AWS連携。
• 統制：SSO、Vault、IaC、監査、24時間対応、内製化支援。

TeamCityの公開実績が見当たらない会社には、CI/CD一般の経験と、TeamCity固有の経験を分けて説明してもらいます。

デモでは、コミットからテスト、Artifact生成までを見ます。ステージング配備、失敗通知、承認を経て、再実行まで通しで確認します。

画面の操作だけでなく、ログでの原因調査や設定のコードレビューについても質問します。加えて、プロジェクト単位の権限分割、Agent不足時のスケール方法も聞いておきます。

見積書に明記するセキュリティと責任分界

Serverの権限設計は、オプションとして扱わず、見積もりと契約で責任範囲を明確にします。

• Serverの機密情報：Serverは、VCS資格情報、クラウドトークン、署名鍵、デプロイ権限を管理するため、管理する担当者と範囲を見積書に明記します。
• 権限・秘密情報：トークンを発行・更新・失効する担当者、保管先、AgentのOS権限、ログへの秘密情報出力の確認方法。
• 成果物：外部委託では、TeamCity設定、Kotlin DSLやYAML、IaC、スクリプト、テストコード、手順書の帰属と引き渡しを契約に記載します。
• 保守範囲：「保守一式」に緊急パッチ、休日対応、影響調査、復旧訓練が含まれるか確認します。

JetBrainsは2026年7月、CVE-2026-63077について、On-Premisesを2025.11.7または2026.1.3へ更新するよう案内しました。

また、JetBrainsは長期の対策として、VPNなどによる外部アクセス制限も推奨しています（出典：JetBrains「CVE-2026-63077」、2026年）。

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

製品機能だけでなく、運用能力や既存環境も判断材料になります。さらに、セキュリティ要件と将来の変更頻度も含めて判断します。

TeamCity CloudとOn-Premisesはどちらを選ぶべきですか？

運用負担を減らして早く始めたい場合はCloudが、閉域網やデータ所在地、独自統制を優先する場合はOn-Premisesが基本になります。

CloudにセルフホストAgentを接続する構成もあります。その場合は、機密コードの実行場所と、Serverの管理主体を分けて検討します。

TeamCityのAgentは何台あれば足りますか？

必要台数は、ピーク時の同時実行数とビルド待ち時間で決めます。開発者数を基準にはしません。

まず、実行時間と時間帯別のキューを測り、テスト分割やキャッシュで短縮できるかを確認します。待ち時間が許容値を超える場合は、追加Agentと自動スケールを比べます。

TeamCityへの移行は自社だけでできますか？

1リポジトリの小規模PoCや単純なビルドであれば、自社で始められる可能性があります。

多数のジョブを移行する場合は、デプロイ権限とテストデータも設計します。監査や失敗時の復旧も、あわせて考えておきます。初期設計と標準化だけ外部支援を受け、運用を自社へ引き継ぐ方法もあります。

2026年のAI・MCP連携は導入時に使うべきですか？

最初から自動実行まで任せなくても構いません。TeamCity 2026.1のCLIやMCPは、ビルド状態やログの調査を支援します。

再実行や設定変更、デプロイを許すトークンには、強い権限が含まれる可能性があります。そのため、まずは読み取り専用に限定します。

対象プロジェクトと承認者を定めます。ログの外部送信や監査記録も確認してから、利用範囲を段階的に広げます。

まとめ

機能の多さよりも、導入後も安全に改善を続けられる設計になっているかを見ます。そのためには、要件整理で対象範囲と成功指標を先に決めます。

進め方で押さえるべきポイント

製品の設定量より、対象範囲と成功指標を先に決めることが重要です。ビルド、テスト、デプロイの内容を具体化します。権限と証跡も明確にしたうえで、PoCで復旧を測り、標準テンプレートを横展開します。

最初に作るべき資料と次のアクション

導入計画では、現状の把握と要件整理から始めます。そのうえで、方式選定と、費用と安全性の確認を行います。

• 現状資料：リポジトリや既存ジョブ、ビルド時間、同時実行数をまとめます。デプロイ先、秘密情報の種類、運用担当者も含めます。
• 基盤要件：開発プロセスの改善に必要な構成と、成功指標を明確にします。
• 導入方式：運用体制とセキュリティ要件に合う方式を選び、PoCから段階的に展開する計画をまとめます。
• 費用区分：ライセンスやAgent、インフラを分けます。移行とテスト、教育と保守も、別々の区分として切り出します。

代表サービスは1〜2件選びます。そのうえで、候補方式と移行範囲を、各社に同じ前提で示します。費用内訳と受け入れ条件も、同じ形でそろえます。

Cloud・On-Premises・ハイブリッドは、運用体制とセキュリティ要件で選びます。6つのフェーズに分け、小さなPoCから段階的に展開します。

費用の参考レンジは、PoCが50万〜150万円程度、標準導入が150万〜500万円程度です。

中〜大規模移行は、500万〜1,500万円以上が目安です。対象の本数と作業範囲に照らして評価します。

ServerとAgentの分離、秘密情報の外部管理、最小権限を設計します。バックアップや定期更新、脆弱性対応の責任分界も、あわせて決めます。

設計、移行、教育のうち、自社で不足する範囲だけを切り出すと、過剰な外注や導入後の手戻りを防ぎやすくなります。

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

▼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を創業。