AI時代のプログラミング言語のあり方を考える

去年ぐらいから、自律的にコードを書いてくれるAIエージェントが複数登場しています。mizchi氏の「CLINEに全部賭けろ」という記事は日本のプログラマーの間ではあまりにも有名でしょう。

Clineを使うかはともかく、AIエージェントにコマンド実行の権限を与えて、自律的にコーディング・ビルド・テストさせるのは当たり前になりました。最近はClaude Codeが人気のようです。

私はそういう動きを横目で見つつプログラムをせっせと手書きしていたわけですが、今年の正月に重い腰を上げてClaude Codeを使い始めてみました。私自身はそういうAIエージェントをまだそこまで使い込めていないので、感覚が掴みきれていないかもしれませんが、この記事は現段階での使用感と見聞きした内容に基づいて書いています。

例によって私はプログラミング言語というものに関心があるので、この記事ではAI時代のプログラミング言語のあり方について考えてみます。

プログラミング言語の選定で何を重視するか

何かやりたいことがあって、AIにプログラムを書かせる時、どういうプログラミング言語を選ぶでしょうか？

プログラミング言語を選定するときの側面はいくつかあると思います：

  • フロントエンド：構文や型システム
  • バックエンド：ターゲットや最適化
  • 資産：ライブラリーや周辺ツール

文法が好きだからこの言語を選ぶ。型システムが好きだからこの言語を選ぶ。シングルバイナリーを出力しやすいからこの言語を選ぶ。Webフロントエンドを書きたいからこの言語を選ぶ。機械学習の資産が豊富だからこの言語を選ぶ。

色々あると思いますが、AIがプログラムを書く時代になると、フロントエンド側の良し悪しは比較的重要じゃなくなってくるのでは、という気がします。多少記述が冗長でも、バックエンドや資産が有用なら使ってみようという気分になる。型システムが気に入らなくても、AIが正しいコードを書いてくれれば問題ない。

言い換えると、これから流行らせたいプログラミング言語は、バックエンドや資産を重点的に整備すべき、ということになります。

型システムはどうなるか

型システムはどうでしょうか。SNSを観測していると意見は様々で、「正しいプログラムを書けるLLMには型システムは邪魔物でしかないので型システムのない言語が流行る」という意見から、「人間の手で書きづらかった定理証明もLLMなら書いてくれるので静的な保証の強い言語が躍進する」という意見までありそうです（これらの意見は、SNSで見た生の意見に私のうろ覚えフィルターをかけた物なので、検索してもこの通りの意見は出てこないと思います）。

個人的には、型システムは色々な面で有益なので、AIに生成させる場合でも型システム（少なくとも、何らかの静的解析可能性）があると捗るのではないかと思います。

例えば、ちゃんとした型システムであれば、静的な検査が通っていれば実行時にある種のエラーが出ないことが保証されます。これは「AI生成物に対してレビューを最小限にする」という運用と相性が良さそうです。

例えば、関数の型が明示されていれば、AIが実装を読まなくてもどういう種類の値が返ってくるか分かりそうです。型システムのない言語だったら、「通常は配列を返すが、空配列の代わりにfalseが帰ってくる」「空配列を渡した時だけ返ってくる多次元配列のshapeが違う」ような治安の悪い挙動も想定しなくてはなりません。

型システムのない言語を生成させる場合でも、ある程度の規模で正しく動作するプログラムを書けるAIならば内部的に型システムに相当する概念を持っているのではないでしょうか。なので、正しいプログラムを生成できるAIにとっては型システムは指針にはなっても障害になることはないのではと思います。

定理証明を使うような強力な型システム（依存型）やその他静的解析が流行るかどうかについては、そこまで楽観的になれません。人間にとって難しいタスクは人間の知能を模倣した存在にとっても難しいのではないでしょうか。少なくとも、汎用のコーディングエージェントではなく、定理証明用に特化したモデルが必要になるのではないかと思います。あるいは、定理証明支援系とLLMで対話させる程度で十分なのか。私はこの辺については素人なので、眉に唾をたっぷり塗って読んでください。

AIにフィードバックできることが大事

Claude Codeを使ってHaskellコードを書かせてみると、テストがない機能についてはREPL（対話環境）を呼び出して実行結果を確認していました。下手な人間よりも勤勉ですね。

AIが一発で正しいコードを生成できないことはよくあります（TypeScriptやPythonのような超メジャー言語ならそういうことも少ないのかもしれませんが）。そういう場合に、AIがコードを修正できるように処理系がガイドする機能は重要そうです。

具体的には、

  • REPLで関数の動作確認や型の確認を行えるようにする（つまり、REPLがあると便利）
  • エラーメッセージを親切にする
    • 型システムがあると親切なエラーメッセージを出すのに役立ちそうです。
  • LSPやMCPで連携できるようにするといいかもしれない

という具合です。

マイナー言語はどうなるか

インターネット上に資料の多いメジャーな言語がLLMにとって書きやすいのは間違いないでしょう。では、マイナーな言語はどうでしょうか？

