チームがAgentを使い始めるとき、まず気になるのは仕事を任せられるかどうかです。別のAgentやサービスへ切り替えるとき、あるいは試用を終えるときには、別の問題が生じます。仕事を新しい担当に渡しても、旧担当のアクセス権や未完了の仕事が自動で引き継がれるわけではありません。
旧Agentには定期実行やレビュー待ちの変更提案が残っているかもしれません。キーの交換が処理するのは一つのアクセス方法です。新Agentがナレッジベースを読めても、完了済みの仕事や未決の提案まで把握したとは限りません。
Busabaseでは正式レコード、変更提案、提出履歴をそれぞれ確認できます。古いチャットを転送するだけで済ませず、旧実行入口の停止、新しい認証情報の権限、未決提案の担当、引き継ぎ元となる正式レコードを確認します。既存の仕事を残しながら、新旧の担当が同じデータを重複して変更する事態を避けるためです。
接続先だけでは引き継げない
エージェントや委託先が変わっても知識ベースは維持できます。確認すべきは、旧担当がまだ何を実行できるか、未決の提案は何か、新担当がどの版を使うかです。
実行入口、認証情報、ChangeRequest、正式レコードの四つに分けます。予定の停止は今後の起動に、認証情報の失効はその経路のアクセスに、提案の処理は未反映の変更に関わります。レコードと履歴は業務の継続を支えます。一つの操作ですべては終わりません。
呼び出し元と管理者を把握する
スケジューラ、配置済みスクリプト、MCP接続、手動の入口を列挙します。アカウント、キーの安全な名称や接頭辞、権限、有効期限を記録します。完全なキーは交接表に保存しません。各入口を止める権限のある人と、実行状態を見る場所も明確にします。
今後の起動を責任者が止めた後、実行中の処理や外部で受理済みの作業を確認します。スケジュール停止と外部作業の取り消しは別のシステムで扱います。BusabaseのBaseやSkill自体が外部スケジューラを停止するわけではありません。
キーは一つの空間専用ではない
APIキーの説明では、キーはアカウントに属し、そのアカウントが参加する複数空間で使えます。x-busabase-spaceは要求先の選択です。実効権限はキーのレベルと空間での役割の共通範囲です。このヘッダーだけでキーの利用先を一空間に制限したことにはなりません。
新担当には独立したキーを作り、必要最小限の権限と期限を設定します。readは読み取り、changeRequestは読み取りと提案で自己マージ不可、writeは審査とマージ、manageは管理と永久的なノード削除まで含みます。人の承認が必要な更新はchangeRequestから始めます。
旧キーは権限のある担当者がAccount → API Keysで管理します。削除は即時失効し、取り消せません。共有している全連携に影響するため、共有の有無を先に確認します。MCP/OAuthは実際の提供者の認可管理で扱い、一つのキー削除を全接続の撤回と説明しないでください。
審査待ちを処理し、元の作者を残す
旧担当の未マージChangeRequestを列挙し、対象、項目差分、根拠、状態を確認します。妥当なものは権限を持つ審査者へ、不要なものは責任者が製品の対応する却下やクローズ操作で扱います。交代を理由に全件承認してはいけません。
キー失効で待ち行列が自動的に空になるとも考えません。失効は今後の要求、提案は独立したライフサイクルです。新担当は正式値と関連提案を読んで未完了を整理します。新提案が必要なら元提案をリンクして差を説明し、競合する重複を避けます。元の作者と提出履歴は維持します。
新担当の最初の仕事を限定する
既存タスクBaseに交接レコードを置けます。件名、旧新の実行主体、入口一覧、安全なキー参照、未決提案、業務レコードとの関連、責任者、残件、検証結果を保存します。アクセスと承認規則はDoc、繰り返す手順はSkillに残し、項目は既存schemaに合わせます。
最初の指示は「指定レコード、交接Doc、待ち提案を読み、現在の版、残件、重複しそうな変更を報告する。外部送信の引き継ぎや旧提案の承認は行わない。必要な修正は差分を示して現権限で提案する」とできます。
個人エージェント用データベースは文脈を残せますが、旧チャットの値を現在の事実と扱わず、正式状態を読み直します。
三種類の確認を分けて完了にする
旧キーの失効は提供者の状態や許可された低リスク確認で責任者が検証します。実送信、支払い、削除を試験に使いません。新キーでは指定資料を読めるか、承認が必要な場面で自己マージせず提案できるかを確認します。計画を成功結果として記録しません。
提案の処置、残件の担当者、正式レコードの継続利用も確認します。失効はマージ済みデータを戻す操作ではありません。誤データは別途訂正します。移行中に実行が重なる場合は並行更新の版確認を使い、正当な変更を守ります。
四つの系統すべてに担当者、結果、残件があれば、引き継ぎを判断できます。渡すのは古いキーと曖昧な指示ではなく、制御されたアクセスと追跡できる仕事です。