Bitbucketはオワコンなのか？将来性とメリットを競合比較から徹底検証する開発チームの選択基準

「リポジトリホスティングサービスはGitHub一択」――そう断言する開発者は少なくないでしょう。
確かに、GitHub Copilotに代表されるAI支援機能や圧倒的なコミュニティ規模を考えれば、その主張にも一理あります。
一方で、Bitbucketを選び続けるチームが今も存在するのも事実です。
JiraやConfluenceとのシームレスな連携、無料枠で使えるプライベートリポジトリ、そしてBitbucket PipelinesによるCI/CDの統合。
これらの強みは、開発体制次第では今なお合理的な選択理由となりえます。

では、Bitbucketは本当に「オワコン」なのでしょうか。
判断材料として押さえておきたいのは、次の2点です。

• Atlassianによるサーバー製品のサポート終了など、事業戦略の転換がもたらす影響
• GitHubやGitLabとの機能比較において、Bitbucketは本当に劣位なのか

本記事では、市場シェアの推移と機能比較をもとに、これらの問いを一つずつ検証していきます。
結論を先取りすれば、Bitbucketの評価は「使うチームの構成」によって大きく左右されるはずです。
自チームに適したバージョン管理基盤を選ぶための判断基準を、この記事で一緒に整理していきましょう。

Bitbucketとは？基本の概要と主要機能をおさらい

「オワコンなのか」を判断するためには、まずBitbucketがどのようなサービスで、どの部分が競合と違うのかを正確に把握しておく必要があります。
比較基準が曖昧なまま議論を始めると、評価が恣意的になりがちです。
ここでは、運営元Atlassianの概要と、Bitbucketを特徴づける要素を順に確認していきましょう。

Bitbucketの概要と運営元Atlassianについて

Bitbucketは、Gitリポジトリをホスティングするサービスで、2008年にMercurial向けのホスティングとしてサービスを開始しました。
2010年にオーストラリアのAtlassian社に買収され、以降は同社の開発者向けプロダクト群の中核として位置づけられています。

Atlassianは2002年にオーストラリアで創業されたソフトウェア企業で、課題管理ツールのJiraやドキュメント管理ツールのConfluenceを擁し、開発組織向けSaaSの分野では世界有数のプレイヤーです。
GitのGUIクライアントであるSourcetreeもAtlassian製であり、開発フローを幅広くカバーしている点は特筆に値します。

Bitbucketには、大きく分けて2つの形態があります。

• Bitbucket Cloud：Atlassianが運用するSaaS型サービス
• Bitbucket Data Center：自社サーバーやクラウドIaaS上に構築するオンプレミス型サービス

なお、かつて提供されていた中小規模向けの「Bitbucket Server」は、新規ライセンス販売が2021年2月に終了し、サポートも2024年2月をもって終了しました。
このサーバー製品の終了が、後述する「オワコン」議論の火種の1つになっていることは、記憶に留めておく必要があるでしょう。

無料プランで使える機能とユーザー数制限

無料枠だけで、どこまで開発を回せるのでしょうか。
Bitbucket Cloudの無料プランは、5ユーザーまでであればプライベートリポジトリを無制限に作成できるのが特徴です。
主な制限は以下の通りです。

• ユーザー数：1ワークスペースあたり5人まで
• Pipelinesビルド時間：月50分まで
• Git LFSストレージ：1GBまで

有料のStandard／Premiumプランに切り替えるとユーザー数の上限が撤廃され、ビルド時間も大幅に増加します。
料金の目安は次の表の通りです（2024年時点の参考値。
為替や価格改定の可能性があるため、最新値は公式サイトで確認してください）

プラン	月額（1ユーザーあたり）	Pipelinesビルド時間	主な特徴
Free	0ドル	月50分	ユーザー5人まで
Standard	約3ドル	月2,500分	ユーザー数無制限
Premium	約6ドル	月3,500分	IP許可リスト、マージチェックの必須化など

5人程度の小規模チームであれば、リポジトリからCI/CDまで無料枠で構築できるという点は、費用対効果の観点で無視できない強みと言えます。

Jira・Confluence・Trelloとの連携でできること

Bitbucket最大の差別化要素は、Atlassian製品群との連携です。
まず、Jiraとの連携では次のようなことが可能です。

• Jiraの課題画面から、ブランチやプルリクエストを直接作成できる
• コミットメッセージに課題キー（例：PROJ-123）を含めると、Jiraの課題にコミットが自動表示される
• プルリクエストの作成・マージ状況が、Jiraの課題タイムラインに反映される

さらに「Smart Commits」と呼ばれる構文を使えば、コミット操作から課題ステータスの変更や作業時間の記録まで実行できます。

PROJ-123 #comment レビュー指摘に対応
PROJ-123 #time 1h 30m

