こんにちは。本日はコードそのものではなく、普段使っているAIツールの使い方について、勢いで書いてみます。
個人開発をしていると、どうしても「要件を考える自分」「コードを書く自分」「レビューする自分」が同一人物になります。
当たり前のことなのですが、これが意外と地味にこたえます。
自分で決めた要件を自分で疑うのは面倒ですし、自分で書いたコードを自分でレビューすると、どうしても甘くなりがちです。
そこで最近試しているのが、
- ChatGPT：要件整理・Issue作成・PRレビュー
- Claude Code：設計・実装・テスト・修正
- GitHub：IssueとPull Requestによる共通インターフェース
という役割分担です。
結論からいうと、コード生成が速くなったこと自体よりも、
「何を作るか」「要件は正しいか」「AIの成果物を受け入れてよいか」
という、より上位の判断に自分の時間を使えるようになったことのほうが、個人的には大きなインパクトでした。
この記事では、この開発方法の具体的なつなぎ方と、実際に使って感じた限界について書いていきます。
結論：Human → 要件・レビューLLM → GitHub → 実装LLM
やっていることを図式化すると、こんな感じです。
Human ↓ ChatGPT （要件整理・レビュー） ↓ GitHub Issue / Pull Request ↓ Claude Code （設計・実装・テスト） ↓ GitHub Pull Request ↓ ChatGPT （レビュー） ↓ Human （最終判断・マージ）
ポイントは、ChatGPTとClaude Codeが直接会話しているわけではない、というところです。
両者はGitHubのIssueとPull Requestという、テキストベースの共通インターフェースを介してやり取りします。
これって、実は実務のチーム開発とかなり似た構造なんですよね。
Slackなどで会話しながら決めた内容を、最終的にはIssueやPull Requestとして記録する。
そのプロセスを、人間同士ではなくAIを含めた形で行っている、とも言えます。
1. 基本フロー：8ステップ
1. 人間とChatGPTで要件を整理する
「こういう機能が欲しい」「こういうバグがある」と、まずは雑にChatGPTへ投げます。
そこから対話しながら、
- 背景
- 要件
- 受け入れ条件
- スコープ外
などを整理していきます。
2. ChatGPTからGitHub Issueを作成する
整理した内容を、タイトル・背景・要件・受け入れ条件などを含むIssueとしてGitHubへ登録します。
自分の環境では、ChatGPT Codex Connector経由でGitHubへ書き込んでいます。
接続方法については後述します。
3. Claude CodeがIssueを読み、設計・実装・テストを行う
ローカルにcloneしたリポジトリ内でClaude Codeを起動し、Issue番号を指定して、
「Issue #XXを確認し、内容に沿って設計・実装・テストまで行ってください」
といった形で依頼します。
4. Claude CodeがPull Requestを作成する
Claude Codeがブランチを作成し、
- 実装
- テスト
- コミット
- push
まで行い、最後にPull Requestを作成します。
5. ChatGPTがIssueとPRの差分を見てレビューする
Issueで合意した要件と、実際の実装内容が一致しているかをChatGPTに確認してもらいます。
単なるコードスタイルではなく、
- 受け入れ条件を満たしているか
- 責務分離は妥当か
- テストが不足していないか
- 既存アーキテクチャを壊していないか
といった観点を明示してレビューを依頼します。
6. レビュー内容をGitHub上に残す
レビュー結果は、できる限りPull Request上のコメントとして残します。
ChatGPT内だけで会話を完結させず、IssueやPRへ記録を残しておくことが重要だと感じています。
7. Claude Codeがレビューコメントを読んで修正する
Claude CodeにPRのレビューコメントを確認させ、指摘事項を修正してもらいます。
修正後はテストを再実行し、必要に応じて追加コミットをpushします。
8. 再レビュー後、人間が最終判断してマージする
最後のマージだけは、現時点では意図的に自動化していません。
「7」と「8」の間に、さらにもう一往復レビューすることも普通にあります。
AIは指摘に対して過剰修正したり、意図を取り違えて別の箇所を変更したりすることがあります。
そのため、1回のレビューで綺麗に終わるとは考えないほうがよいと思います。
2. ChatGPTとGitHubの繋ぎ方
自分の環境では、ChatGPTとGitHubの連携には ChatGPT Codex Connector を利用しています。
この連携によって、ChatGPT / Codex側から対象のGitHubリポジトリを参照し、
- Issueの作成・更新
- Pull Requestの確認
- PRへのレビューコメント投稿
といった操作を行っています。
なお、ChatGPTにはGitHubリポジトリを検索・分析するためのGitHub連携もありますが、こちらは基本的に読み取り用途です。今回の記事で使っている、Issue作成やPRへの書き込みを含む開発フローではChatGPT Codex Connectorを利用しています。
以下は2026年8月時点で、自分の環境で設定した際の手順です。
接続手順
ChatGPTのCodex機能からGitHub連携を開始し、GitHub App「ChatGPT Codex Connector」をGitHubアカウントへ接続します。
ここで自分がつまずいたのが、GitHub Appには、
- Authorize
- Install
という別の手続きが存在する点でした。
ChatGPT側では接続済みに見えていても、GitHub側で対象リポジトリへのInstallが完了しておらず、リポジトリ一覧が0件になるケースがありました。
その場合はGitHubの
Settings → Applications
からChatGPT Codex Connectorを確認し、InstallまたはConfigureから対象リポジトリへのアクセスを設定します。
自分はAll repositoriesではなく、必要なリポジトリだけを選択しています。
接続後は、ChatGPT側から例えば、
「この内容をIssueとして登録してください」
「PR #XXをIssue #YYの受け入れ条件と照らしてレビューし、指摘をPRへコメントしてください」
といった形で依頼しています。
これによって、ChatGPT内だけでレビューを終わらせず、IssueやPRに結果を残す運用ができます。
なお、このあたりのUIやGitHub Appの接続方法は今後変更される可能性があります。本記事の内容は2026年8月時点で自分が利用している環境をベースにしています。
3. Claude CodeとGitHubの繋ぎ方
Claude Code側では、自分はローカル環境のgitとGitHub CLI（gh）を利用しています。
つまり、Claude Code専用のGitHub連携だけに依存するのではなく、普段人間が使っているGit/GitHub CLIの操作をClaude Codeに実行させる形です。
接続手順
まず、ローカル環境へGitHub CLIをインストールし、
gh auth login
でGitHubへ認証しておきます。
次に対象リポジトリをcloneします。
git clone git@github.com:your-name/your-repo.git cd your-repo
そのリポジトリ直下でClaude Codeを起動します。
claude
あとはClaude Codeに、
「Issue #XXを確認して実装してください。テストまで実施し、完了後にPRを作成してください」
と依頼します。
自分の環境では、Claude Codeが内部的に、
gh issue view gh pr create gh pr view --comments
などを使いながら、
- Issue確認
- ブランチ作成
- 実装
- テスト
- commit
- push
- Pull Request作成
- レビューコメント確認
- 修正
という流れを進めています。
認証はローカル環境のgh auth loginに紐づいているため、実際にどのGitHub権限で動くのかはローカル側の設定に依存します。
また、mainブランチへの直接pushやforce pushなどの破壊的な操作については、Claude Code側のパーミッション設定で確認を挟むようにしています。
GitHub MCPサーバーを利用する方法もあります。
ただ、自分の用途ではIssueやPull Requestの読み書き程度であれば、現状ghコマンドを利用するだけでも十分に動かせています。
複数リポジトリを横断した操作や、より高度なGitHub連携を行いたい場合は、MCPを検討してもよいと思います。
4. なぜ別のLLMに分けるのか
同じLLMに、
- 要件整理
- 実装
- レビュー
まで全部やらせることもできます。
Claude Code単体でも、「実装して、その後レビューして」と頼めば一応できます。
それでも自分がChatGPTとClaude Codeに役割を分けているのは、
実装したモデルとは別のモデルにレビューさせることで、独立した視点を入れられるのではないか
という仮説があるからです。
これは人間のコードレビューでも、
「自分で書いたコードを自分でレビューするより、別の人に見てもらう」
ことに近い考え方です。
実装した文脈を持っているモデルにレビューさせると、「なぜこう実装したか」という前提を共有しているぶん、その前提自体を疑う視点が弱くなる可能性があります。
一方、Issueの受け入れ条件とPRの差分を中心に別モデルへ渡すと、
「この実装は本当に要件を満たしているか」
という比較的フラットな視点で見てもらえることがあります。
また、異なるモデルであれば学習やチューニングの傾向も異なるため、片方が見落とした観点をもう片方が拾うケースも実際にありました。
ただし、
別LLMにすれば必ず品質が上がる
という話ではありません。
ChatGPTのレビューが的外れなこともありますし、Claude Codeの実装をChatGPTが誤読して、見当違いの指摘をすることもあります。
両方とも間違える前提で利用する必要があります。
結局のところ、
最終的に差分を確認し、マージしてよいか判断するのは人間
という最後の砦を外さないことのほうが、モデルの組み合わせそのものより重要だと感じています。
現在、自分は
- 要件・レビュー：ChatGPT
- 設計・実装・テスト：Claude Code
という構成で使っています。
逆に、
- 要件・レビュー：Claude
- 設計・実装・テスト：Codex
といった構成も当然あり得ると思います。
こちらは自分ではまだ試していません。
実際に別の組み合わせで運用されている方がいれば、ぜひお問い合わせから教えていただけると嬉しいです。
やってみて思ったこと
良かった点は、自分の作業が、
「コードを書く」
ことから、
「Issueの受け入れ条件を決める」
「PRの差分とレビューコメントを読んで妥当性を判断する」
ことへシフトした点です。
作業時間そのものが必ずしも減ったわけではありません。
ただ、頭を使う場所が、より上位の判断へ移った感覚があります。
また、GitHubにIssueとPull Requestという記録が残るため、後から、
「なぜこの実装になったのか」
を辿れる点も地味に便利です。
ChatGPTとのチャットだけで話を終わらせず、必ずIssueやPull Requestという形に落とす。
この制約自体が、良い副作用を生んでいると感じています。
一方で、詰まった点もあります。
ChatGPT Codex Connectorでは、「接続済みなのにリポジトリが見えない」というAuthorize / Install周辺の問題に遭遇しました。
手順を知っていれば解決できますが、知らないと「連携したのに使えない」と感じるポイントだと思います。
また、ChatGPTへ単純に「レビューして」と依頼すると、命名や体裁など比較的表面的な指摘に寄ることもありました。
そのため現在は、
「このIssueの受け入れ条件を満たしているか」
「既存のアーキテクチャ制約に違反していないか」
「テストで確認できていない境界条件はないか」
など、レビュー観点を明示するようにしています。
丸投げすれば完璧にレビューしてくれる、というものではありません。
まとめ
Coding Agentの価値は、単にコード生成が速くなることだけではないと思っています。
GitHubのIssueとPull Requestを媒介にすれば、
Human ↓ 要件・レビューLLM ↓ GitHub ↓ 実装LLM ↓ GitHub ↓ レビュー ↓ Human
という開発プロセスを、個人開発でも組み立てられます。
AIがGitHubのIssueやPull Requestまで扱えるようになったことで、一人開発でも、
- 要件担当
- 実装担当
- テスト担当
- レビュー担当
を疑似的に分離できるようになりました。
その一方で、AIは速いものの、普通に間違えます。
だからこそ、
「どこまでAIに任せ、どこで人間が判断するか」
を最初に決めておく必要があると感じています。
自分の場合は、レビューが一往復した後でも、最終的なマージだけは必ず自分で確認して判断する、というルールにしています。
AIに全部任せるのではなく、GitHubという共通インターフェースの上で、人間と複数のAIの役割を設計する。
現時点では、このくらいの距離感が個人開発にはちょうどよいのではないかと思っています。
最後まで読んでいただき、ありがとうございました。
最後まで読んでいただきありがとうございます。ご質問やコメントはお問い合わせからよろしくおねがいします。