1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AI駆動趣味開発講座【第三講】Git・GitHubの基礎理解とWindows・SSH環境セットアップ

1
Last updated at Posted at 2026-09-20

Lecture 03: Understanding Git & GitHub Fundamentals: Windows & SSH Environment Setup

← AI駆動趣味開発講座:まとめページに戻る | ← 第二講へ | 第四講へ →

はじめに:第二部スタート!なぜコードを書かない私たちが「Git」を学ぶのか?

第一部(第一講・第二講)では、Node.js のセットアップからスタートし、AIとの対話のみであなたが作ったアプリを構築、さらに機能追加まで行いました。

今回からスタートする 「第二部:Git / GitHub 管理と Vercel によるホスティング公開編」 では、作ったアプリを安全に管理し、最終的にインターネット上に公開するステップへ進みます。

その最初のステップが、バージョン管理ツール 「Git(ギット)」 の導入です。

「コードを読まない・書かない趣味開発なのに、なぜGitが必要なのか?」

結論から言うと、コードを直接書かないAI駆動開発だからこそ、Gitによる「変更の可視化」と「状態の復元」が絶対に欠かせない安全装置になるから です。

本記事では、インストーラーの詳細な画面手順は既存の分かりやすい記事を参照しつつ、「Gitとは構造的に何をしているツールなのか」「なぜAI開発で決定的な役割を果たすのか」という本質 を整理して解説します。

【極めて重要な大前提:趣味開発ルール】
本連載の「コードを読まない・AIに実装を委ねる」スタイルは、あくまで自分や身近な人のためだけに作る個人の趣味開発・プロトタイプ限定のルールです。
実務・業務の開発現場において、コードや変更履歴(コミットログ)の中身を理解・検証しないままAI生成コードを放置することは、極めて不誠実であり、重大な障害や情報漏えいを引き起こす無責任な行為です。 業務開発に携わる際は、必ず変更内容の意図とリスクをレビューした上でGitを活用してください。

1. Gitの本質とは何か?(バージョン管理の仕組み)

Gitとは、ファイルの変更履歴を時系列で記録・管理する「分散型バージョン管理システム」 です。
RIiBoPtpMiRsMKX3dnzl5gb1Urj1-gr93ppp-1.avif

■ 「ファイルの別名保存」との違い

Gitを使わない場合、過去の状態を残そうとすると以下のような運用になりがちです。

my-app/
my-app_20260920/
my-app_20260920_修正/
my-app_20260920_最新/
my-app_20260920_本当に完成/

この方法には大きな問題があります:

  • どのフォルダーで「何を変更したのか」が分からない
  • ディスク容量を無駄に消費する
  • ファイル間の差分を追跡できない

■ Gitが提供する仕組み

Gitはフォルダーを丸ごと別名コピーするのではなく、プロジェクトの「スナップショット(その時点の状態)」と「変更差分」をデータベースとして記録 します。

[コミットA] アプリ初期作成
     │
     ▼ (差分:主要機能や画面表示ロジックを追加)
[コミットB] メイン機能の実装
     │
     ▼ (差分:ボタン配置や追加機能の実装)
[コミットC] 追加機能の実装
  • スナップショット: コミットした時点の全ファイルの状態を記録
  • 差分の追跡: どのファイルの何行目が追加・削除・変更されたかを厳密に記録
  • 復元(ロールバック): 過去の任意のコミット時点へ、プロジェクト全体を確実に戻せる

2. AI駆動開発においてGitが「必須」となる理由

コードを直接書かないスタイルにおいて、Gitは単なるバックアップ以上の決定的な意味を持ちます。

① AIが加えた変更の「差分(Diff)」を可視化できる

AI(ClineやChatGPT等)に修正を依頼すると、AIは複数のファイルを一瞬で書き換えます。
Gitを使っていれば、「AIが具体的にどのファイルのどこを変更したのか」が緑(追加)と赤(削除)の差分として一目で分かります。コードの細部を読まなくても、「意図したファイルだけが触られているか」を確認できます。

