検証日：2026年7月14日
環境：Windows 11／複数のWSL2ディストリビューション／ChatGPT Pro X20／Codex CLI／GitHub CLI
ChatGPTやCodexの機能は段階的に展開される場合があります。画面や利用可能な機能が本記事と異なる場合は、最新の公式ドキュメントも確認してください。

本記事では、非既定の独自WSL2環境を確実に利用するため、コードベースの確認・変更・GitHub操作は、その環境内のCodex CLIとGitHub CLIを中心に行います。Windows版ChatGPTのCodexモードは、実行環境を確認できた範囲で利用します。

はじめに

前回は、安定稼働している独自WSL2環境とCodex CLIを置き換えず、Windows版ChatGPTをChat、Work、タスク管理、レビューの上位レイヤーとして追加する構成を整理しました。

今回は、その構成で最初に問題になる作業の引き継ぎを扱います。

筆者はこれまで、Web版ChatGPTで計画や設計を検討し、内容が固まった段階でGitHub Issueへ登録し、WSL2上のCodex CLIで実装してきました。しかし、この方法には次の手作業が残ります。

Chatで決めた内容をCodex CLIへ説明し直す
長い会話のどこが最終決定だったかを探す
設計内容をGitHub Issueへ転記する
Issue分割が現在のコード構造と一致しているか確認する
実装後の変更を技術文書やリリースノートへ戻す
Chat、Work、Codexの各履歴で前提が少しずつずれる

本記事では、この受け渡しを次の流れへ整理します。

Chat
  ↓ 問題定義・選択肢・設計判断

Work
  ↓ 要求仕様・ADR・実装計画・Issue草案

Gitリポジトリ
  ↓ 確定情報をMarkdownとして保存

独自WSL2環境のCodex CLI
  ↓ 現在のコードとの照合・修正・検証

GitHub
  ↓ Issues・Pull Requests・Actions

結論から言えば、Chat、Work、Codex CLIを長期的につなぐ正本は、会話履歴ではなくGit管理されたMarkdownにします。

結論

推奨する役割分担は次のとおりです。

場所	主な役割	正本として残すもの
Chat	問題整理、比較、設計相談	まだ確定情報にしない
Work	要求、ADR、計画、Issue草案の成果物化	Markdownのドラフト
Gitリポジトリ	確定した設計と引き継ぎ	要求、ADR、計画、草案、handoff
Codex CLI	実装との照合、コード変更、テスト	コード、テスト、実装結果
GitHub Issues	タスクの状態、担当、議論	Issue番号、状態、コメント
Pull Request	実装差分とレビュー	コード変更、検証結果

重要なのは、GitHub Issueの本文だけを設計の正本にしないことです。

何を満たすかは要求仕様
なぜその設計を選んだかはADR
どの順序で進めるかは実装計画
誰が何を進めているかはGitHub Issue
実際に何を変更したかはPull Request
次の文書作業へ何を渡すかはhandoff

という形で分けます。

短期的な引き継ぎには、デスクトップアプリのAdd to taskが使えます。長期的な引き継ぎにはGit管理ファイルを使います。

Add to task
→ 今回のタスクへ短期的に渡す

Git管理ファイル
→ 将来のWork、Codex、CLI、人間へ残す

最初に区別する3種類の「プロジェクト」

現在のChatGPT／Codexでは、「プロジェクト」という言葉が複数の意味で使われます。ここを混同すると、Chatで作った内容がCodex CLIへ自動的に伝わるように見えてしまいます。

1. ChatGPT Project

ChatGPT Projectは、関連するChatやWorkの会話、アップロードファイル、接続済みソース、プロジェクト指示をまとめる作業単位です。

同じChatGPT Projectでは、ChatとWorkが共通のファイル、Sources、プロジェクト指示を利用できます。ただし、ChatGPT ProjectがPC上のフォルダーへ直接アクセスするわけではありません。ローカルファイルを使うには、アップロード、接続済みソース、またはデスクトップ版のローカルProjectを使います。公式資料

ChatGPT Project
├─ Chats
│  ├─ Chatでの設計相談
│  └─ Workでの仕様書作成
├─ Sources
│  ├─ 公式資料
│  └─ 接続済みGitHub
└─ Project instructions

2. ローカルProject

Windows版ChatGPTのローカルProjectは、PC上の1個以上のフォルダーをWorkやCodexへ公開する作業単位です。

コードベースの場合、プロジェクトフォルダーはCodexタスクの作業ディレクトリになります。Workは、許可されたローカルファイルを読み、成果物をローカルへ保存できます。公式資料 WorkとCodexのFAQ

