Amazon Web Services ブログ

AWS Weekly Roundup: Amazon Connect Customer 向け Agentic CX Designer、EC2 AMI ウォーターマーク、MySQL 向けのオープンガバナンスなど (2026 年 6 月 29 日)

Micah Walter — Wed, 01 Jul 2026 07:26:37 +0000

AWS Summit が各地で開催されており、多忙な日々を過ごしています。私は New York City Summit において、「Building AI architectures with AWS Serverless」というワークショップを開催しました。そして、ビルダーたちが、エージェントとサーバーレスサービスを組み合わせて、わずか半日で実際の課題を解決していく様子を見るのは、とても楽しいものでした。6 月 29 日週は Washington, DC Summit に向かいます。このイベントは、常に公共部門におけるイノベーションにスポットライトを当てています。現地にいらっしゃる方は、ぜひお声がけください。

これらのイベントで私がよく受ける質問の 1 つは、「エンジニアリングの長いバックログの解消を待つことなく、チームはどのように AI を業務で活用できるのか」というものです。そして、今週最大のリリースは、まさにその問いに応えるものでした。Amazon Connect Customer は、ビジネスチームがノーコードで AI を活用したカスタマーエクスペリエンスを自ら設計するための方法を提供します。それでは、6 月 29 日週の AWS ニュースを見ていきましょう。

主なトピック

Amazon Connect Customer は、AI を活用したセルフサービスエクスペリエンスを設計およびデプロイするためのノーコードキャンバスである Agentic CX Designer (NLX) をプレビューとしてリリースしました。ビジネスチームは、エージェンティック AI と決定論的 AI を、ガバナンスの効いた単一のフローに統合した音声およびデジタルエクスペリエンスを構築してリリースできます。これにより、設計から、テスト、シミュレーション、そして本番対応のエクスペリエンスまでを、数か月間ではなく数週間で完了できるようになります。今回のリリースには、プレビュー版の Live Sync も含まれています。これは、顧客が話したり、入力したりするのに合わせて、ウェブやモバイルでのエクスペリエンスをリアルタイムで連動させる特許取得済みのテクノロジーです。発信者は、会話を中断することなく、フォームへの入力や適切な製品ページの表示を行うことができます。誰がカスタマーエクスペリエンスを設計するのかを、これがどのように変革するのかにを知るには、「business user is the new architect of customer experience」というブログ記事をお読みいただくとともに、Amazon Connect Customer ページにアクセスしてください。

6 月 22 日週のリリース

6 月 22 日週のリリースのうち、私が注目したリリースをいくつかご紹介します:

AWS Lambda MicroVMs – 各ユーザーまたはジョブ VM レベルの分離を提供する新しいサーバーレスコンピューティングプリミティブ。ほぼ瞬時の起動および再開速度に加えて、実行を一時停止し、最大 8 時間後に再開する機能も備えています。Firecracker を基盤として構築されており、仮想化インフラストラクチャの管理や、分離、速度、状態のトレードオフを強いられることなく、マルチテナントアプリケーション内でユーザーや AI が生成したコードを実行できるよう設計されています。
Amazon EC2 AMI ウォーターマーク – プライベート AMI にカスタム識別子を埋め込むことができます。この識別子は、コピー、リージョン、アカウント共有にわたって、派生するすべての AMI に自動的に引き継がれます。許可された AMI や宣言型ポリシーとウォーターマークを組み合わせることで、承認されたイメージに対してのみ起動するよう制限できます。これは、すべての AWS リージョンで追加コストなしでご利用いただけます。
AWS Outposts セルフサービスおよびライフサイクル管理 – コンソール、CLI、API から直接、セルフサービスの設定、見積り、注文、サブスクリプションの管理、更新、および廃止を追加します。新しい見積りツールは、数秒でリアルタイムのコスト見積りを生成し、お客様が注文を送信する前に、アカウントやリージョンレベルの制約を表示します。
Amazon MSK AI エージェントスキル – Kiro、Claude Code、Cursor などの AI コーディングアシスタントに、Amazon MSK の運用に関する専門的かつ最新のガイダンスを提供します。これは、トラブルシューティング、サイズ設定、設定、モニタリング、および外部 Kafka クラスターから MSK Express への移行をカバーします。かつては専門知識が必要だったタスクが、デベロッパーが自力で完了できるガイド付きのプロセスとなります。
Amazon OpenSearch Service の AI が支援する移行 – Migration Assistant にエージェントがガイドするエクスペリエンスが含まれるようになりました。これは、Kiro や Claude Code などのツールを利用して、セルフマネージド型の Apache Solr、Elasticsearch、または OpenSearch のデプロイを OpenSearch Serverless やマネージドクラスターに移行するのに役立ちます。また、Solr 向けに、ライブトラフィックキャプチャおよびリプレイのサポートも新たに追加されています。
Amazon GuardDuty の AI を活用した調査 (プレビュー) – 実際の脅威と無害なアクティビティを区別するのに役立つよう、ナレッジグラフや脅威インテリジェンスを使用し、直近 90 日間のコンテキストや関連アクティビティを調査して、検出結果とアカウントを自動的に分析します。各調査では、信頼度スコア、MITRE ATT&CK 分類、実用的なレコメンデーションを含む判定結果が数分で返されます。

AWS のお知らせに関する詳しいリストについては、「AWS の最新情報」ページをご覧ください。

その他の AWS ニュース

興味深いと思われる追加の記事やリソースをいくつかご紹介します:

MySQL 向けのオープンガバナンス – Oracle は、MySQL 向けのコミュニティガバナンスモデルを発表しました。これは、Oracle 以外の組織にもプロジェクトにおける明確な役割を与えるものです。これには、新たに設置される Steering Committee に Oracle 以外の組織向けの 4 つの席を設けることや、GitHub を一般公開することが含まれます。AWS も席を有しており、この取り組みを支持する理由や、MySQL を利用するすべてのユーザーのために、既にアップストリームへの修正を提供していることについて説明しています。
AWS 認定を最新の状態に保つ新しい方法 – 対象となる AWS 認定は、あらためて受験する代わりに、AWS Skill Builder において、厳選されたトレーニングとハンズオンラボを完了することで、有効期間をさらに 1 年間延長できるようになりました。このオプションは現在、一部の Associate および Professional 認定を対象にオープンベータ版として提供されており、年内には対象がさらに拡大される予定です。
2026 年応募者向け「All Builders Welcome Grant」完全ガイド – AWS Builder Center で公開されているコミュニティガイド。キャリア初期のビルダーを対象に、この助成金の申請方法を順を追って説明しています。これは、AWS re:Invent 2026 のフルカンファレンスパス、航空券、ホテル費用をカバーします。現在応募を受け付けており、締め切りは 7 月 14 日です。

AWS のブログ記事の詳細な一覧については、AWS ブログページをご確認ください。

他のビルダーと直接交流する機会をお求めですか? お近くの都市で開催される AWS Summits をチェックしたり、世界中のユーザーグループが主催する地元の AWS Community Day を探したり、AWS Builder Center でチュートリアル、コミュニティコンテンツ、スキルアップのための方法を探索したりしてみてください。

6 月 29 日週のニュースは以上です。7 月 6 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください!

– Micah

原文はこちらです。

ITbook 株式会社様のAWS 生成 AI 活用事例：Amazon Bedrock を活用し、要件文書から提案書を自動生成する仕組みを構築し、提案書のドラフト作成を十日から半日に短縮

尾形龍太郎 — Wed, 01 Jul 2026 03:29:47 +0000

本ブログは ITbook 株式会社様とAmazon Web Services Japan 合同会社が共同で執筆いたしました。

みなさん、こんにちは。AWS アカウントマネージャーの尾形龍太郎です。

公共調達の提案書づくりに携わったことがある方なら、調達仕様書と評価基準を何度も読み返し、必須項目の取りこぼしに神経をすり減らした経験があるのではないでしょうか。締め切り間際に「あの加点項目はどこに書いたのか」を探し回る時間も、その一つです。本ブログでは、自治体・国向けのコンサルティングを手がける ITbook 株式会社様が、Amazon Bedrock を活用した提案書作成支援システムを構築し、ドラフト作成にかかっていた約十日分の作業を半日にまで短縮した取り組みをご紹介します。生成 AI を「人の代わり」ではなく「人が考える時間を生み出す道具」として組み込んだ、コンサルティング会社の新しい働き方の事例です。

お客様の状況と課題

ITbook 株式会社様は、自治体・国の案件に対して提案書を提出し、案件を獲得していくコンサルティング事業を主軸とする企業です。提案活動の起点になるのが、公共機関から示される調達仕様書や評価基準書を読み解き、限られた期間内に提案書を仕上げる作業です。

この提案書作成は、コンサルタント一人ひとりの知見と経験が大きく活きる、専門性の高い業務です。一方で、案件数の増加に伴い、事前調査や構成の作り込みにかけられる時間を案件ごとに十分確保することが、組織共通のテーマになっていました。提案の評価を最大化するうえで、評価基準で求められる必須項目や加点項目を確実に押さえる精度を、組織全体で一段引き上げることの重要性が増していました。

とりわけ繁忙期には複数の案件が同時に進行し、提出期限までに構成を磨き込む時間の確保が大きな論点になっていました。過去の類似案件や関連資料を数十件単位で読み込む準備作業の負荷も大きく、コンサルタントが本来注力すべき提案の中身づくりに、より多くの時間を振り向けられる仕組みが求められていました。案件数が増えるほど効果が見込める、品質を保ちながら数をこなすための仕組みづくりが課題でした。

解決策の検討

ITbook 株式会社様がまず明確にしていたのは、「機械的にできる部分は AI に任せ、人は代替のきかない部分に集中する」という考え方でした。ITbook 株式会社様は、コンサルタントの強みは最新情報の反映や複数の知見の統合といった思考にあると考えました。その前段にあたる「調達仕様書を読み、必須項目を整理し、提案のドラフトを組む」工程をいかに短縮できるかが、解決したいテーマでした。

この課題に対し、当初は社内プロセスの整備で対処するか、生成 AI を活用するかが議論されました。検証を進める中で、評価基準と提案内容を突き合わせて構造化する作業は生成 AI が得意とする領域であり、十分な品質が見込めると判断したことから、Amazon Bedrock を採用する方向に至りました。AIMS（ISO/IEC 42001）を取得し AI ガバナンスを重視する同社にとって、データを学習に使わない形で基盤モデルを利用できる Amazon Bedrock は、自治体の機微な情報を扱う上でも安心して採用できる選択肢でした。

ソリューションの概要

構築したシステムは、社内で利用している提案書作成支援システムです。提案担当のコンサルタントや営業担当者が、公共機関向け提案の初期フェーズで利用します。

利用者はまず提案の概要を入力し、続いて提案依頼書・調達仕様書・評価基準書・提案書作成要領などの資料をアップロードします。システムはこれらの資料を生成 AI で読み解き、提案依頼書の概要（背景・課題）、提案に含めるべき提案項目、採点基準（必須・加点）、遵守すべき制約条件を抽出して画面に整理します。抽出結果は人が確認・編集できるようになっており、調整が必要な箇所はその場で編集できます。

図1：システム画面

図2：抽出した提案項目一覧

整理された情報をもとに、システムは提案書のアウトラインを生成します。これは目次ではなく、各章で何をどの目的で書くかを示した、生成 AI 向けの指示書です。利用者がアウトラインを確認・調整したうえで本文生成を実行すると、章ごと、あるいは全章の提案書ドラフトが生成されます。一連の流れには人が確認・修正を挟む Human-in-the-loop の設計が貫かれており、生成結果をそのまま使うのではなく、人が記載内容を確認・修正して仕上げていける構成になっています。

