ID:83183さん

## 【概要】 美容医療プラットフォームで、外部AIサービスを使った肌診断・施術レコメンド機能を新規開発。〔PdM 1名・iOSエンジニア○名〕の体制で、バックエンド（Ruby on Rails）とWebView側（Angular/TypeScript）を担当し、技術調査・仕様調整から設計・実装まで行った。 ## 【課題】 - iOS・AndroidアプリのWebView上で、撮影から外部AIの解析、施術・チケットの提案までを実現できるか分からなかった。 - 解析は1回ごとに費用がかかるが、当初の仕様には利用回数の制限がなく、大量利用や不正利用で費用が膨らむおそれがあった。 - 顔写真という、漏れたときに取り消しのきかない個人情報を扱う必要があった。 ## 【工夫】 - 外部SDKの撮影UIは条件が揃うと自動でシャッターが切れ、利用者が自分のタイミングで撮れないため、顔の特徴点検出（MediaPipe）で位置・向き・明るさを判定する撮影UIを自作した。明るさの基準は顔画像品質の国際規格の参照値、向きの基準は実機で測った値をもとに決めた。 - 外部APIの呼び出しはすべてバックエンドを経由させ、APIキーを端末に置かない構成にした。解析に時間がかかるため、撮影直後に解析を始め、待ち時間に設問へ回答してもらう流れをPdMと決めた。 - 利用回数の制限を提案・実装した。1人あたり（1日2回・月8回）はMySQLで数え、未ログインでも端末IDやIPアドレス＋UAで数える。全ユーザー合計は時間帯ごとの上限をRedisで数え、上限の半分と上限到達でSlackに通知する。半分の値は、GA4の時間帯別の利用者数から、どの時間帯でも通常の2倍以上になるよう決めた。 - 解析の開始時点で仮に数え、失敗した分はワーカーが外部APIに成否を問い合わせて取り消す。費用が発生していない失敗で、利用者の回数が減らないようにした。 - 顔写真は結果が確定したときだけ、アプリ以外の読み取りを拒否した専用ストレージに1枚だけ保存する。一時保存を使わず、結果が出なかった写真を持たない設計にした。 ## 【成果】 - 実機検証をもとに、WebView上で撮影から提案までが動く構成を確定させた。 - 要件になかった利用制限と通知を入れ、費用の上限と異常な利用に気づく手段を用意した。リリース前のため、事業上の成果は未計測。

## 概要 AWS 上で稼働するサービスの運用メトリクス（ALB/ECS・RDS・キャッシュ・検索）の監視・調査業務を、Claude Code を用いて自動化した。毎週のメトリクス収集・判定・レポート作成に加え、異常項目の一次調査までを無人で実行する仕組みを構築した。 ## 体制と担当範囲 - 体制: マネージャー 1 名、エンジニア数名。運用監視の担当は当初自分 1 人で、途中から 2 人体制に移行した - 担当範囲: Claude Code CLI を Docker コンテナ内で動かし Slack と連携する既存の実行基盤の上に、監視対象の整理と判定基準の設計、4 系統の監視手順（Skill）と異常調査手順の作成、Top SQL の詳細統計取得と S3 保存、自動実行のラッパー（失敗通知・再試行）を自分が設計・実装した。週次の運用と調査、2 人体制化に伴う運用ドキュメントの整備も担当 ## 課題 従来は CloudWatch や RDS Performance Insights を個別に開き、メトリクスの変化や高負荷 SQL を手作業で確認していたため、異常の把握と原因調査に時間がかかっていた。Performance Insights はデータの保持期間が 7 日しかなく、過去の負荷状況を後から遡って比較できないことも課題だった。 ## 工夫 - Claude Code CLI を非対話モードで実行し、監視・判定・報告の手順を Skill（Markdown の手順書）として定義。AWS CLI と MCP（Slack 投稿・DB 参照・ログ検索）を実行ツールとして与え、「メトリクス収集 → 判定 → Slack 投稿 → 異常項目の一次調査 → 同一スレッドへの返信」を 1 回の実行で完結させた - EC2 の cron から毎週自動実行する構成にし、失敗時は Slack へ通知、API 過負荷時は間隔を空けて再試行するラッパーを追加した - 監視対象を ALB/ECS（応答時間・5xx・タスク数・CPU）、RDS（CPU・メモリ・デッドロック・行ロック時間・スロークエリ）、キャッシュ（eviction・ヒット率）、検索（クラスタ状態・JVM）の 4 系統に整理し、「前週と違う変化」と「実害のある異常」を分けて判定するよう手順を設計した。配信スケジュールやキャンペーン日で説明がつく変化は要注意項目に載せない - RDS Performance Insights の Top SQL を実行回数・レイテンシ・走査行数・返却行数付きで取得し、基準日で固定したベースラインと前週の 2 軸で比較して、新たに浮上した高負荷 SQL を検知できるようにした。ベースラインを固定したのは、毎週上書きすると基準がずれて緩やかな悪化を見失うため - 保持期間が 7 日の Performance Insights データを毎週 S3 に保存し、過去の Top SQL と調査結果を後から参照できるようにした ## 成果 - 手作業だった週次のメトリクス収集・比較・レポート作成を無人化し、異常項目については原因候補・影響範囲・推奨対応までが自動で出力されるようになった - レポートを起点に、 DB 負荷上位の SQL（1 回約 1 秒・約 14 万行走査で数行を返す結合）、分析用 DB で 8 日間走り続けていたクエリ、バッチ処理が外部 API の応答待ちの間に行ロックを保持し続ける構造的な問題などを特定し、原因と対処方針を課題として起票・共有するところまで自動化と運用で回せるようにした