JetBrainsライブ配信まとめ：AI 開発 Spec Driven Development

はじめに

今回は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またはメールでご連絡ください。

参考資料