実スケールの太陽系を、
HTML 1枚で旅する

1. この制作で得た中心的な知見

実際の大きさ・距離・運動を守る部分と、人が観察しやすくする部分を、別々に設計して検証することが有効だった。遠くの惑星を見つけやすくするために惑星自体を拡大するのではなく、目印やカメラの構図を調整する。運動は天体暦に従わせ、移動速度を感じる演出は独立した粒子で補う。この区別が、後の改善をしやすくした。

以下では、実装、数値・状態試験、設計上の知見、未確認を区別して記録する。利用者から得た「UIが邪魔」「俯瞰が遠すぎる」「移動を自然にしたい」という指摘も、改善の根拠である。

2. 要望が設計を変えた過程

これは要求の変化と実装の対応を整理した表であり、統制された比較実験ではない。各段階の作業時間や主観評価の点数は記録していない。

3. 天体の運動：簡略モデルから天体暦へ

まず調べたもの

初期調査では、半径・周期・軌道要素とケプラー方程式による近似を調べた。こうした近似は軽量だが、与えられた有効期間や誤差の範囲がある。JPLの近似要素表で地球に相当する行が地球・月の重心を表す点にも注意が必要だった。JPL 近似惑星位置

最終版では、位置と速度を事前取得したJPL Horizonsの天体暦を再生する方式を採用した。惑星や衛星の運動をアプリ内で重力積分しているわけではない。相互重力などを含む元の天体暦を、保存した状態から補間している。

取得・組み込み時に固定した条件

取得条件の意味はHorizons API仕様、今回の指定値は保存済み取得記録と最終データによる。「観測者に届く光が示す位置」と「同時刻の幾何学的位置」は区別している。

惑星本体と、惑星系の重心を混ぜない

最終データでは地球中心を 399、木星中心を 599 などとして照会した。衛星の親側も同じ実体の中心に合わせ、同じ時刻のベクトルを加える。

ここで親だけ惑星系の重心にすると、衛星との位置関係へ別のずれを持ち込む。名前が似ている対象を接続する前に、物理的に何の中心なのかを確かめることは、他分野のデータ統合にも応用できる。

最終版のサンプリング間隔

太陽以外の19天体に合計79,589状態を収録した。全天体へ同じ間隔を使わず、短周期の運動や中間点での補間差を見て間隔を変えている。

p(u) = (2u³ − 3u² + 1)p₀
     + (u³ − 2u² + u)h v₀
     + (−2u³ + 3u²)p₁
     + (u³ − u²)h v₁

4. 自転・地軸・座標系で気をつけたこと

位置の公転モデルとは別に、IAUモデルの極方向と本初子午線角から姿勢を作った。NAIFの pck00011.tpc を基に、19天体の姿勢、月の13周期項、トリトンなどの極方向の周期変化を扱っている。NAIF pck00011、PCK仕様

姿勢の独立検証では、19天体×4時点の76ケースをCSPICEと比較し、行列要素の最大差は約 3.64×10⁻¹¹ だった。これは同じ姿勢モデルを正しく実装できているかの確認であり、現実の天体の向きがこの桁まで分かるという意味ではない。

ローカル根拠：rotation-guidance.md、rotation-verification.json。最終アプリへの移植後には、別の10フィクスチャでも比較している。

5. 実スケールを守りながら、近くも遠くも描く

カメラを描画原点にする

太陽系の広がりと、地球表面の近接観察では必要な桁が大きく異なる。JavaScript側の世界座標は倍精度で保持し、各フレームでカメラの位置を差し引いた値を描画へ渡した。

この方法は、巨大な絶対座標の近くで小さな違いを扱う負担を減らす。対数深度バッファと、近くの天体までの距離に応じたnear平面の調整も併用した。座標精度の問題と、前後関係を判定する深度精度の問題は別なので、一方だけで全てを解決したとは考えない。

惑星を拡大せず、目印を別に描く

実比率の全景では、多くの惑星は1画素より小さくなる。天体の球は実際の代表半径のままにし、名前や点を観察用の目印として使った。土星の主な環も、約74,700〜136,800 kmの半径に収めている。

天体の半径は球としての代表値で、扁平率や山の高低までは表していない。物理量の取得元はJPL 惑星物理量と衛星物理量。環の画像や補助光は観察表現の層に置く。

単一HTMLの利点と費用

