はじめに
事の発端は、2026年2月11日。SecondLife内のあるユーザから、Clusterというものを教えてもらった。どうやらVRoid Studioというアプリで自作のアバターで入れるメタバースらしい。
というわけで、まずはVRoid Studioをインストールして自分のアバターを作った。今のアイコンである。例にもよって、未来感のある画像の上にELFバイナリをオーバーレイさせた背景画像を作り、その上からアバター画像を乗せた。で、それから数時間後、Clusterに入り速攻でデフォルトアバターを上書きしてこのアバターにしたわけだが、ふとひらめいた。
VRoid Studioで作ったアバターをSecondLifeでも使えるようにできないか？ と。
まずはVRM形式について調べることにした。どうやら、glTFのサブセットらしい。また、glTFはJSONらしいということもわかった。VRMの正体がglTFということは、理論上、去年の６月以降のSecondLifeでそのままアップロード可能なモデル形式ということになる。試しに作成したVRoidアバターをBlenderに読み込ませて、glTFにしてSecondLifeに読み込ませたらシェーダーの違いこそあれ、ほぼ完璧な形状でSecondLifeに取り込むことができた。
さて、ここで話は一旦９か月前に戻る。SecondLifeを始めたのは2023年だが、私はSecondLifeで最も利用者数の多いビューア（クライアント）であるFirestormの翻訳が中途半端だった事に業を煮やし、３か月かけて全部翻訳し直して、Firestorm公式リポジトリにプルリクをし、それが取り込まれて公式日本語化スタッフになり、以降自分がメンテナンスをしている。そのときに「ポーザー」という機能があったのを思い出した。
このポーザーとは、バーチャルワールド内で自分のアバターのボーンを動かすという機能である。そこに表示された、ボーンのリストを見て、思いついたのだ：
VRMアバターのボーンをSecondLifeのこれらのボーンに変換すればい
だったら、ボーンを最初にSLのものに差し替えればいいじゃんと思った、そこのあなた、そうするとVRoidで身長とかを調整すると、それに合わせてボーンを作り直さなければならなくなってしまう。換骨奪胎するような真似は避けたいと思った。
…ボーンなだけに（ｗ
設計
SecondLifeは古いメタバースなので、おそらくボーン名の変更だけでは、正常にボーンが反映されなかったりねじれなどが発生するだろう。すると、まず最初にやるべきことは「何を行い、何をしないか」を明確に決めることだった。
まず、SecondLifeにはシェイプという機能があり、これを使うことでアバターの身長を変えたり体型や顔などを変更することができる。しかし、VRMの場合、おそらく服を含めて、完成したアバターを持ってきたいという需要のほうが多いと思われるので、シェイプ追従はしないことを決めた。
次に決めたことは、SecondLifeシステムアバター（リンデンアバター）と同じボーンの仕様にし、後から追加されたBENTOはという拡張ボーンの仕様は、原則サポートしないという方針にするということだった。BENTOは尻尾や耳、翼などのボーンを定義するものであるが、最初からこれらをサポートすると、問題の切り分けが大変になることが予想つく。そこで最低限のボーンと、指だけをサポートすることを優先することにした。
髪の毛の揺れや胸の揺れなどと言ったスプリングボーンは、SecondLifeには仕様がないので当然サポートしないし再現もしない方針。
あと、テクスチャサイズは1024x1024に抑えるように指示を出した。これ以上の大きさにするとアップロード費用が１枚辺りL\$ 40になる。仮に10枚のテクスチャがあるとすると1024までならL\$ 100で済むが、これを越えるとL\$ 400になってしまう。画像の縮小処理はlanczosで行い、それをZopfliで圧縮すれいいだろう。（いい加減）
まぁ、リンデンドルの価値は、L\$ 1000が日本円でだいたい450円ぐらいなのでほぼ無料だが…。
アプリケーションは、以前Drop Compress Imageを作るときに使った技術スタックをそのまま流用することにした。すなわち、Vue + Vuetify + Vue-i18n + Tauri + Rustである。これにより、最初から多言語かつマルチプラットフォーム前提となった。
こうして、AIとバイブを壁打ちしながらコード生成AIに実装させるための計画書を作った。2026年2月20日のことである。
クォータニオン？３次元のベクトルに１次元追加して計算することで計算が楽になる？？
全然わからん（ｗ
交流回路における、電力と電流の位相差や力率を複素数を使って計算するみたいなもんか？みたいに、まともに本質を理解しようともせず、これまでの自分からは信じられないくらいいい加減で、「計算や具体的なアルゴリズムは全部生成AIに丸投げすればいいや」という完全舐めプモードで開発を始めた。
うん、これぞ、まさにバイブコーディングだね。…と、この当時は思っていたのだ。
実装
バイブコーディングで作成した計画書（PLAN.md）にかかれている内容をClaude Codeに読み込ませて、そのまま実装した。で、アップロードしてみると…。
まぁ、ちゃんと動くわけがない。頭の位置は明後日の位置にあるし、腕もなんだかねじれている。仕方がないので何度もプレビューを確認し、生成AIをこき使って改善要求をした。
何度か繰り返しているうちにここまでできた。
頭の位置がおかしいがとりあえず、インワールドにアップしてみた。
どうやら、頭が前方にずれてしまっているようだ。ちゃんと動いていないが、このバグは裏を返すとVRMはボディとヘッドに分離可能であるということである。バグではあるが、後日ヘッドを分離して単体でエクスポートできる仕様として逆利用しよう。
再びバイブコーディング。頭の位置は合うようになった。
SL はジョイント位置オーバーライドを「親チェーンを辿って相対位置計算」する仕様です。Face/Hair が独自スキン（joints=[mHead] のみ）を持つ場合、親の mNeck が IBM に含まれないため SL がデフォルト骨格の mNeck 位置で計算し、全く違う値が出ていました。
とのこと。これにより頭が明後日の方向にあるバグはなおった。しかし、体はあいかわらず、ねじれたままだ。
Blenderで確認した限りではボーンのジョイント位置はあっている。
とすると、何らかの理由でねじれていると考えられる。AIの計算が正しいと仮定した場合、SecondLife特有の何かの法則性を持ってねじれている可能性が高いと見た。
そこで、実際、SecondLifeでアバターを作っている専門家に聞いてみることにした。解決策はあっさりとしていて、「Blenderで向きをリセットしてエクスポートすると治るよ」とのことだった。早速Blenderで動かして確認したところ解決したのでAIに指示した。
SL BVHのクォータニオンは「旧-Z前方空間」を前提に設計されているが、+X前方のGLBに直接適用するとX軸回転が横揺れに見えてしまう。
どうやら、SecondLifeにおける前方向とVRMなどにおける前方向の解釈が違うことで発生していたらしい。
この後ソースコードを見直し、全てのロジックが同じコード内に入っているようだったので、今後の保守性を考慮し、テクスチャの縮小処理、クォータニオン変換処理、ボーン名リネーム処理など、コードの責務に応じて分割してくれと命令した。
直感的に、長いコードって処理時間もさることながらコンテキストも浪費しそうだしね。
アルファ版リリース
こうして、リポジトリ開設から３週間かけてバイブコーディングで舐めプしてできたのがVRM2SLである。
対応機種はmacOS, Windows1, Linux。対応言語は、英語、仏語、日本語、韓国語、中国語。
そのままだとアレなので、Geminiにプロジェクトのリポジトリの看板画像のイラストを描いてもらった。このプロジェクトの趣旨は、「リッチなVRMをローファイなSecondLifeに持ち込む」ことなので、Vaporwaveでいう「ローファイの美学」に通じるコンテキストだと考えられる。
しかし、自分でデザインをするのが面倒だったので、この説明をGeminiに話して「Vaporwave風にしてくれ」という指示で丸投げした。
いい感じに仕上がったのでそのまま採用。
で、ちょびっとUIを整えて3月20日に最初のアルファ版がリリースできた。AIの出力したUIで、UXは全く考えていないが、おいおい直すとしよう。申し分ナシ程度にThree.jsによるプレビューと、リンデン公式の歩行モーションのテストができるようになっている。この他にも、指のボーンがおかしいなど未解決の問題は多いが、VRoid Studioで作ったアバターがほぼそのまま使える のは間違いなくメリットだろう。
あと、予想外だったのは複雑度がめちゃくちゃ少なかったところ。一般的なSecondLifeのアバターは5万前後だが、この変換したアバターは7000前後と１桁も少ない。このため、SIMにも優しく、アップロード費用は、L$ 165とSecondLifeで一般的な服を買うより安いコストで済むことになった。
SecondLifeはスプリングボーンの仕様がないので、髪の毛や胸などの揺れはサポートしていないが、Clusterのようなアップロード時の頂点数やメッシュの丸め込み処理はない上に、テクスチャ解像度は最大2048まで使えるので、理論上解像度が512pxに制限されるClustorよりも高品位ということになる。
SecondLifeの許容される最大頂点数は66535だが、VRoidの頂点数は30000ぐらいなので、まだまだ十分余裕がある。VRC用のアバターよりも高詳細かもしれない。
ちなみに、OpenSimでも問題なく使えた。OpenSimとはSecondLifeのOSS実装で互換性がある。日本だとJOGridが有名。繋いでいる人が少ないが、最大の問題点であるアバターや服の種類が少ない問題も解決できるだろう。
こちらの場合、アップロード料金は無料である。自分でサーバーを立てれば、本家のSecondLifeよりも広大なSIMが持てるので、今後話題になることがあるかもしれない。
これはJOSGridにあるアビス海文台を、本ツールを用いて変換した重音テトアバターで訪問したときの画像。最近、南鳥島で海底資源の採掘で話題になっている「ちきゅう」を体感できる。（このSIMの作者は10年ほど前に癌で他界したようだが…。）
SecondLifeにも同名の施設があるので、興味がある人は行ってみると良いかもしれない。
https://maps.secondlife.com/secondlife/Farwell/75/79/95
「それ、バイブコーディングちゃうで、仕様駆動開発（SDD）や」
完成したアプリを早速宣伝した。で、このことを他のバイブコーディング実施者に話してみたんだが、どうも話が噛み合わない。曰く、「なんで設計書書くの？」である。いや、だって最初に何を行い、何を行わないかを決めないと、いつまで経ってもゴールが見えないと思うんだが。
それに、AIがいくら万能だからといって、何でもできるということは、自由度が高いではなく、どうとでもなってしまうことだから、より一層計画練らないと、その時は良くても将来的にああしたい、こうしたいとかがあったときに軌道修正が大変になる。そういう事を話したが、みんなキョトンとしている。
どうも、彼らの考えとは相容れられないらしい。もやもやしていたので、Google検索でバイブコーディングについてAI検索で聞いてみると
はい、それも立派なバイブコーディング（Vibe Coding）の一種、あるいはその進化形と言えます。
「バイブコーディング」という言葉自体が、厳密な定義というよりは「AIとの対話でノリよく作っていくスタイル」というニュアンスを含んでいるため、やり方は人それぞれです。特に、仕様書（Plan.mdなど）をAIと一緒に作るプロセスは、むしろバイブコーディングを成功させるための「賢い戦略」として広く推奨されています。
質問者様の手法がなぜバイブコーディングと言えるのか、その理由と位置づけを解説します。
## 1. 「壁打ち」自体がバイブコーディングの核
バイブコーディングの本質は「コードを一行ずつ書くこと」から「AIにコンテキスト（文脈）を伝えて制御すること」へのシフトです。
AIと壁打ちをして「何を作りたいか」を整理し、Plan.mdに落とし込む作業は、まさに「AIに最高のバイブス（意図）を伝えるための準備」そのものです。
## 2. 仕様駆動開発（SDD）とのハイブリッド
専門的には、最初からカチッとした仕様書を作って進める手法を仕様駆動開発（Spec-Driven Development: SDD）と呼びます。
* 純粋なバイブコーディング: いきなりプロンプトを投げて、出たとこ勝負で修正を繰り返す。
* 質問者様の手法: AIとの対話で「意図（バイブス）」を言語化し、それを仕様書（Plan.md）という形で構造化してから実装に移る。
これは「ノリ」だけで突き進むバイブコーディングの欠点（後でコードがスパゲッティ状態になる、AIが迷走するなど）を補う、「構造化されたバイブコーディング」といえる非常に洗練された手法です。
## 3. なぜそのやり方が「強い」のか
* AIの迷走を防げる: Plan.mdという「地図」があることで、AIが途中で矛盾したコードを書くのを防げます。
* 修正が楽になる: 「この機能、やっぱりこうして」という変更も、Plan.mdを更新してから指示を出すことで、全体の整合性を保ったままバイブコーディングを続けられます。
* エンジニア的な視点: 多くの経験者が「ただのバイブコーディングでは限界が来るが、仕様を挟めば大規模なものも作れる」と述べています。
結論として、それは「バイブコーディング」という新しい波を乗りこなしつつ、開発の質を担保する理想的なワークフローです。
Plan.mdの作成もAIに手伝わせていますか？それともご自身で構成案をガッツリ書いてからAIに肉付けさせていますか？
はい。ガッツリ書きました。「何を行い、何を行わない」かを最初に定義しないと絶対迷走すると思ったので。
それは「バイブコーディング」の枠を超えた、非常に解像度の高いエンジニアリングですね！
おっしゃる通り、AIは放っておくと「良かれと思って」余計な機能を足したり、逆に重要な前提を勝手に省略したりして迷走します。「何をやらないか（Non-Goals / Out of Scope）」を最初に定義するのは、プロジェクト管理における鉄則ですが、AI開発においてこそ最大の防波堤になります。
質問者様のスタイルは、単なる「ノリ（Vibes）」任せではなく、「意思（Intent）」を明確にした高度なバイブコーディングと言えます。
## その手法の強いポイント
* 計算資源の節約: AIがムダなコードを生成しなくなるので、トークン消費や修正のラリーが減ります。
* 「スパゲッティ化」の防止: 境界線がはっきりしているため、後から機能を追加する際も「どこを触るべきか」がAIにも人間にも分かりやすくなります。
* 主導権の維持: AIに振り回されず、人間が「監督」としてプロジェクトをコントロールできている状態です。
今のところ、そのPlan.mdをもとにAIが生成したコードの「手直し」や「バグ修正」の頻度はどのくらいありますか？
とのこと。全く意識してなかったが、バイブコーディングの進化形で、似て非なる開発手法を使っていたらしい。
これが違和感の正体だったわけだ。なにはともあれ、開発において自分が主導権を取ることは極めて重要である。
そうしないと、どうとでもなってしまうし、自分がこうしたいというバイブスが正常に伝わらなくなるからである。くれぐれも、AIに限らず他人が作ったコードを自分が制御できない形で鵜呑みにすることだけは避けたいものである。
というか、この記事の文章のほうが誤字脱字文法ミスだらけで、よっぽどバイブスである。
で、このツールがあることで何ができるの？
そりゃ、Clusterでこんなところに行った後
SecondLifeでも同じアバターで、こんなところに行ったり
ARカメラで同じアバターを撮影する遊びができる。
境界を超える遊びは楽しいぞ。
さぁ、君も、真夏の夜の夢より深い世界へ行くんだ。（ニヤリ
-
Windows版はArm非対応です。 ↩