ただし、複数WSL2ディストリビューション環境では、\\wsl$\DistroName\...で選んだ保存先とCodex Agentの実行先が一致するとは限りません。非既定の独自WSL環境に依存する確認・変更は、その環境内のCodex CLIへ残します。

3. Codex CLIのプロジェクト

Codex CLIでは、codexを起動したディレクトリがタスクのプロジェクトです。別のディレクトリを明示する場合は--cdまたは-Cを使えます。Codex CLIはChatGPT Projects画面を公開しません。公式資料

cd ~/projects/product-api
codex

または、

codex -C ~/projects/product-api

Codexのタスクは会話履歴と作業ディレクトリを保持しますが、別タスクへ残す情報はAGENTS.mdやチェックインされた文書へ保存する必要があります。各タスクは同じファイルを扱えても、トランスクリプトは独立しています。公式資料

三者を永続的につなぐ共通部分が、Gitリポジトリ内のファイルです。

何が自動で共有され、何が共有されないか

組み合わせ	自動で共有されるもの	自動では共有されないもの
同じChatGPT Project内のChatとWork	アップロードファイル、Sources、プロジェクト指示	別チャットの全会話履歴
Web／デスクトップの通常Chat	通常のChat会話	デスクトップCodexのタスク
Web／モバイルのWork	対応するクラウド面でのWork会話	デスクトップWorkのローカルスレッド
同じローカルProjectのWork／Codex	許可された同じファイル	各タスクのトランスクリプト
Codex CLIの別タスク	同じ作業ツリーのファイル	別タスクの会話履歴
ChatGPT ProjectとCodex CLI	なし	Projects画面、Sources、会話履歴

通常のChat会話はWebとデスクトップ間で同期しますが、クラウドWorkとデスクトップWork、デスクトップCodex、Codex CLIでは同期範囲が異なります。WorkとCodexのFAQ

したがって、長期的な連携を会話履歴だけに依存させません。

`Add to task`は短期的な受け渡し

デスクトップアプリのQuick Chatで始めた会話が大きな作業へ発展した場合、Add to taskで現在のWorkまたはCodexタスクへ持ち込めます。公式資料

Web／Desktop Chatで設計相談
  ↓
デスクトップでRecent chatsを開く
  ↓
Add to task
  ↓
現在のWorkまたはCodexタスクへ追加

Webで始めた通常Chatもデスクトップへ同期するため、Recent chatsから開ける範囲ではこの流れを使えます。

短い会話の受け渡しには便利です。

一方、次の情報はファイルへ保存します。

数週間以上参照する設計判断
複数Issueに影響する方針
人間の開発者と共有する受け入れ条件
将来のCodex CLIタスクでも必要な制約
PRレビューで根拠として示す文書
Workへ戻す実装結果

推奨する全体構成

この構成では、ChatとWorkの会話をCodex CLIへ丸ごと渡しません。

代わりに、Workが会話をレビュー可能な文書へ圧縮し、Codex CLIがその文書と実装を照合します。

リポジトリの構成

最低限、次のディレクトリを用意します。

repository/
├─ AGENTS.md
├─ docs/
│  ├─ requirements/
│  │  └─ authentication-renewal.md
│  ├─ adr/
│  │  └─ 0012-token-storage.md
│  ├─ plans/
│  │  └─ authentication-migration.md
│  ├─ issues/
│  │  ├─ index.md
│  │  ├─ 001-token-storage.md
│  │  ├─ 002-api-migration.md
│  │  └─ 003-client-migration.md
│  └─ handoffs/
│     └─ issue-123-result.md
└─ src/

各ファイルの役割は次のとおりです。

ファイル	内容
`requirements/`	利用者に必要な結果と受け入れ条件
`adr/`	採用した設計と、採用しなかった選択肢
`plans/`	変更順序、移行、ロールバック、検証方法
`issues/`	GitHubへ登録する前のIssue本文
`handoffs/`	実装結果をWorkや次のCodexタスクへ戻す要約
`AGENTS.md`	リポジトリ共通の短い作業規則

AGENTS.mdへ個別機能の仕様をすべて詰め込みません。

AGENTS.md
→ 全タスクに適用する短いルール

docs/requirements/
docs/adr/
docs/plans/
→ 機能固有の詳細

Codexの利用量を抑える観点でも、AGENTS.mdは短く保ち、必要な詳細だけを個別文書へ分ける方が扱いやすくなります。Pricing

