みなさん、こんにちは。株式会社 APTO で Physical AI のデータ基盤を構築している田中です。 近年、ロボット向け VLA モデルの台頭により、AI 開発の成否は「学習データの品質」に強く依存するようになっています。 しかし、大容量かつ厳密な同期が求められるロボットの操作データを品質を落とさずに日々収集することは非常に困難であり、Physical AI 開発における最大のボトルネックとなっています。 このブログでは、同じ課題に直面するチームの参考となるよう、APTO 社がこの「データ収集」のハードルをどのように仕組み化して解決したのかを紹介します。 想定読者 Physical AI / ロボティクス分野でデータ基盤を設計している方 AWS 上で大量データのイベント駆動処理を構築しようとしている方 スタートアップで少人数チームの MLOps を運用している方 APTO が AWS 上に構築している双腕遠隔操作ロボット向けの Physical AI データ基盤について、下の図 1 でグリーンの  ① 収集 の部分 — エッジ側で完全性をどう確定させ、Amazon S3 へどう引き渡しているか — を 3 章シリーズの第 1 章として解説します。データ基盤の全体像は「収集 → キュレーション → 拡張 → 学習 → 評価」という MLOps ループで構成されており、第 2 章ではクラウド側の自動キュレーションパイプラインに相当する ② キュレーション 、第 3 章では ③ 拡張 および ④ 学習 への接続を扱う予定です。なお、本稿で扱う ① 収集ではエッジ側のチェックを「データの同期が取れているか」に絞っており、品質スコアリング・重複判定・PII検査・統計集計などのキュレーション工程はすべてクラウド側で実施する設計です。 図 1: MLOps ループ全体像 — 収集が本稿のスコープ   1. APTO と Physical AI APTO は 2020 年 1 月設立、東京都千代田区にある約 40 名のスタートアップです ( APTO 会社概要 2026時点)。「イノベーティブなアノテーションで AI 開発に変革を」を掲げ、AI データプラットフォーム harBest を軸に、画像・動画・3D (LiDAR)・自然言語・音声まで幅広い学習データ事業を展開するスタートアップです。近年は LLM 開発支援、RLHF、エージェント、RAG といった領域に加え、Physical AI のユースケースを増やしています。 その一環として、双腕の遠隔操作ロボット (bimanual teleoperation robot) からデータを集め、Vision-Language-Action (VLA) モデルのファインチューニングに供する自社基盤を AWS 上で開発しています。本基盤の中心は「収集 → 自動キュレーション → 学習」のループを効率よく回し続けるための仕組みであり、このブログではそのうち最も上流にあたる「収集」を扱います。 2. 背景と課題 Physical AI とデータ基盤の関係 Vision-Language-Action (VLA) モデルは、視覚と言語指示を統合してロボットの動作を生成する基盤モデルとして、研究と産業応用の両面で進展しています。Google DeepMind の RT-2 、Physical Intelligence の π0 など、大規模 VLA モデルが相次いで発表されており、ファインチューニング向けの高品質データセットへの需要は今後も拡大が見込まれます。 ファインチューニングの成否は、モデルアーキテクチャの良し悪し以上に「投入するデータが安定した品質で揃っているか」に依存します。LLM の RLHF データセットに対する経験則と同じく、Physical AI でもデータおよびそれを提供するデータ基盤の完成度がモデル品質の上限を決める構造になりつつあります。 データを利用する上で直面する 3 つの構造的課題 Physical AI のデータパイプラインを運用しようとすると、次の課題に必ず突き当たります。 収集現場の不安定性 : 双腕ロボットの遠隔操作中に PC が落ちる、USB が外れる、オペレータが途中で介入する、といった事象は日常的に発生します。1 件でも破損エピソードが混入すれば、その後の再現実験や学習指標の信頼性が損なわれます。 後段クラウドで品質判定するコスト : 1 エピソードが数百 MB〜数 GB に達するため、「ひとまず Amazon S3 にアップロードしてから品質判定する」設計では、転送・ストレージ・再ハッシュのコストが線形に積み上がります。 手動キュレーションの限界 : 収集 → キュレーション → 学習 のループを回すには、目視確認・品質ラベル付け・Snapshot 構成といった工程を機械化しなければ、収集にキュレーションが追いつきません。 本基盤が目指す状態 これらを踏まえ、APTO の Physical AI データ基盤は次の状態を実装目標としています。 不完全なエピソードは エッジ側で除外 し、Amazon S3 には「完成したエピソードだけ」が届く Amazon S3 への到着をイベント駆動で受け取り、人間の判断は Release 承認のみ に限定する レビュアーは、クラウド側のキュレーションパイプラインが算出する品質ゲート結果・データセット統計・lineage を見て承認 / 差し戻しを判断する (詳細は次回ブログで扱う) データの ID をハッシュから導出し、ingest を 冪等 にする (同じデータを何度取り込んでも結果が変わらない)   3. Physical AI のデータ収集が難しい理由 図 2: 収集からキュレーションまでのデータフロー全体像 模倣学習 (imitation learning) は、お手本となるデモンストレーションデータを再現するようにポリシーモデルを学習させる手法です。Physical AI の文脈では、教師データの候補として 人間のテレオペレーションで収集されたデータとシミュレーション環境で生成された合成データが挙げられます。現時点では動作や映像の自然さや接触の忠実度といった面でテレオペデータの方が品質が高いと考えられ、多くの場合は人間が遠隔操作したロボットの動作を再現するようにモデルを学習させます。VLA モデルのファインチューニングでは、この教師データとして用いる「人間のデモンストレーション」が一定品質で揃っていることが前提となります。 ところがロボットの生ログには、次の三つのノイズが必ず混入します。 アクションと状態の混在 : 双腕遠隔操作では、人間が操作するリーダーアームと追従するフォロワーアームを別ストリームとして残さないと、 action と state が同一テンソルに混ざってしまいます。これは学習側のラベル設計を破壊します。 同期ズレ : カメラフレームとモータサンプルのタイムスタンプ差分が一定値を超えると、視覚と動作の対応関係が崩れます。本実装では WARNING / CRITICAL（2ms / 5ms）の二段階閾値で逐次判定しています。 エピソードの欠損 : 書き込み中に PC が落ちた、人間が途中で介入した、といった理由で不完全なエピソードが混じります。1 件の混入で再現実験の信頼性が失われます。 図 3: 双腕遠隔操作の Leader / Follower 構成   これらを後段のクラウドで除去する設計は費用対効果が悪く、Amazon S3 にアップロードしてから「不完全だった」と判明する経路では、転送と再ハッシュのコストが線形に積み上がります。本基盤ではエッジ側で完全性を確定させ、不完全なエピソードは S3 に渡さないことを設計の出発点としました。 4. 設計を貫く 3 原則 本基盤を貫く設計原則は次の 3 つです。データ品質を担保するためのルールとして先に定義し、そのうえでルールに則って AWSのサービスや機能を選定しています。 Immutability : Episode / Snapshot / Batch は一度作ったら書き換えません。修正は新ハッシュで別エンティティを作り、 derived_from で系譜を残します。 Content-Addressed Storage : エピソードの ID はファイル群の決定論的ハッシュから導出します。同じデータを何度取り込んでも同じ ID になり、ingest が冪等になります。 Event-Driven : 完了したエピソードの到着を S3 イベントで検知し、自動処理を駆動します。人間の判断は Release 承認のみに限定します。   5. 収集エンジンの 3 プロセス構成 図 4: sync-engine の 3 プロセス分離   エッジ PC 側の収集エンジン (sync-engine) は、責務の異なる 3 つのプロセスを共有メモリ ( SharedRingBuffer ) で接続する構成を採っています。 Collector プロセス : センサーとカメラからの読み取り、H.264 と FFV1 (深度) の動画エンコードを担当します。 Sync プロセス : メタデータだけでタイムスタンプを照合し、同期品質を逐次判定します。 Storage プロセス : motor_state.bin / sync_log.bin / events.jsonl などのバイナリファイルをディスクに書き出します。 この 3 プロセス構成は、後述する異常停止時の安全装置 (QualityMonitor) と直接結びつきます。Sync プロセス内で品質劣化を検知した時点で multiprocessing.Event を立て、Collector / Sync / Storage の 3 つを同時にグレースフル停止し、エピソードに .failed センチネルを置く流れです。 6. raw フォーマットの設計 現状のフォーマット選定と今後の方向性 エッジで保存する原本 (raw) のフォーマットは、学習で使う LeRobot v3.0 への変換前データを格納するレイヤです。Physical AI / ロボティクスで一般に検討される候補と評価ポイントを並べると次のようになります。 候補 評価ポイント apto-raw-v5 (現行試行) 変換前の物理層を可逆に残せる。当面の運用には十分だが標準ではない MCAP (Foxglove + ROS 2) スキーマと可視化が強い。ロスレス深度動画 (FFV1) や CAN-FD 生ログを 1 階層に同居させる運用を確立できれば有力候補 HDF5 自己 記述型で扱いやすい一方、動画コーデックの選択肢が限定的、巨大単一ファイルが S3 のオブジェクト単位アップロード／部分取得と相性が悪いという課題 Apache Arrow IPC 列指向で学習側との親和性は高い。Stream Format で追記は可能だが、エピソード途中で異常終了した際の整合性保証が現時点のネック これらを踏まえ、現時点では自前の apto-raw-v5 を試行的に採用しています。標準フォーマット側で「ロスレス深度動画 + CAN-FD 生ログを 1 階層に同居させる」運用ノウハウが揃いきっていないため、まずは可逆性と運用容易性を優先した暫定解という位置づけです。 ただし、このレイヤのフォーマット選定は引き続き検討中で、Physical AI 周辺のフォーマット標準は流動的なため、将来的に MCAP などの標準フォーマットへ移行する可能性は残しています。いずれを採るにせよ、(1) 全タイムスタンプを int64 ナノ秒で統一する、(2) CAN-FD 生ログをそのまま保持する、(3) 深度動画をロスレスで保持する、という三点はフォーマット選定に依らず満たす方針です。これらは将来「キュレーションをやり直す」「別の特徴量を後付けで計算する」という要件に直接効いてきます。 クロック同期源 i64 ns で精度を確保しても、各センサーのクロック源が揃っていなければ同期判定そのものが意味を失います。本基盤では次の方針を取っています。 カメラ : PTP (IEEE 1588) 対応の GigE Vision カメラを採用し、PC ホストを PTP マスタとして全カメラを同期。フレームには PC 受信時刻ではなくカメラ側ハードウェアクロックのタイムスタンプを正として保存します。 モータ (CAN-FD) : CAN フレーム自体はタイムスタンプを持たないため、CAN コントローラの SOF 受信タイミングを PC ホストの CLOCK_MONOTONIC_RAW で打刻しています。CANコントローラのHWタイムスタンプを使う方法も考えられます。 WARNING / CRITICAL 閾値の根拠 : カメラフレーム間隔 33 ms (30 fps) に対し、サブフレーム精度を保つために WARNING 2 ms、CRITICAL 5 ms を設定。CRITICAL を超えるとフレーム内での視覚と動作の対応関係がずれ、模倣学習で扱えなくなります。 PTP 同期がない環境では NTP のミリ秒精度に劣化し、CRITICAL を超えるリスクが増えます。本基盤を別環境に適用する場合は、まずクロック同期源の選定が出発点になります。 7. 完全性をエッジで確定させる仕組み 収録中の電源断・プロセスクラッシュで、エピソードが「途中まで書かれた状態」になることは避けられません。問題はそれを後段が完成済みと誤認することです。誤認すると不完全なデータが学習データセットに混入します。エッジ側では「途中で壊れた状態のエピソードを下流に流さない」ことを最優先にしています。 エッジでは抽象度の異なる3つの層で完全性を担保します。 防ぐ失敗 仕組み 失敗時のマーカー レイヤ 1: ファイル単位 単一ファイルが書きかけのまま本来名で残る アトミック書き込み: .part 拡張子で書き出し → fsync → atomic rename 中間ファイルは .part のまま残る（本来名は存在しない） レイヤ 2: エピソード単位 個々のファイルは完全だが、エピソード全体としては途中で中断している .done センチネルによる完了判定。全ファイルが揃った後に .done センチネルを置く .done が存在しない レイヤ 3: 意味的品質 ファイルとしては完全だが、同期ズレで学習に使えない 同期品質劣化時の安全停止 (QualityMonitor): QualityMonitor が閾値超過を検知 .failed を置く 後段（クラウド ingest や Storage プロセス側のスキャナ）は、この3つのマーカーだけを見て「完了 / 未完了 / 失敗」を判定します。中身のパースや SHA-256 検証は後段の責務として明確に切り分けています。 ファイルの存在だけを完了条件にしている理由は、 復旧時の判断を静的検査だけで完結させたい ためです。「特定ファイルが存在するか否か」だけで判定できれば、復旧ロジック自体を実質的に ゼロにできます。後述する Amazon S3 Event Notifications のフィルタ設計も、この原則の延長線上にあります。 全体シーケンス まず初めに全体の流れを図示します。 各データファイルを .part で書き出し → fsync → atomic rename manifest.json を atomic write + 親ディレクトリ fsync 正常完了なら .done、異常停止なら .failed を touch RawUploadAgent が各ファイルを並列 PUT 後、manifest.json を最後に PUT して S3 Event を発火 ファイル単位のアトミック書き込み 個々のファイルは次の手順で書き出します。 .part 拡張子で書き出す（例: cam_front.mp4.part ） 書き終わったら fsync() でデータを物理デバイスに永続化する os.replace() で .part を本来名（例: cam_front.mp4 ）にアトミックに rename する 親ディレクトリに対して fsync() を呼び、ディレクトリエントリの変更も永続化する この手順を守ることで、電源断が起きても「古い完全なデータが残っている」「新しい完全なデータが置かれてい る」「 .part のまま残っている」のいずれかにしかならず、 本来名で半端なファイルが見える状態は発生しません 。 manifest.json も同じ手順で書き出します。 また、エッジストレージ は NVMe SSD + ext4 (data=ordered) を採用しています。ext4 の data=ordered モードでは、データブロックがジャーナル commit より先にディスクへ書き出されることが保証されます。このため、fsync() + os.replace() の組合せでクラッシュ後も「古い完全なデータ」または「新しい完全なデータ」のどち らかが必ず観測されます。これは アトミック書き込みが成立する前提条件です。NFS / FUSE 等にファイルシステムを変更する場合、アトミック書き込みが破綻する可能性があるため、必ず再評価が必要です。 エピソード単位の完了判定 すべてのファイルが揃った時点で、エピソードディレクトリ直下に .done を touch します。途中で中断した場合は .done を置かないか、QualityMonitor が .failed を置きます。 完了検知は、 .done と manifest.json の両方が揃っているかだけで判断します。中身のパースや整合性チェックはクラウド側 ingest の責務として後段に切り分けています。 意味的品質を守る安全装置 (QualityMonitor) ファイルが完全に書けても、収録中の同期品質が劣化していれば学習には使えません。Sync プロセスはカメラフレームと最近傍モータサンプルのタイムスタンプ差分（同期ズレ）を逐次監視しています。この差分の時系列は原本中の sync_log.bin に保存され、後段の品質ゲートでも参照できます。 QualityMonitor が .failed を置く判定条件は次の二つです。 CRITICAL レベルのドリフトが一定フレーム数連続する 観測ウィンドウ内で CRITICAL の割合が一定割合を超える いずれかを満たした時点で、3 プロセス全体（Sync / Storage / Camera）をグレースフル停止し、エピソードに .failed センチネルを置きます。これにより、品質が劣化したフレームが含まれるエピソードはクラウ ドに渡る前にエッジで除外されます。 8. Amazon S3 へのアップロード manifest.json を最後に PUT する設計 RawUploadAgent は完了したエピソードのディレクトリを 1 ファイルずつ Amazon S3 raw バケットにアップロードします。ここで重要なのは、 manifest.json を 最後に PUT することです。 理由はクラウド側の S3 Event Notifications との接続にあります。1 エピソードから 8 オブジェクト前後が生成されますが、すべてに対してイベントを発火させると下流の Amazon SQS キューが 8 倍に膨らみます。さらに、まだアップロード途中の状態で Worker が S3 を読みに行くと、ファイル不一致による偽の IntegrityError が DLQ に積まれてしまいます。 そこで、(1) S3 Event Notifications 側でフィルタを filter_suffix = "/manifest.json" に絞り、(2) manifest.json は他の全ファイルの PUT が完了してから最後に置く、という二段の制約で「完了したエピソード 1 つに対して SQS メッセージ 1 つ」を成立させています。 この設計が成立するのは、S3 Event Notifications がオブジェクトキーの prefix / suffix フィルタをネイティブにサポートしているからです。Terraform での設定はほぼ次の 1 ブロックに収まります。 resource "aws_s3_bucket_notification" "raw" { bucket = aws_s3_bucket.raw.id queue { queue_arn = aws_sqs_queue.s3_events.arn events = [ "s3:ObjectCreated:Put" ] filter_suffix = "/manifest.json" } depends_on = [aws_sqs_queue_policy.s3_events] } filter_suffix を /manifest.json に固定するだけで、エッジ側が manifest.json を最後に PUT した瞬間にのみ SQS メッセージが 1 件キューに入る関係が S3 側で完結します。 実装は concurrent.futures.ThreadPoolExecutor で並列 PUT し、 as_completed() で全 future の完了を待ってから manifest.json を PUT します。1 つでも失敗していれば例外を伝播させ、 .failed を残してエピソード全体を破棄します。 from concurrent.futures import ThreadPoolExecutor, as_completed def upload_episode (episode_dir: Path , bucket: str , key_prefix: str ) -> None : data_files = [f for f in episode_dir.iterdir() if f.name not in { "manifest.json" , ".done" }] with ThreadPoolExecutor(max_workers= 8 ) as pool: futures = [pool.submit(_put_with_checksum, f, bucket, f"{key_prefix}/{f.name}" ) for f in data_files] for fut in as_completed(futures): fut.result() # raise on failure → episode を破棄 # 全データファイル PUT 完了後に manifest.json を最後に PUT # → S3 Event Notifications の filter_suffix="/manifest.json"が発火 _put_with_checksum(episode_dir / "manifest.json" , bucket, f"{key_prefix}/manifest.json" ) _put_with_checksum は boto3 の put_object(ChecksumAlgorithm="SHA256") を呼び、S3 の Additional Checksum 機能でサーバ側でも SHA-256 を再計算させてオブジェクトメタデータに保存します。Worker 側の再計算検証と組み合わせ、データ整合性は二重に担保しています。 .tar でまとめない理由 今回はエピソードを .tar でまとめずに、ディレクトリ構造をそのまま Amazon S3 のキー階層に写し取る方針を採っています。tar 一括 PUT 案と個別 PUT 案を精査した結果、コスト差は小さく(現状 8 ファイル/エピソード規模で損益分岐は約 43 ファイル)、判断は技術観点で決まりました。個別 PUT を選んだ主な理由は次の通りです。 後段 Stage の非対称なアクセスパターン : CosmosStage(映像品質判定)は動画のみ、学習(DataLoader)は Parquet のみを必要とします。個別 PUT なら必要なファイルだけ GET できますが、tar 化すると毎回全体を GET して展開する必要があり、特に GPU ノードで I/O 待ちが発生するのは設計として不適切です。 CopyObject による stream-copy 最適化が崩れる : ColdConvertStage では動画を raw から cold へ CopyObject で転記し、ECS Worker の CPU・帯域コストをゼロに抑えています。これは個別ファイルが独立した S3 オブジェクトとして存在することが前提です。 tar の「全か無か」性質との不整合 : 部分破損で全体が読めなくなる、Range Request で部分読みできない、Glacier 復元で毎回全体を取り出すことになる、IAM / KMS 粒度がファイル単位で切れない、といった問題が積み重なります。 なお tar 形式そのものを否定しているわけではなく、学習配布用の WebDataset 形式や Glacier Deep Archive への長期アーカイブなど、raw アップロード経路とは別レイヤーで tar 化する価値がある用途は存在します。 9. まとめと次回予告 このブログでは、Physical AI のデータ基盤において「完成したエピソードだけを AWS に渡す」状態をエッジ側でどう作るかを解説しました。要点は次の三点です。 自前フォーマット apto-raw-v5 を採用 : i64 ns タイムスタンプ・CAN 生ログ・ロスレス深度を 1 階層で保持しています。MCAP / HDF5 / Apache Arrow IPC のいずれでもこの組合せを単独では満たせなかったためです。 完了判定をファイル存在のみに統一 : .done と manifest.json の両方が揃ったときだけ完了とみなす原則を採り、状態機械の複雑化を避けました。これがクラウド側のイベント駆動設計に直結します。 manifest.json を最後に PUT : Amazon S3 Event Notifications を「エピソード完了 = 1 通知」という対応関係に整理しました。 Physical AI のデータパイプラインを長く回し続けるには、「機械的にやれる工程は全部自動に寄せ、人間の判断を Release 承認だけに集中させる」ことが鍵となります。エッジ側で完全性を確定させる本稿の設計は、その自動化を成立させる土台です。 第 2 章では、この manifest.json 到着イベントを起点に動く AWS 側のキュレーションパイプラインを扱います。Amazon S3 → Amazon SQS → Amazon ECS Fargate Worker のイベント駆動 ingest、Episode / Snapshot / Batch の 3 層モデル、9 サブステップの構造化キュレーションと 2 階層品質ゲートが中心です。続く第 3 章では、データ拡張と VLA ファインチューニングへの接続、シミュレーション環境との統合、マルチロボット対応の方向性を予告編としてお届けします。 同じような課題に取り組まれているスタートアップの参考になれば幸いです。 We are hiring!! APTOは、AIやPhysical AI領域のデータに特化したサービスを提供しています。 技術の実装を進めたい方、研究開発に興味がある方などは、下記採用ページからエントリーください！ https://apto.co.jp/careers/ 著者プロフィール 田中 達也 (Tatsuya Tanaka) APTOにてPhysical AIやロボティクス領域のデータパイプライン開発、およびUI構築をメインに担当しているAIエンジニアです。データの同期やマルチモーダルデータ管理など、AI活用に向けたデータ基盤の設計・開発に従事しています。趣味は競技プログラミングと陸上観戦。学生時代は陸上一筋でしたが、現在はもっぱら見る専門です。 遠藤 俊策 (Shunsaku Endo) ポジション: Co-founder / AI Engineer バンタンゲームアカデミーで、学内の審査会で数々の賞を受賞。その後、AI開発にも興味を持ち2020年1月にAPTOを共同創業。現在は、APTOのCDOとして開発とビジネス双方を管理。 GitHubアカウント: synsax( https://github.com/synsax ) 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Startup 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

スタートアップとの仕事には、本当に刺激的な何かがあります。私は 2 年以上にわたって、このような仕事に精力的に取り組んできました。スタートアップは、他とは異なる周波数で活動しています。切迫感は切実で、制約は厳しく、背負っているリスクは個人的なものです。これらのスタートアップがビジネスモデルを証明するという課題を乗り越えるのをサポートするには、技術的な専門知識だけでなく、迅速に行動し、前提を疑い、まだ完璧なデータが存在していない時点から適切なアーキテクチャに賭ける意欲が必要です。 私が最も気に入っているのは、仕事が決して抽象的ではないことです。すなわち、スタートアップが下すのを私がサポートするあらゆる意思決定は、適時に製品を出荷できるか、予算内に収めることができるか、投資家から次のラウンドで信頼を得られるかに直接影響があるのです。 2026 年 5 月 25 日週の AWS ニュースを見ていきましょう。 ヘッドライン 新規開設 – トルコのイスタンブールにおける AWS ローカルゾーン – AWS はトルコのイスタンブールに新しいローカルゾーンを開設しました。これにより、欧州最大の都市圏の 1 つに AWS のコンピューティング、ストレージ、ネットワーキングサービスを提供できるようになりました。トルコでデータレジデンシーに関する要件を満たす必要がある組織にとって、このローカルゾーンは、AWS サービスのあらゆる機能をフル活用しながら、データを国内に保持することを可能にします。また、エンドユーザーの実際の所在地により近い場所で実行できるため、リアルタイムゲーム、メディア制作、ライブ動画ストリーミング、金融サービスなど、1 桁ミリ秒のレイテンシーを必要とするアプリケーションに、ローカルゾーンは大きなメリットをもたらします。 ローカルゾーンは、大規模なインフラストラクチャ投資です。すなわち、ハードウェア、電力、ネットワーキング、運用上の優秀性といった点で、リージョンと同じレベルのコミットメントが必要となります。また、これは、サービスが行き届いていない市場への継続的な拡大を反映する AWS の取り組みでもあります。 トルコのビルダーにとって、これは一連の新たなアーキテクチャの可能性を切り開くものです。データレジデンシーに関する要件を満たすのに役立つよう、トルコ内にデータを保存およびバックアップできるようになったほか、イスタンブールのローカルゾーンで低レイテンシーワークロードを実行し、AWS リージョンにシームレスに接続できるようになりました。そのため、独自のデータセンターインフラストラクチャを管理することなく、ハイブリッドアプリケーションを構築するための柔軟性が得られます。トルコにおける 10 年にわたる当社の取り組み、利用可能なサービス、お客様、パートナーに関する詳細については、 立ち上げに関するブログ記事 にアクセスしてください。 2026 年 5 月 18 日週のリリース 私が注目したいくつかのリリースや最新情報をいくつかご紹介します: Security Hub Extended が 9 つのカテゴリにわたる 21 の厳選されたパートナーソリューションに対応 – AWS Security Hub Extended は、エンドポイント保護、クラウドセキュリティ体制管理、脅威インテリジェンスなど、9 つのカテゴリにわたる 21 の厳選されたパートナーセキュリティソリューションと統合するようになりました。カスタム統合を必要とせずに、より広範なツールエコシステムから、統合され、優先順位付けされた、セキュリティに関する検出結果を Security Hub 内で直接取得できるようになりました。これは、AWS およびサードパーティーツール全体にわたるセキュリティ体制の統合ビューを求めているエンタープライズセキュリティチームにとって特に有益です。 Amazon SageMaker AI now supports OpenAI-compatible APIs for inference endpoints – OpenAI 互換 API を使用して、Amazon SageMaker AI の推論エンドポイントを呼び出せるようになりました。これにより、SDK の変更なく、AI ワークロードを OpenAI から SageMaker に移行したり、複数のプロバイダー間で機能するアプリケーションを構築したりすることが大幅に容易になります。これにより、OpenAI を使用してプロトタイピングを開始し、AWS 上の、よりスケーラブルでコスト管理されたインフラストラクチャへの移行を検討しているチームにとって、移行のハードルが下がります。既存のアプリケーションコードはそのまま使用できます。必要なのは、SageMaker エンドポイントをポイントすることだけです。 AWS Secrets Manager Agent のプリフェッチと IAM ロール引き受けの紹介 – AWS Secrets Manager Agent は、起動時にシークレットをプリフェッチし、IAM ロールを引き受けてそれらのシークレットを取得できるようになりました。これにより、レイテンシーが重要な要素となるアプリケーションでオンデマンドのシークレット取得に伴うコールドスタート時のレイテンシーが解消されます。エージェントを設定することで、アプリケーションがトラフィック処理を開始する前に必要なシークレットをプリロードできるため、本番におけるシークレット関連のレイテンシースパイクのリスクを軽減できます。また、IAM ロールの引き受けのサポートにより、アクセス許可の境界が異なるワークロード間でエージェントを共有することも容易になります。 AWS がオープンソースの DynamoDB 互換アダプター ExtendDB を発表 – AWS は、DynamoDB 互換アダプター ExtendDB をオープンソース化しました。これにより、代替バックエンドストレージシステム上で DynamoDB API とデータモデルを利用できます。これは、ローカル開発およびテストワークフローにおいて特に有用です。ライブ AWS 接続を必要とせずに DynamoDB API への書き込みが可能です。また、基盤となるストレージレイヤーをより詳細に制御しながら DynamoDB 互換のセマンティクスを必要とするシナリオにも役立ちます。これは、データアクセスレイヤーに移植性を組み込みたいチームにとって実用的なツールです。 AWS SAM CLI がローカルのサーバーレス開発を加速するために AWS CloudFormation Language Extensions のサポートを追加 – AWS SAM CLI が AWS CloudFormation Language Extensions をローカルでサポートするようになりました。これは、変換、動的参照、および他の CloudFormation 言語機能を、ローカルの開発およびテストワークフローで直接使用できることを意味します。これにより、ローカルでテストできるものと、本番で実行されるものの間に長年存在していたギャップが解消され、ローカルでのサーバーレス開発がより高速かつ信頼性の高いものになります。SAM を使用してサーバーレスアプリケーションを構築し、ローカルテストでエッジケースに遭遇した場合、このアップデートによってエクスペリエンスが大幅に改善されます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加の記事やリソースをいくつかご紹介します: Amazon Bedrock introduces new advanced prompt optimization and migration tool – この記事は、Amazon Bedrock で新たにリリースされた高度なプロンプト最適化および移行ツールをカバーしています。これらは、お客様がモデルのパフォーマンスを向上させるためにプロンプトを自動的にチューニングするのに役立ち、異なる基盤モデル間でプロンプトを移行するのを支援します。本番 AI ワークロードにおけるプロンプトの質のイテレーションに取り組んでいる場合は必読です。 Introducing Kiro Web – AWS の AI 利用開発環境である Kiro に、ウェブベースのインターフェイスが追加されました。Kiro Web を使用することで、デスクトップ IDE をインストールすることなく、ブラウザから直接、Kiro の仕様駆動型開発、AI チャット、エージェント機能にアクセスできます。これは、クイックレビュー、新しいマシンでのプロトタイピング、チームへの Kiro ワークフローの導入など、あらゆる場面において、AI 支援開発をより身近なものにするための大きな一歩です。 Announcing updated retry behavior for AWS SDKs and Tools – AWS は、SDK および CLI ツール全体のデフォルトのリトライ動作を更新しました。これにより、デベロッパーによる設定変更を必要とせずに、一時的なエラーに対する回復力が高まりました。更新された動作には、よりスマートなバックオフ戦略と、スロットリング応答のより適切な処理が含まれています。API レート制限や一時的な障害に時折遭遇する本番ワークロードを実行している場合、今回のアップデートにより、すぐに信頼性が高まります。変更内容とアプリケーションへの影響を理解するために、ぜひご一読ください。 Bitnami image removal from ECR Public – AWS は、Bitnami コンテナイメージが Amazon ECR Public から削除されることを発表しました。ワークロードが ECR Public から Bitnami イメージをプルしている場合は、この記事を確認して、タイムラインと移行パスを理解してください。Bitnami イメージは Bitnami の独自のレジストリから引き続き直接入手できます。この記事では、イメージ参照を更新して中断なくプルし続ける方法について説明しています。 今後の AWS イベント カレンダーを確認して、これらのイベントにサインアップしましょう: AWS Summit Amsterdam – 5 月 27 日にアムステルダムで開催され、クラウドと AI に関するセッション、ハンズオンラボ、欧州各地のビルダーや AWS エキスパートとのネットワーキングといった、盛りだくさんの 1 日をお過ごしいただけます。登録は無料です。 AWS Summit Bangkok – AWS Summit Bangkok は 5 月 28 日に開催されます。東南アジアのビルダーやお客様にとって、クラウドイノベーションの最新情報を詳しく知り、つながるための絶好の機会となります。 AWS Summit Milan – 同じく 5 月 28 日、AWS Summit Milan がイタリアで開催されます。AWS コミュニティが一堂に会します。南欧州にお住まいの方は、ぜひご参加ください。 AWS Summit Mumbai – 同じく 5 月 28 日、AWS Summit Mumbai が、クラウドと AI に関するコンテンツをインド全土のビルダーにお届けします。詳細なアジェンダと登録については、リンクをご確認ください。 AWS Summit Los Angeles – ロサンゼルスにおける 6 月 10 日のイベントをお見逃しなく。近日開催予定の AWS Summit LA は、西海岸のビルダーコミュニティとつながる絶好の機会です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンス。ラテンアメリカにお住まいの方は、8 月 22 日に開催される AWS Community Day Belo Horizonte をお見逃しなく。登録は awscommunityday.com.br で受付中です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 5 月 25 日週のニュースは以上です。2026 年 6 月 1 日週の Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

