最近の生成AIを活用したプログラミングはなかなか凄い。指示=プロンプトを出してやれば、少なくとも一定程度世の中でやられているようなプログラムならソースコードを生成してくれる。例えば先日のエントリで紹介した息子用ランダムタイマー程度なら、それなりに書いてくれただろうと思う。自動でプログラミングしてくれるとも言える。将来的にプログラマは不要になるという言説も見かける。
一応これでも一定程度のプログラミング技法を修めた人間として、プログラマ不要論には感情的な反発を覚えるのを否定できないし、一方でプログラマの仕事を一定程度代替・自動化してくれるポテンシャルは間違いなくあるとも思う。このあたりの思索をまとめてみたい。
信用はしきれない
まず第一に、巷でもよく言われる事であるが、生成AIが出力したプログラム・ソースコードを何のチェックも無しに実用することはまだできまい。ほとんどの場合において、質問者の意図に即して問題のないソースコードを出力してくれるとしても、必ずそうである保証は誰もしてくれない。保証がない以上、その出力結果を人がチェックする必要は必ずあり、そのチェック作業を行うにはソースコードを読む能力が必要である。その点で、所謂プログラマと呼ばれる職種の仕事は、低減される可能性は大いにあるが、全く無くなることはない。そもそも生成AI自体、そのプログラムは誰かが書いている訳で。
生成AI技術の進歩によってその回答の信頼性は上がってゆき、いずれはチェック無しに生成AIが出力したソースコードを活用できるようになる、と主張する向きもあるかもしれない。しかし個人的には、そもそも現在の生成AIというものの考え方の限界として、それには無茶があると考えている。例えば以下のような懸念は、生成AI技術の進歩だけでは消せないだろう。少なくとも今は、まだ。
- 悪意に脆弱である。生成AIが出力したソースコードをチェック無しにそのまま利用する事が一般的な世界を仮定したとき、その生成AIを提供する側に悪意があれば、間違いなく出力されるソースコードにバックドアを仕込むだろう。コンピュータセキュリティにおいて性善説を唱えるのは愚かである。
- 生成の典拠となる情報源が玉石混交である。ウェブ上には上記の件のような直接的な悪意がなくとも、古かったり解釈を誤ったりしていて今や適切でないプログラミング技法の解説が数多ある。例えば、Cで標準入力から文字列を取るのに
gets関数を使う1とか、HTMLでフォントを変えるのにfont要素を使う2とか。それらが生成AIによるソースコード出力において参照される可能性を否定できない。 - 著作権上の問題を孕む可能性がある。そもそもこの界隈、ウェブ上にある解説記事のサンプルコードを取ってきて自身のものに組み込んで使うようなことは割と行われていると思う。その場合、そこにはそうする人の意図があり、そうして良いかの判断も3ある。しかし生成AIの場合、その生成物が人の意図しない所で著作権に触れてしまう可能性はある。意図が無ければ、そこには当然判断も有り得ない。
より高次の自動化に進んだという見方
上述の通り、生成AIによるソースコード出力がプログラマの役割を完全に代替する事は無いと考えている。しかしその一方で、プログラマの業務を低減する便利ツール、という一言で片付けて良いのかというと、個人的には引っかかる所もある。これまでのプログラミング方法論のパラダイムを大きく転換するポテンシャルを持っているという見方も可能なように思う。
本エントリの表題にも挙げている「自動プログラミング」という言葉から想起されるものとしては、現在の文脈であれば、まさに本エントリの主題である生成AIによるソースコード生成があたるだろう。しかし一昔前であれば、「自動プログラミング」というのはコンパイラのことであったと聞く4。即ち、機械語ないしアセンブラを直接書くのではなく、より人にとって分かりやすい高級言語によってプログラムを記述し、そこから自動的に機械語を生成する事が、「自動プログラミング」と呼ばれたのである。その点、生成AIによるソースコード生成も構図は似ている。即ち生成AIは、高級言語よりもさらに人にとって分かりやすい自然言語を入力に取って、そこから高級言語のソースコードを自動的に生成しているのである。そのように捉えれば、自動化の段階がより高次に進んだと整理する事も出来る。
もしかするとコンパイラの登場当初は、機械語ないしアセンブラを直接書かずに済む便利なツール、程度の立ち位置だったのかもしれない。しかし今から見れば、高級言語でプログラミングするというのは至極当たり前の事である。振り返るに、コンパイラの登場はプログラミング方法論に対する一つのパラダイムシフトだったのではないかと思う。つまり、近い将来同様の構図により、生成AIがプログラミング方法論にまた一つのパラダイムシフトを齎したものとして数えられる時が来ても不思議ではない。
勿論、構図に類似性はあるとはいえど、これら二者の間には大きな隔たりもある。形式言語と違って、自然言語の解釈には曖昧性がある。また、生成AIの出力は端的に言えば既存情報源の統計上にある。これらの特徴から、生成AIによるソースコード生成は決定論的ではない。そこには上掲の問題点もある。これに対してコンパイラの挙動は決定論的、即ち、あるコンパイラに対して決まったソースコードを入力した時、得られるコンパイル結果は一定である。それ故に、コンパイラが信頼できるものであれば5、少なくとも元のソースコードの通りに動作する生成物は得られると考えて良い。これは生成AIによるソースコード生成と明確に異なる。
違いがあるからこそ、将来的にパラダイムシフトとして扱われる何かである、と言えよう。
「一から作っている」という幻想
ところで、コンパイラの黎明期には、コンパイラの生成物よりも、人が直接書いた機械語・アセンブラの方がパフォーマンスが高かったと聞く。今やコンパイラにおける自動最適化技術の発展により、下手な手書きアセンブラよりもコンパイラの生成物の方が高いパフォーマンスを得られる事も多かろう。しかし、そうでない時期は存在していた訳だ。
そのような時に保守的な向きから出てくる指摘に、やはり一からプログラムを作れなければ駄目だろう、というものがあると思う。現在の生成AIによるソースコード生成にも同じ事が当てはまろう。生成AIの出力を完全には信用出来ない以上、その内容をレビューできる必要はあって、それ即ち、そうしようと思えば自分でそれを一から作れる能力があるという事ではないかと。私も大概保守的な方で、感覚的には同じ意見である。
ただ冷静に考えてみると、「一から作れる」というのはそもそもどういう事だろうか。例えば、冒頭で例示したランダムタイマーを、私は「一から作った」と言えるのか。確かに、あれを構成しているHTML・CSS・JavaScriptは私が全て手ずから書いた6ものである。ドキュメントや関連記事を多少調べはしたが、基本的に、それらを理解・整理した上で自分で書き起こした。しかしそれだけである。画像・音声素材は自分で作ったものではない。そもそも、あのランダムタイマーの動作環境たるブラウザ自体、当然私が作った訳ではない。HTML・CSS・JavaScriptそのものの仕様もまた、当然私が定義したものではない。その点、私はウェブ標準というお釈迦様の掌の上7であれを作ったに過ぎず、その視点から見れば、とても一から作ったとは言えない。
もう一つ例として、コンパイラを考えてみよう。あるコンパイラを要する高級言語を扱う際には、明らかにそのコンパイラという掌の上でしか動けない。ではコンパイラを作れれば「一から作れる」と言えるか？コンパイラをコンパイルするための処理系は？機械語が書ければ良いのか？機械語が書けたとしても、それは動作環境のCPUアーキテクチャに依存している。ではCPUが設計できれば良いのか？だとしても、今度は物理的な意味でCPUを作らねばならない。生産工場を持っている？では次は材料を調達せねばならない、と、キリがない。この流れは極度に簡素化しているが、それですら本当の意味で何かを厳密な意味で「一から作れる」人など存在し得ない。誰もがお釈迦様の掌の上にいるのである。この文脈におけるそれは、具体的には、様々な技術、ひいては人間の相互依存によって構成される分業の社会である。当たり前の事として、社会全体の視点においてその方が効率が良い。
それを踏まえると、生成AIが出力するソースコードをレビュー出来なければならないという事は変わらないが、それを「一から作れる」事と等価とするのは傲慢なのだろう。我々に必要なのは、同じお釈迦様の掌の上にいる兄弟子、くらいのスタンスだろうか。
生成AIは「便利な道具」を脱するか
一方で、生成AIそれ自体がお釈迦様の掌であるように扱われる日が来る事も、可能性としてはあるだろうと思う。つまり、今のコンパイラのように、プログラミングにおいてほぼ盲目的に信用できる基盤的機能になるという事である。そうでない限りは、まだまだ、プログラマの仕事を軽減してくれる便利なツールの枠からは出られない。それを脱するまでには、上掲のようにまだ問題は多くあり、恐らく生成AI技術の進歩だけでは解決できない。しかしそれを乗り越えられたならば、それは正にプログラミング方法論におけるパラダイムシフトと言えよう。
コンパイラが当たり前に存在する時代にプログラミングを始めた身として、これからそのパラダイムシフトが起こるのか否かについて、興味深く見ている。
余談① ー 先輩とpow
大学学部生時代、研究室の先輩に、センサネットワーク端末のプログラムを書いている人がいた。所謂組み込み環境・マイコンのプログラミングであり、Cのソースコードを当該マイコン向けにクロスコンパイルして焼く、という事をされていた。一時期その先輩が、pow8が使えないと嘆いていた。math.h定義の数値処理用関数のライブラリをリンクすると、出力されるバイナリのサイズが大きくなりすぎて当該マイコンのメモリサイズを超えてしまうのだ。先輩は嘆きながらpow等価の関数を自前で9拵えていた。
「一から作っている」のか否か、の話題を考える時、いつもこのエピソードを思い出す。少なくとも私は、powを自作した事はない。
余談② ー 「ピタゴラ装置をじゅんびする装置」
長男も次男もNHK「ピタゴラスイッチ」が好きである。中でもやはり、特にピタゴラ装置を好む。私も好きである。
その中に、「ピタゴラ装置をじゅんびする装置」というものがある。読んで字の如く、ピタゴラ装置の構成要素を並べて準備する部分がピタゴラ装置化されている。装置を準備する装置、言い換えればプログラムを作るプログラムというメタ視点を提示する含蓄ある装置で、中々見応えがある。まさしく本エントリでも度々取り上げたコンパイラの話題にも通じる。
ただ、最初見た時の感想としては、凄いなと思いつつも、例えばドミノの部分などは事前に用意されている一式を運んできて設置するだけなんだなー、等といったことも思ったことを覚えている。しかしよく考えてみれば、我々のプログラミングだってそんなものである。これは上掲のpowの話と同根で、普段我々は、既にあるライブラリ機能を組み合わせて新しいプログラムを作っているのだ。毎回全ての機能を「一から作っている」訳ではない。そこまで含めて、改めて含蓄に富んだ装置であると思っている。
-
かなりシンプルに呼び出せる関数であるが、バッファオーバーランを起こす危険があるため利用すべきではない。代わりに
fgetsなどを利用すべき。↩ - かつては良く使われたが、文書の意味構造に関係ない要素であり現行のHTML標準では廃止されている。CSSを利用すべき。ここでの「かつて」は20年とか前の話である。↩
- 少なくとも本来望ましい姿としては。↩
- 私はその時代を直接知っている訳では無く、歴史として聞いた事があるだけである。↩
- その信頼は、企業や、裾野の広いオープンソースコミュニティによって保たれている。↩
- 久しぶりにちょっと手を動かしたかったので。↩
- 慣用表現として使っているのであって宗教的意図はない。本エントリ中、他の箇所における同表現についても同様。↩
- Cの数値処理ライブラリに含まれる冪乗を計算する関数。↩
-
その先輩が必要としていたのは、冪指数が自然数に限定される簡単な計算ではなく、有理数を冪指数に取るものであった。当然、Cの数値処理ライブラリ中の
pow関数はそれもできるので、そのまま使えれば苦労はなかった訳だが。↩
