下記記事で、CodexとGitHubとの連携環境について紹介したが、本記事では、Web版のChatGPTで、CodexとGitHubの連携環境を構築する手順を簡単に説明する。

（注）本記事の内容は正確性を保証するものではない。

手順１：Codex画面で「環境を選択」をクリックし「環境を作成する」をクリック

手順２：「最初の環境を作成する」という画面（下図）が表示され、リポジトリを作成していれば、候補となるリポジトリが表示されるので、連携するリポジトリをクリック
　　　　（注）連携するリポジトリをクリックして選択しないと「環境を作成する」をクリックできない。

（追記）リポジトリが表示されていない場合は、下図の「リポジトリアクセスを構成してください」を参照ください。解決しない場合は本記事の最後の「リポジトリが表示されていない場合」も参照ください。

手順３：エージェントのインターネットアクセスの有効・無効を選択する
　　　　・インターネットアクセスが無効で良ければ、「環境を作成する」をクリック
　　　　・インターネットアクセスを有効にすると、手順４の画面になる

手順４：インターネットアクセスを有効にした場合の設定画面で各項目を設定
　　　　・ドメイン許可リスト：アクセスが許可されるドメインがデフォルトのものでよければ「共通の依存関係」を選択。
　　　　　他に、「なし」、「すべて（無制限）」が選択できる。
　　　　・ここでは、「許可対象の追加ドメイン」と「許可されているHTTPメソッド」は下図のままとして進める
　　　　・「環境を作成する」をクリック

「共通の依存関係」を選択した場合に適用されるホワイトリスト（抜粋）
（このリストは「ドメインの詳細」のリンク先ページに記載されている）

次は、作成した環境の設定を変更する場合について説明する。

まず、環境の選択メニューをクリックし、「環境を管理する」をクリック

リポジトリの一覧画面が表示されるので、対象のリポジトリの「名前」をクリック

リポジトリの設定一覧画面が表示されるので右上の「編集」をクリック

編集画面が表示される。修正後は「環境を保存する」をクリック
編集画面の各項目についてGPT 5 Thinkingに質問した。

GPT 5 Thinking の回答

了解です。添付画面（「基本」「コードの実行」）で見えている各項目を、上から順にわかりやすく説明します。

基本

• GitHub 組織
  • Codex からアクセスを許可した GitHub アカウント／Organization を選びます。
    ここで選んだ組織配下の“アクセス許可済み”リポジトリだけが次のリストに出ます。
  • 目的：どのアカウントのリポジトリを使うかを切り替えるため。
    
• リポジトリ（検索欄＋一覧）
  • 選択した組織内で、Codex が権限を持っているリポジトリだけが表示されます。検索ボックスで絞り込みも可能。
  • 「リポジトリアクセスを構成してください」リンクは、GitHub 側で追加のリポジトリにアクセス権を与える設定（Permissions/Repository access）へ誘導するためのものです。
  • 目的：この環境が“コードのソース”として参照・操作するリポジトリを決める。
    
• 名前
  • この Codex 環境の表示名。後から一覧で識別しやすくするためのラベル（64 文字まで）。
  • 例：「qzss-dcx 実験用」「blog-builder-prod」など。
    
• 説明
  • 環境の用途メモ（512 文字まで）。利用目的や注意点、主要ツール等を書いておくと運用がラクです。

コードの実行（依存関係、lint、テストの設定）

• コンテナ画像（例：universal）
  • ベースとなる実行用コンテナイメージを選びます。
    universal は Ubuntu 24.04 ベースで、多言語開発を想定した汎用スタック。
  • 目的：実行 OS とあらかじめ入っている基本ツールを決める。
    
• プリインストールされたパッケージ
  • ベース画像に予めバンドルされている共通パッケージ群の利用可否。
    オンにすると、よく使うビルドツールや言語ランタイムのセットアップが短時間で済みます。
  • 追加の依存は後述の「セットアップスクリプト」で入れます。
    
• 環境変数（追加＋）
  • ビルド／実行時に参照させる一般的な環境変数（例：NODE_ENV=production、PYTHONUNBUFFERED=1）。
  • 機微情報には使わず、後述の「シークレット」を使うのが原則。
    
• シークレット（追加＋）
  • トークンやパスワード等の機微情報を安全に注入します（ログや成果物に出ない扱い）。
  • 例：GH_TOKEN、OPENAI_API_KEY、AWS_ACCESS_KEY_ID など。
    
• コンテナのキャッシュ（無効／有効）
  • セットアップ後の状態をキャッシュし、次回以降の起動を高速化します。
  • 依存関係を頻繁に変える開発初期は無効でもよいですが、安定してきたら有効化が時短になります。
  • 依存を大きく更新したのに反映されない場合は、キャッシュを無効にするか、再作成してリフレッシュします。
    