上記のコミットは、課題PROJ-123へのコメント追加と、1時間30分の作業時間の記録をまとめて行います。

Confluenceとの連携では、リポジトリを設計ドキュメントに関連付けることで、仕様書から実装コードへと行き来できるようになります。
Trelloとの連携も、公式のPower-Upを有効にするだけで、カードにブランチやプルリクエストを添付可能です。

GitHubにもJira連携アプリは存在しますが、ネイティブ統合の深さではBitbucketが優位に立っています。
「課題管理からコードレビューまでを1社のエコシステムで完結させる」という設計は、ツール間を行き来する移動コストを削減する、合理的な構成であると言えるでしょう。

Bitbucketは本当にオワコン？市場シェアと利用動向から見る現在地

「オワコン」という言葉は感性論になりがちです。
議論を実質的なものにするためには、少なくとも2つの客観指標が必要でしょう。
1つは市場シェア、もう1つは提供元の事業戦略です。
この章では、この2つの指標をもとに、Bitbucketの現在地を冷静に確認していきます。

Gitホスティング3サービスのシェア比較

まず、開発者アンケートに基づく利用シェアを見てみましょう。
Stack Overflow Developer Survey 2024の調査では、バージョン管理ホスティングの利用状況はおおよそ次のような分布になっています。

サービス	利用率の目安	特徴
GitHub	約9割	圧倒的なコミュニティとエコシステム
GitLab	約3割	DevOps統合プラットフォーム志向
Bitbucket	約1割	Atlassianエコシステムとの統合

この数字は、回答者の属性や調査方法によって多少前後するものの、大勢に影響はありません。
GitHubが事実上の標準（デファクトスタンダード）であること、そしてBitbucketがシェアの面では明確に第3グループに位置することは、否定しようのない事実です。

ただし、ここで注意すべき点があります。
シェアは「利用者の絶対数」を示すものであり、「サービスの死活」を直接示すものではないということです。
むしろ、この程度のシェアでも事業が継続できているということは、特定の顧客セグメントから確固たる支持を受けている証拠とも読めます。

Bitbucket Server（オンプレミス版）サポート終了の影響

「オワコン」論が本格化した発端は、Atlassianのサーバー製品終了方針です。
経緯を整理すると、以下の通りになります。

1. 2020年10月：Atlassianがサーバー製品の終了方針を発表
2. 2021年2月：Bitbucket Serverの新規ライセンス販売を終了
3. 2024年2月：Bitbucket Serverのサポートを完全終了

サポート終了後のBitbucket Serverには、セキュリティパッチが提供されません。
Gitリポジトリは企業のソースコード資産そのものですから、無修正のまま運用を続けるのは重大的なリスクを伴います。
多くの企業が、この時点で移行を迫られたわけです。

選択肢は2つに絞られます。
クラウド版のBitbucket Cloudへ移行するか、大規模組織向けのBitbucket Data Centerへ移行するかです。
問題は、Data Centerが年間サブスクリプション制で、中小規模の予算では割に合いにくい価格帯だったことでしょう。
「手頃なオンプレミス版」の消滅は、Bitbucketの印象を確実に損ないました。
この時点で離脱したユーザーの多くがGitHubやGitLabに流れたことは、シェア推移からも推察できます。

それでもBitbucketを使い続ける企業がある理由

では、シェアが小さくなったBitbucketを、なぜ今も使い続ける組織があるのでしょうか。
理由は主に3つに整理できます。

• Atlassianエコシステムへの深い投資：JiraとConfluenceを長年運用してきた組織にとって、Bitbucketの連携機能は代替が効きにくい資産です。ツールチェーンの乗り換えには、単なる移行作業以上に、ワークフローの再設計と学習コストが伴います
• Data Centerという現実的な退路：規制対応やデータ主権の観点から、SaaSにソースコードを置けない組織にとって、引き続きサポートされるData Centerは重要な選択肢です
• コスト構造の合理性：小規模チームであれば、前章で確認した通り、無料枠でリポジトリからCI/CDまで構築できます

視点を変えれば、Bitbucketの状況は「事業の衰退」ではなく「顧客セグメントの選別」と捉えるのが妥当でしょう。
Atlassian自体は時価総額で見れば健全な企業であり、開発者向け事業から撤退する姿勢は見られません。
シェアで劣勢であることと、提供が終わることは、論理的に別の命題です。

つまりBitbucketの現在地とは、「主流からは外れたが、特定の利用形態においては依然として合理的な選択肢」というもの。
この前提を踏まえた上で、次章から具体的な強みと弱点を検証していきます。

Bitbucketのメリット｜今なお選ばれる3つの強み

前章の結論を思い出してください。
Bitbucketの現在地は「衰退」ではなく「顧客セグメントの選別」でした。
ならば次の問いは自然です。
すなわち、選別して残った組織は、Bitbucketのどの性質を根拠に選び続けているのか。
本章では、その根拠となりうる3つの強みを、機能の詳細レベルで検証します。