Three.js、pako、天体暦、画像、地図、BGMを内蔵し、初回起動も外部読み込みなしで動かす構成にした。配布と再現は簡単になる一方、画像とデータを展開するメモリや初回処理は必要になる。BGM追加後の20.28 MBというファイルサイズを、そのまま実行時メモリ使用量と見なすことはできない。

6. 地球儀：小国は形だけで探させない

地球画像はNASAのBlue Marble、国境と日本語名はNatural Earthの1:50mデータを使った。これは過去の観測を合成した地図であり、現在の雲や都市の状況を示すライブ画像ではない。NASA Blue Marble、Natural Earth

国境データのポリゴンと穴を保持して座標を小数4桁へ丸め、242の国・地域を扱った。242は主権国家の数ではない。属領・係争地域なども含む地図要素の数である。

小さい国や島は、画面上の形だけでは選びにくい。日本語・英語名の検索、国名の目印、対象へ近づく操作を組み合わせた。元データのラベル点のうち10点は対象の領域外だったため、領域内へ補正し、全242点について穴を除く対象領域内にあることを確認した。

地軸と自転を反映すると、国の緯度経度をそのまま世界座標へ置く方法は使えない。国を選ぶときは地球の姿勢を掛けてカメラの方向へ変換し、クリックで国を調べるときは逆回転で地球のローカル座標へ戻している。

見つけられることと、海岸線が精密であることは異なる。小国へのアクセスを改善しても、縮約された地図の細部が増えるわけではない。

7. 俯瞰を「世界全体」から「今回の移動」へ

最初の経路は、一度太陽系全体を見渡す位置まで離れるものだった。ところが地球から月のような移動では、無関係な外側の天体まで収めるために、必要以上に遠くへ引いてしまう。

変更後は、移動元Aと移動先Bの中点を基準とし、A→Bを画面の横軸にする。2天体が同じ奥行きで左右へ並ぶため、その間隔と大きさから俯瞰距離を決められる。天体は動き続けるので、この枠も毎フレーム更新する。

M  = (A + B) / 2
hₓ = tan(f/2) × a × 0.78
hᵧ = tan(f/2) × 0.75
D  = max((L/2 + R√(1+hₓ²)) / hₓ,
         R√(1+hᵧ²) / hᵧ)

手動で見る「太陽系全景」は残している。全体を把握する操作と、対象間を移動する操作は、別の構図を持てるという整理になった。

8. 滑らかな移動：位置・視線・傾きを分ける

距離を対数で、進行を五次式で補間する

近接距離と惑星間距離を直線的に混ぜると、出発直後に天体が急に小さくなりやすい。そこで半径方向の距離を対数で補間し、進行率には、両端で一階・二階微分が0になる五次の補間関数を用いた。

最終経路は、進行率0〜0.36が出発、0.36〜0.58が俯瞰、0.58〜1が接近。俯瞰枠の傾きを旅全体で少しずつ変え、区間ごとに別の停止姿勢へ切り替わらないようにした。手動の旅は約18秒、ギャラリーは選んだテンポに従う。

五次式を使っただけで、アプリ全体の加速度が連続だと証明したわけではない。天体暦の補間点、画面のリサイズ、衝突補正、カメラ枠の選択などは別に考える必要がある。今回確認したのは、代表的な接続点の数値的なつながりである。

通り過ぎた中点を見続けない

カメラが目的地へ進むと、中点は後方へ回る。それでも中点そのものを注視点に使うと、視線が短時間に大きく回り得る。最終版は、俯瞰時の方向から、目的地を見る方向へ球面上で補間する。巨大な距離を持つ注視点同士を直接混ぜない。

到着方位は予測した到着時刻の天体姿勢から決め、旅の間は固定する。これにより、地球の自転を追っていたカメラが、到着直後に突然追従をやめる不連続を避けた。ギャラリーの観察中の周回も、出発前と到着直後に速度を緩めている。

見つかった反転：Quaternionでも自動的に滑らかにはならない

滑らかさを改修する途中の試作では、出発時の姿勢と、その時点の俯瞰姿勢をQuaternionの最短経路SLERPで混ぜていた。木星→イオを天体時刻1日/秒で試すと、ある50 msで約116.956°回転した。独立した別時刻の再現では、約178.218°の変化も見つかった。

