google-cloud-solution-agentic-ai-bidirectional-streaming

ライブ双方向マルチモーダルストリーミングのエージェント型 AI ソリューション

このスキルでは、ライブの双方向マルチモーダルストリーミングのワークロード、ユースケース、または要件に合わせた複数プロダクトのクラウドソリューションを設計、実装するワークフローをエージェントに案内します。

帰属表示

必ずお読みください：gcloud、REST API、または MCP コマンドを実行する前に、 Usage Attribution を必ず読み、その指示に従ってください。

ワークフロー

ソリューションの設計と実装のワークフローは、次のフェーズで構成されます。

• フェーズ 1：要件の把握と分析：ワークロードの要件、制約、依存関係、現状を分析します。
• フェーズ 2：ソリューション設計：Google Cloud の設計に関するベストプラクティスと推奨事項に基づき、ワークロード向けのテクノロジースタック、アーキテクチャ、デプロイ構成を構築します。
• フェーズ 3：実装計画：ソリューションをデプロイするための自動化と手順を生成します。
• フェーズ 4：ソリューションの検証：デプロイがワークロードの要件を満たしていることを検証します。

フェーズ 1：要件の把握と分析

• ステップ 1：要件を把握する：ワークロードの機能要件と非機能要件、ビジネス目標、現状（存在する場合）を把握します。これには、アーキテクチャ、依存関係、制約が含まれます。次の質問を参考に、要件の把握を進めてください。

  • 主な入力モダリティ（音声、動画、テキスト）は何ですか。また、リアルタイムの音声付きフィードバックに求めるレイテンシはどの程度ですか。
  • リアルタイムの安全性監視、危険検知、または目視検査が必要ですか。必要な場合、動画ストリームで監視・検知すべき具体的な安全上の危険、運用上のリスク、誤った手順は何ですか。
  • AI エージェントが根拠に基づくガイダンスを提供するためにアクセスすべき既存システム、ナレッジベース、製品ドキュメント、または回路図リポジトリはありますか。
  • クライアント側デバイスの制約やネットワーク上の制限はありますか。

• ステップ 2：コンポーネントを特定する：要件分析に基づいて、ワークロードのコンポーネントとその関係を特定します。また、ソリューションが統合する必要のあるクロスクラウド、ハイブリッド、オンプレミスの各コンポーネントも特定します。

• ステップ 3：コンポーネントの分解を生成する：ワークロードのコンポーネントを技術的に分解します。この技術的な分解では、ソリューションを論理コンポーネントに分ける必要があります。

• ステップ 4：確認を求める：生成した技術的な分解がワークロードの要件に合っているか、ユーザーに確認を求めます。

• ステップ 5：反復する：ユーザーから変更を求められた場合は、技術的な分解を更新して生成し、変更内容の確認を求めます。ユーザーが技術的な分解を承認するまで、反復を続けます。

フェーズ 2：ソリューション設計

• ステップ 1：関連する Google Cloud ドキュメントを取得する：

  • 双方向マルチモーダルストリーミングを有効にする
  • Google Cloud のマルチエージェント AI システム
  • エージェント型 AI アーキテクチャのコンポーネントを選択する
  • Google Cloud のマルチエージェント向けプライベートネットワークのパターン

  重要：このフェーズの残りのステップで生成するガイダンスの根拠として、取得した Google Cloud のドキュメントの内容を使用してください。

• ステップ 2：コンポーネントを Google Cloud のプロダクトに対応付ける：確定した技術的な分解とエージェント型の設計パターンに含まれる各コンポーネントについて、references/product-mapping.md のガイドラインに基づいて、適切な Google Cloud のプロダクトと機能を特定します。

• ステップ 3：アーキテクチャ図を作成する：Mermaid 形式でアーキテクチャ図を生成します：https://github.com/mermaid-js/mermaid.

