Agentの提案を審査すると、承認か拒否より先に、出典の追加や一項目の訂正を頼むことがあります。具体的に伝えた分だけ次の確認は軽くなるはずですが、戻った内容が元と同じ対象を変更しているか、再確認が必要になることがあります。
修正のたびに新しい提案を作ると議論が切れます。「修正済み」だけでは付随変更が見えません。元の指摘、修正後の内容、正式なレコードを追跡できて初めて、改訂が審査の負担を減らします。
BusabaseのChangeRequestは審査前の変更を保存します。審査中は提案の差分、マージ後は正式レコードを見て、判断どおりに反映されたかを確認します。
対象、問題、受け入れ条件を明確にする
「もっと良くして」だけでは、自由な再生成になりがちです。どの項目に何が不足し、何があれば受け入れられるかを指定します。対象の値に一次資料を追加し、他の項目は維持するよう伝えます。根拠で値を裏づけられなければ、不明と理由を残します。
指摘は元のChangeRequestや対応する操作のコメントに残します。提案全体の問題と単一項目の問題を分けます。前者は全体の再審査、後者は一项内容の修正で足りる場合があります。修正のたびに別の管理表を作る必要はありません。
元の提案で対応できるなら、識別情報と議論を維持します。仕事を分割する必要がある場合は、元と後続の提案の関係と範囲を明示します。等価な二つの提案が同時に承認待ちにならないようにします。
指摘を同じ内容に結びつけておく
修正前に元の提案を開き、対象のレコード、項目、既存の指摘を確認します。必要な変更を整理してから、Agentに対応する修正案を作らせます。全件を再生成する必要はありません。
各修正には、元の値、提案値、根拠、維持する内容を添えます。出典追加の指摘には何を裏づけるかを、更正した値にはその出所を示します。未解決の指摘は一覧に残します。
説明と現在の提案の実際の差分を照合します。範囲が広がった部分は先に確認し、正式レコードが変わっていれば現在の内容に基づいて見直します。議論、修正、審査の対象を明確に保ち、見た版と採用される版の食い違いを防ぎます。
境界のある修正指示を渡す
接続済みAgentには、次のように依頼できます。
この提案とコメントを読み、未解決の指摘を具体的なレコードと項目に対応づけてください。指定内容だけの修正案を作り、前後の値、根拠、未解決事項を示し、他の内容は維持します。修正稿と元の提案リンクを返して比較できるようにしてください。承認、マージ、同じ提案の重複作成は行いません。
人の判断が必要な変更は、提出時に審査を残します。審査者が実際の差分を確認し、マージするかを決めます。Agentの「修正済み」だけで受け入れ済みにはしません。
指摘への回答と現在の全差分を審査する
出典がどこに追加され、値を維持・変更した理由は何か、何が未解決かを一件ずつ確認します。その後、指定外の項目も含む現在の全差分を読みます。Agentの要約だけでは付随変更を見落とす可能性があります。
複数操作は業務上の判断ごとに整理します。同じ規則の通常項目はまとめ、出典の競合、範囲拡大、基準の変更は分けて確認します。一件の修正完了が全体の承認にはなりません。
最小の確認一覧は、元の指摘、対応操作、修正根拠、現在の結果、審査判断を結びます。小規模なら既存コメントと提案で十分です。繰り返す部門間引き継ぎでは、既存タスクBaseに提案の関連、担当者、未解決指摘、受け入れ結果を追加できます。品質基準はDoc、反復手順はSkill、一回の判断は現在の提案に残します。
マージ後は正式レコードで受け入れる
権限ある審査者が受け入れを判断します。マージ後に対象Recordを読み、正式項目が承認した版と一致し、無関係な値が保たれ、出典と履歴が追えることを確認します。実際の記録への反映を確認して修正が閉じます。
下流システムが利用する場合は、依頼範囲に応じて実際の利用結果も調べます。CMSレコードのマージとWebページの正しい表示は別の受け入れ地点です。データ更新の成功だけで、レポート、出力、通知が新値を使ったとは判断できません。
信頼できる改訂は、元の意見から元の修正後の内容、正式な記録へたどれます。次に「修正済み」が戻ったら、元の提案を開いてこのつながりを確認してください。審査の優先度はAI審査のボトルネック、正式な記録の意味はAgentの書き込みを正式な情報にする条件も参考になります。