API 管理

API のスプロールをエージェント対応のカタログに変換

Mon, 16 Mar 2026 02:00:00 +0000

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

最新のクラウドアーキテクチャでは、API はアプリケーションを形作る基本要素です。しかし、組織が拡大するにつれて、API は複数のゲートウェイやチーム、プラットフォームに分散しがちです。このスプロール（散在）は、ガバナンスや再利用を難しくする見えない領域を生み出します。しかも、次世代ソフトウェアにとっては、さらに深刻な問題になり得ます。AI を効果的に活用するうえでの障害になってしまうからです。

そこで今回は、この問題を解決する 2 つの方法をご紹介します。

Specification Boost（仕様の強化）アドオン。Apigee API Hub 上で、API 仕様の読みやすさと見つけやすさを自動的に高められる機能です。
API Hub と API Gateway の新しい統合。

これらを組み合わせることで、分散している API を単一のコントロールプレーンに集約し、エージェント型 AI が前提となる未来に備えられるようになります。

AI 戦略にとって重要な理由

エージェントの力は、与えられる道具によって決まります。Apigee API Hub を使えば、組織に関係するすべての API 情報を集約し、整理して一元管理できます。また API Hub では、開発者が API を見つけて評価しやすくなるような重要情報を蓄積できるため、可能な限り他チームの成果も活用しやすくなります。API Hub で API のスプロールを制御することで、次の点を担保できます。

エージェントが API を見つけられる: 一元化によって、AI ツールが存在に気づけないシャドー API が埋もれてしまうことを防げます。
エージェントが API を使用できる: ドキュメントを充実させることで、ハルシネーションを抑え、関数呼び出しの成功率を高められます。

スプロールは AI 導入の足かせになる

実際、多くの組織では、API を複数のプラットフォームにまたがって管理しています。たとえば、単純なサーバーレス用途は API Gateway、ミッションクリティカルな用途は Apigee、さらにサードパーティ製のソリューションも併用するといった形です。こうした分散環境では、プラットフォームチームがセキュリティを徹底したり、利用状況を追跡したりすることが、主に 3 つの点で難しくなります。

API が分散している: エージェントが発見できないまま、さまざまなシステムに API が散在しています。
不完全な API: API の使い方を理解するために必要なサンプルやエラーコードといった十分なコンテキストが不足しています。
存在が見えない API: 多くのレガシー環境では、仕様がないまま API プロキシが動いており、ドキュメントも存在しないため、自動化ツールからは見えません。

ステップ 1: API メタデータを一元化する

この問題を解決する第一歩は、可視化です。API Gateway と API Hub の新しい統合により、API のメタデータを単一のリポジトリへ自動的に同期できるようになります。

API Gateway では、サービスの実装を問わず、すべてのサービスで一貫して明確に定義された REST API を使用して、バックエンドサービスに安全にアクセスできます。

さらに API Gateway を API Hub に接続すると、API 定義、OpenAPI 仕様、ゲートウェイ設定が、ほぼリアルタイムで自動的に検出および同期されます。この仕組みはバックグラウンドで透過的に動作するため、既存の API やクライアントを変更する必要はありません。

これらのアセットをまとめて管理することで、チームごとに最適なゲートウェイを使うという分散的な運用は維持しつつ、API に関する知識や情報は一か所に集約できます。

ステップ 2: API 仕様強化アドオンで API をエージェント対応にする

API を一元化すると、仕様自体は技術的には正しくても、AI エージェントにとっては十分に分かりやすくない場合があることに気付くかもしれません。そこで、このギャップを埋めるために、API Hub 向けの仕様強化アドオン（公開プレビュー版）を導入しました。

このアドオンを使うと、API の仕様ファイルをエージェント対応の形に整えることができます。仕様を強化することで、開発者、API 利用者、そして AI エージェントのいずれにとっても、仕様がより理解しやすく、また利用しやすくなります。

仕組み:

分析: 一元化された API をスキャンし、利用例の不足やエラー条件の未定義など、仕様上の不足点を検出します。
強化: エージェントが確実に機能するために必要な、正確なパラメータ検証や動作例を追加した「強化版」の仕様を生成します。
簡単な比較: specboost-draft というラベルの付いた並行バージョンが作成されます。元のファイルは上書きされないため、導入前に「元の仕様」と「強化後の仕様」を並べて比較できます。

この機能は、API Hub コンソールの [アドオン管理] セクションから直接有効にできます（図 1）。

図 1: Google Cloud コンソールの [アドオン管理] 画面。ここで仕様強化アドオンを有効化できます。

有効化すると、API Hub のリストビューで仕様のステータスを確認できます。また、図 2 のとおり、強化された仕様は元のファイルの横に分かりやすくリンク表示されるため、強化版へ簡単にアクセスできます。

図 2: 仕様ファイル一覧。元の「s1」仕様と、自動生成された「s1-Specboost」バージョンが表示されています。

使ってみる

どちらの機能もすでに利用可能です。

API Gateway ユーザーの場合: コンソール上に API Hub へのオンボーディングを開始するためのプロンプトが表示されます。API を単一のコントロールプレーンに統合する方法について詳しくは、API Gateway の統合に関するドキュメントをご覧ください。
仕様の強化アドオンの場合: API Hub の設定から直接有効にすると、強化された仕様の生成を開始できます。エージェント型 AI の時代に向けて API ポートフォリオを準備する方法については、ドキュメントをご覧ください。

- プロダクトマネージャー Mak Ahmad

- ソフトウェアエンジニア Kyle Wiese

Apigee での MCP サポート開始のお知らせ: 既存の API を安全で管理されたエージェントツールへ変換

Fri, 09 Jan 2026 00:00:00 +0000

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

本日、Google はフルマネージドのリモート MCP サーバーのリリースにより、Model Context Protocol（MCP）のサポートを拡大しました。これにより、世界中のデベロッパーが Google と Google Cloud のサービスに一貫してエンタープライズ対応のアクセスができるようになります。これには Apigee での MCP サポートも含まれ、エージェントは、Apigee API ハブにカタログ化された安全で管理された API とカスタムワークフローを、エンドユーザーのタスクを完了するためのツールとして使用できます。

Apigee での MCP サポートの開始に伴い、既存の API を変更したり、コードを記述したり、ローカルまたはリモートの MCP サーバーをデプロイして管理したりする必要はありません。Apigee は既存の API 仕様を利用し、基盤となるインフラストラクチャとコード変換を管理するため、ユーザーはエージェントのビジネスロジックに集中できます。

Apigee の MCP サポートの概要

Apigee は、認可、認証、セキュリティ、ガバナンス制御のための 30 種類以上の組み込みポリシーを提供し、API インタラクションが常に保護されるようにします。Apigee のデバッグ UI と分析機能により、API インタラクションをエンドツーエンドで可視化でき、トラフィックやパフォーマンスの問題に関するモニタリングとアラートも可能になります。

Apigee の MCP サポートにより、既存の API をこれまでと同じポリシーで管理しつつ、MCP ツールとして活用できるようになります。エージェントのインタラクション全体の可視化も可能です。これを行うには、環境グループに「MCP プロキシ」を作成し、ベースパスとして /mcp、ターゲット URL として mcp.apigeex.com を指定して、OpenAPI 仕様を含めます。MCP プロキシがデプロイされると、Apigee API ハブに「MCP」API として登録されます。

デプロイされた MCP プロキシは Apigee API ハブに自動的に登録される

tools/list または tools/call リクエストが MCP エンドポイントに対して行われると、Apigee は OpenAPI 仕様に記載されているオペレーションを MCP ツールリストとして使用します。その後、MCP プロキシを API プロダクトにバンドルし、きめ細かい割り当てと ID およびアクセスポリシーを適用して、承認された MCP クライアント、エージェント、デベロッパーのみがこれらのツールを一覧表示して呼び出せるようにします。

このプロセスでは、たとえば、特定の API オペレーションを MCP ツールとして指定できます。そのうえで、「支払い」サービス用の MCP ツールへのアクセスを、既知のクライアント ID を持ち、ツールを使用する正当な理由がある指定エージェントのみに限定できます。

その後、Apigee Analytics を使用して MCP ツールの使用状況のモニタリングが可能です。また、最近リリースされた Apigee の API 分析情報を利用すると、Apigee API ハブのカタログに追加された [分析情報] タブから、MCP エンドポイントのトラフィックとパフォーマンス指標を確認できます。

MCP サポートに対する Apigee のアプローチのメリット

Apigee で MCP をサポートする主な目的は、使い慣れた Apigee のポリシーとワークフローを使用して、MCP ツールを保護、管理し、使用状況をモニタリングできるようにすることです。

これには次のようなメリットがあります。

追加の運用負担なし: API ごとに MCP サーバーをセットアップして管理する必要はありません。MCP プロキシをデプロイするだけで、残りの処理は Apigee が行います。Apigee は、MCP サーバー、コード変換、プロトコル処理を完全に管理します。
ツールのオブザーバビリティとガバナンス: Apigee に組み込まれた ID、認証、セキュリティの各ポリシーを使用して、MCP エンドポイントとツールの保護および管理も行えます。また、Apigee Analytics を使用して、MCP クライアントによるツールの使用状況をモニタリングできます。
包括的なツールセキュリティ: Apigee は、エージェントによるすべてのインタラクションを安全に保ちます。たとえば、Cloud Data Loss Prevention を使用して、ツールから渡される機密データを分類して保護し、Model Armor を使用して、プロンプトインジェクションやジェイルブレイクの試みを防ぐことができます。エージェントとユーザーが MCP ツールを呼び出すための適切な IAM 権限を持っていることを確認できるほか、エージェントのインタラクションフロー全体をエンドツーエンドで表示して完全にデバッグすることも可能です。また、Apigee Advanced API Security を使用して、ツールのセキュリティを維持できます。
一元化されたツールカタログ: MCP プロキシをデプロイすると、Apigee は MCP エンドポイントを仕様とともに Apigee API ハブに自動登録します。これにより、検索可能な一元化されたツールカタログを維持し、ツールの再利用を促進できます。

エージェントフレームワークで Apigee MCP ツールを使用する

Apigee の MCP サポートは、最大限の互換性を実現するように設計されています。保護された Apigee MCP エンドポイントは、ADK、LangGraph など、AI エコシステム全体で広く採用されているさまざまなフレームワークで構築されたエージェントから利用できます。

その中でも Agent Development Kit（ADK）は、Google エコシステム内でエージェントを開発する際に、効率を高める独自のメリットをデベロッパーに提供します。

ADK は、AI エージェントの開発とデプロイ用に設計された、柔軟性の高いモジュラーフレームワークです。Gemini と Google エコシステム向けに最適化されていますが、モデルやデプロイに依存せず、他のフレームワークとの互換性を保つように構築されています。ADK は、エージェント開発をソフトウェア開発のような感覚で行えるよう設計されており、デベロッパーは基本的なタスクから複雑なワークフローまで、幅広いエージェントアーキテクチャを簡単に作成、デプロイ、オーケストレートできます。

ADK に含まれるツールセットは、Apigee と Application Integration の両方に対応しているため、ADK でカスタムエージェントを構築するデベロッパーは、Apigee で管理および保護されている MCP エンドポイントとツールに、エージェントを簡単に接続できます。また、ADK 用の ApigeeLLM ラッパーを使用して、Apigee プロキシ経由で LLM エンドポイントを公開し、ガバナンスをエージェントワークフローに統合することもできます（注: ApigeeLLM ラッパーは現在、Vertex AI と Google AI Studio の Gemini API での使用を想定して設計されていますが、今後他のモデルやインターフェースもサポートする予定です）。

Google Cloud は、カスタムエージェントをデプロイするためのサービスも提供しています。Vertex AI Agent Engine を使用してエージェントをデプロイし、Gemini Enterprise を使用して組織全体で運用できます。

次のステップ

Apigee での MCP サポートは、現在お客様向けにプレビュー版として提供されています。この機能にアクセスするには、Apigee または Google Cloud のアカウント担当者にお問い合わせください。

-Apigee、プロダクトマネージャー、Megan Bruce

-Apigee、プロダクトマネージャー、Antony Arul

Vertex AI Agent Builder の高度なガバナンス機能の発表

Tue, 23 Dec 2025 03:00:00 +0000

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

Google Cloud は、包括的かつオープンなプラットフォームである Vertex AI Agent Builder への重要な投資を継続することで、より迅速な構築、効率的なスケーリング、そしてエンタープライズグレードのセキュリティによる管理を実現します。

このたび、Cloud API Registry の統合により、Vertex AI Agent Builder のツールガバナンス機能が強化されました。今回の最新のアップデートにより、管理者は組織全体のデベロッパーが利用できるツールを Vertex AI Agent Builder コンソールで直接管理できるようになりました。また、デベロッパーは新しい ApiRegistry を使用して、レジストリで管理されているツールを活用できます。

これにより、組織はすでに使用している組み込みのセキュリティと運用管理機能にエージェントを固定し、エージェントをデジタルワークフォースとしてデプロイおよび管理できるようになります。

こちらにある先月の Agent Builder プラットフォームの拡張に続き、エージェントのライフサイクル全体にわたる新機能も導入します。これにより、デベロッパーは新しい ADK 機能とビジュアルツールを使用して開発を高速化し、セッションとメモリのサポートの一般提供を含む Agent Engine サービスの拡張を通じて高いパフォーマンスでスケーリングできるようになります。以下で詳しく説明します。

1. ツールを自信を持って管理

有用なエージェントを構築するには、エージェントが必要なツールにアクセスできるようにする必要があります。しかし、今日のデベロッパーは、各エージェント用のツールの構築にかなりの時間を費やしており、作業の重複が生じています。こうしたアプローチは、エージェントがアクセスできるデータやツールを管理したい管理者にとっても課題となります。

そこで Google は、Vertex AI Agent Builder コンソールに Cloud API Registry を統合することで、ツールガバナンスを強化します。これは、組織全体でデベロッパーが使用できる承認済みツールのセットをキュレートおよび管理できる管理者向けのプライベートレジストリとして機能し、次の機能を提供します。

Google サービス用の事前構築済みツール: Google は最近、BigQuery や Google マップなどの Google サービスに対する MCP のサポートを発表しました。これらのサービスは、Vertex AI Agent Builder で使用できるようになります。
カスタム MCP サーバーのサポート: エージェントの時代に向けて API 資産全体を活用できるようにします。Apigee では、既存のマネージド API をカスタム MCP サーバーに変換し、確立されたデジタルアセットと最新の AI ワークフローを結び付けることができるようになりました。さらに、これらのツールを複数のクラウドから Apigee API ハブに取り込むことで、エージェントのデベロッパーが Cloud API レジストリを通じてキュレートされたカタログに迅速かつ安全にアクセスできるようになります。
ツール管理の強化: Vertex AI Agent Builder の新しいエクスペリエンスを使用してツールを表示、管理、制御する管理者は、組織内のデベロッパーに適切なツールを利用してもらえるようになります。
ツールへのアクセスの簡素化: デベロッパー向けに、Agent Development Kit（ADK）に Cloud API レジストリのサポートが導入され、新しい ApiRegistry オブジェクトによってマネージドツールを簡単に活用できるようになりました。

上記のデモでは、Vertex AI Agent Builder コンソール内で直接ツールを管理および制御するための新しいユーザージャーニーを紹介しています。

2. AI エージェントを迅速に構築

先月、Google は最もインテリジェントなモデルである Gemini 3 Pro をすべてのデベロッパーと企業チームにリリースしました。マルチモーダル理解において世界最高水準のモデルであり、Google 史上最も強力なエージェント型モデルでもあります。ADK との完全な互換性があるため、信頼性と確信を持って、強力な AI エージェントを構築、テスト、デプロイできるようになります。また、コンセプトからインタラクティブなプロダクトへの移行を支援する新機能も導入されます。

ADK による Gemini 3 Pro と Flash のフルサポート: ADK が Gemini 3 Pro と Flash をフルサポートするようになったため、信頼性の高い本番環境対応のエージェントを構築できるようになります。
TypeScript 用 ADK: ADK による TypeScript のサポートを拡張し、どの言語を選択しても ADK の最新機能を直接活用できるようにします。
ADK の状態管理: ADK 内のエージェントの状態管理を大幅に改善しました。ADK は、AI エージェントが会話中および会話全体でコンテキストとメモリを維持するためのシステムです。新たな改善点は次のとおりです。

障害からの復旧: エラーにより会話がクラッシュした場合、ADK がネイティブで状態を復元するため、デベロッパーによる追加の作業が不要になりました。
人間参加型での継続: 複雑なワークフロー内でも、どこでも人間による入力を待機できるようになりました。ADK はエージェントが停止した場所を正確かつ自動的に記憶し、承認後すぐに再開するため、進捗状況を追跡するための追加のコードを記述する必要はありません。
状態とコンテキストの巻き戻し: デベロッパーは会話の任意の時点に遡って、その時点以降のすべてのやり取りを無効にできるようになりました。ユーザーは新しいメッセージを送信することなく、「汚染された」コンテキストを削除できます。そして、新しいセッションを開かなくても、問題解決のためのさまざまなアプローチを試すことができるようになります。

Interactions API の統合: ADK と Agent2Agent プロトコル（A2A）で新しい Interactions API がサポートされるようになりました。これにより、エージェント全体でマルチモーダル入力 / 出力（テキスト、音声、ビジュアル）を管理する一貫した方法が提供され、クライアントアプリケーションとの統合が簡素化されます。
A2UI: A2A プロトコルをベースに構築された A2UI は、リモートエージェント向けに LLM で生成された UI を容易にするための初期段階の UI ツールキットです。これにより、エージェントは共有 UI ウィジェットとコンポーネントをユーザー向けアプリケーションに直接渡すことができるようになります。iframe や実行可能コードの送信に伴うセキュリティリスクやオーバーヘッドは発生しないため、充実したユーザーエクスペリエンスを安全に構築できます。

上のデモでは、A2UI の動作が紹介されています。ユーザーが写真をアップロードすると、リモートエージェントが Gemini を使用して写真を理解し、A2UI を使用して顧客の具体的なニーズに合ったカスタムフォームを動的に生成します。

GitHub の adk-samples または Vertex AI Agent Garden で今すぐ構築を開始できます。Vertex AI Agent Garden は、厳選されたエージェントのサンプル、ソリューション、ツールをまとめたリポジトリで、開発を加速し、ADK で構築されたエージェントのワンクリックデプロイをサポートするように設計されています。AI エージェントの構築、テスト、デプロイに適した本番環境対応の基盤を提供しているテンプレートコレクション、Agent Starter Pack もご利用ください。

3. AI エージェントを効果的にスケーリング

エージェントを構築したら、次の課題は本番環境への移行です。そのため、Google は Agent Engine で利用できるマネージドサービスを継続的に拡大し、エージェントのスケーリングに必要なコア機能を提供しています。

コンテキストを確実に管理: Agent Engine のセッションとメモリバンクが一般提供（GA）に移行します。Agent Engine を使用して、本番環境ワークロードの短期メモリと長期メモリの両方を管理できるようになりました。これにより、エージェントはさまざまなやり取りでコンテキストを維持できます。パーソナライズされた有用な回答を幅広く提供するために不可欠な機能です。このプロダクトは、Google Cloud AI Research の斬新な研究手法（ACL 2025 に採択）を活用しており、エージェントによる情報の学習と記憶のあり方について新たな基準を確立するトピックベースのアプローチを採用しています。
Agent Engine サービスのサポート地域の拡大: すべての Agent Engine サービスが、世界中の 7 つの地域で新たに利用可能になりました。詳しくはドキュメントをご覧ください。
Agent Engine の料金の改定: Agent Engine ランタイムの料金が引き下げられ、2026 年 1 月 28 日より Agent Engine の追加サービスに対する課金が開始されます。詳細およびエージェント費用の仮定のシナリオについては、Agent Engine の料金に関するドキュメントをご覧ください。

