2026.07.25 インフラ

Cloud Endpointsとは？GCPのAPI管理の仕組み・ESPv2・料金とAPI Gateway/Apigeeとの違いを実装者目線で解説

Cloud Endpointsは、自分で作ったAPIの前段にプロキシを1つ置くだけで、認証・アクセス制御・監視・ログ収集をまとめて足せるGoogle CloudのAPI管理サービスです。この記事では、OpenAPI版とgRPC版という2つの形態、リクエストを最初に受けるExtensible Service Proxy（ESP／後継のESPv2）の役割、設定を司るService Managementと実行時に効くService Control、APIキーとJWTによる認証、そしてリクエスト数に応じた料金までを一次情報で整理します。同じGCPのAPI管理であるApigeeやAPI Gatewayとの違い、Cloud Endpointsを採用すべき条件と見送るべき場面の判断基準まで、実装者がAPI基盤の設計で迷う論点を具体的に示します。

まとめ：Cloud Endpointsの仕組みと採用判断の要点

Cloud Endpointsは、GKEやCompute Engineなどで動かす自作APIの手前にESP（Extensible Service Proxy）というプロキシを配置し、そこで認証・APIキー検証・ログ収集を肩代わりさせる仕組みです。API側のコードに認証処理を書き込まずに済むため、バックエンドの実装をビジネスロジックに集中させられます。定義はOpenAPI仕様（旧Swagger）またはgRPCで書き、その定義からService Managementが管理ルールを組み立て、実行時にはService Controlが1リクエストごとに検証とログ記録を担う役割です。後継のESPv2はEnvoyをベースにした高性能プロキシで、OpenAPIとgRPCの両方をさばきます。

料金は呼び出し数に対する従量課金で、月200万呼び出しまでは無料、そこから100万呼び出しあたり数ドルという積み上がり方です。近い立ち位置には、別ライセンスで買うエンタープライズ向けのApigeeと、ESPの運用すら要らないフルマネージドのAPI Gatewayがあります。ESPを自分で持って運用の主導権を握りたいならCloud Endpoints、サーバーレス構成でゲートウェイの運用まで任せたいならAPI Gateway、大規模なAPI事業ならApigeeという棲み分けです。迷う実装者は、本記事後半の採用条件と見送り条件を自社のAPIの規模と運用体制に当てはめて選定してください。

Cloud Endpointsの仕組みとAPI管理という位置づけの整理

Cloud Endpointsを設計へ落とし込むには、まず「自作APIの前に置く管理レイヤー」という立ち位置を押さえます。ここが曖昧だと、API GatewayやApigeeとの役割の境目を見誤り、過剰な作り込みや二重の運用を抱え込みかねません。API管理という枠組みそのものを整理したい場合は、API管理とは何か・仕組みと構成要素を実装者向けに解説した記事が上位の入り口になります。

ESP（Extensible Service Proxy）が担うリクエストの前段処理

Cloud Endpointsの中核は、APIの前段に置くESPというプロキシです。クライアントからのリクエストは、まずESPが受け取り、APIキーやJWT（JSON Web Token）を検証してから、後ろのバックエンドへ転送します。この構造により、認証やキー検証のコードをAPI本体に書き込む必要がなくなり、バックエンドは処理結果を返すことに専念できる形です。ESPはNGINXをベースにしたプロキシとして始まり、後継のESPv2はEnvoyをベースにした高性能・スケーラブルなプロキシで、OpenAPI仕様v2とgRPCの両方に対応します。APIの手前に立って交通整理をするという役割は、APIゲートウェイの考え方そのものです。ゲートウェイの一般的な機能や位置づけを先に固めたい場合は、APIゲートウェイとは何か・役割と機能を解説した記事を押さえておくと、ESPが何を代替しているのかが掴みやすくなります。

Cloud EndpointsのOpenAPI版とgRPC版の違いと選び分け