• セットアップスクリプト（自動／手動）
  • “環境起動直後に走る初期化フェーズ”の扱いを決めます。
    
  • 自動：プロジェクトの種類に応じて npm install / pip install -r requirements.txt / poetry install など、一般的なインストールコマンドを自動推定・実行。
  • 手動：自分で明示的なセットアップ手順を書きます（例：apt-get update && apt-get install ...、npm ci、make setup など）。
    
  • 目的：依存の導入やビルド前準備を再現可能にすること。
    
• エージェントのインターネットアクセス（無効／有効）
  • セットアップ後、エージェント（タスク実行時）が外部ネットワークへアクセスできるかの制御。
  • セキュリティ重視・再現性重視なら無効（ローカル資源とロックされた依存だけで動作）。
    外部 API 叩きやパッケージ取得が必要なら有効。
  • メモ：多くのケースでは「セットアップ時だけネット可、実行時はオフ」にすると安全性と安定性のバランスが良いです。
    
• ターミナル／対話型ターミナルを接続
  • 右側のパネルは環境コンテナに対するシェル操作エリア。
    接続すると /workspace 配下（リポジトリがマウントされる場所）で手動コマンドを試せます。
  • ビルド失敗の原因調査、入っているツールの確認、手動デバッグに便利。
    
• ワークスペースディレクトリを編集
  • リポジトリをどこにマウントするか、ワークスペースのルートを微調整したいときに使います。
    （モノレポでサブディレクトリを作業ルートにする等）。
    

実践的な設定アドバイス

• 権限でつまずきやすい点
  リポジトリが一覧に出ない → GitHub の「Repository access」で当該リポジトリを Explicit access に追加する（組織全体許可にしていない場合）。Private リポジトリは特に忘れがち。
  
• Secrets の徹底
  API キーやトークンは必ず「シークレット」に入れ、環境変数に平文で置かない。
  
• キャッシュ運用
  lockfile（package-lock.json / poetry.lock / requirements.txt 等）を更新したら、一度キャッシュ無効で再セットアップ→その後に再び有効化、が安定。
  
• ネットアクセスの方針
  ①セットアップで依存取得 → ②実行時はネット遮断、が再現性・安全性◎。外部 API を叩くジョブだけ個別に有効化する。

必要なら、あなたのプロジェクト（例：qzss-dcx-esp32c6）向けに「おすすめ初期設定テンプレート（環境変数/シークレット名の例、セットアップコマンド例）」も作ります。気軽に言ってください。

GPT 5 Thinking の回答

了解です。要点だけサクッと👇

何が「Lint」「テスト」に効くのか（対応づけ）

• コンテナ画像 / プリインストール
  ここで決めたOS・言語ランタイム・ツール群が、使えるリンター／テストランナーの土台になります。
  例：Node系なら eslint / vitest、Python系なら ruff / pytest を動かせるかがここで決まる。
  
• セットアップスクリプト（自動/手動）
  Lint/テストに必要な依存のインストール手順を実行します。
  例：npm ci、pip install -r requirements-dev.txt、poetry install。
  → これが終わって初めて eslint . や pytest が実行可能。
  
• 環境変数
  Lint はほぼ影響なし（たまに設定を切り替える程度）。
  テストは挙動を分けるフラグでよく使います（ENV=ci、DJANGO_SETTINGS_MODULE、FEATURE_X=0 など）。
  
• シークレット
  Lint では基本不要。
  テストでは統合テストで外部APIモック用のキーや、CI用トークンが必要になることあり（なるべくモック推奨）。
  
• コンテナのキャッシュ
  依存が変わらなければlint/テストの起動が高速化。
  依存更新で不整合が出たら一度オフにして再セットアップ。
  
• エージェントのインターネットアクセス
  オフでもLintや単体テストはだいたい動く（ローカル依存のみ）。
  外部APIやパッケージ取得を含む統合テストはオンが必要。
  原則：セットアップではオン、実行はオフ（モック重視）が安全。
  
• ワークスペース / ターミナル
  Lint/テストが走る作業ディレクトリ。
  ターミナルは失敗時の手動デバッグに使う。

全体像（1本の流れ）

1. コンテナ決定 → 2) 依存インストール（セットアップ） → 3) Lint（静的チェック） → 4) テスト（単体→結合）
   この順に、上の各設定が“使えるツール・入れる依存・ネット可否・速度”を左右します。

迷ったら

• Lint/単体テスト中心：ネットオフ、キャッシュ有効
• 外部連携の統合テストあり：セットアップ時オン、実行は極力オフ＋モック（例外ケースのみオン）

もっと具体的に、あなたのリポジトリ（言語/フレームワーク）向けに「おすすめ Lint & テスト最小セット（セットアップコマンドと実行コマンド）」を出すこともできます。言語を教えてください。

不明点も多いが、基本的な最小限の設定は行えた。
以降、Codexの設定画面（下図）の他の項目（一般、データ コントロール、コードレビュー）についてGPT 5 Thinkingに確認した内容を紹介する。

了解です。画像に写っている3つの設定タブごとに、主要な項目をサクッと解説します。

一般

