複数LLMで同一システムを診断したら、それぞれ異なる「評価軸」が見えた話
構造監査の観測ログ ― AIモデルごとの視点の違いから学ぶ設計のヒント
はじめに：同じ資料、異なるスコア
あるメール処理システムの設計資料を、複数のLLMに同じプロンプトで評価してもらう実験を行いました。システムの概要は、メール解析→自動タグ付け→データベース格納→AI要約検索という、よく見られる構成です。
同一の資料、同一趣旨のプロンプトで依頼したにもかかわらず、返ってきたスコアは次のようになりました:
| モデル | スコア | 評価の傾向 |
|---|---|---|
| 高速系モデルA | 85 | UX/プロダクト視点 |
| 汎用モデルB | 57 | 設計責任視点 |
| モデルC | 43 | 安全工学寄りの視点 |
| 専門モデルD | 10 | データ整合性重視 |
85点と10点。この差は単なるモデルの性能差やブレではなく、それぞれが異なる評価軸を持っていることを示していました。
評価が分かれたポイント：LLM生成データの永続化
スコアが大きく分かれた核心は、「LLMによるタグ付け結果をデータベースに保存する」という設計要素でした。
プロダクト寄りの評価:
「検索性や可視化が向上し、ユーザー体験が改善される。実装も現実的」
アーキテクト寄りの評価:
「確率的な出力をそのまま永続化すると、データ整合性の担保が難しくなる」
「業務判断に関わる分類を、決定論的でない処理に委ねている」
特に興味深かったのは、データ基盤に詳しいモデルの反応です。プロンプトには「基幹データ」という言葉を使っていなかったにもかかわらず、「BigQuery + タグ + 営業データ」という構成から、自動的に「業務データへの書き込み」として解釈し、慎重な評価を返してきました。
これは、モデルが持つ知識ベースから構造を推論し、リスクを想定する動きです。
各モデルに見えた「職種」的な違い
今回の実験で明確になったのは、各モデルがどの立場でシステムを見ているかという違いでした:
- 高速系モデル: プロダクトマネージャ的視点
→ 「ユーザーにとって価値があるか」 - UX重視モデル: デザイナ的視点
→ 「体験として自然か」 - 安全重視モデル: 監査的視点
→ 「例外発生時の挙動は設計されているか」 - データ基盤重視モデル: アーキテクト的視点
→ 「永続層の整合性は保たれるか」 - 構造分析モデル: 設計責任者的視点
→ 「この構造の責任範囲は明確か」
これは優劣ではなく、役割の違いです。人間の組織でも、同じ仕様書を見て営業は「売れるか」を、インフラエンジニアは「安定稼働するか」を重視するのと同じ現象が、LLMレベルでも観測されたことになります。
安全工学寄りモデルが重視する要素
アーキテクト的な評価軸を持つモデルは、以下の要素が揃った設計に対して慎重な評価を返す傾向がありました:
- LLMが分類・タグ付けを行う
- その結果がデータベースに保存される
- 不明・例外ケースの処理フローが明示されていない
- 決定論的なルールとの併用がない
- ルールIDや監査ログの記録がない
これらが組み合わさると、構造的には次のような形になります:
確率的な処理
↓
永続データ層
この構造を見たとき、これらのモデルは「設計上の注意点」として指摘してきます。
観測から得られた設計上の示唆
今回の実験から抽出できた設計原則は以下の通りです:
LLMの位置づけ:
LLMはユーザーインターフェース層、あるいは提案層として機能させる
判断ロジックの配置:
業務判断に関わる部分は決定論的なコードで実装する
永続化の前に必要な設計:
- スキーマバリデーション
- 信頼度の閾値判定
- 不明ケースのルーティング
- 必要に応じた人間の承認プロセス
たとえタグ付けのような補助的な処理であっても、データベースに書き込まれた時点でそれは業務データになります。確率的な揺らぎを許容する場合、適切なガードレールの設計が重要になります。
実務での使い分け提案
今回の観測から見えた、実用的なモデルの使い分け方:
フェーズ1: 初期検討・プロダクト視点での評価
高速系モデルやUX重視モデルを使い、「ユーザー体験として成立しているか」「実装の現実性」を確認
フェーズ2: 構造監査・安全性の精査
アーキテクト寄りのモデルで、データ整合性やエラーハンドリング、責任範囲の明確さを検証
これは、人間の設計レビューでも行われている分業と同じ構造です。初期フェーズではアイデアの可能性を広げ、後半フェーズで構造の堅牢性を高める。それぞれのモデルを、そのフェーズに適した評価軸として活用する考え方です。
まとめ:AIの評価軸は中立ではない
今回の実験が示したのは、AIモデルごとに異なる評価関数(視点)を持っているという事実です。
アーキテクト寄りのモデルは:
- 記述されていない要素に対して慎重
- 最悪ケースを想定する傾向
- 永続層への影響を重視
- 安定性を優先
一方、プロダクト寄りのモデルは:
- ユーザー価値を重視
- 実装の現実性を考慮
- 体験の自然さを優先
どちらが正しいかではなく、目的とフェーズに応じて使い分けることで、より多角的な設計検証が可能になります。
今回行ったのは、単なるLLM比較ではなく、複数の視点を持つAIによる構造監査の多視点化という試みでした。一つのシステムを複数の職種的視点で診断することで、設計の盲点を発見しやすくなる可能性があります。
これは、設計プロセスにおける新しいアプローチの一つとして、今後検証を重ねていく価値がありそうです。
著:霧星礼知(min.k) / 構造支援:Claude Sonnet 4.5 / AI-assisted / Structure observation