Amazon Web Services ブログ

Amazon Connect Customer とは？エージェンティック AI ソリューションの最新アップデート – 2026 年 5月

Hiroyoshi Umeda — Mon, 15 Jun 2026 02:27:28 +0000

こんにちは、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 によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築などコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

セガサミーホールディングスがオンプレミスの Oracle Database を Amazon RDS for Oracle に移行し、性能と運用効率を大幅改善

Yoshio Uchiyama — Mon, 15 Jun 2026 02:01:15 +0000

セガサミーホールディングス株式会社は、エンタテインメントコンテンツ事業、遊技機事業、ゲーミング事業の 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 2026 Supply Chainブースのご紹介

Nobuhiko Kawai — Mon, 15 Jun 2026 00:50:08 +0000

みなさんこんにちは！関西で製造業のお客様を中心に技術支援をしているソリューションアーキテクトの河井です。今年も 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 に入社し、エンタープライズ技術本部でソリューションアーキテクトとして活動中。関西の製造業のお客様を中心担当している。趣味はサッカーとフットサル。

第 7 回 AWS ジャパン生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】

Yoko Tsukamoto — Mon, 15 Jun 2026 00:01:35 +0000

アマゾンウェブサービスジャパン（以下、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 活用を後押しし、その実用化と発展に貢献してまいります。

経済産業省 GENIAC 基盤モデル開発支援事業 (第4期) における採択事業者への支援を開始

Yoshitaka Haribara — Fri, 12 Jun 2026 09:09:27 +0000

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 基盤モデル開発力の向上に貢献できれば幸いです。

Oracle から Amazon Aurora DSQL へのデータ移行

Kenta Nagasue — Fri, 12 Jun 2026 08:55:44 +0000

本記事は 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 をご覧ください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート

Rie Tanaka — Fri, 12 Jun 2026 04:38:33 +0000

こんにちは。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 メンバーまでお気軽にお声がけください。

執筆者

Amazon Web Services Japan 合同会社ソリューションアーキテクト　田中里絵

フィジカルAIで創薬が変わる Self-Driving Labのご紹介 | AWS Summit 2026 Healthcare & Life Sciences ブース

Toshiki Kameda — Fri, 12 Jun 2026 01:57:49 +0000

国内最大規模の学習型 IT カンファレンスである AWS Summit Japan が、2026 年 6 月 25 日（木）・26 日（金）の二日間にわたり幕張メッセで開催されます。今年のサミットではエージェンティック AI と Physical AI（フィジカル AI）が大きなテーマとして掲げられており、AI Agent が自律的にタスクを遂行するだけでなく、現実世界のモノを動かす技術に注目が集まっています。ヘルスケア・ライフサイエンス（ HCLS ）ブースでは、昨年に続き（開催報告はこちら）、今年も多彩なデモを展示予定です。

本記事では、その中から AWS 上の AI Scientist（ AI 科学者）が実験用ロボットを直接操作し、自律的に科学実験を遂行する Self-Driving Lab デモをご紹介します。

創薬研究と DMTA サイクル

ライフサイエンス研究、特に創薬研究では DMTA サイクル（ Design–Make–Test–Analyze ）と呼ばれる反復プロセスが広く用いられています。研究者は候補となる化合物や実験条件を設計（ Design ）し、それを実際に合成・作製（ Make ）し、得られたサンプルを測定・評価（ Test ）し、その結果を分析（ Analyze ）して次のサイクルへフィードバックする ― このループを何度も回しながら、最適な化合物や条件を探索していきます。しかし、各ステップには専門的な判断と手作業が伴います。サイクルを回す速度と、同時に探索できる範囲が、研究の進捗を左右する大きなボトルネックです。

AI Agent が変える研究のかたち ” Self-Driving Lab ” ― Dry から Wet へ

近年、 AI Agent は研究の世界に急速に浸透しつつあります。 DMTA サイクルにおける Design（設計）や Analyze（分析）のような Dry（計算・情報処理）のプロセス ― すなわちコンピュータ上で完結する In Silico の領域 ― では、最新の基盤モデルを活用した AI Agent が研究者レベルの分析・推論を行えるようになってきました。一方で、 Make（合成）や Test（評価）のような Wet（実験）のプロセスは物理的な操作を伴います。コンピュータの中に閉じた AI Agent だけでは、このステップを自律的に実行することはできませんでした。ここに Physical AI ― AI が実世界の装置やロボットを直接制御する技術 ― を組み合わせることで、はじめて DMTA サイクル全体を AI が回しきることが可能になります。

もし AI が DMTA サイクルのすべてのステップ ― Dry も Wet も ― を自律的に実行できたら、何が起こるでしょうか。 AI が仮説を立て、実験を設計し、ロボットに指示を出して実際にサンプルを作り、測定結果を解析し、次の実験を自分で決める。このループを AI が完全に閉じることができれば、人間の介在なしに実験を 24 時間回し続けることが可能になります。これが Self-Driving Lab（自律実験室）のコンセプトです。Self-Driving Lab が実現することで、探索の範囲を一気にスケールアウトでき、従来であれば研究者が数週間かけて到達する結論に、はるかに短い時間で辿り着ける可能性があります。

