top of page

KNOWLEDGE

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

​著者:可児波起

​確認日:

2026年9月22日

​更新日:

2026年9月25日

ANSWER

​【結論】

AI作業を別スレッドへ引き継ぐときは、完成した文章や要約だけでなく、「何を対象にしているか」「現在どの状態か」「どのIDを操作しているか」「何を実行済みか」「何が失敗・未確認か」「次に何をするか」「変更してはいけないもの」まで渡します。引き継ぎの目的は経緯を説明することではなく、次のAIが同じ対象を取り違えず、その地点から実作業を再開できる状態を保存することです。

Explanation

【詳しく解説】


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


長い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が、ユーザーへ同じ説明を求めず、その地点から安全に作業を再開できることです。



このKnowledgeの関連知識


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

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


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

Knowledgeトップを見る

EVIDENCE

【根拠・検証】


この食品小売事業の作業引き継ぎで起きた修正


筆者が支援する食品小売事業のWix Blog作業では、最初の引き継ぎ文がブログ本文、文体、SEO方針など成果物側の説明を中心に作られました。

それに対して可児 波起から、Wixとの接続が確認できたこと、対象サイトを参照できたこと、更新操作が可能だったことも引き継ぎに含めるよう訂正が入りました。

この訂正により、成果物の要約だけではなく、接続状態や実行可能範囲も引き継ぐ必要があることが明確になりました。



22項目へ拡張しても、対象IDが欠けた


その後、引き継ぎ内容は22項目まで拡張されました。

しかし採掘記録では、対象サイトを一意に識別するサイトIDと、作成されていた2件の下書きIDが引き継ぎ文から欠落していたと整理されています。

文章量が増えれば自動的に再開しやすくなるわけではなく、対象を固定する識別情報が必要だと分かった例です。



このEvidenceで確認できていないこと


改訂後の引き継ぎ文を新しいスレッドへ渡し、その内容だけで問題なく作業を再開できた、という結果までは採掘記録では確認されていません。

そのため本ページでは「この形式なら必ず再開できる」と実証済みの効果としては書いていません。

確認できた引き継ぎ上の不足と、それを元に整理した再開可能な状態保存の設計として扱っています。

SOURCES

【情報源】

Author

【著者】

可児 波起

​マーケティングデザイナー / DXコンサルタント / 音楽家

次に読む

共有ファイルへ応用

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

作業状態だけでなく、複数Projectで共有する人物像ファイルも版と適用範囲を明示する。 この記事では、AIの人物像・方針ファイルを複数プロジェクトで共通利用するときは、同じファイル名だからといって同じ内容・同じ版だとみなさない方が安全です。可児 波起が国際ニュースやSNS資料をChatGPTと読み解き、背景・構造・自身の見解を整理した「世界情勢」プロジェクトでは、同名の「波起人物像.docx」が3スレッドに登場しましたが、今回の採掘ではファイルID、ハッシュ、更新日時、版番号まで確認できませんでした。

このテーマをもっと見る

長時間作業・状態引き継ぎ

工程分割、並列スレッド、作業状態、コンテキスト版管理を扱う。 現在、このテーマには4件の主要Knowledgeがあります。

上位カテゴリ

AIとの仕事設計(AI WORKFLOW)

人間の判断を残しながら、長時間・複数工程の仕事をAIへ任せるための運用設計。

すべてのテーマから探したい場合は、Knowledge一覧へ戻る。

bottom of page