A2B攻撃とは｜NICTの注意喚起と対策3つ【2026年10月】

A2B攻撃（App-to-Backend Attack）とは、一般に公開されているAndroidアプリを解析してサーバの接続先やAPIの仕組みを調べ、そのサーバに合わせて脆弱性を突く攻撃で、NICT（情報通信研究機構）が2026年10月13日の注意喚起で名付けました（2026年10月16日時点の情報）。NICTは国内で相次ぐ情報漏えいの原因の一つとしてこの手口を確認したと発表し、主に狙われる脆弱性を4種類（SSRF・RCE・SQLインジェクション・IDOR/BOLA）、事業者に推奨する対策を3つ（侵害の確認・脆弱性の点検・暫定的な緩和策）示しています。

最終更新：2026年10月16日。NICTの報道発表と注意喚起の本文（PDF・Rev 1.1）、総務省・JPCERT/CC・内閣官房国家サイバー統括室・IPA・個人情報保護委員会の文書に書かれた範囲で整理しています。被害を受けた組織の名前は、NICTとJPCERT/CCの文書に挙がっていないため扱いません。

この攻撃で厄介なのは、アプリそのものに弱点がなくても成り立つことなんです。NICTは「公開アプリが解析されること自体を完全に防ぐことは困難です」と書いており、守る場所はアプリだけでなく、アプリがつながるサーバ側のAPIです。アプリや社内ツールにAIのAPIキーを入れて使い始めた会社にとっては、その鍵をアプリの中に置いたままでよいのかを見直すきっかけにもなります。

この記事では、仕組みと狙われる4種類の脆弱性、NICTの3つの対策のチェック表、AIのAPIキーの置き方、入られた後の初動と報告までを、一次情報に書かれた範囲で整理します。

A2B攻撃とは｜NICTが名付けた手口と10月の注意喚起

A2BはApp-to-Backend Attackの略で、注意喚起の副題にある「Androidアプリを手がかりにしたA2B攻撃」のとおり、アプリ（App）を手がかりに裏側のサーバ（Backend）を攻撃する手法を指します。NICTはバックエンドサーバを「Webサイトやアプリの裏側で、ログイン認証や利用者情報の管理などを行うサーバ」と説明しています（NICTの報道発表）。発表したのはNICTのサイバーセキュリティネクサス（CYNEX）の脅威情報分析チームLETTICE（2024年2月発足）で、注意喚起は独自に実施した調査・分析に基づくものだと注意喚起のPDFに書かれています。

10月の注意喚起を、一次情報の日付で並べると次のとおりです。

なお、NICTが挙げているのは相次ぐ情報漏えい事案の「原因の一つ」で、全ての事案がこの手口によるとは書いていません。JPCERT/CCも「すべての事案で同一の攻撃手法が使用されていることを示すものではありません」と注記しています。

A2B攻撃の仕組み｜公開アプリの解析からサーバに合わせた攻撃へ

NICTのPDFによると、攻撃者はまずGoogle Playの日本地域で公開されているAndroidアプリを入手し、プログラムを解析して、アプリが通信するバックエンドサーバの接続先、APIの構成、通信に使うパラメータなどを集めます。そのうえで、個々のサーバの構成やAPIの仕様に応じた攻撃を組み立て、脆弱性を狙います（NICTの注意喚起PDF「1. 概要」）。

PDFの説明を4つの段に分けると次のとおりです。

1. 公開アプリを入手する：一般に公開されているAndroidアプリを手に入れる
2. 解析して通信先とAPIの構造を調べる：APIの接続先、エンドポイント（APIの個別機能を呼び出すためのアクセス先）、パラメータ、応答データの構造など
3. 攻撃できそうな箇所を特定する：集めた情報から、バックエンドサーバの攻撃対象となりうる箇所を探す
4. サーバに合わせて攻撃する：個々のAPIの仕様や処理内容に合わせたリクエストを送り、脆弱性を探して悪用する

