この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。架空のデータとブラウザの操作を使って、Three.jsの用途、仕組み、失敗時の観察ポイントを学びます。実在のサービスや個人情報へのアクセスは行いません。
検証ステータス： 2026-10-30の既存審査で、固定コミットのJavaScriptとNode.js構文検査の成功を確認。ブラウザのWebGL描画・CDN配信・GitHub Pagesでの操作は未検証です。期待結果は実測ではありません。
| 項目 | 内容 |
|---|---|
| 対象 | Chrome/Edge/Firefox等の現代的なブラウザ（実機互換性は未確認） |
| 使用ライブラリ | Three.js（教材内バージョン: 0.180.0） |
| 費用 | デモのソース自体に有料APIは不要。通信料金や利用条件は環境に依存 |
| データ | ページ内の架空データ。認証情報・位置情報・企業データ不要 |
| 学習操作 | 球体の回転速度をスライダーで変える |
なぜこの技術を試すのか
Webサイトに平面的な画像ではなく奥行きのある展示を置きたいとき、3Dエンジンは画面の作り方そのものを変えます。例えば科学館の展示や製品の回転プレビューでは、同じ物体を別の角度から見せる方が、十枚の静止画を並べるより形状を理解しやすくなることがあります。ただし3Dで見せることが目的ではありません。何を理解させたいかを決めてから、平面画像より得るものがあるか判断する必要があります。今回の惑星は天文学的な正確さを主張するモデルではなく、座標・カメラ・レンダリングの教材です。
動くサンプルを作るときは、見た目が動いたという事実だけで終わらず、「どの入力がどの変数を変え、どの処理が描画を更新したか」を区別する必要があります。今回の教材では、その変化を画面に明示します。実際のサービスへ取り込むときには、認証や保存の処理を別途設計してください。
まず試す：ライブデモと期待する結果
最初に図形を表示し、スライダーを左端の0へ移して回転を止めます。次に1.5へ上げてから、細かい線の位置が変わる様子を観察してください。速さを変えても球体の大きさや視点距離が突然変わらないことを見ます。ChromeやEdgeの開発者ツールでConsoleとNetworkを表示してから試すと、WebGLの利用可否やモジュール取得失敗を区別できます。もし画面が真っ白でステータスが更新されない場合は、JavaScriptの読み込み段階で失敗している可能性があります。
操作の前に確認すること：公開デモが開けない場合のローカル手順
公開デモのURLは公開・動作未確認です。開けない場合は、固定コミットのHTML本体とJavaScript本体をGitHubで開き、それぞれRaw表示からindex.htmlとapp.jsの名前で同じ新規フォルダへ保存します。READMEだけを保存しても画面は動きません。
Python 3を利用できるPCで、保存した2ファイルが見えるフォルダを開き、そのフォルダを作業ディレクトリとしてターミナルを起動します。Windowsではエクスプローラーのフォルダのアドレス欄に
powershellと入力して起動できます。Windowsなら
py -3 -m http.server 8000 --bind 127.0.0.1、Linux/macOSならpython3 -m http.server 8000 --bind 127.0.0.1を実行します。これはローカルHTTP配信のためで、実行結果を確認した操作ではありません。Pythonがない場合は公式資料にあるローカルサーバー方式を選びます。同じPCのブラウザで
http://127.0.0.1:8000/を開きます。最初の文字表示はREADY: JavaScriptを読み込み中、スクリプト初期化がそこまで進むとRUNNING: 3Dを表示になる設計です。RUNNINGの表示だけでは、WebGL描画成功や画面の見え方まで証明できません。実際に球の線と動きを目視し、ConsoleとNetworkも確認してください。スライダーを
0にすると回転角の更新量がゼロ、1.5なら増える設計です。値を戻して比較し、終了するときはサーバーを起動したターミナルでCtrl+Cを押します。
file://でHTMLを直接開くとESモジュールの読み込みがブラウザの安全制限により失敗することがあります。また、ローカルサーバーで開いてもThree.js本体は第三者CDNから取得するため、ネット接続や組織の通信制限に依存します。CDNへ実ファイルや入力値を送る処理はこの教材にはありませんが、ライブラリ取得の通信は発生します。
仕組みの全体図
flowchart LR
A["入力やクリック"] --> B["イベントを受ける"]
B --> C["Three.js のAPI"]
C --> D["状態と描画を更新"]
D --> E["見た目と文字で確認"]
この図は学習用の概念図で、ブラウザ内部の実装やネットワーク通信の詳細を表したものではありません。ライブラリが何でも「操作がどの変数へ届くか」を追いかけることは共通です。
どう動いているのか：APIを読み解く
シーンは3D空間の登場人物をまとめる入れ物、カメラは観察者の位置、メッシュは形状と表面の材質の組み合わせです。SphereGeometryは頂点から球体を構成し、MeshStandardMaterialは照明に反応する見え方を決めます。物体をsceneへ追加しただけでは画面は更新されません。renderer.renderでカメラから見た結果をcanvasへ描画します。回転の角度を単に毎フレーム固定量だけ加算すると、PCの描画速度によって回転の速さが変わります。そこで前回フレームからの経過秒を用いる設計にします。
最小コードの読み方
const scene = new THREE.Scene();
const geometry = new THREE.SphereGeometry(1, 32, 24);
const material = new THREE.MeshStandardMaterial({ color: 0x48bcb7 });
const planet = new THREE.Mesh(geometry, material);
scene.add(planet);
上記はAPIの要点を取り出した抜粋です。コピーして単独実行する完成ファイルではありません。動かすためのHTMLと実装一式はDaily Code側のREADME／デモファイルで確認してください。どの関数がHTML要素を選び、どの行が数値を更新するかを追い、既知の架空値で試します。
一条件だけ変更して比較する
実際のapp.jsのnew THREE.MeshStandardMaterial({color:0x48bcb7,wireframe:true})でwireframe:trueをwireframe:falseへ変更すると輪郭線中心の表示が面の塗りつぶしへ変わります。三角形の網目が分かりやすいのは前者ですが、表面の質感を見せるなら後者が向きます。近くにライトを置く位置を変更すると、陰影がどこに現れるかも変わります。一方、ライトを追加しても球体の3D座標が動くわけではありません。この「モデルの位置」「材質」「光」「カメラ」が独立している点を区別することが、複雑な3Dアプリのデバッグにもつながります。
比較の手順は、最初の値を記録し、一か所だけ変更して、結果が想定の部分に現れたかを確認することです。入力を一度にいくつも変更すると、何が影響したか分からなくなります。変更前へ戻す操作まで含めて検証してください。
失敗したときにどこを見るか
WebGLが無効な環境、端末のメモリが少ない環境、企業ネットワークでCDNを許可していない環境では動かない場合があります。またウィンドウを小さくしたときにcanvasだけ縮めてもカメラのアスペクト比が古ければ見た目が変形します。実用版ではresize処理と画素密度の上限を用意してください。大量に新しいGeometryやMaterialを作り続けるとGPU側の資源を消費するため、不要になったらdisposeすることも重要です。
| 観察した状態 | 切り分ける点 | 対応の例 |
|---|---|---|
| 画面が初期状態から変わらない | スクリプト取得・初期化・イベント登録 | Console / Network / scriptタグを確認 |
| 表示が変わるが意味が合わない | 入力値・配列・単位・更新対象 | 値を固定して一条件ずつ確認 |
| ボタンを押せない | セレクターとDOM生成順序 | idが一致するかHTMLを確認 |
| 一部の端末だけ動かない | ブラウザ機能、権限、CDN、性能 | 端末とバージョン、再現操作を記録 |
ブラウザ内でのエラーと公開Webサーバーの障害は別です。前者は開発者ツールのエラー内容、後者はHTTPレスポンスやアセットの配信条件から調べます。未知の失敗を成功と表現しないことが、技術メモの信頼性を高めます。
業務・学習への応用
機器の形状確認、展示、製品の回転プレビュー、立体配置の教材に応用できます。正式な設計図や寸法保証の代用にする場合は、縮尺、単位、カメラ投影、色管理、端末別の描画品質を別途検証しなければなりません。資料作成では「触れると理解が増す情報」だけを3Dにし、単純な表や説明はHTMLで残す方が読み上げ・印刷・検索に適します。
導入前に決めること
読者へ公開するとき、表示したデータがどこから来るか、誰が変更できるか、画面へ残る情報の種類、ライブラリ更新時の確認項目を決めます。今回のデモにはログインもサーバー保存もありません。そこで運用機能を追加する前に、まず「想定どおり表示される最小部分」と「実務上の信頼性・権限・バックアップが必要な部分」を区別することを勧めます。第三者CDNは外部通信のため、企業ネットワークで許されるか事前確認が必要です。
別方式と比較する
| 方式 | 向く場面 | 注意点 |
|---|---|---|
| Three.js | 球体の回転速度をスライダーで変えるなど目的に合う場面 | 依存ライブラリの更新・利用条件の管理が必要 |
| ブラウザ標準API | 小さな機能を自前で作る | 仕様や互換性を自分で確認する |
| 静的画像・表 | 操作を必要としない説明 | 状態の変化をその場で体験できない |
ライブラリは必要なときに選ぶ道具です。何を達成したいかと学習コストを合わせて比較します。「ライブラリを入れること」を目的にしない方が、小規模なページでは保守しやすくなります。
GitHubサンプル
ブログ本文は背景や考え方、Daily Codeは実行・改造するためのコード、という役割を分けています。外部サービスへ投稿・保存するAPIは含めません。
公式情報・一次情報
資料確認範囲： 2026-10-30にThree.js公式の導入・材質設定とMDNのローカルサーバー資料を再確認。リンク先の将来の変更やすべてのCDNアセット応答まで保証するものではありません。
検証範囲の補足
Daily Codeの固定コミットにあるJavaScriptの静的構文検査は確認済みですが、各ブラウザでの描画・外部CDNの実応答は確認していません。実際に試すときは、本文のローカルサーバー手順とConsole・Networkによる確認を利用してください。
