本記事の内容は私的に実施したものであり、個人の感想です。如何なる組織・製品を代表するものでもありません。

Summary

IBM BobにAzureおよびAWSの公式ドキュメントMCPサーバーを連携することで、クラウド設計の質問・壁打ちの精度が向上した
MCPサーバーは自前で構築する必要はなく、Microsoft・AWSが公開しているエンドポイントをそのまま設定ファイルに記述するだけで利用可能である
IBM Bobは、タスクをサブタスクに自動分割し、人による承認を挟みながらステップバイステップで調査を進める「エージェント的な動作」が可能であり、これがWeb検索ベースのAIアシスタントにはない特徴である

やらないこと

MCPサーバー自体の内部実装や仕様の詳細解説
IBM Bobの導入・セットアップ手順の詳細説明
Azure・AWS各サービスそのものの機能詳細比較

本記事における課題

クラウド設計時の「ちょっと聞きたい」が意外と重い

クラウドアーキテクチャを設計・構築していると、「AWSではこうやっていたが、Azureで同等のサービスはどれか？」「このサービスの自動更新の挙動はどうだったか？」といった、ドキュメントを開けば答えが載っているはずだが、探すのが面倒な問いに何度もぶつかる。

こういった疑問をAIアシスタントに投げる場面も増えてきたが、一般的なWeb検索ベースの回答には以下のような課題を感じていた。

情報の鮮度・信頼性が不均一：ブログや非公式の記事も混入し、古い情報や誤りが含まれる場合がある
一次情報源が曖昧：「どのドキュメントを参照して答えたのか」が見えにくく、回答の根拠を検証しづらい
調査の進捗が見えない：複合的な質問に対してAIが何をどの順番で調べているか分からず、途中で軌道修正できない

特に最後の点は、複雑な設計の壁打ちをAIに依頼する際に顕著な問題となる。質問を投げて結果を待つだけでは、的外れな方向に調査が進んでいても気づけないし、途中で「やはりこっちも調べてほしい」と追加指示を入れるタイミングもない。

やったこと

IBM BobにMCPサーバーを設定する

MCPとは何か

MCP（Model Context Protocol）は、AIアシスタントが外部ツールやデータソースと連携するためのプロトコルである。MCPサーバーをAIクライアントに接続することで、AIは特定のデータソースをツールとして呼び出しながら回答を生成できるようになる。

なお、今回利用したMicrosoftとAWSは、それぞれ公式ドキュメントへのアクセスを提供するMCPサーバーのエンドポイントを一般公開しており、手元に環境構築する必要がなく、気軽に試すことができる。

設定方法

IBM Bobを起動し、右上の歯車のアイコンをクリック。

MCPタブから「グローバルMCP」の右横の「開く」をクリック。

エディターでMCP設定ファイルに以下を記述するだけで、Azure（Microsoft Learn）およびAWS公式ドキュメントをツールとして利用できる。

{
    "mcpServers": {
        "msdocsmicrosoft.docs.mcp": {
            "type": "streamable-http",
            "url": "https://learn.microsoft.com/api/mcp",
            "alwaysAllow": [
                "microsoft_docs_search",
                "microsoft_docs_fetch"
            ]
        },
        "aws-knowledge-mcp-server": {
            "url": "https://knowledge-mcp.global.api.aws",
            "type": "streamable-http",
            "alwaysAllow": [
                "aws___search_documentation",
                "aws___read_documentation"
            ]
        }
    }
}

alwaysAllow に指定したツール名（microsoft_docs_search、aws___search_documentation など）は、Bob側で「常に許可」扱いとなり、質問のたびに許可を求めるダイアログが出ないようになる。作業の流れを止めずに使えるため、設定しておくことを推奨する。

実際の利用シーン：サブタスク分割＋人による承認でステップバイステップに調査を進める

今回投げたプロンプト

今回試したのは以下のプロンプトである。

AWS ACMのように証明書を発行・更新できるサービスはAzureにはある？
また、AWSの場合ALBに証明書をアタッチできるけど、Azureではそれが可能？
それぞれの公式ドキュメントをMCPを使って精査し、詳細かつ具体的なAWSとAzureの違いを
教えてほしい。事前にどういった調査を行うのか、サブタスクに分割してください。

ポイントは末尾の一文、 「事前にどういった調査を行うのか、サブタスクに分割してください」 である。これを加えることで、Bobは調査計画を明示した上で、ステップごとに人の承認を取りながら作業を進めるモードで動作する。

BobならではのTodo管理＋承認フロー

プロンプトを受け取ったBobはまず、以下の6つのサブタスクに調査を分割し、Todoリストとして提示した。

調査計画の策定と全体像の把握
AWS ACMの機能調査（証明書発行・更新・管理機能）
Azure証明書サービスの特定と機能調査
AWSのALBへの証明書アタッチ方法の調査
Azureのロードバランサーへの証明書アタッチ方法の調査
AWS vs Azureの詳細比較レポート作成

このTodoリストはUIに可視化され、各タスクの完了状態がリアルタイムで更新されていく。

また、各サブタスクの完了ごとに「承認」「拒否」ボタンが表示され、人間が結果を確認してから次のステップへ進むという設計になっている。

「サブタスク完了！結果を確認し、修正や次のステップを提案できます。問題なければ、親タスクに結果を返すために確認してください。」