図3：生成した提案書のアウトライン

ソリューションの構成

システムは AWS 上で構築されており、提案書の生成エンジンとして Amazon Bedrock を中心に据えています。アップロードされた提案資料は Amazon S3 に保存され、提案書生成時に生成 AI へ直接渡されます。一方、過去の提案内容や都道府県のガイドラインといった参照知識は、これらの提案資料とは別にナレッジとして登録し、Amazon OpenSearch Service を用いた検索基盤を通じて本文生成時に参照します。利用者は、どのナレッジを使うか、いつの時点の資料を参照するかを選択でき、古くなった情報を除外する運用も行えます。

このシステムの技術的な要点は、提案書生成の処理を一つにまとめず、役割ごとに分割した点にあります。提案依頼書から、いきなり本文を生成するのではなく、まず「提案書を生成するために必要な情報の抽出」を行い、その結果をもとにアウトライン作成、本文生成へと段階を踏みます。本文生成では、Amazon Bedrock AgentCore Runtime と Amazon Bedrock AgentCore Gateway を用いたナレッジ検索ツールを組み合わせ、ディープリサーチのように必要な情報を追加で検索しながら本文を生成する、エージェント型の構成を採用しています。

図4：システム構成

処理を分けたことは、品質とコストの両立にもつながりました。提案依頼書の概要抽出や提案項目の抽出といった比較的単純な工程には軽量なモデルを割り当ててコストを抑え、最も思考力が求められる本文生成にコストを集中させる設計です。基盤モデルには Amazon Bedrock 上の Anthropic の AI モデル Claude を中心に用いて、用途に応じて軽量なモデルも使い分けています。ドキュメントの取り込みでは、抽出結果をマークダウン形式に整えることで後続処理の精度を高める工夫も取り入れました。

開発を通じて得られた学びは、「必要な情報さえ正しく抽出できれば、出力品質はある程度担保できる」という見立てでした。だからこそ、元データから必要な要素を取り出す工程を丁寧に設計しました。この部分は軽量なモデルでも実現できることを検証したうえで進めています。

導入効果：十日分の作業が半日に、思考に使える時間が二倍以上に

導入の効果は、提案書作成のリードタイムに明確に表れました。従来、提案書の骨子を作成するのに約十日を要していた作業が、半日程度で完了するようになりました。

時間が生まれたことで、コンサルタントが本来注力すべき思考の工程に充てられる日数が増えました。従来は付加価値を高める検討に平均二日程度しか取れていなかったところ、平均五日以上と二倍以上の時間を確保できるようになりました。「本質的でない部分はデータや AI に任せ、代替のきかない部分に集中する」という同社の狙いが、実際の業務で形になりました。

品質面でも効果が表れています。評価基準で求められる必須項目や加点項目を、限られた時間の中でも確実に押さえられるようになり、提案書の品質を組織として安定的に担保できる状態に近づきました。これまで個人の経験に依存しやすかった準備工程も、システムによる抽出と編集機能によって組織の標準プロセスとして底上げされています。

今後の展開

ITbook 株式会社様は2026年6月時点で本システムを社内でトライアル的に利用しながら改善を進める段階にあります。今後は、性能改善に加え、管理機能の整備を進める計画です。

適用範囲の拡大も視野に入れています。本システムは公共機関向けに作られていますが、提案書作成は民間企業でも共通するため、段階的に適用範囲を広げていく構想があります。さらに将来的には、提案する側だけでなく、自治体職員が調達仕様書を作成する作業の支援にまで広げることを最終的な目標として描いています。

お客様の声
ITbook株式会社代表取締役社長宇田川燿平氏からは、以下のようなコメントをいただいています。

「国や自治体の調達仕様書から提案書を生成する受注者支援に加え、将来的には調達仕様書そのものの作成支援にも活用予定です。コンサルタントは付加価値の高い業務に集中でき、生成 AI を起点としたコンサルティングの新しいビジネスモデルへの転換を推進します。」

まとめ

ITbook 株式会社様の取り組みは、生成 AI を人の仕事をそのまま代替する道具としてではなく、人が考える時間を生み出すための基盤として業務に組み込んだ事例です。Amazon Bedrock を中心に、処理を役割ごとに分割し、Human-in-the-loop で人の判断を残す設計によって、提案書作成のリードタイムを短縮しつつ、品質を組織として底上げすることを両立しました。AIMS を取得し AI ガバナンスを重視する同社にとって、データを学習に使わない形で基盤モデルを利用できる点も、安心して全社的な活用へ踏み出す後押しになっています。コンサルティング会社が AI ネイティブな働き方を模索するうえで、一つの参考になれば幸いです。

Amazon Bedrock の詳細については Amazon Bedrock のサービスページを、エージェント開発については Amazon Bedrock AgentCoreのサービスページをご覧ください。

なお、本ブログで記載する開発は、ITbook 株式会社様とAWS 上での AI エージェント開発に知見を持つアクロクエストテクノロジー株式会社様（以下、アクロクエスト）が協業して推進しました。ITbook 株式会社様が業務要件と品質基準を定義し、アクロクエスト様が実装を担う役割分担で、2026年1月に開発を開始しました。

アカウントマネージャー尾形龍太郎

完全なライフサイクル制御による分離されたサンドボックスの実行: AWS Lambda が MicroVM を導入

Takumi Saito — Wed, 01 Jul 2026 02:26:35 +0000

本記事は、2026 年 6 月 22 日に公開された Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs を翻訳したものです。翻訳は Solutions Architect の齋藤拓巳が担当しました。

本日、AWS Lambda MicroVMs を発表します。これは AWS Lambda 内の新しいサーバーレスコンピューティングプリミティブで、ユーザーや AI が生成したコードを分離されたステートフルな実行環境で実行できます。
仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境のライフサイクルと状態の直接制御が可能で、インフラストラクチャの管理や複雑な仮想化技術の専門知識は不要です。
Lambda MicroVMs は Firecracker を基盤としています。これは、月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた軽量仮想化技術と同じものです。

この機能が求められる背景

ここ数年、新しい種類のマルチテナントアプリケーションが登場しています。これらのアプリケーションはすべて、エンドユーザーごとに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する必要があるという共通点を持っています。AI コーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、ユーザー提供のスクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在この機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、カーネル共有アーキテクチャのため、信頼できないコードを安全に封じ込めるには大規模なカスタムのセキュリティ強化が必要です。Functions as a Service はイベント駆動型のリクエスト・レスポンスワークロードに最適化されていますが、ユーザーとのインタラクション間で環境の状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。その結果、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低レイテンシーの体験を提供しながら分離された実行を実現するために、カスタム仮想化インフラストラクチャの構築と運用に多大なエンジニアリングリソースを投資するかの選択を迫られます。これは深い専門知識を必要とし、本来構築しようとしているプロダクトからエンジニアリング時間を奪う取り組みです。

Lambda MicroVMs は、まさにこのギャップを埋めるために専用設計されています。
各 MicroVM は、単一のエンドユーザーまたはセッションに対して独自の分離された環境を提供し、高速に起動し、セッションの間メモリとディスクの状態を保持し、ユーザーが離席した際には低コストのアイドル状態に一時停止します。
同じ Firecracker テクノロジーが既に AWS Lambda Functions の基盤となっているため、このスタックを大規模に運用してきたサービスの運用成熟度をそのまま活用できます。

試してみましょう

まず、AWS Lambda コンソールに移動すると、左側のナビゲーションメニューに Lambda MicroVMs が表示されるようになっています。最初に MicroVM イメージを作成する必要があります。

Flask ウェブアプリとその Dockerfile を zip ファイルにパッケージ化し、Amazon Simple Storage Service (Amazon S3) バケットにアップロードしました。

Flask API – app.py

import logging 

 from flask import Flask, jsonify 

 app = Flask(__name__)
 logging.basicConfig(level=logging.INFO)


@app.route("/")
 def hello():
    app.logger.info("Received request to hello world endpoint")
    return jsonify(message="Hello, World!")


 if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

Dockerfile


 FROM public.ecr.aws/lambda/microvms:al2023-minimal 
 RUN dnf install -y python3 python3-pip && dnf clean all 

 WORKDIR /app 

 COPY requirements.txt .
 RUN pip install --no-cache-dir -r requirements.txt 

 COPY app.py .

 EXPOSE 5000 

 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"]

以下のコマンドを使用して MicroVM イメージを作成しました。

aws lambda-microvms create-microvm-image \ 
--code-artifact uri= --name  \ 
--base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ 
--build-role-arn

上の画像のように、AWS コンソールで MicroVM Image を作成することもできます。
コマンドを実行すると、Lambda が zip を取得し、Dockerfile を実行し、アプリケーションを初期化して、実行中のディスクとメモリの状態の Firecracker スナップショットを取得しました。
ビルドログは /aws/lambda/microvms/ 配下の Amazon CloudWatch にリアルタイムでストリーミングされ、イメージの準備が完了すると、Amazon Resource Name (ARN) とバージョン番号とともにコンソールに表示されました。

aws lambda-microvms run-microvm \ 
--image-identifier arn:aws:lambda:::microvm-image:my-image \ 
--execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole \ 
--idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}'

起動は AWS コンソールまたは CLI からも行えます。
ここでは、イメージ ARN と、15 分間操作がないと自動的にサスペンドし、次のリクエストを受信すると自動的にレジュームするよう設定したアイドルポリシーを渡しました。
ネットワークの設定は不要です。
Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、新しい MicroVM を起動します。この MicroVM はスナップショットからレジュームされるため、Flask アプリはすでに実行された状態になっています。
実際、起動が完了した瞬間には Flask アプリはすでに動作していました。
たった 1 回の API 呼び出しで、完全に初期化されブートストラップされたコンピューティング環境が手に入ります。

トラフィックを送信するために、CLI で短期間有効な認証トークンを生成し、X-aws-proxy-auth ヘッダーを使用して通常の HTTPS リクエストに添付しました。
リクエストはすぐに Flask アプリに到達しました。
その後、MicroVM をサスペンドのしきい値を超えてアイドル状態にしたところ、MicroVM はサスペンドされ、メモリとディスクの状態がスナップショットとして保存されました。
次に別のリクエストを送信すると、アプリケーションの状態が完全に保持されたまま再開されました。
クライアント側からは、一時停止が発生したことはまったくわかりませんでした。

仕組み

