AWS Secrets Manager、Azure Key Vault、GCP Secret Manager：2026年 深掘り比較

2026年に適切なクラウド秘密管理ソリューションを選択するには、機能チェックリスト以上の考慮が必要です。直接的なコストへの影響、運用オーバーヘッド、特定のクラウドエコシステム内での統合の深さ、およびコンプライアンス体制が関係します。この分析では、マーケティング表現を排除し、AWS Secrets Manager（特定のユースケース向けのParameter Storeを含む）、Azure Key Vault（Standard、Premium、Managed HSMティアを網羅）、Google Secret Manager（Cloud KMSとの相互運用性を含む）の詳細な情報を提供します。技術的な差別化とエンタープライズユースケースへの戦略的適合性に焦点を当てます。

主要機能と設計パラダイム

AWS Secrets Manager (ASM) は、自動化と幅広い統合を優先します。その主要な機能は、シークレットを保存、取得、ローテーションすることです。シークレットは、データベースの認証情報からAPIキーまで、あらゆるものになり得ます。ASMは、RDS、Redshift、DocumentDBと直接統合し、ネイティブなローテーションをサポートします。KMSが保存時のシークレットを暗号化する一方で、ASMはそのライフサイクルを管理します。シークレットのために見過ごされがちなAWS Parameter Storeは、より低感度の小さなシークレット（最大10KB）を低コストで保存でき、オプションのKMS暗号化を備えた階層的な構成ストアとして機能します。重要な区別は、Parameter Storeが構成用であり、Secrets Managerが認証情報用であることです。

Azure Key Vault (AKV) は、シークレット、キー、および証明書のための一元的なサービスです。この統合により、PKIを多用する環境やハードウェアバックのキー保存が必要な環境での管理オーバーヘッドが削減されます。AKVは、Standard（ソフトウェアバックのキー）とPremium（FIPS 104-2 Level 2検証済みHSMバックのキー）を提供します。Azure Managed HSMは、専用のシングルテナントFIPS 140-2 Level 3検証済みHSMサービスであり、インポート可能なキーを含む重要な暗号化操作に対して、より高い保証レベルを提供します。これらのティア間のアーキテクチャの選択は、セキュリティ体制とコストに直接影響します。

Google Secret Manager (GSM) は、最初からシンプルさとグローバルなアクセシビリティを追求して設計されています。シークレットはグローバルリソースであり、自動的にバージョン管理され、Cloud IAMと密接に統合されています。GSMの主要な暗号化はCloud KMSによって処理され、顧客管理暗号キー (CMEK) および顧客提供暗号キー (CSEK) をサポートしています。AKVとは異なり、GSMは証明書を本質的に管理せず、シークレットとキーのストレージに純粋に焦点を当てています。各シークレットごとのアクセス制御と、その運用における基本的な側面であるシークレットのバージョン管理に重点を置くことで、差別化を図っています。

セキュリティ機能：HSM、暗号化、ゼロトラスト

これら3つのサービスはすべて、保存時および転送時（TLS 1.2/1.3）の暗号化を提供します。違いは、暗号化操作のバックアップとキーの出所です。AWS Secrets ManagerはAWS KMSに依存しており、FIPS 140-2 Level 2検証済みのハードウェアセキュリティモジュールを使用しています。ASMのシークレットは、KMSカスタマーマスターキー（CMK）から派生したデータキーを使用して暗号化されます。明示的に言えば、ASMはシークレット管理プレーン内で直接FIPS 140-2 Level 3の提供を行っていませんが、KMS自体はそのレベルの保証でプロビジョニングできます。

Azure Key Vault Premiumは、キーにnCipher（現Entrust）HSMを使用し、FIPS 140-2 Level 2検証を提供します。AKV内で提供されるマネージドサービスであるAzure Managed HSMは、専用のThales Luna Network HSMを提供し、FIPS 140-2 Level 3検証を実現します。これは、強力な暗号化分離とハードウェアバックのキーの起源の証明を必要とする高度に規制された業界にとって大きな利点です。参考に、シングルテナントのManaged HSMインスタンスは、トランザクション費用に加えて月額約5000ドルから始まります。

