こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの 最終回 となる第 8 回レポートです。シリーズの背景や全体像については、 大阪・IT 企業編レポート をご覧ください。 前日（5 月 14 日）の AI を自社の業務に活かしたい企業の皆様向けセッション に続き、2026 年 5 月 1

G-gen の佐々木です。当記事では、Google Cloud のサーバーレスコンテナサービスである Cloud Run の新しいリソースタイプ、 Cloud Run instances について解説します。 概要 Cloud Run とは Cloud Run instances とは ユースケース Cloud Run instances の基本 特徴 ライフサイクルと再起動ポリシー 主な設定項目 CPU のバーストとスロットリング 注意点 料金 他のリソースタイプ・サービスとの比較 Cloud Run

Elastic Clous Serverless では、これまで Amazon Web Services の 東京リージョンを利用することができましたが、これに加えて、Google Cloud Platform (GCP) の東京リージョン（ asia-northeast1 ）も利用できるようになりました。 日本国内のワークロードにおいて、インフラ管理不要な検索・分析基盤を低レイテンシーで導入できるようになります。 目次 今回のアップデートのポイント 主な活用ユースケース はじめる手順 参考URL 今回の

はじめに 現在、運用しているアプリケーションの老朽化や今後のコスト最適化・拡張性の確保を背景にシステム全体のリプレイスを進めており、その一環としてデータベースは現在のAmazon AuroraおよびDynamoDBからTiDB Cloud（Dedicated）への移行を進めています。 本記事では、このデータベース移行を進めるにあたって調べた内容や実際にハマったポイント等々を紹介したいと思います。 前提 現在の構成 Amazon Aurora MySQL（4クラスタ） DynamoDB 移行後の構成 TiD

2026 年 8 月 21 日、 AWS Glue 6.0 の一般提供について発表しました。これにより、価格が以前の AWS Glue バージョンよりも 30% 低くなり、 Apache Iceberg v3 の機能が完全にサポートされるようになりました。AWS Glue 6.0 は、完全に近代化されたランタイム、Apache Spark 4.1、Python 3.12、および Scala 2.13 に基づいて構築されており、より高速なパフォーマンスを実現しています。 このリリースにより、AWS Glue

本記事は 2026 年 8 月 20 日 に公開された「 Long-term system tables retention in Amazon Redshift with Amazon S3 Tables 」を翻訳したものです。 Amazon Redshift のシステムテーブルは、実行されたすべてのクエリ、確立されたすべての接続といった運用シグナルを継続的に記録します。収集したデータは、データウェアハウス全体の可観測性、パフォーマンス分析、コンプライアンス監査を支えます。しかしこれまで、システムテーブ

はじめに 株式会社セガは、家庭用ゲーム機、PC、スマートフォン向けゲームの企画・開発・販売・運営を軸に、各種コンテンツや商品を全世界へ届けています。同社では、比較的新しい技術も積極的に取り入れる文化のもと、複数タイトルで AWS を活用してきました。 本記事では、同社が開発・運用する『ソニックランブル パーティ』のバックエンドに Amazon DynamoDB と Amazon ElastiCache Serverless for Valkey を採用した経緯・技術的な工夫・得られた効果を、開発チームの声

チューリングの MLOps エンジニアの岩政です。 チューリングでは、センサ入力から車両の将来の行動を一貫して推定する学習ベースのモデルとして End-to-End (E2E) 自動運転 AI を開発しています。E2E 自動運転 AI の学習にはデータセットが必要です。私の所属する MLOps チームが、これを作成するためのデータ基盤の開発を行っています。 MLOps チームでは車両に搭載したカメラなどのセンサから走行データを収集し、Data Lake に格納しています。更に ETL (Extract,

2026 年 8 月 3 日週、私たちは世界中から集まった AWS ヒーローたちを集め 、つながり、協力し、AWS コミュニティでこれまで以上に活躍したビルダーを祝いました。 AWS Heroes Summit は招待制の年次集会で、AI、サーバーレス、コンテナなどの分野を専門とする世界中の専門家が一堂に会し、社内の AWS 製品およびサービスチームとの直接のコラボレーション、技術的な詳細調査、フィードバックセッションを行います。 1日目は、AWS の CEO、マット・ガーマンによる心に響く暖炉辺談話から

本記事は 2026年7月6日に公開された「 Turn Your Amazon CloudWatch Alarms into Actionable Signals 」を翻訳したものです。 午前2時にアラームが鳴ります。スマートフォンを手に取り、目を細めて通知を見ると、こう書いてあります： 「ALARM: my-service-alarm が ALARM 状態に遷移しました。」 コンテキストなし。アプリケーション名なし。200台のインスタンスのうちどれが問題なのか、そもそもそれが重要なのかすら分かりません。

本記事は 2026 年 7 月 14 日に公開された Jishnu Dasgupta と Chetan Dharma の “ Automated Incident Remediation with AWS DevOps Agent and Kiro CLI ” を翻訳したものです。 はじめに インシデント修正の自動化、つまり調査結果を人手をかけずにデプロイ済みの修正へとつなげることは、AWS 上で分散ワークロードを運用するオペレーションチームにとって次の課題です。現在、インシデントが深夜 2 時に発生する

2026 年 8 月 5 日、 Amazon DynamoDB でのベクトル検索の一般提供についてお知らせします。運用データとともにベクトル埋め込みを DynamoDB に保存し、別のベクトルストアにデータを複製することなく、そのデータに対して直接類似度検索を実行できるようになりました。 DynamoDB は、99%以上の再現率を維持しながら、1桁ミリ秒のレイテンシーでネイティブなベクトル検索をサポートします。また、数兆個のベクトルを含む大規模なデータにも対応できるよう設計されています。サーバーのプロビジ

2026 年 5 月 22 日、金融庁と日本銀行は 「フロンティア AI による脅威変化を踏まえた金融機関等の短期的な対応」に係る要請 (金総政第 3245 号ほか) を公表し、経営トップを含めた経営層の直接関与の下で、短期的な対応に取り組むよう金融機関等に要請しました。 要請では、いわゆる「フロンティア AI」により、脆弱性の発見・修正等のサイバーセキュリティ性能の急速な向上が見込まれることを踏まえ、これに対応する取組が必要不可欠とされています。フロンティア AI を用いてソフトウェアの脆弱性を発見・修

はじめに この記事で学べること 前提知識・条件 結論となる3つの設計原則 原則1: コンテキストロットを前提に設計する すべての LLM（大規模言語モデル）は入力長に応じて性能が劣化する 1万行程度でもコンテキストに収まりづらい 実際どのくらいから劣化する？ ノイズとして取り込まれる要素 スマートゾーンとダムゾーン コンテキストエンジニアリング 対策としてのセッション・コンパクション 原則2: ソフトウェアを境界で分割し、近接して配置する（Pragmatic Lambda / モノレポ） なぜ境界が必要か

本稿は、Japan Digital Design 株式会社 佐藤様による「三菱UFJフィナンシャル・グループの DX を牽引する Japan Digital Design、Aurora DSQL の採用で DB コストを約 87% 削減し、運用負荷ほぼゼロを実現」に関する寄稿記事となります。 こんにちは。Japan Digital Design 株式会社 Technology & Development Division で Technical Project Manager を務めている佐藤です