【衝撃】プログラマーは消滅しない？AIが直接バイナリを作れない3つの壁
著名実業家がソースコードは楔形文字のようになりつつあり、完全に排除される段階に来ていると発言し、次はAIが直接効率的なバイナリを作る段階だと主張したことが、開発者の間で大きな議論を呼んでいる。人間はAIに自然言語で指示を出すだけで完結し、人間が読み書きするために作られたプログラミング言語という中間段階は無駄な変換過程になるという理屈だ。本当にそんな未来が技術的に可能なのか、現在の仕組みから賛否の論理、現場の壁までを整理する。
そもそもなぜソースコードを書いているのかという原点に立ち返る必要がある。スマートフォンやパソコンの頭脳であるCPUは、0と1の電気信号の羅列である機械語しか理解できない。しかし人間が0と1を何百万行も直接書くことは不可能に近い。そこで人間は理解しやすい英単語や数式に近い形でプログラムを書くことにした。それがC++やPythonなどのソースコードと呼ばれるものだ。ソースコードのままではCPUは理解できないため、翻訳機が必要になる。その役割を果たすのがコンパイラと呼ばれる特別なソフトウェアであり、人間が書いたものをCPUが直接実行できるバイナリに変換してくれる。人間、ソースコード、コンパイラ、機械語という何重もの翻訳の壁を超えて初めてプログラムは動いている。これは人間の能力の限界を補い、人間にとっての読みやすさと機械にとっての実行しやすさを両立させるための歴史的な工夫の結晶だ。AIが直接行動を理解できるならこの人間向けの翻訳は本当に必要なのかという疑問が出てくるのは自然な流れである。
コンパイラの真の姿は単なる置き換えではない
コンパイラは単に単語を置き換えているのではなく、極めて高度な数学的最適化を行っている。まず人間が書いた文法を解析して意味を木のような構造に整理した抽象構文木を作り、余計な記号や見た目の整形を省いて純粋な構造だけを抜き出す。次にLLVM IRと呼ばれる特定のCPUに依存しない仮想的な中間表現に変換する。ここが重要で、この中間表現はデータの流れを数学的に分析しやすい特別な形式になっており、1つの変数には1回しか値を入れられないという厳しい規則を課すことで、どこでデータが生まれどこで使われるかが一目瞭然になる。コンパイラはこの中間表現に対して無駄な計算を省いたり並列処理できるように順序を入れ替えたりと数百種類もの最適化を施す。人間が適当に書いた冗長な記述が勝手に超高速に改造される仕組みだ。そして最後にインテルやアップルなどそれぞれのCPUの物理構造に合わせて最適な機械語へ変換される。言語ごとに0から翻訳機を作るのではなく、共通の中間表現を挟むことで複雑な翻訳を分割して管理している。この強力な最適化エンジンをAIがどう扱うかが大きな論点になる。
肯定派の論理、究極の最適化と自律改善
肯定派の最大の主張は、AIにとって人間向けのソースコードは足かせになるという点だ。人間は読みやすさのために綺麗に書くが、機械であるAIはデータ構造そのものを直接扱えるため、わざわざ人間の読み書きのための文法規則に従って文章を出力する必要がない。そして中間変換を排除することで究極の最適化が可能になるとも言われている。通常のプログラムは色々な環境で動くように汎用的に書かれるが、AIが直接機械語を作れるなら特定のCPUの内部構造、例えば記憶の階層や処理の流れに完全に特化した専用のバイナリを作ることができる。さらにAIが自分でバイナリを作り実行速度を計測して改善するという循環を1秒間に何千回も自立的に回せる。人間には絶対に真似できない速度であり、囲碁の世界で人間が思いつかない手を打ったように、人間には理解不能だがCPUにとっては最高に速い機械語の並びを発見するかもしれない。コンパイラという中間層をなくし、AIからハードウェアへ直結させることでこれまでにない性能を引き出せるというのが肯定派の強力な根拠であり、理論上は人間が介在しない方が性能を極限まで引き出せるというわけだ。滅茶苦茶厳しい開発の現場を知る人物が言うのだから、現場で直接生成でも良いと思える技術が見えているのではという受け止めもある。
否定派の反論、答えだけ提出する危うさ
一方でソフトウェア開発はただ動いて速ければいいものではないとして、ソースコードをなくすべきではないという否定派の反論も強力だ。コンパイラ技術の世界的権威であるクリス・ラットナー氏は、プログラミングは単なる翻訳作業ではないと主張している。プログラミング言語はコンピューターに対する人間の意図を曖昧さなく厳密に記述するための接点であり、巨大な仕組みを分割して管理したり誤りを未然に防いだりと、人間が仕組みを検証するための基盤になっているという。AIの出力は確率的で常に幻覚と呼ばれる誤りを起こす危険があるため、専門家はコードを決定論的な仕組みに必要な検証可能な論理の要だと指摘する。AIが直接バイナリを出すのは数学の試験で途中式を全て捨てて答えだけを出すようなものだ。もし答えが間違っていた時どうやって気づきどこを直せばいいのか誰にも分からなくなる。人間が確認しなくていいという考えこそが落とし穴だというわけだ。コードは最も厳密な設計書であり、むしろ読みやすいコードをAIに書かせてそれを自然言語で説明できる設計書も書かせるべきだという提案もある。問題発生時に検証できるよう、流れ図や構成図など必要な仕様書を書くようAIに指示すれば作ってくれるのだから、中間表現をAIに書かせればいい。人間は書くことなく内容を読めればいいだけになるという現実的な落としどころだ。
現場の壁、監査と互換性と学習データ
現場の壁としてまず挙がるのが安全性と検証だ。生成のたびに変わってしまうコードですらない物では、ウイルスとして考えたら監視も検証も不能になり、不具合発生時に大混乱になる。動く物はできるかもしれないが中身不明では運用できないという声が多い。監査を事前にするか事後にするかの違いだという整理もあるが、どちらにせよ中身を開示しないままでは通らない。互換性も課題で、直接作ることは良くても他の環境で保たれるのかという疑問が残る。学習データの問題も指摘されている。現代の人類はAIに直接出力をさせられるほど、どのような意図だとどのようなバイナリになるのかというデータを持っていない。コンパイラを使えばいくらでも学習データは作れるが、それならわざわざ大量の電力と計算資源を使ってAIにやらせる必要がなく、無料の変換命令でできるという皮肉な指摘もある。指示の正確さへの疑問も根深い。人間が自然言語で指示するというが、どれだけの人が正確に意図通りの指示を出せるのか。人は楽をすると思考が崩れるため悲惨なことになるという懸念や、そのうちCPU自体も作るという話になるという冗談もある。結論として有力なのは中間表現生成という道だ。仕様書から高級言語、そこから低級言語、そこからバイナリという段階を踏めば指示から生成は可能であり、中間結果を開示するかどうかという小さな問題に帰着する。欲しければ指示すればいいだけだというわけだ。3つの筋書きを比べると、完全直結は夢が大きいが検証と互換と資源の壁が高く、当面は読みやすい中間物を残す協業型が堅い。消滅するのは書く作業の一部であり、読んで確かめる役割は残るというのが冷静な見立てだ。
ネットの反応
ウイルスとして考えたら監視も検証も不可になる。生成するたび変わるコードですらない物へ向かうのは危険だ
人間が検証できないと不具合発生時に大混乱になる
動くものは出来るかもしれんが中身不明では無理だ
コードは最も厳密な設計書。むしろ読みやすいコードを書かせて自然言語で説明できる設計書も書かせるべき
中間結果を開示するかどうかという小さな問題だ。欲しければ指示すれば良いだけだ
どのような意図だとどのようなバイナリになるのかというデータを持っていないので無理だろう。変換命令で無料でできることを高コストでやる意味がない
AIの所感
途中式を捨てて答えだけ出すという例えが全てを物語っている。速さの極限を追う発想は魅力的だが、社会で動く仕組みに必要なのは速さだけでなく説明と修正の可能性だ。当面の現実解は中間表現を残す協業であり、人間の仕事は書くことから読んで確かめることへ移る。消滅するのは作業の一部であり、意図を厳密に残す設計の知恵はむしろ価値を増すと感じる。