Mercurialのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Mercurialのシステム開発は、分散型バージョン管理の仕組みに認証・レビュー・CI/CD・バックアップを組み合わせ、開発基盤として安全に運用する進め方です。

「Mercurialの資産をこのまま使い続けてよいのか」「Gitへ移行した方がよいのか」「社内サーバーとクラウドのどちらが適切なのか」と迷っている担当者は少なくありません。Mercurialはコマンドをインストールするだけのツールではなく、リポジトリ、権限、認証、コードレビュー、CI/CD、障害復旧までを含めて設計して初めて、業務で使えるシステムになります。本記事では、要件整理、製品・構成の選定、設計開発、テスト、稼働、定着の6フェーズに分け、判断基準、チェックリスト、費用相場、見積もりの確認ポイントを具体的に解説します。

▼全体ガイドの記事
・Mercurialのシステム開発の完全ガイド

Mercurialのシステムとは？全体像を整理します

Mercurialは、各開発者のローカル環境にリポジトリと変更履歴を持たせる分散型バージョン管理システムです。開発者はclone、commit、pull、push、mergeなどを使って変更を共有します。したがって、業務で「Mercurialのシステム」を構築する場合は、サーバーを1台置くことではなく、開発者の作業から本番リリース、監査、復旧までの流れを一つの運用基盤として設計することが重要です。

中核になるのは、ソースコードと履歴を管理するMercurialリポジトリです。そこへHTTPSまたはSSHの接続、Web UI、コードレビュー、課題管理、LDAPやActive Directoryとの認証連携、SSO、リポジトリ単位の権限、CI/CDランナー、監査ログ、バックアップ、監視を組み合わせます。Jira、Redmine、チャット、成果物保管などと連携する場合は、どのシステムを正とするか、連携失敗時に誰が再実行するかまで決めておく必要があります。

特に既存環境では、リポジトリ数と容量だけを数えると漏れが生じます。サブリポジトリ、フック、bookmark、named branch、phase、topic、evolve関連の設定、CIジョブ、デプロイ鍵、リリースタグ、過去の監査記録も棚卸しします。これらは移行後の動作や復旧可否を左右するため、構築前に一覧表へ記録します。

Mercurialのシステム開発では、いきなり「Gitへ移行する」または「Mercurialを新規構築する」と決めないことが大切です。まず、既存のワークフローがMercurialのphaseやtopic、変更履歴の扱いと結び付いているかを確認します。リリース事故を防ぐために公開済み変更の書き換えを制限している組織なら、Mercurialを継続する合理性がある場合もあります。

一方で、採用したいホスティング、CIプラグイン、人材、社内標準がGit中心なら、Mercurialを残すことによる教育費や運用担当者の属人化が負担になります。判断は、技術者の好みではなく、(1)現行開発の生産性、(2)セキュリティと監査、(3)5年間の運用費、(4)採用・引き継ぎのしやすさ、(5)移行時の事業停止リスクで比較します。保留する場合は、現行Mercurialを安定運用しながら新規開発だけGitへ寄せる段階移行も選択肢です。

Mercurial公式のリリース情報では、2026年6月29日に7.2.3が公開されています。また、2025年には7.0.1がzstdの脆弱性対応として公開されています（出典: Mercurial公式Release、2025〜2026年）。OSSであることはライセンス費を抑える要素ですが、利用バージョン、Python、OS、暗号ライブラリ、配布パッケージの更新経路を保守対象に含める必要があります。

Mercurialのシステム開発の進め方を6フェーズで解説します

進め方の基本は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズです。各段階で成果物と合格条件を置けば、作ってから「レビューができない」「退職者の権限が残る」「復旧できない」と判明する事態を防げます。ここでは、新規導入にも既存Mercurialの刷新・Git移行にも使える手順として説明します。

