MIXIが「1秒以内の画像検索」を維持しながら「DB管理費→75％削減」、どう実現？：写真・動画共有サービス「みてね」の裏側

MIXIは、写真・動画共有サービス「家族アルバム みてね」の自然言語検索基盤を刷新。膨大な写真・動画から目的の画像を素早く探せる仕組みを維持しながら、検索基盤の管理費用を約75％削減した。

[＠IT]

　MIXIが運営する写真・動画共有サービス「家族アルバム みてね」は、約3000万人の登録ユーザーを抱え、2026年1月時点で累計200億件以上の写真・動画が共有されている。

　同サービスでは、「赤ちゃん」「笑顔」「誕生日ケーキ」といった日常的な言葉から、関連する写真・動画を探せる自然言語検索機能を提供している。写真にタグやコメントが付けられていなくても、画像の内容を基に検索できるのが特徴だ。

　こうした検索機能を大規模なサービスで提供するには、膨大なデータを効率的に処理する必要がある。課題となったのは、検索の応答速度を維持しながら、増え続けるデータを低コストで管理できる基盤を構築することだった。

膨大な写真・動画をどう検索する？　MIXIが採用した仕組み

　MIXIは検索基盤を刷新し、検索応答を1秒以内に維持しながら、同じリクエスト量を前提としたデータベース管理費用を約75％削減したという。検索速度とコストの両立をどのように実現しているのか。

　Amazon Web Services（AWS）は2026年9月29日、MIXIが採用した検索基盤について公式ブログで紹介した。これによれば、MIXIはオブジェクトストレージ「Amazon S3」のベクトルデータ保存・検索機能「Amazon S3 Vectors」を採用した。Amazon S3 Vectorsは2025年12月に一般提供が開始され、同時に東京リージョンでも利用可能になったものだ。

　Amazon S3 Vectorsは、ベクトルデータの保存と類似検索に特化したサーバレスサービスだ。検索用のサーバやクラスタを常時稼働させる必要がなく、保存するベクトルデータの量や検索リクエストなどに応じて料金が発生する。

　MIXIはこの検索基盤において次の3点を重視した。

• 大規模データへの対応
  • 数億〜数十億件のベクトルデータを保存し、新たな写真・動画の追加にも継続的に対応できること
• 持続可能なコスト
  • ユーザー数やデータ量の増加に伴って、インフラコストが過度に膨らまないこと
• 検索の応答速度
  • ユーザーが検索語を入力してから3秒以内に結果を返せること

数十億件のベクトルデータをどう検索するのか

　自然言語検索の実現には、画像と文章を同じ形式のベクトルに変換する技術が使われている。

　MIXIが採用したのは、LINEヤフー（LY Corporation）が公開した日本語向けのCLIPモデル「clip-japanese-base」だ。CLIPは画像と文章をそれぞれベクトルに変換し、両者の意味的な関連性を比較できる機械学習モデルだ。

　MIXIは、写真・動画のアップロード時に画像を512次元のベクトルに変換して保存する。ユーザーが検索語を入力すると、その文章も同じ512次元のベクトルに変換し、保存済みのベクトルとの類似度を計算する。

　類似度の評価には「コサイン類似度」を使用する。ベクトル同士の向きがどの程度近いかを数値化することで、検索語と意味的に関連する画像を見つけ出す仕組みだ。

　同社によると、clip-japanese-baseは「SigLIP2」などの多言語モデルよりも日本語検索で高い精度を示した。また、512次元という比較的小さなベクトル表現と軽量なモデル構成によって、ベクトル生成にかかるコストも抑えられるという。

　ただし、数十億件規模のベクトルデータ全てに対して、検索のたびに類似度を計算するのは現実的ではない。そこで重要になるのが、検索対象を効率的に絞り込む仕組みだ。MIXIは、家族ごとに割り当てられる識別子「family_id」のハッシュ値を使って、データを複数のインデックスに振り分けている。

　検索時には、対象となる家族のデータが格納されたインデックスだけを参照する。これにより、全てのインデックスを横断して検索する必要がなくなり、データ量が増えても効率的に検索できる構成とした。

数十億件のデータ移行費用を数万円に抑えた工夫

　従来の検索基盤では、データの分割管理や圧縮によって1秒未満の検索応答を実現していた。しかし、検索用のサーバを常時稼働させる必要があり、利用が少ない時間帯でも一定の費用が発生していた。

　そこでMIXIは、サーバの構築・管理が不要で、利用量に応じて課金されるAmazon S3 Vectorsへの移行を決めた。ただし、数十億件規模のベクトルデータを移行する際の書き込み費用が課題となった。

　Amazon S3 Vectorsでは、データの書き込み時に1回のリクエスト当たり最低128KB分の料金が発生する。そのため、少量のデータを何度も書き込むと、費用が割高になる。

　そこで約500件のベクトルデータをまとめて書き込むバッチ処理を採用。1回当たりの書き込みデータ量を増やして課金上の無駄を減らし、数十億件規模のデータを数万円程度の一時的な費用で移行できたという。

検索応答1秒以内を維持、運用負荷も軽減

　Amazon S3 Vectorsへの移行によって、MIXIは検索性能を維持しながら、コストと運用負荷を削減した。主な成果は以下の通りだ。

• コスト
  • 同じリクエスト量を前提としたデータベース管理費用を約75％削減
• 性能
  • 検索応答を1秒以内に維持
• 運用
  • シャードの設計・管理が不要になり、障害対応も簡素化

　一方、検索基盤の刷新だけでは解決できない課題もある。その一つが、検索の安全性だ。みてねは子どもの写真を扱うサービスであるため、MIXIは不適切な検索語をAPIサーバ側で検知し、該当する場合は検索結果を返さない仕組みを設けている。

　検索精度についても、社内テストや人手による確認を実施し、コサイン類似度のしきい値を使って検索結果の品質を制御している。

　今回の事例は、既存の検索基盤が性能要件を満たしていても、データ量の増加や将来の機能拡張を見据えて構成を見直すことで、コストと運用負荷を削減できることを示している。