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

出典: GitHubを使わずにAIを使う危険（ここなのAI大学）

冒頭から、データが全て消える可能性への呼びかけです。ここなさんが話しているのは、Claude Codeのようにパソコンの中で動くAIを使う場面で、作ったものをどこに残すかが最初の話題になります。

ここなさんは、GitHubを知らずにAIを使う人へ、突然データが全て消える可能性があるため、今学んでほしいと呼びかけます（0:00）。

ここなさん（動画の中で・0:14〜）

ですけど、これ実は大げさに言っているわけではないんです。ていうのもクロードコードみたいにパソコンの中で動くAIを使っていると、パソコンが壊れてしまった時にこれまでのAIとのやり取りや貯めていた[ナレッジ]が全部消えてしまうんです。

パソコンが壊れるとフォルダーや会話の記録も消えると説明します。GitHubなら中身をネット上へコピーできるとの話です（0:40ごろ）。

毎週AIに記事や資料を作らせるフォルダも、保存先がパソコンの中だけなら、パソコンと一緒に失われます。

私のMacでは、毎日11時47分に、自動で動くAIの仕事が、ノート一式をzipにしてGoogleドライブへ送ります。Macが壊れた時にクラウドから戻すためです。

9月24日から10月2日までの7個、約8.5GBは、ホームフォルダ直下の「Google Drive」という普通のフォルダにありました。Macの中だけです。

私がFinderで見つけました。10月3日にAIに頼んで本物のGoogleドライブへ移し直しました。クラウドへ送る対象だった7個を、本物の保存先へ移した形です。

本物のGoogleドライブには、いま88個のzipがあります。最新は10月12日の分です。毎日自動で動くAIの仕事の行き先と、そこにあるファイルは別々に確かめる対象です。

毎日動いていたバックアップです。それでも7個の行き先が本物のGoogleドライブでなければ、Macが壊れた時にクラウドから取り戻せません。

ここなさんが画面で示すネット上のコピーは、パソコンの外に出たものです。記事を作らせるフォルダでも、手元にコピーが増えただけなら保存先は同じです。

7個のzipは保存されていましたが、クラウドには届いていませんでした。保存したことと、別の場所へ届いたことは別です。

GitHubとは、何を残すサービスなのか。ここなさんの説明は、プログラムの保存や共有という始まりから、AIに書き直してもらうフォルダーへ進みます。完成したファイルを置くことに加えて、途中の変更も残す使い方です。

ここなさんは、もとはエンジニアがプログラムを保存し共有するサービスだと説明します。今はアカウントを作れば使え、AIとも相性がよいとの話です（1:30）。

ここなさん（動画の中で・1:51〜）

どんなサービスなのかなんですけど、簡単に言うとインターネット上にある変更記録[つき]の作業フォルダー置場みたいなイメージです。

動画ではGoogleドライブやiCloudを完成品の倉庫にたとえます。GitHubでは、書き直すフォルダーを変更内容と一緒に残すという説明です。

ゲームのセーブポイントにもたとえています。機械の故障やAIの書き換えに対し、「昨日の状態に戻して」と頼めると話します（2:49）。

ここなさん（動画の中で・3:12〜）

クロードコードを自分のパソコンで使うだけなら[GitHub]がなくても使えます。なので今回解説する[GitHub]は使うために必須のものっていうよりも作ってきたものを守るために保険として使うものと思っておいてください。

指示書を毎週書き直す日には、完成した1枚に加えて、書き直す前の姿も意味を持ちます。倉庫との違いは、戻れる場所を残す点にあります。

指示書の長さを変えた日も、変更前後を並べれば違いが見えます。長さの目安はCLAUDE.mdの目安を扱った記事に書きました。

指示書やルールを入れた私の置き場です。スキルも入れています。2026年7月3日12時31分に初めてGitで管理しました。

会話ログと認証情報は対象外です。その置き場には、キャッシュや大きな実行ファイルも最初から含めない方針を書いています。

私は、ここなさんの「保険」という捉え方に賛成します。毎週書き直す指示書では、完成品の保管に加えて、変更前へ戻れることにも意味があるからです。