最初に、誰が、どのリポジトリを、どの頻度で、どの環境へリリースするのかを可視化します。棚卸し表には、リポジトリ名、管理部門、利用者数、容量、最終更新日、重要度、保存年限、依存するサブリポジトリ、接続方式、CIジョブ、外部連携を記録します。現場へのヒアリングでは、通常の開発手順だけでなく、緊急リリース、障害復旧、退職者の引き継ぎ、監査対応の手順も聞き取ります。

要件は「必須」「できれば」「今回は対象外」に分けます。必須要件の例は、社内SSO、二要素認証、最小権限、保護ブランチ相当の制御、日次バックアップ、復旧訓練、CIの結果保存、監査ログの保持です。Mercurialを残すか移行するかの判断もこの段階で仮説を置きますが、結論は次のPoCで検証します。成果物は現状構成図、課題一覧、要件定義書、移行対象一覧、成功指標です。

候補は、OSSを組み合わせた自社運用、Mercurial対応クラウド、企業向けSCM製品、Gitへの段階移行の4方向で比較します。HeptapodはMercurialへHTTPS・SSH・Web UIでアクセスでき、課題管理、マージリクエスト、オンデマンドCI/CD、コンテナレジストリなどを提供しています（出典: Heptapod公式Features、2026年確認）。一方で、すべてのGitLab機能がMercurialで同じように使えるとは限らないため、subrepository、bookmark、LFS相当の大容量ファイル、外部課題管理との連携をPoCで確認します。

RhodeCodeのような製品は、Mercurial、Git、Subversionを横断した権限管理やコードレビューを求める企業に向きます。クラウドを選ぶ場合は、データ所在地、バックアップの保持期間、SLA、障害時の連絡先、退会時のエクスポート、個人情報の取り扱いを契約前に確認します。自社運用を選ぶ場合は、Mercurial担当者だけでなく、OS、ネットワーク、認証、バックアップ、監視を担当する部門の責任者を決めます。

設計では、開発者PCからリモートリポジトリ、レビュー、CI/CD、成果物、本番環境までの経路を図にします。通信はHTTPSまたはSSHに限定し、管理画面とリポジトリのアクセスを分けます。認証はSSOやLDAPと連携し、入社・異動・退職のアカウント連動を自動化できると、退職者の権限残存を減らせます。権限はプロジェクト管理者、開発者、レビュー担当者、閲覧者、CI用サービスアカウントに分け、共有アカウントは原則として使いません。

Mercurial固有の設計では、公開済み変更を表すphase、短期作業のtopicやbookmark、named branchの使い分けを標準化します。変更を誰でも書き換えられる運用にすると、リリース済み履歴や監査記録の信頼性が下がります。サーバー側フックで禁止する操作、レビューを必須にする条件、タグ付与の担当、緊急変更の承認手順を文書化します。

CI/CDは後回しにしないことが重要です。clone、依存パッケージ取得、静的解析、単体テスト、結合テスト、成果物生成、デプロイ承認までを代表リポジトリで自動実行します。既存のCIがMercurialを直接扱えない場合は、ミラーや変換を安易に追加せず、履歴・権限・失敗時の再実行方法を含めて責任分界を設計します。

テストは画面が表示されるかだけで終わらせません。代表リポジトリでclone、pull、push、merge、レビュー、権限エラー、タグ付け、CI実行を確認します。高負荷時のclone時間、同時push時の挙動、差分表示、検索、Web UIの応答、ログの記録も測定します。テスト用データは本番の容量や履歴の特徴に近づけ、空のリポジトリだけで合格にしないことが大切です。

セキュリティテストでは、退職者アカウントの無効化、権限の横断、秘密鍵の失効、監査ログの改ざん防止、バックアップの暗号化、外部公開設定を確認します。復旧テストでは、サーバー障害、リポジトリ破損、誤削除、認証基盤停止を想定し、目標復旧時間と目標復旧時点を測定します。「バックアップがある」ではなく、別環境へ復元して開発者がcloneできることまでが合格条件です。

