生粋のプログラマーが「ビジュアルスクリプティングしか使えない環境」と本気で向き合ってわかったこと

私は生粋のプログラマーです。
大学では C / C++ / C# を学び、社会人になってからは Java、JavaScript、PHP、Python、Go、TypeScript と、その時代に必要とされる言語を習得してきました。

ところが、2020年頃にVR業界へ転職したことで、私のプログラミング人生は大きく変わりました。
そこで出会ったのが ビジュアルスクリプティング です。

ビジュアルスクリプティングとの出会い

VRChat（ユーザーが自作ワールドを公開できるSNS型VRプラットフォーム）では Udon ¹、
STYLY（ノーコードXR制作ツール）では PlayMaker が使われています。

どちらも Unity の AssetBundle を基盤とするプラットフォームで、C# を直接記述できないという制約があります。
その制約を補う形で、ノードを線でつなぐ「ビジュアルスクリプティング」が発展してきました。

最初の1年は本当に苦しかったです。

たとえば、2つの位置の差から方向ベクトルを求めたいとします。
C# なら以下のように2行ほどで書けます。

Vector3 CalcDirection(Vector3 A, Vector3 B)
{
    var direction = B - A;
    return direction.magnitude < 0.0001f ? Vector3.forward : direction.normalized;
}

これと同等の処理を PlayMaker で組むと、次のようになります。

あえてC#で表現すると、こうなります。

Vector3 CalcDirection(Vector3 A, Vector3 B)
{
    var direction = B - A;
    var length = direction.magnitude;
    if (length < 0.0001f)
    {
        direction = Vector3.forward; // (0,0,1)
    }
    else
    {
        direction = direction.normalized;
    }
    return direction;
}

行数は約3倍。さらに length という使い捨て変数も登場します。
プログラマー視点では非常に冗長で、ノードを整理しないと後で自分でも読めなくなります。

コードレビューも苦労の連続だった

辛いのはコーディングだけではありません。
ビジュアルスクリプティングでは、他人の処理を読むのが極めて困難です。

たとえば、丁寧にノード名をつけていれば何をしているか読み取れます。

しかし、タイトルが省略されている場合は次のようになります。

これを見ても、何をしているのかさっぱりです。
私はレビュー時に、まずノードにタイトルをつけるようお願いしていました。

当時は「こんなの非効率すぎる」「テキストで書かせてほしい」と何度も思いました。

しかし、周囲は楽しそうに使っていた

一方で、同僚の中には「ビジュアルスクリプティングの方がわかりやすい」と言う人もいました。
彼らの多くは3Dモデラーや映像クリエイターで、職種としては非プログラマーです。

私は疑問に思いました。
なぜ彼らは、これを「使いやすい」と感じるのか？

気づき：認知スタイルが違う

1on1 やヒアリングを重ねるうちに、ある傾向に気づきました。

「階層型の箇条書きが得意な人」はテキストプログラミングが得意。
「それが苦手な人」はビジュアルスクリプティングが得意。

階層型の箇条書きというのは、こういうやつです。（クリックすると見れます）

• テキストベースプログラミング
  • Unity
    • Logic / Scripting
      • C#
    • Shader
      • HLSL / ShaderLab（.shaderファイル）
  • Unreal Engine
    • Logic / Scripting
      • C++
• ビジュアルスクリプティング
  • Unity
    • Logic / Scripting
      • Unity Visual Scripting（旧Bolt）
      • PlayMaker
    • Shader
      • Shader Graph
      • Amplify Shader Editor
    • VFX
      • Visual Effect Graph（VFX Graph）
  • Unreal Engine
    • Logic / Scripting
      • Blueprint（Event Graph / Function Graph など）
    • VFX
      • Niagara

こうした階層構造の文章を読むのが苦手な人は、テキストプログラミングにも苦労する傾向がある気がします。
（あくまで、私が出会ってきた数十人規模の傾向です。）

C# や TypeScript のようなテキストプログラミングは、インデントで階層を作り、論理を構造化します。
つまり「階層型箇条書き」を読み書きするスキルが求められます。

一方で、グラフィカルな情報整理が得意な人は、この「階層構造」を苦手としがちな印象があります。
しかし、彼らが作るスライドや資料は非常にわかりやすく、ビジュアル的な構成力に優れています。

この違いは「能力の優劣」ではなく「認知のタイプ」の差です。
いわゆる ビジュアルシンカー（Visual Thinker） の人たちは、文字よりも図や空間で情報を理解します。

たとえプログラマーでなくても、クリエイターはみんな作りたがっている

私の知り合いの3Dモデラーや映像クリエイターの多くは、
「自分でもインタラクティブなコンテンツを作りたい」という強い意欲を持っています。
そのため、自らプログラミングを学び始める人も少なくありません。

