アカウント運用 — API キー・利用量・請求・チーム

これは何か

第 2 章では、API キーを 1 つ発行して FIREWORKS_API_KEY に入れるところまでを扱った。個人で試す分にはそれで十分だが、チームで運用し始めると「誰が何をどこまでできるのか」「自動化はどう鍵を持たせるのか」「今月いくら使ったのか」「使いすぎたら誰が止められるのか」という別の問いが出てくる。この章はその問いに答えるための画面群を扱う。

コンソール（app.fireworks.ai）では、アカウント運用の画面は 2 つの URL 系統に分かれている。/account/ 配下にはメンバー管理の Users（/account/users）、支払いの Billing（/account/billing）、利用量の Usage（/account/usage）があり、/settings/ 配下には 第 2 章で使った API Keys（/settings/users/api-keys）、ユーザー個別の利用上限を設定する Usage limits（/settings/usage-limits）、Enterprise 向けの Governances → Model Access（/settings/governances/model-access）がある。同じ操作でも、コンソールのボタン一つで済むものと、firectl や REST API でしか触れないものが混在している。

いつ使うのか

この章の機能は、次のような場面で使う。

• 新しいメンバーが加わった — Users 画面でアカウントに招待し、その人の役割に応じたロールを割り当てる
• CI/CD やバックエンドから自動的に呼び出したい — 人間のログイン情報を共有せず、サービスアカウント専用のキーを発行する
• 月の請求が想定外に跳ねないようにしたい — スペンドティア・月次スペンド上限・ユーザー個別の利用上限を組み合わせて天井を作る
• どのチーム・どのモデルにいくら使ったか説明したい — Usage & Cost Breakdown の API でモデル別・API キー別の内訳を取る（チーム別のカスタムタグ分解は Enterprise 限定）
• （Enterprise）特定モデルの利用を禁止したい、操作の証跡を残したい — モデルアクセスポリシーと監査ログを使う

紛らわしいのは、効き方の似た 3 つの制限機構である。支出の天井を作るもの（アカウントクォータ・Usage limits）と、使えるモデルを絞るもの（Model access policy）が混在している。効く単位も変更できる人も違う。

Serverless の TPM（tokens per minute）そのものやアダプティブ上限の詳細は 第 5 章で扱った。この章では、その上限がどう決まるか（スペンドティア）と、上限を超えたときに何が止まるか（アカウント停止・ユーザー上限）を扱う。

仕組み（1）— ロールと権限の境界線

アカウント内の各ユーザーには 4 種類のロールのいずれかが割り当てられる。既定は User で、これは「他人が所有するリソースまで編集できる」強い権限を持つ点に注意がいる。権限はロールが上がるごとに単純に積み上がっていく構造になっている。

実務で効く境界を権限マトリクスから抜き出すと次のとおりになる。Contributor と Inference User はアカウントで有効化されていない場合があり、使うには Fireworks サポートへの連絡が要る（2026-09 時点）。

全ロールに共通する 2 点も覚えておくとよい。自分の API キーの作成・削除はどのロールでも可能（Inference User でも自分のキーは作れる）で、全ユーザー・全サービスアカウントの一覧を見ることも全ロール共通である。制限されているのは「変更」の側だけだ。ロールは firectl user update <USER_ID> --role=<ROLE> で変更する。<ROLE> に入る文字列は admin / user / contributor / inference-user のハイフン区切りである。

仕組み（2）— サービスアカウントと API キーの配り方

サービスアカウントは、人間のログイン情報に依存せずアプリ・スクリプト・自動化システムを認証させる仕組みで、CI/CD パイプラインやバックエンドサービス向けに用意されている。共有クレデンシャルを避けられるだけでなく、監査ログ上で「自動化システムが行った操作」と「人間が行った操作」を区別できることが目的として明記されている。サービスアカウントは Web UI からログインできず、OIDC トークンも使えない。できることは API キーによる操作だけである。

