GitHubのForkとPull Request：AI/Codex作業を安全に提案する流れ

AIやCodexに修正を頼むと、短時間で複数ファイルが変わります。その変更をいきなり本体リポジトリや本番サイトへ入れるのではなく、Fork、ブランチ、Pull Requestで一度分けると、差分確認とレビューがしやすくなります。

この記事では、ForkとPull Requestの基本に加えて、AI/Codexが出した変更を安全に提案するために、作業範囲、差分、戻し方、レビュー依頼文をどう整理するかを説明します。

なぜForkが必要？直接pushできない理由

当然のことですが、あなたは他人のGitHubリポジトリに直接コードをプッシュ（アップロード）することはできません。もし誰でも自由に書き込めたら、プロジェクトはめちゃくちゃになってしまいますよね。これは、あなたが家の鍵を持っていない他人の家に入って、勝手に模様替えができないのと同じです。

では、どうすれば他人のプロジェクトに貢献できるのでしょうか？その答えが「Fork」です。

Forkとは、他人のリポジトリを、自分のGitHubアカウント上に丸ごとコピーして、自分専用の保管場所（リモートリポジトリ）を作成する機能です。自分の家に持ち帰って、自由に作業するための「自分用の写し」を作るイメージです。あなたはその自分用のリポジトリに対しては、完全な書き込み権限を持っています。

そして、自分用のリポジトリで行った修正を「こんな変更はどうですか？」と元のプロジェクトに提案する仕組みが「Pull Request」なのです。

Fork & Pull Requestの全体像

実際にコマンドを打つ前に、全体の流れを把握しておきましょう。オープンソースプロジェクトに貢献する際の典型的なフローは、以下の6つのステップで構成されます。

1. Fork: 元となるプロジェクトを、自分のGitHubアカウントにコピーする。
2. Clone: Forkして作成された「自分用の」リポジトリを、自分のPCにコピーする。
3. Branch: 修正作業を行うための新しいブランチ（枝）を作成する。
4. Modify & Commit: 自分のPCでコードを修正し、変更内容をコミットする。
5. Push: コミットした内容を、「自分用の」GitHubリポジトリにプッシュする。
6. Pull Request: 自分のリポジトリから元のプロジェクトへ、「この変更を取り込んでください」というリクエストを送る。

この流れを図にすると、以下のようになります。

[図解：1. 元のリポジトリ →(Fork)→ 2. 自分のGitHubリポジトリ →(Clone)→ 3. 自分のPC →(Push)→ 4. 自分のGitHubリポジトリ →(Pull Request)→ 5. 元のリポジトリ、という流れを示す図]

3つの場所を混同しない

Fork作業で一番多い混乱は、どのリポジトリを触っているか分からなくなることです。作業中は、次の3つを分けて考えてください。

• 元のリポジトリ: 変更を取り込んでもらいたい本体
• 自分のFork: 自分がpushできるGitHub上のコピー
• ローカルリポジトリ: 自分のPC内で編集する作業場所

作業前後に git status と git remote -v を見ると、今どこへpushする設定なのか確認できます。

git status
git remote -v
git branch

実践！オープンソースプロジェクトに貢献する手順

では、具体的な手順を追っていきましょう。練習として、まずは簡単なtypo（誤字脱字）の修正を提案する、というシナリオで進めていきます。

ステップ1: 貢献したいリポジトリをForkする

まず、貢献したいプロジェクトのGitHubページを開きます。ページ右上に表示されている「Fork」ボタンをクリックしてください。

[画像：GitHubのプロジェクトページにある「Fork」ボタンを指している様子]

「Create a new fork」という画面が表示されるので、リポジトリ名などを確認し、「Create fork」ボタンを押します。少し待つと、あなたのGitHubアカウント内に、そのリポジトリの完全なコピーが作成されます。

[画像：Fork作成後の自分のアカウント上にあるリポジトリ画面。URLが自分のユーザー名になっていることがわかる]

ステップ2: Forkしたリポジトリを`clone`する

次に、先ほどForkして作成した「あなたのアカウント上にある」リポジトリを、ローカルPCに`clone`します。元のリポジトリではなく、必ず自分がForkしたリポジトリのURLをコピーする点に注意してください。

git clone git@github.com:あなたのユーザー名/forkしたリポジトリ名.git

ステップ3: 作業用のブランチを作成する

クローンしたフォルダに移動し、これから行う修正作業のための新しいブランチを作成します。元の`main`ブランチを直接汚さずに、専用の作業場で作業を行うのがマナーです。`checkout -b`を使うと、ブランチの作成と移動を同時に行えます。

cd forkしたリポジトリ名

git checkout -b fix-typo-in-readme

ステップ4: コードを修正し、`commit` & `push`する

ローカルPCで、`README.md`などのファイルを開き、誤字を修正するなど、何らかの変更を加えて保存します。変更が終わったら、これまで学んだ通り`add`と`commit`で変更を記録します。

git add .

git commit -m "Fix a typo in README.md"

