アプリのAPIキーが漏れたかもしれない…入れ替えに何日かかる？アプリの再公開は必要？発注者が先に知っておく順番と確認点

「APIキーが漏れたかもしれない」と開発会社から連絡が来たとき、発注者がまず知りたいのは「いつ元に戻るのか」「アプリを出し直す必要はあるのか」ではないでしょうか。実はこの2つの答えは、キーがどこに置かれているかでほぼ決まります。

先に結論をお伝えします。キーが「サーバー側」にあれば、入れ替えは数時間〜1日で終わり、アプリの再公開は不要なことが多いです。一方、キーが「アプリの中」に埋め込まれていると、新しいアプリを公開し、利用者に更新してもらうまで、旧キーを止められないため、数日〜数週間かかることがあります（期間は構成と利用者の更新状況によって変わります）。

この記事では、技術に詳しくない発注者の方向けに、キーの置き場所による違い、入れ替えの正しい順番、日数が変わる要因、開発会社への質問例を整理します（本記事は2026年10月時点の情報です。個別の事故対応は、開発会社や専門機関にご相談ください）。

APIキーとは？漏れると何が起きるのか

APIキーは、アプリやシステムが外部のサービス（地図・決済・メール配信・AIなど）や自社のサーバーを呼び出すときに使う「合鍵」のようなものです。合鍵を他人に拾われると、持ち主になりすましてサービスを使われる可能性があります。

JPCERT/CCは2026年10月に、国内組織での不正アクセスの相次ぐ発生について注意喚起を出しました。その中には、公開されたスマートフォンアプリを解析してAPIを特定したり、盗み出したAPIキーを悪用したりして、権限の変更や不正アカウントの作成、情報の書き換えを行う手口が含まれています。

📰 出典：JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030）

同じ注意喚起では対策として、APIの利用者やトークンに必要最小限の権限を与えて有効期限を設定すること、そして不要になったものや漏えいが疑われるものを速やかに無効化できるようにしておくことが挙げられています。「漏れたら止められる状態」にしておくことが、被害を小さくする土台になります。

高額請求が来たときの責任分担については、APIキーが漏れて高額請求が来た。払わないといけない？で扱いました。この記事は「その前段階＝漏れたかもしれないと分かったとき、どう入れ替えるか」に絞ります。

入れ替えにかかる日数は「キーの置き場所」で決まる

APIキーの置き場所は、大きく2つに分かれます。

	サーバー側に置いている	アプリの中に埋め込んでいる
イメージ	アプリはサーバーに依頼し、サーバーが外部サービスを呼ぶ	アプリが直接、外部サービスを呼ぶ
入れ替えの作業	サーバーの設定を更新するだけ	新しいアプリを作り、ストア審査を経て公開する
アプリの再公開	通常は不要	必要
旧キーを止められる時期	切り替え確認後すぐ	利用者の多くが更新した後（それまで止めると旧版アプリが動かなくなる）
目安	数時間〜1日	数日〜数週間（審査と更新状況による）

※ 日数はあくまで目安です。システムの規模、外部サービス側の手続き、関係者の体制によって変わります。

「アプリに埋め込み」が長引く理由

アプリの中に入っているキーは、利用者のスマートフォンにもコピーされています。新しいキーに差し替えるには、①新しいキーを入れたアプリを作る、②Apple・Googleのストア審査を通す、③利用者に更新してもらう、という3段階が必要です。さらに、旧キーを止めた瞬間、更新していない利用者のアプリは動かなくなります。

そのため、旧キーをいつ止めるかは「漏れたリスク」と「使えなくなる利用者の数」を天秤にかける事業判断になります。ここは開発会社に任せきりにせず、発注者が決める部分です。

なお、そもそも「公開アプリに外部サービスの秘密のキーを入れない」設計にしておけば、この長期化は避けられます。キーの置き場所は、設計の段階で発注者が開発会社に確認しておける項目です。

漏れたかもしれないときの入れ替え手順（発注者が知っておく順番）

クラウドの公式ドキュメントでも、キーの入れ替えは「新しいキーを作る → アプリ側を新キーに切り替える → 旧キーを一旦無効にして動作を確認する → 問題なければ削除する」という順番が示されています。たとえばAWSのドキュメントでは、旧キーを使っているものが残っていないか確認する前にいきなり削除せず、まず無効化して様子を見ることが推奨されています。

