APIキーの再発行と入れ替え｜公開後に止めずに変更するための確認

1. 最初に決めるのは、継続運転より封じ込めを優先するか

担当変更に伴う予防的な交換と、公開リポジトリや共有ログへのキー露出では、同じ手順をそのまま使いません。OWASPは、露出したシークレットの迅速な失効と封じ込めを重視しています。漏洩が確認された場合は、切替確認が終わるまで旧キーを使い続ける方針ではなく、失効による機能停止も含めて判断します。本稿では、疑いの段階でも露出先、利用可能な権限、個人情報への接続範囲を整理し、継続の可否を決める担当へ速やかに共有することを提案します。[1]

例えば、文章生成だけを行う外部APIの停止と、個人情報を含む検索基盤へのアクセス継続では、業務への影響が異なります。本稿では、対象機能を一時停止できるか、受付だけ継続して処理を保留できるか、手作業で代替できるかを先に決めることを提案します。漏洩の可能性や影響範囲が未確定なら、未確定のまま記録し、無停止を変更完了の条件にしません。通常運転を続ける判断には、判断者、対象範囲、見直す時点を残し、開発担当だけに判断を集中させない運用にします。

• 変更理由を、計画変更・漏洩疑い・露出確認のいずれかで記録する。
• 一時停止する機能と、受付を継続できる機能を分ける。
• 緊急時の判断者と連絡先を、キー本体を含めずに記録する。

2. 発行前に、キーを使う処理と配布経路を洗い出す

OWASPは、シークレットの用途、保管場所、利用者、変更時に影響する依存関係を把握できるよう文書化することを勧めています。本稿では、キーの識別名を起点に、Webサーバー、非同期ワーカー、定期処理、CI/CD、運用スクリプトの参照先を台帳にすることを提案します。環境変数名が同じでも、環境や実行単位によって設定元が異なる想定で調べます。管理画面の値だけでなく、実際にどの設定経路から各処理へ渡されるかを追い、値そのものは台帳に転載しません。[1]

RAGを使うアプリなら、利用者の質問に答える経路だけでなく、文書取込み、埋め込み生成、索引更新、失敗文書の再処理を分けて整理します。例えば検索が成功しても、夜間の索引更新だけが旧設定を参照している構成は、日中の画面確認では見落としかねません。本稿では、各処理について実行契機、設定元、更新担当、次回実行時刻を記録することを提案します。使途不明のキーが見つかった場合は、名前だけで不要と決めず、参照元と利用記録を確認する作業を独立して割り当てます。

• 本番・検証環境、対話処理・バックグラウンド処理の参照先を区別する。
• 通常は動かない再実行処理と保守用スクリプトも対象にする。

3. 新キーには、必要なAPI権限だけを与える

新キーを旧キーと同じ権限で発行する前に、現在の処理に必要な操作を確認します。OWASPはシークレットへのアクセスに最小権限を適用し、必要な主体だけが利用できる管理を推奨しています。本稿では、発行画面で選べる権限だけでなく、接続先のプロジェクトやデータ領域も照合することを提案します。例えば回答生成の実行に、文書削除や管理設定の変更が本当に必要かを分けて検討します。提供元が制限機能を持つかは、そのサービスの現行仕様で確認します。[1]

外部APIを呼び出すキーの変更確認と、Webアプリ利用者の閲覧権限の確認は、別の試験項目として扱います。本稿では、権限の異なる検証用アカウントを使い、閲覧可能な文書だけがRAGの検索対象になるかを確認することを提案します。また、キーを業務や環境ごとに分割する案は、管理対象が増える負担も含めて判断します。単一キーを複数処理で共有している場合は、一括変更の影響範囲を明記し、権限変更を今回の交換と同時に行うか、別の変更として扱うかを決めます。

• 許可するAPI操作と接続先を、業務処理ごとに説明できるようにする。
• キーの権限変更と、利用者のデータ閲覧権限の試験を混同しない。

4. 配布と反映は、実行単位ごとに進める

OWASPはシークレット管理の標準化・集中管理、手作業による誤りを減らす自動化、CI/CDのアクセス制限を挙げています。本稿では、新キーを承認済みの保管先へ登録し、アプリには参照先を渡す構成を基本案とします。環境変数を使う場合も、管理画面で値を変更すれば全処理へ即時反映されるとは決めつけません。起動時に読み込むのか、実行中に取得するのか、反映に再起動や再デプロイが必要かを、実装と利用基盤の仕様から確認して作業順を決めます。[1]

計画変更で新旧キーを一時併用する案は、提供元が複数の有効キーを認め、組織としてその期間を許容できる場合に限って検討します。新規発行で旧キーが直ちに無効になる仕様なら、段階移行を前提にせず、保留や停止を含む手順に変えます。本稿では、Webサーバーを先に更新し、その後にワーカーを更新する場合、各段階で残る旧設定の参照先を記録することを提案します。アプリの旧版へ戻す操作が、設定まで旧キーへ戻す操作になっていないかも、実行前に確認します。

• 併用可否、発行時の旧キーへの影響、設定反映条件を公式仕様で確認する。
• シークレット値を、作業チケットやデプロイ出力へ貼り付けない。

5. 確認表で、新キーの成功と業務結果を分けて確かめる

