amazon-elasticache

ElastiCache

レジストリ形式でサブスキルを整理した、モジュール式の ElastiCache ツールキットです。各サブスキルは、ElastiCache に関する特定の領域を扱います。以下のルーターは、ユーザーの意図に適したサブスキルを判断し、そのサブスキルに必要な参照資料のみを読み込みます。

このスキルの仕組み

1. ユーザーのリクエストを、以下のレジストリにある意味カテゴリと照合します。完全に同じ表現ではなく、意味で判断してください（「どのデータ構造を使えばよいか考えるのを手伝って」は、「パターン」という単語がなくても data-modeling に該当します）。
2. 曖昧な場合の判断： ユーザーの意図が複数のサブスキルに該当する場合は、次のルールを順番に適用します。
   • .elasticache/requirements.json が存在し、infrastructure.endpoint が設定されている場合は、monitoring または data-modeling を優先します（既存のキャッシュがあります）。
   • キャッシュが存在しない場合（requirements.json がない、またはエンドポイントが設定されていない場合）は、requirements を優先します。
   • それでも曖昧な場合は、確認のために次の質問を1つだけします。「新しく何かをセットアップしたいですか。それとも既存のものをトラブルシューティングしたいですか？」
3. エンジンまたはデプロイモデルを推奨する前に、「ガードレール」セクションを確認します。
4. 該当するサブスキルの references/{sub-skill-id}/instructions.md を読み込みます。相対パスにファイルが見つからない場合は、プロンプトまたは環境内でスキルディレクトリの絶対パスを確認し、{skill-directory}/references/{sub-skill-id}/instructions.md を再試行します。
5. リクエストが複数のサブスキルにまたがる場合は、パイプラインの順序に従って実行します。
6. サブスキルに、まだセッションメモリにない上流コンテキスト（エンジン、デプロイモデル、エンドポイント）が必要な場合は、先に上流のサブスキルに振り分けます。
7. 該当するサブスキルがない場合は、まず requirements を有効にします。
8. スクリプトまたは CLI の呼び出しに失敗した場合は、エラーをユーザーに表示し、再試行する前に具体的な修正方法を提案します。

サブスキルレジストリ

各エントリには、ID（references/ 配下のディレクトリ名）、領域の説明、照合に使う意味カテゴリ、上流／下流の依存関係が含まれます。

