みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2026年も1月後半に入り、新年の抱負を実行に移す時期になりましたね。「1月は行く、2月は逃げる、3月は去る」という言葉がありますが、気づけばもう月末です。みなさまの年始に立てた目標への取り組みはいかがでしょうか？ 年明けから4週間続けることができたなら、それはもう習慣化への第一歩です。私は体幹トレーニングのプランクを年初から継続中です。このままいけば 12 月頃に開催予定の re:Invent 2026 のキーノートは、最初から最後までプランクをしながら視聴できるようになっている予定です。継続は力なり！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月19日週の主要なアップデート 1/19(月) この日のサービスアップデートはありませんでした。 1/20(火) Amazon EVS が VCF と VMware ESX のソフトウェアバージョン選択をサポート Amazon EVS で VMware Cloud Foundation (VCF) と ESX ソフトウェアのバージョンを選択できるようになりました。これまでは決められたバージョンでしか環境構築できませんでしたが、今回のアップデートで複数のサポート済みバージョン組み合わせから選択可能です。オンプレミスの VMware 環境から AWS への移行時に、既存システムとの互換性を保ちながらスムーズに移行できるメリットがあります。詳細はこちらの サービス詳細ページ と ドキュメントをご参照ください。 Amazon RDS ブルー/グリーンデプロイがダウンタイムを 5 秒未満に短縮 Amazon RDS ブルー/グリーンデプロイ で、データベースのスイッチオーバー時間が大幅に短縮されました。これまで長いダウンタイムが発生していた本番環境でのデータベース更新作業が、わずか 5 秒以下で完了できるようになります。ブルー/グリーンデプロイ は、本番環境 (ブルー) を安全に保ちながら、別環境 (グリーン) でテストを行い、問題がなければ瞬時に切り替える仕組みです。メジャーバージョンアップグレードや定期メンテナンス時に、サービス停止時間を最小限に抑えられるため、24 時間稼働が求められるアプリケーションに特に有効です。詳細は こちらのドキュメントをご参照ください。 Amazon QuickSight が SPICE データセットの拡張サイズ、高速取り込み、豊富なデータ型サポートを開始 Amazon QuickSight の SPICE エンジンが大幅に強化されました。データセット容量が従来の 1TB から 2TB に倍増し、より大規模なデータ分析が可能になります。また取り込み速度も向上したため、データの更新時間が短縮され、リアルタイムな分析により近づけます。さらに文字列データの制限が 2K から 64K 文字に拡張され、長いテキストデータも扱えるようになりました。これにより AI 分析など複雑なワークロードにも対応でき、データ活用の幅が大きく広がります。詳細は こちらのドキュメントをご参照ください。 SageMaker Unified Studio がクロスリージョンおよび IAM ロールベースのサブスクリプションのサポートを追加 Amazon SageMaker Unified Studio で、クロスリージョンサブスクリプションと IAM ロールベースサブスクリプションがサポートされました。従来は同一リージョン内でのデータアクセスに限られていましたが、今回のアップデートにより異なるリージョンの AWS Glue テーブルや Amazon Redshift テーブルにもアクセスできるようになりました。また IAM ロールを使用することで、プロジェクトを介さずに直接データにアクセス可能になり、組織全体でのデータ活用がより柔軟になります。 詳細はこちらのドキュメントをご参照ください。 1/21(水) Amazon RDS for SQL Server が差分およびトランザクションログ復元サポートを強化 Amazon RDS for SQL Server で差分・トランザクションログ復元のサポートが強化されました。Multi-AZ や read replica を設定したインスタンスにおいて、以前は Single-AZ モードに変更してから復元し、再度 Multi-AZ や read replica を設定し直す必要がありましたが、この手順が不要となり復元時間を大幅に短縮できます。高可用性を維持したまま効率的なデータ復旧が可能になるため、ビジネス継続性の向上に役立ちます。詳細は こちらのドキュメントをご参照ください。 AWS がアクセス拒否エラーメッセージに追加のポリシー詳細を導入 AWS IAM でアクセス拒否エラーが発生した際に、どのポリシーが原因かを特定しやすくなりました。これまでエラーメッセージにはポリシーの種類のみ表示されていましたが、今回のアップデートで具体的なポリシー ARN が含まれるようになります。同じ種類のポリシーが複数ある環境では、トラブルシューティング時間を大幅に短縮できます。詳細は こちらの ドキュメントをご参照ください。 AWS Clean Rooms が SQL でのジョインおよびパーティションヒントのサポートを追加 AWS Clean Rooms で SQL クエリに join と partition hints 機能が追加されました。これまで大きなテーブル結合時の処理が非効率だった問題が解決され、broadcast join hint でクエリパフォーマンスが向上し、コストも削減できます。また partition hints により並列処理が改善されます。例えば、スポーツ視聴世帯数の分析で lookup テーブルに hints を適用することで、処理速度とコスト効率が大幅に改善されます。詳細は こちらのドキュメントをご参照ください。 1/22(木) Microsoft Office、Visio、Project 2024 アプリが Amazon WorkSpaces で利用可能に Amazon WorkSpaces Personal と Core で Microsoft Office LTSC Professional Plus 2024 や Visio 2024、Project 2024 といった最新の Microsoft 製品群が利用可能になりました。これまで古いバージョンに制限されていた環境でも、最新の生産性ツールを使った業務が可能です。既存の WorkSpaces バンドルを変更することなく、管理されたアプリケーションカタログから必要なアプリケーションを選択して追加できるため、運用負荷を抑えつつ標準化されたセキュアなデスクトップ環境を構築できます。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Browser がカスタムブラウザ拡張機能をサポート Amazon Bedrock AgentCore Browser で Chrome 拡張機能が利用できるようになりました。これまで標準的なブラウザ自動化では対応が困難だった複雑なワークフローを、カスタム拡張機能を使って自動化できます。拡張機能を S3 にアップロードすることで、ブラウザセッション中に自動インストールされる仕組みです。カスタム認証フローや自動テスト、広告ブロックによるパフォーマンス最適化など、企業での実用的な活用が期待できます。東京リージョンを含む 9 つのリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 AWS Config が 13 の新しいマネージドルールを追加 AWS Config で新たに 13 個の管理ルールが追加されました。AWS Config は AWS リソースの設定変更を監視・記録するサービスで、今回のアップデートにより Amazon Cognito や EBS スナップショット、CloudFormation スタックなどのセキュリティチェックが自動化できます。これまで手動で確認していたセキュリティ設定の検証作業を大幅に削減でき、Conformance Packs を使えば組織全体に一括展開も可能です。詳細は こちらのドキュメントをご参照ください。 1/23(金) Amazon Connect がステップバイステップガイドに条件付きロジックとリアルタイム更新を追加 Amazon Connect の Step-by-Step Guides に条件付きロジックとリアルタイム更新機能が追加されました。これにより、マネージャーはユーザーの入力に応じてドロップダウンメニューの表示切り替えや必須フィールドの調整など、より柔軟なガイド体験を作成できるようになります。また、Connect リソースからの自動データ更新により、エージェントは常に最新情報で作業できます。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for Oracle が Oracle マルチテナント構成でのレプリカをサポート開始 Amazon RDS for Oracle で Oracle multi-tenant configuration でのレプリカサポートが開始されました。従来はこの構成でレプリカを作成できませんでしたが、これにより複数のプラガブルデータベースを統合管理しながら読み取り負荷を分散できるようになりました。クロスリージョンレプリカによる災害復旧や、レプリカのプライマリ昇格も可能です。コスト削減と運用効率化を同時に実現できる点が魅力です。詳細は こちらのドキュメントをご参照ください。 EC2 Auto Scaling がグループ削除保護の新しいメカニズムを導入 EC2 Auto Scaling で削除保護機能が強化されました。新しいポリシー条件キー autoscaling:ForceDelete により、IAM ポリシーでインスタンスが稼働中の Auto Scaling グループの強制削除を制限できます。さらにグループレベルでの削除保護設定も可能になり、重要なワークロードを誤削除から守れます。従来は削除操作の制御が難しかったですが、これにより本番環境での安全性が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Route 53 Domains が .ai およびその他のトップレベルドメインのサポートを追加 Amazon Route 53 Domains で .ai や .shop など 10 個の新しいドメインが登録できるようになりました。AI 企業なら .ai ドメイン、オンラインショップなら .shop ドメインなど、業界や用途に特化したドメインを選択できます。従来の .com や .org に加えて、よりブランドに適したドメインを AWS 上で一元管理でき、DNS 設定や自動更新も統合されているため運用が簡単になります。詳細は こちらをご参照ください。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 本年も皆様に役立つ状況をタイムリーにお届けできればと思っていますので、よろしくお願いします！ 2 月 17 日に「 第6回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～ 」を開催します。様々な業界のモデル開発・利用の取り組みを発表予定です。ぜひご参加いただければと思います。 それでは、1 月 19 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース お客様事例/技術記事 AWS生成AI国内事例ブログ「株式会社デジナーレが Strands Agents と AgentCore で実現した脆弱性情報収集の完全自動化」を公開 株式会社デジナーレ様が Amazon Bedrock、Strands Agents、Amazon Bedrock AgentCore Runtime を活用して、脆弱性情報の収集から分析、レポート作成までを完全自動化したシステムを構築した事例を紹介しています。調査・執筆・校正の 3 段階で構成されるエージェントワークフローにより、従来数時間かかっていた調査作業がゼロ時間になったという結果が報告されています。 AWS生成AI国内事例ブログ「Amazon Bedrock AgentCore を使った業務支援 AI Agent 開発」を公開 株式会社 Works Human Intelligence 様と AWS GenAIIC が共同で取り組んだ AI Agent 開発事例を紹介しています。通勤手当申請の承認を支援するエージェントと、ブラウザ操作エージェントの 2 つを Amazon Bedrock AgentCore Runtime で構築し、プロンプトキャッシュやモデル変更により処理コストを最大 97% 削減することに成功しました。 ブログ記事「【開催報告 & 資料公開】Security for App Builders @ Loft #1 〜AI Coding 時代のセキュリティ実践〜」を公開 2025 年 11 月に開催された「Security for App Builders @ Loft #1」イベントの開催報告です。Coding Agent が生成したコードの安全性確保をテーマに、脅威モデリング、セキュリティのシフトレフト、マネージドサービスによるアプリケーションセキュリティの実装について解説しています。各セッションの資料も公開されています。   ブログ記事「Amazon Bedrock の次世代推論エンジン Mantle におけるゼロオペレーターアクセス」を公開 Amazon Bedrock の次世代推論エンジン Mantle のセキュリティ設計について解説しています。AWS Nitro System のアプローチに従い、ゼロオペレーターアクセス（ZOA）を実現し、AWS オペレーターが顧客データにアクセスする技術的手段を設計段階から排除しています。 Nitro Trusted Platform Module (NitroTPM)  から暗号署名されたアテステーション・メジャーメントによる高い保証によって信頼性が裏付けられています。 ブログ記事「『行政の進化と革新のための生成AIの調達・利活用に係るガイドライン』対応 – 調達チェックシート要件へのAWSサンプル回答」を公開 デジタル庁が公開した政府機関向け生成 AI ガイドラインの調達チェックシートに対する AWS のサンプル回答を提供しています。Amazon Bedrock を活用したオープンソースアプリケーション「 GenU 」を用いた対応例を示しており、政府機関の調達担当者やパートナー企業の提案書作成を支援します。 ブログ記事「NVIDIA RTX PRO 6000 Blackwell Server Edition GPU で高速化された Amazon EC2 G7e インスタンスのご紹介」を公開 Amazon EC2 G7e インスタンスが一般提供開始されました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、G6e インスタンスと比較して最大 2.3 倍の推論パフォーマンスを実現します。最大 768 GB の GPU メモリ、最大 1,600 Gbps のネットワーク帯域幅をサポートし、生成 AI 推論やグラフィックワークロードに最適です。 ブログ記事「LangGraph と Amazon DynamoDB で耐久性のある AI エージェントを構築する」を公開 LangGraph と Amazon DynamoDB を使用して、耐久性のある状態管理を備えた本番環境対応の AI エージェントを構築する方法を紹介しています。新しい DynamoDBSaver コネクタにより、チェックポイントを永続化し、障害からの回復、長時間実行ワークフローの維持、ヒューマン・イン・ザ・ループレビューなどが可能になります。 Kiro関連記事 ブログ記事「すべてのタスクを一括実行：リリースを見送り続けていた機能をついに公開」を公開 Kiro に待望の「すべてのタスクを実行」機能が追加されました。当初は意図的に実装しなかったこの機能ですが、プロパティベーステスト（PBT）、開発サーバー、LSP 診断、サブエージェントなどの検証基盤を構築したことで、安全にバッチ実行できるようになりました。各タスクの出力が自動検証されるため、信頼性を保ちながら開発を加速できます。 ブログ記事「IDE 診断機能による Kiro の進化」を公開 Kiro が IDE の診断情報（型エラー、リンティング結果など）にリアルタイムでアクセスできるようになりました。従来のコーディングエージェントは IDE が検出したエラーを認識できませんでしたが、この統合により、コマンド実行が29% 削減され、コード品質が向上しました。TypeScript から Terraform まで多様な言語・設定ファイルに対応しています。 ブログ記事「Kiro CLI 新機能まとめ : v1.21.0 から v1.23.0」を公開 Kiro CLI の v1.21.0 から v1.23.0 までのアップデートをまとめて紹介しています。Web 検索機能、LSP 統合によるコードインテリジェンス、Knowledge Management 機能、サブエージェント、Plan エージェント、Grep/Glob ツール、マルチセッションサポート、MCP Registry サポートなど、開発体験を大きく向上させる機能が多数追加されています。 ブログ記事「Kiro CLI 1.24.0：スキル、カスタム Diff ツール、改善されたコードインテリジェンス、会話の圧縮」を公開 Kiro CLI 1.24.0 の新機能を紹介しています。Skills による段階的なコンテキスト読み込み、カスタム Diff ツール対応、18 言語に対応した組み込みコードインテリジェンス、AST パターンツール、会話圧縮の詳細コントロール、web_fetch の URL 権限管理、リモート認証サポートなど、開発ワークフローを強化する機能が満載です。 サービスアップデート AWS Security Agent が GitHub Enterprise Cloud をサポート開始 AWS Security Agent が GitHub Enterprise Cloud に対応し、プライベートリポジトリでも AI によるセキュリティ分析が可能になりました。これまで GitHub Enterprise の組織では利用できなかった自動セキュリティレビュー、ペネトレーションテスト統合、自動修復機能が使えます。プルリクエスト時に脆弱性を自動検出し、修正コードも自動提案してくれるため、開発チームのセキュリティ対応が大幅に効率化されます。米国東部(バージニア北部)リージョンで提供中です。詳細は こちらの製品ページ をご参照ください。 Amazon Bedrock AgentCore Browser がカスタムブラウザ拡張機能をサポート Amazon Bedrock AgentCore Browser で Chrome 拡張機能が利用できるようになりました。これまで標準的なブラウザ自動化では対応が困難だった複雑なワークフローを、カスタム拡張機能を使って自動化できます。拡張機能を S3 にアップロードすることで、ブラウザセッション中に自動インストールされる仕組みです。カスタム認証フローや自動テスト、広告ブロックによるパフォーマンス最適化など、企業での実用的な活用が期待できます。東京リージョンを含む 9 つのリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 SageMaker Unified Studio がクロスリージョンおよび IAM ロールベースのサブスクリプションのサポートを追加 Amazon SageMaker Unified Studio で、クロスリージョンサブスクリプションと IAM ロールベースサブスクリプションがサポートされました。従来は同一リージョン内でのデータアクセスに限られていましたが、今回のアップデートにより異なるリージョンの AWS Glue テーブルや Amazon Redshift テーブルにもアクセスできるようになりました。また IAM ロールを使用することで、プロジェクトを介さずに直接データにアクセス可能になり、組織全体でのデータ活用がより柔軟になります。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod がライフサイクルスクリプトデバッグ機能を強化 Amazon SageMaker HyperPod でライフサイクルスクリプトのデバッグ機能が強化され、AI/ML クラスター作成時のエラー原因特定が従来より簡単になりました。詳細なエラーメッセージと CloudWatch ログの場所表示、コンソールからの直接ログアクセス、実行進捗追跡機能により、開発チームの問題解決時間を大幅短縮できます。詳細は こちらのドキュメント をご参照ください。 Amazon EC2 G7e インスタンスが一般提供開始 Amazon EC2 G7e インスタンスが一般提供開始されました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載し、従来の G6e と比較して推論性能が最大 2.3 倍向上しています。大規模言語モデル (LLM) やマルチモーダル生成 AI モデルの展開、空間コンピューティングワークロードに最適です。最大 8 GPU と GPU あたり 96 GB のメモリを提供し、グラフィックスと AI 処理の両方を必要とするワークロードで最高性能を発揮します。米国東部(バージニア北部)と米国東部(オハイオ)で利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

本ブログは 2025 年 12 月 8 日に公開された AWS Blog “ New report: Cloud “fundamental” for European national security and defense ” を翻訳したものです。 クラウドコンピューティングは、欧州全体で国家安全保障・防衛能力を支える重要な基盤として台頭しています。 英国王立防衛安全保障研究所 (RUSI) が発表した 新しいレポート (AWS の支援を受けて独立した調査として実施) では、4 つの欧州諸国がハイパースケールクラウドインフラストラクチャを活用し、複雑化する脅威の状況の中で防衛態勢を強化し、国益を守っている方法を明らかにしています。NATO とその欧州加盟国が技術的優位性を維持・強化できる最新のデジタル基盤を求めている今、これは重要なレポートといえます。 クラウド採用の戦略的必要性 RUSI のレポートは、クラウド技術が欧州の国家安全保障にとって基本となる 3 つの目標、すなわちレジリエンスの達成、レガシーシステムの刷新、人工知能 (AI) などの先進技術の活用を支援することを論じています。この変化は単なるデジタルモダナイゼーションにとどまりません。「NATO と欧州の同盟国にとって、クラウド採用は単なるデジタルモダナイゼーションの問題ではなく、戦略的即応性の問題でもある。相互運用可能でスケーラブルかつ安全なデジタル能力を展開できるかどうかが、新たな脅威を抑止し対応する同盟の能力を左右する」とレポートは主張しています。そして「クラウドコンピューティングは欧州の国家安全保障・防衛にとって基盤となる能力になった」と結論付けています。 各国でのクラウド活用事例 RUSI のレポートは、さまざまなクラウドサービスプロバイダーを活用している英国、ウクライナ、エストニア、フィンランドのケーススタディに基づき、ネットワーク接続性、法規制上の課題、市場集中、地政学的リスクなどの課題に対処しながら、クラウド採用の戦略的・運用的影響を評価しています。 ウクライナ ロシアの侵攻が始まると、 ウクライナは AWS の支援を受けて 、重要な行政データベースとデジタルサービスをクラウドインフラストラクチャに迅速に移行しました。これにより、絶え間ないサイバー攻撃や物理的攻撃にもかかわらず、重要な政府サービスの継続性が確保されました。 RUSI のレポートには、クラウド採用とその影響を説明するために、さまざまなクラウドサービスプロバイダーの事例が含まれています。レポートでは、ウクライナがその後 Delta Platform を展開したことが説明されています。これは、複数のデータソースを統合してリアルタイムの状況認識、安全な軍事通信、自動化された脅威検出を可能にするクラウドネイティブの指揮統制プラットフォームです。クラウドベースのアプローチは、状況に即応した速度と大規模に運用するための基盤となっています。また、レポートが指摘するように、英国・ウクライナサイバープログラムなどのプログラムを通じた国際パートナーのサイバー能力支援も可能にしました。これは、有事の際にクラウドインフラストラクチャが同盟国間の迅速な国際協力をいかに促進できるかを示しています。 エストニア エストニアは、ルクセンブルクにデータ大使館を設立することで、デジタル継続性に対して積極的なアプローチを取っています。このデータ大使館には、国が侵攻された場合に亡命政府がアクセスできる重要な政府データベースが保存されており、最も極端なシナリオでも重要なデジタルガバナンス能力が存続することを保証しています。 フィンランド フィンランドは、ライブ・バーチャル・コンストラクティブ (LVC) 訓練システムを通じて、クラウドコンピューティングを活用して軍事訓練に変革をもたらしました。これらのクラウドベースのプラットフォームは、実機と仮想シミュレーターを統合し、従来のアプローチではコスト的に実現不可能な高度な訓練シナリオを可能にしています。このシステムは、国の規模にかかわらずクラウドを通じて高度な軍事能力にアクセスできることを実証しており、パフォーマンス分析とリアルタイムの訓練データ伝送により、かつてない訓練効果を実現しています。 英国 英国は、国家サイバーセキュリティセンターの Protective Domain Name Service (PDNS) などの取り組みを通じて、クラウド技術を国家サイバー防衛戦略に統合しています。このクラウドベースのシステムは、悪意のあるドメインへのアクセスを防止し、政府ネットワークと重要インフラをリアルタイムで保護します。英国政府は 2025 年 3 月に Borealis 宇宙監視システムを発表しました。このシステムは、衛星を保護し軍事的意思決定を支援するために、最高機密レベルまでの複数のソースからの情報を収集・処理することを目指しています。このプログラムは、クラウドが複雑な宇宙作戦に必要なスケールを提供しながら、機密性の高い防衛データを安全に処理できることを裏付けています。この事例は、クラウド環境での機密データの取り扱いを検討している各国の防衛当局にとって参考になります。 ウクライナ、エストニア、フィンランド、英国の事例は、クラウドコンピューティングが現代の国家安全保障インフラストラクチャの一部となったことを表しています。脅威が進化し続け、より高度化するにつれて、デジタル能力を迅速に展開、スケール、適応させる能力が、国家安全保障の成果をますます左右するようになるでしょう。 戦略的課題と考慮事項 RUSI のレポートは、欧州各国政府が検討すべき課題を挙げています。これには、ネットワーク接続性、相互運用性に影響を与えるレガシーシステムとの統合、デジタル主権の概念をめぐる不確実性、従来のインフラストラクチャ向けに設計された調達システムなどが含まれます。レポートは次のように結論付けています。「したがって、戦略的に検討すべきことは、政府がクラウド技術を採用すべきかどうかではなく、国家安全保障・防衛のメリットを最大化するためにトレードオフをどのように乗り越えるかである」 政府の行動に関する RUSI の推奨事項 RUSI のレポート は、国家安全保障・防衛目的でクラウドコンピューティングを活用しようとする欧州各国政府に対して、以下の推奨事項を提示しています。 国家安全保障・防衛のニーズに特化したクラウド採用の明確な戦略的方向性を策定し、原則に基づくトップダウンのアプローチで全機関の意思決定を導く 国家安全保障アプリケーションのクラウド採用を可能にするよう法的枠組みを改訂する シナリオベースのモデリングを使用して将来のコンピューティング要件を計画し、さまざまな状況における必要なコンピューティングリソースを把握する クラウドサービスの調達と保証機能を一元化する リスクベースのアプローチを採用する。データとサービスの重要度に基づいて調達を行い、有益なクラウド採用を妨げる過度に制限的なポリシーを避けながら、適切なセキュリティ対策を講じる クラウドソリューションを効果的に特定、採用、調達するために必要なスキルを人材が持てるよう、内部能力を構築する。これにより、調達の意思決定が技術的専門知識に基づいて行われるようになる クライアント側の暗号化、データポータビリティ要件、相互運用性標準、ハイブリッドまたはマルチクラウド戦略を含む依存性軽減戦略を実施する 共同演習、責任共有モデル、規制監督を通じて、政府とクラウドサービスプロバイダー間の信頼と透明性を醸成する。これにより、高度な機能へのアクセスを維持しながら、デジタル主権に関する懸念に対処できる つまり、ミッションを変革するには、組織全体が変革する必要があります。変革は、IT、調達、セキュリティ、法務、その他多くの機能にわたる新しい働き方を通じて実現される、強力なトップレベルのリーダーシップビジョンから始まります。組織全体が進化する必要があるのです。 クラウド技術により、ミッションベースのアプリケーションとサービスをアジャイルな方法で開発し、必要に応じて過度なコストをかけずにスケールできます。また、防衛組織にサイバーセキュリティの強固な基盤を提供します。オンプレミスでは多様なセキュリティ機能を常に最新の状態で維持することが難しいですが、クラウドであれば継続的に更新される豊富なセキュリティ機能を活用し、防衛組織のセキュリティ基盤を強化できます。 詳細情報 レジリエントなクラウドサービスの構築 AWS におけるデジタル主権 Trusted Secure Enclaves on AWS AWS NATO チームへのお問い合わせ 専門サポートのための認定 AWS パートナーへのお問い合わせ Chris Bailey Chris は AWS のグローバル国家安全保障・防衛担当ディレクターです。防衛業界での 30 年以上の経験を持ち、国家安全保障・防衛のクラウド採用プログラムの提供に関する専門家です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

