大規模システムにおけるデータベースのパフォーマンス向上や、生成AIの業務適用――。
まだまだ勉強中の新入社員である私にとって、あまり想像できない分野の話でした。
しかし、先日参加したGoogle Cloud Next Tokyo 2026で聴講した「メルカリのAlloyDB運用事例」と「ソフトバンクの生成AI本番導入アプローチ」のセッションは、現場のリアルな課題と解決策が詰まっていて非常に勉強になりました。
この記事では、新入社員の視点からセッションを通じて学んだ技術的な工夫や、これから意識していきたい気づきをまとめてお届けします。
メルカリ事例:AlloyDBを活用した大規模基盤と「泥臭い」運用改善の裏側
まず聴講したのが、メルカリさんのグローバルアプリ基盤に関するセッションです。
モノリスからクラウド・gRPC構成への移行にあたり、ベンダーロックインを避ける目的でAlloyDBを採用されたとのことでした。
モジュールごとにDBを細かく分けるマイクロサービス構成をとっているのですが、印象的だったのはその先にある運用の工夫でした。
1. SigLIP×ScaNNインデックスによる1SQL類似検索の工夫
ECアプリでおなじみの「見た目が似ている商品」を表示する類似検索。
メルカリさんでは以下のような仕組みで実装されています。
- ベクトル化: 画像エンコーディングモデル「SigLIP」で商品画像をベクトル化。
- 類似度計算: PostgreSQLのベクター型とコサイン距離演算子を活用。
- 高速化: ScaNNインデックスを適用。
ここでなるほどと思ったのが、単に「見た目が似ている商品」を返すだけでなく、「現在販売中(ON_SALE)であること」などのビジネス条件も組み合わせ、1つのSQLで完結させているという点です。
新人の学びメモ
技術的に高度なベクトル検索を入れるだけでなく、「今すぐ買えるか」というユーザー視点の条件をSQL1本に落とし込んでいるのがスマートだなと感じました。一方で、ScaNNインデックスの肥大化を防ぐためにバッチでモニタリングしながら手動でクリーンアップしているという、地道な運用面も知ることができて参考になりました。
2. リードプールの「透過的ルーティング」と「ウォームアップ」
Read負荷が増大してプライマリDBだけでは支えきれなくなった際、読み取り専用のリードプール(Read Pool)を導入されたそうです。
ここで工夫されていたのが、「開発者にプライマリかリードプールかを意識させない仕組み(透過的ルーティング)」をクライアント側で実装していたことでした。
sqlcが生成するDBTXインターフェースを満たすクライアントに差し替えるだけで自動ルーティングされると聞き、アプリ側の開発体験まで考慮してインフラを設計する重要性を感じました。
また、新しいリードプールを追加した直後はバッファが冷えていて一時的に性能が落ちるため、「本番クエリをミラーリングして流し、バッファをウォームアップしてから投入する」という運用手順をとっている点も、プロのノウハウとして非常に勉強になりました。
MCnP(Managed Connection Pooling)導入で学んだ「マネージド=丸投げではない」という教訓
Pub/Subのack失敗から発生する「リトライストーム」によるコネクション急増を抑えるため、メルカリさんではMCnP(Managed Connection Pooling)を導入されたそうです。
しかし、ただ有効化して終わりではなく、導入過程でいくつかのハードルがあったとのことでした。
| 直面した課題 | 原因 | どうやって解決したか? |
|---|---|---|
| IAM認証エラー | Language Connectorの自動IAM認証がMCnPで未サポート | マニュアルのIAM認証へ切り替えて解決 |
| 段階的移行ができない | Language Connectorだと全接続が強制的にMCnPに切り替わってしまう | Direct Connectorを採用し、モジュールごとに安全に段階移行 |
一番参考になったポイント
セッションの中で特に印象的だったのが、「マネージドサービスを入れて終わりではない。丸投げではなく、中身の仕組み(プーラーの動きや接続方式)を正しく理解して継続的に調整していくことが大事」という言葉です。
便利なマネージド機能を使うときこそ、内部で何が起きているのかを把握しておく必要があるのだと痛感しました。
ソフトバンク事例:「線の業務代行」を実現するAI活用と組織の作り方
続いて聴講したソフトバンクさんのセッションでは、技術面だけでなく「AIをどうやって組織に定着させるか」という視点で多くの気づきがありました。
「点の作業代行」から「線の業務代行」へ
これまでのAI活用は、文章要約やメール作成といった「点の作業代行」が中心でした。
しかしこれからは、業務プロセス全体をAIに引き渡す「線の業務代行」を前提に準備する必要があるそうです。
【これまで】 人が働く環境が前提 ➔ 一部の作業をAIが手伝う(点の代行) 【これから】 AIが働きやすい環境・データ基盤 ➔ 業務プロセス全体をAIに任せる(線の代行)
新入社員が入社したときに業務マニュアルや環境を整えるのと同じように、「AIにとっても理解しやすく動きやすい環境(Google Workspaceなどのデータ基盤、ドキュメント化、標準化)」を整えることが大切だと整理できました。
本番導入を阻む「2つの壁」をどう越えるか?
AIを現場に定着させるには、以下の2つの壁を乗り越える必要があるとのことでした。
- 技術の壁(本番運用に耐えうるか?)
最初から本番運用に必要な要素が揃った基盤で一気通貫のPoCを行い、小さなテーマで検証して解像度を上げていく。 - 人・組織の壁(現場で使われるか?)
ツールを渡して終わりではなく、現場で問題が起きたときに一緒に伴走する。社員の「ここを変えたい」という想いを束ねて、「現場の業務知」と「エンジニアの実装知」を重ね合わせる。
技術的な検証だけでなく、使う人や組織のプロセスに寄り添うアプローチが必要不可欠なのだと分かりました。
まとめ:新入社員の私がこれから意識していきたいこと
Google Cloud Next Tokyo 2026のセッションを通じて、新卒エンジニアの私は以下の2点を意識していきたいと感じました。
- マネージドサービスやライブラリの「中身の仕組み」まで理解して使うこと(メルカリ事例より)
- 技術単体を見るのではなく、業務全体のフローや使う「人」の視点を持つこと(ソフトバンク事例より)
日々の開発や運用業務の中で、ただタスクをこなすだけでなく「なぜこの構成なのか」「どうすれば運用しやすいか」を考えながら取り組んでいこうと思います。
最後まで読んでいただきありがとうございました!
この記事が、DB運用やAI活用について考えている方の参考になれば幸いです。