「最終版」「修正版」「本当に最終版」「最終版_v3」のようなファイル名が、社内フォルダの中にいくつも並んでいないでしょうか。
見積書、提案書、社内マニュアル、チラシ原稿、ホームページの文章などを、担当者ごとにコピーして直していくうちに、次のような状態になりがちです。
- ☹どれが最新版なのか分からない
- ☹前に戻したいのに、どの時点のファイルを開けばいいか分からない
- ☹誰がどこを直したのか、あとから説明できない
- ☹似た名前のファイルが増えすぎて、確認だけで時間がかかる
- ☹古い資料を間違えて送ってしまいそうで不安になる
岐阜の中小企業でも、こうした「フォルダがぐちゃぐちゃになる問題」はかなり身近です。
これまでは、少し不便でも何とか回っていました。
しかも、ChatGPTなどの生成AIを使って文章や資料をまとめるようになると、この問題はさらに起きやすくなります。
AIに修正案を出してもらう。別案を作ってもらう。複数の資料を一気に整理してもらう。
便利になる一方で、作業後のフォルダには、似た名前のファイルや途中版の資料が増えがちです。
AI時代に必要になるのは、ファイル単体の管理ではなく、フォルダ全体を安全に戻せる管理です。
この記事では、非エンジニア向けにGitとGitHubの考え方を紹介した動画内容をもとに、まずは難しい専門用語ではなく、「AI時代にフォルダをどう管理すればよいか」という視点で解説します。
AIを使うほど「フォルダごと管理」が必要になる

GoogleドキュメントやWordには、1つのファイルの変更履歴を戻す機能があります。
1つの文書だけを直しているなら、それで十分な場面もあります。
問題は、AIに仕事を任せる範囲が広がったときです。
たとえば、AIに文章作成や資料整理を頼むようになると、次のような困りごとが起きやすくなります。
- ›AIが直した後に、元の文章がどこにあるか分からなくなる
- ›別案をいくつも作った結果、どれを採用するのか決められなくなる
- ›資料、画像、メモ、設定ファイルが同時に増えて、フォルダ全体が散らかる
- ›間違った指示を出したあと、作業前の状態に戻せなくなる
- ›複数人で触っているうちに、誰の修正が最新なのか分からなくなる
このような作業では、1つのファイルだけでなく、複数の文書、画像、メモ、設定ファイル、参考資料が同時に動きます。
AIに指示を出すたびに、フォルダの中身が大きく変わることもあります。
そのときに困るのが、「さっきの状態に戻したい」という場面です。
AIに作業を任せる会社ほど、作業前の状態をフォルダごと残しておく仕組みが必要になります。
解決の考え方は「フォルダ全体の変更履歴」を残すこと

ここで役に立つのが、フォルダ全体の変更履歴を残すという考え方です。
その代表的な仕組みがGitです。
Gitは、もともとプログラマーが使ってきた変更管理の仕組みです。
ただし、考え方そのものはコード専用ではありません。
簡単に言えば、Gitはフォルダ全体の履歴を残す仕組みです。
文章ファイル、画像、メモ、設定ファイルなどをまとめて、「この時点の状態」として記録できます。
Googleドキュメントの変更履歴を、1つの文書ではなくフォルダ全体に広げたものと考えると分かりやすいです。
Gitを使うと、ファイル名を何度もコピーして増やさなくても、過去の状態を後から確認できます。
たとえば、ホームページ改善の作業で次のような流れがあったとします。
- ›7月1日:現在のホームページ文章を保存
- ›7月3日:AIでサービス説明文を修正
- ›7月5日:料金表とFAQを追加
- ›7月8日:問い合わせ導線を変更
このように区切りごとに記録しておけば、「7月3日の状態に戻したい」「7月5日の変更だけ確認したい」といった見直しがしやすくなります。
GitHubは「履歴を見える化して共有する場所」

GitとGitHubは、似た言葉ですが同じものではありません。
Gitは、変更履歴を記録する仕組みです。
GitHubは、そのGitをWeb上で共有・確認しやすくするサービスです。
中小企業の業務に置き換えるなら、Gitは「履歴を残すルール」、GitHubは「履歴を見たり共有したりする場所」と考えるとよいです。
エンジニア向けの印象が強いサービスですが、今後は文章作成、資料管理、AI活用の現場でも知っておく価値があります。
GitHubは、コードを書く人だけの場所ではなく、複数人で成果物を安全に育てるための作業場所になりつつあります。
フォルダ管理で知っておくと便利な5つの言葉

