「コードはメンテナンスするのではなく、再生成すべき」：Codeplainが仕様駆動開発を主張
Codeplainは、コードをメンテナンスするのではなく、仕様から再生成するアプローチを提唱。オープンソースの仕様言語Plainが唯一の真実の情報源となり、新たなエージェンティックフレームワークplain-forgeによりAIエージェントが対話的に仕様をドラフトできる。同社は300万ドルを調達し、仕様こそが保守すべき資産だと主張する。
AIがコードを生成する速度がチームのレビュー能力を上回る中、少数ながら増加しつつある開発者は、答えはコードレビューの高速化ではなく、コードレビューそのものを別のものに置き換えることにあると主張している。CodeplainのCEO兼共同創業者であるDušan Omerčevićは、この考え方を体現する人物だ。2025年初頭にスロベニアのリュブリャナで設立されたCodeplainは、同年9月に静かに「仕様駆動、プロダクション対応のコード生成」を約束してローンチした。
その基盤となるのはPlain、オープンソースの仕様言語であり、構造化された人間が読めるドキュメントを、ソフトウェアの構築と振る舞いに関する唯一の真実の情報源として使用する。アイデアは単純だ：何かが壊れたり変更が必要になった場合、コードではなく仕様を編集し、Codeplainが実装をゼロから再生成する。
Omerčevićはインタビューでさらに踏み込んで語る。AIが生成するコードの量が増大するにつれ、ボトルネックはコードの記述からレビューと保守に移行した。仕様は実装詳細ではなく意図をエンコードするため、コードをレビューするよりもはるかに少ない認知的負荷で済むと彼は言う。「私たちのテーゼは、コードはメンテナンスされるべきではない——コードは再生成されるべきだ、ということです。仕様がレビューされるべきであり、仕様こそがメンテナンスされるものです。」
このミッションを推進するため、同社は新たなオープンソースのエージェンティックスキルフレームワーク「plain-forge」をリリースしている。これにより、Claude Code、Codex、OpenCodeなどのコーディングエージェントが、会話を通じてPlain仕様をドラフトし維持できるようになる——つまり、仕様駆動開発においてこれまで最も人間の労力を必要とした部分を自動化する。同時に、CodeplainはGapMinder VCやSilicon Gardensなどの支援者からこれまでに300万ドルの資金を調達したことも発表した。
仕様駆動開発はCodeplainだけのものではない。2025年7月、AmazonはKiroを発表。これは自然言語プロンプトから生成された構造化仕様を使用して開発を導くエージェンティックIDEだ。GitHubもSpec Kitというオープンソースツールキットを発表し、仕様をAIエージェントが直接行動できる実行可能なアーティファクトにしている。さらに遡ると、SpecLangはGitHub Nextの研究プロジェクトで、2023年から平易な英語が真のプログラミング媒体として機能するかどうかを探求していた。SpecLangの作成者の一人でありGitHub Copilotチームの創設メンバーであるJohan Rosenkildeは、Codeplainの取締役を務め、初期の投資家でもある。
しかし、開発者は仕様を書きたがらない。Omerčevićのチームはユーザーテストを通じて、開発者は仕様を書くことには抵抗するが、読むことには概して前向きであることを発見した。適切に構造化された仕様は、それが最終的に生成するコードよりもレビューと推論が容易なのだ。Plain-forgeはこの緊張関係に対する答えだ。開発者にゼロから仕様を書かせる代わりに、コーディングエージェントに問題を調査させ、段階的に仕様をドラフトさせ、人間が見る前にCodeplainのレンダラーに対して検証させる。重要なのは、最初から何百行もの仕様を提示しないことだ。Omerčevićが公然と批判するアプローチである。
「私たちは開発者に200行の仕様を投げつけたりしません。反復的に行います。」と彼は言う。各小さな仕様が動作するソフトウェアを生成し、開発者は即座に確認して応答できる。これにより、開発者は自分が形作ることに全く関与していない完成されたドキュメントに直面するのではなく、一度に一つの機能ずつ仕様に慣れていく。「このように、徐々に仕様を追加していくことで、開発者は仕様との関係を構築していきます。仕様が真実の情報源であり、AIが自分を理解したというフィードバックになるのです。」
このすべての基盤にあるのは、コードは永続的な資産ではなく使い捨ての出力として扱われるべきであり、仕様——生成されたコードではなく——こそがチームが保存し維持すべきものだという根本的な信念である。Omerčevićはこの結論にCodeplainを構築する自身の経験を通じて至ったが、コードにプロフェッショナルとしてのアイデンティティを築いてきた開発者に説明するのは難しいと感じていた。
ここでChad Fowlerの「フェニックスアーキテクチャ」が登場する。FowlerはベテランエンジニアでありBlueYard Capitalのゼネラルパートナーで、ここ6ヶ月間このアプローチのためのより広範な哲学的枠組みの開発に費やしてきた。2024年12月の初投稿「再生ソフトウェア」では、AIがコードを豊富で安価なものにし、ソフトウェアシステムにおいて何を保存する価値があるかについて数十年にわたる前提を覆したと論じている。既存の実装に固執するチームは、自覚するよりも速く技術的負債を積み上げているという。
2025年3月の投稿「会話がコミットである」では、Fowlerは開発者がAI生成コードを手動で編集すると、コードがなぜ存在するのか、どのような決定がそれを形作ったのかという重要な記録を断ち切ると主張する。出力は変わるが、変更の背後にある推論は失われる。時間とともに、失われたコンテキストの蓄積をFowlerは「来歴債務」（provenance debt）と呼び、ほとんどの開発者がそれに名前を付けずにキャリア全体を通じて蓄積してきたと論じる。
「もし私たちがこの豊かで重要な情報を最終的に捉える方向に進まないなら、ソフトウェア構築の革新の波に対して無責任です。」とFowlerは説明する。別の言い方をすれば、仕様とその背後にある推論が今や保存価値のあるものであり、それらが生み出すコードではない。
この文化的シフトの大きさは過小評価できない。開発者はコードにアイデンティティを築いてきたのだ。では、どのようにしてエンジニアに、削除と再生成が進歩であると納得させるのか？Fowlerには二つの方法がある。一つは待つこと——時間とともに古いやり方が時代遅れになり、進化するか死ぬかを見せる。二つ目は、よりポジティブな方法で、削除と再生成が新しいツールのおかげでのみ可能になる新たな厳密性を定義していることを示すことだ。
Fowlerの見解では、Codeplainはその厳密性を実用的な製品に組み込むための信頼できる試みの一つだが、まだ組み立て中のより大きなパズルの一片に過ぎないと慎重に述べている。
Omerčevićはエンタープライズソフトウェアの構築と出荷に精通している。彼は以前、SaaS管理プラットフォームCleanshelfを創業し、2021年にLeanIXに売却、その後LeanIXはSAPに買収された。Codeplainは彼の次の行動であり、すでに顧客が実用化している。身元確認サービスプロバイダーのIncodeは、Codeplainを使用して外部データプロバイダーとの統合を構築・維持している。この種の作業は、絶え間ないAPI調査、急速に変化する外部システム、予期せぬ破損に対する高い許容度を伴う。
Omerčevićが最も熱く語るのは、何かが壊れるという最後の問題だ。仕様は実装詳細ではなく意図をエンコードするため、外部APIが変更されて統合が壊れた場合でも、Codeplainはまったく同じ仕様からコードを再生成することで修正できることが多い。仕様は壊れず、コードだけが壊れるのだ。「仕様を微調整する必要すらありません。まったく同じ仕様からコードを再生成するだけで、多くの場合、小さな変更が壊れても仕様はそのままですから。」
また、このアプローチには強力な経済的根拠もある。Omerčevićによれば、仕様を生成するコーディングエージェントは、コードを直接生成する場合と比べて5～10分の1のトークンしか使用しない。さらに、仕様はエージェントにとって認知的に負荷が低いため、同じコンテキストウィンドウ内でより大規模で複雑な問題を処理できる。コード生成ステップ自体には、Codeplainはフロンティアモデルではなく、より高速で安価なGemini Flashなどのモデルを使用し、コストを抑えている。
彼がたとえるのはTypeScriptコンパイラだ：ClaudeはTypeScriptから直接JavaScriptを生成できるが、専用ツールの方がより速く安く行えるならなぜそうするのか？「専門ツールに本当に得意なことをさせましょう。そしてClaudeには本当に得意なこと——つまりリサーチ——をさせるのです。」