特徴は「不特定多数のサーバに同一の攻撃を試みるのでなく」、解析で得た情報を使って「対象となるバックエンドサーバごとに攻撃内容を変化させている点」です（PDF「2. A2B攻撃の概要」）。ログインが必要なAPIも安全とは限らず、PDFは「利用者アカウントによる認証後に利用できるAPIも攻撃対象となる場合があります」と書いています。JPCERT/CCも「本来画面操作では実行できない内部APIに対する攻撃」を挙げています（JPCERT/CC AT-2026-0030）。

AIについてNICTは「近年、AIの活用によってプログラムの解析や脆弱性の探索が効率化されており、こうした技術がサイバー攻撃に悪用されることが懸念されています」と書き、こうした攻撃がより多くのシステムに及ぶ可能性に注意を促しています。PDFが書いているのはこの懸念と注意で、今回確認された攻撃にAIが使われたかどうかは書かれていません。AIモデルの攻撃能力については、GLM-5.3の攻撃能力をAnthropicが検証した件で整理しています。

狙われる4種の脆弱性｜SSRF・RCE・SQLインジェクション・IDOR/BOLA

PDFは、今回確認されたA2B攻撃で「主に以下の4種類の脆弱性が探索・悪用の対象となっています」として、次の4つを挙げています（PDF「3. 攻撃対象となっている主な脆弱性」）。

4つとも、外から届いた依頼をサーバが確かめずに処理してしまうことで起きる、と言い換えられます。総務省も「アプリ等の利用者側からの通信は信頼できるものとは限らないことを前提に」、サーバ側で認証・認可や入力値の検証をするよう求めています。

自社で今日確かめること｜NICTの対策3つをチェック表に

NICTは、Androidアプリを公開している事業者に3つの対策を「早急に実施することを推奨します」と書いています（PDF「4. Androidアプリを公開する事業者に推奨する対策」）。PDFの記載を確かめやすい表にしました。外注して作ったアプリは、外注先と一緒に確かめます。

①侵害の確認｜公開しているAPIとサーバの洗い出しとログ

NICTの注意喚起のPDFが「今回確認された攻撃に関連するIoC」（侵害指標）の一部として載せているIPアドレスは、69.10.51[.]162、210.149.87[.]120、207.241.172[.]54の3件です（表記はPDFのままで、点が[.]になっている形）。PDFは「IoCとの一致だけで侵害の有無を断定することはできないため、アクセスログや通信内容などと併せて総合的に判断してください」と注意しています。この3件はJPCERT/CCの注意喚起のケースB（API経由での不正な操作）の不審な送信元の一覧にも載っており、JPCERT/CCは「調査時点では正規利用されている可能性もあります」と注記しています。一致の有無だけで判断せず、上の表の「通常と異なるAPI操作」と合わせて見ます。

②脆弱性の点検｜PDFが挙げる6つの観点

PDFは次の6つを「優先的に点検」するよう挙げています。上の2つ、認可不備（IDOR/BOLA）と認証・鍵の露出は、後で紹介する外注先への質問にも入れています。

③暫定的な緩和策｜業務への影響を見ながら

NICTのライブラリーのページは、緩和策を「不要なAPIの停止、アクセス制限、監視の強化、認証情報の無効化・再発行など」とまとめています。PDFが挙げる内容は次のとおりで、業務への影響を考えながら必要に応じて実施するよう書かれています。

• 国外からのアクセスや不要なアクセス元からの通信を一時的に制限する
• 不要な公開API、管理機能、検証環境へのアクセスを停止または制限する
• APIへのアクセス頻度や連続的な識別子の指定などを監視し、必要に応じてレート制限やWAF等によるアクセス制御を行う
• 認証情報やトークンの漏洩・悪用が疑われる場合は、該当する認証情報の無効化・再発行などを実施する
• 脆弱性が確認されたら速やかに修正する。直ちに修正できない場合や、重大な脆弱性の有無を確認できず、暫定的な制限でもリスクを許容可能な水準まで下げられない場合は、該当するAPIや機能、必要に応じてサービス全体の一時停止を検討する

アプリが解析される前提で、サーバ側を確かめる

