Bitbucketのシステム開発の完全ガイド

Bitbucketのシステム開発は、構成と移行・運用の要件で設計が変わります。要件に合った設計が、安全な開発とリリースにつながります。

役割から構成、導入手順、費用、支援先、セキュリティまで、順に見ていきます。各テーマの詳しい内容は、関連記事もご覧ください。

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

Bitbucketのシステムの概要

コードを届けるまでの役割がひと目で分かります。

Bitbucketは、Gitリポジトリを管理し、変更の提案、レビュー、テストを経たコードを各環境へ届けるサービスです。ただし、業務システムの画面やデータベースを直接提供するわけではなく、安全で継続的な開発と改善を支える役割を担います。

リポジトリとプルリクエストの一元管理

リポジトリには、ソースコード、ブランチ、タグ、コミット履歴を保存します。機能の追加や修正は作業用ブランチで行い、プルリクエストで変更内容とテスト結果をレビューしてから統合します。

直接変更を制限：mainへの直接書き込みを制限し、レビューを必須にする運用です。
権限を標準化：Read、Write、Create、Adminなどの権限を、統一した形で整理できる。

プロジェクト権限は、そのプロジェクト内の既存・新規リポジトリへ適用できます（出典：Bitbucket公式サポート「Configure project permissions」、2026年8月確認）。

CI/CDと課題管理の開発フローへの組み込み

Bitbucket Pipelinesでは、ビルド、単体テスト、静的解析、成果物作成を自動化できます。設定に応じて、ステージングへのデプロイや本番リリースの承認も自動化できます。

CI/CDや課題管理をつなぐときは、つなぐ先ごとに情報の扱いを決める必要があります。検討する点は4つあります。

設定の追跡：設定をコードで管理すると、CI/CD条件を変えた人と時期を追えます。
社内環境への接続：セルフホストランナーを使えば、社内ネットワークのテスト環境へつながり、業務システム開発でも扱いやすくなります。
開発履歴の連携：課題キーをコミットやプルリクエストに結び付け、要件からリリースまでの流れを追跡できる。
ナレッジの連携：設計書や運用手順を、ナレッジ管理ツールとつなぐ仕組み。

品質を支えるには、連携の先で誰が何を決めるかも欠かせません。課題キーの入力、レビュー責任者、テスト失敗時の扱いを、導入前に決めておきます。

Bitbucket単体で業務システムが完成しない理由と範囲

役割、設計範囲、導入目的は、次のように分けて考えます。

役割：「Bitbucketのシステム開発」は業務アプリ開発と開発基盤構築を指し、導入で中心になるのは後者です。
誤解を防ぐ：「リポジトリを作ればシステムができる」「CI/CDがあれば運用は不要」と受け取られることがあります。
設計範囲：業務アプリ本体、DB、クラウド基盤、監視、認証、バックアップは、Bitbucketとは別に設計する対象です。
導入目的：開発速度、レビュー品質、リリースの安全性、監査証跡などを、業務成果として示す。

Bitbucketの種類と構成の選び方

構成は、Bitbucket Cloud、Bitbucket Data Center、両者を使い分けるHybridの順に比べます。規模より先に、コードの保管場所、ネットワーク分離、認証を見ます。

可用性、監査、既存資産、運用人材も合わせて評価します。このため、小規模ならCloud、大企業ならData Centerと、単純に分けられるものではありません。

Bitbucket Cloudの強みは導入の速さと運用負荷の低さ

Cloudは、利用人数と必要な統制機能を踏まえてプランを選びます。

Free：利用者が少ない検証で候補に挙がります。
Standard：本番で標準的な権限やCI/CDを使う場合の候補です。
Premium：組織横断の統制や監査を重視するなら、候補になります。

サービス提供側が基盤の保守、可用性対策、機能更新を担います。そのため、自社でサーバーを構築せず、短期間で始められます。新しい開発チームも追加しやすく、標準機能を中心にした導入にも向いています。

外部クラウドへの保管は、社内規程や取引先の要件に合わないことがあります。また、接続元IP制限、二段階認証の必須化、デプロイ権限などの管理機能は、プランによって違います。

導入前には、保管先の承認とデータ分類を確認します。退職者アカウントの無効化と委託先のアクセス条件も、あわせて確かめておきます。

Data Centerの特徴は自社要件に合わせた管理のしやすさ

Data Centerは、自社データセンターや契約したクラウド基盤に置く構成です。ネットワーク、認証、バックアップを中心に、監視やアップグレードも自社で管理します。