② 不具合が起きた際に「動いていた時点」へ確実に復元できる

AIに複雑な指示を出した結果、依存関係が崩れたりエラーが多発して画面が表示されなくなるケースがあります。
コードが読めない状態では、自力でデバッグして元に戻すことは困難です。
しかし、動いていた状態でGitに記録(コミット)してあれば、コマンドやエディタの操作1つで、確実に不具合発生前の正常な状態へ復元 できます。

③ 失敗のリスクがゼロになり、試行錯誤が容易になる

「壊れても確実に直前の状態へ戻せる」という保証があるからこそ、AIに対して恐れることなく新しい機能の追加や大規模なレイアウト変更を依頼できます。

3. Git・GitHubを使った基本の開発サイクル(全体像)

初心者が最も混同しやすいのが、GitとGitHubの関係です。両者は明確に異なる役割を持っています。

項目 Git GitHub
種別 ソフトウェア / ツール Webサービス / プラットフォーム
動作場所 あなたのPC(ローカル環境) クラウド上のサーバー(リモート環境)
主な機能 ファイルの変更履歴の記録・追跡・復元 Gitリポジトリの保管、共有、Web公開連携
ネット接続 不要(オフラインで全機能が使える) 必要(ブラウザや通信経由で利用)
  • Git: 自分の手元(ローカルPC)で履歴を記録・管理するツール
  • GitHub: そのGitの履歴データをクラウド上に保存・共有するWebサービス

■ 日常の開発フロー(6つのステップ)

実際のWeb開発では、手元の「Git」とクラウドの「GitHub」を組み合わせて、以下の6つのステップをぐるぐると回しながら進めていきます。

e1cb265e-ab9f-4817-b40a-2162351f41c6.avif

  1. ① clone(クローン): GitHub上にあるプロジェクトを、自分のパソコンへ丸ごとダウンロードして複製する。
  2. ② pull(プル): クラウド上の最新コードを手元に取り込み、作業環境を最新にする。
  3. ③ 編集: あなたのアイデアをもとに、AIにコードを修正・追加してもらう。
  4. ④ add(ステージング): 変更されたファイルの中から、今回の記録に含めたいものを待機場所へ登録する(git add)。
  5. ⑤ commit(コミット): 変更内容にわかりやすいメッセージを添えて、手元のパソコンに履歴を確定・保存する(git commit)。
  6. ⑥ push(プッシュ): 手元で確定したコミット履歴を、クラウド上のGitHubへアップロードして同期する(git push)。

まずは 「普段はこの順番(pull ➔ 編集 ➔ add ➔ commit ➔ push)で使うんだな」 という全体像を頭に入れておきましょう!

代表的な基本コマンド一覧

日常の開発で使う代表的なコマンドは、以下の4つだけ知っておけば十分です:

git pull    # GitHubの最新を取得
git add .   # 変更をステージング(待機場所へ一括登録)
git commit -m "変更内容"  # ローカルに履歴を記録
git push    # 確定した履歴をGitHubへ送信

※本連載ではVS Codeのボタン操作を中心に進めますが、裏ではまさにこのコマンドたちが動いています。実コマンドのイメージを持っておくと理解がぐっと深まります!

4. Gitの基本構造(3つの領域とクラウド連携の仕組み)

全体像が掴めたところで、「では、サイクルの中の『③ 編集 ➔ ④ add ➔ ⑤ commit』は、自分のパソコンの中でどう動いているのか?」 という内部構造を見ていきましょう。

■ パソコン内にある「3つの領域」

あなたのパソコンの中では、Gitによって以下の 3つの領域 が管理されています。

┌─────────────────┐      git add       ┌─────────────────┐     git commit      ┌─────────────────┐
│ 作業ディレクトリ │ ─────────────────> │ ステージング     │ ──────────────────> │  リポジトリ     │
│ (Working Tree)  │                    │ エリア (Index)  │                     │  (Repository)   │
└─────────────────┘ <───────────────── └─────────────────┘                     └─────────────────┘
  [サイクルの ③編集]     元に戻す (Restore)     [サイクルの ④add]                    [サイクルの ⑤commit]
                                                                                │
                                                                                ▼
                                                                     「main(ローカル)」に履歴確定!
                                                                     ここから push で GitHub へ届く

