Bitbucket・GitHub・GitLabを比較するときに知っておきたい、開発ツール統合の歴史と AIエージェント時代の選択軸

Atlassianの開発者向けアプリセット「Software Collection」の中核をなすのが、ソースコード管理（SCM）のBitbucketと、それに統合された CI/CDの Bitbucket Pipelinesです。本記事では、コード管理ツールと CI/CDツールを「別々の機能」ではなく「開発体験を形づくる組み合わせ」として捉え、SCMと CI/CDが分離から統合へ向かった業界の編成史、そして GitHub・GitLab・Bitbucketそれぞれの設計思想の違いを踏まえて、Bitbucket Pipelinesを選ぶ意味を整理します。

Bitbucketは、Atlassianの SCM（Source Control Management：コードの保管・バージョン管理）にあたる製品です。Bitbucket Pipelinesは、これに統合されたCI/CD（コードを自動でビルド・テスト・デプロイする仕組み）です。

最初に結論めいたことを述べると、Bitbucketは GitHubや GitLabと比べて「決定的な機能差」を持つ製品ではありません。Git・プルリクエスト・内蔵CI/CD・AIアシスタントといった要素は、3製品とも揃っています。

Bitbucketの固有の強みは、Jira・Confluence・Jira Service Managementと同一プラットフォーム上でSDLCが完結する点にあります。

SCMとCI/CDの統合 -- Pipelinesが生まれた背景

もともと SCM（コードの保管・バージョン管理）と CI/CD（自動ビルド・テスト・デプロイ）は、それぞれ独立した専門領域として認識されていました。「コードが変わるたびに自動でテストする」という発想自体が比較的新しく、設計図の保管（＝SCM）と、品質チェック・出荷のライン管理（＝CI/CD）は、そもそも別物として扱われていたのです。世の中的に、GitHub + Jenkins、Bitbucket + Bambooといった「SCMと外部CIサーバーの組み合わせ」が、長らく標準的な構成でした。

この時代の CI/CDは、開発チームの外側に置かれた「専用の自動化サーバー」に近い存在でした。Jenkinsのジョブ設定や Bambooのビルドプランをメンテナンスする担当者がいて、リポジトリ側の変更と CI側の設定変更が必ずしも同じレビューサイクルに乗らないことも珍しくありませんでした。コードを書く人、ビルド環境を面倒見る人、リリースする人の境界が比較的はっきりしていた時代です。

ソフトウェア開発の現場が成熟してくるにつれ、リリースのスピードも求められるようになりました。そうなると自然と、「コード管理からビルド・デプロイまで、ひとつのツールでまとめてやりたい」という声が開発者の間で広がっていきました。これに応える形で、SCMベンダーが CI/CDを自社サービスに取り入れ始めました。
この流れは、2015年に GitLabが CIを本体へ統合したのを皮切りに、2016年の Bitbucket Pipelines、2019年の GitHub Actions一般公開へと広がり、決定的になりました。

これに伴い、ビルド手順の定義方法も変わりました。かつては管理画面から手作業でビルド手順を組み立てていましたが、現在は .yml 形式の設定ファイル（Bitbucketでは bitbucket-pipelines.yml）にパイプライン手順を記述し、コードと一緒にリポジトリに格納します。パイプライン定義そのものがバージョン管理とレビューの対象になる----これを「Pipeline as Code」と呼びます。

この変化の本質は、「CI/CDの設定もアプリケーションコードと同じように扱う」という考え方への転換です。ビルド手順がリポジトリに入ることで、誰が・いつ・なぜデプロイ手順を変えたのかが Gitの履歴として残ります。CI/CDはインフラ担当者だけが触るブラックボックスではなく、開発チーム全体がレビューし、改善していくコードの一部になりました。

その結果、主要3サービスはいずれも「SCM・CI/CD・AIコーディングアシスタント」の3点セットを自社ソフト内に揃えるに至りました。

Bitbucket vs GitHub vs GitLab -- 機能・思想の差分

3サービスの違いは、個別機能よりも設計思想に現れます。

機能名だけを並べると、3サービスはいずれも Gitリポジトリ、プルリクエスト、YAMLベースの CI/CD、AI支援を備えており、違いが見えにくくなります。

