GitHub + Codex workspace
GitHubをCodexで使える作業場所に育てる方法
GitHubを接続しただけで終わらせず、Codexが確認しやすく、人間が判断しやすい作業場所へ段階的に整えます。
このページは非公式の実践ガイドです。GitHubやCodexの画面、機能、仕様は変わる可能性があります。最新情報が必要な場合は、提供元が公開している情報も確認してください。
GPTガイドくん
README、ブランチ、PR、AGENTS.mdを整えると、Codexが作業前提を理解しやすくなります。
まなぶちゃん
接続しただけで終わらせず、作業ルールも置いておきます。
GitHubを接続しただけで何ができる？
GitHubをCodexと組み合わせると、Codexがリポジトリ内のファイル構成を確認し、変更対象のファイルを指定しやすくなる場合があります。Pull Requestのレビューや差分確認にもつなげやすくなります。
ただし、接続しただけで自動的に安全運用になるわけではありません。どのリポジトリを見せるか、何を触らせるか、何を触らせないかを人間が決める必要があります。
接続しただけでは不十分な理由
- 不要ファイルが混じっているとCodexも前提を誤解しやすい
- 外へ出せない情報が入っていると危険
- READMEがないと何のリポジトリか分かりにくい
- ブランチ運用がないと本体へ直接変更しやすい
- Pull Request運用がないと差分確認が弱くなる
- AGENTS.mdがないとCodex向けの作業ルールが伝わりにくい
- Actionsや保護ブランチがないと自動チェックやレビュー必須の安全装置が弱い
結論 GitHubは接続するだけで完成ではありません。リポジトリを整え、作業ルールを置き、差分を見られる流れを作ることで、Codexの作業場所として使いやすくなります。
段階1：コードの図書館として整理する
まずはGitHubをコードの図書館として整えます。サイトやアプリごとにリポジトリを分け、フォルダ構成を分かりやすくし、README.mdでファイルの役割や作業ルールを説明します。
| 入れてよいもの | 入れてはいけないもの |
|---|---|
| HTML / CSS / JavaScript | APIキー / パスワード / SSH鍵 |
| README | DB接続情報 / FTP情報 / GitHub Token |
| 公開して問題ないテンプレート | .envの中身 / 本番設定ファイル |
| サンプル設定 | DB dump / ログファイル / 個人情報 |
| 公開前チェック用メモ | 業務上の非公開情報 |
段階2：変更履歴を残す
GitHubは変更履歴を残せます。コミットは作業のセーブポイントです。小さくコミットすると、何を変えたか分かりやすく、あとから戻したい時の目印にもなります。
| 悪いコミット名 | 良いコミット名 |
|---|---|
| 修正 | トップページに初心者向け導線を追加 |
| 更新 | 安全ページにNG例を追加 |
| test | GitHub用語ページを追加 |
| いろいろ | スマホ表示の余白を調整 |
| 全部変更 | sitemapに新規ページを追加 |
段階3：ブランチで安全に作業する
mainを直接触らず、作業ブランチで修正します。ブランチは本体とは別の作業スペースです。失敗しても本体にすぐ影響しにくく、作業単位で差分を見やすくなります。
| 分かりやすいブランチ名 | 避けたいブランチ名 |
|---|---|
| feature/add-beginner-guide | test |
| fix/internal-link-check | new |
| update/safety-examples | aaa |
| review/github-terms-page | fix |
ブランチを分ければ何をしてもよい、という意味ではありません。差分を見て、人間が最終確認する前提で使います。
段階4：Pull Requestで差分を見る
Pull Requestは、変更を本体へ入れる前に確認する場所です。GitHub Docsでも、Pull Requestは変更の提案、レビュー、取り込みのための機能として説明されています。
目的
変更したファイル
変更内容
確認したこと
未確認事項
リスク
戻す場合の注意- 意図しないファイルが混じっていないか
- SEOタグが変わっていないか
- sitemapやrobotsを触っていないか
- 外へ出せない情報が混じっていないか
- 戻しにくい変更がないか
- 人間が最終確認したか
段階5：Codexにレビューや確認を頼む
CodexにPRレビューや差分確認を頼める場合があります。ただし、AIレビューだけで人間確認不要にはしません。見る観点を明確に伝え、重大な不具合、重要情報の混入、SEOタグ変更、不要ファイル混入を優先して確認します。
Codexレビュー依頼文例
このPull Requestをレビューしてください。
重大な不具合、セキュリティ上の問題、SEOタグの意図しない変更、外へ出せない情報の混入、不要ファイルの混入、戻しにくい変更がないか確認してください。
軽微な好みの指摘ではなく、実害がありそうな点を優先してください。Codex差分確認依頼文例
このリポジトリで今回変更されたファイルを確認してください。
title、canonical、robots、H1、sitemap.xml、robots.txt、ads.txt、.htaccess、外へ出せない情報に意図しない変更がないかを確認し、修正はまだ行わず報告してください。段階6：AGENTS.mdでCodex向けルールを書く
AGENTS.mdは、AI coding agent向けの作業ルールを置くファイルとして使われることがあります。Codex向けに、セットアップ、テスト、コードスタイル、触らない範囲、報告書形式、停止条件を書いておくと、前提を伝えやすくなります。
OpenAIのCodex関連ドキュメントでも、AGENTS.mdはリポジトリ内の追加指示として扱われる文脈があります。ただし万能ではないため、Codexへの個別オーダーにも重要条件を毎回書いてください。
| AGENTS.mdに書く候補 | 目的 |
|---|---|
| このリポジトリの目的 | 作業対象を理解しやすくする |
| 触ってよいファイル | 作業範囲を絞る |
| 触ってはいけないファイル | 重要ファイルの意図しない変更を避ける |
| テスト方法 | 確認手順をそろえる |
| 公開前チェック方法 | HTTP 200やリンク確認を定型化する |
| SEOタグを変更しないルール | 意図しない検索設定変更を避ける |
| 報告書形式 | 人間が読みやすい報告にする |
| 停止条件 | 危険な状態で作業を続けない |
このリポジトリでは、sitemap.xml、robots.txt、ads.txt、.htaccess、Search Console確認ファイル、AdSenseコード、外へ出せない情報を変更しないでください。
HTML本文修正は対象ページだけに限定してください。
作業後は HTTP 200、SEOタグ維持、検索除外設定なし、内部リンク、スマホ表示を確認してください。段階7：GitHub Actionsや保護ブランチを使う
ここは中級以上の段階です。GitHub Actionsでは、HTMLリンク確認、構文チェック、ビルドチェック、テスト実行などを自動化できます。GitHubのドキュメントでも、Actionsはワークフロー自動化の機能として説明されています。
保護ブランチでは、レビュー必須やステータスチェック必須にできる場合があります。ただし設定ミスの影響もあるため、個人サイトでは最初から全部やる必要はありません。
- PR時にリンク切れ確認
- PR時に構文チェック
- mainへ入れる前に確認必須
- 保護された値を通常ファイルに書かない運用
- レビュー後にマージ
個人サイトならまずどこまでやればいい？
- 第1段階コードの図書館として整理する
- 第2段階READMEを書く
- 第3段階小さくコミットする
- 第4段階作業ブランチを使う
- 第5段階Pull Requestで差分を見る
- 第6段階Codexに差分確認を頼む
- 第7段階AGENTS.mdで作業ルールを置く
- 第8段階必要になったらActionsや保護ブランチを検討する
個人サイトや小規模情報サイトでは、まずはリポジトリ整理、README、ブランチ、Pull Request、AGENTS.mdまでで十分なことが多いです。Actionsや保護ブランチは、必要になってから慎重に検討します。
やってはいけないGitHub運用
| 避けたい運用 | 安全寄りの考え方 |
|---|---|
| GitHubをただのバックアップ置き場だと思って重要情報を入れる | 公開してよいコードと説明だけ置く |
| publicリポジトリにAPIキーを置く | APIキーや接続情報は置かない |
| privateなら何でも入れてよいと思う | privateでも共有範囲と連携先に注意する |
| mainを直接どんどん編集する | 作業ブランチとPRで確認する |
| コミット名が毎回「修正」 | 変更内容が分かる名前にする |
| Pull Requestを作らず差分を見ない | PRで変更ファイルと内容を見る |
| Codexにリポジトリ全体を丸投げする | 対象ファイルと確認観点を指定する |
| AGENTS.mdに重要情報を書く | ルールだけを書き、接続値は置かない |
| Actionsや保護ブランチを理解せず入れる | 必要になってから小さく導入する |
| AIレビューだけで人間確認をしない | AIレビューは補助として扱う |
GitHubをCodex作業場所に育てるチェックリスト
- リポジトリの目的が分かる
- READMEがある
- 不要ファイルを入れていない
- 外へ出せない情報を入れていない
- 小さくコミットしている
- main直変更を避けている
- 作業ブランチを使っている
- Pull Requestで差分を確認している
- PR本文に目的と確認内容を書いている
- Codexに見る観点を明確に伝えている
- AGENTS.mdで基本ルールを整理している
- Actionsや保護ブランチは必要になってから検討している
- 人間が最終確認している
関連ページ
GitHubとCodexの前提を混ぜない
GitHub連携では、リポジトリ、Pull Request、差分確認、Codexのタスク単位を分けて読むと、作業対象と報告書が混ざりにくくなります。
このカテゴリの親ページへ戻る
同じカテゴリのページを続けて読む場合は、親ページの一覧から選ぶと迷いにくくなります。
GitHub作業をCodex確認へつなげる
GitHubで差分やPRを見る時は、Codexの作業単位、報告書、公開前チェックもあわせて確認すると安全です。
近いテーマの読み分け
GitHubはコード履歴と差分確認の置き場です。秘密情報を避け、Codex作業場所として整えます。
GitHubとCodexを行き来する
検索や個別ページから入った場合は、親カテゴリや近い実務ページへ進むと全体像をつかみやすくなります。