Cloud Endpointsには、API定義の書き方が異なる2つの形態があります。1つはCloud Endpoints for OpenAPIで、OpenAPI仕様v2（旧Swagger）でAPIを記述する、RESTなHTTP APIに向いた形態です。もう1つはCloud Endpoints for gRPCで、gRPCで定義したサービスに管理機能を足す形態です。どちらもESPv2が処理を受け持ちますが、定義の記法と向くユースケースが分かれます。外部公開するRESTのWeb APIならOpenAPI版、サービス間通信を高効率なバイナリでやり取りするならgRPC版、というのが素直な選び分けです。まず自分のAPIがHTTP/RESTかgRPCかを見極めてから形態を選びます。

Service ManagementとService Controlの役割分担

Cloud Endpointsの管理機能は、役割の異なる2つのコンポーネントで動きます。Service Managementは、OpenAPI仕様から管理ルールを組み立て、APIの有効化・無効化やAPIキーの生成といった設定側を司ります。もう一方のService Controlは実行時に効くコンポーネントで、Checkメソッドで認証やAPIキーを検証し、Reportメソッドでロギングと監視のデータを記録する役割です。ESP/ESPv2はリクエストのたびにこのService Controlへ問い合わせ、通してよいかを確かめてからバックエンドへ渡します。設定はService Management、1リクエストごとの判定と記録はService Control、という分担を掴んでおくと、料金や監視の仕組みも理解しやすくなります。

Cloud Endpointsの認証・監視と料金モデルの設計前提

次に押さえるのが、ESPが肩代わりする認証の方式と、呼び出し数に連動する料金の積み上がり方です。ここの理解が、セキュリティと運用コストの両面を左右します。

APIキーとJWTというCloud Endpointsの認証方式

Cloud Endpointsの認証は、大きく2系統に分かれます。APIキーは、呼び出し元のGoogle Cloudプロジェクトを識別する文字列で、クォータ管理・課金・監視のために使います。誰が使っているかをプロジェクト単位で把握し、利用量に上限をかけたい場面で効く仕組みです。もう1つのJWT検証は、利用者本人を認証する仕組みで、クライアントが認可ヘッダーに載せたトークンをESPが検証します。Google IDトークン、Firebase、Auth0、サービスアカウント間の認証など複数の発行元に対応し、いずれもESPがAPI側でコードを書かずに検証を済ませます。呼び出し元アプリの識別はAPIキー、エンドユーザーの本人確認はJWT、と役割を分けて併用するのが基本です。認証まわりで守るべき観点を体系立てて確認したい場合は、APIセキュリティとは何か・主要リスクと実装対策を解説した記事を合わせて参照してください。

Service Controlによる監視・ロギングとリクエストの流れ

Cloud Endpointsは、通したリクエストのログとメトリクスをService ControlのReportメソッド経由で記録し、Google Cloudの監視基盤へ集約します。呼び出し回数・レイテンシ・エラー率といったAPIの稼働状況を、追加のコードを書かずに可視化できる点が持ち味です。リクエストの流れを整理すると、クライアントの要求をESP/ESPv2が受けてパスを照合し、APIキーやJWTを検証し、Service Controlのチェックを経てバックエンドへ転送、結果をクライアントへ返す、という一連になります。この経路上でチェックと記録がまとめて行われるため、APIの利用状況の把握とアクセス制御を1か所に寄せられます。

Cloud Endpointsの呼び出し数に応じた従量課金の料金モデル

Cloud Endpointsの料金は、APIの呼び出し数に対する従量課金です。2026年7月時点の公開情報では、月0〜200万呼び出しまでが無料、200万〜10億が100万呼び出しあたり3.00米ドル、10億を超える分が100万呼び出しあたり1.50米ドルという段階になっており、請求書には「Service Control」の行項目として表示されます。ESPそのものは、GKEやCompute Engineなど動かす場所のリソース費用がかかりますが、Endpointsの管理機能としての課金は呼び出し数が基準です。小〜中規模のAPIなら無料枠に収まりやすく、規模が伸びるほど段階単価が下がる構造なので、想定する月間呼び出し数を置いて概算し、数値は公式の料金ページで対象時点を実測して確定させてください。

Cloud EndpointsとApigee・API Gatewayの違いと使い分け

基盤選定の決め手になるのが、同じGCPのAPI管理群であるApigeeとAPI Gatewayとの役割の差です。ここを条件で切り分けます。

