Cursor Teams プランの管理

チームで Cursor を運用すると、製品に対する考え方が変わります。1 人が 1 つのサブスクリプションを管理するのではなく、管理者が座席のプール、共有の使用量予算、そしてすべての開発者に適用されるポリシーのセットを管理するのです。このガイドでは、Cursor Teams プランの日々の管理について説明します。座席の追加と削除、ロールの割り当て、座席の上位ティアへのアップグレード、SSO の設定、使用状況ダッシュボードの確認、そして最も頻繁に発生する請求上の問題への対処を取り上げます。

Teams プランの概要

Teams サブスクリプションは座席単位で課金され、月払いまたは年払いで請求され、エディタ内ではなく Web ダッシュボードから管理されます。各座席には使用量の許容量が含まれ、チームの従量課金支出はプールされて集中的に制御されるため、管理者は予算がどこに使われているかを把握できます。

項目	Teams での仕組み
料金モデル	座席ごとの月額、年払いオプションあり
使用量	各座席に許容量が含まれる。従量課金の支出はチームレベルでプールされる
管理	座席、ロール、請求、使用量のための Web ダッシュボード
ロール	管理者とメンバー。管理者は座席、請求、ポリシーを管理する
プライバシー	チーム全体のプライバシーモードを管理者が強制できる
SSO	チームのメールドメイン向けの SAML ベースのシングルサインオン
サポート	請求とアカウントの問題向けの優先サポートチャネル

共有使用量プールの仕組み

Teams プランでは、理解しておくべき使用量の層が 2 つあります。

1. 座席ごとの許容量。 すべての座席には、請求サイクルとともに更新される基本のモデル使用量の許容量が含まれます。許容量内に収まっている開発者には追加料金は発生しません。
2. 共有の従量課金予算。 メンバーが座席ごとの許容量を超えると、追加の使用量はチームの共有予算に対して従量課金レートで請求されます。管理者は支出上限を設定し、プールが消費されるにつれて通知を受け取ることができます。

この設計により、エージェントを多用する 1 人のユーザーが自分の請求額を無言で膨らませることはありませんが、共有プールを切り崩すことはできます。共有予算は、他のクラウド支出と同様に監視すべきチームのリソースとして扱ってください。

プールを監視し、個々の座席ではない

個々の座席の許容量はサイクルごとに更新されますが、従量課金の支出は共有プールから引き出されます。請求期間の終わり近くで高コストな長時間エージェントワークロードを実行する前に、チームレベルの使用状況ビューを確認してください。

座席の追加と削除

すべての座席操作は管理ダッシュボードのチームまたはメンバーのセクションで行います。管理者ロールを持つアカウントでサインインしている必要があります。

座席の追加

1. cursor.com でサインインし、管理者アカウントでチームダッシュボードを開きます。
2. メンバーまたは座席のセクションに移動し、招待オプションを選択します。
3. 開発者の仕事用メールアドレスを入力し、招待を送信します。
4. 招待が送信された時点（またはプランの構成によっては承諾された時点）で座席が予約され、サイクル途中の料金は日割り計算されます。
5. 開発者が招待を承諾し、そのメールアドレスでサインインして座席を取得します。

座席の削除

1. ダッシュボードでメンバー一覧を開きます。
2. 退職するメンバーを見つけて、そのメンバーシップを削除します。
3. その座席の支払いも停止したい場合は、請求セクションで座席自体を削除します。座席を解放せずにメンバーシップだけを削除することが、退職者の分を払い続けてしまう最も一般的な原因です。
4. アクセスは、選択したオプションに応じて、即時または現在のサイクルの終了時に終了します。

操作	請求内容	アクセス終了
サイクル途中で座席を追加	残り期間の日割り	承諾時に即時
メンバーシップのみ削除	座席の請求は継続	座席の解放状況による
座席を削除	プラン条件に応じて次回更新時に停止、または日割り	選択したオプションによる

ロール：管理者とメンバー

Teams プランには 2 つの組み込みロールがあります。チームを作成した人はデフォルトで管理者になります。