ラボ自動化の壁を AI が乗り越える

ラボの自動化装置自体は以前から存在しています。しかし、こうした装置を動かすには実験ごとに専用のプロトコル（メソッド）を作成する必要があり、実験のたびに条件が変わる研究の現場では「プロトコルを毎回書き直す学習コスト・構築コストが重い」という壁がありました。結局、手作業のほうが早いと判断されてしまうケースが少なくありません。

AI Agent がプロトコル設計やバリデーションを自律的に行えるようになると、この状況は大きく変わります。今回のデモのようにループを完全に閉じる Self-Driving Lab だけでなく、研究者と AI が協調しながらプロトコルを半自動的に生成・検証するだけでも、 Wet 研究を大幅に加速できます。自動化装置の真のポテンシャルを引き出す鍵が、 AI Agent にあると言えるでしょう。

デモ紹介：AI Scientist ― フィジカル AI が実現する眠らないラボ

今年の HCLS ブースでは、 Self-Driving Lab のコンセプトを体感いただけるライブデモを展示します。シナリオはシンプルです。 3 種類の異なる色の原液（ A / B / C ）をランダムな比率で混合した「秘密サンプル」を用意します。 AI Scientist は、この秘密サンプルの配合比率を、実際にロボットを操作しながら自律的に突き止めます。

具体的な流れを見てみましょう。

まず AI は秘密サンプルの吸光度スペクトル（光の吸収度合いを波長ごとに測定したデータ）を取得し、ターゲットとなる測定値を把握します。
次に、配合比率に関する仮説を立て、それを検証するための実験パターンを設計します。
設計が決まると、 AI は自動分注装置（ Tecan Fluent ）に対して分注指示を送り、配合候補のサンプルを実際に作製します。
作製したサンプルの測定データをターゲットと比較・分析し、差異が大きい部分に注目して次に試すべき配合を決定します。
このサイクルを数回繰り返すうちに推定精度が上がり、最終的には正しい配合比率に到達します。

色水という身近な題材ではありますが、 AI が「考えて、試して、学んで、また試す」という科学研究の本質的なプロセスを自律的に実行する様子を目の前でご覧いただけます。 Dry のプロセス（仮説生成・実験設計・データ分析）と Wet のプロセス（ロボットによる分注・測定）の両方を AI が担い、ループを完全に閉じて自律的に回している点が、本デモの最大の見どころです。徐々に混合液の色が正解に近づいていく過程は、視覚的にもお楽しみいただけるポイントです。

技術的なポイント

自動分注装置との接続には SiLA 2（ Standardization in Lab Automation ）プロトコルを採用しています。 SiLA 2 はラボ機器間の通信を標準化するオープンな国際規格で、メーカーを問わず装置を統一的なインターフェースで制御できるようにするものです。これにより、 AI Agent がソフトウェアから直接ロボットを操作する連携が可能になります。AI Agent 自体は Amazon Bedrock 上で動作し、実験の計画立案から測定結果の解析、次の実験の意思決定までを一貫して担います。実験全体のワークフロー管理には AWS のクラウドサービスを活用し、一連の自律実験ループをオーケストレーションしています。アーキテクチャの詳細・実装の工夫・技術的なご質問は、ぜひ当日ブースにて直接どうぞ。

同じアーキテクチャで広がる応用先

今回は色水の配合比率という分かりやすいシナリオでデモを行いますが、この Self-Driving Lab のアーキテクチャは、より実践的な研究課題へそのまま展開できます。

創薬研究におけるアッセイ（生物活性の測定試験）条件の最適化
細胞培養のための培地組成探索
製剤における処方設計

いずれも「複数の条件を組み合わせて最適解を見つける」という課題構造は共通しており、 AI が自律的に探索空間を効率よくカバーする Self-Driving Lab の真価が発揮される領域です。HCLS ブースでは、本デモのライブ実演に加え、 4 月に一般提供が開始された Amazon Bio Discovery のデモなど、複数の展示を用意しております。「 AI × ロボット × クラウド」が創る研究の未来を、ぜひ会場で体感してください。皆さまのご来場を心よりお待ちしております。

ヘルスケア・ライフサイエンス関連ブースのご案内：ブース一覧

エリア	ブース番号	タイトル	テーマ
AWS for Healthcare & Life Sciences	A001	AI Scientist ― フィジカル AI が実現する眠らないラボ	Self-Driving Lab
	A013	中外製薬株式会社	創薬・業務向け AI 共通基盤
	A014	第一三共株式会社	AWS PCS × AI エージェントによる創薬研究基盤
	A015	Amazon Bio Discovery	AI エージェント型 AWS マネージドサービス
	A016	AI エージェントが実現する次世代医療ワークフロー	AI エージェントによる自律的な診断支援
