google-cloud-solution-agentic-analytics-spark-knowledge-catalog

クラウドプロバイダーやデータ型をまたいだエージェント型分析

このスキルでは、Google Cloud、オンプレミスシステム、その他のクラウドプロバイダーに分散する構造化データと非構造化データを対象に、エージェント型分析ソリューションのための、ガバナンスが確保された安全なパイプラインを設計し、実装するワークフローを提供します。

クレジット表記

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

ワークフローの概要

ワークフローは次のフェーズで構成されます。

• フェーズ 1：要件の把握。ユーザーが支援を必要としているクラウドワークロードまたはユースケースに関する詳細な要件を収集します。
• フェーズ 2：ソリューションアーキテクチャ。フェーズ 1 で収集した要件を基に、クラウドワークロードまたはユースケースの詳細なソリューションアーキテクチャを作成します。
• フェーズ 3：ソリューションの検証。作成したソリューションを検証する計画を立て、検証手順とスクリプトを作成し、検証を実行します。
• フェーズ 4：ソリューションの整理と提示。作成した内容をまとめ、ソリューションを提示します。

ワークフローに関する重要な注意事項：

• フェーズの厳格な分離：フェーズ 1（要件の把握）でユーザーに確認の質問をする際は、アーキテクチャ設計、技術的な分解、クラウドサービス、コンポーネントの対応付けを推奨、提案、概要説明してはいけません。
• 一部のフェーズを省略できる場合：ユーザーのプロンプトで、このワークフロー内の特定のフェーズまたはタスクがすでに完了または承認済みであることが示されている場合（例：「要件把握の段階は完了しています」「製品の選定は承認済みです」「アーキテクチャは確定しています」）、そのフェーズまたはタスクを繰り返してはいけません。代わりに、技術的な分解の作成、製品の推奨、ソリューションガイドの作成など、依頼されたタスクに直接進んでください。

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

1. ユーザーに、ワークロードの機能要件（ビジネスプロセス、アクティビティ、ユースケース）を説明してもらいます。次の質問を一度に1つずつ尋ねます。

   • 主な在庫データソースは何ですか？PDF 形式のフレーバーレシピや請求書などの非構造化データですか、それとも Iceberg 内の過去の売上データなどの構造化データですか？
   • これらのデータソースはどこでホストされていますか？AWS S3、Azure Blob、Google Cloud Storage、または AlloyDB などのデータベースに分散していますか？
   • Google Cloud 内および他のクラウドプロバイダーなどの外部ロケーションにあるデータソース間で、メタデータをどのように管理し、連携していますか？
   • 大規模な分散データを結合、クレンジングし、予測モデルを実行するために、どのような分析要件と計算要件がありますか？
   • データサイエンティストや運用エージェントは、エージェント型 IDE（VS Code または Antigravity IDE）で、どのような自然言語のプロンプトを実行する想定ですか？

2. ユーザーに、ワークロードの非機能要件を説明してもらいます。 以下は、非機能要件を収集するために尋ねることができる質問の例です。

   • セキュリティ、プライバシー、コンプライアンス: システムが従う必要があるデータプライバシー規則、規制コンプライアンス（例: GDPR、HIPAA）、またはデータガバナンス要件は何ですか？
   • 信頼性: 稼働時間、高可用性、フォールトトレランス、および災害復旧の目標（RTO/RPO）は何ですか？
   • パフォーマンス: ワークロードで必要とされる目標クエリレイテンシと SLA の期待値は何ですか？
   • 運用: データサイエンティストとエンジニアが必要とする運用監視メトリクスは何ですか？
   • コストと持続可能性: 特定の予算制約やデータのエグレス/転送コスト要件はありますか？

3. ワークロードが現在、他のクラウドプロバイダーまたはオンプレミスで実行されているかどうかをユーザーに尋ねます。

   • ユーザーが「はい」と回答した場合は、現在のデプロイメントのアーキテクチャを説明するようユーザーに依頼します。
   • ユーザーが「いいえ」と回答した場合は、次のステップに進みます。

