第2章の最後は、APIのセキュリティです。ここまでのページは「人間がブラウザーで見るWebサイト」を守る話が中心でしたが、現代のWebサービスの裏側では、プログラム同士が直接データをやり取りする通信、すなわちAPIが大量に流れています。スマホアプリも、他社サービスとの連携も、後の章で学ぶAIエージェントも、すべてAPIの上に成り立っています。
そしてAPIには、Webサイトとは違った守り方が必要です。このページでは、APIとは何かの復習から始めて、なぜ専用の防御が要るのか、CloudflareのAPI Shieldがどう守るのかを見ていきます。第2章の総仕上げとして、これまで学んだ機能との役割分担も整理します。
このページで分かること
- API（Application Programming Interface）とは何か
- なぜAPIにはWebサイトと別の守り方が必要なのか
- API Shieldの主要機能（mTLS・スキーマ検証・APIディスカバリー）
- どのプランで何が使えるか
- 初心者が注意するポイント
APIとは
プログラム同士の「注文窓口」
API（Application Programming Interface）とは、プログラムが別のプログラムの機能やデータを利用するための決まりごと（窓口）です。天気アプリを例にすると、アプリ自体は天気を観測していません。「東京の今日の天気を教えて」というリクエストを気象データ会社のAPIに送り、返ってきたデータ（晴れ、最高気温34度…）を画面に表示しているだけです。
人間向けのWebページとの違いは「返ってくるものの形」です。Webページは人間が読むためのHTML（見た目つきの文書）を返しますが、APIはプログラムが処理するための生データ（現在はJSONという形式が主流）を返します。レストランにたとえると、Webサイトが「店内で給仕される食事」なら、APIは「業者向けの卸売窓口」。同じ厨房（サーバーとデータベース）につながっていますが、窓口の性質がまったく違います。
APIは攻撃者にとって「おいしい」入り口
この卸売窓口は、攻撃者から見ると魅力的な標的です。
- データに直結している：APIは構造化されたデータをまとめて返すため、突破されたときの情報漏えいが大きくなりがちです
- 人間確認が使えない：APIの利用者は正規のプログラムです。ブラウザーを前提としたチャレンジ画面やTurnstileのような「人間確認」を挟むと、正規のアプリまで動かなくなります。第2章で学んだ防御の一部が、そのままでは使えないのです
- 忘れられやすい：開発の過程で作られたAPIが、管理者にも忘れられたまま公開され続けていることがあります（シャドーAPI・ゾンビAPIと呼ばれます）。存在を把握していないものは守れません
こうした事情から、「APIセキュリティ」はWAFやボット対策と並ぶ独立した分野になっており、Cloudflareの答えがAPI Shield（API Security製品群）です。
API Shieldの主要機能
API Shieldの防御は、「相手を確かめる」「中身を確かめる」「存在を把握する」の3つの観点で整理すると分かりやすくなります。
mTLS：接続してくる「相手」を証明書で確かめる
第1章のSSL/TLSのページで、サーバーが証明書で身元を証明する仕組みを学びました。通常のHTTPSでは証明するのはサーバー側だけで、クライアント（接続してくる側）は誰でも接続できます。
mTLS（mutual TLS：相互TLS）は、これを双方向にした仕組みです。クライアント側にも証明書を発行して端末やアプリに組み込んでおき、接続時に「正しい証明書を持つクライアントか」を検証します。証明書を持たない接続は、リクエストの中身を見るまでもなく門前払いです。自社のスマホアプリ専用API、IoT機器からの通信など、「接続してよい相手が決まっているAPI」に絶大な効果があります。クライアント証明書の発行に使う認証局はCloudflareが用意してくれるため、mTLS自体は全プランで設定できます。
スキーマ検証：リクエストが「仕様どおり」かを確かめる
APIには、「このURLにはこの形式のデータを送る」という仕様書を機械可読な形式で書く標準（OpenAPIスキーマ）があります。スキーマ検証（Schema Validation）は、この仕様書をCloudflareにアップロードしておき、仕様に合わないリクエストをブロックする機能です。
WAFのマネージドルールが「既知の攻撃パターンに一致するものを拒否する」ブラックリスト型だとすれば、スキーマ検証は「仕様どおりのものだけを許可する」ホワイトリスト型です。想定外のパラメーターや異常な値を使う攻撃は、パターンが未知でも「仕様にない」というだけで弾けます。APIは仕様を厳密に定義できるからこそ成立する、API向きの防御です。
APIディスカバリー：守るべきAPIを「発見」する
API Discoveryは、Cloudflareを流れるトラフィックを分析して、実際に使われているAPIのエンドポイント（APIの個々のURL）を自動的に洗い出す機能です。管理者が把握していなかったシャドーAPIもここで可視化されます。発見したエンドポイントは一覧（Endpoint Management）に登録し、エラー率や応答時間の監視、前ページまでに学んだRate Limitingやスキーマ検証の適用対象にしていきます。「守る対象の台帳を作る」機能と言えます。
このほかEnterprise向けには、ログイン済み利用者の識別情報（JWTと呼ばれるトークン）の検証や、APIが呼ばれる順序の異常検知（Sequence Analytics）など、より高度な機能も用意されています。
どのプランで使えるか
API Shieldのフル機能（API Discovery、高度な検証・分析）はEnterpriseプランの追加契約が中心ですが、基本部分は一般プランにも開放されています（2026年8月時点）。
- 全プランで利用可：mTLS（Cloudflare発行のクライアント証明書）、エンドポイントの手動登録・監視（Freeは100件まで）、スキーマ検証の基本機能（アップロードできる仕様書数などに制限あり）
- Enterprise＋API Shield契約：API Discoveryによる自動発見、JWT検証、Sequence Analytics、登録上限の大幅拡大など
個人開発でAPIを公開する程度であれば、「Rate Limiting＋WAFカスタムルール＋必要ならmTLS」という無料の組み合わせでもかなりの防御になります。API単位の事業を行う規模になったら、API Shieldの本格導入を検討する、という距離感で捉えてください。
初心者が注意するポイント
- まず「自分のAPIはどれか」を把握する：WordPressにもAPIはあります（REST API。URLが /wp-json/ で始まる部分）。守る対象を知ることがAPIセキュリティの第一歩です
- ボット対策・WAFの誤爆に注意：前のページで触れたとおり、ボット対策はAPIやアプリの通信を「自動化」と判定しがちです。APIのURLにはチャレンジではなくブロックやRate Limitingを使う、除外ルールを書くなど、人間向けページとは別の扱いが必要です
- スキーマ検証は仕様書の鮮度が命：APIを更新したのにスキーマを更新し忘れると、正規のリクエストがブロックされます。API開発の手順に「スキーマ更新」を組み込みましょう
- 認証そのものはAPI側の責任：API Shieldは通信の検証を担いますが、「誰にどのデータを返してよいか」という権限管理はアプリケーション側の設計の問題です。ここが崩れているとWAFでもスキーマ検証でも守れません
- HTTPS化は大前提：APIキーやトークンが平文で流れれば、以降の防御はすべて無意味です。第1章のSSL/TLSの知識がここでも土台になります
関連サービス
- Rate Limiting：APIの呼び出し回数制限。API保護の最初の一手です（前々ページ）
- WAF：APIにも適用される中身の検査。スキーマ検証と重ねて使います
- Bot Management：Enterprise版ではAPIトラフィックのボット判定も可能
- Workers：自分でAPIを作る側になるときのCloudflareのサーバーレス実行環境（第5章）
まとめ
- APIはプログラム同士がデータをやり取りする窓口で、人間向けのWebページとは別の守り方が必要
- 「人間確認が使えない」「データに直結」「忘れられやすい」がAPI特有のリスク
- API Shieldは、相手を確かめるmTLS、中身を確かめるスキーマ検証、存在を把握するAPIディスカバリーの3本柱
- mTLSやエンドポイント管理・スキーマ検証の基本は全プランで利用可能。自動発見や高度な分析はEnterpriseの領域
- 個人規模なら「Rate Limiting＋WAF＋必要ならmTLS」の無料構成でも実用的な防御が組める
これで第2章「Webセキュリティ」は完結です。DDoS（量）・WAF（中身）・ボット対策（正体）・Rate Limiting（頻度）・Turnstile（フォーム）・API Security（プログラム間通信）と、攻撃の性質ごとに防御の層を重ねるのがWebセキュリティの基本形だと分かっていただけたと思います。次章からは視点を変えて、「社内のシステムやユーザーを守る」Zero Trustの世界に入ります。
次に読む
※本記事の情報は 2026年8月時点のものです。