コトリンの創始者による新しい言語：英語の代わりにLLMと対話するための正式な方法

2026年3月12日原文(codespeak.dev)

概要

CodeSpeak は、 LLM を活用した次世代型プログラミング言語。コードベースを 5～10倍小型化 し、保守性を向上。手動コードと仕様書生成コードの 混在プロジェクト に対応。実際のオープンソースプロジェクトでの 導入事例 を紹介。 テスト通過率 や縮小効果も具体的に提示。

CodeSpeakの特徴

LLM（大規模言語モデル） を活用した新しいプログラミング言語
Alpha Preview 段階で、uvツールを用いた codespeak-cli のインストールが可能
本番環境 や 長期プロジェクト にも対応
複雑なソフトウェア開発 に従事するエンジニア向け
プロトタイプ開発 だけでなく、実運用を前提とした設計
チーム開発 を重視し、 コミュニケーションの重要性 を強調
ソロ開発者 だけでなく、 複数人のチーム での利用を想定

混在プロジェクトでの運用

手動で記述したコード と 仕様書から自動生成したコード の共存が可能
MarkItDownリポジトリ（forked）での 具体例 を紹介
混在プロジェクトのステップバイステップガイド も提供

コードから仕様書への変換（今後実装予定）

既存コードの一部を CodeSpeak仕様書 に置き換え可能
仕様書は 5～10倍小型化 され、 保守性向上 に寄与
人間による仕様書の維持管理 がより容易に

実際の導入事例

オープンソースプロジェクト の実コードを元に仕様書を生成し、効果を検証
- WebVTT字幕対応（yt-dlp用）
  - コード: 255行 → 仕様書: 38行（6.7倍縮小）
  - テスト: 1278/1279通過（37件追加）
- Faker用イタリアSSNジェネレータ
  - コード: 165行 → 仕様書: 21行（7.9倍縮小）
  - テスト: 2229/2229通過（13件追加）
  - （イタリア市町村コードリスト約8000行は除外）
- BeautifulSoup4のエンコーディング自動検出・正規化
  - コード: 826行 → 仕様書: 141行（5.9倍縮小）
  - テスト: 914/914通過（25件追加）
- EML→Markdown変換（markitdown用）
  - コード: 139行 → 仕様書: 14行（9.9倍縮小）
  - テスト: 192/192通過（27件追加）
- LOC（行数）は空行を除外し、長い行は分割してカウント

CodeSpeakの今後

コードから仕様書への自動変換機能 のリリース予定
保守性・拡張性の高いソフトウェア開発 を目指す開発チーム向け
仕様書中心の開発 による効率化と品質向上

CodeSpeak は、 人間本位のソフトウェア開発 を実現するために設計された、 次世代プログラミング言語。 複雑なチーム開発 や 長期的な保守 を視野に入れたプロジェクトで、 コードの小型化と可読性向上 を実現。

Hackerたちの意見

黒背景に白文字は読みにくいんだよね。なんか、年取ってきたせいか、目が痛くなるし、ちょっと見ただけでも目が慣れるのに数秒かかる。若い子たちがダークモード好きなのは分かるけど、暗いウェブページを読むときはリーダーモードを使わないと、内容が全然読めない。残念ながら、このサイトは白背景に切り替える方法が分かりにくくて、HTMLソース（CTRL+U）を見るしかない時もあるんだよね。

└

明るい部屋にいるの？今、夜だから、あなたのコメントはこんな感じで見えるよ：https://i.imgur.com/c7fmBns.png。でも、昼間の明るい部屋では、明るいテーマや背景色で全部見えるから、そうじゃないと本当に見づらいよね。

└

同じだよ、私もずっとそうだった。いつも文句言ってる。黒地に白文字の方が、白地に黒文字よりもずっと読みやすくて目にも優しいってよく言われてるのに、開発者たちの中にはみんなにそれを強要する世代がいるみたい。NetflixやPrimeみたいなメディアサイトもそうだし。少なくともTubiはちょっと読みやすいかな。時々、サイトにライトテーマを選ぶボタンやUI要素があるけど、技術的に優れた人たちがデザインしたと思われる多くのサイトが、アクセシビリティの問題を完全に無視してるのが不思議だよ。

└

その気持ちわかるよ。私の場合は逆で、明るい背景だと頭痛がするんだ。光に敏感だからね。

└

うん、私も同じだよ。ダークモードが最近すごく人気だから、少数派だね。目が物理的に痛いっていうのを説明するのが本当に難しい。変な感じだよね。

