re:Invent 2025 でコスト効率（Cost Efficiency）メトリクス を発表して以来、お客様から繰り返し寄せられる質問があります。「自社は他社と比べてどうなのか？」というものです。この問いに答えるため、私たちは直近四半期において、分析への参加に同意いただいた 71,000 社を超える AWS のお客様の匿名データを対象に、最適化のパターンを分析しました。Savings Plans のカバレッジは、あらゆるコスト最適化戦略の基盤となるものですが、それはパズルの 1 ピースに過ぎません。データが示すのは、コスト効率が最も高いお客様では、Savings Plans だけにとどまらず、削減効果を複利的に高める一連のプラクティスを実践しているということです。本レポートでは、トップパフォーマーが何を実践しているのか、そして彼らと同じ成果を実現するためにはどうすればよいのかを、詳しく解説します。 2026 年 5 月時点で、すべてのお客様のコスト効率スコアの中央値は 83、一方で平均値は 79 です。この差は、最適化が進んでいないアカウントによるロングテール（裾が長い分布）によって生じています。 EC2 のメモリメトリクスを有効化すると、推奨事項 1 件あたりの削減率が 8〜30 パーセンテージポイント高くなる傾向がありますが、対象のお客様のうち有効化しているのはわずか 17.7% にとどまっています。 AWS Compute Optimizer の「アイドル状態」および「ライトサイジング」の推奨事項をカスタマイズしているお客様は、カスタマイズしていないお客様よりスコアの中央値が 3〜4 ポイント高くなっています。 直近四半期のデータによると、Savings Plans とライトサイジングを併用している大規模なお客様は、Savings Plans のみを利用するお客様と比べて、新しい世代のハードウェアで実行している EC2 インスタンスの割合が約 60% 多く、コスト効率スコアの中央値の改善も 4 倍速い傾向にあります。 Savings Plans のカバレッジが高いと、ライトサイジングや Graviton による最適化機会が見えにくくなる場合があります。Savings Plans のカバレッジが 95〜100% のお客様では、カバレッジが 0〜25% のお客様と比べて、Savings Plans 以外の最適化機会の合計が 65〜80% 減少することが確認されています。 コスト効率メトリクスとは？ コスト効率は、 AWS Cost Optimization Hub において毎日算出される単一のスコア（0〜100%）で、最適化可能な支出額のうち、すでに十分に最適化されている割合を測る指標です。このスコアは、ワークロードの最適化（ライトサイジング、アイドルリソースのクリーンアップ）とレートの最適化（Savings Plans、リザーブドインスタンス）を 1 つの数値に統合しています。メトリクスの仕組みの詳細については、 コスト効率の発表ブログ をご覧ください。 あなたの効率スコアはどのくらい？ 2026 年 5 月時点で、すべてのお客様のコスト効率スコアの中央値は 83、一方で平均値は 79 です。この差は、最適化が進んでいないアカウントによるロングテール（裾が長い分布）によって生じています。 Cost Optimization Hub を開けば、自社の現在地を確認できます。注記：新しい最適化の推奨事項がリリースされると、スコアが変動する場合があります。 最適化の傾向をさらに理解するため、私たちは支出規模に基づいてお客様を「小規模」と「大規模」の 2 グループに分類しました。これは、概ね中小企業とエンタープライズ企業の区分に相当します。小規模のお客様では、最もスコアが低いお客様と最もスコアが高いお客様との間に 52 パーセンテージポイントの開きがあるのに対し、大規模なお客様ではこの差が 35 パーセンテージポイントとより狭い範囲に集中しています。いずれのグループも、上位層では高い効率スコアに達しています。ここから読み取れるポイントは 2 つあります。 小規模のお客様では、スコアのばらつきが大きく、FinOps プラクティスを本格的に導入しているお客様と、取り組みがまだ初期段階にあるお客様が混在していることを反映しています。 大規模のお客様は、より一貫して最適化を行っています。専任の FinOps チームや Savings Plans 戦略を持つ傾向が高く、その結果としてスコアも高くなっています。 図 1. 小規模・大規模のお客様におけるコスト効率スコアの分布。小規模のお客様は 52 ポイントの範囲に分布し、大規模のお客様はより狭い 35 ポイントの範囲に分布している。両グループともに、分布の上位層では同程度に高いスコアに達している。 高い効率スコアは、どこからでも到達できる スコアが高いお客様と低いお客様の違いを分析した結果、上位 25% のお客様に共通して見られる 4 つの行動を特定しました。 Amazon EC2 のメモリメトリクス Amazon CloudWatch  またはサポートされている サードパーティのオブザーバビリティツール を通じて  EC2 インスタンスのメモリメトリクス を有効化しているお客様は、スコアが高くなる傾向があります。既存の EC2 インスタンスでメモリメトリクスを有効化することは、EC2 のコスト最適化において最も効果の高い施策の 1 つです。多くのインスタンスにおいて、メモリデータがあるかどうかで、ライトサイジングの推奨が得られるか、全く得られないかが決まります。新たな削減機会が表面化することで、一時的にコスト効率スコアが低下する場合がありますが、それは、対処できる削減余地をより多く掘り起こせていることを意味します。EC2 のメモリメトリクスを有効化すると、推奨事項 1 件あたりの削減率が 8〜30 パーセンテージポイント高くなる傾向がありますが、対象のお客様のうち有効化しているのはわずか 17.7% にとどまっています。図 2 は、メモリメトリクスの導入が、さまざまなインスタンスタイプでどの程度削減率を向上させるかを示しています。 図 2. メモリメトリクスの有無によるインスタンスタイプ別の削減率 推奨事項設定のカスタマイズ AWS Compute Optimizer の推奨事項をカスタマイズ しているお客様は、カスタマイズしていないお客様よりスコアが 3〜4 ポイント高くなっています。推奨事項のカスタマイズは、必ずしも削減額の増加に結びつくわけではありません。しかし、それはチームが最適化に積極的に取り組み、エンジニアリングチームに推奨事項を信頼してもらえるよう努めていることを示す先行指標となります。 高い Savings Plans のカバレッジはゴールではない Savings Plans のカバレッジが高いお客様は、コスト効率スコアも高くなります。Savings Plans は最適化済みの支出としてカウントされるため、Savings Plans のカバレッジとスコアには直接的な相関があり、カバレッジを上げればスコアも高くなります。一見するとこれは、「高度に最適化されている」という喜ばしい状況に見えますが、時に誤解を招くことがあります。なぜなら、その背後にあるリソースは依然として過剰なサイズである、あるいはアイドル状態である可能性があるからです。 Savings Plans のカバレッジが 95〜100% のお客様では、カバレッジが 0〜25% のお客様と比べて、Savings Plans 以外の最適化機会の合計が 65〜80% 減少することが確認されています。これらの削減機会は、コミットメントが更新時期を迎えたとき、またはワークロードが変化したときに初めて、再び実行可能になります。大規模・小規模のお客様における削減額については、図 3 をご覧ください。ここから次のポイント、「まず縮小する（Shrink first）」につながります。 図 3. Savings Plans カバレッジが低い場合（0〜25%）と高い場合（90%以上）における、ライトサイジングおよび Graviton による削減額の差 まず縮小し、それからコミットする（複利効果） 最も効率的なお客様は、Savings Plans と能動的なライトサイジングを組み合わせており、コスト効率スコアと実際の総削減額の両方で、より大きな成果を上げています。直近四半期のデータによると、コミットメントとライトサイジングを併用している大規模なお客様は、Savings Plans のみを利用するお客様と比べて、新しい世代のハードウェアで実行している EC2 インスタンスの割合が約 60% 多く、コスト効率スコアの中央値の改善も 4 倍速い傾向にあります。Savings Plans を利用しているお客様のうち、能動的にライトサイジングを行っているのは 47.1% に過ぎず、潜在的な削減機会が手つかずのまま残されています。コミットメントはインスタンスの単価を下げ、ライトサイジングは必要なインスタンスのサイズを縮小します。新しい世代のハードウェアでワークロードを稼働させることで、より高い性能を得ながら、単位あたりのコストも下げられます。時間の経過とともに、追加の Savings Plans がより無駄のない最新のリソース構成に割引を適用するため、これらの削減効果は複利的に積み上がっていきます。 効率スコアを改善する方法 ここまで、トップパフォーマーが何を実践しているかを見てきました。ここからは、これらのインサイトを実際の行動に移していきましょう。以下のステップは、リスクと労力の小さい順に並べてあり、まずは取り組みやすい施策から始めて、信頼と推進力を高めながら、より大きな変革へとつなげていくことができます。 アイドルリソースから始める アイドルリソースのクリーンアップは、最もリスクの低い出発点です。対象となるのは、何の役割も果たしていない可能性が高いリソース、たとえばどこにもアタッチされていない Amazon EBS ボリューム、使用率がほぼゼロの EC2 インスタンス、接続のない Amazon RDS データベースなどです。 AWS Compute Optimizer は、 Amazon Elastic Compute Cloud （Amazon EC2）、 Amazon Elastic Block Store （Amazon EBS）、 Amazon Relational Database Service （Amazon RDS）をはじめとするコンピューティング、ストレージ、ネットワークの各サービスにわたって、 アイドルリソース を特定します。今週初めには、 アイドルリソースの検出対象をさらに 6 つの AWS サービスに拡大し 、アイドルリソースに関する推奨事項の数を 2 倍に増やしました。 これらの推奨事項はすべて、 Cost Optimization Hub に集約された形で確認できます。各推奨事項には、そのリソースをアイドル状態であると判定した具体的な基準が含まれています。たとえば、アイドル状態の EC2 インスタンスとは、直近 14 日間においてピーク時の CPU 使用率が 5% 未満、かつネットワーク I/O が 1 日あたり 5 MB 未満であるものを指します。アクションを実行する前に、そのリソースが本当に不要であるかどうかを確認することをお勧めします。EBS ボリュームについては、Compute Optimizer は削除前のスナップショット作成を推奨しています。これにより、データを復元可能な状態に保てます。RDS については、再び必要になる可能性がある場合は、削除ではなくインスタンスの停止を検討するとよいでしょう。ただし、RDS インスタンスはメンテナンスのため 7 日ごとに 自動的に再起動 される点にご注意ください。そのため、長期的な解決策としては、スナップショットを取得したうえで削除することになります。多数の推奨事項に対応しやすくするために、Compute Optimizer の 自動化機能 を利用できます。この機能は、EBS のアップグレードやアタッチされていないボリュームのクリーンアップに関する推奨事項を、設定した基準に合致した場合に定期的に適用し、スナップショットの作成やロールバックにも対応しています。まずは本番以外の環境から始めて、確信を得たうえで、対象を広げていくとよいでしょう。 リソースをライトサイジングする リソースの ライトサイジング は、大きなコスト削減の可能性を秘めています。メモリデータを有効にすると、Compute Optimizer は、メモリの実際の使用状況も把握できるようになるため、メモリ不足を懸念して保守的な推奨にとどまることなく、EC2 インスタンスの CPU とメモリの両方を適正なサイズ に調整できます。新たな削減機会が表面化することで、最初はスコアが低下する場合があります。しかしそれは、実現可能な削減余地がそれだけ多くあることを意味します。Compute Optimizer は、 RDS および Aurora データベース 、 EBS ボリューム 、 Lambda 関数 、 ECS on Fargate  など、さまざまなリソースについてもライトサイジングの推奨事項を提供します。まずは削減額の合計が最も大きい推奨事項に注目し、本番以外のリソースから着手することで、エンジニアの信頼を得ていきましょう。また、 推奨事項をカスタマイズして 、組織のリスクおよびパフォーマンスの許容度に合った内容に近づけることも検討してください。このカスタマイズは、 Compute Optimizer コンソール から、ルックバック期間、使用率のヘッドルーム、インスタンスファミリーなどの項目について推奨事項の設定を調整することで行えます。これらの設定は、組織全体に対して一度だけ構成することも、パフォーマンスとコストのトレードオフが異なる環境向けにアカウントごとに構成することも可能です。 最適化済みリソースの上にコミットメント購入を重ねる アイドルリソースをクリーンアップし、インスタンスのライトサイジングを終えたら、無駄を削減したリソースに対して Savings Plans を購入します。最大限の削減を得るには、この順序が重要です。先にすべてのリソースに対してコミットメントを購入してしまうと、過剰にプロビジョニングされた容量に割引レートを固定することになり、後からライトサイジングをしても、請求額が下がるのではなくコミットメントが余ってしまいます。別の方法として、 より小さい単位で頻繁に購入を始め 、ライトサイジングの進行に合わせてカバレッジを段階的に増やしていくこともできます。この方法には、将来、大きなコミットメントが一度にまとめて期限切れを迎える「崖」を回避できるという利点もあります。新しい Savings Plans Purchase Analyzer のターゲットカバレッジ機能を利用すれば、一度に大きくまとめてコミットするのではなく、時間をかけて段階的にカバレッジを買い増していくことができます。 進捗を追跡し、改善を繰り返す コスト効率スコアは毎日更新されるため、月曜日に実施したアクションは水曜日までに反映されます。このフィードバックループを活用して、削減機会とコスト効率スコアへの影響を確認し、目標に対する進捗を追跡しましょう。月次・四半期ごとの目標を設定すれば、FinOps チームは、具体的なコスト削減額と結びついたコスト効率の改善成果を示せるようになります。週次または隔週のレビューサイクルを設け、アカウント単位の内訳も確認しましょう。これは、最適化目標を着実に追い続ける必要があり、運用面での規律が求められるチームに役立つとともに、最も効率的に取り組んでいるチームの優れた実践を可視化することにもつながります。 まとめ 私たちは、71,000 社を超える AWS のお客様の最適化パターンを分析し、「最も効率的なお客様が何を実践しているのか？」という 1 つの問いに答えました。トップ層のお客様で実施しているのは、Savings Plans の購入だけにとどまりません。メモリメトリクスを有効化し、コミットする前にライトサイジングを行い、最適化を一度きりのイベントではなく継続的な取り組みとして捉えています。 こうしたトップ FinOps プラクティスを実践することで、戦術的に信頼を積み重ねながら文化の変革を促し、測定可能な形でより大きな削減を実現できます。 Cost Optimization Hub を開いて 、現在のスコアと、最も大きな削減機会がどこにあるかを確認してください。スコアは毎日更新されます。 翻訳はテクニカルアカウントマネージャーの西村が担当しました。原文は こちら です。 Rick Ochs Rick Ochs は、Compute Optimizer や RI/SP 購入の推奨事項など、AWS における最適化関連製品を担当するプロダクトチームを率いています。AWS に入社する以前は、Turbonomic で最適化にフォーカスしたクラウドプロダクトチームを牽引していました。 Raj Mehta Raj Mehta は、Amazon Web Services で 4 年の経験を持つプログラムマネージャーです。大規模にカスタマーエクスペリエンスを向上させることを目的としたクラウドの請求・支払いプログラムを牽引しています。これまでの業務には、クレジット適用システムの自動化、請求データの異常検知の開発、AI を活用した請求ワークフローの構築などがあります。デューク大学で定量分析の修士号を取得しており、お客様がクラウドの請求とどのように関わっているかを理解し、改善するために、データドリブンな視点をもたらしています。 Arun Somalinga Arun Somalinga は、AWS のシニアソフトウェア開発エンジニアであり、バックエンド開発において 10 年以上の経験を持っています。彼は AWS Cost Optimization Hub および AWS Compute Optimizer に携わり、数百万に及ぶ AWS アカウントに対して日々、最適化に関する推奨事項のインデックス化と提供を行うコントロールプレーンシステムを構築しています。以前の業務では、AWS Support において診断ツールを構築し、エンジニアがお客様の問題をより迅速に解決できるよう支援しました。仕事以外では、バドミントンと読書を楽しんでいます。

本記事は「 New in Kiro Web: Build with Spec, GitLab, and more 」を翻訳したものです。 先月、私たちは Kiro Web をプレビュー版として公開 し、皆さんがすでに作業している場所へと Kiro を広げました。ブラウザから Kiro とともにアイデアを探求して変更を形にし、ローカル環境を最初にセットアップすることなくプルリクエストをオープンします。あるいは自律モード（Autonomous mode）でタスクを任せれば、Kiro が最初から最後まで処理します。いずれの場合も、1 つのセッションで複数の GitHub リポジトリにまたがる 1 つの変更を調整できます。公開以降、私たちはワークフローの改善を一通り提供してきました。今回のアップデートでは、開発者の皆さんから要望のあった 2 つの機能をお届けします。構造化されたスペックワークフローがブラウザで実行できるようになり、さらに Kiro Web が GitLab に対応しました。GitLab と GitHub の両方にまたがるセッションも含めてです。 Spec が Web へ スペックは、重要な意思決定を最初に行います。プロンプトから直接コードへ進むのではなく、Kiro とともに「何を作るか」「どのように動作すべきか」「何を含めないか」を、曖昧さや矛盾を最も容易に発見できる、コードを書く前に定義します。実装はレビュー済みのスペックから始まるため、プルリクエストの内容はあなたが承認したものを反映しており、後から軌道修正が必要な「最初の推測」ではありません。Kiro Web は Kiro IDE と同じスペックタイプをサポートしているので、Feature Spec を書いたり、Bugfix Spec を進めたり、作業内容が十分に理解できていて要件・技術設計・タスクを一度にまとめたい場合は Quick Plan を使ったりできます。 Kiro はスペックごとにドキュメントを生成します。要件（requirements）は何を作るかを記録し、設計（design）はアプローチを説明し、タスクリスト（task list）は作業を個別のステップに分解します。これらをブラウザ上で直接レビューし、Kiro とチャットしながら要件を追加したり、設計の一部を考え直したり、作業の分解方法を調整したりしながら磨き上げられます。スペックの準備が整ったら、サンドボックス内で Kiro にすべてのタスク、あるいは特定のタスクを実行させることができ、作業が完了するとプルリクエストがオープンされます。。スペックを保存したい場合や別の場所で続けたい場合は、ドキュメントをローカルマシンにダウンロードできます。 Kiro Web から GitLab を利用する Kiro Web は GitHub に加えて GitLab に対応しました。パーソナルアクセストークンで GitLab を接続し、セッションに GitLab プロジェクトを追加して Kiro に作業を依頼します。Kiro はプロジェクトをサンドボックスにクローンし、変更を加え、皆さんに代わってマージリクエストをオープンします。依頼すればマージリクエストやイシューを確認することもできるので、セッションを離れることなく一覧表示や閲覧が可能です。 Kiro Web は当初から、1 つのセッションで複数のリポジトリにまたがる変更を調整してきました。新しいのは、それらのリポジトリが同じプロバイダー上に存在する必要がなくなった点です。1 つのセッションで GitLab と GitHub のリポジトリを混在させることができ、Kiro はそのすべてを横断的に読み取って変更を調整し、それぞれに応じて GitLab ではマージリクエストを、GitHub ではプルリクエストをオープンします。これは、ある場所の共有ライブラリと、別の場所にあるそれに依存するサービスの両方に変更が及ぶ場合に、たとえそれらのプロジェクトが異なるプロバイダー上にあっても重要になります。 最近のアップデート 公開以降、いくつかの改善も提供してきました。最初にリポジトリを接続しなくてもセッションを開始できるようになり、やりたいことを説明してから、必要に応じて後でリポジトリを追加できます。タスクの途中で Kiro を停止したり、ワークスペースの起動中に進捗を確認したり、メッセージの相対的なタイムスタンプを読んだりできます。また、表示が勝手に飛ぶことなく読んでいる位置に留まるようになったため、長時間の実行も追いやすくなりました。さらに、サンドボックスがどのネットワークモードを使用しているかをより分かりやすくし、デフォルトのサンドボックスディスクを 128 GB に増やし、小さい画面でのレイアウトを整理しました。 今すぐお試しください Kiro Web は、Kiro Pro、Pro+、Pro Max、Power の各サブスクライバー向けに app.kiro.dev でプレビュー提供中です。さらに詳しく知りたい場合は、 Specs ガイドと GitLab ガイドをご覧いただき、 Web changelog をフォローして次に何が提供されるかをチェックしてください。

本ブログは 2026 年 6 月 4 日に公開された Blog “ Amazon Cognito unlocks advanced capabilities with next-generation infrastructure ” を翻訳したものです。 Amazon Cognito は最近、3 つの強化を導入しました。要求の厳しいワークロードに対応する高スループットパフォーマンス、保管時のデータ暗号化を完全に制御できるカスタマーマネージドキー、そして事業継続性を向上させるマルチリージョンレプリケーションです。これらの機能は、拡張性とスケールを考慮して設計された次世代のストレージインフラストラクチャによって実現されています。これらの強化をお客様に提供するにあたり、数億件のユーザープロファイルを移行しましたが、おそらくお気づきになることはなかったはずです。本投稿では、新機能の概要、その背後にあるアーキテクチャ、そしてお客様のアプリケーションを稼働させたままゼロダウンタイムで実現した移行について解説します。 Cognito で利用可能になった新機能 新しいインフラストラクチャへの移行は、単に既存の機能を維持するためだけのものではありませんでした。それは、Amazon Cognito の継続的な改善を可能にしつつ、お客様の課題を解決する機能を提供するための基盤を構築するものでした。 高スループットなパフォーマンス : 新しいアーキテクチャは、モダンなアプリケーションが要求するより高いリクエスト量とスケール要件をサポートしながら、アプリケーションが依存する低レイテンシのパフォーマンスを維持します。これにより、1 つのユーザープールあたり数千万人のユーザーと、1 秒あたり数千トランザクション (TPS) をサポートできます。 カスタマーマネージドキー : お客様は、保管時のデータの暗号化に、 AWS Key Management Service (AWS KMS) に保存された独自の暗号化キーを使用できるようになりました。これにより、セキュリティ制御と機能が強化され、お客様は暗号化キーのライフサイクルを完全に管理できます。 マルチリージョンレプリケーション : お客様は、ユーザーのパスワード、属性、設定を含むユーザープール全体のデータを、選択した別のリージョンの別のユーザープールに同期できるようになりました。これにより、お客様は事業継続計画 (BCP) を実装し、リージョンのフェイルオーバーが発生した場合でも認証の可用性を維持できます。予期しない障害が発生した場合でも、アプリケーションをユーザーが利用し続けられるようサポートします。 イノベーションのためのアーキテクチャ 新しいアーキテクチャでは、ID 操作の拡張性とスケーラビリティを目的として設計された専用のストレージレイヤーを使用しています。新しいアーキテクチャは、以下の設計理念を中心に据えて構築しました。 アイデンティティファーストの設計 : ストレージレイヤーがユーザー ID を理解します。クライアント固有のビジネスロジックは存在せず、ID 管理を超えた一般化も行いません。これにより、システムは焦点を絞り、ポータブルで最適化された状態を保ちます。 後戻りできない選択を避ける : アーキテクチャの選択を後から変更可能な状態に保ちながら、価値を段階的に提供します。これにより、新たなニーズが生じた際に進化できます。 後方互換性 : 基盤となるインフラストラクチャへの変更が、お客様のアプリケーションの動作を決して損なわないようにします。 これらの理念が、すべてのアーキテクチャ上の意思決定を形作りました。このアーキテクチャは、独立してデプロイ可能なドメインに分割されています。以前は、 Amazon Cloud Directory を使用していたため、サービスアーキテクチャはすべての顧客情報を永続化するために単一のデータストアに依存していました。これにより、シンプルなデータ走査が可能になりましたが、新機能が必要になった際にデータベーススキーマを調整するには複数サービス間の調整が必要でした。新しいアーキテクチャでは異なるデータセットを使用しており、それぞれが独立して進化できるため、より迅速な機能の反復改善が可能になります。 ゼロダウンタイムでの移行 ユーザーの移行には細心の注意が求められ、すべてのステップでダウンタイムゼロを維持し、データの整合性を確保するために設計された戦略が必要です。私たちのアプローチでは、次の施策を通じて、即時の安定性と長期的な柔軟性の両方を優先しています。 シャドウモード検証 : 顧客の API リクエストを新旧両方のインフラストラクチャに同時に流し、レスポンス構造、ステータスコード、動作特性を比較しました。この検証は、比較中に機密情報が平文で公開されることが決してないように設計されています。たとえば、システム間でタイムスタンプがわずかに異なる場合があるといった既知の差異を考慮し、意味のある不一致のみが対処すべきアラートとして表面化するようにしました。 データバックフィル: ユーザープールを新しいインフラストラクチャに切り替える前に、レガシーシステムから既存のすべてのユーザーレコードを新しいストレージへ一括投入（バックフィル）しました。この反映は本番トラフィックの裏側で並行して実行され、後述のデュアルライトによってバックフィル期間中に行われた変更を取り込み、データの損失や古いデータの参照が発生しないようにしました。シャドウモードはバックフィルの検証レイヤーとして機能しました。データ同期におけるエッジケースへの対応を進めるにつれてシャドウモードの一致率が上昇し、切り替えに進む前にデータの完全性を確認できました。 デュアルライトアーキテクチャ : すべての ID 操作をレガシーサービスと新サービスの両方に同時に書き込むシステムを実装し、整合性を確保するための包括的な検証を行いました。新しいインフラストラクチャへのデュアルライトが失敗した場合でも、操作はレガシーシステムで引き続き成功し、顧客が開始したすべてのリクエストが保持されます。これはつまり、デュアルライトの失敗は内部的な整合性の問題として封じ込められ、顧客に影響を与えなかったということです。 アンチエントロピー検証 : 新旧のインフラストラクチャ間でレコードを継続的に比較し、データの乖離を検出して解決するデータ検証および修正システムを実装しました。アンチエントロピースキャンでは、ユーザー属性、認証情報のハッシュ、グループメンバーシップ、設定などのレコードを比較しました。真の不一致が見つかった場合、システムはレガシーシステムを信頼できる情報源 (source of truth) として使用し、自動的にそれらを調整しました。このレイヤーは、シャドウモードとデュアルライトだけではカバーできないエッジケースを捕捉できました。 ロールバック機能を備えた段階的ロールアウト : 即時ロールバック機能を備えた、制御されたデプロイフェーズを確立しました。ユーザープールを新しいインフラストラクチャに切り替えた後も、すべての書き込みをレガシーシステムへ複製し続け、データの損失なしにいつでもユーザープールをレガシーインフラストラクチャに戻せるようにしました。移行中にロールバックが必要になった場合、オーケストレーターがタイムスタンプ順にエントリを再適用し、ユーザープロファイルをレガシーシステムに同期し直しました。 インフラストラクチャモダナイゼーションから得られた教訓 このモダナイゼーションを通じて、私たちはあらゆる大規模インフラストラクチャプロジェクトに適用できる貴重な原則を学びました。そのため、皆様が同様の移行を実施する際の参考になるよう、これらの学びを共有することにしました。 顧客のアクセスパターンがアーキテクチャの意思決定を左右する : 実際の顧客のアクセスパターンを分析した結果、ID ワークロードは予測可能なパターンに従うことが明らかになりました。これは、完全性と運用のシンプルさのバランスを取った同期型のデュアルライトアプローチを採用できることを意味していました。この原則は、あらゆるドメイン固有の移行に適用できます。汎用的なソリューションに手を伸ばす前に、ワークロードの実際のアクセスパターンを理解しましょう。 動作の保持には従来のテストを超えた技術が必要 : 新旧のシステム間で同等の機能を確保することは簡単でした。しかし、まったく同じ API の動作を保持することは簡単ではありませんでした。機能テストは意図された動作を検証しますが、特定の API の動作を前提に顧客がアプリケーションを構築しているシナリオを特定しました。そのような場合、変更によって顧客のアプリケーションが気づかないうちに壊れてしまう可能性がありました。たとえば、同じユーザーへの同時書き込みが、新旧のシステム間で最終的に異なる状態に収束する可能性があります。書き込みはすべて成功しますが、結果がわずかに異なるのです。同様に、属性を書き込んだ直後にそれを読み取る顧客は、整合性ウィンドウの影響を受けます。更新が反映されるタイミングのわずかな違いが、古いデータの読み取りを引き起こす可能性があります。これらは機能的な障害ではありませんが、実際のトラフィックパターンにおける動作は変化する可能性があります。シャドウモードでの検証により、自動テストだけでは見逃していたエッジケースが浮き彫りになりました。これらの技術には早期に投資しましょう。 段階的な検証は、テストだけでは得られない信頼性を築く : それぞれが異なるアクセスパターンをカバーする複数の独立した検証技術（シャドウモード、デュアルライト、アンチエントロピースキャンなど）を、組み合わせて適用しましょう。単一のアプローチですべてを検出できることはなく、それらの間の隙間こそが本番環境の問題が潜む場所です。即時ロールバック機能を備えた段階的なロールアウトにより、各ステップを検証しながら、迅速に元の状態に戻す能力を維持できます。 ご自身のモダナイゼーションプロジェクトで押さえるべき主要原則 : 目的に特化したソリューションに投資し、拡張性を考慮した設計を行い、段階的な検証を実装しましょう。あるいは、マネージドサービスを利用すれば、アプリケーションを稼働させ続けながら、手間をかけることなくインフラストラクチャが改善され、ビジネスニーズに集中できるようになります。 まとめ 本投稿では、最新の ID 管理機能の基盤を構築する Amazon Cognito のインフラストラクチャモダナイゼーションから得られた全体的なアプローチと学びを共有しました。新しい Cognito インフラストラクチャはすでに稼働しており、カスタマーマネージドキーやマルチリージョンレプリケーションといった機能を提供しています。移行が進むにつれて、すべての Cognito のお客様は、現在ご利用中のものと同じサービス上で、特別な操作を必要とすることなくこれらの機能を利用できるようになります。 認証インフラストラクチャをモダナイズする準備はできましたか？詳細については、 Amazon Cognito をご覧ください。   Howie Li Howie は Amazon Web Services のプロダクトマネージャーで、認証をデフォルトで簡単にすることに取り組んでいます。仕事以外では、旅行を通じて文化や食を探求したり、それらにインスパイアされた新しいアイスクリームのフレーバーを考案したりすることを楽しんでいます。 Georgi Baghdasaryan Georgi は Amazon Web Services のプリンシパルエンジニアであり、組織が大規模にアクセスと認証を安全に管理できるよう支援するアイデンティティシステムを構築しています。彼のより広範な関心は、お客様がクラウドで安心して運用できるようにする、信頼性が高く影響力の大きいインフラストラクチャにあります。仕事以外では、新しい抹茶ラテのレシピを試したり、長距離のサイクリングを楽しんだりしています。 本ブログは Solutions Architect の松井 僚太郎が翻訳しました。

