aws-solution-architect

aws-solution-architect skillの概要

aws-solution-architectの用途

aws-solution-architectは、スタートアップ向けのAWSアーキテクチャ設計を支援するClaude skillです。サービス選定、コスト見積もり、Infrastructure as Codeの方針まで含めて整理できます。単に「AWSサービスを選ぶ」だけでなく、説明可能なアーキテクチャパターン、実装フェーズ、コストを意識したトレードオフまで出したいCloud Architecture作業に向いています。

向いているユーザーと判断シーン

このaws-solution-architect skillは、SaaSプラットフォーム、モバイルバックエンド、Webアプリ、マイクロサービス、データパイプライン、移行案件について、初期段階のAWS設計を必要とする創業者、スタートアップのエンジニア、プラットフォームチーム、コンサルタントに適しています。特に、Lambda/API Gateway/DynamoDBによるサーバーレス構成と、ECS Fargate、Aurora、ElastiCache、EventBridge、Step Functions、マルチリージョン構成などを比較する必要がある場合に有用です。

汎用プロンプトとの違い

このリポジトリには、実務で使える判断材料としてreferences/architecture_patterns.md、references/service_selection.md、references/best_practices.mdが含まれています。さらに、アーキテクチャ推奨、サーバーレススタック生成、コスト最適化のためのPythonスクリプトも用意されています。そのため、単に「AWSアーキテクチャを設計して」と依頼するよりも、要件収集、パターン選定、コスト見積もり、IaC風の出力生成、リスクレビューという明確な流れで進めやすくなります。

得意な領域と注意が必要な領域

初期のアーキテクチャ検討、コストに敏感なスタートアップ向け設計、サーバーレス優先のシステム、構造化されたAWSサービス選定に強みがあります。一方で、人間のAWSレビューなしに、最終的なセキュリティレビュー、コンプライアンス証明、本番デプロイ計画として扱うべきではありません。料金、リージョンごとの提供状況、クォータ、コンプライアンス管理策は、実装前に最新のAWSドキュメントで確認する必要があります。

aws-solution-architect skillの使い方

aws-solution-architectのインストールとリポジトリパス

GitHubリポジトリから次のコマンドでskillをインストールします。

npx skills add alirezarezvani/claude-skills --skill aws-solution-architect

skillは次の場所にあります。

engineering-team/skills/aws-solution-architect

インストール後は、まずSKILL.mdを読んでワークフローを確認してください。その後、次のファイルを確認します。

• assets/sample_input.json：想定される要件入力の形式
• assets/expected_output.json：出力構造
• references/architecture_patterns.md：パターン選定
• references/service_selection.md：サービスごとのトレードオフ
• references/best_practices.md：信頼性、セキュリティ、コストの指針
• scripts/architecture_designer.py、scripts/cost_optimizer.py、scripts/serverless_stack.py：実装ロジック

skillに渡すべき入力情報

aws-solution-architectをうまく使うには、アプリのアイデアだけでは不十分です。アプリケーション種別、想定ユーザー数、秒間リクエスト数、リージョン、月額予算、チーム規模、AWS経験値、データ量、コンプライアンス要件、可用性目標、認証・リアルタイム更新・マルチリージョン・オートスケーリングなどの特別な要件を含めてください。

弱いプロンプトの例です。

Design AWS architecture for my SaaS.

より強いプロンプトの例です。

Use aws-solution-architect for Cloud Architecture. Design an AWS architecture for a B2B SaaS in us-east-1 with 50,000 expected users, 100 RPS average, 500 GB relational data, GDPR requirements, $1,500/month target budget, 5 engineers, intermediate AWS experience, authentication, high availability, autoscaling, no real-time features, and no multi-region requirement. Compare serverless and ECS/Aurora options, estimate monthly cost, list risks, and propose phased implementation.

このように書くと、トラフィック、予算、チームの運用能力、コンプライアンス、ワークロードの特性をもとに判断できるため、skillの意思決定ロジックが働きやすくなります。

実プロジェクトでのおすすめワークフロー

いきなり最終設計を求めるのではなく、まず不足している要件を洗い出してもらうところから始めると効果的です。その後、パターン推奨、サービススタック、コスト内訳、トレードオフ、IaC方針を順に依頼します。例は次のとおりです。

1. “Ask me missing AWS architecture requirements before designing.”
2. “Recommend the best pattern using references/architecture_patterns.md.”
3. “Explain why the rejected patterns are weaker for this case.”
4. “Generate a phased implementation plan with CloudFormation, CDK, or Terraform assumptions.”
5. “Review cost, security, scaling, and operational risks.”

すでにAWSリソースがある場合は、現在のインベントリと支出も含めてください。そうすることで、コスト最適化の流れがより実態に合いやすくなります。