Jiraとのシームレスな連携による課題管理の効率化

第一の強みは、Jiraとの統合の深さです。
連携を有効にすると、Jiraの課題詳細画面に開発パネル（Development Panel）が表示され、その課題に紐づく情報が1か所に集約されます。

• Jiraの課題から、命名規則に沿ったブランチをワンクリックで作成できる
• 課題キーを含むコミット、ブランチ、プルリクエストが自動で紐づけられる
• プルリクエストの承認・マージ状況がリアルタイムにパネルへ反映される
• Pipelinesのデプロイ結果も表示され、「どの課題がどの環境までリリース済みか」が視覚的に追える

ここで注目すべきは、これらが単なるURLのハイパーリンクのような疎結合ではなく、イベントレベルで結合された統合である点です。
課題、コード変更、ビルド、デプロイが単一のデータモデル上で一貫して追跡される。
ソフトウェア工学の用語で言えば、トレーサビリティ（追跡可能性）が自然に確保されるわけです。

「なぜこのコードが変更されたのか」「どのリリースに含まれたのか」という問いに、ツールを横断せずに即答できる状態は、障害対応や監査対応の時間を確実に短縮します。
GitHubでJira連携を実現する場合、Marketplaceアプリの導入と設定保守という追加コストが発生しますが、Bitbucketではそれが標準機能に含まれている。
この差は、運用が数年単位に及ぶほど効いてくるはずです。

Bitbucket Pipelinesで実現するCI/CDの内製化

第二の強みが、リポジトリに標準搭載されたCI/CD機能のBitbucket Pipelinesです。
特徴は、パイプライン定義をbitbucket-pipelines.ymlという1ファイルに記述し、リポジトリ内で管理するスタイルであること。
実行環境はコンテナベースで、imageに指定したDockerイメージ上でスクリプトが走ります。

image: node:20

pipelines:
  default:              # 全ブランチのpushで実行
    - step:
        name: Build & Test
        caches:
          - node
        script:
          - npm ci
          - npm run test
  branches:
    main:               # mainブランチではデプロイまで実行
      - step:
          name: Deploy
          deployment: production
          script:
            - npm run deploy

ポイントは2つあります。
1つは、パイプライン定義自体がGitでバージョン管理される点です。
「設定の変更履歴が残らない」「誰が画面から設定を変えたのか分からない」というCI運用あるあるを、構造的に排除できる。
これはインフラをコードとして扱う思想と完全に整合します。

もう1つは、deploymentキーでステージングや本番といったデプロイ環境を宣言できる点です。
環境ごとのデプロイ履歴が蓄積され、前述のJira開発パネルにも自動反映されます。
CI/CDと課題管理が一社で閉じている構造的な利点が、ここでも発揮されているわけです。

なお、ビルド時間は従量課金の対象です。
無料枠の月50分は、開発規模が大きくなると直ぐに不足します。
その場合は有料プランへの移行か、自社環境でジョブを実行するセルフホストランナーの活用が現実的な選択肢となるでしょう。

無料枠でプライベートリポジトリを複数メンバーで共有可能

第三の強みは、無料枠の構成です。
まず歴史を押さえておきましょう。
Bitbucketは2015年の時点で「5ユーザーまでならプライベートリポジトリを無制限に作成できる」無料プランをいち早く導入しました。
当時のGitHubはプライベートリポジトリに有料プランを要求していた時代であり、小規模チームの閉じた開発でBitbucketが選ばれた理由はここにあります。

2019年にGitHubも無制限のプライベートリポジトリへ踏み切り、この点の優位性は相対的に薄れました。
ただし、Bitbucketの無料枠の価値はリポジトリ単体ではなく、開発に必要な構成要素が一社で無償提供される点にあります。

• Bitbucket Free：プライベートリポジトリ無制限、Pipelines月50分、Git LFS 1GB
• Jira Free：10ユーザーまでの課題管理
• Confluence Free：10ユーザーまでのドキュメント管理

つまり5人程度のチームであれば、バージョン管理・CI/CD・課題管理・ドキュメントという開発基盤の定型構成を、費用ゼロで整えられるわけです。
ツールごとにベンダーを選定し、設定方針を揃える手間も省ける。
リソースが限られたスタートアップや、社内ツール開発チームにとって、この「無償で完結するエコシステム」は決して軽視できないメリットでしょう。

ここまで確認した3つの強みは、いずれもAtlassianエコシステムを前提としたものです。
裏を返せば、エコシステム外で単体利用する場面では優位性が発揮しにくい。
次章では、その弱点側にあたるデメリットを検証していきます。

Bitbucketのデメリット｜GitHubと比べて弱いポイント