1. 作業ディレクトリ(Working Tree)— 【サイクルの「③ 編集」を行う場所】

実際にあなたやAIが直接ファイルを開いて見ているフォルダーそのものです(VS Codeのエクスプローラーに並んでいるファイル群)。
ここでAIに依頼してコードを生成・修正してもらいます。ただし、作業ディレクトリでファイルを書き換えただけの段階では、まだGitの履歴(セーブデータ)には記録されていません。

2. ステージングエリア(Index)— 【サイクルの「④ add」で乗せる待機場所】

次のコミット(履歴記録)に含めたい変更差分を登録しておく「一時的な待機場所(トレイ)」です。
「複数のファイルを変更したけれど、まずは完成した機能のファイルだけを記録したい」という選別を行うために存在します。VS Codeで変更ファイルの横にある「+」ボタンを押す操作(git add)によって、変更がこの待機場所に乗ります。

3. リポジトリ(Repository)— 【サイクルの「⑤ commit」で確定・保存される場所】

確定した履歴(コミットの連鎖)が安全に保存されるデータベースです(プロジェクト内の隠しフォルダー .git に格納されます)。
ここでコミットとして記録されて初めて「いつでもこの状態へ戻せるセーブポイント」になります。


■ 手元のリポジトリとGitHubはこう繋がる!(ブランチと通信の仕組み)

手元の「リポジトリ」にコミットが記録されたら、次は 「⑥ push」でクラウド(GitHub)へ送り届けます。
このとき、ローカル環境とGitHubの間では以下のような連携が行われています。

5b0bdb34-51fd-4d3a-adf3-d10ef0027468.avif

  • main(ローカルブランチ): あなたのパソコン内(リポジトリ)で直接履歴管理している現在のブランチです。
  • commit(コミット): 先ほど説明した「ステージング ➔ リポジトリ」へ変更を確定させる操作です。
  • push(プッシュ): ローカルで記録したコミット履歴を、クラウド上の「GitHub(main)」へ送り込みます。
  • origin/main(リモート追跡ブランチ): クラウド側(GitHub)の最新状態を、手元で把握・追跡しておくための中継地点です。
  • fetch(フェッチ): GitHub側の最新の変更情報を手元(origin/main)に取得して確認します。
  • merge(マージ): 取得した最新の変更を、自分のローカル作業ブランチ(main)に統合・合流させます。
  • pull(プル): fetch(取得)と merge(合流)を一度にまとめて実行し、GitHubの最新コードを手元の作業環境に一気に同期する操作です(pull = fetch + merge)。

VS Codeを使えば、これらの操作は難しい黒い画面のコマンドを打ち込まなくても、画面上のボタンをクリックしていくだけで直感的に進めることができます。

5. WindowsへのGitインストール

概念を理解したところで、実際にWindows環境へGitをインストールしましょう。

■ インストール手順の参照先

Windows向けGit(Git for Windows)のインストール手順については、以下のQiita記事にて最新の画面キャプチャ付きで網羅的にまとめられています。こちらの記事を参照しながら進めてください。

👉 Gitのインストール方法(Windows版) #Git - Qiita (takeru-hirai 様)

■ インストーラー設定のポイント

インストーラー実行時、多数の選択画面が表示されますが、基本的にすべての項目をデフォルト(初期選択)のまま「Next」で進めて問題ありません。


■ インストールの確認

インストールが完了したら、正常にコマンドが認識されているか確認します。

  1. VS Code を起動します。
  2. 上部メニューの 「ターミナル」→「新しいターミナル」 を選択します。
  3. ターミナルに以下のコマンドを入力して Enter を押します:
git --version

以下のようにバージョンが表示されれば、正常にインストールされています。

git version 2.xx.x.windows.x

※もし「コマンドとして認識されていません」という旨のエラーが出た場合は、VS Codeを完全に再起動するか、PC本体を一度再起動してください。