ここで注意が要るのは、サービスアカウントの既定ロールも userだという点だ。User ロールは他人のリソースまで編集できる強い権限なので、最小権限で運用したいなら作成時に --role=contributor や --role=inference-user を明示する必要がある。

キーの実体には運用上の重要な性質がいくつかある。平文の値（key フィールド）は作成時のみ返され、以後は Fireworks 側にも保存されない。取り逃したら再作成するしかない。名前（displayName）を省略すると "default" になる。expireTime を指定しなければキーは無期限で有効であり、lastUsed は未使用のキーには値が入らないため、使われていない古いキーの棚卸しに使える。監査ログ上でサービスアカウントは <サービスアカウントID>@<アカウントID>.sa.fireworks.ai という合成メールアドレス形式で現れるので、監査ログをメールアドレスで絞り込むときはこの形式を使う。

課金面では、サービスアカウントの使用量はアカウントと同じクォータ・上限を共有し、人間のユーザーとは別枠になっていない。ただし後述する利用量 API では api_key_id / api_key_name の次元でキー単位に分解できるため、「どのサービスアカウントがいくら使ったか」自体は追跡できる。

仕組み（3）— スペンドティアとクォータ

使いすぎを防ぐ仕組みは 3 層に分かれる。①②は firectl quota list で確認し（月次スペンド上限の変更も firectl）、③だけはコンソールの Usage limits 画面から設定する。

① アカウント全体のリクエスト上限。全 API 呼び出しは、1 分あたりに送れるリクエストの本数（RPM: requests per minute）という 1 つの速度の枠を共有する。支払い方法が未登録か、有効なクレジット残高が無いアカウントは 10 RPM（どちらか一方でも欠けていれば 10 RPM のままで、カードを登録しただけで残高が 0 なら上がらない）、支払い方法が登録済みで、かつ有効なクレジットがあるアカウントは 6,000 RPM（最大）になる（いずれも 2026-09 時点）。この 6,000 RPM はアカウント全体に適用される固定の天井で、サーバーレス専用でもアダプティブでもなく、スペンドティアを上げても動かない。TPM がトークンの量の上限であるのに対し、RPM は回数の上限で、1 回のリクエストが大きいか小さいかは問わない。

② スペンドティア。主な役割は Serverless の TPM（tokens per minute）上限の天井を決めることで、5 段階ある。プリペイドクレジットを追加すると数分でティアが上がる（例: 100 USD の追加で Tier 1 → Tier 2）。右列の上限額はレガシーの後払いアカウントにのみ適用され、プリペイドアカウントはティアと独立に月次スペンド上限を設定できる（いずれも 2026-09 時点）。

トレーニング用の GPU クォータは、on-demand デプロイメントのクォータとは別枠で、スペンドティアに応じて自動付与される。Tier 1 では Blackwell（B200/B300）枠が 0 で、現行のマネージド学習の shape は Blackwell 上で動くため、事実上トレーニングには Tier 2 以上が要る（H200 は Tier 1 でも 16、H100/A100 は 8 ある）。on-demand デプロイメントは既定で A100 / H100 / H200 / B200 それぞれ 8 GPU、on-demand LoRA は 100 が既定クォータである。学習ジョブが HTTP 429 quota_exceeded で拒否されたら、ティアを上げて再投入する（いずれも 2026-09 時点）。

③ ユーザー個別の Usage limits（申請制の per-user 利用上限機能。有効化には Fireworks への連絡が要る）。有効化されたアカウントでは、Admin が Settings → Usage limits でアカウント既定の 1 ユーザーあたり上限（公式ドキュメントは新規アカウントの既定を 100 USD と記載。2026-09 時点）と、ユーザー個別の override を設定できる。一般メンバーはアカウント既定値と自分自身の使用量・上限だけを見られる。対象はサーバーレス推論のみ（MiniMax M2.7 を除く）で dedicated（GPU 時間）は対象外、上限到達時のレスポンスは HTTP 402 になる。