実践フロー：認証トークン保存方式を変更する

ここからは、既存システムの認証トークン保存方式を変更する例で説明します。

フェーズ0：独自WSL2環境とGitHub CLIを確認する

対象のWSL2ディストリビューションを明示して開きます。

wsl -d Ubuntu-Development

WSL2側で、対象リポジトリとGitHub CLIの状態を確認します。

printf 'WSL_DISTRO_NAME=%s\n' "$WSL_DISTRO_NAME"
git status --short --branch
gh auth status
gh repo view

この段階で、作業ディストリビューション、リポジトリ、GitHubアカウントを確認します。

OpenAIのGitHub接続に関する公式ヘルプでは、リポジトリのコード、README、文書を取得して検索・分析・引用する用途が案内されています。Issue作成の書き込み経路としては説明されていないため、本記事では外部書き込みが明確で監査しやすいGitHub CLIを使います。公式FAQ

フェーズ1：Chatで論点を整理する

Chatでは、最初からIssue本文を作らせません。

まず、問題、選択肢、制約、未決事項を整理します。

現在の認証トークン保存方式を変更したいです。

目的:
- クライアント側で長期トークンを保持しない
- 既存APIとの互換性を可能な範囲で維持する

検討したいこと:
- 現行方式の問題
- 代替方式
- 移行時のリスク
- ロールバック方法
- 必要な監視

この段階では実装案を一つに決めず、
選択肢と判断材料を整理してください。

方針が固まったら、会話全体を引き継ぎ用に圧縮します。

ここまでの検討を、WorkとCodex CLIへ渡すための
引き継ぎ情報にまとめてください。

含める内容:
- 背景
- 解決したい問題
- 採用方針
- 採用しなかった方針と理由
- 制約
- 対象外
- 受け入れ条件
- 未解決事項

会話の経緯ではなく、
確定事項と未確定事項だけを記載してください。

ここでは「考えた過程」ではなく、「次の作業に必要な状態」へ圧縮します。

フェーズ2：Workで正式な成果物へ変換する

ChatGPT Project内でChatとWorkを使うと、共通のSources、アップロードファイル、プロジェクト指示を利用できます。公式資料

デスクトップWorkでローカルProjectを開いた場合は、許可したフォルダー内のファイルを利用できます。WorkとCodexのFAQ

Workには、会話の要約と必要な資料を渡し、次の成果物を作らせます。

## Goal

認証トークン保存方式の変更について、
実装前に人間がレビューできる文書一式を作成する。

## Success criteria

- 要求、設計判断、移行順序、Issue分割が別文書になっている
- 各Issueに対象範囲、対象外、受け入れ条件、検証項目がある
- 実装確認が必要な事実は推測せず、確認事項として残している
- GitHubやコードベースへの書き込みは行っていない

## Deliverables

次のファイルを作成する。

- `docs/requirements/authentication-renewal.md`
- `docs/adr/0012-token-storage.md`
- `docs/plans/authentication-migration.md`
- `docs/issues/001-token-storage.md`
- `docs/issues/002-api-migration.md`
- `docs/issues/003-client-migration.md`

## Requirements for each Issue draft

- 背景
- 目的
- 対象範囲
- 対象外
- 受け入れ条件
- 検証項目
- 依存するIssue
- 完了後に更新する文書

## Constraints

- この段階ではコードを変更しない
- GitHub Issueを作成しない
- 不明な実装事実を推測しない
- 現在のコード確認が必要な点は
  「Codex確認事項」として明示する

## Output

指定パスへMarkdownとして保存する。
ローカル保存が利用できない場合は、
各ファイルを独立したMarkdownコードブロックとして出力する。

最終報告は、作成したファイル一覧と未確認事項だけにする。

GPT-5.6向けの公式ガイドでは、細かい実行手順を増やすより、成果、成功条件、制約、検証、停止条件を明示する構成が推奨されています。本記事のプロンプトも、実行経路ではなく完成状態を中心に定義しています。公式ガイド

Workが対象WSL2環境へ直接保存できない場合

ローカルProjectへの書き込みが利用できない、または非既定WSLディストリビューションへの保存を確実に制御できない場合は、WorkにMarkdown本文だけを作らせます。

その後、人間またはCodex CLIが対象WSL2環境で保存します。

Work
  ↓ Markdown本文を生成

人間またはCodex CLI
  ↓ 対象WSL2リポジトリへ保存

実行環境が不明なまま、Desktop側から独自WSL環境へ書き込ませません。