内部的には、Lambda MicroVMs は、これまで単一の AWS コンピューティングサービスでは同時に提供されていなかった 3 つの機能を実現しています。
1 つ目は、Firecracker による仮想マシンレベルの分離です。
各セッションは専用の MicroVM で実行され、ユーザー間でカーネルやリソースが共有されることはありません。
そのため、あるユーザーが提供した信頼されていないコードはそのユーザーの実行環境内に封じ込められ、他の環境や基盤システムへのアクセスはできません。
2 つ目は、高速な起動と再開です。
このモデルは「イメージを作成してから起動する」方式です。Dockerfile と Amazon S3 に zip アーティファクトとしてパッケージ化されたコードを提供して MicroVM Image を作成すると、Lambda が Dockerfile を実行し、アプリケーションを初期化し、実行中の環境のメモリとディスクの状態の Firecracker スナップショットを取得します。
そのイメージから起動される後続のすべての MicroVM は、コールドブートではなく事前に初期化されたスナップショットから再開されるため、起動とアイドル状態からの再開の両方でほぼ瞬時の起動レイテンシーを実現します。
数ギガバイト規模のインタラクティブセッションでも、エンドユーザーが快適に操作できるほど素早くオンラインに復帰します。
3 つ目は、ステートフルな実行です。
実行中の MicroVM は、ユーザーのセッション全体を通じてメモリ、ディスク、実行中のプロセスを保持します。
アイドル期間中、MicroVM はメモリとディスクの状態をそのまま維持したままサスペンドでき、トラフィックが到着すると再開されます。
インストール済みのパッケージ、ロード済みのモデル、作業中のファイルセットは、ユーザーがセッションを再開した際にすぐに利用可能です。
MicroVM は最大 8 時間の合計実行時間をサポートし、設定可能なアイドル時間の後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間のアイドル期間を伴うインタラクティブなコーディングセッションなど、多様なプロダクトを簡単に構築できます。
Lambda MicroVMs は事前に初期化されたスナップショットから起動されるため、初期化時に一意のコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションでは、互換性のためにサービスが提供するフックとの統合が必要になる場合があります。

Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、独自の API を備えています。
Lambda Functions は引き続きイベント駆動型のリクエスト・レスポンスワークロードに最適な選択肢であり、Lambda MicroVMs はマルチテナントアプリケーション向けに特化して構築されています。具体的には、各エンドユーザーやセッションに対して、ユーザーまたは AI が生成したコードを実行するための独立した分離環境を提供する必要があるアプリケーションに適しています。
この 2 つは互いを補完する関係にあります。
イベント駆動型のバックボーンに Lambda Functions を使用しているアプリケーションは、信頼できないコードを分離して実行する必要があるステップで Lambda MicroVMs を呼び出すことができます。
お客様がアプリケーションを持ち込み、サービスが実行環境を提供します。

提供開始

AWS Lambda MicroVMs は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) の各リージョンで本日より利用可能です。ARM64 アーキテクチャ上で、MicroVM あたり最大 16 vCPU、32 GB のメモリ、32 GB のディスクを提供します。
アイドル状態の MicroVM は、API 呼び出しによる明示的なサスペンド、またはライフサイクルポリシーによる自動サスペンドが可能で、完全な状態を保持したまま高速に再開できるため、実行コストを削減できます。
料金の詳細は AWS Lambda の料金ページをご覧ください。

開始するには、AWS Lambda コンソールにアクセスするか、Lambda MicroVMs 製品ページで詳細をご確認ください。
ドキュメントについては、Lambda MicroVMs デベロッパーガイドを参照してください。

著者について

Micah Walter

Micah Walter は、ニューヨーク市地域およびその他の地域のエンタープライズのお客様を支援するシニアソリューションアーキテクトです。クラウドへの移行のあらゆる段階で、エグゼクティブ、エンジニア、アーキテクトに対してアドバイスを行っており、サステナビリティと実践的な設計に深く注力しています。余暇には、アウトドアや写真撮影、家中を走り回る子どもたちを追いかけて楽しんでいます。

翻訳者について

齋藤拓巳

ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。

AWS Deadline Cloud の Wait and Save サービスマネージドフリートを使ってみる

Hiroki Mori — Tue, 30 Jun 2026 13:09:46 +0000

本記事は 2026 年 5 月 13 日に公開された「Getting Started with Wait and Save service-managed fleets on AWS Deadline Cloud」を翻訳したものです。

ビジュアルエフェクトやアニメーションのスタジオは、 AWS Deadline Cloud を活用することで、クリエイティブな反復作業を加速し、より多くのレンダリングオプションを検討できます。AWS Deadline Cloud は、2D・3D グラフィックスおよび VFX を制作するチーム向けに、レンダー管理を簡単にするフルマネージドサービスです。Deadline Cloud はサービスマネージドフリート（SMF）を提供しており、AWS がコンピューティングリソースのプロビジョニングや管理を自動的に行うことで、ユーザーのインフラ管理の負担を軽減します。Deadline Cloud の SMF で利用できるようになった Wait and Save は、通常のレンダリングジョブが始まるまでの時間に幅を持たせる代わりに、CPU レンダリングのコンピューティング料金を割引する機能です。本記事では、Deadline Cloud のサービスマネージドフリート（SMF）で Wait and Save を設定し、CPU レンダリングコストを削減する方法を紹介します。以下のトピックを取り上げます。

SMF のキャパシティ確保の仕組みを理解する
コスト削減を最大化するための専用 Wait and Save キューとフリートを設定する
Wait and Save、Spot、On-Demand フリートのコストを比較する
Deadline Cloud Monitor でジョブのステータス、待機時間、コストを追跡する
Wait and Save フリートと Spot フリートを組み合わせたハイブリッドフリート構成でキャパシティとコストを最適化するための自動化を行う

サービスマネージドフリート（SMF）のキャパシティ確保の仕組みを理解する

Deadline Cloud の SMF は、主に 2 つの方法で Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを取得できます。On-Demand インスタンスと Spot インスタンスです。On-Demand インスタンスは安定したコンピューティングキャパシティを提供するため、継続的かつ中断のない処理が必要なワークロードに適しています。Spot インスタンスでは、Amazon EC2 の未使用キャパシティを On-Demand 料金と比べて大幅な割引 (最大 90% の節約になることも) で利用できます。このキャパシティは、AWS のデータセンター全体で未使用のコンピューティングリソースが生じた際に提供されます。ただし、Spot インスタンス上のワークロードは、On-Demand リクエストへの対応のために中断される場合があります。

Wait and Save は、レンダリングジョブの開始タイミングに柔軟性を持たせる代わりに、割引されたコンピューティング料金で余剰の CPU Spot キャパシティを活用します。Deadline Cloud が Spot キャパシティの可用性が高い時間帯を利用できるようにすることで、レンダリングワークロードの品質とスループットを維持しながら、大幅なコスト削減を実現できます。最新の料金情報については、AWS Deadline Cloud の料金ページをご覧ください。

Wait and Save によるスマートスケジューリング

キャパシティと料金を最適化するための主な要素は以下のとおりです。

時間帯 – 顧客の利用パターンは一般的に 1 日の業務時間サイクルに連動しており、夕方や早朝はキャパシティの可用性が高くなる傾向があります。オフピーク時間帯にジョブを投入することで、より早くキャパシティを確保できます。
リージョン戦略 – 現在が業務時間外となる AWS リージョンへのジョブ投入を検討してください。たとえば、米国の日中に作業している場合、異なるタイムゾーンのリージョンでは、その時間帯により多くのキャパシティが利用できる可能性があります。異なるリージョンを使用する際は、組織のデータガバナンスおよびデータレジデンシーの要件への準拠を確認してください。

オフピーク時間帯にジョブを投入したり、別のリージョンを選択したりすることで、Wait and Save の利用可能なキャパシティへのアクセスを増やし、割引料金のメリットを享受できます。

Wait and Save を手軽に活用する方法として、Wait and Save フリートのみに紐付けた専用キューを使う方法があります。以降のセクションでは、Wait and Save フリートの基本的なセットアップ手順を説明し、コスト削減効果を示したうえで、既存の EC2 Spot または On-Demand フリートと Wait and Save フリートを統合する方法を紹介します。

前提条件

開始する前に、Wait and Save がワークロードの要件に合っているか確認し、必要な AWS リソースが設定済みであることを確認してください。

Wait and Save は以下のワークロードに対応しています。

CPU ベースのレンダリングワークロードのみ (GPU は非対応)
スケジューリングに柔軟性があるプロジェクト
開始時間が変動しても対応できるワークロード

考慮すべき主な制限事項は以下のとおりです。

インスタンスタイプの選択 – Wait and Save は、指定した要件に合う CPU インスタンスタイプの中から自動的に選択します。特定のインスタンスタイプを指定することはできません。
待機時間 – ジョブは通常 24 時間以内に開始されます。実際の待機時間はリージョン、時間帯、利用可能なキャパシティによって異なります。
中断 – On-Demand リクエストへの対応のため、ワーカーが中断される場合があります。中断されたタスクは最初から再実行されます。

以下の AWS リソースが事前に用意されていることを確認してください。

Deadline Cloud を使用するための AWS アカウント
任意のリージョンに設定された Deadline Cloud モニター　と以下を含みます。
- ユーザー用のリージョナル AWS IAM Identity Center
- モニター URL
- Wait and Save フリートを設定するファーム (Deadline Cloud を初めて使用する場合は、クイックスタートガイドを使ってリソースをプロビジョニングしてください)
対応するデジタルコンテンツ制作 (DCC) アプリケーションと、対応する Deadline Cloud サブミッターのインストール

専用キューの作成

以下の手順で専用キューを作成します。

Deadline Cloud コンソールのナビゲーションペインで Farms を選択します。
ファームの一覧から対象のファームを選択します。
Queues タブで Create queue を選択します。
キューの設定を行います (追加オプションについては Deadline Cloud キューを参照してください)。
- Queue name にわかりやすい名前を入力します (例: Wait and Save Queue)。
- Job attachments で、ジョブの添付ファイル用の Amazon Simple Storage Service (Amazon S3) バケットを設定します。
Create queue を選択します。

図 1: Wait and Save フリート専用のキューを作成する

Wait and Save フリートの作成

以下の手順で Wait and Save フリートを作成します。

Deadline Cloud コンソールのナビゲーションペインで Farms を選択します。
ファームの一覧から対象のファームを選択します。
Fleets タブで Create fleet を選択します。
フリートの詳細を設定します。
- Fleet name にわかりやすい名前を入力します (例: Wait and Save Fleet)。
- Fleet type で Service-managed を選択します。
- Instance market type で Wait and Save を選択します。
Next を選択します。

図 2: サービスマネージドフリートタイプと Wait and Save インスタンスマーケットタイプを選択する

フリートのハードウェアおよびソフトウェア要件を定義します。特定の EC2 インスタンスタイプを選択する必要はありません。Wait and Save は、指定した条件に合うインスタンスタイプの中から自動的に選択します。
- Amount vCPU に vCPU 数の最小値と最大値を入力します (例: 4〜16)。
- Amount memory (GiB) にメモリの最小値と最大値を入力します (例: 32〜64)。
Next を選択します。
ワークロードの要件に応じて Maximum worker count を設定します。デフォルトのクォータはリージョンあたり Wait and Save vCPU 50 個です。クォータはリソースの適切な使用とコスト管理を促進するために設定されています。大規模な本番ワークロードに対応するには、Deadline Cloud の Wait and Save vCPU のリージョンあたりのクォータ引き上げをリクエストしてください。クォータ引き上げのリクエスト手順については、Service Quotas ユーザーガイドを参照してください。
Next を選択します。
Associate queues で、先ほど作成したキューに Wait and Save フリートを関連付けます。
Next を選択します。

図 3: Wait and Save キューをフリートに関連付ける

追加の設定とタグを行い (任意)、Next を選択します。
内容を確認し、Create fleet を選択します。

Wait and Save キューへのジョブ投入

Wait and Save の動作を確認するために、200 フレームのターンテーブルレンダーを投入します。この例では Autodesk Maya と Deadline Cloud サブミッターを使用しますが、他の対応 DCC でも同様の手順で投入できます。

Maya ファイルを保存します。
Maya のシェルフで Deadline Cloud を選択してサブミッターを開きます。
Shared job settings セクションで以下を設定します。
- Farm Selection で、Wait and Save キューが含まれるファームを選択します。
- Queue Selection で、作成した Wait and Save キューを選択します。
Submit を選択し、画面の指示に従ってジョブを Deadline Cloud に送信します。

図 4: 専用の Wait and Save キューを設定した Maya Deadline Cloud サブミッター

Deadline Cloud Monitor でジョブのステータスとコストを確認する

Deadline Cloud Monitor でジョブを追跡し、以下の情報を確認します。