ID	Name	Domain	Semantic Categories	Upstream	Downstream
requirements	ソリューションの適合性	ワークスペースのスキャンと構造化されたヒアリングを通じて、ワークロード、スタック、規模、レイテンシー、永続性、予算を収集します。ElastiCache が適切なサービスかどうかを判断し、ルーティングの推奨事項を添えて引き継ぎます。	キャッシュが必要、アプリを高速化したい、データベースの負荷を軽減したい、Bedrock のコストを下げたい、ElastiCache を使うべきか、ワークロードに最適なものは何か、キャッシュの選択肢を評価中、ElastiCache と X の比較、Valkey と X の比較、要件が漠然とした新しいワークロード	—	setup、data-modeling、genai、monitoring、migration
setup	作成と接続	プロビジョニング、接続性、セキュリティ、認証、IaC、デプロイ方法を扱います。最小限の手間で、ユーザーが利用可能なキャッシュを使えるようにします。エンジンの選択、サーバーレスとノードベースの比較、VPC、TLS、RBAC/IAM、ジャンプホスト／SSM トンネル、CLI/SDK/CFN/CDK/Terraform のスターターを扱います。	キャッシュを作成、ElastiCache をセットアップ、プロビジョニング、Valkey クラスター、Lambda/ECS/EKS/EC2 を接続、VPC、セキュリティグループ、TLS、RBAC、IAM 認証、ジャンプホスト、SSM トンネル、CloudFormation、CDK、Terraform、エンジンの選択、サーバーレスとノードベースの比較、バックアップ、スナップショット、復元、エクスポート	requirements（任意）	data-modeling、genai、monitoring
data-modeling	アプリケーションパターン	AI 以外のパターン（キャッシュアサイド、セッションストア、レート制限、リーダーボード、カウンター、Pub/Sub、ストリーム、ショッピングカート、ジョブキュー、アクティビティフィード）に適したデータ構造、キーのスキーマ、TTL 戦略、無効化の方法、クライアントコードを選択します。	セッションストア、レート制限、リーダーボード、キャッシュアサイド、クエリーのキャッシュ、カウンター、ストリーム、Pub/Sub、ショッピングカート、ジョブキュー、アクティビティフィード、キーのスキーマ、TTL、無効化、データ構造	setup（キャッシュが必要）	monitoring
genai	AI およびベクトルワークロード	リクエストをモード 1（通常のキャッシュ）、モード 2（セマンティックレスポンスキャッシュ）、モード 3（完全なベクトル検索）のいずれかに分類します。サーバー側のベクトル類似検索が必要な場合は Valkey を選び、ノードベースの Valkey 8.2 以上（9.0 を推奨）を必須とします。セマンティックキャッシュ、エージェントメモリ、RAG 検索、レコメンデーション、パーソナライゼーション、AI エージェントの会話／セッションの永続化、フレームワークとの連携（Strands、mem0、LangChain）を扱います。	セマンティックキャッシュ、RAG、エージェントメモリ、会話メモリ、ベクトル検索、埋め込み、レコメンデーション、パーソナライゼーション、Bedrock のレイテンシー、Bedrock のコスト、LLM のキャッシュ、Strands、mem0、LangChain、会話履歴、AI セッションストア、埋め込みプロバイダー、フレームワーク連携	setup（キャッシュが必要）	monitoring
monitoring	運用と監視	まずメトリクスを使ってパフォーマンス、コスト、信頼性を診断し、次に最小限の変更を推奨します。ダッシュボード、アラーム、ログ配信、コストレポート、イベントルーティング、CPU 使用率の高さ／メモリ不足／レプリケーションラグ／接続数の急増／ヒット率の低さ／ホットキー／巨大なキー／スロットの偏り／レイテンシー急増の根本原因のトラブルシューティングを扱います。	キャッシュが遅い、コストが高すぎる、ヒット率が低い、CPU 使用率が高い、メモリ不足、レプリケーションラグ、接続数の急増、ダッシュボード、アラーム、CloudWatch、コスト比較、トラブルシューティング、ホットキー、シャードの負荷の偏り、1 つのノードに負荷が集中、巨大なキー、メモリの肥大化、最も大きなキーはどれか、キースペースの分布、プレフィックス分析、テナントごとのコスト帰属、メモリの偏り、1 つのシャードが満杯、スロット間のメモリの偏り、レイテンシーの急増、遅いコマンドのインシデント、レイテンシー上昇の根本原因	—	setup、migration
migration	エンジンとプラットフォームの移行	移行経路を選択し、事前確認、検証、切り替え、ロールバックの順序を決めます。セルフマネージド Redis から ElastiCache への移行、Redis OSS から Valkey への移行、ノードベースとサーバーレスの切り替え、バージョンアップグレードを扱います。移行前の検証を必須とするゲートを設けます。	移行、Redis OSS から Valkey への移行、セルフマネージドから ElastiCache への移行、ノードベースからサーバーレスへの移行、サーバーレスからノードベースへの移行、エンジンのアップグレード、バージョンのアップグレード、ダウンタイムなしの切り替え、ロールバック	—	setup、monitoring

パイプラインの順序

サブスキルはそれぞれ独立して実行されますが、一般的な複数ステップの流れは次のパイプラインに沿って進みます。

• requirements → setup → (data-modeling | genai) → monitoring
• migration → setup → monitoring
• monitoring → setup | migration（メトリクスが示す場合）

状態の引き継ぎ：requirements.json

.elasticache/requirements.json は、サブスキル間の状態を管理する唯一の信頼できる情報源です。各サブスキルは開始時にこのファイルを読み取り、作業完了後に自身のセクションを書き込みます。書き込む前に読み取り、上書きせずにマージしてください。

