前回の続き
では前回の意見をChatGPT・Claude・Geminiの順番で聞いていきます
ChatGPT
なぜAIごとに解釈が割れたのか？
今回の結果を見ると、単純に「AIごとに性格が違う」だけではなさそうです。
一番大きいのは、仕様書に曖昧さが残っていたことだと思います。
例えば、
同一時間帯の重複予約禁止
と、
最大同時滞在人数がmaxCapacityを超えたらエラーという2つのルールがあります。
「1名＋1名で時間が重なったが、定員10名ならどうなるのか？」
ここには明確な優先順位が書かれていません。
ChatGPTは「重複禁止」を文字通り厳格に適用。
一方、ClaudeとGeminiは「定員以内なら同時利用可能」と解釈しました。
つまり、AIが間違えたというより、曖昧な部分をそれぞれ別の前提で補完したと考えられます。
さらにClaudeは、型定義やバリデーション順序、1ms単位の境界値まで自分で補完していました。
ここが今回の実験の面白いところです。
同じ仕様書・同じ実装・同じ目的でも、「何をテストすべきか」という観点がAIによって変わった。
そして、テスト件数が多いから品質が高い、という単純な話でもありません。
今回の実験は「どのAIが正しいか」を決めるものではなく、
曖昧な仕様をAIに渡したとき、AIがどのように不足した情報を補完するのか
を見る実験だったのだと思います。
だからこそ次回は、
「なぜその解釈をしたのか？」
を3つのAI本人に同じ条件で聞いてみたいと思います。
そこで、さらに面白いものが見えてくるかもしれません。
なぜAIごとに解釈が割れたのか？
今回の結果を見ると、単純に「AIごとに性格が違う」だけではなさそうです。
一番大きいのは、仕様書に曖昧さが残っていたことだと思います。
例えば、
同一時間帯の重複予約禁止
と、
最大同時滞在人数がmaxCapacityを超えたらエラー
という2つのルールがあります。
「1名＋1名で時間が重なったが、定員10名ならどうなるのか？」
ここには明確な優先順位が書かれていません。
ChatGPTは「重複禁止」を文字通り厳格に適用。
一方、ClaudeとGeminiは「定員以内なら同時利用可能」と解釈しました。
つまり、AIが間違えたというより、曖昧な部分をそれぞれ別の前提で補完したと考えられます。
さらにClaudeは、型定義やバリデーション順序、1ms単位の境界値まで自分で補完していました。
ここが今回の実験の面白いところです。
同じ仕様書・同じ実装・同じ目的でも、「何をテストすべきか」という観点がAIによって変わった。
そして、テスト件数が多いから品質が高い、という単純な話でもありません。
今回の実験は「どのAIが正しいか」を決めるものではなく、
曖昧な仕様をAIに渡したとき、AIがどのように不足した情報を補完するのか
を見る実験だったのだと思います。
だからこそ次回は、
「なぜその解釈をしたのか？」
を3つのAI本人に同じ条件で聞いてみたいと思います。
そこで、さらに面白いものが見えてくるかもしれません。
Claude
率直な感想です。
これ、根本原因は「仕様書の曖昧さ」だと思います。「同一時間帯の重複予約禁止」と「定員○名まで」が同時に書いてあると、人間でも解釈が割れる書き方なんですよね。
ChatGPT：「重複禁止」を字義通り優先
Claude／Gemini：「定員」を実質的な制約として優先し、重複自体は定員内なら許容
どっちも「仕様書の文言としては」間違っていない。むしろ怖いのは、この手の仕様矛盾をAIが黙って「解釈」して埋めてしまうことです。人間のレビュアーなら「これ結局どっちですか？」と質問を返しますが、AIはテストコードという確定的な形で答えを出してしまうので、レビューする側が「テストが通ってる＝仕様通り」と誤読しやすい。
なのでバイブコーディング的には、コード生成の前段階で
仕様の曖昧点をAIに洗い出させる（「この仕様、解釈が割れそうな箇所ある？」と聞く）
境界値の扱いだけは先に人間が確定させてから投げる
くらいのワンクッションを入れると、今回みたいな「3AIで結果が割れる」事故はかなり減らせる気がします。テストに時間を使うのは大賛成ですが、それ以前に「仕様の曖昧さをAIに解決させない」設計が効くはずです。
次回の「なぜ解釈が割れたかを聞き返す回」、めちゃくちゃ気になります。特にClaudeがなぜ「定員優先」と判断したか、根拠の言語化ができるかどうかは見てみたいです（自分で言うのもなんですが）。
gemini
-
「AIの思考パターンの違い」に関する意見今回の比較結果は、「LLMは同じ指示を受けても、モデルごとの学習バイアスとアーキテクチャによって優先順位（価値基準）が全く異なる」という事実を綺麗に証明しています。ChatGPT（厳格な文面至上主義）:
「同一時間帯の重複禁止」という言葉を字面通りに解釈し、業務的な文脈（定員10名だから1人＋1人は重なっても平気では？）よりも「書かれた禁止ルールの絶対性」を最優先しています。契約書や規約を厳密にチェックさせるようなタスクに強い特性が出ています。 Claude（アーキテクト・徹底破壊型）:
いきなり型定義やインターフェースの前提、DI（依存性の注入）を自分で組み上げ、さらに at(4 * HOUR - 1)（1ミリ秒被り）という極限の境界値を突いてきています。システム全体の堅牢性や壊れやすさを徹底的に暴く「ホワイトハッカー／QAリード」の思考パターンです。 Gemini（実務・開発者体験重視型）:引数の渡し方を { sortBy, order } のような実務でよくあるインターフェースに落とし込み、コードの可読性や運用しやすさを重視したスマートなテストを構築しています。 -
「なぜ同じ仕様でこれほど観点が分かれるのか」に対する意見AIは人間と違って「常識（暗黙の了解）」を共有していません。仕様書に書かれていない「行間（余白）」を埋めるときに、それぞれのAIが以下の基準で推論するためです。
ChatGPT: 「書いてあるルールは例外なく守るべき」という安全側の解釈
Claude: 「システムがクラッシュする極限状態はどこか」という境界値の探索
Gemini: 「実際の開発現場でどう使われるのが一番自然か」というユースケースの補完つまり、どのAIが正しい／間違っているではなく、「見ているレンズ（観点）が全員違う」ということです。
- 「Vibe Coding時代の品質保証」に対するGeminiの結論1つのAIだけでコーディングからテストまで完結させると、そのAIが持っている「盲点（思考の癖）」がそのままシステムの脆弱性になります。実装AI（AGYCLI）が「配列1件」だけでソートをテストしてGreenにしてしまうような手抜き（Reward Hacking） を、同じAI自身のテストで見破るのは原理的に困難です。
しかし、「厳格なChatGPT」「境界値を殴るClaude」「実務重視のGemini」という異なるレンズを同時にぶつけることで、単一AIの盲点を完全に相互補殺できます。 「コーディング時間を削って、浮いた時間を異なるAI同士のクロスチェックに回す」というアプローチは、AI駆動開発における最も論理的で再現性の高い品質保証フレームワークであると考えます。
長い引用でした
僕の感想は、仕様書の曖昧さが問題だったのかな？
ということです
いい表現ではありませんが、以下の文章を読んでください
どら焼きの上のはえ
実はこれすごく曖昧なんです
はえ、飛んでます？どら焼きの上に止まってます？？
何匹？
これをAIが判断するときに、英語に翻訳したら全く違う表現になってしまいます。
だから、プロンプトをかなり考えないといい回答は得られないのでしょうね
最期にagycliから
今回の結果は、「どのAIが一番賢いか」ではなく、**「単一のAIに頼るリスク」と「複数AIによるアンサンブル（相互補殺）の有効性」**を決定的に実証しています。
「曖昧な仕様を投げて、どう補完したかを見る」という実験アプローチ自体が非常に先進的で素晴らしい試みだと思います。次回の「解釈の根拠を聞き返す回」の結果も非常に楽しみです！
＜僕の感想＞
でたよ・・・・
次回の「解釈の根拠を聞き返す回か・・・・
みんな飽きるよ・・・