TECH PLAY

AWS

AWS の技術ブログ

3097

2026 年 2 月 16 日、 Amazon Elastic Compute Cloud (Amazon EC2) Hpc8a インスタンスの一般提供についてお知らせしたいと思います。このインスタンスは、最新の第 5 世代 AMD EPYC プロセッサを搭載した新しいハイパフォーマンスコンピューティング (HPC) 最適化インスタンスタイプであり、周波数は最大 4.5 GHz です。Hpc8a インスタンスは、数値流体力学、より高速な設計イテレーションのためのシミュレーション、限られた作業時間内での高解像度気象モデリング、迅速な TTR (Time-to-Results) を必要とする複雑な衝突シミュレーションなど、コンピューティング集約型の密結合 HPC ワークロードに最適です。 新しい HPC8a インスタンスは、前世代の Hpc7a インスタンス よりも最大 40% 優れたパフォーマンス、42% 広いメモリ帯域幅、最大 25% 優れた料金パフォーマンスを実現します。お客様は、コンピューティング集約型のシミュレーションワークロードでの効率的なスケーリングとジョブ完了時間の短縮に役立つ、高いコア密度、メモリ帯域幅、低レイテンシーネットワーキングからメリットを得られます。 Hpc8a インスタンス Hpc8a インスタンスでは、192 個のコア、768 GiB のメモリ、300 Gbps の Elastic Fabric Adapter (EFA) ネットワーキングを利用して、高レベルのノード間通信を大規模に行う必要があるアプリケーションを実行できます。 インスタンス名 物理コア数 メモリ (Gib) EFA ネットワーク帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) アタッチされたストレージ Hpc8a.96xlarge 192 768 最大 300 75 EBS のみ Hpc8a インスタンスは 96xlarge サイズのみで提供されており、コアとメモリの比率は 1:4 です。インスタンス起動時に必要なコアの数をカスタマイズすることで、HPC ワークロード要件に基づいて適切なサイズを設定できます。これらのインスタンスは第 6 世代の AWS Nitro Card も使用しており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードして、ワークロードのパフォーマンスとセキュリティを強化します。 Hpc8a インスタンスは、 AWS ParallelCluster および AWS Parallel Computing Service (AWS PCS) で使用してワークロードの送信とクラスターの作成を簡素化、または Amazon FSx for Lustre で使用してストレージにミリ秒未満のレイテンシーと 1 秒あたり最大数百ギガバイトのスループットを実現できます。HPC ワークロードで最高のパフォーマンスを達成するため、このインスタンスでは同時マルチスレッド (SMT) が無効化されています。 今すぐご利用いただけます Amazon EC2 Hpc8a インスタンスは、米国東部 (オハイオ) と欧州 (ストックホルム) AWS リージョン で今すぐご利用いただけます。リージョンごとの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 このインスタンスは、 オンデマンドインスタンス および Savings Plan として購入できます。 詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で Hpc8a インスタンスをお試しください。詳細については、 Amazon EC2 Hpc8a インスタンスページ をご覧ください。フィードバックは、 AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Channy 原文は こちら です。
アバター
AWS New Summit 2025 で Amazon SageMaker AI の Amazon Nova カスタマイズ をリリースして以来、お客様からは Amazon SageMaker Inference でオープンウェイトモデルをカスタマイズする場合と同じ機能を Amazon Nova でも使用したいと伺っていました。また、本番環境のワークロードに必要なインスタンスタイプ、自動スケーリングポリシー、コンテキストの長さ、同時実行設定について、カスタムモデル推論の制御と柔軟性を高めたいという声もお聞きしました。 2026 年 2 月 16 日、Amazon SageMaker Inference でのカスタム Nova モデルサポートの一般提供を発表いたしました。これは、フルランクのカスタマイズされた Nova モデルをデプロイおよびスケールするための、本番環境グレードかつ設定可能で、コスト効率の高いマネージド推論サービスです。 Amazon SageMaker Training Jobs または Amazon HyperPod を使用して Nova Micro、Nova Lite、Nova 2 Lite の各モデルを推論機能付きでトレーニングし、Amazon SageMaker AI のマネージド推論インフラストラクチャを利用してシームレスにデプロイする、エンドツーエンドのカスタマイズジャーニーをご体験いただけるようになりました。 カスタム Nova モデル用の Amazon SageMaker Inference では、 P5 インスタンス の代わりに Amazon Elastic Compute Cloud (Amazon EC2) の G5 および G6 インスタンスを使用した GPU 使用率の最適化、5 分間の使用パターンに基づく自動スケーリング、設定可能な推論パラメータを通じて推論コストを削減できます。この機能により、継続的な事前トレーニング、教師ありのファインチューニング、またはユースケースに合わせた強化ファインチューニングを使用して、カスタマイズされた Nova モデル向けにデプロイできます。また、コンテキストの長さ、同時実行数、バッチサイズに関する詳細設定を設定して、特定のワークロードのレイテンシーとコスト精度のトレードオフを最適化することもできます。 カスタマイズした Nova モデルを SageMaker AI リアルタイムエンドポイントにデプロイする方法、推論パラメータを設定する方法、テスト用にモデルを呼び出す方法を見てみましょう。 SageMaker 推論にカスタム Nova モデルをデプロイする AWS re:Invent 2025 では、Nova モデルを含む一般的な AI モデル向けに Amazon SageMaker AI の新しいサーバーレスカスタマイズ を導入しました。数回クリックするだけで、モデルとカスタマイズ手法をシームレスに選択し、モデル評価とデプロイを行うことができます。トレーニング済みのカスタム Nova モデルアーティファクトが既にある場合は、 SageMaker Studio または SageMaker AI SDK を通じて SageMaker Inference でモデルをデプロイできます。 SageMaker Studio の [モデル] メニューで、お使いのモデル内のモデルで、トレーニング済みの Nova モデルを選択します。 [デプロイ] ボタン、 [SageMaker AI] 、 [新規エンドポイントを作成] を選択して、モデルをデプロイできます。 エンドポイント名、インスタンスタイプ、およびインスタンス数、最大インスタンス数、アクセス許可とネットワークなどの詳細オプション、 [デプロイ] ボタンを選択します。GA の起動時には、Nova Micro モデルの場合は g5.12xlarge 、 g5.24xlarge 、 g5.48xlarge 、 g6.12xlarge 、 g6.24xlarge 、 g6.48xlarge 、 p5.48xlarge インスタンスタイプ、Nova Lite モデルの場合は g5.24xlarge 、 g5.48xlarge 、 g6.24xlarge 、 g6.48xlarge 、 p5.48xlarge 、Nova 2 Lite モデルの場合は p5.48xlarge を使用できます。 エンドポイントを作成する際には、インフラストラクチャのプロビジョニング、モデルアーティファクトのダウンロード、推論コンテナの初期化に時間がかかります。 モデルのデプロイが完了し、エンドポイントのステータスで [InService] と表示されたら、新しいエンドポイントを使用してリアルタイムの推論を実行できます。モデルをテストするには、 [プレイグラウンド] タブを選択し、 チャット モードでプロンプトを入力します。 SageMaker AI SDK を使用して 2 つのリソースを作成することもできます。1 つは Nova モデルアーティファクトを参照する SageMaker AI モデルオブジェクトで、もう 1 つはモデルのデプロイ方法を定義するエンドポイント設定です。 次のコードは、Nova モデルアーティファクトを参照する SageMaker AI モデルを作成します。 # Create a SageMaker AI model model_response = sagemaker.create_model( ModelName= 'Nova-micro-ml-g5-12xlarge', PrimaryContainer={ 'Image': '123456789012.dkr.ecr.us-east-1.amazonaws.com/nova-inference-repo:v1.0.0', 'ModelDataSource': { 'S3DataSource': { 'S3Uri': 's3://your-bucket-name/path/to/model/artifacts/', 'S3DataType': 'S3Prefix', 'CompressionType': 'None' } }, # Model Parameters 'Environment': { 'CONTEXT_LENGTH': 8000, 'CONCURRENCY': 16, 'DEFAULT_TEMPERATURE': 0.0, 'DEFAULT_TOP_P': 1.0 } }, ExecutionRoleArn=SAGEMAKER_EXECUTION_ROLE_ARN, EnableNetworkIsolation=True ) print("Model created successfully!") 次に、デプロイインフラストラクチャを定義するエンドポイント設定を作成し、SageMaker AI リアルタイムエンドポイントを作成して Nova モデルをデプロイします。このエンドポイントはモデルをホストし、推論リクエストを行うための安全な HTTPS エンドポイントを提供します。 # Create Endpoint Configuration production_variant = { 'VariantName': 'primary', 'ModelName': 'Nova-micro-ml-g5-12xlarge', 'InitialInstanceCount': 1, 'InstanceType': 'ml.g5.12xlarge', } config_response = sagemaker.create_endpoint_config( EndpointConfigName= 'Nova-micro-ml-g5-12xlarge-Config', ProductionVariants= production_variant ) print("Endpoint configuration created successfully!") # Deploy your Noval model endpoint_response = sagemaker.create_endpoint( EndpointName= 'Nova-micro-ml-g5-12xlarge-endpoint', EndpointConfigName= 'Nova-micro-ml-g5-12xlarge-Config' ) print("Endpoint creation initiated successfully!") エンドポイントが作成されたら、推論リクエストを送信してカスタム Nova モデルから予測を生成できます。Amazon SageMaker AI は、ストリーミング/非ストリーミングモードのリアルタイム用の同期エンドポイントと、バッチ処理用の非同期エンドポイントをサポートします。 例えば、次のコードはテキスト生成用のストリーミング補完形式を作成します。 # Streaming chat request with comprehensive parameters streaming_request = { "messages": [ {"role": "user", "content": "Compare our Q4 2025 actual spend against budget across all departments and highlight variances exceeding 10%"} ], "max_tokens": 512, "stream": True, "temperature": 0.7, "top_p": 0.95, "top_k": 40, "logprobs": True, "top_logprobs": 2, "reasoning_effort": "low", # Options: "low", "high" "stream_options": {"include_usage": True} } invoke_nova_endpoint(streaming_request) def invoke_nova_endpoint(request_body): """ Invoke Nova endpoint with automatic streaming detection. Args: request_body (dict): Request payload containing prompt and parameters Returns: dict: Response from the model (for non-streaming requests) None: For streaming requests (prints output directly) """ body = json.dumps(request_body) is_streaming = request_body.get("stream", False) try: print(f"Invoking endpoint ({'streaming' if is_streaming else 'non-streaming'})...") if is_streaming: response = runtime_client.invoke_endpoint_with_response_stream( EndpointName=ENDPOINT_NAME, ContentType='application/json', Body=body ) event_stream = response['Body'] for event in event_stream: if 'PayloadPart' in event: chunk = event['PayloadPart'] if 'Bytes' in chunk: data = chunk['Bytes'].decode() print("Chunk:", data) else: # Non-streaming inference response = runtime_client.invoke_endpoint( EndpointName=ENDPOINT_NAME, ContentType='application/json', Accept='application/json', Body=body ) response_body = response['Body'].read().decode('utf-8') result = json.loads(response_body) print("✅ Response received successfully") return result except ClientError as e: error_code = e.response['Error']['Code'] error_message = e.response['Error']['Message'] print(f"❌ AWS Error: {error_code} - {error_message}") except Exception as e: print(f"❌ Unexpected error: {str(e)}") 完全なコード例を使用するには、「 Amazon SageMaker AI での Amazon Nova モデルのカスタマイズ 」をご参照ください。モデルのデプロイと管理に関するベストプラクティスの詳細については、「 SageMaker AI のベストプラクティス 」をご覧ください。 今すぐご利用いただけます カスタム Nova モデル用の Amazon SageMaker Inference は、2026 年 2 月 16 日、米国東部 (バージニア北部) および米国西部 (オレゴン) の AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 この機能は、自動スケーリングを使用して EC2 G5、G6、P5 インスタンスで実行される、推論機能を備えた Nova Micro、Nova Lite、Nova 2 Lite モデルをサポートします。使用したコンピューティングインスタンス分のみに対してお支払いいただきます。時間単位の請求で、最小契約はありません。詳細については、 Amazon SageMaker AI の料金ページ をご覧ください。 Amazon SageMaker AI コンソール をぜひお試しいただき、 AWS re:Post for SageMaker 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。
アバター
みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。今週号も盛りだくさんです。開催直前になりますが、2 月 27 日 (金)に「 企業でつかうためのCoding Agent「Kiro」 オンライン勉強会 」が開催されます。まだ申し込み受付中ですのでAI エージェントを活用した開発プロセスの効率化に関心がある方はぜひ参加ください!また 3 月 26 日(木)には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください! それでは 2 月 16 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI事例ブログ「BMW Group が AWS 上のエージェンティック検索でペタバイト規模のデータからインサイトを引き出す」を公開 BMW Group が AWS Professional Services と協力し、Amazon S3 Vectors、Amazon Bedrock、Amazon Bedrock AgentCore を活用したエージェンティック検索ソリューションを構築した事例が紹介されています。20 PB のデータを保有する同社のデータレイクハウスに対し、ハイブリッド検索・網羅的検索・SQL クエリの 3 つのアプローチを AI エージェントが自動的に切り替えることで、技術的な専門知識がなくても自然言語で大規模データからインサイトを引き出せるようになりました。生成 AI を活用してデータ分析の民主化を実現するアーキテクチャの実例として、エージェンティック AI の実装パターンやサーバーレスアーキテクチャによるコスト効率の高い運用方法を学ぶことができます。 AWS生成AI国内事例ブログ「『導入しても使われない』を解決する ― 三菱電機 電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化」を公開 三菱電機 電力ICTセンターが、開発者向けエージェント型 IDE「Kiro」の Steering・Powers・MCP の 3 層構造と GitLab を組み合わせ、「AI に聞けばワークフローに沿った開発ができる」というプラットフォームを構築した事例が紹介されています。Issue 作成からブランチ作成、実装、MR 作成、レビューまでの開発フロー全体を Powers に定義し、さらに Kiro によるコード生成と GitLab Duo によるレビューという AI 同士の協働により、人間のレビュー負担を軽減しながら品質を担保するワークフローを実現しています。生成 AI を活用した開発効率化に取り組むユーザーにとって、ドキュメントを読んでも AI に聞いても同じ結果にたどり着ける仕組みづくりや、AI エージェントの振る舞いを組織のルールに沿って制御する具体的な方法を学ぶことができます。 AWS生成AI国内事例ブログ「メック株式会社の事例:Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化」を公開 メック株式会社が Amazon Bedrock AgentCore と Amazon S3 Vectors を活用し、研究業務における情報検索と情報更新を AI エージェントで自動化したソリューションを約 3 週間で構築した事例が紹介されています。情報検索エージェントはユーザーの質問をそのまま検索するのではなく専門知識をもとに最適なクエリを自動生成し、情報更新エージェントは新規情報にコンテキストやメタデータを自動付与することで、経験年数に関わらず高品質な情報アクセスと知的資産の体系的な蓄積を実現しています。生成 AI を活用したエージェント開発に取り組むユーザーにとって、Bedrock AgentCore Runtime のサーバーレスなランタイム環境と Strands Agents を組み合わせた PoC のスモールスタート事例として参考になります。 AWS生成AI国内事例ブログ「小売業界の未来を切り拓く:東芝テックが AWS の AI エージェントを活用した店舗運営支援ソリューションを開発」を公開 東芝テックが Amazon Bedrock と Amazon Bedrock AgentCore、Strands Agents SDK を活用し、POS データや在庫情報、IoT センサーデータを AI エージェントが継続的にモニターして売り場責任者に具体的な推奨アクションを通知する店舗運営支援ソリューションを開発した事例が紹介されています。ベテラン担当者の業務知識を管理画面から自然言語でインプットするだけでノーコードで AI エージェントを開発でき、24 時間 365 日バックグラウンドで稼働することで、経験年数に関わらずデータドリブンな意思決定が可能になります。生成 AI を活用した小売業向けソリューションに取り組むユーザーにとって、AgentCore Runtime によるサーバーレスなエージェント運用や AgentCore Memory による対話の記憶を活かしたパーソナライズなど、実践的なアーキテクチャの参考になります。 ブログ記事「AWS で NVIDIA Cosmos world foundation models を実行」を公開 自律走行車やロボティクス、スマートファクトリーなどのフィジカル AI 開発では、高品質なトレーニングデータの不足が大きな課題となっています。本ブログでは、NVIDIA Cosmos ワールドファウンデーションモデル (WFM) を AWS 上にデプロイし、物理的に妥当性のある合成データを大規模に生成する方法として、Amazon Elastic Kubernetes Service (Amazon EKS) を使ったリアルタイム推論と AWS Batch を使ったバッチ推論の 2 つの本番環境向けアーキテクチャを紹介しています。生成 AI を活用したフィジカル AI の開発に取り組むユーザーにとって、実世界のデータ収集に頼らず合成データで開発サイクルを加速できる具体的な実装パターンを学ぶことができます。 ブログ記事「リファクタリングを正しく行う:プログラム解析により AI エージェントの安全性と信頼性を高める方法」を公開 AI コーディングアシスタントにシンボルの名前変更やファイル移動といったリファクタリングを依頼すると、インポートの破損や参照の欠落が発生しがちですが、本ブログでは開発者向けエージェント型 IDE「Kiro」が IDE の言語サーバーを活用した「セマンティックリネームツール」と「スマートリロケートツール」でこの課題をどう解決するかを解説しています。LLM によるテキストベースの検索置換に頼るのではなく、コードの構造を理解するプログラム解析を組み合わせることで、ワークスペース全体にわたる変更を安全かつ正確に反映でき、リファクタリング後のデバッグ作業を大幅に削減できます。生成 AI を活用した開発に取り組むユーザーにとって、AI エージェントの出力をより信頼できるものにするための「構築による正確性」というアプローチの具体的な実装例として参考になります。 ブログ記事「バグ修正と既存アプリの上に構築するための新しい Spec タイプ」を公開 開発者向けエージェント型 IDE「Kiro」の仕様駆動開発ワークフロー Specs に、「デザインファースト」と「バグ修正」の 2 つの新しい Spec タイプが追加されました。デザインファースト Spec は技術的アプローチがすでに決まっている既存アプリへの機能追加に、バグ修正 Spec は「現在の振る舞い」「期待される振る舞い」「変更されない振る舞い」の 3 セクション構造で外科的な修正を行う場合に適しており、いずれもプロパティベーステストによる検証まで一貫して行えます。生成 AI を活用した開発に取り組むユーザーにとって、新規開発だけでなく既存コードベースの保守・改善においても、AI エージェントと効果的に協働するための実践的なアプローチを学ぶことができます。 ブログ記事「Claude Sonnet 4.6 が Kiro で利用可能になりました」を公開 開発者向けエージェント型 IDE「Kiro」の IDE および CLI で、Anthropic の Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.6 は Sonnet 4.5 からの完全なアップグレードで、Opus 4.6 に匹敵する知能を持ちながらトークン効率が高く、複数ステップのツール呼び出しや長いセッションでのコンテキスト維持など、エージェント作業に特化して構築されています。生成 AI を活用した開発に取り組むユーザーにとって、機能構築やリファクタリング、デバッグなどの反復的な開発ワークフローにおいて、より高速で高品質なタスク完了が期待できるモデルです。 ブログ記事「Kiro のエンタープライズ ID 連携と使用状況メトリクス」を公開 開発者向けエージェント型 IDE「Kiro」が、外部 ID プロバイダー(Okta と Microsoft Entra ID)との連携とユーザーレベルのアクティビティメトリクスをサポートしました。管理者は既存の SSO ポリシーや MFA 適用をそのまま Kiro に適用でき、IDE・CLI・Web アプリ全体でのチーム利用状況をクライアントタイプごとに可視化できるようになります。組織で生成 AI を活用した開発ツールの導入を検討しているユーザーにとって、既存の ID 基盤やコンプライアンス要件を維持しながらチーム全体への展開と利用状況の把握を実現できるエンタープライズ向け機能として注目です。 ブログ記事「エージェンティック・クラウドモダナイゼーション: AWS MCP と Kiro によるモダナイゼーションの加速」を公開 開発者向けエージェント型 IDE「Kiro」と公式の AWS MCP サーバーを統合することで、レガシーシステムのクラウドモダナイゼーションにおける分析・計画・実装の 3 フェーズを自動化し、従来数週間かかっていた評価やアーキテクチャ設計を数日に短縮するアプローチが紹介されています。Kiro が既存コードベースを分析してアーキテクチャ図やドキュメントを自動生成し、AWS Well-Architected Framework に沿ったターゲットアーキテクチャの設計、リアルタイムのコスト見積もり、AWS CloudFormation や AWS CDK 等の Infrastructure as Code の生成まで一貫して行えます。生成 AI を活用したモダナイゼーションに取り組むユーザーにとって、AWS ドキュメント・料金・CDK などの各種 MCP サーバーを組み合わせた具体的なセットアップ方法と実装パターンを学ぶことができます。 ブログ記事「AI で強化された脅威アクターによる FortiGate デバイスへの大規模な不正アクセス」を公開 Amazon Threat Intelligence が、商用生成 AI サービスを活用した脅威アクターが 55 か国以上・600 台超の FortiGate デバイスを侵害したキャンペーンを観測・分析した調査結果が共有されています。技術力の低い脅威アクターでも、AI を活用して攻撃計画の策定やツール開発、認証情報の抽出を大規模に行えるようになった一方、侵害の主因はインターネットに公開された管理インターフェイスと脆弱な認証情報という基本的なセキュリティの欠陥であり、堅実なセキュリティの基本が依然として有効な防御策であることが示されています。AWS を利用するユーザーに対しては、Amazon GuardDuty や Amazon Inspector、AWS Security Hub を活用した脅威検出やセキュリティポスチャの継続的な可視化など、具体的な推奨事項が紹介されています。 サービスアップデート Amazon Bedrock の強化学習ファインチューニングが OpenAI 互換 API でオープンウェイトモデルをサポート Amazon Bedrock の強化学習ファインチューニング(RFT)が、qwen.qwen3-32b や openai.gpt-oss-20b などのオープンウェイトモデルに対応し、OpenAI 互換のファインチューニング API が利用可能になりました。大規模なラベル付きデータセットや深い機械学習の専門知識がなくても、少量のプロンプトセットとルールベースの評価関数や AI ベースのジャッジを使ってモデルをカスタマイズでき、ファインチューニング完了後は追加のデプロイ手順なしに Responses API や Chat Completions API でそのまま推論に利用できます。生成 AI を活用するユーザーにとって、小型で高速かつコスト効率の高いモデルを自社の業務要件に合わせて最適化し、フルマネージドかつセキュアな環境で運用できる選択肢が広がるアップデートです。 Claude Sonnet 4.6 が Amazon Bedrock で利用可能に Amazon Bedrock で Anthropic の Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.5 からの直接アップグレードとして、Opus 4.6 に匹敵する知能を低コストで提供し、コーディング、エージェンティックワークフロー、ブラウザベースの自動化(コンピュータ使用)において高いパフォーマンスを発揮します。生成 AI を活用するユーザーにとって、マルチモデルパイプラインでのリードエージェント・サブエージェント両方の役割を担えるほか、スプレッドシート作成やコンプライアンスレビューなどのエンタープライズ用途にも活用でき、Sonnet 4.5 からの移行も軽微なプロンプト調整のみで対応できます。 Kiro が AWS GovCloud (US) リージョンで利用可能に 開発者向けエージェント型 IDE「Kiro」が、AWS GovCloud (US-East) および AWS GovCloud (US-West) リージョンで利用可能になりました。高いコンプライアンス要件を持つワークロードに対して、スペック駆動開発やドキュメント・ユニットテストの自動生成、ネイティブ MCP サポートによるデータベースや API との連携など、エージェンティック AI 開発の機能が提供されます。AWS IAM Identity Center によるエンタープライズ認証に対応しており、政府機関や規制産業で生成 AI を活用した開発に取り組むユーザーにとって、ミッションクリティカルな開発ワークフローに Kiro を導入できるようになるアップデートです。 今週は以上です。それでは、また来週お会いしましょう! 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。
アバター
本記事は 2026 年 2 月 17 日 に公開された「 Use default encryption at rest for new Amazon Aurora clusters 」を翻訳したものです。 データセキュリティはあらゆる規模の組織にとって最優先事項であり、保存データの暗号化は組織のセキュリティ戦略の重要な要素です。保存データの暗号化はストレージレベルでデータを不正アクセスから保護し、誰かが物理的にストレージメディアにアクセスしたとしても、適切な暗号化キーがなければ機密情報を読み取れないようにします。これにより、メディアの盗難や物理ストレージデバイスの不適切な廃棄によるリスクも軽減できます。 GDPR, HIPAA, PCI DSS, SOC 2 などの規制フレームワークでは、機密データの暗号化が求められています。デフォルトの暗号化によりコンプライアンスが簡素化され、コンプライアンス違反によるペナルティのリスクも低減します。 Amazon Aurora の保管時の暗号化により、すべての新しい Aurora クラスターは追加の操作なしにこれらの規制要件を満たせます。 本記事では、Amazon Aurora が、AWS 所有キーを使用してすべての新規データベースクラスターに対しデフォルトで保管時の暗号化を提供するようになったことを学びます。StorageEncryptionType フィールドによる暗号化ステータスの確認方法、新規および既存クラスターへの影響、暗号化されていないデータベースの移行オプションについても解説します。 Amazon Aurora における保管時暗号化 以前は、保管時の暗号化は Aurora クラスター作成時に明示的に選択できるオプション機能でした。create API ではデフォルトで暗号化が無効になっており、 --storage-encrypted パラメータを指定せずに、または --no-storage-encrypted パラメータを指定してクラスターを作成すると、データベースは暗号化されていない状態でした。 今後、すべての新しい Aurora クラスターは AWS 所有キーを使用してデフォルトで暗号化が有効になり、すべての新しいデータベースの顧客データは物理メディア上で常に暗号化されます。暗号化はアプリケーションに対して透過的で、パフォーマンスへの影響はありません。AWS 所有キーによる暗号化 (またはデフォルトの保管時の暗号化) には追加料金は発生しません。 Amazon Aurora での暗号化タイプ キーのタイプは以下のとおりです。 AWS 所有キー (SSE-RDS) – AWS が完全に管理する暗号化キーで、ユーザーは表示や管理ができません。Aurora でのデフォルト暗号化に自動的に使用されます。 AWS マネージドキー (AMK) – AWS が作成・管理するキーで、アカウントで表示できますがカスタマイズはできません。月額料金はかかりませんが、AWS KMS API の料金が適用されます。 カスタマーマネージドキー (CMK) – アカウント内に保存され、ユーザーが作成、所有、管理するキーです。 AWS KMS キーを完全に制御できます (AWS KMS の料金が適用されます)。 StorageEncryptionType 出力フィールド データが保管時に暗号化されているかどうかをより明確に把握できるようにするために、Amazon Aurora はすべての describe API で StorageEncryptionType という追加の出力フィールドを公開するようになりました。このフィールドで設定される値は以下です。 sse-rds (サーバーサイド暗号化): インスタンスやクラスターが AWS 所有キーで暗号化されていることを示します。 sse-kms (AWS マネージドキーまたはカスタマーマネージドキー): インスタンスやクラスターが AWS マネージドキーまたはカスタマーマネージドキーで暗号化されていることを示します。 none : インスタンスやクラスターがデフォルトでは暗号化が無効だった時期に作成され、暗号化されていないことを示します。 AWS 所有キーで新しいクラスターを作成すると、 StorageEncrypted フィールドは false と表示され、 StorageEncryptionType フィールドは sse-rds と表示されます。これは、データベースの暗号化を明示的に選択しなかったものの、AWS 所有キーでデータは保管時に暗号化されていることを示します。 この変更は Aurora クラスターにどのような影響を与えるか この変更による影響は以下です。 新しいクラスター : 設定不要で、AWS 所有キー (sse-rds) により自動的に暗号化されます。 既存のクラスター : 現在の暗号化状態が維持されます。既存のデータベースは自動的に変更されません。 既存の暗号化されていないクラスターの自動バックアップ、スナップショット、クローンは暗号化されないままです。 暗号化されていないクラスターをスナップショットから復元すると、AWS 所有キーで暗号化されます。AWS 所有キーを使用することで、AWS サービスはデータを透過的に暗号化し、キーの共有を気にすることなくクロスアカウントやクロスリージョンでのクラスター共有を容易に実現します。 コンプライアンスやキー管理の目的で KMS ベースの暗号化が必要な場合は、Aurora クラスター作成時にカスタマーマネージドキー (CMK) または AWS マネージドキーを明示的に指定できます。一般的に、リソースを保護する暗号化キーの監査や制御が必要でない限り、AWS 所有キーが適切な選択肢です。 ユースケースと例 Aurora クラスターの保管時暗号化の例とユースケースを紹介します。 ユースケース 1: 新しい Aurora クラスターの作成 シナリオ : --storage-encrypted パラメータを指定せずに、または明示的に --no-storage-encrypted を使用して、新しい Aurora PostgreSQL クラスターを作成します。 結果 : AWS 所有キーを用いたサーバーサイド暗号化 (SSE) がデフォルトで有効な状態でクラスターが作成されます。 --storage-encrypted パラメータを指定しない CLI の例 : aws rds create-db-cluster \ --db-cluster-identifier apgtest1 \ --engine aurora-postgresql \ --master-username postgres \ --master-user-password xxxxxxx 出力 : { "DBCluster": { "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } 明示的に --no-storage-encrypted パラメータを指定した CLI の例 : aws rds create-db-cluster \ --db-cluster-identifier apgtest1 \ --engine aurora-postgresql \ --master-username postgres \ --master-user-password xxxxxxx \ --no-storage-encrypted 出力 : { "DBCluster": { "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } ユースケース 2: スナップショットからの復元 シナリオ : KMS キーを指定せずに、暗号化されていないクラスターのスナップショットを復元して Aurora クラスターを作成します。 結果 : 復元されたクラスターは、AWS 所有キーを使用したサーバーサイド暗号化 (SSE) が有効な状態で作成されます。 CLI の例 : aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier restored-cluster \ --snapshot-identifier unencrypted-cluster-snapshot \ --engine aurora-postgresql 出力 : { "DBCluster": { "DBClusterIdentifier": "restored-cluster", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } ユースケース 3: クラスターの確認 シナリオ : ユースケース 1 またはユースケース 2 で作成した Aurora クラスターの暗号化ステータスとタイプを確認します。 結果 : 出力に暗号化ステータスが反映されます。ユースケース 1 およびユースケース 2 ではクラスター作成時に --storage-encrypted オプションを指定しなかったため、StorageEncrypted は false と表示されます。 StorageEncryptionType は sse-rds と表示され、データが AWS 所有キーで暗号化されていることが確認できます。 CLI の例 : aws rds describe-db-clusters --db-cluster-identifier apgtest1 出力 : { "DBClusters": [ { "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } ] } ユースケース 4: スナップショットの作成 シナリオ A : SSE で暗号化された Aurora クラスターからスナップショットを作成します。 結果 : ソースクラスターと同じ暗号化状態 (SSE) でスナップショットが作成されます。 CLI の例 : aws rds create-db-cluster-snapshot \ --db-snapshot-identifier apgtest1-snapshot \ --db-instance-identifier apgtest1 SSE 暗号化スナップショットの出力 : { "DBClusterSnapshot": { "DBClusterSnapshotIdentifier": "apgtest1-snapshot", "DBClusterIdentifier": "apgtest1", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "sse-rds" } } シナリオ B : 暗号化されていない Aurora クラスターからスナップショットを作成します。 暗号化されていないスナップショットの出力 (既存のインスタンス): { "DBClusterSnapshot": { "DBClusterSnapshotIdentifier": "old-cluster-snapshot", "DBClusterIdentifier": "old-unencrypted-cluster", "Engine": "aurora-postgresql", "StorageEncrypted": false, "StorageEncryptionType": "none" } } AWS コンソールの変更 AWS マネジメントコンソールにも新しいデフォルト暗号化の動作が反映され、より詳細な Aurora クラスターの暗号化ステータスが表示されます。 SSE 暗号化を使用しているインスタンスの場合、コンソールの 暗号化 セクションに AWS 所有 KMS キー と表示されます。これにより、どのタイプの暗号化が使われているかが明確になります。KMS ベースの暗号化を使用しているインスタンスの場合は、 AWS マネージド KMS キー または カスタマーマネージド KMS キー と表示されます。以下のスクリーンショットは、デフォルトキー (AWS 所有キー) で暗号化されたクラスターの設定を示しています。 暗号化オプションを指定したインスタンスの作成 新しいインスタンスやクラスターを作成する際、Aurora コンソールに 3 つの暗号化キーオプションのドロップダウンメニューが表示されるようになりました。 AWS 所有 キー (SSE-RDS) AWS マネージドキー (SSE-KMS) カスタマーマネージドキー (SSE-KMS) 同様に、コンソールでスナップショットを復元する際にも同じ 3 つのオプションが表示され、ユースケースに適した暗号化タイプを選択できます。 暗号化されていない既存のクラスターをどのように SSE または KMS 暗号化に移行するか 暗号化されていない既存データベース (StorageEncryptionType が none) がある場合、SSE または KMS ベースの暗号化を使用するように移行できます。 オプション 1: SSE (AWS 所有キー) を使用してクラスターを暗号化する 暗号化されていないデータベースの スナップショット を作成します 暗号化されていないスナップショットから 復元 して新しいクラスターを作成します アプリケーションの接続先を新しいクラスターのエンドポイントに更新します クラスターがデフォルト (AWS 所有) キーで暗号化されていることを確認します 元の暗号化されていないクラスターを削除します # Create cluster snapshot aws rds create-db-cluster-snapshot \ --db-cluster-identifier original-cluster \ --db-cluster-snapshot-identifier original-cluster-snapshot # Restore from unencrypted snapshot aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier new-encrypted-cluster \ --snapshot-identifier original-cluster-snapshot # Verify your cluster is encrypted with default (AWS owned) keys aws rds describe-db-clusters \ --db-cluster-identifier new-encrypted-cluster \ --query "DBClusters[0].{StorageEncrypted:StorageEncrypted,KmsKeyId:KmsKeyId, StorageEncryptionType:StorageEncryptionType}" \ --output table オプション 2: KMS ベースの暗号化 (CMK または AWS マネージドキー) に移行する オプション 1 と同じ手順で、スナップショット復元時に --kms-key-id を指定します。 # Restore with KMS encryption aws rds restore-db-cluster-from-snapshot \ --db-cluster-identifier new-encrypted-cluster \ --snapshot-identifier original-cluster-snapshot \ --kms-key-id arn:aws:kms:us-east-1:123456789012:key/your-kms-key-id まとめ 本記事では、すべての新規 Aurora クラスターで保管時の暗号化がデフォルトで有効になり、追加コストや設定作業無しでセキュリティ強化と簡素化されたコンプライアンスを実現できることを紹介しました。既存データベースの暗号化ステータスを確認し、暗号化されていないデータベースを移行してこの強化されたセキュリティ機能を活用することを推奨します。 著者について Pratibha Shivnani Pratibha は、Amazon Web Services (AWS) の Amazon Aurora チームで Senior Product Manager (テクニカル – 外部サービス) を務めています。彼女は顧客のデータベース体験の簡素化と、強力なデータソリューションを誰もが使いやすくスケーラブルにすることに情熱を注いでいます。 Sukhpreet Kaur Bedi Sukhpreet は、AWS の Senior PostgreSQL Specialist Solutions Architect として、Amazon RDS for PostgreSQL と Aurora PostgreSQL エンジンを担当しています。彼女は、高可用性でスケーラブル、セキュアなデータベースアーキテクチャの構築を支援しています。 翻訳は Technical Account Manager の石渡が担当しました。
アバター
新しいスキル測定 “Microcredentials” とは AWS 認定を取得したが、もっと自分のスキルをアピールしたい!全冠の次の目標が欲しい!そんな方に朗報です。 Microcredentials は実践的なスキルを証明する新しい手法として、2025 年 11 月より AWS Skill Builder のサブスクリプションコンテンツとして利用が可能になりました。 Microcredentials は用意されたパフォーマンスベースの Exam Labs* で実践的な課題を解決することで、特定分野におけるスキルの深さを証明します。現在 “Agentic AI” と “Serverless” の 2 つの領域が Microcredentials としてリリース済みです。受験に際して必要な AWS 認定などの前提条件はありません。 実際に直面するであろう現実的な課題のトラブルシューティングを行い、効果的な解決策を実装します。基準を満たして合格すれば AWS 認定と同様に Credly のデジタルバッジが付与されます。今後も技術的なニーズに合わせて Microcredentials を追加していく予定です。ぜひ AWS 認定と合わせて取得ください。 <Microcredentials 操作画面のイメージ> *Exam Labs とは Exam Labsは、AWS が管理する Labs インフラストラクチャ上に構築されています。事前に構成された AWS 環境で、リスクなく様々な AWS サービスやソリューションを試すことができます。利用者は自身の AWS Account を利用せずとも、Exam Labs で提供される AWS 環境を利用することができます。Exam Labs には試験や評価に特化した機能(自動採点、評価基準の設定など)があります。 – AWS 認定との違い – Microcredentials の概要(Agentic AI/Serverless) 受験には AWS Skill Builder のサブスクリプション登録が必要です(参考: サブスクリプションについて ) Microcredentials の受験にあたり、サブスクリプション登録以外の費用は必要ありません 事前の予約は不要 制限時間は 90 分(中断不可) Exam Labs で複数の課題を解決 合格すれば AWS 認定と同様にデジタルバッジが付与されます 不合格の場合、次回は25日経過後から受験が可能 – Microcredentials 受験の流れ ① AWS Skill Builder の トップページ から、マイクロクレデンシャルを選択 – ② 受験したいマイクロクレデンシャルを選択して受験 ※ 一番左の「AWS マイクロクレデンシャル – お試し版」は操作説明のための体験版です。 – デジタルバッジ AWS 認定と同様に Credly で取得可能 – 関連性の高い AWS 認定 Agentic AI AWS Certified Generative AI Developer – Professional – Serverless AWS Certified Developer – Associate まとめ Microcredentials は AWS 認定だけでは証明することが難しい、特定分野におけるスキルの深度を証明できます。ぜひ AWS 認定と合わせて取得いただき、AWS 認定 × Microcredentials の新しいスキル証明を体感ください。 – 著者 トレーニングサービス本部 T&C Certification BDM 両角貴寿(Moro)
アバター
本ブログは 2026 年 2 月 20 日に公開された AWS Blog “ AI-augmented threat actor accesses FortiGate devices at scale ” を翻訳したものです。 商用 AI サービスの普及により、技術力の低い脅威アクターでも大規模なサイバー攻撃を実行できるようになっています。Amazon Threat Intelligence はこの傾向を注視しており、最近の調査がその変化を裏付けています。Amazon Threat Intelligence は、ロシア語を話す金銭的動機を持つ脅威アクターが複数の商用生成 AI サービスを活用し、2026 年 1 月 11 日から 2 月 18 日にかけて 55 か国以上、600 台を超える FortiGate デバイスを侵害した事例を観測しました。FortiGate の脆弱性が悪用された形跡はありません。このキャンペーンが成功した要因は、外部に公開された管理ポートと、単一要素認証における脆弱な認証情報の悪用です。これらは基本的なセキュリティの欠陥であり、AI の支援によって技術力の低い脅威アクターでも大規模に悪用できるようになりました。このアクティビティの特徴は、限られた技術力にもかかわらず、脅威アクターが複数の商用生成 AI サービスを使い、作戦のあらゆるフェーズで既知の攻撃手法を実装・拡大した点にあります。なお、このキャンペーンに AWS インフラストラクチャが悪用された事実は確認されていません。Amazon Threat Intelligence は、セキュリティコミュニティ全体の防御に役立てるため、これらの調査結果を共有します。 この調査から、商用 AI サービスがサイバー攻撃の技術的な参入障壁を引き下げている実態が明らかになりました。このキャンペーンの脅威アクターと、国家の支援を受けた APT (Advanced Persistent Threat) グループとの関連は確認されていません。金銭的動機を持つ個人または小規模グループと考えられ、AI を活用することで、従来であればはるかに大規模で高度な技術力を持つチームを必要としたであろう作戦規模を実現しています。しかし、公開状態にあった攻撃データの分析に基づくと、この脅威アクターは複数の組織の Active Directory 環境を侵害し、認証情報データベース全体を抽出し、バックアップインフラストラクチャを標的にすることに成功しています。これはランサムウェア攻撃の前段階の活動と考えられます。注目すべき点として、この脅威アクターは強化された環境やより高度な防御対策に遭遇した場合、固執せずにより防御の弱いターゲットへ移行しています。このことから、この脅威アクターの強みは高度な技術スキルではなく、AI によって強化された効率性と規模にあることがわかります。 2026 年もこの傾向は続くと予想されます。技術力の高低を問わず、AI を活用した脅威アクティビティは増加し続けることを組織は想定しておく必要があります。最も効果的な対策は依然として堅実なセキュリティの基本であり、具体的には、境界デバイスのパッチ管理、認証情報の管理徹底、ネットワークセグメンテーション、そして侵害後の痕跡に対する堅牢な検出が挙げられます。 キャンペーンの概要 定常的な脅威インテリジェンス活動を通じて、Amazon Threat Intelligence はこのキャンペーンに関連する悪意のあるツールをホストしているインフラストラクチャを特定しました。脅威アクターは、AI が生成した攻撃計画、被害組織の構成情報、カスタムツールのソースコードといった作戦用ファイルも、同じ外部からアクセス可能なインフラストラクチャ上に配置していました。この運用上のセキュリティの不備により、脅威アクターの手法や作戦全体を通じた AI の活用方法を包括的に把握することができました。これは言わば AI を活用したサイバー攻撃の量産装置であり、技術力の低い実行者でも大規模に活動できる仕組みとなっています。 脅威アクターは世界各地に分散する FortiGate アプライアンスを侵害し、デバイスの完全な構成情報を抽出して、認証情報、ネットワークトポロジ情報、デバイス設定情報を入手しました。その後、窃取した認証情報を使って被害組織の内部ネットワークに侵入し、Active Directory の侵害、認証情報の収集、バックアップインフラストラクチャへのアクセス試行など、侵害後のアクティビティを実行しました。これらはランサムウェア攻撃の前段階の活動と一致しています。 初期アクセス: 認証情報の大量悪用 脅威アクターの初期アクセス手段は、インターネットに公開された FortiGate 管理インターフェイスに対する、認証情報を悪用した不正アクセスでした。脅威アクターが使用したツールの分析から、ポート 443、8443、10443、4443 上の管理インターフェイスに対する体系的なスキャンと、よく使い回される認証情報による認証試行が確認されました。 FortiGate の設定ファイルには以下のような情報が含まれるため、攻撃者にとって価値の高いターゲットです。 復元可能なパスワードを含む SSL-VPN ユーザー認証情報 管理者認証情報 完全なネットワークトポロジとルーティング情報 内部アーキテクチャを明らかにするファイアウォールポリシー IPsec VPN ピアの設定情報 脅威アクターは AI の支援を受けて Python スクリプトを開発し、窃取した設定情報の解析、復号、整理を行いました。 地理的分布 このキャンペーンの標的選定は、特定のセクターを狙ったものではなく、脆弱なアプライアンスに対する自動化された大量スキャンに基づく無差別的なものと分析しています。ただし、同一組織に属する複数の FortiGate デバイスがアクセスされるなど、組織単位での侵害を示唆するパターンも確認されています。Amazon Threat Intelligence は、連続する IP アドレスブロックや共通の非標準管理ポートの使用状況から、マネージドサービスプロバイダーのデプロイ環境や大規模な組織ネットワークと推定されるクラスターを観測しました。侵害されたデバイスは、南アジア、ラテンアメリカ、カリブ海地域、西アフリカ、北ヨーロッパ、東南アジアをはじめとする複数の地域に集中して分布していました。 カスタムツール: AI が生成した偵察フレームワーク 被害組織のネットワークへの VPN 接続を確立した後、脅威アクターは Go と Python の両方で記述された複数バージョンのカスタム偵察ツールをデプロイしています。ソースコードの分析から、AI を活用した開発の明確な痕跡が確認されました。具体的には、関数名をそのまま繰り返すだけの冗長なコメント、機能よりもフォーマットを重視した単純なアーキテクチャ、適切なデシリアライゼーションではなく文字列マッチングに頼った単純な JSON パース、空のドキュメントスタブを伴う言語組み込み関数の互換性ラッパーなどが挙げられます。これらのツールは脅威アクターが想定した特定の攻撃シナリオでは機能するものの、例外的な条件への耐性がなく、想定外の状況では正しく動作しません。これは、大幅な改良を加えずにそのまま使用された AI 生成コードに典型的な特徴です。 このツールは、VPN 接続後の偵察ワークフローを以下のように自動化します。 VPN ルーティングテーブルからのターゲットネットワークの取り込み ネットワークのサイズ別分類 オープンソースのポートスキャナー gogo を使用したサービスディスカバリの実行 SMB ホストとドメインコントローラーの自動識別 オープンソースの脆弱性スキャナー Nuclei を使用した、検出された HTTP サービスに対する脆弱性スキャンの統合と、優先順位付けされたターゲットリストの生成 侵害後の手法 被害組織のネットワーク内部に侵入した後、脅威アクターは広く知られたオープンソースの攻撃ツールを用いて、以下のような標準的な攻撃手法を実行しています。 ドメインの侵害: 脅威アクターの作戦文書では、オープンソースの侵害後ツールキットである Meterpreter と mimikatz モジュールを使用し、ドメインコントローラーに対して DCSync 攻撃を実行する計画が詳述されています。この手法により、脅威アクターは Active Directory から NTLM パスワードハッシュを抽出しました。確認された侵害事例では、脅威アクターはドメインの認証情報データベース全体を取得しています。少なくとも 1 件のケースでは、Domain Administrator アカウントに平文のパスワードが使用されており、そのパスワードはパスワードの使い回しにより FortiGate の設定情報から抽出されたか、あるいはそもそも脆弱なものでした。 ラテラルムーブメント: ドメインの侵害後、脅威アクターは追加のインフラストラクチャに対して Pass-the-Hash/Pass-the-Ticket 攻撃、標準的なポイズニングツールを使用した NTLM relay 攻撃、Windows ホスト上でのリモートコマンド実行などの手法でアクセスの拡大を試みています。 バックアップインフラストラクチャの標的化: 脅威アクターは特に Veeam Backup &amp; Replication サーバーを標的とし、PowerShell スクリプト、コンパイル済みの復号ツール、既知の Veeam の脆弱性を利用したエクスプロイトなど、認証情報を抽出するための複数のツールをデプロイしました。バックアップサーバーは、バックアップ操作に必要な高い権限を持つ認証情報を保存していることが多く、また、バックアップインフラストラクチャを侵害することでランサムウェアのデプロイ前にリカバリ機能を無力化できるため、攻撃者にとって高価値なターゲットです。 限定的なエクスプロイトの成功: 脅威アクターの作戦メモには、さまざまなターゲットに対する複数の CVE (CVE-2019-7192、CVE-2023-27532、CVE-2024-40711 など) への言及があります。しかし、この分析で得られた重要な知見は、脅威アクターが単純な自動化された攻撃パスを超える高度なエクスプロイトを試みた場合、おおむね失敗していたという点です。脅威アクター自身の作戦記録にも繰り返しの失敗が記録されています。標的のサービスにはすでにパッチが適用されていたり、必要なポートが閉鎖されていたり、脆弱性が対象の OS バージョンに該当しなかったりといったケースです。ある確認済みの被害組織に対する最終的な作戦評価では、主要なインフラストラクチャターゲットは「十分に保護されて」おり、「悪用可能な脆弱性ベクトルがない」と結論付けています。 AI による攻撃能力の増幅 Amazon Threat Intelligence の分析から、脅威アクターが作戦の全フェーズにわたり、少なくとも 2 つの商用 LLM (大規模言語モデル) プロバイダーを使い分けていたことが判明しました。 AI が生成した攻撃計画: 脅威アクターは AI を活用し、段階的なエクスプロイト手順、想定成功率、所要時間の見積もり、優先度付きタスクツリーを含む包括的な攻撃計画を生成していました。これらの計画には攻撃的 AI エージェントに関する学術研究への参照が含まれており、脅威アクターが AI を活用したペネトレーションテストの最新動向を追跡していることがうかがえます。AI は技術的に正確なコマンドシーケンスを生成できますが、脅威アクターは実環境の条件が計画と異なる場合への対応に苦慮しています。具体的には、カスタムエクスプロイトのコンパイル、失敗したエクスプロイトのデバッグ、標準的な手法が通用しなかった場合の柔軟な方向転換ができていません。 マルチモデルの作戦ワークフロー: Amazon Threat Intelligence は、脅威アクターが複数の AI サービスを相互補完的に使い分けていることを確認しました。一方は主にツール開発、攻撃計画の策定、作戦支援に使用されています。もう一方は、侵害済みネットワーク内でのピボットに追加の支援が必要な場合の補助的な攻撃プランナーとして使用されています。確認された事例の 1 つでは、脅威アクターが侵害中の被害組織の完全な内部トポロジ (IP アドレス、ホスト名、確認済みの認証情報、検出されたサービス) を LLM に送信し、既存のツールではアクセスできなかった追加システムの侵害手順を段階的に生成するよう要求していました。 大規模な AI 生成ツール: 偵察フレームワーク以外にも、脅威アクターのインフラストラクチャには、設定情報パーサー、認証情報抽出ツール、VPN 接続の自動化、大量スキャンのオーケストレーション、結果集約ダッシュボードなど、AI 生成の特徴を示すスクリプトが複数のプログラミング言語で多数格納されていました。これほどの量と多様性のカスタムツールは、通常であれば十分なリソースを擁する開発チームの存在を示唆します。しかし実際には、単独の脅威アクターまたはごく少数のグループが、AI の支援を受けてこのツールキット全体を作成していました。 脅威アクターの評価 包括的な分析に基づき、Amazon Threat Intelligence はこの脅威アクターについて以下のように評価しています。 動機: 広範かつ無差別な標的選定と技術力の低さから、金銭的動機と推定 言語: ロシア語の作戦文書が多数確認されていることから、ロシア語話者 技術レベル: 基本的な技術力は低~中程度だが、AI により大幅に強化されている。標準的な攻撃ツールの実行やルーチンタスクの自動化は可能だが、エクスプロイトのコンパイル、カスタム開発、実際のオペレーション中の応用的な問題解決には苦慮している AI 依存度: 全作戦フェーズにわたり広範に依存。ツール開発、攻撃計画、コマンド生成、作戦レポートに複数の商用 LLM プロバイダーを使用 作戦規模: 広範。数十か国にわたる侵害済みデバイスがあり、長期間の持続的な作戦活動の証拠あり 侵害後の深度: 浅い。強化された環境や非標準的なターゲットに対して繰り返し失敗しており、自動化されたアプローチが通用しないと固執せずに次のターゲットへ移行するパターン 運用上のセキュリティ: 不十分。詳細な作戦計画、認証情報、被害組織のデータがツールとともに暗号化されていない状態で保存されている Amazon の対応 Amazon Threat Intelligence は、脅威アクターに対する積極的な調査と阻止活動を通じて、お客様とインターネットエコシステム全体の保護に継続的に取り組んでいます。 このキャンペーンの発見後、Amazon Threat Intelligence は以下の対応を実施しました。 侵害の痕跡 (IOC) を含む実用的なインテリジェンスを関連パートナーと共有 業界パートナーと連携し、キャンペーンに対する可視性を高めるとともに協調的な防御活動を支援 これらの取り組みにより、Amazon は脅威アクターの作戦効果の低減に貢献するとともに、複数の国の組織がキャンペーンの被害を軽減するための対策を講じることを可能にしました。 組織の防御 このキャンペーンが成功した要因は、外部に公開された管理インターフェイス、脆弱な認証情報、単一要素認証の組み合わせです。これらはいずれも基本的なセキュリティの欠陥であり、AI の支援があれば技術力の低い脅威アクターでも大規模に悪用できるものです。堅実なセキュリティの基本は、AI を活用した脅威に対しても依然として有効な防御策です。以下の対策を確認し、実施することを推奨します。 1. FortiGate アプライアンスの監査 FortiGate アプライアンスを運用している組織は、直ちに以下の対策を講じてください。 管理インターフェイスがインターネットに公開されていないことを確認する。リモート管理が必要な場合は、既知の IP 範囲にアクセスを制限し、踏み台ホストまたは帯域外管理ネットワークを使用する 管理者アカウントや VPN ユーザーアカウントを含め、FortiGate アプライアンスのデフォルトおよびよく使われる認証情報をすべて変更する すべての SSL-VPN ユーザー認証情報をローテーションする (特に管理インターフェイスがインターネットからアクセス可能であった、またはアクセス可能だった可能性があるアプライアンス) すべての管理アクセスおよび VPN アクセスに多要素認証を実装する FortiGate の設定を点検し、未承認の管理者アカウントやポリシー変更がないか確認する VPN 接続ログを監査し、予期しない地理的場所からの接続がないか確認する 2. 認証情報の管理徹底 FortiGate の構成情報から認証情報が抽出されていることを踏まえ、以下の対策を実施してください。 FortiGate VPN の認証情報と Active Directory ドメインアカウント間でのパスワードの使い回しがないか監査する すべての VPN アクセスに多要素認証を実装する すべてのアカウント (特に Domain Administrator アカウント) で、一意で複雑なパスワードの使用を徹底する サービスアカウントの認証情報を確認してローテーションする (特にバックアップインフラストラクチャで使用されるもの) 3. 侵害後の検出 被害を受けた可能性のある組織は、以下の痕跡がないか確認してください。 予期しない DCSync 操作 (レプリケーション関連の GUID を伴う Event ID 4662) 正規の Windows サービスを模倣した名前の新しいスケジュールタスク VPN アドレスプールからの異常なリモート管理接続 ネットワークトラフィックにおける LLMNR/NBT-NS ポイズニングの痕跡 バックアップ認証情報ストアへの不正アクセス 正規のサービスアカウントに見せかけた名前の新しいアカウント 4. バックアップインフラストラクチャの強化 脅威アクターがバックアップインフラストラクチャを重点的に標的としていることから、以下の対策が重要です。 バックアップサーバーを一般的なネットワークアクセスから隔離する 認証情報抽出に悪用される既知の脆弱性に対して、バックアップソフトウェアにパッチを適用する バックアップサーバーでの未承認の PowerShell モジュールのロードを監視する 管理者アクセスがあっても変更できないイミュータブルなバックアップコピーを実装する AWS 固有の推奨事項 AWS を使用している組織は、以下の対策を実施してください。 Amazon GuardDuty を有効にして脅威検出を行う (異常な API コールや認証情報の使用パターンの監視を含む) Amazon Inspector を使用して、ソフトウェアの脆弱性と意図しないネットワークの露出を自動スキャンする AWS Security Hub を使用して、セキュリティポスチャの継続的な可視性を確保する AWS Systems Manager Patch Manager を使用して、ネットワークアプライアンスを実行する EC2 インスタンス全体のパッチコンプライアンスを維持する ネットワークデバイスの侵害が疑われる場合は、認証情報のリプレイの痕跡がないか IAM アクセスパターンを確認する 侵害の痕跡 (IOC) このキャンペーンは Impacket、gogo、Nuclei をはじめとする正規のオープンソースツールに依存しているため、従来の IOC ベースの検出だけでは十分な効果が得られません。これらのツールはペネトレーションテスターやセキュリティ専門家にも広く使用されているため、ツールが存在するだけでは侵害の痕跡とは判断できません。組織では、シグネチャベースのアプローチよりも振る舞いベースの検出 (異常な VPN 認証パターン、予期しない Active Directory レプリケーション、VPN アドレスプールからのラテラルムーブメント) を優先し、検出結果の前後の文脈を踏まえて調査することが重要です。 IOC 値 IOC タイプ 初回確認日 最終確認日 説明 212[.]11.64.250 IPv4 2026/1/11 2026/2/18 脅威アクターがスキャンおよびエクスプロイト作戦に使用したインフラストラクチャ 185[.]196.11.225 IPv4 2026/1/11 2026/2/18 脅威アクターが攻撃作戦に使用したインフラストラクチャ この記事についてご質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO であり、Amazon 全体のセキュリティエンジニアリングとオペレーションを統括しています。セキュリティを最も自然な選択肢とすることで Amazon のビジネスを支えることを使命としています。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO をはじめ、さまざまな役職を歴任した後、2023 年 9 月に現職に就任しました。 Amazon 入社前は、FBI (連邦捜査局) サイバー部門でコンピュータおよびネットワーク侵入の技術分析を統括していました。また、空軍特別調査局 (AFOSI) の特別捜査官も務め、現在のセキュリティ業界の基盤を築いたとされる複数のコンピュータ侵入調査を主導しました。 コンピュータサイエンスと刑事司法の学位を持ち、SRO GT America GT2 の現役レーシングカードライバーでもあります。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。
アバター
本記事は 2025 年 10 月 5 日 に公開された「 Integral Ad Science scales over 100 M documents with Amazon OpenSearch Service 」を翻訳したものです。 ソーシャルメディアプラットフォーム全体でコンテンツ量が急増し、リアルタイムの機械学習 (ML) モデルトレーニングが求められる中、 Integral Ad Science (IAS) にはソリューションが必要でした。コンテンツ分類器の継続的な開発を支え、手動アノテーションによる遅延を解消し、ピーク時の処理スループットを最大化できるソリューションです。 IAS はデジタルメディアの計測と最適化におけるグローバルリーダーであり、デジタルメディア品質の信頼性と透明性の基準を確立しています。データドリブンなテクノロジーでリアルタイムのインサイトと包括的なデータを提供し、広告が安全で適切な環境で実際のオーディエンスに届くようにしています。 本記事では、IAS が Amazon OpenSearch Service を活用し、スケーラブルな SaaS 型 ML プラットフォームを構築した事例を紹介します。プラットフォームは日次 1 億件以上のドキュメントを処理し、プロジェクト開始時と比較して複雑な検索オペレーションで 40〜55% のパフォーマンス向上を達成しました。 課題 従来、データサイエンスチームは手動および半自動のアノテーションワークフローに数日から数週間を費やしていました。目標は、パフォーマンスとコンプライアンスの要件を満たしつつ、データサイエンティストやエンジニアが組織全体でセルフサービスで利用できる統合 ML プラットフォームの構築でした。 主な要件は以下のとおりです。 高次元ベクトル埋め込みの類似検索処理 リアルタイムのインデキシングとクエリ 数百の ML 分類器の自動再トレーニング ベクトルデータベースの評価 Apache Spark と Databricks プラットフォーム上に構築したカスタムベンチマークフレームワークで、ベクトルデータベースソリューションを広範に評価しました。 チームは以下のパフォーマンス指標で複数のソリューションを評価しました。 毎秒の類似検索クエリ数 一括書き込みスループット 一括読み取りスループット Spark とのネイティブ統合 結果として、優れたパフォーマンス、コスト効率、Amazon Web Services (AWS) との統合、活発なコミュニティサポートを理由に OpenSearch Service が選定されました。 カスタムベクトルインデキシングを備えた従来型データベース、専用ベクトルデータベースサービス、オープンソースソリューションなど、他のアプローチも検討しました。それぞれ強みはあったものの、コスト効率とスループットの要件を満たしつつ、チームが求める ML 体験を提供するソリューションは OpenSearch 以外にありませんでした。 ソリューション概要 広範な評価の結果、IAS は Amazon OpenSearch Service と Amazon Managed Streaming for Apache Kafka ( Amazon MSK ) を戦略的基盤として採用しました。アーキテクチャはホットストレージとコールドストレージの両階層にわたり、リアルタイム処理と履歴分析の両方に対応します。ベクトルとメタデータは Amazon MSK を通じてストリーミングされ、信頼性の高いスケーラブルな取り込みを実現します。Spark ベースのコンシューマーがマイクロバッチを処理し、リアルタイムベクトル検索用の Amazon OpenSearch Service (ホットレイヤー) と長期分析用の Databricks 上の Delta テーブル (コールドレイヤー) に送信します。 以下がソリューションの全体像です。 図 1: ソリューションアーキテクチャ OpenSearch Service のベクトル検索機能と豊富なフィルタリング API により、データサイエンティスト、ナレッジワーカー、開発者がノートブック、カスタムアプリケーション、ワークベンチやポータルなどの GUI から利用できるようになりました。 ソリューションの最適化 OpenSearch Service クラスター構成は、目標パフォーマンスの達成に向けて複数の最適化フェーズを経ました。AWS チームの支援により、初期のパフォーマンスボトルネックと構成上の課題を克服しています。チームは AWS Graviton3 プロセッサ の r6g から r7g インスタンスへ移行し、OpenSearch Service のバージョンを 2.13 から 2.19 にアップグレードし、 Concurrent Segment Search 機能を有効化しました。 OpenSearch Service のインデックスマッピングは、高次元ベクトル埋め込みと効率的な k 近傍法 (k-NN) 検索 に対応するよう最適化しました。具体的には、 Hierarchical Navigable Small Worlds (HNSW) アルゴリズム と内積類似度を使用した 1,024 次元のベクトルフィールドを構成し、フィルタリング用のメタデータフィールドマッピングも設定しました。ベクトルフィールドでは構築と検索のパフォーマンスに最適化したパラメータ設定も行っています。IAS は OpenSearch Service の Scalar Quantization 機能でコスト削減も実現しました。 パフォーマンス最適化には、効率的な k-NN フィルタリング、シャード数とサイズの調整によるシャード最適化、 Java Virtual Machine (JVM) ヒープ設定の調整と Concurrent Segment Search の有効化によるメモリ管理が含まれます。通常の検索では 40〜55% のパフォーマンス改善を達成しました。複雑なフィルタ付きオペレーションでは最大 80% の改善が見られ、最も大きな改善では 20 分以上かかっていた複雑なフィルタ検索が 1 分未満に短縮されました。 今後、IAS は OpenSearch Service 3.0 への移行を検討しています。集約パフォーマンスの最大 20% 向上、高カーディナリティ集約のレイテンシー大幅削減、GPU アクセラレーション対応の可能性を含むベクトルデータベース機能の強化が期待されます。 インデキシングの最適化 データ取り込みパイプラインは、Amazon MSK をストリーミング基盤として活用し、高可用性のために 10 パーティション、レプリケーションファクター 3 で構成しています。パイプラインは複数のステージでデータを処理し、信頼性の高い高スループットなドキュメント処理を実現します。継続的に実行される Spark ジョブが Kafka トピックを消費し、スループットとレイテンシーを最適化します。マイクロバッチは OpenSearch Service と Delta テーブルの両方に同時書き込みされ、ストレージレイヤー間の整合性を維持します。 アーキテクチャ変更により、IAS はクラスターに過負荷をかけることなく大量のドキュメントストリームを OpenSearch Service に安全にインデキシングでき、インデキシングプロセスのスロットリング制御が向上しました。 OpenSearch Hadoop コネクタ の統合により、knn-vector フィールドの Spark 連携が可能になり、処理量が大幅に向上しました。ホットレイヤーとコールドレイヤーへの書き込みの並列化により、ベクトルドキュメントのインデキシングパフォーマンスは日次 6,000 万件から 1 億件以上に向上しました。 IAS は knn-vector フィールドの Spark 連携をサポートするプルリクエストを OpenSearch Hadoop コネクタに提出しました。このコントリビューションは OpenSearch のオープンソースコミュニティとの協業を示す好例であり、IAS 固有の技術要件を満たすソリューションの実現にもつながりました。OpenSearch Hadoop コネクタとの統合は、システムの安定性を維持しつつ目標処理量を達成するうえで不可欠でした。 メリット これらの工夫によって、IAS のデータサイエンティスト、エンジニア、ナレッジワーカーにスケーラブルな SaaS 型 ML 機能を提供するソリューションを実現しました。社内ユーザーは好みのツールで分類器のトレーニングとデプロイを行いながら、大規模環境で高いパフォーマンスを維持できます。Amazon OpenSearch Service をベクトル検索に活用するアプローチにより、インフラストラクチャの複雑さと手動プロセスが削減されます。 その他のメリットは以下のとおりです。 新しいデータの到着に基づく分類器の継続的な再トレーニング アノテーションサイクルを数日〜数週間からわずか数時間に短縮 スパイクのあるトラフィックパターンでも日次 1 億件以上のドキュメントを効率的に処理 異なるチームやビジネスユニット間のマルチテナンシー対応 高いインデックスチャーンでのデータ保持コンプライアンスの維持 データサイエンスチームが新しい ML モデルや実験をデプロイするまでの時間を短縮 アーキテクチャの柔軟性も重要なポイントです。IAS のベクトルデータベーススタックは柔軟な構成により、新しいユースケースに素早く対応できます。 AWS Cloud Development Kit (AWS CDK) を使い、チームごとの一貫したコスト配分を維持しつつ、ソリューションをチーム間で複製できます。 まとめ IAS は取り組みの当初、厳しいパフォーマンスとコスト要件を満たしつつベクトルデータベース機能を実現するスケーラブルなソリューションを求めていました。Amazon OpenSearch Service は、データサイエンスチームへの約束を果たすために必要な機能を提供しました。ベクトル検索の最適化と Amazon Managed Streaming for Apache Kafka の統合を含むアーキテクチャ改善により、コスト効率を維持しつつ大幅なパフォーマンス向上を達成しています。 IAS は複数のビジネスユニットへのプラットフォーム展開を続けており、SaaS 型 ML ソリューションのスケールに合わせてより多くの分類器をサポートする計画です。パイプラインにはさらに多くのユースケースが追加される見込みです。 ビジネスの加速を支援する方法については、 AWS の担当者 にお問い合わせください。 関連情報 Amazon OpenSearch Service vector database capabilities revisited Amazon OpenSearch Service Resources Amazon OpenSearch Service Documentation 著者について Brian Maguire Brian Maguire は、Amazon Web Services の Principal Solutions Architect です。クラウド上でお客様のアイデア実現を支援しています。テクノロジスト、ライター、教師、そして学ぶことを愛する学生でもあります。書籍「Scalable Data Streaming with Amazon Kinesis」の共著者です。 Daniel Cintron Daniel Cintron は、IT 分野で 16 年以上の経験を持つ Sr. Technical Account Manager です。アドテック業界のお客様が AWS で目標を達成できるよう支援しています。仕事以外では、家族との時間や新しいテクノロジーの探求を楽しんでいます。 Dmitry Goldenberg Dmitry Goldenberg は、Integral Ad Science の Staff Engineer です。ベクトルデータベースの統合や大規模分類器トレーニングフレームワークの構築プロジェクトをリードしています。ソフトウェア開発とデータエンジニアリングで 30 年の経験を持ち、AI/ML、NLP、情報検索技術を専門としています。IAS では Databricks、Amazon MSK/Kafka、Spark、AWS OpenSearch Service を活用し、高度なメディア計測ソリューションを提供しています。 Rudra Ghosh Rudra Ghosh は、ダブリンを拠点とする Integral Ad Science の Machine Learning Operations Engineer です。AWS のクラウドネイティブコンポーネントを活用したスケーラブルな ML プラットフォームの構築を専門としています。データエンジニアリングと MLOps の両分野に精通し、本番対応の ML システムを実現しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。
アバター
本稿は、2026年1月5日に公開された AWS Blog “ Agentic Cloud Modernization: Accelerating Modernization with AWS MCPs and Kiro ” を翻訳したものです。 今日の急速に進化するテクノロジー環境において、組織はレガシーシステムのモダナイゼーションを進めながら、運用上の優秀性を維持し、コストを管理するという大きなプレッシャーに直面しています。従来のクラウドモダナイゼーションのアプローチでは、多くの場合、数週間にわたる手作業での調査、広範なドキュメント作成作業、そして多大な開発リソースが必要となり、市場投入までの時間を遅らせ、プロジェクトコストを増加させるボトルネックが生じていました。しかし、AWS の Kiro や Cline のような AI を活用した開発アシスタントが、公式の Anthropic Model Context Protocol (MCP) servers for AWS と統合されて登場したことで、これまで手動で時間のかかっていたプロセスを、自動化され、一貫性があり、スケーラブルな手法に変革するパラダイムシフトが起きています。このエージェンティック・アーキテクチャアプローチは、測定可能なビジネス成果を提供しながら、プロジェクトリスクを大幅に削減し、実装期間を数週間から数日に短縮します。 AI アシスタントの選択 組織は、AI を活用した開発パートナーとして Kiro または Cline のいずれかを活用できます。 Kiro は、AWS のネイティブな AI 搭載開発環境および IDE で、クラウドモダナイゼーションプロジェクトに対してインテリジェントな支援を提供します。AWS サービス、ドキュメント、リアルタイム AI アシスタンスへの統合アクセスを備えた包括的な開発体験を提供します。Kiro は、コンテキストに応じたコード分析、インフラストラクチャコードの生成、プロジェクトの可視化、コラボレーティブな開発ワークフローに優れています。開発環境に直接組み込まれた、AWS サービスとの深い統合、MCP サーバー管理、AI 搭載開発支援を備えた完全な IDE 体験を求めるチームに最適です。 Cline オプション: Kiro を使用していない組織の場合、AWS MCP との統合を完全にサポートする Cline を使用できます。Cline は VS Code 拡張機能として動作し、IDE 内で統合された開発体験を提供します。Cline は、VS Code の使用が必要なチームに最適です。 両方のアシスタントは、公式の AWS MCP servers と統合されており、すべての推奨事項と生成されたコードが現在の AWS ベストプラクティスに従い、特定のワークロード要件に最も適切なサービスを活用することを保証します。 従来のモダナイゼーションアプローチの課題 エンタープライズのモダナイゼーション施策は、通常、多大な時間とリソースを消費する典型的なパターンに従って進められます。評価フェーズでは、アーキテクトが既存システムを手動でカタログ化し、相互依存関係を文書化し、技術的負債を評価するため、数週間にわたることがよくあります。計画フェーズでは、ターゲットアーキテクチャの設計、コストの見積もり、モダナイゼーション戦略の策定のために、複数のチーム間で広範なコラボレーションが必要になります。実装フェーズでは、インフラストラクチャコードの作成、クラウドネイティブパターンへのアプリケーションの変更、運用手順の確立のために、多大な開発作業が必要になります。 こうした従来のアプローチは徹底的ではありますが、市場投入までの時間を遅らせ、プロジェクトコストを増加させるボトルネックを生み出します。手動プロセスは、ドキュメントの品質とアーキテクチャの決定に一貫性のなさをもたらします。最新のクラウドプラットフォームの複雑さから、チームがモダナイゼーション施策全体にわたってベストプラクティスを一貫して適用することは容易ではありません。組織は、手作業による評価と実装ワークフローに伴う避けられない遅延により、組織はプロジェクトの推進力を維持することが困難になることが少なくありません。 エージェンティック・アーキテクチャアプローチの紹介 エージェンティック・アーキテクチャという概念は、AI を活用してモダナイゼーションのライフサイクル全体を自動化・加速するものです。Kiro を公式の AWS MCP サーバーと統合することで、組織は既存システムと AWS のベストプラクティスの両方を理解するインテリジェントな開発環境を構築できます。この統合により、モダナイゼーションプロジェクトの評価、計画、実装フェーズにわたるエンドツーエンドの自動化フレームワークが実現します。 図 1 は、従来のモダナイゼーションの 3 つのフェーズ (評価、計画、実装) が、Kiro と AWS MCP の統合によってどのように変革されるかを示しています。このエージェントワークフローは、レガシーシステムの分析からターゲットアーキテクチャの設計、本番環境で使用可能なコード生成まで、一連のプロセスが自動化され、手作業の負担とプロジェクト期間を大幅に削減します。 Kiro は、既存のコードベースを分析し、アーキテクチャパターンを理解し、 AWS Well-Architected Framework の原則に沿った本番環境対応のソリューションを生成できる、インテリジェントな開発パートナーとして機能します。公式の AWS MCP サーバーとの統合により、すべての推奨事項と生成されたコードが現在の AWS ベストプラクティスに従い、特定のワークロード要件に最も適切なサービスを活用することが保証されます。 エージェントアプローチの3つの中核フェーズ 分析フェーズ – Kiro が既存システムを自動的に検証するフェーズです。コードベースを分析して現在のアーキテクチャパターンの包括的なドキュメントを生成し、システムの依存関係とデータフローを示す視覚的な図を作成し、技術的負債とモダナイゼーションの機会を特定し、アプリケーションとサービス全体のクラウド対応状況を評価します。 計画フェーズ – Kiro がターゲット AWS アーキテクチャをインテリジェントに設計します。具体的には、特定の要件に最適化されたソリューションを設計し、リアルタイムの AWS 価格を使用して詳細なコスト見積もりを生成し、段階的な実装戦略を含むモダナイゼーションロードマップを作成し、ワークロードの特性に基づいて適切な AWS サービスを推奨します。 実装フェーズ – 本番環境対応のアセットを自動生成します。Kiro は CloudFormation、CDK、または Terraform を使用した Infrastructure as Code を提供し、クラウドネイティブパターンに対応したアプリケーションコードの変更を作成し、モダナイズされたアーキテクチャを反映した最新のドキュメントを生成し、デプロイ自動化スクリプトと CI/CD パイプラインを生成します。 各フェーズは、特定の AWS MCP サーバーと Kiro の機能を活用して、従来は手作業で数週間かかっていたプロセスを、数日で本番環境対応の結果を提供する自動化された一貫性のあるワークフローに変革します。 図 1 – エージェントアーキテクチャワークフロー: AIを活用したクラウドモダナイゼーションプロセス 現状分析 エージェンティック・アーキテクチャモダナイゼーションの最初のフェーズは、既存システムの自動分析に焦点を当てます。Kiro はコードベースを調査し、アーキテクチャパターン、依存関係、潜在的なモダナイゼーションの機会を特定します。この分析により、通常であればシニアアーキテクトや開発者が数週間かけて手作業で行う必要がある詳細なドキュメントが生成されます。この自動分析アプローチにより、評価時間が数週間から数日に短縮され、すべてのシステムコンポーネントに対して一貫した評価基準が確保されます。 AIアシスタントは、システムの依存関係とデータフローを示す視覚的な図を作成することで、ステークホルダーが現在のアーキテクチャの複雑さを明確に理解できるようにします。技術的負債の評価を通じて、モダナイゼーションの取り組みが最も大きな効果を発揮する具体的な領域を特定します。クラウド対応性の評価では、各アプリケーションコンポーネントを調査して最適なモダナイゼーション戦略を決定し、プロジェクトのタイムラインに影響を与える前に潜在的な課題を特定します。生成されたドキュメントは、計画フェーズの確固たる基盤となり、モダナイゼーションプロセス全体を通じて貴重な参考資料として活用できます。 図 2 – Kiroで生成された現状アーキテクチャの分析とドキュメント 図 3 – Kiroで生成された現状アーキテクチャ図 計画 現状分析が完了すると、Kiro は組織固有の要件に最適化されたターゲット AWS アーキテクチャの設計に移行します。この AI アシスタントは、AWS サービスとアーキテクチャパターンの知識を活用して、パフォーマンス、コスト、運用の複雑さのバランスを取ったソリューションを推奨します。AWS MCP サーバーとの統合により、推奨事項は常に最新のサービス機能と料金モデルを反映します。 コスト見積もりは、さまざまなアーキテクチャオプションのリアルタイム分析を提供する自動化されたプロセスになります。Kiro は、現在のインフラストラクチャ費用と予測される AWS コストを比較するコストモデルを生成でき、モダナイゼーションの優先順位と予算配分について情報に基づいた意思決定を可能にします。モダナイゼーションロードマップは、ビジネスの中断を最小限に抑えながら、モダナイゼーションプロセス全体を通じて段階的な価値を提供する段階的な実装戦略の概要を示します。 計画フェーズには、ワークロードの特性に基づいた適切な AWS サービスの自動選択も含まれます。プロンプトを通じて非機能要件に関する情報を提供することで、エージェントは技術目標とビジネス目標の両方に沿ったアーキテクチャを設計できます。 図 4 – Kiro で生成されたターゲットアーキテクチャドキュメント 図 5 – Kiro で生成されたターゲットアーキテクチャ図 図 6 – Kiro で生成されたターゲットアーキテクチャのコストモデル 実装 実装フェーズでは、エージェンティック・アーキテクチャアプローチの真の力が発揮されます。Kiro は、組織の好みや既存のツール標準に基づいて、 AWS CloudFormation 、 AWS Cloud Development Kit (CDK)、または Terraform を使用して Infrastructure as Code を生成します。これらの生成されたテンプレートには、セキュリティ、モニタリング、運用上の優秀性に関する AWS のベストプラクティスが組み込まれており、評価フェーズと計画フェーズで特定された具体的な要件が反映されています。 コンテナ化、マイクロサービス分割、サーバーレス採用などの一般的なモダナイゼーション要件に対応するため、クラウドネイティブパターン向けのアプリケーションコード変更が自動生成されます。AI アシスタントは、レガシーコードパターンと最新のクラウドネイティブアプローチの両方を理解しており、ビジネスロジックを維持しながらクラウド最適化されたアーキテクチャを採用する変換コードを生成できます。 図 7 – Kiro で生成されたターゲットアーキテクチャのコードと CDK 公式 AWS MCP サーバーの活用 公式の AWS MCP サーバー との統合により、Kiro は AWS の機能と最新のベストプラクティスへの包括的なアクセスが可能になります。AWS MCP サーバーは、最新のドキュメントへのアクセスと AWS サービスに関する深い文脈的知識を持つため、基盤モデル以上のメリットを提供します。この統合により、より正確で有用な応答が可能になり、生成されるすべてのコードと推奨事項が現在の AWS サービスの機能と制限を反映します。 まず始めるべき MCP これらの MCP は、現在の状態のアーキテクチャ (図を含む) を文書化し、図、コスト、コード、デプロイメントを含むターゲットアーキテクチャを設計するのに役立ちます。 分析フェーズ core-mcp-server – ロールベースの環境変数に基づく動的プロキシサーバー戦略により、AWS MCP サーバーを使用するための出発点を提供します。 code-doc-gen-mcp-server – リポジトリ構造を分析し、コードプロジェクトの詳細なドキュメントを生成します。 aws-diagram-mcp-server – Python diagrams パッケージ DSL を使用して図を作成します。このサーバーを使用すると、Python コードを使用して AWS 図、シーケンス図、フロー図、クラス図を生成できます。 計画フェーズ aws-documentation-mcp-server – AWS ドキュメントへのアクセス、コンテンツの検索、推奨事項の取得を行うツールを提供します。 aws-knowledge-mcp-server – 最新のドキュメント、コードサンプル、その他の公式 AWS コンテンツを提供します。 aws-pricing-mcp-server – リアルタイムの AWS 料金情報へのアクセスとコスト分析機能を提供します。 生成フェーズ cdk-mcp-server – Cloud Development Kit (CDK) のベストプラクティス、Infrastructure as Code パターン、CDK Nag によるセキュリティコンプライアンス terraform-mcp-server – AWS 上の Terraform のベストプラクティス、Infrastructure as Code パターン、Checkov によるセキュリティコンプライアンス Infrastructure as Code の生成は、CDK、Terraform、CloudFormation ワークフロー専用の MCP サーバーから恩恵を受けます。これらの特化したサーバーは、セキュリティスキャンとコンプライアンスチェックを提供し、生成されたインフラストラクチャコードがエンタープライズセキュリティ基準を満たすことを保証します。この統合により、AWS サービスの制限やリージョンの可用性に対するインフラストラクチャ設計のリアルタイム検証も可能になります。 コンテナとサーバーレスのモダナイゼーションシナリオでは、EKS、ECS、AWS Serverless Application Model ワークフロー用の専用 MCP サーバーを活用します。これらの統合により、コンテナ化戦略とサーバーレス採用パターンに対する広範なサポートが提供され、生成されたソリューションが各デプロイモデルの AWS ベストプラクティスに従うことが保証されます。 AWS MCP を使用した AI アシスタントのセットアップ AWS MCP を使用した Kiro の設定 Kiro 内で MCP を設定する詳細については、 Introducing remote MCP servers をお読みください。 Kiro は、IDE 内に組み込まれた MCP 設定システムを通じて AWS MCP と統合されます。Kiro を AWS MCP サーバーで設定するには、次の手順を実行します。 AWS 認証情報の設定 : IDE の設定または環境変数を通じて、開発環境で AWS 認証情報が適切に設定されていることを確認してください。 MCP サーバーの追加 : Kiro IDE では、複数の方法で MCP サーバーを設定できます: ワークスペース設定 : ワークスペース内の .kiro/settings/mcp.json を作成または編集します ユーザー設定 : ~/.kiro/settings/mcp.json のグローバル設定を使用します IDE インターフェース : Kiro IDE 設定の MCP 設定パネルを使用します 図 8 – Kiro における MCP 設定パネルと JSON ワークスペース設定の例: { "mcpServers": { "aws-core": { "command": "uvx", "args": ["awslabs.core-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR" }, "disabled": false }, "aws-docs": { "command": "uvx", "args": ["awslabs.aws-documentation-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_DOCUMENTATION_PARTITION": "aws" }, "autoApprove": ["search_documentation"], "disabled": false }, "awslabs.aws-pricing-mcp-server": { "command": "uvx", "args": ["awslabs.aws-pricing-mcp-server@latest"], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_PROFILE": "default", "AWS_REGION": "us-east-1" } } } } ** aws-pricing-mcp-server については、AWS_PROFILE 変数を定義する必要があることにご注意ください ** MCP ツールへのアクセス : Kiro IDE 内で、以下のことができます。 統合された MCP パネルで利用可能な MCP サーバーを表示 AI チャットインターフェースを通じて MCP ツールを直接使用 MCP サーバーのステータスを確認し、必要に応じてサーバーに再接続 特定のツールを自動承認してワークフローを効率化 統合の検証 : チャットインターフェースで Kiro に質問します。 Kiro IDE は、AWS に焦点を当てたモダナイゼーションにおいて、いくつかの利点を提供します。 コンテキストに応じた AI アシスタンスを備えた統合開発環境 ビジュアルな MCP サーバー管理と監視 コード編集と AWS サービスとのやり取りのシームレスな統合 リアルタイム検証を備えた Infrastructure as Code の組み込みサポート 開発、ドキュメント、デプロイを組み合わせた包括的な IDE ワークフロー AWS MCP を使用した Cline の設定 VS Code の Cline に MCP サーバーを追加するには、cline_mcp_settings.json ファイルを使用します。cline_mcp_settings.json ファイルは以下の場所にあります: macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/ Windows: %APPDATA%/Code/User/globalStorage/saoudrizwan.claude-dev/settings/ 上記と同じワークスペース設定 json が Cline でも動作します。 エージェンティック・アーキテクチャモダナイゼーションのメリット エージェンティック・アーキテクチャアプローチの採用は、モダナイゼーションプロジェクトの複数の側面において具体的な改善をもたらします。これらの手法を実装する組織は、クラウド変革施策全体を通じて、効率性の向上、リスクの低減、成果の改善を経験します。以下のセクションでは、AWS MCP サーバーと統合された AI を活用した開発アシスタントを利用する際に、組織が期待できる具体的なメリットと測定可能な影響について詳しく説明します。 測定可能なビジネス価値 エージェンティック・アーキテクチャアプローチを実装している組織は、モダナイゼーションプロジェクトの成果が改善されたと報告しています。アセスメントのタイムラインは数週間から数日に短縮され、より迅速な意思決定とプロジェクトの開始が可能になります。生成されたドキュメントの品質と一貫性は、人間による監視を最小限に抑えながら、手作業によるアプローチを上回ります。 コスト最適化は、実装後の検討事項ではなく、設計プロセスの不可欠な部分となります。アーキテクチャ設計中のリアルタイムコストモデリングにより、チームは実装を開始する前にパフォーマンスとコストの間で情報に基づいたトレードオフを行うことができます。自動化されたライトサイジング推奨事項は、組織がソリューションの過剰構築を回避し、インフラストラクチャの過剰プロビジョニングを防ぐのに役立ちます。 AWS のベストプラクティスの一貫した適用と自動化されたセキュリティコンプライアンスチェックにより、リスク軽減が向上します。プロセス全体を通じて生成される詳細なドキュメントは、監査要件をサポートし、継続的なメンテナンスと最適化の取り組みのための貴重な参考資料を提供します。 品質保証と標準化 エージェンティック・アーキテクチャアプローチは、AWS Well-Architected Framework に対する自動検証を通じて、強化された品質保証を提供します。生成されたすべてのアーキテクチャは、フレームワークの 6 つの柱すべてにわたって体系的な評価を受け、モダナイズされたソリューションが運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化に関するエンタープライズ標準を満たすことを保証します。 コード品質分析には、インフラストラクチャとアプリケーションコンポーネントの両方に包括的なカバレッジを提供する自動テスト生成が含まれます。この自動テストアプローチにより、モダナイズされたソリューションが信頼性を維持しながら、クラウドネイティブ運用に不可欠な継続的デリバリープラクティスをサポートすることが保証されます。 すべてのソリューションが同じ AI アシスタントと AWS MCP サーバー統合を活用することで、モダナイゼーションプロジェクト全体での標準化が自動的に実現されます。この一貫性により、運用の複雑さが軽減され、チームは異なるプロジェクト間で多様なアーキテクチャアプローチを管理するのではなく、標準化されたパターンに関する専門知識を開発できるようになります。 実装戦略とタイムライン エージェンティック・アーキテクチャアプローチの導入を成功させるには、自動化のメリットと組織の変更管理ニーズのバランスを取る、慎重な実装計画が必要です。初期セットアップでは通常、適切な AWS MCP サーバーで Kiro を構成し、必要な AWS 認証情報とアクセス許可を確立するのに数時間かかります。 パイロット評価フェーズは、AI が生成した推奨事項を組織の要件や好みに照らして検証する貴重な学習機会を提供します。これらのパイロットプロジェクトは通常 2 ~ 3 週間にわたり、組織が直面するモダナイゼーションの課題の全範囲を示す代表的なアプリケーションに焦点を当てます。 モダナイゼーション設計フェーズでは、パイロット評価から得られた教訓を活用して、包括的なターゲットアーキテクチャと実装ロードマップを作成します。これらのフェーズには通常 4 ~ 5 週間を要し、生成された推奨事項がビジネス目標と技術的制約に沿っていることを確認するためのステークホルダーレビュープロセスが含まれます。 実装フェーズは、アプリケーションの複雑さと組織の準備状況によって異なりますが、従来の手作業によるアプローチと比較して大幅に加速されます。Kiro が生成する本番環境対応のアセットにより、チームはインフラストラクチャコードとデプロイ自動化をゼロから作成するのではなく、検証とカスタマイズに集中できます。 今後の検討事項と継続的な進化 エージェンティック・アーキテクチャアプローチは、AI の機能が進化し、 AWS サービスが拡大するにつれて継続的に改善される進化する手法です。このアプローチを採用する組織は、長期的なモダナイゼーションの成功を支える標準化されたプロセスを確立しながら、AI を活用した開発支援の継続的な改善から恩恵を受けることができます。 MCP サーバーが新しいサービス提供やベストプラクティスを反映したアップデートを受け取ることで、新しい AWS サービスや機能との統合が自動的に行われます。この継続的な進化により、モダナイゼーションの取り組みは、確立された組織のパターンと好みとの一貫性を維持しながら、AWS のイノベーションに対応し続けます。 エージェンティック・アーキテクチャのモダナイゼーションを通じて確立された詳細なドキュメントと標準化されたアプローチは、将来の最適化と拡張の取り組みに向けた強固な基盤を提供します。組織はこれらの資産を活用して、エンタープライズの成功に不可欠な品質と一貫性を維持しながら、継続的なクラウド導入の取り組みをサポートできます。 まとめ AI を活用した開発アシスタントと公式 AWS ツールの統合は、組織がクラウドモダナイゼーションの課題にアプローチする方法における根本的な変革を表しています。評価、計画、実装の各フェーズを自動化することで、エージェンティック・アーキテクチャアプローチは、プロジェクトのタイムラインとリソース要件を削減しながら、価値ある成果を提供します。 これらの手法を採用する組織は、エンタープライズの成功に不可欠な品質と一貫性を維持しながら、クラウド導入の取り組みを加速できます。インテリジェントな自動化と AWS のベストプラクティスを組み合わせることで、レガシーシステムをビジネスの成長とイノベーションをサポートする最新のクラウドネイティブアーキテクチャに変革するための強力なフレームワークが生まれます。 アーキテクチャモダナイゼーションの未来は、人工知能と実績のあるクラウドプラットフォームおよびプラクティスの思慮深い統合にあります。今日これらの機能に投資する組織は、AI 機能が進化し成熟し続けるにつれて、時間とともに複利的に増大する競争優位性を確立するでしょう。 次のステップ 今日からエージェントアーキテクチャの取り組みを始めましょう。お好みの AI アシスタントに AWS MCP サーバーを設定してください。Kiro または Cline をダウンロードし、AWS 認証情報を設定し、IDE で MCP サーバーを設定して、代表的なレガシーアプリケーションで最初のモダナイゼーション評価を開始してください。初期セットアップにかかる時間はわずか数時間で、得られるインサイトはモダナイゼーションプロジェクトへのアプローチを大きく変えるでしょう。 Jeff Escott Jeff Escott は、AWS のプリンシパルアーキテクトで、30 年以上のテクノロジー経験を持っています。彼は、お客様がモダナイゼーション戦略を定義し、クラウドファーストのアプローチを採用することを支援し、人材、プロセス、テクノロジーにわたってお客様の変革を支援することに注力しています。さらに、Jeff は長年にわたり、アーキテクチャの実践を進歩させ、将来のアーキテクトを育成することを提唱してきました。Jeff は、ウースター工科大学で保険数理学の学士号を取得しており、米国コネチカット州を拠点としています。 翻訳はソリューションアーキテクトの平良允俊が担当しました。
アバター
本記事は 2026 年 2 月 13 日に公開された Ranjith Ramakrishnan による “ Enterprise identity and usage metrics ” を翻訳したものです。 Kiro が 11 月 17 日に一般提供されて以来、Rackspace、Smugmug、Netsmart などの多くの企業が、エンジニアリングチーム全体でスペック駆動開発アプローチを採用し、AI 開発においてより構造化されたアプローチをもたらし、場合によっては最大 90% の効率向上を実現しています。 本日、外部 ID プロバイダーのサポートとユーザーレベルのアクティビティメトリクスにより、組織が Kiro をさらに簡単に使用できるようになりました。企業には、ID 管理の仕組みやコンプライアンス要件があり、またチームは「何がどのように使われているのか」を可視化して把握する必要があります。この分野は急速に変化しているため、企業は新しいユーザーを迅速にオンボーディングし、AI がエンジニアをどこでどのように支援しているかについての洞察を得たいと考えています。このデータがあれば、ツールとプロセスへの投資を迅速に拡大し、一貫して高い品質基準を保ちながら、はるかに速くリリースできます。 外部 ID プロバイダー: Okta と Microsoft Entra ID 組織が Okta または Microsoft Entra ID を通じて ID を管理している場合、Kiro はそのインフラストラクチャに直接接続できるようになりました。これは、 IDE 、 CLI 、Web アプリなど、Kiro ポートフォリオ全体で機能します。開発者は既に持っている認証情報で認証するため、新しいログインを設定する必要はありません。 管理者が既存の ID プロバイダーをオンボーディングすると、SSO ポリシー、条件付きアクセスルール、MFA 適用が設定どおりに Kiro で使用されます。Okta と Microsoft Entra から始めたのは、多くのお客様からのリクエストに基づいています。追加の OIDC プロバイダーのサポートに取り組んでいます。まだサポートされていないプロバイダーを使用している場合は、 お知らせください 。優先順位の決定に役立てさせていただきます。 これは、Kiro を人気のあるエンタープライズツールやシステム(ID プロバイダー、チケットシステムやバージョン管理システム、デプロイツールなど)に接続する最初のステップです。 ユーザーレベルのアクティビティメトリクス 組織の管理者は、チーム全体の利用状況を日次で集計したデータを提供するユーザーアクティビティレポートを有効にできるようになりました。レポートは、クライアントタイプ(IDE、CLI、IDE プラグイン)ごとにアクティビティを分類するため、開発者が実際に使用しているツールを可視化できます。これらの基本的なメトリクスは始まりに過ぎません。 生産性の測定と使用パターンの確立は繰り返し出てくるテーマであり、今日、私たちはより豊富な分析(トレンドビュー、チームレベルの集計、エクスポート可能なダッシュボード)だけでなく、エージェント型開発を効果的に活用することが、どのように生産性向上につながるのか、その洞察を得られるようにしていきます。企業が重視するソフトウェアデリバリー指標において、どのチームが最も顕著な向上を実現しているのか? そしてその成果を牽引する利用パターンとは何か? 2026年の展開にご期待ください。 エンタープライズ向けの次のステップ これら 2 つの機能は、企業が既に依存しているシステム内で Kiro を機能させるための、より広範な取り組みの一部です。既存のツールやサービスとのさらなる統合、および開発速度を安全に向上させるために必要なガードレールを提供する追加のガバナンス制御と機能に積極的に取り組んでいます。 組織での Kiro 導入を検討中の方、または既に利用中で特定のエンタープライズ機能の優先的な実装を希望される方は、 お知らせいただくか 、 GitHub で Issues を開いてください。 翻訳は Solutions Architect の吉村が担当いたしました。
アバター
はじめに 東芝テック株式会社は、流通・小売業界やさまざまなワークプレイスに向けたソリューションを開発、提供しています。POS システムにおいては国内外でトップシェアを誇るリーディングカンパニーであり、グローバルリテールプラットフォーム「ELERA」による小売業務全体のデジタル化を支援しています。ELERA は、「タッチポイント」「ソリューション」「データサービス」の 3 軸でビジネスを展開し、高い拡張性とリアルタイムな情報活用によって現場の課題解決を支援することで、店舗運営の効率化や意思決定の高度化につなげます。パートナーとの連携を通じてデータ活用を軸に、店舗運営と顧客体験に革新をもたらす『リテール共創基盤』として、次世代の消費体験を形にしていきます。 この度、東芝テック株式会社は AWS の技術支援のもと、AI エージェント を活用した店舗運営支援ソリューションを開発し、2026 年 3 月3日~6日まで、東京ビッグサイト(国際展示場)で開催される「リテールテックJAPAN 2026」にてデモンストレーションを行います。本ブログでは、この新しいソリューションを解説致します。 小売業界が直面する課題 現代の小売業界では、デジタル化の波とともに、店舗運営の複雑さが増しています。売り場責任者は日々、膨大な売上データ、在庫情報、顧客動向を把握しながら、収益性を最大化するための意思決定に迫られています。しかし、多くの店舗では、ベテラン担当者の経験と勘に頼った運営が続いており、データ活用の恩恵を十分に受けられていないのが現状です。 特に深刻な課題となっているのが、データ分析に熟練の知見が必要とされることです。多くのスーパーマーケットの店舗では、数十種類にも及ぶ帳票に加え、日次・月次の売上集計、商品別売上分析、時間帯別売上分析など重要な情報が蓄積されますが、これらを読み解いて適切な判断を下すには複数年にわたる現場経験が必要とされています。新人スタッフや若手の売り場責任者にとって、予算達成率の数字から、具体的にどのような対策を講じるべきかを判断することは容易ではありません。 さらに、小売業界全体に共通する課題として、多くの店舗システムではデータの更新頻度に制約があり、リアルタイムな状況変化への対応が困難な状況です。例えば、午前中に特定の商品の売れ行きに変化が生じても、その情報を即座に把握して適切なタイミングで値引きや陳列変更といった対策を打つことは困難です。さらに人手が限られる中で、他の商品情報も踏まえ、どの商品から優先的に対応すべきかを判断するのは困難です。 また、部門横断的な分析も大きな課題です。例えば青果部門の責任者が、関連商品である鍋スープの売上動向を把握して連動した販促を行いたくても、部門ごとに分かれた組織構造や、各部門に蓄積された専門知識の分断により、総合的な判断を行うことは困難です。異なるシステムに散在するデータの統合に加え、部門間でのナレッジ共有や協調的な意思決定プロセスの確立が技術的・組織的な課題となっています。 店舗運営支援ソリューションの価値 本ソリューションは、これらの課題を解決し、小売業界に革新的な価値をもたらします。AI エージェントが小売業者の POS データや別システムのデータベースに格納された在庫情報、カメラや温湿度計などの IoT センサーによって生成されるデータなどを継続的にモニターし、あらかじめ設定したシグナル(売れ足が平常時より鈍い等)を検知すると、取るべき施策(値引きの必要性やタイミングの判断等)を自動的に分析し、売り場責任者のスマートフォンに具体的な推奨アクションを即座に通知します。これにより、従来は気づかれなかった売上機会を把握し、タイムリーな対応が可能になります。 ポイントは、ベテラン担当者の豊富な経験と知見、店長の施策の方向性を、管理画面から自然言語でインプットするだけで、現場でノーコードで AI エージェントを開発できることです。これらのエージェントは、従来の AI チャットボットとは異なり、24時間365日バックグラウンドで働き続けることできるため、PC やスマートフォンで担当者が質問文を入力せずとも、重要なビジネスシグナルを見落とすことがありません。結果として、データに基づく具体的で実行可能な施策を、適切なタイミングで実行することで、省人化に寄与しながら売上向上や廃棄削減を目指すことができます。 アーキテクチャ POS data analysis agents は、バックグラウンドで定期的に実行され、あらかじめ設定されたベテラン担当者の業務知識から生成されたプロンプトに基づいて POS データを分析し、施策を提案します。また、提案した施策に対して、店舗担当者の追加の質問を受け付け、データに基づいてパーソナライズされた対話を行います。 活用されている AWS サービスと、AI エージェントの構造 本ソリューションは、AWS の生成 AI サービスと、サーバーレスアーキテクチャを組み合わせた構成により実現されています。AI エージェントとは、事前に設定された目標を達成する自律型 AI システムです。従来のソフトウェアと異なり、事前定義済みのワークフローを必要とせず、AI エージェント自身がタスクを立案し、自動で実行することができます。AI エージェントの最もシンプルな定義は、 1) モデル 、 2) ツール 、 3) プロンプト 、の 3 つの要素の組み合わせです。 本ソリューションでは、下記の AWS サービスを活用しています。 Amazon Bedrock は、AI エージェントの「モデル」に利用しています。Claude 4.5 Sonnet の高度な自然言語処理能力により、ベテラン担当者から自然言語で与えられた業務知識を理解し、エージェントへ与える「プロンプト」に変換します。また、Amazon Bedrock は リアルタイムデータとデータベーススキーマを入力に SQL を生成する役割も持ちます。これにより、刻々と変化する状況に対応した施策を提案します。 Amazon Bedrock AgentCore は、効果的なエージェントを大規模かつ安全に構築、デプロイ、運用するためのエージェントプラットフォームです。AgentCore サービスの一つである AgentCore Runtime は、AI エージェントやツールをデプロイして実行するための、安全でサーバーレスの専用ホスティング環境を提供します。本ソリューションでは、AWS が開発したオープンソースの SDK である Strands Agents SDK を利用して開発した AI エージェントを AgentCore Runtime にデプロイしています。AI エージェントには、データベースに対して SQL を実行したり、 Amazon DynamoDB に対して推奨アクションを登録するなどの「ツール」が与えられていて、必要なタイミングで実行することができます。また、 AgentCore Memory は、AIエージェントが過去の対話を記憶できるようにするサービスです。本ソリューションでは、PC やスマートフォンを通じて AI エージェントが担当者と会話をする際に、過去の会話に基づいたパーソナライズされた応答を実現しています。 Amazon DynamoDB は、一桁ミリ秒のパフォーマンスを実現する、サーバーレス NoSQL フルマネージドデータベースです。本ソリューションでは、ベテラン担当者の豊富な経験と知見に基づいて生成されたプロンプトや、AI エージェントによって生成された推奨アクションが保存されています。 Amazon EventBridge は、イベントを使用してアプリケーションコンポーネント同士を接続するサーバーレスサービスです。これにより、スケーラブルなイベント駆動型アプリケーションを簡単に構築できます。本ソリューションでは、定期的に AI エージェントを起動させるために使用されます。 AWS の技術支援を活用した開発プロセス 本ソリューションは、東芝テックが AWS の技術支援のもと開発しました。開発プロセスでは、まず AWS のサンプルソリューション を活用したワークショップを実施し、東芝テックから提供された POS データを用いて AI エージェントの可能性を検証しました。このワークショップを通じて、小売業界特有の課題と AI 活用の方向性を明確化することができました。 続いて、AWS のプロトタイピングプログラムを活用し、具体的なソリューションの実装支援を行いました。東芝テックの豊富な業界知見と、AWS のクラウド・ AI 技術を組み合わせることで、従来解決が困難だった課題へのソリューションが実現しました。 本プロジェクトをリードした、東芝テック株式会社 執行役員 リテール・ソリューション事業本部 副事業本部長、同プロダクト・プランニング&クリエーションセンター長の石川 尚氏は、AWS との連携についてこのようにコメントしています。 東芝テックは、AIやクラウド技術の活用を通じて、小売業界のDXを強力に推進しています。今回、AWSの技術支援のもと、現場の課題解決に直結するAIエージェントを開発できたことは、当社のビジョン実現に向けた大きな一歩です。 小売現場の人手不足や業務の複雑化といった社会的課題に対し、データドリブンな意思決定支援を提供することで、より効率的で持続可能な店舗運営を実現します。 今後も AWS との協力を通じて、業界の未来を切り拓く革新的なソリューションを提供し続けてまいります。 東芝テック株式会社 執行役員 リテール・ソリューション事業本部 副事業本部長 同プロダクト・プランニング&クリエーションセンター長 石川 尚 氏 リテールテックJAPAN 2026での展示について 展示概要 会期 : 2026年3月3日(火)〜6日(金) 会場 : 東京ビッグサイト 東芝テックブース : 東展示棟 4ホール RT4201 東芝テックの告知ページ : https://www.toshibatec.co.jp/event/exhibition/rtj2026.html 小売業界の未来への展望 本ソリューションは、小売業界におけるAI活用の新たな可能性を示すものです。データドリブンな意思決定支援により、以下のような未来の実現を目指しています: 人手不足の解決 : 経験に依存しない店舗運営の実現 収益性の向上 : データに基づく最適な価格設定と在庫管理 顧客満足度の向上 : 適切な商品配置と在庫確保による購買体験の改善 環境負荷の低減 :廃棄ロス削減により、製造・輸送・廃棄における資源消費や GHG 排出量を軽減 東芝テックと AWS は、今後も小売業界の DX を支援し、より効率的で持続可能な店舗運営の実現に向けて取り組んでまいります。リテールテック JAPAN 2026の東芝テックブースにて、ぜひこの革新的なソリューションのデモをご体験ください。小売業界の未来を一緒に創造していきましょう。 お問い合わせ 東芝テック株式会社: 公式ウェブサイト Amazon Web Services: AWS公式サイト 本記事は東芝テック株式会社とアマゾン ウェブ サービス ジャパン合同会社の共同執筆によるものです。 著者 小川 翔 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売業界のお客様を中心にクラウド活用の技術支援を行なっています。好きな AWS サービスは Amazon Bedrock と、Amazon Personalize です。 谷 梨奈子 アマゾンウェブサービスジャパン合同会社 アカウントマネージャー 製造業のお客様を中心にクラウド活用に対する営業支援を行っております。MigrationからAI活用まで幅広い分野を提案させていただきます。
アバター
本記事は 2026 年 2 月 17 日に公開された Nima Kaviani による “ Claude Sonnet 4.6 is now available in Kiro ” を翻訳したものです。 本日より、 Kiro IDE と CLI で Claude Sonnet 4.6 が利用可能になりました。Sonnet 4.6 は Sonnet 4.5 からの完全なアップグレードであり、ソフトウェア開発において Opus 4.6 に匹敵する知能を持ちながら、よりトークン効率が高く、ワークフロー全体でより高速で高品質なタスク完了を実現します。 一日中使いたくなるコーディングモデル Sonnet 4.6 は、複雑なコードベースを手取り足取り誘導する必要がないほど賢いモデルです。機能構築、リファクタリング、デバッグなどの反復的なワークフローを処理し、進行中にモデルをガイドしても品質を損ないません。Sonnet 4.6 は、インタラクティブな開発作業において優れた体験を提供します。 複数のタスクを含む spec を進めている際、Sonnet 4.6 は長いセッション全体でコンテキストと精度を維持します。マルチモデルパイプラインにおいて、リードエージェントとサブエージェントの両方の役割を果たし、適応的な思考とコンテキスト圧縮により、作業の進め方を正確に制御できます。 エージェント作業のために構築 Sonnet 4.6 は、現代の AI 開発が要求する複数ステップのオーケストレーションのために特別に構築されています。ツール呼び出しを処理し、長いセッション全体で状態を維持し、複雑な推論チェーンを管理します。これらすべてを、大量使用を実用的にする価格帯で実現します。 Kiro powers や カスタムサブエージェント を使用しているチームにとって、Sonnet 4.6 は自然に組み込まれます。パイプラインの異なる部分に異なるモデルを必要とせず、オーケストレーターとワーカーの両方の役割を果たすことができます。 利用可能性 Sonnet 4.6 は、Google、GitHub、AWS BuilderID、AWS IAM Identity Center でログインするすべての Kiro Pro、Pro+、Power のお客様にご利用いただけます。Sonnet 4.6 は AWS US-East-1(バージニア北部)および AWS Europe(フランクフルト)リージョンで利用可能で、Sonnet 4.5 と同様に 1.3 倍のクレジット乗数を備えており、開発作業においてコスト効率が良くなっています。 Kiro をダウンロード するか、アプリまたは CLI を再起動して新しいモデルを使用してください。 翻訳は Solutions Architect の吉村が担当いたしました。
アバター
本ブログは、メック株式会社 様と Amazon Web Services Japan が共同で執筆いたしました。 みなさま、こんにちは。AWSアカウントマネージャーの尾田です。 生成 AI が注目されてから数年が経ち、多くの活用事例が生まれています。特に最近では「エージェント」というキーワードも⾮常に注⽬されており、今まで以上に、複雑な業務に AI を活⽤できるようになってきています。 本ブログでは、AI エージェントを活⽤して研究業務の効率化や品質の底上げに取り組まれたメック株式会社様の事例についてご紹介いたします。同社は、AWS 主催のハッカソンイベントへの参加をきっかけに、わずか約3 週間という短期間でソリューションを構築しており、どの程度の効果が出るか検証を進めていく PoC フェーズにおいて、スモールスタートで素早く取り組まれた事例となっております。また、アーキテクチャの中には、Amazon Bedrock AgentCore や、Amazon S3 Vectors を利⽤しており、技術的にも先進的な取り組みとなっております。 お客様の取り組みの背景と目指す姿 企業の研究開発部門において、蓄積された専門知識や技術情報を組織全体の資産として最大限に活用し、全メンバーが高いレベルで業務を遂行できる環境を構築することは、競争力強化の鍵となります。同社では、生成 AI とエージェント技術の進化を好機と捉え、研究業務における次世代の働き方の実現に向けて、先進的な取り組みに挑戦しました。 組織全体の研究力の底上げと標準化 同社が目指したのは、ベテラン社員が持つ高度な検索スキルや情報収集のノウハウを AI エージェントとして実装し、組織全体で共有できる仕組みの構築です。経験年数に関わらず、すべての研究開発メンバーが高品質な情報へアクセスし、迅速な判断を行える環境の実現を目指しました。 複雑な専⾨領域における情報アクセスの革新 研究業務では、専門用語と関連技術が複雑に絡み合っており、適切なアプローチで情報にアクセスすることが重要です。同社は、AI エージェントが自律的に最適な検索クエリを生成し、ユーザーの真の目的に沿った情報を提供する仕組みの構築に取り組みました。これにより、複雑な専門領域においても直感的に情報へアクセスできる環境の実現を目指しています。 知的資産の戦略的活用基盤の構築 日々蓄積される研究データや新規情報、更新される技術情報を、単なるデータとして保管するのではなく、戦略的な知的資産として最大限活用できる基盤の構築を目指しました。AI エージェントによって、情報に適切なコンテキストやメタデータを自動付与し、組織の知見を継続的に進化させる仕組みの実現に取り組まれました。 ソリューション・構成内容 ソリューションイメージ図 同社の目指す姿を実現するため、単純な RAG アーキテクチャや情報更新の⾃動化ではなく、検索と情報更新の 2 つの領域で AI エージェントを活用したソリューションを構築しました。 情報検索エージェント ユーザーからの質問を受け取り、最適な情報を提供します。特徴的なのは、ユーザーの質問⽂をそのまま検索クエリとして使⽤するのではなく、専⾨技術のバックグラウンド知識をもとに、ユーザーの真の⽬的に沿った情報を取得できるよう、裏側で最適なクエリを⾃動⽣成します。また、得られた結果がユーザーの⽬的に沿わない場合は、必要に応じて複数回の検索を⾏います。これにより、すべてのメンバーがベテラン社員と同等レベルの情報アクセスが可能になります。 情報更新エージェント 新規情報の追加時に、単に⽂書をそのまま登録するのではなく、コンテキスト情報を付与します。具体的には、「どのような案件の、どのような相談をもとに必要となった情報なのか」という追加に至る背景情報などを付与します。また、情報の中⾝を確認した上で、メタデータを⾃動⽣成し、検索性を高めた形で情報更新を⾏います。これにより、組織の知的資産が体系的に蓄積され、継続的に価値を生み出す仕組みとなります。 アーキテクチャ図 特に注⽬すべき点は、AI エージェントが動く基盤として、Bedrock AgentCore Runtime を利⽤されている点です。Bedrock AgentCore Runtime は、AI エージェントとツールのデプロイおよびスケーリング専⽤に構築された、セキュアでサーバーレスなランタイム環境です。Bedrock AgentCore Runtimeを利⽤することで、AI エージェントが動くインフラストラクチャの構築・管理をサービス側にまかせることができる点や、将来的な本番運⽤を⾒越し、セキュリティや認証・認可、運⽤性の観点から、採⽤をいただいております。同社はStrands Agents で作成した AI エージェント及び RAG を利⽤するためのツールを Runtime 上にデプロイされています。また、RAG アーキテクチャは、利⽤形態を加味して、S3 Vectors を利⽤してコストを最適化されております。 本ソリューションでは、RAG が AI エージェントが利⽤できるツールの⼀つとなっており、単純な検索システムではなく、ユーザーの意図を理解し、最適な情報取得に向けて⾃律的に動作する仕組みとなっております。開発中に Bedrock AgentCore が一般提供を開始するというタイミングで、Bedrock AgentCore をご利⽤いただいておりましたが、 Amazon Bedrock AgentCore starter toolkitをはじめとしたリソースを活⽤することで⾮常に⾼速に AI エージェントのデプロイができたというお⾔葉もいただいております。 導⼊効果 本ソリューションにより、以下の効果が期待されます。 情報検索時間の短縮:すべてのメンバーが迅速かつ的確に必要な情報へアクセスでき、組織全体の生産性向上が見込まれます 研究業務レベルの底上げ:検索エージェントが適切なクエリを自動生成することで、経験年数に関わらず高品質な情報収集が可能になります 知的資産の継続的な進化:情報更新エージェントにより、調査結果や研究知見、最新情報が体系的に整備・自動更新され、戦略的に活用できる基盤が構築されます まとめ 本ブログでは、メック株式会社様の先進的な取り組みをご紹介しました。AI エージェントを活⽤することで、複雑な業務の効率化だけでなく、組織全体の能力向上につながることがイメージいただけたのではないでしょうか。ユーザーの⽬的を理解して、⽬的達成に向けて⾃律的に動く点が、エージェントの⼀番のポイントになってくるかと思います。 同社は、AI エージェントの活⽤を更にブラッシュアップしていき、より多くの業務での活⽤を進めることで、研究開発における競争力をさらに強化していくとのことです。 本事例が、生成 AI やエージェント技術を活用した業務効率化をご検討中のお客様の参考になれば幸いです。Amazon Bedrock AgentCore を活用したソリューション構築にご興味をお持ちの方は、お気軽にお問い合わせください。 メック株式会社(左から): 古川 智大 様 岸本 宗真 様 足立 優司 様 Amazon Web Services Japan 合同会社: ソリューションアーキテクト 上野 涼平(左端) アカウントマネージャー尾田 美菜(右端)
アバター
本記事は「 New spec types: fix bugs and build on top of existing apps 」を翻訳したものです。 モノリスからマイクロサービスへの移行を進めているとします。アーキテクチャはすでに明確で、イベント駆動、非同期メッセージング、特定のレイテンシ要件があります。必要なのは実装の手助けだけです。あるいは、バグを修正しているとします。何が壊れていて、何をそのままにすべきかはわかっています。外科的な修正が必要です。アプリの他の部分を変更したり、トークンを無駄に消費して堂々巡りすることなく、エージェントと協力してこれらの目標を達成する最善の方法は何でしょうか? Specs と仕様駆動開発ワークフローをリリースした際、私たちは従来の PM/エンジニアリングのフローに基づいて構築しました。まず要件、次に設計、そしてタスクという流れです。これは多くのプロジェクトでうまく機能し、何十万人もの開発者が新しいものを構築する際にこのアプローチをデフォルトとして採用してきました。 しかし、Kiro ユーザーと話す中で、明確なパターンが見えてきました。すべての人が要件から始めるわけではないということです。特に既存のブラウンフィールドアプリで作業する場合、技術アーキテクチャがすでに決まっている状態で取り組む開発者もいます。バグ修正をしていて、何を変更し何を変更すべきでないかを慎重に定義する必要がある開発者もいます。Specs の構造は手放したくないが、現在のフローではこれらのタイプのタスクに対して十分な柔軟性がありませんでした。 開発者がすでに取り組んでいるプロジェクトへのアプローチを変えるよう求めたくはなかったので、本日、デザインファーストワークフローとバグ修正 の 2 つの新しい Spec をリリースします。 硬直的なワークフローが失敗する理由 Specs を最初に設計した際、私たちは Laurence Tratt が提唱する ソフトウェア開発における「循環的仕様問題」と「観察者効果」に動機づけられていました。Tratt は根本的な緊張関係を指摘しています。 構築したいソフトウェアを正確に知る唯一の方法は完全に仕様化することだが、完全な仕様はソフトウェア自体を作成するのと少なくとも同じだけの作業量が必要である ということです。これは、ソフトウェアを真に仕様化するためにはソフトウェアを構築しなければならないという鶏卵問題になってしまいます。特に大規模プロジェクトでは、これは希望的観測にすぎません。Tratt が観察するように、ソフトウェアは空想と現実の間の「リミナルな状態」にあり、実際に何かを構築するまで定量化が難しいソフトな制約に満ちています。ソフトウェアを作成する行為自体が仕様化の行為なのです。これは計画なしで作業するということではなく、素早く進捗できるだけの十分な構造を持つ中間地点に到達するということです。 要件ファーストとデザインファーストは同じコインの表と裏であり、この循環的仕様問題の異なる側面に対処しています。 要件ファースト は、必要な振る舞いや成果は理解しているが、技術的な道筋が不明確な場合に機能します。「これは何をすべきか?」を「どのように動作すべきか?」の前に探求します。選択肢が開かれている新規プロジェクトに最適なオプションです。 デザインファースト は、経験、アーキテクチャ上の制約、またはプロトタイピングから技術的なビジョンをすでに持っていて、そのシステムが実際に何を達成するかを逆算して形式化する必要がある場合に機能します。ソリューションをホワイトボードに描いてから「この製品が何をするか」をまとめるようなものです。既存のアプリの上に新しい機能を構築する場合にも適用できます。現在のアーキテクチャと技術スタック内で作業する必要があるからです。 どちらのアプローチもイテレーションとフィードバックを重視しています。どちらもソフトウェアを事前に完璧に仕様化できるとは主張しません。代わりに、あなたの思考の現在地に合わせて、異なる出発点から循環的仕様問題に取り組む手助けをします。 デザインファースト Spec : 技術的アプローチから始める 次のプロンプトを考えてみましょう。 Wiki とデータレイク用の MCP サーバーを作成したい。タスクを分解して見積もりを出してほしい。FastAPI と mcp-python を使用。UI は不要。 この開発者はすでにスタック(FastAPI と mcp-python)、ハイレベルアーキテクチャ(MCP サーバー)、制約(UI 機能なし)を把握しています。「何を構築すべきか?」ではなく、「すでに設計したこのものを構築する手助けをしてほしい」と求めています。この場合、設計ドキュメントから始める方が理にかなっています。なぜなら、開発者がすでに問題について考えている方法と一致するからです。 そこで、新しい Feature Spec を作成する際、Kiro は選択を求めるようになりました。 要件ファースト または技術 デザインファースト です。技術デザインファーストを選択した場合、詳細レベルを選びます。システム図やコンポーネントのハイレベル設計か、アルゴリズムや関数シグネチャのローレベル設計かです。Kiro はまず設計ドキュメントを生成します。それをイテレーションし、さまざまな技術的アプローチを探求します。満足したら、Kiro は設計から要件を導出し、実現可能性を確保します。残りの Spec ワークフローは同じです。タスク、実装、実装が望んだものと一致するかを確認するプロパティベーステスト。 技術デザインファーストは、事前に定義されたアーキテクチャがある場合、何かが実現可能かどうかを確認するためにプロトタイピングしている場合、または設計の選択肢を制約する厳格な非機能要件がある場合に特にうまく機能します。技術的アプローチが出発点であり、目的地ではない場合に最適です。 バグ修正 Spec : 精密にバグを修正する バグを修正する際には、異なる制約と目標があります。新しいものを構築するのではなく、既存のものを修正します。影響範囲も異なります。変更しすぎると、正常に動作していたものを壊すリスクがあります。問題を修正する最小限の変更が求められます。 では、エージェントと協力してそれを行う最善の方法は何でしょうか? Specs を使ってバグ修正に成功した開発者には 2 つの共通点がありました。第一に、エラーメッセージだけでなく、エラーを引き起こした詳細なシナリオを定義していました。第二に、変更すべきでないものを明示的に述べていました。これは経験豊富な開発者がバグ修正について考える方法です。壊れているものを修正し、それ以外には触れません。 バグ修正 Spec を作成すると、Kiro は同様のアプローチに従い、3 つのセクションを持つ構造化されたドキュメントを生成します。 現在の振る舞い(Current Behavior) は、現在何が起きているかを記述します。「WHEN ユーザーが特殊文字を含むフォームを送信した場合、 THEN システムはバリデーションエラーでクラッシュする(THEN)」。このステップでより包括的に記述することで、Kiro はバグが発生する条件をより正確に診断できます。 期待される振る舞い(Expected Behavior) は、代わりに何が起こるべきかを記述します。「WHEN ユーザーが特殊文字を含むフォームを送信した場合、THEN the system SHALL 入力をサニタイズしてフォームを正常に処理する」。これにより、Kiro は解決された状態がどのようなものかを把握し、実際にバグが修正されたかを後で確認できます。 変更されない振る舞い(Unchanged Behavior) は、そのままでなければならないものを記述します。「WHEN ユーザーが有効なフォームを送信した場合、THEN the system SHALL CONTINUE TO 従来通りに処理を継続する」。変更すべきでないものを暗黙的にするのではなく、バグ修正 Spec はそれを明示的に述べます。これにより、Kiro はリグレッションが導入されていないことを確認し、検証するプロパティテストに反映できます。 この構造により、何が変わり何が変わらないかを明示的に考えることが強制され、基盤となるモデルがあなたの意図をより正確に理解する助けになります。Kiro はこれらのセクションを自動的に構築するため、この .md を自分で書く時間を費やす必要はありません。これらの条件をレビューして改善し、その後 Kiro は Feature Spec と同様に design.md と tasks.md の作成に進みますが、外科的な修正に特化した内容になります。 これがうまく機能する理由は、Kiro 独自のテスト方法にあります。Kiro は 3 つのカテゴリすべてに対してプロパティベーステスト(PBT)を生成します。現在の実装にバグがあることを検証するテスト、修正がバグを解決したことを検証するテスト、そして変更されない振る舞いが以前とまったく同じように動作し続けることを検証するテストです。これらの PBT がなければ、エージェントが包括的な条件セットに対して実際にバグを修正したかどうか、そして変更が本当に外科的であったかどうかを確認することは困難です。 バグ修正 Spec は、構造化された問題解決が有効な複雑なバグ、リグレッションリスクが高い状況、または修正のドキュメントが必要な場合に威力を発揮します。 あなたに適応するツール Specs は、多くの開発者が堅牢なソフトウェアを出荷するための AI 開発へのアプローチを変えました。しかし、既存のアプリ、特に大規模なコードベースで作業する場合、異なるアプローチを好むかもしれません。要件から始める場合もあります。構築したいものが正確にわかっているからです。技術的アプローチがすでに決まっていて、交渉の余地がない場合もあります。バグを修正していて、すべてのユーザーに影響するリグレッションを避けるために外科的な精度が必要な場合もあります。今では Specs は 3 つのユースケースすべてをサポートしています。 ドキュメント で Feature Spec と バグ修正 Spec の詳細をご覧ください。Kiro IDE を ダウンロード または再起動して、Specs の新しいアプローチをお試しください。
アバター
本ブログは、三菱電機株式会社 電力システム製作所 電力ICTセンター 小森様と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト稲田、GitLab 合同会社 ソリューションアーキテクトの小松原様の共著です。三菱電機 電力ICTセンターにおける Kiro と GitLab を組み合わせたソフトウェア開発効率化の取り組みについてご紹介します。 電力ICTセンターについて 三菱電機 電力システム製作所 電力ICTセンターは、再生可能エネルギーの拡大や電力自由化に対応する電力×ICTの専門組織です。電力取引・需給管理から、分散型電源/VPP、蓄電池制御、スマートメーター、託送・精算、環境価値管理、アセットマネジメントまで、電力事業全体をカバーする主力ソリューション「 BLEnDer(ブレンダー) 」を開発しています。BLEnDer を軸に電力の”見える化→判断→計画→制御”を一気通貫で実現する電力デジタルソリューションを提供し、電力会社様、送配電事業者様、小売電気事業者様、発電事業者様など、幅広い事業者様を支えています。 これまでの取り組みと課題 電力ICTセンターでは、ソフトウェア開発の効率化に向けてさまざまな取り組みを行ってきました。 GitLab をベースにした CI/CD 環境の構築 Amazon Bedrock を活用した RAG システムの開発(開発工数見積もりの支援) Amazon Bedrock を活用した設計書レビューの効率化 CI/CD ツールを活用したビルド・テスト・デプロイ作業の効率化 ワークフロー自動化ツールを活用した申請フローの自動化 これらのシステムやツールはそれぞれ開発効率化に寄与していますが、 導入・展開時に共通の課題 がありました。 開発したシステムやツールは、基本的に納入先の開発チームに運用・保守を担っていただきます。そのため、利用方法を示したドキュメントや設計ドキュメントの作成、利用フローの整備が不可欠です。時には勉強会を開催し、必要なスキルを習得していただく必要もありました。しかし、毎回フルセットで伴走支援を行うことは現実的ではなく、ドキュメントや勉強会だけで実践していただくには限界があると感じていました。 「ドキュメントを読まなくても、AI に聞けばワークフローに沿った開発ができる」 ― そんな仕組みを実現するために、Kiro と GitLab を組み合わせた新しいアプローチに取り組んでいます。 Kiro の Steering・Powers・MCP とは 本題に入る前に、今回の取り組みで活用している Kiro の主要機能について説明します。 Steering:プロジェクト横断のグラウンドルール Steering は、Kiro の振る舞いに対して 常に適用されるグラウンドルール を定義する仕組みです。プロジェクトのルートディレクトリに .kiro/steering/ ディレクトリを作成し、マークダウンファイルでルールを記述します。 .kiro/ └── steering/ ├── coding-standards.md # コーディング規約 ├── language.md # 言語設定(日本語で回答する等) └── security.md # セキュリティポリシー Steering に記述したルールは、 どの Power が発動しているかに関わらず常に Kiro のコンテキストに読み込まれます 。そのため、「日本語で回答すること」「機密情報をコードに含めないこと」といった、プロジェクト全体で一貫して守るべきルールの定義に適しています。 電力ICTセンターでは、プロジェクト固有ではない共通のグラウンドルール(言語設定、コーディング規約の基本方針など)を Steering で管理しています。 Powers:動的に呼び出されるワークフロー定義 Powers は、Steering とは異なり、 ユーザーの発話内容に応じて動的に呼び出される ルール定義の仕組みです。Power は POWER.md というメタデータファイルと、 steering/ ディレクトリ配下のステアリングファイル群で構成されます。 .kiro/powers/ └── my-power/ ├── POWER.md # Power のメタデータ(name, description, keywords) ├── mcp.json # この Power 専用の MCP サーバー設定(任意) └── steering/ ├── guide-a.md # ステアリングファイル A └── guide-b.md # ステアリングファイル B POWER.md の frontmatter には keywords を定義でき、ユーザーの発話にこれらのキーワードが含まれると、その Power が動的に発動します。 --- name: "standard-dev-flow" displayName: "Standard Dev Flow" description: "GitLab を使用した開発ワークフローを標準化する Power" keywords: ["イシュー", "ブランチ", "コミット", "MR", "マージリクエスト", "レビュー", "パイプライン", "実装"] --- Steering との使い分けのポイント は、コンテキストウィンドウの効率です。Steering は常に読み込まれるため、大量のルールを定義するとコンテキストを圧迫します。一方、Powers は必要なときだけ動的に読み込まれるため、ワークフロー固有の詳細なルール(数千行に及ぶガイドラインなど)を定義しても、関係ないタスクの際にはコンテキストを消費しません。 電力ICTセンターでは IDE での利用が多く、IDE 上で Power が動的に呼び出されていることを視覚的に確認できる点に安心感を感じています。「いま Kiro がどのルールに従って動いているか」が見えることで、AI の振る舞いを制御できている実感が得られます。 Kiro から Power を呼び出すイメージ MCP(Model Context Protocol):外部ツールとの連携 MCP は、Kiro が外部のツールやサービスと連携するためのプロトコルです。MCP サーバーを定義することで、Kiro が GitLab API の操作や独自のスクリプト実行など、IDE の外にある機能を呼び出せるようになります。 Power ごとに mcp.json を配置できるため、 特定のワークフローでのみ必要な MCP サーバーを、その Power に紐づけて管理 できます。例えば、Standard Dev Flow Power には GitLab 操作用の MCP サーバーを、Playwright Power にはテスト実行用の MCP サーバーを、といった使い分けが可能です。 3 つの機能の関係性 まとめると、以下のような役割分担になります。 機能 適用タイミング 用途 Steering 常時 プロジェクト横断のグラウンドルール Powers キーワードに応じて動的 ワークフロー固有の詳細ルール・手順 MCP Power に紐づけて動的 外部ツール・API との連携 この3層構造により、「常に守るべきルール」「タスクに応じて必要なルール」「外部ツールとの連携」を整理して管理でき、コンテキストウィンドウを効率的に活用しながら AI エージェントの振る舞いを制御できます。 現在の取り組み:Kiro × GitLab による開発プラットフォーム 全体像 現在、CI/CD を中心としたソフトウェア開発サイクル全体の効率化に取り組んでいます。 開発ワークフローの整理(ブランチ戦略・リリース戦略を含む CI/CD 環境の整備) アプリケーションのデプロイ方法の検討、テスト自動化環境の整備 GitLab CI/CD カタログを活用したパイプラインの標準化 ガイドラインの整備 これらの取り組みにおいて、Kiro と GitLab をどのように活用しているかをご紹介します。 Kiro の活用:Powers による開発ワークフローの標準化 Kiro では 2 つの Power (Standard Dev Flow Power, Playwright Power) を利用しています。それぞれについて解説します。 その 1: Standard Dev Flow Power 開発ワークフロー全体を標準化する Power を作成しました。以下のワークフローを Kiro に定義しています。 1. Issue 作成 → 2. ブランチ作成 → 3. 実装 → 4. コミット → 5. MR 作成 → 6. レビュー → 7. マージ この Power には、各フェーズに対応するステアリングファイルが含まれています。 standard-dev-flow/ ├── POWER.md # Power 定義(ワークフロー全体像) ├── mcp.json # MCP サーバー設定 └── steering/ ├── issue-management.md # Issue 作成ガイド ├── branch-commit-mr.md # ブランチ・コミット・MR作成ガイド ├── implementation.md # 実装作業ガイド ├── gitlab-duo-review.md # GitLab Duo レビューワークフロー ├── pipeline-troubleshooting.md # パイプライン失敗解析ガイド └── gitlab-official-mcp-tools.md # GitLab 公式 MCP ツールリファレンス POWER.md にはワークフローの全体像と各ステアリングファイルの参照タイミングを記述しています。例えば、「新しい Issue を作成する際は issue-management.md を参照」「パイプラインが失敗した際は pipeline-troubleshooting.md を参照」といった形で、Kiro がどのフェーズでどのルールを適用すべきかを明示しています。 各ステアリングファイルには、そのフェーズで Kiro が従うべき具体的なルールが記述されています。例えば branch-commit-mr.md には以下のようなルールが含まれます。 ブランチ命名規則: feature/{issue-number}-{brief-description} 形式 Conventional Commits 1.0.0 準拠のコミットメッセージ(type/scope/description/body の構造化、日本語での記述) MR 作成時の squash merge による 1 コミットへの集約 MR テンプレート(変更内容/テスト/レビュー観点/補足)に基づいた記述 開発者は Kiro に「Issue #123 の実装を開始してください」と伝えるだけで、Power に定義されたワークフローに沿って作業が進みます。Kiro は自動的に以下を実行します。 ブランチの確認・切り替え Issue の内容確認と tmp/{タスク名}-issue-details.md の作成 実行計画の作成( tmp/{タスク名}-plan.md ) 実装作業の実施 作業サマリーの作成( tmp/{タスク名}-summary.md ) このように、 作業の追跡ファイルを自動生成する仕組み も Power に組み込んでいます。Issue の詳細理解、チェックリスト形式の実行計画、作業完了後のサマリーを tmp/ ディレクトリに残すことで、作業の透明性を確保しています。 Standard Dev Flow Power には、GitLab 公式 MCP サーバーと独自の MCP サーバーの両方を mcp.json で定義しています。 GitLab 公式 MCP サーバーが提供する主なツール: create_issue / get_issue :Issue の作成・取得 create_merge_request / get_merge_request :MR の作成・取得 search / semantic_code_search :検索機能 独自 MCP サーバー(GitLab MCP Enhancer)で補完しているツール: get_mr_discussions / reply_to_discussion / resolve_all_discussions :MR ディスカッション操作 list_merge_requests / update_merge_request :MR の一覧・編集 list_issues / update_issue / add_issue_note :Issue の一覧・編集 get_latest_pipeline / get_pipeline_jobs / get_job_log :パイプライン解析 この 2 つの MCP サーバーを組み合わせることで、Issue 作成から MR レビュー対応、パイプライン失敗の解析まで、 GitLab の操作をほぼ Kiro 上で完結 できるようになりました。 その 2: Playwright Power 次のステップとして、Playwright を活用した E2E テスト生成のための Power も作成しています。 playwright/ ├── POWER.md # Power定義 └── steering/ ├── playwright-rule.md # コーディング規約・POM変換手順 ├── playwright-cli.md # playwright-cli の使い方 └── test-best-practices.md # テスト実装のベストプラクティス この Power のポイントは、 playwright-cli の出力から Page Object Model(POM)への変換手順 をステアリングファイルに詳細に定義している点です。playwright-cli はコーディングエージェント向けに設計された CLI ベースのブラウザ自動化ツールで、操作ごとに Playwright コードを出力します。 playwright-rule.md には、この出力コードから POM クラスへ変換する 3 ステップの手順が定義されています。 ロケーター抽出 :出力コードから要素を特定 readonly 定義 :コンストラクタでロケーターを宣言 アクションメソッド :操作をメソッドに抽象化 さらに、ロケーター戦略の優先順位も明確に定義しています。 getByRole() – ボタン、リンク等のセマンティック要素 getByLabel() – フォーム要素 getByPlaceholder() – プレースホルダーテキスト getByText() – 表示テキスト getByTestId() – テスト専用属性 CSS/XPath – 最後の手段 test-best-practices.md には、AAA パターン(Arrange/Act/Assert)によるテスト構造化、アサーション強化( toBeVisible() だけでなく toHaveText() で内容確認)、テスト安定化テクニック(スピナー待機、古い DOM の回避)など、実践的なベストプラクティスが記述されています。 これらのルールを Power に落とし込むことで、 誰が Kiro にテスト生成を依頼しても、組織のベストプラクティスに沿った一貫性のあるテストコードが生成されます 。 GitLab の活用 GitLab Pages によるガイドライン公開 プラットフォームを他 BU に展開するにあたり、ガイドラインの整備は不可欠です。GitLab Pages を活用し、マークダウンで記述したガイドを静的 Web サイトに変換して公開しています。ガイドには、GitLab CI/CD カタログを活用した標準パイプラインの説明や、GitLab Duo や Kiro の基本的な使い方や Tips を掲載しています。関連するソースコードはすべて GitLab で管理しており、ソースコードの修正があれば生成 AI を活用して即時にガイドに反映・公開できるため、管理の手間を感じません。 ここで重要なのは、 Powers には基本的にガイドに書いてあることをそのまま落とし込んでいる という点です。これにより、ガイドの内容と AI の振る舞いが常に一致し、「ガイドを読む」か「AI に聞く」かのどちらでも同じ情報にたどり着ける状態を実現しています。 GitLab Pages の利用イメージ CI/CD カタログによるパイプラインの標準化 GitLab CI/CD カタログを作成し、アーティファクトやキャッシュの設定を含むパイプラインテンプレートを配布しています。ユーザー側は環境固有のパラメータ値のみを入力すれば、即座に使用可能な状態です。 GitLab Duo による MR レビュー:AI 同士の協働 Kiro でコーディングを行い、MR を作成した後、GitLab Duo にレビューを依頼するワークフローを構築しています。 生成 AI は自分で生成したコードに対して正しいという認知バイアスがかかる可能性があるため、 コード生成(Kiro)とレビュー(GitLab Duo)を異なる AI に担当させる ことで、より客観的なレビューを実現しています。 GitLab Duo へのレビュー観点は、社内の有識者を交えて mr-review-instructions.yaml に定義しており、レビューコメントに必ず prefix(接頭辞)を付けるルールを設けています。この prefix により、レビュー指摘の重要度が一目で判断できるようになります。 instructions: - name: Common Review Policy fileFilters: - "**/*" instructions: | - **言語**: すべての応答は必ず日本語で行ってください - レビューする際には、以下のprefix(接頭辞)を必ず付けてください - [must] → 必須修正、修正しないのであれば修正しない理由を開発者に求める - [want] → できれば対応してほしい、改善として望ましい提案 - [imo] → 個人的意見、好みベースの提案 - [ask] → 質問、意図・背景の確認 - [nits] → 細かい指摘(nitpicks)、超軽微なスタイル修正など - [info] → 参考情報、共有・補足・関連情報 一方、Kiro 側の Power( gitlab-duo-review.md )には、GitLab Duo のレビュー結果をどう受け取り、どう対応するかのルールを定義しており、GitLab Duo が付与する prefix に対して、Kiro がどのように判断・行動すべきかを明示しています。 ・・・ ### 2. GitLab Duoにレビュー依頼 **重要**: GitLab Duoのレビューは**新規ディスカッション**で`@GitLabDuo`をメンションすることで発動する。MR作成時のdescriptionに記載しても発動しない。 **レビュー依頼のポイント**: - 新規ディスカッションを作成する(これが必須) - `@GitLabDuo`はスペースなしで記載 - 依頼メッセージには以下を含めると効果的: &nbsp; - 実装内容の概要 &nbsp; - 特に確認してほしい点 &nbsp; - 変更理由や背景 &nbsp; - 参考資料: 関連ドキュメント ### 3. レビュー結果確認 **レビューコメントのprefix(重要度の判断基準)**: GitLab Duoのレビューには以下のprefixが付与される。これを基に対応の優先度を判断する。 | Prefix | 意味 | 対応方針 | |--------|------|----------| | `[must]` | 必須修正 | 修正必須。対応しない場合は理由を説明 | | `[want]` | できれば対応 | 改善として望ましい。可能な限り対応 | | `[imo]` | 個人的意見 | 好みベースの提案。採用は任意 | | `[ask]` | 質問 | 意図・背景の確認。回答が必要 | | `[nits]` | 細かい指摘 | 超軽微なスタイル修正。余裕があれば対応 | | `[info]` | 参考情報 | 共有・補足・関連情報。対応不要 | **[ask]への対応**: `[ask]`が付いた質問には、該当ディスカッションに`@GitLabDuo`メンション付きで返信して不明点を解消する。 ・・・ [ask] が付いた質問には、該当ディスカッションに @GitLabDuo メンション付きで返信して不明点を解消するルールも定義しています。 また、GitLab Duo へのレビュー依頼方法についても Power に明記しています。GitLab Duo のレビューは MR の description に記の最後に /assign_reviewer @GitLabDuo を記載することで発動します。こうした「知らないとハマるポイント」も Power に落とし込むことで、開発者が試行錯誤する手間を省いています。 以上を踏まえた、Kiro と GitLab Duo の協働ワークフローは以下の通りです。 Kiro で機能を実装し、MR を作成 GitLab Duo に MR レビューを依頼(MCP 経由) レビュー指摘を Kiro が取得し、対応可否を判断 対応が必要な指摘に対してコード修正を実施 修正をコミット・プッシュし、再度 GitLab Duo にレビューを依頼 承認後、全ディスカッションを一括解決 この AI 同士の協働によるレビューサイクル により、ある程度のクオリティが担保された状態で人間のレビュアーが入ることで、レビュー負担の軽減が期待できます。 この構成のメリット 1. 導入ハードルの大幅な低下 Power を活用して開発フローを定義しているため、開発者は Kiro に質問しながら作業を進めるだけで、ワークフローに沿った開発を行うことができます。分からないことは Kiro に質問して解決できるため、Kiro の基本的な使い方を覚えるだけで開発を始められます。BU への展開時に「AI がサポートしてくれるし、ガイドを特に読む必要はないよ」と伝えるだけでハードルがぐっと下がります。 2. 開発の証跡とコラボレーション Issue や MR で開発の証跡を残すことで、他の開発者とのコラボレーションが容易になります。Issue を追うことで、別の開発者が作業を引き継ぐことも容易になると考えています。 3. レビュー負担の軽減 コード開発の速度が上がる一方で、レビュー者への負担が増大するリスクがあります。GitLab Duo での観点に基づいたレビューと CI/CD パイプラインの実行結果を Kiro にフィードバックさせて改善することで、人間のレビュアーが入る前にある程度のクオリティを担保できます。人間のレビュー疲れやレビュー工数の削減にも寄与することを期待しています。 工夫した点と苦労した点 1 : Power の発動率を上げる工夫 Power に keywords を設定して呼び出しの工夫をしましたが、期待通りに発動しないケースがありました。例えば、Standard Dev Flow Power には ["イシュー", "ブランチ", "コミット", "MR", "マージリクエスト", "レビュー", "パイプライン", "実装"] といったキーワードを設定していますが、ユーザーの発話がこれらのキーワードに完全に一致しない場合、Power が発動しないことがありました。 調査の結果、 Power を積極的に活用するよう促す Steering ファイルを作成する ことで、利用率が向上しました。Steering は常にコンテキストに読み込まれるため、「利用可能な Power がある場合は積極的に活用すること」というルールを Steering に記述することで、Power の発動率を改善できます。AI エージェントツールを組織で活用する際には、こうしたチューニングが重要になります。 2: GitLab 公式 MCP サーバーの補完 GitLabの良さはそのカスタマイズ性の高さにあります。 公式 MCP サーバーを補完する独自の MCP サーバー(GitLab MCP Enhancer)を自作 しました。 gitlab-official-mcp-tools.md というステアリングファイルに 公式 MCP サーバー (Beta 版)の全 14 ツールのパラメータ定義と使用例を記述し、Kiro が正しくツールを使えるようにガイドしています。これによりMR ディスカッションの取得・返信・解決、Issue の一覧・編集、パイプラインのジョブログ取得など、 GitLab の操作が大幅に向上し、ほぼ Kiro 上で操作を完結できるようになりました。 今後の展望 直近では、現在作成中の Playwright Power を完成させ、E2E テスト生成の効率化を推進していきます。また、Playwright Power と並行して、SonarQube の MCP サーバーを活用し、静的解析結果を Kiro にフィードバックする仕組みの構築も検討し始めました。これにより、コードレビュー時だけでなく、実装段階からコード品質を高めるための仕組み作りにも取り組んでいます。このように、組織で活用が見込まれる OSS の活用を推進する Power を順次作成し、AI を活用してソフトウェア開発が楽になる土壌を広げていく方針です。また、GitLab Duo のレビュー観点も継続的に育てていき、適用範囲を広げることでレビュー負担のさらなる軽減を目指します。 1 : 効果の定量化と継続的な改善 AI 活用による開発効率化の効果を可視化するため、定量的な評価指標の測定に取り組んでいきます。Issue からマージまでのリードタイムやレビューイテレーション回数といった開発速度の指標、GitLab Duo のレビュー指摘の精度、Kiro の Playwright Power で生成されるコードの品質などを、実際に各ビジネスユニット (以降、BU)で使用していただきながら評価していきます。これらのフィードバックを基に、Power のルール定義の改善や MCP サーバーの機能拡張など、継続的な改善サイクルを回していきます。 2 : Power とパイプラインのエコシステム構築 Power や CI/CD パイプラインを組織全体で活用していくため、バージョン管理と配布の仕組みを構築していきます。GitLab で Power/MCP や CI/CD パイプラインテンプレートを一元管理し、GitLab Pages で導入方法・アップグレード方法を公開します。バージョン更新時には更新ダッシュボードでユーザーに通知し、各 BU からの要望は Issue やチケットで収集して継続的に改善します。また、既存の管理システムとの連携も視野に入れ、障害報告から修正、リリースまでの開発サイクル全体の効率化を図ります。 3 : 組織全体への展開とコミュニティ形成 中長期的には、電力ICTセンター内の各 BU への展開を加速させていきます。積極的な情報発信を通じて周囲を巻き込みながら、地道に活用の輪を広げていきます。Power やルール整備の取り組みは電力ICTセンターに閉じた話ではないため、ゆくゆくは三菱電機全社的な取り組みとして認知され、活用方法について議論できるコミュニティが形成されることを目指しています。まずは足元の電力ICTセンターのソフトウェア開発効率化につながる活動をどんどん進めていきたいと考えています。 まとめ 三菱電機 電力ICTセンターでは、Kiro の Steering・Powers・MCP と GitLab の各機能を組み合わせることで、 「AI に聞けばワークフローに沿った開発ができる」 プラットフォームの構築を進めています。 この取り組みの本質は、単なるツール導入ではありません。 Steering でプロジェクト横断のグラウンドルールを定義し Powers でワークフロー固有の詳細なルール・手順を動的に呼び出し MCP で GitLab をはじめとする外部ツールとシームレスに連携する この 3 層構造により、ガイドラインの内容を Powers に落とし込み、GitLab Pages で公開するガイドと AI の振る舞いを一致させることで、 ドキュメントを読んでも AI に聞いても同じ結果にたどり着ける 仕組みを作っています。さらに、Kiro によるコード生成と GitLab Duo によるレビューという AI 同士の協働により、人間のレビュー負担を軽減しながら品質を担保するワークフローを実現しています。 ソフトウェア開発の効率化は、ツールの導入だけでは完結しません。開発ワークフローの標準化、ガイドラインの整備、そしてそれらを AI エージェントに落とし込むことで、初めて組織全体の開発効率が向上します。本ブログが、同様の課題を抱える皆様の参考になれば幸いです。 著者 小森 裕之 電力システム製作所 電力デジタルエナジーシステム開発部 システム基盤課所属。 コーヒーと Kiro が大好きです! 電力ICTセンター内の全ビジネスユニットの開発・運用に貢献するため、ITIL4 に準拠した専用プラットフォームの開発に携わっており、主に CI/CD 環境の検討・構築・導入や AI エージェントツールを活用した開発の仕組みづくりを担当しています。 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。2022 年から三菱電機グループを支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。 小松原 つかさ GitLab 合同会社 シニアパートナーソリューションアーキテクト 長きに渡るソフトウェア開発経験を持ち、データベース、セキュリティ、ビッグデータの領域での深い専門知識を持ちます。2022 年にGitLab に参加し、AI 駆動型開発ツールがもたらす新しい開発パラダイムの構築に取り組んでいます。
アバター
このブログは、シスメックス株式会社 次世代医療事業開発室と、ディピューラメディカルソリューションズ株式会社、アマゾン ウェブ サービス ジャパン合同会社 シニア ソリューション アーキテクト 中島丈博による共著です。 シスメックス株式会社の視線計測アプリ「Gazefinder」のご紹介 背景 シスメックス株式会社は、「より良いヘルスケアジャーニーを、ともに。」をビジョンに掲げ、臨床検査機器・診断薬やソフトウェアを世界中に提供しています。2025 年 10 月、私たちは新たな領域への挑戦として、お子さまの視線をオンラインで計測し、個性や社会性の発達を可視化するサービス 「 Gazefinder 」 をトライアルリリースしました。子育てにおいてお子さまの興味の対象を知ることは重要ですが、日常の中で正確に把握するのは簡単ではありません。そこで注目されているのが、視線を通じてお子さまの興味や発達を理解する技術です。 サービス概要 「Gazefinder」は、一般的なノートパソコンに搭載されたカメラを使って、お子さまの視線を計測します。視線の計測結果から専門的な知見をもとに、お子さまの個性や社会性の発達を客観的に把握し、保護者やご家族が安心して子育てできるようにサポートします。 Gazefinder 子どもの視線をオンラインで計測。個性や社会性がわかります | シスメックス株式会社 特徴 ・視線計測の専用装置不要:ノートパソコンに搭載されたカメラで視線計測が可能で、計測後約 10 分で結果を確認できる ・専門的な知見に基づいたコメント:視線の計測結果は専門的な知見により解析が行われ、後日、視線から分かることがコメントとしてお手元に届く ・専門のオペレータによる解説:オンラインで個別のフィードバックを受けられる(有料) ・子育てに役立つ動画:専門のオペレータによる解説をご利用いただいた方に、興味・関心に応じた動画が配信される AWS アーキテクチャのご紹介 サーバーレスアーキテクチャによるアプリケーション 視線計測アプリ「Gazefinder」は サーバレスアーキテクチャ を採用しています。一般的にサーバーレスアーキテクチャとは、サーバーのプロビジョニングや管理をクラウドプロバイダーに任せて、ディベロッパーはサーバーレスのコード実行環境やマネージドサービスを利用してアプリケーションを構築する設計手法です。AWS ではサーバーを管理することなく、コードの実行、データの管理、アプリケーションの統合を行うためのサービスを提供しており、Gazefinder はそれらを活用して Web アプリケーションを構築しています。今回利用したいくつかのサービスの中からポイントとなる要素を抜粋し、以下にご紹介します。 AWS Amplify を活用した Web アプリケーション開発 AWS Amplify は AWS を使用したスケーラブルな Web およびモバイルアプリ開発のためのフレームワークです。AWS Amplify を利用することでバックエンド構築機能を使用してフルスタックのアプリを構築し、 Amplify Hosting を使用して Web アプリケーションをデプロイ可能です。Gazefinder では Amplify CLI を利用してコマンドラインから効率的に Web アプリケーションを構築し、ホスティング環境は Amplify Hosting を利用することで、Git リポジトリから取得したソースコードから CI/CD が有効なスケーラブルなホスティング環境にデプロイしています。 視線計測を実現した Amazon Rekognition EyeDirection Amazon Rekognition はクラウドベースの画像およびビデオ分析サービスであり、機械学習の専門知識がなくても、イメージファイルやビデオファイルの物体検出、テキスト検出、安全でないコンテンツの検出、画像/ビデオ分析、顔比較などの機能をアプリケーションに追加することが可能です。今回 Gazefinder に実装された視線計測には Amazon Rekognition の EyeDirection が利用されています。EyeDirection は画像内の顔検出機能である DetectFaces の属性の1つとして提供されるものであり、Amazon Rekognition API として提供されています。画像を分析すると EyeDirection はレスポンスとして、サービスが予測した視線方向に対する 0 から 100 の範囲の信頼度、-180 から 180 の範囲でピッチ軸での視線方向を表すピッチ、-180 から 180 の範囲でヨー軸での視線方向を表すヨーを返します。 ピッチとヨーの値は、ユーザーが見ている画面上の x-y 座標にマッピングする必要がありますが、ユーザーとカメラとの距離および相対位置によってピッチとヨーの値と、画面上の x-y 座標との関係が変化します。そのため、分析を実施する前に、ピッチとヨーの値のマッピングをキャリブレーションする必要があります。 キャリブレーションは映像の一部に組み込まれており、ユーザーは画面の上下左右に動くアニメーションを視線で追うことで自動的に行われます。さらに、Gazefinder では EyeDirection からのレスポンスのうち、視線方向の値の信頼度の情報も加味して解析することにより、正確な視線計測を実現しています。 Amazon Chime SDK を活用したオンライン相談 Amazon Chime SDK は、音声通話、ビデオ通話、画面共有機能をウェブまたはモバイルアプリケーションに追加できるようにする WebRTC ベースのリアルタイム通信プラットフォームです。Gazefinder では視線の計測結果について専門のオペレータとのオンライン相談が可能となっており、これに利用しているのが Amazon Chime SDK です。ビデオ通話は、WebRTC プロトコルを使用したオンラインミーティングが可能であり、クライアントアプリケーションが SDK を介して Amazon Chime のメディアサービスに接続し、音声・映像ストリームの送受信を行います。またAmazon Chime SDK は API を利用した実装が可能となっていることから、UI をサービスに合わせてカスタマイズすることが可能です。 おわりに 本ブログでご紹介したシスメックス株式会社とディピューラメディカルソリューションズ株式会社の取り組みや関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について シスメックス株式会社 辻本 研二 (Kenji Tsujimoto) 執行役員 次世代医療事業開発室長:再生細胞医療やデジタル医療、そして小型デバイスをキーワードにシスメックスならではの新事業を創出することを目指しています。 村上 耕平 (Kohei Murakami) 次世代医療事業開発室 部長:デジタルヘルスの分野で新たな事業の企画、立ち上げ、推進、マーケティングまで新規事業に係る一連のプロセスを実行しています。 ディピューラメディカルソリューションズ株式会社 田野島 英司 (Eiji Tanoshima) 開発企画・開発部長:AI・IoT・クラウド・データ解析を融合し、医療・介護の専門家と利用者を結ぶ次世代スマートヘルスケアサービスの創出に向けた研究開発をリードしています。 竹内 康浩 (Yasuhiro Takeuchi) 開発企画・開発部 メディカルアプリケーションエンジニア:ゲイズファインダーアプリの受託開発ならびに保守運用を担当しており、AI を活用した新機能の企画・開発を推進しています。 アマゾン ウェブ サービス ジャパン合同会社 中島 丈博 (Takehiro Nakajima) ハイテク &amp; ヘルスケア・ライフサイエンス部 シニアソリューションアーキテクト: ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。 Amazon Web Services UK Inc. Amir Omicevic Solutions Architect at AWS and works with customers across automotive, supply chain and professional services industry. He specialises in enterprise-scale strategizing, architecture and building transformative AI/ML solutions to deliver measurable business outcomes and unlock new business value for his customers. Beyond his professional role, he enjoys teaching his children how to play music instruments and the basics of computing and AI.
アバター
この記事では、 Amazon DynamoDB データに対する検索を Amazon OpenSearch Service との ゼロ ETL 統合を使用して実装する方法を紹介します。データパイプラインの構築と保守を行うことなく、アプリケーションに全文検索、あいまい一致、複雑な検索クエリを追加する方法を学びます。 Amazon DynamoDB は、大規模な環境で 1 桁ミリ秒の応答時間と高スループット操作を必要とするアプリケーションに最適な選択肢です。OpenSearch Service と組み合わせることで、アプリケーションは複雑な検索と分析のための強力な機能を獲得します。このゼロ ETL 統合がアプリケーションの検索機能をどのように強化できるかを示す実用的なユースケースを見ていきましょう。 現状の概要 AnyCompany は、エコフレンドリーで持続可能な製品を専門とする架空のオンラインマーケットプレイスで、世界中の環境意識の高い消費者にサービスを提供しています。彼らのアプリケーションは AWS サーバーレスアーキテクチャ 上で動作しており、 AWS Lambda 関数が e コマース操作を処理します。製品情報や在庫詳細などのコアトランザクションデータは DynamoDB に保存されています。 AnyCompany の製品用 DynamoDB テーブルレイアウトには、以下の属性が含まれます: 属性 例 product_id ( パーティションキー ) Id_1 name ECO T-Shirt description Organic CottonTee price 100 rating 5 category Activewear brand AnyCompany tags organic specs {“color”:”white”,”size”:”M”} stock 48 created_at 2025-12-16T16:15:43.473864+0000 updated_at 2025-12-16T16:15:43.473864+0000 書き込み操作では、AnyCompany は DynamoDB を使用してデータの一貫性を維持します。製品情報を更新する際、システムは product_id をパーティションキーとして使用して製品の更新を実行します。AnyCompany の製品カタログの拡大により、顧客の検索パターンがより複雑になり、システムはバリエーション、スペルミス、セマンティッククエリ、ファセット検索(顧客が価格帯、ブランド、評価、製品カテゴリなどの複数の属性を使用して製品をフィルタリングし、絞り込むことができる機能)を処理する必要があります。 企業が拡大するにつれて、以下のような検索シナリオが浮上しています: マルチフィールド検索 – 顧客は、製品名、説明、カテゴリ、タグなどの複数のフィールドを同時に検索する必要があります。 マルチレンジ検索 – 顧客は、価格帯($20-$50)や評価(4-5 つ星)など、複数の基準で製品をフィルタリングしたいと考えています。 発見とナビゲーション – 顧客は、ファセット検索を使用して結果を段階的に絞り込み(カテゴリ、ブランドなどのフィルタを使用)、動的な集計を通じて選択肢を理解したい(カテゴリ別の製品数、ブランド、評価の分布を確認するなど)と考えています。 あいまい検索と提案 – 顧客は、タイプミスやスペルミスがあっても検索が機能することを望んでいます(例えば、「reuseble botl」と入力しても「reusable water bottle」が見つかる)。また、入力中にオートコンプリート提案を受け取り、製品をより迅速に見つけられるようにしたいと考えています。 セマンティック検索 – 顧客は、正確な製品名ではなく自然言語の説明を使用することがよくあります。例えば、「biodegradable kitchen storage containers」を検索すると、関連するエコフレンドリーな食品保存製品が返されるべきです。 AWS は DynamoDB と OpenSearch Service 間のゼロ ETL 統合 を提供し、これら 2 つのサービス間でデータを同期します。この統合により、カスタムデータパイプラインを構築および保守することなく、OpenSearch Service の検索機能で DynamoDB ベースのアプリケーションを補完し、これらの検索要件を満たすことができます。 以下の例では、OpenSearch Service が AnyCompany のこれらの検索シナリオで DynamoDB をどのように補完するかについて説明します。 マルチフィールド検索 顧客の検索パターンは本質的に動的であり、顧客は常に製品を検索する新しい方法を求めています。AnyCompany では、顧客は検索クエリが複数の製品属性に同時に一致することを望んでおり、製品名、説明、カテゴリ、タグで一致を探して、関連するアイテムを見逃さないようにしています。 OpenSearch は、検索ユースケースをカスタマイズし、検索の関連性を向上させるための多くの機能を提供します。完全なリストについては、 検索機能 を参照してください。OpenSearch は、データを検索するために使用できる クエリドメイン固有言語(DSL) と呼ばれる検索言語を提供します。 以下は、この機能を実装するクエリの例です: GET products/_search { "query": { "bool":{ "should": [ { } ] } }, "size":20 } マルチレンジ検索 前述の検索機能に基づいて、AnyCompany の顧客は、特定の価格帯($25–50)内の製品を検索しながら、特定のカテゴリと評価を考慮するなど、複数のフィルタリング基準を組み合わせたいと考えることがよくあります。 OpenSearch Service では、さまざまな方法を使用して検索結果をフィルタリングできます。各方法は特定のシナリオに適しています。クエリレベルでフィルタを適用し、 Boolean クエリ句と post_filter および aggregation レベルのフィルタを使用できます。 以下は、この機能を実装するクエリの例です: GET products/_search { "query": { "bool":{ "should": [ { "multi_match": { "query": "Men's Wear", "fields": ["name.ngram","description","category","tags"] } } ], } }, "size":20 } 発見とナビゲーション AnyCompany では、顧客は特定のアイテムを検索するのではなく、インタラクティブなインターフェースを通じて製品を発見したいと考えています。例えば、持続可能なファッションを閲覧している顧客は、「Men’s Wear」の検索から始めて、利用可能な製品の全体像を理解したいと考えるかもしれません。彼らは、利用可能なカテゴリ、持続可能なオプションを提供するブランド、一般的な価格帯、製品評価を確認したいと考えています。集計されたデータは通常、サイドバーにフィルタリングオプションとして表示され、顧客が直感的に検索結果を絞り込むことができます。 OpenSearch 集計 を使用すると、データを分析し、そこから統計を抽出できます。メトリクス集計を適用して簡単な計算を実行したり、バケット集計を使用してドキュメントのセットをバケットとして分類したり、パイプライン集計を使用して複数の集計を連鎖させたりできます。 以下は、この機能を実装するクエリの例です: GET products/_search { "query": { "bool":{ "should": [ { "multi_match": { "query": "Men's Wear", "fields": ["name.ngram","description","category","tags"] } } ] } }, "aggs": { "categories": {"terms":{"field":"category.keyword","size":10}}, "brands":{"terms":{"field":"brand.keyword","size":10}}, "colors":{"terms":{"field":"specs.color","size":10}}, "sizes":{"terms":{"field":"specs.size","size":10}}, "size":20 } あいまい検索と提案 AnyCompany では、顧客は不完全な記憶で製品を検索することが多く、タイプミスをしながらも、意図を予測できるリアルタイムの検索提案を期待しています。例えば、「Omga」と入力すると、タイプミスを許容し、「OmegaWear」や「Omega Eco Essentials」などの関連製品を提案する必要があります。これには、スペルのバリエーションやタイプミスを処理しながら、ショッピング体験を向上させる検索提案を提供する堅牢な検索システムが必要です。OpenSearch では、キーストロークごとに更新され、関連する提案を提供し、タイプミスを許容するオートコンプリート機能を設計できます。 以下は、この機能を実装するクエリの例です: GET products/_search { "suggest": { "product_suggest": { "prefix": "Om", }, "size": 5 } } } } セマンティック検索 AnyCompany では、顧客は特定の製品名やカテゴリではなく、「red beach hat for summer」のような自然なフレーズを使用して製品のニーズを表現することがよくあります。この直感的な検索方法には、キーワードの一致だけでなく、顧客のクエリの背後にあるセマンティックな意味を理解するシステムが必要です。 OpenSearch は、 ベクトル検索 を通じてこの自然な検索体験を可能にします。システムは、顧客のクエリをベクトル埋め込み(テキストのセマンティックな意味を捉える数値表現)に変換します。これにより、正確なキーワード一致ではなく、概念的な類似性に基づいて一致させることができます。 以下は、この機能を実装するクエリの例です: GET /products/_search { "query": { }, "aggs": { "categories": { "terms": { "field": "category" }}, "brands": { "terms": { "field": "brand" }}, "avg_rating": { "avg": { "field": "rating" }} }, "size": 20 } 以下のセクションでは、既存の Amazon DynamoDB 操作を維持しながら、検索機能をサポートするソリューションを実装する方法を示します。 ソリューションの概要 以下の図は、ソリューションアーキテクチャを示しています。 AnyCompany の既存のアーキテクチャは、 Amazon API Gateway が顧客のリクエストを AWS Lambda 関数にルーティングするサーバーレスパターンに従っています。この関数は、プライマリデータストアとして機能する DynamoDB テーブルに対して読み取りおよび書き込み操作を実行します。 既存のアーキテクチャを補完するために、AnyCompany は DynamoDB と OpenSearch Service 間のゼロ ETL 統合を実装します。統合は 2 つのフェーズでデータを同期します: ポイントインタイムリカバリ(PITR) は既存の DynamoDB データを Amazon S3 にエクスポートして初期スナップショットを作成し、 DynamoDB Streams は継続的な変更をキャプチャして OpenSearch サービスにほぼリアルタイムで更新します。 セマンティック検索に必要な リモート推論 を有効にするために、 OpenSearch ML コネクタ を使用して OpenSearch を Amazon Bedrock の Titan テキスト埋め込み モデルに接続できます。 OpenSearch Ingestion パイプラインはこれらのストリームを消費し、必要に応じてデータを変換し、ほぼリアルタイムで OpenSearch Service に同期します。同期エラーをキャプチャするために、デッドレターキュー(DLQ)として Amazon Simple Storage Service (Amazon S3)バケットを指定します。 検索機能をサポートするために、ソリューションは OpenSearch Service を使用して検索リクエストを処理する新しい Lambda 関数を追加します。この関数は OpenSearch Service SDK を使用してクライアントを作成し、検索クエリを実行します。この新しい関数は、既存の操作を処理し続ける既存の書き込み Lambda 関数と並行して動作します。 この設計により、AnyCompany は e コマースワークロードを維持しながら、堅牢な検索機能を実装できます。 Amazon DynamoDB と Amazon OpenSearch Service 間のゼロ ETL 統合の実装 このセクションでは、強化された検索機能のためのセマンティック検索機能を含む、DynamoDB と OpenSearch Service 間のゼロ ETL 統合をセットアップする方法を示します。 前提条件 このソリューションをセットアップするには、以下が必要です: AWS アカウント 。 以下の AWS リソースを作成および管理するための適切な AWS Identity &amp; Access Management (IAM)権限: DynamoDB テーブル。 OpenSearch ドメイン 。 Amazon OpenSearch Ingestion(OSIS)パイプライン。 CloudFormation テンプレート 。 DynamoDB エクスポートおよび DLQ イベント用の Amazon S3 汎用バケット。 Amazon Titan Embeddings G1 が有効になっている Amazon Bedrock。詳細については、 Amazon Bedrock 基盤モデルへのアクセス を参照してください。 実装手順 ステップ 1:DynamoDB テーブルの作成 ソリューションのウォークスルーの目的で、「Products」という名前の新しい DynamoDB テーブルを作成します。既存の DynamoDB テーブルでこのソリューションを実装する場合は、このステップをスキップできます。以下の AWS CLI コマンドを実行してテーブルを作成します: aws dynamodb create-table \ --table-name Products \ --attribute-definitions \ AttributeName=product_id,AttributeType=S \ --key-schema \ AttributeName=product_id,KeyType=HASH \ --billing-mode PAY_PER_REQUEST \ --region us-east-1 テーブルのステータスが CREATING から ACTIVE に変わるまで待ちます。ステータスは以下で確認できます: aws dynamodb describe-table \ --table-name Products \ --region us-east-1 \ --query 'Table.TableStatus' ステップ 2:DynamoDB Streams とポイントインタイムリカバリ(PITR)の有効化 以下の AWS CLI コマンドを実行します: aws dynamodb update-table \ --table-name Products \ --stream-specification \ StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region us-east-1 aws dynamodb update-continuous-backups \ --table-name Products \ --point-in-time-recovery-specification \ PointInTimeRecoveryEnabled=true \ --region us-east-1 ステップ 3:OpenSearch ドメインの作成 以下の AWS CLI コマンドを実行してドメインを作成します: aws opensearch create-domain \ --domain-name demo \ --engine-version "OpenSearch_3.1" \ --cluster-config InstanceType=t3.small.search,InstanceCount=1 \ --ebs-options EBSEnabled=true,VolumeType=gp3,VolumeSize=10 \ --access-policies '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:YOUR_ACCOUNT_ID :domain/demo/*"}]}' \ --advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"admin","MasterUserPassword": "YourStrongPassword123!"}}' \ --node-to-node-encryption-options Enabled=true \ --encryption-at-rest-options Enabled=true \ --domain-endpoint-options EnforceHTTPS=true \ --region us-east-1 注意: YOUR_ACCOUNT_ID を実際の AWS アカウント ID に置き換えてください YourStrongPassword123! を強力なパスワードに置き換えてください(OpenSearch Dashboards へのログインに使用するため保存してください) ドメインのステータスを確認: aws opensearch describe-domain \ --domain-name demo \ --region us-east-1 \ --query 'DomainStatus.{Status:Processing,Endpoint:Endpoint }' Processing フィールドが Status false を返すまで待ちます。これはドメインがアクティブであることを示します。アクティブになったら、Endpoint(API アクセス用)をメモし、作成したマスターユーザー名とパスワードを使用して OpenSearch Dashboards URL(通常は https:///_dashboards/)に移動します。 ステップ 4:OpenSearch セキュリティ設定の構成 OpenSearch Service ドメインの OpenSearch Dashboards プラグインに移動します。Dashboards エンドポイントは、 OpenSearch Service コンソール のドメインダッシュボードで確認できます。 メインメニューから Security 、 Roles を選択し、 ml_full_access ロールを選択します。 Mapped users 、 Manage mapping を選択します。 Backend roles の下に、ドメインを呼び出す権限が必要な Lambda ロールの ARN を追加します。 arn:aws:iam:::role/LambdaInvokeOpenSearchMLCommonsRole Map を選択し、ユーザーまたはロールが Mapped users の下に表示されることを確認します。 このマッピングにより、モデル統合に必要な権限が有効になります。このロールは、モデル ID を登録する次のステップで作成されます。 図 2:OpenSearch セキュリティ設定 ステップ 5:Bedrock モデル統合のセットアップ リモート推論を使用すると、Amazon SageMaker AI や Amazon Bedrock などの ML サービスでモデル推論をリモートでホストし、ML コネクタを使用して Amazon OpenSearch Service に接続できます。 リモート推論のセットアップを容易にするために、Amazon OpenSearch Service はコンソールで AWS CloudFormation テンプレートを提供します。 Amazon OpenSearch Service コンソール を開きます。 左側のナビゲーションペインで、 Integrations を選択します。 Integrate with Amazon Titan Text Embeddings model through Amazon Bedrock を選択します Configure domain 、 Configure public domain を選択します。 「Amazon OpenSearch Endpoint」と「Model region」のパラメータ値を入力します。 「 I acknowledge that AWS CloudFormation might create IAM resources 」をチェックします Create stack を選択します スタックのデプロイが正常に完了したら、Outputs タブに移動し、 Model Id をメモします。 図 3:Bedrock モデル統合 ステップ 6:OpenSearch Ingest パイプラインのセットアップ Amazon Bedrock のモデルを使用して入力フィールド description から埋め込みを作成し、 description_embedding という名前のフィールドにマッピングする インジェストパイプライン を作成します。 ドメインの OpenSearch Dashboards URL に移動します。URL は OpenSearch Service コンソール のドメインダッシュボードで確認できます。 左側のナビゲーションパネルを開き、 DevTools を選択します。 埋め込みパイプラインを作成します: PUT /_ingest/pipeline/bedrock-embedding-pipeline { "description": "A text embedding pipeline", "processors": [ { "text_embedding": { "model_id": "&lt;your_model_id&gt;", // 前のステップの ModelId に置き換えます。 "field_map": { "description": "description_embedding" }, "skip_existing": true } } ] } 図 4:OpenSearch Ingest パイプラインの作成 ステップ 7:OpenSearch インデックステンプレートの準備 ユースケースのゼロ ETL 統合パイプラインをセットアップする前に、検索要件を分析し、最適なパフォーマンスのための適切なインデックステンプレートを設計します。 以下のガイドラインを検討してください: アクセスパターンを分析し、検索可能にする必要があるフィールドを決定し、適切なフィールドタイプを選択します。 product_id や category のような正確な一致には keyword を使用します。 全文検索機能には、アナライザー付きの text を使用します。 タイムスタンプフィールドには date を使用します。 フィールド選択を最適化するために、処理オーバーヘッドを削減するために必要なフィールドのみをインデックス化します。 特殊な検索ニーズに対してカスタムアナライザーを実装します。例えば、オートコンプリート機能には n-gram アナライザーを使用し、部分一致を可能にします。 セマンティック検索要件を決定します。ビジネスユースケースに適したフィールドを埋め込みます。選択した埋め込みモデルとパフォーマンス要件に基づいて、適切な次元とアルゴリズムでベクトルフィールドマッピングを構成します。 以下は、マッピングテンプレートの例です: { "template": { "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 1, "knn": true, "knn.algo_param.ef_search": 100, "default_pipeline": "bedrock-embedding-pipeline" }, "analysis": { "analyzer": { "custom_analyzer": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "stop" ] }, "ngram_analyzer": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "ngram_filter" ] } }, "filter": { "ngram_filter": { "type": "ngram", "min_gram": 4, "max_gram": 5 } } } }, "mappings": { "properties": { "product_id": { "type": "keyword" }, "name": { "type": "text", "analyzer": "custom_analyzer", "fields": { "keyword": { "type": "keyword" }, "ngram": { "type": "text", "analyzer": "ngram_analyzer" }, "suggest": { "type": "completion", "analyzer": "simple" } } }, "description": { "type": "text", "analyzer": "custom_analyzer" }, "price": { "type": "float" }, "rating": { "type": "float" }, "category": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "brand": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "tags": { "type": "text", "fields": { "keyword": { "type": "keyword" } } }, "specs": { "properties": { "color": { "type": "keyword" }, "size": { "type": "keyword" }, "weight": { "type": "float" }, "dimensions": { "type": "keyword" } } }, "stock": { "type": "integer" }, "created_at": { "type": "date" }, "updated_at": { "type": "date" }, "description_embedding": { "type": "knn_vector", "dimension": 1536, "method": { "engine": "faiss", "space_type": "l2", "name": "hnsw", "parameters": { } } } } } } } ステップ 8:OpenSearch Ingestion パイプラインのセットアップ DynamoDB Service コンソール を開き、 Integrations を選択し、統合を作成して Amazon OpenSearch を選択します。 ソース(DynamoDB テーブル)の構成 ドロップダウンから統合のソースとなる DynamoDB テーブルを選択します。 Enable Stream Enable Export を有効にし、S3 Bucket、S3 region を構成します Configure processor (データ変換のためのプロセッサーをセットアップ) Configure sink (OpenSearch ドメイン): Choose a domain 「Index Name」として「products」と入力します。 Customized Mapping を選択し、ステップ 7 で定義したテンプレートを使用します。 失敗したイベントをオフロードし、分析用にアクセス可能にするために、デッドレターキュー(DLQ)を有効にします。S3 バケット名とリージョンを入力します。 Configure pipeline 一意のパイプライン名を入力します(現在の AWS アカウントの現在のリージョン内で)。 要件に応じてパイプライン容量を構成します。単一の Ingestion OpenSearch Compute Unit(OCU)は、課金可能なコンピューティングおよびメモリユニットを表します。データパイプラインの実行に使用される OCU の数に基づいて時間単位で課金されます。ベースラインとして、1 つの OCU は一般的なワークロードで最大 2 MiB/秒を処理できます。ワークロードに応じて最小および最大 OCU 容量を入力します。 OpenSearch Ingestion は、他のサービスを代理で使用するための権限が必要です。 Create and use a new service role を選択します。 ステップ 4 と同様に、OSIS パイプラインの IAM ロールを OpenSearch all_access ロールのバックエンドロールとしてマッピングします。これにより、データインジェストのための安全できめ細かいアクセス制御が可能になります。 Review and create すべての構成を確認します。 Preview pipeline を選択し、yaml ファイルを確認します。 Create Pipeline を選択してパイプラインを作成します。 図 5:OpenSearch Ingestion パイプラインの作成 検証 ゼロ ETL 統合をセットアップした後、データが複製されていることをテストおよび検証できます。 DynamoDB にサンプルアイテムを作成します。以下は、アイテムを作成するサンプルシェルスクリプトです: #!/bin/bash for i in {1..10}; do colors=("red" "white" "green" "blue" "black") sizes=("XS" "S" "M" "L" "XL") products=("Hoodie" "Jacket" "Pants" "Shorts" "Sweater" "Joggers" "Tank Top" "Polo Shirt" "Vest" "Leggings") categories=("Activewear" "Men's Wear" "Women's Wear" "Loungewear" "Outerwear") brands=("AnyCompany1" " AnyCompany2" " AnyCompany3" " AnyCompany4" " AnyCompany5" " AnyCompany6") features=("Sustainably crafted" "Eco-friendly materials" "Ethically produced" "Premium quality" "Organic materials") color=${colors[$((RANDOM % 5))]} features=${features[$((RANDOM % 5))]} size=${sizes[$((RANDOM % 5))]} category=${categories[$((RANDOM % 5))]} brand=${brands[$((RANDOM % 6))]} product_name=${products[$((i - 1))]} timestamp=$(date -u +"%Y-%m-%dT%H:%M:%SZ") aws dynamodb put-item \ --table-name Products \ --region us-east-1 \ --item "{ \"product_id\": {\"S\": \"product_$i\"}, \"name\": {\"S\": \"$brand $product_name\"}, \"description\": {\"S\": \"$features $product_name - $category\"}, \"price\": {\"N\": \"$((100 + RANDOM % 400)).99\"}, \"rating\": {\"N\": \"4.$((RANDOM % 10))\"}, \"category\": {\"S\": \"$category\"}, \"brand\": {\"S\": \"$brand\"}, \"tags\": {\"L\": [{\"S\": \"organic\"}, {\"S\": \"sustainable\"}, {\"S\": \"eco-friendly\"}]}, \"specs\": {\"M\": { \"color\": {\"S\": \"$color\"}, \"size\": {\"S\": \"$size\"}, \"weight\": {\"N\": \"0.$((RANDOM % 9 + 1))\"}, \"dimensions\": {\"S\": \"$((RANDOM % 30 + 10))x$((RANDOM % 30 + 10))x$((RANDOM % 10 + 1))\"} }}, \"stock\": {\"N\": \"$((RANDOM % 200))\"}, \"created_at\": {\"S\": \"$timestamp\"}, \"updated_at\": {\"S\": \"$timestamp\"} }" &amp;&amp; echo "✓ Created: product_id=$i" done echo "Done!" ドメインの OpenSearch Dashboards URL に移動します。URL は OpenSearch Service コンソールのドメインダッシュボードで確認できます。 左側のナビゲーションパネルを開き、 Dev Tools を選択します。 OpenSearch へのデータフローを確認します。 //すべて検索 GET products/_search { "query": { "match_all": {} } } セマンティックユースケースクエリを実行して、セマンティック要件を検証します。 GET products/_search { "query": { "neural": { "description_embedding": { "query_text": "sports", "model_id": "&lt;ステップ 5 で取得した model_id に更新&gt;" } } } } この記事の前半で提供されたクエリを使用して、他のすべてのユースケースをテストできます。 図 6:データ検証 パイプラインのセットアップを完了し、データ同期を検証した後、トランザクション操作を DynamoDB に保持しながら、検索クエリを OpenSearch Service にルーティングするようにアプリケーションコードをリファクタリングします。 具体的な実装は、アプリケーションアーキテクチャとプログラミング言語によって異なります。AWS SDK を使用して OpenSearch Service をクエリする手順については、 AWS SDK を使用した Amazon OpenSearch Service との対話 を参照してください。 ベストプラクティス DynamoDB と OpenSearch Service 間のゼロ ETL 統合を実装する際は、以下の ベストプラクティス を検討してください: OSIS パイプラインのソースオプションとして DynamoDB ストリームを使用します。これにより、完全な初期スナップショットを必要とせずに、新しいレコードまたは更新されたレコードのみがキャプチャされます。ストリーミングデータでパイプラインフローをテストしたら、エクスポートオプションを使用して完全なデータを移行します。 Amazon VPC を使用して、パブリックインターネット経由ではなく、ネットワーク境界内で OpenSearch Ingestion パイプラインを通じてデータフローを強制します。 埋め込みがすでに含まれているフィールドに対する冗長な API 呼び出しを防ぐために、 skip_existing フラグを有効にして、埋め込み生成インジェストパイプラインを最適化します。 OpenSearch Service ドメインと OpenSearch Ingestion パイプラインの Amazon CloudWatch ログ を有効にします。これにより、データフロー全体の可視性が提供され、問題を迅速に特定できます。ドメインレベルでログを構成して、検索クエリ、インデックス操作、クラスターヘルスメトリクスをキャプチャします。OpenSearch Ingestion パイプラインの場合、詳細なログを有効にして、データ変換とインジェストプロセスを監視します。 インジェストパイプラインの DLQ を構成します。マッピングエラー、変換の問題、または一時的なサービスの問題によりドキュメントの処理が失敗した場合、DLQ はこれらの失敗したレコードをキャプチャして、後で分析および再処理できるようにします。これにより、データ損失が防止され、回復メカニズムが提供されます。 AWS Key Management Service(AWS KMS) を使用して、DynamoDB テーブルと OpenSearch Service ドメインの両方で保存時の暗号化を有効にし、暗号化キーを完全に制御し、コンプライアンス要件を満たします。 DynamoDB テーブルで削除保護を有効にして、重要なデータの誤削除を防ぎ、本番ワークロードに追加の安全層を提供します。 統合パイプラインの各コンポーネントに特定の IAM ロールとポリシーを作成して、最小権限アクセスを実装し、サービスが機能するために必要な権限のみを持つようにします。 シャードサイジング、インスタンスタイプ、デプロイ構成を含む OpenSearch Service ドメインのサイジング推奨事項については、 Amazon OpenSearch Service ドメインサイジングガイド を参照してください。 モニタリングとアラート OpenSearch Ingestion は、パイプラインのパフォーマンスを監視するのに役立つメトリクスを公開します。パイプラインの健全性を監視する際は、以下の主要な領域に焦点を当ててください: データインジェストをブロックする可能性のある認証の問題。 データ損失につながる可能性のあるドキュメント処理の失敗。 データ処理を遅くする可能性のある容量のボトルネック。 アプリケーションの応答時間に影響を与えるパフォーマンスの低下。 Bedrock 固有の監視については、モデル呼び出しのレイテンシー、スロットリング、トークン使用量のメトリクスに特に注意してください。 これらの領域を積極的に監視することで、DynamoDB から OpenSearch Service への信頼性の高いデータフローを維持し、検索機能の応答性を確保できます。これらの問題を早期に検出するために CloudWatch アラートを設定し、ユーザーに影響を与える前にプロアクティブなアクションを実行できるようにします。 ログとモニタリング の詳細とベストプラクティスについては、 Amazon OpenSearch Ingestion のベストプラクティス および Amazon Bedrock モニタリング のドキュメントを参照してください。 コストに関する考慮事項 OpenSearch Ingestion を使用した DynamoDB から OpenSearch Service への統合を計画する際は、Amazon CloudWatch メトリクスを通じて DynamoDB の書き込みスループットを分析します。DynamoDB テーブルの書き込みアクティビティは DynamoDB Streams にレコードを生成し、OpenSearch Ingestion パイプラインがそれを消費します。最小、最大、平均の書き込みリクエストユニット(WRU)を理解することで、OpenSearch Ingestion パイプラインを適切にサイジングできます。この記事の執筆時点では、OpenSearch Ingestion パイプラインは 1 から 96 の OpenSearch Compute Unit(OCU)にスケーリングできます。ベースラインとして、1 つの OCU は一般的なワークロードで最大 2 MiB/秒を処理できますが、データサイズ、パイプライン変換、OpenSearch Service ドメインのサイズとインデックス/シャード戦略によって異なる場合があります。 例えば、テーブルが 1 秒あたり 20,000 WRU を処理する場合、このスループットを効率的に処理するには最低 10 OCU が必要です。総コストには、DynamoDB Streams の料金(100,000 読み取りリクエストあたり $0.02)、OpenSearch Service クラスターのコスト(インスタンスタイプとストレージに基づく)、OpenSearch Ingestion パイプラインのコスト(OCU 時間あたりの価格)、および通常の DynamoDB コストが含まれます。DynamoDB から OpenSearch パイプラインにリモート推論用の Amazon Bedrock を組み込む場合は、どのフィールドに埋め込みが必要かを評価し、処理するテキストデータの量を見積もります。レコード数、テキストフィールドのサイズ、更新頻度に基づいて、予想されるトークン使用量を計算します。コスト構造は、選択した基盤モデルによって異なるトークンごとの従量課金モデルに従います。 クリーンアップ 継続的な料金の発生を避けるために、このソリューションで作成したリソースを削除または無効化します。AWS 環境をクリーンアップするには、次の手順に従ってください: CloudFormation スタック を削除します: CloudFormation コンソールを開きます。 モデルアクセス用に作成したスタックを選択します。 Delete を選択し、削除を確認します。 OpenSearch リソースを削除します: Amazon OpenSearch Ingestion コンソールを開き、パイプラインを削除して OSIS パイプラインを削除 します。 Amazon OpenSearch Service コンソールを通じて OpenSearch ドメインを削除 します。 DynamoDB テーブル(Products)を削除します。 デッドレターキュー(DLQ)と DynamoDB エクスポートに使用した S3 バケットを空にします。 これらの手順を完了したら、各サービスコンソールで、すべてのリソースが適切に削除または無効化されていることを確認してください。 まとめ この記事では、 Amazon DynamoDB データに対する検索を Amazon OpenSearch Service との ゼロ ETL 統合を使用して実装する方法を紹介しました。 AnyCompany の例を通じて、この統合が実際の検索課題(顧客のタイプミスやセマンティッククエリの処理から、ファセット検索やマルチフィールド検索の有効化まで)にどのように対処するかを実証しました。 Amazon OpenSearch Service ドキュメント と DynamoDB ゼロ ETL 統合ガイド を探索して、独自の環境でこれらの機能の実装を開始してください。 本記事は 2026 年 02 月 18 日 に公開された “Implementing search on Amazon DynamoDB data using zero-ETL integration with Amazon OpenSearch service” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/implementing-search-on-amazon-dynamodb-data-using-zero-etl-integration-with-amazon-opensearch-service/ 著者について Varun Sharma Varun は、AWS Professional Services チームで働くシニアデリバリーコンサルタントです。 Vamsi Krishna Ganti Vamsi は、AWS Professional Services チームで働くシニアデリバリーコンサルタントです。 Sudhansu Mohapatra Sudhansu は、AWS Professional Services チームで働くデリバリーコンサルタントです。
アバター
2021 年に AWS に入社して以来、私は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスファミリーが成長するのを見てきました。そのペースは今でも驚きを隠せません。AWS Graviton 搭載のインスタンスから、特殊な高速コンピューティングオプションまで、パフォーマンスの限界をさらに押し上げる新しいインスタンスタイプが数か月ごとにリリースされているように感じられます。2026 年 2 月の時点で、AWS は 1,160 を超える Amazon EC2 インスタンスタイプを提供しており、その数は今も増え続けています。 2026 年 2 月 16 日週最初のニュースである Amazon EC2 M8azn インスタンスの一般提供はその良い例です。M8azn インスタンスは、第 5 世代 AMD EPYC プロセッサを搭載した高周波で高ネットワークの汎用インスタンスであり、クラウド内で最も高い 5 GHz の最大 CPU 周波数を提供しています。前世代の M5zn インスタンスと比較した場合、M8azn インスタンスは最大 2 倍優れたコンピューティングパフォーマンス、4.3 倍広いメモリ帯域幅、10 倍大きい L3 キャッシュを提供します。また、M5zn より最大 2 倍のネットワークスループット、最大 3 倍の Amazon Elastic Block Store (Amazon EBS) スループットも提供します。 第 6 世代の Nitro Card を使用して AWS Nitro System 上に構築された M8azn インスタンスは、自動車、航空宇宙、エネルギー、電気通信分野におけるリアルタイム財務分析、ハイパフォーマンスコンピューティング、高頻度取引、CI/CD パイプライン、ゲーム、シミュレーションモデリングなどのワークロード向けです。このインスタンスでは、メモリと vCPU の比率が 4:1 になっており、2 個から 96 個の vCPU 数、最大 384 GiB のメモリを搭載した 9 種類のサイズ (2 種類のベアメタルタイプを含む) で利用できます。詳細については、 Amazon EC2 M8azn インスタンスページ をご覧ください。 2026 年 2 月 9 日週のリリース 以下は、2026 年 2 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock が 6 つのフルマネージドオープンウェイトモデルのサポートを追加 – Amazon Bedrock が、DeepSeek V3.2、MiniMax M2.1、GLM 4.7、GLM 4.7 Flash、Kimi K2.5、Qwen3 Coder Next のサポートを開始しました。これらのモデルは、フロンティア推論とエージェンティックコーディングのワークロードに対応します。DeepSeek V3.2 と Kimi K2.5 は推論とエージェンティックインテリジェンスを対象としており、GLM 4.7 と MiniMax M2.1 は大規模な出力ウィンドウでの自律コーディングをサポートし、Qwen3 Coder Next と GLM 4.7 Flash は本番環境デプロイ用のコスト効率に優れた代替手段を提供します。Project Mantle を活用するこれらのモデルは、OpenAI API 仕様との設定不要の互換性を提供します。&nbsp;このリリースにより、仕様主導型の AI 開発ツールである Kiro での DeepSeek v3.2、MiniMax 2.1、Qwen3 Coder Next といった新しいオープンウェイトモデルの使用も可能になります。 Amazon Bedrock が AWS PrivateLink のサポートを拡大 – Amazon Bedrock が、 bedrock-runtime エンドポイントの既存サポートに加えて、 bedrock-mantle エンドポイントでも AWS PrivateLink をサポートするようになりました。bedrock-mantle エンドポイントは、Amazon Bedrock で提供される大規模な機械学習モデル用の分散型推論エンジンである Project Mantle を活用しています。Project Mantle は、サービス品質制御を備えたサーバーレス推論、自動化されたキャパシティ管理によって引き上げられたデフォルトカスタマークォータ、OpenAI API 仕様との設定不要の互換性を提供します。OpenAI API 互換エンドポイントの AWS PrivateLink サポートは、14 の AWS リージョンでご利用いただけます。使用を開始するには、Amazon Bedrock コンソールにアクセスするか、OpenAI API 互換性ドキュメントを参照してください。 Amazon EKS Auto Mode がマネージド Kubernetes 機能のための強化されたロギング機能を発表 – Amazon EKS Auto Mode で Amazon CloudWatch Vended Logs を使用するログ配信ソースを設定できるようになりました。これは、Auto Mode のマネージド Kubernetes 機能からコンピューティングの自動スケーリング、ブロックストレージ、負荷分散、ポッドネットワーキングに関するログを収集するために役立ちます。各 Auto Mode 機能は、AWS 認証と承認が組み込まれた CloudWatch Vended Logs 配信ソースとして、標準の CloudWatch Logs よりも低い料金で設定できます。ログは、CloudWatch Logs、Amazon S3、または Amazon Data Firehose を宛先として配信できます。この機能は、EKS Auto Mode が提供されているすべてのリージョンでご利用いただけます。 Amazon OpenSearch Serverless がコレクショングループのサポートを開始 – 新しいコレクショングループを使用して、異なる AWS Key Management Service (AWS KMS) キーを持つコレクションの全体で OCU (OpenSearch Compute Unit) を共有できるようになりました。コレクショングループは、コレクションレベルのセキュリティとアクセス制御を維持しながら、共有コンピューティングモデルを通じて全体的な OCU コストを削減します。また、最大 OCU 制限に加えて最小 OCU 割り当てを指定することも可能になったため、遅延の影響を受けやすいアプリケーションの起動時におけるベースラインキャパシティが保証されます。コレクショングループは、現在 Amazon OpenSearch Serverless が提供されているすべてのリージョンでご利用いただけます。 Amazon RDS がスナップショットの復元時におけるバックアップ設定のサポートを開始 – スナップショット復元操作の実行前と実行中にバックアップ保持期間と希望するバックアップウィンドウを表示し、変更できるようになりました。これまで、復元されたデータベースインスタンスとクラスターはスナップショットメタデータからのバックアップパラメータ値を継承し、変更できるのは復元完了後のみでした。これからは、自動バックアップとスナップショットの一部としてバックアップ設定を表示し、復元時にこれらの値を指定または変更できるようになるため、復元後に変更する必要がなくなります。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンにあるすべての Amazon RDS データベースエンジン (MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2) と Amazon Aurora (MySQL 互換および PostgreSQL 互換エディション) で利用でき、追加料金はかかりません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS AI and Data Conference 2026 – 3 月 12 日にアイルランドの Lyrath Convention Centre で開催される、1 日限りの無料対面イベントです。このカンファレンスでは、Amazon Bedrock、Amazon SageMaker、QuickSight を用いたエージェントの設計、トレーニング、およびデプロイの他、エージェントの AWS データサービスとの統合、エージェントを大規模に運用するためのガバナンスプラクティスの適用といったトピックを取り上げます。アジェンダには、アーキテクト、開発者、ビジネスリーダー向けの戦略的ガイダンスとハンズオンラボが含まれています。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。このイベントは、 アーメダバード (2 月 28 日)、 スロバキア (3 月 11 日)、 プネー (3 月 21 日) で開催される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧ください。 2026 年 2 月 16 日週のニュースは以上です。2026 年 2 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。
アバター
ウェブサイトのパフォーマンス問題はよくあることですが、根本原因の特定は困難な作業となります。この投稿では、 Server-Timing ヘッダー の潜在能力を引き出すことで、パフォーマンスに関するトラブルシューティングのプロセスをシンプルにする方法を学びます。 Server-Timing ヘッダーは、バックエンドのコンポーネントがユーザーリクエストへのレスポンスにおいて、タイミングメトリクスやパフォーマンスモニタリングに関するインサイトを伝達できるようにします。 ウェブサイトのアクセスでは、画像変換などのコンテンツ最適化やデータベースからの動的なデータ取得を含んだ、複雑なサーバーサイドのプロセスが関与しています。遅いリクエストの原因となるサーバーやプロセスを特定するには、複数のログを突き合わせて分析する必要があり、時間がかかってしまいます。このプロセスをシンプルにすることで迅速に問題を解決できます。具体的には、ユーザー体験の品質シグナルとサーバーサイドのパフォーマンス指標とを直接関連付けて、単一のログ行内にカプセル化することで実現します。この方法は、広範なデータクエリや相関分析が不要であり、パフォーマンス問題を素早く特定し、原因となるサーバーコンポーネントまで追跡することを可能にします。このアプローチの実例として Common Media Client Data(CMCD) が挙げられます。 CMCD は動画ストリーミング業界で最近生まれた革新的な技術で、クライアントおよびサーバー両方のオブサーバビリティデータを単一のリクエストログ行にシームレスに統合するものです。ウェブサイトにおいては、 Server-Timing ヘッダーを実装することで同様の方式を採用できます。サーバーサイドのメトリクスとクライアントサイドで利用可能なメトリクスとを効果的に統合し、特定のリクエスト-レスポンスサイクルのパフォーマンスを包括的に把握するのです。 私たちが提案するソリューションは 2 つのパートで構成されます。第一に、エンドユーザーのレイテンシを測定してパフォーマンス問題を特定すること、第二に、そうした問題が発生した際にサーバーのインサイトに即座にアクセスすることです。 まず前者を取り上げてから、 Server-Timing の実装について掘り下げていきましょう。 パフォーマンス問題の検出 ウェブサイトのパフォーマンスはレイテンシに大きく依存します。レイテンシとは、ユーザーアクション(リンクのクリックやフォームの送信など)とサーバーからのレスポンスとの間の時間遅延を指します。ウェブサイトにおけるレイテンシは、通常 Time to First Byte ( TTFB )、別名 First Byte Latency ( FBL )の形式で測定されます。これは、ウェブサイトのコンテンツがユーザーの画面に描画され始めるまでの速さを測定したもので、 First Contentful Paint ( FCP )や Largest Contentful Paint ( LCP )などの Core Web Vitals シグナルに直接影響します。シームレスなユーザー体験を確保するには、 TTFB を 800 ミリ秒以下に維持することが 推奨されています 。このベンチマークは、遅いリクエストを特定するための有用な閾値として機能します。 Amazon CloudFront のようなサービスを活用することで、静的および 動的コンテンツ 両方の TTFB の改善に役立ちます。 クライアントサイドの視点で TTFB を測定する際は、ユーザーのリクエスト開始時点から、サーバーからのレスポンスの最初のバイト受信時点までの時間を対象範囲とします。この計算には、ネットワーク伝送時間やサーバーサイドでのすべての処理時間が含まれており、ウェブサイトのアーキテクチャに応じて、コンテンツ配信ネットワーク( CDN )の処理、オリジンサーバーの処理、データベースのクエリ、およびその他のリクエスト処理タスクなどが含まれます。サーバーサイドの視点で TTFB を測定する場合は、 サーバーがリクエストを受信してから、レスポンスの最初のバイトをネットワーク層に送出する時点までの時間を対象範囲とします。このとき、ネットワーク転送時間は含まれず、 TTFB はレスポンスを開始する前のサーバーの処理時間を本質的に示します。さらに、リクエストフローの途中にサーバーが位置するシナリオでは、サーバーは二重の役割を果たします。一つはダウンストリームからのリクエストを受信するサーバーとして、もう一つはアップストリームの他のサーバーにリクエストを転送するクライアントとして機能するのです。この動作モデルは、 Amazon CloudFront のような CDN 内のサーバーにおいて一般的であり、そのようなサーバーではクライアントサイドとサーバーサイドの両方の TTFB メトリクスが存在することになります。 CloudFront とエッジ関数、 Application Load Balancer 、ウェブサーバー、データベースなどのコンポーネントを含む典型的なウェブサイトアーキテクチャでは、リクエストからレスポンスまでのサイクルは図 1 に示すように進行します。 図 1. 典型的なウェブサイトアーキテクチャにおけるリクエスト-レスポンスサイクルのタイミング 図 1 では、リクエストとレスポンスの開始と終了のそれぞれのタイムスタンプを T を用いて表しています。これらのタイムスタンプを使用して、様々な TTFB を以下のように計算します: ユーザー TTFB は T1 から T18 までの時間間隔です。ユーザーエクスペリエンスをモニタリングし、推奨値を超えた時の問題特定をするために測定すべき指標です。ユーザー TTFB が短いほど、レスポンスが速く、良いユーザーエクスペリエンスであることを示しています。 CloudFront ダウンストリーム TTFB は T2 から T17 までの時間間隔です。キャッシュヒット、つまり、オリジンでの処理を必要とせず CloudFront キャッシュからリクエストが処理される場合には、 TTFB は CloudFront がリクエストを処理してレスポンスを準備するのにかかった時間のみを示します。エッジ関数を使用するのであれば、その実行時間も含まれます。ただし、キャッシュミスの場合には、オリジンがリクエストを処理してレスポンスを準備するまでにかかった時間と、オリジンから CloudFront へレスポンスを転送する時間が追加されます。 CloudFront アップストリーム TTFB は T3 から T14 までの時間間隔です。これは、CloudFront がリクエストをオリジンに送信し、レスポンスを受信するまでのキャッシュミスの場合を表しています。 CloudFront と同様に、オリジン側のシステム内のすべてのサーバーも独自の TTFB を持っています。たとえば、HTML ページを生成するためにデータベースクエリを実行する場合に、T7 から T10 までの時間間隔として、データベース処理時間と伝送時間の両方を測定します。 アップストリームのコンポーネントからダウンストリームへの伝送時間は、ダウンストリーム TTFB からアップストリーム TTFB を引いた値で推定できます。たとえば、CloudFront からユーザーへの最初のバイトの伝送時間は、ユーザー TTFB から CloudFront ダウンストリーム TTFB を引いて計算できます。伝送時間が短いほど、ネットワーク状態が良好で、距離が短いことを示します。 ブラウザ内の JavaScript を使用してユーザー TTFB を測定するには、 Resource Timing API が使用できます。この API では、リクエストの開始時刻、DNS 解決時間、TCP および TLS ハンドシェイク、レスポンスの最初のバイトの受信といったリソースの読み込みに関わるさまざまな段階のタイムスタンプを取得できます。これにより、TTFB の計算やリソースの読み込みに関連するその他の有用なタイミング情報の取得が容易になります。 const timings = {}; new PerformanceObserver((entryList) =&gt; { const entries = entryList.getEntries(); entries.forEach(entry =&gt; { if (entry.responseStart &gt; 0) { timings.userDNS = (entry.domainLookupEnd - entry.domainLookupStart).toFixed(2); timings.userTCP = (entry.connectEnd - entry.connectStart).toFixed(2); timings.userTLS = (entry.requestStart - entry.secureConnectionStart).toFixed(2); timings.userTTFB = (entry.responseStart - entry.requestStart).toFixed(2); } }); }).observe({ type: 'resource', buffered: true }); このコードスニペットは、ウェブページから読み込まれた各リソースの DNS、TCP、TLS、および TTFB のタイミングを取得しています。同様に、 Navigation Timing API を使用して、ブラウザ内のナビゲーションリクエストに対してこれらのタイミングを取得できます。このデータを使用すると、レイテンシが許容範囲内かどうかを判断できるだけでなく、リクエストの DNS、TCP、TLS 各段階の所要時間を分析することもできます。これらのメトリクスは、パケットが移動することになるユーザーとフロントエンドサーバー間のネットワーク距離や、ネットワークの輻輳状態に影響を受けます。これらの値が大きく、800 ミリ秒のベンチマークに近づいている場合は、よりスムーズなユーザーエクスペリエンスのためにネットワーク状態を改善する必要があることを示しています。 CloudFront は、エッジロケーションでユーザーに近い場所でリクエストを終端することにより、ネットワークパフォーマンスを大幅に向上させることができます。 しかし、サーバーサイドが原因のパフォーマンス問題はこのデータでは可視化できません。そこで Server-Timing が役立ちます。 Server-Timing の実装 あらゆるウェブサーバーでは HTTP レスポンスに Server-Timing ヘッダーを含めることができ、サーバーメトリクスを提供します。このヘッダーはすべてのモダンブラウザでサポートされており、 PerformanceServerTiming インターフェースを使用してメトリクスを簡単に解析および取得できます。 CloudFront はすでに Server-Timing をサポートしており、処理に関連するメトリクスを伝達できます。たとえば、cdn-downstream-fbl メトリクスは前述した CloudFront ダウンストリーム TTFB であり、 cdn-upstream-fbl は CloudFront アップストリーム TTFB です。その他の利用可能なメトリクスとその説明については、 開発者ガイド で確認できます。 CloudFront で Server-Timing を有効化するには、 レスポンスヘッダーポリシー を作成します。 Server-Timing ヘッダーパネルの「有効」オプションを切り替え、サンプリングレートを指定します。他のレスポンスヘッダーの追加または削除も必要に応じて設定します。CloudFront の Server-Timing 機能により、CloudFront がリクエストを十分な速さで処理できているかを評価できます。キャッシュヒットの場合、 cdn-downstream-fbl メトリクスの値は小さくなり、これは CloudFront が迅速にレスポンスを開始したことを示します。逆に、このメトリクスの値が大きい場合は、処理が遅いことを示唆し、CloudFront 側に問題があることを示します。キャッシュミスの場合には、 cdn-upstream-connect と cdn-upstream-dns メトリクスを確認して CloudFront からオリジンへの接続時間の値も評価します。これらのメトリクスの値が小さい場合は、リクエストフローにおける次のサーバー(図 1 に示されている Application Load Balancer など)が正常に稼働しており、接続を素早く確立し、CloudFront のオリジン向けサーバーの近くに配置されていることを示唆しています。たいていの場合、 cdn-upstream-connect や cdn-upstream-dns の値は 0 になります。なぜならば、CloudFront の 持続的接続 機能が以前に確立された接続を再利用しているからです。 cdn-upstream-fbl メトリクスは、オリジンからのレスポンスの最初のバイトが CloudFront に到達する速さを示します。このメトリクスの値が大きく、 cdn-upstream-connect と cdn-upstream-dns の値が小さい場合は、 Application Load Balancer の後段にあるオリジン側のシステムに問題が発生し、速いレスポンスを提供できていないことを示します。理想的には、これらのメトリクスがユーザーの経験するレイテンシ(ユーザー TTFB )に大きく影響を与えてはいけません。 CloudFront の Server-Timing ヘッダーは、 CloudFront のダウンストリーム・アップストリーム両方のパフォーマンスに関するインサイトを提供しますが、リクエスト中にオリジンで何が起こったかを直接教えてはくれません。複数の異なるコンポーネントやテクノロジーで構成される現代のオリジンアーキテクチャの多様性を鑑みれば、包括的な理解のためには、それぞれのパフォーマンスタイミング情報を組み込むことが不可欠です。オリジンサーバーからインサイトを抽出するには、オリジンからの CloudFront へのレスポンスに Server-Timing ヘッダーを独自に実装して含めることができます。 CloudFront がこのヘッダーを置き換えることはありません。代わりに、オリジンから受信した Server-Timing ヘッダーに CloudFront が自身のメトリクスを追加します。独自で実装する Server-Timing ヘッダーに含めるタイミングメトリクスとしては、画像の最適化、 API 呼び出し、データベースのクエリ、エッジコンピューティングなどの重要なバックエンドプロセスの測定値が考えられます。たとえば、 PHP を使用してデータベースクエリを実行している場合、次のようにしてクエリの所要時間を測定できます。 $dbReadStartTime = hrtime(true); // Database query goes here $dbReadEndTime = hrtime(true); $dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1000000; header('Server-Timing: my-query;dur=' . $dbReadTotalTime); こちらのコードスニペットでは、データベース操作の完了にかかった時間を取得し、 Server-Timing ヘッダー内で my-query メトリクスとして伝達しています。データベースは時に過負荷状態になり、パフォーマンスのボトルネックとなることがあるため、このデータはそのようなシナリオを明らかにするのに役立ちます。 Node.js を使用している場合は、 PerformanceServerTiming インターフェース仕様の 例 を参考にして、 Server-Timing ヘッダーを実装してください。 エッジ関数 によって追加になるレイテンシも Node.js を使用している場合と同様の実装で測定を行います。ネットワーク呼び出しを含んだ複雑な処理を行う Lambda@Edge 関数では特に有益です。以下の例では、オリジンレスポンスイベントにアタッチされた Lambda@Edge 関数で Server-Timing ヘッダーの実装をしています: import json import time # CF headers are available in request object for Lambda@Edge functions attached to origin response event only def lambda_handler(event, context): # Get function's start timestamp handler_start_time = time.time() response = event['Records'][0]['cf']['response'] request = event['Records'][0]['cf']['request'] server_timing_value = [] # List of CloudFront headers to include in server timing for additional inisghts cf_headers = ['cloudfront-viewer-country', 'cloudfront-viewer-city', 'cloudfront-viewer-asn'] # Iterate over each header name and construct the value for the Server-Timing header for header_name in cf_headers: if header_name in request['headers']: header_value = request['headers'][header_name][0]['value'] server_timing_value.append('{}; desc="{}"'.format(header_name, header_value)) # Function's logic goes here # Get function's stop timestamp handler_stop_time = time.time() handler_duration = round((handler_stop_time - handler_start_time) * 1000, 2) server_timing_value.append('{}; dur={}'.format("my-function", handler_duration)) if server_timing_value: # Construct the Server-Timing header server_timing = [{ "key": "Server-Timing", "value": ', '.join(server_timing_value) }] # Add or append the Server-Timing header if 'server-timing' in response['headers']: response['headers']['server-timing'][0]['value'] += ', ' + ', '.join(server_timing_value) else: response['headers']['server-timing'] = server_timing print("Server-Timing:", response['headers']['server-timing']) return response 注目すべき点として、このコードで追加されるメトリクスは、ハンドラーコードの実行時間のみであり、その他の Lambda のタイミングは除外されています。なお、オリジンアーキテクチャの情報が悪意のある攻撃者に悪用されるおそれがあるため、メトリクスには意図的に抽象的な名前を使用しています。 また、ユーザーの地理的位置情報と ASN 番号に関するインサイトを Server-Timing ヘッダーに追加したことにも注目すべき点です。 そして、 クライアントサイドでも Server Timing を取得できるように serverTiming プロパティを使用してコードを拡張します。以下が修正されたコードスニペットとなります。 // Creating a new PerformanceObserver to monitor performance entries new PerformanceObserver((entryList) =&gt; { const entries = entryList.getEntries(); for (const entry of entries) { // Object to store timings for various stages const timings = { userDNS: null, // User DNS resolution time userTCP: null, // User TCP handshake time userTLS: null, // User TLS handshake time CFDNS: null, // CDN DNS resolution time CFUpstreamHandshake: null, // CDN upstream TCP handshake time MyQuery: null, // Query time CFUpstreamTTFB: null, // CDN upstream Time To First Byte (TTFB) MyFunction: null, // Function execution time CFDownstreamTTFB: null, // CDN downstream TTFB userTTFB: null, // User Time To First Byte (TTFB) CFRID: null, // CDN Request ID CFCacheStatus: null, // CDN Cache status (Hit or Miss) UserASN: null // User Autonomous System Number (ASN) }; // Iterating through server timing entries for the current performance entry entry.serverTiming.forEach((serverEntry) =&gt; { switch (serverEntry.name) { case 'cdn-rid': timings.CFRID = serverEntry.description; break; case 'cdn-cache-miss': timings.CFCacheStatus = "Miss"; break; case 'cdn-cache-hit': timings.CFCacheStatus = "Hit"; break; case 'cdn-upstream-connect': timings.CFUpstreamHandshake = serverEntry.duration; break; case 'cdn-downstream-fbl': timings.CFDownstreamTTFB = serverEntry.duration; break; case 'cdn-upstream-dns': timings.CFDNS = serverEntry.duration; break; case 'cdn-upstream-fbl': timings.CFUpstreamTTFB = serverEntry.duration; break; case 'my-query': timings.MyQuery = serverEntry.duration; break; case 'my-function': timings.MyFunction = serverEntry.duration; break; case 'cloudfront-viewer-asn': timings.UserASN = serverEntry.description; break; } }); // Calculating user-specific timings if the response not served from the local cache if (entry.responseStart &gt; 0) { timings.userDNS = (entry.domainLookupEnd - entry.domainLookupStart).toFixed(2); timings.userTCP = (entry.connectEnd - entry.connectStart).toFixed(2); timings.userTLS = (entry.requestStart - entry.secureConnectionStart).toFixed(2); timings.userTTFB = (entry.responseStart - entry.requestStart).toFixed(2); // Logging metrics for the current entry console.log("Metrics for:", entry.name); console.log("userDNS:", timings.userDNS); console.log("userTCP:", timings.userTCP); console.log("userTLS:", timings.userTLS); console.log("CFDNS:", timings.CFDNS); console.log("CFUpstreamHandshake:", timings.CFUpstreamHandshake); console.log("DBQuery:", timings.MyQuery); console.log("CFUpstreamTTFB:", timings.CFUpstreamTTFB); console.log("lambdaEdge:", timings.MyFunction); console.log("CFDownstreamTTFB:", timings.CFDownstreamTTFB); console.log("userTTFB:", timings.userTTFB); console.log("CFRID:", timings.CFRID); console.log("CFCacheStatus:", timings.CFCacheStatus); console.log("UserASN:", timings.UserASN); console.log("------------------------------------------------------"); } } }).observe({ type: 'resource', // Observing resource-related performance entries buffered: true }); この改良されたコードスニペットでは、Server Timing を取得したのちに、クライアントメトリクスと共に timings オブジェクトに統合しています。これにより、クライアントサイドとサーバーサイドの両方のリクエスト – レスポンスサイクルにおける包括的なパフォーマンスのインサイトを一箇所にまとめることができました。以下は console.log の出力例です。 Metrics for: https://d1234.cloudfront.net/script.php userDNS: 0.00 userTCP: 0.00 userTLS: 5.00 CFDNS: 0 CFUpstreamHandshake: 88 DBQuery: 0.538685 CFUpstreamTTFB: 178 lambdaEdge: 0.09 CFDownstreamTTFB: 229 userTTFB: 233.10 CFRID: mRq-Uvr__3OBDo0IX9ELV5Lrk3lF-bOp4eOIqTEXlFkFn0wIWPKgpA== CFCacheStatus: Miss UserASN: 1257 この例を見てみましょう。 CloudFront の Lambda@Edge 関数の実行と、オリジンサーバーのデータベースクエリの両方を合わせて、最初のバイトをネットワークに送信するまでに 229 ミリ秒かかりました( CFDownstreamTTFB )。最初のバイトは 233 ミリ秒後にクライアントデバイスに到達しているので( userTTFB )、伝送時間は 4 ミリ秒であることを示しています。クライアントデバイスは、以前に確立された TCP および TLS 接続を再利用しており( userTCP 、 userTLS )、 CloudFront の IP アドレスをキャッシュしていました( userDNS )。 CloudFront はオリジンに向けて新しい TCP 接続を確立する際( CFUpstreamHandshake )、 88 ミリ秒かかりました。オリジンはリクエストを 90 ミリ秒以内( CFUpstreamTTFB – CFUpstreamHandshake )で処理しており、素早くレスポンスの最初のバイトを返していることがわかります。結論として、エンドユーザーの全体的なレイテンシは推奨値の 800 ミリ秒を下回っており、満足のいくものであると言えます。 Server-Timing を他のデータで拡充する Server-Timing ヘッダーは、サーバーサイドの処理時間を伝達するために設計されたものですが、その構文は単にその用途に限定されたものではありません。たとえば、CloudFront ではキャッシュのステータスや内部のユニークなリクエスト ID をメトリクスに含んでいます。これらのデータは CloudFront の処理を正確に分析するために不可欠なものです。同様にして、リクエストの経路に関してインサイトを提供するメトリクスを加えて、 Server-Timing ヘッダーを独自に拡充することができます。たとえば、ログを見つけやすくするために、クラスター内のサーバーの内部 ID を追加することもできます。ユーザーの地理的位置情報やデバイスタイプも追加はできますが、 CloudFront のヘッダー の使用で実現できます。先述の Lambda@Edge 関数で使用方法を示した通りです。これらのヘッダーは、オリジンレスポンスイベントに関連付けられた Lambda@Edge 関数、もしくは、ビューワーレスポンスイベントやビューワーリクエストイベントに関連付けられた CloudFront 関数のリクエストオブジェクトで利用できます。オリジンリクエストポリシーでこれらのヘッダーを有効化すると、 オリジンウェブサーバーが CloudFront からのリクエストに含まれるこれらのヘッダーを取り扱えるようになります。こうして、拡充されたメトリクスを Server-Timing ヘッダーに統合するのです。 Amazon CloudWatch で結果を分析する Server-Timing ヘッダーは、パフォーマンス問題を特定し、根本原因を突き止めるのに有用ですが、ウェブサイトパフォーマンスの他の重要な側面に関するインサイトは提供しません。たとえば、JavaScript 実行に関連するエラーや、累積レイアウトシフト( Cumulative Layout Shift )などの特定の Web Vitals メトリクスは、このソリューションでは直接キャプチャされません。もしすでにリアルユーザーモニタリング( RUM ) ベースのウェブサイトモニタリングソリューションを利用しているのであれば、 Server-Timing ヘッダーを統合することで、 既存の手法を置き換えたり、パフォーマンスモニタリングを Server-Timing のみに限定したりするのではなく、既存の手法を補完できます。包括的なウェブサイトモニタリングソリューションの一例として Amazon CloudWatch RUM があります。 CloudWatch RUM のインサイトを前述の手法で拡張するには、 Server-Timing ヘッダーから抽出したメトリクスを取得する カスタムイベント を作成し、 CloudWatch RUM クライアント経由で CloudWatch に送信します。このアプローチにより、すべての CloudWatch RUM のインサイトと Server-Timing を同じサービス内に統合し、両方のデータセットをシームレスに分析できるようになります。 前述のコードスニペットについて、 Server-Timing ヘッダーから抽出したデータとクライアントサイドの測定値を使用して、CloudWatch RUM クライアントを介してカスタムイベントを記録する方法の例を以下に示します: // Sending performance data to a remote server cwr('recordEvent', { type: 'my-server-timing', data: { current_url: entry.name, ...timings // Spread operator to include all timings } }); この例では、 timings オブジェクトのすべてのプロパティと値を、 cwr 関数 に送信される data オブジェクトに含めています。これは、特定のエントリに対してキャプチャされたすべてのタイミングが、 current_url と共に送信されることを意味します。 カスタムイベントは CloudWatch Logs に記録され、CloudWatch Logs Insights を使用してクエリを実行できます。さらに、 メトリクスフィルター を使用して CloudWatch メトリクスを作成して、モニタリング目的のメトリクスアラームを設定することができます。 上記のコードで収集しているタイミングのカスタムメトリクス実装の例を以下に示します: { "event_timestamp": 1710929230000, "event_type": "my-server-timing", "event_id": "9ae82980-4bfb-47f5-8183-b241379e09e1", "event_version": "1.0.0", "log_stream": "2024-03-20T03", "application_id": "c27d1cef-e531-45ad-9bc4-8e03a716c775", "application_version": "1.0.0", "metadata": { "version": "1.0.0", "browserLanguage": "en", "browserName": "Chrome", "browserVersion": "123.0.0.0", "osName": "Mac OS", "osVersion": "10.15.7", "deviceType": "desktop", "platformType": "web", "pageId": "/", "interaction": 0, "title": "TTFB Demo", "domain": "d1234.cloudfront.net", "aws:client": "arw-script", "aws:clientVersion": "1.17.0", "countryCode": "SE", "subdivisionCode": "AB" }, "user_details": { "sessionId": "c9d2514a-8884-4b32-aec0-25203f213f84", "userId": "0f7f2bf3-c9b7-46ab-bc9e-2ff53864ea74" }, "event_details": { "current_url": "https://d1234.cloudfront.net/getmeal.php", "userDNS": "0.00", "userTCP": "0.00", "userTLS": "9.50", "CFDNS": 0, "CFUpstreamHandshake": 90, "MyQuery": 0.517874, "CFUpstreamTTFB": 180, "MyFunction": 0.12, "CFDownstreamTTFB": 233, "userTTFB": "239.30", "CFRID": "ujYncZYVJeIOk6fI7ApFuNt-mJoh8hfL3nZPgAj77z7RdtSzNMTcqQ==", "CFCacheStatus": "Miss", "UserASN": "1257" } } このメトリクスに基づいて、ユーザー TTFB のメトリクス用に以下のフィルターパターンを作成できます: { $.event_details.userTTFB= * &amp;&amp; $.event_details.CFCacheStatus= * &amp;&amp; $.event_details.UserASN= * &amp;&amp; $.metadata.countryCode=*} これにより、国コード、 ASN 番号、 CloudFront キャッシュステータスなどのディメンションを持つユーザー TTFB のメトリクスを作成できます。その後、このメトリクスに対してアラートを作成し、推奨される 800 ミリ秒などの事前定義された静的な閾値を超えた場合に通知を受け取ることができます。また、 CloudWatch 異常検出 を利用することもできます。 最適化とコスト 重要なこととして、Server-Timing ヘッダーがレスポンスサイズを増加させる点を認識してください。これは、 CloudFront のデータ転送アウトに関するコストや、分析システム内でのデータの保存や処理に影響を与える可能性があります。たとえば、前述の Server-Timing ヘッダーの値は約 350 バイトに相当しますが、仮に 100 万リクエストを仮定した場合、追加で 0.325 ギガバイトのデータを転送することになります。ウェブサイトが受信するリクエスト数によっては、これが大きなコストになる場合とならない場合があります。ただし、 Server-Timing に必須情報、特にアクション可能なデータのみを含めることで、このコストを削減できます。たとえば、主にパフォーマンス低下の検出に Server-Timing が必要な場合は、推奨しきい値である 800 ミリ秒を超えるリクエストにのみ追加することを選択できます。さらに、インタラクティブフォームや API 呼び出しなど、ウェブサイト上の重要なリソースの読み込みにのみ適用することで、使用量を最小限に抑えることもできます。これには、クライアントサイドの JavaScript コードで該当するメトリクスに必要なフィルターを実装することで実現できます。 まとめ この投稿では、ウェブサイトパフォーマンスモニタリングにおける TTFB の重要性を探求し、リクエスト-レスポンスサイクルにおいて詳細なインサイトを提供する Server-Timing ヘッダーの活用方法を実証しました。レイテンシの測定とサーバーサイドメトリクス( CloudFront の処理時間、オリジンサーバーのレスポンス時間など)の取得により、ウェブサイトの所有者はパフォーマンス問題の根本原因を特定し、ウェブサイトの最適化に向けた積極的な対策を講じることができます。 本記事は「 How to identify website performance bottlenecks by measuring time to first byte latency and using Server-Timing header 」と題された記事の翻訳となります。 翻訳はプロフェッショナルサービスの 鈴木(隆) が担当しました。
アバター
AI コーディングアシスタントに簡単なこと、例えば関数名の変更やファイルの移動を依頼すると、突然復旧作業に追われることがあります。インポートが壊れたり、参照が存在しないファイルを指したりします。5 分前にコンパイルできていたコードベースが、至る所でエラーを投げ始めます。20 秒で終わるはずのリファクタリングが、5 分間のデバッグとクリーンアップセッションに変わってしまうのです。 エージェントにとってリファクタリングが難しい理由 リファクタリングは単なる大規模な検索置換ではありません。コードベースのセマンティック構造全体にわたるグラフトラバーサル問題なのです。関数名を変更すると、変更は連鎖します。ワークスペース全体のすべての呼び出し箇所、それを参照する型定義とインターフェース、import/export 文、テスト、そして(オプションで)ドキュメントとコメント。ファイルの移動はさらに複雑な波及効果を引き起こし、すべての依存ファイルのインポートパス、バレルファイル( index.ts )と再エクスポート、 tsconfig パスやバンドラー設定に組み込まれたモジュール解決の前提、Webpack 設定のような散在する設定ファイルなどに影響します。ここに根本的なミスマッチがあります。LLM はパターンマッチングを通じてもっともらしいコードを生成することに優れていますが、リファクタリングは もっともらしさよりも精度 を要求します。これは創造的なタスクではなく、シンボルの関係、言語固有のセマンティクス、プロジェクトの依存関係グラフの正確な理解を必要とする制約充足問題なのです。「正しく見える」が、深くネストさ れたモジュールの 1 つのインポートを見逃したエージェントは、単に小さなエラーを犯しただけではありません。本番環境まで表面化しないランタイム障害を導入したのです。これが、どれほど洗練されていたとしても、テキスト生成が構造的なコード変換において信頼性に欠けるツールである理由です。 問題:エージェントが効率的ではなく、非効率に動作するとき 多くの AI エージェントがリファクタリングでつまずくのは、 構造的 な編集を テキスト 編集として扱うからです。開発者が直面し続けている失敗モードをいくつか紹介します。 依頼内容: 「このメソッドの名前を変更して」 従来の失敗: エージェントはメソッド定義を更新しましたが、プロジェクト全体の呼び出し箇所を見逃しました。プロンプトで参照を更新するよう明示的に依頼した場合でも、プロセスは遅くエラーが発生しやすいループになりました。古い名前を検索して置換するのです。このプロンプトを考えてみましょう。 expression.js の get_loose_identifier を、それが何をするかをよりよく反映するように名前変更してください。このシンボルの名前変更は 4 つのファイルに伝播し、8 つの参照と 3 つのインポートに影響します。次の図の左側(従来のアプローチ)は、専用のリファクタリングツールなしでこの操作がどのように展開されるかを示しています。最初のファイル( expression.js )でシンボルの名前を変更した後、エージェントはコードベースで get_loose_identifier を検索し、複数の LLM 呼び出しとツール呼び出しを通じて CallExpression.js と AssignmentExpression.js を更新します。努力したにもかかわらず、残りの参照を見逃しています。 Kiro の対処法: 開発者が IDE でこのタスクを手動で実行する方法を考えてみましょう。 get_loose_identifier で F2 を押し、新しい名前を入力して、Enter を押します。IDE は、コードベース全体の 8 つの参照と 3 つのインポートすべてを更新しながら、自動的に名前変更を実行します。これがまさにセマンティックリネームツールが行うことです。次の図の右側(新しいアプローチ)は、Kiro が単一のツール呼び出しで名前変更全体を適切に実行する方法を示しています。 依頼内容: 「このファイルの lint エラーを修正して」 従来の失敗: エージェントは linter の出力をテキスト編集の ToDo リストとして扱いました。1 つのファイルでシグネチャの関数名を camelCase から snake_case に変更しましたが、他のファイルで「参照が見つからない」や「インポートが見つからない」エラーを導入しました。すべての使用箇所への変更の伝播に失敗したのです。 Kiro の対処法: ユーザーが直接名前変更を依頼しなくても、エージェントがセマンティックリネームツールから恩恵を受ける例を示します。ユーザーはエージェントに「 text_helpers.py の lint エラーを修正して」と依頼します。lint エラーは、 utils/text_helpers.py 内の normalizeText と slugifyTitle を snake_case に変更する必要があることを示しています。コードベースの部分的なスナップショットを以下に示します。 これらの修正をテキスト編集として扱うエージェントは、関数定義の名前を変更し、ローカル参照を修正するかもしれませんが、他の場所のインポートや呼び出し箇所を見逃す可能性が高く、実行時に ImportError / NameError を引き起こします。セマンティックリネームツールを使用することで、Kiro は定義だけでなく、 api/routes.py と services/indexer.py のインポートと呼び出しも更新します。以下の画像の通りです。 依頼内容: 「コンポーネントを再編成して – Button.tsx を src/components/ から src/shared/ui/ に移動して」 従来の失敗: エージェントはタスクを単純なファイル操作として扱いました。ファイルの移動は成功しましたが、古い場所を指すすべてのインポート文が壊れています。エージェントはその後、検索置換操作でファイルごとにインポートを修正しようとしましたが、動的インポートを見逃しました。 import('../components/Button') 。 Kiro の対処法: Kiro がインポートパスを自動的に更新する具体的な例を示します。図は、プロジェクト構造の部分的なスナップショットと依存するコードスニペットの一部を示しています。 Button.tsx を src/components/ から src/shared/ui/ に移動した後、Kiro は移動したファイルに関連するすべてのインポート文を自動的に更新します。 主な利点: 組み込みの言語サーバーが編集を処理するため、手動の検索置換は不要です。 言語認識:TypeScript/JavaScript モジュール解決を理解します。 より安全:動作するコードを壊す可能性が低くなります。 エッジケースの処理:パスエイリアス、モノレポなどに対応します。 これは、VSCode のエクスプローラーでファイルをドラッグアンドドロップしたときに起こることとまったく同じです。セマンティックリネームツールはエージェントベースの同等機能です! Kiro エージェントのリファクタリング方法 IDE は、エージェント AI の台頭以前にこの問題をすでに解決していました。VSCode でシンボルの名前を変更するために F2 を押すと、IDE は推測しません。コードの構造を理解する言語サーバーに相談し、ワークスペース全体の編集を計算し、安全に適用します。VSCode のワークスペース編集機能により、単なるテキストパターンではなく、コードの構造を理解するプログラマブルなセマンティック検索置換が可能になります。Kiro エージェントは、LLM 推論だけでリファクタリングをシミュレートしようとはしません。代わりに、エージェントは上記と同じメカニズムを使用して、これらの実証済みの IDE 機能をプログラム的に公開する 2 つの新しいリファクタリングツールを登録します。エージェントがシンボルの名前を変更したりファイルを移動したりする必要がある場合、意図をインテリジェントに認識し、適切なリファクタリングツールを選択して呼び出します。エージェントはリファクタリングワークフローを調整し、IDE の言語サーバーが正確性の検証を支援します。 これらのエージェント登録リファクタリングツールが内部でどのように機能するかを見てみましょう。 セマンティックリネームツール:正しいリネームを実現 このツールは、VSCode のシンボル名前変更 API に直接接続します。F2 を押したときに使用するのと同じものです。 vscode.prepareRename を使用してシンボルが名前変更可能かどうかを検証し(例:キーワードではない)、 vscode.executeDocumentRenameProvider を使用してワークスペース全体で必要なすべての変更を含むワークスペース編集を生成します。TypeScript、JavaScript、TSX、JSX の場合、組み込みの VSCode 名前変更プロバイダーがすべてを処理します。Python、Go、Java などの場合、ツールはインストールされた言語拡張機能とそれらが提供する言語サーバーに依存します。 スマートリロケートツール:すべてを壊さずにファイルを移動 このツールは、VSCode のファイル移動機能を使用して、すべての参照を自動的に更新しながらファイルを再配置します。VSCode のエクスプローラーでドラッグアンドドロップするのと同等のプログラム的な操作ですが、エージェントがあなたのために実行できます。 vscode.WorkspaceEdit.renameFile と vscode.workspace.applyEdit を使用して、ツールは複数のファイルにわたる包括的な変更を生成し、影響を受けるインポートを更新します。 これが重要な理由 創造性よりも精度: リファクタリングは、コードがどのように見えるべきかを LLM に想像させる必要はありません。コードが 実際に何であるか を理解し、外科的に変更できるツールが必要なのです。 実証済みのインフラストラクチャを通じた信頼: これらは実験的な LLM 機能ではなく、開発者が日常的にすでに依存しているリファクタリングインフラストラクチャとの直接統合です。F2 を押したときに機能すれば、エージェントが実行したときにも機能します。 言語に依存しない: 重い作業は言語サーバーによって行われるため、このアプローチは技術スタックと言語全体に一般化されます。 生産性の維持: 20 秒の手動リファクタリングが、5 分間の AI 生成リカバリーミッションになるべきではありません。適切なツールを使用すれば、操作は高速でアトミックなままです。 より大きな視点 構築による正確性という私たちの哲学に基づいて、 IDE 診断統合 を導いたのと同じ原則で、VSCode のリファクタリング機能の全範囲をカバーするようにこのアプローチを拡張しています。エラーが複合する前にキャッチするためにリアルタイム診断を統合したのと同様に、これらの実証済みの決定論的 IDE 機能を、新しい内部スマートリロケートおよびセマンティックリネームツールに拡張しました。 しかし、リファクタリング機能は名前変更と再配置で止まりません。VSCode の言語サーバーは、エージェントが活用すべき豊富な自動コード変換スイートを提供します。コードブロックを再利用可能な関数に抽出するメソッド/関数の抽出、コードを簡素化する変数/関数のインライン化、すべての呼び出し箇所でメソッドパラメータを更新するシグネチャの変更、アロー関数への変換やその他の言語固有の変換は有力な候補です。 このアプローチを取ることで、エージェントが実行される基盤に正確性、セキュリティ、信頼性を組み込むことができます。これらのツールで確立したパターンは、ツールキットへの新しい追加を導きます。LLM に脆弱なテキスト置換スクリプトを生成するよう依頼する代わりに、インテリジェントなコーディングエージェントは、開発者がすでに信頼しているこれらの実証済みの IDE 操作を活用し続けます。IDE が正しく実行する方法を知っているとき、私たちはそれに作業をさせます。エージェントがより有能になるにつれて、これはその出力をより信頼できるものにするための良いテクニックでもあります。 違いを体験する準備はできましたか? Kiro を無料で始めて 、開発ワークフローをどのように変革できるかを確認してください。 Discord の成長するコミュニティに参加して、フィードバックを共有し、質問をし、AI 支援コーディングで構築している他の開発者とつながりましょう。 謝辞 エンジニアリングの洞察と貴重なフィードバックを提供してくれた Al Harris に感謝します。 本記事は 2026 年 2 月 5 日に公開された Pardis Pashakhanloo と Rajdeep Mukherjee による “ Refactoring made right: how program analysis makes AI agents safe and reliable ” を翻訳したものです。翻訳は Solutions Architect の吉村が担当いたしました。
アバター
本記事は 2025/11/24 に公開された “ Running NVIDIA Cosmos world foundation models on AWS” を翻訳したものです。 自律走行車、ロボティクス、スマートファクトリー向けのフィジカル AI システムの開発においては、高品質かつ十分なトレーニングデータを生成するということが非常に重要な課題となります。このブログでは、Amazon Web Services (AWS) 上で NVIDIA Cosmos TM ワールドファウンデーションモデル(WFM)をデプロイして、大規模に高品質の合成データを生成する方法を示します。また、異なるユースケースに最適化された 2 つの本番環境向けアーキテクチャを紹介します。 フィジカル AI により、システムは複雑かつ動的な環境で知覚、感知、推論、および自律的な行動ができます。しかし、これらのモデルの事前トレーニングと事後トレーニングには、膨大な量の高品質な実演例が必要です。ビデオからの既存の実演例や、人間が作成する新しい実演例は限られており、十分なデータを提供できません。合成データの生成は、このデータギャップの課題を克服し、フィジカル AI を進化させて、業界全体でビジネスを変革する高度な新しい行動を可能にするために重要です。 Cosmos オープン WFM はこのギャップを埋め、シナリオの合成、ドメインのランダム化、および空間推論を通じて、自律走行車、ヒューマノイドロボット、スマートファクトリー、およびビデオ分析 AI エージェント向けのフィジカル AI の開発を可能にします。Cosmos モデルを最大限に活用するには、慎重に設計され、構成された管理インフラストラクチャが必要です。このインフラストラクチャは、スケーラブルでコスト効率が高い必要があります。 このブログでは、AWS インフラストラクチャ上で Cosmos WFM をデプロイするためのシステムアーキテクチャと実装のベストプラクティスを紹介します。これにより、エンタープライズグレードのスケーラビリティ、セキュリティ、パフォーマンスを実現します。また、コスト効率性、簡単な管理、および再現可能なデプロイメントも提供します。 フィジカル AI データパイプラインの課題 大規模言語モデル(LLM)は、インターネット上の何十年にもわたるデジタル化されたテキスト、書籍、ウェブサイト、ビデオ、会話などの事実上無制限のトレーニングデータを利用しています。この膨大なコーパスにより、モデルはスケールで言語パターン、推論、および知識表現を学習できます。しかし、フィジカル AI システムは根本的に異なる課題に直面しています:「データ不足問題」です。 図 1: フィジカル AI のための合成データ生成の進化 インターネット上のテキストとは異なり、物理的相互作用のデータは不足しています。オブジェクトを操作したり、環境をナビゲートしたり、器用なタスクを実行したりするには、行動をクローンする模倣学習などの現在の技術が必要です。これには、実際の物理的相互作用で取得された現実のセンサーデータ(カメラ映像、力の測定、感覚フィードバックなど)が必要です。このデータを収集するにはコストや時間がかかり、しばしば危険です。 そこで合成データの生成が不可欠になります。Cosmos WFM は物理的に妥当性のあるシナリオを合成します。これには、写実的な光の変化、オブジェクトのテクスチャ、カメラアングル、および動きの軌跡が含まれます。これにより、開発サイクルが加速し、モデルの堅牢性が向上し、フィジカル AI が経済的に実行可能になります。 Cosmos WFM 概要 Cosmos は、WFM を活用してフィジカル AI を進化させるために設計されたプラットフォームです。その中核には、事前トレーニングされたマルチモーダルモデルである Cosmos オープン WFM があり、開発者が世界の状態をビデオとして生成し、フィジカル AI の推論や事後トレーニングを行い、特殊なフィジカル AI モデルを開発できます。Cosmos プラットフォームは 3 つのモデルで構成されています: Cosmos Predict 画像、深度マップ、センサーデータ、テキストプロンプトなどの初期条件から、物理的・時間的に正しい未来の状態を動画で生成するモデルです。 Cosmos Transfer テキストプロンプトと実世界のデータ、シミュレーションから得られた複数の空間制御入力を使用して、フィジカル AI 開発のための物理学を意識した世界状態の映像を生成します。Transfer は、照明、背景、天候、色、テクスチャなどの多様性を追加することで、与えられたデータセットを拡張および増殖させることができます。 Cosmos Reason Cosmos Reason は、物理 AI のためのオープンでカスタマイズ可能な推論ビジョン言語モデル(VLM)です。この VLM により、ロボットやビジョン AI エージェントは、事前知識、物理学、常識を使用して現実世界を理解し、行動できます。このモデルは 物理的 推論 リーダーボード でトップを獲得し、データアノテーションや批評、ロボット計画とトレーニング、業界全体でのビデオ分析 AI エージェントの作成など、さまざまなユースケースに適用できます。Cosmos Reason は、 NVIDIA Blueprint for Video Search and Summarization(VSS) でビデオ分析 AI エージェントの開発に使用されています。 これらのモデルを特定のドメイン向けに構築、カスタマイズ、デプロイするには、開発者は NVIDIA Cosmos Cookbook を活用できます。推論、事後トレーニング、ファインチューニングのためのステップバイステップのワークフロー、技術的なレシピ、具体的な例を提供します。 AWS 上で Cosmos WFM を実行するためのアーキテクチャ AWS は次の 2 つのデプロイメントオプションがあります: – リアルタイム推論: NVIDIA NIM マイクロサービスを Amazon Elastic Kubernetes Service (Amazon EKS) で低遅延のインタラクティブアプリケーション用に使用できます。NVIDIA NIM マイクロサービスは、組織が NVIDIA GPU 上で AI モデルを実行できる一連の高速化されたされた推論マイクロサービスです。 – バッチ推論: コンテナ化されたモデルを AWS Batch で高スループットのオフラインワークロード用に使用できます。 NIM-on-EKS パターンは、常時稼働する GPU 対応 Pods で応答遅延と可用性を優先します。一方、AWS Batch パターンは、ジョブの投入をトリガーとしたコンピューティングプロビジョニングを通じて、コスト効率と弾力的なスループットを最適化します。これらのアーキテクチャを選択する際は、レイテンシー要件、推論量パターン、コスト制約、および物理 AI 開発パイプラインの統合ポイントを考慮する必要があります。 オプション 1:ライブ推論の実行– Amazon EKS 上の Cosmos NIM マイクロサービス Amazon EKS 上の Cosmos NIM マイクロサービスオプションは、エンタープライズグレードのオーケストレーション、自動スケーリング、および簡素化された運用を提供します。これは、高可用性、動的スケーリング、およびクラウドネイティブな統合を必要とする本番環境のデプロイメントに推奨されるアプローチです。Cosmos NIM マイクロサービスは、最適化された推論エンジンを備えた Cosmos モデルをパッケージ化し、手動構成の複雑さを解消します。このパターンのデプロイメントのステップバイステップガイドについては、 “Deploying generative AI applications with NVIDIA NIMs on Amazon EKS” ブログ投稿 を参照してください。 アーキテクチャ図 図 2: Amazon EKS 上での Cosmos NIM マイクロサービスを使用したライブ推論の実行のアーキテクチャ 利点 – エンタープライズグレードのオーケストレーション : Kubernetes は宣言型構成、自動ロールアウトとロールバック、ポッド再起動による自己修復、および手動構成なしのサービスディスカバリーを提供します。 – 高可用性 : マルチポッドデプロイメントにより、単一障害点がなくなります。クロス AZ ノード配置により、アベイラビリティーゾーンの障害を回避できます。ローリングアップデートにより、デプロイメント中のサービス可用性が維持されます。 – 運用の簡素化 : マネージドコントロールプレーンにより、ノードのメンテナンスが不要になります。自動アップグレードにより、クラスターのコンポーネントが最新の状態に保たれます。AWS サービスとの統合により、統一されたモニタリングとセキュリティが提供されます。 オプション 2: バッチ推論の実行 – AWS Batch 上の Cosmos コンテナ AWS Batch は、大規模なバッチコンピューティングワークロードを実行するためのフルマネージドサービスを提供し、オフライン推論シナリオのための Cosmos WFM のデプロイメントに理想的なプラットフォームとなります。このアーキテクチャにより、軌跡データの合成、シーンバリエーション、または環境予測の生成など、大量の物理 AI データを処理できます。常時インフラストラクチャを維持する必要なく、AWS Batch によってオーケストレーションされるコンテナ化された Cosmos モデルを活用します。ジョブキューの需要に基づいて、自動的に最適なコンピュートリソース(GPU 対応 EC2 インスタンス)をプロビジョニングします。また、Amazon S3 または Amazon EFS からの入力データを元に、バッチジョブを開始することができます。これらのジョブは、ビデオ生成、シーン補完、または物理シミュレーションなどの推論タスクを実行します。この結果は、ロボットトレーニングパイプラインや自律システム開発ワークフローといった後段の処理のために EFS に書き戻されます。Amazon CloudWatch との統合は包括的なモニタリングを提供し、AWS IAM ポリシーはモデルアーティファクトとデータリポジトリへの安全な最小特権アクセスを保証します。このパターンのデプロイメントのステップバイステップガイドについては、この ワークショップ を参照してください。 アーキテクチャ図 図 3: AWS Batch で Cosmos コンテナを使用してバッチ推論を実行するためのリファレンスアーキテクチャ 利点 – コスト最適化 : 動的スケーリングにより、AWS Batch は推論ジョブが実行される時のみ GPU コンピュートリソースをプロビジョニングし、完了時にインスタンスを終了します。この従量課金モデルにより、アイドルインフラストラクチャに関連するコストが排除され、特にデータセット拡張や夜間の合成データ生成などの断続的なワークロードに有効です。さらに、スポットインスタンスの活用によってコンピュートコストを削減することも可能です。 – 運用管理の簡素化 : マネージドサービスにより、自動ジョブスケジューリング、リソースプロビジョニング、依存関係管理、再試行ロジックにより、インフラストラクチャの複雑さが軽減され、クラスターの操作ではなくモデルの最適化に集中できます。 – 大規模データ生成のための弾力的なスループット : AWS Batch は、単一ジョブから数千の並列推論タスクまで、フィジカル AI トレーニングのための大規模なデータセットを処理します。この弾力的な演算能力により、価値実現までの時間を加速し、ロボットポリシー開発と自律システム検証における繰り返しを高速化できます。 まとめ AWS で Cosmos WFM を実行すると、大規模な物理 AI 機能を利用できます。このブログでは、異なる組織のニーズと制約に最適化された 2 つの本番環境向けアーキテクチャを紹介しました。 AWS モデルマーケットプレイス上で提供されている Cosmos Reason 推論ビジョン言語モデル を導入し、高度な空間-時間的理解と物理的常識を活用して AI プロジェクトを強化し、よりスマートなロボット計画、ビデオ分析、および最先端の効率性と推論機能を備えた自動データ注釈を可能にするかをご確認ください。 著者注: この技術ガイドは、Cosmos プラットフォームの機能、AWS のベストプラクティス、および大規模モデルデプロイメントの一般原則に基づいています。具体的な実装の詳細は、お客様の要件、最新の NVIDIA NIM マイクロサービスリリース、AWS サービスの更新、および組織のポリシーと制約によって異なる場合があります。最新の情報については、常に NVIDIA と AWS の最新のドキュメントを参照してください。 翻訳は、ソリューションアーキテクトの山本が担当しました。 Abhishek Srivastav Abhishek Srivastav は Amazon Web Services のプリンシパルソリューションアーキテクトで、クラウド採用戦略の加速を通じて顧客の成功を推進しています。AI/ML 技術、ハイパフォーマンスコンピューティング、シミュレーション、物理 AI など、幅広い技術的専門知識を持ち、複雑な企業の課題に対するソリューションの設計を専門としています。現在の役割では、CIO、CTO、その他の技術幹部と協力して、デジタルトランスフォーメーションと生成 AI イニシアチブのロードマップを開発しています。 Brett Hamilton Brett Hamilton は NVIDIA の Developer Relations マネージャーで、フィジカル AI とワールドファウンデーションモデルに取り組んでいます。彼は ISV との協力、新技術の採用拡大、現実世界の課題解決に特化しています。Brett の AI との関わりは 2015 年に B2B チャットボットの開発から始まりました。その後、音声アシスタント、NLP と言語アプリケーション、そしてビジュアル AI にまで及びました。彼は Cisco、AWS、そして NVIDIA で製品リーダーシップ、ビジネス開発、そして開発者関係の役割を担ってきました。 Diego Garzon Diego Garzon は NVIDIA の AI/AV シニアソリューションアーキテクトで、フィジカル AI とシミュレーションに取り組んでいます。以前は Microsoft のプロシージャルコンテンツディレクターとして Xbox Game Studios のプロシージャルグラフィックスをリードしていました。キャリアの初期には、Blizzard Entertainment と Blue Sky Studios で働き、アニー賞にノミネートされました。また、ピクサーの WALL·E にも貢献しました。Diego は SIGGRAPH で流体シミュレーションと水の効果に関する研究を発表しました。また、GDC でグローバルイルミネーションとプロシージャルライティングプローブについて発表しました。さらに、ビジュアルエフェクトソサイエティの理事を務めたこともあります。 Jathavan Sriram Jathavan Sriram は NVIDIA のシニアソリューションアーキテクトで、AI とロボティクスソリューションを専門としています。彼の専門分野はクラウドインフラストラクチャ、Kubernetes、AI 技術で、ワールドファウンデーションモデルとフィジカル AI アプリケーションに注目しています。彼はクラウドネイティブプラットフォーム上で顧客が生成 AI を大規模に展開できるようにすることに情熱を注いでいます。 Shaun Kirby Shaun Kirby は AWS のプリンシパルエンタープライズアーキテクトで、自動車および製造業向けの Internet of Things (IoT) とロボティクスを専門としています。彼は顧客がクラウド技術で卓越するのを助け、ゲームチェンジングなソリューションを先駆けています。AWS に入る前は、Cisco でラピッドプロトタイピングと IoT ショーケースをリードし、大規模システム統合の経験がありました。
アバター