Gitは、ファイルの変更履歴を記録・管理するシステムです。
「いつ・何を・なぜ変えたか」を残すことで、AIとの業務でも変更を追跡・巻き戻せる状態が作れます。
非エンジニアがAIと一緒に業務を進めるとき、情報をどう書くか（Markdown）・どこに置くか（ディレクトリ構造）と並んで重要になるのが「変更の管理」です。
ファイルはいつか更新され、AIへの指示も書き換えられていきます。
その変更をどう記録するかが、AI業務を長期で安定させる鍵になります。
Gitの考え方を、実務の視点でノートに残します。
Gitがなければどうなるか
Gitの説明に入る前に、Gitがない状態で何が起きるかを整理します。
「自分には関係ない話」に見えても、読み進めると身に覚えのある場面が出てくるのではないでしょうか。
ファイル名で管理する方法の限界
ファイルを更新するとき、こんな方法を使ったことはないでしょうか。
提案書_v2.docx提案書_最終2.docx提案書_最終_修正後.docx
ファイル名に「v2」「最終」「修正後」をつけて上書きを避ける方法です。
これ自体は悪くない工夫ですが、時間が経つと問題が起きます。
「最終と最終2は何が違うのか」「v2からv3で何を変えたのか」が追えなくなります。
差分がわからず、理由が残りません。ファイルが増えるほど管理の負荷だけが上がっていきます。
ファイル名に「最終」「v2」をつける管理は、差分と理由が残らない。
ファイルが増えるほど混乱が増します。
AIに変更を頼み続けると起きること
AIを使った業務でも、同じ問題が起きます。
Claude CodeのようなAIツールにルールファイルや記事の修正を依頼したとき、AIはそのセッションの中で変更を加えます。しかし「2週間前にどんな変更を加えたか」「なぜその変更をしたのか」は、何もしなければ残りません。
セッションをまたぐたびに「確かこの前変えたはずなのに」「どのバージョンが最新だっけ」という状況が繰り返されます。AIとの業務が増えるほど、変更の記録がないことのコストが上がっていきます。
AIとの業務では「変更の記録がない」ことのコストが人間だけで作業するときより高くなりやすい。
セッションをまたぐたびに文脈がリセットされるからです。
Gitとは何か
上書き保存ではなく、履歴を積み重ねる
通常の「保存」は上書きです。今のバージョンを次のバージョンで置き換えるため、前の状態は消えます。
Gitの考え方は違います。変更のたびに「今の状態」をスナップショットとして記録していきます。
ファイルの中身が変わっても、過去のスナップショットはそのまま残ります。
Gitの発想は「保存」ではなく「記録の積み重ね」です。
昨日の状態も、1ヶ月前の状態も、振り返れる状態が続きます。
変更をスナップショットとして保存する仕組み
Gitは変更が起きるたびに、その時点のファイル全体の状態を「スナップショット」として保持します。
スナップショットを写真で例えると、日付順に並んだアルバムのイメージです。
「今日の1枚」を撮っても、昨日の写真は消えません。Gitの記録もこれと同じ構造です。
どの時点に戻っても、その時点の状態が完全に再現できます。
「いつ・何を・なぜ変えたか」が残る
スナップショットには「コミットメッセージ」という一言のメモを添えます。
記事タイトルをSEO向けに修正 ルールファイルにGEO対応ルールを追加 間違ったCTA文言を修正
このメモが変更の「理由」の記録になります。
後から見返したとき、何のためにその変更をしたのかが追えます。
非エンジニアがGitを知っておくべき理由
AI開発ツールはGitとの連携を前提に設計されている
Claude CodeをはじめとするAI開発ツールは、Gitと組み合わせて使うことを前提に設計されています。
これらのツールでは、Gitで管理されたプロジェクトと組み合わせて運用することが推奨されています。
Gitがない環境では、これらのツールが本来の機能を発揮しにくくなります。
AIを使う環境を整えるということは、Gitの仕組みを前提として受け入れるということでもあります。
ルールファイル・指示書の変更を追跡できる
AIへの指示を書いたファイル（CLAUDE.mdなどのルールファイル）は、業務の変化に合わせて更新されていきます。
サービスの方針が変わった、記事の書き方ルールを見直した、禁止事項を追加した
こうした変更がいつ・なぜ行われたか、Gitがなければ記録に残りません。
数ヶ月後に「なぜこのルールがここにあるのか」がわからなくなります。
ルールファイルの変更履歴を残すことは、AIとの業務を長期にわたって安定させる仕組みの一部です。
Gitの基本概念を日常の言葉に置き換える
技術的な説明に入る前に、3つの概念を日常の言葉に置き換えます。
この3つを押さえておくと、AIツールやエンジニアとのやり取りでGit関連の話が出てきたときに迷わなくなります。
| 用語 | 日常語での意味 | 補足 |
|---|---|---|
| リポジトリ | プロジェクトの保管庫 | フォルダに似ているが、変更履歴まで含めて管理する点が異なる |
| コミット | 変更の記録を残す操作 | 「保存」ではなく「記録」。実行するたびにその時点の状態が履歴に刻まれる |
| ブランチ | 試行錯誤を本流から切り離す分岐 | 別ノートで下書きして、OKなら清書に転記するイメージ。失敗しても本流に影響しない |
コミットは「保存」ではなく「記録」です。コミットするたびに「この時点のプロジェクトの状態」がGitの履歴に刻まれます。
AIと働く上でGitが機能する場面
概念の説明が続いたので、実際にGitが役立つ場面を3つ挙げます。
ルールファイルを更新したとき
CLAUDE.mdなどのルールファイルを変更したとき、コミットメッセージに理由を残します。
GEO対応ルールを追加（2026年6月Google公式指針を受けて）
このように書いておくと、後から「なぜこのルールが増えたのか」が追えます。
後から変更理由を確認できるため、AIと共同で作業するときも状況を整理しやすくなります。
以前との違いを比較できる
Gitは「差分を表示する機能」を持っています。昨日と今日でファイルがどう変わったかを、追加・削除・変更の単位で確認できます。
AIが修正したあと「どこが変わったのか」をすべて目で追うのは大変ですが、Gitの差分表示を使えば変更箇所だけを確認できます。レビューのコストが下がり、意図しない変更を見逃しにくくなります。
失敗したら戻せる
AIが加えた変更が意図と違ったとき、Gitを使えば変更前の状態に即座に戻せます。
「Ctrl+Z（取り消し）」と似ていますが、より強力です。
数日前・数週間前の状態にも戻せるため、実験コストが大幅に下がります。
「元に戻せる」という安心感があることで、AIへの依頼を躊躇わずにできるようになります。
Gitで変更履歴を管理することは、「安心して実験できる環境を作ること」でもあります。失敗しても戻せる仕組みがあることで、AIとの業務のスピードが上がります。
非エンジニアが最初に知っておきたいGitの使い方
概念だけ理解しても、実際にどう使うかがわからないと動けません。
実務でよく遭遇する場面を3つ整理します。
コミットにはコメントが必要、プッシュは不要
コミットは「変更の記録を新しく作る操作」です。
何のための記録かが残らなければ意味をなさないため、コメント（コミットメッセージ）が必須になります。
プッシュは「作った記録をリモート（GitHubなど）に送る操作」です。
記録はコミット時点で作られており、コメントもそこに含まれています。送る操作に改めてコメントは必要ありません。
コミット・プッシュしないとどうなるか
| 操作しない状態 | 何が起きるか |
|---|---|
| コミットしない | 変更が「作業中のまま」。ファイルを誤って消すと取り戻せない |
| プッシュしない | 記録が自分のPC上（ローカル環境）だけに存在する。PC破損・別端末ではアクセスできない |
こまめなコミット・プッシュは、万が一のときに「消える範囲」を最小化するための習慣です。
バッティング（コンフリクト）が起きたとき
別々の場所で同じファイルを変更すると、Gitが「どちらが正しいか判断できない」として止まります。
これをコンフリクト（競合）といいます。複数の環境やメンバーで作業していると普通に起きることです。
問題は、ファイルが多いとどのファイルがどう変更されたか自分では把握しきれないことです。
「どちらを残すべきか」を自力で判断するのは難しい場面がほとんどです。
実際に使いやすいのは、
AIに「○○プロジェクトでコンフリクトが起きている」と伝えて、比較を整理してもらう方法
です。
どのファイルで何が競合しているかをAIが整理し、「Aの変更は〇〇、Bの変更は△△ですが、どちらを残しますか？」という形で確認してくれます。
自分で覚えていなくても、提示された内容を見てどちらが正しいか判断できます。
Claude Codeであれば、リポジトリを直接参照して比較を出してもらえます。
Claude Codeを使わない場合は、GitのビジュアルGUIツールやAI開発ツールのエディタでコンフリクトを視覚的に解消できます。競合箇所が色分けで表示され、「現在の変更を採用」「入力された変更を採用」「両方を採用」の3択から選ぶだけです。どちらを残すか画面上で確認しながら判断できるため、非エンジニアでも対応しやすい方法です。
ファイルの書き方・置き場所・変更管理の3つがそろう
非エンジニアがAI業務を安定させるために押さえておきたい概念を整理すると、以下の3つになります。
| 概念 | 役割 |
|---|---|
| Markdown | 情報をどう書くか |
| ディレクトリ構造 | 情報をどこに置くか |
| Git | 情報をどう変更管理するか |
この3つがそろうと、「情報を書く・置く・管理する」というAI業務の土台が完成します。
AIを使いこなす以前に、この土台を整えることが、安定したAI運用につながります。
AIは魔法のツールではなく、整理された情報環境の上で力を発揮します。
次回は「README」を取り上げます。
プロジェクトに1つ置くこのファイルが、AIと人間が同じ前提を共有するための業務マニュアルとして機能する理由を解説します。
＼ ブログ更新が止まっている・記事運用を任せたい方へ ／
企画から執筆・公開まで、まるごとお任せください。お気軽にご相談を。