動画では、Claude Codeを自分のパソコンで使う場合、GitHubは必須ではないと説明しています。作ったものがない日と、指示書が蓄積した日では守る対象が違います。

動画の倉庫の図は、完成品をそのまま保管する役割です。毎週書き直す手順書には、途中の姿も残す役割が要ります。GitHubは変更の記録つきで残すサービスです。

画面の図では、手元への記録とネット上への保存が分かれています。コミットだけならパソコンの中で、プッシュ後はGitHubにも保存された状態です。ここなさんは、この違いを説明しながら、作業で使う言葉を順に示します。

ここなさんはGitを手元のセーブ機能、GitHubをネット上の保存庫と説明します。手元で記録したあとに、外へ預けるという関係です（3:34）。

動画で示す言葉は、リポジトリ・コミット・プッシュ・プル・クローンです。リポジトリは作業フォルダー1つ分の入れ物です。

コミットは区切りの時点を手元へ記録する操作、プッシュはGitHubへ送る操作との説明です。送るのは区切りごと、または1日の終わりです。

ここなさん（動画の中で・6:32〜）

ここが今回かなり大事なポイントなんですけど、コミットしただけだとその記録はまだパソコンの中にしかないんですよね。つまりこの状態でパソコンが壊れたら記録ごと消えてしまいます。

まとめの図で、プルは新しい内容を手元へ取り込む操作です。クローンはGitHubのものを丸ごと手元にコピーする操作と整理します（9:33）。

ここなさん（動画の中で・9:55〜）

実際の作業はクロードコードにコミットしてプッシュしてプルしてってこうお願いすれば代わりにやってくれます。なので大事なのは今自分が何をお願いしているのかっていうのをちゃんと分かっておくことなんですよね。

ここなさんの図は、手元だけの記録とGitHubにもある記録を分けています。GitHubのバックアップでは、この違いが大事です。コミットしただけで安心せず、届いたところまで確かめます。

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

同じ日の12時37分、AIが毎日自動で行う保存作業が作ったコミットに、AIの作業で自動的にできた補助ファイルが19,940個入りました。そのうち1個は約207MBでした。

GitHubの1ファイル100MBの上限を超え、送信は断られました。10月12日21時37分の最後の試みまで、失敗が74回続いています。

いまGitHub側は、手元より423コミット遅れています。

指示書やスキルを入れた別の置き場も、手元のコミット209件のうち207件はGitHubに届かず、GitHub側の最後のコミットは8月6日です。

私の軸は「信頼できる仕組みが先」です。毎週増える記事のフォルダでも、預けたつもりで終えず、届いたかを確かめる仕組みを先に置きます。私は届いた日付を基準にします。

ここなさんは10:02ごろ、自分が何を頼んでいるか分かっておくことが大事だと話します。私はそこに、頼んだ結果がどこまで届いたかを見ることを足します。

架空の料理チャンネルの台本フォルダーを使い、GitHubへ預ける前の設定をここなさんが実演します。台本を送る前に、何を外へ出すかを決める順番です。

アカウント作成の画面で、ここなさんはユーザー名がURLになり、他の人にも見えると説明します。フルネームや会社名を避けるよう案内します。

ここなさんはメールを非公開にするよう案内します。オフなら記録にメールが残る場合があり、Claude Codeからのコミットには別の設定も必要です。

リポジトリ作成では、最初のPublicは誰でも中身が見られる状態と説明します。画面でPrivateに切り替えるよう示します（12:10）。

秘密の鍵やパスワードを含むファイルは、預ける対象から外すよう案内しています。.gitignoreは、預けないファイルを指定する設定ファイルです。

ここなさん（動画の中で・14:53〜）

一度[GitHub]に上げてしまうと後からファイルを消しても記録の方に残ってしまうので必ず最初にプッシュをする前にやっておいてください。

動画のメール非公開とPrivateの画面は、送る前の設定です。対象から外すファイルも先に決めます。過去の記録へ残さない準備は、最初に預ける前に必要です。

取引先の名前が入った資料を置くフォルダでは、公開範囲が関わります。APIキーを置いたフォルダなら、そのファイルを送る対象から外す判断も要ります。

