GitHub をやさしく理解する
Claude Code と組み合わせて GitHub を使うと、ファイルの変更履歴・公開・バックアップが一気にまとまります。このページでは、仕組み・用語・PR ワークフロー・公開範囲・料金 を、Claude Code を使う人の視点でやさしく解説します。
とりあえず要点だけ知りたい方へ
結論だけまとまった軽量版を なぜ GitHub を使うのか に用意しています。先にそちらを読むと、このページの位置づけが分かりやすくなります。
GitHub をひとことで言うと
GitHub は、ファイルの変更履歴を自動で記録してくれるオンライン保管庫 です。
ファイルを「いつ・誰が・どこを変えたか」がすべて記録され、いつでも過去の状態に戻せます。世界中のエンジニアがソースコードの管理に使っているサービスですが、文章ファイルや画像にも同じように使えます。
Google ドライブ・Dropbox との違い
似たようなオンラインストレージとの違いを整理します。
| Google ドライブ / Dropbox | GitHub | |
|---|---|---|
| 主な用途 | ファイル共有・同期 | 変更履歴の管理 |
| 履歴の粒度 | 数日〜数十日分が自動保存 | すべての変更が永久に残る |
| どこを変えたか | ファイル単位 | 1 文字単位で差分表示 |
| 公開機能 | リンク共有 | Web サイトとして公開可能（GitHub Pages） |
| Claude Code との相性 | 連携には追加設定が必要 | 標準で連携、コマンド一発で保存・公開 |
ざっくり言えば、Google ドライブが「今のファイルを置いておく場所」なのに対し、GitHub は「過去から現在までのすべての変化を記録する場所」です。
Claude Code と組み合わせる 5 つのメリット
1. Claude が間違えても安心して戻せる
Claude Code はファイルを直接編集します。たまに「思っていたのと違う書き換え」をすることもありますが、GitHub に保存しておけば 数秒前の状態にワンコマンドで戻せます。
「AI に任せて壊れたらどうしよう」という不安を、GitHub が肩代わりしてくれます。
2. PC が壊れてもファイルが消えない
GitHub に保存（プッシュ）しておけば、PC が壊れても・水没しても・買い替えても、新しい PC で同じ作業を続けられます。提案書や履歴書のように「絶対になくしたくないもの」ほど、GitHub に置く価値があります。
3. スマホや別の PC からも確認できる
GitHub に保存したファイルは、ブラウザから見られます。出先でスマホから「あの提案書の数字どうだったっけ」と確認したり、家の PC で書きかけたものを会社の PC で続けたり、といった使い方ができます。
4. ポートフォリオやサイトとして公開できる
GitHub Pages という機能を使うと、保存したファイルをそのまま 無料で Web サイトとして公開できます。写真家のポートフォリオ、ライターの記事まとめ、自己紹介ページなどを、Claude Code に「公開して」と頼むだけで世界に届けられます。
このガイドのサイト自体も GitHub Pages です
今あなたが読んでいるこのページも、GitHub に保存されたファイルから自動生成されて公開されています。
5. AI エージェントが「過去の経緯」を読んで賢く動ける
これは少し意外かもしれませんが、履歴と PR（プルリクエスト）を残しておくと、Claude Code 自身の判断精度が上がります。
Claude Code は作業中に、必要に応じて以下の情報を自分で読みに行きます。
- コミット履歴（
git log）— いつ・なぜ・何を変えたか - 差分（
git diff）— 直近の変更内容 - PR 説明文 — 「なぜこの変更を入れたのか」の背景
そのため、こんな会話が成立します。
あなた: 「先週入れた変更で何かおかしくなった気がする。原因を調べて」
Claude: （履歴と差分を読んで）「3 日前のコミットで○○を変えた影響です。
当時の意図はこうだったので、こう直すのが安全です」
履歴がないと AI は「今のファイルの状態」しか見えず、勘で推測するしかありません。履歴と PR を残すことは、自分のためだけでなく、AI エージェントへの引き継ぎ資料にもなります。
最低限知っておきたい 3 つの言葉
Claude Code が代わりに操作してくれるので、意味だけ覚えれば OK です。
| 用語 | 普段の言葉に置き換えると | 何をするときに使うか |
|---|---|---|
| リポジトリ | プロジェクト用のフォルダ | 案件・テーマごとに 1 つ作る |
| コミット | 「ここまで OK」のしおりを挟む | 区切りの良いところで保存 |
| プッシュ | GitHub にアップロードする | コミットしたものをオンラインに送る |
図解：コミットは「しおり」を時系列で残す
ファイルの編集途中に コミット を打つと、その時点のファイルの状態がまるごと「しおり」として残ります。後からどのしおりにでも戻せます。
図解：あなたの PC ↔ GitHub の関係
リポジトリ（フォルダ）は、あなたの PC と GitHub の両方に同じものが置かれます。プッシュ で PC → GitHub にアップロードし、プル または クローン で GitHub → PC にダウンロードします。
実際の使い方は、たとえばこんなイメージです。
専門用語を打ち込む必要はなく、日本語で意図を伝えるだけ で動きます。
なぜ PR（プルリクエスト）を作るのか
修正をいきなり main ブランチに直接書き込まず、別ブランチで作業 → PR を作って → マージ という流れを踏むのが、Claude Code を使う場合の標準的な進め方です。一見遠回りに見えますが、この一手間が 「壊さない・戻せる・後から読み解ける」 ための仕組みになっています。
main ブランチを「常に動く正の状態」に保てる
main ブランチは「本番に反映済み・常に動く状態」の置き場として扱います。修正はすべて 別ブランチ（しおりの分岐） で進めるので、修正中にうまく動かなくなっても本番側には影響しません。マージするまでは何度でもやり直せる、安心して試せる作業領域が手に入ります。
「変更の意図」を AI と未来の自分のために残せる
PR には タイトル・説明・関連 Issue・変更ファイル一覧 がひとまとめに残ります。これが後から効いてきます。
- 半年後の自分が「なぜこの変更を入れたんだっけ？」を 1 分で思い出せる
- Claude Code が新しい修正をするときに、過去の PR を読んで判断材料に使う（前述の「メリット 5」と同じ理由）
- 不具合が出たときに「いつ・なぜ入った変更か」を辿れる
コミットメッセージだけだと「何を変えたか」しか残りませんが、PR は 「なぜ」「どこに影響するか」「どう確認したか」 をまとめて記録できます。
「本番反映」の明確な節目になる
PR をマージしたタイミングが「この変更は本番に出してよい」という決定の瞬間になります。Claude Code に「PR をマージして」「マージされたものを xserver にデプロイして」と頼むときも、この節目があると指示が明確になります。
逆に PR を経由しないと、ローカルでの「ちょっと試した変更」と「本番に出すべき変更」の境目が曖昧になり、事故が起きやすくなります。
一人で使うときも PR を作る価値がある
「自分しか触らないのに PR を作る意味あるの？」と感じるかもしれませんが、メリットの大半は一人プロジェクトでも有効 です。
- 修正中に他の作業に切り替えたくなったとき、ブランチごと切り替えれば中断しても安全
- マージ前に diff を一覧で見直せるので、思わぬ変更の混入に気付ける
- 履歴がきれいに残るので、Claude Code が次の修正を考えるときの材料になる
このガイドの事例（9. 修正と PR）も、この方針で進めます。
Public（公開）と Private（非公開）の使い分け
GitHub のリポジトリには 2 種類あります。
| Public（公開） | Private（非公開） | |
|---|---|---|
| 見える人 | 世界中の誰でも | あなたと招待した人だけ |
| 検索エンジン | ヒットする可能性あり | ヒットしない |
| 向いているもの | 公開したい作品・公開ブログ | 提案書・履歴書・下書き全般 |
原則 Private で作成してください
Claude Code の作業用リポジトリは、必ず Private で作成してください。
一度 Public にしたファイルは、たとえ後で削除しても、誰かにダウンロード・キャッシュされている可能性があり、完全に取り消すことはできません。
公開して良いもの・悪いもの
| 公開しても良い | 公開してはいけない |
|---|---|
| 自己紹介サイト・ポートフォリオ作品 | クライアントの提案書・見積もり |
| 一般公開済みのブログ記事 | 履歴書・職務経歴書（連絡先入り） |
| OSS のソースコード | API キー・パスワード・認証トークン |
| 顧客情報・社内資料 |
迷ったら Private にしておく のが安全です。
無料で使える範囲とデータの所在
料金
個人利用であれば、ほぼすべての機能が無料 で使えます。
- Private リポジトリは 無制限 に作成可能
- ストレージは合計 1 GB 程度が目安（テキスト中心なら十分）
- GitHub Pages による Web 公開も無料
あなたのファイルはどこに渡るのか
Claude Code を使うとき、ファイルが渡る相手は次の 2 者です。
| 相手 | 渡るもの | 何のため |
|---|---|---|
| Anthropic（Claude の提供元） | あなたが Claude に見せた 会話とファイルの内容 | AI が回答を生成するため |
| GitHub | あなたが 保存した ファイル | バックアップ・履歴管理のため |
どちらも世界水準のセキュリティで運用されており、Private リポジトリの中身が他人に見られることはありません。Anthropic の利用規約・プライバシーポリシーや GitHub の規約で、個人ファイルの扱いは保護されています。
詰まりやすいエラーと対応
| エラー | 主な原因 | 対応 |
|---|---|---|
gh: command not found |
GitHub CLI 未インストール | macOS Part 1 / Windows Part 1 でインストール |
not logged in to github.com / push 時に認証ダイアログ |
gh auth login 未実行・認証期限切れ |
gh auth login を実行（または Claude Code に「gh で再ログインして」と依頼） |
Permission denied (publickey) で push 失敗 |
SSH 認証で接続している場合、鍵が GitHub に登録されていない | gh auth login で HTTPS 認証に切り替えるのが手早い。SSH 派は SSH と鍵ファイル も参照 |
Issue 作成で No default repository |
作業フォルダがリポジトリではない、または別フォルダにいる | cd で作業フォルダに移動。gh repo view で繋がっているか確認 |
Repository ... already exists |
同名リポジトリが既にある | 別名で作るか、GitHub 上で慎重に削除してから再作成 |
failed to push some refs |
ローカルとリモートで履歴が分岐している | Claude Code に「force push せず履歴を整合させて push して」と依頼 |
| Public で作ってしまった | gh repo create で --private を付け忘れた |
Claude Code に「リポジトリを private に変更して」と依頼。GitHub 上の Settings → Danger Zone から手動でも可 |
困ったら Claude Code に エラーメッセージをそのまま貼り付けて 相談するのが一番早いです。
GitHub の操作でこういうエラーが出ました。原因と直し方を教えてください。
事例ページ側の解決事例は 11. トラブルシュート。
次に読むもの
- 要点だけまとめた軽量版: なぜ GitHub を使うのか
- セットアップに進む: macOS Part 1 / Windows Part 1
- 実践: WordPress (xserver) を Claude Code で管理 / 9. 修正と PR