本記事は 2026 年 5 月 19 日 に公開された「 Automated JDBC query caching with the AWS Advanced JDBC Wrapper 」を翻訳したものです。 データベース負荷の大半を読み取りクエリが占めている場合、元データがほとんど変化しない場合でもレスポンスタイムが悪化し、コストが増加します。従来の対策はカスタムキャッシュレイヤーの構築ですが、クエリごとに外部キャッシュロジックを実装し、シリアライゼーションを処理し、データベースとの整合性を維持する必要があります。ビジネス機能の開発に割くべきリソースを大きく消費します。 本日、AWS Advanced JDBC Wrapper 向けの Remote Query Cache Plugin を発表します。クエリキャッシュを自動的に処理し、JDBC クエリをインターセプトして結果を Amazon ElastiCache for Valkey にキャッシュし、以降の同一クエリをキャッシュから提供します。アプリケーション側の変更はクエリに SQL ヒントを付加するだけです。 本記事では、Amazon CloudWatch Database Insights を使用してキャッシュ対象のクエリを特定する方法、Java アプリケーションで Remote Query Cache Plugin を設定する方法、Amazon CloudWatch でキャッシュの効果をモニタリングする方法を説明します。 外部キャッシュ実装の課題 データベースアプリケーションにキャッシュを追加する場合、通常 3 つの大きな障壁があります。 アプリケーションの複雑な改修: 既存アプリケーションにキャッシュを追加しようとする場合、サービスコードメソッドへのアノテーション、キャッシュパラメータの設定、別設定ファイルでの TTL 管理など、アプリケーション層での変更が必要です。変更はコードベース全体に広がり、特定のフレームワークに依存する場合があります。 新しい API とパターンの習得: キャッシュの統合には、新しいクライアントライブラリの習得、シリアライゼーションフレームワークの理解、キャッシュ障害時のエラーハンドリングの実装が必要です。既存のデータベースコードを維持しながら、これらの技術に習熟する必要があります。 キャッシュ管理の複雑さ: キャッシュの無効化、キャッシュサーバーの適切なサイジング、一貫したキャッシュキーの生成、キャッシュヒット率のモニタリング、キャッシュサーバーがダウンした時の安全な障害処理を手動で管理する必要があります。 結果として、キャッシュロジック構築に多大なリソースを投じるか、データベースコストの増大とパフォーマンス低下を許容するかの選択を迫られます。 AWS Advanced JDBC Wrapper Remote Query Cache Plugin による課題の解決 Remote Query Cache Plugin を使用すると、既存の PostgreSQL、MySQL、MariaDB アプリケーションにクエリ結果キャッシュを統合できます。プラグインはアプリケーションに対して透過的に動作し、自身でキャッシュレイヤーを構築するオーバーヘッドがありません。 キャッシュ対象のクエリに SQL ヒントを追加するだけで済みます。プラグインは Amazon ElastiCache for Valkey の確認、ミス処理、結果のシリアライゼーション、キャッシュへの自動格納を透過的に行います。 プラグインは既存の JDBC インターフェース経由で動作します。Spring Data JPA、Hibernate、Spring JDBC Template、ネイティブ JDBC など、使い慣れたパターンをそのまま使い続けられます。Valkey クライアント、シリアライゼーション、エラーハンドリングはプラグインがバックグラウンドで管理します。 プラグインはキャッシュキーを自動生成し、設定可能な TTL (time-to-live) 値で有効期限を管理し、キャッシュが利用不可の場合はデータベースクエリにフォールバックします。独自の計測コードを追加せずに Amazon CloudWatch へメトリクスを送信してモニタリングできます。 アーキテクチャ概要 Remote Query Cache Plugin のリードスルーキャッシュの動作を次の図に示します。 図 1: Java アプリケーション、Amazon ElastiCache for Valkey、Amazon Aurora または Amazon RDS 間の Remote Query Cache Plugin リードスルーキャッシュフロー 動作の仕組み: アプリケーションがキャッシュヒント ( /* CACHE_PARAM(ttl=<duration>) */ ) 付きのクエリを実行します。 プラグインがクエリに一致するキャッシュ結果を ElastiCache で確認します。 キャッシュヒット (3a): 結果がマイクロ秒単位でプラグインに返され、ステップ 4 と 5 はスキップします。 キャッシュミス (3b): プラグインがクエリを Aurora/RDS データベースに転送します。 データベースがクエリを実行し、最新の結果をプラグインに返します。 プラグインが結果を非同期で ElastiCache に格納し、以降のリクエストに備えます。 プラグインが結果をアプリケーションに返します。 プラグインは初回アクセス時にキャッシュを格納するため、アプリケーションロジックの変更は最小限で、SQL ヒントの設定のみで済みます。 キャッシュ対象クエリの特定方法 すべてのクエリがキャッシュの恩恵を受けるわけではありませんが、まず着目すべきは頻繁に実行されデータベース負荷に大きく影響を与える SELECT 文です。通常、大規模なデータセットを集計または結合して小さく安定した結果セットを返すクエリが該当します。 Amazon Relational Database Service (Amazon RDS) と Amazon Aurora で稼働するデータベースの場合、 CloudWatch Database Insights を使用してこれらのクエリを特定できます。 describe-dimension-keys CLI コマンドは、 db.load.avg 順にランク付けされた上位 SQL 文を返します。このメトリクスは平均アクティブセッション数を測定し、各クエリがどの程度データベースキャパシティを消費しているかを示します。 データベース負荷による上位 SELECT 文の特定 INSTANCE_ID="<your-db-instance-identifier>" REGION="<your-aws-region>" aws pi describe-dimension-keys \ --service-type RDS \ --identifier $(aws rds describe-db-instances \ --db-instance-identifier "${INSTANCE_ID}" \ --query "DBInstances[0].DbiResourceId" \ --output text \ --region "${REGION}") \ --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --metric db.load.avg \ --group-by '{"Group":"db.sql_tokenized","Dimensions":["db.sql_tokenized.statement"],"Limit":20}' \ --region "${REGION}" \ --query 'sort_by(Keys[?starts_with(Dimensions."db.sql_tokenized.statement",`SELECT`) || starts_with(Dimensions."db.sql_tokenized.statement",`select`)], &Total) | reverse(@) | [*].{Load:Total, SQL:Dimensions."db.sql_tokenized.statement"}' \ --output table このコマンドは結果を SELECT 文のみにフィルタリングし、 db.load.avg の降順でソートします。 db.load.avg の値は、対象時間ウィンドウにおけるそのクエリの平均アクティブセッション数です。値が 0.42 の場合、そのクエリが平均して 1 つのアクティブデータベースセッションの 42% を占めていたことを意味します。リストの上位にあるクエリほどデータベースキャパシティを多く消費しており、キャッシュの有力な候補です。 出力例 通常のトラフィック下で稼働する EC サイトアプリケーションを考えてみましょう。コマンドは次のような出力を返す可能性があります。 ----------------------------------------------------------- | DescribeDimensionKeys | +--------+------------------------------------------------+ | Load | SQL | +--------+------------------------------------------------+ | 0.42 | SELECT p.id, p.name, p.price, c.name AS category, ... | | 0.18 | SELECT u.id, u.name, u.email, u.preferences FROM ... | | 0.09 | SELECT r.region_code, r.tax_rate, r.currency FROM ... | | 0.02 | SELECT COUNT(*) FROM orders WHERE status = ? | +--------+------------------------------------------------+ 最初の 3 つのクエリはキャッシュの有力候補です。商品カタログの結合 ( db.load.avg 0.42)、ユーザープロファイルの参照 (0.18)、地域別税率の取得 (0.09) です。これらはデータベース負荷が高く、SELECT のみであり、変更頻度の低いデータに基づいています。4 番目のクエリ (リアルタイム注文件数、0.02) は、注文のたびに結果が変わるためキャッシュすべきではありません。 良い候補の判断基準 シグナル 確認すべきポイント 高い db.load.avg クエリがデータベース負荷に大きく影響を与えている。 SELECT 文 読み取りクエリのみキャッシュに適している。 安定した結果セット 選択した TTL に対してデータの変更頻度が低い。 繰り返し実行 1分間に何度も呼び出される。頻度が高いほど効果が大きい。 候補を特定したら、 /* CACHE_PARAM(ttl=<duration>) */ の形式でヒントを追加します。残りは Remote Query Cache Plugin が処理します。 前提条件 開始前に以下を確認してください。 Amazon ElastiCache for Valkey サーバーレスキャッシュ (推奨)、セルフマネージド ElastiCache Valkey クラスター、またはセルフマネージド Valkey キャッシュ。 AWS Advanced JDBC Wrapper 4.0.1 以降。 PostgreSQL、MySQL、または MariaDB を JDBC で使用するアプリケーション。 Amazon ElastiCache Serverless はインフラ管理不要で自動スケーリングと高可用性が組み込まれているため推奨です。 Remote Query Cache Plugin によるキャッシュの設定 Remote Query Cache Plugin の有効化には、ドライバー依存関係の追加、接続の設定、キャッシュ対象クエリへの SQL クエリヒントの追加の 3 ステップが必要です。 ステップ 1: AWS Advanced JDBC Wrapper 依存関係の追加 まず、Maven 設定にラッパー依存関係を追加します (Gradle もサポートされています)。 Maven: <dependency> <groupId>software.amazon.jdbc</groupId> <artifactId>aws-advanced-jdbc-wrapper</artifactId> <version>4.0.1</version> </dependency> Gradle: implementation 'software.amazon.jdbc:aws-advanced-jdbc-wrapper:4.0.1' ステップ 2: キャッシュ接続の設定 データベース接続設定を更新して Remote Query Cache Plugin を有効にします。フレームワークによって設定が若干異なります。 Spring Boot の例 (application.yml): spring: datasource: url: jdbc:aws-wrapper:postgresql://<DATABASE_CONNECTION_STRING> wrapperPlugins: remoteQueryCache cacheEndpointAddrRw: <VALKEY_ENDPOINT> cacheUseSSL: true username: <DB_USER> password: <DB_PASS> jpa: properties: hibernate: use_sql_comments: true # Required to enable SQL hints データベース認証: この例ではプレースホルダーとしてユーザー名とパスワードを使用しています。AWS Advanced JDBC Wrapper は IAM データベース認証や AWS Secrets Manager など複数の認証方法をサポートしています。詳細は Secrets Manager Plugin を参照してください。 主な設定プロパティ: wrapperPlugins=remoteQueryCache : Remote Query Cache Plugin を有効にします。 cacheEndpointAddrRw : 読み書き操作用の Amazon ElastiCache エンドポイント。 cacheName : Amazon ElastiCache クラスター名 (IAM 認証用)。 cacheUsername : キャッシュのユーザー名 (Amazon ElastiCache Serverless の場合は default を使用)。 cacheIamRegion : IAM 認証用の AWS リージョン。 cacheUseSSL=true : アプリケーションと ElastiCache 間の転送中データに TLS 暗号化を有効にします。すべてのデプロイで true に設定してください。 ステップ 3: 対象クエリへの SQL ヒントの追加 キャッシュ対象のクエリに TTL (time-to-live) 付きの SQL ヒントを追加してマークします。構文は SELECT 文の先頭に /* CACHE_PARAM(ttl=<duration>) */ を付けます。 Spring Data: @Repository public interface ProductRepository extends JpaRepository<Product, Long> { @Query(value = "SELECT * FROM products WHERE category_id = :categoryId AND active = true", nativeQuery = true) @QueryHints({ @QueryHint(name = org.hibernate.jpa.QueryHints.HINT_COMMENT, value = "CACHE_PARAM(ttl=300s)") }) List<Product> findActiveProductsByCategory(@Param("categoryId") Long categoryId); } Remote Query Cache Plugin のドキュメント に、Hibernate と Spring Data の追加例が掲載されています。 OpenTelemetry によるパフォーマンスモニタリング Remote Query Cache Plugin は AWS Distro for OpenTelemetry (ADOT) Collector を通じてキャッシュメトリクスを送信するよう設定できます。ヒット数とミス数、バイパスイベント、ヘルスチェックステータスを取得でき、キャッシュの効果をリアルタイムに把握できます。分散トレーシングを有効にして、クエリがキャッシュとデータベースのどちらにアクセスしたかも確認できます。プラグインは Remote Query Cache Plugin テレメトリドキュメント と テレメトリ設定ガイド に記載の方法で AWS X-Ray にトレースを転送します。 図 2: OpenTelemetry 経由で収集されたキャッシュヒット/ミスメトリクス、ヘルスチェック、クエリパフォーマンスを表示する Amazon CloudWatch ダッシュボード セキュリティの考慮事項 本ソリューションは AWS 責任共有モデル に従います。AWS が ElastiCache と RDS/Aurora の基盤インフラストラクチャを保護します。アクセス制御の設定、暗号化の有効化、認証情報の管理はお客様の責任です。 転送中の暗号化 : 接続 URL で cacheUseSSL=true を設定し、アプリケーションと ElastiCache 間の全トラフィックを暗号化します。 保管時の暗号化 : Amazon ElastiCache Serverless はデフォルトで保管時の暗号化が有効です。ノードベースのクラスターでは、作成時に AtRestEncryptionEnabled=true を設定します。 ElastiCache の IAM 認証 : 静的パスワードの代わりに IAM 認証を使用するには、接続 URL で cacheIamRegion と cacheName を設定します。アプリケーションの IAM ロールに以下のポリシーをアタッチします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "elasticache:Connect", "Resource": "arn:aws:elasticache:REGION:ACCOUNT_ID:serverlesscache:CACHE_NAME" } ] } Performance Insights CLI 用の IAM 権限: aws pi describe-dimension-keys と aws rds describe-db-instances コマンドには以下の最小権限が必要です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "pi:DescribeDimensionKeys", "rds:DescribeDBInstances" ], "Resource": [ "arn:aws:rds:REGION:ACCOUNT_ID:db:INSTANCE_ID", "arn:aws:pi:REGION:ACCOUNT_ID:metrics/rds/RESOURCE_ID" ] } ] } クリーンアップ テスト用に Amazon ElastiCache for Valkey クラスターを作成した場合、継続的な課金を避けるため ElastiCache コンソール または AWS CLI で削除してください。キャッシュを削除すると、キャッシュされた全データが完全に削除されます。新しいキャッシュをプロビジョニングするまで、アプリケーションはデータベースへの直接クエリにフォールバックします。 コード変更を元に戻すには: 接続 URL から wrapperPlugins=remoteQueryCache とキャッシュパラメータを削除します。 クエリから /* CACHE_PARAM(ttl=...) */ ヒントを削除します。 他の Wrapper プラグインを使用していない場合、ビルド設定から Wrapper 依存関係を削除します。 まとめ 本記事では、最小限のアーキテクチャ変更でデータベース負荷を削減しアプリケーションパフォーマンスを向上させる自動クエリキャッシュの方法を紹介しました。 AWS Advanced JDBC Wrapper Remote Query Cache Plugin を設定して Amazon ElastiCache for Valkey と通信し、SQL ヒントを使用してキャッシュ対象クエリをマークします。キャッシュの検索、シリアライゼーション、コネクションプーリング、認証、障害時の安全なフォールバックはすべて自動的に管理されます。繰り返しの読み取りクエリを Amazon ElastiCache にオフロードすることで、書き込みが多い処理やレイテンシーが重要なオペレーション用にデータベースキャパシティを確保できます。 まず、Aurora または RDS インスタンスで Amazon CloudWatch Database Insights を使用し、データベース負荷による上位 SELECT クエリを特定してください。本記事の aws pi describe-dimension-keys コマンドを実行して候補を洗い出します。次に、最も負荷の高い候補に /* CACHE_PARAM(ttl=<duration>) */ ヒントを追加し、ラッパーを設定してアプリケーションをデプロイします。PostgreSQL 直接接続、AWS JDBC Wrapper、Remote Query Cache Plugin のクエリレイテンシーを並べて比較するには、GitHub の jdbc-caching-demo サンプル をお試しください。 著者について Qu Chen Qu は、AWS クラウドテクノロジーとインメモリデータベースサービスの技術エキスパートであるシニアソフトウェア開発エンジニアで、Amazon ElastiCache for Valkey/Memcached と Amazon MemoryDB の構築・保守を担当しています。Valkey オープンソースコミュニティのアクティブなコントリビューターとして、キャッシュを活用した低レイテンシーアプリケーションの構築に関する講演やブログ記事の執筆を行っています。 Puneet Rawal Puneet は、シカゴを拠点とする AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトで、エンタープライズのお客様による AWS でのデータベースワークロードの設計、移行、最適化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

本稿は、日本取引所（以下「JPX」）グループの戦略的なデータ・デジタル事業を担う株式会社 JPX 総研による「生成 AI で“探せなかった開示情報”を見つけ出す 〜 JPX の AI 開示情報検索サービス J‑LENS 〜」について、アーキテクティングと開発をリードされた 太子 智貴 様に寄稿いただきました。 イントロダクション 上場企業が日々開示する適時開示情報は投資家による投資判断だけでなく、企業担当者における同業他社分析・市場動向の把握に活用される重要な情報源となっています。一方で、この開示資料の量は膨大であり、年間で 10 万ページ規模にのぼる情報の中から、関心のあるテーマや企業に関する記載を素早く見つけるのは容易ではありません。加えて、開示資料は年々増加・高度化しており、投資家や企業担当者にとって「必要な情報にいかに早く、正確に辿り着けるか」は大きな課題となっています。 従来型のキーワード検索では、表記ゆれやあいまいな表現、否定形を含む記載などを適切に拾いきることが難しいケースも少なくありません。 こうした課題を解決するため、JPX では、生成 AI を活用した AI 開示情報検索サービス 「 J-LENS（ジェイ・レンズ） 」 を開発しました。 本記事では、J-LENS の背景、仕組み、技術的な工夫、そして今後の展望について紹介します。 会社・サービス紹介 日本取引所グループ（JPX）は、東京証券取引所・大阪取引所などを運営し、日本の金融市場インフラを支えています。その中で 株式会社 JPX 総研 は、データとテクノロジーを軸に、市場参加者の利便性向上や新たな付加価値創出を目的としたサービス開発を担っています。 今回紹介するサービスの J-LENS は、この JPX 総研が中心となり開発した、 上場企業の適時開示情報等（TDnet 開示情報）を対象とした AI 検索サービス です。 J-LENS を使ってみる 課題 日本市場に関心のある投資家が上場企業について理解を深めようとする際、参照すべき情報は多岐にわたります。決算短信を始めとした財務データ、製品情報等のニュース、株主や投資家向けの決算説明資料、業績予想等の適時開示資料など、企業に関する情報は豊富に存在している一方で、それらは複数の開示資料に分散しています。 そのため、投資家は「この企業の成長領域は何か」「直近の業績変化の要因は何か」「事業上のリスクはどこにあるのか」といった関心に応じて、複数の資料を横断的に確認し、必要な情報を探し出す必要があります。 しかし、従来の検索手法では、適切なキーワードを自分で考え、検索結果から関連する資料を選び、さらに資料内の該当箇所を読み解く必要があります。また、同じ意味を持つ用語でも、「TOB」と「公開買付け」のように資料によって表記が異なる場合があり、検索語の選び方によっては必要な情報を見落としてしまう可能性もあります。 特に企業比較や過年度比較などを把握したい場合には、情報収集と整理に大きな手間がかかります。 こうした背景から、投資家が自然な問いかけを起点に、信頼できる企業情報へ効率的にアクセスし、理解を深められるような新しい情報探索体験が求められています。 ソリューション こうした「膨大で分散した開示資料から、意図に合う情報へ自然に辿り着きたい」という課題に対し、JPX 総研では生成 AI を活用した AI 開示情報検索サービス 「J-LENS（ジェイ・レンズ）」 を開発しました。 J-LENS は、ユーザーが入力した 自然な文章の質問を起点 に検索できるよう設計しており、従来のキーワード検索で生じやすい表記ゆれ等による探しづらさの低減を狙っています。 また、生成 AI による検索意図の解析により 日本語以外の入力にも対応 しており、ブラウザの翻訳機能等と組み合わせることで、海外ユーザーにも利用しやすい情報探索体験を提供します。 技術的詳細 活用した主な AWS サービス J‑LENS の基盤には、主に以下の AWS サービスを採用しています。 Amazon Bedrock 生成 AI を活用し、検索クエリの意味理解や回答生成を実施 Amazon OpenSearch Service 開示資料をベクトル化し、意味的類似度に基づく検索を実現 検索精度向上のための AI 補助処理 Step1：開示資料の収集・分割 JPXが保有するデータレイク（J-LAKE）より、決算短信やコーポレート・ガバナンス報告書などの開示資料を収集し、検索に適した単位に分割します。開示資料はページ数や構成が資料ごとに異なるため、単純な固定長分割ではなく、開示種別に応じた内容のまとまりを意識して、分割を行う必要があります。 例えば、決算短信やコーポレード・ガバナンス報告書などはページ数が多く、比較的資料構成が決まっているのでセクション単位で分割し、業績や配当予想の修正のような短い開示資料は開示単位で分割するなど、分割粒度と分割手法も資料種別に応じて切り替えており、後続の検索や要約に活用しやすい形に整えています。 Step2：生成 AI による企業・資料の分析 検索精度を高めるため、資料自体の特徴を分析し、テーマや企業属性に関するタグ情報を付与します。あわせて、各企業の事業内容や特徴に関する情報もメタデータとして整理します。これにより、本文中に明示されていない企業属性や関心テーマも検索に活用しやすくなります。 Step3：Amazon OpenSearch Service への登録 分割した本文情報に加え、フィルタリング条件や画面表示に用いるメタデータをあわせて Amazon OpenSearch Service に登録します。本文の意味情報と構造化された情報を組み合わせることで、自然文検索と条件指定の双方に対応できるようにしています。 Step4：ユーザーの自然文クエリを解析 ユーザーが入力した質問に対して、生成 AI が検索意図を解析します。例えば、対象企業、業種、期間、テーマなどを推定し、Amazon OpenSearch Service で検索しやすい形に整理します。これにより、ユーザーの質問をそのまま検索するだけではなく、検索対象を適切に絞り込むことができます。 Step5：構造化フィルタとベクトル検索の併用 検索期間、上場市場、業種、開示項目などの構造化フィルタと、意味的な近さに基づくベクトル検索を組み合わせて検索を実行します。膨大な開示資料の中から、検索意図に合う可能性の高い資料群に対象を絞り込むことで、関連性の高い結果を得やすくしています。 Step6：検索結果の整理とリランキング Amazon OpenSearch Service から取得した検索結果に対して、検索クエリとの関連性や重要語句などを踏まえて結果を整理・リランキングします。単純なベクトル検索だけでは上位に出にくい資料もあるため、AI を用いて企業名・業種・市場区分・商品名などの重要情報を検索文から抽出し、各チャンクに付与されたメタデータと照合しながら、検索結果を再評価しています。これにより、利用者の検索意図に近い結果をより高い精度で提示できるようにしています。 Step7：回答理由の提示 検索結果とともに、なぜその資料が関連すると判断されたのかを表示します。これにより、利用者は検索結果の妥当性を確認しながら、該当する適時開示資料の本文に進むことができます。また、回答だけに依存せず原文確認につなげることで、事実と異なる回答の抑制にもつなげています。 効果・成果 情報探索の効率化（“探す”から“辿り着く”へ） J-LENS により、投資家や企業担当者は、膨大な開示資料の中から関心テーマに基づく情報へ短時間で到達しやすくなりました。検索結果には資料本文へのリンク、タイトル、開示日等に加え、検索結果が選ばれた理由が提示されるため、内容確認や比較確認にかかる負荷の軽減にもつながります。 単純なベクトル検索だけでは拾いきれない“意図”への対応 開示情報の探索では、本文中の語句の近さだけでなく、「その開示を提出した企業がどのようなビジネスを行っているか」が判断材料になります。たとえば「生成 AI 関連サービスを提供する企業の業績動向」を調べる際、本文に「生成 AI」という語が含まれるかだけでは十分ではなく、システム開発、SaaS、データ分析、業務自動化といった事業領域を踏まえることで、検索意図に近い企業の開示情報を見つけやすくなります。 同様に「海外展開を強化している企業」を探す場合も、本文表現だけでなく、海外売上比率や海外子会社の有無、グローバルな製造・販売網といった企業ごとの事業特性を踏まえることが重要です。 そこで J-LENS では、各企業の事業内容や特徴を生成 AI であらかじめ分析し、検索時に開示資料本文の内容と組み合わせて評価します。さらに、ユーザーの検索クエリについても生成 AI で質問意図を解析し、検索対象となる企業群や資料群を絞り込んだうえで検索を行うことで、膨大な開示資料の中から関心により近い企業や開示情報を上位に提示しやすくしています。 “想定外の発見”と、定性的情報の横断比較を後押し 単純なキーワード一致に依存せず、文脈や意味に基づいて関連情報を抽出することで、従来の検索では見落とされがちであった情報に加え、ユーザーが事前に想定していなかった企業や観点の新たな発見にもつながります。 また、従来は人手で複数資料を読み比べる必要があった定性的な情報についても自然文で横断的な検索が可能となり、投資判断や企業分析における初動調査の効率化が期待できます。 海外ユーザーの利用性 生成 AI による検索意図の解析により、日本語以外の入力にも対応しており、ブラウザの翻訳機能等と組み合わせることで、海外ユーザーにとってもスムーズな情報探索が可能です。 今後の展望 さらなる生成 AI 活用の拡大 J-LENS は現在 β 版として公開しており、利用者からのフィードバックを踏まえながら継続的な改善を進めています。 「検索精度・回答品質のさらなる向上」、「フィルタ機能や検索履歴などの利便性向上」といったフィードバックを踏まえた改善策に加え、ユーザの検索ログ・アクセスログに鑑みたサービスの提供も予定しています。 今後提供するサービスでは、単に情報を「探す」だけでなく、検索結果を起点に企業を「比較・分析し、深く理解する」体験へと進化させていきます。 具体的には検索によって抽出された企業について、事業内容の整理や特徴の深掘り、業界内での位置づけの可視化、類似企業との比較といった分析を可能とすることで、従来は人手に依存していた企業分析プロセスを高度化し、意思決定をより効率的に支援することを目指します。 これらの分析知見の抽出や整理にも生成 AI を活用することで、ユーザーが自然な問いかけを通じて開示検索をきっかけにより深い企業理解を得られる環境の実現を目指します。 執筆者 J-LENS 開発担当（左から、株式会社 JPX 総研 フロンティア戦略部 斎藤裕哉、三村優里香、IT ビジネス部 太子 智貴）

本ブログは、 株式会社テイツー 様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 AWS 上に既にあるリソースを別のシステムの一部として活用しよう、というアイデアを思いつくことは頻繁にあるかと思います。しかし実現に向けたアクションとなると、連携方式の選定や既存システムへの影響評価など検討すべきことが山積し断念、気がつくと巨大で複雑な連携システムが出来上がっていた･･･こんな経験はありませんか。テイツーはこの課題をクラウドの特徴を捉えたシンプルな設計判断で乗り越え、わずか約 3 ヶ月での新サービスリリースを実現しました。 このブログでは既存の AWS 資産を活用した新サービス創出までのアプローチと、リユース業界における店舗 DX の取り組みについてご紹介します。 株式会社テイツー（以下、テイツー）は、「古本市場」「ふるいち」「トレカパーク」などのリユース店舗を全国 180店舗（執筆時点）展開する東証スタンダード上場企業です。同社はトレーディングカードの読取査定機「 TAYS 」の開発・運用を通じて、 AWS の活用を進めてきました。テイツーはこの TAYS の AWS 基盤を活かし、店舗向け POP 自動生成サービス「POP×THREE」をわずか約 3 ヶ月で開発・リリースしました。 リユース業界における店舗運営の課題 テイツーは 1989 年の創業以来、書籍、家庭用テレビゲーム、トレーディングカード、ホビー、スマートフォン、CD、DVD、衣類など幅広いカテゴリのリユース品を取り扱い、「家族で楽しめる廉価な娯楽の提供」を事業の柱としてきました。近年はトレーディングカード市場の拡大に伴い、トレカ読取査定機「TAYS」を自社開発し、BtoB サービスとして外販するなど、テクノロジーを活用した事業展開にも積極的に取り組んでいます。 一方で、リユース業界特有の課題として、商品の買い取り価格が市場動向に応じて日々変動するという点があります。特にトレーディングカードの分野では、新タイトルの発売や大会の開催などによって価格が大きく変動するため、店舗に掲示する買い取り告知 POP を頻繁に更新する必要があります。 これまでは全店舗に配信する買い取り告知 POP の作成に、1 回あたり約 1〜2 時間の作業時間を要していました。主な作業内容はカードの価格変更やタイトルの入れ替えですが、告知を一から作成する場合にはさらに多くの時間がかかるケースもありました。全国の店舗に対してタイムリーに情報を届けるためには、この POP 作成業務の効率化が不可欠でした。 TAYS から POP×THREE へ – 既存 AWS 基盤を活かした新サービス構想 テイツーが運用するトレカ査定システム「TAYS」は、読み取りスキャナーと連携し AWS を中心としたクラウド上でAIによる判定、データ閲覧と編集を可能にした、トレカ買い取りに特化した基盤です。 TAYS の基盤では、Amazon Aurora MySQL を DB サーバとして採用し、Amazon EC2 上のLinux でアプリケーションを稼働させています。AWS WAFによるセキュリティ対策も施されており、全国の店舗からインターネット経由で安全にアクセスできる構成となっています。 TAYS 自身は元々、外販向けの構想や個店ごとの価格設定などを見据えて設計されていました。つまり、そのデータベースには買い取り以外にも店舗運営に必要な商品・価格情報が蓄積されており、新たなサービスを構築するためのデータ資産がすでに存在していたのです。 ここから生まれたのが「POP×THREE」です。TAYS のデータ資産とインフラ基盤を API 経由で活用し、その上にフロントエンドを構築するというアプローチで新サービスを開発できるのでは、という発想からスタートしました。実装内容をなるべく少なく、リリースを速くしたいという方針のもと、2025 年 9 月下旬に開発をスタートし、同年末には提供を開始しています。 POP×THREE のサービス概要 POP×THREE は、TAYS に蓄積された商品・価格データを活用し、店舗向けの買い取り告知 POP を効率的に作成するサービスです。商品データを一括投入し、テンプレートを活用して POP を量産するツールとして設計されています。画像認識には独自構築の画像認識モデルを用いており、カード画像の細かな違いを認識することでトレーディングカードにおけるバリアントの判定も可能となっています。 システムアーキテクチャ POP×THREE はあくまでフロントエンドとして機能し、バックエンドは既存の TAYS 基盤との連携を前提に設計されています。ここでは、TAYS の既存基盤と POP×THREE の新規構成の両方をご紹介します。 TAYS + POP×THREE 基盤 TAYS POP×THREE 構成図（一部省略） TAYS のシステム基盤は、以下の構成となっています。 ネットワーク・アクセス: Amazon Route 53 による DNS 管理、 Elastic Load Balancing (ALB) によるトラフィック分散 コンピューティング: オートスケール構成のAmazon EC2 データベース: Amazon Aurora MySQL をメインの DB サーバとして採用 ストレージ連携:カード画像・スキャン画像・OCR ログなどのデータを各サーバ間で共有。画像処理や一括データ更新を実行 セキュリティ: AWS WAF による Web アプリケーション保護 POP×THREE のワークロード増加に伴いオートスケール化とセキュリティ強化策を講じることで、TAYS は全国の店舗と本部を結ぶより堅牢なシステム基盤として安定稼働しています。 POP×THREE の構成 POP×THREE は、TAYS の資産を最大限に活かすことを念頭に、既存 AWSアカウントに同居する形で構築しました。東京リージョンの 2 つのアベイラビリティゾーンにまたがる構成で、高可用性を確保しています。 ネットワーク・アクセス:共通 ALB によるトラフィック分散 コンピューティング: Private Subnet 内に本番環境・検証環境で分離して配置 キャッシュ: Amazon ElastiCache を本番・検証それぞれに配置し、パフォーマンスを最適化。スロークエリログおよびエンジンログを CloudWatch Logs で管理 セキュリティ: WAF Charmと共通 AWS WAF による Web アプリケーション保護 ログ管理: Amazon CloudWatch Logs と Amazon Data Firehose によるログの収集・S3 への転送（本番・検証それぞれ）。AWS WAF ログ、ALB ログも Amazon S3 に保管 設定管理: AWS Systems Manager パラメータストアによる構成情報の一元管理 設計上のポイント POP×THREE の設計において最も重要な判断は、TAYS の既存データをどのように新サービスから利用するかという連携方式の選定でした。新システムを構築する際の一般的なアプローチとしては、①DB レプリカや DMS によるデータ同期、②既存システム側に専用 API を公開し新システムがそれを利用する、③既存 DB を直接参照する、といった選択肢が考えられます。 テイツーが採用したのは②のアプローチです。TAYS 側に POP×THREE 専用（連携アプリ用）の API を設置し、POP×THREE はその API を介して商品・価格データを取得する構成としました。この判断の背景には、TAYS と POP×THREE で保守を担当する開発ベンダーが異なるという事情もありました。①のレプリカ構成では DB 構造への依存が強くなり、スキーマ変更のたびに両ベンダー間で調整が発生します。DMS によるデータ同期についても、レプリケーションの複雑性と継続的なメンテナンス負荷を踏まえ、現在の運用体制では現実的ではないと判断しました。③は②の構成が取れれば必要ありません。 API を採用した最大の狙いは、システム間の責務を明確に分離し、将来的な変更や機能追加のスピードを確保することにあります。これを介することで、DB 構造変更時の影響範囲は TAYS 側に閉じ、POP×THREE 側は API の後方互換性さえ保たれていれば独立して開発・デプロイが可能です。保守ベンダーが異なっていても、調整コストを最小限に抑えながら利用者の要望に迅速に応えられる構成となっています。一方で、POP×THREE から見れば TAYS が稼働していなければデータ取得ができないという依存は残りますが、Aurora MySQL 自体の高可用性構成と、読み取りレプリカの追加による柔軟なスケーリングにより、実運用上のリスクは許容範囲と判断しました。 加えて年内リリースの方針のもと、各ベンダーがスケジュール遵守を前提に開発を進める必要がありました。API のインターフェース仕様を早期に確定させたことで、TAYS 側（API 公開）と POP×THREE 側（フロントエンド構築）の開発を並行して進められたことも、約 3 ヶ月という短期間でのリリースを支えた要因です。AWS という共通のクラウド基盤上で IAM やネットワーク設計が標準化されていたことで、異なるベンダー間の技術的な齟齬が生じにくかった点も大きく寄与しています。 導入効果 POP×THREEにより、テイツーでは以下の効果が得られています。 業務効率化 すでに POP×THREE を導入している外販先企業では、数時間単位での業務効率化につながっているとのことです。 テイツー直営店での本格利用はこれからですが、全店舗に配信する予定の買い取り告知 POP の作成業務において、運用次第では 1 枚あたり約 30 分程度の作業時間短縮が見込まれています。従来は 1 回あたり約 1〜2 時間を要していた作業であり、特に価格変更やタイトルの入れ替えといった定型的な更新作業での効率化が期待されます。 外販先での実績を踏まえ、さらなる効果が期待されています。 安定稼働とスケーラビリティ POP×THREE はサービス開始以来システムダウンを経験していません。テイツーは「クラウドの恩恵として、マネージドサービスでインフラ管理コストを下げつつも、安定稼働している」と評価しています。 スケーラビリティの面では、直近でトレーディングカードのビッグタイトルが発売され大規模な負荷が発生した際、TAYS のオートスケール対応を実施しました。常時複数台のサーバを配置する構成へ移行し、今後のさらなるトラフィック増加にも対応できる体制を整えています。 AWS の活用メリット テイツーが AWS を活用する中で特に評価しているのは、以下の点です。  複数ベンダーとの円滑な連携: POP×THREE の開発では複数の開発ベンダーに依頼しましたが、AWS という認知度の高い基盤があったことでスムーズに連携を行うことができました 適切なサービス選択の提案: AWS からの技術支援により、要件に合った適切なサービスの選択を行うことができました クラウドの安定性: お客様向けサービスの基盤として、高い可用性と安定稼働を実現しています テイツー様からのコメント 「当社として本件は単なるシステム導入事例ではなく、AWS ならではのスピーディーな立ち上げとして対外的に発信できるテーマだと考えています。 トレカ査定システム TAYS の開発・運用を通じて培った AWS 基盤を最大限に活用することで、POP×THREE を約 3 ヶ月という短期間で立ち上げることができました。既存の RDS を活用し、フロントエンドの開発に集中するというアプローチは、実装をなるべく速く、少なくしたいという当社の方針に合致するものでした。また、AWS からの適切なサービス選択の提案により、限られたリソースの中でも最適なアーキテクチャを構築できたと感じています。 本取り組みは、既存データ資産を活用し小さく始めることで再現可能なモデルであり、AWS の各サービスの機能を利用して継続的に最適化できる点も大きな強みです。 システムの安定稼働はお客様へのサービス品質に直結するものであり、クラウドの恩恵を日々実感しています。今後も AWS の技術を活用し、リユース業界における店舗 DX をさらに推進してまいります。」 — 株式会社テイツー 情報システム部マネジャー 野口 義弘 様 今後の展望 テイツーでは、POP×THREE の展開をさらに加速させるとともに、AWS 基盤の強化を進めていく計画です。現在は TAYS が公開する API を介したデータ連携により運用していますが、導入先の拡大に伴うトラフィック増加に備え、Aurora の読み取りレプリカ追加やキャッシュ戦略の見直しも視野に入れています。さらに、中長期的には API の拡充やイベント駆動型の連携導入により、TAYS と POP×THREE それぞれが独立してスケール・進化できるアーキテクチャへの発展を段階的に進める方針です。直営店についてはこれから POP×THREE の利用を本格化させる段階であり、現場からのフィードバックを得ることで今後の展開を検討していく予定です。 テイツーの取り組みは、既存の AWS 基盤を活かして新たなサービスを迅速に立ち上げるという、クラウド活用の好例です。リユース業界における店舗 DX の推進に向けて、テイツーの挑戦は続きます。