AWS は 2026 年 4 月 18 日 – 22 日にラスベガスで開催された世界最大の放送機器展「NAB Show 2026」に出展し、 30 を超えるデモを展示 しました。全デモの 83% に AI が組み込まれ、 そのうちの半分の展示に AI エージェントが採用されるなど、さまざまなメディアワークフローに AI が組み込まれていました。 AWSメディアセミナーでは、NAB Show に参加したソリューションアーキテクトの井村紀彦と小南英司が登壇し、AWS ブース展示の中から注目度の高いトピックを厳選してご紹介しました。 本セミナーは AWS Black Belt Online Seminar シリーズ として資料を公開しています。 NAB Show 2026 recap メディア & エンターテインメント業界編 [ 資料 ][ 動画 ] Multiplatform Distribution — クラウド × IP × AI でライブ配信を再定義 MXL（Media eXchange Layer）— 11 社相互運用で業界標準が現実に 本エリアで最もインパクトが大きかったのが MXL v1.0 の正式リリースです。非圧縮メディアを超低遅延で交換するクラウド共通規格が存在しなかったために、これまでのライブ制作では環境がベンダーロックインされてしまったり複雑なインテグレーションを自前で行う必要があったりと困難が生じていました。NAB Show のデモでは、 Amazon EC2 上の共有メモリと EFA RDMA を活用し、11 社が映像や音声、メタデータを放送品質で相互に共有しました。多くの製品間で相互運用性が成立することを示した点が画期的です。 3つの AI エージェントでライブ配信障害を End-to-End で診断 ライブ配信の障害特定はこれまで時間と専門知識を要する課題で、視聴者から「映像が止まった」との問い合わせが来た際に、エンコーダーや途中経路、CDN などのどこが原因なのか、切り分けに多大な時間を要していました。会場で常に人だかりができていたこのデモでは、 Amazon Bedrock AgentCore と Strands SDK で実装した 1 つの Supervisor と 3 つのサブエージェントが、MCP（Model Context Protocol）を介して各データソースを統一的に分析します。本デモはこれらのバックエンドを 2 つの UI から利用できる点も特徴的で、非技術者向けの AI アシスタント Amazon Quick と技術者がトラブルシューティングやデプロイを行う AI IDE の Kiro を、利用者のスキルに応じて入口を選べます。実装サンプルは GitHubで公開 されており、任意の AWS アカウントへのデプロイが可能です。 その他の注目展示 AWS Elemental MediaConnect Router は、SDI マトリクスや IP ルーターを使わずにクラウド上でライブ映像フィードのルーティングや切替を API 経由で制御することが可能な AWS サービスです。TAMS（Time-addressable Media Store）は BBC が開発をしたオープンソースプロジェクトで、 Amazon S3 上に保存したライブ素材を TAMS 対応ソリューションを介して追っかけ編集したりプレビューしたりすることを紹介しました。また、AI ブランドセーフティのデモでは Amazon Bedrock と Amazon Rekognition 、 Amazon Transcribe でライブニュース映像をリアルタイムにカテゴリ分析して、適合した広告のみを配信する仕組みを展示しました。 Content Creation — コンテンツ制作 AWS Elemental Inference — 複数デモで存在感を示した今年最大の注目サービス AWS Elemental Inference は、AWS 初のライブ映像向け AI サービスで、追加の制作チームや特別な AI 専門知識を準備することなく、リアルタイムに縦型フォーマットに自動変換し重要シーンのハイライトクリップを自動抽出可能です。 AWS Elemental MediaLive や AWS Elemental MediaConvert と統合されており、既存ワークフローにそのまま組み込めます。Fox Sports での採用も発表されています。 その他の展示 Kiro を用いて Adobe Premiere Pro のネイティブプラグインを半日で開発するデモや、ComfyUI を Amazon EKS 上でコンテナ化することで GPU 環境を安価に実現する AI クリエイティブ環境、 AWS Deadline Cloud による最大 85% コスト削減のレンダリング最適化、Avid Content Core によるクラウド MAM 環境なども展示されました。 Media Lifecycle Management — アーカイブを収益源へ 本テーマは「アーカイブをコストセンターから収益源へ」で、メタデータの自動付与やメタレス検索などの検索の高度化、コンプライアンスや契約のチェックを行う利用可否の判定、多言語翻訳やニュース自動編集を行う作業の自動化の 3 軸で展示が行われました。 AI エージェントによるコンテンツ審査・契約書チェックの自動化 利用可否の判定で多くの来場者の注目を集めていた展示はコンテンツ審査の自動化です。 Amazon Nova で映像全体を分析してレーティングとモデレーションフラグを検出し、Amazon Bedrock Agents で権利検証とメタデータ品質管理を自動化することで、審査サイクルを大幅に短縮し、コンプライアンス基準への一貫した準拠を実現します。また契約書の構造化も多くの来場者を集める展示でした。膨大な PDF に埋もれた権利契約やライセンス、人材契約を、25 種のAI エージェントが分析し、 Amazon OpenSearch Service で検索可能なメタデータに変換します。これにより数十年分の契約を数秒で検索でき、権利判断の意思決定を大幅に加速することが可能です。 その他の展示 検索の高度化では Media2Cloud によるフレームレベル動画分析と、 MediaLake による自然言語によるマルチモーダル検索が展示されました。どちらもオープンソースで公開されており、すぐにデプロイ可能です。作業の自動化では Amazon Bedrock などを用いた 20 言語以上の字幕や吹替自動化が展示されました。 Revenue Generation — 収益の創出 本エリアでは、AI を用いることで中小企業が数分でテレビ広告を自動生成するデモ、広告エージェントによるメディアプラン立案の短縮、ライブスポーツ配信における文脈判断による広告挿入などが展示されました。 Builder Zone 製品開発チームによる高度な技術ディスカッションエリア「 Builder Zone」では、AWS Elemental Inference による縦型動画やハイライト自動生成、 AWS Elemental MediaConnect によるライブ配信品質監視（MQAR）と自動フェイルオーバー、AWS Elemental MediaConnect Router によるクラウドネイティブ映像ルーティング、 Amazon CloudFront の CBOR Web Token (CWT)/Common Access Token (CAT) によるミリ秒以下の認証トークンの展示がありました。 おわりに 本ブログでは、NAB Show 2026 の AWS のブース展示を 4 つのテーマで振り返りました。今年の展示が示した方向性は、(1) AI がリアルタイムを制す (2) IP × クラウドでソフトウェア化を加速 (3) アーカイブが”動く資産”になる (4) コンテンツ制作の民主化でした。セミナーにご参加いただいた皆さま、ありがとうございました。メディアチームでは、業界の皆様に役立つ情報を引き続きセミナーやブログで発信してまいります。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

本記事は「 Introducing the Kiro merch store 」を翻訳したものです。 2026 年 6 月 15 日、Kiro 公式グッズストアを shop.kiro.dev にてオープンしました。これまで Kiro を使って最高の仕事を生み出してきた皆さんが、今度はそれを身にまとえるようになりました。 Kiro コミュニティは、オープンに発展し、プロジェクトを共有し、ハッカソンに参加し、ワークショップに加わるなど、さまざまな活動を続けてきました。このたび Kiro グッズをお届けできることを、私たちは大変うれしく思っています。コミュニティの選択肢がさらに広がり、カンファレンス会場の向こうに別の Kiro ユーザーを見つけたり、お気に入りの Kiro グッズを身につけてハッカソンに参加したり、ラバーダック（アヒルのおもちゃ）の代わりに Kiro のぬいぐるみを使ってデバッグするような、そんな楽しみが生まれます。 コレクションの内容 まずはアパレル、小物、アクセサリーにわたる 15 アイテムからスタートします。 アパレル : ヘビーウェイトのパーカー、T シャツ、キャップやニット帽、さらにはローカットスニーカーまで。Kiro のゴーストがあしらわれた、普段使いにぴったりのアイテムがそろっています。 Kiro コレクションのアパレルアイテムの一例 小物 : ウォーターボトル、メカニカルキーボードのキーキャップ、そして長時間の開発に寄り添う Kiro ゴーストのぬいぐるみなど、実用的な定番アイテムから選べます。 Kiro コレクションの小物アイテムの一例 アクセサリー : 仕上げのひと品として、ラップトップ収納付きのロールトップバックパック、エナメルピン、そして持ち物を彩るさまざまなステッカーをご用意しました。 Kiro コレクションのアクセサリーアイテムの一例 意図を込めたデザイン 質の高いアウトプットは、質の高い意図から生まれると私たちはそう考えています。デザインにも同じ基準を適用し、すべての要素を Kiro のブランド、開発者文化、そして一貫したルックアンドフィールへとさかのぼって紐づけています。これらのアイテムは、Kiroの存在感をさりげなく演出してくれるので、単に「好きだから」という理由で身につけたり使ったりしても、まるで歩く広告塔のような気分になることはありません。 これをしっかり実現するには、細部へのこだわりが欠かせませんでした。たとえば、1 か月で表面がテカってしまわない本物の PBT 製キーキャップ、長時間の着用でも快適で、もたつかずに重ね着できるヘビーウェイトのパーカーと T シャツ、そしてすばやく取り出せる専用サイドジッパー付きの 16 インチラップトップ収納などです。 グッズを通じてブランドに命を吹き込み、世界中の開発者にとって Kiro コミュニティをより身近なものにできることを、私たちはとてもうれしく思っています。これほど開発者に寄り添ったものを作り上げる経験は、非常にやりがいのあるものでした。Kiro ストアは、開発者同士がつながり、ブランドの一員だと感じられる場を生み出しています。— Elie Bess, Canary Marketing ストアを立ち上げること自体が、一大プロジェクトでした。いくつかの定番アイテムから、コミュニティに開かれた本格的なストアフロントへと仕上げるには、厳格な品質チェック、物流体制の構築とスケーリング、そして直感的で公式感のあるストア UI への改善の繰り返しが必要でした。今回は v1 であり、今後も磨きをかけ、新しいアイテムを投入し、皆さんのフィードバックをもとに改善を続けていきます。 カートに追加する準備はできましたか？ Kiro コレクションの全ラインナップは、 shop.kiro.dev にて今すぐご覧いただけます。じっくり見て回り、ぴったりのサイズを見つけて、あなたのセットアップに最も合うアイテムを手に入れてください。購入したら、X・LinkedIn・Instagram では @kirodotdev を、Bluesky では @kiro.dev をタグ付けし、#BuildWithKiro を付けて投稿してください。皆さんが選んだアイテムを、ぜひ見せてください。

こんにちは。広告・マーケティング業界を担当するソリューションアーキテクトチームです。いよいよ 6 月 25 日 (木)、26 日 (金) の 2 日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されます。基調講演や数多くの事例セッションとともに、AWS Expo のエリアでは AWS サービス・ソリューションの最新活用事例や、実際に AWS に触れられるデモを、さまざまな角度から体験いただけます。 その AWS Expo エリア内には、製造、金融、自動車、そして私たちの担当する広告・マーケティングなど、業界別に特化したソリューションをご紹介する AWS Industries Zone が設けられます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決の方法をご覧いただける場です。業界に精通したエキスパートと、具体的な活用シナリオについてじっくりご相談いただけるスペースもご用意しています。私たち広告・マーケティング業界担当チームも、このゾーンに今年ならではのテーマで展示を出展します。本ブログでは、その展示内容を一足先にご紹介します。まだ登録がお済みでない方は、ぜひ下記のリンクから。 登録はこちら AWS 展示 A033：行動ログと AI による次世代パーソナライズ —  購買データだけでなく「顧客の迷い」を資産に、自律型顧客体験の実現へ 購買データという「結果」だけに頼ってパーソナライズしていませんか？閲覧、比較、カート放棄など、購入に至らなかった「顧客の迷い」にこそ本音が隠れています。この行動データを全量収集し資産化することで、顧客の真のニーズを捉えられます。本展示では、行動データの自社資産化基盤と、Agentic AI が最適なコンテンツ・タイミングを自律的に判断して届ける次世代の仕組みをご紹介します。 A035：すべての仮説を AI ペルソナで試す時代へ —  ふと浮かんだアイデアを、自社データで即検証 「この層はどう反応するだろう？」ふと浮かんだ仮説をコストや時間を理由に諦めていませんか？本ソリューションは自社の購買・顧客データから AI ペルソナを生成し、思いついたアイデアをその場で検証できます。試して、直して、また試す——このサイクルが数分で回るから、今まで捨てていた “小さな思いつき” すべてをぶつけられます。カスタムプロンプトで検証シナリオも自在に調整でき、ブースで実際にお試しいただけます。ソリューションのコードは aws-samples（GitHub） で公開中 です。 お客様展示 A034：株式会社電通, 株式会社電通デジタル — AI Agent を活用した広告効果分析の効率化 電通/電通デジタルのマーケティング領域における知見をもとに生まれた新たなエージェントサービスは、広告活動に関わる分析・検証業務を対話形式で支援します。広告データ活用において、課題整理から分析実行、結果の取りまとめまでを自然言語で支援することで、専門的知識や個別担当者への依存を抑え、業務効率化と意思決定の高度化に貢献します。AWS を活用した柔軟なエージェントシステムで広告業務全体を横断的に補助し、より多くの方が直感的に高度な判断を行える環境の実現を目指します。 A036：株式会社NTTドコモ — AI エージェント「SyncMe」の基盤に AWS を活用 あなただけのパーソナル AI エージェント 「SyncMe」 は、ユーザーひとりひとりに合わせた体験を提供するために、マルチエージェントアーキテクチャと独自の記憶管理を組み合わせています。本展示では、パーソナライズを行うため「d アカウント情報に基づいたパーソナライズ」と「エージェントとの会話を重ねることによって育まれるパーソナライズ」の 2 点の取り組みが、どのような工夫で実現されているかご紹介します。 あわせて聴きたい — 関連セッションのご紹介 ブース展示をご覧いただいたあとは、ぜひ関連セッションにも足をお運びください。広告・マーケティング業務に直結するセッション、AI エージェントやデータ分析の最新動向まで、いくつかピックアップしてご紹介します。 広告・マーケティング × AI AIM202｜あなたの新しいエージェンティックなチームメイト、Amazon Quick を知ろう （6/25 木 11:30–12:10） 私たちの多くは、情報を活用するよりも探すことに多くの時間を費やしています。Amazon Quick はそれを変えます。ドキュメント、データベース、メール、Slack のスレッド、ダッシュボード、Jira チケットなど、社内のあらゆるデータに横断的にアクセスし、検索、質問、そしてアクションの実行までを一つの場所で完結させます。Web、モバイル、Slack、Microsoft の各種ツールに対応し、マルチモデル AI を搭載。コンシューマー向けの使いやすさと、エンタープライズレベルのセキュリティおよびガバナンスを両立しています。ベンダーロックインも、ツールごとに分断されたコパイロットもありません。あなたがどこで働いていても、一緒に働いてくれる、たった一つの AI チームメイトです。 ANT310｜AWS Analytics MCP サーバーで実現するエージェント型データエンジニアリング （6/25 木 16:30–17:10） 本セッションでは、AWS Analytics Model Context Protocol (MCP) サーバーをご紹介します。Data Processing MCP Server と Amazon Redshift MCP Server を含むこれらのオープンソースツールにより、AWS Glue、Amazon EMR、Amazon Athena、Amazon Redshift を横断するエージェント型ワークフローが実現できます。AIエージェントとの自然言語による対話を通じて、複雑な分析オペレーションをどのように簡素化できるかをご説明します。MCPサーバーの実装戦略、実際のユースケース、デプロイメントのためのアーキテクチャパターン、そしてアナリティクス環境を理解し統制するインテリジェントなデータエンジニアリングワークフローを構築するための本番環境でのベストプラクティスを取り上げます。 AIM343｜生成 AI で「売れる製品」を作る — POC 止まりを突破する 6 つのプロダクトデザイン戦略 （6/26 金 13:00–13:40） 生成 AI への投資額は世界で急拡大し、2029 年には約 18 兆円規模に達すると予測されています。しかし現実には、AI プロジェクトの多くが POC から本番導入に至らず廃止されており、「技術は動くが、売上にはつながらない」という課題に多くの ISV が直面しています。本セッションでは、この「POC の壁」を突破し、生成 AI を持続的な収益成長エンジンに変えるための 6 つの AI プロダクトデザイン戦略を体系的に解説します。テクノロジードリブンではなくバリュードリブンで「ゴールから逆算」するアプローチを軸に、実際に収益化に成功した ISV の具体的な設計手法をご紹介します。 MAM241 ｜ 「統制された自由」の実現 －電通グループ 140 社を支える AI 時代の IT ガバナンス（6/26 木 14:30–15:00） 生成 AI 時代に拡大するクラウド投資とリスクをどう統制するか。電通グループが AWS のエコシステムで実践する、統制と自由を両立するグループ IT ガバナンスの具体例をご紹介します。 AI エージェント全般 AIM201｜本番展開を見据えて：エージェンティック AI に対する実践的アプローチ （6/25 木 11:30–12:10） AI 実証実験の 46 % は本番に届かず消滅する – 同じ経験をされた方も多いのではないでしょうか。本セッションでは、プロトタイプの壁を突破するために必要な 4 つの柱「運用」「データ」「信頼性」「堅牢性」を、これまで AWS が多くのお客様支援から得たナレッジをもとに体系的に解説します。既存サービスの活用判断から、オブザーバビリティ、データ整備、セキュリティ設計、評価の自動化まで、エージェントの価値を最大化するための近道をお伝えします。 AIM216｜エージェンティック AI におけるビジネスインテリジェンスの再構築と民主化 （6/25 木 12:30–13:10） ビジネスインテリジェンス（ BI ）は、AI の進化とともに大きな転換期を迎えています。構造化・非構造化データの統合活用、ワークフロー自動化が進む一方、エンタープライズ環境ではデータサイロや管理コストといった課題が依然として残っています。本セッションではエージェンティック AI を活用した Amazon Quick による BI の再構築について解説します。Amazon 社内での活用を一例として交えながら、誰もがデータから価値を引き出せる環境の実現に向けた具体的なアプローチをご紹介します。参加者は、自社の BI 戦略にエージェンティック AI を取り入れるためのヒントをお持ち帰りいただけます データ分析基盤 ANT209｜データウェアハウスのモダナイズ – 事例とデモで学ぶ Amazon Redshift マルチウェアハウスアーキテクチャ （6/25 木 15:30–16:10） 「ETL が走ると BI が遅くなる」「生成 AI ワークロードを追加したいがリソースが足りない」といった悩みを抱えていませんか？その課題、マルチウェアハウスアーキテクチャで解決することができます。エンタープライズ分析プラットフォームは、集中型で過負荷状態のデータウェアハウスから、分散型でガバナンスが効いた、生成 AI 対応のマルチウェアハウスアーキテクチャへと進化しています。データをコピーする必要もありません。本セッションでは、ビジネスニーズに応じてスケールするデータウェアハウスアーキテクチャの設計方法を学びます。モノリシックな Amazon Redshift クラスターから最新のマルチウェアハウスアーキテクチャへのモダナイゼーションを実事例で紹介し、ETL・BI・生成 AI それぞれを干渉なく動かすデモを通じて、具体的な実現ステップをお持ち帰りいただけます。 まとめ 広告・マーケティングブースでは、AWS 展示 2 つ、お客様展示 2 つの合計 4 ブースで皆さまをお待ちしています。行動ログ × Agentic AI による自律型パーソナライズ、AI ペルソナによる高速仮説検証、そして株式会社電通, 株式会社電通デジタル様・株式会社NTTドコモ様による最先端のお客様事例を学ぶことができます。ぜひエキスパートと直接お話しください。皆さまのご来場を心よりお待ちしております。 AWS Summit Japan 2026 への登録はこちら 著者について 小川　翔 アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 流通小売業界のお客様を中心にクラウド活用の技術支援を行っています。好きな AWS サービスは Amazon Bedrock と、Amazon Personalize です。