GitやGitHubには専門用語があります。
最初から細かい操作を覚える必要はありませんが、次の5つの考え方だけ分かると全体像が見えやすくなります。
リポジトリ
リポジトリは、管理したいフォルダ一式のことです。
たとえば、社内マニュアルなら、本文、画像、目次メモ、更新履歴、参考資料をまとめた1つの作業フォルダです。
コミット
コミットは、作業のセーブポイントです。
「ここまでの状態を記録しておく」という意味です。
文章を大きく直す前、AIに一括修正を頼む前、公開前のチェックが終わった時点などでコミットしておくと、後から戻りやすくなります。
ブランチ
ブランチは、試作用の別ルートです。
今の状態を壊さずに、「別案を試す」「AIに大胆に書き換えさせる」「新しい構成を検討する」といった作業ができます。
うまくいけば本線に取り込み、うまくいかなければ捨てられるため、思い切った改善案を試しやすくなります。
メイン
メインは、現在の正式版に近い本線です。
会社の文書管理で言えば、「いま採用されている版」です。
メインを直接書き換えるのではなく、別のブランチで試してから取り込むと、変更の事故を減らせます。
プルリクエスト
プルリクエストは、「この変更を正式版に入れてよいですか」と確認する仕組みです。
担当者が修正案を出し、別の人が確認し、問題なければ本線に取り込む流れを作れます。
プルリクエストは、昔ながらの「原稿チェックお願いします」を、履歴とコメント付きで残せる仕組みです。
中小企業で役立つ場面

GitHubという名前を聞くと、システム開発の話に見えるかもしれません。
しかし、考え方は一般業務にも応用できます。
特に岐阜の中小企業で使いやすいのは、次のような場面です。
- ›ホームページの文章や画像指示を管理する
- ›社内マニュアルの更新履歴を残す
- ›チラシ、SNS投稿、メール文面を一式で管理する
- ›AIに作らせた資料の変更前後を確認する
- ›複数人で文章を直すときの衝突を減らす
たとえば、ホームページ改善では、トップページ、サービスページ、FAQ、問い合わせページ、画像指示、SEOメモなどが同時に動きます。
担当者が1人ならまだしも、外部の制作会社、社内担当者、経営者、AIツールが関わると、どれが最新版なのか分かりにくくなります。
このとき、変更履歴と確認の流れを残せる仕組みがあると、後から説明しやすくなります。
DXは新しいツールを入れることだけではなく、変更を安全に扱える仕事の進め方を作ることでもあります。
最初から難しい操作を覚える必要はない

GitやGitHubには、黒い画面でコマンドを打つイメージがあります。
しかし、最初からそこまで覚える必要はありません。
現在は、GitHub Desktopのような画面操作できるアプリもあります。
また、AI開発ツールやエディタの中には、自然な言葉で「変更を保存して」「差分を確認して」といった操作を補助してくれるものも増えています。
中小企業の担当者が最初にやるなら、次の順番で十分です。
- ›GitHubアカウントを作る
- ›非公開のリポジトリを1つ作る
- ›練習用の文章フォルダを入れてみる
- ›作業前と作業後でコミットしてみる
- ›慣れてきたらブランチで別案を試してみる
大切なのは、いきなり業務の重要データで試さないことです。
まずは練習用の文章や社内共有用のメモで、履歴が残る感覚をつかむ方が安全です。
最初の目的はGitHubを完璧に覚えることではなく、「変更前に戻れる仕事の進め方」を体験することです。
まとめ:AIを使う会社ほど、戻せる仕組みが必要になる
AIを使うと、文章作成や資料整理のスピードは上がります。
一方で、変更の量も増えます。
誰が、いつ、何を、どのように変えたのか分からないまま進めると、便利なはずのAI活用が社内の混乱につながることもあります。
だからこそ、これからの中小企業には、AIツールそのものだけでなく、AIが変えた内容を安全に管理する考え方が必要です。
GitとGitHubは、エンジニアだけの専門道具ではなく、AI時代の文書管理・資料管理にも役立つ基礎知識です。
まずは「最終版ファイルを増やして管理する」状態から抜け出し、フォルダ全体の変更を残す発想を持つことが第一歩です。
岐阜の中小企業でも、小さな社内マニュアルやホームページ文章から始めれば、AI時代に合ったDXの土台を作れます。
GitHubの基本的な使い方を社内で学びたい、出張またはオンラインで説明してほしい、最初のアカウント作成やフォルダ管理の設定を手伝ってほしいという場合は、初期設定や使い方のレクチャーも対応できます。




