Apigee

Google Cloud Apigee、Gartner® Magic Quadrant™ API 管理部門で 10 年連続リーダーに選出

Thu, 23 Oct 2025 01:40:00 +0000

※この投稿は米国時間 2025 年 10 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

Google は 2025 年 Gartner® Magic Quadrant™ の API 管理部門でリーダーに選出され、「実行能力」について最も高い評価を得ました。これで 10 年連続の選出となります。

Google は、評価対象となった全ベンダーの中で、実行能力について最も高い評価を得ています。これは、従来の API ユースケースをサポートすることに加え、お客様がこれまでと同じ使い慣れたプラットフォームとネイティブコントロールを使用して AI とエージェント AI 管理を行えるよう橋渡しすることに対する Google のコミットメントを反映したものと確信しています。

API 管理を生成 AI とエージェント AI に拡張

AI とエージェントワークロードの台頭は、API からなる「神経系」によって支えられています。AI ツールは大きな可能性を生み出しますが、組織が試験運用から本番環境に移行する際に障害に直面することは珍しくありません。問題は、これらソリューションの管理、保護、スケーリングです。特に、規制の厳しい環境で LLM とそれを利用するエージェントを使用する場合は、この問題が顕著になります。

これに対処するのが Google Cloud のネイティブ API 管理プラットフォームである Apigee です。実績豊富な各機能の対象を AI イニシアチブへ拡げ、現実的かつ測定可能なビジネス価値の実現を支援します。

Apigee は、すべての AI エージェント、ツール、バックエンドモデルのインテリジェントで安全なプロキシとして機能し、セキュリティ、スケーラビリティ、ガバナンスを強化します。この重要なゲートウェイとして機能することで、エージェントワークロードをリスクから保護し、管理されたデータでの運用を確保するとともに、費用を管理できるようにします。

エージェント AI の管理、ガバナンス、セキュリティ保護

Apigee のさまざまな機能が、AI イニシアチブの本番運用を目指す、企業の API および AI プラットフォームチームを支援します。こうした機能としては、次のようなものが挙げられます。

AI プロダクト化

API プロダクトは Apigee プラットフォームの中心であり、プラットフォームチームが個別の API オペレーションをプロダクトとしてバンドルし、アクセスと割り当てを管理して、利用に供するという一連の作業を可能にします。今日の Apigee は AI プロダクト化への取り組みを支援しています。具体的には、サードパーティインテグレーション（Application Integration による）、MCP サーバーなどのエージェントツール、そしてもちろん API を含むツールをバンドルしており、これによって開発者による再利用、きめ細かいアクセス制御、収益化が容易となり、組織の新たな収益源開拓につながります。

エージェント対応ツール

Google DeepMind が構築したマルチエージェントツールをベースとする Apigee の新しい API 仕様強化機能（現在、限定公開プレビュー中）は、既存の API 仕様を自動的に強化し、エージェントによる検出を容易にします。これは仕様に包括的なサンプル、エラーシナリオ、組織の API パターンから導き出されたビジネスロジックを含めることで実現されます。

AI の費用管理

お客様は、Apigee のネイティブな割り当てポリシーを使用して、API または AI プロダクトレベルでトークン制限を適用します。Looker Studio（無料の Google Cloud サービス）とのインテグレーションにより、API プラットフォームチームが AI トークンの使用状況に関するカスタムレポートを作成し、外部の関係者と共有することが可能になります。

一元化されたツールカタログとオブザーバビリティ

Apigee API Hub は、API、MCP サーバー、サードパーティインテグレーションに関する情報を保存する、一元化されたカタログとして機能し、Gemini を活用した組み込みのセマンティック検索機能がツールの発見と再利用を支援します。Agent Development Kit（ADK）用の Apigee API Hub ツールセットにより、ADK を使用してカスタムエージェントを構築するデベロッパーは、わずか 1 行のコードで Apigee API Hub 内のツールへのアクセスをエージェントに付与できます。API のトラフィックとパフォーマンスに関するデータはカタログに統合され、人間とエージェントがアクセスできるように。さらに、これらのセマンティック機能は、セマンティックなツール識別という新たなユースケースを推進します。

ツールのセキュリティとコンプライアンス

Apigee で用意されている 60 以上のポリシーには、ツールを保護して安全に保つためのセキュリティポリシーが含まれています。これには、Model Armor を使用した AI 安全性強化に関するネイティブポリシーも含まれます。さらに、Apigee Advanced API Security は Apigee のランタイムとネイティブにインテグレーションされており、Google が設計した ML モデルを活用した動的な API セキュリティポスチャー管理や不正行為検出などの高度なセキュリティ機能を実現しています。最後に、Apigee の強化されたデータ所在地機能は、世界各地におけるワークロードのコンプライアンス遵守を支援します。

マルチクラウドのモデルルーティング

Apigee は、エージェントとバックエンドの LLM モデル間のプロキシとして機能し、エージェントとツールの間をつないで、Google Cloud 内外でホストされているバックエンド LLM モデルへのルーティングを行います。Apigee のサーキットブレーキング機能は、AI アプリケーションとエージェントアプリケーションの高可用性を維持するのに役立ちます。

グローバルリーダーから信頼される Apigee

グローバルリーダーは、ミッションクリティカルな API の大規模な管理に Apigee を信頼して利用しています。そしてそれは規制の厳しい業界でも変わりありません。Google は、お客様の進化するニーズに応える世界水準の信頼できるサービスとしての Apigee を維持するため、継続的に投資していくことをお約束します。 Gartner からのこの評価は、継続的なイノベーションと卓越したデベロッパーエクスペリエンスの提供に対する Google の取り組みを裏付けるものだと考えています。

お客様とパートナー様に感謝

Apigee を継続的にサポートし、信頼してくださっているお客様、デベロッパー、パートナーの皆様に心より感謝申し上げます。皆様からの貴重なフィードバックとご協力を活かし、プロダクトロードマップの推進と、信頼できる API 管理エクスペリエンスのご提供に邁進いたします。

レポート全文をダウンロードして詳細をご確認ください。

ー Apigee、アウトバウンドプロダクトマネージャー Geir Sjurseth

ー Apigee、アウトバウンドプロダクトマネージャー Megan Bruce

gRPC から RESTful API へ: gRPC サービスを Rest of the World に公開する

Fri, 23 Aug 2024 01:00:00 +0000

※この投稿は米国時間 2024 年 8 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

最新のマイクロサービスアーキテクチャを設計するにあたっては、パフォーマンスが鍵となることは明らかです。高頻度取引や準リアルタイムシステム以外でも、サービス間通信に数ミリ秒ほどの余分なラグが生じるだけで、全体的なユーザーエクスペリエンスに大きく影響します。こうした環境では高性能通信プロトコルとして gRPC が登場し、低レイテンシ、高効率のシリアル化、厳密に型指定されたメッセージのために広く採用されています。

一方で、システム境界を越えたサービス間通信のほとんどが、依然として HTTP API に大きく依存していることを認識する必要があります。これは、API が主に API 作成者と API 利用者という形で分離されたエンティティ間の契約として機能しており、これを gRPC に変更すると多くの摩擦が生じるためです。さらに、すべてのデベロッパーが gRPC サービスを利用できるほど十分な装備や経験を備えているわけではありません。そのため、API プロバイダは、gRPC サービスのみを提供する方向に自らを制限してしまうと、潜在的なユーザー層を逃してしまう可能性があります。

このブログ投稿では、高性能な gRPC サービスと、広く採用されている RESTful HTTP API のエコシステムとの間のギャップを簡単に埋める方法についてご紹介します。既存の gRPC サービスと一緒にデプロイできる自動生成 gRPC ゲートウェイを活用してプロトコル変換を処理し、HTTP インターフェースを提供するソリューションをご提案します。さらに、クリーンな RESTful API ファサードを安全なセルフサービス方式で提供するためのエンタープライズ API 管理プラットフォームとして Apigee をご紹介します。

gRPC から HTTP へのゲートウェイ

架空の e コマースサイトを運営する会社が、その運営の過程で、コンポーネントの一部が独自の価値を提供していることに気づいたとします。その会社は、自社の戦略的な API エコノミーの取り組みにそれらを組み込むことができると考えています。この例は、さまざまなプログラミング言語で記述されたさまざまなサブコンポーネントで構成されているサンプルのマイクロサービスアーキテクチャに基づいています。API プラットフォームへのオンボーディングを検討したい最初のサービスは、通貨サービスです。このサービスには、サポート対象の通貨を一覧表示し、ある通貨から別の通貨への両替を実行できる 2 つの gRPC メソッドが用意されています。

冒頭で述べたように、gRPC サービスは、内部サービス間通信、いわゆる「East-West」サービス間通信によく使用されます。gRPC は優れたパフォーマンス特性を備えていますが、現状、多数の API が HTTP を主要な通信プロトコルとして使用しています。こうした API を gRPC に移行するには、特にすべてのデベロッパーが gRPC フレームワークに精通しているわけではないことを考慮すると、多大なリソースの投資が必要になります。

この課題を克服するために、従来の JSON HTTP ベースの API をサービスに提供するアダプタレイヤを提供したいと私たちは考えています。プロトコル変換を自ら手動で記述する代わりに、オープンソースの gRPC ゲートウェイプロジェクトを使用して、ユースケース向けのアダプタを自動で生成することにしました。ゲートウェイは、.proto ファイルに基づいてサービスとメッセージを指定しています。これは、サービスプロデューサーと利用者との間に位置する唯一の信頼できる情報源、つまり契約として機能します。ゲートウェイの生成を簡素化するために、便利なラッパーを作成しました。このラッパーに .proto ファイルを直接指定するだけでゲートウェイを生成できます。

code_block: <ListValue: [StructValue([('code', './generate-gateway.sh --proto-path ./examples/currency.proto'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e2fddf0>)])]>

上記のコマンドは、提供された .proto ファイルを解析し、受信した HTTP REST リクエストを gRPC に変換して、指定されたエンドポイントに送信するための go モジュールを生成するものです。最後に、ゲートウェイを go モジュールでラップし、独立してデプロイできるようにします。

最終的なアーキテクチャでは、コンテナイメージを構築し、Cloud Run などのターゲットランタイムにデプロイします。ゲートウェイがどのように動作するかを確認するために、ゲートウェイをローカルで実行することもできます。

