Kiro 好きの Solutions Architect の吉村です。普段はヘルスケア業界のお客様の技術支援に加えて、業界問わず Developer Experience に関するご支援をさせていただいております。 本記事では、医療情報システム開発で避けて通れない数多くの業界ガイドラインに対して、Kiro を医療情報システム開発をよく理解したチームの一員へと育て上げ、一緒に立ち向かうというアプローチをご紹介します。本アプローチは、 第 30 回日本医療情報学会春季学術大会 の AWS ブースや AWS Summit Japan 2026 のヘルスケアブースでのデモ展示で、来場者の皆様と議論し、好意的なフィードバックをいただいたものをベースにしています。 はじめに 医療情報システムの開発には、 医療情報システムの安全管理に関するガイドライン 第 7.0 版 （いわゆる 3 省 2 ガイドラインの 1 つで、厚生労働省が定めるもの。以降「医療情報ガイドライン」）や、 電子カルテの標準仕様 、公共 SaaS 要件 ( GCAS ガイド ) など、参照するべき業界ガイドラインが数多く存在します。医療領域で AI を使おうとする多くの開発現場が「AI 駆動開発でスピードを上げたいけど、大量の業界ガイドラインをどう扱えばいいのか」という悩みに直面します。 今回のアプローチは、AI 活用のベストプラクティスを組み合わせた実験的なもので、皆さんの組織やプロジェクトに合わせて取捨選択・カスタマイズして使うことを前提とします。本記事では Kiro の Agent Skills と Agent Steering で具体化しますが、本質は動的に読み込める知識と開発ルールを与えることにあります。そのため Claude Code など他のコーディングエージェントでも応用でき、皆さんの普段の開発に後付けで組み込めます。 医療情報システム開発で AI 駆動開発がぶつかる壁 規制やガイドラインの多い医療ドメインでは、AI 駆動開発にまつわる様々なアンチパターンに遭遇することがしばしばあります。具体的なアプローチに入る前に、まずは私たちがぶつかる壁を整理します。 AI 駆動開発における課題 大規模言語モデル (LLM) には、コンテキストウィンドウ（エージェントが一連の作業の中で参照できる情報の枠）があります。ここにはシステムへの指示、会話の履歴、読み込んだファイル、ツールの実行結果などが収まり、その容量はトークン量で決まる有限の予算のようなものです。コンテキストウィンドウが大きくなればそれだけ多くの情報を投げ込めて、より良い結果が得られると考えがちですが、実際はそう単純ではありません。入力が長くなるほどパフォーマンスが低下することが、近年さまざまな研究で報告されています。 Chroma が 2025 年に公開した技術レポート 「Context Rot: How Increasing Input Tokens Impacts LLM Performance」 で、入力長が増えると単純なタスクでも性能が大きく変動すると報告しています。 We observe that model performance varies significantly as input length changes, even on simple tasks. Nelson F. Liu 氏らが 2023 年に発表した研究 「Lost in the Middle: How Language Models Use Long Contexts」 では、関連情報が長いコンテキストの中間に置かれると見落とされやすい傾向が報告されています。 significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models. Philippe Laban 氏らが 2025 年に発表した研究 「LLMs Get Lost In Multi-Turn Conversation」 は、指示が曖昧なまま会話がマルチターン化すると、トップクラスのモデルでも性能が低下する。一度誤った仮定を置くと、その後もそれに固執して立て直せなくなる傾向があると報告しています。 when LLMs take a wrong turn in a conversation, they get lost and do not recover クラウド上のワークロードを設計・運用するためのベストプラクティス集である AWS Well-Architected Framework の Agentic AI Lens でも、今のタスクに必要なものだけを組み立て、残りは圧縮・要約することをベストプラクティスとして挙げ、会話履歴やツール定義を毎回すべて詰め込むことをアンチパターンとしています。 これらは、曖昧な指示が AI を不要な仮定へと突き進ませるという現場の実感とも重なります。さらに不要・冗長な情報を詰め込めば、いわゆる AI slop と呼ばれる質の低い出力やハルシネーションを招きます。結果として、指示の質によって成果物の品質に差が生まれます。 医療情報システムにおける課題 こうした一般的な問題に、医療領域ではドメイン固有の事情が重なります。まず、参照するべき業界ガイドラインが大量にあります。医療情報ガイドラインだけを見ても、 概説編 ・ 経営管理編 ・ 企画管理編 ・ システム運用編 ・ 保守委託機関編 の 5 編から成り、全体で 160 ページを超えます。医療情報ガイドライン全体の概要は、AWS ブログ「 医療情報ガイドラインをクラウド上で実践する -概要編- 」でも解説しています。さらに標準仕様に準拠した電子カルテの開発では、GCAS ガイドや電子カルテの標準仕様書の遵守が必要で、Web ページや大量の PDF・エクセルなど形式もさまざまです。これらを人間がすべて理解して AI に的確に指示するのは、簡単ではありません。 ここで 1 つ皆さんにクイズです。Kiro IDE は添付したドキュメントをネイティブのドキュメントブロックとして読み込むことができますが、「医療情報ガイドラインのうち、システム運用編という 1 編だけを添付したら、Claude Opus 4.8 の 100 万トークンのコンテキストは何割くらい埋まるでしょうか？」 Claude Opus 4.8 で医療情報ガイドラインのシステム運用編を添付した直後のコンテキスト消費量 実際に Claude Opus 4.8 で試すと、 この 1 編だけで対話開始時点のコンテキストの約 29% が消費されました。全 5 編ではさらに膨らみ、加えて開発標準や MCP も読み込まれると、やり取りできる余地はますます狭まります。コンテキスト上限に近づくと、多くのコーディングエージェントでは内容が自動的に圧縮 (コンパクション) されます。このことからも、ドキュメントを「とにかく全部 AI に渡す」のは筋が悪く、「必要なときに、必要な情報を、必要な分だけ」渡すべきです。 そして、最終的な妥当性を担保し、責任を持つのは人間です。ドキュメントを与えずに指示を出す場合、その人の理解度がそのまま AI への指示の正確さと出力の精度を左右します。結果として、関わるロールや習熟度によって、指示や成果物の品質に差が生まれやすくなります。 医療情報システムの AI 駆動開発が直面する課題 Kiro をチームの一員に育て上げる ここまで見てきた課題に立ち向かうために、Kiro を「医療情報システム開発をよく理解したチームの一員」に育て上げます。医療情報システム開発に必要な知識と組織の開発の進め方を少しずつ授けていきます。 Kiro とは Kiro は、AI にコードを書かせるだけの段階を越えて、エージェントと協働してソフトウェアを設計・実装する、agentic engineering のための開発環境です。プロンプトから実行可能な仕様 (Spec) を起こす 仕様駆動開発 や、複数のエージェントによる並行作業などを特徴とし、今回活用する Agent Skills・Agent Steering のほか、 MCP ・マルチモーダル入力・ ドキュメント添付 といった機能を備えています。 アプローチの全体像 本記事では、[企画] → [準備] → [開発] → [改善] という 4 つのフェーズに沿って、ソフトウェア開発ライフサイクル (SDLC) 全体を通してこのアプローチを見ていきます。 [企画] Kiro と壁打ちしてアイデアを言語化 [準備] ガイドラインの知識を Agent Skills として与え、コンテキストを構築 [準備] 開発標準やルールを Agent Steering として与え、ハーネスを構築 [開発] 要件定義から設計・実装・テスト・デプロイなど、SDLC 全体を Kiro と一緒に推進 [改善] 開発で見えた学びやプロダクトの成熟度に応じて、知識やハーネスを洗練 企画・準備・開発・改善の 4 フェーズと、各フェーズ共通の制御ループ この 4 つのフェーズに共通して、人間と AI が交互に手を動かしながら、以下の制御ループを繰り返します。 人間が AI にタスクを依頼 AI が計画を作成 人間がレビュー AI が計画を見直し 人間が計画を承認 AI が計画を実行 人間が AI の成果物を検証 このループを各フェーズで回すことで、Kiro に丸投げするのではなく、人間が意思決定権と監督責任を持ち続けます。 しかし、人間の意図は曖昧性をはらんでいます。出発点が曖昧になると AI は不要な仮定を置き、望んでいない方向へ進み始めます。この曖昧性をできる限り排除するために、Kiro が作成する計画の中に、曖昧な部分についての逆質問を含めさせます。曖昧なまま進めず、不明点を [Question] として挙げさせ、人間が [Answer] で意図を伝え、独自の判断で先に進ませません。計画に合意してから実行に移すことで、曖昧な指示による手戻りを未然に防げます。 AI に逆質問させるプロンプト例。不明点を [Question] で挙げさせ、人間が [Answer] で意図を伝える それでは、各フェーズを具体的に見ていきます。 [企画] Kiro と壁打ちして構想を固める これから作るものの構想を、Kiro と壁打ちしながら言語化します。漠然としたアイデアを整理し、ビジネスチームとエンジニアチームが同じ言葉で議論できる共通認識をつくります。 このとき活躍するのが、Kiro のマルチモーダル入力です。ホワイトボードのラフな構成図や手書きのスケッチ、画面イメージなど、言語化しにくいものを画像で渡し、Kiro と対話しながらドキュメントへ落とし込めます。 あわせて、構想の実現可能性や業界の動向も Kiro と一緒に調べ、技術的な選択肢や懸念点を洗い出しながら具体化します。ここでも制御ループが効き、計画段階での逆質問で曖昧な構想の穴を早めに埋められます。 [準備] ガイドラインの知識を Agent Skills として与える ここからが、Kiro へ開発に必要なコンテキストを与えるフェーズです。 まずは、医療情報システム開発に必要なガイドラインの知識を Agent Skills として用意します。スキルは動的に読み込まれるので、Kiro は常に全文を抱え込むのではなく、そのとき必要な知識だけを読み込んで参照します。大量のガイドラインで最初からコンテキストを圧迫することなく、「必要なときに、必要な情報を、必要な分だけ」読み込みます。 スキルの作り方はシンプルで、Kiro 自身にスキルを作らせます。医療情報ガイドラインのような PDF はドキュメントとして直接添付し、GCAS ガイドのように Web で公開されている情報はビルトインの web_fetch ツールでコンテキストに取り込みます。あとは全体像で触れた制御ループに沿って、どんな粒度で分割すべきかを Kiro に計画させ、曖昧な部分は質問させて詰めたうえで、計画を承認してからスキルを生成、成果物を人間がレビューします。 たとえば、ネットワークや認証、データ管理、セキュリティといったトピックごとのスキルに分割し、 SKILL.md にどんな場面で参照すべきかという説明を、 references フォルダに詳細な要件をまとめた参照ファイルを配置します。 [準備] 開発標準を Agent Steering として与える スキルで知識を渡したら、次は開発の進め方を Kiro に教えます。Agent Steering は、ワークスペースの標準やアーキテクチャ、コーディング規約といった前提を Markdown ファイルに定義しておくと、セッションのたびにユーザーが指示しなくても自動的にコンテキストへ読み込まれる仕組みです。プロダクト概要 ( product.md )、技術スタック ( tech.md )、プロジェクト構造 ( structure.md ) といった基盤ファイルや、コーディング規約などの独自ファイルを用意できます。 ここでハーネスという考え方を取り入れます。ハーネスとは、AI を信頼できる開発の担い手にするために、その周りに用意する仕組みです。どれだけ高性能なモデルでも、それ単体で常に期待どおりに動くとは限りません。適切なコンテキストを渡し、進め方や守るべきルールを与え、振る舞いを制御し、出力を検証する。こうした足場を整えてはじめて、AI に開発の一員として安心して任せられるようになります。 ハーネスは単一の機能ではなく、複数の要素の組み合わせです。たとえば、知識を与える Agent Skills、開発の進め方や規約を効かせる Agent Steering、外部のツールやデータへ安全につなぐ MCP、成果物を機械的に検査するテストや静的解析などです。Agent Steering はこれらのピースの一つです。 最初から完璧に作り込む必要はありません。小さく始めて、開発を回しながら見えてきた学びを少しずつ反映したり、プロジェクトの成熟度に合わせて洗練させていくのが現実的です。 たとえば、すでに組織の開発標準や設計方針がドキュメント化されているなら、それらを入力に Kiro と一緒に Agent Steering へ落とし込めます。まだなければ、制御ループの中で Kiro に組織の開発プロセスのあるべき姿を深掘りさせ、一緒に形にしていくこともできます。これらをプロジェクトのハーネスの出発点にすることができます。 ここまで見てきた Agent Skills も Agent Steering も、その実体は Markdown ファイルです。そのため、ソースコードと同じように Git などのバージョン管理ツールで変更を追跡でき、GitHub などを通じてプロジェクトのメンバー全員へ配布できます。こうして育てた Kiro のコンテキストとハーネスは、チームの共有資産として扱えます。 [開発] 整えた土台の上で、Kiro とともに開発する 準備フェーズまで終えると、実は開発フェーズで新しくお伝えすることは、それほど多くありません。ここまで整えてきたコンテキストとハーネス、そして制御ループの上で、皆さんの組織の開発プロセスと設計手法に沿って開発を進めるだけです。 ただし、これは従来どおりの開発を行うだけではありません。Kiro とともに AI ネイティブな開発へとシフトします。人間は実現したい意図を Kiro に伝え、制御ループの中でその意図を一緒に洗練し、コードやドキュメントを書く作業そのものは Kiro に任せます。そのうえで人間は、生成された成果物をレビューし、最終的な意思決定と監督責任を担う立ち回りへと移ります。 開発の進め方そのものは、組織やプロジェクトによってさまざまです。たとえば、チームのための AI ネイティブな開発方法論である AI-DLC を実践するために、OSS で公開されている補助ツール AI-DLC Workflow をベースにしたとします。AI-DLC は Inception・Construction・Operations の 3 つのフェーズからなり、クロスファンクショナルなチームがモブワークで AI と協働し、AI の提案をその場で検証しながら進めるのが特徴です。 要件定義のフェーズ (Inception) では、ユーザーに届けたい価値を起点にユーザーストーリーや受け入れ基準を定義し、並行開発できる単位へとタスクを分解します。 設計・実装のフェーズ (Construction) では、詳細設計から実装、テストへと進めます。このとき Kiro は、準備フェーズで与えたガイドラインの知識や開発標準を参照しながら、成果物を生成します。これらの成果物を人間が検証していきます。 ただし、AI-DLC Workflow はあくまで一例です。重要なのは、皆さんの組織固有の開発プロセスそのものを Kiro に教え、AI ネイティブなプロセスへと変革させていくことです。 AI-DLC については「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」をご参照ください。 [改善] ハーネスを育て続ける ここまで構築してきたコンテキストとハーネスは、一度作って終わりではありません。開発で得た学びやプロダクトの成熟度に応じて、コンテキストとハーネスの 2 つの面から育て続けます。 まず、Kiro に与えた知識（コンテキスト）を最新に保ちます。医療情報ガイドラインのように、規制やガイドラインそのものが改定されることもあります。こうしたとき、改定版を読み込ませて変更点を整理し、該当する Agent Skills を更新すれば、最新の内容に追従し続けられます。膨大な改定内容の読み込みと差分の整理を、Kiro は人間よりはるかに高速にこなせます。これが、規制やガイドラインの多い医療ドメインで、AI ネイティブな開発を行う意義でもあります。 あわせて、開発を支える仕組み（ハーネス）も強化します。たとえば SAST (静的解析) やテストを整備し、ガイドライン遵守・セキュリティ・品質の観点を継続的に検査できるようにします。さらに Kiro の Agent Hooks を使えば、ファイルの保存やタスクの完了といったイベントをきっかけに、これらの検査やレビューを自動で実行できます。手作業の抜け漏れやセキュリティ上の見落としを、仕組みで防げるようになります。 こうしてコンテキストとハーネスが育つほど、Kiro は医療情報システム開発を理解したチームの一員として、ますます頼れる存在になっていきます。 このアプローチの何が嬉しいか ここまで、Kiro をチームの一員に育て上げる流れを見てきました。このアプローチがもたらす効果を整理します。 1 つ目は、開発に関わる全ロールが「同じ前提を備えた Kiro」と協働できることです。医療情報システム開発に必要な知識も開発標準も Kiro 側に持たせているため、それらを参照するのは人間ではなく Kiro です。企画担当も設計者も実装者も QA も、同じ知識とハーネスを備えた Kiro を相棒にできます。これにより、人間が的確な指示を出す難しさや曖昧さを、組織全体で減らせます。 2 つ目は、いま使っている開発プロセスに後付けできることです。このアプローチの本質である Agent Skills と Agent Steering は Markdown ファイルにすぎません。そのため、既存のワークフローやツールチェーンを置き換える必要はなく、非侵襲的に組み込めます。ゼロから作り直さなくてよいので、導入のハードルも低いです。 そして 3 つ目は、組織全体の AI 活用のバーを引き上げられることです。こうして育てた Kiro は、組織全体で共有できます。AI はあくまで人の力を増幅する Amplifier であり、担当者ごとの個人差そのものがなくなるわけではありません。ただ、知識もハーネスもない素の状態に比べれば、どの役割の人もより良い結果にたどり着きやすくなります。 まとめ 本記事では、医療情報システム開発で避けて通れない数多くの業界ガイドラインに対して、Kiro をチームの一員に育て上げて一緒に立ち向かうアプローチをご紹介しました。大量の業界ガイドラインを抱え込んでコンテキストを圧迫するのではなく、ガイドラインの知識を Agent Skills として与え、開発標準を Agent Steering として最初のハーネスを組み込み、制御ループの中で人間が意思決定権と監督責任を持ちながら Kiro と協働する。その土台作りと洗練を重ねることが、このアプローチの核です。 冒頭でも触れたとおり、このアプローチは確立された方法ではなく、AI 活用のベストプラクティスを組み合わせた実験的なものです。だからこそ、皆さんの組織やプロジェクトに合わせて取捨選択し、カスタマイズしていただければと思います。本質は動的に読み込める知識と開発ルールを与えることなので、いま使っているコーディングエージェントや開発プロセスに後付けで試せます。まずは小さなスキルやステアリングを 1 つ作るところから、Kiro と一緒に始めてみてください。 皆さんの開発現場で Kiro が頼れるチームの一員になることを願っています。そしてより良い医療情報システムをより早く提供できる未来を信じています。 著者について Hiroaki Yoshimura AWS Japan のパブリックセクターのソリューションアーキテクトです。ヘルスケア領域のお客様への技術的なご支援と、業界を問わずお客様の Developer Experience に関わるご支援を行っています。また、Kiro に関する ブログ投稿 やイベント登壇も行っています。

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 株式会社 様と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月に開発を開始しました。 アカウントマネージャー 尾形龍太郎