Data Centerを選ぶときは、自社が担う運用と、その構成に合う要件を照らし合わせます。

適合する要件：閉域網、厳格なデータ所在地、独自認証、高い可用性、既存監視との統合を求める場合に向きます。
必要な体制：インフラ、冗長化、障害対応、パッチ、更新検証、専門人材を、自社で用意する必要があります。

ライセンス費だけで比べると、運用費や人件費を含む総保有コストが大きくなる場合があります。また、選ぶ際には、障害時の復旧時間と判断担当者も設計します。

既存資産を活かす場合のHybridと拡張開発

Hybridや拡張開発では、既存環境の活用方法と運用上の分担を先に整理します。

Hybrid：自己管理環境を残しつつ、新チームや公開可能なリポジトリをCloudへ移せる形です。
運用統一：権限、課題管理、監査ログ、CI/CD、サポート窓口のルールを揃えておく。
拡張機能：不足する承認フローや社内ポータルなどを、API、Webhook、Forgeで補える。
外部連携：本体を大きく改造せずに連携を切り出しておくと、将来の変更や移行に対応しやすくなります。

Hybridなら、全体を一度に移さずに済みます。そのうえで、移行期間だけの暫定構成にするか、長期的な併用にするかを先に決めます。

2026年時点では、クラウド側のCI/CD、権限管理、監査、開発支援機能が継続して更新されています。ただし、新機能の採用を目的にするのではなく、運用課題や認証・監査要件に合うかで評価します（出典：Bitbucket公式製品ページ・料金ページ、2026年8月確認）。

ポイント

構成は規模だけで決めず、保管場所、ネットワーク分離、認証の要件を先に確かめます。そのうえで、可用性や監査、既存資産、運用を担う人材に合うかを比べると、選びやすくなります。

Bitbucketのシステム開発の進め方

移行後の照合と教育までが移行計画に含まれます。

導入は、まず現状を把握し、要件定義とPoCで方針を固めてから、設計、段階移行、教育、運用改善へと進みます。この順に進めると、業務への定着とのギャップを小さくできます。

アカウント作成とリポジトリ移行が済んだ時点は、導入の途中です。既存のGit環境がある場合は、権限、ブランチ、リリースのルールも見直します。

例として、開発者10人、リポジトリ15個、検証と本番の環境が各1つというチームを考えます。まず代表リポジトリでレビューとテストを標準化し、そのあとで残りへ展開します。

全員にWrite権限を与えていても、mainへのマージは担当者に限定できます。さらに、ステージングは自動、本番は手動承認にすると、小さく導入して効果を測れます。

要件定義での開発基盤の目的と対象範囲

要件定義では、現状、改善目的、機能・非機能要件を分けて整理します。

現状把握：開発者・チーム数、リポジトリ数と容量、利用中のGitサービス、ブランチ数、課題管理方法、デプロイ先、個人情報・営業秘密の有無を洗い出す。
改善目的：レビュー属人化の解消、リリース短縮、監査時の履歴説明などを、測定できる形で定めます。
要件定義：利用者管理、SSO、二段階認証、IP制限、監査ログ、バックアップ、復旧目標、サポート時間を決めておく。

データの保管場所や委託先のアクセス条件も、文書にまとめておきます。要件が曖昧なまま見積もると、あとから追加費用が発生しやすくなります。

代表リポジトリを使ったPoCの検証内容

全社展開の前に代表リポジトリを1〜3個選び、cloneからブランチ作成、プルリクエスト、レビュー、テストまでを試します。成果物の保存と、ステージングへのデプロイも確かめます。

失敗したときの再実行やロールバックも確認します。言語や構成が異なるリポジトリを選ぶと、展開時の問題を見つけやすくなります。

権限エラー：権限のない利用者がmainへ書き込もうとした場合を試す。
テスト失敗：失敗時の通知と再実行の流れ。
外部サービス停止：停止時にどう対応するかを確かめる。
秘密情報の誤登録：検知と対応方法の確認。

成果物には、設定ファイルと運用手順を入れます。あわせて、エラー対応、残課題、導入効果の測定方法も含めます。運用の判断には、画面のスクリーンショットより、こうした中身が必要になります。

段階的な移行と展開、照合と教育

移行では、対象範囲の確認から教育まで、順に進めます。

移行対象：Gitデータと関連する設定や履歴を洗い出す。
対象外の確認：移行支援ツールの対象外を、別途確かめておく。
移行後の照合：移行前後のデータと設定を突き合わせる。
段階展開と教育：段階的に移行し、担当者ごとに教育する。