みなさん、こんにちは。ソリューションアーキテクトの市川、井上、新澤、川﨑です。この記事では、 AWS Summit Japan 2026 で AWS IoT サービスを利活用した展示の一部をご紹介します。各ブースで表示している資料もこちらに掲載予定です。 AWS IoTで実現するロボット遠隔テレオペレーション体験 (A026) Physical AIの分野では、データ収集、モデルのトレーニング、シミュレーション、現実世界への反映というサイクルを回す必要があります。このデモでは、AWSのIoTサービスを使ってデータ収集をする方法について展示を行っています。コントローラーでセイコーエプソンさんのロボットを操作し、エッジデバイス上のAWS IoT GreengrassからAWS IoT CoreやS3にデータを保存する様なアーキテクチャを紹介します。 赤枠がブースのおおよその展示場所を示しています。 図1：A026展示場所 AIエージェントで実現するスマートマシン -産業機械の自律診断とリアルタイム安全監視-(A162) このブースでは、AWS上に構築されたエージェント型の産業機械保全ワークフローをご紹介します。AIエージェントが故障を自律的に診断し、現場オペレーターへの通知からサポートへのエスカレーションまでを一気通貫で実行する様子をご覧いただけます。エッジAIによる安全監視、計画外ダウンタイムの削減、インシデント対応の迅速化など、建設・製造・農業・鉱業の各現場における機器管理・保守を変革する次世代のフィールドオペレーションを、ぜひブースでご体験ください。 赤枠がブースのおおよその展示場所を示しています。 図2：A162 と A026 展示場所 Physical AIへの第一歩 AWS IoTで実現するPhysical AI基盤 (A161) Physical AIの実現には、クラウドで学習したAIモデルをエッジデバイスにデプロイし、エッジデバイスのセンサーデータをクラウドに送信するための安定した基盤が不可欠です。本ブ ースでは、AWS IoT Core , AWS IoT Greengrass , Amazon Kinesis Video Streams などを用いてデバイス接続からエッジコンピューティング、映像配信を Raspberry PiやJetsonを利用したライブデモで体験いただけます。A/Bデプロイやロールバック等の本番運用機能、生成AI活用に関してもご紹介させていただきます。IoT をこれからはじめる方からエッジAI検討中の方まで、Physical AIへの第一歩をここから踏み出してください。 赤枠がブースのおおよその展示場所を示しています。 図2：A162 と A026 展示場所 builders’ Fair： クラウドVLAが操るミニロボたち ミニロボたちがクラウドベースのVLAで自律的に考えて卓上のフィールドを動き回ります。荷物・障害物・危険エリアなどをAIが見て判断し、複数のミニロボが「何を運ぶ？」「どこに片付ける？」「どう分担する？」「こっち危ないから回り道しよう」と自分たちで動きます。来場者の皆さんもぜひ障害物を置いたり、荷物を散らかしたりしてください。ミニロボたちは協力しながらタスク完遂を目指します。さて、ミニロボたちはちゃんとやりとげることができるか？温かい目で見守ってください！ 赤枠がブースのおおよその展示場所を示しています。 図3：展示場所 インダストリブース：AWS認定デバイスウォール(A017) 昨年のAWS Summit Japan 2025 でご好評いただいた AWS Summit Japan 2025 での AWS 認定デバイスウォール展示のご紹介 が今年も登場します！ エッジデバイスとクラウドを連携させるニーズが高まる中、多様なエッジデバイスから最適なものを選ぶことはお客様にとって課題となっています。 AWS 認定デバイスプログラム は、AWSのIoTサービスとの接続が検証された信頼性の高いデバイスを取りそろえたプログラムです。本展示では、認定デバイスを通じてプログラムの価値とハードウェアパートナーとの協力体制を紹介し、日本国内におけるエッジとAWSを活用したサービス構築の迅速化とビジネスの加速を支援します。 AWS Summit Japan 2026 製造業向け展示の見どころ紹介！ でもブース情報記載しておりますのでご確認ください。 赤枠がブースのおおよその展示場所を示しています。 図4：A017展示場所 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。 新澤 雅治 IoT スペシャリスト ソリューションアーキテクト 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様の Industrial IoT 関連案件の支援に携わる。 井上 昌幸 IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。あなたのとっておきのアイデアを AWS と一緒にカタチにしましょう。 川﨑 裕希 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。IoTやエッジデバイスに興味があり、エッジ推論の検証が最近の趣味です。 <!-- '"` -->

本記事は 2026 年 5 月 11 日 に公開された「 Amazon Aurora DSQL connections: Drivers, strings, and best practices 」を翻訳したものです。 Amazon Aurora DSQL への初めての接続を設定しようとしていますか? PostgreSQL を使ったことがあれば流れは似ていますが、いくつか重要な違いがあります。長期間有効なパスワードの代わりに、 短命の IAM 認証トークン を使用します。静的なエンドポイントの代わりに、複数のアベイラビリティゾーンにまたがる分散クラスターエンドポイントを使用します。接続タイムアウトのトラブルシューティング、トークンの有効期限管理、ドライバーの初回設定など、接続パターンを理解しておくと一般的な問題を回避できます。 本記事では、接続文字列の設定方法、Python・Java・Node.js でのドライバー設定、認証・接続プーリング・ライフサイクル管理のベストプラクティスについて説明します。 接続アーキテクチャ Amazon Aurora DSQL は、従来の PostgreSQL デプロイとは根本的に異なる分散接続アーキテクチャを採用しています。アプリケーションは単一のデータベースインスタンスに接続するのではなく、複数のアベイラビリティゾーンにトラフィックを分散するルーティングレイヤーを介して接続します。ドライバーや接続文字列を設定する前に、エンドポイントの構造とワイヤプロトコルの動作を理解しておく必要があります。以下のセクションでは、接続前に知っておくべきエンドポイント形式とワイヤプロトコルの互換性について説明します。 エンドポイント形式 Amazon Aurora DSQL クラスターのエンドポイントは次のパターンに従います。 &lt;cluster-id&gt;.dsql.&lt;region&gt;.on.aws 例: weaxxxxxxxxxxxxxxxxqdqqm.dsql.us-east-1.on.aws デュアルスタック形式で、IPv4 と IPv6 の両方をサポートしています。エンドポイントは Aurora DSQL の分散ルーティングレイヤーに接続し、複数のアベイラビリティゾーンへの接続分散を自動的に処理します。 主要な接続パラメータ: Host: クラスターエンドポイント (上記の形式)。 Port: 5432 (PostgreSQL 標準ポート)。 Database: postgres (デフォルトのデータベース名)。 SSL Mode: すべての接続で必須。 ワイヤプロトコルの互換性 Amazon Aurora DSQL は標準の PostgreSQL v3 ワイヤプロトコルを使用しており、psql、pgjdbc、psycopg、psycopg2 などの一般的な PostgreSQL ドライバーとの互換性があります。既存のツールやライブラリは、最小限の設定変更で利用できます。 認証とセキュリティ Aurora DSQL では、従来の PostgreSQL データベースとは異なる認証方式とネットワークセキュリティを採用しています。以下のセクションでは、IAM ベースのトークン生成、ネットワーク接続オプション、認証情報管理のベストプラクティスについて説明します。 IAM ベースの認証 Amazon Aurora DSQL は短命の IAM 認証トークンのみを使用します。IAM 認証には以下のセキュリティ上の利点があります。 セキュリティの強化: パスワードの保存やローテーションに伴うリスクを軽減します。 アクセス制御の一元化: AWS Identity and Access Management (AWS IAM) による統一的な権限管理が可能です。 監査証跡: 接続試行が AWS CloudTrail に記録されます。 自動期限切れ: トークンはデフォルトで 15 分後に期限切れになります (最大 1 週間まで設定可能)。デフォルトを超える有効期間の延長は推奨しません。漏洩した長命トークンは重大なセキュリティリスクです。延長が必要な場合は、トークンのスコープを最小限の権限に絞り、CloudTrail で長命トークンを監視してください。 アクセス制御パターンとセキュリティのベストプラクティスの詳細については、 Amazon Aurora DSQL のセキュリティ対策：アクセス制御のベストプラクティス を参照してください。 AWS Command Line Interface (AWS CLI) でのトークン生成: 以下のコマンドで、AWS CLI を使用して Aurora DSQL クラスターの認証トークンを生成します。 aws dsql generate-db-connect-admin-auth-token \ --region us-east-1 \ --hostname &lt;your-cluster-id&gt;.dsql.us-east-1.on.aws 必要な IAM 権限: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": "arn:aws:dsql:region:account-id:cluster/cluster-id", "Condition": { "IpAddress": { "aws:SourceIp": ["10.0.0.0/8"] } } } ] } dsql:DbConnect: 通常のデータベースユーザーとしての接続権限を付与します。 dsql:DbConnectAdmin: 管理者権限を付与します。 最小権限の原則 ユースケースごとに必要最小限の権限のみを付与します。 標準のアプリケーションアクセスには dsql:DbConnect を使用します。 dsql:DbConnectAdmin は管理タスク専用に限定します。 既知のネットワーク範囲のみにアクセスを制限するため、IP ベースの 条件 を追加します。 ネットワークセキュリティ Amazon Aurora DSQL はパブリックアクセスとプライベートアクセスの両方をサポートしています。 パブリックエンドポイントアクセス は以下によりセキュリティを確保します。 IAM ベースの認証 – パスワードベースの脆弱性を軽減します。 IP ベースのアクセス制御 – IAM ポリシー条件により接続を制限します。 SSL/TLS 暗号化の必須化 – 暗号化されたトランスポートが必須です。 プライベートエンドポイントアクセス (AWS PrivateLink) はトラフィックを AWS 内に保持します。 VPC インターフェイスエンドポイント – インターネットに公開されないプライベート接続。 VPC エンドポイントポリシー – ネットワークレベルの追加のアクセス制御。 セキュリティグループ – 特定のサブネットとポートへのトラフィックを制限。 VPC エンドポイントポリシーをアタッチして、エンドポイント経由で接続できるプリンシパルを制限します。設定しない場合、VPC 内のすべてのプリンシパルがエンドポイントを使用してクラスターに接続できます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::account-id:role/your-app-role" }, "Action": [ "dsql:DbConnect" ], "Resource": "arn:aws:dsql:region:account-id:cluster/cluster-id" } ] } ネットワークエグレス制御 インバウンドアクセスの制御だけでは不十分です。エグレス制限がなければ、侵害されたアプリケーションが外部にデータを送出する可能性があります。アプリケーションホストからのアウトバウンドトラフィックを制限してください。 セキュリティグループのアウトバウンドルール – 必要な宛先 (Aurora DSQL のポート 5432、AWS サービスエンドポイントなど) へのトラフィックのみを許可します。 VPC Network ACLs – セカンダリレイヤーとしてサブネットレベルのエグレス制限を追加します。 VPC Flow Logs – 予期しないアウトバウンドトラフィックパターンを監視します。 AWS Network Firewall – セキュリティグループを超えた、きめ細かいエグレスフィルタリングに使用します。 認証情報の管理 Aurora DSQL に接続する際の認証情報管理のベストプラクティスを以下に示します。 認証情報をハードコードしない – アプリケーションコードに埋め込まないでください。 環境変数を使用する – ホスト名やリージョンなどの設定値には環境変数を使用します。 トークンを動的に生成する – 接続時に AWS SDK 呼び出しでトークンを生成します。 AWS Secrets Manager を使用する – 接続設定の保存に利用します。 IAM 認証情報を定期的にローテーションする – AWS のセキュリティベストプラクティス に従います。 認証試行を監視する – CloudTrail による異常検知 を活用します。 認証トークンをログに記録・永続化しない – トークンはデータベースパスワードとして渡されるため、接続文字列ログ、アプリケーションログ、エラーメッセージに漏洩する可能性があります。ロギングフレームワークでパスワードフィールドを確実にマスクし、URL や診断出力にトークンを含めないでください。 接続の監視 CloudTrail はすべての Aurora DSQL 認証イベントを記録します。異常な接続アクティビティを検知するアラートを設定してください。 認証失敗 – DbConnect または DbConnectAdmin の繰り返し失敗に対して Amazon CloudWatch アラームを作成し、認証情報の悪用や設定ミスを検知します。 予期しない送信元 IP やリージョン – CloudTrail イベントを sourceIPAddress と awsRegion でフィルタリングし、想定外のネットワーク範囲からの接続をフラグ付けします。 異常な接続パターン – CloudWatch 異常検知を使用して、接続量の急増や通常の運用時間外の接続を監視します。 長命トークンの使用 – 要求された有効期間がデフォルトの 15 分を超える GenerateDbConnectAdminAuthToken 呼び出しを追跡します。 自動対応として、CloudTrail イベントの Amazon EventBridge ルールを使用して、 Amazon Simple Notification Service (Amazon SNS) 通知や AWS Lambda による修復ワークフローをトリガーできます。 SSL/TLS の設定 Amazon Aurora DSQL は接続に暗号化トランスポートを必須としています。 sslmode=require – 暗号化の最小要件。 sslmode=verify-full – 完全な証明書検証とホスト名検証によるセキュリティ強化。 本番環境の推奨事項: verify-full モードを使用してください。証明書チェーンとホスト名の両方を検証し、中間者攻撃への対策となります。 Amazon Aurora DSQL コネクター AWS は Amazon Aurora DSQL コネクターを提供しています。コネクターは透過的な認証レイヤーとして機能し、IAM トークンの生成とリフレッシュを自動的に処理します。認証コードではなく、接続コードだけを記述すれば済みます。 利用可能なコネクター JDBC Connector – 標準の Java データベース接続レイヤーに IAM 認証を統合し、既存の Java データアクセスフレームワークとシームレスに連携します。 Python Connector – psycopg、psycopg2、asyncpg (非同期ワークロード) をサポートします。認証プラグインとして動作し、既存の接続ワークフローを変更せずにトークン生成を処理します。 Node.js Connectors – node-postgres (pg) と Postgres.js の両方に対応しています。 Go Connector – pgx をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。 Ruby Connector – Ruby アプリケーション向けの IAM ベース認証を提供します。 .NET Connector – Npgsql をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。 Rust Connector – SQLx をラップし、IAM 認証の自動処理、SSL 設定、接続管理を行います。 実装の詳細については、 Amazon Aurora DSQL Connectors GitHub を参照してください。 コネクター使用の利点 トークン管理の自動化 – クラスターホスト名からのリージョン自動検出を含む、IAM トークン生成とリフレッシュのライフサイクル全体を管理します。 シームレスな統合 – 接続プーリングライブラリ (HikariCP、psycopg ConnectionPool、psycopg2 ThreadedConnectionPool、asyncpg ネイティブプール) と透過的に連携します。 フレームワークサポート – Spring Boot、Django など、標準的なデータベースドライバーインターフェイスに依存するフレームワークと互換性があります。 ボイラープレートの削減 – 手動のトークン生成コードの記述やメンテナンスが不要です。 クイックスタート例 (JDBC コネクター) 以下の例は、Java で JDBC コネクターを使用して Aurora DSQL クラスターに接続する方法を示しています。コードを実行する前に、プロジェクトの依存関係に Aurora DSQL JDBC ドライバーを追加し、IAM 認証情報を設定済みであることを確認してください (環境変数、インスタンスプロファイル、または AWS 認証情報ファイルのいずれか)。JDBC URL に jdbc:aws-dsql:// プレフィックスを設定し、 DriverManager.getConnection を呼び出します。コネクターが IAM トークン生成を自動的に処理するため、手動のトークンコードは不要です。コネクターは、トークンを長期間キャッシュするのではなく、新しい接続または接続プールの初期化ごとに新しいトークンを生成します。 // Change the JDBC URL prefix to jdbc:aws-dsql:// String url = "jdbc:aws-dsql://" + clusterEndpoint + ":5432/postgres"; Connection conn = DriverManager.getConnection(url, "admin", ""); // No password needed — the connector handles token generation automatically 手動接続パターン コネクターを使用しない場合 (学習目的、デバッグ、カスタム認証フローなど) は、AWS SDK で IAM トークンを手動で生成し、データベースパスワードとして渡せます。 接続には最低限 sslmode=require が必要です。トークンは、呼び出し元の IAM アイデンティティから派生し、特定のクラスターホスト名にスコープされた、有効期限付きの認証情報です。 SDK トークン生成メソッド Python (boto3) generate_db_connect_admin_auth_token Java DsqlClient.generateDbConnectAdminAuthToken Node.js GenerateDbConnectAdminAuthTokenCommand Go dsql.GenerateDbConnectAdminAuthToken Ruby Aws::DSQL::Client#generate_db_connect_admin_auth_token .NET AmazonDSQLClient.GenerateDBConnectAdminAuthToken Rust dsql::Client::generate_db_connect_admin_auth_token 生成したトークンを、接続確立時にデータベースパスワードとして渡します。 完全なコード例については、 Amazon Aurora DSQL ユーザーガイド と Amazon Aurora DSQL Code Samples を参照してください。 接続プーリング 適切に設定された接続プーリングは、レイテンシーを低減し、Aurora DSQL の接続レート制限への到達を回避します。本セクションでは、プールの設定、サイジング、考慮すべき主要な制約について説明します。 クライアント側プーリングが必須 Aurora DSQL にはサービスレイヤーでの組み込み接続プーリングがありますが、新しい接続ごとに TLS ハンドシェイクとサービスによる認証が必要です。接続をプールすれば、そのコストをリクエストごとではなく一度だけ支払えばよくなります。 PgBouncer や pgpool-II などのサーバー側コネクションプーラーは使用しないでください。 これらのツールは従来の PostgreSQL アーキテクチャ向けに設計されており、Amazon Aurora DSQL の分散接続処理で可用性の問題を引き起こす可能性があります。 プール設定 最も重要なパラメータは 最大接続寿命 です。Amazon Aurora DSQL は接続期間に 60 分のハードリミットを適用します。プールの最大ライフタイムを 45〜55 分に設定し、Aurora DSQL が接続を切断する前にプロアクティブにリサイクルしてください。 Java で HikariCP を使用する場合は、 maximumPoolSize 、 maxLifetime (60 分未満) を設定し、手動のトークン管理を避けるために JDBC Connector を使用します。HikariCP の完全な設定については、公式ガイド「 Using Amazon Aurora DSQL with JDBC, Hibernate, and HikariCP 」を参照してください。 Python の場合は、手動で生成した IAM トークンを使用して psycopg2 で接続するか ( Amazon Aurora DSQL ユーザーガイド – Psycopg2 の使用 を参照)、 Amazon Aurora DSQL Python Connector (GitHub) を使用してトークンのボイラープレートを完全に排除できます。 接続制限とクォータ 接続プールのサイジングを決定する前に、Amazon Aurora DSQL の接続制限を理解しておく必要があります。Amazon Aurora DSQL は接続作成レートの制御に トークンバケットアルゴリズム を使用しています。新しい接続ごとにトークンを 1 つ消費し、バケットは一定レートで補充されます。バケット容量を上限としてバーストも可能です。 クラスターあたりのデフォルト制限は以下のとおりです。 クォータ デフォルト値 備考 最大確立接続数 10,000 クラスターごとの制限。Service Quotas で調整可能 新規接続レート (定常状態) 100 接続/秒 トークンバケットの補充レート バースト容量 1,000 接続 補充前の t=0 時点で利用可能なトークン数 最大接続期間 60 分 ハードリミット。1 時間後に接続切断 最大トランザクション期間 5 分 トランザクションごと (BEGIN から COMMIT まで) トークンバケットの実際の動作: アプリケーション起動時に 1,000 接続を開いた場合、すべて成功します (バーストトークン 1,000 個)。ただし、バケットは空になります。1,001 番目の接続は、バケットが 100 トークン/秒で補充されるのを待つ必要があります。クライアント側プーリングが重要な理由はここにあります。接続を再利用すれば、作成バジェットの消費を避けられます。 接続ライフサイクル Aurora DSQL の接続には最大ライフタイムが固定されており、有効期限付きトークンを使用するため、アプリケーションは接続のリサイクルとトークンリフレッシュを適切に処理する必要があります。 1 時間の接続制限 Amazon Aurora DSQL のすべての接続の最大ライフタイムは 60 分です。1 時間後、接続がアイドル状態でもアクティブ状態でも、サービスが接続を切断します。これは設計上の仕様です。Aurora DSQL の分散アーキテクチャでは内部コンポーネントがバックグラウンドで障害復旧や交換されるため、1 時間の制限によりアプリケーションが定期的に新しい接続を確立し、正常なインフラに自然に接続されるようになっています。Aurora DSQL は切断にジッターを適用するため、接続が同時に切断されることはなく、トランザクション中の接続は切断されません。 トークンの有効期限管理 トークンはデフォルトで 15 分後に期限切れになります (最大 1 週間まで設定可能)。重要なポイント: 有効なトークンで接続が確立された後は、トークンが期限切れになっても接続は有効なままです。新しいトークンが必要なのは新しい接続を確立するときだけであり、60 分の接続制限がバインディング制約となります。トークンの有効期限は制約になりません。 トークンはリージョンスコープでもあります。 region=us-east-1 で生成されたトークンは us-east-1 エンドポイントへの接続にのみ有効で、同じマルチリージョンクラスターの us-east-2 エンドポイントには使用できません。マルチリージョンデプロイでは、アプリケーションが接続する各リージョンエンドポイントに対して個別のトークンを生成してください。 推奨アプローチ: Amazon Aurora DSQL コネクター を使用してください。新しい接続ごとに自動的にトークンを生成するため、トークン管理コードが不要です。 接続リトライロジック 分散システムでは一時的な接続障害は例外ではなく通常の動作です。内部コンポーネントに障害が発生した場合、Aurora DSQL が自動的に処理しますが、アプリケーション側ではその接続に対するエラーが発生します。 SerializationFailure (OCC コンフリクト) と OperationalError (一時的な障害) の両方に対して、エクスポネンシャルバックオフとジッターを伴うリトライロジックを実装してください。推奨パターンについては、Amazon Aurora DSQL の同時実行制御ドキュメントと AWS Builders’ Library – タイムアウト、リトライ、ジッター付きバックオフ を参照してください。 マルチリージョン接続パターン 地理的リージョンをまたいだ高可用性が必要なアプリケーション向けに、Amazon Aurora DSQL マルチリージョンクラスターはリージョンエンドポイントで読み書き両方をサポートするアクティブ-アクティブアーキテクチャを提供します。 アクティブ-アクティブ マルチリージョンアーキテクチャ Amazon Aurora DSQL マルチリージョンクラスターは、アクティブ-アクティブアクセスのためのリージョンエンドポイントを提供します。アプリケーションはどちらのエンドポイントにも接続して読み書きが可能で、地理的な分散とリージョンフェイルオーバーを実現します。 エンドポイント選択戦略 レイテンシーのために最寄りのリージョンエンドポイントに接続し、プライマリリージョンに問題がある場合はセカンダリエンドポイントへのヘルスベースのフェイルオーバーを実装します。 フェイルオーバーロジックは事前にテストしておいてください。 一般的な接続問題のトラブルシューティング 本セクションでは、Aurora DSQL に接続する際に発生しやすいエラーや接続障害と、その原因および推奨される対処方法について説明します。認証失敗、タイムアウトエラー、ドライバーの互換性の問題のいずれの場合も、以下のガイダンスで問題を迅速に診断・解決できます。 問題 1: “Connection Attempt Failed” 症状: Amazon Aurora DSQL エンドポイントへの接続を確立できない 一般的な原因: IAM 権限の不備、認証トークンの期限切れ、ネットワーク接続の問題、エンドポイント形式の誤り 解決方法: 接続失敗を解決するには、以下の手順を順に実行してください。まず、IAM ユーザーまたはロールのポリシーに適切な dsql:DbConnect または dsql:DbConnectAdmin 権限がアタッチされていることを確認します。次に、認証トークンが期限切れでないことを確認します。トークンは短命であり、新しい接続試行のたびに再生成が必要です。クラスターエンドポイントの形式が正しいこと、ポート 5432 へのアウトバウンドトラフィックをブロックするネットワークレベルの制限 (セキュリティグループ、VPC ルーティングルール、ファイアウォールポリシーなど) がないことを確認してください。以下の例は、新しいトークンを生成して明示的なエラーハンドリングで接続を試みることで、根本原因を特定しやすくする方法を示しています。 # Verify IAM permissions aws iam get-user # Test token generation aws dsql generate-db-connect-admin-auth-token \ --region us-east-1 \ --hostname &lt;cluster-id&gt;.dsql.us-east-1.on.aws # Test network connectivity nc -zv &lt;cluster-id&gt;.dsql.us-east-1.on.aws 5432 問題 2: “Access Denied” エラー 症状: 接続は確立されるが認証に失敗する 解決方法: IAM ポリシーに dsql:DbConnect または dsql:DbConnectAdmin が含まれていることを確認します。 IAM ポリシーのアクセス制限条件 (aws:SourceIp、aws:RequestedRegion、aws:PrincipalTag など) を確認します。基本権限が付与されていても、条件によって接続がサイレントに拒否される場合があります。 トークンが正しいリージョンで生成されていることを確認します。 AWS 認証情報が期限切れでないことを確認します。 問題 3: PrivateLink 接続の問題 VPC の外部から PrivateLink 経由で接続する場合、クライアントはクラスターエンドポイントを VPC エンドポイント IP に解決する必要があります。2 つのアプローチがあります。 オプション 1: PGHOSTADDR で IP アドレスをオーバーライド export PGHOSTADDR=&lt;vpce-ip-address&gt; export HOSTNAME=&lt;cluster-id&gt;.dsql.&lt;region&gt;.on.aws psql -h $HOSTNAME -U admin -d postgres SNI に正しいホスト名を使用しながら VPC エンドポイント IP に接続します。 オプション 2: amzn-cluster-id 接続オプションを使用 (DNS 不要) export CLUSTERID=&lt;cluster-id&gt; export PGOPTIONS="-c amzn-cluster-id=$CLUSTERID" psql -h &lt;vpce-endpoint&gt; -U admin -d postgres クラスター識別子を接続オプションとして直接渡し、DNS 解決を不要にします。VPC エンドポイントのプライベート DNS が設定されていない場合に便利です。 詳細については、 PrivateLink 接続エンドポイントを使用した Amazon Aurora DSQL への接続 を参照してください。 問題 4: 接続プールのヘルスチェックストーム 症状: 負荷スパイク時の大量の接続切断と再確立、カスケード的なヘルスチェック失敗、接続レート制限エラー 原因: 短いヘルスチェック間隔 (HikariCP のデフォルト 5 秒タイムアウトなど) により、数千のプール接続に対して同時にヘルスチェックがトリガーされる場合があります。多数のチェックが同時に失敗すると、プールがすべての接続の再確立を試み、100 接続/秒のレート制限を使い果たして障害がカスケードします。 解決方法: すべての接続に固定間隔を使用するのではなく、接続間でヘルスチェック間隔をずらします。 不要な接続リサイクルを避けるため、アイドルタイムアウトを増やします。 HikariCP の場合、 connectionTimeout と validationTimeout をデフォルトより長く設定します。 maxLifetime に十分なジッターを設定します (HikariCP は自動的に ±2.5% を適用)。同期した接続期限切れを回避できます。 まとめ 本記事では、JDBC や PostgreSQL 互換クライアント、AWS CLI など、さまざまなドライバーやツールを使用して Amazon Aurora DSQL に接続する方法を紹介しました。接続アーキテクチャ、IAM ベースの認証トークンの生成と使用方法、認証情報管理と接続プーリングのベストプラクティスについて解説しました。クイックスタート例と、一般的な接続問題の診断・解決に役立つトラブルシューティングガイドも提供しました。 実際に試してみたいですか? プレイグラウンド でセットアップなしに Aurora DSQL を体験できます 。接続の操作、クエリの実行、本記事で紹介した機能の確認を実際に行えます。 著者について Alex Pawvathil Alex は、AWS のシニアテクニカルアカウントマネージャーで、データベースアーキテクチャとエンタープライズ規模の実装を専門としています。クラウドアーキテクチャ、データベース戦略、エンタープライズアドバイザリーで 14 年以上の実務経験があり、Amazon RDS for SQL Server の実装とエンタープライズ規模のデプロイメントの専門家です。 Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカウントマネージャー兼データアナリティクススペシャリストです。AWS のお客様と密接に連携し、継続的なサポートと技術ガイダンスを提供しています。ベストプラクティスを活用したソリューションの計画・構築を支援しながら、AWS 環境の運用状態をプロアクティブに健全に保つことに取り組んでいます。 Rob Petersen Rob は、AWS のシニアテクニカルアカウントマネージャーで、IT 業界での 20 年の経験を活かし、お客様のクラウド導入ジャーニーを支援しています。大規模なクラウドマイグレーションのリードとハイブリッドインフラストラクチャの運用管理の両方の経験があり、クラウド導入時に組織が直面する課題と機会について独自の視点を持っています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Arisa Izuno がレビューしました。

本記事は&nbsp; 2026 年 3 月 30 日に公開された ” Introducing CloudWatch Metrics for AWS Direct Connect Virtual Interface BGP Health and Prefix Count ” を翻訳したものです。 本日、 AWS Direct Connect は Amazon CloudWatch における 仮想インターフェイス（VIF）に関する3 つの新しいメトリクス VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised のサポートを発表しました。これらのメトリクスにより、API を手動でポーリングしたりコンソールを確認したりすることなく、CloudWatch から直接 Border Gateway Protocol（BGP）セッションの正常性とプレフィックス数を把握できるようになります。本ブログでは、新しいメトリクスの概要、ユースケース、および修復アクションをトリガーするアラームの設定方法について説明します。CloudWatch で利用可能な Direct Connect メトリクスの完全なリストについては、 Direct Connect ユーザーガイドの Amazon CloudWatch によるモニタリング を参照してください。 VIF BGP ステータスおよびプレフィックス数メトリクスの提供前 この機能が提供される前は、Direct Connect の CloudWatch メトリクスは物理接続の正常性とトラフィックスループットのみをカバーしていました。BGP セッションステータス、オンプレミスルーターから受け入れたプレフィックス数、AWS からの経路広報、サイレントな経路の消失といった BGP レベルのテレメトリについては、Direct Connect API をポーリングしたり、独自の Lambda 関数を作成したり、またはオンプレミスのネットワーク管理ツールに頼る必要がありました。 Monitor BGP status on AWS Direct Connect VIFs and track prefix count advertised over transit VIF の記事では、そのようなアプローチの一例が紹介されています。今回の新しい CloudWatch メトリクスにより、そうした複雑さは不要となり、プレフィックス数のモニタリングはトランジット VIF に限定されなくなりました。 新しいメトリクスの概要 3 つの新しい CloudWatch メトリクスは、プライベート仮想インターフェイス、パブリック仮想インターフェイス、トランジット仮想インターフェイスの 3 種類すべての VIF タイプで利用できます。 図 1 は、オンプレミスネットワークが 3 種類の仮想インターフェイスを通じて AWS リソースに接続する様子を示すマルチリージョン Direct Connect アーキテクチャです。この図では、企業のデータセンターからDirect Connect を使用して AWS リージョン（us-east-1 および us-west-2）に接続する構成を示しています。プライベート仮想インターフェイスは、単一の VPC に直接接続するか、 Direct Connect ゲートウェイ を介して異なる AWS リージョンの複数の VPC に接続し、プライベートリソースへのアクセスを提供します。トランジット仮想インターフェイスは AWS Transit Gateway への接続を可能にし、単一の仮想インターフェイスを通じて異なる AWS リージョンの複数の VPC にアクセスできます。パブリック仮想インターフェイスは、パブリックインターネットを経由することなく、 Amazon S3 、 Amazon Kinesis 、 Amazon SQS 、 Amazon SNS などの AWS パブリックサービスエンドポイントへのアクセスを提供します。 また、このアーキテクチャでは各仮想インターフェイスのタイプに対して今回の CloudWatch メトリクスで導入された新しい BGP モニタリング機能も紹介しています。この図は、これらのメトリクスが CloudWatch に収集され、さらに CloudWatch ダッシュボードの作成や CloudWatch アラームの生成、Amazon SNS 経由での通知に活用することで、Direct Connect インフラストラクチャ全体にわたる包括的なモニタリングとアラートを実現する方法を示しています。 図 1: 3 種類すべての Direct Connect 仮想インターフェイスのタイプに対応した 3 つの新しい CloudWatch BGP メトリクス VirtualInterfaceBgpStatus このメトリクスは、仮想インターフェイス上の BGP セッションの現在の状態を示します。値が 1 の場合は BGP セッションが確立されていることを示し、値が 0 の場合は切断されていることを示します。このメトリクスに CloudWatch アラームを設定することで、BGP セッションが切断された際に通知を受け取ることができ、DescribeVirtualInterfaces API のポーリングや Direct Connect コンソールの確認が不要になります。 VirtualInterfaceBgpPrefixesAccepted このメトリクスは、仮想インターフェイスを介してオンプレミスのネットワークから受け取った BGP プレフィックスの数を示します。Direct Connect では、 BGP セッションごとにプレフィックス数の上限が設定されており、この上限は仮想インターフェイスのタイプによって異なります。上限を超えると、BGP セッションはアイドル状態となり、セッションステータスがダウンになります。VIF タイプごとの経路数の上限の現在のクォータ値については、 Direct Connect のクォータ ページを参照してください。 VirtualInterfaceBgpPrefixesAccepted をモニタリングすることで、当該の上限を下回るしきい値で CloudWatch アラームを事前に設定しておき、上限に近づく前に早めに通知を受け取ることができます。また、このメトリクスは予期しない経路の消失を検知するのにも役立ちます。たとえば、オンプレミス側でルーティングポリシーの変更が行われ、AWS への経路広報が停止した場合などです。 VirtualInterfaceBgpPrefixesAdvertised このメトリクスは、仮想インターフェイスを介して AWS からオンプレミスネットワークに広報された BGP プレフィックスの数を示します。プレフィックス数の上限はアウトバウンドの経路広報にも適用され、仮想インターフェイスのタイプによって異なります。 VirtualInterfaceBgpPrefixesAdvertised メトリクスを追跡することで、AWS が想定通りの経路を広報していることを確認し、意図しない変更を検出できます。たとえば、経路集約やポリシー変更により経路が予期せず消失された場合などです。 ユースケース Direct Connect の 3 つの新しい CloudWatch メトリクスは、主に 2 つの運用ニーズに対応します。 BGP セッションの正常性のモニタリング VirtualInterfaceBgpStatus メトリクスに対して CloudWatch アラームを直接作成できるようになりました。Lambda 関数や API ポーリングは不要です。メトリクスの値が 0 に変化すると、CloudWatch がアラームを発報 し、Amazon Simple Notification Service（ Amazon SNS ）を通じて通知を受け取ることができます。これにより、BGP セッションのステータス変化に関連するトラフィック障害について、運用の複雑さと平均検出時間（MTTD）の両方を削減できます。 BGP プレフィックス数の変更のモニタリングと診断 VirtualInterfaceBgpPrefixesAccepted と VirtualInterfaceBgpPrefixesAdvertised メトリクスをモニタリングすることで、該当のプレフィックス数の上限を下回るしきい値に CloudWatch アラームを設定しておき、BGP セッションに影響が及ぶ前に早期に通知を受け取ることができます。 プレフィックス数の上限超過の防止だけでなく、これらのメトリクスは BGP セッションが維持されたままでもトラフィックに影響を与える経路変化の検知と診断にも役立ちます。BGP セッション自体は維持されているものの、経路がサイレントに消失される場合があります。たとえば、ルーティングポリシーの変更によって、オンプレミス側が特定のプレフィックスの経路広報を除外したり、意図しない変更により AWS 側から広報されるはずのプレフィックスが外部に広報されなくなった場合です。このような状況では、 VirtualInterfaceBgpStatus は 1 のままですが、影響を受けたプレフィックス宛てのトラフィックは流れなくなります。BGP ステータスとあわせて受信・広報プレフィックス数のメトリクスをモニタリングすることで、いずれかの方向での急激な減少を検出し、トラフィックへの影響と紐づけることで、根本原因の特定にかかる時間を短縮できます。 マルチリージョン構成やディザスタリカバリ (DR) 構成において、2 つの Direct Connect ロケーションが 2 つのリージョンに対してアクティブ/パッシブまたはアクティブ/アクティブの BGP 構成で接続されている場合、これらのメトリクスを使うことで、両方のパスが想定どおりのルートテーブルを双方向で保持していることを確認できます。スタンバイパスが想定されるプレフィックスの一部しか受信または広報していない場合、フェイルオーバーパスに問題があることを示しています。各仮想インターフェイスの両方のプレフィックスメトリクスに CloudWatch アラームを設定しておくことで、DR イベントや計画されたメンテナンスウィンドウの前に、この状態を事前に検知できます。 CloudWatch ダッシュボードでの BGP メトリクスのモニタリング 3 つの BGP メトリクスすべてを 1 つの CloudWatch ダッシュボードにまとめることで、仮想インターフェイス全体の BGP セッションの正常性とプレフィックス数を統合的に把握できます。図 2 は、 VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised をまとめて表示したダッシュボードの例です。 図 2: AWS Direct Connect 仮想インターフェイスの BGP セッションステータスとプレフィックス数を表示する CloudWatch ダッシュボード BGP モニタリングのための CloudWatch アラームの設定 以下の手順では、BGP セッションの障害を検出するために VirtualInterfaceBgpStatus メトリクスに CloudWatch アラームを作成する方法を説明します。 前提条件 アクティブな Direct Connect 仮想インターフェイスを持つ AWS アカウント CloudWatch アラームおよび SNS トピックを作成するための権限 BGP ステータスアラームの作成 CloudWatch コンソールを開き、ナビゲーションペインで アラーム を選択し、 アラームの作成 を選択します。 メトリクスの選択 を選択します。 検索ボックスに VirtualInterfaceBgpStatus と入力し、対象の仮想インターフェイス ID のメトリクスを選択して、 メトリクスの選択 を選択します。 統計 で 最小 を選択し、 期間 を 5 分に設定します。 条件 で、しきい値タイプを 静的 に設定し、 より低い を選択して、BGP セッションがダウンした際にアラームが発報されるよう しきい値に 1 を入力します。 次へ を選択し、アラートを受け取るための Amazon SNS 通知アクションを設定します。 次へ を選択し、アラームの名前を入力し、 次へ を選択し、 アラームの作成 を選択します。 図 3: VirtualInterfaceBgpStatus メトリクスの CloudWatch アラーム プレフィックス数アラームの作成 前述の手順のステップ 1〜2 を繰り返します。 メトリクス名を検索し、対象の仮想インターフェイスのメトリクスを選択します。 VirtualInterfaceBgpPrefixesAccepted は、AWS がオンプレミスネットワークから受け入れたプレフィックス数をモニタリングします。 VirtualInterfaceBgpPrefixesAdvertised は、AWS がオンプレミスネットワークに広報したプレフィックス数をモニタリングします。 統計 で 最大 を選択し、 期間 を 5 分に設定します。 条件 で、しきい値タイプを 静的 に設定し、比較演算子を選択して、しきい値を入力します。 プレフィックス数がしきい値を超えた場合にアラームを発報するには 以上 を選択します。たとえば、受信または広報プレフィックス数が適用されるプレフィックス上限に近づいたことを検出する場合です。 プレフィックス数がしきい値を下回った場合にアラームを発報するには 以下 を選択します。たとえば、受信または広報プレフィックス数が想定される最小値を下回り、経路の消失が発生した可能性を検出する場合です。 次へ を選択し、アラートを受け取るための SNS 通知アクションを設定します。 次へ を選択し、アラームの名前を入力し、 次へ を選択し、 アラームの作成 を選択します。 クリーンアップ テスト目的で CloudWatch アラームを作成した場合は、不要な課金を避けるために削除してください。料金の詳細については、 Amazon CloudWatch の料金ページ を参照してください。 CloudWatch コンソールを開きます。 ナビゲーションペインで アラーム を選択します。 作成したアラームを選択し、 アクション から 削除 を選択します。 考慮事項 メトリクスデータは、Direct Connect が利用可能なすべての AWS リージョンで利用できます。メトリクスは、Direct Connect ロケーションが紐づいているリージョンと同じリージョンの CloudWatch に公開されます。サポートされているロケーションの最新リストについては、 Direct Connect のロケーション ページを参照してください。 Direct Connect リソースに対する、すべての CloudWatch メトリクスは、追加費用なしで提供されます。 3 つの BGP メトリクスすべてを CloudWatch ダッシュボードにまとめることで、すべての仮想インターフェイスにわたる BGP セッションの正常性と経路数を一元的に把握することを推奨します。 メトリクスの値は 5 分ごとに更新されます。CloudWatch メトリクスは収集時点の BGP セッション状態を取得するため、収集間隔の間に発生して回復した BGP セッションのフラッピングはメトリクスに反映されない場合があります。BGP ステータスメトリクスは継続的に監視することで、セッションの安定性の傾向を追跡してください。 マルチリージョンまたはディザスタリカバリ (DR) アーキテクチャでは、各仮想インターフェイスに対して個別に CloudWatch アラームを作成することを推奨します。プライマリパスとスタンバイパスの間でプレフィックス数に大きな差がある場合、スタンバイ側の経路情報が不完全または正常に機能していない可能性があります。 まとめ Direct Connect 仮想インターフェイス向けの新しい CloudWatch メトリクス VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised により、BGP セッションの正常性とプレフィックス数をネイティブに可視化できるようになりました。BGP の障害検出や経路変更のモニタリングに、独自の Lambda 関数や API ポーリングは不要になりました。これらのメトリクスに CloudWatch アラームを設定することで、BGP の問題の検出時間を短縮し、プレフィックス数の上限超過による BGP セッションの切断を防止し、ハイブリッドネットワークが想定通りに動作していることを確認できます。Direct Connectと CloudWatch の詳細については、以下を参照してください。 AWS Direct Connect のユーザガイド Amazon CloudWatch のユーザガイド （訳者注：原文は 2026 年 4 月 13 日にメトリクスの公開リージョンに関する記述が更新されており、本翻訳は更新後の内容に基づいています） 翻訳は Technical Account Manager の豊山が担当しました。原文は こちら です。