機能	管理者	メンバー
メンバーの招待と削除	可	不可
座席の追加または解放	可	不可
請求の表示と変更	可	不可
SSO の設定	可	不可
チームのプライバシーモードの強制	可	不可
チームの使用状況ダッシュボードの表示	可	通常は自分の使用量に限られる
すべての IDE 機能の使用	可	可

誰を管理者にするかの選び方

管理者ロールは小さく保ってください。通常は予算を管理するエンジニアリングマネージャーと、バックアップが 1 人です。管理者は請求を変更できるため、管理者が増えるたびに、誤って座席を追加したり支払い方法を変更したりする人が増えることになります。ダッシュボードのメンバー一覧からメンバーを昇格させます。変更はその人の次回サインイン時に反映されます。

座席の上位ティアへのアップグレード

標準の座席を超えて、Cursor は上位ティア（たとえば Ultra、および一部の請求コンテキストでは Super と呼ばれる最上位ティア）を提供しており、含まれる使用量を引き上げ、最も高性能なモデルと長時間実行エージェント機能を利用可能にします。Teams プランでは、これらのアップグレードは座席単位で処理され、個々のメンバーではなく管理者が管理します。

座席をアップグレードする方法

1. チームダッシュボードを開き、座席をアップグレードしたいメンバーを見つけます。
2. そのメンバーの座席またはサブスクリプションのオプションを開きます。
3. 上位ティアを選択して確定します。料金は、チェックアウト時に表示される請求オプションに応じて、即時の日割り計算または次回更新時の適用となります。
4. メンバーに IDE からサインアウトして再サインインするよう依頼し、新しい制限がアカウントパネルに表示されるようにします。

アップグレード後の一般的な請求問題

• 日割り計算の混乱。 サイクル途中のアップグレードは、通常の更新に加えて、次回の請求書に一度限りの日割り項目を生じさせます。これは想定内であり、二重請求ではありません。
• 誤った座席へのアップグレード適用。 座席一覧は時間とともに増え、古いエントリを含むことがよくあります。アップグレードを確定する前に、座席のメールアドレスを確認してください。
• 制限がすぐに表示されない。 ティアの変更は次のサイクルで有効になることがあります。メンバーの IDE アカウントパネルには、現在有効な制限が表示されます。
• 支払い失敗。 チームのカードが拒否されると、アップグレードが無言で失敗することがあります。再試行する前に、請求履歴で失敗したトランザクションを確認してください。

アップグレードは次のサイクルまで待ってよい

チームの請求の構成方法によっては、座席のアップグレードが日割り料金を伴って即時に有効になるか、次の請求期間の開始時に有効になる場合があります。新しいティアの制限がすぐに表示されない場合は、アップグレードが失敗したと決めつける前に、請求サイクルの日付を確認してください。

SSO 設定の基本

SAML シングルサインオンは、すべての座席を ID プロバイダーに結びつけるため、会社への入社と退社が自動的に Cursor を利用できる人を制御します。設定は管理ダッシュボードのセキュリティ設定から行います。

1. ダッシュボードでセキュリティまたは認証の設定を開きます。
2. SAML SSO を選択し、Cursor が提供するサービスプロバイダーの詳細（エンティティ ID と ACS URL）をコピーします。
3. ID プロバイダー（Okta、Entra ID、Google Workspace など）で、これらの値を使って新しい SAML アプリケーションを作成します。
4. ID プロバイダーのメタデータ URL または XML を Cursor ダッシュボードに貼り付けます。
5. まずテストグループにアプリケーションを割り当ててサインインを検証し、その後チーム全体に展開します。

<!-- Example SAML attribute mapping most identity providers accept -->
<Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
  <AttributeValue>[email protected]</AttributeValue>
</Attribute>

メール属性はメンバーの座席のメールと一致している必要があります。SSO ユーザーがサインインできない場合、ID プロバイダーのメールと座席のメールの不一致が最初に確認すべき点です。

2 つのアカウントで SSO を試験運用する

チーム全体で強制する前に、管理者 1 人とメンバー 1 人で SSO を有効にします。属性マッピングが間違っていると全員を締め出してしまうため、パスワードでまだアクセスできるアカウントで検証してください。