AWS for Public Sector	A039	神戸大学大学院医学系研究科	生成 AI 書類審査ソリューション「 RAPID 」
	A040	公共ヘルスケア＆アカデミア	ヘルスケア× AI ：医療・介護の未来

A001　AI Scientist ― フィジカル AI が実現する眠らないラボ
- AI が仮説を立て、実験し、最適解を導く ― クラウドが繋ぐ Self-Driving Lab
- AI が自律的に仮説を立て、ライフサイエンス向けオートメーションワークステーション実機へ実験を指示し、測定結果を解析して次の実験計画を自ら決める。このサイクル全体を AWS クラウドがオーケストレーション。ブースでは実機稼働の様子をリアルタイムで観察でき、 AI が「秘密の混合サンプル」を自力で推定・再現する瞬間を目の前で体感できます。ぜひブースにお立ち寄りください。
A013　中外製薬株式会社
- 創薬・業務向け AI 開発を支える AWS 共通基盤
- 中外製薬では、創薬領域や全社業務の変革に向けた AI 活用を支える基盤の整備を進めています。 AWS 上に認証、 API 連携、 LLM 利用等の共通機能を集約することで、 AI アプリごとの重複実装を抑制し、品質向上と開発スピード向上を両立します。 AI 活用を広げながら、新たなアプリ、エージェント開発・連携や価値創出に繋げる取り組みをご紹介します。
A014　第一三共株式会社
- AWS PCS と AI エージェントで作る創薬研究基盤
- 近年、 AI や解析技術の急速な発展により研究の在り方は大きく変革しており、ロボティクスや生成 AI の導入によって、大量の情報に基づく意思決定の質の向上と効率化が期待されています。第一三共では AWS PCS を用いた解析基盤の安定化と、 AI エージェントによる研究効率化に挑戦しました。本発表では技術導入の背景・成果・今後をご紹介します。 AI エージェントが研究現場にもたらす変革の可能性や期待について、議論できれば幸いです。
A015　AI 創薬新サービス Amazon Bio Discovery
- Lab in the loop の創薬をすべての研究者に ― AI エージェント型 AWS マネージドサービス
- このブースでは、 AWS の新サービス「Amazon Bio Discovery」をご紹介します。 AI エージェントと 40 以上の生物学 AI モデルを活用し、抗体設計からウェットラボ検証までを一気通貫で支援する AWS マネージドサービスです。計算予測と実験結果が自動フィードバックされることで、研究組織全体で「 Lab-in-the-Loop 」をアクセス可能かつスケーラブルにすることが可能です。ご興味ある方はぜひブースにお立ち寄りください。
A016　AI エージェントが実現する次世代医療ワークフロー
- 画像解析からレポートドラフト生成まで ― 自律的な診断支援で医師を支える
- 日本の放射線科医は世界トップクラスの画像診断件数をこなし、業務負荷は増す一方です。本展示では、新規の医用検査画像の到着を起点に Amazon Bedrock AgentCore にホストされた AI エージェントが読影前の準備を自律的に遂行し、医師が確認と最終判断に集中できるワークフローをお見せします。

- - - エージェントが自動で行うこと：
      - 電子カルテから患者背景・既往歴・過去の読影レポートを収集
      - 専門の医療 AI モデルによる病変検出・臓器セグメンテーション・画像所見の解釈
      - 過去検査の確定所見との突き合わせによる経時比較
      - 診断ガイドライン等と照合した日本語の構造化レポートドラフトを生成。過去レポートから読影医の記述スタイルを抽出し、その医師らしい書き味で下書き
- 医師は AI エージェントによる解析結果とドラフトを確認・修正するだけでレポートを仕上げられ、診断までの時間を短縮可能になります。チャットでの追加指示や所見の深掘りも可能です。ぜひブースで体感してください。

A039　公共アカデミア神戸大学大学院医学系研究科
- 生成 AI 書類審査ソリューション「 RAPID 」による研究申請プロセス DX / AX
- 神戸大学 MedLeap（医療特化型スタートアップ拠点）は、研究審査における修正の往復という課題に対し、申請プロセスを再設計する取り組みを進めています。その実装として、Amazon Bedrock を基盤とする書類審査ソリューション「 RAPID 」で先行開発中。現場のスピードと品質の両立を目指し、当日は、今後の展望をご紹介いたします。 AI 実装、業務改革、産学共創、実証フィールド、スタートアップ創出に関心のある皆様のご来訪をお待ちしております。

A040　公共部門ヘルスケア
- ヘルスケア× AI ：医療・介護の未来
- AWS の先進技術を活用し、医療・介護の現場課題を解決するデモを展示します。医療文書の自動生成や診察・カンファレンスにおける音声入力を利用した診療録・記録の作成、医療情報ガイドラインやデジタル庁 GCAS ガイドを遵守したアプリケーション開発に AWS のエージェントコーディングツール Kiro を活用する方法、Kiro と AWS HealthOmics を利用した精密医療のためのゲノミクス解析と可視化、さらには AI を利用した研究計画書の自動作成まで、ヘルスケアにおける幅広い AI 活用の最前線をぜひブースでご体験ください。

