私はゲーム個人開発でかなり以前からChatGPTを使っています。
使い始めた頃の開発方法は、かなり単純でした。
ChatGPTに設計を相談
↓
ChatGPTにコードを書いてもらう
↓
回答欄からコードをコピー
↓
Visual Studioなどのエディターへ貼り付け
↓
自分のPCでビルド・実行
↓
エラーが出たらChatGPTへ戻すChatGPTをコーディングに使っている人であれば、今でもこの方法を使っている人はかなり多いのではないかと思います。
その後Codexを使うようになり、「コードを実際に書き換える作業はCodex、通常のChatGPTは設計やGitHub上のコード調査」という使い分けをするようになりました。
実際、以前書いた「ChatGPTのGitHub連携でコードを読めない？インデックス未作成の対処法」でも、そのように紹介しています。
ところが別のゲームを開発している最中、少し不思議なことに気付きました。
Codexを使っていない普通のChatGPTなのに、GitHub側へ直接コードを書いていたのです。
設計後に「実装してください」と頼んだらGitHub側にコードができていた
現在開発しているゲームでは、まずChatGPTと仕様や設計について相談し、内容が固まってから実装を依頼しています。
ある段階で、いつものように設計を確認した後、ChatGPTへそのまま実装を依頼しました。
するとChatGPTから返ってきたのは、回答欄へ貼り付けるための大量のC#コードではありませんでした。
実装完了
Branch: ...
PR: ...
Merge commit: ...
Tests: ...という形で、GitHub上での作業結果が報告されました。
最初はあまり意識していなかったのですが、よく考えると以前とはかなり違います。
私はChatGPTからコードをコピーしていません。
自分で新しいソースファイルを作成したわけでもありません。
GitHubを確認すると、実際に実装用のブランチやPull Requestが作成されていました。
ローカルPCではGitHubから取得するだけ
さらに分かりやすかったのがローカルPC側です。
実装されたコードを確認するために行ったのは、ChatGPTの回答からコードをコピーすることではありません。
GitHubからブランチを取得して切り替えます。
git fetch origin
git switch --track -c feature/xxxxx origin/feature/xxxxxすると、すでに実装済みのコードがローカルへ降りてきます。
昔の私の使い方と比べると、かなり大きな違いです。
以前
ChatGPT
↓
コードを回答欄へ出力
↓
人間がコピー＆ペースト
↓
ローカルのソースコードを変更
現在の私の環境
ChatGPT
↓
GitHub上のコードを調査
↓
ブランチ作成
↓
ファイル作成・更新
↓
コミット
↓
Pull Request
↓
ローカルPCでfetch / switch
↓
実装済みコードを取得なぜ普通のChatGPTからGitHubを操作できるのか
ここで重要なのは、GPTというAIモデル自体が突然GitHubへ直接ログインできる能力を身につけた、という話ではないことです。
現在のChatGPTには、外部サービスと接続するためのアプリ、プラグイン、ツール、アクションといった仕組みがあります。
OpenAIの公式ヘルプでも、アプリはChatGPTやCodexを外部の情報だけでなく「アクション」に接続する仕組みとして説明されています。
また2026年7月9日からは、従来のアプリディレクトリがプラグインディレクトリへ移行し、ChatGPTとCodexのワークフロー機能をプラグインから利用する方向へ整理されています。
ChatGPT
↓
接続されたTool / App / Action
↓
GitHubなどの外部サービス
↓
許可された範囲の操作つまり、「ChatGPTは文章やコードを回答するだけのもの」という認識自体を、そろそろ更新した方がよさそうです。
ただし、OpenAI公式のGitHub App説明では今も「読み取り専用」
ここは非常に重要なので注意が必要です。
2026年8月30日時点のOpenAI公式ヘルプでは、通常のChatGPT GitHub Appについて「リポジトリの分析・検索を行うための読み取り専用」と説明されています。
さらに、コードを生成・編集し、GitHubへ直接pushする用途についてはCodexを使用するよう案内されています。
これは、今回私が実際に経験している動作と一見すると矛盾します。
実際の私のChatGPT環境では、Codexを使用していない通常のチャットから、GitHub上のファイル更新、ブランチ作成、コミット、Pull Request作成などの操作が行われています。
ただし、これが全ChatGPTユーザーへ同じ条件で提供されている機能なのか、どのアプリ・プラグイン・ツール経由で提供されているのか、あるいはプランや製品画面によって利用可否が異なるのかまでは、私の画面だけから断定できません。
OpenAI自身も、GitHubやプラグインの利用可能な機能はプラン、ワークスペース、製品画面、権限などによって異なる場合があると説明しています。
そのため、この記事では
ChatGPTなら誰でもCodexなしでGitHubへ書き込めるようになった
とは書きません。
確認できた事実は、あくまで
2026年8月30日時点の私のChatGPT環境では、Codexを使わず、通常のChatGPTからGitHubへの書き込み操作まで実際にできている
ということです。
ではCodexは不要になったのか？
ここはプログラミング初心者ほど誤解しやすいところだと思います。
ChatGPTからGitHubへコードを書けることと、Codexが不要になることは別の話です。
一番分かりやすい違いは、「GitHub上のファイルを操作すること」と「実際の開発環境でコードを動かして検証すること」は同じではない、という点です。
| 項目 | 通常ChatGPT＋GitHub操作 | Codex |
|---|---|---|
| 仕様相談・設計 | 得意 | 可能 |
| GitHub上のコード調査 | 可能 | 可能 |
| GitHub上のファイル更新 | 私の現在の環境では可能 | 可能 |
| ブランチ・コミット・PR | 私の現在の環境では可能 | 可能 |
| 実際の作業環境でコマンドを実行 | GitHub操作とは別 | 可能 |
| ビルド・テスト実行 | 基本的にユーザー側で確認 | 環境内で実行可能 |
| テスト失敗→修正→再テスト | 結果をChatGPTへ返して進める | 自分で反復しやすい |
例えば通常のChatGPTからGitHubへ実装してもらった場合、現在の私の開発では次のようになります。
ChatGPT
↓
GitHub上のコードを変更
↓
実装ブランチ作成
↓
ローカルPCへ取得
↓
Unity / Visual Studioなどで自分が確認
↓
エラーや動作結果をChatGPTへ返す
↓
必要ならGitHub側を再修正一方、Codexは作業環境の中でコードを編集し、利用可能な環境でビルドやテストを実行し、その結果を見てさらに修正する、といった開発作業をまとめて進めることができます。
Codex
↓
コード変更
↓
ビルド / テスト
↓
失敗
↓
エラーを解析
↓
再修正
↓
再テスト
↓
Pull Requestこの差はかなり大きいです。
そのため私は、「ChatGPTからGitHubへ書けるならCodexはいらない」とは考えていません。
設計や長い相談をしながら小～中規模の変更をGitHubへ反映し、最後の実機確認を自分で行うのであれば通常ChatGPTからのGitHub操作はかなり便利です。
一方、複数ファイルを大きく変更し、テストやビルドまで含めて反復的に実装してほしい場合は、Codexの方が適しています。
昔からChatGPTを使っている人ほど、一度「今できること」を確認した方がいい
今回一番伝えたかったのはここです。
私はChatGPTをゲーム開発に長く使っていたため、逆に昔の使い方が自分の中で常識になっていました。
ChatGPTはコードを考えてくれる
↓
実際にファイルへ反映するのは自分
または
実際の実装作業はCodexところが、いつの間にかChatGPTそのものが外部サービスの情報を読むだけではなく、許可されたアクションを実行するための仕組みを持つようになっています。
私自身、実装を依頼してGitHubからローカルへpullしたらすでにコードが出来上がっている、という状態を何度か経験するまで、この変化をきちんと認識していませんでした。
ChatGPTを1～2年前から使い続けている人ほど、一度現在利用できるアプリやプラグイン、接続サービスを確認してみてもよいと思います。
昔できなかったことが、今もできないとは限りません。
GitHubへ書き込める状態は今後も続くのか？
これは現時点では分かりません。
ChatGPT全体としては、外部サービスの情報を読み取るだけではなく、アクションを実行する方向へ機能が拡張されています。そのため「ChatGPTから外部サービスを操作する」という考え方自体がなくなる可能性は低いのではないかと私は考えています。
ただし、GitHubへの書き込みが今後も現在とまったく同じUI・同じプラン・同じ方法で利用できる保証はありません。
特に現在のOpenAI公式ヘルプでは、一般的なChatGPT GitHub Appは読み取り専用であり、コードの生成・編集・pushにはCodexが案内されています。
そのため私は、現在使えているGitHub書き込み機能だけを前提に開発環境を固定してしまうつもりはありません。
今後、通常ChatGPT側のGitHub操作がPluginや別の機能へ統合されたり、利用条件が変わったり、書き込み用途がCodexへ整理されたりする可能性はあります。
もし利用できなくなったとしても、その場合は公式にGitHubへのコード生成・編集・push用途として案内されているCodexへ戻せばよい、と考えています。
private repositoryで使う場合の注意
今回使用しているGitHubリポジトリはprivate repositoryです。
GitHub連携を使う場合は、ChatGPT側だけでなくGitHub側でどのリポジトリへのアクセスを許可しているかも確認しておいた方がよいと思います。
- 必要なリポジトリだけアクセスを許可する
- アクセストークンやAPIキーを会話・画像へ載せない
- いきなりmainへ変更せず実装用ブランチを使う
- Pull Requestのdiffを確認してからmergeする
- ローカルでビルド・テスト・実機確認を行う
- ブログなどへ画面を公開する場合はリポジトリ名、SHA、内部仕様など不要な情報を伏せる
AIが直接コードを変更できるようになるほど便利になりますが、その分「何を変更したのかを人間が確認する」工程はむしろ重要になります。
私が今後使おうと思っている流れ
現時点では、次のような流れが個人開発ではかなり使いやすいと感じています。
1. ChatGPTと仕様・設計を相談
2. GitHubの最新mainを確認してもらう
3. 実装方針を確定
4. feature branchへ実装
5. Pull Requestを作成
6. ローカルPCへ取得
7. ビルド・テスト・実機確認
8. 問題があればChatGPTへ結果を返して修正
9. 問題なければmerge大規模な変更や、自動的にテストと修正を反復してほしい作業ではCodexを使う。
仕様を詰めながらGitHub上のコードを確認し、そのまま比較的小さな実装まで進める場合は通常ChatGPTを使う。
今のところ、この使い分けが自分には合っています。
まとめ
以前の私は、「通常ChatGPTは設計やコード生成を行い、実際にコードを書くのは人間かCodex」という認識でした。
しかし2026年8月現在、私のChatGPT環境ではCodexを使わず、通常のChatGPTからGitHub上のファイル変更、ブランチ、コミット、Pull Requestなどの操作まで実際に行えています。
一方で、OpenAI公式の一般向けGitHub Appの説明では現在も読み取り専用とされ、コードの生成・編集・pushにはCodexが案内されています。
そのため「ChatGPTなら誰でもGitHubへ直接コードを書ける」と一般化することはできません。
それでも今回の経験から一つ確実に感じたのは、昔覚えたChatGPTの使い方を、そのまま現在の限界だと思わない方がよいということです。
特に今もChatGPTが出力したコードを毎回コピーしてエディターへ貼り付けている人は、一度自分の環境でGitHub連携や利用可能なプラグイン・アプリを確認してみる価値はあると思います。
なお、GitHub連携をしたのにChatGPTからコードをうまく検索できない場合については、以前の記事でGitHub Code Searchのインデックス確認方法をまとめています。
ChatGPTのGitHub連携でコードを読めない？インデックス未作成の対処法
※この記事は2026年8月30日時点で、私自身のChatGPT環境とprivate GitHub repositoryを使用して確認した実体験をもとにしています。ChatGPT、Codex、GitHub連携、Plugins / Appsの仕様や利用条件は今後変更される可能性があります。
コメント