本稿では、HTTP応答の成功だけで変更完了とせず、期待した業務結果まで追う確認表を提案します。例えば回答生成なら、要求が受理されたことに加え、処理完了と画面への反映を確認します。RAGなら、検索応答と文書更新を別の行にします。以下の表は実施前のひな形であり、合格を示すものではありません。実際の作業では、担当、実施時刻、結果、秘密情報を除いた証跡の参照先を追記し、実行していない経路を正常扱いしないことを完了判定の前提にします。

Webhookと再実行は、外部への呼出し認証と受信時の署名検証を分けて確認します。署名用の秘密情報を同時に替える必要があるかは、利用構成と提供元の仕様で判断します。本稿では、再実行の確認には模擬データと重複検知用の識別子を用い、送信成功だけでなく二重登録や二重通知の有無を確認することを提案します。本番の未処理データを一括再送して試験の代わりにせず、送信側の受付記録、受信側の処理記録、最終的な業務状態を対応付けて確認します。

6. 旧キーを失効させ、利用の残りを追う

計画変更では、新設定への移行状況と必要な動作確認をそろえてから、承認した時点で旧キーを失効させる手順を検討します。露出が確認された場合の優先順位は冒頭の方針に従います。OWASPは、シークレットを失効可能にし、失効後の利用試行を記録できることを求めています。本稿では、管理画面の操作完了と、旧キーによる要求が拒否された確認を別々に記録することを提案します。拒否の確認には、個人情報の取得やデータ変更を伴わない最小限の要求を選びます。[1]

失効後は、旧キーの利用試行や認証エラーがどの実行元から発生しているかを確認します。OWASPは平文のシークレットをログへ残さず、露出したコードやログから除去する際にも影響やログの完全性を考慮するよう示しています。本稿では、キー値ではなく識別名、実行元、時刻、結果で照合することを提案します。なお、保存データの暗号鍵はAPI認証キーと同じ削除手順にしません。暗号鍵には復号・移行に必要な保持を検討すべき場合があり、別の管理判断が必要です。[1][2]

• 失効後の拒否確認と、新キーによる業務継続確認を記録する。
• 古い設定、配布物、ログに残る値の扱いを担当へ割り当てる。

7. 引継ぎでは、値ではなく再現可能な手順を渡す

OWASPは、誰がアクセスできるか、変更方法、依存関係、連絡先を含む文書を更新することを勧めています。本稿では、引継ぎ資料にキー本体を載せず、保管先の参照名、利用処理、発行・失効の操作権限、承認経路、確認記録への参照を残すことを提案します。担当変更が理由なら、後任が個人の記憶や私有端末に頼らず作業できるかを確認します。完了条件は「値を渡した」ではなく、必要な権限で保管先と手順に到達し、次回変更の準備ができることに置きます。[1]

本稿では、保守時の切り戻し手順も引継ぎ対象にすることを提案します。アプリの不具合を戻す場合でも、失効済みの旧キーは復活させず、新キーを参照する設定を維持できるかを確認します。また、次回のローテーションは日付だけを決めるのではなく、外部APIの仕様変更、接続先の追加、RAG更新経路の変更時に台帳を見直す契機を設けます。未確認の定期処理が残る場合は、担当と確認予定を明記し、作業全体を無条件に完了扱いせず、残件として引き継ぎます。

• 後任が、秘密情報を転載せずに保管先と操作手順を参照できる。
• 切り戻し時に使う設定と、未確認事項の担当・期限が残っている。

よくある質問

発行権限を持つ担当者が不在なら、共有アカウントを使ってよいですか？

本稿では、不在時にその場で資格情報を回覧するのではなく、承認済みの代理担当や緊急アクセス経路を使うことを提案します。その経路がなければ、利用継続か機能停止かを責任者へ判断依頼します。事後には、個人に依存した発行権限と代替手順を見直します。

本番と同等の確認環境がない場合は、どう進めますか？

本稿では、模擬データを使い、本番内でも影響を限定できる経路から確認する案を提案します。ただし、安全な要求や処理範囲を切り出せない場合は、停止枠を設ける判断が必要です。未確認の経路を推測で合格にせず、何が確認できず、どの業務へ影響し得るかを承認者へ示します。

一時休職でも、関連するAPIキーをすべて交換すべきですか？

休職という理由だけで一律には決めません。本稿では、その担当者がキー値を閲覧・持ち出しできた範囲と、運用上の管理要件から交換対象を判断することを提案します。アプリが使うキーと担当者の管理操作権限を分け、交換する場合は対象処理への影響も合わせて確認します。

期限付きで旧キーを残す例外は認められますか？

計画変更で併用可能な場合でも、残す理由、対象処理、承認者、終了期限、期限到来時の処置を定める案とします。依存処理の改修が遅れたことだけで、期限を自動延長しない運用が必要です。露出が確認されたキーは、通常の移行例外として残すのではなく、封じ込めを優先して扱います。

参考・関連資料

• [1] Secrets Management - OWASP Cheat Sheet Series ↗
• [2] Key Management - OWASP Cheat Sheet Series ↗

公式資料の確認日：2026-10-21。業務例は説明用で、顧客の実績ではありません。編集：株式会社N2i。執筆にAI支援を使用し、別のAIによる出典・品質確認に合格した記事を公開する方針です。