- ▶ Part 1/5 GitHubとは何か（本記事）
- Part 2/5 アカウント作成と最初のリポジトリ
- Part 3/5 編集・履歴・チーム共有
- Part 4/5 AI用コンテキストをGitHubで管理する実践
- Part 5/5 組織導入と運用
- GitHubが何のために生まれ、なぜ今、開発以外の業務でも必要になっているかを説明できる
- 「リポジトリ」「コミット」「ブランチ」という3つの言葉のイメージが頭に入る
- 自社で GitHub を導入すべきかどうかを判断する材料を得る
本記事は読み物中心で、実際の操作はありません。手を動かす Part 2 以降への準備編です。
「GitHub」という言葉を、ここ1〜2年で、開発職以外の人からも耳にするようになりました。経理担当が「ChatGPTのプロンプトをGitHubで管理したい」と言い出したり、総務が「社内マニュアルをGitHubに置きたい」と相談してきたり、経営者から「うちもGitHub導入したほうがいい？」と聞かれたり。
本シリーズは、こうした変化の中で GitHubに触れたことがないビジネスサイドの方を対象に、5回に分けて「GitHubとは何か」「どう使うか」「なぜ今 重要か」「社内導入をどう進めるか」を順を追って解説していきます。コードを書きません。プログラマーでなくても理解でき、最終的には自分の業務にGitHubを組み込めるところまで持っていくのが目標です。
第1回の本記事は、すべての入り口となる「GitHubとは何か」です。歴史・基本概念・AI時代の位置付けを、図と例えだけで理解できるように整理します。
GitHubは「ファイルの保存先」ではなく、「変更履歴と、その変更にまつわる会話の保存先」です。Dropbox や Google Drive との一番大きな違いはここにあります。誰がいつ、なぜそのファイルをそう変えたのか──その「経緯」が残ることが、AI時代に効いてきます。
GitHubはひとことで言うと何か
GitHubをひとことで説明するなら、「ファイルの変更履歴と、その変更にまつわるチームの会話を一緒に保管する場所」です。
身近なものに例えるなら、Wordの「変更履歴」機能と、メールやSlackの「やりとり」を1つにまとめた書庫のようなイメージ。誰かがファイルを直したら、いつ・誰が・何を・なぜ直したかが自動で記録され、それに対して別のメンバーが「ここはこう直したほうがいい」とコメントを残せる。そしてそのコメントも全部、そのファイルと一緒に保管される──これが GitHub の本質です。
もともとはソフトウェア開発者が「コードの修正履歴」を扱うために作られたサービスですが、ファイルの中身は別にコードである必要はありません。テキスト・Markdown・Excel・PDF・画像──何でも置けます。ただし、変更履歴の差分が見やすいのは「テキスト形式」のファイルです（後述）。
GitHubが生まれた歴史──Linus、Git、そしてOctocat
GitHubの背景を理解するために、ごく短く歴史を振り返ります。年表で覚える必要はありませんが、「なぜわざわざ Git というツールが生まれたのか」を知ると、その後の使い方の理解が早くなります。
| 年 | 出来事 |
|---|---|
| 2005年 | Linus Torvalds（Linuxの作者）が、Linuxの開発で使っていた商用バージョン管理ツールが使えなくなり、自分たちで Git という変更履歴管理ツールを開発 |
| 2008年 | Tom Preston-Werner ら3名がサンフランシスコで GitHub.com を立ち上げ。Gitを使ったオープンソース開発のハブとして急成長 |
| 2018年 | Microsoftが GitHub を 75億ドルで買収。「マイクロソフトがOSSの中心に出資する」という象徴的な出来事 |
| 2022年 | GitHub Copilot 一般提供開始。AI がコードを補完する時代へ |
| 2024〜2026年 | Copilot の対象が「コード」から「全業務テキスト」「AIエージェント基盤」へ拡張。非エンジニアにとっても無視できない存在に |
注目すべきは2018年以降です。Microsoft 傘下になってから GitHub は急速に「開発者だけの場所」ではなくなり、「組織のあらゆる知識を蓄積する基盤」へと役割を広げています。Copilotが2022年に来て、2025年以降はAIエージェントの記憶（コンテキスト）の保管先としての価値が一気に高まりました。本シリーズが扱うのは、まさにこの「新しい使い方」の領域です。
ちなみにGitHubのマスコット「Octocat（オクトキャット）」はタコと猫を合体させたキャラクターで、ロゴとしてあちこちで見かけます。社内ドキュメントで急に出てきても驚かないようにしておいてください。
3つのキーワード──リポジトリ・コミット・ブランチ
GitHubを使うときに必ず登場する3つの言葉があります。最初はピンとこなくても大丈夫ですが、本シリーズの後半で何度も出てくるので、ここで「ふんわりイメージ」を作っておきます。
リポジトリ（Repository）
リポジトリは、「ある目的のためのファイル一式」を入れる箱です。プロジェクトごと、目的ごとに1つ作るのが普通です。
例えば「営業マニュアル」「経理規程」「ChatGPT用のプロンプト集」「商品データベース」──こうしたまとまり1つにつき、1つのリポジトリを作ります。社内の共有フォルダで言うと「フォルダ1つ」に近い概念ですが、後述する 変更履歴 がついてくる点が決定的に違います。
コミット（Commit）
コミットは、「ファイルを変更した、その瞬間のスナップショット」です。Wordの「保存」に近いですが、ただ保存するだけでなく、必ず「何を変えたか」のメモを一緒に残します。
例えば「営業マニュアルの3章にFAQを追加」「経費精算のフォーマットを修正」のような短いメッセージを添える、というイメージです。これが何百回・何千回と積み重なって、「いつ・誰が・なぜ」を辿れる時系列の記録になります。1ヶ月前のバージョンに戻したいときも、2年前の議事録の状態を確認したいときも、コミット履歴を辿れば一発です。
ブランチ（Branch）
ブランチは、「本筋とは別に、ちょっと試してみる作業場」のようなものです。木の枝（branch）から発想された概念で、本流（main）から分岐して、自分だけの作業空間で安心していじり倒し、上手くいったら本流にマージ（合流）させる、という流れになります。
「経理規程の改訂版」を、本物にいきなり手を入れずに、まずブランチで試して、社内レビューしてから本物に反映する──こうした業務でも自然に使えます。最初のうちは触らなくても良い概念ですが、複数人で同時に編集する段階で必須になります。
3つの関係を一行でまとめると、「リポジトリ（箱）の中で、ブランチ（並行作業場）を分けて、コミット（修正の痕跡）を積んでいく」ということになります。
Dropbox／Google Driveとの違い
ここまで読むと「Google Drive と何が違うの？」と思う方が多いはずです。両者は確かに「ファイルを置く場所」という点で似ています。違いを正確に言語化すると、次の表のようになります。
| 観点 | Google Drive ／ Dropbox | GitHub |
|---|---|---|
| 得意な対象 | WordやExcel、画像、動画など「完成形」のドキュメント | テキスト系（Markdown、コード、CSV）など「作り込みの差分が重要」なファイル |
| 履歴の質 | 「何時何分に上書き保存された」程度 | 「誰が・なぜ・どう変えたか」がメッセージ付きで残る |
| 同時編集 | 同じファイルを複数人で同時に上書きできる（リアルタイム） | 本流とは別ブランチで並行作業し、合流時に差分をレビュー |
| レビュー文化 | コメント機能はあるがレビューには弱い | 変更単位でレビューを依頼・指摘・承認する仕組みが標準装備 |
| AIとの相性 | ファイルを渡せるが、変更履歴はAIに見えにくい | 履歴と意図がそのままAIへの「文脈」になる |
つまり、両者は競合ではなく役割分担です。プレゼン資料・契約書・写真ライブラリは Google Drive、社内ナレッジ（マニュアル・規程・FAQ・AIプロンプト集）は GitHub、というふうに使い分けるのが2026年時点の現実解です。
なぜ今、非エンジニアにもGitHubが必要なのか（AIとの関係）
本シリーズが「非エンジニア向け」を強調する背景にある最大の変化が、生成AIの業務利用です。
2025年以降、ChatGPT・Claude・Gemini・Microsoft Copilot を業務に取り入れる企業が一気に増えました。これらのAIに「いい仕事」をさせるためには、社員それぞれが持つ業務文脈──通称コンテキスト──を、AI が読み込める形で揃える必要があります。具体的には次のような情報です。
- 自社の用語集（顧客がA社、製品名がB、部門名がC……）
- 業務ルール（締切は月末、承認は部長以上、文体は丁寧体……）
- 定型タスクの手順書（議事録の整え方、提案書の構成、メールテンプレ……）
- 過去の意思決定の記録（なぜ取引先を絞ったのか、なぜそのKPIにしたのか……）
こうした情報を、AIにその場で毎回コピペで貼るのは現実的ではありません。1箇所にまとめて、AIから自動参照できる仕組みが必要になります。これに最もフィットする保管庫が GitHub なのです。
具体的には、Claude Code には CLAUDE.md、Cursor には .cursorrules、ChatGPT のカスタムGPTにはアップロードされたファイル群──といった「AIに渡すコンテキストファイル」をどこかに集約・更新・共有する必要があり、その置き場としてGitHubが事実上の標準になっています。GitHub の上に置けば、社員全員が同じバージョンを参照でき、変更履歴も追え、誰がそのルールを書いたかも分かります。
2026年現在、生成AIを「個人の使い倒し」から「組織の資産」へ昇格させたい会社は、ほぼ例外なく GitHub にコンテキストを集める 設計に行き着きます。これは AI ベンダーが特定のクラウドサービスに依存しないニュートラルな置き場として、Git／GitHub を選んでいるためです。
言い換えると、GitHub を社内に整備していない組織は、生成AIの組織化フェーズで一段階遅れるということです。本シリーズの後半、Part 4 ではこの「AI用コンテキスト管理」の実装を、Part 5 では組織として運用する設計を扱います。
GitHubで「できること」非エンジニア視点の10例
イメージを具体化するために、本シリーズで扱うレベル感の「非エンジニアによる GitHub 活用」事例を10個並べます。Part 2以降で実際にやり方を学んでいきます。
- 社内ナレッジベース：マニュアル・規程・FAQ をリポジトリに集約。バージョン管理付きで全社員が参照
- AIプロンプト集：ChatGPT／Claude に投げる定型プロンプトを、部門別・用途別に整理して再利用
- 議事録アーカイブ：会議の議事録をMarkdownで残し、検索・引用しやすい形に
- 社内用語集：略語・専門用語・お客様の呼称を集めた辞書を1つのリポジトリで運用
- 提案書テンプレート集：業界別・案件規模別の提案書ひな形をブランチで管理
- 新人オンボーディング資料：入社時に渡すドキュメント群を、毎年の更新履歴付きで保管
- 意思決定ログ：「なぜその選択をしたか」を残すADR（Architecture Decision Record）の業務版
- 競合・市場調査メモ：定期的に更新する業界レポートをGitHub上で共同編集
- コーディング用CLAUDE.md（開発組織向け）：本シリーズ Part 4 で扱うAI開発支援用コンテキスト
- 採用候補者の評価メモ：採用フローの中で蓄積する評価記録（Private リポジトリで権限制御）
10個のうちプログラミングが必要なものは、ありません。すべて 「テキストを書いて、保存して、共有する」 という日常作業の延長で実現できます。
参考リンク（さらに深掘りしたい人へ）
- GitHub 公式入門ドキュメント──全機能の網羅的入口
- The History of GitHub（GitHub Blog）──創業から現在までのストーリー（英語）
- Pro Git Book（日本語訳）──Git の仕組みを基礎から学べる無料の名著
次に読むべき記事──Part 2 への橋渡し
第1回はここまでです。GitHubが生まれた背景、リポジトリ・コミット・ブランチの3つのキーワード、そしてAI時代に「組織のコンテキスト保管庫」として重要度が上がっている理由をお伝えしました。
次のPart 2/5「アカウント作成と最初のリポジトリ」では、いよいよ手を動かします。GitHubアカウントを作るところから、最初のリポジトリにファイルを保存するところまで、ブラウザだけで完結する操作を画面付きで解説します。1人で 30 分ほど集中すれば終わる内容です。
本シリーズは独立した5回ではなく、Part 1から順に読むことを前提に構成しています。同じ業務を扱う同僚と一緒に、毎週1本ずつ読み進めるくらいのペースが体得しやすいです。
本シリーズの全体像（再掲）
- Part 1（本記事）──GitHubとは何か（理論編）
- Part 2──アカウント作成と最初のリポジトリ（個人ハンズオン）
- Part 3──編集・履歴・チーム共有（チーム運用入門）
- Part 4──AI用コンテキストをGitHubで管理する実践（AI連携）
- Part 5──組織導入と運用（情シス・経営層向け）
本シリーズの内容をベースに、貴社の状況に合わせたカスタム研修を提供しています。「経理・総務・営業など非エンジニア部門にGitHubを展開したい」「AI時代に向けて社内コンテキストを整備したい」「情シス主導でGitHub Organization を立ち上げたい」──いずれのフェーズでも、現場で詰まりやすいポイントを先回りでサポートします。1日完結のワークショップから、3ヶ月の伴走プログラムまで対応可能です。
