プログラミング言語は、人間が機械に指示を与えるために設計された。
その構文には、その歴史が刻まれている。私たちは読みやすい変数名、覚えやすいキーワード、インデント、コメント、ファイル、クラス、そして人間の心的モデルに合う抽象を使う。コンパイラのエラーは人に向けて書かれている。ドキュメントは人のために編まれている。ソースリポジトリは、人がたどれるように構成されている。
だが人間は、実際のコードを書く役目から急速に退きつつある。
私が製品を作り、AI 支援の開発を試しているソフトウェアスタジオ Senternet では、いまや自分のソフトウェアの多くを、コーディングエージェントに指示することで作っている。欲しいものを述べ、結果を確認し、挙動を試し、まずいところは直させるためにエージェントへ差し戻す。エージェントはいまも TypeScript、Python、SQL といった従来のソースコードを出力するが、それはますます、この仕事に必要だからではなく、既存の生態系の名残であるように感じられてくる。
エージェントが人間に読めるコードを書いているのは、主として、私たちのコンパイラ、ライブラリ、OS、API、パッケージマネージャ、デプロイ基盤がそれを期待しているからだ。
そこから、頭を離れない問いが浮かぶ。
人間ではなくエージェントのために設計された最初のプログラミング言語は、どんなものになるのか。
人間に読めるコードは中間形式になりつつある
コンピューティングの歴史のほとんどにおいて、ソースコードには二つの読み手がいた。
一つは、それをコンパイルないし解釈する計算機。もう一つは、のちにそれを理解し、デバッグし、保守し、拡張する必要が生じるかもしれないすべての人間である。
この二つ目の読み手が、言語設計の主要な判断のほとんどを形づくってきた。
Python は読みやすさを重んじる。Ruby は自然で表現力豊かであろうとする。TypeScript は、大人数が JavaScript について考えを整理できるように構造を加える。Rust は所有権とメモリ安全性を明示し、他の言語なら隠してしまう挙動を開発者が理解し制御できるようにする。
これらが価値ある特徴なのは、稀少な資源が伝統的に人間の注意だったからだ。
エージェント的なコーディングは、その経済を変える。
エージェントは打ちやすい構文を必要としない。覚えやすいキーワードも要らない。一学期で教えられる言語も、本棚一つで説明できる言語も要らない。巨大なリポジトリを渡り歩いても疲れない。人にとっては退屈で、冗長で、理解しがたい表現でも処理できる。
エージェントが恩恵を受けるのは、まったく別の性質かもしれない。
- 曖昧さのない意味論
- コンパクトなトークン表現
- 明示された依存関係と副作用
- 決定的な変換
- 形式検証
- 自動並列化
- 機械可読な診断
- 組み込みの来歴
- インクリメンタルなコンパイル
- ハードウェアに特化した最適化
- 制約とテストの直接的な表現
エージェントがソフトウェアの主たる書き手になれば、人間にとっての読みやすさは設計上の中心的制約ではなくなる。
無価値になるのではない。生成されるインターフェースになるのだ。
機械にとって自然な表現が真実の源となり、人間はその時々でいちばん役に立つ形の眺めを受け取る。説明でも、図でも、振る舞いの仕様でも、セキュリティ報告でも、テスト計画でも、あるいは生成された TypeScript でもいい。
人間に読めるコードは、いずれデータベーススキーマのグラフィカルな表示以上に根源的なものではなくなるかもしれない。
なぜエージェントはいまも Python と TypeScript を書くのか
新しい言語にとって最大の障害は、その構文ではない。
生態系である。
新しい言語には、コンパイラ、デバッガ、ライブラリ、ドキュメント、パッケージ管理、エディタ対応、デプロイの道具立て、セキュリティ解析、そして既存プラットフォームへの接続が要る。開発者は、いま持っているものをすべて作り直させる言語を採用したがらない。
エージェントはこの問題を消しはしないが、劇的に小さくするかもしれない。
歴史的に、新しい言語は何百万もの人にそれを学ぶよう説得しなければならなかった。開発者には訓練、実例、書籍、コミュニティの支え、そして未知の技術に自分のキャリアと会社を賭けるだけの確信が要った。
エージェントに数か月の訓練は要らない。あるモデルなりコーディングシステムなりが、ある言語を確実に生成できるようになれば、そのシステムの利用者は全員、ただちにその言語を手にする。
これは、言語の普及を阻んできた歴史的な最大級の壁の一つを取り除く。
生態系の問題は残る。つまり最初に成功するエージェント・ネイティブ言語は、おそらく Python、JavaScript、Rust、C++ を一挙に置き換えたりはしない。それらを吸収するのだ。
LLVM を通じてコンパイルし、WebAssembly を標的にし、既存の C インターフェースを呼び、いまのパッケージを取り込み、確立された API と話すかもしれない。開発者が意識して選ぶ言語としてではなく、コーディングエージェントの下に隠れた中間表現として始まるかもしれない。
その移行は、ほとんどの人が気づかないうちに起こりうる。
その一部はすでに起きている
主にエージェントによって書かれ、消費される、広く採用された汎用プログラミング言語は、まだ存在しない。だが、その方向へ動く初期のプロジェクトはいくつもある。
研究者たちは 2025 年、大規模言語モデルのエージェントが行うコードアクションのための言語として Quasar を発表した。エージェントはツールを呼んだり制御フローを組んだりする際、たいてい Python を生成する。しかし研究者たちは、この仕事に必要な性能・安全性・信頼性の特徴を Python は欠いていると論じた。
Quasar は自動並列化、不確実性の追跡、そして危険になりうる操作を検証する仕組みを加える。現在の実装では、モデルは制限された Python の部分集合を書き、それが Quasar へトランスパイルされる。研究者は、並列化が可能な場合に実行時間が 42 パーセント短縮され、そのセキュリティ機構が働く場合に必要な承認のやり取りが 52 パーセント減ったと報告している。
Quasar はエージェント・ネイティブ言語の最終形ではない。エージェントはいまも Python 風のコードを吐く。だが圧力のありかははっきり示している。人のために設計された言語が、エージェントにとって最良の実行モデルとは限らないのだ。
Pel は、AI エージェントのオーケストレーションのために作られたもう一つの実験的な言語である。最小限の文法を用い、制約付き生成、能力の制御、エージェント間通信、安全な実行、自動並列化に重きを置く。
Pel は Lisp、Elixir、Gleam、Haskell といった言語の影響を受けているが、その設計は、モデルが確実に生成しやすいということ自体が言語の機能である、という前提に立つ。
これは優先順位の意味ある転換だ。従来の言語設計者は、その構文が人に分かりやすいかを問う。エージェント・ネイティブ言語の設計者はおそらく、モデルがそれを一貫して生成でき、機械的に検証でき、人手を介さず誤りから立ち直れるかを問うだろう。
コーディングエージェントはまた、なじみのない言語を人間のように学ぶ必要がないことを示しはじめている。
エソテリックなプログラミング言語を扱うコーディングエージェントに関する 2026 年の研究 では、先端のエージェントはしばしば、見慣れない対象コードを生成しデバッグするための Python プログラムを書いた。研究者がこのメタプログラミング戦略を禁じると、性能は大きく落ちた。
それは、私が描いている未来の原始的だが重要な一形態である。
エージェントは目標となる表現を推し量り、そのための生成器を作り、結果を試し、生成器を直せる。人間的な意味で対象コードを理解したり保守したりする必要はない。対象言語は、操作できるもう一つの機械表現にすぎないのだ。
最初のエージェント・ネイティブ言語は、言語に見えないかもしれない
新しいプログラミング言語を思い描くとき、人はたいてい新しい構文を思い描く。
それはおそらく、いちばん重要でない部分だ。
エージェント・ネイティブ言語は、次のものの構造化された表現でありうる。
- 望ましい振る舞い
- インターフェース
- 制約
- 権限
- 不変条件
- テスト
- 資源の上限
- 性能目標
- セキュリティ方針
- 許容できる失敗の様式
それらの要件をどう実装すべきかは、コーディングエージェントとコンパイラが共同で決めればよい。
あるワークロードでは結果がネイティブの機械語になるかもしれない。別のものでは WebAssembly かもしれない。さらに別のものでは、データベースのクエリプラン、GPU カーネル、サーバーレス関数、あるいは既存サービスの組み合わせかもしれない。
実装に対応する恒久的なソースファイルは、存在しないかもしれない。
残る成果物は、意図と、その意図を実装が満たしているという証拠になるだろう。
ここには三段階の進み方が見える。
第一段階: エージェントが人間のプログラミング言語を書く
いま私たちがいるのがここだ。エージェントは、人間の開発者が書いたかもしれないような見た目のコードを産み出す。
第二段階: エージェントが機械向けの中間表現を書く
人間が主に見るのは、振る舞い、テスト、仕様、生成された説明、そして能力の変化である。日常的なレビューにおいて、下層の実装は重要でなくなっていく。
第三段階: エージェントが実行可能なシステムを直接生成する
真実の源は、意図、方針、インターフェース、制約、検証の証拠の集まりになる。エージェントは必要に応じて、実行可能な実装を生成し、また生成し直す。
その段階に至れば、あるアプリケーションが「何の言語で書かれているか」と問うことは、あまり意味をなさなくなるかもしれない。
人間に読めることは、人間に監査できることではない
この未来に対する最も強い反論は、ソースコードはソフトウェアを書くためだけに使われるのではない、というものだ。
それはデバッグ、監査、統治、セキュリティレビュー、保守、そして説明責任にも使われる。
誰も振る舞いを検分できない重要なシステムを、安全に運用することはできない。
だが読めるソースコードは、実際の理解の代用としてすでに心もとない。大規模な現代のアプリケーションは、自前のコードだけで数百万行に達し、パッケージ、生成ファイル、クラウドサービス、OS、ファームウェアを通じてさらに数百万行に依存している。システム全体を理解している者は、ほとんどいない。
コードが読めても、システムが分かるとは限らない。
エージェント・ネイティブなシステムは、ソースファイルの山より強力な検分の手段を用意する必要がある。たとえばこうしたものを生成できるだろう。
- 特定の振る舞いについての説明
- データの流れの地図
- 重要な性質の証明
- 権限と能力の報告
- 依存関係の履歴
- 変更案のシミュレーション
- 実行可能なテスト
- なぜその判断をしたのかの記録
- 必要なときには人間に読める実装
目標は、何が何でも読めるコードを守ることではないはずだ。
目標は、人間の制御を守ることであるはずだ。
この二つは同じではない。
人に優しいコードの環境的コスト
エージェントがいずれ今日のプログラミング言語を越えていくかもしれない、もう一つの理由がある。エネルギーだ。
広く引用される 27 のプログラミング言語のエネルギー効率に関する 2017 年の研究 は、十のベンチマーク問題について実行時間、メモリ使用量、消費電力を比較した。
その正規化された結果では、Python は C のおよそ 76 倍のエネルギーを消費し、実行時間はおよそ 72 倍を要した。エネルギー効率において、Python は試験された言語のなかで下位に位置した。
この結果はしばしば、Python は環境にとって最悪のプログラミング言語の一つだ、という主張へと単純化されてきた。
実際はもっと込み入っている。
プログラミング言語のエネルギー効率に関する 2024 年の再分析 は、こうした比較が、言語そのものと、その実装、ベンチマークプログラムの質、稼働しているコア数、ライブラリの挙動、メモリ活動、その他の実行上の細部とを混同しうることを見いだした。
それらの要因を統制したのち、研究者たちは、プログラミング言語の実装は実行時間を超えてエネルギー消費に有意な影響を与えていない、と結論づけた。
中心的な問題は、ある言語の構文がなぜか多くの電力を食う、ということではなかった。遅いプログラムは概して総エネルギーを多く使う。ハードウェアが長く動き続けるからだ。
この区別は問題を消し去りはしない。
計算量の多い仕事では、標準の Python は最適化されたコンパイル済みコードよりずっと遅いことが多い。同じ仕事に桁違いに長くかかるプログラムは、実行中のプロセッサの消費電力が同程度でも、桁違いに多くのエネルギーを使いうる。
よい知らせは、その非効率が避けがたいものではないということだ。
コンパイルされた Python 実装に関する 2025 年の研究 は、CPython を PyPy、Numba、Codon、Cython、Nuitka、Mypyc、Pyston-lite といった複数のコンパイル・最適化系と比較した。
研究者たちは、コンパイルが実行時間、メモリ使用量、消費電力を大きく改善しうることを見いだした。試験された一部のワークロードでは、Codon、PyPy、Numba が 90 パーセントを超える速度とエネルギーの改善をもたらした。
より正確な結論は、Python が本質的に環境破壊的だ、ということではない。
人間はしばしば、人間の生産性を基準にプログラミング言語を選び、実行効率を二の次に扱ってきた、ということだ。
Python が成功しているのは、読みやすく、表現力があり、寛容で、巨大な生態系に支えられているからだ。多くの組織では、開発者の時間を節約することが、追加の計算時間を費やすに値する。
エージェントは同じ二律背反に直面しない。
コーディングエージェントは、生産的であり続けるために親切な構文を必要としない。教えやすく、打ちやすく、覚えやすい言語も要らない。特定のワークロードのために選んだ表現を生成し、手元のハードウェア向けにコンパイルし、結果を測り、より効率のよい実装が現れたら差し替えればいい。
エネルギー消費は、ソフトウェアを書き終えてから試みる最適化ではなく、プログラミングの第一級の性質になりうる。
これが重要なのは、エージェントが人の書いたコードを一行ずつ置き換えていくだけではないからだ。おそらく、生産され実行されるソフトウェアの総量そのものを押し上げる。
エージェントは何十もの実装を生成し、何千ものテストを走らせ、個別の作業のために使い捨てのプログラムを作り、動いているシステムを絶えず作り直せる。人間がゆっくり作っていた時代には許容できた非効率も、機械がほぼ無制限にコードを生成できるようになれば、重みを増す。
だから最初のエージェント・ネイティブ言語は、正しさと速さだけを最適化するのではないかもしれない。次のようなことも考慮しうる。
- 総エネルギー消費
- 想定される実行頻度
- 利用できるプロセッサとアクセラレータ
- メモリの移動
- コンパイルのコスト
- 利用できる電力の炭素強度
- そのワークロードを遅らせたり移したりできるか
- その実装が一度だけ動くのか、何十億回も動くのか
普遍的に最適な表現など存在しないかもしれない。
一度きりのデータ変換なら、コンパイルの手間が最小であることが好ましいだろう。何十億ものリクエストを捌く前提のサービスなら、攻めたネイティブ最適化に見合うだろう。バッテリー駆動の端末で動く仕事なら、遅延よりエネルギーを優先するかもしれない。データセンターで走るジョブなら、より低炭素な電力が使える時間帯に合わせて組めるだろう。
こうした判断を、エージェントは自動で下せる。
おそらく環境上の過ちは、エージェントに読めないコードを書かせることではない。人間が読むのを好むというだけの理由で、Python を書き続けさせることのほうだ。
プログラマはどうなるのか
以上のどれも、人間がソフトウェアを作らなくなることを意味しない。
私たちの仕事が上へ移る、ということだ。
コンパイラのために設計された構文で実装手順を記述することに大半の時間を費やす代わりに、こういったことを定めるのにより多くの時間を使うようになる。
- そのシステムが何を成し遂げるべきか
- 何を決してしてはならないか
- どのトレードオフなら受け入れられるか
- 誰が何にアクセスできるか
- 成功をどう測るか
- 失敗をどう扱うべきか
- 本番投入の前にどんな証拠が要るか
それもまたプログラミングである。
多くの意味でそれは、こうした判断をループやクラスや関数や設定ファイルへ手で翻訳するよりも、直接的なプログラミングだ。
プログラマの役割は、ソースコードを産み出すことより、意図と制約と設計と判断を打ち立てることに寄っていく。作ること自体が安くなったとき センスこそがボトルネックになる、という考えに私が何度も立ち返るのは、それも理由の一つだ。
ソフトウェア開発の難所は、構文を打ち込むことでは一度もなかった。難所は、何が起こるべきかを決めることだった。
エージェントは、その翻訳の層を取り除きつつある。
それは誰が作るのか
最初の真にエージェント・ネイティブな言語は、開発者向けカンファレンスで発表されはしないかもしれない。
気の利いた名前も、公開された仕様も、構文を論じるコミュニティも持たないかもしれない。
それは、ソフトウェアを計画し、生成し、検証し、最適化し、コンパイルするために使われる私的な中間表現として、あるエージェント基盤の内側に静かに現れるかもしれない。はじめは従来の言語と既存のツールチェーンを標的にし、そこから少しずつ、それらを迂回していくのかもしれない。
人間がそれをプログラミング言語だと認識するころには、エージェントはすでにそれを使って、世界のソフトウェアのかなりの部分を書いているかもしれない。
勝つのは、人間が読んでいちばん楽しい言語とは限らない。
最も信頼でき、安全で、効率がよく、検証可能なシステムをエージェントが産み出せて、なおかつ人間が結果に対する実質的な制御を保てる。そういう表現である。
プログラミング言語は、人間が計算機に何をすべきか伝えられるように発明された。
次のそれは、計算機が自分自身に伝えられるように発明されるのかもしれない。
Top comments (0)