構成管理 ― Git+モノレポ+GitHub Flowが鉄板 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第3弾として、構成管理（バージョン管理）について解説する記事です。

構成管理は土地の登記簿。Git がデファクトの現在、リポジトリ構造・ブランチ戦略・タグ運用は全ての開発プロセスの前提で、ここを雑にすると他の設計が全て空転します。本記事では Trunk-Based / GitHub Flow / Git Flow の使い分け、モノレポ vs マルチレポ、SemVer・タグ運用、SVN→Git移行まで解説します。

このカテゴリの他の記事

Gitが標準になった経緯

2005年、Linus Torvalds が Linux カーネル開発のために2週間で作ったのが Git です。それまでの商用 VCS（BitKeeper）のライセンスがカーネルコミュニティと揉めたのが直接のきっかけで、「中央サーバーなしで分散的に動き、高速で、ブランチが軽い」という、今では当たり前の特性を持って登場しました。

2008年の GitHub 公開以降、OSS の標準が Git に寄り、企業の閉じた開発もほぼ Git に統一されました。商用 VCS（Perforce・ClearCase）は今も一部の大企業やゲーム業界に残りますが、新規選定で選ぶ理由はほぼありません。現時点では Git一択 が現実です。

世代	VCS	特徴
第1世代	RCS・CVS	ファイル単位・中央集権
第2世代	Subversion（SVN）・Perforce	リポジトリ単位・中央集権
第3世代（現代）	Git・Mercurial	分散・高速・軽量ブランチ

なぜGitが勝ったか

技術的には「分散・高速・軽量ブランチ」が Git の強みですが、普及の決定打になったのは GitHubによるソーシャル化でした。PR（Pull Request）・Issue・Star といった仕組みで、コードレビューと OSS 貢献の体験が根本から変わり、開発者が「GitHub に置くために Git を使う」状態に一気に傾きました。

要素	Gitが優位な理由
分散	中央サーバーがダウンしても全員が完全なコピーを持つ
ブランチ軽量	数ミリ秒で作成・切替、捨てることに抵抗がない
マージ戦略の豊富さ	rebase・squash・merge commit を状況で使い分け
ホスティング連携	GitHub・GitLab・Bitbucket で PR フロー標準化
AI学習データの厚み	ChatGPT・Copilot が Git 操作を完璧に理解

AI 駆動開発の時代では、AIがGit操作を流暢に書けることが選定の決定打になりました。Perforce や ClearCase は学習データが薄く、AI エージェントがコミットや競合解決を正しく扱えません。これだけで新規選定から外れる理由になります。

構成管理で決めるべきこと

構成管理の設計は「Git を使う」で終わりではなく、以下の5つの軸を組み合わせて決めます。どれも後から変えるコストが高いため、プロジェクト開始時に決め切るのが鉄則です。

軸	選択肢
リポジトリ構造	モノレポ・マルチリポ・ハイブリッド
ブランチ戦略	Trunk-Based・GitHub Flow・Git Flow
マージ方法	Squash merge・Rebase merge・Merge commit
タグ・リリース運用	Semantic Versioning・日付タグ・未運用
大容量ファイル	Git LFS・Git Annex・別管理

この5つの組み合わせが、CI/CD・テスト戦略・レビュー運用の前提を決めます。特にリポジトリ構造は最上流で、ここをミスると全てやり直しになります。

モノレポ vs マルチリポ

リポジトリ構造の最大の論点が モノレポ（全部1つのリポジトリ）か マルチリポ（サービスごとに別リポ）かです。「モノレポは大企業の道具」という印象は古く、現時点では中小チームでもモノレポが有力になっています。

軸	モノレポ	マルチリポ
バージョン管理	全コード共通のバージョン	サービスごとに独立
クロスカット変更	1PR で完結	複数 PR で調整が必要
CI	変更範囲テストが必須（遅い）	リポジトリ単位で高速
権限管理	CODEOWNERS で制御	リポジトリ単位で制御
代表ツール	Nx・Turborepo・Bazel・pnpm workspace	（特別なツール不要）