ジョブのステータス – Wait and Save のキャパシティが確保されると、ジョブのステータスが Ready から Running に移行します。デスクを離れている間もジョブの開始や完了を把握できるよう、Amazon EventBridge の通知を設定できます。詳細については、Job Run Status Change イベントを参照してください。
待機時間 – ジョブの投入から実行開始までの時間を確認します。Wait and Save の待機時間は、時間帯、リージョン、ワークロードのサイズ、フリートの設定によって異なります。通常、待機時間は 24 時間未満です。以下のジョブモニターのスクリーンショットに示すように、ジョブの Create time から Start time までの詳細を確認すると、このジョブは実行開始まで約 7 時間かかっています。

図 5: ジョブモニターでジョブの作成日時、開始日時、終了日時を確認できる

中断時の処理 – 中断が発生した場合、未完了のタスクは最初から再実行されます。中断されたワーカーは、リソースが利用可能であれば他のインスタンスタイプから補充されます。短いタスクであれば影響は最小限ですが、実行時間の長いタスクは進捗が失われる場合があります。
使用状況とコストの追跡 – Deadline Cloud の使用状況エクスプローラーを使って、Spot や On-Demand の料金と比較したコストを確認し、実行時間のパターンを追跡できます。専用の Wait and Save キューを使用すると、キューフィルターでジョブの実行中、待機中、中断中の時間帯別の使用パターンを確認できます。

図 6: この使用状況エクスプローラーのビューは、各マーケットタイプ向けに作成した専用キューに同一のジョブを投入した結果を示しています。時間単位の表示設定により、各ジョブがいつ実行されたかを確認できます。

Wait and Save 専用セットアップによるコスト削減

例として送信した 200 フレームの Maya ターンテーブルレンダリングのコストへの影響を見てみましょう。実際の削減効果を示すために、マーケットタイプごとに専用キューを作成し、同一のワーカー性能で同じ Maya ジョブを Wait and Save、Spot、On-Demand の各フリートで実行しました。

3 つのマーケットタイプすべてで 200 フレームの Maya ターンテーブルレンダリングを実行した結果、次の表に示すとおり、コンピューティングコストに大きな差が生じました。このジョブ 1 件において、Wait and Save は Deadline Cloud の On-Demand と比較して 92%、Deadline Cloud の Spot と比較して 78% のコスト削減を実現しました。

サービスマネージドフリートのマーケットタイプ	コンピューティングコスト	ライセンスコスト	200 フレーム Maya ジョブの総レンダリングコスト
On-Demand	$2.09	$2.86	$4.95
Spot	$0.76	$2.04	$2.80
Wait and Save	$0.17	$2.18	$2.35

図 7: 各マーケットタイプにおける 200 フレーム Maya ターンテーブルレンダリングのコンピューティングコストとライセンスコストの合計: On-Demand (左)、Spot (中央)、Wait and Save (右)。

図 8: Deadline Cloud Monitor の使用状況エクスプローラーに表示された各マーケットタイプの総コスト内訳。

キャパシティとコストを最適化する自動ハイブリッドフリートのセットアップ

ジョブのキャパシティ可用性を高めつつ、可能な限りコストを抑えたい場合は、既存の Spot フリートや On-Demand フリートと同じキューに Wait and Save を関連付けることができます。これにより、コスト最適化とキャパシティ可用性のバランスが自動的に取られ、ジョブを遅延なく実行できます。

次のオープンソースの AWS CloudFormation テンプレートは、AWS Lambda と Amazon EventBridge Scheduler を使用して、Wait and Save ワーカーの可用性に応じて Spot フリートのキャパシティをリアルタイムで自動調整します。Lambda 関数は一定間隔で希望するフリートサイズを監視し、主に Wait and Save フリートから必要なワーカー数を確保しつつ、不足分はセカンダリの Spot フリートのインスタンスで補います。Deadline Cloud のワーカー終了ポリシーはワーカーレベルで適用されるため、インスタンスはタスクの完了後にのみ終了します。これにより、レンダリングを中断することなく、フリートを最もコスト効率の高い構成に保てます。

自動キャパシティ管理をデプロイするには、次の手順を実行します。

Wait and Save フリートを、既存のキューに On-Demand または Spot フリートと並べて関連付けます。
Wait and Save フリートの maxWorkerCount を希望するフリート全体のサイズに設定します (例: 両フリート合計で 20 ワーカー)。
CloudFormation テンプレートをダウンロードし、以下のパラメータを指定して README のデプロイ手順に従います。
- TargetMaxWorkerCount: 両フリート合計のワーカー数 (Wait and Save の maxWorkerCount と一致させる必要があります)
- FarmId: Deadline Cloud のファーム ID
- WaitAndSaveFleetId: Wait and Save フリートの ID
- SpotFleetId: Spot フリートの ID
- CapacityCheckRateMinutes: キャパシティチェックの間隔 (デフォルト: 2 分)

Lambda 関数は、Wait and Save ワーカーのオンライン・オフラインに応じて Spot フリートを自動的にスケールアップまたはスケールダウンし、希望する合計キャパシティを維持します。

多くの AWS サービスと同様に、Lambda は従量課金制で、100 万リクエストあたり $0.20 から利用でき、AWS 環境内でコードベースの自動化を素早く構築するためのコスト効率の高い手段です。レンダリングを行っていない間は、EventBridge スケジュールを無効にすることで、キャパシティ管理の自動化と Lambda の呼び出しコストを停止できます。フリート設定でワーカーの最小数が 0 に設定されているため、ジョブがなければワーカーは起動せず、レンダリングコストは発生しません。

クリーンアップ

本記事で作成したリソースが不要になった場合は、以下の手順に従ってください。

AWS アカウントで CloudFormation コンソールを開きます。
本記事の手順に沿って作成したスタックを検索します。
スタックの削除を選択し、ステータスが DELETE_COMPLETE に変わるまで待ちます。これにより、Lambda 関数、EventBridge スケジュール、および IAM ロールがアカウントから削除されます。
Deadline Cloud のリソース (ファーム、フリート、キューなど) を削除するには、Clean up your farm resources in Deadline Cloud を参照してください。

まとめ

Wait and Save は、柔軟な CPU レンダリングワークロードに対して大幅なコスト削減をもたらします。Maya を使った例では、Spot 料金と比較して専用の Wait and Save 構成で 78% のコスト削減を実現しました。最大限の節約を目的とした専用キューの利用でも、柔軟な実行を目的としたハイブリッドフリート構成でも、Wait and Save はレンダリングコストを大幅に削減できます。大規模なプロジェクトではこの節約効果がさらに積み重なり、スタジオが予算内でより多くのコンテンツをレンダリングするのに役立ちます。

AWS 担当者にお問い合わせいただき、ビジネスの加速に向けたサポートについてご相談ください。

参考資料

Wait and Save フリートのセットアップとコスト削減効果を確認したら、引き続き Deadline Cloud の機能を学び、レンダリングワークフローをさらに最適化しましょう。

他のフリートタイプと設定についても学び、レンダリングパイプラインを最適化しましょう。高度な設定オプションについては、Service-managed fleets を参照してください。
Wait and Save と他のインスタンス市場タイプの詳細な料金情報およびリージョン別料金は、AWS Deadline Cloud 料金ページで確認できます。
Wait and Save ジョブの開始・完了時にアラートを受け取るには、ジョブ実行ステータスイベントの EventBridge 連携を使ったジョブステータス変更の自動通知設定について学びましょう。
コストの追跡と使用パターンの分析については、Deadline Cloud の使用状況エクスプローラーによるコストと使用状況の追跡を参照してください。
Deadline Cloud が提供する CloudFormation テンプレートのオープンソースサンプルもご覧ください。

著者について

参考リンク

AWS Media Services

AWS Media & Entertainment Blog (日本語)

AWS Media & Entertainment Blog (英語)

AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp

※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は Visual Compute SSA 森が担当しました。原文はこちらをご覧ください。

AWS マネジメントコンソールへのアクセスを想定するネットワークに制限

中島章博 — Tue, 30 Jun 2026 08:36:31 +0000

本ブログは 2026 年 6 月 24 日に公開された AWS Blog “Restrict AWS Management Console access to expected networks with sign-in resource-based policies and RCPs” を翻訳したものです。

Amazon Web Services (AWS) は 2026 年 6 月 16 日に、リソースベースポリシーとリソースコントロールポリシー (RCP) を AWS サインインでサポートすることを発表しました。リソースベースポリシーと RCP を使用すると、AWS マネジメントコンソールへのサインインと aws login CLI セッションへのアクセスを、想定するネットワーク、オンプレミスのデータセンターネットワーク、およびお客様の Amazon Virtual Private Cloud (Amazon VPC) からのリクエストに制限できます。

サインインのリソースベースポリシーと RCP は、いくつかのセキュリティ目標に対応します。具体的には、コンソールサインインを企業ネットワークに制限すること、コンソールにサインインできるプリンシパルを限定すること、そして AWS Organizations の組織全体にわたって一貫したネットワーク境界制御を適用することです。

この記事では、一般的なユースケースを取り上げます。規制コンプライアンスのために、ある金融サービス企業がコンソールアクセスを企業ネットワークに制限するというケースです。単一アカウントに対してサインインのリソースベースポリシーを使用してこれを実装する方法、AWS CloudTrail で制御を検証する方法、そしてこれらのポリシーが AWS Management Console Private Access やより広範な AWS データ境界フレームワークとどのように統合されるかを説明します。

コンソールサインインアクセスを企業ネットワークに制限する

ある金融サービス企業が、AWS マネジメントコンソールへのサインインを企業ネットワークから行うことを求めているとします。この企業には次の要件があります。

ユーザーは、企業 VPN、オフィスネットワーク、またはお客様の VPC からのみコンソールにサインインする
個人ネットワーク、公衆 Wi-Fi、その他の想定外の場所からのサインイン試行は拒否しなければならない
ロックアウトを防ぐため、指定したプリンシパルはどのネットワークからでもアクセスを保持できるようにする
コンプライアンスの証跡として、すべてのサインイン試行 (許可および拒否) を CloudTrail に記録しなければならない

以下のステップでは、単一アカウントでこれらの要件を適用するリソースベースポリシーを作成する方法を紹介します。

前提条件

AWS Command Line Interface (AWS CLI) が最新バージョンでインストールされ、設定されていること
サインインのリソースポリシーを管理する権限。AWS マネージドポリシーの AWSSignInResourcePolicyManagement をアタッチするか、各プリンシパルに次のアクションへの権限を付与します。
- リソース許可ステートメントの管理: signin:PutResourcePermissionStatement, signin:DeleteResourcePermissionStatement, signin:ListResourcePermissionStatements, signin:GetResourcePolicy.
- コンソール認可の管理: signin:PutConsoleAuthorizationConfiguration, signin:GetConsoleAuthorizationConfiguration, signin:DeleteConsoleAuthorizationConfiguration
特定の企業ネットワーク: IP CIDR 範囲または VPC ID
除外する指定プリンシパルの Amazon リソースネーム (ARN)。これにより、ネットワーク条件が変わってもアクセスを保持できます

注: AWS サインインアクションの完全なリストについては、サービス認可リファレンスの AWS Signin のアクション、リソース、および条件キーを参照してください。

ステップ 1: リソース許可ステートメントを作成する

ほとんどのリソースベースポリシーでは、作成者がポリシードキュメント全体 (JSON ステートメント) を入力する必要があります。サインインのリソース許可ステートメントは異なります。パラメータを指定すると、AWS サインインがポリシーを生成します。

次のコマンドでは、企業 IP 範囲、VPC、除外プリンシパルをパラメータとして指定します。AWS サインインはこれらのパラメータを使用して、コンソールサインインをそれらのネットワークに制限しつつ、除外プリンシパルがどのネットワークからでもサインインできるようにするポリシーを生成します。お客様が制御するのはパラメータの値であり、ポリシーの構造ではありません。生成されたポリシーは、get-resource-policy コマンドでいつでも確認できます。

