何が起きているか
AIコーディングエージェントは、データ変換、パイプライン、Airflowのオーケストレーション、バリデーションテスト、インフラ設定までをプロンプトから自動生成できるようになりました。一方で、プロンプトに依存して場当たり的に実装を進める「vibe coding」では、業務文脈やアーキテクチャ判断がチャット履歴と生成コードに分散し、システムそのものに残らないという課題が顕在化しています。
VentureBeatが取り上げたSpec-driven development(SDD)は、プロンプト・業務ルール・バリデーションロジック・オーケストレーション挙動を、実行可能かつバージョン管理された「仕様(spec)」へと変換し、システムの一部として残すアプローチです。
なぜ重要か
プロンプトは本質的に一過性で、同じ文面でも文脈が変われば同じ実装は再現されません。エンタープライズのデータ基盤は、取込基盤・ストリーミング・ウェアハウス・セマンティックレイヤー・API・ダッシュボード・MLパイプラインへと断片化しており、上流のわずかな変更が下流で静かに壊れるリスクを常に抱えています。プロンプト任せの開発は、この断片化をさらに増幅させます。
SDDの構造
SDDの基盤には、技術標準・命名規則・アーキテクチャ原則・ガバナンスを定義する「constitution(憲法)」が置かれます。その上に、スキーマ仕様(構造的互換性)、変換仕様(業務ロジック)、バリデーション仕様(品質ルール)、オーケストレーション仕様(実行挙動)、セマンティック仕様(共通定義)、AIワークフロー仕様(再利用可能な実装指示)が積み上がります。
例えばワークフロー仕様には、Salesforce顧客データのPython取込コード、Type 2 SCD(SCD2)を実装するDBTモデル、毎時実行のAirflowワークフロー、下流互換性のテスト生成を、エージェントへ指示する内容が含まれます。仕様の多くはMarkdownで保守され、AI支援で生成・洗練されます。
メタデータ駆動の世界との親和性
エンタープライズのデータエンジニアリングは、再利用可能なパターンとメタデータ駆動のパイプラインに大きく依存しています。アーキテクチャが定まれば実装は反復作業に近づくため、宣言的に仕様を残すSDDの恩恵が最も大きく出る領域だといえます。VB Transform(7月14〜15日)では、Intuit・Target・InstacartのエンジニアリングリーダーがオーケストレーションアーキテクチャやIntuitが60日でマルチエージェントを再構築した事例について議論する予定です。
💼 事業会社視点：これは自社にどう効くか
日本企業の事業責任者にとって、SDDは単なる新手法ではなく「AI時代のデータガバナンス戦略」と捉えるべきです。
事業会社のデータ部門: SnowflakeやDBTを採用済みの企業では、業務ロジックがSQLや個人のSlack履歴に散在しがちです。SDDの「constitution」と仕様レイヤーは、CDO・経営企画が現場へ任せきりにしてきた業務定義を、経営の意思として明文化する仕組みになります。属人化したアナリストが辞めた瞬間に業務知識が消える、というよくある事故への保険でもあります。
SaaS・受託開発企業: 顧客ごとのカスタムパイプラインを抱える受託・SIerは、仕様をプロダクト資産として再利用できるかが収益性を決めます。プロンプトで都度生成するのではなく、Markdown仕様をテンプレ化して横展開する体制が、AIエンジニアリングの粗利を守ります。
経営判断: 「AIで生産性が上がった」を語る前に、生成された実装の業務文脈がシステムに残っているかを問うべきです。残っていなければ、技術的負債を高速生産しているだけです。CTO・VPoEには、SDDをCI/CDと同列のガバナンス投資として予算化することを推奨します。
