自社のスマホアプリについて「裏側のAPIが外から直接狙われる」というニュースを見て、不安になった方は多いのではないでしょうか。アプリの画面は問題なく動いているので、何を心配すればいいのかも分かりにくいところです。
「スマホアプリの裏側のAPIが外から直接狙われると聞きました。うちのアプリは大丈夫なのでしょうか」
先に結論をお伝えします。「大丈夫かどうか」は、発注者が技術を理解しなくても、開発会社に5つの質問をすれば見えてきます。確認するのは、「APIの一覧」「誰が何を見られるかの制限」「回数制限」「鍵（APIキー）の扱い」「ログ（記録）」の5点です。
この記事では、JPCERT/CC の注意喚起をふまえ、スマホアプリのAPIについて発注者が確認したいことを、チェックリストと開発会社への質問例とあわせて解説します。攻撃の手順には触れず、確認と発注の観点に絞ります。
そもそも「アプリの裏側のAPI」とは何か
API（＝アプリとサーバーがデータをやり取りするための窓口）は、スマホアプリの裏側で動いています。たとえば会員情報の表示、予約の登録、注文履歴の取得など、アプリの画面で見える機能の多くは、APIを呼び出して実現されています。
ここで大切なのは、画面を作り込んでも、APIの窓口そのものは外から見つけられる可能性があるという点です。アプリを分析して通信先を調べることは、技術があれば不可能ではないと言われています。そのため「画面から操作できないようにしてあるから安全」とは言い切れません。
JPCERT/CC が注意喚起した内容
JPCERT/CC（＝国内のセキュリティ情報を扱う機関）は、2026年10月に、国内組織で相次ぐ不正アクセスについて注意喚起を出しています。その中には、公開されているアプリを分析して見つけたAPIや内部向けのAPIを不正に操作された例、盗まれたAPIキーを悪用された例が挙げられています。
📰 出典：JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（JPCERT-AT-2026-0030、2026年10月8日公開・9日更新）
同じ注意喚起では、対策としてAPIの回数制限（レート制限）、公開していないAPIを含めたアクセス制御、必要最小限の権限の付与、トークンの有効期限設定と速やかな無効化、不要な管理機能を公開しないこと、既知の脆弱性へのアップデートなどが挙げられています。なお、JPCERT/CC は「情報は限定的かつ断片的で、すべての事案で同じ手法が使われているわけではない」としています。以上は執筆時点（2026年10月）の内容です。
注意喚起の全体像と、API以外のBIツールや管理画面への確認事項は、こちらの記事で整理しています。
JPCERT/CCが「相次ぐ不正アクセス」で注意喚起｜スマホアプリのAPI・BIツール・管理画面を持つ発注者が開発会社に確認すること
「うちのアプリは大丈夫？」を確認する5つのこと
ここからは、発注者が開発会社に確認したい5つの点を順に説明します。いずれも、開発会社が答えられれば安心材料に、すぐ答えられなければ見直しのきっかけになります。
1. APIの一覧：外から呼べる窓口がいくつあるか
まず確認したいのは、そもそもAPIがいくつあり、どれが外から呼べる状態なのかです。アプリの機能が増えるたびにAPIも増えるため、運用が長いほど、担当者が全体を把握できていないことがあります。
- アプリが使っているAPIの一覧（名前・役割）があるか
- 画面からは使っていないが、残ったままのAPI（過去の機能や試験用）がないか
- 管理者向けAPIが、一般の利用者向けと同じ場所に公開されていないか
使われなくなったAPIは、見落とされたまま放置されやすい部分です。一覧がなければ、まず作ってもらうことが最初の一歩になります。
2. アクセス制御：誰が・どのデータまで見られるか
次に、ログインした人が、自分のデータだけを見られる作りになっているかを確認します。会員番号や注文番号の数字を変えるだけで、他人のデータが見えてしまうような作りは、典型的な弱点として知られています。
- 会員Aさんが、会員Bさんの情報を取得できないようになっているか
- 一般ユーザーが、管理者向けの操作を呼べないようになっているか
- 権限は「必要な人に、必要な範囲だけ」（＝最小権限）になっているか
この確認は、画面を触るだけでは分かりません。開発会社に、権限ごとのテスト（自分以外のデータにアクセスできないことの確認）を実施したかを聞くのが近道です。
3. 回数制限：短時間に大量の呼び出しをされたらどうなるか
APIに対して、短い時間に大量のリクエスト（＝呼び出し）を送られても、止められる仕組みがあるかを確認します。これが回数制限（レート制限）です。
- 同じ相手からの呼び出しが一定回数を超えたら、制限される設定か
- ログイン試行の連続失敗などで、一時的にロックされるか
- 制限がかかったとき、運営側に通知が来るか
回数制限は、不正な情報収集や総当たりの試行を難しくする効果が期待できます。ただし「入れれば絶対安全」というものではなく、他の対策との組み合わせが前提です。
4. APIキーと認証トークン：鍵の置き場所と有効期限
APIキー（＝サーバーに「自分は許可された相手」と示すための合言葉）は、アプリの中に直接埋め込まないのが基本です。アプリの中に入っているものは、分析によって取り出される可能性があるためです。
- アプリのプログラム内に、重要なキーが書き込まれていないか
- ログイン後に発行される認証トークン（＝一時的な入場券）に、有効期限があるか
- 紛失・漏えいが疑われたとき、すぐに無効化して入れ替えられる手順があるか
- キーを誰が管理し、退職や委託先の変更時に見直されるか
特に「キーの入れ替えに何日かかるか」は、いざというときの被害の大きさを左右します。普段から手順を決めておくことが大切です。
5. ログ（記録）：異常があったときに気づける・追えるか
最後に、不審なアクセスに気づける仕組みと、後から調べられる記録があるかを確認します。ログがなければ、被害があったかどうかさえ判断できません。
- APIへのアクセス記録が残っているか（期間はどのくらいか）
- 普段と違う動き（深夜の大量アクセス、見慣れない国からのアクセス等）に気づける通知があるか
- 異常を見つけたとき、誰がどう動くか（連絡先・手順）が決まっているか
被害を受けた場合の連絡の進め方は、次の記事で整理しています。
ランサムウェア被害を取引先やお客様にいつ知らせる？連絡の順番と、連絡前に開発会社へ確認したい4つのこと
開発会社側の事情も知っておく
ここまで読むと「開発会社が対策を怠っていたのでは」と感じるかもしれませんが、そう決めつける必要はありません。多くの場合、次のような事情があります。
- 契約時の仕様に「セキュリティ診断」「回数制限」が含まれておらず、費用に入っていない
- 機能追加を重ねるうちに、APIの全体像を把握する担当者がいなくなった
- 保守契約が「動き続けること」中心で、セキュリティの定期点検が範囲外になっている
つまり、発注側が「ここまで見てほしい」と伝えていないことが原因のケースが少なくありません。誰かを責めるのではなく、「契約の範囲を一緒に見直す」姿勢で話すと、建設的な相談になります。
確認したあとの進め方
- 5つの質問を開発会社に送り、回答を文書で受け取る
- 「できている」「できていない」「分からない」に分け、できていない項目に優先順位をつける
- 対応を保守の範囲で行うのか、別途の作業として見積もるのかを確認する
- 必要なら、第三者によるセキュリティ診断（脆弱性診断）の実施を検討する
- 半年〜1年ごとに、同じ項目を定期的に見直す
やりがちな失敗
- 「アプリの画面から見えないから大丈夫」と考える：APIは画面とは別の窓口です
- ニュースを見ても、誰に聞けばいいか決まっていない：窓口担当者と開発会社の連絡先を、平時に決めておきましょう
- 開発会社に「安全ですか？」とだけ聞く：答えが「はい」で終わってしまいます。上の5つのように、具体的に聞きましょう
- 診断を1回やって終わりにする：機能追加のたびに状況は変わります
発注者がやることチェックリスト
- ☐ アプリが使っているAPIの一覧を、開発会社に出してもらった
- ☐ 使っていないAPIや管理者向けAPIが、外から呼べる状態でないか確認した
- ☐ 他の利用者のデータを見られないことのテスト結果を確認した
- ☐ 回数制限がかかっているか、かかった時に通知が来るか確認した
- ☐ APIキーがアプリの中に直接入っていないか、入れ替えにかかる日数を確認した
- ☐ アクセス記録の保存期間と、異常時の連絡手順を確認した
- ☐ 脆弱性診断の実施時期と、次回の予定を確認した
- ☐ 対応が必要な項目の費用と、保守契約で見てもらえる範囲を確認した
開発会社への質問例
- 「このアプリで使っているAPIの一覧と、外部から呼び出せるものを教えてください」
- 「ログインしている人が、他の人のデータを取得できないことは、どのようなテストで確認していますか？」
- 「APIに回数制限は入っていますか？制限を超えたとき、こちらに通知は来ますか？」
- 「APIキーや認証トークンの有効期限と、漏えいが疑われたときの入れ替え手順を教えてください」
- 「アクセス記録はどのくらいの期間残していますか？不審な動きがあったとき、誰がどう連絡しますか？」
回答が具体的かどうかが、運用の成熟度を知る手がかりになります。
まとめ：「大丈夫ですか？」ではなく、5つの点を具体的に聞く
スマホアプリのAPIは、画面の裏側にあって見えにくいからこそ、発注者から確認の声をかけることが大切です。
- APIの一覧：外から呼べる窓口を把握する
- アクセス制御：自分のデータだけが見られる作りか
- 回数制限：大量の呼び出しを止められるか
- APIキーとトークン：埋め込まない・期限がある・入れ替えられる
- ログ：気づける・追える・連絡できる
もちろん、これらを実施しても「絶対に安全」と言い切ることはできません。それでも、確認と見直しを重ねることで、被害の可能性と大きさを小さくしていけます。法的な責任や個別の対応は、専門家や公式窓口にご相談ください。まずは、開発会社に5つの質問を送るところから始めてみてください。
あわせて読みたい関連記事