このように、 調査の途中経過を人間に見せ、必要であれば追加指示や軌道修正を受け付ける 構造になっている。

例えばサブタスク2（AWS ACMの機能調査）が完了した時点で、「やはりPrivate CAの制限事項も詳しく調べてほしい」と追加指示を入れたり、「この方向は不要、次に進んでよい」と承認したりすることができる。途中で方針が変わりがちな設計の壁打ちでは、この「中断・修正できる構造」を活用できそうに思う。

調査の深さ：一次情報を網羅した詳細レポートが生成される

これはBobではなく、一般にMCPを利用することによるメリットと思われるが、公式ドキュメントをMCPで参照した上で生成された詳細な技術情報である。

例えばAWS ACMの調査では、

証明書タイプはSSL/TLSのみ（コード署名・メール暗号化は不可）
ED25519鍵はApplication Load Balancerで非サポート
国際化ドメイン名（IDN）はUnicode文字不可、ASCIIエンコードされた文字は可
スタンドアロンWebサーバーへのACM利用は非推奨
レート制限超過時はThrottlingExceptionエラーが返る

といった、ドキュメントをじっくり読まなければ気づかない制約事項まで拾い上げてくれた。

実際に生成されたレポート

生成されたレポートを以下に示す。

本レポート内容の真偽は全て確認していないため、参考程度にご確認ください。

# AWS ACM vs Azure証明書管理サービス 詳細比較レポート

## エグゼクティブサマリー

### 概要

AWS Certificate Manager (ACM)とAzure証明書管理サービスは、それぞれのクラウドプラットフォームにおいてSSL/TLS証明書のライフサイクル管理を自動化するサービスです。両サービスとも証明書の発行、更新、デプロイを簡素化しますが、アーキテクチャ、料金体系、統合方法において重要な違いがあります。

### 主要な違い

| 観点 | AWS ACM | Azure証明書管理 |
|------|---------|-----------------|
| **サービス構成** | 単一の統合サービス | 複数サービスの組み合わせ（Key Vault、App Service証明書、マネージド証明書） |
| **無料証明書** | パブリック証明書（エクスポート不可） | App Serviceマネージド証明書のみ |
| **有料証明書** | エクスポート可能証明書（$7/$79） | App Service証明書（$75.99/$299.99） |
| **証明書認証局** | Amazon Trust Services (ATS) | DigiCert/GlobalSign（Key Vault）、GoDaddy（App Service） |
| **自動更新開始** | 有効期限の60日前 | 有効期限の45日前 |
| **更新チェック頻度** | 毎日 | 4時間ごと（Application Gateway統合時） |
| **証明書有効期間** | 198日（今後短縮予定） | 1年または2年（CAによる） |
| **証明書数制限** | 2,500証明書/リージョン | 制限なし（Key Vault）、トランザクション制限あり |

### 推奨ユースケース

**AWS ACMを選択すべき場合:**
- AWS環境に完全に統合されたシンプルなソリューションが必要
- 無料のパブリック証明書で十分（エクスポート不要）
- ALB/CloudFront/API Gatewayとの緊密な統合が必要
- 証明書管理の運用負荷を最小化したい

**Azure証明書管理を選択すべき場合:**
- 柔軟な証明書管理と中央集権的な管理が必要（Key Vault）
- 複数のAzureサービス間で証明書を共有したい
- エンタープライズレベルのセキュリティとアクセス制御が必要
- 証明書のエクスポートと外部利用が必要

---

## 詳細機能比較表

### 証明書発行・管理

| 機能 | AWS ACM | Azure証明書管理 |
|------|---------|-----------------|
| **パブリック証明書発行** | ✅ 無料（統合サービス利用時） | ✅ 無料（App Serviceマネージド証明書）<br>✅ 有料（App Service証明書、Key Vault統合） |
| **プライベート証明書** | ✅ AWS Private CA経由（別料金） | ✅ Key Vault経由（統合CA） |
| **証明書インポート** | ✅ サポート | ✅ サポート（Key Vault、App Service） |
| **証明書エクスポート** | ✅ エクスポート可能証明書のみ（有料） | ✅ Key Vaultから可能 |
| **ワイルドカード証明書** | ✅ サポート | ✅ サポート（App Service証明書、Key Vault）<br>❌ マネージド証明書は非対応 |
| **SAN証明書** | ✅ 最大10ドメイン（拡張可能、最大100） | ✅ サポート |
| **検証方法** | DNS検証（推奨）、Email検証 | DNS検証、HTTP検証 |
| **証明書認証局** | Amazon Trust Services (ATS) | DigiCert、GlobalSign、GoDaddy |

### 自動更新機能

| 機能 | AWS ACM | Azure証明書管理 |
|------|---------|-----------------|
| **自動更新サポート** | ✅ DNS検証の場合 | ✅ 統合サービス利用時 |
| **更新開始タイミング** | 有効期限の60日前 | 有効期限の45日前 |
| **更新チェック頻度** | 毎日 | 4時間ごと（Application Gateway）<br>自動（App Service） |
| **更新条件** | ・AWSサービスと関連付け<br>・DNS検証設定維持<br>・ドメイン所有権維持 | ・Key Vault統合維持<br>・DNS/HTTP検証設定維持<br>・適切なアクセス権限 |
| **更新失敗時の通知** | ✅ CloudWatch Events経由 | ✅ Event Grid経由 |
| **手動更新トリガー** | ❌ 自動のみ | ✅ Application Gateway設定変更時に即座にチェック |

