A2B攻撃とは？アプリの委託先に確認する5つの質問

2026年10月13日、国立研究開発法人情報通信研究機構（NICT）は、国内で相次ぐ情報漏えいの原因の一つとして、「A2B攻撃（App-to-Backend Attack）」を特定したと発表しました。出典はNICTの発表です。攻撃者が、公開されているAndroidアプリを解析し、アプリが通信するサーバの接続先やAPI（アプリとサーバの窓口）の仕様を調べて、そのサーバを狙い撃つ手口です。総務省も同じ日に、事業者や関係団体に対策の徹底を求めました。出典は総務省のお知らせです。

「うちはアプリを出していない」と思う方も、会員・予約・ポイント・LINEまわりの仕組みを業者に作ってもらっているなら、他人事ではありません。NICTは、同じ問題がiOSアプリや、Webサービスの裏のAPIでも起こり得る、と書いています。

結論：アプリや予約の仕組みを業者に任せている会社が、いまできるのは、業者さんに5つ聞くことです。NICTの注意喚起の中心は「アプリが安全か」ではなく、「アプリを通さずにサーバを直接たたかれても、サーバ側で本人確認と権限確認ができているか」です。当社が直近14件の事案の発表を原文で数えると、アプリが不正アクセスの対象として書かれていたのは5件で、APIの権限の不備を示す記述まで書いたのは、10月13日に出たJR九州フードサービスの1件だけでした。ほかの発表の多くからは、裏のサーバで何が起きていたのかは分かりません。

10月13日に何が公表されたか

NICTと総務省が、10月13日に出したことNICT・CYNEXの注意喚起（詳細PDF）と、総務省のお知らせより

CYNEXの注意喚起（詳細のPDFは全7ページ）には、次のことが書かれています。アプリ自体に脆弱性がなくても、サーバのAPIに認証・認可や入力値の検証の不備があれば、漏えいにつながる。認証を必要としないAPIだけでなく、利用者のアカウントでログインしたあとに使えるAPIも、攻撃の対象になる。恒久的な対策は「アプリ側の制御のみに依存せず」、サーバ側で認証・認可や入力値の検証を行うことだ、という内容です。AIで、アプリの解析や脆弱性の探索が効率化されていることにも注意を促しています。

NICTは、どの事案がA2B攻撃だったかを挙げていません。個別のシステムの診断や相談にも対応しないとして、社内の担当者、開発・運用の委託先、セキュリティ専門事業者に相談するよう書いています。技術的な点検や対応は、社内の担当者、委託先、セキュリティ専門事業者が担います。会社の側は、誰がやるのかと、対応の範囲と完了の記録を確かめます。

A2B攻撃は、こういう順番で進む

ポイントは3です。攻撃者はアプリの画面を通りません。アプリを解析して窓口の場所と使い方が分かれば、アプリを開かずに、窓口へ直接リクエストを送れます。そのとき、サーバが「この人は誰か」「この人に、このデータを見せてよいか」を毎回確かめていなければ、アプリの画面で見せていなかった他人の情報も取れてしまう、ということです。アプリの画面で「自分のデータしか出ない」ように見えていても、守れているとは限りません。

10月13日に出た発表文：業者のアプリのAPIで、他のユーザー情報が取れた

NICTの注意喚起と同じ10月13日に、JR九州フードサービスが、お客さま情報の漏えいを発表しました（社の発表文のPDF）。同社が24店舗（「うまや」「たんや」など）に導入している顧客管理アプリ「トイポアプリ」の提供元、株式会社トイポで起きた不正アクセスです。

JR九州フードサービスの発表文（2026年10月13日）に書かれていたこと発表文の記述だけ

この発表文は、「A2B」という言葉にも、NICTの注意喚起にも触れていません。「権限のない第三者が他のユーザー情報を取得できる状態」は、APIの権限確認の不備を示す記述です。識別子を変える手口だったのかは公表されておらず、IDORやA2B攻撃だったとは特定できません。もう一つ、この読者に近い点があります。お店の側は、アプリを自作したのではなく、業者のアプリを導入していました。裏のAPIの作りは、お店からは見えない部分です。

同じ日、楽天モバイルは、「my 楽天モバイル」の支払い証明書を、第三者が閲覧できる可能性があったと、利用者にメールで通知しました（ASCIIの報道）。自社の脆弱性診断で分かり、6月20日までに改修したとされています。同社が確認できる範囲の記録では、発表時点で第三者の閲覧は確認されていないと報じられています。ブックオフは第2報で、会員データ642万件超の外部への送信を確認したと報じられていますが、「具体的なシステム構成や脆弱性、攻撃手法の詳細」は公表を差し控えている、とされています（セキュリティ対策Labの報道。公式ページの本文は読めていません）。この2件は、数えていません。