セクション	担当	主なフィールド
トップレベル	requirements	engine、deployment_model、region、runtime、patterns、use_case、vpc_id、subnet_ids、security_group_ids
infrastructure	setup	cache_name、resource_id、engine_version、topology、endpoint、port、auth_model、tls、client_library、execution_path、access_mode、tunnel_instance_id、embedding_provider、embedding_model、embedding_dim、embedding_module
genai	genai	mode、mode_2_path、framework
migration	migration	source_type、source_host、migration_path、cutover_status

所有権に関する注意： deployment_model は、初回のヒアリング時に requirements が設定します。エンジンまたはデプロイメントモデルを切り替える場合（例：ノードベースからサーバーレス）、migration がこの値を更新することがあります。

requirements.json のトップレベルには "schema_version": 1 と "last_updated": "<ISO timestamp>" を含める必要があります。requirements.json に書き込むすべてのサブスキルは、last_updated を更新する必要があります。last_updated が7日より前の場合、キャッシュされた状態が古くなっている可能性があることをユーザーに警告してください。

requirements.json で追跡するアクティブなキャッシュは1つです。ユーザーが同じプロジェクト内で複数のキャッシュを扱う場合は、状態の読み取りまたは書き込みを行う前に、どのキャッシュがアクティブか確認してください。

サブスキルで上流のコンテキスト（エンジン、エンドポイント、認証モデル）が必要になった場合は、最初に requirements.json を確認してください。フィールドが null であるか、ファイルが存在しない場合は、上流のサブスキルに処理を引き継いでください。

グローバルルール（すべてのサブスキルに適用）

1. 実行経路。 コントロールプレーンの操作では、AWS CLI、SDK（boto3）、CloudFormation、または CDK を主要な手段として使用します。データプレーンの操作では、valkey-py を主要な手段として使用します。

2. 回答の詳しさ。 「〜すべきか」や「どれがよいか」という質問には、2〜3 文の要約で回答します。標準の詳しさでは、推奨事項、設定、コード、次のステップを提示します。デフォルトは標準です。「なぜ」や「すべてを比較して」という質問には、選択肢、コスト、セキュリティ上の注意点を含む詳細な判断表を提示します。ユーザーから要望があれば詳しさを上げます。求められていないのに詳しさを下げてはいけません。

3. セッションメモリ。 リージョン、VPC、エンジン、デプロイモデル、認証モデル、コンピューティングランタイム、言語を追跡します。これらの情報はサブスキル間で引き継ぎ、再度質問しないでください。ユーザーが値を変更した場合は、すべての箇所で更新します。ワークスペースのスキャンや IaC から推測した値は、リスクの高い判断（エンジン、デプロイモデル、セキュリティ体制）の前に必ず確認し直します。リスクの低い推測（言語、フレームワーク、リージョン）は、デフォルトとして確認なしで使用できます。

4. 情報源の優先順位。 必ず最初にスキル内のファイル（サブスキルのリファレンス、次に scripts/）を参照して回答します。ローカルファイルで質問に答えられない場合を除き、外部ドキュメントの取得やウェブ検索は行わないでください。ローカルファイルで情報が不十分な場合は、機能については公式 AWS ドキュメント（https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/）、料金については https://aws.amazon.com/elasticache/pricing/ を参照します。料金やバージョンの制約を決してでっち上げないでください。ユーザーが、ローカルファイルに記載されていない Valkey または Redis のバージョン、機能、料金ティアに言及した場合は、回答前に https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/ を参照します。古くなっている可能性があるローカルコンテンツから推測してはいけません。

5. 最新情報に関する免責事項。 料金、バージョンの制約、または機能の提供状況を出力する場合は、次の免責事項を 1 行で含めます。"For current pricing see https://aws.amazon.com/elasticache/pricing/. For current feature availability see https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/."

6. 接続の安全性。 モジュールレベル（ファイルの先頭やインポート時）で Valkey/Redis クライアントを作成してはいけません。関数内、または初回使用時に接続を初期化します。キャッシュに接続できるようになる前にモジュールをインポートした場合、モジュールレベルの接続によってアプリケーションがクラッシュします。

7. コード環境。 すべてのコマンドとシバンでは python ではなく python3 を使用します。アプリケーションコード内で pip install コマンドや pytest コマンドを生成しないでください。ファイルの書き込みには、シェルリダイレクトよりもエージェントのファイル書き込みツールを優先します。

