APIキーをWriteに変えると、既存のエージェント処理も即時マージされる?

既存の保持者にも新しい権限が即座に適用されます。承認待ちが続くかは、実際のリクエスト設定で変わります。

Busabase Team
← ブログに戻る
APIキーをWriteに変えると、既存のエージェント処理も即時マージされる?

毎朝Inboxに届いていた変更が、ある日すでに正式レコードへ入っていたら、どこから確認しますか。スケジュールもスクリプトも同じで、エージェントは同じキーを使っています。処理側を調べる前に、アカウントで行われた権限変更を見落としていないか確認する必要があります。

Change RequestからWriteへの変更は、目の前の操作だけに作用しません。同じキーを持つ既存の処理すべてで、次のリクエストの権限上限が変わります。認証情報だけに頼っていた承認待ちは、次回なくなる可能性があります。

Busabaseの仕様では、編集してもキー値と期限は変わらず、新レベルが既存保持者に即座に適用されます。実際の結果はスペースのロールとリクエスト設定でも決まります。変更前に、そのキーを誰が持ち、どの仕事がレビューを維持するために使っているかを確認します。

影響はキーを共有する範囲に及ぶ

キーは特定のエージェントや単一のスペースではなく、アカウントに属します。同じ値をローカル環境、CI、定期実行、別のエージェントが使っていれば、キーを配り直さなくても、それぞれの次のリクエストの権限上限が変わります。

目の前の一件だけを速くしたい場合でも、共有している他の処理を確認する必要があります。実効権限はキーのレベルとスペース内のロールの共通範囲です。Writeへの変更でロールによる制限を回避することはできません。

一度の変更が既存の呼び出し元へ

実行できることと、依頼されたこと

Readは閲覧、Change Requestは閲覧と変更提案、Writeはレビュー・マージ・内容編集、Manageはさらに管理とノードの永久削除を含みます。修正案を提出するだけの仕事なら、通常はChange Requestで足ります。

これはシステム上の能力の区分です。今回どのレコードを変更してよいかは、依頼の範囲で別に判断します。Writeだからアクセス可能なすべてのBaseを変更してよいわけではなく、「自動承認して」と文章に書いても提案専用キーにマージ権限は生まれません。

ChangeRequestが残っても、承認待ちとは限らない

Change Requestsの仕様では、すべての編集がChangeRequestになります。Write権限がある書き込みは通常、作成時にマージされます。提案専用キー、明示的なautoMerge: false、匿名フォームからの書き込みではレビュー待ちになります。

既存処理が提案専用キーだけを頼りに即時マージを防いでいたなら、Writeへの変更で待機がなくなる可能性があります。一方、リクエストがautoMerge: falseを明示していれば、その設定は残ります。以前Inboxに表示されたという事実だけでは、次回の挙動は判断できません。

次の書き込みは待機する?

変更前に、秘密を含まない一覧を作る

Account → API Keysで名前、プレフィックス、レベル、有効期限を確認します。完全なキーを報告書やチャットに貼り付ける必要はありません。管理下の設定を調べ、呼び出し元、対象スペースとBase、操作、承認待ちの明示設定を一覧にします。

この一覧はチームが管理するものです。製品がすべての保持者を自動発見するという意味ではありません。共有範囲が不明なら、共有キーを昇格させるより、Writeが必要な処理に独立したキーを発行する方法を検討します。発行や移行は適切な権限を持つ担当者が行います。

変更後は、実際の結果を確かめる

昇格時には二度目の確認が求められます。変更後は認証情報の読み取りで対象スペースを確かめ、すでに許可された影響の小さい実務処理を一件追跡します。CRの状態、該当する場合はマージ日時、正式レコードの値を確認します。テストのためだけに無関係な業務データを書き換える必要はありません。

確認済みの呼び出し元と、まだ実行されていない定期処理を分けて記録します。approvedとmergedは異なる状態です。リクエスト成功だけで完了とせず、正式データを読み戻します。意図しない即時マージ経路があれば、設定を直してから再開します。

今後の権限と過去の値は別

権限を戻しても過去のマージは戻らない

レベルを下げると既存保持者の今後の能力も変わりますが、すでにマージされた業務値が自動で取り消されるわけではありません。必要なら対象レコードと履歴を確認し、監査の経緯を残す修正を提案します。

担当エージェントの交換はアクセスと待審提案の引き継ぎ、書き込み先の問題は複数スペースの対象確認を参照してください。同一キーのレベル変更では、既存の各処理が次回何をマージできるかを確認することが重要です。

よくある質問

古いエージェントに新しいキーを渡す必要は?

同一キーのレベル編集なら値と期限は変わらず、新レベルが即座に適用されます。処理ごとにキーを分ける場合は別の設定変更です。

Writeでも人のレビューを残せる?

リクエストにautoMerge: falseを明示できます。提案だけの処理なら提案専用キーも適しています。どちらも実際のCR状態で確認してください。

スペースのロールを超えて操作できる?

できません。キーのレベルとアカウントのロールの共通範囲が有効です。正しいスペースへの指定も必要です。