本記事は 2026 年 6 月 11 日に公開された Ranjith Ramakrishnan, Dragos Ilinca による “ Introducing Kiro Pro Max ($100/mo): more credits, less guesswork ” を翻訳したものです。 Kiro の 料金プラン は、お客様の多様なニーズと利用実態にお応えできるよう、一貫した思想のもとで設計されてきました。無料プランでは定評あるオープンウェイトモデルを使って気軽にお試しいただくことができ、月額 $20 の Pro プランは軽量なワークフローに対応しています。月額 $40 の Pro+ プランは Kiro を日常的にご活用いただく開発者に適しており、月額 $200 の Power プランは大規模なワークロードに対応しています。しかしながら、多くのお客様から、$40 と $200 の間には大きなギャップがあるとのフィードバックを頂戴しておりました。Pro+ のクレジット上限に達した場合でも、超過利用を有効化することで作業を継続することは既に可能でしたが、超過利用は予測が難しく、費用がかさんでしまうという課題がありました。 Kiro Pro Max: 月額 $100 このギャップを解消する新しいプランとして「Kiro Pro Max」をご紹介します。本プランの主な内容は以下の通りです。 月 5,000 クレジット : Kiro を 1 日数時間以上ご利用いただくプロフェッショナルな開発者向けに設計 全プレミアムモデルへのアクセス : Claude Opus 4.8、Sonnet 4.6、Auto をはじめ、モデルセレクターに含まれるすべてのモデルをご利用いただけます（地域ごとのモデル提供状況に準じます） Power プランと同等の機能セット : スペック、カスタムサブエージェント、Powers、フック、CLI への完全なアクセス 月額 $100 という価格設定は、日々の業務でエージェンティック開発を実践されるお客様にとって有力な選択肢となります。Pro+ の割り当てを常に大幅に超過されているお客様や、超過料金が $60〜70 に達してしまっているお客様にとって、Pro Max は予測可能な定額料金で大幅に余裕のあるご利用を実現します。 対象ユーザー Pro Max は、Kiro を業務の中核ツールとしてご活用いただくプロフェッショナルな開発者向けに設計されています。1 日を通じて複数のプロジェクトでコーディング、スペックの実行、機能のイテレーション、デバッグを行うようなお客様を想定しています。利用可能な最良のモデルにアクセスし、意義のある作業を進めるのに十分なクレジットを確保しつつ、月次支出を明確に管理されたいお客様に最適な選択肢です。 アップグレード方法 6 月 11 日より、アカウント設定画面から Pro Max へ切り替えていただけます。月の途中でアップグレードされる場合、差額は日割り計算となります。日割り計算後の新しいクレジット割り当ては、ただちに有効となります。Kiro を新たにご利用開始されるお客様は、他のすべてのプランと同様に、 $20 のサインアップボーナスクレジット を Kiro Pro Max サブスクリプションにご適用いただけます。 画一的ではなく、柔軟性とコントロールを 無料プランから Power プランまで、Kiro は様々な利用レベルのお客様に対応するサブスクリプションをご提供しております。週末に個人プロジェクトを開発される場合も、1 日 8 時間プロダクションコードを書き続けられる場合も、すべてのお客様に Kiro を最大限ご活用いただけるよう取り組んでいます。優れた開発者体験には柔軟性とコントロールが不可欠であり、料金プランはお客様の実際の作業スタイルに即したものであるべきです。過小あるいは過大なプランをお客様に強いるものであってはなりません。 ぜひこの機会に Kiro をお試しいただく か、 プランのアップグレード をご検討ください。 翻訳は Solutions Architect の吉村が担当いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 いよいよ AWS Summit Japan 2026 が 6 月 25 日（木）、26 日（金）に幕張メッセで開催されます。今週は各業界ブースの見どころを紹介するブログが続々と公開されました。AI Scientist が実験用ロボットを自律操作する創薬向けの  Self-Driving Lab 、AI エージェントが生産ラインのボトルネックを検知して改善する 製造業向けデモ 、ユナイテッドアローズ様・カインズ様の事例展示を含む 流通・小売・消費財・飲食業界向けブース など、生成 AI エージェントが業務の主役になる未来を体感できる展示が目白押しです。ぜひ事前にチェックしてみてください。 それでは、6 月 8 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS Local Executive Roadshow 名古屋編: タキヒヨー株式会社様、非エンジニアが数週間で社内システムを内製化 タキヒヨー株式会社様は、1751 年創業、270 年以上の歴史を持つ繊維・アパレル企業です。経営に必要なデータが Excel に散在し、VBA マクロでの集計に追われていたことや、需要予測データが分析できる形になっていないことが課題でした。これを解決するために、まず Amazon QuickSight でデータを一元的に可視化し、さらに非エンジニアの担当者が Amazon Bedrock 経由の Claude Code を使ってデータ整形ツールを内製開発しました。その結果、通常なら数カ月・数百万円かかるシステムを数週間で構築し、現場が意思決定業務に集中できるようになったそうです。パートナーのクラスメソッド株式会社様とともに、「まずは可視化から始める」という現実的なアプローチが語られている開催レポートです。 AWS Local Executive Roadshow 広島編: 株式会社エイチビーソフトスタジオ様、生成 AI 導入の「3 つの壁」を乗り越える 株式会社エイチビーソフトスタジオ様は、愛媛県松山市を拠点に全社員リモートで開発を手がける企業で、中小企業への生成 AI 導入支援にも取り組んでいます。支援先では、問い合わせ対応が特定の担当者に集中し回答品質にばらつきが出ることや、導入時の「期待値の壁」「ルール（ガバナンス）の壁」「データの壁」が課題でした。これを解決するために、Amazon Bedrock を活用しつつ、ハンズオンによる期待値調整、叩き台ベースでの運用ルール作り、AI に社員へインタビューさせて属人ノウハウをドキュメント化する、といった工夫を重ねました。その結果、対応時間の削減や負荷集中の緩和に加え、「完璧を待たず小さく始める」ドキュメント化の文化が根づいたそうです。 AWS Summit Japan 2026 流通・小売・消費財・飲食業界向けブースのご案内 テーマは「AI エージェントが業務の主役になる日」。「商品をつくる・届ける・売る / つながる」の 3 つの切り口で、バーチャル AI エキスパートやマルチエージェントによる製品開発、サプライチェーンの危機対応など 6 つのデモを体験できます。あわせて、株式会社ユナイテッドアローズ様の「Amazon Bedrock で実現 対話で深まる日報 AI」や、株式会社カインズ様の「AI で進化する顧客体験」といったお客様の事例展示も予定されています。 AWS Summit Japan 2026 製造業ブース「生産ラインの未来」のご案内 AI エージェントが生産ラインのボトルネックを検知し、改善までを一気通貫で支援するデモを紹介しています。需要の増加を検知して影響を分析し、ボトルネックの特定から工程設計書を参照した改善提案、PLC プログラムの改修案づくり、シミュレーション環境での事前検証までを、エージェントとの会話で体験できます。Amazon Neptune や AWS IoT SiteWise、Amazon Bedrock AgentCore などを活用した構成です。 フィジカル AI で創薬が変わる Self-Driving Lab のご紹介（ヘルスケア・ライフサイエンスブース） AWS 上の AI Scientist が実験用ロボットを直接操作し、設計・実行・分析（DMTA サイクル）を 24 時間自律的に回す「Self-Driving Lab」のデモを紹介しています。会場では、3 色の原液の配合比率を AI が自律的に突き止める実演が行われます。アッセイ条件の最適化や製剤処方の設計などにも応用でき、創薬研究の加速が期待できる内容です。 ブログ記事「 AWS、初の一般提供版 Mythos クラスモデルとなる Claude Fable 5 を発表 」を公開 Anthropic の最上位クラス「Mythos」レベルの機能を、強力なセーフガードを組み込んだうえで一般提供する Claude Fable 5 が発表されました。長時間の非同期実行や高度なビジョン機能、成果物を提供する前に自ら結果を検証する能力が特徴で、評価されたほぼすべてのベンチマークで最先端の性能を示すモデルです。Amazon Bedrock と Claude Platform on AWS の 2 つの方法でアクセスできます。なお本記事には 6 月 12 日付の更新があり、米国政府の輸出管理指令への準拠のため、Anthropic の要請により現在 Claude Fable 5 および Claude Mythos 5 へのアクセスは停止されています（Claude Opus 4.8 などの他モデルは影響を受けません）。ご利用前に最新の提供状況をご確認ください。 ブログ記事「 AWS FinOps Agent のパブリックプレビュー提供開始のお知らせ 」を公開 コスト管理を継続的な運用へと進化させるエージェント型 AI ソリューション AWS FinOps Agent がパブリックプレビューになりました。この記事では、コスト異常を AWS CloudTrail のイベントと関連付けて根本原因と責任者を特定し、Jira チケットや Slack に調査結果を届ける仕組みや、エンジニアが「なぜ先月コストが上がったのか」を自然言語で質問できる機能を紹介しています。Workday 様や Mitre 10 様など初期のお客様の声も掲載されています。月次レビューに追われている FinOps チームの方は必見です。 ブログ記事「 AWS DevOps Agent によるネットワークインシデント対応の自動化 」を公開 この記事では、Amazon CloudWatch のアラートを Webhook で受け取った AWS DevOps Agent が、メトリクス・ログ・ネットワークフロー・API 変更履歴を相関分析し、根本原因と修復プランを提示する方法を紹介しています。セキュリティグループの設定ミスや NAT Gateway のルート削除など、すぐに試せる 4 つのシナリオと、複数アカウントにまたがる Transit Gateway の事例を CloudFormation テンプレート付きで解説しています。手動で 1 時間かかっていた切り分けを数分に短縮できる様子は一読の価値ありです。 ブログ記事「 Amazon Bedrock AgentCore でマルチテナントエージェントを構築する 」を公開 SaaS プロバイダーがエージェント型アプリケーションを本番運用するには、テナント分離やコスト配分、セキュリティといった固有の課題に向き合う必要があります。本記事はシリーズ第 1 回として、Amazon Bedrock AgentCore を使ったサイロ・プール・ブリッジの 3 つの分離パターンと、ランタイム分離・トークン伝播・メモリ階層・ガードレールなど 10 個の設計コンポーネントを体系的に整理しています。マルチテナント SaaS でエージェントを設計する際の見取り図として参考にして頂けるのではないでしょうか。 ブログ記事「 Anthropic / OpenAI 互換 API 向けに最適化された Amazon Bedrock の新しいコンソールエクスペリエンス 」を公開 この記事では、最新の GPT・Claude・オープンウェイトモデルに対応する Amazon Bedrock の次世代推論基盤と、その新しいコンソール体験を紹介しています。最大 3 モデルを比較できるモデルカード、プロジェクト単位での作業、プロジェクト変数を自動で埋め込むライブドキュメントなどにより、モデルの発見から本番移行までをスムーズに行えます。Claude Code や Cline、Cursor などの AI コーディングエージェントとの接続手順も紹介されています。 ブログ記事「 キャパシティ対応推論: SageMaker AI エンドポイントにおけるインスタンスの自動フォールバック 」を公開 GPU キャパシティ不足でエンドポイントの作成や Auto Scaling が失敗する、という悩みを解消する Amazon SageMaker AI の新機能「キャパシティ対応インスタンスプール」を紹介する記事です。優先順位を付けたインスタンスタイプのリストを定義しておくと、キャパシティ制約時に SageMaker AI が自動でリストを順に試し、利用可能なインフラ上にプロビジョニングしてくれます。生成 AI モデルの推論基盤を安定運用したい方におすすめの内容です。 ブログ記事「 2026 AWS Life Sciences Symposium ハイライト: 創薬研究領域 」を公開 この記事では、Sanofi 様や Roche 様、ブリストル マイヤーズ スクイブ様といったリーダーが登壇した本シンポジウムから、エージェント型 AI の創薬活用の最前線を紹介しています。目玉は 40 以上の生物学基盤モデルを備えた Amazon Bio Discovery のローンチで、メモリアル・スローン・ケタリングがん研究所の事例では、標的に対してわずか数週間で高い親和性を持つナノボディを設計した様子が語られています。エージェント型 AI が「将来の約束」ではなく本番インフラとして使われ始めていることが分かる内容です。 ブログ記事「 Kiro の Spec が速く、そしてスマートになりました 」を公開 AI を活用した IDE である Kiro の仕様駆動開発（Spec）フローに、3 つの新機能が追加されました。独立したタスクを依存関係に基づいて同時に処理する「並列タスク実行」、要件・設計・タスクを一度に生成する「Quick Plan」、そしてニューロシンボリック AI で要件の曖昧さや矛盾を設計前に検出する「要件分析」です。「構造と品質を求めると遅くなる」という前提を覆す内容で、大きな Spec の実装時間が大幅に短縮されるとのことです。 ブログ記事「 生成 AI で開発ツール操作を自動化 – Kiro × MCP Server × dSPACE ControlDesk 」を公開 自動車の ECU 開発で使われる dSPACE ControlDesk の複雑な GUI / API 操作を、AWS 上に構築した MCP サーバーと Agentic IDE「Kiro」の組み合わせで自然言語から自動化するアプローチを紹介する記事です。Amazon EC2 上の MCP サーバーが API マニュアルやサンプルコードをナレッジとして保持し、Kiro が ControlDesk を操作する Python コードを自動生成します。API 仕様を調べる時間や新メンバーのオンボーディングコストの削減に役立つ、実践的なユースケースとして参考になります。 サービスアップデート AWS、初の一般提供版 Mythos クラスモデルとなる Claude Fable 5 を発表 Anthropic の Mythos レベルの機能を一般提供する Claude Fable 5 が AWS で発表されました。金融・法務・マーケティング・エンジニアリングなどの専門業務向けに設計され、学習結果に基づいてスキルを自律的に更新し、自ら評価ハーネスを開発して成果物を検証します。Amazon Bedrock と Claude Platform on AWS の 2 つの経路でアクセスできます。なお前述のとおり、6 月 12 日以降は輸出管理指令への準拠のためアクセスが停止されているため、ご利用前に最新の提供状況をご確認ください。 Google DeepMind の Gemma 4 モデルが Amazon Bedrock で利用可能に Google DeepMind のオープンウェイトモデル Gemma 4 ファミリーが Amazon Bedrock で利用可能になりました。Gemma 4 31B、26B-A4B、E2B の 3 種類があり、組み込みの推論機能、ネイティブな Function Calling、35 以上の言語、テキスト・画像・動画・音声のマルチモーダル入力に対応します。31B は最大 256K トークンのコンテキストウィンドウを備え、推論やコーディング中心のワークロードに適しています。現在、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、欧州（フランクフルト）で利用可能です。 OpenAI の GPT-5.4 / GPT-5.5 が Amazon Bedrock の米国東部（バージニア北部）で利用可能に OpenAI の GPT-5.4 と GPT-5.5 が、Amazon Bedrock の米国東部（バージニア北部）リージョンでも利用可能になりました。GPT-5.5 は OpenAI の最も高性能なモデルで、高度なコーディングや調査・分析、長時間にわたるエージェント型タスクに向いています。両モデルとも 272K トークンのコンテキストウィンドウとテキスト・画像入力に対応し、Responses API を通じてサーバーサイド・クライアントサイド両方のツール呼び出しやレスポンスストリーミングを利用できます。 Amazon SageMaker AI が NVIDIA Nemotron モデルのサーバーレスファインチューニングに対応 Amazon SageMaker AI が、NVIDIA の 30B オープンウェイトモデル Nemotron 3 Nano のサーバーレスなモデルカスタマイズに対応しました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）が利用でき、独自データでドメインに合わせた調整が行えます。サーバーレスのため、インフラのプロビジョニングや学習のオーケストレーションは SageMaker AI が処理し、使った分だけの課金でクラスター管理から解放されます。アジアパシフィック（東京）を含む 4 リージョンで利用可能です。 Amazon OpenSearch Serverless が Agentic Search をサポート Amazon OpenSearch Serverless で、自然言語でデータをクエリできる Agentic Search 機能が利用可能になりました。「800 ドル未満で東京行きのフライトを検索する」のように尋ねるだけで、システムが意図を解釈し、最適な検索戦略を計画して適切な DSL クエリを生成し、推論内容の説明とともに結果を返します。背後では LLM を搭載した QueryPlanningTool が自然言語を DSL クエリに変換します。OpenSearch Serverless が提供されているすべての商用リージョンで利用できます。 Amazon OpenSearch Service が エージェント型オブザーバビリティ向けの MCP Apps を提供開始 Amazon OpenSearch Service が MCP Apps に対応し、Claude Desktop や VS Code といった agentic IDE の中で直接オブザーバビリティのワークフローを実行できるようになりました。ローカル環境の AI エージェントが、OpenSearch や Amazon Managed Service for Prometheus に保存されたログ・トレース・メトリクス・アラートを使ってインシデントを調査できます。各ツール呼び出しはエージェント向けの要約テキストと、会話内に描画されるインタラクティブな可視化の両方を返すため、環境を離れずに結果を確認できます。 AWS で AI を活用したコスト調査機能が提供開始 AWS Cost Anomaly Detection に、Amazon Q を使って検出されたコスト異常の根本原因を分析する機能が搭載されました。これまで数時間かかることもあったコスト変化の調査が、わかりやすい言葉での説明として数分で得られます。Amazon Q がコスト変化を使用量主導型かレート主導型かを判断し、原因となったサービス・アカウント・リージョンを特定。使用量主導型の変更は AWS CloudTrail と関連付けて、特定の API コールや IAM プリンシパルに帰属させます。すべての商用リージョンで追加料金なしで利用できます。 AWS Cost Explorer で Amazon Q を活用したインテリジェントなコスト説明機能を提供開始 AWS Cost Explorer に「Amazon Q を利用して分析」機能が追加されました。ボタンを 1 回クリックするだけで、設定したレポートに対するコスト傾向・主なコスト要因・異常などの詳細な分析を受け取れます。設定したフィルターと期間はそのまま分析に引き継がれ、過去の日付には履歴の説明、将来の日付には予測の説明が提供されます。会話を通じてコンテキストが維持されるため、フォローアップの質問で深掘りも可能です。すべての商用リージョンで追加料金なしで利用できます。 Amazon Quick が Snowflake Cortex AI との統合に対応 Amazon Quick が、Model Context Protocol（MCP）を通じて Snowflake Cortex AI と統合できるようになりました。Snowflake のマネージド MCP サーバーを OAuth 認証で接続すると、Cortex Analyst を通じた構造化データへの問い合わせや、Cortex Search を通じた非構造化文書からのインサイト取得を、自然言語で実行できます。Quick の Flows で Snowflake Cortex Agents をオーケストレーションし、繰り返し可能でガバナンスの効いたワークフローを構築することも可能です。Amazon Quick が利用可能なすべての AWS リージョンで利用できます。 Kiro のアップデート Kiro CLI 2.7 が公開、/goal ループと Queue Steering を追加 AI を活用した IDE である Kiro のコマンドラインツール Kiro CLI 2.7 が公開されました。目標を達成するまで実装と自己検証を繰り返す /goal ループ、実行中のエージェントにツール境界で指示を割り込ませる Queue Steering、各ターンのツール呼び出しや変更ファイルを一覧できる強化版 /rewind が追加され、エージェントの自律性ときめ細かな制御をより両立しやすくなりました。 Kiro Web が GitLab 連携とブラウザ上での Spec 実行に対応 ブラウザで動作する Kiro Web に、2 つの機能が追加されました。要件・設計・タスクからなる Spec ワークフローをブラウザ上で実行できるようになり、GitHub に加えて GitLab にも対応しています。1 つのセッションで GitLab と GitHub のリポジトリを混在して扱い、それぞれにマージリクエストやプルリクエストを作成できるようになりました。 Kiro の新プラン「Kiro Pro Max」（月額 100 ドル）が登場 Kiro に、Pro+（月額 40 ドル）と Power（月額 200 ドル）の間を埋める新プラン Kiro Pro Max（月額 100 ドル）が追加されました。月 5,000 クレジット（Pro+ の 2.5 倍）とすべてのプレミアムモデル、Specs・カスタムサブエージェント・powers・hooks といったフル機能を利用でき、Kiro を日常的に使う開発者向けの予測可能な定額プランとなっています。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いよいよ AWS Summit Japan 2026 が 6月25日(木)・26日(金) の 2 日間、幕張メッセで開催されます。260 を超えるセッションと 300 以上の展示が集まる、日本最大の “AWS を学ぶイベント” です。 今回はその中から、開発者の方にぜひ立ち寄っていただきたい「Developer Community Zone」をご紹介します。ここは、開発者同士がディスカッションを楽しみ、コミュニティとのつながりを育むインタラクティブなラウンジです。サーバーレスアーキテクチャでコーヒーを淹れる名物アクティベーション 「Serverlesspresso」 を体験できるほか、コミュニティのメンバーと交流できる、Summit ならではの場になっています。 セッションや EXPO の合間に、ぜひ Developer Community Zone に足を運んで、ビルダー同士の”つながり”を体験してみてください。詳細は AWS Summit Japan 2026 公式サイト をご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年6月8日週の主要なアップデート 6/8(月) Amazon OpenSearch Serverless が Agentic Search に対応 Amazon OpenSearch Serverless に Agentic Search 機能が追加されました。自然言語でクエリを記述すると、LLM を活用した QueryPlanningTool が意図を解釈し、適切な DSL クエリを自動生成して検索を実行します。「東京行きの $800 以下の航空券を探して」のような問い合わせに対して、システムが検索戦略を計画し、推論内容のわかりやすい説明とともに結果を返します。Amazon Bedrock の Claude Haiku などの LLM を使用し、OpenSearch Dashboards または API 経由で設定できます。全ての OpenSearch Serverless 対応リージョンで利用可能です。 AWS Transform における Amazon RDS for SQL Server マイグレーションコスト評価機能の提供開始 AWS Transform で Amazon RDS for SQL Server の TCO 評価機能が利用可能になりました。AI エージェントを活用して、オンプレミス SQL Server 環境を分析し、ワークロード要件を満たす最適なデータベースインスタンスを推奨します。What-if 分析により複数のマイグレーションオプションを評価でき、BYOM (Bring Your Own Media) と License Included の両方のライセンスモデルに対応しています。Database Savings Plans を活用することでオンデマンド価格と比較して最大 20% のコスト削減が可能です。 Amazon Redshift Serverless および RG インスタンスのマニュアルスナップショットコストを削減 Amazon Redshift は、Serverless および RG (AWS Graviton ベース) インスタンスにおけるマニュアルスナップショットの課金モデルを変更しました。従来は各スナップショットの合計サイズで課金されていましたが、新モデルでは複数スナップショット間で固有のデータブロックのみを課金対象とします。これにより、複数のスナップショットを保持する顧客は大幅なコスト削減を実現できます。10TB のデータウェアハウスで 3 つのスナップショットを保持する場合、従来の 30TB 課金が 11TB に削減される計算となり、約 63% のコスト削減効果があります。この変更は 2026年6月8日 から自動的に適用されます。 AWS Application Migration Service が AWS Transform MGN に名称変更 AWS Application Migration Service (MGN) が AWS Transform MGN に名称変更されました。これは MGN が AWS Transform という agentic migration service（AI エージェント型移行サービス）の基盤となるレプリケーションエンジンとして位置付けられたことを反映しています。ユーザーは従来通り MGN コンソールで直接制御する方法と、AWS Transform のエージェンティックワークフローでディスカバリーからランディングゾーン構築、ネットワーク作成、リホストやコンテナ化までを自動化する方法の 2 つから選択できます。既存のコンプライアンス認証（FedRAMP High、HIPAA、PCI DSS、ISO、SOC 1/2/3）はすべて維持され、全商用リージョンおよび AWS GovCloud (US) で利用できます。 6/9(火) AWS Cost Explorer が Amazon Q による AI コスト分析機能を提供開始 AWS Cost Explorer に「Analyze with Amazon Q」機能が追加されました。ワンクリックで、現在表示しているコストレポートについて、コストトレンド、主要なコストドライバー、異常検知の包括的な分析を Amazon Q Developer から受け取ることができます。従来は複数のフィルターやデータポイントをまたいで手動で調査する必要がありましたが、この機能により、設定済みのフィルターや期間に基づいた詳細な説明が自動生成されます。過去データには実績分析を、未来データには予測分析を、混在期間には両方の分析を提供します。すべての商用 AWS リージョンで追加料金なしで利用できます。 AWS FinOps Agent がプレビュー提供開始 AWS FinOps Agent は、FinOps 実務者とエンジニアリングチーム向けの AI エージェントで、コストに関する質問への回答、最適化機会の提示、コスト異常の自動調査、定期的な FinOps ワークフローの実行を行います。Amazon Bedrock 上に構築され、Cost Optimization Hub、Compute Optimizer、Jira、Slack に直接統合することで、エンジニアが普段使うツール内でコスト分析を完結できます。プレビュー版は 米国東部 (バージニア北部)リージョンで提供され、プレビュー期間中は追加料金なしで利用できます（ただし、エージェントが呼び出す AWS API の標準料金は発生します）。 6/10(水) AWS Cost and Usage Report 2.0 でテーブル設定の更新をサポート AWS は AWS Cost and Usage Report 2.0 (CUR 2.0) において、AWS Management Console および SDK/CLI を通じてデータテーブル設定を更新できる機能を追加しました。これにより、既存のエクスポートを削除して再作成することなく、新しい CUR 2.0 機能（追加カラムや詳細な行レベル粒度など）を採用できるようになります。更新された設定は、次回のスケジュール配信から適用されます。 Amazon EC2 M9g および M9gd 汎用インスタンスが利用可能に AWS は AWS Graviton5 プロセッサを搭載した Amazon EC2 M9g および M9gd インスタンスの一般提供を開始しました。M9g インスタンスは前世代の M8g 比で最大 25% の性能向上を実現し、データベースで最大 30%、Web アプリケーションと機械学習で最大 35% の高速化を達成しています。M9gd インスタンスはローカル NVMe SSD ストレージを搭載し、メディア処理やバッチ処理などの高速ストレージを必要とするワークロードに対応します。第 6 世代 AWS Nitro System を採用し、形式検証により数学的に証明されたワークロード分離を提供する Nitro Isolation Engine を初めて搭載しています。現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州(フランクフルト)の 4 リージョンで利用できます。 6/11(木) OpenAI GPT-5.4 および GPT-5.5 モデルが Amazon Bedrock の米国東部 (バージニア北部) リージョンで利用可能に AWS は OpenAI の GPT-5.4 および GPT-5.5 モデルを Amazon Bedrock の米国東部 (バージニア北部)リージョンで提供開始しました。両モデルは 272K トークンのコンテキストウィンドウを持ち、テキストと画像の入力に対応します。GPT-5.5 は OpenAI の最も高性能なモデルで、高度なコーディング、調査分析、ソフトウェア操作、長時間実行されるエージェントタスクに特化しています。GPT-5.4 はフロンティア推論、コーディング、コンピュータ使用、長文コンテキストワークフロー、ツール使用を本番環境にもたらします。両モデルは Responses API 経由で利用でき、サーバーサイドおよびクライアントサイドのツール呼び出し、プロジェクト、レスポンスストリーミングに対応しています。 AWS Workload Credentials Provider を発表 AWS は AWS Workload Credentials Provider を発表しました。このプロバイダーは、AWS Certificate Manager (ACM) からエクスポートした証明書の自動デプロイと、AWS Secrets Manager のシークレットをローカルキャッシュする軽量なクライアント側プロバイダーです。従来は ACM から証明書をエクスポートする際、Amazon EventBridge を使ってカスタム自動化を構築する必要がありましたが、CA/B Forum の規定により公開証明書の有効期限が短縮される中、このカスタム自動化は大規模環境でのメンテナンスが困難になっていました。AWS Workload Credentials Provider は、証明書とシークレットの両方を単一のプロバイダーで配布・自動化できる統合ソリューションを提供します。Windows と Linux で動作し、Apache と NGINX ウェブサーバーに対応しています。 Amazon Aurora が PostgreSQL メジャーバージョン 18 をサポート Amazon Aurora PostgreSQL-Compatible Edition が PostgreSQL メジャーバージョン 18 (18.3) をサポート開始しました。このリリースでは、B-tree skip scans によるクエリパフォーマンス改善、pg_roaringbitmap 拡張機能の追加、オプティマイザ統計の保持によるアップグレード後の性能維持、論理レプリケーションの並列ストリーミングによるレプリケーションラグ削減が実現されます。すべての商用 AWS リージョンおよび AWS GovCloud (US) リージョンで利用可能です。 Amazon Quick と Snowflake Cortex AI の統合 Amazon Quick が Snowflake Cortex AI との統合を発表しました。Model Context Protocol (MCP) を介した接続により、自然言語で Snowflake の構造化データと非構造化ドキュメントをクエリできます。OAuth 認証による Snowflake 管理型 MCP サーバーを設定することで、Cortex Analyst（構造化データ分析）と Cortex Search（非構造化ドキュメント検索）へアクセス可能になります。Amazon Quick の Flows 機能を使用して、Snowflake Cortex Agents を組み合わせた反復可能なワークフローを構築でき、構造化された一貫性のある出力を得られます。この統合は Amazon Quick が利用可能な全 AWS リージョンで提供されます。 6/12(金) Amazon SageMaker AI が Nvidia Nemotron モデルのサーバーレスファインチューニングに対応 Amazon SageMaker AI は Nvidia Nemotron 3 Nano モデル (30B パラメータ) のサーバーレスモデルカスタマイゼーションに対応しました。Supervised Fine-Tuning (SFT) と Reinforcement Fine-Tuning (RFT) の両方に対応し、インフラ管理を完全に自動化することで、開発者はデータ準備とモデル評価に集中できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド)の 4 リージョンで利用できます。 Claude Fable および Mythos に関する発表 もありましたが、米国政府から指示があり、現在アクセス停止となっておりますのでご注意ください。Opus 4.8 等の他のモデルに関しては影響ありません。 それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