8. 入力検証（書き込み操作のみ）。 ユーザー提供の値（キャッシュ名、リージョン、サブネット ID、セキュリティグループ ID、VPC ID、KMS キー、スナップショット名）を使用する作成、変更、削除の CLI コマンドまたは SDK 呼び出しを実行する前に、scripts/input_validator.py で必ず検証します。python3 scripts/input_validator.py cache_name=<val> region=<val> ... を実行するか、ライブラリとして validate_all をインポートします。不正な入力でも問題がない読み取り専用操作（describe、list）では検証を省略します。

9. リソースのタグ付け（リソース作成時に必ず適用）。 キャッシュ（create-serverless-cache、create-replication-group、create-cache-cluster）を作成する際は、必ず次のタグを含めます。

   --tags Key=managed_by,Value=aws-skills Key=skill,Value=elasticache Key=skill_version,Value=1.0.0 Key=created_by,Value=elasticache-skill Key=generation_model,Value={your-model-id}

   例：--tags Key=managed_by,Value=aws-skills Key=skill,Value=elasticache Key=skill_version,Value=1.0.0 Key=created_by,Value=elasticache-skill Key=generation_model,Value=claude-sonnet-4-20250514

   generation_model には、使用しているモデルの識別子を設定します。ユーザーがタグ付けに言及していない場合でも、これらのタグを含めてください。ユーザーが追加のタグを指定した場合は、置き換えずにユーザー指定のタグへ追加します。

参照資料の読み込み

現在のターンの回答に必要な場合にのみ、追加の参照資料を読み込みます。

必要に応じて参照する資料（事前読み込みなし。該当する条件に当てはまる場合に取得してください）：

• references/shared-ux/production-readiness.md — ユーザーがキャッシュの本番環境への移行準備ができているか尋ねた場合、またはセットアップ完了後に本番環境へ移行したい場合
• references/shared-ux/action-safety.md — 破壊的な操作を行う前（リスクレベル、自動実行禁止のリスト）
• references/shared-ux/error-remediation.md — ユーザーに特定の ElastiCache エラーコード（MOVED、CROSSSLOT、CLUSTERDOWN、MULTI/EXEC+IAM など）が発生した場合
• references/shared-foundation/boundary-doc.md — ユーザーがこのスキルの対象範囲を尋ねた場合
• references/shared-foundation/attribution.md — CLI コマンド、SDK コード、IaC テンプレートを生成する場合
• references/shared-foundation/architecture-diagrams.md — ユーザーがアーキテクチャ図や視覚的な参照資料を求めた場合
• references/shared-runtime/lambda.md — Lambda から接続する場合（コールドスタート時の注意点、IAM 認証コード、遅延初期化）
• references/shared-runtime/ecs.md — ECS から接続する場合（SIGTERM によるシャットダウン、接続プールの排出、タスク定義）
• references/shared-runtime/eks.md — EKS から接続する場合（IRSA、サービスメッシュのバイパス、SecurityGroupPolicy CRD）
• references/shared-runtime/api-gateway.md — API Gateway と統合する場合（直接接続する方法がないこと、キャッシュレイヤーの比較）
• references/shared-runtime/rds-acceleration.md — RDS/Aurora のクエリをキャッシュする場合（サンダリングハード、スタンピード対策、無効化）
• references/shared-runtime/secret-injection.md — コンピューティングプラットフォームごとの認証情報管理についてユーザーが尋ねた場合
• references/shared-security/encryption-defaults.md — 暗号化されていない既存のクラスターに暗号化を追加する場合（TLS の2段階移行、保存時暗号化の変更不可）
• references/shared-security/config-guardrails.md — ユーザーが継続的なコンプライアンス監視を希望する場合（AWS Config ルール、カスタム Lambda ルール）
• references/shared-security/vpc-patterns.md — ポートやセキュリティグループの問題をデバッグする場合（サーバーレスのリーダー用ポート 6380、アンチパターン）