Summit 会場：HCLS ブースへのアクセス

本ブログは AWS Summit Japan 2026 ヘルスケア・ライフサイエンスブースの展示紹介シリーズです。他の展示内容については追って公開予定です。

現在利用可能: AWS Graviton5 プロセッサを搭載した Amazon EC2 M9g および M9gd インスタンス

Esra Kayabali — Fri, 12 Jun 2026 00:52:48 +0000

AWS Graviton プロセッサは世代を重ねるごとに着実に進化を遂げ、イテレーションを経るごとに、コンピューティングパフォーマンス、料金パフォーマンス、エネルギー効率の点で進歩してきました。re:Invent 2025 では、Graviton5 を搭載した初のインスタンスである Amazon EC2 M9g のプレビュー版についてお知らせしました。それ以降、お客様は、幅広いワークロードで M9g をテストし、その結果を共有してくださいました。ClickHouse は、コードを変更することなく、M8g と比較して 36% のパフォーマンス向上を実現しました。Honeycomb は、本番オブザーバビリティワークロードの 6 か月間の A/B テストにおいて、Graviton4 と比較してコアあたりのスループットが 36% 向上しました。 HubSpot は、MySQL データベースに M9g をデプロイし、クエリ実行時間を最大 60% 短縮しました。2026 年 6 月 10 日より、M9g インスタンスと、高速かつ低レイテンシーのローカル NVMe SSD ストレージを必要とするお客様向けの新しい M9gd インスタンスの一般提供を開始しました。どちらのインスタンスも、AWS がこれまでに構築した中で最も強力かつエネルギー効率に優れたプロセッサである Graviton5 を搭載しています。

業界では多くの Arm ベースのインスタンスが登場していますが、AWS Graviton の展開の幅広さと奥深さに匹敵するものは他にありません。カスタムシリコンの 5 つの世代と 8 年間の継続的な投資を経て、Graviton は 350 を超えるインスタンスタイプを支え、スタートアップから大企業、強固な ISV パートナーエコシステム、幅広い一連のマネージドサービスに至るまで、12 万を超えるお客様にサービスを提供しています。Graviton は、ウェブアプリケーション、マイクロサービス、分析、データベース、機械学習 (ML) 推論、Electronic Design Automation (EDA)、ゲーム、動画エンコーディングなど、多種多様なワークロードにご利用いただけます。ワークロードでのコンピューティング負荷がより高まり、ワークロードがよりデータドリブンになるにつれ、より多くのデータを移動し、ワークロードをより迅速に完了させるために、より高い処理能力に加え、ネットワークとストレージの帯域幅の拡大を求める声が高まっています。また、当社は、コンピューティング、メモリ、I/O を効率的にパッケージ化して、エネルギー効率を最大化するために、これらのインスタンスを設計しました。

AI の役割が、質問への回答から、アクションの実行、コードの実行、ツールの使用、結果の評価、複数ステップのタスクのオーケストレーションに移行するにつれ、CPU コンピューティングの需要は急速に高まっています。Graviton5 はこの変化に対応するために構築されました。192 コア、5 倍の L3 キャッシュ、最大 33% 低いコア間レイテンシー、高帯域幅を実現する DDR5 メモリを搭載した Graviton5 は、エージェントが CPU バウンドなステップでの待機時間を短縮して、より多くの命令を処理し、多数の同時実行環境に対応するとともに、アクセラレーターを常に稼働させ続けるのに役立ちます。

Meta は、そのエージェンティック AI の取り組みをサポートするために、まずは数千万コアの規模で Graviton を大規模にデプロイしており、Graviton を利用する世界最大のお客様の 1 社となっています。リアルタイム推論、コード生成、複数ステップのタスクのオーケストレーションなど、エージェンティック AI ワークロードは CPU 負荷が高く、Graviton5 の優れたコンピューティングパフォーマンス、より大きなキャッシュ、より高いメモリ帯域幅、コア密度の恩恵を享受できます。

M9g および M9gd の新機能
第 6 世代 AWS Nitro System を基盤として構築された M9g インスタンスは、Graviton4 プロセッサと比較して、より高いコンピューティングパフォーマンス、より大きなキャッシュ、改善されたメモリおよび I/O スケーラビリティを提供する AWS Graviton5 プロセッサを搭載しています。Graviton5 は、Graviton4 ベースのインスタンスと比較して、最大 25% 優れたコンピューティングパフォーマンスを提供し、ウェブアプリケーションでは最大 35%、機械学習推論では最大 35%、データベースでは最大 30%、パフォーマンスが高速化されます。AWS Graviton5 インスタンスは、AWS フリートで初めて最新世代の PCIe Gen6 と DDR5-8800 メモリをサポートする CPU として、クラウドにおけるあらゆるプロセッサインスタンスの中で最速のメモリと、前世代と比較して 5 倍の L3 キャッシュを提供します。また、これらの改善により、エネルギー効率も向上します。そのため、性能を損なうことなく、持続可能性に関する目標を達成するのに役立ちます。