前章で確認した3つの強みには、共通の前提がありました。
すなわち「Atlassianエコシステムの内部にいる」という条件です。
本章では視点を反転させ、その前提が崩れたときにBitbucketが構造的に不利となる点を、3つの観点からできる限り客観的に検証します。
弱点の把握は、次章で行う3サービス比較の基礎資料にもなるはずです。

GitHub CopilotなどAI開発支援機能の差

まず、直近で最も顕著な差がついているのがAI開発支援機能です。
主要な機能の対応状況を整理すると、おおよそ次の表のようになります。

機能カテゴリ	GitHub Copilot	Bitbucket（Atlassian Intelligence）
コード補完・生成	標準搭載	非提供
チャット形式の質問応答	Copilot Chat	Rovo連携経由（Jira等が中心）
プルリクエスト要約	提供あり	提供あり（diffの要約など）
依存関係の自動更新	Dependabot	非ネイティブ

GitHub Copilotは、コード補完からCopilot Chat、プルリクエストのレビュー支援、修正候補の提示まで、コーディングの逐次的な作業に深く入り込んでいます。
一方、Bitbucket側のAI機能の中心は、JiraやConfluenceにおける要約や自然言語検索であり、Bitbucket Cloud向けにもプルリクエストの差分要約や機密情報のハードコード検知といった機能が提供されてはいるものの、コードを書く瞬間を支えるレイヤーの投資規模には明らかな差があります。
この領域は提供状況の変化が速いため、最新情報の確認は前提としていただきたいのですが、発表の規模と投入スピードを並べれば、優位の方向性は動いていないと判断するのが妥当でしょう。

公平に言えば、Copilotは有料アドオンであり、サービス本体の料金比較とは別軸の話です。
しかし「日常の開発体験にAIを組み込む」方針のチームにとって、その資産がどちらのエコシステムに蓄積されているかは、選定要因として重みを増す一方です。

サードパーティ連携とオープンソース開発への弱さ

2つ目は、エコシステムの「外向き」の広がりです。
GitHub Actionsのワークフローは、Marketplaceに公開されたアクションを組み合わせるだけで高度な自動化を組めますし、依存関係の脆弱性検知や自動更新もDependabotとして標準提供されています。
対するBitbucketは、Atlassian Marketplace自体の規模は大きいものの、アプリの中心はJiraとConfluence向けであり、Bitbucket単体で利用できる連携の選択肢は相対的に少ないのが実情です。
Dependabot相当の仕組みを構築するなら、Renovateなどの外部ツールをPipelines上で動かす形で自前実装する必要があります。

より決定的なのは、オープンソース開発との相性です。
公開リポジトリの機能自体はBitbucketにもありますが、OSSコミュニティの実質的な標準語彙はGitHubのもの――fork、スター、Issue、プルリクエストのフロー――になっています。
読者の皆さんも、OSSのREADMEに「Bitbucketで公開」と書かれたリポジトリをどれだけ見たことがあるでしょうか。
外部への公開やコントリビューション獲得を視野に入れるなら、これは致命的な弱点と言わざるを得ません。
ただし、社内の閉じた開発のみを想定するなら、この弱点は発火しません。
影響範囲は「開発の公開性」に依存するわけです。

コミュニティ規模と日本語情報の少なさ

3つ目は、情報環境です。
第2章で確認した通り、Bitbucketの利用シェアは1割程度に留まります。
この差は、そのままトラブルシューティングの情報量に波及します。

• Stack Overflow等のQ&Aサイトで、GitHubとの間では質問・回答の蓄積量が桁違いに異なる
• 日本語の技術ブログやナレッジ共有サイトでも、Bitbucket単体の深い情報は少数派
• PipelinesのYAML構文やワークスペースの権限設計など、細部でつまずいた際に参照できる事例が限られる

ここで忘れてはならないのは、エンジニアリングにおいて「情報が検索で見つかるか」が実質的なコストを規定するという点です。
GitHubであれば、エラーメッセージをそのまま検索すれば解決記事に当たる確率が高い。
Bitbucketでは、英語の公式ドキュメントやAtlassian Communityフォーラムが一次情報の中心となり、自力で読み解く負担が相対的に大きくなります。

もっとも、この弱点には緩和策があります。
公式ドキュメントの品質自体は高く、設定はbitbucket-pipelines.ymlのようにコードとして残るため、一度動いた構成をチーム資産として蓄積すれば、再現性の面ではむしろ有利です。
要するにこの弱点は「既存の知見を借りやすいか」という性質のもので、チームに経験者がいるか、障害時に自前で調査できるかによって、実害の大きさは大きく変わるでしょう。

ここまでで、強みと弱みの両輪が揃いました。
強みはエコシステム内部での深い統合、弱みはエコシステム外部への広がりの欠如です。
次章では、GitHub・GitLabを交えた3社比較として、機能と料金を定量面から突き合わせていきます。

【徹底比較】GitHub・GitLab・Bitbucketの機能と料金