本記事は&nbsp; 2026 年 3 月 30 日に公開された ” Introducing CloudWatch Metrics for AWS Direct Connect Virtual Interface BGP Health and Prefix Count ” を翻訳したものです。 本日、 AWS Direct Connect は Amazon CloudWatch における 仮想インターフェイス（VIF）に関する3 つの新しいメトリクス VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised のサポートを発表しました。これらのメトリクスにより、API を手動でポーリングしたりコンソールを確認したりすることなく、CloudWatch から直接 Border Gateway Protocol（BGP）セッションの正常性とプレフィックス数を把握できるようになります。本ブログでは、新しいメトリクスの概要、ユースケース、および修復アクションをトリガーするアラームの設定方法について説明します。CloudWatch で利用可能な Direct Connect メトリクスの完全なリストについては、 Direct Connect ユーザーガイドの Amazon CloudWatch によるモニタリング を参照してください。 VIF BGP ステータスおよびプレフィックス数メトリクスの提供前 この機能が提供される前は、Direct Connect の CloudWatch メトリクスは物理接続の正常性とトラフィックスループットのみをカバーしていました。BGP セッションステータス、オンプレミスルーターから受け入れたプレフィックス数、AWS からの経路広報、サイレントな経路の消失といった BGP レベルのテレメトリについては、Direct Connect API をポーリングしたり、独自の Lambda 関数を作成したり、またはオンプレミスのネットワーク管理ツールに頼る必要がありました。 Monitor BGP status on AWS Direct Connect VIFs and track prefix count advertised over transit VIF の記事では、そのようなアプローチの一例が紹介されています。今回の新しい CloudWatch メトリクスにより、そうした複雑さは不要となり、プレフィックス数のモニタリングはトランジット VIF に限定されなくなりました。 新しいメトリクスの概要 3 つの新しい CloudWatch メトリクスは、プライベート仮想インターフェイス、パブリック仮想インターフェイス、トランジット仮想インターフェイスの 3 種類すべての VIF タイプで利用できます。 図 1 は、オンプレミスネットワークが 3 種類の仮想インターフェイスを通じて AWS リソースに接続する様子を示すマルチリージョン Direct Connect アーキテクチャです。この図では、企業のデータセンターからDirect Connect を使用して AWS リージョン（us-east-1 および us-west-2）に接続する構成を示しています。プライベート仮想インターフェイスは、単一の VPC に直接接続するか、 Direct Connect ゲートウェイ を介して異なる AWS リージョンの複数の VPC に接続し、プライベートリソースへのアクセスを提供します。トランジット仮想インターフェイスは AWS Transit Gateway への接続を可能にし、単一の仮想インターフェイスを通じて異なる AWS リージョンの複数の VPC にアクセスできます。パブリック仮想インターフェイスは、パブリックインターネットを経由することなく、 Amazon S3 、 Amazon Kinesis 、 Amazon SQS 、 Amazon SNS などの AWS パブリックサービスエンドポイントへのアクセスを提供します。 また、このアーキテクチャでは各仮想インターフェイスのタイプに対して今回の CloudWatch メトリクスで導入された新しい BGP モニタリング機能も紹介しています。この図は、これらのメトリクスが CloudWatch に収集され、さらに CloudWatch ダッシュボードの作成や CloudWatch アラームの生成、Amazon SNS 経由での通知に活用することで、Direct Connect インフラストラクチャ全体にわたる包括的なモニタリングとアラートを実現する方法を示しています。 図 1: 3 種類すべての Direct Connect 仮想インターフェイスのタイプに対応した 3 つの新しい CloudWatch BGP メトリクス VirtualInterfaceBgpStatus このメトリクスは、仮想インターフェイス上の BGP セッションの現在の状態を示します。値が 1 の場合は BGP セッションが確立されていることを示し、値が 0 の場合は切断されていることを示します。このメトリクスに CloudWatch アラームを設定することで、BGP セッションが切断された際に通知を受け取ることができ、DescribeVirtualInterfaces API のポーリングや Direct Connect コンソールの確認が不要になります。 VirtualInterfaceBgpPrefixesAccepted このメトリクスは、仮想インターフェイスを介してオンプレミスのネットワークから受け取った BGP プレフィックスの数を示します。Direct Connect では、 BGP セッションごとにプレフィックス数の上限が設定されており、この上限は仮想インターフェイスのタイプによって異なります。上限を超えると、BGP セッションはアイドル状態となり、セッションステータスがダウンになります。VIF タイプごとの経路数の上限の現在のクォータ値については、 Direct Connect のクォータ ページを参照してください。 VirtualInterfaceBgpPrefixesAccepted をモニタリングすることで、当該の上限を下回るしきい値で CloudWatch アラームを事前に設定しておき、上限に近づく前に早めに通知を受け取ることができます。また、このメトリクスは予期しない経路の消失を検知するのにも役立ちます。たとえば、オンプレミス側でルーティングポリシーの変更が行われ、AWS への経路広報が停止した場合などです。 VirtualInterfaceBgpPrefixesAdvertised このメトリクスは、仮想インターフェイスを介して AWS からオンプレミスネットワークに広報された BGP プレフィックスの数を示します。プレフィックス数の上限はアウトバウンドの経路広報にも適用され、仮想インターフェイスのタイプによって異なります。 VirtualInterfaceBgpPrefixesAdvertised メトリクスを追跡することで、AWS が想定通りの経路を広報していることを確認し、意図しない変更を検出できます。たとえば、経路集約やポリシー変更により経路が予期せず消失された場合などです。 ユースケース Direct Connect の 3 つの新しい CloudWatch メトリクスは、主に 2 つの運用ニーズに対応します。 BGP セッションの正常性のモニタリング VirtualInterfaceBgpStatus メトリクスに対して CloudWatch アラームを直接作成できるようになりました。Lambda 関数や API ポーリングは不要です。メトリクスの値が 0 に変化すると、CloudWatch がアラームを発報 し、Amazon Simple Notification Service（ Amazon SNS ）を通じて通知を受け取ることができます。これにより、BGP セッションのステータス変化に関連するトラフィック障害について、運用の複雑さと平均検出時間（MTTD）の両方を削減できます。 BGP プレフィックス数の変更のモニタリングと診断 VirtualInterfaceBgpPrefixesAccepted と VirtualInterfaceBgpPrefixesAdvertised メトリクスをモニタリングすることで、該当のプレフィックス数の上限を下回るしきい値に CloudWatch アラームを設定しておき、BGP セッションに影響が及ぶ前に早期に通知を受け取ることができます。 プレフィックス数の上限超過の防止だけでなく、これらのメトリクスは BGP セッションが維持されたままでもトラフィックに影響を与える経路変化の検知と診断にも役立ちます。BGP セッション自体は維持されているものの、経路がサイレントに消失される場合があります。たとえば、ルーティングポリシーの変更によって、オンプレミス側が特定のプレフィックスの経路広報を除外したり、意図しない変更により AWS 側から広報されるはずのプレフィックスが外部に広報されなくなった場合です。このような状況では、 VirtualInterfaceBgpStatus は 1 のままですが、影響を受けたプレフィックス宛てのトラフィックは流れなくなります。BGP ステータスとあわせて受信・広報プレフィックス数のメトリクスをモニタリングすることで、いずれかの方向での急激な減少を検出し、トラフィックへの影響と紐づけることで、根本原因の特定にかかる時間を短縮できます。 マルチリージョン構成やディザスタリカバリ (DR) 構成において、2 つの Direct Connect ロケーションが 2 つのリージョンに対してアクティブ/パッシブまたはアクティブ/アクティブの BGP 構成で接続されている場合、これらのメトリクスを使うことで、両方のパスが想定どおりのルートテーブルを双方向で保持していることを確認できます。スタンバイパスが想定されるプレフィックスの一部しか受信または広報していない場合、フェイルオーバーパスに問題があることを示しています。各仮想インターフェイスの両方のプレフィックスメトリクスに CloudWatch アラームを設定しておくことで、DR イベントや計画されたメンテナンスウィンドウの前に、この状態を事前に検知できます。 CloudWatch ダッシュボードでの BGP メトリクスのモニタリング 3 つの BGP メトリクスすべてを 1 つの CloudWatch ダッシュボードにまとめることで、仮想インターフェイス全体の BGP セッションの正常性とプレフィックス数を統合的に把握できます。図 2 は、 VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised をまとめて表示したダッシュボードの例です。 図 2: AWS Direct Connect 仮想インターフェイスの BGP セッションステータスとプレフィックス数を表示する CloudWatch ダッシュボード BGP モニタリングのための CloudWatch アラームの設定 以下の手順では、BGP セッションの障害を検出するために VirtualInterfaceBgpStatus メトリクスに CloudWatch アラームを作成する方法を説明します。 前提条件 アクティブな Direct Connect 仮想インターフェイスを持つ AWS アカウント CloudWatch アラームおよび SNS トピックを作成するための権限 BGP ステータスアラームの作成 CloudWatch コンソールを開き、ナビゲーションペインで アラーム を選択し、 アラームの作成 を選択します。 メトリクスの選択 を選択します。 検索ボックスに VirtualInterfaceBgpStatus と入力し、対象の仮想インターフェイス ID のメトリクスを選択して、 メトリクスの選択 を選択します。 統計 で 最小 を選択し、 期間 を 5 分に設定します。 条件 で、しきい値タイプを 静的 に設定し、 より低い を選択して、BGP セッションがダウンした際にアラームが発報されるよう しきい値に 1 を入力します。 次へ を選択し、アラートを受け取るための Amazon SNS 通知アクションを設定します。 次へ を選択し、アラームの名前を入力し、 次へ を選択し、 アラームの作成 を選択します。 図 3: VirtualInterfaceBgpStatus メトリクスの CloudWatch アラーム プレフィックス数アラームの作成 前述の手順のステップ 1〜2 を繰り返します。 メトリクス名を検索し、対象の仮想インターフェイスのメトリクスを選択します。 VirtualInterfaceBgpPrefixesAccepted は、AWS がオンプレミスネットワークから受け入れたプレフィックス数をモニタリングします。 VirtualInterfaceBgpPrefixesAdvertised は、AWS がオンプレミスネットワークに広報したプレフィックス数をモニタリングします。 統計 で 最大 を選択し、 期間 を 5 分に設定します。 条件 で、しきい値タイプを 静的 に設定し、比較演算子を選択して、しきい値を入力します。 プレフィックス数がしきい値を超えた場合にアラームを発報するには 以上 を選択します。たとえば、受信または広報プレフィックス数が適用されるプレフィックス上限に近づいたことを検出する場合です。 プレフィックス数がしきい値を下回った場合にアラームを発報するには 以下 を選択します。たとえば、受信または広報プレフィックス数が想定される最小値を下回り、経路の消失が発生した可能性を検出する場合です。 次へ を選択し、アラートを受け取るための SNS 通知アクションを設定します。 次へ を選択し、アラームの名前を入力し、 次へ を選択し、 アラームの作成 を選択します。 クリーンアップ テスト目的で CloudWatch アラームを作成した場合は、不要な課金を避けるために削除してください。料金の詳細については、 Amazon CloudWatch の料金ページ を参照してください。 CloudWatch コンソールを開きます。 ナビゲーションペインで アラーム を選択します。 作成したアラームを選択し、 アクション から 削除 を選択します。 考慮事項 メトリクスデータは、Direct Connect が利用可能なすべての AWS リージョンで利用できます。メトリクスは、Direct Connect ロケーションが紐づいているリージョンと同じリージョンの CloudWatch に公開されます。サポートされているロケーションの最新リストについては、 Direct Connect のロケーション ページを参照してください。 Direct Connect リソースに対する、すべての CloudWatch メトリクスは、追加費用なしで提供されます。 3 つの BGP メトリクスすべてを CloudWatch ダッシュボードにまとめることで、すべての仮想インターフェイスにわたる BGP セッションの正常性と経路数を一元的に把握することを推奨します。 メトリクスの値は 5 分ごとに更新されます。CloudWatch メトリクスは収集時点の BGP セッション状態を取得するため、収集間隔の間に発生して回復した BGP セッションのフラッピングはメトリクスに反映されない場合があります。BGP ステータスメトリクスは継続的に監視することで、セッションの安定性の傾向を追跡してください。 マルチリージョンまたはディザスタリカバリ (DR) アーキテクチャでは、各仮想インターフェイスに対して個別に CloudWatch アラームを作成することを推奨します。プライマリパスとスタンバイパスの間でプレフィックス数に大きな差がある場合、スタンバイ側の経路情報が不完全または正常に機能していない可能性があります。 まとめ Direct Connect 仮想インターフェイス向けの新しい CloudWatch メトリクス VirtualInterfaceBgpStatus 、 VirtualInterfaceBgpPrefixesAccepted 、 VirtualInterfaceBgpPrefixesAdvertised により、BGP セッションの正常性とプレフィックス数をネイティブに可視化できるようになりました。BGP の障害検出や経路変更のモニタリングに、独自の Lambda 関数や API ポーリングは不要になりました。これらのメトリクスに CloudWatch アラームを設定することで、BGP の問題の検出時間を短縮し、プレフィックス数の上限超過による BGP セッションの切断を防止し、ハイブリッドネットワークが想定通りに動作していることを確認できます。Direct Connectと CloudWatch の詳細については、以下を参照してください。 AWS Direct Connect のユーザガイド Amazon CloudWatch のユーザガイド （訳者注：原文は 2026 年 4 月 13 日にメトリクスの公開リージョンに関する記述が更新されており、本翻訳は更新後の内容に基づいています） 翻訳は Technical Account Manager の豊山が担当しました。原文は こちら です。

こんにちは。Amazon&nbsp;Web Services Japan&nbsp;のソリューションアーキテクト、田中&nbsp;里絵&nbsp;です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 4 回レポートです。シリーズの背景や全体像については、 シリーズ 初回のイベントレポート をご覧ください。 前日（4&nbsp;月&nbsp;22&nbsp;日）の&nbsp;AI&nbsp;を自社の業務に活かしたい企業の皆様向けセッションに続き、2026&nbsp;年&nbsp;4&nbsp;月&nbsp;23&nbsp;日は同じ名古屋にて、AI&nbsp;で顧客を支援する&nbsp;IT&nbsp;企業のエグゼクティブの皆様をお迎えし、「 AI&nbsp;ツールで実現する継続収益ビジネス&nbsp;〜開発力を資産に変える〜 」と題したイベントを開催しました。AI&nbsp;エージェント時代のビジネスモデル変革をテーマに、登壇企業の実体験から「開発力をどう資産に変えるか」を共に考える一日となりました。 イベントの流れ 当日はまず、Amazon Web Services Japan のソリューションアーキテクト古屋 楓から「AWS で一歩先へ！生成 AI 時代のビジネスモデル変革の打ち手」と題したオープニングセッションを実施しました。このセッションでは、AI Agent を活用して IT 企業のビジネスの形がどう変わっていくのか、 Kiro のデモを交えながら解説しました（AWS セッションの詳細については 大阪・IT 企業編のイベントレポート をご覧ください）。 写真: AWS 古屋によるオープニングセッション ここからは、中部を拠点に&nbsp;AI&nbsp;を活用したビジネス変革に取り組まれている&nbsp;2&nbsp;社のパネルディスカッションの内容をご紹介します。 事例紹介：エスツーアイ株式会社様 〜Kiro の仕様駆動開発で、製造業 SI の課題に挑む〜 1 社目は エスツーアイ株式会社 様です。愛知県知多郡東浦町に本社を構え、製造業、特に自動車部品メーカー向けの SI を行っておられる会社です。生産準備段階から量産までの全体をカバーし、一貫して担当されています。当日はシステム開発センター 部長の與儀（よぎ） 智章 様にお話しいただきました。 背景と課題、お取り組み内容 與儀様は、製造業&nbsp;SI&nbsp;の構造的な課題として&nbsp;3&nbsp;つを挙げられました。1&nbsp;つ目は、新規開発における仕様のブレです。プロジェクトごとに要件定義や設計・開発を進めていく中で、同じ機能でもユーザーによって要求が異なったり、開発者が過去の経験を新しいプロジェクトに取り入れようとすることで、仕様にブレが生じ、設計や機能が肥大化してしまう。2&nbsp;つ目は、運用保守における属人化です。お客様ごとにカスタマイズした構築をしているため、システムに人が紐づいてしまい、負荷分散しようとしても引き継ぎコストがかかる。3&nbsp;つ目は、レガシーシステムからの再構築で発生する仕様漏れです。何十年も前のシステムを新しい仕組みに移行する際、仕様を誰も把握していない状態で進めざるを得ず、後工程で問題が発覚してしまう。 與儀様は、コーディングエージェントを活用してこれらの打ち手になりえるかを探るため、まず自社の休暇申請システムおよび出張旅費精算システムの開発で&nbsp;Kiro&nbsp;の活用にチャレンジをされました。Kiro&nbsp;の仕様駆動開発（Spec&nbsp;駆動開発）では、要件定義&nbsp;→&nbsp;デザイン&nbsp;→&nbsp;タスク化・実装という&nbsp;3&nbsp;つのフェーズを踏むため、従来のウォーターフォール型で起きがちだった仕様のブレを早い段階で防ぐことができます。実際に、画面が動作するところまで&nbsp;2〜3&nbsp;日で到達できたとのことで、早い段階でユーザーに見せることで後工程での問題発生を防ぐ効果が期待できると話されました。 さらに、あえてコーディングルールを縛らずに&nbsp;Kiro&nbsp;に開発させたところ、自社では通常採用しないような設計パターン（例：メール送信処理をデータベースで管理しバッチ実行する方式）が提案され、検討した結果そちらの方が設計として優れていたというケースもあったとのことです。AI&nbsp;を「指示通りに動く道具」ではなく「新しい設計のアイディアを一緒に作るパートナー」として活用できる可能性を実感されたといいます。 一方で、チーム開発に展開する際にはソース管理やコーディングルールの整備が必要になること、AI&nbsp;による変更の影響範囲をどう管理するかといった課題も見えてきた、と述べられました。 今後の展望 今後は、自社が持つ製造業関連のノウハウを最大限活用し、例としてプロジェクトの上流工程段階でのモック開発や、会議ログをもとにしたユーザー向けドキュメントの自動作成など、AI を活用してビジネスのスピード向上を目指したい、と述べられました。また、人間がどう統制し、AI がどう自律的に動くか、といったルールやフレームワークの整備を行うことで、より効果的に AI を活用していきたいとも述べられていました。今回は社内システムの事例についてお話いただきましたが、こうしたお取り組みを通して、SI の業務でどう AI を活用していくかも探っていかれるとのことです。 事例紹介：i&nbsp;Smart Technologies&nbsp;株式会社様&nbsp;〜IoT × AI&nbsp;で製造現場の意思決定を変える「AI&nbsp;製造部長」〜 2&nbsp;社目は &nbsp;i&nbsp;Smart Technologies&nbsp;株式会社 様です。愛知県碧南市に本社を構え、自動車部品メーカーであるアサヒ鉄工様のグループ会社として、アサヒ鉄工で培った&nbsp;IoT&nbsp;の改善ノウハウを他の製造業に展開されている会社です。当日は&nbsp;COO&nbsp;の松下&nbsp;隼人&nbsp;様にお話しいただきました。 背景と課題、お取り組み内容 i Smart Technologies 様は、製造業のお客様向けに IoT ソリューションで生産性データを収集し、データベースに蓄積するところまでは実現されていました。課題は、蓄積されたデータを現場の意思決定にどうつなげるか、でした。製造現場の担当者は日々の業務に追われており、ダッシュボードを見に行く余裕がない。データはあるのに活用されない、という状況にありました。これを解決するために開発されたのが「 AI 製造部長 」です。 AI&nbsp;製造部長は、IoT&nbsp;で収集した生産性データを&nbsp; Amazon Bedrock &nbsp;で解析し、製造部長のように分かりやすい言葉で現場スタッフに通知するサービスです。現場での朝礼代わりに使ってもらい、製造現場の意思決定に活かすことを目指して開発をスタートしました。 開発にあたって、まず課題となったのが&nbsp;AI&nbsp;の回答が安定しないことでした。当時の生成&nbsp;AI&nbsp;の言語モデルは、2026年現在と比べると能力の制約も大きくありました。ときに抽象的な質問、ときにコンテキストが多い質問など、ユーザーの様々な質問に対して効率的に回答を得るために、モデル頼みではなく、データを含めたサービス全体の設計が必要だと気づかれたとのことです。 この壁を乗り越えるために取られたアプローチが&nbsp;2&nbsp;つあります。1&nbsp;つ目は、 ルールベースとのハイブリッド設計 です。よくある質問に対しては、事前に情報を整理して&nbsp;AI&nbsp;に提供しておくようにして回答品質を担保しつつ、それ以外の質問に対してはAIが情報を動的に取得して回答するようにしました。2&nbsp;つ目は、 AI&nbsp;を表面上見せない設計 です。製造現場のユーザーは&nbsp;AI&nbsp;に質問を書くこと自体にハードルがあるため、プッシュ型でユーザーに情報を届ける方式も採用しました。 今後の展望 導入後、現場からは「面白い」という声があり、積極的に使ってもらえるようになったとのことです。AI への抵抗感の強いメンバーもいたため、まずは正確性のある情報を通知するところから運用を開始し、AI の信頼感を少しずつ醸成していきました。このこつこつと実績を積み上げていったことで、今では「人間が書いてるのでは？」と時折聞かれるほど現場に溶け込み、信頼感を獲得されているといいます。 「製造業は、業界の性質上属人化している業務も多く、会社全体のモデルを変えるような&nbsp;AI&nbsp;活用にはチャレンジがある。同じような業界で情報交換をしたり、会社と会社で関係づくりをして、収益モデルを業界全体で変えていくような動きができれば」と述べていただきました。会場ではこのようなメッセージで、大きく共感しながら聞いているお客様が多くおられました。 写真:&nbsp;エスツーアイ株式会社&nbsp;與儀様、i&nbsp;Smart Technologies&nbsp;株式会社&nbsp;松下様、AWS&nbsp;植木によるパネルディスカッション まとめ 名古屋でご登壇いただいた 2 社に共通していたのは、AI を「道具」ではなく「パートナー」として位置づけ、自社のドメイン知識と掛け合わせることで新しい価値を生み出すという発想でした。S2I 様は Kiro の仕様駆動開発で製造業 SI の構造的課題に向き合い、i Smart Technologies 様は IoT データと Amazon Bedrock を組み合わせて製造現場の意思決定を変えるサービスを生み出されました。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした名古屋編に続き、次回は広島編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ…もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に何か取り組みたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ エスツーアイ株式会社様の AWS 生成 AI 事例「Kiro を活用した経費精算システムの迅速な開発」のご紹介 AWS Local Executive Roadshow 大阪・初回レポート（実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜） AWS Local Executive Roadshow 大阪・IT 企業編レポート（AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜）

