Codexのスレッド管理を任せる前に：検索・ピン留め・worktree・並行タスクの整理手順

このテーマをもう少し広げて見るなら、Codex Worktreesで並列作業する前に決めること と Codex subagentsをチームで使う前に：並列レビュー・権限・コストの境界線 も合わせて確認してください。スレッドをworktreeへ分ける判断と、Localへ戻すHandoffの確認点を続けて読めるため。

3行まとめ

1目的

調査、実装、レビューを分けます。

検索性

タイトルと最終報告の語を揃えます。

人間判断

削除やマージ判断は人間に残します。

管理を任せる前に、管理できる形を決めます。

• Codexのスレッド管理を便利にするには、機能を増やす前に、スレッドを「会話」ではなく「作業単位」として扱うルールが必要です。
• スレッド名、最終報告、ピン留め基準、検索キーワード、worktreeの分け方が揃うと、後から探せる作業ログになります。
• Codexに管理を任せる範囲は、候補整理、要約、関連スレッド検索、作業単位の提案までにし、採用判断、マージ判断、破壊的git操作は人間側に残します。

本文の事実確認には、Codex changelog、CodexのAGENTS.md guide、permissions、OpenAIの安全運用記事を使っています。Xで伸びていたスレッド管理の話題は需要シグナルとして扱い、本文の根拠にはしていません。

この記事でわかること

タスク単位

1スレッド1目的へ分けられます。

命名

対象、目的、状態を入れられます。

ピン留め

残す入口と閉じる作業を分けられます。

worktree

並行差分を混ぜずに進められます。

便利機能ではなく、後から探せる作業ログを作ります。

• Codexスレッドを増やす前に決めるタスク単位
• 後から検索しやすいスレッド名と最終報告の型
• ピン留めするスレッド、閉じるスレッド、残すスレッドの基準
• 並行タスクでworktreeを分ける時の注意点
• Codexに任せる管理と、人間が判断する境界
• スレッド管理が破綻する失敗パターン

前提知識

1. 1目的

   何を終わらせるか決めます。

2. 2権限

   read-onlyかworkspaceか分けます。

3. 3作業

   差分、テスト、未検証を記録します。

4. 4報告

   次の作業へ渡せる形で閉じます。

終わり方が揃うと、検索して再開できます。

Codexを継続的に使うと、スレッドが増えます。最初は「このタスクを直して」「このエラーを見て」で十分でも、数日後には、どのスレッドで何を決めたのか、どの差分が残っているのか、どの作業が止まっているのかが分かりにくくなります。

スレッド管理の目的は、会話をきれいに並べることではありません。次に作業を再開する人が、何を試し、何をやめ、どのテストを通し、何が未検証かを短時間で分かる状態にすることです。

スレッドは作業単位として扱う

1スレッドに複数の目的を詰め込むと、検索しても再利用しにくくなります。バグ調査、仕様確認、実装、レビュー対応、公開作業をすべて同じスレッドで扱うと、後から「どこで何を決めたか」が埋もれます。

確認項目

スレッドを立てる前に、目的、対象ファイル、完了条件、許可する操作、未検証の扱いを決めます。これが決まらない場合は、まず調査スレッドとして始め、実装スレッドへ分けます。

注意点

スレッド数を減らすことが目的ではありません。必要な単位で分け、検索できるタイトルと最終報告を残すことが目的です。

スレッドを増やす前にタスク単位を決める

項目	内容	見方
調査		原因、影響範囲、未確認点を出します。
実装		小さな差分とテスト結果を残します。
レビュー		指摘ごとの対応表を作ります。
公開		確認結果と戻し条件を残します。

権限や目的が変わる時は、スレッドを分けます。

Codexにスレッド整理を頼む前に、人間側でタスク単位の基準を決めます。基準がないまま自動整理しても、単に会話が移動するだけです。

1スレッド1目的にする

おすすめは、1スレッド1目的です。調査、実装、レビュー対応、公開作業、振り返りを分けると、後から検索しやすくなります。

スレッド種別	扱う内容	終了条件
調査	原因、影響範囲、候補ファイル	実装方針と未確認点が出た
実装	小さな差分作成	テスト結果と差分説明が出た
レビュー対応	指摘ごとの修正	指摘対応表が埋まった
公開/運用	デプロイ、確認、戻し方	公開確認とロールバック条件が残った