ここまで、Bitbucketの強みと弱みを定性面から確認してきました。
ただ、定性的な議論にはどうしても主観が混入します。
本章では比較軸を「機能」「料金」「CI/CD」の3つに限定し、3サービスを定量面から突き合わせていきます。
なお、料金は為替や価格改定の影響を受けるため、以下の数値は2024年時点の参考値です。
最終判断の際は、必ず公式サイトで最新値を確認してください。

機能比較表で見る3サービスの違い

まず、全体像を1つの表に整理します。

機能	GitHub	GitLab	Bitbucket
無料のプライベートリポジトリ	無制限	無制限	無制限（5ユーザーまで）
標準CI/CD	GitHub Actions	GitLab CI/CD	Pipelines
AI開発支援	Copilot	GitLab Duo	Atlassian Intelligence（限定的）
セルフホスト版	Enterprise Server	Self-Managed	Data Center
エコシステムの方向性	OSSとAIで事実上の標準	DevOps統合プラットフォーム	Atlassian製品群との統合

この表から読み取れる重要な事実は2つです。
1つは、プライベートリポジトリの無制限提供が3社共通となり、かつてBitbucketの最大の差別化要素だった点がもはや優位性ではないこと。
もう1つは、競争の主戦場が「リポジトリホスティング」から「周辺機能の統合度」へ移っていることです。
GitHubはAIとコミュニティ、GitLabは計画からデプロイまでの単一アプリケーション化、BitbucketはAtlassian製品群との結合と、収斂の方向がそれぞれ異なります。
つまり機能比較とは本来、「自チームがどの機能を重心に置くか」を先に決めて初めて意味を持つものなのです。

料金プランの比較｜無料枠と有料プランの費用対効果

次に、料金を同じ粒度で並べます（いずれも1ユーザーあたりの月額、ドル建て）

プラン帯	GitHub	GitLab	Bitbucket
無料プラン	$0	$0	$0（5ユーザーまで）
中間プラン	Team：$4	Premium：$29	Standard：約$3
上位プラン	Enterprise：$21	Ultimate：約$99（年間契約）	Premium：約$6

注目すべきは中間プランの価格差です。
Bitbucket Standardの約3ドルは3社で最も安く、GitHub Teamの4ドル、GitLab Premiumの29ドルとは桁が違います。
ただし、この数字を単純に「GitLabが高い」と解釈するのは早計です。
GitLab Premiumにはコードオーナー機能や高度な権限管理、充実したCI/CD実行時間が含まれており、GitHubで同等の構成を組むとEnterpriseやアドオンの追加が必要になるケースがあります。

費用対効果を考える際の正しい式は、リポジトリ単体の月額ではなく開発基盤全体の総額のはずです。

• Bitbucket：実運用ではJiraやConfluenceの契約とセットになるため、エコシステム全体で見ると差は縮む
• GitHub：本体は安価でも、Copilot Business（$19）などアドオンを積むかで総額が変わる
• GitLab：中間プランの単価は高いが、含まれる機能の範囲が広く、外部ツールの契約を削減できる

要するに比較すべきは「安さ」ではなく、何が含まれ、何が別課金かという構造です。
既にJiraを契約している組織にとってBitbucketの追加コストは極めて小さく、逆にAtlassian製品を一切使わない組織がBitbucketを選ぶ経済的合理性は薄くなります。

CI/CD機能の比較｜Actions・Pipelines・GitLab CI

最後に、実務への影響が最も大きいCI/CDを詳しく見ます。
まず実行時間の無料枠からです。

項目	GitHub Actions	GitLab CI/CD	Bitbucket Pipelines
無料枠の実行時間（月）	2,000分	400コンピュート分	50分
中間プランの実行時間（月）	3,000分	10,000分	2,500分
セルフホストランナー	対応	対応	対応（有料プランのみ）

ここは数字の差がはっきりした箇所です。
無料枠の実行時間は、GitHubの2,000分に対してBitbucketは50分と40倍の差があります。
さらにBitbucketの無料プランは同時実行が1ジョブという制約もあり、テストスイートが成長したチームのフィードバックループを直接遅延させます。
1つ目と2つ目の行に目を向けると、GitHubが時間と並列性で優位、GitLabが中間プランの実行時間とセルフホストランナーによる実質コストの削減で優位という構図が見えてきます。

記述方式については、3社ともYAMLをリポジトリ内に置く「設定のコード化」という思想で共通しています。
例えばGitHub Actionsでは次のように書きます。

name: CI

on: push

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run test