この記事では、パブリック API および Amazon Q との統合を備えた AWS Billing and Cost Management (請求とコスト管理) コンソールのクレジット詳細ページについてご紹介します。これにより、お客様はクレジットの確認と管理を一箇所で行えるようになります。 AWS クレジットを大規模に管理することは容易ではありません。組織の AWS 利用が拡大するにつれて、複数のプログラムからクレジットが蓄積されていきます。残高の追跡、消費の把握、割り当ての制御は、ますます複雑になっていきます。本日、パブリック API および Amazon Q との統合を備えた AWS Billing and Cost Management コンソールのクレジット詳細ページを発表します。これにより、お客様はすべてのクレジットの確認と管理を一箇所で行えるようになります。この記事では、クレジットのメタデータと適用履歴を確認する方法、ビジネス構造に合わせてクレジットレベルの共有を設定する方法、およびクレジットの一時停止や有効化によって消費タイミングを制御する方法をご紹介します。 課題：大規模なクレジット管理 組織の AWS 利用が拡大するにつれて、クレジット管理のニーズも同様に増大します。お客様からは、現在の制約についていくつかのご意見をいただいています。 個々のクレジットの識別 ： 同じプログラムから複数のクレジットが付与される場合、それらを区別するためにお客様は AWS とは別に追跡手段を用意する必要があります。 クレジット消費の追跡 ： どのアカウントやサービスがクレジットを消費したかを把握するには、複数のデータソースを突き合わせ、カスタムレポートを作成する必要があります。 残高の把握 ： お客様はチャージバックの計画や消費予測のために、月に一度よりも高い頻度でクレジット残高の情報を必要としています。 クレジット割り当ての管理 ： クレジットはデフォルトで組織内のすべてのアカウントで共有され、利用率を最大化するようになっています。ビジネス構造上必要な場合に、特定のクレジットを特定のチームやプロジェクトに割り当てるオプションを求めるお客様の声がありました。 クレジット消費タイミングの管理 ： クレジットは利用率を最大化するために自動的に適用されます。特定のクレジットを一時停止し、将来の利用のために確保しておく機能を求めるお客様の声がありました。 クレジット情報の集約 ： 複数のプログラムにまたがるクレジットを管理するチームは、統一的なビューを作成するために独自のスプレッドシートやトラッキングシステムを維持しています。 クレジット詳細ページのご紹介：すべてのクレジットを確認・管理 クレジット詳細ページは、クレジットの可視性とクレジット共有の管理機能を一箇所に集約することで、これらの課題に対応します。 確認・追跡：クレジットのメタデータと適用履歴 クレジットページから任意のクレジットを選択すると、その詳細情報をすべて確認できます。 クレジットメタデータ ： クレジット名、クレジット ID、タイプ、ステータス、発行済みクレジット額、残高、推定残高、開始日、有効期限、適用可能な製品、クレジット所有者のアカウント ID 月次適用履歴 ： 各月の連結アカウント (メンバーアカウント)、サービス、プロダクトコードごとに、クレジットがどれだけ適用されたかを示す内訳 24 時間ごとの残高更新 ： 従来の月次更新に代わり、推定残高を 24 時間ごとに更新 月次適用履歴テーブルは、お客様から最も多く寄せられた「どのアカウントとサービスが各クレジットを消費したのか」という疑問に答えるものです。これにより、社内のチャージバックプロセス、財務締め処理、消費計画をコンソールから直接行えるようになります。 管理：クレジットレベルの柔軟な共有設定 クレジット詳細ページの「共有設定 (Sharing preference)」タブから、お客様は各クレジットの消費方法を管理できます。 クレジットレベルの共有 ： 定義したアカウントグループ内のアカウントにクレジットの消費を制限します。これらのグループの作成と管理には Cost Categories を使用できます。当該クレジットは、指定されたグループに属するアカウントの利用分にのみ適用されるため、クレジットが意図した割り当て先でのみ使われるようになります。これは、予算の区分、規制要件、またはプロジェクト固有の割り当てにより、クレジットを定義されたアカウントセット内に留める必要があるシナリオで有用です。 有効化と一時停止 ： 個々のクレジットのオン・オフを切り替えることができます。アクティブなクレジットは対象の料金に適用されます。一時停止中のクレジットは、再度有効化されるまで適用されません。将来の利用や購入のためにクレジットを確保しておきたい場合に使用します。 主なメリット ビジネス構造との整合 ： 組織構造やビジネスニーズを反映した Cost Categories を使用して、ビジネスユニット、コストセンター、プロジェクト、リージョン、または資金源ごとにクレジットの割り当てを管理できます。 クレジットの消費タイミングの管理 ： クレジットを一時停止して将来の購入に備えたり、意図しない消費を防いだりできます。準備が整ったら再度有効化できます。 再利用可能なグルーピング ： 各クレジットは個別に設定しますが、グルーピングに使用する Cost Category のルールはクレジット間で再利用でき、Cost Explorer、AWS Budgets、コストと使用状況レポート、AWS Billing Conductor などの他のコスト管理ツールとも統合されています。 実際のユースケース この機能は、以下のようなタイプの組織にとって有用です。 複数のビジネスユニットを持つ企業 ： 各部門は、それぞれのプログラムや資金源に合わせたクレジットを受け取ることができ、手動での再配分なしに正確な損益報告を実現できます。 公共機関および教育機関 ： 助成金によるクレジットを承認済みのアカウントに制限することで、資金提供機関の要件に対するコンプライアンスを維持できます。 多国籍企業 ： 税務、法務、または規制上の要件を満たすために、特定の地域のアカウントにクレジットを割り当てることができます。 始めてみましょう クレジット詳細ページは、AWS のお客様向けに AWS Billing and Cost Management コンソールで現在ご利用いただけます。 AWS Billing and Cost Management コンソールのクレジットページに移動します 個々のクレジットを選択してクレジット詳細ページを開くと、クレジットのメタデータと月次適用履歴を確認できます 支払いアカウント (管理アカウント) から Cost Categories を使用して、クレジットレベルの共有設定を行い、特定のアカウントグループにクレジットの消費を制限します パブリック API を通じてプログラムによるクレジットデータへのアクセスを行ったり、Amazon Q を通じてクレジットに関する質問を自然言語で行ったりすることができます (読み取り専用) クレジットの共有設定は、コンソールおよびパブリック API を通じて管理できます。 詳細情報 AWS Billing and Cost Management コンソールのクレジット クレジットレベルの共有に関するドキュメント Cost Categories のドキュメント クレジットデータ用パブリック API Ethan Yoon Ethan Yoon は、AWS Billing and Cost Management チームのシニアプロダクトマネージャーです。クレジット、リザーブドインスタンス、Savings Plans の特典適用に関する市場投入戦略を担当しています。お客様や社内チームと連携し、企業がコストに対する説明責任を維持し、AWS へのコミットメント投資とその特典を適切に活用できるよう支援する機能の開発に取り組んでいます。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2026年 4 月号 はお読みいただけましたでしょうか。今月は、6月25日と26日に AWS Summit Japan 2026 が開催予定となっており、AWS Village では Amazon Connect Customer に関する出展を行います。皆様とお会いできることを楽しみにしています。 今月はアップデート 情報に加え、AWS Summit の Amazon Connect Customer 関連セッションに関する情報をお届けします。皆様のお役に立つ内容があれば幸いです！今月は 以下の内容でアップデート情報をお届けします。 AWS Summit Japan 2026 Amazon Connect Customer 関連セッション 2026 年 5 月のアップデート一覧 AWS Contact Center Blog のご紹介 今月のアップデートに関するよくある質問 1. AWS Summit Japan 2026 Amazon Connect Customer 関連セッション AWS Summit Japan 2026 では、今年も Amazon Connect Customer のお客様導入事例や、ユースケースを元にした最新機能のご紹介についてのセッションを行います。皆様のコンタクトセンター改革のヒントとなる情報をご提供いたしますので、是非ご参加ください。最新のセッション情報、およびご登録については AWS Summit Japan ページをご覧下さい。 日付 時刻 タイトル 6/25(木) 11:30～12:10 AI ネイティブで実現する、妥協なき顧客体験 — Amazon Connect Customer － 6/25(木) 12:20～12:50 JRE GO — 予約体験の再設計と内製開発 6/25(木) 12:30～13:10 Amazon Connect Customer で実現する進化したコンタクトセンター — Agentic AI が変える顧客体験 — 6/25(木) 16:30～17:10 パーソナライズでビジネス成長を実現するコンタクトセンターへ ― AI エージェントが顧客を知り、先回りする― 6/26(金) 13:40～14:10 東京電力におけるコンタクトセンター変革 － CX 向上に向けた AI 活用の取り組み－ 2. 2026 年 5 月のアップデート一覧 Amazon Connect Customer のタスクは何日先までスケジュールできますか？最長90日先までの登録に対応しました – 2026/05/29 Amazon Connect Customer で、最長90日先までのタスクをスケジュール登録できるようになりました。組織が長期にわたるフォローアップ作業の計画、ルーティング、および追跡を行えるようになります。例えば、自動車修理の請求を管理する保険チームでは、査定員の訪問、部品の在庫確認、修理完了後のフォローアップのために将来のタスクをスケジュールでき、それぞれのタスクは関連する請求のコンテキストを保持したまま、適切なタイミングで適切なチームにルーティングされます。タスクのスケジュール登録は、StartTaskContact API、フロー、またはエージェントワークスペースから行えます。この機能は、Amazon Connect Customer が提供されているすべての商用リージョンおよび AWS GovCloud（米国）リージョンで利用可能です。 管理者ガイド Amazon Connect Customer のタスク Amazon Connect Customer のコンタクト後の要約は日本語に対応していますか？日本語を含む8言語ファミリーが新たに追加されました – 2026/05/28 Amazon Connect Customer の生成 AI を活用したコンタクト後の要約が、日本語を含む8つの言語ファミリー（ポルトガル語、フランス語、イタリア語、ドイツ語、スペイン語、中国語、日本語、韓国語）に対応しました。コンタクト後の要約は、音声・チャット・メールチャネルにわたる顧客との会話の簡潔で構造化された概要をエージェントやマネージャーに提供し、トランスクリプト全体を読む必要をなくします。この拡張により、会話で使用された言語で要約が自動的に生成されるため、エージェントはコンタクト後の作業をより迅速に完了でき、マネージャーは複数の言語でコンタクトを確認できるようになります。例えば、グローバルなサポート組織では、フランス語、ドイツ語、日本語で対応した通話の要約を自動生成し、スーパーバイザーがすべての地域のサービス品質を把握できます。この機能は、Amazon Connect Customer のコンタクト後の要約が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 生成 AI を活用したコンタクト後の要約の表示 Amazon Connect Customer のステップバイステップガイドを自然言語で作成できますか？ノーコード UI ビルダーに AI アシスタントが搭載されました  – 2026/05/28 Amazon Connect Customer アシスタントが UI ビルダーに統合され、コンタクトセンターのマネージャーが自然言語を使用してビューを作成・変更できるようになりました。例えば、「評価フィールドとコメントフィールドを含んだフィードバックフォームを作成」と説明するだけで、対応する UI コンポーネントが自動生成されます。生成されたものはレビューしてから公開でき、ステップバイステップガイドやワークスペースページのビュー作成に必要な時間と専門知識を最大70%削減できます。マネージャーは会話形式のプロンプトを使用して、ビューの作成、条件付き UI によるレイアウトの設定、コンポーネントプロパティの設定、スタイルの適用を、手作業に頼らずに行えます。アシスタントはコンポーネントの推奨、オプションの説明、問題のトラブルシューティングも行い、構築作業を迅速化します。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Connect assistant in the UI builder Amazon Connect Customer で AI エージェントによるセルフサービス対話の品質を自動評価できますか？生成 AI を使用した自動評価が可能になりました – 2026/05/27 Amazon Connect Customer で、マネージャーが生成 AI を使用してセルフサービスの対話を自動的に評価し、カスタマーエクスペリエンスを向上させるための集約されたインサイトを取得できるようになりました。マネージャーは評価フォーム内で「お客様の問題はすべて AI エージェントによって解決されたか?」など、自然言語でカスタム評価基準を定義できます。生成 AI はこの基準を使用してセルフサービス対話の質を評価し、会話の文字起こしからの関連する参照ポイントとともに、評価の詳細な推論を提供します。管理者は、これらのインサイトのまとめや個々の問い合わせについて、セルフサービス対話の記録や文字起こしと合わせて確認し、AI エージェントのパフォーマンスを向上させる機会を特定できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）の AWS リージョンで利用可能です。 管理者ガイド セルフサービス対話のパフォーマンス評価 Amazon Connect Customer のエージェントログイン/ログアウトレポートにきめ細かなアクセス制御は適用できますか？タグベースアクセスコントロールに対応しました – 2026/05/26 Amazon Connect Customer のエージェントログイン/ログアウトレポートで、タグベースのアクセスコントロールがサポートされるようになりました。データアクセスに関するコンプライアンスおよび規制要件を満たすために、きめ細かなアクセス制御を適用できます。コンタクトセンター管理者は、リソースタグを使用して、特定のエージェントのログインおよびログアウト情報を閲覧できるユーザーを制御できます。例えば、エージェントに「Department: Customer Service」というタグを付けると、カスタマーサービスのチームマネージャーのみがこれらのエージェントのログイン/ログアウト情報を確認できるようになります。この機能は、Amazon Connect Customer が提供されているすべての AWS 商用リージョンおよび AWS GovCloud（米国西部）リージョンで利用可能です。 管理者ガイド タグベースのアクセス制御 Amazon Connect Cases でエージェントがケースの関連項目を編集・削除できますか？エージェントワークスペースからの直接操作に対応しました – 2026/05/15 Amazon Connect Customer Cases で、関連項目の編集と削除、およびエージェントワークスペースからのケースの直接削除が管理者の介入なしで行えるようになりました。エージェントは、コメントを更新したり、間違ったケースに関連付けられている連絡先のリンクを解除したり、誤って開かれたケースを削除したりできます。また、注文、返品、請求書などのカスタム関連項目を作成・編集・削除して、追加のケースコンテキストを把握することも可能です。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 Amazon Connect Customer でエージェントが自分のパフォーマンス評価だけを確認できますか？自己評価の表示専用権限が追加されました – 2026/05/14 Amazon Connect Customer で、他のエージェントの評価を公開せずに、エージェントが自分のパフォーマンス評価のみにアクセスできる権限がサポートされるようになりました。エージェントはフィードバックを確認してパフォーマンスを向上させることができます。この権限により、エージェントは自分が評価を受けたコンタクトを検索し、通話録音やトランスクリプトと並べて評価を確認したり、確認後に承認を送信したりできます。例えば、複数のコンタクトにまたがる顧客の問題を調査するために部署全体の連絡先を閲覧する権限をエージェントに付与しつつ、評価については自分のものだけを確認できるように設定できます。同僚の機密性の高いパフォーマンスデータをエージェントが閲覧できない状態を確保しながら、運用上の柔軟性を提供します。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド 評価とコーチングの権限 Amazon Connect Customer の Cases と Customer Profiles をカスタムエージェントアプリケーションに埋め込めますか？SDK による統合が可能になりました – 2026/05/12 Amazon Connect Customer で、カスタムエージェントアプリケーションに Cases と Customer Profiles を埋め込めるようになりました。エージェントは問題解決のために既に使用しているツールに加えて、ケースの詳細や顧客のコンテキストにアクセスできるようになります。デベロッパーは Amazon Connect SDK を使用してネイティブの Connect 環境をカスタムアプリケーションに取り込むことができるため、これらの機能をゼロから構築して保守する必要がなくなります。この機能は、Amazon Connect Customer が提供されているすべての AWS リージョンで利用可能です。 管理者ガイド / デベロッパーガイド カスタムアプリケーションへの統合 Amazon Connect SDK（GitHub） Amazon Connect Customer のアフターコンタクトワーク時にステップバイステップガイドを自動起動できますか？ACW 用デフォルトガイドが追加されました – 2026/05/08 Amazon Connect Customer で、アフターコンタクトワーク（ACW）のデフォルトガイドがサポートされるようになりました。コンタクトセンターの管理者は、エージェントが ACW 状態になったときに手動操作なしでステップバイステップガイドを自動的に起動できます。処理コードの記録、ケースの更新、フォローアップアクションの完了など、必要なラップアップタスクをエージェントが自動的に実行できるようにすることで、コンタクト後のワークフローを標準化し、対応時間を短縮できます。ACW 中にエージェントが手動で正しいアプリケーションに移動する必要がなくなるため、コンタクトセンター業務全体において一貫性の向上、エラーの削減、エージェントの生産性向上が期待できます。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、アフリカ（ケープタウン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、欧州（フランクフルト）、欧州（ロンドン）、AWS GovCloud（米国西部）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect のフローブロック: ビューを表示 Amazon Connect Customer のアウトバウンドキャンペーンは複数タイムゾーンの顧客に適切な時間帯で配信できますか？複数の連絡先情報からのタイムゾーン検出に対応しました – 2026/05/07 Amazon Connect Customer のアウトバウンドキャンペーンで、主要な連絡先フィールドだけでなく、顧客プロファイルのすべての電話番号と住所を使用して顧客のタイムゾーンが検出されるようになりました。これまでは主要な電話番号のみが使用されていたため、複数のタイムゾーンにまたがる顧客を見落とす場合がありました。プロファイルの連絡先情報が複数のタイムゾーンにまたがっている場合は、検出されたすべてのタイムゾーンにおいて設定済みの時間帯に含まれる場合にのみ配信し、重複がない場合はプロファイルをスキップします。例えば、顧客に東部標準時の市外局番の携帯電話番号と太平洋標準時の市外局番の事業用電話番号があり、キャンペーンが午前9時から午後5時まで配信されるように設定されている場合、メッセージは両方のタイムゾーンが許可された時間帯に含まれる東部標準時午後12時から午後5時（太平洋標準時午前9時から午後2時）にのみ配信されます。この機能は、Amazon Connect アウトバウンドキャンペーンが提供されているすべての AWS リージョンで追加費用なしで利用可能です。 管理者ガイド アウトバウンドキャンペーンの配信時間設定 Amazon Connect Customer Cases で重複する顧客プロファイルが統合されたときケースも自動的にまとまりますか？アイデンティティ解決との連携に対応しました – 2026/05/05 Amazon Connect Customer Cases で、重複する顧客プロファイルが統合される際にケースが自動的に再度関連付けられるようになりました。これにより、エージェントは常にそれぞれの顧客の完全なケース履歴を確認できます。同じ顧客が異なるチャネルを通じて連絡したり、異なる連絡先情報を提供したりすることで複数のプロファイルが作成される場合があります。Amazon Connect Customer Profiles のアイデンティティ解決がそれらの重複を検出して統合すると、関連付けられたすべてのケースが Cases によって統合プロファイルに自動的にまとめられます。エージェントは複数のプロファイルを検索したり、顧客の履歴を手動でまとめたりする必要がなくなりました。この機能は、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部）、欧州（フランクフルト）、欧州（ロンドン）、アジアパシフィック（ソウル）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、アフリカ（ケープタウン）の各 AWS リージョンで利用可能です。 管理者ガイド Amazon Connect Cases 3. AWS Contact Center Blog のご紹介 Amazon Connect Customer: 中国への発信におけるコンプライアンスのベストプラクティス (日本語翻訳) グローバルにビジネスを展開する企業にとって、中国（国番号 +86）への発信における通信規制への準拠は避けて通れない課題です。規制に適合しない設定のままアウトバウンド発信を行うと、通話切断やサービス停止、さらには中国への発信機能そのものの利用制限といった深刻な影響を受ける可能性があります。本記事では、Amazon Connect Customer を使用して中国へコンプライアンスに準拠した発信を行うための 5 つのベストプラクティス（承認済み DID 番号の設定、禁止番号タイプの排除、レート制限の実装、発信者 ID の設定、番号検証の実装）を紹介します。 4. 今月のアップデートに関するよくある質問 Q. Amazon Connect Customer とは何ですか？ Amazon Connect は、Amazon の運用実績に基づいて構築されたエージェンティック AI ソリューションのファミリーになりました。2026年4月に、Amazon Connect Customer（カスタマーエクスペリエンス）、Amazon Connect Decisions（サプライチェーン）、Amazon Connect Talent（採用）、Amazon Connect Health（ヘルスケア）の4つのソリューションに拡張されました。( Amazon Connect について ) コンタクトセンター領域を担う Amazon Connect Customer は、音声・チャット・メール・タスクなど複数のチャネルを一つのプラットフォームに統合し、AI を中核に据えたクラウドコンタクトセンターソリューションです。料金プランは、すべての AI 最適化機能がチャネル料金に含まれる「Amazon Connect Customer」（旧 Unlimited AI）がデフォルトです。従来のアラカルト型プランは「Amazon Connect Customer Basic」として既存顧客向けに提供されていますが、今後の新しい AI 機能は Connect Customer で提供されるため、Customer Basic からの移行が推奨されます。( Amazon Connect Customer について / Amazon Connect Customer の料金 ) Q. Amazon Connect Customer Tasks とは何ですか? Amazon Connect Customer Tasks は、音声・チャット・メールと同じように優先順位付け、割り当て、追跡、自動化ができる作業項目です。エージェントはエージェントワークスペース上でタスクを受け取り、フォローアップの電話、保険請求の処理、ケースの更新など、コンタクト対応以外の業務を管理できます。タスクは手動で作成するほか、コンタクトフロー内のアクション、ルール、StartTaskContact API から自動生成することも可能です。ルーティングプロファイルによりキューへの振り分けや優先度の設定ができ、今月のアップデートでは最長90日先までのスケジュール登録にも対応しました。（ Amazon Connect Customer Tasks ） Q. Amazon Connect Customer のステップバイステップガイドとは何ですか？ ステップバイステップガイドは、エージェントワークスペース上でエージェントに対して業務手順を段階的に案内する UI コンポーネントです。管理者はノーコードの UI ビルダーでフォーム、ボタン、テキストなどのコンポーネントを組み合わせてガイドを作成し、コンタクトフローでトリガー条件を設定できます。エージェントが通話を受けた際やアフターコンタクトワーク（ACW）に入った際に自動的に表示され、処理コードの入力、ケース作成、顧客情報の確認などを標準化された手順で実行できます。今月のアップデートでは、ACW 状態でデフォルトガイドを自動起動する機能と、AI アシスタントによる自然言語でのガイド作成（作成時間を最大70%削減）が追加されました。（ ステップバイステップガイド ） Q. Amazon Connect Customer にはどのようなレポートがありますか？ Amazon Connect Customer は以下のレポート・分析機能を提供しています。 リアルタイムメトリクス : キューやエージェントの現在の状態（待ち呼数、対応可能エージェント数、サービスレベルなど）をリアルタイムに表示します。 履歴メトリクス : 指定した期間のコンタクト数、平均処理時間、放棄率などを集計し、トレンド分析に活用できます。 ダッシュボード : キューとエージェントのパフォーマンスを視覚的に一覧でき、カスタムウィジェットやカスタムメトリクスの作成も可能です。 ログイン/ログアウトレポート : エージェントの勤務時間を追跡し、タグベースのアクセスコントロールによりチームマネージャーごとに閲覧範囲を制限できます。 会話分析（Conversational Analytics） : 音声・チャット・メールのコンタクトに対してリアルタイムおよびコンタクト後の分析を提供します。自動文字起こし、感情分析、コンタクトの自動分類、PII（個人識別情報）の墨消し、生成 AI によるコンタクト後の要約生成、テーマ検出などの機能を備えています。 分析データレイク : コンタクトデータを Amazon Athena や Amazon Quick で直接クエリ・分析でき、複雑なデータパイプラインを構築することなくカスタムレポートを作成できます。今月のアップデートでは、ログイン/ログアウトレポートへのタグベースアクセスコントロールが追加されました。 Q. Amazon Connect Customer の Identity Resolution(アイデンティティ解決)とは何ですか？ アイデンティティ解決は、Amazon Connect Customer Profiles の機能で、同じ顧客が異なるチャネルや連絡先情報で作成した複数のプロファイルを自動的に検出・統合する仕組みです。今月のアップデートにより、プロファイルが統合される際に Amazon Connect Cases のケースも自動的に統合プロファイルに再関連付けされるようになりました。エージェントは複数のプロファイルを検索する必要なく、常に顧客の完全なケース履歴を確認できます。( Amazon Connect Customer Profiles , Identity Resolution ) Q. Amazon Connect Customer Cases とは何ですか？ Amazon Connect Customer Cases は、顧客との応対履歴をケースとして作成・追跡・管理する機能です。エージェントはエージェントワークスペース内でケースの作成、ステータスの更新、関連するコンタクトやタスクの紐づけを一画面で行えます。ケースにはカスタムフィールドを定義でき、テンプレートを使って業種や業務に応じた構造化が可能です。コンタクトフローからケースを自動作成するルールも設定できます。今月のアップデートでは、エージェントがワークスペースから関連項目の編集・削除やケースの直接削除が可能になったほか、Amazon Connect Customer Profiles のアイデンティティ解決によりプロファイル統合時にケースが自動的に再関連付けされるようになりました。（ Amazon Connect Customer Cases ） Q. Amazon Connect Customer のアウトバウンドキャンペーンとは何ですか？ アウトバウンドキャンペーンは、Amazon Connect Customer Profiles のセグメントに基づいて、音声・SMS・メールなど複数チャネルで顧客にプロアクティブにアプローチする機能です。そして、ジャーニー（複数ステップのワークフロー）を設計し、顧客の行動や属性に応じたパーソナライズされたアウトリーチを実行できます。セグメントビルダーで対象顧客を定義し、ビジュアルフローデザイナーでマルチチャネルジャーニーを構築します。配信ガードレールやエンゲージメント設定により、適切な時間帯・頻度でのコミュニケーション管理も可能です。今月のアップデートでは、顧客プロファイルのすべての電話番号と住所からタイムゾーンを検出し、複数タイムゾーンにまたがる顧客にも適切な時間帯で配信できるようになりました。（ アウトバウンドキャンペーン ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 AWS Summit Japan 2026 にもぜひご登録の上、ご来場ください。会場でお待ちしています！Amazon Connect Customer の最新情報は毎月このブログでお届けしていますので、来月号もお楽しみに。 著者プロフィール   梅田　裕義（Hiroyoshi Umeda） アマゾンウェブサービスジャパン合同会社 シニア Amazon Connect ソリューションアーキテクト 2020年12月入社。コンタクトセンター領域を専門に、Amazon Connect Customer を活用した顧客体験の向上や業務効率化の技術支援を行っています。AI によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築などコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

