本ブログは 2026 年 8 月 6 日に公開された AWS Blog “ Automate certificates with ACME support in AWS Certificate Manager ” を翻訳したものです。 大規模な TLS 証明書の管理は、運用上の最大の懸念事項の 1 つであるとお客様からお聞きしています。 Certification Authority Browser Forum (CA/Browser Forum) は、パブリック証明書の最大有効期間の段階的な短縮を義務付けました。2027 年 3 月までに、最大有効期間は 100 日に短縮されます。2029 年 3 月までには 47 日となります。証明書を 1,000 件管理している組織にとって、最終段階への移行は、毎日およそ 30 件の更新イベントが発生することを意味します。このペースでの証明書の更新と、更新された証明書のローテーションは、手作業やチケットベースのワークフローで大規模に維持できるものではありません。 AWS は先日、 AWS Certificate Manager (ACM) における Automated Certificate Management Environment (ACME) プロトコルのサポートを発表しました。今回のリリースにより、certbot、cert-manager、acme.sh、win-acme などの人気のあるオープンソースツールをはじめ、チームが既に使い慣れている ACME クライアントを使用して、インフラストラクチャのパブリック証明書の発行と更新を自動化できます。サードパーティの認証機関 (CA) を利用しているお客様は、最小限の設定変更で、既存の ACME 互換クライアントの接続先を現在の CA から ACM に切り替えることができます。これは、 Amazon Web Services (AWS) 上、オンプレミス、ハイブリッド環境のいずれで実行している場合でも同様です。ACME を通じて作成された証明書は ACM に登録されるため、証明書インベントリ全体を統合的に把握できます。 この記事では、この機能の仕組み、開始方法、そして証明書の発行を大規模に管理するためのコントロールとベストプラクティスについて説明します。 背景 ACME は、ドメイン所有権の検証と証明書の発行のプロセスを自動化するオープンソースプロトコルであり、証明書自動化の標準的な仕組みとなっています。ACM は、 Elastic Load Balancing (ELB) 、 Amazon CloudFront 、 Amazon API Gateway などの AWS 統合サービスに対して、マネージド型の証明書発行と更新を長らく提供してきました。しかし多くのお客様は、データセンター内で管理するサーバー、Kubernetes クラスター、モノのインターネット (IoT) フリート、ハイブリッド環境など、独自のインフラストラクチャの証明書も自動化する必要があります。これまで、そうしたお客様は外部プロバイダーに頼らざるを得ませんでした。今回のリリースにより、AWS が管理する証明書エンドポイントと標準の ACME プロトコルを使用して、ACM の自動化モデルをそうしたインフラストラクチャにも適用できるようになります。 仕組み この機能では、一元的にプロビジョニングおよび管理される新しいリソースタイプである ACME エンドポイントが導入されます。各エンドポイントは、一意の ACME ディレクトリ URL と AWS Identity and Access Management (IAM) ベースのアクセスコントロールを持つ AWS リソースです。ACM の API または AWS マネジメントコンソールを通じてエンドポイントを作成および管理し、既存の ACME クライアントの接続先をエンドポイント URL に設定します。エンドポイントを通じて発行された証明書は自動的に ACM に登録され、 RequestCertificate および ImportCertificate API コールで作成された証明書と並んで証明書インベントリに表示されます。 このアーキテクチャは 2 つのプレーンに分かれています。コントロールプレーンでは、PKI 管理者が ACM の API を使用して ACME エンドポイントを作成し、そのエンドポイントが証明書を発行できるドメインを事前承認し、外部アカウントバインディング (EAB) 認証情報を生成します。データプレーンでは、ACME クライアントが EAB 認証情報を使用してエンドポイントに登録し、管理者が既に検証済みのドメインに対して証明書をリクエストします。このアーキテクチャによって、お客様は証明書の発行をスケールできるようになります。各クライアントがリクエストのたびにドメイン所有権を証明するのではなく、適切な ACM アクセス許可を持つプリンシパル (通常は PKI 管理者) がエンドポイントレベルで一度だけドメインを検証するため、アプリケーション所有者は証明書を取得するために DNS の認証情報を必要としません。 データプレーンではさらに、EAB がエンドポイントへのクライアントアクセスを制御します。各 EAB は、ACME クライアントが実行できる証明書操作を制御する IAM ロールにバインドされており、ACM で生成した認証情報は認可された ACME クライアントに配布されます。あるエンドポイントに対して認可された ACME クライアントは、別のエンドポイントを使用できません。これにより、環境間にセキュリティ境界が作られます。例えば、開発用エンドポイントに対して認可されたクライアントは、本番用エンドポイントから証明書を取得できません。 図 1 は、ACM を通じた ACME リクエストのフローを示しています。ACME クライアントは、EAB 認証情報を使用して ACME エンドポイントに対して認証を行います。エンドポイントは、証明書のオーダーを発行のために Amazon Trust Services にルーティングします。発行された証明書は ACM インベントリに登録され、 Amazon EventBridge と AWS CloudTrail によって、有効期限のアラートと監査ログが提供されます。 図 1: ACME のアーキテクチャとワークフロー 開始方法 ACM の新しい ACME 機能は簡単に始められます。以下の手順に従って、ACME で発行する最初の証明書を作成してください。 前提条件 ACM リソースを作成および管理するアクセス許可を持つ AWS アカウント インフラストラクチャにインストール済みの ACME クライアント (Certbot、cert-manager、acme.sh など) デバイスにインストール済みの AWS コマンドラインインターフェイス (AWS CLI) (コンソールでの同等の手順については、こちらのブログ記事「 AWS Certificate Manager の ACME サポートを使用してパブリック TLS 証明書の発行を自動化 」を参照してください) 証明書を発行するドメインの Amazon Route 53 ホストゾーン、または DNS プロバイダーで CNAME レコードを作成できる環境 ステップ 1: ACME エンドポイントを作成する ACME クライアントを ACM で使用する前に、ACME エンドポイントを作成する必要があります。このエンドポイントは、ACME クライアントが証明書のリクエストに使用する URL を提供します。 AWS CLI から以下のコマンドを実行して、ACME エンドポイントを作成します。 aws acm create-acme-endpoint \ --authorization-behavior PRE_APPROVED \ --certificate-authority '{"PublicCertificateAuthority":{"AllowedKeyAlgorithms":["EC_prime256v1"]}}' レスポンスからエンドポイントの Amazon リソースネーム (ARN) をメモします。 {"AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555"} 以下のコマンドを実行してエンドポイント URL を取得します。ARN の部分は作成したエンドポイントの ARN に置き換えてください。 aws acm describe-acme-endpoint \ --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 出力される ACME の EndpointUrl を保存します。 { "AcmeEndpoint": { "AcmeEndpointArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555", "EndpointUrl": "https://acm-acme-enroll.<region>.api.aws/6666666-7777-8888-9999-000000000000/directory", "Status": "ACTIVE", "AuthorizationBehavior": "PRE_APPROVED", "Contact": "REQUIRED", "CertificateAuthority": { "PublicCertificateAuthority": { "AllowedKeyAlgorithms": [ "EC_prime256v1" ] } }, "CreatedAt": "2026-07-14T18:23:58.876000-04:00", "UpdatedAt": "2026-07-14T18:23:58.876000-04:00" } } ステップ 2: ドメインを事前承認する ACME クライアントが証明書をリクエストできるようにする前に、管理者がエンドポイントレベルで一度だけ DNS を使用してドメインを検証します。 DomainScope を使用して、許可する証明書パターンを正確に制御します。 ExactDomain のみを有効にすると、クライアントはその特定の名前に限定されます。 Subdomains を有効にすると、 api.example.com のような名前が許可されます。 Wildcards を有効にすると、 *.example.com が許可されます。 スコープを無効のままにしておくと、それ以外の点では有効な ACME リクエストがそのパターンを要求したとしても、完全にブロックされます。本番用エンドポイントでは、よりセキュリティを強化した構成とするために、 ExactDomain と Subdomains のみを有効にし、 Wildcards は無効のままにしておくことを検討してください。 aws acm create-acme-domain-validation \ --acme-endpoint-arn arn:aws:acm:us-east-1:123456789012:acme-endpoint/11111111-2222-3333-4444-555555555555 \ --domain-name example.com \ --prevalidation-options '{"DnsPrevalidation":{"DomainScope":{"ExactDomain":"ENABLED","Subdomains":"ENABLED","Wildcards":"DISABLED"},"HostedZoneId":"Z1234567890ABC"}}' ドメインが Route 53 でホストされている場合、 HostedZoneId を指定すると、ACM が必要な CNAME レコードを自動的に作成します。ドメインが他の場所でホストされている場合は、この指定を省略し、提供される CNAME レコードを DNS プロバイダーで手動で作成してください。レコードが作成されると、通常は数秒以内に検証が完了します。 以下のレスポンスが返されます。 { "AcmeDomainValidationArn": "arn:aws:acm:us-east-1:123456789012:acme-endpoint/1111111-2222-3333-4444-555555555555/acme-domain-validation/6666666-8888-9999-0000-11111111111" } ステップ 3: EAB 認証情報を生成する EAB 認証情報は、ACME クライアントをエンドポイントに対して認証するために使用されます。セキュリティ境界を維持するため、クライアントまたは環境ごとに一意の認証情報を生成してください。 以下のコマンドを実行して EAB 認証情報を生成します。有効期限は組織のリスクプロファイルに合わせて調整してください。 aws acm create-acme-external-account-binding \ --acme-endpoint-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000 \ --role-arn arn:aws:iam::111122223333:role/AcmeIssuanceRole \ --expiration '{"Value": 7, "Type": "DAYS"}' コマンドが正常に実行された際のレスポンスをメモします。 { "ExternalAccountBinding": { "AcmeExternalAccountBindingArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/1234567-1234-1234-1234-123456789012", "AcmeEndpointArn": "arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000", "RoleArn": "arn:aws:iam::123456789012:role/service-role/AcmAcmeIssuanceRole-XXXXXXXX", "ExpiresAt": "2026-07-21T18:47:50.641000-04:00" } } 以下のコマンドを実行して認証情報を取得します。これらの値は、次のステップで ACME クライアントの設定に必要になります。 aws acm get-acme-external-account-binding-credentials \ --acme-external-account-binding-arn arn:aws:acm:region:111122223333:acme-endpoint/00000000-0000-0000-0000-000000000000/acme-external-account-binding/22222222-2222-2222-2222-222222222222 次のステップのために KeyId と MacKey を保存します。 { "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "MacKey": "xxxxxxxx-xxxxxxxxxx-xxxxxxxxxxxxxxx" } ステップ 4: ACME クライアントを設定する エンドポイント URL と EAB 認証情報が準備できたら、使用する ACME クライアントを設定できます。以下は、人気のある 2 つのクライアントの設定例です。なお、サーバー情報には、ステップ 1 の手順 4 で EndpointUrl として取得した値を使用します。 acme.sh: acme.sh --issue --server https://acm-acme-enroll.us-east-1.api.aws/123457-1234-1234-123456789012/directory \ --eab-kid <KeyId> --eab-hmac-key <MacKey> \ --email <EMAIL> \ -d <DOMAIN> \ --dns --yes-I-know-dns-manual-mode-enough-go-ahead-please Certbot: certbot certonly --standalone --non-interactive --agree-tos \ --email <EMAIL> \ --server https://acm-acme-enroll.us-east-1.api.aws/1234567-1234-1234-123456789012/directory \ --eab-kid <KeyId> \ --eab-hmac-key <MacKey> \ -d <DOMAIN> 最初の登録が完了すると、以降の更新は ACME クライアントが処理します。 エンタープライズ向けのコントロール ACME に対応した他のサービスでも証明書は取得できますが、証明書環境をスケールする必要があるお客様に対して、同等のコントロールとガバナンスは提供されません。組織全体のリスクを軽減するために、以下のコントロールが利用できます。 ドメイン検証 多数のドメインを管理しているお客様から、ドメイン空間全体にわたって不正な証明書の発行を防ぐ方法が必要だという声をいただいています。ドメイン検証によって、これを制御できるようになります。検証する各ドメインに対して、そのドメインで発行を許可する証明書パターンを、 ExactDomain 、 Subdomains 、 Wildcards の中から有効にします。例えば、 internal.example.com を検証して Wildcards のみを有効にした場合、ACME クライアントは *.internal.example.com をリクエストできますが、 internal.example.com 自体や api.internal.example.com のリクエストは拒否されます。この制御は、リクエストが ACM の認証機関に到達する前にエンドポイントレベルで適用されます。また、1 つのエンドポイントの下で複数のドメインを、それぞれ独自のスコープで検証できます。 証明書の一元的な可視化 ACME エンドポイントを通じて発行された証明書は ACM に登録されます。 aws acm list-certificates コマンドを使用して、発行されたすべての証明書を確認できます。 IAM による認可、CloudTrail による監査ログとオブザーバビリティ エンドポイントの管理操作は IAM を通じて認可され、CloudTrail に記録されます。IAM ポリシーを使用して、どのプリンシパルがエンドポイントの作成、EAB 認証情報の生成、ドメイン制約の管理を行えるかを制御できます。 ベストプラクティス ACME 証明書を初めて導入するお客様は、組織に合わせて以下のベストプラクティスを検討してください。 組織や環境の境界に合わせてエンドポイントを分割する エンドポイントは、大規模な組織にとって有用な分離の手段として機能します。大企業は、全社で 1 つのエンドポイントを共有するのではなく、組織の境界 (事業部門、子会社、環境) ごとに 1 つのエンドポイントを作成できます。各エンドポイントは独自の事前承認済みドメインと独自の EAB セットを持つため、ある事業部門で認証情報が侵害されても、それを使って別の事業部門の証明書を取得することはできません。 ただし、この分割方針は運用上のオーバーヘッドとのバランスも考慮して判断してください。妥当な出発点は、事業部門内で環境 (開発、ステージング、本番) ごとに 1 つのエンドポイントを作成し、コンプライアンスや組織上の要件がある場合にのみ、事業部門ごとのエンドポイントへ拡張することです。 EAB 認証情報を安全に管理する エンドポイントの有効な KeyId と MacKey を持っている人は誰でも、そのエンドポイントで事前承認済みの任意のドメインの証明書を取得できます。そのため、これらの認証情報はアクセスキーと同様に取り扱う必要があります。 可能な限り MacKey をハードコーディングせず、 AWS Secrets Manager などのシークレットストアを使用します。エンドポイントの使用を認可した ACME クライアントにのみ配布してください。 EAB の有効期限を許容できるレベルに設定します。EAB は長期間有効な認証情報をサポートしていますが、すべてのシナリオで有効期間が極端に長い EAB が必要なわけではありません。 各 EAB のロールを作成する際は、最小権限の考え方に従います。すべてのバインディングでロールを共有するのではなく、EAB ごとにロールを作成することで、AWS 環境におけるリスクの軽減に役立ちます。 CloudTrail で CreateAcmeExternalAccountBinding コールと GetAcmeExternalAccountBindingCredentials コールを個別に監査します。実際のキーマテリアルの取得は、バインディングの作成とは別の API コールであるため、取得イベントに対するアラートは、バインディング作成のみの場合よりも、実際の認証情報の配布を示す強いシグナルになります。 実行時に EAB をクライアントに関連付ける方法を自動化する 複数の ACME クライアントで 1 つのバインディングを共有するのではなく、クライアントまたは環境ごとに一意の EAB 認証情報を生成してください。複数のエンドポイントへとスケールする段階になったら、運用上の労力を軽減するために、以下のパターンから必要なものを取り入れてください。 各 EAB とそれにバインドされた IAM ロールに、所属するクライアント (チーム、アプリケーション、環境) にちなんだ名前を付けます。これにより、スプレッドシートと照合しなくても、 DescribeAcmeExternalAccountBinding の出力だけでバインディングの用途が明確になります。 各クライアントの KeyId と MacKey を、そのクライアントに限定されたシークレットパス (例えば、チームと環境ごとの Secrets Manager のパス) に保存し、クライアントのプロビジョニングパイプラインが自身の認証情報を取得できるようにします。 Kubernetes では、チーム間で 1 つの共有 issuer を使用するのではなく、EAB ごとに 1 つの ClusterIssuer または名前空間スコープの Issuer を使用します。これにより、クライアントと EAB の関連付けがクラスター設定で明示的になり、他のチームに影響を与えずに特定のチームのアクセスを取り消すことができます。 一時的なインフラストラクチャ (ビルドエージェント、オートスケールされるフリート) の場合、一度きりの手動での受け渡しではなく、Infrastructure as Code または継続的インテグレーションおよびデプロイ (CI/CD) パイプラインの一部として EAB 認証情報をプロビジョニングします。これにより、認証情報のライフサイクルがインフラストラクチャのライフサイクルに追従します。 ACME のデプロイをモニタリングする ACME の強みは自動化にあり、組織は ACME の使用状況に異常がないかモニタリングする必要があります。 成功だけでなく、発行の失敗に対してもアラームを設定します。証明書の有効期間が 47 日になると、更新が気付かないうちに失敗した場合に対応できる時間は、有効期間の長い証明書で得られていた数か月の猶予に比べて、はるかに短くなります。 更新の自動化に依存する前にテストします。CA/Browser Forum の短縮された有効期間により、更新失敗が組織の業務を中断させる事態になる前に、非本番のエンドポイントに対して手動更新を強制実行し、クライアント、モニタリング、オンコールのランブックが期待どおりに動作することを確認してください。 提供リージョンと料金 AWS Certificate Manager の ACME サポートは、本日 (2026 年 8 月 6 日) からすべての商用 AWS リージョンで利用可能です。また、AWS GovCloud (US)、中国リージョン、 AWS European Sovereign Cloud の各 パーティション でも後日利用可能になる予定です。ACME の料金の詳細については、「 ACM の料金ページ 」を参照してください。 まとめ 証明書の有効期間の段階的な短縮は、自動化なしに簡単に解決できるものではありません。ACM の ACME サポートは、標準プロトコルと標準ツールを通じてその自動化を提供しながら、セキュリティチームが ACM で頼りにしている可視性とガバナンスのコントロールを維持します。 開始するには、「 AWS Certificate Manager のドキュメント 」を参照するか、「 開始方法ガイド 」に沿って進めてください。 Anthony Harvey Anthony は、AWS のワールドワイド公共部門グループのシニアセキュリティスペシャリストソリューションアーキテクトです。AWS に入社する前は、地方自治体で 5 年間、最高情報セキュリティ責任者を務めていました。公共部門での経験から、少ないリソースでより多くを実現する方法を見出すことに情熱を持ち、その考え方を活かしてお客様のセキュリティの取り組みを支援しています。 Chandan Kundapur Chandan は、AWS Certificate Manager (ACM) チームのプリンシパルプロダクトマネージャーです。15 年以上のサイバーセキュリティの経験を持ち、PKI 製品戦略の推進に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの松永です。8 月に入り各地で猛暑が続いていますね。工場の現場では熱中症対策に神経を使う時期かと思います。少し先の話になりますが、年末の AWS re:Invent 2026 は 11 月 30 日から 12 月 4 日の開催で、早期割引の申し込み期限は 8 月 25 日です。夏のうちに社内調整を始めておくとちょうど良いタイミングかもしれません！今月は Amazon 自身のロボティクスの最前線をピックアップトピックとしてお届けしつつ、7 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック – Amazon のロボティクスに学ぶ、現場で動く AI 製造業のお客様と自動化についてお話ししていると、「どこまでロボットに任せられるのか」「導入した後に現場が使い続けられるのか」という 2 つの問いに行き着きます。実はこの 2 つは、Amazon 自身がフルフィルメントセンターという巨大な現場で向き合ってきた問いでもあります。今月は Amazon のロボティクスの取り組みを題材に、この問いへのヒントを 2 つの視点から探ってみます。 ロボットは「見る」から「感じる」「言葉で指示される」へ Amazon は 2012 年の Kiva Systems 買収以降、 100 万台を超えるロボット を配備してきました。注目したいのは台数ではなく、指示の与え方が進化してきた点です。搬送ロボットの Proteus は、床の符号マーカーに頼らずセンサーで周囲を認識して自律航行するため、人の立ち入りを制限したエリアを設けずに、人と同じ空間で 400 kg 近いカートを運べます。 2025 年に発表された Vulcan は、Amazon 初の触覚を持つロボットです。力覚フィードバックセンサーで押し付ける力を把握し、商品を壊さない範囲で棚の中をかき分けます。平均 10 点が詰まった棚から、対象品目の約 75% を従業員と同等の速度で扱えるとのことです。この能力は、シミュレーションではなく 実世界の接触データ で学習させて獲得されました。 そして 次世代の Proteus では、 自然言語で指示できる ようになりました。技術コマンドやプログラミングは不要で、優先順位や経路はロボット側が判断します（欧州展開は 2027 年上期予定）。土台にあるのはデータ基盤で、フリート全体を賢くする生成 AI 基盤モデル DeepFleet とオペレーター向けの agentic AI モデル Project Eluna も統合されています。 多品種少量で段取り替えが多い現場では、再プログラミングのコストが自動化の投資回収を難しくしてきました。ティーチングやラダーロジックではなく自然言語が操作インターフェースになる流れは、この構造そのものを変える可能性があります。 自動化の設計に、役割分担と人材投資まで含める もう 1 つの視点は、自動化を人の仕事の変化と一体で設計している点です。Vulcan が担うのは保管品目の約 75% で、残りは人に引き継ぎます。対象も脚立が必要だった約 8 フィートの上段と床付近で、人はエルゴノミクス上望ましい power zone の作業に集中できます。100% 自動化を目指さず、機械に任せる範囲を先に決める割り切りが導入の現実性を担保しています。協働型の搬送システム STARK は現場従業員の改善アイデアから生まれ、2027 年までに欧州 15 拠点への拡大が予定されています。 さらに 欧州での一連の発表 では、拠点の近代化に €10 billion 超という設備投資と、25,000 名の増員、Career Choice への 2030 年までの $1 billion のコミットがセットで語られています。対象分野にはメカトロニクスが明示されており、ロボット導入が保全・信頼性エンジニアという職種を必要とする実態と整合します。設備投資額と人材投資額を同時に示すアプローチは、労働力不足と技能継承を抱える日本の製造業が自動化を社内に説明する際のフレームとして参考になるのではないでしょうか。 直近で開催予定のイベント 9/4 – 9/8 IFA 2026 ヨーロッパ最大のコンシューマーエレクトロニクスの展示会が、ベルリンの Messe Berlin で開催されます。Amazon も Hub 27 にブースを出展予定です。 9/14 – 9/19 IMTS 2026 — International Manufacturing Technology Show 北米最大の工作機械の展示会が、シカゴの McCormick Place で開催されます。AWS もブースを出展予定です。会期中には、量子コンピューティングと製造業をテーマにした AWS 主催イベント「 Beyond AI: Quantum Meets Manufacturing — An IMTS Evening Reception 」も開催されます。 10/13 – 10/16 CEATEC 2026 10 月 13 日（火）から 16 日（金）まで幕張メッセで開催されます。主催は電子情報技術産業協会（JEITA）で、今年のテーマは「Transformation – 企業が、産業が、そして社会が変わる -」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 ぜひブースにお立ち寄りください。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントが米国ネバダ州ラスベガスで開催されます。2,200 を超えるセッションが予定され、そのうち約 70% がインタラクティブな形式です。早期割引価格 $1,299（通常 $2,499）の申し込みは 8 月 25 日 23:59 PDT までですので、お早めにご確認ください！ 製造関連ブログのご紹介 7/1 Reduce P&ID analysis time by 80% with hybrid AI maintenance planning PDF の P&ID（配管計装図）から機器とタグを検出し、Amazon Neptune のグラフで依存関係を表現して保全影響を推論する構成です。パイロットでは計画時間を最大 80% 削減できたとのことで、図面資産の活用を検討されている方の参考になります。 7/6 東海旅客鉄道株式会社：超電導リニアの電気設備保守を支える IoT プラットフォームの構築 ※本記事は「事例のご紹介」でご紹介します。 7/15 【開催報告】AWS Summit Japan 2026 — AI エージェントで危機対応：小売×消費財の混乱を AI と人が即座に解決 サプライチェーンの外乱に対し、AI エージェントが影響分析と代替案提示を行い、人の承認を経て実行まで回すデモの実装解説です。分析専用と実行専用でサブエージェントを分ける設計は、現場でエージェントに実行を任せる際の指針になります。 7/16 AI で変える鉄道保全と、「クローズド」を読み解くクラウド設計 — AWS Summit Japan 2026 展示ブース開催報告 異常検知から調査、対応計画の提示、作業指示書の出力までを 4 ステップで実装した保全プラットフォームの報告です。「クローズドは必ずしも安全ではない」という後半の論点は、製造業の OT セキュリティ設計にそのまま読み替えられます。 7/17 ナレッジグラフと IoT データによる生産ラインのボトルネック分析 〜AI エージェントのための製造データの構造化〜 設備やサプライヤーの関係を Amazon Neptune のグラフに、サイクルタイムなどの変動値を AWS IoT SiteWise に分離する設計の解説です。ISA-95 との対応表もあり、データモデル設計の出発点として参考になります。 7/22 AWS Japan Summit 2026 スマートマシンデモ ー自律診断とリアルタイム安全監視ー 展示報告 建設機械のフリート遠隔監視を題材に、予知保全の 3 つのアプローチを比較しています。異常スコアで終わらず原因推定と対処指示まで生成するエージェントの挙動と、人と AI の役割分担の考え方をご覧いただけます。 7/24 ISA/IEC 62443 を踏まえた AWS での OT とクラウドの接続設計 産業用制御システムのセキュリティ規格を踏まえ、OT ネットワークとクラウドの接続方法を解説しています。工場データの収集を始める方にも、既存構成を監査対応の観点で見直したい方にも実務的な内容です。 事例のご紹介 7/6 東海旅客鉄道株式会社：超電導リニアの電気設備保守を支える IoT プラットフォームの構築 東海旅客鉄道株式会社（JR 東海）との共著記事です。山梨リニア実験線の電気設備で状態監視保全を実現するため、AWS 上に IoT プラットフォームを段階的に構築した事例です。AWS IoT Greengrass のコンポーネントがメーター値の読み取りや動作音の特徴量抽出、異常推論をエッジで実行し、クラウドには集計値と推論結果のみを送信します。学習からモデル配信までを Amazon SageMaker Pipelines と AWS Step Functions で自動化し、MLOps を IoT 運用に統合している点が秀逸です。設置環境が多様な拠点を抱える工場やプラントの保全高度化に参考になります。 製造関連の主要なサービスアップデート 7/20 KNFSD File Cache（プレビュー） AWS 上に高速な NFS キャッシュを構築するオープンソースソリューションです。オンプレミスの NFS エクスポートをマウントして AWS 内に再エクスポートし、頻繁に読むデータをメモリとローカル NVMe にキャッシュします。解析モデルがオンプレミスに残ったままでも CAE をクラウドにバーストできます。 7/23 Amazon Bedrock AgentCore のトレースとログが単一のロググループに統合 従来は分散していたトレースとイベントログが、エージェント単位の単一ロググループに統合されました。エージェントごとに IAM ポリシーとカスタマー管理キーによる暗号化を適用できます。プロンプトに図面や品質データが含まれるケースで鍵と権限を絞れるようになりました。 7/23 AWS Parallel Computing Service がノードライフサイクルアクションに対応 CAE や CFD の実行基盤として使われる Slurm ベースのマネージドサービスで、計算ノードのライフサイクルの任意の時点でカスタムスクリプトを自動実行できるようになりました。共有ストレージのマウントやライセンスサーバーへの接続を、独自 AMI に作り込まずに宣言的に構成できます。 7/24 Claude Opus 5 が Amazon Bedrock で利用可能に 長時間のエージェント処理を想定したモデルで、Bedrock 上ではゼロデータリテンションが既定で有効です。図面や仕様書の解析に適しており、設計情報を扱う際の社内審査を通しやすくする要素になります。同じ 7 月には OpenAI GPT-5.6 系モデルの値下げ も発表されました。 7/27 Amazon Neptune がタグベースアクセス制御（TBAC）に対応 リソースタグと IAM プリンシパルタグを条件に使い、グラフデータベースのデータプレーン操作を制御できるようになりました。クラスターの ARN を列挙せずにアクセス境界を運用できるため、BOM グラフを事業部別・拠点別に分離して運用する際のガバナンス手段になります。 7/27 AWS Glue Data Quality が異常検知とカタログへの結果書き込みに対応 しきい値のルールを書かずに、機械学習による時系列予測で「一意な値の急減」や「行数のスパイク」を検出できるようになりました。結果は Data Catalog に書き戻して SQL で照会できます。あわせて 分布統計への対応 も発表され、品質監査の証跡づくりに活用できます。 7/31 Context Ontology Accelerator が一般提供開始 今月の一番の注目です。企業の業務を機械可読なオントロジーとしてモデル化するオープンソースで、AI が起案し現場の専門家が承認したうえで、W3C 標準のナレッジグラフとして自社で保有します。付属の MCP サーバー経由で任意のエージェントから参照でき、Amazon Neptune と Amazon OpenSearch Serverless で構成されます。設備・工程・品質規格の定義が PLM や MES に散在する状況は多くの現場で共通の課題です。回答根拠がグラフとして追跡できるため、PoC で止まりがちだった工場の AI エージェントを監査可能な形で本番に載せる道筋になります。 最後まで読んでいただきありがとうございました。今月はロボットが「感じる」「言葉を理解する」ようになる話と、企業の業務知識を機械可読なグラフとして持つ話をお届けしました。現実世界で動く AI にはそれを支える文脈のデータが必要という点で、この 2 つは同じ方向を向いているように思います。来月も 月刊 AWS 製造ブログ をよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 松永 充弘 (Mitsuhiro Matsunaga) シニア ソリューションアーキテクト 製造業のお客様を担当するソリューションアーキテクトです。クラウド × データ × AI でお客様のビジネスを支援しています。前職では製造業にて、機器の IoT 化、AI 活用を担当していました。

NTTドコモビジネス株式会社（以下、ドコモビジネス）は、日本最大級のネットワーク展示会である「Interop Tokyo 2026（会場：幕張メッセ、会期：2026年6月10日〜12日）」において構築されるShowNet 1 にContributorとして参加し、docomo business SIGN™を活用したモバイル回線・セキュリティ・データ利活用に関する取り組みを行いました。 本記事では、ShowNet管理網へのセキュアなリモートアクセス環境の構築、脅威検知・フローログを活用したセキュリティ機能の評価、およびMEC 2 /SDPF 3 クラウドサーバーやクラウドサービスと連携したテレメトリデータの収集・可視化についてご紹介します。また、それらの構成や検証内容、検証を通じて得られた知見についても解説します。 はじめに ShowNet 2026におけるdocomo business SIGN™の役割 取り組み①: セキュアなリモートアクセス環境 取り組み②: 脅威検知機能の検証 〜キーサイト・テクノロジー様のThreat Simulatorを用いて〜 取り組み③: データ利活用基盤 ShowNet 2026での知見を踏まえた機能リリース フローログ可視化機能のリリース フレキシブルデータ変換機能（スクリプト変換）のリリース 今後の展望 セキュリティ機能の高度化 データ利活用基盤の強化 おわりに はじめに こんにちは、IoT&フィジカルAIサービス部の小林です。 ドコモビジネスは、「Interop Tokyo 2026」にContributorとして参加し、docomo business SIGN™を活用したセキュアなモバイル基盤とIoT脅威検知およびデータ利活用への取り組みを行いました。 ShowNet エクスターナル図 Copyright (c) Interop Tokyo 2026 ShowNet NOC Team Member and NANO OPT Media, Inc. All rights reserved.引用元： https://www.interop.jp/2026/assets/img/shownet/concept/external-pop-2026-web.pdf ShowNet 2026におけるdocomo business SIGN™の役割 docomo business SIGN™は、モバイル回線・セキュリティ・データ利活用を一体で提供するサービスです。SIGNでは用途に応じて複数の回線メニュー(Value/Advanced) が用意されており、脅威検知をはじめとするセキュリティ機能や、アプリケーション接続機能・MECといったデータ利活用機能を組み合わせて利用できます。 ShowNet 2026では、回線・セキュリティ・データ利活用の機能を組み合わせ、会場のネットワーク構築・運用を支えました。 本記事では、その取り組みの中から、「①セキュアなリモートアクセス環境」「②脅威検知機能の実証」「③データ利活用基盤」という3つのテーマに沿ってその裏側をご紹介します。 取り組み①: セキュアなリモートアクセス環境 1つめの取り組みは、ShowNet管理網に対するセキュアなリモートアクセス環境の提供です。 ShowNetでは、構築期間から会期中にかけて、NOC (Network Operations Center) やSTM (ShowNet Team Member) が多数のネットワーク機器やサーバーの設定変更、監視、障害対応をします。 会場内の機器に常に物理的にアクセスできるとは限らないため、遠隔からでも安全かつ簡単に管理網へ接続できるリモートアクセス環境が求められます。 そこで、遠隔地からでも安全に管理網へ接続し、迅速に運用作業を実施できる環境を提供しました。 今回は、docomo business SIGN™ Valueの閉域SIMを活用し、LTE USBドングルをPCへ接続するだけでShowNet管理網へアクセスできる環境を提供しました。 利用者には、あらかじめ設定済みのSIGN SIM入りUSBドングルを配布しました。 一般的なVPN接続のように専用アプリを起動するといったことが必要なく、USBドングルを挿すだけで、物理的にインターネットから隔離された安全なネットワークへ即座に接続できる構成としています。 「インターネットを通らない強固な閉域性」と「デバイス側の設定が不要な利便性」を両立できる点は、docomo business SIGN™ Valueならではの大きな特長です。 ShowNetでは、運用担当者の利便性を損なうことなく、安全なネットワーク運用を支える基盤として活用しました。 さらに、この環境では、閉域接続に加えて、脅威検知機能とフローコレクター機能も組み合わせました。 脅威検知機能では、不審な通信を検知した際にメールやSIGNコンソールで確認でき、必要に応じて指定した回線の通信を停止することも可能です。 フローコレクター機能では、通信の流れを記録できるため、通信状況の把握やインシデント発生時の調査に活用できます。実際に会期後にはフローログを用いて通信状況を分析したところ、構築期間から会期中にかけてShowNet管理網の利用が増加していたことに加え、利用されていたアプリケーションやプロトコル、通信先などを把握できました。 加えて、構築期間から会期中までの通信傾向を時系列で追跡できたことから、フローログが通信実態の把握や障害・セキュリティインシデント発生時の分析基盤として有効であることも確認できました。 利用者からは、「USBドングルを接続するだけで簡単に利用できた」「通信も安定していた」といった評価をいただいています。 取り組み②: 脅威検知機能の検証 〜キーサイト・テクノロジー様のThreat Simulatorを用いて〜 SIGNの脅威検知機能については、キーサイト・テクノロジー様のThreat Simulatorを用いて、実環境に攻撃トラフィックを流す形での検証にも取り組みました。 これは単なる机上評価ではなく、実際に攻撃トラフィックを発生させた環境で検知性能を確認するという、ShowNetならではの検証です。 Threat Simulatorでは、マルウェアダウンロード通信や既知の脆弱性攻撃を含む疑似攻撃トラフィックを生成し、SIGNによる検知可否を評価しました。 検証の結果、マルウェアダウンロード通信などの不審通信について90%以上の検知を確認でき、実運用環境に近い条件下でもSIGNの脅威検知機能が有効であることを確認できました。 Threat Simulatorで生成した攻撃トラフィックの例 Threat Simulatorで生成した攻撃トラフィックに対するSIGNの脅威検知結果 このように、閉域接続によるセキュアな通信、脅威検知によるリスク対策、フローログによる通信の見える化を組み合わせることで、ShowNetのような実運用に近い環境においても、安全性と運用性を両立したモバイル基盤を提供できることを確認しました。 取り組み③: データ利活用基盤 3つめの取り組みは、モバイル回線直結のIaaS基盤を活用したデータ利活用です。 ShowNetでは、ネットワーク機器や分散GPU基盤から出力されるログやメトリクスを収集し、運用状況の把握や展示での可視化で活用しました。 今回の構成では、SIGN Advanced SIM、MEC/SDPFクラウドサーバー、SIGNのアプリケーション接続機能を利用し、ShowNet網内のテレメトリデータを、SDPFクラウドサーバー上のログ分析基盤へ転送・保存できる環境を構築しました。 また、Splunk製のログ分析基盤がMEC/SDPFクラウドサーバー上で安定して動作することも確認しています。 さらに、AI-Grid 4 の取り組みと連携し、分散GPU基盤の利用率や消費電力をクラウド上で可視化しました。 SIGN Advanced SIMとアプリケーション接続機能を活用することで、個別開発や複雑な接続設定を最小限に抑えながら、短期間でデータ収集・可視化基盤を構築できたことも成果の1つです。 あわせて、パロアルトネットワークス様のPA-415-5GやION-1200-C5G-EXP、フォーティネットジャパン様のFortiGate-51G-5Gといった5G対応機器で、SIGN SIMを用いた接続確認も実施しました。複数ベンダーの機器が混在する環境においても相互接続性を確認でき、新たな活用に向けた知見を得ることができました。 今回の検証を通じて、モバイル回線、MEC/SDPFクラウドサーバー、ログ分析基盤、クラウドサービスを組み合わせることで、ShowNet内のデータを収集・可視化・分析に活用できることを確認しました。 ShowNet 2026での知見を踏まえた機能リリース ShowNet 2026では、実際の運用環境に近いネットワーク上で、モバイル回線・セキュリティ・データ利活用の各機能を検証しました。 その中で、サービスの有効性だけでなく、実運用における課題や改善の方向性も見えてきました。 こうした知見をもとに、Interop会期後にはいくつかの機能をサービスへ反映しています。 フローログ可視化機能のリリース ShowNetでは、フローコレクター機能によって収集したフローログを活用し、SIMごとの通信量分析や通信先分析、時系列分析などを実施しました。 その結果、構築期間から会期中にかけての通信傾向や利用実態を把握できることを確認しました。 一方で、こうした分析にはログの集計や可視化が必要となり、利用者自身が実施するには一定の知識や作業を要することも分かりました。 そこで、これらの課題を踏まえ、Interop会期後にはフローログ可視化機能をリリースしました。 SIGNコンソール上で回線ごとの通信量や通信先、時間帯ごとの通信傾向などを確認できるようになり、ネットワーク利用状況の把握や異常通信の早期発見、トラブル発生時の原因調査に活用できます。 これにより、利用者自身が個別に分析環境を準備することなく、通信状況をより手軽に把握できるようになりました。 フレキシブルデータ変換機能（スクリプト変換）のリリース データ利活用の検証では、SIGN Advanced SIMやアプリケーション接続機能を活用することで、短期間でデータ収集・可視化基盤を構築できることを確認しました。 一方で、複数ベンダーの機器やクラウドサービスと接続する中で、デバイスごとに出力されるテレメトリデータの形式が異なり、データ連携時に変換処理が必要となるケースがありました。 こうした課題に対応するため、Interop会期後にはフレキシブルデータ変換機能（スクリプト変換）をリリースしました。 この機能により、ネットワーク側でデータ形式を柔軟に変換できるようになり、多様なデバイスやクラウドサービスとの連携を容易に実現できるほか、データ活用開始までの工数削減も期待できます。 今後の展望 ShowNet 2026では、実運用に近い環境でモバイル回線、セキュリティ、データ利活用の各機能を組み合わせて検証したことで、サービスの有効性だけでなく、実運用における課題や改善の方向性についても多くの知見を得ることができました。 今後は、今回得られた知見をもとに、セキュリティ機能とデータ利活用機能の両面で、より実運用に寄り添った機能強化を進めていきます。 セキュリティ機能の高度化 セキュリティ面では、脅威検知機能のシグネチャ強化や分析機能の拡充を進めていきます。 今回の検証では、マルウェアダウンロード通信などの不審通信に対する有効性を確認できただけでなく、IoT機器特有の通信傾向を活用した検知の可能性も見えてきました。 IoT機器は通信先や通信パターンが比較的固定的であるため、挙動ベースの分析と組み合わせることで、さらなるセキュリティ強化につなげられると考えています。 データ利活用基盤の強化 データ利活用の面では、構築・連携にかかる負荷のさらなる低減と、多様なデータソースへの対応を進めていきます。 今回のShowNetでは、Splunkによるモニタリング基盤構築や各種クラウドサービスとの接続設定を通じて、データ利活用の導入負荷低減が今後の課題であると認識しました。 そこで、IoTカタログ 5 の拡充やデータ連携パターンのテンプレート化を進め、データ活用をより短期間で開始できる環境の実現を目指しています。 おわりに 今回のShowNet 2026では、docomo business SIGN™を活用し、「セキュアなリモートアクセス環境」「脅威検知機能の実証」「データ利活用基盤」という3つの取り組みに挑戦しました。 実運用に近い環境での検証を通じて、サービスの有効性を確認できただけでなく、実運用上の課題や改善の方向性についても多くの知見を得ることができ、その一部は実際のサービス改善にも反映されています。 今後もShowNetのような実証の場で得られた知見をサービスへ反映しながら、現場の機器やクラウドサービスをより安全に、より簡単につなげられる環境づくりに取り組んでいきます。 docomo business SIGN™についてはこちら ShowNetは、最新のネットワーク技術・ネットワーク機器などを相互に接続し、「5年後、10年後に必要となるネットワークの姿」を示すというビジョンのもとに構築するコンセプトネットワークです。 最先端のアーキテクチャを動態展示するネットワークであり、 同時に来場者や出展社にインターネット接続性を提供するネットワークでもあります。 ↩ MEC（Multi-access Edge Computing）は、利用者やデバイスに近いネットワークのエッジでデータ処理やアプリケーション実行をするコンピューティング技術です。クラウドと比べて低遅延での処理が可能であり、リアルタイム性が求められるIoTや映像分析、AIアプリケーションなどで活用されています。 ↩ SDPF（Smart Data Platform）は、NTTドコモビジネスが提供するデータ利活用プラットフォームです。クラウド、ネットワーク、セキュリティなどの各種サービスを統合的に提供し、企業のシステム構築やデータ収集・蓄積・分析を支援します。 ↩ AI-Gridは、地理的に分散したGPUなどのコンピューティング資源をネットワークで相互接続し、統合的にオーケストレーションするAIインフラストラクチャの概念です。ShowNet 2026では、モバイルネットワークを介して、全国に分散配置されたGPU搭載MEC基盤などと連携しました。 ↩ IoTカタログは、docomo business SIGN™において、IoT環境構築に必要なモバイル回線、ネットワーク接続、データ利活用基盤（Things Cloud、MAXIV等）を組み合わせて提供するサービスメニュー群です。お客さまの用途に応じて必要な構成を選択できます。 ↩