AIとヒートマップで回すUIUX改善 ── 匿名化した操作ログから課題を見つけ、日単位で直す
石塚 凪（代表取締役社長 兼 CEO）公開日: 最終更新: 
- 生成AI
- Claude Code
- UIUX
- ヒートマップ
- 保守運用
こんにちは、株式会社Becalmの石塚凪です。普段はシステム全体のアーキテクチャ設計と技術選定を担当しています。
「ボタンの位置を変えたら使いやすくなるはず」「この画面、たぶん分かりにくいよね」。UIUX改善の議論は、こうした"たぶん"から始まることが少なくありません。そして"たぶん"を確信に変えるには、アクセス解析、ABテスト、ユーザーヒアリングと、時間もお金もかかる工程を一つずつ踏む必要があります。
弊社では、保守運用をお任せいただいているサービスで AI・ヒートマップ・匿名化した本番操作ログ を活用し、このサイクルを大きく短縮しています。課題の発見から Issue の起票、承認後の改修と PR の作成までを自動で回す基盤を作っており、エンジニアが手を動かすのは承認とレビューだけです。現在は「気づいた翌日には直っている」ことも珍しくありません。
この記事では、その裏側にあるデータの扱い方と AI の使い方を、少し踏み込んで紹介します。後半では、特に成果が出ている2つの事例も取り上げます。
UIUX改善はなぜ高くつくのか
UIUX改善が高くつくのは、課題の発見から効果測定までのどの工程でも、人がデータの集計や日程の調整、実装に時間を取られるからです。一般的には次の流れで進みます。
- 課題の発見：アクセス解析、問い合わせの集計。数字は「どこで」離脱したかは教えてくれても「なぜ」までは教えてくれない
- 原因の特定：ユーザーヒアリング、ユーザビリティテスト。日程調整・実施・議事録整理だけで数週間かかる
- 改善案の検証：ABテスト。有意差が出るだけのトラフィックと期間が必要。業務システムでは母数が足りないことも多い
- 改修：デザイン → 実装 → レビュー → リリース。一つの改善に数日〜数週間
- 効果測定：リリース後の数値比較。測る指標が事前に決まっておらず、効果が曖昧なまま終わりがち
特に業務で使うシステムでは、ユーザーは「使いにくい」と感じても、わざわざ報告してくれるとは限りません。黙って回避策を覚えるか、静かに使わなくなるか。課題が表に出るまでに時間がかかり、出てきたときには手遅れ、ということもあります。
私自身、前職で業務システムの開発と運用に携わっていたころ、この「黙って回避策を覚える」場面に何度も出会いました。特に印象に残っているのは、現場ごとにいた「Excel のプロ」のような人たちです。システムからデータを書き出しては、関数やマクロを組み合わせて自分たちの業務に合わせた使いやすい Excel を作り、実際の管理はそちらでやり直していました。システムはデータを入れるためだけに開く場所になっていて、本当の業務は Excel の中で回っていたのです。開発側には、一度も報告されていなかった使い方でした。理由を聞いてみると、返ってくるのは「そういうものだと思っていた」「慣れればそこまで困らない」という答えでした。
回避策は、続けているうちに「いつもの手順」になります。本人にとってはもう不満ですらないので、問い合わせにもアンケートにも出てきません。開発側が気づくのは、その Excel を作った人が異動や退職でいなくなり、誰もマクロを直せなくなったときです。ユーザーの声を待つのではなく、操作そのものを見にいく。今の仕組みの出発点には、このときの経験があります。
もう一つ、業務システムならではの難しさがあります。ABテストが成立しにくい ことです。利用者数が限られるうえ、同じ店舗や同じ会社の中で画面が人によって違うと、業務そのものが混乱します。「データで検証したいのに、検証の定番手法が使えない」。私たちの仕組みは、この制約を前提に組み立てています。
株式会社Becalmのアプローチ：3つのデータを AI に渡して、サイクルを回す
私たちが取っているのは、「ユーザーに聞く前に、ユーザーが実際にやったことを見る」というアプローチです。材料は次の3つです。
- ヒートマップ・セッション録画（画面 × 要素）：実ユーザーが画面上で何をしたか（クリック、スクロール、迷い、詰まり）
- 匿名化した本番操作ログ（リクエスト単位）：どの操作がどの順番で行われ、サーバーがどう応答したか
- 本番データの集計値（状態のスナップショット）：操作の結果、データがどう変わったか（件数・状態の分布など）
いずれも 個人を特定できる情報を取り除いた状態 で扱っています。この3つを AI（Claude Code）に渡し、観測 → 仮説 → 改修 → 検証 のサイクルを回します。サイクルを回しているのはエンジニアではなく、定期的に自動で動く改善基盤です。
ポイントは、データの集計から Issue の起票、PR の作成までを基盤が自動で行い、人が関わるのは2か所だけ にしていることです。基盤が起票した Issue に着手するかを決める「承認」と、基盤が作った PR の「レビュー」です。エンジニアがデータを集めて資料にまとめたり、改修の段取りを組んだりする必要はありません。
ログだけでは見えない「何も起きなかった操作」
AI にアプリケーションログを分析させる取り組みは、すでに多くの現場で行われています。ただ、ログに残るのはサーバーに届いたリクエストだけです。押しても反応しなかったボタン、探しても見つからなかったメニュー、途中まで入力してやめたフォームは、ログには一行も残りません。ユーザーが一番困っている瞬間ほど、ログは沈黙しています。
この「何も起きなかった操作」を記録しているのが、ヒートマップツールです。私たちはヒートマップのデータとログを同じ時間軸でつなぎ、AI に一人ひとりの操作を一続きの流れとして読ませています。ヒートマップのデータまで AI に読み込ませて分析する取り組みは、私たちの知る限り、まだあまり聞きません。
AI がやっているのは、数字の集計というより 実際のユーザーの行動の再現 です。どの画面で何を探し、どこを押して、反応がなくてどこへ回り道したのか。画面の前にいたユーザーの動きを AI が一つずつなぞることで、ログだけ、ヒートマップだけでは見えなかった「本当はこうしたかった」が浮かび上がってきます。この記事で紹介する改善のほとんどは、この再現から生まれました。
ただ、「データを AI に渡せば改善案が出てくる」ほど単純ではありません。生のデータをそのまま渡しても、AI はもっともらしいだけの結論を返してきます。ここからは、AI が正しく判断できるようにするために、データと AI の側でどんな工夫をしているかを順に説明します。
仕組みの全体像
株式会社Becalmの仕組みでは、本番環境のデータを匿名化レイヤーで個人を特定できない形にしてから、分析基盤で一本のイベント列に揃えて AI エージェントに渡します。AI の分析役と反証役が残した仮説は、基盤が Issue として自動で起票します。人が Issue を承認すると、実装役が改修して PR を作成し、人のレビューを経てリリースされます。リリース後の効果測定も基盤が自動で行います。
3つのデータを「同じ時間軸」に揃える
最初の壁は、3つのデータの粒度がまったく違うことです。ヒートマップは「画面 × 要素」の集計、ログは「リクエスト」単位、DB は「ある時点の状態」です。そのままでは、「ヒートマップで見えた連打」と「ログに残ったエラー」が同じ出来事なのかどうかすら分かりません。
そこで、すべてのデータを 匿名セッションID × 画面 × 時刻 をキーにした一本のイベント列に揃えています。
- 画面の正規化：/kartes/1234/edit のような URL は /kartes/:id/edit に揃え、画面単位で集計できるようにする。クエリ文字列は、個人情報が紛れ込みやすいため許可したキー以外を捨てる
- 時刻のずれの吸収：端末側の時計とサーバー側の時計は一致しない。クリックと API リクエストを、一定の許容幅の中で前後関係から対応付ける
- 操作の意味付け：「POST /reservations/:id」のような生のリクエストを、「予約を変更した」のように、ユビキタス言語（開発者と現場の利用者が共通で使う、そのドメインの言葉）で表した操作名に変換しておく。AI が読むのは技術的なログではなく、ユビキタス言語で書かれた操作の流れになる
AI に渡るのは、たとえば次のような形のデータです。SALON LINX で、スタッフが朝に予約表を開いたときの操作を例にしています。
{
"session": "s_7f3a…",
"role": "staff",
"device": "tablet",
"events": [
{ "t": "08:51:02", "screen": "/reservations", "action": "予約表を表示" },
{ "t": "08:51:09", "screen": "/reservations", "action": "dead_click", "target": "予約カード（カルテ作成済み）" },
{ "t": "08:51:10", "screen": "/reservations", "action": "dead_click", "target": "予約カード（カルテ作成済み）" },
{ "t": "08:51:18", "screen": "/kartes", "action": "カルテ一覧を表示" },
{ "t": "08:51:31", "screen": "/kartes", "action": "カルテを検索", "query_length": 3 },
{ "t": "08:51:40", "screen": "/kartes/:id", "action": "カルテを表示" }
]
}誰の予約か、何を検索したかは一切含まれていません。それでも「予約から行けないので、検索で回り道している」ことは十分に読み取れます。AI はこのイベント列を頭から読み、ユーザーがたどった操作を一つずつ再現しながら、どこで手が止まったのかを探していきます。
ヒートマップツールの API には取得回数や遡れる期間に制限があるため、知りたいことを先に決めてから1回で取り切り、スナップショットとして保存する 運用にしています。期間を過ぎたデータは取り直せないので、改修前のベースラインは必ず残します。
匿名化は「あとで消す」ではなく「最初から入れない」
本番のデータを扱う以上、ここが仕組み全体の土台です。私たちは、個人を特定できるデータを 分析にも AI への入力にも一切使っていません。そのために、匿名化を「危ない項目を消す」方式ではなく、「許可した項目しか通さない」方式で設計しています。
- 許可リスト方式：操作名・画面・時刻・ステータスなど、明示的に許可した項目だけを通す。新しい項目は、追加の判断をするまで自動的に捨てられる。防ぐもの：ログの項目が増えたときに、個人情報が知らないうちに流れ込むこと
- 鍵付きハッシュによる仮名化：セッションやアカウントの識別子を、分析環境の外で管理する鍵でハッシュ化する。鍵は定期的に切り替える。防ぐもの：匿名IDから元の人物を逆算すること、長期間の行動をつなぎ合わせて人物を推定すること
- 自由記述は値を捨てて特徴量だけ残す：カルテのメモや検索語は中身を捨て、「文字数」「入力にかかった時間」「書き直した回数」だけを残す。防ぐもの：入力内容からの個人の特定
- 最小セル数の制約：集計表の1区分（セル）に一定人数以上が含まれる場合だけ、その集計値を出力する。防ぐもの：小規模なサロンや部署の集計から、特定の個人を推定すること
- 画面側でのマスク：ヒートマップ・セッション録画は、画面上のテキストと入力値をマスクした状態で記録する。防ぐもの：録画からの個人情報の閲覧
さらに、本番 DB は 集計値として読むだけ で、個々のお客さまのレコードを AI に渡すことはありません。本番環境への書き込みや、取り消しの効かない操作は AI からは実行できないようにしています。これらのルールは AI 向けの規約としてリポジトリに明文化しており、人間と同じ基準で AI にも守らせています。
見たいのは「誰が」ではなく「どこで、なぜ詰まったか」です。UIUX改善にはそれで十分ですし、そのほうが分析の焦点もぶれません。
詰まりを「フリクションスコア」で数値にする
画面数が多いシステムでは、「どこから直すか」を決めるだけでも一苦労です。押しても何も起きない場所のクリック（デッドクリック）が多い画面、離脱が多い画面、エラーが多い画面。指標ごとに上位が違うと、議論は声の大きい人の意見に流れがちです。
そこで、画面 × 要素ごとに フリクションスコア を算出しています。
- 詰まりのサイン：デッドクリック、レイジクリック（短時間の連打）、クイックバック（開いてすぐ戻る）、入力欄の滞在時間の外れ値、エラー応答、同じ操作のやり直し
- 重み付け：サインごとの深刻度に加えて、その画面がどれだけ日常的に使われるか で重みを付ける。月に一度しか開かない画面の大きな詰まりより、毎朝全員が開く画面の小さな詰まりのほうが、積み重なる損失は大きい
- セグメント分け：オーナー／スタッフ／お客さまといった役割、PC／タブレット／スマートフォンといった端末、時間帯で分けて算出する。全体の平均では埋もれる「タブレットのスタッフだけが朝に詰まっている」といった偏りが浮かび上がる
操作の「回り道」を見つける
スコアが教えてくれるのは「どこが詰まっているか」です。「ユーザーが本当は何をしたかったのか」を知るには、操作の流れそのものを見る必要があります。
私たちは匿名化したイベント列から、画面と操作の 遷移パターン を集計しています。想定している業務フロー（たとえば「予約表 → 予約詳細 → カルテ」）と、実際に多く通られている経路を比べると、ユーザーが自力で編み出した 回り道 が見えてきます。SALON LINX では、たとえば次のような経路が見つかりました。
- 予約表 → カルテ一覧 → 検索 → カルテ → 予約表、というループが朝に集中している
- 配信設定の途中で、条件の付け外しを何度も往復した末に保存せず離脱している
- 予約確認ページを開いたお客さまが、スクロールを繰り返したあと LINE のトーク画面に移っている
回り道は、「本来あるべき導線が欠けている」ことのサインです。頻度が高く、遠回りの度合いが大きい経路ほど、改善の効果も大きくなります。
AI を「分析役」と「反証役」に分ける
スコアと遷移パターンが揃ったら、AI に仮説を立てさせます。ここで私たちが重視しているのは、一つの AI に考えさせて終わりにしない ことです。
分析役 の AI には、フリクションスコアの上位、該当画面の遷移パターン、画面のソースコードを渡し、詰まりの原因を推定させます。
（SALON LINX での依頼例）予約管理画面で、フリクションスコアが高い要素を上位から見て。それぞれについて、前後の操作の流れから、ユーザーが何をしようとして失敗しているかを推定し、ソースコード上の原因と合わせて説明して。
AI がソースコードも読めるので、「この要素はボタンに見えるが実際はただのラベルで、クリックしても何も起きない」といった、コードレベルの原因 まで含めて仮説が返ってきます。
次に、別の文脈で動く 反証役 の AI に、その仮説を崩しにいかせます。
- その仮説以外に、同じデータを説明できる理由はないか
- 特定の店舗や端末にデータが偏っていないか。サンプル数は十分か
- 時間帯や曜日の影響（サロンなら予約が集中する週末や定休日明けなど）で説明できてしまわないか
反証を生き残った仮説だけを 影響の大きさ × 確信度 × 改修コスト で並べ、上位のものから基盤が Issue として自動で起票 します。AI はもっともらしい説明を作るのが得意なぶん、もっともらしいだけの説明も作ってしまいます。反証役を置いてからは、「直したのに効かなかった」という空振りが目に見えて減りました。
ヒアリングをゼロにしているわけではありません。ただ、ヒアリングは「何が困っていますか」と探るためではなく、生き残った仮説が合っているかを確認する場 に変わりました。聞くことが具体的になるので、短い時間で済みます。
承認されたら、PR の作成まで基盤が進める
基盤が起票する Issue には、仮説と一緒に次の3点が必ず入ります。
- 根拠データ：どの画面のどの指標が、どれだけ悪かったか。再現した操作の流れも添える
- 期待する指標の変化：この改修で、どの指標がどちらに動けば成功か
- ガードレール指標：悪化したら切り戻すべき指標（エラー率、処理時間など）
人がやるのは、この Issue を読んで「着手してよいか」を判断することだけです。承認されると、基盤が実装役の AI（Claude Code）を起動し、改修・テスト・PR の作成までを自動で進めます。各リポジトリにはコーディング規約、テストの方針、デプロイ時の注意点などを AI 向けのルールとして整備しており、実装役はそれに沿って作業します。PR には Issue の3点がそのまま引き継がれます。
Issue を起票する時点で「どうなれば成功か」が決まっているので、リリース後に「効いたのかどうか分からない」状態になりません。承認されなかった Issue も、却下の理由とあわせて基盤が記録し、次の分析で同じ仮説を出し直さないようにしています。
AI に任せてみて意外だったのは、依頼内容と実態のズレを AI が自分で見つけてくる ことです。SALON LINX での実例を2つ挙げます。
- サロンさまから「カルテ一覧の検索を使いやすくしてほしい」というご要望をいただいたときのことです。基盤が起票していた予約管理画面の Issue を確認したところ、多くのスタッフが予約管理画面で、カルテ作成済みの予約を何度もタップしていました（デッドクリック）。反応がないとカルテ一覧に移動し、お客さまを検索して目的のカルテを開いていたのです。AI の見立ては「本当の課題は検索ではなく、予約からカルテへ移動する手段がないこと」。反証役も、時間帯や端末の偏りでは説明できないことを確認しました。そこで検索の改修より先に、予約から直接カルテを開けるボタンを追加しました。リリース後は該当箇所のデッドクリックがほぼなくなり、カルテ一覧での検索回数も減っています。
- 「自動配信をもっと使ってもらうために、配信文面のテンプレートを増やしたい」というご相談をいただいたときのことです。基盤の分析を見ると、自動配信の設定を始めたオーナーの多くは、文面を書き終えたあとの「配信対象の条件」を選ぶステップで手が止まり、条件を何度も付け外ししたうえで、保存せずに離脱していました。AI の見立ては「文面に困っているのではなく、その条件で誰に何人届くのかが分からず、送るのが怖くなっている」。そこでテンプレートを増やす前に、条件を変えるたびに対象人数と届く内容のプレビューがその場で更新されるようにしました。リリース後は設定を最後まで終えるオーナーが増え、自動配信を使うサロンそのものが増えています。
承認とレビューで人が見るのは、こうした判断が妥当かどうかです。データを集めることにもコードを一から書くことにも時間を取られなくなった分、「この改修は本当にユーザーのためになるか」を考える時間 に使えるようになりました。
ABテストなしで効果を確かめる
冒頭で触れたとおり、業務システムでは ABテストが成立しにくいという制約があります。そこで私たちは、改修の前後比較を、比較が崩れないように設計する ことで代わりにしています。
- 1つの PR に1つの仮説：1日に何度もリリースしていると、複数の改修の効果が混ざりやすい。改修ごとに影響する画面を記録し、計測対象を分けておく
- 曜日構成を揃えて比較する：業務システムの利用には曜日の波がある。SALON LINX の場合、サロンは週末に予約が集中し、定休日もサロンごとに違う。改修前後を単純に日数で区切らず、同じ曜日の組み合わせになる期間どうしで比較する
- 改修の影響を受けない画面を対照にする：同じ期間の別の画面の指標も見ておき、全体の利用が増えただけ、という見かけの改善を除く
- 3つの軸で確認する：ヒートマップの指標が改善しても、ログでエラーが増えていれば別の問題を生んでいるかもしれない。「1軸だけで結論を出さない」ことを運用ルールとして明文化している
効果測定も基盤が自動で行います。リリースから一定期間がたつと、Issue に書いた指標の前後比較を計算し、結果を Issue に書き込みます。ガードレール指標が悪化した場合は基盤が担当者に通知し、原因の調査よりも先に切り戻します。検証の結果は「効いた改修のパターン」として AI 向けのルールに書き戻しており、次のサイクルでは AI がそれを前提に仮説を立てます。サイクルを回すほど、仮説の精度が上がっていく仕組みです。
事例1：SALON LINX（株式会社スタイラーズさま）
この仕組みは保守運用をお任せいただいている複数のサービスで回しています。ここからは、特に成果が出ている2つの事例を紹介します。
ここまで例に使ってきた SALON LINX は、株式会社スタイラーズ（東京都港区）が運営する、美容室特化の LINE 自動接客サービスです。予約管理・電子カルテ・顧客管理・自動配信を LINE 上でまとめて扱え、ホットペッパービューティーとの連携にも対応しています。株式会社Becalmが開発と保守運用を担当しています。
SALON LINXは4月にサービス開始からわずか 6 ヶ月満たない中トライアルを含めて100サロン以上 に導入いただいており、月間ユーザー数は約5万人 にのぼります。
ユーザー層は幅広く、PCで管理画面を使うオーナーもいれば、施術の合間にタブレットやスマートフォンで予約を確認するスタッフ、LINE から予約やカルテを確認するお客さまもいます。役割と端末の組み合わせごとに「困っていること」がまったく違うため、セグメントごとのフリクションスコアが特に威力を発揮しています。
データから先に見つけた3つの課題
どれも、ご要望として上がってくる前にデータから見つけた課題です。
朝の「カルテめくり」をなくす
- データから見えたこと：時間帯 × 端末で分けると、開店前のタブレットのスタッフだけ、フリクションスコアが突出していた。遷移パターンを見ると、予約表とカルテの間を来店客の人数分だけ往復していた
- 本当の課題：スタッフが知りたいのはカルテの全文ではなく「前回何をしたか」だけ。それを確認するために、画面の行き来を繰り返していた
- 改修と結果：予約表から前回の来店内容と施術メモをその場で確認できるようにした。朝の準備でカルテを開く回数が大きく減り、カウンセリングの質を上げる準備に時間を使えるようになった
カルテ入力を「書く」から「選ぶ」へ
- データから見えたこと：施術後のカルテ入力画面で、入力欄の滞在時間が外れ値になるセッションが多い。入力内容そのものは扱わず、文字数と入力時間の分布だけを見ても、施術の種類ごとに入力の形がよく似ていた
- 本当の課題：施術の合間に、毎回同じような文章を手で打ち直していた。忙しい時間帯ほど入力が後回しになり、カルテの記録漏れにもつながっていた
- 改修と結果：よく使う文言をテンプレートとして登録し、選ぶだけで入力できるようにした。入力欄の滞在時間が短くなり、施術当日中に完了するカルテの割合も上がった
「LINEで聞く」しかなかったお客さまの迷いを解消する
- データから見えたこと：お客さま向けの LINE 画面で、予約確認ページからトーク画面へ移る遷移が、想定していた業務フローにない経路として上位に出てきた。直前にはスクロールの往復が集中していた
- 本当の課題：お客さまは予約を変えたかったのに、変更の入口が見つからず、サロンへのメッセージで依頼していた。サロン側はそのやり取りを手作業で受けていた
- 改修と結果：予約詳細の目に入る位置に変更・キャンセルの導線を置いた。お客さまが自分で手続きを終えられるようになり、サロンが受ける予約変更のメッセージも減った
ユーザーの声
改修後の効果はヒートマップの指標でも確認していますが、何よりうれしいのはユーザーから直接届く声です。株式会社スタイラーズさまの許可をいただき、SALON LINX のユーザー（美容室のスタイリスト）さまから届いたメッセージを紹介します。
事例2：B社さま 基幹システム
2つ目は、B社さまの基幹システムです。発注・帳票・会計・分析・勤怠など、社内・社外の業務全般を担うシステムで、社員の方は PC だけでなく、現場からスマートフォンでも日常的に利用されています。
利用する方の職種も端末もさまざまで、画面数も多いため、「どの画面のどこで手が止まっているか」をデータで掴めることの効果が大きく出ています。特に、利用頻度で重み付けしたフリクションスコアによって、毎日の業務で何度も通る画面の小さな詰まり を優先して直せるようになったことが、現場の手間の削減に直結しました。
業務の中核を担うシステムなので、使いにくさはそのまま現場の手間と残業につながります。小さな引っかかりを一つずつ、ためずに直していけることが、基幹システムでは特に効いています。
2つのサービスのリリース頻度
この仕組みの導入後、SALON LINX と B社さまの基幹システムでは、改修のスピードが上がりました。直近3か月（2026年7〜9月）の実績は次のとおりです（いずれも月平均の目安）。
- SALON LINX：本番リリース 約130回／月、マージされた改修（PR） 約180件／月
- B社さま 基幹システム：本番リリース 約100回／月、マージされた改修（PR） 約160件／月
SALON LINX では、1日あたり平均4回以上 本番リリースしている計算になります。UIUX改善だけでなく、機能追加や不具合修正も含めた数字ですが、「小さく作って、すぐ出して、データで確かめる」が日常的に回っていることが分かると思います。
保守運用の標準業務として、追加費用なしで
この取り組みは、株式会社Becalmに保守運用をお任せいただいているお客さまに対して 標準業務として提供しており、別途費用はいただいていません。
UIUX改善を「別プロジェクト」として見積もると、調査・ヒアリング・ABテストだけでまとまった予算が必要になり、結果として後回しになりがちです。私たちは、運用中のサービスを日々よくしていくこと自体が保守運用の仕事だと考えています。AI によって調査と改修のコストが下がったからこそ、それを特別なオプションではなく、日常の業務に組み込めるようになりました。
うまく回すための3つのポイント
株式会社Becalmがこの仕組みを回してきて、効いたと感じているのは次の3点です。
匿名化は、分析より先に設計する。 分析の仕組みを作ってから個人情報を消そうとすると、必ず漏れが出ます。最初に「何を通すか」を決め、許可した項目しか流れない構造にしておくことで、データ活用を広げても安全性が崩れません。
AI に「反論役」を置く。 AI の仮説は、根拠付きでもっともらしく見えます。だからこそ、別の文脈で仮説を崩しにいく役を置き、反証を生き残ったものだけを改修に回しています。一つの AI の結論をそのまま信じないことが、空振りを減らす一番の近道でした。
改修と計測を同時に作る。 「どうなれば成功か」を、Issue を起票する時点で書いておく。これだけで、リリース後の振り返りが「なんとなく良くなった気がする」から「この指標がこれだけ動いた」に変わります。検証の結果を AI のルールに書き戻せば、次のサイクルの精度も上がっていきます。
まとめ
UIUX改善のサイクルが重かった理由は、手法そのものよりも、データを集めて読み解き、改修の段取りを組む作業がすべて人に寄っていたことにありました。株式会社Becalmでは、ヒートマップと匿名化した本番操作ログを同じ時間軸でつなぎ、AI に実際のユーザーの行動を再現させることで、その作業を自動で動く基盤に任せています。人が関わるのは Issue の承認と PR のレビューだけです。個人を特定できるデータは一切使わず、見ているのは「誰が」ではなく「どこで、なぜ詰まったか」だけです。
この仕組みで、SALON LINX では月130回前後、B社さまの基幹システムでは月100回前後の本番リリースを続けています。保守運用をお任せいただいているお客さまには、標準業務として追加費用なしで提供しています。
課題も残っています。公開したばかりの画面は比べられる過去のデータがないため、効果測定の精度が落ちます。この期間の測り方は、今まさに試行錯誤しているところです。
振り返ってみると、効いたのは AI の賢さそのものより、ユーザーが黙って覚えてしまう回避策を、声になる前に見つけられるようになったことでした。我慢しながら使われている画面は、どのサービスにもあるはずです。同じ課題を持つ方の参考になれば幸いです。
株式会社Becalmでは、一緒にプロダクトをつくるエンジニアを募集しています。この記事に興味を持っていただけた方は、面談の際に「この記事を読んだ」とお伝えください。採用ページ
株式会社Becalmでは、Web サイト制作・Web システム開発・SaaS 開発のご相談を受け付けています。同じような課題をお持ちの方は、お気軽にお問い合わせください。お問い合わせページ
