Cursorへの課金が、いよいよもって止まらない。
これまでは、月額60ドルの「Pro+」プランをベースに、足りなくなったら都度払いするという小市民的スタイルで凌いできた。しかし、現実は非情である。10ドル、また10ドルと積み重なる課金も、AIの計算資源の前では焼け石に水であった。そして今日、今週四度目となる「You've hit your usage limit」のアラートが画面に表示されたとき、嗚呼、これが年貢の納め時というものか、と僕は静かにまぶたを閉じ、「Ultra」プランへのアップデートボタンを押し込んだのであった。
月額200ドル。 今のレートならざっと32,000円。繰り返すが、毎月である。十年少し前にAdobeが月額課金になったとき、月5,000円という金額で騒いでいたのが懐かしい。デザインツールならまだしも、テキストエディタに毎月三万円を払うことになるなんて、あの頃には考えられなかっただろう。
明日からはもやしを食べてコードを書こうと思う。
とあるプロジェクトの打ち合わせで、「AI生成の画面デザインって、どうしてAIっぽく感じるんですかね？」と聞かれた。これは、プロダクトデザインに関わる人たちにとっては、結構いい酒のつまみになる話だと思う。
デザイナーである僕の感覚的な話になるが（専門外の人が同じ違和感を抱くかどうかは分からないが）よく感じるのは、「ただ、結果だけが立ち上がって見える」という、妙な手触りのことだと思う。
僕は、アプリケーションやWebサービスの画面を見たときに、制作者がどんな順序で考え、何を解こうとしていたのかを想像することができる。あるいは、どこがまだ詰めきれていないのか、どこで思考が止まっているかも、それなりに見抜くことができる。こだわりを感じるところや、迷いのあるところは触れば分かるし、そこに制作のプロセスが痕跡として残っているからだ。
人間のデザイナーはたいてい、何を作るのか、どう使われるのか、情報や構造はどうあるべきか、といった低いレベルの問いから順番に積み上げていく。その結果として、画面全体に一貫した思想がにじむのだが、AIが生成した画面は、第一印象はいかにもいい出来に見えるものの（余白や配色、コンポーネント単体の完成度は高い）しばらく眺めていると、この画面で何をしてほしいのか、この情報はなぜこのように置かれているのか、といった根本的な意図が不明瞭であることに気づく。
単に設計が甘い、という感じとも少し違う。人間が考えきれなかったときのような、迷いの跡がなく、判断の来歴が見えない。どこか空洞を覗き込んでいるような感触だ。
言葉にしていて気づいたが、これは「AIっぽさ」というより、「素人がAIを使って作った感じ」のことを言っているのだと思う。
デザイナーがAIを使う場合は、基礎的な設計や前提をAIとの対話の中で詰め、それを共有したうえで生成させる。そうすると、この種の空洞感はかなり薄れていく。（実際、去年の夏頃から僕が作ったものは、ほとんどそうやって作られている。）
また、「AIっぽいかどうか」は本質的な問題ではない。重要なのは、使いやすいかどうかであり、利用者にとっては制作の方法や背景よりも、目の前の体験がすべてである。利用者が支障なく使えるのであれば、専門家の目に「AIっぽさ」が映ったとしても、ひとまず問題視するべきではないだろう。
だから、僕が「AIっぽさ」を気にしているのは、そこに「使いづらさ」があるからだ。まず「使いづらさ」が先にあって、その使いづらさの原因を専門家として見たときに「これはAI生成に起因しているな」と分かってしまうために、「うーん、いかにもAIぽいですねえ」などと口走ってしまっているに過ぎない。
これは自戒も込めて書いておくのだけど、決して「AIっぽさ」そのものを問題視したいわけではないので、AI生成物をレビューするシチュエーションにおいては、それがどんなAIでどう生成されたか……といった話題にうつつを抜かさず、可及的すみやかに話題の中心を「使いづらさ」とその解決方法に移行するよう努めていきたい。
ここ数日、僕のこのブログが閲覧できない状態が続いていたようだ。
原因は、Netlifyで契約しているクレジット量（1,000クレジット）が上限に達してしまったことで、「クレジットを追加しない限りサイトは停止したままです」という通知が届いていた。なんてこった。
管理画面のCredit usage breakdownを確認すると、Production deploysで1,470クレジットを消費している。つまり、ほぼすべてがデプロイ由来の消費ということになる。1回のデプロイにつき、本番ビルド＋本番CDNへの反映＋メタデータ処理が走り、約15クレジットが使われている計算だ。
昨年11月にCMSをContentfulへ移行したことで、更新回数が増えたのが大きな要因だろう。Contentfulはエントリーを保存するたびにWebhookを飛ばし、Netlifyはそれを検知するたびに自動でデプロイを実行する。それが記事の微修正であっても例外ではない。
言葉を少し直すたびに15クレジットが消費されていたと考えると、これはなかなかに大ごとだ。推敲しやすい環境を手に入れたと思ったら、同時に課金が加速しやすい構造を作ってしまっていた。今さらながら、CMS × Netlifyというのはかなりマズい組み合わせであることに気がついた。
対策としてデプロイを手動に切り替える方法も考えられるが、それでは問題を解決する代わりに利便性を手放すことになる。NetlifyをやめてCloudflare Pagesを使うのがよさそうに思えるが（確か公式にHugo対応していたはず？）今度詳しく調べてみよう。
ここ数日、Cursorを使ったコーディングでFlutterプロジェクトを作っているのだけど、AIを使ったコーディングの一番の恩恵は、実装と同時にドキュメントを整えていけることだと感じている。
デザイナーの頭には、実装している最中に「このコンポーネントはこういうオプションで構成されているなあ」ということが浮かぶ。例えば、スナックバーだと、（1）色：通常とエラーの2種類 （2）メッセージ：文字列 （3）サブメッセージ：文字列（なければ非表示） （4）アイコン：ファイル（なければ非表示） （5）ボタンの有無：boolean （6）ボタンのラベル：文字列 といった具合だ。
これまでだと、「うーん、あとでFigmaにまとめておくか……」と思って終わっていたのだけど、AIがあるとこういうことをポンポン喋って（音声入力して）まとめてくれというだけで仕様書に仕上げてくれる。なんなら実装も整えてくれる。まじ便利。実装でその通りになっていない箇所を見つけるのも簡単。
あと、 doc/spec/ 以下に snackbar card button tab みたいなフォルダを用意して、それぞれに spec （コンポーネントの仕様）と usage-list （どこでどう使ってるか）というファイルを作っている。（ usage-list があるとデザイナーの設計作業はとてもやりやすくなる。デザインの調整はプロダクトの中の相対的な関係や、影響範囲を見渡しながら行っていくため。）
ドキュメントの保守は、コード側に「ここを変えたら、このドキュメントを更新すること」とマーキングしておくことで、AIがコード編集時に自動的に検知できる。
このリリースノートの書き方いいかんじ！ 参考にしたい。