注: リソース許可ステートメントは、ステップ 2 でコンソール認可を有効にするまで効果を発揮しません。そのため、効果が発生する前に完全なポリシーを確認できます。なお、書き込み操作は us-east-1 を対象にする必要があります。

リソース許可ステートメントを作成するには、次の手順を実行します。

1. ターミナルを開き、最新の AWS CLI がインストールされていることを確認します。

2. 次のコマンドを実行し、プレースホルダー値 <my-vpc>、<my-vpc-region>、<my-corporate-cidr>、<excluded-IAM-principal-arn> を、お客様の具体的な設定に置き換えます。

aws signin put-resource-permission-statement \
  --source-vpc <my-vpc> \
  --requested-region <my-vpc-region> \
  --source-ip <my-corporate-cidr> \
  --excluded-principal <excluded-IAM-principal-arn> \
  --region us-east-1

3. 出力に statementId があることを確認して、コマンドが成功したか検証します。

出力例:

{
"statementId":"b2HfHli9qCF1P4eGNll13CrZtusXlcPxxVBqz2aYLjlAcWtWQHP6Hg0"
}

4. get-resource-policy コマンドを実行して、完全なリソースベースポリシーを確認します。

aws signin get-resource-policy

出力例:

{
  "signinResourceBasedPolicy": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "DENY",
        "Principal": {"AWS": "*"},
        "Action": ["signin:Authenticate"],
        "Resource": "*",
        "Condition": {
          "ArnNotEquals": {"signin:PrincipalArn": ["<excluded-IAM-principal-arn>"]},
          "NotIpAddress": {"aws:SourceIp": ["<my-corporate-cidr>"]},
          "StringEquals": {"aws:ResourceAccount": ["<account-id>"]},
          "StringNotEquals": {"aws:SourceVpc": ["<my-vpc>"]}
        }
      },
      {
        "Effect": "DENY",
        "Principal": {"AWS": "*"},
        "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
        "Resource": "*",
        "Condition": {
          "ArnNotEquals": {"aws:PrincipalArn": ["<excluded-IAM-principal-arn>"]},
          "NotIpAddress": {"aws:SourceIp": ["<my-corporate-cidr>"]},
          "StringEquals": {"aws:ResourceAccount": ["<account-id>"]},
          "StringNotEquals": {"aws:SourceVpc": ["<my-vpc>"]}
        }
      },
      {
        "Effect": "DENY",
        "Principal": {"AWS": "*"},
        "Action": ["signin:Authenticate"],
        "Resource": "*",
        "Condition": {
          "ArnNotEquals": {"signin:PrincipalArn": ["<excluded-IAM-principal-arn>"]},
          "StringEquals": {"aws:SourceVpc": ["<my-vpc>"]},
          "StringNotEquals": {"aws:RequestedRegion": ["<my-vpc-region>"]}
        }
      },
      {
        "Effect": "DENY",
        "Principal": {"AWS": "*"},
        "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"],
        "Resource": "*",
        "Condition": {
          "ArnNotEquals": {"aws:PrincipalArn": ["<excluded-IAM-principal-arn>"]},
          "StringEquals": {"aws:SourceVpc": ["<my-vpc>"]},
          "StringNotEquals": {"aws:RequestedRegion": ["<my-vpc-region>"]}
        }
      }
    ]
  }
}

生成されたポリシーには 4 つのステートメントが含まれ、2 つのペアにグループ化されています。最初のペアはネットワークソースによってアクセスを制限し、企業 IP 範囲 (<my-corporate-cidr>) または VPC (<my-vpc>) の外部からリクエストを行うプリンシパルを拒否します。2 番目のペアは、VPC がターゲットにできる AWS リージョンを制限し、<my-vpc> から発信されたリクエストを、<my-vpc-region> に向けられたものでない限り拒否します。このリージョンへのバインディングが必要なのは、VPC ID が単一リージョン内でのみ一意であるためです。

AWS サインインはこれらのポリシーを 2 つのフェーズ、つまり認証前と認証後で評価します。認証後の評価は、コンソールセッションが新しい認証情報をリクエストするたびに繰り返されます。各ペアの中で、1 つのステートメントは認証前フェーズをカバーし、もう 1 つは認証後フェーズをカバーします。

認証前のステートメントは signin:Authenticate アクションを評価します。このフェーズではプリンシパルがまだ認証されていないため、ステートメントは signin:PrincipalArn 条件キーを使用して除外プリンシパルを免除します。このキーはすべてのプリンシパルタイプ (ルートユーザー、AWS Identity and Access Management (IAM) ユーザー、フェデレーションユーザー、ロール) をサポートします。

認証後のステートメントは signin:AuthorizeOAuth2Access および signin:CreateOAuth2Token アクションを評価します。AWS サインインは、コンソールセッションを確立するトークンを発行する認証後に、これらのアクションを評価します。これらのアクションは signin:PrincipalArn キーをサポートしません。代わりに、認証済みのプリンシパルに解決される aws:PrincipalArn を使用します。

aws:ResourceAccount の値は受信側のアカウント ID です。AWS サインインが呼び出し元の認証情報から自動的に取得するため、お客様が自分で設定する必要はありません。サポートされるアクションと条件キーの完全なリスト (各フェーズと各プリンシパルタイプにどのキーが適用されるかを含む) については、Controlling console access with resource-based policies and resource control policies および AWS Sign-In condition keys reference を参照してください。

ステップ 2: アカウントのサインインポリシー適用を有効にする

このステップでは、ステップ 1 で作成したポリシーの適用を有効にします。このステップを実行するまで、ステップ 1 で作成したリソース許可ステートメントは効果を発揮しません。

5. 次のコマンドを使用して、サインインポリシーの適用を有効にします。

aws signin put-console-authorization-configuration \
  --target-id <account-id> \
  --region us-east-1

6. 出力に "consoleAuthorizationEnabled": true があることを確認して、コマンドが成功したか検証します。

出力例:

{
"Output": {
"consoleAuthorizationEnabled": true,
"scope": "ACCOUNT",
"targetId": "<account-id>"
}
}

7. 以下のように get-console-authorization-configuration コマンドを実行して、設定を検証することもできます。

aws signin get-console-authorization-configuration \
  --target-id <account-id> \
  --region us-east-1

8. 適用を無効にしたり個別のステートメントを削除したりするには、delete-console-authorization-configuration または delete-resource-permission-statement を使用します。詳細については、AWS サインインユーザーガイドの Controlling console access with resource-based policies and resource control policies を参照してください。

実装の検証

適用が有効になったので、サインイン試行はリソースベースポリシーに照らして評価されます。さまざまなネットワーク条件からサインインをテストして、動作を検証しましょう。

シナリオ 1: 企業ネットワークからの許可されたサインイン

許可された企業 IP 範囲または VPC からサインインするプリンシパルは、正常にサインインできます。CloudTrail イベントには ConsoleLogin:Success が表示されます。

コンソールサインイン成功時の CloudTrail イベント詳細の例:

{
    "userIdentity": {
        "type": "AssumedRole",
        "principalId": "AROAEXAMPLEID:Dev1",
        "arn": "arn:aws:sts::123456789123:assumed-role/Developer/Dev1",
        "accountId": "123456789123"
    },
    "eventTime": "2026-06-09T19:20:38Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ConsoleLogin",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "192.0.2.100",
    "responseElements": {
        "ConsoleLogin": "Success"
    },
    "eventID": "dd004e78-6447-4f56-8d2d-a795da66f598",
    "readOnly": false,
    "eventType": "AwsConsoleSignIn",
    "managementEvent": true,
    "recipientAccountId": "123456789123",
    "eventCategory": "Management"
}

シナリオ 2: 想定外のネットワークからの拒否されたサインイン

許可された IP アドレス範囲、またはソース VPC にアタッチされた VPC エンドポイント以外のネットワークからサインインするプリンシパルはブロックされます。CloudTrail イベントには ConsoleLogin: Failure が表示され、拒否の原因となったポリシーを特定するエラーメッセージが含まれます。

コンソールサインイン失敗時の CloudTrail イベント詳細の例:

{    
"userIdentity": {
    "type": "IAMUser",
    "accountId": "123456789123",
    "accessKeyId": "",
    "userName": "Dev1"
    },
    "eventTime": "2026-06-09T19:20:38Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "ConsoleLogin",
    "awsRegion": "us-east-1",
    "sourceIPAddress": "198.51.100.76",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Safari/537.36",
    "errorCode": "AccessDenied",
    "errorMessage": "Authorization denied because of a resource-based policy",
    "requestParameters": null,
    "responseElements": {
        "ConsoleLogin": "Failure"
    },
"eventID": "d88a7543-ae89-4186-b1b6-d3116413f2ee",
"readOnly": false,
"eventType": "AwsConsoleSignIn",
"managementEvent": true,
"recipientAccountId": "123456789123",
"eventCategory": "Management"
}

エラーメッセージフィールドには、拒否の原因となったポリシータイプが表示されます。"Authorization denied because of a resource-based policy" (リソースベースポリシーにより認可が拒否されました)。

RCP による大規模展開

上記のステップでは、サインインのリソースベースポリシーを単一アカウントに適用します。多数のアカウントを管理する組織にとっては、RCP がより優れた方法です。RCP は AWS Organizations の組織、OU、またはアカウントレベルでアタッチでき、対象範囲内のすべてのアカウントに自動的に適用されます。RCP の例については、こちらを参照してください。

RCP によってコンソールへのサインインが拒否された場合、エラーメッセージフィールドには拒否が "Authorization denied because of a resource control policy" (リソースコントロールポリシーにより認可が拒否されました) と表示されます。

Console Private Access とデータ境界による拡張

作成したサインインのリソースベースポリシーは、どのネットワークがお客様のアカウントのサインインフローに到達できるかを制御します。AWS Management Console Private Access は補完的な制御を追加します。具体的には、お客様のネットワーク内から、コンソールアクセスを既知の AWS アカウントのセットに限定し、想定外の AWS アカウントへのサインインを防ぎます。

これらの機能を組み合わせることで、コンソールアクセスのデータ境界の形成に役立ちます。

ネットワーク境界: サインインのリソースベースポリシーと RCP は、コンソールサインインを想定するネットワーク (企業 IP 範囲、VPC) に制限します
アイデンティティ境界: サインインのリソースベースポリシーと RCP は、信頼できるアイデンティティのみがコンソールにサインインできることを保証します。コンソール VPC エンドポイントポリシーとサインイン VPC エンドポイントポリシーは、信頼できるアイデンティティのみがお客様の VPC からコンソールを使用できることを保証します
リソース境界: サインイン VPC エンドポイントポリシーとコンソール VPC エンドポイントポリシーは、お客様のネットワークからどの AWS アカウントに到達できるかを制限します

この記事の制御はコンソールアクセスに焦点を当てています。これらの境界を他の AWS サービスやより広範な実装シナリオに拡張するには、Data perimeter policy examples リポジトリと Data Perimeters Blog Post Series を参照してください。

まとめ

サインインのリソースベースポリシーと RCP を使用することで、AWS マネジメントコンソールへのアクセスを想定するネットワークに制限できます。これらの制御は、すべての AWS 商用リージョンで追加料金なしで利用できます。

使い始めるには、AWS サインインユーザーガイドを参照してください。組織全体での適用については、AWS Organizations ユーザーガイドの Resource control policies を参照してください。

Agent Focus の紹介

稲田大陸 — Tue, 30 Jun 2026 05:23:26 +0000