本記事は、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 などのサーバレスのサービスが好きです。

本記事は 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 テンプレートの オープンソースサンプル もご覧ください。 著者について Isha Satpalkar Isha Satpalkar は AWS でデジタルコンテンツ制作のための製品開発に携わるソフトウェアエンジニアです。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は Visual Compute SSA 森が担当しました。原文は こちら をご覧ください。

本ブログは 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 を参照してください。 Swara Gandhi Swara Gandhi は、AWS Identity Solutions チームのシニアソリューションアーキテクトです。安全でスケーラブルなエンドツーエンドのアイデンティティソリューションの構築に取り組んでいます。アイデンティティ、セキュリティ、クラウドに関するあらゆることに情熱を注いでいます。 Rishi Tripathy Rishi は、AWS Identity and Access Management (IAM) チームのプリンシパルプロダクトマネージャーです。企業が大規模に AWS 環境を保護するのに役立つアクセス制御メカニズムに焦点を当てています。導入が簡単で誤設定しにくいセキュリティプリミティブの構築に情熱を注いでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は「 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 を開き、いくつかセッションを動かして、気づいたことを私たちに教えてください。

本記事は「 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 をフォローしてください。

本ブログは、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 の 室橋 弘和 が担当しました。

本記事は 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 リージョンにて追加費用なしでご利用いただけます。 著者について Mas Kubo Mas は AWS のインメモリデータベースチームのプロダクトマネージャーで、Amazon ElastiCache のオープンソース高性能データストアエンジンである Valkey を担当しています。仕事以外では、フリーダイビング、パラグライディング、カイトサーフィン、セーリングを通じて風と海を追いかけています。 本記事は、 Announcing Valkey 9.1 for Amazon ElastiCache を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

本ブログは プリモグローバルホールディングス株式会社 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 はじめに みなさん、こんにちは。古山（アマゾン ウェブ サービス ジャパン合同会社）です。 「新人の接客スキルを底上げしたいが、教える側の負担が大きい」「研修で学んだことを実践する場が足りない」――小売・接客業界で人材育成に携わる方なら、一度はこうした課題に直面したことがあるのではないでしょうか。ブライダルジュエリーの販売を手がけるプリモグローバルホールディングス株式会社 様（以下、プリモ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 を活用した業務改善についてのご相談を承っています。

本ブログは、キヤノンITソリューションズ株式会社とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさま、こんにちは。AWS ソリューションアーキテクトの戸塚、大久保、寺山です。 Amazon および AWS は、 The Climate Pledge を通じた2040 年までのネットゼロカーボン達成のコミットメントや、再生可能エネルギー活用の拡大などを通じて、事業運営に サステナビリティを組み込む取り組み を継続しています。ホテル・外食産業や流通小売業界等では、需要予測や在庫最適化によるフードロス削減が環境負荷の低減と収益性向上の両面で重要性を増しており、AWS ではフードロス削減を支援するアーキテクチャやお客様事例をご紹介しています。こうした文脈の中で、 Chronos-2 は、事前学習済みの時系列基盤モデルによるゼロショット推論を活用することで、個別モデル学習を必要とせず、計算リソースを抑えながら高精度な需要予測を実現します。さらに推論基盤として AWS Graviton プロセッサ搭載インスタンスを組み合わせることで、価格性能比および電力効率に優れた構成を採用でき、 Well-Architected Framework の持続可能性の柱 にも配慮したアーキテクチャとして、二酸化炭素排出量の抑制に貢献することが期待できます。 本ブログでは、こうした取り組みの一例として、キヤノンITソリューションズ様と共同で取り組んだ Chronos-2 による需要予測を起点としたフードロス削減 PoC について、アーキテクチャと技術的なポイントをご紹介します。 本取組の背景 令和 5 年度の日本全体のフードロスは約 464 万トンであり、そのうちホテルを含む外食産業由来のフードロスは約 66 万トンを占めています。中でもホテル業界では、以下のような特徴からフードロスが発生しやすい環境にあり、長年に渡り業界全体の課題となっていました。 ビュッフェ提供における過剰提供・見栄え重視 婚礼・宴会における需要変動の大きさ 宿泊客数の予測不確実性 サービス品質重視による欠品 NG の文化 ホテル業界では、仕入れ・調理・提供・食べ残しといった各工程でフードロスが発生する上に、昨今では SDGs への取り組みを企業側に期待する宿泊客も増加しています。フードロス削減は コスト削減・業務効率化・ブランド価値向上 の観点からホテル経営における重要テーマとなっています。 30 年以上にわたり PMS（※1）を中心としたホテル向けシステムを手掛けてきたキヤノンITソリューションズ株式会社様（以下、キヤノン ITS）にも、近年お客さまから「データはあるが、具体的な削減施策にどう結びつければよいか」という相談が増えています。こうした声を受け、ホテル事業を営むお客さまにご協力いただきながら、Chronos-2 を用いた需要予測によるフードロス削減の PoCに取り組みました。 （※1）「Property Management System（プロパティ・マネジメント・システム）」の略で、「宿泊予約の管理」「客室の管理」「顧客管理」「売上・請求管理」「データ分析」まで、宿泊施設の運営を支援するホテル管理システム フードロス削減のPoCについて すでにホテルにおけるフードロス対策は数多く展開されているものの、持ち帰りや販売など余った料理を活用する方法は食品衛生の観点から、やることに不安を持つお客さまもいます。また、新しい業務が増えることによる現場スタッフの負荷増大の懸念もあります。 そのため、キヤノン ITS は「料理を余らせない」「現場の業務に影響が少ない」アプローチとして需要予測の精度向上による最適な発注量・提供量によるフードロス削減のPoCに取り組みました。 PoCでは、複数のホテルブランドを展開するキヤノン ITS のお客さまにご協力いただきました。このお客さまは、各店舗で発生しているロス量の記録はできていたものの、具体的な対策までは着手ができていませんでした。 そこで、ロス量の実績データを受領して朝食ビュッフェにおける各品目の消費量の予測を試みました。予測には、時系列基盤モデル Chronos-2 を利用しました。 Chronos-2とは Chronos‑2 は、Amazon Science により開発された時系列基盤モデル（Time Series Foundation Model）です。大規模言語モデル（LLM）と同様に、膨大な時系列データで事前学習されており、個別データごとに学習モデルを構築・チューニングすることなく、過去データ（コンテキスト）を入力するだけで予測を実行できる（Zero‑shot forecasting）点が大きな特徴です。 Chronos-Bolt、Chronos も存在しますが、一番の大きな違いは、Chronos-2 では、複数系列・共変量・カテゴリ情報まで扱える「Universal Forecasting」モデルである点です。 今回 PoC で使用するモデルとして Chronos-2 を選定した理由は以下の通りです。 多変量予測 ：多品目 × 短期間データでも予測が可能 商品ごとにモデルを作り直す必要がなく、「クロワッサン・バターロール・ゆでたまご」といった複数品目を同一アプローチで扱える。 共変量付き予測 ：ターゲット（使用量）・日時情報に加えて、曜日・客数・朝食券配布数などの任意の共変量を入力として扱うことが可能 実績データに加え、業務的に意味のある指標を特徴量として投入することで精度向上が見込める ゼロショット予測 ：学習・再学習が不要なため、PoCから運用検討までが非常に短い モデル構築にコストをかけず、業務データを手軽に試すことができる 上記よりホテルの朝食ビュッフェのように「日次・多品目・需要振れが大きい」業務データに適した時系列予測モデルであると判断し、採用しました。 実行環境と検証アプローチ 今回の精度検証では、データ加工・可視化・分析を反復的に行う必要があったため、 Amazon SageMaker AI の Notebook インスタンスを実行基盤として採用しました。Notebook 上では Python 環境を用い、前処理・予測・評価までを一貫して実施しています。 図1：Chronos-2の検証用実行環境 具体的には、CSV や Excel といった時系列データを取り込み、欠損補完や時系列整形などの前処理を行った上で、Chronos-2 を用いた予測処理を実行し、結果の可視化および精度評価を行いました。この一連の流れにより、モデルの挙動やデータ特性を対話的に確認しながら、仮説検証を高速に回すことが可能となります。 Chronos-2 は以下のようにライブラリをインストールすることで簡単に利用できます。 !pip install -U 'chronos-forecasting==2.2.0' # 予測の実行 import pandas as pd from chronos import BaseChronosPipeline from chronos import Chronos2Pipeline pipeline = Chronos2Pipeline.from_pretrained( "amazon/chronos-2", device_map="cpu“, ) test_df = test_df.drop(columns=["使用量"]) predict_df = pipeline.predict_df( train_df, #コンテキストとなるデータ future_df=test_df, # 予測対象のデータ prediction_length=30, # 予測期間 quantile_levels=[0.1, 0.5, 0.9], # 確率的予測のための分位点（Quantiles） id_column="item", # 異なる系列を表すカラム(カテゴリカラムなど) timestamp_column="date", # 時系列情報を表すカラム target="target", # 予測対象となる時系列の値を格納するカラム（複数可） ) PoCから実運用への展開 一方で、Notebook インスタンス上での実行は、PoCや探索的分析には適しているものの、定常的な業務オペレーションとしての運用には必ずしも最適とは言えません。たとえば、定期実行やシステム連携、スケーラビリティといった観点ではより本番環境に適した構成が求められます。 そのため実運用においては、 Amazon SageMaker JumpStart を活用して Chronos-2 モデルを推論エンドポイントとしてデプロイする構成も有効です。これにより、PoC で検証した予測ロジックを業務プロセスへも容易に組み込むことができます。 PoC実施結果 本 PoC では、ご協力いただいたホテル様よりご提供いただいた過去約 3 年分の日次実績データを活用し、朝食ビュッフェにおける主要 3 品目（クロワッサン、バターロール、ゆでたまご）を対象として検証を実施しました。 本検証の特徴として、単に 1 回の予測を行うのではなく、精度がどの要素によって改善されるのかを確認するため、段階的なアプローチを採用し、以下の 3 ステップで検証を進めました。 Step1：最小構成によるベースライン予測 まず最もシンプルな構成として、以下の最小限のデータのみを用いて予測モデルを構築します。 日付 品名 使用量（ターゲット） このステップでは、モデルの性能評価に先立ち特に重要となる「時系列データの整備」を重点的に行いました。 Chronos‑2 では、入力データが一定間隔の時系列として整っていることが前提条件となるため、以下の前処理を行い分析に適したデータセットを整備しました。 品目ごとのデータにおける日付の欠損確認 損日付に対する補完レコードの追加 結果 このベースラインモデルの結果は以下の通りです。 MAPE MAE 80%区間被覆率(※2) 約56.6% 約13.4 約68.9% (※2) 80%区間被覆率とは予測された「80%の確率でこの範囲に収まる」とされる区間に、実測値がどれだけ含まれているかを示す指標 図2：ベースライン予測結果(予測 対 実測) 数値変動の大まかな傾向は捉えられているものの、以下 3 点の実業務における重要な要因を考慮できておらず、 業務で活用するには精度が不十分であることが確認されました。 平日と週末の需要差 宿泊客数による需要変動 直近の消費傾向 Step2：業務データを考慮した予測モデル 次に、実際のホテル業務において使用量を判断する際に利用されている情報を特徴量として追加し予測を行いました。追加したデータは以下の通りです。 前日宿泊者数 朝食券配布枚数 これらの項目は、単なる補助情報ではなく現場において「今日は宿泊者が多いから多めに作る」といった意思決定に直接使用されている重要な指標です。 また、特徴量の選定にあたって以下の観点で絞り込みを行いました。 使用量との相関確認 予測時点で取得可能なデータのみを利用（リーケージ防止） 図3：使用量に対する各特徴量の相関係数 結果 MAPE MAE 80%区間被覆率 約28.3% 約7.1 約78.9% 図4：重要指標を特徴量へ追加後の予測結果(予測 対 実測) ベースラインと比較して、誤差は約50%改善し、以下が適切に反映されるようになりました。 平日／週末の傾向 来客規模の影響 この結果から、業務知識に基づく特徴量の追加が予測精度に大きく寄与することが明確に確認することができました。 Step3：ラグ特徴量による最終的な精度向上 さらに精度向上を図るため、時系列データ特有のパターンである「連続性」と「周期性」をモデルに取り込むことを目的として、ラグ特徴量を追加しました。 本PoCでは、ラグ特徴量の追加を感覚的に行うのではなく、事前に以下の分析を行いました。 自己相関分析 偏自己相関分析 曜日単位の周期性の確認 図5：曜日周期性の確認と自己相関 この結果から、以下のような「連続性」と「周期性」を確認することができました。 「前日の影響を受ける（連続性）」 「1週間単位で繰り返される（曜日周期）」 朝食ビュッフェの需要特性を踏まえた上で、下記の特徴量を追加して予測を行いました。 使用量_lag1（前日の使用量） 使用量_lag7（1週間前の使用量） 結果 最終モデルの結果は以下の通りです。 MAPE MAE 80%区間被覆率 約20.3% 約5.05 約82.2% 図6：ラグ特徴量追加後の予測結果(予測 対 実測) この結果から、 予測精度のさらなる向上 と 予測の信頼性（区間被覆率） の改善実運用への適用が十分に検討可能な水準に到達することが確認できました。また、グラフ上でも、週末の需要ピークや品目ごとの変動特性が再現されており、モデルが単なる数値補間ではなく、需要構造そのものを捉えることができました。 技術的なポイント Chronos-2 における時系列カラムの注意点 Chronos‑2 を利用した時系列予測では、コンテキストとして入力されるデータが「一定間隔の時系列として整備されていること」が前提条件となります。例えば、日次データであれば、時系列カラム×種類カラム(今回の場合は、日付×品目)において、すべての日付が抜け漏れなく並んでいる必要があります。また、予測は、各種類カラムの最終日付から指定した日付分の予測が行われる点にも注意が必要です。 図7：異なる期間のデータを用いた場合の予測対象期間 実運用データでは、非営業日や記録漏れなどにより日付が欠損しているというケースも少なくありませんが、そのまま Chronos-2 に投入すると時系列として正しく解釈されず、エラーが発生する可能性が高いため注意が必要です。 図8：データ抜け日の確認と欠損補完イメージ このため、本 PoC では品目ごとに日付の連続性を確認し、欠損している日については 補完レコード（使用量 0 または NULL）を追加する前処理を行っています。た。Chronos‑2 を活用する際は、モデル以前に「時系列を等間隔に整えるデータ整備」もポイントになります。 リーケージを防ぐ設計 時系列予測や機械学習において注意すべき点のひとつがリーケージ（データリーケージ）です。リーケージとは、予測時点では本来入手できない未来の情報を、誤って特徴量として使用してしまうことを指します。 リーケージが発生すると、一見すると非常に高い予測精度が出るが、実際の業務運用では同じデータが取得できないため、検証時の精度が再現できないモデルになってしまうため注意が必要です。 図9：リーケージの危険性 本 PoC では、「前日終業時点で翌日の朝食使用量を予測する」という業務シナリオを前提とし、前日宿泊者数や朝食券配布枚数など、予測時点で確実に取得可能な情報のみを特徴量として使用しました。機械学習モデリングでも同様ですが、Chronos‑2 を業務に適用する際には、「その情報はいつ取得できるのか？」を意識し、リーケージを防ぐ設計が不可欠です。 ラグ特徴量の有効性 時系列予測では、過去の値が将来の値に影響するという特性をモデルに取り込むため、過去の値をずらして特徴量として使用する「lag 特徴量」がよく用いられます。lag 特徴量を追加することで、直前の傾向（連続性）や、曜日などによる周期的なパターンを表現することができます。 図10：ラグ特徴量のメリットと注意点 本 PoC では、自己相関の結果に基づき、lag1：前日の使用量、lag7：7日前（同じ曜日）の使用量を特徴量として追加しました。 これにより今回の検証では、短期的な増減や曜日単位の周期性を捉えやすくなり予測精度が向上しました。 一方で、lag 特徴量は設定次第でリーケージにつながる可能性があるため、「いつ予測を行うのか」という業務前提を明確にした上で、実運用で取得可能な範囲の lag のみを採用することもが重要になります。 Chronos-2 に関する考察 機械学習モデルの予測精度向上施策を打つことで、Chronos-2 でも同様に予測結果が向上させることが可能 機械学習モデリングの時と同様にコンテキストに含めるデータ項目が多いとより精度向上施策に幅がでて、精度改善に寄与することができる可能性が広がる FineTuningやクロースラーニングなどさらなる精度向上施策を手軽に試せる点も非常に使い勝手が良い 本検証の総括 今回の取り組みを通じ、ホテル業界におけるフードロスは「やむを得ないもの」ではなく、データ活用により削減可能であることを実感しました。現在の、食数予測においてはホテル従業員の経験や勘に依存する部分も多く、その結果として過剰な仕込みやロスが発生しやすい傾向にありましたが、今回の Chronos-2 による需要予測を用いることで需要変動の傾向が可視化され、ロス削減の余地があることが分かりました。 一方で、予測の結果だけですべてが解決するわけではありません。実際の現場では、お客さまへの満足度を考慮してある程度の余剰を持たせる運用が不可欠です。そのため、単に予測結果を提供するのではなく、「予測結果をどう使うか」「どこまでなら調整が出来るか」といった現場に寄り添った運用面もあわせて合わせて考えることが重要です。 今後は、予約状況やイベントなどの外部情報も取り入れながら精度を高めるとともに、予測結果を発注業務などに連携させる仕組みを作ることがより一層重要になると考えます。引き続き、現場に寄り添いながら、ホテル業界全体のフードロス削減に貢献できるよう取り組んで参ります。 まとめと今後の展望 今回の取り組みでは、Amazon Science が発表した時系列基盤モデル Chronos-2 が、ホテルの朝食ビュッフェという「日次・多品目・需要変動が大きい」業務領域において有効に機能することを検証しました。学習不要で即座に予測を開始できることに加え、特徴量の工夫により追加学習なしでも本番業務で活用できる精度に達することを実証しました。これにより、PoC から本番運用への移行を短期間かつ低コストで実現する道筋が示されたと考えています。 AWS では、Amazon SageMaker AI をはじめとする AI/ML サービスを通じて、Chronos-2 のような時系列基盤モデルを本番環境でスケーラブルに運用するための基盤を提供しています。本ブログで紹介した需要予測のアプローチは、ホテル業界に限らず、外食・流通小売・食品製造など、フードロスが課題となる幅広い業種への適用が期待されます。また、こうした需要予測での発生抑制に閉じるのではなく、 スマート廃棄物管理 など多面的なアプローチがフードロス削減を目指す上では不可欠です。 Amazon は、The Climate Pledge を通じて2040年までにネットゼロカーボンを達成することをコミットしており、AWS はその実現に向けて、エネルギー効率に優れたクラウドインフラストラクチャの提供、カーボンフリーエネルギーへの移行推進、そしてお客様のワークロード最適化による環境負荷低減の支援を行っています。本ブログでご紹介した需要予測によるフードロス削減も、テクノロジーを活用した持続可能性への貢献の一つです。同様の取り組みを検討されている皆さまの一助となれば幸いです。 執筆者 キヤノンITソリューションズ株式会社 ホテル業界向けのシステム開発を30年以上手掛けています （左から） 大原 諭 (Satoshi Ohara) 流通業界・サービス業界向けおよびデータマネジメントソリューションのマーケティング・企画担当 大竹 智礼 (Tomonori Otake) データマネジメント領域におけるデータサイエンティストとして、主に流通業界向けのデータ分析、 予測AI、生成AI開発を担当 辻 夏子(Natsuko Tsuji) ホテル業界向けソリューションのマーケティング・商品企画担当。本取り組みの推進リーダー 戸塚 智哉(Tomoya Tozuka) /@tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューションアーキテクトで、AI/ML、IoT を得意としています。最近ではAWSを活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています 大久保 裕太 (Yuta Okubo) 外食業界や飲料メーカーのお客様を支援しているソリューションア―キテクトです。好きなAWSサービスは AWS IoT Core。 最近は、デスクワークによる姿勢の崩れを筋トレで解消しようとしています 寺山 怜志 (Satoshi Terayama) 外食業界や百貨店業界のお客様を支援しているソリューションア―キテクトです。 最近は、時系列基盤モデル Chronos-2 を始めとした機械学習領域での学びを深めています  

