はじめに
ArchitectAI では、AIが生成したアーキテクチャ設計書の品質を保証するために「Multi-LLM品質ゲート」という仕組みを実装しています。
本記事では、その設計思想・実装方法・実際の効果について詳しく解説します。
課題：AI 1社では品質が安定しない
最初のプロトタイプは Claude 一社だけで設計書の生成と品質審査を完結させていました。
これには致命的な問題がありました。自分が生成したものを自分で審査すると、評価が甘くなる。
同じ入力でも、あるときは「可用性設計がしっかりした設計書」が出て、あるときは「シングルAZ・冗長性ゼロ」の設計書が出てくる。しかも自己評価では高スコアが付いてしまう。これでは実務で使えません。
そこで生まれたのが「異なる特性を持つ複数のLLMが独立してスコアリングし、全社合格でないと再生成する」という仕組みです。
3社AIによる並列スコアリング
現在採用している3モデル：
- Claude Sonnet（Anthropic / Amazon Bedrock）
- GPT（OpenAI API）
- Gemini（Google Cloud Vertex AI）
3社が独立して、生成されたアーキテクチャ設計書を5軸でスコアリングします：
| 軸 | 評価内容 |
|---|---|
| Scalability | オートスケール・LB・非同期処理の設計 |
| Availability | マルチAZ・DR・ヘルスチェックの冗長性 |
| Security | WAF・暗号化・Secrets Manager・最小権限IAM |
| Cost Efficiency | コスト試算の根拠・過剰プロビジョニングの有無 |
| Maintainability | 可観測性3本柱・デプロイ戦略・運用手順 |
スコアリング方式は「減点方式（0〜10点）」。各社が独立して採点し、3社すべてが全軸で≥8.0/10をクリアしないと再生成がかかります。
なぜ閾値を 8.0 に設定したか
最初は 7.0 でテストしましたが、7点台だと「及第点だけど品質が低い設計書」が通過してしまうケースがありました。≥8.0 は「ベストプラクティスに沿っており、実際のプロジェクトで初稿として使えるレベル」という経験則から設定しています。
≥9.0 も試しましたが、入力情報が不完全な段階（要件が曖昧など）では達成困難で、再生成の過剰ループになるケースが発生しました。
実装：ThreadPoolExecutor で並列呼び出し
Pythonの concurrent.futures.ThreadPoolExecutor を使って、3社のAPIを並列呼び出しします。
from concurrent.futures import ThreadPoolExecutor, as_completed
from dataclasses import dataclass
from typing import Dict, List
@dataclass
class AxisScores:
scalability: float
availability: float
security: float
cost_efficiency: float
maintainability: float
@dataclass
class ReviewResult:
reviewer: str
axis_scores: AxisScores
passed: bool
feedback: str
def review_architecture(design_content: str) -> dict:
reviewers = [
ClaudeReviewer(),
OpenAIReviewer(),
GeminiReviewer(),
]
results: List[ReviewResult] = []
with ThreadPoolExecutor(max_workers=3) as executor:
futures = {
executor.submit(r.score, design_content): r.name
for r in reviewers
}
for future in as_completed(futures):
results.append(future.result())
# 全社の全軸スコアを集約
all_passed = all(
getattr(result.axis_scores, axis) >= 8.0
for result in results
for axis in ["scalability", "availability", "security",
"cost_efficiency", "maintainability"]
)
avg_scores = {
axis: sum(getattr(r.axis_scores, axis) for r in results) / len(results)
for axis in ["scalability", "availability", "security",
"cost_efficiency", "maintainability"]
}
return {
"passed": all_passed,
"results": results,
"avg_scores": avg_scores,
}
3社の呼び出しが直列だと最大で3倍の時間がかかりますが、並列化することで待ち時間を最小化しています。
構成図（draw.io）の品質審査は別の軸で
アーキテクチャ設計書の品質審査（5軸・≥8.0）とは別に、draw.io構成図には専用の6軸審査を実装しています：
| 軸 | 評価内容 |
|---|---|
| accuracy | 設計JSONとの一致性（サービス・接続） |
| visual_clarity | ノードの重なり・テキスト可読性・余白 |
| layout_logic | フロー方向・AZ/レイヤーグループ化 |
| legend | 凡例ボックス・色説明・AZラベル |
| icon_consistency | 公式クラウドアイコン・スタイル統一 |
| label_quality | ノードラベル・エッジのプロトコル/ポートラベル |
閾値は各軸≥7.0/10。設計書より低めに設定しているのは、図の品質評価はAIによる主観のばらつきが大きいためです。
実際の効果
Multi-LLM品質ゲートの導入後、設計書の問題発生率が大幅に低下しました。
再生成がトリガーされた主なケース：
- 高可用性要件があるのにシングルAZの設計になっていた（Availability軸でClaude/GPT両方が指摘）
- 金融系要件があるのにPCI DSS対応が設計に反映されていない（Security軸でGeminiが指摘）
- オートスケール設定なしでアクセス急増に対応できない設計（Scalability軸で3社全員が指摘）
3社の指摘ポイントが異なることが多く、Claudeが「コスト試算の根拠が薄い」と指摘し、GPTが「監視設計が不十分」と指摘し、Geminiが「冗長性が低い」と指摘する——というケースが典型的です。3社で補完し合っているのを感じます。
まとめ
Multi-LLM品質ゲートのポイント：
- 3社のLLMを並列で使い、互いの弱点を補う
- 減点方式 × 閾値（≥8.0）で合否を明確に判定
- 合格するまで自動再生成
- 設計書と構成図で別々の評価軸を設定
「AIが出してきた設計書をそのまま信頼するのは不安」という課題に対して、「異なるAIが相互チェックする」というアプローチで対応しています。
FREEプランはクレジットカード不要・10cr付与。企画フェーズ全体（Step0〜3）をすぐに試せます。