3つの対策の土台にあるのは、PDFのまとめの「公開アプリが解析されること自体を完全に防ぐことは困難です」という一文です。PDFは恒久的な対策として「アプリ側の制御のみに依存せず、バックエンドサーバ側で適切な認証・認可や入力値の検証などを実施することが重要」と書いています。PDFは同様の問題がiOSアプリやWebサービスのバックエンドAPIでも起こりうるとしており、JPCERT/CCは従業員向け管理システムやBIツールなど、不特定多数のアクセスを想定していないシステムの被害も挙げています。

AIを使う会社の分｜アプリに入れたAIのAPIキーを見直す

アプリや社内ツールにAIのAPIキーを入れている会社は、A2B攻撃を「サーバを持つ会社の話」で終わらせないほうがよいと考えます。JPCERT/CCは手口として「一般公開しているスマートフォンアプリを解析しAPIのエンドポイントやキーを特定する」と「他のシステムの侵害で窃取したAPIキーを使用する」を挙げ、NICTのPDFも「固定された認証情報や暗号鍵が露出していないか確認してください」と書いています。

アプリからOpenAI・Anthropic・GoogleなどのAIのサービスを直接呼ぶ作りで、APIキーをアプリの中に書き込んでいる場合、鍵は利用者の端末に届くプログラムの中にあり、解析で見つかりうる場所です。鍵が他人の手に渡れば、その鍵に許した範囲の操作を他人ができます。

表は、NICTと総務省の「アプリ側の制御のみに依存せず」サーバ側で確かめる考え方を、AIの鍵に当てはめた当社の整理です。

鍵の扱いで先に決めておく4つ

1. 鍵はサーバ側に置く：アプリは自社のサーバを呼び、自社のサーバがAIのサービスを呼ぶ形にします。サーバのAPIを誰でも呼べる作りでは同じことが起きるので、利用者の認証と、JPCERT/CCが挙げる「単位時間あたりのリクエスト件数」の制限もかけます。
2. 用途ごとに鍵を分け、権限を絞る：JPCERT/CCは「API利用者やAPIトークンには必要最小限の権限のみを付与する」よう求めています。用途ごとに分けておけば、1本を止めても他は動き続けます。
3. 期限と使う量の上限を決める：JPCERT/CCは「長期間有効なトークンの使用を避ける」よう求めています。使用量の上限や通知を設定できるかと、その方法は各社の公式ドキュメントで確かめてください。
4. 無効化の手順を先に決めておく：JPCERT/CCは「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」よう求めています。誰が、どの管理画面で、どの鍵を止めるかを事故の前に書き出します。

開発者の手元での保管はmacOS KeychainでAPIキーを管理する方法に、コードに紛れ込んだ鍵を見つける仕組みはGitHubのシークレット漏えい検出の解説にまとめています。AI開発で使われるライブラリにマルウェアが混入した件はLiteLLMのサプライチェーン攻撃の記事で扱っています。

どの鍵を先に無効にするか

止める順番は当社の考え方で、根拠の欄は各機関の文書です。鍵を止めると、その鍵を使っている仕組みも止まるので、どのアプリやツールが使っているかを先に一覧にしておきます。

エージェントの外部連携と、AIに入れたデータの範囲

AIエージェントや社内ツールを社内外のサービスにつないでいる場合は、その連携のトークンも同じ扱いにします。IPAは「自組織が利用している外部サービスをすべて洗い出してください」と求め、その後の対策に「API連携等アプリケーション構成要素単位での管理状況の見直し」を挙げています（IPA）。連携を切る時は、設定を外すだけでなく、発行したトークンも無効にします。AIのサービスに送っている情報に会員の氏名や連絡先などが含まれるかも把握しておくと、漏えいが疑われた時に影響の範囲を説明できます。AIのサービス側に何が保存されるか、その鍵で何を読み書きできるかは、各社の公式ドキュメントで確かめてください。

入られた後｜不審なアクセスに気付いた時の初動と報告

国家サイバー統括室は2026年10月9日の文書で「侵入を完全に防ぐことは困難です。不審な挙動の早期発見と迅速な対応が被害発生及び拡大の防止につながります」と書いています（国家サイバー統括室）。点検の結果、不審なアクセスが見つかることはありえるので、その時の動きを先に決めておきます。

一次情報の記載をもとに、入られた後の初動を5つに並べました。順番は当社の整理で、実際には並行して進めます。

