「生成AI×ビジュアルプログラミング」が進まない理由は？中山心太氏に聞く、高級言語との本質的な違い

現在プログラミングの現場では、生成AIの活用が進んでいます。今やテキストプログラミングにおいて生成AIの活用は珍しいことではなくなりました。一方でビジュアルプログラミングにおいては、テキストプログラミングほど生成AIの活用が進んでいないのが現状です。

「ビジュアルプログラミングとは、結局どんなものなのか」「なぜ広くプロユースされていないのか」「なぜビジュアルプログラミング×生成AIはそこまで進んでいないのか？」

これらの疑問を、株式会社NextInt代表として、ビジュアルプログラミングでのリスキリングサービス「Sheet Camp」を開発しながら、生成AI関連の書籍を出版したりと、2つの領域に精通している中山心太さんに聞きました。

ビジュアルプログラミングの強み、弱みを改めて整理していく中で、「テキストプログラミング」の動かぬ強みも明確になっていきました。

• keyboard_arrow_down ビジュアルプログラミングがプロユースされないのは、変更検証性が低いから
• keyboard_arrow_down ビジュアルプログラミングで生成AIの活用が進まない理由
• keyboard_arrow_down 今後のプログラミングに生成AIが与える影響とは

――まずはテキストプログラミングと比較して、ビジュアルプログラミングのメリット・デメリットについて、改めて教えてください。

中山：前提として、ビジュアルプログラミングには大きく2種類あります。

1つはScratchやBlocklyのように、既存のプログラミング言語と高い互換性を持った「ブロック型」のビジュアルプログラミングです。ブロック型はテキストプログラミングとほぼ等価的に変換できます。

中山：ブロック型のメリットは、構文エラーが絶対に起きないことです。論理エラーや、ゼロ除算などの実行時エラーは起きる可能性がありますが、構文エラーが起きないぶん、初学者にとっての構文を覚えるハードルをスキップできます。また、命令が日本語化されているのも初学者向けです。そのため、ブロック型はプログラムの教育用として主に使用されています。

ただ、ブロック型では、プロが使う上で必要な機能が備えられていなかったり、冗長性が高すぎたりして、プロの使用に耐えられないのが現状です。

中山：もう1つが「フロー型」のビジュアルプログラミングです。

何かしらのイベントが起きた後、そのイベントがどのように伝播していくのかという“フロー”を組んでいくものです。たとえばUnreal Engineのブループリント機能や、日立製作所の統合システム運用管理「JP1」、タスク自動化ツールの「n8n」、最近だと画像生成AIで用いられる「Comfy-UI」などは、プロユースとしても利用されています。

連続的にストリーム処理するものや、タスクに依存関係があるプログラミングは、フロー型のビジュアルプログラミングと極めて相性が良い。それに、ブロック型と同じく構文エラーが起きないというメリットもあります。

中山：そしてフロー型は、テキストプログラミングにはないメリットを持っています。

たとえば「Comfy-UI」であれば、途中のデータ構造が見やすくなっているし、あるいは「Houdini」という3DCG制作用ソフトでは、データフロー型のビジュアルプログラミングを行うことによって、複雑な形状の3Dモデルや、複雑なエフェクトを作成できます。また、日立製作所が開発した統合システム運用管理ツール「JP1」のように、複数の並列処理が実行されて、その実行結果を待ってから次の処理を実行させたいような「合流」を表現したときには、テキストプログラミングよりはるかに楽に表現できます。

中山：初学者向けには、Nintendo SWITCHの『ナビつき！ つくってわかる はじめてゲームプログラミング』というゲームソフトでも、フロー型ビジュアルプログラミングの手法が用いられています。

あとは「ブロック型」と「フロー型」に当てはまらないものとして、原田康徳さんが開発した「ビスケット」があります。これは画像をパターンマッチして変換していくルール記述型のビジュアルプログラミングです。

――フロー型はプロユースされているのに対して、なぜブロック型はプロユースに耐えられないのでしょうか？

中山：ブロック型ビジュアルプログラミングはテキストプログラミングと等価、つまりブロック型でできることは、テキストプログラミングですべてできるからです。

それに、「テキストプログラミングではできるけれど、ブロック型ではできないこと」も存在します。たとえば、関数オブジェクトや関数ポインタなど、変数の中に関数を代入して実行するといった使い方は、現在のブロック型プログラミングではサポートされていないものが大半です。

また、ブロック型では、一つの画面に表示できるプログラミングの行数が、テキストプログラミングに比べてどうしても少なくなってしまう、というもデメリットのひとつです。プロが使うユースケースを、ブロック型ではサポートしきれていないのです。

また、ブロックプログラミングが構文エラーを起こさない点や、日本語でプログラミングできる点も、当然ながらプロから見て魅力にはなりません。プロは構文エラーを起こさないし、プログラミング英語もプロなら書けて当然という前提がありますからね。

むしろプロにとって重要なのは「変更検証性」です。

