はじめに シンガポールは朝7時。ある財務コントローラーが SAP で月次決算を締めようと急いでいますが、その前にシステム認証が3大陸にまたがって彼女の本人確認を行う必要があります。フランクフルトの彼女のチームは応答の遅さに苦しみ、ニューヨークのセキュリティチームは、本番 SAP システムへの検証されていない接続試行をたった今フラグしたところです。SAP を大陸をまたいで運用するグローバル企業にとって、これは例外ではなく日常的に起こることです。 機密性の高い財務取引、人事記録、サプライチェーンデータが、常にパブリックインターネットを流れています。多くの場合、ビジネスと不正アクセスの間に立ちはだかるのは、ユーザー名とパスワード程度でしかありません。 根本原因はアーキテクチャにあります。SAP S/4HANA が単一の AWS リージョンにホストされている場合、そのリージョンから遠いユーザーは TLS ハンドシェイク時に高いレイテンシーを強いられます。同時に、静的な SAP Fiori アセット（JavaScript、CSS、フォント）は、ネットワークエッジでキャッシュされることなく、オリジンサーバーから繰り返し取得されます。トラフィックが Amazon VPC （Virtual Private Cloud）に到達する前に、誰が接続しているのかを暗号的に保証する仕組みがありません。 Amazon CloudFront は、mTLS（相互 Transport Layer Security）の証明書チェックを各ユーザーに最も近いエッジロケーションへ移すことで、これら両方の課題に対応します。CloudFront はクライアント証明書を検証し、静的な SAP コンテンツをキャッシュし、証明書メタデータを HTTP ヘッダーとして SAP バックエンドへ転送して、X.509 ベースのシングルサインオン（SSO）を実現します。 本記事では、CloudFront、 Elastic Load Balancing の Application Load Balancer（ALB）、SAP Internet Communication Manager（ICM）を用いてこのアーキテクチャを実装する方法を学びます。トラストストアのセットアップ、CloudFront と ALB の設定、SAP プロファイルパラメータの手順を順を追って説明します。読み終える頃には、エッジでユーザーを認証し、その ID を SAP へ安全に伝搬する、動作するソリューションが手元にあることになります。 社内テストでは、オリジンが N. バージニア（us-east-1）リージョンにある場合、シンガポールに所在するユーザーの初回ログイン時間をこのアーキテクチャによって約40〜50%短縮できました。この改善は、CloudFront エッジロケーションでのエッジキャッシュによって SAP Fiori のページ読み込み時間が高速化されたことによるものです。結果はネットワーク経路、ユーザーの所在地、ワークロードによって異なります。本記事後半の検証手順を用いて、ご自身の環境で測定してください。 私たちが継続的に耳にするお客様の課題 私たちのお客様は、ワークショップ、EBC（Executive Briefing Center）、その他の定期的な機会を通じて、以下の課題を継続的に持ち込まれます。 「他国にいる SAP Fiori ユーザーから、ランチパッドが遅いと言われている。」SAP が単一リージョンで稼働している場合、静的な Fiori アセット（JavaScript、CSS、フォント）は、ネットワークエッジでキャッシュされることなくオリジンから繰り返し取得されます。その結果、遠隔地のユーザーはページごとに長く待たされます。 「盗まれたパスワードさえあればインターネット経由で SAP ログインに到達できる、とセキュリティが指摘した。」多くのお客様では、パブリックインターネットと財務・人事・サプライチェーンのデータの間に立ちはだかるのは、ユーザー名とパスワード程度でしかありません。トラフィックが VPC に到達する前に、誰が接続しているのかを暗号的に証明する仕組みがありません。 「当社はグローバル企業だが、SAP システムは1つのリージョンにある。」そのリージョンから遠いユーザーは、ログインのたびに TLS ハンドシェイクで高いレイテンシーを強いられ、月次決算のような時間に追われる業務でその影響が累積します。 「SAP の前段に mTLS 付きの ALB をすでに配置している。なぜそれでは不十分なのか。」リージョン内の mTLS 検証はリージョン内のセキュリティを強化しますが、グローバルなハンドシェイクのレイテンシー、静的アセットのエッジキャッシュ、エッジレベルの DDoS 保護は解決しません。 なぜこれが重要なのか これらの課題を解決することは、単なる技術的な演習ではなく、ビジネス成果を変えるものです。エッジでクライアント証明書を検証することで、不正な接続が VPC に到達する前に拒否するゼロトラストの姿勢を強制できます。これにより、すべてのリモートユーザー向けに VPN インフラを展開・維持することなく、攻撃対象領域を縮小できます。静的な SAP コンテンツをキャッシュし、各ユーザーに最も近い Point of Presence で TLS ハンドシェイクを終端することで、私たちのテストではログイン時間を約40〜50%短縮しました。これは、期限どおりに決算を締める財務コントローラーと、遅いランチパッドで待たされ続ける財務コントローラーとの違いを生みます。そして、ID がパスワードではなく X.509 証明書として運ばれるため、従業員をパスワードレスでフィッシング耐性のあるシングルサインオンへと移行させられます。本記事の残りでは、各コンポーネントの詳細な AWS ドキュメントへのリンクを添えて、これらの課題をどのように段階的に解決したかを説明します。 SAP における mTLS のための CloudFront の利点 ALB はリージョン内で強力な mTLS 機能を提供しますが、ALB の前段に CloudFront を追加することで、SAP ワークロードにいくつかの利点が得られます。 CloudFront は最も近いエッジロケーションでクライアント証明書を検証するため、トラフィックが VPC に入る前に不正な接続を拒否できます。TLS ハンドシェイクは 600 を超える CloudFront の Point of Presence（PoP）のうち最も近い場所で行われるため、ユーザーは地理的な所在地に関わらず低いレイテンシーを体験できます。 SAP WebGUI や SAP Fiori アプリケーションは、JavaScript、CSS、フォントファイルなど大量の静的アセットを配信します。CloudFront はこれらのアセットをエッジでキャッシュするため、オリジンへのリクエスト数が減り、ページの読み込み時間が改善されます。さらに、 AWS Shield と AWS WAF の統合による組み込みの保護も得られ、本番 SAP システムに多層防御を追加できます。 CloudFront はクライアント証明書を検証すると、証明書の詳細を抽出します。そして、それらを HTTP ヘッダー（ CloudFront-Viewer-Cert-\* ）としてリクエストに追加します。SAP ICM インスタンスは CloudFront-Viewer-Cert-Pem ヘッダーを読み取り、X.509 証明書ベースの認証を実行します。これにより、クライアントブラウザへの直接的な TLS 接続が不要になります。 アーキテクチャの概要 次の図は、エンドツーエンドのリクエストフローを示しています。Amazon CloudFront はすべてのクライアント接続のエントリーポイントとして機能します。ALB はオリジンとして動作し、SAP ICM は認証のために転送された証明書メタデータを受け取ります。このアーキテクチャは4つのコンポーネントを使用します。X.509 証明書を持つクライアントブラウザ、mTLS verify モードの CloudFront、HTTPS パススルーモードの ALB、ポート 44300 の SAP ICM です。 図1. 1つのお客様管理 VPC 内での Amazon CloudFront と SAP の展開 リクエストフロー ブラウザに X.509 クライアント証明書をインストールします。 AWS Private Certificate Authority（AWS Private CA） がブラウザ用のこの証明書を作成します。あるいは、他の信頼された認証局を使用することもできます。 ブラウザが CloudFront ディストリビューション（例: democf.awsforsap.com ）に接続します。CloudFront はクライアント証明書を要求し、 Amazon S3 トラストストアに保存された CA 証明書と照合します。 検証に成功すると、CloudFront は証明書メタデータを抽出し、 CloudFront-Viewer-Cert-\* ヘッダーをリクエストに追加します。これには、 CloudFront-Viewer-Cert-Pem に含まれる PEM エンコードされた完全な証明書が含まれます。 CloudFront はリクエストを HTTPS 経由で ALB オリジンへ転送します。ALB は mTLS パススルーモードで動作し、トラフィックを SAP ターゲットグループへ転送します。 SAP ICM はリクエストを受け取り、 CloudFront-Viewer-Cert-Pem ヘッダー（ icm/HTTPS/client_certificate_header_name で設定）を読み取り、クライアント証明書を抽出し、証明書のコモンネーム（CN）を CERTRULE トランザクションを通じて SAP ユーザーにマッピングします。 このソリューションは、RISE with SAP on AWS の VPC に対しても展開できます。次の図は、CloudFront と ALB がお客様管理の VPC で稼働し、RISE with SAP の VPC と統合される同じパターンを示しています。 図2. RISE with SAP VPC と統合された別のお客様管理 VPC 内での Amazon CloudFront と SAP の展開 CloudFront mTLS ビューアー認証 CloudFront は、ビューアー接続に対する相互 TLS 認証を verify モード でサポートします。このモードでは、CloudFront はすべてのクライアントに対し、TLS ハンドシェイク中に有効な X.509 証明書の提示を要求します。CloudFront は、Amazon S3 トラストストアに保存された CA 証明書バンドルと証明書を照合します。 証明書の検証が AWS リージョン内で行われる ALB mTLS とは異なり、CloudFront mTLS の検証は、あなたに最も近いエッジロケーションで行われます。CloudFront は、オリジンのリソースを消費する前に、エッジで不正な接続を拒否します。また、ハンドシェイクが最も近い PoP（Point of Presence）で行われるため、CloudFront は TLS ハンドシェイクのレイテンシーも最小化します。 CloudFront ビューアー証明書ヘッダー mTLS verify モードを有効にすると、CloudFront は次のヘッダーを自動的に生成し、 オリジンリクエストポリシー を通じてオリジンへ転送します。 ヘッダー 説明 CloudFront-Viewer-Cert-Pem リーフクライアント証明書の URL エンコードされた PEM 形式 CloudFront-Viewer-Cert-Subject サブジェクト DN の RFC2253 文字列（例: CN=ferrymul,O=awsforsap,C=SG） CloudFront-Viewer-Cert-Issuer 発行者 DN の RFC2253 文字列 CloudFront-Viewer-Cert-Serial-Number 証明書の16進数シリアル番号 CloudFront-Viewer-Cert-Sha256 クライアント証明書の SHA256 ハッシュ CloudFront-Viewer-Cert-Validity ISO8601 形式の NotBefore および NotAfter の日付 CloudFront-Viewer-Cert-Present 証明書が存在する場合は 1、存在しない場合は 0 CloudFront-Viewer-Cert-Pem ヘッダーは、SAP 統合における鍵となるヘッダーです。これには、SAP ICM が X.509 認証に使用するクライアント証明書の全体が含まれます。 実装手順 実装は4つのフェーズで構成されます。まず、認証局とトラストストアを作成します。次に、CloudFront と ALB を設定します。最後に、転送されたクライアント証明書を受け入れるよう SAP を設定します。以下のセクションで各フェーズを順に説明します。 ステップ1: 認証局とトラストストアの作成 最初のステップでは、PKI（Public Key Infrastructure）の基盤を確立します。ブラウザ認証用のクライアント証明書を作成する自己署名 CA を作成します。CloudFront がエッジで受信クライアント証明書をチェックするために使用する Amazon S3 トラストストアに、CA 証明書をアップロードします。これは mTLS チェーン全体の暗号的な信頼の根（root of trust）であるため、CA の秘密鍵は適切に保護してください。 クイックな概念実証には OpenSSL で自己署名 CA をブートストラップできますし、本番環境ではマネージドで監査可能なソリューションとして AWS Private CA を使用できます。最小限の OpenSSL フローでは、CA を作成し、CloudFront が照合する S3 トラストストアへアップロードし、ブラウザへインポートするための PKCS#12 バンドルとしてパッケージ化されたクライアント証明書を作成します。 # 自己署名 CA を作成（有効期間10年） openssl genrsa -out ca.key 2048 openssl req -new -x509 -days 3650 -key ca.key -out ca.pem -subj "/C=SG/O=awsforsap/CN=awsforsap mTLS CA" \# CloudFront が照合する S3 トラストストアに CA 証明書をアップロード aws s3 cp ca.pem s3://&lt;your-bucket&gt;-trust-store/ca.pem \# クライアント証明書（CN = SAP ユーザー名）を発行し、ブラウザ用に .p12 をエクスポート openssl pkcs12 -export -out client.p12 -inkey client.key -in client.pem -certfile ca.pem マネージドで本番運用に耐える方法と、証明書ライフサイクル全体のガイダンスについては、 AWS Private CA ユーザーガイド および CloudFront での相互 TLS 認証 を参照してください。 AWS Private CA は、CA ごとの月額料金に加えて、発行した証明書ごとに課金されます。自己署名 CA より AWS Private CA を選ぶ前に、 AWS Private CA の料金 を確認してください。 ステップ2: Amazon CloudFront の設定 トラストストアが整ったら、次のステップは、エッジでクライアント証明書をチェックする CloudFront ディストリビューションを作成することです。ここでレイテンシーとセキュリティの利点が実現します。CloudFront の 600 を超えるエッジロケーションで mTLS を終端することで、認証の判断を可能な限りユーザーの近くへ移し、ラウンドトリップ時間を短縮し、不正な接続が VPC に到達する前に拒否します。 CloudFront を設定するには、次の手順を実行します。 以下の手順は流れの要約です。詳細なコンソールのウォークスルーとすべての設定については、 ディストリビューションの作成 、 ディストリビューションでの相互 TLS の有効化 、 オリジンリクエストポリシー 、および CloudFront で ACM 証明書を使用するための要件 を参照してください。 ディストリビューションを作成 します。ALB の DNS 名をオリジンとして指定し、HTTPS のみのオリジンプロトコルと TLSv1.2 を使用します。CloudFront コンソールでディストリビューションに移動し、「ディストリビューションを作成」を選択して、ALB の DNS 名をオリジンドメインとして入力します。 オリジンの読み取りタイムアウトを 60 秒に設定 します。SAP WebGUI はコールドスタート時に応答まで 30 秒以上かかることがあり、デフォルトの 30 秒のタイムアウトでは 504 エラーが発生します。 verify モードで mTLS ビューアー認証を有効化 します。「設定 &gt; ビューアー証明書」で「相互 TLS 認証」を選び、「Verify モード」を選択します。トラストストアを、CA 証明書を含む S3 オブジェクトへ向けます。 カスタムのオリジンリクエストポリシーを作成 し、7つの CloudFront-Viewer-Cert-\* ヘッダーをすべて転送します。CloudFront コンソールで「ポリシー &gt; オリジンリクエスト」に移動し、新しいポリシーを作成して、すべての CloudFront-Viewer-Cert ヘッダーを追加します。すべての Cookie とクエリ文字列を転送します。 キャッシュ動作を設定 します。動的な SAP コンテンツ（デフォルトの動作）はキャッシュをオフにし、静的アセット（\*.js、\*.css、\*.png、\*.jpg、\*.ico、\*.tiff）はキャッシュを最適化します。 カスタムドメイン（例: \*.awsforsap.com）用に AWS Certificate Manager（ACM） 証明書を関連付け 、必要に応じて AWS WAF ウェブアクセスコントロールリスト（ウェブ ACL）をアタッチします。 ステップ3: Application Load Balancer の設定 ALB は、CloudFront と SAP インスタンスの間の橋渡し役を担います。このアーキテクチャでは、ALB は mTLS パススルーモードで動作します。つまり、ALB 自身はクライアント証明書をチェックしません。代わりに、CloudFront がすでに検証した証明書ヘッダーをそのまま通過させます。これにより二重チェックのオーバーヘッドを回避し、SAP が証明書メタデータを直接受け取れるようになります。 ALB を設定するには、次の手順を実行します。 ALB と mTLS パススルー設定の完全なリファレンスについては、 Application Load Balancer での TLS による相互認証 を参照してください。 インターネット向けの ALB を作成 します。少なくとも2つのアベイラビリティーゾーン（AZ）に配置し、少なくとも2つのパブリックサブネットを選択し、両方のサブネットにインターネットゲートウェイへのルートがあることを確認します。 ポート 443 の HTTPS リスナーを作成 します。HTTPS:443 を選び、TLS 1.3 のセキュリティポリシー（例: ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 ）を選択し、mTLS をパススルーモードに設定します。 ターゲットグループを作成 します。HTTPS プロトコル、ポート 44300（SAP ICM HTTPS ポート）を使用します。ヘルスチェックパスを /sap/public/ping 、ヘルスチェックプロトコルを HTTPS に設定します。 SAP インスタンスをターゲットとして登録 し、クロスゾーン負荷分散を有効化します。 ステップ4: SAP S/4HANA の設定 最終フェーズでは、AWS インフラを SAP システムに接続します。CloudFront から ALB を経由して転送される証明書ヘッダーを信頼するよう、SAP ICM を設定します。これでエンドツーエンドの mTLS チェーンが完成します。SAP は HTTP ヘッダーでクライアント証明書を受け取り、直接的な TLS クライアント接続を必要とせずに、それを X.509 ベースの SSO に使用します。 CloudFront からの HTTP ヘッダー転送を通じて X.509 証明書認証を受け入れるために、SAP トランザクション RZ10 で次のプロファイルパラメータを設定します。 これらのパラメータと、関連する SICF、STRUST、CERTRULE の手順は、参照先の SAP Note と AWS の SAP 向け mTLS Security Extension ガイド に記載されています。 パラメータ 値 SAP Note icm/HTTPS/accept_forwarded_cert_via_http TRUE 2805092 icm/HTTPS/client_certificate_header_name CloudFront-Viewer-Cert-Pem 3639967 icm/trusted_reverse_proxy SUBJECT=”&lt;your-ALB-cert-subject&gt;”, ISSUER=”&lt;your-ALB-cert-issuer&gt;” 2805092 さらに、次の SAP 設定を実施します。 CERTRULE トランザクション: クライアント証明書の CN（例: CN=ferrymul ）を対応する SAP ユーザーアカウントにマッピングするルールを作成します。 SICF トランザクション: /sap/bc/gui/sap/its/webgui ICF サービスノードで、ログオン手続きとして SSL クライアント証明書を有効化します。 STRUST トランザクション: SAP があなたの CA が発行した証明書を信頼するよう、ルート CA 証明書を SSL Server Standard PSE にインポートします。 ソリューションの検証 4つの設定フェーズをすべて完了したら、エンドツーエンドの mTLS 認証フローが正しく動作することを検証します。次の手順を使用して、証明書検証、ヘッダー伝搬、SAP 認証が成功していることを確認します。 テスト1: CloudFront mTLS ハンドシェイクの検証 クライアント証明書を使って curl で CloudFront mTLS ハンドシェイクをテストします。 curl -v --cert client.pem --key client.key https://democf.awsforsap.com/sap/public/ping mTLS ハンドシェイクが成功すると、HTTP 200 レスポンスが返ります。証明書が無効または欠落している場合、CloudFront は HTTP 403 を返します。 テスト2: 証明書ヘッダー伝搬の検証 CloudFront のアクセスログを有効にし、オリジンリクエストヘッダーを確認します。レスポンスに期待される証明書サブジェクト（例: CN=ferrymul,O=awsforsap,C=SG）が含まれていることを検証します。 テスト3: SAP 認証の検証 クライアント証明書（.p12 ファイルからインポート）をインストールしたブラウザを起動します。https://democf.awsforsap.com/sap/bc/gui/sap/its/webgui にアクセスします。設定が正しければ、SAP は CERTRULE トランザクションでマッピングされた X.509 証明書の CN を用いて自動的にログインさせます。ユーザー名やパスワードの入力を求められることなく、SAP WebGUI セッションが表示されるはずです。 認証が失敗する場合は、SAP ICM トレース（トランザクション SMICM で「移動」→「トレースファイル」を選択）で証明書ヘッダーの解析エラーを確認してください。 主な違い: SAP における CloudFront mTLS と ALB mTLS の比較 以前のブログ記事「 Elevate User Experience and Security of Application Load Balancer for SAP workloads on AWS 」を参照すると、mTLS verify モードを実装するには2つの選択肢があります。以下は、この2つのアーキテクチャタイプの主な違いです。 観点 ALB mTLS（verify モード） CloudFront mTLS（verify モード） mTLS 終端ポイント リージョナル（VPC 内の ALB） エッジ（最も近い CloudFront PoP） 証明書ヘッダー名 X-Amzn-Mtls-Clientcert CloudFront-Viewer-Cert-Pem 静的コンテンツのキャッシュ 利用不可 \*.js、\*.css、画像のエッジキャッシュ DDoS 保護 AWS Shield Standard エッジでの AWS Shield + AWS WAF グローバルなレイテンシー リージョナル（単一リージョン） 600 を超えるエッジロケーションによる低レイテンシー トラストストアの場所 ALB トラストストア（S3 バックエンド） CloudFront トラストストア（S3 バックエンド） 要件やシナリオに基づいて、どちらの選択肢を実装するかを選べます。SAP をグローバルに運用しており、高いパフォーマンスとセキュリティを必要とするリモートワーカーがいる場合は、mTLS verify モードでエッジキャッシュとセキュリティ緩和策を実行できる CloudFront の機能の利用を検討するとよいでしょう。 運用上の考慮事項 いくつかの運用上の詳細が、このアーキテクチャを本番環境で健全に保ちます。SAP WebGUI はコールドスタート時に応答まで 30 秒以上かかることがあるため、504 Gateway Timeout エラーを避けるには、CloudFront のオリジン読み取りタイムアウトを少なくとも 60 秒に設定します。カスタムのオリジンリクエストポリシーを使用する場合、CloudFront はビューアーの Host ヘッダーを ALB へ転送するため、ALB と SAP バックエンドの両方がそのホスト名を受け入れることを確認してください。証明書ライフサイクルを事前に計画します。クライアント証明書は有効期限前に更新し（年1回が良い頻度です）、CA をローテーションするたびに S3 トラストストアを更新します。設定変更後は、すべてのエッジロケーションが新しい設定を取得できるよう、 /\* に対する CloudFront の無効化（invalidation）を作成します。最後に、すべての ALB サブネットにインターネットゲートウェイへのルートがあることを確認してください。いずれかのアベイラビリティーゾーンでルートが欠落していると、断続的なタイムアウトが発生します。 コストについても計画してください。CloudFront はデータ転送（アウト）とリクエストに対して課金し、ALB は時間あたりの料金に加えて Load Balancer Capacity Units に対して課金します。 Amazon CloudFront の料金 および Elastic Load Balancing の料金 のページを使って支出を見積もってください。 リソースのクリーンアップ テスト後の継続的な課金を避けるため、作成したリソースを逆の順序で削除します。 CloudFront ディストリビューションを削除します。CloudFront コンソールでまずディストリビューションを無効化し、ステータスが「Deployed」に変わるのを待ってから削除します。 ALB とターゲットグループを削除します。 Amazon EC2 コンソールで「ロードバランサー」に移動し、対象の ALB を選択して「削除」を選びます。次に、関連するターゲットグループを削除します。 S3 トラストストアを削除します。S3 バケットから CA 証明書を削除し、この目的のためだけに作成したバケットであれば、バケット自体も削除します。 クライアント証明書を失効させます。AWS Private CA を使用した場合は、発行したクライアント証明書を失効させます。自己署名証明書を使用した場合は、.pem、.key、.p12、.csr ファイルを削除します。 SAP プロファイルパラメータを元に戻します。トランザクション RZ10 で icm/HTTPS パラメータを削除またはリセットします。SAP ICM サービスを再起動します。 このディストリビューションのためだけに作成した場合は、ACM 証明書を削除します。 このディストリビューションのためだけに作成した場合は、AWS WAF ウェブ ACL を削除します。 まとめと次のステップ シンガポールのあの財務コントローラーに話を戻すと、このアーキテクチャによって、彼女の月次ログインはより速くなり、接続は VPC に到達する前に暗号的に検証され、そして彼女は一度もパスワードを入力しません。本記事では、このパターンを推し進めるお客様の課題と、それらを段階的にどう解決したかを見てきました。認証レイテンシーを下げるためにエッジで mTLS を終端し、静的な SAP コンテンツをキャッシュし、組み込みの DDoS 保護を追加しながら、証明書ベースの ID を SAP バックエンドへ伝搬しました。要点を振り返ると、CloudFront mTLS verify モードはエッジでクライアント証明書をチェックし、不正な接続が VPC に到達する前に拒否します。 CloudFront-Viewer-Cert-Pem ヘッダーにより、SAP ICM は直接的な TLS クライアント接続なしで X.509 認証を実行できます。静的な SAP アセットのエッジキャッシュは、グローバルに分散したユーザーのページ読み込み時間を改善します。何より、既存の ALB mTLS パターンと並行して、このソリューションを段階的に採用できます。 このパターンをさらに発展させるには、SAP Fiori ランチパッドアプリケーション向けに CloudFront mTLS を実装してみたり、SAP Gateway OData エンドポイントなど他の SAP サービスに適用してみたりしてください。また、 CloudFront Connection Functions と KeyValueStore の統合を検討し、エッジで証明書失効チェックを実装することもできます。 AWS Well-Architected Framework（SAP Lens） のセキュリティのベストプラクティスに従い、証明書とトラストストアを定期的に更新することをお勧めします。 謝辞 貢献してくれた次のチームメンバーに感謝します: Derek Ewell、Adam Hill、Bhuvan Wadhwa。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