1. 不審なアクセスに気付く：IoCとの一致や、通常と異なるAPI操作をログで見つける（NICT）
2. ログの保存：アクセスログ・APIログ・認証ログを残し、誰がどのように調査できるかを把握しておく（IPA）
3. 影響の範囲を調べる：認証の成否、アクセス先のデータ、情報の取得・変更、認証情報の悪用などを速やかに調べる（NICT）。IPAは、異常が見つかったら速やかにセキュリティインシデントと判定し、専門のセキュリティベンダーに詳細調査を依頼することを強く推奨しています
4. 鍵の無効化・再発行：漏洩・悪用が疑われる認証情報やトークンを無効化・再発行し、必要に応じてAPIや機能の停止も検討する（NICT）
5. 報告と相談：報告の対象に当たる漏えいは個人情報保護委員会（権限が委任された分野は委任先の省庁）へ報告する。国家サイバー統括室は攻撃に関する技術的な情報を、国家サイバー統括室や所管省庁、専門機関等へ速やかに共有するよう求めており、JPCERT/CCもインシデント対応の相談を受け付けています

報告の期限について、個人情報保護委員会のページは「発覚したら、まずは速やかに報告してください」「不正な目的で行われたおそれがある場合は、発覚日から、60日以内」と示しています。報告が義務付けられるのは、漏えい等（又はそのおそれ）のうち、要配慮個人情報が含まれる場合、財産的被害が生じるおそれがある場合、不正の目的をもって行われたおそれがある場合、本人の数が1,000人を超える場合（民間事業者等）などで、同じページは「外部からの不正アクセスによりデータが窃取された場合」を不正の目的によるおそれの例に挙げています。

なおNICTは、個別のシステムの診断や技術的な相談には対応していないとし、社内のセキュリティ担当者や開発・運用の委託先、セキュリティ専門事業者などへの相談を案内しています。事故の後の動きを時間で区切った表はAIエージェントによるサイバー攻撃の事例と7つの確認にも載せています。

戻せるか｜鍵の無効化と再発行、ログ、持っているデータ

先に正直に書くと、漏えいした情報そのものは取り戻せません。戻せるのは鍵と仕組みで、後から調べられるかどうかはログ次第です。

国家サイバー統括室は「万が一情報漏えいが発生した場合でも、保有する情報が少なければ被害の拡大を抑えることが可能です」と書き、「バックアップデータについても適切に保護する」ことも挙げています。ログについてIPAは、直近1か月、その後3か月というように段階的に範囲を広げて確認すること、サービスごとに違うログの保有期間を整理しておくことを求めています。NICTが求める「2026年8月以降」のログが、保存期間の設定で消えていないかを今日のうちに確かめておきます。

教育で防げる範囲と防げない範囲｜A2B攻撃の守りは設計と実装

正直に書くと、社員教育でA2B攻撃そのものは止められません。公開アプリの解析は完全には防げず（NICT）、狙われるのはサーバ側のAPIの認可や入力値の検証の不備で、それは設計と実装を直すことでしか埋まりません。一方で、教育が効く場所もあります。

外注先については、国家サイバー統括室が「委託先企業と共に管理する」という認識での安全管理を求め、委託契約に「不正アクセスや漏えいが発生した場合の報告義務を規定する」ことなどを挙げています。契約の見直しと並行して、まずは今の状態を聞くところから始めます。

【要注意】A2B攻撃のよくある読み違い4つ

読み違い1：アプリに脆弱性がなければ大丈夫

❌ アプリの診断で問題がなかったので、A2B攻撃は関係ない
⭕ NICTは「Androidアプリ自体に脆弱性が存在しなくても、バックエンドサーバのAPIに認証・認可や入力値の検証などの不備があれば」、個人情報の漏洩や不正アクセスにつながる可能性があると書いています。確かめる場所はサーバ側のAPIです。

読み違い2：Androidアプリを出していなければ関係ない

❌ うちはiPhoneのアプリとWebだけなので対象外
⭕ NICTは、同様の問題はiOSアプリやWebサービスのバックエンドAPIでも発生する可能性があるとしており、総務省の注意喚起も同じ点を挙げています。