2026年2月6日から22日にかけて、イタリアのミラノ・コルティナにて世界的な冬季スポーツ競技大会が開催されました。本ブログでは、株式会社フジテレビジョン様（以下、フジテレビ）がこの大会において、地上波テレビ放送のライブ映像制作を AWS 上で行う「Live Cloud Production（以下、LCP）」を実現した事例をご紹介します。 テレビのライブ放送を支える3つの処理 Live Cloud Production とは、物理的な設備を削減しクラウド上でのライブ映像の制作を可能にする新しい放送・映像制作ワークフローです。Live Cloud Production を理解する上で、一般的なテレビのライブ放送がどのように行われているのかを最初にご紹介します。テレビのライブ放送で視聴者に届ける映像を制作する上で、主に3つの処理がリアルタイムに行われています。 1つ目は映像スイッチングです。スタジオ、競技会場、リプレイなど複数の映像ソースの中から、放送に乗せる映像をリアルタイムに選択・切り替えます。2つ目は音声ミキシングです。各出演者のピンマイク、会場の環境音、BGM、効果音など多数の音声チャンネルを適切なバランスに調整します。3つ目は CG 合成です。テロップ、スコア表示、バーチャルグラフィックスをリアルタイムに描画し、映像に重ね合わせます。従来はこれらの３つの処理は専用ハードウェアによって処理されていました。 図1: 実際のスタジオの様子。競技映像やスタジオセットの上半分などは CG 合成で作られていて、現地での設営を簡略化している。複数ソースからの映像スイッチングや音声ミキシングも行われている。(提供：株式会社フジテレビジョン) 国際中継における課題 海外で開催されるスポーツイベントの中継では低遅延かつ放送品質の安定した映像伝送を行う必要があるため、競技会場と国内のテレビ局の間に専用回線を敷設する必要があります。さらに、前述の3つの処理（映像スイッチング、音声ミキシング、CG 合成）を行うための専用ハードウェアも現地に輸送・設置しなければなりません。現地への機材輸送・設置には数ヶ月の期間を要し、専用回線の費用も含め大きなコストとなっていました。 フジテレビの取り組み — Live Cloud Production 近年は専用ハードウェアが持つ機能のソフトウェア化が進んでおり、ライブ放送に必要な処理（映像スイッチング、音声ミキシング、CG 合成）をオンプレミスのサーバーやクラウド上の仮想サーバーで実行できるようになってきています。 フジテレビは今回の大会で、ライブ放送に必要な処理を行うソフトウェアを Amazon EC2 上で、海外からの映像伝送を AWS Elemental MediaConnect で行い、LCP として AWS クラウドに集約する構成を採用しました。 ミラノの IBC（国際放送センター）に設置したエンコーダーで8台のカメラ映像を H.265 / 20Mbps の SRT (Secure Reliable Transport) ストリームに変換し、帯域保証付きの公衆インターネット回線2本（本番用・予備用）を通じて AWS フランクフルトリージョンに送出します。フランクフルトリージョンの Amazon EC2 上では、Sony M2L-X（映像スイッチング）、Waves Cloud MX Audio Mixer（音声ミキシング）、Vizrt Viz Engine（CG 合成）が稼働し、AWS Elemental MediaConnect がクラウド内外の映像ルーティングを担いました。完成した番組映像は AWS Direct Connect 経由でお台場のフジテレビ本社に SRT で伝送され、地上波で放送されています。クラウド障害時に備えたパリリージョン経由のバックアップパスも構築しました。 図2: Live Cloud Production の全体構成。ミラノ IBC からフランクフルトリージョン、お台場のフジテレビ本社までの映像・音声・制御の全系統を示す。(提供：株式会社フジテレビジョン) この構成により、IBC 側のスタジオにはスイッチャーやミキサーなどのコントローラーやモニターを中心に配置する形となりました。従来のハードウェアの機能をクラウドに移したことで、現地の設備は大幅に簡素化されています。 パリからミラノへ — 1年半にわたる検証 フジテレビと AWS は3年以上にわたり、段階的に LCP の取り組みを進めてきました。 2024年のパリで行われた夏季スポーツ競技大会では、ソニー製ソフトウェアスイッチャー M2L-X を AWS 上で利用する PoCを実施しました。その後、約1年半にわたり、様々なパートナーのソフトウェアを EC2 上で利用するための検証が重ねられました。各ソフトウェアを動かす EC2 間では、NDI (Network Device Interface) という高品質・低遅延の映像・音声データをリアルタイムで相互伝送する伝送方式が使われており、NDI 伝送の検証も進められました。 2025年8月にはフランクフルトリージョンにクラウド環境を構築し、実際のスタジオを使った最終検証を実施。9月末にはミラノ現地の IBC に設置する全機材の仮組みとクラウドシステムの統合検証を完了しました。 本番運用と結果 期間中は、イタリア国内各所で実施された多数の競技中継を LCP で制作しました。全期間を通じて放送品質を維持した安定運用を達成しています。クラウドを経由した全体の遅延は約 1.7 秒に収まり、従来のオンプレミス構成と遜色ない遅延量で制作することができました。 ネットワークコストは、過去大会の専用線費用と比較して 45% 削減されました（現地インターネット回線費用およびクラウドアプリケーションライセンス費用を含む）。また、現地入りからスタジオオープンまでの技術全体のセットアップ作業時間は、従来と比較して 21% 削減されています。 まとめ 今回は、フジテレビが世界的な冬季スポーツ競技大会で LCP を実現した事例についてご紹介しました。今回の実績を踏まえ、フジテレビは今後の国内外のスポーツ中継への LCP 展開を検討されています。 LCP や放送業界での AWS 活用にご関心のある方は、お気軽にお問い合わせください。 著者 北村 友（Yu Kitamura） アマゾン ウェブ サービス ジャパン合同会社 通信・メディア技術本部 ソリューションアーキテクト 放送局をはじめとしたメディア業界のお客様への技術支援を担当しています。

みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も 週刊AWS をお届けします｡ 先週の木曜日､金曜日に AWS Summit Japan 2026 を開催しました｡台風が近づいていた中ではありましたが､多くのお客様にご来場いただきました｡ブースでたくさんのご相談を頂きましたが､AI 活用でどのような利便性があるのか､また､どういった仕組みでガバナンスを担保できるのか､という観点で質問を頂きました｡AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただき次の一歩につながるヒントを得ていただければ幸いです｡ それでは､先週の主なアップデートについて振り返っていきましょう｡ 2026年6月22日週の主要なアップデート 6/22(月) Amazon Connect Customer が Agentic CX designer (NLX) のプレビュー版を提供開始 Amazon Connect Customer は､AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバス「Agentic CX designer (NLX)」のプレビュー版を提供開始しました｡ビジネスチームがコードを書かずに､エージェント型 AI と､本人確認や決済処理などの正確なアクションが求められるフローを組み合わせた音声・デジタル体験を構築できます｡また､通話中に顧客の Web/モバイルアプリをリアルタイムで操作できる Live Sync 機能も同時にプレビュー提供されます｡例えば､AI エージェントとホテル予約を通話している中で､会話内容に基づいて画面が同期して移動し､ホテルの予約を自動的に行うことがやりやすくなる仕組みです｡なお、プレビュー期間中は、ご自身のユースケースに合わせて精度などを検証いただくことが可能です｡ AWS Network Firewall がデフォルト drop action を更新し接続信頼性を改善 AWS Network Firewall は､新規作成するすべてのファイアウォールポリシーで､stateful action のデフォルトを “Application drop established (bidirectional)” から “Application drop established (server-directed only)” に変更しました｡この変更により､TCP window updates､keep-alives､resets などの正当なサーバーからクライアントへの TCP 制御パケットが誤ってドロップされることがなくなり､診断が困難だった断続的な接続障害を回避できます｡既存のポリシーには影響がなく､新規ポリシー作成時に自動的に適用されます｡ AWS Lambda MicroVMs で分離実行環境を提供開始 AWS Lambda MicroVMs を発表しました｡これはユーザーや AI が生成したコードを安全に実行するためのサーバーレスコンピューティング環境です｡VM レベルの分離､ほぼ瞬時の起動と再開速度､最大 8 時間の状態保存機能を提供します｡米国東部 (バージニア､オハイオ)､米国西部 (オレゴン)､アジアパシフィック (東京)､欧州 (アイルランド) で利用可能です｡従来の Lambda 関数がリクエストに応じて自動的にスケールするのに対し､MicroVMs は run-microvm API を呼んだ回数だけ MicroVM が 1 個ずつ起動し､各 MicroVM に専用の HTTPS エンドポイントが割り当てられます｡この「1 エンドポイント＝1 台」という特性を活かせば､ユーザーやセッションごとに独立した実行環境を割り当て､起動・サスペンド・終了のライフサイクルをアプリケーション側で自在に制御できるため､AI エージェントのコード実行サンドボックスやインタラクティブな開発環境のように「状態を保ったまま長時間使い続ける」ユースケースにうまくフィットします｡一方で従来の Lambda 関数は短時間・ステートレスなリクエストを大量にさばく用途に強いので､ワークロードの性質に応じて両者を使い分けるのがおすすめです｡なお､クォータは同時実行数ではなくアカウント・リージョンあたりの合計メモリ量で管理され､run-microvm API のレート制限はデフォルトで 5 TPS（バースト 5）です｡多数の環境を一度に立ち上げたい場合は､あらかじめサスペンド状態でプレウォームしておくと安定して払い出せます｡これらのクォータは Service Quotas コンソールから上限緩和を申請できます｡ 6/23(火) Claude Tag が AWS Marketplace の Claude Enterprise でベータ版として利用可能に Anthropic は､Claude Tag のベータ版を AWS Marketplace 経由で Claude Enterprise を利用する顧客向けに提供開始しました｡Claude Tag は､Slack チャネル内で @Claude とタグ付けすることで､チームメンバーが Claude にタスクを委任できる新機能です｡チャネルごとにアクセス権限と予算を設定でき､Claude は接続されたチャネルの文脈を記憶しながら､ツールやデータ､コードベースにアクセスできます｡管理者は Claude 管理コンソールで約 1 時間でエージェント ID をプロビジョニングし､チャネルごとにスコープを設定します｡ Amazon GuardDuty AI-powered investigations で脅威対応を加速 (Preview) Amazon GuardDuty に AI-powered investigations 機能 (Preview) が追加されました｡この機能は GuardDuty の findings とアカウントを自動的に分析し､真の脅威と誤検知を数分で見分けることができます｡過去 90 日間の関連アクティビティ､影響を受けるリソース､脅威インテリジェンスを knowledge graph を使って分析します｡これまで､GuardDuty の findings を手動で調査するには時間がかかり､アラート疲れ (alert fatigue) の原因となっていました｡AI-powered investigations により､数分で自動分析が完了します｡また､CLI コマンドを含む具体的な修復手順を提供してくれるため､対応のアクションが素早くなります｡ Amazon CloudWatch Logs がマネージド syslog 取り込みに対応 Amazon CloudWatch Logs が VPC エンドポイント経由での syslog 直接取り込みに対応しました｡ファイアウォール､ルーター､スイッチ､Linux サーバーからエージェントをインストールせずに syslog メッセージを CloudWatch Logs へ送信できます｡RFC 5424､RFC 3164､Cisco FTD/ASA の各フォーマットに対応し､facility､severity､hostname､appName などの構造化フィールドを自動的に抽出します｡PrivateLink に対応していて､Direct Connect や Site-to-Site VPN の Private 通信も可能となっています｡ 6/24(水) Amazon CloudWatch でダッシュボードのタグ機能をサポート Amazon CloudWatch がダッシュボードのタグ機能をサポートしました｡これにより､ダッシュボードをチーム､プロジェクト､環境などのカテゴリで整理し､タグベースでアクセス制御を実装できます｡PutDashboard API が Tags パラメータに対応したほか､TagResource､UntagResource､ListTagsForResource API がダッシュボード ARN をサポートし､1つのダッシュボードに最大50個のタグを設定できます｡CloudFormation と AWS Resource Explorer にも対応しており､追加コストなしで CloudWatch が利用可能な全リージョンで提供されます｡ Amazon Route 53 Global Resolver が AWS アカウント間での DNS View 共有をサポート Amazon Route 53 Global Resolver が､AWS Resource Access Manager (AWS RAM) を使用して DNS View を他の AWS アカウントと共有できるようになりました｡Route 53 Global Resolver は､リモート拠点やオンプレミス環境から AWS 上の Private Hosted Zone とパブリックドメインの両方を解決できる､インターネット到達可能な DNS リゾルバーです｡この機能により､consumer アカウントは自身の Route 53 Private Hosted Zone を共有された DNS View に関連付けることで､所有権を移譲せずに owner の Global Resolver を通じて全 AWS リージョンで名前解決できます｡DNS View 共有は追加料金なしで､Route 53 Global Resolver がサポートされている全リージョンで利用できます｡ AWS IoT Device SDK for Swift の一般提供開始 AWS IoT Device SDK for Swift が一般提供 (GA) を開始しました｡Swift 開発者は macOS 12+､iOS 16+､tvOS 16+､Linux 上で AWS IoT サービスを利用した IoT アプリケーションをネイティブに構築できるようになります｡SDK は MQTT 5 プロトコルをサポートし､AWS IoT Device Shadow､Jobs､Fleet Provisioning の統合クライアントを提供します｡iOS と tvOS では TLS 1.3 に対応しており､最新のセキュリティ標準でデータを保護します｡Swift Package Manager 経由でインストールできます｡ Amazon EC2､AMI ガバナンス強化のための AMI Watermarks 機能を発表 Amazon EC2 が AMI Watermarks 機能を発表しました｡この機能により､Private AMI にカスタム識別子を埋め込み､AMI の系譜追跡とガバナンスポリシーの実施が可能になります｡ウォーターマークは AMI のコピーや派生 AMI 作成時に自動的に引き継がれ､リージョン間コピーやアカウント共有でも保持されます｡Allowed AMIs 機能と組み合わせることで､承認されたウォーターマークを持つ AMI のみからインスタンスを起動するよう制限できます｡全 AWS リージョンで追加料金なしで利用可能です｡ 6/25(木) AWS Network Firewall が VisionHeight のマネージド脅威インテリジェンスルールをサポート AWS Network Firewall が VisionHeight 社の 2 つの新しいマネージドルールグループをサポートしました｡AWS Marketplace 経由で利用できる Zero-Day Threat Protection と Noisy Scanners and Tor Protection により､公開ブロックリストに掲載される数週間前に悪意ある IP インフラストラクチャを先制ブロックし､Tor 出口ノードや高頻度スキャンソースからの通信を遮断してファイアウォールログのノイズを削減します｡VisionHeight の Pulse テレメトリーに基づく独自の脅威インテリジェンスを活用でき､日次更新により最新の脅威情報を反映します｡ それでは､また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