本番稼働は、全リポジトリを一斉に切り替えるより、重要度の低いパイロットから始めます。パイロットでは、利用者への案内、接続先の変更、認証、レビュー、CI、リリース、問い合わせの一連の流れを実際のチームで確認します。問題がなければ、次に重要度の高いリポジトリへ広げます。移行対象が多い場合は、リポジトリごとに責任者と切替日時を割り当てます。

MercurialからGitへ移行する場合は、ソースだけを移すスナップショット移行、ソースと履歴を移す移行、履歴とメタデータまで移す高忠実度移行を使い分けます。GitHub公式は、Mercurialからソースと履歴を移す経路を案内しており、変換にはMercurial、Git CLI、Pythonを使います（出典: GitHub Docs「Migration paths to GitHub」、2026年確認）。現役の重要リポジトリは履歴を確認し、古いアーカイブはスナップショットにするなど、価値に応じてコストを配分します。

切替計画には、最終バックアップ、書き込み停止、変換または同期、利用者確認、切り戻し期限を明記します。切り戻し先を残す期間、旧環境へのアクセスを誰に許可するか、移行後に旧環境へ新しい変更を入れないルールも必要です。GitHub公式も、リポジトリごとのドライラン、移行前後の利用者通知、CI/CDや連携の再設定を推奨しています。変換だけでなく、運用の切替までを稼働作業として見積もります。

稼働後は、使い方の説明会だけでなく、標準手順を日常業務へ組み込みます。開発者向けにはcloneからレビュー、リリースまでの短い手順書を用意し、管理者向けにはユーザー追加、権限変更、バックアップ確認、障害一次対応の手順書を用意します。新入社員が半日程度で基本操作を再現できるか、担当者が不在でも権限変更と復旧連絡ができるかを確認します。

運用指標は、利用リポジトリ数、CI成功率、レビューの滞留時間、cloneやpushの失敗率、復旧訓練の所要時間、未使用アカウント数、脆弱性対応の完了日数などが適しています。月次でログとバックアップを確認し、四半期ごとに権限棚卸しと復旧訓練を行います。Mercurial公式のリリースを追跡し、2025年のようなセキュリティリリースが出た場合に、誰が影響調査と更新判断をするかも運用規程へ記載します。

Mercurialのシステム開発にかかる費用相場とコストの内訳

Mercurial本体は無料で利用できるため、ライセンス費だけを見ると安く感じます。しかし、実際の費用は現状調査、設計、認証連携、移行、CI/CD、バックアップ、監視、教育、保守の合計です。Mercurial専用の国内受託価格は公開例が限られるため、以下はリサーチノートに記載された国内業務システム案件の目安と、公開SaaS料金を組み合わせた推定レンジです。個別案件の確定額ではありません。

現状調査とPoCだけなら、50万〜200万円程度、期間は2〜8週間が一つの目安です。リポジトリ棚卸し、権限確認、代表リポジトリのclone・push、CI連携、移行可否を検証します。小規模な自社運用で、基本的なHTTPS・SSH、権限、バックアップ、簡易CIまでを構築する場合は、初期費用300万〜800万円程度、期間2〜4か月程度が推定レンジです。

SSO、監査ログ、冗長化、複数環境、チケット連携、既存リポジトリの移行を含む中規模基盤では、800万〜3,000万円程度、期間4〜9か月程度が目安になります。多拠点、数百〜数千利用者、災害対策、高可用性、厳格な監査を含む大規模案件では、3,000万円〜1億円以上、9か月〜2年以上になる可能性があります。これらは国内業務システムの一般的な工数・技術者単価をMercurial基盤へ適用した推定であり、リポジトリ数や連携数によって大きく変動します。

