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

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

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

最初にNetsujoが採った対策は、引き継ぎ元と引き継ぎ先のチャット名称を完全一致させることでした。この対策は撤回しました。

現在の結論は次のとおりです。

チャット名は人間向けの任意ラベルです。作業の同一性は`WORK_ITEM_ID`が持ちます。

チャット名はツールごとに違っていて構いません。識別子、認可の対象、mutationのGateとしては使いません。

Incident Card

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

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

FALSE_ASSUMPTION:
一覧で同じ案件をまとめられないことが問題なので、名称を揃えれば引き継ぎは安定する

ROOT_CAUSE:
作業の同一性を、ツール横断で安定しない表示ラベルへ載せていた

IMMEDIATE_FIX:
名称完全一致を必須にした（2026年8月21日公開・のちに撤回）

SYSTEM_FIX:
安定識別子をWORK_ITEM_IDへ移し、チャット名を非authoritativeなラベルへ格下げした

REMAINING_RISK:
WORK_ITEM_IDも人間とAIが転記する値であり、live stateとの照合を省略すれば同じ取り違えが起きる

名称を揃えるルールを、いったん入れた

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

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

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

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

そこで2026年8月21日、次の契約を導入しました。

• 引き継ぎ先のチャット名称を引き継ぎ元と完全一致させる
• 名称が一致しない状態ではコード変更、push、merge、deployを開始しない
• 名称変更機能を確認できない場合、高リスク操作を止める

一覧性は多少改善しました。サイドバーで同じ案件の会話が隣り合うようになり、候補を絞る手数は減りました。

名称完全一致が生んだ4つの副作用

一方で、運用してみると次の4つが出ました。

いちばん重かったのはfalse blockerです。名称の不一致はコードの状態と無関係です。にもかかわらず、mutationを止める条件に載せていたため、「止める理由がないのに止まる」状態を作りました。

停止条件が実態と結びついていないと、運用者は停止を回避する方向へ動きます。回避が常態化した停止条件は、必要な場面でも効きません。

チャット名は識別子ではない

チャット名に求めていた役割を分解すると、次の2つが混ざっていました。

1. 人間が一覧から候補を絞るための索引
2. 同じ作業であることを機械的に判定するための識別子

1は名前で構いません。2は名前では務まりません。理由は次のとおりです。

• 表示名はツールが自由に変更でき、変更履歴が残らない場合がある
• 同じ文字列を複数の会話が持てる
• 名称変更機能の有無がツールによって異なる
• 一致判定に全角・半角、空白、記号の揺れが混入する

識別子に必要な性質は、一意であること、変わらないこと、そして機械が照合できることです。表示ラベルはどれも満たしません。

正本にする識別情報

現在の契約では、次を作業の正本（AUTHORITATIVE_IDENTITY）とします。

チャット名はこの表に入りません。人間が探すためのラベルとして、引き継ぎ本文の冒頭に併記するだけです。

引き継ぎヘッダー

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

WORK_ITEM_ID:
PREDECESSOR_WORK_ITEM:
SUCCESSOR_WORK_ITEM:

EXECUTOR:
ROLE:

REPOSITORY:
PR:
BRANCH:
CURRENT_HEAD_SHA:
BASE_SHA:

CURRENT_STATUS:
BLOCKERS:
AUTHORIZED_ACTIONS:
PROHIBITED_ACTIONS:
NEXT_ACTION:
COMPLETION_CRITERIA:
TERMINAL_RECEIPT:

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

mutationのGateに使う値を入れ替える

停止条件は「表示上の食い違い」ではなく「操作対象の不確定さ」に紐づけます。

# 旧（撤回）
if TARGET_CHAT_NAME != SOURCE_CHAT_NAME:
    STATUS = BLOCKED_METADATA
    MUTATION = NOT_PERFORMED

# 現行
if WORK_ITEM_ID is missing:
    STATUS = BLOCKED_IDENTITY
    MUTATION = NOT_PERFORMED

if CURRENT_HEAD_SHA != live head of BRANCH:
    STATUS = BLOCKED_STALE_STATE
    MUTATION = NOT_PERFORMED

if action not in AUTHORIZED_ACTIONS:
    STATUS = BLOCKED_AUTHORITY
    MUTATION = NOT_PERFORMED

3つとも、止めるべき実態と1対1で対応します。名称が違うだけでは止まりません。SHAが古ければ止まります。

