google-cloud-solution-architecture

Google Cloud ソリューションアーキテクチャのワークフロー

帰属表示

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

ワークフローの概要

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

• フェーズ 1：要件の確認。ユーザーが支援を必要としているクラウドワークロードまたはユースケースに関する詳細な要件を収集します。
• フェーズ 2：ソリューションアーキテクチャ。フェーズ 1 で収集した要件に基づき、クラウドワークロードまたはユースケースの詳細なソリューションアーキテクチャを作成します。
• フェーズ 3：ソリューションの検証。作成したソリューションを検証する計画を立て、検証手順とスクリプトを作成して、ユーザーに提供し、実行してもらいます（または、ユーザーから明示的な許可を得てドライラン検証を実施します）。
• フェーズ 4：ソリューションの整理と提示。作成したコンテンツをまとめて、ソリューションを提示します。

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

• フェーズの厳密な分離：フェーズ 1（要件の確認）でユーザーに確認の質問をする際は、アーキテクチャ設計、技術的な分解、クラウドサービス、コンポーネントのマッピングについて、推奨、提案、概要の提示を行わないでください。機能要件と非機能要件を十分に評価する前にソリューションを提案すると、確証バイアスを招き、特定の製品、機能、ツールに早々に依存するリスクがあります。

• 反復的な承認とタスクの移行：このワークフローで作成する各成果物（技術的な分解、製品の推奨、図、アーキテクチャの説明、デプロイスクリプト）は、ユーザーに提示し、承認を得てください。ユーザーが変更を求めた場合は、次のタスクやフェーズに進む前に、承認されるまで内容を繰り返し修正してください。

• コードやスクリプトの自律的な実行は禁止：ユーザーから明示的かつ明確な許可を得ずに、作成したスクリプトやコードを実行しないでください。スクリプトを自律的に実行すると、意図しないクラウドリソースのプロビジョニング（予期しない費用の発生）、稼働中のインフラストラクチャの変更、セキュリティや安全上のリスクにつながる可能性があります。ユーザーがコマンドを手動で実行できる選択肢を必ず提示してください。

• 一部のフェーズを省略できる場合：ユーザーのプロンプトから、このワークフローの特定のフェーズやタスクがすでに完了または承認済みであると分かる場合（例：「要件確認の段階は完了しています」、「製品の選定は承認済みです」、「アーキテクチャは確定しています」）、そのフェーズやタスクを繰り返さないでください。代わりに、依頼されたタスク（技術的な分解の作成、製品の推奨、ソリューションガイドの作成など）に直接進んでください。

フェーズ 1：要件の把握

1. ユーザーが支援を必要としているワークロードまたはユースケースに関連する、以下の要件を収集します。

   重要：ユーザーがこれらの要件を提示するまで、アーキテクチャ設計、製品の推奨事項、技術的な分解を生成してはなりません。

   • 機能要件：ワークロードのビジネスプロセス、アクティビティ、ユースケースについてユーザーに説明を求めます。
   • 非機能要件：セキュリティ、プライバシー、コンプライアンス、信頼性、災害復旧、コスト、運用、パフォーマンス、持続可能性に関する要件についてユーザーに説明を求めます。
     • 重要：非機能要件が不足している、または不完全な場合は、その重要性を明確に説明したうえで（たとえば、運用 SLA、可用性ティア、スケーリング構成、コスト予算、リソースの種類、セキュリティ体制を直接決定するため）、要件の提示をユーザーに求めなければなりません。
   • 現状：ワークロードが現在、他のクラウドプロバイダーまたはオンプレミスで稼働しているかどうかを尋ねます（稼働している場合は、既存のデプロイのアーキテクチャについて説明を求めます）。
   • システム依存関係：アプリケーションと他のワークロード、製品、システム、ツールとの依存関係についてユーザーに説明を求めます。

2. これまでにユーザーが提示した情報を確認し、曖昧な点や矛盾がないかを確認します（例：ネットワークを完全に分離し、インターネットに一切公開しないという目標と、公開 API からのリアルタイム取り込みとの矛盾）。

   ユーザーの要件に曖昧な点や矛盾がある場合は、次の対応を行う必要があります。

   • 曖昧な点や矛盾を明確に説明します。
   • 矛盾する要件を同時に満たせない理由を説明します。
   • 曖昧さや矛盾を解消するため、トレードオフに関する希望や選択を明確にするようユーザーに求めます。
     • ユーザーが選択を委ねた場合（たとえば、「最善だと思う方法で進めてください」や「お任せします」と回答した場合）は、曖昧さや矛盾を解消するための明確な提案を提示し、その理由を説明してから、提案への承認をユーザーに求めます。

   重要：特定した曖昧さや矛盾がすべて解消されるまで、アーキテクチャ設計、技術的な分解、Google Cloud 製品の推奨事項を提案または生成してはなりません。曖昧な要件や矛盾する要件は、無効なアーキテクチャ上の前提につながります。

3. ワークロードのコンポーネントを論理的な単位に分解した技術的な分解を生成します。フェーズ 2 に進む前に、その内容をユーザーに提示し、承認を得ます。

   重要：フェーズ 2 に進む前に、ユーザーが技術的な分解を承認したことを確認してください。技術的な分解とユーザーの要件との不整合は、このワークフローの後続フェーズの出力を無効にします。

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

フェーズ 1 で承認された要件を使用して、包括的なソリューションアーキテクチャを生成します。

生成するすべてのコンテンツの根拠を明確にする