読み違い3：NICTは「AIが攻撃した」と発表した

❌ AIが自動でアプリを解析して攻撃していることを、NICTが確認した
⭕ NICTが書いているのは、AIの活用で効率化された解析や脆弱性探索の技術がサイバー攻撃に悪用されることへの懸念と、攻撃が広がる可能性への注意です。今回の攻撃にAIが使われたかどうかは、PDFには書かれていません。

読み違い4：IoCの3件と一致しなければ安全

❌ ログに3つのIPアドレスがなかったので、侵害はない
⭕ PDFが載せているのはIoCの「一部」です。一致しないことは安全の証明にならないので、連番IDなどを使ったアクセスといった、通常と異なるAPI操作も合わせて確かめます。

Uravationならこう判断する｜外注先に今日聞く3つの質問

AIの導入を支援する立場から、この注意喚起を受けて最初にやることを3つに絞ります。どれも、新しい製品を選ぶ前にできることです。

判断1：AIの鍵の置き場所の棚卸しを先にやる

アプリ・Webページ・社内ツール・自動化の設定のどこにAIのAPIキーが入っているかを一覧にします。一覧がないと、どの鍵を止めればよいかも、止めた時に何が動かなくなるかも分かりません。JPCERT/CCの「速やかに無効化できるようにする」は、この一覧があって初めてできます。

【AIの鍵の棚卸し】1本ごとに書く
・用途（例：問い合わせへの返信の下書き、社内の要約ツール）
・入っている場所（アプリ／Webページ／自社のサーバ／社内ツール／自動化の設定）
・その鍵を使っている仕組み（止めると何が動かなくなるか）
・権限の範囲と期限
・止める人と止める手順（どの管理画面で行うか）

判断2：アプリを作った外注先に今日聞く3つの質問

1つ目はPDFの「固定された認証情報や暗号鍵が露出していないか」、2つ目は認可不備（IDOR/BOLA）の点検、3つ目は侵害の確認でログを調べる期間に当たります。そのまま送れる文面にしました。答えが「分からない」なら、それ自体が今日の宿題です。

件名：NICTの注意喚起（A2B攻撃）を受けた確認のお願い

いつもお世話になっております。
2026年10月13日にNICT（情報通信研究機構）が出した注意喚起
「相次ぐ情報漏えい、その原因の一つは『アプリ解析からのサーバ攻撃』」を受けて、
開発・運用をお願いしているアプリとサーバについて、次の3点を確認させてください。

1. アプリ（Android・iOS）やWebページの中に、固定の認証情報や鍵（AIのAPIキーを含む）を入れていないか
2. 会員IDなどの識別子を変えた時に、他の利用者の情報を見たり変えたりできないことを、サーバ側で確かめているか
3. 2026年8月以降のアクセスログ・APIログ・認証ログが残っているか。誰が、どこで確認できるか

分からない点があれば、その旨をお知らせください。
注意喚起の本文：https://cynex.nict.go.jp/library/261013-01.html

判断3：直せない時に止める基準を先に決める

NICTは、直ちに修正できない場合や、重大な脆弱性の有無を確認できず暫定的な制限でもリスクを下げきれない場合は、APIや機能、必要に応じてサービス全体の一時停止を検討するよう書いています。止めるかどうかは現場では決めにくいので、どの条件なら止めるかを経営と先に決めておきます。IPAも経営者に、自らのリーダーシップのもとで対策を進めるよう求めています。

よくある質問

A2B攻撃とは何ですか？

公開されているAndroidアプリを解析して、つながるバックエンドサーバの接続先やAPIの仕組みを調べ、そのサーバに合わせて脆弱性を突く攻撃です。NICTの脅威情報分析チームLETTICEが2026年10月13日の注意喚起で「A2B攻撃（App-to-Backend Attack）」と名付け、国内で相次ぐ情報漏えい事案の原因の一つとして挙げました。

iPhoneアプリやWebサービスだけを提供している会社も関係ありますか？

対象になりえます。NICTは、同様の問題はiOSアプリやWebサービスのバックエンドAPIでも発生する可能性があるとしており、総務省も同じ点を示しています。