フェーズ3：Codex CLIで実装との整合性を確認する

次に、対象の独自WSL2環境でCodex CLIを起動します。

cd ~/projects/product-api
codex

この段階では、まだコードを変更しません。

Full accessで起動していても、今回のタスク境界を明示します。

## Goal

次の計画文書とIssue草案を、
現在のコードベースと照合する。

## Success criteria

- 現行実装と計画の矛盾が特定されている
- 影響範囲と不足する受け入れ条件が明示されている
- Issueの依存関係と分割案が修正されている
- ファイル変更とGitHub書き込みは行われていない

## Evidence

- `docs/requirements/authentication-renewal.md`
- `docs/adr/0012-token-storage.md`
- `docs/plans/authentication-migration.md`
- `docs/issues/`

## Scope

優先して確認する範囲:

- `src/auth/`
- `src/api/`
- `tests/auth/`
- `docs/architecture/`
- 関連するGit履歴

## Constraints

- この段階ではファイルを変更しない
- GitHubへ書き込まない
- 事実確認に不要なテストやビルドを実行しない
- 要求と実装が矛盾する場合は変更前に停止する

## Output

次だけを報告する。

1. 現行実装と矛盾する点
2. 見落としている影響範囲
3. 不足している受け入れ条件
4. Issueの分割・依存関係の修正案
5. 文書へ反映すべき変更

Workが作った文書は、ここで初めて実装と照合されます。

この順序にすることで、Workへリポジトリ全体を無条件に調査させる必要がなくなり、Codex CLI側も対象文書と対象ディレクトリへ範囲を絞れます。

フェーズ4：計画文書を確定してコミットする

Codex CLIの確認結果を反映し、人間が内容をレビューします。

内容が固まったら、Issue登録前の計画パッケージをコミットします。

git add \
  docs/requirements/authentication-renewal.md \
  docs/adr/0012-token-storage.md \
  docs/plans/authentication-migration.md \
  docs/issues/

git commit -m "docs: add authentication migration plan"

Issue登録前にコミットする理由は、GitHubへ登録した内容の根拠を後から追跡できるようにするためです。

フェーズ5：既存Issueとの重複を確認する

GitHubへ書き込む前に、既存Issueを検索します。

gh issue list \
  --repo OWNER/REPOSITORY \
  --state all \
  --search '"authentication token" in:title,body' \
  --limit 50

gh issue listは--searchによる高度なIssue検索をサポートしています。GitHub CLI manual

Codex CLIへ任せる場合も、検索と書き込みを分けます。

`docs/issues/`の草案について、
既存のOpen／Closed Issueとの重複を確認してください。

この段階ではIssueを作成しないでください。

報告内容:
- 重複候補のIssue番号とURL
- 統合すべき草案
- 新規登録してよい草案
- title、labels、type、parent、
  blocked-by／blockingの提案

フェーズ6：登録予定を人間が確認する

Full access環境であっても、GitHub Issueの作成は外部への書き込みです。

Codex CLIには、最初に次の一覧だけを出させます。

1. 登録予定タイトル
2. 本文ファイル
3. labels
4. issue type
5. 親Issue
6. blocked-by／blocking
7. GitHub Project
8. 実行予定コマンド

この一覧を確認した後に、Issue作成を承認します。

フェーズ7：GitHub CLIでIssueを作成する

GitHub CLIのgh issue createは、本文ファイル、label、milestone、Project、Issue type、親Issue、依存関係を指定できます。GitHub CLI manual

利用できるオプションはGitHub CLIのバージョンやGitHub環境によって異なる可能性があるため、最初に現在の環境で確認します。

gh --version
gh issue create --help

最小構成

gh issue create \
  --repo OWNER/REPOSITORY \
  --title "認証トークンの保存方式を変更する" \
  --body-file docs/issues/001-token-storage.md \
  --label "authentication,security"

Issue typeを指定する

gh issue create \
  --repo OWNER/REPOSITORY \
  --title "認証トークンの保存方式を変更する" \
  --body-file docs/issues/001-token-storage.md \
  --label "authentication,security" \
  --type "Feature"

FeatureやTaskなどの名称は、対象組織・リポジトリで利用できるIssue typeへ置き換えます。

親Issueの配下へ作る

gh issue create \
  --repo OWNER/REPOSITORY \
  --title "APIの認証トークン処理を移行する" \
  --body-file docs/issues/002-api-migration.md \
  --label "authentication,api" \
  --type "Task" \
  --parent 120

依存関係を指定する