### ロードバランサー統合

| 機能 | AWS ACM | Azure証明書管理 |
|------|---------|-----------------|
| **L7ロードバランサー** | Application Load Balancer (ALB) | Application Gateway |
| **L4ロードバランサー** | Network Load Balancer (NLB) | ❌ Azure Load Balancerは証明書非対応 |
| **証明書アタッチ方法** | ACM証明書ARN参照 | Key Vault証明書参照またはアップロード |
| **SNIサポート** | ✅ 複数証明書対応 | ✅ 複数証明書対応 |
| **自動更新の動作** | 自動的にローテーション | 4時間ごとにポーリング、自動ローテーション |
| **証明書数制限** | リスナーあたり25証明書 | 制限なし（実質的） |
| **その他統合サービス** | CloudFront、API Gateway、Elastic Beanstalk | Front Door、App Service、API Management |

### 料金体系

| 項目 | AWS ACM | Azure証明書管理 |
|------|---------|-----------------|
| **パブリック証明書（統合利用）** | 無料 | 無料（App Serviceマネージド証明書のみ） |
| **エクスポート可能証明書** | ・標準: $7/月<br>・拡張検証(EV): $79/月 | ・標準: $75.99/年<br>・ワイルドカード: $299.99/年 |
| **プライベート証明書** | AWS Private CA料金<br>・CA: $400/月<br>・証明書: $0.75/枚 | Key Vault料金<br>・トランザクションベース<br>・証明書操作: 300回/10秒まで無料枠 |
| **Key Vault/証明書ストレージ** | 含まれる | ・Standard: トランザクションベース<br>・Premium: HSM保護、追加料金 |
| **更新料金** | 無料 | 無料（自動更新時） |

### 制限事項

| 項目 | AWS ACM | Azure証明書管理 |
|------|---------|-----------------|
| **証明書数** | 2,500証明書/リージョン | 制限なし（Key Vault）<br>1,000証明書/webspace（App Service） |
| **ドメイン数/証明書** | 10（デフォルト）、最大100 | 制限なし（実質的） |
| **証明書有効期間** | 198日（今後短縮予定） | 1年または2年（CAによる） |
| **リージョン制約** | リージョナルリソース<br>（CloudFrontは例外でグローバル） | リージョナルリソース<br>（Front Doorはグローバル） |
| **トランザクション制限** | 特になし | ・証明書作成/インポート: 300回/10秒<br>・その他操作: 4,000回/10秒 |
| **バックアップ制限** | N/A | 証明書バージョン500まで |

---

## ロードバランサー統合の詳細比較

### AWS ALB vs Azure Application Gateway

#### アーキテクチャの違い

```mermaid
graph TB
    subgraph AWS["AWS Architecture"]
        Client1[Client] -->|HTTPS| ALB[Application Load Balancer]
        ALB -->|証明書参照| ACM[AWS Certificate Manager]
        ALB -->|HTTP/HTTPS| Target1[Target Group]
        Target1 --> EC2_1[EC2 Instance]
        Target1 --> EC2_2[EC2 Instance]
    end
    
    subgraph Azure["Azure Architecture"]
        Client2[Client] -->|HTTPS| AppGW[Application Gateway]
        AppGW -->|証明書参照| KV[Key Vault]
        AppGW -->|HTTP/HTTPS| Backend[Backend Pool]
        Backend --> VM1[Virtual Machine]
        Backend --> VM2[Virtual Machine]
    end
```

#### 証明書アタッチ方法の比較

**AWS ALB:**

1. **ACM証明書の使用（推奨）**
   ```bash
   # AWS CLI例
   aws elbv2 create-listener \
     --load-balancer-arn arn:aws:elasticloadbalancing:region:account-id:loadbalancer/app/my-alb/1234567890 \
     --protocol HTTPS \
     --port 443 \
     --certificates CertificateArn=arn:aws:acm:region:account-id:certificate/certificate-id \
     --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-targets/1234567890
   ```

2. **特徴:**
   - ACM証明書ARNを直接参照
   - 証明書の自動更新は透過的
   - 複数証明書の追加（SNI）が容易
   - 証明書の物理的なファイル管理不要

**Azure Application Gateway:**

1. **Key Vault統合（推奨）**
   ```bash
   # Azure CLI例
   az network application-gateway ssl-cert create \
     --gateway-name myAppGateway \
     --resource-group myResourceGroup \
     --name myCertificate \
     --key-vault-secret-id "https://myvault.vault.azure.net/secrets/mycert/"
   ```

2. **証明書の直接アップロード**
   ```bash
   az network application-gateway ssl-cert create \
     --gateway-name myAppGateway \
     --resource-group myResourceGroup \
     --name myCertificate \
     --cert-file certificate.pfx \
     --cert-password "password"
   ```

3. **特徴:**
   - Key Vault参照またはPFXアップロード
   - Key Vault統合時は4時間ごとに更新チェック
   - Application Gateway設定変更時に即座にチェック
   - マネージドIDによるKey Vaultアクセス

### 自動更新の動作比較

#### AWS ACM + ALB

