二つのAgentが同じレコードを読み、それぞれ妥当な変更を提案しました。個別に確認すると問題がなくても、一方が先にマージされれば、もう一方は古い内容に基づく提案になります。
審査は変更を受け入れてよいかを判断し、版の確認はその提案を今も同じ形で反映できるかを判断します。共有する業務表には両方が必要です。
読んだ版を提案と一緒に保つ
BusabaseのChangeRequestは変更と不変のコミット履歴を保存し、マージで正式レコードの参照先を進めます。提案が待っている間にも、別の権限を持つ作成者が正式レコードを更新できます。
読み取り時の版を保存してください。現行のレコード変更APIはbaseCommitIdで基点となるコミットを指定できます。連携時には最新APIの形を確認します。レコードIDだけでは、変更判断に使った内容が失われます。
確認する側が元の値、提案値、現在値を比べられることが重要です。書き込みたい最終値だけでは、古い前提が見えません。
同じフィールドと別フィールドを分けて考える
同じフィールドの競合では、どの値が根拠に合うか、新しい資料から提案し直すべきかを判断します。後の提案が正しいとは限らず、承認済みでも古くなる場合があります。
別のフィールドも意味が関連することがあります。要約と本文、段階と次の行動は、別項目でも同じ判断に依存します。構造上重複しないだけで、業務上整合するとは言えません。
送信するのは必要なフィールドの差分に絞ります。以前読んだ全レコードを戻すと、無関係な古い値まで含める恐れがあります。差分は影響範囲を減らしますが、意味の整合性を自動で解決しません。
回復できる更新手順を作る
既存の業務Baseを再利用し、Docにフィールド責任と競合時のルール、Skillに更新手順を置けます。Agentごとに別の正式表を作ると、さらに突き合わせが必要になります。
現在の記録と版を読む、出典を確認する、必要な項目だけ提案する、基点が変われば再比較する、マージ後に再取得する、という順序です。APIキー権限も合わせます。write権限では即時マージされる場合があり、毎回人の審査があるとは限りません。
現行リクエストの形は次のようにできます。プレースホルダーには実際の読み取り結果とスキーマを使います。
{
"operation": "update",
"baseCommitId": "<直前に読んだ headCommitId>",
"fields": {"<実際のフィールド slug>": "<提案する値>"},
"autoMerge": false,
"message": "変更と根拠を説明"
}
送信先は/api/v1/records/{recordId}/change-requestsです。実行済みテストではなく、接続設計の例です。返された状態を読み、必要に応じて提案と現在のレコードを確認します。意味の自動マージや複数システムをまたぐ取引の保証を前提にしません。
タイムアウト後は元の提案を探す
応答が届かなくても、サーバーには保存済みかもしれません。同じ提案の再作成は重複につながります。
保存した提案IDや業務の安定キーで元のChangeRequestと正式レコードを調べます。マージ済みなら結果確認から続け、審査待ちなら同じ提案を再開します。未作成と確認できた場合に再試行します。冪等キーに対応する作成APIでは、元のキーを使い続けます。
送信済み、結果不明、マージ確認済みをクライアントが区別して保持します。Busabaseの履歴は確認対象を提供しますが、回復方法は連携側にも必要です。
マージ後に重要な項目を再取得する
正式レコードを読み、対象項目が受け入れた値か、変更しない重要項目が適切かを確認します。その後の更新があれば、今回受け入れたコミットと現在版を区別し、正常な後続変更を失敗と取り違えません。
現在の記録と版を読み、必要な項目だけ提案してください。資料や版が変わったら元の値、提案値、現在値を責任者に示してください。応答不明時は元の提案を回復し、マージ後は再取得してください。レコードを重複作成せず、承認をマージ完了と報告しないでください。
同じ表を複数Agentで使えるか
担当レコードや項目、版の確認、最小差分、回復情報を決めれば並行作業を設計できます。意味の関連が強い変更には受け入れ責任者を明確にします。表が業務の意味を自動理解するわけではありません。
承認後にすべて審査し直す必要があるか
基点が同じなら通常のマージと再取得を行います。変化が元の判断に影響した場合に、該当する差分と根拠を再確認します。無制限の二重審査にはしません。
正式な書き込みには根拠と責任が必要です。並行作業では各変更の出発点も残し、一つの共有表で手順を整えてから対象を広げます。