GitHubって何？｜「確認お願いします」が仕組みになっている場所

「最終版_修正済み_本当の最終版.xlsx」——このファイル名に、心当たりはないでしょうか。どれが最新か分からない。誰がどこを変えたか分からない。上書きで消えた。ファイル管理のこの混沌を、世界中の開発者は30年かけて解決してきました。その到達点がGitHubです。

AIとものづくりを始めると必ず出会うこの道具を、今回は非エンジニア向けにかみ砕きます。

前回のおさらい: Gitは「全セーブポイントが残る」仕組み

前回書いたとおり、Git（ギット）はファイルの変更履歴をすべて記録し、いつでも過去のどの時点にも戻れるようにする仕組みでした。節目ごとのセーブポイント（コミット）が全部残るので、「最終版_本当の最終版」問題は原理的に起こりません。

GitHubは「そのセーブデータの共有広場」

GitHub（ギットハブ）は、Gitの記録をインターネット上で共有する場所です。チームの全員が同じ履歴を見ながら、それぞれの作業を持ち寄れます。

面白いのは、持ち寄り方に「作法」があることです。プルリクエストと呼ばれる仕組みで、変更をいきなり反映するのではなく、「ここをこう直しました。確認をお願いします」と提案の形で出し、レビューを受けてから合流させます。稟議や校閲に近い文化が、ソフトウェアの世界には最初から組み込まれているのです。

ここは組織づくりの観点から見ると、なかなか示唆的です。「誰が、何を、なぜ変えたか」と「誰が確認したか」が、業務の流れの中に自動的に記録される。 フィードバックが個人の心がけではなく、仕組みとして埋め込まれている状態です。

多くの職場では、レビューや相互確認は「気づいた人がやる」「余裕があればやる」の扱いになっています。だから忙しくなると真っ先に省かれる。省いた結果ミスが出て、また「確認を徹底しましょう」と言う。この繰り返しに心当たりのある方は多いと思います。通らないと先に進めない導線として設計されているかどうか——差はそこにあります。

いまご覧いただいている funwork.ohen-group.com のサイトも、GitHubに履歴が置かれていて、変更がGitHubに送られると自動で本番サイトに反映される仕組み（前回のデプロイの話の実例です）で動いています。

非エンジニアにも関係がある理由

「開発者の道具でしょう?」と思うかもしれません。しかしAI時代には、非エンジニアにこそ関係が出てきます。

第一に、AIの成果物の置き場所として。AIと作ったLPやツールをGitHubに置けば、履歴付きで安全に管理でき、あとから「あの時点に戻して」も自由自在です。

第二に、AIへの指示書の置き場所として。AIエージェントに読ませる業務ルールや手順書をGitHubで管理すると、チームの誰のAIも同じルールで動かせます。これは後日、コンテクストの共有というテーマで詳しく書きます。

第三に、引き継ぎの形として。担当者が変わったとき、引き継ぎ書を新しく書き起こすのではなく、日々の作業の履歴そのものが引き継ぎ資料になっている状態は、かなり強力です。「なぜこうなっているのか」を過去に遡って確認できるので、後任が前任に質問できないまま手探りで進める、ということが起きません。

最初の一歩

アカウントは無料で作れます。そして最初の練習も、AIに伴走させるのが近道です。「GitHubのアカウントを作ったので、この前作ったLPを履歴管理したい。手順を教えながら一緒にやって」——これで十分始まります。用語（リポジトリ＝作品ごとの保管箱、コミット＝セーブポイント、プッシュ＝共有広場への送信）は、使いながら覚えれば大丈夫です。

次回は少し寄り道して、Claude Code以外のAIツールたち（Codex・Cursor・Antigravity）を紹介します。

AI活用・社員研修のご相談はこちらからどうぞ。

この記事の要点

• Git＝全セーブポイントが残る記録の仕組み。「最終版_本当の最終版」問題が原理的に消える
• GitHub＝その記録をチームで共有する広場。「確認お願いします」（プルリクエスト）の作法が組み込まれている
• レビューが個人の心がけではなく、通らないと先に進めない導線として設計されている点が示唆的。忙しいと省かれる確認との差はここにある
• AI時代は非エンジニアにも有用: AIの成果物の置き場所、AIへの指示書・業務ルールの共有場所、そして日々の履歴がそのまま引き継ぎ資料になる
• 最初の一歩はAIに伴走させて。用語は使いながら覚えればよい