AIが広がっていくことによって、非エンジニアの人もエンジニアの知識に触れることが増えていると思う。
例えば、ファイル生成の時にAIがコードを書いて実行していたり、動画をコーディングベースで作っていたり、写真を解析する時にOCRを使ったり…
CLIのコーディングツールとして始まったClaudeCodeとかCodexも今ではGUI上で非エンジニア的な用途で使われている。
この中で僕が今のうちに押さえておいた方がいいと思っている概念がGitである。
特にClaudeCodeを使って仕事をしていくとしたらマストで必要になるし、エンジニアがやっているほど厳密に押さえなくてもいいので概念だけ知っているとめっちゃ便利。
ということで今回はGitについて非エンジニアでもわかるように解説をしていこうと思っている。
非エンジニアでGitに興味がある人、Gitを触りたいけど何を学べばいいかわからない、本を買ってみたけど結局よくわからない人などの参考になれば幸い。
Gitって何？
そもそもGitってなんなのか。よく聞くであろうGithubとかGitlabとかとは違うのか？どうやって使うのかなどを紹介していきたい。
Gitとは、バージョン管理ツール
結論、Gitは「フォルダ丸ごとの変更履歴」を残しておくツール。
Googleドキュメントの「変更履歴」を見たことがある人は多いと思う。いつ、どこが書き換わったかが残っていて、過去の版にも戻せる。
Gitは、あれをフォルダ全体でできるようにしたものだ。
フォルダの中の原稿も、メモも、設定ファイルも、まとめて履歴が残る。
1つだけ違うのは、記録するタイミングを自分で決めること。「導入を書き直した」のように、一言メモを添えて記録していく。
ちなみにGitは元々、Linuxというソフトウェアの開発のために作られたツール。
なのでプログラムのコードを管理するものというイメージが強い。
ただ、中身はただのファイルの変更履歴なので、Markdownで書いた原稿やメモ、設定ファイルでも普通に管理できる。
GitHubは違うの？
ここで「GitHub」も併せて紹介したい。
結論から言うと、Gitは仕組みそのもの、GitHubはGitで管理するファイルを保管できるサービスである。
Gitは自分のパソコンの中だけで完結する。
一方で、GitHubはその履歴ごとネット上に保存して、他の人と共有したり、別のパソコンから使ったりできるようにするサービス。
よく非エンジニアでもGoogleドライブやDropboxを使ってファイル管理をしているケースが多いと思う。Googleドライブの「Git版」と思ってもらえればざっくりOK。
GitLabも同じ立ち位置のサービスで、GitHubとどちらを使うかの違いでしかない。
なので一旦、
- Git：履歴を記録する道具
- GitHub / GitLab：その履歴を置いておく・共有するための場所
とだけ覚えておけば大丈夫。
今はCLIじゃなくてデスクトップアプリケーションベースでできる
もともとGitを使うためにはMacで言うところのターミナルっていう黒い画面を触らなくてはいけなかった。
これはコマンドを覚える必要があって結構大変だった。
今ではデスクトップアプリケーションベースでできるし、そうではなくてもClaudeCodeとかに「ここまでの変更をコミットしてプルリクエスト出して」とか言えばちゃんと管理してくれる。
よって基本的な概念だけを押さえればいいっていう状況。
なんでまたGitをやらなきゃいけないのさ
ここでは、非エンジニアがGitを押さえておくべき理由を2つ紹介する。
ClaudeCodeなどのAIエージェントはフォルダ単位で動くから
ClaudeCodeやCodexは、基本的に「1つのフォルダ」を作業場所にして動く。
そのフォルダの中のファイルを読んで、書き換えて、新しく作る。
つまり、AIが勝手にファイルをガンガン書き換えていくということだ。
上手くいけば最高なんだけど、そうじゃない時もある。
実際に自分も、ClaudeCodeを使って業務ツールを作っていた時に、バグAを直していたら、その影響がいろんなところに波及してしまって、「ちょっと待ってくれさっきの場所に戻してくれ」って感じで戻りたくなった時があった。
ここでGitで管理していれば、
- AIがどのファイルのどこを変えたのかが一目でわかる
- ダメだったら、変更前の状態にすぐ戻せる
- 上手くいったところだけ残せる
という状態になる。
AIに作業を任せるなら、いつでも前の状態に戻れることがそのまま安心感につながる。
というのも、戻れるとわかっていれば、AIに大胆な作業も任せられるから。
ただ、Gitで戻せるのはGitで管理しているファイルだけ。管理していないファイルを消された場合は戻せないので注意して欲しい。
Githubを通じて様々なツールが配布されているから
もう1つの理由が、AI関連のツールの多くがGitHubで配布されていること。
ClaudeCodeのskillsやMCPサーバー、便利なスクリプトなどは、GitHubのリポジトリとして公開されていることがめちゃくちゃ多い。
「このツール良さそう」と思って配布元を見に行くと、だいたいGitHubのページに飛ばされる。
そこでGitの概念を知らないと、「クローンしてください」と書かれていても何をすればいいのかわからない。
正直、ここで脱落している非エンジニアはめっちゃ多いと思う。自分も最初、Githubの画面を見て、「人に読ませる気あるんか」と思ったくらいに専門用語が多い。
逆に言えば、Gitの基本さえ押さえておけば、世界中の人が作ったツールをそのまま使えるようになる。
Gitの基本概念
ここからは、非エンジニアが押さえておけばOKなGitの基本概念を紹介していく。
リポジトリ
リポジトリは、Gitで管理している「フォルダ」のこと。
普通のフォルダと違うのは、中のファイルの変更履歴がすべて記録されていること。
ClaudeCodeで作業するフォルダをリポジトリにしておけば、そのフォルダ内の変更はすべて記録できる。
main・ブランチ
ブランチは、作業の「分かれ道」のこと。
mainは本線で、ちゃんと動く・完成している状態を置いておく場所。
新しいことを試したい時は、mainからブランチを分けて、そっちで作業する。
上手くいったらmainに取り込む。ダメだったらブランチごと捨てればいい。
本線を汚さずに試行錯誤できるのがブランチの良さだ。
コミット
コミットは、履歴を1回記録すること。
最初に説明した「自分で決めたタイミングで記録する」のがこれ。
コミットする時は「何を変えたか」のメモ（コミットメッセージ）も一緒に残す。
後から履歴を見返した時に、どこで何をしたかがわかるようになる。
プルリクエスト
プルリクエストは、「このブランチの変更をmainに取り込んでいいですか？」というお伺いのこと。
GitHub上で、変更内容を一覧で確認して、問題なければ取り込む、という流れになる。
チームで作業する時の確認の仕組みだけど、1人でも「AIが何を変えたのかを最後にまとめて確認する場」として使える。
マージ
マージは、ブランチの変更をmainに取り込むこと。
プルリクエストで確認して、OKならマージする。これで作業が本線に反映される。
クローン
クローンは、GitHubなどにあるリポジトリを自分のパソコンにまるごとコピーしてくること。
人が配布しているツールを使う時は、だいたいこのクローンから始まる。
プッシュ・プル
プッシュは、自分のパソコンの変更をGitHubに送ること。
プルは、GitHubにある最新の状態を自分のパソコンに持ってくること。
別のパソコンで作業したり、配布元のツールがアップデートされた時に使う。
まとめてみる
ざっくりまとめると、こんな感じ。
- リポジトリ：履歴付きのフォルダ
- main / ブランチ：本線と分かれ道
- コミット：履歴を1回記録する
- プルリクエスト：取り込み前の確認
- マージ：本線への取り込み
- クローン：GitHubから丸ごとコピー
- プッシュ / プル：GitHubとの送受信
ただ、これらのコマンドを自分で打つ必要はない。
ClaudeCodeに「コミットしておいて」「ブランチ切って作業して」と言えば、ちゃんとやってくれる。
大事なのは、何が起きているのかを理解できることだ。
実際に作業をするときのイメージ
ここからは、前の章で紹介した基本概念を、実際の作業の流れに沿って見ていく。
例として、ClaudeCodeで作った動画編集用のskillに、新しい機能を足す場面を考えてみる。
①リポジトリを用意する
まずは作業するフォルダをリポジトリにする。
すでにあるフォルダなら、ClaudeCodeに「このフォルダをGitで管理して」と言えばOK。
人が配布しているツールを使う場合は、GitHubからクローンしてくるところから始まる。
②ブランチを切る
作業を始める前に、mainからブランチを分ける。
「新しい機能を試すからブランチ切って」と頼めばいい。
これで、mainの「ちゃんと動く状態」はそのまま残る。
③作業して、区切りごとにコミットする
あとはClaudeCodeにいつも通り作業してもらう。
「ここまでは上手くいった」というタイミングで、「ここまでコミットしておいて」と頼む。
コミットメッセージもClaudeCodeが書いてくれるので、自分で考えなくてもいい。
途中でおかしくなったら、「1つ前のコミットに戻して」で元に戻せる。
④プッシュして、プルリクエストを出す
機能ができたら、ブランチをGitHubにプッシュして、プルリクエストを出す。
ClaudeCodeに「プッシュしてプルリクエスト出して」と言えば一発。
ここで、mainと比べて何が変わったのかを一覧で確認できる。
⑤確認して、マージする
変更内容を見て問題なければ、マージしてmainに取り込む。
これで新しい機能が本線に入る。
逆に、作ってみたけどイマイチだったらブランチごと捨てればいい。mainは何も変わっていないので、ノーダメージだ。
流れをまとめると
- リポジトリを用意する（またはクローンする）
- ブランチを切る
- 作業して、区切りごとにコミットする
- プッシュして、プルリクエストを出す
- 確認してマージする（ダメならブランチごと捨てる）
ただ、1人で作業しているなら、毎回ここまで丁寧にやらなくてもいい。
ちょっとした修正ならmainで直接作業して、コミットだけしておく、というのでも十分だと思う。
大事なのは、「戻れる状態」を作りながら作業することだ。
実際にClaudeCodeで使うシーン
ここでは、僕が実際にClaudeCodeでGitを使っているシーンを紹介する。
自分の作業場所の管理
1つ目は、自分の作業フォルダの管理。
動画編集用のskillの管理
僕は動画編集用のskillを作って使っている。
動画編集の作業が終わるたびに、Claudeの方から「こういう問題が今回発生して、これを次回から対応できるようにしようと思いますが、よろしいですか？」みたいなことを言われてそれをskillに反映している。
skillは使いながら何度も修正していくものなので、変更履歴を残しておくとめちゃくちゃ便利。
「前のバージョンの方が良かった」となった時に、すぐ戻せる。
CLAUDE.mdの管理
CLAUDE.mdは、ClaudeCodeにルールや前提を伝えるためのファイル。
これを毎回記入していったりするのは大変。
よって自分のCLAUDE.mdの大元になるようなテンプレートをGithubで管理していくのがおすすめ。
他の人のGitHubリポジトリからクローンする
2つ目は、他の人が公開しているリポジトリをクローンして使うシーン。
チーム単位で作業をするため
一つのフォルダを複数人が使って作業する場合にはGithubを使っていくことが推奨される。
人が作ったリポジトリをクローンしてくれば、その中身をベースに作業を始められる。
また、CLAUDE.mdとかAGENTS.mdとかをチームで共有することもできるので結構これはおすすめ。
人が配布しているskillsを使うため
GitHubには、他の人が作ったskillsがたくさん公開されている。
クローンしてくれば、そのまま自分のClaudeCodeで使える。
ただ、人が作ったものをそのまま入れるのは注意が必要。中身を確認せずに使うと、意図しない動きをすることもある。
クローンした後に、ClaudeCodeに「このskillが何をするのか説明して」と聞いてから使うのがおすすめかな。
まとめ ~新しい教養になるスキルがGit！？~
最後に、今回の内容を振り返っておく。
- Gitはフォルダ丸ごとの変更履歴を残すツール。GitHubはその履歴を置いておく・共有する場所
- AIエージェントはフォルダ単位でファイルを書き換えるので、Gitで戻せる状態にしておくと安心
- AI関連のツールはGitHubで配布されていることが多く、Gitを知っていると使えるツールが一気に増える
- コマンドは覚えなくていい。概念だけ押さえて、操作はClaudeCodeに任せればOK
ここまで読んでもらえればわかる通り、Gitはもうエンジニアだけのものではない。
僕は、Gitは「AIを使う人の新しい教養」になっていくと思っている。
ひと昔前に、ExcelやGoogleドライブが職種に関係なく使われるようになったのと同じ流れだ。
たしかに、Gitの操作自体はAIに頼めばやってくれる。
ただ、AIが「コミットしました」「ブランチを切りました」と言った時に、何が起きているのかわからないと、結局は任せきりになってしまう。
逆に概念さえ押さえておけば、AIに的確な指示を出せるし、何かあった時に自分で戻れる。
今回紹介した、リポジトリ・ブランチ・コミット・プルリクエスト・マージあたりを押さえておけば、まずは十分だ。
AIを使えば使うほど、ファイルを触る量は増えていく。
だからこそ、エンジニアじゃなくても「履歴を残して、いつでも戻れる」状態を作っておくことが大事だと思う。
Gitを触り始めるきっかけになれば嬉しい。
