本文へ
ハクソク

世界を動かす技術を、日本語で。

十分に詳細な仕様はコードである

元記事: 原文(haskellforall.com)

概要

  • 仕様書からのコード自動生成 に対する誤解と現実を解説
  • OpenAI Symphonyプロジェクト を具体例に批判
  • 仕様書とコードの 複雑性・労力の本質 を整理
  • コード生成の 信頼性・実用性の課題 を指摘
  • 仕様書作成とコーディングの 本質的な難しさ を再考

仕様書駆動のコード生成に対する誤解と現実

  • agentic coding （エージェント型コーディング）推進派は、仕様書から直接コード生成が可能だと主張

  • しかし、実際にはこの主張には 2つの誤解 が根底に存在

    • 誤解1 ：仕様書は対応するコードよりも 単純 である
    • 誤解2 ：仕様書執筆はコーディングよりも 深い思考 を要する

  • 仕様書を「外注の次世代」として扱い、エンジニアが仕様書を書きエージェントに実装を任せる発想

  • 仕様書経由で品質が向上するという幻想

Symphonyプロジェクトの実態と課題

  • OpenAI Symphony は、「仕様書（SPEC.md）からプロジェクト生成可能」と宣伝

  • しかし、このSPEC.mdは 実質的に擬似コードやコード断片 をMarkdownに書き起こしただけの内容

  • 例：データベーススキーマやアルゴリズムの詳細な記述、コードそのものを含む

  • 仕様書と呼べるものの、 実質はコードに極めて近い ものになっている事実

    • 仕様書が十分に厳密であればあるほど、 コードに近づく必然
    • Dijkstraの「狭いインターフェース」の議論を引用し、 形式的記述の限界 を指摘

  • SymphonyのREADME通り、仕様書から実装（例：Haskellでの実装）を試みても バグや動作不良が多発

  • 仕様書が長大化すれば、 Borgesの「正確さについて」 の寓話のように、地図と現実が一致して無意味化

仕様書作成とコーディングの本質的な難しさ

  • 仕様書作成は本来、 コーディング以上に困難 であるべき作業

  • 仕様書作成の目的は、 全体像を俯瞰し批判的思考を促す ため

  • しかし、「仕様書作成はコーディングよりも容易」と考える産業的風潮により、 本質的な思考が省略 されがち

  • SymphonyのSPEC.mdのように、 AI生成の粗雑な仕様書 が生まれる背景

    • 例：Section 10.5のような中途半端な仕様記述

  • 結果として、仕様書とコードの 境界が曖昧化 し、どちらの品質も保証できない状況に陥る

まとめ

  • 仕様書からのコード自動生成は、 仕様書自体が実質的なコード化 を要求
  • 仕様書の厳密さ・詳細さを高めると、 人間がコードを書くのと同等の労力 を要する
  • 仕様書作成やコード生成の 信頼性・品質の限界 を認識し、安易な自動化幻想を持たない姿勢が重要

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

人々が自分たちのより技術的な英語の方言（LLMSpeakとか）を作り始めて、モデルのパフォーマンスやトークンの使用を最適化しようとするのは、時間の問題だと思うよ。非常に圧縮された語彙を使うことで、あいまいさやトークンの使用を減らせるし、非常に具体的な概念が一つの単語に詰め込まれる感じ（モナドはエンドファンクターのカテゴリにおけるモノイドに過ぎない、何が問題なの？）。文法的には、あいまいさを減らすためにオックスフォード・カンマみたいなものが出てくるだろうし、エージェントとのやり取りでの確認作業も減るはず。初心者は同じ概念を不器用に100倍のトークンを使って表現し続けるだろうけど、彼らはプロンプトの精度が足りないからね。LLMの生産性を最大化したい人は、このあいまいさのない、情報密度の高い方言で話し始めるだろうし、それがトークンの使用やLLMのコストを最適化することになるんだ。

└

あいまいさのない言語を使おうよ。Lojbanを提案してもいいかな？ [1] https://en.wikipedia.org/wiki/Lojban [2] 誰かが話してる動画: https://www.youtube.com/watch?v=lxQjwbUiM9w

