A2B攻撃とは｜公開アプリから裏側のAPIを狙う手口と、点検を回す順番

情報通信研究機構（NICT）が2026年10月13日に注意喚起を出してから、「A2B攻撃」という言葉を見かける機会が一気に増えました。公開されているアプリを解析し、その先にあるサーバを狙う手口です。攻撃者が見ているのはアプリではなく、アプリが通信している相手のほうです。

結論を先に書きます。A2B攻撃に使われている技術は新しくありません。スマートフォンアプリの脆弱性診断で以前から踏まれてきた手順に、情報漏えいの共通の入口として名前が付いたものです。そのため最初にやるべきは、製品の買い足しではなく、公開しているAPIの棚卸しと認可の点検になります。この点検は、Androidアプリを公開していない事業者にも同じように当てはまります。

この記事で扱う範囲は次のとおりです。

• A2B攻撃の定義と、攻撃者が実際にたどる4つの段階
• NICTが挙げた4つの弱点のうち、最初に見るべき場所
• 総務省が事業者に求めた3つの行動
• 点検の順番を、公開範囲と影響の大きさで決める方法
• アプリを公開していない事業者がなぜ対象に含まれるのか
• 改ざんが「不正アクセス」ではなく運営指標の異常として現れる場面

A2B攻撃は、アプリの脆弱性ではなくサーバ側の不備を突きます

A2B攻撃（App-to-Backend Attack）は、一般に公開されているアプリを入手して解析し、アプリの接続先サーバの仕様を把握したうえで、そのサーバに合わせた攻撃を仕掛ける手口です。NICTのサイバーセキュリティネクサス（CYNEX）で活動する脅威情報分析チーム「LETTICE」が、国内で相次ぐ情報漏えいの原因の一つとしてこの名前を付けました。

攻撃者がたどる段階は4つです。

• 公開されているアプリを入手する
• 逆コンパイルや通信の観察で、接続先とAPIの仕様を把握する
• アプリを経由せず、APIへ直接リクエストを送る
• 認可や入力値の検証に不備があれば、データを取得または改ざんする

3でアプリ側の制御がすべて外れます。画面に表示していない項目も、入力欄で弾いているはずの値も、リクエストを手で組み立てる相手には関係がありません。アプリ自体に脆弱性がなくても被害が成立するのは、この段差によるものです。

NICTが入口として確認したのはGoogle Playの日本地域で公開されているAndroidアプリですが、注意喚起の本文はiOSアプリやWebサービスのバックエンドAPIでも同じ問題が起こり得るとしています。あわせて、AIの活用によって解析と脆弱性の発見が効率化し、攻撃の対象が広がる可能性にも触れています。

狙われる弱点は4つで、最初に見るのは認可です

NICTは重点的に点検する弱点として、認可不備（IDOR/BOLA）、SQLインジェクション、SSRF、RCEの4つを挙げています。性質が違うので、確認する担当も確認の仕方も分かれます。

この4つのうち、最初に見るのは認可です。OWASP API Security Top 10の2023年版でも、Broken Object Level Authorization（BOLA）が1位に置かれています。認証を多要素化しても、ログイン後に「このデータはこの人のものか」を確かめていなければ、正規の利用者として他人の情報に届いてしまいます。認証と認可は別の仕組みであり、片方を強くしても、もう片方の穴はそのまま残ります。

認可不備は、エラーにならない正常なリクエストとして通過します

点検が後回しになりやすい理由がここにあります。SQLインジェクションやRCEの試行は、失敗すればエラーログやWAFの遮断記録に痕跡を残します。一方、認可不備を突いたアクセスは、認証を通った正規のセッションから、仕様どおりのパラメータで届きます。サーバから見れば成功した正常な応答であり、エラー率も遮断件数も動きません。

侵害の確認がエラーログではなくアクセスログの読み方で決まるのは、この性質によります。見るのは、1つのアカウントが連番に近いIDへ短時間で到達している、画面上の遷移では起こり得ない順序でAPIが呼ばれている、営業時間外にだけ一括取得が走っている、といった動きです。NICTは関連するIPアドレスも公開していますが、一致しただけで侵害の有無は断定できません。アクセスの時系列と通信の内容を併せて判断します。

行政が求めたのは、アプリ側の制御に依存しないことです

総務省は2026年10月、不正アクセスによる情報漏えいの事案を踏まえた対応についてとして、アプリを提供する事業者に注意を呼びかけました。求められているのは3つです。アプリ内の制御のみに依存せず、サーバ側で認証・認可・入力値の検証を実装すること。アクセスログを確認すること。そして、不正アクセスの遮断と被害の拡大防止にあたる暫定的な緩和策を講じることです。

背景には、漏えいそのものの件数があります。個人情報保護委員会の令和7年度年次報告によると、個人データの漏えい等事案について処理した報告は17,139件にのぼりました。加えて、情報処理推進機構（IPA）が2026年1月29日に公表した情報セキュリティ10大脅威 2026では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が入りました。解析と探索の速度が上がる前提で点検の周期を決める、という読み方になります。

点検は、公開範囲と影響の大きさで順番を決めます