AWS の年次フラッグシップイベントである  AWS re:Invent 2025  は、 2025 年 12 月 1 日から 5 日にかけて開催され、5 日間にわたる基調講演、ブレイクアウトセッション、製品発表、ライブデモが行われました。本イベントでは、多数の 新しいサービスや機能 が発表されました。本振り返りでは、自動車および製造業にとって特に重要なハイライトとして、主要な発表内容、実際のお客様事例、注目のデモを取り上げます。内容は戦略的なワークロード領域ごとに整理されており、現在のプロジェクトや優先事項に対応するトピックをすぐに確認できる構成になっています。 Autonomous Mobility 自動運転車 (AV) および高度運転支援システム (ADAS) の開発は、計算性能とストレージリソースの両面で非常に高い要求が課されるワークロードです。 AWS CEO の Matt Garman は 基調講演 において、 AWS Trainium3 チップを搭載した AWS Trainium3 UltraServers の一般提供開始を発表し、次世代の Trainium4 チップに関する展望も共有しました。Trainium3 UltraServers は、 AI トレーニングおよび推論ワークロード向けに高いパフォーマンスを提供し、 Trainium2 UltraServers と比較して最大 4.4 倍の計算性能、 4 倍のエネルギー効率、そして約 4 倍のメモリ帯域幅を実現します。これらは、次世代のエージェンティック AI 、推論モデル、強化学習に最適化されており、自動運転の意思決定システムのトレーニングや、複雑な運転シナリオを推論できる AI エージェントの開発に適しています。 AV および ADAS ワークロードでは、 Amazon S3 の最大オブジェクトサイズが 5 TB から 50 TB に 10 倍拡張されたことで、 LiDAR のポイントクラウド埋め込みやカメラ特徴ベクトルなど、巨大なセンサーデータセットの保存と分析が容易になりました。 Amazon S3 Vectors は現在一般提供されており、 1 インデックスあたり最大 20 億ベクトルまでスケールし、最大 90% のコスト削減を実現します。これにより、ペタバイト規模のデータで学習された知覚システムを支援します。 AWS はさらに、 Amazon OpenSearch Service においてサーバーレス GPU アクセラレーション と自動最適化されたベクトルインデックスを導入しました。これにより、大規模なベクトルデータベースを最大 10 倍高速かつ低コストで構築でき、リアルタイムの類似度検索が可能になります。加えて、 AWS Clean Rooms におけるプライバシー強化型の 合成データ生成 により、エッジケース向けのトレーニングデータ作成が可能になりました。また、 Amazon Nova 2 Omni （プレビュー） は、テキスト、画像、動画、音声を横断したマルチモーダル分析と推論を実現し、知覚および意思決定支援ワークフローを支えます。 AMZ304 のブレイクアウトセッションでは、 Zoox が Amazon SageMaker HyperPod を使用して自律走行ロボタクシー向けの基盤モデルをトレーニングしている事例を紹介しました。カメラ、 LiDAR 、レーダーデータを処理するマルチモーダルモデルを実行し、複雑なエッジケースに対応しています。Amazon SageMaker の Hybrid Sharded Data Parallelism (HSDP) とテンソル並列処理を組み合わせることで、 64 GPU を超える環境で 95% の GPU 利用率を達成し、 AWS Data Transfer Terminals を通じて最大 400 Gbps の速度で毎時最大 4 TB の車両データを取り込んでいます。Zoox は,   正式にサービスを開始した自律走行ロボタクシーサービスのデモンストレーションを、 re:Invent 期間中に実施しました。 Software Defined Vehicle (SDV) AWS は 2025 年 7 月に、仕様駆動型開発によって構想から本番までを支援する AI IDE Kiro をリリースしました。さらに AWS は、新たなクラスの AI エージェントである 3 つの frontier agents 発表しました。 Kiro 自律エージェント、 AWS Security Agent 、 AWS DevOps Agent は、ソフトウェア開発チームの一員として数時間から数日間稼働し続けることができます。 Kiro 自律エージェント は、ソフトウェア定義車両開発を加速するための仮想開発者として活用できます。 Matt Garman は基調講演で、 AWS 史上最も高性能かつ高効率な CPU である Graviton5 も紹介しました。 Graviton5 ベースの新しい Amazon EC2 インスタンスは、前世代と比較して最大 25% 高い性能を提供し、キャッシュサイズは 5 倍に拡大されています。 IND382 のセッションでは、日産自動車が AWS 上での新しい Nissan Scalable Open Software Platform を通じて、ソフトウェア定義車両の開発をどのように加速しているかを共有しました。このプラットフォームにより、テストは 75% 高速化され、世界中の 5,000 人以上の開発者がソフトウェア開発、データ管理、車両運用で協働できる統合クラウド環境が提供され、機能更新の迅速化が実現されています。また CMP360 のセッションでは、 AWS が Graviton5 の設計と性能について詳しく解説し、 Siemens 、 Synopsys 、 Honeycomb 、 Airbnb 、 SAP などの顧客による実ワークロードでの結果と、 Graviton プラットフォームへの移行および運用に関する知見が共有されました。 Connected Mobility すべての AWS お客様は、ワークロード向けに伸縮性と信頼性の高いコンピューティング基盤の恩恵を受けていますが、これはコネクテッドモビリティのバックエンドを運用する自動車業界のお客様にも当てはまります。 AWS は、 AWS Lambda (Lambda), Amazon Elastic Kubernetes (Amazon EKS) , Amazon EMR に対して、コネクテッドモビリティのユースケースに関連する新機能を発表しました。 AWS は Lambda Managed Instances を発表しました。これは、サーバーレスの運用の簡便さを維持しながら、独自の Amazon EC2 上で Lambda 関数を実行できる新機能です。この機能により、特定のコンピューティング要件への対応や、定常的なワークロードのコスト最適化が可能になります。 Lambda Durable Functions は、長時間実行されるタスクにおいて最大 1 年間の実行停止と自動チェックポイント、障害復旧を可能にし、信頼性の高いマルチステップアプリケーションや AI ワークフローを構築できます。 Amazon EMR Serverless は、 Apache Spark ワークロード向けに サーバーレスストレージ を提供し、ローカルストレージのプロビジョニングを不要にすることで、データ処理コストを最大 20% 削減し、ディスク容量不足によるジョブ失敗を防ぎます。 Amazon S3 Tables には 2 つの新機能が追加されました。データアクセスパターンの変化に応じてストレージコストを自動最適化する Intelligent-Tiering ストレージクラス と、 AWS リージョン および アカウント 間で Apache Iceberg テーブルの一貫したレプリカを自動的に維持する レプリケーション機能 です。これにより、地理的に分散したコネクテッド車両データの管理が可能になります。また AWS は、 AWS の Virtual Private Cloud (VPC) と他クラウド上の VPC を高速に接続できるマネージドプライベート接続サービス AWS Interconnect – multicloud （プレビュー） を発表しました。 IND308 のセッションでは、 BMW が Amazon API Gateway , AWS Step Functions , AWS Lambda , Amazon Simple Notification Service (SNS) , Amazon Simple Queue Service (SQS) , Amazon DynamoDB を用いて、モノリシックな Java EE アプリケーションからイベント駆動型サーバーレスアーキテクチャへ移行し、Connected Drive のリモートサービス基盤をモダナイズした事例を紹介しました。この新しいソリューションにより、新機能の市場投入までの時間は 60% 短縮され、 AWS インフラコストは 20% 削減され、インフラ運用負荷も軽減されました。現在では、 1 日あたり 166 億件以上のリクエストを処理し、 184 TB 以上のデータと 1 億件の API コールをサブ秒レイテンシーで処理し、 2,450 万台のコネクテッド車両を支えています。 Digital Customer Engagement デジタルカスタマーエンゲージメントは、音声、チャット、デジタルチャネル全体にわたって、シームレスでパーソナライズされ、信頼性の高い体験をエンドユーザーに提供すると同時に、ブランドの一貫性、コンプライアンス、運用ガバナンスを維持するというお客様のニーズによって推進されています。今回の発表では、会話型 AI モデルおよび本番環境で利用可能なエージェントに焦点が当てられました。 Amazon Nova 2 モデルファミリー は、顧客とのインタラクションの選択肢を拡張します。音声から音声までの体験を提供する Amazon Nova 2 Sonic 、 100 万トークンのコンテキストウィンドウによる拡張推論を可能にする Amazon Nova 2 Lite 、そしてテキスト、画像、動画、音声を横断したマルチモーダル入力に対応する Amazon Nova 2 Omni （プレビュー） が含まれます。カスタマージャーニーにおけるアクション実行のために、 Amazon Nova Act は、フォーム処理、検索および抽出、予約、 QA などの UI ワークフロー自動化を、信頼性高く構築、デプロイ、運用することを支援します。 エンタープライズ規模で安全かつ効果的にエージェントを構築、デプロイ、運用するために、 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ機能、自然な対話機能を提供します。これにより、企業全体でエージェントを展開することが可能になります。さらに、 Amazon Bedrock では 18 種類のフルマネージドなオープンウェイトモデルを含むモデルカタログが拡充され 、品質、レイテンシー、コストのバランスに応じた柔軟な選択が可能になりました。 IND320 のセッションでは、 Toyota Motor North America と Toyota Connected が、 Amazon Bedrock を用いて AWS 上にエージェント型 AI プラットフォームを構築し、 RAG （検索拡張生成）ベースのディーラーアシスタントを提供している事例を紹介しました。このアシスタントは、公式な車両情報へ即座にアクセスでき、月間 7,000 件以上のインタラクションをサポートしています。 Toyota のプラットフォームは 2026 年に次世代システムへと進化し、 AgentCore Runtime , AgentCore Identity , AgentCore Memory を追加することで、安全にスケールし、ローカル在庫確認などのアクション実行を可能にする予定です。 IND3329 のセッションでは、 Cox Automotive が、エージェント型 AI をプロトタイプから本番環境へわずか数週間で移行した事例を紹介しました。同社は Amazon Bedrock AgentCore と Strands Agents を用いて 5 つのエージェント型 AI 製品をデプロイしました。完全自律型のバーチャルアシスタントは、人の介在なしに営業時間外の販売およびサービス対応を行っており、強力なガードレール、評価、コスト管理によって支えられています。 SPS313 のセッションでは、Volkswagen Group が、独自の画像ライブラリでトレーニングした カスタムファインチューニング 済みの拡散モデルと Amazon Nova を組み合わせ、各市場においてブランドガイドラインを自動的に適用することで、グローバルマーケティングをどのようにスケールさせたかを説明しました。 IND3326 および INV204 のセッションでは、大規模なデジタルエンゲージメントに焦点が当てられました。 Formula 1 は AWS Media Services とエージェント型 AI を活用し、同期されたマルチビュー配信を実現するとともに、運用上の根本原因分析を自動化しています。一方 Lyft は、会話型エージェントを用いてカスタマーサポートを変革し、解決までの時間を数分に短縮し、やり取りの半数以上を人のエージェントを介さずに解決しています。 製造およびサプライチェーン 生成 AI (GenAI) 、特にエージェント型 AI は、製造およびサプライチェーン管理を大きく変革しています。 Matt Garman の 基調講演 では、推論と行動が可能な最新の AI エージェント が、これまで専門家による判断や手作業を必要としていたタスクを担い始めていることが紹介されました。 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ、自然な対話機能を追加し、信頼できる AI エージェントの展開を可能にします。これにより、メーカーは予知保全、品質管理、現場最適化といった領域で AI ソリューションを安心してスケールできます。さらに、 Strands Agents の エッジデバイス対応 により、 Strands Agents SDK を使って小規模デバイス上で動作する自律型 AI エージェントを構築でき、自動車、製造、ロボティクス分野における新たなエージェント型ユースケースが実現します。 IND367 のセッションでは、 Audi が AWS 上でトレーニングした AI ベースの品質検査モデルを製造品質プロセスに統合し、溶接継ぎ目の検査を手動サンプリングを大幅に上回るカバレッジで実施している事例を紹介しました。これにより、ほぼ 100% に近い溶接検査が可能となり、人的作業の削減と品質監視の向上を同時に実現しています。 HMC217 のセッションでは、 Rivian が AWS Outposts Gen2 を使用して、 SCADA （監視制御およびデータ収集）、 MES （製造実行システム）、ロボット制御などのミッションクリティカルな工場アプリケーションをエッジで実行している事例を紹介しました。クラウドネイティブなハイブリッド環境により、運用負荷を低減し、キャパシティプランニングを簡素化しています。 PEX305 のセッションでは、 Toyota が IBM などのパートナーとともに、 Amazon SageMaker AI などの AWS サービスを用いて、車両製造および物流全体にわたる配送 ETA の予測モデルを構築している事例を紹介しました。 API206-S のセッションでは、富士通が Amazon Bedrock AgentCore を活用してエージェント型サプライチェーンワークフローを実現している事例を共有しました。この仕組みでは、ガーディアンエージェントがエージェントの出力を継続的に監視し、エージェントの逸脱を修正します。 プロダクトエンジニアリング 自動車メーカーのプロダクトエンジニアリングチームは、コンセプト設計、生成最適化、シミュレーション、拠点間のエンジニアリングコラボレーションにおいて、迅速なサイクルを必要とします。 AWS は、 5 GHz プロセッサと 3 TiB のメモリを備えた新しい メモリ最適化・高周波数 EC2 X8aedz インスタンス の提供開始を発表しました。これらは、シミュレーションの前処理・後処理や大規模なエンジニアリングデータセットなど、メモリ集約型ワークロードを支援します。 Amazon SageMaker HyperPod のチェックポイントレスかつエラスティックなトレーニング は、エンジニアリング向け AI モデルの大規模トレーニングと反復に適用できます。グローバルチーム間で CAD、シミュレーション、テスト成果物を管理するために、 Amazon FSx for NetApp ONTAP と Amazon S3 の統合により、ファイルベースのエンジニアリングワークフローを維持しながら、 S3 スケールでのデータ階層化、共有、分析が可能になります。 CMP340 のセッションでは、 Toyota が AWS Parallel Computing Service (PCS) によって、 高性能コンピューティング (HPC) のセットアップ時間を 6 週間からわずか 30 分に短縮した事例を紹介しました。研究者はオンデマンドで大規模な CPU および GPU シミュレーションを起動し、長時間実行ジョブを実行し、ジョブ完了時に自動でリソースを停止できるようになり、ベンダーによる遅延が解消されました。 マイグレーションとモダナイゼーション AWS の自動車および製造業のお客様は、 AI を活用したサービスによってアプリケーションの移行とモダナイゼーションを加速しています。 AWS は AWS Transform を エージェント型機能 で拡張し、 Windows .NET アプリケーション、 VMware 環境、メインフレームのモダナイゼーションを支援しています。これにより、 11 億行を超えるコードを分析し、 81 万時間以上の手作業を削減しました。 AWS Transform custom は、あらゆるコード、API、フレームワーク、ランタイム、アーキテクチャ、言語、さらには企業独自のプログラミング言語やフレームワークに対して、組織全体でのモダナイゼーションを加速します。事前構築済みおよびカスタムの変換を通じて、多様なコードベースに対して一貫性と再現性のあるモダナイゼーションを実現します。また、 Amazon EKS Capabilities は、モダナイズされたプラットフォームにおけるワークロードのオーケストレーションとクラウドリソース管理を簡素化します。 IND218-S のセッションでは、 Mercedes-Benz が AWS 上で GenAI とエージェント型リファクタリングを活用し、メインフレームベースのグローバル受注システムをモダナイズした事例を紹介しました。 130 万行の COBOL を Java に変換し、最初のコミットから本番稼働まで 6 か月未満で、無事故のリリースを達成しました。 INV212 のセッションでは、 BMW と AWS が、 AWS Transform におけるドメイン特化エージェントが、調査、計画、リファクタリング、テストをどのように加速するかを紹介しました。AI 機能によって支えられた移行ファクトリーにより、テスト作成時間を数日から数時間に短縮し、75% 以上の時間と効率の改善、最大 60% のテストカバレッジ向上を達成しました。 BMW は MAM205 のセッションで再び登壇し、エージェント型 AI を活用したリファクタリングによってメインフレーム移行のリスクをどのように低減したかを詳しく説明しました。さらに、 PEX203 のセッションでは、 AWS Transform for VMware および .NET により、 EC2 と Aurora PostgreSQL 上の Linux ベースアーキテクチャへフルスタック Windows アプリケーションを移行できることが説明されました。 Toyota Motor North America は、サプライチェーンアプリケーションのメインフレーム移行を 50% 以上加速しています。 まとめ 本ブログでは、自動車および製造業界向けに関連性の高い AWS の発表内容と BMW 、 Toyota 、 Rivian 、 Nissan 、 Mercedes-Benz 、 Zoox といったお客様の革新的な事例をまとめました。これらの発表を確認し、ご自身のワークロードを支援できる機能を見極めていただくことをお勧めします。 新しい機能が組織の俊敏性と効率性をどのように支援できるかについて詳しく知りたい場合は、ぜひ AWS にご相談ください。 AWS for Automotive のページ をご覧いただくか、担当の AWS チームまでお気軽に お問い合わせ ください。 本ブログの翻訳はソリューションアーキテクトのショーン・セーヒー (Shawn Sehy) が担当しました。原文は「 AWS re:Invent 2025 Recap for Automotive and Manufacturing 」です。

AWS の年次フラッグシップイベントである  AWS re:Invent 2025  は、 2025 年 12 月 1 日から 5 日にかけて開催され、5 日間にわたる基調講演、ブレイクアウトセッション、製品発表、ライブデモが行われました。本イベントでは、多数の 新しいサービスや機能 が発表されました。本振り返りでは、自動車および製造業にとって特に重要なハイライトとして、主要な発表内容、実際のお客様事例、注目のデモを取り上げます。内容は戦略的なワークロード領域ごとに整理されており、現在のプロジェクトや優先事項に対応するトピックをすぐに確認できる構成になっています。 Autonomous Mobility 自動運転車 (AV) および高度運転支援システム (ADAS) の開発は、計算性能とストレージリソースの両面で非常に高い要求が課されるワークロードです。 AWS CEO の Matt Garman は 基調講演 において、 AWS Trainium3 チップを搭載した AWS Trainium3 UltraServers の一般提供開始を発表し、次世代の Trainium4 チップに関する展望も共有しました。Trainium3 UltraServers は、 AI トレーニングおよび推論ワークロード向けに高いパフォーマンスを提供し、 Trainium2 UltraServers と比較して最大 4.4 倍の計算性能、 4 倍のエネルギー効率、そして約 4 倍のメモリ帯域幅を実現します。これらは、次世代のエージェンティック AI 、推論モデル、強化学習に最適化されており、自動運転の意思決定システムのトレーニングや、複雑な運転シナリオを推論できる AI エージェントの開発に適しています。 AV および ADAS ワークロードでは、 Amazon S3 の最大オブジェクトサイズが 5 TB から 50 TB に 10 倍拡張されたことで、 LiDAR のポイントクラウド埋め込みやカメラ特徴ベクトルなど、巨大なセンサーデータセットの保存と分析が容易になりました。 Amazon S3 Vectors は現在一般提供されており、 1 インデックスあたり最大 20 億ベクトルまでスケールし、最大 90% のコスト削減を実現します。これにより、ペタバイト規模のデータで学習された知覚システムを支援します。 AWS はさらに、 Amazon OpenSearch Service においてサーバーレス GPU アクセラレーション と自動最適化されたベクトルインデックスを導入しました。これにより、大規模なベクトルデータベースを最大 10 倍高速かつ低コストで構築でき、リアルタイムの類似度検索が可能になります。加えて、 AWS Clean Rooms におけるプライバシー強化型の 合成データ生成 により、エッジケース向けのトレーニングデータ作成が可能になりました。また、 Amazon Nova 2 Omni （プレビュー） は、テキスト、画像、動画、音声を横断したマルチモーダル分析と推論を実現し、知覚および意思決定支援ワークフローを支えます。 AMZ304 のブレイクアウトセッションでは、 Zoox が Amazon SageMaker HyperPod を使用して自律走行ロボタクシー向けの基盤モデルをトレーニングしている事例を紹介しました。カメラ、 LiDAR 、レーダーデータを処理するマルチモーダルモデルを実行し、複雑なエッジケースに対応しています。Amazon SageMaker の Hybrid Sharded Data Parallelism (HSDP) とテンソル並列処理を組み合わせることで、 64 GPU を超える環境で 95% の GPU 利用率を達成し、 AWS Data Transfer Terminals を通じて最大 400 Gbps の速度で毎時最大 4 TB の車両データを取り込んでいます。Zoox は,   正式にサービスを開始した自律走行ロボタクシーサービスのデモンストレーションを、 re:Invent 期間中に実施しました。 Software Defined Vehicle (SDV) AWS は 2025 年 7 月に、仕様駆動型開発によって構想から本番までを支援する AI IDE Kiro をリリースしました。さらに AWS は、新たなクラスの AI エージェントである 3 つの frontier agents 発表しました。 Kiro 自律エージェント、 AWS Security Agent 、 AWS DevOps Agent は、ソフトウェア開発チームの一員として数時間から数日間稼働し続けることができます。 Kiro 自律エージェント は、ソフトウェア定義車両開発を加速するための仮想開発者として活用できます。 Matt Garman は基調講演で、 AWS 史上最も高性能かつ高効率な CPU である Graviton5 も紹介しました。 Graviton5 ベースの新しい Amazon EC2 インスタンスは、前世代と比較して最大 25% 高い性能を提供し、キャッシュサイズは 5 倍に拡大されています。 IND382 のセッションでは、日産自動車が AWS 上での新しい Nissan Scalable Open Software Platform を通じて、ソフトウェア定義車両の開発をどのように加速しているかを共有しました。このプラットフォームにより、テストは 75% 高速化され、世界中の 5,000 人以上の開発者がソフトウェア開発、データ管理、車両運用で協働できる統合クラウド環境が提供され、機能更新の迅速化が実現されています。また CMP360 のセッションでは、 AWS が Graviton5 の設計と性能について詳しく解説し、 Siemens 、 Synopsys 、 Honeycomb 、 Airbnb 、 SAP などの顧客による実ワークロードでの結果と、 Graviton プラットフォームへの移行および運用に関する知見が共有されました。 Connected Mobility すべての AWS お客様は、ワークロード向けに伸縮性と信頼性の高いコンピューティング基盤の恩恵を受けていますが、これはコネクテッドモビリティのバックエンドを運用する自動車業界のお客様にも当てはまります。 AWS は、 AWS Lambda (Lambda), Amazon Elastic Kubernetes (Amazon EKS) , Amazon EMR に対して、コネクテッドモビリティのユースケースに関連する新機能を発表しました。 AWS は Lambda Managed Instances を発表しました。これは、サーバーレスの運用の簡便さを維持しながら、独自の Amazon EC2 上で Lambda 関数を実行できる新機能です。この機能により、特定のコンピューティング要件への対応や、定常的なワークロードのコスト最適化が可能になります。 Lambda Durable Functions は、長時間実行されるタスクにおいて最大 1 年間の実行停止と自動チェックポイント、障害復旧を可能にし、信頼性の高いマルチステップアプリケーションや AI ワークフローを構築できます。 Amazon EMR Serverless は、 Apache Spark ワークロード向けに サーバーレスストレージ を提供し、ローカルストレージのプロビジョニングを不要にすることで、データ処理コストを最大 20% 削減し、ディスク容量不足によるジョブ失敗を防ぎます。 Amazon S3 Tables には 2 つの新機能が追加されました。データアクセスパターンの変化に応じてストレージコストを自動最適化する Intelligent-Tiering ストレージクラス と、 AWS リージョン および アカウント 間で Apache Iceberg テーブルの一貫したレプリカを自動的に維持する レプリケーション機能 です。これにより、地理的に分散したコネクテッド車両データの管理が可能になります。また AWS は、 AWS の Virtual Private Cloud (VPC) と他クラウド上の VPC を高速に接続できるマネージドプライベート接続サービス AWS Interconnect – multicloud （プレビュー） を発表しました。 IND308 のセッションでは、 BMW が Amazon API Gateway , AWS Step Functions , AWS Lambda , Amazon Simple Notification Service (SNS) , Amazon Simple Queue Service (SQS) , Amazon DynamoDB を用いて、モノリシックな Java EE アプリケーションからイベント駆動型サーバーレスアーキテクチャへ移行し、Connected Drive のリモートサービス基盤をモダナイズした事例を紹介しました。この新しいソリューションにより、新機能の市場投入までの時間は 60% 短縮され、 AWS インフラコストは 20% 削減され、インフラ運用負荷も軽減されました。現在では、 1 日あたり 166 億件以上のリクエストを処理し、 184 TB 以上のデータと 1 億件の API コールをサブ秒レイテンシーで処理し、 2,450 万台のコネクテッド車両を支えています。 Digital Customer Engagement デジタルカスタマーエンゲージメントは、音声、チャット、デジタルチャネル全体にわたって、シームレスでパーソナライズされ、信頼性の高い体験をエンドユーザーに提供すると同時に、ブランドの一貫性、コンプライアンス、運用ガバナンスを維持するというお客様のニーズによって推進されています。今回の発表では、会話型 AI モデルおよび本番環境で利用可能なエージェントに焦点が当てられました。 Amazon Nova 2 モデルファミリー は、顧客とのインタラクションの選択肢を拡張します。音声から音声までの体験を提供する Amazon Nova 2 Sonic 、 100 万トークンのコンテキストウィンドウによる拡張推論を可能にする Amazon Nova 2 Lite 、そしてテキスト、画像、動画、音声を横断したマルチモーダル入力に対応する Amazon Nova 2 Omni （プレビュー） が含まれます。カスタマージャーニーにおけるアクション実行のために、 Amazon Nova Act は、フォーム処理、検索および抽出、予約、 QA などの UI ワークフロー自動化を、信頼性高く構築、デプロイ、運用することを支援します。 エンタープライズ規模で安全かつ効果的にエージェントを構築、デプロイ、運用するために、 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ機能、自然な対話機能を提供します。これにより、企業全体でエージェントを展開することが可能になります。さらに、 Amazon Bedrock では 18 種類のフルマネージドなオープンウェイトモデルを含むモデルカタログが拡充され 、品質、レイテンシー、コストのバランスに応じた柔軟な選択が可能になりました。 IND320 のセッションでは、 Toyota Motor North America と Toyota Connected が、 Amazon Bedrock を用いて AWS 上にエージェント型 AI プラットフォームを構築し、 RAG （検索拡張生成）ベースのディーラーアシスタントを提供している事例を紹介しました。このアシスタントは、公式な車両情報へ即座にアクセスでき、月間 7,000 件以上のインタラクションをサポートしています。 Toyota のプラットフォームは 2026 年に次世代システムへと進化し、 AgentCore Runtime , AgentCore Identity , AgentCore Memory を追加することで、安全にスケールし、ローカル在庫確認などのアクション実行を可能にする予定です。 IND3329 のセッションでは、 Cox Automotive が、エージェント型 AI をプロトタイプから本番環境へわずか数週間で移行した事例を紹介しました。同社は Amazon Bedrock AgentCore と Strands Agents を用いて 5 つのエージェント型 AI 製品をデプロイしました。完全自律型のバーチャルアシスタントは、人の介在なしに営業時間外の販売およびサービス対応を行っており、強力なガードレール、評価、コスト管理によって支えられています。 SPS313 のセッションでは、Volkswagen Group が、独自の画像ライブラリでトレーニングした カスタムファインチューニング 済みの拡散モデルと Amazon Nova を組み合わせ、各市場においてブランドガイドラインを自動的に適用することで、グローバルマーケティングをどのようにスケールさせたかを説明しました。 IND3326 および INV204 のセッションでは、大規模なデジタルエンゲージメントに焦点が当てられました。 Formula 1 は AWS Media Services とエージェント型 AI を活用し、同期されたマルチビュー配信を実現するとともに、運用上の根本原因分析を自動化しています。一方 Lyft は、会話型エージェントを用いてカスタマーサポートを変革し、解決までの時間を数分に短縮し、やり取りの半数以上を人のエージェントを介さずに解決しています。 製造およびサプライチェーン 生成 AI (GenAI) 、特にエージェント型 AI は、製造およびサプライチェーン管理を大きく変革しています。 Matt Garman の 基調講演 では、推論と行動が可能な最新の AI エージェント が、これまで専門家による判断や手作業を必要としていたタスクを担い始めていることが紹介されました。 Amazon Bedrock AgentCore は、品質評価、ポリシー制御、強化されたメモリ、自然な対話機能を追加し、信頼できる AI エージェントの展開を可能にします。これにより、メーカーは予知保全、品質管理、現場最適化といった領域で AI ソリューションを安心してスケールできます。さらに、 Strands Agents の エッジデバイス対応 により、 Strands Agents SDK を使って小規模デバイス上で動作する自律型 AI エージェントを構築でき、自動車、製造、ロボティクス分野における新たなエージェント型ユースケースが実現します。 IND367 のセッションでは、 Audi が AWS 上でトレーニングした AI ベースの品質検査モデルを製造品質プロセスに統合し、溶接継ぎ目の検査を手動サンプリングを大幅に上回るカバレッジで実施している事例を紹介しました。これにより、ほぼ 100% に近い溶接検査が可能となり、人的作業の削減と品質監視の向上を同時に実現しています。 HMC217 のセッションでは、 Rivian が AWS Outposts Gen2 を使用して、 SCADA （監視制御およびデータ収集）、 MES （製造実行システム）、ロボット制御などのミッションクリティカルな工場アプリケーションをエッジで実行している事例を紹介しました。クラウドネイティブなハイブリッド環境により、運用負荷を低減し、キャパシティプランニングを簡素化しています。 PEX305 のセッションでは、 Toyota が IBM などのパートナーとともに、 Amazon SageMaker AI などの AWS サービスを用いて、車両製造および物流全体にわたる配送 ETA の予測モデルを構築している事例を紹介しました。 API206-S のセッションでは、富士通が Amazon Bedrock AgentCore を活用してエージェント型サプライチェーンワークフローを実現している事例を共有しました。この仕組みでは、ガーディアンエージェントがエージェントの出力を継続的に監視し、エージェントの逸脱を修正します。 プロダクトエンジニアリング 自動車メーカーのプロダクトエンジニアリングチームは、コンセプト設計、生成最適化、シミュレーション、拠点間のエンジニアリングコラボレーションにおいて、迅速なサイクルを必要とします。 AWS は、 5 GHz プロセッサと 3 TiB のメモリを備えた新しい メモリ最適化・高周波数 EC2 X8aedz インスタンス の提供開始を発表しました。これらは、シミュレーションの前処理・後処理や大規模なエンジニアリングデータセットなど、メモリ集約型ワークロードを支援します。 Amazon SageMaker HyperPod のチェックポイントレスかつエラスティックなトレーニング は、エンジニアリング向け AI モデルの大規模トレーニングと反復に適用できます。グローバルチーム間で CAD、シミュレーション、テスト成果物を管理するために、 Amazon FSx for NetApp ONTAP と Amazon S3 の統合により、ファイルベースのエンジニアリングワークフローを維持しながら、 S3 スケールでのデータ階層化、共有、分析が可能になります。 CMP340 のセッションでは、 Toyota が AWS Parallel Computing Service (PCS) によって、 高性能コンピューティング (HPC) のセットアップ時間を 6 週間からわずか 30 分に短縮した事例を紹介しました。研究者はオンデマンドで大規模な CPU および GPU シミュレーションを起動し、長時間実行ジョブを実行し、ジョブ完了時に自動でリソースを停止できるようになり、ベンダーによる遅延が解消されました。 マイグレーションとモダナイゼーション AWS の自動車および製造業のお客様は、 AI を活用したサービスによってアプリケーションの移行とモダナイゼーションを加速しています。 AWS は AWS Transform を エージェント型機能 で拡張し、 Windows .NET アプリケーション、 VMware 環境、メインフレームのモダナイゼーションを支援しています。これにより、 11 億行を超えるコードを分析し、 81 万時間以上の手作業を削減しました。 AWS Transform custom は、あらゆるコード、API、フレームワーク、ランタイム、アーキテクチャ、言語、さらには企業独自のプログラミング言語やフレームワークに対して、組織全体でのモダナイゼーションを加速します。事前構築済みおよびカスタムの変換を通じて、多様なコードベースに対して一貫性と再現性のあるモダナイゼーションを実現します。また、 Amazon EKS Capabilities は、モダナイズされたプラットフォームにおけるワークロードのオーケストレーションとクラウドリソース管理を簡素化します。 IND218-S のセッションでは、 Mercedes-Benz が AWS 上で GenAI とエージェント型リファクタリングを活用し、メインフレームベースのグローバル受注システムをモダナイズした事例を紹介しました。 130 万行の COBOL を Java に変換し、最初のコミットから本番稼働まで 6 か月未満で、無事故のリリースを達成しました。 INV212 のセッションでは、 BMW と AWS が、 AWS Transform におけるドメイン特化エージェントが、調査、計画、リファクタリング、テストをどのように加速するかを紹介しました。AI 機能によって支えられた移行ファクトリーにより、テスト作成時間を数日から数時間に短縮し、75% 以上の時間と効率の改善、最大 60% のテストカバレッジ向上を達成しました。 BMW は MAM205 のセッションで再び登壇し、エージェント型 AI を活用したリファクタリングによってメインフレーム移行のリスクをどのように低減したかを詳しく説明しました。さらに、 PEX203 のセッションでは、 AWS Transform for VMware および .NET により、 EC2 と Aurora PostgreSQL 上の Linux ベースアーキテクチャへフルスタック Windows アプリケーションを移行できることが説明されました。 Toyota Motor North America は、サプライチェーンアプリケーションのメインフレーム移行を 50% 以上加速しています。 まとめ 本ブログでは、自動車および製造業界向けに関連性の高い AWS の発表内容と BMW 、 Toyota 、 Rivian 、 Nissan 、 Mercedes-Benz 、 Zoox といったお客様の革新的な事例をまとめました。これらの発表を確認し、ご自身のワークロードを支援できる機能を見極めていただくことをお勧めします。 新しい機能が組織の俊敏性と効率性をどのように支援できるかについて詳しく知りたい場合は、ぜひ AWS にご相談ください。 AWS for Automotive のページ をご覧いただくか、担当の AWS チームまでお気軽に お問い合わせ ください。 本ブログの翻訳はソリューションアーキテクトのショーン・セーヒー (Shawn Sehy) が担当しました。原文は「 AWS re:Invent 2025 Recap for Automotive and Manufacturing 」です。