Kiro と ABAP Accelerator を使い、AI-Driven Development Lifecycle（AI-DLC）の手法を適用して S/4HANA 上で SAP ABAP アプリケーションを構築する方法を学びます。ビジネス上の意図から、数週間ではなく数時間で動作するコードへと到達します。 はじめに SAP を運用する組織は、重要なビジネスプロセスを支える数千ものカスタム ABAP プログラムを保守しています。SAP S/4HANA 上で新しいアプリケーションを構築する場合でも、レガシーコードをモダナイゼーションする場合でも、あるいは RESTful ABAP Programming Model（RAP）のようなクリーンコア開発プラクティスを採用する場合でも、課題は同じです。すなわち、従来の開発サイクルは遅く、ドキュメントは乏しく、ビジネス上の意図と実際に動作するソフトウェアとの間のギャップは依然として大きいままです。 SAP 開発における現在の AI アプローチは、2 つの極端に分かれます。AI アシスト開発は、コード補完やドキュメント作成といった個別のタスクを支援するヘルパーとして AI を扱いますが、プロセス全体は依然として人間が主導します。AI 自律開発は AI に完全な制御を委ねますが、エンタープライズ SAP システムの複雑さに直面すると破綻します。どちらのアプローチも、SAP チームが必要とするスピードと品質を実現できていません。 本ブログでは、 AI-Driven Development Lifecycle（AI-DLC） の手法を、 Kiro と ABAP Accelerator とともに用いて、SAP S/4HANA 上にフライト予約アプリケーションを構築する手順を解説します。ビジネス上の意図を捉える Inception フェーズ、ABAP コードを生成する Construction フェーズ、そしてサービスを構成する Operations フェーズまで、AI がプロセスを主導し、各ステップであなたが監督するという AI-DLC ワークフロー全体を通して進めます。 ソリューションの概要 次の図は、AI-DLC の手法と、それが SAP ABAP 開発にどのように適用されるかを示しています。 AI-DLC は、AI をすべての開発活動の中心に据えながら、あなたが主導権を握り続けることを可能にする手法です。AI は詳細な計画を生成し、不確かな点があれば質問を投げかけ、先に進む前にあなたの承認を待ちます。 あなたが AI にタスクの完了を指示するのではなく、AI がワークフローを開始し、ソリューションを提案し、重要な意思決定ポイントであなたの検証を求めます。 この手法は 3 つのフェーズで構成されます。 Inception – AI は、Mob Elaboration と呼ばれる協働プロセスを通じて、あなたのビジネス上の意図を詳細化された要件、ユーザーストーリー、作業単位（Units of Work）へと変換します。 Construction – AI がアーキテクチャ、ドメインモデル、コードを提案し、あなたは Mob Construction を通じて技術選定やアーキテクチャ上の意思決定について方向性を示します。 Operations – AI があなたの監督のもとでデプロイとサービス構成を管理します。 各フェーズは前のフェーズで生成されたコンテキストの上に積み重なり、プロジェクトが進むにつれて AI がより的確な提案を行えるようになります。 AI-DLC の手法、その原則、メンタルモデルをより深く理解するには、 AI-DLC ホワイトペーパー および AI-DLC のブログ記事 を参照してください。 AI-DLC が SAP でどのように機能するか AI-DLC は手法であり、構造化されたワークフローとシステム連携をサポートする AI 対応の IDE であればどれでも適用できます。本ウォークスルーでは、Kiro を使って SAP 開発向けに AI-DLC を実装します。 Kiro と AI-DLC ワークフロー – AI-DLC の各フェーズをオーケストレーションし、セッションをまたいでコンテキストを管理し、すべての意思決定の監査証跡を保持する、構造化ワークフローを備えた AI 駆動の IDE です。 ABAP Accelerator – IDE と SAP システムを橋渡しする Model Context Protocol（MCP）サーバーで、AI による コード生成、SAP ABAP Test Cockpit（ATC）を通じた構文検証、オブジェクトのアクティベーション、そして S/4HANA 環境への直接デプロイを可能にします。 これらのツールを組み合わせることで、あなたが自然言語で構築したいものを記述し、AI がそれを要件とコードに分解し、ABAP Accelerator がライブの SAP システムに対してコードをデプロイ・検証し、あなたが各ステップを承認してから次に進む、というワークフローが生まれます。開発ワークステーションでは、ABAP Accelerator を MCP サーバーとして構成した Kiro を実行し、ABAP Development Tools（ADT）API を介して HTTPS 経由で SAP S/4HANA システムに接続します。このワークフローは、開発者権限を持つ非本番の SAP 環境に対して適用できます。 前提条件 始める前に、次の点を確認してください。 SAP HANA データベースを備えた SAP S/4HANA システム 開発者権限を持つ SAP ユーザー（トランザクション SICF（Internet Communication Framework のサービス構成）へのアクセス権、および $TMP パッケージにオブジェクトを作成できる権限を含む） ABAP Accelerator を MCP サーバーとして構成し、ワークスペースに AI-DLC のステアリングファイル をセットアップした状態の Kiro Operations フェーズ中の手動構成ステップのための SAP GUI または SAP Web GUI へのアクセス ABAP Accelerator のインストールとセットアップについては、 ABAP Accelerator リポジトリ の手順に従ってください。 ウォークスルー: AI-DLC でフライト予約アプリケーションを構築する 本ウォークスルーでは、AI-DLC の手法を適用して SAP S/4HANA 上にフライト予約アプリケーションを構築します。このアプリケーションは、フライト検索、キャンセルおよび払い戻し機能を備えた予約管理、乗客情報の取得、e チケットの生成をサポートし、そのすべてがオブジェクト指向 ABAP（ABAP OO）のバックエンドクラス、HTTP ハンドラー経由の REST API、データアクセス用の CDS ビュー、および JSON ヘルパーユーティリティクラスで構築されています。 ステップ 1: ワークフローを開始する まず Kiro を開き、ビジネス上の意図を自然言語の記述として貼り付けます。意図ステートメントには、構築したいもの、機能スコープ、技術要件、そして明示的にスコープ外とするものを記述します。以下は意図ステートメントの例です。あなたの具体的な要件と SAP 環境に合わせて調整してください。 A modern airline seeks to develop a flight booking platform for online reservations and passenger management. The system must support: - Flight search by origin, destination, date, passengers, and class - Payment processing via credit/debit cards - Booking management with cancellation and refund capabilities - Passenger information capture (name, contact, passport, preferences) - Static pricing from database - E-ticket generation Technical Requirements: - SAP HANA database - ABAP OO backend with business logic classes - REST APIs via HTTP handlers - JSON helper utility class - CDS views for data access Out of Scope: - Multi-user roles, booking modifications, external integrations - Dynamic pricing, multi-language/currency, advanced security HTML 意図を送信すると、Kiro はこれを新しいアプリケーション開発リクエストとして認識し、次のステップである要件分析を提案します。この時点で、Kiro で好みのモデルとコーディングモードを選択して進めます。AI-DLC ワークフローは、各フェーズを通して一貫したパターンに従います。 Kiro が、要件、アーキテクチャ、実装の詳細を明確化するための戦略的な質問を投げかけます。 回答を記入するための Answer: タグ付きのファイルを作成します。 Kiro があなたの回答に基づいてソリューションを提案します。 あなたは Kiro が先に進む前にレビューし、承認または修正します。 このサイクルは各フェーズが完了するまで繰り返されます。Kiro はまた、意思決定を記録し永続的な記録を提供する audit.md ファイルも作成します。 ステップ 2: Inception フェーズ — 意図から要件へ Inception フェーズは、Mob Elaboration を通じてビジネス上の意図を明確に定義された要件へと変換することに重点を置きます。実際のシナリオでは、チーム全体がこのセッションに参加します。プロダクトオーナー、開発者、アーキテクトがリアルタイムで集まり、Kiro の提案を検証します。 Kiro はまず、意図ステートメントの曖昧さを明確化するための一連の要件確認質問を生成します。これらの質問は、機能スコープ、ビジネスルール、エッジケース、技術的制約を対象としています。あなたは生成されたファイル内の Answer: タグを使って各質問に回答し、保存します。回答をレビューした後、Kiro は合意されたスコープを捉えた要件サマリを作成します。 要件を承認すると、Kiro は意図を作業単位（Units of Work）、すなわちフライト検索、予約管理、決済処理、乗客管理といった、まとまりがあり独立して構築可能な機能ブロックへと分解します。各ユニットには受け入れ基準を伴うユーザーストーリーが含まれます。Kiro はまた、ビジネス上の意図と期待される効果のサマリも生成します。あなたはこれらの成果物をレビューし、必要に応じて調整し、承認して Construction フェーズへ進みます。 注: スクリーンショットは説明のためのものです。実際の出力は、ワークフロー全体を通じたあなたの具体的な意図ステートメント、回答、意思決定によって異なります。 ステップ 3: Construction フェーズ — 要件からコードへ Construction フェーズは、検証済みの要件を、構造化された設計と生成のステップの連なりを通じて、動作する ABAP コードへと変換します。 アプリケーション設計 Kiro はまず、あなたの要件を技術設計へと変換します。ドメイン駆動設計の原則を用いてコアなビジネスロジックをモデリングし、エンティティ、それらの関係、そして非機能要件を満たすために必要なアーキテクチャパターンを特定します。あなたは設計の出力を注意深くレビューします。ここは、コードが生成される前に、Kiro があなたのビジネスロジックを正しく解釈しているかを検証する場所です。 ユニット生成とコード生成 設計が承認されると、Kiro は作業単位（Units of Work）を生成し、基盤となるユニットから始めて依存するユニットへと進みながらコード生成を開始します。ここで ABAP Accelerator が重要な役割を果たします。SAP システムに直接 ABAP オブジェクトを作成し、構文チェックを実行し、カスタムバリアントに対して ATC 検証を実行し、オブジェクトのアクティベーションを自動的に処理します。ATC が生成コードに問題を検出した場合、ABAP Accelerator はコードを修正し、チェックが通るまで複数のサイクルを繰り返します。 注: スクリーンショットは説明のためのものです。実際の出力は、ワークフロー全体を通じたあなたの具体的な意図ステートメント、回答、意思決定によって異なります。 このプロセス全体を通じて、あなたは生成されたコードとテストシナリオをレビューします。AI-DLC は Inception フェーズにおけるあなたの具体的な回答と意思決定に基づいて手順とアプローチを調整するため、参加者ごとにワークフローは異なります。Construction フェーズは、SAP システムにデプロイ・アクティベートされた生成成果物 – ABAP クラス、HTTP ハンドラー、CDS ビュー、テストケース – のサマリで締めくくられます。 注: スクリーンショットは説明のためのものです。実際の出力は、ワークフロー全体を通じたあなたの具体的な意図ステートメント、回答、意思決定によって異なります。 ステップ 4: Operations フェーズ — コードから稼働するサービスへ Operations フェーズは、動作するアプリケーションを稼働するシステムへと変換します。SAP のデプロイは、一般的なクラウドネイティブのワークフローとは異なります。継続的インテグレーションと継続的デリバリー（CI/CD）のパイプラインではなく、ABAP トランスポートシステム、オブジェクトのアクティベーション順序、そして Internet Communication Framework（ICF）のサービス構成に依存します。 ICF サービス構成 ABAP の HTTP ハンドラーを REST API として公開するには、SAP で ICF サービスノードを構成します。ABAP Accelerator がコード生成とアクティベーションを処理する一方で、ICF サービスノードの作成には SAP トランザクション SICF での手動ステップが必要です。Kiro は、作成が必要な各サービスについて、サービス名とハンドラークラスの割り当てを含む詳細な手順を提供します。Kiro が提供するガイダンスに従って、各 ICF サービスを作成、構成、アクティベートしてください。ICF サービスを構成・アクティベートした後、サービスの準備が整ったことを Kiro に伝えます。Kiro は構成を検証し、Operations フェーズを完了としてマークします。 ステップ 5: アプリケーションをテストする ICF サービスがアクティベートされたら、アプリケーションをエンドツーエンドでテストできます。Kiro に、API をテストするためのシンプルなフロントエンドの生成を依頼します。ベース URL が SAP システムと一致していること、そして ICF サービスパスが SICF 構成と整合していることを確認してください。各 API を順番にテストします。読み取りと検索の操作から始め、次に作成操作、続いて依存する操作、最後にキャンセルと削除の操作をテストします。 注: スクリーンショットは説明のためのものです。実際の出力は、ワークフロー全体を通じたあなたの具体的な意図ステートメント、回答、意思決定によって異なります。 実証された主要な機能 本ウォークスルーは、AI-DLC を従来の SAP 開発アプローチと差別化するいくつかの機能を示しています。 あなたがコードを書いて AI に助けを求めるのではなく、AI が計画を提案し、明確化のための質問を投げかけ、あなたが検証した後にのみソリューションを実装します。このパターンは、要件の詳細化からコード生成、テストに至るまで、あらゆる活動で繰り返され、一貫性のある監査可能なワークフローを生み出します。 ABAP Accelerator は、SAP 環境に直接接続することでシステムを認識したコード生成を提供します。構文チェックを実行し、ATC 検証を実行し、オブジェクトのアクティベーションを自動的に処理します。AI がライブシステムに対してコードを検証するため、生成されるコードは SAP の標準とお客様の組織のガイドラインの両方を満たす可能性が高まります。 あらゆる意思決定、回答、承認は、プロジェクトリポジトリ内の構造化されたファイルに記録されます。これにより、AI が各フェーズをまたいで参照する永続的なコンテキストと、チームがいつでもレビューできる恒久的な監査証跡が生まれます。 フェーズをまたいだコンテキストの蓄積も、もう一つの重要な利点です。各フェーズが前のフェーズの成果物の上に積み重なるため、プロジェクトが進むにつれて AI の提案はますます的確になります。コード生成に到達する頃には、AI はあなたの要件、設計上の意思決定、アーキテクチャ上の選択のコンテキストを把握しています。 メリット AI-DLC を SAP 開発に適用することで、開発のスピードを加速できます。AI が定型的な計画立案、設計の骨組み作成、コード生成を担う一方で、あなたは検証と意思決定に集中できます。これにより、あなたの時間は繰り返しのコーディング作業から、重要な問題解決とビジネスロジックの洗練へとシフトします。 AI が ABAP Accelerator の ATC 連携を通じて、お客様の組織のコーディング標準、設計パターン、セキュリティ要件を一貫して適用するため、品質が向上します。ワークフロー全体を通じた継続的な明確化により、要件の抽象的な AI 解釈ではなく、あなたが意図したものを確実に構築できます。生成されたテストスイートは、アプリケーションライフサイクル全体にわたる回帰テストのための恒久的な資産となります。 このアプローチは、モダンな SAP 開発プラクティスの学習曲線も緩やかにします。RAP を採用する場合でも、S/4HANA へ移行する場合でも、新しいアプリケーションを構築する場合でも、AI-DLC は各実装ステップの背後にある意思決定を説明しながらプロセスをガイドします。 AI-DLC を SAP で活用するためのベストプラクティス 意図ステートメントを書く際は、機能要件、技術的制約、そして明示的にスコープ外とするものについて具体的に記述してください。意図が正確であるほど、AI が必要とする明確化のサイクルは少なくなり、生成される成果物はより正確になります。対象とする SAP 環境、優先するプログラミングモデル、組織のコーディング標準に関する詳細を含めてください。 Inception フェーズでは 、AI の明確化のための質問に丁寧に回答することに時間を投資してください。これらの回答は、後続の要件、設計、コードのすべての基礎となります。Answer: タグは、AI がプロジェクト全体を通じて参照する恒久的な記録を作成するため、じっくりと記入してください。 Construction フェーズでは 、承認する前に生成された各成果物をレビューしてください。特にドメインモデルとアーキテクチャ上の意思決定に注意を払ってください。これらはコードベース全体を形作るものです。AI の提案があなたの期待と一致しない場合は、一般的な修正ではなく具体的なフィードバックを提供してください。フィードバックが的確であるほど、AI はより速く正しいソリューションに収束します。 Operations フェーズでは 、Construction フェーズ中に Kiro が生成するビルド手順を参照してください。これらの手順には、ICF 構成に必要なサービス名とハンドラークラスの割り当てが記載されています。SICF でサービスをアクティベートする前に、各エントリを生成コードと照合して確認してください。 AI-DLC を SAP ランドスケープ全体にスケールさせる際は、まずパイロットアプリケーションから始めて、あなたとチームがワークフローに慣れるようにしてください。学んだ教訓を記録し、一般的なアプリケーションパターン向けに意図ステートメントのテンプレートを洗練させます。経験を積むにつれて、新しいアプリケーション開発からレガシーのモダナイゼーション、S/4HANA 移行まで、ますます複雑なシナリオに AI-DLC を適用できます。 クリーンアップ ウォークスルーの完了後、不要になった場合はトランザクション SICF で作成した ICF サービスを非アクティブ化してください。SAP システムを通じて、ローカルパッケージ（$TMP）から ABAP オブジェクトを削除します。 まとめ 本ブログでは、Kiro と ABAP Accelerator を用いて AI-DLC の手法を適用し、ビジネス上の意図ステートメントから完全な SAP ABAP アプリケーションを構築する方法を学びました。このワークフローでは、AI が要件を詳細化する Inception フェーズ、AI がシステムを認識した検証とともに ABAP コードを生成・デプロイする Construction フェーズ、そしてあなたが ICF サービスを構成してアプリケーションを REST API として公開する Operations フェーズを通過しました。 AI がワークフローを主導し、あなたは監督を行い重要な意思決定を下します。ABAP Accelerator の SAP システムとの直接連携と組み合わせることで、このアプローチは継続的な ATC 検証と自動テストを通じてコード品質を維持しながら、開発時間を大幅に短縮できます。 本ブログで示したアプローチは、新しいアプリケーション開発にとどまりません。同じ AI-DLC ワークフローと ABAP Accelerator を、SAP ECC から S/4HANA へのコード変換、レガシー ABAP のモダナイゼーション、RAP の採用、そしてクリーンコアな S/4HANA 上でのカスタム開発にも利用できます。原則は一貫しています。すなわち、AI 駆動の計画立案、人間による検証、システムを認識したコード生成、そして継続的な品質チェックです。以下のリソースから始めてみてください。 次のステップ SAP 開発向けの AI-DLC を始めるには、以下のリソースをご確認ください。 手法を包括的に理解するために AI-DLC ホワイトペーパー をお読みください。 ABAP Accelerator をインストールし、SAP 環境に接続してください。 Kiro をダウンロードし、AI-DLC ワークフローで構成してください。 ガイド付きのハンズオン体験については、 SAP ABAP Application Development with AI-DLC ワークショップ に取り組んでください。 AI-DLC をお客様の組織の SAP 開発ニーズに合わせてどのように調整できるか、AWS アカウントチームにご相談ください。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

Kiro の使い方を 1 週間で一気に学ぶオンラインチャレンジ「 Kiro University Challenge 」が開催されています。毎日公開されるレッスンで Kiro の機能を学び、学んだ内容を盛り込んだプロジェクトを最終課題として提出すると、Kiro のクレジットを獲得できます。最大 5,250 クレジットです。 参加費は無料で、Kiro の無料プランでも 7 つの必須レッスンすべてに取り組めます。学生限定でも AWS 契約者限定でもなく、誰でも参加できます。日本からの参加も対象です。 スケジュール チャレンジ期間は 2026 年 9 月 21 日 9:00 PT から 10 月 5 日 23:59 PT まで。原文の時刻はすべて太平洋時間 (PT) 表記なので、日本時間 (JST) を併記します。 日付 (PT) 公開されるもの 日本時間 9/21 (月) レッスン 1〜2 9 月 22 日 (火) 0:00 9/22 (火) レッスン 3〜4 9 月 22 日 (火) 16:00 9/23 (水) レッスン 5〜6 9 月 23 日 (水) 16:00 9/24 (木) レッスン 7 + ボーナスレッスン 2 本 9 月 24 日 (木) 16:00 9/25 (金) 最終課題の受付開始 9 月 25 日 (金) 16:00 10/5 (月) 23:59 最終課題の提出期限 10 月 6 日 (火) 15:59 レッスンは全部で 7 本、これに任意のボーナスレッスンが 2 本加わります。レッスン自体は提出も採点もされません。採点対象は最終課題 1 本だけで、その 1 本が 7 つのレッスンすべての観点で評価されます。 レッスンの一部は特定の Kiro サーフェスに固有の内容です。たとえばレッスン 4 は Kiro IDE 限定です。IDE、CLI、Kiro Web のうち 1 つしか使ったことがない方は、これを機に別のサーフェスを試してみてください。 クレジットの配点 クレジットは、最終課題の中で実際に使って見せられたレッスンの数に応じて決まります。 マイルストーン クレジット レッスン 1〜3 各 250 クレジット、最大 750 レッスン 4〜5 各 500 クレジット、最大 1,000 レッスン 6〜7 各 1,000 クレジット、最大 2,000 必須レッスン 7 本すべてを最終課題に含める 1,000 クレジットの完走ボーナス ボーナスレッスン 1 (有料プラン限定) 250 クレジット追加 ボーナスレッスン 2 250 クレジット追加 最大合計 5,250 クレジット 7 本の必須レッスンは、いずれも無料プランで利用できる機能を扱います。ボーナスレッスン 2 本のうち 1 本は有料プラン限定、もう 1 本はすべての Kiro ユーザーが対象です。ボーナスレッスンは 1,000 クレジットの完走ボーナスの条件には含まれません。 獲得したクレジットは、賞の配布後から 2026 年 11 月 30 日 23:59 PT まで引き換えでき、引き換え後は使い切るか 2027 年 3 月 31 日 23:59 PT に失効するまでアカウントに残ります。クレジットは譲渡や現金への交換はできません。 参加条件 18 歳以上 Kiro アカウントを持っていること X または LinkedIn のアカウントを持っていること 参加に使う GitHub アカウントが作成から 3 か月以上経過していること 1 人 1 エントリー、個人での参加 (チーム参加は不可) アルゼンチン、オーストラリア、ブラジル、香港、インドネシア、イタリア、マレーシア、フィリピン、タイ、ベトナム、シンガポール、ロシア、キューバ、イラン、北朝鮮、シリア、ベラルーシ、クリミア地域、いわゆるドネツク人民共和国地域 (DNR)、いわゆるルガンスク人民共和国地域 (LNR)、アラブ首長国連邦に居住する方は対象外です。日本はこのリストに含まれていないため、日本在住の方は参加できます。 AWS の従業員とその同居家族・世帯構成員は参加対象外です。 提出物の要件 最終課題は「動くもの」を 1 本提出します。静的なモックアップは対象外です。提出には次のすべてが必要です。 自分が所有する 公開 GitHub リポジトリにコードをプッシュする リポジトリに .kiro フォルダーを含め、各レッスンの機能をどう設定したかがわかる状態にする 30 秒〜3 分のデモ動画を撮る (3 分を超えた部分は審査されません) X または LinkedIn に公開投稿し、 #KiroUniversity と #BuildWithKiro を付け、X では @kirodotdev 、LinkedIn では @kiro をタグ付けする。投稿には公開リポジトリのリンク、2〜3 文の説明、デモ動画を含める チャレンジのページ のエントリーフォームから、リポジトリのリンク、デモ動画、SNS 投稿のリンク、各レッスンをどう取り込んだかの説明を提出する エントリーフォームのメールアドレスは、クレジットの受け取り連絡先になります。ここを間違えると受け取れません。 失格になりやすいポイント 規約の中で、後から取り返しがつかないものを挙げておきます。 リポジトリの最初のコミットが 9 月 21 日 9:00 PT (日本時間 9 月 22 日 1:00) 以降であること。 チャレンジ期間の開始前にコミットがあるリポジトリは失格の対象です。手元にある既存プロジェクトの続きでは参加できず、チャレンジ期間中に新しく始めたプロジェクトが必要です 提出締切後、審査が終わるまでコミットしないこと。 10 月 5 日 23:59 PT の締切後は、2026 年 10 月 19 日 23:59 PT の審査完了、または受賞メールの受信のうち早いほうまで、コミットを追加できません GitHub アカウントと SNS アカウントは 1 対 1 で対応させること。同じ GitHub アカウントを複数人・複数の SNS アカウントで使った提出は失格の対象です リポジトリが非公開、 .kiro フォルダーやレッスンに必要なファイルの欠落、プロジェクトが説明どおりに動かない、SNS 投稿に指定のタグやハッシュタグ・リンクがない、これらはいずれも失格事由です 公開済みのレッスン レッスンは チャレンジのページ 、X の @kirodotdev 、LinkedIn の @kiro 、そして Kiro Discord サーバー の #kiro-university-challenge チャンネルで公開されます。本記事の公開時点で出ているレッスン 1・2 を紹介します。以降のレッスンは上記のチャンネルで順次公開されます。 レッスン 1: Spec-driven development (250 クレジット) Feature Specs は、新機能を作るための構造化されたアプローチです。要件の洗い出し、技術設計、実装計画の順に進めていきます。複雑な機能、複数ステップの実装、共同作業のプロジェクト、要件や設計を何度も練り直す必要がある機能に向いています。 WHEN a user submits a form with invalid data THE SYSTEM SHALL display validation errors next to the relevant fields この例では、EARS (Easy Approach to Requirements Syntax) 記法を使って、フォームバリデーション機能の要件を構造化されたテスト可能な形で書いています。Kiro にアイデアを渡して spec にしてもらうときは、好みの記法でも、単なる自然言語でもかまいません。詳しくは Specs のドキュメント を参照してください。 レッスン 2: Steering documents (250 クレジット) ~/.kiro/steering/ ディレクトリーに置いた Markdown ファイルを通して、Kiro にプロジェクトの知識を持たせ続けられます。Steering ファイルは Kiro の振る舞いを規定するので、毎回同じ指示を繰り返さなくても、Kiro の出力が自分たちのパターン・ライブラリー・基準に沿ったものになります。 Create a steering file to enforce [insert a convention or standard you want Kiro to enforce], so that [insert context for Kiro to understand your intent behind this prompt]. For example, [insert example of this convention or standard as a code output] ensures [repeat initial convention or standard] is followed. これは steering ファイルを作るためのテンプレートプロンプトです。1) Kiro に守らせたい基準や規約を定義する、2) なぜそれを守らせたいのかという意図を文脈として伝える、3) コードの例で比較を示して守らせる精度を上げる、というベストプラクティスに沿っています。詳しくは Steering のドキュメント を参照してください。 まずはここから チャレンジのページ で公開済みのレッスンを確認し、 Discord の #kiro-university-challenge チャンネルに参加してください。最終課題の提出は 9 月 25 日 16:00 (日本時間) に開始、締切は 10 月 6 日 15:59 (日本時間) です。新しいプロジェクトを 1 つ、Kiro をメインの開発ツールとして作ってください。 Kiro をまだ使っていない方は ダウンロードページ から始められます。 参加にあたっては購入の必要はありません。法律で禁止されている地域は無効です。参加条件・提出要件・クレジットの扱いの詳細は 規約 をご確認ください。受賞者リストはチャレンジ終了後最大 1 年間 こちらのページ で公開されます。 この記事は Kiro の Kiro University Challenge のページを日本語向けに再構成したものです。日程・条件は本記事公開時点の内容です。最新の情報は原文をご確認ください。

低コストでバースタブルな新しい Amazon EC2 インスタンス T8i の一般提供開始をお知らせします。Amazon EC2 T8i は AWS 専用にカスタマイズされた第 6 世代インテル Xeon スケーラブルプロセッサ (Granite Rapids) を搭載しています。T8i インスタンスは最も低価格な EC2 インスタンスのひとつとなり、前世代の T3 インスタンス と比較して最大 30% 優れた料金パフォーマンスを提供します。T8i インスタンスは、CPU 使用率が低から中程度のさまざまなワークロード (フリーミアムサービス、トレーニングおよびデモ環境、ステージングと開発、データ処理、マイクロサービス、低トラフィックの Web サイト、ログインゲートウェイなど) を実行するように設計されています。 T8i インスタンス T3 インスタンスは、小規模かつ費用対効果の高いコンピューティング構成が求められる軽量ワークロードの実行において、非常に多くのお客様から利用されています。これには、マイクロサービスアーキテクチャ、低トラフィックの Web サイト、開発およびテスト環境、小規模データベース、データ処理ジョブ、短時間のコンピューティングタスクなどが含まれます。こうしたお客様の多くからは、T ファミリーのバースタブル性能モデルが好まれています。このモデルでは、ベースラインレベルの CPU パフォーマンスが提供され、必要に応じて CPU クレジットを使用してベースラインを超えるバーストが可能です。 インフラストラクチャのモダナイズや、オンプレミス環境からの移行、イベント駆動型およびマイクロサービスアーキテクチャの採用、さらには AI 推論ワークロードの実験を進める中で、お客様から次の 3 点が求められています。それは、1. コスト最適化された新世代の小規模インスタンス、2. 総所有コストを削減できる優れた価格パフォーマンス、3. 既存の知識とツールを活用できるシームレスな移行パスです。 T8i インスタンスはこうした要望にお応えします。 最大 30% 優れた料金パフォーマンス。 T8i インスタンスは、 AWS Nitro System を基盤とし、カスタムの第 6 世代インテル Xeon スケーラブルプロセッサー (Granite Rapids) を搭載。最大 30% 優れた料金パフォーマンスにより、総所有コストの削減を実現します。 最大 70% 向上したコンピューティング性能。 T8i インスタンスは、T3 インスタンスと比較してコンピューティング性能が最大 70%、ネットワーク帯域幅は最大 1.25 倍、EBS 帯域幅は最大 2.4 倍に向上しています。 T3 からのシームレスなアップグレード。 すでに T3 をお使いのお客様は、T8i へのアップグレードが簡単です。T8i では、お客様がすでに使い慣れた CPU クレジットシステムと軽量コンピューティングオプションをそのままご利用いただけます。T3 から T8i に変更するだけで、より高いコストパフォーマンスが得られます。 高いコスト効果で新規に始めやすく。 AWS を初めて利用するお客様やオンプレミスから移行されるお客様にとって、T8i インスタンスは、低～中程度の CPU 使用率が必要なワークロードの実行のほか、バッチ処理、イベント駆動型関数、CI/CD パイプラインなどの短期間のコンピューティングタスクの実行において、最もコスト効果の高いエントリーポイントの一つとなります。 インスタンスの仕様 T8i インスタンスには 4 つのサイズがあり、いずれも 2 つの vCPU をシングルコアで提供します。次の表は、仕様をまとめたものです。 インスタンスサイズ vCPU メモリ (GiB) ベースラインパフォーマンス/vCPU (%) 1 時間あたりの CPU クレジット獲得数 ネットワーク バースト 帯域幅 (Gbps) t8i.nano 2 0.5 5 3 最大 6.25 t8i.micro 2 1 10 6 最大 6.25 t8i.small 2 2 20 12 最大 6.25 t8i.medium 2 4 20 12 最大 6.25 T3 と同様、T8i インスタンスは 1:0.25、1:0.5、1:1 といった、他の EC2 インスタンスにはない、独自の vCPU 対メモリ比率を提供します。また T3 と同様、CPU クレジットシステムを採用しており、 Standard モードおよび Unlimited モードの 2 つのクレジット設定モードを利用できます。T8i ではデフォルトで Unlimited モードが有効です。 T8i で提供されるサイズ ( nano 、 micro 、 small 、 medium ) よりも大きなインスタンスが必要なワークロードには、 M8i Flex インスタンス をお勧めします。これは、同等の前世代の T3 インスタンスと比較して最大 30% 優れた価格パフォーマンスを提供するとともに、 16xlarge までスケールアップできる柔軟性を備えます。 今すぐご利用いただけます Amazon EC2 T8i インスタンス は現在、以下の AWS リージョンでご利用いただけます: 米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、アジアパシフィック (ハイデラバード、マレーシア、ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ)。リージョンごとの提供状況と今後のリージョン拡張については、 AWS Capabilities by Region の CloudFormation リソースタブでインスタンスタイプを検索してください。 T8i インスタンスは、 オンデマンドインスタンス および スポットインスタンス で購入でき、Savings Plan オプションは近日提供予定です。T8i インスタンスは共有テナンシーのみをサポートしており、Dedicated テナンシーや専有ホストはサポートしていません。 t8i.micro インスタンス および t8i.small インスタンス は、 AWS 無料利用枠 でもご利用いただけます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 T8i インスタンスを Amazon EC2 コンソール でお試しいただき、 AWS re:Post for EC2 または通常の AWS サポート窓口までフィードバックをお寄せください。 — Channy 原文は こちら です。