4. 他のワークロード、製品、またはツールへの依存関係がある場合は、それを説明するようユーザーに依頼します。以下は、依存関係に関する情報を得るために尋ねることができる質問の例です。

   • 外部システム（例: ID プロバイダー、データキュレーションプラットフォーム、CI/CD パイプライン、またはアクティブなデータカタログ）に対する上流または下流の依存関係はありますか？
   • 一般的なデータエンジニアリングソフトウェアのデリバリーライフサイクル（例: バージョン管理、テスト、データ品質保証）に関する要件はありますか？これらの成果物のディレクトリパスまたは例を提供してください。

5. これまでにユーザーが提供した入力を確認し、曖昧さや矛盾がないかチェックします。

   ユーザーが提供した要件に曖昧さや矛盾（例: ゼロコピーとリポジトリへのデータコピー）を特定した場合は、特定した各曖昧さまたは矛盾について次のことを行います。

   • 曖昧さまたは矛盾を説明します（例: データをコピーすることがゼロコピー要件に矛盾し、さらにデータ転送コストも発生する理由を説明します）。
   • 曖昧さまたは矛盾をどのように解決したいかをユーザーに尋ねます。
     • ユーザーが選択をあなたに委ねた場合（例: ユーザーが「最善と思うようにやってください」または「あなたが決めてください」と返信した場合）、曖昧さまたは矛盾を解決するための明確な提案を提供し（例: ゼロコピーのリモートクエリを優先することを提案する）、その理由を説明し（例: マルチクラウド料金とデータ重複を排除するため）、ユーザーに提案の承認を求めます。

   重要: 特定したすべての曖昧さと矛盾が前述のガイダンスに従って解決されるまで、アーキテクチャ設計、技術的分解、または Google Cloud 製品の推奨を提案または生成してはなりません。

6. 重要: ステップ 5 で未解決の矛盾または曖昧さがある場合は、このステップを開始しないでください。 ワークロードのコンポーネントの技術的分解を生成します。

   • 技術的分解では、ソリューションを論理的なコンポーネントに分解する 必要があります。
   • 分解では、関連するレイヤー内におけるロールベースのセキュリティと 認証情報を扱う MUST があります。
   • 分解は、エージェント型分析ソリューションの標準的なアーキテクチャ パターンを表す次の 4 つのレイヤーの下に編成する必要があります。 これらのレイヤーは、ユーザー操作からデータコンテキストとガバナンス を経てコアデータ処理へと流れます。
     • ユーザー操作レイヤー（IDE）: 例: エージェント型開発環境。
     • グラウンディングと信頼されたデータ: 例: 基盤モデル、MCP サーバー、クラウド内のデータウェアハウス。
     • メタデータキュレーション: 例: メタデータスキャン。
     • データ処理と分析: 例: 分析ワークフロー、Spark データ処理、 外部データストア。

7. 生成された技術的分解の承認をユーザーに求めます。

8. ユーザーが変更を要求した場合は、更新された技術的分解を生成します。

9. ユーザーが生成された技術的分解を承認するまで、ステップ 5 から 8 を 繰り返します。

10. ユーザーが技術的分解を承認した後、フェーズ 2 に進みます。 重要: ユーザーが生成されたワークロードの技術的分解を承認するまで、 次のフェーズに進まないでください。

フェーズ 2: ソリューションアーキテクチャ

生成されたすべてのコンテンツをグラウンディングする

このフェーズの各タスクについて、生成されたコンテンツが最新かつ公式の Google Cloud のガイダンスに沿うようにするため、次のリソースを使用して 生成されたコンテンツをグラウンディングします。

• Google Developer Knowledge MCP サーバー
  • MCP サーバーに接続するための手順: https://developers.google.com/knowledge/mcp.md.txt
  • サーバー: https://developerknowledge.googleapis.com/mcp
    • ツール:
      • developerknowledge:search_documents
      • developerknowledge:get_documents
      • developerknowledge:answer_query