評価基準

後からスレッド一覧を見て、「これは何の作業か」「終わったのか」「次に何をするのか」が分かるなら合格です。タイトルだけで判断できないスレッドは、最終報告が弱い可能性があります。

分ける条件

対象ファイルが大きく変わる、権限が変わる、worktreeが変わる、レビュー担当が変わる、本番影響が出る。この場合は新しいスレッドに分けます。

調査スレッドと実装スレッドを分ける

調査はread-onlyで始めやすい一方、実装はファイル編集やテスト実行が必要になります。権限が違う作業を同じスレッドに混ぜると、どこから実行境界が変わったのか追いにくくなります。

根拠

Codexのpermissionsでは、read-only、workspace、danger-full-access、custom profileのように実行境界を分けられます。スレッド単位と権限単位を近づけると、レビューが楽になります。

注意点

調査中に実装へ流れそうになったら、一度止めて、実装スレッドへ切り替えます。Codexが「そのまま直せます」と言っても、人間が権限と完了条件を確認します。

命名と最終報告を揃える

項目	内容	見方
対象		component、Issue番号、機能名を入れます。
目的		調査、実装、レビュー、公開を入れます。
状態		原因確認、最小修正、指摘対応を入れます。
報告		結果、未検証、次の作業を残します。

タイトルと最終報告が揃うほど検索が効きます。

スレッド検索を活かすには、検索対象になる言葉を揃える必要があります。タイトルが曖昧で、最終報告が残っていないスレッドは、数日後にほぼ使えません。

タイトルには対象、目的、状態を入れる

タイトルは短くても構いませんが、対象、目的、状態を入れます。

[調査] SearchBox キーボード選択ずれ 原因確認
[実装] SearchBox キーボード選択ずれ 最小修正
[レビュー] SearchBox 指摘対応 focus移動
[公開] SearchBox v1.8.2 確認と戻し条件

確認項目

対象コンポーネント、Issue番号、機能名、目的、状態を入れます。検索で使う語を毎回変えないことも大事です。

注意点

「続き」「修正」「確認」だけのタイトルは避けます。本人には分かっても、翌週の自分や別メンバーには分かりません。

最終報告は毎回同じ型にする

スレッドの最後には、同じ型で報告を残します。

目的:
変更/調査したこと:
実行したコマンド:
結果:
未検証:
次にやること:
関連スレッド:

評価基準

この報告だけで、次のスレッドを始められるかを見ます。次にやることが曖昧なら、そのスレッドはまだ閉じていません。

改善方法

AGENTS.mdに最終報告の型を書いておくと、スレッドごとのばらつきが減ります。チーム導入の土台は、Codex 101をチーム導入へ落とす記事でも整理しています。

ピン留め・検索・アーカイブの基準を作る

Pin

進行中と基準スレッドだけ残します。

Search

対象名やIssue番号で戻れるようにします。

Archive

完了スレッドは報告を残して閉じます。

Weekly

週1回、ピン留めを棚卸しします。

ピン留めが増えすぎると、入口として機能しません。

スレッドが増えた時に大事なのは、全部を残すことではなく、残すもの、閉じるもの、探すものを分けることです。

ピン留めは進行中か基準スレッドだけにする

ピン留めするのは、進行中の大きな作業、プロジェクト全体の方針、週次の進捗まとめ、戻し条件が載っているスレッドに絞ります。

ピン留め候補

種別	ピン留めする理由
プロジェクト方針	判断の基準になる
進行中タスク	次に再開する
リリース確認	戻し条件がある
週次まとめ	作業ログの入口になる

注意点

ピン留めが増えすぎると、ピン留め自体が機能しません。完了した作業や個別調査は、最終報告を残して閉じます。

検索できる語を最初から入れる

検索で効くのは、後から思い出せる語です。コンポーネント名、Issue番号、エラー名、機能名、リリース名、権限名をタイトルと最終報告に入れます。

確認項目

同じ対象を、SearchBox、search box、検索欄のように毎回変えると検索しにくくなります。表記を揃えるだけで、後から探しやすくなります。

評価基準