みなさん、こんにちは。 いなりく です。 新年あけましておめでとうございます。みなさん Kiro ライフをいかがお過ごしでしょうか。 Kiro CLI 1.24.0 では、 大規模なドキュメントセットの段階的な読み込みを可能にする Skills 、 カスタム Diff ツール 、 18 言語に対応した組み込みコードインテリジェンス 、 リモート認証 、 web_fetch ツールの詳細な権限管理 、 長時間のセッションをスムーズに維持する会話 圧縮の詳細なコントールが導入されました。これらのアップデートが私の Kiro ライフを更に快適にしてくれたので、今回はこれらの追加された機能を深堀ってご紹介します。Kiro って何？という方は「 Kiroweeeeeeek in Japan 開催のお知らせ 」を読んでいただけると Kiro の全体像を掴んでいただけると思います。気になるアップデートのセクションおよび移行ガイドだけを読んでいただいても問題ありません。Kiro CLI の v.1.21.0 から v.1.23.0 までのアップデートに関しては「 Kiro CLI 新機能まとめ : v1.21.0 から v1.23.0 」をぜひお読み下さい。 アップデート１ : Skills による段階的なコンテキスト読み込み アップデート２ : カスタム Diff ツール アップデート 3 : AST パターンツールによる正確なリファクタリング アップデート 4 : 改善されたコードインテリジェンス アップデート 5 : 会話圧縮の詳細なコントロール アップデート 6 : web_fetch ツールの詳細な URL 権限管理 アップデート 7 : リモート認証 移行ガイド アップデート 1 : Skills による段階的なコンテキスト読み込み Skills は起動時にはメタデータ（名前と説明）のみが読み込まれ、エージェントが必要と判断したときにのみ完全なコンテンツが読み込まれます。これにより、コンテキストウィンドウを効率的に管理しながら、広範なドキュメントへのアクセスを提供できます。 Skills の仕組み 従来の Steering ファイルは、エージェント起動時にすべてのコンテンツをコンテキストウィンドウに読み込みます。これは小規模なファイルには適していますが、大規模なドキュメントセットではコンテキストウィンドウを圧迫してしまいます。 Skills は以下のアプローチを採用しています。 起動時 ：名前と説明のみが読み込まれる 実行時 ：エージェントが関連性を判断し、必要に応じて完全なコンテンツを読み込む 効率性 ：使用されないドキュメントはコンテキストを消費しない Skills ファイルの作成 Skills ファイルには、YAML フロントマターで記述された説明的なメタデータが必要です。エージェントが完全なコンテンツを読み込むタイミングを確実に判断できるよう、具体的な説明を記述してください。 --- name: dynamodb-data-modeling description: DynamoDB データモデリングのベストプラクティスガイド。DynamoDB スキーマの設計または分析時に使用。 --- # DynamoDB データモデリング ## 概要 DynamoDB は NoSQL データベースで、適切なデータモデリングが重要です... ## パーティションキーの設計 パーティションキーは均等に分散する必要があります... ## ソートキーのパターン ソートキーを使用すると、効率的なクエリパターンが可能になります... Skills と Steering の使い分け Skills を使用する場合： 大規模なドキュメントセット（API リファレンス、アーキテクチャガイドなど） 特定のタスクでのみ必要な専門知識 コンテキストウィンドウの効率的な管理が必要な場合 複数のトピックに分かれた参照ドキュメント Steering を使用する場合： すべての会話で常に必要な小規模なファイル（README、設定ファイルなど） プロジェクトの基本情報やコンテキスト エージェントの動作を常に制御したいコーディング規約やスタイルガイド カスタムエージェント設定での Steering/Skills の使用 カスタムエージェントでは Skills/Steering ファイルは自動で読み込まれず、カスタムエージェント設定ファイルの resources フィールドで明示的に指定する必要があります。Glob パターンを使用すると、複数の SKill ファイルを一度に含めることができます。エージェントは各 Skills のメタデータを読み込み、会話の文脈に基づいて関連する Skill を自動的に読み込みます。 以下の例では README.md と Steering ファイル（coding-standards.md、project-rules.md）はカスタムエージェントで常に読み込まれ、Skills として、api-reference.md、architecture-guide.md、deployment-guide.md が必要なときだけ読み込まれます。 詳細については、 Skills リソースのドキュメント を参照してください。 { "resources": [ "file://README.md", "file://.kiro/steering/coding-standards.md", "file://.kiro/steering/project-rules.md", "skill://docs/api-reference.md", "skill://docs/architecture-guide.md", "skill://docs/deployment-guide.md" ] } アップデート ２ : カスタム Diff ツール Kiro がファイルの変更を提案する際、デフォルトでは組み込みの Diff ツールを使用して変更内容を表示します。1.24.0 では、外部の Diff ツールを設定できるようになり、シンタックスハイライト、サイドバイサイド表示、お気に入りの GUI ツールなど、好みの Diff 表示方法を選択できます。 設定方法 chat.diffTool 設定で、好みの Diff ツールを指定します。 kiro-cli settings chat.diffTool delta カスタム Diff ツール (delta を利用した場合) 組み込みの Diff には以下のコマンドで戻すことができます。 kiro-cli settings -d chat.diffTool 組み込み diff ツール ターミナルツール ターミナルで直接 Diff を表示するツールは、ワークフローを中断しません。 delta ：Git ユーザー向けのシンタックスハイライトと行番号表示 difftastic ：フォーマットの違いを無視する言語対応の構造的 Diff icdiff ：素早いサイドバイサイドのカラー比較 diff-so-fancy ：クリーンで人間が読みやすい出力 colordiff ：シンプルなカラー表示の Diff bat ：Git 統合を備えたシンタックスハイライト GUI ツール 変更内容を別ウィンドウで確認できる GUI ツールもサポートしています： VS Code ： code Meld ： meld KDiff3 ： kdiff3 FileMerge (macOS) ： opendiff Vim ： vimdiff Neovim ： nvim 注意： GUI Diff ツールは表示専用の一時ファイルを開きます。GUI ツールで行った編集は保存されず、Kiro の提案された変更には適用されません。 カスタム引数の使用 引用符で囲むことで、ツールの動作をカスタマイズできます。 # delta でサイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" 詳細については、 カスタム Diff ツールのドキュメント を参照してください。 アップデート 3 : AST パターンツールによる正確なリファクタリング 新しい pattern-search と pattern-rewrite ツールにより、エージェントはテキストの正規表現ではなく、構文木パターンを使用してコードを検索および変換できます。これにより、文字列リテラルやコメント内の誤検出がなくなります。 pattern-search の使用例 # すべての async 関数を検索 > async function $NAME($$$PARAMS) { $$$ } という構造のコードを検索して # 特定のメソッド呼び出しを検索 > $OBJ.setState($$$ARGS) のパターンを検索して pattern-rewrite の使用例 # var を const に変換 > var 宣言をすべて const に書き換えて # 古い API を新しい API に変換 > $O.hasOwnProperty($P) を Object.hasOwn($O, $P) に書き換えて メタ変数を使用してパターンを定義します。 $VAR ：単一のノード（識別子、式）にマッチ $$$ ：ゼロ個以上のノード（文、パラメータ）にマッチ これらのツールは、コードの構造を理解するため、テキストベースの検索置換よりも正確で安全なリファクタリングが可能です。 アップデート 4 : 改善されたコードインテリジェンス Kiro CLI は、セットアップ不要で 18 言語に対応した組み込みのコードインテリジェンスを提供します。エージェントは、シンボル検索、定義へのナビゲーション、構造的なコード検索を即座に実行できます。 対応言語 Bash、C、C++、C#、Elixir、Go、Java、JavaScript、Kotlin、Lua、PHP、Python、Ruby、Rust、Scala、Swift、TSX、TypeScript 組み込み機能 シンボル検索 ：コードベース全体で関数、クラス、変数を検索 ドキュメントシンボル ：ファイル内のすべてのシンボルをリスト表示 シンボルルックアップ ：定義に即座にジャンプ パターン検索 ：AST ベースの構造的コード検索 パターン書き換え ：AST パターンを使用した自動コード変換 コードベースマップ ：ディレクトリ構造の探索とコード構成の理解 コードベース概要 任意のワークスペースの概要を素早く取得できます。 /code overview クリーンな出力には --silent を使用します。 /code overview --silent これは以下の場合に便利です： 新しいコードベースへのオンボーディング プロジェクト構造に関する Q&A セッション 未知のパッケージを素早く理解 LSP 統合（オプション） 参照の検索、ホバードキュメント、リファクタリングのリネームなどの拡張機能を使用するには、LSP 統合を有効にできます。プロジェクトルートで以下のコマンドを実行することで、 .kiro/settings/lsp.json 設定が作成され、言語サーバーが起動します。 /code init 使用例 # シンボルを検索 > UserRepository クラスを検索して # すべての参照を検索 > Person クラスの参照をすべて検索して # 定義に移動 > UserService の定義を検索して # ファイル内のシンボルを取得 > auth.service.ts にはどんなシンボルがある？ # ホバードキュメントを取得 > AuthService の authenticate メソッドのドキュメントは？ # 利用可能なメソッドを発見 > s3Client インスタンスで使えるメソッドは？ 詳細については、 コードインテリジェンスのドキュメント を参照してください。 アップデート 5 : 会話圧縮の詳細なコントロール /compact コマンドを利用することで会話履歴を要約し、重要な情報を保持しながらコンテキストスペースを解放することができます。今回のアップデートでは保持するメッセージと最小コンテキストウィンドウの割合を指定することが可能になりました。 圧縮の仕組み 圧縮は、古いメッセージを要約しながら最近のメッセージを保持します。これにより、会話の文脈を維持しながら、コンテキストウィンドウを効率的に使用できます。 手動圧縮 ： /compact コマンドを実行 自動圧縮 ：コンテキストウィンドウがオーバーフローすると自動的にトリガー 設定 保持するメッセージの量を設定できます。 compaction.excludeMessages （デフォルト：2）：保持する最小メッセージペア数 compaction.excludeContextWindowPercent （デフォルト：2）：保持する最小コンテキストウィンドウの割合 両方の設定が評価され、より保守的な（大きい）値が優先されます。 圧縮後の操作 # 手動で圧縮を実行 /compact # 元のセッションに戻る /chat resume 詳細については、 会話の圧縮のドキュメント を参照してください。 アップデート 6 : web_fetch ツールの詳細な URL 権限管理 エージェント設定を通じて、エージェントがアクセスできる URL を制御できるようになりました。正規表現パターンを使用して、信頼できるドメインを自動的に許可したり、特定のサイトをブロックしたりできます。 設定方法 エージェント設定ファイルの toolsSettings で URL ベースの権限を設定します。 { "toolsSettings": { "web_fetch": { "trusted": [".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com.*"], "blocked": [".*pastebin\\.com.*"] } } } パターンの動作 パターンは正規表現で、自動的に ^ と $ でアンカーされます blocked は trusted よりも優先されます blocked の無効な正規表現は、すべての URL を拒否します（フェイルセーフ） trusted の無効な正規表現はスキップされます 信頼されたパターンに一致しない URL は、承認を求めるプロンプトが表示されます 使用例 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/myorg/.*", ".*stackoverflow\\.com.*" ], "blocked": [ ".*pastebin\\.com.*", ".*privatesite\\.internal.*" ] } } } この設定により、AWS ドキュメント、組織の GitHub リポジトリ、Stack Overflow への自動アクセスが許可され、特定のサイトがブロックされます。 詳細については、 web_fetch ツールのドキュメント を参照してください。 アップデート 7 : リモート認証 リモートマシン（SSH、SSM、コンテナ経由）で Kiro CLI を実行する際、Google または GitHub でサインインできるようになりました。ポートフォワーディングにより、認証が機能します。 Builder ID と IAM Identity Center Builder ID と IAM Identity Center の場合、デバイスコード認証がそのまま機能します。URL とコードをローカルブラウザに入力するだけです。 ソーシャルログイン（Google または GitHub） ソーシャルログインの場合、CLI は PKCE 認証を使用し、ポートフォワーディングが必要です。OAuth コールバックは localhost にリダイレクトされるため、トンネルなしではリモート CLI に到達できません。 リモートマシンでのサインイン手順 kiro-cli login を実行し、「Use for Free with Google or GitHub」を選択 表示されたポート番号をメモ（毎回異なります。例： 49153 ） ローカルマシンの新しいターミナルで、ポートフォワーディングを設定： ssh -L <PORT>:localhost:<PORT> -N user@remote-host <PORT> をステップ 2 のポートに、 user@remote-host をリモート認証情報に置き換えます。 CLI で Enter キーを押し、ローカルブラウザで URL を開きます 認証を完了すると、コールバックがトンネル経由で CLI に到達します SSH ポートフォワーディングの例 # 基本的なポートフォワーディング（49153 を実際のポートに置き換え） ssh -L 49153:localhost:49153 -N user@remote-host # カスタム ID ファイルを使用（EC2 で一般的） ssh -i ~/.ssh/my-key.pem -L 49153:localhost:49153 -N user@remote-host # SSH 設定エイリアスを使用 ssh -L 49153:localhost:49153 -N myserver 詳細については、 リモート認証のドキュメント を参照してください。 移行ガイド 既存の Kiro CLI ユーザーが 1.24.0 にアップグレードする際のガイドラインです。 ステップ 1：常に読み込みが必要ではない Steering ファイルを Skills に変換 既存の Steering ファイルの中に常に読み込みが必要ではないものがある場合は、Skills に変換することを検討してください。 変換前： { "resources": [ "file://docs/api-reference.md", "file://docs/architecture-guide.md" ] } 変換後： 1. 各ファイルに YAML フロントマターを追加 --- name: api-reference description: API リファレンスドキュメント。API エンドポイント、リクエスト/レスポンス形式、認証方法について記載。 --- # API リファレンス ... 2. エージェント設定を更新： { "resources": [ "skill://docs/api-reference.md", "skill://docs/architecture-guide.md" ] } ステップ 2：カスタム Diff ツールの設定 お気に入りの Diff ツールがある場合は、設定してください。 # delta を使用する場合 kiro-cli settings chat.diffTool delta # サイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" ステップ 3：URL 権限の設定 web_fetch ツールを使用している場合は、信頼できるドメインを設定してください。 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/your-org/.*" ] } } } ステップ 4：コードインテリジェンスの有効化 プロジェクトルートで LSP を初期化 /code init まとめ Kiro CLI 1.24.0 は、開発者の生産性を向上させる多くの新機能を提供します。Skills による効率的なコンテキスト管理、カスタム Diff ツールによる柔軟な変更レビュー、18 言語に対応した組み込みコードインテリジェンス、会話の圧縮による長時間セッションのサポート、詳細な URL 権限管理、リモート認証のサポートなど、開発ワークフローを強化する機能が満載です。 今すぐ Kiro CLI 1.24.0 にアップグレードもしくは インストール して、これらの新機能をお試しください！みなさんの Kiro ライフがより快適になることを願っています！ 著者 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

本記事は 2026 年 01 月 13 日 に公開された “Build durable AI agents with LangGraph and Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/build-durable-ai-agents-with-langgraph-and-amazon-dynamodb/ 私は AI エージェントの急速な進化に魅了されてきました。過去 1 年間で、AI エージェントがシンプルなチャットボットから、複雑な問題を推論し、意思決定を行い、長い会話全体でコンテキストを維持できる洗練されたシステムへと成長するのを見てきました。しかし、エージェントの性能はメモリの質次第です。 この記事では、 Amazon DynamoDB と LangGraph を使用し、新しい DynamoDBSaver コネクタを活用して、耐久性のある状態管理を備えた本番環境対応の AI エージェントを構築する方法を紹介します。DynamoDBSaver は、AWS が Amazon DynamoDB 向けに保守している LangGraph チェックポイントライブラリです。これは、DynamoDB と LangGraph 専用に構築された本番環境対応の永続化レイヤーを提供し、ペイロードのサイズに基づいてインテリジェントに処理しながらエージェントの状態を保存します。 この実装により、エージェントがスケールし、障害から回復し、長時間実行されるワークフローを維持するために必要な永続性を得る方法を学びます。 Amazon DynamoDB の概要 Amazon DynamoDB は、あらゆる規模で 1 桁ミリ秒のパフォーマンスを実現する、サーバーレスでフルマネージドな分散 NoSQL データベースです。構造化データまたは半構造化データを保存し、一貫したミリ秒単位のレイテンシーでクエリを実行し、サーバーやインフラストラクチャを管理することなく自動的にスケールできます。DynamoDB は低レイテンシーと高可用性を実現するように構築されているため、セッションデータ、ユーザープロファイル、メタデータ、またはアプリケーションの状態を保存するためによく使用されます。これらの同じ特性により、AI エージェントのチェックポイントとスレッドメタデータを保存するための理想的な選択肢となっています。 LangGraph の紹介 LangGraph は、複雑なグラフベースの AI ワークフローを構築するために設計された LangChain のオープンソースフレームワークです。プロンプトと関数を一直線に連鎖させる代わりに、LangGraph では分岐、マージ、ループが可能なノードを定義できます。各ノードはタスクを実行し、エッジがノード間のフローを制御します。 LangGraph はいくつかの重要な概念を導入しています: スレッド (Threads) : スレッドは、一連の実行の累積状態を含む各チェックポイントに割り当てられる一意の識別子です。グラフが実行されると、その状態はスレッドに永続化されます。これには、config で thread_id を指定する必要があります ( {"configurable": {"thread_id": "1"}} )。状態を永続化するには、実行前にスレッドを作成する必要があります。 チェックポイント (Checkpoints) : チェックポイントは、各スーパーステップで保存されるグラフ状態のスナップショットで、config、メタデータ、状態チャネル値、実行する次のノード、タスク情報 (エラーや中断データを含む) を含む StateSnapshot オブジェクトで表されます。チェックポイントは永続化され、後でスレッドの状態を復元できます。たとえば、シンプルな 2 ノードグラフは 4 つのチェックポイントを作成します: START での空のチェックポイント、node_a の前のユーザー入力を含むもの、node_b の前の node_a の出力を含むもの、そして END での node_b の出力を含む最終的なものです。 永続性 (Persistence) : 永続性は、チェックポインタの実装を使用して、チェックポイントがどこにどのように保存されるか (メモリ内、データベース、外部ストレージなど) を決定します。チェックポインタは各スーパーステップでスレッドの状態を保存し、履歴状態の取得を可能にし、グラフがチェックポイントから再開したり、以前の実行状態を復元したりできるようにします。 永続性により、ヒューマン・イン・ザ・ループレビュー、リプレイ、障害後の再開、状態間のタイムトラベルなどの高度な機能が可能になります。 InMemorySaver は、LangGraph の組み込みチェックポイントメカニズムで、会話の状態とグラフ実行履歴をメモリに保存し、永続性、タイムトラベルデバッグ、ヒューマン・イン・ザ・ループワークフローなどの機能を有効にします。 InMemorySaver は高速なプロトタイピングに使用できますが、状態はメモリ内にのみ存在し、アプリケーションの再起動時に失われます。 次の図は、LangGraph のチェックポイントアーキテクチャを示しています。高レベルのワークフロー (スーパーステップ) が START から END までノードを通じて実行される一方で、チェックポインタが継続的に状態スナップショットをメモリ ( InMemorySaver ) に保存します: 永続性が重要な理由 デフォルトでは、LangGraph は InMemorySaver を使用してチェックポイントをメモリに保存します。これはセットアップが不要で、即座に読み書きアクセスが可能なため、実験には最適です。 しかし、メモリ内ストレージには 2 つの大きな制限があります。それは一時的でローカルであることです。プロセスが停止すると、データは失われます。複数のワーカーを実行する場合、各インスタンスは独自のメモリを保持します。他の場所で開始されたセッションを再開することはできず、ワークフローが途中でクラッシュした場合に回復することもできません。 本番環境では、これは受け入れられません。エージェントが中断した場所から再開し、ノード間でスケールし、分析や監査のために履歴を保持できる、永続的でフォールトトレラントなストアが必要です。そこで DynamoDBSaver の出番です。 複雑な複数ステップの問い合わせを処理するカスタマーサポートエージェントを構築しているシナリオを想像してください。顧客が注文について尋ね、エージェントが情報を取得し、応答を生成し、応答を送信する前に人間の承認を待ちます。 しかし、次のような場合はどうなるでしょうか: ワークフローの途中でサーバーがタイムアウトした場合 複数のワーカーにスケールする必要がある場合 顧客が数時間後に戻って会話を続ける場合 エージェントの意思決定プロセスを監査したい場合 メモリ内ストレージでは、お手上げです。プロセスが停止した瞬間に、すべてが消えてしまいます。各ワーカーは独自の分離された状態を維持します。再開、リプレイ、または何が起こったかを確認する方法はありません。 DynamoDBSaver の紹介 langgraph-checkpoint-aws ライブラリは、AWS 専用に構築された永続化レイヤーを提供します。 DynamoDBSaver は、軽量なチェックポイントメタデータを DynamoDB に保存し、大きなペイロードには Amazon S3 を使用します。 仕組みは次のとおりです: 小さなチェックポイント (< 350 KB): thread_id 、 checkpoint_id 、タイムスタンプ、状態などのメタデータを含むシリアル化されたアイテムとして DynamoDB に直接保存されます 大きなチェックポイント (≥ 350 KB): 状態は S3 にアップロードされ、DynamoDB は S3 オブジェクトへの参照ポインタを保存します 取得 : 再開時、セーバーは DynamoDB からメタデータを取得し、S3 から大きなペイロードを透過的にロードします この設計により、DynamoDB のアイテムサイズ制限に達することなく、小さな状態と大きな状態の両方を効率的に処理しながら、耐久性とスケーラビリティを提供します。 DynamoDBSaver には、コストとデータライフサイクルの管理に役立つ組み込み機能が含まれています: Time-to-Live ( ttl_seconds ) により、指定された間隔でチェックポイントの自動有効期限が有効になります。古いスレッドの状態は手動介入なしでクリーンアップされ、一時的なワークフロー、テスト環境、または特定の期間を超えた履歴状態に価値がないアプリケーションに最適です。 圧縮 ( enable_checkpoint_compression ) は、状態データをシリアル化および圧縮することで、保存前にチェックポイントのサイズを削減し、取得時に完全な状態の忠実性を維持しながら、DynamoDB の書き込みコストと S3 ストレージコストの両方を削減します。 これらの機能を組み合わせることで、永続化レイヤーの運用コストとストレージフットプリントをきめ細かく制御でき、アプリケーションのスケールに応じて耐久性要件と予算制約のバランスを取ることができます。 はじめに 実行間でエージェントの状態を永続化し、履歴チェックポイントを取得する方法を示す実用的な例を構築しましょう。 前提条件 開始する前に、必要な AWS リソースをセットアップする必要があります: DynamoDB テーブル : DynamoDBSaver は、チェックポイントメタデータを保存するためのテーブルが必要です。テーブルには、PK (文字列) という名前のパーティションキーと SK (文字列) という名前のソートキーが必要です。 S3 バケット (オプション) : チェックポイントが 350 KB を超える可能性がある場合は、大きなペイロードストレージ用の S3 バケットを提供します。セーバーは、オーバーサイズの状態を自動的に S3 にルーティングし、DynamoDB に参照を保存します。 AWS Cloud Development Kit (AWS CDK) を使用して、これらのリソースを定義できます: const table = new dynamodb.Table(this, 'CheckpointTable', { tableName: 'my_langgraph_checkpoints_table', partitionKey: { name: 'PK', type: dynamodb.AttributeType.STRING }, sortKey: { name: 'SK', type: dynamodb.AttributeType.STRING }, timeToLiveAttribute: 'ttl', removalPolicy: cdk.RemovalPolicy.DESTROY, }); const bucket = new s3.Bucket(this, 'CheckpointBucket', { bucketName: 'amzn-s3-demo-bucket', encryption: s3.BucketEncryption.S3_MANAGED, blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL, removalPolicy: cdk.RemovalPolicy.DESTROY }); アプリケーションが DynamoDBSaver を LangGraph チェックポイントストレージとして使用するには、次の AWS Identity and Access Management (AWS IAM) 権限が必要です: DynamoDB テーブルアクセス: dynamodb:GetItem – 個別のチェックポイントを取得 dynamodb:PutItem – 新しいチェックポイントを保存 dynamodb:Query – スレッド ID でチェックポイントを検索 dynamodb:BatchGetItem – 複数のチェックポイントを効率的に取得 dynamodb:BatchWriteItem – 単一の操作で複数のチェックポイントを保存 S3 オブジェクト操作 (350KB を超えるチェックポイントの場合): s3:PutObject – チェックポイントデータをアップロード s3:GetObject – チェックポイントデータを取得 s3:DeleteObject – 期限切れのチェックポイントを削除 s3:PutObjectTagging – ライフサイクル管理のためにオブジェクトにタグを付ける S3 バケット設定: s3:GetBucketLifecycleConfiguration – ライフサイクルルールを読み取る s3:PutBucketLifecycleConfiguration – 自動データ有効期限を設定 インストール pip を使用して LangGraph と AWS チェックポイントストレージライブラリをインストールします: pip install langgraph langgraph-checkpoint-aws 基本設定 大きなチェックポイント用のオプションの S3 バケットとテーブルを使用して、DynamoDB チェックポイントセーバーを設定します: from langgraph.graph import StateGraph, END from langgraph_checkpoint_aws import DynamoDBSaver from typing import TypedDict, Annotatedimport operator # 状態を定義 class State(TypedDict): foo: str bar: Annotated[list[str], add] # DynamoDB 永続性を設定 checkpointer = DynamoDBSaver( table_name="my_langgraph_checkpoints_table", region_name="us-east-1", ttl_seconds=86400 * 30, # 30 日 enable_checkpoint_compression=True, s3_offload_config={ "bucket_name": "amzn-s3-demo-bucket", } ) ワークフローの構築 グラフを作成し、チェックポインタでコンパイルして、呼び出し間で永続的な状態を有効にします: # セッション用の thread_id THREAD_ID = "99" workflow = StateGraph(State) workflow.add_node(node_a) workflow.add_node(node_b) workflow.add_edge(START, "node_a") workflow.add_edge("node_a", "node_b") workflow.add_edge("node_b", END) graph = workflow.compile(checkpointer=checkpointer) config: RunnableConfig = {"configurable": {"thread_id": THREAD_ID}} graph.invoke({"foo": "", "bar": []}, config) 状態の取得 現在の状態を取得するか、タイムトラベルデバッグのために以前のチェックポイントにアクセスします: # 最新の状態スナップショットを取得 config = {"configurable": {"thread_id": THREAD_ID}} latest_checkpoint = graph.get_state(config) print(latest_checkpoint) # 特定の checkpoint_id の状態スナップショットを取得 checkpoint_id = latest_checkpoint.config.get("configurable", {}).get("checkpoint_id") config = {"configurable": {"thread_id": THREAD_ID, "checkpoint_id": checkpoint_id}} specific_checkpoint = graph.get_state(config) print(specific_checkpoint) 実際のユースケース 1. ヒューマン・イン・ザ・ループレビュー 機密性の高い操作 (金融取引、法的文書、医療アドバイス) の場合、人間の監視のためにワークフローを一時停止できます: # エージェントが応答を生成 workflow.invoke({"query": "Approve my loan"}, config) # 人間が別のプロセス/UI でレビュー # チェックポイントは DynamoDB に安全に保存される # 承認後、再開 workflow.invoke({"approved": True}, config) 2. 障害回復 本番システムでは、障害が発生します。ネットワークの中断、API のタイムアウト、または一時的なエラーにより、実行が途中で停止する可能性があります。 メモリ内チェックポイントでは、進行状況が失われます。 DynamoDBSaver を使用すると、ワークフローは最後に成功したチェックポイントをクエリし、そこから再開できます。これにより、再計算が削減され、回復が高速化され、信頼性が向上します。 try: workflow.invoke({"input": "complex query"}, config) except Exception as e: # エラーをログに記録し、運用チームに警告 pass # 後で、最後に成功したチェックポイントから再試行 # 完了したステップを再実行する必要はない workflow.invoke({}, config) 3. 長時間実行される会話 一部のワークフローは数時間または数日にわたります。DynamoDB の耐久性により、会話が確実に永続化されます: # 1 日目: 顧客が問い合わせを開始 workflow.invoke({"messages": ["I need help"]}, config) # 2 日目: 顧客がさらに情報を提供 workflow.invoke({"messages": ["Here's my account number"]}, config) # 3 日目: エージェントがタスクを完了 workflow.invoke({"action": "resolve"}, config) プロトタイプから本番環境への移行は、チェックポインタを変更するだけで簡単です。 MemorySaver を DynamoDBSaver に置き換えて、永続的でスケーラブルな状態管理を実現します: クリーンアップ 継続的な料金の発生を避けるために、作成したリソースを削除します: AWS CDK を使用してデプロイした場合は、次のコマンドを実行します: cdk destroy CLI を使用した場合は、次のコマンドを実行します: DynamoDB テーブルを削除: aws dynamodb delete-table --table-name my_langgraph_checkpoints_table Amazon S3 バケットを空にして削除: aws s3 rm s3://amzn-s3-demo-bucket --recursive aws s3 rb s3://amzn-s3-demo-bucket まとめ LangGraph を使用すると、インテリジェントでステートフルなエージェントを簡単に構築できます。 DynamoDBSaver により、本番環境で安全に実行できます。 DynamoDBSaver を LangGraph アプリケーションに統合することで、耐久性、スケーラビリティ、および特定の時点から複雑なワークフローを再開する能力を得ることができます。人間の監視を伴うシステムを構築し、長時間実行されるセッションを維持し、中断から適切に回復できます。 今すぐ始めましょう プロトタイピング中はメモリ内チェックポイントから始めてください。本番環境に移行する準備ができたら、 DynamoDBSaver に切り替えて、エージェントが記憶し、回復し、自信を持ってスケールできるようにします。 pip install langgraph-checkpoint-aws でライブラリをインストールします。 利用可能な設定オプションを確認するには、 langgraph-checkpoint-aws ドキュメント で DynamoDBSaver の詳細をご覧ください。 本番ワークロードの場合は、 Amazon Bedrock AgentCore Runtime を使用して LangGraph エージェントをホストすることを検討してください。AgentCore は、スケーリング、モニタリング、インフラストラクチャ管理を処理するフルマネージドランタイム環境を提供し、AWS が運用の複雑さを管理する間、エージェントロジックの構築に集中できます。 著者について Lee Hannigan Lee は、アイルランドのドニゴールを拠点とする Sr. DynamoDB Database Engineer です。彼は、ビッグデータと分析技術の強固な基盤を持つ、分散システムにおける豊富な専門知識をもたらします。彼の役割では、Lee は DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に焦点を当てながら、顧客と社内チームがその機能を最大限に活用できるよう支援しています。

