GitHubの使い方は、ゲームのセーブ履歴にたとえると分かりやすい

出典: 【簡単にわかる】エンジニアぽくて苦手な人も多いGitHub、AI時代に全員必須ツールなので解説する

AI に任せる量が増えるほど、何がどう変わったのかを、人が追いきれなくなります。気づいた時には、元の形が分かりません。前の版に、ちゃんと戻せるでしょうか？

語り手は、GitHub が必要だと感じた理由を2つ挙げます。1つ目は、AI の性能が上がり、AI が変更したファイルを人間が追うのが難しくなってきたこと。

語り手（動画の中で・0:51〜）

AIの性能が上がりすぎても、もう人間がAIが変更したファイルを追うのが不可能になってきたと

AI がどこを変えたのか、人が全部は追えなくなった、という話です。2つ目は、更新し続けるコンテキストの履歴が残らないと困ること。語り手は、これを「マスターコンテキスト」と呼びます。

語り手（動画の中で・1:18〜）

あれなんか前の方が性能良かったけど戻せないということになりがちだし

前の版の方が出来は良かったのに、戻せない。そうなりがちだ、と語り手は話します。変更の履歴そのものも財産になる、とも。

聞き手も、AI や X の投稿で GitHub を勧められても、よく分からず使っていない、と話します。語り手は、エンジニア用語を使わずに、文系の仕事でもできる使い方を説明する、と応じます。

任せる量が増えるほど、先に増えるもの。それは作業より、何が変わったのかを後から探す手間です！

私なら、AI に任せても、出す・止める・任せるの境界は自分で決めます。そのために要るのが、AI が何を変えたかを後から追える履歴。

何が変わったか見えないままでは、出すのか止めるのか、決めようがありません。決めるのは私で、その材料になるのが履歴。

9月25日、私は AI に頼んで、企画力のスキルを作りました。最初の版は、頼んだとおりのもの。そのあと、私が承認していない変更が2回入り、2件とも元に戻す操作で取り消しました。

翌9月26日に足したのは、私が GO を出した2点（意欲の見方と、企画の探し場所）だけ。戻す時は、1つの操作で、承認済みの2行だけを取り消せる形です！

語り手の話は、追えなくなる前に履歴を取っておく話です。私の場面は、承認していない変更を履歴の上で見つけて、取り消したところまで。残す理由を語る動画と、承認した物だけを残した私の場面。どちらが上とは言いません。

ゲームでボス戦の前にセーブする時の感覚を、思い出してみてください。もしセーブしていなかったら、どこからやり直しでしょう？語り手が GitHub を説明するたとえも、このセーブです。

語り手は、GitHub を一言で表すのは難しい、と前置きします。今回の用途で大事なのは、保存履歴が残ること。

語り手（動画の中で・2:50〜）

でも今回使う用途で特に重要視されるのはまあセーブ履歴、保存履歴が残るっていうことやね。

ここでの「セーブ履歴」は、ボス戦の前に毎回保存したセーブが、全部残っていくイメージです。セーブしなければ、最初のデータに戻る。AI が全部のコードを消せば、それきりです。

聞き手は、AI がバージョン1、1.1とファイルで残してくれれば GitHub はいらないのでは、と聞きます。答えは、AI が壊したら、パソコンが潰れたら終わり。

Google ドライブにも、履歴の機能はついています。GitHub は履歴を残すために作られたもので、詳しく残り、競合も起きにくい、と語り手。今回は、1人プラス AI たくさんで使う使い方です。

語り手（動画の中で・5:13〜）

ちょっとだけ最初に注意しておくのはギットとギットハブって違うんですよ。

Git はバージョンを管理する側の仕組みで、GitHub はそれを使った Microsoft のサービスです。データを上げた先は、Microsoft 側のサーバー。

語り手は Mac なので、その手順は省かれます。Windows の人は先に Git のソフトを入れる必要があり、迷ったらスクリーンショットを AI に見せて聞けばよい、という話でした。

保存の仕組みが Git、預け先が GitHub。分けて覚えると、何が手元にあって、何が預け先にあるのか、見えてきませんか？