Gitファイル、ブランチ、タグ、コミットに加えて、プルリクエストやレビュー履歴も移行対象に含めます。利用者、グループ、権限、ブランチ制限も、移行対象に入れます。また、Webhook、CI/CD変数、Marketplaceアプリ設定も確認します。

移行アシスタントはGitデータの移行を支援します。一方で、添付、活動フィード、リポジトリ設定、ブランチ権限、マージチェック、アプリデータは、別途確認が必要です（出典：Bitbucket公式サポート「What gets migrated with Bitbucket Cloud Migration Assistant」、2026年8月確認）。

移行の前後では、リポジトリ数、ブランチ、タグ、コミットハッシュを照合します。利用者、権限、Pipeline実行結果も、照合の対象です。

まずは影響の小さいチームから始めます。そのうえで、変更を凍結する期間、旧環境を参照できる期間、切り戻しの条件を決めておきます。

管理者向けには権限と監査、開発者向けにはブランチ運用とレビューを分けて研修すると、現場に定着しやすくなります。

ポイント

導入は、現状把握から運用改善まで段階を踏んで進めます。移行後の照合と教育まで計画に入れておくと、業務への定着とのギャップを小さくできます。

Bitbucketのシステム開発の費用相場

作業範囲が広がるほど、費用幅も大きくなります。

費用は、ライセンスと導入支援、移行、CI/CD構築、教育、保守運用に分けて考えます。公式ライセンスの金額と、要件定義や開発会社への委託費は別物です。

ここで示す導入支援費は、作業範囲に基づく一般的な推定で、公式見積もりではありません。金額は、リポジトリ数、利用者数、認証、デプロイ先、移行対象、可用性要件によって変わります。

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

Cloudのライセンス費の決まり方

Cloudのライセンス費は、プラン別のユーザー数料金と、利用量に応じた追加費用で見積もります。

プラン料金：プランとユーザー数で月額が異なります。
10人の例：Standardは月36.50米ドル、Premiumは月72.50米ドルです。1米ドル150円なら月約5,500円、約10,900円です。
プラン機能：必要な統制機能に応じて選びます。
追加料金：ビルド1,000分とGit LFS 100GBは月10米ドル、セルフホストランナーの同時実行枠は1枠あたり月15米ドルとの案内もあります。

2026年8月時点では、Freeは5ユーザーまで無料です。公式料金では、6〜100人の場合、Standardは1人あたり月3.65米ドル、Premiumは同じ人数帯で月7.25米ドルです（出典：Bitbucket公式料金ページ、2026年8月確認）。

StandardにはGit LFSやPipelinesが含まれます。Premiumでは、マージチェック、IP許可リスト、デプロイ権限、二段階認証の必須化などを検討できます。毎月のビルド時間、成果物の容量、LFSの容量を実測してから見積もります。

導入支援費の規模と移行範囲による違い

導入支援費は、作業の規模と移行範囲によって大きく変わるため、作業ごとの目安を比べます。

PoC・現状診断：50万〜150万円、2〜4週間が目安です。現状を洗い出し、構成を比べ、権限方針と代表Pipelineを作る作業を含みます。
標準Cloud導入：100万〜300万円、1〜2か月が目安です。基本構成、課題連携、Pipeline、運用手順、教育までを用意する作業です。
移行とCI/CD整備：300万〜800万円、2〜4か月が目安です。
複合要件：複数拠点、高可用性、ネットワーク分離、監査、Hybrid、周辺連携まで含むと、800万〜2,000万円以上になる場合があります。

数十〜数百のリポジトリがある場合や、SSO、権限の再設計、秘密情報の整理、各環境へのデプロイ、移行リハーサルを含む場合は、工数が増えます。金額は、業務システム開発の人月単価と想定工数をもとにした編集上の推定です。

運用費と追加作業を含めた総額の比較

見積書は、「導入一式」とまとめず、作業単位に分けて確認します。

初期費用：移行リハーサル、テスト、文書、教育、障害対応設計に抜けがないかを見る。
年間費用：ライセンス、ビルド時間、ストレージ、監視、バックアップ、サポート、脆弱性対応、人件費、追加開発まで含める。
自己管理環境：サーバーと冗長化の費用を加える。
見積もり範囲：現状調査、基本設計、権限設計、移行、Pipeline、テスト、教育、運用引き継ぎ、保守の単位で分ける。

費用の金額だけでなく、見積もりに含まれる内容と、別料金になる条件も確認します。

