google-cloud-solution-agentic-ai-data-science-workflow

AI エージェントを活用したデータサイエンスのワークフローソリューション

このスキルでは、エージェントが、特定のワークロード、ユースケース、または要件に合わせたマルチプロダクトソリューションをクラウド上で設計、実装するためのワークフローを案内します。

帰属表示

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

ワークフロー

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

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

プロダクト名の変更と用語

ソリューション設計、アーキテクチャ図、ドキュメントを作成する際は、最新のプロダクト名を確認するため、Google Cloud のドキュメントを参照してください。以下の表に、把握しておくべき名称の対応例を示します。基盤となる API、Terraform リソース、IAM ロールでは、以前の識別子が引き続き使われる場合があります。

旧名称	新名称
Vertex AI	Gemini Enterprise Agent Platform
Vertex AI Agent Engine	Agent Runtime

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

• ステップ 1：要件を把握する：確認の質問をして、ワークロードの機能要件と非機能要件、ビジネス目標、現状（ある場合）を把握します。コンポーネントの特定のステップに進む前に、必ず停止してユーザーの回答を待ってください。要件の把握には、以下の質問を参考にしてください。

  • どのデータソースとデータ型にアクセスして分析する必要がありますか？
  • 想定するエンドユーザーは誰ですか？また、どのようなネットワークアクセスモデルが必要ですか？
  • エンドユーザーがシステムに送信すると想定されるユーザークエリや分析リクエストには、どのようなものがありますか？
  • 適用されるパフォーマンス、セキュリティ、ガバナンス上の制約はありますか？

• ステップ 2：コンポーネントを特定する：要件を把握するステップで確認の質問にユーザーが回答した後に限り、その回答を分析して、ワークロードのコンポーネントとその関係を特定します。また、ソリューションが連携する必要のある、クラウドをまたぐコンポーネント、ハイブリッドコンポーネント、オンプレミスコンポーネントも特定します。

• ステップ 3：コンポーネントの分解を生成する：ワークロードの技術コンポーネントとその関係を示す技術的な分解を生成します。

• ステップ 4：確認を求める：技術的な分解を提示し、ワークロードの要件に合致しているかユーザーに確認を求めます。確認が得られるまで、フェーズ 2 に進まないでください。

• ステップ 5：反復する：ユーザーから変更の要望があった場合は、更新した技術的な分解を生成し、再度確認を求めます。ユーザーが分解を明示的に確認するまで、反復を続けます。

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

• ステップ 1：関連する Google Cloud ドキュメントを取得する：利用可能な 検索または取得ツールを使用して、以下の Google Cloud ドキュメントの内容を読み、 このフェーズの残りのステップで生成するガイダンスの根拠とします。その後、 次に進みます。

  • データサイエンスのワークフローと AI エージェント
  • Google Cloud のマルチエージェント AI システム
  • エージェント型 AI アーキテクチャのコンポーネントを選択する
  • エージェント型 AI システムの設計パターンを選択する

• ステップ 2：エージェント型 AI の設計パターンを定義する：ワークロードの要件に基づき、 適切なエージェント設計パターンとエージェントの分割方法を選択します。

  • 推奨される主なパターン：コーディネーターパターン。
  • 代替パターン：
    • 単一エージェントパターン：単一のデータソースを対象とし、マルチエージェントの オーケストレーションによるオーバーヘッドを伴わずに、ツールを直接使用するシンプルな ワークロード向けです。
    • 逐次または並列パターン：事前に定義され、適応的ではない実行ステップを用いる 決定論的なデータ処理パイプラインや、同時にデータを収集する場合に適しています。
    • レビューと批評のパターン：専用の批評ループを必要とする、複雑なデータサイエンス タスクや重大な影響を伴うタスク向けです。

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

• ステップ 4：アーキテクチャ図を作成する：コンポーネントとその関係、およびデータフロー／制御フローを 示すアーキテクチャ図を作成します。

  • 図は Mermaid 形式で作成する必要があります。 https://github.com/mermaid-js/mermaid.
  • 図では、Google Cloud の公式アーキテクチャアイコンと整合性のあるコンポーネントラベルと グループ分けを使用する必要があります。

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