Cloud EndpointsとApigeeの違いは機能と価格体系の重さ

Apigeeは、API事業の運営に必要な機能を幅広く備えたエンタープライズ向けのAPI管理プラットフォームです。開発者ポータル、細かなトラフィック制御、収益化、高度な分析までを含み、価格もGCPの従量課金とは別のApigeeライセンスを購入する体系になっています。大規模なシステム連携や、API自体を商品として外部提供するような用途に向く製品です。対してCloud Endpointsは、アプリの隣にESPを置いて認証・監視・アクセス制御という基本機能を軽量に足す、従量課金のサービスです。API管理に厚い作り込みと専任運用を投じられるならApigee、まず必要十分な管理機能を安く足したいならCloud Endpoints、という規模での分岐になります。

API Gatewayとの違いはESPを自分で運用するかどうか

API Gatewayは、Cloud Endpointsと同じOpenAPI定義形式に対応する後発のフルマネージド・サーバーレスゲートウェイです。Endpointsで書いたOpenAPI specの多くをそのまま持ち込め、同様の認証・クォータ設定を使えます。両者の分かれ目は、ゲートウェイの実体を誰が運用するかです。Cloud EndpointsはESP/ESPv2をバックエンドの隣に自分でデプロイして運用し、プロキシの配置やスケールを自分の手で握ります。API Gatewayはそのプロキシ層をGoogleが管理し、Cloud RunやCloud Run functions、App Engineといったサーバーレスなバックエンドの前に、運用の手間をかけずゲートウェイを置ける形です。バックエンドとしてサーバーレスを使い運用を任せたいならAPI Gateway、GKEやCompute Engineで自分のプロキシを細かく制御したいならCloud Endpoints、という軸で選びます。

製品 ゲートウェイの運用 向く用途
Cloud Endpoints ESP/ESPv2を自分でデプロイ GKE/Compute EngineのAPI
API Gateway フルマネージド（Google管理） サーバーレス構成のAPI
Apigee エンタープライズ基盤（別ライセンス） 大規模・収益化するAPI事業

Cloud EndpointsのESPを載せるバックエンドの選び方

Cloud EndpointsのESPは、App Engine（Flexible/Standard）・Compute Engine・GKE・Kubernetes・Cloud Run・Cloud Run functions・Knative servingといった実行環境に載せられます。どこにESPを置くかは、APIバックエンド本体をどのサービスで動かすかに合わせて決めるのが素直です。コンテナ化したAPIをクラスタで運用しているなら、GKE（Google Kubernetes Engine）とは何かを実装者目線で解説した記事で前提を固めた上で、そのクラスタにESPをサイドカーとして同居させる構成が取れます。一方、コンテナをサーバーレスで手早く動かしているなら、Cloud Runとは何か・GCPのサーバーレスコンテナを解説した記事のような実行基盤の前段にゲートウェイを据える構成です。バックエンドの運用形態が決まれば、Cloud EndpointsとAPI Gatewayのどちらが噛み合うかも自然に絞れます。

Cloud Endpointsを採用すべき条件と見送るべき場面の判断基準

ここでは判断を言い切ります。Cloud Endpointsは自作APIへ管理機能を軽量に足すことに強い反面、あらゆるAPI基盤の受け皿ではありません。自社のAPIをどの管理方式に載せるかを、条件付きで見極めてください。

Cloud Endpointsの採用が効くAPIと要件の条件の見極め

採用が効くのは、GKEやCompute Engineで自作APIを動かしており、認証・APIキー管理・監視を、API本体のコードを増やさずにまとめて足したい、という条件が重なるときです。具体例は、社内外へ公開するREST APIやgRPCのサービス間通信、プロキシの配置やスケールを自分で握りたいAPI、既存のOpenAPI定義をそのまま管理レイヤーに載せたい移行案件が当てはまります。特に、呼び出し量に応じた従量課金で小さく始めたい、ESPをバックエンドの近くに置いてネットワーク経路や設定を細かく制御したい、という要件で効きます。こうしたGoogle Cloud上のAPI基盤を自社に取り入れるなら、API開発・システム連携の相談窓口で、OpenAPI/gRPCの選択、ESPを載せるバックエンド、認証方式や監視設計の妥当性を相談するとよいでしょう。