みなさんこんにちは！製造業のお客様を中心に技術支援をしているソリューションアーキテクトの吉川と岩根です。まもなく AWS Summit Japan 2026 が開催されます。今年も千葉の幕張メッセで開催いたしますので是非ご参加ください！今年も製造業向けの展示を出展する予定ですので、その内容をご紹介します！各展示ごとのブログも続々投稿する予定です。 AWS Summit とは AWS Summit は、共に未来を描くビルダーが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、クラウドでイノベーションを起こすことに興味がある全ての皆様のためのイベントです。日本最大の “AWS を学ぶイベント”、それが AWS Summit です。基調講演、260を超えるAWSセッション・事例セッション・パートナーセッションがあり、 300以上の展示でオフラインならではの体験ができます。開催期間は 6 月 25 日 (木) と 26 日 (金) の 2 日間で会場は幕張メッセです。 本ブログでは数ある展示とセッションの中から製造業に関する展示とセッションをご紹介いたします。まだ登録してない方は以下のリンクから是非ご登録ください。 登録はこちら 製造業に関する展示は Hall 7 の AWS Expo 内にある AWS Industries Zone にあります。 AWS Industries Zone では、製造、金融、自動車など 13 の業界別に特化したソリューションと、Physical AI の特設展示をご覧いただけます。各業界をリードするお客様の AWS 活用事例や、生成 AI をはじめとする最新テクノロジーの実用的なデモを通じて、業界固有の課題解決方法をご覧いただけます。また、業界に精通したエキスパートと具体的な活用シナリオについて、ご相談いただけます。 製造領域では、Smart Manufacturing を中心としたコンセプチュアルな 製造 Highlight 展示 と、お客様事例展示や、 Product Engineering や Smart Product などの最新のデモを含む 製造 Industry 展示 の2つの展示エリアを用意しています。 展示全体像 赤い枠が製造展示のエリア A WS Expo 内の Industries Zone の図。赤い枠が製造業むけ展示。上が Highlight 展示、下が Industry 展示 製造業 Highlight 展示の概要 Highlight 展示では「 AI で加速する製造業のルネッサンス」をテーマとして、製造業の未来を体感できる展示を行います。3つの展示で構成されており、以下のような配置となっています。その他に、エリア内に設置された100インチモニタを使用して、各ブースの説明をライトニングトーク形式で紹介したり、展示の概観が分かるような動画を投影する予定です。 生産ラインの未来 製造業では、需要と供給が絶えず変動する中、生産ラインの最適な稼働が求められています。本展示では、生産ライン全体のシミュレーションによりボトルネックを特定し、生産効率を最大化する仕組みをご紹介します。 技術要素として、以下の3点を取り上げます。 ソフトウェア定義型の生産ライン ― ライン構成をコードで定義し、リポジトリで管理する仕組み デジタルツインによるシミュレーション ― 現場から収集したデータを基に、仮想空間上で生産プロセスを検証・最適化する仕組み AI エージェントによる意思決定支援 ― 生産ラインを含む多様なデータを活用し、データドリブンな判断を実現する仕組み これら3つの要素を組み合わせた生産ラインの将来像を、実機デモを交えてご覧いただきます。 工場のデジタルツインとシミュレーションを活用して AI アシスタントでボトルネックの分析 ソフトウェア定義型ファクトリー これまでハードウェアとして物理的に存在していた PLC を仮想化し、ソフト PLC（仮想 PLC ）として動作させることで、生産ラインの制御ロジックをソフトウェアとして扱えるようになります。本展示では、物理 PLC からソフト PLC への移行を実際にお見せし、その可能性を体感いただきます。 ソフト PLC への移行がもたらす最大の変化は、ライン構成そのものをコードとして定義できるようになることです。これにより、 Git リポジトリを活用したバージョン管理が可能となり、誰が・いつ・どのような変更を加えたのかを完全にトレースできます。 さらに本展示では、エッジデバイスからクラウドまでを一気通貫でつなぐエンドツーエンドの制御アーキテクチャをご紹介します。工場のフロアで動作するエッジコンピューティングと、クラウド上のオーケストレーション層がシームレスに連携することで、生産ラインの柔軟性とスケーラビリティが飛躍的に向上します。 ソフトウェア PLC により制御されるミニチュア工場 サプライチェーン 本展示では、 AI がサプライチェーンの意思決定を変える瞬間を体感いただけます。 需要変動や供給遅延が発生した際に、担当者が AI エージェントに分析を依頼し、在庫枯渇の予測・生産計画への影響・代替調達の選択肢・対応方針案を迅速に導き出す一連の流れを体験いただきます。 AI が在庫や物流の状況をリアルタイムに読み解き、複数の対応策をコスト・リスクとともに提示します。 需要の急変や供給の遅延といった製造現場の日常的な課題に、 AI がどのように応えるのか。今まさに起こっている変化をご覧ください。 市 場の変化に応じて、生産計画に反映できる需要予測を行う AI エージェント 製造業 Industry 展示の概要 Industry 展示では、製造業のお客様の現場で「すぐに使える」テクノロジーを、実機デモを通じて体感いただける展示を多数ご用意しています。 Highlight 展示が「未来の製造業」をテーマにコンセプチュアルに描いたのに対し、 Industry 展示は Product Engineering （製品設計開発）と Smart Product （スマート製品開発・運用）という製造業のものづくりライフサイクルを支える 2 つの軸に加え、エッジ × AWS の選択肢を一望できる AWS 認定デバイスウォール 、そしてお客様自身による事例展示エリアで構成しています。 AWS のソリューションアーキテクトや事例企業の方々と、その場で具体的な活用シナリオをじっくり相談できる、ぐっと現場目線のエリアです。 生成 AI 時代の製品設計開発 CAE 解析や CAD 操作、過去ナレッジの活用など、製品設計開発の現場にはエンジニアの専門性に強く依存する業務が数多く存在します。本展示では、フィジカル AI 時代の到来を見据え、エンジニアの設計開発を加速する 2 つの切り口で実機デモをご覧いただきます。 Engineering and Development HUB（ EDH ）による HPC 基盤の俊敏な立ち上げ ― 大規模シミュレーション、 CAE 解析、 GPU を用いたモデル作成といった、フィジカル AI 時代の研究開発に欠かせない HPC 環境を AWS 上に短時間で構築する仕組みをご紹介します。仮想ワークステーションとスケーラブルな HPC 基盤を Web ポータルから即座に利用でき、自動スケーリングやコスト管理機能も標準で備えているため、エンジニアや研究者は使い慣れたツールに集中できます。 Engineering and Development Hub (EDH) 設計開発の現場ですぐに実践できる生成 AI ユースケース ― 自然言語による CAD/CAE 操作アシスト、過去設計ナレッジの瞬時検索、実験レポートの自動生成など、明日からでも取り入れられる「使える AI 」の活用例をご紹介します。その場でご覧いただける動作デモに加え、後日体験できるワークショップもご用意しているので、 AI が設計業務をどう変えるのかをじっくり実感いただけます。 生成AI x CAD + CAE + NVIDIA Isaac によるPhysical AI シミュレーション 「フィジカル AI 時代の研究開発をどう加速するか」を、現場のエンジニア目線で体感いただける展示です。 AI 駆動のスマート製品開発とサービス運用 スマート製品の世界では、製品そのものだけでなく、ソフトウェア開発から市場投入後の運用改善までを含むエンドツーエンドのライフサイクル全体が競争力の源泉となります。本展示では、ソフトウェア開発と運用改善の両面で AI エージェントが何を変えるのかを、 2 つのデモでお見せします。 AI エージェントが加速するスマート製品のソフトウェア開発 ― ソフトウェア開発 AI エージェント Kiro を活用し、企画から運用までのソフトウェア開発プロセスを AI と協調しながら進める世界をご紹介します。組み込みシステムやライフサイクルの長いソフトウェアを含む開発全体に AI 支援を適用できること、既存の設計文書やコーディングルールをそのまま活かせること、そしてチケットを用いた責任分担により人間と AI が役割を持ち寄って開発を進められることを、実際のデモで体感いただきます。 製品開発プロセスの調査・計画・実装・リリース・運用全て Kiro で開発を支援 AI エージェントが実現するデータ駆動のプロダクト改善サイクル ― Amazon Quick を使い、専門知識がなくても AI によるデータ分析を実現する仕組みをご紹介します。営業・保守・設計開発・品質保証といった部門ごとに分散したデータに加え、気象などの公開データも統合し、問題の発見から原因の特定、対策の立案まで、 AI がパートナーとなってプロダクト改善の意思決定を支援します。 出荷したフィールド上の製品情報からえた知見を分析し原因の究明と対策計画を Amazon Quick が立案し意思決定を支援 「製品を作って終わり」ではなく、「作りながら、運用しながらより良くしていく」これからのスマート製品開発のあり方を、ぜひその目でお確かめください。 AWS 認定デバイスウォール エッジデバイスとクラウドを連携させるニーズはここ数年で急速に高まっており、「どのデバイスを選べばよいのか」「クラウド連携の検証コストをどう下げるか」というご相談を多くいただきます。 AWS 認定デバイスプログラムは、 AWS の IoT サービスとの接続が検証された信頼性の高いデバイスをラインアップしたプログラムです。本展示では、認定済みのエッジデバイスを「ウォール」状にずらりと並べ、ハードウェアパートナー各社との協業によって広がる選択肢を一望していただけます。日本国内におけるエッジ × AWS のサービス構築を加速し、お客様のビジネスを後押しする取り組みを、実機を通じてご紹介します。 壁一面に展示された AWS 認定デバイスのラインアップ。多様なエッジデバイスをまとめて見比べいただけます。写真は AWS Summit Japan 2025より お客様事例展示 Industry 展示エリアには、 AWS をご活用いただいているお客様自身による事例展示エリアも併設しています。今回の製造業エリアでは、製造現場とエンジニアリングの両面から、特徴的な AWS 活用事例をお持ちのお客様 2 社をお迎えします。 オムロン株式会社「生成 AI を活用した知財 AI エージェント『 ALBERT 』の内製開発」 世界中で日々数千件もの特許が出願されるなか、知財業務の現場では「全特許を網羅的に把握しきれない」「技術と知的財産の双方に通じた専門人材の工数が逼迫している」「機密情報を扱うため社外の生成 AI サービスを気軽には使えない」といった課題が積み重なっていました。 本展示では、オムロンが Amazon Bedrock や Amazon OpenSearch Serverless などの AWS サービスを活用して内製開発した、知財 AI エージェント 「 ALBERT 」 の取り組みをご紹介いただきます。研究開発に特化した自社の生成 AI 活用基盤「 RD Buddy 」の上に AI エージェントを実装することで、情報漏洩リスクとコスト課題を抑えつつ、特許情報の検索・分析・要約といった知財業務を高度化・効率化。 特許調査・発明説明書作成の工数を 90% 削減 という成果を生んでいます。今後は R&amp;D 部門での利用拡大（ 60 名 → 120 名）から全社展開まで見据えた、まさに「生成 AI による R&amp;D の DX 」を体現する事例です。 i Smart Technologies 株式会社「 Amazon Bedrock を活用した『 AI 製造部長』」 製造現場では IoT データを集めても「データをどう読み解けばよいか分からない」という壁にぶつかることが少なくありません。 i Smart Technologies は、自社の IoT データ収集サービス iXacs に Amazon Bedrock （ Claude ）を組み込み、 多様な製造設備から集まる時系列データを自然言語で解釈する「 AI 製造部長」 を実装しました。 専門知識のない現場担当者が、異常の兆しやその原因、次に取るべきアクションを自然言語で受け取れるようになり、データ解析にかかる時間を 70% 削減という成果を生んでいます。「トヨタのカイゼン文化 × AI 」を体現するこの取り組みは、 IoT 製品そのものに生成 AI を組み込む「組込み AI 」の先行事例としても注目されています。本展示では、収集したデータを「使えるデータ」に変える AI の力を、 COO の松下様ご自身の言葉でご紹介いただきます。 会期中は、お客様ご自身による解説に加え、その場での Q&amp;A も可能です。実装の裏側や苦労した点、運用してみての気づきなど、現場の生の声を直接お聞きいただける貴重な機会ですので、ぜひ足をお運びください！ 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。 吉川 晃平 (Kohei Yoshikawa) アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト ソフトウェア開発者およびシステムインテグレーターとして 20 年以上従事した後、2020 年から AWS Japan で活動中。エンタープライズ事業本部で、日本の多くの製造業や SI 事業のお客様の AWS 活用を支援してきた。 スマートプロダクトのためのサービス開発に興味を持ち、最近は AI 開発エージェントを用いた製品開発ライフサイクルの加速に取り組んでおり、お客様との会話のネタが尽きない毎日を送っている。 趣味は週末のサイクリング、冬はスキー。風を切る乗り物がとにかく好き。 &nbsp;

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今週も様々なアップデートが公開されています。特に、AWS Blogで紹介している AI エージェント対応のデータ基盤は、エージェントをデータに以下に紐づけるのかというイメージの湧くデモになっていますので、ぜひご一読ください。 生成 AI を活用したビジネス変革に取り組むお客様を支援する 生成 AI 実用化推進プログラム は引き続き参加企業を募集しています。ご興味のある方はぜひご覧ください。 それでは、5 月 18 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ:&nbsp; 3 か月で開発スピード 3 倍を達成：キヤノン IT ソリューションズ様が実践した AI Coding Agent 導入・普及の仕組みづくり キヤノン IT ソリューションズ株式会社様（以下、キヤノン ITS 様）は、SIer としての競争力強化と顧客への付加価値提供のため、AI 駆動開発の社内普及を推進しました。生成 AI ツールの導入は進んでいたものの、現場での活用の定着と全社的な広がりが課題でした。これを解決するため、AWS と共同でロードマップを敷き、9 月のキックオフイベント「AI Agent DAY」（参加者 250 名以上）から 3 か月間にわたり、Amazon Q Developer&nbsp;を 57 名で業務適用検証しました。エグゼクティブスポンサーである金澤社長の支援、生成 AI ビジネス推進室による予算負担、ハンズオン・オフィスアワー・Teams コミュニティでの情報共有を組み合わせ、PoC 開発で従来 2 週間かかっていた作業を 3 日で完了するなど、開発スピード 3 倍、工数 67% 削減を達成しています。今後は本検証で得た知見を活かして社内での活用パターンを整理し、AWS と連携してさらなる活用領域の拡大に取り組まれる予定です。 AWS 生成 AI 国内事例ブログ: 富士電機ITソリューションが挑戦する働き方の大変革 〜Amazon Q Developer 活用から Kiro による新しい企業価値創出へ〜 富士電機 IT ソリューション株式会社様（以下、FSL 様）は、製造・流通・金融・建設・公共・文教など幅広い業界向けに IT ソリューションを提供する SIer です。SIer としての競争力強化と顧客への付加価値提供のため、生成 AI による開発生産性向上が重要なテーマでした。FSL 様は 2025 年 12 月から金森 重晴 執行役員の指揮のもと&nbsp;Amazon Q Developer&nbsp;Pro サブスクリプションを 20 ユーザーで展開し、「まず使ってみる」を合言葉にボトムアップ型のアプローチで現場主導の活用文化を育てた結果、現在では 50 ユーザー以上に拡大しています。本記事では、テスト結果報告書の作成や障害情報のインサイト抽出（原田氏）、ソースコードのレビュー支援や既存プログラム理解（久保田氏）、リバースエンジニアリングや見積もりツールの内製開発（前田氏）など現場発の 3 つの活用事例が紹介されています。今後は利用者のさらなる拡大と、仕様駆動開発を実現する&nbsp;Kiro&nbsp;の導入により、SDLC 全体を再設計する取り組みを進めていかれる予定です。 ブログ記事「 AWS における AI エージェント対応のデータ基盤 (1) — ツールを配る時代から、データを返す時代へ 」を公開 AI エージェントに本番データを分析させるには、認可・ビジネスデータカタログ・ドメイン知識の 3 要素を揃える必要があります。本記事ではサンプルリポジトリ&nbsp; aws-samples/sample-sagemaker-agentic-analyst &nbsp;を題材に、これら 3 要素が&nbsp;Amazon SageMaker Catalog、Amazon Bedrock AgentCore、AWS Lake Formation、Amazon S3 Access Grants の組み合わせでどう実装されているかを俯瞰し、構造化データと非構造化データを束ねた分析や Subscribe 申請を仲介するデモシナリオを紹介しています。データ分析エージェントを企業データに安全に接続したい方にぜひお読みいただきたい記事です。 ブログ記事「 AWS における AI エージェント対応のデータ基盤 (2) — SageMaker Catalog で行・列レベルのアクセス権を透過的に適用する 」を公開 上記シリーズの第 2 回です。AI エージェント経由のデータアクセスに、SageMaker Catalog で設定した行・列・オブジェクトレベルのアクセス制御をユーザー本人の権限で透過的に効かせるための実装パターンを解説しています。Cognito トークンから Tool Lambda の手元にプロジェクトロールの一時認証情報を運ぶ 5 ステップの認証情報変換フローや、Policy in AgentCore による Cedar ポリシーでのツール単位認可など、AgentCore Gateway を使った認可設計の実装の中身を詳しく追える内容になっています。 ブログ記事「 【開催報告】ガバメントクラウドワークショップ 2026 春 ～ AI で実践する開発・モダナイズ・運用 ～ 」を公開 5 月 19 日に開催された、ガバメントクラウドに携わる事業者向けワークショップの開催報告です。NTT データ様の Step Functions を中核としたフルマネージド・ジョブ基盤の事例、アクロクエストテクノロジー様の&nbsp;Amazon Bedrock&nbsp;を用いたセキュアな生成 AI 構築、NTT 西日本様の&nbsp; GenU &nbsp;と&nbsp;Amazon Bedrock AgentCore&nbsp;を活用した自治体向け AI エージェント、デジタル庁様による全府省庁約 18 万人向け生成 AI 利用環境「源内」の構築、AI エージェント開発・モダナイズ・運用の 4 テーマ別ワークショップなど、公共分野で生成 AI を活用するヒントが詰まった内容です。 ブログ記事「 Amazon Bedrock が、新しい高度なプロンプト最適化および移行ツールを導入 」を公開 5 月 14 日に発表された&nbsp;Amazon Bedrock Advanced Prompt Optimization&nbsp;の使い方を解説したブログです。元のプロンプトと最適化されたプロンプトを最大 5 個のモデルで同時に比較しながら最適化を進められるツールで、Lambda 関数によるカスタムスコアリング、LLM-as-a-judge ルーブリック、自然言語による方向性基準の 3 通りの評価方法をサポートしています。新しいモデルへの移行や、既存モデルでの精度改善に取り組まれている方にお勧めの記事です。 ブログ記事「 OpenSearch Agent Skills で agentic IDE に組み込み型のインテリジェンスを 」を公開 Claude、Cursor、Kiro&nbsp;などの agentic IDE の中で OpenSearch の専門知識をそのまま活用できる、オープンで組み合わせ可能なスキル集 OpenSearch Agent Skills の発表ブログです。Search、Logs、Solr から OpenSearch への移行という 3 つの基本スキルにより、自然言語の意図から検索アプリケーションの構築、ログ分析、移行作業を数分で実行できます。npx skills add opensearch-project/opensearch-agent-skills&nbsp;でインストールでき、MCP サーバーや追加コンポーネントは不要です。 ブログ記事「 AWS Security Agent のフルリポジトリコードスキャン機能のプレビュー提供開始 」を公開 AWS Security Agent&nbsp;に追加された、コードベース全体をコンテキスト認識型で分析するフルリポジトリコードレビュー機能の解説ブログです。アプリケーションのプロファイリング、脆弱性の検索、トリアージと重複排除、独立した検証という 4 ステージで動作し、既知のパターンと照合する従来の SAST が見逃すような、検証関数の不整合や設計レベルのギャップも検出します。検出結果は Verified / Could not verify を区別した構造化された証拠付きで提示されます。プレビュー期間中は既存の Security Agent のお客様に追加料金なしで提供されています。 ブログ記事「 Sim-to-Real と Real-to-Sim: 高性能な Physical AI を支える原動力 」を公開 現実世界で知覚・推論・行動するロボット、いわゆる Physical AI システムを支える Sim-to-Real / Real-to-Sim パイプラインを解説した記事です。シミュレーションと現実のギャップを埋めるためのドメインランダム化、現実環境をシミュレーション対応のデジタル表現に変換する Real-to-Sim、合成データ生成とフィルタリングなどを取り上げ、Vision Language Action モデル (VLA) の品質がシミュレーションデータの品質に依存することなどが説明されています。製造業・自動運転・医療・エネルギー・小売などの業界応用にも触れられています。 ブログ記事「 AI、技術的負債、そして AI を使いこなす力への道筋 」を公開 エンタープライズが直面する 3 つの共通課題（自社の技術資産の把握不足、AI 導入の停滞、AI を実践的に使いこなす力のギャップ）に対し、AWS Transform custom&nbsp;のモダナイゼーションエージェントを活用してコードからリアルタイムにドキュメントアーティファクトを自動生成するアプローチを提案しています。技術的負債の可視化と AI を使いこなす力の習得を同時に実現し、ポートフォリオ全アプリケーションへの展開を OKR として組織に定着させる進め方を、元 CTO の視点から実践的に解説した記事です。 サービスアップデート Amazon Bedrock がリクエストレベルの使用量属性のサポートを拡大 これまで Converse / ConverseStream API でサポートされていたリクエストレベルのメタデータ付与が、InvokeModel および InvokeModelWithResponseStream API でも利用できるようになりました。チーム、アプリケーション、環境、実験などの単位でモデル推論の使用量を個別のリクエストレベルでタグ付けし、Bedrock のモデル呼び出しログで分析できます。社内の利用状況を細かく可視化してコストを最適化したり、内部関係者へ利用量を報告したりするのが容易になります。Amazon Bedrock が利用可能な全ての AWS リージョンで利用できます。 Amazon SageMaker AI が推論エンドポイントで OpenAI 互換 API をサポート Amazon SageMaker Inference が OpenAI 互換 API をサポートするようになりました。OpenAI SDK、LangChain、Strands Agents&nbsp;などの既存ツールから、エンドポイント URL を変えるだけで SageMaker エンドポイントに接続できます。カスタム連携コードや SDK ラッパーの書き直しは不要で、独自の GPU インスタンス選択、VPC 内でのデータ保持、任意のオープンソース・ファインチューニング済みモデルの実行といった SageMaker のメリットをそのまま享受できます。東京、ソウル、シンガポール、シドニーなど 14 のリージョンで利用可能です。 AWS Transform に新しいエージェンティック移行アセスメント機能が追加 AWS Transform&nbsp;で、What-if シナリオ、カスタマイズ可能な前提条件、柔軟なファイル形式サポート、複数の TCO（総所有コスト）アセスメント機能を含む高度な移行アセスメント機能が利用できるようになりました。RVTools のエクスポート、CMDB データ、AWS Transform 検出ツール、サードパーティのディスカバリーツールなど、手元にあるあらゆるデータからアセスメントを開始できます。リージョン、リソース使用率、サービスマッピングをカスタマイズした What-if シナリオを作成して比較し、EC2、FSx、S3、SQL Server on EC2、仮想デスクトップのコストモデリングや、人材生産性・運用レジリエンス・ビジネスアジリティ・サステナビリティといった Cloud Value Framework の追加要素も含めて評価できます。 AWS Security Agent がペネトレーションテスト検出結果の検証スクリプトを生成 AWS Security Agent で、ペネトレーションテストで発見された各脆弱性に対して、その場で実行可能な検証スクリプトが自動生成されるようになりました。これまでは検出結果の詳細にある再現手順を手作業でなぞる必要がありましたが、今後はセキュリティチームがスクリプトをダウンロードし、環境変数を設定して対象システムに対して実行するだけで脆弱性を独立して再現・検証できます。スクリプトにはセットアップ手順、ドキュメント化された環境変数、機微な値のリダクションが含まれ、トリアージの効率化と修復の加速につながります。AWS Security Agent がサポートされている全リージョンで利用できます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 新緑がまぶしく、汗ばむ日も増えてきた五月下旬。爽やかな初夏の風とともに、嬉しいアップデートが届きました！「オンプレミスの VMware 環境をクラウドに移行したいけど、規模が大きくて…」とお悩みの方、朗報です。Amazon Elastic VMware Service（Amazon EVS）が、1 クラスターあたり最大 32 ホストまでサポートするようになり、大規模な VMware ワークロードもよりスムーズに AWS 上で動かせるようになりました。これまで規模の大きさがネックで移行をためらっていた企業様も、この季節の勢いに乗って、ぜひ一歩踏み出してみてはいかがでしょうか？ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年5月18日週の主要なアップデート 5/18(月) AWS Secrets Manager Agent の pre-fetching と IAM role assumption 機能の提供開始 AWS Secrets Manager Agent に 2 つの新機能が追加されました。pre-fetching 機能により、Agent 起動時に指定したシークレットを一括取得してキャッシュできるようになり、アプリケーション起動時のレイテンシーを削減できます。IAM role assumption 機能により、指定した IAM ロールを引き受けてシークレットを取得できるため、クロスアカウントでのシークレット取得が可能になります。これらの機能は、BatchGetSecretValue API を活用してコストを最適化し、ロールベースのアクセス制御によってセキュリティ態勢を強化します。 Amazon SageMaker Studio が SageMaker Flexible Training Plans による GPU キャパシティ予約をサポート Amazon SageMaker Studio の IDE (JupyterLab および Code Editor) で、SageMaker Flexible Training Plans (FTP) を利用した GPU キャパシティ予約が可能になりました。これにより、高需要の GPU インスタンスへの予測可能なアクセスが確保され、オンデマンドインスタンスと比較して最大 65% のコスト削減を実現できます。完全にセルフサービスで調達でき、インフラ管理は不要です。プラン終了 30 分前には自動的に通知が届き、作業の保存時間が確保されます。 Amazon Redshift が Iceberg テーブルへの ALTER TABLE と AWS Glue Data Catalog マウント経由の書き込みに対応 Amazon Redshift は、AWS Glue Data Catalog (awsdatacatalog) マウント経由での Apache Iceberg テーブルへの直接書き込みと、ALTER TABLE DDL による Iceberg テーブルのスキーマ、パーティション、プロパティの変更に対応しました。自動マウントされる awsdatacatalog を使用することで、外部スキーマを作成せずに Redshift の変換結果をデータレイクに保存でき、あらゆるエンジンからクエリできます。これは AWS Lake Formation と統合された Iceberg テーブルで特に有用です。従来、Iceberg テーブルの構造更新にはテーブルとデータの削除が必要で、データパイプラインの複雑性とレイテンシーが増大していました。Redshift で変更されたテーブルは、Amazon EMR や Amazon Athena などの他の Iceberg 互換エンジンとの互換性を維持します。 Amazon EVS が環境あたり 32 ホストのサポートを開始 Amazon Elastic VMware Service (Amazon EVS) が、環境あたり最大 32 の ESXi ホストをサポートするようになりました。これは従来の上限 16 ホストの 2 倍です。ユーザーは VMware Cloud Foundation (VCF) のドメインとクラスターを柔軟に構成でき、すべてのホストを 1 つの大規模クラスターに配置するか、複数の小規模クラスターに分散させるか、任意の組み合わせを選択できます。この拡張により、最大 32 ホストまでスケールアップするためのサービスクォータ増加リクエストが可能になり、複数環境を管理する運用オーバーヘッドを削減できます。 5/19(火) Amazon MWAA が Apache Airflow 3.2 をサポート開始 Amazon Managed Workflows for Apache Airflow (MWAA) が Apache Airflow 3.2 をサポートしました。このアップデートにより、データアウェアスケジューリング機能が強化され、asset partitioning を使用して S3 パスの特定パーティションなどデータの一部分のみでダウンストリーム DAG をトリガーできるようになりました。Human-in-the-Loop (HITL) 機能には操作や承認の履歴を一覧で確認できるビューが追加され、Grid View の仮想化により大規模 DAG のレンダリングが高速化されました。XCom を UI から直接管理できるようになり、PythonOperator で非同期関数をネイティブサポートするなど、開発者の生産性が向上しています。 5/20(水) Amazon SageMaker HyperPod が推論ワークロードのデータキャプチャに対応 Amazon SageMaker HyperPod が推論ワークロードのデータキャプチャに対応しました。この機能により、推論リクエストとレスポンスのペイロードを記録し、モデルモニタリング、コンプライアンス、デバッグ、オフライン分析に活用できます。データキャプチャは SageMaker エンドポイント、ロードバランサー、モデル Pod の 3 つのレベルで設定でき、必要な可視性に応じて選択または組み合わせて使用できます。キャプチャしたデータは非同期で Amazon S3 に配信され、推論パフォーマンスに影響を与えません。HyperPod Inference Operator または SageMaker JumpStart を通じてモデルをデプロイする際に設定できます。この機能は EKS オーケストレーターを使用する SageMaker HyperPod クラスターで利用可能で、SageMaker HyperPod がサポートされている全ての AWS リージョンで提供されます。 Amazon SageMaker Unified Studio でデータ品質ルールの設定と評価をサポート Amazon SageMaker Unified Studio は、AWS Glue Data Quality を基盤とするデータ品質ルールの設定と評価機能を追加しました。データエンジニア、アナリスト、データサイエンティストは、DQDL (Data Quality Definition Language) を使用してデータ品質ルールを定義し、SageMaker Unified Studio 内で直接評価を実行できます。カタログテーブルの静止データと Visual ETL ジョブ内のトランジットデータの両方に対応し、不良データがデータレイクや下流の分析・機械学習ワークロードに影響を与える前に検出できます。この機能は、Amazon SageMaker Unified Studio が利用可能なすべての AWS リージョンで、IAM Identity Center ベースドメインと IAM ベースドメインの両方で利用できます。 AWS Security Hub が未使用アクセスからのアイデンティティリスクを検出 AWS Security Hub が IAM Access Analyzer と統合し、未使用の IAM 権限、ロール、認証情報を AWS 組織全体で検出する機能を追加しました。中央セキュリティチームは、脅威、露出、ポスチャの findings と同じ統一コンソールでアイデンティティリスクを管理できるようになります。Security Hub を組織で有効化すると、サービスリンク IAM Access Analyzer が各メンバーアカウントに自動作成され、追加設定なしで 90 日間のアクセスアクティビティを評価し、未使用アクセスを検出します。また、実際の使用パターンに基づいて最小権限ポリシーをオンデマンドで生成する機能も提供されます。本機能は Security Hub Essentials に追加コストなしで含まれます。 Amazon Bedrock がリクエストレベル使用状況帰属のサポートを拡張 Amazon Bedrock は、InvokeModel および InvokeModelWithResponseStream API において、個別のリクエストレベルでモデル推論使用状況を特定のチーム、アプリケーション、環境、実験に帰属させることができるようになりました。この機能により、追加のリソースをプロビジョニングすることなく、組織全体での Amazon Bedrock の使用状況分布をきめ細かく可視化し、消費パターンの把握、コスト最適化、内部ステークホルダーへの使用状況報告が可能になります。この機能は、Amazon Bedrock が利用可能なすべての AWS 商用リージョンで提供されています。 5/21(木) Amazon RDS Custom for SQL Server が最新の GDR アップデートに対応 Amazon RDS Custom for SQL Server が、Microsoft SQL Server の最新 GDR (General Distribution Release) アップデートに対応しました。今回のアップデートでは、SQL Server 2019 CU32+GDR (バージョン 15.00.4465.1.v1) と SQL Server 2022 CU24+GDR (バージョン 16.00.4250.1.v1) をサポートします。これらのアップデートは、CVE-2026-32167 と CVE-2026-32176 の 2 つの権限昇格脆弱性に対処しています。RDS Custom インスタンスは、AWS マネジメントコンソール、AWS CLI、または AWS SDK を使用してアップグレードできます。 Amazon SageMaker AI が推論エンドポイント向け OpenAI 互換 API をサポート Amazon SageMaker Inference が OpenAI 互換 API をサポートし、OpenAI SDK、LangChain、Strands Agents などの既存ツールをエンドポイント URL の変更のみで利用できるようになりました。カスタム統合コードや SDK ラッパーは不要で、認証は既存の AWS 認証情報を使用します。これにより、独自の GPU インスタンスの選択、VPC 内でのデータ保持、オープンソースやファインチューン済みモデルの実行、ワークロードに合わせたオートスケーリングが可能になります。本機能は現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド、フランクフルト)、アジアパシフィック (東京、シンガポール、シドニー) を含む 14 リージョンで利用できます。 SageMaker Unified Studio が Glue コネクタのクロスサブネットジョブリトライを自動プロビジョニング Amazon SageMaker Unified Studio が、サブネット障害時の Glue ジョブリトライ用のコネクション自動作成機能をリリースしました。管理者がドメイン VPC に複数のプライベートサブネットを定義すると、システムが自動的にすべての新規プロジェクト向けにコネクタをプロビジョニングします。プライマリサブネットで IP アドレス枯渇やアベイラビリティゾーン障害が発生した場合、Glue ジョブは別のサブネットのコネクタで自動的にリトライされるため、エンジニアの手動介入が不要になります。 5/22(金) AWS Clean Rooms でコラボレーションの変更可能な payment configurations をサポート AWS Clean Rooms でコラボレーションメンバーの payment configurations (支払い設定) を変更できるようになりました。この機能により、SQL クエリ、PySpark ジョブ、ML モデルのトレーニングと推論、合成データ生成の各コストタイプについて、どのパートナーが支払いを担当するかを柔軟に指定できます。変更は change request (変更リクエスト) プロセスを通じて行い、全コラボレーションメンバーの承認が必要です。SQL と PySpark 分析では複数の authorized payers (承認された支払い者) を設定でき、分析実行時に支払い者を選択できます。 AWS Security Agent がペネトレーションテストで発見された脆弱性の検証スクリプトを自動生成する機能を追加 AWS Security Agent は、ペネトレーションテストで発見された脆弱性の検証スクリプトを自動生成する機能を追加しました。セキュリティチームは、手動で再現手順を追跡する代わりに、即実行可能なスクリプトをダウンロードし、環境変数を設定して対象システムに対して実行することで、脆弱性を独立して検証できます。これにより、トリアージの効率化と修復の迅速化が実現します。AWS Security Agent がサポートされる全ての AWS リージョンで利用可能です。 Amazon SageMaker Unified Studio が IAM ベースドメインでビジネスメタデータとガバナンスをサポート Amazon SageMaker Unified Studio は、IAM ベースドメインでビジネスコンテキスト、メタデータ、データガバナンス機能のサポートを開始しました。これにより、IAM 認証を使用する環境でも、AWS Glue Data Catalog のテーブルにビジネス名や説明、README ドキュメントを追加できるようになります。AI 生成メタデータ機能により、大量のテーブルのカタログ化作業を自動化できます。また、ビジネスグロサリーによる用語の標準化、メタデータフォームテンプレートによる構造化属性の管理、サブスクリプションベースのアクセス管理により、組織全体でのデータ検索と安全な共有が実現します。この機能は、SageMaker Unified Studio が利用可能なすべての AWS リージョンで提供されています。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本記事は 2026 年 2 月 12 日 に公開された「 Achieve near-zero downtime database maintenance&nbsp;by using blue/green deployments with AWS JDBC Driver 」を翻訳したものです。 最新のアプリケーションは継続的な可用性を求めており、データベースのメンテナンス運用は開発チームにとって重要な課題となっています。データベース更新、パッチ適用、アップグレードに対する従来のアプローチでは、ダウンタイムや接続障害、手動介入が必要となり、ビジネスオペレーションの中断やユーザーエクスペリエンスに影響を与えることがあります。 Amazon Relational Database Service (Amazon RDS) の Blue/Green デプロイメントは、並列のデータベース環境を作成することで計画的なダウンタイムの課題に対処します。本番環境に適用する前にデータベースの変更をテストできるようにします。このアプローチによりメンテナンスウィンドウは大幅に短縮されますが、切り替えプロセス中に接続の切断、DNS 伝播の遅延、接続障害時の手動介入など、わずかな中断が発生する可能性があります。 AWS は 2023 年に AWS JDBC Driver をリリースし、標準の JDBC ドライバーに AWS 固有の機能を追加しました。PostgreSQL、MySQL、MariaDB の JDBC ドライバー上のレイヤーとして構築されたラッパーで、Amazon Aurora と Amazon RDS の機能をサポートします。Amazon Aurora の接続追跡、AWS Identity and Access Management (IAM) 認証、読み取り/書き込みトラフィック分割など、複数のプラグインが含まれています。フェイルオーバー管理、モニタリング、認証、負荷分散などの機能を AWS JDBC Wrapper Driver でアプリケーションに統合できます。 本記事では、AWS JDBC Driver の Blue/Green デプロイメントプラグイン を紹介します。 組み込みプラグイン で、Blue/Green デプロイメントの切り替え時に接続ルーティング、トラフィック管理、切り替え検出を自動的に処理します。プラグインの設定方法と使用方法を示し、切り替え時にダウンタイムを最小限に抑える方法を説明します。 AWS JDBC Driver Blue/Green デプロイメントプラグインの紹介 Blue/Green デプロイメントプラグインは、AWS JDBC Driver の組み込みコンポーネントで、Blue/Green デプロイメントと連携して以下を提供します。 切り替えの自動検出と準備 遷移中のトラフィック管理 古い DNS の問題を回避する DNS 非依存のルーティング 最小限の設定変更 — JDBC 接続設定のみ プラグインは以下のように動作します。 RDS メタデータテーブルを通じて Blue/Green デプロイメントのステータスを監視 Blue と Green 両環境の接続インベントリを維持 切り替えフェーズに基づいてトラフィックをルーティング 遷移中の接続障害をグレースフルに処理 主な機能 AWS JDBC Driver Blue/Green デプロイメントプラグインは、データベース切り替え時の中断を最小限に抑えるために連携して動作する 3 つのコア機能を提供します。Blue/Green デプロイメントのフェーズの自動検出、両環境の適切なインベントリ管理、および切り替え状況に基づく動的なトラフィックルーティングです。これらの機能はバックグラウンドで継続的に動作し、接続障害を軽減しますが、切り替えプロセス中に発生する可能性のある一時的な例外に対応するため、アプリケーション側でもリトライロジックを実装することが推奨されます。 自動切り替え検出 プラグインはバックグラウンド監視スレッドを使用し、約 1 秒ごとに Blue/Green デプロイメント API をポーリングしてデプロイメントのステータス変更やフェーズの遷移を継続的に検出します。フェーズの変更が検出されると、即座に接続ルーティング戦略を調整します。プロアクティブな監視により、切り替えイベントを予測して接続管理を準備できるため、Blue/Green 遷移全体を通じてアプリケーションの接続性を向上させます。 プラグインは Blue/Green デプロイメントのステータスを継続的に監視し、以下のようにフェーズ遷移を検出します。 フェーズ検出タイムライン : NOT_CREATED : Blue/Green デプロイメントプラグインのコンポーネントがまだ作成されていません。 CREATED : Blue/Green デプロイメントが存在し、プラグインコンポーネントが初期化されます。プラグインは Blue と Green 両環境のインベントリを作成し、クラスターエンドポイントを対応する IP アドレスにマッピングします。両環境のヘルスステータスを追跡する監視接続が確立されます。 PREPARATION : プラグインはトラフィックをリダイレクトする接続ルーティングルールを確立します。各ソースエンドポイント (Blue 環境) を特定の IP アドレスにマッピングする設定を作成し、新しい接続が適切なターゲットに向けられる一方で既存の接続はアクティブなまま維持されます。このフェーズでは、現在のデータベース操作を中断することなく、最終的なトラフィック切り替えに必要なインフラストラクチャをセットアップします。 IN_PROGRESS : アクティブな切り替えが進行中で、遷移中はソース (Blue) とターゲット (Green) 両環境でクエリ実行が一時停止されます。ソース (Blue) 環境への JDBC コールの一時停止によりデータベース負荷を軽減し、ターゲット (Green) 環境でのレプリケーションの追いつきを可能にします。プラグインは Blue 環境の IP アドレスに直接ソースエンドポイント (Blue) への新しい接続をリダイレクトして古い DNS エントリへの接続を排除し、ターゲットエンドポイント (Green) への新しい接続は一時停止します。 POST : プラグインは両環境のクラスタートポロジーと DNS エントリを更新します。プラグインは DNS 伝播を監視し、DNS エントリが安定するにつれて IP ベースのルーティングからホスト名ベースの接続に段階的に移行します。 COMPLETED : 切り替えが正常に完了しました。 プラグインは AWS Blue/Green デプロイメントのステータスを以下のフェーズにマッピングします。 Blue/Green デプロイメントのステータス Blue/Green デプロイメントプラグインのフェーズ プラグインのアクション AVAILABLE CREATED 監視を初期化する。 SWITCHOVER_INITIATED PREPARATION 新しい接続をリダイレクトする接続ルーティングインフラストラクチャを確立する。 SWITCHOVER_IN_PROGRESS IN_PROGRESS すべてのクエリ実行を一時停止し、新しい接続を Blue 環境の IP アドレスにルーティングする。 POST 最初は IP ベースのルーティングでトラフィックを処理し、段階的にホスト名ベースの接続に移行する。 SWITCHOVER_COMPLETED COMPLETED 監視を終了し、通常の操作を再開する。 接続インベントリ管理 プラグインは Blue と Green 両環境のインベントリをすべて維持し、自動切り替え操作を実現します。 Blue 環境の追跡 : CREATED フェーズ中に、プラグインは Blue 環境のすべてのコンポーネント (クラスターエンドポイント、リーダーエンドポイント、ライターエンドポイント、個別のインスタンスエンドポイント) を検出しカタログ化します。各エンドポイントについて、対応する IP アドレスを解決して保存し、現在の本番環境の完全なマッピングを作成します。このインベントリは切り替え操作時の比較のベースラインとなります。 Green 環境の追跡 : 同時に、プラグインは対応するすべての Green 環境のエンドポイントを特定しマッピングします。Blue/Green デプロイメントのメタデータを使用して、各 Blue エンドポイントに対応する Green の対応先を把握し、Blue と Green コンポーネント間の関係を確立します。すべての Green エンドポイントの IP アドレスを解決し、切り替え時に即座に使用できるよう維持します。 適切なトラフィック管理 切り替え時に、プラグインは接続の確立とクエリ実行の両方を対象としたトラフィック管理を実装します。 接続管理 : ルーティング戦略を使用して新しいデータベース接続の確立を制御 クエリ実行管理 : 重要なフェーズ中の既存接続での SQL ステートメントの実行を制御 フェーズごとのトラフィック管理: PREPARATION: Blue エンドポイントへの新しい接続は直接 IP アドレスを使用してルーティングされます。 既存の接続は通常どおり継続します。 DNS 解決をバイパスする IP ベースのルーティングが使用されます。 IN_PROGRESS: Green エンドポイントへの新しい接続は一時停止されます。 Blue エンドポイントへの新しい接続はデフォルトでダイレクト IP ルーティングを使用しますが、 bgSuspendNewBlueConnections が有効な場合は一時停止されます。 Blue と Green 両エンドポイントですべてのクエリ実行が一時停止されます。 アクティブな切り替え期間中、Blue と Green 両環境への既存の接続はドロップされます。 POST: Blue エンドポイントへの新しい接続は、IP ベースのルーティングを使用して Green エンドポイント (新しい Blue 環境) にルーティングされます。 Blue エンドポイントの DNS エントリが更新されると、ホスト名ベースのルーティングに移行します。 Green エンドポイント (古い Green 環境) への新しい接続は拒否されます。 COMPLETED: 新しいアクティブなエンドポイントへの通常のルーティングが再開されます。 前提条件 データベースエンジンの要件 データベースエンジン Blue 環境 Green 環境 Amazon Aurora PostgreSQL エンジンリリース 17.5、16.9、15.13、14.18、13.21 以降 エンジンリリース 17.5、16.9、15.13、14.18、13.21 以降 Amazon RDS for PostgreSQL rds_tools v1.7 以降 (17.1、16.5、15.9、14.14、13.17、12.21) rds_tools v1.7 以降 (17.1、16.5、15.9、14.14、13.17、12.21) Amazon Aurora MySQL 任意のデータベースエンジンバージョン エンジンリリース 3.07 以降 Amazon RDS for MySQL Blue/Green デプロイメント 対応バージョン Blue/Green デプロイメント 対応バージョン アプリケーションスタックの要件 AWS JDBC Driver バージョン 2.6.4 以降 データベースドライバー: PostgreSQL JDBC ドライバーまたは MySQL/MariaDB JDBC ドライバー ランタイム環境: Amazon Corretto 8 以上または Java 8 以上 クラスターのセットアップとトポロジー AWS JDBC Driver Blue/Green プラグインがデータベースのアップグレードやメンテナンス中にアプリケーションのダウンタイムをどのように最小化するかを示すため、テスト環境をセットアップしました。一般的な本番トポロジーを表す、1:1 のライター/リーダー構成の Aurora PostgreSQL クラスターで構成されています。 サンプル Java アプリケーションはクラスターのライターエンドポイントに対して一定の読み取りワークロードを生成し、Blue/Green デプロイメントの切り替え中にプラグインがアプリケーションの接続性を向上させることを実証します。 以下の図のように、Blue/Green デプロイメントを作成しました。 ソース (Blue) 環境には以下が含まれます。 1 つのプライマリライターインスタンス 1 つのリーダーインスタンス 関連するクラスターおよびインスタンスエンドポイント ターゲット (Green) 環境は以下のトポロジーを備えています。 対応するライターインスタンス 対応するリーダーインスタンス 同等のエンドポイント設定 この対称的なセットアップにより、プラグインが Blue/Green デプロイメントのステータスを監視し、切り替えの進行に合わせてアプリケーション接続を適切なエンドポイントに自動的にリダイレクトするため、ターゲット (Green) 環境が切り替えプロセス中にワークロードリクエストを処理できます。 Blue/Green デプロイメントプラグインを使用した Java アプリケーションのセットアップ AWS JDBC Driver をアプリケーションに統合するには、依存関係管理に Maven または Gradle ビルドシステムを使用します。サンプルアプリケーションでは Maven を使用したセットアップを示していますが、依存関係は Gradle プロジェクトでも動作します。 Maven の依存関係 pom.xml ファイルを更新して以下の依存関係を追加します。 &lt;dependency&gt; &nbsp;&nbsp; &nbsp;&lt;groupId&gt;software.amazon.jdbc&lt;/groupId&gt; &nbsp;&nbsp; &nbsp;&lt;artifactId&gt;aws-advanced-jdbc-wrapper&lt;/artifactId&gt; &nbsp;&nbsp; &nbsp;&lt;version&gt;2.6.4&lt;/version&gt; &lt;/dependency&gt; &lt;dependency&gt; &nbsp;&nbsp; &nbsp;&lt;groupId&gt;org.postgresql&lt;/groupId&gt; &nbsp;&nbsp; &nbsp;&lt;artifactId&gt;postgresql&lt;/artifactId&gt; &nbsp;&nbsp; &nbsp;&lt;version&gt;LATEST&lt;/version&gt; &lt;/dependency&gt; Gradle ユーザーは、同じ依存関係を Gradle の依存関係構文で build.gradle ファイルに追加できます。 主なプラグインパラメーター Blue/Green デプロイメントプラグインの以下のパラメーターを設定します。 wrapperPlugins : データベース接続用にロードしてアクティブ化する AWS JDBC Wrapper プラグインを指定します。Blue/Green デプロイメントプラグインを使用するには、以下の Java コードのように bg プラグインをロードする必要があります。 props.setProperty("wrapperPlugins", "bg"); bgdId : プラグイン内で特定の Blue/Green デプロイメント操作を追跡するためのユーザー定義の一意の識別子を指定します (デフォルト: 1)。このパラメーターは AWS コンソールの Blue/Green デプロイメント名やリソース ID とは関係なく、複数の Blue/Green デプロイメントを同時に監視する際にプラグインが区別するための内部ラベルです。例えば、AWS アカウントで 3 つの Blue/Green デプロイメントが同時に実行されている場合、各デプロイメントに一意の bgdId 値 (1、2、3 や bg1、bg2、bg3 など) を割り当て、プラグインが各デプロイメントのステータスと切り替えイベントを独立して追跡・監視できるようにする必要があります。 blue-green-monitoring-connectTimeout : Blue/Green デプロイメントのステータスを追跡する監視接続の接続タイムアウトをミリ秒で設定します (デフォルト: 30000)。プラグインはデプロイメントフェーズの変更を検出するために個別の監視接続を確立するため、このパラメーターは重要です。適切なタイムアウトにより、プラグインは無限に待機することなくデプロイメントの進行状況を確実に監視できます。 blue-green-monitoring-socketTimeout : デプロイメントステータスを追跡する監視接続のソケットタイムアウトをミリ秒で設定します (デフォルト: 30000)。デプロイメントフェーズの確認時に監視操作が無限にブロックされることを防ぎ、ネットワークの問題や応答の遅延時にもプラグインの応答性を維持するために不可欠です。 bgSwitchoverTimeoutMs : プラグインが Blue/Green デプロイメントのステータスを監視し続ける最大時間をミリ秒で定義します (デフォルト: 300000 — 5 分)。このパラメーターは、プラグインがデプロイメントの切り替えプロセスをタイムアウトするまでアクティブに追跡する期間を決定します。Blue/Green 切り替え操作を開始する前に定義した切り替えタイムアウトと同じかそれ以上の値に設定してください。切り替えがタイムアウト前に正常完了した場合、Blue/Green デプロイメントステータスの監視は自動的に停止します。プラグインが無期限に監視せず、Amazon RDS の切り替えプロセスが完了し検出されるのに十分な時間を確保するため、適切な値を設定してください。 bgSuspendNewBlueConnections : 切り替えフェーズ中に Blue クラスターへの新しい接続を一時停止するかどうかを制御します (デフォルト: false)。true に設定すると、プラグインはアクティブな切り替えフェーズ中に Blue ノードへの新しい接続の試行を一時的に停止します。 以下のコードは Blue/Green プラグインパラメーターの設定方法を示しています。 // Configure blue/green plugin parameters props.setProperty("wrapperPlugins", "bg,auroraConnectionTracker,failover2,efm2"); props.setProperty("bgdId","blue-green-demo-id"); props.setProperty("blue-green-monitoring-connectTimeout", "20000"); props.setProperty("blue-green-monitoring-socketTimeout", "20000"); props.setProperty("bgSwitchoverTimeoutMs","600000"); テストでは、Blue/Green プラグインの効果を測定するため、Blue/Green デプロイメントの切り替え中に Aurora PostgreSQL クラスターのライターエンドポイントに対して継続的な読み取り専用ワークロードを実行する 2 つの同一アプリケーションを評価しました。Blue/Green プラグインなしのベースラインアプリケーションは、切り替えフェーズ中に接続の中断が発生し、接続障害を処理するためにアプリケーションレベルのリトライロジックが必要でした。400 件のクエリ中 2 件の接続障害が発生し、切り替えプロセス中のアプリケーションダウンタイムは 30.21 秒で、新しいエンドポイントへの手動での接続再確立が必要でした。 Blue/Green プラグインを有効にし、Blue 接続の一時停止を有効にしたアプリケーションは、切り替えフェーズ中の耐障害性が向上しました。テストシナリオでは、プラグイン有効のアプリケーションは 400 件のクエリ中接続障害がゼロで、切り替えプロセス中のワークロード実行の一時停止は 11.77 秒、自動ルーティングの一時停止と回復で接続を管理しました。プラグインはアプリケーション起動直後に Blue/Green デプロイメントを検出し、デプロイメントプロセス全体を通じてソースとターゲット両環境を継続的に監視しました。POST フェーズと COMPLETED フェーズでは、プラグインがすべてのクエリをターゲット (Green) 環境に自動的にルーティングし、切り替えプロセス中の手動エンドポイント更新が不要になりました。ただし、ネットワーク遷移中に発生する可能性のある接続関連の例外に対応するため、アプリケーションにリトライロジックを実装することを推奨します。 Blue/Green デプロイメントのメタデータとライフサイクルのサマリー Blue/Green デプロイメントの切り替え中に、プラグインがデプロイメントの進行状況とステータスを追跡するメタデータを監視できます。Aurora PostgreSQL の場合は get_blue_green_fast_switchover_metadata() 関数で、デプロイメントフェーズ、トポロジーの変更、切り替えステータスに関するリアルタイム情報を取得します。RDS PostgreSQL の場合は rds_tools.show_topology() 関数が同様のメタデータを提供します。RDS/Aurora MySQL インスタンスは mysql.rds_topology テーブルを使用します。デプロイメントのステータスを確認し、Blue と Green 環境間の遷移が正常に完了したことを検証できます。以下の例はステータス変更のサンプルです。 -[ RECORD 1 ]--+----------------------------------------------- id | 1758432615 endpoint | apg-17.cluster.&lt;aws-region&gt;.rds.amazonaws.com port | 5432 role | BLUE_GREEN_DEPLOYMENT_SOURCE status | AVAILABLE version | 1.0 update_stamp | 1759801475 -[ RECORD 2 ]--+----------------------------------------------- id | 756345441 endpoint | apg-17-green-xxx.cluster.&lt;aws-region&gt;.rds.amazonaws.com port | 5432 role | BLUE_GREEN_DEPLOYMENT_TARGET status | AVAILABLE version | 1.0 update_stamp | 1759801475 postgres=&gt; SELECT * FROM get_blue_green_fast_switchover_metadata('aws_jdbc_driver-" + DriverInfo.DRIVER_VERSION + "'); -[ RECORD 1 ]--+---------------------------------------------- id | 756345441 endpoint | apg-17.cluster.&lt;aws-region&gt;.rds.amazonaws.com port | 5432 role | BLUE_GREEN_DEPLOYMENT_TARGET status | SWITCHOVER_COMPLETED version | 1.0 update_stamp | 1759801921 詳細なパフォーマンスメトリクスと切り替えタイムラインはプラグインによりアプリケーションログに自動的に記録されます。 wrapperLoggerLevel を fine または finest に設定すると、 logSwitchoverFinalSummary やその他の診断情報を取得して分析とトラブルシューティングに利用できます。 Oct 14, 2025 12:11:39 AM software.amazon.jdbc.plugin.bluegreen.BlueGreenStatusProvider logSwitchoverFinalSummary FINE: [bgdId: 'blue-green-demo-id'] ---------------------------------------------------------------- timestamp &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;time offset event (ms) &nbsp; ---------------------------------------------------------------- 2025-10-14T00:10:08.4603764Z -44135 ms &nbsp; NOT_CREATED 2025-10-14T00:10:08.5063897Z -44089 ms &nbsp; CREATED 2025-10-14T00:10:49.7132486Z -2882 ms &nbsp; PREPARATION 2025-10-14T00:10:52.5956307Z &nbsp; &nbsp; 0 ms &nbsp; IN_PROGRESS 2025-10-14T00:11:04.2233952Z 11627 ms &nbsp; POST 2025-10-14T00:11:09.3191489Z 16723 ms &nbsp; Green topology changed 2025-10-14T00:11:38.7487807Z &nbsp; 46153 ms &nbsp; Blue DNS updated 2025-10-14T00:11:39.0190950Z &nbsp; 46423 ms &nbsp; Green DNS removed 2025-10-14T00:11:39.0193661Z &nbsp; 46423 ms &nbsp; COMPLETED ---------------------------------------------------------------- logSwitchoverFinalSummary は、Blue/Green デプロイメントのライフサイクル全体の時系列ビューを提供します。 切り替え前フェーズ (負の時間) : -44.13 秒 : プラグインが初期化され、Blue/Green デプロイメントのステータスを最初に確認します (NOT_CREATED 状態)。 -44.08 秒 : プラグインが Blue/Green デプロイメントの存在を検出し (CREATED に遷移)、すぐに Blue と Green 両環境のインベントリの作成と監視接続の確立を開始します。 -44.08 〜 -2.88 秒 : プラグインは両環境への接続を継続的に監視・維持します。 -2.88 秒 : RDS Blue/Green デプロイメントが切り替えを開始します (プラグインが PREPARATION フェーズを検出)。準備フェーズが始まり、プラグインは差し迫った切り替えに備えます。 -2.88 〜 0 秒 : 最終準備ウィンドウが完了します。 アクティブおよび切り替え後フェーズ (0 ms 以降) : 0 秒 : IN_PROGRESS フェーズが開始し、アクティブな切り替えが実行されます。 0 〜 +11.62 秒 : IN_PROGRESS フェーズが進行中で、アクティブな切り替え時間です (接続障害が発生する可能性があります)。 +11.62 秒 : POST フェーズが開始します。プラグインはソース (Blue) とターゲット (Green) 両環境をアクティブに監視し、Green トポロジーの変更を検出して、新しい接続をターゲット (Green) 環境にルーティングし始めます。 +16.72 秒 : Green トポロジーが変更されます。プラグインは Green クラスターのトポロジーテーブルが新しいエンドポイント ( green- プレフィックスなし) で更新されたことを検出し、インフラストラクチャの切り替えが機能的に完了したことを示します。 +46.15 秒 : Blue DNS が更新されます。プラグインは元の Blue クラスターエンドポイントの DNS レコードが新しいインフラストラクチャ (新しい IP、以前の Green 環境) を指すように更新されたことを検出します。 +46.42 秒 : Green DNS が削除されます。プラグインは Green クラスターエンドポイント ( green- プレフィックス付き) の DNS レコードが削除され、IP アドレスに解決されなくなったことを検出します。 +46.42 秒 : COMPLETED — すべての操作が完了しました。 まとめ 本記事では、AWS JDBC Driver 内の Blue/Green デプロイメントプラグインが Blue/Green デプロイメントの切り替えを自動的に管理し、データベースメンテナンスのダウンタイムをほぼゼロに抑えることを実証しました。プラグインの適切な接続ルーティングとトラフィック管理機能により、RDS と Aurora で Blue/Green デプロイメントを実行しながらデータベースメンテナンス中のアプリケーションの可用性と耐障害性を向上できます。ぜひお客様のユースケースで Blue/Green デプロイメントプラグインを試し、フィードバックや質問を AWS Advanced JDBC Wrapper GitHub discussions で共有してください。 AWS Advanced JDBC Wrapper Driver の追加機能については、以下の関連ブログをご覧ください。 IAM 認証と AWS Secrets Manager の統合については、紹介ブログ「 Introducing the Advanced JDBC Wrapper Driver for Amazon Aurora 」をご覧ください。 RDS Multi-AZ アップグレード時の 1 秒以下のダウンタイム達成については「 Achieve One Second or Less Downtime with the Advanced JDBC Wrapper Driver when Upgrading Amazon RDS Multi-AZ DB Clusters 」をご覧ください。 Initial Connection Strategy プラグインと Failover2 プラグインを使用した接続管理の強化については「 Demystifying the AWS Advanced JDBC Wrapper Plugins 」をご覧ください。 Blue/Green デプロイメントプラグインを他の AWS JDBC Driver の機能と組み合わせることで、データベースメンテナンスプロセスを簡素化しながら、より耐障害性の高いアプリケーションを構築できます。 著者について Jason Pedreza Jason は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。ペタバイト規模の環境における大規模データ変換や移行を専門としています。リレーショナルデータベース、データウェアハウス、データ分析、クラウドネイティブテクノロジーの豊富な知識を活かし、お客様の高可用性データベースソリューションの設計を支援しています。 Chandra Pathivada Chandra は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのオープンソースデータベースエンジンに注力しています。AWS 上でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2026年 3 月号 はお読みいただけましたでしょうか。皆さんのお役に立つ内容があれば幸いです！ 今月は 以下の内容でアップデート情報をお届けします。 Amazon Connect Family 2026 年 4 月のアップデート一覧 AWS Contact Center Blog のご紹介 AWS Black Belt オンラインセミナー (Amazon Connect Customer 関連) 今月のアップデートに関するよくある質問 1. Amazon Connect Family 今月は、アップデート一覧の前に大きなニュースをお伝えします。2026年4月28日、Amazon Connect は単一の製品から4つのエージェンティック AI ソリューションで構成されるファミリーへと進化しました。AWS Applied AI Solutions 担当シニアバイスプレジデントの Colleen Aubrey が About Amazon のブログ で発表した通り、Amazon Connect は以下の4つのソリューションに拡張されました。 リューション 対象領域 概要 Amazon Connect Customer カスタマーエクスペリエンス 従来の Amazon Connect(Unlimited AI)。State Farm、Air Canada、U.S. Bank などが利用する、音声・チャット・デジタルチャネルを統合した AI 駆動コンタクトセンター Amazon Connect Decisions サプライチェーン 25以上の専門ツールと Amazon の30年にわたるオペレーション科学に基づき、需要予測・在庫計画・例外対応を AI チームメイトが支援 Amazon Connect Talent 採用 AI エージェントが24時間365日の音声面接を実施し、構造化された評価とスコアリングで採用プロセスを数週間から数日に短縮 Amazon Connect Health ヘルスケア 臨床現場の管理業務（スケジューリング、ドキュメンテーション等）を AI で自動化し、医療従事者が患者ケアに集中できる環境を実現 これらのソリューションに共通するのは、Amazon 自身が大規模に運用してきた実績に基づいている点です。4 億件以上の SKU を管理するサプライチェーン、2025 年ピークシーズンだけで 25 万人を採用した人材オペレーション、毎日数百万件の顧客対応、そして One Medical や Amazon Pharmacy を通じた医療サービス。これらの現場で培われた AI システムが、各ソリューションの基盤になっています。 設計思想として「ヒューモーフィズム（humorphism）」と呼ばれるアプローチが採用されています。従来のソフトウェアがデスクトップ・フォルダ・ボタンというメタファーで設計されていたのに対し、Amazon Connect の各ソリューションは「AI チームメイト」として振る舞います。ビジネスコンテキストを学習し、チームの働き方に適応し、使うほど賢くなる。ツールではなく、同僚のように機能する AI です。 なお、これまでの AI 駆動のコンタクトセンターソリューションとしての「Amazon Connect」は、今後「Amazon Connect Customer」という名称になります。 詳細は以下をご覧ください: Amazon Connect Decisions Amazon Connect Talent Amazon Connect Customer Amazon Connect Health 2. 2026 年 4 月のアップデート一覧 AI を活用した採用を支援する Amazon Connect Talent (現在はプレビュー版) – 2026/04/28 Amazon Connect Talent のプレビュー版が利用可能になりました。これにより、人材獲得部門のリーダーは AI を活用した採用ソリューションを利用でき、候補者の選定を大規模にスピードアップできます。Amazon Connect Talent は、何十年にもわたる Amazon の採用の知見から情報を得て、AI エージェントを使用して体系的な音声面接を実施し、科学的根拠に基づく評価を実施し、一貫性のある候補者スコアリングを行います。これにより、採用担当者は戦略的な意思決定に集中できるようになります。候補者は、あらゆるデバイスから 24 時間 365 日面接を受けられます。採用担当者は、AI チームメイトが生成したスコア、文字起こし、詳細な候補者評価を確認できるため、一貫した客観性を保ちながらより迅速に採用決定を行えます。プレビュー機能には、AI 主導のスキル評価、適応型質問機能を備えた AI 主導の音声面接、ブランドに合わせてカスタマイズ可能なモバイルファースト候補者ポータル、包括的な採用担当者ダッシュボード、システム管理者オンボーディングツール、迅速なデプロイのための応募者追跡システム (ATS) 統合が含まれます。Amazon Connect Talent は雇用の急増に対応できるように拡張されており、数百人の候補者を同時に評価できます。 Amazon Connect Talent は米国東部 (バージニア北部) および米国西部 (オレゴン) リージョンで利用できます。 AWS が Amazon Connect Decisions を発表 – 2026/04/28 AWS は Amazon Connect Decisions の一般提供を発表しました。これは、サプライチェーンチームが場当たり的な対応から脱却し、先回りしたオペレーションへ移行できるよう支援する、エージェンティック AI の計画およびインテリジェンスソリューションです。Amazon における 30 年間の運用知見と 25 を超える専用サプライチェーンツールを組み合わせることで、AI のチームメイトがビジネスに適応し、チームの意思決定から学習し、継続的にオペレーションを改善します。Amazon Connect Decisions は、小売業、CPG、自動車、工業製造業界など、既存のシステムを入れ替えることなくサプライチェーン業務を変革したいと考えている企業が利用できます。AI のチームメイトは 24 時間 365 日稼働し、需要シグナルを整合して合意済み予測にまとめ、制約を考慮した供給計画を生成し、サプライチェーン全体のオペレーションをモニタリングします。これにより、差異を検出し、自動化された根本原因分析を実行し、数千件の例外をトリアージして、ビジネス上の優先事項に基づき、最も重要な事項のみを実行可能な推奨事項として提示します。 こちら をクリックして無料トライアルを開始することが可能です。Amazon Connect Decisions は米国東部 (バージニア北部) および欧州 (アイルランド) リージョンで利用できます。 Amazon Connect チャットでやり取りできるファイル容量はどれくらいですか？添付ファイル上限が100 MBに拡大、カスタムファイルタイプも追加可能になりました – 2026/04/27 Amazon Connect Customer では、チャット、ケース、およびタスク用の添付ファイルサイズが、以前の 20 MB の制限から最大 100 MB に引き上げられました。また、管理者は Amazon Connect Customer の管理ウェブサイトまたは Amazon Connect API を使用して、チャット、E メール、ケース、およびタスク全体に対する制限を引き上げ、添付ファイルのカスタムファイル拡張子を設定できます。例えば、企業顧客をサポートする、あるテクノロジー企業では、診断バンドルやログアーカイブなどのファイルをチャットで最大 100 MB まで受け付けられるようになったことで、やり取りの回数が減少し、問題をより迅速に解決できるようになりました。また、ある金融サービス企業では、署名済みの契約書やコンプライアンスドキュメント用のファイル拡張子を追加して、顧客がチャットや E メールに直接書類を添付できるようになりました。 管理者ガイド 添付ファイルの有効化 Amazon Connect Customer でスーパーバイザーがエージェントのステータスを変更した履歴は確認できますか？CloudTrail でのログ記録が可能になりました – 2026/04/24 Amazon Connect Customer の分析ダッシュボードを通じて行われたエージェントアクティビティのステータス変更が AWS CloudTrail に監査ログとして記録されるようになりました。この機能強化により、誰がエージェントのアクティビティステータスを変更したのか、いつ変更が行われたのかを可視化できるため、コンタクトセンターのコンプライアンスや運用管理を強化できます。例えば、エージェントが休憩に入る場合、スーパーバイザーはエージェントのステータスを「Available」から「Break」(カスタムステータス)に変更できます。このアクションは、スーパーバイザーの ID、タイムスタンプ、ステータス変更の具体的な内容などの詳細情報とともに CloudTrail にキャプチャされます。追加の設定は不要で、AWS アカウントで CloudTrail のログ記録が有効になっていれば、分析ダッシュボードでのステータス変更が自動的にログに記録されます。 管理者ガイド CloudTrail による Amazon Connect API コールのログ記録 エージェントアクティビティステータスの変更 Amazon Connect Customer の AI エージェントのパフォーマンスはどのように測定できますか？目標達成率・忠実性スコアなど8つの新メトリクスが登場しました – 2026/04/24 Amazon Connect Customer は、目標達成率、忠実性スコア、ツール選択精度など、AI エージェントのパフォーマンスを測定および改善するための新しいメトリクス 8 つの提供を開始しました。これらのメトリクスを活用することで、AI による顧客対応の品質を把握できます。これにより、AI エージェントによる対応結果を正確に測定し、継続的に改善できるようになります。 今回のリリースにより、AI エージェントが顧客のリクエストを正常に解決したかどうかをモニタリングし、忠実性を評価し、文脈に沿わないハルシネーションを検出することが可能になります。ツールの選択と使用の精度を評価したり、有効に設定されている場合は「サムズアップ/ダウン」評価を用いて顧客フィードバックを収集したりすることもできます。これらの新しいメトリクスは、Amazon Connect の AI エージェントパフォーマンスダッシュボードで使用できます。また、 GetMetricDataV2 API や 分析データレイク を活用すれば、独自のレポート作成や既存の分析ワークフローへの統合も行えます。 管理者ガイド AI エージェントのパフォーマンスダッシュボード Amazon Connect Customer のアウトバウンドキャンペーンで発信先に優先順位を付けられますか？最大10個のプロファイル属性に基づく優先ダイヤルが可能になりました – 2026/04/21 Amazon Connect Customer のアウトバウンドキャンペーンでは、ジャーニー内で音声キャンペーンと音声アクティビティの最大 10 個のプロファイル属性に基づいて、優先順位を用いてコンタクト先にダイヤルできるようになりました。 これにより、価値の高い顧客や時間的制約、対応期限のある案件にエージェントの時間を集中させることができ、キャンペーンの効果とコンバージョン率が向上します。Customer Profiles でセグメント作成時に「 セグメントの並び替え – オプション 」を設定し、セグメントコンタクトの優先順位を指定すると、顧客生涯価値、アカウント階層、予約日などの属性でセグメントをソートできます。たとえば、金融サービスチームが契約更新間近の価値の高いアカウントへの働きかけを優先したり、医療提供者が予約が最も早い患者に最初に連絡するようにしたりできます。初期ダイヤル試行が再試行よりも常に優先されるため、キャンペーンの実行全体で優先順位が維持されます。 管理者ガイド アウトバウンドキャンペーンのベストプラクティス 顧客セグメントの構築方法 Amazon Connect Customer のアウトバウンドキャンペーンはどのくらいの頻度で新規顧客を追加できますか？セグメント更新間隔が1時間ごとに短縮可能になりました – 2026/04/20 Amazon Connect Customer のアウトバウンドキャンペーンでは、キャンペーンセグメントを 1 時間ごとに更新できるようになり、以前の最小 24 時間の間隔から短縮されました。これにより、次回の実施を待たずに 1 日を通して新規対象となるお客様にキャンペーンでアプローチできます。セグメントを 1 時間ごとに更新することで、あらゆるキャンペーンタイプで変化するビジネス状況に対応できます。回収チームは、報告を受けたその日の午後に、新たに滞納しているアカウントへの働きかけを開始できます。医療提供者は、新規予約から 1 時間以内に予約リマインダーコールを開始できます。SMS リマインダーに応答がなければ電話による音声通話でフォローする、といったマルチステップのジャーニーにおいても、1日1回のバッチ処理を待たずに、新たに対象となった顧客を随時キャンペーンに追加できます。 使用を開始するには、Amazon Connect Customer のコンソールまたは API を使用してキャンペーン設定時のステップ4 キャンペーンスケジュールにて、「 キャンペーン を更新 – オプション 」を有効にします。 管理者ガイド アウトバウンドキャンペーンのスケジュール設定 エージェンティック音声の音声合成エクスペリエンスを 3 つの新しい AWS リージョンと 10 のロケールに拡張 – 2026/04/20 Amazon Connect Customer では、エージェンティック音声の音声合成エクスペリエンスがアジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、欧州 (フランクフルト) の 3 つの AWS リージョンに拡張され、オーストラリア英語、イギリス英語、シンガポール英語、スペイン語、フランス語、ドイツ語、イタリア語、韓国語などの新しいロケールが追加されました。今回のアップデートにより、より多くのリージョンや言語において、より幅広い顧客に自然で人間のような音声 AI エクスペリエンスを提供できるようになります。 管理者ガイド Amazon Connect のサポートリージョン Amazon Connect のサポート言語 Amazon Connect が AI を活用したセルフサービスにタッチトーンバッファリングを追加 – 2026/04/20 Amazon Connect Customer では、通話がつながった瞬間から自動的に顧客のコンテキストを渡して、セルフサービスエクスペリエンスをパーソナライズできるようになりました。お客様がウェブサイト、モバイルアプリ、通知リンクから通話を開始すると、顧客 ID、セッション参照、キャンペーンコードなどのコンテキストを通話に自動的に渡すことができます。AI エージェントはこのコンテキストを使用して発信者を認識し、通話の理由を理解し、アクションを実行し、問題を解決します。発信者には身元確認や通話理由の再確認は不要です。 管理者ガイド タッチトーンバッファリングの設定 Amazon Connect Customer のフローモジュールはすべてのフロータイプで使えますか？全フロータイプ対応に加え、モジュールのネストも可能になりました – 2026/04/17 Amazon Connect Customer では、すべてのフロータイプでフローモジュールを使用できるようになりました。これにより、インバウンドのカスタマーエクスペリエンス以外にも、共通のロジックや機能を再利用できます。フローモジュールは、繰り返し使用可能なロジックを整理し、フローを使用して構築するカスタマーエクスペリエンス全体で共通の再利用可能な機能を作成します。例えば、エージェントウィスパーフローでモジュールを使用して顧客の最近の取引情報を共有し、エージェントに関連情報を提供して準備を整えさせるなど、以前はインバウンドフローの一部としてしか利用できなかった機能を活用できるようになりました。さらに、フローモジュールを他のモジュール内で使用できるようになったため、あらかじめ構築された中間ステップを 1 つのモジュールにまとめることで、複雑なロジックを構築できます。例えば、クレジットカード適格性モジュールは、最終決定を下す前に、クレジットスコアの確認、収入の検証、支払い履歴の確認を行う他のモジュールを呼び出すことができます。このモジュール式アプローチにより、ビジネス要件の変化に応じて組み合わせたり拡張したりできる再利用可能なコンポーネントを構築できます。 管理者ガイド 再利用可能な機能のためのフローモジュール 3. AWS Contact Center Blog のご紹介 Amazon Connect Customer: 会話型 AI を数か月ではなく数週間で展開 (日本語翻訳) NLX（nlx.ai）が Amazon Connect に加わり、ノーコードで高度な会話型 AI エクスペリエンスを構築・展開できるようになりました。ビジネスチームがエンジニアリングリソースを待たずに、インテリジェントなセルフサービス体験を設計・ローンチできます。United Airlines は従来12ヶ月かかるところを3ヶ月で本番稼働、あるグローバル小売企業は6ヶ月を6週間に短縮した実績があります。エンタープライズが求めるコントロールとスケーラビリティを維持しながら、デプロイまでの時間を大幅に短縮するアプローチです。 Amazon Connect Customer による音声・ビデオ・チャットを統合したコミュニケーションの構築 (日本語翻訳) 音声・ビデオ通話とチャットを同一エージェントとの1つのやり取りに統合するソリューションの構築方法を紹介しています。StartWebRTCContact API で音声・ビデオ通話を開始し、DescribeContact API で通話中のエージェント ID を取得、そのエージェント ID をチャットウィジェットのルーティングに渡すことで、チャネルをまたいでも同じエージェントが対応し続ける仕組みです。例えば、ローン申請の電話中にエージェントが書類を送信し、顧客がその場で署名して返送するといった体験が、数日ではなく数分で完了します。AWS CDK でデプロイ可能なサンプルコードが GitHub で公開されています。 Configure Schedule Adherence Thresholds in Amazon Connect to Account for Operational Variances スケジュール遵守率の測定で、日常的な業務のずれをノイズとして除外するには？ Amazon Connect のスケジュール遵守率に設定可能なしきい値（1〜10分）が追加され、通話対応中に休憩開始が数分遅れるといった運用上の許容範囲を定義できるようになりました。シフトレベルとアクティビティレベルの4段階で設定でき、しきい値内のずれは「遵守」として扱われます。あるシナリオでは、しきい値適用により非遵守時間が45分から15分へ67%削減。リアルタイムダッシュボードでは緑（遵守）・黄（しきい値内）・赤（非遵守）の3段階表示で、スーパーバイザーが本当に注意すべき逸脱を即座に判別できます。 4. AWS Black Belt オンラインセミナー (Amazon Connect Customer 関連) Amazon Connect Customer Profiles による C360 の実現とマーケティング活動での活用 Amazon Connect Customer Profiles による顧客 360 度ビュー（C360）の実現とマーケティング活動での活用方法を解説します。サイロ化された顧客情報を統合し、パーソナライズされた顧客体験を実現する方法をデモを交えてご紹介します。IT マーケティングを検討、実装する方、カスタマーセンターのシステムを検討、実装する方、Amazon Connect Customer を利用しているが、Customer Profiles はまだ利用していない方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） Amazon Connect Cases コンタクトセンターにおけるケース管理の課題と、Amazon Connect Cases がこれらの課題をどのように解決できるかについて解説しています。Amazon Connect Casesを活用することで、効率的なケース管理と顧客体験の向上を実現できるメリットについて理解を深めることができます。カスタマーセンターのシステムを検討、実装する方、Amazon Connect Customer を利用しているが、Cases はまだ利用していない方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） Amazon Connect AI agentsConnect assistant 基礎編 Amazon Connect Customer の AIエージェントについて、基本的な機能について説明し、人間のエージェントによる顧客サービスの向上支援についてユースケースを交えて解説します。また、GUIを介した各種リソースの設定方法についても解説します。Amazon Connect Customer ご利用中のお客様、パートナーの方、コンタクトセンター での AI 活用や業務効率化に関心のある方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） Amazon Connect AI agents self-service 基礎編 Amazon Connect Customer のAIエージェントの概要、特にセルフサービス機能に焦点を当て、顧客セルフサービスにAIを活用するメリット、セットアップ手順、導入後の効果測定について解説しています。コンタクトセンター業務の改善について理解を深めることができます。Amazon Connect Customer ご利用中のお客様、パートナーの方、コンタクトセンター での AI 活用や業務効率化に関心のある方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） 5. 今月のアップデートに関するよくある質問 Q. Amazon Connect とは何ですか？ 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 の最新アップデートはどこで確認できますか？ アップデートは AWS の最新情報（ What’s New ）ページで随時公開されます。 Q. Amazon Connect Customer の AI エージェントのパフォーマンスはどのように測定できますか？ 今月新たに追加された8つのメトリクス（目標達成率、忠実性スコア、ツール選択精度など）を使用して、AI エージェントの品質を多角的に測定できます。AI エージェントパフォーマンスダッシュボードでリアルタイムに確認できるほか、GetMetricDataV2 API や分析データレイクを活用して独自のレポートを作成することも可能です。（ AI エージェントパフォーマンスダッシュボード ） Q. Amazon Connect Customer のフローモジュールとは何ですか？ フローモジュールは、コンタクトフロー内で繰り返し使用するロジックを再利用可能なコンポーネントとしてまとめる機能です。今月のアップデートにより、インバウンドフローだけでなくすべてのフロータイプ（エージェントウィスパー、キュー転送など）で使用可能になり、さらにモジュール内から別のモジュールを呼び出す「ネスト」にも対応しました。（ フローモジュール ） Q. Amazon Connect Customer のスケジュール遵守率しきい値とは何ですか？ スケジュール遵守率しきい値は、エージェントのスケジュールからのずれを「許容範囲」として定義する機能です。例えば、通話対応中に休憩開始が3分遅れた場合でも、しきい値内であれば「遵守」として扱われます。シフトレベルとアクティビティレベルの4段階で1〜10分の範囲で設定でき、リアルタイムダッシュボードでは緑（遵守）・黄（しきい値内）・赤（非遵守）の3段階で表示されます。（ スケジュール遵守率 ） Q. Amazon Connect Customer のアウトバウンドキャンペーンとは何ですか？ アウトバウンドキャンペーンは、Amazon Connect Customer Profiles のセグメントに基づいて、音声・SMS・メールなど複数チャネルで顧客に自動的にアプローチする機能です。ジャーニー（複数ステップのワークフロー）を設計し、顧客の行動や属性に応じたパーソナライズされたアウトリーチを実行できます。今月のアップデートでは、最大10個のプロファイル属性に基づく優先順位付きダイヤルと、セグメント更新間隔の24時間から1時間への短縮が追加され、よりタイムリーで効果的なキャンペーン運用が可能になりました。（ アウトバウンドキャンペーン ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。Amazon Connect の最新情報は毎月このブログでお届けしていますので、来月号もお楽しみに。 著者プロフィール &nbsp; 梅田　裕義（Hiroyoshi Umeda） アマゾンウェブサービスジャパン合同会社 シニア Amazon Connect ソリューションアーキテクト 2020年12月入社。コンタクトセンター領域を専門に、Amazon Connect Customer を活用した顧客体験の向上や業務効率化の技術支援を行っています。AI によるセルフサービスの導入、オムニチャネル対応、分析基盤の構築などコンタクトセンターが抱える課題解決に幅広く取り組んでいます。