使用状況ダッシュボードとプライバシーモード

使用状況ダッシュボードの確認

チームダッシュボードの使用状況セクションには、現在のサイクルについて以下が表示されます。

• チームの総使用量（設定した支出上限を伴う共有プールに対するもの）。
• メンバーごとの内訳（リクエストとトークンの消費量を示すため、プールが枯渇する前にヘビーユーザーを特定できます）。
• モデル分布（高コストな長コンテキストモデルが支出を占めているかどうかがわかります）。
• サイクルにまたがるトレンドライン（現在のプランティアがまだチームに合っているかを予測するのに役立ちます）。

チームへのプライバシーモードの強制

プライバシーモードは、リクエストを処理するために必要な範囲を超えてコードが Cursor サーバーに保存されるのを防ぎます。Teams プランでは、管理者が全員に対してプライバシーモードを強制でき、これにより個々のメンバーがオフにできる機能が取り除かれます。

1. 管理ダッシュボードでプライバシー設定を開きます。
2. チーム全体への強制を有効にします。
3. IDE で確認します。メンバーはプライバシーモードが強制として表示され、設定内でグレーアウトされているはずです。

顧客データや規制対象のコードを扱うチームでは、個々の設定を信用するのではなく、チームレベルでプライバシーモードを強制してください。クラウドで実行されるエージェント機能には独自のデータ取り扱い条件があるため、コンプライアンス上の姿勢にとって重要であれば、それらを別途確認してください。

支払い方法と請求書の管理

支払い情報の更新

ダッシュボードの請求セクションを開き、登録カードの変更、請求先メールの更新、請求書に表示される会社名と税務情報の編集を行います。変更は次回の請求書に適用され、すでに発行された請求書は生成時の詳細を保持します。

請求書の突き合わせ

請求書には、座席ごとの料金と、従量課金の超過分が別々の項目として記載されます。数字がチームに対するあなたの認識と一致しない場合は、請求書と現在のメンバー一覧をエクスポートして比較します。

# reconcile.py - compare an exported invoice CSV against the active members CSV
import csv

def load_rows(path):
    with open(path, newline="", encoding="utf-8") as f:
        return list(csv.DictReader(f))

invoice = load_rows("invoice.csv")       # columns: email, line_type, amount
members = load_rows("members.csv")       # columns: email, role, status

billed = {r["email"] for r in invoice if r["line_type"] == "seat"}
active = {m["email"] for m in members if m["status"] == "active"}

print("Billed but not active:", sorted(billed - active))
print("Active but not billed:", sorted(active - billed))
total = sum(float(r["amount"]) for r in invoice if r["line_type"] != "tax")
print(f"Invoice total excluding tax: {total:.2f}")

「請求されているが有効でない」リストにあるものは古い座席です。解放して更新を停止させてください。

よくある問題のトラブルシューティング

座席のアップグレードが適用されない

サポートに連絡する前に、このチェックリストを順に確認してください。

1. アップグレードがメンバーアカウントではなく管理者アカウントから購入されたことを確認します。
2. 請求履歴で、完了した（失敗していない）トランザクションを確認します。
3. プラン条件でアップグレードが次回サイクルで有効になるかどうかを確認します。
4. メンバーに IDE から完全にサインアウトして再サインインしてもらいます。キャッシュされた認証情報は古い制限を表示することがあります。
5. アップグレードが正しいメールアドレスの座席に適用されたことを確認します。

上記がすべて問題なく、それでもティアが標準のまま表示される場合は、チーム名、座席のメール、アップグレードの請求書 ID を添えて [email protected] にメールしてください。

チームの座席を Super にアップグレードできない

一部の Teams 構成では、最上位ティアがセルフサービスの座席単位アップグレードとして公開されていないか、オプションは表示されるもののチェックアウト時に失敗します。実際には次のようにします。