前章のbitbucket-pipelines.ymlと見比べると、設計思想の違いが見えてきます。
Pipelinesがステップの直列構造でシンプルなのに対し、Actionsはuses:でMarketplaceの再利用可能なアクションを差し込む構成であり、チェックアウトや言語環境の構築を自前で書く必要がありません。
GitLab CI/CDもYAMLベースですが、stagesによるジョブ依存関係の管理と、セルフホストランナーの無償提供が強みです。
ランナーを自社サーバーに置ければ実行時間の従量課金を回避できるため、オンプレミス寄りの組織では実質コストが逆転する可能性すらあります。

一方、Bitbucket Pipelines単体のスペックは決して最上位ではありません。
しかしデプロイ結果がJiraの開発パネルに自動反映される体験は他社の追従を許しておらず、CI/CDの価値を「パイプラインの性能」ではなく「開発フロー全体の統合度」で測るなら、十分に戦える立ち位置です。

以上、機能・料金・CI/CDの3面から確認した結果、すべての軸で勝つサービスは存在しないことが定量的にも裏付けられました。
では、どの軸を重視するチームがBitbucketを選ぶべきなのか。
次章では、チームの類型ごとに適合を判定していきます。

Bitbucketが向いているチームの特徴｜こんな開発体制なら最適解

前章の定量比較が示した結論は「全軸で勝つサービスは存在しない」というものでした。
ということは、議論の焦点は「どれが一番か」から「どの条件のチームにどれが合うか」へ移るはずです。
本章では、これまで確認してきた強み・弱み・料金構造を統合し、Bitbucketが最適解となりうる3つのチーム類型を提示します。
逆に言えば、3つすべてに当てはまらないチームには、他の選択肢が合理的である可能性が高いということです。
そもそも、自チームはどの類型に該当するのか。
判断材料として読み進めてみてください。

Atlassian製品をすでに導入しているチーム

1つ目は、JiraやConfluenceを既に運用しているチームです。
この条件の有利さは、単なる相性の問題ではありません。
まず経済面では、前章で確認した通りBitbucket Standardの月額約3ドルは中間プランで最安水準であり、エコシステム全体の総額に与える影響が極めて小さくなります。
次に運用面では、SSO（SAML）によるアカウント一元管理や、権限設定方針の共有といった管理コストの統合効果が効きます。

そして何より、第3章で確認したJira開発パネルによるトレーサビリティという最大の強みがフルに発揮されるのが、この類型です。
逆に、Jiraを使っていないチームがBitbucketを選んでも、この強みはほとんど発火しません。
「連携の深さ」という差別化要素は、前提たるエコシステムがあって初めて価値を持つわけです。

優先度の判断には、次のチェックリストが使えます。
2つ以上当てはまるなら、Bitbucketの評価を上げて良いでしょう。

• Jiraを課題管理の主軸として運用している
• Confluenceで設計ドキュメントを管理している
• Atlassian Guard等でSSOを一元管理している
• 開発パネルを活用したワークフローをすでに構築している

プライベートリポジトリ中心で開発する小規模チーム

2つ目は、クローズドな開発を5人前後で進めるチームです。
NDAの制約が厳しい受託案件、社内システムの開発、まだ外部公開を想定しないスタートアップのプロダクトなどが該当します。

第4章で確認した通り、Bitbucketの弱点はOSSコミュニティやサードパーティ連携といった「外向き」の領域に集中していました。
つまり、この弱点は開発を外部に公開しない限り発火しない。
影響範囲の制御という観点で見れば、閉じた開発ほど弱点が切り捨てられ、強みだけが残る構図になります。

無料枠の構成を改めて並べると、この類型との適合は明白です。

• Bitbucket Free：プライベートリポジトリ無制限（5ユーザーまで）
• Jira Free：10ユーザーまでの課題管理
• Confluence Free：10ユーザーまでのドキュメント管理

バージョン管理から課題管理、ドキュメント管理までを月額0円で、しかも単一ベンダーで揃えられる。
ツールごとに選定し直し、設定方針を揃えるという隠れコストを考慮すれば、小規模チームにとってこの構成は十分に合理的です。

PipelinesだけでCI/CDを完結させたいチーム

3つ目は、CI/CDに広大なエコシステムを求めず、シンプルなパイプラインで十分なチームです。
Pipelinesの設計思想は、bitbucket-pipelines.ymlの1ファイルに直列のステップを書くというもの。
GitHub Actionsのような再利用可能なアクション群はありませんが、裏を返せば学習コストが低く、パイプライン全体を脳内で把握しやすい性質があります。

ビルド時間の無料枠が月50分と少ない点は、前章の通り留意が必要です。
ただし、この制約は有料プランへの移行か、セルフホストランナーの活用で回避できます。
ランナーでジョブを実行するには、ステップにruns-onを記述します。

pipelines:
  default:
    - step:
        runs-on:
          - self.hosted
          - linux.shell
        script:
          - ./build.sh

自社サーバー上でジョブを実行できれば従量課金を実質的に回避でき、さらに社内ネットワークにあるテスト用データベースや検証環境へ直接アクセスできるようになります。
セキュリティポリシーの都合で、ソースコードもビルド環境もクラウドに置きにくいチームにとって、この構成は現実的な解と言えるでしょう。