ただし、ほとんどの人は テキストベースプログラミングで挫折します。
結果として、自然に ビジュアルスクリプティング に手が伸びていきます。

たとえば Unity のシェーダー言語 HLSL を直接書こうとはせず、
Amplify Shader Editor や Shader Graph のようなビジュアルエディターを採用します。

いくら「HLSLのほうが高速で自由度も高い」と説明しても、彼らには響きません。
Shader Graph の方が圧倒的に見やすいのです。

このとき、私はようやく理解しました。
彼らは「楽をしている」のではなく、「自分の認知特性に合った方法」で学んでいるだけなのです。

見方を変えてみた

この気づきをきっかけに、私は「ビジュアルスクリプティング＝劣っている」という考えを捨てました。
むしろ「誰でもプログラミングできる環境」という価値を再認識しました。

ビジュアルスクリプティングがあるおかげで、3Dモデラーや映像クリエイターでもインタラクティブな体験を作れます。
これはチーム開発の可能性を大きく広げることにつながります。

Unity の Visual Scripting（旧 Bolt）、Shader Graph、
Unreal の Blueprint、Houdini のノードベースシステム。
これほど多くのツールが存在するのは、確実に需要があるからです。

ビジュアルスクリプティングの限界

とはいえ、万能ではありません。
ビジュアルスクリプティングはあくまで 小規模向け の仕組みです。

• Git で差分を確認できない
• 例外処理が弱く、異常系を記述しづらい
• 複雑な分岐が増えると、全体の可読性が崩壊する
• private / public のようなスコープ管理ができず、依存が生まれやすい（※Blueprintは可能²）
• interface が存在せず、ポリモーフィズムを表現できない（※Blueprintは可能²）

このように、拡張性や保守性を前提とした設計には向きません。
そのため、ビジュアルスクリプティングで経験を積んだクリエイターが大規模案件に挑戦すると、苦労する場面が多く見られます。

もしプロジェクトが大きくなりそうなときは、ぜひ 専業プログラマー を頼ってください！

ビジュアルスクリプティングが有効な場面

用途を誤らなければ、ビジュアルスクリプティングは非常に強力です。
特に以下の条件がそろった場合に有効です。

• チームにテキストベースプログラミングが得意な人がいない
• プロジェクト規模が小さい（試作・短期間・演出中心）

また、学習や教育の文脈でも大きな価値があります。
非エンジニアが「ロジックを組む体験」を得るための貴重な入り口であり、
この特性があるからこそ、多様な人が制作に参加できます。

このような環境では、ビジュアルスクリプティングは最も強力なツールです。
これを理解しておくことが、プロジェクトを円滑に進める鍵になります。

まとめ

5年間を通じて、私は次の2つを強く実感しました。

1. ビジュアルスクリプティングは「認知の多様性」を受け入れる発明である
2. ただし「規模」には明確な限界がある

プログラマーがクリエイターと協業するとき、
「自分の得意な形式が相手にとっても最適とは限らない」ことを常に意識すべきだと思います。

おわりに

もしあなたがプログラマーで、
「ビジュアルスクリプティングなんて非効率だ」と感じているなら、
一度そのツールを1日だけ本気で触ってみてください。

そして、テキストが苦手な人たちの視点を少しでも理解できたなら、
きっとクリエイターとの協業が今よりずっとやりやすくなるはずです。

おまけ：AI時代のいま、再び分岐点に立つ

このように、ビジュアルスクリプティングは「誰でも作れる時代」を切り開きました。
しかし近年の AI支援プログラミング の登場で、状況は再び変わりつつあります。

チャット形式でコードを生成し、小規模なインタラクティブコンテンツを構築できるようになりました。
まさにビジュアルスクリプティングが得意としてきた領域です。

ただし現状、AIが対応しているのはほとんど テキストベースプログラミング です。
ビジュアルスクリプティング対応のAIは、まだほとんど存在しません。

この流れが続く限り、AIを活用するためにはテキストベースを学ばざるを得ません。
結果として、大規模だけでなく小規模開発でもテキストベースが優位に立ちつつあります。

この傾向を踏まえると、ビジュアルシンカーの人たちがどのツールを選ぶのか、判断が難しい時代に入っていると感じます。

1. VRChat では後に UdonSharp という C# ライクなテキストプログラミング環境が登場します。 ↩

2. Unreal Engine の Blueprint はビジュアルスクリプティングの中でも特に完成度が高く、抽象化・再利用・カプセル化の仕組みが整っています。他ツールより高機能で、中規模開発にも部分的に対応可能です。 ↩ ↩²