先週、Kiro Crew をフルタイムで開発している私たち3人は、7日間で 1,000 件の pull request をマージしました。1日あたり 120 件を超え、そのすべてが CI とレビューを通っています。Kiro Crew は、このフルタイムのエンジニア3人を中心に、500 人近い熱心なコミュニティコントリビューターとともに開発されています。 この数字を狙っていたわけではありません。並行して開発を進めるやり方が次々に限界にぶつかり、それを越えるたびに少しずつ到達した結果です。ボトルネックにぶつかるたびに、1人がより多くのセッションを回せる新しい進め方が生まれました。振り返ると、その変化は5つの段階に整理できます。最新の段階が、私たちが Crew Mode と呼んでいるものです。コーディングエージェントを使っているなら、あなたもこの梯子のどこかにいます。そして今いる段階が、次に壊れるものを教えてくれます。 図 1: 5つの段階、1人の人間。変わったのはセッション数だけです。 段階 1: 1セッション、手作業。 開発者1人、エージェント1つ、CLI または IDE の中。自分の注意力がシングルスレッドだと気づくまでは、これで足ります。エージェントはすべてのステップの合間にあなたを待つので、あなたがボトルネックです。 段階 2: 複数セッション、手作業。 2つ目のタブを開き、3つ目を開きます。午後いっぱいくらいは助かります。やがて、どのタブでも同じプロジェクトの説明を繰り返し、どのタブが何をしているかを頭の中で管理していることに気づきます。セッションは互いのことを何も知らないので、それらをつなぐのはあなただけです。 段階 3: memory、ダッシュボード、cron、workflow。 Kiro Crew が本格的に始まったのはここです。memory によって、セッションは温まった状態で始まるようになりました。ダッシュボードによって、複数セッションの追跡が容易になりました。cron と monitor ループは、人の手を介さずにセッションを開始し始めました。workflow は、固定のものも動的に生成されるものも、1つのジョブのステップを複数のセッションにまたがってつなぎ、人間が1ステップずつ手でたどらなくてよいようにしました。これで1人が 10〜20 のアクティブなセッションを扱えるようになりましたが、その作業全体を調整するものではありませんでした。workflow のステップは、依然としておおむね順番に実行されます。cron はスケジュールで起きるのであって、別のセッションが終わったときに起きるわけではありません。セッションは別々のタスクやプロジェクトを担当できますが、更新をすべて読んで次に注意を向ける先を選ぶのは、人間のままでした。 段階 4: agent pipeline。 CI のパイプラインではなく、一般的な作業を対象にしたエージェントセッションの組み立てラインです。triage、実装、レビュー、マージがそれぞれ独立したステージとして自分のセッションを持ち、メッセージキューを通してのみ連携します。どのステージも他を待ちません。各ステージは自分のキューに項目が入った瞬間にそれを取り、互いのことを知らないまま、全ステージが同時に動き続けます。対して workflow は、ステップ3がステップ2を待つ鎖です。1人で 20 の同時セッションを超えられたのは、この pipeline のおかげでした。残る課題は、pipeline が人間の設計した固定の形だという点です。結果が計画を無効にしたときに再計画できず、人間が計画を書き直して、影響を受けた作業を振り直す必要があります。 段階 5: セッションをエージェント的に運用する。 ここまでの仕組みで、1人がおよそ 20 の同時セッションを扱えます。50 に近づけると、今度は人間の入力が限界になります。どのセッションにも、ゴールを定義し、起動し、問題を見張り、結果を判断し、次に何をするか決める人が必要です。この5つを 50 セッション分こなすと、それ自体がフルタイムの仕事になります。 図 2: セッション単体は安くなりましたが、その周りの雑務は人間のものでした。Crew Mode がそれを引き受けるまでは。 Crew Mode は、どの単一セッションの外側にも属さないエージェントで、この手作業を自分でこなします。あらかじめ描かれた形をたどるのではなく、セッションの境界をまたいで結果に反応します。セッションは、Crew Mode が作り、初期情報を与え、見張り、閉じる実行単位になります。人間が持つのはゴールです。先週の数字は、pipeline と Crew Mode の初期バージョンが組み合わさって出たものです。開発は今も続いています。 これはどこで動くのか。プロセスが動く場所ならどこでも動きます。crew は1つの gateway とそれが所有するセッションの集まりであり、どのマシンの上にいるかを気にしません。現在、私たちの crew はラップトップ、EC2 インスタンス、クラウド開発デスクトップ上で動いており、今後は Fargate コンテナでも動く予定です。私自身は6〜10 台のマシンを同時に動かし、すべてを1つのダッシュボードから繋いでいます。合わせて 30〜50 のセッションが同時に稼働し、issue の triage、pull request 用のコード作成、レビュー、マージを進めています。crew が受け渡すエージェントジョブは、GitHub Actions や CodeBuild 上でも動きます。 crew 間の協調については早い段階で議論し、「将来の課題」として整理していました。その必要性を具体的にしたのが Crew Mode です。Crew Mode の調整役エージェントは、アクティブなセッションをすべて巡回してブロックされた作業を見つけ、結果を確認し、計画を更新します。50 セッションを超える規模になると、この調整役エージェント自体が次のボトルネックになります。コンテキストを失うこともあり、必要な専門性を持っていないこともあります。スーパーマネージャー1体では、この問題は解けません。役割、スコープ、協調の仕方が異なる複数のエージェントが必要です。1体が計画し、別の1体が実行し、さらに別の1体がレビューする、という形です。そのうえで crew 同士が結果を交換し、作業を互いにルーティングできるようになります。これを設計できたのは、監督役1体がスケールしなくなるのを見たあとでした。 私たちが本当に重視していること 「エージェントがエージェントを運用する」という言い回しは、まさに誇張を招きやすい類のものです。ですから率直に書きます。私たちのゴールは、現場のエンジニアが信頼できる機能を作ることです。現在の開発の大半は、Crew Mode を安全でガバナンス可能にすることに向いています。新しく派手な解決策を発明しようとしているわけではありません。複数のエージェントが自分のために働き始めると、4つのガバナンス上の問題が中心にきます。 エージェント間の調整。 誰が何を依頼し、どのタスクを誰が持ち、何を試して却下したか。これがモデルのコンテキストの中にだけあると、次の compaction で消え、何が起きたのかを誰も再構成できません。明示的で永続的でなければなりません。 memory。 何を覚えてよいか、どのエージェントが、どのプロジェクトについて、誰に見える形で覚えるか。あるエンジニアの訂正が、別のチームのコードベースを扱うセッションを黙って動かしてしまってはいけません。 権限制御。 エージェントが何をしてよいか、どのリポジトリで、どの環境に対して、そして何が人間の承認を要するか。プロンプトで丁寧にお願いするのではなく、ホスト側で強制します。 すべての操作の記録。 コマンド、ファイル変更、承認、拒否のすべてを、エージェントが書き換えられない場所に記録します。信頼は、エージェントが「正しいことをしました」と言うことからは生まれません。履歴を追跡できることから生まれます。 これらは、エージェントが自社を代表してコードを push できるようになったとき、どの会社にも必要になる普通の統制です。エージェントの調整、明確な memory の境界、ホストレベルの権限、そしてエージェントが改変できない監査ログ。セッションを増やすことが効くのは、エンジニアがその作業を理解し、制御し、信頼できるときだけです。 コスト は、エージェントの艦隊が数百セッション規模になると、別の問題として立ち上がります。エージェント本体の作業には、すでに値段がついています。調整はその上にもう一層を足します。セッションを温かく保つ、状態を確認する、結果をルーティングする、fan-out を支える、といった処理です。その規模になると、この追加分の請求が採用の障壁になり得ます。私たちは、定常的な監督に安価なモデルを使う、決定的なチェックはスクリプトに任せる、最小コンテキストでの起動、セッション知識の再利用、タスク単位の正確なコスト計上といった方法で、これを下げる道を探っています。 今日から使えること ここでの学びは、私たちのツールを採用しなくてもすぐ適用できます。今いる段階から始めて、何がもうスケールしていないかを特定してください。次に進む前に、最小で役に立つ改善を1つ入れます。各段階は、次の段階への準備をしながら、それ自体で価値を出します。 同時セッション数を数える。 1つなら段階 1、タブが数枚なら段階 2、というように。この数が、次に解くべき問題を教えてくれます。そしてそれは、いちばん面白そうに聞こえる問題ではまずありません。 段階 1 から 2 は無料。効くのは段階 2 から 3。 タブを増やす前に、エージェントに memory を与えてください。最も安い形は、すべてのセッションが読むリポジトリ内のファイル1枚で、そこに自分の規約と、繰り返し言っている訂正を書いておくことです。どのツールを使っていても、並行セッションを負担から既定の状態に変えるのは、この1手です。 繰り返しの雑務を1つ、スケジュールに渡す。 新しい issue の triage や、不安定なチェックの再実行など、毎日手でやっているジョブを1つ選び、タイマーで始まるセッションに渡します。スケジュール実行されるセッションを1つ動かすほうが、それについてどれだけ読むよりも学べます。 orchestrator の前に pipeline を作る。 セッションが同じ数種類の作業を繰り返しているなら、ステージに名前を付け、その間にキューを置きます。GitHub issue のラベルは、始めるには十分に良いキューです。ラベル1つにセッション種別1つ、各セッションは自分のラベルが付いたものを拾います。 段階 5 から始めない。 5つの務めを書き出し、どれが自分の1日を食べているかを見ます。私たちの場合は、50 を超えるセッション間の巡回でした。最初に自動化すべきはその務めであり、それがどれなのかは、体感できるだけのセッションを動かしてみて初めて分かります。 ガバナンスは初日から始める。規模が出てからではない。 監査ログと権限制御の2つは、今すぐできます。エージェントがやったことを、エージェントが書き換えられない場所に記録し、何をしてよいかをプロンプトではなくホストレベルで決めます。どちらも2セッションのうちは安く、50 セッションになってからの後付けはほぼ不可能です。 私たちが実際に動かしているバージョンを試したい場合、Kiro Crew は memory、ダッシュボード、cron、workflow、pipeline を今日提供しており、基本的な Crew Mode は feature preview を有効にするとリポジトリで利用できます。いちばん速い始め方は、ラップトップにインストールし、リポジトリ1つに向け、スケジュール実行の雑務を1つ渡すことです。自分が寝ている間も動かしたくなったら、クラウドインスタンスへ移します。 この先どこへ向かうか 今は、人間が crew に具体的なゴールを渡します。この機能を出す、このリポジトリを green にする、といったものです。時間が経つにつれ、そのゴールはより抽象的になり、crew は作業を待つのではなく提案するようになるはずです。ただしそれが起きるのは、ガバナンスとコスト制御の機能が整い、十分にテストされたあとです。企業が制御も監査もできず、費用も負えない機能は、プロダクトではなくデモです。 Kiro Crew はオープンソースです。この記事のすべての背後にあるコード、アーキテクチャドキュメント、機能仕様は、公開リポジトリにあります: https://github.com/kirodotdev/KiroCrew 。自分でこのようなソフトウェアファクトリーを作りたい方は、 kiro.dev/crew で Crew を試してください。 この記事は Kiro ブログの How we built a software factory with Kiro Crew to merge 1000 PRs in a week を翻訳したものです。

みなさん、こんにちは。ソリューションアーキテクトの 大前 です。9 月に入り一段と涼しくなってきましたが、いかがお過ごしでしょうか。今月は「エージェントに現場を任せるとき、境界線をどこに引くか」をピックアップトピックとしてお届けしつつ、8 月に公開された製造業向けのブログとサービスアップデートをご紹介します。なお、リンク先には英語の記事も含まれていますが、日本語の解説を添えていますのでぜひご覧ください。 ピックアップトピック: エージェントに現場を任せるとき、境界線をどこに引くか PoC では動いたのに本番に載せられない理由の多くは、モデルの精度ではなく「どこまで AI に判断させるか」が決まっていないことにあります。今回ご紹介している記事のいくつかでは、同じ問いに別の角度から答えていました。 AI に判断を任せ、実行は別の層で制御する コニカミノルタ様の「未来の実験室」 では、材料開発の実験を「緑色を作ってください」と自然言語で指示できます。ただしモデルは座標や動作列を生成しません。担当は目標色・操作候補・停止条件へ分解した JSON の中間表現までで、座標制御は人が設計した決定論的な制御層が担います。役割を絞ったので、軽量な Claude Haiku 系でも成立します。 SUMCO 様の SynchroFabAI も同じ構図で、AI に任せるのは「異常状態の推測」と「因果関係の推測」までであり、操作は人間が実施します。 AWS Summit での Physical AI デモ構築 においても、エージェントの権限を「変更できる／人の承認が要る／外で強制される」の 3 段に切ることで安全性を保ちながらロボットが動くデモを構築しました。これらに共通するのは、AI の判断と現実世界への操作を直結させず、その間に人の確認や決定論的な制御、外部から強制される権限制御を置いている点です。 では、どこまでをAIに任せ、どこからを人や制御層に渡すべきでしょうか。その境界は、モデルの性能だけでは決められません。8 月に公表された Amazon Science の論文で提案されている SOP-Bench では、標準作業手順書（SOP）を AI エージェントに実行させて成功率を測定しています。11 のモデルで試した結果、新しいモデルが必ず高い成功率を示すわけではありませんでした。また、ツール構成を比較した実験では、必要なツールだけを与えた場合に比べ、不要なツールを追加すると成功率がほぼ半減しました。自社の手順と実際のツール構成で性能を測り、安定して実行できる範囲だけをAIに委ねることが、AI と人間の境界を決める現実的な方法です。ただし、境界を決めるだけでは十分ではありません。実運用では、その境界を技術的な制約として強制する必要があります。 決めた境界をインフラ側で強制する 8 月は Amazon Bedrock AgentCore にこの方向の機能が 2 つ加わりました。 時間的ポリシー は、それまでの操作履歴を踏まえて各リクエストを評価する認可ルールで、作業順序の強制や特権操作前の人間承認を設定できます。 AgentCore Payments では支払い上限をインフラ層で強制できます。 「危険な操作をしないでください」とプロンプトに書くのと、そもそもその操作が許可されない状態を作るのは、まったく別のことです。後者は OT のインターロックに近い考え方です。エージェントを現場に出すために必要なのは、モデルを賢くすることだけでなく、任せない範囲を先に決め、その境界を外部から強制することなのかもしれません。 直近で開催予定のイベント 9/14 – 9/19 IMTS 2026 北米最大級の工作機械展示会がシカゴで開催されます。AWS もブースを出展予定で、量子コンピューティングと製造業をテーマにした AWS 主催のレセプションもあります。 10/13 – 10/16 CEATEC 2026 JEITA 主催のデジタルイノベーションの総合展示会が幕張メッセで開催されます。テーマは「Transformation -企業が、産業が、そして社会が変わる-」です。 AWS も Hall 4 で、安川電機様とご一緒に展示を予定しています。 10/26 – 10/31 JIMTOF2026 世界最大級の工作機械見本市が東京ビッグサイトで開催されます。 11/30 – 12/4 AWS re:Invent 2026 AWS 最大の学習イベントがラスベガスで開催されます。2,200 を超えるセッションが予定されています。 製造関連ブログのご紹介 8/3 Engineering Development Hub : A unified workbench to accelerate product development 製品開発チームは、 分断されたツール・データサイロ・計算リソース制約 という課題に日々直面しています。 Engineering Development Hub (EDH) は、複雑なシステムの設計・テスト・検証に必要なアプリケーション・計算・データを1つのオープンソース環境に統合した、クラウドベースのエンジニアリングワークベンチです。 Amazon Lab126 や Rivian などの顧客が既にEDHを活用しており、NVIDIA Isaac Sim でのフィジカルAI模倣学習や車載インフォテインメント開発などの実例を紹介しています。 大規模ハードウェア開発を高速化したい設計・開発部門の方におすすめです。 8/6 Run HPC Simulations faster with Siemens Teamcenter and AWS ParallelCluster 「解析の順番待ちで設計が止まる」という課題を、Teamcenter Simulation と AWS ParallelCluster の連携で解いた記事です。設計を選んでジョブを投げれば入力は自動で置かれ、計算ノードは終われば消えます。数日の設計スタディが数時間に。 解析のリードタイム短縮を検討している CAE・解析部門の方におすすめです。 8/7 Leading FMEG Player Builds Manufacturing Control Tower on AWS 工場ごとにデータが閉じていると、異常に気づくのは手遅れになってからとなります。本記事ではインドの大手電設機器メーカーが約 15 工場を 4 層構成でつなぎ、障害後の意思決定を 24 時間超から 2 時間未満に、拠点追加の工数を 1 工場あたり 20% 未満（従来は 80〜100%）に縮めた事例をご紹介しています。 複数拠点の OT データ統合をこれから広げる方におすすめです。 8/18 SUMCO が挑む、Amazon Redshift × 生成 AI による半導体ウェーハ製造 DX 株式会社 SUMCO 様との共著です。ネットワーク分離と権限分離によるセキュアな AWS 基盤上に、データ分析パイプラインの RedPulse と自然言語でのデータ分析を実現する SynchroFabAI を積み上げた道筋が語られます。 セキュリティを担保しつつ、機械学習による品質予測や、品質に強く寄与するパラメータの要因分析などによるデータ分析の力を組織全体に広げていく過程をご覧いただけます。 8/19 Agentic AI でつなぐモノ・サービスの改善サイクル リリース後に溜まる運用データが、次の開発に一度も戻ってこない。その原因を「データのサイロ」と「人材のサイロ」に切り分け、Amazon Quick で埋める方法です。AI 自身が仮説を立てて検証まで進みます。 製品の改善サイクルを回したい開発・品質部門の方におすすめです。 8/20 Amazon Bedrock とロボティクスで目指す「未来の実験室」 コニカミノルタ株式会社様との共著です。材料開発の実験を自然言語で指示すると、ロボットアームが実際に手を動かし、結果が電子実験ノートに戻るという閉ループを約 2 か月で実装されています。開発には Kiro CLI を活用されており、 生成 AI をチャットの外の実機制御へ広げたい研究開発部門の方におすすめです。 8/21 Accelerating Chip Tape-out with AWS Unified Operations 半導体企業がAWS上でEDA（電子設計自動化）ワークロードを実行する際、インフラの可用性・性能がチップ納期に直結します。 AWS Unified Operations はAWSの最上位サポート層にあたり、専任チームが、アーキテクチャ支援・迅速なインシデント対応・財務最適化・セキュリティ監視を提供します。本記事では、12 か月のテープアウト工程に沿って Unified Operations がどのように支援を行うのかを紹介します。 高可用性が求められる HPC ワークロードを抱える方におすすめです。 8/21 SOP-Bench: A new benchmark for evaluating AI agents on real business procedures Amazon Science が発表した、標準作業手順書（SOP）を AI エージェントに実行させる公開ベンチマークです。倉庫点検や危険物分類を含む、12 業務領域・2,000 超のタスクを実際に動くツールと正解付きで用意し、エージェントの。自社の手順を足して評価することもできます。 エージェントを本番に載せる前の物差しが欲しい方におすすめです。 8/24 ソフトウェア開発を AI エージェントで加速する ── TOPPAN が体験した SDLC 主要フェーズの手応え TOPPAN 株式会社様との共著です。20 名が Kiro CLI を活用し、SDLC の Research・Plan・Release をAI と協調しながら回す体験を行いました。レガシーコードから設計書を復元する手応えや、AWS MCP Server を頼りに CI/CD を組む感触が率直に語られます。 AI を活用した開発の効率化に興味のある方におすすめです。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 1: 企画からステージ制作、アプリケーション開発まで 6 月の Summit で展示した「AI エージェントが街の障害物を自律的に見つけて片付ける」デモを、どう作ったかの記録です。10 名全員が兼務で、実機を使った統合に充てられたのは本番前の約 1 か月という過酷な条件の中で、企画の可視化から 3D モデリング、実装、説明員資料などの全工程を生成 AI と伴走する過程を紹介しています。 AI を使った開発プロセスの型づくりに関心のある方は、ここから読むと全体像がつかめます。 9/1 AWS Summit Japan 2026 Physical AI デモの裏側 Part 2: ロボット開発編 上記デモのロボット側です。FANUC 社製協働ロボット 2 台をクラウドの AI エージェントと連携させるデモ開発の裏側をご紹介しております。画像から動作指令までを 1 つのモデルで出す方式を採らなかった理由、コーディングエージェントの権限を「変更できる／人の承認が要る／エージェントの外で強制される」の 3 つに切った線引き、そして手先の向きを保つ拘束を AI が誤って無効化した経験から「禁止と代替手順はセットで書く」に至った経緯まで、任せる範囲の決め方が具体的に語られます。 今号のピックアップトピックの実例編として、あわせてお読みください。 製造関連の主要なサービスアップデート 8/3 Amazon SageMaker AI がフルファインチューニングに対応 25 以上のオープンソースモデルで全パラメーターを更新できます。設備の型式ごとの符牒や検査基準といった組織固有の語彙を、モデルに深く覚え込ませたいときにご利用いただけます。 8/4 AWS Security Hub Extended がソフトウェアサプライチェーンのセキュリティに対応 外部から取り込むオープンソース部品に悪意あるコードが混ざっていないかを、アプリに組み込む前に検出・遮断できます。 8/6 AgentCore に時系列ポリシーとレート制限を追加 ピックアップトピックでご紹介した機能です。宛先ごとのリクエスト数・トークン数の上限も併せて設定できます。 8/7 AWS Parallel Computing Service が FedRAMP・SOC・ISO・PCI の対象に マネージド HPC サービスである、Parallel Computing Service がSOC、ISO などの主要な第三者認証の対象になりました。統制・監査要件が壁になっていた技術計算部門の導入判断を後押しします。 8/11 AWS Glue から SageMaker Unified Studio へワンクリックでアクセス AWS Glue と同じ権限のままクエリ・品質チェック・パイプライン構築へ移れます。データカタログの整備から分析・AI 活用までを、ツールを行き来せずに進められます。 8/18 AgentCore payments が一般提供開始 エージェントが有料の API を自ら見つけて使い、決済まで行えます。支払い上限はインフラ側で強制されるので、外部データを都度買う調達系エージェントも統制下で運用できます。 8/19 Amazon SageMaker のノートブックが Trusted Identity Propagation に対応 共有ロールではなく利用者本人の ID でデータ参照を制御でき、誰が何を見たかが AWS CloudTrail に残ります。品質データや設計情報の閲覧範囲を部門・拠点で分けたい分析基盤にご利用いただけます。 最後まで読んでいただきありがとうございました。 今月は、AI に任せる範囲の決め方と、その境界を仕組みで守る方法をご紹介しました。来月も、製造業における AI 活用のヒントをお届けします。それでは、また来月お会いしましょう！ 著者について 大前 遼（Ryo Omae） ソリューションアーキテクト 大前 遼（Ryo Omae）は、アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクトです。製造業のお客様を中心に、クラウド活用の技術支援を行っています。好きな領域は機械学習や生成 AI ・ロボティクスで、最近は Physical AI デモの構築に注力しています。

本記事は 2026 年 6 月 16 日 に公開された “ Converting an RDS for SQL Server instance from license included to Bring Your Own Media (BYOM) ” を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for SQL Server は最近 Bring Your Own Media (BYOM) をリリースしました。これにより、既存の SQL Server ライセンスをフルマネージドの RDS インスタンスで使用できるようになりました (詳細は「 フルマネージドの Amazon RDS for SQL Server で Bring Your Own Media によるライセンスモビリティの実現 」を参照)。これは、既存の Microsoft ライセンス契約をお持ちで、その投資を AWS 上で活用してクラウド支出を最適化したいお客様にとって特に価値があります。 すでに License Included (LI) モデルで RDS for SQL Server を実行している場合、データベース移行なしでそれらのインスタンスをインプレースで BYOM に変換できるようになりました。この機能により、RDS for SQL Server インスタンスを AWS 提供のライセンスから独自の SQL Server メディアの使用に移行しつつ、フルマネージドの RDS インフラストラクチャの利点を維持できます。BYOM を使用するには、License Mobility 付きの SQL Server Enterprise Edition または Standard Edition が必要です。ライセンスモビリティの詳細については、 ライセンスモビリティ のページを参照してください。 セットアッププロセスを簡素化するため、BYOM エンジンバージョンのエクスペリエンスも効率化しました。SQL Server のインストールメディアを Amazon Simple Storage Service (Amazon S3) にアップロードし、BYOM エンジンバージョンとして登録します。Amazon RDS はマイナーバージョンアップグレードが利用可能になると自動的に新しい BYOM エンジンバージョンを作成するため、常に最新の状態を維持できます。アップグレードを選択した際、追加の手動手順なしで新しいバージョンが準備されています。 本記事では、インストールメディアの準備、BYOM エンジンバージョンの作成、インプレースでのライセンスモデル変更という、エンドツーエンドの変換プロセスを説明します。 ソーシューション概要 既存の License Included の RDS for SQL Server インスタンスを BYOM に変換するには、以下の手順に従います: SQL Server のインストールファイルを準備し、Amazon S3 にアップロードする。 Amazon RDS が特定のデータベースエンジン構成を構築するために使用する BYOM エンジンバージョンを作成する。 既存の License Included インスタンスを BYOM ライセンスモデルと BYOM エンジンバージョンを使用するように変更する。 前提条件 開始する前に、以下の前提条件を満たしていることを確認してください: AWS Identity and Access Management (IAM) プリンシパル (ロールまたはユーザー) に、 AmazonRDSFullAccess (RDS オペレーション用の AWS マネージドポリシー) と、Amazon S3 で SQL Server インストールファイルの作成、アップロード、アクセスを行うための s3:GetObject 、 s3:CreateBucket 、 s3:PutObject 権限があること。 インストールファイルを保存するための S3 バケット。すべてのインストールファイルは、RDS インスタンスと同じ AWS リージョンの同じ S3 バケットに保存する必要があります。 変換対象の License Included モデルの既存 RDS for SQL Server インスタンス。 既存インスタンスのエンジンバージョンと一致する SQL Server インストールメディア (ISO ファイル)。 開始前の重要な考慮事項 BYOM から License Included への変換はサポートされていません。この変更は元に戻せないため、変換は慎重に計画してください。 BYOM エンジンバージョンはリージョンや AWS アカウント間で共有できません。ただし、インストールメディアは共有できます。BYOM を使用したいリージョンと AWS アカウントごとに BYOM エンジンバージョンを作成する必要があります。 BYOM は SQL Server 2019 および 2022 の Enterprise Edition と Standard Edition でサポートされています。 SQL Server Reporting Service (SSRS) または SQL Server Analysis Service (SSAS) を含むオプショングループは BYOM ではサポートされていません。 インスタンスが Multi-AZ に設定されている場合、変換はプライマリとスタンバイの両方のインスタンスに適用されます。 変換中、インスタンスは modifying 状態になります。Multi-AZ インスタンスの場合、ローリングインプレース変換が実行され、まずスタンバイが変更され、その後フェイルオーバーが発生し (通常 30〜60 秒のフェイルオーバー時間)、旧プライマリが更新されます。Single-AZ インスタンスの場合、変換中にインスタンスがシャットダウンし、変換完了時に再起動します。本番ワークロードではメンテナンスウィンドウ中に変換をスケジュールしてください。 インスタンスにリードレプリカがある場合、変換前に削除し、変換後に再作成してください。新しいレプリカは自動的に BYOM ライセンスモデルを継承します。 変換後、AWS を通じた SQL Server ライセンスの課金は停止します。Microsoft のライセンス契約への準拠を確認する責任はお客様にあります。 クロスリージョンリードレプリカを作成するには、先にターゲットリージョンで BYOM エンジンバージョンを作成する必要があります。 License Included から BYOM への変換の一部としてマイナーバージョンをアップグレードしたい場合、まずターゲットの上位マイナーバージョン用の BYOM エンジンバージョンを作成する必要があります。 ステップ 1: インストールファイルの準備とアップロード 開始するには、既存の RDS インスタンスで実行されているエンジンバージョンと一致する SQL Server インストールメディアファイルが必要です。これは Microsoft Volume Licensing Service Center (VLSC) または Visual Studio サブスクリプションから取得できます。 現在のエンジンバージョンの確認 まず、既存の License Included インスタンスのエンジンバージョンを確認します: aws rds describe-db-instances \ --db-instance-identifier my-li-instance \ --query "DBInstances[0].{EngineVersion:EngineVersion,LicenseModel:LicenseModel}" \ --region &lt; your-region &gt; \ --output table Bash 出力のサンプル : S3 バケットを作成してインストールファイルをアップロードする 1.RDS インスタンスと同じリージョンに S3 バケットを作成します: aws s3 mb s3://amzn-s3-demo-bucket --region &lt; your-region &gt; Bash 2. SQL Server ISO ファイルをアップロードします (以下のメディアファイル名と S3 バケット名はご利用の環境に合わせて置き換えてください): aws s3 cp \ SW_DVD9_NTRL_SQL_Svr_Ent_Core_2022_64Bit_English_OEM_VL_X23-28404.ISO \ s3://amzn-s3-demo-bucket/sqlserver-2022-ee/ \ --region &lt; your-region &gt; Bash クロスアカウント設定: 組織内のアカウント間でインストールメディアを共有する 複数の AWS アカウントを管理している場合、SQL Server インストールメディアを中央の S3 バケットに保存し、AWS Organization 内のすべてのアカウントからのアクセスを許可できます。これにより、各アカウントに同じ ISO ファイルを個別にアップロードする必要がなくなります。 中央の S3 バケットに以下のバケットポリシーを追加して、組織内のすべてのアカウントからのアクセスを許可します。 Amazon S3 Console を使用したバケットポリシーの追加 を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "CrossAccountAccess", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::TARGET-ACCOUNT-ID:role/YOUR-IAM-ROLE" }, "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::YOUR-BUCKET-NAME", "arn:aws:s3:::YOUR-BUCKET-NAME/*" ], "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxxxx" } } } ] } JSON プレースホルダーを実際の値に置き換えてください : o-xxxxxxxxxxxx は AWS Organizations ID、 TARGET-ACCOUNT-ID はアクセスが必要な AWS アカウント ID、 YOUR-IAM-ROLE はインストールメディアへのアクセスに使用する IAM ロール、 YOUR-BUCKET-NAME は S3 バケット名です。 各アカウントでは引き続き独自の BYOM エンジンバージョンを作成する必要がありますが (BYOM エンジンバージョンはアカウント間で共有できないため)、中央のバケットからインストールメディアを参照できます。 注意: S3 バケットは、BYOM エンジンバージョンを作成する RDS インスタンスと同じリージョンにある必要があります。 ステップ 2: BYOM エンジンバージョンの作成 Amazon RDS は BYOM エンジンバージョンを使用して、SQL Server インストールファイルを検証し、再利用可能なテンプレートとしてパッケージ化して登録します。BYOM エンジンバージョンは、既存インスタンスと同じエンジンバージョンを使用する必要があります。 AWS CLI を使用して BYOM エンジンバージョンを作成する 以下のコマンドを実行して、アップロードしたメディアファイルを使用して BYOM エンジンバージョンを作成します : aws rds create-custom-db-engine-version \ --engine sqlserver-ee \ --engine-version 16.00 .4225.2.v1 \ --database-installation-files-s3-bucket amzn-s3-demo-bucket \ --database-installation-files SW_DVD9_NTRL_SQL_Svr_Ent_Core_2022_64Bit_English_OEM_VL_X23-28404.ISO \ --region &lt; your-region &gt; Bash 以下のスクリーンショットが示すように RDS Console から BYOM エンジンバージョンを作成することもできます。 BYOM エンジンバージョンの作成ステータスの監視 BYOM エンジンバージョンの作成には通常数分かかります。ステータスが available と表示されるまで監視します : aws rds describe-db-engine-versions \ --engine sqlserver-ee \ --engine-version 16.00 .4225.2.v1 \ --include-all \ --region &lt; your-region &gt; \ --query "DBEngineVersions[?DBEngineVersionArn!=null].{Version:EngineVersion,Status:Status}" \ --output table Bash 出力のサンプル : 注意: ステータスが Validating/Creating から Available に変わるまで待ってから、ステップ 3 に進む必要があります。 ステップ 3: インスタンスを License Included から BYOM に変換する BYOM エンジンバージョンが available ステータスになったら、既存の License Included インスタンスを BYOM ライセンスモデルを使用するように変更できます。このオペレーションは、インスタンスの再作成やデータ移行を必要とせず、ライセンスモデルをインプレースで変更します。 インスタンスが Multi-AZ インスタンスの場合、ダウンタイムを最小化するためにローリングインプレース変換が実行されます。Single-AZ インスタンスの場合、ダウンタイムが必要です。メンテナンスウィンドウ中にこのタスクを実行することをお勧めします。 注意: BYOM から License Included への変換はサポートされていません。変換は慎重に計画してください。 AWS CLI を使用してインスタンスを変更する aws rds modify-db-instance \ --db-instance-identifier my-li-instance \ --engine-version 16.00 .4225.2.v1 \ --license-model bring-your-own-media \ --apply-immediately \ --region &lt; your-region &gt; Bash 以下のスクリーンショットが示すように、RDS Console からインスタンスを変更してライセンスモデルを変換することもできます。 注意: 選択した BYOM エンジンバージョンがインスタンスの現在のバージョンより高いマイナーバージョンの場合、RDS はマイナーバージョンアップグレードとライセンスモデルの変更を単一のオペレーションで実行します。 変換の確認 変更が完了したら、ライセンスモデルが変更されたことを確認します : aws rds describe-db-instances \ --db-instance-identifier my-li-instance \ --query "DBInstances[0].{ID:DBInstanceIdentifier,Status:DBInstanceStatus,LicenseModel:LicenseModel,EngineVersion:EngineVersion}" \ --output table \ --region &lt; your-region &gt; Bash 既存の DB インスタンスとライセンスモデルを一覧表示する まだ License Included モデルを使用しているすべての SQL Server インスタンスを一覧表示するには : aws rds describe-db-instances \ --region &lt; your-region &gt; \ --query "DBInstances[?starts_with(Engine,'sqlserver') &amp;&amp; LicenseModel=='license-included'].{ID:DBInstanceIdentifier,Engine:Engine,License:LicenseModel,MultiAZ:MultiAZ,ReadReplica:ReadReplicaSourceDBInstanceIdentifier}" \ --output table Bash ライセンス消費の追跡 AWS License Manager を使用して、RDS インスタンスのライセンス消費を追跡できます。ライセンス使用状況を有効化し追跡するには、以下の手順に従います : ステップ 1: AWS License Manager をオンボーディングする インスタンスを追跡するには、License Manager にアカウントのリソースインベントリを読み取る権限を付与するサービスリンクロールが必要です。以前に License Manager コンソールを開いて一度限りのセットアップを許可している場合、このロールはすでに存在するため、ステップ 2 に直接進めます。 初めての場合、AWS Management Console はサービスページにアクセスした時点で自動的にロールを作成します。または、AWS CLI を使用して明示的に作成できます : aws iam create-service-linked-role --aws-service-name license-manager.amazonaws.com Bash ステップ 2: RDS BYOM インスタンス用のセルフマネージドライセンスを作成する セルフマネージドライセンスは、License Manager に何を探し、どのようにカウントするかを指示します。Amazon RDS リソースで実行されている SQL Server を対象とし、カウント単位として vCPU を選択します。 rds-byom-license-config.json という名前の JSON ファイルを作成し、以下の内容を記述します。この例は、Amazon RDS のセルフマネージドな SQL Server Enterprise Edition ライセンスを追跡します。SQL Server Standard Edition ライセンスを追跡するには、同様の JSON ファイルを作成し、 ProductInformationFilterValue の値を sqlserver-se に変更します。 { "Name": "RDS-SQLServer-BYOM-EE", "Description": "Self-managed license for RDS SQL Server Enterprise Edition BYOM", "LicenseCountingType": "vCPU", "LicenseCountHardLimit": false, "ProductInformationList": [ { "ResourceType": "RDS", "ProductInformationFilterList": [ { "ProductInformationFilterName": "Engine Edition", "ProductInformationFilterValue": ["sqlserver-ee"], "ProductInformationFilterComparator": "EQUALS" } ] } ] } JSON 以下のコマンドを実行して、JSON ファイルを使用してライセンス構成を作成します。 aws license-manager create-license-configuration \ --region &lt; your-region &gt; \ --cli-input-json file://rds-byom-license-config.json Bash 出力のサンプル : 出力に表示されるライセンス構成 ARN をメモしてください。次のステップで必要になります。 AWS License Manager コンソールからセルフマネージドライセンスに移動し、「セルフマネージドライセンスを作成」をクリックしてライセンス構成を作成することもできます。 ステップ 3: RDS インスタンスが追跡されていることを確認する ライセンス構成の設定が完了した後、BYOM インスタンスが検出、レポートされるまでに少し時間がかかります。以下のコマンドを使用して追跡リソースを確認できます : aws license-manager list-usage-for-license-configuration \ --region &lt; your-region &gt; \ --license-configuration-arn &lt; license-configuration-arn &gt; Bash 考慮事項 License Manager はリージョンごとに使用状況を追跡します。マルチリージョンの RDS BYOM デプロイメントでは、各リージョンで独立して License Manager を設定してください。 クロスリージョンリードレプリカは、レプリカが存在するリージョンの License Manager によって追跡されます。 クリーンアップ 不要な課金を避けるため、不要になったリソースをクリーンアップしてください。 RDS インスタンスを削除します。 aws rds delete-db-instance \ --db-instance-identifier convert-li-to-byom-demo \ --skip-final-snapshot \ --region &lt; your-region &gt; Bash 関連するすべてのインスタンスとスナップショットが削除された後、BYOM エンジンバージョンを削除します。 aws rds delete-custom-db-engine-version \ --engine sqlserver-ee \ --engine-version 16.00 .4225.2.v1 \ --region &lt; your-region &gt; Bash S3 バケットを削除します。 aws s3 rb s3://amzn-s3-demo-bucket --force Bash ライセンス構成は、リソースがまだ関連付けられている間は削除できません。追跡対象の RDS BYOM インスタンスを先に削除する必要があります。 aws license-manager delete-license-configuration \ --region &lt; your-region &gt; \ --license-configuration-arn &lt; license-configuration-arn &gt; Bash まとめ 本記事では、既存の License Included の RDS for SQL Server インスタンスを Bring Your Own Media (BYOM) ライセンスモデルに変換する方法を説明しました。このプロセスでは、SQL Server インストールメディアを Amazon S3 にアップロードし、BYOM エンジンバージョンを作成し、既存インスタンスを新しいライセンスモデルを使用するように変更します。 AWS 上の SQL Server ライセンスコストを最適化したい場合、この変換は柔軟性を提供します。BYOM を通じて既存の Microsoft ライセンス契約を活用することで、自動バックアップ、パッチ適用、モニタリング、高可用性といった Amazon RDS のフルマネージドの利点を維持しながら、全体的なクラウド支出を削減できます。 Amazon RDS for SQL Server の BYOM の詳細については、 Amazon RDS for SQL Server ドキュメント を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Mesgana Gormley Mesgana は Amazon Web Services (AWS) の Worldwide Public Sector (WWPS) 部門に所属するシニアデータベーススペシャリストソリューションアーキテクトで、Amazon RDS チームと連携しています。AWS のお客様にテクニカルガイダンスを提供し、リレーショナルデータベースワークロードの AWS への移行、設計、デプロイ、最適化を支援することに注力しています。仕事以外では、旅行や家族・友人との時間を楽しんでいます。 Sudhir Amin Sudhir は Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。ニューヨークを拠点とし、さまざまな業種のエンタープライズのお客様にアーキテクチャガイダンスとテクニカルアシスタンスを提供し、クラウド導入を加速しています。スヌーカー、ボクシングや UFC などの格闘技の大ファンで、世界で最も壮大な動物を間近で見られる野生動物保護区のある国への旅行を楽しんでいます。 Barry Ooi Barry は AWS のシニアデータベーススペシャリストソリューションアーキテクトです。お客様の AWS ジャーニーの一環として、クラウドネイティブサービスを使用したデータプラットフォームの設計、構築、実装を専門としています。関心分野はデータ分析と可視化です。