コンピューティングの増大に対応するため、ネットワーキングとストレージの帯域幅が拡張されました。M9g および M9gd インスタンスは、さまざまなサイズにわたって、平均で最大 15% 高いネットワーク帯域幅と 20% 高い Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供し、最大インスタンスサイズではネットワーク帯域幅が最大 2 倍になります。また、M9g および M9gd インスタンスは、Amazon EC2 インスタンスの Amazon EBS と Amazon Virtual Private Cloud (Amazon VPC) ネットワーキングの間の帯域幅の割り当てを最大 25% 調整するのに役立つ機能である Instance Bandwidth Configuration (IBC) もサポートしています。IBC は、データベースの読み書きのパフォーマンス、クエリ処理、ログ記録など、特定の帯域幅要件を満たす必要があるワークロードのパフォーマンスの最適化に役立ちます。これらの機能強化は、高い I/O パフォーマンスを必要とするワークロードのために、より迅速なデータ移動と改善されたスループットをサポートします。

セキュリティと分離は、クラウドでワークロードを実行するための基本的な要件です。Nitro System 内では、AWS Nitro Hypervisor が、インスタンス同士で、また、AWS オペレーターからも分離するように設計されています。M9g および M9gd インスタンスでは、Nitro Isolation Engine の導入により、セキュリティの水準をさらに引き上げています。Nitro Isolation Engine は Nitro System の機能強化であり、インスタンスの分離を強制し、形式検証を活用して数学的な精度で分離の保証を提供します。Nitro Isolation Engine は、仮想マシン間の分離を強制する役割を担う専用コンポーネントです。その役割には、最小限の一連の API を通じて、仮想マシンのメモリ、CPU レジスタ状態、I/O デバイスに対するあらゆるアクセスを仲介することが含まれます。Nitro Isolation Engine は形式検証を活用しています。形式検証とは、ハードウェアまたはソフトウェアが、特定のテストケースにおいてだけでなく、意図されたとおりに動作することを数学的に証明する手法です。この高度な検証手法により、Nitro は形式的に検証された初のクラウドハイパーバイザーとなっており、数学的に証明されたクラウドセキュリティの新たな標準を打ち立てています。

M9g インスタンスは、4 GiB のメモリごとに 1 vCPU を提供し、アプリケーションサーバー、マイクロサービス、中規模データストア、ゲーミングサーバー、キャッシングフリート、コンテナ化アプリケーション、大規模 Java アプリケーション、コードリポジトリ、ウェブアプリケーション、エージェンティック AI など、幅広い汎用ワークロードに適しています。

高速かつ低レイテンシーのローカルストレージを必要とするワークロード向けには、M9gd インスタンスが、最大 11.4 TB の NVMe SSD ストレージに加えて、Graviton4 ベースの M8gd インスタンスと比較して 30% 向上した IOPS とストレージパフォーマンスを提供します。M9gd インスタンスは、アプリケーションサーバー、マイクロサービス、ゲーミングサーバー、中規模 key-value データストア、キャッシングフリート、データログ記録、メディア処理、バッチおよびログ処理、キャッシュやスクラッチファイルなどの一時ストレージを必要とするアプリケーションなど、コンピューティングとメモリのバランスと、高速かつ低レイテンシーのローカルストレージが求められる汎用ワークロードに適しています。

このファミリー全体の主な仕様を次に示します:

M9g	vCPU	メモリ (GiB)	ネットワーク帯域幅 (Gbps)	EBS 帯域幅 (Gbps)
medium	1	4	最大 15	最大 12
large	2	8	最大 15	最大 12
xlarge	4	16	最大 15	最大 12
2xlarge	8	32	最大 17	最大 12
4xlarge	16	64	最大 17	最大 12
8xlarge	32	128	17	12
12xlarge	48	192	25	18
16xlarge	64	256	34	24
24xlarge	96	384	50	36
48xlarge	192	768	100	72
metal-48xl	192	768	100	72

M9gd インスタンスには、ローカル NVMe SSD ストレージが含まれます。以下の表は、各サイズのインスタンスストレージを示しています。コンピューティング、メモリ、ネットワーク、および EBS 帯域幅の仕様は M9g と同じです。

M9gd	vCPU	メモリ (GiB)	インスタンスストレージ (GB)	ネットワーク帯域幅 (Gbps)	EBS 帯域幅 (Gbps)
medium	1	4	1 x 59 NVMe SSD	最大 15	最大 12
large	2	8	1 x 118 NVMe SSD	最大 15	最大 12
xlarge	4	16	1 x 237 NVMe SSD	最大 15	最大 12
2xlarge	8	32	1 x 475 NVMe SSD	最大 17	最大 12
4xlarge	16	64	1 x 950 NVMe SSD	最大 17	最大 12
8xlarge	32	128	1 x 1900 NVMe SSD	17	12
12xlarge	48	192	3 x 950 NVMe SSD	25	18
16xlarge	64	256	1 x 3800 NVMe SSD	34	24
24xlarge	96	384	3 x 1900 NVMe SSD	50	36
48xlarge	192	768	3 x 3800 NVMe SSD	100	72
metal-48xl	192	768	3 x 3800 NVMe SSD	100	72

