AIに仕事を引き継ぐとき、成果物だけでは足りない｜別スレッドで「作業状態」を渡す方法

1 日前

読了時間: 4分

更新日：20 時間前

これは、ChatGPTのようなAIと長い仕事をしていて、途中で別のスレッドや別の担当へ移るときに「何を渡せば、その地点から本当に再開できるのか」という話です。

会話を要約して、完成した文章や決まった方針を渡せば十分そうに見えます。

でも、WixやCMSのような外部サービスを実際に操作する仕事では、それだけでは足りない場面がありました。

どのサイトを触っているのか。どの記事なのか。どこまで終わっているのか。何を試して失敗したのか。次に何をするのか。

こうした「作業状態」が抜けると、説明は理解できても、次のAIが安全に作業を再開できません。

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

僕が最初に作っていた引き継ぎは、成果物や方針の説明が中心でした。何を作ったか、どんな文章にするか、SEOをどう考えるか。読む側には分かりやすい資料です。

ところが実際にWixへ接続し、記事やCMSを操作する作業では、「対象サイトを確認済み」「更新操作が可能」「どのIDを操作している」といった情報も必要でした。

文章が詳しいことと、続きを安全に実行できることは別です。

そこで今は、長いAI作業を引き継ぐとき、会話の要約とは別に作業状態を残します。

TARGET：対象サイト・ページ・データ。STATE：現在どこまで進んでいるか。IDs：サイトIDや記事ID。DONE：実行済み。FAILED：失敗した方法。UNKNOWN：未確認。NEXT：次の具体的操作。DO NOT CHANGE：すでに固定したルール。

この8項目はOpenAIの公式仕様ではなく、僕が複数スレッドと外部サービスをまたぐ作業を続ける中で整理した実務上の型です。

人間なら記事名やページ名だけで対象が分かることがあります。でもAPI操作では、同じ名前の下書きが複数あったり、表示名が後から変わったりします。

次のAIが同じ対象を触る必要があるなら、IDも状態の一部です。どの対象の続きを操作するのかを固定するために残します。

引き継ぎでは成功したことだけを書きたくなります。でも、同じ失敗を繰り返さないためには、すでに試してうまくいかなかった方法も重要です。

原因が分からない場合は、失敗した事実と原因の推測を分けます。さらに「CMSへ保存したが公開画面は未確認」のような状態もUNKNOWNとして残します。

未確認事項を書くのは不備ではなく、次にどこから検証を再開するかを渡すことです。

実際、ある引き継ぎでは内容を22項目まで増やしても、対象サイトIDや下書きIDが抜けていました。情報量が増えれば自動的に再開しやすくなるわけではありません。

大切なのは、背景を全部説明することではなく、次のAIが対象を取り違えず、同じ地点から次の操作へ進めることです。

なお、この形式だけで毎回完全に再開できることを比較実験で証明したわけではありません。実運用で見つかった不足をもとに整理した設計です。

AIへの引き継ぎで渡すべきなのは、完成した成果物だけではありません。

何を対象にし、どこまで終わり、何が失敗し、何が未確認で、次に何をするのか。その「作業状態」まで残すと、次のスレッドで人間が同じ説明をやり直す量を減らせます。

良い引き継ぎの基準は、文章が長いことではなく、その地点から実作業を再開できることだと考えています。