GitHubの基本機能を学ぼうMMS公開ワークショップ

コミット・プッシュの、その先へ

Claude Code / Codex で webアプリを作りながら
GitHubの基本機能を学ぼう

ターミナルは使いません。デスクトップアプリだけで進めます。

120分・ハンズオン サラリーマン大吉、ふたたび 3つのミッション

前回までの大吉くん

大吉くん
妹に「推し活サイトを作って」と頼まれて、Gemini と GitHub Pages でホームページを公開できたんだよなぁ。GitHub、思ったより怖くなかった。

大吉くんは前回、GitHubで「Webサイトを公開する」ところまで体験済みです。
ただ、使えているのはまだ 「ファイルを置いて公開する」 ところまで。

大吉くん
Claude Code や Codex ともつないでみたけれど…ファイルを保存する場所として使っているだけ。
「コミット・プッシュ」は聞いたことがあるけれど、その先って、何ができるんだろう？

今日のゴール

GOAL
ターミナルを使わず、デスクトップアプリだけで小さな Webアプリ（AIリンク集）を作りながら、
GitHubの 「保存のその先」にふれていきます。

「アプリが作れる」がゴールではなく、AIエージェントで一歩踏み出し、GitHubの基本機能まで理解できるようになるのが今日のゴールです。

でもその前に──いきなり作り始める前に、まず 「そもそも Git・GitHub とは何か」 を、次のページで一緒に整理しておきましょう。ここが分かると、今日やることの意味がつながります。

予備知識

そもそも Git・GitHub とは？

名前は似ているけれど、役割が違う「2つのもの」です。

① Git（ギット）＝ 変更を記録する道具

Git 手元のPCの中で動く

ファイルの変更を「記録」して、いつでも前に戻れるようにする道具。

ゲームのセーブ機能に近いものです。作業の区切りで「セーブ（記録）」しておくと、あとから「あの時の状態」に戻したり、何をどう変えたかを見返したりできます。
Gitがやっていること
📄ファイルを編集アプリで作成・修正
→commit
（セーブ）
🗂️変更が記録される区切りごとに履歴がたまる

この「セーブ」のことを commit（コミット） と呼びます。

大事なポイント：Claude Code や Codex を使っていると、この Git が裏で動いています。普段は意識しなくても、「commit」「push」という言葉でこの仕組みに触れています。

素朴な疑問：Gitって、どこにあるの？

大吉くん
commit で「記録する」って言うけど…その記録って、どこに保存されてるの？
なんだか宇宙のどこかに飛んでいってる気がして、ちょっと不安なんだよなぁ。

大丈夫、宇宙には行きません。Gitの記録は、ちゃんと お使いのPCの、いま作業しているフォルダの中 にあります。

記録は「作業フォルダの中」に隠れている
📁作業フォルダお使いのPCの中
→この中に
📄作ったファイルai-link.html など
＋
🗄️.git フォルダ変更の記録をしまう倉庫

「.git」は、普段は隠れて見えないフォルダ。Gitが、変更の履歴をここに自動でためてくれています。

つまり、こういうこと：Gitの記録は、まず手元のフォルダの中（.git）に保管されます。そこから push すると、そのコピーが GitHub（クラウド）にも保管される。だから「どこへ行ったか分からない」ことはありません。
※ この「.git」を自分で開いていじる必要はありません。“裏にこういう倉庫がある”と知っておくだけでOK。（参考：Macなら Finder で Command + Shift +「.」で隠しフォルダを表示できます）

② GitHub（ギットハブ）＝ ネット上の置き場 ＆ 道具箱

GitHub インターネット上（クラウド）

Gitで記録したものを「ネット上に置く」場所。さらに、便利な機能がついた道具箱。

手元（Git）で記録したファイルを GitHub に送って（push）おけば、なくさず保管でき、人と共有したり、自動で動かしたりできます。
Git と GitHub の関係
💻お使いのPCGitで記録（commit）
→push
（送る）
☁️GitHub保存・共有・自動化

commit＝手元でセーブ ／ push＝そのセーブを GitHub へ送る

用語メモ　commit（コミット）＝記録する・セーブする／push（プッシュ）＝GitHubへ送る。この2つはセットでよく使います。

GitHubでできること（今日やるのはここ）

GitHubは「ファイルを置く場所」だけではありません。よく使う代表的な機能はこのあたり。今日はこのうち色のついた3つにふれます。

リポジトリファイルの保存・管理いま使えている
Pull Request / merge変更を確認して取り込む今日・M1
Issueやること・気づきを記録今日・M2
Actions決まった作業を自動で動かす今日・M3
GitHub PagesWebサイトを公開前回やった
※ GitHub Pages（Webサイト公開）は前回のワークショップで体験済み。アーカイブはMMS内にあります。

今日の3つのミッション

  • ミッション1：AIリンク集を作る（commit / push / branch / PR / merge）
  • ミッション2：やりたいことを Issue に記録する
  • ミッション3：Actions で特典の自動収集（見せる中心）
この地図を頭の片隅に置いて、ここからは実際に手を動かしていきます。分からない言葉が出てきたら、このページに戻ってきてOKです。

ミッション 1 　難易度 ★★☆☆☆

AIリンク集を作ろう

デスクトップアプリで Webアプリを作り、GitHubに保存（commit / push）するまで

大吉くんの悩み

大吉くん
AIツールが増えてきて、Chromeのブックマークがぐちゃぐちゃ…。「あれ、あのツールはどこだっけ？」と毎回さがしている。
自分専用の 「入口ページ」 があったらいいのになぁ。
ターミナルはまだ敷居が高い。そこで今日は Claude Code / Codex のデスクトップアプリを使って、Webアプリ（リンク集）を作ります。
※「デスクトップアプリ」＝今日使う道具／「Webアプリ」＝作るもの。この2つは別物です。

手順１：作業フォルダを用意する