📰 出典：AWS「Update access keys」（IAM ユーザーガイド）

これを発注者の言葉に置き換えると、次の流れです。

1. 状況を把握する：どのキーが、いつから、どこで使われているかを洗い出す
2. 新しいキーを発行する：旧キーを残したまま、新しいキーを作る
3. システム側を新キーに切り替える：サーバー設定の更新、必要ならアプリの新版を公開
4. 旧キーを無効化する：切り替えが済んだことを確認してから止める（削除はまだしない）
5. 異常がないか見守る：エラーや使えなくなった機能が出ていないか確認する
6. 旧キーを削除し、記録を残す：何が起きて、いつ入れ替えたかを残す

ただし、不正利用が確認されていて被害が拡大している場合は、順番より停止を優先する判断もあります（旧キーを先に止めて一時的に機能を止める、など）。この判断は、止めたときの影響（どの機能が止まるか）を開発会社から聞いたうえで、発注者が決めるのが望ましいです。

日数が変わる4つの要因

• キーの数と使われ方：1つのキーを複数のシステムで使い回していると、洗い出しと切り替えに時間がかかります
• 外部サービス側の手続き：キーの再発行に申請や承認が必要なサービスもあります
• アプリのストア審査と更新状況：審査の期間や、利用者がどのくらい早く更新するかは自社で制御できません
• 体制と連絡のつきやすさ：夜間・休日に対応できる担当者がいるか、保守契約で緊急対応が含まれるか

入れ替えが終わったあとにやること

• 本当に不正利用されたかを確認する：外部サービスの利用履歴や請求の動きに、心当たりのない利用がないか見る
• キーの権限と範囲を絞る：IPアドレスや利用するアプリ、使えるAPIを制限できるサービスなら設定する
• 再発防止を決める：キーの置き場所、定期的な入れ替え、漏れたときの連絡と判断の流れを取り決める
• 個人情報が絡む場合は法令上の対応を確認する：報告や本人通知が必要かは事案ごとに異なるため、専門家や関係機関に相談する

発注者がやることチェックリスト

• ☐ 開発会社から、漏れたかもしれないキーの一覧（用途・置き場所）を出してもらった
• ☐ そのキーが「サーバー側」か「アプリの中」かを確認した
• ☐ 不正利用の形跡があるか、外部サービスの利用履歴を確認してもらった
• ☐ 入れ替えの手順と、旧キーを止める時期の案をもらった
• ☐ 旧キーを止めたときに使えなくなる機能・利用者の範囲を確認した
• ☐ 作業の担当者と、緊急時の連絡先（夜間・休日含む）を決めた
• ☐ 社内の関係者（経営層・問い合わせ窓口）に状況を共有した
• ☐ 入れ替え後の再発防止策（置き場所・権限・定期入れ替え）を決めた

開発会社への質問例

そのまま使える質問です。

• 「漏れた可能性のあるキーはいくつあり、それぞれ何に使っていますか？」
• 「キーはサーバー側とアプリ内のどちらにありますか？アプリの再公開は必要ですか？」
• 「入れ替えが完了するまでの手順と、おおよその日数を教えてください」
• 「旧キーを止めると、どの機能が使えなくなりますか？旧版アプリの利用者はどうなりますか？」
• 「不正に使われた形跡はありますか？確認はどの記録で行いますか？」
• 「今回の対応は保守契約の範囲に入りますか？別途費用や追加の作業時間が必要ですか？」
• 「今後、キーが漏れても短時間で止められるように、設計や運用を見直せますか？」

まとめ：日数は「キーの置き場所」で決まる。平時に確認しておく

• 入れ替えの日数と再公開の要否は、キーがサーバー側かアプリの中かでほぼ決まる
• 手順は「新キー発行 → 切り替え → 旧キー無効化 → 見守る → 削除」。被害拡大中は停止を優先する判断もある
• アプリ埋め込みの場合、旧キーをいつ止めるかは発注者が決める事業判断になる
• 本当に困らないための対策は、漏れる前に「キーの置き場所」と「止める手順」を決めておくこと

まだ何も起きていない今のうちに、「うちのアプリのキーはどこにあって、漏れたら何日で止められるのか」を開発会社に聞いてみてください。

あわせて読みたい関連記事