これ、あんまり意味が分からないな。* これは言語じゃなくて、仕様をコードにマッピングして再生成するためのツールだよ。* モデルは決定論的じゃないから、再適用するたびに違う出力が出る可能性が高いし（現在のコードを再適用に入れない限り、変更を提案するだけになる）。* モデルは急速に進化してるから、今月のCodex/Sonnetなどは先月とは違うコードを生成する可能性が高い。* テキストの仕様は常に不十分で、重要な詳細が省略されがちだから、小さな例では問題ないけど、大きなコードベースでは厳しい。* どんな非自明なコードベースも、相互作用する何百もの仕様から成り立ってるから、機能に影響を与えるすべての仕様を読み解くのはとても難しい。この分野にはチャンスがあると思うけど、私が見たいのは、* テキスト仕様を書くこと、* モデルがテキストを正式な仕様に変換すること、* その後、正式な仕様がコードに翻訳されて、仕様と照らし合わせて検証できること。2と3は、ADA/Sparkのように検証をサポートする実用的で人気のある言語があれば一つにまとめられるかも。でも、正式な仕様から生成されたテストで実装を検証することでも実現できるよ。

└

私のプロセスは、似たようなものに自然に進化してきたけど、あまり厳密には定義されてないかな。 - AGENTS.mdを自分の基本的な作業方法で立ち上げて、時々プロジェクト特有のものを一つ二つ追加する。 - それからDESIGN.mdを書く。どれだけ詳細かはプロジェクトによって異なるけど、先日、フリーランスのビジネス用に時間追跡、請求管理、会計システムのための非常に詳細なDESIGN.mdを書いたんだ。かなり完成度が高かったから、エージェントがほぼ一発で全部やってくれた。 - さらに、何らかのTECHNICAL-SPEC.mdも書くことが多い。これも詳細はプロジェクトによる。 - 最後に、AGENTSからその二つにリンクを貼る。エージェントには、ドキュメントを維持して、新しい決定と同期させるように指示することが多い。このシステムは私にはうまく機能してるけど、まだまだアドホックで、正式に定義された仕様基準には従ってないと思う。実際、そうあるべきじゃないと思う。私の意見では、技術的に厳密な仕様は設計ドキュメントではなく、自動化されたテストに入れるべきだよ。

└

あなたの反論はポイントを外してると思う。私のプログラムに対する非公式な仕様はユーザー中心なんだ。プログラムが使用者にどんな利益をもたらすかを示したいし、輸送層の要件やユーザーインタラクションの哲学、その他いろいろなことが含まれるかもしれない。プログラムから何を得たいかが分かっているときは、それをデータベーススキーマやメニューオプション、特定の暗号化スキームなどに翻訳する苦痛を経て、最終的にはアンダースコアやダッシュをどこで使うかが文書全体で一貫性を持たなければならない正式な仕様に変換する。あなたは、LLMがルーチン部分（プログラムの説明を正式な説明に変換する）をやるために、私が苦痛を伴う部分をやるべきだと言っている。あなたが「意味がない」と言っていることは、まさに私がLLMにやってほしいことなんだ。私は同じ仕様を再実行して、LLMが私が全く予想していなかった機能を追加したり（前回の同じ仕様から実行したときにはなかった機能）、技術の変化や新しい標準/ベンダーの利用可能性に基づいてユーザーの目標を達成するための戦略を変更するのを見たい。私は、プログラムの特定の機能を説明することから離れて、存在しないプログラムの有用性や便利さを説明する仕様を見たい。私は、LLMにプログラムが達成すべき要件を与えて、どうやって実現するかを調査させたい。制約だけを説明したい、つまり、A、B、Cができるようにしなければならないし、X、Y、Zを防がなければならない。私は、それらの制約を自分の好きなように解決してほしいし、出力に満足できなかったら、さらに制約を与えて再生成をお願いしたい。

└

モデルは決定論的じゃないんだよね。再適用しようとすると、毎回違う出力が出る可能性が高いし（今のコードを再適用に入れずに、ただ変更を提案させるだけだと）。結果が常に証明可能に正しいなら、コードレベルで違ってても関係ないんだ。こういうシステムに興味がある人たちは、コード自体よりも、コードが何をするかの結果の方が無限に重要だと思ってる。

└

モデルは決定論的じゃないって、本当にそうなの？数年前に最初のLlamaモデルが出た時から自分で推論を試してないけど、確か決定論的だったと思う。シードを固定して、入力が同じなら、推論の出力はいつも全く同じだったから。

└

モデルは決定論的じゃない - 再適用しようとすると、毎回違う出力が出る可能性が高いってことは、2人の異なるプログラマーに同じ仕様を渡すようなもんだね。

└

あなたの2ステッププロセスは、上で挙げたのと全く同じ落とし穴にハマらないってどういうこと？

Hacker Newsで議論の続きを見る

ハクソク