本記事は 2026 年 6 月 25 日に公開された Sumitha AP、Rajdeep Mukherjee による “ From OpenAPI/Swagger specifications to test suite in seconds with Kiro ” を翻訳したものです。 API は現代のアプリケーションの基盤です。チームが REST API を構築し改良していく中で、網羅的なテストカバレッジを維持することは継続的な課題となります。 OpenAPI/Swagger 仕様 は、API が どう振る舞うべきか を的確に記述します。エンドポイント、リクエストの形式、レスポンスのスキーマ、ステータスコードなどです。しかし、それらが実際に機能することを証明するものではありません。 そのギャップを埋める作業は、伝統的に開発者の肩にかかってきました。仕様を読み、各エンドポイントをテストケースに落とし込み、正常系とエッジケースを考慮し、テストランナーを組み立て、依存関係をモックし、結果を意味のある形で見せるためのレポート機能を構築します。中規模の API、例えばエンドポイントが 40 個あるとすると、製品コードを 1 行も書く前に 1 週間分の作業が必要です。しかも仕様が安定していることが前提ですが、実際にはほとんど安定しません。 根本的な課題は、API 仕様とそれに対応するテストスイートが独立して保守されていることです。時間が経つにつれ、両者は必然的に乖離していきます。リリース時に書かれたテストはエンドポイントの変更とともに陳腐化し、新しいエンドポイントはテストカバレッジを伴わずにリリースされていきます。 OpenAPI Generator のようなツールは仕様からテストのスキャフォルディングを生成できますが、通常は開発者自身が埋めるためのスタブを提供するだけです。Kiro は別のアプローチを取り、仕様をテスト生成の信頼できる情報源として扱います。OpenAPI/Swagger ファイルを入力すると、Kiro は動作するテストスイート、エンドポイントカバレッジ、エッジケース、スキーマ検証、レポート用スキャフォルディングを、テストファイルをセットアップする時間と同じくらいで生成します。さらに、Kiro は再生成を素早く低コストで行えるようにすることで、テストを仕様と同期させるコストを下げ、フックによってドリフトを早期に検出できます。本記事では、それがどのように機能し、何が生成されるのかを詳しく見ていきます。 Swagger と OpenAPI 仕様 Swagger は、構造化された JSON を使って REST API をドキュメント化する手段として作られました。どんなエンドポイントがあるか、各エンドポイントがどのパラメータを受け取るか、成功時に何を返すか、問題が起きたときに何を返すか、といった語彙を定義します。 最小限の OpenAPI ドキュメントは、各エンドポイントについて、URL パスと HTTP メソッド、受け取るパラメータ（型、位置（location）、必須／任意）、成功時のレスポンススキーマ、ありうるエラーレスポンスとそのコードを指定します。 # openapi.yaml: マシン可読な API の契約 openapi: "3.0.0" paths: /pet/{petId}: get: summary: "Find pet by ID" parameters: - name: petId in: path required: true schema: { type: integer } responses: "200": content: application/json: schema: { $ref: "#/components/schemas/Pet" } "404": description: "Pet not found" OpenAPI ドキュメントは単なるドキュメント以上のものです。REST API のインターフェースを完全に記述する構造化された定義ファイル（JSON または YAML）です。API の提供者と利用者の間の契約として機能し、マシン可読であるため、適切なツールがそれを解析し、推論し、実際の成果物を生成できます。この点は、以降の議論すべてに関わる重要なポイントです。 本記事では、エージェント駆動の開発システムである Kiro を使って、Swagger API 仕様から直接、モックサーバー・設定トグル・HTML テストレポートまで含む実行可能な Node.js テストスイートを自動生成する方法を示します。 既存ツールが力不足な理由 これまでに OpenAPI 仕様を扱ったことがあれば、OpenAPI Generator や Swagger Codegen に出会ったことがあるでしょう。背景として、OpenAPI Generator はガバナンスの違いから 2018 年に Swagger Codegen からフォークされました。両者は似た目標を持ちますが、独立して保守されており、リリース頻度や機能セットも異なります。どちらも仕様ファイルを受け取り、選択した言語のクライアントライブラリ、サーバースタブ、SDK コードを生成するオープンソースツールです。HTTP のボイラープレートを削減するには優れていますが、API の振る舞いを検証する目的では設計されていません。テスト生成に使おうとすると、通常はアサーションが最低限のメソッドスタブ、限定的なモック、わずかなスキーマ検証しか得られません。もっとも、具体的な出力は使用する言語、テンプレート、設定によって異なります。テストはコンパイルされ実行はされるかもしれませんが、エッジケース、エラーハンドリング、スキーマの契約を意味のある形でカバーしているとは限りません。 これは見た目以上に深刻な問題です。アサーションのないテストでも CI ではパスし、カバレッジにはカウントされます。しかし実際にはステータスコード、レスポンスの形、エラーケースをチェックしていません。ビルドは成功し、カバレッジ数値も高いのに、 400 が 500 として返されているといった特定のバグが見過ごされるということが起こり得ます。 Kiro はこの問題に異なるアプローチを取ります。仕様をテンプレート化するのではなく、仕様を推論します。enum の値を現実的なペイロードに解決し、実際のスキーマの契約に紐づいたアサーションを生成し、仕様で定義された振る舞いを反映したモックサーバーを作り出します。出力されるのは後で埋めるためのスキャフォルディングではなく、意味のあるカバレッジを持つ実行可能なテストです。 機能 OpenAPI Generator Kiro アサーション付きの実行可能なテストを生成 ◐ 限定的（テンプレート依存） ✓ あり 仕様に対応するモックサーバーを構築 ✗ なし ✓ あり スキーマから現実的なペイロードを推論 ◐ 部分的 ✓ enum の解決を含む チームのコーディング規約に適合 ◐ カスタムテンプレート ✓ ステアリングファイル経由 仕様のドリフトに応じて CI で再生成 ✗ 手動 ✓ ヘッドレスモード 自然言語の意図を理解 ✗ なし ✓ あり 機能比較: テンプレートベースのジェネレーター vs. Kiro のエージェント駆動アプローチ。 テンプレートベースのアプローチでは、特定の種類の問題が検出されないままになり得ます。例えば 400 エラーが 500 として返されたり、認証エンドポイントが不正な形式のトークンを受け入れたりするケースです。とくに、生成されたテストが実際にはエンドポイントへの呼び出しを行わず、レスポンスの検証もしない場合に顕著です。これらのツールは主にコード生成のために設計されており、振る舞いの検証のためのものではありません。一方で Kiro は、各エンドポイントを実際に呼び出し、レスポンスが仕様で定義されたものと一致するかを検証するテストを生成します。これにより、API の実際の準拠状況についてより信頼できるシグナルが得られます。 ソリューション概要 本ソリューションでは、サンプルの PetStore の Swagger/OpenAPI 仕様 URL を入力として受け取り、Kiro を使って完全に機能するテストプロジェクトを生成します。生成されるプロジェクトには以下のコンポーネントが含まれます。 axios を使用したテストクライアント ：Swagger 仕様で定義されたすべてのエンドポイントをカバーする HTTP テスト。GET、POST、PUT、DELETE 操作と、それに応じたリクエストペイロードおよびレスポンスアサーションを含みます。 Express のモックサーバー ：API をシミュレートするローカルサーバー。各エンドポイントに対して現実的なレスポンスを返すため、ネットワークアクセスや実サービスへの依存なしにテストを実行できます。 設定トグル ：同じテストスイートをモックサーバー（ローカル開発用）または実 API（統合テスト用）に対して実行できる簡単なスイッチ。 HTML テストレポート ：各テストケースの合否と詳細なエラー情報を表示する、スタイル付きで共有可能なレポート。CI/CD パイプラインやプルリクエストのレビューに適しています。 外部テストフレームワークゼロ ：テストは素の Node.js と軽量なカスタムランナーで動作し、フレームワークのバージョン競合をなくし、セットアップの手間を減らします。 前提条件 このウォークスルーを進めるには、以下が必要です。 Node.js Kiro のインストールと設定 Swagger/OpenAPI 仕様の URL（例として Petstore API を使用します） Kiro でテストスイートを生成する それでは、Petstore の Swagger 仕様から完全なテストスイートを生成しましょう。テスト生成のルールをすべてプロンプトに埋め込むのではなく、Kiro のステアリングファイルを使用します。ステアリングファイルは「 .kiro/steering/ 」に配置され、ワークスペース内のすべてのプロンプトで Kiro が従う永続的な指示を提供します。これにより、テスト生成の基準を一度定義しておけば、すべてのプロンプトでその恩恵を受けられます。本ブログでは このサンプル ステアリングファイルを使用しました。チームのニーズや基準に合わせてカスタマイズしてください。 ※ この図は GIF 形式に変換しているため画質が粗くなっています。鮮明な動画は 原文記事 をご参照ください。 サンプルプロンプト Kiro の vibe モードで使用するサンプルプロンプトを示します。 Generate a Node.js test suite from https://petstore.swagger.io/index.html using axios, Express for mocking, and no external test frameworks Kiro は Swagger 仕様を読み込み、すべてのエンドポイントを解析し、プロジェクト全体を生成します。 ※ この図は GIF 形式に変換しているため画質が粗くなっています。鮮明な動画は 原文記事 をご参照ください。 生成されたプロジェクト構造を確認する Kiro は以下のような構造のプロジェクトを生成します。 config.js ：設定トグルを含みます。 useMockServer: true に設定するとローカルの Express モックサーバーに対してテストを実行し、 useMockServer: false に設定すると実際の Petstore API を対象にします。 mock-server/server.js ：Petstore のすべてのエンドポイントに対するルートハンドラを持つ Express アプリケーション。各ハンドラは、Swagger 仕様で定義されたスキーマに一致する現実的なレスポンスデータを返します。 test/ ：API リソース（pet、store、user）ごとに整理された個別のテストファイル。各ファイルには、そのリソースのすべての操作に対するテストが含まれ、レスポンスのステータスコードとペイロード構造に対するアサーションがあります。 test-runner.js ：軽量な素の Node.js テストランナー。すべてのテストファイルを検出して実行し、合否のカウントを追跡し、エラーの詳細を取得します。 Kiro がどのように仕様を解析するかを理解する Kiro は汎用的なテストスタブを生成するだけではありません。Swagger 仕様とステアリングファイルの指示を読み込んで、次のことを行います。 すべてのエンドポイントと HTTP メソッドを識別する ：Petstore API の場合、POST /pet、GET /pet/{petId}、PUT /pet、DELETE /pet/{petId}、GET /store/inventory、POST /user/createWithList などの操作が含まれます。 スキーマ定義からリクエストペイロードを推論する ：POST および PUT 操作について、Kiro は仕様内のモデル定義に基づいて有効なリクエストボディを構築します（例えば、id、name、category、photoUrls、tags、status フィールドを持つ Pet オブジェクト）。 期待されるレスポンスコードに基づいて検証コードを生成する ：各テストは、仕様のレスポンス定義で定められた正しい HTTP ステータスコード（ 200 、 201 、 404 、 405 ）を検証します。 対応するモックサーバーのルートを作成する ：仕様内のすべてのエンドポイントに対して、定義されたレスポンススキーマに合致したデータを返す Express ルートハンドラが生成されます。 テストを実行する モックサーバーに対して実行する ローカルのモックサーバーに対してテストスイートを実行するには、チャットインターフェースで次のプロンプトを入力します。 Run the tests with the mock server 以下のような結果が表示されるはずです。 テストランナーはモックの Express サーバーを起動し、すべてのテストケースを実行し、レポートを生成します。生成された test-report.md をブラウザで開いて結果を確認してください。 テストの品質と分類 生成されたテストスイートには、Petstore の Swagger 仕様で定義されたすべてのエンドポイントをカバーするテストケースが含まれています。これらはユニットテストではなく統合テストです。各テストは axios 経由で実行中の Express サーバーに対して実際の HTTP リクエストを送り、TCP トランスポート、ミドルウェアのパース、ルートマッチング、ハンドラのロジック、状態の変化、JSON シリアライズといったスタック全体を使います。サーバー内部は関数レベルでスタブやモックされていません。複数のリクエストを連鎖させるテストも含まれます。例えば DELETE のテストでは、最初にリソースを POST し、次に DELETE し、最後に GET で 404 を確認するといった具合で、リクエストライフサイクルをまたいで副作用が正しく永続化されることを検証します。このマルチリクエストでブラックボックスなアプローチは、統合テストを統合テストたらしめる特徴です。 品質面では、このスイートには明確な強みがあります。各エンドポイントについて正常系と異常系の両方を体系的にカバーし、OpenAPI 仕様に記載された具体的な HTTP ステータスコード（ 200 、 400 、 404 、 405 ）を検証します。エフェメラルポートとインメモリのシードデータを使用しているため、スイートは完全に自己完結しており決定的です。ネットワーク依存もポートの衝突もなく、どのマシンでも再現可能です。破壊的な操作はレスポンスコードだけを信用せず、後続の読み取りで検証します。 要するに、これは API の形状とエラーハンドリングに対する CI の高速フィードバックに適した、実用的な契約レベルの統合スイートです。プロダクション品質の信頼性に到達するには、テストごとの状態分離、完全な JSON スキーマ検証、認証のカバレッジ、そして実サービスに対する定期的な実行が加わると良いでしょう。 詳細: 削除ライフサイクル全体のテスト Kiro が生成したテストの中でも、より興味深いものの 1 つは、単にエンドポイントを呼び出してステータスコードを確認するだけのものではありません。1 つのテストケースで、リソースのライフサイクル全体を検証します。 このテストが興味深いのは、DELETE のレスポンスだけを信用していない点です。多くの素朴なテストスイートは 200 ステータスコードを確認するだけで止まります。「サーバーが成功したと言ったのだから、成功した」というわけです。しかしそれは状態が実際に変化したかどうかを何も証明していません。バグのあるサーバーは 200 を返しつつ、レコードの削除に静かに失敗するかもしれません。 本当に消えている、ということです。 その代わりに、Kiro は 3 段階のテストを生成しました。 Arrange ：既知の ID を持つ新しい pet を POST し、正常に作成されたことを確認します。 Act ：その pet を DELETE し、サーバーが操作を受け付けたことを検証します。 Verify ：同じ ID を GET し、サーバーが 404 を返すことを検証します。 このパターンは「ラウンドトリップ検証」と呼ばれることがあり、うわべだけのテストと意味のある統合テストを分けるものです。API の状態が実際に遷移することを証明します。すなわち、存在するリソースは破棄でき、いったん破棄されれば本当に消えているということです。スタックのどこかの層（ルーティング、ハンドラのロジック、データストア）が削除を黙って取りこぼしても、GET による検証がそれを捕まえます。 これはテストが自己完結している好例でもあります。テストは、先行するテストによって書き換えられたかもしれないシードデータに依存するのではなく、自分自身でテストデータを用意します。これにより、テストの合否が実行順序に左右されなくなります。テストごとに状態をリセットしないスイートでは、これは小さくとも重要な品質シグナルです。 実 API に対して実行する 生成されたテストがモックの外でも通用するかを検証するには、1 つの環境変数を設定するだけで、開発者はスイートを実際の Petstore サーバーに向けることができます。 PETSTORE_URL=https://petstore.swagger.io npm test あるいは Kiro に「 Run the tests with the real server 」とプロンプトを与えます。これにより、コードを変更することなくまったく同じテストが実行されますが、対象がローカルの Express モックではなく実稼働の共有バックエンドになります。 失敗が発生したとき、それらは通常いくつかの認識可能なカテゴリに分類されます。 実 API が仕様より寛容な場合。 Swagger 定義では不正な入力に対して 405 を文書化していても、実サーバーはそれを静かに受け入れて 200 を返すことがあります。モックの方が現実より厳しかったというわけです。 エラーコードの意味が異なる場合。 モックは非数値 ID に対して 400 を返すかもしれませんが、実サーバーは 404 を返すかもしれません。どちらも擁護可能です。同じ仕様の異なる解釈を表しているだけです。 レスポンス形状が期待と一致しない場合。 テストが文字列として期待するフィールドが JSON オブジェクトとして返ってきたり、ネストされたプロパティが完全に欠落していたりします。 共有状態の前提が崩れる場合。 シードされたデータ（事前にロードされたユーザーや pet など）に依存するテストは、実サーバーがそれらのテストデータを持たないために失敗します。 このようなことが起きたときの推奨は、失敗をやみくもに「修正」しないことです。代わりに、それぞれを切り分けの問いとして捉えます。モックが間違っているのか、テストが間違っているのか、ドキュメントが間違っているのかということです。そこから次のように進めます。 実サーバーがより寛容な場合は、モックを緩めて合わせるか、テストをモック専用としてタグ付けするかを判断します。 エラーコードが異なる場合は、単一の信頼できる情報源（通常は実サーバーの実際の振る舞い）に揃え、モックとテストの期待値の両方を更新します。 共有状態が問題である場合は、テストを自己完結型にします。検証前に自分自身でテストデータを用意し、ローカルにしか存在しないデータに依存しないようにします。 ポイントは、初日から両モードで全テストを通すことではありません。両方のターゲットに対して実行することで、 前提が現実から乖離している箇所 が浮かび上がり、そのギャップを埋める道筋が体系的に得られるということです。 認証された内部 API に適応する Petstore API は認証を求めないパブリックなサンドボックスです。一方、実際の社内 API はほとんどの場合認証を必須とします。認証付きエンドポイントにこのアプローチを適応させる方法を示します。 まず、認証設定に対応できるようにテスト設定を拡張します。資格情報をハードコードするのではなく、外部から渡せるようにすることで、同じスイートを複数の環境で動かせるようにします。 // config.js module.exports = { baseURL: process.env.API_BASE_URL || 'http://127.0.0.1:3000', auth: { type: process.env.AUTH_TYPE || 'none', // 'none', 'bearer', 'apiKey', 'basic' token: process.env.AUTH_TOKEN, apiKey: process.env.API_KEY, apiKeyHeader: process.env.API_KEY_HEADER || 'X-API-Key', username: process.env.AUTH_USERNAME, password: process.env.AUTH_PASSWORD, }, }; 次に、設定された認証タイプに基づいて適切な資格情報を付与する共有クライアントファクトリーを構築します。 // client.js const axios = require('axios'); const config = require('./config'); function createClient() { const headers = {}; switch (config.auth.type) { case 'bearer': headers['Authorization'] = `Bearer ${config.auth.token}`; break; case 'apiKey': headers[config.auth.apiKeyHeader] = config.auth.apiKey; break; case 'basic': const encoded = Buffer.from( `${config.auth.username}:${config.auth.password}` ).toString('base64'); headers['Authorization'] = `Basic ${encoded}`; break; } return axios.create({ baseURL: config.baseURL, headers, validateStatus: () => true, }); } module.exports = { createClient }; これで、すべてのテストファイルが共有クライアントを使用し、資格情報はコードの外に保たれます。 # トークン認証のステージング API に対して実行 AUTH_TYPE=bearer AUTH_TOKEN=eyJhbG... API_BASE_URL=https://api.internal.example.com npm test # API キーで保護されたサービスに対して実行 AUTH_TYPE=apiKey API_KEY=sk-live-abc123 API_BASE_URL=https://gateway.internal.example.com npm test これを整えれば、認証の強制そのものを検証する専用テストも追加できます。資格情報なしのリクエストが拒否されること、期限切れトークンが 401 を返すこと、不十分なスコープが 403 を返すことなどです。これらは Petstore のサンドボックスでは試せないものの、内部サービスではしばしば最も重要となるテストです。 Kiro ヘッドレスモードでテスト再生成を自動化する テストスイートを一度生成できるだけでも有用ですが、本当の価値は、API が進化しても両者を同期させ続けられる点にあります。 Kiro CLI のヘッドレスモード を使えば、CI/CD パイプラインから Kiro をプログラムで実行できます。ブラウザもインタラクティブな端末も不要です。API キーを環境変数として設定し、プロンプトを渡せば、Kiro が一連の処理をエンドツーエンドで実行します。 まとめ 本記事では、Kiro を使って Swagger 仕様から完全な Node.js API テストスイートを数秒で生成する方法を示しました。生成されるプロジェクトには、HTTP テストクライアント、Express のモックサーバー、モック API と実 API を切り替える設定トグル、テストレポートが含まれ、外部のテストフレームワーク依存はありません。 このアプローチは、API 仕様をテストコードに手作業で翻訳する手間を取り除き、包括的な API テストカバレッジを達成するための体系的で再現可能な方法を提供します。Swagger または OpenAPI 仕様を持つあらゆる API に同じパターンを適用できます。 Kiro を始めるには、 kiro.dev をご覧ください。 翻訳は Solutions Architect の吉村が担当いたしました。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 6 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋・広島に続き、2026 年 4 月 28 日は福岡にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、実際に社内への生成 AI 展開に取り組まれた企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：株式会社オーレックホールディングス様 〜「禁止から活用へ」中堅製造業の現場主導 AI 展開〜 事例紹介は 株式会社オーレックホールディングス 様です。福岡県八女郡広川町に本社を置く農業機械・草刈り機のメーカーで、グループ全体での従業員数は約 580 名、創業 1948 年の中堅企業です。乗用草刈り機の部門で国内トップクラスのシェアを持ち、フランスの農業機械ブランドの展開を含めグローバルに事業を展開されています。当日は AWS 木村がモデレーターを務め、経営本部 ソリューションシステム部の岡原 徹 様・月足 浩騎 様・次郎丸 雪衣 様に、実際に社内で進められている生成 AI の展開についてパネルディスカッション形式でお話しいただきました。 きっかけは、全社的な AI 活用の方針転換 お取り組みのきっかけは、2024 年 7 月、社長から「競争力強化のため、安全な環境で生成 AI を積極的に活用していこう」という方針が打ち出されたことでした。実は、オーレックホールディングス様は、生成 AI が話題になり始めた 2022〜2023 年頃、社内情報が外部に学習されることに対する懸念から、社員による生成 AI の利用を一律で禁じていた経緯がありました。しかしながら、生成 AI の活用が世の中的にどんどん広がる中で、「禁止しているだけでは取り残されて競争力が落ちてしまう」という認識に変わり、安全な基盤のもとで活用していこうという方針の転換を経て、AI 活用のプロジェクトが始まりました。 セキュアな基盤と、社員のリテラシー向上の両輪で AI 活用を推進するにあたり、同社が重視したのは 2 つの柱です。1 つ目は、セキュアな AI 基盤を社内に整備すること。2 つ目は、利用者となる社員の AI リテラシーを引き上げることです。ツールを配るだけでは、機密情報の意図しない入力や、AI のハルシネーションを鵜呑みにしてしまうといったリスクが残ります。安心して使える基盤の構築と、正しく使うための教育を同時に進める方針を立てました。 社内 IT 基盤のツールとして選定したのが、AWS が公開する OSS の生成 AI アプリケーション Generative AI Use Cases(GenU) です。選定の決め手は「セキュアに利用できること」と「スモールスタートできる価格設定」の 2 点でした。経営層の方々は、AI 活用の初期の段階から大きな投資をするのではなく、効果を見極めながら段階的な投資をしたいという考え方があったため、トークン単位の従量課金で、比較的安価に利用開始できる GenU がニーズに即していると考えました。また、GenU は、すぐ使えるユースケースがあらかじめ用意されていて、非 IT の担当者でも使い方のイメージが持てた点も選定のポイントになりました。選定から導入までスピード感を持って進め、2024 年 12 月末には導入を完了、運用をスタートさせることができました。 「触ってもらう」から始めた段階的展開 展開にあたって、社員の皆様に段階的に利用を開始してもらうアプローチを取りました。AI 活用の第一期生として、英文ライティングが多い海外営業部門、すでに個人的に生成 AI を使っていた社員を含む 56 名に AI のアカウントを配布しました。少人数で自由に AI を活用した業務課題解決を探索してもらうことで、ユースケースの発見を促すとともに、早期のリスクの洗い出しにもつなげる戦略を取りました。その後、効果が出てきたタイミングで、第二期生として部課長や開発部門など 35 名に追加配布、さらに希望者には都度配布…といったように、利用範囲を段階的に拡大しました。 アカウント配布と同時に、AI の勉強会を実施しました。AI の得意不得意、業務利用時の注意点、プロンプトの作り方の基礎を利用者部門に伝え、より効果的な活用を促しました。さらに、「利用者同士の座談会」を開催し、活用率の高い社員が日頃どのように使っているかをざっくばらんに話してもらう機会を設けたり、アンケートを通して横展開を支援したりなど、細やかなケアを続けていきました。 もう一つ、ユニークな取り組みとして、チャットボットの名前を公募で選定した点を挙げられました。全社員が親しみを持てるよう、 自社製品の乗用草刈り機「ラビットモアー」 にちなんでウサギのキャラクターを設定し、名前を公募しました。最終的に、「AI ちゃびっと」という名称で社内で親しまれるようになりました。今では名前とキャラクターが広く浸透、定着しています。公募という形にしたことで、社員が自分たちのプロジェクトとして参加意識を持てたことも浸透を後押しできたと考えています。 成果：全社員の 40% が自発的に使い始めた 現在の利用状況は、全社員の約 40 %にあたる 200 名が活用しています。そのうち 100 名以上は「自分で使いたい」と手を挙げて始めたメンバーです。当初想定していた文章作成や検索だけでなく、特許調査への組み込み、営業向けのプロンプトの定型化、法令チェック、温暖化係数の計算・ライフサイクルアセスメント解析といった、より専門的な業務での活用まで広がっています。方針が出た時点では社内のどの業務に AI を使えるかというイメージが全く持てなかった状態からのスタートでしたが、情報システム部が一つひとつユースケースを発掘するのではなく、現場が自分たちの課題に AI を当てはめて使い方を見つけてくれた結果でした。 一方で残る課題として、3 点を率直に話していただきました。1 点目はリソース不足で、他のプロジェクトとの兼ね合いで生成 AI の推進が後回しになりやすいこと、また同じ立場で AI 展開を進めている社内外の仲間が少ないこと。2 点目は効果測定の難しさで、AI 活用の成果を定量的に示す手段がまだ整っていないこと。3 点目は社員の皆様への継続的な AI の知見のアップデートです。業務ツールへの AI 組み込みが増える中、継続的な取り組みの重要性を語っていただきました。月足様からも、「AI が質問者に寄り添った回答をしてしまう」という特性があるため、AI のリスクを正しく理解し、最終判断はあくまでも人間が下すという姿勢を社内に根付かせていく必要性を語られました。 横展開を支えた「信頼の土台」 岡原様は、「普段からクロスファンクションでコミュニケーションを取っていて、工場にはデジタルサイネージを設置して IT 部門の活動を発信していた。『IT 部門に頼めば、きっと期待に応えてくれる』という、社員の皆様からの信頼の土台があったから、今回の横展開もうまくいった」と振り返られました。AI のプロジェクトが始まる前から積み重ねてきた地道な活動こそが、全社展開の推進力になった——この話は、参加者の皆様にとっても示唆の大きいポイントでした。 写真: 株式会社オーレックホールディングス 岡原様・月足様・次郎丸様、AWS 木村（営業）によるパネルディスカッション まとめ セッション後には参加者同士のグループワーク・ディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。「IT に詳しくない担当者が手探りで進めた」というリアルな話に共感の声が多く、「同じ悩みを持つ方と話せた」「自分たちだけじゃないと安心した」といった声をいただきました。製造業・中堅企業という条件の中でも、小さく始めて着実に広げていくアプローチが確かに機能することを示してくれたセッションでした。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした福岡編に続き、次回は北海道編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 – AWS Local Executive Roadshow 名古屋編（#4/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。 先週末、6月25日、26日に AWS Summit Japan 2026 が開催されました。今年も多くのお客様にご来場いただき有り難うございました。生成AI、Physical AIに関する説明やデモが多く展示され、このブログの読者の皆様はイベントを楽しめて頂けたのではと思います。AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日のご参加が出来なかった方や、ご来場頂いた方で視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただければ幸いです｡ それでは 6月 22日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ「 店舗の気づきを本部に届ける AI エージェント SMART のご紹介 — Amazon Bedrock AgentCore × Strands Agents によるユナイテッドアローズでの取り組み 」 店舗スタッフの気づきを AI が引き出して言語化し、本部に届けることを支援する AWS サンプルアセット「SMART（Store Manager Agent for Retail Tech）」と、それを活用したユナイテッドアローズの取り組みを紹介する記事です。本部が設定した「問い」を起点に AI が「なぜ」を深掘りし、対話を店舗名・日付・カテゴリといった構造化データに変換して、売上などの定量データと掛け合わせたインサイトを翌朝に届けます。ユナイテッドアローズでは、SMART をベースに Kiro を活用して内製でカスタマイズし、4 店舗で PoC を実施しました。「昨日の店舗がどうだったかを人に聞かなくても把握できる」「AI の深掘りでスタッフに考える習慣が広がった」といった声が寄せられ、本部側でも現場ヒアリングの時間削減や売上向上につながる気づきが得られたとしています。 ブログ記事「 Amazon Bedrock AgentCore での Web Search を発表: AI エージェントを最新かつ正確なウェブ知識に基づかせる 」 Amazon Bedrock AgentCore の Web Search が一般提供を開始しました。保護された AWS 環境からデータを外部に持ち出すことなく、出典が明示された最新のウェブ知識に基づいて応答を生成できるフルマネージドツールです。MCP（モデルコンテキストプロトコル）を使う Bedrock AgentCore Gateway の組み込みコネクタターゲットとして提供され、自然言語クエリに対して関連スニペット、ソース URL、タイトル、公開日を返します。標準的なウェブ検索に加えて Amazon Knowledge Graph も組み合わせるマルチソースグラウンディングを採用しているため、ウェブ検索のみの場合より関連性が高く正確な応答を得やすいとしています。外部の検索 API プロバイダーにユーザープロンプトや検索クエリを送らずに済むため、エンタープライズのガバナンス要件にも対応できます。米国東部（バージニア北部）リージョンで一般提供を開始しました。 ブログ記事「 より高速かつ正確なエンタープライズ AI アプリケーションを実現する Amazon Bedrock マネージドナレッジベースのご紹介 」 所有データを使ってエンタープライズグレードの生成 AI アプリケーションを数分で構築できる、Amazon Bedrock マネージドナレッジベースが発表されました。RAG パイプラインに必要なストレージ・検索・埋め込み・再ランキング・基盤モデルの選択を単一のマネージドプリミティブに抽象化し、デフォルトでサービスが各モデルを自動選択・管理するため、すぐに使い始められます。主な特長は 3 つです。Amazon S3、SharePoint、Confluence、Web Crawler、Google Drive、OneDrive をサポートする 6 つのネイティブデータコネクタ、データタイプやコネクタに応じて最適な解析戦略を自動で選ぶ Smart Parsing、そして単一・複数のナレッジベースをまたぐマルチターン/マルチホップ検索に最適化された Agentic Retriever です。AgentCore Gateway の事前構築済みターゲットとして数行のコードで統合でき、ロールベースの権限が自動生成されます。米国東部（バージニア北部）、米国西部（オレゴン）、東京リージョンを含むアジアパシフィック（シドニー、東京）、欧州（ダブリン、フランクフルト、ロンドン）、AWS GovCloud（米国西部）で利用できます。 ブログ記事「 AWS DevOps エージェントで、本番前にコード変更を評価するためのリリース管理機能が追加 (プレビュー) 」 AWS DevOps エージェントに、本番前にコード変更を評価するリリース管理機能がプレビューで追加されました。デプロイ後の運用（インシデントの自律調査や根本原因分析）はすでに一般提供されており、今回はコード変更の「リリース準備状況レビュー」と「自律リリーステスト」が加わりました。リリース準備状況レビューは、自然言語で指定した社内標準やベストプラクティスに照らして変更を評価し、リポジトリ間の依存関係リスクや AWS Well-Architected に沿ったアクセスコントロールの確認、コミット前の破壊的変更の検出を行います。結果は「ブロック」「注意して続行」「安全にリリース可能」のいずれかで示され、コンソールや GitHub／GitLab のプルリクエストへのコメント、さらに Kiro パワーや Claude Code プラグイン経由で IDE から直接確認できます。自律リリーステストは、変更内容を推論して固有のテストプランを生成し、本番のような環境で実行します。米国東部（バージニア北部）リージョンで、プレビュー期間中は追加料金なしで利用できます。 ブログ記事「 AWS セキュリティエージェントで、脅威モデリング、Kiro パワー、Claude Code プラグインなどが追加 」 開発ライフサイクル全体でアプリケーションを保護する AWS セキュリティエージェントに、新しい機能が追加されました。コードレビューはプルリクエストスキャンに対応し、GitHub に加えて GitLab、Bitbucket、Confluence と連携できるようになりました。新たな脅威モデリング（プレビュー）は、設計ドキュメントやソースコードを分析してアプリケーションのアーキテクチャを理解し、STRIDE フレームワークで脅威を特定して緩和策を提示します。また、Kiro パワーと Claude Code プラグイン（近日リリース予定）、オープンな MCP 統合により、IDE や CLI から直接コードレビューや脅威モデル生成、検出結果の修正を行い、結果をインラインで確認できます。AWS セキュリティエージェントが利用できる AWS 商用リージョンで使え、2 か月間の無料トライアルが用意されています。 ブログ記事「 コーディングは不要 ― ビジネスユーザーこそが顧客体験の新たな設計者に 」 顧客体験（CX）の設計を、エンジニアではなく顧客を理解するビジネスユーザーが主導できるようにする、という考え方を記載した記事です。これまで CX 業務は「キュー（待ち行列）」を前提に運営され、ビジネス側が作りたい体験もエンジニアリングのチケット待ちがボトルネックになっていましたが、エージェンティック AI がこの制約を変えつつあるとしています。記事では、企業が正しく取り組むべき 3 点として、機能単位ではなく顧客ジャーニー全体を支える統合アーキテクチャ、決定論的な処理とエージェンティックな推論を同一のガバナンス下で共存させること、そしてビジネスユーザーに設計の主導権を渡すことを挙げています。あわせて、コード不要でエンドツーエンドの対話体験を視覚的に構築できる Agentic CX Designer（プレビュー）と、音声と画面表示をリアルタイムに同期する特許技術 Live Sync（プレビュー）を、Amazon Connect Customer の機能として紹介しています。また Saks Fifth Avenue でビジネスアナリスト主導で 6 週間での本番稼働を実現した例が示されています。 ブログ記事「 Amazon CloudWatch と OpenTelemetry による Claude Code 利用状況の分析 」 Claude Code のような AI コーディングエージェントの利用状況を、Amazon CloudWatch と OpenTelemetry で可視化する手順を解説した技術記事です。CloudWatch の OpenTelemetry Protocol（OTLP）が一般提供となり、ベアラートークン認証でメトリクスを取り込めるようになったため、コレクターやサイドカー、開発者マシンでの IAM 認証情報の配線なしに、認可ヘッダー 1 つで CloudWatch へメトリクスを直接送信できます。記事では、CloudWatch メトリクス API キー（ベアラートークン）の作成から Claude Code 側の環境変数設定、メトリクスの確認、構築済みダッシュボードのデプロイまでを一通り示しています。ダッシュボードはトークン使用量、開発者の生産性、部門・チーム別のコスト配分、Amazon Bedrock API の健全性などを PromQL で可視化でき、個人の支出スパイクやチーム予算超過、利用減少を検知するアラート例も紹介されています。 ブログ記事「 Accelerating Smart Product SDLC with AI Agent Workshop のご紹介 」 IoT やコネクテッドデバイスの普及で「スマートプロダクト」へと進化する製造業向けに、組込みソフトウェア開発のライフサイクル全体（Research → Plan → Development → Release → Operation）で AI エージェントを活用するワークショップを紹介する記事です。コーディングだけを速くしてもライフサイクル全体のボトルネックは解消されない、という課題意識から、各フェーズ固有の壁を越えるアプローチを提案しています。生成AI を「制御可能・追跡可能・学習可能」な形で開発全域に組み込むことを狙いとしています。 ブログ記事「 NVIDIA RTX PRO 4500 Blackwell Server Edition GPU で高速化された Amazon EC2 G7 インスタンスのご紹介 」を公開 AI 推論、グラフィックス、データ分析向けの Amazon EC2 G7 インスタンスが一般提供を開始しました。AWS は NVIDIA RTX PRO 4500 Blackwell Server Edition GPU をサポートする最初の主要クラウドプロバイダーで、第 6 世代のカスタム Intel Xeon Scalable プロセッサと組み合わせ、前世代の G6 比で最大 4.6 倍の AI 推論性能、最大 2.1 倍のグラフィックス性能を実現します。AI 推論やグラフィックスレンダリング、動画トランスコーディング、VDI、データ分析など幅広い用途に向きます。米国東部（オハイオ）、米国西部（オレゴン）の各リージョンで、オンデマンド、Savings Plans、スポットの購入オプションで利用できます。 Kiro関連 ブログ記事「 Kiro Web の Automations 機能のご紹介 」 ブラウザで使える Kiro Web に、クラウドで動作する Automations 機能が追加されました。依存関係の更新やドキュメントの追従、テストカバレッジの確認など、決まった間隔で繰り返し発生するタスクを Kiro に任せられます。Automations は自律型エージェントが管理し、実行ごとにサンドボックス内で autonomous セッションを作成して、完了すると自動でプルリクエストを開きます。設定は、タスクに名前を付けて GitHub または GitLab（両方も可）のリポジトリを選び、実行内容を記述してスケジュールを決めるだけです。1 つの Automation につき最大 5 つのスケジュールを設定でき、Daily・Weekly などの組み込みオプションのほか cron 式も使えます。古くなったドキュメントの更新、テスト未カバーのパスへのテスト生成、古い TODO／FIXME の整理といった使い方が示されています。 ブログ記事「 Kiro でテスト駆動開発（TDD）：こうあるべき体験 」を公開 テスト駆動開発（TDD）の利点は理解していても、テストと実装の往復や規律の維持、テストを書く単調さが負担になりがちです。この記事は、Kiro の hook（IDE の特定イベントで自動実行される仕組み）を使って、red-green-refactor サイクルを Kiro に徹底させることで、その負担なく TDD の恩恵を得る方法を紹介しています。ファイル保存前に発火する hook を作り、テストを先に書いて失敗（red）を確認してから最小限の実装（green）に進むよう Kiro に促す、という設定例が具体的なプロンプトつきで示されています。 ブログ記事「 Agent Focus のご紹介 」を公開 Kiro IDE に、エージェントとの対話を中心に据えた実験的な新ビュー「Agent Focus」が導入されました。やりたいことを説明し、会話で調整し、作業を開始して進捗を確認する、というチャットファーストの進め方を実現します。画面は 3 つのパネルで構成されます。新規セッションの作成やワークスペース別の状態（作業中・入力待ち・一時停止）を確認する Agents パネル、ファイル変更をインラインの差分で表示する Chat パネル、変更ファイルやスペック要約を必要時に表示する Auxiliary パネルです。複数セッションを並行して独立に動かせ、設定や powers、skills、MCP、ターミナル、直接のファイル編集など IDE 側の機能へもすぐ戻れます。最新の Kiro 1.0 に実装されており、使用するにはダウンロードページからの更新が必要です。 ブログ記事「 Kiro で OpenAPI／Swagger 仕様から数秒でテストスイートを生成 」 OpenAPI／Swagger 仕様（JSON または YAML）を入力すると、Kiro が Node.js のテストスイートを自動生成する手法を解説した記事です。スタブを埋める必要のある従来のコード生成ツールとは異なり、Kiro は仕様の内容を推論し、スキーマ契約に紐づくアサーションを備えた、実行可能なテストを生成します。生成されるのは単体テストではなく、axios で実際の HTTP リクエストを行う統合テストで、ローカルのモックサーバー（Express）と切り替えられる設定や、軽量なテストランナー、HTML レポートが含まれます。たとえば DELETE のテストでは、POST → DELETE → GET と連鎖させて削除後に 404 が返ることまで検証します。環境変数を変えるだけでライブ API に対しても同じテストを実行でき、認証付き API への適応や、 .kiro/steering/ のステアリングファイル、CLI のヘッドレスモードによる CI/CD への組み込みも紹介されています。 ブログ記事「 1 つのセッションで GitLab と GitHub にまたがる変更を調整する 」 Kiro Web が GitLab に対応し、既存の GitHub 対応と合わせて、両プロバイダーのリポジトリを 1 つのセッションに追加できるようになりました。1 つの変更を記述すると、Kiro が両方のリポジトリに反映し、GitLab 側にはマージリクエスト、GitHub 側にはプルリクエストを自動で作成します。コードが 2 つのプロバイダーに分かれていると、両方にまたがる変更で手順を忘れて同期がずれるリスクがありますが、Kiro が横断的に変更を調整することでこれを防ぎます。記事では、GitLab の非公開サービスと GitHub の公開 SDK に、エンドツーエンドで email フィールドを追加する例を紹介しています。Kiro Web はプレビュー版で、Pro、Pro+、Power のサブスクライバー向けに提供されています。 サービスアップデート Amazon Bedrock AgentCore Memory がクロスアカウントアクセスに対応 Amazon Bedrock AgentCore Memory が、クロスアカウントアクセスに対応しました。メモリリソースと、それを利用するエージェントが複数の AWS アカウントにまたがるマルチアカウント構成を組めるようになります。リソースベースのポリシーをメモリリソースにアタッチすることで、あるアカウントのプリンシパルに、別アカウントのリソースに対してメモリのデータプレーン API を呼び出す権限を付与できます。設定後は、利用側アカウントのプリンシパルが、完全なメモリ ARN を参照してイベントの作成、メモリレコードの書き込み・取得、セマンティック検索を実行できます。また、メモリの配信先（Amazon S3、Amazon SNS、Amazon Kinesis Data Streams）を別アカウントに置く構成も可能で、ペイロードの配信やイベントのストリーミングを他アカウントのリソースに対して行えます。Amazon Bedrock AgentCore Memory がサポートされるすべての AWS リージョンで利用できます。 Amazon Bedrock Guardrails の Automated Reasoning checks に新しいポリシー改善ワークフローが追加 Amazon Bedrock Guardrails の Automated Reasoning checks に、ポリシーを自動で改善するワークフローが追加されました。Automated Reasoning checks は形式論理を使って生成 AI の応答の正確性を、定義したポリシーに照らして数学的に検証する機能で、ハルシネーションの検出や検証可能な説明の提示に役立ちます。検証結果の質はポリシーの定義の良し悪しに左右されるため、今回の機能で手作業を減らしながらポリシーを改善できます。追加されたのは 2 つのワークフローです。反復的なポリシー改善ワークフローでは、ポリシー向けに自然言語のテストを作成したお客様が反復改善を実行し、それらのテストにパスするために必要な変更をシステムに導き出させられます。曖昧さ削減ワークフローでは、曖昧な変換結果が頻発する場合に、変数の説明や型定義を自動的に調整して曖昧な変換の発生を減らせます。Automated Reasoning checks が利用できるすべての AWS リージョンで使えます。 Amazon SageMaker Studio ノートブックが G7e インスタンスタイプに対応 Amazon SageMaker Studio ノートブックが、Amazon EC2 G7e インスタンスに対応しました。G7e は最大 8 基の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU（GPU あたり 96GB メモリ）と第 5 世代 Intel Xeon プロセッサを備え、最大 192 vCPU、最大 1600 Gbps の Elastic Fabric Adapter ネットワーキング帯域幅をサポートします。大規模言語モデル（LLM）やエージェント型 AI、マルチモーダル生成 AI、フィジカル AI モデルのデプロイに使え、空間コンピューティングや、グラフィックスと AI 処理の両方を要するワークロードで高い性能を発揮します。米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）の各リージョンで利用できます。 Amazon SageMaker ノートブックインスタンスが G6e インスタンスタイプに対応 Amazon SageMaker ノートブックインスタンスで、Amazon EC2 G6e インスタンスが一般提供されました。G6e は最大 8 基の NVIDIA L40s Tensor Core GPU（GPU あたり 48GB メモリ）と第 3 世代 AMD EPYC プロセッサを搭載し、EC2 G5 インスタンスと比べて最大 2.5 倍の性能を発揮します。モデルデプロイのインタラクティブなテストや、生成 AI のファインチューニングといったインタラクティブなモデル学習に利用でき、最大 130 億パラメータの大規模言語モデル（LLM）や、画像・動画・音声を生成する拡散モデルのデプロイに使えます。東京リージョンを含む米国東部（バージニア北部、オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、中東（ドバイ）、欧州（フランクフルト、スウェーデン、スペイン）の各リージョンで利用できます。 Kiro関連 Kiro が AWS GovCloud (US) で FedRAMP High および DoD IL-4/5 認証を取得 Kiro が、AWS GovCloud (US) リージョンで FedRAMP High および米国国防総省クラウドコンピューティングセキュリティ要件ガイド（DoD CC SRG）の Impact Level（IL）4 および 5 の認証を取得しました。これにより、FedRAMP High や DoD CC SRG IL-4/5 のコンプライアンス要件を持つ連邦機関や公共部門の組織、企業が、機密性の高いワークロードに求められるセキュリティ・コンプライアンス基準を満たした形で、Kiro をエージェント型の開発パートナーとして利用できます。 Kiro-CLI : 設定のホットリロードとリソース継承の制御 Kiro CLI 2.10 では、MCP まわりの繰り返し作業の手間を減らし、カスタムエージェントの作者にコンテキストの制御手段を提供します。エージェントと MCP の設定が、ディスク上で変更を保存するとホットリロードされるようになりました。エージェント設定の編集や新規エージェントファイルの追加、 mcp.json の変更が、セッションを再起動せずに反映されます。再起動するのは影響を受けたサーバーのみで、会話のコンテキストは保持されます。設定の差分は順序に依存しないため、環境変数を並べ替えても不要な再起動は起きません。また、新しい設定 chat.disableInheritingDefaultResources が追加されました。カスタムエージェントがデフォルトの steering、skills、AGENTS.md を継承しないようにする設定で、グローバルリソースを取り込みたくない場合に true にします。v2.7.0 以降、カスタムエージェントはデフォルトリソースを自動的に継承していましたが、この設定でその継承をオフにできます。 Kiro-CLI : V3 (Early Access) の安定性修正と Entra ID のセッション更新 Kiro CLI 2.9 では、Entra ID（Azure AD）ユーザーのセッション期限切れの問題を修正しました。あわせて、V3 (Early Access)における複合シェルコマンドの承認プロンプトのループを解消し、サブエージェント呼び出し向けにコンパクトなツールカードのプレビューを追加しています。 Kiro-IDE : Agent Focus、権限、カスタムエージェント、その他のアップデート Kiro IDE 1.0 では、複数の機能が追加されました。実験的機能の Agent Focus は、チャット中心のレイアウトで複数のエージェントを並行して操作でき、セッションは独立・並列に動作し、ファイル変更はインラインの差分で表示されます。Spec、Plan、Bug Fix、Quick Spec といった構造化ワークフローやフリーフォームのチャットから開始でき、従来の IDE とは右上からワンクリックで切り替えられて、作業内容は双方向に引き継がれます。 最後に、「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近燻製づくりにハマってます。