Google・Meta・Uber・Airbnb はモノレポ。Amazonはマルチリポ寄り（「2枚のピザチームが1サービス1リポジトリ」思想）。どちらが正解かではなく、組織のコミュニケーション構造（Conway の法則）と合致するかで決まります。

モノレポを選ぶ判断基準

モノレポが有利になる条件は「コードが互いに依存している」「一括で変更する必要が頻繁にある」の2つです。逆に、独立性の高いサービス群ならマルチリポの方が運用が軽くなります。

状況	推奨
フロント + バックエンド + 共通型定義	モノレポ（型の一元管理で TypeScript の威力が最大化）
10以上のマイクロサービスを独立チームが持つ	マルチリポ（チーム境界を明確化）
ライブラリと利用アプリの同時開発	モノレポ（ローカル参照で即座に検証）
買収・子会社など独立した組織が集まった	マルチリポ（統合コストを払う価値がないケース多い）

筆者の経験では、8割のチームにはモノレポが刺さると感じています。マルチリポは「組織が本当に独立している」状態で初めて機能し、それは数十人〜数百人規模の明確な分業体制を持っている場合に限られます。迷ったらモノレポから始めて、規模に応じてマルチに分解する順が安全です。

モノレポは迷ったら第一候補。マルチリポは独立性の立証責任がかかります。

ブランチ戦略 — 3つの型

ブランチ戦略は CI/CD 記事でも触れますが、構成管理の観点ではどれだけ短命かが核心です。ブランチが長命になるほどマージ競合が重くなり、レビューも遅くなります。

gitGraph
    commit id: "main"
    branch feature-A
    commit id: "feat A1"
    commit id: "feat A2"
    checkout main
    branch feature-B
    commit id: "feat B"
    checkout main
    merge feature-A id: "PR#1 squash"
    merge feature-B id: "PR#2 squash"
    commit id: "release"

戦略	特徴	向いているケース
Trunk-Based Development	短命 feature ブランチ・数時間〜1日で main へ	高度な CI/CD・熟練チーム
GitHub Flow	feature branch + PR + main	Web サービス・モダン開発の鉄板
Git Flow	main + develop + release + hotfix	パッケージ製品・バージョン並行管理

新規プロジェクトでは GitHub Flow か Trunk-Based が鉄板。Git Flow は複雑すぎて、継続デプロイ型のサービスには過剰です。パッケージ製品・オンプレ配布ソフトなど「バージョン単位で独立運用する必要がある」ケースでのみ Git Flow が活きますが、そういうビジネスモデル自体が減っています。

マージ方法 — 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 単位の粒度で履歴を追う方が実務的で、リリースノート自動生成とも相性が良い。Rebase merge は熟練チームが Conventional Commits を徹底している場合に機能します。

3方式を混在させるのは最悪。Squashに統一が一番揉めません。

タグとリリース運用

リリースを識別するためのタグは、構成管理で軽視されがちな領域です。「いつのコードが本番に出ているか」を即座に特定できないチームは、障害対応で必ず詰まります。

命名	形式	向いているケース
Semantic Versioning（SemVer）	v2.3.1（Major.Minor.Patch）	ライブラリ・パッケージ製品
CalVer（Calendar Versioning）	2026.04.01	SaaS・頻繁にリリースする製品
ビルド番号	build-1234	CI/CD 内部の識別用
日付 + Gitハッシュ	20260422-abc123	簡易な本番追跡

SemVer は「互換性の破壊を Major で示す」というセマンティクスを担保できるチームでこそ機能します。破壊的変更を無計画に Major に突っ込むと機能しない。CalVer は「いつの時点のコードか」が一目で分かる利点があり、SaaSとの相性がいいです。

GitHub Releases や GitLab Release でタグと変更ログをセットで残すのが標準。Conventional Commits + 自動リリースノート生成（release-please・semantic-release）が現時点の鉄板です。

