Amapが実践した、HarnessガバナンスとSDDに基づくチームレベルAI開発パラダイムの進化。
皆さん、こんにちは。Amap大規模言語モデル応用プラットフォームのWang Shuxinです。今回は「Vibe Codingとの決別：HarnessガバナンスとSDDによるチームレベルAI開発パラダイムの進化と実践」を紹介します。
話は昨年9月にさかのぼります。Cloud ConferenceのQoder分科会へ招かれ、Qoderによる開発効率化についてチームの実践を共有しました。Prompt EngineeringとContext Engineeringを活用し、技術設計と開発工程でAIコード生成率53%を実現した、期待に満ちた時期でした。この数字から、AIプログラミングの大きな可能性が見えていました。
その後、AIが半年余りで急速に進化し、チームのコード生成率は80～90%以上になりました。ほぼ倍増した見栄えのよい数字です。しかし、チームへの詳細な聞き取りとPMOの指標を確認すると、不可解な事実が分かりました。効率向上は明確ではなかったのです。
コード生成率は上がっても、プロジェクトの納期は明らかに短縮せず、AIがより多くのコードを書いても、開発者の作業量は減っていませんでした。そこで立ち止まり、問題を見直しました。
当時共有した内容を振り返ります。AI Codingには3つの問題がありました。
第1に、自由な暴走。 AIは業務理解とルールが不足しているため、現実離れしたコードを生成しがちです。同じ機能に3種類の実装を示し、どれも「動く」ものの、既存アーキテクチャと合わないことがあります。
第2に、効率低下。 AIは効率を高めるはずなのに、指示が不明確だと何度も会話を往復します。「直して」「違う、こうして」と繰り返すうちに、自分で書くより時間がかかります。
第3に、重要情報の喪失。 複数回の対話では、AIが以前の重要な制約を「忘れ」ます。タスクが大きすぎると、最初に示したアーキテクチャ要件が後半では消えてしまいます。
これらに対し、Repo Wiki、Memory、Rulesで自由な暴走を制限し、Prompt Engineeringで効率を改善し、Context EngineeringとQuestモードで重要情報の喪失を防ぐという、Qoderの体系的な実践案を提示しました。
当時は未来に大きな期待を持っていました。開発者は要件を定義し、結果を検証するだけになり、文書、コーディング、テストといった作業はAIが担う。AIは生産ツールから新しい開発基盤へ変わり、開発者はコーダーからAIアーキテクトへ変わる、という構想です。
しかし半年後、コード生成率の向上がなぜ本当の効率化につながらないのか、疑問を抱きました。長く考えた末、3つの原因を見つけました。
要件の提示からリリースまでには、製品要件、製品・開発レビュー、設計、開発、コードレビュー、テスト、結合、リリースがあります。すべてにコミュニケーションコストと待ち時間があり、誤りも起きます。
『人月の神話』には「銀の弾丸はない」という有名な議論があります。ソフトウェア開発には、コーディングだけでなくコミュニケーション、協働、意思決定が含まれるからです。コーディングを50%効率化しても、それが全工程の30%なら、全体では15%しか改善しません。さらにAI生成コードは、コードレビュー、デバッグ、手戻りを増やす可能性があります。
そこで、本当の効率化には単一工程ではなく全工程の接続が必要だと分かりました。AIが工程の境界を越え、要件からデプロイまでを閉じたサイクルにする必要があります。
Vibe Codingとは、AIへ数行のプロンプトを与え、数秒で数千行のコードを生成させる「雰囲気によるコーディング」です。新規プロジェクトや小さなスクリプトでは使えても、既存アプリケーションでは非常に危険です。
既存アプリケーションには、歴史的な負債、暗黙の依存関係、コードに埋め込まれた業務知識があります。AIにVibe Codingをさせると、一見完璧でも既存システムとまったく互換性のない案を作ることがあります。しかも、リリース後に初めて問題が表面化する場合があります。
実際に、AI生成コードが中心APIの引数順を変更し、単体テストはすべて通ったのに、リリース後に下流3サービスでエラーが起き、調査に丸一日かかったことがあります。既存アプリケーションのAI開発は「雰囲気」から「規範」へ移行し、明確な受け入れ基準を設けなければならないと痛感しました。
これがSDD（Specification-Driven Development、仕様駆動開発）を導入した理由です。人間の曖昧な考えを、AIが正確に理解できる明確で曖昧さのない構造化仕様へ変換し、AIを管理可能な軌道上で動かします。
フロントエンドとバックエンドの十数モジュールにまたがるリファクタリングを経験しました。1回の会話では完了できません。AIのコンテキストウィンドウには限界があり、注意も分散します。タスクが大きすぎると、一方へ対処する間にもう一方を見落とします。
3つの原因が示す結論は同じです。AIプログラミングを「個人のスキル」から「チームのエンジニアリング能力」へ高め、「Vibe Coding」から「仕様駆動とエンジニアリングガバナンス」へ進化させる必要があります。
目標は、コードを書く工程だけでなく、要件PRDから直接デプロイするまでの全工程をAIでつなぐことです。そのため、**SDD（仕様駆動開発）とHarness Engineering（AIを制御するエンジニアリング）**の2つへ注目しました。
SDDでは、仕様は人間が読む散文ではなく、AI Agentが正確に理解し、実行できる構造化された「意図のコード」になります。
従来はPRDや設計文書が「手引き」であり、コードが唯一の「真実の源泉」でした。そのため文書はすぐに古くなり、コードと乖離します。SDDでは仕様が唯一の真実の源泉です。要件変更時にはまず仕様を変更し、AIツールが仕様に基づいてコードを再生成、検証、更新します。
SDDは4段階で進みます。
1. Specify（仕様定義）。 開発者とAIが検討し、ユーザーストーリー、受け入れ基準、システム制約を定義した構造化仕様を作ります。「元の要件」の段階です。
2. Plan（計画策定）。 AIがコンパイラーのように仕様を詳細な技術案とタスク一覧へ「コンパイル」します。「技術文書」の段階です。
3. Implement（実装）。 AI Agentがタスクを順に実行し、高品質なコードを自動生成します。「ソフトウェア開発」の段階です。
4. Validate（検証）。 仕様に基づいてテストケースを自動生成・実行し、コードが仕様へ完全に一致することを確認します。「機能とコード仕様のテスト」の段階です。
SDDが「何を作るか」を解決するなら、Harnessは「どう管理可能な形で作るか」を解決します。
Harnessは馬具を意味します。大規模モデルは無限の力を持つ野生馬ですが、馬具がなければ乗ることもできず、振り落とされるかもしれません。Harness Engineeringはモデル自体の遺伝子を変えるのではなく、精密な制御システムを設計します。
成熟したHarnessシステムには4つの柱があります。
1. Context Engineering。 単純なRAGではなく、構造化された情報を与えます。「単一の真実の源泉」を維持し、Agentにディレクトリ構造、現在の実行計画、最新文書を知らせます。
2. アーキテクチャ制約。 物理的な仕組みでAIにルールを守らせます。たとえばUI層からデータベース層へ直接アクセスすることを禁止し、階層違反を試みるコードは構文検査すら通らないようにして、コミット前に遮断します。
3. フィードバックループとエントロピー管理。 AIは必ず誤るため、発見と修正の仕組みを作ります。Agentがコードを書く、テストを自動実行する、失敗する、ログを読む、自己修正して再試行する、というサンドボックスを構築します。人が修正した経験も新しいルールへ変え、同じ誤りを二度と繰り返さないようにします。
4. 人間の監督。 人は「コードを書く人」から「レビュー担当者」と「環境設計者」へ変わります。複雑な業務境界を定義し、AIが判断できない5%の曖昧なロジックを処理し、Harness自体のルールを改善します。
Prompt EngineeringからContext Engineering、そしてHarness Engineeringへの変化は、「AIへどう話すか」から「AIに何を見せるか」、さらに「AIを管理された環境でどう動かすか」へのパラダイムシフトです。
次の動画は、Qoderで大規模な要件をエンドツーエンドに開発する全過程です。
PRDからSpec生成、タスク分解、コード生成、テスト検証、最終デプロイまでを自動化しています。開発者はコードを書くのではなく、要件を明確にし、仕様をレビューし、結果を検証します。
基盤となる知識を、プロジェクト層、技術層、資産層の3層で整理します。
実際のプロジェクトでは3層構造でディレクトリを設計し、README.mdで索引を作り、必要な情報だけを読み込みます。構造化と柔軟なオンデマンド読み込みを両立し、Agentが効率よく必要な知識を取得してコンテキスト過負荷を避けます。
Memoryは、AIの「コンテキスト不安」を解決するQoderの中心機能です。長期開発では、以前の意思決定、現在の進捗、今後の作業など多くの情報を記憶する必要があります。Memoryはそれらを構造化して保存、管理し、AIが毎回ゼロから始めず、正しいコンテキストで判断できるようにします。
次にQuest Specモードで、標準化されたdesign.mdを生成します。これは完全自動ではなく、人の介入を必要とする**HITL（Human-In-The-Loop）**です。
要件文書には、製品担当者が当然だと考えていても、実際には確認が必要な「暗黙知」があります。「ユーザーログイン」だけでも、対応するログイン方式、状態の保持、パスワード強度、失敗時の処理などがあります。
SpecモードではAIが質問し、開発者へ暗黙知の明確化を促して、完全なSpecを作ります。Specには次が含まれます。
データモデル：対象テーブル、フィールド定義、関係。
API仕様：入出力、エラーコード、冪等性要件。
最も重要な受け入れ基準：テスト可能で曖昧さがないこと。「ログイン成功後にホームへ移動する」ではなく、「ログイン成功後3秒以内にホームへ移動し、ユーザー名を表示する」と定義します。
完全なSpecがあれば、AIは明確な「設計図」に従い、Vibe Codingではなくなります。
Specの準備後、QoderのExpertsモードで実行します。実際の開発チームのように、フロントエンド、バックエンド、テスト、アーキテクトなど、異なる役割のAgentがそれぞれのタスクを担当します。
AIはSpecから実行計画を作り、大規模タスクを管理可能な小タスクへ分解します。各タスクには明確な入力、出力、受け入れ基準があり、種類に応じて適切なAgentへ割り当てられます。
システムには独立したツールセットを持つ5種類のExpertが組み込まれ、カスタムExpertも作成できます。
ユーザーも調整の一部です。Expertsの実行中にいつでも介入でき、Experts Leaderが次のループで指示を処理し、方向を調整したり不要なタスクを取り消したりします。役割は、意図を明確にし、方向をそろえ、計画をレビューし、結果を受け入れる、経験豊富な開発チームを率いる立場へ変わります。
コード生成とテスト完了後は、Aone（Alibaba社内CI/CDプラットフォーム）のMCPツールを通じ、成果物を運用Agentへ渡してデプロイします。
運用AgentはMCPでCI/CDパイプラインの起動、デプロイスクリプトの実行、状態の照会、異常処理を行います。要件からデプロイまでが接続され、開発者はさまざまなツールを手作業で操作せず、AIの案内のもと重要な判断だけを行います。
フロントエンドとバックエンドが連動するプロジェクトでは、拡張ツールのSkillsも接続しました。SkillsはQoderの能力拡張機構で、たとえばデータベース操作Skillにより、AIがデータベースを直接照会、変更し、データの準備と検証を行えます。これにより、コード生成だけでなく、開発、テスト、検証までエンドツーエンドで完了します。
SDDとHarnessにより、要件からデプロイまでの全工程を接続し、「Vibe Coding」から「仕様駆動とエンジニアリングガバナンス」への転換を実現しました。開発者は受動的なコーダーではなく、要件の定義者、仕様のレビュー担当者、結果の検証者になります。AIも管理不能なブラックボックスではなく、Harnessの制約下で動く信頼できるツールになります。
今後は3つの方向を検討します。
第1に、よりインテリジェントなSpec生成。 現在は人の介入が多いため、対話型の要件明確化を高度化し、負担を減らします。
第2に、より強力なAgent Teams。 現在の協働は比較的単純であり、複数回の反復や動的な役割割り当てなど、より複雑な方式を探ります。
第3に、より完全なナレッジ管理。 ナレッジベースは全体系の基盤です。より賢い知識抽出、更新、再利用の仕組みを探ります。
企業向けソリューションの詳細はこちら ➔
1. AI Codingにおける3つの中心課題
話は昨年9月にさかのぼります。Cloud ConferenceのQoder分科会へ招かれ、Qoderによる開発効率化についてチームの実践を共有しました。Prompt EngineeringとContext Engineeringを活用し、技術設計と開発工程でAIコード生成率53%を実現した、期待に満ちた時期でした。この数字から、AIプログラミングの大きな可能性が見えていました。
その後、AIが半年余りで急速に進化し、チームのコード生成率は80～90%以上になりました。ほぼ倍増した見栄えのよい数字です。しかし、チームへの詳細な聞き取りとPMOの指標を確認すると、不可解な事実が分かりました。効率向上は明確ではなかったのです。
コード生成率は上がっても、プロジェクトの納期は明らかに短縮せず、AIがより多くのコードを書いても、開発者の作業量は減っていませんでした。そこで立ち止まり、問題を見直しました。
2. 「コード生成率」から見えた、効率化の深層課題
しかし半年後、コード生成率の向上がなぜ本当の効率化につながらないのか、疑問を抱きました。長く考えた末、3つの原因を見つけました。
原因1：開発はコードを書くことだけでなく、全工程から成る
原因2：既存アプリケーションでのVibe Codingは危険性が高い
原因3：大規模プロジェクトと複雑な要件は、1回のAI対話の能力を超える
3. 解決策：SDDとHarnessの導入
目標は、コードを書く工程だけでなく、要件PRDから直接デプロイするまでの全工程をAIでつなぐことです。そのため、**SDD（仕様駆動開発）とHarness Engineering（AIを制御するエンジニアリング）**の2つへ注目しました。
SDD（仕様駆動開発）
Harness Engineering（AIを制御するエンジニアリング）
4. 全工程自動化の実践
次の動画は、Qoderで大規模な要件をエンドツーエンドに開発する全過程です。
PRDからSpec生成、タスク分解、コード生成、テスト検証、最終デプロイまでを自動化しています。開発者はコードを書くのではなく、要件を明確にし、仕様をレビューし、結果を検証します。
ステップ1：ナレッジベースの設計
- プロジェクト層：概要、ディレクトリ構造、アーキテクチャ、技術選択など、AIがプロジェクトを理解する基礎です。オンデマンド読み込みのため、最上位のREADME.mdをQoderの「単一の真実の源泉」とします。文書にない情報は、Qoderにとって存在しません。
- 技術層：共通技術、コーディング規約、ミドルウェア、サードパーティ文書、ベストプラクティス、よくある問題など、プロジェクト間で再利用できるチームの技術知識です。
- 資産層：再利用可能なコード、コンポーネント、テンプレート、過去のPRD、技術案、アーカイブ済みテストケースなど、チームが蓄積した「部品」です。
ステップ2：要件PRDの処理
ステップ3：Expertsによるタスク実行
ステップ4：デプロイ
5. まとめと展望
SDDとHarnessにより、要件からデプロイまでの全工程を接続し、「Vibe Coding」から「仕様駆動とエンジニアリングガバナンス」への転換を実現しました。開発者は受動的なコーダーではなく、要件の定義者、仕様のレビュー担当者、結果の検証者になります。AIも管理不能なブラックボックスではなく、Harnessの制約下で動く信頼できるツールになります。