GitHub作業は複数画面で速くなる
repo、差分、指示、公開URL、Search Consoleを行き来する作業では、複数画面を同時に開けることが効きます。
repo、PR、差分、公開URLを同時に見る
GitHubに保存した変更、Codexの作業内容、FTP反映、公開URL確認を並べると、どこまで進んだかを判断しやすくなります。
64GBメモリが効く場面
VS Code、GitHub、Codex、Chrome大量タブ、Search Console、公開URL確認を同時に開くと、メモリの余裕が安定性に出やすくなります。
4Kモニターが効く場面
差分、本文、公開ページ、管理画面を同時に見られるため、タブ切替と確認漏れを減らせます。
GitHubに保存しただけでは本番は変わらない
GitHubへの保存や差分確認だけでは、公開サイトが変わらない場合があります。本番アップロードと公開URL確認まで並列に見ることが大切です。
Codex専門記事への導線
Codexで本番公開まで進める場合、GitHub作業も並列確認の一部になります。Codex側の記事で全体像を整理しています。
並列作業で本当に詰まるのはPC性能より「差分の混線」
Codex・VS Code・ブラウザを同時に開く並列作業で最初に心配されるのはPCスペックですが、実際に作業を壊すのは性能不足ではなく「どの画面でどのリポジトリを触っているか分からなくなる」混線です。特に同じリポジトリを2つの画面で同時に編集すると、片方のcommitがもう片方の作業を上書きし、原因不明の差分が生まれます。
安全な並列の原則は「1画面1リポジトリ、1リポジトリ1作業」です。サイトAの修正はウィンドウ1、サイトBの確認はウィンドウ2、と物理的に分けて、同一リポジトリへの同時編集だけは避ける。この運用なら、メモリに余裕がある限り並列数を増やしても事故は起きません。
実用的な画面レイアウトの例
| 画面/ウィンドウ | 置くもの | 役割 |
|---|---|---|
| メイン画面・左 | Codex（またはClaude Code） | 作業を依頼し報告を受ける |
| メイン画面・右 | ブラウザ（GitHubのPR/diff画面） | AIの変更を差分で確認する |
| サブ画面 | 公開URLのプレビュー | 反映結果を実際の表示で確認する |
| 最小化しておく | 別リポジトリの作業ウィンドウ | 待ち時間に切り替えて進める |
AIの作業には待ち時間が発生します。この待ち時間に別リポジトリの確認作業を進めるのが並列作業の本当のうまみで、「AIを待つ間に人間が別件を確認する」形なら、混線リスクなく作業効率だけが上がります。