※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※元記事を見て、内容がズレていないか査読するようにしています。今回、後半はほぼ自分で手直し。。。
原文
「生成AI×ビジュアルプログラミング」が進まない理由は？中山心太氏に聞く、高級言語との本質的な違い | レバテックラボ（レバテックLAB）
意訳+要約
「生成AI×ビジュアルプログラミング」が進まない理由は？
ビジュアルプログラミングの現状
- ブロック型: 初学者向けで、構文エラーが起きない。しかし、プロが使うには機能が不足しており、変更検証性が低い。
- フロー型: プロユースされており、複雑な処理や並列処理に強い。ただし、変更検証性が低い
ビジュアルプログラミングがプロユースされない理由
- 変更検証性の低さ: ビジュアルプログラミングは、意図しない変更が起きやすく、バグの原因になりやすい。
- 魅力が薄い: ビジュアルプログラミングは構文エラーが起きにくいが、本職の人間は、そもそも構文エラーを起こしにくいので、メリットが薄く感じられる。
ビジュアルプログラミング×生成AIが進んでいない理由
- 学習データの不足: ビジュアルプログラミングのコードが、生成AIの学習データとして十分に蓄積されていない。
- 厳密性の欠如: ビジュアルプログラミングは、テキストプログラミングのような厳密性がないものに適用されやすい。そのため、生成AIでの置き換えが進むとしたら、厳密性を求められないビジュアルプログラミングとなり、協働よりは置き換えになる可能性が高い。→厳密性を求められる箇所で生成AIを利用するのは、現状だとリスクが高い
今後の展望
- 生成AIのバージョンアップが難しくなるかも？
- バージョンアップで生成AIの解釈が変わり、今までのアウトプットが変わる可能性がある
- プログラミングの価値は変わらない
- 「厳密さ」「信頼性」「意図しない変更をしづらくなっていること」などの重要性は、AIが出てきても変わらない
検証
ビジュアルプログラミング
- ブロック型：Scratch、Blocklyが該当
- フロー型：JP1、n8n
感想＋雑記
生成AIの後方互換性を維持するのは、たしかに難しそう。。。
結局、どういう計算をしてその結果になるのか、理解ができないからな。。。
それなら、AI使わないでロジック書いたほうがいいってなる気がしないでもない。
精密さを求められるところは、依然として人手によるプログラミングが必要。
ただ、生成AIが入る余地がないかと言われると、そうでもないってのが読んでみての個人的な感想。どこに適用するのかは、まだ諸説ありって感じ。
ビジュアルプログラミングは、たしかに、フロー型が現場で疲れる事が多い。
JP1使ってたことがあるけど、たしかに、違和感はなかった。
ビジュアル化されていることのメリットとして、概要を把握するのが楽ってのがあると思ってる。
JP1だと、どこで異常終了したのか分かるようになってたはず。※最近使ってないのでうろ覚えだが。。。
原因は、やっぱりログを追ったりしないといけないけど。。。
あんまり、JP1をビジュアルプログラミングするってことはなかったな。
フローの大雑把な処理の配置ぐらいはしたけど、大体はコード書いてた気がする。
いや、そのフローを書くってのがビジュアル化のメリットか。。。
あとビジュアルプログラミングやるとしたら、ビルドプロセスの見える化とかじゃなかろうか？
プログラミングするというよりは、ビジュアライズになりそうな気がする。
どっちかというと、見える化の方が恩恵強そうな気がする。
ビジュアルプログラミングで意図しない変更が入ってバグを作ってしまったのは、あるあるだと思うんだよね。自分も何回かやらかしたし。。。
アレ、マジで疑心暗鬼になるから、個人的には敬遠しがち。
