ADR-0002: Sobakasuを開発する理由（Udonファースト高級言語・ツールチェーン）

Status

Accepted

Context

Sobakasu は VRChat Worlds SDK（Udon）向けに、Udon Assembly（以下 UASM）へ変換するための高級言語およびツールチェーンとして構想された。

現状の主な選択肢には、UdonGraph / UdonSharp / ノーコード系ツール / UASM 手書きなどが存在する。しかし本プロジェクトの目的（Udon向けに最適化した言語設計とツールチェーンの検証、かつ実用に近いUXの確立）に対しては、次の課題がある。

• Unity/VRChat 側の制約や既存ツール仕様により、実装体験・言語機能・開発の自由度が制約される（特に UdonSharp 前提の開発体験に依存しやすい）。
• UASM を直接扱うことは、人間にとって可読性・保守性・レビュー性・ミス耐性の面で負担が大きい。
• 先行事例として、軽量言語を UASM にコンパイルする実験的プロジェクトや、中間言語（IL）的アプローチが存在する。
  • ただし本プロジェクトは「既存言語をUdonに適合させる」よりも、最初からUdonのために設計された高級言語として、UdonSharp 利用者が違和感なく使える体験を主目標に置く。

本プロジェクトの困っている主体は以下である。

• 現時点: 開発者（研究/趣味/実装実験として、Udon向け言語・コンパイラ設計を自由に検証したい）
• 将来: VRChat ワールド制作者（ただし当面は研究優先で、段階的に実用性を上げる）

Decision

Sobakasu は、最初から最後まで Udon ファーストであり続ける。

Sobakasu は UASM 生成を第一級の目的とする、VRChat Worlds SDK（Udon）向け高級言語およびコンパイラ/ツールチェーンとして開発する。

設計原則（固定）:

1. UdonSharp “並み”の使いやすさを設計制約として採用する
   • UdonSharp 利用者が大きく驚かない開発体験（Unity内ワークフロー、イベント駆動、ドット呼び出し、命令型フロー）を優先する。
2. トップレベルスクリプトを基本形とする
   • 1ファイル（.sobakasu）を1つの“スクリプトモジュール”として扱い、トップレベルに状態（フィールド）・関数・イベントを記述できる。
3. C#互換は目的ではない
   • C# の言語仕様やバージョン互換を目標にしない（Roslyn 特定言語機能への追随を目的としない）。
4. C#互換のための class を安直に導入しない
   • 継承等のクラスモデルを前提としない。将来のユーザー定義型は、必要最小限の抽象（例: struct + impl のような方針）で提供できるよう設計余地を残す。
5. Unity Editor 統合を優先する
   • ScriptedImporter / ProgramSource 等により、import→コンパイル→ProgramSource設定→再生 が最短導線で成立することを優先度1とする。
6. Udon の制約（型・メモリ・外部呼び出し）を前提に、安全でレビュー可能な表現へ落とす
   • 直接 UASM を書くより安全で保守しやすい表現を提供し、段階的に機能（APIカバレッジ等）を拡張する。

優先順位:

• 優先度1: C#仕様・バージョンへの依存を前提にしない形で UASM を生成できること
• 優先度1: Unity Editor 統合（import→コンパイル→適用）が成立すること
• 優先度2: 型・メモリ・外部呼び出しの安全な設計検証
• 後回し: API網羅の完全性や最適化（ただし最終的には拡張する）

Alternatives

• UdonSharp をそのまま利用する
  一般用途では最有力。ただし本プロジェクトの目的は「C#互換」ではなく「Udon向け言語/ツール設計の検証」であり、入口をC#に固定すると設計自由度が低い。

• CyanTrigger 等のノーコード/GUI中心ツールを利用する
  ワークフローの価値軸が異なる（本プロジェクトは快適なコーディング体験とコンパイラ実験が主目的）。

• 既存C#を解析して限定トランスパイルする
  入口がC#である限り、Udon向け最適化の自由度が低く、UdonSharp と役割が重なりやすい。

• 手書き UASM
  実用上の生産性が低く、保守・レビュー・ミス耐性が不足する。

• 先行事例（軽量言語→Udon, 中間言語IL 等）を採用/拡張する
  方向性は近いが、本プロジェクトは「最初からUdon向けに設計された高級言語」かつ「UdonSharp利用者が違和感なく使えるUX」を主目標として固定する点が異なる。

Rationale

• Sobakasu は既存ツールと競合すること自体を主目的としない。
  ただし、Udon環境に最適化した言語・コンパイラ設計を自由に検証できる入口が必要であり、その入口を C# 互換に固定しないことに価値がある。
• “UdonSharp並みの使いやすさ”を設計制約として固定することで、言語仕様（構文・イベントモデル・命令型フロー）と Unity 統合の優先順位が明確になり、後続ADRの判断基準が安定する。
• トップレベルスクリプトを基本形にすることで、Unityスクリプトに近い書き味・導入容易性・実装容易性を両立しやすい。
• class/継承を安直に導入せず、必要な抽象のみ段階導入することで、Udon制約下での実装コストと複雑性を抑制できる。

Consequences

Positive

• C#仕様・バージョンに依存しない形で、Udonファーストな言語/ツールチェーンの設計検証ができる。
• UASM 手書きより安全でレビュー可能な開発体験を提供できる。
• Unity Editor 統合を優先することで、実用に近いフィードバックループ（編集→コンパイル→実行→診断）が確立しやすい。
• “UdonSharp並み”を固定したため、ユーザー視点の品質基準が明確になる。

Negative

• Udon/SDK の仕様変更に追随するコスト・破綻リスクがある。
• 学習コスト（独自言語）と、エディタ/診断/デバッグ体験を自前で整える負担が増える。
• デバッグ体験（ソースマップ、診断品質、実行時追跡）を設計実装する必要がある。
• Unity統合（Importer/Asset互換/Editor UI 等）の実装コストが高い。

Success Criteria

段階的に次を満たすことを成功とみなす。

DX（UdonSharp並みの使いやすさ）:

1. .sobakasu を Unity に配置すると自動でコンパイルされ、ProgramSource として設定可能なアセットが生成される
2. エラーは最低限「ファイル/行/列」「原因」「改善提案」を提示する

機能検証（ベンチ）:

1. on interact { Debug.Log("Hello, world!"); } が Sobakasu→UASM→VRChat上で動作する
2. FizzBuzz が動作する
3. ワールドギミック（例: 鏡のON/OFF）が実装できる
4. APIカバレッジを段階的に拡張し、継続的にテスト可能なサンプル群を整備できる