――と言いますと？

中山：ブロック型ビジュアルプログラミングでは、多くがXMLで記述されていて、マウスでノードをドラッグするだけで座標が動いて値が変わります。

ところが、その「変更」にどんな意味があるのか、あるいは意味を持たない変更なのかは、ビジュアルプログラミングだとわかりません。たとえば、ノードの位置や線のつなぎ方を変更したとき、それが意図的な変更なのか、単なる見た目の調整なのかを、一見して判断することが難しいのです。

すなわち、ビジュアルプログラミングはテキストプログラミングに比べて、変更検証性が著しく低いのです。

それに、プロユースにおいては、そもそも気軽に変更できちゃいけないんです。意図しない変更によって、システムに影響が出て、バグや障害につながってしまうことを、プロユースでは許容できない。

意図しない変更をしないようにするには、テキストプログラミングのように明示的に書き換えて、保存して、再実行して初めて変更が反映されるといった、意図してしか変更できないようなプロセスが必要です。

ビジュアルプログラミングのように、ノードをドラッグ＆ドロップして動かしすぐに変更できるのは、プロユースにおいては大きなデメリットとなってしまうのです。

――テキストプログラミングと比べて、ビジュアルプログラミングにおいては、ブロック型、フロー型問わず生成AIの活用がそれほど進んでいないのは、どういった理由が考えられますか？

中山：前提として、ビジュアルプログラミングが生成AIにとっての「学習データ」になっていない、という側面は大きいと思います。ビジュアルプログラミングでつくられたコードがGitHubに上がっているわけでもないですし、デファクトスタンダードになるような実装も存在していません。つまり、生成AIが生成の参考にする学習元が不足しているのです。

では既存のテキストプログラミングをビジュアルプログラミングの形式に変換して学習させればいいのかというと、それも難しい。

先ほど少し話に出たように、テキストプログラミングでできることでも、ビジュアルプログラミングではサポートされていないことがしばしばあるからです。たとえばBlocklyはプログラミング教育用として割り切っているので、ローカル変数はなくグローバル変数しかありません。だから再帰関数などはすごく書きづらい。これはブロック型だけでなくフロー型も同じです。

ただフロー型については、ルールをしっかりとAIに教え込めば、いずれはテキストプログラミングに変換できるようになると思います。「このモジュールはこのインプットがあって、こんなふうにつながっていく」といったような、ある種の回路図的な学習データを十分に用意できれば、テキストプログラミングとフロー型を自由に行き来できるようになるかもしれません。

――ではフロー型については今後、生成AIの活用が進む可能性もあるのでしょうか？

中山：そうですね。ただし、初学者の学習を助ける用途に限って、だとは思います。ユーザーがテキストプログラミングを理解できない場合は、ブロック型のビジュアルプログラミングに変換することで、理解を助けられるでしょう。

一方、プロユースの現場で、コードの概要をビジュアルプログラミングに変換して理解を補助する、なんて用途で使われることはないかと思われます。ビジュアルプログラミングの形式でないと理解できないレベルの人に対し、プロのプログラマとしては「下手にコードに触れてもらいたくない」と感じてしまうのではないかと思うのです。意味をよく理解していない人によって生成され、レビューせずに組み込まれていくプログラムに信頼性なんてないですから。

特にフロー型については、プロユースの現場で、特定のユースケースで使われるツールなので、こちらも現状では、学習データが不足しています。そのため、生成AIによるプログラミングの支援は難しいのではないかと思います。Unreal Engineのブループリントで状態遷移図をつくる際などに、生成AIが使われたりはするかもしれませんが、現実的にはそれくらいじゃないかなと。

――テキストプログラミングへの参入ハードルを下げる意味合いでの、ビジュアルプログラミングへの生成AI活用も意義が薄いとすると、ビジュアルプログラミングとテキストプログラミングの間には高い壁があるように思います。

中山：その通りです。先ほど話した「変更検証性」もそうですが、それ以前に根本的な違いが1つあります。それは、テキストプログラミングはコンピュータリーダブルであり、ビジュアルプログラミングはヒューマンリーダブルである、ということ。

現在、プログラムが解決しているタスクというのは、現実世界の特定の領域において、極めて定型化されたものを指します。その特定の定型化されたタスクを、厳密に解くための手法がプログラミングです。だから今のプログラミングでは、基本的には「全て厳密に確実に解く」ということに主眼が置かれていて、そのためには、テキストプログラミングのようにコンピュータリーダブルな形で厳密に命令を書くのが、一番妥当といえます。

一方ビジュアルプログラミングは、ノードを線で結ぶなど、ヒューマンリーダブルな形で表現にするために、テキストプログラミングで担保しているレベルでの厳密さを持っていない。だから、厳密さを求められにくいタスクにしか利用できない。

こうした厳密性が求められないタスクは、生成AIによる出力によって代替できる領域でもあります。だから、今ビジュアルプログラミングで行われていることの一部が、生成AIに代替される可能性のほうが、むしろ高いんじゃないでしょうか。