```mermaid
sequenceDiagram
    participant ACM as AWS ACM
    participant DNS as DNS Provider
    participant ALB as Application Load Balancer
    participant Client as Client
    
    Note over ACM: 有効期限60日前
    ACM->>DNS: DNS検証レコード確認
    DNS-->>ACM: 検証成功
    ACM->>ACM: 新証明書発行
    ACM->>ALB: 証明書自動更新
    Note over ALB: ダウンタイムなし
    Client->>ALB: HTTPS接続
    ALB-->>Client: 新証明書で応答
```

**特徴:**
- 完全自動、ユーザー介入不要
- DNS検証レコードが維持されている限り継続
- ALBは自動的に新証明書を使用
- ダウンタイムゼロ
- 更新失敗時はCloudWatch Eventsで通知

#### Azure Application Gateway + Key Vault

```mermaid
sequenceDiagram
    participant KV as Key Vault
    participant DNS as DNS Provider
    participant AppGW as Application Gateway
    participant Client as Client
    
    Note over KV: 有効期限45日前
    KV->>DNS: DNS検証確認
    DNS-->>KV: 検証成功
    KV->>KV: 新証明書バージョン作成
    Note over AppGW: 4時間ごとにポーリング
    AppGW->>KV: 新バージョン確認
    KV-->>AppGW: 新証明書バージョン
    AppGW->>AppGW: 証明書ローテーション
    Note over AppGW: ダウンタイムなし
    Client->>AppGW: HTTPS接続
    AppGW-->>Client: 新証明書で応答
```

**特徴:**
- 4時間ごとの自動ポーリング
- Application Gateway設定変更時に即座にチェック
- Key Vaultのシークレット識別子はバージョン指定なしを推奨
- マネージドIDによるアクセス制御
- Event Gridで更新イベント通知可能

### 複数証明書のサポート（SNI）

#### AWS ALB

**設定方法:**
```bash
# デフォルト証明書
aws elbv2 create-listener \
  --load-balancer-arn <alb-arn> \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=<default-cert-arn> \
  --default-actions Type=forward,TargetGroupArn=<target-group-arn>

# 追加証明書（SNI）
aws elbv2 add-listener-certificates \
  --listener-arn <listener-arn> \
  --certificates CertificateArn=<additional-cert-arn-1> \
                 CertificateArn=<additional-cert-arn-2>
```

**特徴:**
- リスナーあたり最大25証明書
- SNIによる自動証明書選択
- 証明書の追加・削除が動的に可能
- すべての証明書が自動更新対象

#### Azure Application Gateway

**設定方法:**
```bash
# 複数のHTTPSリスナーを作成
az network application-gateway http-listener create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name listener1 \
  --frontend-port 443 \
  --ssl-cert myCert1 \
  --host-name www.example1.com

az network application-gateway http-listener create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name listener2 \
  --frontend-port 443 \
  --ssl-cert myCert2 \
  --host-name www.example2.com
```

**特徴:**
- 証明書数に実質的な制限なし
- リスナーごとに証明書を指定
- SNIによる自動証明書選択
- Key Vault統合時はすべて自動更新

### L4ロードバランサーの違い

| 機能 | AWS NLB | Azure Load Balancer |
|------|---------|---------------------|
| **TLS終端** | ✅ サポート | ❌ 非対応 |
| **ACM/証明書統合** | ✅ ACM証明書使用可能 | ❌ 証明書機能なし |
| **ユースケース** | TLS終端が必要なL4負荷分散 | 純粋なL4負荷分散のみ |
| **代替案** | - | Application Gatewayを使用 |

**重要な違い:**
- AWS NLBはTLS終端をサポートし、ACM証明書を使用可能
- Azure Load BalancerはL4のみで証明書機能なし
- AzureでTLS終端が必要な場合はApplication Gatewayを使用

---

## ワークフロー比較

### 証明書の初期設定フロー

#### AWS ACM + ALB

```mermaid
flowchart TD
    Start([開始]) --> Request[ACMで証明書リクエスト]
    Request --> Validation{検証方法選択}
    Validation -->|DNS| DNS_Val[DNS検証レコード追加]
    Validation -->|Email| Email_Val[Email検証]
    DNS_Val --> Wait_DNS[検証完了待機]
    Email_Val --> Wait_Email[Email承認待機]
    Wait_DNS --> Issued[証明書発行]
    Wait_Email --> Issued
    Issued --> Attach[ALBリスナーに証明書アタッチ]
    Attach --> Test[HTTPS接続テスト]
    Test --> End([完了])
```

**手順詳細:**

1. **証明書リクエスト**
   ```bash
   aws acm request-certificate \
     --domain-name example.com \
     --subject-alternative-names *.example.com \
     --validation-method DNS
   ```

2. **DNS検証レコード追加**
   - ACMが提供するCNAMEレコードをDNSに追加
   - 自動検証（数分～数時間）

3. **ALBへのアタッチ**
   ```bash
   aws elbv2 modify-listener \
     --listener-arn <listener-arn> \
     --certificates CertificateArn=<cert-arn>
   ```

4. **所要時間:** 30分～2時間（DNS伝播による）

#### Azure Application Gateway + Key Vault