今すぐご利用いただけます
M9g および M9gd インスタンスは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) リージョンでご利用いただけます。M9g および M9gd インスタンスは、Savings Plans、オンデマンド、スポットインスタンス、ハードウェア専有インスタンス、または専有ホストを通じて購入できます。詳細については、「Amazon EC2 の料金」にアクセスしてください。

M9g および M9gd インスタンスの使用開始に際して、いくつかのリソースをご利用いただけます。AWS Graviton 開始方法ガイドは、Graviton ベースのインスタンス上でワークロードを構築、実行、最適化する方法をカバーするテクニカルガイドです。Graviton Savings Dashboard は、Graviton ベースのインスタンス上でワークロードを実行することで実現できるコスト削減を追跡および測定するのに役立ちます。AWS Transform は、Java アプリケーションを x86 から Graviton ベースの Amazon EC2 インスタンスに移行するためのコード変換を自動化する、AI を利用したサービスです。互換性分析、自動再コンパイル、依存関係の更新、検証を処理します。

Graviton ベースのインスタンスの詳細については、「AWS Graviton プロセッサ」または「Level up your compute with AWS Graviton」にアクセスしてください。

– Esra

原文はこちらです。

実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート

Rie Tanaka — Thu, 11 Jun 2026 09:17:50 +0000

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中里絵です。

本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「AWS Local Executive Roadshow」シリーズの第 3 回レポートです。シリーズの背景や全体像については、前回の大阪・初回レポートをご覧ください。

大阪での 2 日間のイベントに続き、2026 年 4 月 22 日は名古屋にて、AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、「実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜」と題したイベントを開催しました。

イベントの流れ

当日はまず、Amazon Web Services Japan のソリューションアーキテクト古屋楓から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題したオープニングセッションをお届けしました。生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、Amazon Quick のデモを交えながらご紹介しています。セッションの詳細については初回の大阪・事業会社編のレポートをご覧ください。

写真: 古屋によるオープニングセッション

AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、パネルディスカッションへと進みました。ここからは、中部を拠点に 270 年以上の歴史を持ちながら、経営・現場の双方から生成 AI 活用に挑戦されている 1 社の事例をご紹介します。

事例紹介：タキヒヨー株式会社様〜経営と現場、両輪で進める Amazon QuickSight によるデータ活用〜

事例紹介はタキヒヨー株式会社様です。1751 年（江戸時代の宝暦元年）に名古屋で創業された 270 年以上の歴史を持つ繊維アパレル企業で、テキスタイル事業では愛知県一宮市に自社工場をお持ちで、伝統的な英国式紡績機を生かしたものづくりを行われています。アパレル事業では企画・製造・販売に加え、リテール事業として自社ブランドの展開もされており、東京証券取引所・名古屋証券取引所に上場されている企業です。従業員数は540 名(2026年2月末)、ニューヨークに拠点をお持ちのグローバル企業でもあります。

当日は、経営視点と現場視点の両面から、二つのプロジェクトについてパネルディスカッション形式でお話しいただきました。AWS 小嶋がモデレーターを務め、それぞれのプロジェクトの背景から成果までを伺いました。

業務 KPI ダッシュボード化プロジェクト

一つめのエピソードは、執行役員の平田様が経営の視点で推進された、業務 KPI ダッシュボードプロジェクトについてです。

アパレル業界は職人的・属人的な業務傾向があり、勘や経験に頼りがちな面があります。経営として、売上や利益といった KGI よりもっと粒度の細かい業務 KPI で組織の状態を定量的に把握し、営業活動の改善に繋げたいという思いがプロジェクトの出発点でした。ただ当時は、各組織のデータが Excel に散在し、VBA マクロで集計していたため、処理に時間がかかったりマクロが想定どおり動作しないなどの課題がありました。

この課題に対して、Amazon QuickSight を導入し、基幹システムや NAS のデータを一元的に可視化・分析できる基盤を構築されました。ただ、導入にあたって一番苦労されたのが「現場のアレルギー反応」だったといいます。それまで各マネージャーが各々のやり方で管理業務を回していたところに、統一のダッシュボードを導入するという施策そのものに対して、「手間が増える」という受け止めから反発があったとのことです。

この壁を乗り越えるために、とにかく使い勝手にこだわってプロジェクトを進められました。便利さを実感してもらうことで理解を得て、利用も促進したいと考え、ドリルダウン機能の設計に特に注力されました。大きなデータから詳細なデータへと段階的に掘り下げることができ、感覚的な操作で目的のデータにたどり着けるよう設計しました。「普段の動線そのままで使える」ことで現場の抵抗感を下げることに繋げました。また、データの欠損を補うためにWeb経由のデータ入力の仕組みも構築し、ダッシュボードに表示されるデータの信頼性を担保する工夫も行われました。