チャット名の変更機能があるかどうかは、この判定に登場しません。rename capabilityは、もはや高リスク操作のblockerではありません。

判断を変えた記録

このシリーズは、判断を変えた事実も残します。

旧ルールを黙って消さずに残す理由は2つあります。第一に、同じ設計を検討している読者が、名称一致を選んだときに何が起きるかを事前に知れることです。第二に、Netsujo自身が同じ提案を再び採用しないための記録になることです。

よくある失敗

表示名を認可の判断材料にする

表示名は誰でも変更できます。権限の判断はROLEとAUTHORIZED_ACTIONSで行います。

PR番号だけを識別子にする

successor PRへ移ったときに参照が古くなります。PRは操作対象の所在であって、作業単位の識別子ではありません。

同じ`WORK_ITEM_ID`なら同じ状態だと思う

同じ作業であることを示すだけです。branch、HEAD SHA、statusは必ずlive確認します。

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

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

引き継ぎの要約だけを渡す

「CIはGREENです」という要約からは、workflow、run、対象SHA、required checkかどうか、skipされた検査、PR HEADがその後進んだかが分かりません。Narrative（なぜ・何が起きたか）とState Evidence（repository、PR、HEAD SHA、CI run、承認、blocker）を分けて渡します。

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

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

導入後に測ること

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

現時点で確認できるのは、契約をWORK_ITEM_ID基準へ変更したことと、名称不一致によるfalse blockerが停止条件から外れたことです。削減時間の定量データは未計測です。 運用ログを蓄積し、重複調査時間と引き継ぎ失敗件数で評価します。

Evidence

適用限界

• Netsujoの少人数・高頻度なAI開発運用から得た知見です。組織規模、規制、障害許容度が異なれば必要な統制強度は変わります。
• WORK_ITEM_IDの付与規則そのものは、案件管理システムの有無によって設計が変わります。本記事は識別子を分離する原則だけを扱います。
• 本記事はチャット横断の作業識別を扱います。Git worktreeの実装手順、CI rerunの診断、Production verificationは別の回が担当します。

残るリスク

• WORK_ITEM_IDも人間とAIが転記する値です。転記ミスは残ります。
• 引き継ぎ本文のlive stateは、書いた時点の値です。作業開始時に取り直さなければ古くなります。
• 引き継ぎ後に別のAgentが同じPRを更新する可能性があります。
• AIがCURRENT_HEAD_SHAを自己申告しても、実際のリポジトリと一致するとは限りません。照合は実コマンドで行います。

まとめ

同じ案件を複数のAIへ引き継ぐとき、揃えるべきものは名前ではありません。

WORK_ITEM_ID（安定識別子）
+
前後関係
+
repository / PR / branch / HEAD SHA
+
現在状態と権限と完了条件

チャット名は、人間が一覧から探すための任意ラベルとして併記します。ツールごとに違っていても、作業の同一性は損なわれません。

よくある質問

チャット名をツールごとに変えてもよいのですか

構いません。チャット名は人間向けの表示ラベルです。作業の同一性はWORK_ITEM_IDが持ちます。名称を揃えたい場合も、揃えること自体を作業開始の条件にはしません。

以前は名称完全一致を必須にしていたと聞きました

2026年8月21日に導入し、2026年8月25日に撤回しました。一覧性は多少改善しましたが、ツール間のrename能力差、同名重複、名称違いだけで作業が止まるfalse blocker、転記負担を生みました。停止条件は操作対象の実態へ紐づけ直しています。

チャット名を変更できないツールを使っている場合はどうしますか

そのまま使えます。名称変更機能の有無は、現在の契約では高リスク操作のblockerではありません。引き継ぎ本文の冒頭にWORK_ITEM_IDと現在状態を記載します。

WORK_ITEM_IDはどう決めますか

作業単位で一意になり、途中で変わらない文字列であれば形式は問いません。Netsujoでは日付と作業内容を含む文字列を使っています。既存の課題管理システムがあれば、そのチケットIDをそのまま使う方法が転記ミスを減らします。

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

長時間化すると、古い前提、膨張したコンテキスト、途中の状態変更を追いにくくなります。継続する場合もWORK_ITEM_IDと現在状態を明記し、前の作業単位をPREDECESSOR_WORK_ITEMとして残します。