たびたび見かける「そのうちAIが直接バイナリを吐くようになるんでは」という話、原理的に難しいし、できるとしてもだれもやらないし、できるようになったとしてもだれも使わないので、今の仕組みのAIが直接バイナリを吐く未来は来ないと思います。
ここらへんも参照
AIがコードを書くようになるなら、AIだけに理解できる言語を作ればいい、のかな？ - きしだのHatena
AI専用のプログラミング言語は現れない - きしだのHatena
AIが読み書きするコードも読みやすいほうがいい(トランスフォーマの特性の考慮やリーダブルコードについて追記) - きしだのHatena
プログラミング言語は人間が扱いやすく機械が実現できるよう論理を表現するものでありプログラムの本体 - きしだのHatena
※ LLMが生成したコードを内部でコンパイラを呼び出してバイナリにするというのは、例えばここにあるようなプログラム作ればすでに実現可能なので「そのうち」などと言う必要はありません。
LangChain4Jで雑なAIコーディングエージェントを作る - きしだのHatena
原理的に難しい
まず、今の仕組みのAIはロジックをアセンブリで組み立てるのがかなり苦手です。
アセンブラで処理を書くにはレジスタの割り当てを考えて、そのレジスタがその時点でどの役割なのかというのを把握しながら組み立てる必要があります。
また、いまのコンパイラはかなりの最適化を行っていて、プログラムの実行パフォーマンスはコンパイラがいかにプロセッサの仕組みを有効活用できるかにもかかっています。
そうすると、プロセッサの種類や世代ごとにどういう最適化が可能なのかを適用させる必要があります。しかしこれはかなり微妙な部分で、x86であれば年代ごとに機能が増えてるだけだったりしますが、Armであればプロセッサごとに機能を取捨選択しているので組み合わせが難しいです。
OSごとにも違うコードを出す必要があります。Windowsであれば95対応のコードでもWin 11で動くのでどこかの時点に対応していれば問題ないですが、Linuxであればディストリビューションごとに違いがあります。iOSなんかは冷酷に古い機能を切り捨てて互換性のないバージョンアップをしているので、古い機能を使わず新しいバージョンに対応したコードを書く必要があります。
そして、そういった違いは微妙なものなので、混同なく書き分けるというのはAIにはかなり難しいです。
作るのが大変
まあ原理的に難しくても対応環境を絞るなど回避策はあるので、問題なしとしましょう。
AIって、GPUを与えておけば勝手に育って新しい能力を獲得するイメージを持ってる人がいるかもしれませんが、バイナリをちゃんと実用レベルで吐けるようにするには、要件とそれに対応したバイナリを組にしたデータセットを大量に作って学習させる必要があります。
要件に対応したバイナリは普通にコンパイラを使えばいいので生成可能だけど、問題はどういう要件をデータセットに含めるかですね。
実用に耐えるコード生成をするには、結構コストをかけて要件を選んで揃えてデータセットを作る必要があります。
CPUドキュメントや実装解説など他のデータから自然にプロダクトレベルのバイナリ出力能力を獲得できるものでもないので、そこにビジネスチャンスを感じてコストかけてやろうとする人が出るかどうかというのが一番の問題ですね。
コンパイラ使えば秒で確実に性能高くできることをAIで再現するために、そこまでコストをかけて対応するモチベーションを持つ人や組織は出てこなさそうです。
実現するとしても「直接」にはならない
試しにアセンブラを書いてもらってみます。
ローカルなLLMにも割とかけてびっくりなんですが、ここで「14分間の思考」というのに注意ですね。
この14分というのはローカルで動かしてて遅めだからちゃんとサーバーで動かすと5分で終わる可能性もあります。
けど、ここで割と長い時間の「思考」があることに注意です。
ここ最近のAIの能力向上は、この「思考」の過程にあります。もし「直接」バイナリを吐くところまで性能が向上するとしても、その性能向上は「思考」に依存するはずです。
で、その「思考」で何してるかというと、いろいろ実装の戦略を考えるわけですね。
その中では、こうやって仮コードで考えたりもしています。
そして一旦コードを書いてみて検証ということが行われます。
最初に「原理的に難しい」と書きましたが、この「思考」の過程を工夫することで実現可能にはなると思います。ただ、その場合は、AIがバイナリを吐くとしても「直接」にはならないんじゃないかと思います。
で、思考の過程で仮コードで考えるなら、最初からそのコードが使えたほうがいいんじゃない？ってなりますね。
使うのにもコストがかかる
じゃあ、AIを学習させまくって、ほんとに直接バイナリコードが出力できるようになったとしましょう。
Javaだったとして、こういったコードに相当するバイナリがどうなるか見てみます。
void main() { IO.println("hello"); }
で、コンパイルしてファイルサイズを見てみます。
>javac hello.java
>dir hello.class
Volume in drive C has no label.
Directory of C:\Users\naoki\asm
2026/01/07 10:26 304 hello.class
1 File(s) 304 bytes
304バイトになりました。
これ、AIが出力するとしたら、304トークンになりますね。
一方で先ほどのコードは11トークンです。
「いや、バイナリにはそのコード以外のデータも入っているから」と思うかもしれませんが、そういったバイナリのヘッダやフッタ、エントリポイントの情報を付け加えてくれるのも言語処理系の仕事で、そこを肩代わりするのであればAIがそこまで吐き出せないといけません。
11トークンが304トークン。なんか3バイトくらいまとめて扱えてトークンが圧縮されたとして100トークンだとしましょう。
AIの課金って出力トークン単位ですね。出力時間もトークン単位です。
コンパイラを使えばちょっと出てきたコードを一瞬でコンパイルして動かせばいいし形式的な間違いがあれば見つけてくれるのに、10倍のお金と時間をかけて安定性に不安のあるAIコードを使う人がいるように思えないですね。
不具合修正や変更が無理
先ほどアセンブラを出してもらったもの、BASICを指定すると5分考えていました。
ただ、実行するとエラーが出たので伝えて修正してもらいます。
ちゃんと動きました。
これがバイナリ直接だとこういったエラーは出ず、どこかで変な動きになるかセグメンテーションフォールトなどになります。
そこから原因を探すのはかなり大変です。
AIには典型的な不具合の現象から不具合内容が見つけれるよう学習させる必要もあります。
また原因がわかったとしても、バイナリの中から該当部分を見つけるのもかなり難しく、そして修正したらそれ以降のアドレス計算、レジスタ割り付けなどもやりなおす必要がありますね。
これは追加、変更でも同じことがいえます。
バイナリ直接出力は、一発目ができたとしてもそのあとが大変です。
まとめ
AIでの直接バイナリ出力は、原理的に難しい、原理的に可能でも作る人がいない、実現しても使う人がいない、使おうとしても仕事で使い物にならない、ということで、そういうことができるようにはならないと思います。
ロジカルにできることはAIにやらせずロジカルに。
