まいの雑記帳

「LLMがプログラミングするのなら直接マシン語書けるんじゃね?」←そんなわけがない

投稿した日
2026/01/09
更新した日
2026/01/09
読了まで
5.68分で読み終われます (3,407文字)

# はじめに

ここ最近、なんちゃって技術界隈で、なんだかすごい言説が流れてくるようになりました。

曰く、「現代の高級言語は人間がバイナリを読み書きするための単なる中間言語に過ぎないのだから、LLMが直接実行可能なバイナリを生成すればいいのではないか」とのこと。これを聞いた瞬間、まともな技術者なら、苦笑い、爆笑、冷笑(あるいはその他の否定的な感情)を禁じ得なかったのではないでしょうか。

彼らの言う、LLMでプロダクションレベルのコードが書ける時代(笑)では、それが合理的なものに見えているのかもしれません。しかしそれは「明日から全員、口で喋るのをやめて脳波で直接テレパシー通信しようよ!!」と言われるくらい、現実味のない笑い話です。

なぜ、現代のLLMによるバイナリコード出力がこれほどまでにナンセンスで、実現不可能なお笑い草なのか。技術的な無理解とその無謀さをあえて基礎的な観点から整理して笑い飛ばしてみましょう。だいたいそういう内容の記事です。

# Excel方眼紙の呪い

人間が直接コードを書かず、何か別の上位概念からシステムを生成しようという発想自体はそう新しいものではありません。LLMが覇権を握る以前から、この国では「Excel方眼紙さえ完璧ならシステムは動く」と信じて疑わない人々が彷徨っていました

「設計書さえ完璧に記述すれば、あとは誰がコードを書いても同じ。コードなんてただの実装作業でしかないんだから。」

そう謳って構築された、数千億円規模とも言われるの某銀行の巨大システム群が何を生み出したか。それは、誰も全容を把握できず、メンテナンス不能に陥った巨大なブラックボックスでした。

ちなみに、某銀行のシステムが、特定のツールで作られたかどうかなど些末な問題です。ここでの本質的な問題は、マルチベンダによる巨大な分業体制の中で、設計と実装を完全に切り離し、言い換えれば、人をコンパイラのように扱ったことにあります。

その結果どうなったか。コードを見なくていいはずが、コードと乖離し続ける膨大な設計の整合性を取るために、人間が血眼になってExcelを管理する羽目になりました。

厳密な仕様定義と、優秀なエンジニアを大量投入してなお、この苦しみです。確率的にしか動かない現代の残念なLLMにバイナリを生成させればどうなるか、想像に難くありません。

実装を軽視し、抽象的な指示だけでシステムが動くという妄想は、過去に我々が大量のお金と時間をドブに捨てて学んできた、SIer仕草の悪しき再生産に他なりません。出来上がるのはシステムではなく、誰も中身を理解できず、修正も検証も不可能な巨大な産業廃棄物です。行く先にはまたしても、何人もの屍が積み上がることでしょう。

中には、こんなこと🔗を本気で言う人もいます。

「なんか不具合あったらAIに直してって言えば、バイナリ解析して修正してくれるんでしょ?(意訳)」

なるほど。原因の特定も、修正の妥当性も、影響範囲の検証も、すべて省略できる魔法の言葉があるらしい。もしそれが本当なら、我々はとっくにデバッガもテストもCIも捨てているはずです。

# 高級言語はセマンティクスを定義する

これら主張の根底には、プログラミング言語は任意バイナリへの変換を楽にするための中間言語であるという誤った認識があります。これは大きな間違いです。

現代において、高級言語の本質は、ハードウェアの抽象化だけではなく、システムが何であるかというセマンティクスの定義そのものです。そしてさらに重要なのは、高級言語は表現力を上げると同時に、意図的にできないことを増やしているという点です。

RustやGo、TypeScriptなどの現代的な言語を見れば明らかですが、これらは「メモリ領域を勝手に操作できない」「型が合わない計算はできない」といった強力な制約を持っています。なぜそんな制約を入れるのかといえば、自由度と検証可能性がトレードオフの関係にあるからです。