プロダクト	リソース	SKU	以前の料金	新しい料金	料金変更日
ランタイム	vCPU / 時間	8A55-0B95-B7DC	$0.0994	$0.0864	2025 年 12 月 16 日
ランタイム	メモリ / GB-時間	0B45-6103-6EC1	$0.0105	$0.0090	2025 年 12 月 16 日
コード実行	vCPU / 時間	448F-9419-C2EE	無料	$0.0864	2026 年 1 月 28 日
コード実行	メモリ / GB-時間	AC0F-52B0-CE44	無料	$0.0090	2026 年 1 月 28 日
セッション	保存済みセッションイベント	0D5A-FCD2-CB63	無料	$0.25 / 1,000 イベント	2026 年 1 月 28 日
メモリバンク	1 か月あたりの保存メモリ	E954-622B-C859	無料	$0.25 / 1,000 メモリ（LLM の費用は別途請求）	2026 年 1 月 28 日
メモリバンク	取得済みメモリ	6DEC-3026-DDFF	無料	$0.50 / 1,000 メモリ	2026 年 1 月 28 日

上の表には、Agent Engine サービスの変更後の料金と、その変更が適用される時期がまとめられています。

Agent Builder で成果を挙げているお客様

「Burns & McDonnell は、Vertex AI Agent Builder を使用して、組織の知識を企業全体で活用する方法を変革しています。Experience IQ では、ADK を使用して AI エージェントを構築しています。このエージェントは、数十年分のプロジェクトデータと従業員の経験をリアルタイムで実用的なインテリジェンスに変換します。Vertex AI は、決定論的なビジネスルールと確率的推論を組み合わせることで、このイノベーションを責任を持ってスケールできるようにします。これにより、AI は単なる生産性向上ツールではなく、信頼できる運用機能となります。このエージェントは、チームが適切なエクスペリエンスを迅速に特定し、人員配置と計画における手作業を減らし、検証済みのデータに基づいた信頼性の高い意思決定を行うのに役立ちます。Vertex AI を活用することで、Burns & McDonnell は知識を管理するだけでなく、経験を活かして、より迅速かつ的確な意思決定を促進しています。」- Burns & McDonnell、最高イノベーション責任者、Matt Olson 氏

「Payhawk は Vertex AI Agent Builder を使用して、エージェントを、お客様を真に理解する財務アシスタントに変革しています。メモリバンクを活用し、ステートレスなインタラクションから長期的なコンテキスト保持に移行したことで、エージェントがユーザーの制約条件や過去のパターンを継続的に記憶できるようになりました。たとえば、当社の財務管理エージェントは、少額の食事の経費精算などの習慣を記憶し、それを自動的に申請できるようになりました。これにより、申請に要する時間が 50% 以上短縮されています。同様に、当社の出張管理エージェントは、通路側の席などの好みを事前に適用します。これにより認知負荷が大幅に軽減され、エージェントはプロンプトに反応するだけでなく、過去の行動に基づいてニーズを予測できるようになります。」- Payhawk、プリンシパル応用 AI エンジニア、Diyan Bogdanov 氏

「ぐるなびは、Vertex AI Agent Builder を使用して、AI レストラン検索アプリ『UMAME!』を強化しています。このアプリは、Agent Engine のメモリバンクを活用することで、ユーザーのコンテキストを深く理解するという大きな課題を克服しています。従来のプロンプトベースのシステムとは異なり、当社のエージェントはメモリバンクを活用してユーザーの過去の行動、好み、時間的パターンを記憶し、最適なオプションを積極的に提示します。手動で検索する必要がなくなるため、シームレスなエクスペリエンスが実現します。このコンテキスト認識機能により、ユーザーエクスペリエンスが 30% 以上向上すると予測しています。このメモリ機能は、AI とともに新しい食事体験を創造するうえで、誰にとっても欠かせない機能だと考えています。」- ぐるなび、CTO、岩本俊明氏

「SeaArt Entertainment は、Vertex AI Agent Builder を使用して、デジタルアーティスト向けのクリエイティブエクスペリエンスをパーソナライズしています。メモリバンクが導入される前は、AI エージェントがユーザーの好みを確実に記憶することはできませんでした。たとえば、ユーザーが複雑なマルチモーダルのアートプロジェクトに取り組む場合は、セッションごとに同一の詳細情報（好きなキャラクタースタイルやモデルの選択など）を繰り返し説明する必要がありました。メモリバンクを導入してからは、エージェントが過去の会話、アクション、ユーザーの好みを記憶できるようになりました。特に気に入っているのは、エージェントがセッションをまたいでコンテキストをシームレスに記憶できる点です。これにより、より自然でパーソナライズされたやり取りが可能になります。」- SeaArt Entertainment、マルチモーダル AI プラットフォーム担当責任者、Aleksei Savin 氏

利用方法

Vertex AI Agent Builder は、エージェントのライフサイクル全体を管理するための統合プラットフォームを提供し、プロトタイプから本番環境対応のエージェントへの移行を支援します。これらの新機能の詳細については、更新された Agent Builder のドキュメントとリリースノートをご覧ください。

スタートアップ企業の方で、エージェントの構築とデプロイの詳細について関心をお持ちの場合は、スタートアップ向け技術ガイド: AI エージェントをダウンロードしてください。タスクの自動化、創造性の強化、スタートアップでのまったく新しいユーザーエクスペリエンスの構築など、目標の内容を問わず、アイデアからプロトタイプ、そしてスケーリングへと進むために必要な知識を習得できる内容となっています。

-Google Cloud、プロダクトマネージャー Michael Vakoc

-Google Cloud、グループプロダクトマネージャー John Murray

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

OWASP トップ 10 セキュリティ脅威から API を保護する

Tue, 01 Apr 2025 01:00:00 +0000

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

API は最新鋭のサービスに不可欠な要素であり、機密性の高いデータが API でやり取りされることもよくあります。適切な認証、認可、データ漏洩に対する保護がなければ、組織やエンドユーザーはサイバー攻撃のリスクにさらされることになります。

Open Worldwide Application Security Project（OWASP）は、API を含むソフトウェアセキュリティの重要な分野について、コミュニティ主導のドキュメントや標準を開発し、公開しています。API は現在、インターネットトラフィックの半分以上を占めていると推定されています。

AI の導入が進むにつれて、この割合はさらに増える可能性があります。なぜなら、基盤モデルの構築、AI 機能をアプリケーションに統合するプロセスの合理化、異なるプラットフォームで実行されるモデル間の相互運用性の促進、AI モデルのトレーニングや改善に必要なリアルタイムデータへの継続的なアクセスのために、AI はすでに API に大きく依存しているからです。

組織が API セキュリティ戦略を導入する際は、API への依存度が高く、その傾向が強まっている現状を考慮する必要があります。OWASP トップ 10 API セキュリティ脅威のガイダンスは、このための出発点となります。Google は、このリストを基に、OWASP が特定した各リスクに対する軽減策の推奨事項を追加した新しいホワイトペーパー「 Mitigating OWASP Top 10 API Security Threats（OWASP トップ 10 API セキュリティ脅威の緩和策）」を作成しました。このホワイトペーパーでは、各脅威の詳細と、Google Cloud の API 管理プラットフォームである Apigee が API のリスク管理にどのように役立つかを説明しています。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud のセキュリティプロダクトを試せる $300 分の無料クレジット'), ('body', <wagtail.rich_text.RichText object at 0x7f4ab8596160>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', <GAEImage: Google Cloud>)])]>

OWASP トップ 10 API セキュリティリスクへの対応

API セキュリティプログラムを開始したばかりの組織にとって、OWASP トップ 10 API セキュリティ脅威のリストは良い出発点となります。このリストでは、組織が API システムを保護するために対処すべき最も重大な脆弱性を示しており、セキュリティ脅威を、認証、認可、リソース管理、セキュリティの構成ミス、サードパーティのリスクというテーマに大別しています。

オブジェクトレベルの認可の不備（BOLA: Broken Object Level Authorization）、オブジェクトプロパティレベルの認可の不備（BOPLA: Broken Object Property Level Authorization）、機能レベルの認可の不備（BFLA: Broken Function Level Authorization）などの脆弱性は、攻撃者がアクセス制御をバイパスし、データや機能を操作することを可能にするため、特に懸念すべきものです。

BOLA は、API が個々のデータオブジェクトに対して適切なアクセス制御を適用できない場合に発生し、攻撃者が不正にデータにアクセスしたり、変更したりすることを可能にします。BOPLA は、データオブジェクト内の個々のプロパティに対してアクセス制御対策が効果的に適用されない場合に発生し、攻撃者が機密属性を操作することを可能にします。BFLA は、API 内の特定の機能や操作に適切なアクセス制御メカニズムがない場合に発生し、攻撃者が不正な操作を実行することを可能にします。

認証の脆弱性（認証の不備など）は、なりすましや不正アクセスにつながる可能性があります。制限のないリソース消費や、機密性の高いビジネスフローへの制限のないアクセスは、業務の中断や、攻撃者に悪用される可能性のある重要データの公開にもつながりかねません。

セキュリティの構成ミスや API の不適切なインベントリ管理は、攻撃者に悪用される脆弱性をさらに生み出す可能性があります。また、サードパーティ API を安全でない方法で使用すると、それらの API の脆弱性によって使用中の API のセキュリティが脅かされるため、外部リスクが生じます。

これらの脅威に対処するには、堅牢なアクセス制御、安全な認証メカニズム、適切なリソース管理、徹底したセキュリティ構成、サードパーティ API の慎重なインテグレーションなど、多層的なアプローチが必要です。

Apigee と Advanced API Security によるセキュリティリスクの軽減

Google Cloud の API 管理プラットフォームである Apigee を使用すると、API プラットフォームチームはこのような攻撃からバックエンドサービスを保護できる安全な API プロキシをプログラムしてデプロイできます。以下の表は、OWASP トップ 10 API セキュリティリスクから API を保護するのに役立つ Apigee と Advanced API Security の具体的な機能の一部を紹介するものです。

OWASP トップ 10 API セキュリティリスク（2023 年）	Apigee と Advanced API Security の軽減機能
オブジェクトレベルの認可の不備（BOLA）	割り当て管理 OAuth 2.0 と OpenID Connect 機密データの保護 API プロキシのセキュリティ構成チェックとアラート不正行為や異常を検出するルールと ML モデル不審なトラフィックを自動的にフラグ付けしてブロックするセキュリティ対策
認証の不備	認証 OAuth 2.0 と OpenID Connect API キー検証 JSON Web Token（JWT）のサポート不正行為や異常を検出するルールと ML モデル API プロキシのセキュリティ構成チェックとアラート
オブジェクトプロパティレベルの認可の不備（BOPLA）	データマスキング OpenAPI 仕様の検証 API プロキシのセキュリティ構成チェックとアラート不正行為や異常を検出するルールと ML モデルトラフィック分析とレポート
制限のないリソース消費	割り当て管理 Spike Arrest ポリシーキャッシュ不正行為や異常を検出するルールと ML モデル（DoS 攻撃やリソース枯渇の兆候を示すアクティビティを特定） API プロキシのセキュリティ構成チェックとアラート（例: すべてのプロキシに Spike Arrest ポリシーが適用されているかどうかの確認）
機能レベルの認可の不備（BFLA）	API プロダクト（きめ細かいアクセス制御用）割り当て管理 Spike Arrest ポリシー OpenAPI 仕様の検証 API 認証での API キーと OAuth のサポート XML と SOAP ペイロードのメッセージ検証、RESTful API リクエストの検証、GraphQL 検証 API プロキシのセキュリティ構成チェックとアラート不正行為や異常を検出するルールと ML モデル
機密性の高いビジネスフローへの制限のないアクセス	認証とロールベースアクセス制御（RBAC） OAuth 2.0 と OpenID Connect API キー検証と JSON Web Token（JWT）のサポートレート制限 SQL インジェクション攻撃やクロスサイトスクリプティング（XSS）攻撃に対するペイロードの検査 API プロキシのセキュリティ構成チェックとアラート不正行為や異常を検出するルールと ML モデル
サーバーサイドリクエストフォージェリ（SSRF）	入力の検証 SIEM と WAF のインテグレーション API プロキシのセキュリティ構成チェックとアラート不正行為や異常を検出するルールと ML モデル
セキュリティの構成ミス	API プロキシのセキュリティ構成チェックとアラート: プロキシ全体のセキュリティの構成ミスをチェックし、アラートを送信（API を使用してプロキシのセキュリティスコアチェックを CI/CD パイプラインに統合可能）包括的な組み込みのセキュリティポリシー（レート制限、CORS ポリシーなど）アクセス制御（API キー検証を含む）モニタリング、ロギング、アラート（Cloud Monitoring とのネイティブなインテグレーションとサードパーティ製ツールのサポートにより対応）攻撃に対するリアルタイム保護により、セキュリティの構成ミスの悪用を防止
不適切なインベントリ管理	バージョニングとライフサイクル管理 API ハブを介した API インベントリとガバナンスの一元化シャドー API 検出モニタリング、ロギング、アラート（Cloud Monitoring とのネイティブなインテグレーションとサードパーティ製ツールのサポートにより対応） API プロキシのセキュリティ構成チェックとアラート
API の安全でない使用	API プロダクト（きめ細かいアクセス制御用） API ゲートウェイの使用アクセス制御ポリシー（OAuth 2.0、API キー検証、割り当て管理など） XML と SOAP ペイロードのメッセージ検証、RESTful API リクエストの検証、GraphQL 検証モニタリング、ロギング、アラート（Cloud Monitoring とのネイティブなインテグレーションとサードパーティ製ツールのサポートにより対応） SIEM と WAF のインテグレーション不正行為や異常を検出するルールと ML モデル API の使用状況とリスクのリアルタイム表示、脅威への対応

API とアプリケーションのセキュリティに階層的なアプローチを採用する場合は、Apigee と Advanced API Security を Cloud Armor などのウェブアプリケーションファイアウォール（WAF）と併用できます。Cloud Armor が備える DDoS 攻撃に対する堅牢な保護機能（L3 / L4 DDoS 防御機能や DDoS 攻撃のしきい値など）は、制限のないリソース消費やその他のセキュリティ脅威に対する保護を強化するのに役立ちます。

aside_block: <ListValue: [StructValue([('title', 'Cloud CISO のマンスリーニュースレターをメールで受け取る'), ('body', <wagtail.rich_text.RichText object at 0x7f4ab8596a60>), ('btn_text', '今すぐ登録する'), ('href', 'https://go.chronicle.security/cloudciso-newsletter-signup?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY23-Cloud-CISO-Perspectives-newsletter-blog-embed-CTA&utm_content=-&utm_term=-'), ('image', <GAEImage: Cloud CISO Perspectives new header July 2024 small>)])]>

Apigee で API の保護を始める

Apigee を使用して OWASP トップ 10 API セキュリティ脅威を軽減する方法の詳細については、無料のホワイトペーパーをご覧ください。上記の脅威について詳しく説明しているほか、脅威からの保護に役立つプロダクトの機能についても紹介しています。

Apigee に組み込まれているセキュリティポリシーと Advanced API Security の機能の詳細については、ドキュメントをご覧ください。4 月に開催される Google Next に参加される方は、Google Cloud による API と AI のセキュリティリスクの軽減に関するセッションもご確認ください。

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

Apigee で生成 AI アプリを運用化する

Wed, 26 Feb 2025 01:00:00 +0000

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

生成 AI は、今やブームを越えて実運用の段階に達しています。企業は大規模言語モデル（LLM）を基盤とするエンタープライズ向け生成 AI ソリューションの構築に意欲的ですが、デプロイの管理、保護、スケーリングの面で課題を抱えており、特に API に関してはその傾向が顕著です。プラットフォームチームの一員としてすでに統合型の生成 AI プラットフォームの構築に携わっている方も多い中で、次のような質問がよく聞かれます。

組織として、セキュリティと安全性をどのように確保すればよいでしょうか？他の API と同様に、LLM API も攻撃ベクトルとなります。気をつけるべき LLM 特有の考慮事項は、どのようなものですか？
LLM を活用する機会が増えるなかで、予算超過を防ぐのと同時に、各チームが継続的にイノベーションを起こしビジネスの生産性を高めるために必要な LLM キャパシティを確保するにはどうすればよいですか？
使用パターンの把握や、トラブルシューティングの支援、コンプライアンスデータの収集のために、適切なオブザーバビリティ機能をどのように設ければよいでしょうか？
生成 AI アプリケーションのエンドユーザーにできるだけ優れたエクスペリエンスを提供するには、どうすればよいですか？（たとえば、最小限のダウンタイムで最適なモデルから回答を行うには？）

Apigee は Google Cloud の API 管理プラットフォームであり、これまで 10 年以上にわたってこのような API の課題を解決できるようお客様を支援してきました。Apigee API Management を活用した AI によるデジタルバリューチェーンを図で表すと、次のようになります。

図 1: AI によるデジタルバリューチェーン

AI エージェントと LLM を活用した生成 AI は、顧客の企業との関わり方を変え、あらゆる企業に大きな機会をもたらしています。Apigee を利用すると、認証やトラフィック制御、分析、ポリシーの適用といった機能を通じて、セキュリティ、スケーラビリティ、ガバナンスを強化でき、生成 AI エージェントをアプリケーションに統合するプロセスが合理化されます。また、LLM との連携を管理し、セキュリティと効率を向上させることができます。さらに、Google Cloud の Integration Platform as a Service ソリューションである Application Integration には、生成 AI エージェントからデータベースや外部システムへの接続を容易にする事前構築済みコネクタが用意されており、ユーザーリクエストへの応答に役立てられています。

aside_block: <ListValue: [StructValue([('title', '300 ドル分の無料クレジットで Google Cloud の AI と ML を試用'), ('body', <wagtail.rich_text.RichText object at 0x7f4abcad5160>), ('btn_text', '無料で構築を始める'), ('href', 'http://console.cloud.google.com/freetrial?redirectPath=/vertex-ai/'), ('image', None)])]>

このブログでは、LLM API 特有の課題に対処するための Apigee の活用方法を詳しく説明します。また、網羅的なリファレンスソリューションも公開していますので、ご自身で Apigee を利用して課題に対処する際にお役立てください。同じトピックに関して、プロダクトのデモを含むウェブセミナーをご覧になることもできます。

エージェントに取り次ぐプロキシとしての Apigee

AI エージェントは、LLM の機能を活用してエンドユーザーのためにタスクを遂行します。エージェントの構築には、ノーコードまたはローコードのプラットフォームから、LangChain や LlamaIndex などのフルコードのフレームワークまで、さまざまなツールを使用できます。Apigee は AI アプリケーションとエージェントの間で仲介役として機能します。Apigee を使用すると、OWASP トップ 10 API セキュリティリスクから LLM API を守ることができるため、セキュリティが強化されます。ユーザーの認証と認可の管理や、セマンティックキャッシングなどの機能によるパフォーマンスの最適化も可能です。トークンの制限を適用して費用を抑えられるほか、高度なユースケースでは複数の AI エージェント間で複雑なインタラクションをオーケストレートすることもできます。

LLM アプリケーションとモデルをつなぐゲートウェイとしての Apigee