3週間後に、対象名、Issue番号、失敗したテスト名で検索して目的のスレッドへ戻れるかを見ます。

並行タスクはworktreeと権限を分ける

1. 1Thread

   1目的ごとに分けます。

2. 2Worktree

   1差分ごとに分けます。

3. 3Permission

   調査と実装の権限を分けます。

4. 4Review

   人間が追える数に抑えます。

同じworktreeで複数差分を混ぜないことが大事です。

Codexで複数タスクを並行するなら、スレッドだけでなく作業ディレクトリも分けます。同じworktreeで複数の差分を混ぜると、レビューできない変更になります。

worktreeは差分の境界として使う

git worktreeは、並行作業の差分を分けるために使えます。AIエージェントに複数タスクを走らせるなら、1タスク1worktreeに寄せると、差分、テスト、レビューが分かれます。

条件

worktreeを使う前に、branch名、対象Issue、許可する変更範囲、終了後の削除手順を決めます。作成だけでなく片付けまでが運用です。

注意点

破壊的なgit操作をCodexに任せないほうが安全です。git reset --hard、未確認のbranch削除、worktree削除、force pushは人間承認に残します。

権限もタスクごとに分ける

調査タスクはread-only、実装タスクは限定workspace、外部通信が必要なタスクは別承認にします。スレッドだけ分けても、権限が全て同じなら境界は弱いままです。

評価基準

どのスレッドが、どのworktreeで、どの権限で動いたかを説明できる状態にします。説明できない並行実行は、再現もレビューもしにくくなります。

関連

権限やテストゲートの考え方は、Claude Codeに依存更新を任せる前の記事でも同じです。ツールは違っても、権限、テスト、承認境界は分けて考えます。

Codexに任せる管理と人間が残す判断

項目	内容	見方
任せる		要約、関連スレッド、未完了抽出。
確認する		根拠スレッドと対象ファイル。
残す		優先順位、マージ可否、本番影響。
止める		削除、force push、破壊的git操作。

Codexは管理候補を出す役、人間は判断する役です。

Codexに任せると便利な管理作業はあります。ただし、任せてよいのは整理や候補出しであって、採用判断そのものではありません。

Codexに任せやすいこと

Codexには、関連スレッド候補、未完了タスクの抽出、最終報告の整形、検索キーワードの提案、次に分けるべきスレッド候補を出させると便利です。

依頼例

このプロジェクトの最近の作業ログから、
未完了タスク、関連スレッド、次に分けるべき作業単位を整理してください。
まだファイル編集やgit操作はしないでください。

評価基準

Codexの整理結果に、根拠となるスレッドやファイルが示されているかを見ます。根拠なしの要約は、便利でも信用しすぎないようにします。

人間が残す判断

優先順位、採用する方針、マージ可否、本番影響、削除してよいworktree、ピン留めから外す判断は人間が残します。

注意点

Codexに「古いスレッドを整理して」と頼む時も、削除やアーカイブを自動実行させないほうが安全です。まず候補を出させ、人間が確認します。

改善方法

週末に「今週のCodexスレッド棚卸し」を作ります。進行中、完了、保留、削除候補、次週へ引き継ぐものを一覧化します。

セキュリティ・コスト注意

Secret

tokenやenvを残しません。

Logs

本番ログは抽象化します。

Review

並行数はレビュー帯域に合わせます。

Retention

保存期間と共有範囲を確認します。

スレッド検索が便利になるほど、情報管理も必要です。

スレッド管理は、単なる整理ではありません。スレッドには、ファイル名、エラー、ログ、設計判断、時には機密に近い情報が残ります。

スレッドに残す情報を絞る

secret、顧客情報、本番ログ、社外秘の計画、契約情報はスレッドに残さないようにします。必要な場合は抽象化し、具体値は消します。

確認項目

スレッド共有範囲、保存期間、検索対象、添付ファイル、ログの扱いを確認します。スレッド検索が便利になるほど、不要な情報まで見つかりやすくなります。

注意点

「ローカルだから大丈夫」とは限りません。画面共有、ログ転記、同期、エクスポート、社内検索で広がる可能性があります。

並行タスクのコストを見る

並行タスクは速く見えますが、レビュー、差分整理、テスト実行、マージ順序のコストが増えます。Codexが複数タスクを進めても、人間のレビュー帯域が追いつかなければ詰まります。