本ブログは 2026 年 5 月 19 日に公開された AWS Blog、” CIRT insights: How to help prevent unauthorized account removals from AWS Organizations ” を翻訳したものです。 AWS Customer Incident Response Team (CIRT) は、お客様がアクティブなセキュリティインシデントから復旧するためのご支援を行っています。この活動の中で、特定の お客様の構成や設計 を悪用する、新しいまたは流行している攻撃手口を発見することがしばしばあります。 これらの手口を理解することは、アーキテクチャ上の意思決定への反映、対応計画の改善、そして実際にこのような状況が発生した場合の検出に役立ちます。 本投稿では、攻撃者がお客様アカウントの制御を奪取した後に取る新しいアプローチを取り上げます。具体的には、お客様の AWS Organizations 実装から該当アカウントを離脱させ、その構造が提供するポリシーや保護を回避する手口です。 本記事で説明する手口は、AWS サービスの脆弱性を利用するものではありません。代わりに、特定の構成や設計によって生じた予期しない機会を悪用し、AWS アカウント内のリソースを不正に使用するものです。 何が起きているのか このアプローチは、攻撃者が organizations:LeaveOrganization 権限の付与を持つクレデンシャルを使用するところから始まります。この権限は LeaveOrganization API コール へのアクセスを提供し、メンバーアカウントから呼び出されると、そのアカウントを Organization から離脱させようとします。 重要な点として、このアプローチでは侵害されたルートクレデンシャルが使われる場合もありますが、攻撃者は他の手段でアクセス権を昇格させ、必要な権限を取得したり、その権限を持つロールを引き受ける能力を獲得したり、現在のクレデンシャルにこの権限を付与する能力を獲得したりすることもできます。これが、認可に対して 最小権限のアプローチ を取ることが、お客様の環境を保護する上で極めて重要である理由です。詳細については、 AWS Identity and Access Management (IAM) ドキュメント と、 組織単位 (OU) 設計および サービスコントロールポリシー (SCP) 実装に関する AWS Organizations のガイダンスをご覧ください。 お客様の環境への影響 アカウントが Organization から離脱させられると、その Organization の一部として継承されていた制限 (破壊的なアクションを防止していた SCP、利用可能な AWS リージョンを制限していたもの、特定の API コールをブロックしていたもの等) が適用されなくなります。また、当該アカウントは一括請求 (Consolidated Billing) の対象外となるため、Organization の請求アラートやコスト異常検知も該当アカウントの活動をカバーしなくなります。 AWS CloudTrail の組織トレイルは離脱したアカウントからのイベント取得を停止し、委任管理者を介して管理されていた Amazon GuardDuty の検出結果も中央のセキュリティアカウントへ流れなくなります。 その結果しばしば発生するのは、Organization が当該アカウントへの可視性を失う一方で、そのアカウント内には引き続き Organization のリソースが残るという状況です。関連する Threat Technique Catalog のエントリを以下に示します。 T1078.A002: Account Root User : 侵害されたルートクレデンシャルを利用した初期アクセス T1078.004: Cloud Accounts : 侵害された IAM クレデンシャルを利用した初期アクセス T1098: Account Manipulation : 制御を維持するための権限昇格とアカウント設定の変更 T1666.A002: Leave AWS Organization : SCP やガバナンスコントロールを回避するため、メンバーアカウントを Organization から離脱させる T1562.008: Disable Cloud Logs : Organization からの離脱後、中央集約型ロギングの可視性が失われる この手口の検知 アカウントが Organization からの離脱を試みると、CloudTrail には少なくとも 2 つの API コールが記録されます。 organizations:AcceptHandshake と organizations:LeaveOrganization です。中央集約型のロギングを構成している場合、これらのイベントが侵害アカウントから観測される最後のイベントとなる可能性があります。Organization からの離脱後、デフォルトではアカウント内のイベントは自身の CloudTrail ログに記録されることになります。アカウントが Organization に参加または離脱する際に関連する CloudTrail イベントを以下に示します。これらのイベントは、AWS Organizations を管理するためにチームが利用する承認済みの運用ワークフローの一部でない限り、調査が必要です。 CloudTrail イベント 意味 LeaveOrganization メンバーアカウントが Organization から離脱しようとしている AcceptHandshake アカウントが別の Organization への参加招待を承諾している InviteAccountToOrganization Organization がアカウントを招待している RemoveAccountFromOrganization 管理アカウントがメンバーアカウントを削除している (メンバー自らが離脱する場合とは異なる) この手口を防ぐための推奨ステップ organizations:LeaveOrganization アクションを拒否する SCP を実装してください。AWS Organizations は この制御の実装に関する詳細なガイダンス を提供しており、具体的な SCP ポリシー JSON や、本番環境および開発環境のアカウントには保護を維持しつつ正当なアカウント移行を許容できる OU 構造の設計に関するアドバイスが含まれています。 SCP は、メンバーアカウント内で IAM ポリシーが許可できる範囲を制限するガードレールとして機能します。AWS Organizations をご利用のすべてのお客様には、この SCP が現在配置されているかを確認し、配置されていない場合には実装に向けた手順を踏むことを強く推奨いたします。この SCP は迅速にデプロイでき、運用上の影響も最小限です。メンバーアカウントを Organization から分離することを慎重に管理・検討するためのプロセスを提供します。 このアクションは、ルートだけでなく organizations:LeaveOrganization 権限を持つあらゆる侵害された IAM プリンシパルから発生し得るため、IAM 権限の最小権限原則は重要な補完的な制御となります。ユーザーやロールがポリシーの追加・削除・変更を行ったり、別のロールを引き受けたり、自身の権限を変更したりできる範囲を制限することで、不正な権限変更が行われる経路を減らすことができます。IAM ポリシーを定期的にレビューし、過度に広範な権限 (特に iam:AttachRolePolicy 、 iam:AttachUserPolicy 、 iam:PutRolePolicy 、および広範な信頼ポリシーを伴う sts:AssumeRole ) を確認することは、侵害されたプリンシパルが実行できる範囲を制限するのに役立ちます。 ルートアカウントのセキュリティは引き続き重要です。ルートの侵害がこのパターンの一般的な侵入経路となるためです。すべてのルートユーザーに対して多要素認証 (MFA) を有効化し、ルートアクセスキーを削除し、メンバーアカウントからルートクレデンシャルを完全に取り除く ルートアクセスの一元管理 を採用することで、リスクの軽減につながります。 今後について 本手口は、私たちが様々なエンゲージメントを通じて目にしている、より広範なテーマを浮き彫りにしています。攻撃者は AWS のガバナンスコントロールがどのように機能するかをますます認識しており、Organization が提供する制御からアカウントを切り離すための意図的な手段を取っています。AWS CloudTrail を無効化する、Amazon GuardDuty ディテクターを削除する、Organization からアカウントを離脱させるといった行為は、いずれも同じ戦略の派生形にあたります。すなわち、本来であれば攻撃者の活動を制約し、お客様による対応を支援するはずのガードレールと可視性から、お客様のアカウントを切り離すというものです。 これを防ぐための制御は本日時点で利用可能であり、実装も簡単です。 AWS Organizations サービスチームのガイダンス から始め、 DenyLeaveOrganizationSCP を実装することをお勧めします。本手口に対して、最も効果が大きく、かつ最も労力の少ない制御です。それ以外にも、OU 構造全体での SCP のカバレッジを見直すこと、すべてのメンバーアカウントでルートクレデンシャルと IAM 権限が適切に保護されていることを確認すること、検知・対応プロセスが本手口を考慮に入れていることを確かめることが、より強固なセキュリティ態勢に貢献します。 Threat Technique Catalog for AWS には、根底にある手口の検知ガイダンスが含まれています。 関連リソース Threat Technique Catalog for AWS – Matrix T1078.A002: Account Root User T1078.004: Cloud Accounts T1098: Account Manipulation T1666.A002: Leave AWS Organization AWS Organizations における不正なアカウント離脱を防止するための重要なセキュリティコントロール メンバーアカウントのルートアクセスを一元管理する AWS Organizations サービスコントロールポリシー Amazon GuardDuty AWS CloudTrail ユーザーガイド 本投稿に関するフィードバックがありましたら、下のコメントセクションにご投稿ください。 著者について Shannon Brazil Shannon は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアであり、デジタルフォレンジックとクラウドセキュリティ調査を専門としています。コミュニティでは 4n6lady として知られ、セキュリティ教育と次世代の防御者の育成に情熱を注いでいます。 Derek Ramirez Derek は AWS Customer Incident Response Team (CIRT) のセキュリティエンジニアです。サイバーセキュリティと、困難なインシデントレスポンスの課題への対処を支援する AI ツールの構築という、自身が情熱を注ぐ 2 つのことを組み合わせて取り組んでいます。オースティンのダウンタウンを走ったり、ゴルフのショートゲームに取り組んだり、Dallas Cowboys を熱心に応援したりしています。 Richard Billington Richard は AWS Customer Incident Response Team (アクティブなセキュリティイベント中に AWS のお客様をサポートするチーム) のアジア太平洋地域における Sr. Security Engineer です。 翻訳は Security Solutions Architect の 松崎 博昭 が担当しました。