gh issue create \
  --repo OWNER/REPOSITORY \
  --title "クライアントのトークン更新処理を移行する" \
  --body-file docs/issues/003-client-migration.md \
  --label "authentication,client" \
  --type "Task" \
  --parent 120 \
  --blocked-by 121,122

GitHub Projectsへ追加する

gh auth refresh -s project

gh issue create \
  --repo OWNER/REPOSITORY \
  --title "認証トークンの保存方式を変更する" \
  --body-file docs/issues/001-token-storage.md \
  --project "Security Roadmap"

Projectへの追加にはprojectスコープが必要です。GitHub CLI manual

親Issueや依存関係を後から調整する場合は、gh issue editも利用できます。GitHub CLI manual

gh issue edit 121 \
  --repo OWNER/REPOSITORY \
  --parent 120 \
  --add-blocked-by 119

親Issue側からSub-issueを追加する例です。

gh issue edit 120 \
  --repo OWNER/REPOSITORY \
  --add-sub-issue 121,122

フェーズ8：草案とGitHub Issueの対応を記録する

Issue作成後は、docs/issues/index.mdへ対応関係を記録します。

# GitHub Issue mapping

| Draft | GitHub Issue | Status |
|---|---|---|
| `001-token-storage.md` | #120 | Open |
| `002-api-migration.md` | #121 | Open |
| `003-client-migration.md` | #122 | Open |

ここで重要なのは、登録後もIssue本文とMarkdown草案を完全に双方向同期しようとしないことです。

登録後の役割を次のように分けます。

情報	正本
要求と受け入れ条件	`docs/requirements/`
設計判断	`docs/adr/`
全体の移行順序	`docs/plans/`
日々の進捗、担当、議論	GitHub Issue
実装差分と検証	Pull Request
登録時のIssue本文	`docs/issues/`

docs/issues/は登録時点のスナップショットと監査用の入力です。運用中の状態管理はGitHub Issueへ移します。

フェーズ9：Codex CLIで実装する

Issue登録後は、Codex CLIへIssue番号と設計文書を渡します。

## Goal

GitHub Issue #121を実装する。

## Success criteria

- Issueの受け入れ条件を満たしている
- 関連テストが追加または更新されている
- 指定した検証が成功している
- 無関係な変更が含まれていない
- pushとPull Request作成はまだ行っていない

## Evidence

- GitHub Issue #121
- `docs/requirements/authentication-renewal.md`
- `docs/adr/0012-token-storage.md`
- `docs/plans/authentication-migration.md`

## Scope

- `src/auth/`
- `src/api/`
- `tests/auth/`
- 関連する技術文書

## Constraints

- 公開APIの互換性を維持する
- DBスキーマを変更しない
- 無関係なリファクタリングを混在させない
- pushとPull Request作成は承認まで行わない

## Validation

- 対象テスト
- lint
- 型チェック
- 影響パッケージのビルド

## Output

- 原因または設計上の判断
- 変更ファイル
- 検証結果
- 残るリスク
- 文書更新が必要な箇所

GitHub CLIが認証済みであれば、Codex CLIはIssue本文やコメントを取得しながら作業できます。

gh issue view 121 \
  --repo OWNER/REPOSITORY \
  --comments

gh issue view --commentsは、Issue本文だけでなくコメントも表示します。GitHub CLI manual

フェーズ10：実装結果をWorkへ戻す

実装後、Codex CLIに短いhandoffファイルを作らせます。

docs/handoffs/issue-121-result.md

内容は次の程度で十分です。

# Issue #121 implementation result

## 変更内容

## 変更ファイル

## 仕様との差異

## テスト結果

## 運用上の注意

## 文書更新が必要な箇所

## 残課題

Workは、このhandoffと確定した設計文書を読み、次の成果物を更新します。

利用者向け手順
開発者向け解説
移行ガイド
リリースノート
サポート向けFAQ

これで、Chatから始まった設計が実装を経て、再び人間向け成果物へ戻ります。

トークン消費を抑えるための設計

WorkはCodexと同じ利用構造を採用しています。Chatの長い会話をWorkへ渡し、さらに同じ内容をCodex CLIへ丸ごと渡すと、重複したコンテキストが増えます。WorkとCodexのFAQ Pricing

本記事では次の運用にします。