6. 初期設定:ユーザー名・メールアドレスの設定とSSHキーの作成

Gitのインストールが完了したら、最初に一度だけ行う初期設定を進めます。
※以下の設定手順は、先ほどご紹介した takeru-hirai 様のQiita記事(Gitのインストール方法(Windows版)) より一部引用しています。


■ ユーザー名とメールアドレスを設定します

VS Codeのターミナル(PowerShell)を開いて、以下のコマンドを実行してください。

ユーザ名の設定コマンド

git config --global user.name "ユーザー名は任意"

メールアドレスの設定コマンド

git config --global user.email "メールアドレス"

【なぜ必要なのか?】
Gitはすべての変更履歴に対して、「誰がこの変更を行ったのか」をメタデータとして記録します。この情報が設定されていないと、コミットを実行する際にエラーが発生して処理が中断されてしまいます。メールアドレスは、後ほど作成するGitHubアカウントと同じにしておくのがおすすめです。


■ SSHキーを作成します

次回以降、GitHubなどのリモートリポジトリと安全に暗号化通信・認証を行うための「SSHキー」をあらかじめ作成しておきます。
暗号化方式には、現在セキュリティが高く推奨されている Ed25519 方式を使用します。

以下のコマンドを実行してください(your_email@example.com の部分を、先ほどGitに登録したあなたのメールアドレスに書き換えてください):

ssh-keygen -t ed25519 -C "your_email@example.com"

実行すると、保存場所やパスワード(パスフレーズ)の設定を求められます。すべてデフォルトのままで問題ありませんので、何も入力せずにそのまま Enter キーを3回ポン・ポン・ポンと押してください。