セガサミーホールディングス株式会社は、エンタテインメントコンテンツ事業、遊技機事業、ゲーミング事業の 3 つの事業領域を軸に展開する総合エンタテインメント企業グループの持株会社です。同社では、グループ会社であるサミー株式会社の基幹業務システム（販売、調達、生産、在庫管理）を支えるデータベースを、オンプレミスの Oracle Database から Amazon RDS for Oracle に移行しました。本ブログでは、移行の背景にあった課題、移行の取り組み、そして移行後に得られた効果についてご紹介します。 移行対象のシステム 今回の移行対象のデータベースは、サミー株式会社の基幹業務（販売、調達、生産、在庫管理）を支える複数の業務システムのバックエンドとして利用されていました。その大部分を占めるのが intra-mart を開発基盤とした基幹システムです。intra-mart の AP サーバーおよびデータベースはオンプレミス環境で運用されており、今回のプロジェクトで AP サーバーとデータベースの双方を AWS に移行しました。データベースには約 4,000 のテーブル、約 650 のマテリアライズドビュー、約 600 のプロシージャが存在し、データサイズは約 2TB に及びます。基幹系システムであるため、月次メンテナンス日以外は無停止での稼働が求められていました。 課題 当該システムをオンプレミスで運用する中で、大きく 3 つの課題がありました。 物理制約と調達遅延 オンプレミス環境では、リソース拡張にサーバーやストレージの事前購入が必要で、調達に時間がかかるため、事業や環境変化への即時対応が困難でした。初期投資の負担も大きく、突発的な負荷変動にも即座に対応できない状況でした。加えて、ハードウェア障害時には長時間のダウンタイムをともなうリスクがあり、DR/BCP 対策の強化も容易ではなく、基幹系システムとしての可用性に懸念を抱えていました。 運用負荷 監視ツールは自社で選定・管理する必要があり、開発・テスト環境の構築にもインフラ担当への依頼が必要でした。物理機器の保守やハードウェアのライフサイクル対応（リプレイス作業）にも工数を割かれ、月次メンテナンスなど業務時間外の対応も発生していました。こうした定型的な運用業務に時間を取られ、インフラ担当者が本来注力すべき高度な業務に集中しにくく、モチベーションの維持も難しい状況でした。 AI 活用を見据えた拡張性の確保 同社では、グローバルレベルでのデータ基盤強化とデータ利活用の促進、AI 活用による業務効率化を IT 戦略として掲げていました。将来的な AI 活用やデータ分析の推進を見据え、周辺サービスと柔軟に連携できる環境への移行も視野に入れていました。 ソリューション これらの課題を解決するため、オンプレミスのデータベースをクラウドへ移行する方針が決定されました。移行先として AWS に加え Oracle Cloud Infrastructure（OCI）やオンプレミスの継続も検討しましたが、以下の理由から AWS 上のマネージドサービスである Amazon RDS for Oracle を採用しました。 同一エンジン（Oracle）のマネージドサービスへの移行であるため、アプリケーション改修を最小限に抑え、移行コストを低減できる マネージドサービスの活用により、バックアップやパッチ適用などの運用負荷を軽減し、DR/BCP 対策の強化やリソースの柔軟な拡張が実現できる AWS 上にデータベースを配置することで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になり、データ利活用の推進基盤として活用できる また、同社ではクラウドファーストを会社の方針として掲げており、コスト最適化およびマネージドサービス活用による運用効率の向上を推進していたことも、今回の移行を後押ししました。 移行スケジュール 移行は以下のスケジュールで実施しました。 プロジェクト計画フェーズ 移行に先立ち、2025 年 2 月中旬から 3 月末にかけてプロジェクト計画を策定しました。本プロジェクトは Oracle 11g から 19c へのバージョンアップも兼ねていたため、AWS Schema Conversion Tool（SCT）を使用してスキーマの互換性を事前に検証しました。これにより、DB オブジェクトの互換性に関する課題を早期に把握することができました。 また、Amazon RDS for Oracle に向けて対応が必要な箇所や影響範囲の洗い出しを行った結果、帳票出力や SQL Loader によるデータロードなどに影響があることが判明しました。帳票出力については、オンプレミス環境でファイルシステムにマウントして出力していた処理を変更する必要がありました。また、SQL Loader によるデータロードについても同様に影響がありました。いずれも Amazon RDS と Amazon S3 のインテグレーション機能を活用する方式に置き換えて対処しました。S3 インテグレーションへの切り替えは当初想定よりも対応範囲が広かったものの、方針が固まってからはスムーズに進めることができました。 加えて、オンプレミスからクラウドへの移行にあたっては、ネットワークレイテンシーの影響が懸念されました。検証ではデータ量に応じてレイテンシーが増加する傾向が見られましたが、最も遅延の影響を受けやすく、データ量が比較的小さい工場システムで問題がないことを確認し、移行可能と判断しました。 テストフェーズ 2025 年 8 月中旬から 11 月末にかけて、主要業務の SQL を対象としたシステムテストを実施しました。約 8 件の SQL でパフォーマンスの劣化が確認されました。原因は、移行先の Oracle バージョンでオプティマイザが生成する実行計画が最適ではなかったことにありました。この問題には OPTIMIZER_FEATURES_ENABLE パラメータのヒント句で対応しました。OPTIMIZER_FEATURES_ENABLE は、オプティマイザの動作を指定したバージョンの挙動に合わせるパラメータです。移行元のバージョンを指定することで移行前と同等の実行計画が生成されるようになり、性能劣化の大部分を解消しました。 移行実施 2025 年 12 月末に本番移行を実施しました。約 4,000 テーブル・約 2TB の基幹 DB を EXP/IMP で移行しました。本番切替後にも、事前テストでカバーしきれなかった一部の SQL でパフォーマンスの遅延が発生しましたが、テストフェーズで OPTIMIZER_FEATURES_ENABLE によるワークアラウンドを把握できていたため、同じ対処で速やかに改善することができました。それ以外に大きな問題は発生せず、基幹業務システムとしてスムーズに稼働を開始しました。DB が AWS 上に移行されたことでネットワーク構成が改善され、移行前と比較してパフォーマンスの向上も実感できる結果となりました。 導入効果 Amazon RDS for Oracle への移行により、以下の効果が得られました。 パフォーマンスの向上 移行により明らかにパフォーマンスが向上し、日次夜間バッチの処理時間も約 22% 短縮されました。高負荷時に遅くなる事象が解消され、サーバーダウンにつながるような負荷の問題もなくなりました。また、最適なリソース選択が容易になり、ワークロードに応じた適切なインスタンスサイズを柔軟に選択できるようになりました。 柔軟性の向上 AWS への移行により、数分でリソース拡張が可能になり、オンプレミス特有の物理制約や調達遅延が解消されました。突発的な負荷変動が発生した場合でも対処できる選択肢が確保され、事業や環境変化に対応できる安心感のある基盤を実現しました。初期投資についても、オンプレミスのようにサーバーやストレージを事前に大きく購入する必要がなくなり、利用量ベースで投資判断がしやすくなりました。さらに、別リージョンや別 AZ への設計を取り入れやすくなったことで、DR/BCP 対策の強化や事業継続性の向上にもつながっています。 運用効率の改善 監視は Amazon CloudWatch や Amazon CloudWatch Database Insights といった AWS のマネージドサービスに統合され、自社で監視ツールを選定・管理する必要がなくなりました。インフラ担当に頼らず、アプリ開発チームでも環境準備が可能になり、早期の環境構築が実現しました。月次メンテナンス時の再起動も不要になりました。オンプレミスの物理機器保守やハードウェアのライフサイクル対応（リプレイス作業）からも解放され、運用負荷が大幅に低下しました。こうした定型的な運用業務からの解放により、インフラ担当者のモチベーション向上にもつながっています。 データ利活用基盤としての拡張性 AWS 上にデータベースを配置したことで、ETL、分析基盤、AI/ML など AWS の周辺サービスとの連携が容易になりました。データベースを起点とした拡張性が高まり、IT 戦略として掲げるデータ利活用や AI 活用を推進するための基盤が整いました。 こうした効果を踏まえ、今回の AWS 移行についてセガサミーホールディングス株式会社の江田氏は以下のように振り返っています。 「移行により明らかにパフォーマンスが良くなりました。移行後は障害も発生しておらず、インフラ担当者が本来やるべき高度な業務に専念できる環境にシフトすることができました。」 – 江田 英昭 氏　セガサミーホールディングス株式会社 ITソリューション本部 ビジネスシステム部 部長 今後は、クラウドファースト方針のもと AWS のサービスや AI の活用を推進し、Amazon Redshift によるデータ分析をはじめ、グループ全体でのデータ利活用を拡大していく予定です。

みなさんこんにちは！関西で製造業のお客様を中心に技術支援をしているソリューションアーキテクトの河井です。今年も AWS Summit Japan 2026 の季節がやってまいりました！会場は千葉県の幕張メッセです。今年も製造業向けの展示を出展する予定ですので、ぜひ遊びに来てください。AWS Summit の概要と製造ハイライト展示の見どころは こちらのブログ に掲載していますのでご覧ください。 本ブログではハイライト展示内の Supply Chain ブースの展示について紹介します。今回のブースでは、サプライチェーンの意思決定を AI で加速する 2 つのアプローチを展示します。1 つ目は AWS のサービスを組み合わせて作る AI エージェントを活用したアプリケーション で、マーケットサインを起点に需要予測から生産計画提案までを一気通貫で実行するデモです。2 つ目は SaaS 形態でサプライチェーンの Decision Intelligence (DI) をエージェントとして提供する Amazon Connect Decisions で、サプライチェーン上で発生している問題を自動検知し、AI が根本原因の分析と推奨アクションを提示するマネージドサービスです。それぞれ異なるアプローチでサプライチェーンの意思決定を加速する様子をご覧いただけます。 製造業が直面するサプライチェーンの課題 製造製造業のサプライチェーンを管理する方々の頭を悩ませる課題は多くありますが、ざっくりとまとめると下記のように分類できるのではないでしょうか。 需要変動の兆候を掴んでも、定量化できない：  政策発表や市場トレンドの変化を感じても、「実際にどれだけ需要が増えるのか」を定量的に見積もれません。結果として対応が後手に回ります。 需要変動への対応に時間がかかる：  需要が急変したとき、在庫・生産キャパ・部品調達の見通しを確認するために、営業、生産管理、調達部門など様々な部署からの情報が必要で数日かかります。 物流の不確実性： 海上交通を使う場合はコンテナ不足・港湾混雑など予期せぬ問題が発生する可能性があります。そのほかにも地政学的リスクなどにより、輸送のリードタイムが突然倍増し、供給計画が崩れます。 在庫配分の判断の難しさ： 限られた在庫を複数の製品ラインにどう再配分するか、人手では即座に最適解を出せません。 これらの課題に共通するのは、「 情報はあるのに、それを統合して迅速に意思決定する仕組みがない 」 ということです。 AWS サービスを組み合わせた アプリケーションの概要 本デモでは、架空のドローンのメーカー「AnyCompany」（横浜工場）を題材に、マーケットサイン（政府のインフラ点検プロジェクト閣議決定）を起点として、AI エージェントに分析を依頼するだけで以下を一気通貫で提示する仕組みを体験いただけます。 需要予測 — 過去の受注履歴と公共入札件数から、今後 6 ヶ月の需要を予測 在庫・供給状況の可視化 — 現在の在庫水準、サプライヤー別の供給力、コンテナ不足の影響を即座に一覧化 増産シナリオ別の生産計画提案 — 需要予測の各シナリオに対して、3 製品間の生産配分最適化と売上影響を計算 総合提案 — 時間軸別（即時/短期/中期）の具体的なアクションリストを提示 従来なら数日かかる「需要変動への対応策立案」を、AI エージェントへの一言の依頼で数分に短縮します。 （需要予測） （増産シナリオ別の生産計画の提案） AI でどのように解決するのか このデモのアプローチは 3 つのステップで構成されています。 ステップ1：不確実な需要を「数字」に変える 市場の変化を感じても「増えそうだ」という感覚のままでは動けません。時系列基盤モデルが過去の受注履歴と外部指標（公共入札件数）を組み合わせて、「月 180 台（+50%）」のように確率区間付きで需要を予測します。これにより、感覚ではなくデータに基づく判断が可能になります。 ステップ2：制約の中で「何ができるか」を即座に計算する 需要が増えても、部品の供給制約や在庫水準によって実際に対応できる範囲は限られます。AI エージェントが在庫・供給データを取得し、複数製品間の生産配分を利益率・季節需要・納期制約を考慮して最適化します。 ステップ3：段階的な対応策を提示する 「まず生産配分の見直しで即座に対応（追加コストゼロ）→ 需要が上振れしたら追加調達」という段階的な提案により、過剰投資を避けつつ機会損失も防ぎます。AI エージェントがサプライヤー情報や過去の調達実績を検索し、具体的なコスト・リードタイムを含めた調達オプションを提示します。 使用している技術要素 Amazon Bedrock AgentCore Amazon Bedrock AgentCore は、AI エージェントの構築・デプロイ・運用を統合的に提供するプラットフォームです。エージェントにツール・メモリ・データを装備し、複雑なワークフローを処理させることができます。インフラ管理は不要で、セキュアかつスケーラブルなランタイム上でエージェントを実行できます。本デモでは、AgentCore 上に構築したエージェントが担当者の自然言語での依頼を理解し、需要予測の呼び出し → 在庫データの取得 → シナリオ計算 → Knowledge Base 検索を自律的にオーケストレーションします。従来であれば複数部門にまたがっていた確認作業を、1 つのエージェントが一気通貫で実行します。 Chronos-2（時系列基盤モデル） Chronos-2 は Amazon が開発した時系列予測の基盤モデルです。単変量・多変量、さらに影響を及ぼすその他の要因（共変量）を含む予測タスクを、追加学習なしで処理できます。グループアテンション機構により、複数の関連する時系列間で効率的に情報を共有し、高精度な予測を実現します。本デモでは、産業用ドローンの月次受注数（ターゲット系列）とインフラ点検関連の公共入札件数（共変量）を入力として、今後 6 ヶ月の需要を確率区間付きで予測します。単なるトレンド延長ではなく、外部要因の影響を反映した予測が可能です。 Amazon Bedrock Knowledge Bases Amazon Bedrock Knowledge Bases は、RAG（Retrieval Augmented Generation）ワークフローをフルマネージドで提供する機能です。データの取り込みから検索、プロンプト拡張までを、カスタム統合やデータフロー管理なしで実現します。本デモでは、サプライヤー別の基本情報（所在地・供給シェア・リードタイム）、部品仕様、過去の調達実績（増量交渉の実績・コスト増の目安）、航空便切り替え時のコスト情報を格納しています。AI エージェントがシナリオ分析の中で調達オプションを提示する際に、これらの情報を検索して正確な根拠に基づいた提案を行います。 これらの技術要素が同一プラットフォーム（AWS）上で動作するため、予測結果をエージェントに渡すための API 変換レイヤーや、Knowledge Bases へのアクセスのための認証統合を個別に設計する必要がないのも良いところです。IAM による統一的なアクセス制御のもと、エージェントが各サービスをネイティブに呼び出せます。 （アーキテクチャ図） ここからは、サプライチェーンの問題検知と対応を継続的に行うためのマネージドサービス、Amazon Connect Decisions を紹介します。 Amazon Connect Decisions コンセプト：発生した問題を即座に捉え、原因分析から対応策までを自動で提示する サプライチェーンの現場では、在庫不足・供給遅延・需要との乖離といった問題が日々発生します。これらの問題に対して、従来は担当者がデータを突き合わせて原因を調査し、対応策を検討する必要がありました。Amazon Connect Decisions は、この「問題の検知 → 原因分析 → 対応策の提示」という一連の流れを AI で自動化します。 検知（Detection） — あらかじめ定義したメトリクスとルール（例：「在庫カバー日数が 15 日を下回ったら」）に基づいて、サプライチェーン上の問題を自動的に検知します。 洞察（Insight） — 検知された問題に対して、AI が根本原因を分析します。例えば「2025 年に発注した入庫注文 2 件（計 5,169 EA）が未受領のまま 200 日以上経過し、補充パイプラインが完全に途絶している」といった具体的な原因特定を行います。 推奨アクション（Recommendation） — 分析結果に基づき、「発注書作成：17,105 EA」「サプライヤーパフォーマンスレビューの実施」「未受領注文の調査」といった具体的な対応策を優先度付きで提示します。 主な機能 Insights（問題の検知と分析）： ビジネスルールに基づいてサプライチェーンの問題を検知し、 AI が根本原因の分析と推奨アクションを生成します。ユーザーは自社のオペレーションを記述した S&OP を AI に読み込ませて「ガイドライン」を設定します。 Demand Planning（需要予測）： Amazon が培ったノウハウを組み込んだ AI/ML モデルが、過去の販売実績から自動的に需要予測を生成します。少ない履歴データでも初日から利用可能です。営業見込み・顧客コミットメントなど複数部門からのインプットを 1 つの合意予測（Consensus Plan）に統合する仕組みも備えており、AI Teammate（自然言語インターフェース） に「なぜこの予測値になったのか」と聞いて根拠を確認することもできます。 Supply Planning（供給計画）： 需要予測や受注データをもとに、素材の利用可能性・リードタイム・生産キャパシティ・倉庫スペースといった現実の制約を考慮した供給計画（生産・調達スケジュール）を生成します。計画の定期実行スケジュールも設定でき、プランナーが計画を調整・確定したうえで下流プロセスへ公開できます。 （ Insights の検出） （根本原因と推奨アクション） まとめ サプライチェーンの意思決定には、大きく 2 つの局面があります。1 つは市場の変化や突発的な事象に対して「次にどう動くか」を素早く判断する局面。もう 1 つは、日々発生する在庫不足や供給遅延といった問題に対して「いま何が起きていて、どう対処すべきか」を把握し続ける局面です。本ブースでは、前者に対しては AI エージェントがマーケットサインから需要予測・生産計画提案までを一気通貫で実行するデモを、後者に対しては Amazon Connect Decisions が問題を自動検知し、根本原因の分析から推奨アクションまでを提示するデモをお見せします。 注文を待ってから動くのではなく、不確実な時点から先手を打つ。問題が大きくなってから調査するのではなく、発生した瞬間に原因と対応策を手にする。この 2 つのアプローチで、ビジネスのアジリティを強化します。あなたのビジネスへの次の装備となるこの AWS Summit のサプライチェーンブースのデモを、ぜひ体験しに来てください。 著者について 　河井信彦（Nobuhiko Kawai） アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト セキュリティベンダーを経て AWS Japan に入社し、エンタープライズ技術本部でソリュー ションアーキテクトとして活動中。関西の製造業のお客様を中心担当している。趣味はサッカーとフットサル。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が実施する「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。お客様のニーズに合わせ、生成 AI による価値創出のため戦略策定に取り組む方向けの「戦略プランニングコース」、カスタムモデルによる課題解決に取り組む方向けの「モデルカスタマイズコース」、公開モデルによるビジネス課題解決を狙う方向けの「モデル活用コース」をご用意しております。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2026 年 5 月 28 日に開催されました。2024 年 11 月の 第 1 回 、2025 年 2 月の 第 2 回 、2025 年 4 月の 第 3 回 、2025 年 8 月の 第 4 回 、2025 年 11 月の 第 5 回 、2026 年 2 月の 第 6 回 に続き、今回が第 7 回となります。本記事では、イベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパン 戦略事業開発本部 プリンシパル 戦略事業開発マネージャー 塚本 陽子が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベントの冒頭では、塚本が開会の挨拶をしました。塚本はまず、2023年の「 AWS LLM開発支援プログラム 」開始以来、AWS が継続してきた生成 AI 活用支援の歩みを振り返りました。直近では 2026 年 1 月より「 フィジカル AI 開発支援プログラム 」を始動させるなど、移り変わる顧客ニーズに合わせ、支援内容を拡充してきたことを強調しました。 また、これまでの実績として「生成 AI 実用化推進プログラム」への参画企業が合計で 320 社に達したことを報告。経済産業省および NEDO が主導する「GENIAC」プロジェクトへの支援も含め、AWS が日本の生成 AI の発展に尽力している旨を共有しました。 続いて、生成 AI の現状に触れる中で、Amazon CEO Andy Jassy の「株主への手紙」から「不釣り合いに大きな変曲点を見つけたら、大きく賭けよ」という趣旨の一節を引用しました。 技術動向については、2026 年 4 月に「What’s Next with AWS 2026」で発表された最新アップデートに触れ、「お客様が用途に応じて最適な生成 AI を自由に選択できるよう、サービスをさらに拡充していく」という AWS の方針を強調しました。 アップデートの具体的な内容として、AI アシスタント Amazon Quick のデスクトップアプリ・無料プラン提供開始に加え、OpenAI とのパートナーシップ拡大により 最新の OpenAI モデルが Amazon Bedrock 上で利用可能になったこと や Codex on Bedrock、Managed Agents のリリースを紹介。 Amazon Connect の 4 ソリューション（Decisions、Talent、Customer、Health）についても解説しました。 さらに、 Amazon Bedrock において Claude Code と Codex 双方をサポートすることや、Claude のネイティブプラットフォームと AWS の認証・課金を組み合わせた新たなサービスの開始についても紹介しました。 最後に塚本は、今回で 7 回目を迎えた本ミートアップが、エンジニアから経営層までが業界を越えて一堂に会する貴重な場であることに言及。「この場を通じて知識を吸収し、ネットワークを広げていただくことで、みなさまのプロジェクトがさらに前進することを願っています」と期待を込め、挨拶を締めくくりました。 AWS セッション AWS セッションの前半パートでは、ゲストスピーカーである株式会社 NTTドコモ コンシューマサービスカンパニー Senior Principal Architect 三井 力 氏（写真上）が登壇。後半パートでは、AWS ジャパン AIML 事業本部 シニアAIML セールススペシャリスト 近藤 祐丞（写真下）をモデレーターに三井 氏との対談が行われました。 三井氏はまず、同社のスマートライフ事業を支える「プロダクトデザイン部」の体制を解説しました。100 以上のプロダクトを抱え、年間 12,000 回以上のリリースを行う大規模な開発運用（DevOps）組織です。さらなる開発速度向上と顧客体験価値の最大化を目指し、AI 駆動開発に全面的に取り組んでいる旨を語りました。 組織的な仕掛けとして、2025 年 4 月に「生成 AI 本格活用元年」を宣言し、プロジェクトを推進。社内の生成 AI コンテストを通じて 250 件以上のアイデアを創出しました。実用化された施策によって、今年度末までに約 13.3 億円もの事業成果が見込まれています。 技術論として三井氏が強調したのが、AI が信頼できる仕事をするための環境を整える「ハーネスエンジニアリング」の概念です。静的解析やテストを活用してのフィードバックループの実施や、要件定義やレビューといった勘所に高性能モデルを配置する推論サンドイッチといった手法を紹介しました。 また、運用の高度化についても言及。Agent CoreやLangChainを使った自前のエージェントに加え、東京リージョンで GA（一般提供開始）された AWS DevOps エージェントを導入し、障害対応を AI がサポートする体制を整えています。加えて、AWS の提唱する AI-DLC（AI 駆動開発ライフサイクル）に準拠したテンプレートを社内展開し、誰でも標準化された環境で開発を始められる工夫をしています。 対談パートでは、AI 時代の開発者像について議論が交わされました。三井氏は「AI 駆動開発は避けて通れない道。実装を AI が担うようになるからこそ、エンジニアはより上流のビジネス理解や、下流のデータ活用へと役割を広げ、技術を繋いでいく存在になるべき」と指摘。「AI と共に、顧客体験価値の高いプロダクトを作り続けたい」と展望を語り、セッションを締めくくりました。 カスタマー事例 ここからは、生成 AI 実用化推進プログラムに参加する各社の代表者が登壇し、「カスタマー事例」「モデル開発者紹介」の 2 部構成で取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 AI/ML Specialist SA の飯塚 将太（写真左）と鯨田 連也（写真右）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社 JDSC FDE / テックリードの鈴木 海斗 氏は、船主（船舶所有者）の業務を支援する海運 AI エージェント「AI番頭」の取り組みを解説しました。海事領域特有の課題に対し「データ」「回答生成」「運用」において独自の工夫を凝らしています。 データ設計では、画像処理（OpenCV）を用いて古い契約書の不要記述（取り消し線など）を除去し OCR 精度を向上させたほか、船舶データベースによる名称の正規化を行いました。回答生成では、質問からメタデータを抽出して検索ロジックを動的に切り替える仕組みを構築し、高精度な回答を可能にしました。運用面でも、アプリの利用者と目線を合わせながら「観測・評価・改善」を続けてきたのです。こうした活動が評価され、経産省・NEDO「GENIAC-PRIZE」最終審査で第 2 位を獲得しています。 ウォンテッドリー株式会社 Visit AI Squad リーダー の市古 空 氏は、同社のビジネス SNS「Wantedly Visit」における AI エージェントの実装事例と、設計思想の核となる Human-in-the-Loop の重要性について説明しました。 生成 AI の技術基盤には Amazon Bedrock を採用し、マイクロサービス群から共通ライブラリ経由でアクセスして、複数のモデルを柔軟に使い分ける構成にしました。また、採用ドメインにおける説明責任やユーザーの納得感を重視し、AI の判断を人間が評価するプロセスを意図的に組み込んでいます。「Human-in-the-Loop は人間の介入ポイントをいつ・どの粒度で持たせるかを意識して設計することが重要」と市古氏は語りました。 アイフル株式会社 グループシステム本部デジタル推進1部5課 課長兼 CCoE 統括長の大田 悠司 氏は「属人化したレガシーの再生」をテーマに、生成 AI とサーバーレスを活用した完全内製開発の事例を紹介しました。同社は従来はシステム開発を外部ベンダーに頼ることが多く、ドキュメントが欠落・形骸化したレガシーシステムの保守・改善が大きな課題となっていました。 そこで、内製化へと舵を切るため、特定プロジェクトで Amazon Bedrock 経由の Claude Code を活用した仕様駆動開発を実践。特に既存コードから仕様を逆算出するリバースエンジニアリングの工程では、工数を従来の 86.7% 削減することに成功しました。全工程を通じた開発効率も約 4 倍に向上したほか、フルサーバーレス構成への移行により、インフラコストを 95% 以上削減するという劇的な成果をあげています。 株式会社リーフワークス 代表取締役の澤 健太 氏は、会社の規模や目的に合わせて使える PaaS 型 Web サービス構築プラットフォーム「Palette CMS」への AI エージェント実装事例を共有しました。 UI 設計では、チャットを通じて動的に画面要素を生成する Generative UI を採用。アーキテクチャ面では、各エージェントが「これは自分の仕事ではない」と自律判断した時点で専門エージェントへバトンを渡すスキルディスパッチ機能を搭載しました。さらに RAG においては、Markdown の階層構造を保持したままデータ化することで、ドキュメントの文脈を正確に捉えた高精度な回答を実現しています。 モデル開発者紹介 ストックマーク株式会社 取締役 CTO の有馬 幸介 氏は、複雑なビジネス資料を読み解くための専用 AI の開発・運用事例を解説しました。フルスクラッチで開発した1000億パラメータの日本語 LLM やマルチモーダル文書読解 VLM は、特に日本語のドキュメント理解に優れており、GPT-4o を超える性能を示しています。 開発には Amazon SageMaker HyperPod を活用。加えて、多様な学習用合成データ自動生成技術を駆使し、専門的な図面や文書の理解力を大幅に向上させました。今後は大手企業や産総研との協業を通じて、ビジネスシーンにおける生成 AI の社会実装を加速させることを目指しています。 登壇者の皆様 クロージング クロージングでは塚本より、次回の「生成 AI Frontier Meetup」が、2026 年 8 月 27 日に開催予定であることを説明しました。会場は東京都港区の麻布台ヒルズ JP タワーの新オフィスです。加えて、今後開催される他のイベントも紹介しました。 Physical AI — クラウドとロボティクスの融合 AI が仮想空間を超え、物理世界で自律的に動作する「フィジカル AI 」の時代が到来しています。本イベントでは、AWS のフィジカル AI スペシャリストよりグローバルの最新動向を紹介するとともに、ファナック株式会社をゲストに迎え、協働ロボットCRXの実践事例やオープンプラットフォーム戦略を通じて、フィジカル AI プロジェクトを成功に導くための具体的なアプローチをお伝えします。また、同週開催の AWS Summit Japan の「フィジカル AI 観点での楽しみ方」もご紹介します。 イベント概要 日時：2026 年 6 月 24 日（水） 13:00 – 15:00 場所 : 東京都港区麻布台1丁目3-1 麻布台ヒルズ 森JPタワー 36階 形式：対面（定員 70名） ※ 参加希望者は担当営業にお問い合わせください AWS Summit Japan 2026 AWS Summit Japan は、クラウドと AI イノベーションの最前線を体験できる 2 日間の無料イベントです。エージェンティック AI やサーバーレスコンピューティングなど、業界を変革し、デジタル時代においてビジネスの成長を支えるテクノロジーを体感しましょう。業界のリーダーとの交流、同業他社とのコラボレーション、そして AWS エキスパートへ直接質問し疑問を解消できる貴重な機会です。同じ興味・関心を持つプロフェッショナルとの交流を広げ、インタラクティブなワークショップやカスタマーショーケースなど、多彩なラインアップからご自身のビジネスニーズに最適な体験を自由にカスタマイズしましょう。 イベント概要 日時：2026 年 6 月 25 日（木）〜 6 月 26 日（金） 場所：千葉市美浜区中瀬 2 – 1 幕張メッセ 公式サイト：https://aws.amazon.com/jp/events/summits/japan/ 参加者交流会の様子 交流会では、各セッションで語られた具体的な開発手法や組織文化の作り方を起点に、参加者同士の自由な議論が交わされました。業界の垣根を越えて「学びと繋がり」を深める本イベントらしい活気にあふれ、新たな共創の可能性を感じさせる場となりました。 会場内には、技術的な相談に応じる「Ask an Expert」コーナーや、各種の疑問を気軽に相談できる「よろず相談」コーナーも設けられ、参加者の方々の質問に回答いたしました。 おわりに 第 7 回を迎えた本イベントでは、技術的な工夫のみならず、組織文化の醸成やデータの質を追求する取り組みまで多岐にわたる知見が語られました。各社の生成 AI 活用が、より多角的かつ実用的なフェーズに進展していることを実感できる場となりました。AWS ジャパンは、今後もコミュニティの活性化や技術支援を通じて企業の生成 AI 活用を後押しし、その実用化と発展に貢献してまいります。