この度、Amazon Quick on Desktop が AWS アジアパシフィック (東京) リージョンでプレビュー利用可能になりました。2026年3月の東京リージョンローンチに続き、4月にプレビュー公開されたデスクトップアプリケーションも東京リージョンに対応しています。これにより、日本のお客様はデータを国内に保持しながら、デスクトップ上でよりパーソナルでプロアクティブな AI アシスタント体験を実現できます。 “Amazon Quick on Desktop は、本ブログ投稿時点では Preview であり、機能・仕様が変更される場合がございます。”  Amazon Quick on Desktop とは Amazon Quick on Desktop は、Amazon Quick をブラウザの枠を超えてお使いのコンピュータにネイティブに展開するデスクトップアプリケーション (macOS / Windows 対応) です。ローカルファイルへの直接アクセス、OS レベルのプロアクティブ通知、バックグラウンドエージェント、ブラウザ自動化、パーソナルナレッジグラフ といった機能を備えています。 Quick on Desktop でできること ローカルファイルと直接連携 : チャットエージェントにアップロード不要で、許可したフォルダ内のファイルを読み書き・検索・インデックス化。ドキュメント作成やデータ分析もローカルファイルを直接参照して実行できます。 バックグラウンドエージェント : スケジュールに基づいて自動実行されるエージェントが、チャネル監視・メールトリアージ・ミーティング要約・インシデント追跡などを代行します。 プロアクティブ通知とアクティビティフィード : 接続サービスを監視し、重要な情報をデスクトップに通知。アクティビティフィードで優先度順に一覧表示します。 ブラウザ自動化 : Chrome を起動・制御し、Web フォーム入力、スクリーンショット取得、データ抽出、Web アプリとの連携を Quick に委任できます。 パーソナルナレッジグラフ : Slack メッセージ、メール、カレンダーなどの連携サービスおよびローカルファイルからエンティティと関係性を自動抽出し、あなた専用のナレッジグラフを構築。Quick の回答がよりユーザーに沿ったものとなります。 MCP サーバー接続 : Model Context Protocol (MCP) で外部ツールやコーディングエージェントと連携し、Quick の能力を拡張できます。 ドキュメント生成 : Word、Excel、PowerPoint などをチャットから直接生成できます。 ローカルファースト・アーキテクチャ Quick on Desktop は ローカルファースト・アーキテクチャ を採用しています。AI バックエンドはお手元のマシンで実行され、ファイルもローカルに留まります。ネットワーク通信は API Gateway 経由の AI モデル呼び出し と、 接続済みサービス (Slack, Outlook, Gmail 等) への通信 のみです。この設計により、プライバシーを保護しつつ Quick の機能を活用できます。 東京リージョン対応のメリット 1. 国内データレジデンシー データが日本国内の AWS インフラストラクチャに留まるため、個人情報保護法 (APPI) やお客様組織の内部ガバナンス要件を満たしやすくなります。 2. JP-CRIS による国内推論 JP-CRIS (Japan Cross-Region Inference) により、東京リージョンからの推論リクエストは 東京 (ap-northeast-1) と 大阪 (ap-northeast-3) の AWS リージョン内のみでルーティングされます。推論が日本国外で実行されることはありません。 3. 低レイテンシー 日本国内ユーザーのネットワークレイテンシーが改善され、AI 応答やダッシュボード表示、ワークフローの応答などのパフォーマンスが向上します。 最新アップデート Amazon Quick on Desktop は継続的にアップデートされています。 AWS Summit New York で発表された最新機能を含め、注目のアップデートをご紹介します。 Autonomous Agent — あなたの代わりに動き続ける AI Quick に Autonomous Agent（自律型エージェント） が追加されました。自然言語で目的を記述するだけで、バックグラウンドで継続的にタスクを実行するエージェントを作成できます（ 公式ブログ ）。 特徴: ノーコード作成 : 自然言語で目的を伝えるだけで作成可能。プリセットライブラリからの選択にも対応 柔軟な自律レベル : ステップバイステップの指示から、ゴールだけを与えてエージェントに判断させるモードまで選択可能 常時稼働 : ミーティング中や退席中でもバックグラウンドで動作し続ける ガードレール制御 : エージェントごとにガードレールを設定し、動作を制御 学習と改善 : やり取りや修正を通じてエージェントは時間とともに賢くなる Activity Feed — 1日の始まりをトリアージから解放 Quick Desktop の Activity Feed が大幅に強化されました。メール、メッセージング、カレンダー、タスクを 1つの優先度付きビュー に集約し、AI がトリアージを代行します。 特徴: 統合ビュー : メール、メッセージング、カレンダー、タスクを横断的に一元表示 AI によるプライオリティ付け : どのメッセージに素早く返信するか、どのスレッドをスキップするか、どのトピックが重要か判断 サマリーカード : 複数の関連メッセージを返信ドラフト付きの1枚のカードに要約 その場でアクション : 返信、転送、承認、委任をフィードから直接実行（アプリ切替不要） Skills & Agents カタログ 組み込みの スキル・エージェント・コネクタのカタログ がローンチされ、数クリックで導入・共有が可能に。営業、財務、マーケティング向けの 30 以上の準備済みスキルが用意されています。 Quick on Desktop の始め方 Amazon Quick on Desktop を始めるのは簡単です。 アカウント作成 : quick.aws.com で Free または Plus アカウントにサインアップします（AWS アカウント不要、メールアドレスのみで登録可能） アプリダウンロード : ダウンロードページ から macOS または Windows 版のデスクトップアプリケーションをインストールします フォルダ許可 : Quick にアクセスさせたいローカルフォルダを設定します サービス接続 : Slack、Outlook、Gmail 等のビジネスアプリケーションを接続します ナレッジグラフ構築開始 : 使い続けるほどコンテキストが蓄積され、よりパーソナライズされた体験になります エンタープライズ (Professional / Enterprise) アカウントのお客様は、IAM Identity Center による SSO 連携や、管理者によるエンタープライズデプロイも可能です。 エンタープライズセキュリティとガバナンス Quick on Desktop は、ローカルファーストの設計思想に基づきセキュリティとデータプライバシーを確保しています。 ファイルはローカルに留まる : Quick on Desktop はローカルファースト・アーキテクチャを採用しており、ファイルがクラウドにアップロードされることはありません。ユーザーが許可したフォルダのみアクセスし、いつでもアクセスを取り消せます。 ネットワーク通信は最小限 : ネットワーク通信は API Gateway 経由の AI モデル呼び出しと接続済みサービス (Slack, Outlook 等) への通信のみ。データがモデルのトレーニングに使用されることはありません。 エージェントのガードレール : Autonomous Agent にはエージェントごとに自律範囲を設定でき、意図しないアクションを防止します。 フォルダ単位のアクセス制御 : ローカルファイルへのアクセスはフォルダ単位で許可/取り消しが可能。キーワード検索、セマンティック検索、ナレッジグラフ抽出もフォルダ単位で制御できます。 東京リージョンでの JP-CRIS : AI モデルへの推論リクエストは東京・大阪リージョン内に閉じてルーティングされるため、データが日本国外に出ることはありません。 まとめ Amazon Quick on Desktop の東京リージョン対応により、日本のお客様はデスクトップ上でも Quick の AI アシスタントを活用しつつ、データ保全と低レイテンシーの恩恵を受けられるようになりました。ローカルファイルとの深い統合、プロアクティブな通知、パーソナルナレッジグラフ、そしてバックグラウンドエージェントによる自動化が、日々の業務を根本から変革します。 ぜひ Amazon Quick on Desktop をお試しください。

