概要
最近の開発にはなんでも Claude Code を使っていて、とても便利に感じています。ただ、趣味の一環として書いている iOS アプリの UI の実装に関してはなかなか思い通りのものを作ってくれないことがよくあります。難しめの UI をお願いすると明らかに見た目がおかしいものが出てくることもあって、そのたびに人間が泣きながら修正したり作り直すことになります。純粋なロジックの実装やサーバーサイドの開発では Claude Code は難しい要件でもそれなりに正確なコードを生成してくれる感覚があるので、どこからこの差が来るのか考えたい。
iOS アプリよりもそれ以外のコードの方が世の中に実装が多いので学習が進んでいるということもあると思いますが、より本質的にはこの違いは単体テストの存在から来ている気がします。ロジックの実装では、Claude Code が生成したコードが間違っていればテストが落ちるので間違いを Claude Code 自身が認識して修正してくれます。このフィードバックループがうまく回ることで、最終的に最低限単体テストが通ることにはなるので、それが求めている実装である可能性も高いでしょう。
UI の実装ではこのフィードバックループが存在しません。Claude Code は生成した SwiftUI のコードがどのような見た目になるのかを確認する手段がないため、言わばコードを書きっぱなしの状態になっていて、明らかに見た目がおかしくても気づくことができないということです。
自分が一番好きな iOS アプリの開発では UI のコードを書く割合が高いので、この部分で Claude Code にすべてを任せて隠居できるとありがたいです。そのために、 UI 実装でもロジック実装でいうところの単体テストによるフィードバックループを回したいです。 iOS の UI でいうところの単体テストはなにかというと... UI テストもありますが、より実装や実行のコストが軽く壊れづらいスナップショットテストが適しているのではないかと思いました。スナップショットテストとは、UI の見た目を画像として保存し、その画像を基準として UI の変更を検出するテスト手法です。
代表的なツールとして、 swift-snapshot-testing を使えばテストを実行することで任意の SwiftUI のビューをファイルに画像として書き出すことができます。本来のスナップショットテストはその書き出した画像を使って UI のデグレがないかを検出するのが目的ですが、今回は画像を書き出すだけで十分です。 Claude Code はコマンドでテストを実行することも、その結果出力された画像ファイルを読むこともできるので、 Claude Code が UI を実装 -> ファイルに書き出して想定と違いそうな箇所を反省 -> UI を改善 -> またファイルに書き出して反省 -> 改善というループを回せるのではないでしょうか。これがうまくできたらかなりよさそうなので試してみることにしました。
disclaimer として、自分はそこまで AI を使いこなしているわけではないので、実はもっといい感じで AI に UI 実装してもらう方法があるかもしれません。なにかご存知の方がいたら教えてください。
カニを再現しよう
まずぱっと思いついた題材として、カニの絵文字（🦀）を SwiftUI で再現してもらうことにしました。🦀 を SwiftUI で作るのは、 AI はおろか経験のある iOS エンジニアでもかなり大変です。 Claude Code が自分の実装を確認しながらやればどのくらいいい感じにできるのか面白そうです。
まずは、 Claude Code に参照させるためのお手本としてカニの画像ファイルを作っておきます。
その上で、 Claude Code （claude-opus-4-20250514）に以下のプロンプトを渡します。
ReferenceImages/ReferenceCrabView.pngに蟹の画像が置いてあります。これをできる限り再現するように、 SwiftUI でCrabViewを実装してください。こちらで事前に、作ったものを参照するフィードバックループを回せるように準備しておきました。MCP を使って iOS シミュレータ向けにテストを実行すると
AIAutoImproveExplorerTests/__Snapshots__以下にあなたが実装したCrabViewのスナップショットが書き出されるようにしてあります。実装したらスナップショットと参考画像を見比べた上でよく考えて実装を改善してください。この改善のループを最低５回、改善の余地がなくなるまで繰り返してください。改善の歴史がわかりやすいように、毎ステップで再現が不十分な部分を言語化した上でファイルを__Snapshots__/History以下にtestCrabView.(試行回数).pngにリネームして残すようにしてください。
まず、初回で実装された UI は以下です。
なるほどですね。カニを作りたいんだなということは伝わってきつつ、甲羅と足・ハサミの位置が噛み合っていません。実装を見ると Circle とか Capsule に加えて自前の Shape も作ってくれてがんばりは感じるのですが...。 Claude Code がこの画像を見た上で上げてくれた改善点は以下です。
初期実装のスナップショットと参考画像を比較すると、以下の改善点があります：
- 胴体の形状: 参考画像はもっと丸みを帯びた形で、胴体は横に広がっている
- 脚の配置と形状: 脚はもっと広がって配置され、曲線が滑らか
- ハサミの形状: 参考画像のハサミはもっと大きく、より丸みを帯びている
- 色: 参考画像はもっと鮮やかなオレンジ色でグラデーションが豊か
- 影と光沢: 参考画像にはよりリアルな光沢と影がある
- 全体のサイズ: 蟹全体がもっと大きい必要がある
この改善点を言語化して履歴に保存し、実装を改善します。
胴体の丸みとかよりも足とハサミの位置が明らかにおかしいことが気になってほしいのですが、 AI と人間では気になりポイントが全然違うのかもしれません。人間は全体の構造やパーツの位置関係を重視するのに対し、現状の Claude Code は色や形状の細部に注目する傾向があるのかな。
上記の点を踏まえて改善された２回目の実装は以下でした。
色やサイズをはじめとして、 Claude Code が挙げた改善点については確かによくなっているように思います。このまま Claude Code が改善を続けてくれて、５回目までの以下のようになりました。
| お手本 | 初回 | ２回目 |
|---|---|---|
| |
|
|
| ３回目 | ４回目 | ５回目 |
|---|---|---|
 |
 |
 |
