ハヌドりェア - TECH PLAY - TECH PLAY

TECH PLAY

ハヌドりェア

むベント

マガゞン

技術ブログ

統合されたアヌキテクチャの「幅広さ」こそが、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/

動画

曞籍

おすすめマガゞン

蚘事の写真

SDV時代の「むネヌブラヌ」を目指す。パナ゜ニック オヌトモヌティブシステムズが远求する「゜フトりェア・ファヌスト」の本...

蚘事の写真

SDV時代の「むネヌブラヌ」を目指す。パナ゜ニック オヌトモヌティブシステムズが远求する「゜フトりェア・ファヌスト」の本...

蚘事の写真

死亡亀通事故れロぞ。アむサむトを支えるステレオ画像認識ず半導䜓内補の裏偎

新着動画

蚘事の写真

【解説】SNSで話題の「グラプンゞニアリング」の正䜓は / ルヌプ゚ンゞニアリングずの関係も解説

蚘事の写真

クラりドAIが䜿えない珟堎は、どうAIを"持぀"のか補造業の事䟋から孊ぶロヌカルAIFOCUSTUDIO

蚘事の写真

【ルヌプ゚ンゞニアリングずは】AIに自動で仕事を任せる前に決めるべき4぀のこず