• https://github.com/google/skills の関連スキル
• 次のものを含む公式の Google Cloud ドキュメント:
  • マルチクラウドデータレイク、構造化データウェアハウス、非構造化 データストアにまたがるエージェント型クロスクラウド分析ワークフローの リファレンスアーキテクチャ: https://docs.cloud.google.com/architecture/agentic-ai-cross-cloud-analytics.md.txt
  • ワークロードに関連する製品とトピックに関する意思決定ガイド: https://github.com/google/skills/blob/main/skills/cloud/google-cloud-solution-architecture/references/decision-making-guides.md
  • ワークロードに関連する製品とトピックに関するベストプラクティス ガイド: https://github.com/google/skills/blob/main/skills/cloud/google-cloud-solution-architecture/references/best-practices-guides.md

タスク 2.1: ワークロードに必要な Google Cloud の製品と機能を特定する。

1. 確定した技術的分解の各コンポーネントについて、次のリソースのガイダンス に基づき、承認された技術的分解に応じて適切に調整しながら、適切な Google Cloud の製品と機能を特定します。
   • references/product-selection-guidance.md
   • https://github.com/google/skills/blob/main/skills/cloud/google-cloud-solution-architecture/references/decision-making-guides.md
2. 生成された製品の推奨事項を提示し、その推奨事項の承認をユーザーに 求めます。
3. ユーザーが変更を要求した場合は、必要な変更を行います。
4. ユーザーが製品の推奨事項を承認するまで、ステップ 2 と 3 を繰り返します。
5. ユーザーが製品の推奨事項を承認した後、タスク 2.2 に進みます。

タスク 2.2：アーキテクチャ図を生成する

1. Mermaid 形式のアーキテクチャ図を生成します： https://github.com/mermaid-js/mermaid。
2. 生成した図をユーザーに提示し、アーキテクチャ図の承認を求めます。
3. ユーザーから変更の依頼があった場合は、必要な変更を行います。
4. ユーザーがアーキテクチャ図を承認するまで、手順 2 と 3 を繰り返します。
5. ユーザーがアーキテクチャ図を承認したら、タスク 2.3 に進みます。

タスク 2.3：アーキテクチャの説明を生成する

1. 各コンポーネントの目的、コンポーネント間の関係、およびタスクの流れやデータフローを説明する記述を生成します。
2. 生成したアーキテクチャの説明をユーザーに提示し、説明の承認を求めます。
3. ユーザーから変更の依頼があった場合は、必要な変更を行います。
4. ユーザーがアーキテクチャの説明を承認するまで、手順 2 と 3 を繰り返します。
5. ユーザーがアーキテクチャの説明を承認したら、タスク 2.4 に進みます。

タスク 2.4：設計上の推奨事項を生成する

1. ワークロードの要件に基づいて、アーキテクチャ内の各コンポーネントを最適に構成するための設計上の推奨事項とベストプラクティスを生成します。

   重要：

   • 設計上の推奨事項を生成する際は、以下を考慮してください：
     • フェーズ 1 で収集した機能要件。
     • フェーズ 1 で収集した非機能要件。
   • 生成する設計上の推奨事項は、references/design-recommendations.md の推奨事項に沿ったものにしてください。
   • Knowledge Catalog の設計上の推奨事項を生成するには、references/knowledge-catalog-documentation.md に記載されているリソースを使用してください。
   • 非機能要件に関するガイダンスを生成するには、以下のスキルを使用してください：
     • google-cloud-waf-security
     • google-cloud-waf-reliability
     • google-cloud-waf-cost-optimization
     • google-cloud-waf-operational-excellence
     • google-cloud-waf-performance-optimization
     • google-cloud-waf-sustainability

2. 生成した推奨事項をユーザーに提示し、変更が必要かどうかを尋ねます。

3. ユーザーが変更を希望する場合は、必要な変更を行います。

4. ユーザーが生成された設計上の推奨事項が要件を満たしていると確認するまで、手順 2 と 3 を繰り返します。

5. タスク 2.5 に進みます。

タスク 2.5：デプロイ手順を作成します。

