非エンジニアのAI活用体験
Gitって何?非エンジニアが「なぜエンジニアはみんな使うのか」をAIと一緒に理解してみた
PR本記事はアフィリエイト広告(プロモーション)を含みます。紹介する商品・サービスの選定基準や体験談は編集部の見解に基づきます。
この記事を読むと何がわかるか
- 「Git」という言葉がそもそも何を指しているのか、専門用語を使わずにわかります
- なぜエンジニアがこぞってGitを使うのか、身近な例え話で腑に落ちます
- 実際に手を動かす前段階として、「触ってみたい」という気持ちになれる状態を目指します(実際の操作は次の記事で扱います)
「Git」という言葉、聞いたことはあるけれど、結局何なのか説明できない——そんな方は多いのではないでしょうか。この記事は、プログラミング未経験の筆者が、生成AIに素朴な疑問をぶつけながら「Gitとは何か」を理解していった過程を、そのまま体験談として記録したものです。専門用語はできる限り避け、出てきた場合はその場で噛み砕いて説明します。
そもそもの疑問: Gitって何?なぜみんな使うの?
きっかけは単純な疑問でした。「エンジニアの人たちが『Gitに上げる』『ブランチを切る』と言っているのをよく見かけるけれど、結局何をしているんだろう?」というものです。そこで、AIのチャットに率直にこう聞いてみました。
自分: Gitって何ですか?プログラミングの知識が全くない人にもわかるように教えてください。
AI: Gitは、簡単に言うと「文書やファイルの変更履歴を記録して、あとから見返したり元に戻したりできる仕組み」です。Wordの「変更履歴の記録」機能を、もっと本格的にしたものだとイメージしてください。
この時点で、「あ、Wordの変更履歴みたいなものか」という最初のとっかかりができました。ここから、AIに質問を重ねながら理解を深めていきます。
「なぜ必要なのか」をAIに聞いてみる
次に気になったのは、「Wordの変更履歴機能があるなら、わざわざGitを使わなくてもいいのでは?」という点でした。
自分: Wordにも変更履歴機能がありますが、それとGitは何が違うんですか?
AI: 大きな違いは2つあります。1つ目は、Gitは文書だけでなく、プログラムのコードのような「たくさんのファイルの組み合わせ」全体を、まとめて記録・管理できることです。2つ目は、複数人が同時に別々の変更を加えても、あとで安全に1つにまとめられる仕組みが用意されていることです。Wordの変更履歴は基本的に1つのファイルの中の話ですが、Gitは「プロジェクト全体の歴史」を記録するイメージに近いです。
ここで、「1人で使うWordの機能」と「複数人・複数ファイルを前提にした仕組み」という違いが見えてきました。
💡 ポイント: 最初から完璧に理解しようとせず、「自分がすでに知っているもの」に例えてもらうと、専門用語の壁がぐっと下がります。
Gitの基本用語を、身近な例え話で整理してもらう
続けて、Gitでよく出てくる用語を、身近な例えで説明してもらいました。
自分: 「リポジトリ」「コミット」「ブランチ」という言葉がよく出てきますが、それぞれ何のことですか?例え話で教えてください。
AI: 例えるなら、こんなイメージです。
- リポジトリ: プロジェクト全体を保管しておく「専用の保管庫」のようなものです
- コミット: 「ここまでの変更を記録として残しておく」という、セーブポイントを作る操作です。ゲームでいう「ここまで進んだ状態を保存する」に近いイメージです
- ブランチ: 本編とは別に、「もしこうしてみたら」という試し書きができる、複製されたノートのようなものです。本編を汚さずに実験でき、うまくいけば本編に合流させ、うまくいかなければそのノートだけ捨てられます
「セーブポイント」「試し書き用のノート」という例えのおかげで、抽象的だった用語が急に具体的なイメージに変わりました。
| Gitの用語 | 身近な例え |
|---|---|
| リポジトリ | プロジェクト全体を保管する専用の保管庫 |
| コミット | ここまでの変更を記録するセーブポイント |
| ブランチ | 本編を汚さずに試せる複製ノート |
| プッシュ | 自分の手元の変更を、共有の保管庫に反映すること |
| プル | 共有の保管庫にある最新の状態を、自分の手元に取り込むこと |
なぜエンジニアはみんな使うのか、腑に落ちた瞬間
ここまでの説明で一番腑に落ちたのは、次のやり取りでした。
自分: 結局、Gitを使うと何が一番うれしいんですか?
AI: 一言でいうと「安心して実験できること」と「誰が何を変えたか、あとから追えること」です。ブランチという仕組みのおかげで、本編を壊す心配をせずに試行錯誤ができます。そしてコミットという記録が残るので、「いつ、誰が、何を、なぜ変えたか」をあとから振り返れます。これがあるから、複数人での作業でも、何か問題が起きたときに原因を特定しやすくなります。
「安心して実験できる」「あとから振り返れる」という2点は、実はエンジニアに限った話ではありません。文章を書く仕事、資料を作る仕事、どんな仕事にも当てはまる考え方です。この汎用性の高さが、エンジニアがこぞってGitを使う理由なのだと理解できました。
⚠️ 注意: この記事では概念の理解までを扱っています。実際にGitやGitHub Desktopのようなツールを操作してみる体験は、次の記事「バージョン管理(Git)を、AIに手伝ってもらいながら非エンジニアが初めて触ってみた」で扱います。
まずはここから: 最初の一歩
概念のイメージがつかめたら、次はいよいよ実際にツールに触れてみる番です。難しく考えず、まずは次の2つを用意するところから始めてみてください。
- まずGitHubの公式サイトにアクセスし、メールアドレスで無料アカウントを登録する
- 次にGitHub Desktopの公式サイトから、自分のパソコン(Windows/Mac)に合ったインストーラーをダウンロードし、インストールする
- 実際の操作手順(リポジトリの作成、コミットの体験など)は、次の記事「バージョン管理(Git)を、AIに手伝ってもらいながら非エンジニアが初めて触ってみた」で1つずつ解説しています
AIと一緒にGitを理解するためのプロンプト例(3つ)
自分でも同じように理解を深めたい場合に、そのまま使えるプロンプト例を紹介します。
プロンプト例(専門用語を身近な例えで説明してもらう場合):
「Git」という言葉について、プログラミングの知識が全くない人にも
わかるように、身近な例え話を使って説明してください。
・専門用語(リポジトリ、コミット、ブランチなど)が出てきたら、
その都度、身近な例えを添えてください
・説明の長さは、1つの用語につき2〜3文程度にまとめてくださいプロンプト例(自分の仕事に置き換えて理解する場合):
私は[自分の仕事内容、例: フリーランスのライター]をしています。
Gitの「変更履歴を記録できる」「試し書きができる」という考え方を、
私の仕事に例えるとどうなるか、具体例を挙げて説明してください。プロンプト例(理解度を確認してもらう場合):
Gitについて、私は次のように理解しました。この理解に
誤りや不足があれば指摘してください。
・私の理解: [自分の言葉でGitの理解を書く]💡 ポイント: 「自分の言葉で説明してみて、それをAIに添削してもらう」という使い方は、理解度の確認にとても有効です。間違って理解していた部分に気づきやすくなります。
使用例: 事務代行業を営む吉田さんのケース
個人で事務代行業を営んでいる吉田さんの例です。吉田さんは、クライアントの中にWeb制作を依頼する人が増えてきたことをきっかけに、「エンジニアが何気なく使っているGitって何なんだろう」と気になっていましたが、専門書は難しそうで手が出せずにいました。
- まず「専門用語を身近な例えで説明してもらう」プロンプトを使い、リポジトリ・コミット・ブランチの基本的なイメージをつかみました
- 続けて「自分の仕事に置き換えて理解する場合」のプロンプトを使い、事務代行の仕事で例えると「クライアントごとの書類のバージョンを記録しておく仕組み」に近いことを理解しました
- 最後に自分の言葉でGitの理解を書き出し、AIに添削してもらったところ、「ブランチ」の理解にやや誤りがあったことに気づき、修正しました
吉田さんいわく、「専門書を読むより先に、AIに素朴な質問をぶつけながら理解できたので、心理的なハードルがかなり下がった感覚がある」とのことでした(これは吉田さんの体感であり、当社が効果を計測した数値ではありません)。
Before/After: Gitへのイメージの変化
| 項目 | AIに聞く前 | AIに聞いた後 |
|---|---|---|
| Gitのイメージ | 「エンジニアだけが使う難しい専門ツール」 | 「変更履歴を記録し、安心して試行錯誤できる仕組み」 |
| 専門用語への抵抗感 | リポジトリ・コミット・ブランチが何かわからず身構えていた | 身近な例え(保管庫・セーブポイント・複製ノート)でイメージできる |
| 次の一歩への気持ち | 難しそうで手が出せなかった | 実際に触ってみたいという気持ちになれた |
※上記は一般的に想定される理解度の変化の整理であり、当社が数値として計測したものではありません。
よくある質問
Q. Gitを理解するのにプログラミングの知識は必要ですか? この記事で扱った「考え方」のレベルであれば、プログラミングの知識がなくても理解できます。実際にコードを書く場面になると、また別の知識が必要になりますが、まずは考え方を理解することが第一歩です。
Q. AIに聞くだけで本当に理解できますか? 本記事のように、身近な例えに置き換えてもらったり、自分の理解を添削してもらったりする使い方は、専門書をいきなり読むよりも心理的なハードルを下げやすい方法だと感じています。ただし、実際に手を動かして触ってみることで、理解はさらに深まります。
Q. 次は何をすればいいですか? 概念のイメージがつかめたら、次は実際にツールを操作してみる段階です。次の記事「バージョン管理(Git)を、AIに手伝ってもらいながら非エンジニアが初めて触ってみた」で、GUIツールを使った実際の操作を紹介しています。
まとめ
Gitは「変更履歴を記録し、安心して試行錯誤できる仕組み」だと理解すると、専門用語の壁がぐっと下がります。エンジニアではない人にとっても、AIに素朴な疑問を投げかけながら身近な例えに置き換えてもらうことで、専門書を読むよりも取り組みやすく理解を深められる可能性があります。次は、実際にツールを触ってみる体験に進んでみましょう。