• 座席単位のティア変更は支払い方法に紐づくため、請求の所有者（支払いを設定した管理者）がアップグレードを実行するようにします。
• メンバー一覧ではなく請求セクションから、あるいはその逆からアップグレードを試します。プランのバージョンによってオプションの場所が異なります。
• チェックアウトが繰り返し失敗する場合は、サポートまたは営業に連絡し、座席ティアの変更を手動で適用してもらうよう依頼します。座席のメールと希望するティアを添えてください。
• 回避策として、そのヘビーユーザー 1 人だけ上位ティアの個人サブスクリプションで運用し、残りのチームは Teams プランに保つチームもあります。洗練された方法ではありませんが、請求を整理している間、その開発者のブロックを解除できます。

二重請求

よくある原因と修正方法は次のとおりです。

原因	確認方法	修正
タイムアウト後の支払い再試行	2 つのトランザクションがあり、一方が保留または失敗の印	保留のものは通常自動的に解決します。両方が確定する場合はサポートに連絡してください
1 つのメールに個人とチームのサブスクリプション	請求履歴に 2 つの製品が表示される	個人プランを解約するか、サポートに統合を依頼してください
1 サイクルで座席を 2 回追加	同じメールに対して日割りの座席項目が 2 つ	余分な座席を解放してください。サポートが重複分を返金できます
ブラウザの自動入力ミスでカードが 2 回保管	2 つの支払い方法があり、両方に請求	1 つを削除し、誤った方の返金を依頼してください

常に請求書 ID とトランザクションのタイムスタンプを添えてサポートチケットを起票してください。正当な重複の返金は定例的な対応ですが、特定の請求を明確にする必要があります。

削除したメンバーが座席を消費し続ける

これはほとんどの場合、メンバーシップは削除されたものの座席自体が解放されていないか、SSO のグループ割り当てがユーザーを即座に再プロビジョニングしたことを意味します。修正するには次のようにします。

1. ダッシュボードで、その人が非アクティブまたは保留中のメンバーとして表示されるか確認します。保留中の招待は座席を予約します。
2. 保留中の招待をキャンセルし、請求セクションで座席を解放します。
3. SSO がメンバーシップを自動的に再作成する場合は、ID プロバイダーでそのユーザーを Cursor アプリケーショングループから削除します。
4. 請求書に対して座席の突き合わせを再実行し、座席が更新されなくなったことを確認します。

# Quick audit: list seats from the exported members CSV where last_active is over 30 days old
import csv
from datetime import datetime, timedelta

