コードは正しいはずのに、見た目が変だった話

自分で作っている宇宙アプリに、木星のまわりを回る月を4つ追加してみた時のこと。コードを書いた数字はぜんぶ正しいはずなのに、実際見てみたら「なんか変」。Claudeに実装をお願いした時こそ起きやすい、見た目の落とし穴2つを書き残しておきます。

今日のお話：木星に月を4つ足してみた

npcで作っている宇宙アプリの話です。太陽系の惑星をぐるぐる回したり、近くの星まで飛んでいったりできる小さな自社プロダクトで、ここ最近少しずつ機能を足しています。

今回追加してみたのは、木星のまわりを回っている代表的な4つの月。理科の教科書にも出てくる、いわゆるガリレオ衛星と呼ばれているものです。木星のまわりにポチポチと小さな丸を描いて、それぞれ違う速さで回らせるだけの、見た目はシンプルな機能のつもりでした。（実際の速度で動かしているので止まっている様に見えます）

※ 公転周期は概数。space-explorer ではこの実周期どおりに4衛星が木星を周回しています。

実装は、いつものようにClaudeにお願いしました。「木星に4つの衛星を追加して、それぞれ実際の周期で公転させて」とお願いしたら、ほどなくコードを書き上げてくれました。動作テストや内部チェックも別のAIが並列で走ってくれて、「実装完了・問題なし」というお墨付きまで揃って戻ってきた状態です。

※「Three.js」とは、ブラウザの画面の中に3D空間を作るためのライブラリ。この宇宙アプリの土台になっている道具です。

そうやって「できました」と言われたので、ハードリロードして自分の目で確かめてみたところ──ここから2連発のつまずきが始まりました。

つまずき①：衛星が木星の4分の1の大きさに育った

画面を開いてまず思ったのが、「実際こんな大きいの?」でした。木星のまわりに4つ並んだはずの月が、どれも木星の4分の1くらいの大きさで、まるで親子衛星みたいなバランスで並んでいたのです。

本物のガリレオ衛星は、いちばん大きいガニメデでも木星の直径の3パーセントくらい。4分の1なんてとんでもない大きさです。コードの中身を見直してもらうと、衛星のサイズ計算に、もともと惑星用に作ってあった既存の関数をそのまま流用していたのが原因でした。

その関数は「あまりに小さい天体は画面で見えなくなるから、最低でもこれくらいの大きさには見せる」という底上げの仕組みが入っていました。惑星にとっては優しい仕組みなのですが、極小サイズの衛星まで同じ底上げの恩恵にあずかってしまった結果、本来ちょこんと小さく見えるはずの月が一気に底上げされて、堂々と木星に並んでいたわけです。

関数自体はバグっていません。惑星向けには正しく動いています。ただ、衛星のような「もっと小さなもの」に同じ関数を流用すると、底上げが効きすぎてしまう。コードのレビューだけでは見つかりにくい、流用の落とし穴でした。

つまずき②：軌道の線が極太になった

サイズを直してもらったら、今度は別のところに違和感が出てきました。衛星が回る道筋を細い円で示しているのですが、その線が太い帯みたいになっていたのです。「線が太い!」と思わず声が出ました。

※「TubeGeometry」とは、3Dの空間に細いチューブ（管）を描くための仕組み。半径を指定するとその太さのチューブが描けます。

これも原因は単純で、軌道リングを描く時に「管の半径」として渡している数値が、もともと別の場所で「帯の幅」として使っていた値をそのままコピペしたものでした。値だけ見ると同じ「0.06」なのですが、帯の幅で0.06はちょうどよくても、管の半径で0.06は太すぎる──そんなズレが起きていました。

これもまたコードは間違っていません。指定した数字どおりにきっちり描いてくれています。ただ、その数字が表しているものの意味（幅なのか半径なのか）がズレていただけ。

数字は正しい、でも見た目が変

2つのつまずきに共通していたのは、「数字としては正しい」という点でした。コードを文字どおり追いかけても、計算式を検算しても、エラーは出ません。Claudeがレビューしても、別のAIが品質チェックをしても、どちらの違和感も拾えませんでした。

本物の月が木星に対してどれくらいの大きさに見えるかを、コードが「知っている」わけではありません。軌道の線がどれくらいの細さなら自然か、というのも数値では表しにくい話です。これは人の感覚でしか測れない領域なのだと、改めて気づかされました。

AIに任せきれない最後のところ

AIに頼んで作ってもらえる範囲は本当に広がっています。「木星に4つの衛星を、それぞれの周期で公転させて」と日本語で頼めば、ほどなくコードが出てきて動き出します。設計図を渡せば、ほぼ設計図どおりのものを作ってくれます。

ただ、出来上がったものを見て「なんかデカい」「なんか太い」と感じるところは、結局のところ自分で目を凝らして見るしかありません。コードレビューでもユニットテストでもなく、ただ画面を開いてしばらく眺める、という単純な工程。これがいちばん効きました。

面白いのは、この「眺めて違和感を拾う」という工程が、自分で全部書いていた頃よりも大事になったような気がすることです。昔は1行ずつ自分で書いていたから、書きながら見た目もある程度頭の中で想像できていました。今はClaudeにお願いして完成形を見ることが多いので、出てきたものを最初に見るときの感覚が、より大事な品質チェックになっています。

同じように何かをAIに頼んで作っている人がいたら、「数字は合っているはず」と頭で考えるのを一度横に置いて、まずは出てきた画面をのんびり眺めてみてほしいです。ぱっと見の「あれ?」が、いちばん信頼できるレビュアーかもしれません。