統合されたアーキテクチャの「幅広さ」こそが、AI エージェントの能力を左右する ── その理由。 はじめに エージェンティックな統合（agentic integration）による自律的な問題解決が、コンタクトセンターの運用のあり方を再定義しつつあります。AI の推論能力の進化、オープンな統合標準、そしてコンポーザブル（組み合わせ可能）なサービス設計が一つに収束したことで、これまで実現不可能だったことが実用的なものになりました。 すなわち、複数システムにまたがる複雑なお客様の課題を、AI エージェントがリアルタイムに自律的に解決できるようになったのです。 Model Context Protocol（MCP）を通じて接続された Amazon Connect Customer と Salesforce は、この変化の最先端を象徴しています。 エージェンティックな統合は、これを実現するためのアーキテクチャの考え方です。あらかじめすべての判断パターンをコンタクトフローに作り込んでおくのではなく、大規模言語モデル（LLM）を基盤とするオーケストレーター AI エージェントが、「どのシステムを、どの順番で呼び出すか」をその場で判断し、処理の途中で得られた結果を見ながら進め方を柔軟に見直していきます。AI エージェントはお客様の意図をくみ取り、Salesforce のようなシステムオブレコード（顧客情報などを蓄積する中核システム）、運用系のサービス、ナレッジベースにまたがる一連の処理をつなぎ合わせ、複雑な課題を最初から最後まで一貫して解決します。 本記事では、Amazon Connect Customer（システムオブエンゲージメント：お客様との対話を担う中核）と Salesforce（システムオブレコード）を例に、エージェンティックな統合の設計原則、プロトコル層、そしてそれが持つ戦略的な意味を見ていきます。まず、自律的に課題を解決する仕組みである推論ループを紹介し、続いて「乗数効果（multiplier effect）」によって、つなぐシステムの幅広さがなぜ AI の力を何倍にも高めるのかをひもときます。最後に、複数システムを自由に組み合わせて動かす仕組みをエンタープライズ規模で実用化するオープン標準として、Model Context Protocol を紹介します。 構造的制約から、AI エージェント主導のオーケストレーションへ 図: フロー主導の API 統合から、AI エージェント主導のオーケストレーションへのアーキテクチャの転換。左側は、Amazon Connect Customer とバックエンドシステムの間でハードコードされた API 呼び出しを行う直線的なフロー。右側は、中心に位置する AI エージェントが MCP を通じて複数システムを動的にオーケストレーションする様子。 何十年もの間、企業のシステム統合は「システム同士をつなぐことは、機械的な単純作業にすぎない」という一つの思い込みのもとで進められてきました。コンタクトセンターは、この考え方が最もはっきりと表れてきた領域です。IVR（自動音声応答）のメニューは、あらかじめ決められた分岐に沿ってお客様をルーティングし、API は決まった順番で呼び出され、それまでのやり取りの文脈は、担当や処理が切り替わるたびに捨てられてしまいます。 システムオブレコードとしての Salesforce は、お客様に関する完全なストーリー（対話履歴、サービスの嗜好、ロイヤルティ会員ランク、未解決のケース）を保持しています。システムオブエンゲージメントとしての Amazon Connect Customer は、リアルタイムの会話を担います。しかしながら、両者をつなぐ統合層の多くは依然としてトランザクション的なものにとどまっています。定型的な API 呼び出し、静的なデータ参照、そして情報を表示することはできても、その情報について推論したり、それに基づいてインテリジェントに行動したりはできない従来型のコネクタです。 こうしたやり方がもたらす弊害は小さくありません。新しいバックエンドシステムを一つ導入するだけでも、統合を一から作り直す必要があります。ワークフローを少し変えるにも、数か月の開発を要します。その結果、お客様に提供される体験（カスタマーエクスペリエンス）は、断片的でぎこちないものになってしまいます。課題を解決するために必要なデータが、すでに社内の各システムにそろっているにもかかわらず、です。 エージェンティックな統合は、複雑な問題解決のロジックを、あらかじめコード化された判断経路から、動的で AI エージェント主導のオーケストレーションへと移行させます。 Amazon Connect Customer は、AI エージェントをお客様との対話におけるアーキテクチャの中心に、すなわち主たる推論エンジンとして配置します。この AI エージェントは計画を立案し、結果を評価し、到達可能なあらゆるシステムをまたいでオーケストレーションを行います。そこには、以下のようなアーキテクチャ上の違いがあります フロー主導の統合は決定論的（deterministic）です。 各 API 呼び出しはあらかじめコード化されています。あらかじめ定められた経路(主たる経路)が失敗すると、システムは処理を終了するか、エスカレーションします。コンテキストはステップごとにリセットされます。 AI エージェント主導のオーケストレーションは適応的（adaptive）です。 AI エージェントは意図を評価し、ツールを選択し、アクションを動的に連鎖させます。最初のアプローチが失敗しても、お客様に中断を感じさせることなく、代替手段を推論します。Salesforce、予約システム、ナレッジベース──これらはすべて、単一の会話コンテキストの中でコンポーザブルなツールとなります。 従来の API ベースの統合が時代遅れになったわけではありません。推論が不要で、入出力が固定的な高頻度の処理においては、依然として正しい選択肢です。しかし、複雑で文脈に依存するお客様との対話においては、エージェンティックなオーケストレーションが、その土台となる考え方そのものを塗り替えます。すなわち、「インフラ（基盤）としての統合」から「インテリジェンス（知性）としての統合」へ、という転換です。 推論のアーキテクチャ：理解・推論・実行・記憶 図: エージェンティックな推論ループ。相互に接続された 4 つの段階を示す：Understand（理解：意図の解析とコンテキストの読み込み）、Reason（推論：ゴールの分解とツールの選択）、Act（実行：MCP のツール呼び出しの実行と結果の評価）、Remember（記憶：状態の維持とパターンの保持）。矢印は、1 回の会話ターンの中で継続的に反復が行われることを示す。 Amazon Connect Customer の AI エージェントを従来の自動化と分けるのは、その推論アーキテクチャです。それは、あらゆる会話のターンの中で反復的に実行される、相互に依存し合う 4 つの機能から成る連続的なループです。 Understand（理解） ── お客様の発話を解析し、意図（インテント）を特定し、エンティティを抽出したうえで、Salesforce のケース履歴、顧客プロファイルの属性、過去の対話記録を含む会話コンテキスト全体を読み込みます。 Reason（推論） ── リクエストをサブゴールに分解し、どのツールが必要かを見極め、実行する順序を決め、どのツールの結果が別のツールの前提になるか（依存関係）を特定します。 Act（実行） ── バックエンドシステムに対して MCP のツール呼び出しを実行します。各アクションは構造化された結果を返し、AI エージェントはその結果について推論したうえで次のアクションを決定します。実行は「投げっぱなし（fire-and-forget）」ではなく、「評価しながら適応する（evaluate-and-adapt）」方式です。 Remember（記憶） ── 会話の状態を完全に維持し、セッションのコンテキストを保持し、問題解決のパターンを記憶します。 ここで一番大切なのは、このループが「逐次的（sequential）」ではなく「連続的（continuous）」である、という点です。1 回のターンの中で、AI エージェントは「推論・実行・推論・実行」を何度も繰り返すことがあります。Salesforce に問い合わせ、空き状況を確認し、ケースを作成し、レコードを更新し、確認通知を送信する ── これらすべてを、AI エージェントが一貫して指揮する、ひと続きの流れとして実行します。 相乗の原則：統合の乗数効果 図: 乗数効果──システムを 1 つ追加するごとに問題解決力が高まる。段階的な能力の向上を示す積み上げ図：1 システムで「情報提供」、2 システムで「パーソナライズ」、3 システムで「自律的なアクション」、4 システム以上で「ドメインをまたいだエンドツーエンドの問題解決」が可能になる。 エージェンティックなシステムを特徴づけるアーキテクチャ上のインサイトは、次のとおりです。すなわち、あらゆる AI エージェントの自律的な問題解決能力は、その AI エージェントがオーケストレーションできるシステムの「幅広さ」によって大きく決まる、ということです。 これが「乗数効果」です。統合するシステムが 1 つ増えることは、単に機能が 1 つ増えるだけにとどまりません。それは、これまでアーキテクチャ上できなかった「組み合わせによる新たな可能性」を生み出します。システムが 1 つなら、AI エージェントが使えるツールも 1 つだけです。しかしシステムが 3 つになれば、そのときどきの状況（リアルタイムのコンテキスト）に応じて、必要なツールを好きな順番で、条件に合わせて組み合わせながら次々に呼び出せます。こうしてできるアクションの組み合わせのパターンは、システムを 1 つ繋ぐごとに大きく増えていきます。 これは、最もシンプルな形で表れた「相乗的に高まる能力（compounding capability）」です。接続するシステムはどれもが、すでに接続されているすべてのシステムの問題解決力を掛け算のように増幅させます。航空便の運航トラブルのシナリオを考えてみましょう。 システムなし（ゼロ） : 「お客様の便は欠航となりました。当社ウェブサイトをご確認ください。」 1 システム（ナレッジベース） : 「お客様は 72 時間以内の再予約が可能です。」 2 システム（+ Salesforce CRM） : 「ゴールド会員のお客様ですので、再予約は無料で、優先搭乗もご利用いただけます。」 3 システム（+ 予約システム） : 「14:00 発の SL-404 便、座席 12A に再予約いたしました。確認通知をお送りしました。」 4 システム以上（+ 地上交通手配） : 「18:00 にマンハッタンでのお打ち合わせがございますね。ニューアーク空港着の便を予約し、お荷物の経路を変更し、お打ち合わせ先までのお車を手配いたしました。」 「アドバイザー（助言者）」から「自律型 AI エージェント」への進化は、統合アーキテクチャと、それが生み出す乗数効果によって決まります。それぞれの層が、他の層の価値を掛け算のように高めていきます。 プロトコル層：Model Context Protocol 図: MCP のランタイムシーケンス──単一のツール呼び出しが、AI エージェントから AgentCore Gateway を経由して Salesforce へと流れ、再び戻ってくる。認証とプロトコル変換は、意識させることなく（透過的に）処理される。 組み合わせ自在なエージェンティック統合を、実際に使えるものにするアーキテクチャ上の構成要素が、Model Context Protocol（MCP）です。MCP は、誰でも自由に使える共通の仕様（オープン標準）で、AI エージェントが外部システムのさまざまな機能を見つけ出し、接続し、呼び出すための統一されたインターフェースを定めています。 MCP は、個別に作り込む統合（bespoke integration）を、たった一つの原則に置き換えます。すなわち、「コネクタは一度作れば、MCP に対応したどの AI エージェントも、それをすぐに見つけて呼び出せる」という原則です。AI エージェントは MCP サーバーに問い合わせて、そのサーバーが提供する機能の一覧（利用できるツール、必要な入力の形式、返ってくる出力の形）を受け取り、必要に応じてそれらを呼び出します。多くの実装では、これによって AI エージェントとバックエンドシステムをつなぐための専用コードや、個別に埋め込んだ接続設定が不要になります。 例えるなら、MCP は、対応するどの AI エージェントも、対応するどのシステムにも、標準化されたインターフェースを通じて接続できる汎用プロトコルを提供します。これは、ハードウェアの世界における汎用コネクタによく似ています。 リファレンスアーキテクチャ：エージェンティックなオーケストレーション 図: 全体アーキテクチャの概要。中心に Amazon Connect Customer と AI エージェント（オーケストレーター）を配置。上方向には LLM による推論のために Amazon Bedrock、外側には AgentCore Gateway を経由して外部の MCP サーバー（Salesforce ほか）に接続。左側には内部ツール（ナレッジベース、フローモジュール、Note Taker）、そして Amazon CloudWatch がすべての層にわたってオブザーバビリティ（可観測性）を提供する。 エージェンティックな統合をエンタープライズ規模で実現するには、以下のアーキテクチャ構成要素が必要であり、これらはすべて AWS クラウド内で動作します。図は、これらの構成要素が統一されたオーケストレーションアーキテクチャの中でどのように連携するかを示しています。 Amazon Connect Customer (システムオブエンゲージメント) ── 音声・チャット・メッセージングにまたがってお客様との対話を担う、会話型 AI サービスです。AI エージェントを支える以下の機能を提供します。ルーティングとチャネル管理を担うコンタクトフロー、本人確認とコンテキストのための Amazon Connect Customer Profiles、段階的な問題解決手順を導く Step-by-step Guides、そして対話からのインサイトを得るための 会話分析(Conversational Analytics) です。 AI Agent with Guardrails(ガードレール付きの AI エージェント)  ── オーケストレーターであり推論エンジンでもあるこのエージェントは、Amazon Connect Customer の中心に位置し、安全性・コンプライアンス・ポリシーの境界を守らせるガードレールに囲まれています。エージェントは「理解・推論・実行・記憶」のサイクルを継続的に回し、お客様の課題を自律的に解決します。 Internal Tools(内部ツール) ── AI エージェントが直接呼び出す、Amazon Connect Customer ネイティブのツール群です。これには、Retrieval Augmented Generation（RAG）を用いてポリシーや製品情報を検索するナレッジベース、あらかじめ定義したアクションを起動する フローモジュール、そして対話の要約を生成する Note Taker が含まれます。 Amazon Bedrock （基盤モデル） ── AI エージェントを支える推論エンジンであり、Amazon Connect Customer の外部、ただし AWS クラウド内に位置します。意図の理解、計画立案、応答生成を駆動する LLM 機能を提供します。 Amazon Bedrock AgentCore Gateway ── AI エージェントのツール呼び出しを外部の MCP サーバーへとルーティングする、セキュアな接続レイヤーです。OAuth 2.0 による認証、ポリシーの適用、プロトコル変換を担います。これにより、AI エージェントは個別に作り込む統合なしに、あらゆる MCP 準拠システムへ到達できます。 External MCP Servers(外部 MCP サーバー) ── 主たるシステムオブレコードとの接続を担う Salesforce MCP サーバー（ケースの作成、顧客情報の照会、レコードの更新）に加え、他の外部システム向けに任意の数の MCP サーバーを追加できます。AI エージェントはすべての MCP サーバーを同一に扱います。すなわち、発見可能で、呼び出し可能で、コンポーザブルなものとして扱います。 Amazon CloudWatch (オブザーバビリティ) ── すべての層（Amazon Connect Customer、Amazon Bedrock、AgentCore Gateway）にわたってロギング、メトリクス、モニタリングを提供し、エージェンティックなシステムの運用状況を可視化します。各構成要素は、MCP のプロトコル境界によって疎結合となっており、それぞれ独立して進化していきます。 収束点：Amazon Connect Customer と Salesforce の MCP 連携 業界はいま、それぞれ独立して成熟してきた 3 つの能力が一つに合わさろうとしている、まさにその局面にあります。すなわち、連続的に推論し続ける仕組みを備えた AI エージェント、あらゆるシステムを自由に組み合わせられるようにするオープンプロトコル（MCP）、そして AI エージェントを対話の設計上の中心に置くサービス群です。 MCP を通じた Amazon Connect Customer と Salesforce の連携は、この収束をいち早く形にした実装例です。システムオブエンゲージメントが、標準化され組み合わせ自在なプロトコル層を通じて、システムオブレコードに接続します。 動作の仕組み Salesforce は、ホスト型の MCP サーバーを通じて自らの機能を公開します。これは、MCP プロトコルを Salesforce ネイティブの操作へと変換する、ベンダー（Salesforce）自身が構築したインターフェースです。Amazon Connect Customer の AI エージェントは、OAuth 2.0 による認証とアクセスポリシーの適用を担う Amazon Bedrock AgentCore Gateway を通じて接続します。 実行時（ランタイム）には、AI エージェントが MCP のツール呼び出しを発行します。AgentCore が OAuth で認証を行い、リクエストを転送します。Salesforce MCP サーバーはそれを適切な Salesforce API 操作へと変換します。構造化された結果は同じ経路をたどって返され、AI エージェントはその結果について推論したうえで、次のアクションを決定します。 AI エージェントにできること Salesforce MCP サーバーを通じて、AI エージェントは Salesforce の各種操作をコンポーザブルなツールとして利用できるようになります。エージェントは、本人確認やコンテキスト把握のために、Contact（取引先責任者）・Account（取引先）・カスタムオブジェクトを照会し、顧客履歴・嗜好・利用権限（entitlements）を取得できます。会話の流れの中でケースを作成・更新・エスカレーション・クローズし、ケースのライフサイクル全体を管理します。また、公開されている任意の Salesforce オブジェクトに対して、リアルタイムで読み取り・作成・更新・照会といったレコード操作を実行します。さらに、対話の要約、解決に関するメモ、フォローアップタスクを Salesforce に書き戻すことで、アクティビティのログ記録も行います。 なぜこれがアーキテクチャ上において重要なのか Runtime discovery(ランタイムでの発見) ── AI エージェントは Salesforce の機能を実行時に発見します。Salesforce が MCP サーバーに新しいツールを追加した際も、オーケストレーション層のコードを変更することなく、AI エージェントはそれらを利用できます。 Bidirectional context flow(双方向のコンテキストフロー) ── AI エージェントは推論に役立てるために Salesforce から情報を読み取り、実行したアクションを記録するために書き戻します。システムオブレコードは、手作業でのデータ入力なしに、常に最新の状態に保たれます。 Composable with other systems(他システムとのコンポーザビリティ) ── 同じ MCP のパターンは、準拠したあらゆるシステムへと拡張できます。AI エージェントは、Salesforce、予約システム、内部ツールを、まったく同一の仕組みでオーケストレーションします。 Decoupled evolution(疎結合な進化) ── Salesforce の組織側の変更は MCP サーバーに反映され、AI エージェント、コンタクトフロー、ゲートウェイの設定を変更する必要はありません。 MCP を通じて連携する Amazon Connect Customer と Salesforce は、一つの成果を生み出します。すなわち、システムオブレコードの持つ情報の深さを余すことなく活用しながら、お客様の課題をエンドツーエンドで自律的に解決するシステムオブエンゲージメントです。 統合はもはや単なるインフラではありません。それは、AI エージェントが「アドバイザー」として機能するのか、それとも「自律的な問題解決エンジン」として機能するのかを決定づける、戦力を倍増させる要因（フォースマルチプライヤー）なのです。 インパクトのモデル：ビジネス、体験、そして戦略的な意味合い ビジネスへのインパクト システムオブエンゲージメントが、システムオブレコードをまたいでリアルタイムに、自律的なオーケストレーションを行うようになると、カスタマーサービスにかかるコスト構造そのものが変わります。従来は何度も転送を重ね、オペレーターが数分がかりで対応していた複雑で多段階のリクエストも、自動化されたオーケストレーションによってより速く解決できるようになります。転送や折り返し（コールバック）なしに、システムをまたいで必要な処理を次々につなげて実行できるため、1次解決率（FCR）が高まります。人へのエスカレーションは、本当に人の判断が必要なケースだけに絞り込まれていきます。 カスタマーエクスペリエンスへのインパクト お客様は、ストレスや手間が仕組みとして取り除かれていることを実感します。転送されることもなく、本人確認を何度も求められることもなく、保留で待たされることもありません。AI エージェントが顧客記録のすべてを活用するため、あらゆる対応がその文脈に合わせてパーソナライズされます。これは、その場限りの「取引的（トランザクショナル）」な関係から、継続的な「関係性重視（リレーショナル）」な関係への転換です。 リーダーにとっての戦略的な意味合い この領域における差別化要因は、コモディティ化しつつあるモデルそのものの能力ではありません。それは、統合アーキテクチャの「広さ」と「コンポーザビリティ（組み合わせやすさ）」です。統合の広さこそが、AI 戦略における重要な差別化要因なのです。 リーダーは、フロー（flows）ではなくオーケストレーションを前提とした設計を行うべきです。重要なのは、発見可能で、呼び出し可能で、コンポーザブルなシステムを構築することです。着目すべき指標も変わります。すなわち、（有人対応をどれだけ回避できたかを示す）ディフレクション率を測るのではなく、AI エージェントがどれだけ多くの複雑な課題を、エンドツーエンドで自律的に解決したかを測るべきです。 顧客関係管理（CRM）は、最初に統合すべき自然な対象です。その基盤を起点に、外へと広げていきます。新たな接続はどれもが、それ以前の接続を相乗的に高めていきます。Amazon Connect Customer が AI オーケストレーション層として自然な選択肢となるのは、それがリアルタイムの顧客との関係を担い、推論エンジンをネイティブに組み込み、AgentCore Gateway を通じた MCP によってあらゆるシステムに接続できるからです。 はじめよう：エージェンティック統合ワークショップ 本記事で解説したアーキテクチャを実装いただけるよう、参加者がエンドツーエンドのエージェンティックな問題解決システムを構成・接続・テストするハンズオン形式の「Agentic Integration Workshop（エージェンティック統合ワークショップ）」をご用意しています。 Agentic Integration Workshop 注意：本ワークショップにはクリーンアップ（後片付け）の手順が含まれています。プロビジョニングしたリソースを削除し、継続的な課金を避けるために、クリーンアップの手順に従ってください。 まとめ 本記事では、エージェンティックな統合のアーキテクチャ原則、推論ループ、そして Amazon Connect Customer と Salesforce が MCP を通じてどのように接続されるのかを考察しました。乗数効果が示すのは、AI エージェントに接続されるシステムが 1 つ増えるごとに、アーキテクチャ全体の問題解決能力が相乗的に高まるということです。これにより、統合は運用上のインフラから、戦略的なインテリジェンスへと変貌を遂げます。 本記事は、Amazon Connect Customer、Salesforce の MCP サーバー、Amazon Bedrock、そして Model Context Protocol を用いた、エージェンティックな統合のアーキテクチャパターンと戦略的な意味合いを考察したものとなっています。 著者について Chintan Gandhi は、AWS の Amazon Connect Customer Integrations における Applied AI Leader です。お客様がエージェンティックなシステムを導入し、スケールさせることを支援しています。仕事以外では、家族と過ごす時間、チェスやクリケット、読書を楽しんでおり、ときにはアマチュア小説の執筆もしています。 この記事は Chintan Gandhi によって書かれた Integration as Intelligence: Amazon Connect Customer Integrates with Salesforce via MCP の日本語訳です。この記事はソリューションアーキテクトの梅田裕義が翻訳しました。