原因は、動く俯瞰姿勢との内積が0をまたぎ、「どちら回りが最短か」が途中で切り替わったことだった。単に隣り合うQuaternionの符号をそろえるだけでは、固定した出発姿勢との相対回転が180°をまたぐ問題を解消できない。

最終版では、視線を運ぶ基準姿勢と、視線まわりのロール角を分けた。前の基準姿勢を新しい視線へ平行輸送し、目標ロール角は前回値に続くよう角度をアンラップする。表示したロールを基準姿勢へ戻さないことも重要だった。戻すと回転を二重に蓄積してしまう。

base = transport(previousBase, forward)
pairRoll = unwrap(angleAroundForward(base, pairFrame), previousPairRoll)
endRoll  = unwrap(angleAroundForward(base, arrivalFrame), previousEndRoll)

出発: roll = s(u) × pairRoll
俯瞰: roll = pairRoll
接近: roll = (1−s(u)) × pairRoll + s(u) × endRoll

view = rotationAround(forward, roll) × base

9. 光の軌跡：速度感を加えて、天体は守る

光跡は天文シーンとは別のCanvasに描いた。実在する宇宙塵の密度や相対論的な光学現象を再現するものではなく、進行方向と速度を伝える演出である。

天体時刻と、カメラの移動速度を混ぜない

天体時刻を早送りすると、カメラが親惑星について行くだけでも世界座標は大きく変わる。その差分をそのまま「ワープ速度」とすると、旅行していない移動まで粒子へ混ざる。

そこで、同じ天文時刻に固定した経路上で進行率だけを少し前後へ動かし、カメラの移動速度を差分で求めた。小さな数値表示が定量情報を担い、軌跡は方向と速さの印象を補う。

画面端の球は、中心と同じ半径でマスクできない

最初の保護マスクは、カメラからの距離を基に画面上の半径を求めていた。しかし画面端では透視投影の広がりが変わり、余白を少し増やすだけでは輪郭を覆いきれない場合がある。

最終版は、球へ接する線から横・縦の投影範囲を求め、それを囲う保守的な円を作った。土星は環まで含む外接球で保護する。複数の消去領域は destination-out で重ね、重なったところが再び見えるマスクの穴も避けている。

ここでの「守る」は実装上の設計を指す。Canvasの実ピクセルの合成結果や、端末で見たときの演出の強さは、今回のモック試験では評価できていない。

10. UI：情報と操作で、表示時間を変える

通常表示では、目的地・天体名・移動開始の小さなバーを入口とし、詳細・操作・目的地一覧は必要なときだけ開く。複数の大きなパネルが同時に視野を占めないよう、開閉を排他的にした。

ギャラリーでは天体名、距離、旅の段階、周回番号などを画面の端へ残し、操作ボタンは約4秒で隠す。タップは操作の再表示に使い、ギャラリーを止めない。一時停止中とキーボードで操作中は隠さず、終了ボタンとBGMの♪は常にアクセスできるようにした。

全画面への切り替えも試みるが、利用環境により許可されない場合がある。アプリ自身が開始した全画面だけを終了時に戻すよう管理した。画面の向きが変わったときには、UIだけでなく天体の観察距離も調整している。

操作を隠すことと、状況が分からなくなることを分ける。この考え方は、映像鑑賞、顕微鏡・地図ビューア、展示用の自動デモにも転用できる。

11. BGM：音質を作り込み、再生中の処理を減らす

オリジナルのオルゴール三重奏を、残響まで含めた80秒の音源として事前生成した。宇宙の壮大さを感じること、3つの音域が重なること、負荷は低めで音質を重視することが追加要件だった。映画『インターステラー』は雰囲気の参考として挙がったが、映画の音源や旋律を素材として取り込まず、今回のアプリ用に音符から作った。

作曲：3つの役割と、4つのまとまり

曲名は「光の間を渡る / Across the Quiet Light」。6/8拍子、付点四分音符＝48、32小節で構成する。八分音符は約0.4167秒、1小節は2.5秒なので、全体は正確に80秒になる。ニ長調とロ短調の響きを中心に、9度などの付加音と休符で広がりを狙った。これは作曲上の意図であり、聴感評価の結果ではない。

合計352発音。三重奏とは譜面上の3パートを指し、同時に鳴る音を3音へ制限するものではない。打音の余韻は次の音へ重なる。

音作り：金属の立ち上がりと、減衰する空間