AI エージェントでは目下のタスクに応じて、さまざまな LLM を活用する必要が生じることがあります。Apigee はこれを簡素化するために、最適な LLM へのリクエストのルーティングやフェイルオーバーを、柔軟な構成とテンプレートを活用してインテリジェントに行います。また、LLM の堅牢なアクセス制御を行いながら、新しい AI アプリケーションおよびエージェントの導入を効率化します。エージェントは多くの場合、ユーザーのニーズに十分に応えるために、LLM 以外にデータベースや外部のシステムとも接続する必要があります。Apigee の堅牢な API 管理プラットフォームを使用すると、マネージド API を介してこうしたインタラクションを行えるようになります。カスタムのビジネスロジックが必要となる複雑なインタラクションの場合は、Google Cloud の Application Integration プラットフォームを活用できます。

こうしたパターンが万能でないことは覚えておかなければなりません。具体的なユースケースにより、エージェントと LLM のインタラクションのアーキテクチャパターンは変わります。たとえば、必ずしも複数の LLM にリクエストをルーティングする必要はないかもしれません。場合によっては、Apigee エージェントのプロキシレイヤから、データベースや外部のシステムに直接接続することもできます。重要なのは柔軟性です。Apigee では、ニーズに合わせてアーキテクチャを適応させることができます。

それでは、Apigee が役立つ具体的な分野を一つずつ見ていきましょう。

AI の安全性Apigee で管理される API では、Google Cloud のモデル安全性サービスである Model Armor を呼び出すことができます。これにより、あらゆるプロンプトと回答を調査して潜在的なプロンプト攻撃を防ぎ、設定したガードレール内で LLM が回答できるようにします。たとえば、LLM アプリケーションで金融や政治のトピックに関する回答を行わないように指定できます。

レイテンシと費用モデルの回答のレイテンシは、依然として、LLM を活用したアプリケーションを構築するときの大きな要因です。推論プロセスで行う論理的推論の数が多くなると、このレイテンシの問題は悪化します。Apigee ではセマンティックキャッシュを実装することで、モデルを問わず、意味的に類似した質問に対する回答をキャッシュに保存できます。これにより、エンドユーザーの待ち時間が大幅に短縮されます。

このソリューションでは、Vertex AI Vector Search と Vertex AI Embeddings API によってプロンプトを処理し、類似プロンプトの特定に利用します。そして、この類似プロンプトへの回答が Apigee のキャッシュから取得されます。ご利用にあたっては、Apigee のセマンティックキャッシュに関するリファレンスソリューションを参照してください。

パフォーマンスモデルが異なれば、得意分野も異なります。たとえば、Gemini Pro モデルは非常に質の高い回答を提供しますが、Gemini Flash モデルはスピードと効率性に優れています。ユースケースやアプリケーションに応じて、ユーザーのプロンプトをそのジョブに最適なモデルにルーティングできます。

どのモデルを使用するかは API 呼び出しで指定でき、Apigee は一貫した API コントラクトを維持しながら希望するモデルへのルーティングを行います。ご利用にあたっては、こちらのリファレンスソリューションを参照してください。

配分と使用量上限Apigee を使用すると、組織内のすべてのモデルにセルフサービスでアクセスできる統合ポータルを作成できます。また、個々のアプリや開発者ごとに使用量上限を設定することで、それぞれが必要とするだけの容量を確保しながら、全体的な費用を抑えることもできます。LLM トークン数に基づいて Apigee の使用量上限を設定する方法については、こちらをご覧ください。

可用性LLM 推論には大量の計算が必要になるため、モデルプロバイダは通常、一定の時間枠内で使用できるトークンの数を制限しています。モデルでその上限に達すると、アプリケーションからのリクエストがスロットリングされるため、エンドユーザーがそのモデルを利用できなくなる可能性があります。そうならないようにするには、Apigee にサーキットブレーカーを実装して、利用可能な容量のあるモデルにリクエストが再ルーティングされるようにします。ご利用にあたっては、こちらのリファレンスソリューションを参照してください。

レポートプラットフォームチームは、サポートするさまざまなモデルの使用状況や、各アプリのトークン消費量を把握する必要があります。こういったデータは、社内の費用レポートや最適化にも利用可能です。いずれの場合も Apigee では、ダッシュボードを構築し、「LLM API の通貨」とも言えるトークンの実際の利用数に基づいて使用状況を可視化できます。この方法なら、アプリケーションをまたいだ実際の使用量も確認できます。ご利用にあたっては、こちらのリファレンスソリューションを参照してください。

監査とトラブルシューティングコンプライアンスやトラブルシューティングの要件を満たすために、LLM とのすべてのインタラクション（プロンプト、回答、RAG データ）をロギングする必要が生じる場合があります。あるいは、LLM アプリケーションを継続的に改善するために、回答の質を分析したい場合もあります。Apigee を使用すれば、Cloud Logging で LLM とのインタラクションを安全にロギングし、匿名化して、使い慣れたインターフェースからそれを調査することができます。まずはこちらをご覧ください。

セキュリティAPI が攻撃対象領域として捉えられることが増えるなか、セキュリティは API プログラムの最重要事項となっています。Apigee は、API キー、OAuth 2.0、JWT 検証でアクセスを制御できる、LLM API の安全なゲートウェイとしても機能します。そのため、モデルとやり取りするユーザーとアプリケーションの認証に、エンタープライズレベルのセキュリティ標準を適用できます。Apigee では、レート制限と割り当てを適用することで悪用や過負荷を防止し、悪意のある攻撃や予期せぬトラフィックの急増から LLM を保護することもできます。

このようなセキュリティ管理に加え、Apigee は、利用可能なモデルプロバイダとモデルの管理にも利用できます。その場合、モデルにアクセスできるユーザーまたはアプリケーションを定義するポリシーを作成します。たとえば、特に強力な LLM へのアクセスを特定のユーザーに限って許可するポリシーや、一部のタスクにおいて LLM へのアクセスを特定のアプリケーションに限って許可するポリシーを作成することができます。こうして、意図した目的にのみ LLM が使用されるよう、その使用方法をきめ細かく制御できます。

それだけでなく、Apigee には Advanced API Security によるさらに高度な保護機能も用意されています。これは、LLM API を OWASP トップ 10 API セキュリティ脆弱性から防御するのに有効です。

Apigee を LLM アーキテクチャと統合すると、安全で信頼性の高い環境が構築され、AI アプリケーションの機能を存分に活かすことができます。

生成 AI の可能性を最大限に引き出すには

AI の運用化のために Apigee の包括的な機能について確認し、安全かつスケーラブルで効率的な生成 AI ソリューションの構築に取りかかりましょう。詳細と利用開始にご関心をお持ちの方は、Apigee の生成 AI サンプルのページや、より詳しい情報を提供しているウェブセミナーをご覧ください。このページからのお問い合わせもお待ちしています。

-プロダクトマネージャー Michael Vakoc
-カスタマーエンジニア Ruben Gonzalez

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 0x7f4abd3294f0>)])]>

上記のコマンドは、提供された .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 0x7f4abd329040>)])]>

ここで設定された 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 0x7f4abeadc370>)])]>

ご覧のとおり、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 0x7f4abeadc5e0>)])]>

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

イタリア行政府にとっての Apigee と相互運用モデル（Modl）

Wed, 21 Aug 2024 01:30:00 +0000

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

イタリア行政府とその顧客、サプライヤー、システムインテグレータは、Apigee API Management によって、Agency for Digital Italy（AgID）が設計した新しい相互運用モデルへの完全なコンプライアンスを実現しています（参照元: 新しい相互運用モデル - ModI）。

Modl プラットフォームを実現する Apigee

Modl の重要な側面として、API を最優先にしたアプローチの適用を促すことが挙げられます。これにより、すべての関係者やサービスのアクセシビリティと相互運用性が最大化されます。

Apigee は、Modl に準拠したインタラクションの基盤として機能します。

行政府や他の機関が、さまざまな Apigee 機能を使って、Modl 認証を必要とする取り組みやプログラムでどのようにコンプライアンスを実現しているかを以下で説明します。

ハイブリッド クラウドとマルチクラウドのデプロイ行政組織にはそれぞれに独自の IT 環境があります。オンプレミスでデジタルサービスをホストしている組織もあれば、パブリッククラウドプロバイダでホストすることを好む組織もあるでしょう。1 つ以上のクラウドハイパースケーラーに移行するデジタル革命の最中だという組織もあれば、統合プログラムに取り組んでいる組織もあるかもしれません。したがって、さまざまな種類のデプロイモデルをサポートできる API 管理プラットフォームを選ぶことが重要です。

Apigee によってアーキテクチャの自由度が向上するため、行政機関は独自のデータセンターや任意のパブリッククラウドなど、あらゆる場所に API をデプロイできます。たとえば、独自の Kubernetes クラスタ内のコンテナ化されたランタイムサービスで Apigee をホストし管理することも、Google に管理をまかせて Google Cloud 上で Apigee を使用することもできます。

Apigee でサポートされているデプロイプラットフォームと運用モデルの詳細をご覧ください。

トラフィック管理とコントロール ポリシーModI ガイドラインには、行政機関のインタラクションとデジタルサービスの利用がどのように行われるべきかが記されています。

Apigee は API プロキシのポリシーを使って、コードを記述せずに API の動作をプログラムしています。そうすることで、組織はセキュリティコントロール、レート制限、変換、メディエーションなどの一般的な機能を追加することが可能となります。行政府は、50 を超える堅牢な一連のポリシー（以下の画像）から必要なものを選択して、各 API の動作、トラフィック、セキュリティ、サービス品質（QoS）といったプロパティを操作、管理できます。さらに Apigee は、JavaScript アプリケーションなどのカスタムスクリプトとコードをサポートしており、API 機能を拡張できます。

Apigee は Modl ガイドラインの基準を満たせるよう、50 を超える堅牢な一連のポリシーを提供しています。

モニタリングとロギングモニタリングとロギングも、API のデザインと開発において重要な役割を果たします。これを踏まえると、行政機関は、利用するデジタルサービスにこのような機能を提供できる API 管理プラットフォームを選択することが重要です。

Apigee なら、行政機関は組み込み型のカスタム API 分析ダッシュボードを利用して、API トラフィックから得られた重要な情報を分析することにより、利用急増の調査、パフォーマンスの改善、改善機会の特定を行うことができます。さらに、Apigee は API プロキシフローをデバッグし、コンソールまたは分散トレースソリューション内で、API トランザクションの詳細をすべて調査できるようにします。行政機関は、API パフォーマンスやレイテンシをモニタリングしたり、異常なトラフィックパターンを特定したり、予測できない動作に関する通知を受け取ったりすることで、問題領域を素早く特定することができます。

ML ベースの不正行為の検出による API セキュリティの自動化政府と行政は、以前にも増してサイバーセキュリティ攻撃の対象になっています。API セキュリティのリスクを最小化、もしくは排除するために、政府機関や行政機関はすべての必要な予防策を行うべきです。

Apigee は Advanced API Security という、構成ミス、悪意のある bot 攻撃、重大な不正行為から API を保護するアドオン機能を提供しています。Advanced API Security は、マネージド API を定期的に評価して、Modl のセキュリティ基準を満たしていない API プロキシを明らかにし、問題が検出された場合は推奨される対応方法を提示します。ML を活用したダッシュボードは、多数の bot アラート内のパターンを検出して重要なインシデントに素早く反応することで、重大な API の不正使用を正確に特定します。

Apigee によって行政機関は、Modl に沿ったプロファイルを簡単に定義し、デジタルサービスのガイドライン準拠状況を評価するために使用できます。

次に、行政機関が Modl コンプライアンスへの取り組みのために Apigee をどのように活用できるかについて、詳細を見ていきましょう。

Apigee 内で Modl のガイドラインとパターンを適用する方法

これまでご覧いただいたように、Modl ガイドラインには、API を通してデジタルサービスを公開、使用する際に行政機関が準拠しなければならない一連の要件が集約されています。

これらの推奨事項は、ニーズの特定、組織、セマンティクス、手法、セキュリティ、National Digital Data Platform （PDND）の相互運用性を確保するプロセスなどの要素に対処します。さらに、ガイドラインの規制機関によって要件の適用レベルも定義されており、義務か任意かが示されています。

すべての要件が API 管理に関連しているわけではありませんが、Apigee を活用することで、行政機関は特定のガイドラインに準拠できます。Apigee は特に、手法とセキュリティに関する Modl 要件を満たすために組み合わせて使用できる、すべての構成要素を提供します。

たとえば、Apigee によって行政機関は、REST と SOAP 両方のプロトコルでデジタルサービスを公開できます。サービスの公開に加えて、Apigee を使うと、他の機関によって公開されたダウンストリームのデジタルサービスを起動することもできます（REST と SOAP の両方で可能）。

ペイロードの検証は、Apigee が提供するすぐに使用できるポリシーによって実現されます。たとえば、OpenAPI Specification Validation ポリシーや SOAP Message Validation ポリシーなどがあります。

さらに行政機関は、Modl で推奨されているように、これらのインタラクションのためのトランスポートプロトコルとして TLS や mTLS を設定できます。

ModI 要件に基づいてアプリケーションレベルのセキュリティに対処できるよう、Apigee は次のすぐに使えるポリシーを提供しています。

Apigee は Modl ガイドラインに沿ったすぐに使用できるセキュリティポリシーを提供しています。

さらに Apigee は、デジタルサービスへのアクセスに使用されるクーポンを精査したり、クーポンに含まれる情報に基づいて正しいアクションを適用したりするための、すぐに使えるポリシーを提供しています。

すでにお伝えしたように、Apigee を使用すれば、他の行政機関によって公開されたデジタルサービスを起動したり、必要に応じて 1 つ以上のダウンストリームデジタルサービスをオーケストレートしたりすることもできます。こういった場合には、以下のようなすぐに使えるポリシーも役立ちます。

Modl ガイドラインに準拠した形でデジタルサービスを公開して使用するためには、すぐに使えるポリシーを「組み合わせる」必要があります。これを実現するために、行政機関は、さまざまな Modl 要件に対処するための事前構成された一連のポリシーフローを作成できます。

事前構成済みのフローは Apigee 内の共有フローに組み込むことができ、デベロッパーはこれらをデジタルサービスの公開時や使用時に再利用できます。共有フローは、API プロキシや他の共有フローから FlowCallout ポリシーを使って呼び出されます。

共有フローを構成して全員が使用できるようにするために、行政機関には中心となるチームが必要です。

行政機関は Apigee 内で共有フローを呼び出すことができます。

Apigee で対象の共有フローが使用可能になると、特定のデジタルサービスを公開、起動するために定義されたロジックに含めることができるようになります。

ModI のためのアクセンチュアアクセラレータ

Apigee にはアクセンチュアのような、これらの特定の Modl コンプライアンスフローにすでに取り組んでいるパートナーがいます。

アクセンチュアはソリューションの重要性を認識しており、独自のイノベーションセンター内、具体的にはローマのアクセンチュアクラウドイノベーションセンター（ACIC）にて、Modl のすべての要件とガイドラインをカバーするために、Modl コンプライアンスフローを開発しています。クラウドイノベーションセンターでは、特に顧客独自のビジネスニーズに対処するためにカスタマイズされたクラウドソリューションに重点を置いています。

戦略的な立場として ACIC は、クラウド主導のビジネス変革のための業界知識、アジリティ、技術的専門知識を提供するだけでなく、公的機関に固有の規制要件の厳密な遵守を保証する、ソブリンクラウドに特化したセンターオブエクセレンスとしての機能も果たします。これにより、政府の規制を遵守しながら顧客ニーズに対応し、Apigee 技術に対する理解と専門性を高めるための理想的な環境が生まれます。

次のセクションでは、Apigee を活用して ModI コンプライアンスフローを実現するためのアクセンチュアの取り組みについて、さらに詳しく掘り下げていきます。

アクセンチュアのアクセラレータは、顧客が ModI に準拠した Apigee 環境を構築できるよう、すぐに使えるソリューションを提供することを目的としています。

アクセラレータは以下のプロセスに従っています。

公的書類の分析
Modl 要件の収集
Modl 要件のカテゴライズ

分析の結果、API 管理レベルでの影響がある、ModI へのコンプライアンスに必要な一連の要件が導き出され、以下のように分類されました。

ネイティブにサポート: Apigee のすぐに使える機能によってネイティブに要件が満たされます。
カスタム: 再利用可能な共有フローの開発によって要件が満たされます。
プロシージャル: それぞれのサービスの開発時に要件が適用される必要があり、API デベロッパーが担当します。「デベロッパーハンドブック」内に集約されます。

カテゴリ別の要件の内訳は以下の通りです。

アクセンチュアのアクセラレータは、興味を持った顧客が簡単に採用できるよう、Google Marketplace を通じて提供される予定です。対象の Apigee 組織に簡単に統合できる、すぐに使えるパッケージとして公開されます。この時点で、顧客は各 API プロキシに対して適用する ModI 要件を選択し、関連付けられた共有フローを選ぶことができます。

Google Cloud コンソールで Apigee を使用して ModI 要件を適用する方法の例は以下の通りです。GitOps モードにも同じ方法を利用できます。

API プロキシを作成する

2. API 情報を入力する

3. API プロキシをデプロイする

4. API プロキシを編集する

5. Modl 要件を適用するために共有フローを選択する

6. API プロキシをアップデートする

まとめ

Apigee API Management と Google Cloud パートナーは、イタリア行政府のデジタル化に役立つ機能を提供できます。イタリア政府が行政府のあらゆるレベルで行っている大規模な投資と公開入札のおかげで、この機会の迅速な活用が可能となり、国民や企業は、イタリアおよび欧州連合全体で物資、人、サービス、データの移動を円滑に行えるようになるはずです。

詳細情報は Apigee 担当者にお問い合わせください。

ー セールス エンジニア Filippo Lambiente

ー アクセンチュア

Cloud Code プラグインによる API 管理で迅速な API 開発を実現

Mon, 22 Jul 2024 02:10:00 +0000

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

API の配信において中心的な役割を担うデベロッパーは、プロセスの迅速化や簡易化を可能にするツールを求めています。強力な API 管理プラットフォームである Apigee は、API 開発の簡素化と時間短縮を可能にするツールを備え、企業による API のビルド、管理、収益化、スケーリングを支援します。

Apigee は Google Cloud コンソールからアクセスできるほか、一般的に使用される IDE から Cloud Code プラグインを介してアクセスすることも可能です。VSCode の Cloud Code プラグインを使うことで、ワークスペースの作成やプロキシのビルドに加え、Gemini Code Assist の利用が可能になります。これにより、効率的な API 配信を実現できます。プラグインに関する理解を深めるため、まずはワークスペースについて詳しく見ていきましょう。

組織のワークスペース

Apigee におけるワークスペースは、API 開発を支援するために自動的に作成されるフォルダのコレクションを指します。ワークスペースには API 開発に必要なすべてのツールが構造化された形で格納されているため、デベロッパーは必要なツールを準備するための時間を節約することができます。ワークスペースの構成は以下のとおりです。

API プロキシ: プロキシは、プロキシエンドポイント（API の URL）とターゲットエンドポイント（バックエンドサービスへの接続ポイント）で構成されています。プロキシは、API をバックエンドから切り離す役目を果たします。また、ポリシーを使用することで、プロキシの機能を拡張し、管理機能を強化することも可能です。ポリシーは、プロキシを介してメッセージフロー内のさまざまなポイントに追加できます。
共有フロー: 共有フローを使えば、ポリシーやリソースといったよく利用する機能を組織内の複数の API で再利用できます。
環境: 環境は、API プロキシの作成、テスト、デプロイに使用する専用のスペースです。
テストデータ: テストデータは、本番環境に一般的に存在するリソースのセットをひとまとめにしたものです。API プロダクト、デベロッパーアカウント、テスト用のデベロッパーアプリケーション、値など、API の実行に必要なリソースが含まれています。
エミュレータ: エミュレータは、Docker イメージ（ローカルランタイム）を使った単体テストや手動テストによる機能性の検証を行うのに使用します。