本記事は 2026 年 6 月 2 日 に公開された “ Unlock license mobility with Bring Your Own Media on fully managed Amazon RDS for SQL Server ” を翻訳したものです。 長年にわたり、エンタープライズワークロードをクラウドに移行する理由は、管理の容易さ、柔軟なスケーリング、コスト削減を中心に語られてきました。これらは重要な理由ですが、既存のライセンス契約やすでに投資したインフラストラクチャとの兼ね合いで正当化する必要がありました。エージェンティック AI アプリケーションの登場により、その判断基準は変わりました。これらのアプリケーションは、柔軟にスケールする GPU キャパシティ、最新の AI サービスへの低レイテンシーアクセス、そしてデータに直接アクセスして推論できる AI モデルに依存しています。この基盤をセルフマネージドのデータセンターで再現することはますます困難になっています。オンプレミスのインフラストラクチャは管理が難しいだけではありません。クラウドネイティブなエージェンティック AI サービスへのアクセスが限られるため、ビジネスの次の一手に対する制約となりつつあります。 この制約は、業務データが存在するあらゆる場所で顕在化します。多くの企業において、そのデータの大部分は Microsoft SQL Server に格納されており、顧客レコード、注文、在庫、基幹業務システムを支えています。こうしたお客様にとって、移行を妨げていたのは移行したいという意思ではなく、すでに行ったライセンス投資でした。これまで、 Software Assurance を持つお客様が SQL Server ライセンスを AWS に持ち込めるのは、 Microsoft の License Mobility プログラム を利用したセルフマネージドの Amazon Elastic Compute Cloud (Amazon EC2) 上に限られていました。 Amazon Relational Database Service (Amazon RDS) のようなフルマネージドデータベースの場合、既存の SQL Server ライセンスを持つお客様は、License Included モデルでライセンス費用を二重に支払う必要がありました。 Amazon RDS for SQL Server の Bring Your Own Media (BYOM) がこの問題を解決します。既存の SQL Server インストールメディアと、すでに投資済みのライセンスを持ち込み、フルマネージドデータベースサービスである RDS for SQL Server 上で追加のライセンス費用なしに利用できます。BYOM では、既存の SQL Server Enterprise Edition または Standard Edition のライセンスを再利用できます。AWS License Manager を設定済みであれば、BYOM インスタンスは自動的に追跡され、SQL Server のライセンス使用状況とコンプライアンスを継続的に可視化できます。移行を検討されているお客様のために、Amazon RDS は リフト &amp; シフト のパスを提供し、SQL Server の業務データをフルマネージド環境に移行できます。RDS はパッチ適用、バックアップ、高可用性、モニタリングを自動化しつつ、AWS ネイティブのエージェンティック AI や分析サービスに直接アクセスできる環境を提供します。 本記事では、SQL Server のインストールメディアを Amazon Simple Storage Service (Amazon S3) にアップロードし、BYOM インスタンスを起動する方法を説明します。 ソリューション概要 既存の SQL Server ライセンスを再利用するには、ライセンスの配布条件に基づき、ライセンス済みの SQL Server Release to Manufacturing (RTM) メディアを Amazon RDS に提供する必要があります。BYOM では、AWS Console から RTM メディアをアップロードします。開始するには、RTM メディアを Amazon S3 にアップロードし、それに対してフルマネージドの RDS for SQL Server BYOM インスタンスを起動します。AWS License Manager を使用すると、Amazon RDS が BYOM インスタンスを自動的に検出し、vCPU 使用量をレポートするため、SQL Server のライセンス消費を継続的に可視化できます。ライセンスコンプライアンスの責任はお客様にあります。 Amazon RDS Console では、データベース作成ページから RDS for SQL Server BYOM インスタンスを直接作成できます。 ウォークスルー このセクションでは、SQL Server 2022 Standard Edition で BYOM インスタンスを作成する手順を説明します。 前提条件 開始する前に、Software Assurance 付きの有効な SQL Server ライセンス (Standard Edition または Enterprise Edition) があることを確認する必要があります。 ここ からMicrosoft に License Mobility Verification Form を提出する必要があります。 ステップ 1: Visual Studio サブスクリプションから SQL Server RTM メディアをダウンロードする まず、SQL Server の RTM メディアを Amazon RDS がアクセスできる S3 バケットに配置する必要があります。有効なサブスクリプションをお持ちの場合は、Visual Studio サブスクリプションを通じて Microsoft から RTM ISO ファイルをダウンロードできます。ボリュームライセンスで製品を購入した場合は、Microsoft 365 管理センターからもダウンロードできます。 ダウンロードページで「SQL Server 2022」(またはターゲットバージョン) を検索し、SQL Server 2022 Standard を見つけます。言語として English を選択し (他の言語はサポートされていません)、ダウンロード形式として ISO を選択します。 注意 : 言語は English かつコアベースライセンスの RTM ISO ファイルを使用してください。 ステップ 2: Amazon S3 にファイルをアップロードする S3 バケットがまだない場合は、「バケットを作成」を選択して一意の名前を付けます (この例では sqlserver-byom-media を使用します)。次にアップロード画面で「ファイルを追加」を選択し、SQL Server RTM メディアファイルを選択して、「アップロード」を選択して転送を開始します。 ステップ 3: 最初の BYOM インスタンスを作成する RTM メディアが S3 に配置されたら、最初の BYOM インスタンスを作成する準備が整いました。特定のメジャーバージョンに対して初めてインスタンスを起動する際、Amazon RDS Console はバックグラウンドで 2 つのオペレーションを単一のワークフローで処理します。RTM メディアから BYOM エンジンバージョンを作成し (約 20 分)、その BYOM エンジンバージョンに対してインスタンスを起動します。 Amazon RDS Console を開き、左のナビゲーションペインで「データベース」を選択します。 「データベースの作成」を選択します。 「エンジンのオプション」で以下を設定します: エンジンのタイプ : Microsoft SQL Server を選択 データベース管理タイプ : Amazon RDS を選択 エディション : SQL Server Standard Edition を選択 ライセンス : bring-your-own-media を選択 メジャーエンジンバージョン : SQL Server 2022 を選択 マイナーエンジンバージョン : ターゲットバージョンを選択 (例 : 16.00.4245.2.v1 ) 「S3 からの SQL Server RTM メディア」 (メジャーバージョンごとに初回のみ表示) で「S3 を参照」を選択 : バケット名 (sqlserver-byom-media) から RTM ファイルを選択し、ISO ファイルを選択します。例 : “Enu_sql_server_2022_standard_core_edition_x64_dvd.iso” DB インスタンス識別子 : 名前を入力します (例 : sqlserver-se-2022-byom) 残りの設定 (DB インスタンスクラス、ストレージ、接続、認証、バックアップ、メンテナンス) は、License Included インスタンスと同様に設定します。 すべての設定を確認し、「データベースの作成」を選択します。 注意 : 言語は English かつコアベースライセンスの RTM ISO ファイルを使用してください。 重要な制限事項と考慮事項 Amazon RDS for SQL Server で BYOM を使用する際は、以下の考慮事項に留意してください。 まず、SQL Server ライセンスが Microsoft のライセンス契約に準拠していることを確認する責任はお客様にあります。AWS License Manager を使用してライセンス使用状況を追跡できますが、ライセンス上限を超過しても AWS がオペレーションをブロックすることはありません。コンプライアンスはお客様の責任です。 次に、RTM ファイルはコアベースライセンスかつ English 言語のみに対応しています。これらの条件を満たさない場合、BYOM エンジンバージョンの作成は失敗します。 最後に、関連する RDS インスタンス、スナップショット、またはバックアップが存在する間は、BYOM エンジンバージョンを削除できない点に注意してください。 クリーンアップ 不要な課金を避けるため、このウォークスルーで作成したリソースが不要になったら削除してください。 RDS インスタンスの削除 : RDS Console → 「データベース」を選択 → インスタンスを選択 → 「アクション」 → 「削除」 S3 オブジェクトとバケットの削除 : S3 Console → バケットを選択 → 「空にする」 → 「削除」 まとめ SQL Server のライセンス投資を守ることと、クラウドで新たな可能性を生み出す AWS の分析およびエージェンティック AI サービスへのデータアクセスパスを確保することを、二者択一にする必要はありません。Amazon RDS for SQL Server の Bring Your Own Media がその道を開きます。Software Assurance をお持ちであれば、Microsoft の License Mobility プログラムを利用して、既存の SQL Server Standard Edition または Enterprise Edition ライセンスをフルマネージドの Amazon RDS 環境に持ち込むことができます。Amazon RDS では、自動バックアップ、モニタリング、パッチ適用、高可用性の恩恵を受けられます。 本記事では、Amazon RDS for SQL Server で Bring Your Own Media (BYOM) を使い始める方法を説明しました。ウォークスルーでは、Release to Manufacturing (RTM) ファイルの S3 へのアップロードと BYOM エンジンバージョンの作成を取り上げました。 SQL Server の業務データとエージェンティック AI の間にあったライセンスの壁は、もはや存在しません。Amazon RDS for SQL Server の Bring Your Own Media サポートの詳細については、以下のリソースをご参照ください : Amazon RDS for SQL Server ドキュメント AWS License Manager ドキュメント create-custom-db-engine-version CLI リファレンス&nbsp; BYOM は、Amazon RDS for SQL Server がサポートされているすべての商用 AWS リージョンで利用可能です。最新の利用可能状況については、 Amazon RDS for SQL Server の料金ページ をご確認ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Srikanth Katakam Srikanth は AWS のシニアデータベースエンジニアで、Oracle、MySQL、PostgreSQL、Amazon Aurora、Microsoft SQL Server、Amazon Redshift などのデータベース技術、および Oracle Apps や Informatica を含むデータ統合プラットフォームにおいて 10 年以上の経験を持っています。Amazon RDS for SQL Server や Amazon RDS Custom for SQL Server を含む Amazon RDS の商用データベースエンジンを専門としています。AWS 上の SQL Server に関する深い専門知識を活かし、AWS のお客様の多様なニーズに応える機能設計に情熱を注いでいます。 Colleen Betik Colleen は AWS のシニアテクニカルプロダクトマーケティングマネージャーで、Amazon Relational Database Service を担当しています。新しい製品や機能のローンチに向けた差別化されたメッセージングとコンテンツの構築をチームと共に推進しています。Southern Methodist University でマーケティングの B.B.A.、University of Virginia で Global Commerce の M.S.、ESADE で Global Strategic Management の MSc を取得しています。

はじめに 企業がデジタルコマースプラットフォームのモダナイゼーションを進める中で、多くの企業は、コアとなる SAP ERP ワークロードを AWS 上の SAP Cloud ERP Private で運用しながら、SAP Commerce Cloud SaaS を採用しています。SAP Commerce Cloud は、複雑な B2B、B2C、B2B2C の企業向けに設計された統合型 e コマースプラットフォームであり、ホスティング場所を SAP が決定する完全マネージド型の SaaS ソリューションとして提供されます。そのため、重要なアーキテクチャ上の問いは、プラットフォームがどこで稼働するかではなく、AWS 上でホストされている SAP システムといかに効果的に統合するか、という点になります。SAP は、SAP Commerce（SAP Hybris）2205 のメインストリームメンテナンスの終了を 2026 年 7 月 31 日 と発表しており、多くの企業は、SAP Commerce Cloud SaaS と AWS 上で稼働する SAP Cloud ERP Private を統合することで、e コマースインフラストラクチャのモダナイゼーションをますます進めています。正しく設計されたとき、この統合モデルはセキュリティ、高いパフォーマンス、そして運用のシンプルさをもたらします。本ブログでは、4 つの重要な観点、すなわち 1) リージョン選択、2) レイテンシー最適化、3) ネットワーキング、4) セキュリティ実装にわたって、実証済みのアーキテクチャのベストプラクティスを探ります。これらのプラクティスは、SAP Commerce Cloud と AWS 上でホストされる SAP ランドスケープとの間で、堅牢かつスケーラブルな統合を構築するのに役立ちます。 SaaS は一貫性のある予測可能なユーザー体験を提供するように設計されている あらゆる SaaS プラットフォームの中核的な強みは、オンラインでアクセスできる場所であればどこからでも、一貫性のある予測可能なユーザー体験を提供できる点にあります。SAP Commerce Cloud はまさにこの目的のために構築されています。これは、リージョンやネットワークを越えて、買い物客、パートナー、モバイルデバイス、バックエンドシステムにサービスを提供します。ネットワークの変動、レイテンシーの差異、地理的に分散したアクセスに対応することは、このプラットフォームの基本的な設計原則です。 この運用モデルは、今日の大企業における標準的な実践です。企業は、CRM、人事、決済処理、物流、分析プラットフォームなど、複数の SaaS アプリケーションを自社のコアシステムと日常的に統合しています。SAP Commerce Cloud も、この実証済みの同じパターンに従っており、多様な SaaS ソリューションを AWS 上の SAP Cloud ERP Private と統合することは、現在のエンタープライズ標準となっています。 ベストプラクティス 1: リージョン選択 統合パフォーマンスを最適化するため、最も近い AWS リージョンを選択してください。AWS はグローバルなリージョンネットワークを運用しており、企業は SAP S/4HANA のデプロイを Commerce Cloud のエンドポイントと地理的に整合させることができます。鍵となるのは、SAP Commerce Cloud のホスティング場所に地理的に最も近い AWS リージョンを選択することです。このアプローチにより、ラウンドトリップのレイテンシーを最小化し、2 つのプラットフォーム間のリアルタイム API 呼び出しの応答性を向上させます。最も近い AWS リージョンを選択する際に、エンドユーザーの所在地と SAP Commerce Cloud のホスティングリージョンの両方を考慮することで、企業は予測可能で効率的な接続性を実現できます。このリージョン近接性の戦略は、複雑なネットワーク構成を必要とせずにクロスプラットフォーム統合を最適化するための、実践的かつ非常に効果的な方法です。 SAP Commerce Cloud リージョン AWS 上で稼働する SAP Commerce Cloud 向け Intelligent Selling Services * 推奨される最も近い AWS リージョン オーストラリア: ニューサウスウェールズ アジアパシフィック（シドニー）– ap-southeast-2 ブラジル: サンパウロ 南米（サンパウロ）– sa-east-1 カナダ: トロント カナダ（中部）– ca-central-1 中国: 香港 アジアパシフィック（香港）– ap-east-1 中国: North 3 中国（北京）– cn-north-1 中国: 上海 中国（寧夏）– cn-northwest-1 ドイツ: フランクフルト ドイツ: フランクフルト ヨーロッパ（フランクフルト）– eu-central-1 インド: プネ アジアパシフィック（ムンバイ）– ap-south-1 日本: 東京 アジアパシフィック（東京）– ap-northeast-1 オランダ: アムステルダム ヨーロッパ（アムステルダム）– eu-west-3 またはヨーロッパ（アイルランド）– eu-west-1 シンガポール アジアパシフィック（シンガポール）– ap-southeast-1 英国: ロンドン ヨーロッパ（ロンドン）– eu-west-2 アラブ首長国連邦: ドバイ 中東（UAE）– me-central-1 米国: カリフォルニア 米国西部（北カリフォルニア）– us-west-1 または米国西部（オレゴン）– us-west-2 米国: バージニア 米国東部（バージニア北部） 米国東部（バージニア北部）– us-east-1 米国: バージニア (2) 米国東部（バージニア北部）– us-east-1 または米国東部（オハイオ）– us-east-2 * SAP Commerce Cloud 向けの Intelligent Selling Services は、コマースプラットフォーム全体でお客様体験を高めるリアルタイムのパーソナライゼーションを提供します。 参照: ガイダンスについては、 SAP データセンターの所在地 および AWS グローバルインフラストラクチャ をご参照ください。 ベストプラクティス 2: レイテンシー最適化 優れたユーザー体験のための CDN の活用 重要な最適化手法の 1 つは、コンテンツ配信ネットワーク（CDN）を活用して買い物客の体験を向上させ、ストアフロントのパフォーマンスを加速することです。SAP Commerce Cloud のストアフロントは、画像、スクリプト、スタイルシート、商品メディアといった静的コンテンツに大きく依存しており、これらは CDN を通じて効率的にキャッシュおよび配信できます。 Amazon CloudFront は、静的コンテンツの配信とストアフロント API のパフォーマンスの両方を大幅に強化できます。SAP Commerce Cloud へのストアフロント API リクエストを適切にキャッシュすることで、CloudFront はバックエンドシステムの負荷を軽減しながら、エンドユーザーの応答時間を改善します。この二重の最適化、すなわち静的コンテンツ配信の高速化と API オーバーヘッドの削減により、地理的な場所を問わず、高速で一貫性のあるストアフロントのパフォーマンスが確保されます。 CloudFront は、SAP Commerce Cloud がどこにホストされていても、コンテンツ配信を加速するグローバルに分散したエッジネットワークを提供します。ユーザーに近いエッジロケーションでストアフロントのアセットをキャッシュすることで、企業はコアアプリケーションのアーキテクチャを変更することなく、ページの読み込み時間を短縮し、お客様体験を向上させます。 詳細は AWS ブログ : Supercharge your SAP Composable Storefront with Amazon CloudFront をご参照ください。 ミドルウェアがレジリエントなクラウド間の対話を実現する SAP BTP Integration Suite のような堅牢なミドルウェアレイヤーは、SAP Commerce Cloud と SAP Cloud ERP Private システムとの間の信頼性の高い統合に不可欠です。SAP Integration Suite、API ゲートウェイ、イベントブローカーといったプラットフォームは、アプリケーションを疎結合にするマネージドな通信チャネルを構築し、リクエストのキューイング、リトライ、変換、非同期処理を可能にします。 このアーキテクチャパターンにより、一時的なネットワーク遅延やレイテンシーの変動が、重要なビジネストランザクションを妨げることは決してありません。ミドルウェアはまた、キャッシュ、オーケストレーション、監視の機能を提供し、クラウド間のやり取りを円滑にし、システム全体のレジリエンスを向上させます。このようにミドルウェアを実装することは、ハイブリッドクラウド統合における十分に確立されたベストプラクティスであり、クラウドプロバイダーの整合性や地理的な近接性への依存を排除します。 非同期統合はレイテンシー感度を最小化する SAP Commerce Cloud と SAP S/4HANA との間のほとんどのやり取りは、設計上、非同期です。注文レプリケーション、顧客マスターの更新、カタログ同期、在庫フィードといったプロセスは、API、イベントストリーム、またはメッセージキューを通じて交換されます。これらのビジネストランザクションは、ミリ秒レベルの応答に依存せず、正確性やユーザー体験に影響を与えることなく、通常のインターネットレイテンシーを許容できるように設計されています。 同期統合のベストプラクティス SAP Commerce Cloud のリージョンに最も近い AWS リージョン（通常は同じ都市圏に位置します）を選択すると、SAP Commerce Cloud SaaS を AWS 上の S/4HANA Cloud ERP Private インスタンスと統合しても、意味のあるパフォーマンスへの影響はありません。リアルタイムの価格計算、ライブ在庫チェック、クレジットカード認証、与信限度チェック、または在庫可用性チェックといった、より少数の同期シナリオについても、AWS リージョンと SAP Commerce Cloud のホスティング場所との間の一般的なレイテンシーは、許容範囲内に十分収まります。数十ミリ秒程度の応答時間は、エンタープライズアプリケーションが最適なパフォーマンスのために必要とする閾値をはるかに下回ります。 ベストプラクティス 3: ネットワーキング AWS は、外部の SaaS プラットフォームとの統合をさらに強化する高度なグローバルネットワーキング機能を提供します。 AWS Global Accelerator 、 Regional NAT Gateway 、 Amazon Route 53 といったサービスや、高性能な AWS バックボーンルーティングインフラストラクチャは、エンドユーザー、SAP Cloud ERP Private ワークロード、SAP Commerce Cloud のエンドポイント間の接続性を最適化します。 AWS 内のトラフィックエンジニアリングは、ネットワークの障害を自動的に迂回してルーティングし、地理的に分散したデプロイ全体で一貫したパフォーマンスを維持します。企業は Amazon CloudWatch と VPC フローログ を使用して接続性を監視でき、統合トラフィックのパターンとネットワークの挙動を完全に可視化できます。これらのツールにより、AWS 上でホストされる SAP システムから SAP Commerce Cloud への、予測可能で安全かつレジリエントなアクセスが確保されます。 自動トラフィックエンジニアリング – AWS の自動トラフィックエンジニアリングは、ネットワークの障害を自動的に検出して迂回ルーティングすることで、SAP Commerce Cloud への接続性を強化します。AWS は、インターネットトラフィックのパフォーマンスを向上させるために、いくつかの舞台裏の最適化を実施します。 詳細は How AWS improves global connectivity via automated traffic engineering をご参照ください。 ベストプラクティス 4: セキュリティ AWS 上に構築されるセキュリティとコンプライアンス SAP Commerce Cloud は SaaS として稼働しますが、AWS は SAP Cloud ERP Private ワークロードを保護するための可能な限り最も強固な基盤を提供します。AWS は 140 を超えるコンプライアンス認証と、包括的なネイティブセキュリティサービス群を提供します。Identity and Access Management、暗号化、ネットワークファイアウォール、ロギング、監視により、SAP 環境に対する多層防御（defense-in-depth）モデルが実現します。 AWS 上の SAP Cloud ERP Private システムと SAP Commerce Cloud との間のすべての通信は、HTTPS や TLS といった標準的で安全なインターネットプロトコルを介して行われます。OAuth、API トークン、相互 TLS といった認証メカニズムは、ホスティングプロバイダーを問わず一貫して機能します。企業はすでに、銀行、決済ゲートウェイ、その他の重要な SaaS サービスへの接続に、日常的にこれらと同じ手法を利用しています。 AWS の優先事項について詳しくは、 AWS Culture of Security をご参照ください。 ベストプラクティス 5: Amazon 全体のサービスとの統合 さらに、SAP Commerce Cloud を Amazon のフルフィルメントサービスで拡張できます SAP Commerce Cloud を運用している企業は、Amazon のフルフィルメントサービス、すなわち Buy with Prime および Amazon Multi-Channel Fulfillment（MCF） と統合することで、既存のストアフロントとビジネスプロセスを維持しながら、Amazon の物流ネットワークを活用し、e コマース業務を強化できます。 Buy with Prime との統合 Buy with Prime により、ブランドは、迅速で送料無料の配送、簡単な返品、24 時間 365 日のサポート、Amazon のレビューといった Prime のショッピング特典を、自社のウェブサイト上で直接提供できます。SAP Commerce Cloud と統合することで、事業者は信頼されるショッピング体験によってお客様を惹きつけ、維持できます。調査結果によると、買い物客の 95% が Buy with Prime を再び利用する可能性が非常に高く、事業者は買い物客あたりの収益が平均 16% 増加しています。 Amazon Multi-Channel Fulfillment（MCF） Amazon MCF は、事業者がすべての販売チャネルにわたるピッキング、梱包、出荷、配送に Amazon のフルフィルメントネットワークを活用できるようにする、サードパーティロジスティクス（3PL）ソリューションです。SAP Commerce Cloud の事業者は、Amazon のネットワーク内で単一の在庫プールを使用することで、在庫切れ率の低減、在庫回転率の改善、業務効率の向上を実現できます。事業者からは、Amazon 以外のチャネルに MCF を追加して以降、売上または収益が平均で約 19% 増加したと報告されています。 SAP S/4HANA との統合の加速 SAP S/4HANA 向けの Amazon MCF および Buy with Prime アクセラレーター は、SAP Business Technology Platform（SAP BTP）を SAP Integration Suite および Amazon の事前構築済み API とともに活用することで、統合作業を最大 75% 削減し、多くのお客様が 6 週間未満で本番稼働できるようにします。この統合により、SAP のお客様は、既存の SAP S/4HANA のビジネスプロセスを妨げることなく Amazon のフルフィルメントインフラストラクチャを活用でき、既存の SAP ワークフローや構成とシームレスに連携する一般的なやり取りをすぐに利用できます。 SAP および AWS サポートから支援を受ける方法 AWS と SAP は、RISE with SAP on AWS 向けの Migration Support Service を提供しています。これは、RISE 移行および SAP Commerce Cloud 統合の期間中、迅速なトラブルシューティング、統合の課題、本番稼働支援のために、AWS のテクニカルインフラストラクチャエンジニアへの直接的なアクセスを提供するものです。AWS-SAP のエキスパートが戦略的なアドバイザリーとインフラストラクチャの専門知識を提供し、SAP と連携して迅速な課題解決と最適なパフォーマンスを実現することで、ミッションクリティカルな RISE with SAP on AWS ワークロードのより速く、よりスムーズな移行を確実にします。 まとめ SAP Commerce Cloud を AWS 上の SAP Cloud ERP Private と統合することは、業界全体で広く採用されている、実証済みで信頼性の高いエンタープライズアーキテクチャパターンです。SaaS プラットフォームは、インターネットベースで地理的に分散したアクセスを前提に、一から設計されています。非同期統合、ミドルウェア主導の通信、最適な同期統合レイテンシーのための SAP Commerce Cloud ホスティング場所に最も近い戦略的な AWS リージョン選択、そして CDN による高速化により、あらゆるデプロイシナリオで優れたパフォーマンスが確保されます。 AWS は、ミッションクリティカルな SAP Cloud ERP Private ワークロードに対して、セキュリティ、レジリエンス、運用面の成熟度の最適な組み合わせを提供します。同時に、そのグローバルネットワーキング機能により、SaaS プラットフォームとの統合を容易かつ信頼性の高いものにします。 適切なアーキテクチャ設計とベストプラクティスの遵守により、企業は、コアとなる SAP ランドスケープの最適な基盤として AWS を活用しながら、SAP Commerce Cloud によって自社のコマースプラットフォームを自信を持ってモダナイゼーションできます。このハイブリッドモデルは、成功しているデジタルビジネスが今日どのように運営されているか、すなわち柔軟で、分散されており、クラウドプラットフォーム全体でシームレスに接続されている姿を反映しています。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

