Codexを使い始めた人向けGitHub入門：リポジトリ作成からPull Requestまで
作成日:2026.08.10
Windows版ChatGPTデスクトップアプリのCodexを主な例として、GitHubのアカウント・リポジトリ作成から、作業用ブランチでの変更、commit・push、Pull Request、mergeまでの流れを解説します。GitやGitHubの基本用語を丁寧に説明し、Codexの変更内容を確認してから反映するための注意点も紹介します。
目次
今回は、Windows版のChatGPTデスクトップアプリで利用するCodexを主な例として、GitHubのアカウント作成とリポジトリ作成から、Codexで変更を行い、Pull Requestを作成するまでの流れを整理します。
GitHubのすべての機能を説明するのではなく、コーディングエージェントを使い始めた人が、変更内容を確認しながら作業するために必要な基本へ絞ります。
前提
この記事では、次の環境を想定します。
- GitHubのアカウントを作成できる
- Windows版のChatGPTデスクトップアプリを利用する
- Codexを利用できる
- GitやGitHubを詳しく知らない
ChatGPTデスクトップアプリのWindows版には、プロジェクトの操作、Git機能、ファイルの確認、PowerShellなどの統合ターミナルが用意されています。利用できる機能や表示は、アプリのバージョン、アカウント、設定によって変わる可能性があります。現在の対応状況はChatGPTデスクトップアプリのWindows公式ドキュメントを確認してください。
今回の例では、公開しても問題のない小さなサンプルプロジェクトを使います。APIキー、パスワード、秘密鍵、個人情報を含む実際のプロジェクトで試す場合は、先に情報の扱いと権限を確認してください。
GitHubを使う理由
GitHubは、ソースコードや文書を保存し、変更履歴を確認したり、他の人にレビューしてもらったりするためのサービスです。
Codexへ変更を依頼すると、複数のファイルが追加・変更される場合があります。変更前の状態を残し、変更内容を比較できるようにしておくと、意図しない修正を見つけやすくなります。
GitHub公式のHello Worldでも、リポジトリ、ブランチ、commit、Pull Request、mergeという流れでGitHubの基本を説明しています。
最初に覚えるGitHubの用語
最初からGitの仕組みをすべて理解する必要はありません。まずは、変更がどこにあるのかを区別できれば大丈夫です。
| 用語 | 意味 |
|---|---|
| リポジトリ | プロジェクトのファイルと変更履歴を管理する場所 |
| ローカル | 自分のパソコンにある作業場所 |
| ブランチ | 同じプロジェクトの中で、変更を分けて作業する場所 |
| commit | 変更内容を一つの履歴として保存すること |
| push | ローカルに保存したcommitをGitHubへ送ること |
| Pull Request | 変更を取り込む前に、差分を確認・レビューしてもらうための依頼 |
| merge | Pull Requestの変更を取り込み先のブランチへ反映すること |
GitHubへ変更を反映する流れは、次のようになります。
- GitHubにリポジトリを作成する
- Codexアプリへプロジェクトを追加する
- 作業用ブランチでCodexに変更を依頼する
- 変更内容を確認する
- commitとpushを行う
- Pull Requestを作成する
- レビュー後にmergeする
commitやpushを行う前に、変更内容を確認することが重要です。
GitHubのアカウントを作成する
まず、GitHubの公式サイトでアカウントを作成します。
GitHubの画面や料金、メールアドレスの確認方法などは変更される可能性があるため、画面の案内に従って登録してください。
公開用のユーザー名やプロフィール名には、実名を使う必要はありません。ただし、仕事や共同開発で使う場合は、他の人が識別しやすい名前にしておくとよいと思います。
GitHubにリポジトリを作成する
GitHubへログインしたら、リポジトリを作成します。リポジトリは、プロジェクトのファイルと変更履歴を管理する単位です。
GitHubの画面で新しいリポジトリを作成し、次の内容を設定します。
- リポジトリ名
- 公開または非公開
- READMEを最初から作成するかどうか
- ライセンスや.gitignoreを追加するかどうか
公開・非公開を選ぶ
初めて試す場合は、公開しても問題のないサンプルだけを使うか、非公開リポジトリを選びます。
非公開にした場合でも、アクセス権を持つサービスやユーザーからは内容を参照できる可能性があります。非公開だから秘密情報を保存してよい、という意味ではありません。
READMEを追加するかどうか
GitHub上で新しくプロジェクトを始める場合は、READMEを追加しても構いません。一方、既にローカルにあるプロジェクトをGitHubへ登録する場合は、ローカル側にもREADMEがあると、最初のpushで履歴が分かれることがあります。
既存プロジェクトを登録する場合は、空のリポジトリを作成してからローカルプロジェクトを接続する方が分かりやすい場合があります。どちらを選ぶかは、プロジェクトの状態に合わせて決めてください。
リポジトリを作成したら、リポジトリのURLを確認します。このURLは、ローカルのプロジェクトとGitHub上のリポジトリを接続するときに使います。
Codexアプリへプロジェクトを追加する
次に、ChatGPTデスクトップアプリを起動して、Codexで作業するプロジェクトを追加します。
アプリのプロジェクト追加画面から、ローカルにあるプロジェクトのフォルダーを選択します。既存のプロジェクトがない場合は、Codexへ新しいプロジェクトを作成してもらう方法もあります。
GitHubで作成したリポジトリをまだローカルへ用意していない場合は、GitHubのリポジトリ画面に表示される案内からcloneします。Codexアプリのプロジェクト追加画面にcloneの項目が表示される場合は、その案内を利用してください。表示されない場合は、統合ターミナルで次のコマンドを実行し、作成されたフォルダーをプロジェクトとして追加します。
git clone https://github.com/OWNER/REPOSITORY.gitこの記事では、GitHubに作成したリポジトリをローカルへcloneし、そのフォルダーをCodexアプリで開く流れを想定します。
Windows版のアプリは、PowerShellを使ってローカルのプロジェクトを操作できます。プロジェクトの保存場所や、PowerShellとWSLのどちらで作業するかは、最初に確認しておきましょう。
また、Codexにはサンドボックスや承認に関する設定があります。公式ドキュメントでも、完全なアクセス権を与えるとプロジェクト外のファイルへアクセスしたり、意図しない破壊的な操作を行ったりする可能性があると説明されています。必要な範囲の権限に絞り、内容を確認してから承認してください。
最初に確認すること
プロジェクトを追加したら、いきなり変更を依頼せず、まず次のように確認します。
このプロジェクトの構成を説明してください。
まだファイルは変更しないでください。
次の内容を確認したいです。
- 主なディレクトリとファイル
- 起動やテストに必要なコマンド
- Gitの現在のブランチ
- 未commitの変更
- プロジェクト内の開発ルールこの依頼では、Codexにファイルを変更させず、プロジェクトの状態を把握させます。既に変更が残っている場合は、何の変更か確認してから次へ進みます。
作業用ブランチを用意する
GitHubのリポジトリには、最初からmainという名前のブランチが用意されることが多いです。mainは、完成した内容を置く基準ブランチとして扱います。
Codexに変更を依頼するときは、mainへ直接変更を加えるのではなく、作業用のブランチを使います。作業用ブランチを使うと、変更途中の状態を基準ブランチから分けて管理できます。
CodexアプリでGit操作を画面から行える場合は、現在のブランチを確認してから、作業用ブランチを作成します。画面の項目名や操作方法が異なる場合は、アプリに表示される案内を確認してください。
画面操作でブランチを作成できない場合は、アプリの統合ターミナルから次のコマンドを実行します。
git switch -c feature/readme-updatefeature/readme-updateは、READMEを更新する作業用ブランチの例です。ログイン機能の追加ならfeature/add-login、不具合修正ならfix/login-errorのように、作業内容が分かる名前を付けます。
Codexに変更を依頼する
今回は、READMEへローカル環境の起動手順を追加する例にします。いきなり編集を依頼するのではなく、最初に変更方針を確認します。
READMEにローカル開発環境の起動手順を追加したいです。
まず、READMEとプロジェクトの設定ファイルを確認し、
次の内容を説明してください。
- 現在のREADMEの構成
- 既に記載されている起動手順
- 追加する場所
- 変更するファイル
- 確認が必要なコマンド
この段階ではファイルを変更しないでください。Codexの説明を確認し、変更範囲や起動方法に問題がなければ、編集を依頼します。
先ほどの方針でREADMEを変更してください。
- 変更するファイルはREADMEだけにする
- 既存の説明は必要以上に書き換えない
- プロジェクトの設定と一致するコマンドだけを記載する
- 変更後に、変更したファイルと確認した内容を説明する
- 私が確認するまでcommit、push、Pull Requestの作成は実行しない変更するファイルと、実行してよい操作を明示しておくと、作業範囲を確認しやすくなります。不明点がある場合は、推測で進めず質問するよう依頼しておくとよいと思います。
変更内容を確認する
Codexが変更した後は、Codexの説明だけで判断せず、アプリの差分表示や変更ファイルの一覧を確認します。
Codexの公式資料でも、変更を作成した後に結果や差分を確認し、必要な変更だけを採用する流れが案内されています。Codexアプリでも、表示される変更内容と対象ファイルを確認してから次の操作へ進めます。
次の点を確認します。
- 依頼したファイルだけが変更されているか
- 既存の説明や処理が意図せず削除されていないか
- コマンドやファイルパスに誤りがないか
- 文字化けや記述崩れがないか
- APIキー、パスワード、秘密鍵などが含まれていないか
- 必要なテストや動作確認が行われているか
Codexへ次のように、レビューだけを依頼することもできます。
この変更をレビューしてください。
まだファイルは変更しないでください。
次の観点で確認してください。
- 依頼した内容と変更内容が一致しているか
- 変更範囲が広がりすぎていないか
- 既存機能を壊す可能性がないか
- テストや動作確認が不足していないか
- 秘密情報が含まれていないか
問題があれば、対象ファイル、理由、修正案を説明してください。レビュー結果は確認項目を洗い出すために使います。Codexが問題ないと説明しても、最終的には人が差分と動作を確認します。
commitとpushを行う
変更内容に問題がなければ、変更をcommitしてGitHubへpushします。
commitは、変更内容をローカルの変更履歴へ保存する操作です。pushは、そのcommitをGitHubへ送信する操作です。commitしただけでは、GitHubへ変更が送信されたとは限りません。
CodexアプリでGit操作を画面から行える環境では、変更ファイル、commitメッセージ、ブランチ、送信先を確認してから実行します。
画面から操作できない場合は、統合ターミナルで必要最小限のコマンドを実行します。
git status
git add README.md
git commit -m "READMEに起動手順を追加"
git push -u origin feature/readme-updateこのコマンドを実行する前に、git statusで対象ファイルを確認してください。git add .を使うと、意図していない一時ファイルや設定ファイルまでcommit対象になる可能性があります。
pushする前には、作業用ブランチにいることと、送信先のリポジトリが正しいことを確認します。
Pull Requestを作成する
pushが完了すると、作業用ブランチの変更をGitHub上で確認できるようになります。次に、作業用ブランチからmainへ変更を取り込むためのPull Requestを作成します。
Pull Requestは、変更を取り込んでよいか確認してもらうための依頼です。Pull Requestを作成しただけで、mainへ変更が反映されるわけではありません。
GitHubのPull Request作成画面では、次の項目を確認します。
- baseが変更を取り込むブランチになっているか
- compareが作業用ブランチになっているか
- 変更ファイルが依頼した範囲に収まっているか
- 変更内容を説明できるタイトルになっているか
- テストや動作確認の結果を記載しているか
説明欄には、例えば次のような内容を書きます。
READMEにローカル開発環境の起動手順を追加しました。
確認した内容:
- READMEの変更内容
- Codexが変更したファイル
- 起動手順に記載したコマンド
未確認事項:
- 実際のアプリケーション起動GitHub公式のPull Requestクイックスタートでも、ブランチを作成し、変更をcommit・pushした後にPull Requestを作成し、レビューとmergeを行う流れが説明されています。
レビュー後にmergeする
Pull Requestの差分を確認し、問題がなければmergeします。自分一人で使うリポジトリでも、Pull Requestを作成してからmergeする流れを使うと、変更内容を後から確認しやすくなります。
レビューで修正が必要になった場合は、同じ作業用ブランチでCodexに修正を依頼します。修正後にcommitとpushを行うと、既存のPull Requestへ変更が追加されます。
変更範囲が大きくなった場合や、最初の目的と別の作業が混ざった場合は、別のブランチとPull Requestに分けた方がレビューしやすくなります。
Pull Requestをmergeした後は、作業用ブランチを削除するかどうかを判断します。後から同じ作業を続ける場合は、基準ブランチを最新状態にしてから新しい作業用ブランチを作成します。
安全に使うための注意点
mainへ直接変更を加えない
作業用ブランチを使うと、変更途中の内容をmainから分けて管理できます。小さな変更でも、Codexが複数のファイルを変更する可能性があるため、まず作業用ブランチを使う方が安心です。
変更ファイルを確認する
Codexの回答に「READMEだけを変更した」と書かれていても、実際の変更ファイル一覧を確認してください。説明と差分が一致しない場合は、commitやpushを進めずに原因を確認します。
秘密情報を保存しない
APIキー、パスワード、秘密鍵、個人情報を、ソースコードやREADMEへ記載しないでください。GitHubから削除しても、過去のcommitに残っている可能性があります。
権限を必要以上に広げない
Codexアプリのサンドボックスや承認設定は、プロジェクトの内容に合わせて選びます。プロジェクト外のファイルを変更する必要がないなら、広い権限を与えない方が安全です。
AIのレビューだけでmergeしない
Codexは変更内容の説明やレビューを支援できますが、要件を満たしているか、利用者にとって問題がないかまで自動で保証するものではありません。差分、テスト結果、実際の動作を確認してからmergeします。
GitHubとGitは別のもの
Gitは変更履歴を管理する仕組みで、GitHubはGitリポジトリを保存し、Pull Requestなどの共同作業機能を提供するサービスです。
ローカルでcommitしただけではGitHubへ送信されず、pushしただけではレビューが完了したわけでもありません。それぞれの操作が何を意味するのかを意識すると、今どの段階にいるのか分かりやすくなります。
まとめ
今回は、GitHubのアカウントとリポジトリを作成し、Codexアプリで変更を依頼してからPull Requestを作成するまでの流れを整理しました。
最初に覚える用語は、リポジトリ、ブランチ、commit、push、Pull Request、mergeです。これらの関係が分かると、変更をどこで確認すればよいか判断しやすくなります。
Codexへ変更を依頼するときは、作業範囲と実行してよい操作を明示します。変更後は、Codexの説明だけで判断せず、変更ファイル、差分、テスト結果、秘密情報の有無を確認します。
AIに実装を任せる範囲が広くなっても、変更を採用するかどうかの判断まで任せる必要はありません。作業用ブランチとPull Requestを使い、変更内容を確認しながら進めるのがよいかと思います。
奈良市を拠点に、27年以上の経験を持つフリーランスWebエンジニア、阿部辰也です。
これまで、ECサイトのバックエンド開発や業務効率化システム、公共施設の予約システムなど、多彩なプロジェクトを手がけ、企業様や制作会社様のパートナーとして信頼を築いてまいりました。
【制作会社・企業様向けサポート】
Webシステムの開発やサイト改善でお困りの際は、どうぞお気軽にご相談ください。小さな疑問から大規模プロジェクトまで、最適なご提案を心を込めてさせていただきます。
ぜひ、プロフィールやWeb制作会社様向け業務案内、一般企業様向け業務案内もご覧くださいね。
ChatGPT・GitHub・Codexで設計から実装・レビューまで進める方法
2026.08.09
Codexにいきなりアプリ開発を依頼するのではなく、ChatGPTで設計と作業分解を行い、GitHub Issueへ整理してからCodexで実装する流れを紹介します。pushやPull Request、レビュー、手戻りとトークン消費を抑える考え方も説明します。
Windows版Codexで「CreateProcessAsUserW failed: 5」が出たときのPowerShell確認と対処
2026.08.07
Windows 11のCodexで、Get-Contentなどの読み取りコマンド実行時に「CreateProcessAsUserW failed: 5」が発生した事例をもとに、エラー内のpwsh.exeのパスやwhere.exe pwsh、Get-Commandの結果を確認し、PowerShellの導入形態を見直して改善するまでの切り分け手順を紹介します。
CodexのAGENTS.mdとSkillsを使い分けて開発ルールを整える
2026.08.04
Codexを継続的な開発に活用するために、プロジェクト全体の前提や規約をAGENTS.mdへ、文書更新・実装・テストなどの作業手順をSkillsへ分けて記述する方法を紹介します。実際の運用例をもとに、ルールを少しずつ育てる考え方も整理します。
Windows 11でCodexを使い分ける：VS Code拡張・アプリ・CLIの違い
2026.08.03
Windows 11でCodexを使う場合の、VS Code拡張、Codexアプリ、CLIの使い分けを紹介します。既存プロジェクトの修正には、コードや差分を確認しやすいVS Code拡張が向いています。一方、新規プロジェクトのMVPをまとめて作る場合は、CodexアプリまたはCLIが便利です。Gitのcommitやpushを行う前に確認すべきポイントも説明します。