本ブログは 2026 年 4 月 7 日に公開された Amazon Science Blog “ Verifying and optimizing post-quantum cryptography at Amazon ” を翻訳したものです。 自動推論によって、セキュリティ、性能、保守性の要求をどのように両立させるか。 現在、安全なオンライン通信は 公開鍵暗号 によって実現されています。主に RSA と楕円曲線暗号 (ECC) が使われており、その安全性はある計算問題が困難であるという仮定に依存しています。しかし、これらの問題は 従来の コンピュータでは困難と考えられているものの、十分に大規模な量子コンピュータでは扱える可能性があります。「Store now, decrypt later」(今保存して後で復号) 攻撃は、暗号化された情報を傍受しておき、量子コンピュータで復号できるようになるまで保持する攻撃です。こうした攻撃が技術的に実現可能になるよりはるか前から、対策が必要となります。 ポスト量子暗号 (PQC) は、従来のコンピュータ上で動作しながら量子コンピューティングに対しても安全な暗号です。2024 年、米国国立標準技術研究所 (NIST) は 8 年にわたる標準化作業を経て、標準規格 FIPS-203 を公開しました。FIPS-203 では、量子コンピュータからの攻撃に対して安全と考えられている鍵共有メカニズムとして、Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) が規定されています。 本記事では、Amazon Automated Reasoning Group、AWS Cryptography、そしてオープンソースコミュニティが協力して、ML-KEM のオープンソースかつ形式的に検証された最適化実装をどのように作り上げ、お客様を「Store now, decrypt later」攻撃から最高の保証と最小のコストで保護しているかをご紹介します。 優れた暗号エンジニアリングとは何か? Amazon の Customer Obsession に従い、AWS は暗号ソリューションに取り組む際、次の 3 つの目標を優先します。 お客様のデータのセキュリティ : 暗号は安全に実装することが極めて難しく、わずかな欠陥でもお客様のプライバシーを危険にさらす可能性があるため、万全を期す必要があります お客様の体験 : 暗号には計算コストが伴います。AWS はこれを最小化し、お客様に最小のコストと最良の体験を提供します ソリューションを将来にわたって保守する能力 : 保守に費やす時間が少ないほど、お客様のためにより多くのイノベーションを生み出せます しかし、これらの目標の間にはトレードオフがあります。シンプルなコードは保守も安全な記述も最も簡単ですが、動作が遅くなりがちです。一方、高速なコードは監査が難しく、エラーが起きやすい傾向があります。 自動推論 によって、AWS はこのトレードオフを解消し、安全で、高速で、保守しやすい暗号ソリューションを同時にお客様に提供できます。 なぜ新たな ML-KEM 実装が必要なのか ML-KEM (旧称 Kyber) は実装の観点から十分に研究されています。一方では、 Kyber リファレンスコード が、長年精査されてきたクリーンな C 言語実装を提供しています。他方では、ML-KEM をさまざまな指標やプラットフォーム向けに最適化する方法を記述した数多くの研究論文があります。 2024 年に AWS Cryptography と Amazon Automated Reasoning Group が直面した課題は、リファレンス実装のシンプルさと、研究で明らかになった最適化の可能性を、本番環境で使える単一の実装に組み合わせることでした。 2024 年、AWS Cryptography と Amazon Automated Reasoning Group は、徹底的に精査された ML-KEM リファレンス実装のシンプルさと、研究で明らかになった最適化の可能性を、本番環境で使える単一の実装 mlkem-native にまとめるという課題に取り組みました。 同じ頃、AWS は Linux Foundation の Post-Quantum Cryptography Alliance (PQCA) の創設メンバーとなりました。PQCA は、「標準化過程にあるポスト量子暗号アルゴリズムの高保証ソフトウェア実装の構築を目指すオープンソースプロジェクトの集合」である Post-Quantum Cryptography Package (PQCP) を立ち上げました。 そこで AWS は独自にコードを開発するのではなく、チームメンバーが PQCP に参加し、まもなく mlkem-native を立ち上げました。これは、ML-KEM リファレンス実装と、最適化および形式的検証に関する研究を組み合わせることを目的とした、ML-KEM の高保証・高性能 C 言語実装です。 速く、そして慎重なコーディング mlkem-native のモジュラー設計は、ML-KEM の高レベルロジックをカバーする フロントエンド と、性能が重要なすべてのサブルーチンを担当する バックエンド を組み合わせています。各サブルーチン (SHA3 の基礎となる Keccak 置換や、高速な多項式演算の基礎となる数論変換 (NTT) を含む) には、特定のハードウェア向けにネイティブに記述された、高効率な複数の実装が用意されています。デフォルトの C 言語実装に加えて、mlkem-native は AArch64、x86_64、RISC-V64 向けのアセンブリ/組み込み関数バックエンドを提供しています。 mlkem-native のモジュラー設計は、ML-KEM の高レベルロジックをカバーするフロントエンドと、性能が重要なサブルーチンの複数のハードウェア固有実装からなるバックエンドを組み合わせています。 保守性のために重要なのは、フロントエンドとバックエンドの間のインターフェイスが固定されていることです。新しいターゲットアーキテクチャ向けの最適化を追加する開発者は、バックエンド仕様に従って選択したバックエンド機能を実装し、フロントエンドはそのまま維持します。バックエンド仕様の策定は、見かけほど単純ではないことが分かりました。これについては以下で説明します。 限界を知る メモリ安全性 C プログラミング言語のよく知られた課題は、バッファオーバーフローのリスクです。メモリ領域の指定された境界を超えて書き込むと、データ構造が破壊され、悪意を持って悪用されると非特権コードの実行につながる可能性があります。こうした問題の総称が メモリ安全性 です。Rust のようなメモリ安全な言語は、範囲外アクセスの影響を制限できます (たとえば、未定義動作を示す代わりにパニックする)。しかし、間違いそのものを防ぐわけではありません。 型安全性 もう一つのよく知られた課題は ML-KEM の実装に関するもので、整数オーバーフローのリスク、つまり 型安全性 の側面です。RSA や ECC と同様に、ML-KEM はモジュラー演算に依存しています。モジュラー演算では、演算の結果を特定の数 (ML-KEM の場合は素数 3,329 で、 MLKEM_Q または単に q と表記) で割り、その剰余だけが次に持ち越されます。剰余演算子はパーセント記号 % で表されます。 論理的には、ML-KEM で 2 つの数 x と y を加算または乗算する必要がある場合、( x + y ) % q および ( x * y ) % q を計算する必要があります。たとえば、(294 * 38) % q = 11,172 % q = 1,185 となります。このような「即時」のモジュラー q 演算は、データを「正規」範囲 {0, 1, 2, … , q -1} で表すために常にモジュラー還元を適用するもので、極めて遅くなります。 効率的な ML-KEM 実装では、代わりに「遅延」モジュラー q 演算を使用します。データはできるだけ長くモジュラー還元なしで操作され、最悪の場合のオーバーフローのリスクが生じたときにのみ還元が行われます。さらに、これにより Montgomery 還元のような不完全な還元アルゴリズムが使えるようになります。これは高速ですが、必ずしも完全に還元された出力を返すわけではありません。 ML-KEM の場合、モジュラー q = 3,329 のデータは通常、符号付き 16 ビット整数に格納されます。ML-KEM の数多くの算術ルーチン全体で遅延演算を扱う際には、データの最悪値の境界を追跡し、それらの境界が 16 ビット整数の限界を超える可能性のある箇所にモジュラー還元を挿入することが不可欠です。この領域での小さな間違いは、テストで見逃されることがあります。なぜなら、平均的な境界は最悪値の境界よりはるかに小さい傾向があるためです。そして、本番環境でランダムに表面化することがあります。 バッファ境界、特に算術境界の追跡は、時間がかかり、エラーが起きやすい作業です。たとえば、低レベルの算術関数の出力境界を弱めると、まったく別の関数で稀に算術オーバーフローが発生することがあります。これを手作業で確認するには、緻密なドキュメント作成と熟練した監査担当者が必要なだけでなく、開発が遅くなります。 mlkem-native では、C Bounded Model Checker (CBMC) というツールを使用して、C レベルでメモリ安全性と型安全性を自動的に検証しています。各関数について、機械可読かつ人間可読な契約をソースコードに追加してバッファと算術データの境界を指定し、CBMC にそれらの境界に対してバッファオーバーフローや算術オーバーフローが発生し得ないことを自動的に検証させます。 モジュラー還元の簡単な例を見てみましょう。 void mlk_poly_reduce_c(mlk_poly *r) __contract__( requires(memory_no_alias(r, sizeof(mlk_poly))) assigns(memory_slice(r, sizeof(mlk_poly))) ensures(array_bound(r-&gt;coeffs, 0, MLKEM_N, 0, MLKEM_Q))) { unsigned i; for (i = 0; i &lt; MLKEM_N; i++) __loop__( invariant(i &lt;= MLKEM_N) invariant(array_bound(r-&gt;coeffs, 0, i, 0, MLKEM_Q))) { /* Barrett reduction, giving signed canonical representative */ int16_t t = mlk_barrett_reduce(r-&gt;coeffs[i]); /* Conditional addition to get unsigned canonical representative */ r-&gt;coeffs[i] = mlk_scalar_signed_to_unsigned_q(t); } mlk_assert_bound(r, MLKEM_N, 0, MLKEM_Q); } 関連する部分を一つずつ見ていきましょう。まず、 __contract__( … ) に注目します。簡単に言うと、 memory_no_alias と memory_slice の行は、コードが読み書きできるメモリを指定しています。これはメモリ安全性に関連します。 ensures(array_bound(…)) 句は型安全性に関連しています。これは、関数が戻った時点でデータが区間 [0, 1, …, q ) 内にあることを 保証する ことを指定します。証明では、 __loop__(invariant(…)) があり、ループがこの境界を段階的にどう確立するかを指定しています。 i 番目のイテレーションでは、 i 番目の係数まで成立します。最後に、実装は実質的に mlk_barrett_reduce と mlk_scalar_signed_to_unsigned_q を組み合わせています。CBMC はこれらの内部を見ず、それらの契約に置き換えます。 int16_t mlk_barrett_reduce(int16_t a) __contract__( ensures(return_value &gt; -MLKEM_Q_HALF &amp;&amp; return_value &lt; MLKEM_Q_HALF) { ... } int16_t mlk_scalar_signed_to_unsigned_q(int16_t c) __contract__( requires(c &gt; -MLKEM_Q &amp;&amp; c &lt; MLKEM_Q) ensures(return_value &gt;= 0 &amp;&amp; return_value &lt; MLKEM_Q) ensures(return_value == (int32_t)c + (((int32_t)c &lt; 0) * MLKEM_Q)) { ... } mlk_barrett_reduce がまず対称的な出力区間 ( -q /2, …, q /2) を確立し、次に mlk_scalar_signed_to_unsigned_q がそれを [0,1, …, q ) にマッピングしているのが分かります。この例では、仕様が望ましい形で整合していることを目視で簡単に確認できますが、より複雑な例ではそれほど明確ではありません。いずれにせよ、CBMC が自動的にチェックしてくれます。 速く動かしながら安全を保つ 上述の CBMC 証明は、mlkem-native の C コードに対するメモリ安全性と型安全性を確立します。しかし、mlkem-native の最も性能が重要な部分 (Keccak 置換と数論変換) は、AArch64 と x86_64 向けに手作業で最適化されたアセンブリで実装されています。 mlkem-native のアセンブリ実装に対して、高い性能を維持しつつ保証を得るために、AWS は次の 3 つのコンポーネントを使用しています。アセンブリのスーパーオプティマイザーである SLOTHY、対話型定理証明器である HOL Light、そして HOL Light 上に構築されたアセンブリ用検証基盤である s2n-bignum です。これらを組み合わせることで、開発者がクリーンで保守しやすいアセンブリを記述しつつ、デプロイされるコードが正当性の形式的保証を伴ってピーク性能を達成するワークフローが可能になります。 高性能なアセンブリを手で書くと、根本的なトレードオフが生じます。計算を明確に表現するクリーンで監査可能なコードは遅く、高速なコードは密で、マイクロアーキテクチャ固有で、保守が困難です。SLOTHY はマイクロアーキテクチャ固有の最適化を自動化することで、このトレードオフを解消します。アセンブリプログラムを制約充足問題に変換し、制約ソルバーを使用して最適な命令スケジュールとレジスタ割り当てを見つけ、最適化されたアセンブリを出力します。開発者は計算のロジックを重視したクリーンなコードを書き、SLOTHY が高速なコードを生成します。 AWS は、すべての AArch64 および x86_64 アセンブリルーチンの機能的正当性を、HOL Light と s2n-bignum を使用して証明します。SLOTHY が使用される場所では、特定の命令順序やレジスタ割り当てに依存しないように証明が記述されます。したがって、証明を調整することなく、特定のマイクロアーキテクチャ向けにコードを再最適化できます。この「事後」検証アプローチは、アセンブリで表現された計算の数学的な正しさを、それがどのように生成されたかにかかわらず確立します。特に、SLOTHY は信頼できるコンピューティングベース (TCB) から除外されます。 誠実さを保つ 形式的検証は決して絶対的なものではありません。すべての証明は、形式的なオブジェクト (仕様とモデル) を非形式的な現実世界の要件とシステムに結び付けるものであり、これらの結び付きにはギャップが生じます。形式的仕様は実際に必要なものを捉えているか? 形式的モデルは実際のシステムを忠実に反映しているか? 証明基盤自体は健全か? お客様の信頼を獲得し維持するには、これらの限界について透明性を保つ必要があります。そこで AWS は、 SOUNDNESS.md と題したドキュメントを作成・公開しました。ここでは、mlkem-native で何が証明され、何が仮定され、残存リスクがどこにあるかを、HOL Light 証明で使用されるハードウェアモデルの忠実性、CBMC のより大きな TCB、2 つの検証スタック間の手動の橋渡しに至るまでマッピングしています。各ギャップについて、実施されている緩和策を説明し、今後の作業の概要を示しています。 AWS の目標は完璧を主張することではなく、透明性を通じて信頼を獲得することです。コミュニティの皆様には SOUNDNESS.md を批判的に読み、AWS の前提に異議を唱え、残存するギャップを埋めることにご協力いただければ幸いです。 本番環境への展開 mlkem-native は、AWS サービス全体の安全な通信を支える Amazon のオープンソース暗号ライブラリ AWS-LC に統合されています。この統合では、自動インポーターを使用して mlkem-native のソースコードをアップストリームリポジトリから直接取り込み、AWS-LC が最新の検証済み実装と同期し続けることを保証します。 この統合は手間を最小限に抑えるよう設計されています。mlkem-native のモジュラーアーキテクチャにより、AWS-LC はコアの ML-KEM ロジックをインポートしながら、プラットフォーム固有のコンポーネントには独自の実装を提供できます。たとえば、AWS-LC は mlkem-native の暗号プリミティブを既存の FIPS-202 (SHA-3) 実装にマッピングし、AWS-LC の乱数生成およびメモリゼロ化関数を使用し、必要な場合はペアワイズ一貫性テストなど FIPS モード機能を有効にします。これを可能にしているのは、検証済みコードを変更することなく mlkem-native の API を AWS-LC のインフラストラクチャに橋渡しする薄い互換性レイヤーです。 重要なのは、メモリ安全性と型安全性を証明する CBMC 契約が、インポートされたソースコード内に保持されていることです。プリプロセッサがコンパイルされたバイナリからこれらを削除しますが、ソース内には残り、コードの保証の機械チェック可能なドキュメントとして機能します。これは、実装と共に移動する一種の「生きた証明」です。 さらに、mlkem-native も AWS-LC もオープンソースで寛容なライセンスのため、その利点は AWS の枠を超えて広がります。誰でも mlkem-native を自社のシステムに統合し、同じ性能と保証の組み合わせを得ることができます。形式的検証成果物 (CBMC 契約と HOL Light 証明) はリポジトリの一部であり、関連するすべてのツールはオープンソースであり、セットアップと証明チェックのスクリプトが提供されているため、AWS のセキュリティ主張を独立に検証できます。 インパクト mlkem-native の開発は、自動推論を体系的に適用すれば、暗号エンジニアリングの 3 つの目標 (セキュリティ、性能、保守性) が衝突しないことを示しています。 CBMC は、複雑な算術全体で境界を手動で追跡する作業から AWS を解放し、テストでは見逃されて本番環境でランダムに表面化するエラーを捕捉しました。アノテーションはソースコード内に機械チェック可能なドキュメントとして残り、コードを同時により保守しやすく、より安全にします。HOL Light と s2n-bignum により、AWS は数学的な正当性の確実性を持って積極的なアセンブリ最適化をデプロイできました。SLOTHY により、特定のマイクロアーキテクチャ向けにピーク性能を達成しながら、クリーンで監査可能なコードを書くことができました。そして、証明は最適化に依存しないように記述されているため、検証をやり直すことなくコードのターゲットを変更できます。 その結果、従来の開発で達成できるものよりも、同時により安全で、より高速で、より保守しやすい実装が実現しました。AWS はお客様のセキュリティ、お客様の体験、そして革新する能力の間で妥協しませんでした。自動推論は 3 つすべてを実現したのです。 AWS-LC-FIPS リリース プラットフォーム 処理 3.1 4.0 改善倍率 c7i Keygen 30899 65146 2.1 Encaps 30623 61233 2.0 Decaps 25141 51545 2.0 c7g Keygen 29617 71134 2.4 Encaps 28482 66874 2.3 Decaps 23919 64765 2.3 Amazon の暗号ライブラリ AWS-LC で ML-KEM リファレンス実装から mlkem-native に切り替えた際の性能影響。ML-KEM-768 の性能は c7i および c7g EC2 インスタンスで測定されています。数値は 1 秒あたりの処理数を表します (高いほど良い)。ベースラインは ML-KEM の C リファレンス実装を含む AWS-LC-FIPS 3.1 リリースです。AWS-LC-FIPS 4 リリースは mlkem-native でビルドされています。プラットフォームは Intel(R) Xeon(R) Platinum 8488C を搭載した c7i と、Graviton 3 プロセッサを搭載した c7g です。 謝辞 同僚の John Harrison 氏 (Automated Reasoning Group の senior principal applied scientist) には、HOL Light での AArch64 アセンブリ証明の大部分を提供し、また HOL Light 対話型定理証明器および s2n-bignum 検証基盤の保守を担当いただいたことに感謝します。mlkem-native は AWS だけでなく、オープンソースコミュニティの多くのメンバーが関わる共同作業です。とりわけ、共同保守者である zeroRISC の Matthias Kannwischer 氏に感謝します。彼は AWS と共に mlkem-native を立ち上げ、以来プロジェクトの成功に重要な役割を果たしてきました。 著者について Hanno Becker Hanno Becker は Amazon の Automated Reasoning Group の principal applied scientist です。元 Mbed TLS の開発者で、Arm 上の高性能 (ポスト量子) 暗号に情熱を注いでいます。SLOTHY スーパーオプティマイザーの作者でもあります。 Rod Chapman Rod Chapman は Amazon Web Services (AWS) の senior principal scientist です。 Dusan Kostic Dusan Kostic は Amazon Web Services (AWS) の senior applied scientist です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは。ソリューションアーキテクトの東 健一です。普段はパブリックセクター技術統括本部で中央省庁のお客様の技術支援を担当しており、主にガバメントクラウドや医療 DX に関わるご支援を担当しております。 2026年5月19日（火）に、AWS 目黒オフィスにて「ガバメントクラウドワークショップ 2026 春 ～ AI で実践する開発・モダナイズ・運用 ～」を開催しました。 本ワークショップは、ガバメントクラウドに携わる事業者様を対象に、移行を進める上で必要となる技術を深く学び (Dive Deep)、案件で直面するリアルな課題や他官公庁／自治体の取り組みを共有し、参加者同士の交流を楽しむ (Have Fun) ことを目的とした技術イベントです。 今回のワークショップでは、「 AI を使った開発・モダナイゼーション・運用 」をメインテーマに掲げ、事例セッション・デジタル庁様セッションに加え、参加者の皆様にあらかじめ関心のあるテーマを選択いただいたうえで、手を動かしながら学ぶ 4 つのテーマ別ワークショップを実施しました。当日は会場が満席となり、総勢150名以上の方々にご参加いただく盛況なイベントとなりました。さらに夜の部として、AWS ユーザーコミュニティ「JAWS-UG」の公共分野支部である Gov-JAWS との懇親会を併催し、日中のセッションを振り返りながら参加者同士の交流を深める時間としました。 なお、前回の開催内容について気になる方は下記のブログをご参照ください。 【開催報告】 第2回 自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 大阪 【開催報告】第三回 中央省庁向け AWS ガバメントクラウドワークショップ イベント概要 本ワークショップは以下のような形で実施しました。 日時 : 2026年5月19日（火）13:00 – 18:30（12:30 受付開始） 懇親会・Gov-JAWS: 18:30 – 21:00 場所 : アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス 参加対象 : ガバメントクラウドに携わる全ての方々 時間 セッション・ワークショップ名 13:00-14:00 中央省庁担当 事業者様登壇 14:00-14:30 自治体担当 事業者様登壇 14:30-15:30 デジタル庁様登壇 15:30-15:40 休憩 15:40-18:30 各テーマに分かれて Workshop 18:30-21:00 懇親会 / Gov-JAWS イベント構成 オープニングおよび事例セッション・デジタル庁セッションを全体で実施した後、参加者の皆様にあらかじめ選択いただいた以下 4 つのテーマに分かれて、各部屋でハンズオン形式のワークショップを実施しました。 AI エージェントを開発する（Strands Agents / AgentCore） AI を使ってシステムをモダナイズする（AWS Transform / Kiro） AI を使ってシステムを開発する（Kiro IDE 実践） AI を使ってシステムを運用する（生成 AI を用いた AWS 環境のトラブルシューティング効率化） 各セッションの概要と発表資料は以下をご覧ください。 事例セッション・デジタル庁セッション ハイライト Step Functions で実現するフルマネージド・ジョブ開発 — ガバメントクラウド開発における 設計／開発・運用時の「理想と現実」のギャップ 発表資料 ： Step Functions で実現する フルマネージド・ジョブ開発（杉元） NTT データ 杉元様より、ジョブ管理ツールを AWS Step Functions を中核に据えてフルマネージドなジョブ機能として作り変えた取り組みについて、設計・開発・運用のリアルな学びとともにご紹介いただきました。「依存関係の表現」「再実行 / リラン」「リトライや補償」「並列実行」「監視・通知」「権限分離」といった “ジョブ管理っぽさ” を、Step Functions のステートマシンとしてどのように実装で落とし込んだかを共有いただきました。 あわせて、移行時に直面した設計／開発時の理想と現実（苦悩）のギャップ、稼働後に見えてきた運用時の理想と現実のギャップを、失敗事例も含めて整理いただきました。ジョブ管理ツールの置き換えを検討している方や、ワークフローを “運用できるジョブ基盤” にしたい方にとって、現実的な設計判断と運用設計の勘所を持ち帰れるセッションとなりました。 Amazon Bedrock で生成 AI 活用サービスをセキュアに構築する方法 発表資料 ： Amazon Bedrock で生成AI活用サービスをセキュアに構築する方法 – Speaker Deck アクロクエストテクノロジー 鈴木様より、 国土交通省様向けにAI書類審査ソリューションを構築支援したご経験 などを踏まえ、AWS の生成 AI サービスである Amazon Bedrock を前提として、どのように基盤モデルのセキュリティ対応を実現するかのポイントをご紹介いただきました。 あわせて、RAG（Retrieval-Augmented Generation）や AI エージェントといった生成 AI 活用サービスを構築する上でのセキュリティ観点を、構成例を交えながら解説いただきました。日本の公共案件で生成 AI を活用する際に求められるセキュリティの考え方が整理されており、これから生成 AI 活用に取り組む事業者様が設計の指針として持ち帰れる実用的な発表内容でした。 自治体ガバメントクラウドにおける生成 AI 活用 NTT 西日本 三浦様より、自治体のお客様向けに生成 AI を導入された取り組みについてご紹介いただきました。AWS が公開している OSS の生成 AI 活用基盤 GenU の閉域オプションをベースに、 Amazon Bedrock AgentCore を活用した独自 AI エージェントの開発を行っているとのお話で、自治体特有のセキュリティ要件を満たしつつ生成 AI 活用を進めるための実践的な設計・構築のポイントを共有いただきました。OSS をベースとしたうえで自社のユースケースに合わせて AgentCore で拡張するアプローチは、これから自治体向けに生成 AI 導入を検討する事業者様にとっても参考になる内容となっておりました。 GCAS ヘルプデスクについて 概要説明および活用方法のご紹介 デジタル庁 加藤様、萬谷様より、ガバメントクラウドにおける GCAS ヘルプデスクの役割と活動についてご紹介いただきました。GCAS ヘルプデスクの概要から、より効果的にご活用いただくための考え方や問い合わせ方法、実際のお問い合わせ事例やフィードバック、CSP (Cloud Service Provider) との連携内容、今後の改善に向けた方針までお話しいただきました。 GCAS ヘルプデスクが単なる問い合わせ窓口にとどまらず、利用者の声をガバメントクラウドの改善につなげる場であるというメッセージは、参加事業者様にとって今後の活用イメージを大きく広げるものとなりました。 ガバメントクラウドにおける生成 AI 利用環境「源内」の構築と展開 デジタル庁 荻原様より、政府職員の業務品質の向上と効率化を実現するために、ガバメントクラウド上に構築・展開している生成 AI 利用環境「 源内 」についてご紹介いただきました。現在、デジタル庁の職員のみならず、全府省庁約 18 万人の政府職員が生成 AI を利用できるよう、大規模実証事業を推進されています。 本セッションでは、ガバメントクラウドにおける「源内」のシステム概要と、大規模展開にあたって考慮した AI 特有の観点についてご説明いただきました。あわせて、行政業務に特化したアプリケーションの取り組みや、オープンソースソフトウェア (OSS) として公開された内容についてもご紹介いただきました。 ガバメントクラウド上での生成 AI 利用の最前線の取り組みを、構築・運用の双方の観点から伺えるセッションとなり、参加事業者様にとっても今後の生成 AI 活用案件に向けた貴重なリファレンスとなりました。 テーマ別ワークショップ Strands Agents, AgentCore を使った AI エージェントのデプロイ（AI エージェントを開発する） ワークショップ資料 ： AI エージェントハンズオン 〜 作って、動かして、体験する 〜 AWS ソリューションアーキテクトの松本より、オープンソースの AI エージェント開発フレームワークである Strands Agents を使ったエージェント開発の体験から、 Model Context Protocol (MCP) を使った AI エージェントの動きの理解、そして AgentCore Runtime を使った AI エージェントのデプロイまでを、一連のハンズオンとして体験いただきました。 さらに後半では、AWS 公式 GitHub で公開しているサンプル実装である RAPID （生成 AI を活用した書類審査ソリューション）と Moca （マルチエージェントオーケストレーションのサンプル）を実際にお試しいただき、業務適用イメージを具体化していただきました。実装から本番デプロイ、さらにユースケース特化型のサンプル実装までをエンドツーエンドで体験できる内容となり、生成 AI を活用したサービス開発の第一歩として手応えを感じていただけたワークショップとなりました。 Kiro IDE 実践ワークショップ（AI を使ってシステムを開発する） ワークショップ資料 ： Kiro IDE 実践ワークショップ AWS ソリューションアーキテクトの葉山より、生成 AI の概要解説からスタートし、生成 AI を使った開発体験、Kiro を活用した開発業務の効率化までを体験いただきました。仕様駆動開発（Spec-Driven Development）の考え方に基づき、要件定義からコード生成までを Kiro でどのように実現するかをハンズオンで学んでいただきました。「すぐにでも自分の業務で試したい」という声を多くいただいたワークショップとなりました。 生成 AI を用いた AWS 環境のトラブルシューティング効率化（AI を使ってシステムを運用する） ワークショップ資料 ： 生成AIを用いたAWS環境のトラブルシューティング効率化ワークショップ ワークショップ補足資料 ： 生成 AI を用いた AWS 環境のトラブルシューティング – Speaker Deck AWS ソリューションアーキテクトの東より、AWS 上に構築したシステムにおいてトラブルシューティングを生成 AI を用いて効率化するための手法をご紹介し、ハンズオンとして体験いただきました。ガバメントクラウドで活用できる手法・サービスを紹介しつつ、一般の AWS 環境でも活用可能な手法も併せてお試しいただける内容となり、運用業務の効率化に向けた具体的な打ち手を持ち帰っていただけました。 AWS Transform, Kiro を使ったモダナイゼーション（AI を使ってシステムをモダナイズする） AWS ソリューションアーキテクトの今坂より、AI エージェントによるレガシーコードの分析・バージョンアップグレード計画の自動生成を体験いただいた後、AI エージェントを活用したバージョンアップグレードを実際に体験いただきました。「これまで人手で時間をかけていたモダナイゼーション作業が、AI エージェントの活用でここまで自動化できるのか」という驚きとともに、自社案件への適用イメージを持ち帰っていただけたワークショップとなりました。 ※ ワークショップ資料については「Kiro IDE 実践ワークショップ」と同じコンテンツをベースに実施しております。 Gov-JAWS ワークショップと併せて、 Gov-JAWS の活動も行われました。Gov-JAWS は、AWS のユーザーコミュニティ「 JAWS-UG 」の支部として、公共分野における AWS 利用に焦点を当てた新しいコミュニティです。政府や自治体が進める公共分野のクラウド利用に関連する知識やノウハウを共有するための場として設立されました。 イベント当日は夜の部として Gov-JAWS 第 5 回 Meet Up が開催され、懇親会と併せて多くの参加者が交流を深めました。このコミュニティを通じて、今後も公共分野でのクラウド活用に関する情報共有と横のつながりの拡大が期待されています。 詳細は Gov-JAWS 側のページをご覧ください。 まとめ 今回のガバメントクラウドワークショップ 2026 春では、「AI エージェント開発」「モダナイゼーション」「AI 駆動開発」「AI による運用効率化」という生成 AI を軸とした 4 つのテーマに加え、ジョブ基盤の実装事例、生成 AI のセキュアな構成、自治体システム標準化の取り組み、GCAS ヘルプデスクの活用といった、ガバメントクラウドに携わる事業者様にとって直近で必要となるテーマを幅広く取り扱いました。 ご参加いただいた皆様におかれましては、お忙しい中ご足労いただき誠にありがとうございました。また、ご登壇いただいた NTT データ様、アクロクエストテクノロジー様、NTT 西日本様、デジタル庁様にも、貴重な知見をご共有いただきましたことを心より御礼申し上げます。 AWS では、今後もガバメントクラウドに携わる事業者様向けのワークショップを継続して開催してまいります。次回開催のご案内をお待ちください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウド相談窓口を設けております。ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 東 健一 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、主にガバメントクラウドや医療 DX 、コンテナワークロードに関する案件の技術支援に取り組んでいる。

本ブログは、キヤノンIT ソリューションズ株式会社様と Amazon Web Services Japan が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクト木村、アカウントマネージャーの池田です。 本記事では、キヤノン IT ソリューションズ株式会社様が 、Amazon Q Developer を開発現場に導入し、3 か月間効果検証を実施した取り組みをご紹介します。コード生成やレビュー支援による効率化、現場での活用事例、そして検証から得られた知見について詳しく解説します。 なお、本ブログに登場する Amazon Q Developer は 2026 年 4 月 30 日に AI 駆動開発IDE「Kiro」へと進化的に統合されることが発表されています 。 本検証で培ったAI駆動開発のプラクティスやノウハウは、Kiro の仕様駆動開発（Spec-driven Development）へとそのまま活かせるものであり、キヤノン IT ソリューションズ様 の取り組みはまさにこの進化を先取りしたものと言えます。 背景/課題 キヤノンITソリューションズ株式会社様(以下、キヤノン ITS )では、生成 AI ツールの社内推進活動を積極的に実施しています。今後 SIer としての競争力を維持していくために、生成 AI の活用は不可欠です。しかし、個人レベルでの試行には限界があるため、企業として活用のための基盤整備や推進を進める必要がありました。 そこでキヤノン ITS 様は、2024年に「生成 AI ビジネス検討委員会」を立ち上げて、生成 AI ビジネスにおける 5 年後のありたい姿と戦略を策定し、その具体的な施策を推進するための「生成 AI ビジネス推進室」を発足。社内の利用ガイドラインの整備、生成 AI ツールの全社的な導入を推進してきました。 生成 AI ツールの導入後に現場への定着をいかに進めるかは、多くの企業にとって共通の課題です。キヤノン ITS 様は全社横断向けの複数回に渡るイベント形式で「AI 駆動開発の普及」を行うことで、より深い活用推進を実施しました。 なぜ Amazon Q Developer を選択したのか(導入当時) 全社利用が可能な生成 AI ツールは導入済みではありましたが、「AI 駆動開発の普及」という目的に対し、コスト・運用・性能のバランスに優れた選択肢であることから Amazon Q Developer を選択しました。 コスト: 月額ユーザー数の固定料金で予算計画が容易 同機能の固定費用で使えるサービスとしては最も安価 運用: 既存の AWS 環境（情報システム部門の管轄）でアカウント管理可能 AWS から導入・普及の支援を受けることができる 性能: Claude Sonnet 4（実施当時）による高精度の生成 MCP 対応による拡張性の高さ セキュリティ・脆弱性診断、モダナイゼーションなど SI に役立つ機能搭載 AI駆動開発の普及をする上での工夫ポイント 本施策が単なるツール導入だけで終わらぬよう、事前に懸念事項を洗い出し、キヤノン ITS 様と AWS にて、役割分担を行い施策設計をしました。 懸念事項 Amazon Q Developerのリリース・キックオフがなされただけで、ツールが使われない 事業部側での予算制限があり、積極利用がなされない ツールの認知はされているが、使い方が分からずに利用がされない AI駆動開発の取組自体が限られた少数のメンバーにしか知られない 対策 オペレーション整備 ツールを使ってもらえるような申請フローの整備（キヤノン ITS） 興味喚起 「このツールは面白い」と思ってもらえるイベント。継続するための仕掛けづくり（AWS） 障壁排除 ハンズオン/定期的なオフィスアワーを行うことで技術的な懸念点を払拭（キヤノンITS/AWS） イベント化 打ち上げ花火のようなオンラインイベントで終わらせず、興味喚起、ハンズオン研修、利用者のトラッキングを行いランキング発表等、全社向けの年末までのロードマップを敷いて継続施策として打ち出す（キヤノンITS/AWS） エグゼクティブスポンサー エグゼクティブスポンサーである、金澤社長からの支援と声かけを実施（キヤノンITS） ロードマップ全体像 AI駆動開発の社内展開に向けて、Amazon Q Developer の業務適用検証を実施しました。本取り組みは、9 月 5 日に開催した「AI Agent DAY」をキックオフとし、Amazon Q Developer を実際の業務に適用した際の有効性を約 3 か月間にわたり検証したものです。 キックオフイベントには約 250 名が参加し、100 名以上の技術者が Amazon Q Developer のハンズオンを体験しました。その後の業務適用検証フェーズでは、生成 AI ビジネス推進室がツール利用費を負担する形で施策を企画し、57 名が参加しています。検証期間中は、インフラおよびアプリケーションを対象としたハンズオンセッションやオフィスアワー、中間イベントを実施しました。あわせて、Teams 上の「生成 AI 交流広場」での情報共有やアンケートを通じた成果の可視化にも取り組んでいます。 最終的には、技術者向けイベント「CITS Day 2025」において、Amazon Q Developer を効果的に活用した取り組みを表彰しています。なお、表彰対象検討のための利用状況のデータ分析においても、Amazon Q Developer を活用しました。 Amazon Q Developer の利用状況を示すダッシュボード Amazon Q Developer へ利用率ランキングを集計するプロンプト CITS Day 2025 での表彰 活用事例 CITS Dayのイベント内では、複数の事例が共有されました。 事例1: 開発ツール×生成AI（佐野様の発表） 抱えていた課題 プログラミングの抽象化レイヤーの進化と開発ツールの変化への対応 開発業務の効率化と生産性向上 資料作成やアイデア整理などのコーディング以外の作業の効率化 導入した理由・きっかけ 新しい開発スタイルで「速さ」「安全性」「柔軟性」を実現するため Kiro との出会い（2024年夏）がきっかけ 生成 AI の柔軟性を活かしつつ、課題（コード品質のばらつき、非機能要件への対応不足など）を解決するため 導入して得られた結果 バイブコーディングモードを活用することで、マークダウン形式で効率的に資料作成が可能に レイアウト案をアスキーアートで事前確認するなど、視覚的な提示が可能に 仕様駆動開発モードではプロトタイプの迅速な作成が実現 バーコードスキャナーアプリの要件からタスク分解、実装まで効率的に進行 事例2: PoCでのAmazon Q Developer活用（可知様の発表） 抱えていた課題 SNS バズ検知を需給マネジメントに繋げるための PoC を短期間・低コストで実施 SNS API や可視化技術など、未経験の技術を習得して実装 技術検証フェーズに時間やコストをかけられない 導入した理由・きっかけ 社内からの提案で、生成 AI の活用が適した題材と判断 低コスト（$19/月）で社内環境も整備されていたため 短期間での技術獲得とプロトタイプ開発、生成 AI 活用のノウハウ獲得を目指して導入 導入して得られた結果 新規技術（SNS API 活用技術、Streamlit によるアプリ開発技術）の習得が迅速に進んだ 開発スピードが約 3 倍に向上（通常 2 週間かかる作業が 3 日で完了） コスト削減（10 人日 → 3 人日＋$19の料金のみ、約 1/3 のコスト） 事例3: Amazon Q Developerを使用したインフラ構築（谷様の発表） 抱えていた課題 インフラ構築業務での効率化とエラー削減 Terraform の定義言語 HCL の習得や適切なコーディングの必要性 インフラコード化（IaC）におけるコードレビューと品質確保 導入した理由・きっかけ インフラ構築業務の流れが「パラメーター設計 → コード生成 → デプロイ → テスト」に変わる中で効率化を図るため コード生成からドライテスト、デプロイまでのプロセスを改善するため Claude Sonnet 4.5 が API 課金ではなく使える点が魅力的だった 導入して得られた結果 パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能に AI によるコードレビューが人間のレビューを補完し、エラー検出が向上 validate、plan、apply の各段階でのエラー検出と修正が効率化 事例4: 仕様駆動開発の手引き（古川様の発表） 抱えていた課題 「仕様が主、実装が従」という本来あるべき開発の構図が逆転しがち 仕様書の陳腐化や実装との乖離の発生 vibe coding は業務で活用するには曖昧すぎる 導入した理由・きっかけ 自分で設計して自分で実装するケースが多く、生成 AI 導入の恩恵が大きいと考えたため 他の生成 AI ツールと Amazon Q Developer の比較検討を自分自身でやってみたかったため 仕様駆動開発が開発手法として確立しつつあり、業務に適用してみたかったため 導入して得られた結果 ルール制定 → README記述 → 設計書作成 → TODOリスト作成 → 実装という流れで社内用の小規模なツールを効率的に開発できた AI が設計図やタスク分解などを自動化し、人間はレビューと意図合わせに集中できる 仕様駆動開発の考え方を取り入れることで、開発の最初に充実したドキュメントを作れるようになった 事例5: Amazon Q Developer 活用事例紹介（鈴木様の発表） 抱えていた課題 製品機能設計に向けて AI エージェント技術の理解と実験環境構築が必要だった AgentCore や CloudFormation など、大量コードの読解や IaC 化の負荷が高い 新しい技術領域で情報が少なく、定義ミスやドキュメント解釈間違いが発生しやすい 導入した理由・きっかけ Amazon Bedrock AgentCore を使った機能検討のため、AI エージェントの仕組み理解と環境構築を効率化したかった GitHub の AgentCore サンプルを活用する中で、Q を使えばコード理解・修正・IaC 化まで一気に進められると判断 大量コードの理解、React アプリ実装など AI に向いている作業が多かったため Q 活用を決断 導入して得られた結果 AgentCore + Knowledge MCP + CloudFormation による再利用可能なAIエージェント実験環境を構築 React チャットアプリやブラウザ動作確認まで実装〜テストの大部分を Q が自動化 Rules 整備やレビューを通じて、Q を“正解を出す AI ”ではなく“協働する相棒”として運用する体制を確立 Try &amp; Error の混乱を Git コミットや TODO 管理で整理し、AI と協働できる実践的な開発フローを確立 定量的な成果 3か月間の業務適用検証期間において、Amazon Q Developerを利用した取組は以下の定量的な成果を達成しました。 コード生成・開発効率 開発スピード 3 倍向上: 通常 2 週間かかる PoC 開発が 3 日で完了 工数削減 67%: 10 人日から 3 人日へ削減、コストは約 1/3 に コード生成数: 検証期間中、57 名の参加者が累計で数千行のコード生成を実施 レビュー・品質向上 レビュー時間短縮: AIによるコードレビュー支援により、人間のレビュー工数を削減しつつエラー検出精度が向上 エラー早期発見: validate、plan、apply の各段階でのエラー検出が効率化され、手戻りコストを削減 継続利用 参加率 95% : 募集定員 60 名に対し 57 名が参加し継続して利用 アクティブ利用: 検証期間中、定期的なオフィスアワーやTeams「生成AI交流広場」での活発な情報交換を実施 イベント参加: キックオフイベントに 250 名、ハンズオンに 100 名以上が参加 定性的なフィードバック（利用者の声） 検証期間中のアンケートやCITS Day 2025での発表から、以下のような利用者の声が得られました。 「SNS API や Streamlit など、未経験の技術を短期間で習得できた。新規技術獲得へのハードルが大幅に下がった」 「PoC の進め方が大きく変わることを実感。人は課題抽出やロジック検討、結果確認に注力できるようになった」 「生成 AI と開発の構造を組み合わせることで、柔軟性・速さと品質・一貫性の両立が可能になった」 「仕様書を起点に、AI エージェントに任せながら効率的に開発できる。仕様駆動開発が現実的な選択肢になった」 「パラメーターシートやアーキテクチャ図を基に Terraform コードの自動生成が可能になり、インフラ構築業務が大幅に効率化された」 検証の総括 キヤノンITS 様は、生成 AI ビジネス推進室を中心に Amazon Q Developer の展開を推進し、3 か月間の業務適用検証を通じて組織的な AI 駆動開発の定着を実現しました。エグゼクティブスポンサーの支援と予算負担の工夫により現場の参加障壁を排除し、専用 Teams チャネルでのコミュニティ形成、定期的なオフィスアワー、実践的なハンズオンセッションという段階的な学習支援を提供しました。 検証期間中、57 名の技術者が実務で Amazon Q Developer を活用し、開発スピード 3 倍向上、工数 67 %削減という具体的な定量効果を達成。Amazon Q Developer 自身で作成したダッシュボードにより利用状況を可視化し、CITS Day 2025 での表彰制度により 5 つの優秀事例を全社で共有しました。 成功の鍵は、生成AIビジネス推進室の設立による組織的な推進体制、単発イベントで終わらせない年間ロードマップに基づく継続的な支援施策、そして実ビジネスでの活用という 3 つの要素にあります。キックオフから始まり、ハンズオン、中間イベント、表彰へと続く一連の取り組みにより、SNS バズ検知システムなど実際の PoC 案件での成果を創出し、新規技術習得の加速、PoC プロセスの変革、インフラ構築の効率化など、多様な領域での効果を実証しました。 キヤノンITS 様からAmazon Web Services Japanへの期待 今回の取り組みを通じて、Amazon Q Developer を開発現場の生産性向上に有効活用できることが実感できました。PoC からインフラ構築、既存システムの改善まで、多様な領域で活用の可能性が広がっています。 今後は、今回の検証で得られた知見をもとに、社内での活用パターンの整理やナレッジの共有を進め、より多くのプロジェクトで生成AIを活かせる環境づくりを進めていきます。また、Amazon Web Services Japan 様と連携しながら、新機能の検証や他サービスとの組み合わせなど、さらなる活用領域の拡大にも取り組んでいく予定です。 生成AI が IT ライフサイクル全般の在り方を大きく変えつつある中、私たちは、現場の開発体験を改善するとともに、社会やお客様へ更なる価値提供に向けて積極的に活用していくための取り組みを継続して進めていきます。 執筆者 キヤノンITソリューションズ株式会社 生成AIビジネス推進室 石堂 きよみ Amazon Web Services Japan ハイテク&amp;ヘルスケア事業本部 アカウントマネージャー Amazon Web Services Japan ソリューションアーキテクト 木村 直登(Naoto Kimura)

本記事は、シリーズ「AWS における AI エージェント対応のデータ基盤」の第 2 回です。 第 1 回 では、AI エージェントが組織の本番データに対して正しく動くために必要な 3 要素（認可・ビジネスデータカタログ・ドメイン知識）を紹介し、認可が効いている様子をデモで示しました。本記事では、3 要素のうち認可に焦点を当て、AI エージェント経由のデータアクセスに Amazon SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説します。 サンプルリポジトリ: aws-samples/sample-sagemaker-agentic-analyst aws-samples sample-sagemaker-agentic-analyst A demo application that demonstrates how fine-grained access controls configured in SageMaker Unified Studio are transparently enforced on data access through AI agents. AI エージェントにアクセス制御を効かせる 3 つの壁 AI エージェントにデータアクセスを任せるとき、守るべき原則があります。エージェントは独自の認可ロジックを持たず、ユーザーが SageMaker Catalog で付与されている権限を、エージェント経由でもそのまま透過的に利用させることです（SageMaker Catalog は Amazon DataZone の上に構築されており、権限設定は DataZone API で操作します）。エージェント内に独自の認可ロジックを作ると、既存のガバナンスと二重管理になり、整合性を保つのが難しくなるからです。 この原則を実現しようとすると、素直な実装ではたどり着けない 3 つの壁があります。これらは本記事で解説する設計上の工夫によって越えられます。 壁 1: コンピュートリソース自体のロールで権限を取得すると、全ユーザーが同一権限になる。 AI エージェントのツールは AWS Lambda 、 AWS Fargate 、 Amazon EC2 など何らかのコンピュートリソース上で実行されます。そのコンピュートリソース自体のロール（たとえば Lambda の実行ロール）で DataZone の GetEnvironmentCredentials API を呼ぶと、返ってくるのはそのロール自身のメンバーシップに基づくプロジェクトロールです。どのユーザーがリクエストしても同じ認証情報が返るため、ユーザー個別のアクセス制御を効かせるには工夫が必要です。 壁 2: SAML フェデレーション経由のトークンには、IdP 側のグループ情報が乗らない。 AWS IAM Identity Center （以下 IdC）と、たとえば Amazon Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報が Cognito のトークンに自動的には含まれません。「データコンシューマーには athena_query を許可し、ドメイン管理者には cloudtrail_query のみ許可する」といったツール単位の認可を IdC のグループベースで行うには、グループ情報をトークンに載せる工夫が必要です。 壁 3: 設定時と実行時で関与するサービスが異なり、認可の全体像を把握する必要がある。 SageMaker Catalog の裏側では複数のサービスが連携しています。設定時に使うサービスと、クエリ実行時に評価されるサービスが異なるため、全体像を把握しないと正しい実装にたどり着けません。 本記事では、サンプルリポジトリ sample-sagemaker-agentic-analyst がこれらの壁をどう越えているかを解説します。 サービスの役割分担を整理する 本記事で扱うサービスの関係を先に整理します。 Amazon SageMaker Catalog は、データと AI の発見・ガバナンス・コラボレーションを担うサービスで、Amazon DataZone の上に構築されています。データの Publish/Subscribe やアクセス権の設定は SageMaker Catalog（および Amazon SageMaker Unified Studio の UI）で行いますが、実際のクエリ実行時に行・列レベルのアクセス制御を評価するのは AWS Lake Formation です。S3 上のファイルに対するアクセス制御は Amazon S3 Access Grants が担います。 つまり、SageMaker Catalog で「誰がどのデータを見てよいか」を 設定 し、Lake Formation と S3 Access Grants が 実行時 にその設定を評価する、という役割分担です。 重要な原則として、DataZone はクエリ実行パスに入りません。後述する認証情報変換フローでは DataZone API（ RedeemAccessToken / GetEnvironmentCredentials ）を呼びますが、これは AgentCore Gateway に接続された Lambda（以下 Tool Lambda）が プロジェクトロールの認証情報を取得する ための前段であり、Athena クエリや S3 オブジェクト取得そのものには DataZone は介在しません。クエリ実行時の認可評価は Lake Formation と S3 Access Grants が担います。この「認証情報取得の経路」と「データアクセスの経路」の分離を理解しておくと、以降のフローが読みやすくなります。 認証情報変換フロー: 5 つのステップ 壁 1 と壁 3 に対応するため、本サンプルでは 5 つのステップで認証情報を変換します。ブラウザでサインインしたユーザーの Cognito トークンから出発し、最終的にそのユーザーの権限が反映された SageMaker プロジェクトロールの一時認証情報を Tool Lambda の手元に届けます（下図）。 Step 1: ブラウザから AgentCore Runtime へ ブラウザ上の React アプリが、 Amazon Bedrock AgentCore Runtime のエンドポイントに HTTPS リクエストを送ります。このリクエストには 2 つのトークンが乗っています。 Authorization: Bearer &lt;Cognito Access Token&gt; — Runtime の Cognito Authorizer が検証します カスタムヘッダー X-Amzn-Bedrock-AgentCore-Runtime-Custom-Cognito-Id-Token: &lt;Cognito ID Token&gt; — 次のステップで使います Cognito Access Token と Cognito ID Token はどちらも Amazon Cognito が発行する JSON Web Token（JWT）ですが、役割が異なります。Access Token は「このリクエストは正当なユーザーから来たか」を Runtime と Gateway が判定するために使います。ID Token はユーザーのアイデンティティ情報（メールアドレスなど）を含んでおり、次のステップで IdC のユーザーと突き合わせるために使います。 Step 2: chat-agent が Cognito ID Token を IdC Access Token に引き換える Amazon Bedrock AgentCore Runtime はエージェントプロセスをホストするマネージドサービスです。呼び出し主体はその上で動くユーザーコード（本サンプルでは chat-agent ）であり、Runtime サービス自身がトークン変換を自動で行うわけではありません。 chat-agent が IdC の CreateTokenWithIAM API を呼びます。 const tokenRes = await new SSOOIDCClient({ region }).send( new CreateTokenWithIAMCommand({ clientId: idcApplicationArn, grantType: 'urn:ietf:params:oauth:grant-type:jwt-bearer', assertion: cognitoIdToken, }), ); const idcAccessToken = tokenRes.accessToken; jwt-bearer grant で Cognito ID Token を渡すと、IdC はそのクレームから IdC ユーザーを特定し、IdC Access Token を返します。 ここで 2 つの補足があります。 Cognito JWT と IdC Access Token は別物です。 発行者が違い（Cognito vs IdC）、形式も違います（JWT vs 不透明トークン）。Cognito JWT は Cognito 連携アプリでしか通用しませんが、IdC Access Token は IdC の Trusted Identity Propagation（TIP） に対応した AWS サービスで通用します。TIP は、IdC ユーザーのアイデンティティを IAM ロールの STS セッションに identity context として伝播させる仕組みです。DataZone は TIP 対応サービスの 1 つで、 RedeemAccessToken はその入口に位置します。 CreateTokenWithIAM と RedeemAccessToken は、このトークンの世界をまたぐブリッジの役割を果たします。 ただし本サンプルでは、TIP の identity-enhanced session をそのままデータ層まで持ち込んで Lake Formation や S3 Access Grants に評価させる構成は採っていません。SageMaker Catalog の Publish/Subscribe モデルが プロジェクトロール に行・列・オブジェクトレベルの権限を付与する設計になっているため、IdC ユーザーのアイデンティティは RedeemAccessToken → GetEnvironmentCredentials を経由してプロジェクトロールへ引き換えられ、以降のデータアクセスはプロジェクトロールの権限で評価されます。TIP の役割はこの引き換えの前段に限定され、本記事の焦点もそこにあります。 CreateTokenWithIAM には jti 制約があります。 JWT には jti （JWT ID）という一意識別子のクレームがあり、IdC は jwt-bearer grant で受け取った JWT の jti を記録します。同じ jti の JWT が再度送られると拒否されるため、同一の Cognito ID Token で CreateTokenWithIAM を 2 回呼ぶことはできません。このため、chat-agent で 1 リクエストあたり 1 回だけ実行し、得られた IdC Access Token を x-idc-access-token カスタムヘッダーで AgentCore Gateway 経由で全 Tool Lambda に伝播する設計になっています。 なお、 CreateTokenWithIAM を呼ぶための IAM アクション名は sso-oauth:CreateTokenWithIAM です。SDK クライアントは SSOOIDCClient を使いますが、IAM ポリシー側のサービス名は sso-oauth になります。また、IdC の OAuth Customer Managed Application に datazone:domain:access スコープを事前に登録しておく必要があります。 Step 3: Tool Lambda が IdC Access Token を DomainExecutionRole の認証情報に引き換える Tool Lambda が Amazon DataZone の RedeemAccessToken エンドポイントに HTTP POST を投げます。 const redeemRes = await fetch( `https://datazone.${region}.api.aws/sso/redeem-token`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ domainId, accessToken: idcAccessToken }), }, ); const { credentials: domainExecRoleCreds } = await redeemRes.json(); RedeemAccessToken は AWS SDK に含まれていません。 公開ドキュメントでは Athena JDBC ドライバ経由の利用例（ Analyze subscribed data via JDBC ）が示されていますが、サーバーサイドアプリからの直接呼び出しは生の HTTP リクエストで行う必要があります。このため、エンドポイント URL も通常の DataZone SDK が使う datazone.{region}.amazonaws.com ではなく datazone.{region}.api.aws を指定します。 この API には 2 つの特徴があります。SigV4 署名が不要であること（認証は IdC Access Token 自体が行う）、そして jti 制約がないため並列の Tool 呼び出しで複数の Lambda が同じ IdC Access Token を使っても問題ないことです。 返ってくるのは DomainExecutionRole の一時認証情報（ accessKeyId / secretAccessKey / sessionToken / expiration ）です。DomainExecutionRole は SageMaker Unified Studio ドメインに紐付く IAM ロールで、この認証情報には IdC ユーザーのアイデンティティが紐付いています 。内部的には、 RedeemAccessToken が DomainExecutionRole を assume する際に、Step 2 で触れた TIP の仕組みにより STS セッションに IdC ユーザーの identity context が埋め込まれます。これが次のステップで効いてきます。 Step 4: Tool Lambda が DomainExecutionRole の認証情報でプロジェクトロールを取得する Tool Lambda が Amazon DataZone SDK を DomainExecutionRole の認証情報で 初期化し、 GetEnvironmentCredentials を呼びます。 const envCreds = await new DataZoneClient({ region, credentials: domainExecRoleCreds, }).send( new GetEnvironmentCredentialsCommand({ domainIdentifier: domainId, environmentIdentifier: environmentId, }), ); Amazon DataZone は呼び出し元の STS セッションから identity context を取り出し、IdC ユーザーを特定します。そのユーザーがプロジェクトのメンバーであれば、プロジェクトロールの一時認証情報を返します。メンバーでなければ拒否されます。 ここが本サンプルの核心です。DomainExecutionRole の認証情報で呼ぶからこそ、 ユーザー本人のメンバーシップ で認可が評価されます。もし Lambda 実行ロールで直接 GetEnvironmentCredentials を呼んでいたら、Lambda 実行ロール自身のメンバーシップで判定されてしまい、ユーザーごとの権限差が消えます。 Step 5: プロジェクトロールで Athena / S3 を呼び出す Tool Lambda が Athena や S3 のクライアントを プロジェクトロールの認証情報で 初期化し、クエリやオブジェクト取得を実行します。 const athena = new AthenaClient({ region, credentials: { accessKeyId: envCreds.accessKeyId, secretAccessKey: envCreds.secretAccessKey, sessionToken: envCreds.sessionToken, }, }); Athena がクエリを実行すると、Lake Formation がプロジェクトロールの権限に基づいて行・列レベルのフィルタリングを透過的に適用します。ユーザーの権限の範囲内にある行と列だけが結果として返り、範囲外の情報は応答に含まれません。 ステップのまとめ Step 主体 API 入力 出力 1 ブラウザ → Runtime POST /invocations — Cognito Access Token + ID Token（Runtime に到達） 2 chat-agent → IdC CreateTokenWithIAM Cognito ID Token IdC Access Token 3 Tool Lambda → DataZone RedeemAccessToken IdC Access Token DomainExecutionRole 認証情報 4 Tool Lambda → DataZone GetEnvironmentCredentials DomainExecutionRole 認証情報 プロジェクトロール認証情報 5 Tool Lambda → Athena/S3 StartQueryExecution / GetObject 等 プロジェクトロール認証情報 クエリ結果 / オブジェクト Step 5 の S3 アクセスは Publisher と Subscriber で経路が分かれます。後述の「Publisher と Subscriber で異なる S3 アクセス方式」で詳述します。 この設計では、 Lambda 実行ロールはデータアクセスに一切使いません 。権限判定はすべてユーザーに紐付いた認証情報で行われます。 Policy in AgentCore によるツール単位認可 認証情報変換フローはデータアクセスの認可を扱いますが、「どのユーザーがどのツールを呼べるか」という別軸の認可も必要です。AgentCore の認可モデルは、 Inbound（ユーザー → AI エージェントへの入口） と Outbound（AI エージェント → ツールへの出口） の 2 軸で整理されます。Inbound は AgentCore Runtime の JWT Authorizer が Cognito Access Token を検証して「この呼び出し元はエージェントを呼んでよいか」を判定します。Outbound はツール単位の認可で、本サンプルでは AgentCore Gateway の Policy in AgentCore で実現しています（下図）。 グループ情報の埋め込み 壁 2 で述べた通り、IdC と Cognito を SAML フェデレーションで連携する構成では、IdC 側のグループ情報は Cognito トークンに自動的には含まれません。本サンプルでは、 Amazon Cognito の Pre token generation Lambda trigger の V2 イベントを使い、Cognito Access Token に cedar_groups カスタムクレームを埋め込みます。値は |data-producers|security-auditors| のようにパイプ区切りの文字列です。 Cedar ポリシーによる評価 Policy in AgentCore では、Cedar 言語で記述されたポリシーを policy engine に登録し、それを AgentCore Gateway に関連付けます。Gateway にリクエストが到達すると、policy engine が Cognito Access Token の cedar_groups クレームを読み取り、Cedar ポリシーで評価します。Gateway はリクエスト時点で JWT のクレームを AgentCore::OAuthUser エンティティのタグとして Entity Store に格納するため、ポリシー上は principal.getTag("cedar_groups") のようにタグとして参照します。「JWT では cedar_groups クレーム、Cedar ポリシーでは cedar_groups タグ」という名前の対応関係です。 permit( principal is AgentCore::OAuthUser, action, resource == AgentCore::Gateway::"&lt;gateway-arn&gt;" ) when { principal.hasTag("cedar_groups") &amp;&amp; principal.getTag("cedar_groups") like "*|security-auditors|*" &amp;&amp; (action == AgentCore::Action::"cloudtrail-query___cloudtrail_query") }; このポリシーは「 security-auditors グループに属するユーザーだけが cloudtrail_query ツールを呼べる」ことを宣言しています。アクション名の cloudtrail-query___cloudtrail_query は、AgentCore Gateway が MCP ツール定義から自動生成する命名で、 ターゲット名（ cloudtrail-query ） ___ ツール名（ cloudtrail_query ） の形を取ります。 Cedar の policy engine は default-deny （明示的に許可されない限り拒否）で動作します。上記の 1 本のポリシーだけでは security-auditors 向けの 1 ツールしか許可されていないため、他のユーザー・他のツールはすべて拒否されます。同様のポリシーを複数定義することで、たとえばデータコンシューマーには athena_query と s3_read のみを許可し、データプロデューサーにはカタログ管理ツールも許可する、といった職務分離を実現できます。 Policy in AgentCore によるツール単位認可と、認証情報変換フローによるデータアクセス認可は独立した 2 つの軸です。Gateway で「このユーザーはこのツールを呼んでよいか」を判定し、Tool Lambda で「このユーザーはこのデータを見てよいか」を判定します。 Publisher と Subscriber で異なる S3 アクセス方式 非構造化データ（S3 上のファイル）へのアクセスは、プロジェクトの役割によって経路が異なります。Amazon S3 Access Grants は、S3 の prefix / bucket / object 単位で IAM プリンシパルやディレクトリユーザーに READ/WRITE/READWRITE 権限を付与する仕組みで、 GetDataAccess API で当該対象への一時認証情報を取得してから S3 API を呼ぶ形で利用します。SageMaker Catalog の Publish/Subscribe は、この Grant を Subscriber のプロジェクトロールに対してのみ自動作成する 設計です。Publisher 側のプロジェクトロールには明示的な Grant が作られず、Publisher は別のパス（IAM ポリシーによる直接アクセス）でバケットを読みます。これが Publisher/Subscriber で経路が分かれる理由です。 Publisher（プロジェクトがバケットを所有する場合）: プロジェクトロールの認証情報で直接 S3:GetObject を呼びます。アクセス権は、プロジェクトロールに付与された IAM インラインポリシー（プロジェクト配下のプレフィックスに限定）によって許可されます。Publisher プロジェクトロール自身への明示的な S3 Access Grants の Grant は存在しないため、 GetDataAccess は失敗します。 Subscriber（別プロジェクト経由で購読する場合）: SageMaker Unified Studio の Publish/Subscribe が Subscriber ロールに対して IAM タイプの Grant を自動作成します。Tool Lambda はまず S3Control:GetDataAccess で一時認証情報を取得し、その認証情報で S3:GetObject を呼びます。 判断ロジックは、コネクションの accessRole の有無とプロジェクトの所有関係で決まります。プロジェクトレベルのコネクションで accessRole があれば S3 Access Grants 経由、なければ直接アクセスです。 まとめと次のアクション 本記事では、AI エージェント経由のデータアクセスに SageMaker Catalog のアクセス制御を透過的に効かせる実装パターンを解説しました。 設定時と実行時の役割分担 を整理し、SageMaker Catalog / DataZone が設定を担い、Lake Formation / S3 Access Grants が実行時に認可を評価する構造を明確にする 認証情報変換フロー （ CreateTokenWithIAM → RedeemAccessToken → GetEnvironmentCredentials ）で、ユーザーに紐付いたプロジェクトロールの認証情報を Tool Lambda に届ける Policy in AgentCore で、ツール単位の認可をデータアクセス認可とは独立した軸で制御する Lambda 実行ロールはデータアクセスに一切使わず、権限判定はすべてユーザーに紐付いた認証情報で行われます。これにより、SageMaker Catalog で設定された行・列・オブジェクトレベルのアクセス権は、AI エージェント経由でも透過的に適用されます。 第 1 回 で紹介した拡張性（ゼロショット時系列予測のオンデマンド実行）も、本記事で解説した認可の仕組みに支えられています。アクセス制御されたデータを、追加の認証設計なしで Amazon SageMaker AI の推論エンドポイントに流し込めるのは、プロジェクトロールの認証情報が Tool Lambda の手元まで届いているからです。サンプルリポジトリの apps/gateway-tools/time-series-forecast/ と design/data-access-control.md で実装の詳細を確認できます。 高野 賢司 AWS のシニアソリューションアーキテクトとして、東海以西の製造業のお客様を中心に支援しています。Infrastructure as Code や AI 駆動開発を中心とした開発者ツールのエキスパートでもあり、 Kiro によって広がったソフトウェア開発の世界を楽しんでいます。