LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Visual SourceSafeとは？既にサポートが終了した旧世代のバージョン管理システム

Visual SourceSafe(VSS)とは、Microsoftが開発したファイルベースのバージョン管理システムです。ソースコードやドキュメントをチェックイン・チェックアウトという単位で管理する仕組みで、Windows環境の小規模な開発チーム向けに広く使われてきました。

最終バージョンであるVisual SourceSafe 2005について、Microsoft Lifecycleの公式情報ではメインストリームサポートの終了日が2012年7月10日、延長サポートの終了日が2017年7月11日とそれぞれ記載されています^*1。つまり現時点(2026年)では、セキュリティ更新も技術サポートも提供されない状態がすでに9年近く続いていることになるでしょう。

サポート終了後のツールを本番の開発基盤として使い続けることは、脆弱性への対応やOS更新への追随ができないという運用リスクを抱えたままの状態を意味します。現行のバージョン管理システムとしてVSSを新規に採用する企業はほとんど見られず、既存資産をどう移行するかが実務上の課題になっています。

VSSに残る4つの技術的限界：排他ロック・ファイル破損・分散非対応・CI/CD非連携

VSSを使い続ける場合、技術的な限界が主に4つ挙げられます。

1つ目は排他ロックです。公式のMicrosoftブログでは「VSSでファイルをチェックアウトすると、既定では他の利用者が同じファイルをチェックインするまでチェックアウトできない」と説明されており、この仕組みは「排他チェックアウトモード」と呼ばれています^*2。複数人が同じファイルを並行して編集し、後からマージするという現代の開発スタイルとは前提が異なります。

2つ目はファイル破損のリスクです。公式ドキュメントは、VSSのデータベースを検査・修復するANALYZEユーティリティについて「少なくとも月1回、可能であれば週1回の実行を推奨する」と明記しています^*3。裏を返せば、定期的な検査を怠るとデータベース破損に気づけないまま運用を続けてしまうツールだということです。

3つ目は分散開発への非対応です。VSSはネットワーク共有フォルダを介してデータベースへ直接アクセスする構成が前提であり、リモート拠点や社外から接続する場合には別途VPN等の仕組みを用意する必要があります。

4つ目はCI/CDパイプラインとの接続です。GitHub ActionsやAzure Pipelinesといった現代のCI/CDサービスは、Gitへのpush・pullをトリガーに自動でビルドやテストを実行する仕組みを前提に設計されています。VSSにはこうした標準的な連携経路が用意されておらず、開発フローの自動化を組み込みにくい点も実務上の制約になるでしょう。

Gitへの移行方式は2つ：履歴移行と最新のみ移行の比較

VSSからGitへ移行する方法は、大きく2つの方式に整理できます。

1つ目は、過去の変更履歴を含めて移行する方式です。VSSのデータベースを解析し、チェックイン単位の変更をGitのコミットへ変換するツールを使います。代表例がオープンソースのVss2Gitで、VSS 6.0のデータベース内容を読み込み、削除やリネームがあったファイルも含めて履歴を再現できるとされています^*4。過去の変更経緯を追跡できる利点がある一方、変換処理そのものに一定の検証工数がかかります。

2つ目は、履歴を持ち越さず最新のソースコードだけを新しいGitリポジトリへ取り込む方式です。現状のファイル一式を初回コミットとして登録し、そこから先の変更のみをGitで管理していく進め方になります。過去の経緯を参照する頻度が低いプロジェクトであれば、作業も検証も短期間で完了しやすい方式と言えます。

どちらを選ぶかは、後述する判断軸の中でも特に「履歴保全の要否」に左右されることになります。

履歴移行の具体的な実務：変換ツールの特徴と制限

履歴移行を選ぶ場合は、変換ツールの仕様と制限を事前に把握しておく必要があります。Vss2GitはApache License 2.0で公開されているWindows向けのGUIアプリケーションで、VSS 6.0のリポジトリをGitへエクスポートする機能を持ちます^*4。

一方で公式のドキュメントには、一度移行した後の差分だけを追加で取り込む増分移行には対応していないこと、データベースにCRCエラーがある場合の処理は保証されないこと、正式なコマンドラインインターフェースは提供されていないことが明記されています^*4。実行にはGitの実行ファイルへパスが通っている必要がある点も、あわせて確認しておきたい仕様です^*4。

つまり変換作業は、基本的に一度きりで完結させる前提の設計です。移行作業中もVSS側でチェックインが続くと、変換結果と実体がずれてしまう恐れがあります。移行当日はVSSへの新規チェックインを止め、対象範囲を固定したうえで変換を実行する運用が現実的でしょう。

GitHub・GitLab・Azure Reposへの移行手順と接続時の注意点

変換で得たGitリポジトリを実際のホスティングサービスへ取り込む際は、サービスごとに手順と制約が異なります。

GitHubへの取込

GitHubは、外部リポジトリを取り込む方法として、対象リポジトリを–bareオプション付きでクローンし、GitHub上に作成した空リポジトリへプッシュするコマンドライン手順を公式に案内しています^*5。

Azure Reposへの取込

Azure Reposも同様に、bareクローンとgit push –mirrorによる取込に対応しています^*6。ただし公式ドキュメントには複数の注意点が明記されています。まず、Git LFSで管理しているファイルはインポート機能の対象外であり、別途git lfs fetchとgit lfs pushを使って個別に移行する必要があります^*6。次に、二要素認証がかかったリポジトリやMSAベースの資格情報はインポートサービスの認証方式と適合せず、個人アクセストークン等の基本認証相当の手段へ切り替える必要があります^*6。なお、VSSはTFVCとは別の製品であるため、Azure ReposがTFVC向けに備える移行機能はそのままでは使えず、いったんGit形式へ変換したうえで通常のGitインポート経路を使う点も押さえておくべきポイントです^*6。