結局、どこまでいってもビジュアルプログラミングは、テキストプログラミングから切り離した特定のタスクをこなすためのものです。「そもそもビジュアルプログラミングを、AIで支援する必要があるのか？」という疑問は残りますね。

――ビジュアルプログラミング、とくにブロック型が担ってきた「初学者がプログラミングの発想を身につけるための教育」という役割を、生成AIが代替してしまう可能性はないのでしょうか？

中山：その可能性はあると思います。

今のブロック型は、「プログラミング」というものに初めて触れる人にとっての大きなハードルを、3つ解決しています。1つ目は構文エラーを起こさないこと、2つ目は英語がわからなくてもプログラミングできること、3つ目はキーボードの習熟度が低くても操作できること。

このうち、3つ目のキーボード以外は、生成AIでコードを出力させれば解決できてしまいます。生成AIは構文エラーを起こしづらいし、日本語の自然言語から出力できますから。そう考えると、プログラミング教育で活用されているポジションとして、ブロック型のビジュアルプログラミングが担っていた領域が、生成AIに一部リプレイスされる可能性はあるはずです。

もしくは、生成AIとビジュアルプログラミングがかけ合わさることで、より良く教育を支援できるようになることも考えられます。

先日、BlocklyとOpenAIを利用したAIブロックプログラミングアシスタントを個人開発している人を見つけました。AIに自然言語で語りかけ、ブロックの生成や改善を行ったり、既存のブロックの動きをAIアシスタントに解説してもらうこともできるといったプロダクトのようです。

このように、教育目的のビジュアルプログラミングを生成AIと組み合わせることによって、さらに教育効果を高められるようなサービスが、今後他にも出てくる可能性はあるでしょう。

――今後、プログラミングと生成AIの関係はどうなっていくのでしょうか。

中山：だいたいのタスクについては、生成AIに自然言語で入力すれば解決可能になっていくと思います。

現在のプログラマは、普段はRubyやPythonといったLight Language（軽量プログラミング言語、書きやすいが実行速度が遅い）でコードを書いて、速度が必要なところだけCやC++で書いたりしています。それと同じことが生成AIで起こると思います。

つまり、生成AIに自然言語で入力して、タスクを解決してもらったり、場合によっては生成AIがコードを生成したりして、速度や確実性が必要な箇所だけ自分の手で記述するのです。

――となると、生成AIに指示するスキルと、生成AIが書いたコードをそのままで使えない箇所を自分で書いて補えるスキル、どちらも必要そうですね。

中山：そうですね。前者の、生成AIに自然言語でコンピュータの動かし方を指示するのも、感覚的にパッとできるものではなく、コツが必要でしょう。

テキストプログラミングでコンピュータに指示をして、人間の思い通りにコンピュータを動かせるのは、人間がやってほしいことを、プログラミング言語を用いて、コンピュータが理解できるように伝えているからです。指示の出し方、すなわちプログラミング言語の使い方に、一定の学習を要するように、生成AIに指示を出すにも、似たような学習の必要はあるはずです。

また、生成AIを用いた自然言語でのプログラミングが広がったとき、もしかすると、バージョンアップの苦労は今より大きなものになるかもしれないと思っていて。

――それはなぜでしょうか？

中山：生成AIが自然言語からコードを出力するとなると、コードの出力に「AIの解釈」が必ず存在することになります。するともしかしたら、その生成AIのバージョンが変わった瞬間に、「解釈」の方法も変わってしまい、今までに出力してきたコードが壊れてしまったり、指示の出し方がまるっきり変わってしまったり、といったことも起こり得るでしょう。

そう考えると、現在のプログラミング言語というのは非常によくできているんですよね。先ほど話に出たバージョンアップだって、少しずつ書き直していけば対応できるし、たった1回のバージョンアップでプロダクトの大半が使い物にならなくなるようなことは考えづらい。それに、ここまでで話題に出た「厳密さ」「信頼性」「意図しない変更をしづらくなっていること」など、大規模で複雑な処理を複数行うシステム開発において、必要な要素をすべて揃えています。プロユースとしてはあまりにもよくできていて、不足がない。こうしたテキストプログラミングの強みは、簡単に代替できるようなものではなく、ゆるぎない価値を持ち続けるはずです。

生成AIの進化がいかに進もうと、ビジュアルプログラミングもテキストプログラミングも、それぞれが最適な用途に利用され続けるだろうと思います。それぞれの強みとAIの特性を整理したうえで、それらがかみ合うところにAI活用が進んでいけば、今の時点で予見できない進化が起こる可能性もあるはず。私自身、テキストプログラミングのプロフェッショナルとしても、教育を目的としたビジュアルプログラミングサービスをつくる者としても、こうした視点をもって技術を眺めていこうと考えています。

取材・執筆：山田井ユウキ
編集：光松瞳