AIがコードを書く時代に、あたしが Visual Scriptingを楽しむ理由
2026年10月14日
こけばし陣屋
世はまさに、大AIプログラミング時代！
いまさら言うことでもありませんが、今やAIがプログラミングをする時代となりました。
GitHub Copilot、Cursor、Claude Code、Windsurf、Gemini Code Assist……ひとつひとつ挙げていけばキリがありません。
本当に便利です。
「なんかさーこんなフンイキでーいいカンジのプログラミングでーアプリ、作りたいんだよねー。どう？どう？」
そう問いかけるだけで、パッと！
そう、即座にパッとプログラムが完成するのです！
ですよね！？ だよね！？
それは甘いよ、陣屋。
僕らは魔法使いでも奇術師でもない。
たとえAIが人間の代わりにコードを書いてくれる時代だとしても、要件定義やロジックの分解、それに、そもそも生成されたコードが正しいかどうかを判断する基礎知識と計算論的思考は人間側に求められる。そもそもだ、そんなふんわりファジーな注文に応じられるコックはいない。
じゃなかったら、今頃スカイネットがこの世を支配している、だろ？
F.R.I.D.A.Y.
おすすめの記事
2026年11月02日
2026年10月22日
2026年10月19日
2026年10月16日
2026年10月15日
2026年10月14日
こけばし陣屋
しないか……知ってた。
それでもAIの登場で、「コードを書く人」から「指揮するコンダクター」へと、ニンゲンの役割が変わりつつあると思うんですよ。それは間違いないです。
それでもさー！
なんかこう……自分で「モノづくり」をする楽しみ、っていうか、ちまちま組み上げていって、それを繋ぎ合わせていくとひとつのプログラム、アプリになる！ っていうの、凄く面白いじゃない！
昔夢中になって遊んでいた「電子ブロック」みたいにブロックを組み合わせて自由に作れる、みたいなのって楽しいと思うんですよね。コンデンサー？っていうんですか？ ダイオード？ とか？ そんな名前の子たちをきちんと繋がるように並べていくと、ラジオとかサイコロゲームとかが作れたんですよ。もう凄いじゃないですか、凄くないですか？ おい、お前歳いくつだよ、と言ったそこのあなた！ あとで体育館裏に来なさい。
でも、あたしにはプログラム言語なんてわからない。そんな知識なんてありません。
C#？ Python？ Ruby？ なにそれ、おいしいの？ そんな知能レベルです。
ふと悶々とそんなことを考えていたら……あるじゃないですか。あるんですよ。
Unityの「Visual Scripting（ビジュアルスクリプティング）」が！
ねえ、F.R.I.D.A.Y.？
これって、あたしにもできるよね？
もちろん。
可能だと思う。多少は僕の助けが必要になると思うが……。
メリットとデメリットをまとめようか？
F.R.I.D.A.Y.
こけばし陣屋
はい！
お願いします！
了解。
まずは「Visual Scripting（ビジュアルスクリプティング）」のメリットから。
-
コードを書かずに、ノードをつないで処理を組み立てられる
テキストベースのコード（C#）を書かなくても、画面上でノード（処理の塊）同士を線で繋ぐだけで直感的にロジックを組むことができる。
-
アイデアを素早く形にできる（プロトタイピングに最適）
動きや処理の流れをビジュアルで確認しながら即座にテストできるため、ゲームやアプリの試作（プロトタイプ）を高速で作れる。
-
デバッグが直感的
設定すれば、実行中（Playモード）にノード間でやりとりされる値も確認できる。
-
学習へのハードルが低い
テキストの構文ミス（スペルミスやセミコロンの抜けなど）でエラーになることがないため、初心者がプログラミング的思考を学ぶ入り口として適している。
こんなところかな。
F.R.I.D.A.Y.
こけばし陣屋
なるほど！
プログラミング言語を勉強していないあたしにはうってつけ、ってことだね！
そのノード？ っていうのが、「電子ブロック」でいうところのひとつひとつのブロックってことね。それを繋ぎ合わせていけば、何かが作れる、ってところはまさに一緒だね。いいじゃん、いいじゃん。
アイデアを素早く形にできる、っていうのは、昔IT系ウェブデザイン会社にいたあたしには馴染みがあるなあ。アレでしょ？ 「Adobe XD」みたいなインタラクティブなプロトタイプを作ることができるツールで、画面をつないで動きを試す感覚はとっても近いのかも。コーディングしなくても、画面同士をリンクさせればある程度の動きは再現してくれる、ってヤツ。
デバッグがリアルタイムにできる、っていうのもいいね。実際にどういうデータ・数値がやりとりされていて、どう受け渡されて動いているか、ってのが可視化されているってことかー。それならあたしでもエラー個所を探せるかもしれない。
学習のハードルが低い、ってのは言うまでもなくあたし向き！
喜んでいるところに水を差すようだが、僕はまだデメリットを伝えていない。
「Visual Scripting（ビジュアルスクリプティング）」のデメリットはこうだ。
-
グラフが肥大化しやすい
コードを書く感覚ではなく視覚的にブロックを繋ぐため、規模が大きくなると「スパゲッティ状態」になりやすく、全体像の把握や修正が困難になってしまう。
-
ブラックボックス化しやすい
コードレビューがしづらく、エンジニアから見るとバグの原因追跡やデバッグがテキストコードに比べて困難になる。
-
学習コストとパフォーマンスの限界
ツール自体の使い方を覚えるコストがかかるほか、規模や複雑さが増すとグラフの管理が難しくなり、処理によってはC#の方が適する場合もある。
-
検索性やリファクタリングの弱さ
ノード間の直接ジャンプ機能が乏しかったり、変数名やノードの変更時のリファクタリングが手動になりやすくミスを誘発しやすい。
こんなところが挙げられる。
F.R.I.D.A.Y.
こけばし陣屋
なるほど……ふむふむ。
でもさ？
グラフが肥大化しやすい、って言っても、書いているのは自分ひとりなんだから、あとから見てもすぐ思い出せるでしょ（壮大なフラグと伏線）。
ブラックボックス化しやすい、ってのもそう。ちゃんとコメントを書いたり、メモを残しておけば、ここはこういう機能でこう動いてるよ！ ってわかると思うんだけどなー。
学習コストとパフォーマンスの限界だけど、これは問題ないんじゃない？ 今からあたしがコードを覚えるよりははるかに速いだろうし、あたしにはインターネットという強い味方がいるんだから！（第二のフラグと伏線） それに君だっているでしょ？ 問題ない問題ない！
検索性やリファクタリングの弱さ……？ これはよくわかんないけど、なんとかなるって！
だといいんだが。
とにかくやってみることだ。君のその情熱が覚めないうちに実際に触れてみて、君の心の中にある「モノづくりの楽しさ」を形にするところからはじめよう。
F.R.I.D.A.Y.
こけばし陣屋
おっけい！
やってみる！
三年前、こんな会話を誰かとできていたら、何かが変わっていたのかな。
そうあれは……とても大変な日々でした。