>
>
公開日
最終更新日
APIエンドポイントは、SaaS連携、モバイルアプリ、社内システム連携、生成AI活用など、現在のIT基盤を支える通信の入口です。一方で「エンドポイント」は、APIの接続先だけでなく、PC・スマートフォン・サーバーなどネットワーク末端の端末を指すこともあります。用語を混同すると、開発・セキュリティ・情シスの担当者間で対策範囲がずれる原因になります。
本記事では、主にAPIにおけるエンドポイントを対象に、API URLとの違い、HTTPエンドポイントの仕組み、REST・GraphQL・gRPCの設計差、API Gatewayによる統制、認可不備やシャドウAPIへの対策を整理します。50名未満の小規模組織ではまず公開APIの一覧化から、50〜300名規模では仕様・ログ・権限の標準化から、300名超ではゲートウェイや資産検出を含む統制基盤から着手すると進めやすくなります。
本記事では、OWASP API Security Top 10 2023、Model Context Protocolの公式仕様、クラウド各社のAI Gateway関連ドキュメント、国内企業の公開事例を参照し、API設計・管理の実務論点を解説します。
APIエンドポイントとは
APIエンドポイントは、システム間連携におけるデータや処理の具体的な通信窓口です。
API通信における意味
APIとは、異なるアプリケーションやサービスが定められた形式で情報をやり取りする仕組みです。APIエンドポイントは、その仕組みの中でリクエストを受け付ける個別の窓口を指します。たとえば勤怠システムから従業員一覧を取得する場合、https://api.example.jp/v1/employeesのようなAPIアドレスへリクエストを送ります。
ただし、エンドポイントを「URLとHTTPメソッドの組み合わせ」と定義するチームもあれば、「ネットワーク上の接続先URL」として扱うAPI仕様やフレームワークもあります。実務では、API仕様書に対象URL、許可するメソッド、認証方式、入力値、返却値をセットで記載し、認識のずれを防ぎます。
通信の流れは、クライアントがエンドポイントへリクエストを送り、APIが認証・認可・入力検証を行い、必要に応じてデータベースや外部サービスを呼び出してレスポンスを返す形です。レスポンスにはJSONが使われることが多く、成功時は200 OK、作成成功時は201 Created、不正な要求時は400 Bad RequestなどのHTTPステータスを返します。
端末エンドポイントとの区別
セキュリティ分野のエンドポイントは、ネットワークの末端に接続されるPC、スマートフォン、タブレット、サーバー、IoT機器などを指します。こちらはEDR、MDM、パッチ管理、端末暗号化などの対象です。一方、APIエンドポイントはデータや機能にアクセスする論理的な接続先です。
情シス部門では、会議や要件定義書で「エンドポイント」という言葉だけを使わず、「APIエンドポイント」「端末エンドポイント」と修飾して記載すると、担当範囲を明確にできます。端末側の統制を確認したい場合は、セキュリティ用語として混同されやすい端末エンドポイントを管理するMDMの仕組みも参照できます。
APIエンドポイントが担う役割
APIエンドポイントは単なる入口ではありません。利用者を識別する認証、操作権限を判定する認可、入力値の検証、バックエンドサービスへのルーティング、監査ログの出力、過剰アクセスの制御までを含む運用境界になります。公開範囲が広がるほど、設計書にない挙動や例外処理が情報漏えいの原因になります。
Postmanは「2024 State of the API Report」（Postman公式レポートページ）で、回答者の74%がAPIファースト戦略を採用していると報告しています。これは2024年時点の調査であり、組織や地域で差がありますが、画面より先にAPI仕様を定義し、複数のシステム・アプリから再利用する開発が一般化していることを示す材料です。APIファーストで開発する組織では、エンドポイント一覧とOpenAPI仕様書を同じ変更管理の対象に置きます。
API・URL・HTTPエンドポイントの違い
URLは場所を示す住所であり、APIエンドポイントはその場所で実行できるデータ操作の窓口です。
API・URL・エンドポイントの関係
APIはシステム連携のルールや仕組み全体を指します。URLはWeb上のリソースの場所を表す文字列です。APIエンドポイントは、URLに加えて「何をする窓口か」を表す概念として使われます。
用語 | 意味 | 具体例 |
|---|---|---|
API | システム間で情報を連携する仕組み・規約 | 社員情報を取得・登録するAPI |
URL | リソースの所在地を表すアドレス |
|
APIエンドポイント | 特定の処理を受け付ける接続窓口 |
|
HTTPエンドポイント | HTTPまたはHTTPSでアクセスする接続先 |
|
たとえば同じURLでも、GET /v1/usersはユーザー一覧の取得、POST /v1/usersはユーザーの新規登録というように、HTTPメソッドで目的が変わります。このため、運用設計ではURLだけを資産台帳へ載せるのではなく、メソッド、認証、利用者、データ分類も記録します。
HTTPエンドポイントを外部公開する場合、平文HTTPを許可し続ける設計は避けます。TLSを使用するHTTPSを強制し、HTTPからHTTPSへのリダイレクト、HSTS、証明書更新の監視を設定します。社内限定APIでも、クラウド接続や委託先接続があるなら暗号化と証明書管理の対象に含めます。
APIベースURLと個別エンドポイント
API Base URLとは、複数のAPIエンドポイントで共通する先頭部分です。たとえばhttps://api.example.jp/v1がベースURLで、そこへ/usersや/ordersを加えます。環境ごとにベースURLを変え、開発環境・検証環境・本番環境の接続先を分離すると、テストデータを本番へ誤送信する事故を抑えられます。
やってはいけないのは、ソースコードへ本番のAPI Base URLや固定トークンを直接書き込むことです。環境変数、シークレット管理基盤、CI/CDの設定値を使い、開発者のローカル環境や公開リポジトリに機密情報が残らない構成にします。
REST・GraphQL・gRPCの通信特性
設計方式によって、エンドポイントの数と呼び出し方は変わります。RESTはリソース単位、GraphQLはクエリ単位、gRPCはサービスとメソッド単位で設計することが一般的です。
比較軸 | REST API | GraphQL | gRPC |
|---|---|---|---|
エンドポイント数 | 複数。リソースごとに用意 | 単一構成が一般的 | サービス・メソッド単位 |
通信形式 | JSONとHTTPが中心 | クエリとJSONが中心 | Protocol Buffersとバイナリ通信 |
主な用途 | 公開API、Web連携 | 複雑な画面・モバイル連携 | マイクロサービス間通信 |
注意点 | オーバーフェッチ・アンダーフェッチ | 複雑なクエリの制限が必要 | ブラウザ連携に追加構成が必要な場合がある |
GraphQLは/graphqlのような単一エンドポイント構成が標準的ですが、複数エンドポイントに分ける実装も可能です。またgRPCにもネットワーク上の接続先があり、通常はHTTP/2上でサービス・メソッドをRPCとして呼び出します。「URLがない通信」ではなく、RESTとは異なる粒度でサービスを定義する方式と捉えると正確です。
端末情報をAPI連携で統合する例としては、KandjiとAdminaを連携する実務手順を参照してください。
▲ URL（リソースの所在地）とAPIエンドポイント（リソース＋実行操作）の違い
APIエンドポイントの設計・管理手法
APIエンドポイントは、命名規則、仕様書、認証、流量制御、廃止計画を最初からセットで設計します。
API管理市場と管理対象の増加
IMARC Groupは「Japan API Management Market Report 2026-2034」（IMARC Group公式レポートページ）で、日本のAPI管理市場を2025年に9億5,340万米ドル、2034年に37億3,100万米ドルと予測し、2026〜2034年の年平均成長率を16.37%としています。これは市場予測であり実績値ではありませんが、SaaS、クラウド、モバイルアプリ、生成AIの接続増加に伴い、APIを個別開発チームだけで管理し続ける難しさが増していることを示します。対象期間と市場定義の詳細は同ページで確認できます。
50名未満で外部公開APIが少ない組織なら、ツール導入前にOpenAPI仕様書と台帳をGitで管理する方法から始められます。この段階では専任の管理者がいないことが多く、更新コストを最小化することが優先です。50〜300名規模で複数プロダクトがAPIを公開している場合は、チーム間の認識ずれが増えるため、共通の認証方式、命名規則、ログ項目を標準化します。300名を超え、複数クラウドや複数部門がAPIを持つ場合は、個別対応では統制が追いつかなくなるため、API Gateway、カタログ、監査ログ、資産検出を統合し、責任者を明確にします。なお、これらは一般的な目安であり、外部公開APIの数や個人情報の取り扱い範囲によって優先度は変わります。
RESTfulな命名規則
REST APIでは、リソースを名詞・複数形で表すと利用者が理解しやすくなります。たとえば/v1/users、/v1/ordersのように設計し、動詞をURLへ多用しません。処理を明示する必要がある場合も、/v1/orders/{id}/cancelのように例外を限定し、仕様書で意図を説明します。
命名の一貫性は、利用者の実装ミスを減らします。user_idとuserId、created_atとcreatedAtがAPIごとに混在すると、SDKや連携設定で誤りが起きやすくなります。日付の形式、ページネーション、エラー形式、nullの扱いも共通ルールに含めます。
API Gatewayによる一元制御
API Gatewayは、クライアントとバックエンドAPIの間に配置する中継層です。リクエストを適切なサービスへ振り分け、OAuth 2.0やJWTの検証、IP制限、レートリミット、アクセスログ収集、TLS終端などを集約できます。各サービスへ同じ認証処理を個別実装するより、共通制御を保ちやすくなります。
ただし、API Gatewayだけでは業務データの参照権限を完全には判定できません。ゲートウェイは入口の認証・基本制御を担い、バックエンド側では「この利用者がこの注文IDを読めるか」といったオブジェクト単位の認可を実施します。入口と業務ロジックの両方で防御する設計が必要です。
バージョニングとサンセット設計
破壊的変更が必要な場合は、/v1/から/v2/へ新しいバージョンを追加します。レスポンスの必須項目削除、データ型変更、認証方式変更は、既存クライアントを停止させる可能性があるため、同一バージョン内で突然実施しません。
新バージョンの仕様と移行ガイドを公開します。
旧バージョンの利用者、呼び出し回数、依存システムをログで特定します。
Deprecationヘッダーで非推奨化を知らせ、終了日をSunsetヘッダーや開発者向け通知で提示します。移行率を確認し、未移行の利用者へ個別連絡したうえで旧版を停止します。
終了日だけを告知して利用状況を見ない運用は失敗しやすい方法です。アクセスログで利用者を特定できれば移行支援へ進み、特定できなければ旧版の公開範囲を縮小しながら、認証クライアントの登録情報から影響範囲を洗い出します。
OpenAPI仕様書と開発者体験
OpenAPI Specificationは、パス、HTTPメソッド、パラメータ、レスポンス、認証方式を機械可読な形式で記述する標準です。Swagger UIなどを利用すると仕様書を閲覧・試験でき、クライアントSDKやテストケースの生成にも活用できます。仕様書をExcelで別管理し、実装更新時に追従できない状態は避けます。
仕様書には成功レスポンスだけでなく、401 Unauthorized、403 Forbidden、404 Not Found、409 Conflict、429 Too Many Requestsの返却条件を定義します。利用者が再試行の可否や待機時間を判断できるため、問い合わせと無駄な再送を減らせます。
IT資産台帳をAPI連携で更新する運用の例は、API連携を活用してIT資産台帳を自動更新するMDM連携の仕組みで確認できます。
APIを活用してシステム間のデータ連携や台帳管理を自動化したい場合は、MDM連携による台帳自動更新の仕組みと運用ポイントをご覧ください。
API管理における国内企業事例
国内企業の事例では、APIを増やすこと自体ではなく、接続先・権限・コストを一元化することが成果につながっています。
BIPROGY株式会社の生成AI API基盤
BIPROGY株式会社は、グループ社員向けのAzure OpenAI API利用環境を整備する取り組みを同社公式サイトで公開しています（詳細はBIPROGY公式の事例・ブログページで確認してください）。課題は、複数のAIモデル利用に伴う接続先管理、利用量の把握、セキュリティポリシーの統一でした。同社はAzure API ManagementとApplication Gatewayを前段に置き、社内からのAI APIアクセスを集約する構成を採用しました。
この構成では、利用者・アプリケーションごとに流量制御を設定し、モデルやリージョンへのルーティングを管理しやすくしています。AI APIでは、通常のリクエスト回数に加えて入出力トークンがコストと性能に影響します。従来のWeb APIと同じ感覚で無制限に公開すると、予算超過や応答遅延が起きるため、API管理基盤をAI利用のガバナンスに転用した事例といえます。
株式会社日テレWandsのクラウド連携基盤
株式会社日テレWandsは、オンプレミスの基幹システムや会計データと、クラウド上のサービスを安全に連携する目的でAmazon API Gatewayを活用した事例を公開しています。クラスメソッド株式会社が2024年12月17日に公開した導入事例（クラスメソッド DevelopersIOにて該当事例を参照）では、外部接続用のAPIエンドポイントを整備し、既存のセキュリティポリシーを満たす基盤を構築したと説明しています。
課題は、クラウドサービスごとに個別の接続方式を作ると、認証やネットワーク設定が複雑化する点でした。施策として接続窓口を集約した結果、開発メンバーが統制された条件でAPIを追加しやすい状態を作れました。この事例からは、API Gatewayを導入する前に「どのシステムが、誰の権限で、どのデータを扱うか」を整理する必要があると読み取れます。
freee株式会社のデータ公開事例
CData Software Japanは、freee株式会社がCData API Serverを活用し、社内データベースやデータウェアハウスのデータをREST APIとして公開する事例を紹介しています（CData Software Japan公式サイトに掲載。なお、この事例は2019年公開のものであり、現在の製品仕様や同社の構成と異なる場合があります）。課題は、データ連携のたびに個別開発が必要になり、ビジネス部門が必要なデータへ迅速にアクセスしにくいことでした。
施策では、データソースを接続し、ノーコードに近い形でAPIエンドポイントを用意する方法を採用しています。CData Software Japanは、freee株式会社の事例として、システム開発の都度発生していた連携作業を減らし、データ利用までの時間を短縮したと紹介しています。ただし、APIを容易に公開できる仕組みほど、公開対象テーブル、個人情報のマスキング、認可設定、利用ログの確認を事前に組み込む必要があります。
自社に当てはめる際は、製品名の比較より先に、公開API数、接続先の種類、個人情報の有無、監査ログの保存期間、運用担当者数を洗い出します。監査ログから利用者と呼び出し元を追跡できるなら段階導入へ進み、追跡できなければログ設計と認証基盤の整備を先行させます。
実務において特定のデバイス管理ツールとAPI連携を行う際の設定や注意点については、KandjiとAdminaのAPI連携手順と実務ガイドで詳しく解説しています。
APIセキュリティの脅威と対策
APIセキュリティでは、認証済み利用者による不正操作も前提にし、各リクエストで権限を検証します。
BOLAとオブジェクト単位の認可
OWASPは「API Security Top 10 2023」（OWASP API Security Top 10 2023公式ページ）で、Broken Object Level Authorization、通称BOLAを代表的なAPIリスクとして挙げています。BOLAは、利用者がURLやリクエスト内のIDを書き換えた際に、他者のデータへアクセスできてしまう認可不備です。OWASPのBOLA詳細解説は、オブジェクトIDを受け取るすべてのAPI関数で認可確認を行う必要があると説明しています。
たとえばGET /v1/orders/1001で注文情報を返す場合、ログイン済みであることを確認するだけでは不十分です。注文ID 1001が、その利用者・所属組織・ロールで参照可能かを判定します。実装場所はコントローラー、サービス層、認可サーバー、ポリシーエンジンなど構成により異なりますが、各リクエストでオブジェクト単位の認可を行う点は共通です。
認証・認可・入力検証の分離
認証は「誰か」を確認する処理であり、認可は「その操作を許可するか」を判断する処理です。OAuth 2.0やOpenID Connect、JWT、APIキーなどの認証方式を選んでも、認可ルールがなければ権限外アクセスを防げません。外部公開APIでは、短命なアクセストークン、必要最小限のスコープ、トークン失効、クライアントごとの権限分離を検討します。
入力検証では、型、文字数、許可値、ファイルサイズ、ページサイズをサーバー側で確認します。クライアント画面の入力制御だけに依存すると、攻撃者は直接HTTPリクエストを送れます。SQLインジェクションやコマンドインジェクションへの対策として、プレースホルダー、許可リスト、ORMの適切な利用も併用します。
レートリミットと異常検知
レートリミットは、一定時間内に許容するリクエスト数やトークン数を制限する仕組みです。上限を超えた場合は429 Too Many Requestsを返し、必要に応じてRetry-Afterヘッダーで再試行の目安を示します。IPアドレスだけで制限すると共有ネットワークの利用者を巻き込むため、APIキー、ユーザーID、組織ID、クライアントアプリケーションなど複数の単位で制御します。
監視では、認証失敗、403の急増、存在しないIDへの連続アクセス、通常より大きいレスポンス、深夜帯の大量取得、429の増加を確認対象にします。ログにリクエスト本文を無条件に保存すると個人情報やトークンが残るため、識別子のマスキング、保存期間、閲覧権限を決めます。
シャドウAPIとゾンビAPIの可視化
シャドウAPIは、組織が把握していない状態で存在するAPIです。ゾンビAPIは、利用されていないにもかかわらず公開されたままの旧APIを指します。OWASPはAPI資産の不適切な管理をAPI9:2023 Improper Inventory Managementとして取り上げ、ホスト、バージョン、デプロイ済み環境、データフローを文書化する必要があると説明しています。OWASPのAPI資産管理に関する解説を基準に棚卸し項目を作成できます。
ASM（Attack Surface Management）を使う場合も、検出結果を受け取るだけでは対策になりません。DNS、証明書、クラウドアカウント、API Gatewayログ、WAFログ、ソースコード管理を突合し、所有部門が判明したAPIは仕様書・認証・監視の有無を確認します。所有者不明で外部公開されているAPIは、影響調査後にアクセス制限または停止へ進めます。
▲ BOLA（オブジェクトレベルの認可不備）を防ぐリクエスト検証フロー
API管理で起きる失敗パターン
API管理がうまくいかない主因は、仕様変更、権限、利用量、資産情報を別々に扱うことです。
無告知の破壊的変更
既存のレスポンス項目を削除したり、文字列を数値へ変更したりすると、利用中のアプリケーションが停止する場合があります。「社内APIだから影響は少ない」と判断してバージョンを上げずに変更するケースは、特に部門横断連携で問題になります。
対策は、互換性のない変更を/v2/など別バージョンで提供し、旧版の利用状況をログで追跡することです。利用者一覧を取得できれば移行期限とテスト環境を案内できます。取得できない場合は、認証クライアントの登録状況、DNSアクセスログ、ゲートウェイのアクセスログを組み合わせ、影響範囲を特定してから停止日を決めます。
WAFだけに依存する防御
WAFは既知の攻撃パターンや不正な入力の遮断に役立ちますが、正規の認証情報を使って他人の注文IDを指定するBOLAのような業務ロジック攻撃を単独で防ぐことは困難です。WAF導入後に、バックエンドの認可テストを省略するのは危険です。
APIごとに「誰が」「どの組織の」「どのデータを」「どの操作まで」実行できるかをポリシー化します。権限テストでは、管理者、一般利用者、退職済みユーザー、別組織の利用者、期限切れトークンなどを用意し、許可されない操作が必ず403または404になることを自動テストで確認します。
流量制御なしのAI API公開
生成AI APIでは、リクエスト回数だけでなく、入力・出力トークン数が料金と応答時間に影響します。レートリミットがない状態でAIエージェントやバッチ処理を接続すると、ループ処理や再試行により利用量が急増することがあります。
利用部門ごとに1分あたりのリクエスト数、1分あたりのトークン数、日次予算、最大出力トークンを設定します。利用量の監視値がしきい値を超えた場合、通知だけで継続するのではなく、低優先度の処理を待機させる、より低コストなモデルへルーティングする、管理者承認を必要にする、といった動作を決めます。
実務用の棚卸しチェックリスト
公開APIを棚卸しする際は、次の項目を1つの台帳へまとめます。月次で更新できる担当者がいない場合は、CI/CDのデプロイ時に台帳更新を必須化し、手作業だけに依存しない運用へ切り替えます。
API名、Base URL、パス、HTTPメソッド、環境、本番公開日
業務オーナー、技術オーナー、障害時の連絡先
利用システム、認証方式、認可ルール、扱うデータの分類
OpenAPI仕様書の保管先、最新バージョン、非推奨化予定日
レートリミット、ログ保存期間、アラート条件、バックアップの有無
最終アクセス日時、脆弱性診断日、廃止判断日
この台帳で最終アクセス日時と所有部門が確認できるAPIは、更新・継続・廃止の判断へ進めます。どちらも確認できないAPIは、外部公開範囲を先に限定し、利用実態とデータ影響を調査してから復旧または停止を決めます。
API管理の失敗を防ぐと同時に、社内の各種デバイスや資産情報をまとめて管理したい方は、法人向けIT資産と社用デバイスの一元管理方法を参考にしてください。
生成AI時代のAI GatewayとMCP
生成AIをAPIで利用する場合は、モデルへの接続先だけでなく、トークン、プロンプト、ツール実行権限を統制します。
AI Gatewayの役割
AI Gatewayは、アプリケーションとLLM APIの間に配置し、認証、モデルの振り分け、利用量制限、キャッシュ、ログ、障害時の切り替えを管理する中継層です。通常のAPI Gatewayと役割が重なる部分もありますが、AI Gatewayではトークン数、モデル名、プロンプト、応答品質、コンテンツフィルタなどAI特有の情報を扱います。
CloudflareはAI Gatewayの公式ドキュメント（Cloudflare Developers）で、複数のAIプロバイダーへのリクエストを単一エンドポイントから制御し、分析、キャッシュ、レートリミットを利用できると案内しています。対応プロバイダー、設定項目、プランごとの制限は同ドキュメントの「Configuration」および「Providers」セクションで確認できます。Azure API ManagementやApigee、KongなどでもAI API向けの制御機能が拡張されており、実装範囲は各製品の現行ドキュメントで異なります。
社内チャット、問い合わせ要約、コード生成など複数用途でLLMを使う場合、アプリケーションごとにAPIキーを直接配る構成は管理負荷が高くなります。AI Gatewayを経由し、利用者・部署・用途ごとの識別子をログに残すと、費用配賦、異常検知、アクセス停止を実施しやすくなります。
MCPによるツール接続
Model Context Protocol（MCP）は、AIアプリケーションが外部のデータソースやツールと接続するためのオープンプロトコルです。MCPの公式サイト（modelcontextprotocol.io）は、AIアプリケーションと外部システムを接続するための標準として仕様とSDKを公開しています。現行仕様のバージョン、クライアント・サーバー実装のサンプル、対応言語は同サイトの「Specification」および「SDKs」セクションで確認できます。
MCPを導入したからといって、AIエージェントへ業務システムの全権限を渡してよいわけではありません。たとえば「従業員情報を検索する」ツールと「給与情報を更新する」ツールは、別の権限・承認・監査レベルで扱います。読み取り専用ツールから限定公開し、操作系ツールでは人による承認や金額上限を設定すると、誤操作の影響を限定できます。
AIエージェント向けのエンドポイント統制
AIエージェントがAPIを呼び出す構成では、通常のユーザー操作よりも連続実行・再試行・意図しない引数生成が起きやすくなります。そのため、ツールごとに許可する操作を絞り、引数のスキーマ検証、許可リスト、実行回数上限、監査ログを設定します。プロンプトへ機密情報を含める場合は、ログ保存先と閲覧権限も確認対象にします。
まずは本番更新権限を持たない検索系APIを対象に限定検証します。呼び出し履歴、利用者識別子、入力値のマスキング、レートリミット超過時の挙動を取得できれば、次に承認付きの更新系処理へ範囲を広げられます。これらが取得できない状態では、AIエージェントへ更新系エンドポイントを接続せず、読み取り専用の利用に留めます。
▲ 社内アプリケーションと外部LLMの中間に配置するAI Gatewayの統制構成
よくある質問
APIエンドポイントの基本用語と運用上の疑問に、実務で判断しやすい形で回答します。
Q：APIエンドポイントとURLは同じですか？
A：完全に同じ意味ではありません。URLは接続先の場所を表し、APIエンドポイントはそのURLで提供されるデータ取得・登録・更新などの通信窓口を指します。実務ではURLとHTTPメソッドをセットでエンドポイントとして管理すると、操作範囲を把握しやすくなります。
Q：APIエンドポイントとWebhookの違いは何ですか？
A：一般的なREST API呼び出しでは、クライアントが必要なタイミングでリクエストを送ります。Webhookは、イベント発生時にサービス側から登録済みURLへ通知を送る、イベント発生元主導の仕組みです。なおWebhookの受信先もHTTPエンドポイントであり、APIにはイベント駆動やコールバックの設計もあります。即時通知が必要ならWebhook、任意の条件でデータを取得するなら通常のAPIリクエストを使います。
Q：レートリミットはどの程度に設定しますか？
A：利用者数、通常時のピーク、バックエンドの処理能力、外部APIの契約上限から決めます。最初は実測した通常ピークの2〜3倍を上限の目安にしますが、この値は負荷試験で確認したバックエンドの限界値、設定したSLO（応答時間・可用性の目標値）、および呼び出し先の外部APIやデータベースが持つ上限（下流依存先の制約）に照らして調整します。たとえば下流の外部APIが分あたり100リクエストまでの契約であれば、自側の上限もそれ以下に設定します。429の発生数と応答時間を継続的に監視し、しきい値を段階的に見直します。生成AI APIではリクエスト数に加え、トークン数の上限も設定します。
Q：シャドウAPIを見つけるにはどうすればよいですか？
A：DNS・証明書・クラウド設定・API Gatewayログ・WAFログ・ソースコード管理の情報を突合します。外部公開されていて所有者や仕様書が不明なAPIを見つけた場合は、扱うデータと利用実態を調査し、利用が確認できなければ公開停止またはアクセス制限へ進めます。
まとめ
安全なAPIエンドポイントを構築するには、URLやHTTPメソッドを設計するだけでは足りません。認証・認可、OpenAPIによる仕様管理、バージョニング、レートリミット、アクセスログ、廃止手順を一体で運用します。特にBOLAのような認可不備は、正規利用者のリクエストとして見えるため、API GatewayやWAFだけに任せず、業務データ単位で権限を判定します。
明日から着手するなら、まず外部公開・社内公開を問わず、自社のAPIエンドポイントを一覧化します。各APIに所有部門、認証方式、扱うデータ、最終アクセス日時、仕様書、廃止予定日を紐付けてください。そのうえで、所有者不明のAPIと認可ルールが未記載のAPIを優先して調査すると、シャドウAPIやゾンビAPIを減らしながら、AI APIを含む今後の連携基盤を安全に拡張できます。
✅ 外部公開・社内公開を問わず、自社のAPIエンドポイントを一覧化する
✅ 各APIに所有部門・認証方式・扱うデータ・最終アクセス日時・廃止予定日を台帳へ記録する
✅ 所有者不明のAPIと認可ルール未記載のAPIを優先して調査する
✅ シャドウAPI・ゾンビAPIを特定し、利用実態に応じてアクセス制限または停止を判断する
✅ AI APIを接続する場合はトークン数・日次予算の上限を設定してから本番利用へ進む
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