with open("members.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        last = datetime.strptime(row["last_active"], "%Y-%m-%d")
        if datetime.now() - last > timedelta(days=30):
            print("candidate for seat release:", row["email"])

使用量が毎週リセットされない

Teams プランで最も一般的な誤解はリセットのスケジュールです。一般に次のとおりです。

• 座席の許容量は請求サイクルで更新されます。 これはサインアップ時に別途選択しない限り月次です。メインの許容量に毎週のリセットはありません。
• 共有の従量課金予算は請求期間ごとに追跡され、ダッシュボードで表示されるプールの減少は現在の期間のみを反映します。
• 個々の機能は独自のウィンドウを持つことがあります。 一部のエージェント機能やプレビュー機能には、請求サイクルとは独立したより短いローリング制限があり、これがダッシュボードの 2 つの数字が異なるタイミングでリセットされる理由です。

更新日が明らかに過ぎた後もプールがリセットされないように見える場合は、請求のアンカーを確認してください。リセットはカレンダーの月ではなく元のサブスクリプション日付に従い、サイクル途中の座席変更が予想をずらすことがあります。更新後 1 日以上経ってもダッシュボードが古いままの場合は、チーム名と最新の請求書 ID を添えてサポートに連絡してください。

請求の所有者はちょうど 1 人に

管理者 1 人を請求の単一窓口として指名し、支払い方法を会社のカードにし、サイクルごとに請求書をメンバー一覧と突き合わせてください。このガイドにあるほぼすべての Teams 請求問題は、請求書を実際に監視している人がいる場合、5 分で修正できるものになります。

クイックリファレンス

タスク	場所	備考
座席の追加	ダッシュボード、メンバーセクション	サイクル途中は日割り
座席の解放	ダッシュボード、請求セクション	メンバーシップの削除だけでは請求は止まらない
座席ティアのアップグレード	ダッシュボード、座席または請求オプション	管理者のみ。次サイクル適用の場合あり
プライバシーモードの強制	ダッシュボード、プライバシー設定	チーム全体。メンバーは無効化できない
SSO の設定	ダッシュボード、セキュリティ設定	まず 2 つのアカウントで試験運用
使用量の確認	ダッシュボード、使用状況セクション	プールビューとメンバー別内訳
請求の紛争	[email protected]	請求書 ID とタイムスタンプを添えて

座席割り当てと請求証明書の理解

座席は特定の個人に割り当てられたライセンスであるため、請求はインストール数ではなく、割り当てられた座席数に従います。座席には 4 つの状態があります。メンバーに割り当て済み、保留中の招待によって予約済み、解放済みで請求されない状態、そして請求時に割り当て済みと予約済みを合算した請求対象です。保留中の招待は開発者が承諾する前に座席を予約するため、放置された招待が次回の請求書を静かに膨らませます。

サイクル途中の座席変更と日割り

サイクルの途中で座席を追加または解放すると、そのサイクルの残り日数に応じて日割り計算されます。日割りの追加は残りの端数を請求し、日割りの解放は未使用日数をクレジットします（通常は現金ではなくマイナスの項目として）。次回の更新では、その時点で保有する全数量に戻ります。

請求の基本

請求書は各サイクルの開始時に、その時点で保有する座席について生成され、前サイクルの超過分が独自の項目として追加されます。会社名、税務 ID、請求先メールのサイクル途中の変更は、次回の請求書にのみ適用されます。

請求証明書と請求書の違い

請求証明書（レシートと呼ばれることもあります）は支払いが取り込まれたことを確認し、請求書は何が請求されたかを項目別に示します。財務部門はしばしば両方を必要とするため、確認メールを転送するのではなく、請求セクションからダウンロードしてください。

SSO とドメイン検証の設定

SSO はすべての座席を ID プロバイダーに結びつけるため、会社への入社や退社がアクセスを自動的に制御します。次の 4 つの段階を順に進めてください。

ステップ 1 — ドメインの検証

Cursor が提供する DNS TXT レコードを追加し、検証をクリックする前に伝播するのを待ちます。一般的なレコードは _cursor-verification.example.com という TXT エントリで、値は cursor-domain-verification=8f3c1a90b7e44d2fa1c6 であり、DNS ホストで公開します。

ステップ 2 — ID プロバイダーの構成

Cursor は SAML 2.0 と OIDC に対応しています。Cursor が提供するサービスプロバイダーの値をコピーし、プロバイダーでアプリケーションを作成し、プロバイダーのメタデータを貼り付けます（OIDC では同じ値がクライアント ID、シークレット、リダイレクト URI、および座席のメールと一致する必要があるメールクレームにマップされます）。

{
  "protocol": "SAML",
  "sp_entity_id": "https://cursor.com/saml/metadata",
  "acs_url": "https://cursor.com/saml/acs",
  "attribute_mapping": { "email": "user.email", "groups": "user.groups" },
  "signature": "required"
}

ステップ 3 — 属性のマッピングとメンバーのプロビジョニング

アプリケーションを管理者 1 人とメンバー 1 人のパイロットグループに割り当て、拡大する前にメール属性が座席のメールと正確に一致することを確認します。SCIM プロビジョニングをサポートするプロバイダーはメンバーを自動的に作成・削除するため、Cursor が座席の信頼できる情報源になります。

ステップ 4 — 全員への SSO の強制

1. 少なくとも 2 人の管理者がパスワードだけでなく SSO 経由でサインインでき、アプリケーションが誤動作した場合の復旧パスが存在することを確認します。
2. 強制を有効にし、メンバーに新規サインインをテストしてもらいます。

強制は管理者を締め出す可能性がある

SSO が強制されると、属性マッピングの誤りや ID プロバイダーのアプリケーションの障害が、あなたを含むチーム全体を締め出します。請求ダッシュボードにまだアクセスできる管理者を少なくとも 1 人維持し、まず 2 つのパイロットアカウントでマッピングを検証し、強制する前に ID プロバイダーの管理者アカウントを別途確認してください。

ロールと権限のリファレンス

Cursor Teams には、管理者ロール、メンバーロール、および一部のプランでは財務スタッフ向けの請求専用ロールが付属しています。職務を果たせる中で最も狭いロールを使用し、管理者ロールは予算の所有者とバックアップ 1 人に保ってください。追加の管理者はすべて請求を変更できるからです。請求専用アクセスは座席の追加やメンバーアクセスの変更ができず、これが財務が実際に必要とする最小権限です。

機能	管理者	請求専用	メンバー
メンバーの招待と削除	可	不可	不可
座席の追加または解放	可	不可	不可
座席ティアの変更	可	不可	不可
支払い方法の更新	可	可	不可
SSO とドメイン検証の構成	可	不可	不可
チームのプライバシーモードの強制	可	不可	不可
チームの使用状況ダッシュボードの表示	可	読み取り専用	自分の使用量
エディタとエージェント機能の使用	可	座席なし	可

ロールの変更は対象者の次回サインイン時に適用されるため、変更が失敗したと決めつけるのではなく、サインアウトして再サインインするよう依頼してください。

使用状況の分析とレポート

ダッシュボードの指標

指標	わかること	典型的な対応
チームのトークンとリクエスト	共有プールに対する総消費量	予算と比較する
メンバーごとの内訳	誰が最も速くプールを引き出すか	ヘビーユーザーを指導またはアップグレードする
上限に対する支出	ソフトまたはハードキャップまでの余裕	キャップを調整する

使用量のエクスポートとメンバー別の集計

エクスポートは 1 行ごとのファイルでチーム規模では読みにくいため、awk パイプラインでローカルに集計します（JSON の場合は同等の jq -r '.members[] | [.email, .tokens] | @csv' usage.json を使用します）。

# Export the cycle, then rank members by token consumption
curl -s -H "Authorization: Bearer $CURSOR_ADMIN_TOKEN" \
  "https://api.cursor.com/teams/usage/export?cycle=2026-09" -o usage.csv

awk -F, 'NR>1 {tok[$1]+=$4} END {for (u in tok) printf "%s,%d\n", u, tok[u]}' usage.csv \
  | sort -t, -k2 -nr | head -20

ソフトアラートの設定

ソフトアラートは、誰もブロックすることなく共有プールが枯渇する前に警告します。おおよそ 70 パーセントと 90 パーセントに 1 つずつ設定し（alerts: {soft: [70, 90], hard_cap: 100} のような構成）、チームが読むチャネルに配信し、ハードキャップを両方より上に保つことで、アラートが常にロックアウトに先行するようにします。

チームへのプライバシーモードの強制

プライバシーモードは、リクエストを処理するために必要な範囲を超えてコードが Cursor サーバーに保存されるのを防ぎます。管理者は組織全体で強制でき、これにより各メンバーが無効化する機能が取り除かれます。

1. 管理ダッシュボードでプライバシー設定を開きます。
2. チームのすべてのメンバーへの強制を有効にし、保存して、ダッシュボードが強制として報告することを確認します。

強制はメンバーのエディタのトグルをグレーアウトし、チームポリシーの下でリクエストがトレーニング用に保持されるのを停止し、クラウドエージェント機能は独自のデータ取り扱い条件のままにします。1 つを信用するのではなく 3 か所で検証してください。ダッシュボード、メンバーの設定での強制状態、そして管理ポリシービューです。

プライバシーモードはチームポリシーであり、法的保証ではない

プライバシーモードを強制することは、チームのリクエストがどのように扱われるかを設定するものであり、独自のデータ保持レビューに代わるものではありません。設定がどこで強制され、誰が所有するかを記録し、監査人がその管理を追跡できるようにしてください。

座席監査の自動化

手動の突き合わせを、非アクティブな座席にフラグを立て、削除する内容を出力するスケジュールされた監査に変え、すべての変更を人間が承認するようにします。

# seat-audit.sh -- flag seats with no activity for more than N days
#!/usr/bin/env bash
set -euo pipefail
CSV="${1:-members.csv}"; STALE="${2:-30}"; NOW=$(date +%s)
awk -F, -v s="$STALE" -v n="$NOW" 'NR>1 {
  split($4, d, "-")
  age = int((n - mktime(d[1]" "d[2]" "d[3]" 00 00 00")) / 86400)
  if (age > s && $3 == "active") printf "%s,%s,%d days,REVIEW\n", $1, $2, age
}' "$CSV"