私なら、履歴は、古い答えを消して上書きせず、その時その時の答えを残し続けます。セーブ履歴という考えと、重なる向き。

語り手は、保存履歴が残ることを軸に、仕組みと預け先を分けて説明します。私なら、この章からは、その2点だけを持ち帰ります！

GitHub に登録して画面を開いても、何から始めればいいのか分かりません。最初の壁は、たいていここ。頼む先を AI にしたら、何が変わるでしょう？

語り手は、登録した後の画面を見ても分からない、文系にはアレルギーが出る、と話します。空のフォルダを1つ用意し、Codex に開かせます。

頼み方は、作った ID を伝えて、この ID の Git と連携して、と頼むだけ。パスワードなど漏れてはいけない情報が出る時は、操作をこちらに渡し、AI には読み込ませない、と添えます。

Claude Code でも可能。Windows 版は、先に GitHub 側の設定が要る人もいます。

語り手（動画の中で・9:13〜）

とりあえずAIに任せましょう。

連携はストレスが大きく、エンジニア感が強くて、自分には関係ない気がしてきます。それなら、まず AI に任せよう、という答え。聞き手は、AI をこう使っていいのか、意外と盲点だった、と話します。

語り手（動画の中で・10:03〜）

めんどくさいから。いいからお前がやるんや。

語り手のコツは、自分でやらずに「いいからお前がやるんや」と任せること。画面では、Codex がログイン画面を開き、認証まで進みます。

認証コードの入力まで AI に任せる手もある、と付け加えます。ただ、やっていいかは諸説あり。全ての認証情報を、AI の会社に渡すことになるからです。

連携とは、このパソコンと GitHub を直接つなぐこと。認証もなしに急に上がるのは怖いので、先につないでおく必要がある、という話です。

頼む先が AI になると、つまずく所が変わります。手順の難しさより、何を AI に渡さないか。分かれ目は、そこ！

私なら、手を動かす所は AI に渡します。渡さないのは、鍵と、出す・止めるの決定。

6月12日、私は、設定一式の置き場（1,569ファイル・30MB・コミット（セーブ）4つ）を、GitHub の Private のリポジトリ（フォルダの単位）に預けました。

その時、長いコマンドをチャットからコピーして打つと、途中の改行で2行に分かれ、失敗しました。リポジトリは未作成で、手元のデータは無事。

AI が1行で動く道具を作り直し、私が実行して、成功しました！Private であること、手元と GitHub の最後のコミットが同じであることも確かめています。

語り手の形は、連携そのものを最初から AI に頼むもの。私の場面は、手で打って失敗した所を AI に渡し、やり直した形です。

GitHub の画面を開くと、知らない言葉が並びます。でも、語り手が挙げる用語は5つだけ。コミットしたら、それで安心していいのでしょうか？順に追うと、手元に残る物と GitHub に届く物の境目が見えてきます。

語り手が挙げるのは、個人で使う最低限の用語5つ。1つ目のリポジトリ（フォルダの単位）は、フォルダごと GitHub にコピーするイメージです。

2つ目は、コミット（セーブ）。例は、AI に提案スライドを作らせ、1回目がいい感じにできたので保存しておく場面です。コミットは積み上がり、いつでも好きな所に戻れます。

語り手（動画の中で・15:21〜）

こっちの保存自体はこっちのパソコンで行われるのがコミット。で、それをまとめてMicrosoftのサーバーに上げるのがプッシュなんですよ。

コミットは、手元のパソコンの中での保存。それをまとめて Microsoft のサーバーへ上げるのが、3つ目のプッシュ（まとめて上げる）です。プッシュすれば、別のパソコンやチームの人も同じ状態を取り出せます。

4つ目のプル（取得する）は、サーバーに上げた物を取ってくること。勝手に同期されると怖いので、明示的にプルすると話します。

5つ目のブランチ（枝分かれ）は、パラレルワールドです。例は、ToDo リストに時間を測る機能をつける場面。思いどおりにできたらマージ（合体）、できなければ枝分かれの手前まで戻ります。

語り手（動画の中で・21:36〜）