結果として、URL にアクセスすれば経営データがすぐ確認できる状態になり、現場のマネージャーが本来の意思決定業務に集中できる環境が整いつつあるとのことです。今後は、分析の精度向上や、分析から起こしたアクションが業績にどう寄与するかの効果検証をしていきたい、とお話いただけました。

需要予測データのダッシュボード構築プロジェクト

マーケティングチーム兼DX 推進チームの山口様が現場の実践者として推進されたプロジェクトです。

山口様ご自身はエンジニアではなく、プログラムを書いたご経験はありませんでした。ただ、「自分たちの手でなんとか活性化させたい」という思いから、需要予測データを Amazon QuickSight で可視化するダッシュボードの内製構築に取り組まれました。既存データには、複数の情報（色・柄・素材など）が一つのカラムにまとめて格納されていたため個別の値で抽出できない（例えば何色が売れているか？といった分析はできない）、需要予測の数値が絶対値のみのため、判断の基準がなくアクションに繋がらない、という二つの課題がありました。

開発にあたって、当初は Generative AI Use Cases （ AWSが提供するチャットベースの生成AIアプリケーション）で SQL を生成させていましたが、開発が難航しました。チャットベースのアプリケーションで、必要なデータ（DBのテーブル情報、全体設計、既存データなど）をAIに与えながら作業をさせようとすると、開発が進むほどコンテキストの制限に達してしまい、その都度新しい会話を立ち上げ直す必要が生じ、作業上の煩雑さを生んでいました。さらに、本来は必要なコンテキストを渡しきれない状況も発生し、そうなるとAIが出力するSQLが本来の目的と異なるものになる、といった問題も発生していました。

このような経緯から、チャットボットベースのアプリケーションに限界を感じられ、コーディングエージェントの Claude Code を Amazon Bedrock 経由で利用する方針に切り替えられました。コーディングエージェントであれば、AI エージェントがユーザー指示に応じて必要なローカルファイルを自律的に参照しにいくため、今まで作成してきたテーブル情報やシステム設計、エラー内容までを AI が自動で把握してくれ、開発効率が大きく向上しました。

データの課題については、既存のデータのETLにも取り組まれました。具体的には、一つのカラムに混在していた色・柄・素材などのデータを色別・素材別・シルエット別などにそれぞれのカラムに分けて対応し、絶対値で表示されていた需要予測値も ◎○△✕評価が動的に表示される仕組みに変更されました。この際、Claude Code を単なるコード生成ツールとしてではなく、目的を共有し、既存のデータを生かすためにどんな方法がよいかを一緒に探る「頼れる相談相手」として活用されました。「こういう見せ方はどうか」「この分け方だとデータが崩れないか」──ジェンガのピースを崩さないように一つずつ探していくような試行錯誤を、AI と対話しながら繰り返されたとのことです。

結果として、通常であれば外注で数ヶ月・数百万ほどかかるシステムを、非エンジニアの山口様ご自身が数週間で構築されました。さらに、データ構造を深掘りしていく過程で、ベンダー側でブラックボックス化していた課題に気づき、改善提案に繋げられたという副次的な効果もあったとのことです。今後は自社に蓄積された売上・在庫データの取り込みや、Amazon Quick（Amazon QuickSight が進化して生まれた Agentic AI プラットフォーム）の AI チャット機能の活用も検討されています。

お二人から参加者へのアドバイス

最後に、お二人から参加者へのアドバイスをいただきました。

平田様からは、「まずは現業務を可視化してデータで見られる体制を整えることが第一歩。完璧を目指すのではなく、経営層が現場に対して『小さく試して失敗から学ぶ』ことを許容し、現場の変革を後押しするスタンスが重要」というメッセージをいただきました。

山口様からは、「とにかくデジタル上にデータを蓄積することに注力してほしい。デジタルデータは企業の財産になる」というメッセージ。同じ分量のデータでも、デジタルかアナログかで将来の資産価値が大きく変わる。仮にデータの中身が多少整理されていなくても、AI を活用すれば非エンジニアでも理想的な形に整形できる。アナログからデジタルへの移行方法自体も、AI に相談してみてほしい、とお話しいただきました。

写真: タキヒヨー株式会社平田様・山口様、AWS 小嶋によるパネルディスカッション

経営と現場の両輪で取り組まれたお話に続いて、こうしたデータ活用の取り組みを伴走支援するパートナー様からのセッションです。

パートナーセッション：クラスメソッド株式会社様〜生成 AI 活用のためのデータ収集〜

お客様事例のあとには、AWS プレミアティアサービスパートナーであるクラスメソッド株式会社データ事業本部チームリーダー / プロジェクトマネージャーの三鴨勇太様より、「生成 AI 活用のためのデータ収集」と題したセッションをお届けいただきました。名古屋オフィスを拠点に、お客様のデータ基盤構築やデータ戦略支援を担当されている三鴨様から、データドリブン経営を支えるデータ基盤整備の考え方をお話しいただきました。

