設計の穴を実装前に潰す「疑い屋」エージェント『design-critic』を搭載：開発ワークフローが進化
本記事は、マルチエージェント・フレームワーク「C3」（Claude Code Conductor）の最新バージョン（v2.33.0〜v2.34.0）における機能拡張について詳細に解説している。主な焦点は、設計や計画段階で潜在する欠陥を事前に発見するための監査エージェント『design-critic』の導入である。
C3は通常、「ヒアリング→設計→計画→実装→レビュー」というワークフローを持つが、筆者はこれまでのプロセスにおいて、設計・計画フェーズでの手戻り（「あ、ここ詰め切れてなかった」といった欠陥）が発生する弱点に気づいていた。コードに対する監査役（code-reviewerなど）は存在するものの、設計や計画に対して敵対的に疑う専門エージェントが不足していたのが背景である。
この課題に対し、筆者は外部のブログ記事「My Automated Doubt Development Process」から着想を得て、『design-critic』を開発した。これは、要件・設計・計画のレポートを読み込み、「前提発掘（DC-AS）」「曖昧さ（DC-AM）」「抜け漏れ（DC-GP）」という3つのレンズで敵対的に監査するリードオンリーなサブエージェントである。
v2.34.0では、このdesign-criticを計画フェーズの直後・実装前のオプションゲートとして組み込んだ。さらに重要な改善点として、単に指摘をするだけでなく、「起因層（A要件/B設計/C計画）」をタグ付けし、問題が発見された根本的な層へピンポイントで戻す「層別ルーティング」機構を導入した。これにより、設計上の欠陥は設計フェーズに戻して修正することが可能となった。
初仕事として、筆者自身にdesign-criticを走らせたところ、自分自身の設計・計画レポートから合計8件の具体的な穴（前提発掘3件、曖昧さ2件、抜け漏れ3件）を発見した。特に「Agent type 'design-critic' not found」という運用上の致命的な注意点まで指摘されたことは、機能が自己の欠陥を証明した形となった。
この進化は、「作る側」と「疑う側」を分離する構造的アプローチの重要性を示しており、AI開発におけるレビュープロセスを上流工程（設計・計画）に拡張し、手戻りの削減を目指すものである。
背景
本記事は、大規模言語モデル（LLM）を活用したマルチエージェント開発フレームワーク「C3」の進化に関する技術解説である。従来のAI開発では、実装段階になってから設計上の欠陥に気づく手戻りが課題であったため、この『疑い屋』エージェントを導入することで、より上流工程での品質保証を目指している。
重要用語解説
- マルチエージェント・フレームワーク: 複数の独立したAIエージェント（役割を持つプログラム）が連携し、複雑なタスクを分担して解決するシステム構造。人間チームの協業プロセスを模倣している。
- design-critic: C3に組み込まれた監査専門のエージェント。要件や設計書を読み込み、「前提」「曖昧さ」「抜け漏れ」という複数の視点から、欠陥を敵対的に指摘する役割を持つ。
- 層別ルーティング: 発見された問題の根本原因（例：要件起因か、設計起因か）を特定し、その問題が生まれた特定のフェーズや担当者へ修正プロセスを戻す仕組み。手戻りの効率化を図る。
今後の影響
本機能は、AIを活用したソフトウェア開発における品質保証（QA）の概念を大きく変革する可能性を持つ。設計・計画段階での自動的な欠陥発見は、開発コストと時間を大幅に削減し、より信頼性の高いシステム構築を可能にする。今後の展開として、この監査機能をさらに多様なドメイン知識やセキュリティチェックに拡張することが期待される。