私の環境では、AIのpushやプルリクエストの作成も、最後の実行の直前で止まります。私に聞きます。プルリクエストは、変更の取り込みを求める操作です。

mainへの取り込みや履歴の書き換えも、私に聞いてから実行する決まりです。mainは中心の保存先で、ブランチや作業フォルダの削除にも同じ決まりがあります。

設定の側にも、強制pushを止める指定があります。reset –hardやcleanという変更やファイルを消す操作も含め、止める指定は7件です。

台本を一度GitHubへ上げると、消しても記録に残るとここなさんは説明します。私の「取り消せない操作は実行前に止める」決まりとは別の話ですが、どちらも送る前に線を決めておく点は同じです。

取り消せない操作は実行前に止めます。この線を、GitHubをAIに触らせる前に鍵と権限を絞る設定の記事にも書きました。

ここなさんは、準備だけを頼み、指示するまでコミットやプッシュをしないようClaude Codeへ伝えます（13:22）。任せる範囲を最初に区切っています。

料理チャンネルの実演では、準備する操作があります。台本を送る操作とは別です。安全設定は、AIに送信を頼む前に決めておく順番です。

15:31ごろの画面で、コミット直後のGitHubは空です。ここから指示書の全面的な書き直しの実演が始まります。

ここなさんの実演では、コミット直後のGitHubは空です（15:31ごろ）。プッシュすると同じファイルが並びます（15:52ごろ）。

指示書を全面的に書き直す実演です（16:13）。ここなさんは、AIに変更箇所の説明を頼むと、個別に教えてくれると話します。

ここなさん（動画の中で・16:29〜）

ここでやっぱり前の方が良かったなって思ったらさっきのコミットの状態に戻してってお願いするだけで[書き換える]前の状態に戻せます。

ここなさんが示す変更画面は、削除が赤、追加が緑です（16:44）。直前だけでなく、3日前の状態にも戻せます（16:56）。

空のフォルダーでクローンします（17:03）。ここなさんの実演では、ファイルに加えて、コミットの記録まで全部そろいます。

16:13の「どこを変えたか見せて」というここなさんの頼み方に、私は賛成します。全面的な書き直しでも、変更箇所ごとに確かめる入口になるからです。

毎週の記事を作らせる指示書。AIに全面改稿を頼む日は、読みやすさに加えて、記事に必要な条件が残っているかも大切になります。

2026年9月14日、AIに頼んで共通スキル（AIに渡す手順書）の説明文の書き直し案を98件作ってもらい、97件を適用しました。全体の控え約1.3GBと、戻し用のタグを残しました。

この書き直し後の事故は3件です。保護しているファイルに案が混ざり、スキルの説明が空になったほか、別のスキルには別の語が混ざりました。

9月14日の書き直し後は、AIに頼んで承認済みの版や変更前のコピーから戻しました。混ざった語を取り除いて直しました。

戻し用のタグは手元にだけあります。GitHubのタグ一覧には、まだありません。変更前へ戻るための指定も、送信先には届いていない状態です。

戻る場所がパソコンの中だけなら、パソコンと一緒に消えます。ここなさんの6:32の説明と、保存されている場所の話がつながります。

毎週使う指示書の全面改稿では、変更前のコミットとプッシュまでが1組です。戻したい状態を手元に残し、GitHubへ届けるところまで含みます。

19:45から、GitHubを使う上での注意点の話に入ります。ここなさんが挙げるのは、会話の保存範囲や大容量ファイルなどの3か所です。

会話は別の場所にあると、ここなさんは説明します（20:02）。決定事項をメモにしてコミットとプッシュを頼む方法です（20:31）。

ここなさん（動画の中で・20:10〜）

実はクロードコードとの会話の記録って作業フォルダーとは別の場所に保存されてるんです。なので作業フォルダーを[GitHub]に預けても会話の記録までは一緒に守れません。

ここなさんは、.gitignoreで除外したファイルも戻らないと説明します（20:45）。鍵やパスワードは別の場所に保管します。

