最終更新日：
大規模言語モデル（large language model; LLM）を用いた AI エージェントは、コードの生成、実行、検査、修正を反復することでソフトウェア開発を支援する。Endoh が2026年3月5日の記事で報告した Claude Code による簡易 Git 実装ベンチマークでは、外部ライブラリ依存を避けた小規模課題に限って、Ruby、Python、JavaScriptなどの動的で簡潔な言語が高速かつ低コストに見える結果が報告されている（Endoh 2026a）。しかし、この結果は、AI エージェントに適した言語が単に動的型付けで短い言語であることを意味しない。大規模な変更、外部入出力、永続化、安全性境界を含む開発では、型、契約、テスト、診断、モジュール境界による検証可能性が重要な設計候補となる。
本レポートは、AI エージェントにとって高速生成可能なプログラミング言語 Veln1 の設計原理を、「作業面積」の最小化として定式化する。ここで作業面積とは、エージェントが生成すべき表層構文の量、読解すべき文脈の量、失敗後に修正すべき差分の大きさ、検査結果から次の行動を決めるための推論負荷の総体である。Veln は、短く一貫した表層構文、標準化されたツールチェーン、公開境界における局所的な静的検査、契約、実行可能な例、typed holes2、構造化診断を統合する。
本レポートの主張は、AI 向け言語の本質が「最初に短く書けること」だけでなく、「失敗から修正までの距離が短いこと」にある、という点にある。すなわち、生成トークン数、実行時間、検査精度、診断の機械可読性、影響範囲の局所化、人間によるレビュー容易性を同時に設計対象とする必要がある。この観点から、AI エージェントに適した言語は、人間が読める高い意味密度と、エージェントが扱える局所的・構造的なフィードバックを両立する言語でなければならない。
近年、大規模言語モデル（Large Language Model; LLM）を用いたコード生成は、単発の補完機能から、ファイル探索、編集、テスト実行、失敗原因の推定、再修正までを含む AI コーディングエージェントへと発展している。本レポートでは、AI コーディングエージェントを、自然言語または既存コード上の要求を入力として受け取り、プログラムの生成・修正・検証を反復的に実行するソフトウェア主体と定義する。このようなエージェントにとって、プログラミング言語は単なる実行対象ではなく、生成すべきテキストであり、読むべき状態空間であり、失敗時に診断を返す対話相手でもある。
既存のプログラミング言語は、主として人間が記述し、人間が読解し、コンパイラまたはインタプリタが実行可能な形へ変換することを中心に設計されてきた。もちろん、型検査器、静的解析器、言語サーバ、テストランナーなどの開発支援系は従来から存在する。しかし、それらの多くは、人間開発者が診断を読み、設計判断を行い、コードを修正することを前提としている。AI エージェントが開発主体の一部となる場合には、言語設計の評価軸に、エージェントが短い試行錯誤ループで安全にコードを生成・修正できるかという観点を加える必要がある。
この問題意識は、言語ごとのコード生成効率に関する近年の観察とも接続する。Endoh が2026年3月5日の記事で報告した Claude Code を用いた簡易 Git 実装ベンチマークでは、Ruby、Python、JavaScript のような動的で簡潔な言語が、生成時間、費用、安定性の面で有利であったと報告されている（Endoh 2026a; Wiggers 2026）。実験コードと結果は GitHub repository として公開されており、v2 の仕様範囲は SPEC-v2.txt で確認できる（Endoh 2026c; Endoh 2026d）。ただし、この実験は外部ライブラリ依存を避けた小規模な mini-git 課題であり、著者自身も原因を単一要因には還元していない。観測された差には、記述量の少なさ、プロジェクト設定の少なさ、慣用句の安定性、AI の学習データ上の馴染み、型検査や所有権規則に伴う追加作業などが複合的に関与した可能性がある（Endoh 2026a）。したがって、この種の結果を、動的型付け言語が常に AI に適しているという一般命題へ直ちに拡張することはできない。小規模タスクで有効な短さは、大規模コードベースにおいては、暗黙の依存、実行時まで発見されない不整合、影響範囲の不明瞭さとして現れる可能性がある。
したがって、本レポートが扱う中心問題は、「AI が高速に生成できる言語」とは、単に少ないトークンで書ける言語なのか、それとも生成、読解、実行、失敗、診断、修正の一連の循環を短くする言語なのか、という点にある。本レポートでは後者の立場を採る。すなわち、AI エージェントに適した高速生成可能プログラミング言語とは、表層構文の短さだけでなく、標準化されたツールチェーン、局所的な静的検査、契約、実行可能な例、構造化診断、typed holes を統合し、失敗から修正までの距離を縮める言語である。ここで契約とは、関数やモジュールが満たすべき事前条件、事後条件、不変条件をコード近傍に明示する仕組みを指す。また、構造化診断とは、人間向けのエラーメッセージに加えて、機械が処理しやすい形式で位置、期待型、実際の値、修正候補などを返す診断を指す。
ここで typed holes とは、未完成の式や定義を明示的な穴としてプログラム内に保持し、その穴に期待される型、利用可能な変数、候補となる補完などを機械的に取得できる仕組みを指す。Omar らの typed holes および部分プログラムに関する研究は、未完成プログラムを単なる構文エラーではなく、型付きの中間状態として扱う方向を示している（Omar et al. 2017; Omar et al. 2019）。本レポートでは、この基盤を契約、依存グラフ、回帰テスト選択と結び付け、関連しうるテスト候補を返す設計へ拡張する。AI エージェントの作業過程において、未完成状態を情報を持つ状態として保存できることは、初回生成に過度の完全性を要求せず、段階的な検証と補完を可能にする点で重要である。
本レポートで設計する Veln は、AI エージェントにとっての作業面積を最小化するプログラミング言語である。作業面積とは、エージェントがある変更を達成するために読み、生成し、実行し、解釈し、修正しなければならないコード、設定、診断、テスト、依存関係の総量を指す。作業面積を小さくするためには、Ruby や Python 的な簡潔性だけでなく、D 言語に見られるような契約および組み込みテスト、Elixir の ExUnit.DocTest に見られるような実行可能な文書例、さらに構造化されたコンパイラ診断を、言語設計として統合する必要がある。doctest とは、ドキュメント中の実行例をテストとして実行し、説明と挙動のずれを検出する方式である。これは、人間に読めない AI 専用中間表現を提案するものではない。むしろ、人間と AI が同じソースコードを読み、同じ仕様断片、同じ診断、同じテスト結果を共有できることを設計上の制約とする。
本レポートの研究課題は以下の四点である。
第一に、AI エージェントが高速にコード生成できる言語には、どのような記法的・意味論的特徴が必要かを検討する。ここでは、コードの自然性、意味密度、構文上の一貫性、局所的な予測可能性を扱う。
第二に、動的言語の短さと静的言語の検証性をどのように両立できるかを検討する。特に、全域的に強い型付けを要求するのではなく、公開 API、外部 I/O、永続化、危険操作などの境界で型、契約、副作用情報を強める設計を考える。
第三に、エージェントの修正ループを短縮するために、コンパイラ、テストランナー、言語サーバがどのような情報を返すべきかを検討する。自然文のエラーメッセージだけではなく、抽象構文木上の位置、期待型、関連テスト、修正候補、影響範囲を含む構造化診断を対象とする。
第四に、このような言語の有効性をどのようなベンチマークと評価指標で測定できるかを検討する。単純なテスト通過率だけではなく、テスト成功までの時間である Time-to-green、成功までの API 利用費やトークン費用である Cost-to-green、修正反復回数、生成トークン数、修正トークン数、差分サイズ、診断の有用性、人間のレビュー時間を評価軸に含める。
本レポートの構成は次の通りである。第2章では、コードの自然性、簡潔性、認知的次元、静的型付け、typed holes、モジュール化、契約および doctest に関する先行研究を整理する。第3章と第4章では、提案言語の設計目標と非目標を明確化する。第5章から第11章では、中核言語、表層構文、型・契約・副作用、typed holes、ツールチェーン、モジュール文書モデル、エージェント相互作用モデルを設計する。第12章では評価方法を提案する。ケーススタディは現時点では未実施であるため、本稿の対象外とする。第14章から第16章では、設計上のトレードオフ、妥当性への脅威、今後の研究課題を論じる。第17章では、本レポートの主張を総括する。
本章では、AI エージェントに適したプログラミング言語を設計するための理論的背景を整理する。対象となる先行研究は、コードの自然性、言語の簡潔性、記法の認知的性質、静的型付けと保守性、typed holes、言語サーバ、モジュール化、契約、組み込みテスト、および doctest に関する研究である。これらは従来、人間開発者の生産性や保守性を説明するために用いられてきた。本レポートでは、それらを AI コーディングエージェントの生成・読解・修正負荷を説明する枠組みとして再解釈する。
Hindle らは、ソースコードが自然言語と同様に反復性と局所的な予測可能性を持つことを示し、この性質を “naturalness of software” と呼んだ（Hindle et al. 2012）。ここで自然性とは、ある文脈において次に現れやすい記号列や構造が統計的に偏っている性質を指す。ソースコードは形式言語でありながら、実際のプロジェクトでは命名規則、制御構造、ライブラリ呼び出し、エラー処理の慣用句が反復される。この反復性は、補完、バグ検出、コード検索、機械学習によるコード理解に利用できる。
Allamanis らは、Big Code 研究を、巨大なコード集合から統計的規則性を学習し、プログラム理解や生成に利用する研究領域として整理している（Allamanis et al. 2018）。大規模言語モデルがコードを生成できる背景にも、この統計的規則性がある。したがって、AI エージェントが生成しやすい言語とは、単に利用者数が多い言語ではなく、頻出パターンが安定し、標準的な書き方の分散が小さく、局所文脈から次の構造を予測しやすい言語である。
もっとも、モデルがある言語を生成しやすいかどうかは、言語仕様だけでなく、学習コーパスの量、品質、ライセンス上の収集可能性、教材的データの比率にも依存しうる。StarCoder 2 は The Stack v2 などの大規模コードデータを用いるコードモデルとして報告されており、SmolLM2 では Stack-Edu のような教育的データセットも訓練データ設計の一部として位置づけられている（Lozhkov et al. 2024; Ben Allal et al. 2025; Hugging Face TB n.d.）。このことは、Endoh の実験で言及される AI familiarity を、言語の内在的性質とは別の交絡要因として扱う必要があることを示す。
この観点からは、言語設計において自由度を増やすことが常に望ましいとは限らない。同じ処理を多数の等価な構文で書ける言語は、人間熟練者には表現力を与える一方、学習データ上の分布を拡散させ、AI エージェントにとっては生成候補の探索空間を広げる可能性がある。ただし、この関係は Hindle らや Allamanis らの文献から直接導かれる実証済み命題ではなく、本レポートでは設計仮説として扱う。したがって、本レポートでは、構文上の一貫性と標準スタイルを、AI 向け言語設計の中心的性質として扱い、その有効性を第12章の評価対象に含める。
Nanz と Furia は、Rosetta Code に含まれる多言語実装を用いて、言語ごとのコード量や実行特性を比較した（Nanz and Furia 2015）。その結果、スクリプト言語や関数型言語は、手続き型言語やオブジェクト指向言語より短い実装になりやすい傾向が報告されている。この結果は、AI コード生成においても重要である。生成すべきテキストが短いほど、初回生成の時間と費用は小さくなり、修正対象の差分も小さくなる可能性がある。
ただし、簡潔性は単なる文字数や行数の少なさではない。過度に圧縮されたコードは、暗黙の規則や記号の知識を要求し、失敗時の修正可能性を下げる。AI エージェント向けの簡潔性は、Perl 的な高密度な省略ではなく、Ruby や Python に見られるような、意味の単位が短く、かつ読解可能な形で表現される簡潔性でなければならない。
本レポートでは、簡潔性を三つに分ける。第一は token density、すなわち少ないトークンで処理を表現できる性質である。第二は semantic density、すなわち少ない構文で仕様意図を明示できる性質である。第三は repair density、すなわち修正時に小さい範囲の差分で意図した変更を完了できる性質である。AI エージェントにとって重要なのは、初回生成時の token density だけではなく、失敗後の repair density である。
Green と Petre は、記法の使いやすさを分析する枠組みとして Cognitive Dimensions of Notations を提案した（Green and Petre 1996）。この枠組みは、プログラミング言語、視覚的記法、開発環境などを、変更のしにくさ、隠れた依存、情報の見えやすさ、一貫性、エラーの誘発しやすさといった次元から評価するものである。
本レポートでは、この枠組みを AI エージェントの作業負荷に拡張する。たとえば viscosity は、人間にとっての変更のしにくさだけでなく、エージェントが仕様変更に対してどれだけ多くのファイルや構文要素を修正しなければならないかを表す。hidden dependencies は、暗黙のグローバル状態、動的なメソッド生成、実行時に決まる依存関係などとして現れ、エージェントの探索範囲を広げる。visibility は、型、契約、副作用、依存関係、関連テストがコード近傍に見えているかを問う。
この拡張により、AI 向け言語設計は、モデルの性能だけでなく記法そのものの性質として議論できる。エージェントが誤る理由を、単にモデルが不十分であるからと説明するのではなく、記法が不必要に曖昧である、診断が機械可読でない、依存が隠れている、といった設計上の問題として扱える。
静的型付けは、プログラムを実行する前に型の整合性を検査する仕組みである。Hanenberg らの実験は、静的型付けが未文書コードの理解や型エラー修正に有益な場合がある一方、意味的なエラー修正に対して万能ではないことを示している（Hanenberg et al. 2014）。この結果は、AI エージェント向け言語設計において、静的型を全面的な解決策として扱うべきではないことを示唆する。
段階的型付けは、静的型付け部分と動的型付け部分を同一プログラム内で共存させ、プログラマが型注釈の程度を制御しながら静的検査の範囲を広げられる型システムとして定義される（Siek and Taha 2006）。Siek and Taha は、この能力を gradual typing と呼び、完全に注釈された項について単純型付きラムダ計算との整合性を保つ形式的基盤を与えている。本レポートの提案は、この formal gradual typing をそのまま採用するものではない。主に扱うのは、公開 API、外部入出力、永続化、安全性境界では型・スキーマ・契約を強め、内部の短い変換では型推論と軽量な記述を優先するという、段階的な検査配置である。
AI エージェントにとって、強い静的型付けは二面的である。一方では、型エラーが早期に発見され、修正候補が局所化されるため、大規模コードベースで有利に働く。他方では、初回生成時に多数の型注釈、所有権規則、ジェネリクス、ライフタイムなどを同時に満たす必要がある場合、生成の摩擦は増大する。したがって、本レポートでは、常時強い型ではなく、必要な場所で強い型を採用する。
具体的には、公開 API、外部入出力、永続化、ネットワーク、安全性境界では型とスキーマを明示し、内部の短いデータ変換では型推論を優先する。これにより、初期生成の軽さと保守時の検証性を両立させる。重要なのは、型注釈の有無ではなく、エージェントが必要な時点で推論済みの型、期待型、境界条件を取得できることである。
Omar らの Hazelnut は、穴を持つ不完全なプログラムにも双方向型付けの意味論を与える構造的エディタ計算を示した（Omar et al. 2017）。さらに、typed holes を用いたライブ関数型プログラミングの研究では、未完成部分を含むプログラムを、単なる構文エラーではなく、型を持つ途中状態として扱う方向が示されている（Omar et al. 2019）。これは、AI エージェントが段階的にコードを生成する状況と相性がよい。
本レポートでは、AI エージェントは、複雑なプログラムを一度で完全に生成するよりも、仕様を読み、部分実装を置き、診断を受け取り、穴を埋めるという反復に適しているという設計仮説を置く。typed holes は、この反復を言語機能として支える。既存研究が直接支えるのは、穴に期待型、スコープ内の変数、利用可能な関数、周辺文脈を結び付ける考え方である。さらに本レポートでは、これを契約、依存グラフ、回帰テスト選択と統合し、穴に関係するテストや検査範囲を返す設計へ拡張する。
Solar-Lezama の program sketching は、人間が高水準の構造を与え、詳細を合成器が補完する考え方を示している（Solar-Lezama 2013）。本レポートの提案は、完全自動合成ではなく、LLM を用いるエージェントが typed holes と構造化診断を利用して段階的に補完する設計である。その意味で、typed holes は合成器のためだけでなく、エージェントの作業単位として位置づけられる。
typed holes を LLM 補完へ直接接続する研究として、Blinn らは Hazel の typed holes、言語サーバ、LLM によるコード補完を統合する手法を示している（Blinn et al. 2024）。この研究の重要点は、穴の期待型と束縛文脈を言語サーバから取得し、その静的文脈を LLM の入力へ組み込むことで、カーソル近傍や同一ファイルに現れない定義を補完時に利用できるようにする点にある。さらに、Hazel Language Server が未完成・誤りを含むプログラムでも意味のある program sketch を保ち、補完結果を言語サーバとの対話で反復的に修正する構成が示されている。Blinn らは、この方向を Language Server Protocol の保守的拡張である ChatLSP として整理している。
この研究は、本レポートの typed hole completion と agent-facing compiler の直接の先行研究である。したがって、本レポートの独自性は、typed holes から型・束縛文脈を得て LLM 補完へ渡すという点そのものには置かない。本レポートが追加して扱うのは、typed holes を契約、関連テスト、回帰テスト選択、doc drift、safe repair、package metadata と結び付け、言語設計原理として統合する点である。すなわち、穴を埋める候補だけでなく、その候補を適用した後にどの契約を確認し、どのテストを優先し、どの文書更新が必要になるかを、処理系が機械可読に返す設計である。
また、Zhang and Lanser Contributors は、コンパイラ、型検査器、Language Server Protocol が返す診断、シンボル解決、型情報、参照、リファクタリング前提条件を、エージェントや学習ループで利用する方向を提案している（Zhang and Lanser Contributors 2025）。この文献は2026年5月時点ではプレプリントであるため、本レポートでは査読済みの根拠ではなく、近接する研究動向として限定的に扱う。それでも、言語サーバが人間向け IDE だけでなく、エージェントの観測・報酬・検証基盤になりうるという問題意識は、本レポートの評価計画と相互作用設計に直接関係する。
Parnas は、モジュール分割を単なる手続きの分割ではなく、変更されうる設計判断を隠蔽する単位として論じた（Parnas 1972）。この考え方は、AI エージェント向け言語設計において特に重要である。エージェントが変更を行う際、関連しない内部実装まで読み込まなければならないなら、文脈量と誤修正の危険が増大する。モジュール境界が安定していれば、公開 API、契約、副作用、依存先、テスト責務を手がかりに、探索範囲を限定できる。
したがって、モジュールは名前空間やファイル分割の単位にとどまらない。AI エージェントにとってのモジュールは、読まなくてよいものを明確にするための装置である。公開 API と不変条件が明示され、内部の設計判断が隠蔽され、変更理由や移行方針が短く記録されていれば、エージェントは必要な文脈を過不足なく取得しやすくなる。
D 言語は、契約プログラミングと組み込みの単体テストを言語仕様・公式文書に近い位置で提供している。D の Contract Programming 仕様は、事前条件、事後条件、不変条件を含む契約を言語に組み込む意義として、一貫した記法、ツール支援、契約情報を利用した実装上の最適化などを挙げている（D Language Foundation n.d.-a）。契約プログラミングとは、関数や型が満たすべき事前条件、事後条件、不変条件をコード中に記述する手法である。また、D の Unit Tests 仕様は、unittest をモジュールに適用される組み込みテスト枠組みとして定義し、documented unittest により単体テストを文書中のコード例として生成する仕組みも提供している（D Language Foundation n.d.-b）。本レポートでは、この既存機能をそのまま輸入するのではなく、契約を実行時検査、文書化、テスト生成、静的解析、エージェント向け診断に再利用する設計へ拡張する。
Elixir の ExUnit.DocTest は、ドキュメント中の実行例をテストとして実行する仕組みを提供する（Elixir n.d.-a）。また、Elixir の Mix は、プロジェクト作成、コンパイル、テスト、依存関係管理などのタスクを提供するビルドツールである（Elixir n.d.-b）。これらは、説明、例、テスト、プロジェクト操作を近接させる既存事例として参考になる。AI エージェントがコードを修正する場合、ドキュメント、例、テストが離れているほど、更新漏れが生じやすい。doctest は、説明を単なる自然文ではなく検証可能な仕様断片に変える。
これらの既存機能を AI エージェント向けに再解釈すると、重要なのは、コード、仕様、テスト、診断、ドキュメントを近接させることである。統合ツールチェーンが format、test、typecheck、doc、graph、repair を一貫したコマンド体系で提供すれば、エージェントは環境ごとの差異に時間を使わず、生成・検証・修正のループに集中できる。
本章では、AI エージェントに適した高速生成可能プログラミング言語の設計目標を定義する。ここでの高速性は、初回生成に要する時間だけでなく、実行、失敗、診断、修正、再検証を含む総合的な時間と費用を指す。したがって、設計目標は、表層構文の短さ、検証可能性、ツールチェーン、モジュール境界、人間と AI の共通可読性を同時に扱う必要がある。
第一の目標は、高い意味密度である。意味密度とは、少ない構文要素で仕様意図を明確に表現できる性質を指す。人間にとっては、読み書きするコード量が減り、処理の意図を把握しやすくなる。AI エージェントにとっては、生成トークン数と修正差分が減り、試行錯誤の費用が下がる。ただし、意味密度は過度な省略とは異なる。省略された前提を人間や AI が推測しなければならない構文は、短くても作業面積を増やす。
第二の目標は、低いセットアップ摩擦である。小さなプログラムは一つのファイルで即実行でき、標準ツールだけで実行、整形、検査、テスト、文書生成が可能でなければならない。人間にとっては、プロジェクト開始時の設定負荷が下がる。AI エージェントにとっては、環境探索やコマンド推定の負荷が下がり、失敗原因を言語仕様上の問題と環境設定上の問題に切り分けやすくなる。
第三の目標は、明白な標準スタイルである。本レポートでは、同じ処理に対する書き方の分散が大きいほど、コードベース内の一貫性が崩れ、モデルが生成すべき形も不安定になる可能性があるという設計仮説を置く。標準 formatter と linter によって書式を正規化し、命名、エラー処理、モジュール宣言、テスト配置に明確な規約を与える必要がある。これは人間のレビュー負荷を下げると同時に、AI エージェントの出力を既存コードへ合わせやすくするかを評価すべき対象である。
第四の目標は、局所的な静的検査である。すべての内部式に明示的な型注釈を要求するのではなく、公開 API、外部入出力、永続化、安全性境界では型、スキーマ、契約、副作用情報を強める。人間にとっては、重要な境界で仕様を確認しやすくなる。AI エージェントにとっては、変更の影響範囲と破壊してはならない条件を機械的に取得できる。
第五の目標は、typed holes の第一級化である。未完成部分を単なる構文エラーにせず、期待型、利用可能な値、候補関数を持つ作業状態として扱う。さらに本レポートの提案では、契約、依存グラフ、回帰テスト選択と統合し、関連しうるテスト候補も提示できるようにする。人間にとっては、設計途中の意図をコード内に残せる。AI エージェントにとっては、完全な初回生成を要求されず、穴ごとに小さな補完問題へ分解できる。
第六の目標は、構造化診断である。エラーは人間向けの説明文だけでなく、機械可読な形式で位置、抽象構文木上の範囲、期待型、実際の型、関連する契約、修正候補、影響テストを返す必要がある。人間にとっては、原因と修正方針を把握しやすくなる。AI エージェントにとっては、自然文エラーの解釈に必要な文脈量が減り、修正行動を選択しやすくなる。
第七の目標は、実行可能仕様である。実行可能仕様とは、自然文の説明だけでなく、doctest、property test、contract、examples などとして機械的に検証できる仕様断片を指す。ここで property test とは、個別の入出力例だけではなく、入力範囲に対して成り立つべき性質を検査するテストである。人間にとっては、仕様と挙動の対応が明確になる。AI エージェントにとっては、コード変更時にどの説明や例を更新すべきかを検出しやすくなる。
第八の目標は、影響範囲の局所化である。言語とツールチェーンは、変更対象ファイル、依存モジュール、影響を受けるテスト、副作用の範囲を機械的に絞り込めなければならない。人間にとっては、レビュー対象が明確になる。AI エージェントにとっては、読むべきファイル数と再実行すべきテスト数を減らし、Time-to-green と Cost-to-green を改善しうる。ただし、選択の保守性、解析コスト、全テストへのフォールバック率を第12章で評価する必要がある。
第九の目標は、大規模化可能性である。小規模スクリプトでは短く書ける一方、規模が大きくなったときにはモジュール、公開 API、契約、テスト、ドキュメント、パッケージ管理へ自然に移行できなければならない。人間にとっては、試作から本番実装へ段階的に進められる。AI エージェントにとっては、初期生成の軽さと保守時の堅牢性を同じ言語内で扱える。
第十の目標は、AI と人間の共通可読性である。本レポートの提案は、人間が読めない AI 専用中間表現を主たるプログラミング対象にするものではない。人間と AI が同じソースコード、同じ契約、同じ例、同じ診断を共有できることが重要である。AI だけに最適化された表現は短期的には生成しやすく見えても、レビュー、監査、保守、教育の面で作業面積を増大させる。
以上の目標は、互いに独立していない。短さを追求しすぎれば暗黙性が増し、検査を強めすぎれば初回生成の摩擦が増える。したがって、本レポートの設計方針は、初期生成では軽く、境界では厳密に、失敗時には詳細に、修正時には局所的に、という均衡を取ることである。
本章では、本レポートの非目標を明確にする。AI エージェントに適した言語設計を論じる際には、過剰な期待が生じやすい。言語設計は開発の偶有的な摩擦を減らすことはできるが、ソフトウェア開発に含まれるすべての困難を消すことはできない。Brooks は、ソフトウェア開発の困難を、問題領域そのものに由来する本質的困難と、ツール、表記、環境、作業手順に由来する偶有的困難に分けて論じた（Brooks 1987）。本レポートは後者を減らす試みであり、前者を消滅させるものではない。
第一に、本研究は実行時性能で C や Rust に勝つことを目的としない。システムプログラミング、リアルタイム制御、メモリ制約の厳しい環境では、低水準の制御と予測可能な実行性能が不可欠である。本レポートが扱うのは、AI エージェントが生成、修正、検証しやすい言語設計であり、最高性能のネイティブコード生成ではない。性能が重要な領域では、提案言語を glue code、テスト、仕様記述、プロトタイピング、周辺ツールに用いることが現実的である。
第二に、すべてのバグを型システムで防ぐことは目的としない。型システムは、値の形やインターフェースの不整合を早期に検出できるが、仕様の誤解、要件の不足、アルゴリズムの誤り、セキュリティ上の設計ミスを自動的に防ぐわけではない。したがって、本レポートでは型、契約、テスト、doctest、構造化診断を相補的な仕組みとして扱う。
第三に、人間の設計判断を不要にすることは目的としない。AI エージェントは、既存コードの変更、定型的な実装、テスト追加、診断に基づく修正を支援できる。しかし、要求の優先順位、ドメイン上の判断、責任境界、セキュリティ方針、長期的な設計方針は、人間が評価しなければならない。提案言語の役割は、人間の判断を置き換えることではなく、その判断が反映されるコード、契約、テスト、文書を AI が扱いやすい形に保つことである。
第四に、自然言語だけで完全なソフトウェアを生成することは目的としない。自然言語は要求や意図を伝えるために有用であるが、曖昧性を含む。実行可能な仕様、型、契約、テスト、例、依存グラフを併用しなければ、エージェントは曖昧な要求を過剰に補完し、意図しない実装を生成する可能性がある。本レポートは、自然言語のプロンプトを強力にする研究ではなく、自然言語からコードへ移る過程で検証可能な足場を与える言語設計を扱う。
第五に、IDE やエージェントに依存して、ソースコードそのものの可読性を犠牲にすることは目的としない。構造化診断、グラフ API、safe repair 候補は有用であるが、これらは可読なソースコードを補助するものでなければならない。人間がツールなしに最低限の構造を読めないコードは、レビュー、監査、障害対応に適さない。
第六に、既存言語を全面的に置き換えることは目的としない。既存の Ruby、Python、JavaScript、TypeScript、Elixir、D、Rust、Go には、それぞれ大きなエコシステムと実運用上の利点がある。本レポートの提案は、それらを否定するものではなく、AI エージェント時代にどのような設計要素が有効かを抽出する試みである。将来的には、新言語として実装するだけでなく、既存言語の拡張、ライブラリ、言語サーバ、テストランナー、メタデータ仕様として部分的に導入する道も考えられる。
以上の非目標を置くことで、本レポートの対象は明確になる。すなわち、本研究は、AI エージェントが実際に行う生成、実行、失敗、診断、修正の循環から偶有的複雑性を減らすための言語設計を論じるものである。
本章では、提案言語の中核設計を述べる。基本方針は、表層構文を短く読みやすく保ちつつ、中核意味論を小さく直交的にすることである。表層構文とは、開発者と AI エージェントが実際に読み書きする記法を指す。中核意味論とは、評価順序、束縛、関数呼び出し、型、契約、副作用、エラー処理など、プログラムの意味を決める規則を指す。
AI エージェントにとって、表層構文の短さは重要である。しかし、表層構文が多数の例外規則を持つ場合、短いコードはかえって修正しにくくなる。したがって、提案言語では、Ruby や Python 的な簡潔性、Elixir 的な pipeline、ML 系言語に見られる pattern matching、D 言語に見られる contract と unittest、段階的な型注釈、typed holes を組み合わせる。ただし、それらを単に寄せ集めるのではなく、エージェントが予測しやすい小さな核へ写像する。
中核となる値は、数値、文字列、真偽値、列、辞書、構造化レコード、列挙型、関数、Result、Option である。Result は成功または失敗を表す型であり、回復可能な失敗を例外ではなく値として扱う。Option は値が存在する場合と存在しない場合を表す型であり、null や nil の無制限な伝播を避けるために用いる。これらの型を標準化することで、AI エージェントはエラー処理や欠損値処理の慣用句を安定して生成できる。
関数定義は短く、かつ公開境界では型を明示できる形にする。たとえば、設定ファイルを読み込む関数は次のように書ける。
fn load_config(path: Path) -> Result<Config, ConfigError>
raw = fs.read_text(path)?
data = toml.parse(raw)?
Config.from_map(data)
endここで ? は、失敗した Result を呼び出し元へ返す演算子である。より正確には、? の短絡先は、構文的に最も内側にある Result を返す関数または Result を返す無名関数である。無名関数内の ? は、外側の名前付き関数へ非局所的に脱出しない。この規則は、Rust の question mark operator が囲んでいる関数またはクロージャから返る設計と同種の既存設計を参考にする（Rust Reference n.d.-a）。例外を完全に排除するわけではないが、通常の失敗は Result で扱うことを標準スタイルとする。これにより、AI エージェントは失敗経路をコード上で追跡しやすくなる。
データ変換には pipeline を標準的に用いる。pipeline とは、前段の結果を次の関数へ渡す記法である。たとえば、ログ行を読み、空行を除き、構造化データへ変換する処理は次のように表せる。
fn load_events(path: Path) -> Result<List<Event>, ParseError>
fs.read_lines(path)?
|> filter(line -> line.trim() != "")
|> try_map(line -> Event.parse(line))
endpipeline は、メソッドチェーンと似ているが、受け手の型に強く依存しない。データの流れが左から右、上から下へ揃うため、人間にも AI エージェントにも処理順序を追いやすい。標準スタイルでは、短いオブジェクト操作にはメソッド呼び出しを用い、複数段の変換には pipeline を用いる。
失敗しうる列変換には、純粋な map ではなく try_map を用いる。map は T -> U を受け取り List<U> を返す。これに対し、try_map は T -> Result<U, E> を受け取り、すべて成功した場合に Ok(List<U>) を返し、いずれかの要素が失敗した場合に最初の Err(E) を返す。これは Haskell の traverse/sequenceA や Rust の Result に対する collect と同じく、効果を持つ値の列を Result の外側へ反転する標準機能として位置づける（Haskell base n.d.; Rust Standard Library n.d.-a）。したがって、map(line -> Event.parse(line)?) のように、通常の map 内部から外側関数へ失敗を伝播する書き方は標準形ではなく、型検査器は map が要求する返り値型と無名関数の返り値型の不一致として診断する。
分岐には pattern matching を用いる。pattern matching とは、値の形に基づいて分岐し、同時に内部の値を束縛する構文である。Result や Option の分解を標準化することで、エラー処理の形を統一できる。
fn display_name(user: Option<User>) -> String
match user
Some(u) -> u.name
None -> "anonymous"
end
end契約は関数本体の近くに置く。事前条件は require、事後条件は ensure、型またはモジュールの不変条件は invariant で表す。たとえば、ポート番号を検証する関数は次のように書ける。
fn normalize_port(port: Int) -> Int
require port >= 0 and port <= 65535
ensure result in 1..65535
if port == 0
8080
else
port
end
endこの例では、result は関数の返り値を指す特別な名前である。契約は文書、実行時検査、テスト生成、診断に再利用される。AI エージェントは、修正時に契約を変更対象ではなく維持すべき仕様として扱える。
typed holes は中核言語の式として扱う。穴は _ で表し、型検査器は穴を含むプログラムを破棄せず、期待型と候補情報を返す。
fn parse_config(path: Path) -> Result<Config, ConfigError>
ensure result.is_ok implies result.value.port in 1..65535
raw = fs.read_text(path)?
config = _ satisfy port in 1..65535
Ok(config)
endこの例で ensure は返り値 result に対する関数の事後条件である。一方、satisfy は typed hole に対する局所的な補完制約であり、穴に入る Config 値の port が満たすべき条件を処理系へ伝える。事後条件と途中状態の補完制約を分けることで、AI エージェントは関数境界で維持すべき仕様と、穴を埋めるための局所条件を混同せずに扱える。重要なのは、穴を含むコードが formatter、language server、graph、diagnostics の対象であり続けることである。構文エラーで処理系全体が停止する設計では、段階的生成の利点が失われる。
モジュールの中核単位は、公開 API、依存、契約、副作用、例、テストを含む。表層的には短い宣言で表し、中核的には依存グラフ、effect graph、テスト責務へ変換できる。これにより、AI エージェントは実装本文だけでなく、変更範囲と検証範囲を言語処理系から取得できる。
以上の中核設計は、単一の新奇な構文を提案するものではない。むしろ、既存言語で有効であった要素を、AI エージェントの生成ループに合わせて統合する設計である。短い表層、直交的な意味論、明示された境界、機械可読な中間情報を同時に備えることが、本章の要点である。
本章では、提案言語の表層構文を設計する。表層構文の目的は、短く、読みやすく、修正しやすく、診断しやすいコードを実現することである。AI エージェントにとっての構文設計では、生成トークン数だけでなく、読解トークン数と修正トークン数が重要になる。読解トークン数とは、ある変更を行うためにエージェントが読まなければならないコード量を指す。修正トークン数とは、失敗後に生成し直す必要がある差分量を指す。
まず、ブロック構文について述べる。提案言語は、ブロック境界を明示し、部分生成後の構造復元を容易にする可能性があるという仮説のもと、do ... end 型の明示的な終端を採用する。Python のようなインデントベースの構文は視覚的に簡潔であるが、インデントのずれが構文エラーとして現れうるため、部分生成時の復旧性は実証評価の対象となる。一方、波括弧を多用する構文は、短いスクリプトでは記号量が増える。end による終端は、Ruby や Elixir のように自然言語的な可読性を保ちつつ、AI エージェントがブロック境界を復元しやすくなるかを検証するための設計選択として位置づける。
ただし、インデントは意味を持たないわけではない。formatter は標準インデントを強制し、ブロックの入れ子を明確に表示する。構文解析上は end が境界を決め、可読性上はインデントが境界を示す。この二重化により、生成時の頑健性と人間の読解性を両立させる。
次に、pipeline operator を標準構文として採用する。pipeline operator とは、左辺の値を右辺の関数へ渡す演算子であり、ここでは |> と表記する。複数段のデータ変換では、入れ子の関数呼び出しより pipeline の方が処理順序を追いやすい。
orders
|> filter(order -> order.status == "paid")
|> map(order -> Invoice.from_order(order))
|> collect()この記法は、AI エージェントにとっても有利になることを期待する。各行が一つの変換段階に対応するため、失敗した段階を局所化しやすく、修正差分も小さくなるという仮説である。標準スタイルでは、二段以上のデータ変換には pipeline を推奨し、単純なフィールド参照や状態を持つオブジェクト操作にはメソッド呼び出しを許す。
無名関数とブロックは統一する。複数のラムダ構文が併存すると、同じ処理に対する書き方が分散する。提案言語では、短い変換には x -> expr を用い、複数行の処理には do ... end を用いる。
users |> map(user -> user.email)
users |> map do user
require user.active
user.email.lower()
endこれにより、AI エージェントは単純な式と複雑な処理を安定した規則で書き分けられる。
エラー処理では、回復可能な失敗には Result 型を基本とする。例外は、プログラムの通常制御フローではなく、回復不能な失敗や境界外の障害に限定する。Result は Ok(value) または Err(error) を持つ型であり、? によって失敗を呼び出し元へ伝播できる。この方針により、外部入出力、パース、検証、永続化の失敗経路がコード上に現れる。
? の伝播先は、現在の関数または現在の Result を返す無名関数である。したがって、x -> fallible(x)? は、その無名関数自体が Result を返す場合にのみ正しい。通常の map が T -> U を要求する箇所でこの形を書いた場合、処理系は外側関数への非局所脱出として解釈せず、T -> Result<U, E> が渡された型不一致として診断する。失敗しうる変換を pipeline で外側の Result へまとめる場合は、try_map のような traverse 型の標準関数を用いる。この区別を構文規則ではなく型規則として明示することで、AI エージェントは map、try_map、? を一貫した失敗処理パターンとして生成できる。Rust の ? が囲んでいる関数またはクロージャから返る仕様、および Haskell の traverse が作用を左から右に評価して結果を集める設計は、この分離を検討する際の参照点になる（Rust Reference n.d.-a; Haskell base n.d.）。
欠損値には Option 型を用いる。null や nil を任意の型へ混入させると、失敗が遠い実行地点で現れ、診断が難しくなる。Option は Some(value) または None として明示され、pattern matching により処理される。これにより、AI エージェントは欠損値処理を標準化された形で生成できる。
暗黙の戻り値は、関数末尾の式に限定して許す。短い関数では明示的な return を省略できるため、生成トークン数が減る。一方、途中で処理を抜ける場合やエラーを返す場合には、return または ? を用いて意図を明確にする。これにより、Ruby 的な簡潔性と制御フローの明示性を両立させる。
メタプログラミングとドメイン固有言語は制限付きで許す。ドメイン固有言語とは、特定領域の記述に特化した小さな言語や記法を指す。無制限なメタプログラミングは、hidden dependencies を増やし、AI エージェントが実際に存在する関数や型を把握しにくくする。したがって、マクロや DSL は展開結果、生成される公開 API、型、依存、副作用を veln graph や veln explain で取得できる場合に限り、標準的に許可する。
構文評価の指標は、行数だけではない。同じ処理を Ruby、Python、Elixir、TypeScript、Rust と比較した場合の実装行数、生成トークン数、修正時の差分サイズ、抽象構文木の単純さ、構文エラーからの復帰率を測る必要がある。特に AI エージェントにとっては、構文エラーが起きたときに formatter や parser がどれだけ部分的な構造を保持できるかが重要である。したがって、第12章の評価では、構文エラー回復率、ブロック境界の修復回数、修正差分サイズを明示的に測定対象とする。
以上の構文設計は、表現力を最大化するものではなく、安定した生成と局所的な修正を優先する。多様な書き方より、少数の標準形を重視することが、AI エージェントと人間が共有するコードベースでは有効であるという設計仮説を置く。ただし、この仮説は do ... end、インデント、波括弧、pipeline のいずれが実際に構文エラー回復や修正差分の削減に寄与するかを先取りして証明するものではない。これらの評価により、構文上の標準化がどの程度有効であったかを検証する必要がある。
本章では、提案言語における型、契約、副作用の設計を述べる。これらは混同されやすいが、異なる責務を持つ。型は値の形と操作可能性を表す。契約は関数やモジュールが満たすべき意味的条件を表す。副作用は、関数が外部世界または可変状態へ与える影響を表す。AI エージェントにとって重要なのは、これらが別々に追跡され、必要なときに統合診断として取得できることである。
型システムの基本方針は、常時強い型ではなく、必要な場所で強い型である。内部の短い処理では型推論を優先し、公開 API、外部入出力、永続化、ネットワーク、安全性境界では型注釈とスキーマを要求または強く推奨する。これにより、初回生成時の記述負荷を抑えながら、壊れてはならない境界では静的な検査を行う。
たとえば、公開関数は次のように型を明示する。
pub fn create_user(input: UserInput) -> Result<User, UserError>
require input.email != ""
require input.name.size > 0
ensure result.is_ok implies result.value.id != None
user = User.new(input.email, input.name)
Ok(user)
endこの例では、型は入力と出力の形を示し、契約はメールアドレス、名前、成功時の返り値に関する条件を示す。ensure は局所変数 user ではなく、関数終了後の返り値 result を対象にする。型だけでは「空文字列ではない」という条件を表しにくく、契約だけでは UserInput と User の構造を十分に表せない。両者を併用することで、AI エージェントは修正時に守るべき条件をより正確に取得できる。
外部入出力では、スキーマを境界に置く。スキーマとは、JSON、TOML、HTTP request、database row など、外部から来るデータの構造を定義する記述である。外部データは信頼できないため、言語はスキーマ検証を標準化し、検証済みの値だけを内部型へ変換する。
schema UserInput
email: String where email.contains("@")
name: String where name.size > 0
endこのようなスキーマは、実行時検証、API 文書、テストデータ生成、構造化診断に再利用できる。AI エージェントが HTTP API を変更する場合、入力仕様と検証失敗時のエラーが同じ場所から導出されるため、更新漏れが減る。
契約は require、ensure、invariant の三種類を基本とする。require は関数呼び出し前に満たされるべき事前条件、ensure は関数終了後に満たされるべき事後条件、invariant は型またはモジュールが常に満たすべき不変条件である。契約違反時には、どの条件が破られたかだけでなく、呼び出し側と実装側のどちらに責任があるかを示す blame assignment を返す。blame assignment とは、契約違反の原因を、契約を満たさず呼び出した側、または契約を満たすべき実装側へ分類する診断である。
この責任帰属の考え方は、契約、とくに高階関数に対する契約研究で明示的に扱われてきた。Findler and Felleisen は、高階関数では第一階の事前条件・事後条件よりも責任関係が複雑になることを示し、契約監視と blame assignment の形式的な扱いを与えた（Findler and Felleisen 2002）。本レポートでは、この研究をそのまま実装するのではなく、エージェント向け構造化診断として単純化して利用する。第一階の require 違反は呼び出し側候補、ensure 違反は実装側候補として返す。ただし、高階関数、コールバック、非同期境界、外部サービス境界では責任を一意に決められない場合があるため、診断には不確実性と関連する境界を残す。
契約は、文書と重複してはならない。自然文コメントに同じ条件を書き、契約にも同じ条件を書くと、両者が乖離する。提案言語では、契約を文書生成の入力として扱い、ドキュメントには契約から導出された条件を表示する。人間向けには読みやすい説明を生成し、AI エージェント向けには機械可読な条件を返す。
副作用システムは、関数が外部世界へ与える影響を追跡する。対象となる副作用には、ファイルシステム、ネットワーク、データベース、時刻、乱数、プロセス起動、環境変数、標準入出力が含まれる。提案言語では、これらを fs、net、db、time、random、process などの effect label として表す。
fn issue_invoice(order: Order) -> Result<Invoice, InvoiceError>
effect db: write
effect time: read
now = Time.now()
invoice = Invoice.issue(order, now)
db.insert(invoice)?
Ok(invoice)
end副作用情報は、AI エージェントが安全にリファクタリングするために重要である。純粋なデータ変換関数は並べ替えや抽出が比較的容易であるが、データベース書き込みや時刻取得を含む関数は順序を変えると意味が変わる可能性がある。effect label があれば、エージェントは変更時に危険な操作を識別できる。
型エラー、契約違反、副作用違反は、すべて構造化診断として返されるべきである。たとえば、純粋関数として宣言された関数内でファイル読み込みが行われた場合、診断は位置、呼び出された関数、必要な effect label、修正候補を返す。修正候補には、関数へ effect fs: read を追加する案と、ファイル読み込みを呼び出し元へ移す案が含まれる。
以上の設計により、型は形を、契約は意味条件を、副作用は外部影響を担当する。これらを分けて設計することで、過度に複雑な型システムへすべてを押し込まず、AI エージェントが段階的に理解できる検証体系を構築できる。
本章では、typed holes を AI エージェント向け言語の第一級機能として設計する。typed holes とは、未完成の式や定義を明示的な穴としてプログラム内に残し、その穴に期待される型や周辺文脈を処理系が返す仕組みである。従来の多くの言語では、未完成コードは構文エラーまたは型エラーとして扱われ、コンパイラやツールチェーンの処理がそこで止まりやすい。これに対し、本レポートでは、未完成コードを壊れたコードではなく、情報を持つ作業状態として扱う。
本レポートでは、複雑なプログラムを一度で完全に生成させるよりも、構造を先に置き、未確定部分を穴として残し、診断に基づいて補完する作業単位へ分解する方が、AI エージェントにとって扱いやすいという設計仮説を置く。typed holes は、この過程を言語機能として支援する。穴が単なる _ であっても、型検査器は周囲の関数シグネチャ、契約、変数、戻り値の期待型から、穴に必要な情報を推論できる。Blinn らは、Hazel の typed holes と言語サーバを LLM 補完に接続し、期待型や束縛文脈を補完入力へ与えることで、静的文脈を利用した補完を行う手法を示している（Blinn et al. 2024）。したがって、本章の typed hole completion は、この直接の先行研究を踏まえつつ、契約、回帰テスト選択、doc drift、safe repair との統合を本レポートの未検証の拡張として扱う。
たとえば、設定ファイルを解析する途中状態は次のように表せる。
fn parse_config(path: Path) -> Result<Config, ConfigError>
ensure result.is_ok implies result.value.port in 1..65535
raw = fs.read_text(path)?
config = _ satisfy port in 1..65535
Ok(config)
endこのプログラムは未完成であるが、処理系は穴の期待型が Config であること、スコープ内に raw: String と path: Path があること、返り値の成功時には result.value.port が 1..65535 に含まれる必要があること、さらに穴自体の補完制約として port in 1..65535 が与えられていることを知っている。提案言語では、この typed holes の情報を契約とテスト影響グラフに接続し、穴に対する診断を次のように返す。
{
"hole": "_",
"expected_type": "Config",
"available_bindings": ["raw: String", "path: Path"],
"candidate_functions": ["toml.parse", "json.parse", "Config.from_map"],
"related_contracts": ["result.is_ok implies result.value.port in 1..65535"],
"hole_constraints": ["port in 1..65535"],
"related_tests": [
"config_test.loads_valid_file",
"config_test.rejects_invalid_port"
]
}この診断は、人間にも AI エージェントにも有用である。人間は補完方針をすばやく把握でき、AI エージェントは必要な候補を過剰な文脈なしに取得できる。特に重要なのは、関連契約と関連テスト候補が返される点である。ただし、期待型、束縛文脈、候補定義を言語サーバ経由で補完に使う発想は既存研究に含まれる（Blinn et al. 2024）。本レポートの拡張は、typed holes を回帰テスト選択、依存グラフ、契約、doc drift、safe repair と接続し、穴を埋めた後に優先して検証すべき範囲まで返す点にある。穴を埋めるたびに常に全テストを実行するのではなく、影響を受ける可能性のあるテストを保守的に優先実行できることを目標とする。
typed holes は式だけでなく、型、関数、契約にも現れうる。たとえば、戻り値のエラー型が未確定である場合、次のように書ける。
fn import_users(path: Path) -> Result<List<User>, _>
rows = csv.read(path)?
rows |> try_map(row -> User.from_row(row))
endこの場合、? は csv.read(path) の失敗を import_users から返す。一方、try_map に渡された無名関数は Result<User, E> を返し、try_map が行ごとの失敗を Result<List<User>, E> へ集約する。したがって、処理系は csv.read と User.from_row が返しうるエラー型から、穴に入る候補を提示できる。これにより、AI エージェントは型名を推測で生成するのではなく、実際に利用可能なエラー型から選択できる。また、map(row -> User.from_row(row)?) のような記法は、外側の import_users へ短絡する特別規則を持たないため、通常の map には不適合な無名関数として診断される。
部分プログラムの保存可能性も重要である。部分プログラムとは、未完成部分を含むが、構文解析、型推論、依存解析、整形、ドキュメント生成の一部が可能なプログラムを指す。AI エージェントの作業では、途中状態がしばしば発生する。途中状態をファイルとして保存できなければ、エージェントは一度の応答で完全な差分を生成する必要があり、失敗時の復旧が難しくなる。
処理系は、穴を含むプログラムに対して三段階の検査を行う。第一に、構文が保たれているかを検査する。第二に、穴を許した型検査を行い、穴以外の不整合を検出する。第三に、回帰テスト選択の考え方を踏まえ、穴や変更シンボルから影響を受けうるテストを保守的に分類し、優先実行順を与える（Rothermel and Harrold 1996）。この分類は、失敗原因を常に自動的に同定するものではない。typed hole が原因であるか、既存実装が原因であるか、テスト側が古いかが不明な場合は affected tests に含め、選択結果の根拠と不確実性を診断に残す。影響解析が不完全である場合、依存グラフが粗い場合、公開境界をまたぐ変更がある場合には、全テストへのフォールバックを行う。
safe repair 候補も typed holes と結び付く。safe repair とは、処理系が局所的根拠、影響範囲、適用後検査を添えて提示する修正候補であり、自動適用を意味しない。たとえば、期待型が Result<Config, ConfigError> で穴の式が Config を返す候補であれば、処理系は Ok(...) で包む修正を提示できる。ただし、safe repair は自動適用されるべきではなく、適用根拠と影響テストを診断に含める必要がある。
typed holes は、AI エージェントに無制限の自由を与える機能ではない。むしろ、未完成性を明示し、作業単位を小さくし、検証可能な状態を保つための制約である。これにより、エージェントは不完全な初回生成から始めても、言語処理系の助けを借りて段階的に正しいプログラムへ近づける。
本章では、AI エージェント向け言語における標準ツールチェーンを設計する。プログラミング言語は、構文と意味論だけで成立するわけではない。実際の開発では、formatter、linter、type checker、test runner、package manager、documentation generator、language server、dependency analyzer が連携する。これらが分裂している場合、人間開発者も AI エージェントも、コマンド、設定ファイル、出力形式、失敗の意味を個別に理解しなければならない。
Veln では、標準コマンドを veln に統一する。標準コマンドは少なくとも、veln init、veln run、veln test、veln check、veln fmt、veln doc、veln graph、veln explain、veln repair を含む。これらは個別ツールの単なるラッパーではなく、共通のプロジェクトモデル、共通の診断形式、共通の JSON 出力を持つ。
veln init は、最小プロジェクトを作成する。小規模スクリプトでは設定ファイルなしでも動作するが、プロジェクト化する場合には標準ディレクトリ、テスト配置、ドキュメント配置、パッケージメタデータを生成する。AI エージェントにとっては、初期設定の推測が不要になり、生成対象を実装本体へ集中できる。
veln run は、プログラムを即実行する。単一ファイルもプロジェクトも同じコマンドで扱い、必要な依存関係とエントリポイントを標準規則から解決する。実行失敗時には、人間向け表示に加えて、失敗種類、位置、例外またはエラー値、関連する契約、再現コマンドを JSON で返す。
veln test は、unit test、doctest、property test を統合的に実行する。unit test は個別の関数やモジュールの挙動を検査するテストである。property test は、具体例だけでなく、入力の範囲に対して成り立つ性質を検査するテストであり、QuickCheck はその代表的な先行例である（Claessen and Hughes 2000）。AI エージェントは、失敗したテスト名、失敗位置、期待値、実際値、関連する契約、関連する typed hole を取得できる。
veln check は、型、契約、副作用、lint、ドキュメントのずれを統合的に検査する。個別検査が別々のコマンドに分かれていると、エージェントはどの失敗を優先すべきか判断しにくい。veln check は、構文エラー、型エラー、契約違反、副作用違反、未使用定義、非推奨 API、doc drift を統一された重要度で返す。
veln fmt は、標準スタイルへコードを正規化する。formatter は、人間の好みを反映する道具ではなく、生成分布を安定させる道具である。AI エージェントの出力は、formatter により既存コードと同じ形へ揃えられる。これにより、レビュー差分には意味のある変更だけが残りやすくなる。
veln doc は、API 文書、契約、examples、doctest の結果を統合して文書を生成する。自然文コメントと契約が乖離している場合には、doc drift として警告する。doc drift とは、実装、契約、テスト、文書の間に生じた不整合を指す。AI エージェントが API を変更した場合、文書更新を単なる任意作業ではなく検査対象にできる。
veln graph は、dependency graph、call graph、effect graph、test impact graph を出力する。dependency graph はモジュール間依存、call graph は関数呼び出し関係、effect graph は副作用の伝播、test impact graph は変更が影響しうるテストを表す。test impact graph は、変更後に既存テスト集合のどれを再実行すべきかを選ぶ regression test selection の考え方を、言語処理系の標準機能として扱うための表現である（Rothermel and Harrold 1996）。ただし、このグラフは原因分類器ではなく、影響を受ける可能性のあるテスト集合を保守的に近似する装置である。これらのグラフは、AI エージェントが読むべきファイルと優先的に実行すべきテストを絞るために用いる。
veln explain は、型、エラー、契約、依存関係を説明する。通常のコンパイラエラーは、失敗時にのみ説明を返すことが多い。提案言語では、エージェントが任意のシンボル、型、関数、契約、モジュールについて説明を要求できる。これは、人間が IDE 上で定義ジャンプや型表示を使う行為を、機械可読な API として提供するものである。
構造化診断を設計する際には、既存研究と本レポートの拡張範囲を分ける必要がある。コンパイラエラーメッセージ研究は、人間開発者が説明をどのように読み、どのような説明構造や解決策を有用と感じるかを扱ってきた（Barik et al. 2017; Barik et al. 2018; Marceau et al. 2011）。また、Blinn らは typed holes、Hazel Language Server、LLM 補完を統合し、ChatLSP を Language Server Protocol の保守的拡張として位置づけている（Blinn et al. 2024）。Zhang and Lanser Contributors は、診断、型情報、シンボル解決、リファクタリング前提条件をエージェントや学習ループに渡す方向をプレプリントとして提案している（Zhang and Lanser Contributors 2025）。本レポートは、これらの知見を踏まえ、AI エージェントが次の行動選択に使える構造化データを、言語仕様・契約・テスト影響解析と一体化する。したがって、affected_tests、契約、blame、safe repair 根拠を含む JSON は、既存のエラーメッセージ研究や Language Server Protocol 仕様そのものではなく、提案言語のツールチェーン設計である。
veln repair は、safe repair 候補を生成する。safe repair は本レポートの設計上の用語であり、処理系が局所的な根拠を持って提示できる修正案を指す。たとえば、型名の綴り修正、Result の包み忘れ、未使用 import の削除、契約から導かれる境界チェックの追加、変更後に必要な doctest 更新などが含まれる。veln repair は自動修正を強制せず、候補、根拠、影響範囲、適用後に実行すべきテストを返す。
すべての標準コマンドは、人間向け表示と JSON 出力を持つ。JSON 出力は、少なくとも status、diagnostics、affected_files、affected_tests、suggested_actions を含む。これは既存の Language Server Protocol が提供する診断、補完、コードアクション、および ChatLSP 的な typed hole 文脈提供を基盤にしつつ、契約、関連テスト、safe repair 根拠、doc drift を加える拡張である。例を示す。
{
"status": "failed",
"diagnostics": [
{
"kind": "contract_violation",
"file": "src/users.veln",
"line": 42,
"symbol": "Users.create",
"expected": "email is valid",
"actual": "empty string",
"blame": "caller",
"suggested_tests": ["users_test.rejects_empty_email"]
}
],
"affected_tests": ["users_test.rejects_empty_email"],
"suggested_actions": ["add input validation before Users.create"]
}このような出力により、人間は通常の表示を読み、AI エージェントは構造化された情報を読む。両者が同じ検査結果を異なる形式で共有できることが、エージェント向け標準ツールチェーンの中心である。
本章では、提案言語におけるモジュールとドキュメントの設計を述べる。AI エージェントにとって、モジュールは単なる名前空間ではない。モジュールは、読むべき範囲、変更してよい範囲、維持すべき契約、実行すべきテストを限定する作業単位である。Parnas の情報隠蔽の議論に従えば、モジュールは変更されうる設計判断を隠蔽する単位である（Parnas 1972）。本レポートでは、この考え方をエージェントの文脈選択にも適用する。
提案言語のモジュール宣言は、名前、目的、公開 API、依存、不変条件、副作用、例、テスト責務、移行メモ、設計理由、責任境界を含む。これらをすべて長い自然文で記述するのではなく、機械可読な短い宣言としてコード近傍に置く。
module Billing.Invoice
purpose "Create and validate invoices before persistence"
use Billing.Customer
use Money
use Time
invariant "total equals sum of line item amounts"
invariant "issued invoice cannot be mutated"
effect db: write
effect time: read
pub fn issue(customer: Customer, items: List<Item>) -> Result<Invoice, InvoiceError>
endこの宣言は、人間にはモジュールの責務を示し、AI エージェントには依存グラフ、effect graph、公開 API、契約、影響テストを取得する入口を与える。重要なのは、モジュールの説明が README や外部 wiki に分散しすぎないことである。コードと文書の距離が遠いほど、エージェントは正しい文脈を選びにくくなり、更新漏れも増える。
ドキュメントモデルでは、doc comment、contract、example、doctest を統合する。doc comment は自然文による説明であり、契約は検証可能な条件であり、example は典型的な使い方であり、doctest は実行可能な例である。これらを別々に維持すると、同じ仕様が複数箇所に重複し、乖離する。提案言語では、契約と型からドキュメントの一部を生成し、自然文コメントは設計意図や背景に集中させる。
たとえば、次のような関数定義では、型、契約、example が文書生成に使われる。
/// Create an invoice from validated items.
example
invoice = Invoice.issue(customer, [item])?
invoice.total == item.amount
end
fn issue(customer: Customer, items: List<Item>) -> Result<Invoice, InvoiceError>
require items.size > 0
ensure result.is_ok implies result.value.total > 0
...
endこの例では、自然文は関数の意図を述べ、契約は入力と出力の条件を述べ、example は実行可能な利用例を示す。example ブロックは Result を返せる検査文脈として評価され、Invoice.issue が失敗した場合、? はその example を失敗させ、エラー値を doctest の構造化診断に残す。成功した場合には、末尾の真偽式が満たされるかを検査する。AI エージェントが関数を変更する場合、契約または example が失敗すれば、文書と実装のずれを検出できる。
設計理由の記録には、ADR-lite を用いる。ADR は Architecture Decision Record の略であり、重要な設計判断とその理由を記録する文書である。Nygard は、巨大な設計文書よりも小さく更新しやすい記録として ADR を提案し、判断の文脈、決定、状態、帰結を残すことの重要性を述べている（Nygard 2011）。ADR-lite は本レポートの設計上の用語であり、ADR の考え方を軽量化して、モジュール近傍に短い判断理由を置く方式を指す。長大な設計文書を要求すると保守されにくいため、提案言語では、モジュール宣言内に rationale または decision を短く記録できるようにする。
decision "Invoice total is stored, not recomputed"
because "historical tax rules may change after issue"
endこの情報は、AI エージェントが一見冗長に見える設計を誤って単純化することを防ぐ。たとえば、請求書合計を毎回再計算するリファクタリングは、現在のコードだけを見ると妥当に見えるかもしれない。しかし、過去の税率変更を保存する必要があるという設計理由が近くにあれば、エージェントはその変更を避けられる。
ownership または responsibility boundary も重要である。これは、誰がそのモジュールに責任を持つかという組織情報だけでなく、どの不変条件をそのモジュールが守るかを表す。AI エージェントは、境界を越えて内部実装を書き換える前に、公開 API を通じた変更が可能かを検討すべきである。モジュール宣言が責任境界を示していれば、不要な横断的修正を減らせる。
ドキュメント生成は一方向ではなく、検査も行うべきである。veln doc は文書を生成するだけでなく、公開 API と文書の不一致、存在しない関数を参照する example、契約と矛盾する説明、失敗する doctest を検出する。これにより、ドキュメントは静的な説明ではなく、検証対象の一部になる。
以上のモデルにより、モジュールは、コード、仕様、設計理由、検証、文書を束ねる単位となる。AI エージェントは、この単位を使って文脈を選択し、変更範囲を限定し、人間は同じ情報をレビューと保守に利用できる。
本章では、AI エージェントが提案言語とツールチェーンをどのように利用するかを定義する。従来のコンパイラは、主に人間が書いた完全なプログラムを受け取り、実行可能形式またはエラーを返す道具として設計されてきた。提案言語の処理系は、それに加えて agent-facing compiler として設計される。agent-facing compiler とは、AI エージェントが生成途中のコード、診断、依存関係、補完候補を機械的に取得できるようにしたコンパイラである。
エージェントの基本ループは、次の八段階である。第一に、要求仕様と関連するモジュールドキュメントを読む。第二に、veln graph によって関連モジュール、依存、影響テストを絞る。第三に、typed holes を含む部分実装を生成する。第四に、veln check --json を実行する。第五に、診断、穴情報、契約違反、失敗テストを読む。第六に、穴を埋めるか、既存実装を修正する。第七に、影響を受けるテストだけを再実行する。第八に、契約、doctest、ドキュメントを更新し、全体検査を行う。
このループの特徴は、初回生成の完全性を前提としない点にある。AI エージェントは、最初からすべての詳細を決めるのではなく、処理系から返される構造化情報を利用して段階的に収束する。これにより、プロンプトに過剰な文脈を詰め込む必要が減り、失敗時の修正範囲も小さくなる。
この相互作用を支える第一のインターフェースは、Language Server Protocol の拡張である。Language Server Protocol は、エディタや開発環境と言語サーバが、補完、定義ジャンプ、診断、リネーム、コードアクションなどをやり取りするための通信仕様であり、言語サーバと開発ツール間の通信を標準化することを目的としている（Microsoft n.d.）。Blinn らの ChatLSP は、typed holes の期待型や束縛文脈を LLM 補完へ渡すための Language Server Protocol 拡張案として、本レポートと直接重なる（Blinn et al. 2024）。提案言語では、既存の診断、補完、コードアクションと ChatLSP 的な typed hole 文脈提供を基盤にしつつ、contract explanation、effect query、affected test selection、doc drift detection、safe repair 根拠を追加する。
第二のインターフェースは、JSON diagnostics である。診断は自然文だけでなく、位置、範囲、シンボル、期待型、実際型、契約、関連テスト、修正候補を含む。AI エージェントは、この情報を用いて、どのファイルを読み、どの変更を試し、どのテストを再実行するかを決める。Zhang and Lanser Contributors は、コンパイラと Language Server Protocol 由来の事実を、エージェントの処理報酬や検証可能な分析 bundle に変換する方向を提案している（Zhang and Lanser Contributors 2025）。本レポートの JSON diagnostics はこの近接研究を踏まえるが、関連テスト、契約根拠、doc drift、safe repair を言語設計の標準出力として統合する点に焦点を置く。
{
"kind": "type_mismatch",
"symbol": "Config.from_map",
"span": {"file": "src/config.veln", "start": 12, "end": 18},
"expected": "Map<String, Value>",
"actual": "String",
"related_hole": "_config_parser",
"candidate_fixes": [
"parse raw with toml.parse before Config.from_map"
],
"affected_tests": ["config_test.loads_valid_file"]
}第三のインターフェースは、dependency graph API である。AI エージェントは、要求に関係するファイルを全文検索だけで探すべきではない。全文検索は有用だが、依存関係、公開 API、effect、テスト責務を考慮しない。dependency graph API は、変更対象の候補、下流依存、循環依存、公開境界を返す。これにより、エージェントは関連性の低いファイルを読みすぎることを避けられる。
第四のインターフェースは、affected test selection である。これは、変更されたシンボルやモジュールに基づいて、優先的に実行すべきテストを選ぶ仕組みであり、回帰テスト選択に関する既存研究と接続する（Rothermel and Harrold 1996）。すべてのテストを毎回実行することは、時間と費用の面で不利である。一方、関連テストを実行しなければ回帰を見逃す。提案言語では、関数、モジュール、契約、doctest、property test の関係を記録し、変更に応じた保守的なテスト集合を返す。false negative を避けることを優先し、不明な依存は affected tests に含める。false positive が増えすぎる場合や解析根拠が失われる場合には、選択実行ではなく全テストへフォールバックする。
第五のインターフェースは、safe repair API である。safe repair API は本レポートで提案する設計上の API 名であり、既存標準を指すものではない。AI エージェントは、修正候補を自由生成するだけでなく、処理系が提示する局所的な修正候補を利用できる。safe repair API は、候補、適用範囲、根拠、リスク、適用後に実行すべき検査を返す。これにより、エージェントは推測に頼る修正を減らせる。
第六のインターフェースは、typed hole completion API である。これは、穴ごとに期待型、利用可能な束縛、候補関数、関連契約、関連テスト候補を返す。期待型と束縛文脈を補完に利用する部分は Blinn らの研究と重なるため、本レポートでは既存研究を前提とした機能とみなす。重要なのは、補完候補を単なる文字列として返すのではなく、なぜ候補となるのか、どの契約と結び付くのか、適用した場合にどのテストを優先実行すべきかを含めることである。
第七のインターフェースは、contract explanation API である。契約が複雑な場合、AI エージェントは単に条件式を読むだけでは意味を取り違える可能性がある。contract explanation API は、契約の自然文説明、由来するドキュメント、失敗例、関連テストを返す。これにより、エージェントは契約を削除したり弱めたりする前に、その意図を確認できる。
第八のインターフェースは、doc drift detection API である。AI エージェントがコードを変更すると、ドキュメント、例、doctest、契約が古くなることがある。doc drift detection は、変更された公開 API と文書中の参照を照合し、更新が必要な箇所を返す。
以上の相互作用モデルにより、AI エージェントは、自然言語プロンプトとテキスト編集だけに依存する存在ではなくなる。言語処理系は、エージェントが作業するための観測、診断、候補、検証範囲を返す共同作業相手となる。
本章では、提案言語が AI エージェントによるコード生成と修正に有利かを評価する方法を設計する。評価では、単純な Pass@k だけでは不十分である。Pass@k は、複数回生成した候補のうち少なくとも一つがテストを通過する確率を表す指標であり、HumanEval を用いた Codex 評価で代表的に用いられた（Chen et al. 2021）。Pass@k は単発問題の機能的正しさを測るには有用であるが、AI コーディングエージェントの実用性は、テスト通過率だけでなく、通過までの時間、費用、修正回数、差分の大きさ、レビュー負荷、保守性によって決まる。
中心指標は Time-to-green である。Time-to-green とは、タスク開始から指定されたテストが通過するまでの時間を指す。これは、初回生成時間、コマンド実行時間、失敗診断の解釈時間、修正時間を含む。AI エージェント向け言語が有効であれば、初回生成が少し遅くても、診断と修正が速くなり、総合的な Time-to-green が短くなる可能性がある。
第二の指標は Cost-to-green である。Cost-to-green は、テスト通過までに消費した API 費用、入力トークン、出力トークン、ツール実行回数を含む。小規模な実装では短い言語が有利に見えるが、大規模な修正では、読むべき文脈が少なく、診断が構造化され、影響テストが絞られることが費用削減に寄与する。
第三の指標は Iterations-to-green である。これは、生成、実行、失敗、修正の反復回数を数える。反復回数が少ないほどよいとは限らない。一回で長大な差分を生成し、偶然テストを通すよりも、小さな反復で仕様と契約を保ちながら収束する方が保守上望ましい場合がある。したがって、反復回数は差分サイズやレビュー時間と併せて評価する必要がある。
第四の指標は、Generated tokens と Repair tokens である。Generated tokens は初回生成に使われた出力トークン数、Repair tokens は失敗後の修正に使われた出力トークン数である。提案言語の目的は、単に Generated tokens を最小化することではなく、Repair tokens と文脈入力量を含めた総量を減らすことである。
第五の指標は Diff size である。Diff size は、タスク完了までに変更された行数、ファイル数、構文ノード数を表す。AI エージェントが広範囲を不用意に変更すると、レビュー負荷と回帰リスクが増える。モジュール境界、契約、影響範囲分析が有効であれば、Diff size はタスクの本質的範囲に近づく。
第六の指標は Diagnostic usefulness である。これは、診断が次の修正行動をどれだけ直接支援したかを測る。具体的には、診断に期待型、実際型、関連契約、関連テスト、修正候補が含まれていた割合、診断後の修正が成功した割合、診断を読むために追加で必要だったファイル数を測る。
第七の指標は Context size である。Context size は、エージェントがタスク完了までに読んだファイル数、行数、トークン数である。AI エージェントは入力文脈が大きくなるほど費用が増え、重要情報を見落とす可能性も高まる。dependency graph と affected test selection が有効であれば、Context size は小さくなるはずである。
第八の指標は Regression rate である。これは、対象タスクのテストは通過したが、既存機能を壊した割合を表す。AI エージェント向け言語では、局所的な成功だけでなく、既存契約、doctest、property test、影響テストによって回帰を抑えられるかを評価する必要がある。
第九の指標は Human review time である。これは、人間レビューアが差分を理解し、承認または修正依頼を出すまでの時間である。AI による生成が速くても、人間がレビューできない差分であれば実用上の価値は低い。共通可読性、標準スタイル、契約、設計理由の記録が、レビュー時間に与える影響を測るべきである。
第十の指標は Syntax stability である。これは、構文設計と標準 formatter が、同一タスクに対する生成形の分散をどれだけ抑えるかを測る。具体的には、formatter 適用後の構文多様性、同一タスクを複数回生成した場合の抽象構文木上のばらつき、構文エラー回復率、構文エラー後に正しい構造へ戻るまでの修正回数を測定する。この指標により、「少数の標準形が AI エージェントの探索空間を狭めうる」という本レポートの設計仮説を、単なる印象ではなく評価対象として扱う。
比較対象には、Ruby、Python、JavaScript、TypeScript、Elixir、D、Rust、Go、提案言語を含める。Ruby、Python、JavaScript は簡潔な動的言語として、小規模生成の基準になる。TypeScript は JavaScript コードベースへ型注釈を漸進的に導入する実務的基準になる。Elixir は統一ツールチェーンと doctest の基準になる。D は contract と unittest の基準になる。Rust と Go は、静的検査、明示性、ツールチェーンの比較対象になる。
ただし、この比較では、言語そのものの効果と専用ツールチェーンの効果を分離しなければならない。提案言語だけに veln graph、veln check --json、typed hole completion、affected test selection、safe repair を与え、既存言語には最小限の実行コマンドだけを与えるなら、観測された差は表層構文や型設計ではなく道具立ての差で説明されてしまう可能性がある。したがって、既存言語側には少なくとも二種類の条件を置く。第一は素朴ベースラインであり、標準実行環境、単体テスト、最小限の formatter のみを用いる。第二は実務的ベースラインであり、各言語で一般的に利用可能な formatter、test runner、type checker または lint、language server、パッケージ管理機構を与える。たとえば TypeScript では tsc と TypeScript language server、Python では型検査器と Python language server、Rust では cargo と rust-analyzer、Go では go test と gopls を組み合わせる。具体的なツール名とバージョンは、評価時点で固定して記録する。
提案言語側にもアブレーションを置く。アブレーションとは、複数の設計要素を段階的に取り除き、どの要素が結果へ寄与したかを調べる評価方法である。条件は少なくとも、表層構文のみ、構造化診断あり、typed holes あり、関連テスト選択あり、safe repair あり、doc drift 検出ありに分ける。この設計により、「提案言語が速いか」だけではなく、「どの設計要素が Time-to-green、Cost-to-green、Context size、Regression rate、Human review time に寄与したか」を測定できる。
タスクは複数種類に分ける。小規模 CLI 実装、JSON または TOML 設定パーサ、HTTP API、データベース migration、既存コードへの機能追加、バグ修正、リファクタリング、contract 追加、仕様変更への追従を含める。新規生成だけでなく、既存コードの変更を含めることが重要である。AI エージェントの実用的な価値は、空のファイルからの生成よりも、既存コードベースを壊さずに変更できるかに現れる。
実験条件は厳密に揃える。同じモデル、同じタスク仕様、同一の仕様ケースと判定オラクル、同じ最大試行回数、同じ外部ライブラリ制約、同じ実行環境を用いる。ここで同一の仕様ケースと判定オラクルとは、全実装が満たすべき入出力、状態遷移、エラー条件、成功条件を共通化し、結果判定の基準を言語間で変えないことを指す。可能な場合は CLI または API レベルのブラックボックステストを共通化し、言語内単体テストを用いる場合には、言語別テストハーネスを事前登録した対応表に基づいて生成または固定する。これにより、テストハーネスの品質差や言語別ライブラリ差が、言語設計そのものの効果として混入することを抑える。ただし、文字通り同じプロンプトを全言語へ与えるだけでは、言語ごとの標準コマンド、プロジェクト構造、型検査方法、テスト実行方法の差を公平に扱えない。したがって、評価では、同じタスク仕様、同じ成功条件、同一の入出力オラクルに加え、同等の情報量を持つ事前登録済みプロンプトテンプレートを用いる。共通部分には要求仕様、成功条件、制約、失敗時の報告形式を置き、言語別部分には標準コマンド、許可ツール、プロジェクト初期構造、固定済みバージョンだけを機械的に差し込む。加えて、各条件でエージェントに許可するツール呼び出し、診断の提示形式、失敗時に追加で与える情報を明示し、既存言語の実務的ベースラインと提案言語の統合ツールチェーン条件を同列に比較できるようにする。モデルの確率的性質を考慮し、各条件を複数回試行し、平均、中央値、分散、失敗率を報告する。API latency やキャッシュの影響を記録し、可能な範囲で分離する。
affected test selection を評価する場合には、選択されたテストが実際に失敗原因を含んだかだけでなく、false negative、false positive、選択テスト率、全テストへフォールバックした割合を報告する。false negative は、選択されなかったテストに回帰が含まれていた割合であり、エージェント支援では特に重大である。false positive は、影響を受けないテストを選択した割合であり、Time-to-green と Cost-to-green を悪化させる。選択テスト率は、全テスト集合に対して選択されたテストの比率であり、影響解析が保守的すぎるか、危険に狭すぎるかを判断する補助指標となる。
定性的評価も必要である。生成されたコードが標準スタイルに沿っているか、契約を弱めていないか、エラー処理が適切か、ドキュメントと doctest が更新されているか、レビューしやすい差分かを人間評価する。これは自動テストでは測りにくい設計品質と保守性を補うためである。
以上の評価方法により、提案言語の有効性を、単なる成功率ではなく、生成、修正、検証、レビューを含む開発ループ全体から測定できる。
本章では、提案言語の設計上のトレードオフを考察する。AI エージェントに適した言語設計では、短さ、検証性、明示性、柔軟性、既存エコシステムとの接続を同時に満たす必要がある。しかし、これらは常に同じ方向を向くわけではない。したがって、提案言語の価値は、どの性質を最大化するかではなく、どの場面でどの制約を強めるかにある。
Endoh が2026年3月5日の記事で報告した小規模 mini-git 課題では、Ruby、Python、JavaScript のような動的で設定摩擦の小さい言語が、初回生成と機能追加において速く安価に見えた（Endoh 2026a; Wiggers 2026）。これは、型注釈が少なく、短い試作を即実行できる言語が AI エージェントの初期ループで有利になりうることと整合する。ただし、その原因は動的性だけではなく、記述量、設定ファイル、慣用句、学習データ上の馴染みなどの複合要因として扱うべきである。
一方、静的検査は、大規模修正で影響範囲や境界条件を早期に発見する助けになりうる。公開 API、永続化、ネットワーク、外部入出力では、値の形や失敗経路が曖昧であるほど、修正の影響範囲が広がる。AI エージェントは、暗黙のデータ構造や実行時にしか現れない型不整合を見落とす可能性がある。ただし、その効果は型情報だけでなく、公開 API、契約、テスト、診断の設計に依存する。したがって、提案言語では、内部処理には型推論と柔軟性を残し、境界では型、スキーマ、契約、副作用情報を強める。
この設計は、動的言語と静的言語の折衷ではなく、検査の配置を変える試みである。重要なのは、どのコードにも同じ強度の検査を要求することではなく、失敗したときの費用が高い場所、つまり公開境界、外部境界、安全性境界に検査を集中させることである。
簡潔な構文は、AI エージェントの生成トークン数を減らし、人間の読解負荷も下げる。しかし、簡潔性が暗黙性に依存する場合、修正時の負荷はむしろ増える。たとえば、無制限なメタプログラミング、実行時に生成されるメソッド、暗黙のグローバル状態、過度に柔軟な DSL は、hidden dependencies を増やす。
提案言語では、簡潔性を許すが、展開結果、型、依存、副作用を取得できることを条件にする。DSL を禁止するのではなく、veln graph や veln explain によって、DSL が生成する公開 API、呼び出し関係、テスト責務を可視化する。これにより、人間には領域に合った短い記法を提供し、AI エージェントには展開後の構造を提供できる。
この方針は、記法の自由度を一定程度制限する。熟練者にとっては冗長に感じられる場合がある。しかし、AI と人間が共同で保守するコードベースでは、個人の表現力よりも、標準形への収束と修正可能性が重要になる。
人間に読みやすいコードと AI に扱いやすいコードは、多くの部分で一致する。標準スタイルがあること、モジュール境界が明確であること、契約が近くにあること、副作用が追跡できること、実行可能な例が存在することは、人間にも AI にも有利である。
ただし、AI エージェントには、人間向け表示だけでは不十分である。自然文のエラーメッセージは、人間が読むには十分でも、エージェントが確実に次の行動へ変換するには曖昧な場合がある。既存の Language Server Protocol が提供する診断・補完・コードアクションを基盤に、契約、関連テスト、safe repair 根拠を返す拡張が必要である。
したがって、提案言語は、人間向け最適化と AI 向け最適化を対立させない。ソースコードは人間が読める形に保ち、処理系が追加の機械可読情報を返す。AI 専用の不可読な表現を主たる成果物にしないことが、レビュー、監査、教育、長期保守の条件である。
小規模タスクでは、Ruby や Python 的な短さと低いセットアップ摩擦が有利に見える場合がある。設定なしで実行でき、基本的なファイル処理や文字列処理を短く書け、エラー処理が単純で、慣用句が安定していれば、AI エージェントは短時間で動くコードを生成しやすい。これは、プロトタイピング、スクリプト、簡易 CLI、データ変換では大きな利点である。ただし、Endoh の結果は原因を短さだけへ還元できない。OCaml や Haskell は最終的な行数が少ないにもかかわらず、時間と費用が必ずしも小さくなかったため、短い構文、標準ライブラリだけで完結する課題設定、設定ファイルの少なさ、慣用句の安定性、学習データ上の馴染みを複合要因として扱う必要がある（Endoh 2026a; Wiggers 2026）。
しかし、大規模コードベースでは、短さだけでは不十分である。変更の影響範囲、公開 API の互換性、永続化データ、セキュリティ境界、ドキュメント同期、回帰テストが問題になる。短いが暗黙的なコードは、初回生成では有利でも、保守時に高い費用を生む可能性がある。
提案言語は、小規模スクリプトからモジュール化されたプロジェクトへ段階的に移行できる必要がある。初期段階では型注釈や契約を最小限にし、プロジェクト化に伴って公開 API、schema、contract、effect、doctest を追加する。この段階的な移行可能性がなければ、言語は試作には軽すぎ、本番には弱すぎるものになる。
本レポートの提案は、言語仕様だけでは完結しない。typed holes、構造化診断、影響テスト選択、doc drift detection、safe repair は、構文だけでなくツールチェーンによって実現される。したがって、AI エージェント向け言語を評価する際には、言語本体と標準ツールチェーンを分離しすぎてはならない。一方で、経験的評価では両者を一体化しすぎると、表層構文、型設計、標準ライブラリ、専用ツールチェーンのどれが結果に寄与したかを識別できない。第12章で述べたように、既存言語には実務的ベースラインを与え、提案言語にはアブレーションを置くことで、この交絡をできるだけ小さくする必要がある。
これは、従来の言語比較に対する注意点でもある。ある言語が短く書けるかどうかだけでなく、その言語の formatter、test runner、language server、package manager、documentation generator がどれだけ統合されているかが、AI エージェントの作業面積を左右する。言語設計と開発環境設計を一体として扱うことが、AI エージェント時代にはより重要になる。
本章では、本レポートの議論と評価計画に対する妥当性への脅威を整理する。AI エージェント向け言語設計は、言語仕様、モデル性能、ツールチェーン、評価タスク、実行環境が相互に影響する領域である。そのため、単一の実験結果から一般的な結論を導くことには慎重でなければならない。
内的妥当性とは、観測された結果が本当に検証したい要因によって生じたかに関する妥当性である。第一の脅威は、モデル固有の得意不得意である。ある LLM が Ruby や Python を得意とするのは、その言語の構文が本質的に AI 向けであるからではなく、学習データ上の出現頻度や品質が高いからかもしれない。逆に、ある静的言語で失敗が多い場合も、言語仕様そのものではなく、モデルがその言語の慣用句を十分に学習していない可能性がある。
第二の脅威は、プロンプト設計である。同じタスクでも、自然言語の指示、制約の書き方、テストの提示方法、既存コードの渡し方によって結果は大きく変わる。提案言語が有利に見えるプロンプトを無意識に設計してしまう危険がある。評価では、共通仕様と機械的に差し込む言語別情報を分けたプロンプトテンプレートを事前登録し、言語ごとに同等の情報量を与える必要がある。テンプレート、許可ツール、ツールのバージョン、失敗時に返す診断形式を公開し、プロンプト差が結果へ与えた影響も分析対象に含める。
第三の脅威は、タスク選定である。ファイル処理や文字列処理中心のタスクはスクリプト言語に有利であり、並行性やメモリ安全性中心のタスクは別の言語に有利である。提案言語の機能を示しやすいタスクだけを選ぶと、評価は偏る。タスク集合には、新規生成、既存コード修正、バグ修正、リファクタリング、ドキュメント同期を含めるべきである。
第四の脅威は、言語効果とツールチェーン効果の交絡である。提案言語には、構造化診断、typed holes、影響テスト選択、safe repair などを標準装備する。一方、既存言語側に formatter、type checker、language server、test runner、パッケージ管理機構を十分に与えない場合、提案言語の優位は言語設計ではなく専用ツールの優位を測っただけになる。逆に、既存言語に成熟した IDE 支援を与え、提案言語のプロトタイプ実装が未成熟であれば、提案言語は過小評価される。評価では、素朴ベースライン、実務的ベースライン、提案言語のアブレーションを分け、許可されたツールとバージョンを記録する必要がある。
外的妥当性とは、結果を他の状況へ一般化できるかに関する妥当性である。第一の脅威は、小規模タスクの結果が大規模開発に一般化できるとは限らない点である。小規模タスクでは、短い構文、設定の少なさ、基本的な入出力処理の書きやすさが主要な要因になりやすい。一方、大規模開発では、互換性、移行、テスト時間、レビュー体制、セキュリティ、運用上の制約が支配的になる。
第二の脅威は、オープンソースソフトウェア的なタスクと業務システムの差である。公開ベンチマークでは、仕様が短く、テストが明確で、依存が限定されていることが多い。業務システムでは、暗黙知、未文書の制約、過去の移行、規制、組織内 API が存在する。提案言語のモジュール文書モデルはこの問題に対処しようとするが、実際の組織で維持されるかは別途検証が必要である。
第三の脅威は、特定のエージェント実装への依存である。あるエージェントが veln graph や JSON diagnostics をうまく使えるとしても、別のエージェントが同じ情報を有効に使えるとは限らない。評価では、単一のエージェントだけでなく、複数のエージェント実装または複数のプロンプト戦略で検証する必要がある。
構成概念妥当性とは、測定指標が本当に測りたい概念を表しているかに関する妥当性である。本レポートでは「高速生成」を重視するが、これを時間だけで測ると、品質、保守性、レビュー負荷を見落とす。短時間でテストを通したコードが、契約を弱め、エラー処理を省略し、将来の修正を難しくしている場合、それを高速生成の成功と呼ぶべきではない。
同様に、「成功」をテスト通過だけで測ることにも危険がある。テストは仕様の一部を表すが、仕様全体ではない。セキュリティ、性能、可読性、拡張性、ドキュメントの正確性は、単純なテスト成功率では測れない。したがって、評価には human review time、Regression rate、Diagnostic usefulness、doc drift、契約維持率を含める必要がある。
また、トークン数の解釈にも注意が必要である。生成トークン数が少ないことは費用面で有利だが、暗黙の仕様が増えれば、入力文脈や修正トークンが増える可能性がある。評価では、初回生成だけでなく、タスク完了までの総トークン数を測るべきである。
さらに、Diagnostic usefulness や Context size は、言語機能だけでなくツール出力の品質を測っている可能性がある。構造化診断が優れている条件で Context size が小さくなったとしても、それは表層構文の簡潔性ではなく、language server や依存解析の性能を反映しているかもしれない。したがって、評価結果の解釈では、言語構文、型・契約設計、ツール出力、エージェント戦略を分けて報告する必要がある。
統計的妥当性とは、得られた結果が偶然ではなく信頼できるかに関する妥当性である。LLM の出力は確率的であり、同じ条件でも成功と失敗が分かれる。試行回数が少ない場合、平均値や順位は安定しない。評価では、複数回試行し、平均だけでなく中央値、分散、失敗率、外れ値を報告する必要がある。
モデル更新も再現性を脅かす。API として提供される LLM は、同じモデル名でも内部更新される可能性がある。評価時には、モデル名、バージョン、実行日、温度、最大トークン数、ツール使用条件を記録する必要がある。また、API latency、キャッシュ、ネットワーク状態、依存パッケージの取得時間も Time-to-green に影響するため、可能な範囲で分離または記録すべきである。
以上の脅威は、本レポートの提案を無効にするものではない。しかし、AI エージェント向け言語設計の評価には、多面的な測定と慎重な解釈が必要であることを示している。
本章では、提案言語を実用的な設計へ発展させるための未解決課題を整理する。本レポートは、AI エージェントに適した高速生成可能プログラミング言語の設計原理を提示したが、実装、評価、既存言語への導入には多くの課題が残る。
第一の課題は、typed holes と LLM completion の統合である。typed holes は、期待型、利用可能な変数、候補関数、周辺文脈を返せる。Blinn らは、Hazel の typed holes と言語サーバを LLM 補完へ接続し、ChatLSP として Language Server Protocol 拡張の方向を示している（Blinn et al. 2024）。本レポートの提案では、さらに関連契約や関連テストを結び付ける。しかし、それらをどの形式で LLM に渡すと最も効果的かは自明ではない。自然文プロンプトとして渡す方法、JSON として渡す方法、language server の補完候補として渡す方法を比較する必要がある。また、穴を埋める順序を、依存関係やテスト失敗に基づいて自動選択する方法も課題である。
第二の課題は、contract から property test を自動生成する方法である。契約は関数が満たすべき条件を表すため、テスト生成の入力として利用できる。たとえば、port in 1..65535 という契約から、有効範囲内外の入力を生成できる。しかし、任意の契約から有用な property test を作るには、入力生成、境界値選択、前提条件の扱い、失敗例の縮小が必要になる。
第三の課題は、doc comment、doctest、contract の重複排除である。仕様をコード近傍に置くことは重要であるが、同じ条件を自然文、契約、例に重複して書くと、保守負荷が増える。どの情報を契約から生成し、どの情報を人間が自然文で書くべきかを整理する必要がある。特に、設計意図や背景は自然文でなければ表現しにくく、入出力条件は契約や schema に向いている。
第四の課題は、effect system の実用的な粒度である。副作用を細かく分類すれば、AI エージェントは安全にリファクタリングしやすくなる。一方、分類が細かすぎると、注釈負荷が増え、初回生成の摩擦になる。fs、net、db、time、random、process のような粗い分類から始め、必要に応じて read と write、transaction、external service などへ拡張する段階的設計が必要である。
第五の課題は、AI 向け Language Server Protocol 拡張である。既存の Language Server Protocol は、エディタや統合開発環境と言語サーバの通信を標準化する仕様であり、補完、定義ジャンプ、診断などを扱う（Microsoft n.d.）。AI エージェント向けには、typed hole completion、affected test selection、contract explanation、dependency graph query、safe repair、doc drift detection を標準化する必要がある。この方向は ChatLSP や Lanser-CLI のような近接研究と接続するが、本レポートでは、契約、関連テスト、doc drift、package metadata を一つの言語設計原理として統合する点を今後の課題とする（Blinn et al. 2024; Zhang and Lanser Contributors 2025）。この拡張は、提案言語だけでなく、既存言語のエージェント支援にも応用できる。
第六の課題は、dependency graph に基づく context selection である。AI エージェントの入力文脈には上限があるため、どのファイル、どの関数、どの契約、どのテストを渡すかが性能を左右する。依存グラフ、呼び出しグラフ、effect graph、最近の変更履歴、失敗テストを組み合わせ、過不足の少ない文脈を選択する方法を研究する必要がある。
第七の課題は、agent-readable package metadata である。パッケージの公開 API、バージョン互換性、非推奨 API、典型的な使用例、副作用、セキュリティ上の注意が機械可読であれば、AI エージェントは外部ライブラリをより安全に利用できる。既存エコシステムにも機械可読メタデータは存在する。たとえば npm の package.json は入口、実行ファイル、リポジトリ、依存関係などを扱い、PyPA Core Metadata は依存、対応 Python バージョン、Project-URL、Import-Name などを扱い、Cargo manifest は README、repository、license、features、targets などを扱う（npm Docs n.d.; Python Packaging Authority n.d.; The Cargo Book n.d.）。したがって課題は、既存メタデータが存在しないことではない。公開 API の意味、非推奨 API、典型的使用例、副作用、セキュリティ上の注意が、エコシステムごとに README、型定義、ドキュメント、manifest、脆弱性情報へ分散しがちな点を、エージェントが利用しやすい形へ統合することである。
第八の課題は、セキュリティ境界の言語レベル表現である。AI エージェントが生成するコードでは、入力検証、権限、秘密情報、ログ出力、外部コマンド実行、ネットワークアクセスの扱いが重要になる。型と契約だけでなく、秘密値の伝播、権限境界、危険な副作用を言語レベルで表現し、診断できる仕組みが必要である。
第九の課題は、自動リファクタリングと contract preservation である。contract preservation とは、リファクタリング前後で契約が維持されることを指す。AI エージェントが関数抽出、名前変更、モジュール分割、エラー型の整理を行う場合、契約、doctest、影響テストが正しく移動または更新されなければならない。safe repair API と構造化診断を、より大きなリファクタリングへ拡張する必要がある。
第十の課題は、既存言語へのバックポート可能性である。提案言語を新しく実装するだけでなく、既存言語のエコシステムへ部分的に導入する方法を検討すべきである。Ruby では gem、Python では package、TypeScript では transformer または language server plugin、Elixir では Mix plugin、D では compiler extension として、typed holes、構造化診断、contract、doctest、dependency graph の一部を試験的に導入できる可能性がある。
最後に、実証評価が必要である。第12章で述べた評価方法に基づき、実際のプロトタイプ処理系と標準ツールチェーンを用いて、複数の AI エージェント、複数のタスク、複数の既存言語と比較する必要がある。特に、Time-to-green、Cost-to-green、Context size、Human review time がどの程度改善されるかを測定しなければ、本レポートの提案は設計仮説にとどまる。
以上の課題は広範であるが、いずれも同じ方向を向いている。すなわち、AI エージェントの能力を単にモデル側で高めるのではなく、言語、ツール、文書、診断、評価方法を、エージェントと人間が共同で扱える形に再設計することである。
本レポートは、AI エージェントに適した高速生成可能プログラミング言語の設計を検討した。中心的な主張は、「AI が高速に生成できる言語」を、単に動的型付けで短く書ける言語として理解すべきではないという点にある。AI コーディングエージェントの実効的な生成速度は、初回出力のトークン数だけでなく、生成されたコードを実行し、失敗を観測し、診断を解釈し、影響範囲を限定し、最小限の修正でテストを通過させるまでの総合的なループによって決まる。
小規模なコード生成課題では、Ruby、Python、JavaScript のような言語が持つ簡潔な構文、低いセットアップ摩擦、慣用句の明確さ、AI の学習データ上の馴染みが有利に働く可能性がある。Endoh が2026年3月5日の記事で報告したベンチマークは、この点を示唆する事例である（Endoh 2026a; Wiggers 2026）。しかし、その結果は外部ライブラリ依存を避けた小規模課題に関するものであり、大規模なソフトウェア開発へそのまま一般化できない。暗黙の依存、実行時まで検出されない型不整合、テスト範囲の不明瞭さ、ドキュメントと実装の乖離は、エージェントの探索空間と修正コストを増大させる。したがって、短さは重要な要素ではあるが、それだけでは十分でない。
本レポートでは、この問題に対し、AI エージェントにとっての作業面積を最小化するという設計原理を提示した。作業面積を小さくするためには、表層構文の意味密度を高めるだけでなく、公開 API、外部 I/O、永続化、安全性境界において局所的な静的検査を強めることが有力な設計仮説となる。また、契約、doctest、組み込みテスト、実行可能な例をコード近傍に配置することで、仕様と検証を分離しすぎない構造が必要である。D 言語の contract および unittest、Elixir の ExUnit.DocTest と Mix は、この方向を考えるうえで参考になる既存事例である。
さらに、typed holes と構造化診断は、AI エージェント向け言語における重要なインターフェースである。typed holes は、未完成コードを破損状態ではなく、期待型、利用可能な値、補完候補を持つ作業状態として扱うことを可能にする。本レポートでは、これを契約、依存グラフ、回帰テスト選択と統合し、関連しうるテストや優先実行すべき影響テストを返す設計へ拡張した。ただし、この情報は失敗原因を常に自動分類するものではなく、保守的な影響範囲とその根拠を返すものとして扱う。構造化診断は、エラーメッセージを人間向けの自然文に閉じず、ファイル位置、抽象構文木上の範囲、期待値、実際の値、関連 contract、修正候補、影響テストなどを機械可読に返す。これにより、エージェントは失敗原因の推測に費やす文脈量を減らし、次の修正行動を選びやすくなる。
この設計は、人間向けの可読性と AI 向けの操作容易性を対立させるものではない。むしろ、両者は多くの部分で一致する。標準スタイルが明確であること、モジュール境界が安定していること、副作用が追跡可能であること、エラーが局所的に説明されること、実行可能な例が近くに置かれていることは、人間の理解負荷を下げると同時に、AI エージェントの探索負荷も下げる。ただし、AI エージェントには、人間向け表示に加えて JSON 形式の診断、依存グラフ、影響テスト選択、自動適用を前提としない safe repair 候補などの機械可読な補助情報が必要である。
以上を踏まえると、AI エージェントに適した言語の中心原理は、次の四点に要約できる。第一に、短く書けることである。第二に、局所的に検証できることである。第三に、失敗から修正までの距離が短いことである。第四に、人間と AI が同じコードを読めることである。これらの原理は、単一の構文機能によって達成されるものではなく、言語仕様、標準ライブラリ、ツールチェーン、診断形式、テスト文化、モジュール文書モデルの組み合わせとして、実装と評価により検証されるべき仮説である。
本レポートの提案は、既存言語を全面的に置き換えることを目的としない。また、すべてのバグを型システムで防ぐことや、人間の設計判断を不要にすることも目的としない。むしろ、AI エージェントが実際に行っている生成・実行・失敗・修正の循環を言語設計の中心に置き、偶有的な摩擦を減らすことを目的とする。今後は、typed holes と LLM 補完の統合、契約から性質ベースのテストである property test を生成する方法、実用的な effect system の粒度、エディタや開発環境が言語機能を利用するための通信仕様である Language Server Protocol の AI 向け拡張、依存グラフに基づく文脈選択、既存言語への段階的な導入可能性を、実装と評価を通じて検証する必要がある。
結論として、AI エージェント時代のプログラミング言語設計において重要なのは、動的か静的か、簡潔か厳密かという二分法ではない。重要なのは、短い表現、局所的な検証、明示された境界、実行可能な仕様、機械可読な診断を統合し、エージェントと人間が同じプログラムを共同で発展させられる環境を作ることである。そのような言語は、AI だけのための言語ではなく、人間の理解可能性を保ちながら、AI エージェントの生成と修正を加速する言語である。
アクセス日は、項目内に個別記載がない限り2026年5月22日である。ウェブ記事の公開日・更新日は、公開ページで確認できる範囲を記す。
7f6ffdc8c61a3ec7b7f2a64301a6f47d1eaceeb5。本文のベンチマーク解釈は2026年3月5日の記事説明に基づく。URL: https://github.com/mame/ai-coding-lang-bench/tree/7f6ffdc8c61a3ec7b7f2a64301a6f47d1eaceeb5。7f6ffdc8c61a3ec7b7f2a64301a6f47d1eaceeb5 では v2 に status, diff, checkout, reset, rm, show が含まれる。URL: https://github.com/mame/ai-coding-lang-bench/blob/7f6ffdc8c61a3ec7b7f2a64301a6f47d1eaceeb5/SPEC-v2.txt。traverse, sequenceA, mapM, sequence の型と短絡例を2026年5月23日確認。URL: https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-Traversable.html.? の短絡先を2026年5月23日確認。URL: https://doc.rust-lang.org/stable/reference/expressions/operator-expr.html#the-question-mark-operator.Result の FromIterator による collect の挙動を2026年5月23日確認。URL: https://doc.rust-lang.org/core/result/#collecting-into-result.