【ITニュース解説】Le vrai problème du vibe coding, ce n'est pas le code, c'est la mémoire

このニュース記事は、筆者が自身のWebサイトリニューアルプロジェクトを通して、AIを活用したコード生成と、それを支える開発手法であるSpec-Driven Development（SDD、仕様駆動開発）の経験を語った内容である。システムエンジニアを目指す初心者にとっても、プロジェクト管理とツールの選定がいかに重要かを学ぶことができる。

まず、筆者は長らく放置されていたコンサート協会のWebサイトを刷新する個人プロジェクトに着手した。当初、彼は「vibe coding」という手法を試みた。これは、具体的な計画を立てずに、AI（Junieというツール）にコード生成を依頼し、その場の思いつきで開発を進めていくやり方である。確かにAIはタスクごとの計画生成やコード生成を効率的にこなしたが、この開発体制には致命的な問題があった。プロジェクトには納期がなく、開発セッションは不定期かつ間隔が空きがちだったため、数ヶ月の中断があると、以前に何をどこまで進めたのか、次に何をすべきなのか、その「記憶」が完全に失われてしまったのだ。コードの品質や生成速度に問題はなかったものの、決定事項を記録する仕組みがなく、タスクの優先順位付けも行われていなかったため、プロジェクトは頓挫してしまった。これが「vibe coding」の限界であり、コードそのものではなく、プロジェクトの「記憶」の欠如が真の問題であったと結論付けられている。

この経験から、筆者は「記憶」を保存し、プロジェクトの進捗を管理する仕組みの必要性を痛感した。そこで出会ったのが「Spec-Driven Development（仕様駆動開発）」という概念である。SDDは、AIコード生成エージェントに対して、単にコードを生成させるだけでなく、その前提となる明確な文脈や具体的な指示を与えることで、開発プロセスを構造化する手法である。このSDDの考え方を基に、三つの異なるツールが試されていくことになった。

二度目のプロジェクト再起動（リブート）で試されたのは「BMad」というツールである。これは、プロダクトオーナー、アーキテクト、開発者、テスターといったアジャイル開発の役割を持つ21の専門エージェントが、分析、計画、設計、実装の4段階で開発を進めるオープンソースツールである。BMadの最大の強みは、詳細なブレインストーミング能力と、タスクの進捗を「ストーリーファイル」として保存する機能にあった。これにより、前回の「vibe coding」で失われていた「記憶」の問題が解消され、作業の再開が容易になった。また、複数のエージェントが多角的な視点から問題を検討するため、深い洞察が得られた。しかし、このブレインストーミングが広範すぎたため、本来のWebサイト開発という範囲を超え、複数のアプリケーション開発へとプロジェクトの目標が拡大してしまう「スコープドリフト」（目標範囲の逸脱）が発生した。これは個人開発者には負担が大きく、またAIの利用に伴う「トークン消費」（AIが処理する情報量に応じたコスト）も高くなるという問題もあった。BMadは漠然としたアイデアを具体化するブレインストーミングには強力だが、スコープが不安定なプロジェクトや単独開発での日々の実行には不向きだと判断された。

三度目のリブートでは「Superpower」が試された。このツールは、仕様書、計画書、コードの三つのドキュメントを中心に開発を進める、よりシンプルなSDDの形を提供している。Superpowerは、ブレインストーミング機能もBMadより簡素であり、小規模なプロジェクトやプロトタイプ（PoC: Proof of Concept、概念実証）の迅速な作成に適していた。プロジェクトも、Webサイトのみに焦点を絞り直したことで、スコープドリフトを抑え、高速に開発を進めることができた。特に、デザイン提案とHTMLデモが同時に提供される点は、具体的な成果を早期に確認できるメリットがあった。しかし、Superpowerにも課題があった。初期のプロトタイプ作成後、一度固まった仕様を調整するのが難しく、コードと仕様の間にずれ（ドリフト）が生じると、その修正が困難になるという問題である。仕様の変更とコードの変更が頻繁に行き来する「ヨーヨー効果」が発生し、プロジェクトが安定しなかった。

そして、Superpowerのプロジェクトを再起動することなく、既存のコードと仕様を引き継いで「OpenSpec」へと移行した。これが四度目のアプローチとなる。OpenSpecは、リポジトリ内に「現在の挙動の真実の源」である仕様と、「全ての重要な進化の提案」を格納するスペースを持つ。大きな変更を加える際には、まず「変更提案（proposal）」を作成し、それが承認されてからコードを実装する仕組みになっている。この「変更提案の事前検証」と、変更履歴の「アーカイブ」によって、BMadやSuperpowerで問題となった「スコープドリフト」が効果的に防がれるようになった。また、OpenSpecはわずか三つのコマンド（提案作成、実装適用、変更アーカイブ）で運用できるため、非常にシンプルである。このアプローチが、計画と実装を反復的に行う「カンバン」スタイルの開発に適していると感じられた。小規模な変更であれば、提案、デザイン、タスクの各ファイルを迅速に調整でき、変更が仕様に与える影響を都度確認できるため、プロジェクトの長期的な維持管理において安定性をもたらしたと評価されている。

これらの経験を通じて、SDDの核心がプロジェクトの「記憶」を捉えることにあると改めて認識された。決定事項とその理由を記録することで、中断後もスムーズに作業を再開でき、開発の方向性を見失うことがない。また、これらの仕様や計画がコードリポジトリ内に存在することは、プロジェクト管理においても大きなメリットとなる。 それぞれのツールは、その特性によって最適な用途が異なる。BMadは漠然としたアイデアのブレインストーミングや、複数の関係者との協力でプロジェクトの初期段階を固めるのに適している。Superpowerは、具体的な成果を迅速に形にするプロトタイプ開発や、スコープが明確に限定された小規模なアプリケーションの開発に向く。そして、OpenSpecは、一度リリースしたプロジェクトを長期にわたって維持・発展させ、仕様のずれ（ドリフト）を防ぎながら継続的な変更を管理するのに最も適していると結論付けられており、デフォルトで推奨するツールとされている。 しかし、各ツールの評価には、再起動のたびに開発技術（Next.js/Storybook、Rust、Astro）が変わったことも影響している可能性がある。SuperpowerからOpenSpecへの移行時のみ技術スタックは同じであったため、ツールの影響のみを純粋に比較することは難しい。

どのツールを使うにしても、AIが生成した内容を、人間が各段階で注意深く確認する「レビュー」の重要性が強調されている。BMadではレビューの厳密さが開発者の規律に委ねられ、Superpowerは初期段階での厳密さを持つが実装が進むと緩くなる傾向があった。一方、OpenSpecは、全ての変更提案の承認を必須とするため、開発プロセス全体を通して人間によるレビューを強制する仕組みが最も優れていると評価されている。また、計画立案には高度な思考力を持つAIモデルを使い、実際のコード実装にはより直接的で高速・低コストなAIモデルを使い分けることで、開発効率とコストを最適化できるという実践的な知見も得られた。 このようなAIを活用した開発ツールは急速に進化しており、継続的な情報収集と試用が重要である。このプロジェクトを通して、RustやAstroといった新しい技術や、Generative Engine Optimization（GEO）といった概念も習得され、最終的なWebサイトの成果は当初の期待を上回るものになった。