出力品質を上げる実践的なコツ

サービス選定に影響する制約は明確に書きましょう。たとえば、レイテンシ目標、長時間実行ジョブの有無、データベース整合性、コンプライアンス範囲、災害復旧、想定されるトラフィックスパイク、デプロイ方針、チームがコンテナやデータベースを運用できるかどうかです。IaCが必要な場合は、CloudFormation YAML、AWS CDK TypeScript、Terraform HCLのどれで出力したいかを指定します。スタートアップとしてコストを抑えたいなら、最終形だけでなく「MVP now, scale later」という前提で依頼するとよいでしょう。

aws-solution-architect skillのFAQ

aws-solution-architectは初心者にも向いていますか？

はい。基本的なプロダクト要件とトラフィック前提を提示できるなら、初心者にも向いています。このskillには、Lambda、ECS Fargate、Aurora、DynamoDB、API Gateway、SQS、EventBridge、Cognito、CloudFrontなどのAWSサービスをいつ使うべきかを説明するサービス選定リファレンスが含まれています。ただし初心者の場合は、テンプレート生成だけを求めるのではなく、トレードオフや実装フェーズも説明してもらうと理解しやすくなります。

このskillを使うべきでないケースは？

規制対象の本番システム、複雑なエンタープライズ向けlanding zone、深いネットワーク設計、Kubernetes中心のプラットフォーム、最終的なコンプライアンス判断において、唯一の判断材料として使うべきではありません。HIPAA、GDPR、SOC 2、可用性、セキュリティ上の論点を洗い出すことはできますが、認定AWSアーキテクト、脅威モデリング、Well-Architected Review、最新のAWS料金確認の代替にはなりません。

Claudeに直接聞く場合と何が違いますか？

Claudeに直接プロンプトを投げても、もっともらしいAWS構成図や設計案は得られます。一方で、aws-solution-architect skillには、再現しやすいワークフロー、入力・出力スキーマの例、アーキテクチャパターンのリファレンス、サービス選定マトリクス、推奨とコスト最適化の挙動をコード化したスクリプトがあります。そのため、出力の一貫性が高まり、後から検証しやすくなります。

デプロイ可能なインフラを生成できますか？

IaC生成の方針を示すことができ、想定出力ではCloudFormation、AWS CDK、Terraform形式の成果物が参照されています。ただし、生成されたインフラは出発点として扱ってください。デプロイ前に、IAMスコープ、VPC設計、シークレット管理、暗号化、ログ、アラーム、バックアップ方針、環境分離、リージョン別料金を必ずレビューする必要があります。

aws-solution-architect skillを改善する方法

明確な制約でaws-solution-architectの結果を改善する

aws-solution-architectの出力を最も早く改善する方法は、測定可能な制約を与えることです。「スケーラブルで安く」ではなく、「現在100 RPS、12か月後に1,000 RPSを支える」「月額$1,500以内に収める」「4時間のRTOを許容する」「可能な限りマネージドサービスを使う」のように書き換えます。そうすれば、serverless、ECS Fargate、Aurora、DynamoDB、イベント駆動パターンのどれを選ぶべきか、推測を減らして判断できます。

推奨だけでなくトレードオフも聞く

アーキテクチャ検討では、採用しなかった選択肢も重要です。特定のワークロードに対して、なぜEKS、EC2、Aurora、DynamoDB、App Runner、Lambdaを選ばなかったのかを説明してもらいましょう。これにより、コールドスタート、Lambdaの15分制限、運用複雑性、データベースアクセスパターン、予測可能なトラフィック、チーム経験値といった隠れた前提が見えやすくなります。

初稿から実装計画へ反復する

最初のアーキテクチャ案が出たら、次はリスクに焦点を当てた再レビューを依頼します。確認すべき観点は、コストが膨らみやすい箇所、単一障害点、IAMリスク、可観測性の不足、データ移行、ロールバック戦略、クォータ制限です。そのうえで、基盤、コアサービス、セキュリティとモニタリング、CI/CD、スケールアウトという段階的な提供計画を求めます。これはassets/expected_output.jsonの構造にも沿っており、より実行しやすい計画になります。

出力を信頼する前にスクリプトとリファレンスを確認する

重要な設計に使う前に、リポジトリ内のスクリプトとリファレンスを確認してください。architecture_designer.pyを見ると、どの要件フィールドが推奨に影響するかが分かります。cost_optimizer.pyからは、どのコストカテゴリを考慮しているかを確認できます。service_selection.mdとbest_practices.mdを読めば、ガイダンスの前提が見えてきます。これにより、aws-solution-architectのガイドを自分のAWSアカウント、リージョン、コンプライアンスレベル、デプロイツールチェーンに合わせて調整しやすくなります。