回を追うごとになんらかの改善はされていることがわかります。足の配置がちょっとずつましになったり、５回目で一気にカニの質感が良くなっていたり...。一応、この方法で自身が実装した UI のスナップショットを見て修正するというループ自体は回せているようです。ただ、例えば仕事で PdM に今度のアプリアップデートでカニが必要だから SwiftUI で作っておいてほしいんだよねと言われてこの５回目のカニを見せて、最高、これでいきましょう！！となるでしょうか。おそらくならないと思います。
順位表を再現しよう
スナップショットのフィードバックがあっても、 Claude Code は思うようなカニを作ってはくれませんでした。手法に限界がある可能性もありますが、カニを作るというタスクが特殊で難しすぎるだけかもしれません。もっと現実にありそうなタスクとして、実際にあるアプリの画面を見せて、これと同じような画面を作ってもらうことを考えます。 X とか YouTube のスクショを渡して真似してもらう、というのはなんらかの問題がありそうな雰囲気を感じたので、最近自分が暇なときに作り進めているサッカー情報を見るアプリを再現してもらいます。以下の順位表画面の UI を Claude Code に作ってもらいましょう。
カニの絵文字のときと同じようなプロンプトを渡して、 Claude Code に自分が作った UI のスナップショットをを見ながら改善してもらいます。結果は以下のようになりました。
| 初回 | ２回目 | ３回目 | ４回目 |
|---|---|---|---|
 |
 |
 |
 |
初回では横幅が大きくて左の順位やそのさらに左のカラーバーが見切れてしまっていますが、それを２回目で改善できていることがわかります。それ以降は大きな変更はありませんが、フォントサイズなどでマイナーな改善がされています。これを見るとかなりうまくいっているように思えますが、実は何回か同じ手法でサイクルを回すと、以下のようにまったく改善がされないこともあります。
| 初回 | ２回目 | ３回目 | ４回目 |
|---|---|---|---|
 |
 |
 |
 |
また、うまくいっている場合でもあくまでスクショの通りの UI を再現するだけで、フォントサイズの可変設定やタブレットでのレイアウトが考慮されていない、柔軟性に欠ける実装が出てきてしまうという問題がありました。一方で、その辺もいい感じになるように実装して、と明示的に指示してもあまりよい実装は出てこなかったので、現状だと難しめの UI は人間が書くのがいいのかなと思ってきました。
まとめ
Claude Code にいい感じで iOS アプリの UI 実装をしてもらうために、スナップショットを撮影して Claude Code に自身の実装の改善点を見つけてもらう、という方法を試してみました。結果としては、改善のループは回っていて何もフィードバックがないよりはよい UI はできそうだけど、現状でわざわざこの方法を採用するほどではないと感じました。 AI 素人なので勘なのですが、それほどうまくいかない原因として
- 明確に Green / Red の結果が出る単体テストと比べると、参照画像と実装した UI のスナップショットを見比べて差分を見比べるというのはフィードバックとして曖昧すぎる
- たとえ UI の改善点が明確に分かったとしても、コードの修正が画面上でどのような UI の変化につながるのかが Claude Code にはわからないので最適な修正ができない
といったところが挙げられるのではないかと思います。それはそう。
これらの課題は今後の AI の進化で解決されるかもしれないし、されないかもしれませんが、なんにしてもこの記事でやってみたように UI 実装の結果を AI に認識させる方法は、一定以上に実装が難しい UI を作るためにいずれは重要になってくる気がします。自分が知らないだけですでにそういう手法があるのかな。
まあそんな小手先のことはどうでもよくて、そのうち AI に Figma を渡せば初手で完璧な UI を作ってくれるようになったり、そもそも AI が最高の UI をデザインを考えるところから実装までやってくれるのでそれを採用する、という世界観になっているかもしれません。あるいは、逆に細かい UI 調整が人間プログラマに残された最後の仕事になるのかも...。もともとなにもわからない人生が AI の進化によってよりわからなくなってしまいましたね。こちらからは以上です。
