ChatGPT Projectsだけでプログラミング言語を開発する——2週間で見えたAI駆動開発の可能性と限界

「プログラミング言語を作る」——それは多くの開発者にとって憧れであり、同時に膨大な労力を要する挑戦です。黒ヰ樹氏が開発する「Ane」は、その開発プロセス自体が注目に値します。なぜなら、ChatGPT Plusの「Projects」機能だけを作業場として、コンパイラから仕様書、テストケースまでをAIと共同で育てているからです。

2週間という短期間でジェネリクス、型エイリアス、レコード、enumといった本格的な言語機能を実装したという報告は、AI支援開発の現在地を示す重要なケーススタディと言えます。この開発スタイルは、従来の言語開発の常識を覆す可能性を秘めています。

黒ヰ樹氏の開発手法には、いくつかの特徴的な要素があります。

ChatGPT Projectsを中心とした開発環境

ChatGPT Projectsは、コンテキストを保持しながら継続的な対話ができる機能です。この環境を「唯一の作業場」として選択したことには戦略的な意味があります。従来なら、IDE、ドキュメントエディタ、テストフレームワークなど複数のツールを行き来する必要がありましたが、ChatGPTとの対話だけで以下を同時進行させています。

これらを「一緒に育てる」というアプローチは、AIとの対話を通じて仕様とコードが相互に影響し合いながら進化していくプロセスを意味しています。

2週間で到達した言語機能

最も注目すべき追加機能はジェネリクスです。ジェネリクスは型安全性を保ちながらコードの再利用性を高める現代的な言語機能で、設計と実装の両面で高い複雑性を持ちます。それに加えて型エイリアス、レコード、enumといった構造化プログラミングに不可欠な要素も実装されました。

これは単なるトイ言語ではなく、実用性を意識した言語設計が進行していることを示しています。

従来の言語開発との比較

伝統的なプログラミング言語開発は、数年単位のプロジェクトです。例えば、Rustの初期開発は2006年に始まり、安定版リリースは2015年でした。Kotlinも同様に、初期開発から1.0リリースまで5年以上を要しています。

対照的に、Aneプロジェクトは2週間でブートストラップに必要な基本機能群を実装しました。この差は単なるスピードの問題ではありません。**AIが言語設計における「壁打ち相手」として機能し、設計上の矛盾や実装の困難さを即座にフィードバックしている**点が本質的な違いです。

従来の開発では、仕様書を書き、実装し、テストして初めて問題が発見されるという線形プロセスでした。しかしChatGPTとの対話では、「この仕様でジェネリクスを実装するとどうなるか」という探索的な議論が可能です。設計判断のサイクルが劇的に短縮されているのです。

このアプローチのメリット

1. **思考の外部化と整理**: 言語仕様をAIに説明する過程で、設計者自身の考えが明確化されます。曖昧だった部分が対話を通じて具体化されるのです。

2. **実装の即時検証**: 「こういう構文はどうか」というアイデアを、すぐにコードとして試せます。プロトタイピングのスピードが桁違いに向上します。

3. **ドキュメント駆動開発の自然な実現**: ChatGPTとの対話そのものがドキュメントになります。仕様、実装、テストが一貫したコンテキストで管理されます。

4. **一人開発の孤独からの解放**: 言語開発は通常チームで行われますが、一人での開発は孤独で、設計判断のフィードバックが得られません。AIが擬似的なペアプログラミング相手となります。

注意すべき課題と限界

一方で、このアプローチには構造的な課題も存在します。

1. **AIの提案の一貫性**: ChatGPTは文脈を理解しますが、長期的なアーキテクチャの一貫性を完全には保証しません。設計の方向性を決める「軸」は人間が保持する必要があります。

2. **複雑性の管理**: プロジェクトが成長すると、Projects内の会話履歴だけでは管理しきれなくなります。どこかの時点で従来のバージョン管理システムやドキュメント体系への移行が必要です。

3. **検証の責任**: AIが生成したコードやテストは、最終的に人間が検証する必要があります。特に言語のセマンティクスに関わる部分は、AIの「もっともらしい誤り」に気づく専門性が求められます。

4. **再現性とバージョン管理**: ChatGPTとの対話は本質的に一回性があります。同じ質問をしても異なる回答が返ることがあり、厳密な再現性が求められる場合は課題となります。

適用範囲の考察

この開発スタイルが特に効果を発揮するのは、以下のようなケースです。

逆に、Rust級の大規模言語や、形式的検証が必要なミッションクリティカルな言語では、AI支援は補助的な役割にとどめるべきです。

1. ChatGPT Projectsで小さなDSLを作ってみる

まずは野心的な汎用言語ではなく、JSONの代替や設定ファイル用の小さなDSLから始めましょう。

プロンプト例:
「設定ファイル用の簡潔な言語を設計したいです。
YAMLよりシンプルで、JSONより読みやすいものを目指しています。
まず基本的な構文案を3つ提案してください。」

ChatGPTとの対話で構文を決め、パーサーの実装をPythonで進めます。1日あれば動くものができるはずです。

2. 仕様とコードを同時進行で育てる習慣を作る

言語開発に限らず、「仕様を書いてからコード」という線形プロセスを見直しましょう。ChatGPTに「この仕様だと実装でどんな問題が起きるか」と問いかけながら、仕様と実装を往復させます。

具体的には、Projects内で以下の構造を維持します。

これらを常に同じコンテキストで更新し続けることで、Aneプロジェクトのような開発サイクルが実現できます。

3. AI生成コードの検証フレームワークを構築する

AIが生成したコンパイラコードやテストは、必ず検証が必要です。黒ヰ樹氏が「検査スクリプト」を一緒に育てているのは、この課題への実践的な回答です。

以下のような検証チェックリストを作りましょう。

これらをChatGPTに定期的に確認させることで、品質を保ちながら開発速度を維持できます。

Aneプロジェクトは、AIがプログラミング言語開発という高度に専門的な領域でも実用的なパートナーになれることを示しています。ChatGPT Projectsという一つの環境だけで、2週間でジェネリクスを含む本格的な言語機能を実装したという事実は、従来の開発プロセスの再考を迫ります。

重要なのは、AIが人間を置き換えるのではなく、**設計判断のサイクルを圧縮し、探索空間を広げるツール**として機能している点です。言語設計の本質的な判断は依然として人間が行いますが、その判断を支援する環境が劇的に向上しました。

このアプローチは言語開発だけでなく、フレームワーク設計、API設計、アーキテクチャ検討など、多くの「設計的な活動」に応用できます。黒ヰ樹氏の実験は、2024年以降のソフトウェア開発の一つの方向性を示していると言えるでしょう。

この情報は @黒ヰ樹 さんの投稿を参考にしています。