お知らせ 2026年7月からオンラインでサーバーレスに関するワークショップを4件開催します。ぜひ、ご参加ください。 7/7 10:00〜12:00 Kiroによるサーバーレス開発 7/9 10:00〜12:00 イベント駆動アーキテクチャ・アプリケーションの構築 7/14 10:00〜12:00 AWS Lambda durable functions によるコード型ワークフロー 7/16 10:00〜12:00 AWS Lambda マネージドインスタンス 本記事は、2026 年 3 月 30 日に公開された Build high-performance apps with AWS Lambda Managed Instances を翻訳したものです。翻訳は Solutions Architect の 齋藤 拓巳 が担当しました。 最新のサーバーレスイノベーションを把握して、アプリケーションの変革に役立てましょう。 この第 31 回四半期レビューでは、2025 年第 4 四半期に発表された、見逃しているかもしれない AWS サーバーレスの重要なリリース、機能、リソースをご紹介します。 前回の ICYMI を見逃した方は、 2025 年第 3 四半期 の内容をご確認ください。 2025 年第 4 四半期カレンダー re:Invent 2025 におけるサーバーレス この記事では、re:Invent 2025 で発表された主要なサーバーレス関連のアナウンスを取り上げ、アプリケーションの改善に役立つ重要な機能アップデートを紹介するとともに、最新情報を把握するための有用なリソースを共有します。 AWS re:Invent 2025 には 60,000 人以上が現地参加し、基調講演には 200 万人以上のオンライン視聴者が集まりました。 イベントでは 3,000 人のスピーカーによる 3,500 のセッションが開催され、530 の AWS サービスおよび機能のアナウンスに関する情報が紹介されました。 基調講演 サーバーレスムーブメントの火付け役 サーバーレス関連のコンテンツは、Containers and Serverless (CNS) と Application Integration (API) の 2 つのトラックで構成されていました。 これらのトラックでは 150 種類のセッションが開催され、16,000 人を超える参加者が現地で視聴しました。 開発者向けの体験として、 Road to re:Invent Hackathon 、AWS Builder Loft、Builders Arena が用意されていました。 サーバーレステクノロジーで運営されるコーヒーショップ Serverlesspresso は、イベント期間中、Expo Hall と認定資格ラウンジの 2 か所で営業していました。 サーバーレスおよび開発者コミュニティの写真 厳選されたサーバーレス動画のリストは Serverless Land YouTube でご覧いただけます。 AWS Lambda durable functions マルチステップのサーバーレスワークフローにおける状態管理には、従来、複雑な外部オーケストレーションツールが必要でした。 AWS Lambda の durable functions は、開発者が Lambda を活用する方法を拡張します。 信頼性の高いマルチステップのアプリケーションや AI ワークフローを Lambda 内で直接構築できるようになりました。 AWS Lambda durable functions のコード durable functions は、実行中の重要なポイントで現在の状態と完了したステップを保存することで、自動的に進捗のチェックポイントを保存します。 これにより、長時間実行されるタスク中に最大 1 年間実行を一時停止でき、障害が発生した場合も最初からやり直すのではなく最後のチェックポイントから再開して復旧できます。しかも追加のインフラストラクチャ管理は一切不要です。 開発者は Python または TypeScript で構築し、自動リトライとチェックポイント機能を備えたステップで呼び出しをラップできるようになりました。 wait を使用すると、アイドル状態のコンピューティングに課金されることなく、数分、数時間、最大 1 年間まで実行を一時停止できます。 durable functions はリプレイメカニズムを使用して状態を維持し、障害を適切に処理します。 このメカニズムは、障害からの復旧時にチェックポイントから関数コードを再実行することで動作し、データを失うことなく状態の一貫性を確保します。 これにより、多くのユースケースで複雑な外部オーケストレーションツールが不要になります。 外部インフラストラクチャを管理することなく信頼性の高い状態管理が必要な AI ワークフローやマルチステップアプリケーションに特に役立ちます。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画をご覧ください: Deep Dive on AWS Lambda durable functions (CNS380) AWS Lambda Managed Instances Lambda は、 Lambda Managed Instances という新しいコンピューティングオプションを提供開始しました。これは Amazon EC2 の柔軟性とフルマネージドインフラストラクチャを組み合わせたものです。 AWS がインスタンスのプロビジョニング、スケーリング、メンテナンスを自動的に処理しながら、Graviton4、ネットワーク最適化インスタンス、その他の特殊なコンピューティングオプションを含む EC2 の幅広い機能にアクセスできます。 AWS Lambda Managed Instancesの設定 関数は、お客様のアカウントの専用 EC2 キャパシティ上で、お客様自身の Amazon Virtual Private Cloud (Amazon VPC) 内で実行されます。 OS パッチ適用、ロードバランシング、オートスケーリングなどの運用オーバーヘッドは引き続き AWS が管理します。 これにより、サーバーレスの運用モデルを維持しながら、特殊なハードウェアオプションにアクセスできます。 Compute Savings Plans や Reserved Instances などの EC2 料金モデルを Lambda ワークロードに活用することで、コストをさらに最適化できます。 各インスタンスは複数の同時リクエストを処理できるため、予測可能な料金体系と特定のハードウェア要件が重要な、大量かつ定常的なワークロードに特に適しています。 詳細については、 発表ブログ記事 をお読みいただくか、re:Invent ブレイクアウトセッションの動画 Lambda Managed Instances: EC2 Power with Serverless Simplicity (CNS382) をご覧ください。 その他の Lambda に関する発表 マルチテナント SaaS アプリケーションには、テナント間のデータ漏洩や、あるテナントのワークロードが他のテナントに影響を与えるノイジーネイバー問題といった課題があります。 また、カスタムの分離メカニズムの実装にも苦労してきました。 テナント分離モード は、テナントごとに個別の実行環境で関数の呼び出しを処理することで、これらの課題に対処します。 これにより、テナントレベルのコンピューティング環境の分離が自動的に管理されます。 AWS Lambda tenant isolation Lambda は Amazon SQS イベントソースマッピングに Provisioned Mode を追加しました。これにより、高スループットの SQS 処理ワークロードにおいて、予測可能なパフォーマンスとコールドスタートの削減を実現します。 非同期 Lambda 呼び出しで 最大 1 MB のデータを送信 できるようになりました。 従来の 256 KB から引き上げられ、より複雑なデータ処理シナリオの構築が可能になります。 Lambda 関数は IPv6 ネットワーキング をサポートするようになったため、VPC に接続された関数からインターネットや他の AWS サービスにアクセスする際に NAT Gateway が不要になりました。 NAT Gateway を介した Lambda のインターネット接続 (IPv4) と、Egress-Only インターネットゲートウェイを介した Lambda のインターネット接続 (IPv6) です。 Lambda の Rust サポート が一般提供 (GA) になり、実験的ステータスから移行しました。 これは AWS サポートおよび Lambda の可用性 SLA の対象となります。 Lambda は、 Python 3.14 、 Node.js 24 、 Java 25 をマネージドランタイムおよびコンテナベースイメージとして追加し、ランタイムサポートを拡充しました。 これにより、最新の言語機能を利用でき、長期サポートも確保されます。 Amazon ECS Amazon Elastic Container Service (Amazon ECS) Express Mode は、従来開発者の作業を遅らせていたインフラストラクチャのセットアップを自動化することで、コンテナ化されたアプリケーションのデプロイと管理を効率化します。 Amazon ECS Express Mode デプロイメント これにより、AWS のベストプラクティスを活用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。 Express Mode では、単一のコマンドで本番環境対応のコンテナ化された Web アプリケーションと API をデプロイできます。 シンプルな API を通じて、ドメイン、ネットワーキング、ロードバランシング、 AWS Identity and Access Management (IAM) ロール、オートスケーリングが自動的に処理されます。 アプリケーションが進化し、高度な機能が必要になった場合は、Amazon ECS を含むリソースのすべての機能をシームレスに設定してアクセスできます。 詳細については、 発表ブログ記事 をご覧ください。 Amazon ECS は、AI を活用した開発・運用体験を実現するフルマネージド型の MCP サーバー のパブリックプレビューを発表しました。 この Model Context Protocol (MCP) サーバーは、自動更新とパッチ適用、AWS IAM 統合による一元的なセキュリティ管理、 AWS CloudTrail を通じた包括的な監査ログ、そして AWS が実証済みのスケーラビリティ、信頼性、サポートといったエンタープライズグレードの機能を提供します。 Amazon Elastic Container Registry (ECR) の マネージドコンテナイメージ署名 は、セキュリティ体制を強化し、署名のセットアップにかかる運用上のオーバーヘッドを排除します。 コンテナイメージ署名により、イメージが信頼できるソースからのものであることを検証できます。 ECR は、イメージがプッシュされる際に、プッシュしたエンティティの ID を使用して自動的にイメージに署名します。 署名操作は CloudTrail を通じてログに記録されるため、完全な監査が可能です。 Amazon API Gateway Amazon API Gateway では、レスポンスペイロードをクライアントに 段階的にストリーミング することで、REST API の応答性を向上させることができます。 この新機能により、ストリーミングレスポンスを使用して、LLM 駆動のアプリケーション (AI エージェントやチャットボットなど) を構築する際のユーザーエクスペリエンスの向上、Web およびモバイルアプリケーションの Time-to-First-Byte (TTFB) パフォーマンスの改善、大容量ファイルのストリーミング、 Server-Sent Events (SSE) などのプロトコルを使用した増分的な進捗報告を伴う長時間実行オペレーションの実行が可能になります。 Amazon API Gateway streaming API Gateway は、 Application Load Balancer (ALB) との プライベート統合 を導入しました。 これにより、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API を通じて安全に公開できます。 API エンドポイントやカスタムドメイン名に 強化された TLS セキュリティポリシー を設定できるようになり、API のセキュリティ体制をより細かく制御できるようになりました。 Amazon EventBridge Amazon EventBridge に、カスタムアプリケーションや 200 以上の AWS サービスからのイベントを開発者が発見しサブスクライブできる 拡張ビジュアルルールビルダー が導入されました。 このコンソールベースのインターフェースは、EventBridge の スキーマレジストリ と包括的なイベントカタログ、直感的なドラッグアンドドロップキャンバスを統合し、イベント駆動型アプリケーションの構築を簡素化します。 開発者は、個々のサービスのドキュメントを探し回ることなく、すぐに利用可能なサンプルペイロードやスキーマを使ってイベントを閲覧・検索できます。 スキーマ対応のビジュアルビルダーが、イベントフィルターパターンやルールの作成をガイドし、構文エラーを削減して開発時間を短縮します。 EventBridge では、 SQS フェアキュー をターゲットとして指定することもできます。 AWS Step Functions AWS Step Functions では、 TestState API を通じて強化されたローカルテストが可能です。 AWS にデプロイすることなく、包括的なテスト機能にプログラムからアクセスできます。 これにより、開発マシン上でワークフロー定義をローカルに検証する自動テストスイートを構築できます。 お好みのテストフレームワークを使用して、エラーハンドリングパターン、データ変換、モックサービス統合をテストしましょう。 また、新しい メトリクスダッシュボード も追加され、アカウントレベルとステートマシンレベルの両方でワークフローの運用状況を可視化できるようになりました。 その他の発表 Savings Plans の柔軟な料金モデルが、 Database Savings Plans のローンチにより AWS マネージドデータベースサービスにも拡張されました。 1 年間の一定量の使用量 ($/時間) をコミットすることで、データベースコストを最大 35% 削減できます。 割引は毎時間、対象のデータベースサービス全体の適格な使用量に自動的に適用され、コミットメントを超える追加使用量はオンデマンド料金で課金されます。 Amazon DynamoDB が グローバルセカンダリインデックスでの複数属性複合キー をサポートするようになりました。 これまでは値を手動で連結して合成キーを作成する必要があり、新しいインデックスを追加する前にデータのバックフィルが必要になることもありました。 今後は、最大 8 つの既存属性を使用してプライマリキーを作成できるため、多様なアクセスパターンのモデリングや新しいクエリ要件への対応が容易になります。 Amazon Bedrock は、信頼性の高い AI エージェントを大規模にデプロイするための 品質評価とポリシーコントロールを備えた AgentCore を発表しました。 Bedrock には 18 のフルマネージドオープンウェイトモデル も追加され、開発者が利用できる AI モデルの選択肢が拡大しました。 Strands Agents SDK は、モデル駆動型のアプローチで AI エージェントをわずか数行のコードで構築・実行できるオープンソースフレームワークです。 TypeScript のサポートがプレビューとして 利用可能になり 、Strands Agents の構築に Python と TypeScript のどちらかを選択できるようになりました。 Amazon S3 Vectors が一般提供開始となりました。 S3 Vectors は、AI エージェント、推論、検索拡張生成 (RAG)、セマンティック検索を数十億ベクトル規模で実現する、専用設計されたコスト最適化済みのベクトルストレージを提供します。 サーバーレスに関するブログ記事 10 月 モノリスワークフローの分解: AWS Step Functions ワークフローのモジュール化 AWS Serverless MCP Server での AWS Lambda イベントソースマッピングツールの紹介 AWS Step Functions Distributed Map S3 プレフィックスを使用した Amazon S3 オブジェクトの大規模処理 11 月 AWS Lambda の IPv6 ネットワーキング AWS Step Functions Distributed Map によるビッグデータ処理のオーケストレーション AWS Step Functions Distributed Map を使用したネストされた JSON 配列処理の最適化 新しい Amazon API Gateway Portal で API の見つけやすさを向上させる Amazon API Gateway レスポンスストリーミングでレスポンシブな API を構築する AWS Lambda で Python 3.14 ランタイムが利用可能になりました AWS Lambda 上で Rust を使用したサーバーレスアプリケーションの構築 非同期 AWS サービスを AWS Step Functions ステートマシンと統合する際に、予測不能な処理時間を運用の一貫性を保ちながら処理する AWS Lambda が Java 25 をサポートしました Amazon API Gateway TLS セキュリティポリシーによる API セキュリティの強化 Kafka 向けサーバーレスストリーミングワークロードのスループット向上 Amazon API Gateway と Application Load Balancer のプライベート統合を使用してスケーラブルな REST API を構築する LLM レスポンスのストリーミングにおけるサーバーレス戦略 AWS Lambda の新しいテナント分離モードを使用したマルチテナント SaaS アプリケーションの構築 AWS Step Functions と Amazon Bedrock バッチ推論による大規模ドキュメント処理のオーケストレーション AWS Lambda で Node.js 24 ランタイムが利用可能になりました Serverless Office Hours 毎週火曜日の午前 11 時 (太平洋時間) に開催されるライブストリームにぜひご参加ください。サーバーレステクノロジーに関するライブディスカッション、Q&A セッション、深掘りセッションを行っています。 エピソードは serverlessland.com/office-hours でオンデマンドでもご視聴いただけます。 10 月 10 月 7 日 – Amazon API Gateway Routing Rules 10 月 14 日 – Amazon DynamoDB Global Tables 10 月 21 日 – Building agents with Amazon Bedrock AgentCore 10 月 28 日 – What’s new with Observability 11 月 11 月 4 日 – AI 仕様を正しく定義する！ 11 月 11 日 – AWS Lambda で Swift を実行する 11 月 18 日 – EventCatalog の最新情報 11 月 24 日 – pre:Invent 2025 12 月 12 月 9 日 – AWS Lambda Managed Instances 12 月 16 日 – AWS Lambda durable functions さらに詳しく知りたい方へ サーバーレスのランディングページ には、サーバーレスアプリケーションの構築に関する全般的な情報があります。 Lambda リソースページ には、ケーススタディ、ウェビナー、ホワイトペーパー、お客様事例、リファレンスアーキテクチャ、さらに多くの入門チュートリアルが掲載されています。 Serverless Developer Advocacy チームをフォローして、最新ニュースの確認、会話のフォロー、チームとの交流もできます。 Julian Wood: @julian_wood , https://www.linkedin.com/in/julianrwood/ Eric Johnson: @edjgeek , https://www.linkedin.com/in/singledigit/ Gunnar Grosch: @GunnarGrosch , https://se.linkedin.com/in/gunnargrosch Erik Hanchet: @ErikCH , https://www.linkedin.com/in/erikhanchett/ Salih Gueler: @salihgueler , https://www.linkedin.com/in/salihgueler/ Marcia Villalba: @mavi888uy , https://www.linkedin.com/in/marciavillalba 最後に、サーバーレスに関するあらゆる情報については Serverless Land をご覧ください。

