長時間作業・状態引き継ぎ
工程分割、並列スレッド、作業状態、コンテキスト版管理を扱う。
Knowledge → AIとの仕事設計 → 長時間作業・状態引き継ぎ
工程分割、並列スレッド、作業状態、コンテキスト版管理を扱う。
このTopic Clusterには現在6件の主要Knowledgeがあります。下の記事はそれぞれ独立した問いに答えながら、同じテーマを別の角度から補います。
このテーマのKnowledge
1. 人物像ファイルを複数プロジェクトで共有するとき、同じファイル名を「同じ版」とみなさない
AIの人物像・方針ファイルを複数プロジェクトで共通利用するときは、同じファイル名だからといって同じ内容・同じ版だとみなさない方が安全です。可児 波起が国際ニュースやSNS資料をChatGPTと読み解き、背景・構造・自身の見解を整理した「世界情勢」プロジェクトでは、同名の「波起人物像.docx」が3スレッドに登場しましたが、今回の採掘ではファイルID、ハッシュ、更新日時、版番号まで確認できませんでした。
2. AI作業を別スレッドへ引き継ぐとき、成果物だけでなく「作業状態」を渡す
AI作業を別スレッドへ引き継ぐときは、完成した文章や要約だけでなく、「何を対象にしているか」「現在どの状態か」「どのIDを操作しているか」「何を実行済みか」「何が失敗・未確認か」「次に何をするか」「変更してはいけないもの」まで渡します。
AIに長時間作業を任せるときは、作業時間で区切るのではなく、「途中成果を確認できる単位」で工程を分けると安定します。各工程に、目的・入力・完了条件・次工程・必要なら人間の承認ポイントを持たせます。重要なのは細かく分けること自体ではなく、途中で誤りを発見でき、次の工程へ安全に引き継げる大きさにすることです。
ChatGPTを1つの長い会話に集約せず、同じプロジェクト内で「調査」「CMS構築」「著者ページ整備」など役割ごとにチャットを分け、それぞれに工程表と完了条件を持たせると、複数の作業を同時進行しやすくなります。人間は各スレッドの承認・判断ポイントだけに入り、詳細作業はAI側へ残すのが実用的です。
5. ルールをProject Sourceに保存しただけでは引き継げなかった――全文読解と実行直前の再読を工程化した
Knowledge憲法をProject Sourceへ保存した後でも引き継ぎ失敗が起き、開始時の全文読解とHero生成直前の再読へ工程を変更した実例です。
6. AI向けProject Sourcesは増やすだけでは整理できない――正本・旧版・補助資料を分けた実例
同名・旧版系Sourceが複数存在したため、Knowledge憲法を正本、Hero詳細ガイド等を補助、旧Heroルールを削除候補として整理した実例です。
このテーマと交差するKnowledge
「PCでも大きい」「治った」「引き継ぎを上手く出来てない」――短いフィードバックを仕様変更へつなげた実例
長期作業中の人間フィードバックを、次回以降の運用ルールへ蓄積していく更新ループの実例です。
同じPillarの別テーマ
人間の拘束を減らすAI運用 (4件)
承認、通知、拘束時間、人間再介入の設計を扱う。
思考・実行・確認の分離 (3件)
ChatとWorkの役割分担、外部サービス操作の確認状態を扱う。
判断基準・レビュー設計 (4件)
判断基準、生成量と確認量の分離を扱う。
AI漫画のContinuity管理 (2件)
前ページ状態の再注入と、人間によるcontinuity editingを扱う。
上位Pillar
人間の判断を残しながら、長時間・複数工程の仕事をAIへ任せるための運用設計。
全体から探す場合は、Knowledgeトップへ戻る。
CLUSTER