```mermaid
flowchart TD
    Start([開始]) --> Choice{証明書タイプ選択}
    Choice -->|App Service証明書| ASC[App Service証明書購入]
    Choice -->|Key Vault証明書| KVC[Key Vault証明書作成]
    Choice -->|マネージド証明書| MC[マネージド証明書作成]
    
    ASC --> ASC_Val[ドメイン検証]
    KVC --> KVC_Val[CA統合設定]
    MC --> MC_Val[DNS/HTTP検証]
    
    ASC_Val --> Store[Key Vaultに保存]
    KVC_Val --> Store
    MC_Val --> AppSvc[App Serviceに自動適用]
    
    Store --> MI[マネージドID設定]
    MI --> Access[Key Vaultアクセスポリシー]
    Access --> Attach[Application Gatewayに証明書参照設定]
    Attach --> Test[HTTPS接続テスト]
    AppSvc --> End([完了])
    Test --> End
```

**手順詳細:**

1. **Key Vaultで証明書作成**
   ```bash
   # Key Vault作成
   az keyvault create \
     --name myKeyVault \
     --resource-group myResourceGroup \
     --location eastus
   
   # 証明書ポリシー作成
   az keyvault certificate create \
     --vault-name myKeyVault \
     --name myCertificate \
     --policy @policy.json
   ```

2. **マネージドID設定**
   ```bash
   # Application GatewayにマネージドID割り当て
   az network application-gateway identity assign \
     --gateway-name myAppGateway \
     --resource-group myResourceGroup \
     --identity myManagedIdentity
   ```

3. **Key Vaultアクセス許可**
   ```bash
   az keyvault set-policy \
     --name myKeyVault \
     --object-id <managed-identity-object-id> \
     --secret-permissions get list
   ```

4. **Application Gatewayに証明書設定**
   ```bash
   az network application-gateway ssl-cert create \
     --gateway-name myAppGateway \
     --resource-group myResourceGroup \
     --name myCertificate \
     --key-vault-secret-id "https://myKeyVault.vault.azure.net/secrets/myCertificate/"
   ```

5. **所要時間:** 1～3時間（CA統合と検証による）

### 更新フロー

#### AWS ACM

```mermaid
flowchart TD
    Start([60日前]) --> Check[ACMが自動チェック]
    Check --> DNS{DNS検証レコード確認}
    DNS -->|有効| Renew[新証明書発行]
    DNS -->|無効| Alert1[CloudWatch Event発行]
    Renew --> Deploy[ALBに自動デプロイ]
    Deploy --> Complete([更新完了])
    Alert1 --> Manual[手動介入必要]
    Manual --> Fix[DNS設定修正]
    Fix --> Check
```

**特徴:**
- 完全自動、ユーザー介入不要
- DNS検証レコードの維持が必須
- 更新失敗時のみ通知
- ダウンタイムゼロ

#### Azure Application Gateway + Key Vault

```mermaid
flowchart TD
    Start([45日前]) --> KV_Check[Key Vaultが更新開始]
    KV_Check --> Validate{ドメイン検証}
    Validate -->|成功| New_Ver[新バージョン作成]
    Validate -->|失敗| Alert1[Event Grid通知]
    New_Ver --> Poll[Application Gateway 4時間ごとポーリング]
    Poll --> Detect[新バージョン検出]
    Detect --> Rotate[証明書ローテーション]
    Rotate --> Complete([更新完了])
    Alert1 --> Manual[手動介入]
    Manual --> Fix[検証設定修正]
    Fix --> KV_Check
```

**特徴:**
- Key Vaultが自動更新を管理
- Application Gatewayは4時間ごとにポーリング
- 設定変更時に即座にチェック
- Event Gridで詳細な通知

### トラブルシューティング

#### AWS ACM

**一般的な問題と解決策:**

1. **証明書が自動更新されない**
   - **原因:** DNS検証レコードが削除された
   - **解決:** DNS検証レコードを再追加
   ```bash
   # 証明書の検証状態確認
   aws acm describe-certificate --certificate-arn <cert-arn>
   ```

2. **証明書がALBで使用できない**
   - **原因:** 証明書とALBが異なるリージョン
   - **解決:** 同じリージョンで証明書を再発行

3. **ドメイン検証が完了しない**
   - **原因:** DNS伝播の遅延
   - **解決:** 最大72時間待機、DNSレコード確認
   ```bash
   # DNS検証レコード確認
   dig CNAME _validation.example.com
   ```

4. **証明書の有効期限切れ通知**
   - **原因:** 自動更新の失敗
   - **解決:** CloudWatch Logsで詳細確認、DNS設定確認

**監視設定:**
```bash
# CloudWatch Eventsルール作成
aws events put-rule \
  --name acm-certificate-expiration \
  --event-pattern '{
    "source": ["aws.acm"],
    "detail-type": ["ACM Certificate Approaching Expiration"]
  }'
```

#### Azure Application Gateway + Key Vault

**一般的な問題と解決策:**

1. **証明書が更新されない**
   - **原因:** Key Vaultアクセス権限の問題
   - **解決:** マネージドIDの権限確認
   ```bash
   # アクセスポリシー確認
   az keyvault show --name myKeyVault --query properties.accessPolicies
   ```

