次郎の貝塚
技術ブログのような何か
About | Profile | Diary | Application | Source Code | RSS
投稿日時 2026-11-10 23:49:10 +0900 | カテゴリー 技術
Cursor で静的な電卓を作ってみた
ちょっと試したいことがあって、Cursor で Web 電卓を作ってみた。 ソースコードは jiro4989/web-dentaku で公開している。
背景
そもそもなんで電卓を今更作ろうと思ったのかというと、嫌われるデザインの歴史 - Zennという記事を読んだのがきっかけ。
この記事のなかで「スキューモーフィズム」という用語が使われていた。 僕はあまりデザインまわりの用語に疎く、はずかしながらスキューモーフィズムという言葉を初めて聞いた。 スキューモーフィズムは、Web デザインにおいては「UI などを現実の物質に似せた見た目や質感にするデザイン手法」を指す。
用語としては初耳だったのだが、スキューモーフィズムの UI 自体は見覚えがあった。 Windows 98 や XP の頃の Windows のボタン UI などがそれだ。 UI 表現として、前に飛びだしているように表現してあって、いかにも「押せます」って感じの見た目をしている。
今でこそ古臭さを感じるけれど、僕はあの UI が結構好きだ。 分かりやすいし、今だって嫌いではない。
このスキューモーフィズムについて、上記記事内で触れられていた。 「スキューモーフィズムは、嫌われたのではなく、時代が変わって懐かしいものになった」というのは、僕の実感としてもそう思う。
そしてなんとなく、この「スキューモーフィズムで何か作ってみたい」と思った。 ということで、最も簡単に実装できるであろう電卓を実装することにした。
つまり、電卓は重要でなく、スキューモーフィズムを実践することが、今回の目的だ。
実装
手で実装しても良かったのだが、せっかくだったので Cursor に丸投げしてみることにした。 spec.md というファイルに今回作るものの仕様を定義して、それを読みこませて丸ごと実装させた。
用意した spec.md は以下。たったこれだけの指示だ。
# 機能仕様
* GitHub Pages 用の静的な電卓アプリ
* 素のHTML、JS、CSSのみで実装する
* JSはユニットテスト可能に実装する
* CSSは別ファイルに切り出す
* スキューモーフィズムなデザインにする
* パッと見電卓っぽい見た目にする
* 実装するボタンは数字と小数点、DEL, AC, +, -, x, ÷, =, (, ) のみ
こんな雑な指示だけで、Cursor(有料版)は先のアプリを生成してくれた。 AI の実力の凄さを実感するばかりだった。
軽く動作確認したかぎりでは、ちゃんと電卓としての機能は満たしている。 UI も電卓っぽさを表現しているし、ボタンっぽさも再現できている。 ユニットテストも実装されている。
CI まわりの整備は軽く自分で調整したが、アプリケーションの実装においては本当に一切手を加えていない。 いやはや本当にすごい時代になったものだ。
もちろん、これがフロントエンドエンジニアを不要にするとは思っていない。 しかし、雑で良いものをささっと作りたいなら、AI だけで十分満足できるものが作れてしまった。
保守性などを鑑みるとちゃんと作りこんだほうがいいが、今回のプロジェクトにおいては作り捨てなので問題ない。
プロダクトの正解はどこにある？
今回、電卓の実装を Cursor に丸投げしてみて、AI の強力さを再認識したが、同時に危うさも感じている。
今回作った電卓は、非常に単純なものだし、仕様については僕が決めるまでもなく、Web 上に正解が転がっている。 だからあんな雑な指示だけで、ちゃんとしたものが作られた。 一方で、プロダクト開発の世界においては、その限りではない。
僕らエンジニアが開発しているプロダクトは、基本的に非公開情報だ。 当然業務ロジックなども、ほとんどは Web 上に公開されていない。 というよりは、解決できるプロダクトが存在しないから課題になっているわけで、ないものを作るのがプロダクト開発だ。 つまり、電卓のようなありふれたものと違って、プロダクトにおける正解は Web 上にない。
法規制などの守るべきルールはあれど「プロダクトとしてどうあるべきか」という正解は「自分たちが決めたもの」が正解になる。
AI に抱く幻想
機能を作るな。楽して作るな。 - LayerXというスライドとも通ずるものなのだが、AI の早さの誘惑は非常に強力だ。
AI は、人間より膨大な量の仕事を、人間より早く処理できる。 ルールが明確な作業においては、人間よりずっと正確に作業してくれることも多い。 だから、AI にすべてを任せたくなる。 自分より早く、自分より優れた「正解」を出してくれると、そういう幻想を抱きたくなる。
自動化の果て
AI が毎日コードを全スキャンし、バグや脆弱性を検出し、修正方法まで提案してくれるようになった。 それを AI が読み取って、修正コードを作成して Pull Request まで作成してくれる。 そして作成された Pull Request を AI がレビューして、CI がパスするかと合わせて確認して、レビュー結果まで通知してくれる。
機能開発だって AI づくしだ。タスクの記述は AI で行い、それを AI で読み取って Pull Request の作成も AI でやる。なんと素晴らしいことだろう。
だが、この自動化・高速化の果てには何が待っているんだろうか？ 機能開発における正解まで、AI に求めだしたとき、プロダクトはどうなってしまうのだろうか？
例えばテストコードだ。 テストコードは AI で実装するのがもう当たり前になっている。 そして期待値の定義まですべて AI に任せた場合、その期待値の妥当性は誰が検証するのだろう？ AI が期待値を実装する場合は、実装コードを基準に期待値を決めがちだ。 だから、実装がそもそも間違っている場合、期待値も間違っていることに気付けない。 それに誰が気付けるんだろう？
今は、要件定義や設計では AI に丸投げするような事態にはなっていないから、そこが 1 つの防波堤のようになっている。 だがそれがいつまで続くのかについては、未知数だ。
人同士のコミュニケーションとか、社内の承認とか、人が絡むものはいつだって自動化と相性が悪い。 だが「自動化と相性が悪い」からといって排除するのが常に正しいわけでもない。 自動化の誘惑に打ち勝って「ここは人間が必要だ」と決められる人は、果たしているんだろうか？ 成り行きに任せて、すべてを自動化しようとする暴走が起こったとして、それを止められるのだろうか？
そんな危うさを、ふと感じた日だった。