課題・問題
企業成長に伴うデータ量の増加により、夜間の全件転送が限界に
まずは、「TROCCO」のCDC機能の導入前に抱えていたビジネス上の課題について教えてください。
上田 健太郎様（以下、敬称略）：会社の成長に伴ってデータがどんどん増えていき、深夜に前日分のテーブルデータを一括で全件転送するバッチ処理では、転送時間がかかりすぎてしまいました。処理が長引くほど本番サービスへの影響も無視できなくなっていたのです。
弊社が提供する「Park Direct」というサービスは月極駐車場のプラットフォームであり、ダウンタイムが許されません。そのため、本番のデータベースに負荷をかけずにデータを転送する必要があったのです。
また、1日1回のデータ同期では情報の鮮度が低く、用途が限られてしまうという課題も抱えていました。経営企画などのビジネスサイドからも、KPIの達成状況などをより新しいデータで確認したいという要望がありました。データが1日前のものだと、本来は達成しているKPIが未達のように見えてしまうこともあり、ニアリアルタイムに近いデータが求められていました。
そうした課題に対して、最初はどのように対応しようとされたのでしょうか？
上田：最初は、転送頻度を上げるために差分転送を自社開発し、自分たちで解決しようと試みました。ところが、プロダクトのデータベースには1レコードごとにユニークなIDが必ずしも振られておらず、これが原因でデータの同期エラーが発生してしまったのです。
さらに、差分転送をアプリケーション側の更新日時などのロジックに依存させると、特定の処理を通ったレコードの更新日時が古いままになり、転送漏れが発生するというエラーも経験しました。
このような経緯から、より安全で確実なマネージドの方式に任せたほうが良いと考えるようになりました。
なぜ「TROCCO」を選んだのか
難しい運用は自社で行わず、本業にリソースを集中する
「TROCCO」のCDC機能を導入しようと考えたきっかけは何だったのでしょうか？
上田：導入検討のきっかけは、primeNumber社主催のユーザー会「primeNumber User Group」に登壇した際、PostgreSQLに対応したCDC機能が近日中にリリースされるという情報を伺ったことです。
イベントでの上田さまの登壇資料は下記よりご覧ください。
もともと「TROCCO」はデータ基盤の立ち上げ時から利用しており、primeNumber社には大変お世話になっていました。その一方で、全件転送の課題を解決する手段としてCDCの仕組み自体は知っていたものの、ネットなどに具体的な情報が少なく、どう導入すべきか模索していたタイミングだったのです。
そのようなタイミングで、使い慣れた「TROCCO」からCDC機能がリリースされるという話を聞き、導入を検討し始めました。
導入にあたっては、どのような選択肢を比較検討されたのでしょうか？
上田：CDC機能を自社で一から開発するか、CDCサービスを使うかの2択で考えていました。
ただ前提としてAnalyticsチームは現在6名のため、自社で構築・運用するよりも、データマート整備や分析、AIを活用した分析の民主化といった、より事業貢献に近い領域にこそリソースを割いた方が有効だと考えました。
CDCを内製すると常に転送の監視が必要になりますが、そうした難易度の高い運用を自分たちで抱え込むのは、優先度として違うと判断したのです。
他社のCDCサービスも比較しましたが、料金体系が不透明で見通しを立てづらく、運用を続けるうえでのトータルコストの面でも、私たちの状況には見合わない部分が多くありました。最終的に、技術的な難所はマネージドのSaaSに任せるべきだと考え、「TROCCO」のCDC機能を選びました。
「TROCCO」のCDC機能を選んだ決め手は何だったのでしょうか？
上田：決め手は、長年「TROCCO」を使っていたことで培われた、ツールとしての安定性とprimeNumber社のサポートに対する信頼感です。
実際にデータ基盤の立ち上げ時から利用していますが、日常のデータ転送において「TROCCO」が原因で止まるといったトラブルはありませんでした。
自社開発をすれば障害のリスクが伴いますが、安定して動き続けてくれている「TROCCO」の実績と、万が一の際にも頼りになる担当者の技術力やサポート体制への信頼が積み上がっていたため、新しいCDC機能も安心して導入することができました。
導入までの具体的なスケジュールやプロセスについて教えてください。
上田：2025年9月頃に検討を開始し、11月の後半から12月にかけてトライアルという形で使用を開始しました。そして検証を重ね、翌年の2026年1月には本稼働に至りました。
導入後の効果
本番環境に負荷をかけないニアリアルタイム連携で、顧客サービスの信頼性を支える
実際にCDC機能を導入されて、ビジネスや技術面にどのような効果があったかお聞かせください。
上田：一番の成果は、本番のデータベースにほとんど負荷をかけずに、変更データのみをニアリアルタイムで転送できるようになったことです。
弊社のサービスはダウンタイムが許されないため、この技術的なメリットは非常に大きいと感じています。また、自社でCDCを開発していたら発生していたであろう、インフラの監視やトラブル対応といったリソースを割かれずに済んでいることも高く評価しています。
導入後、データ転送の運用や管理はラクになりましたか？
上田：そうですね。ほとんど面倒を見なくて済むようになり、手離れが良くなりました。私たちが気にするようなトラブルは起きておらず、期待通りの安定稼働をしてくれています。
万が一の際にも、すぐにprimeNumber社に手厚くサポートしていただける安心感も魅力です。一度、転送時に問題が発生した際も、私たちが自己検知するのと同じくらいのタイミングで「転送が失敗していませんか」とお知らせをいただき、すぐに調査と対応を進めてくれました。
ニアリアルタイムなデータ連携は、ビジネスサイドでどのように活用されているのでしょうか？
上田：例えば、駐車場を100台単位で法人手配する「Park Direct for Business」では、手配の完了まで時間がかかるため、タスク管理ツールで管理している進捗状況をお客様向けのダッシュボードで公開しています。
こうした顧客向けのレポーティングは事業成長に伴って対象データが急増しており、転送負荷も年々大きくなっていました。プロダクトDBの転送をCDCに移したことで基盤全体の転送リソースに余裕が生まれ、こうしたビジネス向けの活用を止めずに広げていける状態になっています。
今後は、KPIをよりリアルタイムに通知する仕組みや、契約データの不備をAIと組み合わせて早期に検知する仕組みなど、CDCのニアリアルタイム性がより直接的に効いてくる領域へ展開していく予定です。
今後の展望
「AI Analytics Chatbot」による分析の民主化と、さらなる業務効率化へ
データ基盤が安定したことで、今後どのようなことに取り組んでいきたいとお考えですか？
上田：転送や運用の手間が省けたことで、今後はAIを活用した分析の民主化、つまり誰もがデータを活用できる状態（イネーブリング）をさらに推進していきたいと考えています。
その施策の一つとして、弊社では「AI Analytics Chatbot」という仕組みを構築しました。これは、データマートの定義やSQLのコメントをAIに読み込ませることで、Slack上で自然言語で質問すると、AIが分析用のSQLを生成してくれるというものです。
AIを活用することで、どのような変化がありましたか？
上田：AnalyticsチームのSQL開発が圧倒的に効率化されました。また、開発のバックグラウンドを持つビジネスサイドのメンバーも、AIを使って自ら分析を行えるようになってきています。人間が最初に仮説を立てて、それを基にAIが初版のレポートを作成し、人間が品質チェックを行うという流れができつつあります。
今後は、このAIと一緒に分析できる領域をさらに広げ、どの部署でもデータを活用できるような環境を作っていきたいです。
最後に、データ基盤を用いた今後の事業展望をお聞かせください。
上田：オペレーションが複雑な業務のデータクレンジングや不備検知を、データ基盤とAIで自動化していきたいです。
法人向けサービス「Park Direct for Business」では、一度に100台規模のご依頼を頂くこともあり、オペレーションが非常に複雑になります。その結果、お客様からの契約データに不備が生じたり、対応漏れが発生したりするリスクがあるのです。しかし、これらをすべて人力でカバーするのには限界があります。
そこで、CDC機能でデータをニアリアルタイムに連携し、BigQueryのAI関数などとかけ合わせることで、エラーの早期発見やアラート通知を自動化する仕組みを作っていきたいと考えています。
TROCCOのCDC機能にご興味がある方は、こちらからお問い合わせください。
