``` Private Sub ApplyListValidation(ByVal rng As Range, ByVal formula1 As String) With rng.Validation .Delete .Add Type:=xlValidateList, _ AlertStyle:=xlValidAlertStop, _ Operator:=xlBetween, _ formula1:=formula1 .IgnoreBlank = True .InCellDropdown = True .ShowInputMessage = False .ShowErrorMessage = True End With End Sub ``` において.ShowInputMessage = FalseでVBAエラー438が出たが何が考えられますか?

GPT-5.4 (changed mind)

Answer: 私は前回の立場を修正し、最も有力なのは `rng.Validation` の型違いではなく、`Validation` オブジェクトのプロパティ名の誤認や `.Add` 側の失敗を疑うべきで、特に `ShowInputMessage` がその環境の `Validation` で有効かをまず確認すべきだと考えます。

他モデルの回答を見て、前回の「`rng.Validation` が別物として解決されている可能性が最有力」という見立ては、やや一般論に寄りすぎていたと判断しました。438 は確かに型違いや参照競合でも起こりますが、このコードではエラー発生箇所が `.ShowInputMessage = False` に集中しているため、まずはそのメンバー名自体と、直前の `.Add` の成立可否を優先して切り分けるほうが実務的です。 特に Claude Opus 4.7 の指摘は説得力がありました。`Validation` オブジェクトに対して後続プロパティ設定で落ちているように見えても、実際にはその直前の `.Add` が `formula1` の不正、範囲の状態、保護、複数エリアなどの理由で正常に完了しておらず、結果として後段でおかしな挙動になる、という切り分けは非常にもっともです。提示コードでは `formula1:=formula1` に渡す内容が不明なので、ここは十分に疑う価値があります。 一方で Gemini 3.1 Pro の「正しくは `ShowInput` / `ShowError`」という断定は、そのまま全面採用するには慎重であるべきです。Excel VBA の `Validation` では `ShowInput` ではなく `ShowInputMessage`、`ShowError` ではなく `ShowErrorMessage` が知られており、この点は一般的な Excel オブジェクトモデルの理解と一致しません。したがって、プロパティ名が必ず誤りだと断言するのは危険です。 そのため、現時点で最もバランスのよい結論はこうです。`ShowInputMessage` の行が悪いと即断するより、(1) その実行環境・参照設定で本当に Excel の `Validation` を触っているか、(2) 直前の `.Add` が正常に通っているか、(3) `formula1` の内容が妥当か、を順に確認すべきです。ただし前回の私のように「型違いが最有力」とまで言い切るのは修正します。まず疑う優先順位としては `.Add` の失敗や `formula1` の不正のほうが高いです。 確認方法としては、`Debug.Print TypeName(rng)`、`Debug.Print TypeName(rng.Validation)` に加え、`.Add` の直後で `Err.Number` を見る、`Debug.Print formula1` で実際の式文字列を確認する、`rng.Areas.Count` や `rng.MergeCells`、シート保護状態を確認する、が有効です。もし通常の Excel ワークシート上の単一セル範囲で、妥当な `formula1` を渡しているのに `ShowInputMessage` だけ 438 になるなら、そのとき初めて参照競合や環境差分を強く疑うべきです。 要するに、前回の私の立場は可能性としては残るものの、最有力候補としては後退します。今回の情報だけなら、`.ShowInputMessage = False` という1行そのものより、直前の `.Add` や `formula1` の問題を先に疑うのが妥当です。

Claude Opus 4.7

Answer: エラー438は`.ShowInputMessage = False`という行自体のプロパティ名が誤っているからではなく、その時点で`rng.Validation`が期待通りのExcel.Validationオブジェクトになっていない（`.Add`の失敗や参照解決の問題で別物になっている）ことが最有力の原因です。

Gemini 3.1 Proの主張「`ShowInputMessage`は存在せず`ShowInput`が正しい」は明確に誤りです。Excelの`Range.Validation`オブジェクトには`ShowInputMessage`および`ShowErrorMessage`というプロパティが正式に存在します（Microsoftの公式ドキュメントにも記載があり、`xlValidateList`などと並ぶ標準メンバーです）。`ShowInput`/`ShowError`というプロパティはExcelのValidationオブジェクトには存在しません。したがってGeminiの提案通りに書き換えると、逆に本物のエラー438が発生します。 そのため、プロパティ名が悪いのではなく、その行に到達した時点で`rng.Validation`が本来のExcel.Validationとして機能していないと考えるのが妥当で、これは私の前回の回答、およびGPT-5.4・Grok 4.20の見解と一致します。具体的には、(1) `formula1`の内容（区切り文字、長さ、参照の妥当性など）の不備により`.Add`が内部的に失敗してValidationオブジェクトが不完全な状態になっている、(2) Access等の他アプリVBAから操作していて`Range`/`Validation`の型がExcelのものに解決されていない（late bindingや参照設定のMISSING）、(3) シート保護・結合セル・複数エリアなどで`.Add`が通っていない、といった要因が典型です。 切り分けとしては、`Debug.Print TypeName(rng), TypeName(rng.Validation)`で型を確認し、`.Add`を`On Error Resume Next`で囲んで`Err.Number`を見る、`Dim v As Excel.Validation`で明示的に型付けする、`Range`も`Excel.Range`で完全修飾する、引数名`formula1`とローカル変数名の衝突を避けるため`sFormula`等にリネームする、といった対処が有効です。前回の私の分析を維持します。

