となりのAI ・ 番外編 GitHub 03

GitHubは
AIとの作業台

push、pull request、pull。
AI時代の共同作業として理解します。

Extra 03 / GitHub as AI Workbench
となりのAIぜんたい地図
番外3の地図
手元のGitを、GitHubでAIや人と共有する回。上げる(push) → 共有 → 採用前チェック(PR) → 取り込む(pull)、の流れです。

PART 1 ・ 手元を、越える

AIも人も、
同じ場所を見る。

手元だけだと、自分しか見られない。GitHubに上げれば、履歴ごと共有できます。

となりのAIPART 1 ・ 共有する
pushとpullは共有棚との出し入れ
GitHubは「完成品を置く場所」ではなく、人とAIが同じ履歴を見る共有棚です。pushとpullは、その棚との出し入れです。
となりのAIPART 1 ・ 共有する

push = 手元の履歴をGitHubへ送る

pushは手元の履歴をGitHubへ上げる
pushは納品ではありません。手元でcommitした履歴を、AIや人が見られる共有棚へ上げる操作です。
となりのAIPART 1 ・ 共有する

Pull Request = 採用前の確認依頼

Pull Requestは本線へ入れる前の採用依頼
AIが変更したものを、いきなり本線へ入れない。PRにして、差分を見て、人間が採用する。ここがAI時代の安全装置です。
となりのAIPART 1 ・ 共有する

pull = GitHubの最新版を手元へ戻す

pullはGitHubの最新版を手元へ戻す
なぜ必要?GitHub上の最新版と、自分の手元を揃えるため。
合言葉作業前にpull。最新の状態を見てから、次に入る感覚。

PART 2 ・ もう一段

AIエージェントに、
任せる。

repoを渡して、タスクを頼む。AIが速くなるほど、人は「何を採用するか」を握ります。

となりのAIPART 2 ・ AIに任せる

AIエージェントに任せる時代の型

01repoを渡す作業場所を共有する。
02小さく依頼1タスクに絞って頼む。
03diffを見る何が変わったか確認。
04質問する理由を説明させる。
05mergeするよければ採用する。

AIが速くなるほど、人間は
「何を採用するか」を握る。

PART 3 ・ その先と、安全

公開まで、ひと続き。

GitHubの変更を見てWebへ公開するサービスもある。便利な反面、"何を上げるか"の線引きが要ります。

となりのAIPART 3 ・ 安全に

GitHubには、公開と非公開がある

Public 外から見える 教材、サンプル、公開してよいツール。プロフィールや実績にもなる。
/
Private 限られた人だけ 事業途中の資料や、公開前の作業。共有相手を確認して運用する。
BUTprivateでも、患者情報や認証情報を入れてよいわけではありません。そもそも入れないが基本です。
となりのAIPART 3 ・ 安全に

AI時代のGitHub安全チェック

1
患者情報なし
実症例を貼らない
2
APIキーなし
.envに分ける
3
公開範囲確認
public/private
4
差分を見る
AIの変更を確認
AIに渡してよいもの
一般化した教材、公開前提のHTML、架空データ、仕様メモ。
渡さないもの
患者情報、認証情報、施設内の機密、復旧コード、個別症例の経過。
となりのAIまとめ
GitHubで最初に覚える5操作

この回のゴールは、GitHubを「アップロード先」ではなく、AIと共同作業する共有棚として持ち帰ることです。

となりのAIまとめ

3回ぶんの、持ち帰り

AI時代の制作は、
戻れる・見える・任せられる。

Gitで戻れる。GitHubで見える。PRで採用を決められる。だから、AIに任せても、人間が主導権を失いません。

GitHubは、AIと働くための作業台です。

Extra Series ・ 完

GitHubは、非エンジニアが
AIと働くための作業場所。

あとは本編で、自分の1問を壊さず育てる実践へ。

01 / 15