本記事は 2026 年 4 月 15 日に Migration & Modernization Blog で公開された AWS Transform: Comprehensive Codebase Analysis for Modernization を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 アプリケーションのモダナイゼーションは、多くの場合、困難なタスクから始まります。それは、システムの仕組みを理解するための包括的なレガシーコードベース分析です。多くのレガシーアプリケーションは長年にわたる段階的な変更を経て進化しており、ドキュメントは限られ、依存関係は密結合し、ビジネスロジックは複数のサービスやモジュールに分散しています。エンジニアリングチームにとって、この可視性の欠如は共通の課題を生み出します。モダナイゼーションを開始する前に、開発者はソースコードを確認してアプリケーションアーキテクチャ、動作パターン、隠れた依存関係を理解するための時間を費やす必要があります。この作業を行っても、サービス間の依存関係、アーキテクチャ上の制約、埋め込まれたビジネスルールなどの重要な知見は、変更がより複雑でコストがかかるプロジェクトの後半で明らかになることがよくあります。 AWS Transform の包括的コードベース分析マネージド変換は、アプリケーションの明確でエビデンスに基づいた理解を提供することで、これらの課題に対処します。これにより、数か月分の手作業を節約し、モダナイゼーションへの取り組みを加速できます。この記事では、変換の仕組み、前提条件、実行手順、実践的なシナリオを含めた結果の解釈方法、より広範なモダナイゼーションの取り組みとの関係、ベストプラクティス、トラブルシューティングガイダンスについて説明します。この記事を読み終えた頃には、ドキュメントが不十分なレガシーコードベースを構造化されたナビゲーション可能なナレッジベースに変換するための再現可能なアプローチを習得できるでしょう。 AWS Transform の包括的コードベース分析の仕組み この変換は、静的コード解析に基づいて動作します。決定論的ツール、基盤モデル（FM）、大規模言語モデル（LLM）、グラフニューラルネットワーク、自動推論を組み合わせて、アプリケーションコードベースの 4 つの重要な側面を分析します。 システム全体のコンポーネントの関係と依存関係 コードがどのように機能するかを明らかにする動作パターン 実装に埋め込まれたアーキテクチャ上の決定 ステークホルダーとのコミュニケーションのために平易な言葉で抽出されたビジネスロジック この多層的な分析により、技術チームとビジネスリーダーの両方が、実装中に問題が発生する前に十分な情報に基づいたモダナイゼーションの意思決定を行うのに役立つ構造化されたドキュメントが生成されます。 前提条件 開始する前に、以下を確認してください。 AWS Transform コマンドラインインターフェース （CLI）がインストールされていること: 詳細は スタートガイド を参照。 AWS 認証情報が設定されていること: 適切な権限で AWS CLI をセットアップし、AWS 認証情報に AWS Transform サービスを呼び出す権限があることを こちら で確認。最低限、 transform-custom: * の権限が必要。 クリーンな状態の読み取り可能なファイルを含む Git ソースコードリポジトリを準備すること: コミットされていない変更はコミットまたはスタッシュ。 推定所要時間: 30〜45 分（分析の実行時間を除く。実行時間はコードベースのサイズによって異なります） ステップバイステップガイド: 包括的コードベース分析の実行 以下の手順では、レガシーアプリケーションに対して AWS Transform の包括的コードベース分析を実行し、主要なステークホルダーと結果を共有し、インサイトに基づいて行動するまでの完全なプロセスを説明します。 ステップ 1: 環境の確認 AWS Transform が正しくインストールおよび設定されていることを確認します。 atx -version atx custom def list 上記のコマンドは、 AWS/early-access-comprehensive-codebase-analysis などの利用可能な AWS Transform マネージド変換を表示します。 注: 早期アクセス変換 (early-access-*) は機能しますが、お客様のフィードバックに基づいて頻繁に更新される可能性があります。時間が経つと、変換の名前が「AWS/comprehensive-codebase-analysis」として一覧に表示されるようになります。 図 1: AWS マネージド変換のリストで包括的コードベース分析変換が利用可能であることを確認 ステップ 2: コードベースの準備 Git リポジトリがクリーンな状態であることを確認します。 git status 図 2: 分析を実行する前に Git リポジトリがクリーンな状態であることを確認 既存のソースコードリポジトリをクローンします。 git clone <repository-url> 図 3: 包括的分析のためにレガシーコードベースリポジトリをクローン ステップ 3: ターミナルで以下のコマンドを実行 AWS Transform を使用して包括的分析を開始します。これにより、リポジトリ内のすべてのファイルと依存関係に対して深い静的解析が実行されます。 cd /path/to/your/project atx custom def exec -p /path/to/your/repository -n AWS/early-access-comprehensive-codebase-analysis -c "noop" -x -t 注: -n は変換名を指定します -c "noop" – ビルドコマンド（no operation – ビルドステップをスキップ） -x – 確認プロンプトなしでツールを自動信頼/実行 -t – インタラクティブターミナルモードを有効化 図 4: AWS Transform CLI を使用して包括的コードベース分析変換を実行 ステップ 4: 追加コンテキストの提供（オプション） よりターゲットを絞った分析を行うために、設定ファイルを使用して追加のガイダンスを提供できます。 transform-config.yaml という名前のファイルを作成します。 cat > transform-config.yaml << 'EOF' codeRepositoryPath: /Users/milola/Prince-of-Persia-Apple-II transformationName: AWS/early-access-comprehensive-codebase-analysis buildCommand: noop additionalPlanContext: | Focus analysis on the following areas: - Document the overall architecture and code structure - Identify deprecated or outdated coding patterns - Highlight areas that may benefit from modernization - Analyze dependencies and their relationships EOF カスタム設定ファイルを実行します。 atx custom def exec -g file://transform-config.yaml -x -t 図 5: YAML 設定ファイルを使用して追加コンテキスト付きで分析を実行 ステップ 5: 分析のモニタリング 処理が進むにつれて、階層的なドキュメント構造にまとめられた分析結果、優先度付けされた技術的負債のインサイト、簡単にナビゲートできる相互参照されたナレッジベースが提供されます。コードベースのサイズと複雑さに応じて、完全なプロセスには通常 45 分から 2 時間以上かかります。 ステップ 6: 結果の確認 分析が完了すると、4 つの領域にわたって整理された包括的なドキュメントセットが表示されます。 技術的負債レポート: 古くなったコンポーネントの優先度付きビュー、重大度別にランク付けされたセキュリティの問題、長期的な影響について評価されたメンテナンスの懸念事項。 アーキテクチャドキュメント: コンポーネントの依存関係グラフ、サービスの相互作用パターン、データフロー図を含むシステム全体の概要。 ビジネスロジックの抽出: 複雑なプロセスのわかりやすい言葉での説明。主要なビジネスルール、バリデーションロジック、外部統合ポイントを浮き彫りにします。 コード分析: コードベースのファイルごとの内訳。複雑度メトリクス、コード品質の指標、具体的なリファクタリングの機会を提示します。 以下は、プロジェクト概要、技術的負債レポート、コード分析出力、システムアーキテクチャ概要のスクリーンショットです。 プロジェクト概要: 図 6: ビジネスコンテキストと技術的成果を含む、包括的コードベース分析によって生成されたプロジェクト概要ドキュメント 技術的負債レポート: 図 7: プラットフォームの陳腐化やハードウェア依存関係を含む、重大度別に優先度付けされた重要な問題を強調する技術的負債レポート コード分析: 図 8: 複雑度、保守性の指標、品質評価を示すコード分析メトリクス システムアーキテクチャ概要: 図 9: モジュール性と結合度の具体的な評価を含む、システムの強みと弱みを示すアーキテクチャドキュメント ステップ 7: ナレッジベースのナビゲーション 生成されたドキュメントは、ハイレベルなレビューと詳細な調査の両方をサポートするように構造化されています。 ルートレベルでは、エグゼクティブサマリーが最も重要な技術的負債の分析結果とともに表示され、即座に注意を要するインサイトが明らかになります。さらに掘り下げると、ドメインレベルでは関連するコンポーネントが論理的なクラスターにグループ化され、コンポーネントレベルでは個々のモジュールの詳細な分析が提供されます。 ドキュメント全体を通じて、相互参照が関連するコンポーネントと依存関係を接続し、チームがコンテキストを失うことなくシステム全体の関係を追跡しやすくなります。 トップから始めて、モダナイゼーションの優先事項に最も関連する領域を分析してください。 ステップ 8: エクスポートと共有 各グループが受け取る内容を、それぞれの責任と意思決定のニーズに基づいてカスタマイズします。このターゲットを絞ったアプローチにより、各チームはモダナイゼーションの取り組みにおける自分たちの役割に最も関連するインサイトに基づいて即座に行動できます。 まず、エンジニアリングチームに技術的負債レポートを提示してください。これにより、モダナイゼーション中に遭遇するリファクタリングの優先順位とアーキテクチャ上の制約が把握できます。 アーキテクチャチームは、ターゲット状態の計画と慎重な検討が必要な統合ポイントの特定に、システム全体のドキュメントが非常に有用であると感じるでしょう。 ビジネスステークホルダーは、わかりやすい言葉でのビジネスロジック抽出から大きな恩恵を受けます。これにより、変換中に重要なワークフローとルールが保持されていることを検証できます。 セキュリティチームも、依存関係の分析とアーキテクチャのインサイトを確認して、モダナイゼーションプロセスの早い段階でセキュリティに関する考慮事項を特定できます。 ステップ 9: インサイトに基づいた行動 出力は、それに基づいて何を行うかによってのみ価値が決まります。短期的には、関連するセキュリティの問題への対処、優先度の高い技術的負債の正式なドキュメント化、今後のスプリント計画への分析結果の組み込みに注力してください。戦略的には、アーキテクチャのインサイトがモノリシックシステムの分解の決定に情報を提供し、依存関係の分析に基づいてモダナイゼーションの各フェーズの実施順序を決定します。技術的負債データは、測定可能なリスクと影響に基づいた説得力のあるビジネスケースを構築するための基盤を提供します。 実践的なシナリオ 数十年の歴史を持ち、ドキュメントが最小限で、理解できる開発者が限られているモノリシックアプリケーションを引き継いだとします。そして、ビジネスステークホルダーは数か月ではなく数週間以内にモダナイゼーションのタイムラインを必要としています。包括的コードベース分析は、そうでなければ広範な手作業を必要とするディスカバリーフェーズを加速し、数週間ではなく数時間で実行可能な結果を提供します。コンポーネントの相互作用を示す完全な依存関係グラフを生成し、リスクと影響で優先度付けされた技術的負債のホットスポットを特定し、技術とビジネスの理解を橋渡しするビジネスロジックを抽出し、分解戦略に情報を提供するアーキテクチャのインサイトを提供します。この基盤により、特定のコンポーネントをリファクタリングするか、リプラットフォームするか、置き換えるかについて十分な情報に基づいた意思決定が可能になり、推測ではなくエビデンスに裏付けられた現実的なモダナイゼーションタイムラインをビジネスステークホルダーに提供できます。 より広範なモダナイゼーションの取り組みとの関係 包括的コードベース分析は、単独ではなく、より広範なモダナイゼーション機能と連携して動作するように設計されています。生成されるインサイトは、モダナイゼーションジャーニー全体を通じて使用できます。分解の計画では、インサイトが実際の依存関係とアーキテクチャの境界に基づいてモノリシックアプリケーションを管理可能なドメインに分解する方法の理解を提供します。技術的負債の分析は、リスク、影響、ビジネス価値に基づいた順序付きの作業を確保し、モダナイゼーションの各フェーズの優先順位を決定します。詳細なコンポーネント分析は、システムのどの部分が変換の候補であり、どの部分が完全な置き換えの候補であるかを示すことで、リファクタリングの決定を明確にします。ビジネスステークホルダーにとっては、抽出されたビジネスロジックがモダナイゼーション投資のビジネスケースを構築するために必要なナラティブを提供します。これを、後続のすべてのステップをより意図的でより良い情報に基づいたものにする基盤と考えてください。 ベストプラクティス 変換を実行する前に、結果に影響を与える可能性のある既知の問題や制限事項を文書化し、注力すべき特定の懸念領域を特定してください。 変換をターゲットを絞ったインサイトに導くために明確な追加コンテキストを提供し、出力を充実させることができる関連するアーキテクチャ図やドキュメントを含めてください。 分析が完了したら、チームとして技術的負債の分析結果をレビューし、技術的な重大度だけでなくビジネスへの影響に基づいて修正の優先順位を決定してください。 インサイトをスプリント計画と長期的なロードマップに活用し、技術者と非技術者の両方のステークホルダーとドキュメントを共有して、全員がシステムの全体像を理解できるようにしてください。 トラブルシューティング 結果に具体的なインサイトが不足している場合 出力が一般的すぎると感じる場合、最も効果的な修正方法は、エージェントにより明確な方向性を与える additionalPlanContext を通じてより詳細なコンテキストを提供することです。認証、決済処理、特定のサービスレイヤーなど、最も関心のある注力領域やドメインを指定し、エージェントがよりターゲットを絞った分析結果を生成できるように、既存のアーキテクチャドキュメントや図を参考資料として含めることを検討してください。 分析が完了しない場合 分析が完了できない場合は、エージェントが自力で解決できない可能性のある依存関係や設定ファイルの欠落を確認し、プロセスに干渉する可能性のあるコミットされていない変更がない、クリーンな状態の Git リポジトリであることを確認してください。大規模または複雑なコードベースの場合は、エージェントをガイドするために焦点を絞った additionalPlanContext を提供してください。 ドキュメントが広範すぎる場合 生成されたドキュメントが必要以上に広い範囲をカバーしている場合は、 additionalPlanContext でモジュールやドメインを指定してスコープを絞ってください。また、リポジトリ全体ではなく特定のサブディレクトリに対して分析を実行することもできます。これにより、システム全体の出力を確認する必要なく、最も重要な領域に焦点を当てた実行可能なインサイトを得ることができます。 まとめと次のステップ コードベースを理解することは、モダナイゼーション成功の基盤です。AWS Transform の包括的コードベース分析は、数か月の手動ドキュメント作成を数時間の AI によるインサイト生成に変換します。これにより、コードを変更する前に十分な情報に基づいた意思決定を行うための明確さが得られます。この基盤があれば、リアクティブではなく戦略的にモダナイズでき、レガシーアプリケーションをビジネスを推進するスケーラブルで保守可能なシステムに変えることができます。 次のステップとして、パイロットモダナイゼーションプロジェクトから始めてください。以下の追加リソースを確認し、レガシーコードベースに対して包括的コードベース分析を実行してください。アーキテクチャのインサイトを分解の計画に活用し、技術的負債の分析結果に基づいてモダナイゼーションの各フェーズの優先順位を決定し、抽出されたビジネスロジックをステークホルダーと共有してアラインメントを構築してください。定期的に再実行して進捗を追跡し、モダナイゼーションの取り組みが計画した成果を達成していることを検証できます。 追加リソース AWS Transform custom Documentation AWS Comprehensive Codebase Analysis Getting Started with AWS Transform Quotas for AWS Transform Ask questions on re:Post 著者について Damilola Odeleye Damilola Odeleye は、Amazon Web Services (AWS) のシニアテクニカルアカウントマネージャーです。エンタープライズ組織と連携し、クラウドのモダナイゼーションを加速させ、ビジネスに大きなインパクトをもたらす成果を推進しています。モダナイゼーションと AI/ML の両分野を専門とし、テクノロジーを長期的なビジネス成長と整合させることに注力しています。 Srinivas Ganapathi Srinivas Ganapathi は、Amazon Web Services のプリンシパルテクニカルアカウントマネージャーです。カナダのトロントを拠点とし、ゲーム業界のお客様と協力して、AWS 上で効率的にワークロードを実行できるよう支援しています。