大容量ファイルとGit LFS

Git は大容量バイナリファイルが苦手です。数GBの動画・画像・機械学習モデル・ゲームアセットを普通にコミットすると、リポジトリが肥大化して clone に数時間かかる事態になります。

方式	特徴
Git LFS（Large File Storage）	ポインタだけ Git 管理、実体は別ストレージ
DVC（Data Version Control）	ML 向け、S3 等と連携してデータバージョン管理
外部ストレージ（S3・GCS）+ 参照	Git に一切入れず、バージョンだけ別管理
Git Annex	Git LFS より柔軟だが学習コスト高

Git LFSが最も普及しており、GitHub・GitLab・Bitbucket が標準対応。ただし LFS にも落とし穴があって、ブランチを大量に作るとストレージ費用が膨らむため、ML データセットなど数百GB規模は DVC や S3 参照の方が向きます。

バイナリを普通にコミットするとリポジトリが死にます。最初から LFS or 外部参照で設計します。

SVNからGitへの移行判断

現時点でも SVN（Subversion）が残っている現場は存在します。主に10年以上の運用を経た大企業や、CI/CD 整備が進んでいない組織です。SVN から Git への移行は工数が大きいですが、続ける選択肢はほぼ無いと見ていいでしょう。

SVN継続のデメリット	内容
ブランチが重い	ディレクトリコピーで作る設計、切替コストが高い
分散でない	中央サーバー障害で全員が止まる
AIツール非対応	Copilot・Cursor 等が Git 前提
モダンなCI/CDと相性悪	GitHub Actions・GitLab CI は Git 前提
採用不利	新卒〜中堅は SVN の実務経験がほぼない

移行の定番ツールは git-svn（履歴を保持して Git 化）。完全移行には数週間〜数か月かかりますが、「採用・開発速度・AI活用」の3つの観点で、続ける理由はもう残っていません。移行を決めたら、短期決戦で一気にやり切るのが鉄則です。段階移行は「SVN と Git 両方を維持する期間」が地獄になります。

SVN は延命するほど負債が増える。移行は短期決戦で終わらせるのが本命です。

.gitignoreと秘密情報の扱い

構成管理で事故の発生源No.1が、秘密情報（API キー・パスワード・トークン）の誤コミットです。一度コミットすると、Git の履歴に残り続け、Force pushで消しても履歴キャッシュに残るため、実質的に漏洩扱いになります。

対策	内容
.gitignore徹底	.env・*.pem・secrets/ を必ず除外
pre-commitフック	gitleaks・detect-secrets で自動検出
Secret Scanning（GitHub 標準）	push 時に秘密情報を検出、公開前にブロック
漏洩時のローテーション	漏洩した瞬間にキー・トークン全て即時無効化

2022年、Toyota の子会社がアクセスキーを GitHub に誤公開し、約30万件の顧客情報が5年間アクセス可能な状態になっていた事例があります。発覚後にキーを無効化しましたが、5年間の漏洩リスクをゼロにする方法はありません。.gitignore と pre-commit フックは、「面倒だから後で」が許されない領域です。

構成管理の数値Gate・運用指標

※ 2026年4月時点の業界相場値です。テクノロジー・人材市場の変化で陳腐化するため、定期的にアップデートが必要です。

構成管理の健全性は数値で追うのが実務。下記が業界定番の指標です。

指標	推奨値	超えたらどうするか
Featureブランチ寿命	2〜3日	1週間超で強制マージ検討、長命は競合地獄
1 PRの変更行数	〜400行	1000行超は分割。レビューが形骸化
mainへの直push	0件	全てPR経由、branch protectionで強制
コミット単位	Conventional Commits 準拠	feat:/fix:/docs: 等、semantic-release で自動バージョニング
リポジトリclone時間	〜30秒	超過したら LFS／履歴 shallow clone 検討
Secret Scanningアラート対応	5分以内	漏洩キーは即時ローテーション
.gitignore漏洩事故	0件	pre-commit hook で物理ブロック
タグ付けルール	SemVer／CalVer 統一	混在は履歴追跡不能
モノレポCI実行時間	PR時10分以内	変更範囲テスト（Nx／Turbo）で短縮