背景 最近の調査（ McKinsey ）によれば、世界中のエンタープライズ ERP システムでは毎月膨大な数の手作業による介入が発生し、波及しています。たとえば、あるグローバル製造企業では、入金された銀行支払いが請求書と何日も突き合わせられないまま残り、キャッシュフローを悪化させ、売掛金（AR）チームが日々数百件の取引を手作業で消し込むことで売上債権回転日数（DSO）が膨らんでいます。ここで、内部統制マネージャーに「AI がこれらの支払いを自動的に消し込み、計上します」と提案する場面を想像してみてください。返ってくる答えは決まって「間違いを起こさないとどうして分かるのか？」です。複雑な業務プロセスを AI に確実に実行させることへの信頼は、今日多くのユーザーが直面している最大の課題のひとつであり続けています。 SAP のスリーウェイマッチのような高度な組み込み自動化でさえ十分とは言えず、請求書の例外、購買発注（PO）の承認ブロック、月次決算、会社間消し込みなど、ほぼあらゆる業界で手作業の介入が横断的に発生しています。これまでの自動化アプローチも同様でした。ロボティック・プロセス・オートメーション（RPA）は UI のクリック操作を自動化しましたが、画面レイアウトが変わると壊れてしまいました。従来型の機械学習（ML）は例外を予測できても、それを解決することはできませんでした。 お客様の IT ランドスケープは、SAP インスタンス、レガシーシステム、クラウドサービス、サードパーティアプリケーションが入り乱れたパッチワークとなり、それぞれが互換性のないプロトコルと分断されたデータを抱え、ますます複雑化しています。SAP は財務報告の検証済みコアとして機能します。したがって、システム横断的な自動化はいずれも、Sarbanes-Oxley 法（SOX）、ISO、内部監査の要件を満たすために、セキュアなアクセス制御、検証済みのユーザー ID、完全な監査証跡を強制する必要があります。 状況を変えたのは、非構造化された手順を推論し、システム境界を越えてツールを呼び出し、複数ステップのワークフローにわたってコンテキストを維持できる基盤モデル（foundation model）の登場です。 これらの例外を大規模に解決するには、 エージェント型標準作業手順書（Agentic Standard Operating Procedures、SOP） が必要です。これは、ナレッジベースからエンタープライズの手順を解釈し、SAP システムと非 SAP システムをまたいで複数ステップの例外を自律的に解決する、単一かつ統合された AI 駆動エージェントです。判断や承認が必要な箇所では、ヒューマン・イン・ザ・ループ（human-in-the-loop）の制御が働きます。 エージェント型 AI は有望な道を示しますが、新たな課題ももたらします。それは、エージェントがガバナンスの追いつかない速さで増殖していくということです。分断されたシステム間でセキュアに連携するエージェントを構築するのは複雑でコストがかかります。「あらゆる問題に対してエージェントを作る」という無制約なアプローチではなく、段階的に成熟し、各段階で価値を提供し、人間の信頼を漸進的に獲得していく、構造化されたフレームワークが必要です。 本稿では、SAP ユースケース向けの AWS Agentic AI Solutions Framework を紹介します。これは、ヒューマン・イン・ザ・ループ制御による漸進的な信頼、SOP 駆動の統合エージェントアーキテクチャ、決定論的で監査可能なアクションのためのガード付き MCP サーバー、ID を意識したセキュリティとコンプライアンス、監査水準のドキュメンテーションのための永続的な状態管理という 5 つのコア機能に基づいて構築された、プロダクショングレードのアプローチです。続いて、Amazon Bedrock AgentCore を用いて SAP 環境に対してこのフレームワークをデプロイするためのリファレンスアーキテクチャと技術的ベストプラクティスを解説します。 コア機能 さまざまな業界や事業部門のお客様と協働する中で、AWS は、エンタープライズ ERP ランドスケープにおいて安全かつ効果的に稼働するためにお客様のエージェント型 AI システムが備えるべきコア機能のセットに収束しました。次のセクションのリファレンスアーキテクチャは、これらの各機能に対応しています。 リスクを抑えながら段階的に信頼を獲得する： エージェントはまずアドバイザリーモードで開始し、すべてのアクションは人間が実行します。信頼が積み上がるにつれて、エージェントは監督付き実行へと移行し、最終的には、信頼度が定義済みのしきい値を超えた場合にのみ独立して動作する自律的な解決へと進みます。自動化は、信頼を確立した分だけ拡大していきます。 すべてのプロセスに 1 つのエージェントをデプロイする： 業務プロセスごとに別々のエージェントを構築する代わりに、単一のエージェントが、キュレーションされたナレッジベースから SOP を動的に解釈・実行し、例外の種類やプロセスのコンテキストに応じて適切なツールを実行時に呼び出します。お客様の業務チームが SOP を自然言語で作成・所有するため、変更にはコードの再デプロイではなく SOP の更新だけで済みます。エージェントは SOP を厳格なルールではなく推論のコンテキストとして扱い、キュレーションされたプロンプト、構造化されたツールオーケストレーション、ガードレールを通じて、あらゆるステップを決定論的かつ監査可能に保ちます。 一貫した再現性のある結果を得る： 同じ入力は、常に同じ出力を生成しなければなりません。大規模言語モデルは本質的に確率的であるため、決定論（モデルがハルシネーションを起こしたり一貫性のない結果を生成したりするのを防ぐこと）を達成するには意図的な制御が必要です。本ソリューションは、制御されたモデルパラメータ、構造化されたプロンプトエンジニアリング、ハルシネーションを防ぐための信頼できる SOP コンテンツとライブシステムデータからの取得、ポリシーとグラウンディング検証のための実行時ガードレール、アクション実行前に推奨事項をクロス検証するマルチエージェントによる相互検証を通じて、これを強制します。 誰が、いつ、何をしたかを正確に把握する： すべてのエージェントのアクションを適切な ID に帰属させなければなりません。エージェントが自律的に動作する場合は自身のサービスアカウントで認証し、人間が介入する場合はシステムがその人間の検証済み ID に切り替えます。この分離により、コンプライアンスチームはエージェントのアクションと人間が承認したアクションを区別できます。あらゆるツールの呼び出し、データの読み取り、アクションは、SOX、ISO、内部監査の要件を満たす改ざん検知可能な証跡とともにログ記録されます。 初日から監査担当者と運用チームを満足させる： 専用の永続的な状態レイヤーが、例外のライフサイクル全体を記録します。エージェントの推論トレース、認証済み ID を伴うツールの呼び出し、人間へのエスカレーションイベント、解決結果を、すべて不変（immutable）で追記専用（append-only）のレコードとして保持します。リアルタイムのオブザーバビリティがエージェントのパフォーマンスを監視し、振る舞いが想定されるベースラインから逸脱した際に運用チームへ通知します。 リファレンスアーキテクチャ 高いレベルで見ると、本アーキテクチャは ERP の例外をスケジュールに従って検知し、AI エージェントを呼び出して該当する SOP を取得し、SAP および接続されたシステム全体で例外を解決し、監査コンプライアンスのためにあらゆるステップをログ記録します。信頼度が低い場合や承認が必要な場合、エージェントは人間へエスカレーションし、返答を受け取ると再開します。 下記の図 1 は、エンドツーエンドのアーキテクチャを示しています。このアーキテクチャには 3 つの境界があります。お客様の SAP 環境、AWS クラウド、そしてオプションのユーザーインターフェイスです。ここでは、単一の例外が検知から解決までシステム内をどのように流れるかを説明します。 例外検知（Exception Detection）： Amazon EventBridge が、設定可能なスケジュール（デフォルト：5 分ごと）で AWS Lambda 関数をトリガーし、SAP OData サービスをポーリングして新しい例外（ブロックされた請求書、突合できない支払い、欠落した引当金、または SOP が定義する任意の例外タイプ）を検出します。 状態の初期化（State Initialization）： ポーラーは、新しい例外ごとに Amazon DynamoDB の状態テーブルへ status を detected として書き込み、解決に必要な最小限のコンテキスト（PO 番号、総勘定元帳（GL）アカウント、コストセンター）を記録します。重複排除チェックにより、同じ例外が二重に処理されるのを防ぎます。 エージェントの呼び出し（Agent Invocation）： システムは、DynamoDB Streams トリガー経由で自律的に、またはユーザーインターフェイスを通じて手動で、エージェントを呼び出します。エージェントは、AI エージェントの構築・デプロイ・スケーリングのためのフルマネージドサービスである Amazon Bedrock AgentCore 上で稼働し、エージェントフレームワークには AWS のオープンソースのエージェント型 SDK である Strands を使用します。 ツール接続（Tool Connectivity）： カスタム統合コードなしにエージェントへ SAP やその他のシステムへのアクセスを与えるため、マネージドな 2 つの経路のいずれかで接続します。 AgentCore Runtime 上でホストされる MCP サーバー（サンプルコードに含まれています） 大規模でマネージド・ガバナンスされたツールアクセスのための AgentCore Gateway SOP の取得（SOP Retrieval）： すべての解決が承認済みのプロセスに従うことを検証するため、エージェントの最初のツール呼び出しは、エンタープライズコンテンツをインデックス化・チャンク化・取得するフルマネージドの RAG 機能である Amazon Bedrock Knowledge Base から該当する SOP を取得し、処理対象の例外タイプに対する意思決定ツリーを確立します。 SAP の実行（SAP Execution）： ハードコードされた API マッピングを排除し、保守負担を軽減するため、エージェントは SAP OData API 仕様 を含む 2 つ目の Knowledge Base を使用して、正しいエンドポイントとフィールドを実行時に発見し、SAP に対して読み取り・書き込み操作を実行します。これにより、ハルシネーションによる API 呼び出しを防ぎます。エージェントは、ドキュメント内に見つけられるエンドポイントのみを呼び出します。 監査証跡（Audit Trail）： 各ステップで、エージェントは DynamoDB 内の不変な processing_history リストに追記し、以下を記録します。 推論トレース： ステップごとのロジックと取得した SOP のセクション ツールの呼び出し： 入力、出力、タイムスタンプ、認証済み ID 解決結果： 実行された最終アクションと SAP のトランザクション参照 この追記専用ログ（レコードは追加できるが、変更・削除は決してできない）が、SOX と内部監査コンプライアンスのための改ざん検知可能な監査証跡となります。 人間へのエスカレーション（Human Escalation）： 例外が人間の判断を要する場合（金額が重要性のしきい値を超える、またはエージェントの信頼度が定義済みのレベルを下回る場合）、エージェントは Amazon SES 経由で構造化されたエスカレーションメールを送信し、ケースのステータスを awaiting_human_input に更新して停止します。 人間の応答（Human Response）： 人間が返信すると、SES はそのメールを Amazon S3 に保存し、これが Lambda 関数をトリガーします。この関数はメールスレッド全体を解析し、その応答とともにエージェントを再呼び出しします。エージェントは、完全なコンテキストの連続性を保ったまま、中断したところから正確に処理を再開します。 インターフェイスレイヤー（Interface Layer）： ユーザーインターフェイスは意図的に薄く、差し替え可能です。サンプルコードには Streamlit ダッシュボードが同梱されていますが、AgentCore ランタイムのエンドポイントを呼び出せるクライアントであれば何でも動作します。 React またはカスタム Web アプリ ネイティブな SAP 統合のための SAP Fiori タイル Amazon Quick Apps ：ガバナンスされたノーコードの承認体験のため インターフェイスをまったく持たない ：完全に自律的な運用のため 例：購買発注の引当計上を大規模に自動化する。あるグローバル製造企業は、このフレームワークを適用して、1,000 件を超えるアクティブな PO にまたがる 2 億 5,000 万ドル超のカスタム治工具の購買を管理しました。エージェントは該当する SOP を自律的に取得し、各 PO を適切なワークフローで解決し、財務承認のための仮伝票（parked journal entry）を SAP に作成します。以前は 1 決算サイクルあたり 30 日超の手作業を要していたプロセスが、今では PO あたり数分で完了します。 技術的ベストプラクティス デモで動作するエージェント型システムを作るのは簡単です。プロダクショングレードの信頼性、監査可能性、コスト効率には、意図的なエンジニアリング上の選択が求められます。以下のプラクティスは、プロダクション環境でのデプロイから得られたもので、最も一般的なギャップに対処します。 決定論（Determinism） 同じ入力は、同じ出力を生成しなければなりません。これは、単一のメカニズムではなく、階層化された制御によって達成します。 構造化されたプロンプト： 明示的なテンプレート、システムレベルのルール、振る舞いのフック、出力フォーマットの制約を用いて、推論を定義済みのパターンに固定します。 検索拡張生成（RAG）： Amazon Bedrock Knowledge Bases を介して、あらゆる応答を取得した SOP コンテンツとライブシステムデータにグラウンディングし、エージェントがパラメトリックな記憶ではなく信頼できる情報源から推論するようにします。 実行時ガードレール： コンテキストのグラウンディング検証とポリシーベースのコンテンツフィルタリングのために Amazon Bedrock Guardrails を適用します。 マルチエージェントによる相互検証： リスクが高い場合は、スーパーバイザーエージェントを用いて専門のサブエージェントをオーケストレーションし、アクション実行前に推奨事項をクロス検証します。 ID の伝播（Identity Propagation） すべてのエージェントのアクションを適切な ID に帰属させなければなりません。本アーキテクチャは、デュアル ID モデルをサポートします。 自律運用： エージェントは OAuth 2.0 の 2 レッグ（2LO）認証により自身のサービスアカウントで認証し、各ダウンストリームシステムとのマシン間の信頼関係を確立します。 ヒューマン・イン・ザ・ループ運用： AgentCore Identity が OAuth 2.0 の 3 レッグ（3LO）認証へ移行し、人間の検証済み ID をエージェントを通じて対象システムへ伝播します。 この分離により、コンプライアンスチームは監査ログにおいてエージェントが起動したアクションと人間が承認したアクションを明確に区別できます。これは SOX 統制の中核的な要件です。 Cedar ポリシーによるきめ細かな認可 誰が動作しているかを把握することは必要ですが、それだけでは十分ではありません。各 ID が何をできるかも制御する必要があります。 AgentCore Policy は、AWS のオープンソースの認可言語である Cedar を使用し、AgentCore Gateway を経由するすべてのエージェント-ツール間のやり取りに対してきめ細かな権限を強制します。Cedar ポリシーは 4 つの属性を評価します。 プリンシパル ID： ユーザー名、ロール、スコープなどの OAuth クレーム（上記の 2LO/3LO ID モデルから） アクション： 呼び出される具体的なツール（例：invoke_sap_odata_service や send_email） リソース： リクエストがルーティングされる Gateway リクエストコンテキスト： ツールの入力パラメータ。属性ベースのアクセス制御を可能にします（例：書き込み操作を一定の金額しきい値未満の請求書に制限する） システムはデフォルトですべてのアクションを拒否します。ポリシーは Cedar 構文または自然言語で作成します。AgentCore Policy は平易な英語のルールを解釈して候補となる Cedar ポリシーを生成し、自動推論を用いて、強制する前に過度に許容的または制限的なポリシーを検出します。たとえば、「エージェントは任意の PO を読み取ってよいが、仕訳を計上できるのは 50,000 ドル未満に限る」といったルールを、ツール呼び出しが SAP に到達する前に、Gateway レイヤーで決定論的に強制できます。よくあるパターンについては、 AgentCore Policy のドキュメントをご覧ください。 プロンプトの改善（Prompt Improvement） システムプロンプトは、決定論が始まる場所です。特に重要なのは 3 つのパターンです。 明示的なコンプライアンスのフレーミング： 明示的な優先度シグナル（すべて大文字のラベル、必須を示す表現）を用いて、SOP コンプライアンスを交渉の余地のないものとしてフレーミングします。これにより、モデルが手順に違反する形でワークフローを「最適化」してしまう可能性を減らします。 ハルシネーション防止のガードレール： 人間の入力を待ってブロックされている際に、証拠や承認をでっち上げるのではなく、停止してエスカレーションするようエージェントに指示します。これは、エージェント型システムで最も危険な失敗モードのひとつに直接対処します。 実例（Exemplars）： 正しい振る舞いの具体例、日付計算のフォーマット、エスカレーションメールのテンプレート、OData クエリのパターンなどを、プロンプト内に直接含めます。エージェントは、ゼロから生成するよりも参照実装がある方が高いパフォーマンスを発揮します。 実際の例外データを用いてプロンプトを反復改善し、バージョン間で出力品質を追跡します。 評価（Evaluations） エージェント型システムには、複数のレベルでの評価が必要です。 ユニットレベル： 個々のツール呼び出しの正しさをテストします。OData クエリは期待どおりのフィールドを返すか？ メールには適切なコンテキストが含まれているか？ エンドツーエンド： 期待される結果を伴う既知の例外シナリオに対して、ワークフロー全体をテストします。解決済みのケースからリグレッションスイートを構築し、プロンプトや SOP の変更が既存の振る舞いを劣化させないようにします。 運用メトリクス： ビジネスにとって重要な指標を追跡します。解決精度、エスカレーション率、解決までの時間、誤検知率などです。 リアルタイム監視： AgentCore 向けの Amazon CloudWatch の生成 AI オブザーバビリティ機能を使用して、モデル呼び出しのレイテンシ、トークン消費量、ツール呼び出しの成功率、信頼度スコアの分布を監視します。 コスト最適化（Cost Optimization） スケールしても例外あたりのコストを予測可能に保つために： モデルを適切なサイズにする： 定型的な例外には小さいモデルを使い、大きいモデルは複雑なケースのために温存します。 頻繁に取得するコンテンツをキャッシュする： めったに変わらない SOP ドキュメントや API ドキュメントはキャッシュして、Knowledge Base のクエリ量を削減できます。 インテリジェントなプロンプトルーティング： Amazon Bedrock のプロンプトルーティング を使用して、呼び出しごとに最もコスト効率の高いモデルを自動的に選択します。 運用のレジリエンス： ピーク時のボリュームではジッター付きの指数バックオフを実装し、コストの可視化のために例外タイプ別にトークン消費量を追跡します。 オブザーバビリティと状態管理 運用チームと監査担当者の双方を満足させるため、プロダクションのエージェント型システムには 3 つのレイヤーの状態が必要です。 短期セッションメモリ： 単一の解決内でのコンテキスト（会話履歴、ツール呼び出しの結果、中間的な推論）を維持します。 長期メモリ： AgentCore Memory を介して、セッションをまたいで学習したパターンを永続化します。たとえば、既知の PO フォーマットの問題により一貫して例外を発生させるベンダーを認識するなどです。 永続的な監査水準の状態： DynamoDB 内で、例外のライフサイクル全体を不変で追記専用のレコードとして記録します。推論トレース、認証済み ID を伴うツールの呼び出し、エスカレーションイベント、人間の意思決定、解決結果です。 まとめと次のアクション エージェント型 AI は、ERP の例外管理の経済性を根本的に作り変えます。プロセスごとに個別のエージェントを構築・保守する代わりに、組織は、実行時に手順を解釈し、適切なツールを呼び出し、状況が求めるときに人間の判断へエスカレーションできる、単一の SOP 駆動エージェントをデプロイできます。漸進的な導入フレームワークは、自動化が信頼を確立した分だけ拡大することを検証し、ID を意識したアーキテクチャは、エージェントが起動したものであれ人間が承認したものであれ、あらゆるアクションを完全に帰属・監査できることを保証します。 リファレンス実装は、Strands エージェント、SAP OData 統合を備えた MCP サーバー、DynamoDB による状態管理、ヒューマン・イン・ザ・ループのワークフローを含むオープンソースのサンプルコードとして利用可能です。可視化のための Streamlit ダッシュボードも同梱されています。Knowledge Base 内の SOP を更新するだけで、コードを変更することなく、お客様の例外タイプに合わせて適応できます。 まずは、 GitHub リポジトリの ERP 例外管理ソリューション をダウンロードし、SAP OData 統合のための AWS for SAP MCP Server をセットアップしてください。 本稿で参照したサービスをより深く知るには、Amazon Bedrock AgentCore 、 Amazon Bedrock Knowledge Bases 、 Strands Agents SDK をご覧ください。 著者について Sagar は、AWS でエージェント型 AI と生成 AI を活用して業務プロセスを自動化し、レガシーシステムをモダナイズすることで、エンタープライズのデジタルトランスフォーメーションを支援することを専門としています。SAP ワークロードに注力し、お客様が AI を用いて移行・モダナイゼーション・自動化を進めるためのツールとソリューションを構築しています。仕事以外では、テクノロジーへの情熱と、家族と過ごすかけがえのない時間、Formula 1 への深い愛、そして Sachin Tendulkar のクリケットの功績への変わらぬ敬意とのバランスを取っています。 Zach Daniels は、AWS のソリューションアーキテクトで、AWS for SAP を専門とし、ERP 向けのエージェント型 AI アプリケーションに注力しています。お客様と協働して、スケーラブルで Well-Architected な SAP 環境を AWS 上で設計しています。シアトルを拠点とし、スタートアップと技術エンジニアリングでの経験をエンタープライズのお客様との仕事に活かしています。 Abhijeet は、複数の業界にまたがって戦略とデリバリーを主導してきた、20 年以上の SAP テクノファンクショナル経験を持つデータ・AI リーダーです。AWS の SAP データアナリティクス戦略、エージェント型コードモダナイゼーション、AI 駆動のプロセス自動化イニシアチブを牽引しています。コロラドの山でのハイキングとスキーを楽しんでいます。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに 本記事は、 株式会社レスター （以下、レスター）の加瀬 友基 氏による寄稿記事です。 レスターでは、各社・各部門に分散していた営業情報を一つの土台に集める AI 情報プラットフォームを構築しています。中核となるレスターマッチングサービス（以下、RMS）は、顧客ニーズと企業・技術・製品などの解決手段を結びつけるマッチングの仕組みであると同時に、顧客・仕入先、取引実績、担当者との接点、商材、案件、議事録などを相互の関係性を保ったまま蓄積する、グループ共通のデータウェアハウスです。商談時の録音データを AI が議事録としてデータ化し、RMS へ取り込み、AI チャットボット機能で RMS 内の蓄積された情報から必要な知見を引き出します。これにより、ある部門がつかんだ顧客課題を、別部門が持つ人・商材・技術へつなげます。本稿では、この仕組みを構築した背景、Amazon Web Services（以下、AWS）の活用、そして情報を蓄積し続けるための運用についてご紹介します。 レスターとは レスターグループは、「情報と技術で、新しい価値、サービスを創造・提供し、社会の発展に貢献します」の経営理念のもと、半導体・電子部品の販売・ソリューション提供をはじめ、映像・音響・通信機器の取り扱い、太陽光発電などの再生可能エネルギーの企画・オペレーション、完全閉鎖型植物工場の運営、ソフトウェア開発、産業用PCの設計・製造など多岐にわたる事業活動を行っています。 グループの多様な強みを一つの提案力に変えるために 事業領域の拡大とグループ再編の結果、グループが持つ顧客基盤、商材、技術、知見は大きく広がりました。一方で、各社・各事業は、もともとの顧客や商流、情報の持ち方、業務プロセスが異なります。子会社・事業・部門が「どの顧客と接点を持ち、何を得意とし、どのような商材や知見を持つのか」を、日々の営業活動の中で十分に把握することは容易ではありませんでした。 お客様の課題は、必ずしも一つの事業領域だけで完結するものではありません。グループ内に解決手段があっても、必要な情報や担当者にたどり着けなければ、提案にはつながりません。グループの多様な強みを一つの提案力に変えるためには、会社・事業・部門を越えて情報を見つけ、活用できる仕組みが必要です。レスターは「あらゆるニーズに対応できる『エレクトロニクスの情報プラットフォーマー』」をビジョンに掲げています。このビジョンが目指しているのは、例えばステークホルダーの課題を自部門の知識だけで答えるのではなく、グループ全体から最適な人・商材・技術を探し出し、事業横断で提案できる状態を指しています。一つひとつの顧客課題と、グループが持つ多様な解決力を結び付け、あらゆるニーズに応えられるエレクトロニクスの総合商社へと進化することを目指しています。 現場で起きていた、4 つの情報の断絶 背景にある課題を営業の現場で分解すると、単に情報が複数のシステムへ分散していたというだけではありません。会社・事業・部門の境界を越えて、情報の所在と文脈を理解し、次の行動へ移すまでの各段階に断絶がありました。 商談内容の属人化 : 商談の詳細は個人のメモやファイルに残り、組織の知識になりにくい SFA では残らない文脈 : 営業支援システム（SFA）は案件金額や進捗管理に有効でも、顧客の背景や会話の文脈までは十分に残りにくい グループ理解の属人化 : 会社・事業への理解が担当者の経験に依存し、他部門の得意分野、取扱商材、顧客接点まで把握しにくい 訪問前準備の負荷 : 情報収集が担当者の経験と人脈に依存し、訪問前準備に時間がかかる この状態でチャットボットだけを導入しても、参照する情報が古い、少ない、偏っているという問題は解消しません。私たちは、情報が生まれる現場から、会社・事業を越えた蓄積、検索、提案までをつなぐ必要があると考えました。 RMS を中核に、商談の会話から次の提案までをつなぐ こうした 4 つの情報の断絶を解消するため、情報の流れを「データ化する」「蓄積・統合する」「引き出し、提案へつなぐ」の 3 段階に整理しました。それぞれを AI 議事録、RMS、AI チャットボットが担い、商談で得た情報が次の提案に使われるまでを一本につなぎます。 図 1：顧客課題とグループの解決力をつなぐ情報プラットフォーム 1. AI 議事録：会話を「検索できる営業資産」に変える AI 議事録では、オンライン会議や対面商談の録音データと、会議で使用した資料を取り込みます。音声ファイルを Amazon Simple Storage Service (Amazon S3) に保存し、Amazon Transcribe で文字起こしと話者分離を行います。その結果を Amazon Bedrock 上の Anthropic Claude に渡し、会議概要、発言内容、顧客課題、決定事項、次回アクションなどを所定の形式で整理します。生成した議事録や案件情報は、必要に応じて RMS や SFA へ連携します。 Amazon Transcribe では、独自の音声認識モデルを構築することなく音声をテキスト化し、話者分離によって複数人の会議を発言者単位で整理できます。Amazon Bedrock については、社内外の商談情報を扱うため、安全性と統制を効かせながら生成 AI を利用できる点を重視しました。 従来、議事録は会議後の記録作業でした。今回の構想では、議事録を営業データの入口と位置づけています。会話には、顧客の言葉、困りごとの背景、検討状況、関係者、次の打ち手といった、SFA の数値項目だけでは表現しきれない鮮度の高い情報が含まれるためです。 2. RMS：全社の営業情報をつなぐデータウェアハウス RMS には、顧客・仕入先の基礎情報、取引実績、名刺・接点、従業員、商材、SFA の商談情報、Web サイト経由の問い合わせ、そして AI 議事録などを集約しています。単にファイルを保管するのではなく、顧客、担当者、商材、課題、案件の関係性を保ったまま蓄積することが特徴です。 この構造により、顧客を起点に、グループ各社の取引実績、過去の商談、社内の担当者、関連する商材や解決策を横断的にたどることができます。部門ごとに分かれていた情報を、次の提案に使える形で結びつけることが RMS の役割です。 また、レスターグループ各社で取り扱っている多様な商材ごとにビジネスオーナーを置き、内容の最新化、公開範囲、分類を管理する運用を整えています。AI の回答品質は、モデルの性能だけでなく、参照データの鮮度と網羅性に左右されます。そのため、コンテンツマネジメントをシステム運用の一部ではなく、事業側の役割として設計しました。 3. AI チャットボット：必要な情報を引き出し、次の一手へつなぐ AI チャットボットは、RMS に蓄積された情報を業務で使うための対話型インターフェースです。LangGraph で構築した AI エージェントを Amazon Bedrock AgentCore Runtime 上で動作させ、RMS から呼び出した回答をストリーミング表示します。独自に設計した検索・回答の処理を維持しながら、AWS 上の実行環境として RMS と連携できる点を評価しました。 社内文書や議事録の検索には、Amazon Bedrock Knowledge Bases と、そのベクトルストアである Amazon OpenSearch Serverless を利用しています。Amazon S3 は元データの保管先であり、質問のたびにファイルを直接検索するのではありません。会社、商材、案件、担当者などの構造化データが必要な場合は、Catalog API を通じて PostgreSQL から取得します。標準設定では外部 Web 検索を行わず、社内情報に基づく回答を優先しています。 代表的な利用シーンは次の通りです。 訪問前準備 : 対象企業の取引実績、接点、過去の議事録、進行中の商談をまとめる クロスセル : 別部門の議事録にある潜在ニーズと、グループ内の商材・ソリューションを結びつける 提案準備 : 顧客の状況に応じた提案の骨子やトークスクリプトを作る 社内探索 : 商材の担当者、類似案件の経験者、協業可能な部門を探す 利用場面に応じたボタンを用意しており、選択すると「明日この会社へ訪問するので、グループ全体の取引と商談を整理して」といった質問文が自動入力されます。利用者は最初から精緻なプロンプトを書く必要はなく、回答を見ながら追加質問で深掘りできます。回答は結論ではなく、営業が原典や担当者を確認し、次の行動を考えるための出発点です。 AWS を活用した構成と、安全な利用のための設計 AWS を採用した理由は、音声データの保管、文字起こし、議事録の生成、社内情報の検索、回答生成までを、一つのクラウド環境で連携できることです。Amazon S3、Amazon Transcribe、Amazon Bedrock、Amazon Bedrock Knowledge Bases、Amazon OpenSearch Serverless、Amazon Bedrock AgentCore Runtime を組み合わせることで、システム間連携の複雑さを抑えながら、情報が増え続ける前提の基盤を構築しました。また、当社の汎用生成 AI 環境では、AWS がオープンソースで公開する Generative AI Use Cases（GenU） も活用し、そこで得た知見を社内ユースケースの設計に生かしています。 図 2 は、RMS、AI 議事録、AI チャットボットと、今回利用している主な AWS サービスの関係を示したものです。 図 2：AI 情報プラットフォームの AWS アーキテクチャ 主な AWS サービスと役割 Amazon S3 : 音声・資料・正規化済みドキュメントの保管 Amazon Transcribe : 音声の文字起こしと話者分離 Amazon Bedrock : Anthropic Claude による議事録の要約・構造化と、チャット回答の生成 Amazon Bedrock AgentCore Runtime : LangGraph で構築した AI エージェントの実行 Amazon Bedrock Knowledge Bases / Amazon OpenSearch Serverless : 社内文書・議事録の RAG 検索 Amazon Bedrock では、入力したデータや生成結果が基本モデルの改善に使用されることはなく、モデルプロバイダーと共有されることもありません。また、Amazon Bedrock 内のデータは転送中も保管中も暗号化されます。商談や取引に関する情報を扱うため、こうした AWS 側の仕組みに加え、レスター独自の権限設定と運用ルールを設けています。主な対策は次の通りです。 録音時の同意 : 社外商談は事前に相手先の許可を得る 参照対象の選択 : 議事録ごとに社内 AI チャットボット回答時の参照対象へ含めるかを選択し、秘匿性の高い会議は除外する 競合情報の制御 : 担当サプライヤーに応じて競合情報の閲覧を制限する仕組みを設ける 人による最終判断 : AI 回答は参考情報として扱い、重要な判断や社外提出前には原典・担当部署を確認する 特に、「AI に学習させる」という言葉は、モデル自体の追加学習と RAG での参照を混同しやすいため、運用説明では「社内 AI 回答時の参照対象に含めるか」と表現するようにしています。技術的な安全性だけでなく、利用者が誤解しない言葉を選ぶことも重要だと考えています。 導入で難しかったのは、技術よりも「情報が集まり続ける運用」 AI チャットボットの回答は、参照する情報以上には良くなりません。特定の利用者だけが議事録を登録すれば、回答もその部門や担当者に偏ります。商材情報が更新されなければ、AI は古い内容を基に回答します。 そこで、半導体・電子部品を扱うデバイス事業部門から段階的に利用を開始し、社員を対象とした説明会（延べ 500 名以上が参加）、商材ビジネスオーナーへの登録レクチャー、利用フィードバックの回収を実施しました。スマートフォンから録音・登録できる導線も整え、現場が無理なく情報を残せるよう改善を続けています。 運用上の学び : 情報を集めたい運営側は入力項目を増やしがちですが、現場はまず「楽になること」を求めます。AI 議事録で日常業務の負担を下げ、その結果として質の高いデータが蓄積される順序が重要でした。 現在の活用と、見えてきた効果 情報を蓄積する側では、AI 議事録が営業データの入口として回り始めています。社内調査を基に、1 件あたり約 23 分の議事録作成時間を削減できると試算しており、2026 年 7 月現在、月間 2,000 件を超える議事録が作成されています。ただし、私たちが重視しているのは削減時間よりも、毎月 2,000 件を超える商談・会議の情報が、統一形式で検索・分析・再利用できるデータとして蓄積されていく点です。長期的にはこちらの方が大きな価値を生むと考えています。 情報を引き出す側では、2026 年 6 月に AI チャットボットを公開し、利用データと現場の声を基にチューニングを続けています。RMS には取引・接点情報、AI 議事録、SFA 情報、商材情報などが連携され、これまで人に聞くか複数システムを調べていた作業を、1 つの対話画面から始められるようになりました。たとえば、訪問先についてグループ内の取引金額と担当者、過去の商談経緯をまとめる、別部門の顧客課題に対して自部門のソリューションを提案できないか探索する、特定製品を扱う担当者と関連商材を同時に確認する、といった使い方が始まっています。 一方で、現時点は完成形ではありません。登録されていない取引や議事録があれば回答には現れず、情報を入力する利用者が偏れば結果にも偏りが出ます。こうした不足を可視化し、システム、データ、運用の 3 つを同時に改善できることも、パイロット運用の成果だと捉えています。 今後の展開：事業横断で、提案と行動を生む基盤へ 生成 AI を業務に定着させるために必要なのは、高性能なモデルだけではなく、日常業務の中で情報が生まれ、整い、使われ、更新され続ける仕組みです。AWS では、AI を安全に利用するための機能が揃っており、新しい機能も継続的に追加されるという点で、当社の取り組みのような社内横断的な情報の整備、AI 活用を推し進めることができると考えています。今後は、顧客ニーズとグループ内の商材を継続的に照合し、AI が提案候補や新規開拓リストを提示する仕組み、部門を越えて適切な担当者や知見へつなぐ仕組みも検討しており、実際の利用状況と蓄積データを見ながら、顧客・商談・商材・担当者・議事録の関係性をより活用しやすい形へ発展させます。 営業担当者個人の経験や人脈だけに依存せず、ある部門が捉えた顧客課題を、別部門の商材やソリューションへつなげます。半導体・電子部品からシステム、映像・通信、エネルギーまで、レスターグループが持つ幅広い解決手段を一つの営業基盤から活用できる状態を目指します。目指しているのは、社内検索の効率化だけではありません。顧客との会話から課題を捉え、グループ全体の知識と解決手段を組み合わせ、顧客自身も気づいていない潜在ニーズに対して最適な解決策を提案できる営業基盤です。その結果として、新しい顧客と新しいビジネスが継続的に生まれる状態を目指します。 おわりに レスターが構築しているのは、単体のチャットボットではなく、営業活動で生まれた情報を会社の資産に変え、再び営業へ戻す仕組みです。商談の会話がデータになり、関係性を保ったまま蓄積され、必要なときに引き出される。この循環が回るほど、商談を重ねた分だけ会社の知識が積み上がり、事業横断の提案力が高まります。AWS のサービスを活用しながら、この情報循環をレスターグループ全体へ広げ、各事業の強みを一つの提案力へ変えていきます。「まずレスターに相談すれば、解決の糸口が見つかる」という世界を実現し、「エレクトロニクスの情報プラットフォーマー」というビジョンにつなげていきます。 著者について 加瀬 友基（Yuki Kase） 株式会社レスター Data Analysis Management データドリブン経営を担当し、グループ内外のデータを統合・分析する情報プラットフォーム戦略を推進。データと AI を活用し、商社機能の進化と新たな事業・顧客価値の創出に取り組む。

