はじめに こんにちは、同志社大学理工学部情報システムデザイン学科4年生の金谷一輝です。 2026年7 ...

概要 メルカリでは、CoreDB と呼ばれる中核データベースを長年オンプレミス上の MySQL で運用してきました。本記事では、2026 年 4 月に完了した MySQL から TiDB への移行を振り返り、長期的なスケーラビリティの改善、弾力的なリソース確保、クラウド化による運用負荷の軽減といった成果を紹介します。また、移行フローや ProxySQL を活用した段階的な切り替えでうまくいった点、実トラフィックを用いた検証やコスト見積もりで直面した課題、移行後に見えてきた改善テーマについても整理します。 TL;DR 中核データベースであるCoreDBを 2026/04 にオンプレミスMySQLからTiDBへ移行完了 移行により下記の当初目的を達成 長期的スケーラビリティの改善 トラフィック変動に応じたリソース調整 オンプレミス運用からの脱却 DBREのEM/ICを募集中 もう少し詳しい内容が知りたい方へのポイントまとめ 移行は問題があればMySQLに切り戻し可能な構成を維持しながら実施 ProxySQLを活用し段階的にTiDBに本番トラフィックを移行 切り替えを中央管理し、アプリケーションから透過的な切替を実現 バッチ(OLAP)エンドポイントの先行移行、切り替え前の実トラフィックの9回のテストで問題を事前に検出 クエリリプレイによるテストを心がけるも80%負荷再現が当時の限界 事前のベンチマークには問題があり、不正確なコスト見積もりに TiDB DDLはオンライン化/分散実行による高速化を達成 DDL運用負荷が減り、「あるべきテーブル定義」ベースに 上記の内容を、記事内で順に説明していきます。 背景 メルカリには、商品・取引・ユーザーなどのクリティカルなビジネスデータを扱う中核データベースとして CoreDB と呼ばれるデータベースがあります。これは、メルカリのサービス開始当初から利用されていたモノリスアプリケーションのデータを格納してきたものです。下記の記事でもある通り、マイクロサービス化とともに、新規のドメインの独立したマイクロサービスに関しては、各々の独立したデータベースを持ち開発チームがデータベースを持つ運用を想定して、データベースも可能なものは分割してきました。しかし、現在でもなお多くのデータが CoreDB に格納されています。 https://www.publickey1.jp/blog/18/mercari_tech_conf_2018.html この CoreDB は、長らくオンプレミスサーバー上の MySQL で運用してきました。以前は石狩のデータセンターで稼働していましたが、多くのアプリケーションが Google Cloud の東京リージョンへ移行したことを受け、主にアプリケーションとの通信レイテンシを削減する目的で、東京のオンプレミスサーバー上の MySQL へ移行しました。 また、スケールアウト、つまり Read Replica を増やすことで、メルカリのトラフィックの大多数を占める読み取りトラフィックのスケールを実現しながら、同時にスケールアップも行い、運用に収まる現実的な台数を維持しながら運用を行っていました。 https://engineering.mercari.com/blog/entry/20220218-3c7faca4cc/ (Stateful なレガシー MySQL server の章) また、このスケールアップおよびスケールアウトとともに、必要なデータ保存量やトラフィックの増加に伴い、垂直シャーディングを繰り返してきました。すなわち、データの性質が異なり、結合クエリの発行が必要ない範囲に関しては、ソースおよびレプリカのセット、以後クラスタと呼びます、を分け、複数のクラスタで運用をしてきました。 垂直シャーディング( 他のブログ記事 より画像を引用) 今回、2026 年 4 月に全ての MySQL サーバーの書き込みトラフィックを TiDB に移行完了しました。それにあたり、当初何を解決したかったか、それがどのようになったかについて簡単に振り返りたいと思います。 移行にあたって、個別の事象としては、数々の解決してきた課題があり、これについては別のブログ記事で紹介します。 TiDB 移行で何を解決したかったか まずは、移行当初の目的について振り返ります。TiDB 移行により、主に次の 3 つの課題を解決しようと考えていました。 長期のスケーラビリティーの改善 MySQL は Write ノードが単一であるため、書き込み性能を上げるためには、基本的により高性能なサーバーへ置き換えるスケールアップが主な選択肢になります。読み取り性能は Read Replica を増やすことで伸ばしやすい一方、書き込み性能は同じようには水平に伸ばしにくく、大規模なサービスでは長期的な制約になりやすい領域です。 TiDBはMulti Writer, 実データを保存するTiKVもスケール メルカリではスケールアウトとスケールアップを繰り返してきた結果、クラウドなどへの移行を検討する際に、必要なスペックのサーバー、つまりインスタンスクラスがない、あるいは性能が不足する、といったことが発生してきました。また、オンプレミス環境でスケールアップの対応を行うには、非連続なコスト、特にハードウェア調達時に多額のキャッシュアウトが発生し、特異なスペックのサーバーを運用することのリスクなどを含め、限界を迎えつつありました。 トラフィックの増減に対する弾力的なリソース確保 トラフィック増への対応は、物理サーバーの調達、設置など含め、数ヶ月の時間がかかります。また、物理サーバーがある状態でも、スケールアウトを行おうとした場合に、トラフィックの増加に合わせて新規のサーバーをサービスで利用可能にするまでは時間がかかりました。 主に多量のデータを複製する必要があるところに時間がかかったのですが、 XtraBackup と呼ばれるオンラインバックアップ取得ツールで一貫性のあるバックアップを取得しながら、データを新規サーバーにストリームで転送し、その後リカバリ、そして遅延の解消といった工程が必要で、最終的に利用可能になるまで全作業で 2 日ほどかかりました。 オンプレミス運用からの脱却 自社のデータセンターで物理サーバーをホスティングしている以上、維持、運用にも一定のエンジニアリングが求められます。一方で、自社データセンターでは何千、何万台以上といった規模のサーバーを運用しているわけではないため、該当スキルを全面に押し出して積極採用するわけにもいきません。さらに、世の中全体としてクラウド化が進んできた現在、オンプレミス環境の運用に関する経験を有するエンジニアの採用自体が難しくなりつつあります。 また、現状の自社のサーバー運用規模においては、OS / MySQL のデプロイといったことからは解放された上で、性能問題などを解決し、高効率化したい要望がありました。 移行によりどうなったか 今回、TiDB への移行が完了し、それぞれどうなったかを振り返ります。 長期スケーラビリティーの改善 書き込み性能に関してもスケールアウトにて対応可能になったことで、書き込みキャパシティーが大幅に向上しました。 TiDB 移行とともに、大量の不要なデータを削除していたのですが、この際に削除を含めた書き込みのボトルネックが MySQL 側、つまり高いハードウェアスペックのサーバーにあり、TiDB 側は十分な余力がある状態でした。 弾力的なリソース確保 物理サーバーの調達の時間が必要なくなったのは当然ながら、物理サーバーでのリストアは 1 日を超える時間がかかっていたところ、1 日の中で負荷に合わせてリソースをスケールできるようになりました。 https://engineering.mercari.com/blog/entry/20260421-7b2dff6bce/ このスケールの速度の変化により、より効率的な、具体的には高いリソース利用率目標での運用が可能になりました。また、必要なリソース量に対して、細かい粒度でのリソース利用量の調整が可能になりました。 弾力的なリソース確保 オンプレミス運用からの脱却 必要があれば、オンプレミスの MySQL への依存をなくす目処がたち、採用の問題についての懸念事項解消へ大きく前進しました。 また、OS や MySQL のセットアップ、OS への Security Patch 適用、といった問題への対処からも解放されました。 移行全体の振り返り ここまで、当初の大きな目論見に対して、実際にどうだったかを振り返りました。 ここからは、移行全体でのプロセスとしてうまくいったこと、うまくいかなかったことの振り返りを行います。 うまくいったこと：移行のフロー全体 https://pingcap.co.jp/case-study/mercari-tidb-cloud/ TiDB User Day 2025 でも紹介した上記の切り替えに関する大雑把なフローは、手のかかるものでしたが、事前に多くの課題を抽出可能とし、かつ、仮に問題に直面した場合にも、MySQL に再度トラフィックを戻すことができるシステム構成を整えました。 このような、システムの更新・切り替えに問題があった際に元に戻せるようにすることは、変更の適用における基本事項の 1 つではありますが、愚直にやり切りました。これにより移行の是非の意思決定をスムーズに行うこともでき、移行全体を成功に導きました。 うまくいったこと：バッチエンドポイントの先行リリース データベースには複数のエンドポイントがあり、また、データベースは複数のマイクロサービスから利用されている状況でした。切り替えを段階的に行う方法は複数考えられ、例えば、マイクロサービス毎に読み取りを切り替えていく、などの方法も考えられました。 その中で、マイクロサービス毎の切り替えは行わず、アプリケーションとデータベースの間に ProxySQL とよばれる Proxy を配置し、Reader エンドポイントに対しては、徐々に TiDB にトラフィックをシフトしていくことにしました。 ProxySQL を活用した目的は、大きく 2 つありました。1 つは、多くのマイクロサービスに対して、接続先データベースの切り替えを透過的に行えるようにすることです。もう 1 つは、切り替え主体である DBRE（DataBase Reliability Engineering）チームがトラフィックの切り替えを一元的に管理し、問題発生時に迅速に対応できるようにすることです。 一方で、Reader エンドポイントの中でも、OLAP（Online Analytical Processing）に近いよりリスクの高いクエリを含むエンドポイント（バッチエンドポイントと呼ぶ）へのトラフィックを先行して切り替えることにし、複数の問題を事前に発見し対処することができました。 バッチエンドポイント切り替えは、その他の Reader エンドポイント切り替えの 5 日前に実施しました。その前に、前提となる MySQL から DM（Data Migration）を通じた TiDB へのデータ同期の遅延の問題を先に解消したり、万が一一定の遅延が発生した際に、TiDB から自動的に MySQL に参照先が戻るような実装を行いました。 https://docs.pingcap.com/tidb/stable/dm-overview/ うまくいかなかったこと：クエリリプレイの限界 TiDB クラスタの移行は、大体トラフィックの少ない順に移行を行い、多くのクラスタは予定通りに進行したものの、一番最後に残った最大のトラフィックをかかえるクラスタで、複数回の予定延伸が発生しました。 移行のフローに記載していないこととして、クエリリプレイを行った上で、一定期間、読み取りの実トラフィックを TiDB に流す、という予行演習・テストを複数回実施しました。 実トラフィックを流すことによるテストは、もちろん一定のリスクがありますが、最終的に全てのトラフィックを TiDB で処理しようとしている、ということから、切替えの必要条件として少なくとも一定時間、実際のトラフィックを切り替え後の構成で処理できている必要があります。 最後の最大のトラフィック流量を持つクラスタでは、永続運用を目指す本番の切り替え前に、9 回実トラフィックを一時的に試験的に実際のサービスに切り替えました。日中のトラフィックがあまり変わらない時間帯で短時間テストを行い、最終的にはピークタイムで問題なく処理できることの確認を行なっています。 この 9 回の中には最終的な本番切り替え成功に導くための、多くの失敗、つまり学びが含まれていました。負荷を増やすと明らかになった不具合事象の発見もあれば、象徴的な事象として、100% の負荷を流したところ、必要なノード数が多くなった結果、TiDB Cloud の監視サーバーが想定していない負荷となり、メトリックが何も見えなくなった、といったことも発生しました。 最終的な動作確認は、実トラフィックで必要なものの、例えば、上記であげたハイトラフィックの状態で監視が正常通り稼働するかなど、できるだけ多くの観点を実際のトラフィックに影響を与えずに確認できるのが望ましいです。実トラフィックの 100% を移行先の環境にミラーして比較ができることが理想的です。 これに対して、メルカリではリプレイツールなどを利用してそれに対応していたものの、一定以上のトラフィック量だと、リプレイによる「取りこぼし」がありました。実際のユーザートラフィックに影響を与えず、できるだけ取りこぼさず本番に近い負荷をかけることが目標で、これに対して独自ツールは当初、最大トラフィックの 50% 程度のリプレイが実現できていました。様々なボトルネックの解析などを経て、最終的にはメルカリの負荷の 80% 程度はリプレイ可能になりました。 しかし、この 80% 以上はリプレイでは負荷再現ができず、ピークトラフィックとのギャップを埋めた上で検証を行うため、実トラフィックによる試験を行いました。この 20% の負荷の差分に対しても、いくつかの問題へ直面するポイントがありました。 うまくいかなかったこと：コスト見積もり 規模の小さいクラスタは予想通りのコストに概ね収まっていましたが、大きなクラスタになるにつれ、予想していたコストとの乖離が大きくなり、予想コスト超過になりました。 予想コストとの乖離の最も支配的な要因は、自社のトラフィックを模擬したベンチマークにおいて、実トラフィックのうち最も負荷割合の高い、複数の行の同時取得の SELECT ... FROM xxx WHERE id IN (...) という SQL に対するベンチマークシナリオの再現度が低かったため、と推測しています。 この問題が発生した経緯としては、ベンチマークデータに対して、大量の IN 句の要素を妥当な数用意するところに一定の難しさがありました。id は、かなりの数を用意しないと、短期間で id の候補がなくなってしまう一方で、id の払い出しが性能ネックになったりベンチマークに影響を与えても困ります。実装上の都合からこれを簡易化した結果、ベンチマークにおいて、負荷の期待値を実際よりも低く見積もる結果となりました。 一方で分散データベースにおいては、データが複数ノードに分散している状態での取得の再現度は極めて重要であり、これに失敗した結果、実際に多くのコンピュートリソースが必要となりました。 移行後に得られた想定以上の効果 全ての DDL（Data Definition Language）に対する運用上の負荷が大きく下がりました。 以前はオンラインスキーマ変更のツールである gh-ost を利用しており、概ね変更の安定性については満足していたものの、次のような問題がありました。 一部のケースでは gh-ost が使えない 大規模なテーブルの変更は時間がかかる、数週間かかることもある TiDB では、DDL がオンラインで行われることはもちろん、分散データベースにおける分散実行、DXF（TiDB Distributed eXecution Framework）がとても効いており、基本的には全ての DDL が、MySQL に比べて非常に短期間で完了します。具体的には、数週間かかるものが数時間になる、などのケースがいくつか観測されました。 https://docs.pingcap.com/tidb/stable/tidb-distributed-execution-framework/ このように、DDL に対する運用負荷が下がった結果、一部の非常に大規模なテーブルについては、そのテーブルに関わる設計変更を検討した際に、大規模テーブルの定義の変更を見送るような設計をしがちだったのに対し、どちらのテーブル定義であるべきか、というあるべき論に基づき変更が検討しやすくなりました。 この変化により、テーブル設計の修正を含む最適化などがとてもしやすくなりました。 なお、下記の記事のように、稀なケースで TiDB で DDL にとても時間がかかるケースも観測しましたが、最新のバージョンでは改善されております。 https://engineering.mercari.com/blog/entry/20260304-b782487108/ 現在の課題 ここまでで、移行のプロセスでうまくいった点、うまくいかなかった点、移行後に思ったより良かったことについて振り返りました。 最後に、TiDB の移行完了後に対応した、あるいは現在対応している課題についてお知らせします。 分散データベースへの適応 TiDB 切り替え後に、TiDB が分散データベースであることに関連するいくつかの問題への対処を行いました。こちらも追加のブログ記事の公開を予定しております。 コストの問題・安定性の向上 現在のところ、TiDB は全体として非常に安定して稼働しております。 しかし、コスト見積もりが当初予測より上振れたことから、コストの最適化を積極的に行なっております。コストの最適化は、安定性と相反するところであり、最適化を行うことで明らかになる質的な問題を 1 つずつ解消していっております。 ストックアウト問題への対応 クラウドへの移行により、基本的には弾力的なリソース確保ができるようになった一方で、近日のクラウドリソース需要の高まりにより時折発生している、ストック不足のリスクにどのように対応するか、といった検討・検証をしています。 バージョンアップへの対応 TiDB は機能追加や改善の速度が非常に速く、かつ、バージョンアップもオンラインで可能です。 そのため、バージョンアップに迅速に追従し、バージョンアップの恩恵を受けることは TiDB を運用する上では重要です。 一方で、TiDB Cloud では、現状、ダウングレードへのサポートがないため、万が一問題に直面した際に、元のバージョンへ戻せるような仕組みでバージョンアップを行う必要があります。このための手順を確立したり、バージョンアップに対する検証を簡易化するためのツールを開発しています。 TiDB への移行によって多くの課題は解消されましたが、移行完了はゴールではなく、新しい運用フェーズの始まりでもあります。分散データベースやクラウド環境を前提とした運用に適応しながら、コスト、安定性、バージョンアップ対応などを継続的に改善していく必要があります。 まとめ この記事では、メルカリの中核データベースである CoreDB を MySQL から TiDB へ移行した取り組みを振り返りました。TiDB への移行により、当初の目的であった長期的なスケーラビリティの改善、トラフィックの増減に対する弾力的なリソース確保、そしてクラウド化による運用負荷の軽減について、大きな前進がありました。 移行プロセスでは、事前に設計した移行フローが有効に機能し、ProxySQL を活用したトラフィック切り替えの一元管理や、リスクの高いエンドポイントの先行切り替えによって、問題を段階的に発見・解消できました。一方で、実トラフィックを用いた予行演習では多くの学びがあり、トラフィックリプレイの再現性やコスト見積もりには課題も残りました。 移行後には、DDL の運用負荷が想定以上に下がるなど、TiDB の利点も見えてきました。同時に、分散データベースやクラウド環境を前提とした運用では、コスト、安定性、リソース確保、バージョンアップ対応など、継続的に向き合うべきテーマもあります。今回の移行で得た学びを活かしながら、今後も CoreDB の運用をより安定的で持続可能なものに改善していきます。 おしらせ 最後に、現在メルカリでは、この記事の発行者の所属する DBRE チームの EM（Engineering Manager）および IC（individual Contributor）を募集しています。 この記事を読んで興味を持たれた方は、その旨をお知らせください。 詳しくは以下をご覧ください。 EM: https://apply.workable.com/mercari/j/7AD4EF9218/ IC: https://apply.workable.com/mercari/j/ACD2689E9E/

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 いよいよ 8 月、夏本番ですね。連日の暑さに負けず、今週も生成 AI 界隈のアップデートをキャッチアップしていきましょう。 8 月の builders.flash 記事が出ていますので生成AI関連のものをピックアップしてみます。今月も多くの生成AIに関する記事が出ています。 AWS Summit Japan 2026 Builders’ Fair 人気投票第 1 位「ペン字見ます ! ~ AI Agent 先生の辛口査定 ~」の裏側 ! 少量のレガシー言語プログラムを Amazon Quick で解読してみた Amazon Bedrock AgentCore harness と AWS Step Functions を組み合わせて安全に AI エージェントを構築してみよう ! Kiro、1 歳。コードを書く IDE から、仕事を任せるチームへ どの記事も実践的かつ生成AI活用の観点が異なっており参考になりますね。 また新しい AWS Black Belt オンラインセミナー資料・動画 も続々と出ています。生成 AI 関連では「Amazon Bedrock AgentCore Runtime Dive Deep」と「AWS FinOps Agent (preview)」の資料が公開されています。是非チェックしてみてください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 27 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「全従業員の行動変容を目指すAstemo が自己破壊を経て見つけたAI駆動開発の実効性」を公開 Astemo 様は、自動車部品・システムを手がけるグローバルメガサプライヤーです。自動車のソフトウェア定義化 (SDV) が進む中、全従業員の行動変容を目指し、44 名・7 チームが実業務テーマで AI 駆動開発ライフサイクル (AI-DLC) を 3 日間体験しました。人間はレビューと意思決定に集中するスタイルで、3 日間で 9 マイクロサービス / 4,500 行超を開発し、開発スピードは約 200% 向上しています。7 チーム全てがデモ可能なプロトタイプを完成させ、あるチームは翌週に本番リリースまで到達しました。 ブログ記事「Outpost VFX が ビジュアルエフェクト向けに AI モデルのトレーニングを AWS で加速した方法」を公開 Outpost VFX 様は、英国、カナダ、インドにスタジオを構える VFX 制作会社です。フェイスリプレースメント用 AI モデルの学習がシングル GPU の制約で 1〜2 週間かかり、制作のボトルネックになっていました。AWS Generative AI Innovation Center と連携し、Amazon EC2 P5 インスタンスでの分散トレーニングへ移行した結果、学習速度は最大 8 倍に向上しています。初回レビュー用の納品期間も 1〜2 週間から 2 日間へ短縮されました。 ブログ記事「【開催報告】AWS Summit Japan 2026 物流業界向けブース展示「スマートグラス×生成AIエージェントで倉庫業務を革新」」を公開 AWS Summit Japan 2026 の物流業界向けブースで展示した、スマートグラスと生成 AI エージェントによる倉庫ピッキング支援デモの解説記事です。「ピッキングリストをください」と話しかけるだけで、Amazon Nova 2 Sonic が音声のまま理解して WMS から作業リストを取得し、QR スキャンで完了記録まで自動化します。1 会話あたり約 8.9 円というコスト試算まで公開されているのが実践的です。 ブログ記事「【開催報告】AWS Summit Japan 2026 〜 流通小売・消費財・飲食業界向けブース」を公開 「AI エージェントが業務の主役になる日」をテーマにした流通小売・消費財・飲食業界向けブースの開催報告です。バーチャル AI エキスパートから Agentic Commerce まで 6 テーマ 7 デモに加え、株式会社ユナイテッドアローズ様と株式会社カインズ様の事例展示も紹介されています。各デモの詳細解説ブログへのリンク集としても便利です。 ブログ記事「AWS Summit Japan 2026：完全自律型 AI Agent が変える SaaS の世界」を公開 AWS Summit Japan 2026 で展示した、Amazon Bedrock AgentCore を活用したマルチテナント AI CRM デモの解説記事です。メールの分類から回答生成、担当者アサインまでを 6 種類の Agent が協働で処理し、人間は承認のみを行うことで、従来 2 時間かかっていた対応が 5 分以内で完了します。「Agent を取り込む SaaS」設計の 4 つのポイントが整理されており、SaaS 事業者の方におすすめです。 ブログ記事「エージェンティック AI と AWS Transform でメインフレームアプリケーションを再構想 (reimagine) する」を公開 メインフレームのレガシーアプリケーションを、エージェンティック AI でクラウドネイティブに作り変える reimagine パターンの解説記事です。AWS Transform for mainframe が COBOL からビジネスロジックを抽出し、Kiro がマイクロサービス仕様とコードを生成する 3 フェーズの方法論を紹介しています。Human in the Loop の検証を挟み、スピードとリスク低減を両立させる考え方が参考になります。 ブログ記事「Amazon GuardDuty 調査エージェントのご紹介: オンデマンドの AI を活用した脅威評価」を公開 Amazon GuardDuty の調査エージェント (パブリックプレビュー) の紹介記事です。AI がセキュリティ検出結果の調査を自動化し、数時間かかっていた調査を数分に短縮します。リスクレベルや MITRE ATT&CK マッピング、推奨アクションが構造化された形で得られ、AWS MCP サーバー経由で AI ワークフローにも統合できます。 ブログ記事「Security Hub が AI ワークロード保護と Microsoft Azure 対応のマルチクラウドサポートを追加」を公開 AWS Security Hub の 2 つの大きな拡張が発表されました。AI ワークロード保護として、異常なモデル呼び出しやコストハーベスティングを検出する GuardDuty AI Protection、調査を自動化する AI-powered investigations、AI 資産を可視化する Security Hub AI inventory が加わります。マルチクラウド対応では、Microsoft Azure の検出結果を AWS と並べて優先順位付けできるようになりました。 ブログ記事「オープンソースサプライチェーン攻撃の背後にいる北朝鮮のハッカーグループを Amazon が特定」を公開 Amazon Threat Intelligence が、axios、debug、chalk、typo-crypto という人気 NPM パッケージの侵害が同一の北朝鮮関連脅威アクターによるものと初めて特定した調査記事です。生成 AI で悪意のあるパッケージの「見た目の不自然さ」が消えつつあることや、スロップスクワッティングといった新たな脅威も解説されています。OSS に依存する全ての開発者に関係する内容です。 サービスアップデート Amazon Bedrock が OpenAI GPT-5.6 モデルの最大 80% 値下げを発表 Amazon Bedrock 上の OpenAI GPT-5.6 のオンデマンド推論価格が値下げされました。高速・低コストの Luna は 80%、バランス型の Terra は 20% の値下げで、設定変更なしで新価格が自動適用されます (Sol は据え置き)。あわせて Kiro でも GPT-5.6 のクレジット倍率が引き下げ られました (Luna 0.6x → 0.1x、Terra 1.2x → 1.0x)。詳細は こちらのドキュメント をご参照ください。 Grok 4.3 が AWS GovCloud (US-West) の Amazon Bedrock で利用可能に xAI の Grok 4.3 が AWS GovCloud (US-West) の Amazon Bedrock で利用可能になりました。GovCloud への xAI モデルの提供は今回が初めてです。推論の深さを 4 段階で設定でき、ツール利用と指示追従、トークン効率に強みがあります。 Gemma 4 モデルが AWS GovCloud (US-West) の Amazon Bedrock で利用可能に Google DeepMind のオープンウェイトモデル Gemma 4 ファミリーが AWS GovCloud (US-West) の Amazon Bedrock で利用可能になりました。256K トークンコンテキストの 31B、コスト重視の MoE 構成 26B-A4B、低遅延の E2B の 3 バリアント構成です。35 以上の言語と、テキスト・画像・動画・音声のマルチモーダル入力に対応します。 Amazon SageMaker Unified Studio が全プロジェクトツールで Git バージョン管理を強化 Amazon SageMaker Unified Studio の全プロジェクトツール (Query Editor、Visual ETL、Workflows、Notebooks) で、ファイルレベルの Git バージョン管理が利用できるようになりました。これまで Git 非対応だった Notebooks も対象になり、ブランチ作成や競合解決までプロジェクト内で完結します。詳細は こちらのドキュメント をご参照ください。 Amazon OpenSearch Service が OpenSearch 3.7 をサポート Amazon OpenSearch Service で OpenSearch 3.7 が利用可能になりました。1-bit スカラー量子化により、検索精度を維持しながらベクトルワークロードのストレージとメモリ使用量を削減できます。RAG の検索基盤のコストとパフォーマンスに効くアップデートです。詳細は こちらのドキュメント をご参照ください。 AWS Security Hub MCP App がプレビュー公開 Security Hub のエクスポージャー検出結果を Claude Desktop から直接扱える、ローカル実行の MCP サーバーがプレビューになりました。自然言語で上位のエクスポージャーを確認し、攻撃パスの掘り下げから修復の推奨事項まで得られます。全ツールが読み取り専用のため、環境に変更が加わる心配なく試せます。詳細は こちらのドキュメント をご参照ください。 Kiro CLI 2.16.0 / 2.15.0 と IDE 1.0.242 が公開 Kiro CLI 2.16.0 では、会話履歴を引き継いだままサイド会話に分岐できる /tangent コマンドと、/context のツール別トークン内訳表示が追加されました。CLI 2.15.0 では /spec new のガイド付きステップと、Plan モードでの承認後の自動実行が入っています。IDE 1.0.242 では、右クリックメニューの Kiro サブメニューや、エラーに対する「Ask Kiro to Fix」クイックフィックスが加わりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。