データ収集がデータドリブン経営と生成 AI 活用の共通の土台であるという点を特に強調しました。ビジネスの加速のためには、企業が持つデータ資産を生成 AI と組み合わせることで差別化につながる。そのために、属人化している情報があればそれらを効率的にデータ化し、収集していく仕組みが重要だと述べられました。

データ基盤整備の進め方としては、企業文化に合わせて、Needs（需要があるところからデータ基盤整備を進めていく）と Seeds（できるところからデータ基盤整備を始める）の 2 つのアプローチのどちらを取ることもあり、クラスメソッド様が提供するデータ活用基盤構築・運用サービス、データ活用コンサルティング、データ活用分析研修、生成 AI 総合支援サービスなど様々な支援のあり方を紹介いただきました。

写真: クラスメソッド株式会社三鴨様によるセッション

まとめ

セッション後には参加者同士のグループディスカッションやネットワーキングの時間を設け、自社の AI 活用における課題について活発な議論が交わされました。

名古屋でご登壇いただいたタキヒヨー様とクラスメソッド様に共通していたのは、 データをいかに集め、活かせる状態に整えるか という土台の重要性と、小さい成功体験を少しずつ積み重ねる という進め方のベストプラクティスでした。AI を活用している企業様は、データや周囲の巻き込み方など AI 以外の部分にもプラクティスを持っておられることが伝わるセッションでした。

このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした名古屋・3 日目に続き、次回は翌日開催の名古屋・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。

執筆者

Amazon Web Services Japan 合同会社ソリューションアーキテクト　田中里絵

Amazon Web Services ブログ

Amazon Connect Customer とは？エージェンティック AI ソリューションの最新アップデート – 2026 年 5月

1. AWS Summit Japan 2026 Amazon Connect Customer 関連セッション

2. 2026 年 5 月のアップデート一覧

3. AWS Contact Center Blog のご紹介

4. 今月のアップデートに関するよくある質問

著者プロフィール

梅田 裕義（Hiroyoshi Umeda）

セガサミーホールディングスがオンプレミスの Oracle Database を Amazon RDS for Oracle に移行し、性能と運用効率を大幅改善

移行対象のシステム

課題

物理制約と調達遅延

運用負荷

AI 活用を見据えた拡張性の確保

ソリューション

移行スケジュール

プロジェクト計画フェーズ

テストフェーズ

移行実施

導入効果

パフォーマンスの向上

柔軟性の向上

運用効率の改善

データ利活用基盤としての拡張性

AWS Summit 2026 Supply Chainブースのご紹介

製造業が直面するサプライチェーンの課題

AWS サービスを組み合わせた アプリケーションの概要

AI でどのように解決するのか

ステップ1：不確実な需要を「数字」に変える

ステップ2：制約の中で「何ができるか」を即座に計算する

ステップ3：段階的な対応策を提示する

使用している技術要素

Amazon Bedrock AgentCore

Chronos-2（時系列基盤モデル）

Amazon Bedrock Knowledge Bases

Amazon Connect Decisions

コンセプト：発生した問題を即座に捉え、原因分析から対応策までを自動で提示する

主な機能

まとめ

著者について

第 7 回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】

開会のご挨拶

AWS セッション

カスタマー事例

モデル開発者紹介

クロージング

Physical AI — クラウドとロボティクスの融合

AWS Summit Japan 2026

参加者交流会の様子

おわりに

経済産業省 GENIAC 基盤モデル開発支援事業 (第4期) における採択事業者への支援を開始

採択事業者

採択事業者からコメントを頂きました

まとめ

Oracle から Amazon Aurora DSQL へのデータ移行

Amazon Aurora DSQL の概要

移行の課題と要件

ソリューションの概要

前提条件

Amazon Aurora DSQL のターゲットインスタンスを作成する

AWS DMS タスクを構成する

Lambda 関数を作成する

Lambda の構成

AWS Glue ETL ジョブを作成する

データカタログのセットアップ

ジョブの構成

Glue ジョブの IAM 権限

AWS Glue ETL ジョブのスクリプト

Glue ジョブの主な設定

Step Functions ステートマシンを作成する

ステートマシンワークフローの特徴

セットアップの手順

ステートマシンのステート

セキュリティに関する考慮事項

責任共有モデル

セキュリティ実装の優先順位

セキュリティ検証の手順

移行中のデータ保護

脅威モデル

コードのセキュリティレビュー

梅田　裕義（Hiroyoshi Umeda）

AWS サービスを組み合わせたアプリケーションの概要

第 7 回 AWS ジャパン生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】

実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 広島編（#5/8）開催レポート

事例紹介：株式会社エイチビーソフトスタジオ様〜「完璧を待たず、まず触ってみる」現場に寄り添う生成 AI 導入支援〜

実践企業に学ぶ生成 AI 導入の勘所〜眠るデータを企業価値に変える〜 – AWS Local Executive Roadshow 名古屋編（#3/8）開催レポート

事例紹介：タキヒヨー株式会社様〜経営と現場、両輪で進める Amazon QuickSight によるデータ活用〜

パートナーセッション：クラスメソッド株式会社様〜生成 AI 活用のためのデータ収集〜