最後に、このコミットを**自分のリモートリポジトリ（Forkしたもの）**にプッシュします。このとき、作成したブランチ名を指定するのを忘れないでください。

git push origin fix-typo-in-readme

ステップ5: Pull Requestを作成する

いよいよクライマックスです。ブラウザで、**あなたのForkしたリポジトリ**のページを開き直してください。すると、「'fix-typo-in-readme' had recent pushes」という黄色い通知と、「Compare & pull request」という緑色のボタンが表示されているはずです。このボタンをクリックしましょう。

[画像：Forkしたリポジトリに表示される「Compare & pull request」ボタン]

「Open a pull request」というページに移動します。ここで、あなたの変更内容を元のプロジェクトに取り込んでもらうための依頼状を作成します。

• Title (タイトル): 変更内容が簡潔にわかるタイトルを付けます。（例: `Fix a typo in the introduction`）
• Leave a comment (コメント): なぜこの変更を行ったのか、どんな修正をしたのかを丁寧に説明します。これがレビューしてくれる相手への礼儀です。

[画像：Pull Requestの作成画面。タイトルと説明文の入力欄が強調されている]

内容を確認し、「Create pull request」ボタンを押せば、あなたの提案が元のリポジトリの管理者に送信されます。

Pull Requestを出す前の確認リスト

PRは相手にレビューしてもらう依頼です。変更内容が小さく、理由が分かり、確認済みであるほど取り込まれやすくなります。

• git status で不要なファイルが混ざっていないか確認する
• git diff で自分の変更内容を読み直す
• 1つのPRに無関係な修正を混ぜない
• タイトルに「何を直したか」を短く書く
• 本文に「なぜ直したか」「どう確認したか」を書く

チーム開発では、PRの前にブランチ名を揃えると管理しやすくなります。命名の考え方は Gitブランチ運用の基本 で確認できます。

AI/Codex作業でPRを使う時の確認

AIやCodexの変更は、本人が意図していないファイルまで広がることがあります。PRを作る前に、変更範囲を人間が読める形に整理してください。

git status
git diff --stat
git diff
git log --oneline -5

• 関係ないファイルが混ざっていたら、PRに入れる前に分ける
• deploy.local.ps1、APIキー、DB設定、tokenなどの秘密情報が入っていないか確認する
• 削除された行が多い時は、なぜ消えたのか説明できるまで止める
• PHPやHTMLを変えた場合は、構文チェックとローカル表示確認を書く
• 本番へ上げる予定があるなら、アップロード対象ファイルをPR本文にも残す

PR本文に書くこと

PR本文は、未来の自分やレビューする人が「この変更を入れてよいか」を判断するためのメモです。AI/Codex作業では、特に確認済みのことを明確にします。

## 変更内容
-

## 変更した理由
-

## 確認したこと
- PHP構文チェック:
- ローカル表示:
- 変更ファイル:
- 本番へアップロードするファイル:

## 注意点
- 秘密情報は含めていません。
- 戻す場合はどのファイルを戻すか:

ステップ6: レビューとマージ（を待つ）

Pull Requestが作成されると、元のリポジトリの管理者に通知が届きます。管理者はあなたのコードを確認し、コメントを付けたり、追加の修正を依頼したりすることがあります。やり取りを経て、変更内容に問題がなければ、管理者があなたのPull Requestをマージ（取り込み）してくれます。

[画像：自分のPull Requestが「Merged」と表示され、紫色のアイコンになっている様子]

マージされた瞬間、あなたの修正が正式にプロジェクトの一部となります。おめでとうございます！これがオープンソースへの貢献です。

やってはいけないPull Request

• AIが変更した全ファイルを確認せず、そのままPRにする
• 1つのPRに、デザイン修正、SEO修正、DB変更、設定変更を全部混ぜる
• 秘密情報やローカル専用ファイルを含める
• 本番へ上げる予定なのに、アップロード対象を書かない
• レビュー指摘を受けた後、どの差分が追加されたか確認しない

AIやCodexにPR前確認を頼むメモ

PRを作る前に不安な場合は、次のメモをCodexやAIに貼って、差分確認と危険なファイルの有無を見てもらいます。秘密情報そのものは貼らないでください。

Pull Requestを作る前の確認をしたいです。

目的:
-

変更したファイル:
-

確認してほしいこと:
- 関係ないファイルが混ざっていないか
- 削除や上書きが危険ではないか
- 秘密情報やローカル専用ファイルが含まれていないか
- PR本文に書くべき確認項目
- 本番へアップロードする必要があるファイル

注意:
- 秘密情報、APIキー、DBパスワード、tokenは貼りません。
- 必要なら、差分の要約だけを貼ります。

本番公開前の導線

PRを作るだけでは、本番サイトが安全に更新されるわけではありません。マージ後や公開前には、差分、戻し方、アップロード先をもう一度確認します。

• AIコードを本番に入れる前後の安全確認入口
• Codexへ渡す作業範囲を整理する
• AIコード差分を確認するメモメーカー
• ロリポップで自作PHPサイトを安全に更新する入口
• Gitで変更を戻す前に確認すること