2026 年 1 月 20 日、 Amazon Elastic Compute Cloud (Amazon EC2) G7e インスタンスの一般提供が発表されました。G7e インスタンスは生成 AI 推論ワークロードにコスト効率の高いパフォーマンスを提供し、グラフィックワークロードでは最も高いパフォーマンスを実現します。 G7e インスタンスは NVIDIA RTX PRO 6000 Blackwell Server Edition GPU によって高速化されており、空間コンピューティングや科学コンピューティングのワークロードなど、さまざまな GPU 対応ワークロードに適しています。G7e インスタンスは、 G6e インスタンス よりも最大 2.3 倍優れた推論パフォーマンスを提供します。 以前のインスタンスからの改善点は以下のとおりです。 NVIDIA RTX PRO 6000 Blackwell GPU – NVIDIA RTX PRO 6000 Blackwell Server Edition GPU は、G6e インスタンスと比較して 2 倍の GPU メモリと 1.85 倍の GPU メモリ帯域幅を提供します。G7e インスタンスが提供する大容量の GPU メモリを使用することにより、単一の GPU で最大 70B パラメータの中規模モデルを FP8 の精度で実行できます。 NVIDIA GPUDirect P2P – 単一 GPU のメモリでは対応し切れない大きさのモデルについては、複数の GPU にモデルまたは計算を分割することができます。G7e インスタンスは、PCIe インターコネクト経由での GPU 間直接通信を可能にする NVIDIA GPUDirect P2P をサポートしているため、マルチ GPU ワークロードのレイテンシーが低減します。これらのインスタンスは、同一の PCIe スイッチ上にある GPU に最も低いピアツーピアレイテンシーを提供します。さらに、G7e インスタンスは G6e インスタンスに搭載された L40s GPU よりも最大 4 倍広い GPU 間帯域幅を提供するため、マルチ GPU ワークロードのパフォーマンスが向上します。これらの改善により、単一のノード内で最大 768 GB の GPU メモリを提供する複数の GPU で大規模モデルの推論を実行できるようになります。 ネットワーク – G7e インスタンスは G6e インスタンスより 4 倍広いネットワーク帯域幅を提供するため、小規模のマルチノードワークロードでの使用が可能です。また、マルチ GPU G7e インスタンスは Elastic Fabric Adapter (EFA) 経由で NVIDIA GPUDirect Remote Direct Memory Access (RDMA) をサポートすることから、マルチノードワークロードのリモート GPU 間通信のレイテンシーが低減します。これらのインスタンスサイズは Amazon FSx for Lustre での NVIDIA GPUDirectStorage の使用もサポートしており、インスタンスへのスループットが G6e インスタンスよりも最大 1.2 Tbps 高くなるため、モデルをすばやくロードできます。 EC2 G7e の仕様 G7e インスタンスには、最大 768 GB の総 GPU メモリ (GPU あたり 96 GB のメモリ) を提供する最大 8 個の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU と、Intel Emerald Rapids プロセッサが搭載されています。また、最大 192 個の vCPU、最大 1,600 Gbps のネットワーク帯域幅、最大 2,048 GiB のシステムメモリ、最大 15.2 TB のローカル NVMe SSD ストレージもサポートしています。 仕様は以下のとおりです。 インスタンス名 GPU 数 GPU メモリ (GB) vCPU 数 メモリ (GiB) ストレージ (TB) EBS 帯域幅 (Gbps) ネットワーク帯域幅 (Gbps) g7e.2xlarge 1 96 8 64 1.9 x 1 最大 5 50 g7e.4xlarge 1 96 16 128 1.9 x 1 8 50 g7e.8xlarge 1 96 32 256 1.9 x 1 16 100 g7e.12xlarge 2 192 48 512 3.8 x 1 25 400 g7e.24xlarge 4 384 96 1,024 3.8 x 2 50 800 g7e.48xlarge 8 768 192 2,048 3.8 x 4 100 1,600 G7e インスタンスの使用開始には、機械学習ワークロードに AWS Deep Learning AMI (DLAMI) を使用できます。インスタンスの実行には、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用できます。マネージド型のエクスペリエンスを希望する場合は、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) で G7e インスタンスを使用できます。 Amazon SageMaker AI のサポートも近日提供予定です。 今すぐご利用いただけます Amazon EC2 G7e インスタンスは、2026 年 1 月 20 日から米国東部 (バージニア北部) と米国東部 (オハイオ) の各 AWS リージョン でご利用いただけます。リージョンの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 G7e インスタンスは、 オンデマンドインスタンス 、 Savings Plan 、 スポットインスタンス として購入できます。G7e インスタンスは、 ハードウェア専有インスタンス および 専有ホスト での利用も可能です。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で G7e インスタンスをお試しください。詳細については、 Amazon EC2 G7e instances ページ をご覧ください。フィードバックもお待ちしています。フィードバックは AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Channy 原文は こちら です。

デジタル庁は2025年5月27日、『行政の進化と革新のための生成AIの調達・利活用に係るガイドライン』（政府ガイドライン）を公開しました。このガイドラインは、政府機関による生成AIの安全かつ効果的な活用方法を包括的に示しています。 AWS は、政府機関の調達担当者とパートナー企業向けに、政府ガイドラインの調達チェックシートの各要件に対する回答例を提供します。この回答例は、Amazon Bedrock を活用したオープンソースアプリケーション『 Generative AI Use Cases（GenU） 』を用いた 生成AIアプリケーション に対応し、政府機関の調達プロセスとパートナー企業の提案書作成を支援します。 １．政府ガイドラインの概要 ・政府ガイドライン策定の背景 政府における 生成AI の活用は、行政サービスの効率化や質の向上に大きな可能性をもたらします。一方で、情報漏えいや不適切な出力などのリスクも存在するため、適切なガバナンスとリスク管理が不可欠です。今回の政府ガイドラインは、 生成AI の利活用促進とリスク管理を両立させることを目的として策定されました。 ・調達チェックシートとは 政府ガイドラインの中核となるのが「調達チェックシート」です。これは、政府機関が 生成AIシステム を調達する際に、事業者に対して確認すべき要件を体系化したものです。チェックシートには、データプライバシー保護、有害情報の出力制御、セキュリティ確保など、政府機関が重視する技術的・運用的要件が項目別に整理されており、調達担当者が提案書を評価する際の統一的な基準として活用されます。また、事業者にとっては、政府が求める技術要件を明確に把握し、適切な提案を行うための指針となります。 ・主要なポイント [対象範囲] • 対象システム：テキスト生成AIを構成要素とする政府情報システム • 適用開始：2025年5月（※全面適用は、令和８年度以降に調達・利活用を行う生成AI システムから） • 対象外：特定秘密や安全保障等の機微情報を扱うシステム [ガバナンス体制の構築] • AI統括責任者（CAIO）：各府省庁にAI統括責任者を新設 • 先進的生成AIアドバイザリーボード：各府省庁への助言・相談対応 • AI相談窓口：デジタル庁による技術的支援 [リスク管理の仕組み] • 高リスク判定：4つの観点（利用者範囲、業務性格、機密情報、出力判断）でリスク評価 • 調達チェックシート：調達・契約時の要件確認を体系化 • インシデント対応：生成AI特有のリスクケースへの対応体制 ２． AWS のサンプル回答 –  GenU を活用した調達チェックシート要件対応例 ・ GenU の特徴 AWS では、政府機関の生成AI活用を支援するため、 GenU という Amazon Bedrock を活用したオープンソースのアプリケーション実装を提供しています。 GenU は最短10分でデプロイが完了する迅速な導入が可能で、セキュリティ・統制機能を標準搭載した安全性重視の設計となっています。また、チャット、RAG、文書生成、翻訳など多様なユースケースに対応しており、使った分だけの従量課金制によりスモールスタートでコスト効率よく始めることができます。 ・ AWS サンプル回答の活用方法 政府ガイドラインでは、政府機関の生成AIシステムの調達時に「調達チェックシート」の活用が求められています。 AWS では、このチェックシートの各項目に対して、 GenUを活用した場合の具体的な対応例をサンプル回答 として提供し、政府機関とパートナー企業の皆様を支援いたします。サンプル回答の見方については 補足資料 をご参照ください。 [政府機関職員の皆様へ] ・調達・契約時での活用 Amazon Bedrock を活用した応札企業の技術提案と AWSサンプル回答 の対応例を照合し、データプライバシー保護や有害情報制御などの重要要件への技術的実現可能性を客観的に評価 [パートナー企業の皆様へ] ・提案書作成での活用 調達チェックシート要件に対する Amazon Bedrock での技術的対応方針を検討し、適切な技術構成と実装方法を提案書に記載する際の参考資料として活用 回答例は こちら からダウンロードできます。　回答例の見方については 補足資料 をご参照ください。 ３．まとめ 政府ガイドラインは、安全で効果的な 生成AI 活用のための重要な指針です。 AWS のサンプル回答は、この政府ガイドラインで示された調達チェックシート要件に対する AWS としての技術的考え方と対応例をまとめた参考資料として、政府機関の調達担当者とパートナー企業の提案書作成者にご活用いただけます。 参考情報： • Generative AI Use Cases JP (GenU) • Amazon Bedrock • 公共機関における生成 AI の活用案 お問い合わせ 政府機関向けの 生成AI 導入に関するご相談は、 AWSパブリックセクター までお気軽にお問い合わせください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料は政府ガイドラインの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 著者： Atsushi Kimura (AWS Japan, Public Sector, Proposal Manager) Keiji Toyohara (AWS Japan, Public Sector, Senior Manager, Solutions Architect)