1
お使いのPCに、今日の「作業フォルダ」を ai-link という名前で作る
なぜ？ … GitHubで管理する単位は「フォルダごと」。この作業部屋がのちほどリポジトリ（GitHub上の保管場所）になります。今日は全員で名前をそろえると、画面の説明やエラー確認がしやすくなります。
今日のフォルダ名
ai-link
※ すでに同じ名前のフォルダやリポジトリがある人は、ai-link-v2 のように、後ろに数字を付けてもOKです。
今日は説明書ファイルは作らずに進めます　前回のハンズオンで出てきた CLAUDE.md / AGENTS.md は、AIに「このプロジェクトではこう進めてね」と伝える説明書です。小さなリンク集なら、なくても作れます。今日はGitHubの基本機能に集中し、あとで長く育てる段階になったら追加します。

手順２：デスクトップアプリにお願いして作ってもらう

2
アプリに、次の文章をそのまま伝える
なぜ？ … 自分でコードを書く必要はありません。やりたいことを言葉で伝えると、アプリがファイルを作ってくれます。これがAIエージェントの便利なところ。
プロンプト例（コピーして貼り付け）
このフォルダに、よく使うAIツールへのリンクを並べた「AIリンク集」のWebページを作成してください。 ファイル名は ai-link.html にしてください。 HTML1ファイルで完結する形にして、ダブルクリックで開けるようにしてください。 ChatGPT・Claude・Gemini のリンクを入れてください。
アプリが .html ファイルを作ってくれます。実行する前に「このファイルを作っていいですか？」と確認が出たら、内容を見て「はい」で進めます。

手順３：できたページを開いて確認する

