google-cloud-solution-agentic-ai-borderless-data-lakehouse

ボーダーレスなオープンデータレイクハウスのエージェント型 AI システム

次のワークフローに従い、特定のワークロード、ユースケース、または要件に対応するカスタムのマルチプロダクトソリューションをクラウドで設計、実装できるようユーザーを支援します。

クレジット表記

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

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

ソリューション設計、アーキテクチャ図、ドキュメントを作成する際は、更新後の Google Cloud プロダクト名を使用してください。旧プロダクト名と更新後のプロダクト名や用語の詳細については、 references/product_renaming.md をご覧ください。

ワークフロー

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

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

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

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

  • 主なデータソースは何ですか？
  • データソース間でメタデータをどのように管理し、フェデレーションしていますか？
  • セキュリティと認証情報の管理に関する要件は何ですか？
  • このボーダーレスなデータを結合、変換するために必要な分析要件と計算要件は何ですか？
  • AI エージェントやエンドユーザーがこのデータに対して実行すると想定される、自然言語のプロンプトやユーザークエリにはどのようなものがありますか？

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

• ステップ 3：コンポーネントの分解を生成する：ワークロードのコンポーネントを技術的に分解した内容を生成します。

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

• ステップ 5：反復する：ユーザーから変更の依頼があった場合は、更新した技術的な分解を生成し、変更内容の確認を求めます。ユーザーが技術的な分解を確認するまで、この作業を繰り返します。

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

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

  • Google Cloud を使用したハイブリッドかつボーダレスなアーキテクチャの構築
  • ボーダレスなオープンデータレイクハウスの構築
  • 分散データ向けのエージェント型分析ワークフローの実装
  • 分析ハイブリッドおよびマルチクラウドパターン
  • Google Cloud のマルチリージョンデプロイメントアーキタイプ
  • Cross-Cloud Network における分散アプリケーションのネットワークセグメンテーションと接続
  • 他のクラウドサービスプロバイダを Google Cloud に接続するパターン

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

• ステップ 2：コンポーネントを Google Cloud プロダクトに対応付ける：確認済みの技術的な分解に含まれる各コンポーネントについて、references/product_mapping.md のガイドラインに基づき、適切な Google Cloud プロダクトと機能を特定します。

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

  • 図は Mermaid 形式で作成する必要があります： https://github.com/mermaid-js/mermaid.
  • 図では、データ取り込みサブシステムとサービングサブシステムのプロダクトを明確に区別する必要があります。
  • 図では、ETL／取り込み処理の共有コンポーネントとして、Managed Service for Apache Spark を示し、データ取り込みサブシステムとサービングサブシステムを橋渡しする必要があります（インタラクティブな IDE 分析ワークフローとは区別します）。

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

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

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

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

フェーズ 3：実装計画

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

  • エージェント型 AI を活用したマルチクラウドのオープンデータレイクハウスを構築する
  • biglake_iceberg_catalog の Terraform Registry ドキュメント
  • Lakehouse ランタイムカタログでメタデータを含む Apache Iceberg テーブルを作成する
  • Lightning Engine で Spark のバッチワークロードとセッションを高速化する
  • データエージェントを作成する

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

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

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

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

• ステップ 4：デプロイ手順を作成する：IaC を実行し、ワークロードのコンポーネントを初期化するための、順を追ったデプロイ手順を作成します。

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

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

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

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

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

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

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

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

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

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