本記事は 2026 年 4 月 26 日に AWS DevOps & Developer Productivity Blog で公開された AWS Transform custom: Enterprise Code Modernization with the Learn-Scale-Improve Flywheel を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 エンタープライズにおけるモダナイゼーションは、大きな転換点を迎えています。1 つのリポジトリを変換するだけなら容易です。 AWS Transform custom でも、他の既存のツールでも、個別のリポジトリに対して十分に機能し、プロセスも確立されています。しかし、50 のリポジトリではどうでしょうか。100、200 ではどうでしょうか。エンタープライズ規模でモダナイゼーションを進めようとすると、コードを変換することは課題全体の一部にすぎません。人員の調整、ナレッジの蓄積、そしてポートフォリオ全体における品質の維持も重要になります。 本記事では、AWS Transform custom の 大規模な自動化の仕組み が、インテリジェントな学習とスケール実行によって、エンタープライズにおける組織内連携の課題をどう解決するかをご紹介します。あるお客様は、モダナイゼーション全体の期間を 7-12 週間から 2.5 週間へと短縮し、デリバリー期間を 3-5 分の 1 に、総工数を 10-20 分の 1 に削減しました。そして何より、ご自身のモダナイゼーションの取り組みを今すぐ始めるための方法をお伝えします。 エンタープライズ規模における組織内連携の課題 エンタープライズのアーキテクトに直近の大規模モダナイゼーションについて尋ねると、きまって同じような話を耳にします。例えば、あるエンタープライズソフトウェア企業では、大規模なレガシーコードベースをモダンなプラットフォームへ移行する必要がありました。当初の見積りは、複数チームにまたがる調整作業を含めて 12 週間の集中的な作業でした。 コード変換そのものは数日で完了しました。しかし残りの数週間は、コード変換を取り巻く一連の作業に費やされました。具体的には、タイムゾーンをまたぐチームの調整、異なる経緯を持つコードベース間でのパターンの一貫性の確保、そして上流の変更が下流のシステムを壊さないよう依存関係を管理することです。各チームはミーティングやスプレッドシートでステータスを追跡し、シニア開発者の頭の中にしか存在しない暗黙知に頼っていました。 これがエンタープライズにおける組織内連携の課題です。1 つのリポジトリから数百のリポジトリへとスケールするとき、連携のオーバーヘッドは爆発的に増大します。リポジトリが 1 つ増えるごとに、そのリポジトリ自身の複雑さだけでなく、新たな連携箇所、エッジケース、そして想定外の調整要件が加わるのです。 見落とされがちな 70% のギャップ エンタープライズの案件において、私たちはコード変換がモダナイゼーション作業全体の約 30% にすぎないことを確認してきました。残りの 70% には、テスト生成、検証、包括的なドキュメント作成、ビジネス分析、そして数百の作業項目にまたがる組織的な調整などが含まれます。 このギャップこそが、変換ツールによる生産性向上がなかなか実を結ばない理由です。ツールがコードの変更は処理できても、組織は連携、検証、ナレッジの蓄積に依然として苦労しています。変換作業は迅速に終わるのに、プロジェクト全体は数か月を要するという状況です。 実際に私たちが目にしてきたのは、従来のアプローチがエンタープライズ規模で機能しないという事実です。各リポジトリを独立した課題として扱ってしまうからです。チームはコードベース間で同じ作業を繰り返し、一貫性のない判断を下し、開発者が別のプロジェクトへ異動するたびに学びを失っていきます。組織のナレッジは再利用可能な資産とならず、個人の頭の中に閉じ込められたままです。 エンタープライズモダナイゼーションへの新しいアプローチ AWS Transform custom は、エンタープライズモダナイゼーションに対して異なるアプローチをとります。同じ操作を何百回も繰り返すのではなく、すべての実行から学習し、そこで得た知見を次の変換の改善に活用します。 Learn-Scale-Improve フライホイール この Learn-Scale-Improve（学習・スケール・改善）フライホイール のワークフローは、リスクを最小化しつつ学習効果を最大化するよう綿密に設計されたステップで進みます。まず小規模な Learn (学習) パイロットから始め、一括自動化を通じて Scale (スケール) し、計画的なレビューによって Improve (改善) する。このサイクルを繰り返すフライホイールによって、イテレーションのたびに前回よりも良い結果を生み出します (図 1)。 図 1: AWS Transform custom の変換ワークフローにおける Learn-Scale-Improve フライホイール Learn (学習) : 代表的な 2-3 個のリポジトリを対象に、インタラクティブモードで変換を実行するところから始めます。AI エージェントと直接やり取りしながら、各ステップでの判断にフィードバックを提供し、品質を検証します。エージェントが曖昧な箇所に遭遇すると質問を投げかけ、お客様がガイダンスを与えると、システムがそのコンテキストを記録します。パイロットの最後には、蓄積されたフィードバックを確認して変換定義を修正します。その結果として得られるのは、お客様の組織のナレッジが組み込まれた、スケール実行の準備が整った変換定義です。 Scale (スケール) : 次に、自律モードへ切り替えて一括実行を行います。システムは数十、数百のリポジトリを一晩で、手動介入なしに処理し、パイロットで学習したパターンを適用します。ビルドコマンドやテストコマンドを使用して変換結果を検証し、ポートフォリオ全体の進捗状況をリアルタイムで追跡します。これまで数週間のチーム調整を要していた作業が、一晩で完了します。実行中、システムは新しいエッジケース、想定外のパターン、パイロットでは見えてこなかった最適化の機会などを発見事項として記録します。 Improve (改善) : 一括実行のラウンドが終わるごとに、処理中にシステムが記録したナレッジアイテムをレビューします。これらの発見事項は、パイロットではカバーできなかったリポジトリ特有のパターンやエッジケースを浮き彫りにします。その中から価値のある学びを承認することで、次のイテレーションに向けて変換定義が改善されます。このレビューステップが品質管理の役割を担います。システムは自己改変せず、どの学びを取り込むかを決めるのは、変換定義のオーナーです。 Scale と Improve のサイクルは繰り返されます。一括実行のラウンドごとに得られたインサイトが、次のラウンドをさらに効果的にします。変換の成功率は向上し、手動介入は減少し、エッジケースのハンドリングもイテレーションを重ねるたびに改善されます。 このフライホイールは、エンタープライズが組織としてナレッジをどう蓄積し共有するかを大きく変えます。変換定義は単なる自動化スクリプトではありません。特定のモダナイゼーションシナリオに対して、自社がどう取り組むかを体系化した組織資産です。アーキテクトが変換戦略を定義すると、その戦略は再利用可能な定義としてレジストリに保存されます。チームがベストプラクティスを特定すると、それらは変換定義の中に埋め込まれ、すべてのリポジトリに自動的に適用されるようになります。従来であれば、シニア開発者がチームを離れれば、そのナレッジも一緒に消えてしまっていました。AWS Transform custom を利用すれば、その専門知識を変換定義やナレッジアイテムとして蓄積し、組織全体で使える形にできます。個人の専門性が、組織のケイパビリティへと昇華するのです。 エンタープライズのお客様によるモダナイゼーション事例 これらの生産性向上は理論上の予測ではなく、実際の本番環境での成果です。あるエンタープライズソフトウェア企業では、本番環境で稼働する大量の Control-M（訳註: BMC Software 社のワークロード自動化プラットフォーム）のワークフローを Apache Airflow へ移行する必要がありました。このモダナイゼーションには、技術的な精密さと、複雑かつ相互依存するコードベース全体における一貫性の両方が求められました。当初の見積りでは、複数チームでの集中的な調整に 12 週間を要するとされ、一貫性の欠如や統合失敗のリスクも抱えていました。 この企業は、 AWS Transform custom を活用して Learn-Scale-Improve のイテレーション型ワークフローを実行しました。パイロットフェーズでは、代表的なリポジトリに対してインタラクティブモードでの変換を実行し、結果をレビューしたうえで変換定義を洗練させました。イテレーションを重ねるごとに、変換定義はエッジケースへの対応精度を高めていきました。その後、自律モードの一括実行へと移行し、ポートフォリオ全体の移行を 2.5 週間で完了しました。 検証の結果、対象となったすべてのワークフローで 100% の成功率を達成しました。エッジケースのハンドリングは従来のアプローチと比べて 60% 改善し、変換後のコードは業界の専門家が求めるコード品質基準を満たしながら、実行時のパフォーマンスも 19% 向上しました。この事例は、移行のスピードと本番品質の両立が可能であることを示しました。従来のアプローチと比較して、デリバリー期間を 3-5 分の 1 に、総工数は 10-20 分の 1 に削減しました。 ポートフォリオ全体の変換を始めましょう AWS Transform custom の大規模な自動化の仕組みは、 GitHub リポジトリ でソリューションとして提供されています。Learn-Scale-Improve ワークフローに沿って、モダナイゼーションの取り組みを始めてみてください。 前提条件 開始前に、以下をご確認ください。 AWS Transform custom へのアクセスが有効化された AWS アカウント 適切な認証情報で構成された AWS CLI ローカルマシンまたは CI/CD 環境にインストールされた Git AWS Transform custom の操作に必要な IAM 権限 実装の進め方 AWS Transform custom は、 Java のアップグレード (例: 8 から 17、17 から 21)、Python の移行 (例: 3.7 から 3.11)、Node.js のアップデート (例: 14 から 20)、AWS SDK の移行 (例: boto2 から boto3、SDK v1 から v2) など、多様な変換 をサポートしています。これらの AWS マネージドな変換に加えて、組織固有の標準、独自のフレームワーク移行、各環境特有のアーキテクチャパターンに対応するカスタム変換定義を作成することもできます。 AWS Transform custom は、既存の開発プロセスに自然に統合できます。CLI は Jenkins、GitLab CI、GitHub Actions といった CI/CD パイプラインと連携します。変換結果はローカルの Git ブランチとして生成され、お客様の標準的なコードレビュー・マージプロセスに沿って流れていきます。Web インターフェイスでは、チーム横断での進捗状況を一元的に可視化できます。検証コマンドは変換処理中に自動的に実行され、変更が完了したと見なされる前にコードが正常にビルドされ、テストが通過していることを保証します。変換処理の終了時に検証条件を満たさない場合、その変換は失敗として扱われます。 スケール実行までの道のりを加速するため、AWS は本番環境で利用できるスタート地点となるオープンソースのサンプルリポジトリを提供しています。複数のリポジトリと変換定義に対して同時に変換を実行するためのものです。 aws-transform-custom-samples の scaled-execution リポジトリには、一括実行をオーケストレーションするスクリプト、リポジトリのキューイングを管理する仕組み、ポートフォリオ全体のステータス追跡を扱うスクリプトが含まれています。オーケストレーションをゼロから構築するのではなく、サンプルをクローンし、ご自身のリポジトリリストと変換定義で設定すれば、すぐにスケール変換の実行を始められます。 まとめ エンタープライズ規模でのモダナイゼーションには、コード変換ツール以上のものが必要です。本当の課題は、チーム間の連携、実行からの学習、そしてナレッジを組織資産として蓄積することにあります。AWS Transform custom の Learn-Scale-Improve ワークフローは、これらの課題に対して、実行のたびに品質を高める継続的学習、暗黙知を再利用可能な資産へと変える組織ナレッジの捕捉、そして数百のリポジトリに一貫して適用できる一括自動化で応えます。次に重大なセキュリティ脆弱性が発見され、リポジトリ全体のフレームワーク更新が必要になったときも、新しいランタイムのバージョンでパフォーマンスを改善できるようになったときも、すでに効果を検証済みの変換定義を使って、数か月ではなく数日単位で対応できるようになります。 実際のお客様は、デリバリー期間を 3-5 分の 1、総工数を 10-20 分の 1 に削減し、モダナイゼーションを数か月から数週間に圧縮しています。これは願望ではなく、AWS Transform custom を活用している組織が本番環境で実現している成果です。 今すぐ変換を始めましょう まずは 2-3 個の代表的なリポジトリを対象に Learn-Scale-Improve ワークフローを実施し、変換定義を洗練させたうえで、ポートフォリオ全体へと展開してください。 AWS Transform custom の大規模な自動化の仕組みをさらに深く知るには、以下のリソースをご覧ください。 AWS Transform custom ドキュメント : 全機能、API リファレンス、統合ガイドを網羅した技術ドキュメント: AWS Transform custom Scaled Execution サンプルリポジトリ : 複数のリポジトリと変換定義に対して変換を実行するためのオープンソーススクリプト: aws-transform-custom-samples Transformation Registry : AWS マネージドな変換の発見と、カスタム定義の作成: aws-transform-custom-samples 取り組みを開始するには、AWS アカウントチームにお問い合わせいただくか、AWS Transform custom のドキュメントをご参照ください。 著者について Meghan Kothari Meghan Kothari は、Customer Experience and Business Trends チームのシニアテクニカルプロダクトマネージャーです。AWS のリーダーシップと連携し、Agentic AI を活用したアプリケーション開発とモダナイゼーションにおける進化するトレンドを発見するための戦略的な Deep Dive に取り組んでいます。ソリューションアーキテクトおよびフルスタック開発者としての経歴により、開発者体験の形成に貢献する独自の実践的な視点を持っています。 Venugopalan Vasudevan Venugopalan Vasudevan (Venu) は、AWS のプリンシパルスペシャリストソリューションアーキテクトであり、AWS Transform に焦点を当てた Agentic AI の取り組みを主導しています。お客様が AI を活用した開発者向けソリューションおよびモダナイゼーションソリューションを採用しスケールさせ、イノベーションとビジネス成果を加速できるよう支援しています。 Rodney Grilli Rodney Grilli は、AWS のプリンシパルテクノロジストであり、Agentic AI サービスを活用した製品およびコードのモダナイゼーションを専門としています。お客様が製品ポートフォリオをモダナイズし、AI-Native Enterprise への変革を加速できるソリューションを構築しています。

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 合同会社 ソリューションアーキテクト　田中 里絵