3
できた ai-link.html をダブルクリックして、ブラウザで表示を見る
なぜ？ … この時点ではまだ「自分のPCの中だけ」にあるファイルです。GitHubにはまだ送っていません。次の手順でGitHubに保存します。
うまくいかない人用：これをコピーして ai-link.html で保存
<!DOCTYPE html>
<html lang="ja">
<head><meta charset="UTF-8"><title>AIリンク集</title>
<style>
  body{font-family:sans-serif;background:#fff;padding:30px;}
  h1{color:#27314a;}
  a{display:block;background:#eef3f7;margin:10px 0;padding:14px 18px;
    border-radius:12px;text-decoration:none;color:#27314a;}
</style></head>
<body>
  <h1>わたしのAIリンク集</h1>
  <a href="https://chatgpt.com">ChatGPT</a>
  <a href="https://claude.ai">Claude</a>
  <a href="https://gemini.google.com">Gemini</a>
</body></html>

手順４：GitHubに「保管場所（リポジトリ）」を作る

4
GitHubの画面で、今日のファイルを入れる「リポジトリ」を1つ作る
なぜ？ … 手順１で作った“作業部屋（フォルダ）”は、まだ自分のPCの中だけ。その中身を送る先＝GitHub側の受け皿が「リポジトリ」です。送る前に、この受け皿を先に用意します。
リポジトリ 通称：レポ / repo

GitHub上の「プロジェクトの保管場所」。1つのアプリ＝1リポジトリが基本です。

フォルダがまるごと入るロッカーのようなもの。ファイル本体も、これまでの変更履歴も、ここにまとまって入ります。
今日はGitHubの画面から手動で作ります
🌐GitHubを開くブラウザでログイン
→＋New
➕New repository右上の＋→New repository
→名前を入力
📦リポジトリ完成例：ai-link
🔒
今日は Private（非公開）で作ります。
このリンク集は、あとで特典・アーカイブ・メール連携など、自分だけで使う情報を入れて育てていく前提です。最初は必ず Private を選び、公開用に見せたいものは別のデモ版として分けます。
※ イメージ図：実際のGitHub画面は少し変わることがあります。
GitHubNew repository
Repository name
ai-link
Private
You choose who can see and commit to this repository.
Create repository
→名前は ai-link
→今日は Private
→最後に緑のボタン
👀 ここを見る：名前を入れる欄、公開範囲の Private、いちばん下の緑色の「Create repository」ボタン。
AIや CLI でも作れるけれど…　Claude Code / Codex に頼んだり、GitHub CLI（gh）という道具でも作れます。ただし CLI は最初に認証（ghのログイン設定）が必要で、ここが済んでいない人は時間がかかりがち。今日は全員の足並みをそろえるため、GitHubの画面から手動で作ります。
※「CLI」「認証」という言葉は、今日は“そういうやり方もある”くらいの理解でOK。深くは扱いません。

手順５：GitHubに保存する（commit → push）

5
アプリに「GitHubに保存して」と伝える（commit → push）
なぜ？ … 手元のファイルを記録（commit）して、GitHubへ送る（push）と、なくさず保管でき、どこからでも見られます。送り先は、手順４で作ったリポジトリ（受け皿）です。
いま起きていること
📄ai-link.html手元で完成
→commit
（記録）
🗂️変更を記録セーブ完了
→push
（送る）
☁️GitHub保存できた！
※ イメージ図：実際のGitHub画面は少し変わることがあります。
ai-linkCodeIssuesPull requestsActions
main ✓ pushed just now
📁 ai-linklatest commit
📄 ai-link.htmlAIリンク集を追加
📄 README.mdproject overview
→ここに ai-link.html が出ていれば、GitHubへ送れています。
👀 GitHubのここを見る：リポジトリのトップページに、いま作った ai-link.html が出ていれば送信成功です。
この回のポイント　commit＝セーブ／push＝GitHubへ送る。
「次は他のAIツールも足したい」となったとき、そのまま直す道（main）と、別の場所で試す道（branch）の2通りがあります。次のページでその話に進みます。

ミッション 1 　つづき 　難易度 ★★★☆☆

branch・Pull Request・merge

本番を壊さずに「試して → 確認して → 取り込む」3点セット

大吉くんの次のやりたいこと

大吉くん
リンク集ができたから、今度は Grok や Felo、NotebookLM なども足したい。
…でも、せっかく動いているページを直接いじって、うっかり壊したらどうしよう？

その不安、正しい感覚です。だからプロの現場では、いきなり本番を書き換えません。
まず 別の場所でこっそり試して、問題なければ本番に取り込む──この安全な進め方を、GitHubの3つの機能で行います。

これから覚える3つの言葉
🌱branch試すための別レーンを作る
→
🙋Pull Request本番に入れていい？と確認
→
🔀mergeOKなら本番へ合流

この3つはいつもセットで登場します。順番に見ていきましょう。

① branch（ブランチ）＝ 試すための「分かれ道」

branch 本番を壊さずに試す

本番（main）からコピーした「作業用の別レーン」。ここで好きなだけ試せます。

道路の工事中レーンのようなもの。本線（main）はそのまま走らせながら、横に新しいレーンを作ってそこで作業します。失敗しても本線には影響しません。
mainから branch を分ける
🛣️mainいま公開中の本番
→branchを作る
🌱add-toolsツール追加を試す作業レーン

main＝本番の道 ／ branch＝そこから枝分かれした試しの道（add-tools は「ツールを追加する作業用」という意味で付けた名前です）

プロンプト例（コピーして貼り付け）
今のリンク集はそのまま残したまま、AIツールをいくつか追加した別バージョンを作りたいです。 mainを直接変更せず、ツール追加用の branch を作って作業してください。 次のツールをリンク集に追加してください。 ・Grok ・Felo ・Miri Canvas ・NotebookLM ・Skywork ・Manus ・GitHub まずはリンクを増やして、変更内容を commit して GitHub へ push してください。 そのあと、main に取り込む前に確認できるように Pull Request を作成してください。
⚠️
「ツールを足して」だけだと、mainを直接直すことがあります。
本番を残したまま試したい時は、「mainを直接変更せず、branchを作って」と最初に伝えるのが安全です。さらに Pull Request も作って と言うと、確認画面まで進めてもらいやすくなります。
1
アプリに「ツールを追加するための branch を作って」と伝える
なぜ？ … 先に作業レーンを用意してから編集すると、main（本番）は無傷のまま安心して試せます。
2
その branch の中でツールのリンクを追加し、commit → push する
なぜ？ … 編集・記録（commit）・送信（push）は前のページと同じ動き。ちがうのは「main ではなく branch に対して」行っている点だけです。
この時点で GitHub には main（元のまま） と ツール追加を試しているbranch（例：add-tools） の2本がある状態です。まだ本番は変わっていません。branchを作っただけでは、Pull Requestは完成しません。変更を commit → push した後に、GitHub上で「Compare & pull request」から作るか、AIエージェントに「PRも作って」と頼みます。

② Pull Request（プルリクエスト）＝「入れていい？」のお伺い

Pull Request 略して「プルリク」「PR」

branchで作った変更を、本番(main)に取り込む前に「確認してね」と出すお願い。

「この変更を入れてよいか、見てください」という申請書のイメージです。どこをどう変えたかが一覧で見え、コメントも残せます。
変更を見比べてから取り込む
🌱add-toolsツールを足した変更
→Pull Request
🔍変更点を確認どこが変わった？を一覧で

GitHubが「mainと比べてここが変わりました」と差分を見せてくれます。

実際の順番
branchを作る → ツールを追加する → commitする → pushする → Pull Requestを作る → Files changedを見る → 問題なければ mergeする。
※ Pull Requestは「branchを切った瞬間に自動でできるもの」ではありません。push後にGitHubのボタンから作る、またはAIエージェントに作成を頼む、という流れです。

GitHubの画面で作るなら、どこを押す？

AIエージェントに「Pull Requestも作って」と頼めば、ここは代わりに進めてもらえます。自分でGitHub画面から作る場合は、push後に出る 「Compare & pull request」 を押します。出ていない時は、リポジトリ上部の 「Pull requests」タブ から作成画面に進めます。

画面操作で作る場合
1. リポジトリ上部の Pull requests タブを見る
2. push後に出る Compare & pull request を押す（または New pull request）
3. 取り込み先が main、比べるbranchが ツール追加用のbranch になっているか確認する
4. タイトルと説明を確認して、Create pull request を押す

作成後のPull Request画面で見るところ

Pull Requestを作ると、GitHubの 「Pull requests」タブ に登場します。中を開くと、変更点が色分けで見えます。今日はハンズオンなので、実際にこの画面を一緒に見にいきます。

※ イメージ図：実際のGitHub画面は少し変わることがあります。
ai-linkCodeIssuesPull requestsActionsSettings
ツール追加: AIリンクを増やす #2
Open miraichi-ai wants to merge 1 commit into main from add-tools
Conversation Commits 1 Checks 0 Files changed 1
変更内容
Grok、Felo、Miri Canvas、NotebookLM、Skywork、Manus、GitHub を追加しました。
main に入れる前に、Files changed で差分を確認します。
ReviewersNo reviews

LabelsNone yet
Ready to merge Merge pull request
👀 ここを見る：Open は「まだmerge前で確認中」という意味です。main は本番側、add-tools は今回だけの作業用branch名（ツール追加を試している場所）です。ここで main に add-tools の変更を入れていいか を確認します。
※ イメージ図：差分の見え方を教材用に簡略化しています。
Pull request #2ConversationCommitsFiles changed 1
ai-link.html
<a href="https://chatgpt.com">ChatGPT</a>
+ <a href="https://grok.com">Grok</a>
+ <a href="https://felo.ai">Felo</a>
+ <a href="https://notebooklm.google.com">NotebookLM</a>
- <p>あとで追加予定</p>
→緑は追加、赤は削除。どこが変わったかをここで確認します。
👀 ここを見る：PR画面の「Files changed」タブ。緑＝足した行（追加したツールのリンク）がひと目で分かります。
一人開発でも、やる意味はある？
自分しか触らない小さな開発なら、main に直接 commit してもアプリは動きます。必須ではありません。でも Pull Request を一度はさむと──
・Gitのファイル履歴（commit）に加えて、「何を・なぜ変えようとしたか」がGitHub上にタイトル・説明つきで残る
・あとから「この変更、何だっけ？」を見返せる、消えない変更の記録になる
チームなら、ここで他の人がチェックします。今日はその“記録の作り方”を体験しておきます。

③ merge（マージ）＝ 確認OKの変更を本番に「合流」

merge 取り込む・合流させる

Pull Requestで確認した変更を、本番(main)に取り込んで反映させること。

工事レーンで仕上げた区間を、本線につなげて開通させるイメージ。ここで初めて、ツールが増えたリンク集が「本番」になります。
branch を main に合流させる
🌱add-tools確認OK
→merge
🛣️mainツール追加版に更新！

合流が終われば、作業レーン(add-tools)はもう役目を終えて消してOKです。

※ イメージ図：実際のGitHub画面は少し変わることがあります。
Pull request #2ConversationFiles changed
✓ All checks have passed

This branch has no conflicts with the base branch.

Merge pull request Close pull request
→緑のボタンを押すと、add-tools の変更が main に入ります。
👀 ここを見る：PR画面の下にある緑の「Merge pull request」ボタン。これを押すと合流します。
豆知識：このmergeは、本当は自分でこの緑のボタンを押すだけでもできます。今日は流れを通して体験するため、エージェントに「mergeして」と頼んで進めます。「手で押す方法もある」と知っておくと、仕組みがすっきり分かります。

素朴な疑問：「PRを作成」を押すと、いっぺんに何が起きてるの？

大吉くん
デスクトップアプリに 「PRを作成」ボタンがあった。
でも…今ってまだ、ローカルに保存されてるだけだよね？ このボタンを押すと、branch とか commit とか、いっぺんに起きるってこと？

まさにそこが分かりにくいところ。結論から言うと、その1ボタンの中で、ここまで習った手順が順番にぜんぶ走っています。

「PRを作成」ボタンの中で起きていること
🌱① branch作成試す別レーンを用意
→
🗂️② commit変更を記録
→
☁️③ pushGitHubへ送る
→
🙋④ PR作成確認してね、を出す

ボタンを押す前は、ご指摘どおり 「手元に保存されているだけ」。押すと、この4つが一気に進みます。

なぜ1ボタンにまとまっているの？　毎回この順番でやる“決まった流れ”だから、アプリがまとめて代行してくれます。中で何が起きているかを知っておくと、ボタンが急に賢いことをしているわけではない、と分かって安心できます。手で1つずつ行う方法もあります。

全体の流れ（ここまでのまとめ）

「ツールを少し増やす」だけのために遠回りに見えるかもしれません。でもこの流れが、本番を壊さずに安全に育てていくための王道です。

線路でイメージする：本線(main)と枝分かれ(branch)
🌱 ✏️ 🔍 🔀 🎉 main 公開中の本番 ① 枝分かれ branch を作る ④ merge 本線に合流 変更後の本番 ツール追加版に更新 ② ツール追加 commit / push ③ Pull Request チェック・記録

合流（merge）すれば、枝分かれした変更が本線(main)に乗り、ここから先は変更後の内容に。／合流しなければ、枝は分かれたまま（試しただけで終わり）。どちらにするかを選べます。

この回の用語まとめ
・branch＝本番を壊さず試す別レーン　／　・Pull Request（PR）＝入れていい？の確認・記録　／　・merge＝確認OKを本番へ合流
CLEAR
これで commit / push / branch / Pull Request / merge が一周つながりました。
「保存のその先」で何ができるか、手で触って分かったはずです。
次のミッション2では、「やりたいこと・気づき」を記録する Issue にふれます。リンク集を触っているうちに出てきた「次にやりたいこと」を、消えないメモとしてGitHubに残す機能です。

ミッション 2 　難易度 ★★☆☆☆

やりたいことを Issue に記録しよう

思いついたアイデアや「次やること」を、GitHubに消えないメモとして残す

大吉くんの悩み

大吉くん
リンク集を触っていたら、アイデアがどんどん浮かぶ。
「次はカテゴリ分けしたい」「色も変えたい」…でも、メモがLINEやノートにバラバラで、気づくと忘れちゃってるんだよなぁ。

そのアイデア、アプリと同じ場所（GitHub）に置いておけたら便利だと思いませんか？　それを叶えるのが Issue（イシュー） です。

Issue（イシュー）＝ やること・気づきのメモ帳

Issue GitHubの中の付箋 / ToDoカード

「やりたいこと」「直したいこと」「気づき」を1件ずつ書いて残せる、GitHub内のメモ。

机に貼る付箋（ふせん）のイメージ。1枚に1つの用件を書き、終わったらはがす（閉じる）。しかも、アプリのリポジトリと同じ場所に貼れるのがポイントです。
Issueのライフサイクル
💡思いつく「カテゴリ分けしたい」
→書く
📝Issueに残る消えないメモになる
→対応
✅Close（閉じる）終わったら完了に

書いた Issue は、対応が終わるまで ずっと残ります。忘れても大丈夫。

じつは、AIへの「作業依頼書」にもなる
Issue に「カテゴリ分けしてほしい」と書いておけば、それはそのまま Claude Code / Codex への依頼メモになります。「あとでこれをお願いしよう」を、消えない形で置いておけるわけです。

手順：Issueを1つ書いてみる

1
リポジトリの上部にある「Issues」タブを開く
なぜ？ … Issueは、アプリのリポジトリの中にぶら下がっています。だから「このアプリへのメモ」として整理されます。
2
緑の「New issue」を押し、タイトルと内容を書く
なぜ？ … タイトル＝ひと言の用件、内容＝補足。日本語でOK。難しく考えず、思いついたことを素直に書きます。
書き方の例（コピーして貼り付け）
タイトル：AIツールをカテゴリごとに分けて表示したい 内容： ツールが増えてきたので、「会話・相談」「調査」「制作」などのグループに分けて並べたいです。あとで Claude Code / Codex にお願いする予定のメモとして残します。
3
「Create」で作成する
なぜ？ … これで、アイデアがGitHub上に番号つき（#1 など）で記録されます。もう忘れても大丈夫です。
※ イメージ図：実際のGitHub画面は少し変わることがあります。
ai-linkCodeIssuesPull requestsActions
Add a title
AIツールをカテゴリごとに分けて表示したい
Write
ツールが増えてきたので、会話・相談、調査、制作などのグループに分けたいです。
Submit new issue
→タイトルは短く
→内容は日本語でOK
→最後に緑のボタン
👀 GitHubのここを見る：リポジトリ上部の「Issues」タブ。作ったメモが番号つきで一覧に並びます。

じつは、AIに頼んで作ってもらうこともできる

ここまでは GitHub の画面から手で書く方法を見てきました。でも Issue は、Claude Code / Codex に頼んで作ってもらう こともできます。「こういう Issue を立てておいて」とお願いするだけです。

プロンプト例（コピーして貼り付け）
このリポジトリに、次の内容で Issue を1つ作成してください。 タイトル：AIツールをカテゴリごとに分けて表示したい 内容：ツールが増えてきたので、「会話・相談」「調査」「制作」などのグループに分けて並べたいです。あとで対応するためのメモとして残します。
手で書いても、AIに頼んでも、できあがる Issue は同じものです。「画面から作る方法」と「お願いして作る方法」の両方があると知っておくと、その時々でやりやすい方を選べます。

素朴な疑問：Issueって、使わなきゃダメ？

大吉くん
やりたいことを書くだけなら…プロジェクトのフォルダの中にメモ用のファイル（handoff など）を作って、そこに書いておけばよくない？ わざわざ Issue にしなくても…

とても良い疑問です。結論から言うと、Issue は「必ず使わなければいけないメニュー」ではありません。　一人でサッとメモするだけなら、フォルダの中にメモファイルを作る方法でも十分です。

それでも Issue が役に立つのは、こんなときです。

  • チームでプロダクトを作るとき：誰が見ても分かる場所に「やること」が並び、担当や進み具合を共有できる。
  • 履歴として残したいとき：いつ・何を・なぜやろうとしたかが番号つきで残り、メモファイルより探したり整理したりしやすい。
  • 経緯も一緒に残したいとき：その Issue の下にコメントを足して、やりとりや結果を記録していける。
使い分けの目安　自分用のサッとしたメモ → フォルダ内のメモファイルでOK。／みんなで共有したい・あとから履歴をたどりたい → Issue が便利。今日は「こういう道具もある」と一度体験しておくのが目的です。

このミッションのまとめ

この回のポイント
・Issue＝GitHub内の「やること・気づき」メモ（付箋）
・アプリと同じ場所に残るので、あとで見返せる・忘れない
・そのまま AIエージェントへの依頼書にもなる
CLEAR
これで、思いついたことを 消えない形でGitHubに残す 方法が分かりました。
「あとでやろう」が、ちゃんと積み上がっていきます。
最後のミッション3では、その「やること」を自動でこなしてくれる Actions にふれます。決まった作業を、決まったタイミングで GitHub が代わりに動かしてくれる仕組みです。

ミッション 3 　難易度 ★★★★☆

Actions で「毎週の作業」を自動にしよう

決まった作業を、決まったタイミングで GitHub に代わりにやってもらう

大吉くんの悩み

大吉くん
セミナーの特典やアーカイブ、あとで使おうと思っても、いざとなると 探し出すのに時間がかかるし、見つからないことも…💦
ちゃんと管理できればいいんだけど、それも手間で、なかなか続かない。せっかくの特典、ちゃんと活用・管理したいんだよなぁ。
大吉くん
そういえば──MMSの朝活ブートキャンプで ダイチさんが GitHub Actions のことを教えてくれたよな。Another MMS では SYOちゃんさんが、それをさらに噛み砕いて解説してくれた。
あの機能を使えば、この“探す手間・ためる手間”を解決できるかも！

「毎週・決まった手順でやること」は、人がやると忘れるし、面倒。
そこで GitHub に“留守番”をしてもらって、毎週かわりに動いてもらうのが、最後のミッションです。これを担うのが、大吉くんがコミュニティで聞いた Actions（アクションズ）。

このワークショップについて　ここで出てくる 朝活ブートキャンプや Another MMS は、私たち MMS コミュニティで実際に行われている学びの場です。今日の「MMS公開ワークショップ」は、その雰囲気をちょっと体験してもらう会。仲間が教えてくれたことを、手を動かして自分のスキルにしていく──まさに今やっていることです。
miraiさん
miraiさん今日の進行役。つまずきやすい所を、参加者目線で一緒に確認します。
ダイチさん
ダイチさんActionsのヒントをくれた先生役。自動化の考え方をやさしく支えます。

Actions（アクションズ）＝ 自動で動く「からくり」

GitHub Actions 決まった時に・決まった作業を自動で

「いつ動かすか（タイミング）」と「何をするか（手順）」を一度書いておくと、GitHub が自動で実行してくれる仕組み。

自動調理器のタイマー予約のイメージ。「毎週月曜の朝7時に、この手順で調理して」とセットしておけば、こちらが寝ていても勝手に動いて、できあがりを置いておいてくれます。
今回セットする“からくり”の中身
⏰毎週月曜7時タイミング（cron）
→
📨Gmailを見に行く特典・アーカイブを検索
→
📄リンク集に追記ai-link.html に反映
→
💾自動で保存GitHubにcommit

この4つを、毎週 GitHubが勝手にやってくれます。大吉くんは何もしなくてOK。

「随時＝実は毎週」　メールが届いた瞬間に反応する仕組みは大がかり。でも決まった間隔（週1）で見に行くだけなら手軽で、体感はほぼ「いつのまにか増えてる」になります。頻度は自分の使い方に合わせて決められます。

ここからは、実際に“からくり”を組み立てます

ここが今日いちばんの山場です。でも安心してください。コードは自分で書きません。やることは 5つ。順番に1つずつ進めれば、誰でも同じ仕組みが作れます。後で見返せるよう、各手順に「何を・なぜ・どこを見るか」を書いてあります。

当日の進め方　ミッション3は少しレベルが上がります。基本はみんなができるように進めますが、Googleアカウントの状態や認証設定によって、途中で画面が違ったり、少し詰まったりすることがあります。その場で一緒に進められる人は一緒に進める。もし途中で止まっても大丈夫。この教材を見れば、あとから一人で続きを進められるように、手順を細かく残しています。
これから進める5つの手順（全体像）
🔑手順1Gmailの鍵を作る
→
🔒手順2鍵を金庫に預ける
→
🤖手順3AIに仕組みを
作ってもらう
▶️手順4動くかテストする
→
🎁手順5特典が増えたか
確認する
自分でやるのは手順1・2まで。手順3でAIにお願いしたら、あとはほぼ自動です　仕組み作り（プログラムや時間の設定）は、手順3でAIエージェントが全部やってくれます。だから難しいコードを覚える必要はありません。
※「自動で動くと利用料がかかるのでは？」という心配は、よくある疑問です。答えはこのページのいちばん最後の「素朴な疑問」にまとめてあります。
詰まった時の合言葉（コピーして貼り付け）
今、どこまで進んでいて、次に何をすればいいかを日本語で整理してください。 画面に出ているエラーや英語の意味も、初心者向けに説明してください。 勝手に進めず、次に押す場所・確認する場所を1つずつ教えてください。

手順1：Gmailを開くための「鍵」を作る（アプリパスワード）

仕組みが毎週Gmailを見に行くには、Gmailを開くための鍵が要ります。いつものログインパスワードは使わず、この用途だけの専用の鍵（アプリパスワード）を1個作ります。

アプリパスワード そのアプリ専用の、別の鍵

いつものパスワードとは別に発行する、16文字の使い捨ての鍵。

玄関の鍵（本体パスワード）はそのままに、勝手口の鍵を1個だけ追加で作るイメージ。万一もれても、本体は無事で、その鍵だけ無効にできるので安全です。
1
Googleアカウントの「セキュリティ」で、2段階認証プロセスがオンか確認する
なぜ？ … 2段階認証がオンになっていないと、そもそもアプリパスワードを作れません。下のページを開き、「2段階認証プロセス」を確認します（オフなら先にオンに）。
myaccount.google.com/security
※ イメージ図：Google画面はアカウント状態によって表示が変わります。
Google AccountSecurity
How you sign in to Google
2-Step Verification ✓ On
→ここが On なら、アプリパスワード作成へ進めます。
👀 ここを見る：「2段階認証プロセス」がオン（有効）になっているか。ここがオンでないと次に進めません。
2
アプリパスワードの作成ページを開き、名前に GMAIL_APP_PASSWORD と入れて「作成」する
なぜ？ … 下のページを開き、名前を入力して「作成」を押します。この名前は自分用のメモなので本当は何でもよいのですが、あとで GitHub の金庫に登録する名前と同じ「GMAIL_APP_PASSWORD」にそろえておくと、混乱せず分かりやすいです。
myaccount.google.com/apppasswords GMAIL_APP_PASSWORD
3
表示された16文字の鍵をコピーする
なぜ？ … 黄色い枠に「4文字×4」で出る16文字が鍵です。これを、すぐ次の手順2で金庫に貼ります（間のスペースは無くてもOK）。
⚠️
この画面を閉じると、同じ鍵は二度と表示されません。
閉じる前に、必ず次の手順2に進んで、コピーした鍵を金庫に貼ってください。（もし閉じてしまっても、また新しく作り直せば大丈夫です）
※ イメージ図：本物のアプリパスワードは載せません。下はダミー値です。
App passwordsGMAIL_APP_PASSWORD
Your app password for your device
abcd efgh ijkl mnop
→本番では、ここに出た16文字をコピーして、すぐSecretsへ貼ります。
👀 ここを見る：黄色い枠の中の16文字。これをコピーして、すぐ手順2で使います。
🔒
ここが安全の要：この16文字の鍵は、AIにもチャットにも貼らないでください。
鍵は、次の手順で GitHub の「金庫（Secrets）」に直接入れます。本番では設定画面を一緒に見ながら進めます。

手順2：その鍵を GitHub の「金庫（Secrets）」に預ける

作った鍵を、設定ファイルやチャットにそのまま書くのは危険です。GitHub には、秘密の情報を隠して安全にしまう Secrets（シークレット＝金庫） があるので、そこに入れます。

Secrets GitHubの中の金庫

パスワードや鍵など「人に見せたくない情報」を、隠した状態で安全にしまっておく場所。

一度しまうと ●●●で隠れて二度と表示されません。仕組み（Actions）だけが、中の鍵をこっそり取り出して使えます。
鍵は金庫へ。AIにもチャットにも貼らない
🔑手順1の鍵16文字のアプリパスワード
→金庫へ預ける
🔒Secrets●●●で隠れて保管
1
リポジトリの「Settings」タブ →「Secrets and variables」→「Actions」を開く
なぜ？ … リポジトリ上部の歯車「Settings」を開き、左メニューの「Secrets and variables」→「Actions」と進むと、金庫の画面が出ます。
2
「New repository secret」を押し、名前を GMAIL_APP_PASSWORD にして、鍵を貼る
なぜ？ … 名前（Name）は仕組みが鍵を探すラベル。このスペルぴったりでないと見つけられません（手順1で付けた名前とそろえてあります）。Secret欄に手順1の16文字を貼り、「Add secret」を押します。
GMAIL_APP_PASSWORD
3
登録後、値が ●●● で隠れていれば成功
なぜ？ … 中身はもう誰にも（自分にも）見えません。これで安全。もし間違えても、登録し直せばOKです。
※ イメージ図：Secret欄には本物の鍵を表示しません。登録後は中身が見えません。
SettingsSecrets and variablesActions
Name
GMAIL_APP_PASSWORD
Secret
••••••••••••••••
Add secret
→Nameはこのスペル
→Secret欄に16文字
→登録後は●●●で隠れる
👀 GitHubのここを見る：登録後の一覧に GMAIL_APP_PASSWORD が並び、値が ●●● で隠れていれば成功です。
メールアドレスはどこに書くの？　今回、金庫（Secrets）に入れるのは、機密性のいちばん高いアプリパスワード（鍵）だけです。メールアドレスのほうは、仕組み（ワークフロー）の中に直接書きます。
理由：このリポジトリは 非公開（プライベート） で作っていて、他の人には見えないからです。もし「メールアドレスも仕組みの中に書きたくないな」と感じる場合は、アプリパスワードと同じように、メールアドレスも金庫（Secrets）に入れてOK。その場合は手順3でAIに「メールアドレスもSecretsから読むようにして」と頼めば大丈夫です。どちらでも動きます。

手順3：AIエージェントに「集める仕組み」を作ってもらう

ここが要です。自分でプログラムを書く必要はありません。下の文章を、Claude Code / Codex のデスクトップアプリにそのまま貼って伝えるだけ。集める仕組みも、特典を表示する場所も、いらないものを消す機能も、ぜんぶアプリが作ってくれます。

プロンプト例（コピーして貼り付け）
Gmailから「特典・アーカイブ」っぽいメールを毎週自動で集めて、ai-link.html に表示する仕組みを作ってください。次の条件でお願いします。 ・生成AIは使わず、Gmailの検索条件（キーワードで絞る）だけで判定し、毎週の実行に料金がかからないようにする ・Gmailの認証は、GitHubのSecretsに登録したアプリパスワード（名前：GMAIL_APP_PASSWORD）を使う。メールアドレスはワークフローに直接書いてよい ・拾うキーワード（特典・アーカイブ・見逃し・録画・スライド・資料 など）と、捨てる言葉（お支払い・請求・領収・MTG など、個人情報や明細）を分けて、ノイズを除外する ・保存するのは「件名・差出人・受信日・期限・メモ・そのメールを開くリンク」だけ。メール本文の全文や個人情報は保存しない ・集めた特典を ai-link.html に一覧表示する「特典・アーカイブ」セクションも作る ・仕分けは完璧でなくてよい。そのかわり、画面で不要なカードを選んで非表示にできる「編集→選択→削除」機能も付ける ・毎週月曜の朝7時（日本時間）に自動で動かし、手動でも実行できるようにする ・集めた結果は data/resources-auto.json に貯めて、同じ特典の重複は除く。変更があれば自動でcommitして保存する
貼ったあとは？　プロンプトを Claude Code / Codex に渡したら、あとは アプリのメッセージに従って、内容を確認しながら「許可」して進めるだけです。必要なファイル（集めるプログラムや、動かす時間の設定、特典の表示・削除のしくみ）は、アプリが順番に作っていきます。中身のコードは読めなくて大丈夫です。
※ 拾うキーワード・捨てる言葉は、あとから「○○も拾って」「△△は除いて」と頼めば増やせます。自分のメールに合わせて育てていく前提でOK。

（補足）作られた仕組みは、どうやって動いている？

ここは自分で操作する手順ではありません。手順3でAIが作ってくれたものの中身を、軽く知っておくための補足です。全部わからなくて大丈夫。「こういうものが裏で動いているんだな」とイメージできればOKです。

  • 集めるプログラム：Gmailを見て、キーワードで特典を絞り、ai-link.html に書き込む“作業の手順書”。プログラミングのコードで書かれています。
  • 動かす予定表（GitHub Actions）：「いつ・何をするか」を書いておくと、GitHubがその通りに自動で実行してくれる仕組み。手順3でお願いした作業を、ここで代わりに動かしてもらっています。

この「いつ動かすか」の時刻は、cron（クーロン） という書き方で指定されています。

cron 「いつ動かすか」を書く時刻表

「毎週月曜の朝7時」のような“決まった時刻”を、短い記号で表す書き方。

今回の指定は 0 22 * * 0。なぜ7時なのに「22」？ GitHubの時計は世界標準時（UTC）で動いていて、日本はその9時間先。だから日本の月曜7時は、世界標準時だと日曜22時になります。
ここも自分で書く必要はありません　この時刻表もAIが書いてくれます。頻度を変えたいときは「毎日にして」「金曜の夜にして」と日本語で頼めばAIが書き換えます。今回は、特典メールは毎日来るものではないので週1回にしました。
※ 取りこぼし防止に、仕組みは「直近8日ぶん」のメールを見ます（週1実行に少し重ねてある）。

手順4：まずは「ちゃんと動くか」テストする

仕組みができたら、毎週月曜を待たずに その場で1回テスト実行して、ちゃんと動くか確かめます。やり方は2通り。どちらでもOKです。

テストすると、こうなる
📭ビフォー特典はまだ空っぽ
→テスト実行
⚙️1回動かすGmailを見に行く
→
🎁アフター特典カードが増える！

本番のデモでも、この「何もない→動かす→増える」の変化を見ていただきます（過去ぶんはデモ用にわざと空けておくのがコツ）。

やり方A：AIエージェントに「テストして」と頼む（いちばん手軽）

作ってくれたAIに、そのままテストもお願いするのがいちばん簡単です。エラーが出ても、その場で直してもらえます。

プロンプト例（コピーして貼り付け）
いま作った特典収集の仕組みを、一度テスト実行してください。Gmailから特典が集まって ai-link.html に表示されるか確認し、エラーが出たら直してください。

やり方B：GitHubの画面で、自分で動かしてみる

「実際にGitHubのどこで動くのか、自分の目で見てみたい」人は、ボタン操作でも試せます。

1
GitHubの「Actions」タブを開き、作った収集ワークフロー（例：「特典・アーカイブ自動収集」）を選ぶ
なぜ？ … ここに、これまでの実行の記録（緑✔＝成功）が並びます。手順3で作った仕組みが置いてある場所です。
2
右側の「Run workflow」を押し、もう一度「Run workflow」で実行する
なぜ？ … 「いま動かす」ためのボタンです（このボタンが出るのは、手順3で「手動でも実行できるように」と頼んだから）。
3
1〜2分待ち、行の頭に緑の✔が付けば成功
なぜ？ … 実行中はぐるぐる回る黄色、終わると緑✔（成功）か赤✕（失敗）になります。緑✔なら、Gmailを見て→特典を集めて→ファイルに書き込むところまで完了です。
※ イメージ図：実際のGitHub画面は少し変わることがあります。
ai-linkCodeIssuesPull requestsActions
特典・アーカイブ自動収集

workflow_dispatch / schedule

✓ Run collect resources1 minute ago
○ Scheduled runlast week
Run workflow
→右側のボタンで手動実行
→緑の✓なら成功
👀 GitHubのここを見る：「Actions」タブの実行一覧と、右側の Run workflow ボタン。実行後は行の頭に 緑の✔ が付きます。

手順5：ちゃんと増えたか、確認する

1
ai-link.html を開き直して、特典カードが増えているか見る
なぜ？ … 集めた特典は、仕組みが自動で ai-link.html に書き込んで保存（commit）してくれます。開き直すと、新しいカードが並んでいるはずです。これが「盛り付け」の結果です。
手順5を押したあと、裏で起きていること
📨Gmailを検索直近8日・キーワードで絞る
→
🗃️結果を貯めるresources-auto.json に蓄積・重複は除外
→
📄HTMLに反映ai-link.html に自動でcommit

この3つを、毎週月曜はひとりでに、お試しのときはRun workflowで手動で。どちらも中身は同じです。

ノイズが混じっていたら？　言葉のルールでの仕分けは完璧ではないので、関係ないメールが少し混じることがあります。そのときは ai-link.html の画面で 「編集 → 選択 → 削除」で消せます。広めに拾って、最後は人が整える──これが現実的なやり方です。

素朴な疑問：AIを使わないのに、ちゃんと探してくれるの？

大吉くん
「AIは使わない」って言うけど…AIが読んでくれないのに、どうやって特典のメールを見分けるの？ それって無理じゃない？

いい疑問です。ポイントは 「探す」と「考える（賢く読む）」は別の作業だということ。今回やっているのは、メールを賢く読んで判断するのではなく、あらかじめ決めた“言葉”でふるいにかける作業です。

やっているのは“言葉のふるい分け”
「特典・アーカイブ・見逃し・録画 などの言葉を含むメールを拾う／お支払い・請求・MTG などの言葉は除く」というルールを先に書いておくだけ。これは、Gmailの検索窓に言葉を入れて探すのと同じで、無料のふつうのプログラムでできます（AIの賢い判断は要りません）。
※ そのぶん仕分けは完璧ではありません（関係ないメールが少し混ざる）。だから手順3で「編集→選択→削除」機能も一緒に作り、最後は人が整えられるようにしてあります。

素朴な疑問：定期実行のたびに、トークン（クレジット）を消費しちゃうんじゃないの？

大吉くん
毎週動くってことは…そのたびに Claude Code や Codex のトークン（クレジット）が減っていくんじゃないの？
知らないうちに 利用料がかさんでいくのは、正直イヤなんだけど…。

いちばん気になるところですよね。結論は 「AIに“判断”をさせなければ、毎週の実行に料金はかかりません」。カギは、作業を 「考える仕事」 と 「盛り付けの仕事」 に分けて考えることです。

「考える仕事」と「盛り付け」を分ける
🧠考える仕事文章を作る・賢く判断する
＝AIの出番（料金がかかる）
／
🍽️盛り付けの仕事決まった場所に文字を足す
＝ふつうのプログラム（無料）

今回の毎週の自動収集は ぜんぶ右側（盛り付け）。だから AI は留守でよく、トークンは1ミリも使いません。

たとえ：自動調理器　AIが働くのは“自動調理器を組み立てる”手順3の1回だけ。完成すれば毎週ひとりでに動き、シェフ（AI）は厨房にいなくていい＝毎週の実行コストはゼロ。GitHub自身の自動実行も、個人利用なら無料の範囲で足ります。

素朴な疑問：AIを使えば、もっと完成度を高くできる？

大吉くん
逆に、AIにメールを1通ずつ読ませて判断させれば、もっと正確に特典だけ選べるんじゃないの？ そのほうが完成度が高そうだけど…。

そのとおり、できます。AIに1通ずつ読ませれば、仕分けの精度は上がります。ただし、そうすると 「毎週の実行のたびにAIが動く＝そのつど料金がかかる」ことになります。

どちらを選ぶかは“目的しだい”
・精度を最優先　→ AIに読ませて判断（そのつど料金がかかる）
・ずっと無料で回し続けたい　→ 今回の「言葉のルール」方式（料金ゼロ／精度は人の編集削除で補う）
今回は 「毎週ずっと無料で回り続ける」を優先して後者にしました。この“選び方”を考えること自体が、AIを道具として使ううえで大事な学びです。

素朴な疑問：ちゃんと動いたか、通知は来るの？

大吉くん
毎週7時に動くって言うけど…「動いたよ」ってメールが来るの？ 何も来ないと、ちゃんと動いてるのか不安なんだけど。

初期設定では、失敗したときだけメールが来ます。成功したときは、あえて何も来ません（毎週成功メールが来るとうるさいため）。「便りがないのは良い便り」という考え方です。

  • 成功の確認：GitHubの「Actions」タブを見ると、緑の✔と実行日時が並びます。リンク集の特典が増えていれば動いた証拠。
  • 失敗したとき：登録メールに「失敗しました」と届くので、そのとき初めて見にいけばOK。
もっと欲しければ、増やせる　「成功したときも通知がほしい」なら、GitHubの個人設定（Settings → Notifications → Actions）で成功通知をオンにできます。さらに作り込めば「○件追加したよ」とメールやLINEに送ることも可能。初期は失敗時だけ／欲しければオンにできる／作り込めば結果通知も──の3段で覚えておくと十分です。

このミッションのまとめ

やることのおさらい（この5つだけ）
  • 手順1　Gmailの鍵（アプリパスワード）を1個作る。名前は GMAIL_APP_PASSWORD（2段階認証オンが前提）
  • 手順2　その鍵を GitHub の金庫（Secrets）に GMAIL_APP_PASSWORD という名前で預ける
  • 手順3　AIエージェントに「集める仕組み＋特典の表示＋編集削除」を作ってもらう（プロンプトを貼るだけ。動かす時間＝cronもAIが設定）
  • 手順4　ちゃんと動くかテストする（AIに「テストして」と頼む or GitHubの Run workflow → 緑✔）
  • 手順5　ai-link.html を開き直して、特典が増えたか確認（いらないものは編集→削除）
この回の考え方のポイント
・Actions＝決まった時に・決まった作業を自動で動かすからくり
・基本はみんなができるように進める。ただし認証まわりで止まったら、当日は無理に追いかけず、教材を見て後から続きを進めてもOK
・自分でやるのは手順1・2まで。仕組み作り（プログラム・時間設定）は手順3でAIが全部やってくれる
・AIに頼むのは“作る”最初の1回だけ。毎週動くのはAI不使用のプログラム＝毎週の実行はコストゼロ（考える仕事 vs 盛り付け）
・鍵は Secrets（金庫）に預けて安全に。AIにもチャットにも貼らない
・確認は Actionsタブの緑✔。通知は初期設定だと失敗時だけ
CLEAR
これで commit / push / branch / PR / merge / Issue / Actions まで、GitHubの基本機能が一周そろいました。
「保存の場所」だった GitHub が、自分のために働いてくれる道具に変わりました。
3つのミッション、おつかれさまでした。今日触れた機能は、どれも 「自分のAIツールを育てていく」ための土台になります。気になったページは、いつでも戻ってきて見返してください。
教材 全6ページ（導入／Git・GitHubとは／ミッション1／M1の続き：branch・PR・merge／ミッション2：Issue／ミッション3：Actions）。3ミッション分そろいました。