制約があるからこそ、コンパイラは「このバイナリは言語仕様上のメモリ安全性が担保されている」「この並行処理は競合しない」といった、ある意味での数学的な正しさを検証できます。LLMに生のバイナリを直接扱わせるということは、安全性を担保するための制約を全てかなぐり捨て、メモリ破壊もセキュリティホールも作り放題の無法地帯に放り込むことを意味します。ガードレールを撤去してゴツいクソデカスポーツカーを自動運転させるようなもので、事故が起きないわけがありません。

# コンテクストウィンドウとトークンコスト

現実的なリソースとお金の話をしましょう。

実行バイナリの情報密度は、高級言語で記述されたソースコードに比べて極めて低く冗長です。例えば、Goでfmt.Print("Hello world!")と書けば済む処理も、バイナリになれば、システムコールの番号をレジスタに入れ、メモリアドレスを指定し、割り込みを発生させ、スタックを退避し…といった細かな命令コードの羅列になります。ソースコードなら数行で済むロジックが、バイナリデータとしては数KiB, MiBに膨れ上がります。

現在のLLMには、コンテクストウィンドウの限界があります。前述のような、意味の詰まった高級言語でさえ、大規模なシステムを読み込ませればコンクキスト溢れを起こして使い物にならないのが現状です。そこに、冗長極まりないバイナリを流し込めばどうなるか。一瞬で埋まり、LLMがまともに期待する動作をしてくれることはまずないでしょう。

最近ではだいぶ安くなったものの、LLMの出力コストは、安いものでも1万トークンあたり数円〜数十円かかります。数MiBにも及ぶバイナリデータを生成させるために、数万、数十万円の金銭を支払うつもりでしょうか?

手元のPCにあるコンパイラを使えば、事実上0円かつ数秒で、正確に変換してくれる作業を、わざわざ高コストで不確実性のあるLLMにやらせる合理性は、どこにも存在しません。

まともな頭があればこのくらい分かりそうなものですけどね。

# コンパイラがどうの

「コンパイラなんてただのバイナリ変換機だろう」と思っているなら、それも認識を改めるべきです。現代のコンパイラ多くは、過去数十年にわたる人類の英知と膨大な検証の結晶です。

コンパイラは単に変換しているだけではありません。ループの展開やデッドコードの削除、パイプラインを停滞させないための命令順序の並べ替え、レジスタ割り当ての最適化など、高度な処理を厳密に行っています。同じソースコードを食わせても、コンパイルオプション一つで生成されるバイナリは大きく変わってしまいます。

良くも悪くも、LLMは確率的な出力をするものです。なんとなくそれっぽい文字列を生成することには長けていますが、バイナリを正しく生成するなんてことは当然不可能です。

残念なことに、世界には無数の環境があり、命令セットも多岐にわたります。コンパイラは、これらの組み合わせの差異を吸収して、それぞれの環境に最適なバイナリを出し分けてくれています。これをLLMにやらせるということは、OSやプロセッサごとの微妙な仕様の違いやシステムコールの番号を網羅的に充分な量の学習をさせ、環境ごとに毎回何MiBものバイナリを生成し直させるということです。正気の沙汰とは思えません。

# さいごに

ひとつ、勘違いしてはいけないことがあります。

各社が提供しているエージェントは、決して論理を組み立てているわけではありません。あれは膨大な学習データから次に来そうな文字を確率的に吐き出しているだけであり、そこに意思も、理解も、厳密なロジックも存在しません。

だからこそ、私たちは高級言語を使うのです。

確率的に嘘をつくことしかできない残念なLLMが吐き出したコードを確認した上で、コンパイラという決定論的な論理エンジンに通すことで、初めて整合性を担保できるからです。

LLMが直接バイナリを書けばいいなどという妄言は、これらの前提条件を捨てているといっても過言ではありません。

少なくとも技術者を名乗るのであれば、LLMガチャ師仕草をやめて、その残念な自らの頭を活用してみてはいかがでしょうか?

驚き屋を追いかけてのお勉強(笑)には熱心なのに、抽象化された高級言語すらまともに読み書きできないのであれば、技術者としてお話になりません。