Gemini Code Assist を使った API 管理（プレビュー）

Gemini Code Assist は、ユーザーが生成 AI を活用して優れたソフトウェアを構築できるよう支援します。ユーザーが自然言語で要件を入力すると、数秒の内に OpenAPI 仕様が作成されます。一連の操作は、すべて Cloud Code プラグインから実行できます。API Hub との緊密なインテグレーションにより、作成された仕様をプラグインから直接登録することが可能です。

Gemini Code Assist を利用するには、まずプロンプトを入力します。プロンプトでは、自然言語を使って API 仕様を記述します。Gemini Code Assist は組織の API Hub にどんなオブジェクトが存在しているかを把握しているため、ビジネス要件に合わせた仕様をプロンプトが入力されてから数秒のうちに返して、コンテキストに基づいた AI による支援を提供できます。こうしたことが可能なのは、組織の API Hub に登録済みの仕様からオブジェクト、メタデータ、セキュリティスキーマを再利用し、API 間での整合性を確保しているためです。

たとえば、発注を行うための API を作成するとします。プロンプトとして、「発注用の API を作成して」という文章を入力します。Gemini は API Hub に登録されているすべての API を確認したうえで、入力されたビジネス要件に合った仕様の案を作成します。Gemini は、レジストリ内にある API からオブジェクトとスキーマを pull して仕様を作成することで、他の API のビジネス要件との整合性を図ります。ユーザーは、求める仕様が出力されるまで、エディタを使ってプロンプトを改良できます。また、同じ画面からプロンプトの履歴を確認することもできます。

モックサーバーによる速度の向上

テストは、API の開発プロセスにおいて重要な位置を占めます。API の開発だけでなく、API のローカル環境や結合テスト環境でのテストも Cloud Code プラグインから行うことができます。API 仕様が作成されると、その仕様とともにローカルのモックサーバーも必ず作成されます。API の操作は、仕様を作成したものと同じ UI から行えます。また、パラメータを修正したり、仮の値を挿入したりすることで、よくあるシナリオやユースケースをシミュレートできます。モックサーバーが自動で作成されるため、API プロキシの機能性をより迅速に検証できるようになります。

さらに、シンプルなワークフローを実行することで、モックサーバーを簡単に Google Cloud プロジェクトにデプロイできます。クラウドにモックサーバーをデプロイすれば、チームの他のメンバーとモックサーバーを共有して、フィードバックを収集するプロセスを短縮することができます。たとえば、サービスのデベロッパーがフロントエンド側の担当者とモックサーバーを共有すれば、デベロッパーが API を実装するためのコードを書かなくても、フロントエンド側の担当者がそのサービスを試してみることが可能になります。

使ってみる

これで、Cloud Code プラグインを使って API のビルドやデプロイを行う準備が整いました。利用を開始するには、こちらをクリックしてください。API 管理に役立つ Gemini Code Assist で、API 管理の方法を一新しましょう。

ー Google、デベロッパー アドボケイト Emanuel Burgess

Altice Labs が Google の Application Integration を使用して API 管理を強化した方法

Fri, 05 Jul 2024 02:00:00 +0000

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

編集者注: 今回は、Altice Group の通信＆ビジネス市場向け研究開発を主導している Altice Labs からお話を伺います。同社のチームは、Altice Group の事業会社が動画、ブロードバンド、モバイル、エンタープライズサービスを通じて世界中の 5 億人以上の人々とつながれるようにする、最先端の通信ソリューションを構築しています。

Altice Group の事業会社の既存 IT インフラストラクチャは堅牢ですが、エンタープライズサービスバス（ESB）で管理する複雑なワークフローと増え続けるレガシーコンポーネントで構成されており、複雑でもあります。この複雑さが、新しいサービスや機能の迅速なリリースの妨げとなっています。これらの課題を克服するために、私たちは以下に取り組みました。

断片化したシステムとの通信を効率化する API の構築
Apigee API Management を使用した、これらの API のきめ細かな制御と保護
Application Integration を使用した、複雑な統合フロー、データマッピング、エラー処理のオーケストレーション

とりわけ、Application Integration の導入は、複雑さの管理にとても役立っています。Application Integration は Google Cloud の Integration Platform as a Service（iPaaS）であり、自社開発の SaaS かサードパーティ製の SaaS かを問わず、あらゆるアプリケーションをマウス操作だけで簡単に接続してビジネスプロセスを自動化します。その直感的なインターフェースにより、複雑なフローを構築し、データをマッピングし、事前に構築されたタスクやトリガーを使用して業務を効率化できます。

私たちは Application Integration のアーリーアドプターとなり、オーケストレーション、非同期処理、エラー処理、状態管理が重要な状況で応用してきました。

たとえば、Altice Group の事業会社で共通するプロセスの一つが、複数のバックエンドシステムを扱う請求アカウントの作成です。コンシューマ（社内アプリケーションやコンポーネント）は、Application Integration を使用して単一の API とやり取りします。Application Integration はオーケストレーションとエラー管理を行い、たとえ異なるシステム間であっても、API コンシューマに根本的な複雑さを見せることなく、データの整合性を確保します。これにより、スケーラブルではない手作業でのクリーンアップの必要性を回避できます。

インテグレーション戦略の詳細

現在も私たちは、Apigee を使用して API トラフィックとセキュリティポリシーを管理しています。ただし、複雑なインテグレーションには Application Integration を使用しています。この新しいアーキテクチャは、CRM、ID 管理、ショッピングカート、モジュールといったシステムの API を管理し、カスタマージャーニー、請求、従量課金をサポートします。また、ビジネスサポートシステム（BSS）、運用サポートシステム（OSS）、サービス品質、コールセンターなどの運用とサポートのためのコンポーネントも含まれています。

Application Integration は、非同期処理を必要とする場合にとても有効です。たとえば、API コンシューマがかなりの時間を要する処理を開始しても、処理が完了するまで待つ必要はありません。Application Integration がバックグラウンドで（非同期に）処理を行い、処理が完了したらコールバックを送信します。

また、プロデューサが同期レスポンスを送信し、コンシューマが非同期レスポンスを待っている場合でも、Application Integration は同期レスポンスと非同期レスポンスの両方を処理しながらプロセスの状態を維持します。

Altice Group に与えた効果

Altice Labs の新しい IT アーキテクチャは、Altice Group の事業会社が運営するさまざまなサービスのアジャイルな構築、料金設定、管理を可能にします。このプラットフォームは、サービスの検出とサブスクライブから、利用、サポート、そして最終的にはサービスの停止や移行に至るまで、カスタマージャーニー全体をサポートします。このエンドツーエンドの管理は、サービス品質と顧客満足度を維持するために不可欠です。

このプロジェクトの初期フェーズはポルトガルで実施されましたが、他の国でもいくつかのフェーズを実施する予定です。このプロジェクトが完了すれば、世界中の事業会社のビジネスチームが、より効率的かつ少ない労力で新しいサービスを定義し、お客様に導入できるようになります。

Application Integration の詳細

-Altice Labs、デジタルおよびイノベーション戦略 Bruno Cabral 氏

CSP が目指すネットワーク API デジタルマーケットプレイスシンジケーションを通じた、より広範囲へのリーチとよりスマートな収益化

Thu, 27 Jun 2024 03:50:00 +0000

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

通信業界は、デジタル化の台頭とサービス提供におけるより迅速かつ効率的な方法の必要性に促されて、大きな変革を遂げつつあります。この変革における重要なトレンドの一つは、エコシステムを通じてイノベーションを育成し、新たな収益を生み出すネットワーク API の出現です。

API の構築が課題であることはもちろんですが、それらをデベロッパーやお客様に届けるとなると、これはまたまったく別の課題となります。

アプリケーションデベロッパーがそれぞれ異なるプラットフォームやマーケットプレイスを使用していることを考慮し、Google Cloud ではデベロッパーが普段使用している環境にリーチしターゲットとする、マーケットプレイスシンジケーションアプローチを提案しています。このアプローチでは、通信サービスプロバイダ（CSP）向けのネットワーク API がサードパーティ提供のアグリゲータプラットフォームにオンボーディングされ、その後、異なるマーケットプレイスにシンジケートされることで、API の最大限のリーチと採用を実現します。

Google Cloud は、このシンジケーションの取り組みにおいて、Ericsson、Glide、Nokia を含む主要な API アグリゲータプラットフォームベンダーと協力しています。今後、世界規模または地域規模のカバレッジ、革新的なビジネスモデルなどを持つ、特定のユースケースに特化したアグリゲータが登場することが予想されます。複数のアグリゲータがデベロッパーマーケットプレイスに接続できるアプローチは、特定のアプリケーションや顧客のビジネス目標のためにデベロッパーが必要とするリーチを提供するために理想的だと言えます。

昨年の GSMA Open Gateway イニシアチブと関連する CAMARA プロジェクトの立ち上げにより、今こそ CSP が API の作成と提供をより詳細に検討する重要な時期です。

Open Gateway は、通信事業者のネットワークへの普遍的アクセスを提供するように設計された API のフレームワークで、世界のモバイル接続の約 60% を占める主要な移動通信事業者（MNO）からの支持を得ています。これにより、Linux Foundation と GSMA Operator Platform Group が協力して共通の Open Gateway API 標準を定義する CAMARA プロジェクトが立ち上げられました。この標準は、世界中の通信事業者の環境全体で、一貫した API 設計と利用アプローチを使用することで、デベロッパーコミュニティの成長を加速することを目的としています。

GSMA やその他の主要な業界イニシアチブは、ネットワーク API を公開し、より開放的で相互運用可能な通信エコシステムを構築することを支援しており、これは業界の継続的な成長とイノベーションに不可欠です。この相互運用性の向上に伴い、機会も拡大しています。ただしこれは、オーディエンスが API を見つけることができる場合に限ります。

デジタル API マーケットプレイス

デジタル API マーケットプレイスにより、通信事業者は CAMARA やその他の付加価値 API および API バンドル（サブスクライバーの識別と認証、ネットワークスライスなど）を販売可能なプロダクトとしてパッケージ化し、ライフサイクル管理を提供することで、完全にデジタル化された Order to Cash のセルフサービス機能を実現できます。特に、API マーケットプレイスには次のような利点があります。

カタログ: 複数の通信事業者によってサービス提供または提供可能なネットワーク API のカタログ
発見: マーケットプレイス上の API と、その API を使用するアプリケーションをそれぞれデベロッパーと最終消費者に宣伝する能力
請求: デベロッパーの請求書に含まれるべき API 使用量と、デベロッパーがより広範なマーケットプレイスから利用している可能性のある他のサービスをまとめた一括請求

下の図は、Google とそのパートナーである Ericsson、Glide、Nokia のシンジケートされた API マーケットプレイスへのアプローチの方法を示しています。

マーケットプレイスのシンジケーションは、デベロッパーコミュニティが API プロダクトを発見、調達し、ビジネスアプリケーションに組み込む新たな可能性を引き出し、CSP のブランドと収益機会を高めます。その機会には以下のようなものがあります。

より広範なリーチと売上の増幅: 複数のプラットフォームにわたるフットプリントの拡大により、瞬時にオーディエンスと潜在的な購入者を増加させます。
簡素化された管理: 単一のプロダクトカタログと価格構造を維持する能力により、複数のマーケットプレイスを個別に管理する課題を解消します。
効率化されたデータ: 統合された売上と顧客インサイトへのアクセスにより、マーケティングやプロダクトに関する意思決定に役立つ価値ある情報を提供します。
ブランドの一貫性の向上: すべてのプラットフォームでシームレスなブランド体験を提供し、信頼と顧客ロイヤルティを高めます。
運用コストの削減: 複数のプラットフォームの料金やスタッフの必要性を排除し、戦略的なイニシアチブのためにリソースを解放します。
より優れた柔軟性: 特定のプラットフォームやオーディエンスに合わせて提供内容を適応させ、最大の効果を得るためにアプローチをカスタマイズできます。

Google のパートナーは、API シンジケーションによってもたらされる機会に対して熱意を持っています。

Glide の CEO である Eran Haggiag 氏は次のように述べます。「OpenGateway は、AI 時代の ID、支払い、コミュニケーションソリューションを提供するための独自の機会を提供します。この可能性を引き出すためには、グローバルな連携、スタートアップのアジリティ、そして信頼できるインフラストラクチャが不可欠です。私たちは主要な CSP とともに、デベロッパーエコシステムで利用可能な Google ブランドの OpenGateway エクスペリエンスを共同開発しています。Glide は、AI 強化型自動化機能を備えた Google Cloud Marketplace を活用して、エコシステム全体のデベロッパーにシームレスなエクスペリエンスを提供し、世界規模のカバレッジを迅速に拡大しています。Google Cloud は、デベロッパーと CSP の連携が実現された双方にメリットのあるエコシステムの構築を可能にしてくれます。」

Nokia のネットワーク収益化プラットフォーム担当ポートフォリオおよびアーキテクチャ責任者 Mikko Jarva 氏は次のように述べます。「私たちが使用するアプリケーションはネットワークに大きく依存しています。デジタル化が進む中、ネットワーク API を通じて提供されるネットワーク認識と特殊化への依存度は、ますます高まっています。そのため、ネットワーク API エコシステムを実現および拡張するイニシアチブやコラボレーションを強くサポートしており、Nokia Network as Code のようなアグリゲータプラットフォームや、Google Cloud などのマーケットプレイスを通じて、ネットワークとアプリケーションデベロッパーを接続します。」

Ericsson のグローバルネットワークプラットフォーム / プロダクト / エンジニアリング責任者である Joakim Sorelius 氏は次のように述べます。「Ericsson と Vonage は、Google Cloud のデベロッパーや他のサードパーティデベロッパーにネットワークを開放することで、さらなるイノベーションに向けて機能を普遍的に利用できるようにし、グローバルなネットワークプラットフォームの開発をリードしています。デベロッパーが適切に構築されサポートされた API プラットフォームで活躍することで、企業は新しくてカスタマイズ可能な独自の API イノベーションから成長できます。同時に、通信サービスプロバイダはネットワークの収益化と成長の機会から利益を得られます。私たちは CAMARA の成功に尽力し、CAMARA の将来的な進化の原動力となることを目指しています。」

まとめ

Open Gateway や他の主要な業界 API イニシアチブは、通信業界における重要な変革を解き放つ準備が整っており、デジタル API マーケットプレイスがこの変革への道のりにおける主要な推進力となっています。Google Cloud は、ネットワーク API のリーチを拡大するために、マーケットプレイス API の集約およびシンジケーションアプローチを提案しています。ただし、マーケットプレイスシンジケーションの目的は、単に売上を増やすことではありません。よりスマートに販売し、顧客やアプリケーションデベロッパーとより強固な関係を築き、市場を獲得することが重要です。

Google のこれらのパートナーとの取り組みについて詳しくは、以下をご覧ください。

ClearX の API スピンオフ Glide による Telefonica、Orange、Enstream と共同での Google Cloud Marketplace で最近リリースされた実装の強化
Nokia と Google Cloud のコラボレーションによるアプリケーションデベロッパーへの高度なネットワーク機能の提供。Nokia の Network as Code platform の詳細。
Ericsson が提供する社内およびパートナーと共同で構築したさまざまなネットワーク API。

- Google Cloud、通信ネットワーク収益化＆戦略的パートナーシップ担当責任者 Ramesh Nagarajan

Apigee のカスタムレポートで API のパフォーマンス分析情報を獲得する

Thu, 27 Jun 2024 01:10:00 +0000

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

API のパフォーマンスをモニタリングすることは、ユーザーエクスペリエンス、ビジネスの保護、問題解決の事前対応の観点から重要です。API のパフォーマンスを把握するには、応答時間、スループット、エラー率、レイテンシ、可用性などの主要な指標を理解する必要があります。こうした指標の最適化は重要です。というのも、パフォーマンスが良好でないと、ユーザーの不満、ビジネスの損失、会社の評判の低下につながってしまう可能性があるからです。

Apigee API Management のカスタムレポート機能は、API の分析データを詳細に可視化し、API プログラムに関する高度にカスタマイズされた分析情報を取得できる優れた手段です。このようなレポートは、ビジネスチーム、プラットフォームチーム、開発チームなど、API に関与する人すべてにとって有益なものであり、データドリブンな意思決定を促進し、API パフォーマンスのモニタリングを強化するのに役立ちます。Apigee のカスタムレポートを使用して、リクエストエンドポイント、レスポンスコード、エラータイプなどの API 指標に着目することで、ボトルネックや異常を特定し、より迅速な問題の解決につなげることができます。対象期間をカスタムで指定してデータを集計することもでき、傾向の分析、キャパシティプランニング、特定のイベントとパフォーマンスの相関の把握を簡単に行えるため、モニタリング戦略を全体的に強化することが可能です。

このブログでは、本番環境のデプロイのトラブルシューティング、パフォーマンスの最適化、API 戦略全体の強化に役立つ主要なカスタムレポートを紹介します。この記事の主な対象読者は、日常的にプラットフォームのモニタリングを行うプラットフォームチーム、オペレーションチーム、開発チームの方です。ここで取り上げるカスタムレポートは、さまざまなトラブルシューティングのシナリオに合わせて適宜調整、拡張することが可能な基盤として活用できます。

Apigee カスタムレポートについて

サブスクリプションの利用資格にもよりますが、Apigee では最大で 14 か月分の API 分析データが保持されるため、分析情報をさかのぼって確認できるという利点があります。すぐに使える API モニタリングダッシュボードとカスタムレポートは Apigee API のモニタリングの取り組みにおける重要なコンポーネントであり、これらは互いを補完する形で機能します。この事前構築済みダッシュボードでは環境レベルおよび API プロキシレベルで分析情報を取得できます。一方、カスタムレポートではさらに詳細な情報を柔軟性に優れた手法で確認できます。

カスタムレポートを使用すると、特定のチームや目的に関連する、API トラフィックに固有のデータパラメータを取得できます。多種多様なディメンションを使用してデータにフィルタを適用し、フィルタ済みのデータを集計して合計や平均などを割り出すことで、データから有意な情報を引き出せます。たとえば、オペレーションチームであれば、特定の API プロキシとターゲットホスト内のどのリクエスト URI が最も多くのトラフィックを受信しているかを確認できます。また、コレクタリソースからカスタム API データポイントを取り込み、さらに詳細でカスタマイズされた分析を実行することも可能です。

カスタムレポートは非常に柔軟な手法で作成でき、さまざまなディメンションと指標を試すことができます。たとえば、ディメンションとしてターゲット IP1 ではなく、分析が容易なターゲットホストを使用することは、どのようなレポートでもおすすめです。ホストや FQDN は IP アドレスよりも覚えやすく、カスタムレポートでこれらを使用することで、単一のターゲット IP から到達する宛先が複数ある場合にも、トラフィックパスを個別に取得できるようになります。レポートで使用可能なその他の役立つディメンションには、プロキシベースパス、リクエスト URI、ユーザーエージェント、クライアント IP、API プロダクト、デベロッパーアプリ、地域などがあります。

主なカスタムレポート

