Mercurialのシステム開発は、無料の分散型バージョン管理を中心に、周辺の開発サービスを組み合わせて作る基盤です。
導入では既存の資産と必要な開発基盤を見極め、自社運用、クラウド、企業向け基盤、段階移行のうち、運用体制に合うものを選びます。
▼関連記事一覧
・Mercurialのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Mercurialのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Mercurialのシステム開発の見積相場や費用/コスト/値段について
・Mercurialのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Mercurialのシステムの定義
Mercurialは、無料で使える分散型のソースコード管理ツールです。各開発者がローカルにリポジトリと履歴を持つため、ネットワークにつながらない間も、コミットや差分確認を進められます（出典：Mercurial公式「About」、2025年確認）。このツールに開発向けのサービスを加えた運用環境を、Mercurialのシステムと呼びます。
分散型バージョン管理が中心
Mercurialは、開発者のPCにもローカルリポジトリと変更履歴を保存します。そのため、共有サーバーが一時停止しても、ローカルで履歴確認やコミット、ブランチ作業を続けられる点が特徴です。
基本の操作は、hg cloneで複製し、hg addとhg commitで変更を記録する流れです。共有先とは、hg pullとhg pushで同期します。
クライアント導入だけでは足りない点
業務で使うには、Mercurial本体の導入に加えて、要件を満たす設計が必要です。そこで、リモートリポジトリへのHTTPSまたはSSH接続と、利用者・グループ単位の権限を設計しておきます。
さらに、コードレビューやCI/CDから、監査ログ、バックアップ、障害監視までを、一つの運用設計に含めます。退職者のアカウント停止や、契約終了時のデータ返却も、あらかじめ決めておきます。これらが未設定のまま導入されると、後からセキュリティや法務の課題が表面化します。
Mercurialのシステムの構成要素
構成は、手元の作業環境から共有リポジトリを経て、認証・権限、開発プロセス、運用保護へと広げて検討します。最初から高機能な基盤にはせず、リポジトリ数と利用者数に加えて、機密性やリリース頻度を基準に、必要な機能を選びます。
リポジトリと通信経路
中心にあるのは、ソースコードと履歴を保管するMercurialリポジトリです。共有先へはHTTPSまたはSSHで接続し、認証情報やSSH鍵を管理します。
リポジトリごとに、所有者、読み取りだけの利用者、書き込みができる開発者を決めます。レビューを担当する人は、別に決めておきます。
誰でもpushできる状態は、避けておきます。大容量ファイルや生成物を無制限に格納すると、cloneやバックアップが遅くなります。そのため、成果物の保管先と役割を分けます。
認証・権限・監査
SSOや社内ディレクトリとの連携、二要素認証、リポジトリ・グループ単位の権限設定ができるかを確認します。ログインやclone、pushから、権限変更、レビュー承認、管理者操作まで、操作を監査ログに残します。
監査ログの保存期間と検索方法は、先に決めておきます。また、共有アカウントや長期間使われる個人トークンが残っていると、認証を強化してもリスクは下がりません。
レビュー・CI/CD・外部連携
チーム開発では、変更をレビューしてから保護されたブランチへ取り込む流れが欠かせません。課題管理やチャット通知を連携させ、テスト自動化からデプロイ、成果物保管までをつなぐと、コミットからリリースまで追跡できます。
代表的なリポジトリで、CI/CDを試します。pushからテスト開始までの時間、失敗時の通知と再実行、秘密情報の扱いは、PoCで確認します。
Mercurialのシステムの種類
選択肢の中心は、自社運用、Mercurial対応クラウド、企業向け商用基盤です。そのほかに、Gitへの段階移行と、周辺業務の独自開発があります。差分管理の機能は一から作らず、標準機能と既存サービスを組み合わせるのが基本です。
OSSを組み合わせた自社運用
基本の構成は、Mercurial本体、Web UI、SSHサーバーです。さらに、リバースプロキシやバックアップ、監視を加えます。ライセンス費を抑えやすく、ネットワークやデータ保管場所を自社で管理できる点が利点です。
一方で、レビューや細かな権限、SSOの設計から、脆弱性対応と障害復旧まで、自社で担う必要があります。そのため、構成管理ファイルや手順書、復旧訓練の記録を残し、担当者が異動しても運用できるようにします。
Mercurial対応クラウド
Mercurial対応クラウドでは、HTTPSやSSH、Web UIをまとめて利用できます。課題管理やマージリクエスト、CIランナーも使えます。環境構築を短縮でき、チームの増減にも対応しやすい方式です。
契約前には、データ所在地やバックアップ保持、SSO、サポート時間を確認します。CIやストレージの従量課金の条件も、あわせて見ておきます。
Mercurialのホスティングと、利用量に応じたCI/CD課金を組み合わせて提供するサービスもあります（出典：Mercurial対応ホスティングの公式機能一覧、2026年確認）。
認証・監査を重視する企業向け基盤
複数の部署や多拠点で使う場合は、SSOやグループ権限、監査ログを備えた基盤が候補になります。バックアップやAPI、冗長化、サポート窓口の有無も、候補を絞る材料になります。ライセンス費はかかりますが、認証や監査を個別に開発する部分を減らせる場合があります。
候補を比べるときは、利用者数やCPU・メモリ、ストレージを揃えたうえで、バックアップ世代や障害時の目標復旧時間も同じ条件で比べます。
Gitへ段階移行する構成
現役の一部リポジトリを先に移し、残りは保守運用しながら進める方法です。人材採用や連携サービス、レビュー機能の選択肢が広がる一方で、二つの運用ルールが並立する期間が生じます。
並立する期間があるため、移行の完了条件や凍結日を先に決め、併用が恒久化しないようにします。旧環境の参照期間と問い合わせ窓口も、決めておきます。
MercurialとGitの比較
選ぶときは、ソフトウェアの優劣よりも、既存資産とチームの習熟度を見ます。さらに、ホスティング機能や採用市場、移行費用も判断材料になります。
新規案件で周辺サービスを重視するなら、Git系が有利になりやすいです。一方で、既存の履歴や運用ノウハウを大切にするなら、継続運用と段階移行を比べることになります。
分散型という共通点
MercurialとGitは、どちらも開発者がローカルで履歴を持つ分散型バージョン管理です。基本の概念も共通しており、コミットやブランチ、マージを中心に、タグやリモートとの同期も含まれます。
移行では、コマンド名だけを置き換えるのではなく、業務フローとして見直します。ブランチ運用やレビュー、CIを含め、権限とリリース手順まで確かめます。
Mercurial固有の運用の確認
Mercurialには、公開状態を示すphasesや、bookmark、named branchがあります。さらに、履歴を扱うevolve・topics系の拡張やフック、revset検索も使えます。
公開済みの変更を書き換えにくい設計は、リリースブランチの事故防止に役立ちます。
一方で、拡張を増やしすぎると、担当者が変わったときに運用を再現できません。採用する機能を標準化し、設定ファイルとテストケースも管理します。
TCOと人材を含めた採否の判断
ライセンスが無料でも、運用サービスや人材が限られると、保守や教育、障害対応の費用が増えます。一方で、既存チームが習熟しているなら、移行よりホスティングや認証の刷新の方が安全な場合もあります。
判断表では、導入費に加えて、3年間の保守費と教育費を比べます。さらに、移行費や停止リスク、採用難易度も並べます。
Mercurialのシステム開発・導入の進め方
導入は、現状の棚卸しから始め、要件定義とPoC、設計を経て、パイロットから段階展開へ進みます。最後は運用の改善に移ります。
既存環境を残す場合も移行する場合も、まずは代表的なリポジトリで検証してから、本番計画に入ります。検証では、clone、push、レビューのほか、CIや復旧も確かめます。
1. リポジトリと利用状況の棚卸し
リポジトリごとに、所有者、最終更新日、容量を一覧にします。履歴の長さも、一覧に加えます。そのうえで、ブランチやbookmark、phase、subrepoの使い方を洗い出します。
フックや外部連携、CIジョブの有無を確かめます。利用者と機密情報の扱いも、同じように確かめます。
放置されたリポジトリまで移行対象に含めると、不要な検証と保管費が増えてしまいます。そのため、必要な履歴の範囲とアーカイブの扱い、削除承認者を決めておきます。
2. 要件定義とPoCの実施
要件には、利用者数と同時アクセス、データ所在地を含めます。さらに、認証方式と権限粒度、レビューとCI/CDも押さえておきます。加えて、監査とバックアップ、目標復旧時間、サポート時間も含めます。
PoCでは、ネットワーク断や競合する変更、誤ったpushを試します。アカウントの無効化や、バックアップからの復旧も確かめます。
合格基準は、測れる数字で決めておきます。たとえば、clone時間や復旧時間、テスト成功率を挙げられます。監査ログを検索できるかも、基準に加えます。
3. 権限・連携・バックアップの設計
本番設計では、命名規則やブランチ保護、レビュー承認数を文書にまとめます。秘密情報の扱いやログ保存期間も、同じ文書に書きます。さらに、バックアップ世代や暗号化、監視通知も含めます。
CI/CDは、テスト用、ステージング用、本番用で権限と秘密情報を分けます。そのうえで、バックアップから定期的に復旧し、履歴や設定、権限、CI定義まで戻せるかを確かめます。
4. パイロットと段階展開
代表チームとリポジトリを使い、操作やレビュー、CI失敗時の対応を確かめます。リリースや問い合わせの流れも、あわせて見ておきます。
教育資料には、cloneからpushまでの基本操作を入れます。加えて、誤操作の取り消しやコンフリクト解消、緊急リリースの手順を含めます。障害時の連絡先も、同じ資料に載せます。
問題が出たときは、チームを責める前に、標準ルールや画面の分かりにくさを直します。そのうえで、対象を広げていきます。
Mercurialのシステムの費用相場
Mercurial本体は無償です。ただし、導入総額は、調査や設計、移行、認証にかかる費用で決まります。
CI/CD、バックアップ、監視の費用も加わり、教育や保守を含めて総額を見ておく必要があります。
以下の金額は、国内業務システム案件と公開クラウド料金に基づく推定値です。Mercurial専用の国内受託案件に共通する公定価格ではないため、予算のたたき台として使います。
▶ 詳細はこちら：Mercurialのシステム開発の見積相場や費用/コスト/値段について
規模別の初期費用と期間
現状調査とPoCは50万〜200万円で、期間は2〜8週間が目安です。小規模な自社運用は、300万〜800万円で2〜4か月程度です。
中規模の業務開発基盤は、800万〜3,000万円で4〜9か月程度です。一方で、多拠点や高可用性、災害対策、厳格な監査が必要な大規模基盤は、3,000万円〜1億円以上で、9か月〜2年以上となる場合があります。
これらは、機能と体制から算出した推定値です。実際の費用と期間は、利用者数や要件で変わります。
移行費用を左右する履歴と連携の量
MercurialからGit系基盤への移行は、500万〜2,000万円で、2〜6か月程度が目安です。履歴やタグ、ブランチ、作者情報だけに移す範囲を絞る場合は、費用を抑えられます。
一方で、subrepoやフック、CI定義まで再現すると、工数が増えます。さらに、課題やレビュー、権限、外部連携も含めると、いっそう膨らみます。
全履歴が不要なアーカイブは現行ソースだけを保存し、現役の重要リポジトリは高忠実度で移す方法もあります。
ランニングコストの項目別比較
月額または年額の見積もりは、次のとおり費用項目を分けて比べます。
- 利用規模：ユーザー数、ストレージ、通信量に応じた料金
- 実行・保護：CI実行時間、バックアップ容量、監視の費用
- サービス：サポートと追加環境の費用
公開されている料金には、10席込みで月額80ドル、180ドル、600ドルの三段階のプランもあります（出典：Mercurial対応SCMクラウドの公式料金表、2026年確認）。
席数やバックアップ頻度によって、条件は変わります。そのため、為替や税、初期設定費、データ移行費を加えた年間総額で比べます。
業務システムの保守運用費は、初期開発費の年15〜25％程度を目安にすることがあります。
保守の金額は、脆弱性パッチやOS・Pythonなどの実行環境の更新によって変わります。障害対応やリポジトリ復旧訓練、アカウント管理の有無も、金額に関わります。保守契約では、作業項目と対応時間帯を確認します。
Mercurialのシステム開発会社・ベンダーの選び方
ベンダーの説明だけで判断せず、どこまで対応できるかを確かめます。対象は、残置運用やホスティング刷新、Git移行、CI/CD再設計です。国内の窓口や時差、データ返却、障害時の責任分界も、同じ条件で比較します。
Mercurial対応の証拠の確認
実績の件数だけでなく、Mercurialのバージョン管理を説明できるかを確かめます。phasesやbookmark、履歴変換を、どう扱うかも示せるかを見ます。
subrepoやフック、Web UI、レビューも対象に含めます。認証とCI/CDも、確かめる範囲に入ります。代表的なリポジトリで検証できるかも、見ておきます。
成果物には、構成図や移行前後の差分、テスト記録を含めます。運用手順書や復旧手順、設定ファイルの引き渡しまで含めると、担当者の経験を比べられます。
セキュリティと運用体制の比較
まず、TLSやSSH鍵、二要素認証、SSOの担当を決めます。さらに、最小権限や監査ログ、不変バックアップの担当範囲も分けます。脆弱性対応や監視、復旧テストの担当も、分けて決めます。
クラウドでは、所在地や委託先、再委託を確認します。また、削除証明とSLAも見ておきます。
自社運用では、OS・Python・暗号ライブラリの更新責任と、夜間・休日の障害対応を契約に明記します。ソースに個人情報や機密情報がある場合は、委託先の監督とアクセス記録も確認します。
RFPの確認項目と数値化
RFPには、見積もりと受入確認に必要な条件を、次のとおり記載します。
- 規模：リポジトリ数と総容量、最大ファイル、履歴保持期間、利用者数、同時実行数
- 基盤要件：認証方式、権限単位、CI実行時間、バックアップ世代
- 運用条件：目標復旧時間、ログ保存期間、サポート時間
- 移行と受入：移行対象と、検証可能な受入基準
判断の基準は、「十分な性能」や「安全に移行」といった言葉よりも、数字で確かめられる条件にします。たとえば、clone時間や復旧時間、移行後の変更件数、CI成功率が挙げられます。
▶ 詳細はこちら：Mercurialのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら：Mercurialのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
▶ 詳細はこちら：Mercurialのシステム開発の発注/外注/依頼/委託方法について
Mercurialのシステムのセキュリティ対策
ソースコード管理基盤は、知的財産を保管する場所でもあります。そのため、まず通信と認証、権限を分けて守ります。次に、秘密情報やログ、バックアップ、脆弱性対応も、分けて対策します。
OSSでも、保守は必要です。利用しているバージョンと依存ライブラリの更新経路は、運用に組み込みます。
アクセスの最小権限化
共有アカウントをなくし、個人アカウントと多要素認証を基本にします。権限は、読み取りや書き込み、管理やデプロイごとに分けます。
リリース用のサービスアカウントには、期限と目的を設定します。SSH鍵やトークンは洗い出し、退職や異動、委託終了のタイミングで無効化します。
パッチと復旧の定期運用
Mercurial 7.0ではパッケージング方式が変わり、7.0.1ではzstdに由来する脆弱性に対応しました（出典：Mercurial公式リリースノート、2025年）。そのため、バージョン更新はセキュリティ対応としても発生します。
Mercurialの版に加えて、PythonやOSの版を台帳にまとめます。さらに、暗号ライブラリやWebサーバーの組み合わせも記録します。検証環境で更新してから、本番へ適用します。
改ざんに備えたバックアップ
オンラインのバックアップは、侵害やランサムウェアによって、本体と同時に消される恐れがあります。複数世代と別環境を組み合わせ、アクセス制御や改ざん防止、暗号化も加えます。
復旧用の管理者権限は、通常の運用から分けます。四半期に一度など周期を決め、履歴や設定、権限、CI定義を戻して、目標時間に収まるかを確認します。
MercurialからGitへ移行するときの注意点
移行は、ソースを移した後も確認すべき点が残ります。公式移行ガイドでは、ソースと履歴は移せる一方で、設定やコラボレーション情報は別途確認が必要とされています（出典：大手コードホスティングの公式移行ガイド、2026年確認）。
発注側は、移行の前に、残す情報、作り直す機能、アーカイブする資産を決めておきます。
高忠実度移行とスナップショット移行の使い分け
高忠実度移行は、ソースや変更履歴を、できる限り再現する方式です。タグやブランチ、作者情報も再現の対象です。現役の基幹リポジトリや、監査対象の履歴に向きます。
一方、スナップショット移行は、現在のソースだけを新しいリポジトリに登録します。古い試作や参照用のアーカイブに適します。
すべてを高忠実度で移すと、費用と検証期間が膨らみます。そのため、リポジトリごとに重要度を判定します。
履歴・CI・権限の個別検証
任意の過去時点へ戻れるか、タグが同じ成果物を指すかを確認します。さらに、作者と時刻が保たれるか、ブランチ関係を説明できるかも見ます。最新のソースが一致していても、それだけで十分とは言えません。
次に、CIのトリガーやテスト結果、成果物、デプロイ権限を確認します。また、利用者のclone・push・レビュー権限と、拒否操作が監査ログに残ることも検証します。
並行稼働の終了条件
旧環境と新環境を長く並行稼働させると、二重コミットや差分の取りこぼし、問い合わせ先の混乱が起こります。そのため、凍結日時や最終同期、切り戻し期限を決めます。利用者への告知も、あわせて行います。
旧環境の参照期間と、廃止を承認する人も決めます。移行後すぐには旧リポジトリを削除せず、契約や監査、法務上必要な期間は読み取り専用で保管します。
Mercurialのシステム導入で起こりやすい失敗
失敗の多くは、Mercurialの機能不足ではなく、周辺の運用設計を後回しにすることで起こります。導入前には、予算やCI/CD、復旧、独自拡張の扱いを確認しておきます。
無料ソフトだけを前提にした予算
ライセンス費が無料でも、調査や設計、認証、バックアップには費用がかかります。さらに、監視やCI、教育、保守も、費用の対象になります。
判断は、初期費用と月額費用に加えて、障害対応や脆弱性対応、担当者の引き継ぎ、将来の移行費用まで含むTCOで行います。
CI/CDと復旧テストの後回し
cloneやcommitができても、テスト自動化や成果物、デプロイが整わなければ、リリース品質は安定しません。失敗時の通知も欠かせません。
そのため、CI/CDはPoCに含め、バックアップからの復旧も受入条件にします。障害時には、誰が判断し、どのデータから何分以内にどの状態へ戻すかを決めておきます。
独自拡張の増えすぎ
フックや拡張機能で要望のすべてに応えると、更新や移行のたびに再検証が必要になります。そのため、標準機能と設定、外部連携、独自開発の境界を決めます。独自拡張には、所有者、テスト、廃止条件を設定します。
個別チームにしか分からない運用を、全社の標準にしないことも、長期保守では大切です。
Mercurialのシステムに関するよくある質問
導入前には、リポジトリ数や利用者、認証を、自社の状況に当てはめて判断します。CI/CDや移行要件も、同じ考え方で見ます。
Mercurialを新規採用しても問題ありませんか？
採用は可能ですが、対応ホスティングやCI/CDを確認します。さらに、教育や人材確保、将来の移行方針も見ておきます。
新規採用では、3年後の担当者やサービス更新、監査要件を含むPoCを行います。そのうえで、Git系基盤と同じ評価軸で比べます。
Mercurialのシステムは無料で構築できますか？
Mercurial本体は無償ですが、業務システムの構築と運用は無料ではありません。インフラ面では、サーバーとストレージ、バックアップ、監視が要ります。
認証やCI実行、設定も、準備しなければなりません。移行や教育、保守もかかります。
初期費用と3年間のランニングコストを合算して比較します。
Gitへ移行すると履歴は消えますか？
移行方式によります。変換ツールと検証を使い、ソースと変更履歴を移す方法があります。課題やレビュー、権限、CI定義などの周辺情報は、別途対応が必要です。
そのため、高忠実度移行か、現行ソースだけのスナップショット移行かを決めます。移行前後の差分と、過去リリースの再現性も確認します。
Mercurialをクラウドで利用できますか？
利用できます。Mercurial対応クラウドには、HTTPSやSSH、Web UIを備えたものがあります。課題管理やレビュー、CI/CDまでをまとめて提供するものもあります。
SSOや二要素認証、データ所在地を確認します。さらに、バックアップや契約終了時のエクスポート、サポート時間も見ます。CIやストレージの従量課金も、確かめます。
開発会社へ依頼するときの最初の資料は何ですか？
リポジトリ一覧や容量、利用者と権限、認証方式をまとめます。ブランチやphaseの運用も、資料に入れます。
CI/CDや外部連携、バックアップ、監査要件を書き添えます。納期や予算、残置か移行かの仮説も記載します。
未確定の事項は、はっきりと示します。調査とPoC、本番構築を分けた提案を依頼すると、比較しやすくなります。
まとめ
判断の要点
Mercurialのシステムは、無料の分散型バージョン管理を中心とする開発基盤です。その周りに、リポジトリや認証・権限、レビューを組み合わせます。さらに、CI/CDや監査、バックアップ、監視も加えます。
新規採用はもちろん、既存環境を残す価値やホスティング刷新、Gitへの段階移行も比べます。比べる視点は、技術、業務、人材、TCOの四つです。
着手前の最終確認
まずは、リポジトリと利用状況を洗い出し、代表データでPoCを行います。見積もりは、ライセンス費だけで決めず、調査や移行、認証を分けて考えます。CI/CDやバックアップ、教育、保守も、項目ごとに見積もります。
ベンダーに依頼する場合は、対応実績や検証成果物、セキュリティ責任をRFPに含めます。加えて、SLAや契約終了時のデータ返却も書き添えます。こうした条件を先に決めておくことが、長期的な失敗を防ぐ近道です。
▼関連記事一覧
・Mercurialのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Mercurialのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Mercurialのシステム開発の見積相場や費用/コスト/値段について
・Mercurialのシステム開発の発注/外注/依頼/委託方法について
▼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を創業。