本章の内容を、判断材料として1つの表に圧縮しておきます。

チームの条件	Bitbucketの適合度	備考
Atlassian製品を運用中	高	開発パネルによる統合が最大の旨味
5人前後のクローズド開発	高	無料枠で開発基盤が完結
OSS公開・外部コントリビューション前提	低	GitHubが合理的
大規模なCI/CDの並列実行が必要	低	ActionsやGitLab CIが優位

表が示す通り、Bitbucketの適合は「Atlassianエコシステムの内部にどれだけいるか」でほぼ決まります。
この条件から外れたチーム――AI機能を主軸に置きたい、OSSを運営したい、CI実行時間を大量に必要とする――には、移行という選択肢が現実味を帯びてきます。
次章では、その移行を検討すべきケースと実際の手順を確認していきます。

BitbucketからGitHub・GitLabへ移行すべきケースと手順

前章の適合表で、自チームが「低」と判定された読者もいるでしょう。
では、すぐに移行すべきでしょうか。
答えは否です。
移行とは「Bitbucketが終わるから逃げる」行為ではなく、自チームの開発要件と各サービスの強みを再照合した結果として行う、戦略的な再配置であるべきです。
本章では、行き先ごとの移行ケースを整理し、その上で実際の手順と落とし穴までを確認します。

GitHubへ移行すべきケース

1つ目の類型は、次の条件に当てはまるチームです。

• AI開発支援の導入を開発体験の中核に置いている（Copilotへの期待）
• OSSとして公開する、または外部コントリビューションを受け入れる
• Dependabotなど、周辺エコシステムの充実度を重視する
• 技術採用の面から、開発環境の標準性を対外的に示したい

中でも決定的なのは、第4章で確認したOSSとの相性の問題です。
forkとプルリクエストを軸としたコントリビューションフローは、GitHubの語彙で設計されています。
公開を視野に入れた時点で、選択肢は実質的にGitHub一択になると言っても過言ではありません。

また、開発メンバーの採用・育成という観点も見逃せません。
GitHubの利用経験は業界標準のスキルとして一般化しており、新メンバーが既存知識をそのまま活かせます。
学習コストという観点では、コミュニティ規模の差がそのままオンボーディングの容易さの差になるわけです。

GitLabへ移行すべきケース

2つ目の類型は、次の条件のチームです。

• データ主権や規制対応の観点から、ソースコードを自社管理下に置く方針を維持したい
• Jiraに依存しない、単一アプリケーションでの計画〜デプロイの完結を望む
• セキュリティスキャンをCI/CDに組み込みたい

Bitbucket Server終了後、「手頃なオンプレミス構成」を失った組織にとって、GitLab Self-Managedは重要な受け皿です。
セルフホストランナーは無償で提供され、ジョブを自社サーバーで実行すれば実行時間の従量課金を実質的に回避できます。
さらに、SASTや依存関係スキャンといったセキュリティ機能がプラットフォームに統合されており、「パイプラインにセキュリティを組み込む」という要件に対しては3社で最も完成度が高い立ち位置です。
Jiraを運用しておらず、Bitbucketの利点を享受できていなかったチームの移行先として、GitLabは自然な帰結と言えるでしょう。

リポジトリ移行の基本手順と注意点

行き先を決めたら、次は手順です。
Gitリポジトリの本質はコミットオブジェクトの有向非巡回グラフにほかなりませんから、履歴ごと移すこと自体は標準コマンドで実現できます。

# 移行元から全参照を含むミラーを取得
git clone --mirror git@bitbucket.org:myworkspace/example.git

# 移行先へすべてのブランチ・タグをpush
cd example.git
git push --mirror git@github.com:myorg/example.git

--mirrorオプションにより、リモート追跡ブランチを含むすべての参照がそのまま複製されます。
ただしこのコマンドはforce pushと同様に移行先を上書きするため、空の新規リポジトリに対して実行するのが安全です。
移行対象の全体像と落とし穴は、次の表の通りです。

移行対象	移える方法	注意点
履歴・ブランチ・タグ	mirror push	LFSオブジェクトは参照に含まれないため、事前にgit lfs fetch --allが必要
Issue・プルリクエスト	標準手段では移行不可	外部ツールを使うか、移行元を読み取り専用で保管
CI/CD設定	YAMLを書き直し	構文と概念モデルが異なるため、変換より設計し直しが推奨
権限・連携設定	移行先で再構築	保護ブランチ、Webhook、変数・シークレットは再設定必須

特筆すべきは、gitの世界の外にある資産は一切移らないという点です。
Issueとプルリクエストの議論履歴は、多くのチームにとって事実上の設計ドキュメントです。
現実的な落とし所は、「過去の履歴は参照可能な状態でBitbucketに残し、以降の開発を移行先で行う」という併用期間を設けることでしょう。

