【GitHub非エンジニア入門 3/5】編集・履歴・チーム共有｜ブラウザだけで使うGitHubコラボレーション

Part 2 では「自分1人で何かを保存する」レベルまで来ました。本記事はそこから一歩進めて、「同僚と一緒に1つのリポジトリを編集する」仕組みに入ります。GitHub の本領が発揮されるのはここからです。

本記事の中核は4つ──Collaborator招待・Issue・Pull Request・Discussions。それぞれに「いつ使うべきか」「使い分け」「実務での効きどころ」を整理します。

GitHubのチーム機能の本質は、「変更そのもの」と「変更にまつわる議論」が同じ場所に残ることです。Slackで議論し、Google Driveで編集し、メールで承認する──という分散型の業務を、GitHub上で1箇所に集約できます。

Collaborator として同僚を招待する

Private リポジトリは、デフォルトでは作成者しか見られません。同僚に編集してもらうには、明示的に招待する必要があります。

STEP 1　リポジトリの Settings タブ　リポジトリ画面の右上の方にあるタブから Settings を選びます。

STEP 2　左メニューの Collaborators　左の縦メニューから Collaborators をクリック。2FAを再認証するパスワード入力が求められることがあります。

STEP 3　Add people で同僚を招待　緑の Add people ボタン → 同僚のGitHubユーザー名 or メールアドレス を入力 → Send invitation。

招待された側はメール通知＋GitHub上の通知でリンクが届くので、それをクリックして承諾すれば共同編集者になります。承諾すると、両者がそのリポジトリの内容を見て、編集できる状態になります。

権限の違い（個人リポジトリの場合）

個人リポジトリでは、Collaboratorは「全権限を持つ協力者」になります（読むだけ・コメントだけのような権限分けはできません）。機密度の高いリポジトリは、信頼できる同僚にだけ招待するのが原則です。細かい権限管理は、Part 5 で扱う Organization リポジトリで実現します。

Issue──議題と質問の入口

Issue（イシュー）は、リポジトリ単位で立てる「議題ボード」です。Slackのスレッドや、メールの議題、付箋に書いたToDoのような役目をひとまとめにしたものです。

Issueでよくある使い方

• マニュアルの修正提案「このページの手順が古いです。〇〇に直してください」
• 質問「この用語の定義はどこにありますか？」
• タスク管理「今期中に追加するFAQ 5本」
• バグ報告（業務文書版）「規程の番号が重複している箇所があります」

Issueの立て方

1. STEP 1　リポジトリの上部タブから Issues を選択
2. STEP 2　右上の緑ボタン New issue
3. STEP 3　Title（議題タイトル）と本文を入力。Markdown が使えるので箇条書きや見出しもOK
4. STEP 4　右側のサイドバーで Assignees（担当者）と Labels（ラベル）を設定
5. STEP 5　緑ボタン Submit new issue で発行

Labels の効果的な使い方

Issueにはラベル（タグ）をつけて分類できます。よく使う組み合わせは次の通りです。

Issueを閉じる（Close）タイミング

議題の決着がついたら、Issueは Close ボタンで閉じます。閉じたIssueも検索可能なまま残り、過去の意思決定を辿る資料として残ります。「議論したけど決まらなかった」「保留」「対応見送り」も全部 Close で構いません。重要なのは 「未解決のIssueが滞留しないこと」です。

Pull Request──変更を提案して承認をもらう仕組み

Pull Request（プルリクエスト、略してPR）は、GitHubで最も独特で、最も強力な機能です。「リポジトリの本筋（main）に対する変更を、いきなり反映せず、まずレビューしてもらってから取り込む」仕組みです。

なぜ PR が必要か

Word文書を「お疲れ様です。マニュアル更新したので確認お願いします（最新版.docx）」とメール添付で送る運用、よくあります。これには問題が3つあります。

• 修正点が分かりにくい（差分は受け取った人が手動で探す）
• レビューコメントの履歴が残らない（メール本文に消える）
• 誰が承認したか後から追えない

PRはこれら3つを構造的に解決します。変更箇所が色付き（緑＝追加、赤＝削除）で表示され、レビュー指摘・承認の履歴がそのリポジトリに永続的に残るのです。

PR の流れ（5ステップ）

STEP 1　ブランチを作って変更する　ファイルを編集する画面で、コミット時に「Create a new branch for this commit and start a pull request」を選びます。例えば「fix-faq-typo」のようなブランチ名を入れて Commit。これで本流（main）には影響を与えず、別ブランチで変更だけが進みます。

STEP 2　Pull Request を開く　コミット直後、画面に「Pull Request を作りますか？」のバナーが出ます。Compare & pull request を押します。

STEP 3　説明文を書く　「何を変えたか」「なぜ変えたか」「レビュアーに見てほしいポイント」を書きます。空でも作れますが、説明があるほどレビューが速いです。テンプレ例。

## 変更内容
FAQの誤字を3箇所修正

## なぜ
営業から「読みづらい」とフィードバックがあったため

## レビューポイント
- 「お問合せ」→「お問い合わせ」の表記統一でOKか
- 各社向け文言が混在していないか

