メインコンテンツへスキップ
すべての長命の資格情報は、スケジュールに従って、そして露出のヒントがあれば即座に置き換えられる べきです。API キーをローテーションする安全な方法は、ライブキーをその場で変更することでは 決してなく — 新しいものを発行し、トラフィックをそれに移し、何もそれに依存しなくなったら古い ものを退役させることです。その順序で行えば、機能するキーが存在しない瞬間が決して生じません。 このページはステップバイステップのプレイブックです。より広いキーライフサイクル （作成 / 無効化 / 削除）についてはキーを管理を、キーが運ぶ すべてのフィールドについてはトークンオブジェクトを参照して ください。
ここでのすべてのコンソールアクションは Keys 画面（/console/token）にあり、リレーキーでは なくあなたのセッション / アクセストークン上で実行されます。キーの作成、編集、無効化、削除 には Developer ロール以上が必要です。sk-orca-… リレーキーを使うのは /v1/* 推論呼び出し だけです。

​
1. なぜローテーションするのか、そしてなぜその場で行わないのか

OrcaRouter のキーは、単なる文字列ではなく不変のアイデンティティです — 独自のモデル許可 リスト、IP 許可リスト、支出上限、失効、そしてポリシーアタッチメントを 運びます。既存のキーのシークレットマテリアルは変更できません；資格情報と制約は作成時に一緒に 発行されます。 なので「ローテーション」は、後継者を発行してそれに移行することを意味します。次のときに 行ってください：
  • 任意の本番資格情報について固定のペースで（四半期ごとが一般的なベースライン）；
  • キーが漏洩した疑いがある瞬間 — ただし漏洩が確認された場合は、まず断ち切ってから ローテーションしてください（漏洩キー対応を参照）；
  • キーの所有者（従業員、ベンダー統合、廃止されたエージェント）が変わるときはいつでも。
平文（sk-orca-…）は作成時に一度表示されます — そのときにコピーしてください。 その後、 コンソールは orca-7Bf****wxyz のようなマスクされた形式だけを表示します。Developer+ は 通常のキーの平文を後で再表示できますが、ゲートウェイスコープのキー （is_firewall_gateway）の平文を再び読むには Admin が必要です — なのでゲートウェイキーの 最初の表示をあなたの唯一の信頼できるコピーとして扱ってください。

​
2. API キーローテーションのシーケンス

肝心なのはきれいなオーバーラップです：古いものが止まる前に新しいキーが機能する。4 ステップ。
1

後継キーを作成

置き換えるものと同じスコープ — 同じ model_limits、allow_ips、credit_limit_usd、 expired_time、そして同じ guardrail_id / firewall_policy_id — で新しいキーを発行します。 平文を即座にコピーします。ローテーションはスコープを厳しくする理想的な瞬間でもあります： エージェントがもう使わないモデルを落とすか、IP 許可リストを狭めます。
2

トラフィックを移行

新しい sk-orca-… をすべての呼び出し元 — 設定、シークレットマネージャー、CI 変数、 エージェントランタイム — にデプロイします。任意のシークレット変更を出荷するのと同じ方法で ロールアウトします。この時点で両方のキーがライブなので、デプロイは障害なしにずらせます。
3

新しいキーが負荷を運んでいることを検証

古いものに触れる前に、後継者が実際にトラフィックを処理していることを確認します。新しいキーの used_quota が上がり、古いキーのものが平坦になるのを見守ります — キーごとの使用量があなたの 切り替えシグナルです。
4

古いキーを退役

古いキーがトラフィックを示さなくなったら、まず無効化し（可逆）、はぐれ者を見守り、 それから完全に削除します。無効化は一時停止；削除は引き返せない地点です。
各キーに environment ラベルを設定してください — 古いキーと 新しいキーで再利用するか、バンプ（prod → prod-2026q2）して — オーバーラップウィンドウ中に 両方がライブの間、後継者と前任者が明確にラベル付けされるようにします。

​
3. REST での具体的なローテーション

以下のすべてはコンソールアクションです — これらの管理ルートはリレーキーではなくあなたの セッション（UserAuth）の下で実行されます。スケジュール要約エージェントのキーを置き換えて いるとしましょう。同じスコープで後継者を作成します： 
# コンソールセッショントークン — sk-orca-… リレーキーではない
curl https://api.orcarouter.ai/api/token \
  -H "Authorization: Bearer <your-session-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "summarizer-2026q2",
    "environment": "prod",
    "model_limits_enabled": true,
    "model_limits": "openai/gpt-4o-mini",
    "credit_limit_usd": 50,
    "expired_time": -1,
    "guardrail_id": 12,
    "firewall_policy_id": 7
  }'
レスポンスは平文を一度返します（"data": "sk-orca-…"）。それをコピーし、要約器にデプロイし、 先へ進む前に新しいキーが処理していることを確認します。 古いキー（id 481）がトラフィックを示さなくなったら、無効化してから削除します： 
# まず一時停止（可逆）— 古いキーのステータスを Disabled (2) に設定
curl -X PUT https://api.orcarouter.ai/api/token \
  -H "Authorization: Bearer <your-session-token>" \
  -H "Content-Type: application/json" \
  -d '{"id": 481, "status": 2}'

# 何もそれに依存しないと確信したら — 完全に取り消し
curl -X DELETE https://api.orcarouter.ai/api/token/481 \
  -H "Authorization: Bearer <your-session-token>"
キーのステータスは Enabled (1)、Disabled (2)、Expired (3)、Exhausted (4) のいずれかです。 無効化はそれを Disabled に設定します；そのキーが行うすべてのリクエストはその後拒否されますが、 その設定、アタッチメント、履歴は無傷のまま残ります。削除は恒久的です — 資格情報は二度と リクエストを認可できず、削除されたキーは回復不能です。
これらすべてを API なしで行えます — Keys 画面には New key、キーごとの Disabled トグル、そして Delete（単一またはバッチ）があります。上の REST 形式は、スケジュールされた ローテーションをスクリプト化するためのものです。

​
4. ポリシーバインドキーとゲートウェイキーのローテーション

キーのガードレールとファイアウォールアタッチメントはキー上に 存在するため、後継者は同じ姿勢を強制するために同じ guardrail_id と firewall_policy_id を 運ばなければなりません。知っておくべき 2 つのこと：
ガードレールとファイアウォールポリシーは、キー間で共有されるワークスペーススコープの 名前付きリソースです。キーのローテーションはポリシー自体に触れません；既存の guardrail_id / firewall_policy_id に新しいキーを指し直すだけです。ポリシーは中断なくトラフィックを統制し 続けます。
is_firewall_gateway が設定されたキーは、 ファイアウォールゲートウェイ のルート（/api/v1/firewall/*）を駆動します。それを発行すること、そしてその平文を再表示する ことには、どちらも Admin が必要です。そのシークレットを気軽に再読できないため、新しい ゲートウェイキーの平文を作成時にキャプチャし、切り替え前にシークレットマネージャーに保存して ください。
単一のキー — ゲートウェイであろうとなかろうと — を多くのエージェントにまたがって再利用し、 制限を編集して「ローテーション」しないでください。エージェントごとに 1 つのキーが、各 ローテーションを分離し、被害範囲を小さく保ちます。 最小権限チェックリストを参照。

​
5. 緊急ローテーション（漏洩の疑い）

キーが露出していると思う場合、順序が反転します：まず出血を止め、それから移行する。
  1. 調査中に何も認可できないよう、疑わしいキーを直ちに無効化します — あるいは漏洩が 確認されたなら削除してしまいます。
  2. §2 のように後継者を発行してロールアウトします。
  3. 切り捨てる前に、漏洩キーが何をしたかをレビューします：そのキー（トークン）でリクエスト ログをフィルタして被害範囲をスコープします。
完全なインシデントランブックは漏洩キー対応にあります。
短い expired_time はローテーション保険です：失効するキーは、 手動ローテーションを忘れても自身を退役させ、どの単一の資格情報も悪用され得る期間を上限設定 します。

​
6. 次のステップ

キーを管理

これらのステップが構築する、作成 / 無効化 / 取り消しのライフサイクル。

キーにポリシーをバインド

同じガードレールとファイアウォールポリシーを後継者に運びます。

失効するキー

失効を設定して、キーが締め切りでそれ自身をローテーションするようにします。

漏洩キー対応

資格情報が露出したときの緊急パス。
ローテーションは規律あるオーバーラップにすぎません：前任者が止まる前に機能する後継者。各キーを 狭くスコープし続ければ、引き継ぎは退屈なまま — それがまさに資格情報ローテーションに望むこと です。