APIキーの再発行と切替

公開APIの X-API-KEY を再発行して切り替える手順をまとめます。SSGサイトは実行時に公開APIを呼ばないため、正しい順番で進めれば訪問者へのダウンタイムなしで切り替えられます。

1. いつ再発行するか

• キーの漏洩：リポジトリへの誤コミットや、第三者への流出が疑われる場合。
• 委託先の契約終了：制作会社・外部ベンダーとの契約が終わり、アクセスを切り離したい場合。
• 定期ローテーション：セキュリティポリシーに基づく定期的な入れ替え。

APIキー（X-API-KEY）はテナント単位に発行され、サイトコード（X-SITE-CODE）は再発行しても変わりません。1テナントにつき最大3件のキーを発行でき（有効なキーは最低1件必要）、有効ないずれのキーでも認証できます。特定のキーを「再発行」した場合は、そのキーの旧シークレットが即時に無効になります。

2. SSGなら無停止

SSGサイトはビルド時に公開APIを呼び、生成済みのHTMLを配信するため、訪問者のアクセス時（実行時）には公開APIを呼びません。したがってキーの切り替えは次回のビルドにしか影響せず、訪問者へのダウンタイムは発生しません。CIのシークレットを新しいキーへ更新し、再ビルドするだけです。

3. 切替の手順

最大3件まで持てる特性を活かし、新旧キーを一時的に併存させる無停止の手順を推奨します。

• ① 新しいキーを発行する：管理画面（テナント管理者権限のあるアカウント。運営に依頼する場合もあります）で新しいAPIキーを追加発行します。旧キーはこの時点では有効なまま残します。
• ② シークレットを更新する：CI/CDのシークレット（例: GitHub Actions の Secrets）や、SSRサーバーの環境変数を新しいキーへ更新します。
• ③ 再ビルド/再デプロイする：SSGサイトは再ビルドをトリガーします。SSRサイトはローリングデプロイで、旧キーを使うプロセスが残らないようにします。
• ④ 旧キーを無効化・削除する：新キーでの動作を確認できたら、管理画面で旧キーを無効化または削除します。新旧キーが一時併存するため、切替の間もサイトは動き続けます。

4. 切替後の確認

新しいキーでスモークリクエストを送り、200が返ることを確認します。

curl -i \
  -H "X-API-KEY: <新しいAPIキー>" \
  -H "X-SITE-CODE: <サイトコード>" \
  https://api.cms.sharedan.co.jp/api/v1/post-types

続けて旧キーで同じリクエストを送り、401（ShareDanCmsApiError.isUnauthorized）になっていることも確認しておくと安心です。