本ブログは東京電力エナジーパートナー株式会社 サービスソリューション事業部 今野拓也様の監修のもと、アマゾン ウェブ サービス ジャパン合同会社 橋井雄介が執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの橋井です。 電気・ガスなど大規模なインフラを提供する企業にとって、コンタクトセンターはお客さまとの重要な接点となっています。だからこそ、その体験の質が企業への信頼に直結します。「コンタクトセンターに生成 AI を導入したいが、大規模環境で実用的な精度が出るのか」「導入後に組織として使いこなせるのか」——そんな課題をお持ちの方に向けて、 Amazon Connect Customer （旧 Amazon Connect）と Amazon Bedrock を活用した変革を推進している東京電力エナジーパートナー様（以下、TEPCO EP）の事例をご紹介します。 TEPCO EP が取り組むコンタクトセンターの課題 TEPCO EP は、電力・ガスの小売事業を担い、全国複数拠点・数千席規模のコンタクトセンターでお客さまの契約手続きや問い合わせに対応しています。サービスソリューション事業部は「人 × IT の融合により、パーソナライズされたサポートを安心と感動とともに届ける」というビジョンを掲げ、CX 向上を推進しています。 同社のコンタクトセンターでは、デジタルチャネルの比率が向上する中でも電話が約 4 割を占めており、以下の課題がありました。 IVR（Interactive Voice Response: 自動音声応答）が複雑でオペレーターに繋がるまでの導線がわかりにくい オペレータースキルと用件のミスマッチが発生しやすい 応対後の処理負荷が大きく、保留や管理者へのエスカレーションも多い 利用システムが拠点ごとに異なり、会話データの横断的な活用が困難 今回、オンプレミス環境の保守期限を迎えてシステムを刷新するタイミングで、CX 向上と業務効率化を同時に実現するプロジェクト「 SEEDS（Smart Engagement and Efficient Data System） 」を立ち上げました。 図 1 受付チャネルの現状と課題 SEEDS Phase1 で実現したこと Phase1 では、Amazon Connect Customer をベースとした新たな受電環境を構築し、全国にある拠点のうち 18 拠点の切替を完了しました。 要件整理からリリースまで約 10 ヶ月、拠点切替は約 3 ヶ月で完了しています。できる限り標準機能を活用してスクラッチ開発を最小限にしたこと、生成 AI のチューニングやオペレーター画面の構成は検討開始後、早期から実際の挙動などを確認しながら段階的に精度を高めていくアプローチをとったことが、このスピードの鍵でした。 Phase1 で導入した主な機能は以下のとおりです。 音声テキスト化 : お客さまとオペレーターの会話をリアルタイムで文字表示（課題 3, 4 に対応） 会話要約 : 生成 AI が応対内容を自動要約し、オペレーターが利用するカスタム CCP（Contact Control Panel）画面に表示（課題 3 に対応） コールリーズン分析 : 通話内容から問い合わせ理由を自動分類し、データ活用を促進（課題 4 に対応） 法令チェック : オペレーターの説明漏れ等を生成 AI で全件自動チェック（課題 3 に対応） ダッシュボード : リアルタイムの応答状況や実績データを可視化（課題 4 に対応） 図 2 会話要約の活用イメージ 図 3 コールリーズン分析・法令チェックの活用イメージ 技術ポイント: 生成 AI の活用 ここからは、SEEDS の中で技術的にチャレンジングだった要素の一つとして、生成 AI の活用について掘り下げます。 アーキテクチャ設計 Amazon Connect Customer を中心に、 AWS Lambda と Amazon Bedrock を連携させた構成です（図 4）。生成 AI の処理を Amazon Connect Customer の外部に配置し Lambda から Amazon Bedrock を呼び出す設計としたのは、AWS マネージドサービスの中で多様な AI モデルを柔軟に活用できるためです。電力・ガス事業特有の表現や複雑な業務ルールに対応するプロンプトを自由に設計・改善できる柔軟性を確保することを重視しました。また、業界知識の深い実務担当者が単独でプロンプトの修正や評価を行える環境を別途用意し、プロンプトの更新の際には直接プログラムを改修せずにプロンプトファイルの差し替えで環境に反映できる構成としています。 なお、同様のユースケースに取り組むお客さまにとっては、Amazon Connect Customer の ビルトイン AI 機能 （会話要約やテーマ検出など、日本語を含む多言語に対応）を活用し、カスタム実装なしで実現するアプローチも選択肢となります。 図 4 SEEDS Phase1 アーキテクチャ構成（ダイジェスト版） この構成には、タスクの特性に応じて 2つの処理系統 を設けています。 リアルタイム系統（会話要約） : 終話後すぐにオペレーターへ結果を返す必要があるため、通話中にストリーミングされるリアルタイム通話テキストを入力とし、高速な応答が得られる Anthropic Claude Haiku（Amazon Bedrock 上で利用可能な軽量・高速モデル）で処理します。レスポンス性を最優先とした設計です。 バッチ系統（コールリーズン分析・法令チェック・VoC 抽出） : 後続の分析処理は翌営業日以降に行われるため、終話後に確定した完全な通話テキストを入力とし、より高い推論能力を持つ Claude Sonnet（同じく Amazon Bedrock 上で利用可能な高性能モデル）で処理します。処理結果の品質を最優先とした設計です。 いずれの系統でも、Amazon Bedrock の Tool use（関数呼び出し） 機能を活用し、出力を JSON スキーマに沿った構造化データとして取得しています。自由形式のテキスト出力をパースする方式と比較して出力形式の安定性が高く、後続のデータベース保存やダッシュボード連携を一往復の API 呼び出しで確実に完結させています。 なお、基盤モデルはリリース時点では Claude 3.5 Sonnet / Claude 3 Haiku を使用していましたが、2026 年からはパフォーマンスが向上した Claude Sonnet 4.5 / Claude Haiku 4.5 に更新しています。マネージドサービスの利点として、このようなモデルの進化を迅速に取り込むことができます。 各タスクの実装ポイント 会話要約 : 終話後カスタム CCP 画面へ要約を表示します。プロンプト開発時には現場のオペレーターにヒアリングを行い、業務用途を明確にした上で出力フォーマットに反映しました。現場からは 「箇条書きで簡潔に読める」「応対後の処理業務などの参考になる」 と評価されています。要約情報はオペレーター間の通話転送時にお客さま情報を引き継ぐ用途にも活用されているほか、お客さまの声（VoC）の自動抽出も実施し、従来人手で拾いきれなかった細かなニーズやご不満の声を網羅的に収集できるようになりました。 コールリーズン分析 : 64 分類での自動判定を実現し、約 600 件のテストデータで 網羅性 95%・正解率 85% と、目標を上回る精度を達成しました。精度向上の工夫として、生成 AI の出力に対してルールベースの後処理を組み合わせ、AI 単体では解消しにくい誤分類を補正しています。分類結果は呼量分析や呼量予測の精緻化に活用され、オペレーター配置計画の改善につながっています。 法令チェック : 従来はサンプリングによるモニタリングでしたが、生成 AI により低コストで自動実行が可能になったことで、 全件の AI 自動検知 を実現しました。検知ロジックでは、プロンプト内に判断フローを定義し、生成 AI が各ステップの判断根拠を出力しながら段階的に判定を進めます。これにより、複数の条件が絡み合う複雑なルールに対しても精度の高い検知を実現し、応対品質の向上とコンプライアンス遵守の両立を図っています。 生成 AI 活用を組織に定着させる TEPCO EP にとって、コンタクトセンター業務への生成 AI 適用は参考にすべき前例がほとんどない技術チャレンジでした。業務で適切に活用できる高精度なプロンプトを作成するには、生成 AI の特性を理解した上で 業務課題と正面から向き合う 必要があります。そこで段階的に AWS の支援を活用し、生成 AI 活用を目的化せず業務課題の解消を明確に目的設定するプロセスを重視しながら、組織にノウハウを蓄積していきました。 まず、プロジェクト開始前に構築ベンダーと AWS Prototyping Team の支援のもと POC を実施しました。サーバーレスサービスを活用して最小限の MVP 構成を素早く構築し、 実務担当者を含むステークホルダーに生成 AI の使用感を早期に体感 してもらえたことで、その後の要件定義に大きく役立ちました。 次に、各ユースケースの課題定義と実現方法の検討にあたっては、 AWS 生成 AI イノベーションセンター を活用しました。「何を」「どのレベルで」実現するかという タスク設定を技術的に明確化し、評価の枠組みを整えた ことで、後続のプロンプト開発を効率的に進める土台ができました。 続いてプロンプト作成・精度評価については、 AWS Professional Services と協力して進めました。支援の前半は AWS 主導でプロンプトを開発し、後半は TEPCO EP のメンバーが主体となってプロンプト修正と結果分析の試行錯誤を繰り返す形をとりました。 データ準備の重要性やプロンプト評価の手法 など、プロジェクト全体を通じて幅広い知見を得ることができ、この過程で実務担当者 11 名が生成 AI の特性を理解した上でプロンプトを設計・評価するスキルを習得しました。2025 年 12 月の Phase1 完了以降は、 実務担当者が単独で継続的な改善を行える体制 が構築されており、今回の取り組みにより生成 AI 活用の基盤を築くことができたと考えています。 Phase2: よりエージェンティックなコンタクトセンターへ Phase1 で得られた知見をもとに、TEPCO EP では Phase2 としてさらに高度な AI 活用を推進します。Phase1 では主に課題 3・4（応対後の処理負荷、データ活用）にアプローチしましたが、Phase2 では課題 1・2（IVR の複雑さ、スキルミスマッチ）の解消にも踏み込みます。目指すのは「 オペレーター自己完結化 」、すなわちオペレーターが必要な情報に迅速にアクセスでき、応対に集中できる環境の構築です。 TEPCO EP が検討している具体的な取り組みは以下の二つです。 一次応対の自動化 : 従来の IVR を廃止し、自然な会話形式でお客さまの用件を聞き取り、適切なスキルを持つオペレーターに振り分けます。Phase1 で培ったコールリーズン分析の知見を活用し、お客さまが用件に合った窓口へスムーズに到達できるようにすることで CX 向上を図ります。 オペレーターのリアルタイム支援 : お客さまとの会話内容をリアルタイムに分析し、関連するナレッジや手続き情報を自動的に表示します。応対後の後処理についても、登録内容の自動入力や手順ガイドを提供することで、保留や管理者へのエスカレーションを削減し自己完結率を高めます。 これらの実現に向けて、技術的な選択肢を補足します。Amazon Connect Customer では Agentic AI 機能が大幅に強化されており、たとえば一次応対の自動化には自然言語による会話ボット機能が、オペレーター支援にはリアルタイムナレッジ検索やステップバイステップのガイド提供機能が、それぞれ活用できます。Phase1 で構築した Amazon Connect Customer 基盤の上に、これらの機能を段階的に追加していくアプローチが可能です。 図 5 Amazon Connect Customer の Agentic AI 機能概要 まとめ TEPCO EP の事例から、実務担当者が中心となった CX 改善の取り組みにおける重要なポイントを整理します。 CX を起点に技術を選定する : 業務課題を明確にし、それを解決する手段としてクラウドと生成 AI を位置づける マネージドサービス中心のシンプル構成 : 標準機能の活用で開発スピードと保守性を両立し、モデル更新も迅速に取り込む 実データで試行し段階的に精度を高める : 生成 AI のチューニングは実データで検証し、精度と実用性のバランスを追求する スキルを組織に定着させる : プロンプトチューニングや精度評価のスキルを内製化し、自走での改善体制を構築する コンタクトセンターの CX 向上や、Amazon Connect Customer と 生成 AI の活用にご興味のあるお客さまは、お気軽に AWS までご相談ください。 著者について 今野 拓也 東京電力エナジーパートナー株式会社 サービスソリューション事業部 副部長 2007 年東京電力入社。オール電化推進営業、顧客向け Web サイト企画・構築を経て、2019 年より新サービス関連業務・システム構築に従事。2020 年に AI コンタクトセンター（AICC）構築を担当。2025 年よりコール・チャット等運営の統括責任者として新規音声基盤の企画・構築を推進し、現在はサービスソリューション事業部 副部長としてシステム全体統括および SEEDS プロジェクト PM を務める。 橋井 雄介 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト エネルギー・ユーティリティ業界を担当するソリューションアーキテクト。お客さまのクラウド活用と生成 AI 導入を技術面から支援している。