2026年6月4日、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が実施する Generative AI Accelerator Challenge (GENIAC) の一環として実施している基盤モデル開発支援事業の 第4期における採択事業者 のキックオフが行われました。今回 AWS は NVIDIA B200 Tensor Core GPU を搭載する Amazon EC2 P6-B200 インスタンス ( p6-b200.48xlarge )、NVIDIA H200 Tensor Core GPU を搭載する Amazon EC2 P5en インスタンス ( p5en.48xlarge )、NVIDIA H100 Tensor Core GPU を搭載する Amazon EC2 P5 インスタンス ( p5.48xlarge , p5.4xlarge ) 等の学習・推論に必要な仮想サーバーを提供します。 AWS は、 GENIAC バーチャルチーム を中心に、以下の支援を提供します: 計算資源 : Amazon EC2 P6-B200, P5en, P5 インスタンスの提供 技術支援 : AWS Solutions Architect (SA) を中心としたメンバーにより、コンピュート (EC2)・ネットワーク ( Elastic Fabric Adapter (EFA) )・ストレージ ( Amazon FSx for Lustre および Amazon S3 ) で構成される分散学習環境の AWS ParallelCluster  を活用した構築・管理の支援 開発者コミュニティ支援 : 海外モデルプロバイダーの開発メンバーとの交流イベントによる最先端の開発動向調査や海外視察、国内の機械学習エンジニア同士の交流による知見共有をはじめとした Meetup の実施 事業化支援 : GENIAC を通じて開発された基盤モデル・生成 AI アプリケーションの Amazon Bedrock Marketplace 、 AWS Marketplace の活用による go-to-market (GTM) 支援、利用企業との AWS 主催イベントを通じたマッチング機会の提供 これらは、経済産業省商務情報政策局情報処理基盤産業室、NEDO、ボストン コンサルティング グループ (BCG)、および AWS パートナーであるクラスメソッド株式会社と密に連携のうえで提供されます。 採択事業者 採択事業者のうち AWS を利用する事業者は以下です (現時点で承諾が得られたもののみをアルファベット・五十音順で掲載): 株式会社ABEJA Direava株式会社 株式会社DubGuild 株式会社Preferred Networks 株式会社メルカリ ONESTRUCTION株式会社 Sansan株式会社 株式会社Spectee 採択事業者からコメントを頂きました 株式会社ABEJAは、GENIAC第一期から継続して、LLMの社会実装への貢献を目的に、LLMおよび周辺技術の社会実装に取り組んでまいりました。 第四期では間違いが許されないミッションクリティカル事業への利活用を目的に、LLMおよび領域特化型のAIエージェントの研究開発に取り組みます。その上で、株式会社IDOM様と連携し、自動車整備領域における利活用を実証します。 AWS様の大規模な計算資源および技術支援を活用することで、過去事例など複数の情報ソースから必要な情報を自律的に検索・参照するToolUse能力、多様なデータを用いて論理的・段階的に解答を導き出す多段推論能力の強化を進めてまいります。 このたび新たに開発する技術は、実店舗で「Human in the Loop」の元、運用することを予定しています。精度を継続的に向上させながら、自動車整備領域における人手不足、属人化、技術の高度化による生産性低下といった課題の解決に貢献してまいります。 — 株式会社ABEJA 執行役員 木下 正文 氏   弊社はGENIACサイクル4において、外科手術における「未来予測AI基盤モデル」の開発に注力します。 サイクル3に引き続き、Amazon EC2 P5インスタンスや、大規模分散学習を支える最先端のインフラを継続して活用できることに深く感謝しております。AWS様の強力なサポートのもと、最先端AIの力で一歩先の医療現場を支えるソリューションの開発を加速させてまいります。 — Direava株式会社 CTO 斎藤 洸輔 氏   DubGuildは、大規模な音声インタラクションモデルの研究開発に取り組んでいます。 GENIACプロジェクトでは、B200 GPUを搭載したAWSのP6-B200インスタンスを活用し、30B級の大規模音声言語モデルの開発を進めてまいります。 本取り組みにあたり、Generative AI Innovation Centerをはじめ、AWSの皆様より多大なるご支援を賜っておりますこと、心より感謝申し上げます。 — 株式会社DubGuild CEO 大嵜匡俊 氏   株式会社メルカリは、GENIACプロジェクト4期目において、”Generative Retrieval技術を用いた二次流通市場向け高精度検索・推薦基盤モデルの開発”に取り組みます。Amazon EC2 P5インスタンスを活用し、大規模な学習を行います。AI自身が商品を丸暗記して探す次世代検索モデルによって、世界中の誰もが欲しい物にすぐに出会える最高の買い物体験を目指します。 — 株式会社メルカリ 研究開発組織R4D 所長 小堀 訓成 氏   AWS様には第3期に続き、第4期も引き続き支援いただきありがとうございます。 ONESTRUCTIONは本事業において、建設×AIをテーマに、建設ドメイン知識のAIエージェントへの統合と、それによる3次元設計（BIM）のAIによる自律化を目指します。 AWSの圧倒的なレジリエンスと信頼性に加え、とりわけGenAI Innovation Centerのチームによる世界水準の知見によるバックアップにより、建設業界のAI-Powerdを実現させます、ご期待ください。 — ONESTRUCTION株式会社 AI戦略ユニット Manager 日高 洸陽 氏   防災・危機管理分野からは初の採択となる今回、Specteeは独自の災害データとAI技術を基盤に、危機事象をリアルタイムに抽出する災害検知LLMと、ユーザー固有のBCP等を踏まえて行動を示唆する危機管理AIエージェントの開発に取り組みます。学習には Amazon EC2 P5 インスタンス、データ管理には Amazon S3 を活用し、AWS様のバーチャルチームによる技術支援のもと、人命に関わる領域に求められる高い精度と安定性の実現を目指します。日本発の次世代防災・危機管理基盤として、グローバル展開を見据えて開発を加速してまいります。 — 株式会社Spectee 取締役CRDO 加藤 奈々 氏 まとめ AWS では日本のお客様に対し、2023年の AWS LLM 開発支援プログラム にはじまり、グローバルの Generative AI Accelerator や AWS ジャパン生成 AI 実用化推進プログラム といった取り組みを通して生成 AI ワークロードを支援しています。GENIAC においても 第2期 、 第3期 に続き、第4期でも引き続き採択事業者の皆様と伴走し、これまで蓄積してきた知見を活かして日本の生成 AI 基盤モデル開発力の向上に貢献できれば幸いです。

