同じ案件なのに、
チャット名が違う

ChatGPT、Claude Code、Codexを同じ開発案件で使っていると、実装より先に「どの会話が続きなのか」を探す時間が増えることがあります。

Netsujoでも、同じ案件のチャット名称がツールごとに異なり、後継チャット、停止済み作業、Pull Requestとの対応を追いにくい状態が発生しました。

結論は単純です。

**AI間で作業を引き継ぐときは、引き継ぎ元と引き継ぎ先のチャット名称を完全一致させます。**

ただし、名称を揃えるだけでは足りません。同名チャットの重複や途中から分岐した作業を識別するため、WORK_ITEM_ID、PREDECESSOR_CHAT、repository、PR、現在のHEAD SHAも一緒に渡します。

Incident Card

~~~text INCIDENT: 同じ開発案件を扱うChatGPT、Claude Code、Codexのチャット名称が一致していなかった

SYMPTOM: どの会話が後継か、どの会話が停止済みか、どのPRと対応するかを人間が毎回読み直していた

FALSE_ASSUMPTION: 会話本文を読めば同じ案件だと分かるので、チャット名称は表示上のラベルにすぎない

ROOT_CAUSE: ツールを横断して共通に使える作業識別契約がなく、各AIが独自に名前を付けていた

IMMEDIATE_FIX: 引き継ぎ先のチャット名称を、引き継ぎ元の名称と完全一致させる

SYSTEM_FIX: 名称一致に加え、WORK_ITEM_ID、PREDECESSOR_CHAT、repository、PR、HEAD SHA、状態を必須項目にする

REMAINING_RISK: 同名チャットの重複、名称変更、ツール側の表示制限は名称だけでは解決できない ~~~

小さな不整合が、作業の系譜を壊した

チャット名称の違いは、最初は見た目の問題に見えます。一つの会話だけを使っている間は、本文を開けば何の作業か分かります。

問題は、会話が増えたときに現れます。

• ChatGPTで要件と完了条件を決める
• Claude Codeへ実装を渡す
• Codexへ品質監査を渡す
• CI失敗を別チャットで調査する
• 長時間化した会話を停止し、新しい会話へ継続する
• Owner承認待ちで一度閉じる
• mainが進んだあとに再開する

同じ案件がツールごとに別名になると、一覧を見ただけでは系譜が分かりません。人間は会話を一つずつ開き、repository、PR、SHA、残作業を読み直します。

名称不一致自体はコードを壊しません。実際に観測した事実は、追跡と判断へ余分な時間が必要になったことです。その結果、古い会話からの再開、重複調査、停止済み作業との取り違え、別PRのEvidence混入を早く発見しにくくなります。

チャット名称は、一意なIDではなく人間向けの索引である

人間が最初に見るのはUUIDや内部session IDではなく、サイドバーに並ぶ文字列です。名称は次の一次索引になります。

1. 同じ案件を一覧上でまとめる
2. 引き継ぎ元と引き継ぎ先を照合する
3. 停止済み会話と後継会話の関係を探す
4. repositoryやPRを読む前に候補を絞る
5. 複数ツールを横断する検索語にする

そこで、引き継ぎ時の最初の契約を次に固定します。

~~~text TARGET_CHAT_NAME = SOURCE_CHAT_NAME ~~~

略称、英訳、独自の要約、末尾へのCodex、Claude Code、実装などの追記は行いません。役割は名称ではなくEXECUTORとROLEへ分けます。

完全一致だけでは足りない

名称統一は必要ですが、十分ではありません。長時間化した会話を継続すると、旧チャットと新チャットが同名になります。一つの案件から複数laneへ分岐する場合もあります。

名称は人間が探すための索引です。WORK_ITEM_IDは作業単位の安定識別子です。repository、PR、SHA、状態は「いま何を操作してよいか」を判断するEvidenceです。

引き継ぎヘッダーを固定する

実際の引き継ぎでは、本文の冒頭へ次のヘッダーを置きます。

~~~text SOURCE_CHAT_NAME: TARGET_CHAT_NAME: CHAT_NAME_MATCH:

WORK_ITEM_ID: PREDECESSOR_CHAT: HANDOFF_SEQUENCE:

EXECUTOR: ROLE:

REPOSITORY: PR: BRANCH: CURRENT_HEAD_SHA: BASE_SHA:

CURRENT_STATUS: BLOCKERS: AUTHORIZED_ACTIONS: PROHIBITED_ACTIONS: NEXT_ACTION: COMPLETION_CRITERIA: ~~~

会話のテーマだけでは、現在の操作対象を固定できません。PR番号も可変参照です。CURRENT_HEAD_SHAまで渡し、作業開始時にlive stateと照合します。

名称が違えば、mutationを始めない