A2B攻撃で狙われる脆弱性は何ですか？

NICTの注意喚起は、主にSSRF（サーバに意図しない通信をさせる）、RCE（サーバ上で不正なコマンドを実行させる）、SQLインジェクション（データベースに不正な処理をさせる）、IDOR/BOLA（IDを変えると他人の情報が見える）の4種類を挙げています。

IoCのIPアドレスと一致したら侵害されたということですか？

一致だけでは断定できません。NICTのPDFは、アクセスログや通信内容などと併せて総合的に判断するよう求めています。不審なアクセスが確認されたら、認証の成否やアクセス先のデータなど、影響の有無と範囲を速やかに調べます。

アプリにAIのAPIキーを入れています。まず何をすればよいですか？

鍵がどのアプリ・どの版に入っているかを一覧にし、鍵をサーバ側で持つ作りに移す計画を立てます。漏えいが疑われる場合は、その鍵を無効化して再発行します。無効化するとその鍵を入れたアプリからAIを呼べなくなるので、影響を受ける機能も一緒に確かめます。

個人情報が漏れていたら、いつまでに報告しますか？

個人情報保護委員会のページは「発覚したら、まずは速やかに報告してください」としたうえで、不正な目的で行われたおそれがある場合は「発覚日から、60日以内」と示しています。権限が委任されている分野の事業者は、委任先の省庁に報告します。

まとめ

A2B攻撃は、公開アプリの解析で分かったサーバの接続先やAPIの仕組みを使い、サーバに合わせて脆弱性を突く攻撃で、NICTが2026年10月13日に名前を付けて注意を呼びかけました。アプリの解析は完全には防げないので、アプリに鍵（AIのAPIキーを含む）を置かず、誰の依頼かをサーバ側で確かめる。入られた後に備えて、鍵を止める手順とログと報告先を先に決めておく。まずは外注先への3つの質問と、AIの鍵の置き場所の一覧づくりから始めてください。

国内で公表されたサイバー攻撃の事例と自社の点検シートは、資料「AIエージェント時代のサイバー攻撃 事例集と自社点検シート」にまとめています。

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・書籍シリーズ累計66,000部）、『AI推進担当になったら読む本』（大和書房）。
SBクリエイティブ「ビジネス＋IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

今日から始める3つのアクション

1. 今日やること：アプリ・Webページ・社内ツールのどこにAIのAPIキーが入っているかを一覧にし、外注先に3つの質問を送る
2. 今週中：NICTの3つの対策のチェック表を埋め、2026年8月以降のログが残っているかを確かめる
3. 今月中：鍵をサーバ側で持つ作りへの移行と、鍵を止める手順・止める判断の基準・報告先を文書にする

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

参考・出典

• 【注意喚起】相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」〜AIで高度化する脆弱性探索、Androidアプリを手掛かりにしたA2B攻撃に注意〜 — 国立研究開発法人情報通信研究機構（NICT）報道発表、2026年10月13日（参照日：2026-10-16）
• 【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」（CYNEXライブラリー） — NICT サイバーセキュリティネクサス、2026年10月13日（参照日：2026-10-16）
• 同 注意喚起の本文（PDF・全7ページ・Rev 1.1） — 脅威情報分析チームLETTICE、2026年10月13日（参照日：2026-10-16）
• 不正アクセスによる情報漏えい等の事案を踏まえた対応について（公開アプリの解析情報を悪用した攻撃への注意喚起） — 総務省、2026年10月13日（参照日：2026-10-16）
• 直近で相次いでいる国内組織における不正アクセスに関する注意喚起（JPCERT-AT-2026-0030） — JPCERT/CC、2026年10月8日公開・10月9日更新（参照日：2026-10-16）
• 不正アクセスによる漏えい等の事案を踏まえた対応について — 内閣官房国家サイバー統括室、2026年10月9日（参照日：2026-10-16）
• 不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について — 独立行政法人情報処理推進機構（IPA）、2026年10月9日（参照日：2026-10-16）
• 漏えい等の対応とお役立ち資料（漏えい等報告について） — 個人情報保護委員会（参照日：2026-10-16）