本記事は「Introducing Agent Focus – Kiro」を翻訳したものです。

開発者が AI と協働する方法は変わりつつあります。モデルは今や複数ステップの作業を計画し実行できるようになり、より多くの開発者が、自分で一行ずつコードを打ったり直接編集したりするのではなく、エージェントを導くことに一日を費やすようになっています。

IDE は別の場面のために作られたものです。IDE はコードを中心に据えますが、それはまさに「自分で編集しているとき」に欲しいものです。しかし、主な仕事がエージェントに実行させる作業を定義し、洗練し、方向づけることであるとき、それが必ずしも欲しいものとは限りません。

2026 年 6 月 25 日、私たちは Agent Focus を発表します。これは Kiro IDE における実験的な新しいビューで、エージェントとのやり取りを前面に押し出すものです。チャットファーストな働き方の基盤を築きます。やりたいことを記述し、会話を通じて洗練させ、作業を開始し、エージェントが進める様子を確認する——という流れです。これまでの IDE 体験がなくなるわけではありません。Agent Focus はそれと並んで存在し、いつでも両者を行き来できます。

Agent Focus でできること

このビューの中では、複数のワークスペースをまたいで、独立して並行に動く複数のセッションを立ち上げられます。エージェントとチャットしてコードを書いたり、アイデアを探ったり、問題を解いたり——あるいはもっと構造が必要なときには仕様（spec）を定義・洗練したりできます。各セッションで何が起きているかを高い視点で把握し、対応が必要になったら介入する。じっくり見る必要がある作業のときには、コード中心のビューに戻って直接編集できます。

このビューは 3 つのパネルで構成されています。

エージェントパネル（左）: 新しいセッションを作成し、ワークスペースごとにグループ化して閲覧でき、各セッションの状態——作業中、入力待ち（ブロック中）、一時停止中——を一目で確認できます。終わったものはクリアできます。

チャットパネル（中央）: 刷新された新しいチャット体験。エージェントを導き、意図を洗練させ、作業が進む様子を見守れます。ファイルの変更はインラインのコード差分として表示されるので、ビューを切り替えることなく追えます。

補助パネル（右）: 必要になるまで非表示。エージェントが変更されたファイルや仕様のサマリーを示すために表示することもあれば、じっくり見たいときに自分で開くこともできます。

一部の機能はまだこのビューにネイティブ実装されていないため、Agent Focus は設定、powers、skills、MCP、ターミナル、完全な git、直接のファイル編集といったものについて、IDE へ戻る明確な経路を保っています。

これは実験であり、慣れ親しんだ IDE はそのまま残ります

Agent Focus は実験的なリリースです。ぜひ試して、何がうまくいき、何がうまくいかないかを、インターフェース内の「Report issue」ボタン、GitHub の issue、あるいは Discord で教えてください。ただし、中核となる IDE 体験は変わりません。IDE は引き続きデフォルトであり、今日あなたが行っていることはすべて今までどおりに動作し、好きなだけそこにとどまれます。Agent Focus は、私たちが早い段階であなたの手に委ねる「もう一つの働き方」です。

切り替え方法

切り替えは手間がかからないように作られています。Agent Focus はウィンドウ右上に常に 1 クリックで届く場所にあり、「Agent Focus」とラベル付けされています。戻りたいときは、同じ場所にあるコントロールが「IDE」とラベル付けされています。いつでも、どちらの方向にも、自分の作業位置を失うことなく行き来できます。

入手方法

Agent Focus は最新版の Kiro 1.0 に同梱されています。Kiro ダウンロードページから Kiro をアップデートし、新しいビルドになると Agent Focus がウィンドウ右上に表示されます。

Agent Focus は、Kiro におけるチャットファーストでエージェント中心の構築スタイルへの私たちの第一歩であり、ここから成長していきます。その最良の形は、あなたが実際にどう使うかによって形づくられるものです。Kiro をダウンロードし、右上から Agent Focus を開き、いくつかセッションを動かして、気づいたことを私たちに教えてください。

1 つのタスク、2 つのプロバイダー(GitLab と GitHub) をまたぐ変更を 1 セッションで調整する

稲田大陸 — Tue, 30 Jun 2026 05:20:24 +0000

本記事は「One Task, Two Providers: Coordinating Changes Across GitLab and GitHub in one session」を翻訳したものです。

Kiro Web は、既存の GitHub サポートに加えて、GitLab でも動作するようになりました。より興味深いのは、コードが GitLab と GitHub の両方にまたがって存在する場合に何が起きるかです。両方からリポジトリを同じセッションに追加し、単一の変更を記述すれば、Kiro がそれを両方にわたって実行し、一方にはマージリクエスト（MR）を、もう一方にはプルリクエスト（PR）を開いてくれます。これは、コードが 1 つのきれいな場所に収まっていないときに意味を持ちます。

2 つの場所に存在するコード

多くのチームはプロバイダーをまたいで分かれており、たいていそれには正当な理由があります。オープンソースの SDK はコミュニティが見つけられるように GitHub に置かれ、それが通信するサービスは GitLab 上にプライベートのまま残されている。あるいは買収によって、組織の半分が一方のプロバイダーに、もう半分が別のプロバイダーに分かれてしまった。あるいはフロントエンドとバックエンドのチームが、何年も前にたまたま別々のツールに落ち着いただけ、ということもあります。理由が何であれ、そのコストは変更が両方にまたがった瞬間に現れます。1 つの論理的な更新が、2 つのコンテキストで 1 つのプルリクエストと 1 つのマージリクエストになり、ステップを忘れて両者が同期からずれてしまう機会が 2 回生じるのです。

小さな例

ここで使うセットアップを示します。本物の代わりとして、あえてシンプルなものにしています。その場所に、あなたの実際のサービスと SDK を思い浮かべてください——数千行、本物のビジネスロジック、本物の利用者がいるものを。

GitLab 上のプライベートサービスがあるとします。

そして、GitHub 上のパブリック SDK が、そのサービスをラップしています。

email フィールドをエンドツーエンドで追加したいとします。サーバー側の変更は GitLab に属し、SDK 側の変更は GitHub に属します。これは、2 つのリポジトリ、2 つのプロバイダーにまたがって、変更を加えないといけません。

1 つのプロンプト、両方のリポジトリ

GitLab と GitHub の両方をすでに接続した状態で、セッションを開始し、両方のリポジトリ（GitLab の user-service と GitHub の user-sdk）をアタッチします。そして、変更をシンプルな言葉で記述します。

両方のリポジトリがセッション内にあるため、Kiro はそれらを無関係な 2 つのタスクとして扱うのではなく、一緒に推論します。

隔離されたサンドボックスの中で作業し、両方のリポジトリを探索し、それぞれの側が何を必要とするかを把握し、変更を行います。サービスではレコードとレスポンスに email を追加し、SDK では User 型と使用例を更新します。各リポジトリにフィーチャーブランチを作成し、明確なメッセージでコミットします。

完了すると、2つの変更が待っています。サービス用の GitLab 上のマージリクエストは以下のようになります。

そして、SDK 用の GitHub 上のプルリクエストは以下のようになります。

それぞれが、何が変わったかと、そのアプローチの説明を伴っています。あなたは各変更を、それぞれのホームプロバイダー上で、チームがすでに使っているまさにそのワークフローでレビューしてマージします。レビュープロセスについては何も変わりません。ただ、クロスリポジトリの調整作業を自分でやらなくて済んだ、というだけです。

まとめ

プロバイダーをまたぐ分割は、しばしば現実的で、維持する価値があります——パブリック対プライベート、あるチーム対別のチーム。維持する価値がないのは、1 つの変更を両方にわたって整合させるための手作業の労力です。Kiro Web に GitLab と GitHub を接続すれば、1 つのプロンプトが変更をエンドツーエンドで一貫させ、それでもあなたはすでに信頼しているプロバイダー上で、きれいな MR と PR をレビューできます。

Kiro Web で GitLab と GitHub を接続し、両方にまたがる変更を試してみてください。Kiro Web は app.kiro.dev で、Pro・Pro+・Power のサブスクライバー向けにプレビュー提供中です。さらに詳しくは GitLab ガイドをご覧になり、次に何がリリースされるかを知るには Kiro Web の changelog をフォローしてください。

【ベータ開始】AWS 認定を最新の状態に保つ新しい方法

Hirokazu Murohashi — Tue, 30 Jun 2026 05:18:39 +0000

本ブログは、2026 年 6 月 23 日に Tom Lawlor によって執筆された「A new way to keep your AWS Certification current 」を翻訳したものです。

AWS 認定は、雇用主、クライアント、チームメイトに対してあなたの能力を証明するものです。クラウドと AI は急速に進化しているため、認定を維持するには、今あなたの役割にとって重要なことに対してスキルを磨き、常に最新の状態を保つ必要があります。

2026 年 6 月 23 日より、今までのように認定試験を再受験する代わりに、AWS Skill Builder 上の厳選されたトレーニングとハンズオンラボを完了することで、AWS 認定を 1 年間延長して維持できるようになりました。

仕組み

認定の有効期限まで 90 日以内になると、あなたは今回追加された再認定方法の対象となります。再認定までの流れは以下のとおりです。

認定を選択する: AWS Skill Builder で「詳しく見る > スキルを検証する > 再認定」に移動し、維持したい認定を選択します。
トレーニングを完了する: 認定ドメインに関連する、進化し続けるトピックをカバーする厳選されたデジタルコースとハンズオンラボに取り組みます。
認定が自動的に延長される: 要件を満たすと、完了日から1年間、認定が延長されます。これは AWS 認定アカウントに即座に反映されます。

アソシエイトレベルの認定の場合、少なくとも 1 つの実践的なアクティビティを含めて 500 ポイントを獲得する必要があります。プロフェッショナルレベルの認定の場合、少なくとも 2 つの実践的なアクティビティを含め、700 ポイントが必要です。認定の有効期限が切れる前に、自分のペースですべてを完了してください。テストセンターの予約も、試験の受験も不要です。

単なる再認定ではなく、スキルを最新に保つトレーニング

コースとラボは、AWS サービスを開発しているのと同じ AWS のエキスパートによって構築されています。何年も前に学んだ内容の焼き直しではなく、今まさにクラウドがどのように進化しているかを反映したトピックをカバーしています。実践的なアクティビティ (ハンズオン) では、実際の AWS 環境で構築、設定、トラブルシューティングを行うリアルなシナリオに取り組みます。認定の維持に費やす時間は、仕事のスキルを向上させる時間でもあるのです。

開始時のサポート対象

本再認定オプションは、以下の認定を対象にオープンベータとして 2026 年 6 月 23 日より利用可能です。

AWS Certified Solutions Architect – Associate
AWS Certified Developer – Associate
AWS Certified CloudOps Engineer – Associate (AWS Certified SysOps Administrator – Associate の維持に利用可能です)
AWS Certified DevOps Engineer – Professional
AWS Certified Solutions Architect – Professional

今年後半には、AWS Certified Data Engineer – Associate、 AWS Certified Security – Specialty、AWS Certified Machine Learning Engineer – Associate を含む追加の認定も対応予定です。

試験ベースの再認定との関係

従来どおり、認定試験の再受験、上位レベルの試験への合格、または (Cloud Practitioner の場合) AWS Cloud Quest の利用による再認定も引き続き可能です。トレーニングによる認定維持は、追加の選択肢であり、継続的かつ実践的な学習を重視するパスです。どちらのパスでも、有効でアクティブな資格が得られます。

認定延長のカスケード(連鎖)

