人がコードを読まなくなるなら、プログラミング言語は誰のためのものか

お疲れ様です！SI事業本部部長の島田です。

今回は手を動かした話ではなく、最近ずっと頭の中にある「これ、どうなるんやろ」を言葉にしてみます。お題は、プログラミング言語の行く末です。まだ答えは出ていないので、私見多めでお届けします。

最近、コードを書いていない

生成 AI をがっつり使ってシステムを作っていると、気づけば自分ではコーディングをしていません。書いていないどころか、正直、1行ずつ読むこともだいぶ減りました。

じゃあ何をやっているかというと、だいたいこの3つです。

• ガードレールを敷く。 AI にやらせないこと、触らせない場所を決める
• ハーネスを厳しくする。 テストやチェックを用意して、通らないものは先に進めないようにする
• 交通整理をする。 要件のインプットからリリースまで、何をどの順番で流すかの段取りを組む

これまでの記事でも「作業は AI、判断は人」と書いてきましたが、開発でも同じ形に落ち着いてきた感じです。

プログラミング言語は、人間のためのものだった

ここでふと思ったわけです。

Python も、JavaScript も TypeScript も、PHP も Java も、もともとは「人間が書きやすい・読みやすい」ように作られたものですよね。コンピュータ自身は機械語さえあれば動きます。わかりやすい変数名も、インデントも、コメントも、全部人間のための工夫です。

その人間が、書かなくなって、読まなくもなってきた。

だったら、人間向けに作られた言語に縛られる必要って、もうないんじゃないか。AI が書いて AI が読む前提の、AI ネイティブな言語が生まれてくるんじゃないか。

調べてみたら、もう出てきていた

気になって調べてみたら、すでに作り始めている人たちがいました。

たとえば Vercel Labs が実験として公開している Zerolang です。リポジトリの紹介文は、そのまま「エージェントのためのプログラミング言語」。

面白いのは、プログラムの本体がテキストファイルではないところです。本体は、型や権限、呼び出し関係といった情報を持った「グラフ」で、AI はそのグラフに問い合わせて、検査つきの変更を出します。人間が読めるテキストは、そこから書き出した「写し」という位置づけです。

README には "Humans ask for outcomes." とあります。人間は結果を頼むだけ、ということですね。

ただし、README 自身が「実験段階なので、本番や機密データには使わないで」と断っています。今日の仕事で使えるものではありません。それでも、「ソースコード＝人が読むテキスト」という前提を外した言語が、実際に手を動かして作られ始めている。ここは押さえておきたいところです。

とはいえ、すぐには置き換わらないと思う

じゃあ来年には Python も TypeScript もお役御免か、というと、そうはならんと思っています。理由は2つです。

1つ目は、AI は「たくさん読んできた言語」が得意だということ。

今の AI が Python や TypeScript を上手に書けるのは、世の中に大量のコードがあって、それを学習しているからです。逆に、世の中にコードが少ない言語では精度が落ちることが、研究でも報告されています。生まれたばかりの言語には、学習するコードがそもそもない。どれだけ AI 向けに設計しても、最初は「AI が一番苦手な言語」から始まるわけです。皮肉な話ですよね。

2つ目は、人間が読まないなら、なおさら「機械が確かめる仕組み」が要るということ。

人が読んで「これは変やな」と気づく機会が減るぶん、機械的に弾いてくれる仕組みの価値が上がります。型が厳しい言語、コンパイラが口うるさい言語のほうが AI と相性がいい、という話を最近よく見かけるのも、同じ理由だと思います。人間には面倒だった厳しさが、AI にとってはちょうどいい手すりになる。

AIネイティブな言語は、「ガードレール入りの言語」になるんじゃないか

ここからは完全に私の予想です。

AI ネイティブな言語は、記号だらけで人間に読めない暗号のようなもの、にはならないと思っています。そうではなくて、いま私たちが外側から敷いているガードレールが、言語の中に入ったものになるんじゃないか。

• 権限が言語に入る。 「この処理は外部と通信していい」「このデータには触れない」がコードの上に明示されて、違反は動かす前に弾かれる
• エラーが AI 向けになる。 人間向けの文章ではなく、AI がそのまま読んで直せる形で返ってくる
• 変更に検査がつく。 古い前提のままの変更や、型の合わない変更は、書き込まれる前に止まる

さっきの Zerolang も、権限の明示や検査つきの変更を特徴に挙げていて、だいたいこの方向を向いています。

いま私は、プロンプトに「やらないこと」を書き、テストを用意し、権限を絞って、AI が道を外れないようにしています。これ、毎回プロジェクトごとに組み立てているんですよね。言語がそこを最初から持っていてくれたら、、、むっちゃ楽になるはずです。

人間が読むのは、コードではなくなる

そうなったとき、人間の仕事はどこに残るのか。

• 何を作るのかを決める（要件）
• 何をやらせないかを決める（ガードレール）
• できたものを受け入れるかどうかを決める（判断）

読む対象も、コードから「仕様」と「検証の結果」に移っていくんだと思います。プログラミング言語が人間のためのものでなくなっても、人間のための言葉はなくならない。むしろ「何をしてほしいか」「何をしてほしくないか」を正確に言葉にする力が、これまで以上に効いてくるはずです。

エンジニアの経歴は、これまで「Java 何年」「PHP 何年」と言語で語られることが多かったですよね。この先は、「どんなガードレールを敷いて、何を任せて、何を自分で判断したか」で語るようになるのかもしれません。

今回のポイント

• プログラミング言語は、人間が読み書きするために作られてきた。 その前提が崩れ始めている
• AI 向けの言語は、すでに実験が始まっている。 ただし、すぐに主役が入れ替わるわけではない
• AI ネイティブな言語は、ガードレールが最初から入った言語になる（と予想）。 権限、検査、AI 向けのエラー
• 人間に残るのは、決めることと確かめること。 読むのはコードではなく、仕様と検証結果

当たるかどうかは数年後のお楽しみ、ということで話半分に。外れていたら、そのときはまた記事にします。

それでは、また現場に出てきます！