直近14件の発表文を、原文で数えた

10月6日の記事では、9月11日から10月5日に公表された13件の事案を、各社の発表文の原文で読み比べました。そのうち、アプリが出てくる4社の発表文を、今回あらためて原文で読み直しました。これに、10月13日公表のJR九州フードサービス1件を加えた14件で、「発表文に何が書かれていたか」だけを数えます。続報がある事案は、続報を含めて1件と数えます。書かれていない原因は、数えていません。

黄色い4件の書き方には差があります。セイコーマートは、「アプリのサーバーを経由して会員情報を保有するサーバーに対し第三者が不正にアクセス」と書き、アプリのサーバを経由したことまで示しています。ニッポンレンタカー、日本郵便、焼肉きんぐは、「アプリのシステム」「郵便局アプリ」「公式アプリの会員管理システム」への不正アクセスと書いていて、アプリの裏のサーバ（API）の話なのかは、発表文からは分かりません。焼肉きんぐは、原因を調査中としています。

この数え方から言えることは限られます。5件のうち、A2B攻撃だったと確認できるものはありません。NICTが事案名を挙げていないからです。灰色の9件には、VPN機器やWebシステムなどの脆弱性を公表したものもあり、この分類だけでは、A2B攻撃との関係は分かりません。数えて分かったのは、アプリの裏のサーバで何が起きたのかまで書いた発表が、14件のうち1件だけだったことです。だから、会社の側からは、自社の委託先に「確かめたか」を聞くことになります。

業者さんに聞く5つ

NICTが事業者に求めたのは、侵害の確認、脆弱性の点検、暫定的な緩和策の3つです。これを、アプリや予約・会員の仕組みを業者に任せている会社が、まず確認するための5問にしました。NICTの点検項目（入力値の検証、SSRF、コード実行など）を、すべて網羅するものではありません。10月11日の記事の質問票（機器・二段階認証・バックアップ）と同じく、聞くのは会社の側で、技術的な確認と対応は、社内の担当者、委託先、専門事業者が担います。

聞く5つと、聞く理由NICT・CYNEXの注意喚起（2026年10月13日）に対応

【業者さんへの確認票：アプリ・予約・会員・LINEの裏のサーバ】
（NICT「A2B攻撃」の注意喚起、2026年10月13日をもとにした、委託先にまず確認するための質問票です。NICTの点検項目をすべて網羅するものではなく、答えの正しさを判断するものでもありません。確かめた記録を残すためのものです）

記入日：　　年　　月　　日
回答した会社・担当者：
自社の取りまとめ担当：
この回答の対象のアプリ・サービス（Android／iOS／Web／LINE連携など）：
緊急の連絡先・受付時間・対応してもらえる範囲：

質問ごとに、次の4つも書いてください。
・状態：確認済み／未確認／対象外（未確認と対象外は、その理由）
・確認した日と、根拠の記録（点検の報告書、ログ確認の記録など）
・直っていないこと、直す担当、期限
・答え

質問1　直接たたかれても守れるか
聞くこと：アプリを使わずに、サーバへ直接アクセスされても、サーバ側で「誰か」と「そのデータを見てよいか」を確認していますか。アプリの画面の制限だけに頼っていませんか。
答えの例：「APIごとに、ログインしたお客様本人のデータしか返さない作りです。アプリを通さない直接のアクセスでも同じです。確認の方法は○○です」
あいまいな答えの例：「アプリは審査を通っています」「アプリには鍵をかけています」
あいまいだったら：「サーバ側で確認している」と言える根拠（確認の方法、確認した日）を聞いてください。

質問2　他人の番号で見られないか
聞くこと：会員IDやデータの番号を書き換えるだけで、他のお客様の情報が見られないか、いつ、誰が、どの方法で確かめましたか。結果の記録はありますか。
答えの例：「○月○日に、当社の○○が、テスト用の2つのアカウントで、番号を入れ替えても取れないことを、すべてのAPIで確かめました。記録はこれです」
あいまいな答えの例：「脆弱性診断は受けています」
あいまいだったら：診断を受けた日、対象にAPIが入っていたか、他人の番号を試したかを聞いてください。