ポイント

費用は作業単位に分けて見積もり、総額は運用費と追加作業を含めて比べます。金額はリポジトリ数や利用者数などで変わるため、前提をそろえて比べることが欠かせません。

Bitbucketの開発会社・ベンダーの選び方

支援先は、ライセンスを売るだけでなく、開発プロセスと運用を設計できるかで選びます。候補にするのは、Bitbucket CloudとData Centerの両方を理解している支援先です。そして、既存Git環境からの移行、CI/CD、本番デプロイ、認証、監査、利用者教育まで説明できるかを確認します。

Bitbucketと移行の実績の確認項目

支援先の実績は、案件の内容と移行対象を具体的に確かめます。

案件との近さ：社数や認定ランクだけでなく、ユーザー数、リポジトリ数、Cloud・Data Center、移行元を見る。
設計実績：権限・レビューの再設計、デプロイ先、移行後の問い合わせ担当について尋ねる。
移行対象：ユーザー・グループ、ブランチ制限、Webhook、変数、レビュー履歴、アプリ連携の扱い。
対象外の処理：手動移行、再設定、対象外として受け入れる項目を、明示できるかを確かめる。

可能なら、匿名化した構成図や運用手順のサンプルも見ます。対象範囲を明示してもらえるかは、見積もりの精度を判断する材料になります。

技術力と業務設計力の一体評価

設定に詳しくても、リリース承認や障害対応まで設計できなければ、現場への定着は難しくなります。開発力が高くても、最小権限、秘密情報、監査ログ、バックアップを説明できないと、長期運用に不安が残ります。

Cloud・Data Center・Hybridへの対応、API・Webhook、CI/CD、セルフホストランナーの扱いを評価します。認証、脆弱性対応、監視、教育、保守も、あわせて確かめます。

ソースコード、Pipeline設定、IaC、設計書、運用手順の所有権と引き渡し条件を、契約前に確認します。再委託先の範囲、アクセス権限、データ削除を含め、インシデント報告を誰が受け持つかも明確にします。

同じRFPとPoCによる提案の比較

同じ前提条件をRFPに記し、提案内容とPoCの確認項目を揃えて比べます。

RFPの前提：ユーザー・リポジトリ数、移行対象、言語、環境数、デプロイ頻度、認証・監査要件、納期を揃えておく。
提案内容：「導入できます」と書かれているかだけでなく、前提、対象外、体制、工程、成果物、検収、追加費用まで比べる。
PoC：テスト失敗、権限不足、承認拒否、秘密情報検知、障害後の再実行を、実際に試して確かめる。
役割分担：開発、運用、セキュリティの各担当が質問し、内製と継続委託の範囲を分ける。

失敗時の切り戻しや、運用開始後の問い合わせ方法も、提案書で確かめます。

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

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

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

ポイント

支援先は、導入後の開発プロセスと運用まで設計できるかで比べます。提案の前提をそろえ、同じPoCで試すと、社ごとの差が見えやすくなります。

Bitbucketのセキュリティと運用の確認項目

安全性は、サービスの機能だけでなく、組織のルールと日々の運用で決まります。そこで、アクセス、レビュー、本番デプロイ、秘密情報、脆弱性対応を一続きの流れとして捉えます。

権限・ブランチ・デプロイの制御

権限は、ワークスペース、プロジェクト、リポジトリ、ブランチ、デプロイ環境の順に整理します。全開発者にWrite権限を与えていても、mainへの直接書き込みやマージは限定できます。

ブランチ権限を使うと、書き込みやプルリクエスト経由のマージを制御できます（出典：Bitbucket公式サポート「Use branch permissions」、2026年8月確認）。

変更：mainへの直pushを禁止する。
レビュー：2名以上の確認を必須にする。
テストとリリース：テスト成功をマージの条件とし、リリースブランチの作成を限定する。
本番と秘密情報：承認済みグループだけに本番権限を与え、秘密情報はコードに書かない。

人数やリスクに応じて、必要な制御から段階的に導入します。

開発フローでの秘密情報と脆弱性の管理

秘密情報の漏えい防止と脆弱性対応は、開発工程の中に組み込みます。

秘密情報の管理：APIキー、パスワード、証明書、DB接続情報はコミットせず、安全な変数や外部管理、短期認証情報を使って権限を分ける。
誤登録時の対応：ファイルを削除して終えず、キーを無効化したうえで、履歴やログを確かめる。
開発ライフサイクル：開発から運用までの各工程で、対策を整理する。