手順の最後は、CI/CD設定の書き直しです。
前章で見た通り、PipelinesとActions、GitLab CI/CDでは概念モデルが異なります。
逐語的に翻訳するのではなく、パイプラインの目的に立ち返って設計し直す方が、結果的に保守しやすい構成になります。

以上の通り、リポジトリそのものの移行ハードルは決して高くありません。
高くなりがちなのは、周辺資産とワークフローの移行です。
移行の成否は技術力ではなく計画の精緻さで決まる、と総括できます。
いよいよ最終章です。
これまでの検証を総括し、「オワコンか否か」という最初の問いに、改めて答えを下しましょう。

まとめ：Bitbucketはオワコンか？開発チームの賢い選択基準

本記事の冒頭で提示した問いは、「Bitbucketは本当にオワコンなのか」でした。
7つの章を通じて確認してきた事実を、ここで一度整理します。

• 市場シェアは約1割と、GitHubに対して明確に劣位である
• 一方で、Bitbucket Server終了後もCloudとData Centerは継続提供されており、Atlassianに事業撤退の兆候はない
• Jira連携によるトレーサビリティ、Pipelinesによる統合CI/CD、無料枠での開発基盤構築という3つの強みが実在する
• AI開発支援、OSS適合性、情報量の3点で、GitHubとの差は構造的に開いている
• 料金面では中間プラン最安である一方、CI実行時間の無料枠は著しく狭い
• 適合チームの条件は「Atlassianエコシステムの内部にいること」に集約される

結論：オワコンではなく「選ばれる条件が変わった」

これらの事実を突き合わせれば、答えは導けます。
Bitbucketはオワコンではない。
ただし、「誰にでも使える万能ツール」としての地位は終わった、というのが本記事の結論です。

そもそも「オワコン」という言葉には2つの含意があります。
1つは「提供が終わる」、もう1つは「使う理由がなくなる」です。
前者は事実と異なります。
AtlassianはCloudとData Centerの両輪で継続を明言しており、Jira・Confluenceとの統合戦略の中核にBitbucketを置き続けています。
後者については、条件次第というのが正確なところです。
エコシステム内部にいるチームには今なお明確な合理性があり、外部のチームにはほぼない。
Bitbucketの変質とは、衰退ではなく、この二極化の進行だったと総括すべきでしょう。

開発チームのための選択基準

最後に、本記事の検証結果を選択基準として圧縮します。
次の表が、読者の皆さんの意思決定のチェックリストになるはずです。

重視する条件	最適解	根拠となった章
Jira・Confluenceとの統合とトレーサビリティ	Bitbucket	第1章・第3章
5人前後のクローズド開発を低コストで開始	Bitbucket	第3章・第6章
AI開発支援と開発体験の先進性	GitHub	第4章・第5章
OSS公開と外部コントリビューション	GitHub	第4章・第7章
セルフホストと統合セキュリティスキャン	GitLab	第5章・第7章

選定のアプローチとしては、まず自チームが第6章の適合条件に該当するかを確認し、該当しない場合は第7章の移行先判断基準に従って行き先を定める、という2段構えが合理的です。
その際、忘れてはならない視点が2つあります。

1つは、評価対象を「サービス単体」ではなく「開発基盤全体の総額」にすること。
リポジトリの月額だけを見るとBitbucketの優位は小さく見えますが、既にJiraを契約している組織では連携の維持が最大のコスト削減になります。
逆に、単体で安く見えても、周辺ツールの契約と設定保守を合算すれば総額は逆転しうるのです。

もう1つは、移行コストはリポジトリ本体より周辺資産に潜むこと。
第7章で確認した通り、Gitの履歴の移行はmirror pushで一瞬ですが、Issueやプルリクエストの議論、CI設定、権限設計は手作業の再構築が必要です。
「少し不満がある」程度なら移行せずとも良いですが、「戦略的にAIやOSSへ舵を切る」なら、併用期間を設けた計画的な移行が勝ち筋になります。

最後に

道具選びの本質は、常に「自チームの要件」を起点にすることです。
流行やシェアという周囲の引力に引っ張られて移行を繰り返すのは、エンジニアリング資源の最も非効率な使い方でしょう。
逆に、要件が明確なら、シェア1割の選択肢が最適解であることには何の矛盾もありません。

Bitbucketは、Atlassianの世界に住むチームにとっては依然として強力な武器であり、その外に住むチームにとってはレガシーの残滓に過ぎない。
オワコンか否かを問う前に、「自チームはどの世界に住んでいるのか」を定義すること。
それが、本記事を通じてお伝えしたかった選択基準の核心です。
読者の皆さんの次の意思決定が、データと要件の両面から裏付けられたものであることを願っています。