AIコーディングが速くても納品が速くならない理由――小紅書Museの実践

導入

大規模言語モデルは、コードを生成する速度を大きく高めた。しかし、要件の提案から本番リリースまでの時間が同じように短くなったとは限らない。企業の開発には、デザインシステム、社内知識、既存リポジトリの規約、セキュリティ確認、テスト、チーム間の引き継ぎがある。小紅書のAI CodingプラットフォームMuseに関する講演では、コーディングは開発工程の一部にすぎず、そこで得た時間がレビューや修正、再調整で失われる可能性が示された。

ボトルネックはコードの外側にある

企業向けAI Codingの課題は、主に三つに整理できる。

• 企業固有の文脈を理解できない：内部コンポーネント、業務ルール、リポジトリ構造、デザイン規約を知らなければ、出力は動いても実務では使いにくい。
• 情報が分散している：会話、ユーザーの記憶、デザイン、複数リポジトリの情報が別々に存在し、Agentがタスク全体を把握しにくい。
• ツールが安定した工程になっていない：多くのSkillやツールを用意しても、重複実行、矛盾した結果、途中で再開できない処理が起こり得る。

Museが目指すのは、使い捨てのHTMLデモを生成することではない。企画、デザインの試行、実際のコード実装を同じ文脈の流れに置き、プロダクトマネージャー、デザイナー、開発者が編集可能な成果物をもとに案を比較できるようにする。その後、Dev Agentが文脈を引き継ぎ、実際のコードリポジトリへ進む。

自律性だけでなく実行時の制御が必要

Museでは、要件が形成される前の作業と、実際のコードベースで行う作業を分けて考える。前者は業務やデザインの判断を支援し、後者は複数リポジトリの理解、規約、テスト、リリース条件を扱う。確実性が必要な処理にはWorkflowやPipelineを残し、タスクの分割や探索が有効な場面ではAgent Teamを使うという、段階的な構成を取る。

HarnessはAgentを囲む実行時の制御層にあたる。開始前に文脈を確認し、実行中の各ターンを監視し、ツールの引数と戻り値を検証する。副作用を伴う操作の前には、人間の承認を求めることもできる。さらに、会話履歴だけではなく、目標、計画の版、完了済みの手順、ツールの証拠、承認、対象リソースの版、失敗情報を構造化して保存する必要がある。これにより、処理の一時停止、監査、再開、場合によってはロールバックが可能になる。

意味すること

Museの事例が示すのは、AI Codingの競争軸が変わりつつあるということだ。重要なのは、どのモデルが最も速くコードを書くかだけではない。モデルの能力を、再現可能で本番に耐える開発システムへ変換できるかが問われている。モデルは能力の上限を決めるが、実際の導入可否を決めるのは、Agent Runtime、企業知識、検証器、権限境界である。

人間の役割も消えるわけではない。目標の妥当性、案の比較、リスクの監督、最終的な品質や好みの判断へと重心が移る。文脈、ツール、状態、検証、承認が一つのループになって初めて、Vibe Codingは素早い試作から信頼できる開発基盤へ進める。

出典：InfoQ 中文