Bambooの発注は、現状把握、RFPの作成、PoCでの検証、本番構築と引き継ぎの順に進めると、安全に運用できるCI/CD基盤につながります。
発注形態の選び方、要件整理、導入から移行までの手順、費用、委託先の選定を順に見ていきます。全体像はBambooのシステム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・Bambooのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Bambooのシステムを発注・外注する全体像
Bambooの外注は、サーバーへの製品インストールだけでは終わりません。ソース管理やPlan・Stage・Job・Taskを設計するところまで含まれます。
さらに、Build agentの台数や実行環境、成果物の保管、検証・本番へのデプロイも扱います。承認、監査ログ、障害対応までを一つのリリースプロセスとして設計します。
Bambooのシステム開発の範囲と役割
Bambooの発注では、開発基盤としてのBambooの役割と、委託先に任せる範囲を分けて確認します。両者を分けておかないと、見積の前提がずれやすくなります。
- 自動化する工程：リポジトリからのコード取得、ビルド、テスト、成果物保存、各環境へのデプロイ
- 基盤の役割：基幹システムとは異なり、安全で再現性のあるリリースを支える
- Atlassian連携：Jira Software、Bitbucket、Confluenceの課題やコミット、結果、履歴を結び付けやすい
- 委託範囲：Plan設計に加え、Java・.NET、テストツール、Docker・Kubernetes・AWSなどで、どこまでを委託先が受け持つかを決める
- 見積条件：Bamboo本体に全ツールは含まれず、対象サービス、言語、リポジトリ、成果物、デプロイ先の提示が必要
対象条件をそろえて伝えれば、委託先の見積を同じ前提で比べられます。
新規導入と既存Bambooの移行の違い
新規導入では、まず製品を採用するかどうかと、オンプレミスかクラウド型かを判断します。一方、既存利用では、設定や資産を一覧にして、継続するか移行するかを決めます。
- 棚卸し対象：Plan、権限、成果物、エージェント、Webhook、プラグイン、秘密情報
- 判断すること：Bambooを継続するか、Bitbucket Pipelinesなどへ段階移行するか
Atlassianは、2026年3月30日以降の新規顧客によるData Center新規購入を停止し、対象製品の終了日を2029年3月28日と案内しています（出典：Atlassian公式「Data Center End of Life」、2026年確認）。
Bambooを採用する場合は、導入の可否だけでなく、契約中のサポート、データの持ち出し、移行用設定ファイルの引き渡しも確認します。
発注形態の選び方
発注形態は、要件をどこまで決められるか、成果物を固定できるか、移行や運用にどれだけ不確実性があるかで選びます。
現状調査をしないと工数を読めないため、一括で発注するより、調査・PoC・本番を分けて発注する方法が適する場合も多くあります。
請負契約を使う段階
請負契約は、要件整理の後に行う検証環境の構築など、成果物と完成条件を合意しやすい工程に適しています。
仕様書では、まず対象環境と対象リポジトリを明記します。
- 対象範囲：Plan・Stage・Job、エージェント数、テスト項目、性能基準、納品形式
- 成果物の例：検証環境、決めたPlan数の移行、バックアップ復元テスト、運用手順書
「Bambooの導入」だけを完成条件にすると、承認が機能しない、失敗時に戻せない、ログを十分に保持できないといった問題が起こりがちです。
そのため、検収では成功時だけでなく、テスト失敗や権限不足、エージェント停止まで確かめます。さらに、デプロイ途中の異常と、復元後の再実行も確認します。
準委任・時間単価型が適する案件
準委任や時間単価型は、調査の結果によって次の作業が変わる案件に適しています。古いプラグインや不明なスクリプトが多い環境でも、月ごとに優先順位を調整しながら進められます。
- 対象業務：既存Planの棚卸し、移行方式の検討、代替製品の比較、運用改善
- 月次報告：稼働時間と作業内容を報告し、作業の優先順位を共同で調整
作業時間を報告するだけだと、成果や知識移転がどこまで進んだのか曖昧になりがちです。そこで、月次成果物には棚卸し表と設計判断記録を含め、変更履歴、未解決課題、次月計画も残してもらいます。
契約には、時間単価と想定稼働時間を書き込み、超過時の承認方法と担当者の交代条件も入れます。
調査・PoC・本番の分割発注
調査・PoC・本番は分けて発注できます。現状調査からPoC、本番構築、保守へと段階を踏むと、製品選定やエージェント設計の誤りを早い段階で見つけやすくなります。
- 現状調査を行い、RFPの精度を高める
- 低リスクなサービスでPoCを実施する
- 本番環境を構築し、移行する
- 保守運用へ引き継ぐ
PoCでは、画面が表示されるかだけでなく、コミットからビルドとテストを経て、成果物保存、検証環境へのデプロイまでを測定します。
検証では、承認から本番相当環境への反映、ロールバックまでを一連の流れとして確認します。
PoCで得た平均・ピークのビルド時間と同時実行数に加えて、失敗時の復旧時間、運用担当者の作業時間も、本番発注の判断材料にします。
RFPと要件整理の準備範囲
RFPは、委託先に提案を求めるための依頼書で、「Bambooを導入したい」という要望書ではありません。現状と目的、対象範囲を書き、さらに、制約と期待成果、提案してほしい選択肢もそろえます。
不明な項目は空欄にせず、調査対象または提案事項として明記します。同じ前提で見積を作れる状態にしておくことが大切で、そうすると各社の見積を同じ条件で比べられます。
現状と対象範囲の記載内容
現状欄には、まずリポジトリの種類と数、Jira・Bitbucketの利用状況、既存Plan数を書きます。Stage・Job構成と失敗率を記載し、平均・ピークのビルド時間と同時実行数も書きます。
成果物の種類と保持期間、デプロイ先を記載し、承認者と運用体制も書きます。制約としては、オンプレミス限定とネットワーク分離、国外持ち出しの禁止、利用可能なクラウドの範囲を含めます。
認証基盤や監査ログの保存要件も伝えます。そのうえで、対象範囲はBamboo本体、DB、リモートエージェントに分けて書きます。
対象範囲には、Elastic agentやKubernetes上の一時エージェント、ロードバランサーも含めて整理します。
バックアップと監視、通知、秘密情報管理も範囲に含めるかを決めます。対象外とした作業には、担当者を明記します。
- 対象外の例：アプリ改修、テストデータ作成、AWSアカウント調達、既存ネットワーク変更
- 明記する理由：追加請求や責任の押し付けを抑えるため
機能要件と非機能要件の分け方
機能と非機能を分けて、実装する処理と運用上の条件をそれぞれ明記します。分けておくと、開発会社が実装する範囲と、運用で満たす条件を切り分けやすくなります。
- 処理と連携：ソース取得、ビルド、単体・結合テスト、並列実行、成果物の版管理、Jira・Bitbucket連携、通知
- リリース操作：各環境への昇格、承認、失敗時の再実行とロールバック
- Planの管理方式：Bamboo SpecsのYAML・Javaでコード管理するか、画面設定を残すか
- 運用・安全性：可用性、性能、拡張性、バックアップ・復元、監視、パッチ、脆弱性、認証・認可、操作ログ、保管場所、連絡時間、復旧目標
- 秘密情報：ログや成果物への秘密鍵・トークン・本番データ混入を検査し、マスキングと最小権限を設計する
この要件をもとに、秘密情報がログや成果物へ出ていないことを検収で確かめます。
2026年以降の出口戦略
Data Centerの終了予定を踏まえ、発注の時点で移行条件と納品物を定めておきます。
- 契約時期：Data Centerの購入条件と終了予定を確認する
- 納品物：Bamboo Specs、ビルドスクリプト、Dockerfile、IaC、接続情報の構成、設計書、テスト仕様、運用手順
- 移行条件：別ベンダーへの利用権・引き渡し方法、Bitbucket Pipelinesなどへの移行調査を決める。移行先は今決めなくてもよい
- 移行準備：データ形式、成果物保存、秘密情報の再登録、並行稼働の手順を残し、将来の選択肢を保つ
- 移行ツール：AtlassianはBambooからBitbucket Pipelinesへの移行ツールを2026年3月にベータ公開
2026年3月30日以降、新規顧客はData Centerの新規サブスクリプションを購入できず、対象製品は2029年3月28日に終了予定です。
既存顧客の拡張や契約には例外があるため、自社の条件を公式窓口で確認します。
Atlassianの2025年社内事例では、複雑なCI/CDを移行した後、ビルド時間は6時間から1.5時間に、リードタイムは約2日から最短1.5時間に短縮しました。
デプロイ頻度も、1日1回程度から複数回へ増えました（出典：Atlassian公式「1 Billion Build Minutes Later」、2025年8月）。
独自プラグインや権限は、自動で移行できるとは限りません。秘密情報と承認フローも含めて、委託先による調査と検証が必要です。
契約期間中のサポートと出口戦略は、RFPの段階で確かめておきます。
Bambooの発注・外注の進め方
発注は現状把握から始め、採用判断とPoCを経て、基本設計へ進みます。その後は、本番構築、段階移行、運用引き継ぎの順に進めます。
各工程では、終了条件と意思決定者を決めておきます。技術担当に加えて、リリース責任者とセキュリティ担当も参加します。購買・法務と開発チームも加わります。
最初の現状調査での棚卸し項目
まずPlan、Stage、Job、Taskを一覧にします。そのうえで、リポジトリとエージェント、テストの対応関係を確かめ、成果物とデプロイ先の対応関係も確認します。
実行時間と待ち時間、失敗原因、再実行回数を集計します。その結果から、エージェントを増設して解決するか、テストや依存関係を見直す必要があるかを判断できます。
管理者と開発者、承認者、運用担当者の権限も確認します。さらに、認証情報が平文で保存されていないか、退職者のアカウントが残っていないかも調べます。
成果物とログの保管日数、バックアップからの復元可否も確かめます。報告書では、課題を対応の時期ごとに分けて書きます。
- すぐ直す課題：調査で判明した緊急性の高い問題
- PoCで検証する課題：本番前に動作を確かめる事項
- 将来移行時の課題：次の基盤へ移る際に対応する事項
PoCと本番設計の確認項目
PoCでは、一連のリリース工程を実際に試し、本番設計の根拠になる条件を測ります。
- PoCの対象：重要度の低いサービスを一つ選び、コミットからビルド、テスト、成果物保存、承認、本番相当環境へのデプロイまで通す
- 動作の測定：エージェントを1台から増やした場合の待ち時間、コンテナ環境での再現性、テスト失敗時の追跡性
- 構成の選択：単一ノードかData Centerかを決め、ローカル、リモート、Elastic、Ephemeralからエージェントを選ぶ
- 冗長化の条件：Bamboo、DB、共有ストレージ、ロードバランサー、認証、監視、バックアップ復元手順をそろえる
- 設計根拠：過剰な構成を避けるため、ピーク時の同時実行数と許容待ち時間を使う
測定結果をもとに本番構成を決め、冗長化の対象も含めて可用性を確認します。
移行と引き継ぎを失敗させない進め方
移行では、不要な設定を整理したうえで、段階ごとに動作を確かめ、社内への知識移転も行います。
- 移行前の整理：不要なPlan、古いプラグイン、重複スクリプト、期限切れ認証情報を除く
- 段階移行：優先度の高いサービスから移し、旧環境と新環境で同じコミットをビルドして比較する
- 比較項目：成果物、テスト結果、デプロイ結果、ログの追跡性
- 引き継ぎ物：Bamboo Specs、スクリプト、コンテナ定義、IaC、監視設定、障害連絡先、パッチと復元の手順、権限棚卸しの周期
納品後は、自社の担当者が実際にPlanを追加し、ビルドを復旧させて確かめます。
Bambooのシステム発注費用の相場
発注費用は、ライセンスと導入・構築、実行基盤に分けて考えます。移行や保守の費用も、別に見ておく必要があります。
ただし、ここで示す構築費は公開価格ではなく、作業量から推定した予算レンジです。実額は、Plan数やエージェント数、環境数によって決まります。
連携先やセキュリティ水準、既存資産の状態でも変わります。国内のBamboo専用の標準見積は公開が少ないため、条件をそろえて見積もります。
ライセンス費の予算化
Data Centerの費用は、エージェント数と見積時点の契約条件を確認して予算化します。
- ライセンスの単位：一般的なユーザー数ではなく、同時実行能力に関係するエージェント数
- 年間参考額：1台1,200米ドル、5台3,200米ドル、10台5,840米ドル、25台11,600米ドル
- 円換算の目安：1米ドル150円で機械的に換算すると、およそ18万円、48万円、88万円、174万円
- 価格の扱い：為替、税、契約条件を含まない目安。Data Centerは年額契約で、購入可否や条件は時期・顧客区分により変わるため公式価格を取得する
- 台数の算定：待ち時間だけでなく、並列化、キャッシュ、環境分離、成果物の保管期間も考慮する
年間参考額は、公的調達資料に掲載された値です（出典：ペルー国税庁SUNAT公的調達資料、2025年10月）。
参考額は確定価格ではないため、発注時点の条件で見積もり直します。
構築・移行費の相場
構築・移行費は、対象範囲に応じた概算レンジで比較します。
- PoC・評価環境：50万〜150万円程度、期間2〜6週間程度
- 標準導入：150万〜500万円程度、期間1〜3か月程度
- 本番基盤：対象構成を含む場合、500万〜1,500万円以上、3〜9か月程度となることがある
- 環境・製品移行：300万〜2,000万円以上、3〜12か月程度。棚卸し、Specs化、秘密情報再設計、成果物・権限・Webhook移行、並行稼働を含む推定
標準導入の推定には、Jira・Bitbucket連携と複数Stage、開発・検証・本番へのデプロイを含みます。さらに、権限とバックアップ、運用手順に加え、管理者教育も見込んだ推定です。
本番基盤の推定には、Data Centerや複数エージェントを含みます。加えて、Docker・KubernetesやAWSの環境、監視、災害復旧も対象に入れます。
ここまでの数値は、公開されたBamboo専用の標準価格ではなく、要件から算出した概算です。
保守・基盤費を含めた総額での比較
比べるときは、初期費用に加えて、基盤費と保守範囲を含めた総額を見ます。
- 基盤など：AWS・Azure・Kubernetes、DB、ストレージ、ログ、監視、バックアップ、証明書、Marketplaceアプリ、通信費、障害対応
- 保守費の目安：一般的な業務システムでは初期構築費の年15〜25％程度。Bambooでは対応範囲で変わる
- 保守範囲：脆弱性パッチ、エージェント障害、ビルド失敗、プラグイン互換性、夜間対応
- 見積内訳：ライセンス、Plan・エージェント・環境数、移行対象、基盤費、月次アップグレード、問い合わせ時間、障害時SLA、バックアップ復元テスト
ログ保管や脆弱性対応が別料金になっている場合は、初期費用の安い提案でも、3年間の総額では逆転することがあります。
委託先の選定と見積比較で確認すべきポイント
販売代理店であるかは、判断材料の一つにとどめます。委託先には、現行BambooとData Centerの制約を理解しているか、基盤設計から移行・運用まで説明できるかを確認します。
CI/CDの経験に加え、AWSやKubernetes、ID基盤の知識も確認します。監視とセキュリティの体制も見ます。公開事例が別のAtlassian製品ばかりなら、Bamboo Data Centerの実績を質問します。
実績と技術体制の確かめ方
会社名やパートナーランクに加え、担当者が実際に説明できる技術の範囲も聞きます。回答が一般論に終わる場合は、短期間のPoCで再現性を確かめます。
- 移行・運用：Specsへ移したPlanの件数、独自プラグイン、エージェント分離、成果物保持
- 安全性：秘密情報のローテーション、障害時のロールバック、パッチ適用
- 稼働実績：旧環境と新環境の並行稼働と導入後の保守内容
体制表には、責任者とBamboo設計者、インフラ・セキュリティ担当を示してもらいます。運用窓口と代替要員も記載してもらいます。
再委託がある場合は、範囲とアクセス権、所在地を確認します。さらに、事故時の責任と契約終了時のデータ削除も確かめます。特定個人だけに依存する体制は、異動や退職で運用停止を招くため避けます。
複数社の見積の比較方法
各社に同じRFPと質問票を渡し、前提条件をそろえたうえで価格を比べます。内訳と作業量を分けて見るとともに、安さの理由も確認します。
- 作業内訳：要件整理、設計、構築、テスト、移行、教育、文書、保守、基盤費
- 比較条件：Plan・エージェント・環境・リポジトリの数、担当者稼働、期間
- 価格差の理由：作業省略か、再利用可能なテンプレートによる効率化か
評価の配点は一例として、価格を40点、要件適合を25点、技術・移行力を20点とします。残りは運用体制10点と出口戦略5点です。配点は社内の事情に合わせて変えられます。
契約後の保守も評価の対象に含め、提案外の作業とユーザー側の前提作業を記録に残します。さらに、追加変更の単価と、納期遅延時の扱いも書き留めます。
契約とセキュリティの見落としやすい点
契約と検収では、情報管理と脆弱性対応について、担当と条件を明確にします。
- 契約条件：秘密情報の保管場所・暗号化、ログ保存期間、脆弱性通知期限、パッチ責任、再委託、バックアップと削除、障害時SLA
- 権利と引き渡し：ソースコード、Specs、スクリプト、IaC、設計書の著作権・改修権・利用権、別ベンダーへの切り替え条件
- 公開情報：依存ライブラリ情報の公開状況を確認する
- 脆弱性対応：深刻度だけで断定せず、利用バージョン、影響部品、修正版、公開範囲、適用手順を確認し、判断者と適用時期を定める
- 検収条件：ビルド環境と本番の権限を分離し、ログに認証情報を出さない
Atlassianは2026年にもBamboo Data Centerの依存ライブラリ情報を公開しています（出典：Atlassian Security Bulletin、2026年6月確認）。
契約内容と運用手順を対応させ、担当範囲に抜けがないか確認します。
よくある質問（FAQ）
Bambooの発注では、既存環境や契約条件に関する質問が多く寄せられます。運用責任や将来の移行性についても、よく尋ねられます。外注の前に判断しやすいよう、各質問に結論から答えます。
Bambooのシステムは新規で発注しても問題ありませんか？
既存のJira・Bitbucket資産がある企業には、継続利用の合理性があります。オンプレミスやネットワーク分離、監査要件がある企業にも、継続する理由があります。
ただし、Data Centerは2026年時点で新規購入に制約があり、2029年3月28日に終了予定です。
新規で発注する場合は、Bitbucket Pipelines、Jenkins、GitLab CI/CDを同じ要件で比較し、移行の方針も確認します。
Bambooの構築費用は何万円から考えればよいですか？
要件整理の前に見る推定では、小規模なPoC・評価環境が50万〜150万円程度、標準導入が150万〜500万円程度です。標準導入には、Jira・Bitbucket連携と複数環境を含みます。
Data Center、複数エージェント、コンテナが対象に入り、さらに監視や災害復旧、複数チームの移行まで含む場合は、500万〜1,500万円以上になることがあります。
確定価格ではなく、対象範囲と作業量から算出した予算の目安です。
Bambooの外注先には何を質問すればよいですか？
Specsや既存Planの移行実績、エージェント・成果物・秘密情報の設計、失敗時のロールバック検証について質問します。
脆弱性パッチとプラグイン互換性を管理する担当者や、終了を見据えた移行支援も確認します。納品範囲と保守時間、SLAを比べます。さらに、再委託の有無や、契約終了時のデータと設定の引き渡しも見ます。
まとめ
発注で定めるのは、リリース工程を再現でき、安全に運用できる状態を成果物として示すことです。ライセンスの購入やインストールは、その途中の作業にあたります。
Plan、エージェント、成果物を棚卸しし、権限、ログ、秘密情報も洗い出します。そのうえで、RFPには、要件、受け持つ範囲、検収条件をそろえて書きます。
発注前に決める事項
調査・PoC・本番・保守を分けて発注するかを決めます。さらに、請負と準委任をどう組み合わせるかも決めておきます。そのうえで、基盤費と保守費、移行費、障害対応を含めた総額で見積もります。
契約には、秘密情報と監査ログ、脆弱性対応、SLAを記載します。加えて、再委託や権利、SpecsやIaCの引き渡しも書き込みます。
次に取るべきアクション
同じRFPを委託先候補に渡し、Bambooの直接実績と移行・運用体制を質問します。さらに、見積の前提と代替製品への移行性も確かめます。
2026年以降はData Centerのライフサイクルを踏まえて進めます。継続利用する場合でも、移行するデータと設定、その時期を初期設計に残しておきます。
▼全体ガイドの記事
・Bambooのシステム開発の完全ガイド
▼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を創業。