本記事は 2026 年 6 月 3 日 に公開された「 Migrating data from Oracle to Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、サーバーレスで柔軟にスケールする分散 SQL データベースサービスです。複数の AWS リージョンにまたがって、強力な ACID 準拠を実現します。データベースのモダナイゼーションに向けて Amazon Aurora DSQL を検討している場合、サービスの現在の機能と制約の範囲内で既存のエンタープライズデータベースを移行するという課題に直面することがあります。 本記事では、 AWS Database Migration Service (AWS DMS) 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue 、 AWS Step Functions を使い、Oracle ソースから Amazon Aurora DSQL へデータを移行する手順を説明します。エンタープライズ規模のデプロイに適した、自動化されたコスト効率の高い移行パイプラインを構築します。 このソリューションの完全なソースコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリで入手できます。 Amazon Aurora DSQL の概要 Amazon Aurora DSQL は、高可用性、スケーラビリティ、パフォーマンスを必要とするアプリケーション向けに設計された、サーバーレスの分散 SQL データベースです。主な特長は次のとおりです。 サーバーレスアーキテクチャ – Amazon Aurora DSQL はフルマネージドのサーバーレスデータベースサービスで、需要に応じてコンピューティング、ストレージ、実行レイヤーを自動的にスケールします。 PostgreSQL 互換性 – Amazon Aurora DSQL は PostgreSQL 互換の SQL 構文と機能を提供するため、PostgreSQL インターフェイスで動作するアプリケーションに適しています。 分散設計 – 分散アーキテクチャを採用し、複数のアベイラビリティーゾーンにわたる高可用性と耐久性を実現します。 マルチリージョン対応 – Amazon Aurora DSQL は、ディザスタリカバリやグローバルアプリケーション向けにマルチリージョンデプロイをサポートします。 IAM 統合 – AWS Identity and Access Management (IAM) と統合し、認証とアクセス制御を行います。 暗号化 – Amazon Aurora DSQL は、データセキュリティのために保管時と転送時の暗号化を提供します。 移行の課題と要件 エンタープライズデータベースを Amazon Aurora DSQL に移行する際には、いくつかの固有の課題に直面します。 認証の複雑さ – Amazon Aurora DSQL では、特定のトークン生成要件を伴う IAM ベースの認証が必要です。必要なロールを引き受けられる AWS サービスは限られているため、直接接続できる手段が制限され、認証を慎重に管理する必要があります。 スキーマ作成の自動化 – Amazon Aurora DSQL では、データをロードする前にスキーマとテーブルを明示的に作成する必要があります。そのため、ソースデータベースからのスキーマ分析と変換を自動化する仕組みが必要です。 データロードの制約 – Amazon Aurora DSQL は主にファイルからの COPY コマンドでのデータロードをサポートしており、移行戦略に固有の要件が生じます。ファイルはデータベースエンジンからローカルにアクセスできる必要があり、移行パイプラインの構成方法に影響します。 コスト最適化 – 中間処理に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使う従来の方法では、特に移行期間が長期にわたる大規模データベースで、ストレージとコンピューティングのコストが大きくなることがあります。 ソリューションの概要 次の図は、ソリューションのアーキテクチャを示しています。 ワークフローは次のステップで構成されます。 パイプラインがオンプレミスの Oracle データベースからデータを抽出します。ソースには、AWS DMS がサポートする他のリレーショナルデータベースを使うこともできます。 AWS DMS がデータを Amazon S3 に移行し、AWS Glue データカタログを作成します。 Step Functions が AWS DMS タスクの進行を開始・監視し、 AWS Lambda 関数と AWS Glue ジョブを起動します。 Lambda 関数が AWS DMS からテーブルマッピングを取得して Step Functions に返し、Step Functions がそれを AWS Glue ジョブに渡します。 AWS Glue がターゲットの Amazon Aurora DSQL データベースに接続し、データカタログを使ってカラムを識別します。続いてターゲットにスキーマを作成し、ターゲットのデータ型にデータを変換します。最後に Amazon S3 からデータを読み取り、Amazon Aurora DSQL データベースにロードします。 前提条件 始める前に、次の前提条件を満たしていることを確認してください。 AWS DMS のレプリケーションソースとして設定し、データベース移行の準備が整ったソース Oracle データベース。 中間データストレージ用の S3 バケット。次の設定を行います。 ブロックパブリックアクセスを有効化。 デフォルト暗号化 (SSE-S3 または SSE-KMS) を構成。 AWS DMS がターゲットとして使用し、AWS Glue がアクセスするために必要な権限。 AWS DMS タスクの監視、Lambda 関数の起動、AWS Glue ジョブの管理を行うサービスロールを引き受ける Step Functions ワークフローを作成するためのユーザー権限。 特定の Amazon Aurora DSQL クラスターにスコープを限定した次の IAM 権限。 iam:CreateServiceLinkedRole 。 dsql:DbConnect 。 dsql:DbConnectAdmin 。 dsql:GenerateDbConnectAdminAuthToken 。 dsql:GenerateDbConnectAuthToken 。 Amazon Aurora DSQL のターゲットインスタンスを作成する Amazon Aurora DSQL クラスターを作成するには、次のステップを実行します。 Amazon Aurora DSQL コンソールのナビゲーションペインで、[ Clusters ] を選択します。 [ Create cluster ] を選択し、[ Single-Region ] または [ Multi-Region ] を選択します。 暗号化設定、削除保護、タグを構成します。 [ Create cluster ] を選択します。 クラスター作成の詳細な手順、高度な設定、マルチリージョンのセットアップオプションについては、 Aurora DSQL の開始方法 を参照してください。 AWS DMS タスクを構成する 次のステップで AWS DMS タスクを構成します。 データ量を処理できる十分な容量のレプリケーションインスタンスを作成します。 接続情報を設定し、転送時の暗号化のために SSL モードを verify-full に設定した Oracle ソースエンドポイントを作成します。 次の設定で Amazon S3 ターゲットエンドポイントを作成します。 DataFormat を CSV に設定。 EncryptionMode を SSE_KMS に設定。 ServerSideEncryptionKmsKeyId を KMS キーの ARN に設定。 GlueCatalogGeneration と IncludeOpForFullLoad を True に設定。 AWS DMS 移行タスクを作成します。 移行タイプに [ full load ] を選択します。 ソーススキーマのテーブルマッピングを構成します。 ラージオブジェクト (LOB) の処理とパフォーマンスに適したタスク設定を行います。 移行タスクの起動設定を [ Manually later ] に設定します。 AWS DMS の詳細な構成手順、エンドポイント設定、タスク構成オプションについては、 Creating a task 、 Using an Oracle database as a source for AWS DMS 、 Using Amazon S3 as a target for AWS Database Migration Service を参照してください。 Lambda 関数を作成する AWS DMS タスクのマッピングからテーブル情報を抽出する Lambda 関数を作成します。この関数は DMS タスクのテーブルマッピングを解析してターゲットのテーブル名を特定し、それを AWS Glue ETL ジョブに渡します。 Lambda 関数の完全なコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 この関数は主に次の処理を行います。 DMS タスクイベントから tableMappings を解析します。 DMS ルールを順に処理し、選択タイプのルールを見つけます。 object-locator からテーブル名を抽出して返します。 Lambda の構成 メモリ – 128 MB (テーブル名の抽出には十分です)。 タイムアウト – 15 秒 (5 秒より長く設定します)。 IAM ロール – 次の AWS DMS 権限を持つ基本的な Lambda 実行ロール。 dms:DescribeReplicationTasks – AWS DMS タスクの詳細とテーブルマッピングを読み取ります。 dms:DescribeTableStatistics – テーブル単位の移行統計にアクセスします。 Lambda の IAM 権限要件の詳細については、 AWS Lambda アクセス許可の管理 および AWS DMS API Reference を参照してください。 AWS Glue ETL ジョブを作成する AWS Glue ETL ジョブは、スキーマの作成、データ型のマッピング、Amazon Aurora DSQL へのデータロードを担います。 データカタログのセットアップ Amazon S3 をターゲットにすると、AWS DMS がデータカタログのエントリを自動的に作成します。別途クローラーを用意する必要はありません。AWS DMS は移行中にデータカタログを生成し、Oracle ソースの適切なスキーマ情報を使ってテーブルをカタログ化します。 ジョブの構成 ジョブタイプ – Spark ETL。 AWS Glue バージョン – 3.0 以降。 依存 JAR のパス – postgresql-42.7.4.jar (JAR ファイルをダウンロードし、S3 のアクセスパスを指定します)。 Python モジュールのパス – boto3>=1.35.95 (Amazon Aurora DSQL の認証に使用します)。 ワーカータイプ – データ量に応じて調整します。 Glue ジョブの IAM 権限 AWS Glue ジョブには、次のサービスにまたがる権限が必要です。完全な IAM ポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 ステートメント アクション 目的 S3Access s3:GetObject , s3:ListBucket 移行データを Amazon S3 から読み取る GlueDataCatalogAccess glue:GetDatabase , glue:GetTable , glue:GetPartitions スキーマのメタデータにアクセスする AuroraDSQLAccess dsql:DbConnect , dsql:DbConnectAdmin ターゲットデータベースに接続する DSQLTokenGeneration dsql:GenerateDbConnectAdminAuthToken , dsql:GenerateDbConnectAuthToken 認証トークンを生成する AWS Glue の IAM 要件の詳細については、 「AWS Glue」 のセキュリティ および Aurora DSQL での Identity and Access Management を参照してください。 AWS Glue ETL ジョブのスクリプト 完全なスクリプトは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 このスクリプトは主に次の処理を行います。 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() を使って IAM 認証トークンを生成します。 スキーマ検出 – AWS Glue データカタログからテーブルスキーマを読み取ります。 データ型マッピング – 次の表のように、Oracle と Glue のデータ型を Amazon Aurora DSQL 向けの PostgreSQL 互換型にマッピングします。 Glue の型 Amazon Aurora DSQL の型 string VARCHAR(255) int INTEGER bigint BIGINT double DOUBLE PRECISION float REAL boolean BOOLEAN timestamp TIMESTAMP date DATE decimal NUMERIC long BIGINT binary BYTEA map JSONB struct JSONB array TEXT[] 入力検証 – SQL インジェクションを防ぐため、テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で検証します。 DDL 実行 – 明示的なトランザクション管理を伴う JDBC 接続を使って、Amazon Aurora DSQL にテーブルを作成します。 データロード – Amazon S3 から CSV データを読み取り、型キャストを適用し、トランザクション分離レベル REPEATABLE_READ とバッチサイズ 9,900 行で JDBC を使って Amazon Aurora DSQL に書き込みます。 Glue ジョブの主な設定 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() メソッドを使用します。 トークンの有効期限 – 最大 24 時間です。ここでは 1 時間に設定しています。 ユーザー ID – サンプルコードで使用するユーザー ID は admin です。 データ型マッピング戦略 – GlueCatalogGeneration を使うと、スキーマのカラムにはソースの値と一致しないことがあるデフォルトのデータ型が割り当てられます。AWS Glue のコードでデータ型マッピング戦略を定義してください。Amazon Aurora DSQL がサポートするデータ型については、 Amazon Aurora DSQL ユーザーガイド を参照してください。 トランザクション分離レベル – Amazon Aurora DSQL ターゲットでは、データ整合性のために REPEATABLE_READ が必要です。 Step Functions ステートマシンを作成する Step Functions ステートマシンが移行ワークフローを制御します。ステートマシンは AWS DMS タスクを開始し、その状態を監視します。AWS DMS タスクが完了すると、テーブルマッピングを抽出してテーブル名を AWS Glue ジョブに渡します。その後、AWS Glue ジョブを起動します。 次の図は、ステートマシンのワークフローを示しています。 ステートマシンワークフローの特徴 AWS DMS の自動開始 – レプリケーションタスクをプログラムで開始します。 進行状況の監視 – AWS DMS タスクの状態を 60 秒ごとにポーリングします。 完了の検出 – stopped ステータスと進行状況 100% を待ちます。 エラー処理 – 失敗した AWS DMS タスクを適切に処理します。 Lambda 連携 – AWS Glue ジョブ向けにテーブル情報を抽出します。 AWS Glue ジョブの起動 – テーブルパラメータを指定して AWS Glue ETL ジョブを開始します。 セットアップの手順 ステートマシンを構成するには、次のステップを実行します。 Step Functions コンソールで、[ Create state machine ] を選択します。 [ Write your workflow in code ] を選択し、ステートマシン定義を入力します。完全なステートマシン定義については、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 定義内の Amazon リソースネーム (ARN) とジョブ名を更新します。 AWS DMS タスクの ARN を、自分のタスクの ARN に置き換えます。 Lambda 関数の ARN を、自分の関数の ARN に置き換えます。 AWS Glue ジョブ名を、自分のジョブ名に置き換えます。 ステートマシンを作成する前に、参照する ARN が存在することを確認します。 次の権限を持つ IAM 実行ロールを作成します。 dms:StartReplicationTask 。 dms:DescribeReplicationTasks 。 lambda:InvokeFunction 。 glue:StartJobRun 。 CloudWatchLogsDeliveryFullAccessPolicy (ステートマシンの実行ログを保存するため)。 ステートマシンのステート ステートマシンは、次のステートを通じて移行を制御します。 ステート タイプ 目的 StartDMSTask Task DMS レプリケーションタスクを開始する GetDMSTaskDetails Task レプリケーションタスクの状態を取得する CheckDMSTaskStatus Choice ステータス (stopped、failed、running) に応じて分岐する WaitForDMSTask Wait 60 秒ごとにポーリングする DMSTaskFailed Fail 失敗したタスクのエラー処理 ExtractTableName Task Lambda を呼び出してテーブル名を取得する StartGlueJob Task テーブル名パラメータを指定して AWS Glue ETL ジョブを起動する Step Functions のセットアップと AWS DMS との統合パターンの詳細については、 AWS Step Functions デベロッパーガイド および Create and run AWS DMS tasks using AWS Step Functions を参照してください。 セキュリティに関する考慮事項 このソリューションでは、機密データを扱う可能性のある複数の AWS サービスを使用します。次のセキュリティのベストプラクティスに従ってください。 責任共有モデル このアーキテクチャは AWS 責任共有モデル に従います。責任は次のように分担されます。 サービス AWS の管理範囲 お客様の管理範囲 Amazon Aurora DSQL データベースエンジン、パッチ適用、高可用性、インフラストラクチャのセキュリティ IAM ポリシー、VPC エンドポイントの構成、暗号化キーの選択 Amazon S3 ストレージインフラストラクチャ、耐久性、可用性 バケットポリシー、暗号化の構成、アクセス制御、ブロックパブリックアクセス AWS DMS レプリケーションインスタンスの OS、エンジンのパッチ適用 エンドポイントのセキュリティ、SSL/TLS の構成、ネットワークアクセス セキュリティ実装の優先順位 データ移行を開始する前に、次の順序でセキュリティ対策を実装してください。 S3 バケットの暗号化 (SSE-KMS) とブロックパブリックアクセスを構成します。 各サービス (AWS DMS、Lambda、AWS Glue、Step Functions) に最小権限の IAM ロールを作成します。 カスタマーマネージド KMS キーで Amazon Aurora DSQL クラスターの暗号化を有効にします。 データがパブリックインターネットを経由しないように、Amazon S3 と AWS Glue の VPC エンドポイントを構成します。 監査とモニタリングのために、AWS CloudTrail と Amazon CloudWatch のログ記録を有効にします。 すべてのデータベース接続で SSL/TLS が強制されていることを確認します。 セキュリティ検証の手順 デプロイ後、次の点を確認します。 # Confirm S3 bucket encryption aws s3api get-bucket-encryption --bucket your-migration-bucket # Confirm Block Public Access aws s3api get-public-access-block --bucket your-migration-bucket さらに、次の点を確認します。 本番環境の IAM ポリシーにワイルドカード ( * ) リソースが含まれていないこと。 DMS レプリケーションインスタンスがパブリック IP を持たないプライベートサブネットに配置されていること。 すべての JDBC 接続文字列で、Amazon Aurora DSQL への接続に sslmode=require が使われていること。 認証トークンが設定した期間内 (AWS は 1 時間を推奨) に失効すること。 移行中のデータ保護 AWS DMS エンドポイントで転送時の暗号化を有効にします (Oracle ソースには SSL/TLS、Amazon S3 ターゲットには SSE-KMS)。 認証トークンをログに出力しないでください。有効期間の短いトークン (1 時間) を使い、設定は環境変数または AWS Secrets Manager に保存します。 aws:SecureTransport 条件を使って、暗号化されていない通信を拒否する S3 バケットポリシーを適用します。完全なバケットポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 AWS Glue ジョブの IAM ロールを、特定の S3 プレフィックスと Amazon Aurora DSQL クラスターに限定します。ワイルドカードの ARN は避けてください。 KMS キーポリシーを使って、移行データを暗号化・復号できるプリンシパルを制御します。 脅威モデル 次の表は、このアーキテクチャで特定し、緩和した脅威を示しています。 脅威 緩和策 過剰な権限を持つ IAM ロール すべての IAM ポリシーを、ワイルドカードではなく特定のリソース ARN に限定します。 テーブル名を介した SQL インジェクション テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で入力を検証します。 認証トークンの盗難やリプレイ 有効期間の短いトークン (有効期限 1 時間) を使い、ログには出力せず、認証情報はコードではなく環境変数に保存します。 S3 中間ストレージへの不正アクセス ブロックパブリックアクセスを有効にし、バケットポリシーを特定の IAM ロールに限定し、SSE-KMS 暗号化を使用します。 コードのセキュリティレビュー 本記事のすべてのコードサンプルは、入力検証、安全な認証処理、最小権限のアクセスパターン、インジェクション攻撃への防御を対象に、手動でセキュリティレビューを実施しています。レビューは、Bandit 1.7 (Python) と ESLint security plugin (JavaScript) による静的解析を使って行いました。 検出結果: Critical または High の重大度の問題は見つかりませんでした。Medium の検出結果 (情報レベルのログ出力) はレビューのうえ、サンプルコードとして妥当と判断しました。 本番環境にデプロイする前に、Amazon Inspector や同等のツール (Bandit (Python)、ESLint security plugin (JavaScript) など) で独自に静的解析スキャンを実行し、組織のセキュリティ基準に照らして検証してください。 Lambda のセキュリティガイドライン インターネットアクセスのない VPC プライベートサブネットに関数をデプロイします。AWS サービスには VPC エンドポイントを使用します。 AWS Key Management Service (AWS KMS) を使って環境変数を暗号化します。 リソースベースのポリシーを適用し、呼び出しを Step Functions のみに制限します。 実行ロールには最小権限の原則を適用します ( dms:DescribeReplicationTasks と dms:DescribeTableStatistics のみ)。 予約済み同時実行数を設定し、呼び出しの暴走を防ぎます。 Step Functions のセキュリティガイドライン AWS KMS カスタマーマネージドキーを使って、ステートマシンの保管時の暗号化を有効にします。 実行履歴のために、暗号化を有効にした Amazon CloudWatch Logs を有効にします。 ステートマシンの入力や出力で機密データ (トークン、パスワード) を渡さないようにします。AWS Systems Manager Parameter Store または AWS Secrets Manager を使用します。 実行ロールが最小権限に従っていることを確認します (AWS DMS、Lambda の呼び出し、AWS Glue の StartJobRun の権限のみ)。 IAM リソースベースのポリシーを使って、ステートマシンへのアクセスを制限します。 クリーンアップ 今後の課金を避けるため、このチュートリアルで作成したリソースを削除します。 Step Functions コンソールで、対象のステートマシンを選択し、[ Delete ] を選択します。 Lambda コンソールで、対象の関数を選択し、[ Actions ]、[ Delete ] の順に選択します。 AWS Glue コンソールで、対象の ETL ジョブを選択し、[ Action ]、[ Delete job ] の順に選択します。 AWS DMS コンソールで、次のリソースをこの順序で削除します。 移行タスク。 エンドポイント (ソースとターゲット)。 レプリケーションインスタンス。 Amazon S3 コンソールで、移行用バケットを空にして削除します。 Amazon Aurora DSQL コンソールで、対象のクラスターを選択し、[ Delete ] を選択します。 IAM コンソールで、このソリューション用に作成した IAM ロールとポリシーを削除します。 カスタマーマネージド KMS キーを使用した場合は、まだ必要かどうかを評価し、適切であれば削除をスケジュールします。 まとめ 本記事では、AWS DMS、Step Functions、Lambda、AWS Glue を使った自動化のアプローチで、Oracle から Amazon Aurora DSQL へ移行する手順を説明しました。このソリューションは、Amazon Aurora DSQL のサーバーレスアーキテクチャ特有の課題に対応します。Amazon S3 を中間ストレージとして使い、ワークフロー全体に十分なエラー処理を組み込むことで、手作業や運用の複雑さを抑えつつ、信頼性の高いデータ移行を実現できます。 Amazon Aurora DSQL の進化に合わせて、この移行フレームワークはデータベースモダナイゼーションを進めるうえで確かな基盤になります。インフラストラクチャのコストと管理の負荷を抑えながら、Amazon Aurora DSQL を最大限に活用できます。 この移行アプローチを始めるには、次の手順を実行します。 GitHub の sample-oracle-to-aurora-dsql-migration リポジトリをクローンします。 テストテーブルを使って、AWS アカウントに Step Functions ワークフローをデプロイします。 本番のワークロード全体に拡張します。 ご質問やフィードバックがあれば、コメントで共有するか、 AWS re:Post community をご覧ください。 著者について Aliasghar Hussain AWS の Database Specialist Solutions Architect です。Amazon RDS、DocumentDB、DynamoDB、ElastiCache といったクラウドデータベース技術で 6 年以上の経験があります。また、複雑なデータベース移行戦略、モダナイゼーション、インフラストラクチャ最適化に関する技術的なガイダンスを提供する分野の専門家として、お客様の AWS におけるクラウド導入の加速を支援しています。 Wasim Shaikh AWS でデータベースを専門とする Senior Solutions Architect です。お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を利用する際のソリューションの価値向上を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 5 回レポートです。シリーズの背景や全体像については、 初回の大阪・事業会社編レポート をご覧ください。 大阪・名古屋に続き、2026 年 4 月 27 日は広島にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト木村 友則から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI が「アシスタント」から「仕事を任せられる」存在へと進化してきた流れ、人手不足という社会課題に対して AI エージェントが果たせる役割、そして AI コーディングツールの Kiro と AI エージェントプラットフォームの Amazon Quick を、デモを交えてご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: ソリューションアーキテクト木村によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中小企業のお客様への生成 AI 導入を支援されたパートナー企業様に、その現場で得られた知見をお話しいただきました。 事例紹介：株式会社エイチビーソフトスタジオ様 〜「完璧を待たず、まず触ってみる」現場に寄り添う生成 AI 導入支援〜 事例紹介は 株式会社エイチビーソフトスタジオ 様です。愛媛県松山市を拠点に、全社員が完全リモートで業務を行い、スタッフ全員がエンジニアという企業です。システム開発・スマートフォンアプリ開発・Web システム開発などを手がけられ、使い勝手とデザイン性にこだわったアプリケーションの制作や、障害に強いサーバー設計・運用を得意とされています。同社のサービスサイトには「小さく作るを繰り返す」という開発スタイルが掲げられており、AWS を活用したクラウド環境の構築支援も提供されています。当日は AWS 木村 (営業) がモデレーターを務め、代表取締役の影浦 義丈 様に、実際に手がけられた中小企業向けの生成 AI 導入支援についてパネルディスカッション形式でお話しいただきました。 きっかけは、属人化した問い合わせ対応 今回ご紹介いただいたのは、社員 10〜50 名程度の中小企業のお客様に対する、生成 AI を活用したナレッジ共有・業務効率化の導入支援プロジェクトです。 きっかけは、お客様社内での問い合わせ対応に多くの時間が割かれていたことでした。質問が特定の人に集中し、回答の品質も人によってばらつく。多くの企業が抱える「詳しい人に聞かないと分からない」という状態です。影浦様は「お客様に対するサポートも含め、何とかしたいというのが取り組みのきっかけでした」と振り返られました。 立ちはだかった 3 つの壁 ― 期待値・ルール・データ 実際に取り組みを進める中では、大きく 3 つの壁に直面したといいます。 1 つめは 期待値の壁 です。生成 AI に対する社内の温度感に差があり、影浦様は「トップの方は『ゴーゴー』という感じなんですけれども、現場の方は『何のためにやるのか分からない』という気持ちを持たれている場合もある」と語られました。その一方で、「AI を導入すれば何とかなる」「AI を入れれば 100% の結果が返ってくる」という、高すぎる期待値が生まれてしまうこともあったといいます。 2 つめは ルールの壁 です。生成 AI を活用する上で、どこでデータが処理されるべきかといったガバナンスの考え方や社内ルールが、そもそも全くない状態でした。 3 つめは データの壁 です。生成 AI 活用のベースになるノウハウやナレッジが、そもそもドキュメント化されていない。あるいはドキュメントにはなっていても、ファイル形式や保存場所がバラバラだったり、古い状態のまま更新されていなかったりと、活用の準備が整っていない状態でした。 3 つの壁をどう乗り越えたか これらの壁に対する影浦様の実際のアプローチをお話いただきました。 AI への期待値の壁を乗り越えるために、実際に AI に触れてもらい、何ができて何ができないかを肌感をもって理解してもらうことに取り組まれました。ただ、「ツールをポンとお渡しして『やってください』と言っても、なかなか難しい」と感じられたため、社員の皆様に向けたハンズオンを定期的に開催し、生成 AI への理解を高める機会を作りました。あわせて、活用のノウハウがどうしても各人それぞれに蓄積されてしまうという課題に対しては、各自の使い方や「結果が良かった・悪かった」を発表してもらう場を設け、QA を通じて全社的にノウハウを蓄積していく方法をとり、その実施にあたっての支援も行ったということです。 ルールの壁については、いきなり「まずはルールを作ってください！」とお伝えしてもプロジェクトが進みづらい、という前提に立ち、まず影浦様が叩き台となる基準を用意し、それをベースにお客様とやり取りしながら細かく積み立てて運用ルールを作っていかれました。 そして特徴的だったのが、データの壁への対処です。ドキュメント化されていない属人的なノウハウを「ゼロから文章を書いてください」と言ってもなかなか書けない。そこで影浦様が試したのが、 AI でインタビューをさせて、ドキュメントの種を引き出す という方法でした。継続的に改善するには、人のインタビュアーを常に用意するのは難しい。そこで AI を活用してインタビューからドキュメント化までを一貫して行える仕組みを構築したといいます。このとき影浦様が強調されたのは、ツールの新しさそのものではなく使い手の側でした。「生成 AI を結局利用するのは人間なので、人間がどれだけ詳細な指示を与えられるか。これが肝になってくると思います」。AI をうまく動かすためのドキュメントづくりを、AI 自身に手伝わせる。データが整理しきれていない中でも、まず一歩を踏み出すための現実的な工夫です。 取り組みの成果と、残る課題 取り組みの結果、問い合わせ対応の時間が削減され、特定の人への負荷集中が緩和されました。加えて、回答品質のばらつきの是正など、いくつかの成果を得ることにつながりました。 またさらなる成果として、ドキュメント化の「文化」が根づき始めた、という点もありました。それまでは様々な知見が暗黙知になりがちでしたが、AI への取り組みを続けるなかで、少しずつドキュメントに残し、展開していこうという文化につながりつつあるということです。この文化が広がっていくことで、他の業務でも「生成 AI を使ってみたい」という社員様が新しく出てくるなど、新たなユースケースの創出にもつながり始めています。 一方で、文化の定着には時間がかかること、AI の回答精度を上げながら改善し続ける必要があること、勉強会はやっているものの個人ごとの定着度や使い方にばらつきが残ることなど、継続的なフォローの重要性も語っていただきました。 参加者へのアドバイス ― 「触ってみないと分からない」 AI は進化も早く、また企業の課題も様々であるため、AI の活用方法の見定めには「やはり触ってみないと分からないことが多い」と述べられたうえで、「データにしてもセキュリティのルールにしても、完璧に全て揃えてからではなく、今あるもので、まず小さく始めて触ってみることが大切」と述べていただきました。 また、生成 AI の社内展開について、「個人で進めるのではなく、ハンズオンや勉強会、共有会のような場で、全社的に・チームでノウハウを共有しながら進めていただくと、取り組みが定着しやすくなる」と語られました。 写真: 株式会社エイチビーソフトスタジオ 影浦様、AWS 木村 (営業) によるパネルディスカッション まとめ セッション後には参加者同士のグループワーク・ディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。アンケートでは「他業種の方のお話を聞く機会が少ないため大変参考になった」「少人数で密に意見交換ができた」といった、参加者同士の交流を評価する声を多くいただきました。参加者の皆様も、ご自身に近い背景を持つ地元企業の取り組みを情報交換したり、その場で相談しあったりできており、AWS もその輪に参加させていただけてとても有意義な時間だったと感じております。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした広島編に続き、次回は福岡編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「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）開催レポート 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