その出力を、明示的なフラグがある場合にのみ動作するドライラン削除ワークフローに渡します。

# remove-seats.sh -- dry run unless --apply is passed
MODE="dry-run"; [[ "${2:-}" == "--apply" ]] && MODE="apply"
while IFS=, read -r email role age action; do
  [[ "$MODE" == "dry-run" ]] \
    && echo "would release: $email (inactive $age)" \
    || curl -s -X DELETE -H "Authorization: Bearer $CURSOR_ADMIN_TOKEN" \
       "https://api.cursor.com/teams/seats?email=$email"
done < <(./seat-audit.sh "$1")

毎週ドライランを実行し、出力を確認してから削除を適用します。保留中の招待によって予約された座席はスキップし、採用中の人を締め出さないようにします。

監査をスケジュールし、削除はしない

監査を自動化し、削除は手動フラグの背後に残してください。監査と削除の両方を行うジョブは、休暇中に誰もアクセス喪失に気づかないまま座席を削除してしまうでしょう。

更新、解約、ダウングレード

更新時には、プランは保有する数量で座席を再設定し、共有許容量を更新し、前サイクルの超過分を請求するため、更新日の 1 週間前にメンバーを請求書と突き合わせてください。ダウングレードはアップグレードを鏡写しにしたものです。退職者の座席を解放し、不要なティアを削除し、請求で座席数を減らし、次回の請求書で新しい数を確認します。通常は次サイクルで有効になります。