月次スペンド上限については、既定で 80% 到達時に警告メールが送られ、Billing 画面から通知しきい値を追加できる。100% に到達すると、サーバーレス推論・デプロイメント・トレーニングの全 API リクエストが自動的に停止する。再開には月次スペンド上限の引き上げが必要で、クレジット残高も尽きていればクレジット追加も要る。この停止挙動は Enterprise アカウントには適用されず、Enterprise の支出アラートは通知のみである。支払い問題によるアカウント停止は、Billing ページで支払い方法の問題を解消してクレジットを追加すると（後払いアカウントなら未払いの請求書を精算すると）1 時間以内に自動で再有効化される。

仕組み（4）— 利用量とコストの読み方

Usage 画面（/account/usage）は時系列の集計メトリクスを見る場所で、モダリティ別のタブ（Voice タブなど）を持つ。ただし Usage 画面が数えるのは「サーバーが受理したリクエスト」だけで、接続前に失敗したリクエストは画面上ゼロに見える。クライアント側でエラーが出ているのにダッシュボードがきれいなら、原因はクライアント側（タイムアウトや DNS 解決の失敗など）を疑う。デプロイメント・モデル・API キー・カスタムタグ（Enterprise 限定）別の詳しい内訳は、コンソールではなく CLI と HTTP API の 2 経路で取る。

ここで区別すべきなのが「利用量（Usage）」と「コスト（Cost）」という 2 つの軸である。Usage はトークン数や GPU 秒などの計量された数量で、ドルは含まない。ドルが必要なら別のエンドポイントを叩く必要があり、レート適用後の値はどれも「請求済みの金額」そのものではなく、固定費・請求書レベルの割引・最低額・クレジット・税を除いた「レート適用済みの見積もり」である。

コストを取得するエンドポイントは 3 本立てで、それぞれ返すものが違う。

• GET /billingUsage — 計量された数量（トークン・GPU 秒）をデプロイメント／モデル／API キー／カスタムタグ別に返す。ドルは含まない。HTTP でフィルタしたい場合は GET ではなく POST /billingUsage:query を使う（この非対称性が落とし穴）。ただし annotations.team / annotations.project / annotations.environment の 3 次元は Enterprise プラン限定で、それ以外のプランで指定すると HTTP 400（FAILED_PRECONDITION）が返る。モデル・API キー・デプロイメント別の内訳は全プランで使え、タグ自体はプランに関係なく記録され続けるため、Enterprise になった時点で過去分も遡って分解できる
• GET /billing/summary — 請求カテゴリ（serverless / dedicated / training）別のドル明細。granularity=DAILY で日次内訳も取れる
• POST /usageCosts:query — 呼び出し側が指定した次元（HOUR / DAY / MODEL / USER / API_KEY のうち最大 2 つ）で分解したドル小計。ACCOUNT スコープは Admin 限定、SELF は自分のコストのみ

CSV でまとめて取りたい場合は 2 つのエクスポートがある。firectl billing export-metrics は全使用タイプの生ダンプ（ドルなし、1 回最大 31 日）、firectl billing export-usage-costs はサーバーレスに限定したレート適用済みのドル CSV で、モデル／モデルティア／ユーザー／API キーのいずれか 1 次元でグループ化する（1 回最大 31 日、かつ --start-time は過去 100 日より前を指定できない）。

Enterprise のガバナンス機能

Enterprise アカウントには、この章で扱った権限管理をさらに引き締める機能がある。モデルアクセスポリシー（Settings → Governances → Model Access）は、モデルごとに serverless 推論・Serverless Fast・dedicated deployments・training の 4 ケイパビリティを許可（allowlist）または拒否（blocklist）できる。ただしポリシーはアカウント全体に一律適用され、チームやユーザー単位では出し分けられない。反映まで数分（アイドルな API キーでは最大 1 時間）かかり、ルール数はおよそ 85 件が上限である（2026-09 時点）。閲覧は誰でもできるが、更新は Admin のみ。同様に、利用量の内訳をチーム・プロジェクト・環境別のカスタムタグで分解する機能も Enterprise 限定である。