└

自分たちのより技術的な英語の方言を作ることで ああ、リスプの呪いだね。また始まった。偶然にも、80年代のAIバブルが崩壊したのは、リスプの方言が互換性がなかったからでもある。

└

トークンの使用やLLMのコストを最適化する 文脈の汚染がもっと大きな問題だよ。例えば、あのSKILL.mdファイルみたいに、何十キロバイトもあるようなもの。無駄に冗長で長ったらしいから、LLMが賢くなるわけじゃないからね。（賢くならないし、ただ無関係なもので文脈が薄まるだけ。）

└

自分のモデルをトレーニングしていない限り、この方言を常に文脈に送らなきゃいけないんじゃない？モデルはインターネット上の人間の言語テキストでトレーニングされてるから、君の専門的なものじゃないし。結局、人間の言語を使って定義する必要があるってことだよね？それを定義したら、あいまいさを減らすことはできるかもしれないけど、その仕様を持ち歩く必要があるみたいだね。

└

Codexにはすでにそんな言語があるよ。私のために書いてくれた仕様には「dedupe」や「catch-up」が満載で、もっと冗長な言葉を使うようにフィードバックすることが多いんだ。そういうのが私の言葉遣いにも少しずつ入ってきてる。私の同僚が突然「今日」という言葉をいつも使うようになったけど、彼がClaudeをよく使ってるからだと思う。今日、つまり、コードの現在の状態のことね。

└

今日、hnのどこかで言及されてたけど、なんでトークンの使用が気になるの？私は日夜AIにコーディングや他のことをプロンプトしてるけど、Claude Code Max 200やMistralを使ってて、何ヶ月も問題がないよ。

└

それにしても、LLMはこの方言でトレーニングされる必要があるんじゃない？もしトレーニング素材がほとんど曖昧だったら、どうやってそれを明確にしてトレーニングするの？私の中では、これは異なる問題を解決することだと思ってる。私たちは、曖昧な意味から意図を読み取ってほしいんだ。だって、それが人間の考え方や話し方だから。自分がそう思ってない人は、自分を理解してないだけだよ。もしLLMのために簡潔で明確な言語を作ったら、彼らは人間とじゃなくて、お互いに使うことで一番利益を得るんじゃないかな。さらに、彼らはすでにプログラミング言語を使って、コンピュータとやり取りするための簡潔で明確な表現をしているよね。これをどうやって意味のある形で改善するのか、十分なトレーニングデータがあっても難しいと思う。これは本当に真剣に聞いてるから、私が理解しているわけでもないし、もっと知っているわけでもないから。

十分に詳細な仕様はコードだ これはまさにブルックスの「ノー・シルバー・バレット」の主張だね。今でもその考えは変わらないけど、多くの人がそんなに詳細な情報を必要としていないのが現実だと思う。AIに「To-Doリストアプリを書いて」とプロンプトを出すとき、実際には「今まで考えた中で一番いいTo-Doリストアプリを書いて」という意味なんだよね。だから、詳細な仕様は本当に必要ない。

└

でも、もしそのタスク管理アプリを売るつもりなら、ルールは違ってくるし、その仕様書は必要だね。お金を稼ぎたいのか、他と競争したいのかによると思う。

└

AIに「タスク管理アプリを作って」と頼むとき、実際には「今まで考えた中で一番いいタスク管理アプリを作って」という意味なんだよね。だから、詳細な仕様は必要ない。もし誰かが真剣にタスク管理アプリを作ってほしいと頼んでいるなら、既存の数多くのアプリとは違うことをしたいと思っているはず。それを説明する必要があるけど、それが可能かどうかは分からない。

└

そうだね。これは、トレーニングデータに無数の最先端「タスク管理」アプリが含まれているから起こる現象だ。この議論は他の種類のソフトウェアにはうまく当てはまらないよ。

Hacker Newsで議論の続きを見る

同じ出典の記事