しかし、実際の選定では「何を中心に開発組織を設計するか」という思想の差が判断材料になります。GitHubは開発者と OSSコミュニティを中心に据え、GitLabは DevSecOpsの工程を単一製品に畳み込み、Bitbucketは Jiraを中心とした業務・チケット・ドキュメント・運用との接続を重視します。

この差分を組織の選択基準に置き換えると、次のようになります。

• GitHubが向くのは、OSSや採用市場での認知を重視し、Copilotを軸に AI開発体験を追求したい組織
• GitLabが向くのは、計画からセキュリティ・運用までを単一プラットフォームで完結させたい、自前ホスティング志向の組織
• Bitbucketが向くのは、すでに Jira・Confluenceを使っており、SDLC全体を Atlassian Cloud上で一気通貫にしたい組織

Atlassian製品を使っている組織にとってのメリット

Bitbucketの価値が最も発揮されるのは、当然ながら、Atlassian製品で開発・運用を回している組織です。

具体的には、Jiraのチケットとコード・ビルド・デプロイが同一プラットフォーム上で結びつきます。Confluenceのドキュメントとリポジトリが双方向にリンクします。Jira Service Managementとつながり、本番障害のチケットからコミット・プルリクエスト・デプロイまでを追跡できます。権限・SSO・監査ログがAtlassian Adminで一元管理され、データレジデンシーやコンプライアンスも Atlassian Cloudの枠組みに乗ります。

逆に、Atlassian製品を使っていない組織はこのメリットを享受できません。Bitbucket単体を、JiraもConfluenceもない環境に導入しても、GitHubや GitLabに対する明確な優位は生まれにくいでしょう。この非対称性こそが、Bitbucketを検討する際の最も重要な判断材料です。

Bitbucket Pipelinesの仕組み

Bitbucket Pipelinesの仕組みはシンプルです。リポジトリ直下の bitbucket-pipelines.yml にビルド・テスト・デプロイの手順を記述すると、コミットやプルリクエストをトリガーに、Dockerコンテナベースの環境でパイプラインが実行されます。

たとえば、Node.jsアプリケーションを「ビルド・テスト → ステージングへデプロイ」する最小構成は次のように書けます。

このファイル自体がリポジトリで管理されるため、パイプラインの変更もコードと同じくレビューと履歴管理の対象になります。これが「Pipeline as Code」の実際です。

実行環境（ランナー）は2種類から選べます。

• Atlassianホスト型：Atlassianが実行環境を用意します。インフラ管理が不要で、ビルド分数に応じた課金です
• セルフホスト型（Linux / Windows / macOS）：自社のマシンでランナーを動かします。ビルド分数を消費せず、社内ネットワーク内のリソースにアクセスするビルドにも対応できます

料金体系（2026年7月時点）
料金は、Bitbucketのプランに一定のビルド分数が含まれ、超過分が従量課金となる構造です。ビルド分数とストレージはワークスペース単位で、ワークスペース内の全ユーザーが共有します。

（Bitbucketプラン別のビルド分数・ランナー枠。ライセンス費用は別途お問い合わせください）

この基本枠を踏まえたうえで、超過分と追加ランナーの考え方は次のとおりです。

• ビルド分数の超過：1,000分（または100GB）あたり月10ドルで追加購入します
• セルフホスト型ランナー：無料（Free）ランナーはワークスペースあたり最大100台まで利用できます。2026年6月3日に一般提供が始まった Premiumランナーは、同時実行ビルドスロットあたり月15ドルで、実際に使用した最大同時スロット数のみが課金対象です（利用にはワークスペースをAtlassian組織へ接続する必要があります）

小規模なチームなら無料枠と含まれる分数で十分回り、規模が大きくなったらセルフホスト型で費用を最適化する、という段階的な使い方ができます。

（出典：Premium self-hosted runners are generally available）

Pipelinesによって Bitbucketがどう便利になるのか

Pipelinesが Bitbucketに統合されている実利は、別ベンダーの CIを組み合わせる場合と比べると見えやすくなります。