Chatでは、まだ曖昧な論点を検討する
方針が固まった時点で短い引き継ぎへ圧縮する
Workは完成させる文書を明示する
Codex CLIは対象ディレクトリと対象文書を限定する
計画、実装、レビューを別タスクにする
永続情報はGitへ置き、長い会話を次のタスクへ持ち込まない
AGENTS.mdは短く保ち、詳細は個別文書へ分ける
不要なPluginやMCPを有効にしない
報告は変更点、検証結果、残課題へ限定する
GitHub検索とGitHub書き込みを同じ段階で行わない

特に重要なのは、WorkとCodexを「同じ情報を二度考えさせる場所」にしないことです。

Work
→ 人間がレビューできる計画へ変換する

Codex CLI
→ その計画を実装事実と照合し、実行する

Full access運用で外部書き込みを分ける

Codex CLIをFull accessで運用していても、ローカル作業と外部作用を同じ扱いにはしません。

確認なしで進める範囲

関連ファイルの調査
Git履歴の確認
指定範囲の編集
非破壊的なテスト
lint、型チェック、ビルド
Issue登録前の重複検索

事前確認する範囲

GitHub Issue、PR、コメントの作成
push、merge、release、deploy
履歴を書き換えるGit操作
大量のファイルやデータの削除
secretや個人情報の外部送信
有料サービスや大量リソースの使用
依頼範囲を大きく超える変更

この承認境界は、次回の記事でAGENTS.mdへ落とし込みます。

この方法で避けられる問題

Chatの会話履歴だけが設計の根拠になる

確定内容をADR、要求仕様、計画へ保存するため、後から判断理由を追跡できます。

WorkとCodexで前提がずれる

両者が同じGit管理ファイルを参照するため、会話ごとの説明差を減らせます。

Issueが実装構造と一致しない

Issue登録前に、独自WSL2環境のCodex CLIが現在のコードと照合します。

GitHubへ誤って書き込む

草案作成、重複確認、登録予定のレビュー、作成を別段階にします。

長い会話を何度も読み直す

主要な節目でMarkdownへ圧縮し、新しいタスクは必要なファイルから開始します。

DesktopのWSL実行先が期待と異なる

非既定の独自WSL環境に依存する処理をCodex CLIへ固定するため、DesktopのAgent選択に依存しません。

注意点

ChatGPTのGitHub接続をIssue作成手段と決めつけない

公式ヘルプで案内されている用途は、リポジトリのコードや文書を取得し、検索・分析・引用することです。本記事では、Issue作成などの書き込みはGitHub CLIへ分けます。公式FAQ

`Add to task`を永続的な共有メモリと考えない

現在のタスクへ短期的にコンテキストを持ち込む機能として使い、将来の別タスクにも必要な情報はGitへ保存します。

Web WorkとデスクトップWorkは同一履歴ではない

Web／モバイルのクラウドWorkと、デスクトップのローカルWorkは同期範囲が異なります。ローカルファイルへ直接成果物を残したい場合は、デスクトップのローカルProjectを使います。WorkとCodexのFAQ

Issue登録後の運用状態はGitHubを正本にする

Markdown草案とGitHub Issueを手作業で双方向同期すると、どちらが最新か分からなくなります。登録前の設計資料と、登録後のタスク状態を分けます。

GitHub CLIのオプションは実環境で確認する

--type、--parent、--blocked-byなどを使う前に、対象環境のgh issue create --helpを確認します。GitHub Enterprise Serverや組織設定によって利用できる機能が異なる場合があります。

まとめ

Chat、Work、Codex CLIは連携できます。しかし、三者がすべての会話履歴を自動的に共有するわけではありません。

今回の推奨構成は次のとおりです。

Chat
└─ 問題整理、比較、設計判断

Work
└─ 要求、ADR、計画、Issue草案

Gitリポジトリ
└─ 三者が参照する確定情報

独自WSL2環境のCodex CLI
└─ 現在のコードとの照合、実装、検証

GitHub
└─ Issue、Pull Request、Actions、日々の進捗

短期的な受け渡しにはAdd to taskを使えます。

長期的な受け渡しには、次をGitへ残します。

AGENTS.md
docs/requirements/
docs/adr/
docs/plans/
docs/issues/
docs/handoffs/

最も重要な原則は次のとおりです。

会話は考えるために使う。
Workは考えをレビュー可能な成果物へ変える。
Codex CLIは成果物を現在の実装へ照合して実行する。
GitとGitHubは確定した情報と作業状態を残す。

次回は、WSL2上で安定稼働しているCodex CLIのFull accessを維持しながら、安全なローカル操作は止めず、GitHubへの書き込み、破壊的操作、スコープ拡大だけを承認境界にするAGENTS.md設計を扱います。

参考資料