実録サンプルではなく、Python・NumPy・SciPyで音を合成した。基音に整数倍付近の成分と非整数倍の成分を重ね、音域ごとに配合・減衰・定位を変えている。高い成分を早く減衰させ、短い打撃音と控えめな木箱の共鳴も加えた。実在するオルゴールの振動を測定して同定したモデルではない。

残響も事前に合成する。左右で異なる初期反射と、帯域ごとに減衰を変えた拡散残響を用意した。残響のインパルス応答は7秒で、設計上の減衰時間は低い帯域で約5.5秒、高い帯域で約2秒。金属音の輪郭を残しながら空間を広げる狙いがある。最終段では低域・高域を整え、微小なノイズを加えるディザ処理を経て16bitへ量子化した。

ループ：最後の音だけでなく、残響も先頭へ戻す

80秒で波形を切ると、その時点で残っている減衰音や残響が失われる。そこで、各発音の80秒を越える部分を先頭へ足し戻し、残響を畳み込んだ後のはみ出しも同様に折り返した。フィルターへは末尾の1秒を先に通し、毎周の先頭で内部状態がゼロから始まる影響も抑えている。

毎周フェードアウト・フェードインを掛ける方式は採用していない。曲の和声的な帰着と、波形・残響の接続を別々に用意した。ただし、数値的に接続を確認したことと、人に継ぎ目が聞こえないことは同じではない。

再生：重い音作りを、3D描画と同時に行わない

音源は48kHz・16bit・ステレオのFLACとしてHTMLへ内蔵した。最初の♪操作で音声処理を作り、デコードを一度行った後は、AudioBufferSourceNode → GainNode → 出力という小さな構成で繰り返す。再生中のJavaScriptによる音符の予約や、音ごとの合成・残響計算は行わない。

調査では、AudioBufferSourceNodeのループ機能と、一つのノードにstart()を繰り返し呼べない点を確認した。本実装はノードを保持し、音声コンテキストの休止・再開で再生位置を保つ。MDN: AudioBufferSourceNode

decodeAudioData()は復号時に音声コンテキストのサンプルレートへ変換するため、ループ終端は固定のサンプル数から計算せず、復号後のbuffer.durationを使った。MDN: decodeAudioData()

圧縮ファイルを小さくすることと、再生時のメモリを小さくすることは別である。本方式は再生中の合成処理を省く一方、曲全体をメモリへ持つ。音声バッファの大きさは出力サンプルレートでも変わる。30.72 MBは端末で測ったピーク値ではなく、デコード中の一時領域や3D描画のメモリも含まない。CPU使用率・消費電力の比較測定はしていない。

操作と状態管理：非同期の準備が、消音を取り消さないようにする

作曲データは完成HTMLのmusicScore、再生成用のPythonコードはmusicRenderSourceに収録した。後者はブラウザで実行されない保存用テキストであり、Python・NumPy・SciPy・FFmpegを使う別環境向けのコードである。音声の検証範囲は次節にまとめる。

12. 何を、どこまで確認したか

天体暦の補間差

保存点そのものではなく、別に照会した中間時刻のHorizonsと比較した。下の値は、それぞれの標本で得た最大位置差であり、年間全時刻での上界でも、実天体との絶対誤差でもない。

旧版と新版、方式間で標本数・標本時刻が異なる。この表から厳密な改善倍率や方式の順位を決めない。根拠：planet-validation.json、planet-chebyshev-validation.json。

衛星は各24点、合計192点。これは親惑星に対する相対位置の補間差で、親惑星の補間差を含めた太陽中心位置の保証ではない。根拠：satellites-summary.jsonと各衛星の取得・検証記録。

カメラの反転と、その後の測定

会話内に残る実行結果と再現報告による。条件とコードが異なるので、これらを一本の改善率や同条件の性能曲線として扱わない。4.787°も人間の快適性を示す閾値ではない。

天体・移動の数値・状態試験

check-solar-v4.cjs は、実際のThree.jsの数学処理を使い、描画器・DOM・Canvasを代用品に置き換えたNode試験である。BGM追加前の光跡版で記録された結果は次のとおり。BGM追加時には天体・移動コードと天文データがその版から変わっていないことを別途照合した。

BGMの符号化・ループ・操作状態

以下は保存済みの音源検証結果、コードレビュー、BGM追加時のモック試験・配布ファイル検査による。音楽の好ましさや、端末から出た音の評価とは区別する。

