見出し画像

Claude Codeで、UIデザイン改善を毎朝Issue化してPRを出す仕組み

アオキタカユキ｜UIで思考のズレを言語化

なかなか改善ポイントを見つけるのって、時間がかかりますよね。正直、面倒くさい。アナリティクスは入れている。でも、なんかピンとこない。感覚でIssueを決めている。ヒューリスティックなテストも大事です。でも、やはり根拠がないとだめだな、と思っていました。

毎日分析して、Issueを作成して、あわよくばPRまで作ってくれないかな——と。んで、構築してみました。

ひとことで言うと、「毎朝、サイト／プロダクトの状態を見て、改善案をIssueにし、安全に直せるものは自動でPRまで出す」仕組みです。

なぜ作ったか

日次レポートを読んでも、改善が止まると意味がない。数字を見る、課題を言語化する、Issueにする、実装する、効果を見る。この一連を、人の記憶や気合に依存せず回すために作りました。

全体の流れ

計測 → 分析 → Issue化 → 優先順位付け → 自動実装 → PR → レビュー → 効果検証。毎朝（JST 8:00）に GitHub Actions が走ります。

計測では GA4 / Search Console / GitHub指標 / 依存関係の脆弱性などを取ります。分析では Claude が前日比・週次比から異常と改善案を出し、重複を避けて GitHub Issue を作成します。優先度はインパクト ÷ 工数で並べ替え、バックログを更新。安全に直せるものだけブランチを切って実装し、PRを出します。main への直pushはせず、人がレビューしてマージする。対応後の指標変化は、あとから振り返ります。

大事にしている設計原則

ひとつ目は、人が最後に判断すること。自動で直しても、本番反映は人が承認します。「無人で壊す」ではなく、「無人で下書きまで作る」が目的です。

ふたつ目は、重複Issueを増やさないこと。同じ指摘が毎日再提案されないよう、オープンIssueだけでなくクローズ済みも重複判定に含めます。ここを雑にすると、バックログがすぐ汚染されます。

みっつ目は、対応可能なものだけ自動実装すること。コードで直せるものは自動PR。管理画面の操作、外部資産、ビジネス判断が必要なものは Issue にコメントして見送り。権限追加や DOM selector 削除など危険な変更は、手動レビュー必須にしています。全部を自動ではやりません。やる範囲を狭くしています。

よっつ目は、セキュリティも同じサイクルに入れること。依存関係の脆弱性も毎日監査し、検出 → Issue化 → 優先度付け → 修正PR（または手動対応）までつなぎます。改善とセキュリティを別運用にしないほうが、続く気がしています。

適用した2つの事例

同じ骨格を、プロダクト種別に合わせて移植できることがポイントです。

ひとつは Webサイト／LP。目的は PV / CTA / 回遊 / 問い合わせ遷移まわりで、指標は GA4 や Search Console など。CTA導線や UTM、構造化データの整備、重複Issue防止、依存脆弱性の自動Issue化といったところが回るようになります。マーケ寄りのサイトでも、日次で「次に触るべきもの」が見える。

もうひとつはブラウザ拡張。目的は拡張の健全性維持で、DOM互換、UX、ストア公開まわりを見ます。指標は GitHub の活動指標、静的解析、依存脆弱性など。GA4がないプロダクトでも回せるよう、計測層だけ差し替えました。

サイトと拡張では見る数字が違います。でも、Issue化 → 優先度 → 安全な自動PR、という骨格は同じです。

仕組みの部品

部品はざっくり六つです。

  • Daily Report：指標取得・差分・異常検知

  • Claude Analysis：改善案と優先度の生成

  • Issue Sync：重複防止つきIssue作成

  • Backlog：優先度順の固定Issueを更新

  • Auto Implement：安全なIssueだけ実装してPR

  • Security Scan：依存脆弱性の検出とIssue同期

全部が毎回フル稼働する必要はありません。計測が薄いプロダクトなら、静的解析と依存監査からでも回せます。

何を自動化し、何を自動化しないか

ここが一番大事だと思っています。

自動化する:

  • 数値の収集と比較

  • 改善案のたたき台作成

  • Issueの整理と優先順位付け

  • 低リスクなコード修正とPR作成

  • 脆弱性の再検出・解消検知

人がやる:

  • 文言・ブランド判断

  • 外部管理画面の操作

  • 危険な変更の最終判断

  • PRレビューとマージ

AIに全部やらせたい気持ちはわかります。でも、壊したあとの復旧コストのほうが高い。なので、下書きまでで止めています。

うまく回すためのガードレール

仕組みだけで安心しないために、上限と禁止も入れています。

  • 1回の実行で試行数・PR数に上限を置く

  • 既存PRがあるIssueは再実装しない

  • 見送りでも次の候補へ進む

  • ビルド／拡張検証が通らない変更は捨てる

  • 触ってはいけないファイル・権限変更を禁止する

「毎朝がんばるエージェント」ではなく、「毎朝、安全な候補だけを積むバッチ」くらいの感覚です。

導入に必要なもの

最低限はこれです。

  • GitHub リポジトリ

  • GitHub Actions

  • Claude Code 用トークン

  • （任意）GA4 / Search Console など計測基盤

GitHub だけで始められます。計測が薄いプロダクトは、静的解析と依存監査からで十分です。数字が揃ってから、分析の解像度を上げればいい。

このサイクルで得られること

「見て終わり」のレポートから、「直すところまで進む」レポートになります。改善の優先順位が毎日更新され、対応済み課題の再発行が減り、小さな修正が止まらず積み上がる。セキュリティ対応も同じ運用に乗ります。派手な成果というより、止まらなくなる感じです。

まとめ

改善は、アイデアより運用です。毎日の小さな差分を Issue と PR に変える仕組みがあると、プロダクトは静かに強くなります。

この自動サイクルは、完璧なAI開発者を目指すものではありません。「毎日、次にやるべきことを可視化し、安全なものは下書きまで進める」ための、地味で強いPDCAです。

読んでくださってありがとうございました。
この記事が「なるほど」と思えたら、「スキ」や「フォロー」もらえるとうれしいです。チームにもシェアしてもらえると、次の記事のモチベーションになります。

プロモーション

iCAREでは、一緒に成長しながら新しいチャレンジに挑戦できる仲間を募集しています。
まずは、カジュアル面談のお申し込み からお気軽にお話ししてみませんか？
皆さまのご応募を、心よりお待ちしています。

XでもUIデザインやプロダクト開発に関する投稿をしています。ご興味がありましたら、ぜひフォローしていただけると嬉しいです。

いいなと思ったら応援しよう！

アオキタカユキ｜UIで思考のズレを言語化 よろしければ応援お願いします！いただいたチップはUIデザインプロダクト開発に関するnote作成に使わせていただきます！