※ この投稿はお客様に寄稿いただいた記事です。 本稿は、NTTドコモ モバイルイノベーションテック部（以下、MIT 部）が AI-DLC TTT でフィジカル AI 領域の ML パイプラインを構築した取り組みの第 2 回です。 第 1 回：フィジカル AI 領域での ML 開発への適用 第 2 回：2 チーム並行開発の実験結果と知見（本記事） 第 1 回では、AI-DLC の Inception フェーズで要件を構造化し、設計レビューで 11 個の不整合を事前に検出した取り組みをご紹介しました。 第 2 回では、Construction フェーズでの 2 チーム並行開発の実験結果と、得られた知見についてご紹介します。 6. Construction フェーズ：パイプラインの実装（Day 2–3） Inception フェーズで作成した計画に沿って実装を進めました。 両チームとも同一のパイプライン構造を採用しつつ、細部の設計判断に違いが生まれました。 共通アーキテクチャ 両チームが構築したパイプラインの基本構造は以下で共通です。 図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価） 蒸留 MLP の検証 MSE（Mean Squared Error）&lt; 0.01 を両チームとも達成し、Isaac Lab 上での 1024 並列環境による PPO 学習を実行しました。これにより、パイプライン全体（蒸留→PPO→評価）が一通り接続された状態に到達し、以降はパイプラインの構築ではなく成功率の改善に集中できる段階になりました。 チーム間の設計判断の分岐点 テーマ設定の段階で、強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。Inception フェーズに用いた論文などの事前知識でパイプラインの基本構造（蒸留→PPO→評価）までは両チーム共通でしたが、蒸留の入力次元や KL ペナルティの扱いについては複数の有力なアプローチが考えられ、机上では優劣を判断できませんでした。 そこで、それぞれのチームメンバーが AI-DLC の中で判断したアプローチを採用し、実験結果を比較検証する方針としました。全く同じとなる可能性もありましたが、今回は以下のような差異が生まれました。 設計判断 チームピンク チームブルー パイプライン起点 事前収集済みデモデータ（53 エピソード） ACT 学習→デモ収集から（後述の軌道修正あり） 蒸留 MLP 入力次元 28 次元（環境の全観測空間） 12 次元 → Actor 28 次元入力層の最初 12 列に部分ロード PPO への統合方式 蒸留 MLP 全体を Actor としてロード Actor 入力層の最初 12 列に蒸留重みをコピー、残り 16 列はランダム初期化 KL ペナルティ あり（adaptive β方式、3 パターン検証） なし（RSL-RL デフォルト設定に委譲） 検証の焦点 KL ペナルティの効果検証 蒸留初期化の効果そのものの検証 KL ペナルティの β は、蒸留で得た方策をどの程度信頼するかを制御するハイパーパラメータです。 β が大きいほど蒸留ポリシーからの逸脱にペナルティを強くかけ、小さいほど自由に探索できます。 チームピンクは β=1.0（強い制約）、β=0.5（中程度）、β=0（制約なし）の 3 段階で効果を検証しました。 チームブルーの「部分ロード方式」というのは、蒸留 MLP（12 次元入力）の重みを RSL-RL（Isaac Lab 上で強化学習を行うライブラリ）の ActorCritic（行動出力と価値推定を担うネットワーク構造）における第 1 層の重み行列（256 ニューロン × 28 次元入力）の最初 12 列にコピーし、残り 16 列はランダム初期化のまま学習させます。環境の全観測情報を活用しつつ、蒸留知識を初期値として活かすアプローチです。 7. AI-DLC による軌道修正：チームブルーのスコープ変更 Construction フェーズで、AI-DLC の価値が明確に現れた場面がありました。 チームブルーは当初、ACT モデルの学習からデモ収集までを含む、より上流からのパイプライン構築を目指していました。しかし Day 2 の実装開始直後、ACT 学習環境のセットアップに想定以上の工数がかかることが判明しました。3 日間という制約の中で、ACT の環境構築に時間を費やすとコアの蒸留→PPO→評価パイプラインの検証が間に合わないリスクが生じたのです。 この時点で、AI-DLC のプロセスに従い Inception フェーズに立ち戻りました。タスクリストの優先度を再評価し、以下の判断を行いました。 タスクリスト 変更前 変更後 TL-1 蒸留用データの準備（ACT 学習→デモ収集を含む） 「ACT 学習→デモ収集」を除外。事前収集済みデモデータ（53 エピソード）を起点に変更 TL-2 MLP の蒸留 維持 TL-3 PPO Fine-tune 維持 TL-4 評価と比較 維持 この軌道修正がスムーズだったのは、要件がタスクリストとして構造化されていたからです。「何を削って何を残すか」の判断基準が各タスクリストの優先度として明示されており、チーム全員が同じ根拠で合意できました。具体的には、TL-1（データ準備）が最高優先度であり事前収集済みデータ（53 エピソード）で着手可能である一方、ACT 学習は優先度が低くこの事前データで代替可能だったため、ACT 学習を除外するという判断に至りました。場当たり的な「間に合わないから削ろう」ではなく、構造化された優先度に基づく意思決定です。 結果として、チームブルーはコアパイプラインに集中し、蒸留あり/なしの比較実験（64% vs 90%）という本 TTT で最も価値のある知見を得ることに成功しています。 8. 実験結果：2 チームの比較 両チーム共通の比較基準として、ACT ベースライン（模倣学習のみ、人手デモ 10 件＋COSMOS,Mimic による増幅）の成功率は 45% です。 チームピンク：KL ペナルティの段階的検証 KL ペナルティの有無と強度を変えた 3 回の実験を実施しました。 条件 成功率 累積報酬 備考 蒸留初期化 + PPO + Full KL (β=1.0) 0% -6.72 std 減少を阻害、探索不能 蒸留初期化 + PPO + Mean-only KL (β=0.5) 0% 2.05 探索の早期停止 蒸留初期化 + PPO（KL なし） 11% 1.82 局所最適に陥る チームピンクの成功率が全条件で著しく低かった主因は、後に判明した座標変換の欠落（object_pos のロボットベース相対変換が未実装）でした。蒸留の教師データと RL 環境の座標系が一致していなかったため、蒸留 MLP が誤った方策を学習し、KL ペナルティがその誤りをさらに固定化する結果となりました。TTT 後にこの座標変換を修正し 97% に到達した詳細は後述します。 チームブルー：蒸留あり/なしの比較 RSL-RL をデフォルト設定に委譲し、蒸留初期化の有無を直接比較しました。 条件 成功率 累積報酬 備考 蒸留初期化 + PPO（部分ロード） 64% 56.69 蒸留 12 次元→Actor28 次元に統合 ランダム初期化 + PPO（蒸留なし） 90% 84.44 蒸留なしが最高性能 2 チームの結果が示す知見 蒸留初期化は reaching（接近）を加速するが、lifting（持ち上げ）への移行を阻害する局所最適を生む KL ペナルティは、蒸留ポリシーが偏った方策を学習している場合、探索を制限し逆効果になる 蒸留初期化自体が性能を制限する可能性がある（蒸留なし 90% vs 蒸留あり 64%） RPD 論文の前提（オンライン VLA 推論）を私達の実装（重み固定 MLP）に上手く適応できていない 今回の結果は単一タスク、単一条件での実験であり、RPD の手法自体の評価を確定するものではありません。しかし、2 チームが異なる実験設計（KL の段階的緩和 vs 蒸留あり/なしの直接比較）で同じ傾向を観測したことは、今後の検証を進める根拠にはなると考えています。 9. AI-DLC を ML に適用して得られた知見 方針転換と失敗の蓄積を支えるプロセス 各フェーズ（Inception、Construction、Operation、評価）で成果物が定義されているため、方針転換の判断が容易でした。チームブルーの軌道修正はその好例です。 設計レビューにより、実装前に 11 個の不整合を検出できました。ML 実装では「動くが正しくない」コードが生まれやすく、設計段階での整合性検証が手戻りの防止に直結します。 3 回の実験サイクルと失敗分析はすべて構造化ドキュメントとして残り、次の実験の判断根拠として蓄積されました。 実験サイクルの高速化 Kiro が論文の解釈や数式の意味を解説することで、強化学習、蒸留、Isaac Lab、RSL-RL といった専門領域の理解がチーム全員で揃いました。 この共有された理解が、実験サイクルの速度に直結しています。初回の失敗分析から修正、2 回目のパイプライン実行までが数時間で完了しました。速さの要因は 2 つあります。 Inception で実験の仮説と検証基準がドキュメント化されており、「何を変えて次を試すか」の起点が明確だったこと パイプライン全体の構造と各ユニットの役割を全員が把握しており、原因の切り分けと修正方針の合意に時間がかからなかったこと 一般的な ML 実験では仮説の修正から再実験まで数日かかることが多いですが、今回は 1 日で 3 サイクル回すことができました。 ドメイン専門家の役割をどう位置づけるか Kiro の支援により、ドメイン専門家がいないチームでも動作する ML パイプラインの構築まで到達できました。 一方で、「なぜこの手法がこのタスクで機能しないか」を正確に評価する局面や、RPD 論文の前提条件と実装の差異を見抜く局面では、深い理論的理解が必要でした。Kiro が出力したコードの妥当性を判断できない場面が繰り返し発生し、ML 実装の経験が浅い私たちにはかなり負荷が高かったのが実情です。 この経験から、AI-DLC は「専門家がいないと着手できない」状態を「専門家なしでもパイプラインを構築でき、専門家は品質の最終確認に集中する」状態に変えるフレームワークだと捉えています。AI が論文解釈、コード生成、設計レビューを担うことでチームの知識水準が引き上げられ、専門家がレビューすべき範囲が絞り込まれます。 Inception で生成された設計レビューレポートや実験分析レポートを専門家に共有すれば、常駐せずスポット参加でも的確なフィードバックが可能です。今回の座標変換の問題も、TTT 後に構造化された記録を読み返すことで数時間で原因を特定できました。 今後は、Inception で定義した受け入れ基準（座標値の範囲、入力次元の整合性、損失の収束条件など）を自動テストとして実装し、パイプラインの各段階で機械的に検証する仕組みを導入する予定です。ドメイン知識を実行可能なテストコードに変換すれば、専門家が不在でも品質の劣化を早期に検出できます。 （参考）TTT 後：AI-DLC の継続で 97% へ TTT は 3 日間で終了しましたが、AI-DLC のプロセスは継続可能です。TTT 後に得られた結果を補足します。 座標変換の欠落が真因だった TTT 後、構造化された実験記録を読み返し Inception に立ち戻りました。最優先だった TL-1（座標系変換）の実装を再検証したところ、object_pos の座標変換が欠落していることが判明しました。 ACT のデモデータは LeIsaac のワールド座標系で記録されている一方、RL 環境はロボットベース相対座標系を使用しています。この不一致が蒸留 MLP の学習を破綻させていました。 # 欠落していた変換（修正版で追加） object_pos -= [0.35, -0.64, 0.01] # LeIsaacのロボットベース位置 構造化された実験記録があったため、原因の切り分けは数時間で完了しました。 再蒸留の実装と結果 座標変換の修正に加え、TTT 中の観察（reaching は学習するが lifting が伸びない）に基づき、損失関数を Phase-weighted MSE に変更しました。lifting フェーズの重みを 5 倍にしています。 再蒸留を初期重みにロードし、KL なし PPO で 5000 イテレーション（1024 環境並列、約 52 分）を実行した結果です。 条件 成功率 ACT ベースライン（模倣学習のみ） 45% RL-Only（蒸留なし、ランダム初期化） 90% 再蒸留 + PPO 97% 再蒸留 + PPO は RL-Only（90%）を統計的に有意に上回りました（Fisher’s exact test, p=0.049）。 TTT 中に得た「蒸留初期化は逆効果」という結論は、座標変換バグに起因する誤りでした。前処理が正しければ、蒸留初期化は PPO の収束を加速し、最終成功率も向上させます。 構造化された記録が継続を可能にする TTT 後 1 日で 97% に到達できたのは、3 日間の実験記録、失敗分析、設計文書が構造化ドキュメントとして残っていたからです。コンテキストが消えず蓄積されること、失敗が次のサイクルの出発点になることが、AI-DLC を ML 実験に適用する最大の利点でした。 10. 成果と今後の展望 3 日間の定量的成果 カテゴリ 成果物 コード distill.py (~400 行), train_finetune.py (~500 行), evaluate.py (~450 行) — 合計 1,350+ 行 実験 蒸留チェックポイント, PPO 学習結果 (3 Runs + 蒸留あり/なし比較), 100 エピソード評価 ドキュメント タスクリスト, ユニット分割計画, 設計レビューレポート, 実験分析レポート — 計 30+ 文書 今後の展望 技術面では、蒸留データ品質の改善、実機（SO-101）への Sim-to-Real Transfer を計画しています。 プロセス面では、他チームへの AI-DLC プロセス展開、ML 実験における設計レビューテンプレートの標準化を進めます。 著者について 株式会社NTTドコモ 片岡 敬志郎 株式会社NTTドコモ R&amp;D イノベーション本部 モバイルイノベーションテック部 ユースケース協創担当 フィジカル AI、ロボティクス領域における研究開発と社会実装を推進。AI-DLC TTT のテーマ選定を担当し、R&amp;D 組織への AI-DLC 展開を推進中。

※ この投稿はお客様に寄稿いただいた記事です。 本稿では、株式会社NTTドコモ（以下、ドコモ）モバイルイノベーションテック部（以下、MIT 部）が AI-DLC（AI-Driven Development Lifecycle） の TTT（Train The Trainer）に参加し、フィジカル AI 領域における機械学習パイプラインを 3 日間で構築した取り組みについて、全 2 回に分けてご紹介します。 第 1 回：フィジカル AI 領域での ML 開発への適用（本記事） 第 2 回：2 チーム並行開発の実験結果と知見 1. はじめに ドコモの MIT 部ユースケース協創担当では、次世代技術の社会実装に向けた研究開発を推進しています。 私は、注目領域の一つであるフィジカル AI（現実世界で物理的に動作する AI）において、ロボットアームの動作学習を効率化するパイプラインの構築に取り組んでいます。 今回、AWS が提唱する AI-DLC の手法を活用し、模倣学習（IL: Imitation Learning）で獲得した動作知識を強化学習（RL: Reinforcement Learning）で自律的に改善していくパイプラインを 1 つのプロダクトとして捉え、その設計から実装までを AI-DLC のプロセスに沿って、チーム開発で 3 日間という短期間で構築・検証しました。 本記事（第 1 回）では、AI-DLC を ML 領域に適用するに至った私たちの理解と判断、そして Inception フェーズでの要件構造化と設計レビューの実践についてご紹介します。 2. 背景と課題 フィジカル AI における学習の課題 ロボットに動作を学習させるアプローチには、大きく分けて 2 つの方法があります。 模倣学習（Imitation Learning, IL） ：人間のデモンストレーションデータから動作を学習する。学習は安定するが、デモにない状況への汎化が難しい 強化学習（Reinforcement Learning, RL） ：試行錯誤を通じて報酬を最大化するように学習する。未知の状況にも対応できるが、ゼロからの学習はサンプル効率が低い 私たちが対象としたのは、SO-101 ロボットアーム（オープンソースの廉価な 6 軸卓上アーム）による「キューブを持ち上げる」タスクです。 本来模倣学習には 50 件程度のデモデータが推奨されますが、私たちは人手を最小限にしたいと考えており 10 件のデータを収集することから出発しました。模倣学習モデル（ACT: Action Chunking with Transformers）はこの 10 件で成功率 10% でしたが、NVIDIA の提供する COSMOS（物理法則を理解した映像生成によりデータを合成する World Foundation Model）や Mimic（少数のデモから大量の合成軌道を自動生成するデータ増幅フレームワーク）によるデータ増幅を適用したところ、成功率は 45% まで向上しました。しかし、デモデータ 10 件という母数では増幅の効果にも限界があり、改善は頭打ちになりました。 これ以上の改善にはデモデータの追加収集か、別のアプローチが必要です。私たちの目的は少ないデータでタスク成功率を上げることなので、データ収集を増やす方向ではなく、強化学習を組み合わせる方向を選びました。 採用手法：RPD（Refined Policy Distillation） この課題に対して、私たちは RPD（Refined Policy Distillation） 論文のアプローチを採用しました。 RPD は、大規模な模倣学習モデルの知識を軽量なポリシーに蒸留し、さらに強化学習で改善するフレームワークです。 RPD の基本的な流れは以下の通りです。 蒸留 ：大規模モデル（VLA 等）の動作知識を、軽量な MLP（Multi-Layer Perceptron）に教師あり学習で圧縮する PPO（Proximal Policy Optimization） Fine-tune ：蒸留済み MLP を初期ポリシーとして、KL ペナルティ付きの強化学習で改善する。KL（Kullback-Leibler）ペナルティは、元のモデルをオンラインで推論し、その出力を参照分布として「蒸留ポリシーから離れすぎない」よう制約をかける RPD 論文では、教師として大規模 VLA（Vision-Language-Action）モデルをリアルタイムで推論しながら KL ペナルティの参照分布に使います。一方、私たちの実装では VLA の代わりに ACT から蒸留した重み固定 MLP を参照分布として使用しました。この前提の違いが実験結果にどう影響したかは第 2 回で詳述します。 図：RPD 論文のアプローチ（上）と私たちの ACT への適用（下） ML 開発特有の課題 機械学習パイプラインの構築は、一般的なソフトウェア開発とは異なる課題を持っています。 不確実性が高い ：論文との細かな前提の差異などから、論文通りに実装しても動作する保証がない 専門知識が広範 ：強化学習の理論、シミュレータの仕様、座標系変換など複数のドメイン知識が必要 実験サイクルが長い ：仮説→実装→学習→評価のサイクルに時間がかかる これらの課題は、チームでの開発において「何を作るか」「なぜこの設計にするか」の共有コストを増大させます。 個人で AI と対話しながらコーディングを進める「Vibe Coding」のアプローチでは、こうした構造的な課題を 1 つ 1 つ対話の中で解消しても、その判断やコンテキストが流れてしまい蓄積されません。これでは個人でも知見の蓄積が難しいだけでなく、組織的な研究開発となるとさらに顕著な課題になるのではないかと考えました。 3. AI-DLC 理解と適用判断 AI-DLC とは何か AI-DLC は、AI を開発プロセス全体に組み込むためのフレームワークです。私たちは TTT を通じて、以下のように理解しました。 AI-DLC の核心は、AI が作業計画を体系的に作成し、人間が意思決定に集中する協働モデルです。具体的には以下のフェーズで構成されます。 Inception フェーズ ：ユーザーストーリーの定義、要件の構造化、設計レビュー。AI が専門知識を補完しながら、人間が「何を作るか」を決定する。Inception の最後で分けた Unit ごとに小規模なモブチームを形成する。 Construction フェーズ ：Unit ごとのモブチームが詳細設計、実装、テストを並行で進める。AI がコード生成を担い、人間がレビューと意思決定を行う。 Operation フェーズ ：デプロイ、運用への移行。 図：AI-DLC の3フェーズ 従来の「Vibe Coding」との違いは、チーム全体で共有可能な構造化ドキュメント（ユーザーストーリー、設計文書、レビューレポート）が生成される点です。これにより、AI と個人の間の暗黙知がチームの共有知に変わります。 なぜ ML 領域に適用したか AI-DLC の既存事例は Web サービスや業務アプリ開発が中心ですが、私たちは ML 開発への適用をチャレンジしてみました。理由は 3 つあります。 論文→実装のギャップを埋める ：研究開発では論文の手法を実装に落とし込む過程で、前提条件の違いや暗黙の仮定が問題になる。Inception フェーズで AI と対話しながら要件を構造化することで、これらの曖昧さを事前に可視化できるのではないかと考えました。 チーム学習の加速 ：私たちはフィジカル AI に取り組み始めたばかりのチームです。強化学習やシミュレータの専門知識は属人性が高いため、AI-DLC の構造化ドキュメントを通じて、チーム全員が同じ理解水準で議論できる環境を作れると考えました。 実験サイクルの管理 ：ML 実験は「仮説→実装→学習→評価→修正」のサイクルを高速に回す必要がある。AI-DLC のチェックポイント（Inception→Construction→Operation→評価）が、方針転換の判断基準を明確にすると考えました。 私たちは、要件の構造化と設計レビューというプロセスが、不確実性が高く前提条件の検証が必要な ML 開発に適応できるのではないかと考えました。本記事はあくまで ML 領域への適用事例として、私たちの TTT での経験と見解を中心にご紹介するものです。 4. AI-DLC TTT の概要 以上の背景を踏まえ、TTT で実際に取り組んだ内容をご紹介します。 テーマ設定 具体的な目標は以下の通りです。 人手によるデモデータ収集を最小限に抑えつつ、模倣学習によって習得したロボットアームの動作を、強化学習を用いて自律的にブラッシュアップしていくパイプラインを１つのプロダクトとして捉え構築する 参加者を 2 チーム（チームピンク、チームブルー）に分けました。 強化学習を最終段階とするパイプライン構造は共通ですが、ベースとなるモデルが模倣学習の直接的な出力ではなく RPD 論文に基づく蒸留を経由する設計であり、どのように変換を行うかは未検証でした。 そのため、チームごとでアプローチを決め並行して比較検証する方針としました。 両チームの設計判断の詳細は第 2 回でご紹介します。 事前準備 AI-DLC で効果的に開発を進めるために、以下を事前に準備しました。 学習データ ：ACT の実行から得た成功軌道データ 53 エピソード（蒸留の教師データとして使用。人手で収集した 10 件とは別に、ACT がシミュレーション上で成功した軌道を自動収集したもの） 参考論文 ： RPD 、 ACT 、 Knowledge Distillation 、 PPO の 4 本 設計概要ドキュメント ：環境差分、手法の設計思想、データ概要 Amazon EC2 インスタンス ：g6e.8xlarge（NVIDIA L40S 48GB）に Isaac Lab（NVIDIA が提供する GPU 並列ロボット学習シミュレーションフレームワーク）環境を構築済み 5. Inception フェーズ：要件構造化（Day 1） ML パイプラインをプロダクトとして AI-DLC のプロセスに載せた Inception フェーズの具体例を以下に示します。 Inception フェーズでは、フィジカル AI に関する論文や専門情報を Kiro に読み込ませ、要件の構造化とスコープ決定を行いました。 図：チームピンクの Inception の様子、右下に映っているのが SO-101 タスクリストの定義 Kiro との対話を通じて、4 つのタスクリストを定義しました。 表：タスクリスト一覧 # タスクリスト 優先度 TL-1 蒸留用データの準備（座標系変換+データ整形） 最高 TL-2 MLP の蒸留（教師あり学習） 高 TL-3 PPO Fine-tune（強化学習による改善） 高 TL-4 評価と比較（100 エピソード評価） 中 各タスクリストには具体的な受け入れ基準を設定しました。たとえば TL-1 では「座標変換後の joint_pos_rel の範囲が [-2.2, 1.5] 程度であること」「NaN/Inf が含まれていないこと」など、ML 特有の検証項目を含めています。 ユニット分割とデータフロー設計 パイプライン全体を 3 つの実装ユニットに分割し、データフローを設計しました。 なお、TL-4（評価）は Unit 3 の出力を受けて実行する工程として Unit 3 に含めています。 以下はチームピンクのデータフローとコンテキストマップです。 act_demos.npz (Amazon S3)：座標変換 + データ整形【Unit 1】 ↓ obs_flat (12次元) + act_flat (6次元)：教師あり学習（蒸留）【Unit 2】 ↓ distilled_mlp.pt：PPO Fine-tune (KLペナルティ付き)＋評価【Unit 3】 ↓ model_&lt;iter&gt;.pt：100エピソード実行【Unit 3】 ↓ evaluation_report.md 図：コンテキストマップ 図：データフロー（act_demos.npz → 座標変換 → 蒸留 → PPO → 評価） 設計レビューの効果 Inception フェーズではモブスタイル（Mob Inception）を採用し、チーム全員が Kiro を囲んで対話しながら設計を進めました。 この過程で Kiro が設計レビューを実施し、実装前に 11 個の不整合を検出しました。 モブスタイルと AI による支援の組み合わせにより、チーム内でのイメージのすり合わせと合意形成にかかる時間を短縮でき、実際にコードに反映できた点は、AI-DLC ならではの効果だと思いました。 発見された不整合の例： チェックポイント形式の不一致（RSL-RL が期待する actor/critic 分離形式との差異） 入力次元の食い違い（12D と 28D の混在） アクションスケールの不整合（環境間で /0.5 の変換が必要） これらを実装前に検出できたことで、Construction フェーズでの手戻りを削減できました。ML 実装では「コードが動くが出力が正しくない」という不具合が起きやすいため、設計段階での整合性チェックは価値が高いと実感しました。 第 1 回のまとめと次回予告 本記事では、AI-DLC をフィジカル AI（ML）領域に適用するに至った私たちの理解と判断、そして Inception フェーズでの要件構造化と設計レビューの実践についてご紹介しました。 Inception フェーズだけで、設計レビューにより 11 個の不整合を検出し、30 以上の構造化ドキュメントを生成しました。 第 2 回 では、Construction フェーズでの 2 チーム並行開発の実験結果をご紹介します。チームブルーが当初スコープの断念から AI-DLC のフレームに従って軌道修正し成果を出したエピソードや、蒸留初期化についての知見についてお伝えします。 著者について 株式会社NTTドコモ 片岡 敬志郎 株式会社NTTドコモ R&amp;D イノベーション本部 モバイルイノベーションテック部 ユースケース協創担当 フィジカル AI、ロボティクス領域における研究開発と社会実装を推進。AI-DLC TTT のテーマ選定を担当し、R&amp;D 組織への AI-DLC 展開を推進中。