ルールは、書くだけでは形骸化します。引き継ぎ先が名称不一致のまま編集、push、review、merge、deployを始めれば、最初の一回で系譜が切れます。

~~~text if TARGET_CHAT_NAME != SOURCE_CHAT_NAME: STATUS = BLOCKED_METADATA MUTATION = NOT_PERFORMED ~~~

名称修正やread-onlyの状態確認は実行できます。コード変更、push、merge、deployなどのmutationは止めます。

ツール側に名称変更機能がない場合は、できない操作を実施したと報告しません。

~~~text CHAT_RENAME_CAPABILITY: NOT_AVAILABLE

CHAT_NAME_MATCH: UNVERIFIED ~~~

機能がないことと、確認を省略することは別です。

引き継ぐのは会話の要約だけではなく、現在状態である

「CIはGREENです」という要約だけでは、workflow、run、対象SHA、required checkかどうか、skipされた検査、PR HEADがその後進んだかが分かりません。

引き継ぎは二つに分けます。

Narrative

なぜこの作業をしているか、何が起きたか、どの判断を採用したか。

State Evidence

repository、PR、HEAD SHA、CI run、review、authorization、blocker、禁止操作。

名称統一は、NarrativeとState Evidenceを同じ作業へ結びつける入口です。

よくある失敗

引き継ぎ先だけ、分かりやすい名前へ改善する

善意でも系譜は切れます。名称改善は元チャットを含めて一括変更できる場合だけ行います。

末尾にツール名を付ける

ツールを変えるたびに名称が変わります。ツール名はEXECUTORへ、Builder、Reviewer、ControllerはROLEへ記録します。

PR番号だけを名称にする

目的が分からず、successor PRへ移ったときに名称が陳腐化します。名称は作業目的、PRはState Evidenceへ分けます。

同名なら同じ状態だと思う

同名は同じ案件である可能性を示すだけです。branch、HEAD SHA、statusを必ずlive確認します。

停止済みチャットを削除する

旧チャットは前提と判断の履歴です。PREDECESSOR_CHATとTERMINAL_STATUSを残して閉じます。

リスクに応じて運用強度を変える

低リスク作業へ重い台帳を持ち込むと、管理コストが価値を上回ります。UNKNOWNは高リスク側へ倒します。

導入後に測ること

このルールの成否は、同じ名称を付けたかだけでは判断できません。

• 後継チャットを探す時間が減ったか
• 同じ調査の重複が減ったか
• staleな会話からの再開をGateで止められたか
• PR、SHA、承認対象の取り違えが減ったか
• 停止済み作業と継続中作業を区別できるか
• 最終報告から会話の系譜を逆引きできるか

現時点では名称統一ルールを導入したことは確認できます。一方、長期的な削減効果を示す定量データはまだありません。運用ログを蓄積し、重複調査時間や引き継ぎ失敗件数で評価します。

残る問題

チャット名称を統一しても、次は残ります。

• ツールによって名称変更機能が異なる
• 同じ名称の複数チャットを一覧で区別できない
• 会話の要約が古い
• repositoryのlive stateが会話記録から進んでいる
• 引き継ぎ後に別Agentが同じPRを更新する
• AIがCHAT_NAME_MATCH: PASSと自己申告しても、実画面と一致しない可能性がある

名称は入口です。最終的な安全性は、Work Item ID、live state確認、Exact SHA、権限分離、Evidence Ledgerによって支えます。

まとめ

同じ案件を複数のAIへ引き継ぐなら、チャット名称を完全一致させます。ただし、名称だけを唯一のIDにはしません。

~~~text 共通名称 + WORK_ITEM_ID + PREDECESSOR_CHAT + repository / PR / HEAD SHA + 現在状態と権限 ~~~

この組み合わせで、会話の読み直しに依存していた引き継ぎを、検証可能な契約へ変えます。

よくある質問

チャット名を同じにすれば、引き継ぎ事故は防げますか

完全には防げません。名称は人間向けの索引です。同名チャットを区別するWork Item ID、前任チャット、repository、PR、現在のHEAD SHA、権限も必要です。

チャット名へPR番号を入れるべきですか

PR番号だけを名称にする方法は推奨しません。successor PRへ移ったときに名称が古くなるためです。名称は作業目的、PR番号はState Evidenceとして分けます。

Claude CodeやCodex側で名称を変更できない場合はどうしますか

変更できないことを明記し、冒頭に正規名称とWork Item IDを表示します。名称一致を確認できない状態をPASSとは記録しません。高リスク操作を続けるかは別のOwner判断にします。

同じチャットを長く使い続ければ、引き継ぎは不要ですか

長時間化すると、古い前提、膨張したコンテキスト、途中の状態変更を追いにくくなります。継続チャットを作る場合も名称を維持し、前任チャットと現在状態を明記します。