dBFSはデジタル信号の最大値を基準とする表記。表の音量は音源そのものの値であり、アプリの初期音量40%や端末側の音量を適用した出力の測定値ではない。ループ境界の比較は異常に大きな段差を調べる材料であり、不可聴性の証明ではない。

未実施：実ブラウザ／GPUの表示試験、実ピクセルでのマスク評価、Androidでの全画面動作確認、FPSやメモリの測定、長時間連続運転、操作性・酔いやすさの定量評価、BGMの実聴、実ブラウザでの音声出力、端末ごとの復号・再開・継ぎ目、音楽の主観評価。数値試験の成功は、これらの代わりにはならない。

13. 人間とAIの協働として持ち帰れること

今回、人間からの観察は、単なる好みの指定にとどまらなかった。「俯瞰が遠い」という指摘で、カメラが収めるべき対象が太陽系全体から2天体へ変わった。「視線も滑らかに」という指摘で、位置だけを検証していた設計から姿勢の連続性へ検証が広がった。

AI側では、データ取得、数式化、実装、読み取りレビュー、数値試験を分担した。ただし読み取りレビューだけでは、動く目標が180°をまたぐ反転を見つけきれなかった。フレーム間の姿勢差を測り、独立した条件でも再現して、初めて分岐の機構がはっきりした。

ここから得た実務上の知見は、実装を作ることに加えて、何を確かめればよいかを作り、その確認結果の意味も点検することにある。今回の制作だけから、人間とAIの協働方式一般の優越性を証明したとは言わない。

14. 残っている限界と、次に確かめるなら

モデルの限界

• 太陽・8惑星・8衛星・3準惑星を収録する。全ての衛星、小惑星、彗星などを網羅していない。
• 天体暦は2026年の収録範囲に限定。光の到達遅れや相対論的な飛行映像は再現しない。
• 地球の姿勢はUT1観測・章動・極運動をそろえた精密地球姿勢ではなく、月もDEの高精度な姿勢モデルではない。
• 太陽や巨大惑星の表面を剛体的に回すため、実際の差動回転や雲の動きを予報しない。
• 地球以外のテクスチャ経度は厳密に較正していない。未収録の衛星表面は模式色。冥王星画像の黒い領域には観測の欠落がある。
• 軌道ガイドはその瞬間の位置・速度とGMから作る接触楕円で、将来の正確な軌跡ではない。
• 小国を検索できても、地図の縮約を超える地形精度は得られない。

BGMで残る確認

金属音の硬さ、残響と旋律の釣り合い、80秒の反復が鑑賞を邪魔しないかは未聴取である。ヘッドホン・スマートフォンのスピーカー・モノラル再生での印象も未評価。ロスレス形式は量子化後の波形を保つことを意味し、合成音の好ましさや実楽器への忠実度を保証しない。

次に優先する確認

1. 実機での鑑賞：スマートフォンの縦・横、通常・全画面で、天体名と光跡が読みやすいか。
2. BGMの実聴と復帰操作：音の強さ、つなぎ目、♪の連打、タブ切り替え後の立ち上がりを実端末で確かめる。
3. 負荷の測定：起動時間、ピークメモリ、長時間のフレーム時間、BGMの有無によるCPU・電力の差。描画回数をFPSと読み替えない。
4. 同条件の比較：固定した日時・経路・速度・画面比で旧版と新版を比較し、角速度と主観評価を併記する。
5. 試験範囲の拡張：全ての天体間の組合せや極端な画面比、途中での操作変更を、必要な範囲から追加する。
6. 天文データの拡充：対象年や天体を増やす際は、ファイル容量・補間間隔・比較標本を一緒に見直す。

これらは本書で整理した候補であり、今回すでに実施した作業には含めない。

15. 対象ファイルと根拠記録

後から別の版と混同しないよう、この記録が対象とする完成HTMLを次の値で識別する。

16. 出典・素材

数値や素材の外部出典と、今回の実装で得た測定値を分けた。NASA/JPLの出典を挙げたことは、このアプリの表示や精度をNASA/JPLが保証したことを意味しない。

本書の補間・角度分岐の図は説明用に作成した。BGMの波形図は完成FLACの復号データを描いたものである。いずれもアプリのスクリーンショットや端末出力の録音ではない。本書自体も画像・スタイルを内蔵しており、出典リンクを開く場合を除き外部通信は不要。