Cloud Endpointsが向かない要件とAPI Gatewayへ寄せる場面

ESPの運用そのものを持ちたくない、Cloud RunやCloud Run functionsなどサーバーレスなバックエンドの前に手間をかけずゲートウェイを置きたい、という要件では、Cloud Endpointsは窮屈になります。この場合はフルマネージドのAPI Gatewayへ寄せるのが素直でしょう。逆に、開発者ポータルや収益化、きめ細かなトラフィック制御といったエンタープライズ機能を要し、API自体を事業として広く外部提供するなら、Apigeeが噛み合います。呼び出し量がごく小さく、そもそも管理レイヤーを挟むほどでもない内部APIも、Cloud Endpointsの前提と合わないことがあるため、運用体制（プロキシを持てるか）とAPIの規模・公開範囲を軸に選定してください。

Cloud EndpointsのOpenAPI定義からデプロイまでの流れ

実装面では、APIの仕様をOpenAPI（またはgRPC）で記述し、その定義をService Managementへデプロイして管理設定を作り、続いてバックエンドの隣にESP/ESPv2をデプロイして仕様と紐づける、という流れが基本です。定義に認証要件やAPIキーの扱いを書き込んでおけば、ESPがその通りにリクエストを検証します。API GatewayへOpenAPI specを流用する余地も残るため、まずCloud Endpointsで管理を始め、運用の重さを見てAPI Gatewayへ寄せる、という段階的な進め方も取れるでしょう。定義の設計とバックエンド実装、認証設計を分けて進めると、後からの構成変更に耐えやすくなります。

よくある質問

Cloud Endpointsの導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。

Cloud EndpointsとAPI Gatewayはどう使い分ければよいですか？

ゲートウェイの実体を自分で運用するかどうかが分かれ目です。Cloud EndpointsはESP/ESPv2をバックエンドの隣に自分でデプロイして制御し、GKEやCompute Engineで動かすAPIに向きます。API Gatewayはそのプロキシ層をGoogleが管理するフルマネージドで、Cloud RunやCloud Run functionsなどサーバーレスなバックエンドの前に手間なく置ける形です。運用の主導権を握るか任せるかで選びます。

ESPとESPv2は何が違うのですか？

ESP（Extensible Service Proxy）はNGINXをベースにしたプロキシで、ESPv2はEnvoyをベースにした後継の高性能・スケーラブルなプロキシです。ESPv2はOpenAPI仕様v2とgRPCの両方に対応します。新規に構成するならEnvoyベースのESPv2が基準の選択肢になり、対応範囲や設定は公式ドキュメントで対象時点を確認してください。

Cloud Endpointsの認証にはどんな方式がありますか？

呼び出し元プロジェクトを識別するAPIキーと、利用者本人を認証するJWT検証の2系統です。JWTはGoogle IDトークン、Firebase、Auth0、サービスアカウント間認証など複数の発行元に対応し、ESPがAPI側にコードを書かずに検証します。アプリの識別はAPIキー、エンドユーザーの本人確認はJWT、と役割で分けて併用するのが基本です。

Cloud Endpointsの料金はどのように決まりますか？

APIの呼び出し数に応じた従量課金で、Service Control APIが呼び出しを追跡します。2026年7月時点では月200万呼び出しまで無料、200万〜10億が100万あたり3.00米ドル、10億超が1.50米ドルという段階です。ESPを載せるGKEやCompute Engineのリソース費は別途かかります。具体的な単価は公式の料金ページで対象時点を確認してください。

Cloud EndpointsはgRPCでも使えますか？

使えます。Cloud Endpoints for gRPCという形態があり、gRPCで定義したサービスにESPv2を前段として置き、認証・監視・アクセス制御を足せます。RESTのHTTP APIならOpenAPI版、サービス間をバイナリで高効率にやり取りするならgRPC版、という選び分けです。まず自分のAPIがHTTP/RESTかgRPCかを見極めて形態を選びます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る