Google Secret Managerは、すべての暗号化操作にCloud KMSを使用します。Cloud KMS自体は、ソフトウェアバックのキーにFIPS 140-2 Level 1検証を、特定のキーリング構成を通じて利用可能なハードウェアバックのキーにFIPS 140-2 Level 2を提供します。GSMのシークレットはエンベロープ暗号化スキームで暗号化され、データ暗号化キー（DEK）がシークレットを暗号化し、Cloud KMSからのキー暗号化キー（KEK）がDEKを暗号化します。FIPS 140-2 Level 3を必要とする顧客にとって、明示的なオプションはGSM内に直接存在するのではなく、Google Cloudと統合された専用HSMまたはカスタムキー管理システムに関連する別の製品に依存しており、複雑さが増します。

IAMの粒度と監査可能性

Identity and Access Management (IAM) は非常に重要です。AWS Secrets ManagerはAWS IAMポリシーとシークレットレベルで統合されています。例えば、リソースベースポリシーまたはアイデンティティベースポリシーを介して、個々のシークレットに対する特定のプリンシパルまたはロールに対してきめ細かなアクセス許可（例：secretsmanager:GetSecretValue、secretsmanager:RotateSecret）を定義できます。CloudTrailはすべてのAPI呼び出しをキャプチャし、シークレットアクセスと変更の完全な監査証跡を提供します。このきめ細かな制御はAWSの強力な点であり、きめ細かなZero Trustの実装を可能にします。

Azure Key Vaultは、VaultレベルでAzure Role-Based Access Control (RBAC) を使用し、レガシーなアクセスポリシーモデルも使用します（RBACが推奨されます）。RBACは、事前定義されたロール（例：Key Vault Reader、Key Vault Secrets Officer）またはカスタムロールを使用して、さまざまなスコープ（管理グループ、サブスクリプション、リソースグループ、個々のVault）でロールの割り当てを許可します。個々のシークレットアクセスの場合、RBACはシークレットに直接適用できます。Azure Monitor Logs（診断設定経由）は、シークレットアクセスを含むすべてのキーVault操作をキャプチャし、SIEM向けのAzure Sentinelとの統合をサポートします。RBACへの移行により、AKVのIAM管理が簡素化されました。

Google Secret ManagerはGoogle Cloud IAMを広く活用しています。パーミッションは、プリミティブロール（例：roles/secretmanager.secretAccessor、roles/secretmanager.secretVersionManager）またはカスタムロールを使用して、プロジェクト、フォルダ、または個々のシークレットレベルで定義されます。このシークレットごとのバージョン管理機能は、IAMと組み合わせることで、どのプリンシパルがシークレットの特定のバージョンにアクセスできるかを正確に制御できます。Cloud Audit Logs（管理アクティビティ、データアクセス）はすべてのシークレット管理操作をキャプチャし、コンプライアンスとフォレンジックのための詳細で不変のログを提供します。GoogleのIAM条件機能を使用すると、IPソースや時刻などの属性に基づいてさらにきめ細かな制御が可能になります。

シークレットローテーションと統合エコシステム

AWS Secrets Managerは、RDS、Redshift、DocumentDB、およびその他のサービス向けに、Lambda関数を介した組み込みのローテーション機能を提供します。これは間違いなく、その最も強力な実用的な機能です。他のサービス向けのカスタムローテーションは、Python Lambda関数で実現できます。Kubernetesの場合、CSIドライバー用のAWS Secrets & Configuration Providerを使用すると、シークレットをPodに直接マウントできます。TerraformのようなIaCツールは、シークレットの作成、取得、ローテーション構成のためにASMをサポートしています。接続ごとに異なる認証情報を必要とするデータベースの動的シークレットは、ASMのローテーションフックまたはカスタムLambda関数を活用して一般的に実装されます。

Azure Key Vaultには証明書のローテーション機能がありますが、任意の認証情報に対するネイティブな自動シークレットローテーションはありません。データベースのパスワードの場合、通常はカスタムのAzure Functionsを記述するか、CI/CDパイプラインと統合してシークレットを定期的に更新する必要があります。AKVは、シークレットをマウントするためにAzure Kubernetes Service (AKS) CSIドライバーと統合します。TerraformはAKVのVault、キー、シークレットを管理するための広範なサポートを持っています。動的シークレットの生成はAKVのネイティブ機能では明確ではなく、通常は利用側のアプリケーションまたは外部の認証情報仲介サービスによって処理されます。