• カスタム指示
  Codexに“普段どう振る舞うか”を伝える欄。例のように
  • すべてのコード変更では「テスト実行＋Lintで検査」
  • コメントやドキュメントだけの変更ではそれらを省略
    …などの運用ルールを書いておくと、提案や自動アクションの基準になります。
• 差分の表示形式（Unified / Split）
  プルリク等の差分の見せ方を選択。
  • Unified: 1列で前後の変更をまとめて表示（コンパクト）。
  • Split: 左右2列で旧/新を並べる（詳細比較に向く）。
• ブランチ形式（例: codex/{feature}）
  Codexが作業ブランチを切る際の命名テンプレート。
  {feature}・{date}・{time} などのタグを差し込めます（例：codex/unit-tests-for-feature）。
  共同開発時のブランチ規約をここで統一できます。

データ コントロール

• GitHub（接続済み／切断・設定）
  CodexとGitHubアカウントの連携状態。
  • 設定: 対象組織・リポジトリ、権限のスコープを調整。
  • 切断: 連携を解除。
• モデルの改善（ChatGPT データ コントロール）
  あなたの利用データを“製品改善（学習）”に使って良いかの全体設定。ここはChatGPT側のデータコントロールに準拠します。
• 環境を含める（トグル）
  上記“モデルの改善”を許可している場合に、Codex環境の追加コンテキスト（依存関係・実行ログ・補助メタ情報など）も改善用途に含めるかを個別に指定。
  オフにすると、環境コンテキストは改善に使われません（プライバシー重視）。

コードレビュー

• @codex メンション説明
  プルリクのスレッドで @codex を呼ぶと、質問に答えたり、リクエストを受けてレビュー／タスクを開始します。
• 自分のプルリクエストを自動でレビュー（トグル）
  有効にすると、あなたが作成したPRにCodexが自動で改善提案コメントや👍リアクションを付けます。細かな指摘や修正案が自動で届きます。
• リポジトリの対象範囲
  • 検索ボックス: 対象にしたいGitHub組織／リポジトリを検索して追加。
  • 指定のリポジトリのみ: 自動レビューの対象を限定。
  • 各リポジトリ行の自動コードレビュー（トグル）で、個別にオン/オフ。
  • 最終更新者／最終更新日: 設定を最後に変えたユーザーと日時の記録。

（補足）
「リポジトリが表示されていない場合」

まず、下記記事の最後に記載の通り、GitHubアカウントの本人確認（ユーザー名の確認）や、どのリポジトリにアクセスできるかの確認を行ってGitHub側の設定を行ってください。それでも解決しない場合は、下記の質疑応答を参照してください。

GPT 5 Thinking の回答

いい質問です。
結論：リポジトリが出てこない＝必ずしも「コネクター未設定」ではありません。 コネクター（GitHub連携）が入っていても、権限や対象範囲の設定で“表示ゼロ”になることがよくあります。

まず押さえるポイント

• 画面のドロップダウンで組織（Org）を正しく選択していない
• GitHub側で「特定のリポジトリのみ」許可にしていて、1件も選んでいない
• 組織の管理者承認/SSO承認が未完了（Pending）
• プライベートリポジトリの権限が付いていない
• 別の所有者（個人アカウント vs 組織）のリポジトリを見に来ている
• リポジトリがアーカイブ/非表示フィルタに引っかかっている
• 単純に再同期が未実行（キャッシュ）

すぐできる切り分け手順（おすすめ）

1. 画面上部の「GitHub 組織」で目的の組織/個人を選び直す。
2. 下部のリンク（画像の文言だと「リポジトリアクセスを構成してください」）をクリックして、GitHub側の連携設定へ。
3. GitHub側で以下を確認：
   • アプリ/コネクターがインストール済み（対象の組織に）
   • アクセス範囲：
     • テストとして一旦 “All repositories（全リポジトリ）” を選択 → 保存
     • もしセキュリティ方針で「Selected repositories」のみなら、表示したいリポジトリを必ず追加 → 保存
   • プライベートリポジトリへの読み取り権限が付与されている
   • 組織のOwnerが承認している／SSOのAuthorizeが済んでいる（必要な場合）
4. Codexの画面に戻り、更新（リロード）、または再同期。検索欄をクリアして全件が見える状態に。
5. それでも出ない場合：
   • 連携を一度Revoke（取り消し）→ 再接続
   • 目的のリポジトリがその組織配下か（個人配下だった、Orgが違った等）を再確認
   • テスト用にパブリックのダミーrepoを1つ作成して表示されるか確認（表示されれば権限/可視性の問題）

よくある落とし穴

• Org側の「Install App but Pending Approval」状態のまま
• Selected repositoriesに追加したつもりが保存していない
• Fork/Archiveを非表示にするフィルタが効いている
• 以前Agentモードでのみ接続しており、通常モードのCodex環境側で再認可していない

要点まとめ

• 表示が空でも、コネクター未設定と断定は不可。
• まずはGitHub側で“どの組織に・どのリポジトリに権限が出ているか”を確認し、範囲（All/Selected）と承認を整え、Codexで再同期してください。