Claude Fable 5.1 が本日より Kiro のエンタープライズ顧客向けに利用可能になりました。長時間にわたるコンテキスト量の多いエージェントセッションにおいて、Fable 5.1 は新しい基準を打ち立てます。症状を並べるのではなくコードの根本原因まで問題を追跡し、複雑なタスクの全体を通してコンテキストと意図を保持します。 Kiro は、後片付けが必要な初期ドラフトでも、埋める作業が残るスタブでもなく、プロダクションレディなコードを届けるために作られています。Kiro における Fable 5.1 は、次の 3 種類の作業で到達点を引き上げます。 インタラクティブなタスク。 バグ修正、関数のリファクタリング、PR のブロック解消といった、素早いやり取りを伴うコーディングセッションで、Fable 5.1 はより正確になりました。あなたが実際に達成しようとしていることを理解し、より少ないやり取りでそこに到達します。 長時間の複数ステップにわたるタスク。 大規模なリファクタリングや長時間の自律実行において、Kiro の spec 駆動ワークフローは Fable 5.1 でより確実に完了まで走ります。モデルはセッション全体を通して計画を保持し、終盤でコンテキストを失ったり脱線したりしません。 セキュリティやシステムレベルの作業を含む複雑なタスク。 Fable 5.1 は、大規模なコードベース全体にまたがる推論を必要とする難しい問題で、収束性が向上しています。 長時間のエージェントセッションからより多くの価値を Fable 5.1 は、セッションが長くなるほど効率が上がるように設計されています。また Kiro の spec 駆動のアプローチにより、タスクが成功しないと判断された場合には、行き詰まった方向で反復してクレジットを消費し続けるのではなく、モデルは早期に停止します。複数ファイルにまたがるリファクタリング、長時間の自律実行、ツールを多用するセッションといったエージェント性の高い作業では、Anthropic の最も高性能なモデルを Kiro で利用できます。 組織で Fable 5.1 を有効化する Fable 5.1 は、 Model Governance を有効にしている Kiro のエンタープライズ顧客が利用できます。使い始めるには、AWS Management Console で Kiro の設定を開き、Model availability のトグルをオンにして、モデル一覧から Fable 5.1 を選択します。有効化すると、Fable 5.1 はすべてのユーザーの、すべての Kiro クライアントのモデルセレクターに表示されます。このとき、不正利用の検出のために AWS が 30 日間トラフィックを保持し、フラグが付いたトラフィックは人間によるレビューの対象となる旨のデータ保持に関する通知が表示されます。組織としてアクセスを制限する必要がある場合は、同じモデル設定ページから Fable 5.1 をいつでも無効化できます。 セーフガードについて Fable 5.1 には、従来のモデルよりも精度の高い、更新されたサイバーセキュリティのセーフガードが搭載されています。分類器は防御的なセキュリティ作業と本物の脅威をより適切に区別できるようチューニングされており、正当なタスクが中断される場面は少なくなります。Fable 5.1 はソフトウェアの脆弱性の発見に利用できるようになりましたが、エクスプロイトの生成、バイナリベースの脆弱性スキャン、ペネトレーションテストといったタスクは、Kiro では引き続き Opus クラスのモデルへリダイレクトされます。 提供状況 Claude Fable 5.1 は、us-east-1 (IAD) の Kiro エンタープライズ顧客に対して 実験的サポート として段階的に展開されています。 1M のコンテキストウィンドウと 6 倍 のクレジット乗数で提供されます。 Fable 5.1 の利用には、AWS Management Console で Model Governance をオンにし、モデル一覧から Fable 5.1 を選択しておく必要があります。最新のモデルを反映するには、 Kiro をダウンロード するか、IDE または CLI を再起動してください。 Web をご利用の方 はブラウザを再読み込みしてください。 この記事は Kiro ブログの Claude Fable 5.1 is now available in Kiro を翻訳したものです。

本ブログは 2026 年 8 月 31 日に公開された Amazon Science Blog “ Developing provably correct Rust code with Verus ” を翻訳したものです。 コードをその機能の数学的な仕様に照らして自動的に検査する「プログラム検証ツール (program verifier)」である Verus が、ソフトウェアプロジェクトのセキュリティ保証をどのように高めるのかを紹介します。 オープンソースや企業のソフトウェアプロジェクトの多くが Rust プログラミング言語を採用しており、 いくつかの事例 は Amazon 社内 にもあります。Rust が選ばれているのは、C 言語に匹敵するパフォーマンスと柔軟性を備えつつ、洗練された型システムによってさまざまなバグやセキュリティの脆弱性を自動的に防ぐからです。その結果、平均的なコードよりも正しく安全で、しかも高速なコードが得られます。 しかし、「より正しく安全である」ことは「実際に正しく安全である」ことと同じではありません。例えば C では、配列の範囲外アクセス (out-of-bounds access)、つまり配列に割り当てられたメモリの境界を越えたインデックス指定は、予測できない結果を招く危険な誤りです。Rust では範囲外アクセスが起きるとプログラムが停止するため、確かに安全性は高まりますが、本当に正しいプログラムであれば、そもそも範囲外アクセスは起こりません。同様に Rust は、プログラムが期待どおりの結果を計算することや、自身がアクセスできる機密情報を漏洩しないことまでは保証できません。ここで役立つのが Verus です。 配列の範囲外アクセスは、予測できない結果を招く危険な誤りです。正しいプログラムであれば、これを許しません。 Verus とは Verus は、Rust 向けのオープンソースの自動プログラム検証ツール (program verifier) です。プログラム検証ツールは、コードがどのように振る舞うべきかを記述した形式的な数学的仕様を受け取り、あらゆる入力に対してコードがその仕様に一致することを機械的に検査します。 例えば、ソート済み配列から特定の値を探すために、最適化した二分探索アルゴリズムを実装したコードがあるとします。仕様には、コードがインデックスを正常に返した場合に、配列内の対応する要素が目的の値と一致することを記述できます。検証ツールは、あらゆる入力配列と目的の値についてこの仕様が成り立つことを検査します。 一方、従来のテスト手法では、いくつかの特定の配列を試すことはできても、コーナーケースを見落とすおそれがあります (目的の値が配列の最後の要素である場合や、そもそも存在しない場合など)。プログラム検証で重要なのは、コードが仕様に一致することを示す数学的な 証明 を構築する点です。Verus のような 自動 プログラム検証ツールでは、証明構築のうち退屈で低レベルな手順の多くをツールが自動的に処理し、人間の開発者は高レベルな指示を与えます。例えば、帰納的証明の設定やループ不変条件 (loop invariant) の提示などです。以下で説明するように、最近ではこうした高レベルな手順も多くの場合 AI で自動化できます。 Amazon は Rust Foundation の創設メンバーであることを誇りに思っており、さまざまなプロジェクトで Rust を幅広く活用しています。例えば、AWS Lambda と AWS Fargate を支える Firecracker 、Amazon のサーバーレス分散 SQL データベース、そして Nitro Isolation Engine などです。Nitro Isolation Engine は、Amazon Web Services (AWS) の仮想マシン割り当てを管理するソフトウェアである Nitro Hypervisor のために、仮想マシンの分離を強制するものです。Amazon の Rust に対する熱意と、 10 年以上にわたる自動推論への取り組み を踏まえれば、Amazon が書く Rust コードにさらに強力な保証を与えるために Verus を採用するのは自然な流れです。実際に Amazon は、Nitro Isolation Engine が使用する主要なプリミティブや、Amazon 社内の複数の重要なインフラストラクチャについて、Verus を用いて正しさを証明してきました。こうしたユースケースは今後の記事で取り上げる予定です。まずは、Verus で Rust コードを検証するとはどういうことなのかを詳しく見ていきましょう。 Verus による Rust コードの検証 Verus を使うと、Rust 開発者は既存の Rust コードに対する仕様 (および証明) を Rust のソースファイルに直接追加できます。先ほどの二分探索の例を発展させて、探索関数の既存の Rust 実装に対する次の Verus 仕様 (Rust のアノテーションとして記述) を見てみましょう。 Rust のアノテーションとして記述された、探索関数の Rust 実装に対する Verus 仕様。 事前条件 (precondition) は requires キーワードで示され、関数の実行前に真でなければならない条件を記述します。この例ではコードが二分探索を実装しているため、配列がソート済みであることを要求します。 事後条件 (postcondition) は ensures キーワードで示され、関数の実行後に真でなければならない条件を記述します。この例では、関数が Some(index) を返す場合に index が配列の範囲内にあり、そのインデックスにある配列要素の値が、探していた値と一致することを示しています。 重要なのは、関数が None を返す場合には目的の値が配列内に 存在しない ことも示している点です。この 2 つ目の条件がなければ、常に None を返す実装でも仕様を満たしてしまいます。なお、通常の Rust コンパイラはこれらの Verus アノテーションを無視します。そのため、Verus のアノテーションが付いたコードは、Rust のビルドツールである Cargo を使うプロジェクトを含め、検証済みのプロジェクトでも未検証のプロジェクトでも利用できます。 この例は、Verus が採用している重要な設計上の判断も示しています。これは、他の多くの Rust 検証手法とは異なる点です。Verus では、 開発者 が Rust に似た構文を使い、自分のソースコード内に仕様と証明を記述します。証明が失敗すると、ソースレベルで表現された Rust スタイルのエラーメッセージが表示されます。このアプローチにより、証明と実際のコードの同期が保たれ、開発者は仕様や証明のためにまったく新しい言語やツールを学ぶ必要がなくなります。また、コードを書いた開発者、つまりそのコードを最もよく理解している人が、正しさを証明するプロセスにかかわることができます。 Verus は、高速で強力な自動化にも力を入れています。そのために、さまざまな ソルバー (solver) を使用して、プログラムとその仕様から生成される証明義務 (proof obligation) を解消します。実際には、開発者は通常 1 秒未満でコードと証明に関するフィードバックを得られます。これは、対話的な開発ループ (VS Code のような対話的な開発環境に表示される「赤い波線」を含む) を実現できるほどの速さです。 プロジェクト単位で見ると、Verus は数千行のコードと証明を含む複雑なプロジェクトを、従来の一部の自動プログラム検証ツールが個々の関数を検証するのに要していた時間で検証できます。この強力な自動化と高速なフィードバックループは、人間に有用なのは言うまでもなく、AI エージェントが Verus の証明を作成する際にも役立ちます。自動化が進んでいればエージェントの作業は少なくなり、証明の修正と検証をよりすばやく繰り返せるからです。 Rust の型システムは強力な安全性保証を提供しますが、開発者が高性能なコードを書くうえで足かせになる場合もあります。そのため Rust では、明示的に unsafe とラベル付けしたコードも書けます。この unsafe コードも、Rust が安全なコードに求めるすべての要件を満たす必要がありますが、コンパイラはそれらの要件を機械的に検査しなくなります。正しく実装する責任は開発者に委ねられます。しかし Verus を使えば、unsafe な Rust コードの安全性を数学的に証明でき、機械的に検査された安全性保証を取り戻せます。 同様に Rust は「恐れ知らずの並行性 (fearless concurrency)」で知られています。これは、開発者が並行コード、つまり少なくとも一部が並列に実行されるプログラムを書くときに、他のプログラミング言語では許容されてしまうさまざまな誤りを型システムが防ぐという意味です。Verus はこの基盤の上に構築されており、開発者は並行コードが安全であるだけでなく正しいことまで証明できます。 例えば、並行実行には一般に ロック が用いられます。ロックは、プロセッサスレッドが現在操作しているデータ項目への排他的アクセスを与えるものです。Verus では、開発者がロックに 不変条件 (invariant) を付与できます。つまり、ロックを取得した側はその不変条件を満たす値を得られ (例えば、その値は常に偶数である)、ロックを解放するときには、ロックで保護されている値がその不変条件を依然として満たしていることを証明しなければなりません。さらに Verus は、ロックの実装そのものが正しいことの証明もサポートします。これは、高いパフォーマンスを実現するために複雑なカスタムロック方式に依存する Nitro Isolation Engine のようなプログラムでは特に重要です。 すべてのプログラム検証ツールと同様に、Verus の保証は次の要素が正しいことに依存します。Verus 自体、プログラムの意図された振る舞いを記述した「最上位」の仕様、基盤となるランタイム (Rust 標準ライブラリなど) に関する「最下位」の仮定、そしてソースコードを実行可能なプログラムへ変換するコンパイラのツールチェーンです。今後の記事では、これらのコンポーネントの正しさに対する確信をどのように高めているかを詳しく説明します。 オープンソースエコシステムにおける Verus Verus は Amazon での利用に加えて、さまざまなオープンソースプロジェクトで興味深い性質を証明するために使われています。以下にいくつかの例を挙げます。 Vest は、バイナリデータ形式の記述を受け取り、その形式のデータを解析およびシリアル化する Rust コードを自動生成します。生成物には、正しさとセキュリティに関する Verus の証明も含まれます。 Verdict は、X.509 公開鍵暗号標準に対応した、正しさと安全性が証明された証明書検証ライブラリを提供します。ユーザーが指定した検証ポリシーもサポートします。 CapybaraKV プロジェクト は、 永続メモリログ (persistent-memory log) の正しさとクラッシュ安全性を検証します。永続メモリログは、システムがクラッシュしたり予期せず電源を失ったりしても、データを整合性のある状態で保持します。 Atmosphere マイクロカーネル は、Rust で開発され、Verus によって正しさが検証されたマイクロカーネル (最小構成のオペレーティングシステム) です。 Anvil は、クラウドコンピューティングを管理するオープンソースシステムである Kubernetes のコントローラーについて、正しさと「活性 (liveness)」を証明します。妥当な仮定の下で、コントローラーが最終的にシステムを安定した状態へ導くことを示します。 CortenMM メモリ管理システムは、スケーラブルなロックプロトコルを備えた新しいトランザクショナルインターフェイスを提供しており、その並行コードの正しさは Verus で検証されています。 Verus 自体は、各地の学術界と産業界の研究者が協力して開発を進めている、無償のオープンソースプロジェクトです。 著者について Bryan Parno Bryan Parno は Amazon Scholar であり、カーネギーメロン大学の電気・コンピュータ工学およびコンピュータサイエンスの Kavčić-Moura Professor として、Secure Foundations Lab を率いています。研究では、安全なシステムの設計手法と構築手法における長期的かつ根本的な改善に取り組み、特に形式検証されたソフトウェアに重点を置いています。暗号学的に検証可能な計算に関する研究は、IEEE Symposium on Security and Privacy で Best Paper Award と Test-of-Time Award を受賞し、検証済みシステムに関する研究では 6 件の Distinguished Paper Award を獲得しています。ACM および IEEE のシニアメンバーであり、2011 年には Forbes の「30-under-30」科学分野リストに選出され、2010 年には ACM Doctoral Dissertation Award を受賞しました。カーネギーメロン大学で博士号を取得しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

2026 年 7 月 29 日、ファッション・アパレル業界のお客様が集まり、第一回ナレッジ共有会を開催しました。本会は、店舗業務支援 AI エージェント&nbsp; SMART（Store Manager Agent for Retail Tech） を起点に、各社が取り組んできた AI エージェント開発の実践ナレッジを、企業の垣根を越えて共有し合う場です。当日は 6 社 20 名のお客様にご参加いただき、各社から取り組みを発表いただきました。経営層・DX/IT 部門・現場出身のメンバーまで多様な参加者が一堂に会し、熱気にあふれる発表と質疑の時間となりました。本記事では、その模様をレポートします。 取り組みの背景 — SMART から広がる業界の共創 AWS はこれまでも、小売業界、ファッション・アパレル業界のお客様に向けて、 業界ユースケースにフォーカスした合同生成 AI ワークショップ や、 店舗業務にフォーカスした小売業界向け AI エージェント活用ワークショップ など、業界の共通課題に向き合う場を継続的に提供してきました。こうした場では、「自社に役立つものを内製でも作ってみたい」という意見もあれば、「アイデアやものづくりに終わらせないための工夫が知りたい」「近しい業界での他社の実践的な取り組みからぜひ学びたい」という声も多くいただいていました。本ナレッジ共有会は、そうしたお客様の声に応える場として企画したものであり、受け身の勉強会イベントではなく、業界共通課題をテーマに各社がそれぞれ挑戦し、そしてそこで得た知見を共有し合う、業界共創の歩みの中間地点にあたります。 きっかけは、AWS Prototyping Program を通じて誕生した、店舗業務支援 AI エージェント SMART です。SMART は、店舗スタッフの日常の言語化・データ化を支援しフィードバックする AI エージェントのサンプルアセットで、2026 年 4 月に GitHub（aws-samples） で公開しました。6 月に開催した AWS Summit Japan での事例紹介では、ファッション・アパレル以外の店舗事業者様からも多くの関心の声をいただきました。 私たちは、SMART のアセット公開とともに、4 月には SMART の合同ブートキャンプを開催しました。ここでは、AI コーディングエージェント Kiro も活用しながら、SMART のデプロイとカスタマイズを体験いただき、そこから参加企業各社の取り組みが始まりました。SMART をベースに自社利用のために拡張開発を決めたお客様、店舗以外の業務領域での新規 AI エージェントの開発に挑戦を決めたお客様など、各社がそれぞれの現場課題に向き合い、業界としての取り組みへと広がっています。そして 7 月、本記事で紹介する第一回ナレッジ共有会として、各社の実践ナレッジを持ち寄る場が実現しました。4 月のブートキャンプに参加し、そこから活動を開始した 3 社が、どんな課題に直面しどう乗り越えたか、作って終わりにならないための、その実践的な取り組みと学びについてご紹介します。 各社発表 サザビーリーグ IRIS 様：SMART を発展開発 — 麺屋 猪一 の日報改善から全店舗利用へ 株式会社サザビーリーグ IRIS 様からは、グループの飲食ブランドであり、ミシュランガイド ビブグルマンに 9 年連続選出されたラーメン店 麺屋 猪一 を対象に、SMART をベースとして現場に必要な機能をカスタマイズ・発展開発した事例を発表いただきました。 株式会社サザビーリーグ IRIS 管理システムグループ 吉川 真由 氏、大谷 美月 氏のご登壇の様子 猪一における、これまでの店舗の売上日報はチャットツールで本部スタッフにテキストで送る運用でした。そこから IT 主導で要件定義を行い、売上入力の画面や店舗間の状況を可視化するダッシュボード機能などの開発を進められていました。その後、店舗運営マネージャーにデモを通じてヒアリングを重ねて、日報そのものより週報・月報の作成負担が大きいという真の課題を発見し、週報・月報を自動生成する機能を Amazon Bedrock 、 Amazon EventBridge 、 AWS Lambda 、 Amazon S3 Tables 、 Amazon Athena 、 Amazon SNS などを組み合わせて約 1 ヶ月半で開発されました。 店舗 PoC の結果、約 15 分かかっていた週報の作成時間は 0 分に短縮。「言語化が苦手でも AI が言葉にしてくれる」という現場の声も紹介されました。開発では、Kiro と向き合いながらも、実際に使う事業部門や店舗スタッフとのコミュニケーションを繰り返したことで、真に求められるもの、課題解決につながるものへと進化を遂げた過程が印象的な発表でした。そして 7 月の PoC を経て、現在は 8 月にオープンした新店舗を含む全 4 店舗での利用が始まっています。 週報・月報の自動生成を実現したアーキテクチャ 取り組みと成果のまとめ ジンズ様：店舗のリアルを、生成 AI で本部へ繋ぐ — IT 未経験・店舗出身者が Kiro と 2 週間で挑んだ Web アプリ開発 株式会社ジンズ様からは、店舗スタッフ出身で IT 組織への異動後まもないメンバーが、わずか 2 週間で店舗フィードバック収集 Web アプリを開発した事例を発表いただきました。 株式会社ジンズ IT デジタル部 陳 蘇 氏のご登壇の様子 役員から「音声で店舗のフィードバックを収集したい」というミッションを受けて、 Amazon Transcribe による音声テキスト化、Amazon Bedrock による感情分析・ペイン分類、改善案の自動生成と Excel 出力までを、 Amazon API Gateway 、AWS Lambda、 Amazon DynamoDB などで構成されたサーバーレスアーキテクチャとして実装されました。多言語表示・多言語音声入力への対応やいいね機能など、店舗経験者ならではの現場目線の工夫も凝らされています。 AWS の知識ゼロの状態からのスタートでしたが、AWS と一緒に要件整理と想定アーキテクチャをホワイトボーディングするところから始め、議論した内容を Kiro に繰り返しインプットして設計を進めていきました。わずか 2 週間という短期間の中、ただサーバーレス構成で作るだけでなく、多言語対応や非同期処理に作りかえる工夫も行い、ユーザー体験を第一にこだわって作られているのがとても印象的でした。「技術のために現場があるのではなく、現場を助けるために技術がある」という力強いメッセージと、活動を通じて IT 用語の壁を検索や同僚への相談で乗り越えたエピソードは、参加者アンケートでも最も多く言及された発表のひとつとなりました。 音声テキスト化から感情分析・Excel 出力までを担うサーバーレスアーキテクチャ 店舗の声を集めるアプリ コエポスト の画面 アンドエスティ HD 様：Kiro と 2.5 ヶ月で挑む在庫消化 Agent 株式会社アンドエスティ HD 様からは、SMART とは異なる業務領域への挑戦として、商品の売価変更や店舗間移動といった、在庫消化業務を支援する AI エージェントの開発事例を発表いただきました。 株式会社アンドエスティ HD DX本部 鈴木 向陽 氏のご登壇の様子 在庫消化は利益を左右する重要業務でありながら、その判断がベテラン社員の経験に依存しているという課題を感じておられました。そこで、今のやり方をそのまま自動化しても解けないと判断し、担当の業務部門と AI とともに業務そのものを構造化するところから着手されました。判断観点をスコア化して共通の物差しを作り、「AI は判断しない。作戦を複数提示し、人が決める」という設計思想を事業部門と合意した上で、 Amazon Bedrock AgentCore を活用した開発を進めています。 鈴木様は、AWS での開発経験がほぼゼロの状態から、 AWS のサポートも得ながら、Kiro を駆使し、事業部門と何度もプロトタイプをもって壁打ちし、2.5 ヶ月開発を進める中での壁と学びも率直に語られました。発表時点では、AI が売価変更・店舗間移動の候補として挙げるアイテムがベテラン実務者の判断と概ね重なる精度まで到達しており、本番導入を見据えて開発が続いています。「AI エージェントを作る過程で、形のなかった業務フローが構造として見えるようになってきた」という気づきのお話も印象的でした。 形のない業務を業務側 &amp; AI と一緒に構造化する設計思想 俯瞰・検証・深掘りを支えるダッシュボード画面 参加者の声 会の最後に実施したアンケートでは、CSAT 4.65 / 5（回答 20 名）と高い評価をいただきました。第二回への参加意向として 7 割が「ぜひ参加したい」と回答し、参加を希望しないという回答はゼロでした。いただいたコメントの一部をご紹介します。 IT 未経験の店舗出身メンバーが Kiro を使いこなしているのはまさにイノベーティブな取り組みだと思い、とても刺激的でした AWS サービスの初心者、開発の初心者でも短期間で現場が必要な機能・システム（日報、在庫、ご意見箱など）を開発できるのがすごいと思いました 経験がないメンバーが開発できることで事業スピードだけでなく、事業会社でも IT を経験して IT のキャリアアップできる可能性が大きく広げられると感じました 業界近しい他社事例を伺うことで、新たな気づきや取り入れたいアイデアを得ることができ、大変有意義な時間となりました。早速明日から自社の取り組みに組み込めるか検討します 継続的な取り組みを行うことが業界全体の活性化に繋がると思います 次回に向けて — 第二回ナレッジ共有会へ クロージングでは、次のチャレンジの方向性として 3 つの選択肢を示しました。 SMART をさらに発展 ：機能拡張・本稼働からのフィードバックループで価値を深める 店舗業務の別領域へ ：店舗に関わる別業務のエージェントを追加開発 AI エージェントを他業務へ ：店舗以外の業務領域への適用 11 月に予定している第二回ナレッジ共有会での成果共有に向けて、各社の挑戦と業界の活動をさらに飛躍させていきます。 おわりに 今回共有されたナレッジは、各社が業界の課題に向き合い、目標を定めて実際に手を動かし、そして現場とのコミュニケーションを繰り返したからこそ生まれたものです。AWS Prototyping Program から生まれた SMART が、オープンソース化とブートキャンプを経て、業界全体の取り組みへと広がりつつあります。各社で共通していたことは、IT に閉じた活動ではないことです。AI とだけ会話を継続するのではなく、素早く構築したプロトタイプをもとに事業部門、ユーザー部門と何度もやり取りをしながら、さらなる開発と検証を進められたことが最も大きな成功要因であったと考えております。そして今回、多くの CIO や IT,DX 本部長の方々にも参加いただきましたが、そういった方々のスポンサーシップが、本活動を大きく前進させる力になったと感じております。 AWS は今後もブートキャンプ、そして本ナレッジ共有会のような場を通じて、ファッション・アパレル業界のお客様の AI エージェント活用や内製化の挑戦を支援してまいります。お客様の声に耳を傾けて、今後も期待に応える企画を考えてご提供していきます。本取り組みにご興味をお持ちの方は、ぜひ担当営業・ソリューションアーキテクトまでお声がけください。 著者について 濱上 和也（Kazuya Hamagami） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 流通・小売業のお客様の技術支援を行っています。SMART の開発にも関わっています。好きな AWS サービスは Amazon Connect Customer で、業界問わずコンタクトセンター関連の技術支援も行っています。 &nbsp;