Secret Scanningが2022年以降GitHub標準機能になり、事故発見までの時間が劇的に短縮されました。「Toyota子会社の30万件顧客情報5年間アクセス可能事件」（2022年）は、Secret Scanning 未導入の時代の代償を象徴します。

秘密情報はコミット前に物理ブロック。「気をつける」は機能しない運用です。

構成管理運用の鬼門・禁じ手

構成管理で事故る典型パターン。どれも「コードの歴史を壊す」「組織の信用を失う」結末を招きます。

禁じ手	なぜダメか
SVN／Perforce／ClearCaseを新規採用	AI 学習データ薄、採用不利、現時点で合理性ゼロ
.envや秘密鍵をGitにコミット	履歴キャッシュに残り実質回収不能、Toyota 子会社30万件漏洩事件（2022）と同じ
Force pushをmain／developに実行	他メンバーの作業消失、履歴改変で監査NG
ブランチを1週間以上残してマージ	競合地獄、「80%できた」報告が3週間続く
バイナリファイル（動画・モデル）を普通にコミット	リポジトリが数十GBに肥大、clone に数時間
マージ方法（Squash／Rebase／Merge commit）混在運用	履歴が複雑化、「PR単位で revert」が不能に
Git Flowを継続デプロイのSaaSに採用	複雑すぎて開発速度が落ちる、GitHub Flow へ
コミットメッセージ規約なし	履歴検索・リリースノート自動化が不能
1年以上前のブランチを放置	バックログ墓場、定期トリアージで削除
モノレポ vs マルチリポを気分で混在	ツールチェーン分散、CI 重複運用

GitLab 2017年1月 DB削除事件（オンコール中に本番 DB 削除、5種バックアップ中4種機能せず6時間前のスナップショットから復旧）は、「バックアップは取る、ではなく戻せるで評価」という教訓の象徴です。

Force push はmain／developで絶対禁止、feature ブランチでの rebase は許容。どこで禁止か区別が肝心です。

AI時代の構成管理

AI 駆動開発では、構成管理の設計が AI エージェントの性能を直接左右します。AI が Git 操作を流暢に書けることは前提として、リポジトリ構造・コミット規約・ブランチ運用が AI にとって理解しやすい形になっているかが決定的に効きます。

AI時代に有利	AI時代に不利
Git + GitHub（標準）	SVN・Perforce（AIの学習データが薄い）
モノレポ（関連コードが一箇所）	マルチリポ（コンテキストが分散）
Conventional Commits	自由形式コミット
Trunk-Based／GitHub Flow	Git Flow（複雑で AI が間違える）
README・ADRがGit内にMarkdown	Confluence・Notion・口伝

AI エージェントに「このリポジトリで機能Xを実装してほしい」と依頼する時、関連コードが1リポジトリに揃っていて、コミット履歴が構造化されていることは、AI の成功率を劇的に上げます。逆に、依存サービスが10リポジトリに散っているマルチリポは、AI が全体像を把握できず手戻りが多くなります。

AI 時代はモノレポ + Conventional Commitsが圧倒的に優位です。

よくある勘違い①

構成管理は「Git を使えば終わり」と軽く見られがちですが、設計の抜けは必ず後で顕在化します。

Gitを使っていれば構成管理OK

Git はツールにすぎません。リポジトリ構造・ブランチ戦略・マージ方針・タグ運用の設計が構成管理の本質で、チームで合意されていないなら Git を使っていても構成管理は未整備です。

モノレポはGoogleだから成り立つ

現時点では、Turborepo・Nx・pnpm workspace が成熟し、5人のチームでもモノレポが運用可能です。大規模の道具という見方は古く、小規模こそモノレポの恩恵を受けやすい。

よくある勘違い②