MercurialからGitへの移行は、500万〜2,000万円程度、期間2〜6か月程度が推定レンジです。履歴・タグ・ブランチ・作者情報を変換するだけなら比較的抑えられますが、CI書き換え、レビュー運用、権限再設計、並行稼働、教育、全リポジトリのドライランまで含めると工数が増えます。履歴を残さないアーカイブと、監査や保守で履歴が必要な現役システムを分けると、移行費を合理化できます。

公開料金の例では、RhodeCode CloudのStarterは10席込みで月額80ドル、Teamは月額180ドル、Enterpriseは月額600ドルです（出典: RhodeCode公式Cloud Tiers、2026年確認）。別ページではRhodeCode Enterpriseが1ユーザー年額75ドル、最低10ユーザーと案内されています。料金体系や為替、ストレージ、通信、CIの追加費用は変わり得るため、見積時点の公式料金と契約条件を確認します。

保守費は、一般的な業務システムの目安として初期開発費の年15〜25%程度を置くことがあります（出典: NotebookLM業務システム費用Q&A、2026年）。ただし、Mercurial本体の更新、OSやPythonの更新、脆弱性対応、監視、問い合わせ、リポジトリ復旧訓練、CIランナーの従量課金をどこまで含むかで変わります。月額保守とクラウド利用料を一つにまとめず、内訳を分けて比較します。

Mercurialのシステム開発で見積もりを取る際のポイント

見積もりの差は、Mercurialのライセンス費よりも、対象範囲と責任分界の差から生まれます。「サーバーを立てる」「Gitへ移行する」といった大きな作業名だけで依頼すると、認証、CI、バックアップ、教育、切り戻しが別料金になり、後から予算が膨らみます。RFPや依頼書では、リポジトリ、利用者、連携、移行、運用を分けて記載します。

最低限、リポジトリ数、総容量、最大リポジトリ容量、履歴の保存年限、利用者数、同時利用のピーク、開発拠点、認証方式、権限グループ、CIジョブ数、外部連携数、バックアップ世代数、目標復旧時間を渡します。Git移行なら、bookmark、named branch、phase、tag、subrepo、作者名の対応表も準備します。

GitHubの移行計画でも、移行元のリポジトリ名、所有者、URL、最終更新日時、プルリクエストや課題の数を一覧化することが推奨されています。さらに、公式ガイドは全リポジトリでドライランを行い、移行できるデータと移行できないデータ、所要時間を確かめる流れを示しています（出典: GitHub Docs「Planning your migration to GitHub」、2026年確認）。この考え方はMercurialを残す刷新案件にも適用できます。

開発会社やベンダーは、単に「Mercurial対応」と書いてあるかだけで判断しません。Mercurialを継続運用する案件、Heptapodなどでホスティングする案件、Gitへ移行する案件では必要な経験が異なります。提案依頼では、公開可能な実績、対応するMercurialのバージョン、履歴やメタデータの移行方法、CI/CDの実装範囲、SSO・監査・バックアップの担当範囲を質問します。

見積書は、調査・要件整理、PoC、設計、構築、移行、テスト、教育、稼働支援、保守に分かれているものを選びます。固定額と準委任の使い分け、追加変更の単価、納品物、ソースコードとIaCの引き渡し、契約終了時のデータ返却、障害時のSLAも確認します。海外サービスや海外企業を利用する場合は、日本語窓口、時差、データ所在地、準拠法、請求通貨も比較項目に加えます。

Mercurial案件の典型的なリスクは、Git中心の周辺ツールとの互換性不足、サブリポジトリの移行漏れ、履歴変換による作者やタグの欠落、CI書き換えの遅延、バックアップの復元不能、担当者の退職です。リスクごとに、発生条件、影響、回避策、発生時の責任者を決めます。たとえば「レビューがWeb UIで完結する」「重要リポジトリを指定時間内に復元できる」「退職者のアカウントが無効化される」を受け入れ条件にします。

