AI作業を別スレッドへ引き継ぐとき、成果物だけでなく「作業状態」を渡す

「説明できる引き継ぎ」と「再開できる引き継ぎ」は違う

長いAI作業を別スレッドへ移すとき、最初に作りたくなるのは会話の要約です。

何を作ったか、どんな方針だったか、成果物は何か。これらは背景を理解するには役立ちます。

しかし、次のスレッドが実際に外部サービスを操作するなら、それだけでは足りません。

どのサイト、どの記事、どのCMSレコードを対象にするのか。すでに何を実行し、何が未確認なのか。次の操作は何か。

これらが欠けると、説明は理解できても、作業を安全に再開できません。

引き継ぐのは成果物ではなく「状態」

海辺の部屋では、長期AI作業の引き継ぎを「会話のまとめ」ではなく、作業状態の保存として考えます。

最低限、次の情報を残します。

• TARGET：対象サイト、対象データ、対象ページ
• STATE：現在どこまで進んでいるか
• IDs：サイトID、記事ID、レコードIDなどの識別子
• DONE：すでに実行した操作
• FAILED：失敗した方法、戻る必要のない経路
• UNKNOWN：未確認・未検証の項目
• NEXT：次に行う具体的な操作
• DO NOT CHANGE：固定ルール、変更してはいけない設計

この8項目があれば、次のスレッドは「何の続きか」を理解するだけでなく、対象を固定して次の操作へ進みやすくなります。

IDは「技術情報」ではなく、再開地点の一部

記事タイトルや商品名だけでも、人間には対象が分かることがあります。

しかし、外部サービスでは同名の下書きが複数存在したり、表示名が後から変わったりすることがあります。

そのため、次のAIがAPI操作を続ける必要があるなら、対象IDも引き継ぎます。

IDはコード担当者だけが見る細かい情報ではなく、「どの対象の続きを操作するか」を固定するための状態情報です。

失敗した経路も引き継ぐ

引き継ぎでは、成功した作業だけを書きたくなります。

しかし、次のスレッドが同じ失敗を繰り返さないためには、「すでに試してうまくいかなかった経路」も重要です。

たとえばMedia Managerの文字検索では見つからなかった、特定のAPIレスポンスは大きすぎた、Editorでしかできない設定だった、という情報です。

原因が未確認なら、失敗した事実と原因の推測を分けて残します。

未確認事項は「空欄」ではなく、作業項目として残す

「分からなかったこと」を省くと、次のAIはそこを確認済みだと誤解する場合があります。

そこで、送信済みだが読み戻していない、CMSには保存したが公開画面は見ていない、対策は決めたが効果は測っていない、といった状態をUNKNOWNとして明示します。

未確認を残すことは、引き継ぎの不備ではありません。

どこから検証を再開すればよいかを次の担当へ渡すことでもあります。

「次の操作」を具体的に書く

引き継ぎの最後を「今後も改善する」「続きから進める」で終えると、次のAIが再び工程を設計し直す必要があります。

そのため、NEXTには「何をするか」を具体的に残します。

たとえば「既存KnowledgeのdirectAnswerと主要H2を確認して重複判定する」「このIDの下書きをGetで読み戻す」「Hero画像をCMSのheroImageへ登録する」といった形です。

次の操作が明確なら、人間がもう一度長い説明をする必要が減ります。

変更してはいけないものも残す

長期プロジェクトでは、次のスレッドが「より良くしよう」として、すでに確定した設計をやり直してしまうことがあります。

そこで、DO NOT CHANGEとして固定ルールも残します。

Knowledgeなら、1テーマ1回答、Heroのトンマナ、本文の行間、著者URL、URL設計、人間へコード作業を戻さない、といったルールです。

引き継ぎは「自由に考え直すための資料」ではなく、すでに決まったものと未決定のものを分ける資料でもあります。

Projectsはコンテキストを保つが、運用状態は明示して残す

OpenAIのProjectsは、関連するチャット、ファイル、指示をまとめ、継続的な作業で同じコンテキストを利用できる仕組みです。

Workでも、長い作業中にユーザーが進捗を確認し、質問へ答え、方向を変え、重要な操作を承認できる設計が示されています。

ただし、「TARGET / STATE / IDs / DONE / FAILED / UNKNOWN / NEXT / DO NOT CHANGE」という引き継ぎ形式はOpenAIの公式仕様ではありません。

海辺の部屋が、複数スレッド・外部サービス操作・長期CMS運用を継続する中で整理した実務上の方法です。

再開可能な引き継ぎの基本形

1. プロジェクトの目的を1〜2文で残す
2. 現在の対象と識別IDを残す
3. 完了済みの操作を列挙する
4. 失敗した経路と原因未確認を分けて残す
5. 未確認事項を明記する
6. 固定ルールと変更禁止事項を残す
7. 次に行う操作を具体的に書く

良い引き継ぎの基準は、文章が詳しいことではありません。

次のAIが、ユーザーへ同じ説明を求めず、その地点から安全に作業を再開できることです。

再開案は、保存先の現在地と照合してから使う

引き継ぎに「次の記事」が書かれていても、再開までの間に別の作業が進んでいる可能性があります。その案をそのまま実行する前に、保存先の直近の内容と比べます。

可児波起が「海辺の部屋」のブログ制作を再開した会話では、ChatGPTは最初に、公開済みの子記事3本を束ねる「ChatGPT Workの使い分け」のまとめ記事が次だと説明しました。続いて本人が「直近の記事を読んで、wix内部から」と指示すると、最後の応答では、Wix内部の記事を読み直し、ECの客単価を扱う記事を新規公開したと報告しています。

原文を比べて確認できるのは、最初に示した再開案と、現物を読むよう求めた後の制作報告で、対象のテーマが異なることです。なぜ変わったのか、どちらが当時の正しい再開地点だったかは、会話本文だけでは確定できません。

この事例から整理した再開手順は、まず引き継ぎにある対象と次の工程を控え、次に同じ保存先の直近の記事・更新日時・作業メモと照合することです。食い違いがあれば、古い案を黙って実行せず、どの情報を根拠に何を再開するかを決め直します。これは今回の原文比較から提案する手順であり、手戻りが減った効果まで測定したものではありません。

このKnowledgeの関連知識

共有ファイルへ応用： 作業状態だけでなく、複数Projectで共有する人物像ファイルも版と適用範囲を明示する。

人物像ファイルを複数プロジェクトで共有するとき、同じファイル名を「同じ版」とみなさない

現在地： AI WORKFLOW → 長時間作業・状態引き継ぎ

Knowledgeトップを見る