生成AIの急速な普及により、アプリケーションとAPIを狙う攻撃が世界的に増加しています。AIアプリや外部連携APIの増加が、企業の新たなアタックサーフェスを生み出しています。
本稿では、アカマイ・テクノロジーズでAPIセキュリティの拡販を担う筆者が、国内企業の診断事例から見えた日本特有のリスクと対策の方向性を紹介し、AI時代の信頼を支える「APIセキュリティ」の最前線を解説します。
日本におけるAPI周りのリスク実例
前編では、APIセキュリティを「24時間365日稼働する警備システム」と位置づけ、その重要性について解説しました。後編では、「API攻撃が増えているといっても、それは海外の話ではないか？」そんな疑問に答えるために、後編ではヘルスチェックから見えてきた日本国内のリアルな状況に焦点を当てます。
ヘルスチェックを実施した企業の業種別割合
ヘルスチェックとは、Akamaiが提供している無償の診断サービスで、組織のAPIが安全かつ正常に動作しているかを自動的に診断・検証する仕組みです。上図は、ヘルスチェックを実施した企業の業種別割合の推移です。2025年9月末時点の内訳を見ると、コマース（37％）、金融（17％）、製造（17％）、IT/Software（12％）と続いています。
ここで注目すべきは、2025年3月末からの半年間で、コマース業界の割合が24%から37%へと急増している点です。なぜ今、コマース業界でこれほどまでに対策が急がれているのでしょうか。その背景には、特有のビジネス環境と切実な被害実態があります。
ECサイトやリテールアプリは、ユーザーの利便性（UX）を最優先に設計される傾向にあり、ログインセッションを長く保持したり、アプリ内部にAPIトークンを埋め込んだりといった実装が少なくありません。攻撃者はこうした「利便性とセキュリティのトレードオフ」を敏感に察知し、公開データ（在庫・店舗情報）と機密データ（購買・決済情報）が混在するAPI環境を格好の標的としています。
実際に発生している被害も深刻です。個人情報の漏えいだけでなく、「転売ヤー」がボットを用いて商品を買い占め、在庫を枯渇させるケースや、ポイントの不正利用、ギフトカードの偽造など、売上に直結する金銭的被害（Fraud）が多発しています。こうした実害が顕在化しているからこそ、現場での危機感が数字の急増として表れているのです。
業種の割合に続いて、日本企業における検知傾向はどのようになっていたのでしょうか。
金融の検知傾向
当該業種で検知した代表的な検知事例は下表の通りになります。
金融業界では、「OWASP API Security」のAPI3（オブジェクトプロパティレベルの認可の不備）、API8（セキュリティの設定ミス）に関連する検知が多い傾向がありました。一般的に堅牢（けんろう）なセキュリティ対策が施されている金融業界ですが、複雑化するシステム実装において、データベースへのアクセス権限や細かな設定周りに課題が残っているケースが見受けられます。
ただし、これらの検知の多くは本番環境ではなく、開発環境で検出されたものです。これは裏を返せば、「リリース前にリスクを洗い出そうとするガバナンスが正常に機能している」証左でもあり、金融業界全体としては依然として高い水準でAPI管理が行われていると言えます。
金融関連の検知傾向
コマース、製造、IT/Softwareの検知傾向
当該業種で検知した代表的な検知事例は下表の通りになります。
OWASP API SecurityのAPI2（認証の不備）、API3（オブジェクトプロパティレベルの認可の不備）に関連する検知が多い傾向がありました。
検知内容を見ると、「APIが期限切れのJWT（JSON Web Token）を受け入れる」や「クエリパラメータで機微データを公開する」といった事象が含まれています。 これは前述した「利便性（UX）の優先」という背景と深くリンクしています。ログイン状態を維持しやすくするため、あるいは実装を簡易にするために認証プロセスを簡略化した結果、攻撃者につけ込まれやすい「APIリスク」が生まれている現状が浮き彫りになりました。
コマース、製造、IT/Software関連の検知傾向
日本全体として特に目立つのは、以下の3つのリスクです。
OWASP API Security Top10のAPI2、3、8の概要
検知数ランキング（日本vs海外）：浮き彫りになる「認証・認可」の実装不備
日本と海外の検知傾向を比較すると、日本企業が抱える構造的な課題がより鮮明に見えてきます。今回は、環境依存による過剰検知の可能性が高い「パスワードポリシー」を除外し、より攻撃に直結しやすい実質的な上位（2〜5位）のリスクに着目して分析します。
日本では「認証されていない変更操作を許可する」「期限切れのJWTを受け入れる」「認証バイパスに対する脆弱性」といった、認証に関わる不備が上位に並んでいるのが特徴です。これは単なる情報の「過剰な公開」にとどまらず、外部から勝手にデータを「書き換えられる（改ざん）」リスクが高いことを意味しています。
なぜ、日本でこのような「認証・認可の欠落」が目立つのでしょうか。
1.「境界型防御の神話」への過度な依存「閉じたネットワーク（VPNなど）やWAFがあるから安全」という境界防御への過信がいまだに根強く残っています。その結果、APIエンドポイント自体に厳格な認証・認可を実装する意識が希薄になっている可能性があります。
2.「急造DX」による実装の甘さ既存のレガシーシステムに対し、DXの名のもとに急ピッチでAPIを「かぶせた」だけの構成において、セッション管理などの引き継ぎがうまくいっていないケースです。期限切れのJWTが通ってしまうなど、モダンな認証仕様が正しく実装されていない可能性があります。
3.セキュリティ要件の「丸投げ」開発を外部ベンダーに委託する際、「機能要件」は詳細でも「非機能要件（セキュリティ）」が曖昧なまま発注されるケースが少なくありません。認証ロジックの堅牢性が担保されないまま納品されたり、アプリに対する脆弱性診断を外部ベンダー内で実施していたりするケース（悪い意味で脆弱性診断のみをクリアするためのナレッジがたまってしまう）もあったりします。
日本、海外におけるポスチャー検知の検知ランキング