評価基準

並行数は、レビューできる数を上限にします。3本同時に進めても、レビューできるのが1本なら、残り2本は古い差分になります。

改善方法

並行タスクは、read-only調査を多め、実装は少なめにします。調査は並行しやすく、実装はレビュー負荷が高いためです。

失敗点とハマりどころ

報告なし

完了か未完了か分からなくなります。

差分混線

複数スレッドで同じファイルを触ります。

Pin過多

重要な入口が埋もれます。

権限混在

調査と実装の境界が曖昧になります。

終わり方を揃えるだけで、かなり迷子を減らせます。

スレッド管理が破綻する時は、スレッドが多いこと自体より、終わり方が揃っていないことが原因です。

最終報告がない

最終報告がないスレッドは、未完了なのか完了なのか分かりません。検索で見つかっても、次に何をすべきか分からないため、結局もう一度調査することになります。

同じ差分を複数スレッドで触る

同じファイルを複数スレッドで触ると、どちらの判断を採用したのか分からなくなります。同じファイルに触る場合は、関連スレッドを明記し、マージ順を決めます。

ピン留めが増えすぎる

ピン留めは重要な入口です。全部をピン留めすると、入口がなくなります。週1回、ピン留めを外す候補を確認します。

実務で使うなら

1. 1日目

   命名と報告テンプレートを決めます。

2. 2日目

   調査スレッドを分けます。

3. 3日目

   worktreeと実装スレッドを紐づけます。

4. 5日目

   ピン留めと完了スレッドを棚卸しします。

1週間だけ試すと、破綻点が見えます。

実務では、スレッド管理をいきなり完全自動化しません。まず1週間だけ、命名、最終報告、ピン留め、worktree分離を試します。

1週間の進め方

1日目に命名ルールと最終報告テンプレートを決めます。2日目に調査スレッドを分けます。3日目に実装スレッドとworktreeを紐づけます。4日目にレビュー対応を分けます。5日目にスレッド棚卸しをします。

スコアカード

評価軸	合格ライン
命名	対象、目的、状態が分かる
最終報告	目的、結果、未検証、次の作業がある
検索性	対象名やIssue番号で戻れる
worktree	1タスク1差分に近い
権限	調査、実装、外部通信が分かれている
レビュー	人間が追える並行数に収まる

関連導線

スレッドをまたぐ文脈管理は、永続メモリの記事と合わせて考えると整理しやすくなります。スレッドに残す情報、AGENTS.mdに置く情報、永続メモリに残す情報を分けるのが出発点です。

FAQ

全部任せるか

整理候補まで任せ、判断は残します。

少ないほど良いか

1目的で分けるほうが探しやすいです。

worktree必須か

並行差分がある時に有効です。

memoryとの順序

まず命名と最終報告を揃えます。

迷ったら、次の人が再開できるかで判断します。

Codexにスレッド整理を全部任せてもよいですか？

候補整理や要約は任せやすいですが、削除、アーカイブ、ピン留め解除、マージ判断は人間が確認したほうが安全です。

スレッドは少ないほど良いですか？

少なければよいわけではありません。1スレッド1目的に分け、最終報告を残すほうが、長期的には探しやすくなります。

worktreeは必ず使うべきですか？

小さな単発修正なら不要なこともあります。複数タスクを並行する場合や、差分を混ぜたくない場合に使うと効果があります。

永続メモリとスレッド管理はどちらが先ですか？

まずスレッドの命名と最終報告を揃えます。そこから、繰り返し使う知識だけを永続メモリ候補にします。

更新履歴

1. 2026年5月31日

   Codex changelog、AGENTS.md guide、permissions、安全運用記事を確認して初版を作成しました。

導入時には最新の公式情報を再確認してください。

2026年5月31日 JSTに、Codex changelog、Codex AGENTS.md guide、Codex permissions、OpenAIの安全運用記事を確認して初版を作成しました。スレッド関連機能は更新されやすいため、導入時には最新の公式情報を再確認してください。

---

次に読むなら

参照した主な情報源

• Codex changelog
• Codex AGENTS.md guide
• Codex permissions
• Running Codex safely at OpenAI