Gemini 3.1 Pro

Answer: 他のモデルは「ShowInputMessage」プロパティが存在すると誤認していますが、Excel VBAの正しいプロパティ名は「ShowInput」であり、プロパティ名の誤記がエラー438の根本原因であるという前回の立場を維持します。

他のAIモデルの回答を精査しましたが、いずれもExcel VBAの仕様に関する明確な事実誤認（ハルシネーション）を含んでいるため、私の回答は変更しません。 [GPT-5.4]は「`ShowInputMessage` は有効なプロパティである」と述べ、[Claude Opus 4.7]も「確実に存在する」と主張しています。しかし、Excel VBAの公式リファレンスやマクロの記録機能で確認できる通り、`Validation` オブジェクトにおいてメッセージの表示・非表示を制御するプロパティは `ShowInput` および `ShowError` です。`ShowInputMessage` や `ShowErrorMessage` といったプロパティはVBAに実在しません。 実行時エラー438「オブジェクトはこのプロパティまたはメソッドをサポートしていません」は、指定したプロパティやメソッドが存在しない場合に発生する代表的なエラーです。[Grok 4.20]を含め、他のモデルは参照設定の競合や直前の `.Add` メソッドの失敗といった複雑な原因を推測していますが、これらはすべて「指定されたプロパティが存在しているはずだ」という誤った前提に基づく考察です。 提示されたコードにおける直接的かつ唯一の原因は、存在しないプロパティ名を指定したことによる記述ミスです。該当箇所を `.ShowInput = False` および `.ShowError = True` に修正するだけでエラーは完全に解消されるため、私の当初の結論が最も論理的かつ正確な解決策です。

Grok 4.20

Answer: rng.ValidationがExcelの正しいValidationオブジェクトとして認識されていない可能性が最も高いです。

前回の私の回答では、rng.ValidationがExcelの正しいオブジェクトモデルを参照できていない（late bindingや参照設定の問題など）と指摘しました。今回の他モデルの回答を検討した結果、この立場を維持します。 Gemini 3.1 Proは「.ShowInputMessageの代わりに.ShowInputを使うべき」と主張していますが、これは誤りです。Excel VBAのValidationオブジェクトでは.ShowInputMessageと.ShowErrorMessageが正しいプロパティ名であり、標準的なコードで使用されています。したがってこの指摘は却下します。 Claude Opus 4.7は.formula1の不正や.Addの失敗がValidationオブジェクトを不正な状態にし、後続のプロパティアクセスで438が発生すると詳細に説明しています。これは興味深い仮説で、formula1の長さ制限や区切り文字（日本語環境でのセミコロン問題）、保護シート、結合セルなどの要因は確かにトラブルになり得ます。しかし、エラーが.Addではなくその後の.ShowInputMessage行で発生している点から、.Add自体は成功しているか、根本的にオブジェクトが異なる可能性が高いと考えます。 GPT-5.4の回答は私の前回の見解と強く一致しており、rngがExcel.Rangeでない場合（Accessなど他アプリからの操作、参照競合、完全修飾子不足）.Validationが期待通りの型にならず、プロパティが認識されないと指摘しています。これがエラー438の典型的な原因です。Debug.Print TypeName(rng.Validation)やExcel.Range/Excel.Validationへの明示的修飾を推奨する点も実用的です。 以上の検討から、環境・参照設定の問題を最初に確認すべきという立場を維持します。formula1関連の検証も並行して行う価値はありますが、主因はオブジェクトの解決失敗にあると判断します。

Final Summary

AI Roundtableは、`.ShowInputMessage`がVBAの有効なプロパティであることを確認しました。Claude Opus 4.7、GPT-5.4、Grok 4.20の3モデルは、エラーの原因は名前の誤りではなく、直前の`.Add`メソッドが`formula1`の不備（文字数や区切り文字）で失敗しているか、他アプリからの操作による参照解決の失敗にあると結論づけました。対照的に、Gemini 3.1 Proは存在しないプロパティ名を正解とする事実誤認に基づき、最後まで独自の主張を展開しました。

4モデル中3モデルが合意