このBlog postは Open Governance for MySQL: A Step Forward for the Community の日本語訳です。 MySQL — 世界中の数百万のアプリケーションを支えるオープンソースデータベース — が新たな章を開きます。本日、Oracleは、より広範なコミュニティがプロジェクトの開発と方向性に参加するための道筋を作る、 MySQLのコミュニティガバナンスモデルを発表 しました。 このポストでは、AWSがこの動きを支持する理由と、MySQLコミュニティにとっての意味を説明します。 オープンガバナンスがオープンソースを機能させる 多様なコントリビューターと透明性のあるガバナンスを持つオープンソースプロジェクトは、より良いソフトウェアを生み出します。オープンガバナンスは、ユーザーからコントリビューター、そしてリーダーへの明確な道筋を示し、組織がプロジェクトの将来にエンジニアリングリソースなどを投資するを自信を与えます。 MySQLは約30年にわたり、インターネットインフラストラクチャの基盤となってきました。スタートアップから世界最大の企業まで、数十万の企業が最も重要なワークロードをMySQL上で実行しています。コミュニティの参加方法を明確化することで、その基盤が強化され、MySQLの利用者が将来を見据え、ビジネスを構築するための判断材料に役立ちます。 新しいガバナンスモデルの仕組み OracleがMySQLを買収して以来初めて、Oracle以外の組織がエンジンの構築方法と方向性において定義された役割を持つことになります。このモデルは、役割の段階を作ります：コントリビューターがコードと修正を提出し、コミッターが変更をレビューして承認し、プロジェクトリードがオプティマイザーやInnoDBなどの主要サブシステムを所有します。 これらの役割の上に、MySQLの長期的な方向性とリリースポリシーを設定するステアリングコミッティがあります。コミッティには、Oracle以外から4つの席があり、クラウドプロバイダー、MySQLの顧客、オープンソースコミュニティが占め、Oracleが過半数を持ちます。Oracleが最初のメンバーを2年の任期で指名し、その後、Oracle以外の席はコミュニティによる投票により決定されます。 これらすべてを支えるため、これまで存在しなかった外部コラボレーションとコントリビューションのためのチャネルとして、OracleはMySQLコミュニティのためのパブリックGitHubを立ち上げました。 AWSがこれを支持する理由 AWSは15年以上にわたり、ユーザーとして、コントリビューターとして、そしてMySQLに依存するサービスの構築者として、MySQLに深く投資してきました。今日、数万のお客様がAWS上でMySQLワークロードを実行しています。MySQLは私たちのエコシステムで最も重要なデータベースの一つであり、お客様はその長期的な健全性に直接的な利害関係を持っています。 AWSでは、オープンソースはすべての人にとって良いものであると信じており、オープンソースの価値をお客様に、そしてAWSの運用上のオペレーショナルエクセレンスをオープンソースコミュニティにもたらすことにコミットしています。そのコミットメントはシンプルな形で現れます：お客様がAWS上でオープンソースデータベースを実行して問題に遭遇した場合、私たちはアップストリームに対してMySQLを利用するすべてのユーザのために修正に取り組みます。 私たちにはまさにこれらを行ってきた実績があります。PostgreSQLでは、VACUUMを6倍高速化し、アップグレード時にレプリケーションスロットを維持し、autovacuum設定変更の再起動要件を削除しました。LinuxFoundationによるRedisのフォークであるValkeyでは、全文検索とハイブリッドクエリサポートを追加しました。そして、大量のテーブルを持つデータベースのアップグレード時のメモリ不足エラーの修正やヒストグラムエラーの修正など、MySQL自体にもすでにアップストリームに対し修正を貢献しています。 健全なアップストリームプロジェクトは、MySQLに依存するすべての人に利益をもたらします — 自ら運用する人、マネージドサービスを活用する人、またはそれらのシステムにツールや統合を構築する人。より多くのエンジニアがコードをレビューすれば、より多くのバグが発見されます。設計上の決定がオープンに行われれば、リリースされる機能はより幅広い実世界のユースケースを反映します。ガバナンスが透明であれば、組織はコントリビューションが評価され、声が聞かれるという自信を持ってプロジェクトに投資できます。 これは理論ではありません — OpenJDK、Valkey、その他数十のプロジェクトで、幅広い参加がソフトウェアをより良く、コミュニティをより強くした経験です。 私たちはMySQLにもそれを望んでいます。 MySQLコミュニティにとっての意味 このガバナンスモデルは、ユーザー、コントリビューター、エコシステム全体にとって、プロジェクトの長期的な健全性のシグナルです： 品質とセキュリティへのより多くの目 — コミッター、プロジェクトリード、コンポーネント横断的な監視による構造化されたレビュープロセスにより、コードがリリースされる前に、より多くのエンジニアが正確性、パフォーマンス、セキュリティを検証します。 より速いイノベーショ ン — 明確なコントリビューションパスとパブリックなコラボレーションにより、より広範なエコシステムが改善を提案し提供するための障壁が低くなります。 プロジェクトの将来への自信 — Oracle、エンドユーザー、オープンソースコミュニティからの代表を含むステアリングコミッティにより、MySQLの方向性は単一のベンダーだけでなく、それに依存する利用者の利益を反映します。 継続性と互換性 — ガバナンスモデルは、安定性、後方互換性、リリース品質を明示的に優先します。ユーザーとオペレーターは、破壊的な変更を心配することなく改善を採用できます。 より強力なアップストリームプロジェクトは、MySQL上に構築されたすべてのもの — マネージドサービス、セルフホストデプロイメント、ツール、そしてより広範なエコシステム — のより強力な基盤を意味します。 今後の展望 AWSはMySQLステアリングコミッティに席を持ち、プロジェクトのロードマップとリリース決定に直接的な発言権を持っています。私たちは、MySQLを利用しているお客様のためにその発言権を使うつもりです。 AWSは長期にわたってオープンソースコミュニティに貢献しており、お客様のワークロードに最も直接的な影響を与える分野でMySQLプロジェクトに積極的に関与しています： パフォーマンス — 実際のワークロードの実行速度を決定するエンジンの部分に焦点を当てています：クエリオプティマイザー、クエリ実行、インデックス作成、InnoDBストレージエンジン、およびその下のキャッシュレイヤー。 ベクトル検索とインデックス作成 — オープンソースデータベースのベクトル機能を強化してきたAWSの経験が、コミュニティ全体の共同作業に基づいて、MySQLの新しいベクトルサポートに貢献しています。 拡張フレームワーク — MySQLのコンポーネントインフラストラクチャにより、新しい機能はコアサーバーコードに組み込まれるのではなく、定義されたサービスインターフェースを通じて接続するロード可能なコンポーネントとしてリリースできます。これはコミュニティコントリビューションに最もオープンな分野の一つであり、ここに投資する予定です。 これらは、私たちがすでに行っているアップストリームへの貢献の上に構築されています。数十万のお客様のミッションクリティカルなワークロードを実行することで、MySQLの多くのユーザーに影響する実際の問題 — 正確性、安定性、信頼性の問題 — が表面化し、GitHubを通じてコミュニティ全体のための修正に取り組んでいます。 要点はシンプルです：MySQLの開発がオープンになり、AWSはその方向性を形作る席を持ち、すでにアップストリームで修正と改善の貢献をしています。お客様はMySQLをどこで実行してもこれらの恩恵を受けることができます。 Get involved MySQLエコシステム全体の開発者、ユーザー、組織の皆様に、ガバナンスモデルを読み、どのように参加したいかを検討することをお勧めします。オープンソースは人々が参加することで成長します — そしてこのモデルにより、コントリビューションがこれまで以上に簡単になります。 Read Oracle’s announcement Read the Governance model Pravin Mittal Pravin Mittal is Director of Engineering for Amazon Aurora at AWS, where he leads teams building managed MySQL and PostgreSQL services for hundreds of thousands of customers. He represents AWS on the MySQL Community Steering Committee.