Google Secret Managerはシークレットのローテーションスケジュール設定をサポートしており、これによってPub/Subメッセージがトリガーされます。このメッセージは、実際の認証情報更新とシークレットバージョンローテーションを実行するCloud Functionを呼び出すことができます。この設計は柔軟ですが、ほとんどのバックエンドにはカスタムコードが必要です。Kubernetesの場合、Google Secret Manager CSIドライバーを使用すると、シークレットをPod内のファイルとして公開できます。TerraformはGSMシークレットを効果的に管理し、Cloud KMSとの統合は強力なキー制御オプションを提供します。動的シークレットも可能ですが、これもローテーションイベントによってトリガーされるCloud Functionsに依存します。

料金比較（2026年概算リスト価格）

料金モデルは重要であり、多くの場合複雑で、シークレットごとのストレージとAPI呼び出しごとの料金が含まれます。これらの数字は例示であり、地域差やエンタープライズ割引の対象となります。

機能	AWS Secrets Manager	Azure Key Vault (Premium)	GCP Secret Manager
ストレージ（シークレットごと/月、最初の10k）	$0.40	$3.00 (キー、シークレット、証明書)	$0.06
API呼び出し（10kオペレーションあたり）	$0.05	$0.03 (シークレット＆キー)	$0.03
必須ローテーション費用	$0.05/シークレット/月 (有効にした場合)	N/A (カスタムが必要)	N/A (Pub/Sub + Cloud Functionで別途費用)
Managed HSM (オプション)	N/A 直接	約$5000/月 専用HSMインスタンス + 運用費	N/A 直接
例：1000シークレット、1M API呼び出し/月	$400 (ストレージ) + $500 (API) = $900 (+ ローテーションで最大$50)	$3000 (ストレージ) + $300 (API) = $3300	$60 (ストレージ) + $300 (API) = $360
例：100シークレット、100k API呼び出し/月	$40 (ストレージ) + $5 (API) = $45	$300 (ストレージ) + $3 (API) = $303	$6 (ストレージ) + $3 (API) = $9

ストレージ費用の大きな違いに注目してください。Azure Key Vaultのプレミアムティアは、HSMの優位性を提供しますが、シークレットあたりの保存費用が大幅に高くなります。GCP Secret Managerは明らかに最も低いストレージ費用であり、適度なAPIトラフィックで多数のシークレットを扱う場合に魅力的です。AWSは、ストレージ費用が吸収されると、API呼び出しごとの単価が比較的低いため、API呼び出し量が多い場合に競争力があります。

クロスリージョンと災害復旧に関する考慮事項

AWS Secrets Managerはリージョナルサービスです。災害復旧やマルチリージョン展開の場合、シークレットはリージョン間でレプリケートされる必要があります。CloudWatch EventsによってトリガーされるLambda関数を使用してシークレットの変更時にこのレプリケーションを自動化したり、各リージョンで個々のシークレットを定義したりできます。これにより、整合性を確保し、フェイルオーバー時のスプリットブレンシナリオを防ぐためのアーキテクチャ計画が必要になります。

Azure Key Vaultもリージョナルサービスです。シークレットは耐久性のために同一リージョン内で地理的にレプリケートされますが、クロスリージョンレプリケーションには、Vaultとシークレットを複数のリージョンに手動またはスクリプトでデプロイする必要があります。これには、Azure Resource Manager (ARM) テンプレート、Terraform、またはAzure CLIスクリプトを使用してシークレットの同期を確保することが含まれる場合があります。Managed HSMは特定のリージョンにデプロイされ、グローバルに自動クロスリージョンレプリケーションを提供しないため、DRには手動構成が必要です。

Google Secret Managerは、グローバルリソースとしてシークレットを提供します。シークレットを作成すると、それはグローバルにアクセス可能になり、そのバージョンは複数のGoogle Cloudリージョンに保存されます。これにより、シークレット管理の観点からクロスリージョン災害復旧が大幅に簡素化されます。データプレーンはグローバルに利用可能で一貫しており、シークレットアクセスに関するDR計画の負担の多くが解消されますが、アクセスポリシーは一部のケースでリージョン固有のままです。

設定スニペットとIaCのベストプラクティス

Infrastructure as Code (IaC) を使用することは、シークレットの管理にとって非常に重要です。以下は、各プラットフォームでシークレットを作成するためのTerraformの例です。

