AIが賢くなると、AIにわかりやすく人間には理解困難なプログラミング言語が出てくるのでは、みたいな話をよく聞きます。
ただ、次の点から、AI専用の言語は現れないだろうなと思います。
- 意味の記述が必要であることに変わりはない
- すでにAIは独自の言語を持っている
- 低レベルな記述にはコストがかかる
- 作っても学習させるのが大変
意図の記述が必要であることに変わりはない
プログラムを書くときには、「ここを3回繰り返そう」とか「この一連の処理の塊を、この部分だけパラメータで変更可能にしつつまとめよう」とか「xとyをまとめて扱うようにしよう」といった意図をもって処理を書きます。そうすると、その意図が直接書ける言語のほうがいいです。
また、ここでは整数だけ扱うとか、文字列を扱うとか、xとyをまとめたデータを扱うとか、そういったデータ内容を明示すると、プログラムが失敗しにくくなるだけではなく理解もしやすくなります。
結局、AIも修正や機能拡張では自分の書いたコードを見返す必要があります。そうすると、人間向けのプログラミング言語で培われたプログラム表現はAIにも助けになります。
すでにAIは独自の言語を持っている
たとえばpublicをpと書けるような、記述を圧縮した言語が出てくるんじゃないか、って思うかもしれません。
けど、すでにAIは、プログラムに頻出のキーワードを1トークンとして扱っているので、publicもpも違いがありません。
OpenAIのトークナイザを見てみると、ほとんどのキーワードが1トークンになっています。
import java.util.List;だと、.utilや.Listで1トークンになっているのでi juL;と6文字で書くのと差がありません。
また、.utilや.Listで1トークン、つまり特別な文字が割り当てられていることを考えれば、人間が見ているのとは違う字句構造の言語を実は扱っていることになります。"));や");も1トークンです。
結果として、272文字で書かれたプログラムは、次のような67個のコードで表現されたプログラムになっています。
ある意味で、AIは専用の記号体系の言語をすでに持っていると言えます。
大事なのは命令とデータのトポロジー
プログラミングはデータのトポロジーと命令のトポロジーをどう構成するか、プログラミング言語はそのトポロジーをどう表現するかというもので、そういった構造はAIが解釈しようが構成要素は変わらない。
構造が変わらず字句だけ変わるのであれば、改めて作る必要がない。
低レベルな記述にはコストがかかる
もし、抽象度を落として中間コードに近い表現を行う言語を作ったとします。
そうすると、for文での繰り返しを扱うために、多くの命令列が必要になります。さまざまな処理で命令列が増えていきます。
そうなると、必要なトークンが増えます。トークンが増えるということは、トークン数で課金される現状ではコストがかかるということになります。
また、トークン数が長くなれば、その劣化はゆるやかになっているとはいえ、トークン数が短いときよりも性能が劣化します。
その分、コストがかかることになり、メリットがありません。
作っても学習させるのが大変
最後に、もしAI専用の言語を作ったとしても、その言語で書かれた大量かつ多種類のコードで学習させる必要があります。
AI専用なので人間が書くのは面倒です。もし人間が書きやすい形式から1 : 1で変換できるようであれば、最初から人間が書きやすい言語として定義すればいいですね。トークン割り当ての問題になるのでAIの内部表現は変わらない。
で、人間が書けないのであれば、おそらく既存言語からがんばって変換を行って学習させる必要があります。また、人工的にいろいろな処理を生成するということも考えられます。
けど、そんなことするなら、野生のプログラムからたくさん学習できる既存言語でよくない？ってなりますね。
追記(20025/10/06)
新しい概念を作る説：
まず、現状のAIには新しい概念を作れません。既存パターンの組み合わせができるだけです。
また、プログラミング言語に取り込み可能な論理概念は型理論にしろ時相論理にしろ発展的なものがすでに存在しますが、実用には過剰でわざわざ取り込むとは思えません。それを越えた論理は現状のAIには作れません。
現状のAIをこえてそういうことが可能なAIが現れればもちろん作れますが、技術的な裏付けがないのであれば単にトートロジーであまり意味がないです。
低レベルまでAIで作る説：
低レベルの最適化は個別のハードウェアへの依存が高く、それらの特性をすべて学習させて最適化させるのは難しいです。ふつうにコンパイラに任せた方が安いし速いし確実。
ロジカルにできることはAIにやらせないほうが安いし速いし確実です。
