2026年10月16日時点で、A2B攻撃への対策として開発者がまず直すのは、アプリの中にAIのAPIキーなどの秘密を置かないことと、APIがリクエストごとに「この利用者がこのデータを触ってよいか」をサーバ側で確かめることの2つです。A2B攻撃（App-to-Backend Attack）は、情報通信研究機構（NICT）の脅威情報分析チームLETTICEが2026年10月13日の注意喚起で名付けた手口で、公開されているAndroidアプリを解析してサーバの接続先やAPIの仕組みを調べ、そのサーバに合わせて脆弱性を突きます。NICTは注意喚起の本文で「公開アプリが解析されること自体を完全に防ぐことは困難です」と書き、恒久的な対策として「アプリ側の制御のみに依存せず、バックエンドサーバ側で適切な認証・認可や入力値の検証などを実施することが重要」としています（NICTの注意喚起PDF）。
この記事は、注意喚起を開発者向けの実装チェック表に直し、AIのAPIキーをサーバ側に移す設計、BOLA（IDOR）とSSRFの点検、漏えいが疑われる鍵の止め方を、OWASPとOpenAI・Anthropic・Googleの公式文書で確かめられた範囲で整理します。注意喚起の全体像は、同じ日にUravationのメディアに載せた経営・情報システム向けの記事に任せ、ここでは実装に絞ります。
この記事の要点（2026年10月16日時点）
- JPCERT/CCは、公開しているスマートフォンアプリを解析して「APIのエンドポイントやキーを特定する」手口を挙げています。アプリに入れた鍵は、取り出されうる前提で扱います。
- OpenAIとGoogle（Gemini API）は、APIキーをブラウザやアプリなどクライアント側のコードに置かないよう公式に案内しています。
- AIの呼び出しは自社のサーバ経由か、事業者が案内する仕組み（OpenAIの一時的なキー、GoogleのFirebase AI Logic）にし、中継のサーバでも利用者を確かめます。
- サーバ側では、IDを受け取ってデータに触る処理ごとに認可を確かめ（OWASP API1:2023 BOLA）、URLを取りに行く機能にはSSRFの対策を入れます。
- 漏えいが疑われる鍵は、無効化・再発行・使用履歴の確認・アプリとサーバの更新の順で止めます。
対象読者：AI機能を組み込んだスマートフォンアプリやWebサービスと、そのバックエンドAPIを作る開発者・テックリード。
読み終えたらできること：自分のアプリとAPIを6項目のチェック表で点検し、AIのAPIキーを止める手順を各社の公式の案内で確かめられます。
A2B攻撃の流れ｜開発者が押さえる3つの事実
NICTの注意喚起PDFによると、攻撃者はGoogle Playの日本地域で公開されているAndroidアプリを入手し、プログラムを解析して、アプリが通信するバックエンドサーバの接続先、APIの構成、通信に使うパラメータなどを集めます。集めた情報をもとに、サーバごとに攻撃を組み立てる点がこの手口の特徴です（PDF「1. 概要」「2. A2B攻撃の概要」）。NICTとJPCERT/CCの記載を合わせて短く言うと、公開アプリの入手、解析、通信先と鍵の把握、サーバへの攻撃の順です。
開発者として押さえておきたい事実は、次の3つです。
アプリに脆弱性がなくても成り立つ
PDFは「Android アプリ自体に脆弱性が存在しなくても、バックエンドサーバの API に認証・認可や入力値の検証などの不備があれば、個人情報の漏洩やサーバへの不正アクセスなどにつながる可能性があります」と書いています。アプリの診断で問題が出なかったことは、サーバ側のAPIが安全だという理由になりません。
ログインが必要なAPIも対象になる
PDFは「認証を必要としない API だけでなく、利用者アカウントによる認証後に利用できる API も攻撃対象となる場合があります」としています。JPCERT/CCも、本来は画面操作で実行できない内部APIへの攻撃として、ユーザー権限の変更や不正なアカウントの作成を挙げています（JPCERT-AT-2026-0030）。
解析で通信先と鍵が知られる
JPCERT/CCは、API経由の不正な操作の手口として「一般公開しているスマートフォンアプリを解析しAPIのエンドポイントやキーを特定する」と「他のシステムの侵害で窃取したAPIキーを使用する」を挙げています。アプリに入れた鍵は、通信先と同じように相手に知られうる情報として扱います。
NICTが主に狙われている脆弱性として挙げたのは、SSRF、RCE、SQLインジェクション、IDOR（BOLA）の4種類で、同様の問題はiOSアプリやWebサービスのバックエンドAPIでも起こりうるとしています。AIについては、解析や脆弱性の探索がAIで効率化され、こうした攻撃がより多くのシステムに広がる可能性に注意を促していますが、今回確認された攻撃にAIが使われたかどうかは書かれていません。
A2B攻撃対策の実装チェック表｜6項目と根拠
注意喚起とOWASP、AI事業者の公式文書をもとに、開発者が点検する6項目を表にしました。①と②はアプリと鍵の置き場所、③〜⑥（BOLA/IDOR、SSRF、古いAPI・検証環境、鍵の用途分けと上限）はサーバ側と管理画面で確かめる項目です。
| 項目 | 確かめること | 見るところ | 根拠 |
|---|---|---|---|
| ①アプリの中の秘密 | アプリの中にAIのAPIキー・クラウドの鍵・固定のパスワードが無いか | ソースコード、設定ファイル、同梱するリソース、ライブラリの設定。検証用・連携用のURLなど開発の残り物も | OWASP MASWE-0004、NICT PDF「固定された認証情報や暗号鍵が露出していないか」 |
| ②AIの呼び出し経路 | AIの呼び出しを自社のサーバ（または事業者が案内する仕組み）経由にしているか | アプリからAIのAPIを直接呼ぶ箇所。SDKのブラウザ向けの設定を本番で有効にしていないか | OpenAIのAPIリファレンス、GoogleのGemini APIキーの説明、OpenAI・AnthropicのSDKの説明 |
| ③BOLA/IDOR | IDを受け取る処理ごとに「この利用者がこのデータを触ってよいか」をサーバ側で確かめているか | 識別子を変えて他者の情報を閲覧・変更できないか。画面に無い管理用の操作も | NICT PDF「認可不備（IDOR/BOLA）」、OWASP API1:2023・API5:2023、JPCERT/CC |
| ④SSRF | URLを受け取ってサーバが取りに行く機能を絞っているか | URL取得・画像処理・文書変換、Webhook、URLのプレビュー | NICT PDF「SSRF」、OWASP API7:2023 |
| ⑤古いAPI・検証環境 | 古いAPI・検証環境・使っていないサブドメインを一覧にし、止めるか制限しているか | 旧バージョンのAPI、検証環境、サブドメイン、クラウド上の公開サービス、ストレージの公開設定 | NICT PDF「侵害の確認」「暫定的な緩和策」、OWASP API9:2023 |
| ⑥鍵の用途分けと上限 | 鍵ごとに用途を分け、最小限の権限と期限、使う額の上限、無効化の手順を決めているか | 開発・検証・本番で別の鍵、使う額の上限か請求のアラート、止める人と管理画面 | JPCERT/CC（最小限の権限・有効期限・速やかな無効化）、OWASP API4:2023、各社のヘルプ |
①②が片付いても、③〜⑥が残っていればA2B攻撃で狙われる不備は残ります。なお、NICTのPDFは、主に探索・悪用の対象になっている脆弱性をSSRF・RCE（遠隔からのコード実行）・SQLインジェクション・IDORの4種類とし、この4種類の重点的な点検を推奨しています。この表に入れていないRCEとSQLインジェクション（NoSQLインジェクションを含む）は、PDF「脆弱性の点検」の項目で別に確かめてください。NICTのPDFは、アプリの内部構造やAPIの仕様が攻撃者に知られた場合でも、バックエンドサーバの安全性が確保されるように設計・運用することが重要だとしています。以下、表の順に中身を見ていきます。
アプリへのAPIキー埋め込みをやめる｜OWASPと各社の記載
OWASPのモバイルアプリの弱点の一覧（MASWE）は、アプリのパッケージ（APK・IPA）に埋め込まれた機密情報は、パッケージをダウンロードした誰もが取り出せる（anyone who downloads the package can recover it）と説明しています（MASWE-0004）。対象は、自社・他社のサービスのAPIキーと秘密情報、パスワードやセッショントークン、暗号の鍵、検証用・連携用のURLのような開発の残り物です。影響の最初に挙がるのは金銭の損失で、取り出されたAPIキーで課金されるAPI（例としてAI/MLのサービス）を勝手に呼ばれ、持ち主に想定外の請求が来る、という説明です（OWASP MASWE-0004）。NICTのPDFも、点検の観点に「固定された認証情報や暗号鍵が露出していないか」を挙げています。
OpenAI・Google・Anthropicの公式の記載
AIのAPIキーについては、事業者側もクライアント（ブラウザやアプリ）に置かないよう案内しています。2026年10月16日に各社のページで確認できた記載は次のとおりです。
| 事業者 | 公式の記載（要約） | 出典 |
|---|---|---|
| OpenAI | APIキーは秘密情報で、ブラウザやアプリなどクライアント側のコードに出さない。サーバ上で環境変数か鍵管理サービスから読み込む | API Overview（Authentication） |
| Google（Gemini API） | 本番ではAPIキーをWebやモバイルのアプリに直接書き込まない。クライアント側のコードに組み込んだ鍵は利用者が取り出せる。クライアントのアプリを守るには、実際のAPI呼び出しをバックエンドのプロキシサーバで行う | Using Gemini API keys |
| Anthropic | 公式のTypeScript向けSDKは、秘密の認証情報を出さないためにWebブラウザでの利用を既定で無効にしている。APIキーはアカウントの鍵で、クレジットカード番号のように、他人に使われると持ち主の負担で課金される | Claude SDK for TypeScript、API Key Best Practices |
Googleはさらに、Gemini APIの鍵を他のGoogle APIと共用するのを勧めておらず、他のサービス用の鍵の制限からGemini API（Generative Language API）を外し、Gemini用には別の鍵を作るよう案内しています。制限のない標準のAPIキーからのリクエストは、Gemini APIが受け付けません。アプリに地図など別の用途でGoogleのAPIキーを入れている場合は、その鍵の制限にGemini APIが含まれていないかも確かめます。
難読化は鍵を置いてよい理由にならない
MASWE-0004は対策として、APIプロキシやゲートウェイを挟んで静的な秘密をクライアントではなくサーバ側に置くことと、短い時間（例として1時間）で切れる動的なトークンを使うことを挙げています。一方、ホワイトボックス暗号やコード・リソースの難読化は、ほかに安全な方法が無い時の最後の手段（Harden Only as a Last Resort）とされ、取り出しの手間を増やすだけで防ぎはしない（deter but do not prevent extraction）、ほかの対策の代わりにしてはならない、と書かれています。
SDKの「ブラウザで使う」設定を本番で有効にしない
OpenAIのNode.js向けSDKとAnthropicのTypeScript向けSDKは、どちらもWebブラウザでの利用を既定で無効にしており、有効にするには dangerouslyAllowBrowser を true にする必要があります。OpenAIのSDKの説明は、この設定は秘密のAPI認証情報をクライアント側のコードに出すことになり、ブラウザを使える人なら誰でも調べて取り出し、悪用できる可能性があるとしています（OpenAI TypeScript and JavaScript API Library）。危険が小さい場面として挙がるのは、信頼できる利用者だけの社内ツールや、短命の鍵を使う開発・デバッグなどです。AIのAPIキーは使った分だけ課金される鍵なので、一般に公開するアプリでは本番で使わない設定と考えます。
AIの呼び出しは自社のサーバ経由に｜中継で確かめる4つ
アプリに鍵を置かないなら、AIのAPIを呼ぶのは自社のサーバの役目です。アプリは自社のサーバを呼び、自社のサーバがAIのAPIを呼ぶ形で、APIキーはサーバに置く形にします。Googleはバックエンドのプロキシサーバで実際のAPI呼び出しを行うよう案内し、OWASP MASWE-0004も、APIプロキシやゲートウェイで秘密をサーバ側に置く形を挙げています。
ただし、中継のサーバを立てただけでは終わりません。そのAPIを誰でも呼べる作りなら、鍵の代わりに中継のAPIが使われます。攻撃者はアプリを介さずにAPIを直接操作できる（NICT）からです。OWASPのRESTのチートシートも、重要な資源をAPIキーだけで守らないよう書いています（REST Security Cheat Sheet）。
中継のサーバで確かめる4つ
- 利用者の認証：誰の依頼かを確かめます。OWASP API2:2023は、APIキーは利用者の認証ではなく、APIクライアントの認証にだけ使うよう書いています（API2:2023）。
- リクエスト件数の制限：JPCERT/CCは、単位時間あたりのリクエスト件数の制限と、悪用のリスクが高い機能への個別のレート制限・利用回数の制限を求めています。OWASP API4:2023も、1人の利用者が同じ操作をできる回数の制限を挙げています。
- 入力の大きさの上限：OWASP API4:2023は、文字列の長さ、配列の要素数、ファイルの大きさなど、届くすべての引数と本文に上限を決めて守らせるよう書いています（API4:2023）。AIに渡す文章や画像も対象です。
- 利用者ごとの識別子：OpenAIは、利用者がモデルとやり取りする製品では、利用者を一意に表す識別子（safety identifier）を送ることを勧めています（必須ではありません）。悪用の検知に役立ち、1人の悪用で組織全体の利用が止まる可能性を減らせる、という説明です（Safety best practices）。
識別子を付けられるのは、ログインした利用者を知っているサーバだけです。OpenAIの手引きにある例（Python）をそのまま載せます。
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-6-astra",
messages=[{"role": "user", "content": "This is a test"}],
max_completion_tokens=5,
safety_identifier="user_123456",
)- ポイント：
"user_123456"は手引きの見本の値です。実際には利用者を一意に表す値（ユーザー名やメールアドレスはハッシュにした値）をサーバ側で入れます。APIキーはコードに書かず、サーバ上の環境変数か鍵管理サービスから読み込みます（OpenAIのAPIリファレンス）。 - 動作環境：OpenAIの公式Python SDK（モデル名は手引きの記載のまま）。注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。
事業者が案内する「アプリから直接つなぐ」仕組み
音声の会話のように、アプリから直接AIのサービスにつなぎたい場面向けに、事業者は通常のAPIキーをアプリに置かない仕組みを案内しています。
- OpenAI（Realtime API）：ブラウザからつなぐ方法として、ブラウザのSDP（接続の情報）を開発者のサーバが受け取り、通常のAPIキーでRealtime APIに送ってセッションを作る方法と、サーバが通常のAPIキーで一時的なキー（ephemeral API key）を作ってブラウザに返す方法の2つを案内しています（WebRTC）。どちらも通常のAPIキーはサーバに置いたままで、一時的なキーを作るサーバ側のリクエストに利用者の識別子を付けると、識別子がそのセッションに結びつく、とされています。
- Google（Gemini API）：アプリから直接呼ぶ場合は、Firebase AI Logicのクライアント向けSDKを案内しています。間に入るプロキシのサービスとFirebase App Checkで、Gemini APIの鍵はサーバに残り、アプリのコードに埋め込まれないという説明です（Gemini API using Firebase AI Logic）。App Checkを強制すると、本物のアプリや改ざんされていない端末からと確かめられたリクエストだけを受け付け、2026年11月2日からはこの強制が必須になります（Prevent Gemini API abuse with Firebase App Check）。
- Anthropic：今回確認したAPIの概要、SDKの説明、サポート記事の範囲では、アプリから直接つなぐための専用の仕組みは確認できませんでした。自社のサーバで中継する形で考えます。
一時的なキーを返すエンドポイントも、APIの1つです。JPCERT/CCは「非公開APIを含む各APIエンドポイントでアクセス制御を実施し、許可された利用者やHTTPメソッドからのアクセスのみを受け付ける」よう求めています。キーを出す前に利用者を確かめ、発行の回数にも上限をかけます。
BOLA対策｜データに触るたびに認可を確かめる
NICTの説明では、IDOR（Insecure Direct Object Reference）は、利用者IDやデータIDといった識別子を指定する時に適切なアクセス権限の確認が行われていないことで起きる脆弱性で、BOLA（Broken Object Level Authorization：オブジェクト単位の認可不備）とも呼ばれます。識別子を変えるだけで他の利用者の情報が取れてしまう形で、識別子が推測・列挙しやすいと大量の情報漏洩につながるおそれがある、とPDFは書いています。
OWASPが挙げるBOLA対策4つ
OWASP API Security Top 10 2023はこの問題を1番目（API1:2023）に置き、ユーザーから受け取ったIDでデータソースにアクセスするすべての処理で、オブジェクト単位の認可チェックを考えるべきだとしています。防ぎ方は次の4つです（API1:2023）。
- 利用者の権限の方針と階層に基づく認可の仕組みを用意する
- クライアントからの入力でデータベースのレコードにアクセスするすべての処理で、ログインしている利用者がそのレコードにその操作をしてよいかを、認可の仕組みで確かめる
- レコードのIDには、推測しにくいランダムな値（GUID）を使うほうがよい
- 認可の仕組みを確かめるテストを書き、テストが通らない変更はデプロイしない
OWASPは、セッションの利用者ID（例：JWTから取り出したもの）とリクエストのIDを比べるだけでは十分ではなく、対処できるのはごく一部の場合だけだ、とも書いています。NICTのPDFが挙げる点検の観点は「会員 ID などの識別子を変更することで、他者や他テナントの情報を閲覧・変更できないか」です。別の利用者・別のテナントのIDを指定すると拒否されることを確かめるテストを置けば、OWASPが挙げる4つ目の項目（認可のテストを書き、通らない変更はデプロイしない）にそのままつながります。
画面に無い操作もサーバで止める（BFLA）
JPCERT/CCは、本来は画面操作で実行できない内部APIへの攻撃として、ユーザー権限の変更や不正なアカウントの作成を挙げています。管理用の機能など、その利用者が使えないはずの機能を呼べてしまう問題を、OWASPは機能単位の認可不備（API5:2023 Broken Function Level Authorization）として扱っています。防ぎ方として、既定ですべてのアクセスを拒否し、機能ごとに役割へ明示的に許可を与えること、URLのパスだけで一般向けか管理用かを決めつけないことを挙げ、HTTPメソッドを変えるだけで作成・変更・削除ができないかも確かめるよう書いています（API5:2023）。
AIが読むデータにも同じ認可をかける
AIエージェントやRAG（社内文書などを検索して答える仕組み）が利用者の代わりにAPIやデータを読む場合も、誰の依頼かと、その人がそのデータに触ってよいかをサーバ側で確かめる点は同じです。モデルが組み立てたリクエストに入ったIDも、クライアントから届いた入力と同じ扱いにして認可を通す、と考えて設計します。文書の検索に権限をかける実装はRAGのデータセキュリティ実装、エージェントがツールを使う時の認可はMCP認可の実装ガイド（OAuth 2.1）で扱っています。
SSRF対策｜URLを受け取って取りに行く機能を絞る
SSRF（Server-Side Request Forgery）は、外部からのリクエストによってバックエンドサーバに本来意図していない通信をさせる脆弱性で、悪用されると外から直接アクセスできない内部のシステムやクラウド環境のメタデータなどにアクセスされ、機密情報を取られる可能性があります（NICT PDF）。NICTが挙げる点検の観点は「URL 取得、画像処理、文書変換などの機能を通じて、内部ネットワーク、クラウドのメタデータサービス、ローカルファイルなどへアクセスできないか」です。
OWASP API7:2023は、SSRFを招きやすい機能としてWebhook、URLからのファイル取得、独自のSSO、URLのプレビューを挙げています（API7:2023）。利用者が貼ったURLの中身をAIに要約させる、URL先の画像をAIに読ませる、といった機能も、URLを受け取ってサーバが取りに行く機能に当たります。
OWASPが挙げるSSRFの防ぎ方
- 取りに行く仕組みをネットワーク上で隔離する（こうした機能は外のリソースを取るためのもので、内部のものを取る必要はない）
- できる限り許可リストを使う：取得元にしてよい相手先、URLのスキームとポート、その機能で受け付けるメディアの種類
- HTTPのリダイレクトを無効にする
- よくテストされ保守されているURLパーサーを使い、解釈の食い違いによる問題を避ける
- クライアントから届く入力をすべて検証・無害化する
- 取得した応答をそのままクライアントに返さない
OWASPは、SSRFのリスクは常に完全になくせるわけではないとも書き、業務上の必要とリスクを見て守り方を選ぶよう求めています。AIの機能のためにURL取得を新しく足す時は、表の④を設計の段階で確かめておきます。
古いAPI・検証環境・公開設定を棚卸しする
NICTは侵害の確認の最初に、APIとインターネットに公開しているホストを列挙するよう求めています。対象には、アプリが利用するAPI、サブドメイン、旧バージョンのAPI、検証環境、クラウド上の公開サービスなども含めます。暫定的な緩和策としても「不要な公開 API、管理機能、検証環境へのアクセスを停止または制限してください」を挙げています（PDF「4. Android アプリを公開する事業者に推奨する対策」）。国家サイバー統括室も「利用していないシステムや機能は停止・削除する」としています。
OWASP API9:2023の棚卸しの観点
- APIのホストごとに、どの環境か（本番・ステージング・テスト・開発）、誰がネットワークでアクセスできるべきか（公開・社内・取引先）、どのバージョンかを記録する
- APIのバージョンごとに廃止の計画を持つ
- 本番以外の環境に本番のデータを使わない。避けられない場合は本番と同じ守りをかける
- 新しいバージョンで守りを強めた時は、改善を古い版に移すか、古い版を早く止めてすべてのクライアントを新しい版に移すかを決める
最後の項目は、古い版のアプリが古いAPIを呼び続けている時に効いてきます（API9:2023）。MASWE-0004は検証用や連携用のURLがアプリに残ることも弱点に挙げているので、自分たちのアプリのソースと設定に書かれた通信先を一覧にすると、止め忘れのAPIを探す手がかりになります。
クラウドのストレージとデータベースの公開設定
NICTは「S3、GCS、Firestore などのサービスに、認証なし、または本来許可されていない権限でアクセスできないか」も点検の観点に挙げています。国家サイバー統括室も、クラウドサービスを利用する場合はサービスの仕様を理解し、保存領域やデータベースなどの公開設定とアクセス権限の設定をよく確認するよう書いています（国家サイバー統括室）。
鍵の用途分け・使用上限・期限｜止められる鍵にする
JPCERT/CCは対策として「API利用者やAPIトークンには必要最小限の権限のみを付与する」「APIトークンには適切な有効期限を設定し、長期間有効なトークンの使用を避ける」「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」を挙げています。AIのAPIキーに当てはめると、各社の記載から次の準備ができます。
| やること | 公式の記載 | 出典 |
|---|---|---|
| 用途・環境ごとに鍵を分ける | 開発・テスト・本番で別の鍵を使えば、漏れた時にその用途だけをすぐ止めて被害を限れる。鍵の種類と有効期限は作成時に選び、ワークスペースで環境を分けて用途ごとに使う額を管理する（Anthropic） | API Key Best Practices、API overview |
| 使う額の上限と通知 | 外部サービスやAPI連携のすべてに使う額の上限を設定し、できなければ請求のアラートを設定する（OWASP API4:2023）。使用額のアラートと、月の上限で通信を止めるハードリミットを設定できる。本番で有効にする前に手引きを確認する（OpenAI）。Custom Rate Limit の組織は使用量と使う額の上限を、Standard Rate Limit の組織は自動チャージの上限を設定する（Anthropic）。請求のアラートを設定する（Google） | API4:2023、Production best practices、API Key Best Practices、Using Gemini API keys |
| 鍵に制限をかける | 鍵をGemini APIだけに制限し、IPアドレスなど使える接続元を制限する。長く使われていない制限なしの鍵は2026年5月7日からブロックされ、2026年5月28日以降にAI Studioで作る鍵はサービスアカウントに結びついた認可キーになる（Google） | Using Gemini API keys |
| 定期的に替える | 例えば90日ごとなど決まった間隔で新しい鍵を作り、古い鍵を止める（Anthropic） | API Key Best Practices |
| 保管する場所 | サーバ上で環境変数か鍵管理サービスから読み込む（OpenAI）。本番では安全な秘密の保管先に置く（Google）。dotenvを使う場合は .env をソース管理の対象外にし、クラウドでは暗号化された秘密の保管を優先する（Anthropic） | API Overview、Using Gemini API keys、API Key Best Practices |
Anthropicのサポート記事には、サーバ側でpython-dotenvを使って環境変数から鍵を読み込むPythonの例も載っています。どの書き方でも、鍵を読み込むのはサーバのコードで、アプリのパッケージには入れません。鍵の保管・交換の運用はAIエージェントのシークレット・認証情報管理 運用ガイドに、使用量の見える化と予算上限の実装はAIエージェントのコスト監視の記事にまとめています。
入られた後｜漏えいが疑われる鍵を止める手順
国家サイバー統括室は2026年10月9日の文書で「侵入を完全に防ぐことは困難です。不審な挙動の早期発見と迅速な対応が被害発生及び拡大の防止につながります」と書いています。NICTも暫定的な緩和策に「認証情報やトークンの漏洩・悪用が疑われる場合は、該当する認証情報の無効化・再発行などを実施してください」を挙げています。漏えいが疑われる鍵は、次の5段で止めます。
- 鍵の無効化：漏えいや悪用が疑われる鍵を止めます（OpenAIは速やかな無効化を、Anthropicは直ちに無効化することを案内）。
- 再発行：新しい鍵を作り、秘密の管理の仕組みに保管します。バージョン管理には入れません（Anthropic）。
- 使用履歴の確認：管理画面で使用量と請求を見て、身に覚えのない使い方がないかを確かめます。NICTは、不審なアクセスがあれば影響の有無と範囲を速やかに調べるよう求めています。
- アプリとサーバの更新：鍵を入れていたアプリは鍵を含まない版に更新し、古いAPIの版について、改善を古い版にも移すか、古い版を早く止めてすべてのクライアントを新しい版に移すかを決めます（OWASP API9:2023）。
- 上限と制限の見直し：使う額の上限、鍵の制限、用途の分け方を見直します。
どの鍵を先に止めるか
JPCERT/CCは「不要となった、または漏えいが疑われるAPIトークンは速やかに無効化できるようにする」よう求めています。一次情報に照らすと、先に止める候補は次の3つです。
- アプリに入れていた鍵：リリース済みの版を含みます。クライアント側のコードに組み込んだ鍵は利用者が取り出せ（Google）、アプリの解析でキーを特定する手口が報告されています（JPCERT/CC）。
- 侵害が疑われるシステムに置いていた鍵：他のシステムの侵害で窃取したAPIキーを使う手口が報告されています（JPCERT/CC）。
- 使っていない鍵：JPCERT/CCは、不要となったトークンも速やかに無効化できるようにする対象に挙げています。
各社の管理画面での止め方
2026年10月16日に確認した各社の案内です。画面の名前や場所は変わることがあるので、作業の前に公式のページを開いて確かめてください。
| 事業者 | 止め方（公式の記載） | 補足 |
|---|---|---|
| OpenAI | Security settings ですべてのAPIキーを確認し、危うくなった鍵を無効化して新しい鍵に置き換える（Safety best practices） | 無効化は数秒で反映。APIキーの認証に関わる多くの更新は15分以内に反映されるが、それ以上かかる場合もある（API Overview） |
| Anthropic | Claude Consoleにログインし、プロフィールからAPI keysのページを開き、対象の鍵の横の「…」メニューから「Delete API Key」を選ぶ。新しい鍵は同じページの「Create Key」で作る（What should I do if I suspect my API key has been compromised?） | 公開のGitHubリポジトリで見つかったClaudeのAPIキーは、GitHubからの通知を受けてAnthropicが自動で無効化し、メールで知らせる。不審な使い方が続く場合はサポートへ |
| Google（Gemini API） | 漏えいが疑われる時は、①新しい鍵を作る ②アプリを新しい鍵で更新する ③新しい鍵が動くのを確かめてからCloudコンソールで古い鍵を無効化・削除する ④請求のログとAPIの使用状況を確かめる（Using Gemini API keys） | 新しい鍵が完全に動くまで古い鍵を消さない（止まる時間を作らないため）。認可キーには、検知した漏えい鍵の使用を素早く止める仕組みがある |
Googleの手順は、新しい鍵へ切り替えてから古い鍵を止める順で、アプリが止まる時間を作らないための書き方です。OpenAIとAnthropicは速やかな無効化を案内しています。悪用が見えている時は先に止め、動かなくなる機能は後から直す、と事前に決めておくと迷いません。鍵をサーバに置いていれば、差し替えはサーバの設定の変更で済みます。
エージェントの外部連携も切る
AIエージェントを社内外のサービスにつないでいる場合は、その連携のトークンも同じ扱いにします。IPAは、利用している外部サービスをすべて洗い出し、より強固な対策として「API連携等アプリケーション構成要素単位での管理状況の見直し」の検討を挙げています（IPA）。連携の設定を外すだけでなく、発行したトークンも無効にします。開発端末の秘密情報がエージェント経由で外に出る経路は、Copilot CLIのプロンプトインジェクションの記事で扱っています。
戻せるもの・戻せないもの
鍵は無効化して作り直せますが、取られた情報は取り戻せません。後から調べられる範囲はログ次第で、NICTは2026年8月以降のアクセスログ、APIログ、認証ログなどの確認を求め、国家サイバー統括室もログの取得・保管とアクセス記録の取得を挙げています。AIの中継サーバでも、どの利用者の依頼で、いつ、どのAPIを呼んだかを残しておくと、鍵が漏れた時に影響の範囲を説明しやすくなります。
利用者の個人データが漏れた、またはそのおそれがある場合は、報告の義務に当たるかも確かめます。個人情報保護委員会のページは「発覚したら、まずは速やかに報告してください」「不正な目的で行われたおそれがある場合は、発覚日から、60日以内」と示し、「外部からの不正アクセスによりデータが窃取された場合」を不正の目的によるおそれの例に挙げています。
【要注意】A2B攻撃対策でよくある失敗5つ
失敗1：難読化したので鍵をアプリに入れてよいと考える
❌ APIキーを難読化してアプリに入れる
⭕ 鍵はサーバか、事業者が案内する仕組みの側に置く
なぜ重要か：OWASP MASWE-0004は難読化を最後の手段とし、取り出しの手間を増やすだけで防ぎはしないと書いています。
失敗2：ログインが必要なAPIだから認可を省く
❌ 認証済みの利用者しか呼べないので、データごとの認可チェックを省く
⭕ IDを受け取ってデータに触る処理ごとに認可を確かめる
なぜ重要か：NICTは認証後に使えるAPIも攻撃対象になるとし、OWASPはセッションの利用者IDとリクエストのIDを比べるだけでは不十分としています。
失敗3：IDをランダムにしたので認可は要らないと考える
❌ IDを推測しにくい値にしたので、他人のIDは当てられない
⭕ 推測しにくいIDと、処理ごとの認可チェックを両方入れる
なぜ重要か：OWASPが推測しにくいIDを勧めているのは4つの対策の1つで、中心は認可の仕組みです。OWASPの例にも、別のAPIの応答から対象の一覧が分かってしまう場面があります。
失敗4：鍵をサーバに移したが、古い鍵を生かしたまま
❌ 新しい版のアプリから鍵を外し、古い鍵は有効なまま残す
⭕ リリース済みの版に入っていた鍵は新しい鍵に替え、古い鍵を止める
なぜ重要か：Googleは、クライアント側のコードに組み込んだ鍵は利用者が取り出せると書いています。利用者の端末に残った古い版からも、鍵は取り出せる状態のままです。
失敗5：中継のサーバを誰でも呼べる形で公開する
❌ アプリからの依頼をそのままAIに渡すAPIを、認証も回数の制限もなく公開する
⭕ 利用者の認証、リクエスト件数の制限、入力の大きさの上限をかける
なぜ重要か：攻撃者はアプリを介さずにAPIを直接操作できる（NICT）ため、中継のAPIが鍵の代わりに使われます。JPCERT/CCはリクエスト件数の制限を、OWASP API4:2023は使う額の上限と入力の大きさの上限を挙げています。
どこから直すか｜編集部が考える5つの順番
ここまでの一次情報を踏まえ、限られた時間で進める順番を編集部の考えとしてまとめます。各段の根拠は、それぞれの節で挙げた一次情報です。
- アプリの中身を棚卸し：自分たちのアプリのソース、設定ファイル、同梱するファイル、ライブラリの設定に、APIキー・固定のパスワード・検証用のURLが無いかを確かめる（MASWE-0004）
- 鍵をサーバへ移して替える：AIの呼び出しを自社のサーバ経由か事業者の仕組みに変え、リリース済みの版に入っていた鍵は新しい鍵に替える（OpenAI・Google・NICT）
- リクエストごとに認可：IDを受け取るAPIと管理用の操作に、利用者ごとの認可チェックとテストを入れる（OWASP API1・API5）
- 不要なAPIを止める：古いAPI・検証環境・使っていないサブドメインを一覧にして止めるか制限し、URLを取りに行く機能があればSSRFの対策も確かめる（NICT・OWASP API9・API7）
- 鍵の上限と止め方を決める：用途ごとの鍵、使う額の上限か請求のアラート、誰がどの画面で止めるかを書き出す（JPCERT/CC・各社のヘルプ）
1と2を先に置いたのは、アプリに入った鍵は利用者の端末に届いた時点で取り出されうるもの（Google・OWASP）で、取り出された鍵で呼ばれた分は持ち主に請求が来る（OWASP MASWE-0004）からです。3は既存のAPIのコードを1つずつ見直す作業になるので、4と並行して進めます。外部に開発を任せたアプリなら、1〜4を委託先と一緒に確かめます。
よくある質問
A2B攻撃とは何ですか？
公開されているAndroidアプリを解析して、つながるバックエンドサーバの接続先やAPIの仕組みを調べ、そのサーバに合わせて脆弱性を突く攻撃です。NICTの脅威情報分析チームLETTICEが2026年10月13日の注意喚起で「A2B攻撃（App-to-Backend Attack）」と名付けました。iOSアプリやWebサービスのバックエンドAPIでも、同様の問題が起こりうるとされています。
Gemini APIのキーをAndroidアプリに入れてもよいですか？
Googleは、本番ではAPIキーをWebやモバイルのアプリに直接書き込まないよう案内しています。クライアント側のコードに組み込んだ鍵は、利用者が取り出せるためです。サーバで中継するか、アプリから直接呼ぶならFirebase AI LogicとApp Checkを使う方法が案内されています。
BOLAとIDORの違いは何ですか？
ほぼ同じ問題を指す呼び方です。NICTは、識別子を指定する時にアクセス権限の確認が行われていない脆弱性をIDORと呼び、同様の問題をBOLA（オブジェクト単位の認可不備）とも呼ぶと説明しています。OWASPではBOLAの名前で1番目に置かれ、管理用の機能を呼べてしまう問題はBFLA（機能単位の認可不備）として別に扱われます。
漏えいが疑われるAIのAPIキーはどう止めますか？
鍵の無効化、再発行、使用履歴の確認、アプリとサーバの更新の順が基本です。OpenAIとAnthropicは速やかな無効化を案内し、Googleは新しい鍵に切り替えてから古い鍵を止める順を示しています。悪用が見えている時は先に止める、と決めておくと迷いません。
まとめ
A2B攻撃は、公開アプリの解析で分かった通信先やAPIの仕組み、アプリに入っていれば鍵を手がかりに、サーバに合わせて脆弱性を突く手口です。公開アプリが解析されること自体を完全に防ぐことは困難（NICT）なので、アプリにAIのAPIキーを置かず、IDを受け取る処理ごとにサーバ側で認可を確かめます。そのうえで、URL取得の制限、古いAPIの停止、鍵の上限と止める手順を整えておきます。
今日・今週・今月にやること
- 今日：アプリのソースと設定にAIのAPIキーや固定のパスワードが無いかを確かめ、使っている各社の管理画面で鍵の一覧と無効化の場所を確認する
- 今週：AIの呼び出しを自社のサーバ経由か事業者の仕組みに移す計画を立て、IDを受け取るAPIに、他人のIDで拒否されることを確かめるテストを足す
- 今月：古いAPI・検証環境を棚卸しして止め、鍵の用途分けと使う額の上限を設定する
あわせて読みたい
- AIエージェントのシークレット・認証情報管理 運用ガイド2026 — 鍵の保管・交換と、漏えい時の初動
- MCP認可の実装ガイド｜OAuth 2.1対応 — エージェントがツールを使う時のトークンと権限の設計
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。
100社以上の企業向けAI研修・導入支援。著書シリーズ累計66,000部。
SBクリエイティブ「ビジネス＋IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- 【注意喚起】相次ぐ情報漏えい、その原因の一つは「アプリ解析からのサーバ攻撃」 — 国立研究開発法人情報通信研究機構（NICT）報道発表、2026年10月13日（参照日: 2026-10-16）
- 【注意喚起】相次ぐ情報漏洩、その原因の一つは「アプリ解析からのサーバ攻撃」（CYNEX Library） — NICT サイバーセキュリティネクサス、2026年10月13日（参照日: 2026-10-16）
- 同 注意喚起の本文（PDF・Rev 1.1） — 脅威情報分析チームLETTICE、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）
- OWASP Top 10 API Security Risks – 2023 — OWASP API Security Project（参照日: 2026-10-16）
- API1:2023 Broken Object Level Authorization — OWASP（参照日: 2026-10-16）
- API2:2023 Broken Authentication — OWASP（参照日: 2026-10-16）
- API4:2023 Unrestricted Resource Consumption — OWASP（参照日: 2026-10-16）
- API5:2023 Broken Function Level Authorization — OWASP（参照日: 2026-10-16）
- API7:2023 Server Side Request Forgery — OWASP（参照日: 2026-10-16）
- API9:2023 Improper Inventory Management — OWASP（参照日: 2026-10-16）
- MASWE-0004: Sensitive Data Hardcoded in the App Package — OWASP Mobile Application Security（MASVS v2 の MASVS-STORAGE-1 に対応・参照日: 2026-10-16）
- REST Security Cheat Sheet — OWASP Cheat Sheet Series（参照日: 2026-10-16）
- API Overview（Authentication） — OpenAI API Reference（参照日: 2026-10-16）
- Production best practices — OpenAI API（参照日: 2026-10-16）
- Safety best practices — OpenAI API（参照日: 2026-10-16）
- WebRTC（Realtime API） — OpenAI API（参照日: 2026-10-16）
- OpenAI TypeScript and JavaScript API Library（README） — OpenAI・GitHub（参照日: 2026-10-16）
- API Key Best Practices: Keeping Your Keys Safe and Secure — Claude Help Center（参照日: 2026-10-16）
- What should I do if I suspect my API key has been compromised? — Claude Help Center（参照日: 2026-10-16）
- API overview — Claude Platform Docs（参照日: 2026-10-16）
- Claude SDK for TypeScript（README） — Anthropic・GitHub（参照日: 2026-10-16）
- Using Gemini API keys — Google AI for Developers（参照日: 2026-10-16）
- Gemini API using Firebase AI Logic — Firebase（参照日: 2026-10-16）
- Prevent Gemini API abuse with Firebase App Check — Firebase（参照日: 2026-10-16）