国内最大規模の学習型 IT カンファレンスである AWS Summit Japan が、2026 年 6 月 25 日（木）・26 日（金）の二日間にわたり幕張メッセで開催されます。今年のサミットでは エージェンティック AI と Physical AI（フィジカル AI） が大きなテーマとして掲げられており、AI Agent が自律的にタスクを遂行するだけでなく、現実世界のモノを動かす技術に注目が集まっています。ヘルスケア・ライフサイエンス（ HCLS ）ブースでは、昨年に続き（ 開催報告はこちら ）、今年も多彩なデモを展示予定です。 本記事では、その中から AWS 上の AI Scientist（ AI 科学者）が実験用ロボットを直接操作し、自律的に科学実験を遂行する Self-Driving Lab デモをご紹介します。 創薬研究と DMTA サイクル ライフサイエンス研究、特に創薬研究では DMTA サイクル （ Design–Make–Test–Analyze ）と呼ばれる反復プロセスが広く用いられています。研究者は候補となる化合物や実験条件を 設計（ Design ） し、それを実際に 合成・作製（ Make ） し、得られたサンプルを 測定・評価（ Test ） し、その結果を 分析（ Analyze ） して次のサイクルへフィードバックする ― このループを何度も回しながら、最適な化合物や条件を探索していきます。しかし、各ステップには専門的な判断と手作業が伴います。サイクルを回す速度と、同時に探索できる範囲が、研究の進捗を左右する大きなボトルネックです。 AI Agent が変える研究のかたち ” Self-Driving Lab ” ― Dry から Wet へ 近年、 AI Agent は研究の世界に急速に浸透しつつあります。 DMTA サイクルにおける Design（設計）や Analyze（分析）のような Dry（計算・情報処理）のプロセス ― すなわちコンピュータ上で完結する In Silico の領域 ― では、最新の基盤モデルを活用した AI Agent が研究者レベルの分析・推論を行えるようになってきました。一方で、 Make（合成）や Test（評価）のような Wet（実験）のプロセス は物理的な操作を伴います。コンピュータの中に閉じた AI Agent だけでは、このステップを自律的に実行することはできませんでした。ここに Physical AI ― AI が実世界の装置やロボットを直接制御する技術 ― を組み合わせることで、はじめて DMTA サイクル全体を AI が回しきることが可能になります。 もし AI が DMTA サイクルのすべてのステップ ― Dry も Wet も ― を自律的に実行できたら、何が起こるでしょうか。 AI が仮説を立て、実験を設計し、ロボットに指示を出して実際にサンプルを作り、測定結果を解析し、次の実験を自分で決める。このループを AI が完全に閉じることができれば、人間の介在なしに実験を 24 時間回し続けることが可能になります。これが Self-Driving Lab（自律実験室）のコンセプトです。 Self-Driving Lab が実現することで、探索の範囲を一気にスケールアウトでき、従来であれば研究者が数週間かけて到達する結論に、はるかに短い時間で辿り着ける可能性があります。 ラボ自動化の壁を AI が乗り越える ラボの自動化装置自体は以前から存在しています。しかし、こうした装置を動かすには実験ごとに専用のプロトコル（メソッド）を作成する必要があり、実験のたびに条件が変わる研究の現場では「プロトコルを毎回書き直す学習コスト・構築コストが重い」という壁がありました。結局、手作業のほうが早いと判断されてしまうケースが少なくありません。 AI Agent がプロトコル設計やバリデーションを自律的に行えるようになると、この状況は大きく変わります。今回のデモのようにループを完全に閉じる Self-Driving Lab だけでなく、研究者と AI が協調しながらプロトコルを半自動的に生成・検証するだけでも、 Wet 研究を大幅に加速できます。自動化装置の真のポテンシャルを引き出す鍵が、 AI Agent にあると言えるでしょう。 デモ紹介：AI Scientist ― フィジカル AI が実現する眠らないラボ 今年の HCLS ブースでは、 Self-Driving Lab のコンセプトを体感いただけるライブデモを展示します。シナリオはシンプルです。 3 種類の異なる色の原液（ A / B / C ）をランダムな比率で混合した「秘密サンプル」を用意します。 AI Scientist は、この秘密サンプルの配合比率を、実際にロボットを操作しながら自律的に突き止めます。 具体的な流れを見てみましょう。 まず AI は秘密サンプルの吸光度スペクトル（光の吸収度合いを波長ごとに測定したデータ）を取得し、ターゲットとなる測定値を把握します。 次に、配合比率に関する仮説を立て、それを検証するための実験パターンを設計します。 設計が決まると、 AI は自動分注装置（ Tecan Fluent ）に対して分注指示を送り、配合候補のサンプルを実際に作製します。 作製したサンプルの測定データをターゲットと比較・分析し、差異が大きい部分に注目して次に試すべき配合を決定します。 このサイクルを数回繰り返すうちに推定精度が上がり、最終的には正しい配合比率に到達します。 色水という身近な題材ではありますが、 AI が「考えて、試して、学んで、また試す」という科学研究の本質的なプロセスを自律的に実行する様子を目の前でご覧いただけます。 Dry のプロセス（仮説生成・実験設計・データ分析）と Wet のプロセス（ロボットによる分注・測定）の両方を AI が担い、ループを完全に閉じて自律的に回している点が、本デモの最大の見どころです。徐々に混合液の色が正解に近づいていく過程は、視覚的にもお楽しみいただけるポイントです。 技術的なポイント 自動分注装置との接続には SiLA 2 （ Standardization in Lab Automation ）プロトコルを採用しています。 SiLA 2 はラボ機器間の通信を標準化するオープンな国際規格で、メーカーを問わず装置を統一的なインターフェースで制御できるようにするものです。これにより、 AI Agent がソフトウェアから直接ロボットを操作する連携が可能になります。AI Agent 自体は Amazon Bedrock 上で動作し、実験の計画立案から測定結果の解析、次の実験の意思決定までを一貫して担います。実験全体のワークフロー管理には AWS のクラウドサービスを活用し、一連の自律実験ループをオーケストレーションしています。アーキテクチャの詳細・実装の工夫・技術的なご質問は、ぜひ当日ブースにて直接どうぞ。 同じアーキテクチャで広がる応用先 今回は色水の配合比率という分かりやすいシナリオでデモを行いますが、この Self-Driving Lab のアーキテクチャは、より実践的な研究課題へそのまま展開できます。 創薬研究におけるアッセイ（生物活性の測定試験）条件の最適化 細胞培養のための培地組成探索 製剤における処方設計 いずれも「複数の条件を組み合わせて最適解を見つける」という課題構造は共通しており、 AI が自律的に探索空間を効率よくカバーする Self-Driving Lab の真価が発揮される領域です。HCLS ブースでは、本デモのライブ実演に加え、 4 月に一般提供が開始された Amazon Bio Discovery のデモなど、複数の展示を用意しております。「 AI × ロボット × クラウド」が創る研究の未来を、ぜひ会場で体感してください。皆さまのご来場を心よりお待ちしております。 ヘルスケア・ライフサイエンス関連ブースのご案内：ブース一覧 エリア ブース番号 タイトル テーマ AWS for Healthcare & Life Sciences A001 AI Scientist ― フィジカル AI が実現する眠らないラボ Self-Driving Lab A013 中外製薬株式会社 創薬・業務向け AI 共通基盤 A014 第一三共株式会社 AWS PCS × AI エージェントによる創薬研究基盤 A015 Amazon Bio Discovery AI エージェント型 AWS マネージドサービス A016 AI エージェントが実現する次世代医療ワークフロー AI エージェントによる自律的な診断支援 AWS for Public Sector A039 神戸大学大学院医学系研究科 生成 AI 書類審査ソリューション「 RAPID 」 A040 公共ヘルスケア＆アカデミア ヘルスケア× AI ：医療・介護の未来 A001　AI Scientist ― フィジカル AI が実現する眠らないラボ AI が仮説を立て、実験し、最適解を導く ― クラウドが繋ぐ Self-Driving Lab AI が自律的に仮説を立て、ライフサイエンス向けオートメーションワークステーション実機へ実験を指示し、測定結果を解析して次の実験計画を自ら決める。このサイクル全体を AWS クラウドがオーケストレーション。ブースでは実機稼働の様子をリアルタイムで観察でき、 AI が「秘密の混合サンプル」を自力で推定・再現する瞬間を目の前で体感できます。ぜひブースにお立ち寄りください。 A013　中外製薬株式会社 創薬・業務向け AI 開発を支える AWS 共通基盤 中外製薬では、創薬領域や全社業務の変革に向けた AI 活用を支える基盤の整備を進めています。 AWS 上に認証、 API 連携、 LLM 利用等の共通機能を集約することで、 AI アプリごとの重複実装を抑制し、品質向上と開発スピード向上を両立します。 AI 活用を広げながら、新たなアプリ、エージェント開発・連携や価値創出に繋げる取り組みをご紹介します。 A014　第一三共株式会社 AWS PCS と AI エージェントで作る創薬研究基盤 近年、 AI や解析技術の急速な発展により研究の在り方は大きく変革しており、ロボティクスや生成 AI の導入によって、大量の情報に基づく意思決定の質の向上と効率化が期待されています。第一三共では AWS PCS を用いた解析基盤の安定化と、 AI エージェントによる研究効率化に挑戦しました。本発表では技術導入の背景・成果・今後をご紹介します。 AI エージェントが研究現場にもたらす変革の可能性や期待について、議論できれば幸いです。 A015　AI 創薬 新サービス Amazon Bio Discovery Lab in the loop の創薬をすべての研究者に ― AI エージェント型 AWS マネージドサービス このブースでは、 AWS の新サービス「 Amazon Bio Discovery 」をご紹介します。 AI エージェントと 40 以上の生物学 AI モデルを活用し、抗体設計からウェットラボ検証までを一気通貫で支援する AWS マネージドサービスです。計算予測と実験結果が自動フィードバックされることで、研究組織全体で「 Lab-in-the-Loop 」をアクセス可能かつスケーラブルにすることが可能です。ご興味ある方はぜひブースにお立ち寄りください。 A016　AI エージェントが実現する次世代医療ワークフロー 画像解析からレポートドラフト生成まで ― 自律的な診断支援で医師を支える 日本の放射線科医は世界トップクラスの画像診断件数をこなし、業務負荷は増す一方です。本展示では、新規の医用検査画像の到着を起点に Amazon Bedrock AgentCore にホストされた AI エージェントが読影前の準備を自律的に遂行し、医師が確認と最終判断に集中できるワークフローをお見せします。  エージェントが自動で行うこと： 電子カルテから患者背景・既往歴・過去の読影レポートを収集 専門の医療 AI モデルによる病変検出・臓器セグメンテーション・画像所見の解釈 過去検査の確定所見との突き合わせによる経時比較 診断ガイドライン等と照合した日本語の構造化レポートドラフトを生成。過去レポートから読影医の記述スタイルを抽出し、その医師らしい書き味で下書き 医師は AI エージェントによる解析結果とドラフトを確認・修正するだけでレポートを仕上げられ、診断までの時間を短縮可能になります。チャットでの追加指示や所見の深掘りも可能です。ぜひブースで体感してください。 A039　公共アカデミア 神戸大学大学院医学系研究科  生成 AI 書類審査ソリューション「 RAPID 」による研究申請プロセス DX / AX 神戸大学 MedLeap（医療特化型スタートアップ拠点）は、研究審査における修正の往復という課題に対し、申請プロセスを再設計する取り組みを進めています。その実装として、 Amazon Bedrock を基盤とする書類審査ソリューション「 RAPID 」で先行開発中。現場のスピードと品質の両立を目指し、当日は、今後の展望をご紹介いたします。 AI 実装、業務改革、産学共創、実証フィールド、スタートアップ創出に関心のある皆様のご来訪をお待ちしております。 A040　公共部門 ヘルスケア ヘルスケア× AI ：医療・介護の未来 AWS の先進技術を活用し、医療・介護の現場課題を解決するデモを展示します。医療文書の自動生成や診察・カンファレンスにおける音声入力を利用した診療録・記録の作成、医療情報ガイドラインやデジタル庁 GCAS ガイドを遵守したアプリケーション開発に AWS のエージェントコーディングツール Kiro を活用する方法、 Kiro と AWS HealthOmics を利用した精密医療のためのゲノミクス解析と可視化、さらには AI を利用した研究計画書の自動作成まで、ヘルスケアにおける幅広い AI 活用の最前線をぜひブースでご体験ください。 Summit 会場：HCLS ブースへのアクセス 本ブログは AWS Summit Japan 2026 ヘルスケア・ライフサイエンスブースの展示紹介シリーズです。他の展示内容については追って公開予定です。

AWS Graviton プロセッサは世代を重ねるごとに着実に進化を遂げ、イテレーションを経るごとに、コンピューティングパフォーマンス、料金パフォーマンス、エネルギー効率の点で進歩してきました。re:Invent 2025 では、Graviton5 を搭載した初のインスタンスである Amazon EC2 M9g のプレビュー版について お知らせしました 。それ以降、お客様は、幅広いワークロードで M9g をテストし、その結果を共有してくださいました。 ClickHouse は、コードを変更することなく、M8g と比較して 36% のパフォーマンス向上を実現しました。 Honeycomb は、本番オブザーバビリティワークロードの 6 か月間の A/B テストにおいて、Graviton4 と比較してコアあたりのスループットが 36% 向上しました。  HubSpot は、MySQL データベースに M9g をデプロイし、クエリ実行時間を最大 60% 短縮しました。2026 年 6 月 10 日より、M9g インスタンスと、高速かつ低レイテンシーのローカル NVMe SSD ストレージを必要とするお客様向けの新しい M9gd インスタンスの一般提供を開始しました。どちらのインスタンスも、AWS がこれまでに構築した中で最も強力かつエネルギー効率に優れたプロセッサである Graviton5 を搭載しています。 業界では多くの Arm ベースのインスタンスが登場していますが、AWS Graviton の展開の幅広さと奥深さに匹敵するものは他にありません。カスタムシリコンの 5 つの世代と 8 年間の継続的な投資を経て、Graviton は 350 を超えるインスタンスタイプを支え、スタートアップから大企業、強固な ISV パートナーエコシステム、幅広い一連のマネージドサービスに至るまで、12 万を超えるお客様にサービスを提供しています。Graviton は、ウェブアプリケーション、マイクロサービス、分析、データベース、機械学習 (ML) 推論、Electronic Design Automation (EDA)、ゲーム、動画エンコーディングなど、多種多様なワークロードにご利用いただけます。ワークロードでのコンピューティング負荷がより高まり、ワークロードがよりデータドリブンになるにつれ、より多くのデータを移動し、ワークロードをより迅速に完了させるために、より高い処理能力に加え、ネットワークとストレージの帯域幅の拡大を求める声が高まっています。また、当社は、コンピューティング、メモリ、I/O を効率的にパッケージ化して、エネルギー効率を最大化するために、これらのインスタンスを設計しました。 AI の役割が、質問への回答から、アクションの実行、コードの実行、ツールの使用、結果の評価、複数ステップのタスクのオーケストレーションに移行するにつれ、CPU コンピューティングの需要は急速に高まっています。Graviton5 はこの変化に対応するために構築されました。192 コア、5 倍の L3 キャッシュ、最大 33% 低いコア間レイテンシー、高帯域幅を実現する DDR5 メモリを搭載した Graviton5 は、エージェントが CPU バウンドなステップでの待機時間を短縮して、より多くの命令を処理し、多数の同時実行環境に対応するとともに、アクセラレーターを常に稼働させ続けるのに役立ちます。 Meta は、そのエージェンティック AI の取り組みをサポートするために、まずは数千万コアの規模で Graviton を大規模にデプロイしており、Graviton を利用する世界最大のお客様の 1 社となっています。リアルタイム推論、コード生成、複数ステップのタスクのオーケストレーションなど、エージェンティック AI ワークロードは CPU 負荷が高く、Graviton5 の優れたコンピューティングパフォーマンス、より大きなキャッシュ、より高いメモリ帯域幅、コア密度の恩恵を享受できます。 M9g および M9gd の新機能 第 6 世代 AWS Nitro System を基盤として構築された M9g インスタンスは、Graviton4 プロセッサと比較して、より高いコンピューティングパフォーマンス、より大きなキャッシュ、改善されたメモリおよび I/O スケーラビリティを提供する AWS Graviton5 プロセッサを搭載しています。Graviton5 は、Graviton4 ベースのインスタンスと比較して、最大 25% 優れたコンピューティングパフォーマンスを提供し、ウェブアプリケーションでは最大 35%、機械学習推論では最大 35%、データベースでは最大 30%、パフォーマンスが高速化されます。AWS Graviton5 インスタンスは、AWS フリートで初めて最新世代の PCIe Gen6 と DDR5-8800 メモリをサポートする CPU として、クラウドにおけるあらゆるプロセッサインスタンスの中で最速のメモリと、前世代と比較して 5 倍の L3 キャッシュを提供します。 また、これらの改善により、エネルギー効率も向上します。そのため、性能を損なうことなく、持続可能性に関する目標を達成するのに役立ちます。 コンピューティングの増大に対応するため、ネットワーキングとストレージの帯域幅が拡張されました。M9g および M9gd インスタンスは、さまざまなサイズにわたって、平均で最大 15% 高いネットワーク帯域幅と 20% 高い Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供し、最大インスタンスサイズではネットワーク帯域幅が最大 2 倍になります。また、M9g および M9gd インスタンスは、Amazon EC2 インスタンスの Amazon EBS と Amazon Virtual Private Cloud (Amazon VPC) ネットワーキングの間の帯域幅の割り当てを最大 25% 調整するのに役立つ機能である Instance Bandwidth Configuration (IBC) もサポートしています。IBC は、データベースの読み書きのパフォーマンス、クエリ処理、ログ記録など、特定の帯域幅要件を満たす必要があるワークロードのパフォーマンスの最適化に役立ちます。これらの機能強化は、高い I/O パフォーマンスを必要とするワークロードのために、より迅速なデータ移動と改善されたスループットをサポートします。 セキュリティと分離は、クラウドでワークロードを実行するための基本的な要件です。Nitro System 内では、AWS Nitro Hypervisor が、インスタンス同士で、また、AWS オペレーターからも分離するように設計されています。M9g および M9gd インスタンスでは、Nitro Isolation Engine の導入により、セキュリティの水準をさらに引き上げています。Nitro Isolation Engine は Nitro System の機能強化であり、インスタンスの分離を強制し、形式検証を活用して数学的な精度で分離の保証を提供します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。 M9g インスタンスは、4 GiB のメモリごとに 1 vCPU を提供し、アプリケーションサーバー、マイクロサービス、中規模データストア、ゲーミングサーバー、キャッシングフリート、コンテナ化アプリケーション、大規模 Java アプリケーション、コードリポジトリ、ウェブアプリケーション、エージェンティック AI など、幅広い汎用ワークロードに適しています。 高速かつ低レイテンシーのローカルストレージを必要とするワークロード向けには、M9gd インスタンスが、最大 11.4 TB の NVMe SSD ストレージに加えて、Graviton4 ベースの M8gd インスタンスと比較して 30% 向上した IOPS とストレージパフォーマンスを提供します。M9gd インスタンスは、アプリケーションサーバー、マイクロサービス、ゲーミングサーバー、中規模 key-value データストア、キャッシングフリート、データログ記録、メディア処理、バッチおよびログ処理、キャッシュやスクラッチファイルなどの一時ストレージを必要とするアプリケーションなど、コンピューティングとメモリのバランスと、高速かつ低レイテンシーのローカルストレージが求められる汎用ワークロードに適しています。 このファミリー全体の主な仕様を次に示します: M9g vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 4 最大 15 最大 12 large 2 8 最大 15 最大 12 xlarge 4 16 最大 15 最大 12 2xlarge 8 32 最大 17 最大 12 4xlarge 16 64 最大 17 最大 12 8xlarge 32 128 17 12 12xlarge 48 192 25 18 16xlarge 64 256 34 24 24xlarge 96 384 50 36 48xlarge 192 768 100 72 metal-48xl 192 768 100 72 M9gd インスタンスには、ローカル NVMe SSD ストレージが含まれます。以下の表は、各サイズのインスタンスストレージを示しています。コンピューティング、メモリ、ネットワーク、および EBS 帯域幅の仕様は M9g と同じです。 M9gd vCPU メモリ (GiB) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 4 1 x 59 NVMe SSD 最大 15 最大 12 large 2 8 1 x 118 NVMe SSD 最大 15 最大 12 xlarge 4 16 1 x 237 NVMe SSD 最大 15 最大 12 2xlarge 8 32 1 x 475 NVMe SSD 最大 17 最大 12 4xlarge 16 64 1 x 950 NVMe SSD 最大 17 最大 12 8xlarge 32 128 1 x 1900 NVMe SSD 17 12 12xlarge 48 192 3 x 950 NVMe SSD 25 18 16xlarge 64 256 1 x 3800 NVMe SSD 34 24 24xlarge 96 384 3 x 1900 NVMe SSD 50 36 48xlarge 192 768 3 x 3800 NVMe SSD 100 72 metal-48xl 192 768 3 x 3800 NVMe SSD 100 72 今すぐご利用いただけます M9g および M9gd インスタンスは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) リージョンでご利用いただけます。M9g および M9gd インスタンスは、 Savings Plans 、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細については、「 Amazon EC2 の料金 」にアクセスしてください。 M9g および M9gd インスタンスの使用開始に際して、いくつかのリソースをご利用いただけます。 AWS Graviton 開始方法ガイド は、Graviton ベースのインスタンス上でワークロードを構築、実行、最適化する方法をカバーするテクニカルガイドです。 Graviton Savings Dashboard は、Graviton ベースのインスタンス上でワークロードを実行することで実現できるコスト削減を追跡および測定するのに役立ちます。 AWS Transform は、Java アプリケーションを x86 から Graviton ベースの Amazon EC2 インスタンスに移行するためのコード変換を自動化する、AI を利用したサービスです。互換性分析、自動再コンパイル、依存関係の更新、検証を処理します。 Graviton ベースのインスタンスの詳細については、「 AWS Graviton プロセッサ 」または「 Level up your compute with AWS Graviton 」にアクセスしてください。 – Esra 原文は こちら です。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 3 回レポートです。シリーズの背景や全体像については、 前回の大阪・初回レポート をご覧ください。 大阪での 2 日間のイベントに続き、2026 年 4 月 22 日は名古屋にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」と題したイベントを開催しました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト古屋 楓から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick のデモを交えながらご紹介しています。セッションの詳細については 初回の大阪・事業会社編のレポート をご覧ください。 写真: 古屋によるオープニングセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中部を拠点に 270 年以上の歴史を持ちながら、経営・現場の双方から生成 AI 活用に挑戦されている 1 社の事例をご紹介します。 事例紹介：タキヒヨー株式会社様 〜経営と現場、両輪で進める Amazon QuickSight によるデータ活用〜 事例紹介は タキヒヨー株式会社 様です。1751 年（江戸時代の宝暦元年）に名古屋で創業された 270 年以上の歴史を持つ繊維アパレル企業で、テキスタイル事業では愛知県一宮市に自社工場をお持ちで、伝統的な英国式紡績機を生かしたものづくりを行われています。アパレル事業では企画・製造・販売に加え、リテール事業として自社ブランドの展開もされており、東京証券取引所・名古屋証券取引所に上場されている企業です。従業員数は540 名(2026年2月末)、ニューヨークに拠点をお持ちのグローバル企業でもあります。 当日は、経営視点と現場視点の両面から、二つのプロジェクトについてパネルディスカッション形式でお話しいただきました。AWS 小嶋がモデレーターを務め、それぞれのプロジェクトの背景から成果までを伺いました。 業務 KPI ダッシュボード化プロジェクト 一つめのエピソードは、執行役員の平田様が経営の視点で推進された、業務 KPI ダッシュボードプロジェクトについてです。 アパレル業界は職人的・属人的な業務傾向があり、勘や経験に頼りがちな面があります。経営として、売上や利益といった KGI よりもっと粒度の細かい業務 KPI で組織の状態を定量的に把握し、営業活動の改善に繋げたいという思いがプロジェクトの出発点でした。ただ当時は、各組織のデータが Excel に散在し、VBA マクロで集計していたため、処理に時間がかかったりマクロが想定どおり動作しないなどの課題がありました。 この課題に対して、 Amazon QuickSight を導入し、基幹システムや NAS のデータを一元的に可視化・分析できる基盤を構築されました。ただ、導入にあたって一番苦労されたのが「現場のアレルギー反応」だったといいます。それまで各マネージャーが各々のやり方で管理業務を回していたところに、統一のダッシュボードを導入するという施策そのものに対して、「手間が増える」という受け止めから反発があったとのことです。 この壁を乗り越えるために、とにかく使い勝手にこだわってプロジェクトを進められました。便利さを実感してもらうことで理解を得て、利用も促進したいと考え、ドリルダウン機能の設計に特に注力されました。 大きなデータから詳細なデータへと段階的に掘り下げることができ、感覚的な操作で目的のデータにたどり着けるよう設計 しました。「普段の動線そのままで使える」ことで現場の抵抗感を下げることに繋げました。また、 データの欠損を補うためにWeb経由のデータ入力の仕組みも構築 し、ダッシュボードに表示されるデータの信頼性を担保する工夫も行われました。 結果として、URL にアクセスすれば経営データがすぐ確認できる状態になり、 現場のマネージャーが本来の意思決定業務に集中 できる環境が整いつつあるとのことです。今後は、分析の精度向上や、分析から起こしたアクションが業績にどう寄与するかの効果検証をしていきたい、とお話いただけました。 需要予測データのダッシュボード構築プロジェクト マーケティングチーム兼DX 推進チームの山口様が現場の実践者として推進されたプロジェクトです。 山口様ご自身はエンジニアではなく、プログラムを書いたご経験はありませんでした。ただ、「自分たちの手でなんとか活性化させたい」という思いから、需要予測データを Amazon QuickSight で可視化するダッシュボードの内製構築に取り組まれました。既存データには、複数の情報（色・柄・素材など）が一つのカラムにまとめて格納されていたため個別の値で抽出できない（例えば何色が売れているか？といった分析はできない）、需要予測の数値が絶対値のみのため、判断の基準がなくアクションに繋がらない、という二つの課題がありました。 開発にあたって、当初は Generative AI Use Cases （ AWSが提供するチャットベースの生成AIアプリケーション）で SQL を生成させていましたが、開発が難航しました。チャットベースのアプリケーションで、必要なデータ（DBのテーブル情報、全体設計、既存データなど）をAIに与えながら作業をさせようとすると、開発が進むほどコンテキストの制限に達してしまい、その都度新しい会話を立ち上げ直す必要が生じ、作業上の煩雑さを生んでいました。さらに、本来は必要なコンテキストを渡しきれない状況も発生し、そうなるとAIが出力するSQLが本来の目的と異なるものになる、といった問題も発生していました。 このような経緯から、チャットボットベースのアプリケーションに限界を感じられ、コーディングエージェントの Claude Code を Amazon Bedrock 経由で利用する方針に切り替えられました。コーディングエージェントであれば、AI エージェントがユーザー指示に応じて必要なローカルファイルを自律的に参照しにいくため、今まで作成してきたテーブル情報やシステム設計、エラー内容までを AI が自動で把握してくれ、開発効率が大きく向上しました。 データの課題については、既存のデータのETLにも取り組まれました。具体的には、一つのカラムに混在していた色・柄・素材などのデータを色別・素材別・シルエット別などにそれぞれのカラムに分けて対応し、絶対値で表示されていた需要予測値も ◎○△✕評価が動的に表示される仕組みに変更されました。この際、Claude Code を単なるコード生成ツールとしてではなく、 目的を共有し、既存のデータを生かすためにどんな方法がよいかを一緒に探る「頼れる相談相手」として活用 されました。「こういう見せ方はどうか」「この分け方だとデータが崩れないか」── ジェンガのピースを崩さないように一つずつ探していくような試行錯誤を、AI と対話しながら繰り返された とのことです。 結果として、 通常であれば外注で数ヶ月・数百万ほどかかるシステムを、非エンジニアの山口様ご自身が数週間で構築 されました。さらに、データ構造を深掘りしていく過程で、 ベンダー側でブラックボックス化していた課題に気づき、改善提案に繋げられた という副次的な効果もあったとのことです。今後は自社に蓄積された売上・在庫データの取り込みや、 Amazon Quick （Amazon QuickSight が進化して生まれた Agentic AI プラットフォーム）の AI チャット機能の活用も検討されています。 お二人から参加者へのアドバイス 最後に、お二人から参加者へのアドバイスをいただきました。 平田様からは、「 まずは現業務を可視化してデータで見られる体制を整えることが第一歩。完璧を目指すのではなく、経営層が現場に対して『小さく試して失敗から学ぶ』ことを許容し、現場の変革を後押しするスタンスが重要 」というメッセージをいただきました。 山口様からは、「 とにかくデジタル上にデータを蓄積することに注力してほしい。デジタルデータは企業の財産になる 」というメッセージ。同じ分量のデータでも、デジタルかアナログかで将来の資産価値が大きく変わる。仮にデータの中身が多少整理されていなくても、AI を活用すれば非エンジニアでも理想的な形に整形できる。 アナログからデジタルへの移行方法自体も、AI に相談してみてほしい 、とお話しいただきました。 写真: タキヒヨー株式会社 平田様・山口様、AWS 小嶋によるパネルディスカッション 経営と現場の両輪で取り組まれたお話に続いて、こうしたデータ活用の取り組みを伴走支援するパートナー様からのセッションです。 パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用のためのデータ収集〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 データ事業本部 チームリーダー / プロジェクトマネージャーの三鴨 勇太 様より、「生成 AI 活用のためのデータ収集」と題したセッションをお届けいただきました。名古屋オフィスを拠点に、お客様のデータ基盤構築やデータ戦略支援を担当されている三鴨様から、データドリブン経営を支えるデータ基盤整備の考え方をお話しいただきました。 データ収集がデータドリブン経営と生成 AI 活用の共通の土台であるという点を特に強調しました。ビジネスの加速のためには、企業が持つデータ資産を生成 AI と組み合わせることで差別化につながる。そのために、属人化している情報があればそれらを効率的にデータ化し、収集していく仕組みが重要だと述べられました。 データ基盤整備の進め方としては、企業文化に合わせて、 Needs （需要があるところからデータ基盤整備を進めていく） と Seeds （できるところからデータ基盤整備を始める） の 2 つのアプローチのどちらを取ることもあり、クラスメソッド様が提供するデータ活用基盤構築・運用サービス、データ活用コンサルティング、データ活用分析研修、生成 AI 総合支援サービスなど様々な支援のあり方を紹介いただきました。 写真: クラスメソッド株式会社 三鴨様によるセッション まとめ セッション後には参加者同士のグループディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。 名古屋でご登壇いただいたタキヒヨー様とクラスメソッド様に共通していたのは、 データをいかに集め、活かせる状態に整えるか という土台の重要性と、 小さい成功体験を少しずつ積み重ねる という進め方のベストプラクティスでした。AI を活用している企業様は、データや周囲の巻き込み方など AI 以外の部分にもプラクティスを持っておられることが伝わるセッションでした。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした名古屋・3 日目に続き、次回は翌日開催の名古屋・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#1/8）開催レポート 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 大阪編（#2/8）開催レポート タキヒヨー、生成 AI を活用し社内業務効率化と 450 時間超の工数削減を実現。Amazon Bedrock を衣服デザイン等に適用、デジタル人材育成を推進 中堅・中小企業でも広がる生成 AI。企業の成長にも貢献 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