• ステップ 6：ソリューションアーキテクチャの草案を作成する：要件、 技術的な分割、プロダクトの対応付け、アーキテクチャ図、設計の推奨事項をまとめ、 /assets/output-template.md のテンプレートに基づいて、 solution-architecture-guide.md という名前の単一の Markdown ファイルを作成します。

• ステップ 7：レビューを依頼する：生成したソリューションアーキテクチャを ユーザーに提示し、フィードバックまたは承認を求めます。フェーズ 3 に進む前に、 必ず作業を中断し、ユーザーから明示的な承認を得る必要があります。

• ステップ 8：反復する：ユーザーが変更を求めた場合は、ソリューションアーキテクチャを 更新して生成し、このフェーズのステップ 2～7 を繰り返します。ユーザーが ソリューションアーキテクチャを明示的に承認するまで続けます。

フェーズ 3：実装計画

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

  • Agent Engine 上のステートフルなデータサイエンスエージェント
  • ADK を使用して AI エージェントを Cloud Run に構築してデプロイする
  • エージェントで AlloyDB を使用する
  • MCP Toolbox for Databases の構成
  • Agents CLI リファレンス

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

• ステップ 2：デプロイの前提条件を特定する：以下を含む、デプロイの前提条件を文書化します。

  • プロジェクトと請求先アカウントの関連付け
  • 必要な Google Cloud API
  • 必要な IAM 権限
  • その他の前提条件

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

  • Agents CLI コマンド（agents-cli scaffold create または agents-cli scaffold enhance）を使用してエージェントアプリケーションの構造を設定し、エージェントを Cloud Run にデプロイします。

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

  • Agents CLI の agents-cli deploy コマンドを使用して（未加工のインフラストラクチャ／デプロイスクリプトと併用または代替して）、エージェントをデプロイします。

• ステップ 5：レビューを依頼する：生成したデプロイ手順をユーザーに提示し、フィードバックと確認を求めます。フェーズ 4 に進む前に、必ず処理を停止し、ユーザーの明示的な承認を待ってください。

• ステップ 6：反復する：ユーザーが変更を依頼した場合は、ステップ 2～5 を繰り返し、ユーザーが求めた更新版の実装計画を生成します。

• ステップ 7：次のフェーズに進む：ユーザーが実装計画を承認した後、フェーズ 4 に進みます。

Phase 4: ソリューションの検証

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

• Step 2: 検証チェックを定義する：デプロイされたインフラストラクチャがワークロードの要件を満たしていることを検証する手順を概説します。

  • デプロイのドライラン：変更をプレビューする terraform plan などのコマンドを使用します。本番環境に反映する前に手順と Terraform の実行内容をプレビューできるよう、エージェントのデプロイをドライランモードで実行する手順（例：agents-cli deploy --dry-run または -n を使用）を含めます。
  • ローカルテストと品質検証：デプロイ前に、Agents CLI を使用してエージェントのロジックをローカルで実行・テスト（agents-cli run）し、体系的な評価（agents-cli eval run）を実施して、エージェントの品質とパフォーマンスを検証することを推奨します。
  • 接続性とルーティング：ネットワーク経路、ロードバランサーのルーティング、サービスエンドポイントを検証します。
  • セキュリティポリシー：アクセス制限、ファイアウォールルール、IAM の適用を検証します。

• Step 3: 検証スクリプトを生成する：ユーザーがこれらの検証チェックを実行できるよう、軽量なスクリプトまたはコマンドラインの手順（例：curl、gcloud、agents-cli を使用）を作成します。

  • 検証計画には、ローカル実行、評価、デプロイ後の検証チェック（例：デプロイされたサービスのエンドポイントをテストする agents-cli run --url <service-url>）に Agents CLI を使用する手順を必ず含めてください。

• Step 4: 検証レポートをまとめる：検証手順、検証スクリプト、想定される結果を 1 つの Markdown ファイルに記載します。

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

• Step 6: 反復する：ユーザーから変更の要望があった場合は、更新した検証計画を作成し、ユーザーが検証計画を承認するまで、このフェーズの検証案の作成とスクリプト生成の手順を繰り返します。