AIハッカソンに参加するようになって、よく使うようになったものがある。
GitHub（ギットハブ）。
実は、GitHubという名前自体は、ずっと前から知っていた。
もう11年くらい前かな。
当時、Webデザインを勉強していて、HTMLやCSSを覚え、その次くらいにjQueryにも触れていた。
そのとき、GitHubで公開されている無料のコードをダウンロードして、自分のWebサイトに組み込んで使ったことがある。
どこから、誰のコードをダウンロードしていたのか、今はもう覚えていない。
でも、「Feel free to use!」みたいに、自由に使っていいよと書いてあるものが多かった記憶がある。
えっ、こんな便利なものを無料で使わせてくれるの！？
なんて優しいんだろう。
当時はそんなふうに驚いていた。
中には「Buy me a beer」なんて書いている人もいた。
自由に使っていいけど、気に入ったらビールでもおごってね、という感じ。
なるほど、面白い！（笑）
GitHubからダウンロードしたコードで、Webサイトが動き出す！
当時、特に好きだったのが写真のスライダー。
画像が動いて切り替わるだけで、Webサイトの印象がガラッと変わる。
ダイナミックで、すごくインパクトがあった。
これが一番楽しかったな。
ほかにも、クリックすると選択肢が出てきて、その中から好きなものを選んで次に進める仕組みも使っていた。
あとは、今でも印象に残っているものが一つ。
いろいろな写真が、ランダムに重なり合って配置されているギャラリーみたいなもの。
普通だったら、写真をきれいに並べて、そこから選んでもらうよね。
でも、それはわざと写真をバラバラに配置して、クリックして選べるようになっていた。
そのデザインが面白くて、ダウンロードして自分のWebサイトにも使ってみた。
そういうパーツを組み合わせて、いろいろなWebサイトを作っていた。
ちなみに、今同じことをやってと言われても、もうやり方を覚えていない！ できない！（笑）
当時の私にとって、GitHubは、誰かが作ってくれた便利で面白いものを使わせてもらう場所だったんだ。
それから何年も経って、最近Claude Codeを使い始めた。
AIに手伝ってもらいながら、自分の仕事で使うアプリなどを作るようになり、GitHubのアカウントも作成した。
そして、初めて参加するAIハッカソンの案内を見たとき。
GitHubのアカウントを持っていることが、参加条件になっていた。
あっ、作っておいてよかった！
でも、このときの私は、GitHubがチーム開発でどう使われるのか、まだよく分かっていなかった。
実際に参加してみて、初めて知ることになったんだ。
今回は、そんな非エンジニアの私の経験と一緒に、GitHubの基本を整理してみるよ。
GitHubって、そもそも何？
GitHubは、プログラムのコードや関連ファイルを保存・管理して、ほかの人と共有したり、一緒に開発したりできるサービス。
例えば、複数人で一つのアプリを作る場合。
それぞれが自分のパソコンで作業して、変更したファイルを相手にメールで送り合っていたら、管理が大変そう。
どれが最新なの？
誰がどこを変更したの？
前の状態に戻したいときは？
GitHubを使うと、こうした変更を記録しながら、チームで作業を進めやすくなる。
公開されているプロジェクトなら、ほかの人が作ったコードを見ることもできる。
一方、非公開のプロジェクトを作って、許可されたメンバーだけで共同作業することもできる。
なるほど。
約11年前、私は公開されているコードを使う側だった。
今は、自分でもコードを管理したり、チームで開発したりする側になっているんだね。
GitとGitHubって違うの？
ここも最初は少しややこしい。
Git（ギット）とGitHub（ギットハブ）は、同じものではない。
Gitは、ファイルの変更履歴を管理するための仕組み。
いつ、どんな変更をしたのかを記録して、以前の状態と比較したり、必要に応じて戻したりできる。
これを「バージョン管理」という。
一方、GitHubは、そのGitで管理しているプロジェクトをオンラインで共有し、共同開発しやすくするサービス。
ざっくり整理すると、こんな感じ。
| 名前 | 役割 |
|---|---|
| Git | ファイルの変更履歴を管理する仕組み |
| GitHub | Gitで管理したプロジェクトを保存・共有し、共同開発できるサービス |
GitはGitHubがなくても使える。
でも、離れた場所にいる人たちと一緒に開発するときには、GitHubのようなサービスが便利なんだね。
初めてのAIハッカソンで、GitHubを共同利用した
私が初めてAIハッカソンに参加したとき、チームで一つのプロジェクトを作った。
そのとき、チームメンバーがGitHubにリポジトリを用意してくれた。
リポジトリ（Repository）とは、プロジェクトのファイルや変更履歴をまとめて管理する場所のこと。
そこで、メンバーと一緒に作業を進めた。
といっても、私が主に担当したのは、READMEの完成を手伝うこと。
README（リードミー）は、プロジェクトの概要や使い方、セットアップ方法などを説明するファイル。
GitHubでは、README.mdという名前で置かれていることが多い。
プロジェクトを初めて見る人が、「これは何をするもの？」「どうやって使うの？」と理解するための大切な説明書みたいな存在。
私が手伝ったのは、そうした部分だった。
しかも、そのAIハッカソンでは、GitHub上の成果物が一次審査の対象になっていた。
だから、READMEは超重要！
プログラムの中心部分を書いていたわけではない。
でも、ここで初めて実感した。
GitHubって、みんなで同じプロジェクトを共有しながら作業する場所なんだ！
11年前に無料のコードをダウンロードしていた頃とは、まったく違う使い方だった。
4回目のAIハッカソンでは、自分専用のブランチが！
そして現在。
私は4回目のAIハッカソン、Vietnam Japan AI Hackathon 2026に参加している。
今回は、ベトナム人のAIエンジニアと2人のチーム。
Amazonセラー向けのAIエージェント「FrostLoop AI」を作っている。
先日、チームメンバーがGitHubに招待してくれた。
しかも、私専用のブランチまで用意してくれたんだ。
ブランチ（Branch）って何？
簡単に言うと、プロジェクトの開発作業を分けるための仕組み。
例えば、チームの基準になるコードをmainというブランチで管理しているとする。
そこから、自分の作業用ブランチを作れば、まずはそのブランチで変更を進められる。
完成したら、内容を確認して、必要な変更をmainに取り込む。
こうすれば、全員が最初から同じ場所を直接編集するよりも、安全に共同開発しやすくなる。
なるほど。だから自分専用のブランチを作ってくれたんだね。
ただし、実は私、まだそのブランチで本格的な作業をしていない。
中身は見たけれど、今のところ、それ以外の作業は主に自分のMacのローカル環境で進めている。
色やフォントに関するCSSの変更は、すでにチーム側にも反映されたようだけれど。
なぜ慎重になっているかというと……。
間違って、チームメンバーが作ったものを壊したくないから！
せっかく作ってくれたプログラムに、私の操作で問題を起こしたら困る。
だから、ある程度ローカルで形にしてから、GitHubでの作業に進もうと考えている。
チームメンバーは、作業のためのMarkdownファイルも共有してくれた。
こういうルールを確認しながら進めるのも、共同開発の大事な部分なんだと思う。
GitHubでよく出てくる言葉を整理してみた
GitHubを使い始めると、知らない言葉が次々に出てくる。
私もまだ勉強中だけれど、まずは代表的なものを整理してみよう。
| 用語 | 初心者向けの意味 |
|---|---|
| Repository（リポジトリ） | プロジェクトのファイルと変更履歴を管理する場所 |
| Branch（ブランチ） | 作業を分けて進めるための仕組み |
| Commit（コミット） | 変更内容を履歴として記録すること |
| Push（プッシュ） | ローカルのコミットをGitHubなどのリモートに送ること |
| Pull（プル） | リモート側の変更を手元に取り込むこと |
| Pull Request（プルリクエスト） | 自分の変更を別のブランチに取り込んでもらうための提案 |
| Merge（マージ） | 分かれていた変更を統合すること |
| README | プロジェクトの概要や使い方を説明するファイル |
名前だけ見ると難しそう。
でも、チームで作業する場面に当てはめると、少し分かりやすくなる。
例えば、自分のブランチで作業して、変更をコミットする。
それをGitHubにpushする。
そしてPull Requestを作り、チームメンバーに変更を確認してもらう。
問題がなければ、mainなどのブランチにマージする。
もちろん、これは一般的な流れの一例。
チームによってルールは違うし、必ずこの手順で作業するわけではない。
ローカルで作業するのと、GitHubで作業するのは何が違う？
私自身、今まさに気になっているところ。
ローカル（Local）とは、ここでは自分のMacの中にある作業環境のこと。
例えば、Macに保存したプロジェクトのCSSを変更する。
それだけなら、通常は自分のMac上のファイルが変わるだけ。
GitHubにあるチームのファイルが、自動的に書き換わるわけではない。
ローカルで変更をコミットし、そのコミットをGitHubへpushするなど、別の操作が必要になる。
ただし、AIコーディングツールがGit操作まで行う場合もあるので、何を実行するのかは確認しておきたい。
そして、専用ブランチにpushすることと、mainに変更を取り込むことも別の操作。
ブランチを使うのは、チームの作業を守るための方法の一つでもある。
私がまだ慎重なのは、知らない操作があるから。
でも、少しずつ仕組みが分かれば、必要以上に怖がらずに使えるようになるのかもしれないね。
GitHubのコードは、誰でもダウンロードして使っていいの？
ここで、11年前のことを思い出した。
私は当時、GitHubからいろいろなコードをダウンロードして、自分のWebサイトに使わせてもらっていた。
でも今は、自分でもGitHubにプロジェクトを保存している。
ということは、今度は私が作ったものを、誰かがダウンロードして使うこともあるの？
気になって調べてみたら、GitHubにはPublic（公開）とPrivate（非公開）という設定があることが分かった。
| 公開設定 | 誰が見られる？ |
|---|---|
| Public（公開） | 原則として誰でもコードを閲覧・ダウンロードできる |
| Private（非公開） | 自分やアクセスを許可された人だけが閲覧できる |
なるほど。
自分のリポジトリを確認してみた。
すると、全部で18個！
そのうちPublicが3個、Privateが15個だった。
いつの間に18個も作っていたんだろう！（笑）
でも、ここでもう一つ疑問が。
Publicなら、誰でも自由に使っていいということ？
実は、そうとは限らないらしい。
コードが公開されていて、誰でも見ることができるのと、誰でも自由に使っていいのは別の話なんだ。
そこで出てくるのが、ライセンス（License）。
GitHubのライセンスって何？
ライセンスは、プログラムをほかの人がどんな条件で利用できるかを示すもの。
例えば、公開されているコードでも、作者が利用条件を指定している場合がある。
よく使われるライセンスの一つが、MIT License。
これは、著作権表示やライセンス文を残すなどの条件を守れば、商用利用や改変、再配布なども広く認められるライセンス。
一方、Publicのリポジトリでも、ライセンスが付いていない場合には、自由に改変したり、自分の製品に組み込んだりしていいとは限らない。
GitHubで見られるから、何でも自由に利用していいわけではないんだね。
そう考えると、11年前に見た「Feel free to use!」という言葉も、あらためて印象的。
ただし、実際にコードを利用するときは、その言葉だけでなく、ライセンスなどの利用条件を確認することが大切。
そして、あの「Buy me a beer」。
使ってくれる人が、もしよかったら作者を応援できる。
そんな文化があることにも、当時は驚いた。
コードを公開する人、使う人、改良する人、応援する人。
GitHubには、そうしたつながりもあるんだね。
自分が作ったコードも、誰かに使ってもらえる？
これも今回、ちょっと面白いなと思ったこと。
私は今、Claude CodeやCodexを使って、自分の仕事に必要なアプリやツールをいくつも作っている。
その一部はGitHubに保存している。
もちろん、自分だけで使うものもあるし、業務用なので公開したくないものもある。
でも、もし「これはほかの人にも使ってもらえそう！」というものがあったら？
自分が権利を持ち、公開して問題のないコードなら、Publicにして、適切なライセンスを設定することで、ほかの人にも利用してもらえるようにできる。
ただし、公開前には注意も必要。
APIキーやパスワード、顧客情報、非公開にしたい業務データなどが含まれていないか。
ほかの人が作ったコードや素材を、許可なく公開していないか。
過去の変更履歴にも、公開してはいけない情報が残っていないか。
こうした点は、ちゃんと確認したい。
私も今すぐ公開する予定ではないけれど、いつか自分のプロジェクトを見直して、問題がなく、誰かの役に立ちそうなものがあれば、1つか2つ共有してみるのも面白そうだと思っている。
11年前は「なんて優しいんだろう！」と思いながら、誰かのコードをダウンロードしていた私。
今度は自分が「Feel free to use!」と言う側になるかもしれない。
そう考えると、なんだか楽しいね。
AIハッカソンにGitHubは必須？
私の1回目のAIハッカソンでは、GitHubアカウントが参加条件だった。
そして4回目でも、チーム開発にGitHubを使っている。
だから、私にとってはAIハッカソンとGitHubがかなり密接につながっている。
ただし、すべてのAIハッカソンでGitHubが必須というわけではない。
参加条件や成果物の提出方法はイベントによって異なる。
GitHubのリポジトリURLを提出するイベントもあれば、デモ動画やプレゼン資料などを中心に評価するイベントもある。
だから、参加前には募集要項や提出条件を確認した方がいい。
とはいえ、AIを使ってアプリを開発するなら、GitHubの基本を知っておいて損はなさそう。
チーム開発だけでなく、自分一人で作っているプロジェクトの変更履歴を残すためにも利用できるから。
初心者は、何から始めればいい？
これからAIハッカソンに参加する人なら、まずはGitHubのアカウントを作って、画面を見てみるところからでもいいと思う。
例えば、こんな順番。
- GitHub公式サイトでアカウントを作る
- 公開リポジトリを開き、ファイルやREADMEを見てみる
- 自分の練習用リポジトリを作ってみる
- READMEなどの簡単なファイルを編集してみる
- コミットやブランチの意味を少しずつ覚える
公開リポジトリを見て、気になるコードがあったら、READMEやライセンスも確認してみる。
GitHubには、ファイルをZIPでダウンロードする方法や、Gitを使って手元にコピーする方法もある。
そして、チームのリポジトリを使う場合は、最初に作業ルールを確認したい。
どのブランチを使うのか。
変更はどのように共有するのか。
mainへ直接pushしてよいのか、それともPull Requestが必要なのか。
分からなければ、チームメンバーに聞けばいい。
私も、まだGitHubのすべてを理解しているわけではない。
だからこそ、いきなり重要なプロジェクトで試すより、練習用のリポジトリで操作を覚えるのもよさそうだね。
GitHubを知って11年。やっと共同開発の入口に立った気がする
振り返ってみると、ちょっと面白い。
11年ほど前、Webデザインを勉強していた私は、GitHubから無料のコードをダウンロードして、自分のサイトに使っていた。
特に好きだったのは、動くスライダーや、ちょっと変わった写真のギャラリー。
便利なコードを公開してくれる人たちに驚きながら、いろいろなパーツを組み合わせるのを楽しんでいた。
それから長い間、GitHubにはほとんど触れていなかった。
ところが最近、Claude Codeを使うようになってアカウントを作り、AIハッカソンに参加するようになった。
1回目のハッカソンでは、チームのリポジトリでREADMEの完成を手伝った。
4回目のハッカソンでは、自分専用のブランチまで用意してもらった。
同じGitHubなのに、関わり方が少しずつ変わっている。
しかも、今度は国際チームでの共同開発。
まだ分からないことも多いし、間違った操作をしないように慎重になっている。
でも、こうして少しずつ経験していくことで、GitHubが何のためにあるのかが分かってきた。
さらに、今回あらためてPublicやPrivate、ライセンスについて調べてみて、昔とは違う発見もあった。
GitHubは、単に自分のコードを保存する場所でも、チームで共同開発する場所でもない。
世界中の人たちが、コードを公開したり、共有したりできる場所でもあるんだね。
知っていることと、実際に使ってみることは、やっぱり違う。
そして、これもAIハッカソンに参加してよかったことの一つなんだと思う。
次は、自分専用のブランチをもっと使いこなせるようになりたいな！
そしていつか、11年前の私が感動したように、誰かに「これ、自由に使っていいよ！」と言えるものを公開できたら面白いかもしれないね。