本ブログは 2025 年 11 月 12 日に公開された AWS Blog “ Amazon Elastic Kubernetes Service gets independent affirmation of its zero operator access design ” を翻訳したものです。 本日 (2025 年 11 月 12 日)、 Amazon Elastic Kubernetes Service (Amazon EKS) のゼロオペレーターアクセス体制について、独立した第三者機関により裏付けられたことを発表しました。 Amazon Web Services (AWS) では、 セキュリティは最優先事項 です。この信念のもと、規制業界のお客様や最も厳格なセキュリティ要件を持つお客様が求めるデータプライバシーを実現できるよう、マネージド Kubernetes サービス向けの運用アーキテクチャを設計・実装しています。これにより、重要かつ機密性の高いワークロードを安心して AWS 上で実行できます。AWS のサービスは、Amazon EKS の管理において、AWS の従業員が顧客コンテンツを読み取り、コピー、抽出、変更、またはその他の方法でアクセスする技術的な経路を持たないように設計されています。 AWS では、信頼を獲得することは単なる目標ではなく、あらゆる意思決定の指針となる リーダーシッププリンシプル の 1 つです。お客様が AWS を選ぶのは、ワークロードの構築、移行、実行、およびデータの保存に最も安全なグローバルクラウドインフラストラクチャを提供すると信頼しているからです。この信頼をさらに高めるため、AWS は AWS Trust Center を立ち上げ、AWS クラウドでお客様の資産をどのように保護しているかについての情報をより入手しやすくしました。この立ち上げに合わせて、業界をリードするデータプライバシー体制を示すための オペレーターアクセス へのアプローチと、AWS クラウドにおける AWS 責任共有モデル での AWS の責任をどのように果たしているかについて、Trust Center で説明しています。 AWS のコアシステムとサービスの多くは、ゼロオペレーターアクセスで設計されています。これは、少なくともサービスの管理において顧客コンテンツへいかなる手段でもアクセスできないよう、アーキテクチャとモデルが運用されることを意味します。これらのシステムとサービスは、自動化とセキュアな API を通じて管理されており、過失であれ故意であれ顧客コンテンツへのアクセスを防いでいます。このようなサービスには、 AWS Key Management Service (AWS KMS) 、 Amazon Elastic Compute Cloud (Amazon EC2) （ AWS Nitro System を通じて）、 AWS Lambda 、 Amazon EKS 、 AWS Wickr があります。 AWS は AWSのデジタル主権に関するお客様との約束 において、AWS サービスがどのように設計・運用されているか、特に顧客コンテンツの取り扱いについて、お客様により高い透明性と保証を提供することを約束しました。この透明性向上の一環として、英国を拠点とする大手サイバーセキュリティコンサルティング会社である NCC Group に、Amazon EKS のアーキテクチャと、お客様に提供しているセキュリティ保証について独立したアーキテクチャレビューを依頼しました。NCC Group はレポートを発行し、AWS のセキュリティに関する主張を裏付けました。レポートには次のように記載されています。 “NCC Group found no architectural gaps that would directly compromise the security claims asserted by AWS.” (NCC Group は、AWS のセキュリティに関する主張を損なうようなアーキテクチャ上のギャップを検出しませんでした。) 具体的には、このレポートは Amazon EKS のセキュリティポスチャに関する以下の内容を検証しています。 AWS の従業員がマネージド Kubernetes コントロールプレーンインスタンスにインタラクティブにアクセスする技術的手段は存在しない AWS の従業員がマネージド Kubernetes コントロールプレーンインスタンス内の顧客コンテンツを読み取り、コピー、抽出、変更、またはその他の方法でアクセスする技術的手段は存在しない AWS の従業員が Kubernetes コントロールプレーンインスタンスを管理するために使用する管理 API は、Kubernetes データプレーン内の顧客コンテンツにアクセスできない Kubernetes コントロールプレーンを管理するために使用される管理 API への変更には、常に複数人によるレビューと承認が必要 AWS の従業員が etcd データベースのバックアップストレージ内の顧客コンテンツにアクセスする技術的手段は存在しない。etcd データベースのデータ保護に使用される平文の暗号化キーには、AWS の従業員は誰もアクセスできない AWS の従業員は、マネージド Kubernetes コントロールプレーンまたは Kubernetes データプレーン内の顧客コンテンツにアクセスすることなく、管理 API を使用してのみ Kubernetes クラスター API エンドポイントとやり取りできる。AWS の従業員が Kubernetes クラスター API エンドポイントで実行したすべてのアクションは、お客様が有効にした監査ログを通じてお客様に表示される 管理 API へのアクセスには常に認証と認可が必要。管理 API によって実行されるすべての運用アクションはログに記録され、監査される マネージド Kubernetes コントロールプレーンインスタンスは、信頼されたパイプラインによってデプロイされたテスト済みのソフトウェアのみを実行できる。AWS の従業員は、このパイプライン以外でマネージド Kubernetes コントロールプレーンインスタンスにソフトウェアをデプロイすることはできない NCC Group の詳細なレポートでは、これらの各主張について、NCC Group が主張を評価するために使用した範囲、方法論、手順を含めて検証しています。 Amazon EKS がゼロオペレーターアクセスを実現する仕組み AWS は常に最小権限モデルを採用し、 顧客コンテンツ を処理するシステムにアクセスできる人員を最小限に抑えています。各 AWS 従業員が割り当てられたタスクや責任を遂行するために必要な最小限のシステムにのみアクセスできるよう製品とサービスを設計し、そのアクセスも必要な時だけに制限しています。顧客データを保存または処理するシステムへのアクセスはすべてログに記録され、異常がないか監視・監査されます。AWS は、AWS の従業員が不正な目的で顧客コンテンツにアクセスすることを防ぐようにすべてのシステムを設計しています。これは AWS カスタマーアグリーメント と AWS サービス条件 で約束しています。AWS の運用において、お客様への通知と許可なしに顧客コンテンツにアクセス、コピー、または移動することは決してありません。 AWS の運用アーキテクチャでは、コンフィデンシャルコンピューティングを実現する AWS Nitro System ベースのインスタンスのみを使用して、マネージド Kubernetes コントロールプレーンを運用しています。 AWS は、限定的な操作のみ可能な管理 API を使用してアクセスを厳密に制御し、オペレーターが Kubernetes コントロールプレーンインスタンスへの直接アクセスやインタラクティブアクセスなしに、トラブルシューティングや診断のための許可リストに登録されたアクションを正確に実行できるようにしています。これらの API は、Kubernetes コントロールプレーンまたはお客様の Kubernetes データプレーン内の顧客コンテンツにアクセスする技術的手段を持たないよう最初から設計されています。 AWS の標準的な変更管理プロセスでは、これらの管理 API 自体の変更や、サービス運用のガードレールとなる関連ポリシーの変更には、複数人によるレビューと承認プロセスが組み込まれています。このモデルは、お客様が選択した Kubernetes データプレーンの起動モードに関係なく、すべての Amazon EKS クラスターで一貫して実装されています。 さらに、これらの限定的な操作のみ可能な管理 API とのすべてのやり取りはログを生成し、最小権限の原則に従って必須の認証と認可が行われます。クラスターの監査ログを有効にすることで、お客様は AWS の従業員がクラスターの API エンドポイントで実行したすべてのアクションを確認できます。 デフォルトで、AWS は すべての Kubernetes API データをエンベロープ暗号化 による保存時暗号化を適用して etcd データベースに格納し、さらに etcd データベースのバックアップストレージを保護することで、クラスタースナップショット内の顧客コンテンツへのアクセスを防ぐ多層的な保護を実現しています。また、AWS のシステムは、 etcd データベースとそのバックアップのデータを保護するために使用される平文の暗号化キーに AWS の従業員が誰もアクセスできないように設計されています。 これらのオペレーターアクセス制御は、ワーカーノードの実行方法に関係なく、Amazon EKS コントロールプレーンに一律に適用されます。セルフマネージド、 Amazon EKS Auto Mode 、 AWS Fargate のいずれでも同様です。 AWS 責任共有モデル に記載されているとおり、Amazon EKS Auto Mode と Fargate 起動モードを除き、Kubernetes ワーカーノードの設定のセキュリティ確保はお客様の責任となります。Amazon EKS における AWS マネージドデータプレーン起動モードのセキュリティの詳細については、 詳細情報 セクションの関連リンクを参照してください。 まとめ Amazon EKS は、AWS の従業員が Amazon EKS 内の顧客コンテンツを読み取り、コピー、変更、またはその他の方法でアクセスできないように設計・構築されています。AWS Nitro System ベースのコンフィデンシャルコンピューティング、限定的な操作のみ可能な管理 API、複数人による変更承認プロセス、エンドツーエンドの暗号化を使用することで、AWS はオペレーターアクセスの技術的経路を排除しています。NCC Group による独立した検証では、これらの保証を損なうようなアーキテクチャ上のギャップは検出されませんでした。Amazon EKS は最も厳格な規制要件やデジタル主権要件を満たすゼロオペレーターアクセスモデルを提供し、組織が最も機密性の高いミッションクリティカルなワークロードを AWS 上で安心して実行できるようにしています。 詳細情報 NCC Group レポート Amazon EKS ドキュメント Amazon EKS Auto Mode のセキュリティ概要 AWS Fargate のセキュリティ概要 AWSのデジタル主権に関するお客様との約束 AWS の継続的デリバリーの実践と安全なパイプラインの自動化 この記事に関するご質問がある場合は、 AWS サポート にお問い合わせください。 Micah Hausler Micah は AWS のプリンシパルソフトウェアエンジニアで、Kubernetes とコンテナセキュリティに注力しています。 Lukonde Mwila Lukonde は AWS の Amazon EKS チームのシニアプロダクトマネージャーで、ネットワーキング、レジリエンス、運用セキュリティに注力しています。アプリケーション開発、ソリューションアーキテクチャ、クラウドエンジニアリング、DevOps ワークフローにおいて長年の経験があります。 Manu Mazarredo Manu はオランダのアムステルダムを拠点とする AWS のプログラムマネージャーです。AWS リージョンと業界全体にわたるコンプライアンスおよびセキュリティ保証の監査とエンゲージメントをリードしています。過去 20 年間、情報システム監査、倫理的ハッキング、プロジェクト管理、品質保証、ベンダー管理に従事してきました。 Tari Dongo Tari はロンドンを拠点とする AWS のセキュリティ保証プログラムマネージャーです。EMEA 全体のサードパーティおよび顧客監査、証明、認証、評価を担当しています。以前は、Big 4 (四大会計事務所) および金融サービス業界でセキュリティ保証とテクノロジーリスクに従事していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 12 月 23 日に公開された AWS Blog “ Exploring the zero operator access design of Mantle ” を翻訳したものです。 Amazon では、改善点について率直かつオープンに議論する文化があります。この文化があるからこそ、お客様への価値提供の基準を継続的に引き上げるための投資とイノベーションに注力し続けることができています。2025 年 12 月初め、 Amazon Bedrock の次世代推論エンジンである Mantle において、このプロセスが実際に機能している例を共有する機会がありました。生成 AI の推論処理やファインチューニングのワークロードが進化し続ける中、お客様に最適化された方法で推論を提供する方法も進化させる必要があり、それが Mantle の開発につながりました。 次世代推論エンジンのアーキテクチャを再構築するにあたり、AWS はセキュリティの基準を引き上げることを最優先事項としました。AWS はお客様と同様に、セキュリティとデータプライバシーに一切妥協しない姿勢で取り組んでいます。これは当初からビジネスの中心であり、Amazon Bedrock においても初期段階から徹底してきました。生成 AI の推論ワークロードは、お客様がデータの潜在的な価値を引き出すための、かつてない可能性をもたらします。しかし、その可能性を活かすには、最も機密性の高いデータを処理し、最も重要なシステムと連携する生成 AI システムを構築する際に、セキュリティ、プライバシー、コンプライアンスの最高基準を確保する必要があることを、AWS は当初から理解していました。 前提として、Amazon Bedrock は AWS 全体に適用されているものと同じ運用セキュリティ基準で設計されています。AWS は常に最小権限モデルを運用に採用しており、各 AWS オペレーターは割り当てられたタスクを実行するために必要な最小限のシステムにのみアクセスでき、その権限はタスクの実行に必要な期間のみに限定されています。顧客データやメタデータを格納または処理するシステムへのアクセスはすべてログに記録され、異常がないか監視され、監査されます。AWS はこれらのコントロールを無効化またはバイパスするあらゆる行為を防止しています。さらに、Amazon Bedrock ではお客様のデータがモデルのトレーニングに使用されることはありません。モデルプロバイダーは顧客データにアクセスする手段を持っていません。推論処理は、AWS が管理する Amazon Bedrock のサービスアカウント内でのみ行われ、モデルプロバイダーはこのアカウントにアクセスできないためです。この強力なセキュリティポスチャにより、お客様は安心して機密データを生成 AI アプリケーションで活用できるようになっています。 Mantle では、AWS はさらに高い基準を設けました。 AWS Nitro System のアプローチに従い、Mantle をゼロから設計してゼロオペレーターアクセス (ZOA) を実現しました。これは、AWS オペレーターが顧客データにアクセスするための技術的手段を設計の段階から徹底して排除したものです。代わりに、システムとサービスは顧客データを保護する自動化とセキュアな API を使用して管理されます。Mantle では、AWS オペレーターが基盤となるコンピューティングシステムにサインインしたり、推論プロンプトや生成結果などの顧客データにアクセスしたりする手段はありません。Secure Shell (SSH)、 AWS Systems Manager Session Manager 、シリアルコンソールなどの対話型通信ツールは、Mantle のどこにもインストールされていません。さらに、すべての推論ソフトウェアの更新は、サービスにデプロイされる前に署名と検証が必要であり、承認されたコードのみが Mantle で実行されることを保証しています。 Mantle は、最近リリースされた EC2 インスタンスアテステーション機能 を使用して、顧客データ処理のための堅牢化され、制限された、イミュータブルなコンピューティング環境を構成しています。Mantle でモデルの重みを取り扱い、顧客プロンプトに対する推論処理を担当するサービスは、 Nitro Trusted Platform Module (NitroTPM) から暗号署名されたアテステーション・メジャーメントによる高い保証によってさらに裏付けられています。 お客様が Mantle エンドポイント (例: bedrock-mantle.[regions].api.aws ) を呼び出すと、Amazon Bedrock の Responses API を提供するエンドポイントなど、顧客データ (プロンプト) は TLS を通じてお客様の環境を離れ、ZOA で運用される Mantle サービスまで暗号化されたまま送信されます。フロー全体および Mantle 内で、AWS、お客様、モデルプロバイダーのいずれのオペレーターも顧客データにアクセスできません。 今後の展望 Mantle の ZOA 設計は、お客様のデータのセキュリティとプライバシーに対する AWS の長期的なコミットメントの表れです。だからこそ、AWS のすべてのチームがセキュリティの基準をさらに引き上げるための投資を行うことができています。同時に、NitroTPM アテステーションなど、Amazon 社内で使用している基盤となるコンフィデンシャルコンピューティング機能を、すべてのお客様が Amazon Elastic Compute Cloud (Amazon EC2) で使用できるようにしました。 AWS はここで止まることはありません。お客様のデータのセキュリティを強化するための投資を継続し、これをどのように実現しているかについて、より高い透明性と保証を提供することにコミットしています。 著者について Anthony Liguori は Amazon Bedrock 担当の AWS バイスプレジデント兼ディスティングイッシュドエンジニアであり、Mantle のリードエンジニアです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 1 月 22 日 に公開された「 Managing Amazon OpenSearch UI infrastructure as code with AWS CDK 」を翻訳したものです。 複数の AWS リージョンや環境にまたがって可観測性と分析機能を拡張していくと、ダッシュボードの一貫性を維持することが難しくなります。チームはダッシュボードの再作成、ワークスペースの作成、データソースの接続、設定の検証に何時間も費やすことがあります。繰り返しが多くエラーが発生しやすいプロセスであり、運用の可視化を遅らせる原因となります。 Amazon OpenSearch Service の次世代 OpenSearch UI は、個々の OpenSearch ドメインやコレクションから切り離された、統合されたマネージド分析エクスペリエンスを提供します。ワークスペースは、コラボレーター管理機能を備えた専用のチームスペースであり、可観測性、検索、セキュリティ分析のユースケースに合わせた環境を提供します。各ワークスペースは、OpenSearch Service ドメイン、 Amazon OpenSearch Serverless コレクション、 Amazon Simple Storage Service (Amazon S3) などの外部ソースを含む複数のデータソースに接続できます。OpenSearch UI は、 AWS IAM Identity Center 、 AWS Identity and Access Management (IAM)、IdP 起点のシングルサインオン (IAM フェデレーションを使用した SAML)、AI を活用したインサイトによるアクセスもサポートしています。 本記事では、 AWS Cloud Development Kit (AWS CDK) を使用して OpenSearch UI アプリケーションをデプロイし、OpenSearch Dashboards Saved Objects API でワークスペースとダッシュボードを自動作成する AWS Lambda 関数と統合する方法を紹介します。この自動化により、環境は標準化され、バージョン管理され、デプロイ間で一貫性のある、すぐに使用できる分析機能を備えた状態で起動します。 本記事で学ぶ内容: AWS CloudFormation を使用する AWS CDK で OpenSearch UI アプリケーションをデプロイする Lambda ベースのカスタムリソースを使用してワークスペースとダッシュボードを自動的に作成する 即座に可視化できるサンプルデータを生成して取り込む OpenSearch Dashboards Saved Objects API を使用してプログラムで可視化を構築する AWS Signature Version 4 を使用して API リクエストを認証する この記事のすべてのコードサンプルは、 AWS Samples リポジトリ で入手できます。 ソリューションの概要 以下のアーキテクチャは、AWS CDK、AWS Lambda、OpenSearch UI API を使用して OpenSearch UI ワークスペースとダッシュボードの作成を自動化する方法を示しています。 ワークフローは左から右に流れます。 スタックのデプロイ – 開発者が cdk deploy を実行してインフラストラクチャを起動し、CloudFormation スタックを作成します。 ドメインの作成 – CloudFormation が OpenSearch ドメイン (データソースとして機能) を作成します。 OpenSearch UI アプリの作成 – CloudFormation が OpenSearch UI アプリケーションを作成します。 Lambda のトリガー – CloudFormation がカスタムリソースとして Lambda 関数を呼び出します。 データの生成と取り込み – Lambda がサンプルメトリクスを生成し、ドメインに取り込みます。 Saved Object API を使用したワークスペースとアセットの作成 – Lambda が OpenSearch UI API 呼び出しを使用して、ワークスペース、インデックスパターン、可視化 (円グラフ)、ダッシュボードを作成します。 サンプルデータとすぐに使用できるダッシュボードを備えた、完全に設定された OpenSearch UI が Infrastructure as Code (IaC) によって自動化されます。同じワークフローを既存の OpenSearch UI アプリケーションのインフラストラクチャに統合して、将来のデプロイ時にダッシュボードを自動的に作成または更新し、環境間の一貫性を維持することもできます。 前提条件 本ソリューションには以下が必要です。 十分な権限を持つ AWS ユーザーまたはロール – OpenSearch Service ドメイン、OpenSearch UI アプリケーション、Lambda 関数、IAM ロールとポリシー、仮想プライベートクラウド (VPC) ネットワークコンポーネント (サブネットとセキュリティグループ)、CloudFormation スタックなどの AWS リソースを作成および管理する権限が必要です。テストや概念実証のデプロイには、管理者ロールの使用をお勧めします。本番環境では、最小権限の原則に従ってください。 開発ツールのインストール: AWS CLI v2.x 以降。詳細については、 AWS CLI の開始方法 を参照してください。 Node.js 18.x 以降。 AWS CDK v2.110.0 以降: npm install -g aws-cdk 。 Python 3.11 以降。 CDK のブートストラップ – アカウントまたはリージョンごとに 1 回のセットアップです。 cdk bootstrap <aws://123456789012/us-east-1> このコマンドにより、アカウントで AWS CDK デプロイに必要な S3 バケットと IAM ロールが作成されます。 サンプルコードの取得 GitHub からサンプル実装をクローンします。 git clone https://github.com/aws-samples/sample-automate-opensearch-ui-dashboards-deployment.git cd opensearch-dashboard-automation-sample リポジトリには以下が含まれています。 opensearch-dashboard-automation-sample/ ├── cdk/ │ ├── bin/ │ │ └── app.ts # CDK アプリのエントリポイント │ └── lib/ │ └── dashboard-stack.ts # OpenSearch ドメイン、Lambda、カスタムリソース └── lambda/ ├── dashboard_automation.py # ワークスペースとダッシュボード自動化のメイン Lambda ├── sigv4_signer.py # AWS SigV4 署名ユーティリティ └── requirements.txt # Python 依存関係 このサンプルは、OpenSearch UI アプリケーションのデプロイ、ワークスペースの作成、サンプルデータの取り込み、IaC を使用した可視化とダッシュボードの自動生成方法を示しています。 リポジトリをクローンした後、スタックをデプロイして、最初の OpenSearch ワークスペースとダッシュボードを自動的に作成できます。 ソリューションの理解 デプロイする前に、ソリューションの仕組みを確認しましょう。以下の手順では、AWS CDK スタックをデプロイしたときに自動的に実行されるアーキテクチャと自動化ロジックについて説明します。次のセクションには、実行する実際のデプロイコマンドが含まれています。 OpenSearch UI リソースのプロビジョニング AWS CDK は AWS CloudFormation とシームレスに統合されています。つまり、OpenSearch リソースと自動化ワークフローを IaC として定義できます。本ソリューションでは、AWS CDK が OpenSearch ドメイン、OpenSearch UI アプリケーション、自動化ロジックを実行する Lambda ベースのカスタムリソースをプロビジョニングします。 OpenSearch UI の自動化をデプロイする際、依存関係を正しく解決するためにリソース作成の順序が重要です。推奨される順序は以下のとおりです。 Lambda 実行ロールの作成 – AppConfigs と API へのアクセスに必要 OpenSearch ドメインの作成 – プライマリデータソースとして機能 OpenSearch UI アプリケーションの作成 – AppConfigs で Lambda ロールを参照 Lambda 関数の作成 – 自動化ロジックを定義 カスタムリソースの作成 – スタックデプロイ中に Lambda 自動化をトリガー 以下のコードスニペット ( cdk/lib/dashboard-stack.ts より) は、主要なインフラストラクチャ定義を示しています。 export class OpenSearchDashboardStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: OpenSearchDashboardStackProps) { super(scope, id, props); const masterUserArn = props?.masterUserArn || `arn:aws:iam::${this.account}:role/Admin`; // Step 1: Create IAM Role for Lambda FIRST const dashboardRole = new iam.Role(this, 'DashboardLambdaRole', { assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'), inlinePolicies: { OpenSearchAccess: new iam.PolicyDocument({ statements: [ new iam.PolicyStatement({ actions: ['opensearch:ApplicationAccessAll'], resources: ['*'] }), new iam.PolicyStatement({ actions: ['es:ESHttpPost', 'es:ESHttpPut', 'es:ESHttpGet'], resources: [`arn:aws:es:${this.region}:${this.account}:domain/*`] }) ] }) } }); // Step 2: Create OpenSearch Domain const opensearchDomain = new opensearch.Domain(this, 'OpenSearchDomain', { version: opensearch.EngineVersion.OPENSEARCH_2_11, capacity: { dataNodes: 1, dataNodeInstanceType: 'r6g.large.search' }, // ... additional configuration }); // Step 3: Create OpenSearch UI Application const openSearchUI = new opensearch.CfnApplication(this, 'OpenSearchUI', { appConfigs: [ { key: 'opensearchDashboards.dashboardAdmin.users', value: `[${masterUserArn}]` // Human users }, { key: 'opensearchDashboards.dashboardAdmin.groups', value: `[${dashboardRole.roleArn}]` // Lambda role } ], dataSources: [{ dataSourceArn: opensearchDomain.domainArn }], // ... additional configuration }); // Step 4: Create Lambda Function const dashboardFn = new lambda.Function(this, 'DashboardSetup', { runtime: lambda.Runtime.PYTHON_3_11, handler: 'dashboard_automation.handler', code: lambda.Code.fromAsset('../lambda'), timeout: cdk.Duration.minutes(5), role: dashboardRole }); // Step 5: Create Custom Resource const provider = new cr.Provider(this, 'DashboardProvider', { onEventHandler: dashboardFn }); new cdk.CustomResource(this, 'DashboardSetupResource', { serviceToken: provider.serviceToken, properties: { opensearchUIEndpoint: openSearchUI.attrDashboardEndpoint, domainEndpoint: opensearchDomain.domainEndpoint, domainName: opensearchDomain.domainName, workspaceName: 'workspace-demo', region: this.region } }); } } 実装に関する重要な注意点: Lambda ロールは、その Amazon リソースネーム (ARN) を dashboardAdmin.groups で参照できるように、OpenSearch UI アプリケーションより先に作成する必要があります。 Lambda ロールには、 opensearch:ApplicationAccessAll (OpenSearch UI API アクセス用) と es:ESHttp* 権限 (OpenSearch ドメインへのデータ取り込み用) の両方が含まれています。 カスタムリソースにより、自動化関数がデプロイ中に実行され、OpenSearch UI と OpenSearch ドメインの両方のエンドポイントがパラメータとして渡されます。 OpenSearch UI API での認証 OpenSearch UI (Dashboards) API とプログラムでやり取りする場合、Lambda 関数や自動化スクリプトが API に安全にアクセスできるように適切な認証が必要です。OpenSearch UI は、OpenSearch ドメイン API と同様に AWS Signature Version 4 (SigV4) 認証を使用しますが、いくつかの重要な違いがあります。 OpenSearch UI API リクエストに署名する際、サービス名は es ではなく opensearch である必要があります。これはよくある混乱の原因です。OpenSearch ドメインエンドポイントは引き続きレガシーサービス名 es を使用しますが、OpenSearch UI エンドポイントには opensearch が必要です。間違ったサービス名を使用すると、認証情報が有効であってもリクエストは認証に失敗します。 POST、PUT、DELETE リクエストの場合、OpenSearch UI API のセキュリティ要件を満たすために以下のヘッダーを含めます。 ヘッダー 説明 1 Content-Type JSON ペイロードの場合は application/json に設定 2 osd-xsrf 状態を変更する操作に必要 ( true に設定) 3 x-amz-content-sha256 データの整合性を確保するためのリクエストボディの SHA-256 ハッシュ SigV4 署名プロセスは、botocore の AWSRequest オブジェクトを使用する際にこのボディハッシュを自動的に計算し、リクエストの整合性を維持して送信中の改ざんを防止します。 以下のコードスニペット ( lambda/sigv4_signer.py より) は、OpenSearch UI API へのリクエストに署名して送信する方法を示しています。 def get_common_headers(body: bytes = b"{}") -> Dict[str, str]: """ Get common headers for OpenSearch UI API requests. Args: body: Request body bytes to hash Returns: Dictionary of required headers """ body_hash = hashlib.sha256(body).hexdigest() return { "Content-Type": "application/json", "x-amz-content-sha256": body_hash, "osd-xsrf": "osd-fetch", "osd-version": "3.1.0", } def make_signed_request( method: str, url: str, headers: Dict[str, str], body: bytes = b"", region: str = None, ) -> Any: session = boto3.Session() if not region: region = session.region_name # Create AWS request request = AWSRequest(method=method, url=url, data=body, headers=headers) # Sign with SigV4 using 'opensearch' service name (not 'es') credentials = session.get_credentials() SigV4Auth(credentials, "opensearch", region).add_auth(request) # Send request using URLLib3Session http_session = URLLib3Session() return http_session.send(request.prepare()) SigV4 署名関数は、正しいサービス名 ( opensearch ) を使用してリクエストに署名し、必要なヘッダーを添付して、OpenSearch UI エンドポイントに安全に送信します。 サンプルデータを使用したワークスペースとダッシュボードの作成 Lambda 関数 ( lambda/dashboard_automation.py ) は、OpenSearch UI API を通じてワークスペースのプロビジョニング、サンプルデータの生成、可視化とダッシュボードの作成のプロセス全体を自動化します。以下の API リストを参照してください。 Workspace API リスト Saved Objects API リスト 以下の手順に従います。 ワークスペースの検索または作成。OpenSearch UI の各ダッシュボードはワークスペース内に存在する必要があります。関数はまずワークスペースが既に存在するかどうかを確認し、必要に応じて作成します。ワークスペースは 1 つ以上のデータソース (OpenSearch ドメインや OpenSearch Serverless コレクションなど) を関連付けます。 def get_or_create_workspace(endpoint: str, region: str, data_source_id: str, workspace_name: str) -> Optional[str]: """Get existing workspace or create new one (idempotent).""" # Check for existing workspace workspace_id = find_workspace_by_name(endpoint, region, workspace_name) if workspace_id: return workspace_id # Create new workspace url = f"https://{endpoint}/api/workspaces" payload = { "attributes": {"name": workspace_name, "features": ["use-case-observability"]}, "settings": {"dataSources": [data_source_id]} } response = make_signed_request("POST", url, get_common_headers(), json.dumps(payload).encode(), region) return response.json()["result"]["id"] ワークスペース検索ロジックにより、繰り返しのデプロイが 冪等 になります。Lambda 関数は重複を作成するのではなく、既存のワークスペースを再利用します。 サンプルデータの生成と取り込み。最初の起動時にダッシュボードを意味のあるものにするために、Lambda 関数は HTTP リクエストメトリクスをシミュレートする小さなデータセットを生成し、Bulk API を使用して OpenSearch ドメインに取り込みます。 def generate_sample_metrics(num_docs: int = 50) -> list: """Generate realistic HTTP API request metrics.""" endpoints = ["/api/users", "/api/products", "/api/orders"] status_codes = [200, 201, 400, 404, 500] status_weights = [0.70, 0.15, 0.08, 0.05, 0.02]# Realistic distribution documents = [] for i in range(num_docs): documents.append({ "@timestamp": generate_timestamp(), "endpoint": random.choice(endpoints), "status_code": random.choices(status_codes, weights=status_weights)[0], "response_time_ms": random.randint(20, 500) }) return documents 関数はこのデータをドメインに取り込みます。 def ingest_sample_data(domain_endpoint: str, region: str, documents: list) -> bool: """Ingest documents using OpenSearch bulk API.""" index_name = f"application-metrics-{datetime.utcnow().strftime('%Y.%m.%d')}" bulk_body = " ".join([ f'{{"index":{{"_index":"{index_name}"}}}} {json.dumps(doc)}' for doc in documents ]) + " " url = f"https://{domain_endpoint}/_bulk" response = make_domain_request("POST", url, headers, bulk_body.encode(), region) return 200 <= response.status_code < 300 サンプルデータの取り込みにより、各デプロイに分析データが含まれ、最初のログイン時にダッシュボードにすぐにデータが表示されます。 可視化の作成。インデックスパターンが利用可能になった後、Lambda 関数は HTTP ステータスコードの分布を示す円グラフの可視化を作成します。 def create_visualization(endpoint: str, region: str, workspace_id: str, index_pattern_id: str) -> Optional[str]: """Create pie chart showing HTTP status code distribution.""" url = f"https://{endpoint}/w/{workspace_id}/api/saved_objects/visualization" vis_state = { "title": "HTTP Status Code Distribution", "type": "pie", "aggs": [ {"id": "1", "type": "count", "schema": "metric"}, { "id": "2", "type": "terms", "schema": "segment", "params": {"field": "status_code", "size": 10} } ] } payload = { "attributes": { "title": "HTTP Status Code Distribution", "visState": json.dumps(vis_state), "kibanaSavedObjectMeta": { "searchSourceJSON": json.dumps({ "index": index_pattern_id, "query": {"query": "", "language": "kuery"} }) } } } response = make_signed_request("POST", url, get_common_headers(), json.dumps(payload).encode(), region) return response.json().get("id") この可視化は、後でダッシュボードパネル内に埋め込まれます。 ダッシュボードの作成。最後に、Lambda 関数は前のステップで作成した可視化を参照するダッシュボードを作成します。 def create_dashboard(endpoint: str, region: str, workspace_id: str, viz_id: str) -> Optional[str]: """Create dashboard containing the visualization.""" url = f"https://{endpoint}/w/{workspace_id}/api/saved_objects/dashboard" # Define panel layout for the visualization panels_json = [{ "version": "2.11.0", "gridData": {"x": 0, "y": 0, "w": 24, "h": 15, "i": "1"}, "panelIndex": "1", "embeddableConfig": {}, "panelRefName": "panel_1" }] payload = { "attributes": { "title": "Application Metrics", "description": "HTTP request metrics dashboard", "panelsJSON": json.dumps(panels_json), "optionsJSON": json.dumps({"darkTheme": False}), "version": 1, "timeRestore": False, "kibanaSavedObjectMeta": { "searchSourceJSON": json.dumps({"query": {"query": "", "language": "kuery"}}) } }, "references": [{ "name": "panel_1", "type": "visualization", "id": viz_id }] } response = make_signed_request("POST", url, get_common_headers(), json.dumps(payload).encode(), region) return response.json().get("id") ダッシュボード作成プロセスが完了し、ユーザーがワークスペースにアクセスするとすぐにアプリケーションメトリクスのインタラクティブな可視化が提供されます。 ロギング、エラー処理、ヘルパーユーティリティを含む完全な実装は、 AWS Samples GitHub リポジトリ で入手できます。 AWS CDK によるインフラストラクチャのデプロイ AWS CDK スタックと Lambda 自動化が整ったら、完全なソリューションをデプロイして、OpenSearch UI ダッシュボードが自動的に作成されることを確認する準備ができました。 スタックのデプロイ クローンしたリポジトリのルートディレクトリから、AWS CDK フォルダに移動し、 前提条件 セクションの IAM ユーザー ARN を使用してスタックをデプロイします。 cd cdk npm install npx cdk bootstrap# First time only npx cdk deploy -c masterUserArn=arn:aws:iam::123456789012:user/your-username AWS CDK が OpenSearch ドメイン、OpenSearch UI アプリケーション、Lambda 関数、自動化を実行するカスタムリソースをプロビジョニングするため、デプロイプロセスには通常 20〜25 分かかります。 デプロイの確認 デプロイが完了したら: AWS CDK 出力に表示される OpenSearch UI エンドポイントを開きます。 IAM 認証情報を使用してサインインします。 新しく作成された workspace-demo ワークスペースに切り替えます。 Application Metrics ダッシュボードを開きます。 サンプルデータからの HTTP ステータスコードの分布を表示する円グラフの可視化を確認します。 ダッシュボードには、合成アプリケーションメトリクスが入力された円グラフの可視化が自動的に表示され、Saved Objects API を使用してデプロイ直後に意味のある分析ダッシュボードをブートストラップする方法を示しています。 拡張 1: Saved Object Import API によるダッシュボード作成の簡素化 OpenSearch Dashboards が進化するにつれて、インデックスパターン、可視化、ダッシュボード間の複雑な依存関係の管理がますます困難になる可能性があります。各ダッシュボードは複数の保存オブジェクトを参照することが多く、環境間で手動で再作成または同期することは時間がかかり、エラーが発生しやすくなります。 ダッシュボード管理を簡素化するために、Saved Objects Import/Export API の使用をお勧めします。この API を使用すると、依存オブジェクトを含むダッシュボード全体を単一の転送可能なアーティファクトにバンドルできます。このアプローチにより、ダッシュボードを CI/CD ワークフローの一部としてバージョン管理、移行、環境間でデプロイでき、一貫性を維持しながら運用オーバーヘッドを削減できます。 ダッシュボードのエクスポート ダッシュボードは OpenSearch UI から直接エクスポートするか、 saved object export API を使用できます。 Stack Management を開き、次に Saved Objects を開きます。 ダッシュボードと関連オブジェクト (可視化やインデックスパターンなど) を選択します。 Export を選択します。 エクスポートしたファイルを dashboard.ndjson として保存します。 このファイルには、改行区切り JSON (NDJSON) 形式でシリアル化された保存オブジェクトが含まれており、バージョン管理やデプロイ自動化に使用できます。 プログラムによるダッシュボードのインポート Saved Objects import API を使用して、NDJSON ファイルをターゲットワークスペースにプログラムでインポートできます。 # Pseudo code for import function def import_dashboard(workspace_id, ndjson_file): # Read the exported dashboard file dashboard_config = read_file(ndjson_file) # POST to import to opensearch ui endpoint url = f"{opensearch_ui_endpoint}/w/{workspace_id}/api/saved_objects/_import" response = make_signed_request("POST", url, dashboard_config) return response.success Import/Export API により、ダッシュボードをアプリケーションコードと同様にデプロイ可能なアセットとして扱うことができます。エクスポートしたダッシュボードをソース管理に保存し、AWS CDK または CloudFormation パイプラインに統合して、複数の環境に自信を持って自動的にデプロイできます。 拡張 2: セキュリティ設定の強化 場合によっては、OpenSearch UI アプリケーションのセキュリティ設定を強化したい場合や、追加のセキュリティ設定でデプロイされた OpenSearch ドメインを扱っている場合があります。以下では、OpenSearch UI アプリケーションのセキュリティ設定を強化しながら、AWS CDK で IaC を実現する方法について説明します。具体的には、OpenSearch ドメインが VPC 内にある場合や、きめ細かなアクセス制御が有効になっている場合の OpenSearch UI アプリケーションのセットアップ方法を説明します。 OpenSearch ドメインが VPC 内にある場合、ダッシュボードと適切に接続するために追加の設定が必要になります。 データを取り込む Lambda 関数と VPC 内の OpenSearch ドメイン間の通信を有効にする OpenSearch Service ドメインが VPC 内にある場合、ドメインにデータを取り込む Lambda 関数はドメインと通信できる必要があります。最も簡単な方法は、Lambda 関数を OpenSearch Service ドメインと同じ VPC 内で実行し、同じセキュリティグループを付与することです。例は GitHub リポジトリ で提供されています。 OpenSearch Service ドメインと通信しようとするクライアントからの HTTPS 通信を許可します。この例では、クライアントは OpenSearch Service ドメインで使用されているのと同じセキュリティグループを使用します。 openSearchSecurityGroup.addIngressRule( openSearchSecurityGroup, ec2.Port.tcp(443), 'Allow inbound HTTPS traffic from itself', ); Lambda 関数が引き受けるロールにこのマネージドポリシーを追加して、VPC へのアクセスを許可します。 iam.ManagedPolicy.fromAwsManagedPolicyName('service-role/AWSLambdaVPCAccessExecutionRole') Lambda 関数が使用する VPC とセキュリティグループを指定します。この場合、VPC は OpenSearch Service ドメインで使用されているものと同じです。 const dashboardFn = new lambda.Function(this, 'DashboardSetup', { // ... additional configuration vpc: vpc, securityGroups: [openSearchSecurityGroup] }); VPC エンドポイントアクセスのための OpenSearch UI サービスの認可 OpenSearch Service ドメインがダッシュボードからアクセスできるようにするには、VPC エンドポイントアクセスを有効にする必要があります。これは、以下の設定に示すようにカスタムリソースを使用して実現できます。 const authorizeOpenSearchUIVpcAccess = new cr.AwsCustomResource(this, 'AuthorizeOpenSearchUIVpcAccess', { onUpdate: { service: 'OpenSearch', action: 'authorizeVpcEndpointAccess', parameters: { DomainName: opensearchDomain.domainName, Service: 'application.opensearchservice.amazonaws.com', }, physicalResourceId: cr.PhysicalResourceId.of(`${opensearchDomain.domainName}-VpcEndpointAccess`), }, policy: cr.AwsCustomResourcePolicy.fromStatements([ new iam.PolicyStatement({ actions: ['es:AuthorizeVpcEndpointAccess'], resources: [opensearchDomain.domainArn], }), ]), }); きめ細かなアクセス制御の有効化 きめ細かなアクセス制御を OpenSearch UI と組み合わせて使用すると、各ユーザーに許可される操作をより細かく制御できます。これは、OpenSearch UI に付属する管理者、読み取り、書き込み権限を超えてユーザーのアクションを制限したい場合に特に便利です。固有のロールを作成し、1 人以上のユーザーにマッピングして、誰がどの機能にアクセスできるかを正確に制御できます。 前のセクションでは、同じ Lambda が OpenSearch Service ドメインと OpenSearch UI の両方にリクエストを行うために使用されました。ただし、OpenSearch Service ドメインと OpenSearch UI の間でメインロールが同じでない状況では、各ロールに対して Lambda 関数を作成することをお勧めします。前述のように、OpenSearch UI の自動化をデプロイする際、依存関係を正しく解決するためにリソース作成の順序が重要です。推奨される順序は以下のとおりです。 ダッシュボード Lambda 実行ロールの作成 – AppConfigs と API へのアクセスに必要 OpenSearch ドメインメインロールの作成 – ドメインの作成と API に必要 OpenSearch ドメインの作成 – プライマリデータソースとして機能 OpenSearch ドメイン Lambda 関数の作成 – OpenSearch ドメインの自動化ロジックを定義 OpenSearch ドメインカスタムリソースの作成 – スタックデプロイ中に Lambda 自動化をトリガー OpenSearch UI アプリケーションの作成 – AppConfigs で Lambda ロールを参照 OpenSearch UI Lambda 関数の作成 – OpenSearch UI の自動化ロジックを定義 OpenSearch UI カスタムリソースの作成 – スタックデプロイ中に Lambda 自動化をトリガー OpenSearch Service ドメインを作成する際、以下のようにきめ細かなアクセス制御パラメータを指定します。 // Step 3: Create OpenSearch Domain const opensearchDomain = new opensearch.Domain(this, 'OpenSearchDomain', { // ... additional configuration // Enable Fine-Grained Access Control in your OpenSearch Domain fineGrainedAccessControl: { masterUserArn: openSearchMasterRole.roleArn, } }); OpenSearch Service ドメインと通信する Lambda 関数には、ドメインに書き込むために必要な権限が必要です。以下は、Lambda 関数がドメインのメインロールを引き受ける設定例です。 // Step 4: Create Lambda Function for OpenSearch Domain const domainFn = new lambda.Function(this, 'DomainSetup', { // ... additional configuration role: openSearchMasterRole }); 次に、必要に応じてロールとロールマッピングを作成するカスタムリソースを追加します。 // Step 5: Create Custom Resources for OpenSearch Domain const domainProvider = new cr.Provider(this, 'DomainProvider', { onEventHandler: domainFn }); // A custom resource to create roles (Optional) new cdk.CustomResource(this, 'DomainRoleSetupResource', { serviceToken: domainProvider.serviceToken, // ... additional configuration }); // A custom resource to create role mappings (Optional) new cdk.CustomResource(this, 'DomainRolesMappingSetupResource', { serviceToken: domainProvider.serviceToken, // ... additional configuration }); OpenSearch Service ドメインでの追加ロールの作成 (オプション) 一部のユーザーに特定の権限を付与したい場合は、ロールを作成することをお勧めします。これは、OpenSearch Service ドメインエンドポイントへのリクエストで実現できます。 roles エンドポイントの詳細については、OpenSearch ドキュメントの Create role を参照してください。 # Pseudo code to create a role def create_role(domain_endpoint: str, region: str, new_role_name: str) -> bool: """Create a new role""" url = f"https://{domain_endpoint}/_plugins/_security/api/roles/{new_role_name}" payload = { "description": "", "cluster_permissions": [ // ... Permisions ], "index_permissions": [ { "index_patterns": [ // ... Index patterns ], "fls": [], "masked_fields": [], "allowed_actions": [ // ... Allowed actions ], }, ], } response = make_domain_request("PUT", url, headers, json.dumps(payload).encode(), region) return response.success ダッシュボードユーザー用の OpenSearch ドメインでのロールマッピングの作成 (オプション) ユーザーを 1 つ以上のロールにマッピングして、OpenSearch Service ドメインへのアクセスを制御できます。これは、ドメインに接続された OpenSearch UI ダッシュボードに反映されます。 rolesmapping エンドポイントの詳細については、OpenSearch ドキュメントの Create role mapping を参照してください。 # Pseudo code to create a role mapping def create_role_mapping(domain_endpoint: str, region: str, new_role_name: str) -> bool: """Create a new role mapping""" url = f"https://{domain_endpoint}/_plugins/_security/api/rolesmapping/{new_role_name}" payload = { "backend_roles": [ "", "", ], } response = make_domain_request("PUT", url, headers, json.dumps(payload).encode(), region) return response.success 実装に関する重要な注意点: デフォルトでは、OpenSearch ドメインはメインユーザー用のロールマッピングを all_access と security_manager の下に作成します。これらのマッピングを変更する場合は、誤ってアクセスを失わないようにメインユーザーをリストに残しておくことをお勧めします。 きめ細かなアクセス制御を使用する場合、ユーザーが OpenSearch ドメインのロールにマッピングされずに OpenSearch UI を開くと、OpenSearch UI の管理者グループに属していても、OpenSearch ドメインにあるデータを可視化または変更できません。このため、適切なロールマッピングを追加するカスタムリソースを作成することをお勧めします。OpenSearch UI 管理者は引き続き OpenSearch UI ダッシュボードに変更を加えることができます。 OpenSearch ドメイン API とプログラムでやり取りする場合、Lambda 関数や自動化スクリプトが API に安全にアクセスできるように適切な認証が必要です。OpenSearch ドメインは SigV4 認証を使用します。OpenSearch ドメイン API リクエストに署名する際、サービス名は es である必要があります。 コストに関する考慮事項 本ソリューションは複数の AWS サービスを使用しており、それぞれに独自のコストコンポーネントがあります。 Amazon OpenSearch Service – 主なコスト要因です。料金はインスタンスタイプ、ノード数、 Amazon Elastic Block Store (Amazon EBS) ストレージに基づきます。テストには、より小さいインスタンス (例: t3.small.search ) を使用するか、使用後にドメインを削除してコストを最小限に抑えることができます。 AWS Lambda – 自動化関数はデプロイ中にのみ実行され、数回の短い呼び出しに対して最小限の料金が発生します。 AWS CDK と CloudFormation – 一時的な IAM ロールと Amazon S3 デプロイアセットを作成しますが、コストはごくわずかです。 料金の詳細については、 Amazon OpenSearch Service の料金 を参照してください。 クリーンアップ テストが完了したら、継続的なコストを避けるためリソースをクリーンアップしてください。プロジェクトディレクトリを開き、AWS CDK スタックを削除します。 cd cdk npx cdk destroy cdk destroy コマンドは、AWS CDK スタックによってプロビジョニングされたリソースを削除します。これには以下が含まれます。 Amazon OpenSearch Service ドメイン OpenSearch UI アプリケーション AWS Lambda 関数とカスタムリソース デプロイに関連付けられた IAM ロールとポリシー クリーンアップにより、関連する料金を停止し、コスト効率の良い AWS 環境を維持できます。 その他のリソース Amazon OpenSearch Service ドキュメント AWS CDK カスタムリソースドキュメント OpenSearch Dashboards API リファレンス API リクエストの AWS Signature Version 4 まとめ Saved Objects API を次世代 Amazon OpenSearch UI と統合することで、ワークスペース、サンプルデータ、可視化、ダッシュボードを含む分析エクスペリエンス全体を IaC から直接プログラムで作成できます。 このアプローチにより、IaC の力を分析レイヤーにもたらします。AWS CDK と AWS Lambda を使用することで、ダッシュボードを環境間で一貫してバージョン管理、デプロイ、更新でき、手動セットアップを削減しながら信頼性とガバナンスを向上させます。ダッシュボード自動化により、チームはセットアップではなくインサイトに集中でき、組織とともにスケールする observability-as-code を実現できます。 著者について Zhongnan Su Zhongnan は、Amazon Web Services (AWS) の Amazon OpenSearch Service チームのソフトウェア開発エンジニアであり、OpenSearch Dashboards のアクティブなメンテナーです。オープンソースプロジェクトと AWS マネージドサービスの両方で、クラウドベースのインフラストラクチャの構築と、開発者エクスペリエンスを向上させる基盤となる UI およびプラットフォームの強化に取り組んでいます。 Paul-Andre Bisson Paul-Andre は、Amazon Pharmacy のソフトウェアエンジニアです。Amazon Pharmacy の配送を調整し、お客様へのタイムリーな配達を可能にするインフラストラクチャの開発と保守を担当しています。プロセス最適化に情熱を持ち、既存のワークフローの分析、ソリューションの実装、より広いコミュニティとのインサイトの共有を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の榎本 貴之がレビューしました。