2. **Application Gatewayが新証明書を取得しない**
   - **原因:** シークレット識別子にバージョン指定
   - **解決:** バージョンなしの識別子を使用
   ```bash
   # 正しい形式: https://myvault.vault.azure.net/secrets/mycert/
   # 誤った形式: https://myvault.vault.azure.net/secrets/mycert/abc123
   ```

3. **証明書の検証失敗**
   - **原因:** DNS/HTTP検証設定の問題
   - **解決:** 検証方法の再設定
   ```bash
   # 証明書ステータス確認
   az keyvault certificate show \
     --vault-name myKeyVault \
     --name myCertificate
   ```

4. **トランザクション制限エラー**
   - **原因:** Key Vaultの操作制限超過
   - **解決:** 操作頻度の調整、複数Key Vaultの使用

**監視設定:**
```bash
# Event Grid サブスクリプション作成
az eventgrid event-subscription create \
  --name cert-expiration-alert \
  --source-resource-id /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault-name> \
  --endpoint <webhook-url> \
  --included-event-types Microsoft.KeyVault.CertificateNearExpiry
```

---

## 運用上の考慮事項

### 移行時の注意点

#### AWS ACMへの移行

**既存証明書からの移行:**

1. **証明書のインポート**
   ```bash
   aws acm import-certificate \
     --certificate fileb://certificate.pem \
     --private-key fileb://private-key.pem \
     --certificate-chain fileb://certificate-chain.pem
   ```

2. **注意点:**
   - インポートした証明書は自動更新されない
   - 有効期限前に手動で更新が必要
   - DNS検証を設定すれば次回から自動更新可能

3. **移行手順:**
   - 新しいACM証明書をリクエスト
   - DNS検証を完了
   - ALBで新証明書に切り替え
   - 古い証明書を削除

**ダウンタイム最小化:**
- ALBは複数証明書をサポート
- 新証明書を追加してから古い証明書を削除
- SNIにより自動的に適切な証明書を選択

#### Azure証明書管理への移行

**既存証明書からの移行:**

1. **Key Vaultへのインポート**
   ```bash
   az keyvault certificate import \
     --vault-name myKeyVault \
     --name myCertificate \
     --file certificate.pfx \
     --password <password>
   ```

2. **注意点:**
   - PFX形式が必要
   - インポート後は自動更新設定が必要
   - CA統合を設定しないと自動更新されない

3. **移行手順:**
   - Key Vaultに証明書をインポート
   - マネージドIDとアクセスポリシーを設定
   - Application Gatewayで新証明書を参照
   - 古い証明書を削除

**ダウンタイム最小化:**
- 複数リスナーを使用
- 新証明書のリスナーを追加
- トラフィックを徐々に移行
- 古いリスナーを削除

### ベストプラクティス

#### AWS ACM

1. **DNS検証を使用**
   - Email検証より自動化が容易
   - 更新が完全自動

2. **証明書のタグ付け**
   ```bash
   aws acm add-tags-to-certificate \
     --certificate-arn <cert-arn> \
     --tags Key=Environment,Value=Production Key=Application,Value=WebApp
   ```

3. **CloudWatch監視の設定**
   - 証明書の有効期限アラート
   - 更新失敗の通知

4. **リージョン戦略**
   - 各リージョンで証明書を個別に管理
   - CloudFrontはus-east-1の証明書を使用

5. **証明書の整理**
   - 未使用の証明書を定期的に削除
   - 証明書数の上限（2,500）に注意

#### Azure証明書管理

1. **Key Vault統合を優先**
   - 中央集権的な管理
   - 自動更新のサポート
   - セキュアなアクセス制御

2. **バージョンなしのシークレット識別子を使用**
   ```
   # 推奨
   https://myvault.vault.azure.net/secrets/mycert/
   
   # 非推奨（バージョン指定）
   https://myvault.vault.azure.net/secrets/mycert/abc123
   ```

3. **マネージドIDの使用**
   - サービスプリンシパルより安全
   - 認証情報の管理不要

4. **Event Grid統合**
   - 証明書ライフサイクルイベントの監視
   - 自動化ワークフローのトリガー

5. **トランザクション制限の考慮**
   - 大規模環境では複数Key Vaultを使用
   - 操作頻度の最適化

6. **証明書の自動更新設定**
   ```bash
   # 更新ポリシー設定
   az keyvault certificate set-attributes \
     --vault-name myKeyVault \
     --name myCertificate \
     --policy @renewal-policy.json
   ```

### よくある落とし穴

#### AWS ACM

1. **リージョンの不一致**
   - **問題:** 証明書とALBが異なるリージョン
   - **影響:** 証明書が使用できない
   - **回避策:** 各リージョンで証明書を個別に作成

2. **DNS検証レコードの削除**
   - **問題:** 検証レコードを誤って削除
   - **影響:** 自動更新が失敗
   - **回避策:** DNS変更時に検証レコードを保持

3. **証明書のエクスポート期待**
   - **問題:** 無料証明書はエクスポート不可
   - **影響:** EC2等で直接使用できない
   - **回避策:** エクスポート可能証明書を購入（有料）

4. **Email検証の使用**
   - **問題:** Email検証は手動承認が必要
   - **影響:** 自動更新が困難
   - **回避策:** DNS検証を使用

5. **証明書数の上限**
   - **問題:** リージョンあたり2,500証明書の制限
   - **影響:** 新規証明書が作成できない
   - **回避策:** 未使用証明書の削除、上限引き上げリクエスト

