はじめに

今回はJetBrainsのライブ配信で「Spec Driven Development（仕様駆動開発）」について、JetBrains Developer AdvocateのPaul Everettと、PyCharmの生みの親であるDmitry Jemerovの議論とデモをまとめました。

1時間以上ある英語の動画なので、この記事では日本語にまとめてご紹介いたします。

Spec Driven Developmentとは？

仕様（Spec）を先に作る
仕様をAIに読ませる
仕様に沿ってAIが実装する
人間がレビューして確定させる

という開発スタイルです。

AI時代の開発で「とりあえず生成してレビューする」だけだと破綻しやすいため、AIに方向性を与えるための枠組みとして注目されています。

AI時代のボトルネックは「実装」ではなく「レビュー」

Dmitry氏が強調していたのは、AIを導入すると

コード生成は一瞬でできる
しかしレビューの負荷が爆増する

という点です。

AIは必要以上に細かいエッジケースまで考慮してしまい、結果として

仕様以上に複雑な実装
無駄に膨らんだコード
保守しづらい構造

を作ってまい、「コードを書く作業」は楽になったが、その分「人間がレビューして正しさを判断する負担」が爆増している。

AI fatigue（AI疲れ）という現実

AIは大量のコードを生成しますが、毎回レビューをするのは人間です。

レビュー対象が増え続けると、

途中から判断が雑になる
結果、コードが肥大化して破綻する

という状態になりやすい。

この現象が配信内では「AI fatigue（AI疲れ）」として語られていました。

Human in the Loopはまだ必須

配信では「AIにmainブランチへのコミットまで任せるか？」という話も出ましたが、結論としては

現時点では人間が最終判断するべき

AIが生成するコードの量と速度は異常なので、人間が関与しない開発はリスクが高いという認識です。

仕様書が増えすぎる問題（スケール問題）

Spec Driven Developmentの弱点として、Dmitry氏は重要な課題を挙げていました。

巨大なプロジェクト（例：IntelliJのような長寿コードベース）では

Issueだけで数十万
意思決定を仕様として残すと「50万個以上のspec」が発生し得る

という話がありましたが、こうなると今度は、

仕様（spec）の管理が困難
AIが読むべき仕様（spec）を選ぶのが難しい
context windowに入らない

など、現実的な運用が崩れます。

ここはまだ「誰も答えを持っていない未解決領域」として語られていました。

仕様は最小限が大事

Dmitry氏いわく、

小さい修正なら仕様を書くよりコードを書いた方が早い
specが長いほどレビューが大変
AIは「100項目のチェックリスト」を作りがちで、
98個は正しくても2個が致命的に間違っていることがある
→ その2個を見抜くのが大変

結論として、

specは必要最小限でいい
あからさまな（obvious）なことは書きすぎない

ということが語られていました。

小さな単位で作業するのが効果的

Paul氏は「作業を小さな単位に分割するべき」（細かすぎ注意）と主張していました。

AIに「世界を作れ」と言うと爆発する
PRの差分が大きいほどレビューできなくなる

という問題があるためです。

一方でDmitry氏は、

小さすぎる単位だと効率が落ちる
「人間がレビューできるPRサイズ」が目安になる

と補足していました。

AgentOSを使った実例デモ

Paul氏はAgentOSという仕組みを使って、spec drivenなワークフローを紹介していました。

AgentOSでは例えば

mission.md（プロジェクトの目的）
roadmap.md（やること）
tech-stack.md（技術方針）
feature spec（機能仕様）

をMarkdownで管理し、それをAIに読ませて開発を進めます。

「毎回プロンプトで説明し直さない」ための仕組みとして紹介されていました。

AIにテストも書かせるべき？

「AIが書いたコードのテストをAIに書かせるのはアリか？」という質問に対して、Dmitry氏は肯定的でした。

理由としては、

テストは面倒で時間がかかる
setupコードなどが多く、AIが得意
人間はレビューに集中できる

という点が挙げられていました。

期待されるAI 開発の未来：IDE機能 × AIの融合

Dmitry氏は、AIが単なるチャットツールではなく、

コミットメッセージ生成
リネーム候補提案
コード理解の支援
IDE操作そのものの補助

など、IDE機能を賢くする方向に進むことを期待していました。

この方向性はまさにJetBrainsが得意とする領域で、
JetBrains IDE（IntelliJ IDEA / PyCharmなど）はAI時代の開発環境として相性が良いことがわかります。

最大のリスクは理解を失うこと

配信で語られた最大のリスクは、AIがどんどん開発を進めると、

人間が全体構造を理解できなくなる
想定外の変更が混ざる
「動くけど怖い」システムになる

AIが作ったものを人間が理解できない状態は危険

という警鐘です。

まとめ

AI 開発に必要なのは「方向づけ」と「制御」
AIは確実に開発を加速させますが、その分

レビュー疲れ
コード肥大化
仕様管理の難しさ
理解の喪失

という新しい問題も発生しています。

Spec Driven Developmentは、AIを実戦投入するための現実的な方法であり、
今後「AIと開発プロセスをどう統合するか」が重要になると感じました。

その中心にあるIDEとしてJetBrains IDEはかなり有力な選択肢だと思いました。

ナットウシステムからのお知らせ

NATTOSYSTEM は JetBrains 製品に関するご質問、ご相談等を受け付けております。
どんな質問でも構いませんので、弊社のXまたはメールでご連絡ください。

参考資料