質問3　公開している窓口の一覧
聞くこと：アプリが使うAPI、サブドメイン、古い版のAPI、検証用の環境、クラウド上の公開サービスの一覧はありますか。使っていないものは止めましたか。
答えの例：「公開しているものは一覧にしています（○件）。使っていない古い版は、○月に止めました」
あいまいな答えの例：「必要なものしか公開していません」
あいまいだったら：一覧の有無と、最後に見直した日を聞いてください。

質問4　ログの確認と連絡
聞くこと：2026年8月以降のアクセスログ・認証ログに、不審なアクセスがないか確認しましたか（可能なら、それ以前のログも）。確認した範囲と結果を教えてください。NICTの注意喚起に載っている侵害指標（IPアドレスなど）との照合に加えて、認証なしの大量取得、連番IDでのアクセス、他の会員情報の閲覧・変更などの、通常と違う操作も見ましたか。不審なアクセスが見つかったとき、私たちへ連絡する窓口と時間を教えてください。
答えの例：「○月○日に、8月1日からのログを確認しました。NICTの注意喚起のIPアドレスとの一致はなく、大量取得や連番IDでのアクセスも見つかりませんでした。一致しないことだけで安全とは判断していません。見つかったときは、○○が○時間以内に電話します」
あいまいな答えの例：「異常は出ていません」
あいまいだったら：どの期間のログを、いつ、誰が見たかを聞いてください。

質問5　止める判断と連絡
聞くこと：不審なアクセスや情報の取得が見つかったとき、またはすぐに直せない・安全かどうか確認できないとき、APIや機能、サービス全体を一時的に止める判断は誰がしますか。お客様への連絡の文面と手順は、誰が用意しますか。
答えの例：「止める判断は当社の○○が、御社の○○様に連絡のうえ行います。連絡文のひな形は、こちらです」
あいまいな答えの例：「そのときに相談します」
あいまいだったら：判断する人の名前と、連絡の順番を、先に決めてもらってください。

備考（追加の費用がかかるか、いつまでに回答がもらえるか）：

答えが「大丈夫です」だけだったときは、「いつ、誰が、何で確かめましたか」を聞き返してください。確認票の「あいまいだったら」の欄に、聞き返す言葉を書いてあります。業者さんを疑うためではなく、会社の側が、確かめた記録を持っている状態にするためです。

アプリを出していない会社も、予約システム、会員サイト、LINEと連携した仕組みの業者さんには、同じ5つを聞けます。NICTは、同様の問題がiOSアプリやWebサービスのバックエンドAPIでも起こり得る、と書いているからです。

この記事でまだ分からないこと

5件のうち、A2B攻撃だった事案があるのかは分かりません。NICTは事案名を挙げておらず、発表文もA2Bに触れていません。数えたのは、各社の発表文に書かれていたことだけで、書かれていない原因は数えていません。灰色の9件も、アプリ経由でなかったとは言えません。14件は、10月13日までに公表された事案のうち、当社が原文を読んだ分です。10月6日以降に公表された事案の多くは、読めていません。ブックオフと楽天モバイルは、公式の本文を読めていない報道の情報なので、数えていません。確認票は、点検そのものではありません。答えが正しいかどうかを、当社が判断するものでもありません。個別のシステムの診断は、NICTも受け付けておらず、社内の担当者や委託先、セキュリティ専門事業者の仕事です。

よくある質問

うちはアプリを出していません。関係ありますか？

予約システム、会員サイト、LINEと連携した仕組みを業者に作ってもらっているなら、聞く価値があります。NICTは、同じ問題がiOSアプリやWebサービスの裏のAPIでも起こり得る、と書いています。

A2B攻撃だった事案は、どれですか？

公表されていません。NICTは、相次ぐ漏えいの原因の「一つ」として特定したと書くだけで、個別の事案名は挙げていません。

業者さんが「大丈夫です」と答えたら、どうしますか？

「いつ、誰が、何で確かめましたか」と聞き返してください。ログなら期間、診断なら対象と日付、一覧なら最後に見直した日です。答えられないときは、「未確認」と記録して、確かめる日を決めてもらってください。

ログの確認や点検を、自社でやる必要はありますか？

NICTは、個別のシステムの診断を受け付けておらず、社内の担当者、開発・運用の委託先、セキュリティ専門事業者に相談して対応を進めるよう書いています。会社の側では、誰がやるのかを決めて、対応の範囲と完了の記録を確かめるところまでが仕事です。

HaruIroAIはこう考える

この種の注意喚起は、読んだ会社が自分で直す話ではなく、作った業者に聞く話だと考えています。アプリの中身もAPIの作りも、お店からは見えません。見えないから、聞く言葉を決めておく。答えを紙に残しておく。それだけで、何か起きたときの動きが変わります。