変更	メンバーが維持するもの	メンバーが失うもの
メンバーの入れ替え	残りのメンバーは影響なし	削除されたメンバーの座席とアクセス
座席ティアのダウングレード	コアのエディタ機能	より多くの含まれる使用量と最上位モデル
座席数の削減	新しい数までの座席	新しい数を超える座席は解放される
プランの解約	支払い済みサイクルの終了までのアクセス	チームダッシュボード、SSO、共有プール

解約は同じようには元に戻せない

チームプランを解約しても現在のサイクルは返金されません。アクセスはすでに支払った期間の終了まで続き、その後停止します。後でチームを再作成するには、座席、SSO、プライバシーを再設定する必要があるため、解約する前にメンバー一覧と請求書をエクスポートしてください。

よくある質問

座席は人単位で請求されますか、インストール単位ですか？

人単位です。1 つの座席は、マシンの数に関係なく 1 人の指定メンバーをカバーします。1 つのログインを共有すると座席は節約できますが、人単位で監査できないため、避けてください。

同じサイクルで座席を 1 つ追加し、別の 1 つを削除するとどうなりますか？

どちらも残り日数に日割り計算され、多くの場合、相殺されて小さな純変化になります。二重請求されたと決めつける前に、対応する追加項目と解放項目を探してください。

メンバーは自分の座席をアップグレードできますか？

いいえ。座席ティアの変更は、チームの支払い方法に対して管理者がチームダッシュボードから行います。

月の 1 日にプールがリセットされないのはなぜですか？

プールはカレンダーの月ではなく、請求のアンカー、つまり元々サブスクリプションを開始した日付に従います。古いダッシュボードをバグとみなす前に、最新の請求書でサイクル開始日を確認してください。

SSO が全員を締め出したらどうすればよいですか？

強制する前に復旧パスを用意してください。問題が発生した場合は、SSO を完全に無効にするのではなく、ID プロバイダーでマッピングまたはアプリケーションを修正し、サインインを再有効化してください。

財務は座席なしで請求を支払えますか？

はい、請求専用ロールを提供するプランでは可能です。座席やメンバーの管理なしに支払いと請求書へのアクセスを付与し、財務が実際に必要とする最小権限となります。