この記事は Kiro ブログの Tackling technical debt at scale with autonomous mode in Kiro Web を翻訳したものです。 ソフトウェア開発チームはどこも、保守と新機能開発のあいだの緊張関係を経験しています。一方に使った時間は、もう一方に使えなかった時間です。オープンソースのメンテナーにとってこの課題はさらに深刻で、チームは小さく、ユーザーベースは大きく、バックログは伸び続けます。 形式検証 、つまりソフトウェアの性質を証明するために数学的技法を使う領域では、ドメインの複雑さゆえにこの痛みが特に大きくなります。 AWS Automated Reasoning Group は、 Kani Rust Verifier や C Bounded Model Checker (CBMC) を含む複数のオープンソース形式検証ツールを保守、あるいは主要なコントリビューターとして開発しています。本記事で紹介する取り組みを始めた 2025 年 11 月時点で、これらのリポジトリには 916 件のオープン issue があり、コアとなる検証機能の開発を進めながらでは、チームが対応できる速度よりも速く保守タスクが積み上がっていました。 技術的負債への従来のアプローチは、開発者の時間を保守に割り当てて機能提供を遅らせるか、負債が複利で膨らむのを放置するかの二択を強います。対話型の AI コーディングアシスタントは個々のタスクを速くしてくれますが、それでもすべてのステップで開発者がループの中にいる必要があります。私たちが欲しかったのは第三の選択肢、つまり issue を読むところからプルリクエストを開くところまで保守タスクを一気通貫で引き受け、エンジニアは判断が最も価値を持つコードレビューでだけ関わる、という形です。それが Web の Kiro の autonomy モード です。保守を含む幅広いタスクをこなせるエージェンティックなソフトウェアエンジニアリングツールで、エンジニアはより価値の高い仕事に集中できます。実際にどうなったかというと、2 か月のあいだに Kiro は私たちのリポジトリ群で 87 件のオープン issue に対応するプルリクエストを提出しました。これは、それまでの 22 か月（約 2 年）でチームが対応してきた量に迫る数です。 本記事では、どのようにセットアップしたか、2 つのケーススタディの詳細、そして自分のリポジトリで Kiro を自律的に使う方法を紹介します。 Kiro の自律モードの仕組み 自律モードの Kiro は、既存のワークフローと統合しながら、専用のセキュアなクラウド開発環境の中で自律的に動作します。Kiro に作業を割り当てるのは簡単です。 app.kiro.dev でタスクを記述する、GitHub issue に kiro ラベルを付ける、あるいはコメントで /kiro とメンションする、のいずれかです。すると Kiro はリポジトリを隔離されたサンドボックスにクローンし、issue と関連コードを分析し、作業をステップに分解し、変更を実装し、テストスイート全体を実行して、プルリクエストを開きます。すべてのプルリクエストは、CI の通過とコードオーナーのレビューを含め、人間が書いたコードとまったく同じ承認要件の対象になります。Kiro はマージ権限を持たず、ブランチ保護ルールを回避することもできません。 このアプローチに最も向いているのは、受け入れ基準が明確でスコープが独立しているタスクです。依存関係の更新、再現手順がはっきりしたバグ修正、ドキュメントの改善は、いずれも良い出発点です。アーキテクチャ上の決定や横断的なリファクタリングを要するタスクは、人間に任せたほうがよいでしょう。Kiro は曖昧さに遭遇したとき、推測ではなく確認の質問を返します。Kani と CBMC のリポジトリでの運用では、マージされた Kiro 生成コードが持ち込んだリグレッションはゼロでした。 定量的なインパクト Kani リポジトリでは 2025 年 11 月初旬に Kiro の自律モードを使い始め、同月後半に CBMC へ広げました。両リポジトリを通じて、数字がその効果を示しています。 コード保守（29%） : 依存関係の更新、ツールチェーンのアップグレード、CI の改善、リファクタリング ドキュメント改善（4%） : プロジェクトドキュメントとビルド手順の更新 バグ修正（36%） : クラッシュ、誤った結果、不変条件違反などの報告済み issue の解決 機能の完成（26%） : プロトタイプ機能で文書化されていたギャップへの対応 次のグラフは CBMC リポジトリの月次プルリクエスト活動です。2025 年の大半は、このリポジトリで解決された issue は月あたり 2 件未満でした。それが 11 月には 60 件に跳ね上がりました。これらのプルリクエストの多くはまだレビューを通過中で、11 月に CBMC へ提出された 64 本の Kiro のプルリクエストのうち、2026 年 9 月時点で 16 本がマージ済み、47 本がオープンのまま、1 本は別の変更で元の issue が解決されたためクローズされています。いずれも文書化されたオープン issue に対応するものです。CBMC と Kani を合わせると、2025 年 11 月と 12 月に Kiro は 87 件のユニークな issue に対応するプルリクエストを提出しました。それ以前の 22 か月（2024 年 1 月から 2025 年 10 月）に、チームが両リポジトリで対応した issue は合計 94 件でした。 図 1: 2024 年 1 月から 2025 年 12 月までの CBMC リポジトリの月次プルリクエスト活動。2025 年の大半は月あたり 2 件未満の issue しか解決されていませんでした。Kiro を導入した 2025 年 11 月には、65 本のプルリクエストで 60 件の issue に対応するまで跳ね上がりました。 2025 年 11 月と 12 月に CBMC と Kani へ提出された 94 本のプルリクエストのうち、2026 年 9 月時点で 35 本（37%）がマージ済み、56 本（60%）がオープンでレビュー中、3 本（3%）は別の変更で元の issue が解決されたためクローズされています。マージされたもののうち、提出されたそのままマージされたものもあれば、対話的な仕上げを要したものもあります。レビューのバックログは重要なボトルネックを示しています。Kiro はチームがレビューできる速度より速くプルリクエストを生成できるのです。これらは実質的な変更でした。中央値のプルリクエストは 5 ファイル・約 110 行に触れており、最大のものは約 1,000 ファイルに及びました。1 タスクあたり集中した開発作業 2〜3 時間として、94 本のプルリクエストはおよそ 200〜280 時間の実装工数に相当します。これはレビュー時間と、最終的にマージされないかもしれないプルリクエストを除いた数字であり、また多くのタスクが機械的な更新ではなくバグ修正や機能の完成であることを踏まえると、下限として見るのが妥当です。 スループットの変化も同じくらい際立っています。Kiro 導入前の 22 か月、CBMC で解決された issue は月あたり 2 件未満でしたが、2025 年 11 月には 60 件、30 倍を超える増加でした。11 月に開かれた 65 本のプルリクエストのほぼすべて（64 本）が Kiro によるもので、このスパイクが開発者の工数の振り替えではなくエージェントによる追加キャパシティを反映していることが分かります。全体として Kiro は、チームの歴史的な issue 解決スループットのおよそ 10 倍の速度で実装作業を生み出しました。ただし実際に得られる価値は、レビューと仕上げのキャパシティに左右されます。マージされたプルリクエストは引き続きリグレッションをゼロに保っており、その裏づけとなる母数はいまやはるかに大きくなっています。運用全体（2025 年 11 月から 2026 年 9 月）で、183 本の Kiro 生成プルリクエストが 2 つのリポジトリにマージされました。初期コホートで今もオープンな 56 本は、品質上の懸念ではなく先述のレビューのボトルネックを反映したものであり、リグレッションゼロという記録はそれらがレビューを通過するにつれて改めて検証されていきます。 ケーススタディ: サブモジュール更新の自動化 Kani プロジェクトは、別系統の検証ワークフロー向けに Rust プログラムの中間表現を得るため、 charon の Git サブモジュールを保守しています。 Dependabot で自動更新している他のサブモジュールと違い、charon の更新には統合テストが必要です。翻訳レイヤーの変更が、Kani が Rust のセマンティクスを正しくモデル化できるかに影響しうるからです。手作業での更新はふつう 2〜3 時間かかり、サブモジュールの更新、コンパイルとビルド失敗の調査、上流の変更の分析、リグレッションテスト、テスト失敗の調査までを含みます。この作業に開発者の時間を繰り返し費やすのではなく、私たちはこのプロセスを Kiro に引き渡し、自律的に処理させています。 図 2: Kani の charon Git サブモジュールを更新するために Kiro の自律エージェントへ与えたタスクプロンプト。小さく、説明が明確なコミットで段階的に更新するよう指示しています。 Kani の issue #2236 は 2 年以上バックログに残っていました。 Kani は Rust 向けのオープンソース形式検証ツールで、 Firecracker や s2n-quic といった重要な AWS プロジェクトの CI で使われ、 CBMC に依存しています。ファザーが Kani コンパイラのクラッシュを明確な再現手順つきで報告していましたが、根本原因を突き止めるには大きなコンテキストスイッチが必要でした。これは放置ではなく意図的なトリアージです。ユーザーをブロックする issue や健全性を脅かす issue はすぐに修正されますが、影響を受けるユーザーがいないファザー発見のクラッシュは、優先順位づけの勝負に毎回負けます。ユーザーをブロックするバグと同じだけ高価なコンテキストスイッチを要求しながら、見返りが同じではないからです。 kiro ラベルを付けたあと、Kiro は 2 時間 22 分で修正とリグレッションテストを含む PR #4461 を提出しました。人間が費やした時間は 5 分未満です。issue が古かったため、私たちは Kiro にまずバグがまだ存在するかを確認し、すでに解決されているなら再現ケースをリグレッションテストとして追加するよう依頼しました。Kiro は計画を適応させ、そのままマージできるプルリクエストを出してきました。 Kiro はさらに PR #4445 と #4464 も作り、Kani の charon Git サブモジュールを段階的に更新しました。小さく、説明が明確なコミットにするという指示だけを与えたところ、Kiro は利用可能な更新を分析し、更新の順序を決め、コミットを生成してプルリクエストを開きました。開発者は変更をレビューし、特定のコメントには /kiro fix 、すべてのコメントには /kiro all で作業を依頼できます。段階的なコミットと明確な説明のおかげで、レビュアーは機械的な更新作業ではなく意味的な正しさに集中できます。 図 3: レビュアーがプルリクエストのコメントで /kiro fix を使い、特定のレビューフィードバックへの対応を Kiro の自律エージェントに指示しています。 ケーススタディ: Kani の内部コンパイラエラーの修正 前のセクションでは Kani issue #2236 の見出しだけを紹介しました。2 年間眠っていたものが、人間の作業 5 分未満で解決した、という話です。ここでは、その人間とエージェントの協働が実際にどう進んだのかを見ていきます。 必要だったのは issue に kiro ラベルを付けることだけでした。エージェントは作業に取りかかり、issue を分析して計画を返しました。 図 4: Kani issue #2236 の調査に向けて Kiro の自律エージェントが提案した計画。リポジトリのセットアップ、バグの再現、修正の作成という手順が並んでいます。 この issue はかなり古かったので、何らかの変更で偶然すでに修正されていた可能性も十分にありました。私たちは Kiro の計画に対して、次のガイダンスを返しました。 After having set up the repository and development environment please first make sure that the bug even still exists. Please do so by creating a regression test from the code sample provided in this issue. If the bug no longer reproduces then just create a pull request that introduces this new test (and have that pull request resolve this issue). Other than that, your plan sounds good, please go ahead. Kiro は更新したタスク計画を返し、そのうえで Kani PR #4461 としてマージしたプルリクエストを作りました。チームの誰にもコンテキストスイッチは発生していません。 うまくいかなかったこと Kiro が生成したプルリクエストの失敗パターン Kiro がどこで失敗したかを理解することは、成功と同じくらい重要でした。それが作業の割り当て方とレビューの期待値を形づくったからです。 CI を通ってしまう誤った修正。 CBMC の PR #8892 では、リグレッションテストが memcpy を呼びながら --no-library を使っていたため、問題のコードパスが一度も実行されていませんでした。修正があってもなくてもテストは通ってしまいます。私たちはこれを、対象の関数を直接実行するユニットテストに置き換えました。 教訓: CI が通ることは必要条件だが十分条件ではない。レビュアーは、テストが修正を本当に検証しているかを確かめる必要がある。 アーキテクチャ的に誤った修正。 根本原因ではなく症状に対処してしまった修正もありました。PR #8703 では 172 行の再構成がネストした量化子を壊しており、正しい修正は元の場所の 9 行でした。こうしたケースにはアーキテクチャの知識を持つレビュアーが必要です。また Kiro は、既存のユーティリティを使わずに機能を作り直してしまうこともありました。 プラットフォーム固有の失敗。 Kiro は Linux 上で開発するため、プラットフォーム依存の問題がすり抜けることがあります。PR #8894 は空の構造体（ struct S {} ）を使っており、これは GCC 拡張としては有効ですが MSVC モードでは拒否されます。修正は gcc 限定のタグを追加することでした。該当するプラットフォームガードを示す既存のテストがあったにもかかわらずです。 フォーマット違反と古くなったプルリクエスト。 ほぼすべてのプルリクエストに軽微なフォーマットの問題がありました。レビューされないままのプルリクエストはコンフリクトも溜めていきます。PR #7861 は develop から 1,614 コミット遅れており、簡単ではないリベースが必要でした。コストを複利で膨らませないために、素早いレビューが欠かせません。 対話的な仕上げでループを閉じる ここまでに挙げた限界は現実のものですが、話はそこで終わりません。そのすべてが、開発者がエディタや IDE を開くことなく解決されました。 Kiro CLI を使い、メンテナーはプルリクエストのブランチで kiro-cli chat セッションを開始し、会話を通じて修正を導きます。メンテナーが判断を与え、エージェントが実行を担います。この 2 フェーズのワークフロー（自律的な生成、その後の対話的な仕上げ）は両モードの強みを組み合わせ、合計の時間コストを、開発者が各タスクを一気通貫でこなす場合よりも十分に低く保ちます。 図 5: 2 フェーズのワークフロー。Kiro の自律エージェントは、ラベルの付いた GitHub issue をサンドボックス内で分析・実装・テストまで進め、プルリクエストを開きます。メンテナーのレビューで変更が必要になったときは、対話的な Kiro CLI セッションが調査・修正・コミットを繰り返し、プルリクエストがマージできる状態になるまで仕上げます。 2 フェーズが機能する理由。 自律エージェントはコールドスタートの問題をなくします。レビューの時点で、動くコード、通っているテスト、アプローチの明確な説明がそろっているのです。対話型の CLI は非同期のやり取りの待ち時間をなくし、数時間ではなく数分で問題を解決します。どちらのフェーズも、メンテナーが自分でコードを書くことを求めません。 定性的なインパクト。 AWS Automated Reasoning Group の Senior Manager of Applied Science、Rahul Kumar は次のように述べています。「Kiro は私たちの技術的負債への向き合い方を根本的に変えました。以前は、サブモジュールの更新は機能開発からのコンテキストスイッチを要するため、何週間もバックログに居座っていました。いまは issue に kiro とラベルを付ければ、更新・テスト・ドキュメントまでワークフロー全体を処理してくれます。11 月だけで、Kiro が生成した 15 本のプルリクエストをリグレッションゼロで Kani にマージしました。」 日常的な保守を引き受けることで、Kiro は開発者を、アーキテクチャ上の決定、複雑なアルゴリズム設計、コミュニティとの関わり、そして形式検証の研究に集中させてくれます。 自分のリポジトリで Kiro Web を使う方法 自分のオープンソースプロジェクトで試してみたい方は、 こちらの手順 に従ってください。 複雑なタスクや対話的な仕上げには、上の「対話的な仕上げでループを閉じる」で説明したとおり、プルリクエストのブランチで Kiro CLI を使い、会話を通じて作業を導いてください。 参加する Kiro Web は、 app.kiro.dev にて有料の Kiro ユーザー全員に一般提供されています。すでに Kiro をご利用中の方は、 app.kiro.dev/agent にサインインして上記の手順に進んでください。 2026 年 9 月時点で、Kiro は公開されている CBMC と Kani のリポジトリに 400 本を超えるプルリクエストを提出し、そのうち 183 本がマージされ、約 150 件のユニークな issue に対応しました。430 件以上の issue をフラグ付けしたプライベートのステージングリポジトリでは、さらに 360 本を超えるプルリクエストを生成し、レビューと段階的な上流への取り込みが進んでいます。定義の明確な issue のバックログを持つリポジトリを保守しているなら、このアプローチは数分で始められます。

この記事は Kiro ブログの GPT‑5.6 models now support 1 million token context windows in Kiro を翻訳したものです。 本日より、Kiro の IDE 、 CLI 、 Web のすべてで、GPT‑5.6 Sol、Terra、Luna が 100 万トークンのコンテキストウィンドウに対応します。これにより、コードベース全体、長文ドキュメント、長く続いたマルチターンのエージェント履歴を、チャンク分割や要約を挟まず、細部を失わないまま 1 回のリクエストで処理できるようになります。 100 万トークンで何が変わるのか 272K から 1M へのジャンプは、扱える量が増えるだけの話ではありません。1 回のパスでどんな仕事が可能になるか、その種類そのものが変わります。 リポジトリ規模の理解。 コードレビュー、移行、リファクタリングにおいて、コンテキストウィンドウが大きくなることで、コンテキストを手作業で用意したり、モデルの視界に入っていない部分をセマンティック検索で近似したりする必要がなくなります。レガシー移行、依存関係のマッピング、ファイルをまたいだアーキテクチャ監査を、切り出した一部ではなくコードベース全体に対して実行できます。 エンドツーエンドのデバッグ。 難しいバグの多くは 1 つのファイルの中には存在しません。API レイヤー、スキーマ、アプリケーションの状態が互いに影響し合って現れます。1M コンテキストなら、アプリケーション全体と、マルチターンの実行ログやツール出力を一緒に渡しても、前のステップがメモリから圧縮されて落ちることはありません。 長時間にわたるエージェンティックなタスク。 複数ステップのエージェンティックな作業では、コンテキストが大きくなることでセッションの全履歴（コードのイテレーション、コンパイラの出力、ターミナルのログ）が視界に残り続けます。その結果、再プロンプトが減り、長い実行でもタスクを確実に完了できるようになります。 料金 Kiro における GPT‑5.6 の料金は、OpenAI と Amazon Bedrock が共に採用しているものと同じ 2 段階のコンテキストモデルに沿っています。今回のローンチに合わせて、GPT‑5.6 ファミリーのクレジット倍率を更新しました。272K トークンまでのリクエストは、以下のショートコンテキスト料金で課金されます。 モデル Kiro クレジット倍率 GPT‑5.6 Sol 4.4x GPT‑5.6 Terra 2.2x GPT‑5.6 Luna 1.1x 272K トークンを超えるリクエストは、OpenAI および Amazon Bedrock の GPT‑5.6 におけるロングコンテキスト料金と同様に、ショートコンテキスト料金の 2 倍で課金されます。完全な比較は モデルのドキュメント をご覧ください。 提供状況 GPT‑5.6 Sol、Terra、Luna の 1M コンテキストは、 実験的サポート として、Kiro Pro、Pro+、Pro Max、Power のお客様へ段階的にロールアウトしています。 Kiro をダウンロード するか、IDE または CLI を再起動して、利用可能な最新のモデルを確認してください。 Web をお使いの場合は、ブラウザを再読み込みするとモデルセレクターに GPT‑5.6 が表示されます。

ニューヨークの 9 月中旬には、特別なエネルギーがあります。パンプキンスパイスラテがたっぷりとあり、気温も下がってきていて、もうすぐセーターが必要となりそうな天気です。街は全速力で戻ってきました。AWS のローンチカレンダーも同様です。2026 年 9 月 14 日週、そのエネルギーは、Amazon Bedrock 上の新しいフロンティアモデル、Amazon Quick のデスクトップアプリ、そして AI エージェントで最大の効果を得ている開発者は単により良いツールを使っているだけではなく、働き方そのものが違うのだという示唆に表れていました。 では、早速見ていきましょう! 見出し OpenAI GPT-6 Astra が Amazon Bedrock 上で一般的に利用できるようになりました – GPT-6 Astra は OpenAI の最新かつ最も高性能なモデルであり、Amazon Bedrock 上で実行できるようになりました。より深い推論と判断、プロフェッショナル品質の文章とデザイン、および高度なコンピュータとブラウザの使用を、要求の厳しいビジネスワークフローにもたらします。このモデルは、最大 100 万の入力トークンのコンテキストウィンドウをサポートしているため、大規模なコードベース、長期契約、または大量のドキュメントコレクションを送信して、競合する入力を調整するように依頼できます。 サポートされている Amazon Bedrock API を使用して GPT-6 Astra を呼び出すことも、Amazon Bedrock のモデルを使用するように ChatGPT Work と Codex を設定することもできます。ローンチと並行して、OpenAI は ChatGPT Work 用の新しいエンタープライズプラグインを導入しています。これにより、Astra のブラウザ使用機能を一般的なビジネスアプリケーション全体に拡張できます。確立された AWS 統制は、ワークロードの保護、アクセスの管理、モデル呼び出しアクティビティの監査に役立ちます。また、推論データはモデルトレーニングには使用されません。 もっと読む 2026 年 9 月 7 日週のリリース 9 月 7 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon Quick デスクトップアプリが macOS と Windows で一般的に利用できるようになりました – Amazon Quick デスクトップアプリを使用すると、Amazon Quick をコンピュータに接続して、ローカルファイルを操作したり、バックグラウンドでカレンダー、E メール、ビジネスアプリに接続したままにしたりできます。会話、コンテキスト、エージェントはデスクトップとモバイル全体で同期したままであるため、ある画面で始めた作業が別の画面に引き継がれます。今回のリリースでは、Quick エージェントはコンピュータを閉じた後も実行され続けるため、オフィスを離れる前に長時間かかるタスクを開始し、帰宅中にモバイルアプリからの入力を追加して、帰宅時に結果を確認することができます。既存の Quick ユーザーは デスクトップアプリをダウンロード でき、モバイルアプリは Apple App Store と Google Play から入手できます。 もっと読む AWS Lambda が Lambda マネージドインスタンスで 90 分の関数タイムアウトをサポートするようになりました – Lambda マネージドインスタンスでの非同期呼び出しとイベントソースマッピング (ESM) 呼び出しでは、最大 90 分の関数タイムアウトを設定できるようになりました。これは、以前の 15 分の制限から 6 倍に増加しています。これにより、作業を複数の関数に分割することなく、より長い継続実行を必要とするデータ処理、メディアトランスコーディング、財務計算、AI 推論、およびバッチジョブへの扉が開かれます。同期呼び出しでは、既存の最大 15 分が維持されます。より長いタイムアウトは、非同期で呼び出された場合、最大 1 年間実行できる Lambda 永続関数内のステップにも適用されます。 もっと読む Amazon EBS Volume Clones がアカウント間でボリュームをコピーするようになりました – Amazon Elastic Block Store (Amazon EBS) Volume Clones は、ボリュームを別の AWS アカウントにコピーし、ターゲットアカウントの AWS Key Management Service (AWS KMS) キーで再暗号化できるようになりました。本番稼働用と開発用を別々のアカウントで維持する場合は、ボリュームを AWS Resource Access Manager (AWS RAM) と共有し、ターゲットアカウントに同じアベイラビリティーゾーンで新しいコピーを作成させることができます。例えば、本番稼働のデータベースボリュームを独立した開発のアカウントに複製できます。クロスアカウントコピーは、暗号化されていないボリュームやカスタマーマネージドキーで暗号化されたボリュームなど、すべてのボリュームタイプで機能します。 もっと読む 第 2 世代のシングルラック AWS Outposts が一般的に利用できるようになりました – 新しいシングルラック AWS Outposts は自己完結型の 42U ラックで、コンピューティング、ストレージ、ネットワーキングを 1 つのコンパクトなユニットにまとめたものであり、低レイテンシー、ローカルデータ処理、またはデータレジデンシーが必要で、設置面積を大きくする余地がない場所に適しています。シングルラックは最大 2,688 の vCPU と 100 TB の Amazon EBS ストレージを搭載し、汎用 (M7i、M8i)、コンピューティング最適化 (C7i、C8i)、メモリ最適化 (R7i、R8i)、Outposts アクセラレーテッドネットワーキングインスタンスなど、x86 搭載の最新の Amazon EC2 インスタンスをサポートしています。マルチラックの Outposts や AWS リージョンと同じ API、コンソール、自動化、ガバナンス、セキュリティコントロールを利用できます。 もっと読む Amazon OpenSearch Serverless が Vercel の v0 で利用可能になりました – Vercel の v0 内で検索または AI アプリケーションを自然言語で記述し、Amazon OpenSearch Serverless でバックアップされたフルスタックアプリを入手できるようになりました。v0 は、コレクションをプロビジョニングし、データをインデックス化し、OpenSearch Serverless エンドポイントを使用して検索拡張生成 (RAG) ワークロードのフルテキスト検索とベクトル検索を、v0 インターフェイスを離れることなく行います。OpenSearch Serverless はユーザーに代わってキャパシティをスケールアップ/ダウンするので、ユーザーはクラスター管理ではなくアプリケーションに集中できます。新しい AWS アカウントでプロビジョニングすることも、既存の AWS アカウントをリンクすることもできます。 もっと読む AWS Transform for .NET モダナイズが CLI を介して一般的に利用できるようになりました – AWS Transform カスタムで AWS マネージド .NET モダナイズを単一の CLI コマンドでトリガーし、インタラクティブに実行したり、既存のパイプラインにスクリプト化したりできます。CLI は、ウェブアプリケーション、Visual Studio IDE、Kiro パワー、および MCP エージェントでの既存の AWS Transform for .NET エクスペリエンスと並行して機能します。言語バージョンのアップグレード、フレームワークの移行、パフォーマンスの最適化、そのまま実行またはカスタマイズできる変換によるコードベースの分析に使用できます。.NET モダナイズの変換には、1 か月あたり 50,000 分の無料エージェント時間が含まれます。 もっと読む AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他の AWS のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: Clare Liguori がフロンティアエンジニアリングについて発表 – 既に AI コーディングアシスタントを使用しているけれども、リリースがそれほど速くないと感じている場合は、ここから始めてください。AWS のシニアプリンシパルエンジニアである Clare Liguori が、 フロンティアエンジニアリング に関する実践者向けマニフェストを発表しました。これは、Amazon 全体のチームから引用された、AI エージェントによるソフトウェアの構築方法を変えるための 10 の原則です。議論は直接的です。ソフトウェア開発は、エージェントとの連携方法を変えた人と、コーディングツールだけを変えた人の 2 つに分かれています。フロンティアエンジニアリングはバイブコーディングではありません。最初の数週間は、ステアリングファイルの作成、コードベースのリファクタリング、エージェントの作業の細分化の学習に費やします。それらの週はゆっくりと感じられます。その後数週間は、ソフトウェアを直接構築するのではなく、ソフトウェアを構築するエージェントのセットアップを構築することになるため、劇的に速く感じられます。 世界中の学生に Kiro を 1 年間無料で提供 – Kiro Students プログラムは、11 の大学から 16 か国の 121 の新しい学校に拡大しています。対象となる学生は、1 か月あたり 1,000 クレジットで Kiro を 1 年間利用でき、プレミアムモデルや Kiro Web などの有料機能をすべて利用できます。クレジットカードやトライアルタイマーは不要です。IDE、CLI、ブラウザの Kiro Web、または Kiro Crew で作業できます。ユーザーが学生である場合は、 大学の E メールアドレスでサインアップ してください。 セキュリティのための AI の現状: 信頼にとって何が重要かを測定する – セキュリティチームはトリアージ、脅威モデリング、インシデント対応、コードレビューに AI を使用していますが、すべてにフラグを立てるツールでは時間の節約にはなりません。「 セキュリティのための AI の現状 」では、Anshumali Shrivastava 氏と Neha Rungta 氏が Deception Benchmark を紹介しました。これは、モデルが実際の脆弱性と、リスクが高いように見えるけれども実際には安全なコードを見分けることができるかどうかをテストする新しい評価です。ベンチマークには、16 の言語と 70 を超える共通脆弱性タイプ一覧 (CWE) カテゴリ全体で 14,822 のサンプルが含まれています。標準プロンプトでは、精度は 55% 前後に達しますが、精度とほぼ同じくらい不正確になる可能性も高く、テストした 12 のモデルのいずれも、偽陽性と偽陰性の両方を 10％ 未満に抑えていませんでした。投稿は、検証済みの採点のためのデータセット、ホワイトペーパー、および送信ワークフローにリンクしています。 AI を活用した足場により、フルスタック AWS アプリケーションを数分で構築 – Nx Plugin for AWS のバージョン 1.0 は、API、ウェブサイト、データベース、AI エージェント用の決定論的ジェネレーターと、それらを実行するための AWS インフラストラクチャを含むオープンソースのツールキットです。各ジェネレーターは、セキュリティ、オブザーバビリティ、および型安全性が既に実装された状態で、実際にデプロイ可能なコードを作成しているため、AI アシスタントは基盤を組み立て、アプリケーションロジックに労力を費やすことができます。Bingo Industries ではこれを利用して、マルチエージェント運用チャットボットをアイデアから本番稼働までを 3 週間未満で完了させました。プラグインは GitHub 上のオープンソース です。 pnpm create @aws/nx-workspace を使用してワークスペースを作成し、コーディングエージェントに付属の MCP サーバーを指定します。 コンピューティングでの最も古いアーキテクチャ – 「 All Things Distributed 」で、Werner Vogels 氏はお客様からよく聞かれる質問「AI が私の仕事を取ってしまうのか?」という質問から始めます。そして記憶に行き着きます。Kiro Crew で時間を過ごした後、彼は Jeff Hawkins の「 A Thousand Brains 」から、Crew がマークダウンファイル、ベクトルデータベース、およびキーバリューインデックスでどのように保存、統合、忘却を行うかまでの線をなぞります。彼の結論は、脳はコンピューティングでの最も古いアーキテクチャであり、それがどのように機能するかを最もよく考えた人が次のツールを構築するということです。さあ、構築しましょう。 AWS のブログ記事の詳細な一覧については、 AWS ブログ ページをご確認ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Summits – AWS Summits は、クラウドや AI のコミュニティが一堂に会し、つながり、学び、そして最新のテクノロジーを探求するための無料の対面イベントです。 今後の場所にはドバイ (9 月 30 日) が含まれます。 カレンダー全体 を閲覧してお近くのサミットを探したり、グローバルライブストリームやオンデマンドハブを介してセッションをストリーミングしたりできます。 AWS Community Days – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。今後のイベントには、 ベルリンでの DACH (9 月 15 日) 、 ブダペストでの CEE (9 月 17 日) 、 オランダのユトレヒト (9 月 23 日) 、 南フロリダのマイアミ (10 月 14 日) 、 オーストラリアのブリスベン (10 月 16 日) などがあります。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 9 月 14 日週のニュースは以上です。9 月 21 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! – Micah この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2026 年 5 月 21 日から 23 日に開催された「第 21 回情報危機管理コンテスト」にて経済産業大臣賞 と AWS 賞 を受賞した 『ITソルーション室_げんこつ』 の皆様にインタビューを行いました。 情報危機管理コンテストは、企業インフラを模した環境で発生するセキュリティインシデントに対し、参加チームが調査・対応を行い、主催者が用意した窓口へ報告を行う実践的なコンテストです。今回はチーム編成や役割分担、コンテストへの準備に加えて、生成 AI の活用が進むなかでのインシデントレスポンスの変化についてもお話をうかがうことができました。インタビュー記事を通して、コンテストで得た学びや、これからのクラウド、AI 、自身のキャリアイメージなどをお伝えできればと思います。 ITソルーション室_げんこつ 静岡大学 総合科学技術研究科 情報学専攻 1 年 河口 欣仁 氏 情報学部 情報科学科 3 年 高島 湊斗 氏 総合科学技術研究科 情報学専攻 2 年 髙橋 陽拓 氏 情報学部 行動情報学科 4 年 齊藤 遼太 氏 日々の研究や活動について AWS : はじめに、日々どのような研究や活動をされていますか。 河口 : 教育分野での LLM エージェント活用を研究しています。個人的には Web 開発の経験が長く、アルバイトや受託開発のほか、AWS と関わりのある企業に 1 年ほど在籍していたこともあります。 齊藤 : サイバーセキュリティ領域で、バイナリの静的解析やデコンパイラの研究開発が専門です。セキュリティ・キャンプでは受講生・講師の両方を経験し、サイバー・スレット・インテリジェンス領域でのインターンも経験しています。 高島 : 自分で法人を立ち上げ、AI システムの PoC や業務システムの受託開発をしています。法人設立から半年ほど、個人事業も含めると数年ほどシステム開発に携わっています。 髙橋 : 生成 AI 系の研究で、オントロジーを AI に読み込ませ、背景の概念が変化したときにマッピングを自動化するテーマに取り組んでいます。 『げんこつ』 と ITソルーション室について AWS : ITソルーション室とはどのような組織ですか。 齊藤 : 静岡大学 情報学部の学生団体です。浜松キャンパスで IT やパソコンのトラブルを持ち込んでもらい、学生が一次対応として解決しています。年間 100〜200 件ほど対応しています。大学から部屋と予算をいただき、独自ネットワークの運用や勉強会、コンテスト出場といった活動をしています。アクティブメンバーは約 40 人で、浜松キャンパスの人なら誰でも入れます。 AWS : チーム『げんこつ』の成り立ちを教えてください。 齊藤 : もともと「 sawayaka-sec (さわやかセキュリティ)」というチームが 6〜7 年前に大木研究室から始まり、情報危機管理コンテストで受賞するなど実績を重ねてきました。そこから系譜が続き、当初は研究室メンバーが多かったのですが、次第に ITソルーション室のメンバーが増えました。今年は研究室系が私だけになったため、チーム名を「げんこつ」に変更しました。情報危機管理コンテストには通算 8 年参加しています。 コンテストでの役割分担 AWS : 今回の役割分担はどのように決めましたか。 齊藤 : 私がコマンダーとして全体の意思決定・レポーティング・先方とのやり取りを担当しました。他のメンバーには、意思決定に必要な情報を集めるファストフォレンジックを分担してもらいました。 河口 : 準備段階でも役割が分かれていました。得意領域の調査、事前に環境を再現して起きそうなことを練る人、エージェントを前もって作る人、特化した MCP を作る人もいました。 AWS : 役割の割り振りはどう決まるのですか。 齊藤 : 明確に指名するのではなく、「エージェント基盤をなんとなく用意しておいてね」「こういう技術が使われそうなので予習しておいてね」といった形です。お互いの得意分野を分かっているので、自然と決まっていきます。 コンテストで得た学び AWS : 今回のコンテストで得た学びを教えてください。 齊藤 : AI エージェントを使えば、インシデントレスポンスの技術的な部分の 8 割ほどを代替できる時代になったと感じています。コンテストは、かつて技術とそれ以外が半々だったのが、意思決定のゲームに変わってきています。その中で我々が明確にミスしたのは、意思決定のときに「仮定」と「事実」を混同した点です。結論ありきで「この仮定が正しければこうなるはずだ」という調査をしてしまいました。「2 時間以内にどうにかしてください」という時間的プレッシャーもありました。 河口 : エッジで情報を集めるメンバー間で横のコミュニケーションから筋の通らない仮説が立ち、「この結論を論じるために情報を取りに行こう」という合意をコマンダーに投げてしまうことがありました。コマンダーもエッジの人間も、その状況をメタ的に認知できていなかったのが反省点です。 AWS : 次に活かすとしたら、どのように改善しますか。 河口 : 自分たちがどういう情報にアクセスでき何を知れるのかを初動で把握し、症状と原因を分けて考えるべきでした。症状の原因を当てずっぽうに追うのではなく、アクセスできる情報を一つずつ見て原因を探り当てるべきだったと思います。 齊藤 : インシデントレスポンスに残る技術的要素とは、「今使える事実は何が存在し、どこから取りうるのか」に対する直感を持っていることだと思います。今回、AWS コンソールに対してその直感を持っている人があまり多くなかった。 髙橋 : その直感を持っていたチームがあり、彼らは対象環境をほぼ完答していました。我々はプレッシャーの中で「こうすればうまくいくだろう」という方向に飛びつき、そこで 30 分ほど失ったのが大きかったです。 今後のキャリアへの影響 AWS : 今回の経験は今後のキャリアにどうつながりますか。 髙橋 : 一次情報や確定したドキュメントを大切にする姿勢は、今後も活かしていきたいです。 高島 : 先ほどの「結論ありきで情報を探してしまった」反省で、結論を一番出していたのは僕だと思います。今後は AI に自分が収集しきれない範囲まで集めてもらい、自分は意思決定に時間を集中させたいと考えています。 齊藤 : 私の専門のバイナリ解析は、インテリジェンスが欲しいから行うものです。マルウェアを解析して通信先を突き止め、攻撃者の属性（アトリビューション）を導く。そのためには事実とインテリジェンスの切り分けが重要で、当面は人間側にも一定の専門性が求められます。AI を前提とした専門性について考えるきっかけになりました。 河口 : 大きく 2 つあります。1 つは、インシデントが起きる前提でどう対応するか、信頼性の高い環境をどう作るか、許容されるダウンタイムについて利害関係者とどう合意するか、といったことを具体的に考える機会になった点です。作り込まれたシナリオが良い材料になりました。もう 1 つは、シビアな事態でのチームや個々のメンバーの心情をキャッチする大切さです。情報は人的要因で歪むことがあるので、心理的安全性に配慮したコミュニケーションと、二人で一緒に確認する進め方が大事だと感じています。 これから参加される方に向けて AWS : 最後に、これから参加される方へ一言お願いします。 齊藤 : 本物に近いインフラの上で本物に近いインシデントが起きる体験は、学生が独力で用意するのはかなり難しい。それが無料で参加でき、決勝まで進めば会場（和歌山県白浜）までの費用も負担されます。机上演習としての学習効果は高く、私は 3 回参加しましたが毎回学びがあります。最近は出場チームが固定化しつつあるので、参加チームが増えてほしいと思っています。 おわりに ITソルーション室_げんこつ の皆様、お忙しい中インタビューに快く対応いただきありがとうございました。 このブログは、2026 年 8 月時点の情報に基づいて ソリューションアーキテクト 深井 宣之 が執筆しました。