開発・エージェント

バージョン管理とは

この記事の結論

バージョン管理とは、ファイルの変更を「版」として記録し、あとから比べたり、前の版に戻したりできるようにする考え方と仕組みです。
道具の種類は大きく3つに分かれます。手元のパソコンだけで記録するローカル型、1台のサーバーに集めて管理する集中型、全員が履歴の完全な写しを持つ分散型です。
分散型の代表であるGitは、2005年にLinuxカーネルの開発のために作られました。AIにコードを書かせる場面では、何が変わったかを確かめる手段になります。

ばーじょんかんり／Version Control

ファイルの変更を版として記録し、あとから比べたり戻したりできるようにする考え方と仕組みです。

最終更新: 2026-09-26

バージョン管理とは何か（意味と読み方）

バージョン管理とは、ファイルに加えた変更を「版（バージョン）」として順番に記録し、いつでも見比べたり、前の版に戻したりできるようにする考え方と、それを支える仕組みのことです。読み方は「ばーじょんかんり」、英語では version control、または source control とも呼ばれます。

身近な例が、企画書_最終.docx、企画書_最終_修正版.docx のようにファイル名で版を分ける方法です。これも素朴なバージョン管理ですが、どれが最新か、どこを変えたのかが分からなくなりがちです。専用の道具は、この「版の記録」を名前の工夫ではなく仕組みで引き受けます。

記録の置き場所であるリポジトリの中身については別のページで扱います。ここでは、なぜ記録を残すのか、どんな方式があるのかを見ていきます。

バージョン管理の仕組み：何を記録しているのか

どの道具でも、1つの版にはおおむね次の情報が結びつきます。

その時点のファイルの内容、または前の版からの変化
変更した人と日時
なぜ変えたのかを書いた説明文

版の持ち方は道具によって違います。Pro Git の「Gitの基本」によると、SubversionやCVSなどの多くの道具は元のファイルと、そこからの差分を積み重ねて保存します。これに対してGitは、記録のたびにプロジェクト全体の状態をスナップショットとして残します。変わっていないファイルは、前と同じものへのつながりだけを持たせて容量を抑えています。

同じ資料には、Gitが保存するものすべてにチェックサム（内容から計算した識別用の値）を付けていることも書かれています。途中でデータが壊れたり書き換わったりすれば、値が合わなくなるので気づけます。

記録を残す操作がコミット、流れを分けて並行に作業する仕組みがブランチです。

バージョン管理システムの種類と歴史

Pro Git の「バージョン管理に関して」は、道具の移り変わりを3つの段階で説明しています。

ローカル型：自分のパソコンの中の簡単なデータベースに変更を記録する方式です。代表例はRCSです。共同作業には向かず、そのディスクが壊れれば履歴ごと失います。
集中型：1台のサーバーに全ファイルと履歴を置き、各自がそこから取り出して作業する方式です。CVS、Subversion、Perforceが挙げられています。管理はしやすい反面、サーバーが止まれば全員が記録を残せなくなります。Subversionは公式サイトでも、自らを集中型のバージョン管理システムと紹介しています。
分散型：各自が最新のファイルだけでなく、リポジトリ全体を写し取って持つ方式です。Git、Mercurial、Bazaar、Darcsが例に挙がっています。どの写しも全データのバックアップになり、サーバーが失われても手元から復元できます。

Gitの成り立ちはPro Git の「Git略史」にまとまっています。Linuxカーネルの開発ではBitKeeperという分散型の商用ツールを使っていましたが、2005年にその無償利用ができなくなりました。そこでLinus Torvaldsらが、スピード、単純な設計、数千の並行ブランチへの対応、完全な分散などを目標に、自前の道具としてGitを作りました。

AI開発でバージョン管理が効く場面

AIコーディングエージェントは、1回の依頼で複数のファイルをまとめて書き換えることがあります。バージョン管理をしていれば、そのあとに git diff を打つだけで、どのファイルのどの行が変わったかを一覧で確かめられます。

依頼の前に版を切る：AIに任せる直前の状態を1つ記録しておくと、結果が気に入らないときにそこへ戻ってやり直せます。
いつから壊れたかを追う：git log で記録を新しい順にたどり、動いていた版と壊れた版を見比べると、原因の範囲を絞れます。
コード以外も記録する：システムプロンプトや評価用の質問集もテキストファイルにして同じ履歴に入れると、「どの指示文のときに結果が変わったか」を後から比べられます。

AIと進めるときの記録の区切り方と差分の見方は、AI時代のGit運用｜コミット分割と差分レビューの実践手順で手順として解説しています。

バージョン管理についてのよくある誤解

誤解：クラウドストレージの版履歴があれば同じこと → 実際：ファイル単位で古い版を取り出すことはできますが、複数ファイルをまとめた「この時点のプロジェクト全体」を説明文つきで残したり、並行する作業を合流させたりする用途には向いていません。
誤解：バージョン管理＝Git → 実際：Gitは分散型の道具の1つです。Mercurialのような別の分散型もあれば、Subversionのような集中型も公式サイトで開発と配布が続いています。
誤解：1人で作るなら要らない → 実際：数日前の自分は他人と同じです。何を変えたか思い出せないとき、履歴が唯一の手がかりになります。
誤解：入れておけば何でも戻せる → 実際：戻せるのは記録した版だけです。記録する前に上書きした変更や、そもそも追跡していないファイルは戻せません。

バージョン管理を始めるときのコツ

最初の1行を書く前に始める：途中から始めると、それ以前の経緯は残りません。フォルダを作ったらすぐ記録を始めます。
1つの版に1つの目的：あとで「この変更だけ取り消したい」となったとき、目的ごとに分かれていれば迷いません。
説明文に「なぜ」を書く：何を変えたかは差分を見れば分かりますが、なぜ変えたかは書かないと残りません。
手元だけで終わらせない：分散型でも、手元のディスク1台にしかなければローカル型と同じ危うさがあります。別の場所にも写しを置きます。

出典・参考資料

よくある質問

Q1. バージョン管理とは何ですか？
ファイルに加えた変更を版として順番に記録し、あとから見比べたり前の版に戻したりできるようにする考え方と仕組みです。版ごとに、変更の中身、変更した人と日時、変えた理由の説明がまとめて残ります。

Q2. 集中型と分散型のバージョン管理は何が違いますか？
集中型は1台のサーバーに履歴を集め、各自はそこから取り出して作業します。分散型は各自がリポジトリ全体の写しを持つので、サーバーが止まっても手元で記録を続けられ、どの写しもバックアップになります。Subversionは集中型、Gitは分散型です。

Q3. Gitはいつ、なぜ作られたのですか？
2005年に、Linuxカーネルの開発で使っていた商用の分散型ツールが無償で使えなくなったことをきっかけに、Linus Torvaldsらが作りました。速さ、単純な設計、多数のブランチを並行して扱えること、完全な分散が目標に掲げられていました。

Q4. バージョン管理とバックアップは同じものですか？
重なる部分はありますが、目的が違います。バックアップはある時点の丸ごとの複製を残すもので、バージョン管理は変更の一つ一つを理由つきで積み重ねるものです。どこをなぜ変えたかを追えるのはバージョン管理の側です。

Q5. AIにコードを書かせるとき、バージョン管理は必要ですか？
強くおすすめします。AIは一度に多くのファイルを書き換えることがあるため、依頼の前に版を記録しておけば、変わった箇所を差分で確かめたり、結果が合わないときに元の状態へ戻したりできます。