すべてのエンドポイントを同じ密度で見るのは現実的ではありません。公開範囲（誰でも叩けるか）と影響（漏れたら何が起きるか）の2軸で並べ替えると、着手順が決まります。

4と5は見落としが起きやすい場所です。古いバージョンのアプリをたどると、停止したつもりの旧APIや検証環境の接続先が出てくることがあります。経済産業省が2023年5月29日に公表したASM導入ガイダンスは、情報システム部門が把握していないIT資産や、公開状態のまま残っている資産を外部から発見する手順を整理しています。点検の前段に資産の一覧化を置くのは、一覧にないものが点検されないからこその順序です。

実装側の確認観点は、IPAの安全なウェブサイトの作り方がそのまま使えます。APIサーバをWebアプリケーションと別物として扱わず、同じ観点で見るのが近道です。

アプリを公開していない事業者も、同じ点検の対象です

「自社はAndroidアプリを出していないので関係ない」という判断は、早すぎます。A2B攻撃で起点になっているのはアプリですが、成立の条件はサーバ側の不備であり、アプリはAPI仕様を知るための手段の1つにすぎません。

同じ情報は、別の経路からも手に入ります。ブラウザの開発者ツールで見えるWebフロントの通信、配信しているJavaScriptの中身、パートナー向けに配ったAPI仕様書、外部に公開しているドキュメントやサンプルコード、そして退職者や委託先の手元に残った資料です。APIのエンドポイントが知られること自体は、本来は問題になりません。目指す状態は「APIを隠せていること」ではなく、「APIが知られても安全であること」です。

委託先に開発を任せている場合は、点検の依頼先が分かれます。侵害の確認とログの保存期間は自社の運用担当、認可と入力値の検証の実装は開発委託先、停止の判断と公表の要否は責任者というように、質問の宛先を先に決めておくと、実際に何か起きたときの初動が早くなります。

ライブサービスでは、改ざんは不正アクセスではなく指標の異常として現れます

ゲームやライブ配信、ECのように、サーバ側で数値が動くサービスでは、A2B攻撃の影響がセキュリティ部門ではなく運営部門の画面に先に出ます。スコアやランキングの書き換え、本来の条件を満たさないアイテムの付与、クーポンやポイントの不正取得、課金判定の回避といった形です。いずれも漏えいとしては報告されず、イベントの成績や経済バランスの異常として現れます。

この種の異常は、権限の判定と計算をサーバ側に寄せる設計で大半が防げます。残るのは、クライアントで処理せざるを得ない部分です。そこは防ぎきろうとするより、到達し得ない値、不自然な操作間隔、特定のアカウントだけに偏った分布といった動きを、サーバ側の記録から継続的に拾う運用に切り替えるほうが現実的です。1回の検知で処分を決めず、複数の根拠と人の確認を挟む手順も併せて決めておきます。

必要になるのは、セキュリティのログと運営の行動データを別々に眺めない体制です。どちらか片方だけを見ていると、攻撃は原因不明の数値のブレとして処理され、そのまま埋もれます。行動データ側から異常の原因をたどる進め方は、データ分析AI Agentの記事とAIエージェントのユースケース12選でも扱っています。

自社環境に置くAI Agentでは、権限も監査記録も自社側に残ります

異常の監視をAI Agentに任せる場合、論点が1つ増えます。Agentが業務データとサーバのログに触れる以上、その接続先と権限そのものが点検の対象になります。外部のサービスへログを送る構成を選べば、公開APIを1つ増やしたときと同じ検討が必要になります。

ThinkingAIの企業向けAI Agentプラットフォーム「Agentic Engine」は、オンプレミス型のセルフホストレイヤーとして顧客自身の技術環境内でご利用いただけます。顧客データはすべて自社環境内に保持されます。権限まわりでは、ロールベースアクセス制御（RBAC）、データアクセスレベル設定、機密操作の承認フロー、マルチアカウント分離管理、ユーザー操作履歴監査をGovernance Studioで一元的に扱えます。Agentごとに、参照できるデータと実行できるアクションを分けて設定する考え方です。外部システムとの接続はMCPに準拠し、OAuth 2.0による認証と権限管理、監査を前提にしています。

データ分析Agentは、指標の異常を検知した時点で、分解と原因の切り分けまで進みます。先ほどの到達し得ない値や偏った分布を、運営担当が気づく前に拾うのがこの部分の役割です。AI Agent自身のID管理という論点はSSOとAIの関係で、AIを閉じた環境で動かす構成そのものは生成AIをクローズド環境で使う3つの構築方式とオフラインAIの選び方で整理しています。

点検は一度では終わりません

A2B攻撃への対応で難しいのは、技術そのものより運用の継続です。APIは機能追加のたびに増え、認可のチェックは追加した担当者の判断に委ねられます。点検を一度通しても、次のリリースで同じ状態に戻ることがあります。

ログの保存期間、判断する人、修正を担当する体制。この3つは、インシデントが起きてから決めるには時間が足りません。製品の選定より先に、公開しているAPIの一覧と、それぞれの所有者を書き出しておくほうが結果につながります。NICTは個別システムの診断や技術相談を受け付けていないため、点検の実務は社内の担当者、開発・運用の委託先、セキュリティ専門事業者のいずれかに割り当てることになります。