正直ね、細かい用語とか覚える必要はないんですよ。

細かい用語は、覚えなくていい。大事なのは保存履歴が残せることで、ブランチは機能ごとに切ると少し扱いやすい、くらいで足りるという話です。知っていれば、履歴を管理する選択肢が広がります。

5つ並ぶと、いちばん差が大きいのはコミットとプッシュの違い。手元に積むか、GitHub に届けるか。ここを分けて見ると、履歴がどこにあるかが見えてきます！

私なら、用語を覚える前に、プッシュが届いたかを見る手を先に置きます。委ねた先が止まっていても気づける仕組み。それが先です。

10月13日の記事に、私の作業フォルダの履歴の件数と、GitHub に届いた最後の日時を書きました。

私の記事より（GitHubのバックアップは届いている？パソコンの中と最後の日付を見比べて確かめる）

私の作業フォルダはGitで管理し、コミットは1,377件あります。GitHubに届いた最後の日時は、9月26日の9時37分です。

1,377件は、10月13日の数。10月29日の朝は、手元が1,587件。GitHub に届いた最後は、9月26日の朝の1件です。用語より先に、届いたかを見る手を置く理由がここにあります。

手元は、それより633コミット先。指示書やスキルを入れた別の置き場は、手元が212件。GitHub の最後は8月6日で、210件が届いていません。

まだ届いていない分の中に、約207MBの1ファイルがあります。GitHub の1ファイル100MBの上限を超える大きさ。

語り手は、用語は5つで足りると話します。私の手元では、コミットは積み上がっているのに、プッシュが GitHub に届いていません！

一度書いた物は、あとで消しても履歴に残ります。書いたこと自体を忘れていたら、どうなるでしょうか？動画は、会社の業務を上げてよいかという問いから、この話に入ります。

聞き手は、会社の業務を GitHub に上げるのはよくないと思っていた、と話します。語り手の答えは、基本的には問題ない。でも、拡張機能などいろいろなものと連携させるので、ウイルスに遭いやすく、GitHub 経由で漏れた情報が多いと続けます。

語り手（動画の中で・16:55〜）

基本的には個人情報や特にあのパスワード等々は絶対書かないようにする

個人情報、特にパスワードは、どんな時も書かない。それが基本の作法だと話します。

語り手（動画の中で・17:50〜）

で、これ何がやばいって忘れるんすよ。個人情報を書いちゃったことを。

怖いのは、書いたことを忘れてしまう点。履歴なので、昔のある瞬間だけ個人情報が入っていた物を、AI やプログラムが虱潰しに探します。1個でも取られたら終わり、と話します。

流出したら困るデータは、載せない。一方で、載せないと使えない場面もあり、線引きは微妙だとも話します。クレジットカード番号は論外。

消せば済む話ではありません。履歴に入ったら、残る。勝負は、入れる前です！

私なら、鍵や個人情報は、履歴に入る前に止める仕組みを先に置きます。守る物を決めるのは人。止める仕事は、検査に任せます。

10月22日の記事に書いたのは、AI からパスワードを見えなくしたい、という話。

私の記事より（Claude Code 情報漏洩対策は何から始めるか、飯塚浩也さんの5つの防御を動画の順に追う）

2026年10月9日、私は、AIにパスワードなどを直接見られない形で、うまく設定もしやすくしたい、と書きました。

その向きは、私の作業フォルダでは検査の形です。コミットの前に、鍵が混ざっていないかを調べる検査が走ります。見つかれば、コミットは止まる仕組み。

6月12日に設定一式を GitHub に預けた時にも、この検査と、秘密に当たるファイルを預けない設定を付けました。

10月8日の週次の採点レポート。note の記事のプレビューURL（鍵つき）を写していました。検査がそれを見つけて、自動の保存コミットが10月9日の朝から約45時間止まりました。

直し方は、鍵を伏せ字にすること。レポートを書き出す側にも、鍵を伏せる道具を足しました！

コミットに入る手前で止まった、鍵つきのURL。語り手は、書かないことを作法として話します。私の手元では、書かない決まりの手前に、鍵を見つけて止める検査がありました。