ブランチは長く残しておくほど安心

長命ブランチはマージ地獄の温床。1週間以上残るブランチは、main の変更を取り込み続けないと競合が雪だるま式に増えます。2〜3日でmainに帰るのが健全です。

Force pushは絶対悪

main・develop への force push は確かに禁じ手ですが、自分のfeatureブランチでは rebase で履歴を整えるのが標準運用。「絶対ダメ」ではなく「どこではダメか」を区別するのが正しい理解です。

Git を使う＝構成管理できている、ではない。設計は別物です。

筆者メモ — GitLab 2017年1月 DB削除事件

構成管理を語るなら、GitLab の2017年1月31日の本番DB削除事件は外せません。オンコール担当のエンジニアが深夜の障害対応中に、誤って本番の PostgreSQL データベースのディレクトリを削除してしまいました。本来は待機系で実行するはずのコマンドでした。

事件の深刻度を増したのは、バックアップが5種類あったのに、そのうち4種類が機能していなかったことです。最終的に6時間前のスナップショットから復旧しましたが、その間の約300件のプロジェクトと約5,000のコメントが失われました。

GitLab はこの事件をライブでTwitter配信し、詳細なポストモーテムを全公開しました。「バックアップは取られているだけでなく、定期的にリストア訓練しないと意味がない」「人間の手作業を最小化するため、IaC と自動化を徹底する」という教訓は、以後の業界標準に強い影響を与えました。事故の最中に隠さずライブで流す姿勢自体が、Blameless 文化の好例として語り継がれています。

バックアップは「取る」ではなく「戻せる」かで評価。訓練なきバックアップは気休めです。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• VCS（Git 一択）
• リポジトリ構造（モノレポ／マルチリポ）
• ブランチ戦略（Trunk-Based／GitHub Flow／Git Flow）
• マージ方法（Squash／Rebase／Merge commit）
• タグ命名規則（SemVer／CalVer／ビルド番号）
• 大容量ファイルの扱い（LFS／DVC／外部参照）
• .gitignoreと秘密情報検出の方針
• SVN等レガシーVCSの移行計画（該当する場合）

最終的な判断の仕方

構成管理の本質はコードの歴史を追跡可能にすることで、Git を使うだけでは半分も達成できません。リポジトリ構造・ブランチ戦略・マージ方法・タグ運用・秘密情報管理の5つをセットで設計し、チーム全員が同じルールで動く状態にして初めて機能します。ツールと運用設計を混同しないのが第一歩です。

現時点で筆者が推す鉄板構成は「Git + GitHub + モノレポ + GitHub Flow + Squash merge + Conventional Commits + SemVer／CalVer + Git LFS + Secret Scanning」です。AI 駆動開発との相性・小規模から大規模までスケールする柔軟性・採用の観点、どれを取ってもこれ以上の選択肢はありません。マルチリポは組織が本当に独立している大規模組織限定、SVN は移行一択、Perforce・ClearCase は新規選定の対象外です。

選定の優先順位

1. モノレポをデフォルト — マルチリポは独立性の立証責任をかける
2. ブランチ戦略はGitHub FlowかTrunk-Basedを選ぶ — Git Flow は避ける
3. Squash merge + Conventional Commitsで履歴を構造化
4. Secret Scanning + pre-commitで漏洩を物理的にブロック

「迷ったらモノレポ + GitHub Flow」これで8割のチームは事足ります。

まとめ

本記事は構成管理について、Gitの優位性・モノレポvsマルチリポ・ブランチ戦略・マージ方法・タグ運用・LFS・秘密情報・AI時代の最適形まで含めて解説しました。如何だったでしょうか。

モノレポをデフォルトに、GitHub FlowかTrunk-Basedを選び、Squash merge+Conventional Commitsで履歴を構造化、Secret Scanning+pre-commitで漏洩をブロック。これが2026年の構成管理の現実解です。

次回は開発環境とローカル実行（Docker Compose・Dev Container・クラウドIDE）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。