#### Azure証明書管理

1. **バージョン指定のシークレット識別子**
   - **問題:** 特定バージョンを指定
   - **影響:** 自動更新が機能しない
   - **回避策:** バージョンなしの識別子を使用

2. **Key Vaultアクセス権限の不足**
   - **問題:** マネージドIDに適切な権限がない
   - **影響:** 証明書の取得失敗
   - **回避策:** "Key Vault Secrets User"ロールを付与

3. **App Service証明書の誤解**
   - **問題:** App Service証明書がApplication Gatewayで直接使用できると誤解
   - **影響:** 設定エラー
   - **回避策:** Key Vault経由で使用

4. **トランザクション制限の見落とし**
   - **問題:** 大量の証明書操作
   - **影響:** スロットリング発生
   - **回避策:** 操作の分散、複数Key Vaultの使用

5. **証明書形式の問題**
   - **問題:** PEM形式の証明書をアップロード
   - **影響:** Application Gatewayで使用不可
   - **回避策:** PFX形式に変換

6. **自動更新の設定漏れ**
   - **問題:** CA統合を設定していない
   - **影響:** 手動更新が必要
   - **回避策:** DigiCert/GlobalSign統合を設定

---

## ユースケース別推奨

### シンプルなWebアプリケーション

**要件:**
- 単一リージョン
- 1～5個の証明書
- 基本的なHTTPS対応

**AWS推奨構成:**
```
ACM（無料パブリック証明書）
  ↓
Application Load Balancer
  ↓
EC2 / ECS / Lambda
```

**理由:**
- 設定が最もシンプル
- 完全無料
- 自動更新が透過的

**Azure推奨構成:**
```
App Serviceマネージド証明書（無料）
  ↓
App Service
```

または

```
Key Vault（DigiCert統合）
  ↓
Application Gateway
  ↓
Virtual Machines / App Service
```

**理由:**
- App Serviceの場合はマネージド証明書が最適
- VMの場合はKey Vault + Application Gateway

### マルチリージョン展開

**要件:**
- 複数リージョンでの展開
- グローバルな負荷分散
- 低レイテンシー

**AWS推奨構成:**
```
Route 53（グローバルDNS）
  ↓
CloudFront（us-east-1のACM証明書）
  ↓
各リージョンのALB（リージョナルACM証明書）
  ↓
アプリケーション
```

**理由:**
- CloudFrontでグローバルエッジ配信
- 各リージョンで独立した証明書管理
- 自動フェイルオーバー

**Azure推奨構成:**
```
Traffic Manager / Front Door（グローバルDNS）
  ↓
各リージョンのApplication Gateway（Key Vault証明書）
  ↓
アプリケーション
```

**理由:**
- Front Doorでグローバルエッジ配信
- Key Vaultで中央集権的な証明書管理
- リージョン間での証明書共有が容易

### エンタープライズ環境

**要件:**
- 大量の証明書（100+）
- 厳格なセキュリティ要件
- コンプライアンス対応
- 詳細な監査ログ

**AWS推奨構成:**
```
AWS Organizations（マルチアカウント）
  ↓
各アカウントのACM
  ↓
CloudTrail（監査ログ）
  ↓
CloudWatch（監視・アラート）
```

**追加要素:**
- AWS Config（コンプライアンス監視）
- AWS Security Hub（セキュリティ統合）
- AWS Private CA（プライベート証明書）

**理由:**
- アカウント分離によるセキュリティ強化
- 詳細な監査証跡
- 自動コンプライアンスチェック

**Azure推奨構成:**
```
Azure Policy（ガバナンス）
  ↓
Key Vault（Premium SKU、HSM保護）
  ↓
Azure Monitor（監視）
  ↓
Microsoft Sentinel（SIEM）
```

**追加要素:**
- Azure RBAC（詳細なアクセス制御）
- Azure Private Link（プライベート接続）
- Event Grid（イベント駆動自動化）

**理由:**
- HSM保護による最高レベルのセキュリティ
- 中央集権的な証明書管理
- 詳細な監査とコンプライアンス

### コスト重視

**要件:**
- 最小限のコスト
- 基本的な機能で十分
- 小規模～中規模

**AWS推奨構成:**
```
ACM（無料パブリック証明書）
  ↓
Application Load Balancer
  ↓
EC2（オンデマンドまたはスポット）
```

**月額コスト例:**
- ACM証明書: $0
- ALB: ~$22.50
- EC2: 使用量による

**理由:**
- 証明書コストゼロ
- 必要最小限の構成
- 自動更新で運用コスト削減

**Azure推奨構成:**
```
App Serviceマネージド証明書（無料）
  ↓
App Service（Basic/Standard tier）
```

**月額コスト例:**
- マネージド証明書: $0
- App Service Basic B1: ~$13

**理由:**
- 証明書コストゼロ
- PaaS による運用コスト削減
- 自動スケーリング

**コスト比較:**

| シナリオ | AWS月額 | Azure月額 |
|---------|---------|-----------|
| 小規模Web（1証明書） | ~$22.50（ALBのみ） | ~$13（App Service Basic） |
| 中規模Web（5証明書） | ~$22.50（ALBのみ） | ~$55（App Service Standard） |
| エクスポート可能証明書 | +$7/証明書 | +$75.99/年/証明書 |