# AWS Secrets Manager シークレット
resource "aws_secretsmanager_secret" "db_credentials" {
  name                    = "production/app/db_credentials"
  description             = "主要アプリケーションのデータベース認証情報。"
  recovery_window_in_days = 7
  rotation_lambda_arn     = aws_lambda_function.db_rotation_function.arn
  rotation_rules {
    automatically_after_days = 90
  }
}

resource "aws_secretsmanager_secret_version" "db_credentials_version" {
  secret_id     = aws_secretsmanager_secret.db_credentials.id
  secret_string = jsonencode({
    username = "admin"
    password = "super_secret_pw"
  })
}

# Azure Key Vault シークレット
resource "azurerm_key_vault" "main" {
  name                          = "mykv-2026-prod"
  location                      = "eastus"
  resource_group_name           = azurerm_resource_group.main.name
  sku_name                      = "premium"
  tenant_id                     = data.azurerm_client_config.current.tenant_id
  enabled_for_disk_encryption   = true
  purge_protection_enabled      = true
  soft_delete_retention_days    = 90
}

resource "azurerm_key_vault_secret" "db_password" {
  name         = "db-password"
  value        = "super_secret_pw_az"
  key_vault_id = azurerm_key_vault.main.id
  content_type = "application/text"
}

# GCP Secret Manager シークレット
resource "google_secret_manager_secret" "api_key_prod" {
  secret_id = "api-key-prod"
  project   = var.gcp_project_id
  replication {
    automatic = true
  }
  rotation {
    rotation_period = "2592000s" # 30日
  }
}

resource "google_secret_manager_secret_version" "api_key_prod_version" {
  secret      = google_secret_manager_secret.api_key_prod.id
  secret_data = "gcp_super_secret_key"
}

HashiCorp Vaultのようなシークレットバックエンドを使用しない場合、IaCステートファイル内のsecret_stringやvalueのような機密性の高い値を暗号化することが重要です。この例では、簡潔にするためにsuper_secret_pwをハードコードしていますが、実際には、環境変数やデプロイ時にそれらを挿入する別のシークレット管理ツール、または初期シードのためにクラウドプロバイダーのシークレットストレージ自体を活用するなど、安全な方法で渡されるべきです。

結論：選択のシナリオ

AWS Secrets Managerを選択する場合： AWSに深く投資しており、特にRDS、Redshift、DocumentDBを使用し、ネイティブな自動ローテーションを重視する場合。API呼び出しの料金は、ストレージ費用が吸収されると良好にスケールします。認証情報と構成（Parameter Storeを使用）の両方に対応する包括的で統合されたソリューションが必要な場合、AWSは強力なエコシステムを提供します。Lambda駆動の自動化がコア戦略であるクラウドネイティブなAWSアプリケーションにこれを検討してください。

Azure Key Vaultを選択する場合： 組織が厳格なコンプライアンス要件（例：Managed HSMによるFIPS 140-2 Level 3）、大きなPKIフットプリント、またはキー、シークレット、証明書のための一元的なストアを必要とする場合。Azure Active Directory（現Entra ID）およびAzureサービスを大いに活用しているAzure中心の組織は、AKVの統合が一貫していることを感じるでしょう。AKVは、キーがオンプレミスHSMから発生し、Azureに安全にインポートされるハイブリッドシナリオに最適です。

Google Secret Managerを選択する場合： 多数のシークレットに対する費用対効果が最優先される場合、または自動バージョン管理機能を備えたグローバルに分散されたシンプルなシークレット管理システムを優先する場合。GSMは、GKE (Google Kubernetes Engine) 上のマイクロサービスアーキテクチャやGCPエコシステム内のサーバーレス関数 (Cloud Functions, Cloud Run) に最適です。その定額で低いストレージ費用は、アクセス頻度は低いが高いボリュームのシークレットにとって魅力的です。

結局のところ、最適な選択は、既存のクラウド戦略、規制要件、運用モデル、および特定の予算制約に合致するものです。時期尚早の最適化は避け、まずはクラウドプロバイダーのネイティブな提供物から始め、必要に応じて要件をスケールアップしてください。

関連資料

• FortiGate 7.6 NGFW設計：基本を超えて
• Palo Alto Networks Prisma Cloud CNAPPレポート2026
• 高トラフィックアプリケーション向けAWS CloudFront WAF最適化2026
• Azure Sentinel SIEM統合のベストプラクティス
• GCP Zero Trust: BeyondCorp実装戦略