Claude Codeマルチエージェント開発で69件のバグを発見―全工程監査が救った致命的な法令違反

Claude Codeのマルチエージェント体制で飲食店向けAI原価計算SaaS「Genka」を開発していたmakiさんが、クローズドβテスト前に実施した全工程監査で69件のバグを発見しました。中でも最も深刻だったのは、食品表示法で義務付けられているアレルゲン情報がPDF出力に一切含まれていなかったという法令違反レベルの欠陥でした。

この事例は、AI駆動開発における品質保証の本質的な課題を浮き彫りにしています。要件定義(RD)から受け入れテスト(UAT)まで全工程を通過しながら、なぜこのような致命的バグが残ったのか。そして、それを防ぐために何が必要なのか。

makiさんが実施したのは、以下の全工程の成果物を横断的に監査するアプローチです。

この監査により発見された69件の漏れのうち、P0（即時対応が必要）と判定されたのが12件。アレルゲン情報の欠落は、法令遵守という観点から最も深刻な問題として特定されました。

Claude CodeとGitHub Copilotの品質管理における決定的な違い

GitHub CopilotやCursorなどのAIコーディングツールと比較すると、Claude Codeのマルチエージェント体制には構造的な特徴があります。複数のエージェントが各工程を分担することで開発速度は向上しますが、**工程間の整合性チェックが人間の責任として残る**点が重要です。

従来の人間主導開発では、要件定義を書いた人間が「当然アレルゲン情報は必要」と認識していれば、設計・実装・テストの各段階で自然とチェックされます。しかしAIエージェントは、明示的に指示されない限り「食品表示法の遵守」という文脈を保持しません。

これは**暗黙知の明示化**という古典的な課題が、AI時代に新しい形で再浮上していることを意味します。

この手法の3つの本質的メリット

1. **法令・規制リスクの早期発見**: ドメイン固有の規制要件は、AIが最も見落としやすい領域です。飲食業界なら食品表示法、医療なら個人情報保護法、金融なら金商法といった業法は、工程横断的な監査でしか捕捉できません。

2. **工程間の論理的整合性の検証**: 要件定義に書かれた機能が設計書に反映されているか、設計書の仕様がテストケースでカバーされているかを、成果物を並べて確認することで可視化できます。

3. **AIの「思考の癖」の発見**: 複数の工程でAIが同じパターンのミスを繰り返している場合、プロンプト設計やコンテキスト設定に構造的な問題がある可能性があります。この視点は、次のプロジェクトの品質向上に直結します。

注意すべき3つの落とし穴

一方で、この手法には明確な制約もあります。

1. **監査者の専門知識への依存**: 食品表示法違反を発見できたのは、監査者がその存在を知っていたからです。ドメイン知識のない領域では、同様の致命的バグを見逃すリスクが残ります。

2. **時間コストの増大**: 9つの工程すべての成果物を精査するには、相当の工数が必要です。スタートアップの初期段階では、このリソースを確保できない場合があります。

3. **監査タイミングの判断**: Phase 4直前という実施タイミングは適切でしたが、もし致命的バグがPhase 2の設計段階で混入していた場合、手戻りコストは膨大になります。段階的な監査ポイントの設計が必要です。

どんな開発に向いているか

この全工程監査アプローチが特に有効なのは以下のケースです。

逆に、プロトタイプ開発やMVP検証段階では、全工程監査はオーバーキルになる可能性があります。リスクと工数のバランスを見極める判断力が問われます。

アクション1: ミニマム版の「3工程チェックリスト」を作る

全9工程は難しくても、まずは以下の3つをチェックする習慣をつけましょう。

1. **要件定義 → 設計書**: 要件に書かれた機能がすべて設計書に反映されているか

2. **設計書 → 実装**: 設計書の仕様が実際のコードで実現されているか

3. **要件定義 → テストケース**: 要件の受け入れ条件がテストでカバーされているか

スプレッドシートで対応表を作り、各項目に✓を入れていくだけでも、致命的な漏れの大半は防げます。

アクション2: ドメイン固有の「必須チェック項目」を整理する

あなたが開発している領域で「これは絶対に守らなければならない」という法令・規制・業界標準をリストアップしてください。

このリストを「監査チェックリスト」として各工程の成果物に照らし合わせることで、AIが見落としやすいコンプライアンス要件を補完できます。

アクション3: AIに「自己監査プロンプト」を実行させる

最終的な人間による監査の前に、AIエージェント自身に以下のようなプロンプトで自己チェックさせる方法も有効です。

あなたが作成した設計書について、以下の観点で漏れがないか確認してください。

1. 要件定義書に記載されたすべての機能要件が設計に反映されているか
2. [業界名]における法令遵守事項（例: 食品表示法）が考慮されているか  
3. セキュリティ・プライバシーに関する要件が明記されているか

漏れがある場合は、該当箇所と理由を報告してください。

これは完璧ではありませんが、人間の監査負荷を軽減し、見落としリスクを下げる「第一段階フィルター」として機能します。

Claude Codeのようなマルチエージェント開発は、開発速度を劇的に向上させますが、品質保証の責任は依然として人間にあります。特に法令遵守やドメイン知識が必要な領域では、AIの出力を盲信せず、体系的な監査プロセスを組み込むことが不可欠です。

今回の事例が示すのは、「AIが書いたコードだから安全」ではなく、「AIが書いたからこそ、人間が構造的にチェックする仕組みが必要」という逆説です。全工程監査は工数がかかりますが、法令違反でリリース後に回収・謝罪するコストと比較すれば、はるかに合理的な投資といえるでしょう。

この情報は @maki さんの投稿を参考にしています。