「招待リンクから団体へ参加する方法を紹介する」というTODOを、複数の会話で見つけた場合を考えます。同じ名前だから既存チケットへまとめると、静止画の制作と動画の制作が一枚に混ざるかもしれません。
集約するときは、作業の対象と成果物を照合します。同じテーマでも成果物が違えば別の作業として残します。既存作業の続きなら、前提と残作業を追記する先を決めます。
以下は2026年9月11日に、SquadNoteのPlaneチケットと固定したGit文書を読み合わせた記録です。説明欄にCodex chatの日付が残っている例を使いますが、会話全文から自動抽出した実験ではありません。チケットを今回作成・統合したわけでもありません。
同じテーマの二枚を、成果物で分ける
確認した制作チケットは、親のSQN-46と、子のSQN-47、SQN-48です。説明を短くすると、次の違いがありました。
| ID | 対象 | 成果物 | 関係 |
|---|---|---|---|
| SQN-46 | Instagram投稿シリーズ | テーマの管理と継続運用 | 親 |
| SQN-47 | 招待リンクからの参加案内 | カルーセル5枚、HTML/CSS、キャプション、altテキスト | 静止画版 |
| SQN-48 | 同じ参加案内 | 縦型MP4、編集ソース、場面画像、字幕、表紙 | 動画版 |
子の二枚にはCodex chat 2026-09-09という出典の記載があり、動画版は静止画版を参照していました。テーマが同じなのは重複ではなく、別の形式へ展開したためです。
Git側でも、静止画版のREADMEはSQN-47、動画版のREADMEはSQN-48へ戻れます。制作の初期履歴560e752、音声付き確認の履歴afcf45f、後続の運用文書e295f5cも読みました。
この場合、二つをまとめると「画像はできたが、動画の字幕はまだ」という状態を一つのDoneで表せなくなります。会話側に同じ表現が出ても、まず納品するものを比べます。
同じ変更を扱う親子は、実行するタイミングを残す
もう一組、SQN-14とSQN-27はどちらもTurnstileの旧版互換バイパスを削除する作業です。こちらは成果物の形式ではなく、実行条件に違いがありました。
SQN-14には、アプリ更新の普及を確認して互換コードを削除する方針があります。SQN-27はその子で、2026-09-10以降に旧版利用状況を確認したうえで最終削除する、という実行条件を具体化しています。説明だけでなく、取得したparentの関係も一致しました。
「旧コードを削除する」という語だけで後から出たTODOを消すと、更新案内の普及を待つ条件まで失います。反対に、同じ削除を独立した二件として同時に実装すれば、作業が重なります。
ここでは、親を背景と全体の条件、子を実行時期が決まった作業として読むことができます。今回読んだ時点では両方Doneでしたが、実運用のログや削除後の本番動作は再確認していません。状態は取得結果、コード削除の正しさは別の検証対象です。
取り込む前に、一行へ圧縮して照合する
会話から候補を拾ったら、いきなり新規チケットを作る前に、次の一行へ直します。
対象のサービス / 変える対象 / 作る成果物 / 完了を確認する条件
招待案内なら「SquadNote / 招待参加の案内 / 縦型動画 / 現行導線と字幕・映像が一致する」です。これで既存チケットを検索し、タイトルだけでなく説明と親子関係を読みます。
一致した後の扱いは、次のように分ける案です。
- 対象・成果物・完了条件が同じなら、既存チケットへ追加情報を集める。
- 同じテーマで成果物が違うなら、関連する別作業として残す。
- 全体方針の一部で、独立して確認できる範囲なら、親子関係を検討する。
- 完了した成果物への修正依頼なら、変更理由と対象版を残し、既存作業の再開か追加作業かを判断する。
文章の類似度を使う場合も、候補を探す補助に留めます。似た文章から、字幕の完了条件や配布待ちの前提を読み取れるとは限りません。
一つの候補に複数の会話が関係するなら、出典を一つへ上書きせず、日付と要点を追加します。ただし、説明欄へ会話全文を貼る必要はありません。秘密情報や検証用の招待URLは転記せず、次の担当者が判断を追える記録へ絞ります。
Doneだけを拾うと、次の残作業を落とす
SQN-48は取得時点でDoneでした。一方、固定したGit文書の公開前検証には、公開用音声の未生成、字幕の発話同期、実操作確認などの残作業が書かれています。
この二つだけから、元のチケットを誤って閉じたとは断定できません。初回制作と、その後の公開準備で範囲が変わった可能性もあります。確認できるのは、Doneという状態だけでは最新成果物をそのまま公開できると判断できないことです。
集約時には、チケットがDoneなら対応不要とする前に、後続の変更がないかを見ます。この例なら、次の内容を残作業の候補として整理できます。
参照元: 動画版のチケットと、固定コミットの公開前検証
現在あるもの: 確認用の無音マスター、編集可能な制作ソース
残作業: 公開用音声、字幕との同期、実操作と投稿画面の確認
完了の証拠: 最終版の検証結果と、承認後の公開記録
これは今回起票した内容ではなく、読み取った資料から作った引き継ぎ例です。公開や有料素材の生成は行っていません。
会話のTODOから、既存のどの成果物を、どの時点から進めるのかを特定します。見つかった文章をすべて新規チケットにする必要はありません。今回の例では、静止画と動画を分けて残し、公開準備の残りを最新のGit文書から確認する必要がありました。