code_block: <ListValue: [StructValue([('code', '(cd generated/gateway && docker build . -t gateway:latest)\r\ndocker run -p 8080:8080 -e GRPC_SERVER_ENDPOINT=localhost:9090 gateway:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e2fdaf0>)])]>

ここで設定された GRPC_SERVER_ENDPOINT 環境変数は、ゲートウェイがトラフィックを送信する先の gRPC エンドポイントを指しています。この場合、gRPC 通貨サービスはすでにポート 9090 でローカルに実行されています。ゲートウェイが起動したら、通常の JSON HTTP リクエストをゲートウェイのエンドポイントに送信できます。

code_block: <ListValue: [StructValue([('code', 'curl -X POST localhost:8080/hipstershop.CurrencyService/Convert -d \'{"from": {"units": 3, "currency_code": "USD", "nanos": 0}, "to_code": "CHF"}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e2fdcd0>)])]>

ご覧のとおり、gRPC 通貨サービスが、より広範な API エコシステムで簡単に使用できる JSON HTTP API として提供されるようになっています。ただし、この新しい API がこの会社の確立された API 戦略とどのように整合しているかを考えると、まだ改善の余地があります。

この API は、広く利用されている RESTful API 設計原則には従っておらず、依然として元の .proto 仕様の構造を多分に反映しています。
この API は、認証、一元的なロギングとモニタリング、エラー処理、収益化などの API 管理機能をサポートしていません。
開発者は、新しい API を見つけ、自分自身を API 利用者としてオンボードできるセルフサービスオプションにアクセスできません。

API 管理で参入障壁を下げる

API 管理レイヤを Apigee API Proxy ファサードの形で活用することで、上記の機能の一部を実現し、ひいては API の採用を促進できます。Apigee は gRPC サービスをパススルーモードでネイティブに公開できますが、ここでは以前に変換されたプロトコルで操作し、次のようなさまざまな便利なポリシーと構成を適用できます。

適切な RESTful ファサードを提供でき、gRPC の基盤となるメッセージ形式を抽象化できるメソッド、パス、ペイロードの変換
API プログラムの運用パフォーマンスと成功を測定するための指標と、豊富な分析データの収集
他のシステムを保護し、クライアントにクォータを課すための一貫した API セキュリティ、エラー処理、トラフィック管理制御

gRPC ゲートウェイ上に構築するには、まず API プロキシが gRPC ゲートウェイに安全にアクセスできるようにする必要があります。この API プロキシは、Cloud IAM を使用して認証を適用可能な Cloud Run にデプロイできます。このセキュリティメカニズムでは、API プロキシは Google Cloud 認証自体を使用するか、API クライアントから受信した認証情報を転送するように構成する必要があります。

API プロキシを使用してルートを管理する Apigee の柔軟で包括的なアプローチにより、RESTful パスを API 利用者に公開し、実行時に gRPC ゲートウェイが期待するパスに書き換えることができます。

code_block: <ListValue: [StructValue([('code', 'curl -X POST "https://$APIGEE_HOSTNAME/currency/v1/convert" -d \'{"from": {"units": 3, "currency_code": "USD", "nanos": 0}, "to_code": "CHF"}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e2fd400>)])]>

Apigee API プロキシを介して通貨サービスをプロキシすると、API 指標と分析データが自動的に収集され、API の健全性と成功に関する豊富な分析情報が得られます。また、追加のトラフィック管理、セキュリティ、メディエーション、さらにはコード拡張ポリシーを適用して、API プロキシを構築することもできます。

この API を新しいユーザーに紹介して宣伝するためにご活用いただけるのが、Apigee のデベロッパーポータルです。API プロダクトを公開し、デベロッパーが API を発見、探索、テストできるようにすることで、新たな機会が生まれます。これをさらに進めるには、必要に応じて API プロダクトを収益化し、使用量ベースの価格設定やサブスクリプションプランなどのさまざまな戦略で追加の収益源を得られるようにします。

まとめと次のステップ

ここでは、gRPC サービスを HTTP API として簡単に新しいユーザーに公開し、Apigee のような包括的な API 管理プラットフォームの利点も活用する方法を示しました。gRPC のパフォーマンスと REST API の使い慣れたツールを組み合わせることで、サービスとデータの新しい可能性が解き放たれ、より幅広いデベロッパーとアプリケーションにリーチできます。このハイブリッドアプローチを採用することで、API エコシステムを構築するときに gRPC と REST のギャップを埋めることができ、両方の長所を活用できます。

関心のある方は、Apigee DevRel サンプルの手順を実行して、これをテストすることができます。

-アプリケーション モダナイゼーション担当 EMEA ソリューション リード Daniel Strebel

-Apigee、EMEA テクニカル ソリューション コンサルタント Omid Tahouri

Google Cloud（Apigee）、2023 年 Gartner® Magic Quadrant™ で API 管理のリーダーに選出

Wed, 25 Oct 2023 03:00:00 +0000

※この投稿は米国時間 2023 年 10 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud（Apigee）は、2023 年 Gartner® Magic Quadrant™ で API 管理のリーダーとして認定されました。これで 8 年連続となります。これは、さまざまなユースケースをサポートできる Google の能力と、API 管理においてあらゆる規模の組織向けに提供している包括的な機能が引き続き認められた結果によるものと考えています。Google Cloud（Apigee）は、本年のレポートでもその実行能力とビジョンの完全性を高く評価されました。

API の導入はここ数年で急増し、数々の組織で API が拡散している状態となっています。既存のアプリケーションアーキテクチャに生成 AI や ML の機能が導入されているなか、これらのモデルの安全なデータアクセスを確保する API のニーズが高まっています。それと並行してデベロッパーの負担も増大しており、セキュリティ対策を強化するだけでなく、セキュリティ要件やコンプライアンス要件の変化に迅速に対応することが求められています。

Apigee API 管理は、Lean Business Services、チューリッヒ市、Conrad Electronics といった世界中のお客様に利用されており、モダナイゼーションから収益化までの幅広いユースケース向けの API 構築を支援しています。オンプレミス、ハイブリッド、クラウドベースなどの環境を問わず、驚異的なスケールにも対応しています。組織がデジタルインタラクションを推進し、AI / ML のような新たなテクノロジーを取り入れるために API への依存度を高めるにつれて、API 管理の複雑性も急速に増しています。このようなダイナミックな課題に対処することは、Google が自らの責任として重要視していることであり、お客様、ユーザー、コミュニティから寄せられる評価と信頼に深く感謝しています。

API 管理ベンダーの選択は、単なる技術的な選択にとどまらず、ビジネスに重大な影響を与える決断でもあります。Gartner Magic Quadrant for API Management は、プロバイダが現在の市場の課題に適切に対処しているか、プロダクトビジョンを実行できているかという両面について、プロバイダの有効性に関する優れたインサイトを提供しているという点で、役立つ判断材料になると Google は考えています。

Google の日々の投資が Gartner によって適切に評価されたと言えるものの、Apigee プロダクトのイノベーションはまだ始まったばかりです。今年も、以下のような主要な領域への投資を継続しています。

商業的柔軟性 - 2022 年 8 月に導入した従量課金制の価格設定が好評を博し、それ以来、さらなる柔軟性を求める声が高まっていました。このことを受けて、さらなる簡素化を行い、すべてのモデルで料金属性を調整して、従量課金制の価格設定の粒度を高めました。これらの変更は、より低費用で Apigee を導入し、実際の使用量に合わせて費用を綿密に調整できるようにすることを目的としています。

汎用性 - Apigee は、パブリッククラウドやオンプレミスでホストされるバックエンドサービスにより、あらゆる規模で運用されるさまざまな API ユースケースに対応します。また、デベロッパーは、Apigee Hybrid を使用することで、API プロキシをどのような環境にも柔軟にデプロイできます。今年は、軽量 API プロキシ（標準 API プロキシ）をデプロイする機能も導入しました。これは、Apigee にデプロイされる従来の API プロキシの 1/5 の費用でトラフィックをオーケストレートするものです。この機能により、Apigee に組み込まれた API プロキシがより多面的になり、アプリケーションのトラフィックをオーケストレートできるだけでなく、トランザクションを収益化するプロダクトへと変えることも可能になります。

生成 AI イノベーション - Google Cloud Next ‘23 限定公開プレビューにおいて、デベロッパーの労力を軽減する Apigee API 管理の Duet AI を発表しました。Apigee API 管理の Duet AI を使用すると、デベロッパーは自然言語プロンプトで API 仕様を構築できるようになります。さらに、これらの仕様を使って ChatGPT や Vertex AI などのツールに安全な実世界のデータアクセスを提供する拡張機能を作成できます。また、Google トラフィックのコーパスでトレーニングされた大規模言語モデルを組み込み、セキュリティの異常を自動的に検出できるようにしました。

API セキュリティ - API は、アプリケーションの機能やデータへの直接アクセスを提供するため、攻撃者に狙われやすいターゲットとなっています。Google は昨年、API の構成ミスや bot 攻撃を検出する Advanced API Security を発表し、今年に入ってからは、ビジネスロジック攻撃を検出する ML モデルを追加しました。さらに最近、異常を通知して、フラグを立てる、リダイレクトする、トラフィックをブロックするといったプロアクティブな対応を取る機能も追加しました。これらの機能には、Google Cloud コンソールや専用の API を介してアクセスできるため、セキュリティ管理や既存のシステムへの統合が簡素化されます。

デベロッパー エクスペリエンス - API 開発やセキュリティに対する要求が特に高まる中、Google はデベロッパーエクスペリエンスの簡素化に尽力しています。API ポートフォリオが増え続けるなか、デベロッパーはどこで設計した API 仕様であっても、ユニバーサルカタログの API Hub に自動的にカタログ化できます。さらに、Application Integration の一般提供を開始したことで、実務担当者は、Google Cloud とサードパーティアプリケーション間の相互運用性を強化できるようになりました。Google は、プラットフォームへのワークロードの「シフトダウン」によってデベロッパーが疲弊しないようにすることで、デベロッパーの負担を軽減することを目指しています。

Google は、Gartner Magic Quadrant はベンダーを評価するための優れた情報源であると考えており、お客様をサポートするための Google の継続的な投資がこの業界で認められたことを嬉しく思います。何よりも、お客様のご支援と、私たちが力を入れている Apigee の今後へのご期待に感謝いたします。

レポートの全文は、こちらからダウンロードしていただけます（メールアドレスが必要です）。Apigee API 管理について詳しくは、こちらをご覧ください。

^{Gartner Magic Quadrant for API Management、2023 年 10 月 11 日、Shameen Pillai、飯島} ^{公彦、Mark O’Neill、John Santoro、Paul Dumas、Andrew Humphreys、Nicholas Carter。この Magic Quadrant レポートは、以前は Magic Quadrant for Application Services Governance（2015 年）、および Magic Quadrant for Full Life Cycle API Management（2016 年、2018 年～2022 年）として公開されています。}

^{Google Cloud（Apigee）は、これまで、2018 年～2022 年は Google（Apigee）として、2015 年～2016 年は Apigee としていたものと同一のものです。上の図は、リサーチ} ^{ドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Apigee までご請求ください。Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ組織の見解により構成されるものであり、事実の表明とは解釈されません。Gartner は、明示または黙示を問わず、商品性や特定の目的への適合性を含め、本リサーチに関連したいかなる保証も行いません。}

^{GARTNER は、米国およびその他の国における Gartner, Inc. またはその関連会社の登録商標およびサービスマークであり、MAGIC QUADRANT は、Gartner, Inc. またはその関連会社の登録商標であり、許可を得て使用しています。著作権はすべて同社に帰属します。}

-Apigee、インフラストラクチャ担当プロダクト マーケティング責任者 Rachel Richardson

-Apigee、グループ プロダクト マネージャー Nils Swart

Apigee API 管理の料金と対象範囲を細分化

Tue, 10 Oct 2023 01:20:00 +0000

※この投稿は米国時間 2023 年 10 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

昨今のアプリケーションおよびインテグレーションでは、API の活用がこれまでになく進んでいます。すでに 90% 以上のデベロッパーが、小規模のアプリからミッションクリティカルな運用まで、さまざまな目的で API を利用しています。その結果、組織は複数の API ゲートウェイを扱うことになり、運用、セキュリティ、メンテナンスのオーバーヘッドが生じています。こうした背景において、API 管理の画一的なアプローチは、多くの企業のニーズに合わなくなってきています。

Google Cloud はお客様のニーズに応え、2022 年 8 月に Apigee の従量課金制を導入し、API 管理費用をフレキシブルに管理できるようにしました。この変更は確かな成果をもたらしましたが、お客様からは他にも、Apigee を低料金で使い始めたい、使用量に対する継続的な支出を柔軟に最適化したい、といった要望がありました。

このたび、以下の方針に基づき料金モデルが改定されることになりましたのでお知らせいたします。

Apigee の従量課金制モデルとサブスクリプションモデルの料金属性を統一する
従量課金制の料金を細分化する

この改善により、従量課金制において使用量に対する支出をきめ細かく管理し、使用量が増えるに従ってサブスクリプション料金に簡単に移行することが可能となります。

従量課金制とサブスクリプションで料金属性を統一

今後は、従量課金制とサブスクリプションの両方の料金モデルで同じ料金属性が使用されます。どちらでも、以下の各属性の正確な使用量に基づいて料金が請求されます。

API 呼び出し: ランタイムが処理した API 呼び出しの数
環境: デプロイ環境の使用（リージョンごと、1 時間あたり）
プロキシのデプロイ: 環境にデプロイした API プロキシの数（リージョンごと、1 時間あたり）
アドオン機能: 要件に応じて追加容量や機能を選んでお支払い
補助的な Google Cloud サービス: Google Cloud のネットワークインフラストラクチャまたはサポートの使用に対する明朗料金

従量課金制料金モデルの場合、上述の各属性の使用量に応じて料金が決まります。サブスクリプション料金モデルの場合、上述の各属性について、料金ティア（Standard、Enterprise、Enterprise Plus）ごとに一定の容量が与えられます。

従量課金制の料金を細分化

さらに、従量課金制の料金を細分化します。これによって、少量の使用から始めて、実際の使用状況に沿って継続的な支出を最適化することが可能となります。API 管理機能のフルパッケージに対する包括的な料金ではなく、実際に使用した機能の分のみお支払いいただきます。具体的には、この細分化は以下に示す 2 つのメインの料金属性が対象です。

API 呼び出し

API 呼び出しを処理する API プロキシのタイプに基づいて料金が決まります。以下のように 2 種類の API プロキシを導入します。

標準 API プロキシ: Apigee の一部のポリシーにアクセスできる軽量プロキシです。拡張可能な API プロキシの 5 分の 1 の料金で使用できます。標準 API プロキシは、以下の用途に適しています。

バックエンドサービスにトラフィックを送信する（変換処理は最小限）
複雑度の低いトラフィックを処理する（以下に示す拡張可能な API プロキシに比べ格安）

拡張可能な API プロキシ: 完全にプログラム可能なプロキシで、Apigee のポリシーや機能に無制限にアクセスできます。拡張可能な API プロキシは、以下の用途向けに設計されています。

複数のバックエンドサービス間で複数のユーザーのトラフィックを管理する API プロダクトを構築する
複雑な構成を簡素化し、共有フローを使って標準設定を適用する
複雑な変換やきめ細かな管理を要するトラフィックを処理する

標準 API プロキシの呼び出しの料金は、拡張可能な API プロキシの 5 分の 1 に設定されています。

環境

Apigee の環境とは、開発者が API プロキシを作成、デプロイするための組織内のソフトウェア環境です。この環境の料金は、API プロキシをデプロイする環境のタイプによって決まります。以下のように、利用可能な Apigee 機能に基づき 3 種類の環境を導入します。

ベース環境: Apigee プラットフォームに低料金でオンボーディングし、複雑度の低い API を管理できます。ベース環境では以下を行えます。

標準 API プロキシのデプロイ
API のモニタリング
API Hub、Apigee 開発ツールの使用
他の Google Cloud サービスへのアクセス

ベース環境は、プロトタイピング、社内開発、小規模のアプリケーションなど、基本的なトラフィックオーケストレーションを必要とする API ユースケースに適しています。

2. 中間環境: API のポートフォリオを管理できるほか、さまざまなアドオン機能も利用できます。中間環境では以下を行えます。

ベース環境でできることすべて
拡張可能な API プロキシのデプロイ
共有フロー、API プロダクト、デベロッパーポータルの構築
アドオン機能としてのアナリティクスの購入

この中間環境に適した API ユースケースとしては、API プロダクトを構築してデベロッパーに公開する、導入が増加している API のポートフォリオを管理する、API トラフィック内の複雑な変換やメディエーションを処理する、といったものがあります。

3. 包括的な環境: 高い信頼性と卓越したパフォーマンスを備え、ミッションクリティカルなアプリやトラフィックの予期せぬ急増に対応します。包括的な環境では以下を行えます。

中間環境でできることすべて
複数リージョンへのデプロイ
環境ごとの追加プロキシの購入、デプロイ
QPS の自動スケーリング、コンフィデンシャルコンピューティング、ハイパフォーマンスコンピューティング（HPC）

包括的な環境は、高い信頼性およびパフォーマンスが要求されるミッションクリティカルなアプリケーションや、API オペレーションの詳細制御が必要な API ユースケース向けに設計されています。

単一の Google Cloud プロジェクト内で複数の環境タイプを組み合わせて使用することで、料金を細かく管理できるようになりました。ニーズに応じて、環境タイプを切り替えることも可能です。Apigee の新しい従量課金制料金モデルの概要を以下に示します。

Apigee API 管理を使ってみる

この変更により、低料金で Apigee の使用を開始し、費用を明確に管理しながら API 管理のフルライフサイクルへ移行することが可能となります。このような特徴を備えたソリューションは市場にほかに存在しません。新しい料金モデルについて詳しくは、料金ページまたは技術ドキュメントをご覧ください。Apigee を使い始める手順については、こちらを参照してください。

ーグループ プロダクト マネージャー Nils Swart

ープロダクト マネージャー Sujin Park

Apigee は政府機関のゼロトラスト導入にどう役立つのか

Thu, 01 Jun 2023 03:40:00 +0000

※この投稿は米国時間 2023 年 5 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

政府機関のアプリケーションエコシステムを効果的に構築するうえで重要となるのが、安全なデータ共有です。新しいアプリケーションを構築する代わりに API を使用すると、行政機関のリーダーは既存の技術環境内でデータドリブンな分析情報を収集できるようになります。API を活用することで、政府機関はアプリケーションベースの情報を統合し、その目標を支えることができます。

米国政府機関では現在、サイバー攻撃の検出と防御のために、ゼロトラストセキュリティアーキテクチャの導入が推奨されています。API の保護は、ゼロトラストアーキテクチャの実装における基本原則です。Gartner® は自社の Innovation Insight for API Protection レポートで次のように述べています。「今年は 15% 未満ですが、2026 年までに、組織の 40% が高度な API 保護とウェブアプリケーションセキュリティの機能に基づいてウェブアプリケーションや API 保護のプロバイダを選択するようになるでしょう。」

この投稿では、Google Cloud の Apigee が、ゼロトラストの原則に沿った API 保護の構築にどのように役立つかを説明します。

政府機関のゼロトラストアーキテクチャ導入における Apigee のメリット

Apigee は、政府機関のセキュリティリーダーがプラットフォームアプローチを採用して API を安全に管理するのに役立つ、フルライフサイクルの API 管理プラットフォームです。図 1 に示されているように、政府機関は Google Cloud のソリューションである「ウェブアプリと API の保護」（WAAP）を使って、ゼロトラストアーキテクチャへの取り組みを開始できます。WAAP は Cloud Armor、reCAPTCHA Enterprise、Apigee を使用して政府のウェブサイトを保護します。また、bot や不正行為のリスクを軽減して即座に結果を出し、成熟したセキュリティ対策を支援します。Apigee には、セキュリティ、トラフィック管理、可視性、自動化、ガバナンスに対応するすぐに使えるポリシーが備わっており、ゼロトラストに準拠したアーキテクチャに必要とされる重要な要素を 1 か所で管理できます。

図 1. アーキテクチャ概要: Google Cloud のウェブアプリと API の保護

ゼロトラストに対応した Apigee ソリューションの特徴

図 2 には、Apigee の機能を示すリファレンスアーキテクチャの概要が示されています。ポリシー管理および適用ポイントとして機能しつつ、ウェブアプリケーションファイアウォール、消費者の行動 / インテントベースの信頼アルゴリズム、IAM、分析システム、ロギングシステム、モニタリングシステムとシームレスに連携します。このアーキテクチャは、アクセスデータのテレメトリーに基づいてシステムのオブザーバビリティを向上させ、ゼロトラストアーキテクチャを段階的に成熟させるための基盤を提供します。

図 2. NIST 800-207 のユースケース。契約社員と複数のクラウドプロバイダを抱える企業。ゼロトラストアーキテクチャを実現するポリシー管理および適用ポイントとしての Apigee で保護されている

マルチクラウド API ゲートウェイ: Apigee は、クラウドでホストされるポリシー構成および適用ポイントであり、適用エンジンの復元性に関するリスクを軽減します。パブリッククラウドやプライベートクラウドの任意の環境で、一貫した制御によって API を管理することができます。また、OIDC、Oauth 2.0、SAML、JWT の SSO、MFA、コンテキストアウェアアクセス、パスワードなしのアクセス機能を適用するためのすぐに使えるポリシーを備え、クラウドファーストの高度なリソースの認証と認可を提供します。

自動化された脅威対策: Apigee の Advanced API Security により、API の構成ミスの特定、bot の検出、セキュリティスコアと保護に関する推奨事項の提供、API 環境のセキュリティ修復の自動化が可能になります。また、単一の IP アドレスからの大量の呼び出しなど、異常なトラフィックを示す特定の API トラフィックパターンを使用して、DDoS や OWASP Top 10 の脅威から保護します。

シームレスなインテグレーション: Apigee は、悪意のある消費者の行動を検出するために reCAPTCHA などの信頼アルゴリズムと統合できるだけでなく、OWASP Top 10 の攻撃から保護するために Cloud Armor などの WAF とも統合でき、高度な脅威対策を提供します。

Identity and Access Management（IAM）: Apigee は、Google Cloud Identity、Okta、Active Directory などの既存の ID プロバイダとの統合によって ID 管理を簡素化します。多要素認証、特権アクセス、ID 連携、行動パターン検出、生体認証信号などの ICAM システムと連携して高度なセキュリティポリシーを適用できます。さらに、Oauth 2.0、JWT、SAML トークンを使用して時間制限付きアクセスを実装する API の継続的かつコンテキストに応じた認証と認可の環境を構築します。

分析とモニタリング: Apigee Analytics は、API のパフォーマンスとセキュリティの全体像の把握を可能にし、組織が API をリアルタイムでモニタリングし最適化できるようにします。これには、API の使用状況、パフォーマンス、セキュリティに関する詳細な分析情報が含まれます。また Apigee は、Google の Chronicle のようなさまざまな SIEM システムとシームレスに統合することもできます。

ガバナンス、コンプライアンス、監査: Apigee の API Hub を使用すると、組織のすべての API に関する情報を 1 か所に集めて管理できます。Apigee API Hub には設計、実装からサポートの終了、使用停止に至るまでライフサイクルのあらゆる段階の API が含まれ、一貫した設計基準とガバナンスチェックを徹底することができます。

次のステップ

Apigee は、安全な API 管理を通じて、重要なライフサイクル管理を実装するためのプラットフォームベースのアプローチを提供します。私たちのアプローチには、時間制限のあるアクセスのプロビジョニングと終了に対処する機能の提供、主権を保護しながらデータを活用する機能、企業リソースのガバナンスに自動化と深い可視性を提供する機能が含まれ、これらすべてがゼロトラストアーキテクチャの成熟を促すために役立ちます。

API とアプリケーションを保護するためのベストプラクティスを確認して、Google Cloud で Apigee を使ってみましょう。ぜひ、無料トライアルの開始または料金の確認をご検討ください。また、Apigee セールスまでお問い合わせいただくと、API 管理のユースケース評価をお手伝いいたします。

- Google Public Sector、カスタマーエンジニア Saurabh Chhatwal

API 管理で政府プラットフォームを統合

Fri, 14 Apr 2023 03:20:00 +0000

※この投稿は米国時間 2023 年 4 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

ハワイ州の福祉局やイタリアのヴェネト州など、世界中の政府機関が API を利用してレガシーシステムをモダナイズし、各部署や自治体間の相互運用性を実現して独自のセキュリティ体制を強化しています。Apigee は、政府機関が API を構築、管理、保護することを支援する最先端の API 管理プラットフォームです。

政府機関の多くでは、依然としてデータサイロや分離されたプラットフォームが使用されており、その結果、デジタルエクスペリエンスが非効率的で断片化されたものとなっています。Apigee は、政府機関がアプリケーションやデータへのアクセスを安全かつ実用的な方法で簡単に共有できるようにします。さらに、デベロッパーは Apigee を使用することで、市民や政府職員が利用できるモダンなウェブおよびモバイルエクスペリエンスを作成できます。

API を使用して政府システムを安全に接続する

政府のシステムのデータが、ファイアウォールルールや認証プロトコルなど、多くのセキュリティ対策によって保護されていることは偶然ではありません。データセキュリティは政府機関にとって最優先事項であり、これは望ましいことです。しかし、このセキュリティの実現のためにアクセス性が犠牲にされるべきではありません。政府が保有するデータは、安全であることは当然として、アクセス、理解、共有も容易であるべきです。

安全なデータアクセスを実現するためには、Apigee API 管理を活用して、一貫性のある安全な API を提供できます。API レイヤはバックエンドシステムの前に位置するため、直接接続することの複雑さがなくなります。Cloud Interconnect や Cloud VPN などの Google Cloud ネットワーキングサービスを使用することで、Apigee とバックエンドシステムの間にプライベートで安全な接続を作成できます。認証とネットワーキングのオーケストレーションは API レイヤで行われるため、内部で簡単にデータを共有できるだけでなく、パートナーや近隣の自治体との外部接続を確立することもできます。

Apigee のアーキテクチャ

政府プラットフォームの統合

Apigee はデータシステム間の相互運用性を実現できるため、政府機関はサービスやテクノロジーの改善やモダナイズをより自由に行えます。人々が政府のデジタルサービスを利用する際、断片化されたエクスペリエンスに遭遇することがよくあります。行政機関のリーダーは、API を使用してデータを共有し、接続されるアプリケーションを構築することで、住民のエクスペリエンスを改善できます。

統合された政府プラットフォームは、ユーザーエクスペリエンスを向上させ、コールセンターやヘルプデスクなどのサポートサービスの負担を軽減します。そこで Google は、多くのウェブサイト上に散在する部門アプリケーションの代わりに、各部門の機能を単一の直感的なアプリケーションに統合するプラットフォームの構築を支援したいと考えています。

API 管理は、外部ユーザーのエクスペリエンスを向上させるだけでなく、政府職員のエクスペリエンスと生産性も向上させることができます。政府ではよくある、データにアクセスできないことによって生じる非効率的なプロセスは、通常は時間のかかる手作業で解決されています。API が可能にするシステム間の相互運用性により、データにアクセスできなくなる問題が解決されます。デベロッパーは、これらの API を使用して、細分化されたシステムを統合し、手動プロセスをデジタル化し、運用能力を拡張するソリューションを作成できます。

API エコシステムへのアクセスを管理する

データサイロ間の接続が可能になったとしても、API へのアクセスを管理する責任は引き続き存在します。この作業は、一元的な API 管理システムがない場合は困難になる可能性がありますが、Apigee では、API プロダクトとアプリケーションを使用することで安全な API を簡単に公開できます。API プロダクトは API プロキシを有用なサービスにバンドルし、アプリケーションは API プロダクトを利用するために必要なアクセスキーを提供します。これらのリソースを使用して、API をセグメント化し、必要なアクセスレベルに基づいて使用を制限します。

API プロダクトを作成したら、Apigee のデベロッパーポータルを利用することで、OpenAPI Specification を使用して安心して API を公開し、消費を管理できます。これらのポータルは、提供する機能が柔軟であるだけでなく、デプロイが非常に簡単です。また、ポータル内ではデベロッパーが直接 API を簡単に探索、理解、テストできるため、開発スピードを向上させるうえで大きな役割を果たします。

使ってみる

Apigee を使用することで、州の機関や地方自治体はデジタルプレゼンスをモダナイズし、データやサービスを取り巻くエコシステムを構築できます。Apigee API 管理は、従量課金制の料金プランまたは 60 日間の無料トライアルを利用して、今すぐお試しいただけます。ご利用にあたっては、こちらの動画をご覧ください。Apigee およびサービスの詳細については、Google のセールススペシャリストまでお問い合わせください。

- Google Public Sector、Apigee カスタマーエンジニアスペシャリスト Raven Hedden

Eventarc と Cloud Run でクラウドリソースの変更に対応する

Thu, 26 Jan 2023 09:20:00 +0000

※この投稿は米国時間 2023 年 1 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

Eventarc と Cloud Run でクラウドリソースの変更に対応する

この投稿では、クラウドインフラストラクチャ内の変更を通知するイベントに Eventarc を使って非同期で対応する方法を取り上げます。また、こうしたイベントへの反応、ダウンストリームのオペレーションの実施ができる基本的な Cloud Run サービスの実装についても説明します。ここでは例として、Apigee の監査ログイベントを使用して Eventarc のイベントをトリガーします。トリガーの仕組みは一般的な GCP の監査ログに基づいているため、監査ログをサポートするあらゆる GCP サービスにもこの事例を簡単に適用できます。

Eventarc とは

クラウドコンピューティングといえばまず思い浮かぶのは、インフラストラクチャの動的な性質です。また、複雑なアーキテクチャでもワンクリックで、あるいは GitOps のパイプラインに PR をマージして簡単にプロビジョニングできる点です。

インフラストラクチャの作成プロセスを簡素化し、プロビジョニングにかかる時間を数日から数分に短縮することで、Google はプロセスとガバナンスの要件を刷新しました。インフラストラクチャの変更へ適切に反応するには、より高度な自動化とレジリエンスが欠かせません。そこで登場するのが Eventarc です。Eventarc を使えば、さまざまな種類のイベントソースからイベントを非同期に配信し、無数のサーバーレスイベントハンドラでこれらに対応できます。

Eventarc では、次のようなさまざまイベントに反応できます。

Cloud Storage、Firebase のアラート、Firebase Remote Config の変更といった直接公開されたイベント
多数の GCP サービスの監査ログエントリ
一般的な Pub/Sub メッセージ
パートナーのソース

サポート対象のイベント一覧はこちらをご覧ください。

こうしたイベントは、Cloud Run、Kubernetes Service、Workflows で処理できます。イベントソースとイベントハンドラの組み合わせは多数存在するため、このデモンストレーションでは監査ログイベントおよび Cloud Run での処理方法を取り上げることとします。利用可能なドキュメントおよびオープンソースの例を参照すれば、このコンセプトをその他の利用可能な組み合わせに簡単に適用できます。

Eventarc ハンドラの定義

このサンプルでの基本アーキテクチャは次の通りです。

上図の編集可能版についてはこちらのリンクをご確認ください。

ここでは、Apigee が発行した監査ログを Eventarc で処理したいイベントのソースとして使用します。このイベントはその後、Eventarc が管理する Pub/Sub トピックに追加され、Cloud Run の Node.js サービスで処理されます。

Cloud Run イベントハンドラ

まず、シンプルな Cloud Run サービスで監査ログイベントに反応するサンプルアプリケーションを作成します。これを行うには、eventarc-handler というフォルダと、このフォルダ内に格納する package.json と index.js ファイルを作成します。また、後ほどこれを Cloud Run 用のコンテナとして構築した際に Cloud Build へノードモジュールが送信されないよう、gcloudignore ファイルも作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir eventarc-handler && cd eventarc-handler\r\n\r\ncat >package.json <<EOF\r\n{\r\n "name": "eventarc-handler",\r\n "description": "Eventarc Demo",\r\n "version": "1.0.0",\r\n "private": true,\r\n "main": "index.js",\r\n "scripts": {\r\n "start": "node index.js"\r\n },\r\n "engines": {\r\n "node": ">=12.0.0"\r\n },\r\n "author": "danistrebel",\r\n "license": "Apache-2.0",\r\n "dependencies": {\r\n "express": "^4.17.1",\r\n "@google/events": "^3.1.0",\r\n "cloudevents": "^4.0.1"\r\n }\r\n}\r\nEOF\r\n\r\ncat >index.js <<EOF\r\nconst { HTTP } = require(\'cloudevents\');\r\nconst express = require(\'express\');\r\nconst {toLogEntryData} = require(\'@google/events/cloud/audit/v1/LogEntryData\');\r\n\r\nconst app = express();\r\napp.use(express.json());\r\n\r\napp.post(\'/\', async (req, res) => {\r\n try {\r\n const cloudEvent = HTTP.toEvent({ headers: req.headers, body: req.body });\r\n const logEntryData = toLogEntryData(cloudEvent.data);\r\n console.info(\'Received EventarcEvent:\', logEntryData.protoPayload.methodName);\r\n console.info(logEntryData);\r\n\r\n res.status(200).send(\'OK\');\r\n } catch (error) {\r\n console.error(\'Error in handing Eventarc Event\');\r\n console.error(error);\r\n res.status(500).send(\'Internal Error\');\r\n }\r\n});\r\n\r\nconst port = parseInt(process.env.PORT) || 8080;\r\napp.listen(port, () => {\r\n console.log("eventarc-handler: listening on port", port);\r\n});\r\nEOF\r\n\r\ncat >.gcloudignore <<EOF\r\nnode_modules\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f434640>)])]>

必要な Google API を有効にして上記のイベントハンドラを実行対象の Cloud Run サービスとしてデプロイするには、eventarc-handler フォルダ内で次のコードを実行します。

code_block: <ListValue: [StructValue([('code', 'export PROJECT_ID=my-project\r\nexport REGION=europe-west1\r\n\r\ngcloud services enable run.googleapis.com \\\r\nartifactregistry.googleapis.com \\\r\ncloudbuild.googleapis.com --project $PROJECT_ID\r\n\r\ngcloud run deploy eventarc-handler --region $REGION --project $PROJECT_ID --source . --no-allow-unauthenticated'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f4340a0>)])]>

サービスがデプロイされたら、サンプルのクラウドイベントでテストを行うことができます。これを実行するには、Cloud Run サービスの URI を取得して SERVICE_URI（形式: https://eventarc-handler-some-hash.a.run.app）に保存し、サンプルイベントのペイロードを送信する必要があります。このサンプルイベントでは、わかりやすくするためリクエストとレスポンスの詳細が省略されています。実際のクラウドイベントにはさらに詳細な情報が含まれています。

code_block: <ListValue: [StructValue([('code', 'SERVICE_URI=$(gcloud run services describe eventarc-handler --region $REGION --format="value(status.url)") --project $PROJECT_ID\r\n\r\necho $SERVICE_URI\r\n\r\ncurl -X POST "$SERVICE_URI" \\\r\n-H "Authorization: Bearer $(gcloud auth print-identity-token)" \\\r\n-H \'Content-Type: application/json\' \\\r\n-H "ce-id: 1" \\\r\n-H "ce-source: //pubsub.googleapis.com/projects/my-apigee-org/topics/my-topic" \\\r\n-H "ce-specversion: 1.0" \\\r\n-H "ce-type: google.cloud.audit.log.v1.written" \\\r\n-H "ce-dataschema: type.googleapis.com/google.logging.v2.LogEntry" \\\r\n-H "ce-subject: apigee.googleapis.com/organizations/my-org/developers/somedeveloper@example.com" \\\r\n-H "ce-methodname: google.cloud.apigee.v1.SampleResource.SampleMethod" \\\r\n-d \'{\r\n "resource": {\r\n "labels": {\r\n "service": "apigee.googleapis.com",\r\n "project_id": "my-apigee-org",\r\n "method": "google.cloud.apigee.v1.SampleResource.SampleMethod"\r\n },\r\n "type": "audited_resource"\r\n },\r\n "insertId": "1de11nde7ys3b",\r\n "timestamp": "2022-08-04T14:56:05.729242115Z",\r\n "protoPayload": {\r\n "authenticationInfo": {\r\n "principalEmail": "someone@example.com"\r\n },\r\n "authorizationInfo": [],\r\n "response": {},\r\n "serviceName": "apigee.googleapis.com",\r\n "serviceData": {},\r\n "request": {},\r\n "requestMetadata": {},\r\n "resourceName": "organizations/my-apigee-org/developers/somedeveloper@example.com",\r\n "methodName": "google.cloud.apigee.v1.SampleResource.SampleMethod"\r\n },\r\n "receiveTimestamp": "2022-08-04T14:56:05.729242115Z",\r\n "logName": "projects/my-apigee-org/logs/cloudaudit.googleapis.com%2Factivity"\r\n}\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f434160>)])]>

Cloud Logging UI または次の gcloud コマンドで Cloud Run ログのクラウドイベントからログステートメントを確認できます。

code_block: <ListValue: [StructValue([('code', 'gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=eventarc-handler" --project $PROJECT_ID --limit 25 --format "value(textPayload)"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f434490>)])]>

出力結果に次のログエントリが含まれているはずです。

code_block: <ListValue: [StructValue([('code', 'Received EventarcEvent: google.cloud.apigee.v1.SampleResource.SampleMethod'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f434850>)])]>

これでイベントハンドラの準備が整いました。次は取得するイベントに進みます。

監査ログイベントのソース

Eventarc は、Cloud Audit Logs に書き込まれるイベントに反応できます。このサンプルでは Apigee Management API にある特定のメソッドに反応したいので、Apigee サービスの監査ログを有効にする必要があります。これは、こちらに記載した API 経由もしくは GCP UI で行えます。

監査ログが想定通り動作していることを確認するため、Apigee UI を開いてプロキシを開きます。その後以下のコマンドを実行して、このアクションに対して監査ログが作成されていることを確認します。

code_block: <ListValue: [StructValue([('code', 'gcloud logging read "logName : projects/$PROJECT_ID/logs/cloudaudit.googleapis.com AND protoPayload.serviceName: apigee.googleapis.com" --project=$PROJECT_ID --limit 25 --format "value(protoPayload.methodName)"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f64bc5cbf40>)])]>

Eventarc で監査ログイベントをイベントハンドラに転送する

これでイベントソースとイベントハンドラのどちらも構成が済んだので、この 2 つのコンポーネントを非同期のイベントデリバリーパイプラインに統合する Eventarc を作成します。

これを行うには、GCP コンソールまたは以下の gcloud コマンドを利用して Eventarc API を有効にします。

code_block: <ListValue: [StructValue([('code', 'gcloud services enable eventarc.googleapis.com --project $PROJECT_ID'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f64bc5cb730>)])]>

サービスを有効にしたら、新規の Eventarc トリガーを作成できます。Cloud コンソールで、次の情報の新規トリガーを作成します（Pub/Sub および Compute のサービスアカウントには、提案されたロールを割り当ててください）。

トリガーの名前: apigee-developer-app

イベントプロバイダ: Apigee

イベント: google.cloud.apigee.v1.DeveloperApps.CreateDeveloperApp

リソース: Any resource

リージョン: global（Apigee コントロールプレーンはグローバルサービスであるため）

サービスアカウント: Compute Engine default service account

イベントの宛先: Cloud Run

Cloud Run サービス: eventarc-handler

サービス URL パス: /

gcloud の場合は以下を参照してください。

code_block: <ListValue: [StructValue([('code', 'PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")\r\n\r\ngcloud projects add-iam-policy-binding $PROJECT_ID --member=serviceAccount:service-$PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com --role=roles/iam.serviceAccountTokenCreator\r\n\r\ngcloud projects add-iam-policy-binding $PROJECT_ID --member=serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/eventarc.eventReceiver\r\n\r\ngcloud projects add-iam-policy-binding $PROJECT_ID --member=serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com --role=roles/run.invoker\r\n\r\ngcloud eventarc triggers create apigee-developer-app \\\r\n--location=global \\\r\n--service-account=$PROJECT_NUMBER-compute@developer.gserviceaccount.com \\\r\n--destination-run-service=eventarc-handler \\\r\n--destination-run-region=$REGION \\\r\n--destination-run-path="/" \\\r\n--event-filters="type=google.cloud.audit.log.v1.written" \\\r\n--event-filters="serviceName=apigee.googleapis.com" \\\r\n--event-filters="methodName=google.cloud.apigee.v1.DeveloperApps.CreateDeveloperApp" \\\r\n--project $PROJECT_ID'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f161430>)])]>

Eventarc 用に自動作成された Pub/Sub サブスクリプションを確認します。

code_block: <ListValue: [StructValue([('code', 'gcloud pubsub subscriptions list'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f161d90>)])]>

これまでに作成し指定した Cloud Run アプリケーションとして push エンドポイントが一覧表示されることを確認します。

エンドツーエンドのバリデーション

同じ Apigee 組織の Apigee UI から、次のリソースを作成できます。

[Publish] > [Developers] から [App Developer] を作成
[Publish] > [Products] から [API Product] を作成
[Publish] > [Apps] から [APP for the Product and Developer] を作成

Cloud Logging UI または次の gcloud コマンドで Cloud Run ログのクラウドイベントからログステートメントを確認できます。

code_block: <ListValue: [StructValue([('code', 'gcloud logging read "resource.type=cloud_run_revision AND resource.labels.service_name=eventarc-handler" --project $PROJECT_ID --limit 25 --format "value(textPayload)"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f161e80>)])]>

出力結果に次のログエントリが含まれているはずです。

code_block: <ListValue: [StructValue([('code', 'Received EventarcEvent: google.cloud.apigee.v1.DeveloperApps.CreateDeveloperApp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f5e74f0>)])]>

また、Eventarc の実行は Eventarc UI または該当するエクスプローラーの UI で確認できます。

Apigee 固有の Eventarc ユースケース案

上記のサンプルを参考に Cloud Run サービスを拡張して、さらに便利なダウンストリームアクションをトリガーできます。これにより、クラウドアーキテクチャや Google API が管理するその他のリソースの変更へ非同期に反応できるようになります。

Apigee のコンテキスト内で Eventarc のトリガーを適用可能な例を一部ご紹介します。

開発者アプリの承認フロー
Apigee には、アプリケーションの任意の承認という考えがあります。ここで説明した Eventarc のアーキテクチャを使えば、API プロダクトオーナーによる手動承認が必要な、新規登録された開発者アプリケーションの承認プロセスをトリガーするワークフローを実装できます。まずは、Cloud Logging のアラート、メール、chatbot 経由、または問題追跡ツールでの問題作成から開始します。このアプローチに関する説明は、こちらのコミュニティ投稿をご確認ください。
アプリケーションや開発者の動的な登録
アプリケーションや開発者を管理する Apigee の仕組みは、サードパーティの ID プロバイダ（IdP）と簡単に統合できます。これにより、たとえば Apigee とバックエンドサービスのどちらでも使用できるアクセストークンを作成できます。新規に作成された DeveloperApps で Eventarc のイベントを使用すると、Apigee の認証情報を外部の IdP と同期できます。そのため、外部のアクセストークンが使用されても Apigee の分析データセマンティクスを維持できます。
デベロッパーポータルや API Hub での API プロダクトの自動公開および自動更新
API の公開は API プログラムの重要な側面です。Apigee では、デベロッパーポータルに公開された API のアーティファクトが、API プロダクトに基づきながら疎結合されています。デベロッパーポータルの公開 API と API プロダクトを同期させるため、Eventarc を利用してポータルの API を自動で登録、更新、削除できます。同じ仕組みを Apigee API Hub での API の公開にも適用できます。

まとめ

Eventarc はインフラストラクチャの変更に応じてワークフローをトリガーできるパワフルなサービスです。サポートされているトリガーイベントやイベントハンドラにより、さまざまな自動化プロセスやガバナンスプロセスの実装に適しており、クラウドインフラストラクチャの動的な性質を補完するツールになっています。

まずは、さまざまなイベントタイプやターゲットに合わせて Eventarc を作成する手順を記載したクイックスタートをご確認ください。

- アプリケーションモダナイゼーションソリューションリード Daniel Strebel

アサヒグループホールディングス：GKE、Apigee、GCVE などを活用し、100 年企業のアーキテクチャーを着実にモダナイズ

Mon, 25 Apr 2022 03:00:00 +0000

「期待を超えるおいしさ、楽しい生活文化の創造」をミッションに、グローバルかつローカルな "グローカル" ビジネスを展開するアサヒグループホールディングス株式会社（以下、アサヒグループ）。そんな同社が今、全社を挙げて取り組んでいる業務システムのモダナイズに Google Cloud がどのように貢献できているのか？このプロジェクトを推進するアサヒグループジャパン株式会社 DX 統括部の清水博マネージャーに話を伺いました。

利用しているサービス：

BigQuery、Google Kubernetes Engine、Apigee API 管理、Google Cloud VMware Engine

利用しているソリューション：

インフラストラクチャのモダナイゼーション

Google Cloud との出会いで拓かれたモダナイズへの道筋

「2014 年に私が DX 統括部（当時はシステム統括部）に転籍してきた当初、アサヒグループには会社のミッションを遂行するための環境やツールが整備されておらず、通常業務に支障が出ているという状況でした。IT 部門はまさにコストセンター（業務にかかったコストだけが集計される部門）と化していて、日々、ツールのアップデートなどに追い立てられているような状態だったのです。」

と、清水氏は当時を振り返ります。しかし、グループとして業務システムをモダナイズ化する必要性は理解していたものの、すでに古いシステム上で長年回っているシステムを止めることはできず、開発リソースにも限りがあります。それからの数年間、清水氏はいかに従来の資産を延命しつつ、新たな環境に移行していくのかを考え続けることになりました。

「そうした中でも、我々がアサヒグループの DNA 的に理解していたのが、他社の真似をして SaaS を導入しただけでは勝てないということ。"勝てるアサヒ" になるためには、アサヒグループ固有の切り口で、アサヒグループにしかできないビジネスモデルを、いかに新しい、モダンな環境で作るかというチャレンジが必要でした。Google Cloud に出会ったのはそうした模索をしている中でのことです。」

その出会いの場となったのが、2017 年 6 月に行われた「Google Cloud Next '17 in Tokyo」。ここで BigQuery のパフォーマンスに惚れ込んだ清水氏は、BigQuery を自社分析基盤に導入することを決意します。

「膨大な量の実データを見たこともないようなスピードで処理しているデモを見て、こんなふうにデータを回せたらビジネスがもっと面白くなると確信しました。当時の我々の分析基盤には、アイデアを具体的にデータで表現するにあたってタイムラグが大きすぎるという課題があったのですが、これを BigQuery の導入で解決できると考えたのです。」

また、アサヒグループではこのタイミングでそれまで自社で運用し、トラブルの多さに悩まされていた自社データセンターを、GKE（Google Kubernetes Engine）に切り替えていく取り組みもスタートしています。

「私は一企業で担保できるインフラの可用性には限界があると思っています。そうした中、ゲーム業界や EC 業界など、秒単位のシステム停止が致命傷となる先進的な業界ではとっくにコンテナ技術を活用し始めているわけです。であれば、我々がそれを使わない手はありませんよね。かなり大きな挑戦ではありましたが、導入して約 3 年が経過した現在もインフラレイヤーでの障害は 1 度も起きておらず、インフラ運用のトラブルがビジネスに与える影響を極小化できています。」

こうした成果からクラウド活用への手応えを感じ始めたアサヒグループは、この流れをさらに加速させるべく、2017 年後半から 2018 年にかけて Apigee も導入。これには大きく 2 つの狙いがあったと清水氏は言います。

「アサヒグループにはさまざまなシステムのハブとなる、データの連係を管理する仕組みがあるのですが、それが可用性におけるボトルネックになっている面もありました。これを疎結合という概念のもとに解決したいというのが第 1 の狙い。そしてもう 1 つが API を駆使したデータのやり取りでグループ企業や取引先を繋いでいくモダンなアーキテクチャの実現です。Apigee は、こうした従来の課題解決と将来に向けたビジョンの実現を両立できるプロダクトということで採用を決めました。」

旧システムを Google Cloud VMware Engine に一時的にマイグレーション

清水氏のリーダーシップの下、着実にモダナイズを進めているアサヒグループ。同社では 2027 年を一つの節目と捉え、そこに向けて段階的にレガシーなシステムを過去の延長線上ではないモダンなアーキテクチャに生まれ変わらせていくとしています。

そして、ここで大きな役割を果たしているのが、Google Cloud 上で VMware vSphere 環境を実現するソリューション、GCVE（Google Cloud VMware Engine）です。その導入にいたった背景について、清水氏は次のように説明します。

「ここまで、アサヒグループがいかにしてシステムをモダンなアーキテクチャに寄せていこうとしているのかというお話をさせていただきましたが、実際にそのための計画を立てていく中で、我々が保有している何百というシステムすべてを一度にモダナイズするのが非現実的だということがはっきりしてきました。古いシステムはそれぞれ OS やアプリケーションのバージョンが異なり、さらに長期間メンテナンスがされていないものも多く、一様なモダナイズができないのです。各事業会社にとって生命線となるようなシステムは利用者も多く、予算も付くのでモダナイズしやすいのですが、そうではない、利用者が少ないわりに廃止することはできないというシステムも多く、これらをどうやってモダナイズしていくのかを考えねばなりません。そもそも、そこにコストをかけてまでやる必要があるのかという疑問もありました。」

もしやるにしても圧倒的に時間が足りないと言う清水氏。

「しかし、だからといってシステムをそのままコンテナに移植するような拙速な移行だけはしたくありません。そこで、モダナイズの見通しが立っていないシステムのうち、仮想マシンが比較的新しく、長期に渡って稼働可能なものについて GCVE を一時的な移動先としてモダナイズまでの猶予を創出するという決断をしました。ここで重要なのは、これまでデータセンター内の VMware vSphere 環境でやっていたことを、何も変えずにクラウド上でも実現できることです。これこそが GCVE の大きなベネフィットであり、この戦略の根幹だと考えています。なお、GCVE では、Intel 製の CPU をはじめ、ハードウェアのスペックが高いことも魅力的でした。そのため、1 ノードごとの集約率も高まり、コストパフォーマンス高くワークロードを稼働させることができ、満足しています。」

この際、GCVE に移行しても猶予時間を稼げない特に古いシステムに関してはあえて、オンプレミスに残すという判断をしたこともポイントだと語る清水氏。「古く、予算も付かないようなシステムに最後通告を突きつける」ことで、組織的な危機感を煽る、それでもダメなら廃棄という判断をすることも必要だと言います。

クリックして拡大

なお、現在は実際に移行したらどういうことが起こるのかをシミュレーションしている段階とのこと。実際の切り替えは 2022 年 6 月から開始され、年度内には完了する予定で、利用者サイドからは移行されたことがわからないほど自然な移行になる見込みです。

「Google Cloud を活用した一連の取り組みによって、"勝てるアサヒ" に近付いた、いや、もうなっているのではないでしょうか。フレームワークはもうできていて、あとはそれを実践して証明していくだけ。勝ちのモデルはできていると自負しています。そしてこうした取り組みを通じ、多くの人材がアサヒグループに興味を持ってくれたことも、Google Cloud を採用したメリットの 1 つだと感じています。」

アサヒグループホールディングス株式会社

国内ビール産業の興隆期を支えた大阪麦酒会社（1889 年設立）の流れを受け継ぐ国内 100 年企業の 1 つ。酒類事業を中核に、三ツ矢、カルピス、ワンダといった主力 6 ブランドによる飲料事業、食品事業などをグローバルに展開する。従業員数は 29,850 名（連結、2020 年 12 月 31 日現在）。

インタビュイー

アサヒグループジャパン株式会社　

DX 統括部マネージャー清水博氏

インテル株式会社

（Google Cloud パートナー）

ヴイエムウェア株式会社

（Google Cloud パートナー）

アサヒグループホールディングス株式会社の導入事例 PDF はこちらをご覧ください。

その他の導入事例はこちらをご覧ください。

Apigee で GraphQL API を管理する方法

Fri, 17 Dec 2021 01:00:00 +0000

※この投稿は米国時間 2021 年 12 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

過去 20 年間、REST API は、組織のデータやバックエンドを外部、パートナー、内部のアプリケーションに公開するための、軽量で柔軟な標準ツールとして使用されてきました。Google Cloud の Apigee は API 管理におけるリーダーであり、レート制限の定義、認証と認可の実施、API を悪用しようとするクライアントのブロック、API の更新後のシームレスな動作などの REST API 管理を可能にします。

GraphQL は、デベロッパーにとって使いやすく柔軟な API を構築するためのパラダイムとして急速に普及しています。アプリケーションデベロッパーが必要とする情報を、バックエンドのデータソースに過不足ない形でリクエストできるからです。現在、REST と GraphQL のどちらも強力な API の選択肢となりえ、API プロバイダは、この次世代の API をどう構築、管理するかという課題に直面しています。今回の Apigee のリリースにより、REST と GraphQL の併用が簡単に行えるようになりました。デベロッパーはどちらかを選ぶ必要はありません。自身のスタックに GraphQL を追加し、同時に REST に対する既存の投資を活用することができるのです。

Apigee は既存の豊富なポリシーに加える形で、新しい GraphQL ポリシーを追加しました。このポリシーはトラフィックの管理やパフォーマンス改善、さらにはバックエンドサービスの変更やコードの記述を伴わないセキュリティの向上を実現するものです。GraphQL ポリシーを Apigee で作成したプロキシに追加することで、デベロッパーは GraphQL のクエリとレスポンスが特定のスキーマに準拠しているかどうかを検証できます。また、Apigee の標準的なプロキシの PreFlow でこのポリシーをチェーンさせることで、バックエンド API に対して、他の検証や管理機能を実行できます。

Apigee は、StepZen とパートナーを組み、こうした GraphQL の機能をお客様にお届けします。StepZen は、ローコードの構成要素と API 開発を高速化するコネクタを主力とした、組織向け GraphQL プロバイダです。このブログ記事では、StepZen で構築された GraphQL API を含むプロジェクト（GitHub からクローン可能）を使用して、ポリシーがどのように機能するかを説明します。

ハイレベルのアーキテクチャは、以下のようになっています。

シナリオの仕組み

私たちのシナリオは、e コマースのカスタマイズです。1 つの GraphQL エンドポイントが複数の API をまとめており、Apigee を介してプロキシされています。例えば、ユーザーの住む都市名と、3 米ドル相当の商品がそこの現地通貨でいくらになるかが表示される e コマースエクスペリエンスがあるとします。たったの数ステップで、複数の API を結合した単一の GraphQL エンドポイントにクエリを実行できます。GraphQL エンドポイントは Apigee GraphQL ポリシーによって保護されています。

Apigee の役割

Apigee は、クエリがスキーマに適合しているかどうかをチェックし、API キーが有効であることを確認し、GraphQL 呼び出しの分析情報を収集します。Apigee の API プロダクトと GraphQL のサポートを利用して、割り当てを追加したり、特定の GraphQL オペレーションへのアクセスを制限したりできます。

この簡単な設定では、単一の GraphQL スキーマを検証できます。さらに、 Apigee がサポートするフローを活用すれば、ユーザーごとに異なるバージョンのスキーマを利用することも可能です。クエリを許可したままで、スキーマへのリクエストを完全にブロックすることもできます。また、GraphQL エンドポイントへのアクセスをデベロッパーポータルで公開することで、セルフサービスで API を利用しているデベロッパーでも、新しいエンドポイントにアクセスするための一意の認証情報を登録し、取得できるようになります。

StepZen の役割

StepZen は、バックエンドでの GraphQL 呼び出しを実行します。具体的には以下を行います。

国、市町村、IP アドレスに基づいて割り出したユーザーの地域の現地通貨の情報を入手するため、api.ip-api.com を呼び出します。
最初の呼び出しで得られた通貨情報を使用して、通貨換算 API（api.frankfurter.com）から、現在の為替レートで該当する通貨に換算した商品の価格を取得します。

以下は、このシナリオに沿った GraphQL リクエストとレスポンスの例です。

GraphQL クエリ:

code_block: <ListValue: [StructValue([('code', '{\r\n location(ip: "8.8.8.8") {\r\n city\r\n continent\r\n country\r\n countryCode\r\n priceInCountry(amount:100 from:"EUR")\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f64bc58f0a0>)])]>

GraphQL のレスポンス:

code_block: <ListValue: [StructValue([('code', '{\r\n "data": {\r\n "location": {\r\n "city": "Ashburn",\r\n "continent": "North America",\r\n "country": "United States",\r\n "countryCode": "US",\r\n "priceInCountry": 114.44000000000001\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649ed4b6d0>)])]>

上記のクエリは、単一のリクエストで地域および通貨の情報を両方取得しています。2 つの REST API が呼び出され、適切なレスポンスが生成されます。StepZen スキーマは、通貨換算 API を使って、priceInCountry フィールドを地域のレスポンスに追加します。デベロッパーが自身で複数の API を組み合わせる必要はありません。取得したいフィールドを指定するだけで、それに適したレスポンスが作成されます。

StepZen と Apigee はどちらも管理 API を持っているため、StepZen のエンドポイントに Apigee プロキシを作成するプロセスを自動化することができます。そのためのオープンソースユーティリティもご用意しました。StepZen のアカウントをお持ちでない方には、ユーティリティでアカウントをプロビジョニングします。これにより、StepZen スキーマがデプロイされ、Apigee プロキシが自動的に構築されます。プロキシの呼び出しには API キーが必要となるように構成されており、GraphQL リクエストを StepZen のスキーマと照合して自動的に検証します。

環境の準備と運用

ご自身のアカウントにプロキシ、API プロダクト、デベロッパー、アプリ、プロパティセットの作成とデプロイに必要な Apigee 権限が付与されていることを確認してください。
git clone git@github.com:apigee/stepzen.git を実行してリポジトリをクローンします。
先ほどリポジトリをクローンしたディレクトリに移動し、以下のコマンドを実行します。
./apizenSetup -o <your_org> -e <your_env> -t $(gcloud auth print-access-token) -i $(gcloud auth print-identity-token) -z
このスクリプトでは、いくつかのオプションのパラメータを実行できますが（リポの README ファイルで説明されています）、デフォルトで指定する必要があるパラメータは次のとおりです。

-o <Apigee 設定に使用する組織名またはプロジェクト名>
-e <環境名>
-t <必要な Apigee アーティファクトのデプロイと作成にアクセスできる gcloud トークン>
-i <gcloud が生成した ID トークン>

StepZen はこれを利用して、一意の StepZen アカウントを 1 つ生成します。

-z

これはオプションですが、提供された場合、スクリプトは StepZen の認証情報を出力します。StepZen ツールを後で使う場合には便利です。

スクリプトはいくつかのステップを実行し、以下のように随時進捗状況を出力します。

StepZen のエンドポイントを呼び出し、StepZen アカウントの詳細を取得する。
StepZen の認証情報を保存する Apigee PropertySet を作成または更新する。
StepZen アカウントを下りターゲットとして事前に構成された Apigee API プロキシをデプロイする（上記で構成された PropertySet に依存）。
エンドポイントの保護のための認証情報を持つデベロッパー、API プロダクト、アプリを作成または更新する。

スクリプトが完了すると、curl コマンドの例（下記参照）が表示され、設定時に作成された API キーが表示されます。

上記のようにオプション "-z" を提供した場合、スクリプトは StepZen アカウント、管理者キー、API キーを出力します（これらの情報は書き留めておき、大切に保存してください）。これらの詳細を YAML として保存し（実際にも YAML として出力されます）、後で StepZen ツールで使用することができます。

エンドポイントのテスト

スクリプトが完了すると、次のような curl コマンドの例が表示されます。

code_block: <ListValue: [StructValue([('code', "curl -X POST 'https://<apigee_environment_host>/graphql/stepzample?apikey=<APIKEY>' \\\r\n-H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/json' -H 'Accept: application/json' \\\r\n --compressed -d @gql-query.json"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f478d00>)])]>

この curl コマンドは、上記の例で挙げたのと同じ GraphQL クエリを含む "gql-query.json" という名前のファイルを参照しています。この curl コマンドを実行すると、上記とまったく同じ出力が返されます。このファイルのクエリを更新したり、コピーして独自のクエリファイルを作成することも可能です。

API に Google マップを追加する

おまけとして、この API に Google マップを加えてみましょう。これにより、e コマースアプリでオンライン注文した商品を受け取ることができる最寄りの実店舗を表示できるようになります（これをもとに、配達と受け取りのどちらが簡単か判断することもできます）。

1. API キーを使って Google Maps API を StepZen から呼び出します。API キーを取得する手順: Google Maps Platform のスタートガイド

2. リポジトリにサンプルスキーマをご用意しています。StepZen Maps サンプルフォルダの config.yaml.sample ファイルの名前を config.yaml に変更してください。

3. config.yaml ファイルを編集して、<apikey> を自分のキーと入れ替えます。

code_block: <ListValue: [StructValue([('code', 'configurationset:\r\n - configuration:\r\n name: google-maps\r\n key: <apikey>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649f478580>)])]>

4. このスクリプトを新しい StepZen スキーマで実行します。スクリプトは、前回作成された StepZen アカウントを検出し、再利用します。

code_block: <ListValue: [StructValue([('code', './apizenSetup -o <your_org> -e <your_env> -t $(gcloud auth print-access-token) -i $(gcloud auth print-identity-token) -S stepzen-maps-example -m maps'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e16e850>)])]>

5. では、この新しい設定を、先ほどの curl コマンドでテストしてみましょう。

今回は、stepzen-maps-example ディレクトリに保存された GraphQL クエリを指定します。新しい curl コマンドは以下のようになります（もちろん、エンドポイントの API キーとホスト名はご自身のものに更新してください）。

code_block: <ListValue: [StructValue([('code', "curl -X POST 'https://<apigee_environment_host>/graphql/stepzample?apikey=<APIKEY>' \\\r\n-H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/json' -H 'Accept: application/json' \\\r\n --compressed -d @stepzen-maps-example-gql-query.json"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e16ec70>)])]>

今回実行するクエリは以下のようなものです。

code_block: <ListValue: [StructValue([('code', 'query MyQuery {\r\n\t\tlocation(ip: "8.8.8.8") {\r\n\t\t\tfindNearby(keyword: "Target") {\r\n\t\t\t\tname\r\n\t\t\t\tvicinity\r\n\t\t\t}\r\n\t\t\tcity\r\n\t\t\tcountryCode\r\n\t\t\tregionName\r\n\t\t}\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f649e16e4c0>)])]>

クエリの実行内容

このクエリでは、Google DNS の最初のロケーションクエリで返された IP の緯度 / 経度に対して、最も近いターゲット地域が検索されます。

この情報は、最初の検索結果で解決された緯度および経度として、埋め込まれた findNearby に渡されます。StepZen は、スキーマの構成時に提供された Google Maps API とキーを使用します。

これを api-ip-api.com のクエリ機能と組み合わせることで、単一の GraphQL クエリでターゲットストアに最も近い実店舗を取得でき、エクスペリエンスを向上させることができます（今回はこの店舗での受け取りを想定していますが、他の店舗でもお試しください）。

次のステップ

Apigee ポリシーや StepZen GraphGL エンドポイントの構築と実行に関して詳しくは、以下の関連資料をご覧ください。

Apigee の GraphQL 対応のお知らせ- Apigee で GraphQL API を管理する方法
Apigee GraphQL ポリシー - GraphQL の使用 | Apigee X
StepZen のスタートガイド（英語） - https://stepzen.com/docs/quick-start
GraphQL スキーマの設計（英語）https://stepzen.com/docs/design-a-graphql-schema

- Google Cloud プロダクトマネージャー、Geir Sjurseth

- StepZen デベロッパー、Carlos Eberhardt

Google が 2021 年 Gartner® Magic Quadrant® でフルライフサイクル API 管理のリーダーに選出

Fri, 08 Oct 2021 04:00:00 +0000

※この投稿は米国時間 2021 年 10 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

Gartner は 2021 年のフルライフサイクル API 管理のマジッククアドラントで、Google Cloud の Apigee を 6 年連続でフルライフサイクル API 管理のリーダーとして認定しました。この成果は、Google Cloud の API 管理に関する差別化されたビジョンと、継続的なプロダクトのイノベーションを提供してきた優れた実績を証明するものだと考えています。今回のレポートでは、Apigee は実行能力において、あらゆるベンダーの中で最高位を獲得しています。この場をお借りして、お客様、デベロッパー、パートナーの皆様からのご意見をお寄せいただいたことに感謝いたします。

API は、企業がデジタルファースト戦略を実現するための重要な仕組みの一つであり、パートナーやお客様に新しい体験やアプリケーションを提供します。これらの API を効率的かつスケーラブルに活用するためには、API 管理が必須であり、適切な API 管理ベンダーと提携することが、API プログラムの構築とスケーリングの成功には不可欠です。また、Gartner などの業界アナリスト企業が実施する調査は、企業が適切なソリューションを評価、選択する際に役立ちます。

Nationwide Insurance、ABN Amro、Bed Bath & Beyond、Pizza Hut などの多くの企業のお客様が、API 管理のパートナーとして Google Cloud の Apigee を選択しています。Google の使命は、お客様が デジタルエクセレンスへと飛躍するのを支援することです。デジタルエクセレンスとは、迅速かつ反復的にデプロイし、スケーリングし、デジタルプログラムを一貫して提供する能力のことです。Google は、お客様が収益性の高い API ベースのプラットフォームを構築し、測定可能なビジネス上の成果を実現するお手伝いをしたいと考えています。

「API により、Veolia は新たな革新の機会をもたらす、新たなエコシステムとパートナーにアクセスできるようになりました。Apigee のおかげで、優れたカスタマーエクスペリエンスを迅速かつ簡単に提供できています。また、バックエンド IT の複雑さが取り除かれ、一貫性と安全性のもと、顧客に情報とデータを素早く提供できるようになりました。」と Veolia の CTO である Pascal Dalla-Torre 氏は語っています。

このビジョンの一環として、Google Cloud は継続的なイノベーションの実現に注力しています。

ハイパースケールの実現 - API を使用した世界規模でのスケーリング、分散した従業員間の接続、地域のパートナーとのコラボレーションを支援するため、今年に入って Apigee X を発表しました。これは、Google Cloud が持つ AI、セキュリティ、ネットワークに関する専門知識をシームレスに融合させた API 管理プラットフォームのメジャーリリースで、デジタルトランスフォーメーションの取り組みを構築する基盤となるアセットを企業が効率的に管理できるよう支援します。
デベロッパーの効率化 - 今日のデベロッパーは、API やインテグレーションのニーズに対応するために複数のツールを使用しています。さらに、新しい API スタイルやソフトウェア開発ツールの普及が複雑さに拍車をかけています。そのため、先日、Google は API とインテグレーションのニーズに対応した統合プラットフォーム Apigee Integration、マイクロサービスのニーズに対応した Apigee Adapter for Envoy、GraphQL などの新しい API スタイルのサポート、既存の SDLC ツールを使って API を管理できる柔軟性、会話型 AI 向けのフルフィルメントソリューションを発表しました。
アプリケーション開発の自由度の向上 - 業界を問わず、IT チーム外の技術に精通した従業員が、AppSheet のようなコード不要の開発ツールを使って社内アプリケーションを構築するケースが増えています。API 管理への投資をこれらの技術に精通した従業員にまで拡大できるよう、Apigee と AppSheet のプラットフォーム間のインテグレーションへの投資を続けています。
API のための AIOps - デジタルエクセレンス戦略では、API が中心となり、お客様や従業員向けのさまざまなアプリケーションを接続するための中枢神経系として機能します。そのため、API が常に利用可能で、期待通りに機能することがきわめて重要です。ハイパースケール API プログラムのモニタリングに関する課題を克服するために、Google は、業界をリードする Google の機械学習機能を利用して、異常検出などの機能を API オペレータに提供しています。
業界に特化したソリューション - 新しいデジタルプログラムの市場投入までの時間を短縮し、特定の業界の要件に対応するために、オープンバンキング、Health APIx、e コマースのモダナイゼーション、通信事業者向けの Contact Center AI フルフィルメントといった、各業界における API の導入を加速する一連の機能を提供しています。

このたび、光栄にも 2021 年 Gartner マジッククアドラントのフルライフサイクル管理のリーダーに選出されたことをお知らせさせていただきました。今後もパートナーとして、お客様のデジタルトランスフォーメーションの実現に向けて革新的な取り組みを続けていければと考えています。レポートの全文は、こちらからダウンロードできます（メールアドレスが必要です）。Apigee について詳しくは、こちらのウェブサイトをご覧ください。

^{Gartner Magic Quadrant for Full Life Cycle API Management、2021 年 9 月 28 日、Shameen Pillai、飯島公彦、Mark O'Neill、John Santoro、Akash Jain、Fintan Ryan}

^{Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、プロダクト、サービスを推奨することはありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言することもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ＆アドバイザリ組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、商品性や特定の目的への適合性を含め、本リサーチに関連したいかなる保証も行いません。}

^{上の図は、リサーチドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Google（Apigee）までご請求ください。}

- Google Cloud ビジネスアプリケーションプラットフォーム、プロダクト担当責任者、Vikas Anand

Arab Bank: Anthos と Apigee を使ってアプリケーションのイノベーションを促進

Mon, 28 Jun 2021 10:00:00 +0000

※この投稿は米国時間 2021 年 6 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

1930 年に創業し、ヨルダンに本部を置く Arab Bank は、中東で最も古くからある銀行の一つです。世界の 28 か国に支店をもち、その堅実な運営方針と、各地域の文化および習慣を尊重する姿勢によって、お客様の信頼を獲得しています。

中東および北アフリカ諸国では、クラウドプロバイダがデータセンターを設置済みの一部地域を除き、銀行業界におけるクラウド技術の導入が全体的に遅れています。その背景には、クラウドサービス（PaaS および SaaS）のデータセキュリティ、成熟度、セキュリティ管理に対する懸念があること、さらに、規制の存在があります。こうした状況の中でも、当行はこれまでいくつかの好機に恵まれ、クラウドを活用して開発やテストの期間を短縮させたり、フィンテックコミュニティやデジタルサービスプロバイダと連携して各社のソリューションをバンキングエコシステムに組み込んだりするなどの成果をあげてきました。このようにフィンテック業界の力を借り、社内のイノベーションを促進、スピードアップするためには、外の世界と柔軟につながることができるオープンなアーキテクチャが必要となります。当行は、Google Cloud と連携することでこの目標を達成し、Apigee や Anthos などのプラットフォームを活用してアプリの開発、テストのプロセスをスピードアップすることができました。その結果、顧客や従業員に対して最新技術を用いた革新的アプリやサービスを提供できるようになり、アジリティおよび柔軟性の促進や、ワークロードの最適化につながっています。

規制の厳しい業界にクラウドを取り入れる

まずは、社内のリーダーやスタッフに、クラウド技術や、API レイヤ、コンテナといった概念およびそれらがもたらすメリットについて理解してもらう必要がありました。Google の力を借りて、オープンテクノロジーに関するデモセッションや討論会を催すなどして社内教育を進め、主な関係部門の賛同を得られるよう努めました。クラウドプロバイダの候補選びで重視した点は 4 つあります。それは、セキュリティ管理の成熟度、使いやすさ、コスト、さらに、新しい環境への導入や技術の進化に対応できるスケーラビリティやアジリティを備えているかどうか、という点です。特にこのスケーラビリティを重視していた私たちにとって、Google Cloud のイノベーションロードマップは非常に魅力的でした。Google の担当者との直々の打ち合わせはもちろん、Google Cloud Next のカンファレンスで、技術やイノベーション、新しいものづくりに情熱を傾ける人々と出会えたことも、私たちの判断に大きく影響しました。

当行でのクラウド導入の道のりに話を戻しましょう。前述のように、地域特有の制限があるという理由から、私たちはハイブリッドクラウド方式を採用し、これを発展させていくことにしました。この方法なら、本番環境で提供中の多数のサービス、中でも個人情報（PII）やその他の機密データを扱うようなサービスの運用をオンプレミスで継続する一方で、開発およびテストや、本番環境の一部のワークロード（顧客データを含まないもの）には、クラウドを活用することが可能となります。

当地域の適用法令が近いうちに大幅改定され、他国へのデータ転送が許可されるようになる見込みは低そうです。今の状況が続いても、クラウドツールがあれば、顧客データをトークン化および匿名化して利用しながら、データの保守はオンプレミスで行えます。このような運用方法は、オンラインで提供している各種サービス（顧客のオンボーディングや、クレジット機能のオンライン申請、マーケットプレイスでの操作など）にも適用されます。今後、パートナー各社と API 統合を進めることにより、当行の価値提案をデジタル化という観点から総合的に充実、促進させて、主な顧客であるコンシューマーバンキングの利用者はもとより、中小規模ビジネス、大企業、その他法人のお客様に対してアピールできると考えています。

クラウドでつながりと基盤をつくる

デジタルトランスフォーメーションにおいて最初に着手したのは、Google Cloud の API 管理プラットフォームである Apigee を導入し、世界中のデジタルバンキングエコシステムとつながることでした。Apigee では、セキュリティ、共有、メディエーションに関するポリシーのほか、デベロッパーポータル機能も提供されているため、オープンバンキングの標準を満たしつつ、イノベーションに専念できました。

Apigee の導入を進める一方で、フィンテックの新しいアイデアを促進する場としてアクセラレータプログラムを始動し、当行のデジタルプラットフォームにこれらのアイデアを取り入れて顧客に提供できるようにしました。さらに、各種バンキング API も開発しました。これらはすべて、PSD2 およびオープンバンキングの規制に従って設計、文書化され、パートナー各社に提供されています。フィンテック企業のクリエイティブなソリューションの設計に活用していただけるよう、これらの API はコード構造の要件とともに当行の API 開発ポータルで公開されています。

次に着手したのは、Google Cloud のマネージドアプリケーションプラットフォームである Anthos の導入です。Anthos はハイブリッドクラウドに対応しているので、これを運用の基盤として、マイクロサービスコンテナの統合や外部機関との連携を進めました。現在、Anthos のインフラストラクチャ上には数百のマイクロサービスが展開され、これらが Google Kubernetes Engine（GKE）のコンテナやオンプレミスで実行されています。コラボレーションや、開発、テストにはクラウドを、本番環境にはオンプレミスをという使い分けをしています。

クラウドのセットアッププロセス全体や、Anthos の導入にあたっては、Google Cloud の Professional Services Organization（PSO）の力を借りました。最初は、クラウドツールを利用し、試行錯誤を繰り返しながら学んでいきました。Anthos の仕組みについて理解を深めた今では、Arab Bank の目指すデジタルファースト化およびそれに伴うスケーリングのしやすさを重視しながら、健全性、安定性、復元力を兼ね備えた基盤の上に、新たなインフラストラクチャを構築しています。

現在、Anthos で実行しているサービスは、顧客獲得およびオンボーディング用のモバイルアプリのほか、お客様が WhatsApp などのメッセージングプラットフォームを使って瞬時に金銭をやり取りできるようにする Arabi-Pay アプリがあります。さらに、Arab Bank の従業員を対象に、Anthos を活用した即日融資サービスも提供しており、7 分未満で最大 $7,000 の貸し付けが可能です。

中小企業（SME）のお客様向けにも、SME クライアント向けデジタルオンボーディングプロセスや、ペーパーレスの SME 融資プラットフォームを整備するなど、各種デジタルサービスを構築しました。

当地域ではお客様との直接の関わりを重視する習慣があることから、デジタル化が遅れていると思われがちです。しかし、最近の COVID-19（新型コロナウイルス感染症）のパンデミックによって、デジタルバンキングサービスや電子決済の導入が進み、オンラインでの購入や支払いに対して前向きな気風が広がっています。Apigee や Anthos を基盤とした当行のバンキングアプリは、お客様の主要な手続きを想定し、幅広い機能を備えているうえに非常に使いやすいのが特長で、新規のお客様の 90% 以上がこれらのモバイルアプリを活用してくださっています。今後 18 か月で利用率はさらに上昇し、100% に近付くと予想しています。

もちろん、こうした利用率の上昇は、サービス障害のリスクと表裏一体です。ほんの一瞬ダウンタイムが発生しただけでも、多くのユーザーがその問題に遭遇する可能性があります。Google Cloud の Anthos および Apigee の場合、プロセスを迅速に再開できるので、たとえ障害が発生したとしても、ユーザーにほとんど気付かれずに済みます。COVID-19 のパンデミックが始まった当初は、各支店の営業時間短縮を余儀なくされましたが、それをきっかけに一般のお客様を中心にデジタルサービスの活用が進み、各種手続きを自己完結していただくことができました。さらに、Google Cloud のおかげで、社内チームおよび外部パートナーが常につながりながら生産性を維持できるといったメリットも生まれています。Google Cloud なしでは、デジタルトランスフォーメーションを理想的なペースで続けることは困難だったでしょう。

国境やタイムゾーンを超えた連携

Google Cloud のおかげで、社内での共同作業やパートナーとの連携のあり方が大きく変わりました。デベロッパーが世界中の地域やタイムゾーンに散らばっていることを活かし、24 時間年中無休の運営体制を確立しています。テストや開発作業を週末も含めて絶え間なく継続できるので、現在、新しいデジタルサービスを数週間というかつてない速さでデプロイすることができています。これにより、イノベーション優先という高い意識が社内に生まれ、運営モデルのレベルアップにつながりました。

Google Cloud のツールを取り入れるにあたってもう一つ重視したのは、ソフトウェア開発ライフサイクルで発生しがちな非効率なプロセスを排除することです。現在では、設計担当の小規模チームから、本番環境での導入作業に至るまで、完全にアジャイルな方法でソフトウェアを構築しています。2 年前は、本番環境にリリースできるシステムの数が 1 年間で多くても 2 つまでだったのに対し、現在は、デジタルパッケージをほぼ 1 か月に 1 つのペースでリリースしています。さらに、こうした毎月のリリースの合間に、臨時や修正のリリースも行っています。各部門がバラバラに機能していた状態から脱却し、製品、営業、運用、IT Dev Factory、インフラストラクチャ、サポートに至るまでの各部門間の連携が大幅に向上しました。

API によってアジャイルなプロセスを促進するのと並行して、デザイン思考のワークショップを開催して早い段階で外部のお客様や見込み客に参加してもらうようにしています。それにより、お客様の真の悩みや、既存の方式に対する考え方について理解を深め、新しいデジタル方式にできるだけスムーズに移行する方法を探るのが狙いです。こうした取り組みの結果、以前に比べて格段に的確性の増した製品やサービスをそれぞれのお客様に提供できるようになっています。

バンキングにとどまらないサービス

Google Cloud のおかげで、バンキングにとどまらず、お客様の生活に密着した幅広いオンラインサービスを展開できるようになっています。たとえば、最近リリースした住宅ローンアプリでは、家選びから、ローンの交渉および締結、さらには家のデコレーションの手配にまで対応するサービスを提供しています。このような総合的サービスを成功させる決め手となったのが、地域の主要企業との API を通じた連携です。

その他のデジタルサービスについても、顧客層や年齢に応じて生活に密着したソリューションを提供できるよう、詳細なロードマップを用意しています。サービスのデジタル化への取り組みはまだまだ始まったばかりですが、今後もクラウドを使って、あらゆる目標を実現していく所存です。

詳細については、Google Cloud のオープンバンキングソリューションをご覧ください。PSD2 の要件に従いながら、オープンバンキングの提供プロセスを簡易化、促進する方法を解説しています。Open banking, powered by Apigee API management（オープンバンキング: Apigee API 管理を活用）と題した動画も合わせてご覧ください。

-Arab Bank 最高執行責任者 Eric Modave

AI による API オペレーション簡素化で API プログラムのスケーリングをスムーズに

Wed, 09 Jun 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 5 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

API はデジタルトランスフォーメーションの根幹です。API を使用すると、組織の境界の内外でデータと機能をデベロッパーと安全に共有し、アプリケーションをより迅速に構築できます。また、パートナーとシームレスにつながってやり取りできるため、新しいビジネス収益を促進することも可能です。

API の使用範囲にはビジネスクリティカルな情報も含まれるため、ダウンタイムやパフォーマンスの低下により、収益、顧客、ブランド価値が大幅に減少する可能性があります。そのため、API の可用性を維持し、期待どおりに機能させるという責任がオペレーションチームに重くのしかかるようになりました。API がダウンすると、顧客エクスペリエンスを促進するサービスもダウンします。こうしたサービスは、組織におけるコラボレーションとビジネスプロセスに利用されています。

しかし、API プログラムをビルドしてスケーリングするなか、API オペレーターがすべての API を手動でモニタリングして管理することは事実上不可能になってきます。これを解決するために、Google Cloud は API 管理プラットフォームのメジャーリリースである Apigee X を介して、業界をリードする AI と ML テクノロジーの力を API オペレーションに導入しました。Apigee X は、AI、セキュリティ、ネットワーキングに関する Google Cloud の専門知識をシームレスに組み合わせて、大規模な API を効率的にビルドして管理できるようにします。

API データを実際に活用する

Apigee は機械学習を API メタデータに適用し、API オペレーションのさまざまな側面を簡素化するために必要なツールを提供します。API での AI 利用の好例として、以下のような異常検出が挙げられます。

AI を活用したルール: 事前定義された一連の条件に基づいてアラートをトリガーします。これらの条件は、業界をリードする Google の機械学習モデルを過去の API データに適用することによって決まります。
自動しきい値: API のモニタリング基準を調整し、パターンベースの値に設定します。
オーバーヘッド削減: オペレーターが異常を手動でモニタリングしたり、API のモニタリングしきい値を調整したりする必要性がなくなります。

「過去の API データに AI モデルと ML モデルを適用したこれらの高度な機能は、私たちが考えもしなかったシナリオについて警告してくれます。このような自動化機能により、事前の作業を大幅に削減できます。セキュリティ面においても、行動につながるインサイトを得ることで、プロキシが安全な HTTPS ポートを介してのみ公開され、コンプライアンス要件を遵守した状態であることを確認できるようになりました。また、ユーザーアクションを綿密にモニタリングし、監査の際にレポートをすばやく抽出することもできます。」- Citrix 社グローバルテクノロジー＆セキュリティ担当シニアマネージャー Adam Brancato 氏

Google Cloud のお客様は API プログラムをスケーリングする際に、AI を活用した機能が非常に役立つと実感しています。Google Cloud で最近発表された State of the API Economy 2021 レポートでは、企業における異常検出、bot 防止、セキュリティ分析機能の使用量が 230% 増加していることが明らかにされています。

Apigee X の詳細と、AI と機械学習の活用例を確認するには、こちらの動画をご覧ください。Apigee X を無料で試すには、こちらをクリックしてください。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

DueDil が Apigee API 優先のアプローチを活用して大規模なデータ分析を提供している方法

Thu, 03 Jun 2021 03:00:00 +0000

※この投稿は米国時間 2021 年 5 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

名前が示すように、DueDil はデューデリジェンスサービスを提供します。大手金融サービス企業 / 成長著しいテクノロジー関連企業 / 保険会社を対象に提供する DueDil のサービス範囲は、顧客固有のリスクの評価と選択から、顧客オンボーディングおよびリアルタイムリスクモニタリングまで、多岐にわたります。2009 年に設立された DueDil は、400 を超えるクライアントの 3,000 人超の企業ユーザーを支援しており、これらユーザーがそれぞれの取引相手をただ理解するだけでなく、規制要件を遵守したうえでより効率的に把握できるようサポートしています。

デューデリジェンスサービスは近年発展を遂げてきました。それを支えているのは、新しい規制と新しいテクノロジーです。旧来のシステムやプロセスの多くが最近まで、ペンと紙によるワークフローや、労力のかかるスプレッドシート作業に依存してきましたが、今や新たな規制とテクノロジーの双方によって、それが置き換えられています。DueDil では、このテクノロジー変革によって、手作業のプロセスを自動化に置き換える機会が生まれたことを認識したうえで、同時にもう一つの新たな機会にも着目しました。それは、データを単に処理するだけでなく、異なる IT システムの情報をつないでデータドリブンの分析情報を生成し大規模に提供することによって、データを有効化する機会です。

この機会を活用するため、DueDil は、企業間の約 3 億の接続をマッピングするプラットフォーム、Business Information Graph（B.I.G）を構築しました。数十億ものデータポイントを取り込み、1 日に数回更新される B.I.G では、不正行為のリスクなど、ビジネス上の関係について固有の分析情報が提供されます。B.I.G. の有効性はその結果からも一目瞭然です。DueDil の顧客の中では、パートナーのオンボーディングが最大 80% 迅速化し、リスク検証のスピードが最大 18 倍増し、手作業でのポートフォリオチェックに要していた時間を最大 80% 削減するなどの成果が出ています。

このような変革すべてを生み出すパワーの源はどこにあるのでしょうか？その答えは、アプリケーションプログラミングインターフェース（API）にあります。

「市場展開の観点から言えば、当社の製品は API です」と、DueDil の COO、Denis Dorval 氏は最近行われたウェブキャストで述べ、顧客が B.I.G. のリソースを直接自分で活用し、それをベースに DueDil の API で独自のニーズに合わせたビルドができることを説明していました。

迅速、安全、スケーラブルな API を提供する API 管理プラットフォームの選択

DueDil では、より優れた分析情報と効率性アップにつながる B2B エコシステムを接続するという同社のビジョンを実現するために、いくつかの明確な基準を満たすことのできるクラウドプロバイダを探しました。当時 DueDil が必要としていたのは、社内デベロッパーが数種類のシステムを活用して新たなユースケースやプロセス自動化を実現するための API と、顧客に提供する製品化された API のためのロバストな管理システムでした。数十億ものデータポイントを高速処理する高度な分析と豊富な処理力に加え、そのすべてを支えるエンタープライズクラスのセキュリティ、スケーラビリティ、アジリティが必要でした。また同社では、プロバイダの切り替えに伴ってユーザーエクスペリエンスが損なわれてしまうことを避けるため、円滑な移行を優先課題としていました。

DueDil のエンジニアリングマネージャーである Robert Cicero 氏は、次のように述べています。「Google Cloud の Apigee API 管理プラットフォームの安定感と、そのサービスの力強さは、際立っていました。」

また、「Apigee は回復力の高いアジャイルなプラットフォームで、API を迅速、安全、大規模にビルドするという当社のニーズを満たしています」と説明し、Apigee の API セキュリティ防御ツールおよびポリシーの多くが追加設定なしですぐに利用できることを評価しました。たとえば、Apigee の JSON 脅威検出ポリシー、カスタムポリシー、認証 / 認可プロセスは、瞬時にデプロイできるため、レイテンシを最小限に抑えることができます。つまり DueDil では、セキュリティ上の脅威がネットワークに侵入する前にそれを阻止しながら、サービス遅延のリスクを回避できるようになりました。

現在、DueDil には、ビジネスデューデリジェンスを推進する社内サービスが 5 つあり、すべて Apigee 経由で公開されています。また、Apigee の収益化機能も使用して、API の利用を後押ししています。しかし、DueDil の市場展開戦略はペースが速くクライアント重視であるため、同社が Apigee を使用する最大の目的は、クライアント向けに API を迅速にプロトタイピングして、特定の API の表示と動作の把握を可能とすることにあります。これにより、DueDil とそのパートナーや顧客は、バックエンドシステムの構築に時間を取られることなく、分析情報から価値を生み出すことにより多くの時間を割くことができます。

また、Apigee によって、BigQuery、Google データポータル、Google Cloud Storage といった他の Google Cloud サービスとも、簡単に接続できるようになります。Apigee はシステムの中枢神経の役割を果たし、システムを接続してプロセスを自動化する機能だけでなく、パートナーと顧客による B.I.G. サービスの使用状況に関する分析情報と可視性を DueDil に提供します。

Cicero 氏はさらにこう付け加えています。「Apigee への移行はシームレスで、API 管理プロバイダを Apigee に切り替えたことを誰にも気づかれませんでした。それが最大のメリットであったのは間違いありません。」

API を活用して、セキュリティおよびガバナンスのポリシーを適用しながらセルフサービスを提供

今後に向けて DueDil は、Apigee を活用して、スタッフとクライアントにより多くの権限、可視性、機会を提供し、IT 部門に頼ったり長い承認プロセスを延々と待ったりすることなくセルフサービス方式でアプリを作成し編集できるようにする計画を立てています。API を利用して B.I.G. やその他の機能を会社全体でより多くのチームに公開することで、DueDil では、動きをさらに速めてイノベーションプロセスに関与する人材を増やすことが可能になるでしょう。Apigee API 管理機能を活用している DueDil は、Cloud Functions、Cloud Pub/Sub など、その他の Google Cloud プロダクトおよびサービスも詳しく調べて試してみる意向です。

Cicero 氏は次のように述べています。「最終的には、企業がデューデリジェンスに取り組むやり方は、会社ごとに若干異なっています。DueDil にとっては、多様化したビジネスに対して構成可能かつ動的な環境を提供できる唯一の方法は、順応性のあるプラットフォームを使用するか否かにかかっています。Apigee により、DueDil はさまざまな企業のためにサービスを創造し提供するうえで必要となるアジリティを手に入れることができました。」

Google Cloud は現在、銀行、資本市場、保険、決済のあらゆる場面で世界的に利用されており、困難な課題の解決に役立っています。優れた可視性、管理性でどこからでも API を設計、保護、分析、スケールできる Google Cloud Apigee API 管理についての詳細は、こちらをクリックしてください。Apigee API 管理を無料で試すには、こちらをクリックしてください。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

Google Cloud で脅威や不正行為からのウェブアプリと API の保護を強化する

Fri, 07 May 2021 13:00:00 +0000

※この投稿は米国時間 2021 年 4 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

企業が顧客やパートナーと接するうえでウェブアプリケーションと公開 API の重要度が高まる中、多くの企業がこれらの資産を保護するための専用ツールに注目しています。調査会社の Gartner は、2020 年のレポート「Defining Cloud Web Application and API Protection Services（クラウドウェブアプリケーションおよび API 保護サービスの概要）」の中で、次のように述べています。「2023 年までに、公開されているウェブアプリケーションの 30% 以上が DDoS 対策、ボット対策、API 保護、ウェブアプリケーションファイアウォール（WAF）を組み合わせたクラウドウェブアプリケーション API 保護（WAAP）サービスによって保護されるようになる。なお、現在この数字は 10% 未満である。」1 現在、これらのサービスのほとんどは、脅威の種類に応じて異なるポイントソリューションの形で提供されています。そのため、保護機能に差が生じ、サービスの取得費用と運用費用が増大しています。

このような課題に対処するため、Google Cloud は、ウェブアプリケーションと API を包括的に脅威から保護するセキュリティソリューション「ウェブアプリ API 保護（WAAP）」を発表しました。

Google Cloud WAAP は、Google が自社の公開サービスをウェブアプリケーションの悪用、DDoS 攻撃、不正なボット活動、API を標的とした脅威から保護するために使用しているのと同じ技術を基盤としたサービスです。WAAP は、サイロ化されたアプリケーション保護から統合されたアプリケーション保護への移行を象徴しています。WAAP を使用すれば、脅威対策の強化、運用効率の向上、公開設定とテレメトリーの統合を実現できます。また、クラウドとオンプレミス環境をまたいだ保護も実現できます。

Google Cloud WAAP は、3 つの主要プロダクトを組み合わせて、脅威と不正行為に対する包括的な保護を実現します。

Google Cloud Armor は、Google Cloud が世界に展開する負荷分散インフラストラクチャの一部であり、WAF と DDoS 攻撃対策機能を備えています。Open Web Application Security Project（OWASP）のトップ 10、高度なアプリケーション悪用、ボリューム型攻撃と第 7 層 DDoS 攻撃の両方からアプリケーションを保護します。

Google Cloud の API 管理プラットフォームである Apigee は、セキュリティに重点を置いた API ライフサイクル管理機能を提供します。Apigee は、API キーの検証、OAuth アクセストークンの生成と検証、トラフィックのレート制限、クォータの適用、API トレンドの分析を行います。

reCAPTCHA Enterprise は、不正行為、スパム、さらにスクレイピング、認証情報の読み取り、自動アカウント作成、自動ボットの悪用などの不正行為から、透過的にユーザーを保護します。

Google Cloud WAAP ソリューションのアーキテクチャの概要

SADA Systems の CTO である Miles Ward 氏は、次のように述べています。「当社のお客様は、Google Cloud WAAP の各プロダクトからすでに大きな恩恵を受けています。プロダクトがパッケージ化されたため、今後はより包括的なセキュリティソリューションを、より幅広い客層に、より迅速に届けることができるでしょう。SADA は、Google と提携して、お客様のミッションクリティカルなプロジェクトにこの優れたセキュリティソリューションを導入できることをうれしく思います。」

WAAP がお客様にどのように役立っているか

次に、2 つのシナリオを通して、セキュリティ上の高度な要求に対処するため、銀行や航空会社が Google Cloud の WAAP ソリューションをどのように活用しているのかをご紹介しましょう。

セキュリティ要件と使いやすさのバランスを取る

ある銀行がマイクロサービスを基盤とした決済アプリを新しくリリースしようとしています。アプリケーションのアーキテクチャの要件により、公開している複数の API に保護対策が必要です。このアプリに関係する部門が 3 つあり、各部門ごとに優先事項が異なるため、複数の優先事項の間でバランスを取る必要があります。

この場合、Google Cloud の WAAP ソリューションを使用すれば、銀行の複数のチームが密接に協力することで、1 つのソリューションと 1 社のベンダーだけを使用して全部門の要件を満たすことができます。

OWASP トップ 10 ウェブアプリケーションセキュリティリスクの管理

ある航空会社で、自社の予約サイトを OWASP トップ 10 ウェブアプリケーションセキュリティリスクから保護しなければならなくなりました。漏洩した、または盗まれたメールアドレスとパスワードを使用した、攻撃者によるアクセス権の不正取得（認証情報読み取り）を防ぐことが優先事項となりました。この航空会社の API は、サードパーティ旅行サイトが予約のために使用しているため、航空会社は公開 API の認証と認可も管理できる必要があります。

この航空会社では、Google Cloud の WAAP ソリューションを採用しており、WAF として Cloud Armor、API 管理層として Apigee、認証情報読み取り対策として reCAPTCHA Enterprise を使用しています。

Google Cloud WAAP ソリューションのワークフロー

Google Cloud WAAP ソリューションを使用したこのリクエストのワークフローを見てみましょう。

WAAP ソリューションの最初の窓口は Cloud Armor です。Cloud Armor は、クロスサイトスクリプティング（XSS）、SQL インジェクション（SQLi）などの OWASP トップ 10 の脆弱性を保護し、さらに第 3 層、第 4 層、第 7 層の DDoS 攻撃からの保護も行います。
Cloud Armor ポリシーに対し上記のルールがいずれも適用されなかった場合、reCAPTCHA Enterprise API にリクエストが送信され、受信トラフィックが正当なリクエストであるかどうか（機械のボットによるものか人間によるものか）が評価されます。正当なリクエストであれば、そのリクエストが航空会社のバックエンドに転送されます。正当なリクエストではない場合は、Cloud Armor が 403 レスポンスコードをユーザーに送信することで、リクエストを拒否できます。さらに Cloud Armor は、別のページにリダイレクト、リクエストをハニーポットに転送するなど、より高度な対策を取ることができます。
どの API リクエストも、Cloud Armor の OWASP ルールと DDoS 対策の評価が完了すると、有効性を確認するため Apigee に転送されます。Apigee は、リクエストで使用された API キーやアクセストークンが有効かどうか、また消費者に API へのアクセス権があるかどうかを判断します。リクエストが正当なものではないと判断した場合、Apigee は 403 レスポンスコードをエンドユーザーに送信でき、それ以外の場合はリクエストを航空会社のバックエンドに転送します。

WAAP ソリューションは、航空会社の予約サイトに寄せられるすべてのリクエストに対する最初の窓口となり、リクエストが航空会社のバックエンドに到達する前に水際で不正行為者を検知し、その影響を軽減します。

デジタルトランスフォーメーションを加速させる組織が増え、ビジネスプロセスや商取引のデジタルでのやり取りへの依存度が高まるにつれ、高度なセキュリティと保護の必要性もますます増大しています。Google Cloud の WAAP ソリューションのような統合型アプリケーション保護サービスに移行すれば、組織は、脅威の防止能力の改善、運用効率の向上、公開設定とテレメトリーの統合を、圧倒的な速さで実現できます。

今すぐ WAAP を使ってみる

Google Cloud によるウェブアプリと API の包括的な保護の詳細については、WAAP ソリューションページをご覧ください。また、アプリのモダナイゼーションと保護に関するオンデマンドウェブセミナーをご覧いただき、Enterprise Strategy Group が執筆した、最新のウェブアプリケーションのセキュリティ対策の課題への WAAP を利用した対処に関するホワイトペーパーをお読みください。

^{1. Gartner, Defining Cloud Web Application and API Protection Services, Jeremy D'Hoinne and Adam Hils 2020 年 5 月 20 日更新。}

-セキュリティおよびコンプライアンス担当スペシャリスト Varsha Datta

-Google Cloud セキュリティプラクティスリード Ann Wallace

GraphQL: API コンシューマ向けの一貫したアプローチの構築

Thu, 15 Apr 2021 01:00:00 +0000

※この投稿は米国時間 2021 年 4 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

新しいモバイルアプリやウェブアプリを開発する際にはアプリケーションプログラミングインターフェース（API）を使用してデータや機能を組み合わせますが、API の操作については通常 REST と GraphQL という 2 つの一般的な選択肢のどちらかを選ぶことになります。

この記事では、両者のアプローチを比較し、GraphQL API の利用者にとって一貫性のあるエクスペリエンスを構築するために利用できる REST API のベストプラクティスをご紹介します。これらはどちらかが他方よりも優れているというものではなく、同じプロジェクトでなくても同じチーム内で両方を使用できます。ただし、プロジェクトでどのような API を使用するかとは別に、一貫性のあるエクスペリエンスを提供できれば、業務の効率化と高速化につながります。

REST と GraphQL の比較

REST は API が準拠するソフトウェアアーキテクチャスタイルであり、開発者は標準的な方法でサービスを操作できます。GraphQL は API 用のクエリ言語で、こうしたクエリを実行するためのランタイムです。REST と GraphQL は、リソースを URL として識別してアプリがデータや機能を取得できるという点で似ていますが、多くの違いがあります。

GraphQL は 1 つのエンドポイントでデータを交換しますが、REST の場合は複数のエンドポイントが関わってくることが少なくありません。GraphQL リゾルバはフィールドに対してデータを取得します。また、失敗したリゾルバがあっても残りのクエリが有用なデータを取得して返すことができます。この操作パラダイムは複数の REST クエリを実行したときと同様の結果が得られるようになっているため、1 つの GraphQL クエリで複数の REST クエリが置き換えられることもよくあります。
GraphQL はデータのオーバーフェッチとアンダーフェッチ、つまり、必要以上に多いまたは極端に少ない情報がフェッチされることを防ぎます。REST API のレゾリューションにはさまざまなレベルがあります。取得するデータが多いものもあれば、少ないものもあります。ですから、たとえば従業員の名前と ID 番号のみが必要な場合でも従業員のプロフィール全体がフェッチされるなど、データが過剰に取得されてしまうようなケースや、逆に取得できるデータが少なすぎるために何度も API 呼び出しを行わなくてはならないケースが発生します。
REST は各種の HTTP メソッドを使用し、通常 JSON を使用してペイロードデータを交換します。一方 GraphQL では HTTP POST が最もよく使用され、クエリタイプはプロトコル内で指定します。GraphQL はスキーマ定義言語（SDL）というカスタムクエリ形式も使用します。リクエストで SDL が使用されていてもデータは JSON で返されるため、クライアントはレスポンスを簡単に活用できます。GraphQL クライアントライブラリは、ReactJS UI フレームワークとのネイティブ統合を備えており、他の言語やパラダイムでも利用可能なため、多くの開発者が使用できるようになりました。
開発者が API を見つける手段も異なります。REST API の場合、API の発見や操作のためにはなんらかのポータルをストアフロントとして利用します。GraphQL では、組み込みのプレイグラウンドがポータルとなっており、開発にも対応します。これは統合開発環境に近く、開発者は新しいクエリをその場で検索できるうえ、タブ補完などの補助機能も利用できます。また、ドキュメントも異なります。REST は通常、OpenAPI 仕様とポータルを使用します。OpenAPI には拡張機能がいくつかあります。たとえば、Apigee SmartDocs は OpenAPI 仕様からインタラクティブなドキュメントを作成します。GraphQL を使用する場合は通常、Graphiql などのスキーマベースのインタラクティブなドキュメントを使用して、開発や GraphQL エンドポイントの操作を行います。

こうした特長により、GraphQL を使用するユースケースは増えてきていますが、導入時に問題が生じる可能性があります。相互運用性が必要なプロジェクトや社内インフラストラクチャの分解を伴うプロジェクトの場合、GraphQL はわずかな API で異なるさまざまなレガシーシステムに対応できる便利なツールです。また、セルフサービスのデベロッパープログラムや関連する成長戦略でも活用できます。このような場合は通常、大企業が API 管理プラットフォームで REST API を利用可能にすることで社内外のイノベーションを促進します。

このようなプログラムでは、API を開発したチームの外で、多くの開発者が、開発チームが想像もしなかった多くの用途にその API を使用します。その点で、従来のインフラストラクチャ中心の API プロジェクトとは異なります。したがって、一貫性があり信頼性が高く直感的に使いやすいエクスペリエンスを開発者に提供することの重要性が高まります。また、これは GraphQL を導入する際の課題の一つにもつながります。具体的に言えば、REST の場合は一連の API をざっと見れば比較的簡単にそれらがどのような機能を持ち、どのように使えばよいかを直感的に理解できますが、GraphQL ではまだそれができません。

GraphQL で REST ベースのプラクティスを使用する

ジョブでは GraphQL と REST の両方が使用される可能性があるので、そのようなジョブに最適なツールを積極的に使用する必要があります。GraphQL による生産性を高めるには、長年にわたって Google が開発者プログラムの構築で培ってきた REST ベースのベストプラクティスの一部を採用することをおすすめします。

API は企業がアセットを使用するためのデジタルプロダクトであると考えます。また、アセットをよりよく活用するためには、開発者が API を使用できるようにします。この場合の開発者には社内の従業員、パートナー、外部顧客のすべてを含みます。API はデジタルプロダクトなので、開発者が API の使用方法を理解し、魅力的なエクスペリエンスを市場に提供するためには、一貫性のあるエクスペリエンスが必要です。API の採用やデジタル企業の成長戦略において、デベロッパーの負荷は大きな課題となります。そのため、REST の場合と同様に一貫性が GraphQL の鍵となります。

グラフを、複数の名詞で定義づけられたデータドリブンの階層構造として扱う

REST アーキテクチャスタイルの原則の一つは、簡素化された一貫性のあるインターフェースを作成することであり、これによりインフラストラクチャの複雑さが合理化されます。整形式の REST クエリが GET/listEmployeesByDepartment のような形を取ると考える人は誰もいません。これではむしろ Java 関数のように見えます。整形式の REST リソースは GET /Employees、POST /Employees など複数の名詞を使用します。使い方を予測しやすい仕様にすることで、REST API は開発者がリソースを使用して新しいエクスペリエンスを構築する速度に直接影響を与えます。時は金なりです。

GraphQL のスキーマでは、カタログ内の本のタイトルや著者などのエンティティ間の関係を定義するのにグラフの階層を使用します。これは基本的にデータドリブンの階層構造ですが、Java 関数のような機能的階層構造として扱われることもあります。このせいで、予測可能かつ直感的で一貫性のあるエクスペリエンスが妨げられ、負荷が生じる可能性があります。

整形式の GraphQL は整形式の REST と同じような形になるようにしましょう。GET /Books ができるなら POST /Books もできると考えるのが自然です。これを、データベースの名詞ではなく、GET listBooksByGenre などの動詞ベースの関数で定義された Java に似た構造と比較してみましょう。POST するにはどうすればよいでしょうか？対象は /BooksByGenre にすべきなのか、/Books なのか、それとも /listBooks なのかは誰もわかりません。ですから、データドリブンのアプローチをとり、グラフをデータドリブンの階層構造として扱うことをおすすめします。

REST が合理的な場合に GraphQL を強制しない

REST では、特にコマンドクエリ責務分離（CQRS）などのパターンを使用する場合、ユーザーはさまざまな URL からデータのリクエストと送信を行うことがよくあります。CQRS は Martin Fowler によって初めて確認されたデザインパターンで、データを読み取るモデルとデータを更新するモデルを分離します。開発者は多くの場合、REST で CQRS を使用して、マイクロサービスアーキテクチャの複数のサービスからデータを取得します。

GraphQL では、ミューテーション（GraphQL デベロッパーがデータを送信する方法）は、特にデータ型が多種多様な場合や送信されるデータがほとんどない場合に、きわめて迅速に複雑になる可能性があります。データの取得と送信を分離する CQRS と同様のスタイルを使用することをおすすめします。これは大企業、特に REST ベースの API レイヤをすでに使用している企業にとって特に有効な可能性があります。GraphQL は API 管理レイヤ上で、あるいはその代替としてデータを取得できますが、データの送信には既存の REST API を使用できます。これは、REST が合理的な場合に GraphQL を強制すべきでないことを示しています。

再利用できるよう最適化する

大企業で GraphQL をデプロイする際には、開発者がさまざまな種類のバックエンドを扱えるようにする必要がある場合に問題に直面することが少なくありません。そのような場合には、多数の業務部門がそれぞれスキーマを部分的に開発し、通常はスキーマスティッチングやスキーマ連携によって 1 つの包括的なグラフとして開発者に提示されます。データの表現に一貫性がないため、クエリの動作でグラフのさまざまな部分から異なるデータや動作が返される場合に問題が生じます。SDL で変数名が同じに見えるのであれば、異なるデータソースに解決されるという理由だけで、異なる値や形式を返すようにするべきではありません。

さらに、リレーカーソル接続と入力ヒントは、リクエストされているグラフの部分に関係なく、いずれも均一な挙動を示す必要があります。

これはミューテーションでとりわけ問題となります。その理由は、開発者がある方法でスキーマの一部にデータを送信し、そのデータがまた特定のある形式で記録されるようになっている場合、スキーマの別の部分にデータを送信したときにさらに別の形式で記録されても気付けない可能性があるためです。再利用性と API の製品化を最適化する場合、ミューテーションはとりわけ問題となるため、GraphQL でミューテーションの開発と設計を行う方法を特に注意することをおすすめします。

最後に、フィールド名を確認しましょう。同じ名前のフィールド名がスキーマの異なる部分にあるからといって、異なるデータと動作を提供することは、開発者にとっては不親切です。たとえば、スキーマの一部に名、ミドルネーム、姓が想定される名前フィールドがあり、スキーマの別の部分では「姓.名」の形式が想定されている名前フィールドがある場合、こうした不一致のせいで開発者に使ってもらえない可能性があります。

GraphQL ではクエリの効率を最適化するのは簡単ですが、再利用性の最適化を意識的に行いましょう。API によってデベロッパーが混乱する状況を回避することは利益をもたらします。

REST か GraphQL を問わず API は管理が必要なプロダクト

グラフをデータドリブンの階層構造として扱うことから、再利用性とデベロッパーの使用量を最適化することまで、これらのベストプラクティスのほとんどは 1 つの中心的な考え方に基づいています。それは、成長戦略に役立つ API はデベロッパー向けのプロダクトであるため、デベロッパーの API 使用エクスペリエンスは、API が採用されるかどうかの最も重要な決定要因の一つになるということです。Apigee API 管理を活用して、開発者プログラムはこの考え方を REST API で何年にもわたって採用してきました。企業がその考え方をより広く GraphQL に適用するにつれて、これらの API プログラムは、開発者がイノベーションを実現できるように精通するようになるでしょう。

GraphQL と REST の詳細については、Google Cloud Next の動画をご覧ください。こちらのコミュニティ投稿を表示し、リファレンス実装への便利なリンクや、Apigee で GraphQL クエリ認可を有効にするツールを提供する GitHubリポジトリへのリンクをご確認いただけます。

- Google Cloud シニアプロダクトマネージャー David Feuer

Apigee X と Cloud CDN を使用した高パフォーマンスのグローバル API の実現

Tue, 13 Apr 2021 04:00:00 +0000

※この投稿は米国時間 2021 年 4 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

組織は、イノベーションを促進し、業務を効率化するために、デジタルビジネスエコシステム戦略への投資を増やしています。このようなエコシステムはアプリケーションプログラミングインターフェース（API）を介して、パートナー、デベロッパー、顧客などのさまざまな関係者を結び付けています。ソフトウェアシステム同士を接続する API は、このようなエコシステム内における価値交換の主要メカニズムとなります。

たとえば、インドネシアのメガバンクである Bank BRI は、50 以上の収益化オープン API を使用してオンラインショッピングモールを作成し、5,000 万ドルを超える収益を新たに創出しました。これらの API により、70 社以上のエコシステムパートナーは同行の信用評価機能、事業評価機能、リスク管理機能を活用できます。同様に、世界有数の天気予想メディアで、ビッグデータ企業でもある AccuWeather は、7 万人以上の登録デベロッパーに API を公開し、それらのデベロッパーは同社のデータと機能を使用して 3 万個以上のアプリを作成しました。

デジタルビジネスエコシステムをスケールアップすると、新しい市場の解放、地域のパートナーシップの拡大、分散した従業員の接続が可能になりますが、これはすべて API プログラムのスケールアップから始まります。Google は、お客様が API プログラムをグローバルにスケールできるように、Google のネットワーク機能を API 管理に組み込みました。

Apigee と Cloud CDN によってグローバルリーチを拡大し、高パフォーマンスを実現

Apigee X は Google Cloud のライフサイクル全体における API 管理プラットフォームの最新リリースです。Apigee X を使用すると、Cloud コンテンツ配信ネットワーク（CDN）を API にシンプルかつ簡単に適用できます。この 2 つのソリューションを連携させることで、企業は API の保護と管理ができるだけでなく、関係者のグローバルエコシステム全体で API を利用可能にすることができます。

具体的には、企業は Apigee を使用して、API へのセキュリティの適用、API の使用方法と使用者の制御、API の公開、API の使用状況のモニタリングと分析、API の収益化といった API プロダクト管理を行えます。Cloud CDN は、API を呼び出しているエコシステム参加者の数や場所に関係なく、API とそれらがサポートするサービスのパフォーマンスを向上させるのに役立ちます。

Cloud CDN は Google Cloud のグルーバルに分散されたエッジネットワーク上で実行され、組織がコンテンツをグローバルに提供できるようにします。Gmail や Google 検索などのサービスをサポートする Google の大規模なネットワークインフラストラクチャを活用し、コンテンツをユーザーの近くにキャッシュすることによってレイテンシが低減するので、トラフィックのピークシーズンのパフォーマンスと可用性を向上させることができます。組織のバックエンドシステムではなく Google のグローバルエッジからデジタルアセットを提供できるため、ウェブページやアプリはさらに高速に実行され、よりスムーズなエクスペリエンスを実現できます。

Cloud CDN は頻繁にアクセスされるデータを顧客やエンドユーザーの近くのネットワークエッジにできる限り迅速にキャッシュするので、組織はホリデーシーズンや新学期シーズンなどに発生する可能性のある季節的なトラフィックの急増にもシームレスに対処できます。キャッシュ保存に対するこのアプローチは、エコシステムのエクスペリエンスと信頼性を改善できるだけでなく、ウェブサーバーの負荷、コンピューティングの使用量、そして最終的には費用を最小限に抑えることも可能です。

より良いデジタルエクスペリエンスがもたらすデジタルエコシステムの拡大

やり取りする相手が顧客、パートナー、サードパーティデベロッパーのいずれであるかにかかわらず、企業がデジタルエコシステムを拡大できるかどうかは、それが生み出すデジタルエクスペリエンスの質に左右されます。アプリの読み込みが遅すぎたり、サービスが常に利用可能ではないならば、エコシステムの参加者は減るでしょう。API とそれによって提供されるアプリが安全でない場合も同じです。デジタルエコシステムのバリューチェーンの各リンクは、やり取りの流れを維持するために API 管理とネットワーク管理に依存しています。Apigee X と Cloud CDN の力を組み合わせることにより、お客様は前述の課題に対応し、ビジネスを拡大することが可能になります。Apigee X はこちらから無料でお試しいただけます。Cloud CDN について詳しくは、こちらをクリックしてください。以下の動画では、Apigee と Cloud CDN を組み合わせた最新のデモをご覧いただけます。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

Apigee と Google Cloud Armor による多層 API セキュリティ

Mon, 29 Mar 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 3 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

情報セキュリティに関するトピックは、毎日のように大きなニュースになっています。大小のスキームで使用される悪意ある bot や、有名な大企業とその顧客を巻き込み、最終的に多数の政府機関、民間組織、人に影響を与える全面的な「ソフトウェアサプライチェーン攻撃」など、さまざまなセキュリティリスクについて、おそらく耳にされたことがあるはずです。

企業がオンラインチャネルで顧客にサービスを提供したり、場所を問わず世界中のリモートワーカーと業務を行ったりする目的でデジタルプログラムを拡張するのに伴い、このようなセキュリティ攻撃がより一般的になると予想されています。アプリケーションプログラミングインターフェース（API）は、さまざまなアプリケーションやサービスの原動力となるデータや機能をつなぐ、企業のデジタルプログラムの基本コンポーネントであるため、悪意のある攻撃の媒介となりますが、企業が攻撃パターンとその阻止方法の理解を深めるために使用できる分析情報源にもなります。Google Cloud の State of the API Economy 2021 レポートによると、不正なトラフィックは 172% 増加し、企業における異常検出、bot 防止、セキュリティ分析機能の使用量は 230% 増加しています。

アジャイル、スマート、プロアクティブなデジタルセキュリティメカニズムに関わる費用がビジネス運営において避けられないものとなったことに伴い、API セキュリティは企業の IT セキュリティポートフォリオの不可欠な部分になっています。こちらの記事で紹介しているように、最近リリースされた Apigee X により、API セキュリティをさらに強化できます。

Apigee と Google Cloud Armor による多層 API セキュリティ

API はさまざまなデジタルアセットへの扉になります。それぞれの扉には、その背後にあるものを不正アクセスから保護して安全な状態に保つために、鍵をかける必要があります。そのため、組織が API セキュリティを最高レベルにまで高められるよう、Google Cloud は Apigee と Cloud Armor を統合し、業界トップクラスの API 管理テクノロジーとウェブアプリケーションファイアウォールテクノロジーを融合しています。お客様は、Google Cloud のライフサイクル全体の API 管理プラットフォームの最新リリースである Apigee X により、簡単かつシームレスに Cloud Armor ウェブアプリケーションファイアウォール（WAF）を API に適用し、セキュリティを強化して、承認されたユーザーだけが自社のデジタルアセットにアクセスできるようにすることができます。

気象データや天気予報のグローバルリーダーである AccuWeather にとって、新しいアプリケーションを構築するうえでも、外部デベロッパーが AccuWeather のアセットでイノベーションを実現できるように、同コミュニティ向けのデータや機能を収益化するうえでも、API は不可欠なものになっています。AccuWeather は、同社の API の用途がこのように新たに拡大したため、同社のデジタルアセットを管理、保護するための堅牢なセキュリティを必要としていました。

AccuWeather 最高技術責任者 Chris Patti 氏は次のように述べています。「過去 10 年にわたり、AccuWeather は、API を使用して最も正確で役立つ気象情報を企業のお客様に提供するためのデジタルソリューションを変革し続けています。Apigee の戦略的パートナーシップと包括的な API 管理プラットフォームのおかげで、数週間という短期間で業界トップクラスの API を設計、開発、リリースできました。今では、1 日あたり 500 億回の API 呼び出しに対応しています。多くの組織では、独自のデジタルソリューションを利用しているため、変革を推進するために API ファーストの戦略を採用することが増えています。新しい Apigee X のリリースに加えて、グローバルなスケーリング、パフォーマンス、セキュリティに対応できる、reCAPTCHA、Cloud Armor、コンテンツ配信ネットワーク（CDN）といった Google の優れた機能によって、当社は今後、API プログラムをさらに強化できると考えています。」

Apigee と Cloud Armor を組み合わせることにより、複数のレベルで API を保護できます。

クリックして拡大

Apigee X には、OAuth（Open Authorization）、API キー、ロールベースのアクセス、その他多くの API レベルのセキュリティ機能が含まれており、Cloud Armor は、DDoS（分散型サービス拒否攻撃）保護、ジオフェンシング、OWASP（Open Web Application Security Project）トップ 10 リスクの軽減、カスタムレイヤ 7 フィルタリングなど、ネットワークとアプリケーションのセキュリティを提供します。Apigee X と Cloud Armor により、デベロッパーは統合されたセキュリティ機能をすぐに利用して、複数のレベルで API を保護できます。

クリックして拡大

お客様は、Cloud Identity and Access Management（IAM）を簡単に活用して、Apigee プラットフォームへのアクセスの認証と承認を行ったり、顧客管理の暗号鍵（CMEK）で暗号化データをより細かく管理したりすることもできます。

Apigee X と Cloud Armor は、脅威や不正行為からアプリケーションと API を保護するための強力な機能を提供します。これらのプロダクトは、ウェブアプリと API の保護（WAAP）ソリューションの一部としても利用可能です。このソリューションでは、reCAPTCHA Enterprise のアンチ bot 対策と不正防止対策を追加で利用できます。

攻撃者と新たな脆弱性が絶えず出現しているため、セキュリティは変化しますが、API セキュリティに対する多層的アプローチにより、企業は安心して、セキュリティ面で妥協することなく、新しいデジタルサービスや新しいエクスペリエンスに API を迅速に活用できます。Apigee X の詳細について、また Apigee と Cloud Armor の活用例については、次の動画をご覧ください。

-Google Cloud ビジネスアプリケーションプラットフォームプロダクト担当責任者（ディレクター）Vikas Anand

今こそデジタルエクセレンスの実現を - Apigee X のご紹介

Mon, 15 Feb 2021 03:00:00 +0000

※この投稿は米国時間 2021 年 2 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

デジタルトランスフォーメーションは企業にとってここ数年の最優先事項でしたが、世界的なパンデミックをきっかけに、その緊急性はますます高まっています。多くの業界では、以前なら何年もかかっていたであろうことに数週間または数か月で対応しなければならなくなりました。Google が行ったアンケート結果をまとめた「State of the API Economy 2021」レポートによると、4 分の 3 の企業が 2020 年もデジタルトランスフォーメーションに重点を置いており、そのうちの 3 分の 2 が実際に投資額を増やしています。

API はデジタルトランスフォーメーションの根幹です。今日の困難な状況にある組織を支援するため、Apigee X をご紹介します。API 管理プラットフォームのメジャーリリースである Apigee X は、AI、セキュリティ、ネットワーキングにおける Google Cloud の専門知識をシームレスに組み合わせ、企業がデジタルトランスフォーメーション戦略を構築する資産を効率的に管理できるようにします。

「API は、企業がデジタル化を実現するための特に重要なステップの一つに数えられるようになりました。API は、マイクロサービス、EDA、サーバーレス、ハイブリッド / マルチクラウドなど、最新のアーキテクチャパターンを採用する際の鍵になります。」これは、リサーチ＆アドバイザリ企業 Gartner の 2020 年 7 月のレポート「Gartner Market Share Analysis: Full Life Cycle API Management, Worldwide, 2019」にある記述です。このレポートはさらに次のように続きます。「COVID-19（新型コロナウイルス感染症）後の事業再開において、企業はニューノーマルに対する独自の道を見つける必要に迫られます。最も成功するのは今回の危機の最中に再スケーリングや再編成を開始した企業でしょうが、再開時にこれを始める企業が大多数でしょう。再スケーリングと再編成には運用手法の分解と再構成が必要ですが、ここで重要な役割を果たすのが API プラットフォームです。API プラットフォームが効果的で広範囲であるほど、再スケーリングと再編成がより迅速かつ容易になります。」

API は、ソフトウェア同士の通信手法や、開発者がどのように大規模なデータと機能を活用するかを定義するものです。つまり API は、ソフトウェアスタックの単なるコンポーネントではなく、ビジネス戦略を実行して大規模なイノベーションを実現するために開発者が使用するプロダクトといえます。すべてのプロダクトと同様に API も管理が必要です。今月で 10 年目を迎える Apigee には、世界中の 1,000 人を超えるお客様との協力の下、10 年にわたる深い専門知識と経験が蓄積されています。

Nationwide Insurance の Annuity Technology でバイスプレジデントを務める Rick Schnierer 氏は次のように述べています。「Apigee は、API 戦略の展開方法だけでなく、API を使用したデジタルトランスフォーメーションについて戦略的に考えるための道筋を示してくれました。Apigee を導入することで、以前は 2～3 か月かかっていたモノリシックサービスの開発がマイクロサービスとして数日で済むようになり、開発を統合することもできるようになりました。API を一元化モデルを通じてではなく、自分たちで作成し、共有することができるようになったのです。Apigee API 管理プラットフォームを通じて、それまで自分たちだけでは想像もしていなかったビジネス上のつながりが得られるようになりました。」

Deutsche Bank の Corporate Bank Technology でマネージングディレクターを務める Shaun Cotter 氏は、次のように述べています。「Deutsche Bank では、エコシステムに統合する API ソリューションの設計および実装に Apigee X を使うことを楽しみにしています。Google Cloud パートナーシップを結んでいる当行にとって、API によって実現する統合を効果的かつ安全に活用することは重要です。結果として、当行内のサービスをより適切に結びつけ、サードパーティとのイノベーションを実現し、より幅広い顧客基盤にサービスを提供することが可能になります。」

Apigee X でデジタルエクセレンスを実現する

デジタルトランスフォーメーションに対する投資額の増加からうかがえるように、現在競争力を持つのは変革に対する意図ではなく、変革を実現している企業だといえます。単にクラウドや API を利用したり、API 管理を採用したりするだけでは不十分です。むしろ、デジタルエクセレンス、つまり迅速にデプロイとスケーリングを繰り返し、絶えずデジタルプログラムを提供する能力が成功への要件になっています。そのためには、コアとなるエンタープライズ戦略として、収益性の高い API ベースのプラットフォームを構築し、ビジネスで大きな成果をあげることができる、デジタルの採用が必要になります。変革を段階的に行い、API ベースのプログラムをご利用になっているお客様が、デジタルエクセレンスを実現し、API ベースのプラットフォームをご利用になれるようサポートすることが Apigee X の第一の目標です。

Pitney Bowes の最高イノベーション責任者である James Fairweather 氏は次のように述べています。「Pitney Bowes は、クライアントに最高のエクスペリエンスを提供する方法を常に模索しており、その実現に Apigee のテクノロジーを活用しています。API によるプログラムの質を高め、デジタルトランスフォーメーションをさらに加速することができるという Apigee X のリリースを心待ちにしていました。先行きが見通せない状況のなか、場所を問わずにビジネスを進め、プロセスを自動化し、新しいデジタルエクスペリエンスを迅速かつ安全に提供するため、API 戦略の強化が世界中で進められています。Apigee X は、reCAPTCHA Enterprise、Cloud Armor（WAF）、Cloud CDN などの新機能で API を強化することで、私たちのような企業がデジタルイニシアチブをスケールして、顧客、従業員、パートナーに革新的なエクスペリエンスを容易に提供できるようにしてくれます。」

Apigee X の差別化要因

ここで Apigee X についてさらに詳しく見ていきましょう。

グローバルなリーチ、優れたパフォーマンスと信頼性

市場状況の変化と動的な作業環境に伴い、組織はグローバル展開にむけて API プログラムをスケールし、各地の従業員をサポートしています。Apigee X を導入することで、お客様は Cloud CDN を活用し、API の可用性とパフォーマンスを世界規模で最大化することができます。また API を 24 の Google Cloud リージョンにデプロイすることができるようになり、100 を超えるロケーションでキャッシュ機能の質が向上しました。

マルチレイヤセキュリティとプライバシー

API プログラムをスケールすると、組織の内外で不正行為のリスクが高まります。Google の「State of the Economy 2021」レポートにも詳細が記載されていますが、Apigee では昨年、不正な API トラフィックが 170% 以上増加しました。Apigee X は、API セキュリティを強化する Cloud Armor ウェブアプリケーションファイアウォールや、Apigee プラットフォームへのアクセスを認証および承認する Cloud Identity and Access Management（IAM）といった機能の適用に統合アプローチを採用しています。企業は CMEK を使用して暗号化データをより細かく制御できると同時に、選択したリージョンにデータを保存し、VPC Service Controls を使用してユーザーがデータにアクセスできるネットワークロケーションをコントロールすることができます。

AI を活用した自動化

ビジネスクリティカルなアプリケーションの質を高めるために API を採用する企業が増えているなか、常に利用可能で安全、期待どおりに動作するアプリケーションを要望する声が運用チームやセキュリティチームに寄せられています。Apigee X は、業界をリードする Google の AI 機能と機械学習機能を過去の API メタデータに適用し、自律的な異常検出、ピークシーズンのトラフィック予測を行い、API がコンプライアンス要件に対応している状態を保ちます。その結果、API の運用担当者やセキュリティの管理者が、簡単なタスクに時間を費やすことなく、ビジネスにとって本当に重要なことに集中できるようになります。

API 管理の分野で業界のリーダーであり、10 年間にわたりさまざまなお客様と協力してきた Google は、新しいデジタルエクスペリエンス、より強力でインテリジェントな自動化機能、効果的なデータドリブンアプリケーションの構築に API を活用して真のビジネス変革を実現した企業を見てきました。本日の発表は引き続き API 管理の可能性を広げ、企業が今後 10 年間でデジタルエクセレンスを達成するための道筋を提示するものです。皆様が Apigee を活用して素晴らしい成果を上げられるのを楽しみにしております。こちらをクリックすると、Apigee の新リリースを無料でお試しいただけます。

Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨することはありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言することもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ組織の見解により構成されるものであり、事実の表明とは解釈されません。Gartner は、明示または黙示を問わず、商品性や特定の目的への適合性を含め、本リサーチに関連したいかなる保証も行いません。

-Google Cloud ビジネスアプリケーションプラットフォーム担当バイスプレジデント兼ゼネラルマネージャー Amit Zavery

Google Cloud、「オープンデータ API プロジェクト」に参画しオープンデータ活用を支援

Thu, 24 Dec 2020 07:00:00 +0000

Google Cloud は、 API 管理プラットフォーム Apigee の提供を通じて、内閣官房情報技術総合戦略室が一般公開された「オープンデータ API プロジェクト」に技術協力しました。

この「オープンデータ API プロジェクト」は、全国の地方公共団体が公開されているオープンデータの活用を促進する取り組みです。全国 10 の地方公共団体が公開している新型コロナウイルス感染症関連の CSV 形式のオープンデータを Web API 化し「オープンデータ API ポータル」でカタログ化して公開されています。このプロジェクトでは、Google Cloud の Apigee をフル活用することで最小限の時間とコストでの開発を実現されました。例えば CSV の API 化には Hosted Targets、ポータルの構築には統合ポータルといった Apigee の機能が利用されています。またキャッシュ機能でサーバの負荷を軽減し、さらに API アナリティクスを活用することでデータの利用状況の分析も可能になりました。

Google Cloud は、このオープンデータ API プロジェクトを通じ、官民連携によるデータ利活用の促進に貢献し、Society 5.0 時代における「人間中心のデータ駆動型社会」の実現に向けた政府の取り組みを強力にサポートしていきます。

- by Google Cloud Japan Team

Apigee: SAP 向け API の管理を強化するソリューション

Fri, 13 Nov 2020 02:00:00 +0000

※この投稿は米国時間 2020 年 11 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

企業が SAP 環境を Google Cloud に移行する理由はさまざまです。最もよく挙げられる理由は、SAP のワークロードを Google Cloud に移行することで得られる、アジリティ、スケーラビリティ、セキュリティの面での利点です。稼働時間とパフォーマンスの改善に注目する企業も多くあります。

また、ほとんどの企業はなんらかのタイミングで、自社のビジネスデータの中に「宝」が眠っており、それを掘り出すための鍵を握るのがクラウドであると考えるようにもなります。しかし、クラウドを利用してデータから収益を上げようとする場合にぶつかる課題は特殊なものです。また、そうした課題に対処するには専用のツールが必要になります。クラウドで SAP 環境を運用している企業の大部分は、レガシーシステムおよびデータストアも利用し続けていますが、こうした企業の方がより大きな課題を抱える傾向があります。

API の可能性と注意点

こうした状況で役に立つのが、Google Cloud の高度なデータ分析機能、機械学習機能、AI 機能、そして特に API（アプリケーションプログラミングインターフェース）管理ツールです。Apigee API Management Platform は、SAP システムおよびデータストアにイノベーションとチャンスをもたらすことができるため、Google の多くの SAP のお客様にとって期待の星となっています。

API 管理は、ビジネスデータから価値を獲得するうえで直接的に重要な役割を果たします。適切なデータセットを、そのデータを収益化する意思と能力のある人々につなぐことで、間接的なメリット（売上の増加やカスタマーエクスペリエンスの向上につながる分析データの生成など）と直接的なメリット（データへのアクセス権の他社への販売など）の両方を手に入れることができます。

こうした種類のトランザクションをきめ細かく処理できるため、API は現代のデジタルビジネスプラクティスの柱となっています。現在、あらゆるモバイルデバイス、ウェブサイト、アプリケーションに、連携サービスやデータソースにアクセスするための API が使用されています。API は、アプリ、プラットフォーム、アプリケーションエコシステム全体をつなぐ役目を果たします。また、Representational State Transfer（REST）などの事実上の標準を使用することで、API を利用して革新的なアプリケーションを短時間で構築し、デプロイできます。

レガシーシステムが最新の API と調和しない 3 つの理由

SAP 環境を運用している Google Cloud のお客様は、データを有効に活用しようとお考えかもしれません。しかし、その SAP システムおよびデータ、さらに REST などの最新のアプローチを採用していない従来の API では、それはかなり難しいでしょう。その理由は次のとおりです。

アクセス性、ユーザビリティ、セキュリティのバランスをとる作業は困難で、リスクが高い。ビジネスクリティカルなシステムへのアクセスをサードパーティや社内のデベロッパーに提供する場合、大きなリスクを伴うことがあります。セキュリティを重視している SAP のチームですら、SAP のレガシーシステムに信頼できるプログラムからのアクセスを提供するプロセスには、長い時間と多大な労力がかかることが珍しくありません。また、アクセスの制限と API 機能の制限という手法は共にセキュリティリスクの緩和という意味では有用ですが、こうした戦術を採用した場合、イノベーションの速度が遅くなり、そもそもこのプロセスを開始した理由が損なわれてしまいます。
SAP のレガシーアプリケーションとその他のデータストア全体で API を管理する作業は複雑でコストがかかり、技術的に困難である。最新の API の「手法と根拠」と、レガシーシステムの設計のベースとなっているプログラムからのアクセスのタイプの間には根本的な不一致があります。例えば、最新のアプリは通常、API リクエストをかなり大量に送信します。これは、クライアント側のシングルページアプリケーションにも、弾力的にスケールされた最新のアプリサーバーで実行されている従来のサーバー側アプリにも当てはまります。また、最近のアプリでは使用することになっているデータペイロードとレガシーシステムが提供することになっている、データペイロードとでは、サイズと構造にも相違があります。

これらの例は結局、同じ問題に行き着きます。SAP のレガシーシステムを利用している場合も、そうしたシステムから移行しようとしている場合も、最近のユースケースや統合事例でデータにアクセスできるようにするのは非常に困難であるということです。また、サードパーティのデベロッパーに依頼して、レガシーシステムを利用できるように手法とスキルセットを調整してもらうという案は、なかなか受け入れられないでしょう。

API アクセスの収益化には、別の技術的および実際的な課題がある。多くの企業にとって、データに関する重要なポイントは収益化です。つまり、有効利用が望めるデータソースにアクセスする権限を有料にしてデベロッパーに請求するということです。これは、既存の API の前に仮想的な回転式改札口を置いておけばよいというほど単純な問題ではありません。あらゆる収益化戦略の成否は、その料金に左右されます。これは、データの利用者、データアクセスのタイミング、データの用途を正確に理解しなければならないことを意味します。デベロッパーに API コールの料金を請求しなくても、貴社の API トラフィックに関連するすべてのデータフローとデータインタラクションの全体像を把握できるなど、貴重な知見がより高度な分析により得られるようになります。概して、API を収益化するには、単に旧式の手法に従ってシステムを公開するだけではなく、デベロッパーの利用を考慮して API を最新のスタイルで構築し、設計、管理する必要があります。

レガシーであるかどうかにかかわらず、SAP 環境が SAP システムのデータに焦点を当てるものであり、SAP システム内のデータを他のアプリケーションに公開するものではないというのいうは、おそらく周知の事実でしょう。また、こうしたツールが自動的に構築されることはないため、問題は誰が構築するのかという点になります。

Apigee: API 管理でギャップを埋める

Apigee のような API 管理ソリューションを利用する IT 組織は、より効率的にこうした問題に対処できます。具体的には、以下の 3 つの主な SAP アプリケーションモダナイゼーションパターンに対処するために Apigee を活用しています。これらのパターンはすべて、API を使用して価値を創出する際に生じる課題を示しています。

1. レガシーサービスのモダナイゼーション。Apigee の重要な機能の一つに、SAP のレガシーインターフェースに API の「ラッパー」を配置するというものがあります。これによりデベロッパーは、機能豊富で即応性に優れた最新の API で作業できるようになります。また、Apigee プラットフォームは、API 呼び出しを受け取り、変換して最適化するプロセスを処理してから、基盤となる SAP 環境にリクエストを渡します。

API 管理に対するこのアプローチにより、IT 組織はいくつかの便利な機能も手に入れることができます。Apigee は SAP のレガシーインターフェースに機能を追加するための API の設計、実装、テストのプロセスを簡略化し、デベロッパーが API を使用して作業する場所、方法、タイミングの管理を支援します。これは Apigee の API モニタリングおよび指標のベースにもなります。これらの作業を IT チームが独力で構築するには多大な労力が必要になるため、この機能は重要です。

2. ソースシステムからの API の抽出。Apigee プラットフォームは、SAP のレガシーシステムとデベロッパーの間に抽出レイヤーを提供することで、一貫性があり信頼性が高く、予測可能なデベロッパーエクスペリエンスも確保します。このように基盤ソースシステムから API を分離することで、Apigee はシステムの処理と可用性の変化に適応できます。その一方、デベロッパーが API を使用することで、通常どおりにビジネスを継続できます。このようにして、SAP 導入企業は API ソリューションをパッケージ化して販売でき（デベロッパーポータルを介して API を公開するなど）、ターゲットシステムごとに API の利用をモニタリングできます。

デベロッパーのエントリポイントからソースシステムを分離することで、連携したアプリケーションに、ECC から S/4HANA への移行といった大規模なバックエンドの変更の影響が及ばないようにすることもできます。バックエンドの変更をサービスに適用しても、アプリは中断されることなく同じ API の呼び出しを続けます。移行によって、複数の SAP および SAP 以外の実装の S/4HANA への統合、または一部の機能をクラウドネイティブのシステムに移動することによる中核的な SAP システムのクリーンアップなどに結び付くこともあります。Apigee は消費側のアプリケーションを基盤システムに対する変更から抽出し、これらの多様なシステム間に統一性を持たせるため、ECC から S/4HANA への移行などの統合プロジェクトにおけるリスクを軽減できます。

3. クラウドネイティブでスケーラブルなサービスの作成。Apigee は、SAP アプリケーションと、マイクロサービスが重要な役割を果たす最新の分散型アプリケーションアーキテクチャ間のギャップを埋めることができる点でも秀でています。ほとんどの場合、このギャップは大きなものです。また、SAP データをマイクロサービスとして再パッケージ化し、このデータを収益化する機能を提供できるだけでなく、パフォーマンス、可用性、セキュリティに関する重要な機能もいくつか備えています。アクセス制御、認証、セキュリティモニタリング、脅威評価に対処できるだけでなく、必要に応じてトラフィックをスロットリングしてバックエンドシステムを通常どおり使用し続ける一方で、あらゆるワークロードに合わせてスケールできるエンドポイントをアプリケーションに提供します。

言うまでもなく、Apigee のセキュリティ機能は API 管理ツールの用途にかかわらず非常に重要です。Apigee はパフォーマンス、分析、信頼性に関する機能も提供するため、最初から完全に成熟した API 収益化戦略を展開できますが、イノベーションのために SAP システムを公開することでミッションクリティカルなシステムを危険にさらすこともなく、IT チームも安心です。

Conrad Electronic と Apigee: API を使用してイノベーションを促進

非常に多くの企業が Apigee を使用して、これまでは可能と思えなかった手法で SAP のレガシー環境を有効に利用しています。Apigee と Google Cloud のその他のコンポーネントを連携させ、SAP ユーザーにイノベーションの新たな道筋を示した事例として、Conrad Electronic が挙げられます。

Conrad Electronic は長年の歴史を持つドイツの小売企業であり、イノベーションに向けて一歩ずつ着実に進むアプローチをとっています。同社は、既存の SAP のレガシー環境と Google BigQuery を併用することで、デジタル面での変革を実現しました。これにより、以前は分散した数十ものシステムに保存されていたデータをリポジトリに一元化できました。Conrad Electronic は、その変革の影響力と有効性を、Apigee を使用して 2 つのレベルで増大させました。

まず、Apigee を使用して配送会社および B2B 顧客の調達システムとのデータ交換を管理し、これらの会社に提供する小売エクスペリエンスを改善する一方で、従来のトランザクション環境につきものの障害とエラーの可能性を削減しています。

また同時に、Apigee を使用して自社のデベロッパーにイノベーションと試験運用のための最新のツールセットを提供しています。小規模な開発チームはこれを活かし、店内のスタッフと来店した客が、自分のタブレットなどのデバイスを使用して主要な製品、サービス、保証に関する情報にアクセスできるようにする、使いやすいツールを構築しました。

Conrad Electronics でデジタル・ディスラプション担当最高責任者を務める Aleš Drábek 氏は、次のように述べています。「API を利用すれば、何にも依存することなく自由に、短期間で効率的にアイデアを現実のものとすることができます。効率的な API 管理ソリューションである Apigee のおかげで、API の能力を活かして、お客様との関わり方、そして B2B のお客様へのデータの転送方法を変革できました。」

API 管理が秘める可能性

イノベーションを起こすための新しいビジネスモデルや手法で SAP システムを使えるようにする際に生じる課題を Apigee でいかに解決できるかについて詳しくは、こちらをご覧ください。また、SAP のお客様向けの Google Cloud ソリューションについて詳しくは、こちらをご覧ください。

-Google Cloud SAP 戦略およびアーキテクチャ担当パートナー技術リーダー Benjamin Schuler

Apigee

Google Cloud Apigee、Gartner® Magic Quadrant™ API 管理部門で 10 年連続リーダーに選出

API 管理を生成 AI とエージェント AI に拡張

エージェント AI の管理、ガバナンス、セキュリティ保護

グローバル リーダーから信頼される Apigee

お客様とパートナー様に感謝

gRPC から RESTful API へ: gRPC サービスを Rest of the World に公開する

gRPC から HTTP へのゲートウェイ

API 管理で参入障壁を下げる

まとめと次のステップ

API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する

Google Cloud（Apigee）、2023 年 Gartner® Magic Quadrant™ で API 管理のリーダーに選出

Apigee API 管理の料金と対象範囲を細分化

従量課金制とサブスクリプションで料金属性を統一

従量課金制の料金を細分化

API 呼び出し

環境

Apigee API 管理を使ってみる

Apigee は政府機関のゼロトラスト導入にどう役立つのか

政府機関のゼロトラスト アーキテクチャ導入における Apigee のメリット

ゼロトラストに対応した Apigee ソリューションの特徴

次のステップ

API 管理で政府プラットフォームを統合

API を使用して政府システムを安全に接続する

政府プラットフォームの統合

API エコシステムへのアクセスを管理する

使ってみる

Eventarc と Cloud Run でクラウド リソースの変更に対応する

Eventarc と Cloud Run でクラウド リソースの変更に対応する

Eventarc とは

Eventarc ハンドラの定義

Cloud Run イベント ハンドラ

監査ログイベントのソース

Eventarc で監査ログイベントをイベント ハンドラに転送する

エンドツーエンドのバリデーション

Apigee 固有の Eventarc ユースケース案

まとめ

Cloud Run にイベント機能を取り込む Eventarc が一般提供に

アサヒグループホールディングス：GKE、Apigee、GCVE などを活用し、100 年企業のアーキテクチャーを着実にモダナイズ

Google Cloud との出会いで拓かれたモダナイズへの道筋

旧システムを Google Cloud VMware Engine に一時的にマイグレーション

Apigee で GraphQL API を管理する方法

シナリオの仕組み

環境の準備と運用

エンドポイントのテスト

API に Google マップを追加する

次のステップ

Google が 2021 年 Gartner® Magic Quadrant® でフル ライフサイクル API 管理のリーダーに選出

Arab Bank: Anthos と Apigee を使ってアプリケーションのイノベーションを促進

規制の厳しい業界にクラウドを取り入れる

クラウドでつながりと基盤をつくる

国境やタイムゾーンを超えた連携

バンキングにとどまらないサービス

銀行がコアシステムに復元力を導入し、2021 年にイノベーションへの復帰を加速する方法

AI による API オペレーション簡素化で API プログラムのスケーリングをスムーズに

API データを実際に活用する

今こそデジタル エクセレンスの実現を - Apigee X のご紹介

DueDil が Apigee API 優先のアプローチを活用して大規模なデータ分析を提供している方法

迅速、安全、スケーラブルな API を提供する API 管理プラットフォームの選択

API を活用して、セキュリティおよびガバナンスのポリシーを適用しながらセルフサービスを提供

Google Cloud で脅威や不正行為からのウェブアプリと API の保護を強化する

WAAP がお客様にどのように役立っているか

今すぐ WAAP を使ってみる

GraphQL: API コンシューマ向けの一貫したアプローチの構築

REST と GraphQL の比較

GraphQL で REST ベースのプラクティスを使用する

グラフを、複数の名詞で定義づけられたデータドリブンの階層構造として扱う

REST が合理的な場合に GraphQL を強制しない

再利用できるよう最適化する

REST か GraphQL を問わず API は管理が必要なプロダクト

Apigee X と Cloud CDN を使用した高パフォーマンスのグローバル API の実現

Apigee と Cloud CDN によってグローバル リーチを拡大し、高パフォーマンスを実現

より良いデジタル エクスペリエンスがもたらすデジタル エコシステムの拡大

今こそデジタル エクセレンスの実現を - Apigee X のご紹介

Apigee と Google Cloud Armor による多層 API セキュリティ

Apigee と Google Cloud Armor による多層 API セキュリティ

成果につながる意思決定を行うために API 分析を活用するトップ企業

今こそデジタル エクセレンスの実現を - Apigee X のご紹介

Apigee X でデジタル エクセレンスを実現する

Apigee X の差別化要因

グローバルリーダーから信頼される Apigee

政府機関のゼロトラストアーキテクチャ導入における Apigee のメリット

Eventarc と Cloud Run でクラウドリソースの変更に対応する

Eventarc と Cloud Run でクラウドリソースの変更に対応する

Cloud Run イベントハンドラ

Eventarc で監査ログイベントをイベントハンドラに転送する

Google が 2021 年 Gartner® Magic Quadrant® でフルライフサイクル API 管理のリーダーに選出

今こそデジタルエクセレンスの実現を - Apigee X のご紹介

Apigee と Cloud CDN によってグローバルリーチを拡大し、高パフォーマンスを実現

より良いデジタルエクスペリエンスがもたらすデジタルエコシステムの拡大

今こそデジタルエクセレンスの実現を - Apigee X のご紹介

今こそデジタルエクセレンスの実現を - Apigee X のご紹介

Apigee X でデジタルエクセレンスを実現する

2021 年の API を活用したデジタルトランスフォーメーションの動向トップ 5

レガシーシステムが最新の API と調和しない 3 つの理由