支援実績一覧
パフォーマンス改善
データベースや配信経路の最適化によって、システム全体の応答速度と安定性を向上。
チケット管理SaaSの検索レスポンスを高速化（N+1解消）
チケット管理SaaSにて N+1 解消と Preload / IN句最適化を実施し、一覧APIの応答時間を 1.4s → 0.2s（約7倍高速化）、DBクエリ数を 80%削減。
| 観点 | 内容 |
|---|---|
| 課題 | 一覧APIで N+1 クエリが多発し、ページ取得ごとに大量の SELECT が発行されていた。 |
| 対応 | データアクセス層を再設計し、関連データを Preload で一括取得。複合条件の参照は IN句によるバッチ取得で最適化。 |
| 観測 | リクエスト相関IDをキーとした構造化クエリログを導入し、クエリ数・種別・レイテンシをリアルタイム可視化。 |
| 結果・成果 | クエリ数を削減し DB負荷と接続プールの占有率が安定。さらに、性能退行を常時検知できる状態を確立。 |
MySQL障害からの復旧と書き込み性能の安定化
本番DB障害の原因となっていたバッチI/O負荷を、テーブル月次パーティション化とINSERT最適化で解消し、バッチ時間を70%短縮、空きメモリ安定化。以降3ヶ月再発なし。
| 観点 | 内容 |
|---|---|
| 課題 | 業務時間帯に本番DBが障害を起こし、再送リトライがスパイクして全体のレスポンスが悪化。加えて、可視化が不十分で再発リスクを十分に評価できない状態だった。 |
| 初動 | Aurora 自動フェイルオーバーとリードレプリカ分散を即時整備し、Slow Query / CloudWatch メトリクス / エラーログを常時監視できる状態に。 |
| 調査 | CloudWatch メトリクスとイベントログを相関分析し、バッチ処理の DELETE→INSERT 方式 がメモリ・I/O を圧迫していることを特定。 |
| 対応 | テーブルを 月次パーティション化し、バッチを TRUNCATE + Multi-row INSERT に刷新。運用は 段階的移行・即時ロールバック・週次レポート をセットで定着させた。 |
| 結果・成果 | 計画外フェイルオーバーの 再発リスクを抑制。バッチ時間と負荷変動が安定し、システム全体の可用性と 判断スピード が向上。 |
リバースプロキシ(Nginx)導入によるオリジン負荷の軽減
CDN〜アプリ間にNginxリバースプロキシを導入し短期TTLキャッシュ/コネクション再利用を実装。オリジン到達リクエストを40%削減しCPU負荷と応答ばらつきを安定化
| 観点 | 内容 |
|---|---|
| 課題 | 動的APIがアプリサーバーに集中し、CPU使用率の高止まりとレスポンスばらつきが発生していた。CDN→アプリの直結構成により、リクエスト負荷を吸収できない状態。 |
| 対応 | CDN とアプリの間に Nginx 中継レイヤを配置し、短期TTLキャッシュと Keep-Alive接続再利用 を導入。 |
| 運用 | 段階的導入と即ロールバック可能な設計を採用。HIT / MISS を可視化し、TTL と除外対象パスを継続的にチューニング。 |
| 結果・成果 | オリジン到達リクエストを大幅削減し、アプリのCPU負荷とレスポンスのばらつきが安定。ピーク時の耐性が向上。 |
開発生産性向上
品質保証の自動化とビルドパイプラインの改善により、継続的な開発速度を維持。
自動テスト基盤整備による安心して改善できる状態の確立
手動検証依存だった環境に対し、Unit/Integration/E2E の三層テスト基盤を構築し、リグレッションを防止。“壊さない確信” を得て大規模リファクタとアップグレードを継続可能に。
| 観点 | 内容 |
|---|---|
| 課題 | 手動検証に依存しており、リグレッション発生・検証コスト増・手順の属人化により、改善スピードと大型アップグレードが停滞していた。 |
| 対応 | ユニット / 結合 / E2E の3層を明確に定義し、テストが実装しやすい実行環境（CI・DB・モック・データ投入）を整備。 |
| 運用 | テストテンプレート化 と 共通 Fixture / Builder により、記述と保守コストを圧縮。失敗時に原因が一読で分かる命名規則を整備。 |
| 結果・成果 | “壊していない確信” を得られる状態により、リファクタリングや依存アップグレードを安心して実施可能に。手動確認も大幅に削減。 |
ビルド環境刷新による開発スピード向上
Webpackベースの巨大フロントエンドプロジェクトをRspackにリプレイスしビルド時間を短縮。Dev→Prod→CIで小刻みに展開し、即時ロールバック・二重ベンチ・差分検査を標準化。互換性を保ちながら“目に見える”短縮と運用の安定を獲得。
- 課題：Webpack前提の巨大モノレポでHMR遅延・初回/CIビルドの重さ・キャッシュ不安定が恒常化し、レビュー滞留とMTTR悪化を招いていた。
- 対応：Webpack高互換の Rspack を段階導入（Dev→Storybook→Prod→CI）、BUNDLERトグルで即ロールバック可。変換/SourceMap/分割ポリシーを両者で等価化し、設定のDRY化とキャッシュ戦略を再設計。
- 運用：毎PRで 二重ビルド＋差分検査（サイズガード）とスモークセットを常時通過。ベンチを自動化し、指標（p50/p95・バンドルサイズ・キャッシュヒット）を可視化。
- 成果：HMR体感とビルド所要が 目に見えて短縮、レビュー待ちと開発マシン負荷が 安定方向 に。互換（SSR/Storybook/Sentry等）を維持したまま段階的に効果を回収。
プロダクト改善
検索体験や予約システムなど、ユーザー視点での操作性と信頼性を向上。
検索体験を改善し「0件」を減らす（クエリ緩和＋ランキング調整）
完全一致検索により「0件」になりやすい検索体験を、段階的な条件緩和とスコアリング調整により改善。代替提案を自然に提示できるようにし、離脱率を抑えつつ手応えのある結果提示を実現した。
| 観点 | 内容 |
|---|---|
| 課題 | 完全一致検索により、条件が少しずれただけで「0件」になりやすく、ユーザーが再検索を繰り返して離脱につながっていた。 |
| 対応 | 検索条件を段階的に緩める多層ロジックを導入し、近さに応じてfunction_score / gauss decay でスコアリング。 緩和内容をメタデータとして保持し、UIに理由を明示。 |
| 運用 | 緩和ステップ／重み／閾値をダッシュボードで継続モニタリングし、A/Bテストによる副作用の検証と調整を継続。 |
| 結果・成果 | 「0件検索」を大幅に減らし、再検索回数の減少と滞在時間の向上を達成。 代替提案の受容率向上により、検索体験が分断されずスムーズに。 |
| 効果 | 手応えのある検索体験が実現し、在庫消化率・予約率の改善に寄与。今後のML化 / ベクトル検索への拡張余地も確保。 |
検索インデックス更新を非同期化し、ピーク時の耐性向上
Airbnb型の複合条件検索を前提に、Outbox→Pub/Sub→Indexer の非同期パイプラインでインデックス更新を平準化。書き込み系のP95を維持しつつ、イベント発行→ES反映の鮮度SLOを定義・計測し、冪等・順序制御・DLQ/再処理で最終的整合を担保。さらに Query Relaxation と function_score/gauss、Top-Nリランキングを段階導入し、0件率の低減とCVR向上をA/Bで検証した実装事例。
- 課題：在庫・価格更新を同期で ElasticSearch に反映していたため、書き込み処理が負荷集中時に遅延・タイムアウト。セール時などのスパイクで可用性が不安定化していた。
- 対応：Outbox → Pub/Sub → Indexer の非同期パイプラインへ刷新。また部分アップサートで更新処理の軽量化。
- 成果：書き込み体験の安定を維持しつつ、大きな遅延なくElasticSearch 反映。ピーク時も在庫の鮮度と検索信頼性を両立。
- 波及効果：非同期更新が社内標準化され、他のAPIにも展開。負荷を平準化しながら拡張できる更新基盤として、運用コスト低減を実現。
期限切れ予約の自動解放により、在庫整合性と販売機会を維持
期限切れ予約が在庫に残存する問題に対し、Redis TTL＋バックグラウンド解放ジョブを設計し、自動回収を実現。未解放率を7%→ほぼ0%にし販売機会損失を防止。
| 観点 | 内容 |
|---|---|
| 課題 | 一部の予約が解放されずに残り、在庫が「満席のように見える」状態が発生。販売機会を失い、担当者の手動解放も発生していた。 |
| 対応 | Redis の TTL（有効期限）とバックグラウンドジョブを用いて、期限切れ予約を自動解放する仕組みを導入。 - 同一予約の重複処理を防ぐため、一意キーで制御。 - Redis はトリガー、実際の在庫更新は DB が担当する構成に。 |
| 可視化 | 滞留中の予約数と解放までの経過時間をメトリクス化し、モニタリングで挙動を常時把握。 |
| 成果 | 未解放予約はほぼゼロに改善。在庫が速く正確に更新されるようになり、販売機会損失を防止。 |
| 効果 | 予約APIのレスポンスが安定し、ロック待ちも減少。手動での解放作業がほぼ不要になった。 |