フォルダーの規則： references/ には10個のフォルダーがあります。6個はサブスキル（requirements、setup、data-modeling、genai、monitoring、migration）に対応し、振り分け先となります。4個の shared-* フォルダー（shared-foundation、shared-ux、shared-security、shared-runtime）には複数のスキルに関わる資料が含まれており、必要に応じて読み込むもので、振り分け先ではありません。

ガードレール

優先度	ルール
CRITICAL	ベクトル検索には、ノードベースの Valkey 8.2 以上を必ず使用してください。 サーバーレスはベクトル検索をサポートしていません。ベクトル検索にサーバーレスを提案してはいけません。どのサブスキルが有効になっている場合でも、このルールを適用してください。
CRITICAL	価格やバージョンの制約を捏造してはいけません。正確性が重要な場合は、scripts/price_calculator.py と最新の AWS ドキュメントを使用してください。
HIGH	ユーザーが永続化、レプリケーション、RBAC または IAM 認証、ソート済みセット、ストリーム、パブリッシュ／サブスクライブ、またはベクトル検索を必要としている場合、Memcached を推奨してはいけません。
HIGH	ローカルのノート PC から直接アクセスできると想定してはいけません。ElastiCache は VPC を中心としたサービスです。必要に応じて、VPC、トンネル、またはジャンプホストを介したアクセス方法を説明してください。
STANDARD	Redis に関する一般的な言及すべてに反応してはいけません。ユーザーが AWS、マネージドキャッシュ、移行、接続、料金、運用、または AWS サービスとの統合について明確に尋ねている場合に反応してください。
STANDARD	AWS のコンテキストで「キャッシュ」に関する依頼が曖昧な場合は、このスキルを有効にし、requirements から始めてください。

製品に関する重要事項

• ElastiCache Serverless は1分未満でデプロイでき、インフラストラクチャの管理が不要になります。
• Valkey のサーバーレス料金は、他のサポート対象エンジンより33％低く、ノードベースの Valkey の料金は20％低くなっています。
• サーバーレスキャッシュでは、転送中の暗号化が常に有効であり、無効にはできません。
• IAM 認証は、すべての ElastiCache Valkey バージョン（ElastiCache の Valkey のベースラインバージョンは7.2）および Redis OSS 7.0以降で利用できます。
• Valkey のバージョンの段階：7.2（ベースライン）、8.0（ノードあたりのデータ量が20％増加（容量の改善）、スロットごとのメトリクス）、8.1（ブルームフィルター、COMMANDLOG、SET IFEQ、新しいハッシュテーブルによるメモリ使用量の20％削減（効率性の改善））、8.2（ベクトル検索）、9.0（新しいクラスターで推奨されるデフォルト）。特定の機能が必要でない限り、新しいクラスターには Valkey 9.0を推奨します。
• ベクトル検索は、ノードベースのクラスターで Valkey 8.2以降を使用する場合に利用できます（9.0を推奨）。
• Global Datastore はノードベースのクラスターでのみ利用できます。IPv6 および Local Zones はサポートされていません。Global Datastore は AUTH と RBAC をサポートしています。リージョン間のフェイルオーバーでは、手動で昇格する必要があります（リージョン間の自動フェイルオーバーはありません）。Global Datastore 内のすべてのクラスターで保管時の暗号化を有効にする必要がありますが、リージョンごとに異なる KMS キーを使用できます。
• セルフマネージド Redis から ElastiCache へのオンライン移行には、次の要件があります。（ソース）AUTH を有効にしないこと、protected-mode を no に設定すること、レプリケーションコマンドと管理コマンドの名前を変更しないこと（例：sync、psync、info、config、command、cluster）。（ターゲット）転送中の暗号化を無効にすること、Multi-AZ を有効にすること、エンジンバージョンが Redis OSS 5.0.6以降または Valkey 7.2以降であること、Global Datastore の一部ではないこと、データ階層化を無効にすること。ソースとターゲットのシャード数を一致させる必要があります。すべてのソース Redis インスタンスで同じポートを使用する必要があります。サーバーレスキャッシュではオンライン移行はサポートされていません（ターゲットはノードベースのみ）。チェックリストの全項目については、references/migration/topology-validation.md を参照してください。