私がClaude CodeにHaskellを書かせた感じでは、多少手直しは必要なものの、割とちゃんとしたコードを出してくれるという印象です。あまり高度なコードを書かせたわけではないのでアレですが、Haskell程度ならある程度は書いてくれるということです。

学習データがもっと少ない言語はどうでしょうか。LLMの汎化能力に期待して良いのなら、最低限の文法を教えてあげれば、既存の言語から概念を転用して書いてくれそうです。

最近、Flixという言語をClaude Codeに書かせたという記事を見ました。Claude CodeにFlixのドキュメントを与えて、適宜参照させる感じです。コンパイラーも呼び出せるようにします。Flixはエフェクトという機能が特色のようです。

結論としては、LLMは新興言語にも有益だということのようです。

mizchi氏がMoonbitという言語をClaude Codeに書かせた話もあります：

マイナー言語はエコシステムが貧弱なことが弱点ですが、AI支援も活用してエコシステムをゴリゴリ整備していく人が一定数いれば差は埋まっていくんじゃないかと思います。楽観的すぎるでしょうか。

LLMが機械語を直接出力する日は来るか

SNSを徘徊していると、「プログラミング言語が不要になってAIが直接機械語を書くようになるのでは」という意見がたまに見られます。この類の意見は定期的に見かけますが、直近で見かけたものはこれです：

正直、これは真面目に反論する必要あるか？というレベルの意見なのですが、最低限の反論を書いておきます。

一つは、機械語は機械に依存するので、機械語で書くと移植性が損なわれます。AIに機械語のプログラムを書かせるのにどのくらいのコスト（GPU、電力）がかかるのかは分かりませんが、x86-64向けに生成させたプログラムをArm64向けには再利用できません。同じx86-64であってもWindows向けとLinux向けでは書き分けが必要です。しかし、高級言語というレイヤーを介せば移植性を獲得できます。

一つは、機械語はあまりにも低レベルです。クラスやモジュールはおろか、関数という概念すらありません。そして、ある程度の規模のプログラムを書くには何らかの高級な概念が不可欠になってくると思います。自然言語を入力として機械語を出力するLLMを訓練することは理論的には可能かもしれませんが、そういうLLMの内部を調査したら関数・データ型・モジュール等の概念を自力で再発明していた、というのがオチではないでしょうか。そういう実験のためにGPUと電力とデータセット作成の労力を費やす人が、果たして現れるのでしょうか。

（まあ、「自然言語から機械語を生成させるように訓練したAI」の内部を解析したら人類にとって未知の抽象化が発見された、的なSF的展開にワクワクしないと言ったら嘘になりますが。）

機械語で書いたプログラムは間違えた時のデバッグが難しいという問題もあります。機械語で不正なプログラムを書いたら典型的にはillegal instructionやsegmentation faultが出て、有益な情報はデバッガーを使わないと得られません。デバッガーがあっても、高級言語のデバッグ情報がないとデバッグは大変です。私は去年、Haskellプログラムのsegmentation faultのデバッグを行う機会（GHCデバッグ日誌 CI編）がありましたが、C言語の呼出規約と互換性がない世界でのデバッグはなかなか大変でした。

あとは、「Webで動かす用途では機械語ではなくJavaScriptやWebAssemblyが必要になる」というものもありますが、これは重箱の隅ですかね。

もちろん、特殊な用途であれば機械語・アセンブリー言語をLLMに書かせるということはあり得ます。現状でもアセンブリー言語を書くような用途（命令の特性を考慮して最適化したい、SIMD等の特化した命令を活用したい、など）はあるわけですし。ffmpegがアセンブリー言語を手書きして高速化している、というような話は聞こえてきます。しかし、普通のアプリケーションを書くような用途ではAIに高級言語を生成させる、というスタイルが続くのではないかと思います。

あるいは、技術的特異点に到達してプログラミングを取り巻く環境が大幅に変化した場合は、普通のアプリケーションを書く時でもAIが機械語を直接書くという未来もやってくるかもしれません。しかし、特異点の向こう側を未来予測するという活動にどれほどの意味があるでしょうか。なので、「予測可能な未来では」普通のアプリケーションのためにAIが機械語を直接書くようなことにはならないのではないか、としておきます。

AI時代のプログラミング言語について、いくつか思ったことを書いてみました。私のAIエージェント使用歴はまだ僅かなので、もっと使い込んだ後ならより精密な意見が書けるかもしれません。あるいは、AIエージェントの進化で状況が変わっていくかもしれません。

現時点での私に欠落しているものを一つ書いておくと、トークン数とかコンテキスト長あたりの感覚は私にはありません。その辺の感覚がある人ならもっと突っ込んだことが言えるかもしれません。

AIにコードを無限に生成させられる時代にどういう言語機能があれば複雑さを抑え込めるか、という問題は語る価値がありそうですが、今の私からは良い回答は出てこないので保留にしておきます。

こんな駄文ばっかり書いてないで自作言語処理系の開発を進めろ、という声が聞こえてきそうです。頑張ります。

Spread the love