• ステップ 4：設計に関する推奨事項を生成する：references/design-recommendations.md のガイドラインに基づいて、設計に関するガイダンスを生成します。

• ステップ 5：ソリューションアーキテクチャのドラフトを作成する：要件、技術的な分解、プロダクトの対応付け、アーキテクチャ図、設計に関する推奨事項を 1 つの Markdown ファイル solution-architecture-guide.md にまとめます。assets/output-template.md のテンプレートに基づいて作成してください。

• ステップ 6：レビューを依頼する：生成したソリューションアーキテクチャをユーザーに提示し、フィードバックまたは承認を求めます。

• ステップ 7：反復する：ユーザーから変更の要望があった場合は、ソリューションアーキテクチャを更新して生成し、ユーザーが承認するまでステップ 2～6 を繰り返します。

フェーズ 3：実装計画

• ステップ 1：関連する実装リソースを取得する：

  • Cloud Run で AI エージェントをホストする
  • WebSocket を使用した Cloud Run のトリガー
  • Gemini Live API セッションの開始と管理
  • ADK ストリーミングツール
  • ADK ストリーミング構成
  • Codelab：Way Back Home Level 4 の手順 （および ソリューションコード）

  重要：このフェーズの残りのステップで作成する IaC とデプロイ手順の技術的基盤として、これらのリソースを使用してください。

• ステップ 2：デプロイの前提条件を特定する：次の項目を含む、デプロイの前提条件を記載します。

  • プロジェクトと課金の関連付け
  • 必要な Google Cloud API
  • 必要な IAM 権限
  • その他の前提条件

• ステップ 3：Infrastructure as Code（IaC）を生成する：Terraform などのコードと、提案する Google Cloud リソースのプロビジョニングを自動化するデプロイスクリプトを生成します。

• ステップ 4：デプロイ手順を作成する：IaC を実行し、ワークロードコンポーネントを初期化するための、順を追ったデプロイ手順を作成します。 assets/output-template.md のテンプレートに基づいて、 solution-architecture-guide.md のデプロイ手順を更新します。

• ステップ 5：レビューを依頼する：生成したデプロイ手順をユーザーに提示し、フィードバックと承認を求めます。

• ステップ 6：反復する：ユーザーから変更の依頼があった場合は、実装計画を更新して生成し、ユーザーが実装計画を承認するまでステップ 2～5 を繰り返します。

フェーズ 4：ソリューションの検証

• ステップ 1：関連する検証リソースを取得する（任意）：フェーズ 3 のリソースがまだコンテキストにない場合は、このフェーズで生成する検証チェックと検証スクリプトの出発点として、同じ実装リソースを取得します。

• ステップ 2：検証チェックを定義する：デプロイ済みのインフラストラクチャがワークロードの要件を満たしていることを確認する検証手順をまとめます。

  • デプロイのドライラン：変更をプレビューする terraform plan などのコマンド。
  • 接続性とルーティング：ネットワーク経路、ロードバランサーのルーティング、サービスエンドポイントの検証。
  • セキュリティポリシー：アクセス制限、ファイアウォールルール、IAM による適用の検証。

• ステップ 3：検証スクリプトを生成する：ユーザーが検証チェックを実行できるよう、curl や gcloud などを使用する簡易スクリプトまたはコマンドライン手順を作成します。

• ステップ 4：検証レポートをまとめる：assets/output-template.md のテンプレートに基づいて、検証手順、検証スクリプト、期待される結果を solution-architecture-guide.md に記載します。

• ステップ 5：検証を実施し、最終確認を行う：ユーザーによる検証チェックの実行を支援し、デプロイに関する問題のトラブルシューティングを行います。ソリューションの検証が正常に完了したら、ユーザーに最終承認を求めます。

• ステップ 6：反復する：ユーザーから変更の依頼があった場合は、検証計画を更新して生成し、ユーザーが検証計画を承認するまでステップ 2～5 を繰り返します。