GitLabへの取込

GitLabは「Repository by URL」という機能でリポジトリURLを指定した取込に対応しており、GitLab.comでは既定で有効になっています^*8。ただし大規模なリポジトリでは取込処理が3時間でタイムアウトする場合があるとされており^*8、履歴を多く含む移行では事前にリポジトリサイズを確認しておく必要があるでしょう。

移行前に整理すべき4つの判断軸

変換ツールと移行先が決まっても、着手前に整理しておくべき判断軸が4つあります。

1つ目は履歴保全の要否です。過去の変更経緯を監査や障害調査で参照する頻度が高いプロジェクトほど、変換にかかる工数を投じてでも履歴移行を選ぶ価値があります。参照頻度が低いなら、最新のみ移行で工数を抑える判断も合理的でしょう。

2つ目はリポジトリ分割です。VSSは1つのデータベースの中に複数プロジェクトを共有ファイルとしてまとめて管理できる構造を持っています。Gitへ移行する際に、この構造をそのまま単一リポジトリとして持ち込むか、プロジェクトごとに分割するかによって、その後のアクセス権限管理や依存関係の見通しやすさが変わってきます。

3つ目はブランチ戦略です。VSSでの並行作業は限定的だったため、Git移行を機にmainブランチと開発ブランチを分ける運用や、プルリクエストによるレビュー体制を新たに設計し直す企業が多く見られます。

4つ目は権限設計とLFSです。Gitのホスティングサービスでは、リポジトリやブランチ単位でアクセス権限を細かく設定できます。またVSSで管理していた大容量のバイナリファイルは、そのままGitへ入れるとリポジトリを肥大化させるため、Git LFSへの切り替えを検討します。Git LFSは実ファイルをリポジトリの外部に保存し、リポジトリ内には参照用のポインタファイルだけを置く仕組みで^*7、GitHubの場合はプランに応じて1ファイルあたり2GBから5GBまでの上限が設けられています^*7。

内製移行と外注委託のコスト構造比較

VSSからGitへの移行を内製で進める場合と、外部パートナーへ委託する場合では、費用構造・必要スキル・リスク対応の重心が異なります。以下の表に主な違いを整理しました。

移行を成功させる検証と並行運用のポイント

移行作業そのものより、移行後に問題へ気づける体制のほうが重要です。

移行直後は、VSS側とGit側を一定期間並行運用し、変換されたファイルの内容やタイムスタンプに差異がないかを実際の開発者にレビューしてもらう工程を挟んでおくと、後戻りのリスクを抑えられます。

並行運用の期間中にVSSへの新規チェックインを完全に止めておかないと、移行後のGitリポジトリと実体がずれてしまいます。移行基準日以降はGitのみへチェックインするというルールを、全メンバーへ周知しておく必要があります。

並行運用で問題がないことを確認できたら、VSSサーバーの停止・廃止に進みます。サポートが終了した製品を稼働させ続けること自体がリスクであるため、移行が完了した後は速やかに廃止する判断が望ましいと言えるでしょう^*1。

まとめ：VSSからGit移行を進める3つの判断軸

本稿ではVisual SourceSafeの現状とGitへの移行方式を、公式情報に基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、Visual SourceSafe 2005はメインストリーム・延長ともにサポートが終了しており、排他ロックやファイル破損のリスクを抱えたまま運用を続けること自体がリスクです^*1*2*3。第二に、Gitへの移行方式には履歴を変換ツールで引き継ぐ方式と最新のみ移行する方式があり、履歴保全の必要性に応じて選ぶ判断が求められます^*4。第三に、移行先ごとの取込手順や制限を踏まえたうえで、内製と外注のどちらで検証・並行運用を進めるかを、自社の体制と照らして判断する必要があります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Microsoft Learn「Microsoft Visual SourceSafe 2005 – Microsoft Lifecycle」（https://learn.microsoft.com/en-us/lifecycle/products/microsoft-visual-sourcesafe-2005）
2. *2　出典：Microsoft Learn（アーカイブブログ）「Team Foundation vs. SourceSafe | Locking vs Exclusive Checkouts」（https://learn.microsoft.com/en-us/archive/blogs/korbyp/team-foundation-vs-sourcesafe-locking-vs-exclusive-checkouts）
3. *3　出典：Microsoft Learn（旧バージョンドキュメント）「How to: Find and Repair Data Corruption」（https://learn.microsoft.com/en-us/previous-versions/0z4xw998(v=vs.80)）
4. *4　出典：Vss2Git公式GitHubリポジトリ「README」（https://github.com/trevorr/vss2git）
5. *5　出典：GitHub Docs「Importing an external Git repository using the command line」（https://docs.github.com/en/migrations/importing-source-code/using-the-command-line-to-import-source-code/importing-an-external-git-repository-using-the-command-line）
6. *6　出典：Microsoft Learn「Import a Git repository into a project – Azure Repos」（https://learn.microsoft.com/en-us/azure/devops/repos/git/import-git-repository?view=azure-devops）
7. *7　出典：GitHub Docs「About Git Large File Storage」（https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage）
8. *8　出典：GitLab Docs「Migrate through a Git URL」（https://docs.gitlab.com/user/import/third_party_systems/repo_by_url/）

Tweet