このフェーズの各タスクでは、生成するコンテンツを最新の正式な Google Cloud のガイダンスに沿ったものにするため、以下のリソースを使用して根拠を明確にする必要があります。

• Google Developer Knowledge MCP サーバー
  • サーバー：https://developerknowledge.googleapis.com/mcp
  • ツール：
    • developerknowledge:search_documents
    • developerknowledge:get_documents
    • developerknowledge:answer_query
• https://github.com/google/skills の関連スキル
• 以下を含む、Google Cloud の公式ドキュメント：
  • ワークロードのテクノロジーカテゴリに関連するリファレンスアーキテクチャと設計ガイド：references/architecture-guides.md
  • ワークロードに関連するプロダクトとトピックの選定ガイド：references/decision-making-guides.md
  • ワークロードに関連するプロダクトとトピックのベストプラクティスガイド：references/best-practices-guides.md

生成するガイダンスの各項目には、関連する Google Cloud 公式ドキュメントページの引用を含める必要があります。

タスク 2.1：ワークロードに必要な Google Cloud のプロダクトと機能を特定する

1. ユーザーのワークロードの各コンポーネントに適したプロダクトと機能を推奨します。

   重要：

   • 非推奨、廃止、提供終了、またはサポート対象外のプロダクトや機能は推奨しないでください。プロダクトや機能のステータスを確認するには、developerknowledge:answer_query または developerknowledge:search_documents を、"{product_name} release status" のようなクエリ文字列とともに呼び出します。
   • ワークロードのあるコンポーネントに複数のプロダクトや機能を使用できる場合は、次の手順に従ってください。
     • 最も適切なプロダクトや機能を推奨します。代替プロダクトがある場合、関連するプロダクトのドキュメントに各プロダクトを選択するタイミングのガイダンスが記載されていることがあります。そのガイダンスに従ってください。
     • 利用可能な代替プロダクトや機能について説明します。
     • 各代替プロダクトや機能の長所と短所を説明します。

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

   重要：同じターン内では、これ以上の内容（アーキテクチャ図、説明、デプロイ構成など）を生成しないでください。ユーザーがプロダクトの選択を承認するまで、プロダクトの選択肢を提示した直後に処理を停止します。

3. ユーザーがプロダクトの選択を承認した後、タスク 2.2 に進みます。

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

1. Mermaid 形式でアーキテクチャ図を生成します： https://github.com/mermaid-js/mermaid。
2. 生成した図をユーザーに提示し、タスク 2.3 に進む前に承認を得ます。

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

1. 各コンポーネントの目的、コンポーネント間の関係、タスクフローまたはデータフローを説明する内容を生成します。
2. 生成したアーキテクチャの説明をユーザーに提示し、タスク 2.4 に進む前に承認を得ます。

タスク 2.4：設計に関する推奨事項を作成する

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

   重要：

   • 設計に関する推奨事項を作成する際は、次の内容を反映してください。
     • フェーズ 1 で収集した機能要件。
     • フェーズ 1 で収集した非機能要件。
   • 非機能要件に関するガイダンスを作成するには、次のリソースを使用してください。
     1. ワークロードに関連する製品やトピックのベストプラクティスガイド：references/best-practices-guides.md
     2. Well-Architected Framework の柱に関するスキル：
        • セキュリティ要件：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. 作成した推奨事項をユーザーに提示し、タスク 2.5 に進む前に承認を得ます。

タスク 2.5：デプロイガイダンスを作成する

1. ソリューションをデプロイできるようにするためのインフラストラクチャ・アズ・コードと手順を含む、デプロイガイダンスを作成します。
2. 作成したデプロイガイダンスをユーザーに提示し、フェーズ 3 に進む前に承認を得ます。

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

タスク 3.1：デプロイ前の検証

1. 生成したソリューションを静的に検証し、稼働中のリソースをプロビジョニングせずにワークロードの要件を満たしていることを確認するための、デプロイ前の計画を作成します。
   • デプロイのドライラン：ドライランコマンド（例：terraform plan または（サポートされている場合）gcloud ... --dry-run）を使用して、インフラストラクチャの構文を検証し、プロビジョニングされるリソースをプレビューします。
   • アーキテクチャとポリシーの分析：ネットワークルーティングトポロジ、ファイアウォールルール、IAM の適用について、ベストプラクティスに照らして静的に検証します。
2. 静的検証計画をユーザーに提示し、ドライランコマンドを実行する明示的な許可を得ます。ユーザーから許可を得た場合はコマンドを実行します。許可を得られない場合、またはユーザーが希望する場合は、ユーザーが手動で実行できる正確なコマンドを提示します。
3. ドライランのチェックで特定されたエラーやポリシーとの不一致をトラブルシューティングして修正し、検証が成功するまで続けます。
4. タスク 3.2 に進みます。

タスク 3.2：ランタイム検証（デプロイ後）

1. ライブ環境でランタイム検証を行うために今すぐインフラストラクチャをデプロイするか、フェーズ 4 に直接進むかをユーザーに尋ねます。
2. ユーザーがインフラストラクチャのデプロイを選択した場合：
   • ユーザーがインフラストラクチャをデプロイした後、ライブエンドポイントへの到達可能性、ネットワーク経路、ロードバランサーのルーティングをテストするために、ランタイム検証コマンド（curl、ping、gcloud などのツールを使用）を作成し、ユーザーが実行できるように提示します。
   • チェックに合格するまで、デプロイやランタイムルーティングに関する問題をトラブルシューティングします。
3. フェーズ 4 に進みます。

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

最終的な提示に向けて、生成したすべてのテキストおよびコードの成果物をパッケージ化します。

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