なぜ実装エージェントはUXの指摘をしてくれないのか ─ コード起点レビューと画面起点レビューの違い

実装エージェントには UX の指摘が期待できない。リポジトリを見せた途端、レビューは「実装可能な改善」に寄る。これはモデルの能力不足ではなく、見せたコンテキストの問題だ。記事は 3 層に分析する。まずコンテキスト：リポジトリという豊かな情報は、同時に「現在の構造で実装できるか」を暗黙の制約として埋め込む。結果画面の改善を例にとれば、リポジトリ接続のエージェントは「ScoreCard から useDiagnosisScore に分けて責務を軽くする」と言う。保守性の観点では正しい。だが画面のみ見たチャットは「複数の支援情報を同時に見せず、利用者がまず持ち帰る一つを決めるべき」と返す。別の問いに答えている。前者は「実装をどう維持するか」、後者は「利用者に何を伝えるべきか」。次に、モード。「直して」と頼むと「直せる範囲」の提案に収束する。修正作業を期待されないチャットでは「そもそもこの機能は要るのか」を言いやすい。最後に、モダリティ。スクリーンショットだけを渡すと、実装経緯は見えず、初見の利用者として画面を読む。情報量が少ないほうが、レビューは自由になるのだ。コードには余白が 16px だと書かれても、その余白が見た目で息苦しいかは画面を見た方が早い。中小企業が個人開発や外注管理で直面するのは、実は UX 判断の不在だ。機能は足りているが「ユーザーは次に何をすればいいか分かるのか」が抜ける。リポジトリ有りのエージェントと無しで役割分離する。PM 兼 UX レビュアーはスクリーンショット、実装はコード起点。この分け方が、制作現場の体験を変える。