レポート名	ディメンション	指標
レイテンシ分析	プロキシベースパスターゲットホストリクエスト URI クライアント IP	avg(target response time) avg(total response time)
レスポンスコード分析	プロキシベースパスターゲットホストリクエスト URI ターゲットレスポンスコード	sum(traffic)
API プロダクトパフォーマンス分析	API プロダクトデベロッパーアプリターゲットホストレスポンスステータスコードクライアント IP アドレス	sum(traffic) avg(total response time)
キャッシュ分析	プロキシベースパスターゲットホストリクエスト URI	sum(cache_hit) sum(traffic)
ユーザーエージェント分析	プロキシベースパスターゲットホストユーザーエージェント / ユーザーエージェントファミリー / ユーザーエージェントタイプレスポンスコード	sum(traffic)
API ロケーション分析	プロキシベースパスターゲットホスト地域	sum(traffic) avg(total response time)

それぞれについて、次のセクションで詳しく説明します。

1. レイテンシ分析

レイテンシ分析は、システム内またはネットワーク内のボトルネックや遅延を特定する際に有用です。パフォーマンスの最適化や、全体的なユーザーエクスペリエンスの改善に役立てることができます。

Apigee で、単一のプロキシに対して複数のターゲットバックエンドがある場合、レイテンシの問題のトラブルシューティングが難しくなります。カスタムレポートがあれば、ターゲットホスト、リクエスト URI、クライアント IP などのディメンションを使用して、特定のターゲットエンドポイントに照らしてレイテンシを特定できます。このようにすることで、大きなレイテンシを発生させている特定のバックエンドまたは特定のリクエスト URI を迅速に見つけ出すことができるので、デバッグプロセスの簡素化につながります。クライアント IP アドレスをディメンションとして使用すると、特定のアプリケーションユーザーの遅延の根本原因を特定したり、問題が発生しているのがローカルネットワーク内なのか、ISP 側なのか、それとも API サーバーへのルート上なのかを調査したりする際に役立ちます。

ターゲットエンドポイントのレイテンシ分析のレポートを作成する手順は次のとおりです。

指標として avg(total response time) と avg(target response time) を選択する
ディメンションとしてプロキシ ベースパス、ターゲット ホスト、リクエスト URI、クライアント IP を選択する
フィルタを適用してデータを限定する
期間を指定してカスタムレポートを実行する

以下は、サンプルのカスタムレポートのスクリーンショットです。

分析の精度を高める目的で、ターゲットホストとリクエスト URI が選択されています。ターゲットホストを使用することで、大きなレイテンシを発生させている API プロキシ内のターゲットエンドポイントに絞り込んでいます。リクエスト URI フィルタを適用することで、大きなレイテンシが発生している個々の API リクエストに関連する問題をトラブルシューティングできます。特定のリクエスト URI が大きなペイロードを処理しているか、複雑なオペレーションを処理しているとき、トラブルシューティングを必要とする大きなレイテンシが発生していることが示唆されています。次のスクリーンショットは、3 番目のディメンションとしてリクエスト URI を使用したサンプルレポートです。

クライアント固有の問題をトラブルシューティングするために、ディメンションとしてクライアント IP が追加されています。次のスクリーンショットは、4 番目のディメンションとしてクライアント IP を使用したサンプルレポートです。

2. レスポンスコード分析

API の健全性やユーザーエクスペリエンスの全体像をすばやく把握できるレスポンスコード分析は重要です。200 OK、404 Not Found、500 Internal Server Error などのレスポンスコードを確認することで、成功か失敗かをすぐに理解できます。レスポンスコード分析は API の信頼性の向上に効果的です。問題が発生する前に修正や最適化を行えるためです。

このレポートでは、ターゲットホスト、リクエスト URI、ターゲットレスポンスコードなどのディメンションを使用してフィルタを適用します。エラーの傾向の可視化や、バックエンドシステム内の問題の特定、エラーが頻繁に発生しているリクエストの特定を行います。

レスポンスコード分析レポートを作成する手順は次のとおりです。

指標として sum(traffic) を選択する
ディメンションとしてプロキシ ベースパス、ターゲット ホスト、リクエスト URI、ターゲット レスポンス コードを選択する
フィルタを適用してデータを限定する
期間を指定してカスタムレポートを実行する

以下は、サンプルのカスタムレポートのスクリーンショットです。

次のスクリーンショットは、別のディメンションとしてリクエスト URI を使用したサンプルレポートです。

3. API プロダクトパフォーマンス分析

このレポートでは、API プロダクトのパフォーマンスに関する実践的な分析情報を詳細に、各デベロッパーアプリ / クライアント IP ごとに把握することが可能で、以下のような機能を利用できます。

デベロッパー アプリケーションの詳細なトラブルシューティング: API プロダクト、デベロッパーアプリ、リクエスト URI、レスポンスステータスコードなどのディメンションを組み合わせて使用することで、エラーが発生している場所と条件を正確に突き止めることができます。これにより、特定の API 顧客の問題の解決で勘に頼る必要はなくなります。
クライアントに着目した分析情報: API プロダクトの利用に深くかかわる人は、主にデベロッパーやクライアントです。「クライアント IP アドレス」のディメンションは、個々のクライアントに関連するエラーの分離に役立てることが可能で、利用者側の潜在的なネットワークの問題や構成エラーの特定に有用です。
API プロダクト ユーザーのパフォーマンスとエラーの相関関係: エラー指標とともに「avg(total response time)」を含めることで、遅い応答がエラーの原因になっているか、エラーが全体としての API パフォーマンスに影響しているかを確認できます。

アプリデベロッパー向けのレスポンスコード分析レポートを作成する手順は次のとおりです。

指標として sum(traffic) と avg(total response time) を選択する
ディメンションとしてデベロッパー アプリ、API プロダクト、プロキシ ベースパス、ターゲット ホスト、レスポンス ステータス コード、クライアント IP アドレスを選択する
フィルタを適用してデータを限定する
期間を指定してカスタムレポートを実行する

以下は、サンプルのカスタムレポートのスクリーンショットです。

4. キャッシュヒット分析

キャッシュヒット分析は、Apigee のキャッシュシステムがどの程度うまく機能しているかを把握するために必須であり、API の速度とユーザーエクスペリエンスの改善に役立ちます。この分析で得られる Apigee キャッシュのキャッシュヒット値は、キャッシュシステムを評価する際に重要なパラメータとなります。カスタムレポートでリクエスト URI などのディメンション、キャッシュヒットや総トラフィックなどの指標を使用すれば、Apigee のキャッシュパフォーマンスを詳細に把握できます。

キャッシュヒット分析レポートを作成する手順は次のとおりです。

指標として sum(cache hit) と sum(traffic) を選択する
ディメンションとしてプロキシ ベースパスとリクエスト URI を選択する
フィルタを適用してデータを限定する
期間を指定してカスタムレポートを実行する

以下は、サンプルのカスタムレポートのスクリーンショットです。

API プロキシ内の特定のリクエスト URI のキャッシュのパフォーマンスを見るには、プルダウンでリクエスト URI のディメンションを選択してカスタムレポートを生成します。

5. ユーザーエージェント分析

API 利用者が使用しているデバイス、ブラウザ、オペレーティングシステムを把握できる Apigee のユーザーエージェント分析も重要です。この分析情報から、デバイスやブラウザ固有の互換性に関する問題の特定や、詳細なログに基づくエラーのデバッグ、ユーザーエクスペリエンスを向上させるカスタムの API レスポンスの構築などを行えます。悪意のある bot や不審なアクティビティを検出し、セキュリティを強化することもできます。

ユーザーエージェント分析レポートを作成する手順は次のとおりです。

指標として sum(traffic) を選択する
ディメンションとしてプロキシ ベースパス、ターゲット ホスト、ユーザー エージェント / ユーザー エージェント ファミリー / ユーザー エージェント タイプ、レスポンス コードを選択する
フィルタを適用してデータを限定する
期間を指定してカスタムレポートを実行する

以下は、サンプルのカスタムレポートのスクリーンショットです。

6. API ロケーション分析

リクエスト URI ごとの API ロケーション分析は、API の特定のエンドポイントにヒットするトラフィックの地理的な起点を把握するために必要です。この分析を活用すると、ネットワークの問題やリージョン単位での停止などを原因とした特定の地域に固有の問題や、地理的距離が関係するパフォーマンスの問題を特定しやすくなります。また API を通じて、ローカライズされたコンテンツを地域に応じて正しく配信したり、不正行為検出の一環として不審なロケーションパターンにフラグを立てたりする際にも、この分析は役立ちます。他にも、パフォーマンスの最適化（コンテンツ配信やリソースの配置など）や、データプライバシーに関する規則の遵守、地域に合わせたトラブルシューティングの実践、事前対応型のキャパシティプランニング、さらには、地域ごとの API 使用パターンを考慮して情報に基づく意思決定を行うというマーケティングの領域において強みを発揮します。

キャッシュヒット分析レポートを作成する手順は次のとおりです。

指標として sum(traffic) と avg(total response time) を選択する
ディメンションとしてプロキシ ベースパス、ターゲット ホスト、地域を選択する
フィルタを適用してデータを限定する
期間を指定してカスタムレポートを実行する

以下は、サンプルのカスタムレポートのスクリーンショットです。

カスタムレポートにアクセスする

Google Cloud コンソールからのレポートの取得方法:

1. UI でカスタム レポート機能に移動する

保存されているレポートで、カスタムデータを取得する
環境と期間を選択して、選択した指標を確認する（指標は選択したディメンションでグループ化されます）

2. （期間が短い場合）レポートを UI からリアルタイムでダウンロードする

[エクスポート] をクリックしてレポートを CSV 形式でダウンロードする
（任意）CSV ファイルをスプレッドシートソフトウェアで開く

3. （期間が長い場合）レポート ジョブを使用してレポートを非同期で生成する

[ジョブを送信] をクリックする
環境と期間を選択して、選択した指標を確認し、[作成] をクリックする（指標は選択したディメンションでグループ化されます）
ジョブが完了したら、[レポートジョブ] をクリックしてレポートをダウンロードする
スプレッドシートソフトウェアで CSV を開く

リアルタイムとレポートジョブの選択の基準については、ドキュメントをご覧ください。

以下は、ダウンロードされて Google スプレッドシートにインポートされたサンプルのレポートのスクリーンショットです。

また、Apigee の管理用 API でカスタムレポートを作成して利用することもできます。

復習用: レポート作成の操作手順

以下に示す手順に沿って、新しいカスタムレポートを作成できます。

https://apigee.google.com/organizations/<project-name>/analytics/custom-reports にアクセスします。[+カスタムレポート] をクリックします。
レポートの名前とレポートの説明をそれぞれ対応するフィールドに入力します。
記録する指標を選択します。その指標に対して実行する集計関数を選択します。
まずプロキシに対して、次いでプロキシ内にスコープされた特定のリソースに対して、1 つ以上のディメンションを順番に選択します。
フィルタを使用して、結果を特定の条件を満たす指標に制限します。このステップは任意です。
すべてのパラメータが選択されたら、レポートを保存します。

カスタムレポートを使用して API パフォーマンスを追跡する

カスタムレポートは Apigee プラットフォームで利用できる応用範囲の広い機能です。詳細かつ柔軟にデータを分析できるので、API パフォーマンスをトラッキングできるのはもちろん、さまざまな関係者の多様な要求にも応えます。利用を開始するには、Google Cloud コンソール内のカスタムレポート機能か、Apigee の管理用 API を使用します。さらに高度な可視化と分析については、Looker Studio との統合をご覧ください。

詳しく知りたい場合は、Apigee で API を最大限活用するために Google Cloud コンサルティングのエキスパートがどのようにお役に立てるか、また、お客様が学習、構築、運用し、成功を収めるうえで Google Cloud コンサルティングサービスをどのように活用できるかをご確認ください。

^{1. IP アドレスを対象にしたターゲットサーバー分析は簡単に行えますが、その有効性は、単一のターゲットサーバー IP が複数のマイクロサービスをサポートする Apigee を使用した ASM デプロイなどの一部のシナリオで制限される可能性があります。}

-戦略的クラウド エンジニア Aakanksha Nikhare

-戦略的クラウド エンジニア Ayush Gupta

Apigee で DialogFlow CX の chatbot のセキュリティを強化する

Tue, 25 Jun 2024 02:20:00 +0000

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

chatbot を作成したいと考える組織の多くが、Google Cloud のサービスである Dialogflow を利用します。Dialogflow は、自然言語を理解して応答できる会話型エージェントを作成するためのサービスです。2 つのエディションが用意されていますが、多くの組織は高度な chatbot 機能を利用するために Dialogflow CX を選択します。ただし、ミドルウェアソリューションがない状態で chatbot をウェブサイトに統合してしまうと、サービスアカウントキーのような機密性の高い認証情報をフロントエンドに直接挿入したり、認証されていない URL を使用したりする恐れがあります。本番環境グレードのシステムにとって、これはおすすめの方法ではありません。エージェントと Google プロジェクト ID が公開され、脆弱な状態になる可能性があります。

このリスクは、フロントエンドと DialogFlow CX API の間に Apigee レイヤを導入することで軽減できます。Apigee は Google Cloud が提供するフルライフサイクルの API 管理プラットフォームで、企業が API を設計、保護、公開、分析、モニタリング、収益化できるようにします。また、バックエンドサービスとそれにアクセスするクライアントとの間の堅牢なレイヤとして機能し、多数の機能や利点を提供します。この際、Apigee は以下を可能にします。

認証と認可の一元化: Apigee は安全なゲートウェイとして機能し、すべての認証プロセスと認可プロセスを処理します。これにより、フロントエンドで認証情報を公開する必要がなくなります。
アクセス制御: Apigee では、アクセスポリシーを詳細に定義し、特定の DialogFlow CX API とやり取りできるフロントエンドコンポーネントを判断できます。
API キーの管理: Apigee は API キーの管理を支援し、侵害が生じた場合のローテーションプロセスや取り消しプロセスを簡素化します。
脅威からの保護: Apigee は、レート制限、割り当て管理、Spike Arrest などの組み込み機能を提供し、不正行為や潜在的な攻撃から API を保護します。

Apigee を仲介役として使用することにより、chatbot 統合のセキュリティを強化できるだけでなく、API を管理、モニタリングするための強力なツールも獲得できます。この投稿では、会話型エージェントのセキュリティを高める Apigee の構成方法をご紹介します。

会話型エージェント用 Apigee プロキシの作成と構成

まず、Google Cloud 上で Apigee のインスタンスを作成するか、既存のインスタンスを再利用します。評価用インスタンスを設定する方法については、こちらをクリックしてください。
こちらのガイドを使用して DialogFlow CX エージェントを作成します。
コンソールからエージェント ID とロケーションを抽出して、手近なところに保存しておきます。

4. サービスアカウントを作成し、「DialogFlow API Client」ロールを付与します。

5. apigee.google.cloud にアクセスし、[Reverse Proxy]（リバースプロキシ）タイプの [Create a Proxy]（プロキシを作成）をクリックして、「myproxy」などと名前を付けます。

6. ターゲットエンドポイントを DialogFlow CX Detect Intent API として構成し、プロジェクト ID、エージェント ID、ロケーションを適切に置き換えます。