この記事は 2025 年 12 月 22 日に公開された When data is all you need: An overview of IoT communication with the cloud を翻訳したものです。翻訳はプロフェッショナルサービスの権藤 陸が担当しました。 IoT（Internet of Things）プログラムに取り組む技術チームやマーケティングチームは、遅かれ早かれ、デバイス群（フリート）とクラウド間でデータをやり取りする必要があるプロジェクトに直面します。このデータは極めて重要です。マーケティングはユーザーにより多くの機能を提供したいと考え、ビジネスチームはデータに基づく意思決定を求め、技術チームは既存デバイスフリートとの接続性を最適化しようとします。これらすべての理由は、最終的にはカスタマーエクスペリエンスの向上という一点に収束します。本記事では、IoT プロジェクトの初期段階と、デバイスとクラウド間で通信するために利用可能な選択肢のいくつかを紹介します。また、要件やプロジェクト制約に基づいて通信方式を選択するための具体的な指針も提供します。一般的なソリューションから、あまり標準的ではないアプローチまでを取り上げ、コスト・スコープ・期間を損なう典型的な落とし穴を回避するための助けとなることを目的としています。 IoT デバイスとデバイスデータ IoT プロジェクトに携わる前、私は IoT をデバイス中心の視点で捉えていました。接続されたデバイスは、センサーやアクチュエータを通じて現実世界と相互作用する、IoT の中核コンポーネントです。しかし、それはソリューションの一部にすぎません。もう一つの重要な要素が「データ」です。プロジェクトによっては、必要なのはデバイスデータだけというケースもあります。多くの IoT プロジェクトでは、最初の技術的な議論は、デバイスとクラウド間でデータをどのように流すか、そしてどの通信プロトコルが必要かという点に集中します。では、どの通信プロトコルが必要なのでしょうか。結論から言えば、ケースバイケースです。さまざまなプロジェクト、プロトタイプ、業界での経験を通じて、単一のプロトコルだけを使う必要はないということを学びました。プロジェクトごとに適切な通信プロトコルを選択することは、探索的なプロセスになることもあります。その鍵となるのが、次の 4 つのシステム制約に分解して考えることです。 デバイス： メモリ容量、利用可能な通信インターフェース、計算能力、消費電力といった物理的な制約は何か。 データ： デバイスで収集されるデータの種類は何か。各データタイプの量（ボリューム）はどれくらいか。データの流れは双方向か片方向か。 コスト： 各データタイプにおける通信コストはいくらか。できるだけ早くクラウドに送るだけの価値があるか。 セキュリティ： 単にデータを送受信するだけでは不十分です。通信は、認証・認可・検証・プライバシーポリシーをサポートする安全な方法で管理される必要があります。セキュリティ機能は、分析段階および通信プロトコル選定時の基盤要件として考慮しなければなりません。 注： 本記事で紹介する各通信プロトコルは、X.509 証明書、カスタムオーソライザー、フェデレーションなど、さまざまな認証方式を実装できます。 MQTT プロトコル MQTT は、IoT プロジェクト向けの標準的なメッセージングプロトコルです。双方向で、軽量かつスケーラブルであり、HTTP と同様にアプリケーションレイヤの高レベルプロトコルですが、特性は異なります。また、多くのライブラリやプログラミング言語で広くサポートされています。 OSI モデルにおける HTTP と MQTT プロトコル MQTT は パブリッシュ-サブスクライブモデルに基づいており、ブローカーがクライアント間の通信を仲介します。基本的な MQTT メッセージは、メッセージ内容を階層的に識別する「トピック」と、JSON、バイナリ、テキストなどの形式で表現される「ペイロード」という 2 つの要素で構成されます。 もしプロジェクトにおいて、デバイスとクラウド間でメッセージを送受信するための通信チャネルが必要な場合、MQTT は非常に適した選択肢です。MQTT を利用することで、デバイスのデータやステータスをクラウドに送信し、クラウドからのリクエストやメッセージを受信できます。シンプルで柔軟な設計を維持しながら、MQTT はアプリケーションを簡素化するための機能をネイティブに提供します。たとえば、適切なトピック階層構造を設計することで、デバイスが送信または受信できるメッセージを効率的に制御できます。詳細については AWS IoT Core 向け MQTT トピック設計 を参照してください。 AWS IoT Core は、MQTT、MQTT5、MQTT over WebSocket、HTTPS プロトコルをサポートしています。また、MQTT ブローカーとして動作し、デバイスをクライアントとして扱います。AWS IoT Core は、さまざまな追加機能やサービスを提供しています。たとえば、デバイスの自動プロビジョニングを可能にする仕組みや、デバイスタイプ・属性・タグに基づいて静的または動的なデバイスグループ（ジョブ）を制御する機能などがあります。さらに、単一デバイスの運用から、デバイスフリート全体の管理へと移行することもサポートしています。 AWS IoT Core を用いた MQTT 通信 データストリームと MQTT デバイスから送信される MQTT メッセージには、通常、測定値、ステータス、イベント、制御データ、設定データなどが含まれます。このプロトコルは柔軟性が高く、1 つのメッセージに 1 つまたは複数のデータペイロードを含めることができます。たとえば、単一のイベントを含むメッセージもあれば、特定の時点における複数の測定値やデバイスステータスを含む JSON オブジェクトをペイロードとして送信することも可能です。一方で、複数のメッセージを管理するよりも、ストリームベースの通信が適しているケースもあります。代表的なユースケースの一つが、デバイスの不揮発性メモリにローカル保存またはキャッシュされているデータを扱う場合です。デバイスは、定期的に、あるいはリクエストに応じてオンデマンドでこれらのデータを送信できます。また、ストリームは、高ボリュームで準リアルタイムなデータを送信する際にも一般的に利用されます。たとえば、複数のデバイスから生の測定データを送信し、クラウド上で処理・分析を行うケースです。 データまたは映像ストリームの取り込み Amazon Kinesis は、データやビデオストリームの取り込み、処理、分析をサポートするサービス群です。代表的なユースケースとして、デバイスから Amazon Kinesis Data Streams へデータをストリーミングするケースがあります。詳細については、 AWS IoT Core および Amazon Kinesis を用いたデバイスデータ取り込みのベストプラクティス を参照してください。これら 2 つの通信チャネルは、クラウドとの通信要件を満たすために、同一デバイス上で併用されることも少なくありません。 送信専用（メッセージ送信のみ）パターン 一部のプロジェクトでは、デバイスからクラウドへの軽量な片方向通信レイヤのみが求められます。アプリケーション、デバイス、またはプロジェクト上の制約により、デバイスとクラウド間で双方向通信を確立することが常に可能とは限りません。また、システムがサードパーティによって開発されており、新たな機能追加が難しい場合にも、このような片方向通信の構成が採用されることがあります。 双方向通信は、デバイスがステータス更新や測定値を送信し、それに対してクラウドが確認応答を返す場合に一般的に用いられます。一方で、この片方向通信パターンをサポートするために、AWS IoT Core、 Amazon API Gateway または AWS AppSync などのサービスを利用できます。ただし、これは publish-only プロトコルであるため、デバイス側はクラウドの更新情報を取得するためにポーリングを行う必要があります。その結果、デバイス切断検知などの機能は、他のプロトコルのように標準で提供されず、追加実装が必要になります。 HTTP によるリクエストのみの通信 MQTT が利用できない場合でも、HTTPS プロトコルを使用し、レスポンスメッセージを通じてクラウドからデータを受信することが可能です。データが AWS に取り込まれた後は、200 を超える AWS のマネージドサービスを利用して、データの処理、分析、知能化を行えます。 デバイスで静的データを受信する デバイスまたはデバイスフリートが、クラウドから静的または準静的なデータを読み取る必要がある場合もあります。たとえば、設定情報やソフトウェアアップデートなどです。アプリケーションですでに MQTT プロトコルを実装している場合、 MQTT シャドウ は、設定情報のような比較的小さな静的データを取得するための効率的な手段です。詳細については、 AWS IoT Core のメッセージブローカーおよびプロトコルの制限とクォータ を参照してください。 Amazon S3 バケットからの読み取り ファームウェア更新のように、バージョン番号やステータスを含む比較的大きなファイルについては、 Amazon Simple Storage Service (Amazon S3) から直接ダウンロードできます。 S3 からの能動的なデータ受信：双方向プロトコルと片方向プロトコルの比較 デバイスを 伴わない IoT プロジェクト（稀なケース） IoT デバイスを直接扱って開発を行うことが、常に可能とは限りません。たとえ複数のデバイスを管理する IoT クラウドアプリケーションを構築することが目的であっても、さまざまな制約によって状況が複雑になる場合があります。たとえば、次のようなケースです。 現場に展開済みの既存デバイスを更新できない、または更新に非常に大きな開発工数が必要な場合。 既存システムが依存しているため、現在のデバイス通信機能を変更できない場合。 サードパーティ製デバイスが含まれる場合。これには、独自の制御システムや独自の通信プロトコルを持つデバイス、あるいはチーム側で変更できないクローズドなシステムが含まれる可能性があります。 実現可能性の検証やシステム全体像の把握が目的であれば、IoT クラウド基盤およびアプリケーションのプロトタイプを開発することが有効です。この際、既存デバイスのテレメトリデータや制御機能を活用できます。このアプローチには、主に次の 2 つの戦略が考えられます。 クラウド間（Cloud-to-Cloud）通信ソリューションを実装する。 既存デバイス API に対するラッパーを開発する。 デバイス開発を伴わない、クラウド間通信 クラウド間通信を利用することで、既存ソリューションを新しい開発から分離できるという利点があります。また、異なるアプリケーションプロトコルを使用してデバイステレメトリデータを転送し、データの制御性を高めることも可能です。既存アプリケーションと新規アプリケーション間に仮想ネットワークを構築するために、 Amazon Virtual Private Cloud (Amazon VPC) を活用することも考えられます。この通信方式は、たとえばデバイスグループ単位で測定値や状態を受信するようなケースでは、非常に効率的です。一方で、Amazon VPC の運用には追加の管理工数が必要となります。また、対象デバイスがサードパーティ製である場合には、共同開発が必要になることがあり、これが導入の障壁となることもあります。 デバイス開発を伴わない、既存の通信機能を活用する方式 もう一つの選択肢は、 Amazon API Gateway を利用して、外部システムがすでに提供している API を活用するラッパーを開発する方法です。典型的なユースケースとしては、REST API や WebSocket API と通信するケースが挙げられます。サードパーティ API を利用する場合、1 秒あたり、1 分あたり、あるいは 1 日あたりのリクエスト数を制限するセキュリティ対策が施されていることがあります。これらの制約はスケーラビリティを制限する要因となる可能性があるため、事前に考慮しておく必要があります。 結論 IoT の強みの一つは、通信、データ保存、そしてエッジで意思決定を行える点にあります。IoT プロジェクトの進め方としては、デバイス（モノ）を起点に、その能力に基づいて設計を行うアプローチがあります。一方で、本記事では、データ中心のモデルに基づく異なるアプローチを紹介しました。最初にデータに着目することで、よりコスト効率の高いソリューションを設計できます。また、複数の通信プロトコルを使ってデータを取得することで、プロジェクトの目的や制約に合致した構成を実現できます。 参考文献 [ 1 ] https://aws.amazon.com/what-is/mqtt/ [ 2 ] https://docs.aws.amazon.com/pdfs/whitepapers/latest/designing-mqtt-topics-aws-iot-core/designing-mqtt-topics-aws-iot-core.pdf [ 3 ] https://aws.amazon.com/blogs/iot/best-practices-for-ingesting-data-from-devices-using-aws-iot-core-and-or-amazon-kinesis/ [ 4 ] https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html [ 5 ] https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits 著者について Alfonso Torres Soto は、インダストリアルエンジニア（修士）およびプロジェクトマネージャー（PMP）です。AWS のソリューションアーキテクトとして、お客様のアイデアを現実のものにする支援を行っています。テクノロジーと哲学の双方に情熱を持っています。 <!-- '"` -->

はじめに 現代のデジタル社会において、組織はサイバーセキュリティの脅威に対する懸念を強めており、インフラストラクチャをより適切に保護する方法を積極的に模索しています。高度化するサイバー攻撃の増加と、より厳格になるデータ保護規制により、コンテンツ配信インフラのセキュリティ確保は企業にとって重要事項となっています。安全なコンテンツ配信ソリューションの必要性は、かつてないほど高まっています。 最近、 Amazon CloudFront は CloudFront VPC オリジン のサポートを発表しました。これにより、顧客は CloudFront ディストリビューションからのみプライベートサブネット内のオリジンにルーティングできるようになりました。このアーキテクチャでは、パブリック IP アドレスやインターネットゲートウェイが不要となり、防御と監視が必要な攻撃対象領域を効果的に最小化できます。 現代のインターネットベースのアプリケーションにおいて、セキュリティは重要ですが、顧客は包括的なアプリケーションアーキテクチャとして、高可用性も必要としています。AWS は、CloudFront VPC オリジンと CloudFront Functions を使用したマルチリージョンのアクティブ/アクティブ構成によって、これらの要件に対応できます。 ユースケース概要 図1. CloudFront VPC オリジンを使用したマルチリージョンのアクティブ/アクティブ構成 マルチリージョンのアクティブ/アクティブ構成を実装することで、複数の AWS リージョン（例：us-east-1 と us-west-1）でワークロードを同時に実行し、各リージョンがアクティブにトラフィックを処理します。CloudFront VPC オリジンは、CloudFront Functions を通じて加重ルーティングを実装することが可能であり、各リージョンの重みは CloudFront KeyValueStore に保存できます。これにより、再デプロイなしでリージョン間のトラフィック分散を調整できます。例えば、リージョン間でトラフィックを 50/50 に分割し、運用ニーズに基づいてリアルタイムで調整することが可能です。この構成により、単一リージョンに障害が発生した場合でも他のリージョンでサービスを継続できるため、アプリケーションの可用性が向上します。また、トラフィックの重み付け調整により、計画的なメンテナンスやパフォーマンス最適化時にも柔軟に対応できます。 マルチリージョン構成では、データベースのレプリケーション戦略も重要な検討事項となります。リージョン間でデータベースをレプリケーションする場合、レプリケーション遅延が発生するため、ユーザーが異なるリージョンにアクセスすると、データの不整合が発生する可能性があります。このような場合、Session Affinity の実装を推奨します。CloudFront Functions で Cookie ベースのルーティングを利用することで、同一ユーザーのリクエストを一貫して同じリージョンにルーティングし、データ整合性を保証できます。 さらにプライマリとセカンダリの 2 つの CloudFront VPC オリジンを持つ オリジングループ に対してトラフィック分散することにより、あるリージョンで障害が発生した場合に正常なリージョンにフェールオーバーするため、回復性を高めることも可能です。 この構成は、インフラストラクチャを保護するだけでなく、リージョン障害やその他のサービス中断を伴うシナリオにおいて、アプリケーションの可用性を確保します。CloudFront VPC オリジンとマルチリージョン展開の組み合わせにより、セキュリティと可用性が両立する包括的なソリューションを実現し、現代の重要システムの要件を満たすことが可能です。 セットアップ手順 ステップ 0：前提条件 セットアップを開始する前に、以下の前提条件が満たされていることを確認してください： CloudFront ディストリビューション VPC オリジンとして、異なるリージョンに配置された 2 つの内部 Application Load Balancer（ALB） 以降のステップに進む前に、ALB と ALB ターゲットグループ の設定をテストしてください。ALB と ALB ターゲットグループの設定については、 Application Load Balancer の作成 を参照してください。 CloudFront ディストリビューション用の VPC オリジンは、 AWS Management Console または AWS Command Line Interface（CLI） を使用して作成できます。このブログ記事では、AWS コンソールを使用して作成する方法を説明します。 ステップ 1：VPC オリジンのセットアップ 1. Amazon CloudFront コンソールを開き、 [VPC origins] を選択し、 [Create VPC origin] をクリックして、新しい VPC オリジンを作成します。以下に示すように、VPC オリジン名を入力し、オリジン ARN を選択します。 図2. VPC オリジンの作成 2. 両リージョンの VPC オリジンが作成されたことを確認してください。新しい VPC オリジンのステータスは最初 “Deploying” となり、以下に示すように、使用可能な状態になると “Deployed” に変わります。 図3. VPC オリジンのデプロイ確認 3. Amazon CloudFront コンソールを開き、 [Distributions] を選択してから、該当するディストリビューションを選択します。次に [Origins] タブを選択し、 [Create origin] をクリックします。 Origin domain として VPC オリジンを選択し、 [Create origin] をクリックして、以下に示すようにディストリビューションに VPC オリジンを追加します。 図4. ディストリビューションへの VPC オリジンの追加 4. 以下に示すように、両方の VPC オリジンがディストリビューションに追加されたことを確認します。 図5. ディストリビューションへの VPC オリジン追加の確認 5. Amazon CloudFront コンソールを開き、 [Distributions] を選択してから、該当するディストリビューションを選択します。次に [Origins] タブを選択し、 [Create origin group] をクリックします。以下に示すように、 Origins のプライマリとセカンダリの VPC オリジンに加え、 Failover criteria を指定し、デフォルト用のオリジングループを作成します。 図6. ディストリビューションへのオリジングループ追加 6. 以下に示すように、オリジングループがディストリビューションに追加されたことを確認します。 図7. ディストリビューションへのオリジングループ追加の確認 ステップ 2：CloudFront KeyValueStore の設定 1. 以下に示すように、キーと値が含まれる JSON ファイルを S3 バケットにアップロードします。キーと値のペアは、CloudFront KeyValueStore コンソールから直接追加することもできます。このブログ記事では、JSON ファイルをアップロードし、KeyValueStore 作成時に S3 URI を指定する方法で実施します。 { "data": [ { "key": "origin-group-us-east-1-primary", "value": "50" }, { "key": "origin-group-us-west-1-primary", "value": "50" } ] } 図8. VPC オリジンの重み付け設定用 JSON ファイル（キー：オリジン名、値：重み） 図9. JSON ファイルの S3 バケットへのアップロード 2. Amazon CloudFront コンソールを開き、 [Functions] と [KeyValueStores] タブを選択します。 [Create KeyValueStores] をクリックして KeyValueStore を作成し、以下に示すように、KeyValueStore 名を入力し、JSON ファイルの S3 URI を指定した後、 [Create] をクリックします。 図10. KeyValueStoreの作成 3. KeyValueStore が作成されたことを確認します。新しい KeyValueStore の Last modified は、最初 “Provisioning” と表示され、以下に示すように、使用可能になるとタイムスタンプに変更されます。 図11. KeyValueStore のデプロイ確認 ステップ 3：CloudFront Functions の設定 1. Amazon CloudFront コンソールを開き、 [Functions] を選択します。 [Create function] から以下に示すように、関数名を入力して JavaScript バージョンを指定した後、 [Create function] をクリックして関数を作成します。 図12. 重み付けルーティング用の関数作成 2. [Associate existing KeyValueStore] をクリックし、作成した KeyValueStore を選択して、関数に KeyValueStore を関連付けます。以下に示すように、選択後、 [Associate KeyValueStore] をクリックします。 図13. 関数への KeyValueStore の関連付け 3. [Development] ウィンドウ内の [Build] タブで重み付けルーティングのロジックを実装し、以下に示すように [Save changes] をクリックします。 import cf from "cloudfront"; // Initialize CloudFront KeyValueStore const kvs = cf.kvs(); /** * Origin Group configurations * OriginGroup1: us-east-1 (primary), us-west-1 (secondary) * OriginGroup2: us-west-1 (primary), us-east-1 (secondary) */ const originGroups = [ { name: "origin-group-us-east-1-primary", originIds: [ "vpc-origin-us-east-1-internal-webapp-alb", "vpc-origin-us-west-1-internal-webapp-alb" ] }, { name: "origin-group-us-west-1-primary", originIds: [ "vpc-origin-us-west-1-internal-webapp-alb", "vpc-origin-us-east-1-internal-webapp-alb" ] } ]; /** * Failover criteria configuration * Defines which HTTP status codes should trigger failover to secondary origin */ const failoverCriteria = { statusCodes: [500, 502, 503, 504] }; /** * Selects an Origin Group index based on weighted probability * * @param {Array&lt;number&gt;} weights - Array of weights corresponding to each Origin Group * @returns {number} - Index of the selected Origin Group */ function getOriginGroupIndex(weights) { // Calculate the sum of all weights const sum = weights.reduce((total, weight) =&gt; total + weight, 0); // Generate a random number between 1 and the sum of weights let choice = Math.floor(Math.random() * sum) + 1; // Start from the last Origin Group and work backwards let index = weights.length - 1; // Subtract each weight from our random number until we find the selected Origin Group while ((choice -= weights[index]) &gt; 0) { index -= 1; } return index; } /** * Retrieves the current weight configuration for each Origin Group from KVS * * @returns {Promise&lt;Array&lt;number&gt;&gt;} - Array of weights for each Origin Group */ async function getWeightsFromKvs() { const weights = []; // Fetch weight for each Origin Group from the KeyValueStore for (let i = 0; i &lt; originGroups.length; i++) { const weight = await kvs.get(originGroups[i].name); weights.push(parseInt(weight, 10)); // Convert string to integer with base 10 } return weights; } /** * CloudFront function handler that routes requests to Origin Groups based on weighted distribution * * @param {Object} event - CloudFront event object * @returns {Object} - Modified request object */ async function handler(event) { // Get current weights for each Origin Group const weights = await getWeightsFromKvs(); // Select an Origin Group based on the weighted distribution const selectedOriginGroupIndex = getOriginGroupIndex(weights); const selectedOriginGroup = originGroups[selectedOriginGroupIndex]; // Create and route to the selected Origin Group with originIds array and failover criteria cf.createRequestOriginGroup({ originIds: selectedOriginGroup.originIds, failoverCriteria: failoverCriteria }); return event.request; } 図14. 重み付けルーティング用の関数サンプルコード 注意: このコードはあくまでサンプルコードです。本番環境での利用を想定したものではありません。 図15. 開発ウィンドウでの重み付けルーティングロジックの実装 4. [Publish] タブを選択し、以下に示すように [Publish function] をクリックして関数を公開します。 図16. 関数の公開 5. 関数が公開されたことを確認します。以下に示すように、ステータスは “Development” から “Published” に変更されます。 図17. 関数の公開確認 6. Amazon CloudFront コンソールを開き、 [Distributions] を選択してから、該当するディストリビューションを選択します。次に [Behaviors] タブを選択し、 [Create Behavior] をクリックします。以下に示すように、 Path pattern の入力と Origin and origin groups にデフォルト用のオリジングループを指定します。 図18. Path pattern と Origin and origin groups の入力 7. [Function associations] セクションで、 Function type として CloudFront Functions を選択し、 Viewer request として先ほどの関数を選択します。以下に示すように、最後に [Create behavior] をクリックします。 図19. Viewer request としての関数の関連付け ステップ 4：関数のテスト 1. 以下に示すように、動作を編集し、キャッシュポリシーとして [CachingDisabled] を選択します。これは、重み付けに従って両方の VPC オリジンにトラフィックが分散されていることを確認するため、意図的にキャッシュを無効にするための設定です。 図20. キャッシュポリシーで [CachingDisabled] を選択 2. 以下に示すように、CloudFront ドメインに対して複数回リクエストを実行し、両方の VPC オリジンにトラフィックが分散されていることを確認します。 $ echo ""; for i in `seq 1 5`; do echo "Request [$i]"; curl &lt;your-distribution-id&gt;.cloudfront.net; echo ""; echo ""; done Request [1] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [2] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [3] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [4] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [5] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; 図21. CloudFrontドメインへの curl コマンド 3. Amazon CloudFront コンソールを開き、 [Functions] と [KeyValueStores] タブを選択します。KeyValueStore を選択し、 [Key value pairs] セクションで [Edit] をクリックします。以下に示すように、VPC オリジンの重み値を変更し、 [Save changes] をクリックします。 図22. KeyValueStore コンソールでの重み値の変更 4. 以下に示すように、CloudFront ドメインに対して再度複数回リクエストを実行し、変更が反映されていることを確認します。 $ echo ""; for i in `seq 1 5`; do echo "Request [$i]"; curl &lt;your-distribution-id&gt;.cloudfront.net; echo ""; echo ""; done Request [1] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [2] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [3] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [4] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [5] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-west-1 VPC origin&lt;/h1&gt; &lt;/html&gt; 図23 . us-east-1 の重みを 0、us-west-1 の重みを 100 に設定した場合の CloudFront ドメインへの curl コマンド 5. Amazon EC2 コンソールを開き、VPC オリジンとして設定されている us-west-1 の ALB リスナー Default action として [Returned fixed response] を選択し、 Response code を 500 エラーに設定 図24. Amazon EC2 コンソールで ALB リスナーの Default action を変更 6. 以下に示すように、CloudFront ドメインに対して再度複数回リクエストを実行し、セカンダリーの us-east-1 にフェイルオーバしていることを確認します。 $ echo ""; for i in `seq 1 5`; do echo "Request [$i]"; curl &lt;your-distribution-id&gt;.cloudfront.net; echo ""; echo ""; done Request [1] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [2] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [3] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [4] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; Request [5] &lt;!DOCTYPE html&gt; &lt;html&gt; &lt;h1&gt;index.html delivered from us-east-1 VPC origin&lt;/h1&gt; &lt;/html&gt; 図25. us-west-1 の ALB リスナーが 500 エラーを返す設定をした状態の CloudFront ドメインへの curl コマンド まとめ セキュリティと可用性という重要な要件に基づき、このソリューションでは CloudFront VPC オリジンと CloudFront Functions を効果的に活用してこれらの要件を達成する方法を示しました。 このソリューションは非常に柔軟性が高く、ユーザーセッションの維持、ユーザーの位置に基づくパフォーマンスの最適化、特定のアプリケーション要件への対応など、さまざまなニーズに応じてトラフィックルーティングをカスタマイズできます。この柔軟性により、セキュリティと可用性を維持しながら、幅広いビジネスニーズに対応することが可能です。 このブログが、重要なアプリケーションのための強固なソリューションの構築に役立ち、堅牢なセキュリティ制御とサービスの継続的な可用性を確保しながら、ビジネスを成長させる一助となれば幸いです。 このブログの著者 針谷 浩紀 (Hiroki Harigai) Technical Account Manager