1ファイル100MB超は受け付けないとの説明です（21:13）。ここなさんは、動画や大きい画像をGoogleドライブへ分けます。

ここなさん（動画の中で・21:19〜）

例えば私は完成したYouTube動画も保管しているんですけど動画はすぐに100MBを超えてしまうので[GitHub]に保存することができないんですよね。

他人の公開ツールをクローンする時も注意点です（21:44）。悪いプログラムが含まれる場合があると、ここなさんは話します。

作った人の確認を、ここなさんは勧めます（22:16）。スター数は安全の保証ではなく、中身が不明なら動かさずAIにも読み込ませません。

注意点を示した画面の3か所には、保存されない会話や受け付けない大容量が含まれます。公開ツールの中身も含みます。預けた範囲の外の話です。

私のMacでは、Claude Codeとの会話の記録は専用のフォルダにあります。容量は8.2GBです。フォルダは222あります。

指示書やルールの控えがGitHubへ最後に届いたのは、10月12日18時37分です。ところが会話の記録は、対象に1件も入っていません。

指示やルールを入れた私の置き場には、会話ログを最初から対象に入れない方針があります。会話の記録を追跡している件数は0件です。

第3章で見たとおり、約207MBの1ファイルが100MBの上限で断られた件は、この落とし穴の実例です。

鍵やパスワードは、GitHubではなく別の保管先に置く話です。その考え方は1Passwordでパスワードを見せない方法の記事に書きました。

公開ツールの人気一覧を見る前に、作った人を確かめます。人気の一覧の読み方はGitHub週間ランキングを扱った記事で扱いました。

人気の一覧に並ぶツールでも、中身が分からなければ、そのまま使う判断には進めません。AIへ読み込ませる指示書にも、この確認が関わります。

第7章では、預けた範囲の外を自分の目で一覧にします。作業フォルダーの名前だけで判断せず、含まれるファイルまで見える形にする点検です。

23:16の宿題は、AIの作業フォルダーを1つ選び、非公開の保存先へ送ることです。送信前に、現在の保存状態を読む15分を置きます。

ここなさんの宿題です（23:16）。いま使うAIの作業フォルダーを1つ選び、非公開のリポジトリへプッシュしてほしいと話します。

ここなさん（動画の中で・23:25〜）

何ヶ月もかけて育てた指示書や[ナレッジ]がいきなり消えてしまう前に今日のうちに1回だけでもプッシュしておいてください。それだけでも少しは安心できますからね。

23:25の発言を受けた宿題は、何か月も育てた指示書やナレッジが消える前にプッシュすることです。今日のうちに1回です。

今週、AIに記事を作らせたフォルダー。指示書を書き直した日なら、その変更を含むフォルダーが、選ぶ対象になります。

そのフォルダーを送る前に、15分で点検します。保存先に届いた内容まで読むことで、宿題がやったつもりで終わらなくなります。

GitHubのバックアップでは、第3章で示した手元とGitHubの日付が合えば、届いたことを確認できます。合わなければ、点検を終えたあとにプッシュを1回頼む順です。

→ 届いた範囲を15分で確かめる

AI作業フォルダを1つ選び、15分で読む。①最後のコミットの日付を手元とGitHubで比較。②Private・メール非公開を確認し、鍵やパスワードを除外。③100MB超のファイルと会話記録の対象範囲を確認。3点を1行ずつ書けば完了。15分で3点が出なければ、分かった分だけ1行ずつ書いて止めます。途中でGitHub上を書き換えず、読むだけにします。

23:25、ここなさんは、何か月も育てた指示書やナレッジが消える前にプッシュしてほしいと結びます。今日のうちに1回だけです。

コミットだけなら、まだパソコンの中です。プッシュ後はGitHubにも保存される。ここなさんが示した図のこの違いが、動画の芯でした。

私の軸は「信頼できる仕組みが先」です。作業フォルダーを預けたつもりで終えません。届いたかを確かめる仕組みを先に置きます。

第7章の点検で見るのは、保存した回数より、保存先に届いている内容です。あなたのAI作業フォルダーは、いまどこまでGitHubに届いていますか。