code_block: <ListValue: [StructValue([('code', 'https://<location>-dialogflow.googleapis.com/v3/projects/<project-id>/locations/<location>/agents/<agent-id>/sessions/abc:detectIntent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4abb8efee0>)])]>

7. [Proxy Develop]（プロキシ開発）タブで、以下のように <GoogleAccessToken> と <Scopes> を HTTP ターゲット接続に追加します。

8. 利用可能な環境にプロキシをデプロイします。このステップでは、先ほど作成したサービスアカウントを使用することが重要です。このサービスアカウントは、DialogFlow CX API へのリクエストを認証するために使用されます。

9. 任意の API クライアントを使ってプロキシをテストします。DialogFlow CX Intent API からの応答が表示されます。

すばらしいですね。プロキシが動作し、DialogFlow CX とやり取りをしています。

Apigee のデバッグコンソールで、リクエストのすべての経路をトレースできます。

次のステップ

初めてのプロキシが機能したので、次のステップに進む準備ができました。次のことが可能です。

Apigee Oauth ポリシーを構成して、フロントエンドからプロキシを呼び出すユーザーの認証処理を追加する
要件に応じて Spike Arrest ポリシーと割り当てポリシーを追加する

この Apigee プロキシ URL は、ウェブサイトや chatbot のフロントエンドに埋め込んで使用できます。Apigee プロキシを使用することにより、効率的な API 管理、ユーザーアクセス制御、割り当て管理、そして API のモニタリングや収益化が可能になります。

ー Google Cloud、戦略的クラウド シニア エンジニア Pallavi Vageria

commercetools と Google Cloud Application Integration で e コマースエクスペリエンスを構築する

Fri, 07 Jun 2024 01:00:00 +0000

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

デジタルコマースの世界は急速に進化しています。企業が競争力を維持するには、自社のコマースシステムを幅広いアプリケーションやサービスと統合できるようにする必要があります。さらに、顧客はターゲットを絞った、パーソナライズされたエクスペリエンスを期待しています。Google の AI およびデータソリューションは、e コマースソリューション内で顧客にパーソナライズされたエクスペリエンスを提供する機会を生み出します。これは、AI を活用した検索機能、商品レコメンデーション、AI chatbot、AI によるコンテンツ作成などを実装することで実現できます。これらの機能を実装し始めた組織は、Google Cloud サービスをクラウドネイティブのヘッドレスコマースプラットフォームである commercetools に接続できるようになると、大きな価値が得られます。

Google Cloud の Application Integration は、Integration-Platform-as-a-Service（iPaaS）ソリューションで、さまざまなアプリケーションやサービス間でのデータ接続と管理を合理化するツールを備えています。Google は最近、commercetools コネクタ（現在公開プレビュー版）をリリースしました。これを利用して、ユーザーは、e コマースプラットフォームと Google Cloud ソリューション、および 80 を超えるコネクタのライブラリで利用可能な他のプラットフォームとの間でのインテグレーションを加速できます。commercetools コネクタを利用して、commercetools のデータを BigQuery や Vertex AI などの Google Cloud サービスと統合することで、ユーザーは e コマース内で幅広い分析と ML 機能を利用できるようになります。たとえば、commercetools のデータをモデルのプロンプトとして使用してパーソナライズされた分析情報を生成したり、BigQuery に入力された commercetools のデータを活用して BigQuery ML で ML モデルを作成して実行したりできます。

このブログ記事では、commercetools コネクタのさまざまな機能と、それを活用してカスタマーエクスペリエンスを向上させるいくつかのユースケースをご紹介します。

commercetools プラットフォームを Google Cloud と接続する

commercetools は、コンポーズ可能なコマースプラットフォームを提供する会社で、450 社を超える企業に、デジタルタッチポイントでも物理的なタッチポイントでも優れたショッピング体験を実現するために必要なコンポーネントを提供しています。世界最大手の企業が、commercetools が提供するツールを利用して、将来を見据えたデジタルサービスを実施し、リスクと費用を削減し、収益増加を図っています。

commercetools コネクタは、新たなレベルのインテグレーションを可能にし、次のようなさまざまなのメリットをもたらします。

インテグレーションの簡素化: commercetools プラットフォームと、Google の Application Integration で利用できるコネクタ、タスク、サービスの豊富なエコシステムとの接続を確立します。事前に構築されたコネクタにより、BigQuery、Vertex AI、Pub/Sub、Cloud Spanner などの Google ファーストパーティサービスや、コネクタを持つサードパーティシステムと簡単に統合できます。インテグレーションの処理は Application Integration に任せて、データマッピングタスクを使用してデータ変換のニーズに簡単に対応できます。これにより、製品化までの時間を短縮し、開発費用を削減できます。
データフローの強化: BigQuery や Vertex AI などの Google Cloud サービスを、事前構築されたコネクタと vertex AI 予測タスクとともに使用することで、e コマース向けの高度なデータ分析と ML が可能になります。インテグレーションタスクを使用して、これらのアプリケーション間のデータフローをオーケストレートおよび変換します。こうして設計したインテグレーションフローを使用して、ビジネス分析、インテリジェントな商品のおすすめ、パーソナライズされたプロモーションなどを促進できます。

イノベーションの加速: e コマースプラットフォーム用のカスタムインテグレーションの構築と維持にかかる技術的なオーバーヘッドを削減します。Application Integration を使用して、ドラッグ＆ドロップインターフェースで commercetools と Google Cloud 間のインテグレーションを構築することで、デベロッパーリソースが解放され、革新的なカスタマーエクスペリエンスの構築に注力できます。

commercetools コネクタは、次のようなさまざまなユースケースに利用できます。

1. commercetools のデータを BigQuery へ: commercetools コネクタは、リアルタイムデータを commercetools から BigQuery に転送して、組織が顧客データを活用して分析情報を獲得し、カスタマーエクスペリエンスを改善してコンバージョン率を向上させるのに役立ちます。

次の例は、commercetools から BigQuery に商品データを push する方法を示しています。API 呼び出しによってインテグレーションがトリガーされます。ただし、スケジューラ、Pub/Sub メッセージなど、使用可能なトリガーはどれでも使用できます。次に、Application Integration が、commercetools から商品データを取得し、反復処理ループに進みます。このループでは、すべての商品のサブインテグレーションを呼び出し、すべての商品を収集して BigQuery に保存します。

BigQuery にある commercetools のデータを使用して、e コマースやその他の多様なデータソースからのデータを組み合わせて、情報に基づいたデータドリブンな意思決定を行うことができます。

2. オンデマンドの AI を活用した分析情報: Vertex AI を使用してオンデマンド予測を生成することで、e コマースを強化します。イベントを使用して予測をトリガーすると、これがテキストプロンプトに対する応答の生成、商品のおすすめの生成、商品の需要の予測など何であっても、Vertex AI モデルからリアルタイムの回答を得ることができます。

以下の例では、Pub/Sub メッセージを使用して、Application Integration で Vertex AI タスクを使用した Vertex AI 予測をトリガーしています。commercetools の商品データを抽出し、それを Vertex AI モデルのプロンプトとして使用して、e コマース商品の商品説明を生成しています。AI が生成した商品説明を使用して commercetools の商品を更新することで、これをさらに一歩進めることができます。

この種のインテグレーションフローは、e コマースプラットフォームデータを接続して、Vertex AI から AI の分析情報を直接引き出すのに役立ちます。

3. e コマースのパーソナライゼーション: ユーザーは今では、多数のデバイスに接続されており、意思決定を行うまでに複数のデジタルインタラクションポイントに到達します。たとえば、購入者は、購入する前にウェブサイトと検索エンジンの両方で検索する傾向があります。そのため、さまざまなチャネルにわたってパーソナライズされたエクスペリエンスを提供することがますます重要になっています。commercetools を使用して、チャネル間でデータの整合性を保つことで、オムニチャネルの e コマース戦略を実現できます。commercetools コネクタは、commercetools を Google Cloud 上の顧客データプラットフォーム（CDP）およびレコメンデーションエンジンと統合し、顧客データの一元的なハブを作成して、さまざまなチャネルにわたって一貫したパーソナライゼーションを促進することで、この戦略をさらに一歩進めるのに役立ちます。

これら 2 つの主要なプラットフォームの力を組み合わせることで、企業は成長と成功を促進する優れたカスタマーエクスペリエンスを生み出すツールを獲得できます。今すぐ始めましょう: Google Cloud Marketplace で使用可能な commercetools を見つける。Commercertools と Google のパートナーシップに関するページにアクセスする。Application Integration と commercetools コネクタの詳細を見る。

-Google Cloud、ISV パートナーエンジニア、Maria Alejandra Emmanuelli

-commercetools、エンジニアリング責任者、Siawash Shibani 氏

Google Cloud 環境向けのシャドー API 検出のご紹介

Fri, 19 Apr 2024 01:25:00 +0000

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

企業は平均 200 を超える多数の API を運用しており、その数は増え続けています。いずれの API も機密データのフロントドアとなる可能性があります。もっと対応が困難なのは、こうした API の中でどれがアクティブに管理されていない「シャドー API」なのかを特定することです。シャドー API は良かれと思ってなされた開発イニシアチブとレガシーシステムから生まれ、適切な監視やガバナンスなしで動作し、有害なセキュリティインシデントを引き起こす可能性があります。

このたび開催される Google Cloud Next では、Apigee API Management ソリューションに含まれる Advanced API Security のシャドー API 検出機能（プレビュー版）を発表いたします。

Apigee API Management で API を保護する

Apigee は、クラウドとオンプレミスで API を構築、管理、保護できる Google Cloud のターンキー API 管理ソリューションです。Apigee は、きめ細かい制御に加え、認証や認可などの 50 種類を超える組み込みのセキュリティポリシーにより、API トランザクションの信頼性を確保できます。

Advanced API Security は、API の構成ミスを特定し、悪意のある bot 攻撃やビジネスロジック攻撃を検出するために先を見越して機能し、組織が迅速に対策を講じて脅威を軽減できるようにします。以前、この保護機能はアクティブに管理されている API でのみ使用できました。このたび、Advanced API Security でシャドー API を検出する機能が加わったことで、見つけにくい盲点をなくしてセキュリティのギャップを埋められるようになりました。

Advanced API Security でシャドー API を検出する

Advanced API Security が Google Cloud のリージョン外部アプリケーションロードバランサと統合され、特定リージョン内の API トラフィックを検出、特定して規制要件とパフォーマンス要件をサポートできるようになりました。

次の例は、ベルギーリージョン（europe-west-1）での実際の動作を示しています。

Google Cloud の外部アプリケーションロードバランサのリージョンを選択すると、関連する API を見つけることができます。

Advanced API Security はロードバランサを通過するリクエストとレスポンスを検査することで、API とその関連情報（API エンドポイント、プラットフォーム、プロトコル、パラメータ名、レスポンスなど）を抽出します。直感的なインターフェースを通じて、API が動作している場所や、実行されているオペレーションの種類、API の最新アクティビティについて重要な詳細にアクセスできます。

Advanced API Security は、選択したロードバランサにリンクされているすべての API をカタログ化して整理します。

シャドー API 検出では、履歴データも参照して新しい API 呼び出しを発見し、新たなシャドー API の認識や検出を常時行えます。さらに注意が必要な個々のエンドポイントにタグを付けて、API サーフェス全体で包括的な保護を確保することができます。

ロードバランサに関連付けられたシャドー API エンドポイントの詳細情報

シャドー API を検出すると、API オーナーと協力して、全社的なセキュリティおよび API 管理標準に従って管理を確立できます。不足しているセキュリティ対策を実装して、侵害のリスクを軽減することもできます。

シャドー API 検出機能の利用を開始する

Advanced API Security でシャドー API を検出すれば、セキュリティ対策を強化し、アプリケーションインフラストラクチャに潜む脆弱性を見つけるためのさらにプロアクティブなアプローチを導入することができます。シャドー API 検出機能を使える Advanced API Security にアクセスするには、今すぐお申し込みください。

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

-Google Cloud、プロダクト マネージャー Shelly Hershkovitz

Gemini Code Assist を使用して、API、インテグレーション、自動化フローを構築する

Mon, 15 Apr 2024 03:00:00 +0000

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

API とアプリケーション間のインテグレーションは、現代のアーキテクチャのデジタル神経系を形成します。API はさまざまな環境やシステムに広がるデータソースにインテリジェンス（AI モデルやアプリ）を接続する経路であり、インテグレーションは SaaS ワークフロー全体でインテリジェントなアクションを促します。しかし、このような API やインテグレーションを構築するには、多くの場合、専門知識が必要であり、さらに一貫した標準と品質を確保するために多くの時間とリソースが必要となります。

このたび、Google Cloud の Apigee API Management と Application Integration（公開プレビュー版）で Gemini Code Assist をご利用いただけるようになりました。Gemini Code Assist は、特別な専門知識を必要としない自然言語プロンプトを使用して、エンタープライズグレードの API とインテグレーションを構築するプロセスを簡素化します。

Gemini Code Assist: 各企業に合わせてカスタマイズされた AI アシスタント

既製の AI アシスタントは API とインテグレーションの構築を支援できますが、企業はそれぞれ独自の要件、スキーマ、データソースを持っているため、そのプロセスには依然として時間がかかります。AI アシスタントがこのコンテキストを理解しない限り、ユーザーは手作業でこれらの項目に対処する必要があります。

Gemini Code Assist は、セキュリティスキーマ、API パターン、インテグレーションといった企業のコンテキストを理解し、それを使用してユースケースに合わせてカスタマイズされた推奨事項を提供します。さらに、Gemini Code Assist を使用することで、ゼロからプロンプトを入力するのではなく、開発中に既存の API やインテグレーションを反復処理できます。最後に、Gemini の予測的な提案は新しいアイデアを生み出します。

API の構築に Gemini Code Assist を使用する

Apigee は、あらゆるユースケースや環境（クラウドまたはオンプレミス）で API を構築、管理、保護するための Google Cloud のターンキー API 管理ソリューションです。Google Cloud コンソールから、または Cloud Code プラグインを介して VS Code のような一般的に使用されている IDE から、Apigee にアクセスできます。

そしてこのたび、Gemini Code Assist を使用することで、専門知識がなくても、一貫した品質の API を Apigee で作成できるようになりました。API Hub にある既存の API 仕様が要件を満たしていない場合、Gemini を使用して必要なものを自然言語で記述するだけで、新しい API を作成できます。Gemini Code Assist は、API Hub にあるセキュリティスキーマや API オブジェクトなどのアーティファクトを考慮し、それを使用してお客様に合わせた仕様を作成します。これにより、開発およびレビューサイクルの時間を大幅に節約できます。

Gemini Code Assist を使用して、カスタマイズされた一貫性のある API 仕様を生成

Apigee では、実際の API の動作をシミュレートし、API Hub に仕様を公開することで、並行して複数の開発ストリームをテスト、実行できます。

Gemini Code Assist provides guidance and explanations during API proxy creation

さらに Gemini は、API プロキシの作成時に、新しいポリシー構成を追加するための詳細なガイダンスを提供します。最後に、Gemini は既存の構成に対する説明も提供するため、アップデートやメンテナンスに必要な習得期間が短縮されます。

Gemini Code Assist を使用してインテグレーションと自動化を構築する

Application Integration は Google Cloud の Integration Platform as a Service（iPaaS）であり、自社開発の SaaS かサードパーティの SaaS かを問わず、あらゆるアプリケーションをマウス操作だけで簡単に接続してビジネスプロセスを自動化します。その直感的なインターフェースにより、複雑なフローを構築し、データをマッピングし、事前に構築されたタスクやトリガーを使用して業務を効率化できます。

そしてこのたび、Gemini Code Assist を使用することで、チームの誰もが要件を記述するだけで、Application Integration でエンドツーエンドの自動化フローを作成できるようになりました。たとえば、バグトラッキングシステム（JIRA など）に問題が新規作成されたときに、Gemini を使用して CRM（Salesforce など）でケースを更新するタスクを自動化できます。Gemini にプロンプトを発行するか、インターフェースで提供されるワンクリック提案を使用できます。Gemini はプロンプトと既存の企業のコンテキスト（API やアプリケーションなど）に基づいて、ユースケースに合わせてカスタマイズされた複数のフローを提案します。

Gemini Code Assist を使用してインテグレーションフローを作成し、SaaS プロセスを自動化

Gemini は企業のコンテキストに従って自動的に変数を作成し、タスクを事前構成し、インテグレーションをすぐに使用できる状態にします。Gemini はプロンプトに応答するだけでなく、フローをインテリジェントに分析し、最適化（コネクタの交換や REST エンドポイント呼び出しのファインチューニングなど）のプロアクティブな提案を行います。また、既存のフローをワンクリックで拡張し、メンテナンスの労力を大幅に削減するのにも役立ちます。

Gemini Code Assist からの予測的な提案によってインテグレーションフローを拡張

Application Integration インターフェースは視覚的にわかりやすいため、フローを理解しやすく、新規ユーザーでも簡単に使い始めることができます。Gemini は既存の構成に基づいてインテリジェントな説明を自動的に生成できるため、インテグレーションをより早く導入できます。

使ってみる

API とインテグレーションは、AI モデルとアプリケーションによって差別化されたエクスペリエンスを提供するために不可欠な構成要素です。Gemini Code Assist を使用すると、企業の品質基準に準拠しながら、これらの API とインテグレーションを構築するトイルを大幅に削減できます。数週間以内に、Gemini Code Assist（公開プレビュー版）を使用して、Apigee や Application Integration 内での API とインテグレーションの構築を簡素化できるようになります。

-Google Cloud、プロダクトマネージャー Michael Vakoc
-Google Cloud、プロダクトマネージャー Pramodh Ramesh

Gemini で Google Cloud を強化

Wed, 10 Apr 2024 01:00:00 +0000

※この投稿は、2024 年 4 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

この度、Gemini for Google Cloud を発表できることを嬉しく思っています。生成 AI の機能はここ 1 年で驚異的な成長を遂げ、私たちの製品ポートフォリオ全体に浸透しています。

Gemini for Google Cloud は、開発者、Google Cloud サービス、およびアプリケーション向けの新世代の AI アシスタントです。ユーザーがより効果的に作業およびコーディングを行い、より深いデータのインサイトを取得し、セキュリティ上の課題に対処できるよう支援します。Google の Gemini ファミリーのモデルを使用した Gemini for Google Cloud により、お客様はクラウド上でより多くのことを達成できます。

Gemini for Google Cloud は、堅牢なセキュリティ、コンプライアンス、プライバシー制御を実現するエンタープライズ対応の AI 機能を提供し、業界をリードする可用性を備えています。

Gemini を Google Cloud に統合する方法を詳しく見てみましょう。

Gemini Code Assist でソフトウェアデリバリーを加速

Google Cloud は、Duet AI for Developers の進化形であり、最新の Gemini モデルを使用した Gemini Code Assist を発表しました。開発者が VS Code や JetBrains などの一般的なコードエディターでより高速かつ高品質なアプリケーションを構築できるよう、AI を活用した支援を提供します。Gemini Code Assist は、オンプレミス、Gitlab、Github、Bitbucket、さらには複数のリポジトリなど、どこにあってもプライベートコードベースをサポートするエンタープライズグレードのコーディング支援ソリューションです。堅牢なエンタープライズ機能で構築されているため、組織はセキュリティ、プライバシー、コンプライアンスの要件を満たしながら、大規模に AI 支援を導入できます。

「当社は Google Cloud の Gemini Code Assist のローンチパートナーとして、LLM ベースのコードアクセラレーションワークフローを導入したことで、効率が 30% 以上向上しました。Gemini Code Assist のコード補完機能とバグ解決機能により、作業時間を削減でき、イノベーションと生産性の限界を押し広げることができ、嬉しく思っています。」 - Quantiphi Inc.、共同創業者 Asif Han 氏

Google Cloud Next ‘24 では、Gemini Code Assist の新機能を紹介しています。

コードベース全体の認識 (現在プライベートプレビュー中) : 新機能の追加、ファイル間の依存関係の更新、バージョンアップグレードの支援、包括的なコードレビューなど、コードベース全体に対して、大規模な変更を実行できます。この機能は、業界最大の 100 万トークンのコンテキストウィンドウを提供する Google の Gemini 1.5 Pro モデルによって強化されています。
コードのカスタマイズ (現在プライベートプレビュー中) : 企業はプライベートコードベースを接続して Gemini Code Assist を調整し、開発者がコンテキストアウェアなコード生成を提供できるように支援します。さらに、Gemini Code Assit が GitLab、GitHub、Bitbucket などの複数のソースコードリポジトリにアクセスするための接続も提供しています。

「Gemini Code Assist と RAG を使用したコードのカスタマイズにより、コードの補完と生成の観点で、Gemini の開発者支援の質が大幅に向上しました。コードのカスタマイズにより、全体的なコード受け入れ率が大幅に向上することを期待しています。」 - Turing、エンジニアリングディレクター兼生成 AI 責任者 Kai Du 氏

統合サービス: Apigee と Application Integration で Code Assist の範囲を拡大し、アプリケーションにシームレスにアクセスおよび接続できるようにしました。
エコシステムの強化: 2023 年 12 月のエコシステムの発表に続き、現在、Datadog、Datastax、Elastic、HashiCorp、Neo4j、Pinecone、Redis、Singlestore、Snyk、Stack Overflow を含む複数のパートナーからのデータとナレッジソースを使用して Gemini Code Assist を改善しています。

「Stack Overflow が Google Cloud の最新の AI テクノロジーを採用し、Google Cloud が当社の知識を AI ツールに統合するなど、AI に焦点を当てたこの画期的なパートナーシップは、開発者の創造性を解き放ち、精度を犠牲にすることなく生産性も向上し、社会的責任のある AI を提供するという両社の共同コミットメントを強調しています。両社の強みを結集することで、さまざまな業界でイノベーションを加速させることができます」 - Stack Overflow、CEO Prashanth Chandrasekar 氏

Gemini Cloud Assist でアプリケーションのライフサイクルを効率的に管理

Gemini Cloud Assist は、クラウドチームがアプリケーションのライフサイクルを設計、運用、最適化するのに役立ちます。Gemini のコンテキストに応じてパーソナライズされた AI ガイダンスは、Google Cloud リソースを理解し、新しい設計の作成、ワークロードのデプロイ、アプリケーションの管理、問題のトラブルシューティング、パフォーマンスとコストの最適化に貢献します。複雑なタスクを加速し、生産性を向上、ビジネスへの集中を支援する Gemini Cloud Assist にて提供される機能は以下の通りです。

目標主導型の設計: Gemini Cloud Assist に希望する設計結果を説明すると、ニーズに合わせたアーキテクチャ構成が生成されます。また、その提案の理由も説明します。
ガイド付き操作とトラブルシューティング: Gemini Cloud Assist は問題を診断し、根本原因を特定し、解決策を推奨、インシデントの迅速な解決を支援します。
カスタマイズされた最適化: コスト削減、パフォーマンス、高可用性のいずれを優先する場合でも、Gemini Cloud Assist は強化すべき領域を特定し、目標を達成する方法を提案します。

Cloud Assistは、アラートの要約、ログの説明、コンテキストに応じたトラブルシューティングで時間を節約します。

Gemini Cloud Assist は、Google Cloud コンソールのチャットインターフェースから直接アクセスでき、さまざまなクラウド製品やリソースを管理するインターフェースに直接埋め込まれます。Gemini Cloud Assist は現在プライベートプレビュー中です。

「Gemini Cloud Assist は、Google Cloud 環境の最適化に有用で、発生した問題のトラブルシューティングに役立ちます」 - Ford Motor Company、エンタープライズアーキテクト Sai Dutta 氏

Gemini in Security でセキュリティの専門性を向上

2023 年、Google Cloud は防御側に生成 AI を一般提供した市場初の大手クラウドプロバイダーの 1 社になりました。そしてこの度、Gemini in Security Operations を Chronicle に追加し、セキュリティチームのスキルおよび生産性を向上させ、脅威をより簡単に検出、調査、対応できるようにしました。2024 年 4 月末に一般提供される新たな調査支援機能は、自然言語を新しい検出に変換し、イベントデータを要約、実行するアクションを推奨するほか、会話型チャット形式のプラットフォームでユーザーを誘導します。

Gemini in Security Operations を使用すると、ユーザーは Chronicle の会話型チャットを使用してインシデントとアラートをすばやく調査できます。

「Gemini in Security Operations は、当社の Cybersecurity Operations Center プログラムの効率を高め、オペレーショナルエクセレンスの推進を可能にしています。」 - Fiserv、サイバーセキュリティオペレーション担当上級副社長 Ronald Smalley 氏

さらに、Google Cloud のセキュリティポートフォリオ全体に新しい AI 機能を導入しています:

Gemini in Threat Intelligence （現在パブリックプレビュー中）：会話型検索を通して Mandiant の最新の脅威インテリジェンスにアクセスし、脅威アクターの行動に関する洞察を数秒で得ることができます。また、関連する Open-Source Intelligence (OSINT) 記事のウェブクローリングを自動化し、情報を取り込み、簡潔な概要を提供することで、アナリストを支援し、脅威調査の効率向上にも貢献します。

Gemini in Security Command Center （現在パブリックプレビュー中）：構成ミスや脆弱性に関する重大かつ優先度の高いアラートを要約し、シミュレートされた攻撃経路内の潜在的なエクスプロイトからの防御方法に関する推奨事項を提供するため、組織はリスクをプロアクティブに軽減できます。

Gemini in Security の機能は SecLM API に基づいて構築されており、Gemini をよりセキュリティに特化し、拡張可能なものにします。

Gemini in Security により、Pfizer などのお客様は、複雑な分析をより迅速に実行し、新人アナリストをより迅速にオンボーディングできるため、経験豊富なアナリストが高度な脅威にかける時間を確保できています。新機能の詳細についてはこちら、Gemini in Security についてこちらをご覧ください。

Gemini in BigQuery で分析とワークフローを高速化

本日、Gemini in BigQuery のプレビュー版も発表しました。Gemini in BigQuery は、取り込みやパイプラインの作成から、AI を活用した機能による価値ある分析情報の導き出しまで、分析ライフサイクル全体にわたって、データエンジニアとデータアナリストの生産性や、クエリのパフォーマンスを向上させるほか、コストを最適化し、業界を一変させます。

Gemini in BigQuery は自然言語のサポートと埋め込みの可視化により、ノートのようなエクスペリエンスを提供する新しいデータキャンバスが付属しています。

あなたが自転車シェアリング会社のデータアナリストだと想像してみてください。Gemini in BigQuery の新しいデータキャンバスを使用して、データセットの探索、上位のトリップの特定、カスタマイズされたビジュアライゼーションの作成を同じインターフェース内で自然言語プロンプトを使用して行うことができます。

Gemini in BigQuery には、データのクレンジングとラングリングでユーザーを支援する AI 拡張データ準備と、ローコードのビジュアルデータパイプラインを構築する機能も含まれています。また、クエリのレコメンデーション、セマンティック検索、ローコードのビジュアルデータパイプライン開発ツール、クエリのパフォーマンスの向上、エラーの最小化、コストの最適化のためのインテリジェントなレコメンデーションも提供します。ユーザーは、自然言語プロンプトを使用して SQL または Python コードを作成し、クエリの作成中にリアルタイムの提案を得ることもできます。

「BigQuery の新しい AI を活用した支援機能と、ほかの Google Workspace 製品との簡単な統合により、当社はデータから貴重な分析情報を抽出できます。自然言語ベースのエクスペリエンス、ローコードデータ準備ツール、自動コード生成機能により、優先度の高い分析ワークフローが合理化され、データ担当者の生産性が向上し、影響の大きいイニシアチブに集中する時間が確保できます。さらに、当社のユーザーにはビジネスユーザーを含んでおり、さまざまなスキルセットを持っていますが、よりアクセスしやすいデータの洞察を活用して有益な変化をもたらし、組織内で包括的なデータドリブンな文化を育むことができています」 - Veo、分析責任者、Tim Velasquez 氏

また、BigQuery から Vertex AI へのシームレスな接続を構築し、BigQuery から Vertex の AI モデルに直接アクセスできるようにしました。これにより、AI モデル、従来の ML 演算子、統計関数をデータパイプラインをシームレスに組み合わせて、マルチモーダル分析を行うことができます。この新機能により、ドキュメント、動画、画像、音声の録音を構造化データとともに分析できます。

Gemini in Looker でインサイトを自動化

Gemini in Looker は、ビジネスデータにチャットでアクセスするための新しい方法をユーザーに提供します。本日、新たに Conversational Analytics をプライベートプレビューで公開し、チャットでビジネスエキスパートに質問するのと同じくらい容易にデータに関する質問をするためのマルチターン機能を提供します。Conversational Analytics は、Looker に専用のスペースを提供し、データを使用してあらゆるトピックに関するチャットを開始、わずか数秒でインサイトを導き出し、発見と分析の次の段階に導きます。

あなたが e コマースプロバイダーであると想像してください。Gemini in Looker に質問をすると、売上の傾向を把握し、グラフの作成方法の詳細を含むインサイトをすぐに調べることができます。

Conversational Analytics に加えて、コードを記述しないでもシャープなビジュアライゼーションとレポートを作成でき、Google Workspace と接続するとチームで共有できるように設計された新機能がパブリックプレビューでリリースされます。

Gemini in Looker は、クエリから作成、検索、共有までのスピードを加速させ、組織内の大多数のユーザーに BI のメリットを提供する、いつでも利用可能なインテリジェントアシスタントです。

Gemini in Databases を使用してデータベースの開発と管理の強化

Gemini in Databases は、データベースにおける作業をあらゆる側面で簡素化する、AI を活用した支援を提供し、チームがより重要なことに集中できるようにします。

開発者、オペレーター、データベース管理者は、自然言語を使用してアプリケーションをより迅速に構築できます。Gemini in Databases は現在プレビュー中で、単一画面からデータベースフリート全体を管理、最適化できるほか、データベースの移行を加速します。

Google Cloud コンソールのリッチな SQL エディタである Database Studio では、SQL の生成と Gemini の要約機能を公開します。開発者は、ベストプラクティスに基づいてコーディングプロセスを加速するための高品質な支援を受けることができるようになりました。さらに、AI 主導のチャットインターフェイスを利用して質問を明確にし、必要に応じてサポートを受けることができます。

オペレーターは、Database Center の単一画面からデータベースフリート全体を管理できます。Database Center は、可用性、データ保護、セキュリティ、コンプライアンスの問題をプロアクティブに評価し、洞察とヒントを提供するインテリジェントなダッシュボードを通じて、データベースフリートの管理を簡素化します。スマートレコメンデーションを使用すると、アシスタントに分析を任せて提供されるアドバイスに従うだけで、パフォーマンスを最適化し、問題のトラブルシューティングを行うことができます。

Gemini in Databasesで、Gemini に「すべての運用データベースは高可用性を備えているか？」と尋ねると、Database Center内で影響を受けるデータベースを確認することができます。

Gemini in Databases は、コード変換を含む Database Migration Service で社内のデータベース移行のラストマイルも支援します。さらに、SQL 開発者のスキルアップとリスキリングを支援するために、生成されたコードと推奨事項の詳細な説明とともに、ダイアレクトを並べて比較できる説明可能性が組み込まれています。

「Gemini in Databases を使用することで、フリートの健全性を数秒で確認することができ、アプリケーションに対する潜在的なリスクをこれまで以上に迅速に、プロアクティブに軽減できます」 - Ford Motor Company、データベーステクノロジー技術専門家 Bogdan Capatina 氏

Gemini for Google はすでにエンタープライズ対応

Google Cloud では、特に大企業の厳しいニーズに対応すべく Gemini for Google Cloud を設計しました。Gemini for Google Cloud が既存システムと統合されると、効率がすぐに向上します。また、データのセキュリティとプライバシーがお客様にとって重要であることを認識しており、コア機能として強力な保護を提供します。

運命の共有: 私たちは AI を取り巻く潜在的な著作権問題を理解しており、著作権を理由に異議を申し立てられた場合、生成 AI の補償に伴う潜在的な法的リスクは当社が責任を負います。
データの管理: 企業の要件を満たすため、データの所在地を選びつつ、Google Cloud の広大でスケーラブルなネットワークのメリットを享受できます。
責任あるデプロイ: Gemini は責任ある AI を念頭に置いて構築されており、ソースを追跡し、AI の応答を独自のデータに直接結びつけて、説明責任を高めることができます。

AI があなたのためにできることを想像してみてください

Gemini for Google Cloud を使用すると、開発者からクラウドオペレーター、セキュリティオペレーター、ビジネスアナリストに至るまで、誰もが AI の力を活用できます。業界における AI イノベーションのペースは今後も加速していくでしょう。Google Cloud は、お客様が今すぐ価値を生み出せる、生産的で責任あるイノベーションを提供します。当社のお客様はすでに、生産性の向上、市場投入までの時間の短縮、運用コストの削減、セキュリティ体制の向上を実感しています。AI を活用したビジネス変革はまだ始まりにすぎないのです。

-- Google Cloud バイスプレジデント兼ジェネラルマネージャー Brad Calder

TPG Telecom: Apigee を使用して API の配信時間を 50% 短縮

Fri, 22 Mar 2024 01:15:00 +0000

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

TPG Telecom は、大規模な合併および買収（M&A）と有機的成長に基づいた戦略を掲げるオーストラリア通信業界の新星です。Vodafone、TPG、iiNet、AAPT などのブランドを擁する TPG は、広範なモバイルおよびファイバーネットワークを通じて 500 万人のモバイルユーザーと 220 万人の固定ブロードバンド利用者に各種サービスを提供しています。

API は 3 つの意味で TPG のビジネスに不可欠です。顧客体験の観点からは、顧客関連のサービスを中心に統合型 API が運用されています。また、ネットワークや支払い関連のサービスにも API が使用されています。M&A ベースの成長戦略を採用している TPG では、API 機能を備えた複数の技術スタックとシステムを運用しなければなりませんでした。クロスセルを通じて既存のビジネスと買収後のビジネスのメリットを実現するなど、さまざまな理由から最新の API 管理プラットフォームに移行する必要があったのです。TPG は複数の顧客管理（CRM）システムや課金システムを通じて、モバイル、固定ブロードバンド、ワイヤレスの利用者を支援しており、こうしたシステムは、さまざまな形式とプロトコルで API を提供しています。そのため、多様な API 配信プラットフォームのサポートと API 全体の可視性は TPG にとってなくてはならないものです。API ゲートウェイとして Apigee を使用することで、TPG は一貫した形式で API をデジタル消費者システムに公開しています。こうしたデジタルシステムのおかげで、複数の API プロトコルをサポートする複雑な仕組みの実装に煩わされることなくデジタル体験の充実に集中することができ、さまざまなバックエンドシステムへの統合も容易になります。

TPG では API ガバナンスが重要な要素になっています。これは、利用された API から得られるフィードバックに基づいて API がどのように利用され、それがどのようなパフォーマンスを示しているかを理解し、API の利用体験を継続的に向上させる必要があるためです。API 関連の指標を使用してアラームをトリガーすることで、ダウンストリームシステムの問題を事前に特定して解決することが可能になりました。

TPG は、より広範なビジネスの方向性に合わせて、主にオンプレミスの API 管理ソリューションで賄っていた要素を分散型のクラウドネイティブプラットフォームに置き換えたいと考えていました。また、シームレスかつ一貫した方法で API を配信できるように、アウトソーシングされた多様な開発モデルから、アジャイルで集中型の DevSecOps に移行することも模索していました。

さまざまな言語またはフレームワークで API を構築し、ユーザー向けの機能を一貫して公開できるソリューションを提供している別のクラウドプロバイダとの連携を求めていました。さまざまなバックエンドの統合をサポートするとともに、優先パートナーのランタイムを確保しながら、TPG のオンプレミスサービスとパートナーのクラウドサービスにおけるアカウント間のシームレスな統合を進めなければなりません。さらに、可視性を高めるために、すべての API を共通のガバナンスプラットフォーム下に置く必要がありました。

Apigee を選択した理由

複数の API 管理プラットフォームを評価したうえで、TPG は Apigee を選びました。Apigee は、直観的な設計と包括的な機能群によりマーケットリーダーの座を占めているという事実などの複数の理由から TPG に最適なサービスでした。Apigee のライセンスモデルを使用すれば、ライセンスにかかる費用をより適切に予測できるようにもなります。

また、API を公開して保護し、自動化された CI / CD パイプラインを有効にすることで、より迅速かつ効率的にデプロイするための労力が大幅に軽減されました。加えて、AI、Kubernetes、サービスメッシュなどのテクノロジーに対する Google Cloud の投資と習熟度、ビジネスに役立つ豊富なアプリケーションを備えたすべてのテクノロジーが TPG の選択を後押ししました。

さらに、Apigee は柔軟なデプロイオプションを提供しているため、TPG は Apigee ハイブリッドを選ぶことにより、マルチクラウド環境とオンプレミス環境を横断したランタイムの統合を実現しました。Apigee のおかげで、ビジネス全体のすべての API に対して共通のガバナンスプラットフォームを確立できています。

2022 年末に最初の API セットを使用して Apigee を稼働させた TPG Telecom は、現在 6 つのプラットフォームを最大 300 の基盤システムに接続すべく数年にわたる取り組みを進めています。TPG は、社内外の利用者に向けて自らが公開した API を使用するという経験を一貫して積んできました。さらに、Apigee プラットフォームに組み込まれたセキュリティ機能を通じて、使用される API に脆弱性がないことを保証するとともに、パフォーマンスや可用性の問題を検出できるよう、リアルタイムのモニタリングを実施しています。その結果、統合を大幅に加速できました。

Apigee の使用を一元的に進めるのではなく、社内での価値の実証に基づいて TPG 全体での採用を拡大しています。別の言い方をすれば、API を Apigee にオンボーディングする機会を各チームと連携して模索しているということです。

下の図は TPG における現在の Apigee アーキテクチャの全体像と API を外部サービスプロバイダと統合する方途を示しています。

現在のアーキテクチャ - Apigee

API の可視性と重複の課題を克服する

Apigee は、ビジネスに API を活用するなかで直面するさまざまな課題の克服に役立ちます。たとえば、TPG では API とその使用量の可視性が限られていたため、ポリシーの作成が困難となり、脆弱性の修正が遅れて API のテストとリリースが減速し、ひいては市場投入までのペースが大幅に鈍化していました。さらに、ビジネスユニット間の可視性が欠如していたために、API ベースのプロダクトやサービスの重複がさまざまなビジネスやブランドにわたって広範に認められました。API を公開する単一のプラットフォームがないため、外部の利用者が TPG のサービスを利用すると、API リクエストが複数の統合ポイントを通過することになり、応答時間が遅くなります。また、プロセスと実装ルールを標準化、明確化するための文書化アプローチを改善するとともに、ルール、パターン、統合スタイルに関連する API アーティファクトを保存するための統合リポジトリを提供する必要もありました。

Apigee と API Hub により、API を設計、公開するための一元的な場所を得ることができました。そこでは、文書化が尽くされており、明確な仕様を閲覧できます。また、複雑さを低減し、作成時間を短縮できるよう、今後は単一の API 形式に移行する予定です。

Apigee 以前、重複はセキュリティ制御にも広がっていました。API 利用者に抽象化レイヤを提供する統合型の API 管理体制および API ソリューションが欠けていたため、さまざまな侵入テストチームとセキュリティチームを関与させたうえで、バックエンドシステム、ネットワーク、顧客体験アプリケーションを個別にテストする必要があったのです。異なるプラットフォームに同じ制御を実装するのに必要な時間を短縮することが最優先事項でした。なぜなら、侵入テストサイクルが 2 つのスプリントで実行されるからです。一つはアプリケーションのセキュリティ対策の推奨に関わるもので、もう一つはそれらの対策が実装されていることを確認するものでした。

今では Apigee の Advanced API Security を単一の制御プレーンとして使用して、公開されている数百の API 全体のセキュリティを管理しています。Apigee の Advanced API Security ソリューションによって提供されるセキュリティ制御の推奨事項と修復により、重要なセキュリティ制御を一貫して適用するプロセスも合理化できました。

Apigee の実装以前、API 管理の状況は断片的で複雑なものでした。複数のソリューションがあるため、CI / CD、オブザーバビリティ、ガバナンスなどのプラットフォームエンジニアリング上のベストプラクティスに投資することは困難でした。New Relic、Splunk などのサービスを通じてオブザーバビリティを実装することは叶わず、問題を特定して適切な担当者に対応を通知するためのアクティブなモニタリングも実施していませんでした。自動化された CI / CD がなければ、こうしたプラットフォームに手動の手順が多く含まれるビルドとデプロイのプロセスが必要となり、コードのバージョニングの維持と管理が容易ではなく、ソリューションの本番環境へのデプロイが数週間遅れたことも多々あります。

また、Apigee のおかげでロギングとモニタリングを標準化できたことで、すべての API が共通のパターンに従うことになり、Apigee ログが Splunk に送信されてプラットフォーム全体でオブザーバビリティを確保できます。現在は、システムにタイムアウトや遅延などの問題が発生しているかどうかを特定するためのアラートやモニタリングシステムをいくつか構成しており、関連チームと迅速に連携してこうした問題を解決できるようになりました。

以前のプラットフォームでは、実行ロジックは API の開発とデプロイの間で密結合されていました。つまり、開発者は API サービスを外部の利用者に提供するまでに、かなりの量のビジネスロジックを理解する必要があったのです。開発者に最新の情報を提供しなければならず、オーバーヘッドが不必要に増加していました。今では Apigee を使用することで、疎結合アーキテクチャを実装し、デプロイ、標準、ランタイムの運用に重点を置く一元的 API チームを組織して、開発関連のオーバーヘッドを削減し、リリースサイクルを加速させています。

Apigee を使用することで、TPG は API の標準化、セキュリティ、一貫した統合プロセスを実装できました。新しいスマートフォンの発売などの特別なイベントやプロモーションを計画するとき、TPG はリクエストの量と予想される発売関連のトラフィックを捕捉し、その他のビジネス指標を記録して、EKS クラスタの自動スケーリング特性を決定しています。Apigee ハイブリッドを使用すれば、パフォーマンスや可用性に影響が生じることなく、非常にうまくスケーリングができます。

API を本番環境に 2 倍の速さでオンボーディング

現在、統合、オブザーバビリティ、関連する自動化を含め、わずか 2 週間で API を本番環境にオンボーディングしています。以前の API 管理プラットフォームでは、これに最大 4 週間かかっていました。Apigee の Advanced API Security を使用すれば、侵入テストを実行する前に各 API のセキュリティスコアを評価し、多くの問題を特定、修正できるため、基本的なセキュリティ制御で本番環境 API を保護できているという十分な確信が得られます。

TPG は現在、社内外の API 利用者向けに企業全体で Apigee の導入を推し進めるとともに、TPG Telecom 傘下のクロスセルやアップセルの機会を生み出す API の潜在可能性を具体的な形にしていく体制を整えています。

-TPG Telecom、インテグレーション、プラットフォーム エンジニアリング、自動化担当ドメイン マネージャー Nitin Nair 氏

-Google Cloud、Apigee 担当ソリューション エンジニアリング プリンシパル Ivan Niccolai

Apigee と GKE 間の接続を、Private Service Connect および GKE Gateway を使ってモダナイズする

Tue, 12 Mar 2024 01:00:00 +0000

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

昨今のクラウドネイティブ全盛の状況において、企業はアジャイルな API 管理と、Kubernetes 上で動作するマイクロサービスの柔軟性の両方を求めています。Google Cloud は、総合的な API 管理機能を備えた Apigee と、コンテナ化アプリケーションのオーケストレーションのための Google Kubernetes Engine（GKE）という、高度なソリューションを提供しています。しかし、これらの環境を互いに接続し、Kubernetes ベースのマイクロサービスに対する API トラフィックを効率化することは容易ではありません。こんなときに役立つのが Private Service Connect（PSC）で、VPC から Google、サードパーティ、独自サービスへの安全なプライベート接続を確立することができます。PSC なら、Apigee からバックエンドターゲットへのサウスバウンド通信において、安全で効率の良いスマートなソリューションを提供することが可能となります。

接続に伴う課題

Apigee と GKE を接続する従来の方法は、ネットワーキングの面でさまざまな複雑化を招きます。Apigee と GKE の接続の効率化を妨げる課題としては、一般的に以下のようなものがあります。

一般公開の状態になる: Apigee から GKE に API トラフィックをルーティングすると、GKE サービスを一般公開しなければならなくなることがよくあります。これにより、攻撃ベクトルが生じ、セキュリティリスクが生まれる可能性があります。
トラフィックのボトルネックおよび費用: 公共のインターネット接続のみに頼ると、想定外のレイテンシが生じてパフォーマンスが低下し、下り（外向き）料金が増加する可能性があります。
管理が複雑: ネットワークおよび VPC ピアリング接続の構成や、CIDR 範囲の重複の回避、Apigee や GKE などのプラットフォーム間のアクセス権管理など、複雑な管理作業が発生します。

Private Service Connect のアプローチ

PSC は、Apigee デプロイメントが GKE サービスと連係する方法を根本的に変え、セキュリティのレベルアップと大幅な単純化を実現します。具体的には、以下のような特徴があります。

非公開の内部ネットワーキング: PSC では、サービスアタッチメントおよびエンドポイントを使用して、VPC 間でサービスを直接公開します。複雑な VPC ピアリングの設定は不要で、公共インターネットにクラスタを晒さずに済みます。PSC では、Google Cloud VPC 内で GKE Gateway 用の非公開のエンドポイントを容易に確立できます。これにより、Apigee と Kubernetes サービスの間の通信が Google Cloud の内部ネットワーク経由で直接行われるようになります。そのため、公共インターネットを完全にバイパスでき、複雑な VPC ピアリングの実装が不要です。
きめ細かなセキュリティ管理: PSC では、Apigee からのアクセスを GKE クラスタ内の一部のサービスに制限できます。このきめ細かな管理方法によって、リスクを最小化できます。
パフォーマンスの向上: Google Cloud の高パフォーマンスネットワーク経由のプライベート接続により、レイテンシが短縮されるとともに信頼性が高まり、API レスポンス時間が全体的に改善します。

主な構成要素

Apigee: Google Cloud の堅牢な API 管理プラットフォーム。API の作成、管理、保護、モニタリングを簡素化するとともに、ポリシー適用、分析、収益化などの機能も提供します。
GKE Gateway: Kubernetes Gateway API（新しく柔軟な API 仕様）の GKE での実装。Ingress オブジェクトを改善した高度なネットワーキングリソースであり、GKE クラスタにおける内部および外部トラフィックのルーティングやロードバランシングの機能が拡張されています。
Private Service Connect: このインテグレーションの要である PSC によって、GKE クラスタをホストする VPC と Apigee VPC の間のプライベート接続を設定し、ルーティングを管理します。

安全な接続を設定

接続を確立するには、以下の手順に沿って操作します。ここでは、主に GKE Gateway の作成について詳しく説明します（その他の手順は非常に簡単で、詳しいドキュメントも提供されています）。

1. 内部の GKE Gateway をデプロイする:

これは細かな手順に分かれていますが、概要としては以下を行う必要があります。

VPC ネイティブクラスタを作成する。VPC ネイティブクラスタとは、Pod やサービスが Google Cloud VPC ネットワークの IP アドレスを直接使用するクラスタを指します。
Gateway API および HTTP ロードバランシングアドオンを有効にする。これは、クラスタの作成時または更新時に、必要に応じて行えます。
プロキシ専用サブネットを構成する。これは、GKE クラスタを実行するサブネットとは異なります。REGIONAL_MANAGED_PROXY の目的で作成するようにしてください。
名前付き IP アドレスを作成する。名前付き IP アドレスを使うことで、Gateway リソース用の静的 IP を予約することができます。Gateway の IP アドレスを指定しない場合は、Gateway コントローラが自動的に IP アドレスを割り当てます。注: このブログ記事の公開時点では、PSC サービスアタッチメントは共有 IP アドレス（SHARED_LOADBALANCER_VIP）を使用する転送ルールに対応していません。しかし、名前付き IP アドレスを予約しなかった場合や、目的を明示的に定義せずに名前付き IP アドレスを作成した場合、Gateway が使用する IP アドレスのデフォルトの目的は SHARED_LOADBALANCER_VIP になります。これを回避するために、以下に示す gcloud コマンドを使って GCE_ENDPOINT という目的の名前付き IP アドレスを作成しましょう。GCE_ENDPOINT という IP アドレスの使用にあたっては、以下の点に留意してください。

Apigee から Gateway への HTTP トラフィックと HTTPS トラフィックの両方に、同じ IP アドレスの Gateway を使用することはできません。また、Gateway へのトラフィックを HTTP から HTTPS へと同じアドレス上でリダイレクトすることはできません。
Apigee から Gateway への通信で HTTP のみまたは HTTPS のみを使用している場合は、上記の事項はさほど問題になりません。ただし、HTTP と HTTPS の両方を使用する場合は、2 つの異なる Gateway（HTTP 用と HTTPS 用）で処理する必要があるため、2 つの名前付き IP アドレスが必要となります。
ただし、これは元のクライアントから Apigee への初期トラフィックには当てはまりません。初期トラフィックを処理する外部の L7 ロードバランサは、SHARED_LOADBALANCER_VIP という目的を使用しており、HTTP トラフィックと HTTPS トラフィックの両方に対応し、HTTP から HTTPS へのリダイレクトも行えます。

この手順は、PSC サービスアタッチメントが SHARED_LOADBALANCER_VIP という目的の共有 IP アドレスを使用する転送ルールをサポートするようになった時点で、省略できるようになります。この手順を行う前に、この制限事項がまだ適用されているかどうかを確認してください。

code_block: <ListValue: [StructValue([('code', 'gcloud compute addresses create <IP_ADDRESS_NAME> \\\r\n \t\t --purpose=GCP_ENDPOINT \\\r\n \t\t --region=<COMPUTE_REGION> \\\r\n \t\t --subnet=<SUBNET> \\\r\n \t\t --project=<PROJECT_ID>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4ab8564700>)])]>

Gateway リソースを作成する: 名前付き IP アドレスを使って Gateway を作成する yaml ファイルの例を以下に示します。

code_block: <ListValue: [StructValue([('code', 'kind: Gateway\r\napiVersion: gateway.networking.k8s.io/v1beta1\r\nmetadata:\r\n name: sample-gateway\r\nspec:\r\n gatewayClassName: gke-l7-rilb\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n addresses:\r\n - type: NamedAddress\r\n value: <IP_ADDRESS_NAME>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4ab85649a0>)])]>

PSC サービス アタッチメントを設定する: GKE Gateway をデプロイする VPC ネットワークで、PSC サービスアタッチメントを作成します。GKE Gateway に対して作成した転送ルールを使って、サービスアタッチメントを構成するようにしてください。
エンドポイント アタッチメントを作成する: これは Apigee 組織内で構成されます。
GKE サービスへの Gateway ルートを構成する: これを行うことで、コンテナ化アプリケーションおよびルートのデプロイを、Gateway のデプロイ手順から切り離すことが可能となります。

まとめ

Private Service Connect は、Apigee による GKE ワークロードとの連係を改善し、セキュリティ、パフォーマンス、運用効率を向上させることができます。公共インターネットや複雑な VPC ピアリングの管理を回避し、Google Cloud 内部の安全なインフラストラクチャを活用することで、リスクを減らすとともに、クラウドネイティブの API サービス用の効率的で堅牢なバックボーンを実現できます。

ーカスタマー エンジニア NJ Njoku

ーネットワーキング スペシャリスト Lorin Price

開発者による効果的な API の作成をプラットフォームエンジニアが支援するための 5 つの戦略

Wed, 31 Jan 2024 03:00:00 +0000

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

最新のアプリケーションでは、複雑な機能を処理して超高速のパフォーマンスを実現し、記録的な速さで具現化する API を構築することが開発者に求められています。プラットフォームエンジニアは、そのような開発者に適切なツールや手法を提供して API 開発の負担を軽減する縁の下の力持ちです。

では、プラットフォームエンジニアが API 開発に影響を与えるには、どうすればよいでしょうか？それには、大きく分けて 5 つの戦略が存在します。以下の戦略を実践することで、プラットフォームエンジニアは開発者がより優れた API を作成する手助けができます。

API と内部プラットフォームを製品として扱う
API 管理を内部プラットフォームに組み込む
プロキシとポリシーのための CI / CD パイプラインを構築する
開発者が利用するためのゴールデンパスを作成する
API の管理と自動化のために Apigee を活用する

各戦略を詳しく見ていきましょう。

1. API と内部プラットフォームを製品として扱う

優れたデジタルコネクテッドエクスペリエンスは、API、つまりアプリケーション同士の対話を可能にするデジタルメカニズムによってもたらされます。簡単に言えば、API はサービス統合を可能にするソフトウェア製品にすぎません。消費者向けに出荷される他のソフトウェア製品と同様に API も、ソフトウェア開発ライフサイクル（SDLC）のような体系的プロセスを使用して、テスト、保護、デプロイ、管理が行われるべきです。内部プラットフォームは、このようなデジタル製品の提供を可能にします。それは、共通のツールセットと、組織の考えや提供価値を体現した「独善的」なテンプレートを開発者が使用できるようにすることで実現されます。たとえば、組織の要件で、API にアクセスしようとするすべてのアプリケーションに OAuth トークンの提示が義務付けられているとします。この場合、プラットフォームエンジニアは、フローコールアウトを使用して OAuth v2 ポリシーをプロキシにアタッチするために使用される共有フローパイプラインを利用可能にするゴールデンパスを作成するでしょう。

API がそうであるように、内部プラットフォームも製品です。社内のサイロを取り払い、組織でチーム横断的に連携して要件を理解することは、プラットフォームエンジニアリングチームの主要な役割です。この連携により、開発者にとってより良いツールがもたらされます。

2. API 管理を内部プラットフォームに組み込む

プラットフォームエンジニアの中核となる責務は、開発者が使用する内部プラットフォームを作成することです。この内部プラットフォームは、独善的なテンプレートやツールに開発者がアクセスできるようにすることで、開発者に自律性をもたらします。これらのテンプレートやツールを作成すれば、API 管理のさまざまな側面をプラットフォームで処理できるようになります。API 管理を内部プラットフォームに組み込むことで、標準化、セキュリティ、割り当て、モニタリング、自動デプロイなどをプラットフォームに搭載することができます。

3. プロキシとポリシーのための CI / CD パイプラインを構築する

API はデジタル製品であるため、コードを通じて作成、管理されなくてはなりません。プラットフォームエンジニアの一般的なタスクは、API のソフトウェア開発ライフサイクルを自動化するために CI / CDパイプラインを作成することです。標準的な CI / CD パイプラインは、静的コード解析、単体テスト、デプロイ、統合テストで構成されます。

大まかに言うと、開発者はローカルでプロキシを開発し、Git を使ってプロキシコードをソースコードリポジトリに commit します。commit により、テストを実施してフィードバックを提供する自動化されたパイプラインが開始されます。成功すると、コードは本番環境にリリースされるまで、さまざまな環境にプロモートされます。構築した API は組織内の他の人が見つけられるようにしておく必要があります。内部 API の置き場所として便利なのが API Hub です。外部 API の検出と顧客向けのドキュメントには、デベロッパーポータルを利用できます。

4. 開発者が利用するためのゴールデンパスを作成する

ゴールデンパスは、開発者のベロシティを向上させるコードとツールを統合したテンプレートで構成されます。その名が示すように、ゴールデンパスは開発者がソフトウェアを構築する際に最も抵抗の少ないパスを見つけるのを助けるもので、多くの場合にセルフサービスのテンプレートとワークフローを活用します。これらのテンプレートは、共通のタスクと独善的な戦略で構成されます。Apigee で API を開発する場合、標準的なゴールデンパスには以下が含まれます。

スタートガイド
プロキシ / ポリシー作成 / モックバックエンド用のスキャフォールディングテンプレート
自動的に挿入される標準的な共有フロー構成
テストとデプロイのための CI / CD パイプライン
API レジストリテンプレート

5. API の管理と自動化のために Apigee を活用する

今回の主役である Apigee について説明します。Apigee は、API を構築、管理、保護するツールをプラットフォームチームに提供する API 管理プラットフォームで、ライフサイクル全体を通して API を管理するために使用できます。Apigee の API は、顧客とビジネスロジック（バックエンド）の間に位置するデジタルインターフェースであるプロキシから始まります。プロキシは API ポリシーのアタッチメントポイントとしても機能し、組織が API の動作をプログラムできるようにします。さらに、プロキシは API をバックエンドへの直接アクセスから切り離し、複雑さを隠すことも可能にします。プラットフォームエンジニアは、開発者をプロキシの作成に集中させることで、より優れた API を作成できるようサポートします。プラットフォームは、API がどのように機能するかに関して独善的でなければなりません。Shared Flows などの Apigee ツールを使用すると、標準化と整合性を確保することができます。また、FlowCallout ポリシーとフローフックを使用すれば、これらのポリシーをプロキシにアタッチし、API 間で再利用できます。

より良い API を構築する

プラットフォームエンジニアは、API と内部プラットフォームを製品として扱い、API 管理をプラットフォームに組み込み、API の管理と自動化のために Apigee を活用し、プロキシとポリシーのために CI / CD パイプラインを構築し、開発者が利用するためのゴールデンパスを作成することで、開発者が Apigee を使ってより優れた API を構築することを手助けできます。開発者を支援する方法について、さらに詳しいガイダンスをご希望の場合は、こちらの詳細なホワイトペーパーをご確認ください。まだ Apigee をお使いでない場合は、詳細をご覧になるか、こちらから利用を開始していただけます。

-カスタマー エンジニア David Rush

-デベロッパー リレーションズ エンジニア Emanuel Burgess

API 管理

API のスプロールをエージェント対応のカタログに変換

AI 戦略にとって重要な理由

スプロールは AI 導入の足かせになる

ステップ 1: API メタデータを一元化する

ステップ 2: API 仕様強化アドオンで API をエージェント対応にする

使ってみる

Apigee での MCP サポート開始のお知らせ: 既存の API を安全で管理されたエージェント ツールへ変換

Apigee の MCP サポートの概要

MCP サポートに対する Apigee のアプローチのメリット

エージェント フレームワークで Apigee MCP ツールを使用する

次のステップ

Vertex AI Agent Builder の高度なガバナンス機能の発表

1. ツールを自信を持って管理

2. AI エージェントを迅速に構築

3. AI エージェントを効果的にスケーリング

Agent Builder で成果を挙げているお客様

利用方法

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

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

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

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

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

OWASP トップ 10 セキュリティ脅威から API を保護する

OWASP トップ 10 API セキュリティ リスクへの対応

Apigee と Advanced API Security によるセキュリティ リスクの軽減

Apigee で API の保護を始める

Apigee で生成 AI アプリを運用化する

生成 AI の可能性を最大限に引き出すには

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

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

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

まとめと次のステップ

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

イタリア行政府にとっての Apigee と相互運用モデル（Modl）

Modl プラットフォームを実現する Apigee

Apigee 内で Modl のガイドラインとパターンを適用する方法

ModI のためのアクセンチュア アクセラレータ

まとめ

Cloud Code プラグインによる API 管理で迅速な API 開発を実現

組織のワークスペース

モックサーバーによる速度の向上

使ってみる

Altice Labs が Google の Application Integration を使用して API 管理を強化した方法

インテグレーション戦略の詳細

Altice Group に与えた効果

-Altice Labs、デジタルおよびイノベーション戦略 Bruno Cabral 氏

CSP が目指すネットワーク API デジタル マーケットプレイス シンジケーションを通じた、より広範囲へのリーチとよりスマートな収益化

デジタル API マーケットプレイス

まとめ

Apigee のカスタム レポートで API のパフォーマンス分析情報を獲得する

Apigee カスタム レポートについて

主なカスタム レポート

1. レイテンシ分析

2. レスポンス コード分析

3. API プロダクト パフォーマンス分析

4. キャッシュ ヒット分析

5. ユーザー エージェント分析

6. API ロケーション分析

カスタム レポートにアクセスする

復習用: レポート作成の操作手順

カスタム レポートを使用して API パフォーマンスを追跡する

Apigee で DialogFlow CX の chatbot のセキュリティを強化する

次のステップ

commercetools と Google Cloud Application Integration で e コマース エクスペリエンスを構築する

commercetools プラットフォームを Google Cloud と接続する

Google Cloud 環境向けのシャドー API 検出のご紹介

Apigee API Management で API を保護する

Advanced API Security でシャドー API を検出する

シャドー API 検出機能の利用を開始する

Gemini Code Assist を使用して、API、インテグレーション、自動化フローを構築する

Gemini Code Assist: 各企業に合わせてカスタマイズされた AI アシスタント

API の構築に Gemini Code Assist を使用する

Gemini Code Assist を使用してインテグレーションと自動化を構築する

使ってみる

-Google Cloud、プロダクト マネージャー Michael Vakoc-Google Cloud、プロダクト マネージャー Pramodh Ramesh

Gemini で Google Cloud を強化

Gemini Code Assist でソフトウェア デリバリーを加速

Gemini Cloud Assist でアプリケーションのライフサイクルを効率的に管理

Gemini in Security でセキュリティの専門性を向上

Apigee での MCP サポート開始のお知らせ: 既存の API を安全で管理されたエージェントツールへ変換

エージェントフレームワークで Apigee MCP ツールを使用する

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

OWASP トップ 10 API セキュリティリスクへの対応

Apigee と Advanced API Security によるセキュリティリスクの軽減

ModI のためのアクセンチュアアクセラレータ

CSP が目指すネットワーク API デジタルマーケットプレイスシンジケーションを通じた、より広範囲へのリーチとよりスマートな収益化

Apigee のカスタムレポートで API のパフォーマンス分析情報を獲得する

Apigee カスタムレポートについて

主なカスタムレポート

2. レスポンスコード分析

3. API プロダクトパフォーマンス分析

4. キャッシュヒット分析

5. ユーザーエージェント分析

カスタムレポートにアクセスする

カスタムレポートを使用して API パフォーマンスを追跡する

commercetools と Google Cloud Application Integration で e コマースエクスペリエンスを構築する

-Google Cloud、プロダクトマネージャー Michael Vakoc
-Google Cloud、プロダクトマネージャー Pramodh Ramesh

Gemini Code Assist でソフトウェアデリバリーを加速

開発者による効果的な API の作成をプラットフォームエンジニアが支援するための 5 つの戦略