株式会社リクルートは、日本国内で HR・販促事業を行う事業会社です。リクルートでは、満足度No1(*1)を誇る飲食店予約・グルメ情報サイト『ホットペッパーグルメ』を運営しています。 『ホットペッパーグルメ』では、ユーザーが飲食店を検索する際の「0件ヒット」問題を解決するため、 Amazon OpenSearch Service （以下、OpenSearch Service）を採用し、Hybrid Search 機能を実現しました。約6ヶ月の取り組みにより、検索における0件ヒットを90%削減し、検索経由の予約数を10%向上させることに成功しています。 本ブログでは、『ホットペッパーグルメ』における検索改善の取り組みについて、チャレンジから導入効果までをご紹介します。 課題 『ホットペッパーグルメ』では、ユーザーが飲食店を探そうと検索しても、検索結果が0件になるケースがありました。行きたいお店があるのに見つけられず、ユーザーと飲食店のマッチングの機会を逃してしまう状況です。これはユーザー体験の低下だけでなく、検索から予約への転換機会の損失にもつながる重要なビジネス課題でした。 0件ヒットが発生する背景として従来の検索技術である Lexical Search には限界があり、ユーザーの意図を正しく理解できないケースがありました。 Lexical Search について : Lexical Search（字句検索）は、入力されたキーワードと完全に一致する文字列を検索する手法です。しかし入力ミスに弱いという課題がありました。ユーザーが「寿司」と入力しようとして「寿し」や「すそ」と入力してしまうと、検索結果を取得できません。また、日本語はスペースで単語を区切らない言語のため、セグメンテーションエラーが発生しやすいという日本語特有の課題もありました。 Vector Search の限界 : Vector Search（ベクトル検索）は、テキストを数値ベクトルに変換し、意味的な類似度で検索する手法です。タイポや言い換えに強いという特徴がありますが、固有名詞の検索で精度が低下するという課題がありました。店舗名のような固有名詞を検索する際、意味的に近い別の店舗が上位に表示されてしまいます。また、位置情報などのノイズにより、検索意図とは異なる結果が返される意味的なずれも発生していました。 検索手法 Lexical Search Vector Search 完全一致キーワード ○ × タイポ耐性 × ○ 言い換え対応 × ○ 固有名詞の精度 ○ × 日本語セグメンテーション × ○ 一般的に、ユーザーは検索結果の上位に高い関心があるため(*2)、 特にTop-1の検索結果を改善する方針 としました。 OpenSearch Service を活用した Hybrid Search の実現 これらの課題を解決するため、『ホットペッパーグルメ』では Lexical Search と Vector Search を組み合わせた Hybrid Search を採用しました。またそれを支える基盤として、OpenSearch Service を採用しました。 OpenSearch Service を選定した最大の理由は、Full-text Search と Vector Search を単一のサービスで実現できる Hybrid Search 機能の統合です。また、フルマネージド型サービスとしてインフラ管理の負荷を軽減できる開発・運用の容易さも重要な選定ポイントでした。さらに、OpenSearch Ingestion による Managed ETL や言語別テキスト解析プラグインなど AWS がサポートするプラグインが充実しており、豊富な周辺機能を活用できます。Blue/Green デプロイによる無停止でのスケーリングも、運用の安心感を確保する上で大きなメリットでした。 アーキテクチャと実装 Two-tower Model Architecture 『ホットペッパーグルメ』では、検索クエリと店舗情報をそれぞれ別のエンコーダーで処理する Two-tower Model Architecture を採用しました。 Two-tower Model は、Query Encoder と Document Encoder という2つの独立したエンコーダーで構成されています。Query Encoder はユーザーが入力した検索クエリ（例：「東京 寿司」）をベクトルに変換します。一方、Document Encoder は店舗情報をベクトルに変換します。店舗情報には、店舗名、住所、メニュー、説明文、キャッチコピー、レビューなど、検索に関連する情報が含まれます。埋め込みのスコープについても検証を行いました。店舗名や住所といった基本情報のみを使用するパターンと、メニューや説明文、キャッチコピーといったコンテンツフィールドを含めるパターンを比較し、検索精度への影響を評価しています。 モデルの学習には対照学習を採用しました。学習データとして、ユーザーの検索ログと LLM で生成した合成ペアを組み合わせて使用しています。ユーザーログからは実際の検索行動に基づくクエリと店舗のペアを抽出し、LLM 生成の合成ペアにより学習データのカバレッジを拡大しました。ベースモデルには日本語 BERT を採用し、『ホットペッパーグルメ』のドメインに特化したファインチューニングを実施しています。汎用的な埋め込みモデルと比較して、店舗名のようなドメイン固有の用語に対する検索精度が向上しました。埋め込みの次元数は512次元を採用しています。 日本語テキストの形態素解析には Sudachi を使用し、split_mode: A（最小単位での分割）を設定しています。これにより、日本語特有の複合語や固有名詞を適切にトークン化し、検索精度の向上に寄与しています。 導入プロセス Built-in Hybrid Search（第1フェーズ） 最初のステップとして、AOS の標準機能である Built-in Hybrid Search を導入しました。Built-in Hybrid Search は実装が容易であり、検索基盤の構築よりもモデル改善に集中できるというメリットがありました。 Built-in Hybrid Search では、OpenSearch が Lexical と Vector の検索結果を取得し、それぞれのスコアを正規化した後、単一のスコアにマージしてから Reranking を行います。この仕組みにより、短期間で Hybrid Search を導入し、効果を検証することができました。 一方で、運用を通じて課題も見えてきました。一度スコアがマージされると、スコアの差異が何に起因するのかを把握できなくなります。Lexical Score が高く Vector Score が低い場合、それがタイポによるものなのか、言い換えによるものなのか、あるいはレアな固有名詞によるものなのか、判断できません。どちらのシグナルを重視すべきかは検索意図に依存するため、固定のマージ重みでは対応しきれないケースがありました。この学びから、Reranker には統合されたスコアではなく、Lexical Score と Vector Score を個別に渡す必要があるという結論に至りました。 Custom Hybrid Search（第2フェーズ） Built-in Hybrid Search の課題を解決するため、Custom Hybrid Search を開発しました。 Custom Hybrid Search では、Lexical Score と Vector Score を別々に保持し、マージ前の個別スコアを Reranker に渡すことで、より精緻なランキングが可能になりました。また、ユーザーログや検索意図などの追加シグナルを Reranking に活用しています。スコアの統合には LightGBM による適応的なスコア統合とランキングを採用し、機械学習モデルによる動的なスコア統合を実現しています。アーキテクチャは Planner → Executor → Merger &amp; Reranker の構成となっており、検索意図に応じた柔軟なランキングを実現しています。Custom Hybrid Search の導入により、Top-1 検索精度が最大2倍改善しました。 段階的なリリース戦略 新しい検索システムの導入にあたり、A/B Test Router を用いたトラフィック制御を実施しました。当初は新規システムに10%、既存システムに90%のトラフィックを振り分け、この比率を段階的に調整しながら A/B テストにより効果を検証しました。A slot / B slot による並行検証を行い、新システムの安定性と効果を確認した上で、トラフィック比率を徐々に増加させていきました。 成果 ビジネス成果 : Custom Hybrid Search を本番環境に導入した結果、検索経由の予約数が10%改善し、0件ヒット検索が90%削減されました。これらの改善により、ユーザーと飲食店のマッチング機会が大幅に増加し、サービス全体の価値向上につながっています。 技術的成果 : 運用面でも多くのメリットが得られました。Blue/Green デプロイによる無停止でのスケーリングで運用負荷が軽減され、Plugins や OpenSearch Ingestion を活用することでランキングモデルの改善サイクルを加速できています。フルマネージド型サービスとしてインフラ管理の負荷が軽減されたことで、運用の安心感も確保できました。 まとめ 本ブログでは、『ホットペッパーグルメ』における OpenSearch Service で実現された Hybrid Search を活用した検索改善の取り組みをご紹介しました。 Lexical Search と Vector Search を組み合わせた Hybrid Search により、それぞれの検索手法の強みを活かしながら弱点を補完し、0件ヒット問題を大幅に改善することができました。また、Built-in Hybrid Search から Custom Hybrid Search への段階的な進化により、Top-1 検索精度を最大2倍改善し、検索経由の予約数10%向上という成果を達成しています。 OpenSearch Service の採用により、Lexical Search と Vector Search を組み合わせた Custom Hybrid Search の構築、開発・運用の容易さ、Blue/Green Deployment による安定した運用を実現できました。 こうした検索基盤の進化は、新たなユーザー体験の創出にもつながっています。2026年1月22日にリリースした 「席押さえ」機能 は、現在地周辺のお店をマップから探し、「今すぐ席を押さえる」ボタンをタップするだけで、予約なしで席を確保できるアプリ限定機能です。リアルタイムな「空席情報」と「位置情報」を地図 UI 上でマッチングするこの検索体験も、OpenSearch Service で実現しています。 Reference (*1)2025年6月時点　株式会社東京商工リサーチ調べ (*2) Google検索のClick Trough Rateは、Top1が27.6% backlinko 社調べ AWS re:Invent 2025 – Build Advanced Search with Vector, Hybrid, and AI Techniques (ANT314) Amazon OpenSearch Service BlackBelt 『ホットペッパーグルメ』「席押さえ」機能を全国で提供開始

新年あけましておめでとうございます。ソリューションアーキテクトの konippi です。 Kiro CLI は、2025 年 11 月から 12 月にかけて、v1.21.0・v1.22.0・v1.23.0 と立て続けにアップデートがリリースされました。Web 検索機能、コードインテリジェンス、サブエージェント、Plan エージェントなど、開発体験を大きく向上させる機能が追加されています。Kiro についてまだご存知でない方は「 Kiroweeeeeeek in Japan 開催のお知らせ 」を読んでいただけますと幸いです。また、Kiro のアップデートは Changelog よりご確認ください。 本記事では、これら 3 つのバージョンで追加された主要機能をまとめて紹介します。 v1.21.0 Web 検索・取得機能 Kiro CLI がインターネットからリアルタイムで情報を取得できるようになりました。最新のライブラリバージョン、ドキュメント、技術的な問題の解決策などを、ブラウザに切り替えることなく開発ワークフロー内で直接検索できます。 主な用途 最新のライブラリドキュメントの参照 技術的な問題の解決策の検索 API の最新仕様の確認 使い方 # エージェントが自動的に Web 検索を実行 &gt; React 19 の新機能について調べて教えてください Web 検索機能により、開発中に必要な情報をその場で取得でき、開発フローが中断されることがなくなります。 v1.22.0 コードインテリジェンス機能 v1.22.0 で追加された機能の 1 つは、Language Server Protocol (LSP) 統合による強力なコードインテリジェンス機能です。Kiro IDE と同等のコード理解能力がターミナルで利用できるようになりました。 組み込み機能（セットアップ不要） インストール直後から以下の機能が利用可能です: 対応言語: Bash, C, C++, C#, Elixir, Go, Java, JavaScript, Kotlin, Lua, PHP, Python, Ruby, Rust, Scala, Swift, TSX, TypeScript 主な機能: シンボル検索 : コードベース全体から関数、クラス、変数を検索 定義へのジャンプ : シンボルの定義箇所へ即座に移動 パターン検索 : AST ベースの構造的コード検索 パターン書き換え : AST パターンを使った自動コード変換 コードベース概要 : プロジェクト構造の即座の把握 # コードベース全体の概要を取得 &gt; /code overview # より簡潔な出力 &gt; /code overview --silent LSP 統合（オプション） さらに高度な機能が必要な場合は、LSP サーバーを統合できます: # プロジェクトルートで初期化 &gt; /code init これにより、参照検索、リネームリファクタリング、診断情報、コード補完などの機能が追加されます。 自然言語でのクエリ例: &gt; UserRepository クラスを見つけて &gt; s3Client で使えるメソッドは? LSP サーバーは自動的に検出・起動され、ワークスペースごとに .kiro/settings/lsp.json で設定が管理されます。 対応言語と Language Server 言語 拡張子 Language Server インストールコマンド TypeScript/JavaScript .ts, .js, .tsx, .jsx typescript-language-server npm install -g typescript-language-server typescript Rust .rs rust-analyzer rustup component add rust-analyzer Python .py pyright npm install -g pyright または pip install pyright Go .go gopls go install golang.org/x/tools/gopls@latest Java .java jdtls brew install jdtls (macOS) Ruby .rb solargraph gem install solargraph C/C++ .c, .cpp, .h, .hpp clangd brew install llvm (macOS) または apt install clangd (Linux) カスタム Language Server の追加 上記以外の言語を使用する場合、 .kiro/settings/lsp.json を編集してカスタム Language Server を追加できます: { "languages": { "mylang": { "name": "my-language-server", "command": "my-lsp-binary", "args": ["--stdio"], "file_extensions": ["mylang", "ml"], "project_patterns": ["mylang.config"], "exclude_patterns": ["/build/"], "multi_workspace": false, "initialization_options": { "custom": "options" }, "request_timeout_secs": 60 } } } 編集後、Kiro CLI を再起動して設定を反映してください。 ※ コードインテリジェンス機能はワークスペース単位で設定されます。各プロジェクトで独立して管理されるため、プロジェクトごとに /code init を実行する必要があります。 Knowledge Management 機能 Knowledge Management 機能により、プロジェクト固有のドキュメントやコードベースを永続的な知識ベースとして管理できるようになりました。この機能は Experimental 機能であり、使用前に有効化が必要です。 2つのインデックスタイプ: Fast (Lexical – BM25) : 高速なキーワードベース検索。ログファイルや設定ファイルに最適 Best (Semantic – all-minilm-l6-v2) : 意味を理解するセマンティック検索。ドキュメントや研究論文に最適 基本的な使い方 # 機能を有効化 $ kiro-cli settings chat.enableKnowledge true # ディレクトリをインデックスに追加 $ /knowledge add --name "project-docs" --path /path/to/documentation # セマンティック検索を使用 $ /knowledge add --name "api-docs" --path /path/to/docs --index-type Best # パターンフィルタリング &gt; /knowledge add --name "rust-code" --path /path/to/project \ --include "*.rs" --exclude "target/*" # ナレッジベースを確認 &gt; /knowledge show エージェント別の独立した知識ベース 各エージェントは独自の知識ベースを持ち、コンテキストの混在を防ぎます: # デフォルトエージェントで知識を追加 &gt; /knowledge add /path/to/docs # カスタムエージェントに切り替え &gt; kiro-cli chat --agent my-custom-agent # カスタムエージェント専用の知識ベースを作成 &gt; /knowledge add /path/to/agent/docs 知識ベースはセッション間で永続化され、自然言語クエリで検索できます。 v1.23.0 サブエージェント機能 複雑なタスクを専門的なサブエージェントに委譲できる機能が追加されました。サブエージェントは独自のコンテキストを持ち、並列実行が可能です。 主な特徴 自律実行 : 独自のコンテキストで独立して実行 リアルタイム進捗追跡 : タスク実行中の状態をリアルタイムで確認 並列タスク実行 : 複数のサブエージェントを同時実行 カスタムエージェント設定のサポート : 専門化されたエージェントを利用可能 コアツールへのアクセス : ファイル読み書き、シェルコマンド、MCP ツールの使用 結果の自動集約 : 完了時に結果をメインエージェントに自動返却 使用例 # デフォルトのサブエージェントを使用 &gt; 複数のデータソースを並列で調査して # カスタムエージェントをサブエージェントとして使用 &gt; 商品アイテムの一覧を返す API エンドポイントを backend エージェントで、 商品アイテム一覧ページの UI コンポーネントを frontend エージェントで実装して カスタムエージェントを使用することで、フロントエンドとバックエンドの同時開発など、より高度なワークフローを実現できます。 ※ 既存のエージェント設定でツールを制限している場合は、 subagent ツールを許可リストに追加する必要があります。 Plan エージェント機能 アイデアを構造化された実装計画に変換する専用のビルトインエージェントが追加されました。要件収集、リサーチを通じて、実装前に詳細なタスク分解を作成します。 アクセス方法 キーボードショートカット: Shift + Tab キー（Plan モードと実行モードを切り替え） スラッシュコマンド: /plan プロンプトと同時に起動: /plan 商品一覧を取得する API エンドポイントを実装したい ワークフロー 要件収集 : 構造化された質問でアイデアを洗練 リサーチと分析 : コードインテリジェンス、grep、glob ツールを使用してコードベースを探索 実装計画の作成 : 明確な目標とデモ説明を含む詳細なタスク分解を作成 計画の承認と引き継ぎ : 承認された計画を実行エージェントに転送 各タスクに含まれる情報: Problem Statement (問題定義) : 何を作るのか、解決すべき課題 Requirements (要件) : 実装すべき機能と制約 Background (背景) : 技術的な意思決定の理由と前提知識 Proposed Solution (提案する解決策) : 実装アプローチの全体的な戦略 Task Breakdown (タスク分解) : 目標、実装ガイダンス、Demo Plan エージェントは読み取り専用モードで動作し、ファイルを変更せずに計画に集中します。コードベース探索、Language Server、Grep / Glob ツール、Web 検索は利用可能ですが、ファイル書き込みやコマンド実行、MCP ツールは使用できません。 Grep / Glob ツール 高速なファイル検索のための2つの新しいビルトインツールが追加されました。 Grep ツール : 正規表現を使用した高速コンテンツ検索。bash の grep 、 rg 、 ag コマンドの代替として使用 Glob ツール : Glob パターンを使用した高速ファイル発見。bash の find コマンドの代替として使用 両ツールは .gitignore を自動的に尊重し、カレントディレクトリでデフォルトで信頼されます。 使用例 # エージェントが自動的に使用 &gt; すべての Rust ファイルで 'async fn' を検索して &gt; src ディレクトリ内の全ての .ts ファイルを見つけて shell ツールとの違い: 項目 Grep / Glob ツール shell ツール .gitignore 自動的に尊重 考慮しない 速度 高速 標準 カレントディレクトリ デフォルトで信頼 デフォルトで確認が必要 エージェント設定で allowedPaths と deniedPaths を設定してアクセス範囲を制御できます。 マルチセッションサポート 複数のチャットセッションを管理できるインタラクティブなセッションピッカーが追加されました。セッションは起動したディレクトリごとに保存され、会話のターンごとに自動保存されます。 コマンドラインからの操作 # セッションピッカーを開く $ kiro-cli chat --resume-picker # 最新のセッションを再開 $ kiro-cli chat --resume # または -r # セッション一覧を表示 $ kiro-cli chat --list-sessions # または -l # セッションを削除 $ kiro-cli chat --delete-session &lt;SESSION_ID&gt; # または -d チャットセッション内からの操作 # セッションピッカーを開く &gt; /chat resume # セッションをファイルに保存 &gt; /chat save &lt;FILE_PATH&gt; # ファイルからセッションを読み込む（.json 拡張子は省略可能） &gt; /chat load &lt;FILE_PATH&gt; セッションピッカーには、セッション名、最終アクティビティ、メッセージプレビューが表示されます。 MCP Registry サポート MCP レジストリサポートにより、組織レベルでの MCP ツールのガバナンス機能が追加されました。管理者は利用可能な MCP ツールを管理・制御でき、チーム全体での一貫性とセキュリティを確保できます。 まとめ Kiro CLI v1.21.0 から v1.23.0 にかけて、以下の主要機能が追加されました: v1.21.0 : Web 検索・取得機能によるリアルタイム情報アクセス v1.22.0 : コードインテリジェンス機能 (LSP 統合によるさらに高度なコード操作) Knowledge Management 機能による永続的な知識ベース管理 (Experimental 機能) v1.23.0 : サブエージェントによる並列タスク実行 Plan エージェントによる構造化された実装計画 Grep / Glob ツールによる高速ファイル検索 マルチセッションサポート MCP Registry によるガバナンス機能 これらのアップデートにより、Kiro CLI はターミナル上での AI 駆動開発体験をさらに強化し、より複雑なタスクを効率的に処理できるようになりました。 まだ Kiro CLI を試していない方は、 公式サイト からダウンロードできるのでぜひ試してみてください。また、 Kiro のドキュメント を参照し、ぜひたくさんの機能を触ってみてください！ 著者 小西 杏典 (Kyosuke Konishi) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2025 年に新卒入社した 1 年目のソリューションアーキテクト konippi です。Amazon Q Developer CLI をはじめ、いろいろな OSS に Contribution することが好きです。 X : https://x.com/_konippi LinkedIn : https://www.linkedin.com/in/kyosuke-konishi GitHub : https://github.com/konippi

はじめに 「AWS を使ってみたいけれど、学習方法がわからない」「実践的に AWS を学んでみたい」「AWS をより活用していきたい」といったお悩みがある方にぜひご参加いただきたいのが、AWS 初学者向けのイベント AWS JumpStart です。 AWS JumpStart は 2022 年の創設以来、参加者は年々増加しており、2025 年には 2500 人もの方が参加し、高い満足度をいただいています。 多くの方から「来年もぜひ開催してほしい」との声をいただき、2026 年も開催が決定しました！本記事では、イベントの内容や 2026 年の開催情報についてご紹介します。 AWS JumpStart とは AWS JumpStart は、新卒を含む AWS 初学者のエンジニアを対象とした、クラウドネイティブなテックリード人材を育成するための第一歩となる実践的な研修プログラムです。事前学習用動画と 2 日間の集中的なオンラインワークショップを通して、皆様の AWS に対する理解度を一気に引き上げることを目的としています。2 日間のプログラムを経て実践的なアーキテクチャ図を自分で設計できるようになることを目指します。 AWS について話を聞いたことはあるが使ったことはない EC2 等の単体サービスは触ったことあるが、システム全体の設計経験はない クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい といった方々には、短期間で一気にレベルアップできる内容となっているので、AWS を学びはじめるのにもってこいのプログラムとなっています。 AWS JumpStart 2026 のご案内 2026 年も全 4 回、各回 2 日間での開催を決定しました！ AWS JumpStart 2026（全てオンラインでの開催です） 開催日時（各回 2 日間：9 – 18 時） 2026年 5 月 11 日 (月) ~ 5 月 12 日 (火) 2026年 6 月 4 日 (木) ~ 6 月 5 日 (金) 2026年 9 月 17 日 (木) ~ 9 月 18 日 (金) 2026年 11月 12 日 (木) ~ 11 月 13 日 (金) 参加費 無料 参加登録ページ Coming Soon 2026 年の AWS JumpStart では、各回同じコンテンツで開催しますので、ご都合に合わせてご参加ください。 参加登録方法については、2026 年 2 月ごろを目処にお知らせいたします。 こちらのブログ内でもアップデートさせていただきますので今しばらくお待ちください。 AWS JumpStart 2026 も多くの方々のご参加を心よりお待ちしております！ 事前学習コンテンツ 「AWS を学習するのは初めてでイベントでついていけるか不安」という方もご安心ください。AWS JumpStartでは、初心者の方でも安心して参加できるよう、無料の事前学習コンテンツをご用意しています。 本イベントに申し込まれた方に別途ご連絡いたしますが、「早めに内容を確認したい」といった熱心なご意見をしばしばいただくため、以下に事前コンテンツの一例を掲載いたします。 (※ AWS Builder ID アカウントを作成する必要があります。) Cloud for Beginners モジュール 0 ~ 5 Web サービスの基礎について説明しています。 AWS Cloud Practitioner Essentials モジュール 1 ~ 6 AWS の基本的な概念を包括的に学習いただけます。 事前学習コンテンツをイベント参加前にご覧いただくことで当日の理解がより深まります。ぜひご活用ください。 2025 年開催の様子 AWS JumpStart 2025 は全 2 日、オンラインにて開催しました。イベントの内容や雰囲気をご紹介します。 受動的な講義だけではなく、能動的に手を動かしていただけるコンテンツを目指しています。 1 日目 1 日目は、講義形式の座学と実際に手を動かすハンズオンを交互に実施し、知識定着を図りました。 座学では、事前学習コンテンツの振り返りに加え、実際にAWSでシステムを構築する際のアーキテクチャのポイントを解説しました。 ハンズオンでは、仮想サーバーの起動から始まり、最終的に簡単なWebアプリを動かすまでを体験していただきました。2025 年からの新しい取り組みとして、ペアプログラミング形式で実施しています。「次に何をするべきか」「どうしてこの手順を実施するのか」などを話し合いながら進めることで、わからない部分を共有したり調べたりしながら理解を深めることができます。参加者の方からも「協力しながら学べたことで、より深く理解できた」と好評をいただいています。 2 日目 2 日目は、より実践的に AWS を学んでいただけるコンテンツをご用意しました。 コンテンツはクイズとアーキテクティング課題の二つです。 クイズでは、1 日目の内容から出題し、知識の定着を図るとともに、この後のアーキテクティング課題に取り組むにあたって必要な知識の確認を行います。 アーキテクティング課題では、参加者の皆さんには、とある企業の新入社員としてアーキテクチャを設計するというシナリオで、アーキテクチャを考えていただきました。要件に沿ってどのようなサービスを選定しアーキテクチャを設計するかを検討します。まず個人で検討を行い、その後グループワークで議論を深めていきます。グループワークでは AWS 社員がサポートしますので、AWS 初学者の方でも安心してアーキテクティングの考え方を実践的に学ぶことができます。最終的にはアーキテクチャ図を成果物として作成します。AWS JumpStart を通じて、実践的なアーキテクチャ図を理解し、自ら設計・作成できるようになることを目指しています。 AWS JumpStart 2025 では、以下のようなアーキテクチャ図が最終成果物として作成されました。 参加者からの感想 参加者の皆様から、さまざまなポジティブな感想をいただくことができました。 2日間を通して、AWSのサービスについて理解を深めることができました。それぞれのサービスの特徴や他のサービスとの関連についても、さらに学習を進めていきたいと思います。 アーキテクチャ図の作成を初めてやったが、講義内容や個人調査、グループディスカッションを通して徐々に形作ることができたのが面白かった。これからはAWSの構成図を見るのが楽しくなりそう。 実際にAWS環境に触れることが初めてで手探り状態ではありましたが、今まで漠然としていたサービスだったりのイメージが少し掴めたような気がします。 自分たちが疑問に思うであろう点をあらかじめ説明していただき、内容がスムーズに理解できました。このプログラムを通じて資格の取得にも励んでいきたい。 まとめ AWS JumpStart は、AWS 初学者のエンジニアを対象とした実践的な研修プログラムです。2026 年も全 4 回の開催が決定しており、事前学習コンテンツと 2 日間のオンラインワークショップを通じて、AWS の基礎から実践的なアーキテクチャ設計まで、短期間で集中的に学ぶことができます。 AWS を学び始めたい方、実践的なスキルを身につけたい方は、ぜひ AWS JumpStart 2026 にご参加ください。皆様のご参加を心よりお待ちしております！