1. ユーザーがソリューションをデプロイできるように、コードと手順を含むデプロイ手順を作成します。

   重要：

   • デプロイ手順には、Google Cloud プロジェクトの設定、課金の有効化、必要な API の有効化、必要なロールと権限の設定など、デプロイの前提条件に関する手順を含める必要があります。
   • 作成するデプロイ手順の技術的な基盤として、以下のリソースを使用してください。
     • https://github.com/gemini-cli-extensions/data-agent-kit-starter-pack/tree/main/skills： 複雑なデータパイプラインの設計、dbt によるデータ変換、Spark と BigQuery の SQL ノートブックの作成、Dataflow パイプラインの作成とトラブルシューティング、Google Cloud のデータエコシステム全体にわたるエンドツーエンドのワークフローのオーケストレーションを、好みのコーディングエージェントを使って行えるようにする、専門的なスキルと MCP ツールのスイートを提供するプラグインです。
     • https://codelabs.developers.google.com/next26/gen-keynote/raw-data-forecasting#0： 好みのエージェント型開発環境から Data Agent Kit 拡張機能を使用して、クラウドをまたぐデータトポロジーを効率的に分析する手順を説明する Codelab です。
     • https://codelabs.developers.google.com/governance-context-part1#0：BigQuery にデータ基盤を構築し、厳格なメタデータタグ（Knowledge Catalog Aspects）を適用して有効なデータとノイズを区別し、Gemini CLI を使用して LLM がガバナンスルールに厳密に従うかをローカルでテストする手順を説明する Codelab です。
     • https://docs.cloud.google.com/dataplex/docs/establish-foundational-data-context.md.txt： Knowledge Catalog でデータコンテキストを確立する方法を示すチュートリアルです。
     • https://docs.cloud.google.com/dataplex/docs/ingest-custom-sources.md.txt： 独自のカスタムデータソースに関する情報を Knowledge Catalog に取り込む方法を説明するガイドです。

2. 作成したデプロイ手順をユーザーに提示し、変更が必要かどうかを尋ねます。

3. ユーザーが変更を求めた場合は、必要な変更を加えます。

4. 作成したデプロイ手順が要件を満たしているとユーザーが確認するまで、手順 2 と 3 を繰り返します。

5. フェーズ 3 に進みます。

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

1. 作成したソリューションを検証する計画を作成します。この計画では、作成したソリューションがワークロードの要件を満たしていることを確認する手順を示す必要があります。
2. 検証計画をユーザーに提示し、フィードバックまたは承認を求めます。
3. ユーザーが変更を求めた場合は、必要に応じて計画を更新します。
4. ユーザーが検証計画を承認するまで、手順 2 と 3 を繰り返します。
5. 承認された検証計画の手順を実行するために、curl や gcloud などのツールを使用してスクリプトまたはコマンドを作成します。
6. 検証チェックを実行する許可をユーザーに求めます。
7. ユーザーが許可した場合は、検証チェックを実行し、デプロイに関する問題をトラブルシューティングします。
8. すべての検証チェックに合格したら、フェーズ 4 に進みます。

フェーズ 4：ソリューションのパッケージ化と提示

1. フェーズ 2 とフェーズ 3 で作成したテキスト成果物を、assets/output-template.md のテンプレートに基づいて、solution-architecture-guide.md という名前の単一の Markdown ファイルにまとめます。
2. 統合した solution-architecture-guide.md をユーザーに提示します。
3. ユーザーのワークスペースにコードファイルを書き込む許可をユーザーに求めます。
4. ユーザーが許可した後、ユーザーのワークスペースにコードファイルを書き込みます。

参考リソース

• https://docs.cloud.google.com/data-cloud-extension/antigravity/transform-data.md.txt: Data Agent Kit 拡張機能を使用して、ノートブックでデータの変換と分析を行う方法を説明するガイドです。
• https://docs.cloud.google.com/dataplex/docs/use-cases.md.txt: Knowledge Catalog のユースケースです。
• https://docs.cloud.google.com/managed-spark/docs/guides/lightning-engine-serverless.md.txt: Lightning Engine を使用して Apache Spark のワークロードを高速化する方法を説明するガイドです。
• https://docs.cloud.google.com/bigquery/docs/use-knowledge-catalog.md.txt: BigQuery のガバナンスおよびエージェント機能レイヤーとして Knowledge Catalog を使用する方法を説明するガイドです。