本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第3弾として、構成管理（バージョン管理）について解説する記事です。
構成管理は土地の登記簿です。Gitがデファクトの現在、リポジトリ構造・ブランチ戦略・タグ運用は全ての開発プロセスの前提で、ここを雑にすると他の設計が全て空転します。本記事ではTrunk-Based / GitHub Flow / Git Flowの使い分け、モノレポvsマルチリポ、SemVer・タグ運用、SVN→Git移行まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『いちばんやさしいClaude Codeの教科書』・『Claude CodeによるAI駆動開発入門』も参考にしてみてください。
この記事の結論
- モノレポをデフォルトにする
- ブランチ戦略はGitHub FlowかTrunk-Basedを選ぶ
- Squash merge+Conventional Commitsで履歴を構造化し、Secret Scanningで漏洩をブロックする
この記事を読む前に
本記事は開発・テスト・リリース・監視といった、サービスを作って動かし続ける工程の話が中心です。IT用語にあまり馴染みがない方は、基礎編の「開発から運用までの流れ」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも構成管理（バージョン管理）とは何か
Word文書の「変更履歴」を思い浮かべてください。いつ・誰が・どこを変えたかが記録され、いつでも前の状態に戻せます。この機能がなければ、「最終版_v3_修正済み_本当の最終.docx」というファイル名地獄になるのは誰もが経験済みでしょう。
構成管理（バージョン管理）とは、ソースコードの変更履歴を記録し、いつでも過去の状態に戻せるようにする仕組みです。現代ではGitがデファクト標準で、リポジトリ構造・ブランチ戦略・タグ運用まで含めた「コードの土地台帳」です。
もし構成管理がなければ、誰かの変更が別の人の変更を上書きし、障害時に「いつからおかしくなったか」を追跡できず、チーム開発が成立しません。
Gitが標準になった経緯と、なぜGitが勝ったか
2005年、Linus TorvaldsがLinuxカーネル開発のために2週間で作ったのがGitです。それまでの商用VCS（BitKeeper）のライセンスがカーネルコミュニティと揉めたのが直接のきっかけで、「中央サーバーなしで分散的に動き、高速で、ブランチが軽い」という、今では当たり前の特性を持って登場しました。第1世代（RCS・CVS）のファイル単位管理、第2世代（Subversion・Perforce）の中央集権型を経て、分散・高速・軽量ブランチの第3世代がGitです。
技術的な強みに加えて、普及を決定づけたのはGitHubによるソーシャル化（2008年〜）でした。PR・Issue・Starといった仕組みでコードレビューとOSS貢献の体験が根本から変わり、開発者が「GitHubに置くためにGitを使う」状態に一気に傾きました。さらにAI駆動開発の時代では、AIがGit操作を流暢に書けることが選定の大きな理由になっています。PerforceやClearCaseは学習データが薄く、AIエージェントがコミットや競合解決を正しく扱えません。商用VCSは今も一部の大企業やゲーム業界に残りますが、新規選定はGit一択が現実です。
構成管理で決めるべき5つの軸
構成管理の設計は「Gitを使う」で終わりではなく、①リポジトリ構造（モノレポ / マルチリポ）、②ブランチ戦略（Trunk-Based / GitHub Flow / Git Flow）、③マージ方法（Squash / Rebase / Merge commit）、④タグ・リリース運用（SemVer / CalVer）、⑤大容量ファイルの扱い（LFS / 外部参照）──の5軸を組み合わせて決めます。この組み合わせがCI/CD・テスト戦略・レビュー運用の前提を決め、どれも後から変えるコストが高いため、プロジェクト開始時に決め切るのが鉄則です。
モノレポ vs マルチリポ
リポジトリ構造の最大の論点がモノレポ（全部1つのリポジトリ）かマルチリポ（サービスごとに別リポ）かです。「モノレポは大企業の道具」という印象は古く、現時点では中小チームでもモノレポが有力になっています。
| 軸 | モノレポ | マルチリポ |
|---|---|---|
| バージョン管理 | 全コード共通のバージョン | サービスごとに独立 |
| クロスカット変更 | 1PR で完結 | 複数 PR で調整が必要 |
| CI | 変更範囲テストが必須（遅い） | リポジトリ単位で高速 |
| 権限管理 | CODEOWNERS で制御 | リポジトリ単位で制御 |
| 代表ツール | Nx・Turborepo・pnpm workspace | （特別なツール不要） |
Google・Meta・Uber・Airbnbはモノレポ、Amazonはマルチリポ寄り（「2枚のピザチームが1サービス1リポジトリ」思想）。どちらが正解かではなく、組織のコミュニケーション構造（Conwayの法則）と合致するかで決まります。
モノレポが有利になる条件は「コードが互いに依存している」「一括で変更する必要が頻繁にある」の2つです。フロント+バックエンド+共通型定義の構成なら型の一元管理でTypeScriptの威力が最大化し、ライブラリと利用アプリの同時開発もローカル参照で即座に検証できます。逆に、10以上のマイクロサービスを独立チームが持つ場合や、買収などで独立した組織が集まった場合はマルチリポの方が運用が軽い。筆者の感覚では8割のチームにはモノレポが刺さり、マルチリポは「組織が本当に独立している」ことの立証責任がかかる側です。迷ったらモノレポから始めて、規模に応じて分解する順が安全です。
ブランチ戦略 — どれだけ短命かが核心
ブランチ戦略は、構成管理の観点ではブランチがどれだけ短命かが核心です。長命になるほどマージ競合が重くなり、レビューも遅くなります。
主役は2つ。GitHub Flow（featureブランチ+PR+main）はWebサービス・モダン開発の鉄板で、Trunk-Based Development（数時間〜1日で mainへ）は高度なCI/CDを持つ熟練チーム向けのさらに攻めた型です。Git Flow（main+develop+release+hotfix）はパッケージ製品やバージョン並行管理が必要なケース専用で、継続デプロイ型のサービスには複雑すぎます。そういうビジネスモデル自体が減っているため、新規プロジェクトではGitHub FlowかTrunk-Basedの二択と考えて問題ありません。
マージ方法 — Squash／Rebase／Merge
PRをマージする方法には3種類あり、どれを採用するかでコミット履歴の読みやすさが大きく変わります。どれが優れているというより、チームで統一することが肝心です。
| 方式 | 結果 | メリット | デメリット |
|---|---|---|---|
| Squash merge | PR 全体を1コミットに圧縮 | main 履歴が簡潔・PR 単位で revert 可能 | PR 内の細かい履歴が失われる |
| Rebase merge | PR のコミットを順に main に積む | リニア履歴で追いやすい | コミット規約の徹底が前提 |
| Merge commit | PR 分岐と merge commit が残る | 「この PR をマージした」履歴が残る | main が複雑な履歴になる |
現時点の主流はSquash mergeです。特に中小チームではPR単位の粒度で履歴を追う方が実務的で、リリースノート自動生成とも相性が良い。3方式を混在させるのは最悪で、Squashに統一が一番揉めません。
タグ・リリース運用と大容量ファイル
「いつのコードが本番に出ているか」を即座に特定できないチームは、障害対応で必ず詰まります。タグの命名は、ライブラリ・パッケージ製品ならSemVer（v2.3.1、互換性の破壊をMajorで示す）、頻繁にリリースするSaaSならCalVer（2026.04.01、いつの時点のコードか一目で分かる）が定番です。GitHub Releasesでタグと変更ログをセットで残し、Conventional Commits + 自動リリースノート生成（release-please・semantic-release）を組み合わせるのが現時点の鉄板です。
もう一つの注意点が大容量ファイルです。Gitは大容量バイナリが苦手で、動画・機械学習モデル・ゲームアセットを普通にコミットするとリポジトリが肥大化し、cloneに数時間かかる事態になります。主役はGit LFS（ポインタだけGit管理、GitHub等が標準対応）で、MLデータセットなど数百GB規模はDVCやS3参照が向きます。最初からLFS or 外部参照で設計するのが鉄則です。
なお現場にSVNが残っている場合、続ける選択肢はほぼありません。ブランチが重く、AIツール（Copilot・Cursor等）がGit前提で、採用面でも不利です。git-svnで履歴を保持して移行できますが、「SVNとGit両方を維持する期間」が地獄になるため、移行を決めたら短期決戦で一気にやり切るのが鉄則です。
.gitignoreと秘密情報の扱い
構成管理で事故の発生源No.1が、秘密情報（APIキー・パスワード・トークン）の誤コミットです。一度コミットするとGitの履歴に残り続け、Force pushで消しても履歴キャッシュに残るため、実質的に漏洩扱いになります。
対策は4段構えです。.env・*.pem・secrets/ を必ず .gitignore に入れ、pre-commitフック（gitleaks・detect-secrets）でコミット前に物理ブロックし、GitHub標準のSecret Scanningでpush時に検出し、それでも漏れたら即時ローテーションする。2022年にはToyotaの子会社がアクセスキーをGitHubに誤公開し、約30万件の顧客情報が5年間アクセス可能な状態になっていた事例があります。詳細は秘密情報管理の記事で扱いますが、「気をつける」は機能しない運用であり、コミット前の物理ブロックが必須です。
3つのシナリオで考える
個人開発・スタートアップの場合
GitHubにモノレポ、GitHub Flow、Squash mergeという組み合わせが最短の鉄板だと思います。フロント・バックエンド・共通型を1つのリポジトリに置いて、pnpm workspaceで管理してしまいましょう。Secret Scanningは標準で有効になっていますので、あとはpre-commitにgitleaksを入れて漏洩をブロックしておけば安心です。タグはCalVerか、GitHub Releasesの自動生成で十分だと思います。
中小SaaS企業の場合
モノレポにTrunk-Based（またはGitHub Flow）、Conventional Commitsとsemantic-releaseを組み合わせる段階です。branch protectionでmainへの直pushをゼロにして、CODEOWNERSでレビューの必須範囲を制御していきます。モノレポのCIはNxやTurborepoの変更範囲テストを使って、PR時10分以内を守りたいところです。
大企業の場合
組織が本当に独立しているならマルチリポ（1チーム1サービス1リポ）、共通基盤や型を共有するならモノレポと、Conwayの法則に合わせて選ぶのが正解だと考えています。SVNのようなレガシーVCSが残っている場合は移行計画を最優先で立てて、履歴改変禁止や署名コミットといった監査要件はbranch protectionで強制する形にします。
構成管理の数値Gate・運用指標
※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。
構成管理の健全性は数値で追うのが実務です。下記が業界定番の指標です。
| 指標 | 推奨値 | 超えたらどうするか |
|---|---|---|
| Featureブランチ寿命 | 2〜3日 | 1週間超で強制マージ検討、長命は競合地獄 |
| 1 PRの変更行数 | 〜400行 | 1000行超は分割。レビューが形骸化 |
| mainへの直push | 0件 | 全てPR経由、branch protectionで強制 |
| リポジトリclone時間 | 〜30秒 | 超過したら LFS／shallow clone 検討 |
| Secret Scanningアラート対応 | 5分以内 | 漏洩キーは即時ローテーション |
| モノレポCI実行時間 | PR時10分以内 | 変更範囲テスト（Nx／Turbo）で短縮 |
AI判断軸 ― AIが読みやすい履歴を作る
モノレポがAIのコンテキスト把握を助ける構造的理由
モノレポでは全サービスの型定義・API仕様・テストが1つのリポジトリに集約されています。AIにコード修正を依頼する場合、関連するファイルがすべて同じリポジトリ内にあるためコンテキストとして渡しやすく、AI側も依存関係を正確に把握できます。マルチリポ構成ではサービスAの修正がサービスBのAPI仕様変更を伴う場合、2つのリポジトリを跨いでコンテキストを組み立てる必要があり、AIの精度が落ちます。
Conventional CommitsがAIによる変更履歴の解析を可能にする
feat: fix: chore: のプレフィックスでコミットメッセージを構造化していると、AIはGit履歴から「このリリースに含まれる機能追加・バグ修正・破壊的変更」を自動的にリストアップできます。CHANGELOG自動生成やリリースノート作成もAIが正確にこなせるようになります。自由形式のコミットメッセージ（「修正」「対応」など）では、AIはコミットの意図を推測するしかなく、精度が大幅に下がります。
やってはいけないこと
構成管理で事故る典型を、特に危険な6つに絞ります。どれも「コードの歴史を壊す」「組織の信用を失う」結末を招きます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
.envや秘密鍵をGitにコミット | 履歴キャッシュに残り実質回収不能（Toyota子会社30万件事件） → pre-commitで物理ブロックする |
| main / developへForce push | 他メンバーの作業消失・履歴改変で監査NG → branch protectionで禁止する（featureブランチのrebaseは許容） |
| ブランチを1週間以上残してマージ | 競合が雪だるま式に膨張 → 2〜3日で必ずmainへ戻す |
| バイナリファイルを普通にコミット | リポジトリが数十GBに肥大しcloneに数時間 → 最初からLFS / 外部参照で設計する |
| マージ方法の混在運用 | 履歴が複雑化しPR単位のrevertが不能に → Squashに統一する |
| コミットメッセージ規約なし | 履歴検索・リリースノート自動化が不能 → Conventional Commitsを導入する |
なお「Gitを使っていれば構成管理OK」という安心も禁物です。リポジトリ構造・ブランチ戦略・マージ方針が未設計のままでは、登記簿はあっても地図がない状態です。
筆者メモ — GitLab 2017年1月 DB削除事件
構成管理を語るなら、GitLabの2017年1月31日の本番DB削除事件は外せません。オンコール担当のエンジニアが深夜の障害対応中に、誤って本番のPostgreSQLデータベースのディレクトリを削除してしまいました。本来は待機系で実行するはずのコマンドでした。
事件の深刻度を増したのは、バックアップが5種類あったのに、そのうち4種類が機能していなかったことです。最終的に6時間前のスナップショットから復旧しましたが、その間の約300件のプロジェクトと約5,000のコメントが失われました。
GitLabはこの事件をライブでTwitter配信し、詳細なポストモーテムを全公開しました。「バックアップは取られているだけでなく、定期的にリストア訓練しないと意味がない」「人間の手作業を最小化するため、IaCと自動化を徹底する」という教訓は、以後の業界標準に強い影響を与えました。事故の最中に隠さずライブで流す姿勢自体が、Blameless文化の好例として語り継がれています。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- リポジトリ構造（モノレポ / マルチリポ）
- ブランチ戦略（Trunk-Based / GitHub Flow）
- マージ方法（Squash / Rebase / Merge commit）
- タグ命名規則（SemVer / CalVer）
- 大容量ファイルの扱い（LFS / DVC / 外部参照）
.gitignoreと秘密情報検出の方針- SVN等レガシーVCSの移行計画（該当する場合）
こうした決定はADR（アーキテクチャ決定記録）として残しておくと、後からの見直しに効きます。
この記事に関連する記事
まとめ
本記事は構成管理について、Gitの優位性・モノレポvsマルチリポ・ブランチ戦略・マージ方法・タグ運用・LFS・秘密情報・AI時代の最適形まで含めて解説しました。如何だったでしょうか。
モノレポをデフォルトに、GitHub FlowかTrunk-Basedを選び、Squash merge+Conventional Commitsで履歴を構造化、Secret Scanning+pre-commitで漏洩をブロック。これが2026年の構成管理の現実解です。
次回は開発環境とローカル実行（Docker Compose・Dev Container・クラウドIDE）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は GitHub も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（62/95）