監査ログ（コンソールサイドバーの Account settings 配下）は、ストレージへの読み取り・書き込み・削除の全操作を timestamp・principal・response code・resource path・message の 5 列で記録する。カスタム SSO（社内の ID 基盤（Okta や Microsoft Entra ID など）でのログインに一本化する仕組みである SSO・シングルサインオンを、OIDC または SAML 2.0 で Fireworks に持ち込める機能）や、ID 基盤側のユーザーの増減を Fireworks 側へ自動同期する仕組みである SCIM プロビジョニングも Enterprise 限定で、SCIM を使う場合は「グループ同期とグループ→ロールのマッピングが未サポートで、プロビジョニングされたユーザーは全員 User ロールになる」点に注意が要る。

ここまでの 3 つと異なり、ここから先はプランを問わず全アカウントに適用される既定の挙動である。Fireworks は既定でゼロデータリテンション（Zero Data Retention）であり、プロンプトと生成結果はリクエスト処理中の揮発メモリ上にしか存在せず(プロンプトキャッシュが有効な場合は、関連する KV キャッシュを含め数分間保持されることがある)、永続ストレージには記録されない（トークン数などのメタデータはサービス提供に必要な範囲で記録される）。この既定には例外が 2 つある。1 つは第 7 章で扱った Responses API で、store=True が既定のためユーザープロンプト・モデル応答・呼び出したツールを含む会話全体が保存され、30 日後に自動削除される（保存させたくない場合は store=False を渡す）。もう 1 つは FireOptimizer のように、ユーザーが明示的にオプトインした高度機能である。個別の契約条件や監査レポートは、Fireworks の Trust Center や担当者に確認する。

firectl user create --user-id "ci-bot" --service-account --role=contributor

firectl api-key create --service-account="ci-bot" --key-name="CI Pipeline Key" -o json

firectl user list --filter 'service_account=true' -o json

firectl api-key delete <KEY_ID>

firectl user delete ci-bot

firectl billing get-usage \
  --start-time 2026-08-01 --end-time 2026-09-01 \
  --usage-type serverless \
  --group-by model_name

firectl billing get-usage \
  --start-time 2026-08-01 --end-time 2026-09-01 \
  --account-costs-only

つまずきポイント

理解度チェック

まとめ

• ロールは Inference User ⊂ Contributor ⊂ User ⊂ Admin の順に権限が積み上がる。既定の User は他人のリソースも編集できる強い権限を持つ
• サービスアカウントは人間の認証情報に依存しない自動化用の主体で、既定ロールは user。API キー発行は Admin 限定の操作
• 使いすぎを防ぐ仕組みは、アカウント全体の 6,000 RPM 固定上限、スペンドティアが決める TPM 上限、ユーザー個別の Usage limits の 3 層に分かれる
• 「Usage（数量）」と「Cost（ドル）」は別軸で、billingUsage / billing/summary / usageCosts:query の 3 エンドポイントが役割分担している
• モデルアクセスポリシー・監査ログ・カスタム SSO は Enterprise 限定のガバナンス機能で、実運用に組み込む前に社内で確認するとよい

次章では、コンソール画面の外から Fireworks を操る道具箱として、firectl・各言語 SDK・FireRouter・FireConnect といったツールとの連携を扱う。

参考リンク

• Managing users
• Service Accounts
• Account quotas
• Usage & Cost Breakdown
• Per-User Usage Limits
• Exporting Usage Costs
• Exporting Billing Metrics
• Model access policy
• Enterprise features
• Custom SSO
• Audit & Access Logs
• Zero Data Retention
• firectl api-key create
• firectl billing get-usage