Generating public/private ed25519 key pair.
Enter file in which to save the key (/c/Users/xxxx/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

ランダムなアスキーアートが表示されれば、キーペア(秘密鍵と公開鍵)の生成が完了です!

上記コマンドにより、以下の2つのファイルが生成されます:

  • 秘密鍵: ~/.ssh/id_ed25519(※パソコン内に厳重に保護。絶対に他人に渡さない)
  • 公開鍵: ~/.ssh/id_ed25519.pub(※GitHubに登録する鍵)

■ 設定内容の確認

登録内容が正しく保存されたかを確認するには、以下のコマンドを実行します:

git config --global --list

出力結果の中に、設定した user.name と user.email が表示されていれば初期設定は完了です。

7. クラウドの保管庫「GitHub」のアカウントを作成しよう

ローカル環境(あなたのPC)のGit準備が整ったので、次にリポジトリの保管場所となる GitHub(ギットハブ)のアカウントを作成(無料登録) しておきましょう!

■ 詳しいアカウント作成手順の参照先

GitHubのアカウント登録画面や入力手順については、以下のQiita記事にてスクリーンショット付きで非常にわかりやすく解説されています。この記事を参照しながら登録を進めてみてください。

👉 Githubアカウント作成方法 #GitHub - Qiita (hanamr8ngineer 様)


■ 登録の流れ(要点まとめ)

  1. GitHub公式サイト(github.com) にアクセスします。
  2. 画面右上の 「Sign up」(または「Sign up for GitHub」)をクリックします。
  3. 画面の案内に沿って以下の情報を順番に入力します:
    • Email: 先ほどGitの初期設定(user.email)で登録したメールアドレスを入力
      ※ Gitの初期設定と同じメールアドレスにしておくと、GitのコミットをGitHubアカウントに紐づけやすくなります。
    • Password: ログイン用パスワードを設定
    • Username: お好みのユーザー名(半角英数字・ハイフン)を設定
    • Email preferences: お知らせメールの受信希望(不要なら n)
  4. アカウント検証(パズル認証): ボット防止の簡単な画像パズルをクリアします。
  5. 認証コードの入力: 登録したメールアドレス宛に届く確認コード(数字)を入力します。
  6. アンケート等の画面が表示された場合は、最下部の 「Skip personalization」 をクリックしてスキップして構いません。

ダッシュボード(ログイン後のトップ画面)が表示されれば、GitHubアカウントの準備はすべて完了です!

8. GitHubへ公開鍵(SSHキー)を登録しよう

GitHubのアカウントが作成できたら、SSH接続してコードをやり取りする前に、先ほどPC内で作成した 「公開鍵」をGitHubに登録 します。
これを行っておくことで、パソコンとGitHubの間で安全な通信ができるようになります。

※本章の公開鍵登録およびSSH接続テストの手順は、以下のQiita記事を参考にしています。
👉 GitHubにおけるSSH接続の方法 #Git - Qiita (yuki-y15 様)


■ ステップ1:作成した公開鍵の内容をコピーする

作成した公開鍵(id_ed25519.pub)の中身をコピーします。
VS Codeのターミナル(PowerShell)で以下のコマンドを実行してください:

Get-Content ~/.ssh/id_ed25519.pub | Set-Clipboard

【POINT】
実行しても画面には何も文字が出ませんが、すでにクリップボードに公開鍵がコピーされた状態 になっています!
マウスでドラッグ選択して「最初や最後の文字が欠けてしまった」というコピペミスを防げる一番安全で確実な方法です。

※もし公開鍵の文字列(ssh-ed25519 ...)を目で確認したい場合は、パイプ以降を外して Get-Content ~/.ssh/id_ed25519.pub を実行すると画面に出力されます。


■ ステップ2:GitHub の Web画面から登録する

ブラウザでGitHubにログインした状態で、以下の手順で登録を行います。

  1. 画面の右上にあるプロフィールアイコンをクリックし、「Settings」を選択します。

スクリーンショット 2026-09-20 121539.avif

  1. 左サイドバーのメニューから「SSH and GPG keys」を選択します。

スクリーンショット 2026-09-20 121539.avif

  1. 「New SSH key」ボタンをクリックします。

スクリーンショット-2026-09-20-121556.avif

  1. 公開鍵の情報を入力して登録を完了します:
    • Title: 分かりやすい名前を入力します(例: laptop - 2026-09 や my-windows-pc など、どのパソコンの鍵か分かる名前)
    • Key type: Authentication Key のままでOKです
    • Key: 先ほどメモ帳等にコピーした公開鍵の内容(ssh-ed25519 ...)をそのまま貼り付けます
  2. 最後に緑色の 「Add SSH key」 ボタンをクリックして保存します。

これにて、Web上の公開鍵登録は完了です!


■ ステップ3:SSH接続ができるかテストしてみよう!

公開鍵の登録が完了したら、実際にあなたのパソコンからGitHubへ正常に接続できるかを確認しておきましょう。

VS Codeのターミナル(PowerShell)で、以下のコマンドを実行してください:

ssh -T git@github.com

初回接続時は、以下のように「接続先(GitHub)を本当に信頼しますか?」という確認メッセージが表示される場合があります:

The authenticity of host 'github.com (xxx.xxx.xxx.xxx)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

このメッセージが表示されたら、キーボードで yes と入力して Enter を押してください。

以下のように、あなたのGitHubユーザー名を含む認証成功メッセージ が表示されれば、SSH接続設定は完璧に成功です!

Hi あなたのユーザー名! You've successfully authenticated, but GitHub does not provide shell access.

【POINT】
「...but GitHub does not provide shell access(GitHubはシェルアクセスを提供していません)」という注意書きが末尾に付きますが、これは「GitHubサーバーでコマンド操作はできませんが、認証自体は完全に成功していますよ」という意味なので全く心配いりません。


【発展コラム】SSH接続の裏側で何が起きているの?(※興味のある方のみ)

先ほどの ssh -T git@github.com で、なぜパスワードを入力していないのに「安全に本人確認」ができたのでしょうか?
その裏側では、以下の図のように 「お互いを確かめ合う2段階のチェック」 が行われていました。

03b069e1-c456-4992-bdad-7a868dbb7ed2.avif

❶ サーバー確認(「相手は本当に本物のGitHubか?」)

  • 初めて接続したときに「Are you sure you want to continue connecting (yes/no)?」と聞かれて yes と答えましたね。
  • あれは、GitHubサーバーが持っている「ホスト秘密鍵」で作った署名を、あなたのパソコンが「ホスト公開鍵」で検証し、「通信相手が偽物や詐欺サーバーではなく、間違いなく本物のGitHubだ!」と確認するステップです。
  • この確認が完了すると、あなたのPC内の ~/.ssh/known_hosts というファイルに「本物のGitHubの鍵情報」が安全に記録され、次回以降は確認が出なくなります。

❷ ユーザー確認(「アクセスしてきたのは本当にあなたか?」)

  • 相手が本物のGitHubだと確認できたら、次はGitHub側が「本当にあなたが操作しているのか?」をチェックします。
  • あなたのパソコン内に大切に保管してある 「秘密鍵(id_ed25519)」 で暗号署名を作ってGitHubへ送ります。
  • GitHubは、先ほどWeb画面で登録してもらったあなたの 「公開鍵(id_ed25519.pub)」 を使って、その署名をピタリと照合します。
  • 一致すれば、「秘密鍵を持っている本物のあなたからのアクセスだ!」と確認され、晴れて Hi [ユーザー名]! You've successfully authenticated... と接続が許可されます。

【まとめ】
「相手が本物か」と「自分が本物か」を、お互いに 秘密鍵でサインして、公開鍵で確かめ合う。
だからパスワードを送信する必要がなく、通信を盗聴されてもパスワードが盗まれる心配が一切ない、極めて安全な通信方式なのです。

さらに「公開鍵暗号」や「共通鍵暗号」の仕組み・理論について深く知りたい方は、以下の分かりやすい解説記事もぜひ参考にしてみてください!
👉 【セキュリティ】公開鍵暗号方式・共通鍵暗号方式 #初心者向け - Qiita (mabo23 様)

第三講のまとめ

項目 要点
Gitの役割 ファイルの差分とスナップショットを時系列で記録するバージョン管理システム
AI開発での価値 複数ファイルの差分可視化、不具合発生時の即時復元、試行錯誤のリスクゼロ化
GitとGitHubの違い Git=ローカルのバージョン管理ツール / GitHub=リモートのクラウドホスティング
開発サイクル clone ➔ pull ➔ 編集 ➔ add ➔ commit ➔ push の全体フロー
基本構造 作業ディレクトリ(作業中)→ ステージング(選別)→ リポジトリ(履歴確定)
初期セットアップ Windowsインストーラーの実行、git --version 確認、名前・メアド登録、Ed25519鍵作成
GitHub連携準備 GitHubアカウントの作成、公開鍵(SSHキー)の登録、接続疎通テスト完了

これで、手元のローカル環境(Git)とクラウドの保管場所(GitHub)の両方の基盤がバッチリ揃いました!

謝辞・参考記事について

本記事の執筆にあたり、Windows環境へのGit導入手順、GitHubのアカウント作成手順、SSH接続設定の手順、および公開鍵暗号方式の解説について、以下のQiita記事を参考・一部引用させていただきました。分かりやすく丁寧な知見を公開してくださっている皆様に、心より深く感謝申し上げます。

【takeru-hirai 様、hanamr8ngineer 様、yuki-y15 様、mabo23 様へ】
本記事での引用やリンクのご紹介に関して、もしご都合の悪い点や気になる箇所などがございましたら、速やかに修正・削除等の対応をさせていただきます。大変お手数をおかけいたしますが、コメント欄等にて遠慮なくお知らせいただけますと幸いです。


次回予告(第四講へ進む)

▶ 【第四講】GitHubリポジトリ作成からローカルへのクローン・VS Code操作実践(Push & Pull)

GitHub上で実際に空のリポジトリ(demo)を作成し、VS Codeでフォルダー(test)を開いてクローン。ファイル作成から初めてのコミット&プッシュ、Web編集からのプル(Pull)同期まで、Git/GitHubの双方向サイクルをノーリスクのテスト環境で完全マスターします!


← 第二講へ | まとめページに戻る | 第四講へ進む →

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?