コンテキストを、全部履歴にする必要はあるのでしょうか？動画の答えは、更新し続ける物だけ。上げる物を選ぶところから、話が始まります。

語り手は、コンテキストを2つに分けます。会議の議事録のように、一度読むだけのもの。お客さんのプロフィールや、よく使うスキルのように、書き込んで更新し続けるもの。後者を、語り手はマスターコンテキストと呼びます。

語り手（動画の中で・26:15〜）

書き込んで更新するか読むだけかの違いって感じですね

分かれ目は、書き込んで直していくか、読むだけか。例は、お客さんの情報に、ビールが好き、と書き足されていく場面。

実演1では、プロフィールを音声入力で話し、AI に Markdown のファイルとして保存してもらいます。コミットとプッシュを頼めば、GitHub への送信まで済む流れ。

AI が書いた登録者数は、800人。8万人に直して改めてコミットとプッシュをすると、変更の前後が行で並びます。聞き手は、用語が分かると意外といい、と話します。

使う理由として挙がるのは、散らかったファイルを AI に整理させて壊れても戻せること。パソコンが潰れた時の備えにもなります。

実演2はブランチ。別のプロフィールを足して画面でブランチを切り替えると、足したファイルがあります。メインへのマージを頼めば、合体。1人なら、コミットとプッシュだけで足りると話します。

最後に、GitHub が難しい人は設定を自分でやっているのだと思う、と語り手。AI にやらせれば大体どうにかなる、全部任せるのが AI と融合している指標、とも話します。

語り手（動画の中で・40:11〜）

これぐらい自分でできるしっていうのは逆に甘え。

自分でできそうなことを AI に任せないのは、むしろ甘え、という言い方。コミットとプッシュのやり方は、音声入力でも登録したコマンドでもいいと話します。

全ての作業を AI の窓から命令する世界が来る。そのやり方に慣れておくことが、将来への投資であり保険になる、と締めくくります。

全部ではなく、更新し続ける物だけを選んで上げる話。先に要るのは、上げる物を選ぶ線引きです！

私なら、AI に任せる範囲が広がるほど、履歴に入れる物は自分で選びます。実行のボールを AI に渡す点は、動画と同じ向き。

任せる物が増えるほど、何を残すかの線は自分で引く。手を動かすのは AI、履歴に入れる物を選ぶのは私です。

9月29日の朝のLIVEで、私は、アウトプットしている物の種類を分けて、コンテキストとコンテンツを分けていく、と話しました。

あわせて話したのは、AI が作ったコンテンツは混ぜてはいけない、混ぜるとぐちゃぐちゃになる、ということ。

Obsidian などで、混ぜない設計をするのが大事、とも話しました。

更新し続ける物と、AI が作った物。この2つを混ぜないことが、上げる物を選ぶ線引きの最初の決まりです。

語り手が話すのは、更新し続けるコンテキストだけを上げて、AI に全部任せる世界に慣れること。私の場面は、AI が作った物と、更新し続ける物を混ぜない設計を話した所です！

語り手は、GitHub を「セーブ履歴」が全部残る場所と説明します。話は、登録もつなぎ方も AI に頼む形、用語5つ、個人情報とパスワードの扱いへ。最後は、更新し続けるコンテキストだけを上げる考え方でした。

AI に任せるほど要るのは、何が変わったかを後から追える履歴。私は、承認していない変更2件を、元に戻す操作で取り消しました。頼りにしたのは履歴。出す・止める・任せるの境界は、私が決めます！

コミットは手元の記録。プッシュしなければ、GitHub には届きません。私の手元は1,587件。GitHub に届いている最後は、9月26日の朝の1件。私なら、届いたかを見る手を先に置きます。

個人情報とパスワードも、履歴に残るもの。私の手元では、鍵つきのURLが、コミットに入る手前で検査に止められました。上げるのは、更新し続けるコンテキストだけ。AI が作った物とは混ぜません。

AI に頼んで直してもらったファイルは、手元でどんどん増えていきます。いま変更を任せている仕事を1つ選ぶなら、その変更を、後から追える形で残せていますか？