TeamCityの発注は、現状の調査、CI/CD基盤の設計と構築、移行と運用の引き継ぎの順に進めると、開発工程に合う基盤を整えやすくなります。発注形態、RFPと要件整理、契約と費用、委託先の選び方を押さえておくと、担当者として社内で決めるべき事項が分かります。
▼全体ガイドの記事
・TeamCityのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
TeamCityのシステムを発注する前に知っておきたい全体像
外注する範囲は、製品導入、CI/CD構築、既存ジョブ移行に、周辺クラウド設計と運用支援を加えて分けて考えます。ライセンスのみの見積もりと、移行・教育まで含めた見積もりを並べても、金額差が品質によるのか作業範囲によるのか判断できません。
開発・運用の基盤としてのTeamCity
TeamCityは業務アプリとは扱いが違うため、役割と処理の流れ、発注書の書き方を先にそろえておきます。
- 役割：開発・運用の基盤で、受注や在庫を管理する業務アプリケーションとは性格が異なります。
- 処理：リポジトリの変更をServerが管理し、Agentがビルドやテストを実行します。
- 発注書：「TeamCityの開発」とせず、「TeamCityを中心としたCI/CD基盤の設計・構築」と記載します。
対象はGitHubやGitLabのほか、Bitbucket、Perforceなどのリポジトリです。TeamCityは成果物を保管し、次の環境へ渡します。また、発注書に具体的に書いておくと、委託先との認識を合わせる助けになります。
発注範囲の五つの作業
発注範囲は、次の五つの作業に分けて考えると整理しやすくなります。
- 現状調査・企画・方式設計：既存工程や目的を整理し、構成と利用方式を決めます。
- ServerとAgentの構築：実行基盤を用意します。
- パイプライン設計：ビルド、テスト、デプロイを設計します。
- 既存環境からの移行：現在のジョブを移します。
- 運用設計と教育：運用方法を決め、担当者に引き継ぎます。
非機能要件は別枠で扱います。SSOや秘密情報管理、監査ログなどが対象で、バックアップや障害時の復旧、脆弱性対応も別枠にします。
見積もりは、リポジトリ数やビルド構成数に加えて、同時実行数と1日の実行回数で変わります。成果物の容量と保持期間も影響します。
TeamCityの発注形態の選び方
社内にCI/CDを設計・運用できる担当者がいなければ、要件整理から構築、引き継ぎまでの一括委託が適しています。一方で、開発チームに十分な知識があれば、PoCや難易度の高い移行だけを外注し、日常のパイプライン追加は内製できます。CloudとOn-Premisesのどちらにするかは、外注するかどうかとは別の論点として判断します。
初めての導入と大規模移行に向く一括委託
一括委託では、委託先が次の作業をまとめて担当します。
- 現状の洗い出し：既存工程やジョブを確認します。
- 方式と基盤の設計：CloudまたはOn-Premises、ネットワーク、認証を設計します。
- 構築と標準化：パイプラインを整え、テストします。
- 教育：利用者へ操作や運用を引き継ぎます。
JenkinsやGitLab CI/CDから移行する場合は、ジョブの置き換えだけでなく、不要な手作業や重複ジョブの整理も必要です。
窓口を一つにできる一方で、委託先に依存すると、契約終了後に設定を変更できないおそれがあります。そこで、Kotlin DSLやYAML、IaC、運用手順を納品物に含め、社内担当者が変更できる状態を受入条件にします。
分割発注による内製化と費用のコントロール
分割発注では、専門会社へ依頼する作業と社内で担う作業を分けます。
- 専門会社へ依頼：現状調査と基本設計を任せます。
- 難しい移行：対応が難しいサービスの移行を依頼します。
- 安全性の確認：セキュリティレビューを依頼します。
- 社内で対応：定型的なビルド構成の追加や運用を担います。
小規模PoCで自社に合う方式を確かめてから本番を外注する段階発注も有効です。会社が分かれると調整が増えるため、契約書には各社がどこまでを受け持つかを明記します。成果物の形式や設定リポジトリの所有者、障害時の連絡先も書いておきます。
分割発注では、安さだけでなく、会社間の調整を担う管理担当者の工数も比べます。
Cloud・On-Premises・ハイブリッドの選び方
TeamCityの利用方式は、運用負担やネットワーク、データの扱いに合わせて選びます。
- TeamCity Cloud：JetBrainsがサーバーを運用し、導入や更新の負担を抑えやすい方式です。
- On-Premises：サーバー、DB、Agent、ネットワーク、更新を自社または委託先が管理します。
- ハイブリッド：Cloudと自社側の環境を組み合わせます。
Cloudの料金は、コミッター数とビルドクレジットに加え、ストレージやデータ転送量でも変わります。JetBrains提供のAgentのほか、自社ネットワークやプライベートクラウドのセルフホストAgentも接続できます（出典: JetBrains公式TeamCity Cloud移行ドキュメント、2026年確認）。
閉域網や独自の実行環境を必要とする企業や、データの所在地、既存の認証・監査基盤を優先する企業に向きます。脆弱性対応と復旧訓練は、自社側の責任になります。
ハイブリッドでは、たとえば管理サーバーをCloudに置き、機密コードのビルドを自社側のAgentで実行できます。
RFPと要件整理の進め方
RFPは、現在の開発工程と導入後に達成したい成果を委託先へ伝える資料です。「TeamCityを導入したい」という内容では、ライセンス販売なのか、構築や移行、運用代行まで求めるのかを、委託先が判断できません。
RFPには、現状と目的、対象範囲を書きます。制約、納品物、評価基準も加えてまとめておくと、提案内容と見積条件を比べやすくなります。
リポジトリから復旧手順までの現状調査
現状調査では、開発工程と処理量を確認し、移行ジョブや非機能要件も確かめます。
- 開発工程：リポジトリの種類と数、言語、ビルドツールを確認します。テストや成果物、デプロイ先、実行環境、承認者も含めます。
- 処理量：1日のビルド回数、ピーク時の同時実行数、平均ビルド時間、Agent待ち時間、失敗率を確認します。
- 移行ジョブ：既存ジョブを「継続」「統合」「廃止」に分けます。
- 非機能要件：SSO・SAML、接続網、バックアップ頻度、目標復旧時間、監査ログ保存先、夜間連絡体制。
ログと成果物の保存期間も確認します。Agentを置くサブネットも、この段階で押さえます。
ビルドサーバーには、リポジトリの資格情報や署名鍵が集まりやすいため、保管場所と取得権限、ログへの出力制限を要件に含めます。
代表サービスでのPoCと効果・リスクの確認
全社のパイプラインを一度に移行せず、性質の異なる1〜2サービスでPoCを行います。
- 単体テスト中心：テストを含むビルドを確認します。
- Dockerイメージ作成：イメージ作成工程を確認します。
- ステージング配備：環境へのデプロイ工程を確認します。
コミットからステージング配備まで、一連の流れを通します。そのうえで、ビルド時間と失敗時の原因特定を確認します。Agent待ち時間や手作業の削減量も見ます。
合否基準は、設定できたかどうかではなく、運用できるかで決めます。たとえば、失敗したビルドを開発者が自力で再実行できることを条件にします。さらに、設定がKotlin DSLまたはYAMLとしてレビューでき、秘密情報がログに露出しないことも確認します。
担当者が運用手順に沿って復旧できるかどうかも、合否の対象にします。
PoCを有償の調査・設計フェーズとして発注し、本番構築の見積もりを次の契約に分ける方法もあります。
本番展開の標準化と段階移行
本番展開では、設定標準化、新機能の採用判断、段階移行を進めます。
- 設定標準化：各要素の命名規則を決めます。
- 設定管理：Kotlin DSLや利用可能なYAMLベースPipelinesで履歴とレビューを残します。
- 機能の選定：2026.1の機能を自社の権限設計と運用能力に合わせて判断します。
- 段階移行：重要度の低いサービスから始め、設定をテンプレート化して広げます。
命名規則の対象は、プロジェクトとビルド構成、ビルドチェーンです。さらに、VCS接続や成果物保管、通知、権限も含めます。
2026.1では、TeamCity CLIやMCP連携が案内されています。また、Pipelinesの機能強化とSAMLプラグインの同梱も案内されています（出典: JetBrains Blog「TeamCity 2026.1」、2026年5月）。
全社で一斉に移行すると、Agentの不足や資格情報の失効、外部接続の漏れ、デプロイの停止が起こることがあります。そこで、委託先には移行リハーサルと切り戻し条件を納品物として求めます。凍結期間や安定稼働の確認、残課題一覧も含めます。
TeamCityの契約形態と費用相場
発注費は、JetBrainsへのライセンス料金と、委託先へ支払う費用に分けて考えます。委託先への費用には、調査・設計、構築・移行、運用が含まれます。
無償版を使う場合でも、環境設計やセキュリティ、移行の費用は必要です。テストや教育にも費用がかかります。導入作業を含めた総額を比べるには、ライセンス販売の見積もりに加えて、作業ごとの費用を並べる必要があります。
ライセンス費用の確認項目
ライセンス料金は、価格モデルと価格の時点、更新条件、長期費用に分けて確認します。
- 価格モデル：On-PremisesとCloudの料金を確認します。
- 価格の時点：現行のドル表示と過去の円価格を区別します。
- 更新条件：新規・既存ライセンスの割引条件を確認します。
- 長期費用：1年目に加え、3年・5年のTCOを比べます。
JetBrains公式購入ページでは、On-Premises Professionalは無料です。Build Agent 3台とBuild Configuration 100件が含まれます。
Enterpriseは年額2,399ドルでAgent 3台を含みます。また、追加Agentは1台あたり年額359ドルです。
Cloudは最低3コミッターで、年額540ドルの表示があります。Cloudで料金に関わる利用量は、ビルドクレジット、ストレージ、データ転送量です（出典: JetBrains公式TeamCity購入ページ、2026年8月確認）。
価格は税、為替、契約条件で変わるため、発注前に公式ストアで確認します。JetBrainsの2025年1月開始の円価格表では、Cloudは年額25,200円／コミッターでした。
同価格表ではOn-Premises Enterprise Serverが新規335,860円、追加Build Agentが新規50,260円でした（出典: JetBrains「日本円価格表」、2025年1月開始）。
2026年の公式購入ページはドル表記です。そのため、古い円価格を現在の確定価格として扱うことはできません。
2025年11月3日以降の新規On-Premisesライセンスは、従来の50％更新割引の対象外となる方針です（出典: JetBrains Blog「Updates to TeamCity On-Premises Renewal Pricing」、2025年9月）。
既存と新規で更新条件が混在することもあります。そこで、1年目だけでなく3年・5年のTCOを提示してもらいます。
構築・移行費の作業範囲別レンジ
TeamCity固有の日本市場の受託開発統計は確認できていません。代わりに、業務システムの人月相場とCI/CD構築の作業量から算出した参考レンジを示します。
- 小規模PoC：50万〜150万円程度、期間は2〜6週間が目安です。
- 標準導入：150万〜500万円程度、期間は1〜3か月が参考です。
- 中〜大規模移行：500万〜1,500万円以上、3〜9か月を見込むことがあります。
- 基盤の再設計：1,000万〜3,000万円以上になることもあります。
これらはTeamCity単体の価格ではなく、周辺基盤を含む推定レンジです（出典: NotebookLMリサーチノート、2026年8月確認）。
小規模PoCは、1リポジトリと1〜3本のビルドを対象に、Git連携、単体テスト、権限設定を行います。
標準導入は、複数リポジトリと10〜30本程度のビルド構成が対象です。Dockerやクラウド連携に加えて、成果物保管や通知、運用手順も含みます。
中〜大規模移行は、数十〜数百のビルドを対象とし、複数環境の構成やSSO・監査への対応まで行います。冗長化やIaC、教育も含みます。
基盤の再設計には、Kubernetesや複数クラウドへの対応が含まれます。さらに、セキュリティ検査、デプロイ自動化、内製化支援も含まれます。
準委任と請負の使い分け
契約形態は、作業の進め方と成果の確定度に合わせて分けます。
- 調査・PoC：課題を発見し、専門家の稼働時間に価値がある段階では準委任が使われやすいです。
- 構築・移行：納品物と検収条件を定める請負契約。
- 運用監視：構築・移行と分けて契約する方法。
準委任では、作業内容と稼働人数、期間、報告方法を定めます。成果物の完成だけでなく、調査や助言の過程も管理します。
確定した設計に基づく構築や移行、テスト、手順書の作成は、納品物と検収条件を決めた請負契約に向く場合があります。
要件が固まらない部分まで一つの請負契約にすると、追加費用や納期変更が争点になりやすくなります。
Kotlin DSLやYAML、IaCなどの設定ファイル、スクリプト、テストコードは、権利の帰属と再利用範囲を契約書に書きます。手順や教育資料は、権利の帰属と再利用範囲を契約書で定めます。
委託先の選定と見積比較の観点
委託先は、TeamCityだけでなく、開発工程やクラウド、ネットワークを横断して設計できる会社を選びます。セキュリティ、移行、教育も同じ会社で扱えるかを見ます。
公開情報でCI/CD支援が確認できても、TeamCityの導入経験や認定まで公開しているとは限りません。そのため、専門会社と断定せず、面談で実績と担当者の経験を確かめます。
実績の確認範囲と担当工程
候補会社には、製品と技術、実績の中身、比較候補の適合性を確認します。
- 製品と技術：Cloud・On-Premises、Jenkins・GitLab CI/CDの経験。
- 実績の中身：課題、構成、担当工程、規模、成果、現在の保守体制。
- 運用対応：失敗調査、成果物保持、権限分離、障害復旧を説明できるか。
Agent数やSSO/SAMLへの対応、Vaultなどの秘密情報管理を確認します。KubernetesやIaCへの対応も見ておきます。
顧客名を出せない場合も、匿名で実績の詳細を説明できるかを見ます。「CI/CDの実績があります」という一文では、担当工程まで分かりません。
大規模・基幹系なら、たとえば日立製作所やNTTデータのように、DevOps・CI/CD支援を公開する会社が候補になります。クラウドと運用定着を重視するならTISやSCSK、内製化と教育ならCTCなども比較できます。
これらは、公開情報からCI/CDやDevOps支援が確認できる候補であり、TeamCityの案件実績を一律に保証するものではありません。
問い合わせの際は、TeamCityのバージョンや移行元を示したうえで、Agent数やSLAへの対応可否を確認します。
作業・前提・除外項目をそろえた見積書の比較
見積書は、作業、費用項目、契約条件の三つに分けて比べます。
- 作業：要件定義、基本・詳細設計、構築、パイプライン作成を書きます。移行、テスト、教育、文書、保守も含めます。
- 費用項目：ライセンス、クラウド、Agent実行費、ストレージ、転送、監視。
- 契約条件：担当人数、期間、前提、納品物、検収条件。
構築のみの見積もりと、移行・教育まで含む見積もりを並べるときは、作業の範囲をそろえておくと、違いが見えやすくなります。
安さだけで決めず、リポジトリの整理やテストコードの不足が除外されていないかを確認します。ネットワーク申請や証明書、秘密情報管理が作業に含まれているかも確かめます。夜間対応やバージョンアップも確認します。
更新作業や移行後の調整が除外されているかを確かめ、リポジトリ数やビルド構成数が変わった場合の単価も確認します。追加作業の承認手順と上限金額は、契約前に決めておきます。
見積もりに含めるセキュリティと運用責任
見積もりには、基盤の保護、委託先のアクセス、脆弱性対応を含めます。
- 基盤の保護：ServerとAgentを分離し、管理画面をVPNやアクセス制御で守ります。
- 権限と秘密情報：実行権限を最小限にし、資格情報を各所へ直書きしません。
- 委託先の管理：本番情報へのアクセス、作業記録、終了時の返却・削除を決めます。
トークンや署名鍵、クラウド資格情報は、直書きせず、秘密情報管理基盤と連携させます。直書きを避ける場所は、リポジトリや設定ファイル、環境変数、ビルドログです。
委託先の担当者が本番資格情報に触れる範囲と、アクセスログの記録方法、脆弱性の報告期限を契約で定めます。
2026年7月、JetBrainsはTeamCity On-Premises全バージョンに影響するCVE-2026-63077を公表しました。
HTTP(S)で到達できるサーバーでは認証を迂回してOSコマンドを実行される可能性があり、2025.11.7または2026.1.3への更新が推奨されています（出典: JetBrains Security Advisory「CVE-2026-63077」、2026年7月）。
TeamCity Cloudではこの脆弱性への対応作業は不要とされています。ただし、セルフホストAgentを使う場合の管理までJetBrainsが代行するわけではありません。リポジトリ権限やトークン、デプロイ先の管理も、利用者側で担う部分です。
発注時には、更新の検証と緊急パッチ、脆弱性発生時の連絡、復旧訓練を保守範囲に含めます。
よくある質問
TeamCityの発注では、製品を選ぶだけでなく、委託範囲や移行対象を整理する必要があります。運用責任やライセンスの更新条件も、発注前に固めておきます。よく寄せられる質問に、簡潔に答えます。
TeamCityのシステム開発はどこまで外注できますか？
現状調査や方式選定、設計、構築まで外注できます。既存CI/CDからの移行や、セキュリティ設計、教育、保守も依頼できます。
社内に残したい業務がある場合は、PoCと基本設計だけを依頼し、定型パイプラインの追加や一次切り分けを内製する分割発注も可能です。契約時に、納品物と引き継ぎ条件を決めることが重要です。
TeamCityの導入費用は最低いくらですか？
On-Premises Professionalは無料ですが、設定・移行費は別です。PoC（1リポジトリ程度）は50万〜150万円程度、標準導入は150万〜500万円程度が参考レンジです。
金額は、対象リポジトリやビルド構成、移行元で変わります。SSOやクラウド連携、教育の有無も金額に影響します。そのため、同じRFPをもとに複数社から見積もりを取ると比べやすくなります。
TeamCity Cloudなら運用を外注しなくてもよいですか？
Cloudは、TeamCityサーバーの運用負担を減らせます。ただし、パイプライン設計や失敗調査、Agent、リポジトリ権限、秘密情報、デプロイ先の管理は残ります。
自社で担える場合は、サーバー構築を外注せず、設計レビューや移行支援だけを依頼できます。セルフホストAgentを使う場合は、OS、ネットワーク、更新、容量、資格情報の管理責任も確認します。
TeamCityのAIやMCP機能も発注要件に入れるべきですか？
失敗調査やログ要約が目的なら、将来の要件またはPoCに含めます。初期は実行・配備の権限を絞り、読み取り専用や対象の限定、人の承認を設けます。さらに、操作ログと秘密情報の外部送信防止を備え、権限を段階的に広げます。
まとめ
TeamCityの発注では、製品を入れるだけでなく、開発からデプロイまでをつなぐCI/CD基盤として要件をまとめます。
リポジトリやビルド構成、同時実行数を洗い出し、デプロイ先や秘密情報、復旧手順も確認します。そのうえで、Cloud、On-Premises、ハイブリッドを比べます。
PoC、一括委託、分割発注から自社に合う形を選びます。次に、RFPには作業範囲や納品物、検収条件を記載します。契約や運用責任、更新費用も書いておきます。
見積もりは、ライセンス費と構築費、移行費に分けます。教育や保守、クラウド費も、別の項目として示してもらいます。さらに、1年目だけでなく3年・5年のTCOで比べます。
TeamCityの経験に加え、セキュリティと内製化まで説明できる委託先を選ぶと、導入後も運用できる開発基盤に近づきます。
▼全体ガイドの記事
・TeamCityのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。