AWS 認定を維持すると、まだアクティブな関連する下位レベルの認定の有効期限も、維持した認定の有効期限に合わせて自動的に延長されます。たとえば、Solutions Architect – Professional を維持した場合、Solutions Architect – Associate も次の有効期限に合わせて延長されます(まだ有効で、1 年以内に期限切れとなる場合に限ります）。

始めるために必要なもの

- 有効な AWS Skill Builder サブスクリプション (個人サブスクリプション、またはチームサブスクリプション)
- 有効期限まで 90 日以内の認定
- 上記のサポート対象認定のいずれか

以上です。上記以外の追加購入も、別途の登録プロセスも不要です。

始め方

AWS Skill Builder にログインし、「再認定」に移動して、対象かどうかを確認し、メンテナンスパスを開始してください。

これは AWS 認定プログラムからの提供であり、AWS Skill Builder の体験を通じて提供されます。これは、AWS 認定があなたとともに進化する次のステップです。クラウドプロフェッショナルが求めてきた、継続的で実践的な学習を通じて資格を継続的に維持することができます。

最新の状態を維持し、認定を維持しましょう。今日から認定資格のメンテナンスを始めましょう。

この体験は現在オープンベータ版です。正式な一般提供の前に体験を改善し続けるため、フィードバックを収集しています。ご意見がありましたら、完了後のアンケートからお知らせください。

翻訳は Technical Instructor の室橋弘和が担当しました。

Amazon ElastiCache 向け Valkey 9.1 のお知らせ

Tsutsumi Hayato — Tue, 30 Jun 2026 01:25:49 +0000

本記事は 2026 年 6 月 29 日に公開された “Announcing Valkey 9.1 for Amazon ElastiCache” を翻訳したものです。

Amazon ElastiCache で Valkey 9.1 がご利用頂けるようになりました。Valkey オープンソースプロジェクトの最新のコミュニティ主導のイノベーションが、ElastiCache 上で低レイテンシーが求められ、高スループットかつ運用要件が厳しいインメモリワークロードを実行するお客様に提供されます。本投稿では、Valkey 9.1 が、要求の厳しいワークロードからさらに高いスループットとメモリ効率を引き出しながら、マルチテナントおよび共有クラスターのデプロイメントに対してより強力な分離を提供する方法について説明します。また、一般的なアプリケーションや運用ワークフローを簡素化する新しいコマンド、エンジンの動作に対するオペレーターの可視性を高める新しいオブザーバビリティ機能、そして ElastiCache が最新の Valkey オープンソースのイノベーションをフルマネージドサービスとして継続的に提供していく方法についても取り上げます。

オープンソースの Valkey コミュニティは、セキュリティ、可観測性、パフォーマンス、効率性、ツールの強化に重点を置いた貢献により、Valkey 9.1 を開発しました。アップストリームリリースの詳細な技術情報については、Valkey 9.1 コミュニティ発表をご覧ください。

大規模環境におけるコストパフォーマンスの向上

Valkey プロジェクトがコストパフォーマンスに注力していることは、大規模な ElastiCache デプロイメントを運用しているお客様にとって極めて重要です。スループット、レイテンシー、メモリ効率におけるわずかな改善でさえ、大きなコスト削減につながる可能性があるためです。例えば、Samsung Electronics は、ElastiCache for Valkey へアップグレードすることで、グローバルサービスに必要なパフォーマンス、信頼性、開発者体験を維持しつつ、約 30% のインフラコスト削減を達成しました。Valkey 9.1 はこの方針を引き継ぎ、ノードあたりのリクエスト処理数を増やし、同じ容量により多くのデータを保存でき、ワークロードのスケールに応じてより予測可能な運用を実現するための機能強化を提供します。

スループットが制約となるワークロードでは、ノードあたりのパフォーマンスが向上することで、既存インフラ上でのトラフィック増加への対応、スケーリングイベントの遅延、または同じリクエスト量を処理するために必要なノード数の削減が可能になります。Valkey 9.1 には、さまざまなワークロードでスループットを向上させる、再設計された I/O スレッディング通信モデルが含まれています。アップストリームの Valkey ベンチマークテストにおいて、Valkey 9.1 は 512 バイトのペイロード、9 つの I/O スレッド、および 10 コマンドのパイプライン深度を使用して、単一サーバーで 1 秒あたり最大 210 万リクエストを達成しました。完全な結果を確認し、バージョン間で比較するには、Valkey Performance Dashboards をご覧ください。また、アップストリームでテストされたワークロードにおいてスループットを最大 17% 向上させる I/O スレッディングの強化も含まれています。

Valkey 9.1 では、一般的な高スループットのアクセスパターンのパフォーマンスも向上しています。これには、XRANGE と XREVRANGE による高速なストリーム範囲読み取り、キャッシングワークロードにおける高スループットの文字列読み取り、リーダーボードやスケジューラ向けの高速なソート済みセットクエリ、そしてクライアント初期化のオーバーヘッドを削減するキャッシュ済み COMMAND レスポンスが含まれます。

メモリバウンドなワークロードでは、メモリ効率の向上により、同じノードサイズでより多くのデータを保存できます。また、アプリケーションの動作を変更することなく、メモリ圧迫を軽減することも可能です。Valkey 9.1 では、128 バイト未満の STRINGS のメモリ使用量が最大 20% 削減され、ソート済みセットのメモリ使用量が最大 10% 削減されます。これらの削減は、大量の小さなキャッシュ値、ランキング、スケジュール、レート制限の状態を保存するワークロードにとって特に有用です。

Valkey 9.1 では、内部のリハッシュ動作も改善され、キースペースの拡大時におけるレイテンシーへの影響が軽減されています。さらに、SREM、ZREM、HDEL などのバルク削除操作中には、不要なハッシュテーブルのリサイズが一時停止されます。これらの機能強化により、お客様はスループットの向上、メモリ負荷の軽減、運用の予測可能性の向上を実現し、ElastiCache インフラストラクチャからより大きな価値を引き出すことができます。ビジネスにとっては、インフラコストの削減、トラフィック増加への余裕の確保、ピーク需要時の安心感の向上につながります。エンドユーザーにとっては、パーソナライズされた体験の読み込み、リアルタイムランキングの表示、イベント処理、レイテンシーに敏感な AI 機能との対話など、いずれの場面においても、よりレスポンシブで信頼性の高いアプリケーション体験を提供できるようになります。

マルチテナントワークロードに対するきめ細かなアクセス制御

マルチテナントや共有クラスターのワークロードを運用するチームは、クラスターモードのスケーラビリティと可用性を犠牲にすることなく、アプリケーション、テナント、環境を分離する方法を必要としています。例えば MoEngage は、ElastiCache for Valkey を活用して、世界中の 1,350 以上のブランドにサービスを提供し、毎日数十億のパーソナライズされたメッセージを配信するカスタマーエンゲージメントシステムを支えています。Valkey 9.0 では、クラスターモードにおける番号付きデータベースを導入することでこの課題に対応し、論理的な分離とシャード間の水平スケーリングを両立させました。これにより、クラスターモードのメリットをすべて維持したまま、単一クラスター内でテナントや環境を分離できます。

例として、ユーザーを作成し、データベース 0 と 1 へのアクセスに制限することができます:

ACL SETUSER app-user on >secretpass +@all ~* db=0,1

認証後、そのユーザーはデータベース 0 を操作できます:

SELECT 0
OK

SET mykey "hello"
OK

しかし、データベース 2 にはありません:

SELECT 2
(error) NOPERM No permissions to access database

Valkey 9.1 ではその基盤の上に、データベースレベルのアクセスコントロールリストが追加され、ユーザー権限を特定のデータベースに限定できるようになりました。これまでもアクセス制御ルールによって、ユーザーが実行できるコマンドやアクセスできるキーを制限することは可能でしたが、それらの権限はデータベース全体に広く適用されていました。Valkey 9.1 では、必要なデータベースに対してのみユーザーにアクセス権を付与できます。クラスターモードでの番号付きデータベースとデータベースレベルのアクセス制御を組み合わせることで、より強力な分離とガバナンスを維持しながら、共有クラスターに集約できるワークロードの範囲を広げられます。

新しいコマンドによる一般的なワークフローの簡素化

アプリケーションがスケールするにつれて、一時的な状態の消費、複数の有効期限付きキーの設定、クラスター全体のデータスキャンなどの一般的なワークフローを実装するために、チームはマルチステップのクライアントロジックに依存することがよくあります。これらのパターンは、複雑さを増し、ネットワークのラウンドトリップを増加させ、アプリケーションコードの保守を困難にする可能性があります。

Valkey 9.1 ではこれらのワークフローを簡素化する新しいコマンドが導入されました。HGETDEL は、ハッシュから 1 つ以上のフィールドをアトミックに取得して削除します。これにより、一時的な状態、ワンタイムトークン、キューのようなデータを一度だけ消費するワークフローを構築できます。たとえば、ワーカーは他のジョブメタデータをそのまま残しつつ、ジョブの状態を 1 つのコマンドで取得して削除できます。

HSET job:42 status "pending" payload '{"action":"send_email"}' retries "3"
HGETDEL job:42 FIELDS 2 status payload

MSETEX は、共有の有効期限を持つ複数のキーを 1 つのコマンドで設定します。これにより、セッションキー、キャッシュフラグメント、レート制限バケット、その他一時的なアプリケーション状態を一貫した TTL で書き込むようなパターンが簡素化されます。

MSETEX 3 session:abc "user:1" session:def "user:2" session:ghi "user:3" EX 3600

Valkey 9.1 では CLUSTERSCAN も導入されており、クラスター全体でキーをスキャンするための統一された方法が提供されます。これまではクライアントが各ノードを個別にスキャンし、結果をマージする必要がありました。CLUSTERSCAN は、キーを反復処理するためのクラスター全体のインターフェイスを提供することで、クラスター対応の運用ツール、デバッグ、インベントリジョブ、移行ユーティリティを簡素化します。

CLUSTERSCAN 0 MATCH "session:*"

これらのコマンドを組み合わせることで、開発者や運用担当者は一般的なワークフローをより直接的に表現でき、クライアント側の複雑さを軽減し、大規模なクラスターモード有効デプロイメントとより自然に連携するアプリケーションやツールを構築できます。

大規模デプロイメントにおけるオブザーバビリティの向上

Valkey 9.1 では、大規模なデプロイをより効果的に運用できるようにする可視性の改善も新たに追加されています。新しいメインスレッドおよび I/O スレッドの使用率メトリクスにより、エンジンの稼働状況をより明確に把握できるようになり、実際のワークロードによる負荷と想定内のスレッド動作を運用者が見分けやすくなります。

本リリースでは JSON 形式のサーバーログも追加され、カスタムパースロジックなしでオブザーバビリティプラットフォームにエンジンログを取り込み、検索、分析することが容易になります。

これらの機能強化により、チームはクラスターのチューニング、パフォーマンス問題の調査、大規模な ElastiCache デプロイの管理をより自信を持って行えるようになります。

まとめ

Amazon ElastiCache 向け Valkey 9.1 は、高性能キャッシュからリアルタイム性・共有性・運用面での要求が厳しいアプリケーションを支えるより広範な基盤へと、Valkey の進化をさらに推し進めるものです。ノードベースのクラスターを運用するお客様にとって、このリリースはインフラストラクチャの効率向上、ワークロードの分離強化、アプリケーションやツールの複雑さの軽減、そして大規模なデプロイをより高い信頼性で運用することに役立ちます。

まずは以下を試してみましょう:

初めての Valkey 9.1 キャッシュを作成する: 新しいキャッシュを起動するには、ElastiCache 入門チュートリアルを参照してください。
既存のクラスターをアップグレードする: Valkey または Redis OSS を実行している既存の ElastiCache クラスターをアップグレードするには、エンジンバージョンのアップグレードに関するドキュメントに従ってください。
既存のセルフホストワークロードを ElastiCache に移行する: Valkey または Redis OSS のオンラインマイグレーションを使用して、Amazon EC2 上のセルフホスト型オープンソース Valkey または Redis OSS から Amazon ElastiCache へデータを移行できます。
オープンソースリリースを確認する: 技術的な詳細については、Valkey 9.1 のコミュニティ発表をお読みください。

Amazon ElastiCache 向け Valkey 9.1 は、対応する AWS リージョンにて追加費用なしでご利用いただけます。

著者について

本記事は、Announcing Valkey 9.1 for Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

接客スキルの属人化に悩む企業へ ― プリモグローバルホールディングスがAmazon Bedrock で実現した AI ロールプレイ研修

Genya Koyama — Tue, 30 Jun 2026 01:03:53 +0000

本ブログはプリモグローバルホールディングス株式会社様とアマゾンウェブサービスジャパン合同会社が共同で執筆いたしました。

はじめに

みなさん、こんにちは。古山（アマゾンウェブサービスジャパン合同会社）です。

「新人の接客スキルを底上げしたいが、教える側の負担が大きい」「研修で学んだことを実践する場が足りない」――小売・接客業界で人材育成に携わる方なら、一度はこうした課題に直面したことがあるのではないでしょうか。ブライダルジュエリーの販売を手がけるプリモグローバルホールディングス株式会社様（以下、プリモGHD様）も、まさにこの課題を抱えていました。本ブログでは、AWS の生成 AI 勉強会をきっかけに同社が Amazon Bedrock を活用した AI ロールプレイサービスを導入し、接客研修を変革した取り組みについて、背景から導入効果、今後の展望までをご紹介します。

多くの接客企業が直面する「教育の属人化」という課題

プリモGHD様の販売店では、接客スキルの平準化が長年の課題でした。接客品質がスタッフ個人の経験やスキルに依存しており、店舗間・スタッフ間でばらつきが生じていたのです。新人教育は熟練スタッフが担当していましたが、教育に割く工数が大きな負担となっていました。営業マニュアルや社内レクチャー動画、商品販売のお手本動画など、教育コンテンツは整備されていたものの、それらはインプットが中心であり、学んだ内容をアウトプットする機会が限られていました。同社は社員定着率の向上も重要なテーマとして捉えており、キャリアマップを描きながらスタッフのレベルを段階的に引き上げる仕組みを構築したいと考えていました。同社には「プリモカレッジ」という既存の教育体系があり、この仕組みの中に新たなアウトプットツールを組み込むことが検討されました。

AWS の生成 AI 勉強会が転機に ― Amazon Bedrock を選んだ理由

2024 年末、AWS の古山よりプリモGHD様の全社向けに AI 勉強会を実施しました。この勉強会では、AWS のサービスや当時注目を集めていた生成 AI の活用可能性について紹介しました。勉強会の実施、その後のアンケート調査を通して、同社は生成 AI を活用した AI ロールプレイが自社の接客研修の課題解決に有効であると感じました。インプット中心だった研修に、実践的なアウトプットの場を加えることで、学びの定着を促進できると考えたのです。これを受けて、AWS から Amazon Bedrock を活用した AI ロールプレイサービスを展開するパートナー企業をご紹介し、プリモGHD様・パートナー企業・AWS の 3 社で検討を開始しました。デモンストレーションを実施したところ好感触を得られ、本格的な導入に向けたプロジェクトが動き出しました。Amazon Bedrock を基盤として選択した理由は、シーンやトーンに応じて複数の大規模言語モデル（LLM）を柔軟に使い分けられる点にあります。ブライダルジュエリーの接客では、お客様に寄り添う繊細なコミュニケーションが求められるため、シナリオに応じたモデルの選択が重要でした。

ソリューションの概要 ―短時間でコース草案が作れる AI ロールプレイ

パートナー企業の協力を経て導入した AI ロールプレイサービスは、Amazon Bedrock などを基盤としたクラウドベースの研修ツールです。スタッフは PC やスマートフォンから AI を相手にロールプレイを行い、接客スキルを実践的に磨くことができます。このサービスの特徴は、研修コースの作成が容易な点です。シーン設定を入力するだけで AI が自動的にシチュエーションを生成し、コース草案の作成にかかる時間はわずか 5 分程度です（音声認識や論点抽出などの処理時間を除く）。これにより、研修担当者は多様な接客シナリオを素早く準備し、草案を元に現場の接客ノウハウを持つトレーナーとの協議を行うことができます。

技術的な構成と工夫 ― 多様な接客シーンへの対応

Amazon Bedrock による LLM の使い分け: シーンやトーンに応じて最適な LLM を選択できるため、カジュアルな来店対応から、プロポーズリングの相談といった情緒的な場面まで、多様な接客シナリオに対応が可能です。ロールプレイという特性上、最新のLLMを使うこと必ずしも正しいわけではないため、シーンに合わせて適切なLLMを選択しています。音声認識との連携: スタッフの発話を音声認識で取り込み、AI がリアルタイムに応答することで、実際の接客に近い体験を提供します。

AI によるフィードバック機能: ロールプレイ終了後、AI が論点を抽出しフィードバックを提供します。スタッフは自身の改善点を客観的に把握でき、次の練習に活かすことができます。また、フィードバックの内容については、新人スタッフの方たちも使用することから、まずは「上手くいっていることを褒める」という形に調整して現場での利用を促しました。

使うほど実感が深まる ― 利用回数と満足度の正の相関

導入後、5 段階評価のアンケートを実施した結果、教育効率化に対する評価が高いことが確認されました。高評価を得た上位 3 項目は以下の通りです。

1. 後輩への推奨: 自分が体験して良かったと感じ、後輩にも勧めたいという声

2. フィードバックの納得感: AI が提供するフィードバックの質に対する高い評価

3. 先輩の負担軽減: 教育担当の熟練スタッフの工数削減への貢献

一方、今後の改善が期待される項目として「コース数の不足」「音声認識精度」「会話の不自然さ」が挙げられました。

特筆すべきは、利用回数と満足度の間に明確な正の相関が確認された点です。1〜2 回の利用者が全体の 44.7% を占め、そのポジティブ率は 56.0% にとどまりましたが、6回以上利用した層では 91% 超の高い満足感を示しています。この結果は、AI ロールプレイが「使えば使うほど効果を実感できるツール」であることを裏付けています。

現場の新人スタッフが語る 3 つの変化

先輩の時間を奪わずに練習できる: 「先輩に申し訳ない」「忙しい先輩にお願いしづらい」という心理的ハードルが解消され、気兼ねなく練習に取り組めるようになりました。失敗を恐れず発言できる: AI が相手のため恥ずかしさや緊張が軽減され、積極的にトライできる環境が生まれました。インプットからアウトプットへの一貫した練習: 研修で学んだ内容を、記憶が曖昧になる前にすぐ実践できる点が高く評価されています。

教育体系への本格組み込みへ ― 今後の展望

プリモGHD様はこの成果を踏まえ、2026 年 4 月からの新入社員向け接客フロー研修において、AI ロールプレイをアウトプットツールとして本格活用を開始しています。既存の教育体系「プリモカレッジ」への組み込みを進め、接客スキルの底上げと教育工数の削減を両立する仕組みの確立を目指しています。今後はコース数の拡充や音声認識精度の向上にも取り組み、より実践的な研修環境の構築を進めていく計画です。

まとめ

本事例は、AWS の生成 AI 勉強会をきっかけに、プリモGHD様自身が社内課題を特定し、Amazon Bedrock を活用した AI ロールプレイの導入に至った取り組みです。接客業における人材育成は、熟練スタッフの暗黙知に依存しがちです。生成 AI を活用することで「いつでも・何度でも・気兼ねなく」練習できる環境を実現し、インプット中心だった研修にアウトプットの場を加えることができます。利用回数と満足度の正の相関は、継続的な活用を促す仕組みづくりが成功の鍵であることを示しています。

接客スキルの平準化や教育工数の削減に課題を感じている企業の皆様は、ぜひ AmazonBedrock の活用をご検討ください。AWS では、生成 AI を活用した業務改善についてのご相談を承っています。

Amazon Web Services ブログ

AWS Weekly Roundup: Amazon Connect Customer 向け Agentic CX Designer、EC2 AMI ウォーターマーク、MySQL 向けのオープンガバナンスなど (2026 年 6 月 29 日)

ITbook 株式会社様のAWS 生成 AI 活用事例：Amazon Bedrock を活用し、要件文書から提案書を自動生成する仕組みを構築し、提案書のドラフト作成を十日から半日に短縮

お客様の状況と課題

解決策の検討

ソリューションの概要

ソリューションの構成

導入効果：十日分の作業が半日に、思考に使える時間が二倍以上に

今後の展開

まとめ

完全なライフサイクル制御による分離されたサンドボックスの実行: AWS Lambda が MicroVM を導入

著者について

Micah Walter

翻訳者について

齋藤 拓巳

AWS Deadline Cloud の Wait and Save サービスマネージドフリートを使ってみる

サービスマネージドフリート（SMF）のキャパシティ確保の仕組みを理解する

Wait and Save によるスマートスケジューリング

前提条件

専用キューの作成

Wait and Save フリートの作成

Wait and Save キューへのジョブ投入

Deadline Cloud Monitor でジョブのステータスとコストを確認する

Wait and Save 専用セットアップによるコスト削減

キャパシティとコストを最適化する自動ハイブリッドフリートのセットアップ

クリーンアップ

まとめ

参考資料

著者について

AWS マネジメントコンソールへのアクセスを想定するネットワークに制限

コンソールサインインアクセスを企業ネットワークに制限する

前提条件

ステップ 1: リソース許可ステートメントを作成する

ステップ 2: アカウントのサインインポリシー適用を有効にする

実装の検証

シナリオ 1: 企業ネットワークからの許可されたサインイン

シナリオ 2: 想定外のネットワークからの拒否されたサインイン

RCP による大規模展開

Console Private Access とデータ境界による拡張

まとめ

Agent Focus の紹介

Agent Focus でできること

これは実験であり、慣れ親しんだ IDE はそのまま残ります

切り替え方法

入手方法

1 つのタスク、2 つのプロバイダー(GitLab と GitHub) をまたぐ変更を 1 セッションで調整する

2 つの場所に存在するコード

小さな例

1 つのプロンプト、両方のリポジトリ

まとめ

【ベータ開始】AWS 認定を最新の状態に保つ新しい方法

仕組み

単なる再認定ではなく、スキルを最新に保つトレーニング

開始時のサポート対象

試験ベースの再認定との関係

認定延長のカスケード(連鎖)

始め方

Amazon ElastiCache 向け Valkey 9.1 のお知らせ

大規模環境におけるコストパフォーマンスの向上

マルチテナントワークロードに対するきめ細かなアクセス制御

新しいコマンドによる一般的なワークフローの簡素化

大規模デプロイメントにおけるオブザーバビリティの向上

まとめ

著者について

接客スキルの属人化に悩む企業へ ― プリモグローバルホールディングスがAmazon Bedrock で実現した AI ロールプレイ研修

はじめに

多くの接客企業が直面する「教育の属人化」という課題

AWS の生成 AI 勉強会が転機に ― Amazon Bedrock を選んだ理由

ソリューションの概要 ―短時間でコース草案が作れる AI ロールプレイ

技術的な構成と工夫 ― 多様な接客シーンへの対応

使うほど実感が深まる ― 利用回数と満足度の正の相関

現場の新人スタッフが語る 3 つの変化

教育体系への本格組み込みへ ― 今後の展望

まとめ

齋藤拓巳