NISTのSecure Software Development Frameworkは、開発工程全体を見渡すための枠組みです。組織の準備、ソフトウェアの保護、安全な生成、脆弱性への対応という4つの実践群を示しています。

2025年12月に改訂版1.2のドラフトが公開され、2026年4月にはプロジェクトページが更新されました（出典：NIST Secure Software Development Framework、2026年確認）。

Bitbucketで課題とレビュー、テスト、成果物、リリース履歴をつなげると、活動を記録しやすくなります。

監査・バックアップ・改善の継続

運用では、定期的な棚卸しを含め、監査、復旧の確認、効果の測定を続けます。

定期の見直し：月次や四半期ごとに、利用者、グループ、管理者、リポジトリ、Webhook、トークン、ブランチ権限を見直す。
アクセス整理：退職者や異動者の権限を削除し、使われていないリポジトリや変数を片付ける。
監査：要件、変更、レビュー、テスト、承認、デプロイを追跡できるかを確かめる。

バックアップには、リポジトリの複製に加えて、権限、Pipeline設定、環境変数の復旧方法、運用手順、拡張機能設定も含めます。復旧訓練では、目標時間内に利用できるかを検証します。

リリース後は、開発時間、レビュー待ち時間、デプロイ失敗率、障害復旧時間を測ると、導入効果と課題を説明しやすくなります。

ポイント

セキュリティは、機能の多さよりも、社内のルールと日々の運用で左右されます。権限から脆弱性対応までを一続きの流れとして、定期的に見直しておくことが欠かせません。

よくある質問

導入では、機能に加えて、開発体制、セキュリティ、費用、移行、運用を合わせて考えます。

Bitbucketは業務システムそのものですか？

いいえ。Bitbucketは、Gitリポジトリ、レビュー、CI/CD、開発履歴を管理する開発基盤です。業務画面、DB、認証、監視を含む業務システム本体は、別に設計します。Bitbucketが担うのは、ソースコードとリリース工程の管理です。

Bitbucket CloudとData Centerはどちらが良いですか？

短期間で始めたい、基盤の運用を抑えたい、標準機能を使いたい場合は、Cloudが候補になります。厳格なネットワーク分離、データ所在地、自社認証、独自の可用性要件がある場合は、Data Centerも比べます。

既存環境を残して段階的に移行する場合は、Hybridも検討します。判断の基準は、自社の規程と運用体制です。

小規模チームでもBitbucketを導入する価値はありますか？

小規模でも、mainへの直push防止、レビュー記録、テスト自動化、再現可能なリリース手順に役立ちます。

複雑な承認階層は定着しにくいため、命名、ブランチルール、必須テスト、秘密情報管理など、事故防止に必要なルールから始めます。

既存のGit環境から安全に移行できますか？

移行はできますが、Gitデータをコピーすれば終わるとは限りません。まず、ブランチ、タグ、コミットを事前に洗い出します。さらに、ユーザー、グループ、権限、レビュー履歴も確かめます。Webhook、Pipeline、拡張機能の設定も、移行前に洗い出しておきます。

移行アシスタントの対象外は、手動で再設定する計画が必要です。そのうえで、代表リポジトリで検証し、照合と切り戻しの条件を決めて、段階的に進めます。

まとめ

Bitbucketのシステムは、業務アプリを作る仕組みではなく、開発基盤です。Git管理、レビュー、CI/CD、課題管理をつなぎ、認証と監査も含めて支えます。

導入前には、Cloud、Data Center、Hybridの違いを、自社のデータ、ネットワーク、運用要件に照らして整理します。

導入前に押さえるべき要点

Bitbucketの役割は開発基盤と定め、業務アプリ本体やクラウド基盤との境界を決めます。そのうえで構成を比べ、リポジトリ、ブランチ、権限、レビューを要件に含めます。さらに、CI/CD、認証、監査、移行範囲も要件として定めます。

次に確認するべき項目

導入前は、PoCと見積もりで範囲、進め方、支援体制を確かめておく必要があります。見る点は4つあります。

PoCと見積もり：代表リポジトリで検証し、同じ前提で見積もりを比べる。
契約範囲：移行対象外、追加ライセンス、教育・保守、設定の引き渡し、障害時の切り戻しを明記しておく。
導入手順と費用：現状把握から運用まで進め、ライセンス、支援、移行、CI/CD、教育、監視、バックアップ、保守を見積もる。
支援先：移行実績、セキュリティ、業務フロー、成果物の引き渡し、障害時の体制を確かめる。

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