本ブログは dSPACE Japan 様と アマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 1. はじめに 自動車分野で行われている自動運転技術の開発では、データ駆動型アプローチの重要度が高まっています。膨大な実走行データを体系的に整備・活用することで多様な運転環境への対応が可能になり、モデルの汎化性能と信頼性を継続的に向上させることができます。 しかし、自動運転システムが生成するデータ量は膨大であり、その管理と活用には大きな課題が伴います。データ収集から学習、検証、デプロイ、モニタリングまでを統合管理する「MLOps」の導入が不可欠です。 本記事では、30 年以上にわたり車両開発ツールを提供してきた dSPACE 社の製品と、AWS クラウドサービスを統合した MLOps ソリューションをご紹介します。 2. 自動運転開発における課題 自動運転技術の進展に伴い、AI を活用した認識・判断アルゴリズムの高度化が急速に進んでいます。一方で、実際の車両開発・量産適用を見据えると、単なるモデル精度の向上だけでは解決できない、複合的な課題に直面されているのではないでしょうか。 膨大かつ多様なセンサーデータの管理と活用 先進的な自動運転システムでは、1 時間あたり 1 テラバイトを超えるカメラデータに加え、LiDAR、Radar、GPS など多種多様なセンサーデータが生成されます。これらのデータは地理的にも分散して収集されることが多く、効率的な保存・検索、シナリオや条件に基づくデータ抽出、開発・検証フェーズ間での一貫したデータ利用を実現することが大きな課題となっています。 学習精度と車両環境での挙動の乖離 クラウド環境で学習した AI モデルが高い認識精度を示していても、リアルタイム実行制約、センサー同期誤差やノイズ、車載ハードウェア上での実行条件といった要因により、実車両環境では期待通りに動作しないケースが少なくありません。このため、学習結果をそのまま車両に適用するのではなく、車両環境を考慮した検証・評価プロセスを MLOps と連携させることが不可欠となります。 検証と学習の分断による改善サイクルの停滞 自動運転の安全性は、まれなエッジケースや特定シナリオへの対応によって大きく左右されます。しかし多くの開発現場では、クラウドを中心とした AI 開発・MLOps チームと、SIL (Software-in-the-Loop)／HIL (Hardware-in-the-Loop)／実車評価を担う車両開発チームが、異なるツールやプロセスで作業しています。この分断により、どのシナリオで性能低下が発生したのか、その原因となるデータをどのように再学習へ反映させるのかといった情報がチーム間で共有されず、検証結果を効率的に再学習へフィードバックする仕組みが整っていないケースが多く見られます。検証結果と学習データを結び付け、継続的な改善サイクルを回すことが大きな課題です。 再現性・説明責任の確保と検証コストの増大 自動運転 AI の開発では、使用したデータ、学習条件、モデル構成、検証環境を後から正確に説明・再現できることが求められます。しかし、実験管理、検証条件、車両構成情報が個別に管理されることで、結果の再現性やトレーサビリティの確保が困難になり、社内レビューや将来的な認証・法規対応を見据えた際に重大なリスクとなります。さらに、データ駆動型開発ではモデル更新が頻繁に行われるため、そのたびに同等レベルの検証を実施することは大きな負担となります。すべてを再検証するのではなく、モデル変更の影響範囲を見極め、効率的に検証を行う仕組みが必要とされています。 これらの課題を解決するためには、クラウド MLOps のスケーラビリティと、車両開発・検証を熟知したツールチェーンを統合し、データ収集から学習、検証、デプロイ、モニタリングまでを一貫して管理できる基盤が求められます。次章では、こうした課題に対応する dSPACE と AWS による統合 MLOps ソリューションについて詳しく説明します。 3. ソリューション： dSPACE と AWS による自動運転向け統合 MLOps アーキテクチャ 自動運転 AI 開発における効率化を実現するため、dSPACE と AWS はそれぞれの強みを活かし、AI モデルの学習から SIL/HIL での検証、さらに実運用を見据えた評価・改善までをつなぐ統合 MLOps 環境を共同で提供します。本ソリューションでは、データ駆動開発（DDD）で扱うデータ収集・整備・検証の流れ（左側）と、MLOps で扱う学習・追跡・デプロイの流れ（右側）を接続します。これにより、学習と検証が分断されがちな自動運転 AI 開発において、改善サイクルを一貫したパイプラインとして回すことを目指します。 本アーキテクチャの特徴は、dSPACE 製品と AWS サービスがシームレスに連携できる点にあります。 図1: AWS サービスと dSPACE 製品の統合アーキテクチャ Data Collection：後工程で“使える形”を前提にしたデータ収集 本パイプラインの起点は、走行試験、評価ベンチ、シミュレーションなど多様なソースから得られるデータの収集です。自動運転開発ではデータ量の多さだけでなく、どの条件・どのシナリオで取得されたかが重要となるため、後工程での検索・抽出・学習・検証に耐えうる形で蓄積することが求められます。 この Data Collection フェーズでは、 RTMaps を活用することで、カメラ、Radar、LiDAR など複数センサのデータをリアルタイムに扱いながら、システム全体としての振る舞いを意識したデータ取得が可能となります。さらに、RTMaps を用いたデータ収集は、後続の検証や SIL/HIL を含むシステム統合試験でも同一の処理構成を再利用できるため、データ取得と検証の分断を抑えたパイプライン設計につながります。こうして収集されたデータは、次の Data Preparation フェーズにおいて IVS に引き渡され、タグ付けや検索、データセット化といった処理へとスムーズに接続されます。 Data Preparation：IVS によるデータマネジメントとデータセット管理 収集したデータは、学習にそのまま利用できるとは限りません。Data Preparation フェーズでは、 dSPACE IVS (Intempora Validation Suite) を用いて、データの自動タグ付け、検索、変換を行い、学習に適したデータセットとして整理します。 重要なのは、単にデータを整えるだけでなく、どの条件で抽出・加工されたデータセットなのかを後から辿れることです。本パイプラインでは、IVS を介してデータセット定義と証跡（トレーサビリティ）を管理し、以降の学習・検証フェーズと一貫して結び付けます。 Training：AWS を活用した学習の自動化と実験・モデル管理 整備されたデータセットは、AWS のクラウドサービスへシームレスに受け渡され、大規模な学習処理が実行されます。本構成では、 Amazon SageMaker AI を中心とした学習基盤を活用し、必要な計算リソースを柔軟に利用することで、効率的なモデル学習を実現します。 SageMaker Training Jobs は、学習ジョブごとに GPU インスタンスを自動的にプロビジョニングするため、高価な GPU リソースを学習実行時のみ使用でき、コスト効率に優れています。また、学習コードをコンテナイメージとして Amazon ECR に格納し、学習データを Amazon S3 に配置するアーキテクチャにより、「コード・データ・環境」の三要素が分離され、実験の再現性が担保されます。さらに、実験管理には SageMaker AI のマネージド MLflow を用い、学習条件、評価指標、生成されたモデルを一元的に管理します。これにより、モデルの品質担保に必要な履歴情報を体系的に蓄積し、後工程の検証や将来の説明責任に対応します。 Validation / System Integration & Testing（SIL/HIL）：学習成果を車両開発レベルで検証し、信頼性を高める 学習によって得られた AI モデルは、SIL や HIL を活用して、自動運転システムとしての機能検証や統合試験へと進みます。 dSPACE の SIL/HIL ソリューション は、制御ソフトウェアや AI モデルを実車に近い条件で段階的に評価できる点が特長です。SIL では、アルゴリズムやソフトウェアの論理的な正しさや機能挙動を早期に確認でき、モデル更新による影響を効率的に洗い出すことができます。さらに HIL では、実際の ECU (Electronic Control Unit) として AI モデルを接続することで、リアルタイム性やインタフェース、システム全体としての振る舞いを含めた検証が可能となります。 検証フェーズで得られた結果は、データ条件やモデル情報とひも付けて管理され、Data Preparation フェーズへフィードバックされます。これにより、SIL/HIL で顕在化した課題を起点に学習データセットを見直し、再学習へつなげるといった、検証起点の改善サイクルを回すことが可能となります。結果として、モデル開発と車両開発・検証を分断することなく、品質向上と開発効率化の両立を支援します。 4. 開発環境「Kiro」を活用した開発効率化 MLOps 開発プロセスをさらに効率化するためには、AWS が提供する開発環境「 Kiro 」を利用することが考えられます。 Kiro は Spec 駆動開発を特徴とし、要件定義・設計・実装タスクを構造化されたドキュメントとして管理しながら、エージェント機能によるコード生成を行うことで、開発者が本質的なアルゴリズム設計に集中できる環境を提供します (図 2 参照)。 図 2: Kiro による MLOps 開発ワークフローの効率化 ここでは、MLOps 開発において Kiro がどのように活用できるか、いくつかの例をご紹介します。 ハイパーパラメータ最適化スクリプトの生成 エージェント機能に最適化要件を伝えることで、2 フェーズアプローチの最適化スクリプトを生成できます。Phase 1 (粗探索) でパラメータ範囲を広く設定し、ランダムに 20 組をサンプリングして並列・短時間で完了させ、Phase 2 (細探索) で Phase 1 の結果を基に最良パラメータ周辺を詳細に探索するといった、重要なパラメータを体系的に調整するスクリプトの生成が可能です。 学習データ品質チェックの自動化 学習データの品質チェックスクリプトの生成にも活用できます。データセット構造チェックでは必要なディレクトリ構成や設定ファイルを検証し、PIL (Python Imaging Library) を使った画像破損チェック、YOLO フォーマットのラベル形式検証、画像-ラベル対応関係チェックにより、不整合を検出します。破損画像や不正確なアノテーションを学習前に自動検出することで、無駄な学習実行を防止できます。 このほか、train.py や Dockerfile などのボイラープレートコード生成、SageMaker ジョブ投入スクリプトの雛形作成など、MLOps 開発における定型的な作業にも Kiro を活用することで、開発者が本質的なアルゴリズム設計に集中でき、開発サイクルの短縮が期待できます。 5. まとめ 本記事では、自動運転 AI 開発における課題と、dSPACE と AWS による統合 MLOps ソリューションをご紹介しました。RTMaps と IVS によるデータ収集・整備から、Amazon SageMaker AI と MLflow を活用した学習・実験管理、さらに SIL/HIL による車両レベルでの検証までを一貫したパイプラインとして接続することで、学習と検証の分断を解消し、検証起点の改善サイクルを回すことが可能となります。加えて、開発環境「Kiro」を活用することで、ハイパーパラメータ最適化やデータ品質チェックといった定型作業を自動化し、エンジニアが本質的なアルゴリズム設計に集中できる環境を実現します。 自動運転 AI 開発の効率化や継続的改善を検討されている方にとって、本記事がソリューション選定の一助となれば幸いです。ご質問やご相談は、dSPACE および AWS の担当者までお気軽にお問い合わせください。 著者について 丹羽 伸二 AWS Japan のシニアソリューションアーキテクトとして自動車業界のお客様を担当。自動車業界で15年以上の経験を持ち、主にプロダクトエンジニアリング領域におけるモダナイゼーションや AI 活用の取り組みを支援しています。 村山 哲也 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループリーダー。データドリブン開発や開発環境のプラットフォーム化などのクラウド系ソリューション、および自動車開発に関わる AI 活用に関するプロトタイピング活動とエンジニアリングをリードしています。 宮本 敬丈 dSPACE Japan 株式会社 CX 技術部 Business Prototyping グループ AI チームリーダー。データサイエンティストとして、製造業、自動車領域における AI 活用、MLOps 基盤構築、エンジニアリングプロセスの自動化に従事。AWSを含むクラウドアーキテクチャの構想や生成 AI、RAG、MCP を活用した業務高度化に取り組んでいます。  

概要 メルカリでは、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/