STEP 4　Reviewers を指定　右サイドバーの Reviewers で、レビューしてもらう同僚を指名します。指名されたメンバーには通知が飛びます。

STEP 5　レビューを受けて Merge　レビュアーが「Approve」（承認）してくれたら、緑の Merge pull request ボタンを押します。これで変更が main に統合されて、本流のリポジトリに反映されます。マージ後はブランチを削除して構いません（履歴は残ります）。

このPR運用は、最初は「面倒」に感じますが、3〜4回回すと「直接編集していたら絶対拾えなかった指摘」を1〜2件はもらえることに気づきます。これが組織の集合知が積み上がる仕組みです。

Reviewers と Comments──レビューの作法

レビューする側の操作も覚えておきます。指名された側で実際に行うアクション。

1. PRの Files changed タブで差分を見る（緑＝追加、赤＝削除）
2. 気になる行で ＋アイコンを押すとその行にコメントできる
3. 「Start a review」を選んで複数行にコメントしてから一括送信（おすすめ）
4. 右上の Review changes から、Comment（質問・意見だけ／承認はしない）／Approve（変更を承認／マージOK）／Request changes（修正を要求／マージ前に直してほしい）を選ぶ

レビューコメントのトーン

感情を抑えた、事実ベースの建設的な書き方がGitHubの文化です。日本語の社内運用でも次のテンプレが使えます。

• ×「ここダメじゃないですか？」
• ○「この箇所、〇〇規程の表現と合わせるなら『△△』が良さそうですが、いかがでしょうか」
• ×「もっと詳しく書いて」
• ○「このセクションの読者を経理担当者と想定すると、補足例があると判断しやすいかもしれません」

コメントは永続的に残るので、感情的な書き方は採用面接での評価にも影響しかねません。書き方の作法は組織の文化として最初に揃えておくと良いです。

Discussions──社内フォーラムとして使う

Issue が「具体的なタスク・問題」を扱うのに対して、Discussions は「もっとオープンな話題」を扱うフォーラム機能です。社内Slackの「相談チャネル」をGitHub上で持つようなイメージです。

Issue と Discussions の使い分け

Discussions を有効化する

新規リポジトリではデフォルトでオフになっています。Settings → General → Features → Discussions にチェックで有効化されます。チームに招待した直後に有効化しておくと、後から議論の置き場ができて便利です。

変更履歴（History）の読み方

GitHubの根幹は「履歴」です。リポジトリのファイル一覧画面で各ファイルを開くと、右上に History ボタンがあります。これがそのファイルの全変更履歴です。

履歴画面では次のことができます。

• 各コミットのメッセージと日時を一覧
• クリックすると、そのコミットでの「変更前→変更後」が色つきで表示
• 誰がそのコミットをしたか（アバター付き）
• 過去の任意のバージョンに戻ってファイルを見ることが可能

「3ヶ月前のマニュアルってどんな状態だったっけ」が、ボタン2回でわかります。Word文書の「変更履歴」とは比較にならないレベルで遡れる仕組みです。

Blame（ブレイム）──行単位で履歴を見る

ファイル右上の Blame ボタンを押すと、ファイルの各行が「いつ・誰が」書いたかを表示します。「この一文を書いたのは誰だっけ？」を即座に特定できる強力な機能です。

ちなみに「Blame（責める）」というネーミングは技術的な慣習で、責任追及のためではなく「経緯を追う」ために使うものです。社内文化としても、責める用途では絶対に使わないようにしてください。

通知の整え方──情報過多にならないために

GitHubのデフォルト通知は、メール＋ブラウザ＋アプリの3経路で来ます。チーム運用が進むと、1日に数十通の通知が来て「メールが埋もれる」状態になりがちです。

推奨設定

1. 右上アバター → Settings → Notifications
2. Watching の通知設定を「Participating, @mentions and custom」に変更（自分が関わるものだけ）
3. メール通知は「Pull Request reviews」「Direct mentions」だけにオン
4. その他の通知は GitHub内のNotificationタブでまとめて見る

メール通知が爆発する原因の多くが、「Watch」設定でリポジトリ全体を購読している状態です。慣れてきたら、本当に追いたいリポジトリだけ All Activity に上げて、それ以外は Participating だけにするのが続けやすい運用です。

公式ドキュメント・参考リンク

• Issues 完全ガイド（GitHub公式）──ラベル・マイルストーン・プロジェクトボードまで
• Pull Requests 完全ガイド（GitHub公式）──PR作法・レビュー作法の網羅版
• Discussions 公式ドキュメント──カテゴリ設計・通知制御の詳細
• Beginner's guide to GitHub: Creating a pull request（GitHub Blog）──スクショ豊富で初心者向け

Part 4 への橋渡し

Part 3 まで来たら、GitHubの基本動作はほぼマスターできています。Part 4 では、いよいよこの仕組みを使って 「AI用のコンテキストを社内で集約・活用する」具体的な実装に踏み込みます。Claude Code の CLAUDE.md、Cursor の .cursorrules、ChatGPT用のプロンプト集──こうしたAI関連ファイルをGitHubで管理する設計を、実例ベースで解説します。