HopBaseAPI キーが漏えいしたら、まずコンソールでそのキーを無効化してください。無効化したキーへのリクエストは即座に拒否され、ほかのキーには影響しません。次に同じ設定の新しいキーを作って差し替え、使用量を旧キーで絞り込んで CSV を書き出し、漏えい期間中にどのモデルが呼ばれ、いくら使われたかを確認します。退職者対応も同じ考え方です。メンバーを停止すれば、そのメンバー配下のキーはすべて即座に使えなくなります。そのうえで本人が作成した部門キーを処理します。本記事では、最初の 10 分でやること、事前に有効にすべき設定、退職時の回収チェックリスト、監査ログと使用量 CSV による確認方法をまとめます。
キー漏えい発覚から最初の 10 分
公開リポジトリ、チャット、スクリーンショット、ログなどでキーが見つかったら、原因究明より先に被害を止めます。
- 0〜2 分:無効化:コンソールの「API キー」で該当キーを無効化します。即時に反映され、影響はそのキーだけです。不要と確定したら失効(削除)させます。削除したキーも削除者・削除日時・過去の使用量が残り、後から確認できます。
- 2〜5 分:ローテーション:新しいキーを作成し、元のキーと同じグループ・クォータ・有効期限・IP リスト・同時実行数を設定して、サービスや設定ファイルを差し替えます。
- 5〜8 分:使用量の確認:「使用量」ページで漏えいしたキーを絞り込み、漏えい期間のリクエスト時刻・モデル・トークン数・ステータスを見て、不正利用がいつ始まったかを特定します。
- 8〜10 分:証跡の保存:同じ条件で CSV を書き出し(1 ファイル最大 5 万行・400 日分)、経理やセキュリティ担当に渡します。各行は「公式コスト × 割引 ÷ 為替レート = 実際の請求額」で検算でき、失敗したリクエストは課金されません。
この 4 ステップのあとで漏えい元を調べ、同じ人が作成したほかのキーもローテーションが必要か確認します。各キーには作成者が表示され、使用量ページでも「キー作成者」で絞り込めます。
ローテーションの推奨手順
緊急でない定期ローテーションは「新しいキーが先、古いキーが後」で、サービスを止めずに行います。
- 旧キーと同じ設定で新しいキーを作成;
- 新しいキーをサービスに反映;
- 使用量ページで旧キーを絞り込み、新しいリクエストが来ていないことを確認;
- 旧キーを無効化し、失効させる。
キーに有効期限を設定しておけば、定期ローテーションは「期限までに必ずやる作業」になります。有効期限を空欄にすると無期限です。
予防設定:漏えいしたキーでできることを最小にする
漏えいを完全には防げなくても、1 本のキーで起こりうる最大の損失は事前に固定できます。キーごとに次の項目を設定できます。
| 設定 | 効果 | 推奨 |
|---|---|---|
| キーのクォータ | そのキーで使える上限額(米ドル)。使い切るとリクエストは処理前に拒否(HTTP 402 insufficient_quota) | そのサービスの通常 1 か月分に少し余裕を足した額 |
| 有効期限 | 期限が来ると自動的に使えなくなる | 一時的な作業、外部委託、CI テストでは必ず設定 |
| IP リスト | キーを使える IP を制限 | 本番サービスは送信元 IP を 1 行に 1 つ登録 |
| グループ(1〜10 個) | 含まれるグループのモデルだけを呼び出せる。GET /v1/models で確認可能 | 業務に必要なグループだけを入れ、漏えいしたキーでほかのモデルを使えないようにする |
| 同時実行数 | 同時に処理できるリクエスト数を制限 | バッチ用キーは低めにし、大量呼び出しに使われないようにする |
組織レベルでも 3 つの備えがあります。
- 1 サービス 1 キー:漏えいしても止まるのは 1 サービスだけ;
- メンバークォータと部門クォータ:キー自体にクォータがなくても、所属メンバーと部門の当期クォータで上限がかかる;
- 残高アラート:「利用可能残高」に複数段階のしきい値を設定し、下回るとメールとサイト内通知で知らせる。異常な消費に早く気づける。
メンバー・部門・3 段階クォータの組み方は社員への LLM API キー配布と管理、評価項目の全体像は企業向け AI API セキュリティチェックリストを参照してください。
退職者の API キー回収チェックリスト
退職日に、次の順で実施します。
- メンバーを停止:「チーム管理 → メンバー」で停止します。停止するとそのメンバー配下のキーはすべて即座に使えなくなります。
- 本人が作成した部門キーを洗い出す:メンバーに紐づかず部門に直接紐づくキー(本人が保守していた本番サービスなど)もあります。キー一覧の作成者を見るか、使用量ページで「キー作成者」で絞り込み、1 本ずつローテーションします。
- 最終期の使用量を書き出す:メンバーで絞り込んで CSV を書き出し、当期の精算と部門配賦に使います。
- ロールを見直す:部門責任者だった場合は後任を指名し、企業管理者だった場合は企業オーナーが管理者権限を取り消します。
- メンバーを削除(任意):ログインアカウントが停止され、配下のキーもすべて削除されます(元に戻せません)。過去の使用量と記録は残り、「削除済みメンバー」で確認できます。
- 本人が見た共有設定をローテーション:平文を見られる立場にあったサービス用キーは、上記の「新しいキーが先」の手順で入れ替えます。
監査ログと使用量 CSV で完了を確認する
対応しただけでは終わりません。対応したこと、そしてそれが効いていることを示せる必要があります。
- 監査ログ:組織変更、メンバー変更、クォータと権限の変更、キー操作がすべて記録され、日時と対象で検索できます。企業オーナーと企業管理者が閲覧でき、「誰が何時にどのキーを無効化し、どのメンバーを停止したか」を照合できます。
- 使用量 CSV:リクエストごとにモデル・トークン数・レイテンシ・ステータスが記録されます。旧キーや退職者で絞り込み、無効化した時刻以降に成功・課金されたリクエストがないことを確かめます。
- 旧キーのセルフチェック:旧キーで
GET /v1/usageを呼び、使えなくなっていることを確認します(このエンドポイントはis_activeで判定。残高とクォータの照会ドキュメント参照)。
調査で扱うのは課金メタデータです。プロンプトと出力はリクエストの処理にのみ使われ、業務データとして保持されず、学習にも使われません。通信はすべて TLS です。
HopBase に登録して、すべてのキーにクォータと IP リストを設定する
よくある質問
API キーが漏えいしたら、削除するだけで十分ですか?
まず無効化して被害を止め、同じ設定の新しいキーに差し替えます。そのうえで旧キーで使用量を絞り込み、CSV で漏えい期間の利用額を確認します。削除だけでは損失の大きさも、同じ人が作ったほかのキーを替えるべきかも分かりません。
退職した社員の API キーはどう回収しますか?
メンバーを停止すると、配下のキーはすべて即座に使えなくなります。次に「キー作成者」で本人が作成した部門キーを探し、1 本ずつローテーションします。メンバーを削除すると配下のキーも削除されますが、過去の使用量は残ります。
あるキーがいつ、どのモデルを呼んだかを調べるには?
使用量ページでそのキーを絞り込むと、リクエストごとの時刻・モデル・トークン数・レイテンシ・ステータスが分かり、CSV でも書き出せます。キーの作成・変更・無効化などの操作は、監査ログで日時と対象から検索できます。