コードと同じ場所でビルドが走るため、リポジトリと CIの間でログインや権限を二重に管理する必要がありません。Jiraのチケットとビルド結果が紐づき、「どの作業がどのビルドにつながったか」を追えます。マージするかどうかの判断がプルリクエスト画面の中で完結します。そして、別ベンダーの CIを調達・接続・維持する運用負荷そのものが不要になります。

派手な機能ではありませんが、日々の運用における摩擦を着実に減らす効果があります。

なお、既存の Bambooからの移行を検討している場合は、2026年6月29日に Bamboo → Bitbucket Pipelinesの移行ツールが一般提供されています。デプロイメントプロジェクトの移行やインスタンス単位での移行、監査レポートに対応しており、移行の初期調査を進めやすくなりました（出典：Bamboo to Bitbucket Pipelines migration tool is now GA）。

Rovo / Rovo Devとの連携

Software Collectionの文脈では、Bitbucketと Pipelinesは Rovo Dev（開発者向けAIエージェント）の作業基盤としても位置づけられます。Rovo Devは2025年10月に CLI・Bitbucket Cloud・GitHubで一般提供が始まり、2026年2月には VS Code（Cursorなどの VS Code互換IDEを含む）にも対応しました。JiraやBitbucketの画面からも呼び出すことができます。

想定されるユースケース例

• 自然言語でビルドを起動する（「mainの最新を stagingに出して」）。
• プルリクエストレビューを自動化し、差分の要約や潜在的なバグ、テスト不足を指摘する。
• 失敗したパイプラインのエラーログから原因の仮説を提示する。
• Jiraのチケットを起点にコード変更案を作り、プルリクエストを起票するまでの下書きを用意する。

特徴的なのは、プルリクエストが Jiraのチケットに紐づいている場合、Rovo Devが受け入れ基準（acceptance criteria）と照らして変更内容を検証できる点です。「このコードは要件を満たしているか」という問いに、ツールの境界をまたいで答えようとする設計になっています。

2026年4月には、Jiraのワークアイテム（課題）から直接、セキュアなクラウドサンドボックス上でコードを生成し、条件を満たしていればスムーズにプルリクエストを作成できる「Rovo Dev in Jira」が発表され、順次提供されています。Jira・Confluence・コードベースなどのプロジェクトのコンテキスト（チーム共通認識）を文脈として利用でき、Jira Automationのアクションとして呼び出して反復タスクのコード生成を自動化することも可能です（*利用にはRovo Devのクレジットと、Bitbucket Cloudまたは GitHub Cloudの接続が必要です）。

さらに2026年6月16日からは、作業項目の Developmentパネルにある「Open in coding tool」から、手元の AIコーディングツールへコンテキスト付きで作業を引き渡せるようになりました。提供開始時点での対応は次の6ツールです。

（「Open in coding tool」の対応ツールと引き渡し方式。コンテキストは Atlassian MCP経由で自動的に付与されます）

Pipelines側でも、パイプラインのステップとして AIエージェントを実行する「Agentic Pipelines」がオープンベータで提供されています。既定の Rovo Devに加えて、2026年6月には Claude Code、続いて OpenAI Codexにも対応し、YAMLの provider 指定で使い分けられます（出典：Agentic Pipelines now supports OpenAI Codex）。

なお、Rovo Devは GitHub Cloudにも対応しており、SCMが GitHubのままでも利用を始められます。ただし、先述の通り、Jira・Bitbucket・Confluence・Jira Service Managementが揃った環境でこそ、チケット・コード・ドキュメント・障害情報を横断する本来の力を発揮する設計です。

SCMと CI/CDツールの選び方まとめ

Bitbucketと Pipelinesは、SCMとCI/CDの統合という業界全体の流れのなかにある、Atlassian製品を活用する上でのベストプラクティスです。GitHub・GitLabとの間に決定的な機能差はなく、選択の本質はエコシステムにあります。Atlassian製品を中心に開発・運用を回している組織にとっては合理的な選択肢であり、そうでない組織にとっては移行コストが効果を上回ってしまうかもしれない、という整理になります。

リックソフトは、Atlassianの Platinum Solution Partnerとして、Bitbucketへの移行支援、Pipelinesによる CI/CD整備などをご支援しています。ご検討中の方はお気軽にお問い合わせください。