---

## まとめ

### AWS ACMの強み

1. **シンプルさ:** 単一サービスで完結、学習コストが低い
2. **統合性:** AWSサービスとのシームレスな統合
3. **コスト:** 無料のパブリック証明書（統合利用時）
4. **自動化:** 完全自動の更新プロセス
5. **CloudFront統合:** グローバルCDNとの統合が容易

### Azure証明書管理の強み

1. **柔軟性:** 複数のサービスオプション（Key Vault、App Service証明書、マネージド証明書）
2. **中央管理:** Key Vaultによる統合管理
3. **セキュリティ:** HSM保護、詳細なRBAC
4. **制限なし:** 証明書数の制限なし（Key Vault）
5. **エンタープライズ機能:** 詳細な監査、コンプライアンス機能

### 選択基準

**AWS ACMを選択すべき場合:**
- AWS環境に完全に統合されたい
- シンプルで運用負荷の低いソリューションが必要
- 無料の証明書で十分
- CloudFrontを使用したグローバル配信

**Azure証明書管理を選択すべき場合:**
- 柔軟な証明書管理が必要
- 中央集権的な管理を重視
- エンタープライズレベルのセキュリティが必要
- 複数のAzureサービス間で証明書を共有

### 最終推奨

両サービスとも成熟しており、それぞれのクラウドプラットフォームで優れた証明書管理を提供します。選択は主に以下の要因に依存します：

1. **既存のクラウド環境:** 既にAWSまたはAzureを使用している場合、そのプラットフォームの証明書サービスを使用するのが自然
2. **要件の複雑さ:** シンプルな要件ならAWS ACM、複雑な要件ならAzure Key Vault
3. **コスト:** 小規模ならどちらも低コスト、大規模ならAzureの方が柔軟
4. **運用スキル:** チームの既存スキルセットに合わせる

---

## 参考資料

### AWS ACM
- [AWS Certificate Manager Documentation](https://docs.aws.amazon.com/acm/)
- [Managed Certificate Renewal](https://docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html)
- [SSL Certificates for Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/https-listener-certificates.html)
- [ACM Exportable Certificates](https://docs.aws.amazon.com/acm/latest/userguide/acm-exportable-certificates.html)

### Azure証明書管理
- [Azure Key Vault Certificates](https://learn.microsoft.com/azure/key-vault/certificates/)
- [Application Gateway Certificate Renewal](https://learn.microsoft.com/azure/application-gateway/renew-certificates)
- [App Service Certificates](https://learn.microsoft.com/azure/app-service/configure-ssl-app-service-certificate)
- [TLS Termination with Key Vault](https://learn.microsoft.com/azure/application-gateway/key-vault-certs)
- [Certificate Lifecycle Management](https://learn.microsoft.com/azure/architecture/example-scenario/certificate-lifecycle/)

---

**作成日:** 2026年6月15日  
**バージョン:** 1.0

Web検索ベースとの比較感

同様の質問をWeb検索ベースのAIアシスタントに投げた場合と比べると、以下のような違いを感じた。

観点	Web検索ベース	IBM Bob + MCP
応答速度	やや遅い	速い
情報源の信頼性	公開時期の古いブログ記事など混入の可能性あり	一次情報（公式ドキュメント）限定
回答の構造化	バラつきあり	整理されている印象
根拠の透明性	曖昧になりやすい	ツール呼び出しログが見える
調査の進捗可視化	なし	Todoリストで常に把握できる
途中の軌道修正	基本的に不可	サブタスク単位で承認・追加指示が可能

ツール呼び出しが可視化される安心感

IBM Bobのインターフェース上では、MCPツールがどのクエリで呼び出されたかがUIに表示される。これにより「この回答はMicrosoft LearnまたはAWS公式ドキュメントをどのように検索して得られた結果なのか」が確認でき、根拠検証のコストが大幅に下がる。

まとめ・所感

MCPによってタスク特化の情報収集を行う

MCPでは、データベースやその他コマンド実行など具体的なシステム操作や、AWSおよびAzure環境の操作を行わせることも勿論可能だが、今回のような情報収集にも有用であることを認識した。Web検索は汎用性が高い一方で、情報の鮮度・正確さのコントロールが難しく、多少の手間をかけてもMCPを設定するメリットはあるように感じた。

「サブタスク分割＋人による承認」はAIエージェントとの新しい協働スタイル

従来のAIアシスタント利用は「質問して回答を待つ」という一問一答の形が主流であった。IBM BobのTodo管理＋承認フローは、これを 「調査計画を立てて一緒に進める」という協働スタイル に変える。調査方向が正しいかを途中で確認できる、不要なサブタスクをスキップできる、追加指示で深掘り対象を変えられる、といった自由度は、複雑な設計検討において便利になる。

あくまで今回の主眼はクラウドサービスの比較作業の効率化であったが、AIエージェントの優位性、および人手の介在を前提とした場合のAIとの共存について実感できるユースケース事例であると感じた。

最終的な判断は人間のもの

あくまで「調査と整理をIBM Bobに任せ、判断は自分で行う」という役割分担において、サブタスクの承認フローにより各ステップで人間が内容を確認することで、最終成果物の品質に対してオーナーシップを持ち続けられる構造になっていると考える。

参考リンク