概要
https://nowokay.hatenablog.com/entry/2026/01/07/111410
詳細内容
## AIがバイナリを直接吐くようにはならない
https://nowokay.hatenablog.com/entry/2026/01/07/111410
AIがソースコードを介さずバイナリを直接生成する未来は、技術的制約、コスト、保守性の観点から現実的ではないと論じる。
**Content Type**: 💭 Opinion & Commentary
**Language**: ja
**Scores**: Signal:5/5 | Depth:4/5 | Unique:4/5 | Practical:3/5 | Anti-Hype:5/5
**Main Journal**: 84/100 | **Annex Potential**: 85/100 | **Overall**: 84/100
**Topics**: [[LLM, コンパイラ, バイナリ生成, ソフトウェア工学, トークンコスト]]
著者のきしだ氏は、一部で語られる「AIがいずれ人間向けのソースコードを介さず、直接バイナリ（機械語）を出力するようになる」という予測に対し、原理、コスト、保守性という複数の現実的な観点からその可能性を明確に否定している。
まず技術的な原理として、最新のプロセッサ最適化やOSごとの微妙な仕様差、複雑なレジスタ割り当てといった低レイヤーのロジックを、AIが混同なく正確に書き分けることは極めて困難である。現在のコンパイラが数十年かけて到達した高度な最適化をAIで再現するためには、要件とバイナリを対にした膨大な学習データが必要となる。しかし、既存のコンパイラが「一瞬で、確実に、高性能に」実現できている領域をあえてAIで代替しようとするビジネス上のモチベーションは、どの組織にも生まれにくいと筆者は指摘する。
さらに、経済性と効率性の観点も重要だ。Javaの極めて短いコード（約11トークン）がコンパイル後に数百バイトのバイナリになる例を挙げ、AIの課金体系が出力トークン単位である以上、バイナリを直接出力させることはソースコードを出力させるよりも遥かに高いコストと長い生成時間を要することを意味する。コンパイラを使えば一瞬で済む処理に対し、わざわざ「10倍のお金と時間」をかけて不安定な出力を得る合理性はない。
また、デバッグと保守性の問題も決定的な要因である。バイナリ出力で不具合が発生した場合、その原因箇所を特定して修正することは困難を極める。ソースコードという「論理の表現」があるからこそ、人間はAIの出力を検証し、誤りを指摘して修正させることが可能になる。最近の「思考するLLM（o1など）」が内部の推論過程でコード的な戦略を用いていることからも、論理を組み立てるプロセスには中間言語としてのコードが不可欠であり、ならばそのコードを成果物として利用する方が全ての面において合理的であると筆者は結論づけている。
ウェブアプリケーションエンジニアにとって、この論考は「AI時代のプログラミング言語の役割」を再定義するものである。言語は単なる機械への命令手段ではなく、人間が論理を把握し、ソフトウェアの同一性を管理するための「インターフェース」であり続ける。AIがどれほど進化しても、読みやすく保守しやすいコードを書くスキルの価値は損なわれないという視点は、今後のキャリア形成においても重要な示唆を与えてくれる。