本ブログは 2025 年 6 月 30 日に公開された AWS Blog “ AWS Certificate Manager now supports exporting public certificates ” を翻訳したものです。 AWS Certificate Manager (ACM) は、AWS サービスやオンプレミス、ハイブリッドアプリケーション向けのパブリックおよびプライベート TLS 証明書のプロビジョニング、管理、デプロイを簡素化するサービスです。多様なワークロードに対する ACM の柔軟性をさらに高めるため、AWS は強力な新機能である ACM エクスポート可能なパブリック証明書 を導入しました。この機能により、ACM からパブリック TLS 証明書と関連するプライベートキーをエクスポートできるようになります。エクスポートした証明書は、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、 Amazon Elastic Kubernetes Service (Amazon EKS) Pod、オンプレミスサーバー、または他のクラウドプロバイダーでホストされているサーバー上のワークロードを保護するために使用できます。この機能は、AWS アカウントで新しく作成されたパブリック証明書をサポートしています。 このブログでは、多様なインフラストラクチャ全体でエクスポート可能なパブリック証明書のエクスポートとデプロイを自動化する方法を紹介します。EC2 インスタンスやハイブリッド環境の仮想マシンなど、複数の宛先に証明書を自動的にデプロイするワークフローの作成手順を説明します。この自動化の仕組み、メリット、および開始するためのステップバイステップガイドを提供します。さらに、 Amazon EventBridge との統合により、証明書が発行または更新されたときに自動的に証明書のエクスポートをトリガーする方法についても説明します。これにより、異種環境全体での証明書のデプロイが効率化され、管理オーバーヘッドが大幅に削減されます。 背景: ACM と証明書管理 ACM は、TLS 証明書の購入、アップロード、更新の複雑さを取り除くマネージドサービスです。 Elastic Load Balancing (ELB) 、 Amazon CloudFront 、 Amazon API Gateway など、ACM と統合された AWS サービス向けに追加料金なしでパブリック証明書を提供します。ACM は、サードパーティのパブリック証明書のインポートや、 AWS Private Certificate Authority を通じたプライベート証明書の発行もサポートしています。本日 (2025 年 6 月 30 日) のリリース以前、ACM パブリック証明書は CloudFront などの ACM と統合された AWS サービス 向けに設計されており、それらのサービスにシームレスな TLS 暗号化を提供していました。サードパーティのコンテンツ配信ネットワーク (CDN) や EC2 インスタンスで TLS を終端するワークロードでは、お客様は通常、他のプロバイダーから証明書を取得するか、一元管理のために ACM にインポートしていました。お客様からは、これらのユースケースにも ACM を使用し、そのシンプルさとスケーラビリティをより幅広い環境に拡張したいというご要望をいただいていました。新しい ACM エクスポート可能なパブリック証明書機能は、このニーズに応えるものであり、一元管理と自動更新を維持しながら、ACM で管理されたパブリック証明書をカスタムワークロードで使用するためにエクスポートできるようになりました。 ACM を使用すると、パブリック証明書をリクエストし、ドメインの所有権が検証された後、Apache、NGINX、Microsoft IIS などの TLS を終端するソフトウェアで使用するために証明書をエクスポートできるようになりました。ACM は証明書の更新を処理するため、アプリケーションを中断させる可能性のある証明書の有効期限切れのリスクが軽減されます。 仕組み: ACM パブリック証明書の発行と更新 ACM エクスポート可能なパブリック証明書を使用するには、発行と更新のプロセスを理解し、証明書管理を自動化する方法を把握する必要があります。このセクションでは、これらのプロセスと自動化機能について説明します。これらは証明書のデプロイと維持に不可欠です。 ACM パブリック証明書の発行 ACM パブリック証明書の発行には、以下の手順が含まれます。 証明書のリクエスト: ACM の AWS マネジメントコンソール、または AWS コマンドラインインターフェイス (AWS CLI) や API で、保護したいドメイン名 (例: example.com や *.example.com) を指定して証明書をリクエストします ドメイン所有権の検証 : ACM では、ドメインの管理権限を証明する必要があります。ドメインが Amazon Route 53 でホストされている場合、ACM にドメインの所有権を検証するようリクエストできます。AWS 外でホストされているドメインの場合、DNS 検証 (CNAME レコードの追加) または E メール検証 (ドメイン連絡先に送信されたメールへの応答) を使用できます 証明書の発行: ドメインの所有権が検証されると、ACM は公開鍵、プライベートキー、証明書チェーンを含む証明書を発行します 統合された AWS サービスへの証明書の関連付け: 統合された AWS サービスに証明書を関連付ける方法については、 ACM と統合されたサービス を参照してください 証明書のエクスポート: 新機能により、ACM コンソール、AWS CLI、または API を使用して、ACM と統合されていないサーバーで使用するために パブリック証明書 、プライベートキー、証明書チェーンをエクスポートできるようになりました アプリケーションへのバインド: エクスポートした証明書をサーバー (例: Apache や NGINX) にインストールして、TLS 終端を有効にします この新機能のリリースにより、ACM で作成したパブリック証明書をエクスポートできるようになりました。エクスポートの可否は証明書の作成時に指定します。 エクスポート可能なパブリック証明書を作成するには、ACM コンソールを使用して新しいパブリック証明書を作成します。開始するには、 ACM コンソール で [証明書をリクエスト] を選択し、[パブリック証明書をリクエスト] ページの [エクスポートを許可] で [エクスポートを有効にする] を選択します。[エクスポートを無効にする] を選択すると、この証明書のプライベートキーは ACM からのエクスポートが許可されなくなり、証明書の発行後に変更することはできません。 図 1: パブリック証明書をリクエストしてエクスポートを有効化 [エクスポートを有効にする] オプションを選択して証明書を作成し、ドメインの所有権の検証を完了したら、図 2 のようにエクスポートプロセスに進むことができます。証明書をエクスポートするには、証明書のリストから証明書を選択し、[その他のアクション] を選択して、[エクスポート] を選択します。 図 2: 証明書のエクスポート ACM パブリック証明書の更新 ACM は証明書の更新プロセスを自動化します。このプロセスには以下が含まれます。 更新の開始: ACM は証明書の有効期限の 60 日前に自動的に更新プロセスを開始します ドメインの再検証: ACM は初回発行時と同じ方法 (DNS または E メール) を使用してドメインの所有権を再検証します 証明書の更新: 再検証が成功すると、ACM は同じ Amazon リソースネーム (ARN) で有効期限が更新された新しい証明書を発行します ACM で証明書が更新されると、サービスは自動的に EventBridge イベントを送信し、新しい証明書が利用可能になったことを通知します。更新が失敗した場合、ACM は AWS Health Dashboard と EventBridge の両方に通知を送信します。これらの証明書イベントに関する情報を受け取るには、特定の証明書関連イベントを監視する EventBridge ルールを作成します。これらのルールを設定して Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信することで、関係者が証明書のステータスに関するタイムリーな更新を受け取ることができます 新しい EventBridge スキーマフィールド: ACM 証明書の更新が成功すると、 ACM Certificate Available イベントに exportable フィールドが含まれるようになりました。このフィールドは、パブリック証明書がエクスポート可能かどうかを TRUE|FALSE で示します。 { "version": "0", "id": "id", "detail-type": "ACM Certificate Available", "source": "aws.acm", "account": "account", "time": "2019-12-22T18:43:48Z", "region": "region", "resources": [ "arn:aws:acm:region:account:certificate/certificate_ID" ], "detail": { "Action" : "ISSUANCE" | "RENEWAL" | "IMPORT" | "REIMPORT", "CertificateType" : "AMAZON_ISSUED" | "PRIVATE" | "IMPORTED", "CommonName": "example.com", "DomainValidationMethod" : "EMAIL" | "DNS", "CertificateCreatedDate" : "2019-12-22T18:43:48Z", "CertificateExpirationDate" : "2019-12-22T18:43:48Z", "DaysToExpiry" : 395, "InUse" : TRUE | FALSE, "Exported" : TRUE | FALSE, "Exportable" : TRUE | FALSE &lt;== New } } エクスポートと更新: 更新された証明書をエクスポートし、手動でサーバーに更新するか、EventBridge ルールによってトリガーされる AWS Systems Manager Automation ドキュメントなどの EventBridge ターゲットを使用して更新できます。詳細については、 Amazon EventBridge のイベントバスターゲット を参照してください EventBridge ルールを使用して特定のイベントを監視し、処理のために 1 つ以上の ターゲット (Amazon SNS トピック、 AWS Lambda 関数、その他の AWS サービスなど) に配信できます。たとえば、DNS 設定の問題によりドメイン検証が失敗した場合、ACM は ACM Certificate Renewal Action Required EventBridge イベント を生成します。SNS トピックをターゲットとする EventBridge ルールを作成することで、E メールアラートを受信するようサブスクライブし、必要な是正措置を講じることができます。 EventBridge を使用した更新済み証明書のデプロイの自動化 証明書の更新プロセスにより、手動介入なしで TLS 証明書の有効性を維持できますが、多様な環境全体で証明書を更新するには依然として手間がかかる場合があります。ACM が証明書を更新すると、EventBridge イベントが生成されます。このイベントに基づいてターゲットをトリガーする EventBridge ルールを設定できます。 通知の送信: イベントを Amazon SNS に配信して、管理者に E メールまたは SMS 通知を送信します 証明書デプロイの自動化: Lambda 関数または Systems Manager Automation ドキュメントをトリガーして、ACM API を使用して更新された証明書を取得し、サーバーに更新します 更新失敗の監視: ACM 証明書の更新失敗イベントに基づいてアラートを設定します。これらのイベントは通知チャネルに直接配信して、ドメイン検証エラーなどの問題を通知できます これを設定するには、ACM 更新イベントに一致する EventBridge ルールを作成し、ターゲット (SNS トピックや Lambda 関数など) を指定します。この自動化により手動介入が最小限に抑えられ、インフラストラクチャ全体でシームレスな証明書更新が実現します。 ソリューションの概要 このセクションでは、2 つのワークフローについて説明します。1 つ目は、既存の ACM パブリック証明書をエクスポートし、ターゲットの EC2 インスタンスまたは仮想マシンにインストールする自動化プロセスです。2 つ目は、ACM でパブリック証明書が自動更新されて利用可能になったときにトリガーされ、対象の EC2 インスタンスと仮想マシンの証明書を更新するワークフローです。このソリューションではターゲットシステムとして EC2 インスタンスと仮想マシンを使用していますが、同じ方法を適用して、さまざまな種類のシステム全体でパブリック証明書を大規模に更新できます。 前提条件 この自動化されたパブリック証明書のエクスポートと更新プロセスを拡張するには、以下を行います。 EC2 インスタンスの管理: Systems Manager による EC2 インスタンスの管理 の手順に従ってください オンプレミスや他のクラウド環境の仮想マシンの管理: Systems Manager によるハイブリッドおよびマルチクラウド環境のノード管理 の手順に従ってください 更新された証明書をデプロイする EC2 インスタンスと仮想マシンに TargetTagKey タグを追加します。自動化はこれらのタグを使用してターゲットインスタンスを識別します ExportCertificate API の操作には証明書のパスフレーズが必要です。セキュリティのベストプラクティスを維持するため、パスワードはプレーンテキストではなく、暗号化して安全に保存することをお勧めします。この実装では、 AWS Secrets Manager を使用してこれらの機密認証情報を安全に保存します。このソリューションでは、 Amazon DynamoDB を使用して証明書メタデータを維持します。これには、Secrets Manager に保存されている対応するシークレット名への参照が含まれます。セキュリティを強化するため、DynamoDB テーブルのデータは AWS Key Management Service (AWS KMS) を使用して保存時に自動的に暗号化されます ACM 証明書のエクスポート 図 3: ACM 証明書の発行とエクスポートのワークフロー 図 3 のワークフローは、既存の ACM パブリック証明書を API 駆動のプロセスでエクスポートし、対象のシステムにデプロイする自動化プロセスです。 プロセスは、ユーザーが API Gateway エンドポイントにリクエストを送信することから始まります。リクエストには、エクスポートする証明書を識別する CertificateArn 、証明書の識別用の CertName 、証明書をインストールするターゲット EC2 インスタンスを識別するための TargetTagKey と TargetTagValue などの必須パラメータが含まれます。以下は API Gateway に送信されるペイロードの例です。 { "CertificateArn": "arn:aws:acm:us-east-1:1234567890123:certificate/8106d6b2-f204-4354-8893-d49e311b3900", "CertName": "academe", "TargetTagKey": "env", "TargetTagValue": "dev" } リクエストを受信すると、API Gateway は複数のオーケストレーションされた状態を含む AWS Step Functions ワークフローをトリガーします 最初の状態では、 acm-Export という Lambda 関数が実行され、プライベートキー用のパスフレーズを生成します acm-Export Lambda 関数は、生成されたパスフレーズを Secrets Manager に安全に保存し、そのパスフレーズを使用して ACM 証明書をエクスポートします acm-Export 関数の完了後、Step Functions ワークフローは ssm-run Lambda 関数を呼び出します この関数は 2 つの操作を実行します。DynamoDB (インベントリ追跡システムとして機能) で証明書の存在を確認し、レコード管理を行います。既存の certificateARN が見つかった場合、関数は現在の CertExpiryDate と LastExportedDate のタイムスタンプ値でレコードを更新します。初めてエクスポートされる証明書の場合、一致するエントリが存在しなければ、Lambda 関数は DynamoDB に新しいレコードを作成します。この新しいレコードには、証明書の詳細と追跡情報を含むメタデータが記録されます。図 4 は、このメタデータがコンソールの DynamoDB テーブルエントリでどのように構造化されているかの例です 図 4: DynamoDB テーブル内の証明書メタデータ DynamoDB でのメタデータ検証ステップの後、Lambda 関数は Install-ACMCertificate というカスタム Systems Manager ドキュメントの実行も開始します。このドキュメントは、新しくエクスポートされたパブリック証明書を指定された EC2 インスタンスにインストールする処理を行います。同じ Systems Manager ドキュメントを使用して、オンプレミスサーバーへの証明書のインストールや更新も行うことができ、証明書デプロイの柔軟性を提供します Systems Manager ドキュメントの実行が成功すると、 TargetTagKey に一致する EC2 インスタンスに新しくエクスポートされたパブリック証明書がデプロイされます。デフォルトでは、Linux サーバーでは証明書は /etc/ssl/certs と /etc/ssl/private に保存されますが、これらのパスは Systems Manager ドキュメントでカスタマイズできます Systems Manager ドキュメントの実行が成功した後、Step Functions ワークフローは次の状態に進み、 Statuscheck という別の Lambda 関数をトリガーします。この関数は、先に開始された Systems Manager ドキュメントの実行ステータスを監視します。Step Functions ワークフローは、ターゲットの EC2 インスタンスへの証明書のインストールが成功したことを確認した後、実行を完了します ACM 証明書の更新とエクスポート 図 5: ACM 証明書と更新プロセス 証明書の有効期限が 60 日以内になると、ACM は自動的に更新プロセスを開始します。ACM が証明書の更新を正常に完了すると、以下の例のように EventBridge でイベント を生成します。 { "version": "0", "id": "id", "detail-type": "ACM Certificate Available", "source": "aws.acm", "account": "account", "time": "2019-12-22T18:43:48Z", "region": "region", "resources": [ "arn:aws:acm:region:account:certificate/certificate_ID" ], "detail": { "Action" : "RENEWAL", "CertificateType" : "AMAZON_ISSUED", "CommonName": "", "DomainValidationMethod" : "DNS", "CertificateCreatedDate" : "2025-05-22T18:43:48Z", "CertificateExpirationDate" : "2026-06-23T18:43:48Z", "DaysToExpiry" : 395, "InUse" : "TRUE", "Exported" : "TRUE", } } 図 5 のワークフローは、既存の ACM パブリック証明書を API 駆動のプロセスでエクスポートし、対象のシステムにデプロイする自動化システムです。 このソリューションでは、証明書の更新通知を監視し、それに応じて acm-renew Lambda 関数をトリガーする EventBridge ルールを使用します。関数は ACM イベントから証明書 ARN を受け取って実行を開始します。この ARN をルックアップキーとして使用し、DynamoDB テーブルをクエリして関連する証明書メタデータを取得します。このクエリから、 Certificate Name や、更新された証明書が必要なリソースを識別する TargetTag Key-Value ペアなど、重要な証明書の詳細を抽出します。これらの詳細は、その後の証明書デプロイプロセスに必要であり、更新が正しいシステムに適用されることを確認するのに役立ちます この情報はペイロードにフォーマットされ、Step Functions ワークフローをトリガーするために使用されます。この Step Functions ワークフローは、 ACM 証明書のエクスポートセクション で説明したのと同じプロセスに従います ステップ 3 から 9 は、 ACM 証明書のエクスポートセクション で説明したプロセスに従います。ステップ 9 が正常に完了すると、Step Functions ワークフローは実行を完了します。この時点で、更新されたパブリック証明書はターゲットの EC2 インスタンスに正常にインストールされ、自動化された証明書のエクスポートとインストールプロセスが完了します ソリューションのダウンロード、実行、証明書エクスポートの検証、AWS アカウントへのデプロイの詳細な手順は、 GitHub で入手できます。 料金と利用可能なリージョン ACM エクスポート可能なパブリック証明書は、AWS 商用リージョン、AWS GovCloud (US) リージョン、および中国リージョンで利用可能であり、前払いなしの従量課金制の料金モデルに従います。ELB、CloudFront、API Gateway などの ACM と統合された AWS サービス 向けのパブリック証明書は、引き続き追加料金なしで利用できます。詳細な料金については、 AWS Certificate Manager の料金 を参照してください。 まとめ ACM エクスポート可能なパブリック証明書機能により、統合されたマネージド証明書ソリューションで多様なワークロードを保護できるようになりました。EC2、コンテナ、オンプレミスサーバー、他のクラウドプロバイダー向けの証明書エクスポートが可能になったことで、ACM は一元管理、自動更新、コスト効率の高い料金を提供しながら、TLS 管理を簡素化します。ぜひ ACM コンソールでこの機能をお試しいただき、証明書管理ワークフローを効率化してください。 FAQ ACM はパブリック証明書の有効期間の短縮をサポートしますか? ACM は、今後数か月以内に CA/Browser Forum の TLS 証明書に関する要件に合わせて、パブリック証明書の有効期間を短縮する予定です。ACM は既に証明書の更新を自動的に処理し、新しい証明書がデプロイ可能になったときに通知する機能を提供しています。Amazon Trust Services (ATS) は、公的に信頼される TLS 証明書の標準が設定される CA/Browser Forum に積極的に参加しています。CA/Browser Forum の要件を満たすため、AWS は以下のスケジュールで TLS 証明書の最大有効期間を適用します。 2026 年 3 月 11 日まで、発行される TLS 証明書の最大有効期間は 398 日 2026 年 3 月 1 日以降、発行される TLS 証明書の最大有効期間は 200 日 2027 年 3 月 1 日以降、発行される TLS 証明書の最大有効期間は 100 日 2029 年 3 月 1 日以降、発行される TLS 証明書の最大有効期間は 47 日 有効期間が短い証明書の料金はどうなりますか? ACM のエクスポート可能なパブリック証明書をご利用の場合、証明書の最大有効期間の変更に伴うコスト増加についてご懸念があることを理解しています。AWS は ACM を通じて発行される証明書の公正な料金を維持することをお約束します。業界標準の変更に伴い、年間の証明書コストを現在の料金と同等に維持することを目指して、料金体系を適宜調整する予定です。料金変更が適用される前に、詳細をお知らせします。 このブログについてご質問がある場合は、 AWS サポート にお問い合わせください。 Pravin Nair Pravin は Data Protection and Privacy のシニアセキュリティソリューションアーキテクトです。お客様のビジネスニーズをサポートする安全でスケーラブルなソリューションの構築を支援しています。保存時および転送時の暗号化、インフラストラクチャセキュリティ、プライバシーに関するバックグラウンドを持っています。 Santosh Vallurupalli Santosh は AWS のシニアソリューションアーキテクトです。ネットワーキング、コンテナ、移行を専門としており、お客様のクラウド導入の過程を支援し、困難な課題に対するクラウドに特化したソリューションの構築を楽しんでいます。仕事以外では、旅行、F1 観戦、「The Office」を繰り返し視聴することが好きです。 Chandan Kundapur Chandan は AWS Certificate Manager (ACM) チームのプリンシパルテクニカルプロダクトマネージャーです。約 20 年のサイバーセキュリティ経験を持ち、AWS のお客様がパブリックおよびプライベート証明書でリソースとエンドポイントを識別し保護できるよう、ACM チームの製品戦略を推進することに情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは株式会社 Works Human Intelligence 様と Amazon Web Services Japan 合同会社が共同で執筆しました。 Works Human Intelligence (以下、WHI) は「人に真価を。」をコーポレートブランドに掲げ、日本の大手企業および公共・公益法人向け統合型人事システム COMPANY の開発・販売・サポートの他、HR 関連サービスの提供を行っています。WHI は人事部門が定型業務ではなく戦略的な業務に取り組めるよう尽力しており、今回は AWS の Generative AI Innovation Center (以下、GenAIIC) とともに取り組んだ AI Agent を活用したプロダクト構築から得た知見についてご紹介します。 背景 Overview 人事システムをご利用されるお客様は、組織変更や人事制度変更、社員情報の更新といった多くの場面で対応が必要となります。WHI では AI Agent を活用することで、担当部署の方々の業務負荷軽減、生産性向上に寄与できることを期待しています。実際に AI Agent を活用したプロダクトの構築に取り組んだところ、いくつかの悩みが生じました。WHI が課題解決に向けて取り組む中で、GenAIIC には新しい観点を追加し、良いものを作るためのサポートを期待していました。 今回のプロジェクトの対象は、担当部署の方の業務を支援する 2 つの AI Agent です。 1 つ目の AI Agent (以下、通勤手当エージェント) は引越しの際などに生じる通勤手当申請の承認に関するエージェントです。2 つ目の AI Agent (以下、ブラウザ操作エージェント) は、お客様に代わって COMPANY を操作するエージェントとなっています。 ここからは通勤手当エージェント、ブラウザ操作エージェントの順に、2 つのエージェントの課題と解決方法をお伝えします。 通勤手当エージェント 課題 Challenge 通勤手当エージェントは、通勤手当申請の承認という定型業務を支援するエージェントです。WHI では既に LangGraph と Amazon ECS、AWS Fargate を用いた PoC を進めていましたが、開発途中で Amazon Bedrock AgentCore がリリースされたため、移行を検討し始めました。 COMPANY とシームレスに統合する AI Agent の実現に向けての Amazon Bedrock AgentCore でのソリューション構築、および現行開発している AWS Fargate や Amazon Cognito を用いた認証認可の実装を含んだ統合的なマルチエージェント環境への移行を GenAIIC と共に実施したいと考えました。 解決策 Solution overview 通勤手当エージェントは LangGraph と Amazon ECS を利用して開発していましたが、全て同じ ECS タスクとして起動するモノリシックな構成になっていることに対して WHI も懸念がありました。そこで、サブエージェントは個別に Amazon Bedrock AgentCore Runtime で起動するように変更しました。マルチテナント対応が求められていたため、自分たちで構築できる自由度を求めて Amazon DynamoDB と Amazon Cognito を用いてテナント管理をすることとしました。 アーキテクチャ 通勤手当エージェントは Slack が呼び出しの起点となるため、呼び出されたタイミングで認証を行い、リクエストに対して適切な各サブエージェントが処理を行う仕組みとなっています。 結果 Results and Impact プロジェクトの途中で Amazon Bedrock AgentCore が GA したことで、本格的に活用できるようになりました。通勤手当エージェントは LangGraph を継続して利用していますが、サブエージェントは別の Runtime で起動するように変更を行いました。この対応により将来のサブエージェント拡充を容易にしています。今後はサブエージェントを束ねるスーパーバイザーエージェントを Strands Agents に変更することも検討しています。 また、今まではエージェントの状態を確認するために Langfuse をホストしていたため運用コストが発生していましたが、Amazon Bedrock AgentCore Observability に変更することで負荷が軽減されました。 ブラウザ操作エージェント 課題 Challenge ブラウザ操作エージェントは、ブラウザを使い、COMPANY にアクセスし、内容を確認した後、操作を行なってエビデンスを取得する処理を行います。構築は LangGraph と Playwright MCP で進めていました。ブラウザ操作のトークン数は、以下のアプローチによって、88% の削減効果が確認できていました。 エージェントループ (AI と Playwright MCP との会話履歴) から過去の不要になった部分を削除 Playwright MCP の戻り値からブラウザ操作に不要な部分を削除 TOOL 部分のプロンプトキャッシュの有効化 しかしながら、独自実装に依存していたため、Strands Agents への移行が困難といった課題を抱えていました。また、より一層トークンを削減する方法について検討していました。こうした中で GenAIIC と協働することとなりました。 解決策 Solution overview ブラウザ操作エージェントは Strands Agents を使い、いくつかのブラウザ操作ツールを試しながら、処理がうまくいくことを確認し、その後は利用するトークン数の削減に取り組みました。エージェントのワークフローは以下の 5 つのステップで構成されています。 操作テンプレート選択 : ユーザーの指示に基づき、ナレッジベースから最適な操作テンプレートを検索します。 操作マニュアル作成 : 取得したテンプレートのプレースホルダーを、別のナレッジベースから取得した情報で置換します。 ブラウザ操作 ( 現状確認 ): 作成したマニュアルに基づき、ブラウザを操作して現状の確認を行います。 変更案作成: 現状確認で得られた情報 (CSV など ) を基に、変更案を作成し、ユーザーに提示します。 変更実行 ( ブラウザ操作 ): ユーザーの承認後、変更案に基づき再度ブラウザを操作して変更を実行します。 基本的なワークフローを定めていますが、ユーザーのインプットに情報が足りない場合や、一部の作業のみ行うことなどもエージェントの自立的な判断で柔軟に対応できます。 アーキテクチャ ブラウザ操作エージェントから COMPANY へのアクセスには IP アドレス制限を行なっているため、VPC 内に Amazon Bedrock AgentCore Runtime を配置し、NAT ゲートウェイ経由で固定 IP アドレスでアクセスする構成としました。また、操作テンプレートや操作手順作成時の補助情報を格納するナレッジベース、短期的な情報を保存する S3 バケットも構築しました。 結果 Results and Impact ブラウザ操作エージェントは Strands Agents を利用して構築しました。ブラウザ操作ツールは browser-use、Playwright、fast playwright を試し、fast playwright が消費するトークン数が最も少ないことを確認しました。加えて、Bedrock のプロンプトキャッシュの有効化やシステムプロンプトの変更といった改善を WHI と GenAIIC で協力して行ったことで、一回の処理でかかる費用を最大 97% 削減することに成功しました。 主な改善施策は以下の通りです。 ユーザーメッセージも対象としたプロンプトキャッシュの活用 : Bedrock のプロンプトキャッシュ機能を有効化 (2,171 円 → 307 円 ) エージェントの行動最適化 : サブエージェントのプロンプトを改善し、不要な操作を削減 (307 円 → 154 円 ) モデルの変更 : モデルを Claude Sonnet 4.5 から Haiku 4.5 に変更 (154 円 → 56 円 ) これらの改善によりコストを最適化しつつ、複数の変更を連続して実行するシナリオや、指示が曖昧な場合にエージェントから人間に質問するシナリオなど、より複雑なタスクも成功させることができました。 まとめと今後 Conclusion and Next step WHI と GenAIIC が協力して開発を進めたことで、AI Agent の実行基盤を Amazon Bedrock AgentCore Runtime に移すことに成功し、Amazon Bedrock AgentCore Observability を活用して稼働状況を確認できるようになりました。 Amazon Bedrock AgentCore を利用することによって、マネージドサービスでログの確認も容易にできるようになり非常に開発が楽になった、また、ブラウザエージェントは Strands Agents にしたことで、柔軟に動作するエージェントが少ない実装で実現できたと WHI メンバーは語っています。現実には数多くの定型作業が存在するため、それらを支援する AI Agent を構築することは難しさを伴いますが、GenAIIC との協業により、ビジネスロジックの開発に集中できる状態に到達しています。 Amazon Bedrock AgentCore は実行基盤にあたる Runtime だけではなく、他の機能も備えているため、WHI では今後の活用を検討しています。また、AI Agent はモデルの変更によって挙動もコストも変わります。今回のプロジェクトを通じて、処理が実行可能であることまで確認ができたため、 今後も継続してモデルの検証を行いコスト最適化を実施する予定です。

2025 年の年末は、長い休憩を取って南半球の素晴らしい夏を楽しむことができました。休暇から戻り、私にとって 2026 年最初の記事を書いているのですが、この記事は AWS ニュースブログで私が書く最後の記事でもあります (これについては後ほど説明したいと思います)。 AWS コミュニティは、世界中で開催されているさまざまな AWS re:invent re:Caps で今年も好調なスタートを切っています。また、既に AWS Community Day イベント を開催しているコミュニティもあり、先週は AWS Community Day Tel Aviv 2026 が行われました。 2026 年 1 月 12 日週のリリース 2026 年 1 月 12 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Kiro CLI の最新機能 – Kiro CLI が、ウェブフェッチ URL のきめ細かな制御、カスタムエージェントのためのキーボードショートカット、強化された差分ビューなどを提供するようになりました。これらの機能強化により、許可リストまたはブロックリストを使用してエージェントがアクセスできる URL を制限したり、単一のセッションで複数の専門エージェントを使用するときのシームレスなエクスペリエンスを確保したりするなど、さまざまなアクションが可能になります。 AWS European Sovereign Cloud – 2023 年に発表された、新しい独立したクラウドインフラストラクチャを構築する計画 に続き、すべてのお客様に対する AWS European Sovereign Cloud の一般提供が発表されました。このクラウドでは、包括的な一連の AWS サービスを使用して、ヨーロッパのお客様の最も厳しい主権要件を満たす体制が整えられています。 Amazon EC2 X8i インスタンス – 以前に AWS re:Invent 2025 でプレビュー版としてリリース された、新しいメモリ最適化 Amazon Elastic Compute Cloud (Amazon EC2) X8i インスタンスの一般提供が先週発表されました。X8i インスタンスは、3.9 GHz の持続的なオールコアターボ周波数を備えたカスタム Intel Xeon 6 プロセッサを搭載しており、利用できるのは AWS 上のみです。これらの SAP 認定インスタンスは、クラウド内の同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 その他のアップデート これらのプロジェクト、ブログ記事、ニュース記事も目に留まりました。 5 core features in Amazon Quick Suite – AWS VP Agentic AI である Swami Sivasubramanian が、ほとんど何にでも Amazon Quick Suite を使用する方法について語ります。2025 年 10 月、業務上の質問にすばやく回答し、インサイトをアクションに変換する新しいエージェンティックチームメイトとして Amazon Quick Suite が発表されました。Amazon Quick Suite は、1 つのトピックに関して多角的な視点を提供するだけでなく、さまざまなトピックに関するリサーチにも役立つ、お気に入りの生産性向上ツールの 1 つになりました。 Deploy AI agents on Amazon Bedrock AgentCore using GitHub Actions – 2025 年、Amazon Bedrock AgentCore が発表されました。これは、Amazon Bedrock でホストされているか他の環境でホストされているかにかかわらず、さまざまなフレームワークやモデルで AI エージェントをシームレスに作成し、管理できるようにする柔軟なサービスです。GitHub Actions ワークフローを使用して、AgentCore Runtime で AI エージェントのデプロイを自動化する方法を学びましょう。このアプローチは、エンタープライズレベルのセキュリティ制御を備えたスケーラブルなソリューションを提供し、継続的インテグレーションとデリバリー (CI/CD) の完全な自動化を実現します。 近日開催予定の AWS イベント 1 月 28 日または 29 日 (タイムゾーンによって異なります) に行われる Best of AWS re:Invent に参加しましょう。この無料バーチャルイベントは、AWS re:Invent からの最もインパクトのある発表と、一番人気のセッションをお届けするイベントです。オープニングセッションでは、AWS VP 兼 Chief Evangelist の Jeff Barr がハイライトをご紹介します。 25 万 USD の賞金と AWS クレジットを獲得できる Global 10,000 AIdeas Competition への応募が締め切られる 1 月 21 日まであとわずかになりました (「AIdeas」の「I」は「Idea」の「I」で、「L」の小文字ではありません)。コードはまだ必要ないので、アイデアだけを提出してください。セミファイナリストに選ばれた場合は、 AWS 無料利用枠 の範囲内で Kiro を使用してアプリを構築することになります。賞金の獲得や、 AWS re:Invent 2026 で特集される可能性以外にも、次世代 AI ツールを実際に使用する経験を積み、世界中のイノベーターとつながることができます。 1 月の初めに、 コミュニティビルダープログラムの 2026 年の申し込みが開始されました 。申し込みは 1 月 21 日の午後 24 時 (太平洋標準時) までとなっています。このプログラムに参加する最後のチャンスをお見逃しなく。 こうした機会に興味がある場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学びましょう。 以上で、私がここ AWS で過ごした最も有意義な章の 1 つを締めくくりたいと思います。皆さんのために記事を書くことは、私にとって本当に素晴らしい経験でした。チームと私が全力を傾けて書いた記事を読むために時間を取ってくださった皆さんに感謝しています。ローンチチームとの緊密なコラボレーションと、皆さんからのフィードバックは、私が成長する糧となりました。サハラ以南のアフリカ (SSA) コミュニティは大きく成長しており、私はこのコミュニティに集中する時間を増やしたいと考えています。とは言うものの、AWS での仕事は続けていくので、お近くのイベントで皆さんとお会いできるのを楽しみにしています! 2026 年 1 月 26 日週の Weekly Roundup もお楽しみに! – Veliswa Boya 原文は こちら です。