特に「移行完了」の定義は細かく分けます。履歴が見えること、タグが一致すること、ブランチまたはbookmarkの対応が確認できること、ビルドが再現できること、レビューと課題の責任者が追跡できること、利用者が新しい接続先へ切り替えられることは別々の確認項目です。納品時に未解決の制約一覧を受け取り、将来のアップデートや追加連携の前提を残します。

Mercurialのシステム開発でよくある質問

ここでは、Mercurialの継続利用や移行を検討する担当者から寄せられやすい疑問に回答します。費用、クラウド、Git移行、国内企業への依頼という4つの観点で、判断の前提を整理します。

Mercurial本体や一部の関連ソフトウェアは無料で利用できますが、業務基盤としての構築・運用を無料で完結できるとは限りません。認証、権限、バックアップ、監視、CI/CD、脆弱性対応、教育、障害復旧に人件費がかかります。ライセンス費を抑えたい場合も、5年間の運用工数と保守体制を含む総保有コストで判断します。

運用できます。HeptapodはMercurialのHTTPS・SSH・Web UIに対応し、CI/CDや課題管理も提供しています。RhodeCode CloudのようにMercurialとGitを一つの管理基盤で扱えるサービスもあります。ただし、SSOの方式、データ所在地、バックアップ、CIの従量課金、SLA、契約終了時のエクスポートを確認し、自社の機密性・規制・可用性要件に合うかをPoCで確かめます。

適切な変換手順と検証を行えば、履歴を残して移行できる場合があります。ただし、Mercurial固有のphase、bookmark、named branch、subrepository、フック、レビューや課題の履歴がそのまま対応するとは限りません。重要リポジトリはドライランでコミット数、作者、日時、タグ、ブランチ、差分、ビルド結果を比較し、移行後の旧環境を一定期間読み取り専用で保持します。

依頼できますが、国内でMercurialを専門に掲げる受託会社の公開情報は限られます。そのため、一般的なシステム開発会社へ相談する場合も、Mercurialの実案件、履歴移行、認証・権限、CI/CD、バックアップ復旧の経験を個別に確認します。必要に応じて、MercurialコアやHeptapodに詳しい海外企業と、国内の要件整理・運用支援会社を組み合わせる方法もあります。日本語窓口と時差、責任分界を契約書に明記します。

まとめ：6フェーズとPoCでMercurialの判断を安全に進めます

最初の一歩は、全リポジトリの一覧、利用者と権限、容量、CI、外部連携、バックアップ状況を一枚にまとめることです。そのうえで現役の代表リポジトリを選び、Mercurial継続、対応クラウド、自社運用、Git移行の各案を比較します。小さな検証で履歴、レビュー、CI、復旧の可否を確かめると、本番切替後の予想外の追加費用を抑えられます。

提案を比較するときは、初期費用だけでなく、脆弱性対応、OSやPythonの更新、権限棚卸し、復旧訓練、利用者教育、問い合わせ対応の費用を確認します。稼働後に誰が何をするかが明確なら、Mercurialを残す場合もGitへ移行する場合も、開発基盤を安定して運用できます。

Mercurialのシステム開発は、要件整理、選定、設計開発、テスト、稼働、定着の6フェーズで進めます。最初にリポジトリ、権限、CI/CD、バックアップ、監査、連携を棚卸しし、Mercurialを残すのかGitへ移行するのかを、業務・技術・運用費の3方向から比較します。PoCでは、代表リポジトリの履歴、レビュー、CI、性能、復旧を実際に確認します。

費用は、PoCで50万〜200万円程度、小規模な自社運用で300万〜800万円程度、中規模基盤で800万〜3,000万円程度、Git移行で500万〜2,000万円程度が推定レンジです。Mercurial専用の公開相場ではないため、リポジトリ数、容量、利用者、認証、CI、可用性、移行範囲を示して個別見積もりを取得します。金額だけでなく、納品物、保守、復旧訓練、契約終了時のデータ返却まで比較することが、長く使える開発基盤につながります。

▼全体ガイドの記事
・Mercurialのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。