Agentに業務資料の整理や共有レコードの更新を任せると、ほかの人は元資料を一から読み直さずに仕事を進められます。ただし、確認とマージを終えた値でも、資料の読み違い、確認漏れ、後から得た確かな証拠によって誤りが見つかることがあります。
値だけを書き換えると、次の担当者には変更理由が伝わりにくくなります。レコード全体を古い版に戻すと、その後に確認された正しい更新まで上書きするおそれがあります。誤った値を使ったレポートや書き出しがあれば、表の一項目を直すだけでは対応は終わりません。
Busabaseのレコードには現在の内容と履歴があり、ChangeRequestには変更とレビューの経緯が残ります。誤りを入れた変更を特定し、確かな資料を根拠に必要な範囲だけ修正を提案し、正式レコードと既知の利用先を確認する。この流れなら、値とともに、次にその値を使う人の判断根拠も整えられます。
まず誤りの利用を止める
誤った値をまだ参照している人や処理を確認します。管理権限のある範囲で該当する自動処理を一時停止し、記録の責任者に判断の保留を依頼します。一つの項目の問題を、知識ベース全体の無効化に広げる必要はありません。
記録へのリンク、現在の版、問題の項目、発見の根拠を残します。見覚えのある昔の値へすぐ戻すと、その後の正当な更新まで失うかもしれません。目標は、今の記録を正確にし、理由を追えるようにすることです。
元の変更と事実を照合する
Busabaseのレコードには現在の内容と履歴があります。ChangeRequestは変更と審査状態を保持し、マージでレコードのcommit参照が進みます。過去のcommitが残るため、訂正も新たな変更として記録できます。
詳細と履歴から問題を持ち込んだ変更を探し、変更前後の値、出所、審査を確認します。契約書、システムの受領記録、責任者による確認などと照合してください。エージェントの自己申告は手がかりであり、置き換える値には根拠が必要です。資料の整理には出典と添付による証拠の残し方も使えます。
訂正の範囲を提案にする
元の業務Baseはそのまま使います。調整が必要な案件には、補助的な「データ訂正」Baseを設けられます。分かる件名、対象レコードとの関連、項目、現在値、提案値、証拠の場所、元と訂正のChangeRequestリンク、担当者、状態、下流の検証結果を保存します。実際のschemaに合わせるための初期設計です。
接続済みエージェントには「最新レコードと指定資料を読み、訂正が必要な項目だけを示す。他の確認済み項目は保ち、元の変更との関係を説明する。差分を提示してから許可された権限で提案し、履歴や無関係な更新を消さない」と指示できます。
REST APIで連携する場合も、最新の読み取りから版の根拠を取得して差分を作ります。途中で更新されたら再読して照合します。同時更新の競合はマージ前の古い提案への対処で、マージ後の事実訂正とは役割が違います。
審査者が判断できる差分にする
どの項目が、なぜ誤りで、何に直すのかを示します。根拠と、維持すべき項目も明記します。変更説明には業務上の理由を記載し、元の変更と訂正案件を関連づけます。「正常に戻す」だけでは判断できません。
APIキーの権限により審査待ちになるかが変わります。changeRequestは読み取りと提案ができても自己マージはできません。writeは即時マージが可能です。人の確認が必要なら、キーと明示的な審査設定で担保します。チャットの約束だけに任せません。
正式値と下流を別々に確認する
マージ後に正式レコードを読み直し、訂正値と保持すべき項目を確認します。元の変更、訂正、現在値を追えることを確認し、訂正案件へ結果を戻して責任者の確認を得ます。
誤った値は報告書、書き出しファイル、別のエージェントの文脈にも残り得ます。分かっている利用先、再生成する成果物、担当者、再確認結果を列挙します。外部処理には既存連携、スクリプト、担当者への通知が必要です。訂正記録の保存だけで全利用先が更新されるわけではありません。
過去の版は経緯の確認に役立ちますが、丸ごと戻すと後続の正しい変更も取り消し得ます。現在に対する訂正なら影響を説明しやすくなります。履歴の存在を、全システムの一括ロールバック機能と扱わないでください。
次の人が確認できる状態で終える
正しい値、根拠、履歴、既知の下流対応を責任者が確認できれば、完了を判断できます。不明な利用先は残存リスクとして残します。まず実際の一件を提案、マージ、読み直しまで進め、再利用する確認事項をDocやSkillへ保存します。次のエージェントは正確な現在値と、今回残した指針の両方を利用できます。